[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] ARB_robustness and array bounds checking
On Oct 25, 2011, at 9:44 AM, Gregg Tavares (wrk) wrote:
> On Tue, Oct 25, 2011 at 9:29 AM, Chris Marrin <email@example.com> wrote:
> 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 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.
> That 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?
> 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.
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.
Remember that drivers stream commands. The reason it's unreasonable to require an error to be returned from, for instance, an out-of-bounds vertex array access is because there's no place to return the error. Even if you were able to stash it in glError at some later time, to which of the possibly many drawArrays calls that you made would the error correspond?
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: