On 11/18/2012 4:23 PM, Manu wrote:

Actually, they probably will. People using it will need to use it regardless of
how it's implemented. Hardware support it great when available, but
realistically, it's used when processing data for execution on another processor
that does support it in hardware (typically a GPU). Use of fp16 is probably not
optional; it doubles your bandwidth wherever the loss of precision is acceptable.

Doing implicit conversions on them implies doing them on the x86 CPU, which has no hardware support for the type. All operations would require software emulation.

It would just make the experience seamless, and also implement the expected casting/data-loss rules. It's the type safety/casting rules that I find most valuable, and the ability to use them in templates without specialising the half path.

I guess it would be nicer/simpler to perform actual work as floats and then re-pack it on write back, rather than emulating all the operations in half space. This wouldn't strictly retain half precision though, it would be slightly higher precision since the intermediates were full precision (which is surely preferable?).

If it is a storage-only format, then what role do implicit conversions play?

It saves pack/unpack calls whenever interacting with them in structs or streams, which helps generic code. And also encourages use of the type in structs, as it is not an 'inconvenience' as such. Where I'm from, memory/bandwidth is often far more scarce than processing time.

x86 can do half conversion fairly efficiently (about 5 opcodes, possibly one of the reasons it hasn't found it's way into SSE yet). But it's no surprise that platforms like ARM implemented the conversion operations in hardware, there's no time to waste on mobile devices.

I've also seen a few threads on this forum before about people targeting GPU backends to do GPGPU processing with D. Has that ever actually been used? Found useful in practise?