Some Unreal based games have fps drop when using a 1000Hz polling rate mouse

[sysrq-reisub]

Compatibility Report

• Killing Floor 2 and Paladins
• 232090 and 444090

System Information

• GPU: NVIDIA GTX 1060
• Driver/LLVM version: NVIDIA 418.43
• Kernel version: Linux 5.0.0-7
• Proton version: 3.16.8 Beta

I confirm:

• that I haven't found an existing compatibility report for this game.
• that I have checked whether there are updates for my system available.

Symptoms

The two following games have a similar issue when the mouse polling rate is 1000Hz (competitive gaming mouses)

Basically any mouse movements cause the FPS to drop consistently from (example) 160 fps to 50

The issue disappears in Paladins when the polling rate of the mouse is set to 500Hz, and in Killing Floor 2 becomes less consistent (even if it is still present a bit)
The only common thing between those two games is the game engine

(The situation is even worse when wine without steam proton is not used, in this case the fps drop to 8 fps when there is a mouse movement causing the game to be unplayable)

This is a similar issue to #147 and
#1418

But I do not know if they are the same, they are also saying it's fixed in the latest proton version I'm using but I cannot totally say that for me, the fps especially in paladins are still dropping a lot honestly compared when a 1000Hz mouse is used

systeminfo.txt
steam-444090.log

Reproduction

• Have a 1000Hz mouse
• Open one of those two games and play a game

[Zeioth]

I can replicate this issue in every Wine game, not only unreal engine games. When my mouse use a polling rate of higher than 125-500hz, games show severe stuttering and high frametimes, ONLY when the player move the camera. Everything else seem to run smooth.

Affect the next games

• Sekiro: Polling rate 1000, or 500 cause frametimes spikes and stuttering when the player move the camera. Polling rate 125 fixes the issue.
• Quake Champions: Polling rate 1000 cause frametimes spikes and stuttering when the camera move quickly. Polling rate 125 fixes the issue.
• The witcher 3: Polling rate 1000 cause frametimes spikes when the camera move too fast, but it doesn't produce stuttering. Polling rate 125 fixes the issue.
• Doom 2016: Polling rate 1000 cause frametimes spikes and stuttering when the camera move too fast. Polling rate 125 or 500 fixes the issue.
• Shadow of the tomb raider: Polling rate 1000 cause frametimes spikes and stuttering when the camera move too fast. Polling rate 125 or 500 fixes the issue. (Reported by GameDev1909)

It doesn't affect the next games

• Bioshock: Infinite: Linux native OpenGL game. Runs perfect with any polling rate.
• Portal 1: Linux native OpenGL game. Runs perfect with any polling rate.
• Nier: Automata: Runs perfect with any polling rate. Maybe because the camera move extremely slow.

Other people reporting this bug:

• Ultimate Doom FPS drops with higher mouse polling rate.
• Another ~10 people on discord.

How to reproduce

In the game 'Sekiro', press the physical DPI button of your mouse, and move the camera.

System information

• Distro: Arch antergos XFCE
• Kernel: Linux 5.0.5.arch1-1
• GPU: Ryzen 1700
• Driver: 418.49.4
• Wine version: 4.5-tkg
• DXVK version: Tested with master and 1.0.2, but probably affects all the other versions.
• Mouse: BenQ Zowie EC2-A

Tested with the next wine versions

• 3.16 stating + dxvk 0.61
• 3.18 stating + dxvk 0.61
• 3.20 tkg + dxvk 0.61
• 4.0 + dxvk 0.61
• 4.5 + dxvk 0.61
• 4.5 + dxvk 1.0.2
• esync-staging-pba-3.16 -> This build doesn't present FPS drops when the player move the camera. In sekiro, the camera jiggers instead. All other games run without camera stuttering.

[sysrq-reisub]

For me only in Unreal based games as the title says, some titles like Overwatch run with no problems with a 1000Hz polling rate mouse

[Zeioth]

It's extremely obvious in some games (like Sekiro). For the rest, you need to enable a frametimes GUI to appreciate it.

If you run Overwatch with the env var

DXVK_HUD=frametimes,fps

Most likely you will be able to find the difference between esync-staging-pba-3.16 (Which seems work correctly with most games) and any other build. I haven't tested this specific game though.

[tannisroot]

What Desktop Environment do you use?

[sysrq-reisub]

I personally use GNOME on Ubuntu 19.04

[tannisroot]

Polling rate shouldn't even matter much because Gnome limits it to the refreshrate of your display, see this https://gitlab.gnome.org/GNOME/mutter/merge_requests/168

[Zeioth]

I've run

sudo evhz

As described here. My mouse can achieve 1000hz correctly. Also, let's remember that on my end, the problem only occurs on Wine games. Native games don't stutter with polling rate 1000.

[ghost]

I'm getting this in Borderlands GOTY Enhanced. FPS will be perfectly fine and stable until I start moving the mouse, even just a tiny bit, then it just completely tanks down to 10-20. I'm using Arch, Linux 5.0.5, Ryzen 2700X, and Vega 56 w/ mesa 19.0.1. Proton 4.2-2

Update: Setting my mouse's polling rate to 500Hz solves the issue. I would of course like to use 1000Hz, but for now this makes games playable again.

[aqxa1]

Another issue is that you can't actually change the polling rate if the mouse is connected to a USB3 port, so you're stuck with 1000hz if the mouse requests it. See: https://bugzilla.kernel.org/show_bug.cgi?id=82571

[sysrq-reisub]

My mouse can achieve 1000Hz perfectly too, anyway there are even online testing tools like https://zowie.benq.com/ja/support/mouse-rate-checker.html

[SuperMatt]

I've managed to perform a small test of this. When I am running in X11, my FPS drops as soon as I touch my mouse, from 100 to about 80. Under wayland, the drop is from 100 to about 95.

As I am running my mouse off a USB3 port, I am unable to reduce the polling to see if it makes a difference.

[Zeioth]

I recorded a video:

from 0:00 to 0:20 - Polling rate 1000
from 0::20 to 0:20 - Polling rate 125

Look at the frametimes graph. This is pure wine, I ran the game like:

WINEPREFIX="~/doom" "~/doom/drive_c/Games/Doom 2016/DOOMx64vk.exe"

Edit: Another one on Sekiro.

[Zeioth]

Good news: I've fixed the issue on my end by flashing the last available version of my BIOS (B350 tomahawk arctic). More details here and here.

[ghost]

I'm already on a newer BIOS than the one you screenshotted and still encountering this problem, so unfortunately I don't think this fixes it for everyone.

[Zeioth]

@dougty things you can try:

• The command 'evhz' to make sure your mouse is working at 1000.
• Try with a different distro.
• Try with a different desktop environment.
• Close all the processes in background.
• Check that your USB ports are xhci
• Try your mouse in another computer, with the same game.
• Make sure your CPU is powerful snough
• Try a different motherboard, with the last update of the BIOS (This solved my issue).

I wouldn't be surprised at all if some motherboard manufacturers don't pay enough attention to the way 1000hz mices perform on their devices. Specially since in native games, the issue is not even noticeable.

[ghost]

@Zeioth Thanks, but I'm certain this is a wine problem. 1000Hz works fine in native Linux games and on Windows via dual boot, so it's not a problem with the hardware. I also have a newer MSI motherboard with a newer BIOS, so that isn't the problem either. I'm glad this resolved the issue for you, but I'm certain there is something in wine/Proton that can be done to fix it properly for everyone.

[tgharib]

Does the issue still occur with esync disabled?

[SuperMatt]

I have just tried Quake Champions with and without esync disabled and the results are identical. As soon as I touch the mouse, the framerate drops. The very moment the hand comes off the mouse, the FPS returns to normal.

[Zeioth]

@tgharib Yes, it's wasn't related with esync on my end.
@SuperMatt Please try to flash the last version of your motherboard bios. That eliminated the stuttering associated with mouse polling rate 1000 on my end.

[SuperMatt]

@Zeioth I have indeed flashed my latest bios version, and it has made no difference.

[momumi]

Has anyone using an Intel CPU encountered this bug? I have a Ryzen 3900X, and it seems like everyone else who's reporting this bug also has a Ryzen CPU.

I've tried various versions of wine/proton and it seems like the only thing that has helped so far is using wine-git from the AUR. Here's my /etc/makepkg.conf compile flags that I used when I built wine-git (git hash: a63a98c388):

CPPFLAGS="-D_FORTIFY_SOURCE=2"
CFLAGS="-march=native -O2 -pipe -fno-plt"
CXXFLAGS="-march=native -O2 -pipe -fno-plt"
LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now"

I'm not 100% sure that this fixed the bug since it only triggers for me after playing for >=1hr. However, I managed to play The Witness for about 3 hours which is the longest I've gone with no stuttering.

This bug seems to trigger slightly differently for me than everyone else who has posted already, so I'll list how it behaves for me:

• Games start of out running smoothly, but after playing for about an hour they start stuttering. The stuttering starts suddenly after the 1 hour mark, and it doesn't seem to get better or worse after that. The only way to fix it is to restart the game.
• Both the keyboard and mouse produce stuttering.
• It doesn't matter what the game is rendering, it can be a static image and moving the mouse will cause the frame rate to drop dramatically (130fps -> 60fps). When the mouse stops moving, the frame rate will return to normal
• No Native Linux games are affected. All wine games seem to be affected.
• It doesn't matter what keyboard or mouse I use. Even using xdotool to move the mouse causes stuttering with no keyboard or mouse plugged in.
• For stuttering caused by the keyboard, it seems that releasing a key fixes it. For example, holding w will cause stuttering, however pressing and releasing any other key will stop the stuttering while the w key is still held. If multiple keys are pressed at once, then only releasing the most recently pressed key will stop the stuttering.
• system information

[franksouza183]

@momumi I have a similar problem, I get mouse stuttering after 1 hr in proton, in my case with the 7 Days to Die game, including the native version (with vulkan support enabled). I suspect it could be a issue in vulkan. Tested with RADV and AMDVLK, no difference. The native opengl version does not exist this problem, except the very inferior performance. This also happens with DOOM 2016 when using vulkan. My card is Radeon R9 380, amdgpu driver.

[Sanaki]

Take a look at #3316. That one seems more likely in your case.

[scuba10steve]

@momumi, I can say that I've started noticing a very similar issue when playing things such as Skyrim: SE, and Halo MCC. I'm running an Intel cpu, specifically an i5 6600k, I'm not entirely certain it would be limited to just Ryzen CPU's. I first thought it was an issue with my CPU starting to show it's age, but any native games seem to run ok. But it maxes out my CPU and it seems to be related to mouse movement.

[maxanier]

I can confirm this issue and workaround for Just Cause 3 (based on the Avalanche Engine, not Unreal I think). Game lags/stutters as soon as I move the mouse. Switching to a different mouse (lower refresh rate) fixes this.
(Also using ryzen, don't know if this is related)
If anyone got an idea how to fix the issue, I am happy to test it.

[TRPB]

I just wanted to say that the same issue affects Jedi Knight: Dark Forces 2, there is a huge amount of stutter when moving the mouse at high polling rates.

Does anyone know if there's a way to set mousepoll per application? I can't unload the usbhid module as I guess other stuff is using it so have to reboot.

edit: in addition, proton 3.7 does not have this issue so it's fairly recent. I didn't try every version between that one and the latest but 3.7 works fine!

[TRPB]

Some additional testing. Forcing the following proton versions gives these results:

3.7-8: No issue
4.11-13: No issue
5.0-10: Mouse polling issue

I'm not sure what releases there were between 4.11 and 5.0, but that's where the issue is.

[jazztickets]

The Hunter: Call of the Wild is also affected by this bug (Apex Engine).

EDIT: As of October 2023 I no longer have the problem with this game.

[nettnikl]

Just Cause 3 seems to be also affected.

Thanks to the contributed answers here, i found a workaround for my case, it might be helpful for your situation too:
I installed evhz-git, and checked different settings for my mouse, as i own one of those gaming mouses, the Hero 502 (which is actually quite common, so i hope you guys have the same luck). At one of the dpi settings you can select via the hardware dpi button, the polling rate is actually 500 instead of 1000 - and the lag is gone!

[parkerlreed]

Just Cause 2 as well on Proton Experimental. #670 (comment)

[Marek-Svoboda]

Compiling a kernel with a a timer frequency proportionate or equal to the mouse's polling rate seems to mitigate the impact of the issue.

[Etaash-mathamsetty]

I found a related wine mr: https://gitlab.winehq.org/wine/wine/-/merge_requests/825
seems to be ClipCursor causing the issue, unfortunately that MR probably won't get merged

[BenA0]

Compiling a kernel with a a timer frequency proportionate or equal to the mouse's polling rate seems to mitigate the impact of the issue.

Game: Killing Floor 2

Tested with a compiled identical kernel only difference being 300HZ vs 1000HZ, fps dips when moving cursor is still present, although reduced my fps drop by 5% (from 36% less fps to 29% less fps, which in my case was 280 FPS when not touching the mouse, reduced to 180 FPS(300HZ kernel) / 200FPS(1000HZ kernel) when moving around the mouse )

Reproducible on:
wayland, x11
kde-plasma, sway
300HZ-kernel, 1000HZ-kernel
proton 7.0.4, proton experimental, proton-GE-custom

It seems polling rate of 125/250 either does not reduce fps, or the reduction is negligible to the point of not being noticeable.

Hopefully the root cause is found and fixed, until then im stuck having to play on windows drive

[UndyingSisyphos]

I know this thread is old but I wanted to give my humble opinion on the topic.
It's unlikely that the issue is caused by proton because I have experienced it myself on Windows too. I can confirm that the polling rate is the cause since lowering it via software fixes it. Proton may make the problem worse and easier to reproduce but it's unlikely that it's the root cause.
The only thing I can think of is that the Engine itself may be the root cause but I have albsolutely no idea how it could be fixed.
The problem in my case presented itself randomly, no updates were done in the time it passed between when it was behaving normally and when it started having the problem, so it's pretty safe to assume that neither the game version nor the graphics driver have anything to do with it.
I have tried checking the files from Steam and re-installing the entire game but neither of the two did anything to help.
The root of the problem is surely in the enigne but something else is triggering it since I never had this issue before. And it seems probable that proton may cause something that triggers it more easily and more often than it normally occurs on native windows machines.