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

[O'Rourke, Tom]

On Tue, Jan 26, 2016 at 09:17:51AM -0800, Jesse Barnes wrote:
> On 01/26/2016 09:00 AM, 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>
> >>>>
> >>>> 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?
> 
> Yep; I think a userspace solution with a kernel interface would do a
> better job here (I outlined one a few years ago, but the lazyweb hasn't
> implemented it for me yet).

[TOR:] Patch 14/22 in this series sends display configuration info to SLPC.
If there are multiple displays, SLPC can take that into consideration.
> 
> > 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).

[TOR:] Could those hints be sent to GuC as well?
> > 
> > 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.
> 
> I definitely want to see benchmarking here too.  Maybe the GuC does
> boosting differently, but it may be just as good as what we have for all
> practical purposes.
> 
> Jesse