English Amiga Board


Go Back   English Amiga Board > Coders > Coders. General

 
 
Thread Tools
Old 08 August 2019, 13:37   #21
deimos
Registered User

 
Join Date: Jul 2018
Location: Londonish / UK
Posts: 235
Quote:
Originally Posted by zero View Post
Obviously you must pipeline as best you can, rather than just start the blitter than then busy wait. If you do it right it's going to be a lot more efficient than entering and exiting an interrupt.
So, still build a queue, but add a macro at strategic places to test whether the blitter is available and process the head of the queue if it is?
deimos is offline  
Old 09 August 2019, 10:18   #22
zero
Registered User

 
Join Date: Jun 2016
Location: UK
Posts: 334
Quote:
Originally Posted by deimos View Post
So, still build a queue, but add a macro at strategic places to test whether the blitter is available and process the head of the queue if it is?
That's not a bad strategy. Obviously it depends what system you are targeting, because that will determine how much work you can do between blits.

For example, if you are writing a game for the A500 you can try to interleave blits and enemy movement. If you time it right by the time you have figured out where the enemy needs to go and calculated all the values to poke into the blitter, the blitter will be finished with the previous one. You still need to poll in case you are running on a faster A1200, but at least you avoided wasting all those cycles on an interrupt.

Another down-side of interrupts is that it can be tricky to generate the queue as the blits are taking place. Imagine the blitter finishes and the interrupt sees the end of the queue so stops, but then after that another item is added to the queue. You need to either avoid that, or detect it and re-start the blitter.

The other issue with interrupts is that you have to make sure updates to your queue are atomic. The interrupt could trigger half way through an update to the queue, so there is a little bit of overhead to manage that. I'd avoid pausing interrupts during the update and just use some kind of counter that can be written atomically.

One other way to do it is with a copper list that is effectively the blit queue. You really need to be one frame behind for that to work though, but maybe that doesn't matter for things like enemy bobs.
zero is offline  
Old 20 August 2019, 22:38   #23
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,288
On interrupts, does anyone know what the minimum interrupt latency is for a chipmemory only A1200/68020? On the A500/68000 it's around 44 cycles and I was wondering what the figure is for the A1200/68020.

(What I mean by latency here is the minimum time between an interrupt trigger and the start of the actual interrupt handler - not the time for running a minimal handler and properly returning from it).

I've often wondered if the A1200 might do better with a blitter queue than the A500 and the above is part of that puzzle.

Tried several forms of them on the A500 and the only one that ever was worth the effort was running clear blits on a Dual Playfield screen. That actually gained me a performance benefit. Standard queues though (whether the queue merely copied over data into the Blitter registers or actually set up the blits), not so much. Never seemed to be faster - though they were very convenient to use once I had them set up.
roondar is offline  
Old 21 August 2019, 00:33   #24
a/b
Registered User

 
Join Date: Jun 2016
Location: europe
Posts: 112
best/cache/worst, and (read/prefetch/write cycles):
Interrupt (I-Stack) 26(2/0/4) 26(2/0/4) 33(2/2/4)
Interrupt (M-Stack) 41(2/0/8) 41(2/0/8) 48(2/2/8)
a/b is offline  
Old 21 August 2019, 15:44   #25
Photon
Moderator

Photon's Avatar
 
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 4,765
Quote:
Originally Posted by zero View Post
The issue is the 68000, it's just not designed for fast interrupt response. Some other CPUs, especially 8 bit ones, are much better.
Theoretically, you could get the overhead down by quite a bit by only using, say, 3 registers in the interrupt code. This might make the code slower and bigger, while expectations stay the same for 68000 and are higher than for, 8-bit CPUs.
Photon is offline  
Old 21 August 2019, 16:22   #26
DanScott
Lemon. / Core Design

DanScott's Avatar
 
Join Date: Mar 2016
Location: Sunny Bournemouth, UK
Posts: 433
Quote:
Originally Posted by zero View Post
Another down-side of interrupts is that it can be tricky to generate the queue as the blits are taking place. Imagine the blitter finishes and the interrupt sees the end of the queue so stops, but then after that another item is added to the queue. You need to either avoid that, or detect it and re-start the blitter.

The other issue with interrupts is that you have to make sure updates to your queue are atomic. The interrupt could trigger half way through an update to the queue, so there is a little bit of overhead to manage that. I'd avoid pausing interrupts during the update and just use some kind of counter that can be written atomically.
This is why you double buffer your list...
DanScott is offline  
Old 21 August 2019, 18:20   #27
deimos
Registered User

 
Join Date: Jul 2018
Location: Londonish / UK
Posts: 235
Quote:
Originally Posted by DanScott View Post
This is why you double buffer your list...
But wouldn't that mean not being able to start blitting a list until you've moved onto building the other one?
deimos is offline  
Old 22 August 2019, 09:56   #28
zero
Registered User

 
Join Date: Jun 2016
Location: UK
Posts: 334
Quote:
Originally Posted by deimos View Post
But wouldn't that mean not being able to start blitting a list until you've moved onto building the other one?
Yes, you add additional latency to screen updates. 20ms per frame. It's not a big deal for the most part, 20ms is not really noticeable.
zero is offline  
Old 22 August 2019, 10:29   #29
deimos
Registered User

 
Join Date: Jul 2018
Location: Londonish / UK
Posts: 235
Quote:
Originally Posted by zero View Post
Yes, you add additional latency to screen updates. 20ms per frame. It's not a big deal for the most part, 20ms is not really noticeable.
In my case, 3D graphics and a frame rate of around 10fps or less, the latency would be the time to build the entire queue, so maybe even 100ms or more. I can see scope to do smaller queues, maybe one per object, which would massively reduce that, but a single queue that could be consumed at the same time it was added to would be most convenient. But I'm not sure if it's possible.
deimos 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
Please help me!! Blitter pain! h0ffman Coders. Asm / Hardware 5 15 June 2013 18:59
Blitter using the copper... h0ffman Coders. Asm / Hardware 9 23 February 2012 08:25
Did Starglider use the blitter? mc6809e Retrogaming General Discussion 8 04 February 2012 15:19
Filling with the blitter... Lonewolf10 Coders. Tutorials 7 13 September 2011 14:30
Blitter nasty or not? JackAsser Coders. Tutorials 5 28 March 2010 22:45

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 02:35.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Page generated in 0.07779 seconds with 15 queries