<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - [llvmpipe] Mesa 18.1.2 fails lp_test_format, lp_test_arit, lp_test_blend, lp_test_printf, lp_test_conv tests" href="https://bugs.freedesktop.org/show_bug.cgi?id=106644#c41">Comment # 41</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - [llvmpipe] Mesa 18.1.2 fails lp_test_format, lp_test_arit, lp_test_blend, lp_test_printf, lp_test_conv tests" href="https://bugs.freedesktop.org/show_bug.cgi?id=106644">bug 106644</a> from <a class="email" href="mailto:sroland@vmware.com" title="Roland Scheidegger <sroland@vmware.com>"> Roland Scheidegger</a> <pre>(In reply to Ben Crocker from <a href="show_bug.cgi?id=106644#c40">comment #40</a>) > 'make check'/lp_test_arit fails in exactly the same way when I run it > on a ppc64le machine. That is sort of expected I guess. We only use "arch rounding" with either sse41 or altivec. sse2 has a special path too (as it can do float->int conversion with nearest rounding). All other architectures will do round via float->int conversion (by doing float add with +-0.5 depending on sign first) - look at lp_build_round. This will do nearest rounding, but not nearest even, which the test expects. I think this should not be a problem in practice. If your chip does have native rounding instructions, you could try forcing the same path as what we use with sse41 - which is using llvm.nearbyint (in theory I suppose it should work with architectures which don't support this natively, but if you're unlucky it will just try to call into some math lib which is definitely no good and will just crash, and even if it would work you don't want to do that). If it's natively supported, not only should this be more correct, but also be much faster.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>