Cyberpunk 2077 (2.5 "Edgerunners 2") — reproducible queue deadlock under streaming on RADV/gfx1201

Venue: https://github.com/HansKristian-Work/vkd3d-proton/issues (cross-reference ValveSoftware/Proton)

Summary

After the Cyberpunk 2077 Update 2.5 (Edgerunners 2, Oct 22 2026, game build 60152385347545148 / exe 3.0.5813403), the game reproducibly deadlocks during heavy streaming on RADV — the built-in benchmark freezes at a deterministic ~507 s point on its route, the save-load path freezes ~3–5 min in, and even boot-time shader streaming wedges within ~35–215 s. The engine's watchdog writes a post-mortem (CrashInfo.json) and either aborts the process or leaves it wedged. The same install ran fine on game build 2.31a on Oct 21 (5 days prior) on an unchanged kernel/Mesa.

Environment

• GPU: AMD Radeon AI PRO R9700 (Navi 48, gfx1201, 1002:7551, 32 GB), PCIe 5.0 x16
• Driver: Mesa/RADV 26.0.8 (radv is not a conformant Vulkan implementation build)
• Kernel: 7.0.0-38-generic (Ubuntu 26.04); amdgpu, default lockup_timeout, gpu_recovery=auto
• Display: 3840x2160@165 VRR, GNOME Wayland + XWayland
• Proton: GE-Proton11-7 (primary); also tested GE-Proton11-6, GE-Proton11-9 — identical freeze
• Game: GOG via Heroic, all 5,131 files md5-verified against depot
• No NVIDIA anything: pure AMD path (nvapi fully removed for tests)

Evidence

CrashInfo.json (engine post-mortem telemetry) per run:

• benchmark route: sessionLength 505.9 / 506.9 / 507.9 s, district: "Glen", isOom: false
• save-load path: sessionLength 348.9 s, real-world coords, isOom: false
• boot streaming: sessionLength 35–47 s on cold shader cache, ~156–215 s otherwise

Watchdog minidump (Cyberpunk2077-*.dmp, context-only snapshots, no exception stream):

• Thread names stream identifies the only non-parked threads. In the benchmark freeze: GameThread parked + vkd3d_queue thread executing inside winevulkan.dll (queue submission / wait never returning). Another capture showed FSR Interpolation Thread inside d3d12core.dll while GameThread parked.
• redDispatcher11 job workers executing normal engine SIMD math when snapshotted — engine-side is healthy; the wedge is below it.

vkd3d-proton log (with PROTON_LOG=1) shows per-frame activity stopping at the freeze instant — last lines are routine d3d12_command_queue_QueryInterface/DiscardResource warnings, no error. OptiScaler's independent overlay swapchain kept presenting at ~5.7 ms right up to process abort, confirming the wedge is in the game's queue path, not the whole process.

No kernel-side evidence: zero amdgpu reset/timeout messages in dmesg/journal (gpu_recovery would log); no OOM (62 GB RAM, VRAM peaked ~6.7/32 GB during boot wedge).

Ruled out (each independently — identical freeze)

Repro

1. proton run Cyberpunk2077.exe --launcher-skip -skipStartScreen on GE-Proton (any 11-x)
2. Either: wait through boot streaming on a cold cache (freeze in ~35–215 s), or reach the menu → CONTINUE → save load (freeze ~3–5 min), or -benchmark (freeze at ~507 s route point)
3. Engine watchdog writes CrashInfo.json; process wedges (or aborts with default watchdog timeout)

Notes / hypotheses

• Timing varies with streaming schedule, not a fixed timer — deterministic only on the benchmark's scripted route.
• 2.5 shipped a new renderer surface (DLSS 4.5/Streamline update, FSR4_FrameGeneration, DLSS_DynamicMultiFrameGeneration options, changed asset streaming) — plausibly a new descriptor-heap/queue usage pattern similar to the historic CP77 OOB-descriptor RADV hangs that vkd3d already works around for RT mode (v2.11 changelog).
• Happy to test patches or provide more dumps; the repro is 100% reliable here.

Attachments

• Cyberpunk2077-20261026-004140-460-576/Cyberpunk2077.dmp — watchdog minidump from a stripped-config freeze
• CrashInfo.json — latest engine post-mortem
• System: Mesa 26.0.8 / kernel 7.0.0-38 / GE-Proton11-7+ / gfx1201