[Mesa-dev] [PATCH] glsl: Fix type error when lowering integer divisions

[Kenneth Graunke]

On 08/12/2011 10:38 AM, Paul Berry wrote:
> This patch fixes a bug when lowering an integer division:
>
>    x/y
>
> to a multiplication by a reciprocal:
>
>    int(float(x)*reciprocal(float(y)))
>
> If x was a a plain int and y was an ivecN, the lowering pass
> incorrectly assigned the type of the product to be float, when in fact
> it should be vecN.  This caused mesa to abort with an IR validation
> error.
>
> Fixes piglit tests {fs,vs}-op-div-int-ivec{2,3,4}.

Good catch, Paul!  Thanks again for writing all these test cases.

Reviewed-by: Kenneth Graunke <kenneth at whitecape.org>

Come to think of it, we may want to avoid this altogether on i965.  The 
mathbox has an INT DIV message that computes integer quotient and 
remainder...so we can support it natively.

I guess the question is "which is faster?".  My intuition says that 
using INT DIV will be faster on Gen6+, possibly on Gen5, and slower on 
Gen4/G45.  AFAICT on Gen5+ you can compute quotient & remainder 
separately (3 or 4 rounds) while on Gen4 you always have to compute both 
(3 + 4 = 7 rounds?).  Meanwhile RCP is 2 rounds.  Not only is that more 
rounds, it means hogging the shared mathbox for longer.

Since Gen6 is supposed to be 2 rounds for everything and each EU has its 
own mathbox, it should save a MUL (and compute the answer without float 
imprecisions...which may be worth it anyway?).

I suppose measurements are in order. :)  Perhaps I ought to implement a 
similar float->int->float path for fmod.

Unfortunately, the HW doesn't do FDIV in ALT mode, so we still need to 
lower division for floats, I guess.