Uninitialized varying test on r500 on Windows

[Stefan Dösinger]

Hi Matteo,

I'm trying to make my Windows systems test failure free and I'd like to
ask you for your opinion of a failure I am getting in
test_uninitialized_varyings on my r500 GPU (Radeon X1600M)

I have attached the output of d3d9:visual to this mail. I am a bit lost
how those results fit in the grand scheme of things. Is it just another
case of some varying components being initialized to 0 and others to 1,
or do you see a pattern in these?

The .y=0.5 result in test cases 14 and 17 are weird as well. The test
failure in line 7362 (pretransformed_varying_test) seems related too,
although here my card behaves in the same way as WARP.

The d3d8 version of test_uninitialized_varyings is affected as well. The
line numbers are from commit 9eb56e25e37b4adec0d72875455ffb787238672f.

Cheers,
Stefan

[Matteo Bruni]

2017-02-19 20:10 GMT+01:00 Stefan Dösinger :
> Hi Matteo,
>
> I'm trying to make my Windows systems test failure free and I'd like to
> ask you for your opinion of a failure I am getting in
> test_uninitialized_varyings on my r500 GPU (Radeon X1600M)
>
> I have attached the output of d3d9:visual to this mail. I am a bit lost
> how those results fit in the grand scheme of things. Is it just another
> case of some varying components being initialized to 0 and others to 1,
> or do you see a pattern in these?

I don't know that I am particularly authoritative on the matter.
Anyway, I guess cases 9, 10 and 11 are somewhat reasonable and I would
be okay with accepting them (maybe with a broken, given that we
probably prefer the current results over those).
> The .y=0.5 result in test cases 14 and 17 are weird as well. The test
> failure in line 7362 (pretransformed_varying_test) seems related too,
> although here my card behaves in the same way as WARP.

My feeling is that a number of drivers are just broken in some way or
another with partially initialized varyings. That would suggest that
we shouldn't care about these test cases but since newer GPUs seem to
generally do the "correct" thing I think there is some value in
keeping them around. Maybe it makes sense to make these tests fail on
Windows only if the red component is not 0x7f +- 1 i.e. something
like:

ok(... || broken(tests[i].partial && color_match(color & 0x00ff0000,
tests[i].expected & 0x00ff0000), 1), ...);

If you go for that you can probably also uncomment the two tests
failing for me on the HD 2600. Either way, please add / update
comments accordingly.

Thanks for looking into those test failures :)