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, deepa...@linux.intel.com wrote: > >>From: Deepak S <deepa...@linux.intel.com> > >> > >>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 <deepa...@linux.intel.com> > >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 -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
