[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] ARB_robustness and array bounds checking
On Wed, Oct 26, 2011 at 11:53 AM, Chris Marrin <email@example.com> wrote:
On Oct 25, 2011, at 10:23 AM, Gregg Tavares (wrk) wrote:
> ...Requiring driver vendors to use one-of-n fallback techniques will eventually require some vendor to go down a slow path or ignore your requirements. I think the way section 4.5 is written today is sufficient. We should make section 6.4 match that, which would make it match the ARB_robustness spec. I don't have a solution for your testability requirement, and I think testability is a nice goal, but in this case not at the expense of performance.
>I don't believe testability is an overriding requirement of WebGL. It's a good goal, but I don't think it should be required in the spec. We should (continue to) strive for maximizing performance.
> This is a security issue. Doesn't Apple want to be able to verify that you can't read data you're not supposed to be able to read?
This thread started with me proposing we drop the requirement in section 6.4 that an out-of-bounds array access return an error, thus requiring expensive intervention at the WebGL layer. If the wording of section 6.4 matched that in section 4.5, then we could make WebGL implementations more performant if the driver can guarantee appropriate handling of out-of-range accesses. In particular, the wording from section 6.4:
If a vertex attribute is enabled as an array, a buffer is bound to that attribute, and the attribute is consumed by the current program, then calls to drawArrays and drawElements will verify that each referenced vertex lies within the storage of the bound buffer. If the range specified in drawArrays or any referenced index in drawElements lies outside the storage of the bound buffer, an INVALID_OPERATION error is generated and no geometry is drawn.
should be changed to:
If a vertex attribute is enabled as an array, a buffer is bound to that attribute, and the attribute is consumed by the current program, then calls to drawArrays and drawElements shall ensure that no accesses outside the bounds of that vertex buffer occur. If detected when the drawArrays or drawElements call is made, an INVALID_OPERATION error is generated and no geometry is drawn. Otherwise, at runtime and invalid access may return a constant value (such as 0), or the value at any valid index of the same vertex buffer. In this case (possibly incorrect) geometry would be rendered and no error would be generated. But no accesses outside the vertex buffer bounds would occur.
(typo: runtime and => runtime an)
This change wouldn't allow the use of GL_ARB_robustness' robust buffer access as specified today. Robust buffer access only guarantees the following: "indices within the vertex array that lie outside the arrays defined for enabled attributes result in undefined values for the corresponding attributes, but cannot result in application failure". See http://www.opengl.org/registry/specs/ARB/robustness.txt . For example, it might fetch other random data reachable by the context (and, hopefully, produced by that context).
What's the goal? To allow the use of robust buffer access as currently written, or to specify stronger guarantees for ARB_robustness and incorporate those into the WebGL spec? If the latter, then I think we should spec the stronger robust buffer access first, so that GPU vendors are on board, and we know what the parameters will be.
From a process standpoint I'd like to wait to make a change like this until after we've snapshotted the next version of the WebGL spec, because this is a significant change requiring a good deal of consideration.
I agree that it's possible for a cleverly written test to intuit the correct behavior, possibly by knowing something about the particular hardware or driver. If so, that's fine. But I don't think we should over-specify the behavior and lose performance.