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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
