Announcement

Collapse
No announcement yet.

ATI R500 Gallium3D Performance In June 2010

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

  • ATI R500 Gallium3D Performance In June 2010

    Phoronix: ATI R500 Gallium3D Performance In June 2010

    The past several months have been very exciting in the world of Gallium3D, the new graphics driver architecture for Linux and other operating systems that has been in development for years. This year we have witnessed the emergence of LLVMpipe to accelerate OpenGL commands on the CPU, Nouveau's Gallium3D driver starting to work well, and many other advancements. Over the past few months we have also been pleased with how the "R300g" driver has taken shape with this Gallium3D driver for ATI Radeon R300/400/500 series hardware (up through the Radeon X1000 series) stabilizing, performing well, and advancing beyond the classic Mesa 3D R300 driver. Today we have a fresh set of benchmarks looking at this ATI Gallium3D driver that soon will become the default.

    http://www.phoronix.com/vr.php?view=15000

  • #2
    The suspiciously flat line performance of the Gallium3D drive in most tests makes me think that this driver is still very CPU-bond (software fallbacks?). Can anyone confirm or dismiss this?

    Comment


    • #3
      Could you do the same test with low end R500 or mid end R300/R400 cards?

      I'm always going to 800x600 on my Radeon 9600 to get better FPS in Nexuiz on classic Mesa. I wonder how good/bad FPS I can get with Gallium3D now.

      Comment


      • #4
        As you can imagine probably it would be interesting which commit caused the regression. But maybe it's not so easy to find out with git-biselect because there is so much working at the code...?

        Comment


        • #5
          Those benchmarks are good as they spot obvious potential issues.

          Comment


          • #6
            It would be even more interesting if catalyst 9.3 numbers were show too.

            Comment


            • #7
              Originally posted by Jimbo View Post
              It would be even more interesting if catalyst 9.3 numbers were show too.
              Well, from an open source fan boy, catalyst can go to hell...

              Comment


              • #8
                Originally posted by sylware View Post
                Well, from an open source fan boy, catalyst can go to hell...
                Well, from a fellow open source fan boy, I'd quite like to see the comparision with that last usable fglrx too.

                C'mon, 3D accel is generally the only reason so many people use fglrx in the first place, so a comparision to show how far the open drivers are coming along in a series of 3D benchmarks is relevant...

                Comment


                • #9
                  Catalyst will go to hell much sooner if the OSS stack can match (or approach) its 3D performance.

                  So bring on the comparison, so we can see how far we still have to go!

                  Comment


                  • #10
                    Is this with VSync on or off?

                    Comment


                    • #11
                      Originally posted by nanonyme View Post
                      Is this with VSync on or off?
                      Considering FPS of ~100 - 110 it would be safe to assume VSync is off.
                      Vsync wouldn't make Gallium stick to 20 FPS either.


                      The conclusion is:

                      1) Gallium is experiencing FLAT lines
                      - This means it is being maxed out by the CPU in those tests.

                      2) Gallium starts with a lower frame rate than Mesa but fares better at higher resolutions.
                      - This means there is a lot of overhead (CPU?) but it scales well.

                      Comment


                      • #12
                        Two thoughts:
                        1) r300g uses a SLOW (at least until very recently) flush+sync (glFinish) implementation since the current implementation of swap&sync is still considered experimental.
                        2) I'm not sure whether color tiling is automatically enabled on r500. It should give a nice boost.
                        I'll be happy if a dev can correct/complete me.

                        Comment


                        • #13
                          Originally posted by kbios View Post
                          Two thoughts:
                          1) r300g uses a SLOW (at least until very recently) flush+sync (glFinish) implementation since the current implementation of swap&sync is still considered experimental.
                          However there is the exact same slow implementation in r300c.

                          Originally posted by kbios View Post
                          2) I'm not sure whether color tiling is automatically enabled on r500. It should give a nice boost.
                          Yes, it is, but you need latest xf86-video-ati from git.

                          I guess I should figure out why it fails so badly in Tremulous and Smokin' Guns.

                          Comment


                          • #14
                            Originally posted by marek View Post
                            However there is the exact same slow implementation in r300c.


                            Yes, it is, but you need latest xf86-video-ati from git.

                            I guess I should figure out why it fails so badly in Tremulous and Smokin' Guns.
                            well to be fair is impressive already how fast it got compared to march in only 3 months, but ppl remember that mesa 7.9 is under constant heavy development, which could lead to some issues until the code stabilize, for example:

                            * many operations internally in libgl could be only partially implemented(aka remember it could be several algorithm for 1 function wich optimize the render depending on X number of variants).

                            * some operations could be handle rigth now through llvmpipe until the proper code for the gpu is optimized

                            * that game could be using an gl extension not implemented yet so it fall to llvmpipe or it generates an error and fallback

                            * mesa 7.9 still hasnt reached the level for optimization of the render code cuz they still are focused on gl2.1/glsl features, so many algorithm can just be putting there up to the point it renders properly if so it's stays like that for waiting for further optimization when they reach that level


                            so conclusion, is a very early code yet(mesa 7.9 isnt even in alpha state) so many many stuff can go wrong right inside libgl but even that way they are showing an outstanding progress nonetheless.

                            lol if they make the driver render at 50% of the speed of fglrx or even more in mesa 7.9, hell why use fglrx after that?(if someone wanna answer just point stuff that actually works 100% of the time without glitches/slowdown/poor quality, i made it really hard, didin't i?)

                            Comment


                            • #15
                              Well all I can say is that I'm very happy whith the way Gallium3D radeon driver is improving. I'm using it for about a week now and I don't care so much about the games as I do about desktop performance. And with Gallium KDE/KWin desktop effects sure do run a bit more fluidly. The two other 3D apps I care a lot are Stellarium and Blender. I didn't have time to test those two with Gallium yet, but I'll see after I finish with the exams. So keep doing the great job guys!

                              Comment

                              Working...
                              X