similar to: how to build NE10 Project using llvm compiler

Hello, I want to force the linker to load all the symbols (object files) related to specific archive (.a) even though the application does not use them explicitly. (In similar in gnu linker the option for the linker will be –whole-archive, or in diab –A ). System is 64bit. Re, Yehuda Marko Yehuda.Marko at scaleil.com +972544373003 ScaleIL [image: fb-cover-6221-3464467]

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

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

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

Hello Timothy, Great to hear from you! Fired up my hardware today and this issue looks like a regression in Ne10 library. The commit in Ne10 [1] that I tested to be working successfully back in May 5b63074db45000f9688460990ee3f5e147d93782 which is the Patch Phil at ARM added to fix the overflow issue in nfft=60 case. After git-bisect, looks like the culprit patch in Ne10 [1] is

Using GCC 4.9.2, decoding the opus test vector set 10 times. All tests pass. I will do longer tests later with a larger test set, but it looks good so far. I am having a lot of trouble with the Ne10 detection. Using the precompiled Ne10 binaries at http://people.linaro.org/~viswanath.puttagunta/opus/NE10_root/ Both NE10 and Ne10 capitalizations seem to be in use. Also, where should the NE10

Hi everyone, I am working on Ne10 project. Ne10 provides NEON optimized FFT routines that are much faster (compared to those without NEON), on most ARMv7-A and all ARMv8-A devices. How about integrate it into Opus? I am not familiar with configure script, but I find "Optinal Packages" in it. If we provides --with-ne10-fft option, the one extra thing that users need to do is to

Hi, Attached patch modifies some of the Ne10 includes in celt/arm. The original includes worked, but ended up pulling in extra Ne10 headers that were unnecessary. This allows libopus to be built with just the Ne10 DSP module installed on the user's machine. Please review. Thanks, --Michael -------------- next part -------------- An HTML attachment was scrubbed... URL:

On 29 April 2015 at 17:22, Timothy B. Terriberry <tterribe at xiph.org> wrote: > > Viswanath Puttagunta wrote: >> >> 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]. >

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

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.

Viswanath Puttagunta wrote: > if OPUS_ARM_NEON_INTR > CELT_ARM_NEON_INTR_OBJ = $(CELT_SOURCES_ARM_NEON_INTR:.c=.lo) \ > - %test_unit_rotation.o %test_unit_mathops.o > -$(CELT_ARM_NEON_INTR_OBJ): CFLAGS += $(OPUS_ARM_NEON_INTR_CPPFLAGS) > + $(CELT_SOURCES_ARM_NE10:.c=.lo) \ > + %test_unit_rotation.o %test_unit_mathops.o \ > +

Hi Michael, Sorry for accidentally dropping that. Can you send me the latest version of the patch? Thanks, Jean-Marc On 15/02/17 04:30 PM, Michael Bradshaw wrote: > On Fri, Jan 27, 2017 at 7:41 PM, Michael Bradshaw <mjbshaw at google.com > <mailto:mjbshaw at google.com>> wrote: > > Attached patch modifies some of the Ne10 includes in celt/arm. The >

Motivation At the moment, when targeting armv7a, clang defaults to generate code as if -mcpu=cortex-a8 was specified. When targeting armv8a, it defaults to generate code as if -mcpu=cortex-a53 was specified. This leads to surprising code generation, by the compiler optimizing for a specific micro-architecture, whereas the intent from the user was probably to generate code that is

Hello, I see from [1] Jean-Marc comment that opus project is open to adopting ARM focussed fft optimizations in NE10 project/library at [2]. In light of this information, if and when fft implementations for 60, 120, 240, 480 become available in NE10 library, a. Will the approach of enabling this optimization using --enable-armv7-neon-float or similar flag be acceptable to begin with? or b.

Thanks for everyone giving their feedback! I saw pretty unanimous support for making -mcpu=generic the default and making -mcpu=generic schedule for an in-order CPU (Cortex-A8 in this case). I'll be making those changes shortly. I think the comments also make clear that it's less obvious whether we'd want -mcpu=native to become a default. It's probably good for some use cases, but

I was working with the rmetrics portfolioBacktesting function and dug into the code to try to find why my formula with 113 items, i.e. A1 thru A113, was being truncated and I only get 85 items, not 113. Is it due to a string length limitation in R or is it a bug in the strsplit or gsub functions, or in my string? I'd very much appreciate any suggestions ============Input script:

Hello All, I need some help with respect to cross compiling for ARM. While trying to cross compile for the ARM target, I am hitting some errors. I need some help in this. I use the following command to cross compile for ARM Cortex A72 (ARM v8-a), 64 bit architecture: *cmake -v CC='clang' CXX='clang++' -DCMAKE_C_COMPILER=../build_directory_llvm/bin/clang

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