Alyssa Rosenzweig
d51bc95837
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). As an example, it doesn't make sense to unify global_atomic_amd with global_atomic_2x32, as an example. The first takes 3 scalar sources, the second takes 1 vector and 1 scalar. 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. Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Reviewed-by: Jesse Natalie <jenatali@microsoft.com> Reviewed-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Rob Clark <robclark@freedesktop.org> Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22914>
`Mesa <https://mesa3d.org>`_ - The 3D Graphics Library ====================================================== Source ------ This repository lives at https://gitlab.freedesktop.org/mesa/mesa. Other repositories are likely forks, and code found there is not supported. Build & install --------------- You can find more information in our documentation (`docs/install.rst <https://mesa3d.org/install.html>`_), but the recommended way is to use Meson (`docs/meson.rst <https://mesa3d.org/meson.html>`_): .. code-block:: sh $ mkdir build $ cd build $ meson .. $ sudo ninja install Support ------- Many Mesa devs hang on IRC; if you're not sure which channel is appropriate, you should ask your question on `OFTC's #dri-devel <irc://irc.oftc.net/dri-devel>`_, someone will redirect you if necessary. Remember that not everyone is in the same timezone as you, so it might take a while before someone qualified sees your question. To figure out who you're talking to, or which nick to ping for your question, check out `Who's Who on IRC <https://dri.freedesktop.org/wiki/WhosWho/>`_. The next best option is to ask your question in an email to the mailing lists: `mesa-dev\@lists.freedesktop.org <https://lists.freedesktop.org/mailman/listinfo/mesa-dev>`_ Bug reports ----------- If you think something isn't working properly, please file a bug report (`docs/bugs.rst <https://mesa3d.org/bugs.html>`_). Contributing ------------ Contributions are welcome, and step-by-step instructions can be found in our documentation (`docs/submittingpatches.rst <https://mesa3d.org/submittingpatches.html>`_). Note that Mesa uses gitlab for patches submission, review and discussions.