Announcement

Collapse
No announcement yet.

OpenCL Support Atop Gallium3D Is Here, Sort Of

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    good to know.
    thanks

    Comment


    • #22
      Originally posted by bridgman View Post
      We'll have a better idea once the 3xx-5xx Gallium3D driver is further along.

      Cooper is starting to come up to speed on the r300g driver and will help there; the "plan" is still that 6xx/7xx classic mesa, 3xx-5xx Gallium3D and 6xx/7xx KMS/GEM/TTM/DRI2 will all finish off at roughly the same time. All of them seem to be pretty close now; between MostAwesomeDude's work and nha porting the shader compiler across I have to think that most of the heavy lifting for the 3xx-5xx Gallium3D driver has been done.

      Once those three are all working, we can tell you roughly how long it will take for the 6xx/7xx Gallium3D driver
      Here's hoping the 8xx driver won't lag too much.
      You seem to have so much work on your plate

      Comment


      • #23
        Remember that it's not just us doing the work. Our developers are supposed to be "a small part of a much larger community".
        Test signature

        Comment


        • #24
          I reallistically can't see outside devs bringing a full-featured driver for a just-released hardware. And I can't see AMD releasing specs way before the hardware is selling.
          So community work will always be good for infrastructure, porting and debugging, but the core work has to be done by insiders if it's meant to be on time (not years after the hardware is on the shelves).

          Comment


          • #25
            Depends what you mean by "core work". I agree that our time is generally best spent adding support for new GPUs, since that is the one area where access to inside information can speed up understanding and troubleshooting even if the inside information can't be released.

            That said, there are also a few places where pitching in a bit of effort might be able to "push something over the hump" and make it possible for community developers to make progress on other parts of the stack. That's how I see the 3xx-5xx Gallium3D driver, and why I think it's worthy of some time.
            Last edited by bridgman; 02 September 2009, 11:41 AM.
            Test signature

            Comment


            • #26
              Hopefully basic 3d accel and KMS for r600+ will make it to Fedora 12

              Comment


              • #27
                Originally posted by bridgman View Post
                Depends what you mean by "core work". I agree that our time is generally best spent adding support for new GPUs, since that is the one area where access to inside information can speed up understanding and troubleshooting even if the inside information can't be released.

                That said, there are also a few places where pitching in a bit of effort might be able to "push something over the hump" and make it possible for community developers to make progress on other parts of the stack. That's how I see the 3xx-5xx Gallium3D driver, and why I think it's worthy of some time.
                Exactely. r300g is both infrastructure (looking to improving Gallium3D) and porting work, so it's best done by the community but can be done only on that kind of hardware: many years old (r300 is 7 years old) and well-known by people outside AMD.

                But an r800g driver could only be made by AMD (otherwise it'd be ready in 2016), that's why I hope you'll manage to get it out on time.

                Comment


                • #28
                  I expect that the first step for Evergreen 3D will be adding support to the classic Mesa driver - that will get functionality into users hands much more quickly.

                  Once support has been added to the classic mesa driver, anyone in the community can write "r800g".
                  Test signature

                  Comment


                  • #29
                    I have to say that the plans outlined by bridgman are all very reasonable, and I agree that it's the Right Thing for going forward.

                    We've had a short discussion about r300 vs. r300g on IRC without any real conclusion. Obviously, the long term focus will be on r300g, there's no doubt about it; the question is whether classic Mesa will get OpenGL 2.0 support.

                    Personally, I increasingly side towards not adding OpenGL 2.0 to the classic driver. Better to stabilize it at an OpenGL 1.5 level for the conservative folk, and then focus on getting up to OpenGL 2.1 for Gallium.

                    Comment


                    • #30
                      Yep. Once r300g gets a bit further it will (hopefully) become a lot easier to decide where each new feature should be implemented, and at that point it seems likely that anything more than low-hanging fruit will go into r300g. Right now there's a strong temptation to add functionality to r300 "because it is there".

                      If we can continue to share the shader compiler between r300 and r300g (thank you !!) I guess it's possible that r300 may end up as "1.5 plus GLSL" but there may be other driver enhancements required to support GLSL that I haven't realized yet. I have no ideal how GLSL arrays are implemented, for example
                      Last edited by bridgman; 02 September 2009, 03:10 PM.
                      Test signature

                      Comment

                      Working...
                      X