[TF2] [Linux] [Vulkan/DXVK] Games stutter on keyboard/mouse input after playing for some time

[stellarkookies]

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

[Tiagoquix]

Seems to be a duplicate of #5630

[stellarkookies]

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.

[ZeroYamaoka]

Try to run game in -noborder

[stellarkookies]

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.

[stellarkookies]

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...

[yipa33]

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.

[stellarkookies]

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...

[rtaft]

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

[rtaft]

m_rawinput 0 did not help

[fililip]

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?

[Lachrymogenic]

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...

[rtaft]

Replying to https://github.com/ValveSoftware/Source-1-Games/issues/5767#issuecomment-2094802453

Turning on the steam overlay fixed it for me.

[AzhamProdLive]

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

[baaannnaaannn]

i have same problem linux mint mate enabling steam overlay fixes it for me but its strange

[nk167]

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

[3r1]

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

[0CCULTIST]

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....

[Skincanvas]

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.

[AzhamProdLive]

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

[tulser]

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.

[leighmacdonald]

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?

[notkiniro]

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

[pmku]

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.

[purplebar0]

From a short amount of testing (~40 minutes), enabling the Steam overlay seemed to fix it for me. I will update the post otherwise.

It is clear that some library loaded by the game, or the game itself is trying to interact with the Steam overlay even if it is not present (hint: SteamNoOverlayUI environment variable set to 1, but it is possible it crashes too).

Major issue, any mouse or keyboard event that would be picked up by the overlay causes a delay and the game becomes unplayable, and I only observed it happening in this game. Please look into this.

Artix Linux, x11

https://github.com/ValveSoftware/Source-1-Games/issues/5767#issuecomment-2067529637

Maybe something expects that the overlay is in the foreground, or is trying to open the overlay?

[some-username-here1]

I'm having a similar issue as well, but instead of it being constant, it only happens whenever I send any type of input regardless of mouse or keyboard

[sneakernets]

This is happening on the steam deck now! Ran into it an hour into playing. Never seen this before until today, and now I've seen it happen 3 times in a row.

[i-likegithub]

I've also encountered this issue and have been trying to find a solution for months now. I've been using OpenGL Legacy since because of it. I was thinking it might be because I'm using an integrated gpu (Intel HD 630) and thought that it doesn't support vulkan; but after finding this post and seeing the replies that enabling steam overlay fixes it, I'm now even more confused lol. I use Arch btw.

[baaannnaaannn]

I'm having a similar issue as well, but instead of it being constant, it only happens whenever I send any type of input regardless of mouse or keyboard

For me too

[jonramster]

Same here Ubuntu 24.04 LTS Framework Laptop 13 AMD Ryzen 7040Series AMD Ryzen™ 5 7640U w/ Radeon™ 760M Graphics × 12 32.0 GiB

I use OpenGL as Vulkan performance is terrible for unclear reason

[Kangaroux]

EDIT: Steam overlay is enabled though I can't open it with the hotkey and I don't see the little notification when launching a game saying the overlay is available. The overlay is working after I disabled and re-enabled it.

EDIT 2: With the overlay working I'm not experiencing the stuttering issues anymore.

I'm also experiencing this issue in Deadlock and Baldur's Gate 3. I've tried both Xorg and Wayland. When it happens in Deadlock the console starts flooding with warnings about SDL input events taking ~50ms to process.

I don't think it's related to Vulkan or Proton since Deadlock is running natively and using DX11. BG3 is using Vulkan. It looks like Deadlock is using DXVK, so ultimately still using Vulkan under the hood.

This has started happening in the past week for me, here's my apt history if perhaps that's relevant.

Start-Date: 2024-11-03  18:02:38
Commandline: apt upgrade -y
Requested-By: jessie (1000)
Upgrade: firefox-locale-ar:amd64 (1:131.0.3~1728926590~22.04~7d07882, 1:132.0~1730223411~22.04~3341e9c), firefox-locale-de:amd64 (1:131.0.3~1728926590~22.04~7d07882, 1:132.0~1730223411~22.04~3341e9c), firefox-locale-en:amd64 (1:131.0.3~1728926590~22.04~7d07882, 1:132.0~1730223411~22.04~3341e9c), firefox-locale-es:amd64 (1:131.0.3~1728926590~22.04~7d07882, 1:132.0~1730223411~22.04~3341e9c), firefox-locale-fr:amd64 (1:131.0.3~1728926590~22.04~7d07882, 1:132.0~1730223411~22.04~3341e9c), firefox-locale-it:amd64 (1:131.0.3~1728926590~22.04~7d07882, 1:132.0~1730223411~22.04~3341e9c), firefox-locale-ja:amd64 (1:131.0.3~1728926590~22.04~7d07882, 1:132.0~1730223411~22.04~3341e9c), firefox-locale-pt:amd64 (1:131.0.3~1728926590~22.04~7d07882, 1:132.0~1730223411~22.04~3341e9c), firefox-locale-ru:amd64 (1:131.0.3~1728926590~22.04~7d07882, 1:132.0~1730223411~22.04~3341e9c), gnome-control-center-faces:amd64 (1:41.7-0ubuntu0.22.04.9pop0~1727959659~22.04~a1bcd6c, 1:41.7-0ubuntu0.22.04.9pop0~1729817737~22.04~168857a), xserver-xorg-core:amd64 (2:21.1.4-2ubuntu1.7~22.04.11, 2:21.1.4-2ubuntu1.7~22.04.12), libarchive13:amd64 (3.6.0-1ubuntu1.2, 3.6.0-1ubuntu1.3), system76-power:amd64 (1.2.1~1725653641~22.04~290805e, 1.2.2~1729703462~22.04~b0edf27), python3-pip-whl:amd64 (22.0.2+dfsg-1ubuntu0.4, 22.0.2+dfsg-1ubuntu0.5), python3-urllib3:amd64 (1.26.5-1~exp1ubuntu0.1, 1.26.5-1~exp1ubuntu0.2), xserver-xorg-legacy:amd64 (2:21.1.4-2ubuntu1.7~22.04.11, 2:21.1.4-2ubuntu1.7~22.04.12), firefox:amd64 (1:131.0.3~1728926590~22.04~7d07882, 1:132.0~1730223411~22.04~3341e9c), xserver-common:amd64 (2:21.1.4-2ubuntu1.7~22.04.11, 2:21.1.4-2ubuntu1.7~22.04.12), update-manager-core:amd64 (1.0.0~1729010520~22.04~6ecadbb, 1.0.0~1730209379~22.04~12dbfd9), gnome-control-center-data:amd64 (1:41.7-0ubuntu0.22.04.9pop0~1727959659~22.04~a1bcd6c, 1:41.7-0ubuntu0.22.04.9pop0~1729817737~22.04~168857a), python3-pip:amd64 (22.0.2+dfsg-1ubuntu0.4, 22.0.2+dfsg-1ubuntu0.5), xserver-xephyr:amd64 (2:21.1.4-2ubuntu1.7~22.04.11, 2:21.1.4-2ubuntu1.7~22.04.12), gnome-control-center:amd64 (1:41.7-0ubuntu0.22.04.9pop0~1727959659~22.04~a1bcd6c, 1:41.7-0ubuntu0.22.04.9pop0~1729817737~22.04~168857a), code:amd64 (1.94.2-1728494015, 1.95.1-1730355339), ubuntu-release-upgrader-core:amd64 (1.0.0~1729010520~22.04~6ecadbb, 1.0.0~1730209379~22.04~12dbfd9), firefox-locale-zh-hans:amd64 (1:131.0.3~1728926590~22.04~7d07882, 1:132.0~1730223411~22.04~3341e9c), firefox-locale-zh-hant:amd64 (1:131.0.3~1728926590~22.04~7d07882, 1:132.0~1730223411~22.04~3341e9c)
End-Date: 2024-11-03  18:03:28

Start-Date: 2024-11-03  18:04:57
Commandline: apt install nvtop
Requested-By: jessie (1000)
Install: nvtop:amd64 (3.0.0-0~jammy1.0)
End-Date: 2024-11-03  18:04:58

Start-Date: 2024-11-04  22:17:50
Commandline: apt install -y inxi
Requested-By: jessie (1000)
Install: inxi:amd64 (3.3.13-1-1)
End-Date: 2024-11-04  22:17:51

### NOTE: these packages are proton-vpn, not proton (wine). 

Start-Date: 2024-11-04  22:23:51
Commandline: apt upgrade -y
Requested-By: jessie (1000)
Upgrade: python3-proton-vpn-api-core:amd64 (0.35.5, 0.36.4), discord:amd64 (0.0.72, 0.0.73), python3-proton-vpn-network-manager:amd64 (0.9.1, 0.9.4), libopenjp2-7:amd64 (2.4.0-6ubuntu0.1, 2.4.0-6ubuntu0.2), libopenjp2-7:i386 (2.4.0-6ubuntu0.1, 2.4.0-6ubuntu0.2), proton-vpn-gtk-app:amd64 (4.6.0, 4.7.1), python3-proton-vpn-local-agent:amd64 (1.0.0, 1.1.3)
End-Date: 2024-11-04  22:23:54

Start-Date: 2024-11-04  22:23:59
Commandline: apt autoremove -y
Requested-By: jessie (1000)
Remove: amdgpu-dkms-firmware:amd64 (1:6.8.5.60202-2041575.24.04)
End-Date: 2024-11-04  22:23:59

Start-Date: 2024-11-06  19:05:42
Commandline: apt install -y mangohud
Requested-By: jessie (1000)
Install: mangohud:amd64 (0.6.5-2)
End-Date: 2024-11-06  19:05:42

Easier to read summary:

Upgraded:
- code:amd64
- discord:amd64
- firefox-locale-ar:amd64
- firefox-locale-de:amd64
- firefox-locale-en:amd64
- firefox-locale-es:amd64
- firefox-locale-fr:amd64
- firefox-locale-it:amd64
- firefox-locale-ja:amd64
- firefox-locale-pt:amd64
- firefox-locale-ru:amd64
- firefox-locale-zh-hans:amd64
- firefox-locale-zh-hant:amd64
- firefox:amd64
- gnome-control-center-data:amd64
- gnome-control-center-faces:amd64
- gnome-control-center:amd64
- libarchive13:amd64
- libopenjp2-7:amd64
- libopenjp2-7:i386
- proton-vpn-gtk-app:amd64
- python3-pip-whl:amd64
- python3-pip:amd64
- python3-proton-vpn-api-core:amd64
- python3-proton-vpn-local-agent:amd64
- python3-proton-vpn-network-manager:amd64
- python3-urllib3:amd64
- system76-power:amd64
- ubuntu-release-upgrader-core:amd64
- update-manager-core:amd64
- xserver-common:amd64
- xserver-xephyr:amd64
- xserver-xorg-core:amd64
- xserver-xorg-legacy:amd64

Installed:
- inxi:amd64
- mangohud:amd64
- nvtop:amd64

Removed:
- amdgpu-dkms-firmware:amd64

$ neofetch
OS: Pop!_OS 22.04 LTS x86_64 
Kernel: 6.9.3-76060903-generic 
Uptime: 3 days, 1 hour, 35 mins 
Packages: 2901 (dpkg), 36 (flatpak), 8 (snap) 
Shell: zsh 5.8.1 
Resolution: 2560x1440 
DE: GNOME 42.9 
WM: Mutter 
WM Theme: Pop 
Theme: Pop-dark [GTK2/3] 
Icons: elementary-xfce-dark [GTK2/3] 
Terminal: gnome-terminal 
CPU: AMD Ryzen 7 5700X3D (16) @ 3.000GHz 
GPU: AMD ATI Radeon RX 6700/6700 XT / 6800M 
Memory: 14308MiB / 32006MiB

[Kangaroux]

The steam overlay may incorrectly appear as enabled in the settings. Make sure to disable and re-enable it. You should see the steam overlay notification when you start a game. There is an overlay toggle both in the steam settings as well as each game (right click > properties), so I would try doing it for both.

[Recipient4626]

This just happened to me, games start to stutter on keyboard / mouse inputs after running some time.

Happened on Arch Linux, KDE Plasma Wayland, KDE X11, Hyprland, with or without gamescope, proton 9.0, 8.0, proton-GE 9.18, on NARAKA: BLADEPOINT and Age of Empires IV. It started to happen within a week ago or so on my end.

After NARAKA started to stutter, I immediately opened 7 Days To Die (proton 9.0) and it didn't stutter there so I originally thought it was NARAKA specific, but it seems to be something with proton/wine/steam.

I run FFXIV from lutris; if my memory is correct, FFXIV didn't stutter when NARAKA started to stutter, and it is run on UMU-Proton 9.0, so it could be related to steam itself.

Haven't tried turning on steam overlay yet.

If FFXIV starts to stutter as well, I will come back and update.

[elkabyliano]

I have the same issue on Deadlock since the last patch. I am on linux Linux Operating System: Linux Mint 22
Kernel: Linux 6.8.0-48-generic

but several others players on windows have the same issue. I have enabled the steam overlay but same issue. Where can I post it on github?

[Wad67]

Can confirm this has started occurring for me too

Appears to be everything on proton for me, usually about 30 minutes in Routine 50ms cpu time on every input, baseline 6-7ms

Linux Mint 22 x86_64

6.8.0-49-generic

Xfce 4.18, compositor disabled