New ppc board by Acube/A-Eon: A1222 "Tabor"

[Spectre660]

Unfortunately the regular Debian Mplayer powerpc32 wont run.
Would have to try to compile a non-altivec version but
I suspect that  other components may also causes  problems .
Same issue on the Sam460ex but I compiled a non-altivec version some time ago and that works.Interestingly the regular Mplayer version in Ubuntu-mate 15.10 works ok on the Sam460ex . Tabor does not work with X windows stuff under Lubuntu 15.10. I can experiment and see if I can get a regular Debian benchmark by some means .
 

What are the Prometheus Trailer benchmark results running mplayer on regular Debian with the emulated floating point?

[Spectre660]

Interesting paper of floating point emulation.
http://www.ll.mit.edu/HPEC/agendas/proc08/Day1/11-Day1-PosterDemoA-Spetka-abstract.pdf

[Spectre660]

So the end results are based on the actual method used.

That is the same article I linked to in post #91 of this thread. I'm pleased that someone read it and found it "interesting". The 3D bar graph shows that the fully trapped FPU instructions (FastFPE and NWFPE) take at least twice as long to execute on average as compiling with software FP which is considered slow compared to hardware FP. It looks like there is not much difference on the bar graph for basic FP calculations but this is probably due to lack of resolution for smaller measurements. Complex FP instructions (in hardware or software emulation) usually use FP (often polynomial approximation) equations using basic FP math (FADD, FSUB, FMUL, FDIV, FABS, FSQRT, FINT, etc.) so the complex instructions are composites of many simple calculations but without using traps. Programs using heavy FP calculations would use traps more frequently so they would have more overhead than the complex FP instructions but using the complex FP instructions would reduce this additional overhead .

[Spectre660]

Just tested - Its fast enough to play back an MP3 ok.

-
Uh oh.

[Spectre660]

With Linux Mplayer SPE binary yes.
regular Linux Mplayer video not working with emulation under powerpc32 .

And 720p@Youtube?

[Spectre660]

There can be large variations of results between program versions and OS's on the same "slow" cpus.
Examples from a Sam460ex below


==================================================================================

AmigaOS 4.1FE Livefor-it-Mplayer

10.AmigaOS 4.1:> mplayer -benchmark -nosound -ao null -vo null -lavdopts skiploopfilter=none big_buck_bunny_720p_surround.avi
LiveForIt-MPlayer-6.5.7 SVN-r37230-snapshot-1.1.1 (C) 2000-2014 MPlayer Team

BENCHMARKs: VC: 804.386s VO:   0.142s A:   0.000s Sys:  19.587s =  824.115s
BENCHMARK%: VC: 97.6061% VO:  0.0172% A:  0.0000% Sys:  2.3767% = 100.0000%

Exiting... (End of file)
================================================================================

AmigaOS 4.1FE MUI-Mplayer

4.AmigaOS 4.1:> mplayer -benchmark -nosound -ao null -vo null -lavdopts skiploopfilter=none big_buck_bunny_720p_surround.avi
MPlayer UNKNOWN-4.4.3 (C) 2000-2010 MPlayer Team


BENCHMARKs: VC: 620.417s VO:   0.104s A:   0.000s Sys:  19.714s =  640.236s
BENCHMARK%: VC: 96.9045% VO:  0.0163% A:  0.0000% Sys:  3.0792% = 100.0000%

Exiting... (End of file)
==================================================================================

Morphos 3.9 Mplayer

 mplayer -benchmark -nosound -ao null -vo null -lavdopts skiploopfilter=none big_buck_bunny_720p_surround.avi
MPlayer SVN-r37401 (C) 2000-2015 MPlayer Team

BENCHMARKs: VC: 680.264s VO:   0.070s A:   0.000s Sys:  37.769s =  718.103s
BENCHMARK%: VC: 94.7307% VO:  0.0097% A:  0.0000% Sys:  5.2595% = 100.0000%
Exiting... (End of file)
==================================================================================

Linux Ubuntu 15.10 Mplayer

julian@Sam460ex:~$ mplayer -benchmark -nosound -ao null -vo null -lavdopts skiploopfilter=none
'/home/julian/Documents/big_buck_bunny_720p_surround.avi'
MPlayer2 2.0-728-g2c378c7-4build1 (C) 2000-2012 MPlayer Team

BENCHMARKs: VC: 354.405s VO:  99.944s A:   0.000s Sys:  15.271s =  469.621s
BENCHMARK%: VC: 75.4663% VO: 21.2819% A:  0.0000% Sys:  3.2519% = 100.0000%

Exiting... (End of file)
==================================================================================

 

Most of OS does not use FLOAT, but most of the programs that run on the OS that play sound and video use float, and most of this are ported from Linux, compiled with static linking.

I tell you right now, I'm not going to waste my time down grading software to support slow CPU's without FPU. Having to jump to math library, simple fmuls and fdivs, has overhead, jumps and branches have overhead, registers has to be put in stack, and restored, and return values has be set and so on, I think the math library idea from 90's was wacky idea to begin with. And is not a good direction to be going.

It's more likely be using more double floats in my programs, because its not good idea to mix and match int with float, because of overhead; a FPU while its integrated in CPU this days. Actually works as independent processor unit, there is no way to move a value from a CPU register into a FPU register without storing it on RAM, so makes more sense to write code for the FPU or write the code for CPU instructions. Do not do casting between float and int, or at least as little as possible.

[Spectre660]

Some more intersting results.
Look at the MorphosOS results.

==================================================================================
AmigaOS 4.1 FE Live-For-it-Mplayer

11.AmigaOS 4.1:> mplayer -benchmark -nosound -ao null -vo null -lavdopts skiploopfilter=none
Prometheus-Trailer.mp4
LiveForIt-MPlayer-6.5.7 SVN-r37230-snapshot-1.1.1 (C) 2000-2014 MPlayer Team

BENCHMARKs: VC: 463.903s VO:   0.029s A:   0.000s Sys:   2.854s =  466.786s
BENCHMARK%: VC: 99.3823% VO:  0.0063% A:  0.0000% Sys:  0.6115% = 100.0000%

Exiting... (End of file)
==================================================================================

AmigaOS 4.1 FE  MUI-Mplayer

4.AmigaOS 4.1:> mplayer -benchmark -nosound -ao null -vo null -lavdopts skiploopfilter=none
Prometheus-Trailer.mp4
MPlayer UNKNOWN-4.4.3 (C) 2000-2010 MPlayer Team

BENCHMARKs: VC: 409.400s VO:   0.015s A:   0.000s Sys:   2.576s =  411.991s
BENCHMARK%: VC: 99.3711% VO:  0.0036% A:  0.0000% Sys:  0.6253% = 100.0000%

Exiting... (End of file)
==================================================================================

Morphos 3.9 Mplayer

MPlayer-1.1-svn-2015.05.21/MPlayer -benchmark -nosound -ao null -vo null -lavdopts skiploopfilter=none
Prometheus-Trailer.mp4
MPlayer SVN-r37401 (C) 2000-2015 MPlayer Team

BENCHMARKs: VC: 190.363s VO:   0.009s A:   0.000s Sys:   5.132s =  195.504s
BENCHMARK%: VC: 97.3703% VO:  0.0045% A:  0.0000% Sys:  2.6252% = 100.0000%

Exiting... (End of file)
==================================================================================

Linux Ubuntu 15.10

julian@Sam460ex:~$ mplayer -benchmark -nosound -ao null -vo null -lavdopts skiploopfilter=none
'/home/julian/Documents/Prometheus-Trailer.mp4'
MPlayer2 2.0-728-g2c378c7-4build1 (C) 2000-2012 MPlayer Team

BENCHMARKs: VC: 289.712s VO:  18.294s A:   0.000s Sys:   1.753s =  309.759s
BENCHMARK%: VC: 93.5281% VO:  5.9059% A:  0.0000% Sys:  0.5660% = 100.0000%

Exiting... (End of file)
==================================================================================

[Spectre660]

The bechmark is just supposed to test CPU and bus speed.
Of the 3 OS's OS 4.1 currently is the only one that works with any GPU acceleration. GPU Acceleration dos not work in Linux on the Sam.
But the actual playback under OS 4.1 is degraded because of the slower decoding.
UVD & VDPAU do work well on the Tabor.

@Spectre660

The version of avcodec library that is in LiveForIt-Mplayer was picked to support newer video codecs. Older avcodec library's are faster, but do not play newer video formats. I can go back to older avcodec library, but then complain about new video formats not working, there for I see no point in doing anything about.

We need hardware accelerated video decoding, this is the direction avcodec is going, it get harder and harder to compile stuff, if you do not have hardware acceleration decoding.

As I learned, MorphOS version was compiled without pthreads support, and it also has slightly different avcodec library.

The Linux version can gains speed by using UVD & VDPAU, you are not using it clearly.

[Spectre660]

Anyway we now know that this bechmark as used to compare the
X1000 runing AmigaOS 4.1 to G4 Mac's runing MorphOS is not giving a balanced comparison.

http://www.amiga-news.de/en/news/AN-2012-02-00011-EN.html
http://amigaworld.net/modules/newbb/viewtopic.php?topic_id=37054&forum=45&88

This is what your testing really testing.
Avcodec the version mplayer was compiled with there is big difference between etch version.
newlib or clib depending on how mplayer was compiled.
OS API that newlib or clib depends on.
OS API that mplayer depends on.
The hardware you're running on.
The other programs that runs in background and stealing CPU cycles.

While you have the same code, you compile it; it can end up doing something completely different on different OS.

To make any sense, of anything need to unit test the smallest of things, to find the bottlenecks.

If you have the same code running on two different OS's, and one case the code is slower, and the other is faster, then it's not the CPU or bus speed that is course of it, how the OS and library's was compiled and what has been optimized and what has not.

If what you're testing is not 100% the same you never know way it is slower or faster.

[Spectre660]

What candy thing am I running ?

That's not what I'm saying, your complain to me about speed, I just gave you the answer to way it might be the case.

MorphOS Mplayer uses a older avcodec lib, its compiled without pthreads.
MUI Mplayer OS4 is also using a older version with avcodec I think.

The difference between MPlayer on MorphOS and MUI MPlayer on OS4, if using the same avcodec lib, depends on OS and newlib / clib stuff, that it runs on. And the fact that Mplayer on MorphsOS was its compiled without pthreads.

And you running that candy thing in the background while benchmarking you're going to screw up all tests.

I repeat again, if you won't to find bottlenecks to help out developers improve anything, the only thing that going to help is benchmark every tiny thing, individually. As isolated cased.

If you change too many factors, you cannot make sense of the results.

[Spectre660]

The more time taken by the CPU to decode the video means that it has the remaining time to  do  the display and audio. So if a 60 second clip takes 54 second to just decode you only have 6 seconds to display 60 seconds of video and audio which means that it cant be done in real time.
Thus the reason for this benchmark which does not involve any GPU acceleration .When you actually try to play a 480p MP4 video under OS 4.1 on the Sam460ex it cannot sync the audio and video even in windowed mode with the AmigaOS 4.1FE version of video acceleration with the Radeon HD driver. In Linux it is sync in windowed mode even with no GPU acceleration. On the other hand the same video converted to an xvid avi plays back in full screen mode in perfect sync on the Sam460ex under AmigaOS 4.1FE.Linux cannot do it in fully screen in sync .

Odd, degraded "because of the slower decoding...", why?  

[Spectre660]

Using the SDL audio make no difference. Still out of sync .

Is it possible that there is an issue with the compiler and the amcc 440 core ?

https://lists.mplayerhq.hu/pipermail/mplayer-users/2007-February/065692.html

I that version you using I experimented with AHI, that's way audio is out of sync with video, use SDL audio, and you should have no problem.

I did not won't that version to be uploaded to OS4Depot.net, but it was done anyway.

My best version is 6.5.8 not 6.5.7.

[Spectre660]

Great endorsement .

Been expecting this one.
As for being "crippled", its got better specs than a SAM460.