[MPlayer-dev-eng] [PATCH] AltiVec: dct64 for mp3lib, IMDCT for liba52, detection code

[Daniel Egger]

Am Don, 2003-01-16 um 20.38 schrieb Romain Dolbeau:

> The only Darwin/MacOSX specific bit is the AltiVec detection function,
> borrowed from FFMpeg. Someday I'll write a similar one for linux/ppc.
> Everything else is (should be :-) compliant with the Motorola PEM (or is
> it PIM ?)

Lucky you, it only worked because you haven't defined any AltiVec
vectors directly. The PEM (at least my version which I cannot find right
now :/) specifies that the compiler has to take values in parens whereas
gcc 3.2 uses the typical C declarations i.e. in {}s.

There're also a few more nasties which make the motorola gcc the only
compiler which is compliant with their selfdefined API. OS X 10.2 uses
gcc 3.2 which has slightly different semantics.

> I didn't expect the mp3 stuff to be critical, but I profiled a run of
> 1024 frames from a movie and the dct64_1 function was one of the top CPU
> eater. So I optimized it :-) On those 1024 frames I get a more than 3x
> speed-up, and dct64_altivec is no longer in the top 10 :-)

That's surprising I've no idea which type of codec your movies use and 
what size they are but here with DVD size AVI's encoded with MPEG4 (or
sort of :)) the mp3 decoder hardly shows up at the profiling radar.

> Or write a clean, non-portable detection function for every supported OS
> :-) Seriously, is there any OS except Darwin/OSX/Linux/NetBSD running on
> PPC that can compile mplayer ?

Yes, and even your small list imply 3 different implementations. A few
more to name here: AmigaOS, Beos, QNX, VxWorks. Haven't worked with any
of them for ages but most likely there are some freaks who cannot get a
kick by running a standard OS. :)

> Maybe that's why mplayer segfaults on OSX 10.1 at work :-)

Could be, but it's more likely that 10.1 is using a different gcc
with the motorola extensions.

BTW: 
static complex_t __attribute__((aligned(16))) * w[7] = {w_1, w_2, w_4,
w_8, w_16, w_32, w_64};

That might cause problems in the rare possibility that this is the last
part of data in memory and the compiler doesn't pad it. You might want
to make sure that data accessed by AltiVec is always padded to 128 bits.

-- 
Servus,
       Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20030117/29c2900d/attachment.pgp>