|
|---|
| | 
Andrew Copland
Posts 113
06 May 2017 16:19
| Gunnar von Boehn wrote:
|
The original 68k FPU has 80 bit registers
The original FPU does expand every input to 80bit and it always does all calculations in 80bit.
Our current FPU design does work 100% the same.
So we also work in 80bit like the original.
...
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..
|
Ok now I understand :) 64-bit would be plenty, indeed as you say 32-bit would be fine and faster for most operations. There was an article about a flight sim (TFX I think - can't find it now) where everything had been written using doubles (64-bit) at the insistence of the flight model coder, but it didn't fit into memory and there were performance issues. A couple of the other coders got together when he was away and switched it all to single precision (32-bit) and everything still worked just fine :) My suggestion would be to drop 80-bit dead asap.
64-bit will be fine and I'd bet it'll be compatible with all of the existing software that uses the FPU. I'm actually used to just having 32-bit precision from console. However for purely practical reasons I don't suppose you could have separate 32-bit and 64-bit pipelines within the FPU could you? In short:
- Extended (80-bit) pointless,
- 64-bit probably still fully compatible,
- 32-bit FPU would be good enough for 90% of cases. Andy
| |
| | 
Thierry Atheist
Posts 644
06 May 2017 18:01
| Andrew Copland wrote:
| Gunnar von Boehn wrote:
| The original 68k FPU has 80 bit registers
The original FPU does expand every input to 80bit and it always does all calculations in 80bit.
Our current FPU design does work 100% the same.
So we also work in 80bit like the original. |
Ok now I understand :) 64-bit would be plenty, indeed as you say 32-bit would be fine and faster for most operations. |
Gunnar von Boehn wrote:
| The original 68k FPU has 80 bit registers
The original FPU does expand every input to 80bit and it always does all calculations in 80bit.
Our current FPU design does work 100% the same.
So we also work in 80bit like the original. |
Andrew Copland wrote:
| My suggestion would be to drop 80-bit dead asap.
64-bit will be fine and I'd bet it'll be compatible with all of the existing software that uses the FPU.In short:
- Extended (80-bit) pointless,
- 64-bit probably still fully compatible,
- 32-bit FPU would be good enough for 90% of cases. Andy |
Gunnar von Boehn wrote:
| The original 68k FPU has 80 bit registers
The original FPU does expand every input to 80bit and it always does all calculations in 80bit.
Our current FPU design does work 100% the same.
So we also work in 80bit like the original. |
Andrew Copland wrote:
| | Ok now I understand :) 64-bit would be plenty, indeed as you say 32-bit would be fine and faster for most operations. |
Gunnar von Boehn wrote:
| The original 68k FPU has 80 bit registers
The original FPU does expand every input to 80bit and it always does all calculations in 80bit.
Our current FPU design does work 100% the same.
So we also work in 80bit like the original. |
Andrew Copland wrote:
| | Ok now I understand :) |
Gunnar von Boehn wrote:
| | The original 68k FPU has 80 bit registers Our current FPU design does work 100% the same.
So we also work in 80bit like the original. |
Andrew Copland wrote:
| | Ok now I understand :) |
Gunnar von Boehn wrote:
| | So we also work in 80bit like the original. |
| |
| | 
Mike Brantley
Posts 36
06 May 2017 19:36
| Just to chime in... My only care is that LightWave 5 eventually work on my Vampirized Amiga. Have never seen a non-fpu version of that version. It's my favorite Amiga program. It mostly works on my X1000 and is fast, but there are some things that don't work. On a Vampire classic Amiga I am hoping it will eventually work 100 percent, even if slower at rendering than my X1000.
For now I have an integer version of the older LightWave 3.5 ready for use while awaiting the FPU implementation.
For other programs, like VistaPro and Scenery Animator, I can live with the interger versions if I have to. But hopefully the eventually Apollo / Vampire FPU will work with existing Amiga softwarebase. I have VistaPro working pretty well under OS4, but Scenery Animator is a bit of a mess. It just wants to run on more compatible Amiga hardware.
I love these types of programs. Don't give a flip about games. ;)
One thing I have learned from my OS4 experiences is that often new software never turns up to take advantage of new hardware capabilities.
Anyway, my Vampire should arrive any day, and then I can start experimenting.EDIT: Woot woot! I just checked my mailbox, and my Vampire is here now!
| |
| | 
Gregthe Canuck
Posts 274
06 May 2017 21:00
|
My suggestion is to decide which FPU functions are actually in common use or make sense and do those in hardware.The remaining set can be solved in software. This seems to be where this thread is heading. Also as Gunnar says there are considerations for actual free space on the FPGA. Mike - congratulations on your new Vampire!
| |
| | 
Kolbjørn Barmen
(Needs Verification)
Posts 219/ 2
06 May 2017 21:44
| Sure, 32bit or 64bit precision is fine as long as the programs we have work with that. As I understand things, the FPU already exists, so why not get it out the door so we can try it out with the software we use?
| |
| | 
Gunnar von Boehn
(Apollo Team Member)
Posts 6214
06 May 2017 21:59
| Kolbjørn Barmen wrote:
|
Sure, 32bit or 64bit precision is fine as long as the programs we have work with that.
|
Yes, of course they will.
Why should they not!
Kolbjørn Barmen wrote:
|
As I understand things, the FPU already exists, so why not get it out the door so we can try it out with the software we use?
|
Please reread the thread.
The whole point is that we ask people to work together with us on a nice killa-app testcase.
If someone show up with interest to write some lines for AMIGA....
| |
| | 
Daniel Sevo
Posts 299
06 May 2017 22:00
| Gunnar von Boehn wrote:
|
Daniel,
thanks for the post, but can you pleasew help me understand what was you point?
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...
|
My point was *not* that we need 80 bit precision ;-) My point was that there is value in doing a compatible FPU for current generation of Vampires, but not necessarily keeping that compatibility for future upgraded Apollo core in a next gen FPGA.
Because: Next gen Vampire will make possible new workloads not currently seen on 68k Amiga (I assume) so a lot of software wont truly benefit unless patched/recoded or recompiled anyway (to use AMMX, SuperScalar FPU etc). But for current gen.. if the FPU can be done as 32 (or 64) bit and an custom fpulib can somehow downgrade the precision on the fly then that would certainly be a viable compromise.
| |
| | 
Olivier Landemarre
Posts 147
07 May 2017 13:25
| Hello, I'm quite surprised to see under Amiga there is not a lot of software using FPU, under Atari there is some and the speed difference is quite different between FPU and not FPU version. For example opengl test with tiny_gl library is 3 time faster in FPU version compare to 68000 version in Kronos bench.
I have made FPU and 68020 version of Inshape 3 3D modeler and difference is very important.
Probably this softwares could be optimized but need a lot of work to do it.
It's probably nice to replace FPU by SSE but it need compiler able to do it. On Atari we use FPU with double in 64 bits (GCC) and 96 bits (PureC), at my known 80 bits is not use and I think 96 bits not give better precision than 80 bits version as 16bits looks not used at all if I remember well. I'm very curious to see one time FPU on 68080 to compare with CT60 card.
| |
| |
Kolbjørn Barmen
(Needs Verification)
Posts 219/ 2
07 May 2017 23:06
| Olivier Landemarre wrote:
|
I'm quite surprised to see under Amiga there is not a lot of software using FPU |
So am I, since I have plenty of Amiga software that does use FPU. It was standard on just about any "big box" Amiga as well as the vast majority of CPU cards for the other models. No-one questioned having and using FPU back in the 90s, this whole "Amiga does not need FPU" is something I think started with Jens Schoenfeld when he dropped FPU on his ACA cards.
| |
| |
Gunnar von Boehn
(Apollo Team Member)
Posts 6214
08 May 2017 07:01
| Olivier Landemarre wrote:
|
I'm quite surprised to see under Amiga there is not a lot of software using FPU,
|
"Lot" and "many" has to be seen in relation. The number of games for OCS/ECS AMIGA is huge.
The number of games for AGA AMIGA is big.
The number of tools and applications which can run without FPU is big.
The number of applications which require a FPU in tiny.
| |
| |
Gunnar von Boehn
(Apollo Team Member)
Posts 6214
08 May 2017 07:40
| Kolbjørn Barmen wrote:
|
It was standard on just about any "big box" Amiga as well as the vast majority of CPU cards for the other models.
|
Lets try to keep to facts please!
The AGA bixbox AMIGA, the A4000 was sold in numbers as 030 version without FPU and without MMU.
Of the non-AGA big box, the A2000 was sold the most.
The A2000 come with stock 68000 or course without FPU.
Not all accelerators came with FPU.
And of those accelerator cards which had an FPU, very many used the very slow 68881/68882 FPU - which could be emulated in Software without problems.
| |
| | 
Aksel Andersen
Posts 120
08 May 2017 08:16
| I'm sorry, but you will never convince me I don't need an fpu.
| |
| |
Aksel Andersen
Posts 120
08 May 2017 08:24
| Gunnar von Boehn wrote:
|
Kolbjørn Barmen wrote:
|
It was standard on just about any "big box" Amiga as well as the vast majority of CPU cards for the other models.
|
Lets try to keep to facts please!
The AGA bixbox AMIGA, the A4000 was sold in numbers as 030 version without FPU and without MMU.
Of the non-AGA big box, the A2000 was sold the most.
The A2000 come with stock 68000 or course without FPU.
Not all accelerators came with FPU.
And of those accelerator cards which had an FPU, very many used the very slow 68881/68882 FPU - which could be emulated in Software without problems.
|
That's not exactly accurate. That might be true for the user base 20 years ago. But in 2017 the remaining user's mostly have fpu..
| |
| | 
Martin Soerensen
Posts 232
08 May 2017 08:49
| Aksel Andersen wrote:
| | That's not exactly accurate. That might be true for the user base 20 years ago. But in 2017 the remaining user's mostly have fpu.. |
Based on what data? I have quite a few running Amigas here but none of them have FPUs since I don't see much reason to have it. Most people I know with Amigas also do not have FPUs since they mainly use their Amigas for WHDLoad gaming. I would still like to have an FPU in my two Vampire machines but not at any cost (SAGA and a fast IDE controller is much more useful IMO).
| |
| |
Aksel Andersen
Posts 120
08 May 2017 08:55
| I think the percentage of big box amigas and power users are higher in the user base than 20 years ago. Of course I don't have any data to back that up.
| |
| | 
Przemyslaw Tkaczyk
Posts 155
08 May 2017 08:55
| I feel I need to jump in this conversation at this point. I understand the priorities for the A-Team are now widely appealing AGA-implementation and V1200 hardware design, and the FPU is being put on hold for many important reasons BigGun just pointed out.
Nevertheless, I can't agree that all the software list comes to just tools/games/applications. I represent another huge chunk of Amiga user base that keep the platform alive, and that is the Demoscene.
Most acclaimed and awarded productions make heavy use of the FPU. Mad Wizards, Ephidrena, Appendix, Ghostown - these all are well respected and got their numerous awards with breaththrough demos for high end Amigas (meaning fast CPU and often RTG graphics) that pushed the platform forward over the past years. And I myself consider the Vampire project a best high-end Amiga there is. Leaving FPU out would be a big mistake. I recently talked hours with Kiero/Elude (look him up if you don't know the guy) on our trip to Revision2017. As one of the best Amiga coders out there, he pointed out that FPU is a must. So don't just take my word for it. Look up some of the greatest MaWi, Elude, Ghostown, Ephidrena productions and see if they will run without FPU.
Please don't leave out one of the most important aspects of Amiga legacy that is the Demoscene. Nedless to say, many of scene coders went on did some great tools for "regular" users, too.
| |
| |
Aksel Andersen
Posts 120
08 May 2017 09:04
| +1 Amiga is all about demos for me..
| |
| | 
Mr Niding
Posts 459
08 May 2017 09:17
| Unless Im misunderstanding the posts, it looks to me like people think Gunnar isnt implementing FPU at all. I do belive what he highlighted to be the issue; TIME Anyhow, just copy pasting Gunnars post from page 2)
The 68060 is not fully pipelined.
This means FADD throughput is 1/3 clocks.
1) Our FPU is FULLY pipelined.
We can have a throughput of 1 FMAD per clock.
2) Our FPU units are independent and can work in parallel.
This means we can have a throughput of not only 1 FADD per clock.
But also 1 FMUL per clock.
This means with good code you have 2 FLOPS per cycle.
3) The 68K FPU design is limited by 2 operants ISA encoding.
The 2 Operant encoding create the need for many "filler" FMOVE instructions. These instruction create unneeded dependency chains and lower the FPU performance.
Our is internally a 3 Operant machine. By for example FUSING FMOVE+FADD or FMOVE+FMUL we can create a much higher throughput than all previous 68K-FPU.
If you take the above differences into account the you see that we can provide 10 times higher performance than 68060.
But today there is NO software written to use this power.
To use this full power potential, the software needs to be be written use the Super-Scalarity really efficiently - this is best done in ASM.
There are also some challenges in writing this.
As while the throughput is super, all FPU instructions still have a latency. This means perfect FPU code needs to consider this.
A good coder good do with something - never seen on AMIGA before.
If coder show the will to do this, to write a small but Killa-app, and has the will to test/profile/debug the FPU design with this - which can take several month. Then we will happily support this. |
| |
| |
Aksel Andersen
Posts 120
08 May 2017 09:35
| It's kinda mixed signals. I don't see why whe have to be convinced fpu isn't necessary.
| |
| |
Thierry Atheist
Posts 644
08 May 2017 09:45
| Gunnar von Boehn wrote:
| The original 68k FPU has 80 bit registers
The original FPU does expand every input to 80bit and it always does all calculations in 80bit.
Our current FPU design does work 100% the same.
So we also work in 80bit like the original. |
They have a FPU... Gunnar von Boehn wrote:
| 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... |
But, probably should be limited to 64 bits....Gunnar von Boehn wrote:
| Our FPU has a significant latency or course.
You as coder will need to handle this. |
It has a bit of a problem.....Gunnar von Boehn wrote:
| 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! |
The future is BRIGHT, but has a limitation......Gunnar von Boehn wrote:
| 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. |
So, inconclusive: We get 32 bit limited FPU, soon?Gunnar von Boehn wrote:
| | 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.. |
Or just wait for new SUPER FPU performance in the next Vampire series accelerator (mother) boards?I'd be surprised if no FPU was in the current one, ever. Have they run out of LEs (logic elements) on the Vampire 2?
| |
|
Information about the Apollo CPU and FPU.