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