ValveSoftware / Proton

Compatibility tool for Steam Play based on Wine and additional components
Other
24.3k stars 1.06k forks source link

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

Open sysrq-reisub opened 5 years ago

sysrq-reisub commented 5 years ago

Compatibility Report

System Information

I confirm:

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 https://github.com/ValveSoftware/Proton/issues/147 and https://github.com/ValveSoftware/Proton/issues/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

Zeioth commented 5 years ago

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

It doesn't affect the next games

Other people reporting this bug:

How to reproduce

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

System information

Tested with the next wine versions

sysrq-reisub commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

What Desktop Environment do you use?

sysrq-reisub commented 5 years ago

I personally use GNOME on Ubuntu 19.04

tannisroot commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@DougTy things you can try:

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 commented 5 years ago

@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 commented 5 years ago

Does the issue still occur with esync disabled?

SuperMatt commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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

momumi commented 4 years ago

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:

franksouza183 commented 4 years ago

@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 commented 4 years ago

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

scuba10steve commented 4 years ago

@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 commented 4 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

Just Cause 2 as well on Proton Experimental. https://github.com/ValveSoftware/Proton/issues/670#issuecomment-1159623640

Marek-Svoboda commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 1 year ago

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.