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> > > And I guess also > > Cc: stable@xxxxxxxxxxxxxxx It already was ;-) -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
