Re: [PATCH 03/17] drm/i915/ringbuffer: Fix context restore upon reset

From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 03/17] drm/i915/ringbuffer: Fix context restore upon reset
Date: Mon, 11 Jun 2018 13:28:21 +0300	[thread overview]
Message-ID: <152871290100.1718.3598535879434166387@jlahtine-desk.ger.corp.intel.com> (raw)
In-Reply-To: <20180610194325.13467-4-chris@chris-wilson.co.uk>

Quoting Chris Wilson (2018-06-10 22:43:11)
> The discovery with trying to enable full-ppgtt was that we were
> completely failing to the load both the mm and context following the
> reset. Although we were performing mmio to set the PP_DIR (per-process
> GTT) and CCID (context), these were taking no effect (the assumption was
> that this would trigger reload of the context and restore the page
> tables). It was not until we performed the LRI + MI_SET_CONTEXT in a
> following context switch would anything occur.
> 
> Since we are then required to reset the context image and PP_DIR using
> CS commands, we place those commands into every batch. The hardware
> should recognise the no-ops and eliminate the expensive context loads,
> but we still have to pay the cost of using cross-powerwell register
> writes. In practice, this has no effect on actual context switch times,
> and only adds a few hundred nanoseconds to no-op switches. We can improve
> the latter by eliminating the w/a around known no-op switches, but there
> is an ulterior motive to keeping them.
> 
> Always emitting the context switch at the beginning of the request (and
> relying on HW to skip unneeded switches) does have one key advantage.
> Should we implement request reordering on Haswell, we will not know in
> advance what the previous executing context was on the GPU and so we
> would not be able to elide the MI_SET_CONTEXT commands ourselves and
> always have to emit them. Having our hand forced now actually prepares
> us for later.

Please comment about the destiny of the tracepoint for the sake of the
bisecter that will end up here to look for a lost tracepoint :)

Also, you could throw a Testcase: this affects.

> 
> v2: Sandybridge has to agree to use LRI as well.
> 
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> Cc: Matthew Auld <matthew.william.auld@gmail.com>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

Regards, Joonas
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx