Bug 38971 - [bisected]oglc glsl-autointconv subcase negative.function.ambiguousMatch failed
[bisected]oglc glsl-autointconv subcase negative.function.ambiguousMatch failed
Status: VERIFIED FIXED
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965
git
All Linux (All)
: high normal
Assigned To: Kenneth Graunke
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-07-05 03:35 UTC by fangxun
Modified: 2011-07-14 04:14 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
output of glsl-autointconv(negative.function.ambiguousMatch) (2.23 KB, text/plain)
2011-07-05 03:35 UTC, fangxun
Details

Note You need to log in before you can comment on or make changes to this bug.
Description fangxun 2011-07-05 03:35:43 UTC
Created attachment 48766 [details]
output of glsl-autointconv(negative.function.ambiguousMatch)

System Environment:
--------------------------
Arch:        i386
Platform:    huronriver 
Libdrm:     (master)2.4.26
Mesa:      (master)a221807dc5d69598afd1d0e0a4e715fb82a9f30d
Xserver:    (master)xorg-server-1.10.2.902
Xf86_video_intel: (master)2.15.0-163-g98f2e3855d70c02b05e2721a70ebce0c17e44283 
Kernel: (drm-intel-fixes)2b1ecb7337592a7bf0989efac46a5b52daab769e

Bug detailed description:
-------------------------
This regression happens on ironlake and sandybridge. Bisect find
commit 60eb63a855cb89962f2d5bb91e238ff2d1ab8702 is the first bad commit.
commit 60eb63a855cb89962f2d5bb91e238ff2d1ab8702
Author:     Kenneth Graunke <kenneth@whitecape.org>
AuthorDate: Tue Jun 14 16:28:32 2011 -0700
Commit:     Kenneth Graunke <kenneth@whitecape.org>
CommitDate: Wed Jun 29 16:07:13 2011 -0700

    glsl: Find the "closest" signature when there are multiple matches.

    Previously, ir_function::matching_signature had a fatal bug: if a
    function had more than one non-exact match, it would simply return NULL.

    This occured, for example, when looking for max(uvec3, uvec3):
    - max(vec3, vec3)   -> score 1 (found first)
    - max(ivec3, ivec3) -> score 1 (found second...used to return NULL here)
    - max(uvec3, uvec3) -> score 0 (exact match...the right answer)

    This did not occur for max(ivec3, ivec3) since the second match found
    was an exact match.

    The new behavior is to return a match with the lowest score.  If there
    is an exact match, that will be returned.  Otherwise, a match with the
    least number of implicit conversions is chosen.

    Fixes piglit tests max-uvec3.vert and glsl-inexact-overloads.shader_test.

    NOTE: This is a candidate for the 7.10 and 7.11 branches.

    Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
    Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
    Reviewed-by: Eric Anholt <eric@anholt.net>


Reproduce steps:
----------------
1. xinit&
2. ./oglconform -z -s -suite all -v 2 -D 115 -test glsl-autointconv negative.function.ambiguousMatch
Comment 1 Ian Romanick 2011-07-05 10:03:36 UTC
I'm curious to see which signature matched for the 3rd call to 'func'.
Comment 2 fangxun 2011-07-07 18:38:42 UTC
This regression only happens on mesa master branch.
Comment 3 Kenneth Graunke 2011-07-09 02:02:13 UTC
@Ian: It matched the first one (which is what I expected my code to do).

I implemented the wrong policy.  Page 42 (49 of the PDF) prohibits ambiguous function calls (no exact match and multiple inexact matches).  I've sent a patch to the mailing list for review which fixes the issue.  Subject line is:
[Mesa-dev] glsl: Reject ambiguous function calls (multiple inexact matches).
Comment 4 Kenneth Graunke 2011-07-11 10:54:59 UTC
commit 7304909d6537e00252347a10d0bae54ffd77ff91
Author: Kenneth Graunke <kenneth@whitecape.org>
Date:   Sat Jul 9 00:20:34 2011 -0700

    glsl: Reject ambiguous function calls (multiple inexact matches).
    
    According to the GLSL 1.20 specification, "it is a semantic error if
    there are multiple ways to apply [implicit] conversions [...] such that
    the call can be made to match multiple signatures."
    
    Fixes a regression caused by 60eb63a855cb89962f2d5bb91e238ff2d1ab8702,
    which implemented the wrong policy of finding a "closest" match.
    However, this is not a revert, since the original code failed to
    continue looking for an exact match once it found two inexact matches.
    
    It's OK to have multiple inexact matches if there's also an exact match.
    
    NOTE: This is a candidate for the 7.10 and 7.11 branches.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38971
    Reviewed-by: Eric Anholt <eric@anholt.net>
    Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Comment 5 fangxun 2011-07-14 04:14:36 UTC
Verified with mesa master commit 02c8ee202f5a159659a027deae4721ff05cd1530.