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

[LiveForIt]

@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.

[LiveForIt]

@matthey

Sure you can reserve a few gate array's for DCT, Deblocking and color space conversion, accelerate speed on FPGA. However I do not think you, be able to play H264 video buy just simulating normal CPU instructions. But FPGA's are pretty expensive, how many gate will you need to do that on FPGA, and will it cost you more than buying a ASIC from Broadcom, VIA or Intel.

[dooz]

Dramatically faster SOON with second core in use? :angry:

you have looked in your glass ball or wishful thinking?

.....dramatically faster if second core will be soon in use.....

I wrote *IF* as a keyword here, and that is completely different meaning.

But anyway, without multicore support all this hardware is not used 100% and that is the main disadvantage of every new product.

SPE and non-standard FPU in P1022 is not that important IMHO. At least there is some kind of FPU that we can use somehow.

No multicore support should be our primary concern both with A1222 and X5000.

------
Domagoj Ozanic (domagoj.ozanic@zg.t-com.hr)
Amiga WARP Organization http://www.amigawarp.org
A1200T Blue Thunder Tower (BTT) - AmigaOS 4.1 FE
BlizzardPPC 200 MHz / BVisionPPC / 256 MB RAM

[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.

[LiveForIt]

The benchmark is just supposed to test CPU and bus speed.

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.

[wawrzon]

.....dramatically faster if second core will be soon in use.....

I wrote *IF* as a keyword here, and that is completely different meaning.

in other words usual case of someone entering discussion to post his dreams and visions.

[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.

[LiveForIt]

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.

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 of avcodec, (don't know they are the same, should be).

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 cases.

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

[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.

[Iggy]

...why integrate 64-bit processor when  there is no 64-bit support in OS, also why integrate quad core processor  when there is no multicore support in OS. There is no space for unsued  things in low-end product.

...Tabor  is a very-low-end and low-cost AmigaOS4 (I hope also MorphOS) PPC  configuration which is affordable for every Amigan to buy. It is also  very powerfull because its faster that SAM460, dramatically faster if  second core will be soon in use.

Why? Because I want it, and it adds minimal cost.
And there will be uses for these in the future (hey, I'm optimistic).

Faster? Slightly until the fpu issues are factored in.

And while it is dual core..."why integrate quad core processor  when there is no multicore support in OS", so why integrate a dual core.
You do know there are single core T10XX cpus, don't you?

...Of the 3 OS's OS 4.1 currently is the only one that works with any GPU acceleration. ..
But the actual playback under OS 4.1 is degraded because of the slower decoding...

Odd, degraded "because of the slower decoding...", why?
And you make it sound like AROS and MorphOS don't use GPU acceleration at all.
For decoding, true.
But for 2D and 3D graphics acceleration, untrue (although, MorphOS does not to implement that for the Radeon HD cards).

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.

Yes, comparing processors with significant differences is tricky.
Also, as MorphOS usual has a slight performance advantage on similar platforms, again, not a fair comparison.

What candy thing am I running ?

I thought everyone was clear that you are working with Linux, not OS4 (where you would find Candi).

[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?  

[Iggy]

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 .

Ah, I did not examine those closely enough.
So gPU acceleration is a good thing.
I'm curious as to how Hyperion implemented it.
I thought the primary reason that Linux and MorphOS didn't use it was the difficulty in getting really complete documentation for GPUs themselves.

I mean, when you compare Linux systems that have proprietary drivers supplied by the gpu manufacturers to systems with open drivers you see a big performance hit in the latter.

[LiveForIt]

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]

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.

[mongo]

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.

You don't have to decode the whole video before you can start playing it. As long as you're not using more than 6 seconds of CPU time to display the video frames and play the audio you can play the video in real time no problem. The only problem is if you use more than 60 seconds to decode a 60 second video.

[matthey]

Sure you can reserve a few gate array's for DCT, Deblocking and color space conversion, accelerate speed on FPGA. However I do not think you, be able to play H264 video buy just simulating normal CPU instructions. But FPGA's are pretty expensive, how many gate will you need to do that on FPGA, and will it cost you more than buying a ASIC from Broadcom, VIA or Intel.

Accelerating video processing by SIMD and DSP like instructions in the CPU has advantages for many types of of programs. CPU non-general purpose video support like Intel's Quick Sync probably gives the most acceleration but I don't know if it necessary. The following is a benchmark of encoding a 449 MB, four-minute 1080p file to 1024×768 (CPU is a Core i7 3770).

Software encoding = 172 seconds
AMD Radeon HD 6870 = 86 seconds
Nvidia GeForce GTX 570 = 83 seconds
Quick Sync Video in i7 = 22 seconds

This shows how effective CPU specific acceleration can be but it also may benefit from being a popular hardware standard. Video acceleration on these gfx boards goes across the gfx bus which adds latency and the support is less standard. Integrating standard gfx on the motherboard could potentially reduce this overhead. I would like to see the Amiga go back to custom standardized hardware including the CPU and integrated graphics.