search for: vld1_s16

...; + const int leftover = N & 7; + const opus_val16 *x = _x-ord; + VARDECL(opus_val16, rnum); + SAVE_STACK; + /* Extend rnum by 3 zeros to handle the case that (ord % 4) is non-zero. */ + ALLOC(rnum, ord+3, opus_val16); + for (i=0;i<ord-3;i+=4) + vst1_s16(rnum+i, vrev64_s16(vld1_s16(num+ord-i-4))); + for (;i<ord;i++) + rnum[i] = num[ord-i-1]; + rnum[ord] = rnum[ord+1] = rnum[ord+2] = 0; + (void)arch; + +#ifdef SMALL_FOOTPRINT + for (i=0;i<N-7;i+=8) + { + int16x8_t x_s16x8 = vld1q_s16(_x+i); + int32x4_t sum0_s32x4 = vshll_n_s16(vget_low_s16 (x_s16...

...ine with Mr. Zanelli's code: static inline void xcorr_kernel_neon(const opus_val16 *x, const opus_val16 *y, opus_val32 sum[4], int len) { int j; int32x4_t xsum1 = vld1q_s32(sum); int32x4_t xsum2 = vdupq_n_s32(0); for (j = 0; j < len-3; j += 4) { int16x4_t x0 = vld1_s16(x+j); int16x4_t y0 = vld1_s16(y+j); int16x4_t y3 = vld1_s16(y+j+3); int16x4_t y4 = vext_s16(y3,y3,1); xsum1 = vmlal_s16(xsum1,vdup_lane_s16(x0,0),y0); xsum2 = vmlal_s16(xsum2,vdup_lane_s16(x0,1),vext_s16(y0,y4,1)); xsum1 = vmlal_s16(xsum1,vdup_...

..._neon.h> static inline void xcorr_kernel(const opus_val16 *x, const opus_val16 *y, opus_val32 sum[4], int len) { int j; int32x4_t xsum1 = vld1q_s32(sum); int32x4_t xsum2 = vdupq_n_s32(0); for (j = 0; j < len-1; j += 2) { xsum1 = vmlal_s16(xsum1,vdup_n_s16(*x++),vld1_s16(y++)); xsum2 = vmlal_s16(xsum2,vdup_n_s16(*x++),vld1_s16(y++)); } if (j < len) { xsum1 = vmlal_s16(xsum1,vdup_n_s16(*x),vld1_s16(y)); } vst1q_s32(sum,vaddq_s32(xsum1,xsum2)); } Cheers, John Ridges

Hi JM, I have no doubt that Mr. Zanelli's NEON code is faster, since hand tuned assembly is bound to be faster than using intrinsics. However I notice that his code can also read past the y buffer. Cheers, --John On 6/6/2013 9:22 PM, Jean-Marc Valin wrote: > Hi John, > > Thanks for the two fixes. They're in git now. Your SSE version seems to > also be slightly faster than

Hi all, This is Linfeng Zhang from Google. I'll work on ARM NEON optimization in the next few months. I'm submitting 2 patches in the following couple of emails, which have the new created celt_fir_neon(). I revised celt_fir_c() to not pass in argument "mem" in Patch 1. If there are concerns to this change, please let me know. Many thanks to your comments. Linfeng Zhang

...line with Mr. Zanelli's code: static inline void xcorr_kernel_neon(const opus_val16 *x, const opus_val16 *y, opus_val32 sum[4], int len) { int j; int32x4_t xsum1 = vld1q_s32(sum); int32x4_t xsum2 = vdupq_n_s32(0); for (j = 0; j < len-3; j += 4) { int16x4_t x0 = vld1_s16(x+j); int16x4_t y0 = vld1_s16(y+j); int16x4_t y3 = vld1_s16(y+j+3); int16x4_t y4 = vext_s16(y3,y3,1); xsum1 = vmlal_s16(xsum1,vdup_lane_s16(x0,0),y0); xsum2 = vmlal_s16(xsum2,vdup_lane_s16(x0,1),vext_s16(y0,y4,1)); xsum1 = vmlal_s16(xsum1,vdup_...

...um, out + d, len - d, d, arch ); +#else + VARDECL(opus_int16, rB); + (void)arch; + SAVE_STACK; + + /* Extend rB by 3 zeros to handle the case that (d % 4) is non-zero. */ + ALLOC(rB, d + 3, opus_int16); + for (ix = 0; ix < d - 3; ix += 4) { + vst1_s16(rB + ix, vrev64_s16(vld1_s16(B + d - ix - 4))); + } + for (; ix < d; ix++) { + rB[ix] = B[d - ix - 1]; + } + rB[d] = rB[d + 1] = rB[d + 2] = 0; + + for (ix = d; ix < len - 7; ix += 8) { + int16x8_t in_s16x8 = vld1q_s16(in + ix); + int32x4_t out32_Q12_0_s32x4 = vshll_n_s16(vget...

...rnel(const opus_val16 *x, const opus_val16 > *y, opus_val32 sum[4], int len) > { > int j; > int32x4_t xsum1 = vld1q_s32(sum); > int32x4_t xsum2 = vdupq_n_s32(0); > > for (j = 0; j < len-1; j += 2) { > xsum1 = vmlal_s16(xsum1,vdup_n_s16(*x++),vld1_s16(y++)); > xsum2 = vmlal_s16(xsum2,vdup_n_s16(*x++),vld1_s16(y++)); > } > if (j < len) { > xsum1 = vmlal_s16(xsum1,vdup_n_s16(*x),vld1_s16(y)); > } > vst1q_s32(sum,vaddq_s32(xsum1,xsum2)); > } > > > Cheers, > John Ridges >...

...[1]), 3); + SUMM = vmlal_lane_s16(SUMM, YEXT[2], vget_high_s16(XX[0]), 3); + + YY[0] = YY[1]; + len -= 8; + } + + /* Consume 4 elements in x vector and 8 elements in y vector + * However, y[7] should not be accessed unless len > 4 + */ + if (len > 4) { + XX_2 = vld1_s16(xi); + xi += 4; + /* Consume XX_2[0:3] */ + SUMM = vmlal_lane_s16(SUMM, vget_low_s16(YY[0]), XX_2, 0); + + YEXT[0] = vext_s16(vget_low_s16(YY[0]), vget_high_s16(YY[0]), 1); + SUMM = vmlal_lane_s16(SUMM, YEXT[0], XX_2, 1); + + YEXT[1] = vext_s16(vget_low_s16(YY[0]), vge...

...[1]), 3); + SUMM = vmlal_lane_s16(SUMM, YEXT[2], vget_high_s16(XX[0]), 3); + + YY[0] = YY[1]; + len -= 8; + } + + /* Consume 4 elements in x vector and 8 elements in y vector + * However, y[7] should not be accessed unless len > 4 + */ + if (len > 4) { + XX_2 = vld1_s16(xi); + xi += 4; + /* Consume XX_2[0:3] */ + SUMM = vmlal_lane_s16(SUMM, vget_low_s16(YY[0]), XX_2, 0); + + YEXT[0] = vext_s16(vget_low_s16(YY[0]), vget_high_s16(YY[0]), 1); + SUMM = vmlal_lane_s16(SUMM, YEXT[0], XX_2, 1); + + YEXT[1] = vext_s16(vget_low_s16(YY[0]), vge...

...d3d5f 100644 --- a/configure.ac +++ b/configure.ac @@ -89,6 +89,23 @@ has_sse=no ) AC_MSG_RESULT($has_sse) +AC_MSG_CHECKING(for NEON in current arch/CFLAGS) +AC_LINK_IFELSE([ +AC_LANG_PROGRAM([[ +#include <arm_neon.h> +int32x4_t testfunc(int16_t *a, int16_t *b) { + return vmull_s16(vld1_s16(a), vld1_s16(b)); +} +]])], +[ +has_neon=yes +], +[ +has_neon=no +] +) +AC_MSG_RESULT($has_neon) + SAVE_CFLAGS="$CFLAGS" CFLAGS="$CFLAGS -fvisibility=hidden" AC_MSG_CHECKING(for ELF visibility) @@ -148,6 +165,15 @@ has_sse=no fi ]) +AC_ARG_ENABLE(neon, [ --enable-neon...

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

Should call celt_inner_prod(). --- celt/bands.c | 7 ++++--- celt/bands.h | 2 +- celt/celt_encoder.c | 6 +++--- celt/pitch.c | 2 +- src/opus_multistream_encoder.c | 2 +- 5 files changed, 10 insertions(+), 9 deletions(-) diff --git a/celt/bands.c b/celt/bands.c index bbe8a4c..1ab24aa 100644 --- a/celt/bands.c +++ b/celt/bands.c

...(FIXED_POINT) +#if defined(FIXED_POINT) +void xcorr_kernel_neon_fixed(const opus_val16 * x, const opus_val16 * y, opus_val32 sum[4], int len) +{ + int j; + int32x4_t a = vld1q_s32(sum); + //Load y[0...3] + //This requires len>0 to always be valid (which we assert in the C code). + int16x4_t y0 = vld1_s16(y); + y += 4; + + for (j = 0; j + 8 <= len; j += 8) + { + // Load x[0...7] + int16x8_t xx = vld1q_s16(x); + int16x4_t x0 = vget_low_s16(xx); + int16x4_t x4 = vget_high_s16(xx); + // Load y[4...11] + int16x8_t yy = vld1q_s16(y); + int16x4_t y4 = vget_low_s16(yy); + int16x4_t y8 = vget_hig...

From: Jyri Sarha <jsarha at ti.com> I optimized Speex resampler for NEON capable ARM CPUs. The first patch should speed up resampling on any platform that can spare the increased memory usage. It would be nice to have these merged to the master branch. Please let me know if there is anything I can do to help the the merge. The patches have been rebased on top of master branch in

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

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

Hi Timothy, As I mentioned earlier [1], I now fixed compile issues with fixed point and resubmitting the patch. I also have new patch that does intrinsics optimizations for celt_pitch_xcorr targetting aarch64. You can find my latest work-in-progress branch at [2] For reference, you can use the Ne10 pre-built libraries at [3] Note that I am working with Phil at ARM to get my patch at [4]

As promised, here's a re-send of all my Aarch64 patches, following comments by John Ridges. Note that they actually affect more than just Aarch64 -- other than the ones specifically guarded by AARCH64_NEON defines, the Neon intrinsics all also apply on armv7; and the OPUS_FAST_INT64 patches apply on any 64-bit machine. The patches should largely be independent and independently useful, other

Here are my aarch64 patches rebased to the current tip of Opus master. They're largely the same as my previous patch set, with the addition of the final one (the Neon fixed-point implementation of xcorr_kernel). This replaces Viswanath's Neon fixed-point celt_pitch_xcorr, since xcorr_kernel is used in celt_fir and celt_iir as well. These have been tested for correctness under qemu