public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Nick Hoath <nicholas.hoath@intel.com>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
	Chris Wilson <chris@chris-wilson.co.uk>,
	"Intel-gfx@lists.freedesktop.org"
	<Intel-gfx@lists.freedesktop.org>,
	"Ursulin, Tvrtko" <tvrtko.ursulin@intel.com>
Subject: Re: [PATCH 3/3] drm/i915: Fix premature LRC unpin in GuC mode
Date: Wed, 20 Jan 2016 14:21:08 +0000	[thread overview]
Message-ID: <569F97D4.8000906@intel.com> (raw)
In-Reply-To: <569F9473.6020300@linux.intel.com>

On 20/01/2016 14:06, Tvrtko Ursulin wrote:
>
> On 20/01/16 13:55, Chris Wilson wrote:
>> On Wed, Jan 20, 2016 at 01:40:57PM +0000, Tvrtko Ursulin wrote:
>>> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>>
>>> In GuC mode LRC pinning lifetime depends exclusively on the
>>> request liftime. Since that is terminated by the seqno update
>>> that opens up a race condition between GPU finishing writing
>>> out the context image and the driver unpinning the LRC.
>>>
>>> To extend the LRC lifetime we will employ a similar approach
>>> to what legacy ringbuffer submission does.
>>>
>>> We will start tracking the last submitted context per engine
>>> and keep it pinned until it is replaced by another one.
>>>
>>> Note that the driver unload path is a bit fragile and could
>>> benefit greatly from efforts to unify the legacy and exec
>>> list submission code paths.
>>>
>>> At the moment i915_gem_context_fini has special casing for the
>>> two which are potentialy not needed, and also depends on
>>> i915_gem_cleanup_ringbuffer running before itself.
>>>
>>> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>> Issue: VIZ-4277
>>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>>> Cc: Nick Hoath <nicholas.hoath@intel.com>
>>> ---
>>> I cannot test this with GuC but it passes BAT with execlists
>>> and some real world smoke tests.
>>> ---
>>>    drivers/gpu/drm/i915/i915_gem_context.c | 4 +++-
>>>    drivers/gpu/drm/i915/intel_lrc.c        | 7 +++++++
>>>    2 files changed, 10 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c b/drivers/gpu/drm/i915/i915_gem_context.c
>>> index c25083c78ba7..0b419e165836 100644
>>> --- a/drivers/gpu/drm/i915/i915_gem_context.c
>>> +++ b/drivers/gpu/drm/i915/i915_gem_context.c
>>> @@ -438,7 +438,9 @@ void i915_gem_context_fini(struct drm_device *dev)
>>>    	for (i = 0; i < I915_NUM_RINGS; i++) {
>>>    		struct intel_engine_cs *ring = &dev_priv->ring[i];
>>>
>>> -		if (ring->last_context)
>>> +		if (ring->last_context && i915.enable_execlists)
>>> +			intel_lr_context_unpin(ring->last_context, ring);
>>> +		else if (ring->last_context)
>>>    			i915_gem_context_unreference(ring->last_context);
>>>
>>>    		ring->default_context = NULL;
>>> diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
>>> index 5c3f57fed916..b8a7e126d6d2 100644
>>> --- a/drivers/gpu/drm/i915/intel_lrc.c
>>> +++ b/drivers/gpu/drm/i915/intel_lrc.c
>>> @@ -918,6 +918,7 @@ int intel_execlists_submission(struct i915_execbuffer_params *params,
>>>    	struct intel_engine_cs  *ring = params->ring;
>>>    	struct drm_i915_private *dev_priv = dev->dev_private;
>>>    	struct intel_ringbuffer *ringbuf = params->ctx->engine[ring->id].ringbuf;
>>> +	struct intel_context    *ctx = params->request->ctx;
>>>    	u64 exec_start;
>>>    	int instp_mode;
>>>    	u32 instp_mask;
>>> @@ -982,6 +983,12 @@ int intel_execlists_submission(struct i915_execbuffer_params *params,
>>>
>>>    	trace_i915_gem_ring_dispatch(params->request, params->dispatch_flags);
>>>
>>> +	if (ring->last_context && ring->last_context != ctx) {
>>> +		intel_lr_context_unpin(ring->last_context, ring);
>>> +		intel_lr_context_pin(ctx, ring);
>>> +		ring->last_context = ctx;
>>> +	}
>>
>> I think this is the wrong location and should be part of submitting the
>> context inside the engine (because intel_execlists_submission should not
>> as it is entirely duplicating the common GEM batch submision code and
>> the unique part is engine->add_request()).
>
> So into engine->emit_request you are saying? That works just as well
> AFAICS, just making sure I understood correctly.

I think it should go in to intel_logical_ring_advance_and_submit. The 
extra pinning is being put in place to cover GPU usage of the pin. It 
should probably therefore go in to the last common place between 
execlists & GUC, as close to hardware submission as possible.

>
>> Note that it should be:
>>
>> if (engine->last_context != request->ctx) {
>> 	if (engine->last_context)
>> 		intel_lr_context_unpin(engine->last_context, engine);
>> 	engine->last_context = request->ctx;
>> 	intel_lr_context_pin(engine->last_context, engine);
>> }
>
> Ooops!
>
> Regards,
>
> Tvrtko
>

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2016-01-20 14:21 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-20 13:40 [PATCH 1/3] drm/i915: Make LRC (un)pinning work on context and engine Tvrtko Ursulin
2016-01-20 13:40 ` [PATCH 2/3] drm/i915: Make LRC pinning own a reference to the context Tvrtko Ursulin
2016-01-20 13:50   ` Chris Wilson
2016-01-20 13:40 ` [PATCH 3/3] drm/i915: Fix premature LRC unpin in GuC mode Tvrtko Ursulin
2016-01-20 13:55   ` Chris Wilson
2016-01-20 14:06     ` Tvrtko Ursulin
2016-01-20 14:18       ` Chris Wilson
2016-01-20 14:50         ` [PATCH v2] " Tvrtko Ursulin
2016-01-20 15:18           ` Chris Wilson
2016-01-20 14:21       ` Nick Hoath [this message]
2016-01-20 13:55 ` [PATCH 1/3] drm/i915: Make LRC (un)pinning work on context and engine Chris Wilson
2016-01-20 14:50 ` ✓ Fi.CI.BAT: success for series starting with [1/3] " 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=569F97D4.8000906@intel.com \
    --to=nicholas.hoath@intel.com \
    --cc=Intel-gfx@lists.freedesktop.org \
    --cc=chris@chris-wilson.co.uk \
    --cc=tvrtko.ursulin@intel.com \
    --cc=tvrtko.ursulin@linux.intel.com \
    /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