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

RE: [Public WebGL] Feature proposal for TypedArrays

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?


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,



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; see http://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,



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