Re: [Intel-gfx] [PATCH] drm/i915: use hsw rps tuning values everywhere on gen6+
On Wed, Aug 15, 2012 at 10:41:45AM +0200, Daniel Vetter wrote: James Bottomley reported [1] a massive power regression, due to the enabling of semaphores by default in 3.5. A workaround for him is to again disable semaphores. And indeed, his system has a very hard time to entre rc6 with semaphores enabled. Ben Widawsky run around with a kill-a-watt a lot and noticed: - There are indeed a few rare systems that seem to have a hard time entering rc6 when desktop-idle. - One machine, The Indestructible Toshiba regressed in this behaviour between 3.5 and 3.6 in a merge commit! So rc6 behaviour with the current setting seems to be highly timing dependent and not robust at all. - The behaviour James reported wrt semaphores seems to be a freak timing thing that only happens on his specific machine, confirming that enabling semaphores shouldn't reduce rc6 residency. Now furthermore the Google ChromeOS guys reported [2] a while ago that at least on some machines a simply a blinking cursor can keep the gpu turbo at the highest frequency. This is because the current rps limits used on snb/ivb are highly asymmetric. On the theory that gpu turbo and rc6 tuning values are related, we've tried whether the much saner looking (since much less asymmetric) rps tuning values used for hsw would also help entering rc6 more robustly. And it seems to work. Reference[1]: http://lists.freedesktop.org/archives/dri-devel/2012-July/025675.html Reference[2]: http://lists.freedesktop.org/archives/intel-gfx/2012-July/018692.html Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=53393 Tested-by: Ben Widawsky b...@bwidawsk.net Cc: sta...@vger.kernel.org Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch Ok, I've merged this one here, making the commit message a bit more cautious. Unfortnately we don't seem to have the understanding (nor the resources to gain it) of the hw to do better than copypaste what we get from the hw team :( -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: use hsw rps tuning values everywhere on gen6+
James Bottomley reported [1] a massive power regression, due to the
enabling of semaphores by default in 3.5. A workaround for him is to
again disable semaphores. And indeed, his system has a very hard time
to entre rc6 with semaphores enabled.
Ben Widawsky run around with a kill-a-watt a lot and noticed:
- There are indeed a few rare systems that seem to have a hard time
entering rc6 when desktop-idle.
- One machine, The Indestructible Toshiba regressed in this behaviour
between 3.5 and 3.6 in a merge commit! So rc6 behaviour with the
current setting seems to be highly timing dependent and not robust
at all.
- The behaviour James reported wrt semaphores seems to be a freak
timing thing that only happens on his specific machine, confirming
that enabling semaphores shouldn't reduce rc6 residency.
Now furthermore the Google ChromeOS guys reported [2] a while ago that
at least on some machines a simply a blinking cursor can keep the gpu
turbo at the highest frequency. This is because the current rps limits
used on snb/ivb are highly asymmetric.
On the theory that gpu turbo and rc6 tuning values are related, we've
tried whether the much saner looking (since much less asymmetric) rps
tuning values used for hsw would also help entering rc6 more robustly.
And it seems to work.
v2: Testing on James Bottemly's funky machine indicates that the
Haswell values are not aggressive enough. And testing from the Google
ChromeOS team indicates that we actually want symmetric values for the
most power savings. So let's try that.
Reference[1]:
http://lists.freedesktop.org/archives/dri-devel/2012-July/025675.html
Reference[2]:
http://lists.freedesktop.org/archives/intel-gfx/2012-July/018692.html
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=53393
Tested-by: Ben Widawsky b...@bwidawsk.net
Cc: sta...@vger.kernel.org
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_pm.c | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 58c07cd..314da5c 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2441,17 +2441,10 @@ static void gen6_enable_rps(struct drm_device *dev)
dev_priv-max_delay 24 |
dev_priv-min_delay 16);
- if (IS_HASWELL(dev)) {
- I915_WRITE(GEN6_RP_UP_THRESHOLD, 59400);
- I915_WRITE(GEN6_RP_DOWN_THRESHOLD, 245000);
- I915_WRITE(GEN6_RP_UP_EI, 66000);
- I915_WRITE(GEN6_RP_DOWN_EI, 35);
- } else {
- I915_WRITE(GEN6_RP_UP_THRESHOLD, 1);
- I915_WRITE(GEN6_RP_DOWN_THRESHOLD, 100);
- I915_WRITE(GEN6_RP_UP_EI, 10);
- I915_WRITE(GEN6_RP_DOWN_EI, 500);
- }
+ I915_WRITE(GEN6_RP_UP_THRESHOLD, 59400);
+ I915_WRITE(GEN6_RP_DOWN_THRESHOLD, 59400);
+ I915_WRITE(GEN6_RP_UP_EI, 66000);
+ I915_WRITE(GEN6_RP_DOWN_EI, 35);
I915_WRITE(GEN6_RP_IDLE_HYSTERSIS, 10);
I915_WRITE(GEN6_RP_CONTROL,
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: use hsw rps tuning values everywhere on gen6+
James Bottomley reported [1] a massive power regression, due to the
enabling of semaphores by default in 3.5. A workaround for him is to
again disable semaphores. And indeed, his system has a very hard time
to entre rc6 with semaphores enabled.
Ben Widawsky run around with a kill-a-watt a lot and noticed:
- There are indeed a few rare systems that seem to have a hard time
entering rc6 when desktop-idle.
- One machine, The Indestructible Toshiba regressed in this behaviour
between 3.5 and 3.6 in a merge commit! So rc6 behaviour with the
current setting seems to be highly timing dependent and not robust
at all.
- The behaviour James reported wrt semaphores seems to be a freak
timing thing that only happens on his specific machine, confirming
that enabling semaphores shouldn't reduce rc6 residency.
Now furthermore the Google ChromeOS guys reported [2] a while ago that
at least on some machines a simply a blinking cursor can keep the gpu
turbo at the highest frequency. This is because the current rps limits
used on snb/ivb are highly asymmetric.
On the theory that gpu turbo and rc6 tuning values are related, we've
tried whether the much saner looking (since much less asymmetric) rps
tuning values used for hsw would also help entering rc6 more robustly.
And it seems to work.
Reference[1]:
http://lists.freedesktop.org/archives/dri-devel/2012-July/025675.html
Reference[2]:
http://lists.freedesktop.org/archives/intel-gfx/2012-July/018692.html
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=53393
Tested-by: Ben Widawsky b...@bwidawsk.net
Cc: sta...@vger.kernel.org
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_pm.c | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index d64dffb..cf10a1d 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2482,17 +2482,10 @@ static void gen6_enable_rps(struct drm_device *dev)
dev_priv-rps.max_delay 24 |
dev_priv-rps.min_delay 16);
- if (IS_HASWELL(dev)) {
- I915_WRITE(GEN6_RP_UP_THRESHOLD, 59400);
- I915_WRITE(GEN6_RP_DOWN_THRESHOLD, 245000);
- I915_WRITE(GEN6_RP_UP_EI, 66000);
- I915_WRITE(GEN6_RP_DOWN_EI, 35);
- } else {
- I915_WRITE(GEN6_RP_UP_THRESHOLD, 1);
- I915_WRITE(GEN6_RP_DOWN_THRESHOLD, 100);
- I915_WRITE(GEN6_RP_UP_EI, 10);
- I915_WRITE(GEN6_RP_DOWN_EI, 500);
- }
+ I915_WRITE(GEN6_RP_UP_THRESHOLD, 59400);
+ I915_WRITE(GEN6_RP_DOWN_THRESHOLD, 245000);
+ I915_WRITE(GEN6_RP_UP_EI, 66000);
+ I915_WRITE(GEN6_RP_DOWN_EI, 35);
I915_WRITE(GEN6_RP_IDLE_HYSTERSIS, 10);
I915_WRITE(GEN6_RP_CONTROL,
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: use hsw rps tuning values everywhere on gen6+
Am Mittwoch, den 15.08.2012, 10:41 +0200 schrieb Daniel Vetter:
James Bottomley reported [1] a massive power regression, due to the
enabling of semaphores by default in 3.5. A workaround for him is to
again disable semaphores. And indeed, his system has a very hard time
to entre rc6 with semaphores enabled.
s,entre,enter,
Ben Widawsky run around with a kill-a-watt a lot and noticed:
- There are indeed a few rare systems that seem to have a hard time
entering rc6 when desktop-idle.
- One machine, The Indestructible Toshiba regressed in this behaviour
Never heard that Toshiba name.
between 3.5 and 3.6 in a merge commit! So rc6 behaviour with the
current setting seems to be highly timing dependent and not robust
at all.
- The behaviour James reported wrt semaphores seems to be a freak
timing thing that only happens on his specific machine, confirming
that enabling semaphores shouldn't reduce rc6 residency.
Now furthermore the Google ChromeOS guys reported [2] a while ago that
at least on some machines a simply a blinking cursor can keep the gpu
turbo at the highest frequency. This is because the current rps limits
used on snb/ivb are highly asymmetric.
On the theory that gpu turbo and rc6 tuning values are related, we've
tried whether the much saner looking (since much less asymmetric) rps
tuning values used for hsw would also help entering rc6 more robustly.
And it seems to work.
Reference[1]:
http://lists.freedesktop.org/archives/dri-devel/2012-July/025675.html
Reference[2]:
http://lists.freedesktop.org/archives/intel-gfx/2012-July/018692.html
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=53393
Tested-by: Ben Widawsky b...@bwidawsk.net
Did James already confirm, that this fixes his problem?
Cc: sta...@vger.kernel.org
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_pm.c | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index d64dffb..cf10a1d 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2482,17 +2482,10 @@ static void gen6_enable_rps(struct drm_device *dev)
dev_priv-rps.max_delay 24 |
dev_priv-rps.min_delay 16);
- if (IS_HASWELL(dev)) {
- I915_WRITE(GEN6_RP_UP_THRESHOLD, 59400);
- I915_WRITE(GEN6_RP_DOWN_THRESHOLD, 245000);
- I915_WRITE(GEN6_RP_UP_EI, 66000);
- I915_WRITE(GEN6_RP_DOWN_EI, 35);
- } else {
- I915_WRITE(GEN6_RP_UP_THRESHOLD, 1);
- I915_WRITE(GEN6_RP_DOWN_THRESHOLD, 100);
- I915_WRITE(GEN6_RP_UP_EI, 10);
- I915_WRITE(GEN6_RP_DOWN_EI, 500);
- }
+ I915_WRITE(GEN6_RP_UP_THRESHOLD, 59400);
+ I915_WRITE(GEN6_RP_DOWN_THRESHOLD, 245000);
+ I915_WRITE(GEN6_RP_UP_EI, 66000);
+ I915_WRITE(GEN6_RP_DOWN_EI, 35);
I915_WRITE(GEN6_RP_IDLE_HYSTERSIS, 10);
I915_WRITE(GEN6_RP_CONTROL,
Acked-by: Paul Menzel paulepan...@users.sourceforge.net
Thanks,
Paul
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: use hsw rps tuning values everywhere on gen6+
On Wed, Aug 15, 2012 at 03:36:34PM +0100, James Bottomley wrote: On Wed, 2012-08-15 at 16:05 +0200, Paul Menzel wrote: Am Mittwoch, den 15.08.2012, 10:41 +0200 schrieb Daniel Vetter: between 3.5 and 3.6 in a merge commit! So rc6 behaviour with the current setting seems to be highly timing dependent and not robust at all. - The behaviour James reported wrt semaphores seems to be a freak timing thing that only happens on his specific machine, confirming that enabling semaphores shouldn't reduce rc6 residency. Now furthermore the Google ChromeOS guys reported [2] a while ago that at least on some machines a simply a blinking cursor can keep the gpu turbo at the highest frequency. This is because the current rps limits used on snb/ivb are highly asymmetric. On the theory that gpu turbo and rc6 tuning values are related, we've tried whether the much saner looking (since much less asymmetric) rps tuning values used for hsw would also help entering rc6 more robustly. And it seems to work. Reference[1]: http://lists.freedesktop.org/archives/dri-devel/2012-July/025675.html Reference[2]: http://lists.freedesktop.org/archives/intel-gfx/2012-July/018692.html Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=53393 Tested-by: Ben Widawsky b...@bwidawsk.net Did James already confirm, that this fixes his problem? Well, no ... I think no-one cc'd me on anything after the initial bug report, but the patch won't apply to 3.5, so cc stable isn't really going to work ... it will need backporting. I can test either the backport or 3.6-rc1 with the patch if there's interest. Sorry, the cc: you got lost, testing feedback highly welcome. The ChromeOS guys just reported back that for them fully symmetric values actually lead to the least power consumption for light gpu loads (which these are not yet), so maybe we need to tune things some more even. Thanks, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
