[Ffmpeg-devel] patch: altivec optimizations for h264 decoder
Mon Feb 6 22:29:49 CET 2006
On 6-feb-2006, at 17:31, Derk-Jan Hartman wrote:
> I'll test it in a couple of hours on a Dual G5. (If no one did
> before I did of course).
I tried the patches, but they don't work for me.
These are the effects that i am seeing.
Darwin veda.student.utwente.nl 8.4.0 Darwin Kernel Version 8.4.0: Tue
Jan 3 18:22:10 PST 2006; root:xnu-792.6.56.obj~1/RELEASE_PPC Power
gcc version 4.0.0 (Apple Computer, Inc. build 5026)
> On 6-feb-2006, at 14:07, Romain Dolbeau wrote:
>> Michael Niedermayer wrote:
>>> mixing declarations and statements, romain is this an issue for
>>> ppc-asm or do
>>> all compilers which support ppc-asm support this too?
>> They probably do. It would be intesrting to know what OS and compiler
>> the author of the patches used (I don't have linux/ppc anymore).
>>> romain please review and test, you are the ppc maintainer
>> I am ? damn, more responsabilities :-/
>> I can't test, as I don't have a sample, and if I had,
>> I don't have a machine fast enough for 1080p anyway
>> (the G4 isn't the fastest CPU around...)
>> Patch 1 : nothing to add, except that gcc register allocator is
>> going to hate ff_h264_idct_add_altivec_mat
>> Patch 2 : in PREFIX_h264_qpel4_hv_lowpass_altivec, why use
>> VEC_LOAD_UNALIGNED_CHECK ? tmpbis is computed from tmp
>> (comments -> assumed aligned) and tmpStride (comments ->
>> multiple of 16), so it has to be aligned.
>> Patch 4 : is put_pixels8_altivec really faster than the C
>> version ? there's not computation whatsoever, and with the
>> need to load the destination block to insert the new
>> data, it may be slower to use AltiVec than regular C code.
>> I'm a little bit short on time to be able to make a more
>> thorough investigation, sorry
>> Romain Dolbeau
>> <romain at dolbeau.org>
>> ffmpeg-devel mailing list
>> ffmpeg-devel at mplayerhq.hu
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
More information about the ffmpeg-devel