Feral's GameMode 1.2 Released For Optimizing Linux Gaming

[starshipeleven]

Sure. Mind you i didn't look at all of it.

It's in two parts, a library ("libgamemode", see the lib directory), and a daemon.
A game links against that library and calls gamemode_request_start(). When the game is done it calls gamemode_request_end(). See the example for that.
What the library does is it opens a Dbus socket and uses it to talk to the daemon.
The daemon sets the cpufreq governor by using pkexec (!) to run a little program called cpugovctl (part of "daemon") that sets the governor.

You can glance a decent deal from the comments in the various files.

Now what's wrong with it...
First, it requires the GAME to send a message saying "i started", and worse it requires the game to say "i stopped".
The problem with "i stopped" is an obvious one. The daemon handles this by checking periodically to see if the game is still running.
This is not just a problem of "why does the game have to link against this", but also that it uses dbus (yet another library).
There are two ways of doing this without changing the game, with pooling and by using proc events (https://bewareofgeek.livejournal.com/2945.html).
Note that there is also a library called "libgamemodeauto" which is to be preloaded (LD_PRELOAD). It works without changing the games code.

Other problems are using systemd and meson.
Meson is not needed for this at all, as it is a really simple code.
Systemd... i don't know what it uses it for as it does everything itself. README says "This design also means that while the host library currently relies on systemd for exchanging messages with the daemon, ..". Looking through the files i don't see where exactly it uses systemd (probably the dbus related files), not that i looked too hard. Since it uses it to talk to the game, just cutting out the messaging completely would get rid of this as well.

Oh, and one of the "Planned Features" is "Improved client state tracking (PID is unreliable)". Proc events would make it practically reliable.

What it currently does, i could write in half an hour to an hour. (Because i did something similar already, and it is fairly simple when you know how it goes)

Hm, interesting. It would be kinda amateurish even for a shell script. Seriously, PID checking is just bad in 2018.

I thought they were using systemd for process tracking (even simply polling systemctl to see the status of the game service if the game has a systemd unit), because really, that's the whole point of it.

[gens]

Hm, interesting. It would be kinda amateurish even for a shell script. Seriously, PID checking is just bad in 2018.

I thought they were using systemd for process tracking (even simply polling systemctl to see the status of the game service if the game has a systemd unit), because really, that's the whole point of it.

Tracking by PID is not that bad. Obviously they found some game where it won't work, though.
The LD_PRELOAD thing, many games already do that (including dota2). You get a script called "start.sh" or something and it works. It's good for games. (EDIT: They use it for other libraries, not the gamemode one specifically) Only problem if that start.sh overwrites LD_PRELOAD instead of appending to it.
Using systemd itself to track a game is much more trouble, for gamemode and for those making the games. And it's not necessary.

[starshipeleven]

Tracking by PID is not that bad. Obviously they found some game where it won't work, though.

Tracking by PID is unreliable because PIDs can be reused once their process died, and if a new process takes the same PID of the old process you were watching, then your daemon will think some other random process is the game process.

It's not horribly unreliable, granted, it usually works decently unless your system is really starved for new PIDs (which I can concede isn't that common on a desktop PC), but that's something you shouldn't rely on for serious work.

Using systemd itself to track a game is much more trouble, for gamemode and for those making the games. And it's not necessary.

Define "much more trouble".

It's basically as easy as shipping a 3-lines systemd unit (a text file) for the game, and have the game "launcher" actually tell systemd to start that service as the user (systemctl --user start gamename) so that just polling systemctl status gamename with your daemon will return the status of the game.

With a mildly more advanced systemd unit (add another line to the 3-line text file) you can actually have your game depend on the "game mode" systemd unit where you run the daemon to start game mode, so that when the game starts systemd will also run the "game mode" daemon/script.
Aand then add yet another line that tells systemd to shut down the "game mode" service (so it will execute the operations to restore the situation back as before) once the game terminates.

I can agree that it would be "controversial" and that you can do the same also without, but it is not hard. You can basically make an equivalent of this Game Mode thing with systemd units and a script where you keep the commands to change governor and process priority or whatever and revert them back when it's time.

[gens]

Tracking by PID is unreliable because PIDs can be reused once their process died, and if a new process takes the same PID of the old process you were watching, then your daemon will think some other random process is the game process.

It's not horribly unreliable, granted, it usually works decently unless your system is really starved for new PIDs (which I can concede isn't that common on a desktop PC), but that's something you shouldn't rely on for serious work.


Define "much more trouble".

It's basically as easy as shipping a 3-lines systemd unit (a text file) for the game, and have the game "launcher" actually tell systemd to start that service as the user (systemctl --user start gamename) so that just polling systemctl status gamename with your daemon will return the status of the game.

With a mildly more advanced systemd unit (add another line to the 3-line text file) you can actually have your game depend on the "game mode" systemd unit where you run the daemon to start game mode, so that when the game starts systemd will also run the "game mode" daemon/script.
Aand then add yet another line that tells systemd to shut down the "game mode" service (so it will execute the operations to restore the situation back as before) once the game terminates.

I can agree that it would be "controversial" and that you can do the same also without, but it is not hard. You can basically make an equivalent of this Game Mode thing with systemd units and a script where you keep the commands to change governor and process priority or whatever and revert them back when it's time.

You see, that's why i'm bitter.
Imma go light one up.

[xcom]

Which games are using this automatically if installed ?