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

Reply via email to