[Public WebGL] WebGL2 element array buffer and copy buffer (5.1 Buffer Object Binding)

Kevin Rogovin ([email protected]) [email protected]
Mon Jul 20 13:17:14 PDT 2020


Just to be clear: I am only advocating this extension for WebGL2 ONLY
(not WebGL 1) which on MS-Windows means mapping to D3D10/D3D11/D3D12
which have robustness already anyways. For Vulkan and OpenGL support,
on desktop robust access is there already; mobile is messier (and one
can argue that my below use-case is pointless because mobile is always
shared memory, so CPU-GPU traffic is not much of a thing... but it is
still because of the wonkiness of drivers, mostly kernel side, of
allocating the memory for the buffer objects to which to stream). The
extension would have to be requested at context creation (there's the
iffy "every extension please" issue, but there are already extensions
that have that nature too, for example render to floating point
buffer).

The goal is that I am aiming to have the GPU generate an index buffer
instead of the CPU generating it each frame and sending it to the GPU
every frame. Just on using/abusing render to texture and samping from
texture from vertex shader (together with attributeless rendering) I
have use cases that doubled and even tripled performance compared to
playing buffer object ouija board with glBufferData, glBufferSubData,
pools and mucking with sizes. The benefit (for my loads) of a GPU
generated index buffer is an additional 33% performance advantage (i.e
something that is 24 ms/frame would then be like 16 ms/frame).
However, that is pointless to do if the WebGL2 implementation needs to
snoop the index buffer anyways. I am much better off then doing
non-indexed draw calls for this case. So, I'd really like to know or
have an extension that guarantees the no snoop. The extension would
also allow me to save an additional load of bandwidth copying the
buffer made to an index buffer all in one swoop that makes sense
together. After all, if the CPU must snoop, there is zero point
(nearly) for doing GPU generated index buffers.

So the extension question: is this an extension worth the time to draft?

Best Regards,
-Kevin



On Mon, Jul 20, 2020 at 10:01 PM Jeff Gilbert ([email protected])
<[email protected]> wrote:
>
>
> We would need to check whether we do indeed have RBAB everywhere we
> have WebGL2. Otherwise, we'd need more info on how this enables
> compelling workloads, to offset the downside of Apps accidentally not
> working on a number of older desktop and mobile drivers.
>
> Worth considering for your usecase (complicated vertex fetch) is
> vertex-pulling, which should be possible with vanilla WebGL 2.
>
> On Mon, Jul 20, 2020 at 5:51 AM Kevin Rogovin
> ([email protected]) <[email protected]> wrote:
> >
> > Hi,
> >
> >  Hopefully this thread necromancy will live on the correct thread still.
> >
> > > 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.
> >
> > 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.
> >
> > I can draft the extension, but I would like to feel the water on this.
> >
> > 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.
> >
> > Best Regards,
> >  -Kevin Rogovin
>
> -----------------------------------------------------------
> You are currently subscribed to [email protected]
> To unsubscribe, send an email to [email protected] with
> the following command in the body of your email:
> unsubscribe public_webgl
> -----------------------------------------------------------
>

-----------------------------------------------------------
You are currently subscribed to [email protected]
To unsubscribe, send an email to [email protected] with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------





More information about the public_webgl mailing list