When mapping the buffer a second time, we need to use the new pointer, not the one from the previous mapping. Otherwise, we will most likely crash.
Apparently, we've just been getting lucky and getting the same bo->virtual pointer in both cases. libdrm probably has a hand in that. Signed-off-by: Kenneth Graunke <kenn...@whitecape.org> Cc: mesa-sta...@lists.freedesktop.org --- src/mesa/drivers/dri/i965/intel_extensions.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c b/src/mesa/drivers/dri/i965/intel_extensions.c index b04bd8f..bbbb76f 100644 --- a/src/mesa/drivers/dri/i965/intel_extensions.c +++ b/src/mesa/drivers/dri/i965/intel_extensions.c @@ -87,6 +87,7 @@ can_do_pipelined_register_writes(struct brw_context *brw) /* Check whether the value got written. */ drm_intel_bo_map(brw->batch.workaround_bo, false); + data = brw->batch.workaround_bo->virtual; bool success = data[offset] == expected_value; drm_intel_bo_unmap(brw->batch.workaround_bo); @@ -145,6 +146,7 @@ can_write_oacontrol(struct brw_context *brw) /* Check whether the value got written. */ drm_intel_bo_map(brw->batch.workaround_bo, false); + data = brw->batch.workaround_bo->virtual; bool success = data[offset] == expected_value; drm_intel_bo_unmap(brw->batch.workaround_bo); -- 2.1.2 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev