Guarantees about layer texture shape

Right now the explainer indicates that for any given layer you request a sub image for each view/eye and it returns a combination of a GPUTexture and a view descriptor. This implicitly allows a very wide range of texture shapes to be returned:

• An array texture with a layer per view.
• A single texture with separate viewports for each view (XRWebGLLayer-style).
• A separate texture per view.
• A 3D texture with a depth slice per view.
• Some absolutely insane combination of the above.

While the API shape accommodates any of that , it would be a good idea (in my opinion) to limit the possible texture shapes that can be returned from the API so that developers have some guarantees about the patterns that can be used safely.

For example: If each view corresponds with a separate texture or layer you can safely clear the texture with every render pass. However if each view corresponds to a viewport into a single larger texture then you have to make sure you only clear the texture on the first render pass (WebGPU has no built-in way to clear only a subsection of a render attachment, so you would end up overwriting the first view's rendering on the second pass.) On the other hand, if using the multiple-viewport pattern some developers would be inclined to try and render both views in a single render pass. That would fail if some browsers returned a single texture and others returned an array texture.

Furthermore, some techniques such as multiview rendering rely on the render target being an array texture. While the technique is not supported in WebGPU today if we want to plan for it in the future we would either need to mandate array texture usage today or introduce a configuration option in the future that allows developers to require that a layer is backed by an array texture.

I seem to recall discussing this in the past with @cabanier and I believe that at the time we were both in favor of requiring WebGPU textures to always be array textures (when multiple views are necessary, anyway). Still, it would be good to confirm that and get the decision recorded in the repo. 😁

(One last consideration: If we DID constrain the API to only return array textures we might want to take a moment to re-evaluate the API shape because then there would be no specific reason to return the texture on a per-sub-image basis.)

CC @mwyrzykowski

Start with the explainer's current per-view sub-image texture and view-descriptor API, then review the listed texture-shape options and their rendering consequences. Confirm whether multiple-view layers should require array textures and record the decision in the repository; if the API changes, reassess whether the texture needs to be returned per sub-image.