similar to: [PATCH] AltiVec Patch Updated for 1.1.1

Sorry that it has been a while since the last altivec patch. I have noticed something interesting, and so it remains unfinished... On the ppc, even with the altivec optimizations, almost a quarter of the time is spent in FLAC__stream_encoder_process(). I finally discovered that it is because of all the integer to float conversions. Aside from being exceptionally slow on the g4, they

Hi, I have been playing with Altivec, and I rewrote a couple of the routines in assembly. Looking at the archives, I noticed that there may already be some effort on this. Anyways... Right now, I have two routines working. They need to be cleaned up, made relocatable, and documented; otherwise, they seem to work fairly well. I see an overall ~27% speed improvement when encoding with the

I tried to send this message via gmane a couple of weeks ago but it never got through moderation. So maybe the moderator is on holiday, or there is some other problem in the gmane->flac-dev connection? -------------------- Start of forwarded message -------------------- Newsgroups: gmane.comp.audio.compression.flac.devel Subject: A couple of points about flac 1.1.1 on ppc/linux/altivec

Josh Coalson <xflac@yahoo.com> writes: > --- John Steele Scott <toojays@toojays.net> wrote: >> Back in October 2004, I did a bit of work on FLAC to get version >> 1.1.1 to >> build correctly under GNU/Linux/PPC. Only now have I realised that >> somewhere >> along the way something broke in FLAC's decoding. On my machine, >> roughly 50%

--- Chris Csanady <cc@137.org> wrote: > Hi, > > I have been playing with Altivec, and I rewrote a couple of the > routines > in assembly. Looking at the archives, I noticed that there may > already > be some effort on this. Anyways... > > Right now, I have two routines working. They need to be cleaned up, > made > relocatable, and documented; otherwise,

--- Brady Patterson <brady@spaceship.com> wrote: > On Thu, 27 Jan 2005, John Steele Scott wrote: > > That looks fine to me as well. However, the best solution is > something which > > Luca suggested a few months ago, which is to use the functions > defined in > > altivec.h. These are C functions which map directly to Altivec > machine > > instructions. I

Luca Barbato <lu_zero@gentoo.org> writes: > Josh Coalson wrote: >>>Probably a version check could help. >> how about this logic: >> if cpu is ppc >> if as exists >> if as is apple version >> use as >> else if as is gnu version >> use as to assemble but src/libFLAC/ppc/gas directory >> else >>

--- John Steele Scott <toojays@toojays.net> wrote: > Josh Coalson <xflac@yahoo.com> writes: > > > --- John Steele Scott <toojays@toojays.net> wrote: > >> Back in October 2004, I did a bit of work on FLAC to get version > >> 1.1.1 to > >> build correctly under GNU/Linux/PPC. Only now have I realised that > >> somewhere > >>

--- John Steele Scott <toojays@toojays.net> wrote: > Back in October 2004, I did a bit of work on FLAC to get version > 1.1.1 to > build correctly under GNU/Linux/PPC. Only now have I realised that > somewhere > along the way something broke in FLAC's decoding. On my machine, > roughly 50% > of FLAC files are being decoded incorrectly. > > I presume that I

--- Luca Barbato <lu_zero@gentoo.org> wrote: > Josh Coalson wrote: > > since I don't know how to resolve this, in current CVS I have > > checked in a system where there are src/libFLAC/ppc/as and > > src/libFLAC/ppc/gas selected by configure. I have also checked > > in as many patches as I could make sense of (the cpu.c detection > > stuff and the

Josh Coalson wrote: > --- Luca Barbato <lu_zero@gentoo.org> wrote: > >>Josh Coalson wrote: >> >>>since I don't know how to resolve this, in current CVS I have >>>checked in a system where there are src/libFLAC/ppc/as and >>>src/libFLAC/ppc/gas selected by configure. I have also checked >>>in as many patches as I could make sense of

Josh Coalson wrote: > since I don't know how to resolve this, in current CVS I have > checked in a system where there are src/libFLAC/ppc/as and > src/libFLAC/ppc/gas selected by configure. I have also checked > in as many patches as I could make sense of (the cpu.c detection > stuff and the configure.in stuff). can you guys take a look at > current CVS and help me get

On Thu, 27 Jan 2005, John Steele Scott wrote: > That looks fine to me as well. However, the best solution is something which > Luca suggested a few months ago, which is to use the functions defined in > altivec.h. These are C functions which map directly to Altivec machine > instructions. I am willing to help out, but I don't find the current lpc_asm.s > very easy to follow, and

finished hooking up the altivec stuff so it works in ProjectBuilder. I ran a test, doing a 'flac -t' on 400MB of files compresses at level 5. the runtime dropped from from 180 sec to 105 sec! once I get the latest autotools on my ibook I'll try and get asm compilation to work that way. Josh --- Josh Coalson <xflac@yahoo.com> wrote: > OK, checked it all in (only minor

good news, I finally got the asm compilation working with both autotools and project builder. it's all checked in. Brady, can you try it out too? autogen.sh may need a little tweaking depending on your environment. here's what mine looks like (I have some of the required libs in local places in the user acct that I build flac in, and the rest I get from Fink installed in /sw). aclocal

Thanks. I was worried about the assembler invocation but it looks like you solved that problem. Smooth build on my pbook (G4, 10.2.8, gcc-3.3, ac-2.59, am-1.6.3). Only problem was lack of check for docbook-to-man; my patch is attachments 1-2. Not so smooth on my imac (G3, 10.2.8, gcc-3.3, ac-2.52, am-1.6.1; that's what came with the last 10.2-compatible dev tools). First problem: typo in

>Your "make check" output has two classes of errors: >1. llvm-gcc or llvm-g++ not being found. Its possible this results from >Cygwin requiring the .exe extension. The makefiles probably need to be >enhanced to include the suffix. Okay, but that did not seem to be a problem before. I thought about that being a possible problem. The make install removes the .exe

Hello, I'm using Mono with experimental LLVM backend support on PowerPC. I noticed that although LLVM's IR contains SIMD instructions the assembly produced doesn't contain any Altivec instructions and my PowerPC970 machine of course has Altivec support. Isn't there some kind of autodetection? I searched in Target sources but only found out that Altivec is disabled by default. Can

Hello, I'm using Mono with experimental LLVM backend support on PowerPC. I noticed that although LLVM's IR contains SIMD instructions the assembly produced doesn't contain any Altivec instructions and my PowerPC970 machine of course has Altivec support. Isn't there some kind of autodetection? I searched in Target sources but only found out that Altivec is disabled by default. Can

I think I've gotten FLAC__lpc_restore_signal() about as good as I'm going to get it. Here's what I have: -a new file, lpc_asm.s, which has the assembly routines -changes to cpu.h, cpu.c, and stream_decoder.c to enable them -changes to configure.in to support the new cpu stuff -a preliminary Makefile.am -maybe something else I'm forgetting Now automake complains that configure.in