[Mesa-dev] [PATCH] i965/fs: Fix 32-bit integer multiplication.
idr at freedesktop.org
Tue Aug 16 14:35:27 PDT 2011
-----BEGIN PGP SIGNED MESSAGE-----
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 <kenneth at 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
> 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/
-----END PGP SIGNATURE-----
More information about the mesa-dev