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 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.