[1/2] nir: Add is_divergent_vector search helper

Submitted by Alyssa Rosenzweig on May 7, 2019, 3 a.m.

Details

Message ID 20190507030004.7568-1-alyssa@rosenzweig.io
State New
Headers show
Series "Series without cover letter" ( rev: 1 ) in Mesa

Not browsing as part of any series.

Commit Message

Alyssa Rosenzweig May 7, 2019, 3 a.m.
This allows algebraic optimizations to check if the argument accesses
multiple distinct components of a vector. So a swizzle like "xyz" will
return true, but "yyy" will return false, as will a scalar. This can be
useful for optimizations on vector processors, where a convergent
swizzle can be done in one clock (replicating as if a scalar) but a
divergent one must be scalarized. In these cases, it is useful to
optimize differently based on whether the swizzle diverges. (Use case is
the "csel" condition on Midgard).

Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Cc: Jason Ekstrand <jason@jlekstrand.net>
---
 src/compiler/nir/nir_search_helpers.h | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

Patch hide | download patch | download mbox

diff --git a/src/compiler/nir/nir_search_helpers.h b/src/compiler/nir/nir_search_helpers.h
index 1624508993d..46d7c300643 100644
--- a/src/compiler/nir/nir_search_helpers.h
+++ b/src/compiler/nir/nir_search_helpers.h
@@ -143,6 +143,22 @@  is_not_const(nir_alu_instr *instr, unsigned src, UNUSED unsigned num_components,
    return !nir_src_is_const(instr->src[src].src);
 }
 
+/* I.e. a vector that actually accesses multiple channels */
+
+static inline bool
+is_divergent_vector(nir_alu_instr *instr, UNUSED unsigned src, unsigned num_components,
+             const uint8_t *swizzle)
+{
+   unsigned first_component = swizzle[0];
+
+   for (unsigned i = 1; i < num_components; ++i) {
+      if (swizzle[i] != first_component)
+         return true;
+   }
+
+   return false;
+}
+
 static inline bool
 is_used_more_than_once(nir_alu_instr *instr)
 {

Comments

Divergence is generally when multiple parallel "lanes" go in different
directions -- a jump that some lanes take and others don't, which
requires the GPU to execute some lanes first, and then the rest,
separately.

IMO better names might be is_scalar_swizzle or something.

On Mon, May 6, 2019 at 11:00 PM Alyssa Rosenzweig <alyssa@rosenzweig.io> wrote:
>
> This allows algebraic optimizations to check if the argument accesses
> multiple distinct components of a vector. So a swizzle like "xyz" will
> return true, but "yyy" will return false, as will a scalar. This can be
> useful for optimizations on vector processors, where a convergent
> swizzle can be done in one clock (replicating as if a scalar) but a
> divergent one must be scalarized. In these cases, it is useful to
> optimize differently based on whether the swizzle diverges. (Use case is
> the "csel" condition on Midgard).
>
> Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
> Cc: Jason Ekstrand <jason@jlekstrand.net>
> ---
>  src/compiler/nir/nir_search_helpers.h | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
>
> diff --git a/src/compiler/nir/nir_search_helpers.h b/src/compiler/nir/nir_search_helpers.h
> index 1624508993d..46d7c300643 100644
> --- a/src/compiler/nir/nir_search_helpers.h
> +++ b/src/compiler/nir/nir_search_helpers.h
> @@ -143,6 +143,22 @@ is_not_const(nir_alu_instr *instr, unsigned src, UNUSED unsigned num_components,
>     return !nir_src_is_const(instr->src[src].src);
>  }
>
> +/* I.e. a vector that actually accesses multiple channels */
> +
> +static inline bool
> +is_divergent_vector(nir_alu_instr *instr, UNUSED unsigned src, unsigned num_components,
> +             const uint8_t *swizzle)
> +{
> +   unsigned first_component = swizzle[0];
> +
> +   for (unsigned i = 1; i < num_components; ++i) {
> +      if (swizzle[i] != first_component)
> +         return true;
> +   }

Can num_components be 1? If so, then this will return false, whereas
you probably wanted it to return true.

> +
> +   return false;
> +}
> +
>  static inline bool
>  is_used_more_than_once(nir_alu_instr *instr)
>  {
> --
> 2.20.1
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

> IMO better names might be is_scalar_swizzle or something.

Ah, yes, that would be a better name! is_not_scalar_swizzle in this case
(logic is flipped).

> Can num_components be 1? If so, then this will return false, whereas
> you probably wanted it to return true.

I think that's the correct behaviour...? It should return true if
multiple distinct channels are accessed. For nr_components=1, that's
false by definition.
On Tue, May 7, 2019 at 5:45 PM Alyssa Rosenzweig <alyssa@rosenzweig.io> wrote:
>
> > IMO better names might be is_scalar_swizzle or something.
>
> Ah, yes, that would be a better name! is_not_scalar_swizzle in this case
> (logic is flipped).
>
> > Can num_components be 1? If so, then this will return false, whereas
> > you probably wanted it to return true.
>
> I think that's the correct behaviour...? It should return true if
> multiple distinct channels are accessed. For nr_components=1, that's
> false by definition.

Right, that's my bad -- I was thinking is_scalar, but this is
is_non_scalar, so you're good. (My personal preference would be to
make it is_scalar and then stick a negation into the nir rule, but I
don't have anything solid to back up that preference. Negations in
names are confusing to me, I guess.)

Cheers,

  -ilia
Gotcha. I wasn't sure negations in the NIR search rule were possible...?
Sigh ... given that there's both "is_used_by_if" and
"is_not_used_by_if" ... gonna go with "no".

On Tue, May 7, 2019 at 6:42 PM Alyssa Rosenzweig <alyssa@rosenzweig.io> wrote:
>
> Gotcha. I wasn't sure negations in the NIR search rule were possible...?
D'oh.
They aren't. It's just a function pointer. We could add support for it but 
it doesn't seem worth the effort.

On May 7, 2019 17:42:23 Alyssa Rosenzweig <alyssa@rosenzweig.io> wrote:

> Gotcha. I wasn't sure negations in the NIR search rule were possible...?
> _______________________________________________
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Makes sense, thank you for the clarification.