<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Add FP64 support to the i965 shader backends" href="https://bugs.freedesktop.org/show_bug.cgi?id=92760#c69">Comment # 69</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Add FP64 support to the i965 shader backends" href="https://bugs.freedesktop.org/show_bug.cgi?id=92760">bug 92760</a> from <a class="email" href="mailto:itoral@igalia.com" title="Iago Toral <itoral@igalia.com>"> Iago Toral</a> <pre>(In reply to Samuel Iglesias from <a href="show_bug.cgi?id=92760#c68">comment #68</a>) > 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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>