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@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
