Kenneth Graunke
72a28706a4
We would like to start performing slab allocation of resources, where multiple resources can be backed by a single GEM object. Originally, I had thought to move busy tracking, cache domain tracking, and so on into resources themselves, instead of having them at the BO level. Multiple resources would point at the same BO with an offset. Unfortunately, this meant adjusting the batch BO pinning code to take resources rather than BOs. That cascades into needing iris_address for genxml packing to store resources, not BOs. Which means that places which have use raw BOs would need to start creating resources instead. Except some places, like aux BO handling, really don't make sense as pipe resources and really would rather use raw BOs. So iris_address would need to store both, which convolutes the genxml field. And, having a BO and resource means that every place in the code needs to handle that offset correctly. It sounds simple, but is a giant mess. Instead, we take a different route: adjust iris_bo itself, so that BOs are either be backed by a GEM object (as is the case today), or backed by another underlying BO. "Real" BOs have bo->gem_handle != 0. "Slab allocated" or "fake" or "wrapper" BOs have bo->gem_handle == 0. We move fields into a union based on these cases. amdgpu takes this approach. This sounds complex at first glance---in theory, every place that interacts with BOs might need to handle the wrapper BO special case. But in practice, they don't. For suballocated BOs, we can set the wrapper's address field to the underlying BO's address plus any offset, at which point it looks like any other BO. Most other properties are easily queried; the main code that needs updating is execbuf handling and bufmgr internals. For now, we simply move the fields. Any code that accesses either bo->real.* or bo->gem_handle will need updating in future patches to actually handle the slab-allocated case. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12623>
`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.