Change in libosmocore[master]: libomsocoding: NEON viterbi acceleration

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.

laforge gerrit-no-reply at lists.osmocom.org
Thu Jul 23 08:26:09 UTC 2020


laforge has posted comments on this change. ( https://gerrit.osmocom.org/c/libosmocore/+/19372 )

Change subject: libomsocoding: NEON viterbi acceleration
......................................................................


Patch Set 1: Code-Review-1

(3 comments)

-1 just for the legality of the copyright notice. the other comment is not worth a -1.

https://gerrit.osmocom.org/c/libosmocore/+/19372/1//COMMIT_MSG 
Commit Message:

https://gerrit.osmocom.org/c/libosmocore/+/19372/1//COMMIT_MSG@11 
PS1, Line 11: Although autodetection according to __ARM_NEON would work because this
            : is only defined if the fpu is neon neon-fp16 neon-vfpv3 eon-vfpv4
            : neon-fp-armv8 crypto-neon-fp-armv8 doing that would lead to a unknown
            : performance impact, so it needs to be enabled manually.
I don't like this kind of approach.  We have auto-detection for x86 SIMD instructions, and we should try to align with that for NEON.  The detection would only have to be done once at startup, right?  Projects like ffmpeg are doing run-time detection of CPU features for a very long time.

So without even knowing how bad the impact would be, I'm not sure we should disable it.

The only question would be whether or not we should enable it by default in all our builds anyway.  I'm not sure who is running osmo-bts-trx on an ARM without NEON support.  We have plenty of osmo-bts-sysmo on old cores, probably also -octphy. But we've never heard of an osmo-bts-trx user who doesn't have a modern, NEON enabled core, AFAICT.


https://gerrit.osmocom.org/c/libosmocore/+/19372/1/src/conv_acc_neon.c 
File src/conv_acc_neon.c:

https://gerrit.osmocom.org/c/libosmocore/+/19372/1/src/conv_acc_neon.c@5 
PS1, Line 5: Copyright (C) 2020 Eric Wild <ewild at sysmocom.de>
erm, coypright by sysmocom, Author is you. At least as long as it was done during work hours :P


https://gerrit.osmocom.org/c/libosmocore/+/19372/1/src/conv_acc_neon_impl.h 
File src/conv_acc_neon_impl.h:

https://gerrit.osmocom.org/c/libosmocore/+/19372/1/src/conv_acc_neon_impl.h@5 
PS1, Line 5:  
same here of course



-- 
To view, visit https://gerrit.osmocom.org/c/libosmocore/+/19372
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings

Gerrit-Project: libosmocore
Gerrit-Branch: master
Gerrit-Change-Id: I58ff2cb4ce3514f43390ff0a2121f81e6a4983b5
Gerrit-Change-Number: 19372
Gerrit-PatchSet: 1
Gerrit-Owner: Hoernchen <ewild at sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria <vyanitskiy at sysmocom.de>
Gerrit-Reviewer: laforge <laforge at osmocom.org>
Gerrit-Comment-Date: Thu, 23 Jul 2020 08:26:09 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: Yes
Gerrit-MessageType: comment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20200723/0a06401c/attachment.htm>


More information about the gerrit-log mailing list