[Intel-gfx] [PATCH] drm/i915: Unconditionally flush writes before execbuffer

[Chris Wilson]

On Thu, May 21, 2015 at 04:21:46PM +0200, Daniel Vetter wrote:
> Hm right. What about emphasising this a bit more in the comment:
> 
> 	/*
> 	 * Empirical evidence indicates that we need a write barrier to
> 	 * make sure write-combined writes (both to the gtt, but also to
> 	 * the cpu mmaps). But userspace also uses wc mmaps as
> 	 * unsynchronized upload paths where it inform the kernel about
> 	 * domain changes (to avoid the stalls). Hence we must do this
> 	 * barrier unconditinally.
> 	 */

For reference the wording in the commit is:

/* Unconditionally flush out writes to memory as the user may be
 * doing asynchronous streaming writes to active buffers (i.e.
 * lazy domain management to avoid serialisation) directly into
 * the physical pages and so not naturally serialised by the GTT.
 */

> Mostly just rewording, unsing unsynchronized as used by gl/libdrm and
> clarification why we need to have the barrier unconditionally. With that

Hmm, glMapBufferRange does use unsynchronized, but async is almost
universally preferred when talking about io and runqueues.

/* Unconditionally flush out writes to memory as the user may be
 * doing asynchronous streaming writes to active buffers in this
 * batch (i.e. lazy domain management to avoid serialisation, for
 * example with glMapBufferRange(GL_MAP_UNSYNCHRONIZED_BIT)) directly
 * into the physical pages and so not naturally serialised by the GTT.
 */

> Reviewed-by: Daniel Vetter <daniel.vetter at ffwll.ch>
> 
> And I guess also
> 
> Cc: stable at vger.kernel.org

It already was ;-)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre