[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] ARB_robustness and array bounds checking
On Mon, Oct 24, 2011 at 10:05 AM, Chris Marrin <email@example.com>
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
On Fri, Oct 21, 2011 at 8:20 AM, Chris Marrin <email@example.com> wrote:
Currently the WebKit implementation of WebGL keeps around the current
index array so it can be used to do bounds checking on draw calls. This is
mandated 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't
require the behavior mandated in the WebGL spec. They simply guarantee that
no fetches outside the array will happen. Compliant behavior would be to
simply return 0 values for these accesses. So bounds checking on the WebGL
side would still be required.
If this is the case, I think we should make changes so drivers
implementing this extension can avoid the WebGL side bounds checking. I'm
not 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 the
behavior 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 out
of 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.
Not to be snarky but seriously? How many driver bugs have we found? And we want trust that some untestable feature is actually working? If it's not testable then it's not tested. If it's not tested it's not working.
It would also be nice if the behavior was consistent because if drivers handle this differently (some return a specific value, others return the ends of arrays, others return a different value) you can be sure that people will ship apps, see that it works on their own hardware and then only later find that it's draw crazy stuff on other hardware.