[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 10:43 AM, Vladimir Vukicevic
<vladimir@mozilla.com> wrote:
>
> Howdy,
>
> We've got a couple of demos where the app is changing buffers pretty frequently, and the buffer index range checking is taking up significant amounts of time.  We have to do this because the WebGL spec currently requires generating an INVALID_OPERATION error if the index buffer contains an index that's out of bounds for the bound arrays.  Our algorithm there could certainly be better, but this is one of the most significant costs a well-written app has to pay even if it's doing everything right.
>
> ARB_robustness unfortunately does not guarantee any particular behaviour, though I believe that DX10 class hardware will always return 0 values for out of bounds access (as required by DX10).  (Note that there's still a bunch of stuff that needs to be verified here -- for example, does DX10 class hardware do this even when executing DX9 code, as it would with ANGLE?  Does all DX10 hardware do this correctly [is it required by WHQL?])  If the verifications pan out, I propose that we change the spec to match this behaviour.  This has a couple of properties (both pros and cons):
>
> - With a hardware/driver whitelist, or perhaps on windows just checking "is DX10 + ARB_robustness supported", we can completely get rid of the performance bottleneck on modern hardware; this is the main goal, and it means zero penalty for correctly written apps.  Vendors could even expose a no-op extension (EXT_out_of_bounds_index_access_returns_zero or something) to indicate this explicitly.
>
> - 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!
>
> - It removes the INVALID_OPERATION error.  This is actually less desirable, but I suggest that implementations print a warning to the console saying something like "Invalid indices detected; draw operation will be slow!".  We'll only detect that if we don't have the proper hardware semantics though, so we should consider adding a new webgl hint, something like WEBGL_DEBUG_CHECKS_ENABLED that will turn on explicit index checking and any other checks that we can think of even in the presence of proper hardware semantics.
>
> I realize that this is an incompatible spec change, but I don't believe content will be affected -- any content that is doing this currently will be getting an INVALID_OPERATION error.  There could potentially be content that wasn't checking for errors and ended up having these draws be no-ops which could suddenly draw garbage, but that's all the more reason to fix it.
>
> Thoughts?

Hi Vlad,

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?

-Ken

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