3131c2fc7a
Our hardware requires that we write to URB using full vec4s at aligned addresses. It gives us an ability to mask-off dwords within vec4 we don't want to write, but we have to know their positions at compile time. Let's assume that: - V represents one dword we want to write - ? is an unitinitialized value - "|" is a vec4 boundary. When we want to write 2-dword value at offset 0 we generate 1 write message: | V1 V2 ? ? | with mask: | 1 1 0 0 | When we want to write 4-dword value at offset 2 we generate 2 write messages: | ? ? V1 V2 | V3 V4 ? ? | with mask: | 0 0 1 1 | 1 1 0 0 | However if we don't know the offset within vec4 at *compile time* we currently generate 4 write messages: | V1 V1 V1 V1 | | 0 0 1 0 | | V2 V2 V2 V2 | | 0 0 0 1 | | V3 V3 V3 V3 | | 1 0 0 0 | | V4 V4 V4 V4 | | 0 1 0 0 | where masks are determined at *run time*. This is quite wasteful and slow. However, if we could determine the offset modulo 4 statically at compile time, we could generate only 1 or 2 write messages (1 if modulo is 0) instead of 4. This is what this patch does: it analyzes the addressing expression for modulo 4 value and if it can determine it at compile time, we generate 1 or 2 writes, and if it can't we fallback to the old 4 writes method. In mesh shader, the value of offset modulo 4 should be known for all outputs, with an exception of primitive indices. The modulo value should be known because of MUE layout restrictions, which require that user per-primitive and per-vertex data start at address aligned to 8 dwords and we should statically always know the offset from this base. There can be some cases where the offset from the base is more dynamic (e.g. indirect array access inside a per-vertex value), so we always do the analysis. Primitive indices are an exception, because they form vec3s (for triangles), which means that the offset will not be easy to analyse. When U888X index format lands, primitive indices will use only one dword per triangle, which means that we'll always write them using one message. Task shaders don't have any predetermined structure of output memory, so always do the analysis. Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20050>
`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.