mirror of
https://gitlab.freedesktop.org/mesa/mesa.git
synced 2026-05-08 06:58:05 +02:00
read-only mirror of https://gitlab.freedesktop.org/mesa/mesa
a8fafc0f32
Our backend does a somewhat unusual sequence:
1. Set up the interference graph
2. Try to register allocate
3. Fail and realize we have to spill
4. Recreate(!) the interference graph with different node counts,
because unfortunately spills and fills may need temporary registers
set aside for that purpose, which can no longer be used generally.
5. Ask for the best spill node because we know we must spill
On step 4, ra_realloc_interference_graph() reallocs the in_stack
bitset for the new nodes. However, it leaves the new bitset words
uninitialized, because it's supposed to be set up by ra_select().
On step 5, however, the Intel backend calls ra_get_best_spill_node()
_without_ first calling ra_select() (or ra_allocate()). So at that
point, the in_stack bitset is not properly initialized, and we'll
end up reading uninitialized garbage in ra_get_best_spill_node(),
and non-deterministically end up skipping candidates for spilling.
While debugging this, I observed ra_get_best_spill_node() seeing
non-zero in_stack bits set while g->tmp.stack_count was 0. So no
nodes could possibly be in the stack.
We could simply initialize the memory, but there's a deeper problem:
in Chaitin-Briggs allocators, the list of spill candidates is built in
the "Select" step. In our implementation, we technically don't make a
list of candidates, but rather flag registers that *aren't* candidates.
By never running ra_allocate() on our new graph, we never produce that
info. So when we ask for a spill node, we consider *all* registers as
spill candidates, which is far from ideal.
To fix this, we simply call ra_allocate() to rebuild that information
on the new graph. It's worth noting that it may not be quite the same
as the information we had for our old graph, too, as we reserved some
registers, increasing interference.
This escaped our notice for a long time because our allocation loop
tries to spill a single register, tries to allocate, and repeats if
it fails. Because retrying calls ra_select(), which initializes the
spill candidate info, this non-determinism only happened for the first
register selected. However, recently the backend gained support for
spilling multiple registers in each loop step, which highlighted this
problem, as different per-step-spill-sizes produced different results
due to this non-determinism.
Cc: mesa-stable
Fixes:
|
||
|---|---|---|
| .ci-farms | ||
| .ci-farms-disabled | ||
| .github/workflows | ||
| .gitlab | ||
| .gitlab-ci | ||
| android | ||
| bin | ||
| build-support | ||
| docs | ||
| include | ||
| src | ||
| subprojects | ||
| .clang-format | ||
| .clang-format-ignore | ||
| .clang-format-include | ||
| .dir-locals.el | ||
| .editorconfig | ||
| .git-blame-ignore-revs | ||
| .gitattributes | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| .graphqlrc.yml | ||
| .mailmap | ||
| .mr-label-maker.yml | ||
| CODEOWNERS | ||
| meson.build | ||
| meson_options.txt | ||
| README.rst | ||
| VERSION | ||
`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.