| Message ID | 1372438472-3233-1-git-send-email-jbarnes@virtuousgeek.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, Jun 28, 2013 at 09:54:32AM -0700, Jesse Barnes wrote: > Coming out of idle is usually due to some sort of user input (swiping a > screen, clicking a button) and often results in some sort of graphical > animation. To prevent stutter for a CPU or GPU intensive animation, > boost the GPU and CPU freq to the maximum to get the first frame out as > quickly as possible. The normal CPU and GPU frequency management code > will take over from there and (hopefully) clock down to save power as > needed if the max frequencies aren't required. > > This could probably be done more cleanly, and possibly without another > uncached read in the execbuf path if we tracked idleness elsewhere. I'm > also unsure about the cpufreq calls; I don't really know if this will do > what I want... Would seem like a good idea to make intel_mark_busy() dtrt and use them. -Chris
On Fri, 28 Jun 2013 19:37:01 +0100 Chris Wilson <chris@chris-wilson.co.uk> wrote: > On Fri, Jun 28, 2013 at 09:54:32AM -0700, Jesse Barnes wrote: > > Coming out of idle is usually due to some sort of user input (swiping a > > screen, clicking a button) and often results in some sort of graphical > > animation. To prevent stutter for a CPU or GPU intensive animation, > > boost the GPU and CPU freq to the maximum to get the first frame out as > > quickly as possible. The normal CPU and GPU frequency management code > > will take over from there and (hopefully) clock down to save power as > > needed if the max frequencies aren't required. > > > > This could probably be done more cleanly, and possibly without another > > uncached read in the execbuf path if we tracked idleness elsewhere. I'm > > also unsure about the cpufreq calls; I don't really know if this will do > > what I want... > > Would seem like a good idea to make intel_mark_busy() dtrt and use them. That'll give us a slightly delayed idle indicator, but it should work ok... Owen, if this patch looks like it'll work for you, I'll update it to use our mark busy/idle stuff and see if we can merge it upstream. Thanks,
On 6/28/2013 11:37 AM, Chris Wilson wrote: > On Fri, Jun 28, 2013 at 09:54:32AM -0700, Jesse Barnes wrote: >> Coming out of idle is usually due to some sort of user input (swiping a >> screen, clicking a button) and often results in some sort of graphical >> animation. To prevent stutter for a CPU or GPU intensive animation, >> boost the GPU and CPU freq to the maximum to get the first frame out as >> quickly as possible. The normal CPU and GPU frequency management code >> will take over from there and (hopefully) clock down to save power as >> needed if the max frequencies aren't required. >> >> This could probably be done more cleanly, and possibly without another >> uncached read in the execbuf path if we tracked idleness elsewhere. I'm >> also unsure about the cpufreq calls; I don't really know if this will do >> what I want... > > Would seem like a good idea to make intel_mark_busy() dtrt and use them. > -Chris > Is there a way to force the GPU always to run at the top speed? (since it might well be the most efficient way to run things due to race-to-halt)
On Fri, 28 Jun 2013 12:10:51 -0700 Arjan van de Ven <arjan@linux.intel.com> wrote: > On 6/28/2013 11:37 AM, Chris Wilson wrote: > > On Fri, Jun 28, 2013 at 09:54:32AM -0700, Jesse Barnes wrote: > >> Coming out of idle is usually due to some sort of user input (swiping a > >> screen, clicking a button) and often results in some sort of graphical > >> animation. To prevent stutter for a CPU or GPU intensive animation, > >> boost the GPU and CPU freq to the maximum to get the first frame out as > >> quickly as possible. The normal CPU and GPU frequency management code > >> will take over from there and (hopefully) clock down to save power as > >> needed if the max frequencies aren't required. > >> > >> This could probably be done more cleanly, and possibly without another > >> uncached read in the execbuf path if we tracked idleness elsewhere. I'm > >> also unsure about the cpufreq calls; I don't really know if this will do > >> what I want... > > > > Would seem like a good idea to make intel_mark_busy() dtrt and use them. > > -Chris > > > > Is there a way to force the GPU always to run at the top speed? > (since it might well be the most efficient way to run things due to race-to-halt) Yeah I posted a patch for that earlier; adds a new i915.enable_turbo param. If disabled, it just always runs at top speed when not in C6.
On Fri, Jun 28, 2013 at 11:40:27AM -0700, Jesse Barnes wrote: > On Fri, 28 Jun 2013 19:37:01 +0100 > Chris Wilson <chris@chris-wilson.co.uk> wrote: > > > On Fri, Jun 28, 2013 at 09:54:32AM -0700, Jesse Barnes wrote: > > > Coming out of idle is usually due to some sort of user input (swiping a > > > screen, clicking a button) and often results in some sort of graphical > > > animation. To prevent stutter for a CPU or GPU intensive animation, > > > boost the GPU and CPU freq to the maximum to get the first frame out as > > > quickly as possible. The normal CPU and GPU frequency management code > > > will take over from there and (hopefully) clock down to save power as > > > needed if the max frequencies aren't required. > > > > > > This could probably be done more cleanly, and possibly without another > > > uncached read in the execbuf path if we tracked idleness elsewhere. I'm > > > also unsure about the cpufreq calls; I don't really know if this will do > > > what I want... > > > > Would seem like a good idea to make intel_mark_busy() dtrt and use them. > > That'll give us a slightly delayed idle indicator, but it should work > ok... > > Owen, if this patch looks like it'll work for you, I'll update it to use > our mark busy/idle stuff and see if we can merge it upstream. I'm in favour of a bit of hystersis, probably because I think this is ultimately a firmware tuning issue. Something that userspace can only provide hints for, and only the hardware can respond fast enough. Nevertheless will try out this pair to see if makes my systems sweat. -Chris
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c index 87a3227..fd4b4cb 100644 --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c @@ -26,6 +26,7 @@ * */ +#include <linux/cpufreq.h> #include <drm/drmP.h> #include <drm/i915_drm.h> #include "i915_drv.h" @@ -1058,6 +1059,29 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data, goto err; } + /* + * Before dispatching, check if the GPU is busy. If not, + * boost the GPU and CPU freqs to maximum to make sure + * animation startup is smooth. + */ + if (intel_gpu_idle(dev)) { + struct cpufreq_policy *policy; + unsigned int cpu = smp_processor_id(); + int cpu_freq; + + mutex_lock(&dev_priv->rps.hw_lock); + if (IS_VALLEYVIEW(dev)) + valleyview_set_rps(dev, dev_priv->rps.max_delay); + else if (IS_GEN6(dev) || IS_GEN7(dev)) + gen6_set_rps(dev, dev_priv->rps.max_delay); + mutex_unlock(&dev_priv->rps.hw_lock); + + policy = cpufreq_cpu_get(cpu); + cpu_freq = cpufreq_quick_get_max(cpu); + + cpufreq_driver_target(policy, cpu_freq, CPUFREQ_RELATION_H); + } + exec_start = batch_obj->gtt_offset + args->batch_start_offset; exec_len = args->batch_len; if (cliprects) { diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h index 6f7f33e..e84176b 100644 --- a/drivers/gpu/drm/i915/intel_drv.h +++ b/drivers/gpu/drm/i915/intel_drv.h @@ -840,4 +840,6 @@ extern bool intel_set_pch_fifo_underrun_reporting(struct drm_device *dev, enum transcoder pch_transcoder, bool enable); +extern bool intel_gpu_idle(struct drm_device *dev); + #endif /* __INTEL_DRV_H__ */ diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index e809c57..7ad2764 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -5621,3 +5621,27 @@ int vlv_freq_opcode(int ddr_freq, int val) return val; } +bool intel_gpu_idle(struct drm_device *dev) +{ + struct drm_i915_private *dev_priv = dev->dev_private; + + if (IS_VALLEYVIEW(dev)) { + u32 gtlc_pw_status; + + gtlc_pw_status = I915_READ(VLV_GTLC_PW_STATUS); + if (gtlc_pw_status & (1<<7)) + return false; + else + return true; + } else if (IS_GEN6(dev) || IS_GEN7(dev)) { + u32 gt_core_status; + + gt_core_status = I915_READ(GEN6_GT_CORE_STATUS); + if (gt_core_status & GEN6_CORE_CPD_STATE_MASK) + return true; + else + return false; + } else { + return false; + } +}
Coming out of idle is usually due to some sort of user input (swiping a screen, clicking a button) and often results in some sort of graphical animation. To prevent stutter for a CPU or GPU intensive animation, boost the GPU and CPU freq to the maximum to get the first frame out as quickly as possible. The normal CPU and GPU frequency management code will take over from there and (hopefully) clock down to save power as needed if the max frequencies aren't required. This could probably be done more cleanly, and possibly without another uncached read in the execbuf path if we tracked idleness elsewhere. I'm also unsure about the cpufreq calls; I don't really know if this will do what I want... Requested-by: Owen Taylor <otaylor@gtk.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 24 ++++++++++++++++++++++++ drivers/gpu/drm/i915/intel_drv.h | 2 ++ drivers/gpu/drm/i915/intel_pm.c | 24 ++++++++++++++++++++++++ 3 files changed, 50 insertions(+)