[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] changing out-of-bounds index access to return 0 values instead of generating INVALID_OPERATION

On Tue, Jun 5, 2012 at 12:05 PM, Vladimir Vukicevic
<vladimir@mozilla.com> wrote:
> ----- Original Message -----
>> The OpenGL working group has been developing a new extension
>> (GL_ARB_robust_buffer_access_behavior) which more precisely defines
>> the behavior of out-of-range buffer accesses. Out-of-bounds reads
>> from
>> buffer objects, such as in indexed draw calls, will be allowed to
>> return either a value from within the buffer object, or 0.
>> Out-of-bounds writes can go anywhere within the buffer, or be
>> discarded.
>> I do think that we should eventually make a change to the WebGL spec
>> in this area, but it's essential to make sure that it agrees with
>> whatever is added to the OpenGL spec, so that implementations will
>> actually be able to eliminate the overhead when these extensions are
>> available. For this reason I think that we should wait until
>> GL_ARB_robust_buffer_access_behavior is ratified before changing the
>> WebGL spec. What do you think?
> Ah right, I couldn't remember the name of that extension.  The problem, as I remember, is that the behaviour will be one of two things, right?  And we need (or wanted) more determinism than that.  So we could pick one of the behaviours, and if we can get the read-0 behaviour even now, I'd say we should pick that as long as it'll be a valid behaviour option in the upcoming extension.  As for timing, I guess it depends on how long until it's ratified :)

The main problem with GL_ARB_robustness was that it still left certain
out-of-bounds access behavior undefined.
GL_ARB_robust_buffer_access_behavior fixes this. While there are still
a couple of valid behaviors, it will actually be possible to verify
them by issuing out-of-range reads against small buffers, and ensuring
that the resulting values are one of the values in the buffer, or 0.

I think it would be a mistake to specify anything different in WebGL
except exactly what GL_ARB_robust_buffer_access_behavior specifies (or
will specify). Otherwise, once that extension becomes available, it
still won't be possible to delegate to it directly; the browser will
still have to contain a lot of computationally expensive code to
emulate a particular behavior.

On Tue, Jun 5, 2012 at 12:16 PM, John Bauman <jbauman@chromium.org> wrote:
> On Tue, Jun 5, 2012 at 10:43 AM, Vladimir Vukicevic <vladimir@mozilla.com>
> wrote:
>> - It means that when we don't have out-of-bounds-returns-zero semantics on
>> the underlying implementation, implementations will have to do more work to
>> match the semantics (copying of arrays, dealing with interpolated data,
>> etc.).  It's potentially finicky and certainly computationally expensive,
>> but I'm OK with this -- if your code is using bogus indices anyway, I don't
>> really care if it's slow as a result!
> On GLES2, wouldn't implementations have to keep shadow copies of every
> vertex buffer in order to do this? Currently they only have to keep shadow
> copies of index buffers.

It's a very good point that if read-returns-0 behavior is mandated,
that this will require shadowing of vertex buffer data. This would be
another reason to allow read-returns-value-from-within-buffer
behavior; that way, only the indices would need to be shadowed and
potentially copies made and manipulated.

On Tue, Jun 5, 2012 at 12:33 PM, Gregg Tavares (社用) <gman@google.com> wrote:
> Do you have a sample that shows this overhead?
> It would be nice to verify there aren't simpler solutions (ie, optimizing)
> before changing the spec.

+1 to seeing a test case. Since GL_ARB_robustness isn't widely
deployed yet, I don't see how it'll be possible to eliminate the
overhead of scanning the indices for safety, which would defeat the
purpose of a spec change.


You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl