On Tue, Jan 20, 2015 at 4:02 PM, Matt Turner <matts...@gmail.com> wrote:
> On Tue, Jan 20, 2015 at 3:51 PM, Jason Ekstrand <ja...@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.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
