Bug 104971 - Test failures on 32 bit Mesa compiled with GCC 7.x
Summary: Test failures on 32 bit Mesa compiled with GCC 7.x
Status: RESOLVED MOVED
Alias: None
Product: piglit
Classification: Unclassified
Component: tests (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Piglit Mailing List
QA Contact: Piglit Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-02-06 18:12 UTC by Clayton Craft
Modified: 2019-03-06 15:47 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Clayton Craft 2018-02-06 18:12:46 UTC
Compiling 32 bit Mesa with GCC 7.x and -O1 results in a number of test failures in piglit (e.g. packUnorm2x16).

These tests do *not* fail in either of the following cases:

1) Mesa is compiled with GCC 7 and the -mfpmath=sse flag

2) Mesa is compiled with GCC 6.x

3) Mesa is compiled with -O0

Compiling Mesa with GCC 7 and negating the (exposed) options (e.g. -fno-<option>) that are enabled by -O1 still results in a failure. These options were collected from the output of: gcc -Q --help=optimizers -O1|grep enabled
Comment 1 Mark Janes 2018-02-09 00:52:07 UTC
Full list of failures:

    piglit.spec.glsl-es-3_00.execution.built-in-functions.const-packunorm2x16.sklm32
    piglit.spec.arb_shading_language_packing.execution.built-in-functions.const-packunorm4x8.sklm32
    piglit.spec.arb_shading_language_packing.execution.built-in-functions.const-packunorm2x16.sklm32

Failure mode always the same:

Probe color at (0,0)
  Expected: 0 255 0 255
  Observed: 255 0 0 255
Test failure on line 1343
Comment 2 Clayton Craft 2018-02-09 01:35:16 UTC
I found one specific test case in piglit that fails (from piglit.spec.arb_shading_language_packing.execution.built-in-functions.const-packunorm2x16):

    actual = packUnorm2x16(vec2(1e+256, 0.9));
    
    if (true
        && actual != 3865509887u
        ) {
         vert_color = red;
    }
Comment 3 Francisco Jerez 2018-02-09 02:08:44 UTC
(In reply to Clayton Craft from comment #2)
> I found one specific test case in piglit that fails (from
> piglit.spec.arb_shading_language_packing.execution.built-in-functions.const-
> packunorm2x16):
> 
>     actual = packUnorm2x16(vec2(1e+256, 0.9));
>     
>     if (true
>         && actual != 3865509887u
>         ) {
>          vert_color = red;
>     }

That confirms my suspicion that this is really a bug of the piglit test.  The 0.9 floating point value is exactly mid-way between the 0xe665 and 0xe666 unorm constants, so the test's expectations that it will give 0xe666 are unwarranted.

The easiest solution for this is likely to be to add some checks to the python generator to avoid testing conversions that have an ambiguous result.
Comment 4 Kenneth Graunke 2018-02-09 07:40:25 UTC
It's interesting that it's all constant expression tests.
Comment 5 Francisco Jerez 2018-02-09 19:13:54 UTC
Apparently the gen_builtin_packing_tests.py generator goes through some effort to allow different encodings for each subtest with an ambiguous result, but for this specific one the two rounding modes which are considered at all by the generator yield the same result 0xe666, so it only emits one check into the shader, even though the GLSL spec allows for round(0xe665.8) to give either 0xe665 or 0xe666 as a result.
Comment 6 Mark Janes 2018-02-09 21:23:19 UTC
The first failures I saw were:
    actual = packUnorm2x16(vec2(0.89999998, -1e+256));

    if (true
        && actual != 58982u
       ) {
        vert_color = red;
    }

    actual = packUnorm2x16(vec2(-1e+256, 0.89999998));

    if (true
        && actual != 3865444352u
       ) {
        vert_color = red;
    }


are those examples of the same test issue?
Comment 7 Francisco Jerez 2018-02-09 21:37:25 UTC
(In reply to Mark Janes from comment #6)
> The first failures I saw were:
>     actual = packUnorm2x16(vec2(0.89999998, -1e+256));
> 
>     if (true
>         && actual != 58982u
>        ) {
>         vert_color = red;
>     }
> 
>     actual = packUnorm2x16(vec2(-1e+256, 0.89999998));
> 
>     if (true
>         && actual != 3865444352u
>        ) {
>         vert_color = red;
>     }
> 
> 
> are those examples of the same test issue?

Yeah, they look bogus in the same way.  The test only accepts 0xe666 as valid encoding even though when doing the scaling with full x87 precision you'll get a result around 0xe665.7f, which is actually slightly closer to 0xe665, so it ends up being rounded down by the GLSL front-end which the test doesn't allow as valid result.
Comment 8 GitLab Migration User 2019-03-06 15:47:10 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/piglit/issues/7.


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.