Skip to content

qemu: do not pick D3DMetal on Intel Macs - #8042

Open
nightness wants to merge 1 commit into
utmapp:mainfrom
nightness:macos/intel-dxmt-default
Open

nightness wants to merge 1 commit into
utmapp:mainfrom
nightness:macos/intel-dxmt-default

Conversation

@nightness

Copy link
Copy Markdown

D3DMetal requires Apple silicon. On an Intel Mac its DXGIFactory checks for Apple silicon, shows an alert and exits. With the DirectX driver left at Default, which picks D3DMetal whenever D3DMetal.framework is bundled, the render server worker for every guest D3D context dies, and the Windows desktop never renders through Neptune. canRunD3DMetal returned true for every x86_64 build.

On x86_64, D3DMetal is now allowed only when the process is translated by Rosetta (sysctl.proc_translated == 1), which means an x86_64 build running on Apple silicon. Intel Macs fall back to DXMT, as they already do when D3DMetal is not bundled. The Settings picker uses the same check, so it no longer offers D3DMetal on Intel.

This touches the x86_64 branch of canRunD3DMetal. #8018 changes the arm64 branch of the same function; the two don't overlap in behavior.

Resolves #8040

Related: #8041, utmapp/qemu#17, utmapp/dxmt#1, utmapp/dxmt#2

Testing: Tested by a human on MacBook Pro 2017 (Intel Core i7-7700HQ, Radeon Pro 560), macOS 15.8.1 (OpenCore Legacy Patcher), with an x86_64 build (with #8041 applied so GPU acceleration works unsigned), D3DMetal.framework bundled, the DirectX driver at Default, and a Windows 11 x64 guest (viogpu3d v0.5).

  • Before: the bug reproduced. UTM set NPT_BACKEND=d3dmetal, every render server worker exited right after npt: Neptune renderer initialized (worker … exited with status 16777215), and the guest display stalled.
  • After: UTM picks DXMT (npt: loaded D3D11 library: …/dxmt-native.framework/…), contexts and rings are created, and the desktop composites at 1440x900.

The author acknowledges that this change has been tested and/or reviewed by a human in accordance with UTM's AI contribution guidelines.

D3DMetal requires Apple silicon. On an Intel Mac its DXGIFactory checks for
Apple silicon, shows an alert and exits, so with the DirectX driver left at
Default (which picks D3DMetal whenever it is bundled), the render server
workers for every guest D3D context die and the Windows desktop never
renders. canRunD3DMetal returned true for every x86_64 build.

On x86_64, only allow D3DMetal when the process is translated by Rosetta
(sysctl.proc_translated), that is when an x86_64 build runs on Apple
silicon. Intel Macs then fall back to DXMT, as they already do when D3DMetal
is not bundled.

Resolves: utmapp#8040

Assisted-by: Claude:claude-opus-5-5
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[x86_64] Windows 3D: D3DMetal hangs the render server on Intel Macs (should fail or default to DXMT); working path + fixes

1 participant