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

[Reimar Döffinger]

Hello,
[...]
On Mon, Apr 02, 2007 at 11:33:17AM +1000, Finn Thain wrote:
> Reimar Doeffinger wrote:
> > 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.

Yes, but there are only a few syscalls and you know exactly which
arguments they take, plus there are no syscalls that I know of that use
varargs. Basically the problem is you can only convert calling
conventions when you know exactly how the function works.

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

That's possible, though just deciding for one official value and fixing
whatever needs fixing wouldn't be that bad an approach either.
Or as a compromise deciding on one value and warning if any of the
others are used (if the lib has a proper way to print a warning).

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

AFAIK only Altivec is so problematic, and actually only Altivec on
Linux, OSX seems to have a special syscall to check for it IIRC.
But I myself only learned of this mess while I was trying to fix
libavcodec...

Greetings,
Reimar Döffinger