Summary
Switching Windows graphics API to Vulkan (m_APIs: 15000000 first in ProjectSettings.asset) causes the app to crash inside xrCreateSession. The plugin's session-creation code at native~/displayxr_hooks.cpp:722-741 has no Vulkan branch on Windows:
#if defined(_WIN32)
if (item->type == XR_TYPE_GRAPHICS_BINDING_D3D12_KHR) { ...d3d12... }
else if (item->type == XR_TYPE_GRAPHICS_BINDING_D3D11_KHR) { ...d3d11... }
#elif defined(__APPLE__)
if (item->type == ...METAL_KHR) { ...metal... }
#endif
When Unity uses Vulkan, s_backend = nullptr and downstream code crashes. The log line at native~/displayxr_hooks.cpp:710 is also misleading:
[DisplayXR] Graphics binding: VULKAN (via MoltenVK on macOS)
— fires unconditionally, suggesting the original author assumed Vulkan only ever came from macOS + MoltenVK.
Crash signature
displayxr_unity!<unknown>
UnityOpenXR!session_RequestExitSession
UnityEngine.XR.OpenXR.OpenXRLoaderBase:Internal_CreateSessionIfNeeded
UnityEngine.XR.OpenXR.OpenXRLoaderBase:StartInternal
Why it matters
Discovered while investigating XR eye-texture MSAA on Windows (companion issue: "Build-path silhouette aliasing"). Unity OpenXR on Vulkan historically has different MSAA handling than D3D12 — Vulkan on Windows is a plausible workaround path for the silhouette aliasing problem if the plugin supported it. Currently can't even test the hypothesis.
Scope
Add a Windows-capable Vulkan backend mirroring the structure of native~/displayxr_d3d12_backend.cpp. The existing native~/displayxr_vulkan_backend.cpp (currently macOS-only via MoltenVK) and native~/displayxr_standalone_vulkan.cpp (SA-session Vulkan path) likely have reusable code.
Also fix the misleading log message to reflect the actual platform.
Acceptance
- App doesn't crash with
m_APIs: 150000001200000002000000 (Vulkan first, D3D12/D3D11 fallback) in test-transparent's ProjectSettings.asset.
displayxr.log shows a correct Vulkan binding line.
- Ghost asset renders without geometric corruption.
- Bonus: MSAA probe in
TransparentAutoSetup shows whether Vulkan unlocks XR.eye.msaa > 1 (the original question we wanted to answer).
Summary
Switching Windows graphics API to Vulkan (
m_APIs: 15000000first inProjectSettings.asset) causes the app to crash insidexrCreateSession. The plugin's session-creation code atnative~/displayxr_hooks.cpp:722-741has no Vulkan branch on Windows:When Unity uses Vulkan,
s_backend = nullptrand downstream code crashes. The log line atnative~/displayxr_hooks.cpp:710is also misleading:— fires unconditionally, suggesting the original author assumed Vulkan only ever came from macOS + MoltenVK.
Crash signature
Why it matters
Discovered while investigating XR eye-texture MSAA on Windows (companion issue: "Build-path silhouette aliasing"). Unity OpenXR on Vulkan historically has different MSAA handling than D3D12 — Vulkan on Windows is a plausible workaround path for the silhouette aliasing problem if the plugin supported it. Currently can't even test the hypothesis.
Scope
Add a Windows-capable Vulkan backend mirroring the structure of
native~/displayxr_d3d12_backend.cpp. The existingnative~/displayxr_vulkan_backend.cpp(currently macOS-only via MoltenVK) andnative~/displayxr_standalone_vulkan.cpp(SA-session Vulkan path) likely have reusable code.Also fix the misleading log message to reflect the actual platform.
Acceptance
m_APIs: 150000001200000002000000(Vulkan first, D3D12/D3D11 fallback) in test-transparent'sProjectSettings.asset.displayxr.logshows a correct Vulkan binding line.TransparentAutoSetupshows whether Vulkan unlocksXR.eye.msaa > 1(the original question we wanted to answer).