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

Ken Russell ([email protected]) [email protected]
Tue Jul 21 17:53:45 PDT 2020


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.

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.

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 https://github.com/KhronosGroup/WebGL, even better.

(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.)

Thanks much,

-Ken



On Mon, Jul 20, 2020 at 2:56 PM Kevin Rogovin ([email protected])
<[email protected]> wrote:

>
> 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
> -----------------------------------------------------------
>
>

-- 
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20200721/e8979838/attachment.html>


More information about the public_webgl mailing list