Re: [Intel-gfx] [PATCH 2/6] drm/i915: Retire requests along rings

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-04-25 10:30:51)
> Related, there could be potential to unify i915_request_retire_upto and 
> ring_retire_requests. Latter could pass in NULL as the upto request, 
> just the completed check would need to be different depending on the mode.

Also remember that _upto is the public variant, doing the individual
request retirement was kept private. As the ordering is paramount, the
public version needs to be retire iff first, or retire all/upto.

An attempt was made to have one interface that dtrt.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Retire requests along rings

[Tvrtko Ursulin]

On 24/04/2018 15:57, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2018-04-24 15:46:49)


On 24/04/2018 14:14, Chris Wilson wrote:

In the next patch, rings are the central timeline as requests may jump
between engines. Therefore in the future as we retire in order along the
engine timeline, we may retire out-of-order within a ring (as the ring now
occurs along multiple engines), leading to much hilarity in miscomputing
the position of ring->head.

As an added bonus, retiring along the ring reduces the penalty of having
one execlists client do cleanup for another (old legacy submission
shares a ring between all clients). The downside is that slow and
irregular (off the critical path) process of cleaning up stale requests
after userspace becomes a modicum less efficient.

In the long run, it will become apparent that the ordered
ring->request_list matches the ring->timeline, a fun challenge for the
future will be unifying the two lists to avoid duplication!

v2: We need both engine-order and ring-order processing to maintain our
knowledge of where individual rings have completed upto as well as
knowing what was last executing on any engine. And finally by decoupling
retiring the contexts on the engine and the timelines along the rings,
we do have to keep a reference to the context on each request
(previously it was guaranteed by the context being pinned).

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
@@ -322,9 +325,9 @@ static void advance_ring(struct i915_request *request)
   } else {
   tail = request->postfix;
   }
- list_del(>ring_link);
+ list_del_init(>ring_link);


Why the _init flavour? There are two list heads for being on two
separate lists, but are either path reachable after being removed from
the respective lists? (I may find the answer as I read on.)


Yes. rq are held elsewhere and may end up being individually retired
(via the retire_upto paths) multiple times. i915_request_retire() should
only be called once (otherwise asserts).

So init + list_empty() is being used to prevent retiring the same
request multiple times.


- if (engine->last_retired_context)
- engine->context_unpin(engine, engine->last_retired_context);
- engine->last_retired_context = request->ctx;
-
- spin_lock_irq(>lock);
- if (!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >fence.flags))
- dma_fence_signal_locked(>fence);
- if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, >fence.flags))
- intel_engine_cancel_signaling(request);
- if (request->waitboost) {
- GEM_BUG_ON(!atomic_read(>i915->gt_pm.rps.num_waiters));
- atomic_dec(>i915->gt_pm.rps.num_waiters);
- }
- spin_unlock_irq(>lock);
+ __retire_engine_upto(request->engine, request);
   


I did not figure out why do you need to do this. Normally retirement
driven from ring timelines would retire requests on the same engine
belonging to a different ring, as it walks over ring timelines.


Right, so retiring along a ring ends up out of order for a particular
engine.
  

Only for direct callers of i915_request_retire it may make a difference
but I don't understand is it an functional difference or just optimisation.


I was hoping the GEM_BUG_ON(!list_is_first()); explained the rationale.


Thanks, I remembered after pressing send.


This is then from where list_del_init comes from, since this function
can retire wider than the caller would expect. But then it retires on
the engine (upto) and the callers just walks the list and calls retire
only to find already unlinked elements. Could it just as well then
retire it completely?


We're still trying to only do as little work as we can get away with.


I was thinking about something else, but it was a flawed idea since two 
walks are crucial for correct ordering for both engine and ring retirement.



- /* Move the oldest request to the slab-cache (if not in use!) */
- rq = list_first_entry_or_null(>timeline->requests,
-   typeof(*rq), link);
+ /* Move our oldest request to the slab-cache (if not in use!) */
+ rq = list_first_entry_or_null(>request_list,
+   typeof(*rq), ring_link);


This is less efficient now - I wonder if you should still be looking at
the engine timeline here?


No, either way you have to walk all engine->requests upto this point, or
all ring->requests. To keep the interface manageable, retirement is in
ring order.

On the other hand, we don't retire as often if we can get away with it.
1 step forwards, 1 step backwards.


AFAIR and AFAICS the point of this was to free up the oldest request 
just to help with request recycling as new ones are added. By now 
changing it to be oldest on the ring timeline it a) my not be very old, 
or b) not even completed, while there might be much older and completed 
requests on the respective engine timeline.


Hm, or 

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Retire requests along rings

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-04-24 15:46:49)
> 
> On 24/04/2018 14:14, Chris Wilson wrote:
> > In the next patch, rings are the central timeline as requests may jump
> > between engines. Therefore in the future as we retire in order along the
> > engine timeline, we may retire out-of-order within a ring (as the ring now
> > occurs along multiple engines), leading to much hilarity in miscomputing
> > the position of ring->head.
> > 
> > As an added bonus, retiring along the ring reduces the penalty of having
> > one execlists client do cleanup for another (old legacy submission
> > shares a ring between all clients). The downside is that slow and
> > irregular (off the critical path) process of cleaning up stale requests
> > after userspace becomes a modicum less efficient.
> > 
> > In the long run, it will become apparent that the ordered
> > ring->request_list matches the ring->timeline, a fun challenge for the
> > future will be unifying the two lists to avoid duplication!
> > 
> > v2: We need both engine-order and ring-order processing to maintain our
> > knowledge of where individual rings have completed upto as well as
> > knowing what was last executing on any engine. And finally by decoupling
> > retiring the contexts on the engine and the timelines along the rings,
> > we do have to keep a reference to the context on each request
> > (previously it was guaranteed by the context being pinned).
> > 
> > Signed-off-by: Chris Wilson 
> > Cc: Tvrtko Ursulin 
> > ---
> > @@ -322,9 +325,9 @@ static void advance_ring(struct i915_request *request)
> >   } else {
> >   tail = request->postfix;
> >   }
> > - list_del(>ring_link);
> > + list_del_init(>ring_link);
> 
> Why the _init flavour? There are two list heads for being on two 
> separate lists, but are either path reachable after being removed from 
> the respective lists? (I may find the answer as I read on.)

Yes. rq are held elsewhere and may end up being individually retired
(via the retire_upto paths) multiple times. i915_request_retire() should
only be called once (otherwise asserts).

So init + list_empty() is being used to prevent retiring the same
request multiple times.

> > - if (engine->last_retired_context)
> > - engine->context_unpin(engine, engine->last_retired_context);
> > - engine->last_retired_context = request->ctx;
> > -
> > - spin_lock_irq(>lock);
> > - if (!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >fence.flags))
> > - dma_fence_signal_locked(>fence);
> > - if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, >fence.flags))
> > - intel_engine_cancel_signaling(request);
> > - if (request->waitboost) {
> > - 
> > GEM_BUG_ON(!atomic_read(>i915->gt_pm.rps.num_waiters));
> > - atomic_dec(>i915->gt_pm.rps.num_waiters);
> > - }
> > - spin_unlock_irq(>lock);
> > + __retire_engine_upto(request->engine, request);
> >   
> 
> I did not figure out why do you need to do this. Normally retirement 
> driven from ring timelines would retire requests on the same engine 
> belonging to a different ring, as it walks over ring timelines.

Right, so retiring along a ring ends up out of order for a particular
engine.
 
> Only for direct callers of i915_request_retire it may make a difference 
> but I don't understand is it an functional difference or just optimisation.

I was hoping the GEM_BUG_ON(!list_is_first()); explained the rationale.

> This is then from where list_del_init comes from, since this function 
> can retire wider than the caller would expect. But then it retires on 
> the engine (upto) and the callers just walks the list and calls retire 
> only to find already unlinked elements. Could it just as well then 
> retire it completely?

We're still trying to only do as little work as we can get away with.

> > - /* Move the oldest request to the slab-cache (if not in use!) */
> > - rq = list_first_entry_or_null(>timeline->requests,
> > -   typeof(*rq), link);
> > + /* Move our oldest request to the slab-cache (if not in use!) */
> > + rq = list_first_entry_or_null(>request_list,
> > +   typeof(*rq), ring_link);
> 
> This is less efficient now - I wonder if you should still be looking at 
> the engine timeline here?

No, either way you have to walk all engine->requests upto this point, or
all ring->requests. To keep the interface manageable, retirement is in
ring order.

On the other hand, we don't retire as often if we can get away with it.
1 step forwards, 1 step backwards.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Retire requests along rings

[Tvrtko Ursulin]

On 24/04/2018 15:46, Tvrtko Ursulin wrote:


On 24/04/2018 14:14, Chris Wilson wrote:

In the next patch, rings are the central timeline as requests may jump
between engines. Therefore in the future as we retire in order along the
engine timeline, we may retire out-of-order within a ring (as the ring 
now

occurs along multiple engines), leading to much hilarity in miscomputing
the position of ring->head.

As an added bonus, retiring along the ring reduces the penalty of having
one execlists client do cleanup for another (old legacy submission
shares a ring between all clients). The downside is that slow and
irregular (off the critical path) process of cleaning up stale requests
after userspace becomes a modicum less efficient.

In the long run, it will become apparent that the ordered
ring->request_list matches the ring->timeline, a fun challenge for the
future will be unifying the two lists to avoid duplication!

v2: We need both engine-order and ring-order processing to maintain our
knowledge of where individual rings have completed upto as well as
knowing what was last executing on any engine. And finally by decoupling
retiring the contexts on the engine and the timelines along the rings,
we do have to keep a reference to the context on each request
(previously it was guaranteed by the context being pinned).

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/i915_drv.h   |   3 +-
  drivers/gpu/drm/i915/i915_gem.c   |   1 +
  drivers/gpu/drm/i915/i915_request.c   | 140 +++---
  drivers/gpu/drm/i915/i915_utils.h |   6 +
  drivers/gpu/drm/i915/intel_ringbuffer.c   |   6 +-
  drivers/gpu/drm/i915/intel_ringbuffer.h   |   1 +
  drivers/gpu/drm/i915/selftests/mock_engine.c  |  27 +++-
  .../gpu/drm/i915/selftests/mock_gem_device.c  |   2 +
  8 files changed, 120 insertions(+), 66 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h 
b/drivers/gpu/drm/i915/i915_drv.h

index 8fd9fb6efba5..1837c01d44d0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2058,8 +2058,9 @@ struct drm_i915_private {
  void (*resume)(struct drm_i915_private *);
  void (*cleanup_engine)(struct intel_engine_cs *engine);
-    struct list_head timelines;
  struct i915_gem_timeline global_timeline;
+    struct list_head timelines;
+    struct list_head rings;
  u32 active_requests;
  u32 request_serial;
diff --git a/drivers/gpu/drm/i915/i915_gem.c 
b/drivers/gpu/drm/i915/i915_gem.c

index 795ca83aed7a..906e2395c245 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5600,6 +5600,7 @@ int i915_gem_init_early(struct drm_i915_private 
*dev_priv)

  goto err_dependencies;
  mutex_lock(_priv->drm.struct_mutex);
+    INIT_LIST_HEAD(_priv->gt.rings);
  INIT_LIST_HEAD(_priv->gt.timelines);
  err = i915_gem_timeline_init__global(dev_priv);
  mutex_unlock(_priv->drm.struct_mutex);
diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c

index b1993d4a1a53..aa84b5447fd5 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -286,6 +286,7 @@ static int reserve_gt(struct drm_i915_private *i915)
  static void unreserve_gt(struct drm_i915_private *i915)
  {
+    GEM_BUG_ON(!i915->gt.active_requests);
  if (!--i915->gt.active_requests)
  i915_gem_park(i915);
  }
@@ -298,6 +299,7 @@ void i915_gem_retire_noop(struct i915_gem_active 
*active,

  static void advance_ring(struct i915_request *request)
  {
+    struct intel_ring *ring = request->ring;
  unsigned int tail;
  /*
@@ -309,7 +311,8 @@ static void advance_ring(struct i915_request 
*request)

   * Note this requires that we are always called in request
   * completion order.
   */
-    if (list_is_last(>ring_link, 
>ring->request_list)) {
+    GEM_BUG_ON(!list_is_first(>ring_link, 
>request_list));

+    if (list_is_last(>ring_link, >request_list)) {
  /*
   * We may race here with execlists resubmitting this request
   * as we retire it. The resubmission will move the ring->tail
@@ -322,9 +325,9 @@ static void advance_ring(struct i915_request 
*request)

  } else {
  tail = request->postfix;
  }
-    list_del(>ring_link);
+    list_del_init(>ring_link);


Why the _init flavour? There are two list heads for being on two 
separate lists, but are either path reachable after being removed from 
the respective lists? (I may find the answer as I read on.)



-    request->ring->head = tail;
+    ring->head = tail;
  }
  static void free_capture_list(struct i915_request *request)
@@ -340,30 +343,79 @@ static void free_capture_list(struct 
i915_request *request)

  }
  }
+static void __retire_engine_request(struct intel_engine_cs *engine,
+    struct 

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Retire requests along rings

[Tvrtko Ursulin]

On 24/04/2018 14:14, Chris Wilson wrote:

In the next patch, rings are the central timeline as requests may jump
between engines. Therefore in the future as we retire in order along the
engine timeline, we may retire out-of-order within a ring (as the ring now
occurs along multiple engines), leading to much hilarity in miscomputing
the position of ring->head.

As an added bonus, retiring along the ring reduces the penalty of having
one execlists client do cleanup for another (old legacy submission
shares a ring between all clients). The downside is that slow and
irregular (off the critical path) process of cleaning up stale requests
after userspace becomes a modicum less efficient.

In the long run, it will become apparent that the ordered
ring->request_list matches the ring->timeline, a fun challenge for the
future will be unifying the two lists to avoid duplication!

v2: We need both engine-order and ring-order processing to maintain our
knowledge of where individual rings have completed upto as well as
knowing what was last executing on any engine. And finally by decoupling
retiring the contexts on the engine and the timelines along the rings,
we do have to keep a reference to the context on each request
(previously it was guaranteed by the context being pinned).

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/i915_drv.h   |   3 +-
  drivers/gpu/drm/i915/i915_gem.c   |   1 +
  drivers/gpu/drm/i915/i915_request.c   | 140 +++---
  drivers/gpu/drm/i915/i915_utils.h |   6 +
  drivers/gpu/drm/i915/intel_ringbuffer.c   |   6 +-
  drivers/gpu/drm/i915/intel_ringbuffer.h   |   1 +
  drivers/gpu/drm/i915/selftests/mock_engine.c  |  27 +++-
  .../gpu/drm/i915/selftests/mock_gem_device.c  |   2 +
  8 files changed, 120 insertions(+), 66 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8fd9fb6efba5..1837c01d44d0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2058,8 +2058,9 @@ struct drm_i915_private {
void (*resume)(struct drm_i915_private *);
void (*cleanup_engine)(struct intel_engine_cs *engine);
  
-		struct list_head timelines;

struct i915_gem_timeline global_timeline;
+   struct list_head timelines;
+   struct list_head rings;
u32 active_requests;
u32 request_serial;
  
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c

index 795ca83aed7a..906e2395c245 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5600,6 +5600,7 @@ int i915_gem_init_early(struct drm_i915_private *dev_priv)
goto err_dependencies;
  
  	mutex_lock(_priv->drm.struct_mutex);

+   INIT_LIST_HEAD(_priv->gt.rings);
INIT_LIST_HEAD(_priv->gt.timelines);
err = i915_gem_timeline_init__global(dev_priv);
mutex_unlock(_priv->drm.struct_mutex);
diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index b1993d4a1a53..aa84b5447fd5 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -286,6 +286,7 @@ static int reserve_gt(struct drm_i915_private *i915)
  
  static void unreserve_gt(struct drm_i915_private *i915)

  {
+   GEM_BUG_ON(!i915->gt.active_requests);
if (!--i915->gt.active_requests)
i915_gem_park(i915);
  }
@@ -298,6 +299,7 @@ void i915_gem_retire_noop(struct i915_gem_active *active,
  
  static void advance_ring(struct i915_request *request)

  {
+   struct intel_ring *ring = request->ring;
unsigned int tail;
  
  	/*

@@ -309,7 +311,8 @@ static void advance_ring(struct i915_request *request)
 * Note this requires that we are always called in request
 * completion order.
 */
-   if (list_is_last(>ring_link, >ring->request_list)) {
+   GEM_BUG_ON(!list_is_first(>ring_link, >request_list));
+   if (list_is_last(>ring_link, >request_list)) {
/*
 * We may race here with execlists resubmitting this request
 * as we retire it. The resubmission will move the ring->tail
@@ -322,9 +325,9 @@ static void advance_ring(struct i915_request *request)
} else {
tail = request->postfix;
}
-   list_del(>ring_link);
+   list_del_init(>ring_link);


Why the _init flavour? There are two list heads for being on two 
separate lists, but are either path reachable after being removed from 
the respective lists? (I may find the answer as I read on.)


  
-	request->ring->head = tail;

+   ring->head = tail;
  }
  
  static void free_capture_list(struct i915_request *request)

@@ -340,30 +343,79 @@ static void free_capture_list(struct i915_request 
*request)
}
  }
  
+static void 

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Retire requests along rings

[Chris Wilson]

Quoting Chris Wilson (2018-04-24 14:14:11)
> In the next patch, rings are the central timeline as requests may jump
> between engines. Therefore in the future as we retire in order along the
> engine timeline, we may retire out-of-order within a ring (as the ring now
> occurs along multiple engines), leading to much hilarity in miscomputing
> the position of ring->head.
> 
> As an added bonus, retiring along the ring reduces the penalty of having
> one execlists client do cleanup for another (old legacy submission
> shares a ring between all clients). The downside is that slow and
> irregular (off the critical path) process of cleaning up stale requests
> after userspace becomes a modicum less efficient.
> 
> In the long run, it will become apparent that the ordered
> ring->request_list matches the ring->timeline, a fun challenge for the
> future will be unifying the two lists to avoid duplication!
> 
> v2: We need both engine-order and ring-order processing to maintain our
> knowledge of where individual rings have completed upto as well as
> knowing what was last executing on any engine. And finally by decoupling
> retiring the contexts on the engine and the timelines along the rings,
> we do have to keep a reference to the context on each request
> (previously it was guaranteed by the context being pinned).
> 
> Signed-off-by: Chris Wilson 
> Cc: Tvrtko Ursulin 

As might have been expected, this is the one that gen8 takes a dislike
to. The symptom being a failed context switch leading to an
(eventual) unrecoverable GPU hang.

Afaict, I have all the asserts in place to ensure that we are tracking
the previous context correctly and only unpinning it after we guarantee
it is no longer in use by the GPU. Ideas? Can you see my mistake? :(

> ---
>  drivers/gpu/drm/i915/i915_drv.h   |   3 +-
>  drivers/gpu/drm/i915/i915_gem.c   |   1 +
>  drivers/gpu/drm/i915/i915_request.c   | 140 +++---
>  drivers/gpu/drm/i915/i915_utils.h |   6 +
>  drivers/gpu/drm/i915/intel_ringbuffer.c   |   6 +-
>  drivers/gpu/drm/i915/intel_ringbuffer.h   |   1 +
>  drivers/gpu/drm/i915/selftests/mock_engine.c  |  27 +++-
>  .../gpu/drm/i915/selftests/mock_gem_device.c  |   2 +
>  8 files changed, 120 insertions(+), 66 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 8fd9fb6efba5..1837c01d44d0 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2058,8 +2058,9 @@ struct drm_i915_private {
> void (*resume)(struct drm_i915_private *);
> void (*cleanup_engine)(struct intel_engine_cs *engine);
>  
> -   struct list_head timelines;
> struct i915_gem_timeline global_timeline;
> +   struct list_head timelines;
> +   struct list_head rings;
> u32 active_requests;
> u32 request_serial;
>  
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 795ca83aed7a..906e2395c245 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -5600,6 +5600,7 @@ int i915_gem_init_early(struct drm_i915_private 
> *dev_priv)
> goto err_dependencies;
>  
> mutex_lock(_priv->drm.struct_mutex);
> +   INIT_LIST_HEAD(_priv->gt.rings);
> INIT_LIST_HEAD(_priv->gt.timelines);
> err = i915_gem_timeline_init__global(dev_priv);
> mutex_unlock(_priv->drm.struct_mutex);
> diff --git a/drivers/gpu/drm/i915/i915_request.c 
> b/drivers/gpu/drm/i915/i915_request.c
> index b1993d4a1a53..aa84b5447fd5 100644
> --- a/drivers/gpu/drm/i915/i915_request.c
> +++ b/drivers/gpu/drm/i915/i915_request.c
> @@ -286,6 +286,7 @@ static int reserve_gt(struct drm_i915_private *i915)
>  
>  static void unreserve_gt(struct drm_i915_private *i915)
>  {
> +   GEM_BUG_ON(!i915->gt.active_requests);
> if (!--i915->gt.active_requests)
> i915_gem_park(i915);
>  }
> @@ -298,6 +299,7 @@ void i915_gem_retire_noop(struct i915_gem_active *active,
>  
>  static void advance_ring(struct i915_request *request)
>  {
> +   struct intel_ring *ring = request->ring;
> unsigned int tail;
>  
> /*
> @@ -309,7 +311,8 @@ static void advance_ring(struct i915_request *request)
>  * Note this requires that we are always called in request
>  * completion order.
>  */
> -   if (list_is_last(>ring_link, >ring->request_list)) {
> +   GEM_BUG_ON(!list_is_first(>ring_link, >request_list));
> +   if (list_is_last(>ring_link, >request_list)) {
> /*
>  * We may race here with execlists resubmitting this request
>  * as we retire it. The resubmission will move the ring->tail
> @@ -322,9 +325,9 @@ static void advance_ring(struct i915_request *request)
> } 

[Intel-gfx] [PATCH 2/6] drm/i915: Retire requests along rings

[Chris Wilson]

In the next patch, rings are the central timeline as requests may jump
between engines. Therefore in the future as we retire in order along the
engine timeline, we may retire out-of-order within a ring (as the ring now
occurs along multiple engines), leading to much hilarity in miscomputing
the position of ring->head.

As an added bonus, retiring along the ring reduces the penalty of having
one execlists client do cleanup for another (old legacy submission
shares a ring between all clients). The downside is that slow and
irregular (off the critical path) process of cleaning up stale requests
after userspace becomes a modicum less efficient.

In the long run, it will become apparent that the ordered
ring->request_list matches the ring->timeline, a fun challenge for the
future will be unifying the two lists to avoid duplication!

v2: We need both engine-order and ring-order processing to maintain our
knowledge of where individual rings have completed upto as well as
knowing what was last executing on any engine. And finally by decoupling
retiring the contexts on the engine and the timelines along the rings,
we do have to keep a reference to the context on each request
(previously it was guaranteed by the context being pinned).

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.h   |   3 +-
 drivers/gpu/drm/i915/i915_gem.c   |   1 +
 drivers/gpu/drm/i915/i915_request.c   | 140 +++---
 drivers/gpu/drm/i915/i915_utils.h |   6 +
 drivers/gpu/drm/i915/intel_ringbuffer.c   |   6 +-
 drivers/gpu/drm/i915/intel_ringbuffer.h   |   1 +
 drivers/gpu/drm/i915/selftests/mock_engine.c  |  27 +++-
 .../gpu/drm/i915/selftests/mock_gem_device.c  |   2 +
 8 files changed, 120 insertions(+), 66 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8fd9fb6efba5..1837c01d44d0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2058,8 +2058,9 @@ struct drm_i915_private {
void (*resume)(struct drm_i915_private *);
void (*cleanup_engine)(struct intel_engine_cs *engine);
 
-   struct list_head timelines;
struct i915_gem_timeline global_timeline;
+   struct list_head timelines;
+   struct list_head rings;
u32 active_requests;
u32 request_serial;
 
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 795ca83aed7a..906e2395c245 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5600,6 +5600,7 @@ int i915_gem_init_early(struct drm_i915_private *dev_priv)
goto err_dependencies;
 
mutex_lock(_priv->drm.struct_mutex);
+   INIT_LIST_HEAD(_priv->gt.rings);
INIT_LIST_HEAD(_priv->gt.timelines);
err = i915_gem_timeline_init__global(dev_priv);
mutex_unlock(_priv->drm.struct_mutex);
diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index b1993d4a1a53..aa84b5447fd5 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -286,6 +286,7 @@ static int reserve_gt(struct drm_i915_private *i915)
 
 static void unreserve_gt(struct drm_i915_private *i915)
 {
+   GEM_BUG_ON(!i915->gt.active_requests);
if (!--i915->gt.active_requests)
i915_gem_park(i915);
 }
@@ -298,6 +299,7 @@ void i915_gem_retire_noop(struct i915_gem_active *active,
 
 static void advance_ring(struct i915_request *request)
 {
+   struct intel_ring *ring = request->ring;
unsigned int tail;
 
/*
@@ -309,7 +311,8 @@ static void advance_ring(struct i915_request *request)
 * Note this requires that we are always called in request
 * completion order.
 */
-   if (list_is_last(>ring_link, >ring->request_list)) {
+   GEM_BUG_ON(!list_is_first(>ring_link, >request_list));
+   if (list_is_last(>ring_link, >request_list)) {
/*
 * We may race here with execlists resubmitting this request
 * as we retire it. The resubmission will move the ring->tail
@@ -322,9 +325,9 @@ static void advance_ring(struct i915_request *request)
} else {
tail = request->postfix;
}
-   list_del(>ring_link);
+   list_del_init(>ring_link);
 
-   request->ring->head = tail;
+   ring->head = tail;
 }
 
 static void free_capture_list(struct i915_request *request)
@@ -340,30 +343,79 @@ static void free_capture_list(struct i915_request 
*request)
}
 }
 
+static void __retire_engine_request(struct intel_engine_cs *engine,
+   struct i915_request *request)
+{
+   GEM_BUG_ON(!i915_request_completed(request));
+
+   local_irq_disable();
+
+   spin_lock(>timeline->lock);
+  

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Retire requests along rings

[Tvrtko Ursulin]

On 23/04/2018 11:13, Chris Wilson wrote:

In the next patch, rings are the central timeline as requests may jump
between engines. Therefore in the future as we retire in order along the
engine timeline, we may retire out-of-order within a ring (as the ring now
occurs along multiple engines), leading to much hilarity in miscomputing
the position of ring->head.

As an added bonus, retiring along the ring reduces the penalty of having
one execlists client do cleanup for another (old legacy submission
shares a ring between all clients). The downside is that slow and
irregular (off the critical path) process of cleaning up stale requests
after userspace becomes a modicum less efficient.

In the long run, it will become apparent that the ordered
ring->request_list matches the ring->timeline, a fun challenge for the
future will be unifying the two lists to avoid duplication!

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/i915_drv.h   |  3 +-
  drivers/gpu/drm/i915/i915_gem.c   |  1 +
  drivers/gpu/drm/i915/i915_request.c   | 43 ---
  drivers/gpu/drm/i915/intel_ringbuffer.c   |  5 +++
  drivers/gpu/drm/i915/intel_ringbuffer.h   |  1 +
  drivers/gpu/drm/i915/selftests/mock_engine.c  | 27 +---
  .../gpu/drm/i915/selftests/mock_gem_device.c  |  2 +
  7 files changed, 50 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8444ca8d5aa3..73936be90aed 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2058,8 +2058,9 @@ struct drm_i915_private {
void (*resume)(struct drm_i915_private *);
void (*cleanup_engine)(struct intel_engine_cs *engine);
  
-		struct list_head timelines;

struct i915_gem_timeline global_timeline;
+   struct list_head timelines;
+   struct list_head rings;
u32 active_requests;
  
  		/**

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 795ca83aed7a..906e2395c245 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5600,6 +5600,7 @@ int i915_gem_init_early(struct drm_i915_private *dev_priv)
goto err_dependencies;
  
  	mutex_lock(_priv->drm.struct_mutex);

+   INIT_LIST_HEAD(_priv->gt.rings);
INIT_LIST_HEAD(_priv->gt.timelines);
err = i915_gem_timeline_init__global(dev_priv);
mutex_unlock(_priv->drm.struct_mutex);
diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index 1437538d5bfa..0bf949ec9f1a 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -292,6 +292,7 @@ void i915_gem_retire_noop(struct i915_gem_active *active,
  
  static void advance_ring(struct i915_request *request)

  {
+   struct intel_ring *ring = request->ring;
unsigned int tail;
  
  	/*

@@ -303,7 +304,9 @@ static void advance_ring(struct i915_request *request)
 * Note this requires that we are always called in request
 * completion order.
 */
-   if (list_is_last(>ring_link, >ring->request_list)) {
+   GEM_BUG_ON(request != list_first_entry(>request_list,
+  typeof(*request), ring_link));
+   if (list_is_last(>ring_link, >request_list)) {
/*
 * We may race here with execlists resubmitting this request
 * as we retire it. The resubmission will move the ring->tail
@@ -318,7 +321,7 @@ static void advance_ring(struct i915_request *request)
}
list_del(>ring_link);
  
-	request->ring->head = tail;

+   ring->head = tail;
  }
  
  static void free_capture_list(struct i915_request *request)

@@ -424,18 +427,18 @@ static void i915_request_retire(struct i915_request 
*request)
  
  void i915_request_retire_upto(struct i915_request *rq)

  {
-   struct intel_engine_cs *engine = rq->engine;
+   struct intel_ring *ring = rq->ring;
struct i915_request *tmp;
  
  	lockdep_assert_held(>i915->drm.struct_mutex);

GEM_BUG_ON(!i915_request_completed(rq));
  
-	if (list_empty(>link))

+   if (list_empty(>ring_link))
return;
  
  	do {

-   tmp = list_first_entry(>timeline->requests,
-  typeof(*tmp), link);
+   tmp = list_first_entry(>request_list,
+  typeof(*tmp), ring_link);
  
  		i915_request_retire(tmp);

} while (tmp != rq);
@@ -644,9 +647,9 @@ i915_request_alloc(struct intel_engine_cs *engine, struct 
i915_gem_context *ctx)
if (ret)
goto err_unreserve;
  
-	/* Move the oldest request to the slab-cache (if not in use!) */

-   rq = list_first_entry_or_null(>timeline->requests,
-   

[Intel-gfx] [PATCH 2/6] drm/i915: Retire requests along rings

[Chris Wilson]

In the next patch, rings are the central timeline as requests may jump
between engines. Therefore in the future as we retire in order along the
engine timeline, we may retire out-of-order within a ring (as the ring now
occurs along multiple engines), leading to much hilarity in miscomputing
the position of ring->head.

As an added bonus, retiring along the ring reduces the penalty of having
one execlists client do cleanup for another (old legacy submission
shares a ring between all clients). The downside is that slow and
irregular (off the critical path) process of cleaning up stale requests
after userspace becomes a modicum less efficient.

In the long run, it will become apparent that the ordered
ring->request_list matches the ring->timeline, a fun challenge for the
future will be unifying the two lists to avoid duplication!

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.h   |  3 +-
 drivers/gpu/drm/i915/i915_gem.c   |  1 +
 drivers/gpu/drm/i915/i915_request.c   | 43 ---
 drivers/gpu/drm/i915/intel_ringbuffer.c   |  5 +++
 drivers/gpu/drm/i915/intel_ringbuffer.h   |  1 +
 drivers/gpu/drm/i915/selftests/mock_engine.c  | 27 +---
 .../gpu/drm/i915/selftests/mock_gem_device.c  |  2 +
 7 files changed, 50 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8444ca8d5aa3..73936be90aed 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2058,8 +2058,9 @@ struct drm_i915_private {
void (*resume)(struct drm_i915_private *);
void (*cleanup_engine)(struct intel_engine_cs *engine);
 
-   struct list_head timelines;
struct i915_gem_timeline global_timeline;
+   struct list_head timelines;
+   struct list_head rings;
u32 active_requests;
 
/**
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 795ca83aed7a..906e2395c245 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5600,6 +5600,7 @@ int i915_gem_init_early(struct drm_i915_private *dev_priv)
goto err_dependencies;
 
mutex_lock(_priv->drm.struct_mutex);
+   INIT_LIST_HEAD(_priv->gt.rings);
INIT_LIST_HEAD(_priv->gt.timelines);
err = i915_gem_timeline_init__global(dev_priv);
mutex_unlock(_priv->drm.struct_mutex);
diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index 1437538d5bfa..0bf949ec9f1a 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -292,6 +292,7 @@ void i915_gem_retire_noop(struct i915_gem_active *active,
 
 static void advance_ring(struct i915_request *request)
 {
+   struct intel_ring *ring = request->ring;
unsigned int tail;
 
/*
@@ -303,7 +304,9 @@ static void advance_ring(struct i915_request *request)
 * Note this requires that we are always called in request
 * completion order.
 */
-   if (list_is_last(>ring_link, >ring->request_list)) {
+   GEM_BUG_ON(request != list_first_entry(>request_list,
+  typeof(*request), ring_link));
+   if (list_is_last(>ring_link, >request_list)) {
/*
 * We may race here with execlists resubmitting this request
 * as we retire it. The resubmission will move the ring->tail
@@ -318,7 +321,7 @@ static void advance_ring(struct i915_request *request)
}
list_del(>ring_link);
 
-   request->ring->head = tail;
+   ring->head = tail;
 }
 
 static void free_capture_list(struct i915_request *request)
@@ -424,18 +427,18 @@ static void i915_request_retire(struct i915_request 
*request)
 
 void i915_request_retire_upto(struct i915_request *rq)
 {
-   struct intel_engine_cs *engine = rq->engine;
+   struct intel_ring *ring = rq->ring;
struct i915_request *tmp;
 
lockdep_assert_held(>i915->drm.struct_mutex);
GEM_BUG_ON(!i915_request_completed(rq));
 
-   if (list_empty(>link))
+   if (list_empty(>ring_link))
return;
 
do {
-   tmp = list_first_entry(>timeline->requests,
-  typeof(*tmp), link);
+   tmp = list_first_entry(>request_list,
+  typeof(*tmp), ring_link);
 
i915_request_retire(tmp);
} while (tmp != rq);
@@ -644,9 +647,9 @@ i915_request_alloc(struct intel_engine_cs *engine, struct 
i915_gem_context *ctx)
if (ret)
goto err_unreserve;
 
-   /* Move the oldest request to the slab-cache (if not in use!) */
-   rq = list_first_entry_or_null(>timeline->requests,
-