2015-07-30 20:37 GMT-03:00 Rodrigo Vivi <rodrigo.vivi@xxxxxxxxx>: > > > On Tue, Jul 14, 2015 at 12:30 PM Paulo Zanoni <przanoni@xxxxxxxxx> wrote: >> >> From: Paulo Zanoni <paulo.r.zanoni@xxxxxxxxx> >> >> Due to the way busy_bits was handled, we were not doing any flushes if >> we didn't previously get an invalidate. Since it's possible to get >> flushes without an invalidate first, remove the busy_bits early >> return. >> >> So now that we don't have the busy_bits guard anymore we'll need the >> origin check for the GTT tracking (we were not doing anything on GTT >> flushes due to the GTT check at invalidate()). >> >> As a last detail, since we can get multiple consecutive flushes, >> disable FBC before updating it, otherwise intel_fbc_update() will just >> keep FBC enabled instead of restarting it. >> >> Notice that this does not fix any of the current IGT tests due to the >> fact that we still have a few intel_fbc() calls at points where we >> also have the frontbuffer tracking calls: we didn't fully convert to >> frontbuffer tracking yet. Once we remove those calls and start relying >> only on the frontbuffer tracking infrastructure we'll need this patch. >> >> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@xxxxxxxxx> >> --- >> drivers/gpu/drm/i915/intel_drv.h | 2 +- >> drivers/gpu/drm/i915/intel_fbc.c | 13 +++++++------ >> drivers/gpu/drm/i915/intel_frontbuffer.c | 2 +- >> 3 files changed, 9 insertions(+), 8 deletions(-) >> >> diff --git a/drivers/gpu/drm/i915/intel_drv.h >> b/drivers/gpu/drm/i915/intel_drv.h >> index f4abce1..2437666 100644 >> --- a/drivers/gpu/drm/i915/intel_drv.h >> +++ b/drivers/gpu/drm/i915/intel_drv.h >> @@ -1240,7 +1240,7 @@ void intel_fbc_invalidate(struct drm_i915_private >> *dev_priv, >> unsigned int frontbuffer_bits, >> enum fb_op_origin origin); >> void intel_fbc_flush(struct drm_i915_private *dev_priv, >> - unsigned int frontbuffer_bits); >> + unsigned int frontbuffer_bits, enum fb_op_origin >> origin); >> const char *intel_no_fbc_reason_str(enum no_fbc_reason reason); >> void intel_fbc_cleanup_cfb(struct drm_i915_private *dev_priv); >> >> diff --git a/drivers/gpu/drm/i915/intel_fbc.c >> b/drivers/gpu/drm/i915/intel_fbc.c >> index c271af7..1f97fb5 100644 >> --- a/drivers/gpu/drm/i915/intel_fbc.c >> +++ b/drivers/gpu/drm/i915/intel_fbc.c >> @@ -884,22 +884,23 @@ void intel_fbc_invalidate(struct drm_i915_private >> *dev_priv, >> } >> >> void intel_fbc_flush(struct drm_i915_private *dev_priv, >> - unsigned int frontbuffer_bits) >> + unsigned int frontbuffer_bits, enum fb_op_origin >> origin) >> { >> if (!dev_priv->fbc.enable_fbc) >> return; >> >> - mutex_lock(&dev_priv->fbc.lock); >> + if (origin == ORIGIN_GTT) >> + return; >> >> - if (!dev_priv->fbc.busy_bits) >> - goto out; >> + mutex_lock(&dev_priv->fbc.lock); >> >> dev_priv->fbc.busy_bits &= ~frontbuffer_bits; >> >> - if (!dev_priv->fbc.busy_bits) >> + if (!dev_priv->fbc.busy_bits) { >> + __intel_fbc_disable(dev_priv); >> __intel_fbc_update(dev_priv); > > > are we going to kill fbc_update for good? ;) It is part of the long term plan, but it requires many other changes first, so I'm focusing on the bugs here. > > But yes, we need to force the disable on flush so this is good. > I'd just add in a separated patch, but anyway feel free to use > > Reviewed-by: Rodrigo Vivi <rodrigo.vivi@xxxxxxxxx> > >> >> + } >> >> -out: >> mutex_unlock(&dev_priv->fbc.lock); >> } >> >> diff --git a/drivers/gpu/drm/i915/intel_frontbuffer.c >> b/drivers/gpu/drm/i915/intel_frontbuffer.c >> index 777b1d3..ac85357 100644 >> --- a/drivers/gpu/drm/i915/intel_frontbuffer.c >> +++ b/drivers/gpu/drm/i915/intel_frontbuffer.c >> @@ -129,7 +129,7 @@ static void intel_frontbuffer_flush(struct drm_device >> *dev, >> >> intel_edp_drrs_flush(dev, frontbuffer_bits); >> intel_psr_flush(dev, frontbuffer_bits, origin); >> - intel_fbc_flush(dev_priv, frontbuffer_bits); >> + intel_fbc_flush(dev_priv, frontbuffer_bits, origin); >> } >> >> /** >> -- >> 2.1.4 >> >> _______________________________________________ >> Intel-gfx mailing list >> Intel-gfx@xxxxxxxxxxxxxxxxxxxxx >> http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Paulo Zanoni _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx