[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:14 AM, Gregg Tavares (wrk) <firstname.lastname@example.org> wrote:
> On Mon, Oct 24, 2011 at 10:05 AM, Chris Marrin <email@example.com> wrote:
>> 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
>> require the behavior mandated in the WebGL spec. They simply guarantee
>> 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
>> 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.
>> 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
> 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.
I agree with Gregg. In this key area it's crucial to be able to test
that the guaranteed behavior is working.
Let's push for more tightly defining the behavior for out of range
buffer accesses. At a minimum, we should try to understand what can be
supported today, and is likely to be supportable on future hardware.
You are currently subscribed to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: