MangoHud reports gamemode off [workaround found]

[Zeioth]

Describe the bug I'm on arch linux and I've installed gamemode and lib32-gamemode. I've rebooted. But this is what systemctl --user status gamemoded.service show after running a game as mangohud gamemode %command%.

I'm not able to identify what the issue what could be. I'm using amd-pstate, I don't know if that's a problem.

Expected behavior gamemode runs correctly and mangohud reports is runnings correctly.

System Info (please complete the following information):

• OS and version: Arch linux
• GameMode Version: 1.7-1

Additional context The command gamemoded -t do not show errors:

[Zeioth]

Here you can see my CPU scheduler

[Zeioth]

A game reporting gamemode is off

[JCPersson]

Hello, I have the same issue and reported it here #443, can you verify if it happens with all games or only games that launch using the Proton compatibility layer? For me it started happening at the same time as I upgraded from a Nvida GPU plus Intel CPU combo to a AMD CPU and GPU, so I am suspecting it's some form of issue with AMD hardware.

[Zeioth]

@JCPersson it seems you are actually right. I've tested with the native Linux game Beat Invaders and gamemode is set on correctly

[Bulletdust]

I can confirm the same issue here running gamemode 1.7-1 under KDE Neon 5.27.10 kernel 6.2.0-39-generic (64-bit). Nvidia RTX 2070S, 535.146.02 drivers, i7-8700k.

Running gamemoded -t reports no problems, but gamemode is always reported as disabled under MangoHUD whether I launch a game via Proton under Steam or via Bottles.

[juanejot]

I likewise am running: steam launcher 1.0.0.78-2, mangohud 0.7.0-2, goverlay 1.0-1 (probably tangential, but just in case useful), gamemode 1.7-1, and lib32-gamemode 1.7-1 on an Arch system (kernel 6.6.7.arch1-1, mesa 23.3.1-1), all installed via pacman

and can confirm that gamemode -s says gamemode is not active while I'm in fact not running a game, says it is active while I am running a steam game with arguments mangohud gamemoderun %command%, but mangohud claims that it is not, and further when running a benchmark, the frame plot is visually (therefore I admit, anecdotally) not as smooth as the frame plot of Pop!_OS with a 6.6.6 kernel running steam & mangohud flatpaks (so versions 0.7.0 & 1.0.0.78 respectively, with mesa 23.3.0 bundled into the flatpak installation), an older apt installation of gamemode (both amd64 and i386, version 1.6.5 I believe), that says gamemode is on.

Also, be it due to running wayland/xwayland on the Arch install & just x11 on the Pop!_OS one; or due to gamemode, the benchmark score ends up empirically higher on the Pop!_OS install. (EDIT: see below; this turns out to have some bearing, but does not solve gamemode 1.7 having errors & showing as not running in mangohud).

So gamemode 1.7-1 loads on the Arch system (giving similar outputs to gamemoded -t and systemctl --user status gamemoded.service as above), but given my github reading regarding similar messages, may not successfully be injected into the game runtime.

I had wanted to install flatpak versions of steam & mangohud to more direct A/B testing under Arch, but recent versions of steam seem to be really finicky with old backups; even carefully following (probably old, but all that's updated online) steps to see my current non-flatpak game install library, it still isn't seeing it, and I don't have the bandwidth to download that particular game & its benchmark all over again (but it also seems to happen in other games, in which I'm not running benchmarks, and which would be yet more bandwidth to re-download).

In sum, MangoHUD seems to see gamemode running, frameplots are smoother, and benchmarks are higher, with (the apt packaging of) gamemode 1.6.5 (on a separate & somewhat differently configured install on the same hardware), and not with (the pacman packaging of) gamemode 1.7.

Any thoughts?

UPDATE: Simply switching Arch over to running the GUI via x11 rather than Wayland makes up both the benchmarked empirical performance difference, as well as makes the frametime plot glacially flat (mostly, though anecdotally comparable to or slightly better than on Pop!_OS). Of note, I get similar errors to the output of systemctl --user status gamemoded.service as above, while the game is running, even under x11. I'd say it's just a reporting issue between the latest version of gamemode & mangohud, but for those errors.

[juanejot]

Update to my above comment, just having updated to gamemode & lib32-gamemode version 1.8.1-1 on the Arch system, running the game in steam & exited long enough to enter the following command. The quote below is the output of systemctl --user status gamemoded.service:

● gamemoded.service - gamemoded Loaded: loaded (/usr/lib/systemd/user/gamemoded.service; enabled; preset: enabled) Active: active (running) since Wed 2023-12-20 18:47:54 PST; 59s ago Main PID: 1254 (gamemoded) Status: "GameMode is now active." Tasks: 2 (limit: 38302) Memory: 1.4M (peak: 3.6M) CPU: 18ms CGroup: /user.slice/user-1000.slice/[email protected]/app.slice/gamemoded.service └─1254 /usr/bin/gamemoded

Dec 20 18:48:41 [MachineNameRedacted] gamemoded[1254]: ERROR: External process failed with exit code 127 Dec 20 18:48:41 [MachineNameRedacted] gamemoded[1254]: ERROR: Output was: Dec 20 18:48:41 [MachineNameRedacted] gamemoded[1254]: ERROR: Failed to update split_lock_mitigate Dec 20 18:48:41 [MachineNameRedacted] gamemoded[1254]: ERROR: Skipping ioprio on client [3274,3274]: ioprio was (0) but we expected (4) Dec 20 18:48:41 [MachineNameRedacted] gamemoded[1254]: ERROR: Addition requested for already known client 3274 [/usr/bin/env]. Dec 20 18:48:41 [MachineNameRedacted] gamemoded[1254]: -- This may happen due to using exec or shell wrappers. You may want to Dec 20 18:48:41 [MachineNameRedacted] gamemoded[1254]: -- blacklist this client so GameMode can see its final name here. Dec 20 18:48:41 [MachineNameRedacted] gamemoded[1254]: ERROR: Skipping ioprio on client [3287,3287]: ioprio was (0) but we expected (4) Dec 20 18:48:41 [MachineNameRedacted] gamemoded[1254]: ERROR: Addition requested for already known client 3287 [/home/[UsernameRedacted]/.local/share/Steam/ubuntu12_32/steam-launch-wrapper]. Dec 20 18:48:41 [MachineNameRedacted] gamemoded[1254]: ERROR: Skipping ioprio on client [3288,3288]: ioprio was (0) but we expected (4) ~ ~ ~ ~ ~ ~

UPDATE: I've also never had a gamemoded -t test fail, but now, with no explanation about what failed, I get:

: Loading config : Running tests

:: Basic client tests :: Passed

:: Dual client tests gamemode request succeeded and is active Quitting by request... :: Passed

:: Gamemoderun and reaper thread tests ...Waiting for child to quit... ...Waiting for reaper thread (reaper_frequency set to 5 seconds)... :: Passed

:: Supervisor tests :: Passed

:: Feature tests ::: Verifying CPU governor setting ERROR: Governor was not set to performance (was actually powersave)! ::: Failed! ::: Verifying Scripts ::: Passed (no scripts configured to run) ::: Verifying GPU Optimisations ::: Passed (gpu optimisations not configured to run) ::: Verifying renice ::: Passed (no renice configured) ::: Verifying ioprio ::: Passed ERROR: :: Failed! : Tests Failed!

[a-plastic-bag]

Update to my above comment, just having updated to gamemode & lib32-gamemode version 1.8.1-1 on the Arch system, running the game in steam & exited long enough to enter the following command. The quote below is the output of systemctl --user status gamemoded.service:

● gamemoded.service - gamemoded Loaded: loaded (/usr/lib/systemd/user/gamemoded.service; enabled; preset: enabled) Active: active (running) since Wed 2023-12-20 18:47:54 PST; 59s ago Main PID: 1254 (gamemoded) Status: "GameMode is now active." Tasks: 2 (limit: 38302) Memory: 1.4M (peak: 3.6M) CPU: 18ms CGroup: /user.slice/user-1000.slice/[email protected]/app.slice/gamemoded.service └─1254 /usr/bin/gamemoded Dec 20 18:48:41 [MachineNameRedacted] gamemoded[1254]: ERROR: External process failed with exit code 127 Dec 20 18:48:41 [MachineNameRedacted] gamemoded[1254]: ERROR: Output was: Dec 20 18:48:41 [MachineNameRedacted] gamemoded[1254]: ERROR: Failed to update split_lock_mitigate Dec 20 18:48:41 [MachineNameRedacted] gamemoded[1254]: ERROR: Skipping ioprio on client [3274,3274]: ioprio was (0) but we expected (4) Dec 20 18:48:41 [MachineNameRedacted] gamemoded[1254]: ERROR: Addition requested for already known client 3274 [/usr/bin/env]. Dec 20 18:48:41 [MachineNameRedacted] gamemoded[1254]: -- This may happen due to using exec or shell wrappers. You may want to Dec 20 18:48:41 [MachineNameRedacted] gamemoded[1254]: -- blacklist this client so GameMode can see its final name here. Dec 20 18:48:41 [MachineNameRedacted] gamemoded[1254]: ERROR: Skipping ioprio on client [3287,3287]: ioprio was (0) but we expected (4) Dec 20 18:48:41 [MachineNameRedacted] gamemoded[1254]: ERROR: Addition requested for already known client 3287 [/home/[UsernameRedacted]/.local/share/Steam/ubuntu12_32/steam-launch-wrapper]. Dec 20 18:48:41 [MachineNameRedacted] gamemoded[1254]: ERROR: Skipping ioprio on client [3288,3288]: ioprio was (0) but we expected (4) ~ ~ ~ ~ ~ ~

UPDATE: I've also never had a gamemoded -t test fail, but now, with no explanation about what failed, I get:

: Loading config : Running tests :: Basic client tests :: Passed :: Dual client tests gamemode request succeeded and is active Quitting by request... :: Passed :: Gamemoderun and reaper thread tests ...Waiting for child to quit... ...Waiting for reaper thread (reaper_frequency set to 5 seconds)... :: Passed :: Supervisor tests :: Passed :: Feature tests ::: Verifying CPU governor setting ERROR: Governor was not set to performance (was actually powersave)! ::: Failed! ::: Verifying Scripts ::: Passed (no scripts configured to run) ::: Verifying GPU Optimisations ::: Passed (gpu optimisations not configured to run) ::: Verifying renice ::: Passed (no renice configured) ::: Verifying ioprio ::: Passed ERROR: :: Failed! : Tests Failed!

#452 it's seemingly a bug with the latest version

[tuxtergames]

any news about this, still get OFF status with steam?

[bpc1]

For gamemode failing check the issue @a-plastic-bag linked

And for mangohud looks like gamemode stopped preloading libgamemode.so which is what mangohud checks to see if gamemode is running. As a workaround you can preload it manually with LD_PRELOAD command. Obviously you still need to start gamemode with gamemoderun. One more thing this doesnt work on OpenGL games. Heres my example of the launch options, your path to libgamemode.so might be different

 LD_PRELOAD=/usr/lib/libgamemode.so gamemoderun mangohud %command%

[juanejot]

For gamemode failing check the issue @a-plastic-bag linked

And for mangohud looks like gamemode stopped preloading libgamemode.so which is what mangohud checks to see if gamemode is running. As a workaround you can preload it manually with LD_PRELOAD command. Obviously you still need to start gamemode with gamemoderun. One more thing this doesnt work on OpenGL games. Heres my example of the launch options, your path to libgamemode.so might be different

 LD_PRELOAD=/usr/lib/libgamemode.so gamemoderun mangohud %command%

This preload suggestion for the launch options worked great! The issue of noticeable performance penalties with gamemode 1.8.1(-2, now) vs 1.7 remain. Haven’t tested… well, testing again, because if 1.8.1(-x so far) doesn’t work for its main goal… Anyway, thanks for the preload tip!

[Zeioth]

I can confirm passing the env var LD_PRELOAD=/usr/lib/libgamemode.so displays gamemode on.

[michaldybczak]

I can also confirm this on Manjaro testing branch with AMD dGPU. On Proton game (like Baldur's Gate 3) Mangohud shows: *GAMEMODE OFF while in terminal, I can confirm that it is active:

$gamemoded -s
gamemode is active

When game is closed, terminal shows gamemode inactive, so it looks like terminal shows a real state, but Mangohud is not.

When I was using Nvidia (different laptop) on the same system, this worked correctly.

Operating System: Manjaro Linux KDE Plasma Version: 6.0.3 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.3 Kernel Version: 6.7.12-1-MANJARO (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 7840HS w/ Radeon 780M Graphics Memory: 30.6 GiB of RAM Graphics Processor: AMD Radeon Graphics Manufacturer: TUXEDO Product Name: TUXEDO Sirius 16 Gen1

Device-1: AMD Navi 33 [Radeon RX 7700S/7600/7600S/7600M XT/PRO W7600] driver: amdgpu v: kernel

I can also confirm, that this workaround works: LD_PRELOAD=/usr/lib/libgamemode.so gamemoderun mangohud %command%

and makes Mangohud showing "GAMEMODE ON"

[gschintgen]

See also: https://github.com/flightlessmango/MangoHud/issues/591

[joan31]

Hi

Bug is still not corrected.

And workaround does not work with some games using OpenGL or Dxvk

[Alxston]

I too have had this issue with the longest time with either Kubuntu and Arch. But I thought maybe it was because of a 32bit game client. I can't even find libgamemode.so nor libgamemode0.so, libgamemode0:i386.so etc which is what currently Ubuntu lets us use.

[joan31]

You are right. The command will be different between 32bits and 64 bits games.

For 32 bits games :

LD_PRELOAD=/usr/lib32/libgamemode.so gamemoderun mangohud %command%

For 64 bits games :

LD_PRELOAD=/usr/lib/libgamemode.so gamemoderun mangohud %command%

[tuxtergames]

You are right. The command will be different between 32bits and 64 bits games.

For 32 bits games :

LD_PRELOAD=/usr/lib32/libgamemode.so gamemoderun mangohud %command%

For 64 bits games :

LD_PRELOAD=/usr/lib/libgamemode.so gamemoderun mangohud %command%

tks mate, works here, for Nobara users the path for lib is

LD_PRELOAD=/usr/lib64/libgamemode.so.0.0.0 for 64bit games LD_PRELOAD=/usr/lib/libgamemode.so.0.0.0 for 32 bit games

[Alxston]

Thank you!!!

You are right. The command will be different between 32bits and 64 bits games.

For 32 bits games :

LD_PRELOAD=/usr/lib32/libgamemode.so gamemoderun mangohud %command%

For 64 bits games :

LD_PRELOAD=/usr/lib/libgamemode.so gamemoderun mangohud %command%

[Steemx]

You are right. The command will be different between 32bits and 64 bits games. For 32 bits games : LD_PRELOAD=/usr/lib32/libgamemode.so gamemoderun mangohud %command% For 64 bits games : LD_PRELOAD=/usr/lib/libgamemode.so gamemoderun mangohud %command%

tks mate, works here, for Nobara users the path for lib is

LD_PRELOAD=/usr/lib64/libgamemode.so.0.0.0 for 64bit games LD_PRELOAD=/usr/lib/libgamemode.so.0.0.0 for 32 bit games

This worked for me, Fedora 42 workstation, thanks you!!

[jn64]

There is no need to set different 32-bit and 64-bit lib path.

Use this:

LD_PRELOAD="/usr/\$LIB/libgamemodeauto.so.0${LD_PRELOAD:+:$LD_PRELOAD}" mangohud %command%

Full explanation in https://github.com/FeralInteractive/gamemode/issues/443#issuecomment-3370205275