Require compositor sync for WebGPU XR texture writes

[cabanier]

I was trying to optimize the texture handling during complex WebXR sessions to make the WebGPU flow similar to WebGL.
I'm unsure if this clarification is needed in the spec but it seems that the browser needs to be able to wait for the work to be finished before submitting to the compositor and this is not mentioned. This language impacts how we can wait for work to be completed during a frame.

---

Preview | Diff

[AdaRoseCannon]

@mwyrzykowski is probably the better than me for review for this

[mwyrzykowski]

WebGPU guarantees read / write hazards must not occur in general, so do we need to explicitly call it out? What do you think @toji ?

[cabanier]

@mwyrzykowski I think it is still worth calling out here. WebGPU handles hazards within WebGPU work, but the XR compositor is an external consumer of these textures and this spec is defining that handoff point. It seems that for the "regular" flow to an HTML page the flushing is defined.

There is similar precedent in both WebGL and WebXR's WebGL path.
From WebGL, The Drawing Buffer:

WebGL presents its drawing buffer to the HTML page compositor immediately before a compositing operation...

and:

Before the drawing buffer is presented for compositing the implementation shall ensure that all rendering operations have been flushed to the drawing buffer.

WebXR has even closer language for XRWebGLLayer:

the content of the opaque framebuffer is presented to the immersive XR device immediately after an XR animation frame completes

and:

Before the opaque framebuffer is presented to the immersive XR device the user agent shall ensure that all rendering operations have been flushed to the opaque framebuffer.

WebGPU defines the queue/completion model, but not this XR compositor handoff. For example, Queue timeline:

Associated with the execution of operations on the compute units of the GPU. It includes actual draw, copy, and compute jobs that run on the GPU.

So I don't think this is trying to restate WebGPU's internal hazard guarantees. It is specifying that after the application submits WebGPU work for an XRFrame, the UA must not let the XR compositor consume the current XR textures before the relevant writes are visible, either by waiting for that work or by making the compositor depend on it on the GPU side.

This also matches how WebXR/WebGPU samples are written: they submit frame work with GPUQueue.submit() and return from the XR animation frame callback; they do not call GPUQueue.onSubmittedWorkDone() before returning.
Authors are not expected to do that for every XR frame.

[mwyrzykowski]

I see no harm in adding it 👍

[toji]

Agreed that there's no harm adding this. The XR compositor is intentionally very loosely defined, so I think it's reasonable to assume that it's not implied to be implemented as a WebGPU process when WebGPU is used, and thus may need some additional synchronization.