[Intel-gfx] [PATCH] drm/i915: "Race-to-idle" on switching to the kernel context

[David Weinehall]

On Wed, Aug 23, 2017 at 04:03:44PM +0100, Chris Wilson wrote:
> Quoting David Weinehall (2017-08-23 15:54:13)
> > On Fri, Aug 18, 2017 at 03:08:15PM +0100, Chris Wilson wrote:
> > > During suspend we want to flush out all active contexts and their
> > > rendering. To do so we queue a request from the kernel's context, once
> > > we know that request is done, we know the GPU is completely idle. To
> > > speed up that switch bump the GPU clocks.
> > > 
> > > Switching to the kernel context prior to idling is also used to enforce
> > > a barrier before changing OA properties, and when evicting active
> > > rendering from the global GTT. All cases where we do want to
> > > race-to-idle.
> > > 
> > > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > > Cc: David Weinehall <david.weinehall at linux.intel.com>
> > 
> > No statistically significant speedup on suspend in our typical
> > benchmark, but that one doesn't take into account systems in load--it
> > suspends from idle, and from the description it seems that this patch
> > would mostly affect systems with load.
> 
> In terms of everything else, I doubt we ever are significantly waiting
> for the GPU upon suspend, the user interface would finish showing its
> "going to suspend" screen before starting the suspend, so its only going
> to be background tasks still rendering to the gpu oblivious of the
> incoming suspend. Rare -- I'm going to squirrel this patch away until we
> have a need for it.

I suspect that the most common use-case for suspend is laptops,
triggered by the user closing the lid; ""going to suspend" screens
are gonna go unseen by most users.

> Thanks for the review and testing, and if you do come across a workload
> which could benefit do let me know. It may well be that userspace isn't
> as smart as I expect...

I think the main reason that I didn't see much improvement in our
benchmarks is the way we measure suspend times; to be able to get
numbers that are comparable night after night we "normalise" the load by
running a non-measured suspend/resume right before the one we actually
measure. This means that by the time we benchmark we have already
performed the flushing that your patch achieves, so the benefits of your
patch wouldn't be visible.

With your patch we get more stable results already on the first run,
so there definitely is a benefit.


Kind regards, David