List of affected tests: dEQP-GLES3.functional.shaders.builtin_functions.precision.mix.lowp_vertex.scalar dEQP-GLES3.functional.shaders.builtin_functions.precision.mix.lowp_vertex.vec2 dEQP-GLES3.functional.shaders.builtin_functions.precision.mix.lowp_vertex.vec3 dEQP-GLES3.functional.shaders.builtin_functions.precision.mix.lowp_vertex.vec4 dEQP-GLES3.functional.shaders.builtin_functions.precision.mix.lowp_fragment.scalar dEQP-GLES3.functional.shaders.builtin_functions.precision.mix.lowp_fragment.vec2 dEQP-GLES3.functional.shaders.builtin_functions.precision.mix.lowp_fragment.vec3 dEQP-GLES3.functional.shaders.builtin_functions.precision.mix.lowp_fragment.vec4 dEQP-GLES3.functional.shaders.builtin_functions.precision.mix.mediump_vertex.scalar dEQP-GLES3.functional.shaders.builtin_functions.precision.mix.mediump_vertex.vec2 dEQP-GLES3.functional.shaders.builtin_functions.precision.mix.mediump_vertex.vec3 dEQP-GLES3.functional.shaders.builtin_functions.precision.mix.mediump_vertex.vec4 dEQP-GLES3.functional.shaders.builtin_functions.precision.mix.mediump_fragment.scalar dEQP-GLES3.functional.shaders.builtin_functions.precision.mix.mediump_fragment.vec2 dEQP-GLES3.functional.shaders.builtin_functions.precision.mix.mediump_fragment.vec3 dEQP-GLES3.functional.shaders.builtin_functions.precision.mix.mediump_fragment.vec4 dEQP-GLES3.functional.shaders.builtin_functions.precision.mix.highp_vertex.scalar dEQP-GLES3.functional.shaders.builtin_functions.precision.mix.highp_vertex.vec2 dEQP-GLES3.functional.shaders.builtin_functions.precision.mix.highp_vertex.vec3 dEQP-GLES3.functional.shaders.builtin_functions.precision.mix.highp_vertex.vec4 dEQP-GLES3.functional.shaders.builtin_functions.precision.mix.highp_fragment.scalar dEQP-GLES3.functional.shaders.builtin_functions.precision.mix.highp_fragment.vec2 dEQP-GLES3.functional.shaders.builtin_functions.precision.mix.highp_fragment.vec3 dEQP-GLES3.functional.shaders.builtin_functions.precision.mix.highp_fragment.vec4 This is the same problem described for modf in bug 89645 but for mix. In gen6+, mix() is implemented as an lrp hardware operation, so I guess there is no way around this other than adding conditionals to check for infinities and resolve them directly. An alternative would be to implement it as gen5 (when lrp was not available in hardware) by doing x*(1-a)+y*a, which works better in some cases but still produces NaN for some (specifically when we need to multiply infinity with 0). This method should have a performance penalty.
These tests now all pass after commit 6c1b3db5fb439806b9b67442f1042615ffa32816 Author: Pyry Haulos <phaulos@google.com> Date: Fri May 29 14:06:53 2015 -0700 Allow alternative mix() implementation Some compilers translate mix(a, b, x) to a + (b - a)*x which produces slightly different results than the form a*(1 - x) + b*x suggested by the GLSL specification. This change relaxes tests to allow both forms. Bug: 21110253 Change-Id: I3af056145ef8e64c0fc998302770fd38d105481a
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.