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.

Update: 1 Hz GPU telemetry across two further hangs

Captured with nvidia-smi dmon -s pucvmet -d 1 plus 10 s per-thread CPU sampling.

Hang A — Xid 109 fired:

16:38:50-16:39:30   sm 46-51%  pwr 103-107W  pclk 2887  fb ~10800MB  rxpci 1300-1800MB/s  (healthy)
16:39:31            rxpci 3637 MB/s
16:39:32-37         fb 10813 -> 11182MB   sm 47->44   rxpci 1983->1046
16:39:38-44         sm 44->37   rxpci 805->555
16:39:45            sm 37->6    pwr 95->79
16:39:46            sm 4        pwr 56     fb 11094->10312MB (-782MB)
16:39:47-51         5 second gap - GPU could not be sampled
16:39:51            Xid 109
16:39:52+           mclk 13801 -> 810 -> 405 MHz

Hang B — no Xid, texture detail reduced:

16:47:30-43   sm 37-39%  pwr 93W  pclk 2842  rxpci 0   (healthy)
16:47:44      sm 3       pwr 82              rxpci 0   (abrupt, no precursor)
16:48:02+     txpci 350 -> 12 MB/s
16:49:00      all process CPU stops except audio threads

Hang B shows zero host-to-device traffic for the entire session yet produces the identical hang, so the upload burst visible in Hang A is not causal.

Both hangs end in the same thread state: main thread spinning in userspace (wchan=0, syscall=running) at 50-100% of a core, all PsoJob and LoadJob workers parked on futexes, and every vkd3d_fence / vkd3d_queue thread idle. In Hang A two threads spin simultaneously (VCMain at 100% of a core plus NBA2K27.exe at 51%), with vkd3d-swapchain in an hrtimer_nanosleep retry loop.

Sustained txpci of 250-370 MB/s (device-to-host) is present throughout normal play, dropping to ~12 MB/s once wedged.

In Hang B the title subsequently reported "network connection lost" and entered a reconnect loop; per-thread sampling shows the render stall begins ~75 s before the session drop, so that is downstream of the hang.

No thermal or power violations, no ECC errors, no PCIe errors in any capture. BAR1 flat at 38 MB.

Reproduction time ranges from ~80 seconds to ~9 minutes of gameplay, with no configuration found that prevents it.