WHDLoad blitter speed tests - needs you!

[Codetapper]

I wonder if a slightly different approach could work. I am no macro expert but say a game like R-Type 2 that really slows down in places, could you pass the blitsize value to a macro that decides what blitter code to put in?

eg. move.w #$2501,$dff058
bsr _BlitWait

If you could tell the program somehow that it's a blit of size $2501, then with some bit-manipulation you could work out it's either a small, medium or large blit, and then branch partway into the blitter wait routine so there are 2/3/4 tst.b's left to do if those are optimal numbers? Effectively you would want the following to be put in the patch:

            move.w #$2501,$dff058
            bsr _BlitWait2         ;BLITWAIT $2501 somehow patches this in
            ...

_BlitWait4  tst.b
_BlitWait3  tst.b
_BlitWait2  tst.b
            tst.b
.1          btst #6,$dff002
            bne .1
            rts

Maybe it's impossible, but could something like that work? Is there any analysis of the type of blit (ie. a non cookie cut D=A type) to check if games that do not cookie cut will slow down?

Also isn't 16x16 the most common size blit in most Amiga games? If that is the case, I would be wary about ever adding in blitter wait code that will slow it down.

BTW this is a very interesting thread!

[girv]

Interesting idea about the macro automatically setting up the blitwait loop, I'll have to have a think about that Small point: probably just a typo in your code, but the tst.b's need to be inside the loop so as to keep the CPU away from the custom registers, ie: the "bne" needs to branch to one of the _BlitWaitX labels instead.

There's no analysis of different types of blit, we'd need another batch of tests to gather results. Common ones to test would be D=0 and D=A - any others you can think of? DMA wouldnt be so saturated with these blits so I'd hazard a guess that they wouldn't be slowed down as much as a cookiecut.

16x16 may well be the most common size of blit though I guess every game is different

Something I've just realised is that the tests only blit one plane, so 16x16 is working with 1x16 words of image data (+mask etc.), whereas a game might (likely?) be blitting interleaved so really be dealing with 1x16*depth data words. 16x16 interleaved in 16 colours would be 64 words, or the equivalent of the 32x32 blit in the current tests.

Could we come up with a set of likely sizes to test, taking interleaved blits into consideration ? Perhaps we should think of the blit sizes in terms of data words moved rather than pixel dimensions.

I think we also need to get results for a smoother, more regular range of blit sizes, so we can better determine where each blitwait loop style becomes most efficient. Perhaps theres even a formula lurking in the data to calculate the best number of waits for a given blitsize Now that would be a cool macro to have

[Codetapper]

Well I think there are only 3 blits you need to worry about. A clear loop where D=0, a basic copy for background tiles in games D=A, and the cookie cut. Perhaps one more for good measure involving D=AB in case there is a mask one for too. So 4 should be a pretty good test.

As for the test sizes, I would still imagine 16x16 for a normal tile and 16x16x4/5 for interleaved blits in 16/32 colours would be the most common blits for all background stuff, and then any player objects - well they could be almost anything I guess.

There will always be some exceptions, from memory in the AF interview regarding First Samurai, they chose to use something like 32x24 sized blocks for the maps.

And regarding that code I was just doing an example of course! Didn't actually expect it to work etc!

[Wepl]

Originally Posted by Codetapper

If you could tell the program somehow that it's a blit of size $2501, then with some bit-manipulation you could work out it's either a small, medium or large blit, and then branch partway into the blitter wait routine so there are 2/3/4 tst.b's left to do if those are optimal numbers?

for best performance the blitwait should be located before the blit operation. this will make it hard to get the blitsize of the previous blit.

[Dwyloc]

Could someone repost WHDLoad BlitterSpeed.slave to the zone as I would like to see how my Blizzard1240 040/40 compare to the other 040 cards people have already run the test on.