[Mesa-dev] [PATCH 2/3] i965/fs/nir: Optimize (gl_FrontFacing ? x : y) where x and y are ±1.0.

[Matt Turner]

On Fri, Feb 20, 2015 at 11:54 AM, Eric Anholt <eric at anholt.net> wrote:
> I wanted patch #1 to land, so I took a look at this one :)

Thanks! :)

> Matt Turner <mattst88 at gmail.com> writes:
>> +   if (brw->gen >= 6) {
>> +      /* Bit 15 of g0.0 is 0 if the polygon is front facing. */
>> +      fs_reg g0 = fs_reg(retype(brw_vec1_grf(0, 0), BRW_REGISTER_TYPE_W));
>> +
>> +      /* For (gl_FrontFacing ? 1.0 : -1.0), emit:
>> +       *
>> +       *    or(8)  tmp.1<2>W  g0.0<0,1,0>W  0x00003f80W
>> +       *    and(8) dst<1>D    tmp<8,8,1>D   0xbf800000D
>> +       *
>> +       * and negate g0.0<0,1,0>W for (gl_FrontFacing ? -1.0 : 1.0).
>> +       */
>> +
>> +      if (value1->f[0] == -1.0f) {
>> +         g0.negate = true;
>> +      }
>
> Does this do what you want?  If g0.0 happened to be *all* zeroes, you're
> still going to get 0 after negation, right?

That's a good question. I'm not sure. The bits below it are

13: Source Depth Present to Render Target.
12: oMask to Render Target
11: Source0 Alpha Present to RenderTarget.
8:6: Starting Sample Pair Index

BDW adds some additional fields as well.

The others are "ignored". It's not clear to me that at least one of
the defined bits is guaranteed to be zero. It's no guarantee or
anything, but FWIW without realizing it we were depending on some bit
being non-zero for the frontfacing optimizations that used ASR as well
(commits d1c43ed4, 19c6617a) and haven't seen any problems from it. So
if there's a problem... we're not making it worse in this commit...

The simulator seems to set some bits in the ignored fields, but I
don't have any explanation for that, nor is that evidence that we can
rely on the hardware to do the same.

Or maybe I'm just wrong and some bit is guaranteed to be set?

> (I suppose your primitive type is probably going to be triangles if
> you're doing facing, so the low bits will be non-zero)