Announcement

Collapse
No announcement yet.

A Fresh Look At The AMD Radeon Gallium3D Performance

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

  • #46
    @whizse

    It seems that every gallium driver has got issues showing the reference pictures in test 3 and test 4 does not show anything or renders incorrectly. intel 945 without gallium renders everything correctly, intel snb has bad rendering in test 4. As additional error with nouveau (tested with series 7 and 9): screenshot with n crashes the driver. I would suggest to test every driver against gl2benchmark and trine. trine is also a good test as it does not work correctly with nouveau series 7 and shows nothing with intel snb. Of course heaven would be interesting too. Only testing openarena (and quake live) is boring, that works basically everywhere...

    Comment


    • #47
      Originally posted by Kano View Post
      @whizse

      It seems that every gallium driver has got issues showing the reference pictures in test 3 and test 4 does not show anything or renders incorrectly. intel 945 without gallium renders everything correctly, intel snb has bad rendering in test 4. As additional error with nouveau (tested with series 7 and 9): screenshot with n crashes the driver. I would suggest to test every driver against gl2benchmark and trine. trine is also a good test as it does not work correctly with nouveau series 7 and shows nothing with intel snb. Of course heaven would be interesting too. Only testing openarena (and quake live) is boring, that works basically everywhere...
      Right, but file bug reports. I have no interest in gl2benchmark any longer, as for Trine, it seems to work fine on my hardware. The only bug open with Trine/SNB is 36224 and it could probably need updating.

      Comment


      • #48
        Originally posted by Kano View Post
        @whizse

        It seems that every gallium driver has got issues showing the reference pictures in test 3 and test 4 does not show anything or renders incorrectly. intel 945 without gallium renders everything correctly, intel snb has bad rendering in test 4. As additional error with nouveau (tested with series 7 and 9): screenshot with n crashes the driver. I would suggest to test every driver against gl2benchmark and trine. trine is also a good test as it does not work correctly with nouveau series 7 and shows nothing with intel snb. Of course heaven would be interesting too. Only testing openarena (and quake live) is boring, that works basically everywhere...
        What's this about Trine not working on Nouveau? And what are "series" 7 and 9?

        Comment


        • #49
          Good job AMD.....if you keep up the good job i swear i will switch from Nvdia to AMD very soon. I appreciate very much your effort!

          Comment


          • #50
            @tacco:

            I already have, it was AMDs work on open source drivers that convinced me to get a radeon on my new laptop (well, that and Optimus)

            Comment


            • #51
              BTW, 75% of Catalyst performance FTW! With some optimisations still on the way!

              We shouldn't open the champagne just yet, though. These are rather simple 3d applications, and I'm guessing that more recent engines are going to suffer because of the GLSL compiler.

              Once the work on GLSL 3.3 is done, we'll have OpenGL 3.3 conformance too (there are only a few extensions missing, GLSL is the biggest part). Any news on how this is going?

              Still, I'm very impressed by the improvements.

              Comment


              • #52
                Originally posted by pingufunkybeat View Post
                BTW, 75% of Catalyst performance FTW! With some optimisations still on the way!

                We shouldn't open the champagne just yet, though. These are rather simple 3d applications, and I'm guessing that more recent engines are going to suffer because of the GLSL compiler.

                Once the work on GLSL 3.3 is done, we'll have OpenGL 3.3 conformance too (there are only a few extensions missing, GLSL is the biggest part). Any news on how this is going?

                Still, I'm very impressed by the improvements.
                Ho hum, the work going on is to support GLSL 1.30 isn't it? And to get up to OpenGL 3.3 you would need to implement GLSL 1.40, 1.50 and then 3.30.

                But maybe the biggest hurdle is the step from 1.20 to 1.30?

                Comment


                • #53
                  Yep, 1.30 is on the menu first (the others haven't been started). But higher GLSL functionality must be planned for some time after that is finished. I don't know how extensive the required GLSL changes are, but there must be a reason why the progress seems to be so slow.

                  Comment


                  • #54
                    Originally posted by pingufunkybeat View Post
                    Yep, 1.30 is on the menu first (the others haven't been started). But higher GLSL functionality must be planned for some time after that is finished. I don't know how extensive the required GLSL changes are, but there must be a reason why the progress seems to be so slow.
                    I know about the GLSL 1.30 progress in Mesa, so I'll give a summary of what's still needed.

                    In the Mesa state tracker (st/mesa), the main key is my GLSL->TGSI translator that adds native integer support for drivers that support it, which is required for GLSL 1.30. I'm putting the finishing touches on that as we speak (I'm taking a short break from it to type this post), and I'm hoping to get it merged to Mesa master before the 7.11 merge window closes on June 24.

                    Once that's merged, the only requirement on the driver side will be to add integer support to each Gallium driver for hardware that supports it.

                    The biggest chunk of undone work is in core Mesa, though. GLSL 1.30 adds switch statements and clip distances, neither of which have been started on. As I understand it, there is also some work that needs to be done in Mesa outside of the GLSL compiler as part of the shader extensions required by OpenGL 3.0.

                    Comment


                    • #55
                      Thanks for the update. So the majority of remaining GLSL work is in adding additional language constructs to the compiler?

                      Do you know how much additional work is needed for 1.40, 1.50 and beyond? Are they small changes, or huge amounts of new functionality?

                      Comment


                      • #56
                        Thanks for taking the time to explain things, and for doing the work in the first place, we sure do appreciate it!

                        Comment


                        • #57
                          Originally posted by pingufunkybeat View Post
                          Thanks for the update. So the majority of remaining GLSL work is in adding additional language constructs to the compiler?
                          Switch statements are a language construct, but gl_ClipDistance is a built-in variable that apparently needs some work in either the compiler or core Mesa to get working properly. (I'm not sure about what's needed for it, since I know less about rendering than I do about shaders.) I think we might also need gl_InstanceID and anything else required by the GL_EXT_gpu_shader4 extension.

                          Originally posted by pingufunkybeat View Post
                          Do you know how much additional work is needed for 1.40, 1.50 and beyond? Are they small changes, or huge amounts of new functionality?
                          I don't know for sure, but probably the latter.

                          Originally posted by whizse
                          Thanks for taking the time to explain things, and for doing the work in the first place, we sure do appreciate it!
                          Thanks for appreciating my efforts!

                          Comment

                          Working...
                          X