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

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;
    }

(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.

It's interesting that it's all constant expression tests.

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.

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?

(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.

-- 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.