mesa: 35ade36c88e5aaa0b18c3cc911d9a4de3a60a80b (master 11.3.0-devel) $ ./bin/shader_runner generated_tests/spec/glsl-1.30/execution/built-in-functions/fs-roundEven-float.shader_test -auto Probe color at (36,0) Expected: 0.000000 1.000000 0.000000 1.000000 Observed: 1.000000 0.000000 0.000000 1.000000 Probe color at (60,0) Expected: 0.000000 1.000000 0.000000 1.000000 Observed: 1.000000 0.000000 0.000000 1.000000 PIGLIT: {"result": "fail" } e4f01da15d8c6ce3e8c77ff3ff3d2ce2574a3f7b is the first bad commit commit e4f01da15d8c6ce3e8c77ff3ff3d2ce2574a3f7b Author: Jose Fonseca <jfonseca@vmware.com> Date: Fri Apr 1 11:50:28 2016 +0100 gallivm: Prefer backend agnostic intrinsic for rounding. We could unconditionally use these instrinsics, but performance with SSE2 would suck, as LLVM falls back to calling libm. lp_test_arit. Reviewed-by: Roland Scheidegger <sroland@vmware.com> :040000 040000 0f7b55e9ae1e5faa3e9ee24d5ab66605e5be096d 09bf79b798b6210887add905b1f91d8587b58bc2 M src bisect run success
Hmm I looked at this and the round llvm intrinsic doesn't actually do something useful (or at least definitely not what we want). The code generated is awful and apparently wrong. llvm.round will do per-element calls into __roundf which is horrible. I think that's because libm round is specced to do round-nearest-away-from-zero, which is both not what we want and what we can't do natively with the roundps instruction. I'll fix this...
Fixed by cb438d8b3e1e32faf714f22b308c8f9c5506209b.
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.