Closed sankhesh closed 2 years ago
I thought about this some more. My wrong assumption was that FPEs are limited to the C++ code, but of course those are HW runtime checks, which will also trigger when executing ISPC code. This is an issue: our rendering code is optimized for performance (and robustness when it matters, i.e., for intersection, but typically not for material shading code); we even recommend to set denormals-are-zero and flush-to-zero; in many places division-by-zero is fine, because the algorithms correctly deal with inf
. Thus, I tend to close with "won't fix". What is the context, why does VTK enable FPEs (and, BTW, inconsistently between Windows (underflows trigger) and Linux(underflows ignored)?
Oh, it's even close to impossible to avoid FPEs for ISPC code: inactive pixels or sections of diverging code correspond to (software) masked SIMD lanes, i.e., those results are never used but intermediate results may be computed with garbage values that can still trigger FPEs (at least for AVX2 where are no mask registers / predicates that AVX512 has).
Totally fine by me. VTK enables FPE checks for all rendering tests to catch idiosyncracies. I have a change that disables this for OSPRay tests here - https://gitlab.kitware.com/vtk/vtk/-/merge_requests/8483
There are multiple floating point exceptions when rendering with
vtkFloatingPointExceptions::Enable
502 fixes some of them but I still see the following: