From 7f821289cb5bdf730d3af03472d83a1562bce25a Mon Sep 17 00:00:00 2001 From: "Juan A. Suarez Romero" Date: Thu, 19 Dec 2019 20:01:16 +0100 Subject: [PATCH] Revert "nir/lower_double_ops: relax lower mod()" This reverts commit 8172b1fa03fe74165728bfb182c98a3e62193d2b. This commit was done taking in account Vulkan spec, but did not realize it was affecting OpenGL too. Closes: #2252 --- src/compiler/nir/nir_lower_double_ops.c | 21 ++++++--------------- 1 file changed, 6 insertions(+), 15 deletions(-) diff --git a/src/compiler/nir/nir_lower_double_ops.c b/src/compiler/nir/nir_lower_double_ops.c index 57bcb342a80..322ae49bacd 100644 --- a/src/compiler/nir/nir_lower_double_ops.c +++ b/src/compiler/nir/nir_lower_double_ops.c @@ -426,24 +426,15 @@ lower_mod(nir_builder *b, nir_ssa_def *src0, nir_ssa_def *src1) * * If the division is lowered, it could add some rounding errors that make * floor() to return the quotient minus one when x = N * y. If this is the - * case, we should return zero because mod(x, y) output value is [0, y). - * But fortunately Vulkan spec allows this kind of errors; from Vulkan - * spec, appendix A (Precision and Operation of SPIR-V instructions: - * - * "The OpFRem and OpFMod instructions use cheap approximations of - * remainder, and the error can be large due to the discontinuity in - * trunc() and floor(). This can produce mathematically unexpected - * results in some cases, such as FMod(x,x) computing x rather than 0, - * and can also cause the result to have a different sign than the - * infinitely precise result." - * - * In practice this means the output value is actually in the interval - * [0, y]. - * + * case, we return zero because mod(x, y) output value is [0, y). */ nir_ssa_def *floor = nir_ffloor(b, nir_fdiv(b, src0, src1)); + nir_ssa_def *mod = nir_fsub(b, src0, nir_fmul(b, src1, floor)); - return nir_fsub(b, src0, nir_fmul(b, src1, floor)); + return nir_bcsel(b, + nir_fne(b, mod, src1), + mod, + nir_imm_double(b, 0.0)); } static nir_ssa_def * -- 2.30.2