[Mesa-dev] [PATCH v2 26/82] glsl: Don't do copy propagation on buffer variables

[Jordan Justen]

24-26 once again makes me wonder if these optimization *can* be used
with SSBOs based on the same ext spec wording I referenced before:

"The ability to write to buffer objects creates the potential for
 multiple independent shader invocations to read and write the same
 underlying memory. The same issue exists with the
 ARB_shader_image_load_store extension provided in OpenGL 4.2, which
 can write to texture objects and buffers. In both cases, the
 specification makes few guarantees related to the relative order of
 memory reads and writes performed by the shader invocations."

In these patches "other threads" were specifically mentioned.

Did these patches also prevent bad things from happening in generated
code? (Like mentioned for patch 23.)

-Jordan

On 2015-06-03 00:01:16, Iago Toral Quiroga wrote:
> Since the backing storage for these is shared we cannot ensure that the
> value won't change by writes from other threads.
> ---
>  src/glsl/opt_copy_propagation.cpp | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/glsl/opt_copy_propagation.cpp b/src/glsl/opt_copy_propagation.cpp
> index 806027b..f206995 100644
> --- a/src/glsl/opt_copy_propagation.cpp
> +++ b/src/glsl/opt_copy_propagation.cpp
> @@ -330,7 +330,7 @@ ir_copy_propagation_visitor::add_copy(ir_assignment *ir)
>           */
>          ir->condition = new(ralloc_parent(ir)) ir_constant(false);
>          this->progress = true;
> -      } else {
> +      } else if (lhs_var->data.mode != ir_var_shader_storage) {
>          entry = new(this->acp) acp_entry(lhs_var, rhs_var);
>          this->acp->push_tail(entry);
>        }
> -- 
> 1.9.1
> 
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev