[Intel-gfx] [PATCH v2] drm/i915: Modifying RC6 Promotion timer for Media workloads.
Deepak S
deepak.s at linux.intel.com
Wed Mar 11 06:59:48 PDT 2015
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 at linux.intel.com wrote:
>>>> From: Deepak S <deepak.s at 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 <deepak.s at 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
>
Thanks Chris. extending intel_mark_busy/intel_mark_idle
makes sense. I will work on adding the change
More information about the Intel-gfx
mailing list