On Tue, Dec 1, 2015 at 4:24 PM, Ian Romanick <i...@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?
-ilia
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
