[Public WebGL] Index Validation and using the same buffer for both GL_ARRAY_BUFFER and GL_ELEMENT_ARRAY_BUFFER

Kenneth Russell [email protected]
Wed Jan 13 11:32:39 PST 2010

On Tue, Jan 12, 2010 at 4:36 PM, Chris Marrin <[email protected]> wrote:

> On Jan 12, 2010, at 3:23 PM, Gregg Tavares wrote:
> > I was in the process of writing some index validation code before calling
> glDrawElements and I found out that apparently some WebGL implementations
> currently assume that the same buffer will never be used for both a
> >
> > as in
> >
> >     buf = ctx.createBuffer();
> >     ctx.bindBuffer(ctx.ARRAY_BUFFER, buf);
> >     ctx.bindBuffer(ctx.ELEMENT_ARRAY_BUFFER, buf);
> >
> > The spec does not disallow this.
> >
> > My understanding is the reason some implementations assumed this would
> never happen was that to efficiently validate the indices, client side
> shadow copies of the buffer data needed to be kept. If there is an
> assumption that any buffer bound to GL_ELEMENT_ARRAY_BUFFER will only ever
> be bound to GL_ELEMENT_ARRAY_BUFFER then only the few buffers that are bound
> to GL_ELEMENT_ARRAY_BUFFER need to be shadowed.
> I will assume you're talking about the WebKit implementation. When I did
> that, I tried not to make an assumption that they would be different
> buffers. It tried to keep information about both types separate so a single
> buffer could represent both. If you use the same buffer for both you'd be
> shadowing much more than you needed to, but I think it should still work.
> Let me know what the case is where this will fail if the same buffer is used
> for both and we can see if it can be fixed.

The case that will fail is:

  - Bind the buffer to ARRAY_BUFFER
  - Use bufferData to upload unsigned byte or short data which will be
treated as indices
  - Unbind the buffer
  - Bind the buffer to ELEMENT_ARRAY_BUFFER
  - Call drawElements, referring to the previously uploaded data as indices

Because the buffer was bound to ARRAY_BUFFER when the data was uploaded, the
WebKit index validation code won't keep a client-side copy.

Possible solutions include:

  1. Keep a client-side copy of *all* data uploaded to buffer objects. Very
wasteful of memory.
  2. Lazily pull back data from buffer objects bound to ELEMENT_ARRAY_BUFFER
using glMapBuffer when they are referenced from drawElements. Once
client-side data exists for a buffer object, always keep it in sync during
bufferData and bufferSubData calls.
  3. Forbid binding the same buffer object to the ARRAY_BUFFER and
ELEMENT_ARRAY_BUFFER points in the WebGL spec.

We should keep in mind that hardware and drivers are moving in the direction
where index clamping will be done in hardware.

I'm not sure whether solution (3) would impact any real-world apps; I
haven't seen any demos which would be affected.

Personally I would prefer (3), with (2) as an alternative, but not (1).


> The problem is that makes these implementations fail if the user does use
> the same buffer for both as in the example above.
> >
> > If this optimization is important than it seems like we should make it
> part of the spec and require that a buffer can only be ever bound to one or
> the other. That way, we'll get the same results on all implementations.
> Otherwise, it seems like we need a conformance test to make sure
> implementations are not taking this shortcut as programs that are spec
> compliant will only run on some implementations.
> If it turns out to be problematic to use the same buffer for both we should
> talk about disallowing it. But let's make sure we can't make an efficient
> implementation without that restriction first.
> Vlad, have you written this code for Mozilla? Are you having issues with a
> common buffer and shadowing?
> -----
> ~Chris
> [email protected]
> -----------------------------------------------------------
> You are currently subscribe to [email protected]
> To unsubscribe, send an email to [email protected] with
> the following command in the body of your email:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20100113/91f18450/attachment.html>

More information about the public_webgl mailing list