Fallout 4 stuck after loading screen.

dxvkclosed d3d11intel anvneeds feedback

doitsujin/dxvk#4401 · opened 2024-10-25 by maltalef101 · updated 2025-10-15 · 10 comments · github

Mmaltalef101 2024-10-25 github

Fallout 4 starts normally and with no issues. Aaaand then the game is loaded, and I'm filled with VK_ERROR_DEVICE_LOST in the Proton logs. From what I've been reading around this is a problem with Intel's ANV driver being absolute crap regarding vulkan and stuff. I'm not well versed in the linux video stack so apologies if my assumptions are colossally incorrect.
This is what's put in dmesg

[ 3858.787615] i915 0000:00:02.0: [drm] Resetting rcs0 for preemption time out
[ 3858.787689] i915 0000:00:02.0: [drm] Fallout4.exe[61390] context reset due to GPU hang
[ 3858.788015] i915 0000:00:02.0: [drm] GPU HANG: ecode 9:1:85d77ffb, in Fallout4.exe [61390]

Software

uname -a: Linux vic20 6.10.1-zen1 #1-NixOS ZEN SMP PREEMPT_DYNAMIC Tue Jan 1 00:00:00 UTC 1980 x86_64 GNU/Linux
Fallout 4 in windowed mode lowest settings possible
(tried borderless, fullscreen, and nothing makes a difference)

System information

GPU: Intel Corporation HD Graphics 620 (from lspci)
Driver: mesa 24.0.7 (using i915 module)
Wine version: 9.0
DXVK version: 2.3.1

Apitrace file(s)

When testing I found that using WineD3D via PROTON_USE_WINED3D=1 solved my issue (obv the game run horribly bc opengl). As per instructions, apitraces are preferred without dxvk intervention. I don't think this is useful in this case as my problem is not reproducible without dxvk enabled. (Please tell me if an apitrace is needed so I can go through the procedure)

Log files

steam-377160.log

Apologies if some useful information was omitted or is wrong, tell me if so and I'll rectify the issue ASAP.

Thanks in advance.

BBlisto91 2024-10-25 github

If able I think it would be most interesting to try the newest Intel driver. None on the team have a Intel GPU to try and test with and I am not aware of any such issues on AMD or Nvidia.

Also if you are able to get Vulkan Validation layers installed on your system (the package name probably depends on your distro) then it might be interesting to get a new log with VK_INSTANCE_LAYERS=VK_LAYER_KHRONOS_validation DXVK_DEBUG=validation PROTON_LOG=1 %command%

BBlisto91 2024-10-25 github

Actually before doing what I posted above I found something on the mesa tracker that might be applicable here.

From issue https://gitlab.freedesktop.org/mesa/mesa/-/issues/3637

This is a known issue. The problem is a fragment shader that's run during the loading screen that takes too long and the kennel times out. The reason it runs on windows is likely a longer timeout.

A potential workaround to try is mentioned in these comments https://gitlab.freedesktop.org/mesa/mesa/-/issues/3637#note_656051

Edit: Another thing to try might be INTEL_DEBUG=reemit as a launch option

Mmaltalef101 2024-10-25 github

Yes, the behavior is similar. I'll try the suggested workaround in a bit and see what happens. Even if it works it's something that seems weird to have to do for when I want to play this specific game. It seems odd that the issue you first linked to is still open after four years. That's a long time for an issue to not be fixed.

Now, this is absolutely speculation, but, would the timeout cause the VK_ERROR_DEVICE_LOST? My guess is that it resets and loses the handle to the device or something along those lines. I honestly have close to no idea on what actually happening.

Mmaltalef101 2024-10-25 github

On the Vulkan validation layer approach, I'll have to investigate how to install them on NixOS, as that is the distribution I'm using currently. Even if the problem goes away with one of the fixes, I'll keep trying to contribute to this investigation, such as you say, this issue doesn't seem to be present on AMD or Nvidia, and I might add, I've played this game before on my other computer (one that is currently dismantled so it's not so easy to go and try and reproduce), and I don't remember having this much struggle to make it run correctly.

BBlisto91 2024-10-25 github

Now I am not a dev, dxvk, driver or otherwise (am tester), so don't qoute me here but afaik VK_ERROR_DEVICE_LOST just means that the driver had a problem where things are taking longer than expected. A common cause is the GPU driver hanging or crashing and so it stops communicating, and the timeout is there to prevent the driver from spitting it out everytime it has to do work.
If the issue here is that there is some work that takes so long that the timeout gets overrun so the system thinks the driver hung it makes sense it spits out that error because it thinks communication was lost.

For what happens behind the scene in the driver when such a error is shown i don't know. I assume some type of reset or recovery is done yes.

Ddoitsujin maintainer 2024-10-25 github

Now, this is absolutely speculation, but, would the timeout cause the VK_ERROR_DEVICE_LOST

Yes, timeouts do trigger DEVICE_LOST, and there's no meaningful way to keep going after receiving such an error.

Mmaltalef101 2024-10-29 github

Update:

The issue is resolved when upping preemt_timeout_ms in sysfs to 5000 ms (out of curiosity I tried with 6000 ms initially and that worked too). What I want to know currently is if I should reproduce the issue with the default preemt_timeout_ms and Vulkan validation layers enabled. I guess if the issue is not reproducible with the higher timeout set, there would be no point in debugging in those conditions.

I have not tried with the INTEL_DEBUG=reemit approach. If needed or useful, just ask. I am not aware of the usability of the information that may come to light with that approach.

On another note, is this issue primarily related to Intel's implementation or something on the Vulkan side? If this is an Intel problem my guess is that it won't be easy to fully solve. Something I read on the Mesa issue linked to previously is that this is a known problem that doesn't really happen on Windows because the timeout may be higher on these type of operations. If that's the case, then it may well be outside of dxvk's scope.

Hope we can get some definitive conclusion. Upping the timeout value still seems janky.

Mmaltalef101 2024-10-29 github

In regards to performance, I don't have a measurable figure of this, but I can say that with my low expectations it's playable. Barely. I guess that's not much of a mystery being that I'm running integrated graphics on a pretty old processor by today's standards.

BBlisto91 2024-10-29 github

I am not a dev so I can't say if dxvk can do anything about the long stall that makes the driver timeout, I assume the game does the same on Windows. I think this is something that have to be solved on Intels side.
Imo the first thing to do would be to bump the linked mesa issue. Faith, which mention that it is known and they were working on a fix, does not work at Intel anymore so maybe it fell through the cracks somehow. Would be good to get some other Intel dev eyes on it.

BBlisto91 2025-09-26 github

@maltalef101 Would you mind giving this another go with dxvk master? A lot has changed shader compilation wise so we might be lucky this has improved. You can download a build here https://github.com/doitsujin/dxvk/actions/runs/17993501449
Remember to check that graphics drivers are up to date before trying

Launch options

Launch lines

VK_INSTANCE_LAYERS=VK_LAYER_KHRONOS_validation DXVK_DEBUG=validation PROTON_LOG=1 %command%x1 2024-10