[Intel-gfx] [RFC 00/22] Add support for GuC-based SLPC
tom.orourke at intel.com
Tue Jan 26 17:17:08 PST 2016
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.
More information about the Intel-gfx