search for: arm_silk_map

It's unnecessary, and isn't defined correctly on floating-point. This makes us correctly use Neon functions (in floating-point mode) on platforms where Neon is detected by RTCD. --- silk/arm/arm_silk_map.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/silk/arm/arm_silk_map.c b/silk/arm/arm_silk_map.c index 53a60a0..04767b5 100644 --- a/silk/arm/arm_silk_map.c +++ b/silk/arm/arm_silk_map.c @@ -48,7 +48,7 @@ void (*const SILK_BIQUAD_ALT_STRIDE2_IMPL[OPUS_ARCHMASK + 1])(...

Thank Jonathan! I'll fix the MAY_HAVE_NEON() in silk/arm/arm_silk_map.c Linfeng On Thu, Jun 1, 2017 at 3:34 PM, Jonathan Lennox <jonathan at vidyo.com> wrote: > Semantically, OPUS_ARM_MAY_HAVE_NEON is supposed to mean the compiler > supports, and the CPU may support, Neon assembly code, which isn’t > necessarily the same thing as the compiler suppor...

...tangled and confusing, but what you’ll > find is that the MAY_HAVE_NEON macro isn’t used in the jump tables for the > two Neon intrinsics functions (silk_NSQ_noise_shape_feedback_loop_neon > and celt_pitch_xcorr_float_neon) which are used in a floating-point neon > build. See silk/arm/arm_silk_map.c and celt/arm/arm_celt_map.c. > > So long as OPUS_ARM_MAY_HAVE_NEON_INTR and OPUS_HAVE_RTCD are set in > config.h, it’ll pick up those functions, and check for them using RTCD. > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/p...

...onding unit test. --- silk/LPC_analysis_filter.c | 8 +- silk/SigProc_FIX.h | 8 +- silk/arm/LPC_analysis_filter_arm.h | 60 +++++++ silk/arm/LPC_analysis_filter_neon_intr.c | 176 +++++++++++++++++++++ silk/arm/arm_silk_map.c | 14 ++ .../test_unit_optimization_LPC_analysis_filter.c | 85 ++++++++++ silk_headers.mk | 1 + silk_sources.mk | 1 + tests/test_unit_optimization.c | 2 + 9 files cha...

Created corresponding unit test, and the optimization is bit exact with C function. --- silk/SigProc_FIX.h | 7 ++- silk/arm/arm_silk_map.c | 12 ++++ silk/arm/inner_prod_aligned_arm.h | 58 +++++++++++++++++++ silk/arm/inner_prod_aligned_neon_intr.c | 66 ++++++++++++++++++++++ silk/enc_API.c | 2 +- silk/inner_prod_aligned.c...

..., Neon assembly code, which isn’t necessarily the same thing as the compiler supporting Neon intrinsics. (The Visual Studio ARM compiler, for instance, supports intrinsics but not assembly.) So I don’t think this patch is the right solution. Instead, I think the problem is actually that silk/arm/arm_silk_map.c uses the MAY_HAVE_NEON macro, which it shouldn’t be using. If that file were changed so that the jump tables just listed the _neon versions of the functions directly, you’d get the speedup you’re looking for. On Jun 1, 2017, at 6:03 PM, Linfeng Zhang <linfengz at google.com<mailto:linfen...

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

...least the comments in that file > should be updated to indicate the register that’s used to pass it in, > and that it’s ignored. > > 2. In the 0003- patch, you shouldn’t use the MAY_HAVE_NEON macro in > your new arm_celt_map tables, for the same reason we didn’t want it > in the arm_silk_map tables. I have no further issues with your patches, so once you address the two issues Jonathan pointed out, I'll be able to merge them. Cheers, Jean-Marc > > Out of curiosity, what’s the CPU in the Chromebook you’re using to > test? > >> On Jun 1, 2017, at 6:33 PM, Lin...

Hi, Attached are 5 patches related to celt_inner_prod() and dual_inner_prod() NEON intrinsics optimization. In 0004-Optimize-floating-point-celt_inner_prod-and-dual_inn.patch, the optimization changed the order of floating-point inner products, which will change the results. I created celt_inner_prod_neon_float_c_simulation() and dual_inner_prod_neon_float_c_simulation() to simulate the order

Hi all, I'm sending patch "Optimize silk_warped_autocorrelation_FIX() for ARM NEON" in an separate email. It is based on Tim’s aarch64v8 branch https://git.xiph.org/?p=users/tterribe/opus.git;a=shortlog;h=refs/heads/aarch64v8 Thanks for your comments. Linfeng

...re of this is pretty tangled and confusing, but what you’ll find is that the MAY_HAVE_NEON macro isn’t used in the jump tables for the two Neon intrinsics functions (silk_NSQ_noise_shape_feedback_loop_neon and celt_pitch_xcorr_float_neon) which are used in a floating-point neon build. See silk/arm/arm_silk_map.c and celt/arm/arm_celt_map.c. So long as OPUS_ARM_MAY_HAVE_NEON_INTR and OPUS_HAVE_RTCD are set in config.h, it’ll pick up those functions, and check for them using RTCD. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/opus/attac...

...the assembly functions, but at least the comments in that file should be updated to indicate the register that’s used to pass it in, and that it’s ignored. 2. In the 0003- patch, you shouldn’t use the MAY_HAVE_NEON macro in your new arm_celt_map tables, for the same reason we didn’t want it in the arm_silk_map tables. Out of curiosity, what’s the CPU in the Chromebook you’re using to test? > On Jun 1, 2017, at 6:33 PM, Linfeng Zhang <linfengz at google.com> wrote: > > Hi, > > Attached are 5 patches related to celt_inner_prod() and dual_inner_prod() NEON intrinsics optimization....

...ile > > should be updated to indicate the register that’s used to pass it in, > > and that it’s ignored. > > > > 2. In the 0003- patch, you shouldn’t use the MAY_HAVE_NEON macro in > > your new arm_celt_map tables, for the same reason we didn’t want it > > in the arm_silk_map tables. > > I have no further issues with your patches, so once you address the two > issues Jonathan pointed out, I'll be able to merge them. > > Cheers, > > Jean-Marc > > > > > Out of curiosity, what’s the CPU in the Chromebook you’re using to >...

...r results on floating-point. --- silk/NSQ_del_dec.c | 6 +- silk/SigProc_FIX.h | 4 +- silk/arm/NSQ_del_dec_arm.h | 88 ++ silk/arm/NSQ_del_dec_neon_intr.c | 1125 +++++++++++++++++++++++ silk/arm/arm_silk_map.c | 23 + silk/main.h | 6 +- silk/mips/NSQ_del_dec_mipsr1.h | 2 +- silk/tests/test_unit_optimization_NSQ_del_dec.c | 142 +++ silk/x86/NSQ_del_dec_sse.c | 6 +- silk/x86/main_sse.h...

NSQ_LPC_BUF_LENGTH is independent of DECISION_DELAY. --- silk/define.h | 4 ---- 1 file changed, 4 deletions(-) diff --git a/silk/define.h b/silk/define.h index 781cfdc..1286048 100644 --- a/silk/define.h +++ b/silk/define.h @@ -173,11 +173,7 @@ extern "C" #define MAX_MATRIX_SIZE MAX_LPC_ORDER /* Max of LPC Order and LTP order */ -#if( MAX_LPC_ORDER >

I rebased my previous 3 patches to the current master with minor changes. Patches 1 to 3 replace all my previous submitted patches. Patches 4 and 5 are new. Thanks, Linfeng Zhang

Following Tim's comments, here are my reworked patches for the Neon intrinsic function patches of of my Aarch64 patchset, i.e. replacing patches 5-8 of the v2 series. Patches 1-4 and 9-18 of the old series still apply unmodified. The one new (as opposed to changed) patch is the first one in this series, to add named constants for the ARM architecture variants. There are also some minor code