[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 <firstname.lastname@example.org>
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):
I believe this is tested by the D3D10 DTM tests.
This hardware wouldn't necessarily do this in D3D9 or OpenGL, though, because for example the driver may combine buffers when uploading, and not bother to set the limits that would cause draw calls to return zeros. Also, ANGLE would need to walk streaming or dynamic vertex buffers anyway, to determine what portions to upload with a draw call.
- 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!
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 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.
You are currently subscribed to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: