Announcement

Collapse
No announcement yet.

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

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

  • #41
    a graph and a whinge....maybe ubuntu is broken ?

    Comment


    • #42
      Originally posted by pingufunkybeat View Post
      You are right, and I should have written "FLOSS radeon drivers".

      What is missing is not really a part of OpenGL, but they are still missing: dynamic power management, UVD, OpenCL. Some belong in the kernel, some in Mesa, etc.

      Since the GPU drivers are spread between different projects now, it's harder nowadays to be specific
      Radeon HD2000-4000 never really supported OpenCL in the first place (at least not fully, and not for what I needed it to do). For Evergreen and newer, we've got OpenCL support that's being worked on in the Mesa master repository, and the piglit OpenCL test support has been merged to piglit master. It's not necessarily finished yet, but it's getting better. 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. I don't know if they're to the point of wanting bug reports, but piglit tests are even better in my opinion.

      Comment


      • #43
        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 peripheral vision.

        http://www.100fps.com/how_many_frame...humans_see.htm
        Not only that, but most users want a video card that can handle more than 60 FPS average for an additional reason: If your average is 60, your minimum will be lower. Ideally, you want a minimum frame rate that can keep up with your screen's refresh rate, which is 60hz for many LCDs I've seen.

        Comment


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

          The less OpenGL effects you stack up, the closer the open source driver gets to Catalyst.

          I noticed PTS likes to turn on every graphics option, including non-default graphics options. So pay attention to the graphics option as even a single option in there can sometimes absolutely slaughter the framerate of the open source driver compared to Catalyst.

          It's not that the open source driver is a lot slower, rather it's just a tiny bit slower at some effect and then that effect is getting multiplied by 100x per second which adds up quickly. Turning off the graphics option and the framerate increases multiple fold. For some games, it's just a matter of finding which switch is killing your framerate with the open source driver, and it's almost always an optional graphics option.
          Translation: The two drivers perform closer when the CPU is doing the majority of the work and the GPU does less.

          Shocking, I know.

          Comment


          • #45
            Originally posted by Veerappan View Post
            Radeon HD2000-4000 never really supported OpenCL in the first place (at least not fully, and not for what I needed it to do). For Evergreen and newer, we've got OpenCL support that's being worked on in the Mesa master repository, and the piglit OpenCL test support has been merged to piglit master. It's not necessarily finished yet, but it's getting better. 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. I don't know if they're to the point of wanting bug reports, but piglit tests are even better in my opinion.
            Since I work with OpenCL a lot these days (this means binary blob at work, unfortunately), I'd love to test it, but I don't have fully OpenCL-capable Radeon card at the moment. Perhaps soon.

            Comment


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

                      Working...
                      X