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

[patrik]

Originally Posted by patrik

There is no mirror of this $b80038 register, so 030 caching concerns could be avoided?

I am still curious whether the address decoding results in any mirrors of the Akiko registers?

[Karlos]

Originally Posted by patrik

I am still curious whether the address decoding results in any mirrors of the Akiko registers?

If there is, then you'd at least get rid of the annoying CACR poking

[Thomas Richter]

Actually, you could just load the 68030.library to avoid any CACR poking....

[Karlos]

Originally Posted by Thomas Richter

Actually, you could just load the 68030.library to avoid any CACR poking....

There he goes again, always with the MMU

It was just an experiment in this case. We don't have any firm data to suggest Akiko is any use on 68030 other than the Beast (70Mhz) because so far nobody has tested it. I was made aware however that there are Minimig systems that have it and they might be less hampered by chip ram access which seems to be the limiting factor rather than Akiko itself.

[Thomas Richter]

Originally Posted by Karlos

I was made aware however that there are Minimig systems that have it and they might be less hampered by chip ram access which seems to be the limiting factor rather than Akiko itself.

Akiko was a 5-minute design without too much thought, but also without too much cost. What do you expect from this last-minute hack? The Os support is even less useful - it first goes through Akiko (potentially even accessing out-of-range memory) and then through a second pass with the blitter. Thus, two-pass through two slow devices, a really winning combo.

[Karlos]

Originally Posted by Thomas Richter

Akiko was a 5-minute design without too much thought, but also without too much cost. What do you expect from this last-minute hack? The Os support is even less useful - it first goes through Akiko (potentially even accessing out-of-range memory) and then through a second pass with the blitter. Thus, two-pass through two slow devices, a really winning combo.

That's the funny thing though. The tests we had showed that the implementation wasn't actually that bad. It's having to manually transfer the output to contended chip ram that's the problem more than the IO between the CPU and Akiko itself. Using a fast memory destination, it was converting about 9.3M pixels/sec which is basically the bus limit halved (due to write and read). If you could write back to chip ram at the same pace as you can write to Akiko, things may have been better.