Announcement

Collapse
No announcement yet.

Ubuntu 12.10: Open-Source Radeon vs. AMD Catalyst Performance

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

  • #46
    Originally posted by locovaca View Post
    You have heard wrong. 60 hz is when flickering of CRTs tends to become unnoticeable for viewing objects head on. Try staring at a CRT running at 60 hz then viewing it with your periphrial vision.

    http://www.100fps.com/how_many_frame...humans_see.htm
    Frankly, I can't view a CRT at less then 85Hz, because I can see the flicker even at 75Hz. 60Hz is just unbearable.

    Simple test: take some benchmark thats running at @120 FPS. Hook it up to both a 60Hz screen and a 120Hz (native; none of this "Truemotion" junk Samsung/Sony push on TV's) screen. Do a blind test on which is smoother.

    The human eye can *distinguish* a heck of a lot more frames then it can pick out individually. In other words: While the eye can't pick out individual frames much beyond 30 or so, it can distinguish the difference in motion between 30, 60, and 120 without issue.

    Comment


    • #47
      Originally posted by gamerk2 View Post
      Translation: The two drivers perform closer when the CPU is doing the majority of the work and the GPU does less.

      Shocking, I know.
      Actually, not really.

      The driver runs on the CPU. The difference in performance is mostly caused by the FLOSS driver not being as optimised as the proprietary one.

      Once the GPU HARDWARE gets the data, it will do it at the same speed. It's just that getting the right data to the hardware at the right moment takes longer with the open driver -- and that one runs on the CPU.

      That's why 300+ fps benchmarks are much slower on open drivers -- the little latencies all add up 100 times, and that makes a big difference. When the majority of the work is done by the GPU, they are much closer in performance, since the driver is doing comparatively little, so the GPU is not starved waiting for it.

      Comment


      • #48
        Originally posted by marek View Post
        My graphics settings are maxed out. Still, I can't reach the low framerate I get with PTS.
        So to take that one step further, what you are implying, is that PTS is doing something that is crippling the results and is therefore NOT a valid benchmark. I wonder if that would be an oversight, of if the results are intentionally sabotaged...?

        I've never taken PTS seriously.

        Comment


        • #49
          Originally posted by Sidicas View Post
          Just in general, I noticed the performance doesn't scale well with OpenGL effects compared to Catalytst. Turning on bloom alone in the new version of openarena is enough to slaughter the framerate by 1/8th on r300g. I don't have the benchmarks with Catalyst and bloom, but I'm pretty sure it doesn't get slaughtered by 1/8th.
          Yea, I noticed something similar. When testing UT2004, the general thing that impacted the performance of r600g was texture size. LOD is important, but way after texture size - the optimal settings that I've found for my cards was pretty much "low" texture size and "high" LOD.

          Originally posted by Kano View Post
          Basically every oss driver is not for "real" gamers.
          Define that... You can be a real gamer while playing 2D games, and all of those are well supported by OSS drivers.

          Originally posted by Veerappan View Post
          If you give it a shot and find something that doesn't work email the mesa-dev list, create a piglit test, or submit a patch.
          Speaking of Piglit tests, are there any OGL conformance tests that work on Catalyst? It would be interesting to compare how both conform to standards.

          Comment


          • #50
            Originally posted by GreatEmerald View Post
            Yea, I noticed something similar. When testing UT2004, the general thing that impacted the performance of r600g was texture size. LOD is important, but way after texture size - the optimal settings that I've found for my cards was pretty much "low" texture size and "high" LOD.
            Does it make sense to use high LOD with low textures? I mean, the textures are already low-res, why store even lower res variants?

            Comment


            • #51
              Originally posted by GreatEmerald View Post
              Define that... You can be a real gamer while playing 2D games, and all of those are well supported by OSS drivers.
              Indeed, although I do play 3D games with R600g and I do tend to consider myself as being an enthusiast gamer. Now, I am an enthusiast Linux gamer, and this does limit the section of titles I can play somewhat, but for the most part I am quite happy of the performance of my Diamond Radeon HD 4670. Over the past year I have played through titles such as Enemy Territory: Quake Wars, Prey, Trine, Trine 2, and Amnesia: The Dark Descent with acceptable performance, and the only game I have not been able to launch ostensibly due to graphics issues is Bastion, and the only game where I have really performance problems is Pshyconauts, but this is due to bugs in the port and not my driver setup.

              And this is on an, admittedly updated, Fedora 16 setup. I am waiting to see if I will get performance improvements when I update to Fedora 18 or not.

              Comment


              • #52
                Originally posted by droidhacker View Post
                So to take that one step further, what you are implying, is that PTS is doing something that is crippling the results and is therefore NOT a valid benchmark. I wonder if that would be an oversight, of if the results are intentionally sabotaged...?

                I've never taken PTS seriously.
                I've finally managed to make Reaction Quake pick up the PTS config and I can now reproduce the low framerate. Sorry for the noise.

                Comment


                • #53
                  Originally posted by bug77 View Post
                  Does it make sense to use high LOD with low textures? I mean, the textures are already low-res, why store even lower res variants?
                  Oh, I wasn't clear, I meant mesh LOD.

                  Comment


                  • #54
                    Originally posted by pingufunkybeat View Post
                    Once the GPU HARDWARE gets the data, it will do it at the same speed. It's just that getting the right data to the hardware at the right moment takes longer with the open driver -- and that one runs on the CPU.
                    Not at all. The CPU driver has a huge impact on what the GPU hardware can do. The driver has to configure a lot of functionality, control clock gating, optimize the shader programs, etc. There are still entire swaths of features on all three major lines of hardware that the FOSS drivers don't enable and the lack of which seriously impacts performance. Examples of such features recently brought up right on this very site are texture tiling, hierarchical Z-buffering, higher PCI transfer speeds, and power state control.

                    You can also easily measure where the bottleneck lies. If your CPU is pegging 100%, the driver (or the app itself) is the bottleneck. If the GPU is pegging 100%, it's the hardware. Any recent tests I've seen have shown that the CPU usage with the FOSS drivers is not all that terrible (though not great) and yet the FPS is extremely worse. Clearly, then, the GPU hardware is the bottleneck; in this case, not because the hardware itself is bad, but because it's running in a race with its hands tied behind its back and one leg chopped off.

                    Comment


                    • #55
                      Does anybody know what the fundamental reason for the speed difference is? The proprietary driver is at least 3X faster on all tests - that is not something that you can achieve only with incremental code tweaking.
                      Last edited by Michael504; 10-31-2012, 09:18 PM.

                      Comment


                      • #56
                        From the perspective of the 3D engine, there are not really that many additional features missing between the open and closed driver. At this point about all that is missing is HiZ. PCIE 2.0 is now enabled by default in recent kernels and now that mesa 9.0 is out, 2D tiling is enabled by default in xf86-video-ati (not sure if it was enabled in these tests or not). What there is is 15+ years of optimizing memory managers, driver heuristics and micro-optimizations in the closed driver. A lot of what helps performance is driver heuristics for things like buffer placement or minimizing extra transfers of data. E.g., forcing some buffers to prefer vram rather than gart increases performance by a factor of 4x:
                        http://lists.freedesktop.org/archive...er/029415.html

                        General non-HW improvements that can make a huge difference:
                        - Better buffer placement heuristics
                        - Shader compiler improvements
                        - Better buffer upload/caching heuristics
                        - Utilize both cached and uncached (WC) gart memory
                        - Better tiling (1D/2D/linear) selection heuristics

                        Comment


                        • #57
                          Originally posted by GreatEmerald View Post
                          Speaking of Piglit tests, are there any OGL conformance tests that work on Catalyst? It would be interesting to compare how both conform to standards.
                          Mozilla had a WebGL conformance test and a lot of the proprietary drivers have historically failed it, such as the last proprietary Catalyst driver available for R300 hardware.

                          The proprietary Catalyst driver for R300 hardware got blacklisted by Mozilla for WebGL while the open source r300g driver isn't blacklisted and works fine. You can force your way past the blacklist when using the proprietary driver, but then the PC just locks hard when it hits some WebGL. I think there is also some 2D acceleration blacklists too because scrolling in firefox is a *LOT* faster on the open source r300g driver than the old proprietary driver on pages with lots of images.

                          Also, newer versions of Compiz and KWIN + latest Catalyst proprietary driver for r300 hardware locks the system hard as well..

                          So pretty much r300g is the only option for R300 hardware users.

                          Keep up the great work, Marek!

                          Comment


                          • #58
                            i installed ubuntu 12.10 yesterday on a first gen i3 notebook with AMd 5470M dGPU.
                            The default unity desktop performance is piss poor. A simple mouse click takes a few seconds to register.

                            Comment


                            • #59
                              Originally posted by Veerappan View Post
                              I think that this has possibly been fixed due to a KWin bug.

                              https://bugs.freedesktop.org/show_bug.cgi?id=55998
                              Fair enough, that's not intel's fault.

                              I accidentally clicked on the adblock button in chromium.
                              Code:
                              [70796.656970] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung

                              Comment


                              • #60
                                Originally posted by elanthis View Post
                                Examples of such features recently brought up right on this very site are texture tiling, hierarchical Z-buffering, higher PCI transfer speeds, and power state control.
                                Like Alex says, most of this is finished for radeon cards. Perhaps not turned off by default on most distros, but it's been written.

                                And yes, optimizing shaders can bring huge gains, but Quake3 doesn't need much of that, and it's still slower.

                                You can also easily measure where the bottleneck lies. If your CPU is pegging 100%, the driver (or the app itself) is the bottleneck. If the GPU is pegging 100%, it's the hardware. Any recent tests I've seen have shown that the CPU usage with the FOSS drivers is not all that terrible (though not great) and yet the FPS is extremely worse. Clearly, then, the GPU hardware is the bottleneck; in this case, not because the hardware itself is bad, but because it's running in a race with its hands tied behind its back and one leg chopped off.
                                I don't know much about GPU drivers to argue with you about this. It will depend on how often the GPU has to wait for the driver to finish doing its stuff, and I can think of scenarios where this induces delays even when CPU is far from 100% load, I get this regularly when running OpenCL software. But like I said, I'm not a driver guy, so I have no clue how it is really done.

                                Comment

                                Working...
                                X