From: Erik S. <esc...@pe...> - 2011-12-15 16:24:51
|
OpenCL supports only two operations for halfs: vload_half, converting it to a float, and vstore_half, converting from a float. Nothing else exists explicitly, not even vectors of halfs. Essentially the only thing one can do with the half type is to pass a half* to these load/store routines. There are routines such as float sin_half(float) that are only required to have the precision offered by datatype half (allowing optimisations), but the API is via float. There is text in the standard presumable allowing this to be optimised to use operations that act directly on half values, but this is not required. I added code to detect whether clang supports half (called __fp16 in C), and if so, these vload_half/vload_store routines are available. sin_half and friends are always available, forwarding to their float counterparts by default -- I assume that target-specific optimisations can do better. -erik 2011/12/15 Pekka Jääskeläinen <pek...@tu...> > 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 > > > > ------------------------------------------------------------------------------ > 10 Tips for Better Server Consolidation > Server virtualization is being driven by many needs. > But none more important than the need to reduce IT complexity > while improving strategic productivity. Learn More! > http://www.accelacomm.com/jaw/sdnl/114/51507609/ > _______________________________________________ > Pocl-devel mailing list > Poc...@li... > https://lists.sourceforge.net/lists/listinfo/pocl-devel > -- Erik Schnetter <esc...@pe...> http://www.cct.lsu.edu/~eschnett/ AIM: eschnett247, Skype: eschnett, Google Talk: sch...@gm... |