Bug 89645 - dEQP-GLES3: modf does not produce correct results with infinities
Summary: dEQP-GLES3: modf does not produce correct results with infinities
Status: RESOLVED WONTFIX
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Intel 3D Bugs Mailing List
QA Contact: Intel 3D Bugs Mailing List
URL: https://cvs.khronos.org/bugzilla/show...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-03-18 08:01 UTC by Iago Toral
Modified: 2017-02-13 19:35 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Fixes modf with infinities by adding a conditional at the IR level (1.68 KB, text/plain)
2015-03-18 08:01 UTC, Iago Toral
Details

Description Iago Toral 2015-03-18 08:01:32 UTC
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.
Comment 1 Kenneth Graunke 2015-03-19 01:45:35 UTC
I'm not aware of any real world programs using modf().
Comment 2 Matt Turner 2017-02-13 19:35:18 UTC
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.