[FFmpeg-devel] libavutil simd

[Luca Barbato]

Rich Felker wrote:
> On Tue, Oct 02, 2007 at 12:15:56AM +0200, Luca Barbato wrote:
>> Michael Niedermayer wrote:
>>> so please correct me if iam wrong but i dont see how the altivec "detection"
>>> code in libavcodec could have ever worked short of by pure luck that gcc
>>> didnt use altivec anywhere when compiling normal c code
>> you may use -maltivec (-mabi=altivec) only on the files in which you are
>> effectively using altivec intrinsics.
>>
>>> so it really does not seem like runtime altivec detection is possible not
>>> even with fork and sigill catching or /proc/ with current gcc
>> Possible is possible, the question is if it's worth the hassle. I always
>> been on the "don't care" side, so it's fine for me .
> 
> For what it's worth, I'm against hacks in the build system as well as
> dirty unreliable detection methods.

the build system won't have hacks but proper usage of Makefile (btw it's
already done for sparc iirc)

> If certain users really need the
> optimizations they can compile a build specific to their cpu or else
> install a special binary package. This is how the Linux kernel already
> works on most (all?) distributions, and we'd have a lot fewer packages
> per arch than Linux does, probably.

No, the opposite, everybody but g3 users want to have altivec...

> e.g. if another project builds libav* in-tree like MPlayer does.

That is an hack by definition...

> And, for the time being, this still seems to be the
> preferred way to use libav*... Users of a library should not have to
> be aware of hacks that library makes to support runtime CPU detection.

I still consider saner put on an init function (to be run before you do
ANYTHING) that switches the implementations according to the application
requirements. How the application figures what to do is up to it.

Sounds completely off?

lu

-- 

Luca Barbato

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