Re: [PATCH i-g-t v2] pm_rps: Changes in waitboost scenario

[Chris Wilson <chris@chris-wilson.co.uk>]

Quoting Dec, Katarzyna (2017-08-21 09:29:47)
> Thanks for comments.
> Do we need more changes then being drm-master? You wrote something about not being the one client.

If you wanted to be complete you would check master, auth and render.
They are different classes of fd the driver handles, and rps should work
with any. You could say that render is the lowest common denominator and
only test with that -- that's a much better argument that testing with
master alone.

> Is proposed approach for checking boost not good enough? Do you have any suggestions?

Why are we checking for boost? We certainly don't wish to imply that if
you follow this sequence you will be granted max gpu clocks; that's a
policy decision we should not be so eager to be involved in. waitboosting
is to solve a particular issue with slow clock ramp up for benchmarks and
interactivity, of which interactivity is the much more noticeable. We
don't test that, nor do we track the impact it has upon power
consumption.

Basically the test is following the implementation, and not measuring
the behaviour of the system, because that is much harder to get right,
and would almost certainly lead to better integration with interactive
systems (i.e. so that we could apply gpu boosts ad prioritisation more
intelligently than reacting to a stall which is easy to abuse).
Reacting well to benchmarks should be handled by rps itself and not need
a waitboost on throttling. In fact, I am very tempted to remove
waitboosting for the user and only use it for catching up to missed
vblanks. Along with the suggestions on how to improve reclocking for
particular clients/workloads. (Such changes will break the test, because
it is testing what the kernel is doing now, not how we expect the system
to perform.)
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx