bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Mon Apr 11 06:21:24 UTC 2016

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

--- Comment #81 from Samuel Iglesias <siglesias at igalia.com> ---
(In reply to Iago Toral from comment #69)
> (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?
>
> 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?

--
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/20160411/972b4eaa/attachment.html>
```