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

Re: [Public WebGL] OES_texture_half_float doesn't allow Tex(Sub)Image2D to take ArrayBuffers as input



On Wed, Feb 12, 2014 at 10:32 PM, Vladimir Vukicevic
<vladimir@mozilla.com> wrote:
>
>
> ----- Original Message -----
>> From: "Jeff Gilbert" <jgilbert@mozilla.com>
>>
>> I agree that trying to spec a Float16Array is out of scope, but it's
>> completely possible to have a blob (or user-JS-packed data) that it would be
>> desirable to upload. Just as we allow for types like UNSIGNED_SHORT_5_6_5 to
>> be represented by Uint16 arrays, it seems reasonable to allow HALF_FLOAT to
>> be, as well.
>>
>> Even with a lack of typed array, it should still be possible to submit a raw
>> blob untyped ArrayBuffer of the right size.
>> I'm going to submit a quick PR of this.
>
> Huh, I've just assumed this was always in there!  Using a raw ArrayBuffer is problematic, because we don't have a way to refer to a sub-ArrayBuffer.  IMO, we should accept a Uint16Array, to match common the common storage data format in native OpenGL usage.
>
> And on that note, I'm going to propose an extension soonish to do the ArrayBuffer case -- add entry points that take an ArrayBuffer, offset, length.  I've seen JS code that runs into this where it loads a blob of data from network/file/wherever and then wants to upload it needing to create a bunch of unnecessary views.  We're also running into this a lot with Emscripten/asm.js code, where the views end up being unnecessary GC objects created/destroyed where we have no need of any GC objects.

Allocation of these objects should be cheap in most JavaScript engines
today, and as I pointed out before, taking ArrayBufferView here
instead of ArrayBuffer offers some semblance of type checking of the
incoming data. Also, uploading and updating textures is already a
relatively expensive operation. Do you have data that shows a marked
performance increase by adding overloads taking raw ArrayBuffers?

-Ken



>     - Vlad
>
>> ----- Original Message -----
>> From: "Kenneth Russell" <kbr@google.com>
>> To: "Jeff Gilbert" <jgilbert@mozilla.com>
>> Cc: "public webgl" <public_webgl@khronos.org>
>> Sent: Wednesday, February 12, 2014 4:54:00 PM
>> Subject: Re: [Public WebGL] OES_texture_half_float doesn't allow
>> Tex(Sub)Image2D to take ArrayBuffers as input
>>
>> This limitation was deliberate, because there is no ArrayBuffer view
>> type which supports working with half-float data. The main use case
>> for half-float textures is memory reduction compared to 32-bit float
>> textures when using them as render targets.
>>
>> C source code is available which can pack and unpack values into and
>> from 16-bit floats, and it might be possible to translate this code to
>> JavaScript. I'm not sure whether JavaScript provides the necessary
>> math primitives. See
>> http://en.wikipedia.org/wiki/Half-precision_floating-point_format and
>> the references at the bottom.
>>
>> If it were possible to do the packing in JavaScript, then plausibly
>> UNSIGNED_SHORT should be allowed as an upload format, and the user
>> would be responsible for packing their own data. We definitely should
>> not add a Float16 ArrayBuffer view type. That would add a lot of
>> complex code to JavaScript VMs for a very narrow use case.
>>
>> I think it would be possible to re-ratify a new version of the
>> extension, rather than creating a new one. At least, I'd argue for
>> simply revising the extension, and would be willing to raise it with
>> the Khronos board of promoters. However, I am not sure that focusing
>> on this issue is the best investment of the working group's time.
>> There are a lot of other outstanding issues that are more pressing in
>> my opinion -- advancing the WebGL 2.0 spec and implementations in
>> particular.
>>
>> -Ken
>>
>>
>> On Wed, Feb 12, 2014 at 4:04 PM, Jeff Gilbert <jgilbert@mozilla.com> wrote:
>> >
>> > Surely it should?
>> > Instead, it appears that the only way to upload data into them is through a
>> > uselessly imprecise image/canvas/video source.
>> >
>> > We have since ratified this extension. If we want to accept a change, how
>> > does that work? Do we have to make a new extension?
>> >
>> > -Jeff
>> >
>> > -----------------------------------------------------------
>> > You are currently subscribed to public_webgl@khronos.org.
>> > To unsubscribe, send an email to majordomo@khronos.org with
>> > the following command in the body of your email:
>> > unsubscribe public_webgl
>> > -----------------------------------------------------------
>> >
>>
>> -----------------------------------------------------------
>> You are currently subscribed to public_webgl@khronos.org.
>> To unsubscribe, send an email to majordomo@khronos.org with
>> the following command in the body of your email:
>> unsubscribe public_webgl
>> -----------------------------------------------------------
>>
>>

-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------