[Mesa-dev] [PATCH 2/6] glsl: Implement any(v) as any_nequal(v, false).

[Ian Romanick]

On 12/01/2015 01:36 PM, Ilia Mirkin wrote:
> On Tue, Dec 1, 2015 at 4:24 PM, Ian Romanick <idr at freedesktop.org> wrote:
>>> So this is the test I came up with:
>>>
>>> FRAG
>>> DCL IN[0], GENERIC[0], PERSPECTIVE
>>> DCL OUT[0], COLOR
>>> DCL TEMP[0..4], LOCAL
>>> IMM[0] UINT32 { 0, 0, 0, 0 }
>>> 0: MOV TEMP[0], IN[0]
>>> 1: USNE TEMP[0], TEMP[0], IMM[0]
>>> 2: OR TEMP[0].x, TEMP[0].xxxx, TEMP[0].yyyy
>>> 3: OR TEMP[0].x, TEMP[0].xxxx, TEMP[0].zzzz
>>> 4: OR TEMP[0].x, TEMP[0].xxxx, TEMP[0].wwww
>>> 5: MOV OUT[0], TEMP[0].xxxx
>>> 9: END
>>
>> I think the more common case, and certainly the case that Matt was
>> targeting with the optimization in patch 6, is where the result of
>> any(v) is used in a conditional:
>>
>>     if (any(v)) {
>>         do_this();
>>     } else {
>>         do_that();
>>     }
>>
>> or
>>
>>     result = any(v) ? a : b;
>>
>> Looking at my very out-of-date shader-db, 100% of the uses excluding one
>> application fit one of these patterns.  That app has a bunch of macros
>> that do 'any(notEqual(v, vec#(0.0)))', so TGSI is already going to
>> generate extra instructions.
> 
> What I'm failing to see is *any* justification for this change. Why
> are you removing that GLSL IR node? Is it hurting anyone? If you want
> it to generate something different into nir, go for it... Having an if
> () on the result will just add an extra USNE, it won't do anything
> about the first one.
> 
> We have all sorts of nodes for like or, and, etc -- all of those are
> superfluous, we could just use nand everywhere right? But we don't
> because it's more convenient to see what's going on. Why are you
> trying to get rid of ir_unop_any?

Deleting redundant code is generally a good thing.  Having multiple ways
to represent the exact same thing means that an optimization like the
one in patch 6 has to recognize all of them.  Representing every logical
operation using NAND would add code and complexity.  Note that we don't
have special "== 0", "+ 1", etc operators, so ir_unop_any and
ir_unop_all are a little odd in that respect.

I think even if we add code to st_glsl_to_tgsi to recognize the
any_nequal(v, false) pattern, it will still be a net reduction on lines
of code.

>   -ilia