[Public WebGL] Oversight in bufferData and bufferSubData specification

Kenneth Russell [email protected]
Mon May 23 11:46:33 PDT 2011


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.

> 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.

-Ken

> -----
> ~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