[Intel-gfx] [PATCH] drm/i915: Boost GPU clocks if we miss the pageflip's vblank

[Chris Wilson]

Quoting Chris Wilson (2017-08-18 10:30:47)
> Quoting Chris Wilson (2017-08-17 13:37:06)
> > If we miss the current vblank because the gpu was busy, that may cause a
> > jitter as the frame rate temporarily drops. We try to limit the impact
> > of this by then boosting the GPU clock to deliver the frame as quickly
> > as possible. Originally done in commit 6ad790c0f5ac ("drm/i915: Boost GPU
> > frequency if we detect outstanding pageflips") but was never forward
> > ported to atomic and finally dropped in commit fd3a40242e87 ("drm/i915:
> > Rip out legacy page_flip completion/irq handling").
> 
> +One of the most typical use-cases for this is a mostly idle desktop.
> Rendering one frame of the desktop's frontbuffer can easily be
> accomplished by the GPU running at low frequency, but often exceeds
> the time budget of the desktop compositor. The result is that animations
> such as opening the menu, doing a fullscreen switch, or even just trying
> to move a window around are slow and jerky. We need to respond within a
> frame to give the best impression of a smooth UX, as a compromise we
> instead respond if that first frame misses its goal. The result should
> be a near-imperceivable initial delay and a smooth animation even
> starting from idle. The cost, as ever, is that we spend more power than
> is strictly necessary as we overestimate the required GPU frequency and
> then try to ramp down.

Of course the first thing the display wants it be able to preemptively
boost! Now given that this basically tieing prio=DISPLAY to an always
boosted context, should we extend that grant to prio=MAX_USER. That is
all batches sent by the highest user context are executed at high GPU
clocks?

EGL only offsets low/normal/high priority contexts, so we would have to
give that grant to all high priority GL contexts -- the restriction
being that to get a high priority context at all, you have to be
CAP_SYS_NICE.

Vk is more flexible in that regard and will offer more priority values.

CL I'm not sure about.

A slightly softer idea is that it is a context-param in addition to
priority (to boost or not to boost that is the boolean), but still
always set by GL for its high priority contexts. Or we add a new EGL
extension.
-Chris