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 <kenn...@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.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
