[FFmpeg-devel] [PATCH] Unbreak Altivec PPC optimizations

Michael Niedermayer michaelni
Wed Dec 24 11:46:39 CET 2008

On Wed, Dec 24, 2008 at 10:48:34AM +0100, Guillaume POIRIER wrote:
> Hello folks,
> Now that we have a "all or none" situation regarding the
> implementation of  h264_idct8_add, h264_idct8_add4 (same for
> h264_idct_add, h264_idct_add16, h264_idct_add16intra, h264_idct_add8),
> Altivec-enabled builds lead to corrupt picture.
> Since it will take time for me (or anyone else!) to implement all of
> them, I'd like to suggest the attached patch to temporarily improve
> the situation.

iam fine wth the patch though iam not altivec maintainer

> I'm like to point out that in the future, care should be taken to
> _strictly_ avoid adding such dependencies between accelerated
> routines, because it's a pain to keep up with such changes for non-x86
> maintainers.

Id like to point out that this was unavoidable and telling me to avoid
that next time is just not helping if you cannot even suggest how exactly
the last (aka the current) one should have been avoided.
(i hope above doesnt sound too nasty ....)

I mean, mans said to give maintainers a 24h warning ahead, this can be
done but would have made no real difference at all, no single maintainer
dealt with this in a timeframe even close to 24h after it was known ...
it just would slow work down by 24h for such changes though then they
arent that common ...

"Avoiding" the issue by simply not introducing the dependancy would
require to add complexity and overhead to the code that
could negate the whole speed gain, besides its work that is known to
be thrown away. if a new 4x4 idct function is introduced that simply
must use the same permutations as the already used optimized 4x4 idct

Thus in the end unless you suggest that some kind of optimizations
should better not be done at all, this really seems unavoidable. But iam
surely open to suggestions if you have some ...

The truth and real problem IMHO is that large parts of the non x86 code
is not maintained at all, and the solution for this cant be to stop
improving code because it might break unmaintained code.

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20081224/97017d0b/attachment.pgp>

More information about the ffmpeg-devel mailing list