Performance of Akiko C2P on 030/50 CD32 systems

[Karlos]

Originally Posted by abu_the_monkey

nor mine, just a thought that popped in my tired noggin

Well, that's pretty much how all this stated. I was curious about whether or not there was a potential benefit.

[abu_the_monkey]

where are all the guys with a TF330 hiding?

[abu_the_monkey]

Originally Posted by Thomas Richter

Hardly. Akiko is synchronous, and the slow part is attempting to read from its registers as the CPU needs to wait for the relatively slow chip bus. For a conversion from fast mem to chip mem, the CPU does not need to wait for anything - it can retire chip bus accesses in its push buffer while continuing to work. That does not help for Akiko,

does this mean that I have things back to front?
after a write to chip ram I can read from fast with no penalty?

[Karlos]

Originally Posted by abu_the_monkey

does this mean that I have things back to front?
after a write to chip ram I can read from fast with no penalty?

I think you can read as long as it's from cache. If it has to go over the bus, I dunno. This is why I was thinking along the lines of trying to prefill some of the cache. However the numbers don't look great. The NullC2P plus the Akiko Limit suggest that there's no wiggle room.

[pipper]

The whole issue is that the data has to go over the chipmem (from the view of the CPU) bus 3 times. Write to Akiko, read from Akiko, write to destination bitmap planes.
If only they had made Akiko in a way that _it_ would forward the converted data asynchronously to the destination addresses, it would have been the best way. Maybe they could have made it so it can steal DMA cycles from the blitter…dunno. But I guess incorporating Akiko into the whole DMA scheme was a whole other ballgame for a late addition to the chip, so they didn’t.

[thellier]

Not really related to the topic:
Is it possible to use the akiko registers as screen bitmaps (ie setting screen pointers to those registers adresses) ? they would be seen as a 32 pixels line as they are in chip men, no ? then copper could copy new pixels iin those registers for defining next line, perhaps ?

[grond]

Originally Posted by pipper

If only they had made Akiko in a way that _it_ would forward the converted data asynchronously to the destination addresses, it would have been the best way. Maybe they could have made it so it can steal DMA cycles from the blitter…dunno. But I guess incorporating Akiko into the whole DMA scheme was a whole other ballgame for a late addition to the chip, so they didn’t.

Um, in that case they could simply have implemented chunky fetch. Remember, chunky fetch doesn't change the DMA scheme at all, it only means that each bit has to end up in a different place in the palette-lookup registers. It's a simple rewiring.

[Karlos]

This brings me full circle to the odd outliers - games that were reportedly faster on Akiko. Errors in measurement or just completely dominated by C2P time and on a CPU not fast enough to complete the ALU workloads behind the chip write for software C2P to be better?

[Thomas Richter]

Originally Posted by thellier

Not really related to the topic: Is it possible to use the akiko registers as screen bitmaps (ie setting screen pointers to those registers adresses) ? they would be seen as a 32 pixels line as they are in chip men, no ? then copper could copy new pixels iin those registers for defining next line, perhaps ?

No, Akiko does not sit on the custom chip bus, so it cannot act as source (nor destination) of a custom chip DMA.

[Thomas Richter]

Originally Posted by grond

Um, in that case they could simply have implemented chunky fetch. Remember, chunky fetch doesn't change the DMA scheme at all, it only means that each bit has to end up in a different place in the palette-lookup registers. It's a simple rewiring.

As far as Denise is concerned, certainly. However, that still does not give you chunky. It gives you "chunky oddly distributed over 8 sources". Thus, in addition, the DMA logic would have to be touched to get a linear frame buffer.

[Karlos]

Oddly distributed chunky. That reminds me of that RGB port device. What was it? Graffiti?

[Karlos]

Other than determining the actual point at which Akiko becomes slower than the CPU, there's not much else I'm looking for here. The CPU requirements for TKG are high enough already that there's no meaningful intersection below 50MHz 030, except perhaps in 1x2 pixelmode 2/3 size on some slower part.

I'm fully open to suggestions from cycle counters and scheduling sleuths but I think I'm going to put this to one side for now. I'm happy to add the option for Akiko C2P support to the engine for those that want to experiment with it but I think it's going to be counter productive.

[grond]

Originally Posted by Thomas Richter

As far as Denise is concerned, certainly. However, that still does not give you chunky. It gives you "chunky oddly distributed over 8 sources". Thus, in addition, the DMA logic would have to be touched to get a linear frame buffer.

Why would that be? Just point the 1st bitplane pointer to the buffer, the 2nd to buffer+4, the 3rd to buffer+8 a.s.o. and then set the modulo accordingly. Whatever other adjustments might be necessary, could be accomplished through a copperlist.

But I guess this is off-topic in this thread.

[Thomas Richter]

Because the bitmap DMA accesses memory contiguously, and not interleaved. With this setup, the first word accessed by the third bitplane will be identical to the third word accessed by the first bitplane, and this is surely not what you want. Sure, it seems "trivial enough", but I'm not sure how Agnus interacts with memory and whether it has to open pages. Thus, there is certainly something to do.

[meynaf]

Originally Posted by abu_the_monkey

after a write to chip ram I can read from fast with no penalty?

On 040 and 060 yes. On 030 no - any memory access will stall until the write is finished, even from cache.

[Karlos]

Originally Posted by meynaf

On 040 and 060 yes. On 030 no - any memory access will stall until the write is finished, even from cache.

That sucks.

[grond]

Originally Posted by Thomas Richter

Because the bitmap DMA accesses memory contiguously, and not interleaved. With this setup, the first word accessed by the third bitplane will be identical to the third word accessed by the first bitplane, and this is surely not what you want.

I guess one could use the bitplane modulo to basically make each line just one 32bit fetch long and then add a modulo of 28 bytes to skip the other seven bitplanes.

Sure, it seems "trivial enough", but I'm not sure how Agnus interacts with memory and whether it has to open pages. Thus, there is certainly something to do.

I still think chunky-fetch is a rather trivial change once you've got an 8bit planar mode and it certainly is easier to implement than a DMA-driven c2p-converter.

[Karlos]

For the sake of completeness and curiosity, I've added Fast 2 Fast tests for the Akiko Naive, Akiko Naive (reg buffered) and Kalms versions.

[Thomas Richter]

Originally Posted by grond

I guess one could use the bitplane modulo to basically make each line just one 32bit fetch long and then add a modulo of 28 bytes to skip the other seven bitplanes.

While this is true, the modulo is added at the end of the scanline. So yes, this idea works, but only if the display is 16 pixels wide. Well, it's probably *a bit* too narrow to be useful. (-;

Originally Posted by grond

I still think chunky-fetch is a rather trivial change once you've got an 8bit planar mode and it certainly is easier to implement than a DMA-driven c2p-converter.

Sure.

[Karlos]

16 pixels wide you say? That's almost as good as the first generation chunky copper hacks

I take this back, whenever I see AB3D1. No matter how blocky it was, 12-bit RGB is still sweet.