NBA 2K27 (appid 4356430) hangs reproducibly a few minutes after launch. The GPU goes idle, the game's job-system workers all park having finished their work, and the main thread spins in userspace indefinitely. The process stays alive — audio keeps playing — but the render loop never advances.

I am not certain this is a vkd3d-proton bug rather than a game-side one; the evidence below points at a lost wakeup in the title's own job system. Filing here because vkd3d is in the path, and because the vkd3d_fence / vkd3d_queue threads show a pattern that may mean something to you. Happy to be redirected.

System

Hang signature

Captured live from /proc/<pid>/task/* while hung:

249-306 jiffies/5s   NBA2K27.exe    wchan=0, syscall=running    <-- main thread, userspace spin
 24 PsoJob           futex_wait_multiple                         <-- all workers parked
 24 LoadJob          futex_wait_multiple
 10 vkd3d_fence      futex_do_wait    <-- most with 0 jiffies accumulated, ever
 10 vkd3d_queue      futex_do_wait    <-- same
  9 RenderThread     futex_do_wait
GPU: 2-4% util, 500-900 MHz, ~22 W, VRAM still allocated

syscall=running on every sample — the main thread never enters the kernel. Meanwhile VCAUDIO3, FAudio_AudioCli and OpusDecoderThre continue to accumulate CPU for as long as the hang lasts, so only the render/main loop is wedged.

The detail that may be relevant to vkd3d: the majority of vkd3d_fence and vkd3d_queue threads show zero CPU time accumulated over the whole process lifetime — they appear never to have been given work, even though a large PSO compile completed successfully immediately beforehand (48 MB pso.toc, 2.9 GB Steam shader cache).

The title never sets its own SHADER_BUILD_STAGE_3_ID (stays 0 in VideoSettings.cfg) across every run, on every configuration, including runs where the pipeline cache was fully built.

Eliminated by direct test

Each tested individually; hang reproduced in all cases:

• Driver 595.91.07 → 610.57.04 (open)
• Xorg → Wayland
• Proton Experimental → Hotfix
• fsync → esync (PROTON_NO_FSYNC=1): workers move from futex_wait_multiple to anon_pipe_read, hang otherwise identical — so not a Wine sync-primitive lost wakeup
• PSO cache empty vs. fully rebuilt (2.9 GB)
• iGPU excluded via VK_DRIVER_FILES=.../nvidia_icd.json (verified: zero Intel/anv libraries in /proc/<pid>/maps)
• VKD3D_CONFIG=nodxr, force_host_cached, no_upload_hvv
• VKD3D_DISABLE_EXTENSIONS=VK_NV_raw_access_chains
• DLSS off, VSync off, quality preset High and Ultra
• CPU affinity taskset -c 0-7 (P-cores only): worker pools scale 24 → 8, hang identical

Hardware ruled out: PCIe negotiates Gen5 x16 under load, Replays Since Reset: 0, no AER events; 60 s of sustained GPU compute (llama.cpp) completely clean; thermals 30-37 °C with HW Thermal Slowdown and HW Power Brake counters both 0 µs; stock power limit, no overclock.

Note on Xid 109

On this hardware the hang is sometimes accompanied by NVRM: Xid 109 CTX SWITCH TIMEOUT, name=RenderThread (also reported at NVIDIA/open-gpu-kernel-modules#1146 for GB202). In my case the two are separable: with VKD3D_DISABLE_EXTENSIONS=VK_NV_raw_access_chains VKD3D_CONFIG=nodxr,force_host_cached the Xid stopped being logged across subsequent runs while the hang persisted unchanged. Without those options the main thread spins tight at ~100% of a core and the Xid fires; with them it spins at ~50% with a yield (wchan=poll_schedule_timeout) and no Xid appears. That reads to me like the GPU context being starved by a CPU-side stall for long enough to trip the context-switch watchdog, i.e. the Xid is downstream of the hang.

Logs

I have not yet captured a VKD3D_DEBUG / PROTON_LOG trace — the runs above had VKD3D_DEBUG=none and WINEDEBUG=-all. I can reproduce this on demand within a few minutes of launch and will attach a full log; tell me which log level is most useful. I also have 1 Hz nvidia-smi dmon telemetry covering the approach to the hang and complete per-thread dumps.