Announcement

Collapse
No announcement yet.

R600g Driver Patch That Can 4x The Frame-Rate

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

  • R600g Driver Patch That Can 4x The Frame-Rate

    Phoronix: R600g Driver Patch That Can 4x The Frame-Rate

    Following yesterday's article comparing the AMD Radeon Linux drivers on Ubuntu 12.10, Marek Olk looked into some of the cases where the open-source Radeon Gallium3D driver was much slower than the proprietary Catalyst driver. Already with one patch that touches only two dozen lines of code, Marek was able to quadruple the open-source driver frame-rate for at least one game...

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

  • #2
    So... can you rerun all the benchmarks in the previous article with this patch?

    Comment


    • #3
      Originally posted by Sidicas View Post
      So... can you rerun all the benchmarks in the previous article with this patch?

      Nice idea...

      I'm very interested to soon build a machine with mini-ITX MB and a AMD APU and was to use the Catalyst driver....but was a bit worried with AMD "long therm" support as for drivers goes tacking in account what they did recently.

      R600g performance simply didn't seem to cut it and difference seemed so high that i was w/o hope that it would improve enough any time....


      But now....can we have a rerun of the tests ?

      Comment


      • #4
        Originally posted by Sidicas View Post
        So... can you rerun all the benchmarks in the previous article with this patch?
        That test was using the stable versions provided by Ubuntu, so I doubt Michael will just take that and apply the patch.

        But he's already said he was going to test out the latest git versions, and this patch has been merged into master now. So yes, the test is coming.

        Comment


        • #5
          Nice to hear. Wonder how well this will scale with other titles.

          Comment


          • #6
            Well... I was excited when I read that title. 4x the frame-rate on some of those tests would put them neck-n-neck with catalyst... but then I realized the test he's getting 4x performance on is the game that runs horribly slow on the OSS drivers. According to the Phoronix post, on the 6870 Reaction Quake get's 519 fps with Catalyst and 8 fps with Radeon... even if you quadruple that figure, you're still only getting 32 fps compared to Catalyst's 500+

            Don't get me wrong, it sounds like a very promising patch, congrats and thank you to the developer... I hope it's just that game, but I'm not going to hold my breath until I see more benchmarks.

            Comment


            • #7
              in mailine now

              commit fa58644855e44830e0b91dc627703c236fa6712a
              Author: Marek Olk <maraeo@gmail.com>
              Date: Thu Nov 1 00:52:19 2012 +0100

              r600g: fix abysmal performance in Reaction Quake

              The problem was we set VRAM|GTT for relocations of STATIC resources.
              Setting just VRAM increases the framerate 4 times on my machine.

              I rewrote the switch statement and adjusted the domains for window
              framebuffers too.

              NOTE: This is a candidate for the stable branches.

              Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
              Reviewed-by: Jerome Glisse <jglisse@redhat.com>

              Comment


              • #8
                before they improve heuristics ...

                they should check that they don't do huge amounts of useless stuff (like the stuff this patch removes).

                Comment


                • #9
                  Radeon superhero!

                  Cool!

                  Marek is a radeon superhero!

                  Comment


                  • #10
                    Nice work Marek! - both for that patch and for the next one, included below for reference.

                    author Marek Olk 2012-11-01 01:00:37 (GMT)
                    committer Marek Olk 2012-11-01 02:17:58 (GMT)
                    commit 1eedebc65b02130ef7a27062a1ed67972a317a08
                    tree b5994b2c8624e671efeb2d69823b96db7f572949
                    parent fa58644855e44830e0b91dc627703c236fa6712a

                    r600g: re-enable handling of DISCARD_RANGE, improving performance
                    It seems to work for me now. Even the graphics corruption is gone.

                    This also boosts performance in Reaction Quake.

                    Comment


                    • #11
                      Well, don't get too happy yet. I only replaced one heuristic with some other one. It's possible it will behave worse in some other app, who knows. Buffer placements are not a solved problem yet. We need a solution that is more robust in extreme scenarios.

                      Comment


                      • #12
                        Originally posted by marek View Post
                        Well, don't get too happy yet. I only replaced one heuristic with some other one. It's possible it will behave worse in some other app, who knows. Buffer placements are not a solved problem yet. We need a solution that is more robust in extreme scenarios.
                        More specifically.. If the game is VRAM starved then the performance would go down by some unknown amount with this patch, right? If it's not VRAM starved, the performance would go up by 4x or more with this patch, correct?. So it's just trading apples for oranges, although it certainly seems better to assume that the user has bought enough VRAM to play the games they're trying to play, it's certainly possible some users with cheaper hardware are better off without this patch, right?.

                        Somebody should try benchmarking the patch with an R600 GPU that has very little VRAM.

                        Do all the open source graphics drivers have these buffer heuristics problems?
                        Last edited by Sidicas; 11-01-2012, 10:30 AM.

                        Comment


                        • #13
                          Originally posted by marek View Post
                          Well, don't get too happy yet.
                          Well spoken Actually mesa is borked for me with present git master as the gdm login screen shows only garbage, which I believe did not happen like that in the long time. I am not sure what happen within the last two days for r600 [AMD E-350] but I am emerging (Gentoo package management) commit by commit to see what made my screen like that... However it is not this patch as I am already few commits back with checking and it is still there

                          Comment


                          • #14
                            Originally posted by ryszardzonk View Post
                            Well spoken Actually mesa is borked for me with present git master as the gdm login screen shows only garbage, which I believe did not happen like that in the long time. I am not sure what happen within the last two days for r600 [AMD E-350] but I am emerging (Gentoo package management) commit by commit to see what made my screen like that... However it is not this patch as I am already few commits back with checking and it is still there
                            It's much easier to isolate a regression using git bisect.

                            Comment


                            • #15
                              Originally posted by Sidicas View Post
                              Do all the open source graphics drivers have these buffer heuristics problems?
                              Potentially all drivers for hardware with different memory pools with different performance trade-offs. Additionally, besides, the total amount of vram on a card, the amount of vram used by other user apps will affect this to a certain degree.
                              Last edited by agd5f; 11-01-2012, 10:59 AM.

                              Comment

                              Working...
                              X