Sylvain Collange (full.name@gmail.com) on 4/19/11 wrote:
---------------------------
>>Ian Ameline (ian.ameline@(NoSpam).gmail.com) on 4/18/11 wrote:
>>---------------------------
>>>*Fully* compliant? As in <= 1/2 ULP precision guarantees for add, subtract, divide, multiply *and* sqrt?
>
>Yes. Unlike x86-SSE for instance, which is not compliant with the current IEEE-754
>standard. Not until we get the FMA operator...
>
>>>Denormal support?
>
>Implemented in hardware at full speed. Unlike most CPUs, which trap on subnormals
>and handle them in microcode at a much lower speed.
>
>>>+-0 and +- infinity correctly generated and handled?
>
>These ones were already supported long before GPGPU APIs came out. At least since
>GeForce 6 / Radeon X1x00, and likely earlier.
>
>Ping-Che Chen (pcchen@kimicat.com) on 4/19/11 wrote:
>---------------------------
>>Right now, OpenCL 1.1 requires basically the following:
>>
>>1. round to nearest even, other rounding modes are optional. Dynamic rounding mode selection is not supported.
>>2. INF and (non signaling) NaN must be supported.
>>3. Denormalized number is optional.
>>4. No exception handling is supported right now.
>>5. +, -, * must be infinitely precise. Division and sqrt are not required to be infinitely precise.
>
>For double precision, it also requires FMA, subnormals, all 4 mandatory IEEE rounding
>modes, and correctly rounded division and sqrt.
>
>Basically, current-generation GPUs are already far ahead of x86 and most other
>CPU architectures in terms of numerical compliance.
>Power6/7 and Itanium are still arguably one notch ahead of GPUs, but that is about it.

gpu's are so much faster in 32 bits code than anything else; the focus is too much upon floating point in HPC, if you ask me. Every transform you can do more accurately in integers than in floating point; in floating point you always have the problem of erros getting backtracked, no such issues with integer transforms.

Vincent