fix(webgpu): WebGPU XR rendering on Apple Vision Pro#8756
Merged
Conversation
Fixes #8755. - WebgpuGraphicsDevice#setViewport / setScissor skip the underlying passEncoder calls when the backbuffer is bound to an XR projection-layer texture. visionOS Safari treats an explicit scissor call as a positional hint for the eye-display sub-region (even at the attachment extent), clipping the rendered content to a sub-rectangle of the eye. The default scissor (= attachment) works correctly, so we leave it untouched. See https://bugs.webkit.org/show_bug.cgi?id=315274. - frameStart tracks the backbuffer's intrinsic width/height to the actual output texture (canvas swapchain or XR projection layer) so downstream viewport / Y-flip math uses the right extent. - WebXR runtime view descriptors are passed through to createView as-is, preserving the runtime's per-eye format (e.g. sRGB view over a linear texture) instead of clobbering it with a format override. - xr-bridge prefers the view descriptor's format for the per-view viewFormat so the render pipeline matches what the view sees. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
mvaligursky
added
area: graphics
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Related to #8755.
WebGPU+WebXR was rendering only into a sub-rectangle of each eye on Apple Vision Pro. Root cause is a visionOS Safari quirk where any explicit
passEncoder.setScissorRect(...)call (even one equal to the WebGPU pass-start default = full attachment) is interpreted as a positional hint for the eye-display sub-region, clipping the content. Upstream WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=315274.Changes
WebgpuGraphicsDevice#setViewport/#setScissor— early-return without calling the underlyingpassEncodermethods whenthis.xrColorTextureis set. The default viewport/scissor (= attachment extent) is what AVP needs to map the projection-layer texture across the full eye. Shadow state is deliberately not updated either, so non-XR cache checks aren't poisoned.frameStart— track the backbuffer's intrinsic_width/_heightto whatever texture we're rendering into this frame (canvas swapchain or XR projection layer), instead of falling back todevice.widthvia the getter.WebgpuRenderTarget#assignColorTexture— pass the WebXR runtime's per-eye view descriptor through tocreateViewas-is, preserving itsformat(e.g. sRGB view over a linear texture) instead of clobbering with a separate format override.WebgpuXrBridge#beginFrame— preferviewDescriptor.formatfor the per-viewviewFormatso the render pipeline format matches what the view will see.