similar to: opus Digest, Vol 76, Issue 11

Hi Ralph, I have pushed patches to enable radix 3 and radix 5. Github: https://github.com/projectNe10/Ne10/releases/tag/v1.2.0 Best Regards, Phil Wang > Date: Thu, 11 Dec 2014 10:46:50 -0800 > From: Ralph Giles <giles at thaumas.net> > Subject: Re: [opus] [ARM][FFT][NEON] Integrate Ne10 into Opus? > To: opus at xiph.org > Message-ID: <5489E69A.5000305 at thaumas.net>

Hi, I am working on DSP module of Ne10. I see there are fixed-point and floating-point FFT inside Opus. Is fixed-point FFT only a fall back for CPU without VFP? On ARMv7-A and ARMv8-A, benchmark result shows that fixed-point (int32) and floating-point (float32) FFT have similar performance. I guess fixed-point version is not often used on these platforms. Is it worth the effort to NEON-optimize

Hi Jean-Marc, I have implemented fixed-point FFT with 32-bit twiddles. Now I want to evaluate the accuracy, what method does Opus use? I use function implemented inside Ne10 to calculate SNR. Any comment? | size | SNR (dB) | | 16 | 82.558587 | | 32 | 83.530298 | | 60 | 80.292433 | | 64 | 82.752950 | | 120 | 79.625077 | | 128 | 83.091260 | | 240 | 79.555263 | | 256 |

Hi Timothy, It requires some extra effort if twiddles and input/output have different bit width. Since Opus uses int32 for twiddles, we are going to do the same thing. Thanks, Phil Wang -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not

Hi all, 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

Hi, | This patch introduces a new IR instruction named 'addrspacecast' that will be | used to represent the casting operation between pointers of different address | spaces. This instruction will represent whatever kind of conversion (potentially | both value and size of the pointer) and the semantic of the conversion between a | pair of address spaces is target specific. Assuming I

Hi, all, Does Opus need celt_pitch_xcorr' s fixed point version for ARM aarch64 architecture? If yes, which version does Opus prefer: assembly or instrinsics? Thanks, Zhongwei -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the

Hi, Apart from whether fast-isel should be enabled or disabled (I think enabled, personally), I haven't heard any dissenting voices about how to attack the merge problem yet. Tim, am I correct in saying that you believe AArch64 -> ARM64 is the right way to go? Does anyone disagree with that approach? Cheers, James ________________________________________ From: llvmdev-bounces at

Hi Timothy and Viswanath, > FYI, I got Phil @ ARM to independently verify for any compile/link > warning/errors and he said he did not find any... And since I haven't > heard from you for a week, I went ahead and pushed RFCv3. Yes, I do get it built without compile/link warning/errors. To save some time, please turn off other modules in Ne10 Open $NE10_DIR/CMakeLists.txt and find

I'm trying to get these cleaned up and landed, but I'm running into some trouble with this patch. Using commit a08b29d88e3c (July 21) of Ne10, I'm seeing test failures for 60-point FFTs: nfft=60 inverse=0,snr = -3.312408 ** poor snr: -3.312408 ** nfft=60 inverse=1,snr = -16.079597 ** poor snr: -16.079597 ** All other sizes tested appear to work fine (84 to 140 dB of SNR). This

On 3 February 2015 at 01:31, Phil Wang <Phil.Wang at arm.com> wrote: > Hi all, > > 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

Hi Timothy, Sorry for late reply. I have upstreamed the patch to fix the regression here: https://github.com/projectNe10/Ne10/commit/ee5d856cd9cb8c4a15ace567df4239f4e788d043 I have tested it with Vish's branch: http://git.linaro.org/people/viswanath.puttagunta/opus.git/shortlog/refs/heads/rfcv3_fft_fixed) Both unit test dft and unit test mdct passed on ARM v7/v8, floating point/fixed

Hi Viswanath, Great to see it coming. > Phil, > > As you mentioned earlier, could you please address all > compile and linker errors/warnings coming out of Ne10 library? [Phil Wang] OK, I will deliver it. But I will try to add -funsafe-math-optimisations flag to our build system first. Also I will have a look into our build system on Linux. From your previous response, I guess there

There is definitely some use for a Neon fixed-point FFT. How much exactly I'm not sure. Fixed-point is a bit more than just a fall-back for CPUs with no FPU. There are CPUs for which fixed-point is still faster. It depends on the exact model but also on what you run. For example, even on x86 I believe that SILK encoding is slightly faster in fixed-point, even though CELT is faster in float.

Hi, Have you guys seen this? http://lab.llvm.org:8011/builders/clang-aarch64-lnt/builds/1522 There are a lot of commits in there, and I'm far away from ARM64 hardware for a few days, so if one of you guys could have a look, it'd be great. :) cheers, --renato

Hello to everybody, I am writing this mail to inform you about a patch that will be committed soon (respect to current reviews). Here the link to the first mail in llvm-commits: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130812/184422.html This patch introduces a new IR instruction named 'addrspacecast' that will be used to represent the casting operation between

Dear all, Following the Benchmarking BOF from 2013 US dev meeting, I’d like to propose some improvements to the LNT performance tracking software. The most significant issue with current implementation is that the report is filled with extremely noisy values. Hence it is hard to notice performance improvements or regressions. After investigation of LNT and the LLVM test suite, I propose

Thanks Timothy and Jean-Marc, I will start NEON optimizing fixed-point FFT. Is it int32 good enough? Benchmark data shows that FFT using int16 is much faster than FFT using int32. > -----Original Message----- > From: Timothy B. Terriberry [mailto:tterribe at xiph.org] > Sent: Friday, December 26, 2014 6:52 AM > To: Phil Wang; opus at xiph.org > Cc: Zhongwei Yao; Yang Zhang; Zhou

On 28/12/14 11:04 PM, Phil Wang wrote: > It requires some extra effort if twiddles and input/output have > different bit width. Since Opus uses int32 for twiddles, we are going > to do the same thing. Actually, the existing Opus code has 16-bit twiddles, mostly because it makes it possible to use smulwb on ARMv5E. That being said, I agree that for Neon it makes sense to use 32-bit

Hi, I'm trying to generate some SPARCv8 assembly for a sparc target that doesn't have an FPU. I'm unable to get the flow to generate calls to a soft-float library. Since I wasn't able to find a definitive answer, I was hoping someone might be able to offer some pointers or shed some light. Running "clang -c -emit-llvm -msoft-float test.c -o test.bc" doesn't generate