Define WebGPU layer creation and texture lifecycle - #37
Conversation
Specify projection and non-projection layer creation using the layer types defined by the WebXR Layers API. Define user-agent-managed texture sets, frame-scoped GPUTexture acquisition and expiration, compositor synchronization, and WebGPU layer teardown. Align XRGPUBinding method organization and validation with XRWebGLBinding, and remove the unstable API markup.
|
I know that this is a large change. @toji, would it help if I break it into at least 2 patches so the layer changes are more clear? |
|
@mwyrzykowski is probably better equipped to look at this than I |
|
I put an html version of the updated spec here: https://cabanier.github.io/WebXR-WebGPU-Binding There's a fair number of changes that come from the |
|
/agenda discuss layer support for WebGPU |
toji
left a comment
toji
left a comment
There was a problem hiding this comment.
Not a full review yet, but posting what I have so far. Will try and finish reviewing tomorrow.
| using |binding|'s [=XRGPUBinding/device=] with the storage properties described by | ||
| |motionVectorDescriptor|. Otherwise, set its motion vector resource to `null`. | ||
| 1. If the user agent was unable to allocate any resource for |textureSet|, release every | ||
| resource allocated by these steps and throw an {{OperationError}} {{DOMException}}. |
There was a problem hiding this comment.
This is worth comparing to WebGPU's canvas context texture handling. https://gpuweb.github.io/gpuweb/#dom-gpucanvascontext-configure
In that case, if textures can't be allocated (do to OOM or a validation failure of the configuration) then error textures are returned. These are textures that have the right "shape" in that the set all the attributes as expected but any attempt to use them "dirties" the whole pass and you just get black output with a validation error.
Wether or not we want to carry that pattern into WebXR's integration with WebGPU is worth discussing.
There was a problem hiding this comment.
/agenda discuss error handling when textures can't be allocated
Replace the nonexistent GPUTexture size property with width, height, and depthOrArrayLayers for color, depth-stencil, and motion-vector textures.
|
/agenda discuss error handling when textures can't be allocated (#37 (comment)) |
toji
left a comment
toji
left a comment
There was a problem hiding this comment.
Got through createProjectionLayer() today. 😅 I'll wrap up the remainder soon! Thanks for your patience!
| * {{GPUTextureDescriptor/dimension}} set to {{GPUTextureDimension/"2d"}}. | ||
| * {{GPUTextureDescriptor/format}} set to |format|. | ||
| * {{GPUTextureDescriptor/usage}} set to |usage|. | ||
| * {{GPUTextureDescriptor/viewFormats}} set to an empty sequence. |
There was a problem hiding this comment.
Not necessary to discuss as part of this change, but we might want to consider whether or not viewFormats should be exposed as part of the layer creation args? It's primary purpose is to make it easier to support sRGB rendering.
| <div class="algorithm" data-algorithm="destroy a WebGPU-backed layer"> | ||
|
|
||
| ### getViewDescriptor ### {#xrgpusubimage-getviewdescriptor} | ||
| When {{XRCompositionLayer/destroy()}} is invoked on a [=WebGPU-backed layer=] |layer|, the user |
There was a problem hiding this comment.
Perhaps I'm just missing it, but I went searching for some spec language either here or in the base layers spec that details how the session should deal with having a destroyed layer in it's layers array. I don't think we have anything about that? That's worth spelling out explicitly, but that probably also belongs in the based layers API.
There was a problem hiding this comment.
yeah. I'll file an issue in the layers spec.
| The <dfn dict-member for="XRGPULayerInit">viewPixelHeight</dfn> member specifies the height, in pixels, of each view's texture. | ||
|
|
||
| The <dfn dict-member for="XRGPULayerInit">layout</dfn> member specifies the {{XRLayerLayout}} of the layer. | ||
| The <dfn dict-member for="XRGPULayerInit">layout</dfn> member specifies the {{XRLayerLayout}} of the layer. {{XRLayerLayout/"default"}} is not valid for non-projection layers created by an {{XRGPUBinding}}. |
There was a problem hiding this comment.
This is a departure from WebGL, right? I don't recall if it was discussed prior to this or not, sorry, just want to make sure that we have the reasoning for it documented somewhere.
(Assuming that it is different than the WebGL layers behavior, maybe a note calling attention to that would be appropriate?)
There was a problem hiding this comment.
No, it's the same in the layers spec.
Co-authored-by: Brandon Jones <tojiro@gmail.com>
State that expiring color, depth-stencil, and motion-vector textures terminates write access without destroying their underlying storage.
Place projection layer creation and its texture sizing helper before the non-projection layer helpers to improve specification flow.
Allocate motion-vector textures only for projection layers with a usable depth aspect, keeping stencil-only and depthless layers on the normal rendering path. Split ignoreDepthValues initialization between mandatory space-warp depth use and implementation-selected reprojection, and align the subimage, viewport, and Space Warp prose with those conditions.
toji
left a comment
toji
left a comment
There was a problem hiding this comment.
Github is falling over apparently and won't let me review your latest changes? I can still see the correct prievew, though, so I can say that overall the rest of the changes looked good. Two more comments and then I'll re-review once you've resolved the outstanding issues and Github lets me see the diff. 😅
Document why quad and cylinder layers accept all XRSpace values while equirect and cube layers require non-viewer reference spaces. Remove the redundant prose form of getSubImage's layers feature check while retaining the normative algorithm step.
3 participants
Preview | Diff