[FFmpeg-devel] libavutil simd

Rich Felker dalias
Tue Oct 2 00:34:54 CEST 2007

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

As for why I'm against stuff in the build system, it goes against the
principle of isolating hacks. Unlike hacks isolated near the code
they're needed for, hacks in the build system will potentially affect
other uses of the code, e.g. if another project builds libav* in-tree
like MPlayer does. 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.


More information about the ffmpeg-devel mailing list