Announcement

Collapse
No announcement yet.

RadeonSI Gallium3D Is Improving, But Still Long Shot From Catalyst

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

  • #21
    Originally posted by Luke View Post
    I've tested GLAMOR with r600g on my Radeon HD6750, the only time I can ever see a 2d performance reduction in GLAMOR compared to EXA is in video rendering transitions in Kdenlive.
    Actually, i think Glamor falls back to EXA/UXA on r600g and Intel drivers in the cases when it doesn't implement a function. So that's why it's significantly better on those parts than on SI, where it truly falls down to pure software rendering when something is missing.

    Question then becomes this: if GLAMOR is a frontend to OpenGL, what is GLAMOR doing that makes OpenGL slow down in RadeonSI? Is the issue in GLAMOR, or in one or more OpenGL commands that are still slow in RadeonSI?
    There are 2 main issues that i'm aware of:

    1. Missing functions entirely. Tests like the lines and circles that are spectacularly bad happen because glamor doesn't accelerate them at all, because no one has written the code to do that in OpenGL yet.

    2. Batching lots of small operations together. In lots of cases the 2d driver might run a bunch of commands together, while in OpenGL it tries to do stuff like binding a separate texture per character, which introduces a lot of overhead. I'm not sure how much of an issue this really is in practice - it definitely needs a lot of work to look good in benchmarks, but I don't know if this is something you'd really notice that much in practice or not.

    Comment


    • #22
      Yeah. I was hoping to see the performance of the drivers with the Ungine benchmarks.


      I heard that there was problems with libre office (and other programs) with Glamor, but with the new upstream patches most of the problems have disappeared.

      Comment


      • #23
        Valve is so forthcoming when it comes to Linux, I am sure something could be arranged for Michael to automate benchmark testing using DOTA2, Left 4 Dead 2, and other games. I would really love to see AMD's open source driver be put to the test.

        Comment


        • #24
          Originally posted by brent View Post
          You actually see these scaling effects in the benchmarks if you compare the 7850 results against the 7950 results. In many cases, both GPUs have almost similar results with open drivers, while Catalyst is able to push considerably more frames on the 7950 compared to the 7850. That very much looks like the open drivers are CPU limited.
          Yes but Catalyst performance seems to regress hard in the Rx series compared to the HD 7xxx whereas the Radeon SI doesn't! R9 performs better than the older ones as it should be the case.

          Now I am amazed with the results guys! Not even 3 months passed since October and in some cases performance went up 14x for Radeon SI...
          Please keep the work high guys! AMD needs it and I can say deserves it!

          Comment


          • #25
            Originally posted by smitty3268 View Post
            Actually, i think Glamor falls back to EXA/UXA on r600g and Intel drivers in the cases when it doesn't implement a function.
            No, there are no fallbacks to any other acceleration architecture from glamor, only directly from glamor to software rendering. There is no difference between how glamor works on radeonsi vs. r600g. The main reason why the software fallbacks are less painful on Intel GPUs is that they can do the software rendering directly to the GPU accessible memory with relatively little pain, whereas this is not the case for us, especially not with discrete GPUs.

            1. Missing functions entirely. Tests like the lines and circles that are spectacularly bad happen because glamor doesn't accelerate them at all, because no one has written the code to do that in OpenGL yet.
            Right, we need more people helping to improve glamor. But it's picking up momentum, so I'm confident that the biggest perfomance issues can be solved this year.

            2. Batching lots of small operations together. In lots of cases the 2d driver might run a bunch of commands together, while in OpenGL it tries to do stuff like binding a separate texture per character, which introduces a lot of overhead. I'm not sure how much of an issue this really is in practice [...]
            I don't think it's much of an issue. In particular, wrt to your example of text rendering, glamor uses a similar kind of glyph cache as EXA does to minimize per-glyph overhead. IME this has actually performed slightly better than EXA for a long time, and there is probably potential for more improvement.

            P.S. I doubt glamor has any major impact on 3D benchmarks.

            Comment


            • #26
              Originally posted by enfocomp View Post
              Wow, the open source driver has been making some amazing progress recently... actually pretty surprised. I can't wait until the performance is on par with the Catalyst driver, because it's plagued with bugs and terrible 2D support. All we need now is a control panel for Gallium3D to quickly tweak options like vsync and power management so it can be a viable replacement for ALL users.

              Thanks for providing these benchmarks & keep up the good work!
              Try driconf (even though it's not maintained anymore), it may work. Also try starting an application with "vblank_mode=3" to force V-Sync (not sure if it's 3 or something else, try 1 and 2 maybe, too).

              Comment


              • #27
                Originally posted by blackout23 View Post
                Of course people care when catalyst runs 35% faster. Efficiency matters always. It's not like catalyst on Linux is on par with Windows to begin with.
                I don't care about efficiency when I'm gaming. I want the system to run flatout and never fall below 30FPS. If it does that it doesn't matter if it's running at 60FPS or 600FPS, so long as it never dips below 30 FPS I'm golden.

                Now doing things that don't require the GPU to be much more then a frame buffer, sure, get it down to running off of 0.001w if you can.

                Comment


                • #28
                  Originally posted by ua=42 View Post
                  I found it interesting that the older games were at around 50% and the newer games were around 75%. Looks like one (or more) of the older gl commands is really slow.
                  IIRC because they are. OpenGL3.0+ can do the same tasks as OpenGL2.1- much faster, but you'd lose compatibility with OpenGL2.1- if you write the game to make use of the newer methods of doing things. Least thats how it was explained to me a few years back by a game dev.

                  Comment


                  • #29
                    Originally posted by Andrecorreia View Post
                    the really problem is not 3d right now, is the 2d performance, what i see in phoronix last 2d benchs, opensource are really bad
                    GCN based GPUs don't have 2D hardware, they require it to be handled by the 3D engine. AMD did this to get more 3D performance in the same chip size, with Catalyst it has shown to be pretty fast and power efficient.

                    Give em' another 6 months to hammer it out and just as happened with R300 and R600, there will be a night and day difference after they've got all their underpinnings in place and can start working on optimization.

                    Comment


                    • #30
                      Well, I just ordered a 7870 for fun and self-hatred during an Amazon deep discount. Let's see how this baby works under Mesa!

                      Comment

                      Working...
                      X