@pavlor: we know it. See "Blender Tabor powerpc32".

And I doubt that "Hyperion´s FPU emulation" will be better than Debian/PowerPCSPE FPU emulation.

@cdimauro

Quote:

we know it. See "Blender Tabor powerpc32".

That is Blender on powerpc32 (not powerpcspe!) Linux.

@pavlor: that should be Blender PowerPC (not SPE) that runs on Debian SPE.

He cannot install the SPE version of Blender, but the PowerPC version can be used on such distro, and make use of the FPU emulation which internally uses the SPE unit.

However, let Spectre660 clarify it.

Pavlor is correct.
Dependency issues prevent the powerpc32 Blender from running under powerpcspe

@cdimauro

Quote:

cdimauro wrote: @pavlor: that should be Blender PowerPC (not SPE) that runs on Debian SPE. He cannot install the SPE version of Blender, but the PowerPC version can be used on such distro, and make use of the FPU emulation which internally uses the SPE unit. However, let Spectre660 clarify it.

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

You guys DO realize that Spectre660 job doesn't entail giving you info to base estimates of standard fpu emulation via spes?
Don't you?

Its a given that it can't be as fast as a standard fpu, in that the illegal op codes need to be trapped, then the translation software has to interpret the intended instruction and execute a substitute via spe instructions.
But that still has to be faster than using integer instructions to simulate fpu instructions.

Right now, recompilation looks like the best option for retaining performance, but that requires specifically compiled binaries.

Let's give Hyperion's programmers a chance to create the initial solution, with the qualifier that that will probably improve with time.

@Spectre660

Quote:

Spectre660 wrote: Pavlor is correct. Dependency issues prevent the powerpc32 Blender from running under powerpcspe

That is no good answer unless you specify what kind of dependencies you are talking about.

And dedicated binaries are always best, which is why I use source based system management instead of binary package based ones.

Last edited by kolla on 22-Oct-2015 at 10:57 PM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

The Debian 8 powerpcspe distribution has its quirks and the Tabor installation also has its share .
Dependencies is not a area that I am very good in .


root@TaborPowerPCSPE:/home/julian/Downloads# apt-get install blender
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
blender : Depends: blender-data (= 2.74+dfsg0-2) but it is not going to be installed
Depends: libavdevice55 (>= 6:11~beta1) but it is not installable
Depends: libopenimageio1.4 but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
root@TaborPowerPCSPE:/home/julian/Downloads#

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

@Spectre660

Quote:

Spectre660 wrote: Pavlor is correct. Dependency issues prevent the powerpc32 Blender from running under powerpcspe

OK. I've got confused because you put no o.s. for Tabor result, and Debian 8 for the subsequent 460ex.

So, currently we have only one data for the FPU emulation without using the SPE unit.


@iggy

Quote:

iggy wrote: You guys DO realize that Spectre660 job doesn't entail giving you info to base estimates of standard fpu emulation via spes? Don't you?

Well, NOW it's clear.
Quote:

Its a given that it can't be as fast as a standard fpu, in that the illegal op codes need to be trapped, then the translation software has to interpret the intended instruction and execute a substitute via spe instructions. But that still has to be faster than using integer instructions to simulate fpu instructions.

Absolutely, but don't expect big changes, because the trap mechanism is slow itself. It takes at least 10 cycles (minimum 3 + 7; see my comment #671... or the e500v2 reference manual) to just execute the first instruction of the trap handler. In 10 cycles the SPE unit can execute up to 20 floating instructions, to give an idea of the great differences between native and trapped execution.
Quote:

Right now, recompilation looks like the best option for retaining performance, but that requires specifically compiled binaries.

That's what we already said.
Quote:

Let's give Hyperion's programmers a chance to create the initial solution, with the qualifier that that will probably improve with time.

They cannot make miracles. Take at look a the e500v2 manual, and you can see yourself how long takes the trap mechanism (in best and worst conditions). That's something that cannot be avoided, whatever optimization you can bring out.

But let's wait and see... in "two weeks".

@cdimauro

Quote:

But let's wait and see... in "two weeks".

In this case rather "When it is done".


I hope A1-A1222 will arrive soon enough. Christmas is of course out of question, but 31st Amiga Anniversary could be ideal time.

@cdimauro

Quote:

just execute the first instruction of the trap handler. In 10 cycles the SPE unit can execute up to 20 floating instructions

There is a compelling argument for compiling specific binaries in that statement.

@iggy

Quote:

iggy wrote: Varisys is a hardware design company, one that only recently has been asked to design Amiga hardware.

I'm sorry, but I fail to see the "Amiga" about this H/W, so why would it be such a special challenge? It's simply a standard SoC soldered to a PCB with traces for memory chips, PCIe, connectors, etc. And no, one of the the key points of OS4 (and the rest of the "NG" OS's) was to break free of special, custom Amiga H/W...

OT:
Not that this is my point in this post, but fact is it's not even called "Amiga" (despite the borderline infringement by using the "A12xx" model name). And IMHO, having things like MAI Articia-S, "Xorro/Xena/whatever", and now the e500v2, is not exactly helping the image of the "Amiga" trade mark...
/OT

@Spectre660, @umisef

Quote:

Spectre660 wrote: Anyway A-Eon now own DvPlayer and Tunenet. Two programs that would be affected by the FPU emulation speed. So special SPE floating point versions of these should not be a problem.

Quote:

umisef wrote: 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 think the instruction overlapping problem was established very early on in this thread, but this hasn't stopped people talking about trapping.

Isn't the only realistic way to tackle this to have the OS identifying this CPU very early on in the boot process and then make the OS ignore all HW access to the FPU, making the OS handling everything FPU in S/W emulation in order to provide the proper Book-E/PowerISA necessary for the already existing Amiga application base? (On Linux it's a simple thing to recompile everything, the OS, the Applications, the Lot, but this isn't the case on Amiga which couldn't be more far from this)

In my view, "special SPE floating point versions" of programs simply won't happen in a context where existing normal Amiga applications exists side by side with them. It's either this or that. How could you have selective trapping when instructions overlap? Right? And it won't be SPE because it's not possible to recompile the application base. This leaves only one option, right?

SPE floating point may have made sense in very special embedded applications, but it is of no benefit whatsoever in an Amiga context, rather the opposite! And I think it's kind of telling that even Freescale abandoned this idea in the next version of the core, thus reinstating the "classic" floating-point unit, and the SPE, SPESFP, and DPESFP were all removed. This core turned out to be merely a parenthesis in the core's evolution.

Even the (ex-)maintainer of Debian for PowerPCSPE calls it a "braindead FPU design".
https://lists.debian.org/debian-powerpc/2012/05/msg00025.html

It's indeed an extremely mysterious choice of CPU...




@iggy

Quote:

iggy wrote: @Spectre660 So we can expect some specialized binaries?

No.

Quote:

Yasu wrote: But 1000? That's a lot of boards.

OMG! A thousand?!??




Quote:

Spectre660 wrote: He mentioned that the price point could be low enough to be selling at a loss

I bet!

I think the initial price figures of between 700-1000 wasn't taken out of thin air, I believe these figures must have come from somewhere. But at this point, if it's a matter of offloading a thousand boards with e500v2, I don't think it's entirely surprising if the price will end up to be a fraction of this.

Which can perhaps be a good thing from a community point of view!

The final price of the Pegasos 2 G4 was $399 (€360) a decade ago (when H/W prices was generally much higher than today).

The mplayer benchmark shows that the Tabor is like a Pegasos2 G4 1GHz running at 700 MHz (in that particular CPU intensive application). So perhaps €300 is a "fair" price?

Heck, at €250 maybe even I would buy one? (Total price will of course go up with the GFX card/GPU necessary to make it possible to i.e. view movies etc, a plain old Radeon 9250 won't be enough )

@TRIPOS

Quote:

but fact is it's not even called "Amiga" (despite the borderline infringement by using the "A12xx" model name).

Official name is AmigaOne A1222.

Quote:

Isn't the only realistic way to tackle this to have the OS identifying this CPU very early on in the boot process and then make the OS ignore all HW access to the FPU, making the OS handling everything FPU in S/W emulation

Hyperion thinks they will be able to emulate "classic" FPU in hardware. Is this possible? What performance we can expect? Your opinion is as valid as mine in this regard.

Quote:

Pegasos2 G4 1GHz running at 700 MHz

Don´t forget the second core (we are speaking about Tabor, not its use under AmigaOS...).

Quote:

Heck, at €250 maybe even I would buy one?

You in the Red fold? End of the world is near.

Last edited by pavlor on 23-Oct-2015 at 09:25 PM.

@pavlor

Quote:

pavlor wrote: Official name is AmigaOne A1222.

Oh? Traditionally, the "AmigaOne" mark has been reserved for systems, not motherboards...

This has changed now?



I missed this, you got any source?

(EDIT: OK, I just remembered the old Eyetech references of motherboards, but still I think it was mainly a brand meant for systems, as defined by Amiga Inc. And still: You got any source that this motherboard will be called "AmigaOne"? What's with that "Tabor" thing then?)


Quote:

Quote: Isn't the only realistic way to tackle this to have the OS identifying this CPU very early on in the boot process and then make the OS ignore all HW access to the FPU, making the OS handling everything FPU in S/W emulation Hyperion thinks they will be able to emulate "classic" FPU in hardware. Is this possible? What performance we can expect? Your opinion is as valid as mine in this regard.

I just provided (once again) a couple of arguments of why H/W emulation in H/W isn't plausible in this case. You chose not to discuss them but to call them "opinions". Well, let's wait and see then...



Quote:

Quote: Pegasos2 G4 1GHz running at 700 MHz Don´t forget the second core (we are speaking about Tabor, not its use under AmigaOS...).

No, we are talking about the "AmigaOne A1222 AmigaOS 4 Hardware". Thus only one core. Amiga is per definition single core.

This board will not sell outside the Amiga community. There is no USP outside.


Quote:

Quote: Heck, at €250 maybe even I would buy one? You in the Red fold? End of the world is near.

I'm an Amigan.

But that doesn't make me insane per definition, right?

(Or does it? )

Last edited by TRIPOS on 23-Oct-2015 at 09:49 PM.
Last edited by TRIPOS on 23-Oct-2015 at 09:48 PM.

@ TRIPOS & pavlor

Quote:

Hyperion thinks they will be able to emulate "classic" FPU in hardware. Is this possible? What performance we can expect? Your opinion is as valid as mine in this regard.

The one thing we do know is that recompilation of the OS and software running under it will also alleviate the problem.
"Is this [trapping] possible?" , well the Linux guy (Spectre660) and Hyperion's developers seem to think so.

No point in doubting it until we see the release of the product.

@iggy

Quote:

iggy wrote: recompilation of the OS

Perhaps. (But why?)

Quote:

[recompilation of the] software running under it

Nope!

@TRIPOS

Quote:

TRIPOS wrote: @Spectre660, @umisef Quote: Spectre660 wrote: Anyway A-Eon now own DvPlayer and Tunenet. Two programs that would be affected by the FPU emulation speed. So special SPE floating point versions of these should not be a problem. Quote: umisef wrote: 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 think the instruction overlapping problem was established very early on in this thread, but this hasn't stopped people talking about trapping. Isn't the only realistic way to tackle this to have the OS identifying this CPU very early on in the boot process and then make the OS ignore all HW access to the FPU, making the OS handling everything FPU in S/W emulation in order to provide the proper Book-E/PowerISA necessary for the already existing Amiga application base? (On Linux it's a simple thing to recompile everything, the OS, the Applications, the Lot, but this isn't the case on Amiga which couldn't be more far from this)

Yes, Hyperion already stated this: the old (normal) FPU will be emulated. Emulation is fast according to they guy who posted the comment, but it's a clear lie (see all other comments about benchmarks and e500v2 manual).
Quote:

In my view, "special SPE floating point versions" of programs simply won't happen in a context where existing normal Amiga applications exists side by side with them. It's either this or that. How could you have selective trapping when instructions overlap? Right? And it won't be SPE because it's not possible to recompile the application base. This leaves only one option, right?

It has to be seen how many existing applications use string instructions. Anyway, the solution here is to have SPE versions, which likely will happen at least for the most important/used applications.
Quote:

SPE floating point may have made sense in very special embedded applications, but it is of no benefit whatsoever in an Amiga context, rather the opposite! And I think it's kind of telling that even Freescale abandoned this idea in the next version of the core, thus reinstating the "classic" floating-point unit, and the SPE, SPESFP, and DPESFP were all removed. This core turned out to be merely a parenthesis in the core's evolution. Even the (ex-)maintainer of Debian for PowerPCSPE calls it a "braindead FPU design". https://lists.debian.org/debian-powerpc/2012/05/msg00025.html

Do you know Motorola history? It clearly shows the braindead design choices that were made in the past. And Freescale has followed the path...
Quote:

It's indeed an extremely mysterious choice of CPU...

Absolutely. Path following...
Quote:

@iggy Quote: iggy wrote: @Spectre660 So we can expect some specialized binaries? No.

Why not?


@iggy

Quote:

iggy wrote: @ TRIPOS & pavlor Quote: Hyperion thinks they will be able to emulate "classic" FPU in hardware. Is this possible? What performance we can expect? Your opinion is as valid as mine in this regard. The one thing we do know is that recompilation of the OS and software running under it will also alleviate the problem.

According to the previous Hyperion comment, the o.s. will not be recompiled. Of course, a proper kernel is needed to handle such board and CPU, but that doesn't mean that a recompilation of the entire o.s. is needed. And FPU emulation will be provided, but it'll be very slow.

Sensible applications need to be recompiled for SPE.

@TRIPOS

Quote:

You got any source that this motherboard will be called "AmigaOne"? What's with that "Tabor" thing then?)

Watch Trevor´s presentation from AmiWest. Tabor (motherboard) is named "AmigaOne A1222" on one of the slides.

19:05


I´m the only one who saw this name?


Quote:

I just provided (once again) a couple of arguments of why H/W emulation in H/W isn't plausible in this case.

Arguments? Well, good to see another "expert" in this field...


Quote:

But that doesn't make me insane per definition, right?

What else would you call someone who is still emotionally attached to particular clone of 20 years dead platform?

@cdimauro

Quote:

but it's a clear lie

I thought your own comments in this thread proved we know nothing about performance of FPU emulation in hardware.