The write hazard lies extend also to the cache-dirty tracking; as we purposefully do not tell the kernel we are writing to the bo, it fails to note the CPU cache as dirty and so the gem_read() may not sufficiently flush the caches prior to reading back from the GPU.
Signed-off-by: Chris Wilson <[email protected]> Cc: Antonio Argenziano <[email protected]> --- tests/i915/gem_exec_schedule.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/tests/i915/gem_exec_schedule.c b/tests/i915/gem_exec_schedule.c index 59102b6bc..a9383000a 100644 --- a/tests/i915/gem_exec_schedule.c +++ b/tests/i915/gem_exec_schedule.c @@ -54,7 +54,8 @@ uint32_t __sync_read_u32(int fd, uint32_t handle, uint64_t offset) { uint32_t value; - gem_sync(fd, handle); /* No write hazard lies! */ + gem_set_domain(fd, handle, /* No write hazard lies! */ + I915_GEM_DOMAIN_GTT, I915_GEM_DOMAIN_GTT); gem_read(fd, handle, offset, &value, sizeof(value)); return value; @@ -63,7 +64,8 @@ uint32_t __sync_read_u32(int fd, uint32_t handle, uint64_t offset) static inline void __sync_read_u32_count(int fd, uint32_t handle, uint32_t *dst, uint64_t size) { - gem_sync(fd, handle); /* No write hazard lies! */ + gem_set_domain(fd, handle, /* No write hazard lies! */ + I915_GEM_DOMAIN_GTT, I915_GEM_DOMAIN_GTT); gem_read(fd, handle, 0, dst, size); } -- 2.20.1 _______________________________________________ Intel-gfx mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/intel-gfx
