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 

Andrew Copland

Posts 113
05 Sep 2017 10:31


Gunnar von Boehn wrote:

Andrew Copland wrote:

  I did write a ray marcher that used almost all of the FPU functions but it was in C.
   
  The demand that everything be in pure 68k asm is a BIG request Gunnar.
 

 
  No, I did not demand this.
 
  I said that the "core" calculation routines need be written in ASM.
  I'm sure you fully agree with me that only in ASM you have full control what you are doing.
 
  The point of writing fast code is to write the code
  - that uses both pipelines (Super-scalar),
  - that avoid instruction dependencies (is non sequential, interleaved or unrolled)
 
  You can control this easily in ASM.
  In C you can not - unless you at the same time re-write the C compiler.
 
  So doing this in ASM is for the coder certainly much less effort than doing it in C.
 
 
 

 
From the first thread post:
Gunnar von Boehn wrote:
Please note that coders willing to support need to be willing to put in significant time, and that all development will be done with 68k ASM.

 
I guess it's just a language barrier/misunderstanding that in English that statement is unequivocal and means "68k ASM only".
 
Otherwise I'd have done a bit more to Amiga-ify the Ray Marcher I wrote before now.


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
05 Sep 2017 11:33


Andrew Copland wrote:

Development will be done with 68k ASM.

I guess it's just a language barrier/misunderstanding that in English that statement is unequivocal and means "68k ASM only".

 
Seems like :-)
 
The main fpu calculation routine needs be written in ASM - to be able to fully control instruction ordering.

In what the rest is written does not matter.

Andrew Copland wrote:

Otherwise I'd have done a bit more to Amiga-ify the Ray Marcher I wrote before now.

Nice looking forward to it.


Rod March

Posts 119
06 Sep 2017 07:36


Gunnar von Boehn wrote:

rollef 2000 wrote:

  Was there are a time the hardFPU fit to current Vampire?
 

 
  a) we have cards where it fits.
 

Is there a chance these cores will be made available (if they're stable)?

If it has to be either SAGA or FPU in the V2 it would be super to have the option.


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
06 Sep 2017 08:31


Rod March wrote:

Gunnar von Boehn wrote:

 
rollef 2000 wrote:

  Was there are a time the hardFPU fit to current Vampire?
 

 
  a) we have cards where it fits.
 
 

 
  Is there a chance these cores will be made available (if they're stable)?

We have cards where it fits.
We have Vampire cards that were never sold.
There are bigger Vampire cards in the team, which we developers use, that we did not put on the market.


Michal Warzecha

Posts 209
06 Sep 2017 12:03


The question is: can full HW FPU fit into V4 Vampires?
I don't know how people on other forums react about missing FPU, but on our PPA many people cry about it. It's true bone of contention, looks like FPU begin more important for them than even SAGA. I think all of them should know did You plan to add fully working FPU to V4 (and of course to V2 whitch was sold in big quantity).
If any of Your bigger dev boards have it already, mayby You can show people how fast is that, do some LightWave tests and they'll know what they're waiting for.


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
06 Sep 2017 12:17


Michal Warzecha wrote:

The question is: can full HW FPU fit into V4 Vampires?

 
Yes, and this question has been answered before. ;-)
 
The Vampire-4 uses on purpose a much more expensive and about 2 times bigger FPGA than the V2. The purpose is to fit the HW FPU.
 
For the V4, we will bring out cores with FULL-HARD FPU.
 
Saying this - please mind that the VAMPIRE-2 has not a bad FPGA.
The VAMPIRE2 FPGA is much bigger and more capable than the cheaper FPGA's used in ARCADE and MIST.
 


Michal Warzecha

Posts 209
06 Sep 2017 12:30


Your answer was not so clear before, because You said something about much bigger dev boards, I was affraid full FPU fits there, and V4 still can not handle it. Anyway it's great information.
Tell me, IF someone decide to get fully working FPU in V2, can You calculate what features will be deleted from V2 to handle CPU, FPU and Fast RAM?
I think it could be good compromise between people who don't care about DIGITAL-VIDEO for example, but they want FPU, and the people who don't care much about FPU and they decide to have fully working SAGA and FEMU or FEMU combined with half hardFPU. It's still FPGA, You can do everything inside. If FPU is so big problem for so many people, why not to create 2 different versions of core if size is limit?


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
06 Sep 2017 12:40


Michal Warzecha wrote:

It's still FPGA, You can do everything inside.

And everything takes time.
Hardware development and testing takes usually significant more time than software development.

Doing many different version like you proposed would need month of time. Is this justified while people are waiting for the V1200?   




Gunnar von Boehn
(Apollo Team Member)
Posts 6207
06 Sep 2017 12:55


FEMU tuning for VAMPIRE-2
 

 
We can see major speed improvements after tuning FEMU for 68080.
 
Mind, that this FEMU version can only run on 68080, it uses extra registers only available on 68080 and 64bit instruction only available on APOLLO 68080.
 


Michal Warzecha

Posts 209
06 Sep 2017 13:05


Gunnar von Boehn wrote:

  And everything takes time.
  Hardware development and testing takes usually significant more time than software development.
 
  Doing many different version like you proposed would need month of time. Is this justified while people are waiting for the V1200?   
 
 

Of course I understand that, but I was thinking now when all modules are more or less done is more like LEGO for You to add or remove features.
It's only proposition for future. Many ppl buy V2 and they're little bit unhappy of lack FPU. So, when all new cards will be ready You can think about split V2 for 2 versions.
Of course when FEMU+V2 will work like 040/060 FPUs there will be no reason to do that.


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
06 Sep 2017 13:13


Michal Warzecha wrote:

Of course when FEMU+V2 will work like 040/060 FPUs there will be no reason to do that.

The HARD-FPU is faster than 68060 FPU.
Also the V4 is faster than V2.
So if people want the faster FPU then V4 might be their solution.

While FEMU, will certainly NOT reach 68060 FPU speed - reaching AMIGA 4000/68040 level seems not far away - just look at the SYSINFO screenshot and see for yourself.


Michal Warzecha

Posts 209
06 Sep 2017 14:00


I belive You, anyway I'm not any side of this "conflict", I don't want to force anything, I don't even own Vampire yet. Im just reading post and it was only my idea how to solve FPU problem. Some people just feel "betrayed" (have no idea it's proper word for it :) )
  Vampire v2 problem is it's crazy success, too much cards was sold and leave people without FPU is not... nice if there is any other option. Of course in case FEMU will not solve FPU problem.
 


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
06 Sep 2017 14:18


Michal Warzecha wrote:

  "conflict"
 

 
I see no conflict at all.
 
The Vampire was always sold without FPU.
People were always told to only buy it for the feature it has at the day they order it. And not to expect "wonder features" to come.
 
Please look at the FEMU screenshot.
FEMU gives now MFLOPS scores equalling an A4000/40.
 
I see here reasons  for people being happy and thankful -
but I can not see any reason for people being disappointed.


Peter Heginbotham

Posts 214
06 Sep 2017 14:38


So from an end user perspective, I have an Amiga 600 with 128Mb RAM, I can use large hard disks, a processor which wipes the floor of the Amiga 4000/030 I used to own, a graphic card outputting 720P@32bit. Now with the new 2.7 core and the softfpu its the running @ 040/25 speeds wheres the problem?




Vojin Vidanovic

Posts 770
06 Sep 2017 14:56


Peter Heginbotham wrote:

  So from an end user perspective, I have an Amiga 600 with 128Mb RAM, I can use large hard disks, a processor which wipes the floor of the Amiga 4000/030 I used to own, a graphic card outputting 720P@32bit. Now with the new 2.7 core and the softfpu its the running @ 040/25 speeds wheres the problem?

 
  With by the end of the year, v2 users should have AGA and all audio/video DIGITAL-VIDEO out, more then A500/A600 was ever supposed to have.
 
  Problem is in people wanting either 101% compatibility which Amigas never had amongst each other, people praising their expensive PPC/060 accelerators, or those downgrading someone elses success.
 
  Now when softFPU is mature enough, there are some people screaming for hardFPU in v2 instead of SAGA, missing only SAGA will bring them advancement and further 68k library access.
 
  In human nature, more then in product.
 
  I am also happy to see  product list extended by V4 500 Vampire.
  CLICK HERE 
  New to v2 are:
  Increased performance by 25%
  512 MB DDR3 Memory
  Dual Flash Chips
  FastKick
  USB
  RJ45 100BaseTX Ethernet
  Expansion ports (e.g. Wifi Module
  Plus hardFPU v4 only and all happy things 2.7-3 core will provide to v2


Samuel Devulder

Posts 248
06 Sep 2017 15:04


How cool that is! Congrats!
     
I'd like to see an updated video of EXTERNAL LINK (one month old only) using this new version of FEmu. The choppiness at 1:15 should have gone away with this 080-optimized version FEmu.


Rod March

Posts 119
07 Sep 2017 01:52


Gunnar that new screenshot looks awesome! 5 Mflops, well done! I expected a performance gain for FEMU of 2x-4x from v1, but that's more like 25x!

So encouraging to see some attention being given to FPU. Great stuff! Awesome work Apollo team!


Krzysztof Wojteczek

Posts 29
07 Sep 2017 08:12


Peter Heginbotham wrote:

So from an end user perspective, I have an Amiga 600 with 128Mb RAM, I can use large hard disks, a processor which wipes the floor of the Amiga 4000/030 I used to own, a graphic card outputting 720P@32bit. Now with the new 2.7 core and the softfpu its the running @ 040/25 speeds wheres the problem?
 
 

In my reality (public gold 2.5, femu.080 v 0.10) the "power" of softfpu looks like this: 21h 56m 2 s (78962) seconds + 24 h = circa about 46 hours - LW.3.5 gives wrong rendering times when it calculates with softfpu vs my blizzard 1260/75  ... 1h 29m 11s (5351sec).
Test scene is here: EXTERNAL LINK
Software used: LightWave 3.5 fpu and nonfpu version.
My score with vampire v2 gold 2.5 and nofpu LightWave 3.5  - 7h 12min 29 sec (25 949 sec)



Gunnar von Boehn
(Apollo Team Member)
Posts 6207
07 Sep 2017 08:44


Krzysztof Wojteczek wrote:

  In my reality ...
 

 
I'm sure you spend a lot time on the tests.
But how sure are you that your comparison was done correctly?
 
First of all, you compare the speed of the pre-alpha FEMU version.
Why do you do this at all?

It was clearly stated that this version is not finished and not speed tuned at all.
You know yourself that FEMU will be magnitudes faster when fully speed tuned. So what intention do you have bashing an early pre-alpha release?
 
 
Second, your list does compare two different compiles of the same program. This "kills" the CPU comparison factor of your list.
All you can for certain say is that compile a) of the program runs at different speed than compile b)
 
Third and most important, the non-FPU version of lightwave uses and calls the AMIGA math libs.
The AMIGA math lib on 68060 can use the FPU also in the non-fpu tests. Did you double check this?
Or did you install the same 68_000_ math libs for all systems to ensure this not happens?

I bet you did not.

So you do compares are not done right.
You compare the speed of between two different math libs and not of the CPUs.
 
As you see your results are biased and influenced by a lot more things than you thought.



Mr Niding

Posts 459
07 Sep 2017 08:54


@Krzysztof Wojteczek

In another thread, Gunnar did also say;

The new FEMU depends on GOLD 2.7 features.

Ofcourse all tests are intresting for data collection, but for looking forward to whats going to be available for V2 soonish (tm); it seems a bit odd to run comparative tests with FEMU+Gold 2.5.

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