From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Widawsky Subject: Re: [PATCH] drm/i915: Revert RPS UP_EI value for SandyBridge and IvyBridge Date: Wed, 24 Oct 2012 12:05:35 -0700 Message-ID: <20121024120535.1e89a095@bwidawsk.net> References: <1350830642-10923-1-git-send-email-chris@chris-wilson.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from shiva.chad-versace.us (209-20-75-48.static.cloud-ips.com [209.20.75.48]) by gabe.freedesktop.org (Postfix) with ESMTP id B17F3A08A1 for ; Wed, 24 Oct 2012 12:05:49 -0700 (PDT) In-Reply-To: <1350830642-10923-1-git-send-email-chris@chris-wilson.co.uk> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: Chris Wilson Cc: intel-gfx@lists.freedesktop.org, stable@vger.kernel.org, Daniel Vetter List-Id: intel-gfx@lists.freedesktop.org On Sun, 21 Oct 2012 15:44:02 +0100 Chris Wilson wrote: > Even though we do not use the EI mode for determining when to change GPU > frequencies for RPS, changing this value causes no up interrupts to be > generated whilst an OpenGL client runs. > > Fixes regression from commit 1ee9ae3244c4789f3184c5123f3b2d7e405b3f4c > Author: Daniel Vetter > Date: Wed Aug 15 10:41:45 2012 +0200 > > drm/i915: use hsw rps tuning values everywhere on gen6+ > > Reported-by: Eric Anholt > Signed-off-by: Chris Wilson > Cc: Eric Anholt > Cc: Ben Widawsky > Cc: Daniel Vetter > Cc: stable@vger.kernel.org > --- > drivers/gpu/drm/i915/intel_pm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c > index 81e88c2..15b585e 100644 > --- a/drivers/gpu/drm/i915/intel_pm.c > +++ b/drivers/gpu/drm/i915/intel_pm.c > @@ -2493,7 +2493,7 @@ static void gen6_enable_rps(struct drm_device *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_UP_EI, IS_HASWELL(dev) ? 66000 : 100000); > I915_WRITE(GEN6_RP_DOWN_EI, 350000); > > I915_WRITE(GEN6_RP_IDLE_HYSTERSIS, 10); I've not verified this with interrupts, but simply reading back the current frequency using the sysfs interface. What I've seen running xonotic on Ivybridge is that we do bump the frequency initially, and then stops. Nearing the end of the demo, we again raise the frequency. Note that on my system, both before, and after this patch, I am able to get to the max GPU frequency with the xonotic demo. Specifically, on my IVB which has a range of 350->1100 with an RP1 of 650. I see the following (the demo is roughly 2 minutes) without patch: Within a few seconds we cycle up to 750 Nothing for about 30 seconds very slowly cycle up to 1100 (*just* before the demo ends) demo ends; throttle down to 350 quickly with patch: Within a few seconds we cycle up to 1000 Nothing for about 30 seconds cycle up to 1100 demo ends; throttle down to 350 slowly I think if this fixes someones critical issue, it's great, but unfortunately I do not see the problem the patch claims to fix. Furthermore, none of us can really make sense of why this has the effect that it does, but I believe a lot of that is because the workloads we run (in this case xonotic) are very blackbox. Personally, on this IVB, I think the behavior before the patch is more desirable because it stays near RP1 for a longer period of time, and drops to RP0 quickly (but it's definitely a matter of opinion). -- Ben Widawsky, Intel Open Source Technology Center