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

[broadblues]

Yet many masochists *do* choose to run it on AmigaONE branded hardware. ;-)

I run it on a SAM-Flex 440 733MHz, works okay. I mean it's not going to knock out the likes of Sintel or Tears of Steel, but it's okay for small projects and editing music videos.

I admit if I'm in a hurry I use my loonix laptop with a more recent version of blender, but I like using it on the SAM.  But my loonix laptop stil falls far short of those specs posted above!


It also works on the x1k but I don;t have a Warp3D capable gfx card and so WaZp3D is a bit sloe and glitchy.

[Iggy]

@Iggy

whoops. try morph-files instead.

-- eliyahu

VERY cool!
Thanks.

BTW - I just noticed you were in the US, and on the East coast.

[nicholas]

I run it on a SAM-Flex 440 733MHz, works okay. I mean it's not going to knock out the likes of Sintel or Tears of Steel, but it's okay for small projects and editing music videos.

I admit if I'm in a hurry I use my loonix laptop with a more recent version of blender, but I like using it on the SAM.  But my loonix laptop stil falls far short of those specs posted above!


It also works on the x1k but I don;t have a Warp3D capable gfx card and so WaZp3D is a bit sloe and glitchy.

Doing stuff it's not ideally suited for is all part of the joy of using old and quirky hardware.

[Spectre660]

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

[matthey]

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

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]

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 .

[matthey]

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

Yes, depending on restrictions and requirements of the method used. IEEE compatibility and similar accuracy and behavior as the standard PPC FPU are requirements for emulating or trapping the PPC FPU without problems. There are many ways to get floating point support with the P1022 CPU with widely varying performance.

1) Best: Recompiling software to use the P1022 GPR FPU should give good FP performance but the executable will only work on the Tabor board. This is hardware FP.
2) Good: Recompiling software to use software floating point should give fair FP performance and should work on standard PPC hardware with or without an FPU. This is software FP usually using a floating point library provided by the compiler.
3) Poor: Emulation or JIT emulation of the standard PPC FPU gives fair performance without recompiling but with much development time, overhead and resources used for the emulation and possibly bugs or problems due to the complexity. The results of this method were not shown in the article you linked.
4) Bad: Trapping all the standard PPC FPU instructions and emulation of the standard FPU has major overhead for each trapped instruction but recompiling is not needed and it is simpler than (JIT) emulation. The results of this method would be the FastFPE and NWFPE method in the article you linked.

[Iggy]

... Bad: Trapping all the standard PPC FPU instructions and emulation of the standard FPU has major overhead for each trapped instruction but recompiling is not needed...

-
Uh oh.

[Spectre660]

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

-
Uh oh.

[duga]

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

And 720p@Youtube?

[Spectre660]

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

And 720p@Youtube?

[Iggy]

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

OK, its a start.
Maybe Hyperion needs your input as recompilation seems to be the best course with this cpu.
Recompiling what can be, and resorting to trapping/emulation as only a secondary method for execution.

[nicholas]

OK, its a start.
Maybe Hyperion needs your input as recompilation seems to be the best course with this cpu.
Recompiling what can be, and resorting to trapping/emulation as only a secondary method for execution.

Perhaps having the entire OS as shipped by Hyperion recompiled specifically for this CPU and then just having trapping for third party binaries that the end user installs might be a good compromise?

Plus third party devs can always ship two binaries with their future releases as was the case with 040/060 specific builds in the past.

[matthey]

Perhaps having the entire OS as shipped by Hyperion recompiled specifically for this CPU and then just having trapping for third party binaries that the end user installs might be a good compromise?

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.

Plus third party devs can always ship two binaries with their future releases as was the case with 040/060 specific builds in the past.

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.

[EvilGuy]

If you are not up to challenges presented by hardware or software limitations, then you probably shouldn't code at all.

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

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