Performance of Akiko C2P on 030/50 CD32 systems

[abu_the_monkey]

If the numbers are correct, it's an even bigger shame that Akiko can't do direct DMA to chip ram.

[Karlos]

Originally Posted by abu_the_monkey

If the numbers are correct, it's an even bigger shame that Akiko can't do direct DMA to chip ram.

True. Especially given the chip *does* have DMA already. I think it uses some ring buffers or something for the CD drive.

The numbers do look a bit startling though. Especially given that its pixels converted per second, full round trip.

I'll put the code on GitHub later in the interests of transparency

[Karlos]

The numbers do seem a bit "unpossible" though. This has to be some sort of cache interference if the loop counts are correct and timing is accurate.

I'll move onto testing and actual block conversion when I get a minute later. That might be more informative

[paraj]

Haven't spotted any errors in your code, but they seem too good to be true. Unless my math is off (wouldn't be the first time) 53768 CIA ticks would correspond to 20*53768=1075360 14MHz clock ticks with each loop iteration taking (20*53768)/100000 = 10.7536 of those. Seems suspiciously low with 16 accesses... The ones taking twice as long might be believable.

[Karlos]

Originally Posted by paraj

Haven't spotted any errors in your code, but they seem too good to be true. Unless my math is off (wouldn't be the first time) 53768 CIA ticks would correspond to 20*53768=1075360 14MHz clock ticks with each loop iteration taking (20*53768)/100000 = 10.7536 of those. Seems suspiciously low with 16 accesses... The ones taking twice as long might be believable.

Even the ~170ms runs seem a bit suspect - that would be 18.8 MPix/s, which implies 18.8MB/s written to Akiko and 18.8MB/s read back.

[robinsonb5]

There's definitely something weird going on with the timing here.
Just out of curiosity I ran the test on the Minimig FPGA core and watched its operation using SignalTap - here's a trace.
(There are two accesses per longword because the TG68 CPU has a 16-bit bus, so my implementation of the Akiko cornerturn expects pairs of word accesses.)

So a complete iteration, from the start of the first write to the start of the next block of writes, takes roughly 352 cycles of the fastest clock in the system, which is 113.34MHz.
I make that 8.82ns per cycle times 352 cycles = 3105ns, or 3.105us for one complete round of the test.

The test is 100000 rounds long, so roughly 310.5ms for the entire test.

Yet the program usually reports about 89000 ticks, 126ms - and sometimes reports only 2,000 ticks, 30ms.

(I'm wondering if maybe ReadEClock() reacts badly to interrupts being disabled for an extended period?)

[paraj]

FWIW here's my timing code that I've never had problems with on my 060 (note: hard coded assumption about 50MHz). Can't remember why I open util.library in the code though..

[Karlos]

To my knowledge, the Eclock is driven by a divider on the bus. It shouldn't be impacted by interrupt status (unless using it to create a delay of course).

[paraj]

Originally Posted by Karlos

To my knowledge, the Eclock is driven by a divider on the bus. It shouldn't be impacted by interrupt status (unless using it to create a delay of course).

I don't remember exactly how the OS handles it, but there is the issue of rollover. Can't remember the details right now of how often that happens, but when timing I found it best to let OS do its stuff regularly and sum time time (with DMA off!) of inner loop.

[Karlos]

Should be about every 101 minutes to wrap the lower 32-bit value at 709kHz or so.

[robinsonb5]

Originally Posted by Karlos

Should be about every 101 minutes to wrap the lower 32-bit value at 709kHz or so.

Except the CIA timer registers which are clocked by eclock are only 16 bits wide, so they overflow every 90ms or so. The OS checks for an overflow and increments the upper 48 bits of the timestamp if detected, but it can only detect a single overflow; if the counter wraps round several times while interrupts are disabled it will indeed lose time.

It might be better to time using the TOD clocks - they're 24-bits wide and on slower clocks (VSync or PSU tick for one CIA, and HSync for the other), so wraparound is rare.

[Karlos]

Originally Posted by robinsonb5

Except the CIA timer registers which are clocked by eclock are only 16 bits wide, so they overflow every 90ms or so. The OS checks for an overflow and increments the upper 48 bits of the timestamp if detected, but it can only detect a single overflow; if the counter wraps round several times while interrupts are disabled it will indeed lose time.

Right, that's got to be it. The only solution then is to use a smaller benchmark, call it multiple times and average the results.

[paraj]

Originally Posted by Karlos

Should be about every 101 minutes to wrap the lower 32-bit value at 709kHz or so.

It's only 32-bit if they're in cascade mode and you use both 16-bit timers. Probably else going on, but IIRC timer.device only relies on one 16-bit counter and proper OS operation for wrap around.

EDIT: what robinsonb5 said

[Karlos]

That's the first time the Eclock has ever let me down. Mind you, I don't normally write code that runs with interrupts disabled.

A better iteration might be 2560 (equivalent to 320*256 pixels) and accumulate a bunch of those. Then, outliers an be identified and eliminated, and the remainder averaged.

[paraj]

Originally Posted by Karlos

That's the first time the Eclock has ever let me down. Mind you, I don't normally write code that runs with interrupts disabled.

It's because you're such a nice person that doesn't usually beat the system on the head.


My timing.c spaces the beatings for this reason.

[Karlos]

Originally Posted by paraj

It's because you're such a nice person that doesn't usually beat the system on the head.


My timing.c spaces the beatings for this reason.

Yeah, I'm going to go for conversion cycles closer to a real workload size.

[abu_the_monkey]

learning new stuff all the time

Yeah, I'm going to go for conversion cycles closer to a real workload size.

sounds like the way to go

[Karlos]

Can we retry the version from here:

https://github.com/0xABADCAFE/akiko-fun/tree/main

This does 20 runs of 2560x32 e,g, (320x256) and derives from there.

Note that it's still only testing reg > hw > reg until we are getting sensible measurements. Then I will start doing actual c2p conversion tests.

[Lunda]

Originally Posted by Karlos

Can we retry the version from here:

https://github.com/0xABADCAFE/akiko-fun/tree/main

This does 20 runs of 2560x32 e,g, (320x256) and derives from there.

Note that it's still only testing reg > hw > reg until we are getting sensible measurements. Then I will start doing actual c2p conversion tests.

See attached pic.

[abu_the_monkey]

that is more believable.

still almost 9mb/s ain't too shabby.

@Lunda is that with the 030 clock at 70mhz? (5 times the 14mhz cpu clock)