[Mesa-dev] [PATCH v2 26/82] glsl: Don't do copy propagation on buffer variables
Jordan Justen
jordan.l.justen at intel.com
Mon Jun 22 14:28:40 PDT 2015
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
More information about the mesa-dev
mailing list