Maximum blitter speed with pipelining

[zero]

Originally Posted by roondar

So, the gain is in not needing to update every value every frame.

Don't underestimate the overhead of interrupts either, or the time wasted polling. Particularly on an 020 or with fast RAM, the copper is a lot better.

[roondar]

Originally Posted by zero

Don't underestimate the overhead of interrupts either, or the time wasted polling. Particularly on an 020 or with fast RAM, the copper is a lot better.

Indeed, on machines with fastram using the copper is always better. And interrupt based blitting is almost always the slowest option out of the three choices here

Never tried stuff on the 68020 but IIRC the A1200 CPU can write to chipmemory at twice the speed of the copper so it may actually be interesting to so what that does to the advantage of the copperlist.

I do want to add that on a 68000 without fastram, polling can be done for ~20 CPU / 10 DMA cycles total per blit by dynamically switching BLTPRI on and off while still working on faster CPU's (or 0 cycles by never switching it off ever - though this will break stuff on faster CPU's so I wouldn't do that).

So polling overhead is not as high as you'd think.

None of which changes that using the copper can result in gains, which is interesting and nice to know.

---
Edit: I became a bit unsure about the amount of cycles for polling I stated, so I checked to be certain.
My Blitter wait code including cycle count on a 68000:

cycles	code
16			move.w	#$8400,dmacon(a6)
16	.bltwait	btst.b	#DMAB_BLTDONE-8,dmaconr(a6)
 8			bne.b	.bltwait
16			move.w	#$0400,dmacon(a6)
-- 56c

So I was in fact wrong, the polling takes 56 cycles which is much more than I guestimated and makes using the Copper a better bet than I figured.

[britelite]

Originally Posted by Photon

It does for most things everyone does with the Blitter.

Exceptions are clear and polyfill.

I have a several other use cases too where the blitter doesn't completely block the cpu

[dissident]

Actually I work on some AGA-routines that use the copper to set up the blitter for line-drawin/filling and moving BOBs.

I noticed, that the speed of the blitter is different on an A1200/020 without FAST memory and on an 68060/50 mHz with FAST memory. I waitet for the last blit to be finished in my copperlist and change the background colour. Funnily the blitter needs more time on the 68060 system. And on a friend's A1200/060 who has pushed it upto 83 Mhz the blitter is also much slower, too. Time critical routines on a 68020 machine which use the blitter&copper and finish at line $135 don't work on faster processors. Turning on BLTPRI doesn't help anyway, because of FAST memory. Or if the routine runs also on the 68060 then turning on BLTPRI freezes all.

Is there any special behaviour of the BLTPRI-Bit in conjunction with FAST memory&Caches?

[Toni Wilen]

It is most likely caused by slow CPU chip ram (and custom registers) access speed. (Blitter speed is still the exact same). It is "feature" of most accelerators.

[sandruzzo]

I think with fast processor is better to split works betwenn cpu and blitter, or better do all by cpu

[borchen]

Last week I just figured out how to let the copper 'drive' the blitter and I actually got it to work! (I'm still in assembly-noob-country)

In my original code I used the CPU to setup/trigger the (rather small) blit:

    lea	$dff000,a6		; a6 = custom chips base

    bsr.w    WaitBlitter

    move.l    #$09f00000,BLTCON0(a6)        ; blit control 0 & 1
    move.l    #$ffffffff,BLTAFWM(a6)        ; blit source A masks

;----- 1, row 1, tile 1

    move.w    #0,BLTAMOD(a6)            ; blit source A modulo
    move.w    #scrBpl-(tileBpl*1),BLTDMOD(a6)    ; blit dest D modulo
    move.l    #Sword,BLTAPTH(a6)        ; blit source A
    move.l    #Screen+(tileBpl*0),BLTDPTH(a6)    ; blit destination D
    move.w    #(tileH*BPLS)<<6+(tileW*1/16),BLTSIZE(a6); blit size = start

I converted this CPU-blitter-setup/trigger into the copperlist:

    dc.w    $ffdf,WAIT        ; line 255    

;----- trigger blitter

    dc.w    $0001,$7ffe        ; wait for blitter

;----- initialize blitter

    dc.w    BLTCON0,$09f0        ; blit control 0
    dc.w    BLTCON1,$0000        ; blit control 1

    dc.w    BLTAFWM,$ffff        ; blit source A first mask
    dc.w    BLTALWM,$ffff        ; blit source A last mask

;----- blit 1: row 1, tile 1

    dc.w    BLTAMOD,0        ; blit source A modulo    
    dc.w    BLTDMOD,scrBpl-(tileBpl*1)    ; blit dest D modulo

    dc.w    BLTAPTH            ; blit source A
blt1apth:
    dc.w    0

    dc.w    BLTAPTL            ; blit source A
blt1aptl:
    dc.w    0

    dc.w    BLTDPTH            ; blit destination D
blt1dpth:
    dc.w    0

    dc.w    BLTDPTL            ; blit destination D
blt1dptl:
    dc.w    0

    dc.w    BLTSIZE,(tileH*BPLS)<<6+(tileW*1/16)    ; blit size = start

Now all I had to do, in my initialization code, was poke the blt1apth & blt1aptl and blt1dpth & blt1dptl pointers using the CPU after setting the Coprocessor danger mode (COPCON):

;----- set COPPER = show picture

;    bset.b    #1,COPCON(a6)        ; OLD enable blitter control
    move      #2,COPCON(a6)        ; CORRECT enable blitter control
    move.l    #Copper,COP1LCH(a6)    ; COP1LCH -> custom copperlist

;----- initialize blit 1
    
    move.l    #Sword,d0
    move.w    d0,blt1aptl
    swap    d0
    move.w    d0,blt1apth

    move.l    #Screen+(tileBpl*0),d0
    move.w    d0,blt1dptl
    swap    d0
    move.w    d0,blt1dpth

[Toni Wilen]

Originally Posted by borchen

bset.b #1,COPCON(a6) ; enable blitter control

This sort of works but it also has 2 errors..

[borchen]

This sort of works but it also has 2 errors..

Thanks for pointing that out...but 2 errors in 1 command and it still works?

The COPCON-register apparently is a 1 bit register, so how does one set this?

Should it be:

bset.l #00,COPCON(a6)

?

On how to set individual bits I used the following page: http://mrjester.hapisan.com/04_MC68/...t05/Index.html

[Toni Wilen]

Register is write-only, bset (and friends) are always byte-wide read-modify-write instructions when accessing memory: move #2,COPCON(a6) is the correct way. (or any value that has bit 1 set, other bits don't exist)

btw, why do you need to "trigger" the blitter with CPU? Code can easily become too timing sensitive if both CPU and copper list modifies blitter registers, especially when/if timing gets off enough to cause both to run at the same time.. Result will be undebuggable mess

[sandruzzo]

@Toni

Since you know Amiga very well, I would ask you is it worth to do blitting via copper for a game, or it's just for a demo.

[borchen]

Thanks Toni for pointing me in the right direction about setting the COPCON register. I just thought: "I have to set 1 bit so I have to use the bset command"...silly me.
I changed it to move #2,COPCON(a6) and it works like a charm.

btw, why do you need to "trigger" the blitter with CPU?

I do not 'need' to do it this way, but i'm just playing around with some code and was curious if I could get this to work at all.

It's a 'not because i have to, but because I can' thingy: [ Show youtube player ] (Dutch people will understand this...)

Code can easily become too timing sensitive if both CPU and copper list modifies blitter registers,

In the piece of code I have now only the copper triggers the blitter.

especially when/if timing gets off enough to cause both to run at the same time.. Result will be undebuggable mess

Tell me about it; that's exactly what happened a lot when moving blittersetup-code from the CPU to the copperlist.
That's why I was pretty happy with myself when it finally worked without glitches.

The end-result is exactly the same, but uses hardly any CPU.

There's still a little piece of code in the mainloop I still have to 'migrate' to the blitter:

	move.w	#300,d0			; wait for rasterline 300 = EOFrame
	bsr.w	WaitRaster

;----- barrelshift picture 1px to left using CPU

	lea	Sword,a0
	moveq	#(tileBplS*BPLS)/2-1,d0	; 48 words
.brlsl
	rol.w	#1,(a0)+
	dbf	d0,.brlsl

Now I have to figure out how to barrelshift data with the blitter....something with reading an extra word of data & masking....but that's besides this topic.

[Toni Wilen]

Originally Posted by sandruzzo

Since you know Amiga very well, I would ask you is it worth to do blitting via copper for a game, or it's just for a demo.

IMHO copper list blits can be only faster (=cpu can do stuff at the same time without ever wasting cycles for blitter waits) when there is lots of blits and each blit has at least one idle cycle and blit parameters don't change much (for example only A and D pointer changes, all other registers don't need updating, most of the copper list don't need updating/frame). Also line draws can be faster when using copper. (They have 2 idle cycles/pixel)

[sandruzzo]

Originally Posted by Toni Wilen

IMHO copper list blits can be only faster (=cpu can do stuff at the same time without ever wasting cycles for blitter waits) when there is lots of blits and each blit has at least one idle cycle and blit parameters don't change much (for example only A and D pointer changes, all other registers don't need updating, most of the copper list don't need updating/frame). Also line draws can be faster when using copper. (They have 2 idle cycles/pixel)

So it will be good to do things with copper. But with multiple blitting for a game, when we have a lot of bobs on screens, we could ha a big copperlist, or am I wrong?

[Toni Wilen]

Originally Posted by sandruzzo

So it will be good to do things with copper. But with multiple blitting for a game, when we have a lot of bobs on screens, we could ha a big copperlist, or am I wrong?

Most normal blits (cookie cut or not) don't have any idle cycles. Clear has idle cycles but usually there is only one large clear = no repeated need to wait for the blitter. (just make sure the CPU does something useful during the clear)

I don't think copper list becomes too big, at least as long as as blits share same data (no need to update modulos, bltcon0/1 in copper list).

[sandruzzo]

Originally Posted by Toni Wilen

Most normal blits (cookie cut or not) don't have any idle cycles. Clear has idle cycles but usually there is only one large clear = no repeated need to wait for the blitter. (just make sure the CPU does something useful during the clear)

I don't think copper list becomes too big, at least as long as as blits share same data (no need to update modulos, bltcon0/1 in copper list).

A hel of work! Maybe this tecnique is good for bigger blits, like 3d game

[dissident]

Originally Posted by Toni Wilen

It is most likely caused by slow CPU chip ram (and custom registers) access speed. (Blitter speed is still the exact same). It is "feature" of most accelerators.

What I can’t understand is the fact that running my routines out of FAST memory on a 68060 with the BLTPRI-Bit turned on, the blitter controlled by the copper, needs more time to execute. Yes, I know that most accelerators are slower accessing CHIP-memory than the original 68020 CPU. And yes, the CPU has to clear the picture which is CHIP memory and has to update the copperlist which is also in CHIP memory. But the blitter in this case has full priority over the CPU. To my mind, this should have no effect at all, if I'm not totally wrong.

[Toni Wilen]

Exact same blitter start position in both tests? Exact same other (copper, bitplanes, same fmode etc) DMA channel usage in both tests?

[dissident]

Originally Posted by Toni Wilen

Exact same blitter start position in both tests? Exact same other (copper, bitplanes, same fmode etc) DMA channel usage in both tests?

I tested my routine (linedrawing+filling/bobs+clearing) all done with the blitter/copper and startet the blits always at a certain line at the top of the screen with a copper-wait command. BLTPRI set on 68020 and 68060 for the same routines. FMODE, DMA channel usage all the same. The speed on my different CPUs of the blitter execution is the same. So I was however wrong there Thanks for your hint, Toni.
But apart from this I know that the overclocked 68060/83 Mhz CPU of my friend behaves different. Setting the BLTPRI-bit for my routines freezes this machine. Maybe the whole clock/bus handling is messed up there or incompatible due to the fact of overclocking.

[frank_b]

Hi Toni.

Can you please describe how the arbitration works in blit nice mode? The HRM mentions that the blitter yields for one cycle (slot?) if the CPU is halted for several cycles. What happens if there are idle cycles in the blit? Can the CPU realign to use them? Will the blitter yield if the CPU is blocked by other DMA? I wonder if it would be worthwhile to use blitnice mode if the CPU is doing multiplies or divide instructions.

Will the CPU get cycles if blocked by just the blitter? Do other DMA channels count in this case?