Fastest method to clear a single bitplane on Amiga OCS - My findings

[BigT]

I was messing around with clearing a single bitplane in ASM on A500 OCS ie 320x256=10240 bytes. My findings were as follows:
clr.l (a0)+ dbra loop - 178 scanlines
clr.l (a0)+ dbra loop unrolled x16 clr.l statements - 118 scanlines
move.l d1,(a0)+ unrolled x16 - 73 scanlines
movem.l d1-d6/a2-a3,-(a0) unrolled x2 - 56 scanlines
blitter D channel clear - 50 scanlines
Blitter D + movem.l combination - 27 scanlines


What I was most surprised by was how close in performance a movem.l operation was to the blitter. I had always thought the blitter was much faster....

[ross]

Originally Posted by BigT

I was messing around with clearing a single bitplane in ASM on A500 OCS ie 320x256=10240 bytes. My findings were as follows:
clr.l (a0)+ dbra loop - 178 scanlines
clr.l (a0)+ dbra loop unrolled x16 clr.l statements - 118 scanlines
move.l d1,(a0)+ unrolled x16 - 73 scanlines
movem.l d1-d6/a2-a3,-(a0) unrolled x2 - 56 scanlines
blitter D channel clear - 50 scanlines
Blitter D + movem.l combination - 27 scanlines


What I was most surprised by was how close in performance a movem.l operation was to the blitter. I had always thought the blitter was much faster....

It is actually MUCH faster. Otherwise how could you cut the time required for a clear combining CPU + Blitter?
When you activate only the D channel half of the blitter cycles are idle cycles (therefore usable by the CPU or other DMA channels to access the memory).

[DanScott]

other DMA activity will affect the timings too.

How were these "scanlines" calculated ? Was bitplane DMA active at any point down the screen etc...

[ross]

Originally Posted by DanScott

other DMA activity will affect the timings too.

How were these "scanlines" calculated ? Was bitplane DMA active at any point down the screen etc...

Just checked with my buffer clear code: 27 scanlines without other DMA activity.

[Thomas Richter]

Originally Posted by BigT

What I was most surprised by was how close in performance a movem.l operation was to the blitter. I had always thought the blitter was much faster....

For a task as simple as this, the limiting factor is not so much the CPU power, but the chip memory bandwidth. The advantage is more on the side of the blitter if you try implement the minterms, masking and shifts as well by the CPU.

[BigT]

Originally Posted by DanScott

other DMA activity will affect the timings too.

How were these "scanlines" calculated ? Was bitplane DMA active at any point down the screen etc...

For my simple test, I had the one bitplane active in terms of bitplane DMA and was waiting until line 54 to execute the clear operation.

[BigT]

Originally Posted by ross

Just checked with my buffer clear code: 27 scanlines without other DMA activity.

Is your code using both Blitter & CPU or just Blitter ?

[BigT]

Originally Posted by Thomas Richter

For a task as simple as this, the limiting factor is not so much the CPU power, but the chip memory bandwidth. The advantage is more on the side of the blitter if you try implement the minterms, masking and shifts as well by the CPU.

Agreed, when using advanced logic functions like the cookie cutter $CA, or blitter masks for clipping BOB's, the blitter is far superior to CPU operations on 68000 OCS/ECS platforms.

[ross]

Originally Posted by BigT

Is your code using both Blitter & CPU or just Blitter ?

CPU+Blitter.
And yes, one bitplane do not change much (26~27 or similar, depends on how much I unroll the CPU code).

Originally Posted by BigT

Agreed, when using advanced logic functions like the cookie cutter $CA, or blitter masks for clipping BOB's, the blitter is far superior to CPU operations on 68000 OCS/ECS platforms.

Also the shift operations are free, while with the bare 68k are very heavy.

And no complex operations are required. You try a simple A->D (with blitter nasty active).
CPU is blocked by the maximum speed obtainable with movem, while the blitter uses all available cycles.
Then you realize the real speed of the blitter

[kamelito]

I guess testing if part of the screen is already cleared add too much overhead right?

[ross]

Originally Posted by kamelito

I guess testing if part of the screen is already cleared add too much overhead right?

It depends.
If you have a lot of modified parts and few bitplanes, a full clear is better.
The reverse is true for a few objects and many bitplanes

[dodke]

But often if you use blitter only to clear it can be a great time to do some other calculations you probably need to do anyway using the CPU