[MPlayer-dev-eng]

[Arpi]

Hi,

Eh you're faster sending new versions than me applying them :)

> > Hm, this code is certainly suboptimal because it'll only work
> > with Darwin; what about simply executing an altivec instruction
> > and catching the trap, I think libmpeg2 does that. An alternative
> > would be checking the CPU capabilities directly but this requires
> > root privileges.
> 
> Checking CPU capabilities requires supervisor mode (mfmsr is a
> supervisor-level instruction).

about the altivec stuff: imho it is not needed to be detected, if
the code is compiled with --enable-altivec (or what, i don't remember how
is the checkmade in ./configure) then it's ok to use altivec code.

even on x86 the default is no detection, but you can do
--runtime-cpudetection to compile cpu-independent code which does
runtime detection and enabling optimizations.

> But indeed libmpeg2 does it throught catching SIGILL, and I
> added that to my code. Seems to work for positive detection
> in MacOSX. BTW the libmpeg2 inside mplayer seems out-of-date,
> as there's none of the new AltiVec code.

yes it's a very old version, afair it's a cvs between 0.2.0 and 0.2.1.
the new libmpeg2 API (used in 0.3.x) didn't apply our needs, but Fabian
& me patched it to work with mplayer, the patch is waiting for acceptation
on mpeg-dev list. if it will be applied (or some other code with equal
effect) then we can try upgrading. also i don't want to upgrade before 0.90
release, since the new code was not tested...

maybe as for a temp. solution you could try to backport altivec code.
the optimization specific code (idct, mc) didn't changed since 0.2.0, imho

> 3) AltiVec detection code ("borrowed" from FFmpeg and
>     libmpeg2) & enough code to enable the AltiVec IMDCT

hope it won't cause symbol name conflict with ffmpeg at linking.


A'rpi / Astral & ESP-team

--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu