Source-1-Games
Source-1-Games copied to clipboard
ValveSoftware
[TF2] [Linux] [Vulkan/DXVK] Games stutter on keyboard/mouse input after playing for some time
System Information
Fedora Silverblue, Steam Flatpak Intel Core i5-1240P Mesa Intel(R) Graphics (ADL GT2) Mesa 24.0.5 (git-7737614720) GNOME 45.5 Wayland
Problem
Greetings! Just as the title says, I'm getting an incredibly strange stuttering issue when playing certain Source 1 games using built-in DXVK. I'll use TF2 after the latest 64-bit update as an example, but I have also observed this behavior in L4D2 and Portal 2.
This bug happens seemingly at a random time after a sustained play session. It doesn't seem to happen on any particular map or with any particular class. The stuttering only happens whenever I move my mouse or give any keyboard input to the game; with no inputs, frame pacing behaves normally, with little/no stuttering.
I'm running TF2 with mastercomfig 9.10.2 and with the following arguments:
mangohud %command% -novid -nojoy -nosteamcontroller -nohltv -particles 1 -precachefontchars -noquicktime
The bug report is from my laptop, but I also remember having a similar problem on my desktop, which has an Intel Coffee Lake CPU and a Radeon 6600XT, running Fedora Kinoite with a similar software stack. Both machines use Wayland by default.
Attached is a clipped video of the issue. Note how frame pacing is incredibly unstable whenever I am giving inputs to the game (i.e. normal gameplay, moving the camera, moving my player, moving the cursor, etc.), but becomes stable when I stop giving any inputs.
Hopefully this issue can be addressed soon, since it is the only blocker I have encountered to a perfect DXVK-native experience. Thanks in advance!
https://github.com/ValveSoftware/Source-1-Games/assets/160363779/edd133a9-7232-40f4-a179-5c302049258e
I'm not sure I agree. The stuttering there is present from game launch (and not after a delay), and seems to be some sort of context 'refreshing' issue, as mangohud keeps resetting itself in their recordings, and doesn't seem to be input related. Regardless, I'll try out the launch options they found and see if it makes any difference.
Tested with -noborder and -windowed and using DXVK HUD instead of MangoHud. Same results, at around the same time (although I haven't properly measured it out yet).
One interesting observation I've made is that the lagspike pattern when holding a key looks similar to 'delayed' inputs on a text editor (i.e. one character gets typed, there's a short delay, then the characters start repeating)
Attached is a screenshot of said 'delay' phenomenon. Note the 'bump', then the sequential lagspikes.
An interesting development: turning on the Steam In-Game overlay seems to negate the issue. I played a session for almost 2 hours without any issues. I got the idea from #5785, where it seems to have fixed that particular issue. I'll retest tomorrow switching between overlay toggles and see if it really fixes it.
I believe this should still be counted as a regression, however; this behavior never (to my memory) presented itself in any game using ToGL, only DXVK-native...
Having the same issue. Game runs well for about 15 minutes and then suddenly starts to stutter at regular, rapid intervals. However, standing still or watching the spectator camera results in a smoothly-running game, making me think, as well, that this is input-related.
After some more testing, the in-game overlay does indeed mitigate the problem. This works as a fix for now, although I still believe this is a regression.
Additionally, I took some accurate(ish) time measurements between game launch and when the stutter begins.
MangoHud, no In-Game overlay, 1080p @ 75Hz fullscreen:
37:44 - 2264 seconds
39:22 - 2362 seconds
42:25 - 2545 seconds
38:07 - 2287 seconds
TOTAL AVG: 39 minutes, 24 seconds - 2364.5 seconds
Not sure if this is relevant to the bug-hunting, but thought it was interesting how the timing is more or less consistent, about 40 minutes or so. This may be machine-dependent, though...
I'm also seeing this issue. The timing seems about right. The first occurrence was right after a map change, the second was right after a round ended, overall twice in around 90 minutes. I had to restart the game to clear it out. The video above does not really convey the issue.
Moving the mouse jumps maybe 10 pixels at a time, then stops, then jumps 10 more when turning, almost like its snapping to every X pixels, instead of being a smooth motion. Moving forward is smooth, I want to say that strafing does this as well.
Mint 21.3
It's weird that enabling the overlay fixes it (I always disable it out of habit on all systems), I would have never thought this of all things would work, thank you @stellarkookies for pointing towards the workaround!
I do wonder why this happens though, and why only on the keyboard + mouse combo. The fact that it triggers after some time may suggest some kind of KMB input buffer getting overfilled and the game not being able to handle it or something along those lines.
PS: have you tried running Source games (DXVK) in gamescope to see if it's an issue there?
I'm having the same problem, decided not to make a thread or anything because I'm not sure if it's a duplicate.
I'm on Ubuntu using i3 and xorg. TF2 is running in Vulkan, selecting "Legacy OpenGL" doesn't fix it. Running with -noborder doesn't fix it. Usually occurs about 1 hour and 30 minutes after launching the game and seems to happen for no real reason. Only way to fix is to restart the game. Here are my launch arguments:
-novid -vulkan -console -noborder
Here's my neofetch:
OS: Ubuntu 20.04.6 LTS x86_64
Host: B450M-HDV R4.0
Kernel: 6.5.5-060505-generic
Uptime: 10 hours
Packages: 3119 (dpkg), 8 (flatpak)
Shell: bash 5.0.17
Resolution: 1920x1080
WM: i3
Theme: Adwaita-dark [GTK2/3]
Icons: Papirus-Dark [GTK2/3]
Terminal: konsole
CPU: AMD Ryzen 5 3400G (8) @ 3.700GHz
GPU: AMD ATI 08:00.0 Picasso
Memory: 6858MiB / 13884MiB
Here's a video: stuttering.webm
It seems to stutter when moving the mouse or keyboard and I don't know how to fix this. I am not using MangoHUD or anything like that, just stock TF2 with BUDHUD. The 64 bit update is really great, but I feel like it's causing this strange issue...
Replying to https://github.com/ValveSoftware/Source-1-Games/issues/5767#issuecomment-2094802453
Turning on the steam overlay fixed it for me.
Turning on the steam overlay fixed it for me.
Didn't fixed it for me, I still have the stutters after around 30 minutes of gameplay
My neofetch :
OS : Arch Linux
Kernel : 6.9.2-arch1-1
WM : BSPWM
CPU : Intel i5-10300H
GPU : GeForce RTX 3060 Mobile
RAM : 24 GiB
Steam installed from Package manager
My launch options when running the game :
prime-run mangohud %command% -windowed
I'll try running without the mangohud and see if it still happens too (I don't have the Steam Overlay enabled in general)
EDIT : Trying to remove mangohud didn't fixed the issue
i have same problem linux mint mate enabling steam overlay fixes it for me but its strange
Another linux mint player down there. Stutters seem to be separate from in-game 'net_graph' fps counters. Toggling steam overlay on-off doesn't do anything with it. Not using mangohud.
Launch options:
-w 1024 -h 768 -force_device_id 67DF -force_vendor_id 1002 -vulkan -novid -nojoy -nosteamcontroller -nohltv -particles 1 -precachefontchars -noforcemaccel -noforcemspd
Neofetch:
OS: Linux Mint 21.3 x86_64
Kernel: 5.15.0-112-generic
Resolution: 1920x1080
DE: Cinnamon 6.0.4
Terminal: gnome-terminal
CPU: Intel i3-8100 (4) @ 3.600GHz
GPU: AMD ATI Radeon RX 470/480/570/5
Memory: 3639MiB / 7752MiB
Another linux mint player Steam overlay was already on and made no difference, also tried changing mouse polling rate, disabling desktop composition, and closing all other applications. Have not experienced this phenomenon in other games but I have not played source games recently.
Stuttering begins after ~15-30 minutes when moving the mouse or pressing any keyboard buttons, this is visible on mangohud. Each keypress creates one individual spike but any mouse mouse movement causes an excess of spikes and the experience is unplayable slideshow-like stuttering as the camera jumps greatly between each frame.
using mastercomfig 9.10.1
Launch options:
gamemoderun MANGOHUD=1 %command% -nosplash -novid -nojoy -nosteamcontroller -nohltv -particles 1 -precachefontchars -noquicktime -gl_nv_bindless_texturing -NoQueuedPacketThread -gl_enablesamplerobjects -windowed
Neofetch:
OS: Linux Mint 21.1 x86_64
Host: Z790 GAMING X AX
Kernel: 5.15.0-58-generic
Resolution: 1920x1080 (240hz), 2560x1440 (60hz)
DE: Xfce 4.16
WM: Xfwm4
CPU: 13th Gen Intel i7-13700K (24) @ 4.100GHz
GPU: NVIDIA 01:00.0 NVIDIA Corporation Device 2782
(NVIDIA GeForce RTX 4070 Ti/PCIe/SSE2 - 4.6.0 NVIDIA 535.86.05)
Memory: 5234MiB / 31934MiB
Same issue on Debian 12.5, Mesa 22.3.6, Ryzen 5000 Series CPU, Navi 23 GPU. Stuttering whenever there's keyboard or mouse input after ~15-30 minutes of gameplay. Issue doesn't occur on OpenGL.
Disabling steam overlay doesn't fix issue
Update: Have experienced the issue on OpenGL for the first time since posting. It can still still occur, but it's just much less prevalent
Update 2: ENABLING Steam overlay has seemingly fixed the issue so far on Vulkan....
Arch Linux, i9 14900KF /w microcode, RTX 4090 /w proprietary drivers, X.Org, XFCE4, Steam Beta, I don't know what else could be, or should have been, a factor.
Turning ON Steam Overlay, seems to have fixed my problem. Maybe speaking too soon, but at the very least, I can play over an hour straight now without problems. VERY frustrating for that to be the solution, of all the things I have tried. Thank you for sharing.
Arch Linux, i9 14900KF /w microcode, RTX 4090 /w proprietary drivers, X.Org, XFCE4, Steam Beta, I don't know what else could be, or should have been, a factor.
Turning ON Steam Overlay, seems to have fixed my problem. Maybe speaking too soon, but at the very least, I can play over an hour straight now without problems. VERY frustrating for that to be the solution, of all the things I have tried. Thank you for sharing.
Yeah, turning on Steam Overlay fixed it for me too, dunno how or why
I'm also reporting that I've encountered the same issue in a manifestation essentially similar to everyone else's. I did note that the time until stuttering occurred for one desktop host was consistent, taking ~33 minutes +/- 1 minute to then suddenly manifest after launching the game without having the Steam overlay enabled. Like most others, enabling the overlay masked the issue from occurring, at least, within the aforementioned time while the game was running.
Same issue. 12900K / RTX 4090 (proprietary) / sway wm (wayland) / arch.
Usually takes more than 30 mins though, generally closer to 1.5-2hrs. Maybe having more vram allows it to last longer if its some sort of mem leak?
The issue persists for me, having the Steam Overlay enabled does NOT fix it for me.
Running on Legacy does not cause this issue.
Using Arch Linux
Suspicious that it might be a memory leak
I have the exact same issue, nothing above fixed it. And I don't even have a compositor on, so kwin issue is out of question.
