[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Need to spec range checking for WebGL ANGLE_instanced_arrays?

On 3/24/2014 11:40 PM, Mark Callow wrote:

On 2014/03/25 3:36, Vladimir Vukicevic wrote:

"Out-of-bounds reads may return values from within the buffer object or zero. Out-of-bounds writes may modify values within the buffer object or be discarded."

The "or" statements there are problematic for WebGL, are they not?
I thought a query had been added so that an app. can determine the implementation's behavior. Perhaps I am confusing this with another extension. With such a query it becomes possible to write a test.

Indeed.  I didn't see such a query in this extension, but that would be ideal.  Even better would be an extension that would let you specify a specific behaviour, even at a performance cost.  The driver can almost certainly do a more efficient job at protecting/checking this than something sitting on top of GL can.

They provide a security benefit, but for any other buffer accesses (e.g. those added in a future WebGL 2/ES3.0/ES3.1), it seems that WebGL implementations will still need to do the validation and emulation of zero-read/no-op-write at which point the value of ARB_rbab for performance reasons goes down significantly.
I don't understand this point. What other way of accessing the buffer can there be other than read and write?

For a WebGL based on ES 3.1 we will need to consider SSBOs, images and textures. We should probably push for a new robustness extension that covers those as well as buffer objects.

Sorry, I meant accessing buffers used as something other than vertex arrays.. though now that I read the actual GL spec in conjunction with the extension, I see that the section in the extension that actually defines the desired behaviour (0 on read, discard on write) is only for client-side vertex arrays (section 2.8).  WebGL doesn't have or use client-side vertex arrays.  Vertex arrays in buffer objects is section 2.9, and it has the "or" language.. so it can't be depended on without a query to see what actually happens.

So I don't see this extension as actually providing any significant performance benefit for WebGL, unfortunately.  Even the fully-defined texel fetches on incomplete textures language doesn't help.. what WebGL considers incomplete and what OpenGL considers incomplete might differ (WebGL might have a stricter definition, e.g. if relevant WebGL extensions aren't enabled).

    - Vlad