[Mesa-dev] [PATCH] intel/compiler: Flag surface reads as having side-effects

[Francisco Jerez]

Jason Ekstrand <jason at 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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20181126/f033875f/attachment.sig>