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

[Martin Peres]

On 10/02/16 09:37, Daniel Vetter wrote:
> On Tue, Feb 09, 2016 at 02:08:23PM +0200, Martin Peres wrote:
>> On 26/01/16 19:00, 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>
>>>
>>> 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).
>>
>> Since there is soon to be a GPU scheduler, the GuC could get this
>> information already, right? Unless you are talking about having mesa signal
>> when it starts creating a new batchbuffer and you would like the GPU to
>> prepare to ramp-up.
>
> We don't tell the guc when we're stalling for a batch, so no it doesn't
> know. The entire desing seems to center around the idea of just aiming for
> some average fps, which is silly for spikey workloads. I assuming that
> without some other magic we'll still need explicit boosting and
> deboosting.

Right, the needs for a desktop environment are not taken into account 
here. I guess this is really because of Android which is likely using 
planes for compositing so the only problem the GuC developers are trying 
to solve is to guarantee 60 FPS while playing games while saving as much 
power as possible.

Also, SKIA (GPU accel for Chrome) uses the GPU very little so I guess it 
is not really helping the browser case in the mind of the GuC developers.

While the SLPC is IMO the right approach for fast reclocking and tying 
power gating, scheduling and power management together, it needs to 
allow the kernel to give hints and it should listen to them!

Battery life should not be optimised at the ms level, but more at the 
second level. This means that spiky loads should be able to use the 
boost frequencies (if allowed to by the kernel) but the GPU should ramp 
down more or less quickly as the task drags on in order to meet the 
average power consumption target.

May I also repeat that all this really have to be bypassable for 
benchmarking, no boost, fixed frequencies as requested by the kernel and 
a counter to report the number of throttling events at the GPU level. 
Without this, the performance team just cannot do its work properly.