[Mesa-dev] [PATCH] mesa, glsl_to_tgsi: fixes for native integers

[Ian Romanick]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/30/2011 03:59 AM, Christoph Bumiller wrote:
> On 29.08.2011 19:22, Ian Romanick wrote:
>> On 08/27/2011 08:44 AM, Bryan Cain wrote:
>>> On 08/27/2011 05:39 AM, Christoph Bumiller wrote:
>>>> I still don't quite like booleans as floats, but I guess I can just
>>>> easily track back to the source SET to emit my
>> set-predicate-register op
>>>> without having all the fuss in between.
>>
>>> For now, I'm trying to get things working.  Once integers are working on
>>> softpipe and r600g with no piglit regressions, I'll look into
>>> optimizations like using AND.
>>
>> I think this is the underlying problem.  Without this patch series, some
>> of the code treats booleans as integers, and some of it still tries to
>> apply floating-point tricks.  Instead of reverting back to using
>> floating-point for booleans, it seems much better (by all metrics) to
>> finish the conversion to integer.  Emitting (1-x) for logical-not or
>> (a*b) for logical-and when you have an actual NOT and AND instructions
>> is just silly.
>>
>> Fixing that will make it irrelevant whether the integer set-on
>> instructions generate 1 or ~0 for true.  Right?
>>
> The NOT will only work for ~0 but not 1, so it does matter.

Oh man... memories of years of 68k assembly coding come rushing back.
Of course.  That's why all assembly coders use ~0 and 0 for logic
values.  It took me years to get used to C using 1 and 0.  When using 1
for logic true, you can also use xor, a bit-toggle instruction (if you
have one), or USEQ.  The (1-x) optimization is really just for old GPUs
that don't have native SEQ instructions.

> So should we force everyone to generate a specific value (~0 or 1, i.e.
> some hardware will have to NEG, which is mostly free) for integer SET,
> and emit the F2I(NEG(b)) for float SET (except for e.g. GLSL step()) ?
>
> With ~0 you can do NOT, with 1 you don't need negation on cast to int,
> or with 1.0f you don't need to do anything on cast to float (seems like
> a rare case to me) but use AND after every integer SET.
> 
> There's no optimal solution, you can only hope to optimize away any
> extra operations e.g. if you see IF(F2I(NEG(SET()))), you know that F2I
> and NEG don't make a difference so you let the SET write your
> FLAGS/PREDICATE register(s) and kill the other operations.

It's hard to say which is better, and it is likely to be dependent on
the GPU architecture.  At this point I would pick one of the values,
either 1 or ~0, and just implement that.  Once that works, it shouldn't
be hard to add a flag so that drivers can select the other value.  Then
you can look at the code generated for real shaders to see if it makes
any difference.

In the absence of any real data, you can't really make any performance
decisions.  Just pick whichever is easier to get right.  It's only then
that you can get performance data.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk5dWw0ACgkQX1gOwKyEAw/gsQCfWv4//r0PaJHA6H2jH8gkc4Kt
iuMAn0rChh5kQAZrta1b3XIjP9CjdiiM
=ZF4W
-----END PGP SIGNATURE-----