On Thu, Jan 22, 2015 at 9:06 AM, Matt Turner <[email protected]> wrote:

> On Thu, Jan 22, 2015 at 7:27 AM, Jason Ekstrand <[email protected]>
> wrote:
> > On Jan 22, 2015 3:41 AM, "Kenneth Graunke" <[email protected]>
> wrote:
> >> diff --git a/src/glsl/nir/nir_opt_algebraic.py
> >> b/src/glsl/nir/nir_opt_algebraic.py
> >> index 169bb41..cf16b19 100644
> >> --- a/src/glsl/nir/nir_opt_algebraic.py
> >> +++ b/src/glsl/nir/nir_opt_algebraic.py
> >> @@ -68,6 +68,22 @@ optimizations = [
> >>     (('fadd', ('fmul', a, b), c), ('ffma', a, b, c)),
> >>     (('fge', ('fneg', ('fabs', a)), 0.0), ('feq', a, 0.0)),
> >>     (('fmin', ('fmax', a, 1.0), 0.0), ('fsat', a)),
> >> +   # Logical and bit operations
> >> +   (('fand', a, a), a),
> >
> > This isn't correct.  The fand operation will normalize to 0.0/1.0.
>
> I didn't understand why we had integer and float versions of bitwise
> operators before, but now I really don't understand what fand/for/fxor
> are for. What is their purpose? (Examples please)
>

They're for hardware that doesn't do integers.  That's not our hardware, so
we can really just ignore them for now.  I don't think our codegen can even
handle them.
_______________________________________________
mesa-dev mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to