RTX PRO 6000 Blackwell (96 GB): Xid 32 PBDMA `PBENTRY` channel reset in WH3 DX12 — vkd3d-proton does not observe the channel loss

vkd3dopen

HansKristian-Work/vkd3d-proton#3120 · opened 2026-06-23 by koodijahti · updated 2026-06-23 · 1 comments · github

Kkoodijahti 2026-06-23 github

Summary

On an RTX PRO 6000 Blackwell Max-Q (96 GB), driver 610.43.02, running Total War: WARHAMMER III in DX12 (vkd3d-proton) with PROTON_VKD3D_HEAP=1, after an extended session the kernel logs Xid 32 on a single channel and resets it. The GPU survives — no GPU-wide reset, no Xid 56. vkd3d-proton logs nothing: no VK_ERROR_DEVICE_LOST, no device-removed callback — so the offending command cannot be captured with VKD3D_CONFIG=breadcrumbs. The game just stalls and tears down. I'd like guidance on (a) whether vkd3d should detect this, and (b) the correct way to capture the faulting command.

Kernel log

NVRM: Xid (PCI:0000:01:00): 32, pid=21256, name=Warhammer3.exe, channel 0x00000017 intr0 00040000
NVRM: Xid (PCI:0000:01:00): 32, pid=21256, name=Warhammer3.exe, channel 0x00000017 intr0 00040000

intr0 0x00040000 = bit 18 = NV_PPBDMA_INTR_0_PBENTRY — an invalid pushbuffer entry (malformed command/control dword in that channel's pushbuffer content, per dev_pbdma.ref.txt). Single channel 0x17; the GPU stayed up and only that channel was reset.

Environment

GPU: RTX PRO 6000 Blackwell Max-Q Workstation Edition, 97887 MiB, VBIOS 98.02.6A.00.03
Driver: 610.43.02; Kernel 7.0.11 (CachyOS / Arch); KDE Plasma — KWin Wayland
Proton: proton-cachyos cachyos-11.0-20260601
DXVK (reported in same log): v2.7.1-715-geae756358b52bed; vkd3d-proton as bundled in that proton-cachyos build
Launch: PROTON_VKD3D_HEAP=1 %command% -dx12 — VK_EXT_descriptor_heap confirmed active in the log (sampler + resource descriptor heaps created)
Display at time of fault: a TV driven off the NVIDIA card via an HDMI↔DP adapter, 1080p60 (NVIDIA scanout)

Context — why this only surfaced now

This DX12 path was previously unreachable. In DX11/DXVK the game died almost instantly from a separate descriptor-pressure fault: an Xid 31 MMU fault at a high-dword-corrupted VA (0x100_00000000), originating in vkd3d's d3d12_command_allocator_allocate_meta_index "Meta descriptor pressure → global heap" fallback, which fired ~2,000,000 times per session on this 96 GB card. PROTON_VKD3D_HEAP=1 (VK_EXT_descriptor_heap) eliminated that completely — pressure 2,067,954 → 0, no more Xid 31. With DX12 finally stable, this Xid 32 PBENTRY appeared only after a long session, which is why it looks like a DX12-command-stream issue specific to this title on Blackwell rather than the earlier descriptor problem.

Ruled out

Hardware: row-remap clean (Channel/TPC Repair Pending = No), zero ECC/hardware-class Xids (no 48/63/64/79/92/94/95), temps normal.
Not the descriptor bug: no MMU fault, no 0x100, Meta descriptor pressure count = 0 in this run's log.
Not a GPU-wide event: kernel logged only the two Xid 32 lines; no Xid 56, no FIFO/reset/recovery sequence.

Questions for maintainers

vkd3d-proton does not detect this single-channel reset as a device loss — should it? The app receives no VK_ERROR_DEVICE_LOST; it just stalls and tears down.
Because of (1), VKD3D_CONFIG=breadcrumbs produces no dump. What is the correct way to capture the offending command for a frozen-channel PBDMA PBENTRY when vkd3d never observes the loss — apitrace, a specific VKD3D_CONFIG, a hang/timeout flag, or a debug build?
Is a Blackwell host PBENTRY on the WH3 DX12 command stream a known pattern, or likely a vkd3d command-translation issue worth bisecting by version?

Repro & next steps

WH3 → DX12 (-dx12) + PROTON_VKD3D_HEAP=1 on proton-cachyos, RTX PRO 6000 Blackwell. Plays a full session, then Xid 32 on one channel. Still pinning the exact scene/action. Planned follow-ups I can provide if useful:

Display A/B: re-run with the display moved to the AMD iGPU (USB-C) instead of the NVIDIA card, to test whether channel 0x17 is the present/swapchain path (i.e. whether the fault is display-path-dependent).
Version check: re-test on a newer Proton-Experimental build (verifying the heap fix stays active / pressure = 0) to see whether the Xid 32 reproduces there.

I can attach full nvidia-smi -q, the complete PROTON_LOG, and vulkaninfo --summary on request.

Kkoodijahti 2026-06-23 github

Follow-up — two corrections + a version data point.

Reproduced on Proton-Experimental experimental-11.0-20260617 (newest vkd3d, ~16 days newer than
the cachyos-11.0-20260601 build above), heap fix still active (Meta descriptor pressure = 0, no
Xid 31):

NVRM: Xid (PCI:0000:01:00): 32, pid=42319, name=Warhammer3.exe, channel 0x00000016 intr0 00040000
NVRM: Xid (PCI:0000:01:00): 32, pid=42319, name=Warhammer3.exe, channel 0x00000016 intr0 00040000

Two corrections to the original report:

The channel is not fixed. It was 0x17 in the original log and 0x16 here — so the channel ID
isn't meaningful; the fault lands on whichever channel is executing. The only invariant is intr0
0x00040000 (PBENTRY).
Time-to-fault tracks loaded-save vs fresh-campaign, not wall-clock. The original "after an
extended session" is misleading. In practice a freshly-started campaign runs a long time before
any Xid, whereas loading a mid-campaign save reaches the fault within a turn or two of ordinary
play (seen on two different saves, turn 16 and turn 17). The turn-17 sequence: load save → end
turn 17→18 (fine) → queue some buildings → move a couple of characters around the campaign map →
channel hung. No battle, all on the campaign map. So loaded saves hit it far faster than fresh
campaigns at equivalent on-screen activity, which points at accumulated game-state/resource volume
rather than session length or linear turn count.

Possibly relevant repro modulator: the fault appears display-path/refresh dependent. On native
DisplayPort monitors at reduced refresh I can play the same campaign for many turns with no Xid;
the fast 1-turn reproductions are all on a 1080p60 TV driven through an HDMI↔DP adapter off the
same GPU. That hints the trigger is present-path / timing-sensitive rather than purely command
content. (I plan to test scanout off a second GPU to isolate this.)

Version note: both my newest vkd3d builds (cachyos Jun-1 and Experimental Jun-17) throw the
byte-identical PBENTRY, so this doesn't look like a recent regression. Bisecting older isn't
useful here — pre-VK_EXT_descriptor_heap builds reintroduce the Xid 31 MMU fault, which kills the
session before this one can surface.

Still happy to provide a full PROTON_LOG, nvidia-smi -q, or test a specific VKD3D_CONFIG capture
flag if there's a way to catch the offending command despite vkd3d not observing the channel loss.