Announcement

Collapse
No announcement yet.

R600g Driver Patch That Can 4x The Frame-Rate

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

  • #16
    Originally posted by Sidicas View Post
    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?
    That was my initial thought as well: If this change will ALWAYS put the resources in VRAM, what happens if you are VRAM starved (or worse: Don't have enough free VRAM to honor the request?).

    Comment


    • #17
      Originally posted by gamerk2 View Post
      That was my initial thought as well: If this change will ALWAYS put the resources in VRAM, what happens if you are VRAM starved (or worse: Don't have enough free VRAM to honor the request?).
      The kernel driver will attempt to free up enough vram to honor the request by migrating other buffers out of vram, but if there is still not enough room, you'll end up with gart. Depending on how much migration has to take place, it's sometimes better to just use gart in the first place. There are no simple answers.

      Comment


      • #18
        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
        Can you try setting R600_LLVM to 0, because running glxgerars with R600_LLVM=1 produces this:

        Comment


        • #19
          Originally posted by Sidicas View Post
          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?.
          If the game is VRAM starved, TTM will do a lot of buffer moves to satisfy r600g wanting buffers in VRAM, possibly moving some buffers out. The same happens when those other buffers are used. Yeah, the time spent on rendering can be lower than the time spent on buffer moves. The problem with the current implementation is it doesn't honor the initial placement when we run out of memory and then some memory is freed. I would expect some buffers to be moved back to their initial location, which isn't happening. Also we should evict buffers based on how they're used (colorbuffer or texture, index buffer, etc.).

          Comment


          • #20
            Originally posted by Sidicas View Post
            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.
            According to the tables at http://en.wikipedia.org/wiki/Compari...3xxx.29_series the Radeon HD 2400 Pro (RV610) was available with 128MB or 256MB or 512MB of DDR2 VRAM. All other desktop/discrete R600 hardware has 256MB or more. In the mobility segment, the Mobility Radeon X2300 and the Mobility Radeon HD 2300 (RV515) were available with 128MB (as well as 256MB and 512MB for the Mobility Radeon HD 2300), with everything else having 256MB or more.

            Comment


            • #21
              OK, it looks like Sapphire might have made a 128MB GDDR4 version of the HD 2600 XT.

              Comment


              • #22
                Originally posted by F i L View Post
                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.
                Default configuration on ubuntu is not good. With proper config i reach 60fps on HD6850 with r600g vs 340fps for fglrx same config. Using ubuntu like config i am at 8fps.

                Comment


                • #23
                  Originally posted by glisse View Post
                  Default configuration on ubuntu is not good. With proper config i reach 60fps on HD6850 with r600g vs 340fps for fglrx same config. Using ubuntu like config i am at 8fps.
                  Would you mind giving us some ideas on what a proper config might be? I'm on a 4670, and I've enabled PCIE, but haven't seen any gains.

                  Thanks

                  Comment


                  • #24
                    Add this line to your gpu device section in xorg.conf
                    Option "ColorTiling2D" "true"

                    And use kernel >= 3.6 and mesa from git.

                    Comment


                    • #25
                      And no Unity, eh?

                      Comment


                      • #26
                        Considering my card has 1024 MB of VRAM, I may be in for a little bit of win then?

                        Comment


                        • #27
                          Originally posted by glisse View Post
                          Default configuration on ubuntu is not good. With proper config i reach 60fps on HD6850 with r600g vs 340fps for fglrx same config. Using ubuntu like config i am at 8fps.
                          That's good to hear, and now I'm excited to see how this patch effects the performance with proper settings and/or on Gnome Shell.

                          Comment


                          • #28
                            Originally posted by Sidicas View Post
                            Somebody should try benchmarking the patch with an R600 GPU that has very little VRAM.
                            I can see the benefit of testing on other cards to get the subtle differences in implementation, but wouldn't memory shortages be relatively "easily" tested with developer tools or special driver options/commands. [ie, a tool that fills up VRAM with movable or unmovable blocks of memory to simulate different constraints]

                            [I'm curious though what, if any, external testing is even possible to assist developers, considering I expect it requires analysis of memory allocation/usage. I guess there are the piglit unit tests. Of if Michael (by that I mean the automated test suite) could be more granular in the driver performance testing (which features improved/regressed release to release). Not being a driver developer, I'm not sure what help I could really offer?]

                            [It always seems funny that Phoronix on the one hand talks about new features/improvements/and sometimes bugs that do not relate to the normal every day user, only those on the bleeding edge, but on the other hand often only runs benchmarks on default settings... such a contradiction]
                            Last edited by Craig73; 11-01-2012, 02:58 PM.

                            Comment


                            • #29
                              Originally posted by agd5f View Post
                              It's much easier to isolate a regression using git bisect.
                              Some time in the future I might take a look at that, but in the mean time it is quite easy using portage features for that purpose as all I need to do is to place EGIT_COMMIT="" in the live git ebuild for the package and then emerge it. It would do all other steps for me installing it it the proper place etc so it is not all that bad approach to find stuff out either I think

                              Originally posted by sobkas View Post
                              Can you try setting R600_LLVM to 0, because running glxgerars with R600_LLVM=1 produces this:
                              This is exactly what my screen looked like, however changing the setting didn't help

                              offender found here
                              http://cgit.freedesktop.org/mesa/mes...d1b57b437ed991

                              this one works just fine
                              http://cgit.freedesktop.org/mesa/mes...f4974646bc332d

                              Comment


                              • #30
                                further examination led to discovery that 5ab82e0ccf84855e9311ebfc58d1b57b437ed991 is the sole root of the problem as git master works well with just this one patch reverted

                                Comment

                                Working...
                                X