[Public WebGL] Oversight in bufferData and bufferSubData specification

Gregg Tavares (wrk) [email protected]
Mon May 23 15:10:28 PDT 2011


Whether or not WebGL supports Float64 internally is irrelevant.

bufferData and bufferSubData do NOT use the type information from the buffer
views. Pretending they do by banning one of the views is pointless.



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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20110523/78d7d46d/attachment.html>


More information about the public_webgl mailing list