@pixie

Quote:

pixie wrote: @Karlos From quake I got: AGA 345fps from low res 320x256 256 109fps from produtivity mode 640x480 256 146fps from ham low res RTG 397fps from low res 320x256 256 171fps from 640x480 256

For Quake, it's unlikely Pistorm32-Emu68-RPI CM4 on A1200's AGA would reach 60 fps 320x200/240/245 resolution.

_________________
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:

For Quake, it's unlikely Pistorm32-Emu68-RPI CM4 on A1200's AGA would reach 60 fps 320x200/240/245 resolution.

Indeed, it got 69.2 FPS on RTG, I guess it wouldn't.

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

@pixie

I haven't tested Sam's Quake benchmark with demo1.



On a single thread, RPI 4B's ARM Cortex A72 CPU out-of-order processing upgrade from RPI 3B+ ARM Cortex A53 is relatively minor.


From https://ibug.io/blog/2019/09/raspberry-pi-4-review-benchmark/


I usually follow PC's Quake "timedemo demo3" (320x200 resolution with full UI) benchmarks from https://thandor.net/benchmark/33

Last edited by Hammer on 22-Nov-2022 at 11:12 PM.
Last edited by Hammer on 22-Nov-2022 at 11:11 PM.
Last edited by Hammer on 22-Nov-2022 at 10:50 PM.
Last edited by Hammer on 22-Nov-2022 at 10:50 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)

@Gunnar

Quote:

Gunnar wrote: Today all good FPU are fully pipelined. Still all the FPU operation need several clock cycle to finish. But you can start a new FPU instruction every clock! This means you have several instruction in flight in parallel. All modern FPUs work like this - they are all pipelined. On POWER, on INTEL on ARM, on 68080 - all modern FPU work like this Typically todays FPUs have about 6 or more operations in flight. The 68080 can have up to 22 FPU operations in flight in parallel!

AMD K19.5 Zen 4's reorder buffer has 320 instructions deep which accommodates the tracking of a large number of instructions in flight.

AMD K8 Sledge-Hammer's reorder buffer allows the instruction control unit to track and monitor up to 72 in-flight macro-ops (whether integer or floating-point).

AMD refers to the more simplified fixed-length operation as macro-ops (sometimes also Complex-Op or COPs). In their context, macro-operations are fixed-length operations that may be composed of a memory operation and an arithmetic operation. Fixed-length operations are one of RISC's design ideologies. Intel refers to the variable-length x86 instructions as macro-ops.

Last edited by Hammer on 01-Dec-2022 at 12:58 AM.
Last edited by Hammer on 01-Dec-2022 at 12:52 AM.
Last edited by Hammer on 01-Dec-2022 at 12:49 AM.
Last edited by Hammer on 01-Dec-2022 at 12:47 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)

Quote:

Hammer wrote: AMD refers to the more simplified fixed-length operation as macro-ops... Intel refers to the variable-length x86 instructions as macro-ops.

Why can't these people agree on definition of the terms they use?

Anyway, good to hear that the 68080 uses techniques similar to modern CPUs. Those guys must really know their stuff!

@Hammer

Quote:

I usually follow PC's Quake "timedemo demo3" (320x200 resolution with full UI) benchmarks from https://thandor.net/benchmark/33

Here you go:

320x200: 73.8 FPS
320x240: 66.3 FPS
320x256: 63.1 FPS
640x480: 29.5 FPS

Emu68 0.11, PiStorm600, CM4, Amiga600 (2MB CHIP, 1.8GB FAST)

@michalsc

Quote:

michalsc wrote: @Hammer Quote: I usually follow PC's Quake "timedemo demo3" (320x200 resolution with full UI) benchmarks from https://thandor.net/benchmark/33 Here you go: 320x200: 73.8 FPS 320x240: 66.3 FPS 320x256: 63.1 FPS 640x480: 29.5 FPS Emu68 0.11, PiStorm600, CM4, Amiga600 (2MB CHIP, 1.8GB FAST)

Have you tried Amiga's HAM mode with Samuel Devulder's Quake build?


For A1200, I have pre-ordered CM4.

Last edited by Hammer on 02-Dec-2022 at 10:26 AM.
Last edited by Hammer on 02-Dec-2022 at 10:24 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)

@bhabbott

Quote:

bhabbott wrote: Why can't these people agree on definition of the terms they use? Anyway, good to hear that the 68080 uses techniques similar to modern CPUs. Those guys must really know their stuff!

Different companies have their own terminologies and culture.

68060 FPU is not pipelined and it doesn't have out-of-order processing, hence missing re-order-buffer hardware.

The function of the reorder buffer is to put the instructions back in the original program order after the instructions have finished execution possibly out of order. The reorder buffer maintains an ordered list of the instructions. Instructions are added at one end of the list when they are dispatched and they are removed from the other end of the list when they are completed. In this way, instructions will be completed in the same order as they were dispatched.

The text that annoyed me is when Gunnar minimized the modern X86 CPU's instructions in flight capability while maximizing AC68080 FPU's instructions in flight capability.

Quote:

Gunnar wrote: Typically todays FPUs have about 6 or more operations in flight. The 68080 can have up to 22 FPU operations in flight in parallel!

Last edited by Hammer on 02-Dec-2022 at 10:17 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)

I've no time to reply to comments, because in the last period I was very busy writing article articles on my technical blog plus I've started again working on my architecture .

However I've written another 16 articles about the packed vs planar graphics to further clarify the topic. Just reporting now what I've written on LinkedIn.

https://www.appuntidigitali.it/19768/amiga-packed-16-endgame/

This is the last article of a very long series about #planar vs #packed #graphics, which I've written to debunk a common urban legend which is floating around since decades and spreading the idea that #bitplanes (planar graphics) were "more efficient" compared to #chunky (packed graphics).

Links to all articles are reported at the beginning of this last one.

The entire series is made of an introductory article which is more theoretical, exposing in detail the dispute, analyzing the most common cases / scenarios (graphic primitives), reporting the best and worst cases mostly from a memory accesses / #bandwidth point-of-view (which usually dictates the limits of a specific #hardware platform), with some numbers to make it easier to understand the limits of each graphics format.

The subsequent 16 articles take a real-world example (the #Commodore #Amiga personal computer, which was very famous from mid 80s to mid 90s) and going in depth exploring all of its features related to the graphics (planar), how they work, and their limits.
On the exact opposite side, a corresponding "packed" version of each feature is exposed and explained, to show how much more efficient (on average) this hypothetical "packed" Amiga version could have been, both in terms of used space ("graphic" memory) and consumed bandwidth (again, of the "graphic" memory).

All articles are very complex, extremely technical (sometimes going to the transistors level to show how many resources should have been needed to implement some feature / graphic primitive), heavily based on the Amiga #architecture (except the first, theoretical article, which is more general), and some are very long too.
They can be seen as the chapters of a book.
So, it takes a lot of time, patience, and expertise on the exposed concepts, in order to "enjoy" everything. For those reason, I don't recommend to get into them if you're not prepared to "digest" all this stuff.

Last but not really least, the 17 articles are in Italian (but they can be easily translated with some automatic tool, like DeepL, Google Translate, ChatGPT, ...).

@cdimauro

Sounds like you claim that Jay Miner and his team were incompetent for going planar and you could have done a much better job going chunky 40+ years ago.





mkay......

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

@Kronos

Quote:

Kronos wrote: @cdimauro Sounds like you claim that Jay Miner and his team were incompetent for going planar and you could have done a much better job going chunky 40+ years ago. mkay......

It was just a bad design decision and I could have done nothing else: I was only a teenager at the time and clearly lacking the experience / expertise for proposing something better.

@cdimauro

Quote:

cdimauro wrote: It was just a bad design decision

Was it really? Everything "chunky" that existed at that time s###ed a## and considering that it was originally planned to be a game console with 128k max the padding needed for 5 or 6 bit modes was not an option (and neither was going 8bit/pixel).

I see it a bit like 8086 vs 68000, sure the 68k was the better design from a modern viewpoint, but back in 78/79 the extra RAM needed to store 32bit pointers and the higher transistor count made the 8086 a viable product.

Quote:

and I could have done nothing else: I was only a teenager at the time and clearly lacking the experience / expertise for proposing something better.

I was obviously refering to the idea of your adult self being arond at that time doing a "better" job.

Last edited by Kronos on 20-May-2023 at 03:58 PM.

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

@cdimauro

Very interesting and detailed article.
Even though I don't have the technical knowledge to fully understand everything, it seems like an in-depth analysis of the pros and cons of the two solutions.
The end summary gives a very interesting insight into what this hypothetical chunky chipset could have been from the start.
Thanks, I've been hoping for a long time for someone with technical knowledge to do this kind of work.

@Kronos

Quote:

Kronos wrote: @cdimauro Quote: cdimauro wrote: It was just a bad design decision Was it really?

Absolutely. 17 articles on the topic should be more than enough to remove any doubt about it. But, of course, they should be read.
Quote:

Everything "chunky" that existed at that time s###ed a##

OK, and? It doesn't mean that it was not possible to use the packed / chunky graphic to save space and bandwidth, as I've described.

In fact, it was possible...
Quote:

and considering that it was originally planned to be a game console with 128k max the padding needed for 5 or 6 bit modes was not an option (and neither was going 8bit/pixel).

This clearly shows that you have NOT read the articles (not even the first, theoretical, one).

So, absolutely no: with packed graphic you have LESS padding compared to ANY equivalent planar graphics.
Quote:

I see it a bit like 8086 vs 68000, sure the 68k was the better design from a modern viewpoint, but back in 78/79 the extra RAM needed to store 32bit pointers and the higher transistor count made the 8086 a viable product.

Correct.

However this example doesn't apply to the packed vs planar dispute.
Quote:

Quote: and I could have done nothing else: I was only a teenager at the time and clearly lacking the experience / expertise for proposing something better. I was obviously refering to the idea of your adult self being arond at that time doing a "better" job.

Certainly possible then: I had this idea very long time ago.

I've also shared it on Olaf's Amiga coding forum around 13-14 years ago (I don't recall precisely now). People like Gunnar were very skeptical, but once I've (mathematically) proved my thesis, then there were no objections anymore.

To me it was a natural, obvious, conclusion once I've mastered both planar and packed / chunky graphics.

Maybe it's because of my mindset: I spent a good part of my life optimizing the use of the available resources, taking into account and thinking around the limits of a system, and trying to find solutions (sometimes novel, original ones) to specific problems.

Anyway and from wherever are coming, those are the facts: packed graphics would have been a much better format to use & implement.

@babsimov

Quote:

babsimov wrote: @cdimauro Very interesting and detailed article. Even though I don't have the technical knowledge to fully understand everything, it seems like an in-depth analysis of the pros and cons of the two solutions. The end summary gives a very interesting insight into what this hypothetical chunky chipset could have been from the start. Thanks, I've been hoping for a long time for someone with technical knowledge to do this kind of work.

Thanks. It took me several months to write those articles and even if a single person appreciated them then I'm happy.

@cdimauro

The issue is that you are still 2nd guessing with 30+ years of hindsight.

Same as every historian could tell you why Varus failed and was doomed to fail from the get go.
Put them in the same situation with the same background and fog of war they would still end the same.


Reality is, Jay worked with primitive tools, a small budget and against an unrealistic timeframe. So yeah he did start with what he had learned from the AtariXL instead of starting from scratch (just like Intel with the 8086) and someone decided that this new system should do more then 16 "free" colors meaning that packed pixels would either waste bits or start at any given bit in a byte. Both a nogo when even the design we got had the tendency to strangle the weak CPU as it was.

Sure with hindsight we could go back and decide that the system would only finished in a way and at a time where shipping it with 256/512k was a non issue, which would have made it sensible to give the chipset it's own separate display buffer (read like a CGA/EGA/VGA card), but none of that was an option when the started.

It is the same as looking back at

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

@Kronos


A few years ago I had read or listened to an interview with Jay Miner in which he explained that one of his regrets about the Amiga was not having chosen the chunky display directly.

Unfortunately, I searched for this, but I can't find this interview, maybe it's no longer online or maybe one day I'll come across it by chance.

That's why I've been waiting a long time for someone to give us some insight into what a chunky Amiga chipset could have been and what it might or might not have done better or not.

Here an article about the history of Amiga (french) :
http://obligement.free.fr/articles/amiga_histoire_1983.php

At a moment they talk about planar or chunky choice :
"There was thus a debate on the graphics modes that the new machine should use. Chunky pixel mode would be more suitable for 3D games that Jay Miner and RJ Mical had in mind, while planar mode would be more suitable for producing 2D displays and GUI. Ultimately, planar mode was chosen to make designing a multi-window operating system and 2D features much faster and easier, and because planar bit-planes only required a small amount of memory, so that at the time, memory was still very expensive."

Last edited by babsimov on 21-May-2023 at 10:34 AM.

@cdimauro


By the way, would it be possible to create a simulator of this Amiga Chunky chipset from WinUAE sources so that you can create a game demo for us using the advantages mentioned, such as all the sprites usable in AGA, the different dual play field modes, EHB 128 and 256 color mode. Or the 15/16 bit mode for AGA graphics, the 256/256 couleurs dual playfield AGA.

In short, to see in "real" what all this could have given?

Last edited by babsimov on 21-May-2023 at 10:40 AM.

@babsimov

Yes, sure you can do that.

But there's no sense in doing it, You can do planes without using planar, Or two images on top of each other and you have two planes, OR three images on the top of each other and you have three planes.

how it’s done is not important, how it looks in the end is.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@babsimov

“I am not a hardware developer”

(Many have asked the same before)

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@NutsAboutAmiga


In that case, I'd love to see how all of this could look animated in different types of games.


@kolla

It seems like it's not necessarily necessary to design the chipset, see NutsAboutAmiga's answer