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

[Jesse Barnes]

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

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

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