Announcement

Collapse
No announcement yet.

Here's Why Radeon Graphics Are Faster On Linux 3.12

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

  • matyas
    replied
    Just for fun, let's see what people think numbers (through a pool)

    http://phoronix.com/forums/showthrea...nix-benchmarks

    And the purpose is not to make Michael change the governor, neither to convince anyone. It's highly subjective, so it simply would be nice to see the landscape in terms of numbers.

    Leave a comment:


  • bridgman
    replied
    Originally posted by matyas View Post
    I believe switching to performance governor for Phoronix benchmarks would make them more deterministic going forward. What Michael thinks might not be aligned with that thought
    The problem with all these discussions is that the right answer is always "you need both". Marek's point about using the performance governor if you want to isolate the graphics drivers for benchmarking is correct, but Michael's point about testing real-world configurations is also fair.

    In a perfect world you would run something closer to real-world usage tests (eg making sure frame rate stays above 60 hz) on real world configurations and run "350 FPS is better than 300 FPS" benchmarks on configurations which isolate the graphics driver as much as possible (eg setting performance governor).

    One could make a compelling argument that going from 250 to 350 FPS on a high end GPU should not be a priority for the open source driver devs at this point, or at least it should be a lower priority than working on apps which don't run at all or which run sluggishly.

    Leave a comment:


  • matyas
    replied
    Governor...

    The argument that things should be benchmarked using the user defaults is valid. However, then benchmarking with various kernel options (e.g. dpm enabled), using latest dev mesa, and all the things outside a vanilla user default seem to be in direct contradiction with using defaults.

    If you do benchmark, make some effort to have a properly set up environment. You wouldn't benchmark with your laptop running on battery for instance. Switching to performnace governor is an explicity indicator to the operating system that you now _care_ about performance. Which is what benchmarking is about. That is what is intended to exercise the subsystems properly from a benchmarks perspective. I would see a benchmark using defaults more like a average Joe usability index, but not real benchmarking.

    I believe switching to performance governor for Phoronix benchmarks would make them more deterministic going forward. What Michael thinks might not be aligned with that thought

    Leave a comment:


  • schmidtbag
    replied
    I seriously cannot believe the amount of finger-pointing going on here, and sadly its making me lose a lot of respect for people who I otherwise thought were humble and hard-workers.


    It is NOT by any means Michael's fault why the results came out this way. He is not obligated to run under a different governor, just as he isn't obligated to use some obscure distro, make some minor kernel tweak or tweak the drivers for individual tests - the point of these benchmarks is to show what the average person will/should encounter from everyday upgrades. If the governor is known to be problematic then fine, switch out of it, but if the CPU is actually underclocking due to a lack of stress, that really gets me to think the governor is not the problem.

    What Michael is obligated to do is benchmark using the most typical/average software setup, and a hardware setup that has the lowest probability of skewing the results (meaning, his choice of CPU, mobo, RAM, and storage were fine for testing GPUs, because all of those parts are good enough that they SHOULDN'T be a bottleneck). If you want benchmarks for the utmost highest possible results, you're in the wrong place and always have been. Even if this website was strictly benchmarks and nothing else, no single person would ever have the time to set up some of the silly or unrealistic requests here.

    I'm not (yet) blaming the driver developers either, since they were being affected by an outside source.

    HOWEVER

    The CPU Michael used was better than almost anything AMD has to offer. That being said, it is absolutely unacceptable for the drivers to be THAT held back by the CPU, even in its low-freq state. This could mean that APUs are behind in performance simply because the CPU isn't fast enough. I'm not bashing AMD CPUs either - AMD CPUs are fully capable of playing most modern games without being maxed out.

    But like I said, I'm not yet blaming the driver developers. I think tests should be done with catalyst the HD6870 (because that had the greatest performance impact) and see how much of a difference that makes. If, while testing catalyst, the 3.11 ondemand vs 3.12 ondemand has a performance impact less than 5%, that's where I think the open source radeon drivers are the blame.
    Last edited by schmidtbag; 15 October 2013, 11:00 AM.

    Leave a comment:


  • log0
    replied
    Originally posted by bridgman View Post
    Isn't the whole point that the governor issue *is* being addressed in the kernel already and that's where the performance jump came from ?
    I assume it is addressed, but I've only seen i7 benchmarks here with the default configuration, no comparisons to performance setting. Maybe you know more?

    Leave a comment:


  • bridgman
    replied
    Originally posted by log0 View Post
    Well, how about communicating this more clearly?

    Instead of: "Here's Why Radeon Graphics Are Faster On Linux 3.12"

    Something like: "Why is linux still using the ondemand governor as default?" (... even if it is broken and is making performance benchmarks pretty much useless as cpu loads will vary with different gpus)
    Isn't the whole point that the governor issue *is* being addressed in the kernel already and that's where the performance jump came from ?

    Leave a comment:


  • s_j_newbury
    replied
    Originally posted by jonnor View Post
    A useful benchmark would be to see how often/seldom the system failed to reach the deadline for a frame at 60 fps.
    I had that in my mind too.

    Leave a comment:


  • jonnor
    replied
    Originally posted by s_j_newbury View Post
    I'm not sure I really buy the default argument. The default it to have FPS rate limited to the display refresh rate, and rightly so. If there's a call to measure performance with games far below the capabilities of the gfx hw such that they are cpu bound, wouldn't a more meaningful benchmark be overall power utilisation? What use case is the in running at multiple 100s fps more than you can see?
    A useful benchmark would be to see how often/seldom the system failed to reach the deadline for a frame at 60 fps.

    There are some games where running at a framerate higher than 60fps can give advantages, but that is due to internal quirks of the engine, and not an important usecase for ordinary gamers.

    Leave a comment:


  • log0
    replied
    Originally posted by Michael View Post
    Then it should be fixed or the default setting changed within the kernel.
    Well, how about communicating this more clearly?

    Instead of: "Here's Why Radeon Graphics Are Faster On Linux 3.12"

    Something like: "Why is linux still using the ondemand governor as default?" (... even if it is broken and is making performance benchmarks pretty much useless as cpu loads will vary with different gpus)

    Leave a comment:


  • menfin87
    replied
    Originally posted by marek View Post
    You can use that, but don't bother me with the benchmark results, because as a driver developer I am not interested. It's not only the graphics driver being benchmarked here, it's also cpufreq. And who knows what cpufreq will do next time.
    You are not interested as a driver developer ? So if a user complains about performance problems, do you just tell him "I don't see it so there is no problem" or do you maybe try to understand what is going on ? You should be glad that someone is testing an average user configuration to spot problems that would be blamed on you.

    Leave a comment:

Working...
X