On Wed, Aug 10, 2016 at 2:24 PM, Kenneth Graunke <kenn...@whitecape.org> wrote:
> On Wednesday, August 10, 2016 10:02:12 AM PDT Erik Faye-Lund wrote:
>> On Wed, Aug 10, 2016 at 4:30 AM, Kenneth Graunke <kenn...@whitecape.org>
>> wrote:
>> > On Haswell (GL 3.3):
>> >
>> > total instructions in shared programs: 6208759 -> 6203860 (-0.08%)
>> > instructions in affected programs: 856541 -> 851642 (-0.57%)
>> > helped: 3157
>> > HURT: 113
>> > LOST: 7
>> > GAINED: 15
>> >
>> > On Broadwell (GL 4.4):
>> >
>> > total instructions in shared programs: 11637854 -> 11632016 (-0.05%)
>> > instructions in affected programs: 1055693 -> 1049855 (-0.55%)
>> > helped: 3900
>> > HURT: 176
>> > LOST: 1
>> > GAINED: 18
>> >
>> > Signed-off-by: Kenneth Graunke <kenn...@whitecape.org>
>> > ---
>> > src/compiler/nir/nir_opt_algebraic.py | 4 ++++
>> > 1 file changed, 4 insertions(+)
>> >
>> > diff --git a/src/compiler/nir/nir_opt_algebraic.py
>> > b/src/compiler/nir/nir_opt_algebraic.py
>> > index 1cf614c..4e9896f 100644
>> > --- a/src/compiler/nir/nir_opt_algebraic.py
>> > +++ b/src/compiler/nir/nir_opt_algebraic.py
>> > @@ -251,6 +251,10 @@ optimizations = [
>> > (('ieq', 'a@bool', False), ('inot', 'a')),
>> > (('bcsel', a, True, False), ('ine', a, 0)),
>> > (('bcsel', a, False, True), ('ieq', a, 0)),
>> > + (('bcsel@32', a, 1.0, 0.0), ('b2f', ('ine', a, 0))),
>> > + (('bcsel@32', a, 0.0, 1.0), ('b2f', ('ieq', a, 0))),
>> > + (('bcsel@32', a, -1.0, -0.0), ('fneg', ('b2f', ('ine', a, 0)))),
>> > + (('bcsel@32', a, -0.0, -1.0), ('fneg', ('b2f', ('ieq', a, 0)))),
>> > (('bcsel', True, b, c), b),
>> > (('bcsel', False, b, c), c),
>> > # The result of this should be hit by constant propagation and, in the
>>
>> Same as the previous patch, this smells like intel-isms. Hardware that
>> has native bcsel with support for two inline immediates will do better
>> without.
>
> It definitely feels a little strange replacing a single bcsel with
> a fneg/b2f/ine, as that's three operations instead of one.
>
> I expect the ine to go away - assuming 'a' is a properly formatted
> boolean (0 or 0xFFFFFFFF), "ine a 0" will just become 'a'. ieq would
> turn into inot.
I made the point in another place in this thread, but you don't have
to assume -- things that take booleans as input should only ever get 0
or ~0. Anything else would be a bug in the compiler. Now that I have a
little more free time before school starts, I've been thinking about
making booleans have a bit-width of 1 (i.e. making them logical) and
then only lowering to their concrete representation very late, if at
all. That would keep this confusion from happening, in addition to
bringing a lot of other benefits, and it should be a lot easier now
that we have bit widths in NIR.
> If the boolean was a comparison, the inot could be
> folded in - i.e. inot(flt(a,b)) -> fge(a,b). Or, some GPUs can handle
> boolean negation as a source modifier, so it might be free there too.
>
> Floating point negation can usually be done as a source modifier.
>
> For reference, here's a shader snippet from Goat Simulator which
> prompted me to write this optimization:
>
> const vec4 LocalConst1 = vec4(0.250000, -0.250000, 0.000000, 1.000000);
>
> void main()
> {
> ...
> InstrHelpTemp.r = ( ( Temporary1.r >= 0.0 ) ? LocalConst1.b : LocalConst1.a );
> ...
> }
>
> which could be turned into
>
> InstrHelpTemp.r = float(Temporary1.r < 0.0);
>
> which seems arguably better, regardless of hardware.
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
