[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
As someone who is being bit by this issue (many buffer switches with high overhead) I'd love to see some work done here to make common-cases faster. Development-time tooling (webgl-debug/etc, or built into the browser dev tools such as the warnings you mention) is much more useful here than the INVALID_OPERATION error as one should only ever be tracking these kinds of issues in debug code -- no one should ever be calling getError after each draw in production, so they'd never see it anyway!
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):
- 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.
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: