[macOS] 3D rendering SIGSEGV: MoltenVK null subpass in secondary command buffers under VK_KHR_dynamic_rendering (Apple Silicon)

[yasser159]

Summary

On Apple Silicon (M4 Pro / macOS 26, GeneralsXZH weekly-2026-05-29 + retail 1.04 data), 3D rendering crashes with a SIGSEGV once draws are submitted. The 2D shell/menu renders and the swapchain initializes fine; the crash is consistently in MoltenVK's VK_KHR_dynamic_rendering path when DXVK records draws into secondary command buffers (vkCmdExecuteCommands). This appears to be the blocker behind "3D rendering: under active testing".

Root cause (in MoltenVK, not GeneralsX)

MVKCommandEncoder::getSubpass() returns nullptr while encoding a secondary command buffer's draws under dynamic rendering (the encoding-context render pass isn't established for the secondary path — beginSecondaryEncoding() doesn't set it up). Multiple encoder sites then dereference the null subpass / unset state. Guarding each one advances the crash to the next:

1) MVKRenderSubpass::getSampleCount()                 (this == null)
   <- MVKCommandEncoder::beginMetalRenderPass / setSubpass
2) MVKMetalGraphicsCommandEncoderState::prepareDraw +92  (subpass->isMultiview(), subpass null)
3) MVKMetalGraphicsCommandEncoderState::bindState  +424  (unset draw state)
   <- finalizeDrawState <- MVKCmdDrawIndexed::encode <- encodeSecondary <- MVKCmdExecuteCommands

Faulting addresses are small offsets off a null base (0x8, 0x3b0, 0x3f8) — classic null-this/null-member derefs.

Diagnostics & partial guards (attached)

I added null/bounds guards at the MoltenVK encoder sites (getSampleCount, getSubpass derefs, prepareDraw). Each one moves the crash one layer deeper (getSampleCount → prepareDraw → bindState), confirming a cascade rather than a single bug. These guards are diagnostic band-aids, not a fix — even fully guarded, the secondary-CB draws would render with unbound state. The correct fix is to establish the render-encoder/subpass state for secondary command buffers that inherit dynamic rendering (or to avoid emitting secondary CBs for these draws). Patch with the guards attached for reference.

Repro

• Build: GeneralsXZH (weekly-2026-05-29 and from-source main), MoltenVK 1.4.350-era.
• Launch with -win (shell-map 3D) → crash ~10s at Maps\ShellMapMD render; with -win -noshellmap → reaches menu, crashes ~48–75s once menu/secondary-CB draws occur.
• A repeatable test harness (launch + intro-skip + crash-frame capture) is available; happy to share.

Environment

M4 Pro, macOS 26.x, retail 1.04 .big data, DXVK 2.6 (fork), MoltenVK from VulkanSDK 1.4.350 (identical to the bundled build).

This may warrant an upstream MoltenVK issue (secondary command buffers + VK_KHR_dynamic_rendering); filing here first since it's the macOS-3D blocker. Glad to help test fixes.

[yasser159]

Useful config finding: dxvk.tilerMode = False avoids the secondary-CB cascade

DXVK only uses secondary command buffers when perfHints().preferPrimaryCmdBufs is false. On Apple Silicon that hint is false (dxvk_device.cpp: matchesDriver(VK_DRIVER_ID_MESA_HONEYKRISP) || !tilerMode — MoltenVK isn't Honeykrisp, and Apple GPUs are tilers). Forcing dxvk.tilerMode = False in dxvk.conf flips preferPrimaryCmdBufs → true, so DXVK records draws into the primary command buffer and the secondary-CB null-subpass crash disappears.

Verified progression (M4 Pro, macOS 26):

• default: crash in secondary-CB path (encodeSecondary → prepareDraw), ~48–60s
• dxvk.tilerMode = False: secondary path gone; crash moves to the primary path (MVKMetalGraphicsCommandEncoderState::bindState, still a null getSubpass() in the depth/stencil block) ~60s
• + MVK_CONFIG_PREFILL_METAL_COMMAND_BUFFERS=2 (immediate encoding): advances past the MoltenVK null; next crash is in Apple's AGX driver (setAndBindRenderTarget, bus error) ~74s

So tilerMode=False is a useful mitigation that sidesteps one whole class of these crashes. The remaining ones (getSubpass() null on the primary path in bindState, then AGX) are the deeper layers. getSubpass() returning null during draw encoding (even on the primary path) looks like the core gap — the encoding-context render pass isn't consistently set when DXVK's dynamic-rendering draws are encoded.