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? -Daniel > --- > drivers/gpu/drm/i915/i915_gem_execbuffer.c | 8 ++++++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c > index 650ae02484b0..4f97275ba799 100644 > --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c > +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c > @@ -1127,8 +1127,12 @@ i915_gem_execbuffer_move_to_gpu(struct intel_engine_cs *ring, > if (flush_chipset) > i915_gem_chipset_flush(ring->dev); > > - if (flush_domains & I915_GEM_DOMAIN_GTT) > - wmb(); > + /* 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. > + */ > + wmb(); > > /* Unconditionally invalidate gpu caches and ensure that we do flush > * any residual writes from the previous batch. > -- > 2.1.4 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- 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