similar to: Errors when compiling for ARM Cortex-M4

This is required in order to build using the built-in assembler in clang. --- I squashed the two changes since it would break the normal gcc build otherwise. --- celt/arm/arm2gnu.pl | 2 ++ celt/arm/celt_pitch_xcorr_arm.s | 18 +++++++++--------- 2 files changed, 11 insertions(+), 9 deletions(-) diff --git a/celt/arm/arm2gnu.pl b/celt/arm/arm2gnu.pl index eab42ef..5c24758 100755 ---

This is required in order to build using the built-in assembler in clang. --- celt/arm/celt_pitch_xcorr_arm.s | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/celt/arm/celt_pitch_xcorr_arm.s b/celt/arm/celt_pitch_xcorr_arm.s index 09917b1..3c4b950 100644 --- a/celt/arm/celt_pitch_xcorr_arm.s +++ b/celt/arm/celt_pitch_xcorr_arm.s @@ -309,7 +309,7 @@

On Fri, 7 Feb 2014, Timothy B. Terriberry wrote: > Martin Storsjo wrote: >> This is required in order to build using the built-in assembler >> in clang. > > These patches break the gcc build (with "Error: bad instruction"). Ah, right, sorry about that. > Documentation I've seen is contradictory on which order ({cond}{size} or > {size}{cond}) is correct.

I?m trying to build Opus (git master) for iOS, and it doesn?t build unless I disable the ARM assembly. It looks like the problem is that Apple?s assembler doesn?t support all the assembler directives that the GNU assembler does. I suspect this is a combination of the fact that Apple platforms are Mach-O rather than Elf, and just the fact that Apple?s assembler is extremely divergent from the

This avoids having to use the public symbol name when jumping here, on platforms where the public symbols have an underscore prefix. --- This avoids having to add heuristics for adding prefixes to symbols in jumps to local labels as well. --- celt/arm/celt_pitch_xcorr_arm.s | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/celt/arm/celt_pitch_xcorr_arm.s

On 19 December 2014 at 05:26, Timothy B. Terriberry <tterribe at xiph.org> wrote: > Viswanath Puttagunta wrote: >> I responded to your feedback before I started on RFCv3.. and took your >> silence as approval :).. I guess that email got lost in your inbox sea >> some where.. so re-posting the responses. > > Sorry, I did see it but I guess I read it rather more

On 19 December 2014 at 17:25, Viswanath Puttagunta <viswanath.puttagunta at linaro.org> wrote: > Optimize celt_pitch_xcorr function (for floating point) > using ARM NEON intrinsics for SoCs that have NEON VFP unit. > > To enable this optimization, use --enable-intrinsics > configure option. > > Compile time and runtime checks are also supported to make sure > this

On Sat, 8 Feb 2014, Martin Storsjo wrote: > This is required in order to build using the built-in assembler > in clang. > --- > I squashed the two changes since it would break the normal gcc > build otherwise. > --- > celt/arm/arm2gnu.pl | 2 ++ > celt/arm/celt_pitch_xcorr_arm.s | 18 +++++++++--------- > 2 files changed, 11 insertions(+), 9 deletions(-)

Hello Timothy, Appreciate the thorough review. Have a few questions before I re-spin the patch in-line. On 28 November 2014 at 15:52, Timothy B. Terriberry <tterribe at xiph.org> wrote: > Review comments inline. > >> +if OPUS_ARM_NEON_INTR >> +noinst_LTLIBRARIES = libarmneon.la >> +libarmneon_la_SOURCES = $(CELT_SOURCES_ARM_NEON_INTR) >>

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

Viswanath Puttagunta wrote: > I responded to your feedback before I started on RFCv3.. and took your > silence as approval :).. I guess that email got lost in your inbox sea > some where.. so re-posting the responses. Sorry, I did see it but I guess I read it rather more quickly than I thought. Apologies for that. > guidance. I wouldn't know where else to put this. Without

Sorry for typo.. from shows as "--no-chain-reply-to --thread ./*" instead of from "Viswanath Puttagunta". So resent it again after fixing my command line.. Otherwise, the patch for RFCv2 is identical. Regards, Vish On 7 December 2014 at 02:08, --no-chain-reply-to --thread ./* <viswanath.puttagunta at linaro.org> wrote: > From: Viswanath Puttagunta

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

Two comments on the various infrastructure for RTCD etc. 1. The 0002- patch changes the ABI of the celt_pitch_xcorr functions, but doesn’t change the assembly in celt/arm/celt_pitch_xcorr_arm.s correspondingly. I suspect the ‘arch’ parameter can just be ignored by 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,

Hi Linfeng, On 06/06/17 04:09 PM, Jonathan Lennox wrote: > Two comments on the various infrastructure for RTCD etc. > > 1. The 0002- patch changes the ABI of the celt_pitch_xcorr functions, > but doesn’t change the assembly in celt/arm/celt_pitch_xcorr_arm.s > correspondingly. I suspect the ‘arch’ parameter can just be ignored > by the assembly functions, but at least the

Hi, Thank you for your response. I pulled yesterday to commit da97db1ca1f92592af3534c9a2596da0e9a009ca, added a bunch of more defines to my compile options, and assembled & linked in armopts.s,celt_pitch_xcorr_arm.s. Performance jumped up from about 4.8 Mb/s to 5.3 Mb/s on the same device, so it is improvement. Not sure what other tweaks there would be to try, but if it could match the

optimizations done for this CPU architecture. Whether it is in-line assembly or assembly optimization of function (Eg: celt_pitch_xcorr_arm.s), or using intrinsics, it is still some optimizations. So, I don't understand your perspective. I really thought about this for the most amount of time... could you please suggest an alternative here?.. Because I'm really out of ideas in this area

Thank Jonathan and Jean-Marc! I attached the new patch sets in inner_prod_5patches_v3.zip. The Chromebook I'm using is Chromebook 13 CB5-311 series RMN: Z3ENN CPU info: $ cat /proc/cpuinfo processor : 0 model name : ARMv7 Processor rev 3 (v7l) BogoMIPS : 2.31 Features : swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae CPU implementer : 0x41 CPU

https://bugs.freedesktop.org/show_bug.cgi?id=74648 Priority: medium Bug ID: 74648 Assignee: nouveau at lists.freedesktop.org Summary: Ultima IX (wine) movie playback crashes game QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: Linux (All) Reporter: christopher at

Viswanath Puttagunta wrote: > + SUMM = vdupq_n_f32(0); It kills me that there's no intrinsic for VMOV.F32 d0, #0 (or at least I couldn't find one), so this takes two instructions instead of one. > + /* Consume 4 elements in x vector and 8 elements in y > + * vector. However, the 8'th element in y never really gets > + * touched in this loop. So, if len == 4,