| Message ID | 20180314093748.8541-8-chris@chris-wilson.co.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 3/14/2018 3:07 PM, Chris Wilson wrote: > Valleyview and Cherryview update the GPU frequency via the punit, which > is very expensive as we have to ensure the cores do not sleep during the > comms. But the patch 5 applies this workaround to only VLV. > If we perform frequent RPS evaluations, the frequent punit > requests cause measurable system overhead for little benefit, so > increase the evaluation intervals to reduce the number of times we try > and change frequency. > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > --- > drivers/gpu/drm/i915/intel_pm.c | 13 +++++++++++++ > 1 file changed, 13 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c > index b1a73fc7f3e8..9de7d53aa4d3 100644 > --- a/drivers/gpu/drm/i915/intel_pm.c > +++ b/drivers/gpu/drm/i915/intel_pm.c > @@ -6165,6 +6165,19 @@ static void gen6_set_rps_thresholds(struct drm_i915_private *dev_priv, u8 val) > break; > } > > + if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) { > + /* > + * Baytrail and Braswell control the gpu frequency via the > + * punit, which is very slow and expensive to communicate with, > + * as we synchronously force the package to C0. If we try and > + * update the gpufreq too often we cause measurable system > + * load for little benefit (effectively stealing CPU time for > + * the GPU, negatively impacting overall throughput). > + */ > + ei_up <<= 2; > + ei_down <<= 2; > + } > + > /* When byt can survive without system hang with dynamic > * sw freq adjustments, this restriction can be lifted. > */
Quoting Sagar Arun Kamble (2018-03-15 09:23:25) > > > On 3/14/2018 3:07 PM, Chris Wilson wrote: > > Valleyview and Cherryview update the GPU frequency via the punit, which > > is very expensive as we have to ensure the cores do not sleep during the > > comms. > But the patch 5 applies this workaround to only VLV. Still using an indirect method that uses a RTT, so still true that the punit access is noticeable. -Chris
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index b1a73fc7f3e8..9de7d53aa4d3 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -6165,6 +6165,19 @@ static void gen6_set_rps_thresholds(struct drm_i915_private *dev_priv, u8 val) break; } + if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) { + /* + * Baytrail and Braswell control the gpu frequency via the + * punit, which is very slow and expensive to communicate with, + * as we synchronously force the package to C0. If we try and + * update the gpufreq too often we cause measurable system + * load for little benefit (effectively stealing CPU time for + * the GPU, negatively impacting overall throughput). + */ + ei_up <<= 2; + ei_down <<= 2; + } + /* When byt can survive without system hang with dynamic * sw freq adjustments, this restriction can be lifted. */
Valleyview and Cherryview update the GPU frequency via the punit, which is very expensive as we have to ensure the cores do not sleep during the comms. If we perform frequent RPS evaluations, the frequent punit requests cause measurable system overhead for little benefit, so increase the evaluation intervals to reduce the number of times we try and change frequency. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> --- drivers/gpu/drm/i915/intel_pm.c | 13 +++++++++++++ 1 file changed, 13 insertions(+)