Bug 107089

Summary: [GLSL] "Multiplication by zero" optimization for floating point expression should be skipped
Product: Mesa Reporter: vadym <vadym.shovkoplias>
Component: glsl-compilerAssignee: mesa-dev
Status: RESOLVED MOVED QA Contact: Intel 3D Bugs Mailing List <intel-3d-bugs>
Severity: normal    
Priority: medium    
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments: shader test

Description vadym 2018-07-02 15:17:38 UTC
Created attachment 140436 [details]
shader test

Shader test for this case is attached.
Comment 1 Ilia Mirkin 2018-07-02 15:29:35 UTC
GLSL's approach to NaN is pretty weak.

https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_shader_precision.txt

"""
    The following rules apply to both single and double precision operations:  
    Dividing by 0 results in the appropriately signed IEEE Inf.  Any denormalized 
    value input into a shader or potentially generated by an operation in a shader 
    can be flushed to 0.  In general, correct signedness of 0 is not required.  The 
    rounding mode cannot be set and is undefined.  Support for signaling NaNs is 
    not required and exceptions are never raised.  Operations and built-in functions 
    that operate on a NaN are not required to return a NaN as the result.
"""

So NaN * 0 -> 0 appears to be a valid transformation. I haven't gone back and checked what's in the core specs, but I doubt it's any different.
Comment 2 Roland Scheidegger 2018-07-02 18:41:21 UTC
(In reply to Ilia Mirkin from comment #1)
> So NaN * 0 -> 0 appears to be a valid transformation. I haven't gone back
> and checked what's in the core specs, but I doubt it's any different.
For this particular shader, it's actually -Inf * 0.0 -> NaN that is checked.
The optimization though looks unsafe to me. Although sure enough glsl allows this crazyness (I mean why does it even have a isnan function if you're not required to generate NaNs...), but some (newer) apps might expect ieee754 behavior (or they might expect d3d10 behavior, which is the same wrt NaNs).
Comment 3 Ian Romanick 2018-07-02 22:49:17 UTC
Basically, unless you use precise, it's like compiling -ffast-math.  A lot of apps go to lengths to avoid the possibility of generating Inf or NaN in shaders due the the problems that they cause.
Comment 4 GitLab Migration User 2019-09-18 19:46:15 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/819.

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.