similar to: 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%

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

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

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

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

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

Hi all, I'm trying to compile the flac-1.1.1 tarball on a Linux PPC system (a G3 iBook running Debian Testing). Configure is fine, but make bombs out almost immediately with: lpc_asm.s: Assembler messages: lpc_asm.s:1: Error: junk at end of line, first unrecognized character is `l' lpc_asm.s:2: Error: junk at end of line, first unrecognized character is `C' lpc_asm.s:4:

Sadly the latest optimization broke completely everything. The asm code isn't gas compliant. the libFLAC linker script has a typo, disabling the asm optimization and/or altivec won't let a correct build anyway. Instant fixes for the asm stuff: sed -i -e"s:;:\#:" on the lpc_asm.s to load address instead of addis+ori you could use lis and la and PLEASE use the @l(register)

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

thanks for the feedback, but it would really help if you supply a patch (diff -c), I didn't understand all the changes you described. someone reported a problem with src/libFLAC/include/private/lpc.h that was fixed in CVS and may fix the problem building with asm disabled http://cvs.sourceforge.net/viewcvs.py/*checkout*/flac/flac/src/libFLAC/include/private/lpc.h?rev=1.24 Josh --- Luca

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, This patch adds Altivec-optimized implementations of oc_enc_frag_sad and oc_enc_frag_ssd. This patch is against the latest svn revision of theora-ptalarbvorm. Speeds up encode on a plant stop-motion clip on a 1 GHz PPC 7447 by ~3%, timewise. Time spent in oc_enc_frag_sad is reduced from 4.2% to 2.3% and oc_enc_frag_ssd from 1.2% to 1.0%, as reported by Shark. Currently this is only

Erik de Castro Lopo wrote: >> > I'll try to power up my Linux/PPC machine in the next couple of days >> > so I can test this. >> >> Any news? > > Sorry, haven't had a chance to set up that machine. Hopefully this > weekend. I have several patches, but they interfere with this ppc/altivec patch. (one of them changes lpc.h,another changes

This set of patches removes PPC/Altivec code from FLAC. I decided to split the patch into 5 parts to make it more simple: 1) removes FLAC__lpc_restore_signal_asm_ppc_altivec_16* from lpc.h and stream_decoder.c 2) removes PPC-specific code from cpu.c and cpu.h 3) removes PPC stuff from libFLAC/Makefile.lite and build/*.mk 4) removes as/gas/PPC-specific stuff from configure.ac and

Erik de Castro Lopo wrote: > lvqcl wrote: > >> The most problematic parts are 3 and 4 since I cannot directly >> test them neither on Darwin PPC nor on Linux PPC. > > I'll try to power up my Linux/PPC machine in the next couple of days > so I can test this. Any news?

lvqcl wrote: > The most problematic parts are 3 and 4 since I cannot directly > test them neither on Darwin PPC nor on Linux PPC. I'll try to power up my Linux/PPC machine in the next couple of days so I can test this. Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

Included is an updated patch against Flac 1.1.1. Although I can not be certain, I believe that it will function under Linux as well as Darwin. By default, the asm versions of the functions are disabled. However, if you are on a Darwin system, you may enable them with: CFLAGS=-DUSE_ASM_ALTIVEC_RESTORE ./configure I have also included support to detect AltiVec and also PPC64 availability,