Announcement

Collapse
No announcement yet.

P-State/CPUFreq CPU Frequency Scaling Tests For Radeon/NVIDIA Gaming With Linux 4.16

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

  • P-State/CPUFreq CPU Frequency Scaling Tests For Radeon/NVIDIA Gaming With Linux 4.16

    Phoronix: P-State/CPUFreq CPU Frequency Scaling Tests For Radeon/NVIDIA Gaming With Linux 4.16

    With last week's release of Feral GameMode as a system tool to optimize Linux gaming performance, which at this point just toggles the CPU frequency scaling driver's governor to the "performance" mode, reignited the CPU governor debate, here are some fresh Linux gaming benchmarks. Tests were done with both the CPUFreq and P-State scaling drivers on Linux 4.16 while testing the various governor options and using both AMD Radeon and NVIDIA GeForce graphics cards.

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    so
    1) schedutil > ondemand
    2) performance is sometimes the best option
    3) schedutil seems the sanest default
    edit:
    didnt mention p-state as it is intel specific and doesnt apply to ryzen
    pstate now is in good shape for intel cpus
    Last edited by davidbepo; 17 April 2018, 10:30 AM.

    Comment


    • #3
      What's not being taken into account here, is how powersave to performance can have a bigger impact on a lower clocked processor. This a key thing being missed out by this article and by many people throwing around wild claims.

      For some people it might make very little different, for others it can make a huge difference. And since powersave is the default for most (unless you have an older Intel CPU), you are probably likely to want to use it.

      Comment


      • #4
        Seems schedutil is the best all-around option. Fairly good energy savings, without really sacrificing performance.

        Comment


        • #5
          Please try also older good supported cards Kepler gk107.

          Comment


          • #6
            I know it wasn't the point of this article, but am I the only one still amazed by how well the open source amd drivers hold up?

            Comment


            • #7
              Originally posted by fuzz View Post
              I know it wasn't the point of this article, but am I the only one still amazed by how well the open source amd drivers hold up?
              They are doing well AMD. Now it's mostly their Linux Vulkan performance that has to catch up to Nvidia.

              We shouldn't be amazed though, this should be the expected performance level. Just cause it's open source we shouldn't expect or settle for slower performance.

              Comment


              • #8
                Originally posted by humbug View Post
                They are doing well AMD. Now it's mostly their Linux Vulkan performance that has to catch up to Nvidia.

                We shouldn't be amazed though, this should be the expected performance level. Just cause it's open source we shouldn't expect or settle for slower performance.
                True, it's just been a long time coming!

                Comment


                • #9
                  Originally posted by humbug View Post
                  They are doing well AMD. Now it's mostly their Linux Vulkan performance that has to catch up to Nvidia.

                  We shouldn't be amazed though, this should be the expected performance level. Just cause it's open source we shouldn't expect or settle for slower performance.
                  Because it's open source, no, but we have to take in consideration the budget allocated for driver development by NVidia and AMD, especially open source. I would say the current performance is nothing short of a miracle.

                  Comment


                  • #10
                    Performance is only one side of the equation; Latency is at least as important. (And argueably even more so with Games!)
                    When the governor has to make a choice which frequency to select based on previous input data, the game will likely stutter. (This means CPUfreq 'ondemand' & 'schedutil', but also Intel P-State driver!)
                    On the other hand, when no time is wasted on decision-making logic (like with CPUfreq 'performance'), more CPU time is available for what really counts: computing the game!
                    Probably this is also the reason why Feral chose the performance governor. (Although this isn't enough for Intel P-State; Intel-specific "Performance-Bias" seems to be ignored by most...)

                    Comment

                    Working...
                    X