Targeted log (WINEDEBUG=-all,err+all,fixme+d3d12) shows the failure clearly:
d3d12_device_validate_shader_meta: Attempting to use 16-bit operations in
shader 5bb2de31aab01344, but this is not supported.
d3d12_pipeline_state_init_compute: Failed to create Vulkan compute pipeline,
hr 0x80070057.
d3d12_device_validate_shader_meta: Attempting to use 16-bit operations in
shader 583e3be83ea52e24, but this is not supported.
d3d12_pipeline_state_init_compute: Failed to create Vulkan compute pipeline,
hr 0x80070057.
err:sync:RtlpWaitForCriticalSection section ".../ntdll/loader.c: loader_section"
wait timed out in thread 0538, blocked by 053c, retrying (60 sec)
[repeats for every other thread in the process, indefinitely]
The thread that fails pipeline creation (053c) then holds the Wine loader
critical section indefinitely, deadlocking the entire process.
Confirmed on two independent systems with identical shader hashes:
| System A | System B | |
|---|---|---|
| GPU | GTX 1080 (GP104) | GTX 1070 (GP104) |
| OS | Linux Mint 22.2, kernel 7.0.0-38 | CachyOS, kernel 7.2.8 |
| Proton | GE-Proton11-7 | Experimental 11.0-20260924 |
| Driver | 580.178.04 | 580.178.4 |
| Failing shaders | 5bb2de31aab01344, 583e3be83ea52e24 | identical |
Pascal does not support shaderFloat16/shaderInt16. The 11.12 game update
appears to have introduced compute shaders requiring 16-bit operations, which
is why this is new and why it affects Pascal specifically — Turing and newer
support these natively and are unaffected.
Two issues here:
Please attach a default proton log
Confirming same root cause on AMD Polaris (RX 580 8GB), Mesa 25.3.6 RADV, kernel 7.1.8.
Identical failing shaders: 5bb2de31aab01344, 583e3be83ea52e24 ("16-bit operations [...] not supported").
shaderFloat16=false on this driver. No Xid/GPU fault (AMD): instead loader_section
deadlock (thread holds loader lock, 60s retries) then EXCEPTION_BREAKPOINT at 99% preload.
Game worked before discovery_11.12.x (UE 5.7.4 now). All Proton versions fail.
Follow-up: pragmatic workaround tested successfully on the Polaris system above.
Gated d3d12_device_supports_16bit_shader_ops to allow on RADV (same pattern
as the existing Turnip exception). Verified first that the driver really
compiles it: vkCreateShaderModule + vkCreateComputePipelines with a Float16
compute shader both return VK_SUCCESS on RX 580/RADV.
Result: full online match played start to finish, no crash,
dmesg clean. Minor visual artifacts under observation.
Happy to submit this as a PR (possibly narrowed to pre-RDNA if there's a
clean arch query) if maintainers want it.
Has anyone tried the equivalent capability test on Pascal — vkCreateShaderModule + vkCreateComputePipelines with a Float16 compute shader on the proprietary 580 driver? If it returns VK_SUCCESS there as it does on RADV, the same gating fix might cover GP104/GP106. If it fails, then Pascal genuinely needs the 32-bit demotion path rather than a capability override, and the two cases need different fixes despite the identical symptom.
I did some debugging with my AI agent, and it managed to fix the issue on the VKD3D side. I have a friend with GTX 1080 and he previously crashed at around 95% shader precaching. Now he can normally play the game on DirectX12 without crashes and without any stutterings
Feel free to test my solution, I'll try creating a PR if this manages to work for everyone
ge-proton11-7x2 2026-10proton experimentalx1 2026-10WINEDEBUG=-all,err+all,fixme+d3d12`)x1 2026-10VKD3D_CONFIG=pipeline_library_no_serialize_spirvx1 2026-10VKD3D_CONFIG=single_queuex1 2026-10VKD3D_CONFIG=single_queue,no_upload_hvvx1 2026-10__GL_SHADER_DISK_CACHE_SIZE=10737418240x1 2026-100x80070057x1 2026-10
Summary
THE FINALS (Steam appid 2073850) crashes reliably at ~90-95% of the in-game
"PRELOADING SHADERS" progress bar, in the main menu, on a GTX 1080 (Pascal).
The NVIDIA driver reports an Xid 31 MMU fault (write to unmapped address) from
the GameThread, and the game's own crash reporter records CrashType=GPUCrash.
The game ran reliably for months before the discovery_11.12.x game update.
Earlier crashes on discovery_11.06.x were GameThread hangs after 15-60 minutes;
since 11.12 it is a hard GPU fault within ~30 seconds, every launch.
Reproduction
Reproduces whether the preload is slow (cold cache) or fast (warm cache), so it
is tied to a specific item rather than elapsed time or thermal/load conditions.
Kernel log
NVRM: GPU at PCI:0000:01:00: GPU-be57f044-5206-c62f-22fb-c04e2aade5cb
NVRM: Xid (PCI:0000:01:00): 31, pid=95197, name=GameThread, channel 0x000000c4,
intr 10000000. MMU Fault: ENGINE GRAPHICS HUBCLIENT_FE faulted @ 0x0_22000000.
Fault is of type FAULT_PTE ACCESS_TYPE_WRITE
Game crash context
CrashType = GPUCrash
ErrorMessage = GPU Crash dump Triggered
Misc.IsStuck = true
Misc.StuckThreadId = 436
GPUBreadCrumbs = GPUCRASH_NONE
MemoryStats.bIsOOM = 0
MemoryStats.AvailablePhysical = 6378246144
SecondsSinceStart = 32
GameStateName = DiscoveryGameStateMainMenu
EngineVersion = 5.7.4-1408560+discovery_11.12.x_ue57
RHI.RHIName = D3D12
RHI.FeatureLevel = SM6
System information
Reproduces on
Tested without effect
VKD3D_CONFIG=single_queueVKD3D_CONFIG=single_queue,no_upload_hvvVKD3D_CONFIG=pipeline_library_no_serialize_spirv-onethread__GL_SHADER_DISK_CACHE_SIZE=107374182402.8 GB of 8 GB VRAM in use, 459 GB disk free, no OOM in kernel log)
Notes
Thread dumps taken while hung (before the watchdog fired) showed every thread
blocked —
futex_do_wait,ntsync_schedule,anon_pipe_read— with zerothreads running, including 4 threads named
PSOPrecompilePo.Possibly Pascal-specific, since the game appears to work for other Linux users
on newer NVIDIA hardware.