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
