On Tue, May 19, 2015 at 03:41:48PM +0100, Chris Wilson wrote: > On Mon, May 11, 2015 at 04:25:52PM +0100, Chris Wilson wrote: > > On Mon, May 11, 2015 at 12:34:37PM +0200, Daniel Vetter wrote: > > > On Mon, May 11, 2015 at 08:51:36AM +0100, Chris Wilson wrote: > > > > With the advent of mmap(wc), we have a path to write directly into > > > > active GPU buffers. When combined with async updates (i.e. avoiding the > > > > explicit domain management along with the memory barriers and GPU > > > > stalls) we start to see the GPU read the wrong values from memory - i.e. > > > > we have insufficient memory barriers along the execbuffer path. Writes > > > > through the GTT should have been naturally serialised with execution > > > > through the GTT as well and so the impact only seems to be from the WC > > > > paths. > > > > > > > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > > > Cc: Akash Goel <akash.goel@xxxxxxxxx> > > > > Cc: stable@xxxxxxxxxxxxxxx > > > > > > Do we have a nasty igt for this? Bugzilla? > > > > I've added igt/gem_streaming_writes. > > > > That wmb() is not enough for !llc. Since the wmb() made piglit happy it > > is quite possible I haven't hit the same path exactly, but it's going to > > take some investigation to see if igt/gem_streaming_writes can possibly > > work on !llc. > > Humbug. > > Found the bug in gem_streaming_writes, even though I still think the > wmb() is strictly required, it runs fine without (presumably I haven't > managed to avoid all barriers in the execbuffer path yet). However, I > think can improve the stress by inserting extra gpu load -- that should > help make the CPU writes / GPU reads of the buffer concurrent? Just a small update. I haven't found a way to reproduce this in igt yet, but I can still observe the effect using vbo-map-unsync and the fix there is the above patch to make the wmb() unconditional. We need to put this into stable@ reasonably quickly (I suspect some of the 4.0 mmap(wc) regressions are due to this as well). -Chris -- Chris Wilson, Intel Open Source Technology Centre -- 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