But having the Amiga able to run RiVA really fast, but at the same time being unable to run FFMPEG, Quake, full quality MP3 codecs, struggling with Real3D, VistaPro, Lightwave, is... well, not that fun.

I can't speak for Gunnar but it sounds like he just encouraged those wishing to prioritize the implementation of the FPU to identify an app that should both test and showcase the technology.

Sounds like a challenge to take some initiative.

My apologies Gunnar, I thought you had the split 32-bit | 64-bit | 80-bit split FPU with only 64-bit operations extended to 80-bit for exponent.

In fact I thought you guys started out with a plain 32-bit FPU originally.

Most FPU's I've worked with operate at different speed (cycles) depending on the instruction. So 32-bit operations used to be fastest, then 64-bit and ... well I've never used extended for anything but I assume it was even slower :)

So you do _everything_ at full 80-bit format and don't have a split implementation?

mpega.library comes in integer and FPU versions.  The author claims that the FPU code is more accurate.

 
But to be honest, No software depends on 80bit accuracy.
So it makes sense that today all architecture go for 64bit max and not one does 80bit anymore...

 
Our FPU has a significant latency or course.
You as coder will need to handle this.

We are aware that future FPGA that we plan to usenext year will allow us to reach GIGAFLOPS! so yes really 1000 MegaFLOPS
But we can not have this speed and also do 80bits!
 
So this is the dilemma. We have to now make a decision.
In reality the existing software on AMIGA uses mostly SINGLE.
That we internally calc it in EXTENDED is senseless overkill.

Shall we continue in the future to do this overkill - even if no software needs this?

Or shall we rather take advantage of the super FPUs that next-gen FPGA will otherwise give us..
 
 

Lets remember that a lot of users already have overclocked 060s (me included) and unless current gen vampires get an FPU they will never truly replace the 060 equipped Amigas. Yes it will play movies in 640x360 but in 95% of games Vampire will not offer a useful speed advantage over 060 in regular games and the really advanced games (Quake I, Quake II etc) that really benefited from a fast 060 will not run at all..
Same goes for a lot of the productivity software (and far from all are open source so that they could be patched or recompiled). (Although using any Amiga for 3d rendering in this day and age is pure madness, I don't feel sorry for you guys :-)

So maybe one way to look at is to say that very few apps really need/use FPU so its poor usage of resources to put it there.
Another way to look at is it to say that the design will eventually run out of space in current FPGA so a split is inevitable at some point in the future. Let this one be the true 68080 (not 68EC080) that replaces the 060 once and for all for all current gen Amiga software. And let us worry about what might come in the future when the Apollo core has grown into a seriously capable and modern CPU no longer constrained by budget FPGAs.

Also.. I remember my brother buying a Pentium for the equivalent of €2000 in 1996 to play Quake as the 486DX was dead slow. ;-)
One game /does/ make people upgrade their hardware. ;-)

Quake uses 32bit Floats - it makes no difference in Quake
whether you calculate them in 32bit or 64bit or 80bit...
 
Using for them more than 32bit will only make them slower and fill up our FPGA quicker leaving no room for anything else you might like to have...

I think the point moreover, would be to identify a standout application that would offer a popular proof of concept that would bring perceived value to Vampire users.

Games may not be your thing, but they are the most popular way to showcase the use of an FPU.

It only takes one application to get the ball rolling...

Seems most of the people do not know about what they are talking.
I'm a Scientific Software Developer, that means floating point calculations are my "bread and butter".

Single/Float (32Bit) is for most of the calculations usually enough.
32Bit float as 6 to 7 significant digits that means:
Imaging for a 3D Scene 1-9 km wide you still can describe something with 1 mm precision without and tricks thats more than enough. Bigger scenes you make tricks because you do not keep the whole scene in memory, so you only care the 1km around you and the far away things don't have to be so precise anymore

And thats a single 32bit float.. if you take a double it becomes really crazy stuff, double (64 bit) has 15-16 significant digits that means
a 1.000 km wide area you can make precise down to 1 pm (10^-12 m) or 1.000.000 km (remember circumfence of Earths 25.000 km ) down to 1 nm (10^-9 m, remember wavelength of light around 500 nm).
(Thats the reason I need double precision for my Mapparium program, the coordinates on the earth shelf needs to be rather high precision, higher than single, but still far away from reaching double precision)

There are very few occasion where you need more than double.. and to be honest in that cases the 80 bit extended is not enough and you need to develop 128bit and 256bit (google "Octuple-precision floating-point" ;)) math

Did you notice something odd on your x86_64 PC in contrast to your i386-pc? in terms of floating point calculations? No? Good, that means you do not need 80bit floats.
AMD/Intel marked the FPU as deprecated for x86_64 and all the 64 bit programs you are using, do not use the FPU at all, because it's very slow and old. All new floating point calculations on Intel/AND Processors are done with SSE2/SSE3 which does not have a extended float mode (80 bit) only single (32 bit) and double (64 bit). Even worse the SSE2/SSE3 floating point calculations does not have any SIN/CoSin/EXP and so on (as the FPU had) but Intel and AMD give out special routines (Google "Intel Approximate Math") these routines are very long (about a page assembler code) but much faster than the one line FPU.

@Gunnar:
Just curious: a Gigaflop FPU? you are having a FPGA running with GHz and more? :-O or you can do 10 fpu commands in one cycle (100 MHz + 10 FPU commands/cycle = 1GFlops)? :O I'm a little surprised. But if so I'm very happy.

While FPGAs are defined at time of boot-up, so 32, 64, 80 or even 96 bit can probably execute in the same amount of cycles? Only limit is the amount of bits retrieved from RAM per fetch. Is your CPU 32 bit, 64 bit, or "other", externally on the motherboard?

For my v500+ to be the complete and ultimate all-in-one amiga package i also need backwards compatible fpu and mmu.

First then i can retire my a4000. (which makes me a little bit sad ;)

Dont get me wrong. The work done by the team is awesome and we all appreciate it.

<child mode> But you all promised us FPU!!!!</child mode>

cheers! :)

People is asking for a FPU in order to run their favourite software.
But... demanding for FPU is demanding for HARDWARE compatibiluty, while what seems to matter is SOFTWARE compatiblity.
Now, Gunnar stated more than once that developing a full 68k compatible FPU would waste precious FPGA space and would be not as effective as people would expect and, reading all the tech and info about it two or three posts above, I can understand why.
And I have no reason to not trust Gunnar and the rest of Apollo team.

That said, is there the possibility to write a library that converts FPU calls into CPU calls (or does it already exists)? That would make any FPU requiring software run even without it, and I bet it would be faster than most 68082/040 HW out there. Maybe not faster than 060 but this can be acceptable: Vampire owners will have a super fast Integer performance (90% of Amiga Software), super fast GFX performance (100% of Amiga Software), lots of really fast RAM, very fast IDE and the equivalent of a 060FPU. That seems more than fair to me.

Returning to Apollo FPU: I clearly understand the fact that 80bit float is insane, and it can be understood by everyone reading the well written post above, even Intel and AMD deprecated it.
So, if the choice Apollo team has to made is to follow or not the same route of Intel and AMD (scrap the FPU for something that works very fast with 32/64 bit operations) let's do it, it has proven to work very well. I bet the Amiga user base will adapt to it once it will be real and software will be recompiled accordingly, libraryes will be written, compilers will be built.
Just look at what is happening with SAGA: Cannonball, Rick Dangerous and other games I can't recall right now are ported on a WIP gfx system just for passion's sake. I bet it will happen also with whatever idea you came up with your "FPU".
How I know it? Because you've always did an excellent job despite all and because I know the passion and love Amiga community has inside.

Fully agree: I worked 20 years in CAD/CAM development and we never ever had to use 64Bit precision, that would have been overkill.
32Bit is just enough to have 0.1mm precision on a 20m long drawing, 2D or 3D that is. I do not know much about RayTracing but i have reasons to believe that things do not change much.

Excellent Post!!
Yes GigaFlop is really no problem.
SuperScalar with 2 instructions per cycle would be the architecture first goal. But this is all a little too early to go into this now.

What would make real sense now.
Is to create a real good usecase.

This usecase should have the following features:

a) not too overly complex to be easy to profile

b) written in ASM

c) not completely artificial and useless but something sensible

d) Very FPU heavy to really be able to use 100 MFLOPS.
    mostly FADD / FMUL

e) Written with high paralism in mind.
    To be able to fully use Super Scalar FPU.
    Our FPU has a LATENCY of several cycle.
    So the test needs be able to work well with this.