Performance of Akiko C2P on 030/50 CD32 systems

[Cyprian]

Originally Posted by Karlos

A wild thought appears:

Consider that the limits to Akiko are in the transfer of converted planes from it's register to the chip ram.

GRIND only uses a 4 bit display depth. On an unexpanded CD32. You still have to write 8 longs to it, but you only have to transfer 4. So, it might give a significant boost to the already decent framerate on CD32.

as far as I remember GRIND uses 6bits per chunky pixel and converts it to four bitplanes. Additional bits are used for color interleaving.

[Karlos]

Originally Posted by Cyprian

as far as I remember GRIND uses 6bits per chunky pixel and converts it to four bitplanes. Additional bits are used for color interleaving.

From a bandwidth perspective, what matters is how much data you have to move from Akiko to chip memory. If there are only 4 bitplanes, you only read Akiko 4 times and move the longs to their target planes.

The actual write and read access to Akiko itself is much faster. On the 030/70, it maxed out the bus. This is why I think an Akiko routine for a 4 plane target is a potential performance win, but at the same time, the way Dread organises it's data may make it difficult to retrofit.

[paraj]

Originally Posted by KK/Altair

You've got the first 16 bits right (except IIRC the topmost bits are bitplane 0).
But the columns are interleaved in Dread engine, so it's not followed by B3 but A3[1] - or however you would denote the logical pixel just below A.

Thanks for the info (and the great work obviously), now it's clearer what the blits do.


This makes good use of the blitter passes to shuffle things back from the "scrambled" column layout to a more normal one for free while doing the C2P steps.


For the purposes of this thread I think it means Akiko will be close to useless. However maybe in the (very) long run the Grind team will optimize for 030+ (where blitter C2P isn't the best approach) in which case another chunky buffer layout might be on the table, and it can be revisited. But obviously A500 first

[Karlos]

Wildcard necromancy...

It turns out there are Minimig implementations with Akiko. I wonder if they are more viable.

[abu_the_monkey]

Originally Posted by Karlos

I wonder if they are more viable.

In what way?

for testing?

I know it is a hardware implementation, but, would it be accurate timing wise to a real cd32 or is it just enough to get the software/games that use it to work?

it might give odd results if you were to run your akiko test program on it (like winuae does), but, you never know.

[Karlos]

Originally Posted by abu_the_monkey

In what way?

for testing?

I know it is a hardware implementation, but, would it be accurate timing wise to a real cd32 or is it just enough to get the software/games that use it to work?

it might give odd results if you were to run your akiko test program on it (like winuae does), but, you never know.

Apparently other Akiko enabled titles run better on it, so I can only assume access times are improved. It must still work the same way from a programming perspective.

[abu_the_monkey]

can't believe that no one with a tf330 gave your akiko test tool a try and reported the results.

[Karlos]

I lost interest and started looking at the sound side. I think I have pretty decent 16 channel mixer for 040+, but I still need to complete the output side and put some proper thought into latency/synchronisation. I thought I'd have a break from that for a short time and go back to doing some modding, since that's what it was all for