List of affected tests: dEQP-GLES3.functional.shaders.builtin_functions.precision.tanh.highp_vertex.scalar dEQP-GLES3.functional.shaders.builtin_functions.precision.tanh.highp_vertex.vec2 dEQP-GLES3.functional.shaders.builtin_functions.precision.tanh.highp_vertex.vec3 dEQP-GLES3.functional.shaders.builtin_functions.precision.tanh.highp_vertex.vec4 dEQP-GLES3.functional.shaders.builtin_functions.precision.tanh.highp_fragment.scalar dEQP-GLES3.functional.shaders.builtin_functions.precision.tanh.highp_fragment.vec2 dEQP-GLES3.functional.shaders.builtin_functions.precision.tanh.highp_fragment.vec3 dEQP-GLES3.functional.shaders.builtin_functions.precision.tanh.highp_fragment.vec4 tanh is implemented as: body.emit(ret(div(sub(exp(x), exp(neg(x))), add(exp(x), exp(neg(x)))))); For some values of x this leads to a infinity values in the denominator and numerator. The division of such values leads to a NaN instead of 1.0 (the result expected by dEQP and the result of tanh from libc too). I suppose we can add as-hoc code to handle these cases and produce a result of 1.0 directly in software when we detect them, but I wonder if it is worth the cost.
I have not seen a single (non-test) shader that uses tanh(), so I'm not worried about any performance impact. Emitting extra instructions to compute the correct value sounds sensible.
glibc's tanh() returns 1.0f if x > 22.0.
I believe these tests were stricken from the Android must-pass list, but I think they still may exist in the Vulkan CTS.
I think these were fixed by commit d4983390a869c3051929858a8b783be53d46b722 Author: Haixia Shi <hshi@chromium.org> Date: Thu Dec 8 17:41:02 2016 -0800 compiler/glsl: fix precision problem of tanh (they at least pass for me as of commit d49d275c41)
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.