On Mon, Nov 26, 2018 at 2:08 PM Francisco Jerez <[email protected]> wrote:
> Jason Ekstrand <[email protected]> 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? > Yes, they do. Looking a bit more, I just found is_volatile() which is actually what I want. It does, indeed, return true for these but not for the new SEND opcode I added. That explains why things haven't exploded before. Thanks! I'll fix the send opcode. Feel free to disregard this patch. --Jason > > case SHADER_OPCODE_UNTYPED_ATOMIC: > > case SHADER_OPCODE_UNTYPED_ATOMIC_LOGICAL: > > case SHADER_OPCODE_UNTYPED_ATOMIC_FLOAT: > > -- > > 2.19.1 > > > > _______________________________________________ > > mesa-dev mailing list > > [email protected] > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev >
_______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
