From: Dave Gordon <david.s.gordon@intel.com>
To: intel-gfx@lists.freedesktop.org, Chris Wilson <chris@chris-wilson.co.uk>
Subject: Re: [CI 22/25] drm/i915: Track the previous pinned context inside the request
Date: Thu, 28 Apr 2016 19:15:23 +0100 [thread overview]
Message-ID: <5722533B.8090307@intel.com> (raw)
In-Reply-To: <1461833819-3991-22-git-send-email-chris@chris-wilson.co.uk>
On 28/04/16 09:56, Chris Wilson wrote:
> As the contexts are accessed by the hardware until the switch is completed
> to a new context, the hardware may still be writing to the context object
> after the breadcrumb is visible. We must not unpin/unbind/prune that
> object whilst still active and so we keep the previous context pinned until
> the following request. We can generalise the tracking we already do via
> the engine->last_context and move it to the request so that it works
> equally for execlists and GuC.
>
> v2: Drop the execlists double pin as that exposes a race inside the lrc
> irq handler as it tries to access the context after it may be retired.
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> ---
Hmmm .. not sure this is going to play well with request reordering in
the scheduler, or with preemption! I think it makes it a bit more
difficult; perhaps we will just have to clear it for all preempted requests.
.Dave.
> drivers/gpu/drm/i915/i915_drv.h | 11 +++++++++++
> drivers/gpu/drm/i915/i915_gem.c | 8 ++++----
> drivers/gpu/drm/i915/intel_lrc.c | 14 ++++++++------
> 3 files changed, 23 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 0bd9d17ff974..eb4a95b853dd 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2305,6 +2305,17 @@ struct drm_i915_gem_request {
> struct intel_context *ctx;
> struct intel_ringbuffer *ringbuf;
>
> + /**
> + * Context related to the previous request.
> + * As the contexts are accessed by the hardware until the switch is
> + * completed to a new context, the hardware may still be writing
> + * to the context object after the breadcrumb is visible. We must
> + * not unpin/unbind/prune that object whilst still active and so
> + * we keep the previous context pinned until the following (this)
> + * request is retired.
> + */
> + struct intel_context *previous_context;
> +
> /** Batch buffer related to this request if any (used for
> error state dump only) */
> struct drm_i915_gem_object *batch_obj;
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index e4c8a8b998d1..fc68af50ed1b 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1413,13 +1413,13 @@ static void i915_gem_request_retire(struct drm_i915_gem_request *request)
> list_del_init(&request->list);
> i915_gem_request_remove_from_client(request);
>
> - if (request->ctx) {
> + if (request->previous_context) {
> if (i915.enable_execlists)
> - intel_lr_context_unpin(request->ctx, request->engine);
> -
> - i915_gem_context_unreference(request->ctx);
> + intel_lr_context_unpin(request->previous_context,
> + request->engine);
> }
>
> + i915_gem_context_unreference(request->ctx);
> i915_gem_request_unreference(request);
> }
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
> index 4be11f8d0e04..0682a79be02c 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -771,12 +771,14 @@ intel_logical_ring_advance_and_submit(struct drm_i915_gem_request *request)
> if (intel_engine_stopped(engine))
> return 0;
>
> - if (engine->last_context != request->ctx) {
> - if (engine->last_context)
> - intel_lr_context_unpin(engine->last_context, engine);
> - intel_lr_context_pin(request->ctx, engine);
> - engine->last_context = request->ctx;
> - }
> + /* We keep the previous context alive until we retire the following
> + * request. This ensures that any the context object is still pinned
> + * for any residual writes the HW makes into it on the context switch
> + * into the next object following the breadcrumb. Otherwise, we may
> + * retire the context too early.
> + */
> + request->previous_context = engine->last_context;
> + engine->last_context = request->ctx;
>
> if (dev_priv->guc.execbuf_client)
> i915_guc_submit(dev_priv->guc.execbuf_client, request);
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-04-28 18:15 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-28 8:56 [CI 01/25] drm/i915/fbdev: Call intel_unpin_fb_obj() on release Chris Wilson
2016-04-28 8:56 ` [CI 02/25] drm/i915/overlay: Replace i915_gem_obj_ggtt_offset() with the known flip_addr Chris Wilson
2016-04-28 8:56 ` [CI 03/25] io-mapping: Specify mapping size for io_mapping_map_wc() Chris Wilson
2016-04-28 8:56 ` [CI 04/25] drm/i915: Introduce i915_vm_to_ggtt() Chris Wilson
2016-04-28 8:56 ` [CI 05/25] drm/i915: Move ioremap_wc tracking onto VMA Chris Wilson
2016-04-28 8:56 ` [CI 06/25] drm/i915: Use i915_vma_pin_iomap on the ringbuffer object Chris Wilson
2016-04-28 8:56 ` [CI 07/25] drm/i915: Mark the current context as lost on suspend Chris Wilson
2016-04-28 8:56 ` [CI 08/25] drm/i915: L3 cache remapping is part of context switching Chris Wilson
2016-04-28 8:56 ` [CI 09/25] drm/i915: Consolidate L3 remapping LRI Chris Wilson
2016-04-28 8:56 ` [CI 10/25] drm/i915: Remove early l3-remap Chris Wilson
2016-04-28 8:56 ` [CI 11/25] drm/i915: Rearrange switch_context to load the aliasing ppgtt on first use Chris Wilson
2016-04-28 8:56 ` [CI 12/25] drm/i915: Unify intel_ring_begin() Chris Wilson
2016-04-28 8:56 ` [CI 13/25] drm/i915: Remove the identical implementations of request space reservation Chris Wilson
2016-04-28 14:02 ` Dave Gordon
2016-04-28 14:31 ` Chris Wilson
2016-04-28 14:51 ` Daniel Vetter
2016-04-28 8:56 ` [CI 14/25] drm/i915: Manually unwind after a failed request allocation Chris Wilson
2016-04-28 14:43 ` Dave Gordon
2016-04-28 14:55 ` Chris Wilson
2016-04-28 8:56 ` [CI 15/25] drm/i915: Preallocate enough space for the average request Chris Wilson
2016-04-28 8:56 ` [CI 16/25] drm/i915: Update execlists context descriptor format commentary Chris Wilson
2016-04-28 8:56 ` [CI 17/25] drm/i915: Assign every HW context a unique ID Chris Wilson
2016-04-28 14:55 ` Dave Gordon
2016-04-28 15:32 ` Chris Wilson
2016-04-28 18:08 ` Dave Gordon
2016-04-28 18:35 ` Chris Wilson
2016-04-28 8:56 ` [CI 18/25] drm/i915: Replace the pinned context address with its " Chris Wilson
2016-04-28 15:23 ` Dave Gordon
2016-04-28 8:56 ` [CI 19/25] drm/i915: Refactor execlists default context pinning Chris Wilson
2016-04-28 8:56 ` [CI 20/25] drm/i915: Move the magical deferred context allocation into the request Chris Wilson
2016-04-28 8:56 ` [CI 21/25] drm/i915: Move releasing of the GEM request from free to retire/cancel Chris Wilson
2016-04-28 8:56 ` [CI 22/25] drm/i915: Track the previous pinned context inside the request Chris Wilson
2016-04-28 18:15 ` Dave Gordon [this message]
2016-04-28 18:33 ` Chris Wilson
2016-04-28 8:56 ` [CI 23/25] drm/i915: Store LRC hardware id in " Chris Wilson
2016-04-28 8:56 ` [CI 24/25] drm/i915: Stop tracking execlists retired requests Chris Wilson
2016-04-28 8:56 ` [CI 25/25] drm/i915: Unify GPU resets upon shutdown Chris Wilson
2016-04-28 10:58 ` ✗ Fi.CI.BAT: failure for series starting with [CI,01/25] drm/i915/fbdev: Call intel_unpin_fb_obj() on release Patchwork
2016-04-28 11:21 ` 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=5722533B.8090307@intel.com \
--to=david.s.gordon@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