Gamescope runs fine, when it works then starts to stutter very badly on Fedora KDE

[Melorn366]

What repository did I use in order to install the latest gamescope on fedora ? This https://copr.fedorainfracloud.org/coprs/petrb/gamescope/packages/

Why did I use this repository when gamescope is available in the main repository? Because this issue was present with older gamescope builds (which is available on fedora)

What else do I notice during the time when the Bug happens?

GPU usage is 100% all the time.

What others programs do I use in order to make gamescope run at the best performance?
Corectrl (to control gpu fancurve and set the gpu governor to performance along with cpu), gamemode (So that I can force the CPU to have a higher priority during steam gameplays. In gamemode.ini file i set renice to 10, desiredgov set to performance and finally softrealtime to auto )

Does this issue occur when gamemoded is not in use (deleted from the game launch section). Yes it happens. With the newer gamescope version and the older one which is available in fedora.

What files should I provide, so this issue could be sorted ?

[petr666]

Hi, this is my repository, so only for clarification, despite package has version 3.7.1, it is actually built from master so it matches commit d537d6a. I did not encounter this bug yet, but i am not using it very much, i was testing some games maybe for 30 minutes or so.

[Melorn366]

@petr666 Hi there check out my video about this.
launch option gamescope -w 1920 -h 1080 gamemoderun %command%

As I said in the video, i disabled futex2 so it is definitely not the one causing the issue. The bug happens randomly. The performance is very good until this bug happens (it can happend totally randomly, sometimes it need more then 30 mins). Using KDE (and the bug could be reproduced both in wayland and x11 session)

https://www.youtube.com/watch?v=i_09HOxnhJg

[Kiwii]

In gamemode.ini file i set renice to 10

10 or -10? Higher nice value means lower priority.

[Melorn366]

In gamemode.ini file i set renice to 10

10 or -10? Higher nice value means lower priority.

Accodin to this webside (you are wrong) https://gamecrate.com/linux-gaming-boost-your-performance-gamemode/25200
Quote
"f you have four or more CPU cores. I like to set the “renice” value at “10” - this will increase the priority of your game’s process, telling Linux to prioritize the game’s CPU time."

[Melorn366]

The issue is still present. Its definitely not caused by gamemode. For further testing purpose I deleted gamemode from my system, and just let gamescope run without even moving a mouse in menu. The issue appeared precisely at 30 mins. I tested this stock kernel (without any patches) and with custom tkg patches. The issue could have been reproduced at both times. So no matter what Desktop environment I use, it happens all the time. Tested on Fedora, Ubuntu, Arch, variants like (endeavour, garuda) . This issue still exist.

[Melorn366]

As I said I would love to provide logs or anything that the dev needs. I just need explanation how to provide them.

[emersion]

Maybe trying to capture some traces with gpuvis when it's stuttering would help.

[Melorn366]

Maybe trying to capture some traces with gpuvis when it's stuttering would help.

If you explain how to capture gpuvis traces during stutter, I would gladly help.

Recently the terminal post this while running games Unhandled NET_WM_STATE property change: _NET_WM STATE_MAXIMIZED HDRZ

[Melorn366]

Okay. Figured it out that gpuvis is your tool emersion. Buit it using aur repo. Now how to find traces when it comes to steam games? Or how does it work? I would gladly help. I just need explanation.

[ppascher]

Have the same issue with "The Witcher 3". After ~24 minutes the game starts stuttering. FPS according to MangoHud drop from ~160 to ~80. Restarting the game helps (for another 24 minutes). If I start the game without gamescope the issue is gone. Running under Windows is fine as well. I tried different Proton Versions but it did not make a difference. This is on kernel 5.12.4 and mesa-git (as of 2021-05-15) with a 6900xt. Will try to get some traces/logs.

[ppascher]

Not sure if this is the same issue as the OP but the symptoms describe my issue. Here is a trace-cmd capture right after it started stuttering.
witcher3_trace-cmd.dat.tar.gz.
Frametimes start looking like this instead of a constant value/line:

[ppascher]

Tried some more games. The stuttering appears after the 24 minute mark for
The Witcher3 (DXVK)
Cyberpunk 2077 (VKD3D)
Doom Eternal (Vulkan)
Book of Forbidden Tales 2 (OpenGL)

It does not seem to be temperature related as those are pretty stable after 10 minutes. To test I ran all fans at 100% speed which dropped the temperatures by 5-8°C but the issue still appeared after 24 minutes. And as mentioned before: without gamescope all those games work fine while having the same temperature.

[ppascher]

Still is an issue with latest master on my machine (arch 5.14.2, mesa-git):
Tried a trace-cmd capture again (as last one did not contain required info from what @emersion told me in irc):
20210908_witcher3_trace-cmd.dat.tar.gz
gpuvis screenshot of when the stuttering starts:

[ppascher]

I just tried starting two games via gamescope with a 10 minute delay. Both windows ran next to each other on one screen (sway tiled mode). The first game (Kingdom Come Deliverance via DXVK) started stuttering as expected after ~24 minutes. The second game (Witcher3 / DXVK) ran fine for another 10 minutes and then also started stuttering.
If I use the same setup but switch to a different workspace on the same monitor so that the games are not visible they run fine even after the 24 minute mark. So it appears the games have to be visible for 24 minutes for the bug to kick in.
Edit: When started without gamescope both games run fine next to each other for >3h (as is the case when just running one game).

[Melorn366]

Greetings ppacher. Yes we have the same issue. To be precise exactly the same ! Finally someone !

I am very worried about this issue. If steamdeck releases and this issue will be still present in December. Steamdeck will fail miserably. I truly wish team valve the best. But this issue haven't been fixed for half a year now.

This information is not reaching either Emerson or Plagmen ( Pierre-Loup A. of Valve)

BTW thx for sharing ppascher.

The 24 min mark is present ! After that it stutters.

ppascher. I have a question for you.

1.You say that gamescope run fine when you start it in a different workspace? I need to test this.
2. How do you set up gamescope to play games at 1920x1080? are you setting it up like this ( -W 1920 -H 1080 or -w 1920 -h 1080) ? For me this does not change the resolution of games like warframe ( -w 1920 -h 1080) whit this nothing happens and the game start in 720p.
3.Are you using integer scaling ? Option -n

[ppascher]

I run at 3440x1440 and tried both -W/-H and -w/-h. I do not use -n. I tried running with and without gamemode/mangohud. I manually fullscreen my game as with the -f option games do not run. I use git master of sway/wlroots/mesa on arch. Tried both custom kernel and default distro kernel. Hopefully we can figure out what is causing this.

[Melorn366]

Hey there ppasher, thx for the reply. I don't know what it is causing this, but it concerns me that plagman or emerson doesn't respond. Can you contact them ? They doesn't seem to notice our conversation..This is very serious bug.

[emersion]

This is an open-source project. Feel free to submit patches, but don't expect your bugs to magically fixed.

I don't have time to look into your issue at the moment.

[Melorn366]

@emersion Greetings thx for responding. This has been an issue for months now and I pretty much bad at programming. But lets ask @ppascher

Btw emersion what kind of data do you need in the future in order for this to be fixed?

[ppascher]

One more thing I noticed is when I keep moving the mouse the stuttering is gone. As soon as I stop the cursor the stuttering is back.

[ppascher]

In case anyone else runs into this and is able to make sense of it here is another gpuvis screenshot of a trace with gamescope events logged while stuttering:

And here is the full trace file:
20211017_gamescope_trace-cmd.dat.tar.gz

[ppascher]

some more information:
starting steam via gamescope (either from within sway or directly from tty with /usr/local/bin/gamescope -e -f -- steam -tenfoot -steamos -fulldesktopres and then a steam game does not cause these stutters.
Starting steam from within sway without gamescope and then using the steam game launch options to start a game via gamescope causes these stutters after ~24-25 minutes.

[jarrard]

ARK goes into stutter mode after 20mins with gamescope, no idea whats going on.

[jarrard]

I just remembered; I believe this stutter happens with gamescope and Star Citizen (via wine). So that is yet another game that gets this bug and surely a solution can be found.

[Plagman]

@ppascher interesting trace, thanks a lot! Looks like something is keeping the steamcompmgr thread busy for a long time. This would be great to look at such a trace with latest gpu-trace, which also includes a perf capture.

Separate from that, worth re-testing with current master, as the buffer import path has changed significantly and might interact with this issue.

[ppascher]

@Plagman Sorry, did not get a notification and just now saw your reply. I just tested with kernel 5.15.11, mesa, wlroots, gamescope git master as of today and still run into this issue. I created a new capture using gpu-trace and sent you a download link through the valvesoftware contact page (I get an error when trying to attach the file to this comment)
This trace shows the stuttering and also a brief period where the stutter was reduced when I kept moving the mouse.
Thank you for looking into this.

[JPEspinoza]

Hello, I don't know if this is related, but someone on Reddit asked me to mention it here.

On Fedora 35 with Gnome, Nvidia and Xorg (no Gamescope), when I play Valheim (Native, Vulkan) it starts stuttering after about 30 minutes unless I enable the Steam overlay, which seems to workaround the bug. To be clear: Steam overlay disabled = stuttering and low FPS after ~30 minutes, Steam overlay enabled = normal performance. I don't need to open the overlay in game either, just having it be enabled works. I do have an FPS counter though.

Maybe the Steam overlay has something to do with this issue? Or whatever it does bypasses the error? Again, I'm not using Gamescope, so its probably a completely different issue specific to Valheim.

More people mentioning the bug in this thread: https://www.reddit.com/r/linux_gaming/comments/lmslz9/best_settings_to_optimize_valheim/

[madmonki]

Any solutions? I get this issue on Apex and Elden Ring but probably I will get on every game. My launch options are gamemoderun gamescope -e -f -- %command% . Distro is Endeavour (arch btw) and using kde-wayland.

[cactushydrocodone]

The issue just disappeared for me. Im on arch, maybe an update of some package fixed it

[madmonki]

Hello, I don't know if this is related, but someone on Reddit asked me to mention it here.

On Fedora 35 with Gnome, Nvidia and Xorg (no Gamescope), when I play Valheim (Native, Vulkan) it starts stuttering after about 30 minutes unless I enable the Steam overlay, which seems to workaround the bug. To be clear: Steam overlay disabled = stuttering and low FPS after ~30 minutes, Steam overlay enabled = normal performance. I don't need to open the overlay in game either, just having it be enabled works. I do have an FPS counter though.

Maybe the Steam overlay has something to do with this issue? Or whatever it does bypasses the error? Again, I'm not using Gamescope, so its probably a completely different issue specific to Valheim.

More people mentioning the bug in this thread: https://www.reddit.com/r/linux_gaming/comments/lmslz9/best_settings_to_optimize_valheim/

It appears the bug gone with this solution. My steam overlay was off.

[ppascher]

It appears the bug gone with this solution. My steam overlay was off.

Enabling steam overlay prevents the issue for me as well. Tested in both DXVK (Kingdom Come Deliverance) and VKD3D (Cyberpunk 2077). Thank you @JPEspinoza

[itspngu]

I can confirm that enabling the Steam overlay "fixes" the issue. I'm on Fedora (Rawhide) aswell.

[itspngu]

It's related to -e/--steam, which I had in my commandline because my cursor wasn't working as reported by others in #420. Removing that and using Proton 6.3 instead of 7 (tried both Experimental and GE) allows me to turn off the Steam overlay and not have the degradation after 24 minutes.

/cc @Plagman

[ghost]

Same issue in Back 4 Blood on Fedora Silverblue 37 flatpak gamescope/steam versions, using -f and -r flags, 6700 XT GPU. Game runs fine for a while and ~30 minutes later the frame timing jumps up and down with extreme unplayable stutters. Whether I set max_fps or v-sync in game doesn't seem to matter.

[madmonki]

you should have -e in flags and enable steam overlay. @mystrdat

[CartoonFan]

Ran into this issue too, unfortunately 😢

Nvidia GTX 960, Ryzen 3700X, Arch Linux, Openbox, Castlevania Advance Collection, Proton-tkg 7.18.r11.gaabde227, Linux 5.19.14-270-tkg-bmq

Here's my Steam launch options:

gamescope -w 1280 -h 720 -r 60 -o 60 -n -i -Y -e -- obs-gamecapture %command%

And here are the proton logs:
steam-1552550_gamescope_no_overlay.log
steam-1552550_no_gamescope_no_overlay.log

I'm running vk-capture, but I can't imagine the problem is there, right? For me, the time limit is about 27-28 minutes before the stuttering starts. I don't have concrete proof, but I suspect that the game window needs to be in focus for the stuttering to happen; I feel like the game was running for >28 minutes with no problem, but after about...maybe 11 minutes of in-focus gameplay, the stutters happened.

Running with the overlay helped, but I'm recording game footage, so it's not really an optimal solution. Running without gamescope and without the overlay also worked fine, in my brief testing. It also doesn't seem Wine-specific: I encountered slowdowns with Risk of Rain as well (again with gamescope on and the overlay off).

Anyway, I'm happy to provide more information if it'll help 👍

[CartoonFan]

I managed to take a picture with MangoHud running (sorry for the tiny font 🤣) :

Like before, the stutters happened after somewhere between 95-96K frames--roughly 28 minutes of gameplay. Curiously, GPU usage seems to be reduced after the stutters begin; it went from 20-30% usage to 10-20% usage 😕 .

I also managed to get some logs (again, from MangoHud):

game_2022-10-23_23-15-07.csv

game_2022-10-23_23-15-07_summary.csv

There seems to be a bunch of weird 14 FPS dips surrounded by normal FPS rates 🤔

My gamescope params are here:

-w 1600 -h 900 -W 1600 -H 900 -r 60 -o 60 -i -n -Y -e

If possible, I'd really love to see a fix that's not just "turn on the steam overlay" 🙏

(Also, IMO, this bug is up there with #216 and #577 for me...but those I can kind of work around 😆)

[Sturmlocke86]

Same issue here on Ubuntu 22.10 and Nvidia T600 with 515 drivers installed. Going to try the suggested launch command addition -e plus will also enable Steam Overlay, as I usually turn Steam Overlay off, and report back how it goes. Installed Gamescope via Ubuntu 22.10 repos. Tried Proton Exp and Proton 7 so far.

[Sturmlocke86]

Update

Ok, doing what the others suggested "fixed" the issue on my end as well: Activate Steam Overlay, add -e line to Gamescope launch command in Steam, use Proton 6, 7 or Exp - works with all of them. Performance is more or less normal after this. Usable workaround for now, but not optimal when recording or streaming via OBS ofc. That said, wouldn't mind donating a few coins to fix this.

[justin8]

Sadly this issue still exists for me; when I enable steam overlay with or without the -e I get a black window (despite using the fullscreen flag in the gamescope command) and it never loads.

[hikkidev]

@Melorn366 please, rename this issue to make it easier to find

[Sporknife]

I still experience this issue when using gamescope.

Operating System: Arch Linux
KDE Plasma Version: 5.26.5
KDE Frameworks Version: 5.102.0
Qt Version: 5.15.8
Kernel Version: 6.1.9-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors: 12 × Intel® Core™ i7-8700 CPU @ 3.20GHz
Memory: 15,5 GiB of RAM
Graphics Processor: AMD Radeon RX 480 Graphics
Mesa: 22.3.4-1, 23.1 (chaotic-aur)

[cheungyau2022]

I am having the same issue. Ubuntu 22.04 with Nvidia Tesla P40. Games run fine for around half an hour, then frame drops severely, and frame time goes crazy. Without gamescope all games run perfectly. I will try enabling steam overlay and adding -e option.

[zaskokus]

It appears the bug gone with this solution. My steam overlay was off.

Enabling steam overlay prevents the issue for me as well. Tested in both DXVK (Kingdom Come Deliverance) and VKD3D (Cyberpunk 2077). Thank you @JPEspinoza

out of curiosity, what are your parameters to run KCD over gamescope? No matter what I do the game doesn't start (leaving wine components hanging and requiring to be killed manually). I get the splash screen and then nothing.

[GrabbenD]

How can I use GPUVIS to generate a graph with the right values to debug stutter (@ppascher mentioned that @emersion provided the correct commands in a IRC channel)? For reference, I'm using amdgpu with Mesa

Any help is highly appreciated!

[bhavdeepsingh]

Getting this issue with non steam games on steam deck. Does anyone have an idea of what workaround might work there? Enabling the overlay in game mode doesn’t appear to be a thing

Reddit thread: https://www.reddit.com/r/SteamDeck/s/KZ9lKAOLtw

[sharkautarch]

Getting this issue with non steam games on steam deck. Does anyone have an idea of what workaround might work there? Enabling the overlay in game mode doesn’t appear to be a thing

Reddit thread: https://www.reddit.com/r/SteamDeck/s/KZ9lKAOLtw

Looking at the reddit thread, looks like at some points there's a spike in one of the cpu cores (see time 0:02 of the video, time 0:04)...
Not sure if gamescope is the actual process causing the spike, or if it is the game...
Also maybe the games you're having issues with are just non-vulkan/non-d3d games? which would be significant because normally gamescope is forced to pass frames thru Xwayland for non-vulkan/non-d3d games...

If you can look at the terminal/stdout output of gamescope, you should be able to check if gamescope is able to bypass Xwayland by seeing if it prints lines that start with: [Gamescope WSI]
Not sure how you find the terminal/stdout output of gamescope on the steam deck, ask @Joshua-Ashton if you don't know

If you determine that the problem is with games where gamescope isn't able to bypass Xwayland, then try launching said games with: gamescope <gamescope-params> -- env MESA_LOADER_DRIVER_OVERRIDE=zink <game> which may translate opengl stuff in a game to vulkan, which then allows gamescope to bypass Xwayland

EDIT: if you still end up experiencing stuttering, try building the gs-inline-paintall branch of my fork for now:
I don't think the gs-inline-paintall branch will fix the issue, but it might reduce its severity.
I think that to completely fix the issue, @Joshua-Ashton might need to look into moving the calls to XQueryPointer() to a worker thread or something, since it seems like it can block for around 1ms sometimes (and it is also a relatively big hotspot)

commands to clone and build it:

git clone https://github.com/sharkautarch/gamescope.git
cd gamescope
git checkout gs-inline-paintall
git submodule update --init --recursive
meson setup -Dc_args="-Wno-uninitialized -Wno-maybe-uninitialized" -Dcpp_args="-Wno-uninitialized -Wno-maybe-uninitialized" --reconfigure build
ninja -C build

commands to give it the ability to run it w/ realtime perms:
setcap 'CAP_SYS_NICE=eip' build/src/gamescope

double check the directory where this branch was built (because I'm not sure how compiling and running stuff works on the steam deck):
pwd
copy the output of the above command (I'll refer to it as <path>)

run it like so:

• if you found that you needed to add env MESA_LOADER_DRIVER_OVERRIDE=zink then do so again:
  <path>/build/src/gamescope --rt <gamescope-params> -- env MESA_LOADER_DRIVER_OVERRIDE=zink <game>
• otherwise run:
  <path>/build/src/gamescope --rt <gamescope-params> -- <game>

[yellowsink]

This bug goes away for me when unsetting the LD_PRELOAD env var for the gamescope process (eg steam launch command like env LD_PRELOAD="" gamescope -w 1920 -h 1080 -f -- %command%)

[Etmix]

This bug goes away for me when unsetting the LD_PRELOAD env var for the gamescope process (eg steam launch command like env LD_PRELOAD="" gamescope -w 1920 -h 1080 -f -- %command%)

Thank you! This fixes the issue for me.
Enabling the overlay and adding "-e" did not work.

[Mentalgen]

What's LD_PRELOAD being set to that's causing this then?

[jamesdsparling]

What's LD_PRELOAD being set to that's causing this then?

This is usually set to both the 32 and 64 bit gameoverlayrenderer.so dynamic libraries whether steam overlay is enabled or not.
e.g:
:/persist/home/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so:/persist/home/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so

[jbellionjourdan]

Not sure if it can help, but on my end this issue triggers only when --mangoapp is set.

When the game starts stuttering, hiding mangohud with RALT+F12 helps lowering the issue by ~75% but doesn't make it disappear.

Removing the --mangoapp flag when launching the game makes it completely disappear, i can play for one hour straight or more without any stuttering after the ~20min mark.

[Forge64]

In gamemode.ini file i set renice to 10

10 or -10? Higher nice value means lower priority.

Accodin to this webside (you are wrong) https://gamecrate.com/linux-gaming-boost-your-performance-gamemode/25200 Quote "f you have four or more CPU cores. I like to set the “renice” value at “10” - this will increase the priority of your game’s process, telling Linux to prioritize the game’s CPU time."

For internet reference, the website linked was wrong. Quoting the nice manpage:

Run COMMAND with an adjusted niceness, which affects process scheduling. With no COMMAND, print the current niceness. Niceness values range from -20 (most favorable to the process) to 19 (least favorable to the process).