<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#c81">Comment # 81</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>(In reply to Iago Toral from <a href="show_bug.cgi?id=92760#c69">comment #69</a>) > (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. The generic solution would be if x = N * y and the result of mod(x,y) is equal to 'y' (so floor(x/y) = N - 1), then we should return 0 because mod(x,y) ∈ [0,y). I think this is the proper solution although we add a bcsel in that case. 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>