If the user triggers an implicit batch flush while holding access to a
CPU mapped buffer, that mmapping will be invalidated by the kernel for
non-LLC devices. (The kernel when executing a batch will change the
cache domain of the buffers in that batch, which for non-LLC CPU access
will cause that buffer to be clflushed and any further CPU access to be
discarded.) To prevent this, simply disallow any CPU async mmap access.
The cases where async CPU access to a non-LLC buffer should continue to
be allowed via their preferred snooping path.
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Kenneth Graunke <kenn...@whitecape.org>
Cc: Matt Turner <matts...@gmail.com>
---
src/mesa/drivers/dri/i965/brw_bufmgr.c | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.c
b/src/mesa/drivers/dri/i965/brw_bufmgr.c
index 0f6ad07b62..819408c180 100644
--- a/src/mesa/drivers/dri/i965/brw_bufmgr.c
+++ b/src/mesa/drivers/dri/i965/brw_bufmgr.c
@@ -738,10 +738,17 @@ can_map_cpu(struct brw_bo *bo, unsigned flags)
if (bo->cache_coherent)
return true;
- if (flags & MAP_PERSISTENT)
- return false;
-
- if (flags & MAP_COHERENT)
+ /* If PERSISTENT | COHERENT is set, the mmapping needs to remain valid
+ * across batch flushes where the kernel will change cache domains of the
+ * bo, invalidating continued access to the CPU mmap on non-LLC device.
+ *
+ * ASYNC poses a similar problem in that in while the buffer is mapped,
+ * the batch may be implicitly flushed, again invalidating the CPU mmap
+ * for non-LLC devices. (Although it is technically illegal for the user
+ * to trigger a flush whilst they have buffers mapped, it may happen
+ * automatically.)
+ */
+ if (flags & (MAP_PERSISTENT | MAP_COHERENT | MAP_ASYNC))
return false;
return !(flags & MAP_WRITE);
--
2.11.0
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
