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

On Nov 25, 2014, at 10:07 AM, Viswanath Puttagunta <viswanath.puttagunta at
linaro.org> wrote:
> 
> > 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.

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.

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

Peter

On Nov 25, 2014, at 10:44 AM, Peter Robinson <pbrobinson at gmail.com>
wrote:
>>>> 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.
Oh, sure, Linux and Android need it ? they?re the primary use case for run-time
Neon detection.  The existing detection infrastructure in silk/arm/armcpu.c
seems fine for that case, though.

On 25 November 2014 at 09:39, Jonathan Lennox <jonathan at vidyo.com>
wrote:
>
> On Nov 25, 2014, at 10:07 AM, Viswanath Puttagunta <
viswanath.puttagunta at linaro.org> wrote:
>>
>> > 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.
As I understand, your statement for ARMv8 is true for AAarch64 mode. But
for ARMv8 in AAarch32 mode, neon is still optional (although I haven't
heard of an implementation that does not support NEON even in AAarch32
mode). So, for AArch64 mode, I think rtcd can be disabled. Also, even the
neon detection procedure currently in opus will not work on ARMv8 AArch32
mode. Please refer
http://community.arm.com/groups/android-community/blog/2014/10/10/runtime-detection-of-cpu-features-on-an-armv8-a-cpu
This is one of my todo lists after this patchset gets reviewed and accepted.

It looks like this is what the configure script is already doing ? arm64
sets rtcd_support to no.
>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/opus/attachments/20141125/7b108c8b/attachment.htm

On 25 November 2014 at 10:11, Viswanath Puttagunta
<viswanath.puttagunta at linaro.org> wrote:
>
> On 25 November 2014 at 09:39, Jonathan Lennox <jonathan at vidyo.com>
wrote:
> >
> > On Nov 25, 2014, at 10:07 AM, Viswanath Puttagunta
<viswanath.puttagunta at linaro.org> wrote:
> >>
> >> > 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.
> As I understand, your statement for ARMv8 is true for AAarch64 mode. But
for ARMv8 in AAarch32 mode, neon is still optional (although I haven't heard
of an implementation that does not support NEON even in AAarch32 mode). So, for
AArch64 mode, I think rtcd can be disabled. Also, even the neon detection
procedure currently in opus will not work on ARMv8 AArch32 mode. Please refer
>
http://community.arm.com/groups/android-community/blog/2014/10/10/runtime-detection-of-cpu-features-on-an-armv8-a-cpu
> This is one of my todo lists after this patchset gets reviewed and
accepted.
>
> It looks like this is what the configure script is already doing ? arm64
sets rtcd_support to no.
I can't find any evidence of this in configure.ac. Can you please
point me to where rtcd_support is set to no for armv8 (AAarch64)?
> >
> > 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.
>