Announcement

Collapse
No announcement yet.

OpenCL Support Atop Gallium3D Is Here, Sort Of

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

  • #16
    Originally posted by 89c51 View Post
    once AMD finishes the work with classic mesa they will be able to port the code in gallium quite quickly (i think bridgman made a comment about it in the past)
    when is classic mesa finished?
    i mean feature wise...
    is there a concrete list of features they want to implement, then call it a day and start working on gallium?

    Comment


    • #17
      It would really be bad if Intel didn't at least have long term plans for Gallium use, considering there's already basic drivers available.

      Oh well, time will tell...

      Comment


      • #18
        Originally posted by Pfanne View Post
        when is classic mesa finished?
        i mean feature wise...
        is there a concrete list of features they want to implement, then call it a day and start working on gallium?
        Most of the features were finished in April, and any missing bits were added along the way while porting across to the radeon-rewrite code base. All we're doing now is fixing bugs. We may run across other missing bits along the way but feature-wise the code has been finished for a while.

        Work will continue on the classic Mesa implementation even after the initial bug-fixing is done, including getting it running over KMS/GEM/TTM, and we will probably use the classic mesa implementation as a base for extending the shader compiler, but the bug fixing is the only reason for not starting Gallium3D 6xx/7xx work now.

        I just hate porting code to a new platform unless it works properly on the current platform. We didn't really have a choice in the case of radeon-rewrite, but porting is *much* easier if you start with something that's already working the way you want
        Last edited by bridgman; 08-31-2009, 07:13 PM.

        Comment


        • #19
          every time i hear this i get excited and cant wait xD
          i know i sound impatient, but how long will a basic gallium port take. (i feel like im asking you this question every time you answer one of mine ^^), since mostawesomedude has been working on the r300-500 code for ages. ( i know he is not a fulltime developer and you have more manpower )

          Comment


          • #20
            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
            Last edited by bridgman; 08-31-2009, 09:58 PM.

            Comment


            • #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".

                  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; 09-02-2009, 11:41 AM.

                      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".

                            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; 09-02-2009, 03:10 PM.

                                Comment

                                Working...
                                X