<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#c68">Comment # 68</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:siglesias@igalia.com" title="Samuel Iglesias <siglesias@igalia.com>"> Samuel Iglesias</a> <pre>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?</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>