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

Eric Anholt eric at anholt.net
Tue Aug 16 12:59:22 PDT 2011

On Tue, 16 Aug 2011 11:55:50 -0700, Kenneth Graunke <kenneth at whitecape.org> 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.
> 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.

Nope, we don't copy-propagate/coalesce across type changes, particularly
because you can't mix float/int on snb at all.

> - Do we use saturate on integers?
>   Doubtful, as it doesn't make much sense, but...

Looks like we would!  We should just disable try_emit_saturate() for
integer expressions.

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

We only use MAC for linterp, and have no MAD code.  The risk of this
patch would be instruction scheduling across the acc reg usage in the
MUL, but the scheduler will see some misc. register being accessed, and
treat it as a barrier.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20110816/9cd3993c/attachment.pgp>

More information about the mesa-dev mailing list