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

Ken Russell ([email protected]) [email protected]
Wed Jul 22 10:55:43 PDT 2020


Understood that you can't share the source code for your project.

Please do create an example, even artificial. There's no urgent rush. It's
very important for motivating such a significant change to WebGL's API.

Thanks,

-Ken



On Wed, Jul 22, 2020 at 12:33 AM Kevin Rogovin ([email protected])
<[email protected]> wrote:

>
> Hi,
>
>  I *really* cannot share the source code for the project; I can
> generate a toy example but the toy will be terribly artificial. Due to
> the complexity this is going to take a few days; I will need to beg to
> my bosses for that time.
>
> My aim is that I will check for the extension that would allow for
> copies directly to index buffer and if it was not present, just assume
> that robust access is also not present on device and skip the index
> buffer completely to achieve compatibility with such devices (and
> avoid the danger that the CPU might snoop the GPU buffer).
>
> Best Regards,
>  -Kevin
>
> On Wed, Jul 22, 2020 at 3:54 AM Ken Russell ([email protected])
> <[email protected]> wrote:
> >
> > 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.
> >
>
> -----------------------------------------------------------
> 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/20200722/d4c15b8e/attachment.html>


More information about the public_webgl mailing list