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

[nicholas]

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.

Sounds like this would be the least worst way forward then. IIRC something similar is already in place for the X1000 boards because of missing/modified CPU instructions and the same for G5 specific builds on MorphOS. (Recompiled CPU specific builds that is, not trapping.)

[Iggy]

The challenges with developing for the Amiga aren't hardware or software related..

No, you are right, the primary challenge is the limited/small market.

[kolla]

What prevents binaries from asking the OS about the abilities of the hardware, and run code accordingly? I mean, other operating systems manage to have "fat" binaries that contain entirely different architectures, but on Amiga it is not even possible to have one binary for variations within one architecture.

[QuikSanz]

What prevents binaries from asking the OS about the abilities of the hardware, and run code accordingly? I mean, other operating systems manage to have "fat" binaries that contain entirely different architectures, but on Amiga it is not even possible to have one binary for variations within one architecture.

Question of the day! Why not query the system?

Chris

[Hans_]

What prevents binaries from asking the OS about the abilities of the hardware, and run code accordingly? I mean, other operating systems manage to have "fat" binaries that contain entirely different architectures, but on Amiga it is not even possible to have one binary for variations within one architecture.

This is already done in various programs for altivec/non-altivec code. The W3D_SI driver, for example, will use altivec on hardware that has it, and non-altivec code on machines that don't. The graphics library goes one step further and has copy routines that are optimized for specific processors (incl. using DMA on certain platforms). IIRC, MiniGL has a few altivec routines as well.

The examples above are a bit different from simply having a fat binary with completely different compiles sitting there side-by-side. Instead, the developer himself/herself compiles different versions of just the parts that matter. I personally prefer that approach, as the sections of a program that actually benefit from altivec/SPE/whatever is usually limited.

Hans

[EvilGuy]

No, you are right, the primary challenge is the limited/small market.

Yeah, yeah, definitely that too. Small ponds, big fish and all that as well.

[kolla]

This is already done in various programs for altivec/non-altivec code. The W3D_SI driver, for example, will use altivec on hardware that has it, and non-altivec code on machines that don't. The graphics library goes one step further and has copy routines that are optimized for specific processors (incl. using DMA on certain platforms). IIRC, MiniGL has a few altivec routines as well.

Good, that is how it should be.

The examples above are a bit different from simply having a fat binary with completely different compiles sitting there side-by-side. Instead, the developer himself/herself compiles different versions of just the parts that matter. I personally prefer that approach, as the sections of a program that actually benefit from altivec/SPE/whatever is usually limited.

Which is really what I meant, it should not be such a big deal, not like OS4 has this vast portfolio of abandoned native software anyhow.

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

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

[Iggy]

@Spectre660

So we now now that Linux would outperform Amiga NG solutions (and that MorphOS would outperform OS4).
That we all would have pretty much presumed, but they figure are interesting.

I wonder how a Linux hosted version of AROS would have compared.

[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)
==================================================================================

[Iggy]

@Spectre660

Interesting.
What causes that much variance?
Is it the differing source files or the settings?

[matthey]

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.

The most popular free sound and video players are based on mplayer and ffmpeg. There are all integer codecs/plugins. The 68k mpega.library, Riva and MooVid show what fast integer codecs can do. My 68060@75MHz plays MP3s and MPEG videos (up to 640x480) without problems despite lacking 32x32=64 bit integer multiply in hardware and lacking fast DSP like instructions which accelerate integer codecs. I wouldn't be surprised if the Apollo core in FPGA is able to play 720p video using an integer codec.

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.

I agree with what you are saying here. There are developers who will not want to mess with recompiling software for a non-standard CPU. Standard hardware allows for more optimal software without the need for fat binaries, patching and creating hardware specific codecs/plugins and/or recompiling for specific hardware. The amount of developer time wasted for multiple compiles, patching and debugging on non-standard hardware is often underestimated and especially deadly to a small market with limited development resources. Standard hardware floating point support using direct floating point instructions in the code is needed for competitive modern general purpose computing. Without this, the Amiga will fall further and further behind. Embedded PPC processors are already behind the curve and the situation is likely to get worse.

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.

A superscalar CPU has independent units which work in parallel as you say. This makes it advantageous to work on mixed (integer, FPU, SIMD) instructions in the code as otherwise the unused units are idle. The compiler instruction scheduler will schedule these instructions to keep as many CPU units busy as possible even if integer and floating point parts of the source are separated. You are also correct that transferring data between CPU units can have significant overhead. Pipeline bubbles can be generated when transferring data between units using instructions or the DCache with longer pipelines giving longer stalls. Depending on the CPU design, these stalls may be avoided by not touching the transferred data for several cycles. The instruction scheduler may improve these situations also although the results can vary. In general, mixing float and integer is good but the programmer should try to reduce the number of float<->int conversions.

[dooz]

I done some quick browsing and found this news on:

http://www.software4embedded.de/node/9844

Quote:
15.10.2012 | 14:27 Uhr
Freescale Semiconductor introduced  four new devices for their QorIQ T1 and T2 families of 64-bit processor  families. The new processors are the T1040, T1020, T1022, and T2081. The  new Freescale devices are built on Power Architecture technology. All  of the parts are pin-compatible. They are ideal for entry-level to  mid-range networking, printing and security device applications. Samples  of the T1040 device will be available in the third quarter of 2013. The  other T1 and T2 devices will follow soon after.

That  statement was really only annoucement. What really happened is that T  series, T1022 samples were probably available more close to the end of  2013. So far we learned that it takes minimum about 2.5 years to develop  hardware like Tabor, so Tabor was probably one years already in  development when T series could be "considered" for a product.

If  we look what was Freescale CPUs were available as a option 2.5 years  ago, the logical choice is.... suprise.... P1022 ;-) All other P10xx CPU  options doesnt offer anything new. So the first next option would be to  use P2041 which is based on e500mc core with normal FPU (P2040 doesnt  have gigabit ethernet). But.... those are quad core CPUs... not really  low end suitable solution for low-end Tabor. The same story is valid  also for P3041.

These are the prices for P and T processor from the Freescale web page (for 1000 units):

P1022: US$30.13
P2041: US$129.06 (1.2 GHz)
P2041: US$161.89 (1.5 GHz)
P3041: US$137.66 (1.2 GHz)
P3041: US$181.70 (1.5 GHz)
T1022: US$43.07 (1.2 GHz)
T1022: US$51.68 (1.4 GHz)

So  P20xx is too expensive for low-end, T10xx was not available. Who would  really stop one year development because new CPU is around the corner!?  And when you do that, maybe new thing will arrive so you really never  release the product.

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

P1022 is a snapshot of present moment  when we can have Tabor as it is right now. Otherwise we wouldn not have  this board at all. All other options are in future development.

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. This very-low-end is recognizable if  you study the board further (only one PCIe slot, mini-ITX format, P1022,  everything else i integrated). So if CPU is different then we would  probably start asking about many other aspects of the board (for  example...why only one PCIe slot...etc.)

At the end this board is low-end with I hope very acceptable price. Its not something in the middle way to X5000 range.

Well all that is only my opinion.....feel free to correct...

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

[OlafS3]

I done some quick browsing and found this news on:

http://www.software4embedded.de/node/9844

Quote:
15.10.2012 | 14:27 Uhr
Freescale Semiconductor introduced  four new devices for their QorIQ T1 and T2 families of 64-bit processor  families. The new processors are the T1040, T1020, T1022, and T2081. The  new Freescale devices are built on Power Architecture technology. All  of the parts are pin-compatible. They are ideal for entry-level to  mid-range networking, printing and security device applications. Samples  of the T1040 device will be available in the third quarter of 2013. The  other T1 and T2 devices will follow soon after.

That  statement was really only annoucement. What really happened is that T  series, T1022 samples were probably available more close to the end of  2013. So far we learned that it takes minimum about 2.5 years to develop  hardware like Tabor, so Tabor was probably one years already in  development when T series could be "considered" for a product.

If  we look what was Freescale CPUs were available as a option 2.5 years  ago, the logical choice is.... suprise.... P1022 ;-) All other P10xx CPU  options doesnt offer anything new. So the first next option would be to  use P2041 which is based on e500mc core with normal FPU (P2040 doesnt  have gigabit ethernet). But.... those are quad core CPUs... not really  low end suitable solution for low-end Tabor. The same story is valid  also for P3041.

These are the prices for P and T processor from the Freescale web page (for 1000 units):

P1022: US$30.13
P2041: US$129.06 (1.2 GHz)
P2041: US$161.89 (1.5 GHz)
P3041: US$137.66 (1.2 GHz)
P3041: US$181.70 (1.5 GHz)
T1022: US$43.07 (1.2 GHz)
T1022: US$51.68 (1.4 GHz)

So  P20xx is too expensive for low-end, T10xx was not available. Who would  really stop one year development because new CPU is around the corner!?  And when you do that, maybe new thing will arrive so you really never  release the product.

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

P1022 is a snapshot of present moment  when we can have Tabor as it is right now. Otherwise we wouldn not have  this board at all. All other options are in future development.

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. This very-low-end is recognizable if  you study the board further (only one PCIe slot, mini-ITX format, P1022,  everything else i integrated). So if CPU is different then we would  probably start asking about many other aspects of the board (for  example...why only one PCIe slot...etc.)

At the end this board is low-end with I hope very acceptable price. Its not something in the middle way to X5000 range.

Well all that is only my opinion.....feel free to correct...

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

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

you have looked in your glass ball or wishful thinking?

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