[Public WebGL] Oversight in bufferData and bufferSubData specification

Ben Vanik [email protected]
Mon May 23 14:56:44 PDT 2011


I haven't been keeping up on WebCL, but that may likely have 64-bit float
support and want to add it for interop with WebGL. In such a case that they
do this (probably via an extension) you'd want symmetry between the APIs for
all the buffer sharing scenarios and end up adding a WebGL extension to
support DOUBLE.

On Mon, May 23, 2011 at 2:47 PM, Kenneth Russell <[email protected]> wrote:

>
> On Mon, May 23, 2011 at 2:24 PM, Chris Marrin <[email protected]> wrote:
> >
> > On May 23, 2011, at 11:33 AM, Kenneth Russell wrote:
> >
> >>
> >> On Sat, May 21, 2011 at 11:14 AM, Gregg Tavares (wrk) <[email protected]>
> wrote:
> >>>
> >>>
> >>> On Sat, May 21, 2011 at 12:16 AM, Kenneth Russell <[email protected]>
> wrote:
> >>>>
> >>>> On Fri, May 20, 2011 at 8:17 PM, Gregg Tavares (wrk) <[email protected]
> >
> >>>> wrote:
> >>>>> Why does it matter?
> >>>>> in real GL, bufferData and bufferSubData just take void* and a length
> so
> >>>>> it
> >>>>> seems like any ArrayBufferView should be valid.
> >>>>> I can do this now
> >>>>> gl.bufferData(gl.ARRAY_BUFFER, someUint8BufferView);   // upload
> bytes,
> >>>>> gl.vertexAttribPointer(0, 3, gl.FLOAT, ...)   // use as floats
> >>>>> or visa versa
> >>>>> gl.bufferData(gl.ARRAY_BUFFER, someFloat32BufferView);   // upload
> >>>>> floats,
> >>>>> gl.vertexAttribPointer(0, 3, gl.BYTE, ...)   // use as bytes
> >>>>> so why does it matter that I can upload a Float64Array? What I upload
> >>>>> and
> >>>>> how I used it are not related in WebGL
> >>>>
> >>>> Misinterpretation or reinterpretation of uploaded data is irrelevant.
> >>>> OpenGL ES 2.0 does not support double-precision floating point values
> >>>> at all and neither does WebGL. Uploading a Float64Array into a buffer
> >>>> object will only result in garbage values that can not be properly
> >>>> referenced as vertex attributes.
> >>>>
> >>>> From the standpoint of strongly typing the IDL, only the
> >>>> ArrayBufferView subclasses that can legally be used in the API should
> >>>> be accepted. If a future version of WebGL begins to accept
> >>>> double-precision floating-point values, then the IDL could either be
> >>>> changed to add overloads taking Float64Array, or could be changed back
> >>>> to what it is now, taking the superclass ArrayBufferView.
> >>>
> >>> I don't agree. bufferData doesn't have a type like texImage2D so you
> can't
> >>> validate that they are passing in valid data. It's not worth
> complicating
> >>> the IDL or even checking for this case IMO.
> >>> I can download float32 data and do this
> >>> var bogusView = new Float64Array(someFloat32Array);
> >>> gl.bufferData(gl.ARRAY_BUFFER, bogusView);  // Shouldn't matter. I'm
> still
> >>> uploading Float32 data.
> >>> Why does it matter? Changing this will not add even 1 bit of safety. In
> fact
> >>> as it is now you can upload an ArrayBuffer, untyped. There is zero need
> to
> >>> check for Float64Array since the API can't validate any of the other
> cases.
> >>> There is no reason to complicate it now for one out of million cases.
> >>
> >> Supporting uploading of Float64Arrays with no error reporting at all
> >> gives the incorrect impression that such data can somehow be validly
> >> referenced on the GPU, which it can't in the OpenGL ES 2.0 API. At a
> >> minimum I think that an OpenGL error should be raised if one is passed
> >> to bufferData or bufferSubData.
> >
> > It can be validly uploaded. To WebGL, it's just a bunch of bytes. The
> interpretation on the other end is up to the GPU. WebGL doesn't define
> support for 64 bit floats. But it would be completely reasonable to define
> some sort of extension that would require its support. So I think it would
> be a mistake to add logic to disallow it.
>
> OpenGL ES 2.0 does not support 64-bit floats at all, not even via an
> extension, and I think it is unlikely that support will be added to
> mobile hardware within at least several years, if ever. Therefore any
> WebGL extension adding 64-bit float support would be desktop-only, and
> so far the working group has shied away from defining such extensions.
>
> -Ken
>
> -----------------------------------------------------------
> 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
> -----------------------------------------------------------
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20110523/e06822be/attachment.html>


More information about the public_webgl mailing list