Proton Experimental: Multiple games experience input lag / input event loss #4571
Comments
Games that ship their own vulkan-1 will be broken with your VR wrappers.
|
Thanks for the report, are you using rtkit-daemon or configured ulimit so that the new priority mechanism work? Could you try with that disabled, by uninstalling rtkit-daemon and have 0 RLIMIT_NICE? Same question with fsync / futex2, it would be nice if we can narrow this down a bit more. |
|
I'm guessing this could be related to ValveSoftware/wine@287781d#commitcomment-45900927, or some similar issue with driver processes that don't have any specific priority set and could so lag behind the game threads. |
|
Yes, I'm actually using rtkit-daemon and configured ulimit for -15. I used similar patches in my custom-baked Proton back in version 3.x and 4.x but didn't experience such behavior there. Actually, I had one patch that increased priority of the input-related threads/drivers - not sure how wine (or Proton for that matter) changed since then. I'm also using a fsync / futex2 patched kernel (including MuQSS) but since multiple games show problems starting with futex2, I disabled it globally by a session environment variable. |
|
BTW: I recently added a patchset for bcache which removes a system_wq workqueue congestion from the kernel, and it looks like this lag is no longer an issue in Wine/Proton. But it shows there's still a potential to get this which may somehow be related to the kernel event handler (system_wq): https://lore.kernel.org/linux-bcache/CAC2ZOYtrrOXD35ZWLer8R8n1dcyqGi_dipHp+y1JNt_eaue_9A@mail.gmail.com/T/#t This kernel patch series is proposed for inclusion in 5.12 with backports back to 5.4+. I'm currently applying that on top of my 5.10 kernel. |
|
These are my input driver patches I added to Proton: I added these because I was seeing slow hotplug input device detection in demanding games, and missed input events (back when I played Tomb Raider, the trigger button often didn't engage the bow). It did improve things but didn't fix it. In the aftermath, that may have also been an instance of the system_wq congestion which has been introduced into bcache in 2014. |
|
It will be useful to have a dedicated Proton Experimental thread for to report regressions. |
Ignore that, it auto-spawns on dbus calls. Usually after system boot it had been running because some process triggered it - seems to happen no longer and thus I assumed it wasn't working at all. But looking back at older logs, it spawns when I play Proton games. |
|
@rbernon Do you know if it would be enough to make all winedevice.exe threads highest priority for an artificial test? Actually, I did that (alt+tab out of the game, run I'm not sure why that happens: Sometimes it just works, sometime the problem persists until I eventually reboot the system. While the game is running (and using CPU), I ran I also disabled vsync and triple buffering to verify that I'm not just seeing delayed screen content. The issue is currently different to why I initially reported it. I think my initial issue is actually some Bluetooth problem with my Elite 2 controller, I don't see that (delays of multiple seconds, input event loss) happen with my Xbox Series X controller. But there's still a constant lag of what feels like 200ms across all games I'm testing. In a fast paced shooter this feels like running around while drunk - somewhat funny but not very useful without actually being drunk. ;-) Enabling futex2 only seems to make that worse (but the whole implementation seems to not work correctly for me, I get audio-dropouts and inconsistent frame rates when using futex2, so that's probably a different issue). Mouse and keyboard input experiences the same lag, so it's not specific to the driver. |
|
It looks like vkd3d games don't experience this issue... |
|
Mouse and keyboard input is usually received by the application process itself, in the thread(s) that call Peek/GetMessage, and then there's a roundtrip to wineserver. The winedevice processes are only receiving gamepad input so far. One exception for mouse input though, if the game uses rawinput, then some of the input is received in explorer.exe, which pushes it to wineserver, which in turn dispatches to the right application threads. In this case it will also depend on the application thread (possibly dinput thread if the game uses dinput) calling Peek/GetMessage. Among these I only see explorer.exe, wineserver and the dinput thread for which increasing priority could make a difference. I don't think we should change the priority of the application threads themselves, but if they have a low priority and for some reason don't call Peek/GetMessage often enough, then it could be an issue. |
|
Ah so I didn't re-read the initial message and I see now this was about gamepad input. So in this case the flow is indeed coming from winedevice.exe, which replies to (wine) ioctls, or pushes input messages to wineserver. In all cases there's wineserver involved in the middle, and ioctls / device read (used by xinput I think) is currently the worst as it involves multiple roundtrips from the application to wineserver and from winedevice.exe to wineserver. |
|
Is this true for SDL patched Proton? As far as I could track it, winebus.sys directly interfaces with SDL, but I'm not sure how that integrates with xinput. Maybe I have to get back into some Proton development and testing patches... From your description, whatever winebus.sys does, lives in a winedevice.exe thread - and passing information between the game and winebus.sys has to go through wineserver? This sounds somewhat crazy to do. I can just guess this is about abstraction across different platforms but Proton is quite specifically for Windows games on Linux. Couldn't we just call from xinput right into the Linux APIs? |
Yes, that's correct.
It possibly could for simple input but I think it would fail to work correctly in some cases, or be much more difficult to implement, for all the Windows internal interactions to work properly and consistently across processes. It's clearly not ideal, and especially with the current overhead of things like reading HID reports from device files, but there are ways to make it better, it only needs time and effort to implement the required mechanisms. |
|
I wonder if things could be improved if wineserver wouldn't be strictly single threaded: It could implement different threads to serialize independent subsystems individually instead of putting all and everything on the same queue. But that's probably not easy to implement either, maybe even impossible. |
|
Can confirm for Slime Rancher 2, input lag of whole minutes.
|
This comment was marked as resolved.
This comment was marked as resolved.
|
Is this on wayland? If it is, it is a different issue from my initial post. |
|
It was actually my aio cooler breaking lol |
ghost
mentioned this issue
|
I keep seeing this with current Steam, using Proton Experimental. Enshrouded and Satisfactory in particular. If I set my mouse (Logitech G600, so 'singing-gundi' in ratbagctl, which is what I use to configure it in Linux) report rate higher than 200Hz I get building lag as I move the mouse around, this can definitely accumulate to several seconds worth. At 200Hz it's OK unless something else is being demanding enough on CPU. The last time that was an issue was a YouTube 60Hz video playing in a Firefox tab on my other monitor. It feels like the mouse events get queued up and only cleared at the rate the game/wine ends up consuming them. Is there no way that wine could consume them in real time, remember the latest, and only report that when a 'client' asks ? At least as an option ? The user gets what they ask for if they then move their mouse around very quickly and the game only sees very jerky movement, but it would still be better than inflicting the lag on yourself. |
What do your CPU temps look like? It turned out mine was a bad cooler and thermal throttling |
They're fine. I'm in-game in Satisfactory, 100+ FPS according to mangohud, working fine at 200Hz, but any higher report rate and I get the lag. CPU is holding a little below 70 degC, with the frequency holding above 5300MHz, so not at all throttled. This only happens if the mouse report rate is 'too high'. I can only set it to certain values, Whilst it's lagging, due to 'too high' rate, I note that Xorg process is pegged at 100%, especially if I try 1000Hz, which can cause the whole game to lag up severely. At 333Hz there's notable lag, and a bit of an FPS drop (from ~110 to ~90). Hardware info from Steam "System Report" with Satisfactory running:And the basic hardware info: |
Using latest Proton (probably started with experimental-wine-5.13-20210120 or experimental-wine-5.13-20210115), multiple games see input event loss or extreme lag.
Usually, single button presses on the gamepad aren't recognized, pressing it a second or third time and it works.
Sometimes, button presses are detected but the release isn't detected.
Axes sometimes do not update and just hang in some position until the situation eventually recovers after some time.
Button presses sometimes lag behind (usually just a short period, sometimes seconds). Axes also lag behind, often releasing an axis lags behind several seconds (see above).
In some games, this can also be observed for keyboard events. Mouse movement seems not to be affected but mouse buttons are. I usually do not play with mouse so I cannot really confirm this.
Games tested and affected:
The problem is probably depending on CPU usage of the game, titles putting more pressure on the CPU experience the problem more intense. From a programmer perspective, I'd say that the scheduler is starving the input event threads in wine. This MAY be a result from using the MuQSS scheduler in my kernel but even if it is, this is a problem that should be fixed in wine as scheduler behavior tends to change over time or due to pressure put on the system.
The text was updated successfully, but these errors were encountered: