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@xxxxxxxxx wrote:
From: Tom O'Rourke <Tom.O'Rourke@xxxxxxxxx>
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.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
