On Oct 21, 2011, at 11:10 AM, Kenneth Russell wrote:
On Fri, Oct 21, 2011 at 10:02 AM, Gregg Tavares (wrk) <firstname.lastname@example.org> wrote:
On Fri, Oct 21, 2011 at 8:20 AM, Chris Marrin <email@example.com> wrote:
Currently the WebKit implementation of WebGL keeps around the currentindex array so it can be used to do bounds checking on draw calls. This ismandated in section 6.4 of the spec. The ARB_robustness extension requires
that out-of-bounds array accesses be forbidden. But by my reading it doesn'trequire the behavior mandated in the WebGL spec. They simply guarantee thatno fetches outside the array will happen. Compliant behavior would be to
simply return 0 values for these accesses. So bounds checking on the WebGLside would still be required.If this is the case, I think we should make changes so driversimplementing this extension can avoid the WebGL side bounds checking. I'mnot sure it's practical to change the ARB_isolation extension at this point.
So I would be in favor of changing section 6.4 of the spec to match thebehavior required in the extension.If I understand correctly the issue with ARB_isolation is there is no
guarantee the driver is obeying anything. It doesn't report errors for outof bounds access so there is no way to test that it's actually working. For
WebGL we wanted something testable as far as I remember.
This is my recollection as well. There have been discussions in some
of the working groups about strengthening the guarantees in
ARB_robustness' robust buffer access: for example, either clamping the
access to within the buffer, or returning a specified constant value,
so that the extension's behavior is testable. Otherwise the best test
that can be written is one which accesses wildly out-of-range values
and passes if it doesn't crash, which isn't very good.I'm not sure I understand the issue. ARB_robustness states that out-of-bounds accesses are forbidden. Do we care if an error is reported or not? The only thing that would help with is debugging. And we can always add a debugging extension like the two we already have which would do bounds checking and report errors as stated in today's spec. But it would be nice if we could avoid this overhead for hardware that complies with ARB_robustness.