On Wednesday 11 March 2015 07:26 PM, Chris Wilson wrote:
On Wed, Mar 11, 2015 at 07:07:12PM +0530, Deepak S wrote:
On Friday 06 March 2015 10:10 PM, Daniel Vetter wrote:
On Thu, Mar 05, 2015 at 09:27:59PM +0530, deepak.s@xxxxxxxxxxxxxxx wrote:
From: Deepak S <deepak.s@xxxxxxxxxxxxxxx>
In normal cases, RC6 promotion timer is 1700us/500us. This will
result in more time spent in C1 state. For more residency in
C6 in case of media workloads, this is changed to 250us.
Not doing this for 3D workloads as too many C6-C0
transition delays can result in performance impact.
v2: Extend GPU busy & idle detection framework for rc6 Promotion
timer changes (Chris)
Signed-off-by: Deepak S <deepak.s@xxxxxxxxxxxxxxx>
I've thougth Chris' idea was to put this into the gen6_rps_boost/idle
functions? You could check from within them I think for whether the vcs is
still busy ... One more comment below.
-Daniel
Hi Daniel,
gen6_rps_boost/idle will be called only for RCS right? Also we get gen6_rps_boost during __wait_request
But we want to program promotion timer when we add request to VCS to apply the value immediately.
It's gen6_rps_busy/gen6_rps_idle. They are called from intel_mark_busy
and intel_mark_idle. It is intel_mark_busy/intel_mark_idle that we want
to extend to cover the VCS case as well. I think if you add a ring
parameter to the functions, we can start specialising per ring and
global state changes. You will then also be in a position to judge what
is the best idle timer (and consider making i915_gem_idle_work_handler
per ring). The goal is simply to evolve the current infrastucture for
idle/busyness handling to cover your use case as well (and hopefully in
the process improving the old/general cases).
-Chris
Thanks Chris. extending intel_mark_busy/intel_mark_idle
makes sense. I will work on adding the change
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
