There might be room for much better settings.
Please ping me and we can check.

However, it would be interesting to see the results of CT60 using the 68000 soft-float FPU test. That would be a good CPU benchmark.

Would also assume this is the same with a standard Amiga running Kronos on EmuTOS?

This could be interesting to have pure 68000 openGL test under CT60, this quite easy todo only force choice of FPU before start the test, I have no CT60 to do this.

Olivier

Vincent Rivière wrote:

Current Apollo 68080 has no FPU.   I believe that FreeMiNT (or Kronos?) SFP004 detection is completely bogus on 68080 (will have to be fixed).   When I ran Kronos FPU and OpenGL tests, I chose the 68000 variant, while reference CT60 tests had obviously been run on 68060 FPU.   Performance of soft-float will always be poor compared to real FPU.     However, it would be interesting to see the results of CT60 using the 68000 soft-float FPU test. That would be a good CPU benchmark.

This ROM has identical features as the EmuTOS floppy optimized for Vampire. With the MapROM feature of the upcoming GOLD3, it will be easy to run EmuTOS from hard disk. Until that, you still need to boot the EmuTOS floppy (very easy with Gotek).

I send you results to compare. Need some time to understand results, before share I think.

Olivier

Vincent Rivière wrote:

Current Apollo 68080 has no FPU.   I believe that FreeMiNT (or Kronos?) SFP004 detection is completely bogus on 68080 (will have to be fixed).   When I ran Kronos FPU and OpenGL tests, I chose the 68000 variant, while reference CT60 tests had obviously been run on 68060 FPU.   Performance of soft-float will always be poor compared to real FPU.     However, it would be interesting to see the results of CT60 using the 68000 soft-float FPU test. That would be a good CPU benchmark.

There was absolutely no issue with memory bandwidth limitation, as I incorrectly suspected. The problem of instability (occasional blanks) simply occurs when the Pixel Clock is set too high. On my monitor, it must stays < 60 MHz to be completely stable.

There are several solutions to reduce the Pixel Clock frequency:
- use RBT (Reduced Blanking Timing): they are just fine with LCD monitors
- decrease vertical refresh. My LCD monitor can deal down to 24 Hz without any trouble.

I have used the umc tool to compute new modelines:
EXTERNAL LINK 
Basically:
- I have kept standard timings for 4:3 modes
- I have used RBT timings for 16:10 modes
- I have reduced the frame rate to 30 Hz for 1440x900 and 1680x1050 video modes, in order to reduce the pixel clock.

Results:

1680x1050 (my native monitor resolution) is perfectly stable and crisp, in 30 Hz:
EXTERNAL LINK  The only drawback of 30 Hz is the mouse pointer which is not exactly as smooth as usual (not a big issue).
Of course, everything is very small in this resolution.

840x525 is exactly half of my native resolution. It is also perfectly stable, even in 60 Hz. There are no visible artifacts due to rescaling. This resolution is very good, as icons remains big enough. And the screen ratio is respected.
EXTERNAL LINK 
So: everything just work well, no more mysteries related to SAGA :-)

Now again Kronos benchmark would be interestimg again to see if the performance is about the same as on the lower resolution.

Still using GOLD2 core.

To my surprise results in 1280x1024 were slightly different than previous ones. Maybe about 5%. Since previous test, I had recompiled EmuTOS and fVDI. Maybe that could explain some things, but certainly not difference in CPU performance. Maybe there is something slightly random somewhere.

Reference (100%) is still fVDI + FreeMiNT in 1024x768 60 Hz, but run again before other tests to avoid eventual difference of software I had recompiled.

1) fVDI + FreeMiNT in 1680x1050 30 Hz EXTERNAL LINK  Resolution is higher, but frame rate is twice lower. Pixel clock is 58.75 MHz (vs. 64.35 MHz in 1024x768).
CPU result is slightly lower, other ones are almost equal. I can't understand why CPU result is lower, as other results didn't change. Maybe some randomness. Anyway, everything is almost identical.

2) fVDI + FreeMiNT in 640x480 60 Hz EXTERNAL LINK  Frame rate is identical, resolution is lower, pixel clock is 24.05 MHz (vs. 64.35 MHz in 1024x768).
We can see +20% boost on CPU and Disk! Memory speed also increased a bit. Strangely, other values stayed almost the same. I still wonder if the disk benchmark is really relevant.

3) fVDI + EmuTOS in 1024x768 60 Hz EXTERNAL LINK  FreeMiNT provides preemptive multitasking, but it must be verified that it does not bring too much overhead. So I tested the same setup with plain single-task EmuTOS, still with fVDI.
CPU, soft-FPU and memory results are identical. This means that FreeMiNT does not bring any significant overhead, great OS :-)
VDI (graphics) is a bit faster (is this relevant?), maybe is is because the AES (windowing environment) is different (EmuTOS AES vs XaAES).
Disk is *much* worse with plain EmuTOS. This is mainly because FreeMiNT uses disk caching, and different filesystem driver.

4) Plain EmuTOS in monochrome (no SAGA) EXTERNAL LINK  Of course, ultimate test is without SAGA at all. So I ran Kronos with normal Amiga display, without SAGA. Please note that, at bootup, the Vampire card displays a Vampire logo in 640x480, and that one stays displayed on the DIGITAL-VIDEO output until software uses SAGA by itself. If I understand correctly, SAGA still runs behind the scenes in this case. Video mode used to display the logo might be lower than 16-bit, though.
Result: +25% CPU boost!
soft-FPU and OpenGL result are identical. I hardly understand how this is possible, as CPU is supposed to be significantly faster.
VDI (graphics) is much lower, this is because the EmuTOS VDI is used in that case (instead of fVDI + SAGA driver), and bitplane manipulation is more complicated for the CPU than TrueColor.
Disk result is still bad due to EmuTOS vs FreeMiNT.
Memory and video bus speed seems to be much worse... but it is not! This is because Kronos mixes the results of 2 different tests. See details: EXTERNAL LINK  Beware, on this detail screen "Your computer" is the second bar starting from top, while reference is the first bar.
We can see that STRam (= Chip RAM) performance is identical.
On the other hand, video results are very bad. They actually use VDI functions! So it is actually a VDI (graphics API) test, not raw memory performance.

My conclusion:
Everything looks good, with expected performance. We can go ahead with other stuff.

very nice result.
Impressive as always!

This looks not bad either

BTW the recent cores (pre-GOLD3) do also support planar modes over SAGA.
This means you can run ATARI style monochrome, or 2bit planar / 4bit planar also over DIGITAL-VIDEO. If you like :-)

And you can freely program their resolution so not only 640x480 but also 1024x768 or what size you want to have.

I look forward to see in the future Kronos scored of a x13 BLACK VAMPIRE core. :-)

  ADDQ.l #1,D0
  ADDQ.l #1,D0
  ADDQ.l #1,D0
  ADDQ.l #1,D0

The 68060 is generally a very good CPU.
The 68080 is from design an improved 68060 core.
Where the 68060 did had some design limitations, the 68080 tries to remove most of those limitations.

A huge difference between the 68060 and 68080 is the AMMX instruction enhancement.
The 68080 does not only support BYTE/WORD/LONG operations but also 64bit and 128bit operations.
If you are able to use these AMMX operations
E.g. in Video driver or in a game then you can expext up to 10 times speed up compared to old 68k code.

[edit: Vincent's CPU numbers suddenly disappeared? At least for me, the corresponding link goes nowhere]
 

So generally coding for the 68080 or generating code for it became easier than coding for the 68060.

I think the improvements / fixes we added to the 68080 are the same that Motorola also would have improved the 68060  if they would have continued on it.