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

[LiveForIt]

Most of the AmigaOS does not need floating point so only a few modules need to be recompiled. A modified version of AmigaOS is already needed for standard PPC FPU trap support and emulation. This is not a problem.



Right. It's more work and time for developers but this is the best option when there is so much difference in floating point performance between full trapping and recompiling. The partial FPU trapping of the 68040 or 68060 for 6888x instructions usually provides better performance than the 6888x and usually with less than a 20% performance loss compared to recompiling for the 68040 or 68060 FPU.

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.

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

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

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

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

[LiveForIt]

@matthey

Accelerating video processing by SIMD and DSP like instructions in the CPU has advantages for many types of of programs.

Sure it can, but it's like learning a new language in the case of SIMD (AltiVec), I also find hard to find good documentation on how to use it. the basic idea is that you can multiplay 4 values at the same time, or divide 4 values at the same time, so if you are working normal code, find places where you can do tings in steps of 4. So you can optimize a lot but not everything.

As for DSP is normally referees to some coprocessor, many codecs in avcodec requires a DSP.

[LiveForIt]

@kolla

Youtube