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 <chris@xxxxxxxxxxxxxxxxxx>
Cc: Antonio Argenziano <antonio.argenziano@xxxxxxxxx>
---
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
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
