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