|
|---|
| | 
Estrayk / PaRaDoX
Posts 21
04 May 2017 01:10
| All of us, know that there must be some problem with the implementation of fpu but we do not know which.
| |
| | 
Gunnar von Boehn
(Apollo Team Member)
Posts 6214
04 May 2017 01:21
| There are two main problem 1) is called "TIME" 2) lazyness of community
| |
| | 
Obetto Sannala
Posts 61
04 May 2017 07:01
| Can you please explain "lazyness of community"? Can I help in any way on this point?
| |
| | 
Mr-Z EdgeOfPanic
Posts 189
04 May 2017 07:23
| Obetto Sannala wrote:
|
Can you please explain "lazyness of community"?
Can I help in any way on this point?
|
What Gunnar means is that somebody has to write a test case for the FPU.
Wish i could but I'm the worst coder in the world.
| |
| | 
Peter Heginbotham
Posts 214
04 May 2017 14:07
| If this is case why not release a beta version like the Gold3 FASTIDE beta and see what works well or crashes and burns
| |
| | 
Claudio Guglielmotti
(Apollo Team Member)
Posts 185
04 May 2017 14:25
| Seems that Biggun choosed to work on AGA at the moment...
| |
| | 
Roman S.
Posts 149
04 May 2017 16:41
| ... or he just want to release Vampire standalone as soon as possible. The team can do this without the FPU - but definitely not without AGA (well, at least the OCS has to work).
| |
| | 
Daniel Sevo
Posts 299
04 May 2017 19:32
| Gunnar von Boehn wrote:
|
There are two main problem
1) is called "TIME"
2) lazyness of community
|
1. Actually I think it's amazing how much stuff you and the team has added lately, sometimes it seems like magic - so work has obviously been done with good progress, so I will label this as "priority" instead of time then ;-) 2. People have different skills so it remains to be seen who can help with what but I think it would be helpful if you outlined a bit more specifically what kind of help your team would find useful.
| |
| |
Gunnar von Boehn
(Apollo Team Member)
Posts 6214
04 May 2017 20:09
| Daniel Sevo wrote:
|
2. People have different skills so it remains to be seen who can help with what but I think it would be helpful if you outlined a bit more specifically what kind of help your team would find useful.
|
You are right. Lets try to explain the situation. 1) On AMIGA only small amount of software uses FPU.
2) Most 68K systems had no FPU.
And the 68881/ 68882 FPU had very low performance.
3) Our FPU design is very modern and very powerful compared to even to the best old 68k, the 68060. 68080 can offer you a new level of FPU performance that no 68k ever reach before. But we have no software on AMIGA land able to take advantage of this. Also we have some decision to make.
Right now the APOLLO FPU is like an improved 68060 FPU.
We know that this super now but will be limiting to our progress in the future for future CPU generations.
We can keep the APOLLO like this or we could do the effort and make some design decision which will allow us to easier reach higher performance in the future. Like we used RIVA to test and develop our AMMX instruction - we ideally like to develop a small FPU usecase which will allow us to verify our decision.
| |
| |
Roman S.
Posts 149
04 May 2017 21:12
| Why not to take some fractal generator from Aminet? Like EXTERNAL LINK
| |
| | 
John William
Posts 563
04 May 2017 22:05
| Gunnar von Boehn wrote:
|
Daniel Sevo wrote:
|
2. People have different skills so it remains to be seen who can help with what but I think it would be helpful if you outlined a bit more specifically what kind of help your team would find useful.
|
You are right.
Lets try to explain the situation.
1) On AMIGA only small amount of software uses FPU.
2) Most 68K systems had no FPU.
And the 68881/ 68882 FPU had very low performance.
3) Our FPU design is very modern and very powerful compared to even to the best old 68k, the 68060.
68080 can offer you a new level of FPU performance that no 68k ever reach before. But we have no software on AMIGA land able to take advantage of this.
Also we have some decision to make.
Right now the APOLLO FPU is like an improved 68060 FPU.
We know that this super now but will be limiting to our progress in the future for future CPU generations.
We can keep the APOLLO like this or we could do the effort and make some design decision which will allow us to easier reach higher performance in the future.
Like we used RIVA to test and develop our AMMX instruction - we ideally like to develop a small FPU usecase which will allow us to verify our decision.
|
That is not true when it comes to few software uses FPU. There are lots of awesome games in aminet that needs FPU, including DOSBox, Exult, and even Quake. I hope FPU will become reality. Heck, even AmiBlitz needs FPU and even game maker player needs FPU.
| |
| |
Gunnar von Boehn
(Apollo Team Member)
Posts 6214
04 May 2017 22:27
| John William wrote:
|
That is not true when it comes to few software uses FPU. There are lots of awesome games in aminet that needs FPU, including DOSBox, Exult, and even Quake. I hope FPU will become reality. Heck, even AmiBlitz needs FPU and even game maker player needs FPU.
|
But percentage wise this is very few.
Much less than 1%
Many of the application you mentioned, do from design NOT need an FPU, some of the compiled bin might want to use an FPU - because it was ACCIDENTILY compiled to use one. But this is often not a requirement!
Of those you mentioned only Quake needs really an FPU.
Let try to make this more clear
FLOATs (the FPU variables) are internally nothing else but 2 INTEGER VALUES.
So FLOATING points can of course fully correctly calculated just with normal integer instruction.
You do NOT need an FPU for this.
Technically the idea of an FPU is to help the system to process FLOATS a little faster, thats all.
Now you have to look at the things in perspective.
Look for example at the famous "AIBB Beachball test".
Its a popular FPU Benchmark in AMIGA land.
AIBB Beachball routine comes in 2 version.
1st The Version using the FPU to calc the Beachball.
2nd The same code using Integers to do the Floating point calculation.
If you compare how fast an 68030@50 MHz + 68882@50 MHz can calculate this Beachball compared to the APOLLO 68080.
Then you can see that Apollo is so fast in Integer that it can do the calculation faster than the FPU can do it!Now lets look at the existing AMIGAs and their potential. FPU 68882 ~ 2 MFlops
68040@25 MHz ~ 8 MFlops
68060@50 MHz ~ 16 MFlops 68080 can provide up to ~ 200 MFlops For the 2 MFlops that an 68882 can give you - we do not need to turn on our FPU - we can do this easily and single handed in Integer... The problem on AMIGA is - there is currently no software needing a real fast FPU. Lets together make a sensible use-case - then it will make sense to use the FPU!
| |
| |
John William
Posts 563
05 May 2017 01:17
| Gunnar von Boehn wrote:
|
John William wrote:
|
That is not true when it comes to few software uses FPU. There are lots of awesome games in aminet that needs FPU, including DOSBox, Exult, and even Quake. I hope FPU will become reality. Heck, even AmiBlitz needs FPU and even game maker player needs FPU.
|
But percentage wise this is very few.
Much less than 1%
Many of the application you mentioned, do from design NOT need an FPU, some of the compiled bin might want to use an FPU - because it was ACCIDENTILY compiled to use one. But this is often not a requirement!
Of those you mentioned only Quake needs really an FPU.
Let try to make this more clear
FLOATs (the FPU variables) are internally nothing else but 2 INTEGER VALUES.
So FLOATING points can of course fully correctly calculated just with normal integer instruction.
You do NOT need an FPU for this.
Technically the idea of an FPU is to help the system to process FLOATS a little faster, thats all.
Now you have to look at the things in perspective.
Look for example at the famous "AIBB Beachball test".
Its a popular FPU Benchmark in AMIGA land.
AIBB Beachball routine comes in 2 version.
1st The Version using the FPU to calc the Beachball.
2nd The same code using Integers to do the Floating point calculation.
If you compare how fast an 68030@50 MHz + 68882@50 MHz can calculate this Beachball compared to the APOLLO 68080.
Then you can see that Apollo is so fast in Integer that it can do the calculation faster than the FPU can do it!
Now lets look at the existing AMIGAs and their potential.
FPU 68882 ~ 2 MFlops
68040@25 MHz ~ 8 MFlops
68060@50 MHz ~ 16 MFlops
68080 can provide up to ~ 200 MFlops
For the 2 MFlops that an 68882 can give you - we do not need to turn on our FPU - we can do this easily and single handed in Integer...
The problem on AMIGA is - there is currently no software needing a real fast FPU.
Lets together make a sensible use-case - then it will make sense to use the FPU!
|
K, I agree with that. But there are plan in the future for FPU release, right? I mean I really want to play those aminet rtg games and some of them are sweeeeeeeeeeeet including maze of galius.
| |
| | 
Wawa T
Posts 695
05 May 2017 01:17
| im not sure anymore , but why amiblitz needs fpu i think was a mystery even for maintainers;)
i myself linked once starfighter against mesa headers instead of dummies by sheer oversight, and since then my port sits in aminet demanding ogl libs even though it doesnt need them.. shame!
| |
| |
John William
Posts 563
05 May 2017 01:24
| wawa t wrote:
|
im not sure anymore , but why amiblitz needs fpu i think was a mystery even for maintainers;)
i myself linked once starfighter against mesa headers instead of dummies by sheer oversight, and since then my port sits in aminet demanding ogl libs even though it doesnt need them.. shame!
|
Where can I find your port in aminet?
| |
| |
Gunnar von Boehn
(Apollo Team Member)
Posts 6214
05 May 2017 01:38
| John William wrote:
|
K, I agree with that. But there are plan in the future for FPU release, right? I mean I really want to play those aminet rtg games and some of them are sweeeeeeeeeeeet including maze of galius.
|
This is on Open source game right?
So for you compiling this game without using FPU would be what, hundred times, or thousand times? less work than us doing the FPU.Seems wrong to support such lazynes. Listen we have the potential to do something MUCH more demanding!
But we should NOT carelessly do this.
We have a full 80bit 68k compatible FPU - but we know that if we look into the near future (next generation FPGA or ASIC) then this is not the most future proof basis for all of us. It would be smart to look forward now and create a basis which is
a) future proof
b) compatible
c) fast enough to open a range of stuff which was never done on AMIGA Like RIVA is a great showcase for the AMMX power.
We should look for a real usable showcase to proof and verify the power of the FPU.
| |
| |
Wawa T
Posts 695
05 May 2017 01:46
| | Where can I find your port in aminet? |
EXTERNAL LINK
but remember, you need agl storm mesa libs set in libs, even though for nothing. i should correct this but i have no time left to compile amiga stuff, except aros68k for now.
minimal resolution is 800x600 afair. and it depends very much on pixelformat/byteorder of rtg framebuffer. if its wrong the game is very slow. otherwise it was about half as fast as it should be on an a4k/060/voodoo, but mostly since the framebuffer could not be fed via zorro bus fast enough, it might be fluid with vampire.edit: errm. im not even sure, it might have been compiled with -m60040 or something like that. in that case it will likely expect fpu as well;)
| |
| | 
Thierry Atheist
Posts 644
05 May 2017 02:08
| Why release an FPU, if they are creating, what might be a significant new class of FPU capability? IF they release a FPU that is of today's class, then people will write code for that, and fracture the code base between current FPU type processing, and the NEW FPU architecture they want to bring to AMIGA, which will make AMIGA greater still than what anyone has imagined!!!! I'm for Gunnar's future model of what AMIGA can become!!!!!! We're still at 5:30 a.m. of the dawn of a new day for AMIGA! Can't wait to laugh in the face of the people that thought AMIGA was "out for the count". :-) :-DDD (P.S. You know, I think this was a secret plan that he didn't want to talk about.)
(P.P.S. You can have a bazillion Hz, if it isn't used properly it amounts to nothing. AMIGA is computing done correctly!!!!)
| |
| |
Thierry Atheist
Posts 644
05 May 2017 03:38
| Gunnar, Please make the FPU that you were aspiring to make, don't break the AMIGAN hearts of all true believers.... (Lifted from Stan Lee.)
| |
| |
John William
Posts 563
05 May 2017 06:03
| wawa t wrote:
|
| Where can I find your port in aminet? |
EXTERNAL LINK
but remember, you need agl storm mesa libs set in libs, even though for nothing. i should correct this but i have no time left to compile amiga stuff, except aros68k for now.
minimal resolution is 800x600 afair. and it depends very much on pixelformat/byteorder of rtg framebuffer. if its wrong the game is very slow. otherwise it was about half as fast as it should be on an a4k/060/voodoo, but mostly since the framebuffer could not be fed via zorro bus fast enough, it might be fluid with vampire.
edit: errm. im not even sure, it might have been compiled with -m60040 or something like that. in that case it will likely expect fpu as well;)
|
WOW!! In that case, I agree 100% with you :D Let the ball rolling baby! You are right about the AMMX! I love that technology and I have being enjoying watching movies on my Amiga 500 :D Thank you guys! Keep up the excellent work!
| |
|
Information about the Apollo CPU and FPU.