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@xxxxxxxxxxxxxxxxxx> > > Cc: David Weinehall <david.weinehall@xxxxxxxxxxxxxxx> > > 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. 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... -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
