By: Vincent Diepeveen (diep.delete@this.xs4all.nl), April 20, 2011 2:17 am
Room: Moderated Discussions
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
---------------------------
>>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
Topic | Posted By | Date |
---|---|---|
New Article: Predicting GPU Performance for AMD and Nvidia | David Kanter | 2011/04/11 11:55 PM |
Graph is not red-green colorblind friendly (NT) | RatherNotSay | 2011/04/12 03:51 AM |
Fixed | David Kanter | 2011/04/12 08:46 AM |
New Article: Predicting GPU Performance for AMD and Nvidia | James | 2011/04/12 12:30 PM |
New Article: Predicting GPU Performance for AMD and Nvidia | David Kanter | 2011/04/12 02:51 PM |
Try HD6450 or HD6850 | EduardoS | 2011/04/12 03:31 PM |
Try HD6450 or HD6850 | David Kanter | 2011/04/13 10:25 AM |
Try HD6450 or HD6850 | EduardoS | 2011/04/13 03:20 PM |
of cause | Moritz | 2011/04/14 08:03 AM |
of cause | EduardoS | 2011/04/14 01:55 PM |
Barts = 5D | Moritz | 2011/04/14 09:26 PM |
Barts = 5D | Antti-Ville Tuunainen | 2011/04/15 12:38 AM |
Limiting fixed function units | Moritz | 2011/04/15 04:28 AM |
Limiting fixed function units | Vincent Diepeveen | 2011/04/20 02:38 AM |
lack of detail | Moritz | 2011/04/20 09:24 AM |
lack of detail | EduardoS | 2011/04/20 11:45 AM |
gpgpu | Vincent Diepeveen | 2011/04/16 02:10 AM |
gpgpu | EduardoS | 2011/04/17 12:31 PM |
gpgpu | Groo | 2011/04/17 12:58 PM |
gpgpu | EduardoS | 2011/04/17 01:08 PM |
gpgpu | Ian Ameline | 2011/04/18 03:55 PM |
gpgpu | Ping-Che Chen | 2011/04/19 12:59 AM |
GPU numerical compliance | Sylvain Collange | 2011/04/19 11:38 AM |
GPU numerical compliance | Vincent Diepeveen | 2011/04/20 02:17 AM |
gpgpu | Vincent Diepeveen | 2011/04/20 02:02 AM |
gpgpu and core counts | Heikki Kultala | 2011/04/20 04:41 AM |
gpgpu and core counts | Vincent Diepeveen | 2011/04/20 05:52 AM |
gpgpu and core counts | none | 2011/04/20 07:05 AM |
gpgpu and core counts | EduardoS | 2011/04/20 11:36 AM |
gpgpu and core counts | Heikki Kultala | 2011/04/20 10:16 AM |
gpgpu and core counts | EduardoS | 2011/04/20 11:34 AM |
gpgpu and core counts | Heikki Kultala | 2011/04/20 07:24 PM |
gpgpu and core counts | EduardoS | 2011/04/20 08:55 PM |
gpgpu and core counts | Heikki Kultala | 2011/04/21 06:48 AM |
gpgpu and core counts | EduardoS | 2011/04/22 01:41 PM |
AMD Compute and Texture Fetch | David Kanter | 2011/04/21 10:42 AM |
AMD Compute and Texture Fetch | Vincent Diepeveen | 2011/04/22 01:14 AM |
AMD Compute and Texture Fetch | David Kanter | 2011/04/22 10:53 AM |
AMD Compute and Texture Fetch | EduardoS | 2011/04/22 01:46 PM |
AMD Compute and Texture Fetch | David Kanter | 2011/04/22 02:02 PM |
AMD Compute and Texture Fetch | EduardoS | 2011/04/22 02:18 PM |
AMD Compute and Texture Fetch | anon | 2011/04/22 03:30 PM |
AMD Compute and Texture Fetch | David Kanter | 2011/04/22 09:17 PM |
gpgpu and core counts | Vincent Diepeveen | 2011/04/20 12:12 PM |
gpgpu and core counts | Heikki Kultala | 2011/04/21 10:23 AM |
gpgpu and core counts | Vincent Diepeveen | 2011/04/22 02:11 AM |
Keep the crazy politics out of this | David Kanter | 2011/04/22 08:39 AM |
Keep the crazy politics out of this | Vincent Diepeveen | 2011/04/22 09:12 AM |
Keep the crazy politics out of this | David Kanter | 2011/04/22 10:44 AM |
gpgpu and core counts | Jouni Osmala | 2011/04/22 11:06 AM |
gpgpu | EduardoS | 2011/04/20 11:59 AM |
gpgpu | Vincent Diepeveen | 2011/04/20 12:37 PM |
gpgpu | EduardoS | 2011/04/20 05:27 PM |
gpgpu | Vincent Diepeveen | 2011/04/21 02:06 AM |
gpgpu | EduardoS | 2011/04/22 02:00 PM |
New Article: Predicting GPU Performance for AMD and Nvidia | PiedPiper | 2011/04/12 10:05 PM |
New Article: Predicting GPU Performance for AMD and Nvidia | David Kanter | 2011/04/12 10:42 PM |
New Article: Predicting GPU Performance for AMD and Nvidia | MS | 2011/04/15 05:04 AM |
New Article: Predicting GPU Performance for AMD and Nvidia | Kevin G | 2011/04/16 02:25 AM |
New Article: Predicting GPU Performance for AMD and Nvidia | David Kanter | 2011/04/16 08:42 AM |
New Article: Predicting GPU Performance for AMD and Nvidia | Vincent Diepeveen | 2011/04/20 02:20 AM |
memory | Moritz | 2011/04/14 09:03 PM |
memory - more | Moritz | 2011/04/15 11:11 PM |
New Article: Predicting GPU Performance for AMD and Nvidia | Kevin G | 2011/04/14 11:30 AM |