[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Public WebGL] Re: Public review of updated WEBGL_multiview extension proposal



​Any other comments on this? This is a fairly big design decision, so I'd like to get more feedback before making the change.


I think the implementation of choosing the read buffer in ANGLE would be feasible, but it would be worth it to also prototype that first.


-Olli


From: Rafael Cintron <Rafael.Cintron@microsoft.com>
Sent: Wednesday, August 30, 2017 3:40 AM
To: Olli Etuaho; Public WebGL (public_webgl@khronos.org)
Subject: RE: Public review of updated WEBGL_multiview extension proposal
 

Thank you for explaining the other variants.  I still think having a readPixels/copyTexImage2D on the extension object would be the best for web developers. 

 

From an implementation perspective, I think the component that should implement readpixels/copyTexImage2D for Multiview would be ANGLE since it already handles the scissor, viewport, etc adjustments on behalf of the outer code.

 

--Rafael

 

From: Olli Etuaho [mailto:oetuaho@nvidia.com]
Sent: Friday, August 25, 2017 3:34 AM
To: Rafael Cintron <Rafael.Cintron@microsoft.com>; Public WebGL (public_webgl@khronos.org) <public_webgl@khronos.org>
Subject: Re: Public review of updated WEBGL_multiview extension proposal

 

Thanks for the feedback Rafael,

 

the need for reads is intended to be covered like this by the current spec:

 

1) For texture array multiview framebuffers: You can read the layers by creating another framebuffer to use as a read framebuffer, and attach the layer you want to read with framebufferTextureLayer.

 

2) For opaque multiview framebuffers: Wherever the capability to generate opaque multiview framebuffers is added to a web API, the API can also provide the capability to generate secondary opaque multiview framebuffers with 1 view that point to the same underlying memory. Then the reads could be done using these secondary framebuffers.

 

Of course 2) does leave more work to be done by other web APIs - so it is a bit of a trade-off. My proposal here also means that you can't implement a function readMultiviewFramebuffer(fbo) that would work for both texture array and opaque multiview framebuffers. So maybe having a readPixels variant that takes a view index would be better, but I wanted to make sure this other alternative is understood before we start inventing additional API entry points that diverge from the native OVR_multiview spec.

 

-Olli


From: Rafael Cintron <Rafael.Cintron@microsoft.com>
Sent: Friday, August 25, 2017 4:49 AM
To: Olli Etuaho; Public WebGL (public_webgl@khronos.org)
Subject: Re: Public review of updated WEBGL_multiview extension proposal

 

The overloads could go on the extension object instead of WebGLRenderingContext.

 

--Rafael


From: owners-public_webgl@khronos.org <owners-public_webgl@khronos.org> on behalf of Rafael Cintron <Rafael.Cintron@microsoft.com>
Sent: Thursday, August 24, 2017 2:29:51 PM
To: Olli Etuaho; Public WebGL (public_webgl@khronos.org)
Subject: [Public WebGL] RE: Public review of updated WEBGL_multiview extension proposal

 

This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing

Feedback

I am very supportive of the Multiview extension.  I think it will definitely help WebVR scenarios. 

 

One aspect of the API that could use improvement is the following statement:

“The error INVALID_FRAMEBUFFER_OPERATION is generated by commands that read from the framebuffer such as BlitFramebuffer, ReadPixels, CopyTexImage*, and CopyTexSubImage*, if the number of views in the current read framebuffer is greater than 1.”

 

ReadPixels and CopyTexImage* are frequently used in test code to ensure correct rendering.  Without these APIs, writing these types of tests will be challenging.  Perhaps a future (or current?) version of the extension could add overloads to these functions that contain an additional ‘view’ integer parameter that specifies the view on which to perform the operation. 

 

--Rafael

 

From: owners-public_webgl@khronos.org [mailto:owners-public_webgl@khronos.org] On Behalf Of Olli Etuaho
Sent: Friday, August 18, 2017 6:13 AM
To: Public WebGL (public_webgl@khronos.org) <public_webgl@khronos.org>
Subject: [Public WebGL] Public review of updated WEBGL_multiview extension proposal

 

Hello all!

 

We have a significantly updated version of the WEBGL_multiview extension proposal, and kindly request the community's feedback on it so we can incorporate the feedback and proceed to move the extension to draft:

 

https://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_multiview/

 

I hope this addresses the major concerns people had with regards to the extension in the previous discussion earlier during the year.

 

The extension is now self-contained and is designed not to require any amendments to the core WebGL spec. But since enabling the implementation of a zero-copy multiview pipeline is still a goal, an "opaque multiview framebuffer" abstraction has been added to the extension proposal. This is a type of a multiview framebuffer that other web APIs like WebVR would be able to create, and that would work also with WebGL 1.0. The specific shape of the WebVR API to create this type of framebuffers will still need to be specified within the WebVR working group.

 

We have also worked on implementing functionality that would be required by the extension in ANGLE, and the new revision of the proposal has taken findings from that work into account. Particularly, we've removed restrictions on shaders since we found out the restrictions won't be necessary for good performance. On the other hand, we've added some minor restrictions that are required by a performant implementation on top of OpenGL and Direct3D, like baseViewIndex having to match between different framebuffer attachments.

 

Regards, Olli