mesa: 4825264f75c83576f251290547f121f066b46a70 (master 12.1.0-devel) $ ./bin/linestipple -auto Testing Baseline: PIGLIT: {"subtest": {"Baseline" : "pass"}} Testing Restarting lines within a single Begin-End block: PIGLIT: {"subtest": {"Restarting lines within a single Begin-End block" : "pass"}} Testing Line strip: Probe color at (34,20) Expected: 0.000000 0.000000 0.000000 Observed: 1.000000 1.000000 0.000000 PIGLIT: {"subtest": {"Line strip" : "fail"}} Testing Line loop: PIGLIT: {"subtest": {"Line loop" : "pass"}} Testing Factor 2x: PIGLIT: {"subtest": {"Factor 2x" : "pass"}} Testing Factor 3x: PIGLIT: {"subtest": {"Factor 3x" : "pass"}} PIGLIT: {"result": "fail" } 320d1191c61a0a82444605c12e5c4b2ee0b241eb is the first bad commit commit 320d1191c61a0a82444605c12e5c4b2ee0b241eb Author: Jose Fonseca <jfonseca@vmware.com> Date: Mon Apr 4 00:05:33 2016 +0100 gallivm: Use llvm.fmuladd.*. Reviewed-by: Roland Scheidegger <sroland@vmware.com> :040000 040000 31dca10c80a2741d596cb6d81cd6015e1312dc2e e24948d177adab4b2fc35cd186d8dbffec3f3a0d M src bisect run success
I suppose I missed that when I did a piglit run... This is fairly interesting, it seems to be due to inaccurate float math. The stipple code gets for position x0,x1 10.5, 34.5 leading to a length 24. However, with the MADs used for vertex transform replaced by fmas, I get position 10.500002, 34.500000 instead. Hence length 23.999998. And subsequently patterns getting different (I think it makes no difference on the first segment, but the second due to the stipple->counter += length line). Not sure though why the results would be seemingly less accurate with fma. (And not sure there shouldn't be some different behavior wrt rounding in the line stipple code?)
Althought generally FMA is more precise, it's possible that it give less precise results. Especially when dealing with things like whole integers, it's quite possible that the lower precision of a non-fused MAD ends up "snapping" things to the right values. Whereas FMA preserves any intermediate rounding error in the final result. From my POV, the issue is either: - llvmpipe/draw stipple implementation needs better rounding (eg.g, RoundToNearest as opposed to Truncate) - the linestipple piglit test needs to be updated to not rely on precise rounding of the stipple. Either way I doubt the solution is to avoid FMA.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/241.
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.