| Summary: | dEQP-GLES3: modf does not produce correct results with infinities | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Iago Toral <itoral> |
| Component: | Drivers/DRI/i965 | Assignee: | Intel 3D Bugs Mailing List <intel-3d-bugs> |
| Status: | RESOLVED WONTFIX | QA Contact: | Intel 3D Bugs Mailing List <intel-3d-bugs> |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | git | ||
| Hardware: | Other | ||
| OS: | All | ||
| URL: | https://cvs.khronos.org/bugzilla/show_bug.cgi?id=13907 | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | Fixes modf with infinities by adding a conditional at the IR level | ||
I'm not aware of any real world programs using modf(). These tests were changed to accept a NaN return value in: commit 4fdcdd50d72a1317dbab9f75738e5bb9ccd30634 Author: Pyry Haulos <phaulos@google.com> Date: Tue May 5 12:31:13 2015 -0700 Relax builtin precision tests, fix issue in div rounding * sin(), cos() and derived: Use |x| * 2^-10 for mediump inputs outside of range [-pi,pi]. * asin(), acos(), and atan(): Use 4096 ULP for highp (from OpenCL's fast relaxed math). * modf(): allow any value, including NaN, as fractional if Inf support is not mandated for the precision (lowp and mediump). * atan(y, x): allow any value if y or x is Inf and no Inf support is mandated for the precision. * div (and derived): allow rounding of -/+inf to -/+maxval when both inputs are ordinary and denominator is not 0 (legal in RTZ mode). Bug: 20453754 Bug: 18323265 Change-Id: I8e2fad8909e29993e961d66a175963071ea2e5a8 There's also a Khronos bug discussing the issue in $URL. Conclusion is "Allow NaN or zero. State that NaN preferred." |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Created attachment 114429 [details] Fixes modf with infinities by adding a conditional at the IR level List of affected tests: dEQP-GLES3.functional.shaders.builtin_functions.precision.modf.lowp_vertex dEQP-GLES3.functional.shaders.builtin_functions.precision.modf.lowp_fragment dEQP-GLES3.functional.shaders.builtin_functions.precision.modf.mediump_vertex dEQP-GLES3.functional.shaders.builtin_functions.precision.modf.mediump_fragment dEQP-GLES3.functional.shaders.builtin_functions.precision.modf.highp_vertex dEQP-GLES3.functional.shaders.builtin_functions.precision.modf.highp_fragment The problem is that Mesa implements modf as trunc to get the integer part, then subtracts that from the parameter to obtain the remainder and that gives a NaN instead of 0. I tried calculating the remainder directly with ir_unop_fract but that also gives as NaN as result, so it looks like there is no way around this issue. Of course, we can add a conditional check to modf in order to detect this case specifically and solve it directly, but that would hurt all emissions of the function, so I am not sure that we want to do this. Attached is a patch that does this at the IR level (even if we want to do this maybe we want to do it inside i965, not sure) and fixes the tests.