Based on the change originally made by @joelsgp in PR #417, but there
were issues with the original commit message:
- Used an emoji which may cause rendering issues in CLI tools
- Mentioned Bitcoin mining which is inaccurate and contained
unnecessary censorship
This commit adds two new configuration options: igpu_desiredgov and
igpu_power_threshold which allow for a different CPU governor when the
Intel integrated GPU is under load. This currently only applies to
Intel integrated GPUs and not AMD APUs because it uses the Intel RAPL
infrastructure for getting power information. If on a platform that
without an Intel integrated GPU or where the kernel does not support
RAPL, the new options will be ignored and it will fall back to the old
behavior.
One of the core principals of gamemoded to date has been that, when
playing a game, we want to use the "performance" CPU governor to
increase CPU performance and prevent CPU-limiting. However, when the
integrated GPU is under load, this can be counter-productive because the
CPU and GPU share a thermal and power budget. By throwing the CPU
governor to "performance" game mode currently makes the CPU frequency
management far too aggressive and it burns more power than needed. With
a discrete GPU, this is fine because the worst that happens is a bit
more fan noise. With an integrated GPU, however, the additional power
being burned by the CPU is power not available to the GPU and this can
cause the GPU to clock down and lead to significantly worse performance.
By using the "powersave" governor instead of the "performance" governor
while the integrated GPU is under load, we can save power on the CPU
side which lets the GPU clock up higher. On my Razer Blade Stealth 13
with an i7-1065G7, this improves the performance of "Shadow of the Tomb
Raider" by around 25-30% according to its internal benchmark mode.
SCHED_ISO is not supported by upstream kernels, so don't try to use this by
default since for most users it will result in an error log that trying to
set the scheduling policy fails.
Without extra system configuration, we will also not have permission to renice
processes by default, so out of the box doing this will fail as well.
Users that wish to use these features can enable them from the config once
they have configured their system appropriately.
This also fixes the instances in testing where we don't have the nv overclock in use, but we do have the mode set
Solves issues explaining the what the perf_level actually meant, and future proofs for any PR that wants to set individual perf levels
This covers the MVP for now, and simply allows pinning the power level to "high"
Full overclocking set up is somewhat more complicated, and it'll be better to implement that at the same time as the same for Nvidia, where we're currently only really setting the top end power level
This allows direct control over who can make requests on behalf of other processes
require_supervisor can also be used to allow a supervisor to take direct control of gamemode on the system (perhaps a GUI, or game launcher)
This commit adds configuration support for the renice value and amends
documentation and examples. This commit by itself does nothing, the
following commit is needed to actually apply the new settings.
Signed-off-by: Kai Krakow <kai@kaishome.de>
This adds support for a new configuration option "softrealtime" to be
read from the general section. This commit alone does nothing, the
following commit adds actually making use of the value.
Signed-off-by: Kai Krakow <kai@kaishome.de>
Checks for a gamemode.ini in /usr/share/gamemode/ (or in the cwd for debugging)
Currently allows for blacklisting and whitelisting clients based on rudimentary needle-haystack executable name checks
See the example/gamemode.ini file for expected syntax
Using the BSD licensed inih library (with additional meson.build file)
