Lets talk about A1222 - Tabor

[Daytona675x]

@kamelito

Daniel aka Daytona wrote in the youtube message stream that for now he didn't encounter any performance issue with the Tabor while porting Wings and Tower 57

That's not entirely correct I did not mention Wings in that context. It was about T57, at least I meant it to be about T57 only.
Of course I encountered performance issues - but I was able to solve them by coming up with the native SPE build of T57. With that build there are no performance issues

@Niding

He did comment that he wasnt overly excited by the CPU choice, but at the end of the day he seemed content with the performance of the Tabor.

Right, of course I'd prefer a CPU with a std. FPU, who wouldn't. First of all that SPE thingy means lots of trouble.
The AOS4 pre-release version I got contains a first version of the FPU emulation. It's performance is good enough as long as not too much FPU code has to be emulated. But most important: it works reliable.

However, at this moment I am only happy with the Tabor's float-performanceif the code is either SPE native or only contains few FPU instructions to be emulated.

But, luckily, Thomas Frieden is working on, let's call it "FPU turbo emulation" (I don't know how much I'm allowed to say) and I know that he's making good progress with that. I'm pretty confident that this thing will solve most performance issues with non-native code.

And that's what I mean with "at the end of the day":
While at the moment the performance is fine for my T57 adventure, I'm confident that once Thomas finishes the work on emu-v2 it will also be good for most other float-hungry non-native stuff.
I'd suggest to give the Tabor a chance to show its full potential, and that means:

let the Hyperion guys first finish their work on the OS and don't be so negative yet. I bet they weren't overly excited by the CPU choice neither - but they are actually solving those issues, I guess some moral support won't hurt

The Tabor's CPU is pretty fast so IMHO chances are good that at the end of the day we'll end up with a system that performs ~ up to 1.5 times as fast as the 460 for native- or int-code and around 460-speed for code with rather huge amounts of code to be emulated in one way or the other.
Don't nail me on any of this though, it's just my opinion / my guess based on what I saw / experienced / know so far. We'll see.

So much to my opinion. Regarding those two games on Tabor:

T57: when using SPE directly then the performance is nice. When using std. FPU commands then performance is low, although not as low as one might expect considering all those exceptions and emulated FPU commands.

Wings: I didn't even try it on Tabor yet The problem with Wings is that it's based on good old Warp3D. So internally it does looooots of vertex transformations and stuff like that. This would be too much to ask from the current FPU emulation.
Now you might say: then do like you did for T57 and compile it for SPE.
Unfortunately that isn't that easy as it is for T57.
To make a long story short: compiled for SPE = code without those 32 FPU registers (SPE uses the GPRs). And this becomes a problem when calling library functions (e.g. Warp3D) which expect floats in FPU registers...
So either the game's float-code was emulated - then the data ended up in the emulated registers and all is good - but slow.
Or the game's float-code was SPE native - then the data ended up in a GPR - but the lib-function expects it inside an (emulated) FPU rgister, where it never appeared.
With T57 it was much easier because I do almost everything in software myself and the few libs I rely on aren't critical (or I wrote replacement functions).
I'll wait for the new turbo-emu before playing around with Wings on Tabor.

[Daytona675x]

@Thellier
:confused: 68k? Interface?? Stack??? "Normal C functions"?
I talk about the PPC ABI used in AOS4.
In one single thing you're right though: *calling* *Warp3D* functions is not critical at all.
However this is not because floats aren't passed through registers, they are of course. It is because floats / doubles aren't passed by value in Warp3D - and this is even true for functions that only want single float / double values (which is a design specialty of W3D that I had forgotten about). Which is why in that particular case they aren't passed through float registers indeed. So I could give Wings a SPE try indeed (although the results are probably not satisfying because with some bad luck there are double-based memcpys inside the W3D driver).
However, the ABI incompatibility I explained remains and causes trouble, of course. Just replace "Wings" by the name of your favorite 3D game and replace "e.g. Warp3D" by "MiniGL" (which has tons of functions that expect floats by value) in my explanation and you have a better example why simple re-compiling often won't work.

@Iggy
Yup.  IMHO chances are good that the pretty high performance of that thing in  combination with Thomas Frieden's optimizations save the day

@dirkzwanger
Yes,  and let's not forget that this thing is meant to be an entry level  system. So if real fpu-hungry *non*-native stuff runs "okay", then it  should be fine. And let's also not forget that real critical stuff (e.g.  minigl) can certainly be modified to at least do a high amount of work  in native code.

All in all: let's wait and see and be optimistic (and there's certainly reason to be optimistic)

[Daytona675x]

Hi
@Daytona675x
 
You are certainly a good coder but you have difficulties to admit when you are wrong
"calling library functions (e.g. Warp3D) which expect floats in FPU registers"
is just a wrong statement as Warp3D (both OS3 and OS4 versions) never used FPU registers for calling functions

>MiniGL (which has tons of functions that expect floats by value)
True but there are not "expecting floats in FPU registers" too


Greetings
Alain Thellier

OMG, boy, I really don't have time for this crap, but well:
I don't know what your problem is (but somehow it seems to have something to do with a ego issue or things like "projection") but before you write more nonsense I suggest you do four things:

1. read before you write. I said that I was wrong with Warp3D.lib indeed since it doesn't pass floats by value even for functions like e.g. W3D_SetAlphaMode, which was sth. I forgot. As I wrote before.

2. read the specs. Hint #1 and Hint #2.

3. take a your favorite C compiler suited for PPC AOS4, write some lines of code containing a nice glTranslatef(1.0f,2.0f,3.0f), look at the assembly output. Do you still want to really tell anybody that float parameters are not passed through float registers?

4. come back here and better delete your previous statements.
While you probably are a more or less decent coder you should probably stick to topics you know more about.

Cheerio

p.s.: to the other readers: of course, as I said before, the problem with SPE compiled code calling functions with float parameters inside FPU-compiled code (and vice versa) exists, it exists as I outlined, it exists with e.g. MiniGL, floats are passed through registers (if there are FPU registers...), no matter what Allain Thellier keeps saying here.
The only thing I was mistaken was taking Warp3D.lib as an example; MiniGL however is a good example. Which is what I wrote before, but just in case anybody else besides that pal here likes to skip reading that part
Good part of my little mistake: I might give Wings a shot on Tabor - but guess what: I already said that too