Re: [PATCH 1/2] drm/i915: Unconditionally flush any chipset buffers before execbuf

From: Mika Kuoppala <mika.kuoppala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
	Akash Goel <akash.goel@intel.com>,
	stable@vger.kernel.org
Subject: Re: [PATCH 1/2] drm/i915: Unconditionally flush any chipset	buffers before execbuf
Date: Thu, 18 Aug 2016 16:59:35 +0300	[thread overview]
Message-ID: <8760qynpo8.fsf@gaia.fi.intel.com> (raw)
In-Reply-To: <20160818131258.20431-1-chris@chris-wilson.co.uk>

Chris Wilson <chris@chris-wilson.co.uk> writes:

> If userspace is asynchronously streaming into the batch or other
> execobjects, we may not flush those writes along with a change in cache
> domain (as there is no change). Therefore those writes may end up in
> internal chipset buffers and not visible to the GPU upon execution. We
> must issue a flush command or otherwise we encounter incoherency in the
> batchbuffers and the GPU executing invalid commands (i.e. hanging) quite
> regularly.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90841
> Fixes: 1816f9236303 ("drm/i915: Support creation of unbound wc user...")
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Akash Goel <akash.goel@intel.com>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> Tested-by: Matti Hämäläinen <ccr@tnsp.org>
> Cc: stable@vger.kernel.org
> ---
>  drivers/gpu/drm/i915/i915_gem_execbuffer.c | 13 +++----------
>  1 file changed, 3 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index 699315304748..bce587abc601 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -1015,8 +1015,6 @@ i915_gem_execbuffer_move_to_gpu(struct drm_i915_gem_request *req,
>  {
>  	const unsigned int other_rings = eb_other_engines(req);
>  	struct i915_vma *vma;
> -	uint32_t flush_domains = 0;
> -	bool flush_chipset = false;
>  	int ret;
>  
>  	list_for_each_entry(vma, vmas, exec_list) {
> @@ -1029,16 +1027,11 @@ i915_gem_execbuffer_move_to_gpu(struct drm_i915_gem_request *req,
>  		}
>  
>  		if (obj->base.write_domain & I915_GEM_DOMAIN_CPU)
> -			flush_chipset |= i915_gem_clflush_object(obj, false);
> -
> -		flush_domains |= obj->base.write_domain;
> +			i915_gem_clflush_object(obj, false);
>  	}
>  
> -	if (flush_chipset)
> -		i915_gem_chipset_flush(req->engine->i915);
> -
> -	if (flush_domains & I915_GEM_DOMAIN_GTT)
> -		wmb();

Was a bit worried about this vanishing.

But after chatting with Chris and also founding this:
https://lwn.net/Articles/174655/
[in I386 AND X86_64 SPECIFIC NOTES]

I am convinced that the uncached write to force the chipset_flush
will be strong barrier enough.

Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>

> +	/* Unconditionally flush any chipset caches (for streaming writes). */
> +	i915_gem_chipset_flush(req->engine->i915);
>  
>  	/* Unconditionally invalidate GPU caches and TLBs. */
>  	return req->engine->emit_flush(req, EMIT_INVALIDATE);
> -- 
> 2.9.3
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx