Overview Features Coding ApolloOS Performance Forum Downloads Products Order Contact

Welcome to the Apollo Forum

This forum is for people interested in the APOLLO CPU.
Please read the forum usage manual.
Please visit our Apollo-Discord Server for support.



All TopicsNewsPerformanceGamesDemosApolloVampireAROSWorkbenchATARIReleases
Information about the Apollo CPU and FPU.

Status of the FPUpage  1 2 3 4 5 6 7 8 9 10 11 12 13 

Thellier Alain

Posts 141
29 Jun 2017 09:08


@Jari
>I have started working with soft FPU. Suprisingly it is already able to run Mandelbrot
Congratulations Jari very well done :-)

Just for curiosity :
What did you used as basis ? ShoeBill SoftFpu ? UAE code ?
How did you set the fpu trap for all tasks ?

Alain Thellier


Martin Soerensen

Posts 232
29 Jun 2017 09:32


I assume this can only work with system-friendly software unless it can be patched into the KS somehow?
But I guess most FPU software runs from WB anyway like productivity software, 3D games and 060 demos.


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
29 Jun 2017 09:35


Martin Soerensen wrote:

  I assume this can only work with system-friendly software unless it can be patched into the KS somehow?

Yes it will of course be included in the KS.
This means FPU is then always supported.
 

Martin Soerensen wrote:

But I guess most FPU software runs from WB anyway like productivity software, 3D games and 060 demos.

Lets make this clear:
- 060 demos are not the target

- 3D games:
90% of AMIGA 3D games DOOM/Wolfenstein/Gloom/etc use integer and run better than perfect already.

QUAKE is the big 3D game really needing an FPU.
The SOFT-FPU is right now as fast as 68882, maybe 2 times faster.

I think the main advantage of this Soft-FPU is NOT 200 FPS in Quake.
But that every software able to run on 68030 & 68882 will run - just better.




Martin Soerensen

Posts 232
29 Jun 2017 10:24


Yes, unlike ScummVM and Netsurf etc. not all software has source code available so it can be recompiled for nofpu so simply having an 68882 compatible soft FPU will 'fix' much of the issues towards running old FPU software.

Some software was even compiled for FPU although it doesn't really use it except in the initialization and will thus cause an error message on startup. In this case, the speed of the soft FPU is completely irrelevant.


Marcus Sackrow

Posts 37
29 Jun 2017 16:40


Gunnar von Boehn wrote:

  The SOFT-FPU is right now as fast as 68882, maybe 2 times faster.

I'm not sure where you got that information.
But the FMath test on a 68882/50 Mhz finish in 1.51 s. The Screenshot here shows 9.74 s.


Roy Gillotti

Posts 517
29 Jun 2017 17:15


From my understanding from what I thought I read on IRC, this is straight up 68k assembly work?

If that is the case, would there be any performance increases to be had by utilizing some of the  Apollo specific 64-bit functions?

If I'm wrong about that I apologize.


Roman S.

Posts 149
29 Jun 2017 18:01


Simo Koivukoski wrote:

     
This doesn't look too good... My A1200 + ACA1233n (68030 @ 40 MHz + 68882 @ 50 MHz) scores over 6 times better:
   


 


Montag PS

Posts 8
29 Jun 2017 18:57


Roman S. wrote:

  This doesn't look too good... My A1200 + ACA1233n (68030 @ 40 MHz + 68882 @ 50 MHz) scores over 6 times better:

I don't think it's fair to compare these results to Jari's soft FPU. It seems clear to me that his work is still at an early stage and highly experimental, so we should give him time and all of our support, don't you agree?

Jari Eskelinen wrote:

  As a personal asm learning project I have started working with soft FPU. Suprisingly it is already able to run Mandelbrot generator (though under UAE only, some problems with Vampire, need to discuss with the team).




Gunnar von Boehn
(Apollo Team Member)
Posts 6207
29 Jun 2017 19:38


Roman S. wrote:

  This doesn't look too good...   
 

 
Your post is low quality and shows lack of respect for the coder.

What do you expect when the project was just started, and is was stated that no tuning was done yet.


Steve Ferrell

Posts 424
29 Jun 2017 19:47


Montag PS wrote:

 
Roman S. wrote:

    This doesn't look too good... My A1200 + ACA1233n (68030 @ 40 MHz + 68882 @ 50 MHz) scores over 6 times better:
 

 
  I don't think it's fair to compare these results to Jari's soft FPU. It seems clear to me that his work is still at an early stage and highly experimental, so we should give him time and all of our support, don't you agree?
 
 
Jari Eskelinen wrote:

    As a personal asm learning project I have started working with soft FPU. Suprisingly it is already able to run Mandelbrot generator (though under UAE only, some problems with Vampire, need to discuss with the team).
 

 
 
 

 
  You're absolutely right.  And Jari's soft FPU is already outperforming my 68882/50Mhz by roughly 40% when measuring MFlops, so it should handle just about any classic Amiga app just fine.  If you're looking for raw horsepower for rendering or other math intensive applications then you shouldn't be looking to the Vampire to begin with.
 
  If nothing else, it provides a way for all those apps that require but may not even use an FPU to run without crashing.  And a soft FPU is a great stop-gap measure until the Apollo team releases their FPU for use on the Vampire.
 


Roman S.

Posts 149
29 Jun 2017 20:04


It's not about the developer. If the performance difference is really as high as AIBB says (somehow I trust it more than SysInfo), the SoftFPU will probably need some extra HW assistance to be useful for anything but the last-resort solution. Of course, I don't know how much it can be tuned...


Steve Ferrell

Posts 424
29 Jun 2017 20:17


Roman S. wrote:

It's not about the developer. If the performance difference is really as high as AIBB says (somehow I trust it more than SysInfo), the SoftFPU will probably need some extra HW assistance to be useful for anything but the last-resort solution. Of course, I don't know how much it can be tuned...

You're still being overly critical. Jari stated that his soft FPU project was a learning experiment or proof-of-concept exercise.  Running comparative performance benchmarks on it versus real silicon at this stage is not only premature, but a distraction and a waste of time.  There's still a lot of work and optimization to be done, so why not let him get to it instead of criticizing his work and the soft FPU's performance?  I'd expect a 2x performance increase at the least after his code is optimized.


Roy Gillotti

Posts 517
29 Jun 2017 20:23


Actually pretty amazing, unless I was mistaking what he meant, but I think he claimed to have never done any ASM work before this project.
 


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
29 Jun 2017 20:27


Steve Ferrell wrote:

I'd expect a 2x performance increase at the least after his code is optimized.

Maybe __much__ more.

But this behavior of criticizing peoples work is not acceptable and not justified at all.

Such a project is work for many weeks.
And you start with building a frame work
and then you implement the stuff for correctness,
and the last step is speed tuning.

Putting down such a project when it just started is not fair and just bad manner.


Martin Soerensen

Posts 232
29 Jun 2017 20:33


Steve Ferrell wrote:
You're still being overly critical.

I second that. When developing stuff, it is silly to spend time optimizing for performance prematurely. The first step is to make a proof of concept and speed is completely irrelevant at this stage because if you can't make it work at all, then the effort you spent optimizing the non-working code would mean that you wasted much more time than necessary. If you fail, you want to fail as quickly as possible so you can try another path.
 
From a 'newbie' 68k asm programmer (meant in a positive way) simply making something like this work at all is impressive. Next step would probably be to verify and improve the numerical accuracy, add more instructions and then finally start optimizing for speed. The speed might increase by 3x or it might be possible to get 50x. It is hard to know at this point which is also why it makes no sense judging it based on its current speed.

Edit: Seems that Gunnar was slightly faster than me with a very similar comment. :)


Vojin Vidanovic

Posts 770
29 Jun 2017 22:13


"he SOFT-FPU is right now as fast as 68882, maybe 2 times faster."

"I'm not sure where you got that information.
But the FMath test on a 68882/50 Mhz finish in 1.51 s. The Screenshot here shows 9.74 s."

Ahh, what a childish reactions.

a) Its soft FPU emulation. It can vary in results in every test at this stage + its not ment to be final FPGA core updated FPU and its performance, but a soft emulation to brigde the gap time, and than it will be forgotten.

b)If I would defend gunnar, I would theorize he ment then stock A3000 FPU (as example, since we dont target to beat 060 with softFPU) which was 68881 (16 MHz ) or 68882 (25 MHz). Not some mid end accel card you have there, one of high end FPUs :-)

So far all evil was "there was no FPU". Now is "not fast enough".

You cant easily please mankind :-)


Roman S.

Posts 149
29 Jun 2017 22:44


I don't really understand the fuss in this thread.

I don't know the SoftFPU internals and progress, so I can't judge whether benchmarking it at the current stage makes sense or not - but if I see Apollo Team posting their benchmark results and talking about performance, I assume it already is at this stage.

I really hate to see being accused about... well, something relevant to the author. Nobody talked about the author here, we were talking about the SoftFPU.

'FPU', "no FPU' - this is meaningless to the end user. What is meaningful is: software works/does not work, software is sluggish/fast. The purely software emulated FPU can address the 'does not work' (unless we are dealing with real-time problem, like in case of FFMPEG), but clearly not the 'sluggish/fast' problem (at least on the FPGA).

Last, I'm not going to post in this thread anymore, neither I am going to comment any FPU-related topic on this forum - it always quickly turns into sh*t-storm of personal attacks. Sorry, I just have enough.


Vojin Vidanovic

Posts 770
29 Jun 2017 23:20


Take note that other FPGA systems like Minimig, Mist or FPGA Arcade also dont have a hardware FPU, cant run FPU related binaries and dont have a softFPU option, and if there was, it would be slower then on Vampire.

That is a fair comparison to ongoing progress.

I agree benchmarks were never like real life use,
but again it is a indicator of what could be experienced.


Jari Eskelinen

Posts 23
30 Jun 2017 05:57


Roy Gillotti wrote:

Actually pretty amazing, unless I was mistaking what he meant, but I think he claimed to have never done any ASM work before this project.

Yes, this is correct. Never done any asm before. Never done any 68k code before either. That's why I said I was actually surprised when I got first fractal generator to actually run and then others as well.

Why I mention this? There's three interesting aspects:

- Good: Performance probably can be boosted easily, code is very inefficient now since I did not know best and most efficient design patterns from the heart - I just want to make it run first, optimizations can follow.

- Bad: Probably gazillion of bumps ahead and slow process - seasoned asm veteran could probably produce results much faster, I have to rely on manuals constantly.

- Superb: Well, turned out 68k asm is not that hard and it's actually quite fun. So you there, start coding now and do amazing things :-)


Philippe Flype
(Apollo Team Member)
Posts 299
30 Jun 2017 06:41


Indeed you did it well. Starting with Asm is always a big amount of informations to deal with. Many RTFM. And here you also need go into the darkside of the cpu : dealing with traps, supervisor mode, stackframes, ... You had put the basis of the mechanics, and that is remarquable. Continue the very good work and soon the whole amiga community will have something that is missing since 25 years. Very nice stuff.

posts 254page  1 2 3 4 5 6 7 8 9 10 11 12 13