[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



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.

-Jeff

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