mirror of
https://gitlab.freedesktop.org/mesa/mesa.git
synced 2026-01-07 19:30:12 +01:00
read-only mirror of https://gitlab.freedesktop.org/mesa/mesa
7bb4ada8e0
When freeing a buffer, we may return a non-idle buffer to the cache, which means we cannot unmap aux entries at that time. Instead, we defer unmapping the stale aux entry until we reuse a BO from the cache. Unfortunately, this can lead to a recursive locking issue: 1. intel_aux_map_add_mapping wants to set up a new aux entry It takes the intel_aux_map_context::mutex lock, then calls: add_mapping -> get_aux_entry -> add_sub_table -> add_buffer -> intel_aux_map_buffer_alloc -> iris_bo_alloc 2. iris_bo_alloc tries to allocate a BO from the cache, doing: alloc_bo_from_cache -> intel_aux_map_unmap_range -> intel_aux_unmap_range ...which then tries to take the intel_aux_map_context::mutex lock. But it is already locked. One solution would be to rework the aux map handling code to allocate BOs without holding its lock, but that looks to be painful. Another is to make the lock recursive, but we try and avoid that. A third option wuold be to add a BO_ALLOC flag that makes alloc_bo_from_cache skip any buffers with aux_map_address != 0 so we don't have to unmap, making the less cache effective but fixing the recursive lock. A fourth option is to simply bypass the BO cache altogether for the buffers that hold the aux map itself. Allocating new BOs for the aux tables should be relatively rare, so there's probably not a lot of benefit in using the BO cache. Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5191 Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12420> |
||
|---|---|---|
| .gitlab/issue_templates | ||
| .gitlab-ci | ||
| android | ||
| bin | ||
| build-support | ||
| docs | ||
| include | ||
| src | ||
| subprojects | ||
| .dir-locals.el | ||
| .editorconfig | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| .mailmap | ||
| .travis.yml | ||
| meson.build | ||
| meson_options.txt | ||
| README.rst | ||
| REVIEWERS | ||
| 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://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.