[FFmpeg-devel] libavutil simd

[Luca Barbato]

Michael Niedermayer wrote:
> personally iam in favor of the simplest and least hackish solution
> for x86 we can easily and cleanly figure out the cpu capabilities
> 
> for ppc and sparc there is no simple and clean way, what really is the
> big problem with treating ppc without altivec like a different
> architecture than ppc with altivec?
> with x86 we cant as there are so many different variants (mmx, 3dnow, mmx2
> sse, sse2, ....)
> 
> the whole thread seems to be centered around "we must do it at runtime
> no matter what" i just cant help but keep wondering why that is so
> important?

certain binary distributors may have yet another headache about that...

> if it can be done cleanly iam all for it but it rathr looks
> like we would need 10 different solutions to do it for each different OS
> and for another 5 OS would need to fork which many applications 
> (other libs) just cant do
> i think this outwheights the complexity of considering ppc / ppc-altivec
> different architectures, that is for us certainly and from the applications
> point of view maybe as well especially for the case where the application
> has to figure it out itself

as I said before I don't care that much, I can spend some time cleaning
things but I'm one of those that don't see the point of having single
binaries.

> 
> PS: let me remind everyone that libavutil is supposed to be LIGHTweight,
> simple, modular and fast
> and i really would rather drop SIMD in libavutil completely before we
> fill it up with some of the idiotic hacks suggested by the army of
> bloated zombies in this thread. Many of you really sound like win32
> users who want their ideas implemented no matter how stupid

having a 4 times faster adler doesn't sound stupid if you are going to
use it quite often...
same goes for sha1, md5, aes...

lu

-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero