Disclaimer

I did this analysis with Claude, this is a summary of the troubleshooting I did with various proton versions and steam launch parameters. Since the more recent update of drivers the game stopped functioning completely - while it was working on 595.58 + older proton (one of the April releases, cannot remember now which exactly). I could switch back to nvidia-dkms drivers and try back the old version with flags I had.

All in all, it's baffling to me that nvidia is just ignoring this on linux when they fixed these lumen / nanite issues asap when they occured on windows.

Anyways, summary below. If you need me to run more diagnostic / logs let me know and I will attach them to this issue.

Additional diagnostic data — same game, same Blackwell+CachyOS class

Hit the same issue on RTX 5090. The novel signal I want to add to this thread is that VKD3D-Proton's existing per-game GZW workaround is firing, but the crash still reproduces deterministically inside Nanite::ShadeBinning. Bisecting the renderer top-down identifies which UE5 subsystem hangs the GPU at each stage.

Stack

VKD3D-Proton's existing GZW quirk IS being applied

From the Proton log at init, the per-game workaround added in 0f5e58d fires correctly:

info:vkd3d-proton:vkd3d_instance_apply_application_workarounds:
  Program name: "GZWClientSteam-Win64-Shipping.exe" (hash: f779e6f4c254f6a8)
info:vkd3d-proton:vkd3d_instance_apply_application_workarounds:
  Detected game GZWClientSteam-Win64-Shipping.exe, adding 2 configs, removing 0 configs.
info:vkd3d-proton:vkd3d_instance_apply_application_workarounds:
  Detected game GZWClientSteam-Win64-Shipping.exe, adding shader quirks for specific shaders.

So the Root CBV / shader-hash quirks land, but the crash still happens. The existing quirks are insufficient for the 5090 / driver 595.71.05 / build 4.3.0 combination.

Crash signature (current, after disabling DLSS-G, Lumen GI, Lumen Reflections)

Kernel side, consistent across every run:

NVRM: Xid (PCI:0000:01:00): 109, pid=N, name=GameThread,
      channel 0x00000019, errorString CTX SWITCH TIMEOUT, Info 0x3c030

(Info low bits vary slightly per run; channel is stable at 0x19 for the Nanite path. Earlier, with Lumen+DLSS-G still on, the failing channel was 0x27 and Info 0x3c803c — different command queue, different rendering subsystem.)

UE5 side:

LogD3D12RHI: Error: GPU crash detected:
  - Device 0 Removed: DXGI_ERROR_DEVICE_REMOVED
LogRHI: Error: Active GPU breadcrumbs:
  (ID: 0x80000347) [Active]  Frame 1
  (ID: 0x800004f3) [Active]    FRDGBuilder::Execute
  (ID: 0x8000042f) [Active]      Scene
  (ID: 0x8000045a) [Active]        BasePass
  (ID: 0x8000045c) [Active]          NaniteBasePass
  (ID: 0x8000045d) [Active]            Nanite::BasePass
  (ID: 0x8000045e) [Active]              Nanite::ShadeBinning   ← GPU dies here
LogNvidiaAftermath: Error:
  Legacy Aftermath GPU Crash:
    GFSDK_Aftermath_GetDeviceStatus failed: 0xbad00002
    GFSDK_Aftermath_GetPageFaultInformation failed: 0xbad00002
LogD3D12RHI: Error: GPU Crashed or D3D Device Removed.

The GPU dies inside Nanite::ShadeBinning — Nanite's material-binning compute pass — during the very first scene-rendering frame after the splash sequence.

Bisection journey (each step verified by breadcrumb shift)

Starting from the default-graphics crash and disabling subsystems one at a time. Every step changed the failure point in a way that's visible in the UE breadcrumb log — making clear that each subsystem can hang the GPU independently on this hardware.

Independent triggers seen across the bisection: Lumen GI, Lumen Reflections (Lumen scene maintenance), DLSS Frame Gen (On4X), and now Nanite compute binning. Each one independently capable of hanging the GPU on this hardware/driver combo.

Notes on Streamline / NGX

Even after disabling DLSS-G, Streamline still spams the same NGX errors at startup. Probably unrelated to the crash (these fire ~10s before GPU death, after which other subsystems crash on their own) but worth noting:

LogStreamlineAPI: Error: NVSDK_NGX_UpdateFeature failed 0xbad00002
LogStreamlineAPI: Error: Failed to create process C:\Windows\System32\nvngx_update.exe -cmsid 0 -feature sl_reflex_0 -api bootstrap
LogStreamlineAPI: Warning: Detected base interface 'ID3D12CommandQueue' while expecting SL proxy
                  — please use slUpgradeDevice to obtain SL proxies for DXGI/D3D interfaces
LogStreamlineAPI: Warning: Invalid backbuffer resource extent (3440 x 1440)

Materials available on request

Happy to provide:

• Full Proton log (PROTON_LOG=1, ~12 MB compressed)
• UE Crash Reporter dumps from ~/.../GZW/Saved/Crashes/UECC-Windows-* (multiple from this session)
• Aftermath dump files
• Game shader cache (fozpipelinesv6/) if helpful for hash matching
• Bisection logs for individual stages above

Let me know what would be most useful for triage.

These LLM analysis usually just add more noise rather than being helpful.
If you've got any practically verified helpful information to add to the original report then just post that in short.

I mean it's a summary of observation of logs I pulled out during different runs, proton versions, launch options, should be helpful to the person that picks this up to try and identify the problem considering they do not own all the different hardware ppl are referencing in these.

Linking this here as I managed to find a workaround for the time being until nvidia decides to patch this problem https://github.com/HansKristian-Work/vkd3d-proton/issues/3048#issuecomment-4512128535