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

Re: [Public WebGL] Need to spec range checking for WebGL ANGLE_instanced_arrays?




On 3/25/2014 3:50 PM, Kenneth Russell wrote:
On Tue, Mar 25, 2014 at 9:13 AM, Vladimir Vukicevic
<vladimir@mozilla.com> wrote:
Indeed.  I didn't see such a query in this extension, but that would be
ideal.  Even better would be an extension that would let you specify a
specific behaviour, even at a performance cost.  The driver can almost
certainly do a more efficient job at protecting/checking this than something
sitting on top of GL can.
GL_ARB_robust_buffer_access_behavior is in fact the extension allowing
the choice of behavior; it requires a new flag to be specified during
context creation.
Hmm, no, I meant to specify specific behaviour, not an "or" behaviour. That is, I want to specify "always return 0 on out of bounds reads", even if that would result in a performance hit.

I'm not sure I agree with the assertion that the robustness and robust
buffer access behavior specs, even in their current form, are not
useful for speeding up WebGL. Depending on the amount of undefined
behavior the WebGL community is willing to accept, it would be
possible to use these extensions to use the driver's or GPU's security
mechanisms more directly.
I thought the goal was to not have this kind of undefined behaviour? It's the type of thing that can lead developers to "accidentally depend" on an implementation that returns 0 for out-of-bounds, for example, or to discard an oob write, and have the code break on other hardware where they clamp to in-bounds indexes. At that point it becomes hard to decide where to draw the line where this type of undefined behaviour is OK.

But I definitely understand the pragmatism. So maybe we're trying to go too far with "no undefined behaviour" -- after all, the cases where we're going through lots of hoops to avoid it are almost always actual programming errors. Maybe we should just focus on that... for example, maybe we should have a WebGL "strict mode" where there is no undefined behaviour at all, or where things such as this are explicitly errors? It would be work, and would require the ability to do things like rewrite shaders on the fly to range check, but it might be worth it.

     - Vlad


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