[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 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. The thought was that the "or" statements in the spec
would still allow conformance tests to be written. If a given
out-of-range access of a buffer object could return either 0 or a
value within the buffer, then for a sufficiently small source buffer,
the vertex shader could still verify that the value fetched from the
buffer was one of the (known) values in the buffer. That was the plan
for using this extension in WebGL implementations while still having a
conformance test.

It's been difficult to reach agreement among GPU vendors regarding
what guarantees to provide about out-of-range accesses. It's
understandable that it's not possible to implement certain types of
array range checking, for example within uniform buffer objects,
without severe performance penalties. I thought that Direct3D 10
specified that out of range fetches from buffers returned 0, but am
having difficulty finding this in the online documentation.

> So I don't see this extension as actually providing any significant
> performance benefit for WebGL, unfortunately.  Even the fully-defined texel
> fetches on incomplete textures language doesn't help.. what WebGL considers
> incomplete and what OpenGL considers incomplete might differ (WebGL might
> have a stricter definition, e.g. if relevant WebGL extensions aren't
> enabled).

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.

As a concrete example, the WebGL conformance suite could be changed to
stress out-of-range accesses of buffers of various kinds, but instead
of checking for errors or specific rendering results, simply assert
that the test must successfully run to completion instead of crashing.
Unfortunately, this wouldn't allow direct testing of the spec text
stating that buffer fetches must not allow data outside the buffer to
be read.

Security is the most important attribute of the WebGL API, and it's
essential to preserve its security properties as new features are
added from OpenGL ES 3.0 and 3.1. The WebGL working group will
highlight again to the OpenGL and OpenGL ES WGs the need to specify
the behavior and make it robust in order to expose these features to
the web.

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