Project

General

Profile

Bug #2826

osmo-trx: different output in convolve test between x86 vs neon vs neon-vfpv4

Added by pespin over 1 year ago. Updated 5 months ago.

Status:
Resolved
Priority:
High
Assignee:
Category:
-
Target version:
-
Start date:
01/11/2018
Due date:
% Done:

0%

Spec Reference:

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.

testsuite.log-neon testsuite.log-neon 2.86 KB pespin, 01/11/2018 05:14 PM
testsuite.log-neon-vfpv4 testsuite.log-neon-vfpv4 7.02 KB pespin, 01/11/2018 05:15 PM
convolve_test.ok convolve_test.ok 7.6 KB pespin, 01/11/2018 05:15 PM

Related issues

Related to OsmoTRX - Bug #2721: OsmoTRX build verification job for armResolved12/07/2017

Related to OsmoTRX - Bug #2828: some osmo-trx tests failing in i586 OBS machineResolved01/13/2018

History

#1 Updated by pespin over 1 year ago

  • Related to Bug #2721: OsmoTRX build verification job for arm added

#2 Updated by pespin over 1 year ago

  • Related to Bug #2828: some osmo-trx tests failing in i586 OBS machine added

#3 Updated by ttsou over 1 year ago

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.

#4 Updated by pespin over 1 year ago

Thanks for looking into it. If you have time and didn't see it yet, please read https://lists.osmocom.org/pipermail/openbsc/2018-January/011655.html

#5 Updated by pespin 9 months ago

ttsou friendly ping in case you forgot about this topic :-)

#6 Updated by laforge 8 months ago

  • Assignee changed from ttsou to tnt

#7 Updated by laforge 7 months ago

  • Priority changed from Normal to High

#8 Updated by tnt 6 months ago

  • 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.

#9 Updated by tnt 6 months ago

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.

#10 Updated by tnt 5 months ago

  • Status changed from In Progress to Resolved

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)