Flyt is a daemon for Linux that applies optimisations to the system and individual process.
  • Zig 95.7%
  • C 4.1%
  • Roff 0.2%
Find a file
Marc Di Luzio ace04e1823
All checks were successful
/ build and test (push) Successful in 40s
WIP ListGames
2026-09-04 01:06:13 +01:00
.forgejo/workflows WIP 2026-09-01 20:00:03 +01:00
data More TODO cleanup, refactor of the CPU module to handle errors and use an enum for governors 2026-09-01 22:44:09 +01:00
src WIP ListGames 2026-09-04 01:06:13 +01:00
.gitignore Initial port to Zig 2026-07-06 00:14:18 +01:00
AGENTS.md Add the agents file from SDL2 2026-08-31 00:53:31 +01:00
build.zig Final cleanup and add comments 2026-09-03 20:45:06 +01:00
build.zig.zon Increment patch version 2026-09-03 00:21:12 +01:00
CLAUDE.md Add the agents file from SDL2 2026-08-31 00:53:31 +01:00
LICENSE.txt Initial port to Zig 2026-07-06 00:14:18 +01:00
README.md Final cleanup and add comments 2026-09-03 20:45:06 +01:00

🏄 Flyt

Flyt is a daemon for Linux that automatically applies system and process optimisations.

Flyt can apply the following optimisations:

  • Setting the CPU governor
  • Renicing client tasks
  • Screensaver inhibiting
  • Setting I/O priority

Flyt also has support for:

  • Automatic client detection
  • Custom scripts on client add/remove
  • Per-client configuration from environment

⚠️WARNING ⚠️

Flyt is a Work In Progress and has not been battle-tested, so here be dragons.

Q&A

Why use Flyt?

It's common see people say "you don't need GameMode" and they're not wrong. That mantra applies to Flyt too. Most Linux distributions worth their salt already run games at pretty much their best. Flyt is only a final glaze on an already excellently iced cake.

These performance daemons simply take it one step further and work to ensure games and similar tools get the priority they deserve while ensuring other baseline gaming-centric behaviour is enforced (e.g. swapping to performance mode and disabling the screensaver). They're also a baseline for experimenting with and customising game performance in the edge cases where specific intervention is required.

Why use Flyt rather than GameMode?

While Flyt works towards 1.0 it is still missing some GameMode features (see below), but it already improves on GameMode in a number of ways:

  • Automatic client detection
  • A significantly improved config system
    • Enabling and disabling of individual modules at runtime (including dbus)
    • Client and system optimisations can be set in the client environment
    • Config env values can be single values, config structs or even file paths
    • Config file reload detection is instant and only on a true file change
    • Allow and denylists use wildcards
  • Scripts module is expanded to support client add/remove and heartbeat events
  • Simplified API surface
    • Unified methods infer requester (e.g. for supervisor requests)
    • Removed duplicate API endpoints (restart/reload)

Meanwhile, Flyt can listen for the same DBus messages as GameMode, allowing it to act as a drop-in replacement while providing a more robust feature-set and extended user customisation.

Why not make these changes to GameMode?

This project started as some fun just for myself, but while on that path I stumbled into a number of actual beneficial user-facing improvements that I cared to share. Many of these features could be ported to Feral's C codebase, but I don't (currently) have the motivation to do so.

What does "Flyt" mean?

Flyt is a Norwegian word that roughly translates to "flow". It's often used in the context of smooth performance in videogames.

AI?

This is handmade software, not written by AI.

Development

Flyt improves on a number of developer and reliability experiences:

  • Extensive unit and integration test coverage
  • Expanded error and failure state handling
    • This is expecially the case in adverse situations like OOMs
    • Reports errors as dbus errors, giving more helpful contextual information
  • Modularised allowing for simpler implementation of new cleanly isolated features
  • Uses pidfds by default to avoid potential issues with PID re-use
  • Faster Dbus message response times, harder work is executed async by an event queue

Why Zig?

Zig has inspired me to take up Systems programming again, it gives me energy in ways that C never did. It's a programming language, ecosystem and community that feels, above all else, honest, and that's something I find joy in sinking my teeth into.

Road to 1.0

We can safely hit 1.0 once the tool is stable, but another blocker is full feature-parity with GameMode.

This is the core list of tasks needed to fully surpass GameMode's current features.

  • Complete implementations of all optimisations in GameMode
    • CPU core pinning or parking
    • GPU performance mode (NVIDIA and AMD), GPU overclocking (NVIDIA)
    • Kernel scheduler (SCHED_ISO)
    • Power profile setting
    • Split-lock mitigation
    • Double check everything, not all of the GameMode internals are documented
  • Implement ListGames API (and then an equivelant of gamemodelist)
  • Implement Games API
  • Ensure org.freedesktop.portal.GameMode still works
  • Use the power profiles daemon dbus interface (pull #573)

Other fun to have

  • Run the tests in CI
  • Vendor the systemd libraries, rather than needing one installed to build
  • Implement a non-dbus path, needs a real-world example though
  • Ensure individual optimisations applied (or not applied) to each client are visible to the user (in ListGames or other APIs?)
  • Learn from TigerBeetle's tidy script
  • gamemodelist is hacky, it should use the ListGames API, needn't be it's own command, and could just be flyt --list
  • Tons of TODOs in the source to explore

Maintained by

Marc Di Luzio

License

Copyright © 2026 Marc Di Luzio

Flyt is available under the terms of the BSD 3-Clause License (Revised)

GameMode is Copyright © 2017-2025 Feral Interactive and the GameMode contributors

GameMode is available under the terms of the BSD 3-Clause License (Revised)