Jason Ekstrand <ja...@jlekstrand.net> writes: > --- > src/intel/compiler/brw_shader.cpp | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/src/intel/compiler/brw_shader.cpp > b/src/intel/compiler/brw_shader.cpp > index 34b8f3acf93..5cb91e0dce9 100644 > --- a/src/intel/compiler/brw_shader.cpp > +++ b/src/intel/compiler/brw_shader.cpp > @@ -1007,6 +1007,18 @@ backend_instruction::has_side_effects() const > case SHADER_OPCODE_SEND: > return send_has_side_effects; > > + case SHADER_OPCODE_TYPED_SURFACE_READ: > + case SHADER_OPCODE_TYPED_SURFACE_READ_LOGICAL: > + case SHADER_OPCODE_UNTYPED_SURFACE_READ: > + case SHADER_OPCODE_UNTYPED_SURFACE_READ_LOGICAL: > + case SHADER_OPCODE_BYTE_SCATTERED_READ: > + case SHADER_OPCODE_BYTE_SCATTERED_READ_LOGICAL: > + /* The back-end compilers don't know how to properly re-order reads > with > + * respect to writes. In order to prevent accidental re-ordering and > + * CSE, flag them as having side-effects. > + */ > + return true; > +
Why would that be necessary? Don't surface writes and atomics act as a scheduling barrier? > case SHADER_OPCODE_UNTYPED_ATOMIC: > case SHADER_OPCODE_UNTYPED_ATOMIC_LOGICAL: > case SHADER_OPCODE_UNTYPED_ATOMIC_FLOAT: > -- > 2.19.1 > > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
