Quoting Kenneth Graunke (2017-07-05 21:56:54)
> ---
> src/mesa/drivers/dri/i965/brw_bufmgr.c | 15 +++++++++++++--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.c
> b/src/mesa/drivers/dri/i965/brw_bufmgr.c
> index 7756e2b5f6c..46696be3577 100644
> --- a/src/mesa/drivers/dri/i965/brw_bufmgr.c
> +++ b/src/mesa/drivers/dri/i965/brw_bufmgr.c
> @@ -56,6 +56,7 @@
> #ifndef ETIME
> #define ETIME ETIMEDOUT
> #endif
> +#include "common/gen_clflush.h"
> #include "common/gen_debug.h"
> #include "common/gen_device_info.h"
> #include "libdrm_macros.h"
> @@ -698,12 +699,22 @@ brw_bo_map_cpu(struct brw_context *brw, struct brw_bo
> *bo, unsigned flags)
> VG(VALGRIND_FREELIKE_BLOCK(map, 0));
> drm_munmap(map, bo->size);
> }
> + } else if (!bo->cache_coherent) {
> + /* If we're reusing an existing CPU mapping, the CPU caches may
> + * contain stale data from the last time we read from that mapping.
> + * (With the BO cache, it might even be data from a previous buffer!)
> + *
> + * We need to invalidate those cachelines so that we see the latest
> + * contents.
> + */
> + gen_invalidate_range(bo->map_cpu, bo->size);
> }
This leaves us in trouble on the first invocation with MAP_ASYNC, where
we create the cpu mmaping but don't change any of its domains. (Not that
GL allows for READ | UNSYNCRONIZED if my reading of the spec was
correct.) However, if you use
if (!(flags & MAP_ASYNC))
wait_rendering(); /* teach me to use gem_wait! */
if (!bo->cache_coherent)
gen_invalidate_range();
and a set_domain(GTT, 0) on creation that should cover everything.
In the meantime, s/else if (!bo->cache_coherent)/if (!bo->cache_coherent)/
-Chris
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
