Skip to content

nir: Add unified atomics

Currently, we have an atomic intrinsic for each combination of memory type
(global, shared, image, etc) and atomic operation (add, sub, etc). So for m
types of memory supported by the driver and n atomic opcodes, the driver has to
handle O(mn) intrinsics. This makes a total mess in every single backend I've
looked at, without fail.

It would be a lot nicer to unify the intrinsics. There are two obvious ways:

1. Make the memory type a constant index, keep different intrinsics for
   different operations. The problem with this is that different memory types
   imply different intrinsic signatures (number of sources, etc). Also, in any
   single backend, there are a lot more operations than there are memory types.

2. Make the opcode a constant index, keep different intrinsics for different
   operations. This works well, with one exception: compswap and fcompswap
   take an extra argument that other atomics don't, so there's an extra axis of
   variation for the intrinsic signatures.

So, the solution is to have 2 intrinsics for each memory type -- for atomics
taking 1 argument and atomics taking 2 respectively. Both of these intrinsics
take an nir_atomic_op enum to describe its operation. We don't use a nir_op for
this purpose, as there are some atomics (cmpxchg, inc_wrap, etc) that don't
cleanly map to any ALU op and it would be weird to force it.

The plan is to transition to these new opcodes gradually. This series adds a
lowering pass producing these opcodes from the existing opcodes, so that
backends can opt-in to the new forms one-by-one. Then we can convert backends
separately without any cross-tree flag day. Once everything is converted, we can
convert the producers and core NIR as a flag day, but we have far fewer
producers than backends so this should be fine. Finally we can drop the old
stuff.
Edited by Alyssa Rosenzweig

Merge request reports