Avoid undefined behavior in glsl-routing test
commit17bccd6b2b2e73903c6909561187329297d97bcc
authorPierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Fri, 3 May 2019 13:43:36 +0000 (3 15:43 +0200)
committerPierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Wed, 8 May 2019 15:01:06 +0000 (8 17:01 +0200)
tree4e34683151eb3227f7f54598008e5eea2672ee91
parenta7a58e05fe7e0148fabb55703249842e560c5bf5
Avoid undefined behavior in glsl-routing test

This test reads attribute in the FS (e.g: gl_SecondaryColor) without writing
them in the VS.
It shouldn't affect the output since in this case the eq() function returns 0.0,
so it's equivalent to: r += 0.0 * gl_SecondaryColor.

The problems are:
  - if gl_SecondaryColor is unwritten, its value is allowed to be NaN, in which
case it will affect the output color and test will fail even if the driver is valid
  - the GLSL 1.20 specs says (7.6 Varying variables):

"The values in gl_Color  and  gl_SecondaryColor  will be derived automatically by
the system from gl_FrontColor, gl_BackColor, gl_FrontSecondaryColor, and
gl_BackSecondaryColor  based on which face is visible."

And the paragraph before says:

"A particular [varying variable] should be written to if any functionality in a
corresponding fragment shader or fixed pipeline uses it or state derived from it.
Otherwise, behavior is undefined."

This commit replaces the 'r += eq(...) * gl_SecondaryColor' lines with
'if (eq(...)) r += gl_SecondaryColor' ones which aren't affected by the above
issues.

Fixes the test on my AMD Vega10 system.

Reviewed-by: Eric Anholt <eric@anholt.net>
tests/shaders/glsl-routing.c