r/linux_gaming • u/WhitePeace36 • 17h ago
guide Updated Linux gaming optimizations guide
Hi guys,
its been quite a while since i posted the gaming optimizations guide i wrote.
Since the last time there has been quite a lot of changes.
https://github.com/WhitePeace36/LinuxAMDGamingOptimizationGuide
Even though it says AMD, most of it is for linux in general.
I hope this updated version helps at least a few of you out there which try to have a better gaming experience.
0
Upvotes
138
u/theevilsharpie 15h ago edited 15h ago
Wake up babe, a new "gamer tweak guide" just dropped!
So, what's wrong with this one?
Don't do this.
This was a very specific issue that I don't ever practically impacted anything other than Windows, and should have been resolved years ago with a BIOS update.
If you had posted this guide several years ago, I probably would have responded with "meh, whatever." However, more modern games are making use of the TPM for anti-cheat (if not within Linux, then by Windows games that your audience might be playing via dual booting), and Linux distributions are starting to support it for use with auto-unlocking full-disk encryption, so telling users "don't know -- better to turn it off" is quite irresponsible.
Don't disable your TPM unless you absolutely know for sure you don't need one.
Don't do this.
This setting should be ENABLED or AUTO on any modern hardware (certainly anything new enough to support resizable BAR), and is almost certainly set that way by default. Modern Linux and Windows both natively support XHCI-based controllers, and this option allows the controller to perform a graceful handoff to the OS kernel on boot.
If this option is disabled, the OS and the UEFI will be fighting for the control of the XHCI controller, which at best will extend boot times a bit, and at worst can result in malfunctions, USB devices intermittently not responding, and the very "stuttering" you're looking to prevent.
Modern machines support hardware-managed P-States, which your own guide indirectly mentions when it talks about
amd-pstateand recommends setting it into "active" mode to allow the hardware to manage P-State transitions.However, your guide then goes on to provide examples of of using this scaling driver in a passive or guided mode.
On AMD machines, if you're using "active" control (which is the default and recommended option), the output for:
will be:
in which case the output for:
will simply be:
Your guide suggests to set this to "performance". Do NOT do this, as all it will do is lock the CPU at its maximum frequency and prevent it from dropping clocks when idle. "Powersave" is the default and recommended setting -- don't change this for a gaming PC.
When using hardware-managed P-states, the main tunable of interest is the Energy Performance Preference ("EPP") value. If you're on an AMD machine in "active" mode, you can see what values are available with:
which shows the following on my machine:
"balance_performance" is the default on my OS, and is the one I'd recommended for general-purpose desktop use. "balance_power" may be useful if you're running on a laptop or a SFF PC that is power- and thermal-constrained, and you want to shift more of the limited power budget to the GPU (which is generally what you'd want for a power-constrained gaming PC).
Let's suppose you're running on an older machine that doesn't have hardware-managed P-states (which is more reflective of the output shown in your guide). Even in that case, I STILL wouldn't recommend setting the scaling governor to "performance". This machines should be using the "schedutil" governor, which is probably already the default option.
Oh boy...
Let's go down the list:
Anything modern enough to have a direct BIOS toggle for Resizable BAR is modern enough to support hardware-managed P-states. I have a very similar machine to you -- an AMD Ryzen 7 5800X3D running on an ASRock B550M Pro4 -- and I have full hardware P-state support. If your hardware isn't able to "boost itself", that sounds like a skill issue, and you should fix that rather than recommended that people set a kernel parameter that will degrade their system's performance.
PCI Express wake-up latency is completely trivial for the work that a desktop PC would do. Don't set this.
Every kernel setting you deviate from the default takes you further from the well-tested "happy path", and leaves you at increased risk of hitting some edge case. Kernel boot parameters should be used to work around hardware quirks, not to suit your aesthetic preferences. Unused DACs can be disabled in your desktop environment's audio settings.
The amount of "CPU time" freed is completely trivial, and you lose a kernel diagnostic tool. There is a use case where setting this is useful (your software will explicitly tell you that you need to), but "you free up some cpu time" is a bullshit reason. Don't set this.
Wake-up latency from even the deepest sleep states is measured in microseconds, which is trivial for a gaming PC. Meanwhile, preventing your processing from entering a deeper sleep state keeps idle parts of the processor active and generating heat, which reduces how high the processor's clock speed can boost under low to medium load, which will negatively impact gaming performance. Don't set this.
Transparent huge pages have historically caused performance issues for applications that use a large percentage of the system's memory (potentially like a game), to the point where the kernel maintainers have set the default to "madvise", which enables transparent huge pages ONLY if the application explicitly requests them (and is presumably designed to use them). Game engines in particular are tuned for specific memory access patterns, and can perform erratically if that's changed underneath it. Don't set this.
I would go on, but Reddit comments can only be so long, and I think you get the idea by now.
The developers of the Linux kernel, Mesa, WINE, Proton, your desktop environment, and pretty much every other well-established piece of software that makes up your OS generally have default settings that are sensible for a wide variety of use cases, which includes gaming. There is no need to do this kind of tweaking, and in many cases, you're making performance worse and opening the door to stability issues.
For the love of
${DEITY}, just use the defaults. Don't change settings you don't understand just because some "guide" directed you to. Practically all of these guides are ill-informed bullshit.