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

  • #71
    Originally posted by marek View Post
    I second this. People who are serious about performance should always set the "performance" governor. I even removed the file /etc/init.d/ondemand, so that I always get "performance" on boot. The init.d script sets "ondemand" after 1 minute or so after boot, i.e. when you least expect it, which messes up benchmark results. If you play games with the "ondemand" governor and complain about performance to us, you're wasting our time.

    While it's a good thing that we know what the problem was, it's also a big fail for Phoronix. "ondemand" should never ever be used for benchmarking.
    No. I am only interested in seeing benchmarks on vanilla systems. If performance is hidden behind non-default configurations then it is irrelevant and something that should be fixed and until it is fixed please don't waste my time.

    Comment


    • #72
      Originally posted by Petteri View Post
      No way. Games, drivers or operating system in general should handle this kind of tweaking without bothering users. CPU and GPU frequency scaling should "just work".

      I'm not going to tell my little sister that she has to change the cpufreq governor to play games.
      Most people don't game, but are becoming more and more aware of power consumption and/or battery life, thus the profiles are written to favor low power usage over performance because most PC gamers will put 2 and 2 together and change the settings for performance.

      Comment


      • #73
        Originally posted by zoomblab View Post
        No. I am only interested in seeing benchmarks on vanilla systems. If performance is hidden behind non-default configurations then it is irrelevant and something that should be fixed and until it is fixed please don't waste my time.
        I am only interested in seeing benchmarks on properly configured systems.

        Comment


        • #74
          Originally posted by zoomblab View Post
          No. I am only interested in seeing benchmarks on vanilla systems. If performance is hidden behind non-default configurations then it is irrelevant and something that should be fixed and until it is fixed please don't waste my time.
          So you wouldn't test binary drivers at all?

          They are not installed out-of-the-box and are considered a non-default configuration?

          To me, it seems strange to test free drivers on distributions which force ancient codepaths, when enabling newer, more optimised code is trivial.

          Like I said, a combination of vanilla "out-of-the-box" and tweaked benchmarks would be nice.

          Comment


          • #75
            Originally posted by schmidtbag View Post
            My bad - I should have been more precise, I forgot this is the internet and everything stated must be 100% accurate. While governors such as "ondemand" or "performance" apply to either AMD or Intel, there are still drivers (if that's even the right word) that affects how these governors work between CPUs. In other words, the governors ARE specific to, at the very least, the CPU family. It could ven be specific to each generation or each model, but I wouldn't know for sure. So for example if you have an AMD system that can clock from 1.2GHz to 3.5Ghz, it doesn't mean an intel CPU can operate the same way and remain stable. If the governors were indifferent to the CPU, problems like this would have been found a long time ago.

            The point of me saying this is there's a possibility that the ondemand governor for AMD might have done a better job at determining what frequency to operate at.
            Not 100% accurate, just not jumping the gun If Michael or another forum poster would be so kind as to put out AMD CPU based benchmarks for comparison, thatd be wonderful. We could see if this was related to the generic or specific parts of the governor. But jumping the gun and pointing the finger at Intel and that it only affects them seems a bit of a disservice until we have data to back that up. It very well could be ONLY occuring on Intel CPU's but I feel like that would be unlikely since the change wasn't in the Intel CPU freq module, it was in the generic cpufreq governors. But again, we need to wait and see
            All opinions are my own not those of my employer if you know who they are.

            Comment


            • #76
              Originally posted by Ericg View Post
              Schmidt I need to throw your entire post out the window.... Like not "Prove it wrong," I need to literally pick up the bits, put them in a bucket, and throw the bucket out of a closed window.

              Its not an "intel governor" its the ondemand governor in the subsystem that handles ALL CPU scaling. This change effects every CPU that uses the ondemand governor-- interestingly enough (in perspective of your post) no modern intel CPU actually uses the ondemand governor UNLESS you're on *buntu. Everyone ELSE moved over to the customized Intel P-State driver like 2 or 3 kernel releases ago (i've asked Michael to compare the P-State driver to ondemand with this change). But Ubuntu, for their own reasons, has not moved over yet.

              AMD CPU's are likely affected by this as well, perhaps even just as much as the benchmarked Intel CPU. This whole thing is in regards to a kernel subsystem, not specific branded hardware.
              I confirm this - only CPUs using cpufreq driver scaling government method are affected (all of them).
              Intel with PState is not affected, its far more precise driver. Cpufreq correlates to PState, as HAL to udev.
              This is software error, lets just everyone test it - how far his performance with fixed ondemand compares to buggy, yet tuned ondemand and performance.
              Ideally everyone should move to PState, but its not a instant-mash.

              Comment


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

                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.
                That would be a more useful metric. The presentation of the FPS metric as a simple bar chart here is the thing that is misleading, since it implies that there is some difference that the user cares about above 60fps. I quite like the way that notebookcheck reviews show the same data as a grid of game vs graphic settings with fps and a simple colour for each cell to indicate acceptable/unacceptable - it is much easier at a glance to see which titles, on which settings, are playable, and which aren't.

                Comment


                • #78
                  Originally posted by chrisb View Post
                  That would be a more useful metric. The presentation of the FPS metric as a simple bar chart here is the thing that is misleading, since it implies that there is some difference that the user cares about above 60fps. I quite like the way that notebookcheck reviews show the same data as a grid of game vs graphic settings with fps and a simple colour for each cell to indicate acceptable/unacceptable - it is much easier at a glance to see which titles, on which settings, are playable, and which aren't.
                  Patches to PTS are always welcome and it's trivial to make new tables that work with any relevant test profile, etc.
                  Michael Larabel
                  https://www.michaellarabel.com/

                  Comment


                  • #79
                    The integrated gpus need more assistance from the Cpu so they don't get throttled down. Intel and AMD should be writing the code for these governors so they achieve the best balance and hence look good to their customers.

                    Comment


                    • #80
                      Originally posted by pingufunkybeat View Post
                      So you wouldn't test binary drivers at all?

                      They are not installed out-of-the-box and are considered a non-default configuration?
                      There is a huge difference. People are used to install new drivers whereas they are not used to tune scheduler parameters.

                      Comment

                      Working...
                      X