[MPlayer-dev-eng] shared liba52 and mm_accel macros

[Finn Thain]

Reimar Doeffinger wrote:

> 
> Hello,
> On Mon, Apr 02, 2007 at 01:24:28AM +1000, Finn Thain wrote:
> [...]
> > The assumption here is that, come runtime, the architecture has been 
> > determined already, so reuse the same value. Well, I'm not comfortable 
> > with that, since I know that Mac OS X can run powerpc binaries 
> > alongside intel binaries (and I seem to recall that an emulated 
> > powerpc app can dynamically link with a native x86 dylib (?)).
> 
> I'm quite certain that not, maybe you can compile PPC and x86 code into 
> one dylib, but I don't think anyone seriously ever tried to do emulation 
> this way. Also because it means you have to convert ABI and calling 
> conventions, and with functions like printf that is nearly impossible.

Well, don't forget that the syscall interface has calling conventions too. 
Probably some libraries are emulated and also some calling conventions are 
converted... but I'm guessing, which isn't getting us anywhere.

Anyway, assuming that you are correct, then I suppose it doesn't matter 
much what value gets used for MM_ACCEL_ALTIVEC. In a shared library, we 
could test a mask of several bits for backward compatibility (other than 
those bits that may have been used for portable accelerations like 
MM_ACCEL_DJBFFT...)

> 
> [...]
> > I concluded that the whole idea of choosing an optimisation via a 
> > library API is broken -- in this case a52_init(uint32_t mm_accel). It 
> > should be taken care of by the library at compile time (it's not like 
> > we don't have the source) or else CPU features should be detected 
> > automatically at runtime by the library. It shouldn't be part of the 
> > API. (Or else libraries are intended to be forked and bundled as they 
> > are in mplayer et al.)
> 
> I strongly disagree, simply due to the fact that Altivec detection on 
> Linux simply is _impossible_ inside a library. Yes, libavcodec does it, 
> but the code is absolutely broken i.e. incorrect, completely lacking 
> thread safety and other problems, and this is _not_ fixable. Altivec can 
> only be autodetected in the main() function.

I had no idea that runtime detection was so difficult. As a Gentoo user, I 
compile everything tuned to my CPU. But I don't know how the binary 
distros handle altivec and all the other optimisations on other 
architectures. Maybe the API originally came from closed-source code...

-f

> Greetings,
> Reimar Döffinger