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

Eric Anholt eric at anholt.net
Fri Feb 20 13:41:09 PST 2015


Matt Turner <mattst88 at gmail.com> writes:

> 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?

A "This negation looks like it's safe in practice, because bits 0:4 will
surely be TRIANGLES" comment seems fine with me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20150220/d8c25cc4/attachment-0001.sig>


More information about the mesa-dev mailing list