Initial Atomic<T> type implementation.
#5125
Conversation
docs/proposals/003-atomic-t.md
Outdated
| enum MemoryOrder | ||
| { | ||
| Relaxed = $(kIRMemoryOrder_Relaxed), | ||
| SeqCst = $(kIRMemoryOrder_SeqCst), |
There was a problem hiding this comment.
FWIW Vulkan doesn't actually support sequentially consistent atomics. We do support AcquireRelease which is close, but doesn't support some obscure use cases. I think it would be fine to only have Relaxed for now.
There was a problem hiding this comment.
I see. SeqCst was added because metal supports it.
There was a problem hiding this comment.
I guess we can have AcquireRelease here and map it to SeqCst on metal.
| __intrinsic_op($(kIROp_AtomicInc)) | ||
| [__ref] T increment(MemoryOrder order = MemoryOrder.Relaxed); | ||
| __intrinsic_op($(kIROp_AtomicDec)) | ||
| [__ref] T decrement(MemoryOrder order = MemoryOrder.Relaxed); |
There was a problem hiding this comment.
Would they return the original value too?
There was a problem hiding this comment.
Yes, all atomic methods returns original values.
| extension float : IArithmeticAtomicable {} | ||
| extension half : IArithmeticAtomicable {} |
There was a problem hiding this comment.
There was a problem hiding this comment.
The interface definition is fine, because IArithmeticAtomicable is IAtomicable, and compareExchange is a IAtomicable method.
However this reminds me that the currently code emit logic for floating point atomics on HLSL is wrong. We should be using the InterlockedAddF32/F16 etc instead of InterlockedAdd.
|
I am going to merge this first, and then attempt to fix the floating point intrinsics on hlsl later. |
Closes #5084.
Todo: test new Atomic type for all existing targets as well as wgsl target.