From c24bca2d3a0e4255dbe155cfb7d942bfb104a2ad Mon Sep 17 00:00:00 2001 From: Mike Blumenkrantz Date: Wed, 9 Mar 2022 13:44:16 -0500 Subject: [PATCH] zink: lower dmod on AMD hardware MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit this hardware won't return the correct value from dmod instructions, so lower it to ensure that cts passes nobody else will ever hit this, so perf isn't an issue and regular fmod can be left alone fixes (amd): KHR-GL46.gpu_shader_fp64.builtin.mod_d* Fixes: 5fae35fb17d6d89c4fe1d9d5a19d827caf25b9fc ('zink: fix 64bit float shader ops ') Reviewed-by: Daniel Schürmann Part-of: --- src/gallium/drivers/zink/zink_compiler.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/src/gallium/drivers/zink/zink_compiler.c b/src/gallium/drivers/zink/zink_compiler.c index 6887bb0289d..789120a7dc9 100644 --- a/src/gallium/drivers/zink/zink_compiler.c +++ b/src/gallium/drivers/zink/zink_compiler.c @@ -353,6 +353,21 @@ zink_screen_init_compiler(struct zink_screen *screen) screen->nir_options.lower_flrp64 = true; screen->nir_options.lower_ffma64 = true; } + + /* + 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. + + -Table 84. Precision of core SPIR-V Instructions + * for drivers that are known to have imprecise fmod for doubles, lower dmod + */ + if (screen->info.driver_props.driverID == VK_DRIVER_ID_MESA_RADV || + screen->info.driver_props.driverID == VK_DRIVER_ID_AMD_OPEN_SOURCE || + screen->info.driver_props.driverID == VK_DRIVER_ID_AMD_PROPRIETARY) + screen->nir_options.lower_doubles_options = nir_lower_dmod; } const void *