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

Jesse Barnes jbarnes at virtuousgeek.org
Tue Jan 26 07:45:42 PST 2016


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

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

Jesse


More information about the Intel-gfx mailing list