Mesa (main): iris: Drop fallback GEM_MMAP_GTT if GEM_MMAP with I915_MMAP_WC fails

[GitLab Mirror]

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

Author: Kenneth Graunke <kenneth at whitecape.org>
Date:   Thu May 20 01:41:37 2021 -0700

iris: Drop fallback GEM_MMAP_GTT if GEM_MMAP with I915_MMAP_WC fails

XXX: This is actually wrong.  The dmabuf imported case can be mapped via
GEM_MMAP_GTT if the iommu is working, according to Joonas, but GEM_MMAP
would fall over and fail.  So we would need this fallback.
ALTERNATIVELY...we would need to flag such imported dmabufs as
unmappable, and then make iris_transfer_map/unmap always do blits
instead of direct mappings.  That seems like the saner approach

We never want to use GEM_MMAP_GTT, as it does detiling maps, and iris
always wants direct maps.  There were originally two cases that this
fallback path was attempting to handle:

1. The BO was allocated from stolen memory that we can't GEM_MMAP.

   At one point, kernel patches were being proposed to use stolen
   memory for userspace buffers, but these never landed.  The kernel
   has never given us stolen memory, so we cannot hit this case.

2. Imported objects may be from memory we can't GEM_MMAP.

   For example, a DMABUF from a discrete AMD/NVIDIA GPU in a PRIME
   setup would be backed by memory that we can't GEM_MMAP.  We could
   try and mmap these directly with GEM_MMAP_GTT, but that relies on
   the IOMMU working.  We could mmap the DMABUF fd directly (but have
   never tried to do so), but there are complex rules there.  Instead,
   we now flag those imports, however, and rely on the iris_transfer_map
   code to perform staging blits on the GPU, so we never even try to
   map them directly.  So this case won't reach us here any longer.

With both of those out of the way, there is no need for a fallback.

Acked-by: Lionel Landwerlin <lionel.g.landwerlin at intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10941>

---

 src/gallium/drivers/iris/iris_bufmgr.c | 19 +------------------
 1 file changed, 1 insertion(+), 18 deletions(-)

diff --git a/src/gallium/drivers/iris/iris_bufmgr.c b/src/gallium/drivers/iris/iris_bufmgr.c
index 605326dceaf..d8466860798 100644
--- a/src/gallium/drivers/iris/iris_bufmgr.c
+++ b/src/gallium/drivers/iris/iris_bufmgr.c
@@ -1226,30 +1226,13 @@ iris_bo_map(struct pipe_debug_callback *dbg,
 {
    assert((flags & MAP_RAW) || bo->tiling_mode == I915_TILING_NONE);
 
-   void *map;
+   void *map = NULL;
 
    if (can_map_cpu(bo, flags))
       map = iris_bo_map_cpu(dbg, bo, flags);
    else
       map = iris_bo_map_wc(dbg, bo, flags);
 
-   /* Allow the attempt to fail by falling back to the GTT where necessary.
-    *
-    * Not every buffer can be mmaped directly using the CPU (or WC), for
-    * example buffers that wrap stolen memory or are imported from other
-    * devices. For those, we have little choice but to use a GTT mmapping.
-    * However, if we use a slow GTT mmapping for reads where we expected fast
-    * access, that order of magnitude difference in throughput will be clearly
-    * expressed by angry users.
-    *
-    * We skip MAP_RAW because we want to avoid map_gtt's fence detiling.
-    */
-   if (!map && !(flags & MAP_RAW)) {
-      perf_debug(dbg, "Fallback GTT mapping for %s with access flags %x\n",
-                 bo->name, flags);
-      map = iris_bo_map_gtt(dbg, bo, flags);
-   }
-
    return map;
 }