[Intel-gfx] [PATCH 03/18] drm/i915: only nuke FBC when a drawing operation triggers a flush

[Chris Wilson]

On Tue, Oct 20, 2015 at 11:49:49AM -0200, Paulo Zanoni wrote:
> There's no need to stop and restart FBC: a nuke should be fine.
> 
> Signed-off-by: Paulo Zanoni <paulo.r.zanoni at intel.com>
> ---
>  drivers/gpu/drm/i915/intel_fbc.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
> index 9477379..b9cfd16 100644
> --- a/drivers/gpu/drm/i915/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> @@ -1088,8 +1088,10 @@ void intel_fbc_flush(struct drm_i915_private *dev_priv,
>  		if (origin == ORIGIN_FLIP) {
>  			__intel_fbc_update(dev_priv);
>  		} else {
> -			__intel_fbc_disable(dev_priv);
> -			__intel_fbc_update(dev_priv);
> +			if (dev_priv->fbc.enabled)
> +				intel_fbc_nuke(dev_priv);

Ok, what does nuke actually do? From the name, I would expect FBC to be
left in an unusable state.

> +			else
> +				__intel_fbc_update(dev_priv);
>  		}
>  	}

This becomes

if (enabled && origin != ORIGIN_FLIP)
  intel_fbc_nuke();
else
  __intel_fbc_update();

It seems a little odd that anything is done if disabled, so care to
elaborate that reason, and I presume there is an equally good comment
before the context that explains why FLIP is special?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre