Mplayer Development And Optimization For Arm Options

[Serge]

Probably it is a good idea to consolidate efforts and try to submit some of the useful ARM related patches upstream:
http://lists.mplayerhq.hu/pipermail/ffmpeg...ust/014460.html
http://lists.mplayerhq.hu/pipermail/mplaye...ber/046207.html

I can only test MPlayer on Nokia 770, so can't be sure if any ARM9E (that's the core used in Nokia 770) specific optimizations are also good for Zaurus. So people who are able to compile MPlayer from sources and test it on zaurus are welcome in this thread. One of the examples is the new armv5te optimized idct in MPlayer 1.0rc1, can anybody benchmark it on Zaurus?

Also this is not quite ARM architecture related, but libmad based decoder in MPlayer seems to have troubles with variable bitrate audio (it loses sync with video). Some more details can be found here http://lists.mplayerhq.hu/pipermail/mplaye...ust/045017.html and in the followup messages. Any volunteer to investigate this problem?

All in all, ffmpeg optimizations for ARM are not nearly as good as for x86, so investing some time in it may provide some performance improvement.

[koen]

I ran the benchmark on my ipaq h2200 (400MHz pxa255) and I can see that the memory bus is a bottleneck, since the 770 and pxa270 machines run the bus at a higher speed.
If that isn't the case, arm926 cores kick xscale ass

CODE

root@h2200:/data# sh doom-test.sh
idct is 2
BENCHMARKs: VC:  82.432s VO:   0.071s A:   0.000s Sys:   1.293s =   83.796s
BENCHMARKs: VC:  80.798s VO:   0.066s A:   0.000s Sys:   0.916s =   81.780s
BENCHMARKs: VC:  80.758s VO:   0.067s A:   0.000s Sys:   0.912s =   81.737s
BENCHMARKs: VC:  80.676s VO:   0.070s A:   0.000s Sys:   0.897s =   81.643s
BENCHMARKs: VC:  80.649s VO:   0.067s A:   0.000s Sys:   0.950s =   81.665s
idct is 7
BENCHMARKs: VC:  75.593s VO:   0.069s A:   0.000s Sys:   0.902s =   76.564s
BENCHMARKs: VC:  78.993s VO:   0.069s A:   0.000s Sys:   0.903s =   79.965s
BENCHMARKs: VC:  79.248s VO:   0.066s A:   0.000s Sys:   0.933s =   80.246s
BENCHMARKs: VC:  79.242s VO:   0.067s A:   0.000s Sys:   0.931s =   80.239s
BENCHMARKs: VC:  79.080s VO:   0.066s A:   0.000s Sys:   0.904s =   80.050s
idct is 10
BENCHMARKs: VC:  77.020s VO:   0.067s A:   0.000s Sys:   0.905s =   77.992s
BENCHMARKs: VC:  80.152s VO:   0.066s A:   0.000s Sys:   0.905s =   81.124s
BENCHMARKs: VC:  80.219s VO:   0.181s A:   0.000s Sys:   0.903s =   81.303s
BENCHMARKs: VC:  80.238s VO:   0.066s A:   0.000s Sys:   1.024s =   81.328s
BENCHMARKs: VC:  80.359s VO:   0.066s A:   0.000s Sys:   0.906s =   81.331s
idct is 16
BENCHMARKs: VC:  73.140s VO:   0.068s A:   0.000s Sys:   0.916s =   74.124s
BENCHMARKs: VC:  76.616s VO:   0.066s A:   0.000s Sys:   1.014s =   77.695s
BENCHMARKs: VC:  76.927s VO:   0.066s A:   0.000s Sys:   0.905s =   77.899s
BENCHMARKs: VC:  76.992s VO:   0.069s A:   0.000s Sys:   0.906s =   77.966s
BENCHMARKs: VC:  77.157s VO:   0.067s A:   0.000s Sys:   0.940s =   78.165s

[Serge]

Thanks for running benchmarks. They show that these armv5te optimizations for idct are useful for xscale too. I was just unsure if it is possible to develop a shared code that runs fine on both arm926 and xscale or have to implement two different versions. I'll try to optimize this idct further as much as possible primarily for arm926, but will also keep in mind that this code is also useful on xscale and will take this into account Anyway, iwmmxt implementation of idct specifically optimized for xscale may be a better choice (idct takes quite a noticeable fraction of decoding time, so it is at least useful for some machines like zaurus C3000). If anybody skilled with arm assembly would like to try it, I could provide some help with information (but I don't have any machine that can run iwmmxt code anyway).

I ran the benchmark on my ipaq h2200 (400MHz pxa255) and I can see that the memory bus is a bottleneck, since the 770 and pxa270 machines run the bus at a higher speed.

That's interesting. If memory performance is really very important for mplayer, probably it should be possible to find the parts of code with heavy memory use and optimize memory access patterns for better cache and memory bus utilization. I have already done some tests trying to figure out how to make best use of memory bandwidth on Nokia 770 some time ago: http://maemo.org/pipermail/maemo-developer...ber/006579.html

This information can turn out to be very useful for further optimizations

If that isn't the case, arm926 cores kick xscale ass

Well, arm926 core should be somewhat faster per clock, here are some links to optimization docs for different arm flavours: http://www.internettablettalk.com/forums/s...read.php?t=2406

But I expected that 416MHz should be still a lot faster because of higher cpu clock frequency. Maybe memory performance is really a limiting factor here and it makes performance of all these chips closer to each other.

Another possible explanation could be nonoptimal set of optimization options or older version of gcc for zaurus builds of mplayer. It should be relatively easy to test mplayer with a different set of optimization options. You can take upstream mplayer 1.0rc1 tarball and compile it using:
CFLAGS="-O4 -mcpu=iwmmxt -fomit-frame-pointer -ffast-math" ./configure
make

It may have some problems with video/audio output drivers if compiled without zaurus specific patches, but this should not be a problem for testing decoding capabilities only