Mesa (main): iris: Bypass the BO cache when allocating buffers for aux map tables

[GitLab Mirror]

Module: Mesa
Branch: main
Commit: 7bb4ada8e06fa27cbcffd9619d911a1534ef5062
URL:    http://cgit.freedesktop.org/mesa/mesa/commit/?id=7bb4ada8e06fa27cbcffd9619d911a1534ef5062

Author: Kenneth Graunke <kenneth at whitecape.org>
Date:   Mon Aug 16 12:54:47 2021 -0700

iris: Bypass the BO cache when allocating buffers for aux map tables

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 at intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12420>

---

 src/gallium/drivers/iris/iris_bufmgr.c | 19 ++++++++++++++++---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/src/gallium/drivers/iris/iris_bufmgr.c b/src/gallium/drivers/iris/iris_bufmgr.c
index 9534f77a6b8..5596a5cb546 100644
--- a/src/gallium/drivers/iris/iris_bufmgr.c
+++ b/src/gallium/drivers/iris/iris_bufmgr.c
@@ -1674,9 +1674,22 @@ intel_aux_map_buffer_alloc(void *driver_ctx, uint32_t size)
 
    struct iris_bufmgr *bufmgr = (struct iris_bufmgr *)driver_ctx;
 
-   struct iris_bo *bo =
-      iris_bo_alloc(bufmgr, "aux-map", size, 64 * 1024,
-                    IRIS_MEMZONE_OTHER, 0);
+   bool local = bufmgr->vram.size > 0;
+   unsigned int page_size = getpagesize();
+   size = MAX2(ALIGN(size, page_size), page_size);
+
+   struct iris_bo *bo = alloc_fresh_bo(bufmgr, size, local);
+
+   simple_mtx_lock(&bufmgr->lock);
+   bo->address = vma_alloc(bufmgr, IRIS_MEMZONE_OTHER, bo->size, 64 * 1024);
+   assert(bo->address != 0ull);
+   simple_mtx_unlock(&bufmgr->lock);
+
+   bo->name = "aux-map";
+   p_atomic_set(&bo->refcount, 1);
+   bo->index = -1;
+   bo->kflags = EXEC_OBJECT_SUPPORTS_48B_ADDRESS | EXEC_OBJECT_PINNED;
+   bo->mmap_mode = local ? IRIS_MMAP_WC : IRIS_MMAP_WB;
 
    buf->driver_bo = bo;
    buf->gpu = bo->address;