[Mesa-dev] [PATCH 15/16] i965/fs: Add support for removing MOV.NZ instructions.

[Jason Ekstrand]

On Tue, Jan 20, 2015 at 4:02 PM, Matt Turner <mattst88 at gmail.com> wrote:

> On Tue, Jan 20, 2015 at 3:51 PM, Jason Ekstrand <jason at jlekstrand.net>
> wrote:
> > Except typeless...  We need some sort of assurance that the result of a
> NIR
> > comparison is always 0 or ~0.
>
> Help me understand how this is a different situation from what we have
> today?
>
> Let's take for instance a vec2 == vec2 comparison. On Gen4/5 we
> generate two CMPs an AND to combine their results and a single
> resolving AND.NZ with 1 to generate the flag.
>
> Look at
> generated_tests/spec/glsl-1.10/execution/built-in-functions/fs-op-eq-vec2-vec2-using-if.shader_test
> for example.
>
> Why should NIR necessitate doing any of that differently?
>

Because we don't have a concept of "boolean".  Instead, a == b is supposed
to produce ~0 if equal and 0 if not.  On older gens, we have to clean up by
doing -((a == b) & 1).  If we're doing a vector operation, we have to take
the final result and and things together so we get -((a.x == b.x) & 1) &
-(a.y == b.y) & 1).  Of course, we can propagate through the and and just
get -(((a.x == b.x) & (a.y == b.y)) & 1) which is what we want to do.
Right now, NIR doesn't do anything interesting like transforming b2f into &
with 0x3f800000 but, as per the boolean convention in NIR, it could.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20150120/64a19c61/attachment.html>