Bug #2826
closed
osmo-trx: different output in convolve test between x86 vs neon vs neon-vfpv4
Added by pespin over 6 years ago.
Updated about 5 years ago.
Description
I attach the output while running convolve_test (previously in utils/ directory) on a x86 with ssse3 and sse4.1. Now that I am implementing the infrastructure to run tests in ARM (see #2721), I found out that the output for this test is different in neon and neon-vfpv4 cases. The output is also different between the 2 neon ones. The arm testsuite.log files contains the diff aginst the x86 one (as it was the first one I used and the tool was initially wrote against it, it's the "expected" output").
I don't know if that's expected or if it's actually a bug. Assigning to Tom as he seems to be the one knowing more about this topic and who wrote the initial code for ARM.
Files
- Related to Bug #2721: OsmoTRX build verification job for arm added
- Related to Bug #2828: some osmo-trx tests failing in i586 OBS machine added
I still need to look into the specific numbers as well as reproduce the issue locally, however, I suspect the issue relates to IEEE-754 floating point conformance.
The ARMv7 NEON instruction set is not IEEE-754 compliant, which can very well lead to inconsistent floating point output across builds.
An interesting question would be if the test fails on ARMv8 where the NEON instruction set is IEEE-754 compliant.
I will have more details shortly.
ttsou friendly ping in case you forgot about this topic :-)
- Assignee changed from ttsou to tnt
- Priority changed from Normal to High
- Status changed from New to In Progress
Looking at that now ...
I mean direct exact text compare for such kind of test is never going to work because of the IEEE precision ... sometimes because of non-perfect compliant operation, or because we purposefully do a faster less precise operation, or because operations in different orders, ... and so in either case you convole_test should have the test vector and expected results built-in and do the compare internally tolerating small deltas (sometime like X% deviation + a small epsilon).
But looking at the logs posted, some of the deviations seems a bit large, so I'll be checking that first.
Ok.
- Removed unused / unsupported features from the codebase
- Reworked the convole_test utility to be more useful and consistent across platform
- That new test utility actually uncovered a bug in the neon vfp4 implementation, so fixed that.
- Re-enabled convolve_test by default.
All pushed on gerrit for review.
- Status changed from In Progress to Resolved
Also available in: Atom
PDF
