Bug 107089 - [GLSL] "Multiplication by zero" optimization for floating point expression should be skipped
Summary: [GLSL] "Multiplication by zero" optimization for floating point expression sh...
Status: RESOLVED MOVED
Alias: None
Product: Mesa
Classification: Unclassified
Component: glsl-compiler (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: mesa-dev
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-07-02 15:17 UTC by vadym
Modified: 2019-09-18 19:46 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
shader test (237 bytes, text/plain)
2018-07-02 15:17 UTC, vadym
Details

Note You need to log in before you can comment on or make changes to this bug.
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.