[Intel-gfx] [PATCH] drm/i915: Unconditionally flush writes before execbuffer
Daniel Vetter
daniel at ffwll.ch
Thu May 21 08:30:32 PDT 2015
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 at 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 at vger.kernel.org
>
> It already was ;-)
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
More information about the Intel-gfx
mailing list