On Tue, Mar 31, 2015 at 2:20 PM, Matt Turner <matts...@gmail.com> wrote: > On Tue, Mar 31, 2015 at 11:11 AM, Rob Clark <robdcl...@gmail.com> wrote: >> On Tue, Mar 31, 2015 at 2:03 PM, Kenneth Graunke <kenn...@whitecape.org> >> wrote: >>> I'm pretty sure you want b2f here, not u2f...the slt/sge/seq/sne opcodes >>> are defined to return either 0.0 or 1.0. flt and friends return 0 or >>> 0xFFFFFFFF. u2f converts the numerical value of the unsigned source to >>> float, so this would return 0.0 or 4294967295.0. >>> >> >> hmm, that is a bit sad (since on the flt/etc cases I'd have to >> multiply by 0xffffffff, which would in turn require a mov for the >> 0xffffffff or perhaps emitting a driver uniform/const), and since it >> makes the b2f more complicated.. > > Are you saying your hardware returns 0/1 for false/true?
yup > If you can do integer negation as a source mod, you can just negate its uses. nop, only float negate.. I guess I could do the minus-one thing. But in cases where the value is just consumed by another instruction as a boolean, then the 0/1 thing is good enough. (but having b2u_recast type op seems like it would give me a good way to fix things up only if they are needed by an instruction consume uint/int, so we could abstract better whether bool is 0/1 or 0/~0) > Alternatively, Jason's implemented a pass to "resolve" booleans to > these values, which is necessary for us on i965 Gen4 and Gen5. You > could probably use that. ok, is that already merged or on list somewhere? BR, -R _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
