search for: rtcd

...ou posted your patch before I posted mine, so probably I should be the one on the hook to rebase after your fix goes in. Looking over your patch quickly, I don?t think any of my changes should be that difficult to merge with yours. I haven?t studied your patch in depth yet. Does Ne10 use its own RTCD code, or do you use Opus?s? On Mar 3, 2015, at 5:18 PM, Viswanath Puttagunta <viswanath.puttagunta at linaro.org> wrote: > Hello Jonathan, > > I am unable to apply your patch cleanly on tip. > > Timothy/opus-dev, > > This patch has some conflicts with my ARM patch...

...he hook to rebase after your fix goes in. Looking over your patch quickly, I don?t think any of my changes should be that difficult to merge with yours. >> Yeah.. trivial merge issues.. shouldn't take too long to resolve. I haven?t studied your patch in depth yet. Does Ne10 use its own RTCD code, or do you use Opus?s? >> Not using Ne10's RTCD feature at the moment.. using Opus's rtcd. libopus RTCD for linux/armv7 will not work for aarch64. It needs to be updated (or just disabled if system built for aarch64 since Neon support is mandatory)... It is in my todo list.. My...

..., I don?t think any of my changes should be > >> that difficult to merge with yours. > > > >>> Yeah.. trivial merge issues.. shouldn't take too long to resolve. > >> > >> > >> I haven?t studied your patch in depth yet. Does Ne10 use its own RTCD > >> code, or do you use Opus?s? > > > >>> Not using Ne10's RTCD feature at the moment.. using Opus's rtcd. libopus > >>> RTCD for linux/armv7 will not work for aarch64. It needs to be updated (or > >>> just disabled if system built for aar...

Thanks for the prompt and helpful replies. Built with --enable-custom-modes --disable-static --enable-intrinsics --enable-rtcd --enable-float-approx All worked. Only thing odd, rtcd was not enabled: Floating point support: ........ yes Fast float approximations: ..... yes Fixed point debugging: ......... no Inline Assembly Optimizations: . No inline ASM for your platform, please send patches...

...your fix goes in. > Looking over your patch quickly, I don?t think any of my changes should be > that difficult to merge with yours. > >> Yeah.. trivial merge issues.. shouldn't take too long to resolve. > > I haven?t studied your patch in depth yet. Does Ne10 use its own RTCD > code, or do you use Opus?s? > >> Not using Ne10's RTCD feature at the moment.. using Opus's rtcd. libopus RTCD for linux/armv7 will not work for aarch64. It needs to be updated (or just disabled if system built for aarch64 since Neon support is mandatory)... It is in my todo l...

...ooking over your patch quickly, I don?t think any of my changes should be >> that difficult to merge with yours. > >>> Yeah.. trivial merge issues.. shouldn't take too long to resolve. >> >> >> I haven?t studied your patch in depth yet. Does Ne10 use its own RTCD >> code, or do you use Opus?s? > >>> Not using Ne10's RTCD feature at the moment.. using Opus's rtcd. libopus >>> RTCD for linux/armv7 will not work for aarch64. It needs to be updated (or >>> just disabled if system built for aarch64 since Neon support i...

Nit: in dual_inner_prod_sse, why not do both horizontal sums at the same time? As in: xsum1 = _mm_add_ps(_mm_movelh_ps(xsum1, xsum2), _mm_movehl_ps(xsum2, xsum1)); xsum1 = _mm_add_ps(xsum1, _mm_shuffle_ps(xsum1, xsum1, 0xf5)); _mm_store_ss(xy1, xsum1); _mm_store_ss(xy2, _mm_movehl_ps(xsum1, xsum1)); --John

...sts/test_unit_dft.c b/celt/tests/test_unit_dft.c index bcee440..484dc57 100644 --- a/celt/tests/test_unit_dft.c +++ b/celt/tests/test_unit_dft.c @@ -47,8 +47,7 @@ #if defined(OPUS_X86_MAY_HAVE_SSE2) || defined(OPUS_X86_MAY_HAVE_SSE4_1) # include "x86/x86cpu.c" -#elif defined(OPUS_HAVE_RTCD) && \ - (defined(OPUS_ARM_ASM) || defined(OPUS_ARM_MAY_HAVE_NEON_INTR)) +#elif defined(OPUS_ARM_ASM) || defined(OPUS_ARM_MAY_HAVE_NEON_INTR) # include "arm/armcpu.c" # include "celt_lpc.c" # include "pitch.c" diff --git a/celt/tests/test_unit_mathops...

...sts/test_unit_dft.c b/celt/tests/test_unit_dft.c index bcee440..484dc57 100644 --- a/celt/tests/test_unit_dft.c +++ b/celt/tests/test_unit_dft.c @@ -47,8 +47,7 @@ #if defined(OPUS_X86_MAY_HAVE_SSE2) || defined(OPUS_X86_MAY_HAVE_SSE4_1) # include "x86/x86cpu.c" -#elif defined(OPUS_HAVE_RTCD) && \ - (defined(OPUS_ARM_ASM) || defined(OPUS_ARM_MAY_HAVE_NEON_INTR)) +#elif defined(OPUS_ARM_ASM) || defined(OPUS_ARM_MAY_HAVE_NEON_INTR) # include "arm/armcpu.c" # include "celt_lpc.c" # include "pitch.c" diff --git a/celt/tests/test_unit_mathops...

..._ARM_MAY_HAVE_MEDIA) +# define celt_pitch_xcorr_media MAY_HAVE_EDSP(celt_pitch_xcorr) +#endif # if defined(OPUS_ARM_MAY_HAVE_EDSP) opus_val32 celt_pitch_xcorr_edsp(const opus_val16 *_x, const opus_val16 *_y, opus_val32 *xcorr, int len, int max_pitch); # endif -# if !defined(OPUS_HAVE_RTCD) -# define OVERRIDE_PITCH_XCORR (1) +#if defined(OPUS_ARM_PRESUME_NEON) + +#define OVERRIDE_PITCH_XCORR (1) # define celt_pitch_xcorr(_x, _y, xcorr, len, max_pitch, arch) \ - ((void)(arch),PRESUME_NEON(celt_pitch_xcorr)(_x, _y, xcorr, len, max_pitch)) -# endif -#endif /* End CPU_ARM */ + (...

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

...re, 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 patchs...

...patch goes into opus first. Regards, Vish On 1 March 2015 at 20:47, Jonathan Lennox <jonathan at vidyo.com> wrote: > The attached patch cleans up Opus's x86 intrinsics configury. > > It: > * Makes ?enable-intrinsics work with clang and other non-GCC compilers > * Enables RTCD for the floating-point-mode SSE code in Celt. > * Disables use of RTCD in cases where the compiler targets an instruction > set by default. > * Enables the SSE4.1 Silk optimizations that apply to the common parts of > Silk when Opus is built in floating-point mode, not just in fixed-poi...

> On Nov 16, 2015, at 6:27 PM, Sean Darcy <seandarcy2 at gmail.com> wrote: > > Thanks for the prompt and helpful replies. > > Built with --enable-custom-modes --disable-static --enable-intrinsics --enable-rtcd --enable-float-approx > > All worked. Only thing odd, rtcd was not enabled: > > Floating point support: ........ yes > Fast float approximations: ..... yes > Fixed point debugging: ......... no > Inline Assembly Optimizations: . No inline ASM for your...

...n CPU architecture also implies all lower-capability architectures. Unfortunately, the ARM opus_cpu_capabilities function only currently checks for those architectures that are enabled in the configuration, and thus —disable-asm — or a floating-point build — doesn’t check for Media or EDSP. Thus, RTCD for these configurations doesn’t end up taking advantage of Neon Intrinsics support. The attached patch should fix this, by checking for a CPU feature if the feature or any higher feature is enabled in the configuration. -------------- next part -------------- A non-text attachment was scrubbed.....

...fine OPUS_ARM_PRESUME_NEON and OPUS_ARM_PRESUME_NEON_INTR if you’re building for armv7, and OPUS_ARM_PRESUME_NEON_INTR for arm64 (since every Apple armv7 CPU has supported Neon, and of course arm64 supports it though the assembler syntax is different). This should be slightly faster than using RTCD, since the Neon functions can be direct calls instead of indirect ones. Do those defines not get set for you, or is there some Neon code that doesn’t get invoked properly with the PRESUMEs? > On May 24, 2018, at 2:37 PM, Victor Cherepanov > <victor.v.cherepanov at gmail.com> wrote:...

Hi, ./configure --build x86_64-unknown-linux-gnu --host arm-linux-gnueabihf --disable-assertions --disable-check-asm --enable-intrinsics CFLAGS=-O3 --disable-shared When configuring with floating-point and intrinsics enabled as above, the generated config.h only has OPUS_ARM_MAY_HAVE_NEON_INTR defined (to 1), with /* #undef OPUS_ARM_ASM */ /* #undef OPUS_ARM_INLINE_ASM */ /* #undef

--- configure.ac | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index f267ef7..606511b 100644 --- a/configure.ac +++ b/configure.ac @@ -190,8 +190,8 @@ AC_ARG_ENABLE([rtcd], [enable_rtcd=yes]) AC_ARG_ENABLE([intrinsics], - [AS_HELP_STRING([--enable-intrinsics], [Enable intrinsics optimizations for ARM(float) X86(fixed)])],, - [enable_intrinsics=no]) + [AS_HELP_STRING([--disable-intrinsics], [Disable intrinsics optimizations for ARM(float) X86(fixed)]...

and rtcd disabled (CFLAGS=-mfpu=neon) broken since: cfdaf365 Optimize silk_NSQ_del_dec() for ARM NEON --- silk/arm/NSQ_del_dec_arm.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/silk/arm/NSQ_del_dec_arm.h b/silk/arm/NSQ_del_dec_arm.h index c62b5055..9e76e169 100644 --- a/silk/arm/NS...

...tecture, 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 re...