English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 03 July 2020, 21:57   #1
leonard
Registered User
leonard's Avatar
 
Join Date: Apr 2013
Location: paris
Posts: 56
avoid blitter wait

Hi!

I know it's a very touchy subject Let me explain. I know blitter wait is mandatory if you want to run perfectly on all kind of amiga. But let say I'm in a specific context:
a) running on A500
b) the code is located in CHIP memory
c) the blitter is executing AREA mode, with ABCD enabled
d) blitter is runnin in NASTY mode

If a,b,c and d are true, the blitter has just 1 idle cycle at begin of area right? And if the code is located in CHIP memory, having two instructions in between blitter run and next blitter reg write should be enough? Let's imagine that kind of code:

move.w d0,(a0) ; run blitter by writing to $dff058
move.l a1,d0
add.w (a2)+,d0 ; read data ( a2 could be either CHIP or FAST ram )
move.w dn,(a1) ; --> write into another blitter register, without waiting

it works on WinUAE (cycle exact, etc), but want your option about that. Is it safe to NOT wait blitter i this situation?

Last edited by leonard; 03 July 2020 at 22:06.
leonard is offline  
Old 03 July 2020, 22:11   #2
jotd
This cat is no more
jotd's Avatar
 
Join Date: Dec 2004
Location: FRANCE
Age: 48
Posts: 4,257
nasty mode means that it has priority over cpu so it should be okay. I've seen that done in games like Danger Freak.
jotd is offline  
Old 04 July 2020, 00:08   #3
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 50
Posts: 2,729
Works for the described setup but.. you're calling for trouble in fast Amigas.
If you can, use blitter wait
ross is offline  
Old 04 July 2020, 00:59   #4
leonard
Registered User
leonard's Avatar
 
Join Date: Apr 2013
Location: paris
Posts: 56
Quote:
Originally Posted by ross View Post
Works for the described setup but.. you're calling for trouble in fast Amigas.
If you can, use blitter wait
the idea is to have the fastest possible code on A500 ( the slowest amiga ). All other amiga will use another code path, with a blitter wait. ( I want to keep 50hz on A500 )
leonard is offline  
Old 04 July 2020, 01:18   #5
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 2,080
This might sound a bit counter-intuitive, but I've found that the fastest possible way of blitting on the A500 (or indeed any Amiga) is to only ever run the Blitter in nasty mode if you have absolutely no other choice but to wait for the Blitter to complete it's task. Running the CPU for non-waiting tasks while blitting is almost always faster than using Blitter nasty. The trick is, naturally, to find useful work for the CPU to do while blitting.

An easy way I've found to do this is to use a Blitter Wait macro that dynamically switches Blitter Nasty on and off. This allows me to run the setup code of the next blit (minus the actual setting of the Blitter registers) while the Blitter is running the previous blit. You could also opt to use the Copper to set up the Blitter (and deal with Blitter waits) instead, though that can get tricky when incorporating Copper effects as well.

I've not had much positive results using Blitter interrupts, they generally have too much overhead to be a net performance gain.
roondar is offline  
Old 04 July 2020, 01:29   #6
leonard
Registered User
leonard's Avatar
 
Join Date: Apr 2013
Location: paris
Posts: 56
Quote:
Originally Posted by roondar View Post
I've not had much positive results using Blitter interrupts, they generally have too much overhead to be a net performance gain.
Agree, but this is very special code. I can't use copper-driven blitter queue for some reason. So I'm using nasty mode with CPU very fast blitter setup for all A+B+C+D operations. But, I have some blitter clear operations, plenty of blitter idle cycles. The CPU could run during these blitter clears and is doing some other work. Blitter interrupts is the only way I have in this case ( and I have few of them per vblank, about 10 )
leonard is offline  
Old 04 July 2020, 08:42   #7
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 45
Posts: 23,970
It should be safe, enough time even when including idle cycles and prefetch. (It probably is good idea to have replacement "good" code if CPU is not 68000 or code is running in fast RAM)

This is not a problem in this situation but it can cause random problems if timing is tight enough: after writing to BLTSIZE, there is always 2 idle cycles before blitter normal operation starts. Normally CPU can only use one of them but if some other higher priority DMA channel steals the slot meant for second idle cycle, suddenly CPU has chance to use second slot too. In worst case this happens very rarely but can be just long enough delay to break the code.

I have probably said this every time when it it about blitter interrupts but I think it is worth repeating: interrupt startup and exit (RTE) takes almost 70 cycles on 68000 and almost all of the cycles are CPU memory accesses. Lots of blitter interrupts: lots of time wasted doing "nothing".
Toni Wilen is online now  
Old 04 July 2020, 10:25   #8
leonard
Registered User
leonard's Avatar
 
Join Date: Apr 2013
Location: paris
Posts: 56
Quote:
Originally Posted by Toni Wilen View Post
This is not a problem in this situation but it can cause random problems if timing is tight enough: after writing to BLTSIZE, there is always 2 idle cycles before blitter normal operation starts. Normally CPU can only use one of them but if some other higher priority DMA channel steals the slot meant for second idle cycle, suddenly CPU has chance to use second slot too. In worst case this happens very rarely but can be just long enough delay to break the code.
that's why I forced the code to be in CHIP memory. It means just one NOPs instructions following the move.w dn,(an) that run the blitter command should be enough? ( 1 nop is 2 memory cycles, 4 cpu cycles )

Quote:
Originally Posted by Toni Wilen View Post
I have probably said this every time when it it about blitter interrupts but I think it is worth repeating: interrupt startup and exit (RTE) takes almost 70 cycles on 68000 and almost all of the cycles are CPU memory accesses. Lots of blitter interrupts: lots of time wasted doing "nothing".
I agree but do you think there is a better choice in my very specific case: I'm running some blitter "clear" commands ( D destination used only ). I don't know the size of each clear in advance, and I have about 6 to 14 of them. I need to also run specific CPU code in paralell. ( and obviously can't use the copper to drive the blitter in my case). So having a short IRQ blitter queue, just for these few blt clear commands is my only option, right?
leonard is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
How to avoid flickering when using blitter directly? jotd Coders. Asm / Hardware 22 24 December 2019 08:17
Immediate Blitter & Wait for Blitter... volvo_0ne support.WinUAE 29 10 December 2018 17:56
"Wait for Blitter"... DamienD support.WinUAE 3 01 April 2017 21:09
Wait() mritter0 Coders. C/C++ 2 17 May 2014 19:14
Blitter busy flag with blitter DMA off? NorthWay Coders. Asm / Hardware 9 23 February 2014 21:05

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 20:12.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.
Page generated in 0.07209 seconds with 13 queries