[opus] [RFC PATCHv1] cover: celt_pitch_xcorr: Introduce ARM neon intrinsics

Peter Robinson pbrobinson at gmail.com
Tue Nov 25 07:44:31 PST 2014

>> > Also is there plans to make the NEON optimisations on ARMv7 run time
>> > detectable like they have in cairo/pixman? For generic distributions
>> > it would nice to be able to be able to enable them as they offer
>> > decent performance improvements but have the code fall back on devices
>> > that don't support NEON.
>> Yep, adding support for ARMv8 is the final objective. I did not want to introduce too many changes in the first shot... and hence only introduced for ARMv7. In theory, most of the code (neon intrinsic code) in this patch should remain unchanged for ARMv8. Only the mechanism by which neon/asimd presence is detected during runtime and the flags used during compile are the only ones that should change. I will work on this once this patch gets reviewed and accepted. I made sure these changes are fairly localized.
>> And yes, this patch also supports runtime detection of neon. Actually, most of code to do run time detection of neon was already there in the project before this patch. I just re-used the infrastructure.
> ARMv8 shouldn’t need Neon detection at all — Neon is a mandatory part of the ARMv8 architecture, unlike ARMv7, where it’s optional.  It looks like this is what the configure script is already doing — arm64 sets rtcd_support to no.

My question about run time detection was limited for ARMv7 where it's
a valid requirement, agreed that it's not an issue for ARMv8

> I believe iOS, Windows RT/Windows Phone 8, and Blackberry 10 all require CPU support for Neon when running on ARMv7+ platforms, so detection shouldn’t be necessary there either.  The configure script should probably default rtcd_support accordingly, but configuring with --disable-rtcd should be sufficient to build on these platforms, regardless.

I'm mostly concerned about Linux distros where there's a mish mash of
options and a number of ARMv7 SoCs that don't have NEON so I'd like to
see it enabled and used by default but have appropriate fall back so
it doesn't break those SoCs without it.


More information about the opus mailing list