Announcement

Collapse
No announcement yet.

R600 Open-Source Driver WIth GLSL, OpenGL 2.0

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

  • #16
    Originally posted by Hephasteus View Post
    I don't understand all the. Oh it's not going to come soon. Or it's not going to happen soon. These people have been working on this junk for YEARS.
    I think it's a product of the instant gratification-driven times we live in. For those of us who have really been following this stuff, we know how far open-source ATI support has come and how many prerequisite hurdles they've jumped to get to this point.

    Comment


    • #17
      Originally posted by Louise View Post
      Shouldn't Gallium Core Drive for R600-R800 be changed from TODO to WIP? That is what VMware is working on, right
      I think it is referring to an "r600g" driver, which AFAICT does not exist yet, since the work is being done for the classic mesa r600 driver first.
      http://cgit.freedesktop.org/mesa/mes...allium/drivers

      Comment


      • #18
        Originally posted by bridgman View Post
        The Gallium3D driver for 3xx-5xx already has GLSL and GL 2.1 enabled, and that's where all the development work is happening.

        I believe the shader compiler still needs some work for flow control instructions, but initial impression is that they don't actually get used very much.
        Interesting. Featuer matrix:
        R500: GL Level: 1.5/2.0
        R600+: GL Level: 2.0/3.0

        GLSL:
        R500: GLSL: WIP
        R600+: GLSL: MOSTLY

        Very interesting!

        Comment


        • #19
          Originally posted by Dragonix View Post
          Interesting. Featuer matrix:
          R500: GL Level: 1.5/2.0
          R600+: GL Level: 2.0/3.0

          GLSL:
          R500: GLSL: WIP
          R600+: GLSL: MOSTLY

          Very interesting!
          The feature pages don't tell the whole story (but I'm not sure anyone is ready to change the layout *again* ). You need to look at the R500 : Gallium3D : MOSTLY and know that the Gallium3D feature more-or-less includes GLSL and GL2.1. At least that's the plan.

          For 6xx-7xx there was no Gallium3D driver and 3D support of any kind was very recent so we added GLSL support to the existing "classic mesa" driver. For 3xx-5xx there was already a Gallium3D driver and developer focus had already shifted to the Gallium3D driver. Since the Gallium3D driver for 3xx-5xx already *had* GLSL and GL2.1 enabled it didn't seem to make a lot of sense to do anything in the "classic" HW driver.

          Comment


          • #20
            Originally posted by bridgman View Post
            The feature pages don't tell the whole story (but I'm not sure anyone is ready to change the layout *again* ). You need to look at the R500 : Gallium3D : MOSTLY and know that the Gallium3D feature more-or-less includes GLSL and GL2.1. At least that's the plan.

            For 6xx-7xx there was no Gallium3D driver and 3D support of any kind was very recent so we added GLSL support to the existing "classic mesa" driver. For 3xx-5xx there was already a Gallium3D driver and developer focus had already shifted to the Gallium3D driver. Since the Gallium3D driver for 3xx-5xx already *had* GLSL and GL2.1 enabled it didn't seem to make a lot of sense to do anything in the "classic" HW driver.
            So you advice me to use the Gallium driver? Great.. that halves the lousy performance again =)

            Comment


            • #21
              Originally posted by bridgman View Post
              For 3xx-5xx there was already a Gallium3D driver and developer focus had already shifted to the Gallium3D driver. Since the Gallium3D driver for 3xx-5xx already *had* GLSL and GL2.1 enabled [...]
              Are you sure about this?
              It's been a few weeks since I tried r300g but iirc it didn't have GLSL/GL2.1 yet. Afaik it's supposedly being implemented by nhaehnle in his r300g-glsl branch, but that has not seen any commits since more than two months so I didn't even bother giving it a try.
              But I'll give r300g a try again tomorrow.

              Comment


              • #22
                No, I advise you stop feeling put-out because you thought GLSL work was moving much faster on 6xx than it was on 3xx-5xx

                GLSL is not ready for general use on either of the open drivers yet, but it is making progress on both.
                Last edited by bridgman; 12-19-2009, 05:22 PM.

                Comment


                • #23
                  Originally posted by Zhick View Post
                  Are you sure about this?
                  It's been a few weeks since I tried r300g but iirc it didn't have GLSL/GL2.1 yet. Afaik it's supposedly being implemented by nhaehnle in his r300g-glsl branch, but that has not seen any commits since more than two months so I didn't even bother giving it a try.
                  But I'll give r300g a try again tomorrow.
                  I haven't had a chance to try any of the new code myself, but someone asked about the status on #radeon a week or so ago and eosie replied that GLSL and GL 2.1 were already enabled :

                  http://people.freedesktop.org/~cbril...ate=2009-11-21

                  Note that "enabled" is a bit arbitrary, in the sense that you can report lots of functionality without implementing it, you're just "raising the bug count". Michael's article said that Richard had enabled the reporting of GLSL and GL 2.0 in the 6xx-7xx driver; it's important to understand that the 300g driver has *already* reached that point.

                  I believe the r600 shader compiler is further ahead than the r300g compiler with respect to the instructions required for "full" GLSL, but it appears that a lot of apps require GLSL but then use essentially the same functions supported by arb_vp and arb_fp. Mesa compiles GLSL and ARB_*P down to the same IL and only passes IL to the driver, so having GLSL enabled and starting to test apps is useful without waiting for all of the new IL functions to be implemented.

                  The following snippet is a pretty good summary of r300g status :

                  02:33 #radeon: < EruditeHermit> eosie, does it report GL2.0 yet?
                  02:33 #radeon: < eosie> EruditeHermit: yes, except NPOTs
                  02:34 #radeon: < EruditeHermit> so glxinfo reports 2.0?
                  02:34 #radeon: < eosie> 2.1 actually
                  02:34 #radeon: < EruditeHermit> nice
                  02:34 #radeon: < EruditeHermit> so what doesn't work then?
                  02:34 #radeon: < eosie> lots of things
                  With respect to GLSL and GL2.x, that's pretty much the same as 6xx-7xx. Neither is ready for general use but both have progressed to the point where it's worth enabling these features so that app testing can begin. Most of the testing so far has been on unit tests rather than full-blown applications.

                  My understanding was that Nicolai was adding the missing Mesa IL instructions which would be required to *fully* implement GLSL on 3xx-5xx, which is (slightly) orthogonal to enabling GLSL itself for all of the IL functions which are already implemented.

                  Anyways, the key point here is that r300g and r600 are following different paths to the same goal, so they are not going to pass milestones in exactly the same order.
                  Last edited by bridgman; 12-19-2009, 05:47 PM.

                  Comment


                  • #24
                    thanks for the info bridgman. I just updated to r300g, so I can have GLSL, which I need as a programmer.
                    My experience so far: compiz works, World Of Goo works, Qt GLSL demo works. Openarena 15fps, chromium-bsu crashes, insane CPU usage. But it fits my needs
                    Will maybe buy an Evergreen GPU, once I figured out what I can use it for

                    Comment


                    • #25
                      Originally posted by bridgman View Post
                      I believe the r600 shader compiler is further ahead than the r300g compiler with respect to the instructions required for "full" GLSL, but it appears that a lot of apps require GLSL but then use essentially the same functions supported by arb_vp and arb_fp.
                      Wine claims that it needs GLSL to implement some of DirectX shaders opcodes. I don't know exactly which ones though, but I think they are already implemented. But yet Half-Life 2 -> ARB vp/fp sort of works in DirectX 8 mode, but Half-Life 2 -> GLSL doesn't.


                      http://wiki.winehq.org/DirectX-Shaders
                      Last edited by monraaf; 12-19-2009, 09:04 PM.

                      Comment


                      • #26
                        It is fun to think a year back, when all the talk was about getting the infrastructure right (staging and such) and get the specs out.

                        Now we see a new feature every month.

                        Comment


                        • #27
                          Originally posted by bridgman View Post
                          AFAIK the VMWare folks are primarily working on (a) the Gallium3D driver for their emulated SVGA hardware, and (b) the non-driver portions of the Gallium3D framework (ie Mesa, Xorg, GL, VG, CL etc... state trackers along with refining the internal APIs).

                          Corbin (MostAwesomeDude) mentioned that he was starting on a Gallium3D driver for 6xx-8xx but that's all I have heard. Richard is looking forward to working on Gallium3D as well; best guess is that will happen after (a) some testing / fixing on 6xx-7xx GLSL, and (b) getting inital 3D engine support working on Evergreen.
                          So VMware is taking a gamble that it will get done when they are ready

                          Comment


                          • #28
                            I hope that the work done with r600 GLSL will be used in future r600g Gallium driver. As far as I know current Gallium drivers use a lot of features (files) from classic mesa drivers. Am I right? If so, does it mean that with correct r300g and r600 drivers it will be far simplier to create r600g driver?
                            I hope it's true I've been a programmer for several years, but I've never worked on such a large code-base. If I knew what to do I would help with this probably

                            And most important: Good Work!

                            Comment


                            • #29
                              Recently i installed ubuntu on an old amilo laptop with an r300 chip. I was impressed. Everything looked much more "integrated", from the initial modesetting, to compiz, even some small things like window resizing which was pretty smooth (unlike nvidia). So i would really like to move my hardware to ATI as soon as possible (from nvidia), possibly with an r700-r800 chipset, but before i do that i would really like someone to explain when we can expect to have most of the missing pieces completed. From what i read it is not only a driver issue but a lot of other things that need work on the rest of the stack.

                              Maybe someone to clarify what these things are (and with a timeframe please ?)

                              Comment


                              • #30
                                Originally posted by Pfanne View Post
                                thats probably, why it says "mostly"...
                                most of the work is done, but it still doesn't do anything
                                but i did see some nice furmark screenshots.
                                Just a note,but it is probably not a great idea to run Furmark in wine on a ATI 4850/4870 card where the drivers do not have VRM protection like they do in the windows drivers. Without that protection present, furmark has been proven to kill those cards.

                                Comment

                                Working...
                                X