Add libgamemode support

[DavidHusicka]

Gamemode is a open source library/daemon that allows games to request a set optimizations on the host system on Linux. Some games that use gamemode are Rise of the Tomb Raider, Shadow of the Tomb Raider and DiRT 4.

This PR implements gamemode such a way that users without gamemode can still play the game without any issues. If gamemode is installed on the host system, osu!lazer requests optimizations upon start of every beatmap and requests end upon end of every beatmap. Usage of gamemode can be verified with gamemoded -s command.

Gamemode is available on most Linux distributions and can be installed for example using sudo apt install gamemode on Ubuntu and sudo pacman -S gamemode on Arch.

You can check gamemode at https://github.com/FeralInteractive/gamemode

[Game4all]

Platform-specific stuff like this shouldn't reside in osu.Game project but rather in osu.Desktop project and use a component that you insert into the drawable hierachy and which listens for value changes of Game.LocalUserPlaying field instead of calling it in PlayerLoader (see the following link for an example https://github.com/ppy/osu/blob/master/osu.Desktop/Windows/GameplayWinKeyBlocker.cs).

Also you may want to add platform checks to add this component only when the host runs linux and should add handling for cases where the DLL isn't locatable (as it'll cause a crash as it is right now when calling the PInvoke methods and the DLL isn't locatable).

(All what is said above assumes of course that support for gamemode is accepted.)

[DavidHusicka]

Will look into moving it to the osu.Desktop project.

It already checks whether the DLL is available on the system. Tried to run without gamemode on and it works without any issues.

[bdach]

I'm not personally convinced by this pull.

Most of all, from what I can see, you could just do gamemoderun ./osu.AppImage and get pretty much the same results (although that would activate the tweaks in menus as well). Given that's the case, it feels simpler to not merge this, and force whoever might want to use that daemon to do so through the CLI command. Accepting this is another implicit dependency to track (and worse yet, it's a silent one - if the gamemode API ever changes, the only way we'll ever know is if somebody bothers to report it silently failing).

The lesser issue I take is with the mode of activation. It's not like the game is less graphically intensive in the menus. So I don't really get why the game mode is only ever launched during gameplay.

The way I see it, performance management at that level (fiddling with OS/hardware parameters) should either fall squarely to the OS, or to a user if they wish to tweak it, and not to the game.

Oh, and as an aside, if we were to take this, it might actually be better to take it at the framework side rather than locally in the game.

[DavidHusicka]

I'm not personally convinced by this pull.

Understandable

Most of all, from what I can see, you could just do gamemoderun ./osu.AppImage and get pretty much the same results (although that would activate the tweaks in menus as well). Given that's the case, it feels simpler to not merge this, and force whoever might want to use that daemon to do so through the CLI command.

User can force gamemode through a CLI command but from a perspective of an user, it is better to install daemon and have all games calling it when it's needed rather than having to start up terminal and type some commands to play a game.

Accepting this is another implicit dependency to track (and worse yet, it's a silent one - if the gamemode API ever changes, the only way we'll ever know is if somebody bothers to report it silently failing).

I don't think the API will change. It's made for games and once game is published on for example Steam, it usually won't get update for years. Furthermore, such a change would break a lot of other games since distributions distribute updates with different speed so I don't see the API changing anytime soon.

The lesser issue I take is with the mode of activation. It's not like the game is less graphically intensive in the menus. So I don't really get why the game mode is only ever launched during gameplay.

This is for the same reason as why osu! (as in stable) is locked at 240 FPS in the menu. There is no need to have better performance in the menu since it would only cause higher CPU and battery usage. Menu is not a game.

The way I see it, performance management at that level (fiddling with OS/hardware parameters) should either fall squarely to the OS, or to a user if they wish to tweak it, and not to the game.

Gamemode is something explicitly installed by the user. It is not preinstalled on any distribution I know about. Using gamemode is considered safe by many people. For example, Lutris, which is a game launcher that most people on Linux use, enables gamemode for all games it installs by default if it detects that gamemode is installed on the system.

Oh, and as an aside, if we were to take this, it might actually be better to take it at the framework side rather than locally in the game.

There is no way I can detect from framework side whether the user is in game, isn't it?

I marked this PR as WIP for now since I am planning to move this to the osu.Desktop project. I am glad for this discussion to take place. If you have any other points you'd like to mention, don't be afraid to do so. I will understand if this won't get merged since it's something that may sound scary to some people and/or you don't want to add this as an additional dependency.

[sr229]

I don't really see the performance benefits in this PR. There are a lot of reasons for this:

• Some or most Linux distributions comes with a low-latency kernel which you can swap out the generic one. This uses a much more efficient scheduler and governor, which makes any kind of performance benefits of libgamemode integration moot.
• Even with generic kernels, you can still pull off a low input latency. It's already tested against 7DEs by someone on Reddit, which is also a consideration,
• It doesn't come preinstalled, which makes it even useless since your average Linux user wouldn't want to add a new package just to get performance for just one process. If you really wanted to, just do it for the entire system.

So in a practical sense, this kinds of integration just adds bloat, since what libgamemode does can be done system-wide anyways, and it'll work better minus the dependency.

[smoogipoo]

Tending to agree with @sr229, especially the "your average Linux user wouldn't want to add a new package just to get performance for just one process" part.

[DavidHusicka]

@sr229 you made really good points. Regarding performance, I am implementing this because I have a good experience with gamemode. I noticed performance increase in several games on my setup with vanilla kernel.

The other part is about gamemode usage. It stands and falls on the actual usage of gamemode by the Linux community. This is a thing that cannot be easily measured. I will try to get some numbers anyway. According to pkgstats from Arch Linux, gamemode is installed on 6,4% of computers that opted into statistics. Steam for example is installed on 42,3% of these computers. From now on, there is a lot of assumptions and all I write can be (and most likely is) absolutely wrong. This is just to get some numbers. If we assume that only Steam users use gamemode, then 15,1% of Steam users have gamemode on their system. If every osu! player is Steam user, then roughly 15% of players have gamemode on their system which is roughly every 7th user. I repeat again, these numbers are based on assumptions that are most likely wrong and made up just to get some numbers. I don't think that every osu! player has Steam and that only Steam user install gamemode.

Source of the statistics: https://pkgstats.archlinux.de/packages

Anyway, I think that this PR is complete from my side. If you have any questions and/or comments, please let me know.

[sr229]

Unless you can give more solid figures, my point still stands. Installation metrics is not really a good basis of how good a package is, as sometimes they're a interdependency of a software feature (for example, Lutris).

The costs for adding this outweighs any benefits you planned, plus the fact it only executes during gameplay just makes it inherently a bad design pattern.

I'm against this PR as this only adds more complexity, if you really want performance, run gamemoderun manually to it or just tweak your kernel to use the performance governor.

[hwsmm]

If it helps, Ubuntu higher than 20.04 has gamemode by default.
https://www.gamingonlinux.com/2020/04/the-gamemode-performance-tool-from-feral-interactive-makes-it-into-ubuntu-2004

I can confirm this as I didn't need to install anything to use gamemode in Ubuntu 20.04 and 20.10, but it is also true that most people don't make use of this.

However, if the problem is about how many users actually have gamemode, I don't see that is a problem because Ubuntu literally has it by default.

[bdach]

Ubuntu adding upstream support is probably the strongest argument I've heard for taking this in thus far. Given the distro's popularity it at least gives some hope that this will see actual usage, which I wasn't convinced about until now.

Note that I'm not still super sold on this, neither do I interpret Ubuntu/Canonical's decision as representative of the Linux ecosystem as a whole, because it's so fragmented that nothing ever will be. I'm personally mostly looking for the most bang for the buck with integrations like these.

[sr229]

Ubuntu adding upstream support is probably the strongest argument I've heard for taking this in thus far. Given the distro's popularity it at least gives some hope that this will see actual usage, which I wasn't convinced about until now.

Note that I'm not still super sold on this, neither do I interpret Ubuntu/Canonical's decision as representative of the Linux ecosystem as a whole, because it's so fragmented that nothing ever will be. I'm personally mostly looking for the most bang for the buck with integrations like these.

I'm looking at this more in a distro-agnostic presence, especially when best practices in Linux mandates that you should compensate for multiple configurations, and not just one specific configuration (so that means if you want to make it optimized in ubuntu, it should reflect the same on every standard Linux distribution out there). As someone who deals with Linux desktop for over 3+ years, I will say this and I will say this again that compensating only for one distribution can lead to nasty side effects when used on another distribution because they use a more updated library or doesn't have the package set it's looking for.

So, I'm leaning on just providing a guide on giving awareness on using built-in functions of the Linux kernel rather than rely on a library only a fraction of users would even use.

[peppy]

Ignoring linux politics (because this isn't something we are going to get involved in in this project; please take that elsewhere) I am still tentatively "for" supporting this, but it would be nice to see some kind of benchmarks showing how it actually improves things.

While adding support is pretty low overhead (and low chance of regressing over time) we generally don't blindly merge things, especially when they involve performance.

aka. please do not respond to this thread unless the response is benchmarks comparison this PR to master.

[DavidHusicka]

Here are some data from benchmarks I run

All data are generated against master and this PR using mangohud --dlsym dotnet run --project osu.Desktop -c Release command. Benchmark was run on a beatmap called The Big Black.

Framerate

Frametime

On previous picture, there were a huge spikes on the start of runs number 2 so I removed the spike so the rest of the graph could be seen better. The resulting picture is below.

Maximal frametimes from all tests

Original data:

https://drive.google.com/drive/folders/1QFNsvmAd0oaWO7Jzym3nkv1B-ds_-YF5?usp=sharing

Conclusion?

It is nothing groundbreaking but to me, it seems it has a little less/smaller spikes with gamemode.

[peppy]

Thanks for the benchmarks. What is the scale of the frame time graphs?

[DavidHusicka]

Thanks for the benchmarks. What is the scale of the frame time graphs?

It should be microseconds.

[smoogipoo]

This causes a 2-3 second freeze at the start of gameplay for me.

OS: Manjaro 21.0.2 Ornara
Kernel: x86_64 Linux 5.10.30-1-MANJARO

[peppy]

@DavidHusicka Sorry for the delay in actioning on this PR. Was going to look at getting this merged (or otherwise closing it for now) but due to the issue @smoogipoo came across this is non-mergable for now. If this isn't something you can reproduce and/or know a fix for, it may be best to hold off on implementing this for now.

[DavidHusicka]

Managed to reproduce. Had no idea that this happens. The situation on my end isn't as bad as for @smoogipoo but it isn't great experience nevertheless. Will look further into the issue.

[peppy]

Going to close this one for now. I think the issue causing the delay in mode changes needs to be reported upstream before anything can happen here. We don't want osu! to be setting game mode for its complete execution, as it's quite common for users to leave it open in the background while potentially performing other tasks.

As an aside, the HighPerformanceSession class has now been merged, so attempting to add this a second time should be trivial, if/when we see that as a potential.