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

Re: [Public WebGL] Feature proposal for TypedArrays



On Wed, May 12, 2010 at 12:50 PM, Gregg Tavares <gman@google.com> wrote:
>
>
> On Wed, May 12, 2010 at 10:34 AM, Chris Marrin <cmarrin@apple.com> wrote:
>>
>> On May 11, 2010, at 6:37 AM, tomi.aarnio@nokia.com wrote:
>>
>> > Hi all,
>> >
>> > Thanks for the feedback! To clarify, my proposal is aimed at
>> > TypedArrays, not the WebGL core spec. As I see it, having the necessary
>> > datatypes in place right from the start will reduce fragmentation of the
>> > TypedArray API in the future.
>> >
>> > Granted -- fp16 is not yet a first-class citizen on most C compilers, so
>> > it will have to be emulated using fp32 or plain integers. Luckily there are
>> > several open-source libraries available for that, see for instance
>> > www.openexr.com. Besides, we don’t need a full-blown math library here, just
>> > the conversion functions to/from fp32, which are almost trivial to write.
>> >
>> > I don’t quite understand the alleged problems with doing math in fp16.
>> > From the JavaScript perspective, fp16 is no different from fp32, because
>> > neither one is supported natively. If you do myArray[i]*myArray[j], the
>> > multiplication happens in double-precision regardless of the source operand
>> > precision, right?
>>
>> But on all major hardware, converting to and from fp32 and fp64 is a
>> simple cast. No such operation exists for fp16. As I mentioned before, we
>> can support passing fp16 to WebGL by using the unsigned short array.
>>
>> I also agree with Ken that we should eventually support this, just not in
>> 1.0.
>
> If you've already got code converting from JS Number to/from float and JS
> Number to from byte and JS Number to/from short etc then adding 1 more JS
> Number to/from half seems like an hour or two of work a the most.
>
> Why not put it in 1.0?  Because once it's in TypedArray, separate from
> WebGL, it's possibly going to take a lot more work to get it added since
> it's a different standards group that will be responsible for it.

Bringing an implementation of a half-float TypedArray to performance
parity with the other array types is much more than an hour or two of
work.

I anticipate that the same people driving the WebGL spec will end up
driving the TypedArray spec, so I think that future changes to that
spec will not take significantly more time than changes to WebGL
(which will be required anyway to make use of the new half-float
TypedArray).

-Ken

>> > I realize I should’ve been more careful in using the term “bandwidth”,
>> > because I meant memory bandwidth, not network bandwidth. Memory bandwidth
>> > usage has a big impact on performance in any modern GPU, and similarly on
>> > power consumption in any embedded GPU. Memory bandwidth savings are the main
>> > reason why half-precision floats have been universally adopted in both
>> > desktop and mobile GPUs, although the space savings are a nice bonus.
>> >
>> > Best regards,
>> >   Tomi
>> >
>> > From: ext Gregg Tavares [mailto:gman@google.com]
>> > Sent: Monday, May 10, 2010 19:07
>> > To: Aarnio Tomi (Nokia-NRC/Tampere)
>> > Cc: public_webgl@khronos.org
>> > Subject: Re: [Public WebGL] Feature proposal for TypedArrays
>> >
>> >
>> >
>> > On Mon, May 10, 2010 at 8:44 AM, <tomi.aarnio@nokia.com> wrote:
>> > Hi all,
>> >
>> > I’d like to propose a new feature for TypedArrays, namely support for
>> > the ‘half’ datatype, also known as fp16.
>> >
>> > I think it's probably a good idea to add 'half' to the TypedArrays spec
>> > but just to make it clear there are a bunch of issues tied up here that
>> > should be separated
>> >
>> > 1) half support in TypedArrays
>> > 2) half support in WebGL
>> > 3) space savings benefits
>> >   3a) transmission time
>> >   3b) memory
>> >
>> > My opinions below
>> >
>> > 1) yes
>> > 2) yes in extensions
>> > 3a) You can compress data lots of ways. For example you could transmit
>> > fp16 but convert (in JavaScript) to fp32.
>> > 3b) Is this really important? If the platform has so little memory that
>> > it needs fp16 to run an app it's unlikely to run most apps.
>> >
>> >
>> >
>> > Although the half datatype is not strictly required for core WebGL,
>> > there are several widely deployed OES extensions that do require it;
>> > seehttp://www.khronos.org/registry/gles/. It’s also universally supported on
>> > desktop GPUs (required by OpenGL 3.0 and later), and part of the IEEE
>> > 754-2008 standard. And of course, it’s immensely useful in saving memory
>> > space and bandwidth in cases where fp32 precision and range would be
>> > overkill.
>> >
>> > I believe the extra effort to support fp16 in TypedArrays would be
>> > minimal, considering that FP32 and FP64 are already supported.
>> >
>> > Best regards,
>> >   Tomi
>> >
>> > PS. If this is not an appropriate forum for discussing TypedArrays, then
>> > please do advise where to find one. There were no pointers in the TypedArray
>> > spec as of May 6.
>> > __________________________
>> > Tomi Aarnio
>> > Nokia Research
>> > tomi.aarnio@nokia.com
>> > http://research.nokia.com/people/tomi_aarnio
>> >
>> >
>>
>> -----
>> ~Chris
>> cmarrin@apple.com
>>
>>
>>
>>
>>
>> -----------------------------------------------------------
>> You are currently subscribe to public_webgl@khronos.org.
>> To unsubscribe, send an email to majordomo@khronos.org with
>> the following command in the body of your email:
>>
>
>

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