[Intel-gfx] [RFC 00/22] Add support for GuC-based SLPC

[Daniel Vetter]

On Tue, Feb 09, 2016 at 02:08:23PM +0200, Martin Peres wrote:
> On 26/01/16 19:00, Daniel Vetter wrote:
> >On Tue, Jan 26, 2016 at 07:45:42AM -0800, Jesse Barnes wrote:
> >>On 01/22/2016 09:00 AM, Daniel Vetter wrote:
> >>>On Wed, Jan 20, 2016 at 06:26:02PM -0800, tom.orourke at intel.com wrote:
> >>>>From: Tom O'Rourke <Tom.O'Rourke at intel.com>
> >
> >I'd say we need to keep the boost-deboost stuff alive, e.g. by manually
> >telling guc that the we want different limits, then resetting those limits
> >again after the boost is done. Same for fast idling - kernel simply has a
> >better idea if anyone is about to submit more work (we have execbuf hints
> >for specific workloads like libva).
> 
> Since there is soon to be a GPU scheduler, the GuC could get this
> information already, right? Unless you are talking about having mesa signal
> when it starts creating a new batchbuffer and you would like the GPU to
> prepare to ramp-up.

We don't tell the guc when we're stalling for a batch, so no it doesn't
know. The entire desing seems to center around the idea of just aiming for
some average fps, which is silly for spikey workloads. I assuming that
without some other magic we'll still need explicit boosting and
deboosting.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch