# GameMode: a Linux daemon that lets games request temporary system optimisations

> GameMode is a daemon and library pair from Feral Interactive that applies CPU governor, I/O priority, niceness, scheduler and GPU settings for the duration of a game. This article covers what it changes, how the client/daemon split works, how to build 1.8.2, and where it stops being the right tool.

**FeralInteractive/gamemode** — Optimise Linux system performance on demand

- Repository: https://github.com/FeralInteractive/gamemode
- Stars: 6,024 · Forks: 215
- Language: C
- License: BSD-3-Clause
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/feralinteractive-gamemode

## The problem GameMode was written to solve

Linux CPU frequency governors are general-purpose. The README is explicit about the origin of the project: GameMode started as a stop-gap for problems with the Intel and AMD powersave or ondemand governors, which react to load on a timescale that does not match a game's frame pacing. A game that alternates between a busy render thread and idle waits can leave cores parked at a low frequency at exactly the moment a frame needs to be finished. GameMode's answer is to let the game itself ask for a different set of system settings, and to have those settings reverted when the game exits.

The audience is narrower than "Linux gamers". It is people running a desktop distribution with systemd, who want a temporary, reversible change to governor, I/O priority, process niceness, kernel scheduler class, screensaver state, GPU performance mode or core pinning, scoped to one process tree rather than applied globally at boot. It is also useful to anyone maintaining a launcher or a game that wants to integrate the request directly instead of asking users to edit launch options.

## How the daemon, the library and the loaders fit together

The README describes a deliberate split: a host daemon and library (gamemoded and libgamemode), and client loaders (libgamemodeauto and gamemode_client.h). The stated reason is safety for the client side. A game or launcher can call into the client API without knowing whether the daemon is installed or running, because the client side is designed to fail harmlessly rather than to require a live service.

The daemon currently uses systemd for message exchange, which the README frames as an implementation detail rather than a contract: the same clients could be served by different internals. That matters if you are evaluating GameMode for an embedded or non-systemd target, because the client abstraction is reusable but the shipped daemon is not portable to a system without the user bus. The configuration is read by the daemon from four locations in descending priority: $PWD, then $XDG_CONFIG_HOME or $HOME/.config/, then /etc/, then /usr/share/gamemode/. The first two are labelled unsafe in the README, and the reason is concrete: [gpu] settings take no effect in those files. A per-directory config can therefore look like it is being applied while its GPU section is silently ignored.

## Building 1.8.2 and confirming the daemon runs

The README documents distro packages for Ubuntu, Debian, Solus, Arch, Gentoo, Fedora, OpenSUSE and Mageia, so on those systems the package manager is the shortest path. The source route below is the one the README gives, pinned to the 1.8.2 release. It assumes a C toolchain, meson, ninja and systemd development headers are already present; the README lists per-distribution dependency commands for Ubuntu, Debian, Arch, RHEL 10, Fedora, OpenSUSE, Gentoo and Nix.

Clone the repository and check out the release tag before building. Omitting the checkout builds master instead, which the README presents as the alternative rather than the default.

```bash
git clone https://github.com/FeralInteractive/gamemode.git
cd gamemode
git checkout 1.8.2 # omit to build the master branch
./bootstrap.sh
```

After installation, the README gives a single self-test command. If the daemon and its dependencies are wired up correctly, this returns without error.

```bash
gamemoded -t
```

To exercise it on a game that does not integrate GameMode itself, prefix the launch. The second form is the Steam launch option string, with %command% left for Steam to expand.

```bash
gamemoderun ./game
gamemoderun %command%
```

For versions before 1.3 the README gives the LD_PRELOAD string instead of gamemoderun, and notes that the backslash in \$LIB is required. Uninstalling is two commands: stop the user service, then run the ninja uninstall target against the build directory.

```bash
systemctl --user stop gamemoded.service
ninja uninstall -C builddir
```

## Where GameMode is the wrong tool

The hybrid GPU case is the clearest limitation, and the README states it plainly: commands like optirun cannot be integrated automatically, because the GameMode request is made once the game has already started. The workaround is to set GAMEMODERUNEXEC to the wrapper command, for example GAMEMODERUNEXEC=optirun or GAMEMODERUNEXEC="env DRI_PRIME=1", and the README notes this variable can be set globally in /etc/environment so the same prefix is not duplicated. It also warns that GameMode will not be injected into the wrapper, so the wrapper process itself does not receive the optimisation request.

The second limitation is the configuration priority order. Because $PWD and $XDG_CONFIG_HOME are read ahead of /etc/, a stray gamemode.ini in the directory you launch from can override system-wide settings, and its [gpu] section will do nothing at all. That is a debugging trap rather than a feature, and the README does not offer a command to print the merged result.

The third is scope. GameMode changes scheduling and frequency policy for a process tree. It is not a frame limiter, not a compositor bypass, and not a substitute for fixing a driver or a misconfigured Proton prefix. If your stutter comes from shader compilation or from a background process outside the game's tree, none of the optimisations listed in the README will touch it.

## GameMode against a hand-written wrapper script

The obvious alternative is a shell script that writes to /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor before launching the game and restores the previous value afterwards. The difference in approach is lifecycle and failure handling. A script has no way to know the game has exited if the process forks or if the launcher spawns a child and returns, and it has no recovery path if the machine reboots mid-session with the governor still set to performance. GameMode puts that state in a daemon that owns the request and reverts it, and the client side is explicitly designed to be safe when the daemon is absent.

A second alternative is a distribution or desktop-level performance mode that applies a profile for the whole session. That is simpler and does not require per-game launch options. The trade-off is granularity: a session-wide profile stays applied when you alt-tab to a browser or leave the machine idle, while GameMode's whole premise is that the optimisation is temporary and tied to the game's lifetime. If you only ever run one game on a dedicated machine, the session-wide approach is less machinery for the same result.

## Maintenance, licensing and the cost of upgrading

The repository is not archived, and the last push was on 2026-06-15. The most recent release listed is 1.8.2 from 2024-08-19, preceded by 1.8.1 on 2023-12-12 and 1.8 on 2023-12-06. That gap between the last release and the last push is worth noting when you plan an upgrade: master carries work that is not in a tagged release, which is why the README offers the checkout-tag step as a choice rather than a requirement.

Upgrade cost is low but not zero. The configuration format is an ini file with an example at example/gamemode.ini, and the README points at that file for explanations of the variables rather than documenting them inline. If you maintain a local gamemode.ini in /etc/, diffing it against the example after an upgrade is the practical way to catch renamed or added keys. Uninstalling is documented as stopping gamemoded.service and running ninja uninstall -C builddir, so a source install can be reversed cleanly.

Licensing is BSD 3-Clause (Revised), with the bundled inih library under the New BSD license. That is a permissive license, which generally means redistribution in a product is possible provided the copyright notice and disclaimer are retained, but the practical obligations depend on how you ship it. Nothing here is legal advice; read LICENSE.txt in the repository before bundling the daemon or the client library into a distributed build.

## Conclusion

Adopt GameMode if you run a desktop Linux distribution with systemd and want per-game optimisation without editing sysfs by hand; it is packaged for Ubuntu, Debian, Solus, Arch, Gentoo, Fedora, OpenSUSE and Mageia, and the 1.8.2 release is the version the README tells you to check out. Do not adopt it on a system without a user D-Bus session, and do not expect it to wrap a hybrid GPU launcher automatically, because the README states the request is made after the game has started and that GameMode will not be injected into a GAMEMODERUNEXEC wrapper. Before relying on it, run gamemoded -t on the installed build and inspect the merged configuration with the priority order in mind, since a gamemode.ini in $PWD or $XDG_CONFIG_HOME silently drops every [gpu] setting.

## FAQ

### Is GameMode one word or two?

The project writes it as one word, GameMode, in the README heading and throughout the documentation. The executable names follow the same convention: gamemoded, gamemoderun and gamemode.ini.

### What does GameMode mean for Linux users?

In this project it is a daemon and library combination that lets a game request a set of temporary optimisations to the host OS or the game process. The README lists CPU governor, I/O priority, process niceness, kernel scheduler, screensaver inhibiting, GPU performance mode, core pinning and custom scripts.

### How do you turn on GameMode for a game?

Games and launchers that integrate support activate it automatically when the game runs. For everything else you launch through gamemoderun, or put gamemoderun %command% in the Steam launch options.

### How do you install GameMode on Linux?

Packages exist for Ubuntu, Debian, Solus, Arch, Gentoo, Fedora, OpenSUSE, Mageia and possibly more. From source, the README gives git clone, git checkout 1.8.2, then ./bootstrap.sh, with gamemoded -t to verify the install.

### How do you install GameMode on Arch Linux?

The README lists pacman -S meson systemd git dbus libinih gcc pkgconf for the build dependencies, and a gamemode package is listed among the available distro packages.

## Sources

- [FeralInteractive/gamemode on GitHub](https://github.com/FeralInteractive/gamemode)
- [Issues](https://github.com/FeralInteractive/gamemode/issues)
- [License: BSD-3-Clause](https://github.com/FeralInteractive/gamemode/blob/master/LICENSE)
- [README](https://github.com/FeralInteractive/gamemode/blob/master/README.md)
- [Releases](https://github.com/FeralInteractive/gamemode/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/feralinteractive-gamemode