<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 20, 2015 at 4:02 PM, Matt Turner <span dir="ltr"><<a href="mailto:mattst88@gmail.com" target="_blank">mattst88@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, Jan 20, 2015 at 3:51 PM, Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> wrote:<br>
> Except typeless...  We need some sort of assurance that the result of a NIR<br>
> comparison is always 0 or ~0.<br>
<br>
</span>Help me understand how this is a different situation from what we have today?<br>
<br>
Let's take for instance a vec2 == vec2 comparison. On Gen4/5 we<br>
generate two CMPs an AND to combine their results and a single<br>
resolving <a href="http://AND.NZ" target="_blank">AND.NZ</a> with 1 to generate the flag.<br>
<br>
Look at generated_tests/spec/glsl-1.10/execution/built-in-functions/fs-op-eq-vec2-vec2-using-if.shader_test<br>
for example.<br>
<br>
Why should NIR necessitate doing any of that differently?<br>
</blockquote></div><br></div><div class="gmail_extra">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.<br></div></div>