Archives Discussions

[CaptainN]

OCL spec talks only about int

OCL spec says:

"

The OpenCL C programming language implements the following functions that provide atomic
operations on 32-bit signed, unsigned integers and single precision floating-point (50) to locations
in __global or __local memory.

(50) Only the atomic_xchg operation is supported for single precision floating-point data type.

"

Whether anybody known any way how to do floating point atomic operations?

Best regards.

[d_a_a_]

According to Lee Howes:

Float atomics are not a CL problem, they're a hardware problem. Integer ALUs take up barely any space, you can throw those around and do atomics on data in cache easily. Floating point has higher latency, it sits in a pipeline for longer. It's much much harder to synchronise. It doesn't really help for normals anyway, does it? Or maybe it is safe to do component by component on normals as long as you normalise later.

In other words "I've never understood why so, is that really hard to have them on float???" yes. It is. To do inefficient ones is sortof ok at the cost of a lot of lock data in cache, they would have to be a lot less efficient than integer ones are currently. There are also all sorts of questions about IEEE compliance of the atomic operations.

You can come close, though. You can do atomic exchanges on the data. You can treat floats as ints in many cases if you want to do atomic min, max, cmpxchg and of course the bitwise ones. You have to be slightly careful of course because min/max etc wouldn't handle denorms correctly.

http://forums.amd.com/forum/messageview.cfm?catid=390&threadid=139081&highlight_key=y&keyword1=atomic

[LeeHowes]

Someone has suggested that I add an additional comment to what I said before.

There is another issue with float atomics, which is not a technical one but can easily lead to confusion for the programmer (and this is also true of using cmpxchg to emulate float atomics) which is that the answer you get is no longer deterministic because floating point arithmetic is order dependent. Of course what you end up with is arithmetic error, not completely missed computations as you might trying to do it without atomics at all, but that error can lead to significant differences in the final answer if you're not careful about what you're doing.

(2^25) + 1.0 is one obvious simple example of a lost computation. The answer to that would be 2^25 (I think, unless I miscalculate by a bit. Someone tried this on me in an interview once).

[CaptainN]

Thank you, Lee Howes!