Do these timings look right

[Auscoder]

Using blitter to perform some performance tests right now.. side project fun.

Orange section is using 50% clear using Blitter (Nasty cleared) and 50% CPU
Wait blitter called immediately after the CPU code completes. Its called at the start of the vertical blank interrupt. (total approx 30 scanlines)

Blue section is 3 individual blits, each 48x48x3 bitplanes using all channels, masked, and interleaved source+dest data. I add another 1 word for shifting. So really 64x48x3... These more or less scale linearly when blitting the same source data. ie. 1 blit is using only 33% of the blue time. waitBlitter called between individual blits. (total approx 57 scanlines) (or approx 19 scan lines per 64x48x3 bitplane blit)

Green is free CPU time once waitBlitter is called (with nasty bit set)

I wanted to check if these timing seem reasonable. CPU shouldnt matter if I understand right, Blitter speed should not be impacted here. The CPU is an 040 under WinUAE. So important for the clear... Most accurate emulation settings I could find. Its very similar running on my A1200/060

How does it look? Did I do something silly

[Toni Wilen]

It probably is correct if CPU is not doing any chipset bus accesses during the blit because 68040+ CPU speed and memory accesses are far from accurately emulated. (Number of accesses is closer to real if memory cycle exact and data cache emulation is enabled but timing between accesses is still going to be far from correct)

If blitter nasty is off, CPU accesses to chipset bus (which includes custom registers = nasty off and polling bltbusy wastes blitter cycles) will affect blitter speed.

If you do blitter clear, you can keep blitter nasty enabled because clear cycle sequence uses every other cycle, CPU will always have cycles available.

[Auscoder]

Originally Posted by Toni Wilen

It probably is correct if CPU is not doing any chipset bus accesses during the blit because 68040+ CPU speed and memory accesses are far from accurately emulated. (Number of accesses is closer to real if memory cycle exact and data cache emulation is enabled but timing between accesses is still going to be far from correct)

OK thanks for that, not super critical that UAE is exactly correct or not, as I have seen super close results for the CPU/Blitter clear (weirdly then) on the real hardware. I have been using cycle exact and data cache emu.

If blitter nasty is off, CPU accesses to chipset bus (which includes custom registers = nasty off and polling bltbusy wastes blitter cycles) will affect blitter speed.

So is it right to say then that : With Blitter nasty off that only the chipset bus access will slow the blitter. How about regular chip ram access, or even fast ram. Does blitter only give up cycles with nasty off when the CPU is busy? If CPU is not busy and nasty is off, does blitter still give up those cycles? Seems so?

If you do blitter clear, you can keep blitter nasty enabled because clear cycle sequence uses every other cycle, CPU will always have cycles available.

Thanks, this makes sense and correlates with the profiling I have seen. I didn't understand why until now.

[Kalms]

Originally Posted by Auscoder

So is it right to say then that : With Blitter nasty off that only the chipset bus access will slow the blitter. How about regular chip ram access, or even fast ram. Does blitter only give up cycles with nasty off when the CPU is busy? If CPU is not busy and nasty is off, does blitter still give up those cycles? Seems so?

This is detailed in the Hardware Reference Manual. The OCS manual applies to a large extent even for the AGA machines. This page specifically: http://amigadev.elowar.com/read/ADCD.../node012B.html

Particularly these sections toward the end of the page:

If DMAF_BLITHOG is a 1, the blitter will keep the bus for every available
Chip memory cycle. This could potentially be every cycle (ROM and Fast
memory are not typically Chip memory cycles).

If DMAF_BLITHOG is a 0, the DMA manager will monitor the 68000 cycle
requests. If the 68000 is unsatisfied for three consecutive memory
cycles, the blitter will release the bus for one cycle.

The above concerns when the CPU and the 68000 both try to access something on the chipbus. That means custom chip register access or chipram access. (Also, fake-fast access on A500 will result in chipbus allocation, with associated CPU/blitter stalls). "Real fastram" access - for example, when a 68040 accesses fastram that is mounted on the CPU accelerator board itself - will not involve the chipbus, and then the CPU and blitter will not interfere with each other.

[Toni Wilen]

Note that blitter nasty works exactly like described, it is not just blitter cycles that count but _any_ 3 consecutive chipset bus cycles that stalls the CPU.

This is important difference because you might think that for example blitter clear or linedraw is "immune" to blitter nasty=0 because it only uses every other cycle. But if it is interleaved with for example bitplane and copper cycles, CPU may start stealing blitter cycles.