<div dir="ltr">WebGL's API structure and restrictions have been designed from the beginning to enable maximum portability of content. This is one area that has the potential to prevent content from running on a significant fraction of devices.<div><br></div><div>As a concrete example, Apple and Google are collaborating to upgrade WebKit's WebGL 2.0 implementation, and iOS' OpenGL ES driver does not advertise support for robust buffer access behavior. It may in fact have that behavior under the hood - we'd need to test with some content - but if not, and if Safari on iOS had WebGL 2.0 support, I'm pretty sure you wouldn't want your content to run everywhere except there.<br><div><br></div><div>Could you please share the source code of some example which can demonstrate the performance difference? Feel free to write the "before" and "after" cases, with the expectation that the "after" case won't work. I can help you measure its performance on a browser that lifts the restrictions on element array buffers' usage. If you'd propose it as a pull request under sdk/demos/ on <a href="https://github.com/KhronosGroup/WebGL">https://github.com/KhronosGroup/WebGL</a>, even better.</div><div><br></div><div>(I fully recognize that there's likely a large performance gain to be had here, but it's important to motivate this to the community and not just develop an extension for one particular customer's use case.)</div><div><br></div><div>Thanks much,</div><div><br></div><div>-Ken</div><div><br></div></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 20, 2020 at 2:56 PM Kevin Rogovin (<a href="mailto:kevinrogovin@invisionapp.com">kevinrogovin@invisionapp.com</a>) <<a href="mailto:public_webgl@khronos.org">public_webgl@khronos.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Hi,<br>
<br>
 Like I said I can make it work without the extension, but with the<br>
extension I am looking at a 33% performance gain, which is a big deal.<br>
<br>
 I confess I do not really follow the portability objection: I'd check<br>
for the extension and if it existed would use GL_ELEMENT_ARRAY_BUFFER<br>
binded buffers more freely and if not, then not (and just lose the<br>
performance gain). Just as the case for applications use<br>
EXT_color_buffer_float.<br>
<br>
-Kevin<br>
<br>
On Mon, Jul 20, 2020 at 11:44 PM Jeff Gilbert (<a href="mailto:jgilbert@mozilla.com" target="_blank">jgilbert@mozilla.com</a>)<br>
<<a href="mailto:public_webgl@khronos.org" target="_blank">public_webgl@khronos.org</a>> wrote:<br>
><br>
><br>
> I would try vertex pulling or other index-buffer-data caching<br>
> mechanisms before making the case for this extension, given the<br>
> portability concerns I mentioned.<br>
><br>
> On Mon, Jul 20, 2020 at 1:18 PM Kevin Rogovin<br>
> (<a href="mailto:kevinrogovin@invisionapp.com" target="_blank">kevinrogovin@invisionapp.com</a>) <<a href="mailto:public_webgl@khronos.org" target="_blank">public_webgl@khronos.org</a>> wrote:<br>
> ><br>
> ><br>
> > Just to be clear: I am only advocating this extension for WebGL2 ONLY<br>
> > (not WebGL 1) which on MS-Windows means mapping to D3D10/D3D11/D3D12<br>
> > which have robustness already anyways. For Vulkan and OpenGL support,<br>
> > on desktop robust access is there already; mobile is messier (and one<br>
> > can argue that my below use-case is pointless because mobile is always<br>
> > shared memory, so CPU-GPU traffic is not much of a thing... but it is<br>
> > still because of the wonkiness of drivers, mostly kernel side, of<br>
> > allocating the memory for the buffer objects to which to stream). The<br>
> > extension would have to be requested at context creation (there's the<br>
> > iffy "every extension please" issue, but there are already extensions<br>
> > that have that nature too, for example render to floating point<br>
> > buffer).<br>
> ><br>
> > The goal is that I am aiming to have the GPU generate an index buffer<br>
> > instead of the CPU generating it each frame and sending it to the GPU<br>
> > every frame. Just on using/abusing render to texture and samping from<br>
> > texture from vertex shader (together with attributeless rendering) I<br>
> > have use cases that doubled and even tripled performance compared to<br>
> > playing buffer object ouija board with glBufferData, glBufferSubData,<br>
> > pools and mucking with sizes. The benefit (for my loads) of a GPU<br>
> > generated index buffer is an additional 33% performance advantage (i.e<br>
> > something that is 24 ms/frame would then be like 16 ms/frame).<br>
> > However, that is pointless to do if the WebGL2 implementation needs to<br>
> > snoop the index buffer anyways. I am much better off then doing<br>
> > non-indexed draw calls for this case. So, I'd really like to know or<br>
> > have an extension that guarantees the no snoop. The extension would<br>
> > also allow me to save an additional load of bandwidth copying the<br>
> > buffer made to an index buffer all in one swoop that makes sense<br>
> > together. After all, if the CPU must snoop, there is zero point<br>
> > (nearly) for doing GPU generated index buffers.<br>
> ><br>
> > So the extension question: is this an extension worth the time to draft?<br>
> ><br>
> > Best Regards,<br>
> > -Kevin<br>
> ><br>
> ><br>
> ><br>
> > On Mon, Jul 20, 2020 at 10:01 PM Jeff Gilbert (<a href="mailto:jgilbert@mozilla.com" target="_blank">jgilbert@mozilla.com</a>)<br>
> > <<a href="mailto:public_webgl@khronos.org" target="_blank">public_webgl@khronos.org</a>> wrote:<br>
> > ><br>
> > ><br>
> > > We would need to check whether we do indeed have RBAB everywhere we<br>
> > > have WebGL2. Otherwise, we'd need more info on how this enables<br>
> > > compelling workloads, to offset the downside of Apps accidentally not<br>
> > > working on a number of older desktop and mobile drivers.<br>
> > ><br>
> > > Worth considering for your usecase (complicated vertex fetch) is<br>
> > > vertex-pulling, which should be possible with vanilla WebGL 2.<br>
> > ><br>
> > > On Mon, Jul 20, 2020 at 5:51 AM Kevin Rogovin<br>
> > > (<a href="mailto:kevinrogovin@invisionapp.com" target="_blank">kevinrogovin@invisionapp.com</a>) <<a href="mailto:public_webgl@khronos.org" target="_blank">public_webgl@khronos.org</a>> wrote:<br>
> > > ><br>
> > > > Hi,<br>
> > > ><br>
> > > >  Hopefully this thread necromancy will live on the correct thread still.<br>
> > > ><br>
> > > > > ANGLE does use the GPU for robust buffer access when using the D3D11 backend (most windows users).  D3D9 always validates index ranges on the CPU.  We also rely on the Vulkan or OpenGL extensions to do it when available on other platforms.<br>
> > > ><br>
> > > > What do people think of having an extension for WebGL2 that: removes the restriction jazz of ELEMENT_ARRAY_BUFFER and gives an assurance to an application that robust access is used for fetching vertices via an index buffer, i.e. the implementation won't induce a CPU inspect of an index buffer.<br>
> > > ><br>
> > > > I can draft the extension, but I would like to feel the water on this.<br>
> > > ><br>
> > > > My use case, which a follow up question on a different thread will address in more detail, is for GPU generated index buffers. Right now, I have scenes where instancing is not sufficient but I manage to get the GPU to generate my vertex buffers entirely. I have  a scene of 1.5 million vertices; for these loads the actual vertex count is 1 million and the index count is 1.5 million.; getting the index buffer generated by GPU is a big performance gain for these kinds of scenes (something like 3N ms/frame without index buffer and 2N ms/frame with index buffer) for some value of N.<br>
> > > ><br>
> > > > Best Regards,<br>
> > > >  -Kevin Rogovin<br>
> > ><br>
> > > -----------------------------------------------------------<br>
> > > You are currently subscribed to <a href="mailto:public_webgl@khronos.org" target="_blank">public_webgl@khronos.org</a>.<br>
> > > To unsubscribe, send an email to <a href="mailto:majordomo@khronos.org" target="_blank">majordomo@khronos.org</a> with<br>
> > > the following command in the body of your email:<br>
> > > unsubscribe public_webgl<br>
> > > -----------------------------------------------------------<br>
> > ><br>
> ><br>
> > -----------------------------------------------------------<br>
> > You are currently subscribed to <a href="mailto:public_webgl@khronos.org" target="_blank">public_webgl@khronos.org</a>.<br>
> > To unsubscribe, send an email to <a href="mailto:majordomo@khronos.org" target="_blank">majordomo@khronos.org</a> with<br>
> > the following command in the body of your email:<br>
> > unsubscribe public_webgl<br>
> > -----------------------------------------------------------<br>
> ><br>
><br>
> -----------------------------------------------------------<br>
> You are currently subscribed to <a href="mailto:public_webgl@khronos.org" target="_blank">public_webgl@khronos.org</a>.<br>
> To unsubscribe, send an email to <a href="mailto:majordomo@khronos.org" target="_blank">majordomo@khronos.org</a> with<br>
> the following command in the body of your email:<br>
> unsubscribe public_webgl<br>
> -----------------------------------------------------------<br>
><br>
<br>
-----------------------------------------------------------<br>
You are currently subscribed to <a href="mailto:public_webgl@khronos.org" target="_blank">public_webgl@khronos.org</a>.<br>
To unsubscribe, send an email to <a href="mailto:majordomo@khronos.org" target="_blank">majordomo@khronos.org</a> with<br>
the following command in the body of your email:<br>
unsubscribe public_webgl<br>
-----------------------------------------------------------<br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>I support flexible work schedules, and I’m sending this email now because it is within the hours I’m working today.  Please do not feel obliged to reply straight away - I understand that you will reply during the hours you work, which may not match mine.</div><div><br></div></div></div>