[WebGPU-XR] Check XRGPUBinding before native fallback - #18711
Conversation
There was a problem hiding this comment.
Pull request overview
This PR adjusts WebXRLayers.isCompatible() so native sessions are not rejected before checking whether the active engine is WebGPU and whether XRGPUBinding supports projection layers. This makes the WebGPU projection-layer path reachable on native runtimes that correctly advertise XRGPUBinding.createProjectionLayer, while keeping native WebGL on the existing legacy NativeXRRenderTarget path and preserving browser behavior.
Changes:
- Reorders compatibility checks to evaluate WebGPU +
XRGPUBinding.createProjectionLayerbefore the native WebGL fallback. - Keeps native WebGL sessions explicitly incompatible with WebXR Layers (legacy path unchanged).
- Adds unit tests covering 5 compatibility permutations across native/browser and WebGPU/WebGL.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| packages/dev/core/src/XR/features/WebXRLayers.pure.ts | Reorders isCompatible() checks to allow native WebGPU projection-layer support while retaining native WebGL fallback behavior. |
| packages/dev/core/test/unit/XR/webXRLayers.test.ts | Adds focused Vitest coverage for the compatibility matrix (native/browser × WebGPU/WebGL × binding availability). |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
I will actually ask someone from the native team to review that, because there is a reason why it is there. @bghgary @CedricGuillemet , any input here? |
|
Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s). |
|
Snapshot stored with reference name: Test environment: To test a playground add it to the URL, for example: https://snapshots-cvgtc2eugrd3cgfd.z01.azurefd.net/refs/pull/18711/merge/index.html#WGZLGJ#4600 Links to test your changes to core in the published versions of the Babylon tools (does not contain changes you made to the tools themselves): https://playground.babylonjs.com/?snapshot=refs/pull/18711/merge To test the snapshot in the playground with a playground ID add it after the snapshot query string: https://playground.babylonjs.com/?snapshot=refs/pull/18711/merge#BCU1XR#0 If you made changes to the sandbox or playground in this PR, additional comments will be generated soon containing links to the dev versions of those tools. |
⚡ Performance Test Results🟢 All performance tests passed — no regressions detected. |
🟢 Memory Leak Test Results4 passed, 0 leaked out of 4 scenarios 🟢 All memory leak tests passed — no leaks detected. Passed Scenarios (4)
|
|
Visualization tests for WebGPU |
|
WebGL2 visualization test reporter: |
RaananW
left a comment
RaananW
left a comment
There was a problem hiding this comment.
Will merge after the native team give me the OK.
CedricGuillemet
left a comment
CedricGuillemet
left a comment
There was a problem hiding this comment.
I'm not sure of all the implications this will have with native webgpu support but I guess it's fine for now.
FWIW, I'm testing with my wgpu branch in addition to the other scenarios :) |
Background
Broader WebGPU runtime testing showed that
WebXRLayers.isCompatible()rejects every native session before checking the active engine andXRGPUBindingcapabilities. A standards-compatible WebGPU runtime can therefore exposeXRGPUBinding.createProjectionLayerand still be prevented from selecting the existing WebGPU projection-layer path.Change
XRGPUBinding.createProjectionLayerbefore the native WebGL fallback.NativeXRRenderTargetpath.Tests
Adds five explicit compatibility cases:
XRGPUBindingXRWebGLBindingLocal validation:
Relation to #18688
cc @RaananW. This is intentionally separate from #18688: this PR makes the WebGPU layer provider reachable when the runtime advertises the required capability, while #18688 addresses projection/NDC and upright rendering after that layer path is active. The changes do not overlap files.