[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 #19 from Chris Wilson <chris at chris-wilson.co.uk> ---
(In reply to Ray Strode [halfline] from comment #18)
> (In reply to Chris Wilson from comment #17)
> > The gfx driver doesn't have that information. I'm not sure if the kernel
> > knows what is an active hid, and certainly there's no link to it to either
> > the cpu scheduler or to us. 
> I don't understand, the kernel sends input events from
> keyboard/mice/touchscreens to userspace via /dev/input/eventN interface, so
> why couldn't the clock speed get boosted any time an event got posted to one
> of those devices?
> 
> git grep seems to suggest there's a function called input_register_handler()
> that lets various parts of the kernel hook into the event stream for all
> devices (granted this was just 60 seconds of searching, so I may be missing
> something).

There is no way we can predict which of those will result in a requirement for
low latency output. You do not want to bake policy into the kernel, on 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 ????)
Realistically that will just result in the GPU always running at max frequency,
or idling. 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.

> > From our perspective the only way we can
> > identify such streams is by looking at what ends up on the display, and
> > backtracking from there. The piece that pulls all of this together is the
> > compositor.
> But wouldn't it better if we could ramp up the clockspeed before firefox
> started rerendering a page getting drag scrolled, not after the compositor
> is responding to damage requests?
> 
> > Because we are looking for anything that interacts with the user to
> > preferentially give those low latency. We identify these by contexts which
> > are tied to files and processes. On the other hand, we can remove that
> > guesswork if userspace is able to tell us what is high priority and what is
> > not.
> Okay, so it's not just video card in turbo mode or power save mode, but also
> certain GL contexts getting preferential access to the card.  Seems like a
> worthwhile thing to have, I guess, but giving gnome-shell preferential
> access doesn't help firefox rerender faster, right ?

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. The difference is 20+W, and growing with larger and larger
embedded gpus. There is the race-to-idle argument, but if the workload is not
bursty like a compositor, you will be costing too much power by continually
over-estimating the clocks.

There is a reasonable argument that we need to track workloads by context and
reclock based on what contexts are active, rather than the current technique of
just sampling the workload as a single entity on the gpu. That would give us
the ability to remember that every time firefox renders a frame it will need X%
of the gpu and adjust accordingly. Sadly the RPS unit is not part of the
context, otherwise that would be much easier.

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?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee 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/bfac70cb/attachment-0001.html>