Message ID | 20180216043322.22874-2-dhinakaran.pandiyan@intel.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Quoting Dhinakaran Pandiyan (2018-02-16 04:33:19) > From: Rodrigo Vivi <rodrigo.vivi@intel.com> > > So far we are using frontbuffer tracking for everything > and ignoring that PSR has a HW capable HW tracking for many > modern usages of GPU on Core platforms and newer Atom ones. > > One reason for that is that we were trying to keep same > infrastructure in place for VLV/CHV than the rest of platforms. > But also because when this infrastructure was created > the front-buffer-tracking origin wasn't that good and stable > how it is today after Paulo reworked it to attend FBC cases. > > However this PSR implementation without HW tracking died > on gen8LP. And newer platforms are starting to demand more HW > tracking specially with PSR2 cases in mind. > > By disabling and re-enabling PSR totally every time we believe > someone is going to change the front buffer content we don't > allow PSR HW tracking to do this job and specially compromising > the whole idea of PSR2 case where the HW tracking detect only > the damaged area and do a partial screen update. > > So, from now on, on the platforms that has hw_tracking let's > rely more on HW tracking. > > This also is the case in used by other drivers and more validated > by SV teams. So I hope that this will lead us to less misterious > bugs. > > v2: Only do this for platform that actually has hw tracking. > > v3 from DK > Do this only for flips, small gradual changes are better. > > Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> > Cc: Jim Bride <jim.bride@linux.intel.com> > Cc: Vathsala Nagaraju <vathsala.nagaraju@intel.com> > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> > --- > drivers/gpu/drm/i915/i915_drv.h | 1 + > drivers/gpu/drm/i915/intel_drv.h | 3 ++- > drivers/gpu/drm/i915/intel_frontbuffer.c | 2 +- > drivers/gpu/drm/i915/intel_psr.c | 10 +++++++++- > 4 files changed, 13 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h > index 90eca42ab2b8..31aae988d515 100644 > --- a/drivers/gpu/drm/i915/i915_drv.h > +++ b/drivers/gpu/drm/i915/i915_drv.h > @@ -770,6 +770,7 @@ struct i915_psr { > bool y_cord_support; > bool colorimetry_support; > bool alpm; > + bool has_hw_tracking; Time for some bool:1 compaction? > @@ -841,6 +842,9 @@ void intel_psr_invalidate(struct drm_i915_private *dev_priv, > if (!CAN_PSR(dev_priv)) > return; > > + if (dev_priv->psr.has_hw_tracking && origin == ORIGIN_FLIP) > + return; > + > mutex_lock(&dev_priv->psr.lock); > if (!dev_priv->psr.enabled) { > mutex_unlock(&dev_priv->psr.lock); > @@ -881,6 +885,9 @@ void intel_psr_flush(struct drm_i915_private *dev_priv, > if (!CAN_PSR(dev_priv)) > return; > > + if (dev_priv->psr.has_hw_tracking && origin == ORIGIN_FLIP) > + return; > + Much easier for the causal reader to understand :) -Chris
On Fri, 2018-02-16 at 08:54 +0000, Chris Wilson wrote: > Quoting Dhinakaran Pandiyan (2018-02-16 04:33:19) > > From: Rodrigo Vivi <rodrigo.vivi@intel.com> > > > > So far we are using frontbuffer tracking for everything > > and ignoring that PSR has a HW capable HW tracking for many > > modern usages of GPU on Core platforms and newer Atom ones. > > > > One reason for that is that we were trying to keep same > > infrastructure in place for VLV/CHV than the rest of platforms. > > But also because when this infrastructure was created > > the front-buffer-tracking origin wasn't that good and stable > > how it is today after Paulo reworked it to attend FBC cases. > > > > However this PSR implementation without HW tracking died > > on gen8LP. And newer platforms are starting to demand more HW > > tracking specially with PSR2 cases in mind. > > > > By disabling and re-enabling PSR totally every time we believe > > someone is going to change the front buffer content we don't > > allow PSR HW tracking to do this job and specially compromising > > the whole idea of PSR2 case where the HW tracking detect only > > the damaged area and do a partial screen update. > > > > So, from now on, on the platforms that has hw_tracking let's > > rely more on HW tracking. > > > > This also is the case in used by other drivers and more validated > > by SV teams. So I hope that this will lead us to less misterious > > bugs. > > > > v2: Only do this for platform that actually has hw tracking. > > > > v3 from DK > > Do this only for flips, small gradual changes are better. > > > > Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> > > Cc: Jim Bride <jim.bride@linux.intel.com> > > Cc: Vathsala Nagaraju <vathsala.nagaraju@intel.com> > > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> > > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> > > --- > > drivers/gpu/drm/i915/i915_drv.h | 1 + > > drivers/gpu/drm/i915/intel_drv.h | 3 ++- > > drivers/gpu/drm/i915/intel_frontbuffer.c | 2 +- > > drivers/gpu/drm/i915/intel_psr.c | 10 +++++++++- > > 4 files changed, 13 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h > > index 90eca42ab2b8..31aae988d515 100644 > > --- a/drivers/gpu/drm/i915/i915_drv.h > > +++ b/drivers/gpu/drm/i915/i915_drv.h > > @@ -770,6 +770,7 @@ struct i915_psr { > > bool y_cord_support; > > bool colorimetry_support; > > bool alpm; > > + bool has_hw_tracking; > > Time for some bool:1 compaction? Oddly it increases the binary size, so I didn't make this change in the new version I sent out - https://patchwork.freedesktop.org/series/39502/ I also left out Patch 5/5: The mod_timer patch that Andy sent avoids the problem this patch works around. Patch 4/5: frontbuffer flush during prepare_fb() might be necessary to exit PSR early (before we start updating pipe registers) > > > @@ -841,6 +842,9 @@ void intel_psr_invalidate(struct drm_i915_private *dev_priv, > > if (!CAN_PSR(dev_priv)) > > return; > > > > + if (dev_priv->psr.has_hw_tracking && origin == ORIGIN_FLIP) > > + return; > > + > > mutex_lock(&dev_priv->psr.lock); > > if (!dev_priv->psr.enabled) { > > mutex_unlock(&dev_priv->psr.lock); > > @@ -881,6 +885,9 @@ void intel_psr_flush(struct drm_i915_private *dev_priv, > > if (!CAN_PSR(dev_priv)) > > return; > > > > + if (dev_priv->psr.has_hw_tracking && origin == ORIGIN_FLIP) > > + return; > > + > > Much easier for the causal reader to understand :) > -Chris > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 90eca42ab2b8..31aae988d515 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -770,6 +770,7 @@ struct i915_psr { bool y_cord_support; bool colorimetry_support; bool alpm; + bool has_hw_tracking; void (*enable_source)(struct intel_dp *, const struct intel_crtc_state *); diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h index 898064e8bea7..7192045c5149 100644 --- a/drivers/gpu/drm/i915/intel_drv.h +++ b/drivers/gpu/drm/i915/intel_drv.h @@ -1862,7 +1862,8 @@ void intel_psr_enable(struct intel_dp *intel_dp, void intel_psr_disable(struct intel_dp *intel_dp, const struct intel_crtc_state *old_crtc_state); void intel_psr_invalidate(struct drm_i915_private *dev_priv, - unsigned frontbuffer_bits); + unsigned frontbuffer_bits, + enum fb_op_origin origin); void intel_psr_flush(struct drm_i915_private *dev_priv, unsigned frontbuffer_bits, enum fb_op_origin origin); diff --git a/drivers/gpu/drm/i915/intel_frontbuffer.c b/drivers/gpu/drm/i915/intel_frontbuffer.c index fcfc217e754e..efda1af9a5b3 100644 --- a/drivers/gpu/drm/i915/intel_frontbuffer.c +++ b/drivers/gpu/drm/i915/intel_frontbuffer.c @@ -79,7 +79,7 @@ void __intel_fb_obj_invalidate(struct drm_i915_gem_object *obj, spin_unlock(&dev_priv->fb_tracking.lock); } - intel_psr_invalidate(dev_priv, frontbuffer_bits); + intel_psr_invalidate(dev_priv, frontbuffer_bits, origin); intel_edp_drrs_invalidate(dev_priv, frontbuffer_bits); intel_fbc_invalidate(dev_priv, frontbuffer_bits, origin); } diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c index 2ef374f936b9..2a31c7cbdb41 100644 --- a/drivers/gpu/drm/i915/intel_psr.c +++ b/drivers/gpu/drm/i915/intel_psr.c @@ -824,6 +824,7 @@ void intel_psr_single_frame_update(struct drm_i915_private *dev_priv, * intel_psr_invalidate - Invalidade PSR * @dev_priv: i915 device * @frontbuffer_bits: frontbuffer plane tracking bits + * @origin: which operation caused the invalidate * * Since the hardware frontbuffer tracking has gaps we need to integrate * with the software frontbuffer tracking. This function gets called every @@ -833,7 +834,7 @@ void intel_psr_single_frame_update(struct drm_i915_private *dev_priv, * Dirty frontbuffers relevant to PSR are tracked in busy_frontbuffer_bits." */ void intel_psr_invalidate(struct drm_i915_private *dev_priv, - unsigned frontbuffer_bits) + unsigned frontbuffer_bits, enum fb_op_origin origin) { struct drm_crtc *crtc; enum pipe pipe; @@ -841,6 +842,9 @@ void intel_psr_invalidate(struct drm_i915_private *dev_priv, if (!CAN_PSR(dev_priv)) return; + if (dev_priv->psr.has_hw_tracking && origin == ORIGIN_FLIP) + return; + mutex_lock(&dev_priv->psr.lock); if (!dev_priv->psr.enabled) { mutex_unlock(&dev_priv->psr.lock); @@ -881,6 +885,9 @@ void intel_psr_flush(struct drm_i915_private *dev_priv, if (!CAN_PSR(dev_priv)) return; + if (dev_priv->psr.has_hw_tracking && origin == ORIGIN_FLIP) + return; + mutex_lock(&dev_priv->psr.lock); if (!dev_priv->psr.enabled) { mutex_unlock(&dev_priv->psr.lock); @@ -957,6 +964,7 @@ void intel_psr_init(struct drm_i915_private *dev_priv) dev_priv->psr.activate = vlv_psr_activate; dev_priv->psr.setup_vsc = vlv_psr_setup_vsc; } else { + dev_priv->psr.has_hw_tracking = true; dev_priv->psr.enable_source = hsw_psr_enable_source; dev_priv->psr.disable_source = hsw_psr_disable; dev_priv->psr.enable_sink = hsw_psr_enable_sink;