[Bug 92760] Add FP64 support to the i965 shader backends

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=92760

--- Comment #69 from Iago Toral <itoral at igalia.com> ---
(In reply to Samuel Iglesias from comment #68)
> Hello Jason, Connor:
> 
> I have found a problem with mod() working with double operands: mod(x, y) is
> calculated as x - y * floor(x/y).
> 
> When working with doubles on i965, we need to do two lowering passes:
> one to calculate the reciprocal of 'y' and other for the floor().
> 
> If x == y, then x/y == 1.0 but I found that calculated value is slightly
> less than 1.0 because of rounding errors. In that case, floor() returns 0.0
> and mod(x,y) ends up returning 'y' instead of 0. This is not happening for
> all values and that's the reason we have not seen it before.
> 
> We propose to create a lowering pass for mod() with doubles in
> nir_lowering_double_ops, where we check if x == y and return zero or the
> formula depending on the case. It would affect the performance for mod()
> operation due to the added bcsel but, as it only affects doubles (we can
> make nir_opt_algebraic to skip the double's case), we think it is not a bad
> idea.
> 
> What do you think?

I've been thinking about this and this is not a good idea, we probably have the
same problem every time that a = b * N where N is an integer. If we want to fix
this I think we need to check the fractional part of a / b and round the result
if it is "almost" 1.0... that is going to lead to some awful code, because
round is also lowered and it is a truly ugly hack but at least it should get
things like mod(10, 5)  or mod (10.6, 5.2) working as expected. It might break
things like mod(10, 4.999...) but I think that's probably more acceptable.

BTW, we found this issue in the desktop fp64 CTS tests.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-3d-bugs/attachments/20160402/27ff033a/attachment.html>