FNV (22380): Goodsprings exteriors 8-15 FPS and GPU faults (BIF0 page fault / MTL_COMMAND_QUEUE_ERROR_TIMEOUT) on M2 Pro #27

Game: Fallout: New Vegas (appid 22380) — 32-bit x86, Direct3D 9

Environment

• Mac14,9 MacBook Pro, Apple M2 Pro (10 CPU cores, 16 GPU cores), 16 GB, macOS 26.6.2 (25G83)
• FX Steam Launcher 1.9.1 (es.fxgam.steamac@1.9.1+2d9331c109), notarized build
• SteamOS 7.2.9-steamac, image 20261007.6125817 (0.4.5), branch stable, Steam client deck
• Proton Experimental (ARM64) + Steam Linux Runtime 4 arm64, auto-selected by Steam
• DXVK 3.1.1-97-ga78a467cadb22be (from the Proton log)
• VM flags: --display 1280x720 --mem 6144 --cmdline "... steamac.gpu_mib=3072" --perf-stats

Game settings
1280x720 fullscreen, V-Sync on, "Ultra" preset, antialiasing 0, anisotropic 4x,
shader grass off, water reflections/refractions/displacements off, LOD object fade 3.0.

What works

The whole stack initialises correctly. The FNV launcher detects
Virtio-GPU Venus (Apple M2 Pro), so D3D9 really goes through DXVK → Venus →
Metal (no wined3d fallback). Menus and the 2D UI hold a locked 60 FPS
(16.7 ms). The game loads, saves work, and it is playable indoors at ~40 FPS.

Problem 1 — exteriors collapse to 8–15 FPS

Goodsprings exterior, same settings:

perf: flush n=66 p50/p95/p99/max=73.0/92.3/99.7/101.6 >25=66 >50=66
     shown p50/p95/p99/max=66.7/100.0/100.0/100.0  vsyncs(60 Hz) 4:33 5:26 6:5

Median frame consumes 4–6 refresh intervals (67–100 ms). Individual frames of
933 ms, 2567 ms and 3967 ms also appear. ioreg reports the real Apple GPU at
66 % Device/Renderer Utilization during this, while the in-game HUD shows
8 % GPU and 6 % CPU — the guest's own counters do not reflect host GPU load,
which made this look CPU-idle at first.

Because the work is per-frame GPU time and not fill rate, dropping resolution
is not a fix: 720p → 640x360 did not change the character of the problem, and
the numbers above already imply that no resolution makes 60 FPS reachable.

Problem 2 — GPU faults, two different drivers

MoltenVK (default). While playing the exterior the whole Mac froze; recovery
needed a power-cycle. DiagnosticReports:

gpuEvent-steamac-vm  restart_reason 3  "BIF0 page fault"
  bif0_fault: {"is_read": true, "address": 90426675200, "sideband": 39}
gpuEvent-WindowServer / gpuEvent-<other hosts>  restart_reason 10  "MMU interrupt"
WindowServer_...userspace_watchdog_timeout.spin: WindowServer main thread blocked in
  Metal → IOGPU → IOGPUFamily → AGXG14X, watchdog fires after 5.58 s
ResetCounter...: "Boot faults: btn_rst,finger_reset force_off"  (hard reset)

KosmicKrisp (--vulkan-driver kosmickrisp). Confirmed active
(libvulkan_kosmickrisp.dylib mapped in the VM process). The game crashed
during a save load with:

MESA: error: VK_ERROR_DEVICE_LOST: Command queue error 1
(MTL_COMMAND_QUEUE_ERROR_TIMEOUT), with message "The operation couldn't be
completed. (MTL4CommandQueue ...)"

and a host-side MMU interrupt at the same moment. This time the GPU firmware
recovered instead of wedging the machine.

So the two Vulkan-on-Metal backends fail differently on the same workload —
one with a GPU page fault, one with a command-queue watchdog timeout — both
consistent with frames that take 100 ms to several seconds.

Things that are not the cause

• VRAM starvation: reproduced at steamac.gpu_mib=2048 and 3072, and outdoors
  the GPU is only ~66 % busy.
• Shader compilation at load: MTLCompilerService was idle when sampled during
  the 8 FPS gameplay; Steam Shader Pre-Caching is on.
• Guest OOM: nothing in the guest journal, free shows several GB available.
• Missing D3DX9: Proton ships d3dx9_24..43 in both system32 and syswow64.

Separate, smaller issue: the DirectX redist hangs on every launch

Steam's first-run legacycompat script runs
Steamworks Shared/_CommonRedist/DirectX/Jun2010/DXSETUP.exe, whose
infinst.exe D3DX9_40_x64.inf step hangs indefinitely under FEX (it was still
at ~1.6 % CPU after 10 minutes, blocking the launch). Creating
HKLM\Software\Valve\Steam\Apps\22380 did not make Steam skip it. Renaming
DXSETUP.exe makes the step fail fast so the game proceeds — harmless, since
Proton provides D3DX9. Worth handling upstream if FNV is meant to be a
supported title.

Questions

1. Is the Goodsprings slowdown the expected ceiling for 32-bit D3D9 through
   Venus on M2-class hardware, or a bug?
2. For the GPU faults — is there a launcher/VM environment variable to capture
   a more detailed Venus/MoltenVK command stream trace at the moment of the
   BIF0 page fault / MTL_COMMAND_QUEUE_ERROR_TIMEOUT?
3. Would either backend be expected to survive frames longer than Metal's
   command-buffer watchdog, or is the fix necessarily to make frames short?

Happy to run any instrumented build and return logs — the VM, the disk image
and the game install are all reproducible on this machine.