From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 14/20] drm/i915/gt: Track timeline activeness in enter/exit
Date: Mon, 22 Jul 2019 17:14:23 +0100 [thread overview]
Message-ID: <cdae186f-8f1f-7d1d-dd18-b129ab8053ae@linux.intel.com> (raw)
In-Reply-To: <20190718070024.21781-14-chris@chris-wilson.co.uk>
On 18/07/2019 08:00, Chris Wilson wrote:
> Lift moving the timeline to/from the active_list on enter/exit in order
> to shorten the active tracking span in comparison to the existing
> pin/unpin.
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> ---
> drivers/gpu/drm/i915/gem/i915_gem_pm.c | 1 -
> drivers/gpu/drm/i915/gt/intel_context.c | 2 +
> drivers/gpu/drm/i915/gt/intel_engine_pm.c | 1 +
> drivers/gpu/drm/i915/gt/intel_lrc.c | 4 +
> drivers/gpu/drm/i915/gt/intel_timeline.c | 98 +++++++------------
> drivers/gpu/drm/i915/gt/intel_timeline.h | 3 +-
> .../gpu/drm/i915/gt/intel_timeline_types.h | 1 +
> drivers/gpu/drm/i915/gt/selftest_timeline.c | 2 -
> 8 files changed, 46 insertions(+), 66 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
> index 8faf262278ae..195ee6eedac0 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
> @@ -39,7 +39,6 @@ static void i915_gem_park(struct drm_i915_private *i915)
> i915_gem_batch_pool_fini(&engine->batch_pool);
> }
>
> - intel_timelines_park(i915);
> i915_vma_parked(i915);
>
> i915_globals_park();
> diff --git a/drivers/gpu/drm/i915/gt/intel_context.c b/drivers/gpu/drm/i915/gt/intel_context.c
> index 9830edda1ade..87c84cc0f658 100644
> --- a/drivers/gpu/drm/i915/gt/intel_context.c
> +++ b/drivers/gpu/drm/i915/gt/intel_context.c
> @@ -242,10 +242,12 @@ int __init i915_global_context_init(void)
> void intel_context_enter_engine(struct intel_context *ce)
> {
> intel_engine_pm_get(ce->engine);
> + intel_timeline_enter(ce->ring->timeline);
> }
>
> void intel_context_exit_engine(struct intel_context *ce)
> {
> + intel_timeline_exit(ce->ring->timeline);
> intel_engine_pm_put(ce->engine);
> }
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> index e74fbf04a68d..072f65e6a09e 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> @@ -89,6 +89,7 @@ static bool switch_to_kernel_context(struct intel_engine_cs *engine)
>
> /* Check again on the next retirement. */
> engine->wakeref_serial = engine->serial + 1;
> + intel_timeline_enter(rq->timeline);
>
> i915_request_add_barriers(rq);
> __i915_request_commit(rq);
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index 884dfc1cb033..aceb990ae3b9 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -3253,6 +3253,8 @@ static void virtual_context_enter(struct intel_context *ce)
>
> for (n = 0; n < ve->num_siblings; n++)
> intel_engine_pm_get(ve->siblings[n]);
> +
> + intel_timeline_enter(ce->ring->timeline);
Here we couldn't enter all sibling contexts instead? Would be a bit
wasteful I guess. And there must be a place where it is already done.
But can't be on picking the engine, where is it?
> }
>
> static void virtual_context_exit(struct intel_context *ce)
> @@ -3260,6 +3262,8 @@ static void virtual_context_exit(struct intel_context *ce)
> struct virtual_engine *ve = container_of(ce, typeof(*ve), context);
> unsigned int n;
>
> + intel_timeline_exit(ce->ring->timeline);
> +
> for (n = 0; n < ve->num_siblings; n++)
> intel_engine_pm_put(ve->siblings[n]);
> }
> diff --git a/drivers/gpu/drm/i915/gt/intel_timeline.c b/drivers/gpu/drm/i915/gt/intel_timeline.c
> index 6daa9eb59e19..4af0b9801d91 100644
> --- a/drivers/gpu/drm/i915/gt/intel_timeline.c
> +++ b/drivers/gpu/drm/i915/gt/intel_timeline.c
> @@ -278,64 +278,11 @@ void intel_timelines_init(struct drm_i915_private *i915)
> timelines_init(&i915->gt);
> }
>
> -static void timeline_add_to_active(struct intel_timeline *tl)
> -{
> - struct intel_gt_timelines *gt = &tl->gt->timelines;
> -
> - mutex_lock(>->mutex);
> - list_add(&tl->link, >->active_list);
> - mutex_unlock(>->mutex);
> -}
> -
> -static void timeline_remove_from_active(struct intel_timeline *tl)
> -{
> - struct intel_gt_timelines *gt = &tl->gt->timelines;
> -
> - mutex_lock(>->mutex);
> - list_del(&tl->link);
> - mutex_unlock(>->mutex);
> -}
> -
> -static void timelines_park(struct intel_gt *gt)
> -{
> - struct intel_gt_timelines *timelines = >->timelines;
> - struct intel_timeline *timeline;
> -
> - mutex_lock(&timelines->mutex);
> - list_for_each_entry(timeline, &timelines->active_list, link) {
> - /*
> - * All known fences are completed so we can scrap
> - * the current sync point tracking and start afresh,
> - * any attempt to wait upon a previous sync point
> - * will be skipped as the fence was signaled.
> - */
> - i915_syncmap_free(&timeline->sync);
> - }
> - mutex_unlock(&timelines->mutex);
> -}
> -
> -/**
> - * intel_timelines_park - called when the driver idles
> - * @i915: the drm_i915_private device
> - *
> - * When the driver is completely idle, we know that all of our sync points
> - * have been signaled and our tracking is then entirely redundant. Any request
> - * to wait upon an older sync point will be completed instantly as we know
> - * the fence is signaled and therefore we will not even look them up in the
> - * sync point map.
> - */
> -void intel_timelines_park(struct drm_i915_private *i915)
> -{
> - timelines_park(&i915->gt);
> -}
> -
> void intel_timeline_fini(struct intel_timeline *timeline)
> {
> GEM_BUG_ON(timeline->pin_count);
> GEM_BUG_ON(!list_empty(&timeline->requests));
>
> - i915_syncmap_free(&timeline->sync);
> -
> if (timeline->hwsp_cacheline)
> cacheline_free(timeline->hwsp_cacheline);
> else
> @@ -370,6 +317,7 @@ int intel_timeline_pin(struct intel_timeline *tl)
> if (tl->pin_count++)
> return 0;
> GEM_BUG_ON(!tl->pin_count);
> + GEM_BUG_ON(tl->active_count);
>
> err = i915_vma_pin(tl->hwsp_ggtt, 0, 0, PIN_GLOBAL | PIN_HIGH);
> if (err)
> @@ -380,7 +328,6 @@ int intel_timeline_pin(struct intel_timeline *tl)
> offset_in_page(tl->hwsp_offset);
>
> cacheline_acquire(tl->hwsp_cacheline);
> - timeline_add_to_active(tl);
>
> return 0;
>
> @@ -389,6 +336,40 @@ int intel_timeline_pin(struct intel_timeline *tl)
> return err;
> }
>
> +void intel_timeline_enter(struct intel_timeline *tl)
> +{
> + struct intel_gt_timelines *timelines = &tl->gt->timelines;
> +
> + GEM_BUG_ON(!tl->pin_count);
> + if (tl->active_count++)
> + return;
> + GEM_BUG_ON(!tl->active_count); /* overflow? */
> +
> + mutex_lock(&timelines->mutex);
> + list_add(&tl->link, &timelines->active_list);
> + mutex_unlock(&timelines->mutex);
> +}
> +
> +void intel_timeline_exit(struct intel_timeline *tl)
> +{
> + struct intel_gt_timelines *timelines = &tl->gt->timelines;
> +
> + GEM_BUG_ON(!tl->active_count);
> + if (--tl->active_count)
> + return;
> +
> + mutex_lock(&timelines->mutex);
> + list_del(&tl->link);
> + mutex_unlock(&timelines->mutex);
So we end up with one lock protecting tl->active_count and another for
the list of active timelines?
> +
> + /*
> + * Since this timeline is idle, all bariers upon which we were waiting
> + * must also be complete and so we can discard the last used barriers
> + * without loss of information.
> + */
> + i915_syncmap_free(&tl->sync);
> +}
> +
> static u32 timeline_advance(struct intel_timeline *tl)
> {
> GEM_BUG_ON(!tl->pin_count);
> @@ -546,16 +527,9 @@ void intel_timeline_unpin(struct intel_timeline *tl)
> if (--tl->pin_count)
> return;
>
> - timeline_remove_from_active(tl);
> + GEM_BUG_ON(tl->active_count);
> cacheline_release(tl->hwsp_cacheline);
>
> - /*
> - * Since this timeline is idle, all bariers upon which we were waiting
> - * must also be complete and so we can discard the last used barriers
> - * without loss of information.
> - */
> - i915_syncmap_free(&tl->sync);
> -
> __i915_vma_unpin(tl->hwsp_ggtt);
> }
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_timeline.h b/drivers/gpu/drm/i915/gt/intel_timeline.h
> index e08cebf64833..f583af1ba18d 100644
> --- a/drivers/gpu/drm/i915/gt/intel_timeline.h
> +++ b/drivers/gpu/drm/i915/gt/intel_timeline.h
> @@ -77,9 +77,11 @@ static inline bool intel_timeline_sync_is_later(struct intel_timeline *tl,
> }
>
> int intel_timeline_pin(struct intel_timeline *tl);
> +void intel_timeline_enter(struct intel_timeline *tl);
> int intel_timeline_get_seqno(struct intel_timeline *tl,
> struct i915_request *rq,
> u32 *seqno);
> +void intel_timeline_exit(struct intel_timeline *tl);
> void intel_timeline_unpin(struct intel_timeline *tl);
>
> int intel_timeline_read_hwsp(struct i915_request *from,
> @@ -87,7 +89,6 @@ int intel_timeline_read_hwsp(struct i915_request *from,
> u32 *hwsp_offset);
>
> void intel_timelines_init(struct drm_i915_private *i915);
> -void intel_timelines_park(struct drm_i915_private *i915);
> void intel_timelines_fini(struct drm_i915_private *i915);
>
> #endif
> diff --git a/drivers/gpu/drm/i915/gt/intel_timeline_types.h b/drivers/gpu/drm/i915/gt/intel_timeline_types.h
> index 9a71aea7a338..b820ee76b7f5 100644
> --- a/drivers/gpu/drm/i915/gt/intel_timeline_types.h
> +++ b/drivers/gpu/drm/i915/gt/intel_timeline_types.h
> @@ -58,6 +58,7 @@ struct intel_timeline {
> */
> struct i915_syncmap *sync;
>
> + unsigned int active_count;
Is it becoming non-obvious what is pin_count and what is active_count? I
suggest some comments dropped along the members here.
> struct list_head link;
> struct intel_gt *gt;
>
> diff --git a/drivers/gpu/drm/i915/gt/selftest_timeline.c b/drivers/gpu/drm/i915/gt/selftest_timeline.c
> index f0a840030382..d54113697745 100644
> --- a/drivers/gpu/drm/i915/gt/selftest_timeline.c
> +++ b/drivers/gpu/drm/i915/gt/selftest_timeline.c
> @@ -816,8 +816,6 @@ static int live_hwsp_recycle(void *arg)
>
> if (err)
> goto out;
> -
> - intel_timelines_park(i915); /* Encourage recycling! */
> } while (!__igt_timeout(end_time, NULL));
> }
>
>
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2019-07-22 16:14 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20190718070024.21781-1-chris@chris-wilson.co.uk>
2019-07-18 7:00 ` [PATCH 02/20] drm/i915/gt: Hook up intel_context_fini() Chris Wilson
2019-07-22 12:22 ` Tvrtko Ursulin
2019-07-18 7:00 ` [PATCH 04/20] drm/i915/execlists: Cancel breadcrumb on preempting the virtual engine Chris Wilson
2019-07-18 7:00 ` [PATCH 05/20] drm/i915: Hide unshrinkable context objects from the shrinker Chris Wilson
2019-07-18 7:00 ` [PATCH 06/20] drm/i915: Remove obsolete engine cleanup Chris Wilson
2019-07-22 12:46 ` Tvrtko Ursulin
2019-07-22 16:29 ` Chris Wilson
2019-07-18 7:00 ` [PATCH 07/20] drm/i915/gt: Move the [class][inst] lookup for engines onto the GT Chris Wilson
2019-07-18 7:00 ` [PATCH 09/20] drm/i915: Use intel_engine_lookup_user for probing HAS_BSD etc Chris Wilson
2019-07-22 12:49 ` Tvrtko Ursulin
2019-07-22 16:34 ` Chris Wilson
2019-07-18 7:00 ` [PATCH 11/20] drm/i915: Rely on spinlock protection for GPU error capture Chris Wilson
2019-07-22 13:40 ` Tvrtko Ursulin
2019-07-18 7:00 ` [PATCH 13/20] drm/i915: Teach execbuffer to take the engine wakeref not GT Chris Wilson
2019-07-22 16:03 ` Tvrtko Ursulin
2019-07-18 7:00 ` [PATCH 14/20] drm/i915/gt: Track timeline activeness in enter/exit Chris Wilson
2019-07-22 16:14 ` Tvrtko Ursulin [this message]
2019-07-22 16:42 ` Chris Wilson
2019-07-18 7:00 ` [PATCH 15/20] drm/i915/gt: Convert timeline tracking to spinlock Chris Wilson
2019-07-18 7:00 ` [PATCH 17/20] drm/i915/gt: Add to timeline requires the timeline mutex Chris Wilson
2019-07-18 7:00 ` [PATCH 18/20] drm/i915: Protect request retirement with timeline->mutex Chris Wilson
2019-07-18 7:00 ` [PATCH 20/20] drm/i915/gt: Mark context->active_count as protected by timeline->mutex Chris Wilson
2019-07-18 7:16 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/20] drm/i915: Move aliasing_ppgtt underneath its i915_ggtt Patchwork
2019-07-18 7:25 ` ✗ Fi.CI.SPARSE: " Patchwork
2019-07-18 7:48 ` ✓ Fi.CI.BAT: success " Patchwork
2019-07-18 10:05 ` ✓ Fi.CI.IGT: " Patchwork
[not found] ` <20190718070024.21781-3-chris@chris-wilson.co.uk>
2019-07-22 12:33 ` [PATCH 03/20] drm/i915/gt: Provde a local intel_context.vm Tvrtko Ursulin
2019-07-22 16:28 ` Chris Wilson
2019-07-23 13:44 ` Tvrtko Ursulin
[not found] ` <20190718070024.21781-10-chris@chris-wilson.co.uk>
2019-07-22 12:53 ` [PATCH 10/20] drm/i915: Isolate i915_getparam_ioctl() Tvrtko Ursulin
2019-07-22 16:04 ` Tvrtko Ursulin
2019-07-22 16:16 ` Chris Wilson
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=cdae186f-8f1f-7d1d-dd18-b129ab8053ae@linux.intel.com \
--to=tvrtko.ursulin@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox