search for: ne10_fft_c2c_1d_float32_neon

...I have already added support for scaled forward non-power-of-2 floating-point FFT: https://github.com/projectNe10/Ne10/commit/79c3d787302f8d74b9bcfe6545d487cdf1b101d9 Two flags are added to cfg structure: is_forward_scaled and is_backward_scaled. By setting is_forward_scaled to anything but zero, ne10_fft_c2c_1d_float32_neon will scale the output. So we can remove need for one buffer on stack mentioned below. As for the _t API style, it may confuse existing users if we provide two API for the same functionality or if we modify the existing API. How about we keep the typedefs in Opus? For example: typedef ne10_int32_t...

...float *out; > + int i; > + ALLOC(temp, st->nfft, ne10_fft_cpx_float32_t); > + ALLOC(tempin, st->nfft, ne10_fft_cpx_float32_t); This seems like a fairly large increase in peak stack usage (7.5 kB). Is there any chance of reducing this? For example, presumably the first thing ne10_fft_c2c_1d_float32_neon() does is bit-reverse the input... if it could be modified to do the scaling at the same time, that would get rid of one buffer. The other option is to make opus_fft's callers do it (clt_mdct_forward already does this in the C version). The other other option is to modify the API to take a...

...is the peak stack usage.... rest looks like fairly straight forward cleanup. Is the peak stack usage a complete blocker in current form? If it is indeed a blocker, would it be acceptable if we can reduce additional buffer requirement from 2 buffers (current) to 1, possibly by moving scaling inside ne10_fft_c2c_1d_float32_neon? (I will let Phil comment on if there is any reason not to do this.. and suggest any alternatives if necessary) I will work on fixing up code from opus side. Phil is one of developers/maintainers of opus. Please correct me if any of information below is inaccurate from a libNE10 change request pe...

...ed support for scaled forward non-power-of-2 floating-point FFT: > https://github.com/projectNe10/Ne10/commit/79c3d787302f8d74b9bcfe6545d487cdf1b101d9 > > Two flags are added to cfg structure: is_forward_scaled and is_backward_scaled. > By setting is_forward_scaled to anything but zero, ne10_fft_c2c_1d_float32_neon will > scale the output. So we can remove need for one buffer on stack mentioned below. Thanks Phil, I have tested this in my **local setup** and it works for **non-power-of-2**, mainly for nfft = 60, 120, 240, 480. But any reason why this functionality cannot be extended to power-of-2 as well?...

Viswanath Puttagunta wrote: > Is the peak stack usage a complete blocker in current form? Since this only affects people who enable NE10, I don't think this is a blocker.

...YPE_NEON ne10_fft_alloc_c2c_float32_neon +#define NE10_FFT_CFG_TYPE_T ne10_fft_cfg_float32_t +#define NE10_FFT_STATE_TYPE_T ne10_fft_state_float32_t +#define NE10_FFT_DESTROY_C2C_TYPE ne10_fft_destroy_c2c_float32 +#define NE10_FFT_CPX_TYPE_T ne10_fft_cpx_float32_t +#define NE10_FFT_C2C_1D_TYPE_NEON ne10_fft_c2c_1d_float32_neon +#else +#define NE10_FFT_ALLOC_C2C_TYPE_NEON(nfft) ne10_fft_alloc_c2c_int32_neon(nfft) +#define NE10_FFT_CFG_TYPE_T ne10_fft_cfg_int32_t +#define NE10_FFT_STATE_TYPE_T ne10_fft_state_int32_t +#define NE10_FFT_DESTROY_C2C_TYPE ne10_fft_destroy_c2c_int32 +#define NE10_FFT_DESTROY_C2C_TYPE ne10_fft_de...

Hello opus-dev, I've been cooking up this patchset to integrate NE10 library into opus. Current patchset focuses on encode use case mainly effecting performance of clt_mdct_forward() and opus_fft() (for float only) Glad to report the following on Encode use case: (Measured on my Beaglebone Black Cortex-A8 board) - Performance improvement for encode use case ~= 12.34% (Based on time -p

...nfft length (scaled fft) not supported in NE10 */ + opus_ifft_c(st, fin, fout); + } + else { + memcpy((void *)cfg, st->arch_fft->priv, sizeof(ne10_fft_state_float32_t)); + state.buffer = (ne10_fft_cpx_float32_t *)&buffer[0]; + state.is_backward_scaled = 0; + + ne10_fft_c2c_1d_float32_neon((ne10_fft_cpx_float32_t *)fout, + (ne10_fft_cpx_float32_t *)fin, + cfg, 1); + } + RESTORE_STACK; +} diff --git a/celt/arm/celt_ne10_mdct.c b/celt/arm/celt_ne10_mdct.c index cf175cb..0979cbe 100644 --- a/celt/arm/celt_ne10_mdct....

...nfft length (scaled fft) not supported in NE10 */ + opus_ifft_c(st, fin, fout); + } + else { + memcpy((void *)cfg, st->arch_fft->priv, sizeof(ne10_fft_state_float32_t)); + state.buffer = (ne10_fft_cpx_float32_t *)&buffer[0]; + state.is_backward_scaled = 0; + + ne10_fft_c2c_1d_float32_neon((ne10_fft_cpx_float32_t *)fout, + (ne10_fft_cpx_float32_t *)fin, + cfg, 1); + } + RESTORE_STACK; +} diff --git a/celt/arm/celt_ne10_mdct.c b/celt/arm/celt_ne10_mdct.c index cf175cb..0979cbe 100644 --- a/celt/arm/celt_ne10_mdct....

Hello All, I extended the libNE10 optimizations for float towards mdct_backwards/opus_ifft. I am able to get about 14.26% improvement for Decode use case now on my Beaglebone Black. Please see [1] for measurements. Questions 1. Since this patch needs to go in after Encode [2] patch) should I submit this as patch series? 2. Since Jonathan Lennox posted intrinsics cleanup [3] patch, should

Hi All, As per Timothy's suggestion, disabling mdct_forward for fixed point. Only effects armv7,armv8: Extend fixed fft NE10 optimizations to mdct Rest of patches are same as in [1] For reference, latest wip code for opus is at [2] Still working with NE10 team at ARM to get corner cases of mdct_forward. Will update with another patch when issue in NE10 gets fixed. Regards, Vish [1]:

Hi All, Changes from RFC v2 [1] armv7,armv8: Extend fixed fft NE10 optimizations to mdct - Overflow issue fixed by Phil at ARM. Ne10 wip at [2]. Should be upstream soon. - So, re-enabled using fixed fft for mdct_forward which was disabled in RFCv2 armv7,armv8: Optimize fixed point fft using NE10 library - Thanks to Jonathan Lennox, fixed some build fixes on iOS and some copy-paste errors Rest

Hello Timothy / Jean-Marc / opus-dev, This patch series is follow up on work I posted on [1]. In addition to what was posted on [1], this patch series mainly integrates Fixed point FFT implementations in NE10 library into opus. You can view my opus wip code at [2]. Note that while I found some issues both with the NE10 library(fixed fft) and with Linaro toolchain (armv8 intrinsics), the work

...*)tempin; + scale = vld1_dup_f32(&st->scale); + for (i = 0; i < N2; i++) { + inq = vld1q_f32(in); + in += 4; + outq = vmulq_lane_f32(inq, scale, 0); + vst1q_f32(out, outq); + out += 4; + } + + cfg->buffer = (ne10_fft_cpx_float32_t *)&temp[0]; + + ne10_fft_c2c_1d_float32_neon((ne10_fft_cpx_float32_t *)fout, + (ne10_fft_cpx_float32_t *)tempin, + cfg, 0); + RESTORE_STACK; +} diff --git a/celt/arm/celt_ne10_mdct.c b/celt/arm/celt_ne10_mdct.c new file mode 100644 index 0000000..177bda2 --- /dev/null +++ b/cel...

...s nfft length (scaled fft) not supported in NE10 */ + opus_fft_c(st, fin, fout); + } + else { + memcpy((void *)cfg, st->arch_fft->priv, sizeof(ne10_fft_state_float32_t)); + state.buffer = (ne10_fft_cpx_float32_t *)&buffer[0]; + state.is_forward_scaled = 1; + + ne10_fft_c2c_1d_float32_neon((ne10_fft_cpx_float32_t *)fout, + (ne10_fft_cpx_float32_t *)fin, + cfg, 0); + } + RESTORE_STACK; +} diff --git a/celt/arm/celt_ne10_mdct.c b/celt/arm/celt_ne10_mdct.c new file mode 100644 index 0000000..cf175cb --- /dev/null ++...

...s nfft length (scaled fft) not supported in NE10 */ + opus_fft_c(st, fin, fout); + } + else { + memcpy((void *)cfg, st->arch_fft->priv, sizeof(ne10_fft_state_float32_t)); + state.buffer = (ne10_fft_cpx_float32_t *)&buffer[0]; + state.is_forward_scaled = 1; + + ne10_fft_c2c_1d_float32_neon((ne10_fft_cpx_float32_t *)fout, + (ne10_fft_cpx_float32_t *)fin, + cfg, 0); + } + RESTORE_STACK; +} diff --git a/celt/arm/celt_ne10_mdct.c b/celt/arm/celt_ne10_mdct.c new file mode 100644 index 0000000..cf175cb --- /dev/null ++...

...s nfft length (scaled fft) not supported in NE10 */ + opus_fft_c(st, fin, fout); + } + else { + memcpy((void *)cfg, st->arch_fft->priv, sizeof(ne10_fft_state_float32_t)); + state.buffer = (ne10_fft_cpx_float32_t *)&buffer[0]; + state.is_forward_scaled = 1; + + ne10_fft_c2c_1d_float32_neon((ne10_fft_cpx_float32_t *)fout, + (ne10_fft_cpx_float32_t *)fin, + cfg, 0); + } + RESTORE_STACK; +} diff --git a/celt/arm/celt_ne10_mdct.c b/celt/arm/celt_ne10_mdct.c new file mode 100644 index 0000000..cf175cb --- /dev/null ++...

Changes from RFC PATCH v3 - Just rebased on tip - For all else, please see notes from RFC PATCH v3 at http://lists.xiph.org/pipermail/opus/2015-March/002902.html - latest wip opus tree/branch https://git.linaro.org/people/viswanath.puttagunta/Ne10.git branch: rfcv4_final_fft_ne10 Viswanath Puttagunta (1): armv7(float): Optimize encode usecase using NE10 library Makefile.am

Changes from RFC PATCH v1: - passing arch parameter explicitly - reduced stack usage by ~3.5K by using scaled NE10 fft version - moved all optimization array functions to arm_celt_map.c - Other cleanups pointed out by Timothy Phil, As you mentioned earlier, could you please address all compile and linker errors/warnings coming out of Ne10 library? You can find my working Ne10 repo at [1] You

Changes from RFC PATCH v2 - fixed compile issue when just compiling for --enable-intrinsics for ARMv7 without NE10 - Notes for NE10: - All compile/link warnings are now in upstream NE10 - Only patch pending upstream in NE10 is the one that needs to add -funsafe-math-optimizations for ARMv7 targets. - Phil Wang @ ARM is working on getting this fixed. - Note that even without