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

Kevin Rogovin ([email protected]) [email protected]
Mon Jul 20 14:55:41 PDT 2020


Hi,

 Like I said I can make it work without the extension, but with the
extension I am looking at a 33% performance gain, which is a big deal.

 I confess I do not really follow the portability objection: I'd check
for the extension and if it existed would use GL_ELEMENT_ARRAY_BUFFER
binded buffers more freely and if not, then not (and just lose the
performance gain). Just as the case for applications use
EXT_color_buffer_float.

-Kevin

On Mon, Jul 20, 2020 at 11:44 PM Jeff Gilbert ([email protected])
<[email protected]> wrote:
>
>
> I would try vertex pulling or other index-buffer-data caching
> mechanisms before making the case for this extension, given the
> portability concerns I mentioned.
>
> On Mon, Jul 20, 2020 at 1:18 PM Kevin Rogovin
> ([email protected]) <[email protected]> wrote:
> >
> >
> > 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
> > -----------------------------------------------------------
> >
>
> -----------------------------------------------------------
> 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