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

[Daniel Vetter <daniel@ffwll.ch>]

On Thu, May 21, 2015 at 04:22:55PM +0100, Chris Wilson wrote:
> 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@ffwll.ch>

Yeah, r-b: me also with this one. Jani, can you please exchange the
comment and apply to -fixes?
-Daniel

> > 
> > And I guess also
> > 
> > Cc: stable@vger.kernel.org
> 
> It already was ;-)
> -Chris
> 
> -- 
> Chris Wilson, Intel Open Source Technology Centre

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch