-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/16/2011 11:55 AM, Kenneth Graunke wrote: > On 08/15/2011 10:57 PM, Eric Anholt wrote: >> The MUL opcode does a 16bit * 32bit multiply, and we need to do the >> MACH to get the top 16bit * 32bit added in. >> >> Fixes fs-op-mult-int-*, fs-op-mult-ivec* > > Sigh. You're right, of course...this is straight out of the > documentation (aside from dropping the high 64-bits). > > Reviewed-by: Kenneth Graunke <kenn...@whitecape.org> > (assuming it's passed a full piglit run) > > To implement a first stab at your "Emit just the MUL if we know an > operand is small enough" FINISHME, we could at least check if it's an > ir_constant of integer type that fits in 16-bits. That would be easy > and at least make things like 2*x not suck.
I hope you mean 'make things like 3*x not suck' because 2*x should be a shift. :) > But now I'm a bit paranoid...are we following the other restrictions? > > - Do we generate multiplies with mixed float/integer operands? > I could see it happen, say, after some optimization pass. If there's no explicit cast, that should fail ir_validate. Or do you mean in the lower-level IR? > - Do we use saturate on integers? > Doubtful, as it doesn't make much sense, but... > > Thankfully, we never use W and UW types (no 16-bit integers), so...we're > okay on those. But we might someday. Right? Wouldn't that be 'mediump int' if there were such a thing? > Also, using the accumulator always makes me paranoid, wondering exactly > when and what we're accumulating. Do MADs on integers work, given that > we currently implement MAD via MAC? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk5K4p8ACgkQX1gOwKyEAw9DFgCfeNBfIBuuMozssBxLHS2c2WD5 FwEAn0ywsF7bj4xoPAO46A0RrYPWUqSm =qMKH -----END PGP SIGNATURE----- _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
