drm/asahi: per-context GPU job completions stall ~50 ms every ~100 ms after ~30 min of a D3D12 game (other contexts unaffected; restarting the process fixes it) #666

Summary

In a long-running Diablo II: Resurrected session (D3D12 → vkd3d-proton → Honeykrisp), the game becomes jittery after ~20–45 minutes. Host gpu_scheduler tracepoints show the game's GPU context starts having frequent ~50 ms windows with no job completions, roughly every ~100 ms, while the job submission rate is unchanged. The compositor's GPU contexts keep completing normally during those windows, so the GPU is not globally stalled. Restarting only the game process (new GPU context/VM) restores normal behaviour; the host and VM stay up. Nothing is logged in dmesg.

Environment

• Hardware: MacBook Pro 14" M2 Max (2023), GPU G14C, 30 active cores
• Distro: Omarchy (Arch Linux ARM based, Asahi stack), kernel 7.1.12-2-12.2-sep-ARCH (linux-aurora 7.1.12.aurora2-12.2, a downstream fork from https://github.com/iconidentify/aurora-linux, not the official linux-asahi package; I can retest on an official kernel once Omarchy 4.5 is out and there is a reasonable upgrade path), 16K pages
• Host Mesa / vulkan-asahi 26.2.4
• Guest: muvm 0.7.0 / libkrun 1.19.6 (virtio-gpu DRM native context), guest kernel 6.12.109
• x86-64 Mesa (FEX overlay) mesa-fex-emu-overlay-x86_64 26.2.3; FEX-Emu 2610 (locally patched); Proton Experimental 11.0-20261027b; vkd3d-proton cae2e003b
• Display: 4K60 external monitor (DP), no VRR; game windowed, VSync on

Steps to reproduce

1. Launch Steam under muvm/FEX and start Diablo II: Resurrected (offline character).
2. Play normally (move between areas) for 20–45 minutes.
3. Jitter appears and persists; Save & Exit + relaunching only the game fixes it until it reoccurs ~20–45 minutes later. Reproduced in 5 sessions.

Measurements

Host ftrace of gpu_scheduler events (drm_sched_job_queue/run/done), 20 s windows, same game process at ~5 min (smooth) vs ~36 min (jittery). Game context = fence context 46607290.

• Compositor contexts (14, 128) keep completing normally during the game's stall windows, which points to something per-context or per-queue.
• The workload is ~50 small, mostly serialised jobs per frame. Lowering resolution or disabling heavy effects (AO, shadows, AA) does not help.
• Over the session, the VMM holds ~9k → ~11.5k dmabufs (one per guest BO), then plateaus. The game's RSS grows from ~3.0 to ~4.5 GB. The engine is known to churn committed resources.
• VKD3D_CONFIG=single_queue and VKD3D_SWAPCHAIN_PRESENT_MODE=MAILBOX do not fix it. VKD3D_SHADER_CACHE_PATH=0 causes heavy tile-pattern texture corruption on this stack (separate issue).
• Ruled out: thermals, CPU saturation, host memory or IO pressure, and the libkrun fence path (the kernel queue→run wait did not grow).

Raw traces (~50 MB each), the analysis scripts, and asahi-diagnose output are available on request.

Possibly related

• Power management is way too aggressive regards gpu compositing of browsers and/or memory speed #459 (GPU power management too aggressive). Not confirmed: here only one context stalls, while others keep completing.
• Earlier the same week, the same game triggered an asahi GPU timeout with an Unmapped fault in the DCMP unit, followed by a DRM scheduler QueueJob timeout. The host graphics stack wedged and needed a reboot.

Questions

• Is there firmware or kernel state per GPU VM/context that grows with BO bind/unbind churn, such as page-table or TLB-invalidation work, or firmware buffer or heap growth?
• Are there asahi debug flags or tracepoints that would show what the firmware is waiting on for this queue?