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 --- 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
