Project

General

Profile

Actions

Bug #2826

closed

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

Added by pespin about 6 years ago. Updated about 5 years 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.


Files

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 armResolvedpespin12/07/2017

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

Actions
Actions #1

Updated by pespin about 6 years ago

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

Updated by pespin about 6 years ago

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

Updated by ttsou about 6 years 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.

Actions #4

Updated by pespin about 6 years 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

Actions #5

Updated by pespin over 5 years ago

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

Actions #6

Updated by laforge over 5 years ago

  • Assignee changed from ttsou to tnt
Actions #7

Updated by laforge over 5 years ago

  • Priority changed from Normal to High
Actions #8

Updated by tnt over 5 years 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.

Actions #9

Updated by tnt over 5 years 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.

Actions #10

Updated by tnt about 5 years ago

  • Status changed from In Progress to Resolved
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)