Unified DXVK/VKD3D lag timebomb in most games if compiled from git #4436
Comments
|
We have found out that, when this triggers, it only happens when moving the mouse, I'll be posting a video soon. |
|
DXVK does not interact with mouse input in any way, I strongly doubt it's even remotely possible that this is our bug. Also haven't seen anything like this on my machine even in extended play sessions. As for Unreal Engine titles, I ran Hellblade and Days Gone for ~an hour not too long ago to test some unrelated changes. |
I understand that they don't interact with mouse input, but when I run a game that natively uses Vulkan (ie. Quake 2 Remastered, Saints Row) they're not affected by this problem. Switching to any of your releases paired with a vkd3d release completely fixes this mouse problem. I'm not any more expert than you, but the only thing dxvk and vkd3d have in common is dxgi. I don't know if I'm being helpful but I can post a video on YouTube or logs. |
|
Well what I'm saying is that this functionally doesn't make any sense and I can't reproduce it. First step would probably be to provide detailed info about your build environment, including compiler version, MinGW version if applicable, and the exact command lines you're using to build the whole thing. Another question would be what kind of environment you're running on as well, any sort of input issue points more towards wine/compositor issues than us. |
I'm using fully updated Arch Linux, MinGW 13.1.0-1. I tried with X11, X11 + gamescope, Wayland and Wayland + gamescope. Same problem happens after roughly 25 to 40 minutes of gameplay. There's an intermittent heavy stutter that runs at its own pace, but only when playing with keyboard and mouse apparently, and it gets worse if you move your mouse once the "timebomb" triggers. I'm using your package-release.sh script to build dxvk, using vkd3d's package-release.sh script to build vkd3d as well. Nothing goes wrong while compiling. Switching to "old" versions of vkd3d + dxvk completely gets rid of the issue. Running a game that natively uses Vulkan or OpenGL never triggers this problem (under the same proton prefix and under the same circumstances of course). I'm going to upload a video of the problem on YouTube (recorded by a friend of mine) in order to showcase the problem. |
|
Video uploaded, manually switch to 1080p if it starts at 360p. This is a footage after roughly 30 minutes of playtime. The lag "timebomb" shows up at 0:44 timestamp: |
|
Does this also happen with the builds that ship with Proton Bleeding Edge or downloaded from GitHub CI or only with self compiled? Also are you able to bisect which commit it started with? |
This is precisely what the release builds are from. MinGW stuff hasn't been updated in a year or so, so the past couple of stable releases were compiled using exactly this in release mode.
Does "old versions" include self-compiled builds of stable releases? I'm not running anything special here, just plain old KDE Wayland with (generally) no Steam overlay and (generally) no Gamescope, and RADV on a 6900XT. If this is an issue that supposedly affects any (UE4) game on any setup then what exactly is it that makes my system the special snowflake that this doesn't happen on? Sorry for the rather annoyed tone but we have a release planned soon, so if this issue actually does affect a majority of users then I need a reliable way to reproduce it in order to actually do somehting about it. |
Yes, to also answer @Blisto91 the "old versions" included my own self-compiled. I have self-compiled versions of both dxvk and vkd3d saved, but I don't know where to start, honestly, maybe we can guess something:
|
|
For the sake of having a complete background, I'm actually going to test this whole thing without using ecores on intel and by using only one ccx on amd. It's probably unrelated and nonsensical but it doesn't harm me to test, my boyfriend is also testing with me. We've been trying to troubleshoot this for days to no avail. |
|
could you send a log with also could u try windowed mode |
Yes, I'll attempt both things after testing the ecores/ccx thingy. Edit: I'm sorry because these tests take a very long time, it's 25 to 40 minutes per-test. Yet, reproducibility should be easy (not timewise of course) as long as you're playing with a mouse and a keyboard on newly compiled dxvk + vkd3d. |
|
Can you try https://github.com/doitsujin/dxvk/tree/no-occlusion? |
funny story, I can't reproduce it either |
I'm building it while my boyfriend is testing without ecores. |
Is it actually git cloned and compiled or just picked from releases? If nobody can reproduce this here, it could actually be related to a change that affects ecores (to-be-confirmed since my boyfriend is still testing, he's playing since 31 minutes without the problem triggering as of now). |
Does not seem to be the problem. Will try no-occlusion straight away @doitsujin |
Timebomb triggered at 33 minutes with this fork. Some walls and corners were invisible. My boyfriend will test this again with debug logging, I'm going to sleep soon. Make a list of more things that I should try and I'll do it right after waking up (I don't have work so I'm free the whole day). |
|
Well, that rules out the only DXGI change since 2.4.1, so.... |
Could it be a shared change between DXVK and VKD3D? Because we don't experience that problem with neither Proton GE and Experimental, yet we used to not have that problem at all and I always compiled the latest git releases for both of us. I strictly believe that, at some point in time, something changed, and it affected both dxvk and vkd3d, and specifically "mouse handling" (probably not the right term) somehow. It's weird that anything that runs on native API (Vulkan / OpenGL) does not suffer from this issue on any Proton prefix, yet the moment we try using git compiled dxvk + vkd3d this starts triggering. It's interesting that games that run, for example, on Insomniac Engine and its forks, don't even suffer from this issue, while other games (notably Unreal Engine) have this timebomb as long as they use DXVK or VKD3D and as long as you play them with a mouse and keyboard. My boyfriend will provide debug logging until the problem starts happening, and if you can 100% conclude that this is certainly not a DXVK + VKD3D issue, I'll have to look somewhere else. Most worrying scenario would be this problem affecting the majority of people but they have no idea. We really need more people testing this. |
|
Been playing Hogwarts Legacy for around 110 mins now but haven't been able to reproduce. |
That's not exactly the steps, I meant manually compiling dxvk and vkd3d straight away and putting them in a compatibility tool. |
|
I asked above if the issue shows with the builds included in Proton Bleeding Edge or from the CI. Edit: Could you share the ones you have compiled? |
This will take a long time to test, I was mainly testing git compiled dxvk and vkd3d. Bleeding Edge breaks too much stuff, I'd rather live with the lag timebomb. |
|
I would like to try the ones you have compiled yourself to test with. Just package them up and attach here |
|
|
I've got to sleep now, I'll keep myself updated when I wake up. File attached in the previous message. |
|
Played Hogwarts Legacy for 90 minutes more, this time with the Bleeding Edge DLLs replaced with vkd3d-proton, dxvk and dxvk-nvapi from your archive. Still nothing sadly |
|
since you can build your own dxvk and know that the issue has been happening for 2 months, could you bisect it? |
My boyfriend actually tried experimental bleeding edge overnight (without my DLLs) and the timebomb triggers there as well. Are you sure you were actually playing with a keyboard and a mouse? The problem only seems to happen when using m+k. Regular Proton Experimental is completely fine and unaffected by the way. And again: native Vulkan/OpenGL games running under any of these compatibility tools do not expose the problem, so it's definitely a dxvk+vkd3d thing.
See my message above where I list my older compiled dxvk+vkd3d combos, I don't know where to start. If you have an idea, maybe a date, I can start from there and test. |
|
It's funny that this issue has existed for one year or more as far as I remember but people are still not understanding the nature of the issue. |
Those are preloaded, 1 of them will print famous error in log. Because system is 32 or 64 and it tries both. I just imagined ... what will happen if both can be loaded ? :) (for example system has multilib config). I guess they will fight each other => lag. |
|
Yep, my bet is on 32 and 64 conflict each other when both are loaded: |
They should only actually load the correct version for the executable, not both. Easy to test, just set the LD_PRELOAD to one of them. |
Yep, in addition, steam itself (and all it's children processes) are "infected" by 32 bit library on 64 bit multi-lib system. |
Why it only happens after a certain time, e.g. for cs2 it's somewhat 28-min. |
It depends on the nature of the conflict. I also made |
|
I've been able to reproduce this issue too on Fedora/KDE Plasma 6 (Wayland)/ProtonGE 9 22 So far only LD_PRELOAD="" seems to completely eliminate the problem, no severe stuttering after 40-45mins of gameplay. I tried disabling GPU acceleration in web view without success.
I tried changing uid/guid owner and chmoding ~/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so, steam overlay isn't loaded as expected but the issue remains. |
Not sure, I had 32 and 64 bits loaded. So I did |
That's interesting, out of curiosity, i extended the scope of what was loaded and... this is quite confusing... i'll deep dive on it later to experiment. |
It is simple. Only 2 libraries are loaded there ;) |
|
Indeed, i chown/chmoded the 32 and 64bits libraries and that fixed the issue, from there i tested keeping the correct 32bits overlay and that worked. From the tests i've done so far (with a 32bits DX11 game)
I guess it's because a 64bits library is loaded with a 32bits game or the other way around (haven't tested it yet) causing this issue. |
I can just speculate. As we see into |
|
On closer inspection, the culprit may be gamescope, i noticed that all 64bits gameoverlayrenderer.so are "not permitted" without it and with gamescope based on the 1st lsof i posted, one manages to be loaded by gamescope: With gamescope, tries to load the 64bits one instead: Without gamescope, reaper (wine) loads the correct 32bits gameoverlayrenderer: Full lsof: |
I don't have "gamescope" and still had a problem. |
|
Could be a wrong lead there for sure, i'll try to investigate while playing a bit more later, thanks for the help. |
|
No, it's not gamescope. |
|
Just a heads up, the problem was confirmed to be related to the Steam for Linux, you should continue discussing it here: ValveSoftware/steam-for-linux#11446 Although this problem doesn't seem to affect native APIs such as Vulkan and OpenGL, it's still not directly related to DXVK/VKD3D, although there's a correlation between Enabling Steam Overlay or else using a custom The problem started happening since the game recording update for Steam. Edit: Native Vulkan games (under Proton) seem to be affected as well, maybe not all of them. |
I have no idea what is it. So I would prefer to keep it completely removed in my setup. Thanks, though. |
You only need Steam Input for PlayStation / Nintendo gamepads and such. Usually, the "default" setting works just fine. |
This is only correct for OpenGL. Native Vulkan games (running via wine) are affected as well. |
Yeah, I just saw some users having this problem on Vulkan, was never reported before and I never had them so I assumed it was fine. |
|
I did run into this issue in Path of Exile 2 with its Vulkan renderer. |
|
I don't get why they keep adding "features" which immediately break everything or make it worse. This one is not alone. They added GPU detection, which powers-on double gpu which raises heat and consumption just to keep steam opened, Had to block it by appguard. |
Nah, this time-bomb stutter issue started long before. It has existed at least for more than a year. People reported it on CS:GO long long time ago, and the fix was similar: disable steam overlay or use 'LD_PRELOAD'. |
|
for me LD_PRELOAD does nothing. and true that i had this time bomb before steam recording, however i only noticed it in CS2 and as i dont play CS2 for some few months, i havent tried to troubleshot this so cant confirm for sure is this related in any way. |
Will mangohud workaround command be needed to work with |
and others
There's a literal "lag timebomb" when pulling the latest git versions of DXVK and VKD3D and compiling them. These lag timebombs are unified, meaning that they happen in both DXVK git and VKD3D git, and they trigger after roughly ~25 to ~40 minutes of gameplay and generally only trigger if the user is providing input to the game. This problem exists since roughly 2 months and I felt like it would be good to report it here. Since the problem is unified (happens on both DXVK and VKD3D) I actually didn't know where to report it.
Affected games mostly use Unreal Engine. Insomniac Engine games, for example, didn't seem to be affected.
Using a "Release" version of DXVK + a "Release" version of VKD3D seems to solve the problem.
More specifically, the game is smooth before the "timebomb" triggers, then consistent and repeated heavy stutters begin to happen. If needed, I can record a video.
EDIT: We have found out that, when this triggers, it only happens when moving the mouse.
Software information
Any game that uses DXVK or VKD3D pulled from git and compiled, this problem is unified and common in both DXVK and VKD3D
System information
Apitrace file(s)
Log files
The text was updated successfully, but these errors were encountered: