Re: [RFC 00/22] Add support for GuC-based SLPC

[Daniel Vetter <daniel@ffwll.ch>]

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@intel.com wrote:
> >> From: Tom O'Rourke <Tom.O'Rourke@intel.com>
> >>
> >> SLPC (Single Loop Power Controller) is a replacement for
> >> some host-based power management features.  The SLPC
> >> implemenation runs in firmware on GuC.
> >>
> >> This series is a first request for comments.  This series
> >> is not expected to be merged.  After changes based on
> >> comments, a later patch series will be sent for merging.
> >>  
> >> This series has been tested with SKL guc firmware
> >> versions 4.3 and 4.7.  The graphics power management
> >> features in SLPC in those versions are DFPS (Dynamic FPS),
> >> Turbo, and DCC (Duty Cycle Control).  DFPS adjusts
> >> requested graphics frequency to maintain target framerate.
> >> Turbo adjusts requested graphics frequency to maintain
> >> target GT busyness.  DCC adjusts requested graphics
> >> frequency and stalls guc-scheduler to maintain actual
> >> graphics frequency in efficient range.
> > 
> > Either it's been forever long ago or I missed that meeting, so I'll drop
> > my big arch concerns here. We probably need to discuss this internally, at
> > least the benchmark data. Two big items:
> > 
> > - How does GuC measure fps rendered to the screen? More specifically, how
> >   does it figure out that we missed a frame and kick the throttle up?
> 
> Yeah, this has been covered before, both in the design review and with
> the GuC team; I don't think the DFPS feature is ready for Linux usage
> yet, or at least not generally, since afaik it doesn't have a way to
> monitor offscreen rendering at all, so may end up keeping the GPU freq
> lower than it needs to be when several clients are rendering to
> offscreen buffers and passing them to the compositor (depending on the
> compositor behavior at least).

There's also all kinds of issues with the current design, like:
- kernel knows when exactly we missed the vblank to display the next
  frame, guc can only control for average fps.

- all the fun you mention about multiple clients.

- what if we have more than 1 display running at different fps?

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).

Of course this assumes that guc slpc actually obeys our new limit requests
fast enough, so we'd still need to benchmark to make sure it's not slower
than what we have.

> > - This patch series seems to remove the limiting abilities, and also
> >   completely no-ops out our boost/deboost features. Can we recover these
> >   features?
> 
> This is a good question; if the GuC handles this it should probably be mentioned somewhere.

Limiting's still intact, spotted the code to set limits using guc in one of
the last patches. The boost-deboost is the big issue imo, also since it
interferes with our won missed-frame logic.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx