Usefulness of `supports_atomics` in its current form

[christiangnrd]

At the moment, supports_atomics returns a boolean, but different backends have different levels of support. For example, Metal essentially only supports 32-bt integers and floats, with 64-bit integer atomics being limited to min and max.

Would it be useful/worth it to add granularity to the function?

Came up when fixing the histogram example for oneAPI and Metal which don't support 64-bit atomics.

[vchuravy]

👍 these functions are post-hoc additions to attempt to allow these queries without breaking compatibility.

So we could add a more fine-grained interface that uses types as well.

[christiangnrd]

What should the API look like? Essentially extending the supports_atomics signature to supports_atomics(::Backend, ::DataType)?

What about partial support? For example, Metal has some 64-bit atomic support, but only for ulong and with min and max modify operations. Should the operation also be part of the support check? Also, Metal only supports weak guarantees. From my (noob to atomics) understanding, that means the operations can fail sometimes? Should that factor into it? I believe @anicusan had to use a different algorithm in the AK.jl accumulate! because of the lack of strong memory guarantees.

This is kind of just me dumping my thoughts while I try to better understand atomics and how they relate to GPU programming/KA.