@Karlos

Quote:

Karlos wrote: @cdimauro There are some old discussions here http://eab.abime.net/showthread.php?t=74008 I guess the point is that the code is running entirely from the instruction cache and the only memory IO are long reads from fast memory and long writes to chip memory. There are older discussions on Google groups too. -edit- If the bus is completely busy on useful data transfer then I think it's fair to say the code is copy speed.

I doesn't, looking at the thread you kindly provided.

From Matt's comment (#2):
http://eab.abime.net/showthread.php?t=52125
and, again, from the second comment:
http://eab.abime.net/showpost.php?p=659957&postcount=2

a full c2p conversion (without delta etc) need to do 3 things:

1) read 256x240 bytes = 60kB of data from fastmem
2) transform it
3) write 256x240x5 bits = 37.5kB of data to chipmem

Step 1 and 3 can not be done in parallel.
Step 2 can mostly be done in parallel with step 1 & step 3.

Step 1 takes perhaps 20 scanlines.
Step 2 takes perhaps 50 scanlines.
Step 3 takes perhaps 125 scanlines.
[the figures above are rough estimates.]


Thus you can expect the full conversion to take 20+125=145 scanlines. The CPU's memory bus will be busy all the time.
The CPU will be doing actual processing during about 50 of those 145 scanlines. Rest of the time is the CPU stalling waiting for the bus interface to finish previous operations.

The bottleneck is represented by the chip mem access (writes), as expected, and fortunately a good part could be run in parallel (step #2), but the conversion cost isn't zero.

I don't know if those numbers are still valid, or something better was done (the post is very old), since I had no time to read the whole thread.

@cdimauro

I think Kalms routines are still considered the gold standard for C2P. The only thing to do now I guess is to put theory to the test. Use a fast ram buffer and c2p it into chip and time how long it takes for some number of iterations. Then do the same thing for a basic copy of the same data size.

_________________
Doing stupid things for fun...

cdimauro Quote:

The bottleneck is represented by the chip mem access (writes), as expected, and fortunately a good part could be run in parallel (step #2), but the conversion cost isn't zero.

Kalms Quote:

Step 2 can mostly be done in parallel with step 1 & step 3.

"Mostly" is not quite zero.

Kalms Quote:

Thus you can expect the full conversion to take 20+125=145 scanlines.

But the math which excludes the transform/conversion cost says practically zero.

@Karlos

Quote:

Karlos wrote: @cdimauro I think Kalms routines are still considered the gold standard for C2P. The only thing to do now I guess is to put theory to the test. Use a fast ram buffer and c2p it into chip and time how long it takes for some number of iterations. Then do the same thing for a basic copy of the same data size.

Let's see if someone can do some tests and provide real-world numbers.


@matthey

Quote:

matthey wrote: cdimauro Quote: The bottleneck is represented by the chip mem access (writes), as expected, and fortunately a good part could be run in parallel (step #2), but the conversion cost isn't zero. Kalms Quote: Step 2 can mostly be done in parallel with step 1 & step 3. "Mostly" is not quite zero.

Indeed. So, it's not true that it's like just copying data.
Quote:

Kalms Quote: Thus you can expect the full conversion to take 20+125=145 scanlines. But the math which excludes the transform/conversion cost says practically zero.

It's 14% of the overall CP2 time. We can say that it's not so much relevant.

However the full specs of the system weren't disclosed.

@cdimauro

Kalms routines are on GitHub and include some unit tests that could be coopted for this purpose.

_________________
Doing stupid things for fun...

@Karlos

Quote:

The 32-bit aligned write bandwidth (from the CPU) for vanilla AGA is about 7MB/s. If you are "doing it right", you'd want to ensure that your engine is doing that, and not doing single byte writes. This also applies to any RTG card.

The engine here is ADoom which uses some ASM routines to draw wall spans up to two pixels at once. Yes long words would be better. But aside from that it would be plotting pixels one byte at a time.

Quote:

Assuming this bandwidth was your only bottleneck, at 7MB/s you ought to be able to fill about 115 frames per second at 320*200 for 8 bits per pixel.

Just in the copy operation? Well, given Doom is rendering, I didn't even get close!

I did include screen copy speed which ADoom reports itself using what ever method was used.

Quote:

I don't remember exactly, but if memory serves, a loop unrolled move16 based fill I wrote for the BVPPC managed something like 17MB/s (aligned, cached source data).

I considered doing that loop unrolling. Though I had hoped the 68020+ would have included the 68010 loop mode. But it looks like MOVE16 is two words anyway so that wouldn't work.

Quote:

I used to have a small benchmark tool that measured VRAM bandwidth using a variety of techniques and had some data for different cards, including PIV. Alas I lost that a long time ago.

That reminded me. I forgot to mention. My PicassoIV is in the video slot and my CyberVision64 is in a Zorro slot,

@cdimauro

Quote:

The problem here is that the 68060@50Mhz is a monster compared to AGA's chipmem. So, if you directly render to chip ram instead of fast ram, then you're killing the performances. Especially if you don't combine the writes to maximize the chipmem bandwidth usage with 32-bit writes.

My results would confirm this. As shown by the figures and pointed out in my article, directly rendering to chip ram is actually slower than copying an off screen render to chip. In fact, even without the post render copy, I found it to be slower than a C2P conversion! This is what I really wanted to test. Simulating packed-planar by directly rendering to chip ram and assuming it can access a byte per pixel.

Quote:

Also and AFAIR, chipmem cannot be cached. And maybe the Amiga4000 had issues using the burst mode. The MOVE16 might not be used for this reason. But here I don't recall correctly, so it might be ok. To be checked.

I read on forums (like EAB) that MOVE16 may not always have burst mode enabled on Amiga hardware but it will work for the purpose of actually doing a MOVE16.

Quote:

In short: direct rendering to chip ram is expected to give poor results. Better to render to fast mem, and then use a quick routine to copy to chip ram: the "usual way". But then the goal of this experiment (testing packed graphics speed against planar) cannot be achieved...

Yes that was the goal. I'm rather disappointed that all the talk over the years of how the Amiga needed chunky so Doom would be fast may not have been so fast after all. However, we need to consider that Doom was written for VGA hardware, as well as chunky.

Also, my background thinking for this is the usual Amiga game, where screen graphics would be already in chip ram. And could be blitted to screen bitmap as well. Or use the CPU to copy bitmap blocks into screen edge for scrolling. It would be rather inefficient to copy graphics into the bitmap for each frame when the hardware offers features like parallax and scrolling. But a game like Doom is designed to render the screen by hand on each frame.

So, it's not just that the Amiga design is bad for Doom, Doom is a bad design for the Amiga.

@NutsAboutAmiga

Quote:

Interesting to see this score, but score does necessary say everything. I guess also depends on how the graphic card is connected, like Blizzard Vision is connected directly to the CPU accelerator card instead of through a PCI adapter or directly through the Zorro slots.

In my case, PicassoIV through video slot. CyberVisio64 through Zorro slot.

Quote:

You can’t really test an imaginary chipset, you run analyzes, but yeh, chip ram will be a limited factor, you hit, and it does not matter how fast the CPU is.

It's the closest way I could think to do it. In any case, the Doom speed test is the real one, so gives an indication of native, RTG as well as chip.

@Karlos

Quote:

It just occurred to me that this thread split out of the PvP thread (now overrun with x86 v 68k legacy compatibility discussion), which was itself split out of another thread ...

I don't recall for how long I had this idea but as stated the idea would predate discussions. I can have ideas for months onward before I start working on them. But, I checked and it was two months ago I downloaded sources and began the actual work.

@matthey

Quote:

It would be interesting to see bus tests to the graphics card memories of the test machines. The bandwidth is probably enough to not restrict performance though.

The closest to that would be the direct RTG rendering I tested. It takes some time to lock the bitmap, render the frame, then unlock it. Given the screen is a linear framebuffer I don't know if it really renders direct to VGA buffer or not. Since the VGA design isn't exactly a linear framebuffer. And it can be restricted to 64KB pages depending on mode in which case double buffering is out.

Quote:

The Amiga custom chips primarily only have to worry about memory bandwidth. VMEM would have been optimal as Jay Miner noted as dual ported memory allows the custom chips and CPU to access memory at the same time as well as doubling the bandwidth. It probably seemed like VMEM was created for the Amiga and then CBM didn't use it which must have been extremely frustrating for Jay. His motivation was obvious in his drive to finish the Ranger chipset specs before he left CBM only to be ignored and an inferior ECS introduced 3 years after he completed the Ranger specs. Pure incompetence by CBM!

Yes, my conclusion was the Amiga needed VRAM. Even with planar having VRAM would at least have speed it up.

@cdimauro

Quote:

So, it would be good to have some measurement to effectively see how long it takes in such fast processor / system.

...

Quote:

@Karlos: I'll appreciate if you or someone else has some numbers, because it looks strange to me. Maybe HyperX could test only this C2P part.

Yes, this is included in native results. For Native PAL and NTSC. Under Chunky2Planar time.

Last edited by Hypex on 15-Aug-2022 at 02:12 PM.

@pavlor

That's interesting. I find the benchmark does run slower than the actual game. Doom can play itself and on my 060 it's a respectable speed around 20FPS. A few people at my Amiga club were impressed at how well it ran even using AGA. But then I ran the speed test and they wanted to know why it was so slow.

@Karlos
Quote:

Karlos wrote: @cdimauro Kalms routines are on GitHub and include some unit tests that could be coopted for this purpose.

Yup. Let's see if HyperX is interested on benchmarking them.


@Hypex
Quote:

Hypex wrote: @cdimauro Quote: The problem here is that the 68060@50Mhz is a monster compared to AGA's chipmem. So, if you directly render to chip ram instead of fast ram, then you're killing the performances. Especially if you don't combine the writes to maximize the chipmem bandwidth usage with 32-bit writes. My results would confirm this. As shown by the figures and pointed out in my article, directly rendering to chip ram is actually slower than copying an off screen render to chip. In fact, even without the post render copy, I found it to be slower than a C2P conversion! This is what I really wanted to test. Simulating packed-planar by directly rendering to chip ram and assuming it can access a byte per pixel.

I think that's a wrong approach. I'll clarify at the bottom.
Quote:

Quote: Also and AFAIR, chipmem cannot be cached. And maybe the Amiga4000 had issues using the burst mode. The MOVE16 might not be used for this reason. But here I don't recall correctly, so it might be ok. To be checked. I read on forums (like EAB) that MOVE16 may not always have burst mode enabled on Amiga hardware but it will work for the purpose of actually doing a MOVE16.

OK, nice to know. Thanks.
Quote:

Quote: In short: direct rendering to chip ram is expected to give poor results. Better to render to fast mem, and then use a quick routine to copy to chip ram: the "usual way". But then the goal of this experiment (testing packed graphics speed against planar) cannot be achieved... Yes that was the goal. I'm rather disappointed that all the talk over the years of how the Amiga needed chunky so Doom would be fast may not have been so fast after all. However, we need to consider that Doom was written for VGA hardware, as well as chunky. Also, my background thinking for this is the usual Amiga game, where screen graphics would be already in chip ram. And could be blitted to screen bitmap as well. Or use the CPU to copy bitmap blocks into screen edge for scrolling. It would be rather inefficient to copy graphics into the bitmap for each frame when the hardware offers features like parallax and scrolling. But a game like Doom is designed to render the screen by hand on each frame. So, it's not just that the Amiga design is bad for Doom, Doom is a bad design for the Amiga.

No, I think that the approach is not correct. Of course, Doom is a 3D game, so it's very different from the 2D ones which were the more popular ones on the Amiga.

However you're making tests on a unbalanced and much younger platform. I mean: an 68060@50Mhz running Doom greatly exceeds the specs of PCs running Doom when this game arrived.

The bottleneck for your Amiga 4000 was/is the AGA chipset, and it was obvious that it creates its own problems even with your "beast". But your machine is much more powerful compared to a 386 or a 486, which were the most common CPUs used for running Doom. So, you're surpassing the AGA problems with a very powerful CPU + memory system.

To be more clear, if your goal is to check the comparison between packed and planar, then you should use very very similar systems, with ideally only this feature which is different. Otherwise you aren't comparing packed vs planar, rather benchmark two different systems.

So, the best test would be using systems where all is exactly the same, but with one using planar and the other using packed. Possible solution: changing WinUAE implementing an additional hardware configuration where there's only packed. Then you can test an Amiga 1000/500/2000/600 in cycle-exact mode for chipset & CPU, and it'll give a much more realistic result.

Or, just implement single routines which simulate the display controller, or implement some primitives, and then you can benchmark them using exactly the same workload. However this will not benchmark an hardware system with packed and planar.
Quote:

Hypex wrote: @cdimauro Quote: So, it would be good to have some measurement to effectively see how long it takes in such fast processor / system. ... Quote: @Karlos: I'll appreciate if you or someone else has some numbers, because it looks strange to me. Maybe HyperX could test only this C2P part. Yes, this is included in native results. For Native PAL and NTSC. Under Chunky2Planar time.

OK, thanks.
Quote:

Hypex wrote: @pavlor That's interesting. I find the benchmark does run slower than the actual game. Doom can play itself and on my 060 it's a respectable speed around 20FPS. A few people at my Amiga club were impressed at how well it ran even using AGA. But then I ran the speed test and they wanted to know why it was so slow.

20FPS is a very good result: very fluid, albeit not full-motion.

And that's thanks to your "beast".

@Hypex

Amiga 4000 lacks a fast local bus for the video card and it doesn't help the overall frame buffer performance.

486's fast VL-Bus concept has evolved into AGP and PCIe 16 lanes slots where the graphics card has a fast conduit with the host CPU. AGP is the PCI-era solution for a fast graphics slot.

In 1996, I have encountered a situation between upgrading my Amiga 3000 with CyberVision 64 and CyberStorm 68060 @ 50Mhz

vs

Buying an out-of-the-box PC clone with Pentium 150/S3 Trio 64UV graphics card/Yamaha Sonata 16bit sound card/1 GB Quantum Bigfoot IDE-based PC. Pentium 150 was overclocked to 166 Mhz with a 60 Mhz to 66 Mhz jumper.

CyberVision 64 has an S3 Trio 64V chip.

Stealth 64 PCI has an S3 Trio 64V chip.


For Doom benchmarks from https://thandor.net/benchmark/32
Stealth 64 PCI 1MB PCI (with Pentium 100) scored 65.74 fps.

Meanwhile, Diamond Viper V330 PCI (NVIDIA RIVA 128) scored 70.19 fps.

C= AGA's 19.6 fps is payable and performance is somewhere within the mid-range ISA SVGA cards.

ET4000AX 1MB ISA with Pentium 100 (and related 430VX PCI chipset and ISA bridge) has scored 27.10 fps.

ET4000AX comes in very fast 16-bit VRAM or 32-bit DRAM SKUs.

Amiga 1200 AGA couped with fast CPU has less bus mastering overheads when compared to Amiga 4000's Zorro III Super Buster chipset.

The real transfer speed between the Amiga 3000/4000 implementation of Zorro III and a Zorro III card is somewhere around 13.5 MByte/s due to the limitations of the Buster chip.

Intel's first PCI implementation peaked at 25 MByte/s.

-----
On a side note, Pentium 166 Mhz with SiS6326 PCI card scored 88.08 fps, but compared to NVIDIA RIVA/TNT, the SiS 6326 chipset is trash with OpenGL.

I'm in the not position to buy Amiga 1200 since my Dad purchased both an Amiga 3000 and 368DX-33+ET4000AX PC clone and around early 1992 to 1993 respectively. My Dad wasn't aware of Amiga 1200's Q4 1992 release window. My Dad wasn't happy about aging Amiga 3000's ECS after Amiga 1200's AGA release.

Last edited by Hammer on 16-Aug-2022 at 04:55 AM.
Last edited by Hammer on 16-Aug-2022 at 04:51 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)

@Hypex

https://www.youtube.com/watch?v=lH7l_sU-mCk
With 68060 @ 100Mhz, Amiga 1200 AGA vs RTG running Doom II. Amiga 1200 AGA frame rate is higher than your Amiga 4000 setup. The real-time frame rate counter is in the top right corner.

Last edited by Hammer on 16-Aug-2022 at 05:54 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

It's not clear which RTG card is in use in the video, but the fact that the framerate isn't much better on the RTG card suggests that there could be some bus speed limitations here. For Doom to work at its best under RTG, it's essential that the widest data are transferred so as not to waste bandwidth.

_________________
Doing stupid things for fun...

@Karlos

From https://youtu.be/lH7l_sU-mCk?t=131
It shows "CSGFX". This is CSLabs RTG. Warp1260 for Amiga 1200.

CSGFX has a better frame rate stability when compared to AGA.
A1200's AGA still scales with a fast CPU.

Last edited by Hammer on 16-Aug-2022 at 09:15 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)

@cdimauro

Quote:

20FPS is a very good result: very fluid, albeit not full-motion.

A1200's AGA is capable of full motion video with CSLabs Warp A1260's 68060 @ 100 Mhz. You're bullshit again.

_________________
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

At up to 7MB/s, AGA should be capable of playing video, especially if it's already in a suitable format and streaming from memory.

However, if what you have is some modernish compressed video stream, with all the mpeg like compression tricks and YUV encoding streaming from disk, then I dunno. That's a big workload even before you decide how to convert your RGB pixels into something renderable on screen.

_________________
Doing stupid things for fun...

PADDING

_________________
I HAVE ABS OF STEEL
--
CAN YOU SEE ME? CAN YOU HEAR ME? OK FOR WORK