Re: [Intel-gfx] [PATCH 22/27] drm/i915: Eliminate lots of iterations over the execobjects array

[Joonas Lahtinen]

On ke, 2017-04-19 at 10:41 +0100, Chris Wilson wrote:
> The major scaling bottleneck in execbuffer is the processing of the
> execobjects. Creating an auxiliary list is inefficient when compared to
> using the execobject array we already have allocated.
> 
> Reservation is then split into phases. As we lookup up the VMA, we
> try and bind it back into active location. Only if that fails, do we add
> it to the unbound list for phase 2. In phase 2, we try and add all those
> objects that could not fit into their previous location, with fallback
> to retrying all objects and evicting the VM in case of severe
> fragmentation. (This is the same as before, except that phase 1 is now
> done inline with looking up the VMA to avoid an iteration over the
> execobject array. In the ideal case, we eliminate the separate reservation
> phase). During the reservation phase, we only evict from the VM between
> passes (rather than currently as we try to fit every new VMA). In
> testing with Unreal Engine's Atlantis demo which stresses the eviction
> logic on gen7 class hardware, this speed up the framerate by a factor of
> 2.
> 
> The second loop amalgamation is between move_to_gpu and move_to_active.
> As we always submit the request, even if incomplete, we can use the
> current request to track active VMA as we perform the flushes and
> synchronisation required.
> 
> The next big advancement is to avoid copying back to the user any
> execobjects and relocations that are not changed.
> 
> v2: Add a Theory of Operation spiel.
> v3: Fall back to slow relocations in preparation for flushing userptrs.
> v4: Document struct members, factor out eb_validate_vma(), add a few
> more comments to explain some magic and hide other magic behind macros.
> 
> Signed-off-by: Chris Wilson 

Changelog checks out. Assuming you peeked at the generated html docs:

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 22/27] drm/i915: Eliminate lots of iterations over the execobjects array

[Chris Wilson]

The major scaling bottleneck in execbuffer is the processing of the
execobjects. Creating an auxiliary list is inefficient when compared to
using the execobject array we already have allocated.

Reservation is then split into phases. As we lookup up the VMA, we
try and bind it back into active location. Only if that fails, do we add
it to the unbound list for phase 2. In phase 2, we try and add all those
objects that could not fit into their previous location, with fallback
to retrying all objects and evicting the VM in case of severe
fragmentation. (This is the same as before, except that phase 1 is now
done inline with looking up the VMA to avoid an iteration over the
execobject array. In the ideal case, we eliminate the separate reservation
phase). During the reservation phase, we only evict from the VM between
passes (rather than currently as we try to fit every new VMA). In
testing with Unreal Engine's Atlantis demo which stresses the eviction
logic on gen7 class hardware, this speed up the framerate by a factor of
2.

The second loop amalgamation is between move_to_gpu and move_to_active.
As we always submit the request, even if incomplete, we can use the
current request to track active VMA as we perform the flushes and
synchronisation required.

The next big advancement is to avoid copying back to the user any
execobjects and relocations that are not changed.

v2: Add a Theory of Operation spiel.
v3: Fall back to slow relocations in preparation for flushing userptrs.
v4: Document struct members, factor out eb_validate_vma(), add a few
more comments to explain some magic and hide other magic behind macros.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h |2 +-
 drivers/gpu/drm/i915/i915_gem_evict.c   |   92 +-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c  | 1953 +--
 drivers/gpu/drm/i915/i915_vma.c |2 +-
 drivers/gpu/drm/i915/i915_vma.h |1 +
 drivers/gpu/drm/i915/selftests/i915_gem_evict.c |4 +-
 drivers/gpu/drm/i915/selftests/i915_vma.c   |   16 +-
 7 files changed, 1187 insertions(+), 883 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7b6926861e04..b0c4b9cb75c2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3558,7 +3558,7 @@ int __must_check i915_gem_evict_something(struct 
i915_address_space *vm,
 int __must_check i915_gem_evict_for_node(struct i915_address_space *vm,
 struct drm_mm_node *node,
 unsigned int flags);
-int i915_gem_evict_vm(struct i915_address_space *vm, bool do_idle);
+int i915_gem_evict_vm(struct i915_address_space *vm);
 
 /* belongs in i915_gem_gtt.h */
 static inline void i915_gem_chipset_flush(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c 
b/drivers/gpu/drm/i915/i915_gem_evict.c
index 204a2d9288ae..a193f1b36c67 100644
--- a/drivers/gpu/drm/i915/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/i915_gem_evict.c
@@ -50,6 +50,29 @@ static bool ggtt_is_idle(struct drm_i915_private *dev_priv)
return true;
 }
 
+static int ggtt_flush(struct drm_i915_private *i915)
+{
+   int err;
+
+   /* Not everything in the GGTT is tracked via vma (otherwise we
+* could evict as required with minimal stalling) so we are forced
+* to idle the GPU and explicitly retire outstanding requests in
+* the hopes that we can then remove contexts and the like only
+* bound by their active reference.
+*/
+   err = i915_gem_switch_to_kernel_context(i915);
+   if (err)
+   return err;
+
+   err = i915_gem_wait_for_idle(i915,
+I915_WAIT_INTERRUPTIBLE |
+I915_WAIT_LOCKED);
+   if (err)
+   return err;
+
+   return 0;
+}
+
 static bool
 mark_free(struct drm_mm_scan *scan,
  struct i915_vma *vma,
@@ -175,19 +198,7 @@ i915_gem_evict_something(struct i915_address_space *vm,
return intel_has_pending_fb_unpin(dev_priv) ? -EAGAIN : -ENOSPC;
}
 
-   /* Not everything in the GGTT is tracked via vma (otherwise we
-* could evict as required with minimal stalling) so we are forced
-* to idle the GPU and explicitly retire outstanding requests in
-* the hopes that we can then remove contexts and the like only
-* bound by their active reference.
-*/
-   ret = i915_gem_switch_to_kernel_context(dev_priv);
-   if (ret)
-   return ret;
-
-   ret = i915_gem_wait_for_idle(dev_priv,
-I915_WAIT_INTERRUPTIBLE |
-I915_WAIT_LOCKED);
+   ret = ggtt_flush(dev_priv);
if (ret)
return ret;
 
@@ -337,10 +348,8 @@ int