From 51694072218b5ae84b5d8f98ee2172d7c5d61b31 Mon Sep 17 00:00:00 2001 From: Francisco Jerez Date: Fri, 6 Nov 2015 13:19:56 -0800 Subject: i965/nir/fs: Add comment for no-op memory barrier functions Reviewed-by: Jordan Justen --- src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp index 5d2dd18552a..02b9f5bbc8a 100644 --- a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp +++ b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp @@ -1709,6 +1709,25 @@ fs_visitor::nir_emit_intrinsic(const fs_builder &bld, nir_intrinsic_instr *instr case nir_intrinsic_group_memory_barrier: case nir_intrinsic_memory_barrier_shared: + /* We treat these workgroup-level barriers as no-ops. This should be + * safe at present and as long as: + * + * - Memory access instructions are not subsequently reordered by the + * compiler back-end. + * + * - All threads from a given compute shader workgroup fit within a + * single subslice and therefore talk to the same HDC shared unit + * what supposedly guarantees ordering and coherency between threads + * from the same workgroup. This may change in the future when we + * start splitting workgroups across multiple subslices. + * + * - The context is not in fault-and-stream mode, which could cause + * memory transactions (including to SLM) prior to the barrier to be + * replayed after the barrier if a pagefault occurs. This shouldn't + * be a problem up to and including SKL because fault-and-stream is + * not usable due to hardware issues, but that's likely to change in + * the future. + */ break; case nir_intrinsic_shader_clock: { -- cgit v1.2.3