[Intel-gfx] [PATCH v2 8/9] drm/i915: Nuke FBC from SW_FINISH ioctl

[Chris Wilson]

On Mon, Nov 25, 2013 at 04:54:48PM +0200, ville.syrjala at linux.intel.com wrote:
> From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> 
> FBC host modification tracking only works through GTT mmaps, so any
> direct CPU access needs to manually nuke the compressed framebuffer
> on modifications. Do the nuking from the SW_FINISH ioctl.
> 
> v2: nuke from SW_FINISH insted of DIRTYFB ioctl
> 
> Signed-off-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
> ---
>  drivers/gpu/drm/i915/i915_gem.c  |  2 ++
>  drivers/gpu/drm/i915/intel_drv.h |  1 +
>  drivers/gpu/drm/i915/intel_pm.c  | 30 ++++++++++++++++++++++++++++++
>  3 files changed, 33 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 40d9dcf..fdd7279 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1309,6 +1309,8 @@ i915_gem_sw_finish_ioctl(struct drm_device *dev, void *data,
>  	if (obj->pin_display)
>  		i915_gem_object_flush_cpu_write_domain(obj, true);
>  
> +	intel_fbc_nuke(obj);

All though it doesn't matter (since intel_fbc_nuke does sufficient
checks itself), it would seem clear to me to put this in the same
if(obj->pin_display) block as the cpu flush.

Notwithstanding that,
Reviewed-by: Chris Wilson <chris at chris-wilson.co.uk>

Do we have any i-g-t to make sure that this path remains correct?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre