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@xxxxxxxx> 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@xxxxxxxxxxxxxxx > > It already was ;-) > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html