[Bug 102199] Kabylake has poor performance, doesn't upclock during activity quickly with single display configurations

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=102199

--- Comment #20 from Ray Strode [halfline] <rstrode at redhat.com> ---
(In reply to Chris Wilson from comment #19)
> There is no way we can predict which of those will result in a requirement
> for low latency output.
Input usually leads to screen updates...  Granted not all screen updates take
longer than a vblank period when the gpu is downclocked... Still, it would
certainly ramp up less often than glFinish before every swap buffer in the
compositor right? 

> You do not want to bake policy into the kernel, 
But isn't everything we're talking about here heuristics (missed vblank, wait
boosting)?

> the other hand if may be a worthwhile experiment for userspace to construct
> that link (i.e. pass a input fd to the gfx that it then watches, and ????)
not sure what you mean by "pass an input fd to the graphics."  certainly if
there was an ioctl "PLEASE BOOST THE CLOCKSPEED OF THE GPU NOW", gnome-shell
could call it before starting big animations, and whenever the user clicked or
typed.

> Realistically that will just result in the GPU always running at max
> frequency, or idling.
why? if the user is watching a video they aren't using the mouse or typing... 
Likewise, if they're reading a webpage, or if they're not using the computer.

But if they're moving the mouse around, they're probably going to click
something. if they click something, it's probably going to fade open or scroll
or whatever.  it seems like that would the right to scale up the clock?

> We may as well just set a flag on the fd (that the
> compositor hands to its clients) that says render-as-fast-as-possible, or
> just switch off reclocking all together.
not following this.

> What we are talking about here is a mechanism to override the workload based
> reclocking of the GPU for a much faster initial ramp (otherwise it uses an
> exponential curve, reclocking every 10-30ms); it's a power-performance
> tradeoff. The gpu can decode a video at minimal clocks, there is no reason
> for that workload to be consuming more power than required. So the key is
> detecting what workload is going to miss a latency deadline and only
> supercharging the gpu for that task.
Sure, this makes sense to me. But do you think there are a lot of rendering
tasks that result directly from user input, that wouldn't benefit from faster
initial ramp?

Thinking about it, I guess an obvious one would be typing a document. hmm. so
that makes me think we shouldn't do it for keyboard events. But of course,
hitting the super key should still open the shell overview fast. hmm.

> Also not everything firefox is doing is urgent, it will be a mix of laying
> out and rendering the page, plus some interactive responses that we want to
> minimise the latency for. How do we identify those different cases?
fair point.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20170818/50b7d00c/attachment.html>