@Spectre660

Quote:

Trying to establish when the T1022 would have been available from .

As the idea behind Tabor clearly predates the T10XX line, its not that big an issue.
Varisys was suggesting chips like this when the X1000 was being designed.

The availability date of the T10XX line isn't that important if the basic ideas behind Tabor were mapped out before their introduction.

You, personally, have taken more flack for this spec than you are due.
After all, you weren't part of that design decision, and you're doing useful work testing out Tabor under Linux.

@olegil

Quote:

olegil wrote: Hence the ONLY logical explanation can be "we cannot justify delaying this any longer".

The only logical conclusion (well apart from the obvious "they are just clueless") is that Trevor had no input in the choice of SoC as this board is just side-project based on something else Varisys is working.


Sure no proof to back that, but by far makes more sense than:
"We couldn't wait a few months for the allready announced and far better part cos that would have meant Hyperion would not have started porting on the finished HW for those 6 months later on" (or something like that).

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@olegil

Quote:

my current favourite solution would be T1022 + SB850

The neat thing about the T10XX series is that they don't really require a Southbridge.
In fact, a Southbridge would use up the available PCI-e lanes.

I'd rather see a simplified Mini ITX design that uses the cpu alone.

In any case, with at least 1000 Tabor boards to sell, and more likely to be constructed, the chances of seeing a T10XX based solution are greatly reduced.

Want an e5500 cored cpu?
There is still the X5000.

BTW - My favorite solution would now be an e6500 based cpu, with SMP support implemented in the NG OS' ported to it.

@Kronos

Yes, this design choice probably was Varisys' decision.
They have a lot of talented people, but are not really oriented toward Amiga solutions.

They did encourage the shift to Qorlq cpus, the X5000 has one.
But since the basic idea behind Tabor probably predates the T10XX series, well this is what they decided on.

Its a shame that the e500mc based chips cost more than the e500v2 based chips, as the use of the former would have circumvented the fpu issue.

Last edited by iggy on 21-Oct-2015 at 09:04 PM.
Last edited by iggy on 21-Oct-2015 at 03:05 PM.

@iggy

The neat thing about the SB850 is that it has tons of SATA, USB and PCIe x1 lanes, so you don't actually LOSE any PCIe. You in fact GAIN them.

_________________
This weeks pet peeve:
Using "voltage" instead of "potential", which leads to inventing new words like "amperage" instead of "current" (I, measured in A) or possible "charge" (amperehours, Ah or Coulomb, C). Sometimes I don't even know what people mean.

Interesting paper of floating point emulation.

http://www.ll.mit.edu/HPEC/agendas/proc08/Day1/11-Day1-PosterDemoA-Spetka-abstract.pdf

_________________
Sam460ex : Radeon Rx550 Single slot Video Card : SIL3112 SATA card

@Spectre660

Quote:

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

It doesn't apply here, since the e500v2 has hardware support for executing floating point operations. The problem is this FPU (because it's an FPU, at end) is totally incompatible with the normal PowerPC FPU.

Anyway, you have the board, and I already asked to do some test with Debian PowerSPE, using exactly the same application (FPU intensive ones), but with FPU emulation (trapping) and with SPE respectively: why don't you make same test?

@cdimauro

Help me to understand clearly by correcting me were I am wrong.
(1) The SPE uses its native FP operations. this one is seems clear.
(2) On the powerpc32 version the kernel traps the FP operations and uses generic non SPE
operations to emulate them.
if #2 above is correct would is be possible to use SPE instructions for the emulation in the AmigaOS Kernel or not ?
If so would this not be faster than #2 with the non SPE operations. ?


Quote:

cdimauro wrote: @Spectre660 Quote: Spectre660 wrote: Interesting paper of floating point emulation. http://www.ll.mit.edu/HPEC/agendas/proc08/Day1/11-Day1-PosterDemoA-Spetka-abstract.pdf It doesn't apply here, since the e500v2 has hardware support for executing floating point operations. The problem is this FPU (because it's an FPU, at end) is totally incompatible with the normal PowerPC FPU. Anyway, you have the board, and I already asked to do some test with Debian PowerSPE, using exactly the same application (FPU intensive ones), but with FPU emulation (trapping) and with SPE respectively: why don't you make same test?

_________________
Sam460ex : Radeon Rx550 Single slot Video Card : SIL3112 SATA card

@Spectre660

Quote:

Spectre660 wrote: @cdimauro Help me to understand clearly by correcting me were I am wrong. (1) The SPE uses its native FP operations. this one is seems clear. The code can use the SPE unit, through its instructions, for doing FP operations. [quote](2) On the powerpc32 version the kernel traps the FP operations and uses generic non SPE operations to emulate them.

Yes.
Quote:

if #2 above is correct would is be possible to use SPE instructions for the emulation in the AmigaOS Kernel or not ?

Yes.
Quote:

If so would this not be faster than #2 with the non SPE operations. ?

Yes. And IMO that's what the Debian PowerSPE kernel does when it executes an application which uses the regular FPU instructions.

But, even better, you can try applications directly compiled to use the SPE instructions, without requiring any trap-and-emulate mechanism.

Please, do some test, as I requested, so it'll be useful to see how both scenarios are handled by this CPU. Thanks.

@olegil

Actually, since there are a limited number of PCI-e lanes on the T10XX series, using them to connect a Southbridge would mean that the video card could not be directly connected.

While the SB850 does provide PCI-e X1 connections, generally video cards are not connected to a Southbridge, as all data still travels to the cpu (or Northbridge) via the Southbridge's PCI-e connections.

@cdimauro

looks like the Debian 8 powepcSPE is by default compilinge binaries for SPE .

root@TaborPowerPCSPE:/home/julian# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/powerpc-linux-gnuspe/4.9/lto-wrapper
Target: powerpc-linux-gnuspe
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-10' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libitm --disable-libsanitizer --disable-libquadmath --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-powerpcspe/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-powerpcspe --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-powerpcspe --with-arch-directory=ppc --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-secureplt --disable-multilib --enable-multiarch --with-cpu=8548 --enable-e500_double --with-long-double-128 --enable-checking=release --build=powerpc-linux-gnuspe --host=powerpc-linux-gnuspe --target=powerpc-linux-gnuspe
Thread model: posix
gcc version 4.9.2 (Debian 4.9.2-10)
root@TaborPowerPCSPE:/home/julian#

_________________
Sam460ex : Radeon Rx550 Single slot Video Card : SIL3112 SATA card

@Spectre660: yes, it was stated on the Debian PowerPCSPE wiki page.

@cdimauro

Quote:

cdimauro wrote: Altivec: [...] - has support for different datatypes; - supports data streams to better handle data flows; - has 4 operands instructions. Regarding the last 3 sentences, I've to check if SPE offers some support. I had not time to see the details of the SPE unit: I'll do it this week-end, if possible.

I had some time, so I took a look at e500v2 reference manual. I can confirm that the SPE unit has nothing of those 3 sentences.

Also is has only the most simple floating operation operations (some more complicated, like the square root, as missing). So it means that emulating FPU instructions requires more time in this case.

Last but not least, there are from 3 to 8 clock cycles that should pass BEFORE starting to fetch and execute the first instruction (which takes at least 7 cycles, since it starts from the "fetch" pipeline stage) of the proper interrupt vector called by the FPU trap mechanism. But, of course, more instructions are executed for emulating an FPU instruction, and it takes time. Plus, at the end, the instruction to return from the interrupt takes a similar time as the beginning (from 3 to 8 clocks + at least 7 clocks for executing the subsequent instruction).

So, as it can be seen, executing FPU-intensive applications will be slow.

Tests with real-world applications are welcome...

@cdimauro

Lame ppcSPE performs a little faster than a Sam440ep-flex 800mhz.

Quote:

cdimauro wrote: @Spectre660: yes, it was stated on the Debian PowerPCSPE wiki page. @cdimauro Quote: cdimauro wrote: Altivec: [...] - has support for different datatypes; - supports data streams to better handle data flows; - has 4 operands instructions. Regarding the last 3 sentences, I've to check if SPE offers some support. I had not time to see the details of the SPE unit: I'll do it this week-end, if possible. I had some time, so I took a look at e500v2 reference manual. I can confirm that the SPE unit has nothing of those 3 sentences. Also is has only the most simple floating operation operations (some more complicated, like the square root, as missing). So it means that emulating FPU instructions requires more time in this case. Last but not least, there are from 3 to 8 clock cycles that should pass BEFORE starting to fetch and execute the first instruction (which takes at least 7 cycles, since it starts from the "fetch" pipeline stage) of the proper interrupt vector called by the FPU trap mechanism. But, of course, more instructions are executed for emulating an FPU instruction, and it takes time. Plus, at the end, the instruction to return from the interrupt takes a similar time as the beginning (from 3 to 8 clocks + at least 7 clocks for executing the subsequent instruction). So, as it can be seen, executing FPU-intensive applications will be slow. Tests with real-world applications are welcome...

_________________
Sam460ex : Radeon Rx550 Single slot Video Card : SIL3112 SATA card

@cdimauro

Quote:

- "string" instructions are also unsupported and trap every time;

Apparently, it's worse than that --- the SPE instruction encodings collide with the encodings used by the "string" instructions (and altivec). So if an executable uses string instructions (or altivec), those instructions may not trap, but rather silently do something completely different than what was intended.

@umisef

Quote:

SPE instruction encodings collide with the encodings used by the "string" instructions

wasnt that the kind of showstopper that made coldfire kind of compatible to 68k but not faster as soon as it has been tested. this might be conclusion that put the end to ultimate_ppc, sice we had these string instructions/fpu debate being mentioned by some insiders. the sam 440 kind of performance wouldnt exactly cut it, especially if not restricted to fpu. wouldnt be worth to invest in magnitude of boards except the know what to do. hope they have considered it.

@Spectre660

Quote:

Spectre660 wrote: @cdimauro Lame ppcSPE performs a little faster than a Sam440ep-flex 800mhz.

Thanks!

That's good enough for this kind of processor. Other applications (like Blender, which makes more use of floating point operations) might have better results.

One last thing. If you plan to do other benchmarks, try to use just one processor. Setting the thread affinity helps here, albeit it's not the same as turning off the second core.


@umisef

Quote:

umisef wrote: @cdimauro Quote: - "string" instructions are also unsupported and trap every time; Apparently, it's worse than that --- the SPE instruction encodings collide with the encodings used by the "string" instructions (and altivec). So if an executable uses string instructions (or altivec), those instructions may not trap, but rather silently do something completely different than what was intended.

I hadn't time to check the opcode table here.

That's a very bad new. I don't know how much those instructions are used on applications (maybe emulators use them), but this requires proper binaries compiled.

For Altivec overlap I don't think that it's a problem, because I think that it's very likely that the application crashes soon just after starting the first computation.


@wawa

Quote:

wawa wrote: @umisef Quote: SPE instruction encodings collide with the encodings used by the "string" instructions wasnt that the kind of showstopper that made coldfire kind of compatible to 68k but not faster as soon as it has been tested. this might be conclusion that put the end to ultimate_ppc, sice we had these string instructions/fpu debate being mentioned by some insiders. the sam 440 kind of performance wouldnt exactly cut it, especially if not restricted to fpu. wouldnt be worth to invest in magnitude of boards except the know what to do. hope they have considered it.

Yes, Coldfires have overlapping instructions with other standard 68K instructions. Plus they use Line-A opcodes, if I remember correctly, that prevents the use of Mac emulators, for example.

@iggy

Wrong.

T1022 has up to 8 PCIe lanes, wiring these as two x4 interfaces is not a problem.

That's one x4 to SB850, with 6 x1 downstream for slots.
Plus one x4 for graphics, in a x16 slot.

You don't need to use the serdes for GbE (there are two RGMII), and SATA can come off the SB850.

Without an SB you can only get x4 + x1 + x1 + one SATA + one extra either SATA or x1 PCIe. And only two USB. No audio. This is why even I (who normallly advocate sticking with the interfaces the SoC has rather than adding anything) am for it.

_________________
This weeks pet peeve:
Using "voltage" instead of "potential", which leads to inventing new words like "amperage" instead of "current" (I, measured in A) or possible "charge" (amperehours, Ah or Coulomb, C). Sometimes I don't even know what people mean.

@cdimauro

Debian 8 results using non-smp kernels

Lame (AKsck.wav)

lame '/home/julian/Documents/AKsack.wav'

Sam460ex

Encoding /home/julian/Documents/AKsack.wav
to /home/julian/Documents/AKsack.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III (11x) 128 kbps qval=3
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
10529/10529 (100%)| 0:43/ 0:43| 0:45/ 0:45| 6.2934x| 0:00
-------------------------------------------------------------------------------

Tabor SPE

Encoding /home/julian/Documents/AKsack.wav
to /home/julian/Documents/AKsack.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III (11x) 128 kbps qval=3
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
10529/10529 (100%)| 1:07/ 1:07| 1:09/ 1:09| 4.0484x| 0:00
-------------------------------------------------------------------------------


Mplayer (Prometheus-Trailer)

mplayer -benchmark -nosound -ao null -vo null -lavdopts skiploopfilter=none '/home/julian/Documents/Prometheus-Trailer.mp4'

Sam460ex

BENCHMARKs: VC: 269.653s VO: 17.698s A: 0.000s Sys: 1.671s = 289.022s
BENCHMARK%: VC: 93.2984% VO: 6.1233% A: 0.0000% Sys: 0.5783% = 100.0000%

Tabor SPE

BENCHMARKs: VC: 220.144s VO: 27.725s A: 0.000s Sys: 6.090s = 253.959s
BENCHMARK%: VC: 86.6848% VO: 10.9171% A: 0.0000% Sys: 2.3980% = 100.0000%

_________________
Sam460ex : Radeon Rx550 Single slot Video Card : SIL3112 SATA card

@Spectre660

But that's using SPEFP instructions, not traps. Right?

Personally I need video decoding more than I need audio encoding, but obviously the lame (hehe) numbers show exactly the performance problem that has been discussed in this thread.

_________________
This weeks pet peeve:
Using "voltage" instead of "potential", which leads to inventing new words like "amperage" instead of "current" (I, measured in A) or possible "charge" (amperehours, Ah or Coulomb, C). Sometimes I don't even know what people mean.

@olegil

Yes it is using the SPEP instructions.
We will see how well the AmigaOS 4.x FPU implementation works.


These are Sam440ep-Flex 800mhz AmigSO 4.1 lame results .
So in theory if a SPE binary can be done for specific programs then
it may be worth it.

Encoding Work:Downloads/AKsack.wav to Work:Downloads/AKsack.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III (11x) 128 kbps qval=3
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
10529/10529 (100%)| 1:15/ 1:15| 1:15/ 1:15| 3.6575x| 0:00
-------------------------------------------------------------------------------


Quote:

olegil wrote: @Spectre660 But that's using SPEFP instructions, not traps. Right? Personally I need video decoding more than I need audio encoding, but obviously the lame (hehe) numbers show exactly the performance problem that has been discussed in this thread.

_________________
Sam460ex : Radeon Rx550 Single slot Video Card : SIL3112 SATA card

Still no official info release about Tabor A1222 anywhere?

If 1000 units are really being produced, that clearly indicate that no-one is doing T10xx based "Amiga" system yet.

Anyway.
Below EUR1000 system to replace my SAM440 is interesting vs the EUR2000 alternative.
Just need to see how it works with FPU using SW.

_________________
- KimmoK
// For freedom, for honor, for AMIGA
//
// Thing that I should find more time for: CC64 - 64bit Community Computer?