From: Pekka J. <pek...@tu...> - 2011-12-15 08:06:13
|
On 12/15/2011 01:09 AM, Erik Schnetter wrote: > Erik Schnetter has proposed merging lp:~schnetter/pocl/main into lp:pocl. > > Requested reviews: pocl maintaners (pocl) > > For more details, see: > https://code.launchpad.net/~schnetter/pocl/main/+merge/85761 > > I added support for the half datatype, protected by #ifdef cl_khr_fp16, > analogous to cl_khr_fp64. I don't know which targets support this datatype > (presumably all, since llvm supports them?), so I enabled this for all > targets -- this will break things if this is wrong. Just curious... How does LLVM/Clang support the half by default nowadays? I've heard that for NVIDIA GPUs, for example, the half is supported only as a storage format. That is, you have the float in 16bit format in memory but whenever you compute something with halfs, they are converted to single precision floats to avoid the need for separate floating point units for halfs. Just curious to hear what happens when you use half floats in LLVM/Clang now -- do they convert them to single precision fp whenever computation occurs? The last time I checked, 'half' was not a datatype in the LLVM IR thus they could not be selected (to be implemented with the target ISA) nicely. It seems there are only two intrinsics for halfs available: http://llvm.org/docs/LangRef.html#int_fp16 Does Clang generate those automatically for halfs in OpenCL C now? For example if you perform a basic operation halfA + halfB, what happens? I'm interested in a proper half support as for embedded/mobile it is more beneficial than just for saving the memory bandwidth as you can save in the area of the FPU, improve the speed, lower the energy consumption, etc. if you can do with half floats for your computations. But I think they do not accept it as a proper datatype in LLVM before there is a real (read: off-the-shelf) target in LLVM that supports it natively. -- --Pekka |