[FFmpeg-devel] libavutil simd

[Rich Felker]

On Tue, Oct 02, 2007 at 01:04:02AM +0200, Luca Barbato wrote:
> > 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...

Ah.. WTF does MPlayer even run on such slow stuff? It's kinda like
asking MPlayer to run on pre-MMX pentiums. Sure it will work but the
biggest movie you could play is 64x48 mpeg1... I expect g3 is a bit
better but not much.

> > e.g. if another project builds libav* in-tree like MPlayer does.
> 
> That is an hack by definition...

Well good Makefiles should be written such that it's not a hack but
something clean you're expected to be able to do.

Anyway it's not a big deal as long as it doesn't break things.

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

The application should be able to either call a function to detect the
cpu capabilities, or provide its own set if it already detected them
in a different way.

Alternatively, if there's a reliable way such as /proc/cpuinfo to
detect them (reliable meaning no false positives, not no false
negatives) then we probably don't even need this. IMO it's safe for a
library to open and read /proc/cpuinfo. It's not safe for a library to
fork and/or set signal handlers.

Rich