[Mesa-dev] [PATCH] i965/fs: Fix 32-bit integer multiplication.

[Ian Romanick]

-----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 <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
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-----