Announcement

Collapse
No announcement yet.

RadeonSI Gallium3D Is Improving, But Still Long Shot From Catalyst

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

  • #16
    the really problem is not 3d right now...

    the really problem is not 3d right now, is the 2d performance, what i see in phoronix last 2d benchs, opensource are really bad

    Comment


    • #17
      Good to see the progress. This IS pretty impressing. Yes, maybe fglrx is in most parts 2x the max. fps, but 120 fps is already a lot. I'm really impressed. If issues solve at this speed, then I hope Kabini/Kaveri is going to lift off soon on Linux. I can't wait for mainboard vendors to support Kaveri and bring Kabini boards and to see the 45W Kaveri in stores. Hopefully I can gift myself one for birthday this year.

      Comment


      • #18
        Originally posted by zanny View Post
        I've heard that someone is working on a kcm module for kde 5 to control Mesa settings in the system settings framework. That was a while ago, though.

        I find it odd that in that span of cards they all perform within pretty close margins of each other. I wonder how the 260x / 7770 perform? Are they in that same envelope? If that is the case, anyone looking at radeonSI gpus would get the best bang for the buck at the lowest end of the scale.

        But that doesn't seem right. I thought the patches to enable all the cores went in a few Mesa versions ago? Why would hardware with only 2/3 the shaders (7850 vs 7950) perform on par or better in all these tests?

        That is because they all have got 32 ROP units. So what this benchmarks are really testing is how fast this GPUs can push pixels onto screen. As others already stated benchmarks beyond 100fps are pretty much useless, you could simply use glxgears instead.

        These cards need vertex and shader heavy food. The 7950 has a theoretical peak performance of 2.8 TFLOPS? Its compute units are just idling along with loads presented here.

        Comment


        • #19
          This is competitive with r600g

          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!
          In fact, these results mean that for gaming/openGL loads there should be no more need to root around for older r600/Evergreen/Northern Islands hardware. GLAMOR is still reported to be slow for 2d loads but that should not be too hard to fix-at least not on the larger cards and midsize cards. 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. 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?

          I can tell you that Catalyst also sucks for 2d acceleration, especially for XV video playback. Back in Summer 2012 one version was so slow it took a radeon 6750 just to play a 1080p video without lagging, the 5570 could not cut it. of course, the previous version of Catalyst crashed outright on XV playback. GLAMOR won't have to be that hot to beat it unless Catalyst has improved a hell of a lot in video work.

          Comment


          • #20
            Originally posted by Luke View Post
            In fact, these results mean that for gaming/openGL loads there should be no more need to root around for older r600/Evergreen/Northern Islands hardware. GLAMOR is still reported to be slow for 2d loads but that should not be too hard to fix-at least not on the larger cards and midsize cards. 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. 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?

            I can tell you that Catalyst also sucks for 2d acceleration, especially for XV video playback. Back in Summer 2012 one version was so slow it took a radeon 6750 just to play a 1080p video without lagging, the 5570 could not cut it. of course, the previous version of Catalyst crashed outright on XV playback. GLAMOR won't have to be that hot to beat it unless Catalyst has improved a hell of a lot in video work.
            The problem of glamor is that in some cases it doesn't use GPU for rendering. In such cases it fallbacks to software rendering which is too slow in glamor. Bug report for this.

            Comment


            • #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