The platform profile lives in /sys/firmware/acpi/platform_profile. The
desiredprof and defaultprof options correspond to the values for the
platform profile set when gamescope begins and ends, respectively.
HACK: The platform profile may restrict what values the governor can
take, so we choose to set the governor before the platform profile in
order to store the correct default governor, and restore the platform
profile before the governor. This is done to maximize correctness after
restoration, but it can cause issues if the previous platform profile
restricts the governor.
TODO: Save all the state we care about before any of it is changed. In
thsi case, we should set (and restore) the platform profile before the
governor.
Attribute the contributions made by members of the community, but avoid
unweildy and inconsistent copyright notices at the top of each file.
Existing contributor copyright notices have been left as-is.
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 makes it more clear that libgamemode and libgamemodeauto are indeed libraries. Also, the misleading name `libgamemode_dep` has been renamed to `gamemode_dep`, which now also includes the dependency on libdl. The misleading `libgamemode_includes` variable name has also been changed.
Signed-off-by: Stephan Lachnit <stephanlachnit@protonmail.com>
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)
