Re: [PATCH 1/2] drm/i915: Simplify flush_cpu_write_domain

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Wed, Jan 21, 2015 at 02:53:48PM +0100, Daniel Vetter wrote:
> We can push down the decision whether to force flushing into the
> implementation since in all places that matter obj->pin_display is
> accurate already. The only place where the optimization really matters
> is the sw_finish_ioctl, and that already checks for obj->pin_display
> on its own.
> 
> I suspect that this was simply an artifact of how
> 
> commit 2c22569bba8af6c2976d5f9479fe54a53a39966b
> Author: Chris Wilson <chris@chris-wilson.co.uk>
> Date:   Fri Aug 9 12:26:45 2013 +0100
> 
>     drm/i915: Update rules for writing through the LLC with the cpu
> 
> evolved - only v2 added the pin_display tracking.
> 
> Note that we still retain the gist of this logic from the above commit
> with the explicit force argument for the low-level clflush function.
> 
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
>  drivers/gpu/drm/i915/i915_gem.c | 14 ++++++--------
>  1 file changed, 6 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index f486555fb4a8..783d1040bf83 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -39,8 +39,7 @@
>  #include <linux/dma-buf.h>
>  
>  static void i915_gem_object_flush_gtt_write_domain(struct drm_i915_gem_object *obj);
> -static void i915_gem_object_flush_cpu_write_domain(struct drm_i915_gem_object *obj,
> -						   bool force);
> +static void i915_gem_object_flush_cpu_write_domain(struct drm_i915_gem_object *obj);
>  static __must_check int
>  i915_gem_object_wait_rendering(struct drm_i915_gem_object *obj,
>  			       bool readonly);
> @@ -1516,7 +1515,7 @@ i915_gem_sw_finish_ioctl(struct drm_device *dev, void *data,
>  
>  	/* Pinned buffers may be scanout, so flush the cache */
>  	if (obj->pin_display)
> -		i915_gem_object_flush_cpu_write_domain(obj, true);
> +		i915_gem_object_flush_cpu_write_domain(obj);
>  
>  	drm_gem_object_unreference(&obj->base);
>  unlock:
> @@ -3680,15 +3679,14 @@ i915_gem_object_flush_gtt_write_domain(struct drm_i915_gem_object *obj)
>  
>  /** Flushes the CPU write domain for the object if it's dirty. */
>  static void
> -i915_gem_object_flush_cpu_write_domain(struct drm_i915_gem_object *obj,
> -				       bool force)
> +i915_gem_object_flush_cpu_write_domain(struct drm_i915_gem_object *obj)
>  {
>  	uint32_t old_write_domain;
>  
>  	if (obj->base.write_domain != I915_GEM_DOMAIN_CPU)
>  		return;
>  
> -	if (i915_gem_clflush_object(obj, force))
> +	if (i915_gem_clflush_object(obj, obj->pin_display))
>  		i915_gem_chipset_flush(obj->base.dev);
>  
>  	old_write_domain = obj->base.write_domain;
> @@ -3735,7 +3733,7 @@ i915_gem_object_set_to_gtt_domain(struct drm_i915_gem_object *obj, bool write)
>  	if (ret)
>  		return ret;
>  
> -	i915_gem_object_flush_cpu_write_domain(obj, false);
> +	i915_gem_object_flush_cpu_write_domain(obj);

This is the only place where there's a slight change in behaviour.
Previosuly we would not clflush here when pin_display==true, but from
now on we will. I had a patch to do only this change (part of some FBC
series), but IIRC you argued it could hide bugs. I guess you've
now changed you mind ;)

Anyway this makes sense to me, so
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

>  
>  	/* Serialise direct access to this object with the barriers for
>  	 * coherent writes from the GPU, by effectively invalidating the
> @@ -3981,7 +3979,7 @@ i915_gem_object_pin_to_display_plane(struct drm_i915_gem_object *obj,
>  	if (ret)
>  		goto err_unpin_display;
>  
> -	i915_gem_object_flush_cpu_write_domain(obj, true);
> +	i915_gem_object_flush_cpu_write_domain(obj);
>  
>  	old_write_domain = obj->base.write_domain;
>  	old_read_domains = obj->base.read_domains;
> -- 
> 2.1.4

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx