[Public WebGL] Oversight in bufferData and bufferSubData specification

Chris Marrin [email protected]
Mon May 23 14:27:39 PDT 2011


On May 23, 2011, at 11:46 AM, Kenneth Russell wrote:

> On Mon, May 23, 2011 at 11:23 AM, Chris Marrin <[email protected]> wrote:
>> 
>> On May 20, 2011, at 6:50 PM, Kenneth Russell wrote:
>> 
>>> 
>>> In the bufferData and bufferSubData variants taking ArrayBufferView,
>>> we failed to specify what happens if a Float64Array is passed.
>>> http://www.khronos.org/registry/webgl/specs/latest/#5.12 mentions that
>>> Float64Array can not be used with WebGL, but does not specify what
>>> happens if an attempt is made.
>>> 
>>> The other entry points which take ArrayBufferView (readPixels,
>>> texImage2D, texSubImage2D) also take a type enum, and generate
>>> INVALID_OPERATION if that type enum and the type of the
>>> ArrayBufferView do not match. Therefore, these entry points will
>>> already generate INVALID_OPERATION in this case.
>>> 
>>> Options seem to be:
>>> 
>>> 1. Generate an INVALID_VALUE OpenGL error if a Float64Array is passed.
>>> 2. Change the IDL in the WebGL spec to explicitly enumerate all of
>>> the ArrayBufferView subclasses accepted for bufferData, bufferSubData,
>>> readPixels, texImage2D, and texSubImage2D.
>>> 
>>> Firefox 4 currently has a bug where it silently accepts Float64Arrays
>>> for bufferData, so some change is definitely needed.
>>> 
>>> I would probably recommend (2) despite the slight explosion in the IDL
>>> because it's most compatible with the intent of the spec. This would
>>> mean that an exception would be raised per the Web IDL spec.
>> 
>> Enumerating types wouldn't prevent errors in all cases. If you pass an ArrayBuffer that happens to contain Float64 data, either in its entirety or interleaved with other types of data, there would be no way to detect the error. There's also no way to detect the error when you pass a Float32 array and you should have passed in an Int32 array.
> 
> Yes, both of these are true.
> 
>> There are cases where it might be perfectly valid to pass a Float64Array to bufferData. The author might be storing 64 bit floats interleaved with other data types.  With proper offsets the 64 bit floats would be ignored by the WebGL drawing commands. The author might be passing the data as a Float64Array because the first data value happens to be a 64 bit float and passing it makes the offsets come out right. I'm not saying that's the best way to manage your WebGL buffers, but it is a reasonable thing to do.

> 
> This sounds like a pretty esoteric use case. The 64-bit floating point
> data would only be legally accessible on the CPU due to OpenGL ES 2.0
> API restrictions, but the rest of the data would be being uploaded to
> the GPU. Presumably once the other data is uploaded to the GPU, the
> CPU side copy should be discarded, but that wouldn't be possible
> because of the data interleaving. This would result in two times the
> space being consumed, part on the GPU and part on the CPU, than
> otherwise should be.

But doing such a thing would be legal and I see no reason to protect an author from doing it. The amount of data being transferred might be minuscule compared to the convenience of keeping the data together. That's for the author to decide.

> 
> 
>> I don't think we can or should put any restrictions the types passed to bufferData.
> 
> I think that at least some error check should be done here since it's
> very unlikely that a developer would intentionally try to upload a
> Float64Array. Generating an INVALID_VALUE OpenGL error would be fine
> but I think that at least some check is needed.

As I mentioned in my other post, we may have extensions in the near future that require 64 bit float support. I wouldn't want to avoid such error checking when such an extension were enabled. I just don't see why we should prevent this...

-----
~Chris
[email protected]




-----------------------------------------------------------
You are currently subscribed to [email protected]
To unsubscribe, send an email to [email protected] with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------




More information about the public_webgl mailing list