@Kronos

Get back in your trench, then

_________________
Doing stupid things for fun...

@Karlos

Quote:

Karlos wrote: @pixie Does anyone have a 68K quake benchmark on current Emu68 PiStorm/CM4, RTG that we can just compare to his reported Sam460? 640*480*8 bit, ideally. Just curious.

Using Samuel Devulder's Quake 68K port with 640x480x8 bit basic frame buffer RTG with PiStorm32 Lite-Emu68 with stock clock speed RPi 4B 8GB.

Demo3 has +37 fps results.

Demo1 has +40 fps results.

End user overclock is available. i.e. 1.8 Ghz to 2.2 Ghz.

Basic frame buffer RTG is not 2D accelerated.

AmiQuake 68K can be faster.

Last edited by Hammer on 05-Jan-2024 at 04:34 AM.
Last edited by Hammer on 05-Jan-2024 at 04:19 AM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@Hammer

Quote:

Basic frame buffer RTG is not 2D accelerated.

Why does this matter? Quake redraws every pixel every frame anyway*, so there's nothing any traditional 2D acceleration can do to help. You just need dumb framebuffers and the ability to flip between them.

*Also true in 3D which is why one of the optimisations for GL quake was to simply not clear any buffers. Not clearing the Z buffer was handled by using a modified depth test that halved the depth precision and reversed the test order each frame.

_________________
Doing stupid things for fun...

@fishy_fis

Quote:

fishy_fis wrote: Sorry, this is completely off topic to the threads intent, but seeing as its gone this way a lot already, would anyone be interested in a thread where we can get a clear picture of where all systems sit in terms of raw performace? Emu68 on A500/a1200 with both pi3, pi3 and CM4, 68k under emulation on x86(64), ppc on x86 under both uae and qemu, native ppc on assorted ppc systems, etc, etc. [...]

No. Because it will just prove what the users of such systems are already aware of: all of them are blazing fast when it comes to 68k execution. Call it petunia, trance, rpi, tf530, uae jit on i7/i9. All of them offer more than the (extremely limited) modern or legacy 68k software library can chew of.

Speed was an asset back 15 years ago. When there were no FPGAs on the horizon (apart from Natami as a project), no (relative) cheap custom accel., limited NG PPC access and the PC were restricted in dual core cpus, while the majority of 1200 were sporting the ageing classic 68k accel. and the A500 were in stock condition. Here we are, a decade and a half afterwards and ppl are using RPis to post sysinfo and syspeed results on the fcbk group, while waiting for new software that usually targets the lowest possible amiga denominator, something between 7 and 14 Mhz. So ultimately, speed never really was a decisive factor,

Take notice from the LW benchmark, what's the difference if you render a scene in 4 or 2 mins or even in 2 seconds? How many scenes a user will be rendering per day and can't wait for 3 minutes in addition? Unless someone decides to recreate Babylon 5, of course :P

And if someone wants to measure speed under a cost effective point of view then he better includes the full system cost and not just the accel. by assuming that the future user already owns a classic Amiga. No. Let's calculate the full cost of the fastest 1200 or 4000 compared to a G5 from the dustbin and then we can discuss further .

_________________

@Cool_amigaN

Quote:

Take notice from the LW benchmark, what's the difference if you render a scene in 4 or 2 mins or even in 2 seconds? How many scenes a user will be rendering per day and can't wait for 3 minutes in addition? Unless someone decides to recreate Babylon 5, of course :P

Iteration.

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@Cool_amigaN

Quote:

No. Because it will just prove what the users of such systems are already aware of: all of them are blazing fast when it comes to 68k execution. Call it petunia, trance, rpi, tf530, uae jit on i7/i9. All of them offer more than the (extremely limited) modern or legacy 68k software library can chew of

Never underestimate the need to measure and sort (fnar). But in any case if you have blazing fast 68K then you probably don't need to think about native for the vast majority of software that isn't compute bound 100% of its runtime.

_________________
Doing stupid things for fun...

@Karlos

it is not blazing fast 68K.
it is just emulator.
emulator with speed of one six of native code.
and real speed of 25 years old pc.
not real and not fast.
nothing worth drop real hardware.
hardware that is not boring pc
(today commodity hardware)

@ppcamiga1

You keep spouting the same stupid, moronic garbage. It's 2024. Please, have a new year's resolution and get some new material?

Tell me, how is it 1/6th the native speed when there's no native ARM Amiga code to compare it against?

Read this and try and wrap your tiny hamster mind around the implications of it https://www.patreon.com/posts/emu68-0-15-3-new-85948607

Look at the 68K code on the left, versus the translated arm code on the right. It's almost 1:1. Now I appreciate elementary school arithmetic may not be your strongest subject but just maybe you can intuit that if there's approximately 1 arm instruction for evert 68k instruction, then it's hardly running at 1/6th native speed, is it? Obviously, the efficiency is dependent on what the 68K code does and I could probably write some horrific integer division / bitfield test to brutalise it, but that would run like turd on every 68K, real or emulated. However most real world code is dominated by simple operations, in approximately this order: Move, integer add/sub, integer logic, branching, multiplication and right at thr end of an every shrinking occurrence count, division abd bitfields.

Now, you could also say "well even if it was always this efficient, it's only using 1 core out of 4". Well, right back at you with every multicore PPC machine costing many multiples as much, so suck it down. There are more ways to use those cores and extra memory from the host than there are from within AmigaOS, which is zero.

Finally, is the transcripted code less efficient than code that had been compiled from the same source, directly to ARM? Almost certainly. However, the relative factor there will be completely dependent on what that code does and whether or not it's suitable for vectorisation.

However you look at it, you certainly pull a number out of your arse with 1/6.

_________________
Doing stupid things for fun...

@Karlos

Quote:

Karlos wrote: @ppcamiga1 However you look at it, you certainly pull a number out of your arse with 1/6.

That's where @ppcamiga1 stores all his numbers, where he does his best thinking, and subsequent reading of the calculated results. This much is evidently clear by now.

_________________
All the way, with 68k

@Karlos

68k code on emu68k on my rpi3 is still six times slower than native code.

Last edited by ppcamiga1 on 07-Jan-2024 at 10:51 AM.

@Karlos

so you want us amiga ppc users to drop ppc because it is not cheap
in exchange we get something as slow and as outdated as ppc
many times slower than native code and ancient compared to win/lnx/osx
it is dumb
leave ppc as it is
start working on something that will be at least on year 2001 level
start working on something that will be at least as good as win/lnx/osx was in year 2001

Last edited by ppcamiga1 on 07-Jan-2024 at 10:50 AM.

@ppcamiga1

No. I don't want anything from you "PPC users" or for you to do anything whatsoever. Just carry on humping your architectural corpse and convincing yourself you have it good.

You go on about making something "at least as good as was in 2001." No. That was NG's job. It's had decades. It failed. You have no SMP and no 64-bit address space. You barely have memory protection (since you still have public memory, you still have all the problems of list corruption etc).

Those of us that don't fancy paying high prices for hardware, to run an utterly ineffectual solution on, that we have to pay N times over for the OS, then a set of extra drivers and enhancer software, or don't want to wait another undefined amount of time for hardware announced years ago that isn't even going to run properly due to FPI incompatibility. We'll just just use 68K, thanks. Maybe we we might opt to run an ARM 32/BE AROS port some day. Or maybe not. We aren't interested in delusions of being mainstream or modern.

Enjoy your dead horse.

Last edited by Karlos on 07-Jan-2024 at 12:04 PM.
Last edited by Karlos on 07-Jan-2024 at 12:03 PM.

_________________
Doing stupid things for fun...

@ppcamiga1

Quote:

ppcamiga1 wrote: @Karlos 68k code on emu68k on my rpi3 is still six times slower than native code.

I see. What are you measuring and how are you measuring it? You see, actual developers do this. I've already linked you to the patreon post detailing what was the state of the art on PiStorm months ago, that shows, in detail, what is tested, how it is tested, what the results are, from the Emu68 author himself.

Where's your equally competent rebuttal?

Do you see how this works yet?

Last edited by Karlos on 07-Jan-2024 at 12:12 PM.

_________________
Doing stupid things for fun...

@Karlos

Quote:

Enjoy your dead horse.

Boldly spoken high from another dead horse....

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Kronos

Karlos knows very well that he’s riding an old pony…

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@Kronos & kolla

My ancient pony has the benefit of being resurrected into a virtual afterlife where most of the shackles of 90's silicon are gone. A key differentiator here is that my dead horse was much loved and consequently much effort has been invested in making high-performance, highly compatible emulations of it. Even on the dead horse that NG rides on, for additional irony.

Last edited by Karlos on 07-Jan-2024 at 12:50 PM.

_________________
Doing stupid things for fun...

@Cool_amigaN

As someone who used Amithlon/OS3.9 as his sole system for a few years I have to disagree about there being no practical use for as much 68k cpu raw grunt as one can muster.
Even OS usage.
Compression/decompression for example. Try browsing a compressed archive in Dopus Mag in "real time" without 1st extracting the archive when its a 500MB+ archive with lots of files at 1ghz emulated 040 type speeds vs 2ghz emulated '040 (as random examples). Even just extracting the archive. And its not like a person always does one thing at a time on a computer either.
Playing music, while browsing the web, while browsing compressed archives... it all adds up.
And then there was things like pc task, dosbox, fpse (playstation emulator), code compiling, videos and video conversion, uae, Archimedes emulation, Mac emulation, Mame, VICE, the ability to run 3d games in higher resolutions and framerates, some of the quake modes are quite heavy too. Amiblitz was another that could never have enough raw speed. And then there's 3d rendering as you yourself mentioned, where while a full movie isnt going to happen, even a 30 second clip can be 1800 frames. Even at 540p a person appreciates the hours/days of rendering time that can be saved by throwing more and more cpu grunt.

Im sure I could come up with a million and one more examples, but this is based on my usage.

The usual argument/counter to this that people make is "why not just do these things on pc?", and yes there's logic in that, but that same argument dismisses everything but Windows, and to a lesser extent Mac and Linux.
And if a person enjoys AmigaOS more and can do something under that rather than something they enjoy less then why not AmigaOS?

Long story short, there's just as much use of as much 68k grunt as can be mustered for AmigaOS3.x as there is any other Amiga derived OSes running on other CPU ISAs.

As for price/performance, yes, it's not irrelevant from a real world/real people perspective, but it kind of would be from a perspective of pure performance. Its not like there's not comparisons all over comparing performance of hardware at hugely different price points. And then there's also the new/second hand factor to consider too. And the fact that AROS on x86 native would make any bars or charts showcasing price/performance nigh on impossible to represent.

Last edited by fishy_fis on 12-Jan-2024 at 06:51 AM.
Last edited by fishy_fis on 12-Jan-2024 at 06:50 AM.

@fishy_fis

Quote:

The usual argument/counter to this that people make is "why not just do these things on pc?", and yes there's logic in that, but that same argument dismisses everything but Windows, and to a lesser extent Mac and Linux. And if a person enjoys AmigaOS more and can do something under that rather than something they enjoy less then why not AmigaOS?

I have an own built OS31 distro made out of aminet utils and it's amazing how snappy it is comparing to its host (windows).
Quote:

As for price/performance, yes, it's not irrelevant from a real world/real people perspective, but it kind of would be from a perspective of pure performance. Its not like there's not comparisons all over comparing performance of hardware at hugely different price points. And then there's also the new/second hand factor to consider too. And the fact that AROS on x86 native would make any bars or charts showcasing price/performance nigh on impossible to represent.

Having a little pi5 running through an hypervisor system run a draco like amigaos build, which could then run like rabbit hole in another core a game here and there, or a linux browser in another screen like we used to run shapeshifter might turn this into a little machine way more satisfying then most costly ones

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@Karlos

Quote:

Karlos wrote: @Hammer Quote: Basic frame buffer RTG is not 2D accelerated. Why does this matter? Quake redraws every pixel every frame anyway*, so there's nothing any traditional 2D acceleration can do to help. You just need dumb framebuffers and the ability to flip between them. *Also true in 3D which is why one of the optimisations for GL quake was to simply not clear any buffers. Not clearing the Z buffer was handled by using a modified depth test that halved the depth precision and reversed the test order each frame.

Quake ports like AmiQuake are based on WinQuake v1.09.

Using Caffeine R927's Quake port on A1200-PiStorm-Emu68-stock RPi4B and CGX/P96 copy functions (CPU driven for R927's BCM P96 driver)

320x200 8 bit demo1 = 121.19 fps.
320x200 8 bit demo3 = 119.49 fps.

640x480 8 bit demo1 = 50.71 fps.
640x480 8 bit demo3 = 50.08 fps.

RPi 4B overlock is available.

Last edited by Hammer on 12-Jan-2024 at 02:05 PM.
Last edited by Hammer on 12-Jan-2024 at 02:05 PM.
Last edited by Hammer on 12-Jan-2024 at 02:03 PM.
Last edited by Hammer on 12-Jan-2024 at 02:01 PM.
Last edited by Hammer on 12-Jan-2024 at 01:52 PM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@ppcamiga1

https://www.vgamuseum.info/index.php/benchmarks/quake-640

Athlon XP 2200+ (1.8 Ghz), Soltek SL75-KAV (Via KT133A), 512MB SDR CL3. AGP8X cards may be limited by AGP4X chipset. Quake 1 640x480 without and with fastvid, timedemo 1, DOS.

Quake 1 640x480 Software Render with Fastvid patch
nVIDIA Riva 128 4MB AGP1x 1997 = 104 fps.
S3 Savage IX 8MB AGP2x 1999 = 100 fps

S3 VirgeDX375 4MB EDO PCI 1996 = 80.6 fps
ATI Radeon 7000 32 MB DDR AGP 4X = 60.1 fps

3D Labs Premedia 2 ELSA 8 MB SGR AGP1x 1997 = 45.5 fps
Teseng ET4000W32P 1 MB PCI 1994 = 33.4 fps
----------------------

Using CaffeineOS R927's Quake 68K port on A1200-PiStorm-Emu68-stock RPi 4B (1.8 Ghz ARM Cortex A72)

CGX/P96 copy functions (CPU driven for R927's BCM P96 driver)
640x480 8 bit demo1 = 50.71 fps.
640x480 8 bit demo3 = 50.08 fps.

68040/68060 copy functions
640x480 8 bit demo1 = 51.58 fps.
640x480 8 bit demo2 = 59.64 fps.
640x480 8 bit demo3 = 50.87 fps.

CGX/P96 Experimental DB (DirectBuffer) function is not working i.e. grey screen.
CGX/P96 Experimental TB function is not working i.e. grey screen.

RPi 4B overlock is available.

----
SGI's Quake demo1 software render benchmarks
http://www.sgidepot.co.uk/quake1bench.html
----


https://www.amiganews.it/forum/viewtopic.php?f=37&t=17550&start=60#p236718

Quake 1 software rendering
640x 480 AmigaOneXe 933 Mhz = 47.8 fps
640x 480 Sam460 1Ghz = 61 fp


https://eab.abime.net/showpost.php?p=1253867&postcount=2238

QUAKE I PPC 640x480 (timedemo demo2) software

Peg2+G4/1000Mhz+R7000(64)+512MB 54.9 fps
A1SE+G3/666Mhz+Voodoo3+512MB 39.2 fps
Peg1+G3/600Mhz+Voodoo3+256MB 30.5 fps

Last edited by Hammer on 12-Jan-2024 at 03:08 PM.
Last edited by Hammer on 12-Jan-2024 at 03:06 PM.
Last edited by Hammer on 12-Jan-2024 at 03:02 PM.
Last edited by Hammer on 12-Jan-2024 at 03:00 PM.
Last edited by Hammer on 12-Jan-2024 at 02:51 PM.
Last edited by Hammer on 12-Jan-2024 at 02:41 PM.
Last edited by Hammer on 12-Jan-2024 at 02:34 PM.
Last edited by Hammer on 12-Jan-2024 at 02:30 PM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)