Repository navigation
Asynchronously allocate WebXR Layers' GPU-side resources #252
Description
The WebXR spec is using promises in many places but not for the layers creation, which expect to throw the OperationError in the createLayer calls if resource allocation fails:
- Allocate and initialize resources compatible with session’s XR device, including GPU accessible memory buffers, as required to support the compositing of layer.
- If layer’s resources were unable to be created for any reason, throw an OperationError and abort these steps.
Because of this UA's might need to add a blocking ipc/queue call in the JS process if GPU resources are allocated in another process or queue. Would it be worth it to add an async API for layer creation? Or any way to report the OperationError later?
I created a related issue for XRWebGLLayer: immersive-web/webxr#1177
Activity
cabanier commentedon Mar 5, 2021
I agree that this is a problem in the spec and the implementation is running a blocking IPC call to create these swapchains.
Would it work that we defer the creation of the GPU resources until the pending render state finishes?
It's not possible to use the layer object until it is part of the
layersarray. This could cause some frame glitches though as it might take longer to create the layer then the next Raf callback.cabanier commentedon Mar 5, 2021
Thinking about this a bit more, how is this different from regular WebGL?
It also lets you create textures and framebuffers synchronously.
I think that we should the spec as folllows:
getSubImageandgetViewSubImageare allowed to throw an OperationError if the allocation failedgetSubImageandgetViewSubImageon a layer that is not in thelayersarray must be flagged as an error.cabanier commentedon Mar 5, 2021
/agenda should we make the layer creation function asynchronous?
MortimerGoro commentedon Mar 5, 2021
I like this approach if we can move as many static checks as possible to the place of steps 18 and 19. Ideally if the createLayer calls succeed it should be very unlikely that the internal allocation of the swapchain fails. So we'd need to make sure that all the format, size and other not supported checks are checked as early as possible.
cabanier commentedon Mar 10, 2021
@MortimerGoro I made the changes to the spec.
We talked about this in the meeting and for now I didn't change that
getSubImageandgetViewSubImageare allowed to throw errors because finishing the allocation is allowed to happen later.Let me know if you're OK with these updates.
MortimerGoro commentedon Mar 11, 2021
@cabanier I'm OK with the updates. Only one question, in case the allocation fails later, where is the OperationError triggered?
cabanier commentedon Mar 11, 2021
We had a short discussion on how for framebuffers, you can check their status but there isn't something similar for textures.
I think we still have some work to do in this area because it is possible to run out of GPU memory. How does this suface in WebGL?
MortimerGoro commentedon Mar 11, 2021
ok, I can only think of isTexture but that doesn't check allocation AFAIK, only that it was created using createTexture or similar.
Other option would be to consider the not propertly allocated opaque texture as an invalid color/depth attachment to the framebuffer that uses it, so checkFramebufferStatus could be used. The problem with this is that it might conflict with other typical errors from framebufferTexture2D attachment calls, confusing users to think they have invalid code when the opaque texture allocation failed instead.
I think we need to first decide if "not propertly allocated opaque texture" instance can exist at all or it's handled via some exception.
There is a OUT_OF_MEMORY error in WebGL/GL. I guess running out of memory could also lose the WebGL context.
cabanier commentedon Mar 16, 2021
I agree. If such a texture type can't exist this means that the checking should be complete by
getSubImage/getViewSubImagetime.Otherwise, we would need to generate an exception, or simply ignore the rendering and flag the error through some event.