How much CPU does C2P consume?

[HornBeamSoft]

Originally Posted by Bruce Abbott

Not sure what you mean by that - I don't think you can have an A1200 'with Fast RAM only'.

I mean A1200 original 68020 14 MHz Fast RAM FakeRTG
2 steps down from full-screen low detail
You may check it?

[Bruce Abbott]

Originally Posted by HornBeamSoft

I mean A1200 original 68020 14 MHz Fast RAM FakeRTG
2 steps down from full-screen low detail
You may check it?

Ah, I understand now.

I don't have an A1200 RAM board at present (though I do intend to buy one). However I found this post from 'Cammy' at Amiga.org:-

DoomAttack

Amiga A1200 020/14Mhz 8Mb (Optimised 020 C2P) - 22976 realtics (3.3 fps)
Amiga A1200 020/14Mhz 8Mb (Blitter 020 C2P) - 20660 realtics (3.6 fps)
Amiga CD32 68020/14Mhz 8Mb (Optimised 020 C2P) - 18971 realtics (3.9 fps)
Amiga CD32 68020/14Mhz 8Mb (Akiko Optimised C2P) - 12872 realtics (5.8 fps)
Amiga A1200 030/28Mhz 64Mb (Optimised 020 C2P) - 17732 realtics (4.2 fps)
Amiga A1200 030/28Mhz 64Mb (Blitter 020 C2P) - 12727 realtics (5.8 fps)
Amiga A1200 030/50Mhz 128Mb (Optimised 020 C2P) - 8696 realtics (8.6 fps)
Amiga A1200 030/50Mhz 128Mb (Blitter 020 C2P) - 8296 realtics (9.0 fps)

Note that these runs were done with the window set 'almost full-screen' which I presume means 1 step down. Expect about 10% higher frame at the standard 2 steps down.

Here we see that an A1200 with FastRAM got 3.6 fps (~4 fps at 2 steps down) using 'blitter assisted c2p'. Curiously a CD32 with FastRAM got 3.9 fps. Using akiko c2p the CD32 got 5.8 fps, which is the same as a 28MHz 030 with blitter-assisted c2p. pretty impressive that the stock 14MHz 020 with FastRAM and akiko matches an 030 going twice as fast!

On reading this I realized that I hadn't tested my system with blitter-assisted c2p (thinking it was slower than optimized c2p on a fast CPU). So I tested it just now and guess what, it's faster! 10.93 fps, ie. the same speed as direct copy to ChipRAM. This means chunky mode would have no benefit at all!

However the results for the CD32 with akiko show that chunky mode would make a significant improvement to a stock A1200 (with or without FastRAM). When I get a RAM board I will test it to find out how much faster Doom could have run on it with chunky mode. Next step after that - design a circuit that adds chunky mode to the AGA chipset.

[Bruce Abbott]

Here's another interesting post from 'skolman' on Amiga.org, showing execution time of the Gloom c2p routine on various systems:-

c2p Gloom 1x1 256 colors

68020/14 - 61.6 ms
68020/14+fast - 54.6 ms
68020/14+akiko - 24.2 ms
68030/50+fast - 21.7 ms
68040/25+fast - 18.6 ms
68020/14+fast+akiko - 17.6 ms
68060/50+fast - 9.1 ms

Here we see that on a CD32 with FastRAM akiko does it 3.1 times faster than Gloom's CPU-based c2p routine, faster even than a 25MHz 68040! Seems that Gloom's c2p routine is not optimized.

This illustrates another reason for having akiko or chunky, less programming effort required to get optimum results. This could have helped to encourage developers to port games from the PC. Unfortunately the engineers working on the AGA chipset didn't think chunky was important enough to implement - which it wasn't for 2D games developed for the Amiga.

[meynaf]

Originally Posted by Bruce Abbott

On reading this I realized that I hadn't tested my system with blitter-assisted c2p (thinking it was slower than optimized c2p on a fast CPU). So I tested it just now and guess what, it's faster! 10.93 fps, ie. the same speed as direct copy to ChipRAM. This means chunky mode would have no benefit at all!

Blitter assisted c2p is in some way slower than optimal c2p on a fast cpu, in the sense it takes more time to complete. However, cpu can do useful things while blitter is running - giving a faster overall process.

[Thomas Richter]

Originally Posted by Bruce Abbott

This means chunky mode would have no benefit at all!

No, it means that you haven't understood the problem. You are with this approach wasting resources you could invest better into something else. ChipRAM bandwidth is one of the bottlenecks, and with the current design the limiting factor. Remove that bottleneck - then planar to chunky conversion becomes the bottleneck. If you're wasting CPU or blitter resources do to the conversion, you don't have these resources available to do something better instead.

[cookieninja]

Originally Posted by AestheticDebris

Everyone.at Amstrad thought the same about the GX4000 console. When you're on the inside of a project, tunnel vision can easily blind you to mistakes that are obvious to outside observers.

You say that, but isn't something badly wrong when you're development is not focused on improving the product range bringing in significantly more cash? It really should not been hard to see. If only they hadn't strayed as far as they did from the original mission of a games focused machine



If the higher end had a reduced budget, like it should, the appeal of leaning on 3rd party cards more would've surely been stronger

[AestheticDebris]

Originally Posted by cookieninja

You say that, but isn't something badly wrong when you're development is not focused on improving the product range bringing in significantly more cash? It really should not been hard to see. If only they hadn't strayed as far as they did from the original mission of a games focused machine



If the higher end had a reduced budget, like it should, the appeal of leaning on 3rd party cards more would've surely been stronger

My point was more "The engineers and managers thought they'd done a good job" is a pretty weak argument, because of course they did. And, within the constraints they set themselves, maybe it was. It doesn't necessarily mean it was a good overall product and looking back on it with hindsight is a perfectly valid way of assessing whether they were right.

[Bruce Abbott]

Originally Posted by Thomas Richter

No, it means that you haven't understood the problem. You are with this approach wasting resources you could invest better into something else. ChipRAM bandwidth is one of the bottlenecks, and with the current design the limiting factor. Remove that bottleneck - then planar to chunky conversion becomes the bottleneck. If you're wasting CPU or blitter resources do to the conversion, you don't have these resources available to do something better instead.

You still don't get it. In 1992 Commodore didn't have the resources (time, money, engineering talent, chip manufacturing facilities) to invest in this something else you talk about. What they did have was an ecosystem based around OCS/ECS, so AGA would need to have that in it. They would extend the number of bitplanes to 8 because it was relatively easy to do (the same reason Jay Miner chose bitplanes) and the OS already supported it. They would extend the data bus to 32 bits (same as the A3000 already had from the CPU side) and double CAS to get up to 4 times the bandwidth, because that was also relatively easy. But they wouldn't be doubling the bus speed because that was too hard to do with the limited resources they had.

Trying to do too much at once is why AAA was stillborn. AGA was late even without doubling the bus speed, or adding chunky mode or a 32 bit blitter or 8 sound channels. The time needed to implement that stuff was time that Commodore - and the market - didn't have.

I'm sure the engineers would have loved to implement all those things. But that was what AAA was supposed to be. In the mean time they needed something now to replace the aging A500. They all thought AGA was a pretty good step up, and I agree. With up to 4 times the DMA bandwidth increasing effective blitter speed by up to 60% or more, 256 colors and HAM 8 in all resolutions up to 1280x512, bigger sprites and more colorful dual playfields, there was plenty for Amiga developers and users to like. Add a 32 bit CPU running at twice the clock speed of the 68000 and you have big step up on the A500 - for a very modest price increase.

Then you come barging in 32 years later to dump on their efforts - which is not only very silly but also off-topic for this thread. AGA bandwidth is what it is and arguing that it should have been something else is not helping at all.

[BSzili]

This is now a what if thread, excellent!

[TCD]

Originally Posted by BSzili

This is now a what if thread, excellent!

The Whatif monster is slowly consuming the whole board!

[sokolovic]

Originally Posted by TCD

The Whatif monster is slowly consuming the whole board!

Maybe we could talk about Shadow of the Beast then ?

[Thomas Richter]

Originally Posted by Bruce Abbott

You still don't get it. In 1992 Commodore didn't have the resources (time, money, engineering talent, chip manufacturing facilities) to invest in this something else you talk about.

The entire comparison you make is quite silly. You assume a system where you render in fast, then manually copy (or convert) to chip. That's bizarre - the entire blitter system was actually designed to offload rendering to the chipset, and not to ignore the chipset. Copying chunky regions is at least possible with the blitter - though not the area filler and the line drawer. You like to "prove" that "c2p does not add complexity" and "chunky isn't worth it". That's attempting to justify bad decisions by setting up biased measurements.

Originally Posted by Bruce Abbott

What they did have was an ecosystem based around OCS/ECS, so AGA would need to have that in it. They would extend the number of bitplanes to 8 because it was relatively easy to do (the same reason Jay Miner chose bitplanes) and the OS already supported it.

The decision for planar was made a time there wasn't sufficient memory and bandwidth available. It created a system that was relatively easy to scale in memory, but relatively hard to scale otherwise. So that's a historical artefact, but not an argument to base future systems on it.

Originally Posted by Bruce Abbott

Trying to do too much at once is why AAA was stillborn. AGA was late even without doubling the bus speed, or adding chunky mode or a 32 bit blitter or 8 sound channels. The time needed to implement that stuff was time that Commodore - and the market - didn't have.

AGA was late because the management was asleep, and not because the technology would be impossible to do. Instead, they created with the A3000 an expensive system build around a budget chipset, and hoping people would buy it. AGA would have been an idea to put into the A3000. High end system, new high end chipset (by then) - that would have made sense. When I saw the A3000 at the CeBit in Hannover, I was really wondering who would want to invest so much money in a system that wasn't much more capable what I already had. Sounds like I was not the only one.

Originally Posted by Bruce Abbott

Then you come barging in 32 years later to dump on their efforts - which is not only very silly but also off-topic for this thread. AGA bandwidth is what it is and arguing that it should have been something else is not helping at all.

AGA bandwidth is what it should have been two years earlier. And that two years they could have used to design a better system. Planar was certainly *not* the way to move foreward anymore, it was rather obvious to see.

[Bruce Abbott]

Originally Posted by Thomas Richter

The entire comparison you make is quite silly. You assume a system where you render in fast, then manually copy (or convert) to chip. That's bizarre...

No, it's making better use of the hardware. When you have a fast CPU with local RAM it's more efficient to render your single (8 bit) pixels into that RAM and copy it to the slower screen memory 32 bits at a time.

- the entire blitter system was actually designed to offload rendering to the chipset, and not to ignore the chipset.

The entire blitter system was designed to be faster than the slow CPUs of the day, by eliminating instruction overhead and being able to work in parallel with the CPU (when it's not accessing ChipRAM). When you have a much faster CPU a lot of that advantage evaporates. This is not a fault of the design since such CPUs didn't exist at the time.

Copying chunky regions is at least possible with the blitter - though not the area filler and the line drawer.

Yes, and 'cookie cutting' too. You could even change colors while copying by masking off individual bits - perhaps get anti-aliasing for free!

You like to "prove" that "c2p does not add complexity" and "chunky isn't worth it". That's attempting to justify bad decisions by setting up biased measurements.

I never said c2p doesn't add complexity. Obviously it does. But it has the huge advantage that no extra hardware is required, and the code is small and not overly complex so it's easy to implement. We would all love to have chunky in hardware - but we don't, and getting it in hardware is expensive. Code costs nothing and reaches the widest audience.

The measurements are not 'biased', they are simply reality. If you disagree then please show us your code that gets a faster frame rate in Doom using some other method.

You talk about 'bad decisions' with the benefit of your 20/20 hindsight and armchair engineering skills, as if you would have done better. Maybe you are right and Jay Miner etc. were all idiots compared to you, but without a time machine there's nothing anyone can do about that. That's not to say we can't make improvements now though. Please show us your design for a circuit with chunky pixels and much faster operation that can be added to or replace the AGA chipset at a reasonable price. Here's something to get you started:-

Amiga Replacement Project

"To make replacements for all the custom chips of the AMIGA, useable in any real AMIGA."

AGA-on-ECS
This provides as much AGA functionality on either OCS or ECS based systems and retains the existing pinouts (and 16-bit data bus limitation). It should be possible to implement FP/EDO memory to get 2X increase and it might be possible to extend that to a 4X improvement with faster memory. We may also simply use SDRAM (3.3V SDR) and start with the fastest memory we can to achieve this.

Originally Posted by Thomas Richter

The decision for planar was made a time there wasn't sufficient memory and bandwidth available. It created a system that was relatively easy to scale in memory, but relatively hard to scale otherwise. So that's a historical artefact, but not an argument to base future systems on it.

In 1991 there were very good reasons to base 'future' systems on it - compatibility, cost, engineering skills, time to market.

AGA was late because the management was asleep, and not because the technology would be impossible to do.

15 engineers working on AAA, management expecting results and not getting them because the engineers didn't have the skills. Of course if they were all geniuses like you it would have been a piece of cake, right? Or would management have had to constantly crack the whip to motivate you?

Your rant is off-topic. There are other threads you can post in to argue your theories - though be warned that the subject has already been discussed ad nauseam. Here we are discussing c2p performance on actual Amiga hardware, not some theoretical machine that you imagine would have appeared in a perfect universe.

[lmimmfn]

Originally Posted by TCD

The Whatif monster is slowly consuming the whole board!

Lmao, I spat out my tea

[grelbfarlk]

What if ID made Doom in the Shadow of the Beast engine.
+So many more frames of animation for each character.

+You can just shoot things instead of limply punching them.

+Will run at a high framerate on a 68000@7MHz.

-Scrolling will be jerky on anything less than a Pentium, apparently, I guess.

-Joystick and keyboard support comes later, if you have a really wide mousepad, it's not so bad but you are literally scrolling horizontally the linear feet your character is running.

[Thomas Richter]

Originally Posted by Bruce Abbott

No, it's making better use of the hardware. When you have a fast CPU with local RAM it's more efficient to render your single (8 bit) pixels into that RAM and copy it to the slower screen memory 32 bits at a time.

"Better use of" in the sense of "burns more cycles"? By utilitizing the CPU for things the chipset could do better?

Originally Posted by Bruce Abbott

The entire blitter system was designed to be faster than the slow CPUs of the day, by eliminating instruction overhead and being able to work in parallel with the CPU (when it's not accessing ChipRAM). When you have a much faster CPU a lot of that advantage evaporates. This is not a fault of the design since such CPUs didn't exist at the time.

And when that happens, it is time to stay asleep and keep the chipset as it? Is that your sort of logic?

Originally Posted by Bruce Abbott

I never said c2p doesn't add complexity. Obviously it does. But it has the huge advantage that no extra hardware is required, and the code is small and not overly complex so it's easy to implement. We would all love to have chunky in hardware - but we don't, and getting it in hardware is expensive. Code costs nothing and reaches the widest audience.

Then don't argue that it doesn't add complexity. Add real measurements - what about the same engine on a RTG graphics card - with chunky memory and a chunky blitter? That it something CBM could have done, if they just haven't been asleep. Reinterpreting the planar data from Agnus in chunky is not exactly rocket science.

Originally Posted by Bruce Abbott

The measurements are not 'biased', they are simply reality. If you disagree then please show us your code that gets a faster frame rate in Doom using some other method.

They are biased because they are measuring stupid algorithms. There is no reason to convert, and you should use the blitter to do the job. No, that's obviously not possible with ECS, but that's exactly the point.

Originally Posted by Bruce Abbott

You talk about 'bad decisions' with the benefit of your 20/20 hindsight and armchair engineering skills, as if you would have done better.

I'm talking about decisions that were quite obvious at that time. Or how do you call a "read my lips - no new chips" decision "reasonable" at times increasing competition, and pressure from other systems? I once was a student at IBM - they had a slogan there: "If you don't row - you don't stop - you drift backwards".

Originally Posted by Bruce Abbott

Maybe you are right and Jay Miner etc. were all idiots compared to you,

Jay wasn't an idiot - he left the company due to some management idiots.

Originally Posted by Bruce Abbott

but without a time machine there's nothing anyone can do about that.

Then why do you come up with some biased measurements attempting to sell me that "nothing was wrong"? Actually, a lot was wrong.

Originally Posted by Bruce Abbott

That's not to say we can't make improvements now though. Please show us your design for a circuit with chunky pixels and much faster operation that can be added to or replace the AGA chipset at a reasonable price.

Take the Akiko logic, put it at the end in Alice. Really, it is not so complicated.

Originally Posted by Bruce Abbott

In 1991 there were very good reasons to base 'future' systems on it - compatibility, cost, engineering skills, time to market.

The "future system" was based on "same old shit". Well, maybe that was "engineering skill" at CBM - I don't think so. That was "management skill".

Originally Posted by Bruce Abbott

15 engineers working on AAA, management expecting results and not getting them because the engineers didn't have the skills. Of course if they were all geniuses like you it would have been a piece of cake, right? Or would management have had to constantly crack the whip to motivate you?

Management wasn't motivating - management was doing exacly the oposite - they *killed* the ideas by stupid decisions. Like not willing to invest into chips.

Originally Posted by Bruce Abbott

Your rant is off-topic. There are other threads you can post in to argue your theories - though be warned that the subject has already been discussed ad nauseam. Here we are discussing c2p performance on actual Amiga hardware, not some theoretical machine that you imagine would have appeared in a perfect universe.

I'm not talking about "theoretical machines". Take a real Amiga with a chunky graphics card, and a real algorithm using a blitter on such a machine. That will give you some realistic perofrmance numbers. Sure, such cards did not exist back then - but with a little bit of glue logic, they could have existed in the form of the chipset.

[sokolovic]

Originally Posted by grelbfarlk

What if ID made Doom in the Shadow of the Beast engine.
+So many more frames of animation for each character.

+You can just shoot things instead of limply punching them.

+Will run at a high framerate on a 68000@7MHz.

-Scrolling will be jerky on anything less than a Pentium, apparently, I guess.

-Joystick and keyboard support comes later, if you have a really wide mousepad, it's not so bad but you are literally scrolling horizontally the linear feet your character is running.

Yes but would it be a crap game ?

[Dunny]

Originally Posted by sokolovic

Yes but would it be a crap game ?

What? It's SOTB so no.

[Karlos]

To get this thread back on topic, the basic question is perhaps not well phrased. They all consume about 100% CPU while they run. The CPU itself might be stalling for data or on writes during that time if it's really fast and the memory is slow, but you aren't going to be task switching in the middle to save them cycles for something else: it's a short cpu/memory bound workload.

A better question might be, how long does c2p take? You can start by benchmarking your best fast to chip copy time. That's your "light speed" solution that you won't get any faster than.

Divide your screen area to be converted (in bytes) by that number to get a value in seconds. That's your absolute best case. Any actual c2p will be slower.

The best ones, on 060 with good memory interfaces, tend to almost perfect and we say they achieve "copy speed".

[Thomas Richter]

Yes, you can achieve "copy speed", but that's because "copy speed" is slow. The trick is to avoid the copy in first place, and let the chipset do the work. But that's not possible due to an architecture bound to planar.