Page 5 of 7 FirstFirst ... 34567 LastLast
Results 41 to 50 of 68

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

  1. #41
    Join Date
    Jul 2008
    Posts
    356

    Default

    a graph and a whinge....maybe ubuntu is broken ?

  2. #42
    Join Date
    Nov 2008
    Location
    Madison, WI, USA
    Posts
    860

    Default

    Quote 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.

  3. #43
    Join Date
    Nov 2008
    Location
    Madison, WI, USA
    Posts
    860

    Default

    Quote 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.

  4. #44
    Join Date
    Jun 2012
    Posts
    331

    Default

    Quote 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.

  5. #45
    Join Date
    Jun 2009
    Posts
    2,926

    Default

    Quote 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.

  6. #46
    Join Date
    Jun 2012
    Posts
    331

    Default

    Quote 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.

  7. #47
    Join Date
    Jun 2009
    Posts
    2,926

    Default

    Quote 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.

  8. #48
    Join Date
    Oct 2009
    Posts
    2,052

    Default

    Quote 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.

  9. #49
    Join Date
    Sep 2008
    Location
    Vilnius, Lithuania
    Posts
    2,508

    Default

    Quote 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.

    Quote 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.

    Quote 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.

  10. #50
    Join Date
    Dec 2009
    Posts
    492

    Default

    Quote 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?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •