c429d5025e
The idea here was that pixel shader framebuffer writes used the g0 and g1 thread payload register values to construct the message header. However, most messages are headerless and don't use either. There's a 2012-era comment that the simulator at one point had a bug where certain headerless messages would incorrectly take the values from the g0/g1 register contents rather than using sideband. But, that was likely fixed eons ago. So we really don't need to do this. Furthermore, there are many more shader stages these days: - VS: r1 contains output URB handles - TCS: r1 contains ICP handles - TES: r1 contains gl_TessCoord.x (r4 contains output URB handles) - GS: r1 contains output URB handles - CS: r1 contains LocalID.X on DG2+ but nothing on older hardware - Task/Mesh: r1 contains LocalID.X - BS: r1 contains bindless stack handles Vertex and geometry aren't likely to benefit here because r1 is needed for their output messages, which are also what terminate the shader. TES will definitely benefit because we were making a value pointlessly live for the whole program. Same for TCS, to a lesser extent. Compute prior to DG2 was the worst, as g1 literally has no meaningful content, so there is no point to keeping it live. fossil-db on Alchemist shows substantial spill/fill improvements: Totals: Instrs: 148782351 -> 148741996 (-0.03%); split: -0.03%, +0.01% Cycles: 12602907531 -> 12605795191 (+0.02%); split: -0.70%, +0.72% Subgroup size: 7518608 -> 7518632 (+0.00%) Send messages: 7341727 -> 7341762 (+0.00%) Spill count: 54633 -> 52575 (-3.77%) Fill count: 104694 -> 100680 (-3.83%) Scratch Memory Size: 3375104 -> 3287040 (-2.61%) Totals from 301172 (48.21% of 624670) affected shaders: Instrs: 95531927 -> 95491572 (-0.04%); split: -0.05%, +0.01% Cycles: 9643531593 -> 9646419253 (+0.03%); split: -0.91%, +0.94% Subgroup size: 4492512 -> 4492536 (+0.00%) Send messages: 4399737 -> 4399772 (+0.00%) Spill count: 20034 -> 17976 (-10.27%) Fill count: 41530 -> 37516 (-9.67%) Scratch Memory Size: 1522688 -> 1434624 (-5.78%) Assassin's Creed Odyssey in particular has 20% fewer fills. Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30146>
`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://docs.mesa3d.org/install.html>`_), but the recommended way is to use Meson (`docs/meson.rst <https://docs.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://docs.mesa3d.org/bugs.html>`_). Contributing ------------ Contributions are welcome, and step-by-step instructions can be found in our documentation (`docs/submittingpatches.rst <https://docs.mesa3d.org/submittingpatches.html>`_). Note that Mesa uses gitlab for patches submission, review and discussions.