[PATCH] drm/i915: Ajdust down threshold in intel_pm.

[PATCH] drm/i915: Ajdust down threshold in intel_pm.

[Stéphane Marchesin]

The up and down thresholds are very asymetric, so it is possible
to have a case where a spike of rendering increases the GPU clock to
the max (because the up threshold is low) and then a simple blinking
cursor is enough to keep the clock at the maximum speed forever
(because the down threshold is high).

Lowering the down threshold allows the GPU clock to go back down even
when there is a blinking cursor on the screen.

Signed-off-by: Stéphane Marchesin <marcheu@chromium.org>
---
 drivers/gpu/drm/i915/intel_pm.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index d0ce2a5..eba882a 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2432,7 +2432,7 @@ void gen6_enable_rps(struct drm_i915_private *dev_priv)
 		   dev_priv->max_delay << 24 |
 		   dev_priv->min_delay << 16);
 	I915_WRITE(GEN6_RP_UP_THRESHOLD, 10000);
-	I915_WRITE(GEN6_RP_DOWN_THRESHOLD, 1000000);
+	I915_WRITE(GEN6_RP_DOWN_THRESHOLD, 100000);
 	I915_WRITE(GEN6_RP_UP_EI, 100000);
 	I915_WRITE(GEN6_RP_DOWN_EI, 5000000);
 	I915_WRITE(GEN6_RP_IDLE_HYSTERSIS, 10);
-- 
1.7.5.3.367.ga9930

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915: Ajdust down threshold in intel_pm.

[Daniel Vetter]

On Tue, Jul 03, 2012 at 02:16:42PM -0700, Stéphane Marchesin wrote:
> The up and down thresholds are very asymetric, so it is possible
> to have a case where a spike of rendering increases the GPU clock to
> the max (because the up threshold is low) and then a simple blinking
> cursor is enough to keep the clock at the maximum speed forever
> (because the down threshold is high).
> 
> Lowering the down threshold allows the GPU clock to go back down even
> when there is a blinking cursor on the screen.
> 
> Signed-off-by: Stéphane Marchesin <marcheu@chromium.org>

I've just merged Eugeni's hsw rc6 patches - those contain newly tuning
variables. Can you maybe try out whether these would have the same effect?
I'd prefer to simple enable these, presuming that the hw guys we've got
them from did some decent tuning ...
-Daniel
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48

Re: [PATCH] drm/i915: Ajdust down threshold in intel_pm.

[Daniel Vetter]

On Wed, Jul 04, 2012 at 09:52:11AM +0200, Daniel Vetter wrote:
> On Tue, Jul 03, 2012 at 02:16:42PM -0700, Stéphane Marchesin wrote:
> > The up and down thresholds are very asymetric, so it is possible
> > to have a case where a spike of rendering increases the GPU clock to
> > the max (because the up threshold is low) and then a simple blinking
> > cursor is enough to keep the clock at the maximum speed forever
> > (because the down threshold is high).
> > 
> > Lowering the down threshold allows the GPU clock to go back down even
> > when there is a blinking cursor on the screen.
> > 
> > Signed-off-by: Stéphane Marchesin <marcheu@chromium.org>
> 
> I've just merged Eugeni's hsw rc6 patches - those contain newly tuning
> variables. Can you maybe try out whether these would have the same effect?
> I'd prefer to simple enable these, presuming that the hw guys we've got
> them from did some decent tuning ...

Ping.

3.6 merge window is approach fast and I think I'd be good to get this in
... Or something similar, based on the hsw ratio between downclock and
upclock limit, but with the slightly bigger thresholds used by ivb/snb for
upclocks maybe?
-Daniel
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48

Re: [PATCH] drm/i915: Ajdust down threshold in intel_pm.

[Stéphane Marchesin]

[-- Attachment #1.1: Type: text/plain, Size: 1850 bytes --]

On Mon, Jul 16, 2012 at 12:50 PM, Daniel Vetter <daniel@ffwll.ch> wrote:

> On Wed, Jul 04, 2012 at 09:52:11AM +0200, Daniel Vetter wrote:
> > On Tue, Jul 03, 2012 at 02:16:42PM -0700, Stéphane Marchesin wrote:
> > > The up and down thresholds are very asymetric, so it is possible
> > > to have a case where a spike of rendering increases the GPU clock to
> > > the max (because the up threshold is low) and then a simple blinking
> > > cursor is enough to keep the clock at the maximum speed forever
> > > (because the down threshold is high).
> > >
> > > Lowering the down threshold allows the GPU clock to go back down even
> > > when there is a blinking cursor on the screen.
> > >
> > > Signed-off-by: Stéphane Marchesin <marcheu@chromium.org>
> >
> > I've just merged Eugeni's hsw rc6 patches - those contain newly tuning
> > variables. Can you maybe try out whether these would have the same
> effect?
> > I'd prefer to simple enable these, presuming that the hw guys we've got
> > them from did some decent tuning ...
>
> Ping.
>
> 3.6 merge window is approach fast and I think I'd be good to get this in
> ... Or something similar, based on the hsw ratio between downclock and
> upclock limit, but with the slightly bigger thresholds used by ivb/snb for
> upclocks maybe?
>

So now that the dust settled, and that we better understand what's going
on, I am sure that those values are not adequate for us (neither the
default SNB/IVB, nor the Haswell ones).

For the record, here is what we set differently for Chrome OS to solve our
issues (we didn't see a performance regression, but we do get a major power
consumption reduction for lighter GPU loads like playing a video and that
blinking cursor):

GEN6_RP_DOWN_TIMEOUT 10000
GEN6_RP_UP_THRESHOLD 0x4000
GEN6_RP_DOWN_THRESHOLD 0x4000

Stéphane

[-- Attachment #1.2: Type: text/html, Size: 2471 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx