[MPlayer-dev-eng] shared liba52 and mm_accel macros
Reimar.Doeffinger at stud.uni-karlsruhe.de
Mon Apr 2 11:38:57 CEST 2007
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
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
More information about the MPlayer-dev-eng