Francisco Jerez
f0b6348ad0
This hardware bug is the result of a control flow optimization present in Gfx8-9 meant to prevent the ELSE instruction from disabling all channels and update the control flow stack only to have them re-enabled at the ENDIF instruction executed immediately after it. Instead, on Gfx8-9 an ELSE instruction that would normally have ended up with all channels disabled would pop off the last element of the stack and jump directly to JIP+1 instead of to the ENDIF at JIP, skipping over the ENDIF instruction. In simple cases this would work okay (though it's actual performance benefit is questionable), but in cases where a branch instruction within the IF block (e.g. BREAK or CONTINUE) caused all active channels to jump outside the IF conditional, the optimization would break the JIP chain of "join" instructions by skipping the ENDIF, causing the block of instructions immediately after the ENDIF to execute with all channels disabled until execution reaches the reconvergence point. This issue was observed on SKL in the dEQP-VK.reconvergence.subgroup_uniform_control_flow_elect.compute.nesting4.0.38 test in combination with some Vulkan binding model changes Lionel is working on. In such cases the execution with all channels disabled was leading to corruption of an indirect message descriptor, causing a hang. Unfortunately the hardware bug doesn't provide a recommended workaround. In order to fix the problem we point the JIP of an ELSE instruction to the instruction immediately before the ENDIF -- However that's not expected to work due to the restriction that JIP and UIP must be equal if and only if BranchCtrl is disabled -- So this patch also enables BranchCtrl, which is intended to support join instructions within the "ELSE" block, which in turn disables the optimization described above, which in turn causes us to execute the instruction immediately *before* the ENDIF with all channels disabled -- So in order to avoid further fallout from executing code with all channels disabled we need to insert a NOP before ENDIF instructions that have a matching ELSE instruction. Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20921>
`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.