Please attach a log like the template asks for.
I assume a LLM helped fill this out? I'd suggest cutting the reports down in the future as over half of it could be removed without losing any important information.
A video would have been more helpful.
But thank you for reporting the regression.
Fair point! I guess that's why they call it a Large Language Model. 😉
I will create and attach the log and capture a short video.
I've attached the Proton log from GE-Proton 11.7 (DXVK v3.1-19), captured while the stuttering was reproducible.
The log contains access violations in libnvidia-glcore.so.615.71.09. These violations does not happen in 11.6, so i attached a 11-6-working.log additionaly
Steam's video recording technically works, but enabling the Steam overlay makes the stuttering disappear, both visually and in MangoHud measurements, so I cannot capture the issue that way.
I can't confirm that 3.1 works fine, in fact it's the exact same mess no matter which DXVK I throw at it.
No idea where the Nvidia exceptions are coming from, Vulkan validation is clean. Has nothing to do with the issue though, I'm reproducing this on AMD as well.
Please try DXVK_CONFIG="d3d11.cachedDynamicResources=a". This seems to help here somewhat, which makes me wonder if EAC is periodically scanning mapped VRAM or something, which would be exceptionally slow.
The d3d11.cachedDynamicResources=a setting appears to have a limited positive effect on the frametime measurements, but the periodic stuttering persists and there is no consistent, noticeable improvement in gameplay smoothness.
Just to clarify regarding the possibility that EAC might be involved: The EAC option is unchecked in my 7 Days to Die launcher throughout my testing.
I checked the running game process and found the following command-line arguments: -force-d3d11 -nogs -noeac.
I believe this isn't apparent from the Proton logs I've attached, so I wanted to mention it explicitly.
Well, might just be a different problem from what I was running into then, dunno. "Stutter" can mean literally anything.
should have been fixed a while ago, the problem I was running into was indeed a differet one.
proton 11.7x2 2026-10proton 11.6x1 2026-10DXVK_CONFIG="d3d11.cachedDynamicResources=a"x1 2026-10WINE_DISABLE_QPC_TSC=1x1 2026-10
Description
7 Days to Die suffers from severe, reproducible periodic stuttering with DXVK
601930949(v3.1-19), while DXVK70d7508c(v3.1) runs smoothly.I isolated the issue by swapping DXVK versions within a custom GE-Proton 11.7 installation, keeping the Wine version and other Proton components unchanged.
A controlled A/B/A test confirmed that the stuttering disappears with the older DXVK build and returns when switching back to the newer build.
System Information
winex11.drv(XWayland)taskset -c 0-7,16-23DXVK Versions
Working:
70d7508c01201ed3d4bfb33da42ba834eafe3857Affected:
601930949d111edbbcf9dd463948426d9f8f6dddCommit comparison:
https://github.com/doitsujin/dxvk/compare/70d7508c01201ed3d4bfb33da42ba834eafe3857...601930949d111edbbcf9dd463948426d9f8f6ddd
Controlled A/B/A Test
I created a separate copy of GE-Proton 11.7 and replaced its complete DXVK directory with the version included in GE-Proton 11.6.
A separate copy of the game's Wine prefix was used throughout the component-swap tests, leaving the original game installation and prefix untouched.
The actually loaded
d3d11.dllanddxgi.dllbinaries were verified usingcmpagainst the corresponding DXVK builds.MangoHud Measurements
Approximately 30 seconds per run, using the same saved game state and CPU affinity.
Observed Behavior
Original DXVK v3.1-19:
Older DXVK v3.1 in the same GE-Proton 11.7 base:
Reverting to DXVK v3.1-19:
The reference save was restored before comparative runs.
Measurement note: MangoHud recorded approximately 300 periodic samples per 30-second run, not individual frametimes for every rendered frame.
Additional Tests
QueryPerformanceCounter Workaround
Tested:
WINE_DISABLE_QPC_TSC=1Results:
The workaround did not resolve the issue.
Unigine Superposition
Tested the Windows Direct3D benchmark at 1080p Medium through both GE-Proton versions.
Neither version exhibited comparable sustained frametime spikes.
This suggests that the regression may depend on specific D3D11/DXGI usage patterns in 7 Days to Die rather than affecting all DXVK workloads.
Extended Gameplay
GE-Proton 11.6 was also tested for approximately two hours without noticeable stuttering.
Potential Regression Areas
The 19 commits between the working and affected DXVK versions include changes to:
These are potential investigation areas, not confirmed root causes.
Conclusion
The controlled component-swap experiment provides strong evidence of a DXVK regression between
70d7508cand601930949.The regression appears to be contained within the 19 commits separating these versions.
MangoHud CSV files from the tests are available for further investigation.