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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxxx>
> Cc: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx>
> Cc: Mika Kuoppala <mika.kuoppala@xxxxxxxxxxxxxxx>
> Cc: Matthew Auld <matthew.william.auld@xxxxxxxxx>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>

Reviewed-by: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx>

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




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux