[Mesa-dev] [PATCH] glsl: Consider ubo_load to be a horizontal operation.

[Kenneth Graunke]

On Monday, February 22, 2016 9:39:34 AM PST Matt Turner wrote:
> Unclear to me whether it actually is a horizontal operation that cannot
> be vectorized, but the fact that i965 generates the same code in either
> case makes me less interested in finding out.
> 
> Cc: mesa-stable at lists.freedesktop.org
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94199
> ---
>  src/compiler/glsl/ir.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/src/compiler/glsl/ir.h b/src/compiler/glsl/ir.h
> index 93c893d..f6ed16d 100644
> --- a/src/compiler/glsl/ir.h
> +++ b/src/compiler/glsl/ir.h
> @@ -1686,6 +1686,7 @@ public:
>               operation == ir_binop_dot ||
>               operation == ir_binop_vector_extract ||
>               operation == ir_triop_vector_insert ||
> +             operation == ir_binop_ubo_load ||
>               operation == ir_quadop_vector;
>     }
>  
> 

It's not really a "horizontal" operation...but the vectorizer code isn't
going to handle it.  One could "vectorize" UBO loads by looking for
scalar loads at consecutive component offsets (0, 4, 8, 12) and changing
them to a single vecN load at the .x component's offset.

At least for i965, this shouldn't be useful.  IIRC, we already align the
base offset of UBO loads to vec4s, and always load a whole vec4, since
it's the same cost as any other load.  This means that all four scalar
loads get the same base offset, and so CSE takes care of it.

Because of that, I don't think there's much value in implementing a
proper vectorizer, so simply disabling the existing broken one seems
like a fine plan.

Reviewed-by: Kenneth Graunke <kenneth at whitecape.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160222/f213b903/attachment.sig>