From: Mika Kuoppala <mika.kuoppala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 04/26] drm/i915: Flush the execution-callbacks on retiring
Date: Wed, 19 Jun 2019 16:12:46 +0300 [thread overview]
Message-ID: <87fto57m7l.fsf@gaia.fi.intel.com> (raw)
In-Reply-To: <20190618074153.16055-4-chris@chris-wilson.co.uk>
Chris Wilson <chris@chris-wilson.co.uk> writes:
> In the unlikely case the request completes while we regard it as not even
> executing on the GPU (see the next patch!), we have to flush any pending
> execution callbacks at retirement and ensure that we do not add any
> more.
>
I did see the next patch. Looked like a mountain.
Well we don't lose warnings and we should never see
a precompleted request with current codebase so,
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> ---
> drivers/gpu/drm/i915/i915_request.c | 93 +++++++++++++++--------------
> 1 file changed, 49 insertions(+), 44 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c
> index d7fd77e8a789..51b068a57193 100644
> --- a/drivers/gpu/drm/i915/i915_request.c
> +++ b/drivers/gpu/drm/i915/i915_request.c
> @@ -119,6 +119,50 @@ const struct dma_fence_ops i915_fence_ops = {
> .release = i915_fence_release,
> };
>
> +static void irq_execute_cb(struct irq_work *wrk)
> +{
> + struct execute_cb *cb = container_of(wrk, typeof(*cb), work);
> +
> + i915_sw_fence_complete(cb->fence);
> + kmem_cache_free(global.slab_execute_cbs, cb);
> +}
> +
> +static void irq_execute_cb_hook(struct irq_work *wrk)
> +{
> + struct execute_cb *cb = container_of(wrk, typeof(*cb), work);
> +
> + cb->hook(container_of(cb->fence, struct i915_request, submit),
> + &cb->signal->fence);
> + i915_request_put(cb->signal);
> +
> + irq_execute_cb(wrk);
> +}
> +
> +static void __notify_execute_cb(struct i915_request *rq)
> +{
> + struct execute_cb *cb;
> +
> + lockdep_assert_held(&rq->lock);
> +
> + if (list_empty(&rq->execute_cb))
> + return;
> +
> + list_for_each_entry(cb, &rq->execute_cb, link)
> + irq_work_queue(&cb->work);
> +
> + /*
> + * XXX Rollback on __i915_request_unsubmit()
> + *
> + * In the future, perhaps when we have an active time-slicing scheduler,
> + * it will be interesting to unsubmit parallel execution and remove
> + * busywaits from the GPU until their master is restarted. This is
> + * quite hairy, we have to carefully rollback the fence and do a
> + * preempt-to-idle cycle on the target engine, all the while the
> + * master execute_cb may refire.
> + */
> + INIT_LIST_HEAD(&rq->execute_cb);
> +}
> +
> static inline void
> i915_request_remove_from_client(struct i915_request *request)
> {
> @@ -246,6 +290,11 @@ static bool i915_request_retire(struct i915_request *rq)
> GEM_BUG_ON(!atomic_read(&rq->i915->gt_pm.rps.num_waiters));
> atomic_dec(&rq->i915->gt_pm.rps.num_waiters);
> }
> + if (!test_bit(I915_FENCE_FLAG_ACTIVE, &rq->fence.flags)) {
> + set_bit(I915_FENCE_FLAG_ACTIVE, &rq->fence.flags);
> + __notify_execute_cb(rq);
> + }
> + GEM_BUG_ON(!list_empty(&rq->execute_cb));
> spin_unlock(&rq->lock);
>
> local_irq_enable();
> @@ -285,50 +334,6 @@ void i915_request_retire_upto(struct i915_request *rq)
> } while (i915_request_retire(tmp) && tmp != rq);
> }
>
> -static void irq_execute_cb(struct irq_work *wrk)
> -{
> - struct execute_cb *cb = container_of(wrk, typeof(*cb), work);
> -
> - i915_sw_fence_complete(cb->fence);
> - kmem_cache_free(global.slab_execute_cbs, cb);
> -}
> -
> -static void irq_execute_cb_hook(struct irq_work *wrk)
> -{
> - struct execute_cb *cb = container_of(wrk, typeof(*cb), work);
> -
> - cb->hook(container_of(cb->fence, struct i915_request, submit),
> - &cb->signal->fence);
> - i915_request_put(cb->signal);
> -
> - irq_execute_cb(wrk);
> -}
> -
> -static void __notify_execute_cb(struct i915_request *rq)
> -{
> - struct execute_cb *cb;
> -
> - lockdep_assert_held(&rq->lock);
> -
> - if (list_empty(&rq->execute_cb))
> - return;
> -
> - list_for_each_entry(cb, &rq->execute_cb, link)
> - irq_work_queue(&cb->work);
> -
> - /*
> - * XXX Rollback on __i915_request_unsubmit()
> - *
> - * In the future, perhaps when we have an active time-slicing scheduler,
> - * it will be interesting to unsubmit parallel execution and remove
> - * busywaits from the GPU until their master is restarted. This is
> - * quite hairy, we have to carefully rollback the fence and do a
> - * preempt-to-idle cycle on the target engine, all the while the
> - * master execute_cb may refire.
> - */
> - INIT_LIST_HEAD(&rq->execute_cb);
> -}
> -
> static int
> __i915_request_await_execution(struct i915_request *rq,
> struct i915_request *signal,
> --
> 2.20.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2019-06-19 13:12 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-18 7:41 [PATCH 01/26] drm/i915: Keep engine alive as we retire the context Chris Wilson
2019-06-18 7:41 ` [PATCH 02/26] drm/i915: Skip shrinking already freed pages Chris Wilson
2019-06-18 11:59 ` Chris Wilson
2019-06-18 16:06 ` Mika Kuoppala
2019-06-18 16:22 ` Chris Wilson
2019-06-18 7:41 ` [PATCH 03/26] drm/i915: Stop passing I915_WAIT_LOCKED to i915_request_wait() Chris Wilson
2019-06-19 11:44 ` Mika Kuoppala
2019-06-18 7:41 ` [PATCH 04/26] drm/i915: Flush the execution-callbacks on retiring Chris Wilson
2019-06-19 13:12 ` Mika Kuoppala [this message]
2019-06-19 13:18 ` Chris Wilson
2019-06-18 7:41 ` [PATCH 05/26] drm/i915/execlists: Preempt-to-busy Chris Wilson
2019-06-18 7:41 ` [PATCH 06/26] drm/i915/execlists: Minimalistic timeslicing Chris Wilson
2019-06-18 7:41 ` [PATCH 07/26] drm/i915/execlists: Force preemption Chris Wilson
2019-06-18 7:41 ` [PATCH 08/26] drm/i915: Make the semaphore saturation mask global Chris Wilson
2019-06-19 10:45 ` Tvrtko Ursulin
2019-06-18 7:41 ` [PATCH 09/26] dma-fence: Propagate errors to dma-fence-array container Chris Wilson
2019-06-18 7:41 ` [PATCH 10/26] dma-fence: Report the composite sync_file status Chris Wilson
2019-06-18 7:41 ` [PATCH 11/26] dma-fence: Refactor signaling for manual invocation Chris Wilson
2019-06-18 7:41 ` [PATCH 12/26] dma-fence: Always execute signal callbacks Chris Wilson
2019-06-18 7:41 ` [PATCH 13/26] drm/i915: Track i915_active using debugobjects Chris Wilson
2019-06-18 7:41 ` [PATCH 14/26] drm/i915: Signal fence completion from i915_request_wait Chris Wilson
2019-06-18 7:41 ` [PATCH 15/26] drm/i915: Remove waiting & retiring from shrinker paths Chris Wilson
2019-06-18 7:41 ` [PATCH 16/26] drm/i915: Throw away the active object retirement complexity Chris Wilson
2019-06-18 7:41 ` [PATCH 17/26] drm/i915: Provide an i915_active.acquire callback Chris Wilson
2019-06-18 7:41 ` [PATCH 18/26] drm/i915: Push the i915_active.retire into a worker Chris Wilson
2019-06-18 7:41 ` [PATCH 19/26] drm/i915/overlay: Switch to using i915_active tracking Chris Wilson
2019-06-18 7:41 ` [PATCH 20/26] drm/i915: Forgo last_fence active request tracking Chris Wilson
2019-06-18 7:41 ` [PATCH 21/26] drm/i915: Extract intel_frontbuffer active tracking Chris Wilson
2019-06-18 7:41 ` [PATCH 22/26] drm/i915: Coordinate i915_active with its own mutex Chris Wilson
2019-06-18 7:41 ` [PATCH 23/26] drm/i915: Rename intel_wakeref_[is]_active Chris Wilson
2019-06-18 8:14 ` Chris Wilson
2019-06-18 7:41 ` [PATCH 24/26] drm/i915: Teach execbuffer to take the engine wakeref not GT Chris Wilson
2019-06-18 7:41 ` [PATCH 25/26] drm/i915: Replace struct_mutex for batch pool serialisation Chris Wilson
2019-06-18 7:41 ` [PATCH 26/26] drm/i915: Move idle barrier cleanup into engine-pm Chris Wilson
2019-06-18 8:57 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/26] drm/i915: Keep engine alive as we retire the context Patchwork
2019-06-18 9:09 ` ✗ Fi.CI.SPARSE: " Patchwork
2019-06-18 9:18 ` ✓ Fi.CI.BAT: success " Patchwork
2019-06-18 13:45 ` [PATCH 01/26] " Mika Kuoppala
2019-06-18 13:59 ` Chris Wilson
2019-06-18 14:03 ` Chris Wilson
2019-06-18 14:08 ` Mika Kuoppala
2019-06-18 19:15 ` ✗ Fi.CI.IGT: failure for series starting with [01/26] " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87fto57m7l.fsf@gaia.fi.intel.com \
--to=mika.kuoppala@linux.intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=intel-gfx@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.