[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] ARB_robustness and array bounds checking
On Tue, Oct 25, 2011 at 9:29 AM, Chris Marrin <firstname.lastname@example.org>
On Oct 24, 2011, at 10:14 AM, Gregg Tavares (wrk) wrote:
>> ...This is my recollection as well. There have been discussions in some
>> of the working groups about strengthening the guarantees inThat is very snarky and not particularly helpful. If we made "testability" a requirement, there are many drivers functions that would have to change. Look at section 4.5 of the spec. It states that all shaders "must not be allowed to read or write array elements that lie outside the bounds of the array". And then goes on to state that an implementation may generate an error or return some constant value in place of the invalid access. So why in section 6.4 do we require errors to be generated on vertex array accesses?
>> 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.
I'd say just the opposite. We should change section 4.5 of the spec to require 1 of N testable solutions. The GPU vendor can pick one of those N solutions and we and write tests that try each of the N solutions and make sure at least one of them holds true. Same for section 6.4
That seems like it fits both needs. The need be flexible and the need to be testable.
There are many error conditions that different drivers handle differently. The OpenGL specs are left purposely flexible in some areas to avoid overly constraining drivers with error handling that would be too expensive. We may be able to tighten some of the error handling requirements at the WebGL layer without adding undue overhead. But in the case of vertex array bounds checking, today's requirements add significant overhead.
> 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.