Blitter interrupt during VERTB interrupt

[ross]

Originally Posted by dissident

Just check my copper-demo

Yeah, I know your demo
Absolutely a copper usage masterpiece (is the AGA counterpart of Angels Copper Master).

Thanks for the detailed response.

[Emufr3ak]

Originally Posted by Toni Wilen

There is not much gained by running CPU and blitter simultaneously if blitter cycle sequence does not have any idle cycles (which are always available for the CPU. Don't waste them!). In no-idle-cycle case CPU is immediately (technically after 2 or 3 cycles) blocked until blitter finishes.

IMHO it is practically only useful when clearing (every other blitter cycle is idle cycle) or D=A filling (every 3rd cycle is idle cycle). All other common channel combinations don't have idle cycles.

Only exception is if code is running in real fast ram. (or blitter nasty not set but why would you do that in a demo or game?)

Is this also true for Amiga 1200? Or does the faster CPU make a difference there?

[Kalms]

Originally Posted by phx

I would really prefer when the game engine, which renders the frames, runs in an interrupt, triggered by VERTB. This way I have a kind of multitasking and let the "main program" do tasks which are not VERTB-synced, like reading data from the disk.

Side note, I implemented a thread switcher with the intent of supporting a small number of parallel threads ("track loading from disc", "MFM decoding", "decompression", "realtime graphics") and push as much logic as possible out of the interrupt handlers. Source code here.

The homemade threading solution was reasonably efficient for all types of threading transitions except for when an interrupt wakes up another thread (timings at the bottom of the page). It was difficult to write and mistakes when using it results in hard-to-debug deadlocks... so all in all I cannot really recommend using it. Was good to get an understanding of what sort of performance can be expected from a thread switcher.

It is possible to speed up the context switches triggered within interrupts further, but that involves rather intricate engineering.

[ross]

Originally Posted by Kalms

Side note, I implemented a thread switcher with the intent of supporting a small number of parallel threads ("track loading from disc", "MFM decoding", "decompression", "realtime graphics") and push as much logic as possible out of the interrupt handlers.
..
Was good to get an understanding of what sort of performance can be expected from a thread switcher.

This is exactly what i'm talking about!
When I have time I will inspect your code to see if I can use it for my purposes
(logically I will publish any valuable variation).

EDIT:

It is possible to speed up the context switches triggered within interrupts further, but that involves rather intricate engineering.

Yes, my idea is to reduce context register saving, using a "maximum" of numbered tasks, everyone working in different IRQ level (plus user mode).
IRQ levels forced by a master (VBL?) that steer other sub-levels.

Thanks!

[ross]

Draft:

EXTER	Level 6 External interrupt (free from control, music routine, timed fast execution)
DSKSYN	Level 5 Disk Sync value found (catched, support to disk routine for read error)
AUDx	Level 4 Audio Interrupt (free, unused) 
VERTB	Level 3 Vertical Blank Interrupt (master, some scattered MFM decoding)
PORTS	Level 2 CIA Interrupt (double: forced, user code, high priority, semaphored; CIA timed routine)
SOFT	Level 1 Software Interrupt (forced, user code, normal priority, depack routine)
USER	Level 0 User Mode (user code, low priority, pre-calc, synthetic audio sample generation)

Written in hurry

[dissident]

Originally Posted by Toni Wilen

IMHO it is practically only useful when clearing (every other blitter cycle is idle cycle) or D=A filling (every 3rd cycle is idle cycle). All other common channel combinations don't have idle cycles.

I guess you refer to the blitter cycle sequence table 6-2 of the HRM http://amigadev.elowar.com/read/ADCD.../node0127.html

Right?

[Toni Wilen]

Originally Posted by dissident

I guess you refer to the blitter cycle sequence table 6-2 of the HRM http://amigadev.elowar.com/read/ADCD.../node0127.html

Yes and no. It is correct in non-fill cases but it does not mention that some fill channel combinations add extra idle cycle (for example commonly used D=A takes in fill mode 3 cycles, A read, one idle and D write)

Interestingly enough first HRM revision had more complete table and included this special case. Later editions removed it.

[dissident]

Originally Posted by ross

Yeah, I know your demo
Absolutely a copper usage masterpiece (is the AGA counterpart of Angels Copper Master).

Thanks for the detailed response.

It was a pleasure to me. And thanks for the praise. Yes, I remember that in a different thread you already mentioned you know my copper demo. I'm getting old.

[dissident]

Originally Posted by ross

Yes, my idea is to reduce context register saving, using a "maximum" of numbered tasks, everyone working in different IRQ level (plus user mode).
IRQ levels forced by a master (VBL?) that steer other sub-levels.

Just like the OS where the VBI steers the system multitasking. Sounds good.

[dissident]

Originally Posted by Toni Wilen

Yes and no. It is correct in non-fill cases but it does not mention that some fill channel combinations add extra idle cycle (for example commonly used D=A takes in fill mode 3 cycles, A read, one idle and D write)

Interestingly enough first HRM revision had more complete table and included this special case. Later editions removed it.

I guess I found this first HRM revision here https://archive.org/stream/Amiga_Har.../n189/mode/2up but to me this table is not extended or different.

[dissident]

Originally Posted by ross

Draft:

EXTER    Level 6 External interrupt (free from control, music routine, timed fast execution)
DSKSYN    Level 5 Disk Sync value found (catched, support to disk routine for read error)
AUDx    Level 4 Audio Interrupt (free, unused) 
VERTB    Level 3 Vertical Blank Interrupt (master, some scattered MFM decoding)
PORTS    Level 2 CIA Interrupt (double: forced, user code, high priority, semaphored; CIA timed routine)
SOFT    Level 1 Software Interrupt (forced, user code, normal priority, depack routine)
USER    Level 0 User Mode (user code, low priority, pre-calc, synthetic audio sample generation)

Written in hurry

Or more detailed here: http://amigadev.elowar.com/read/ADCD.../node016F.html

[Toni Wilen]

Originally Posted by dissident

I guess I found this first HRM revision here https://archive.org/stream/Amiga_Har.../n189/mode/2up but to me this table is not extended or different.

It is not old enough. This one: http://www.bombjack.org/amiga/amiga-books.htm (276 page "Amiga Hardware Manual")

[dissident]

Originally Posted by Toni Wilen

It is not old enough. This one: http://www.bombjack.org/amiga/amiga-books.htm (276 page "Amiga Hardware Manual")

Not quite. I've checked it. The "Blitter Cycle Sequence"-table (and some other chapters) are missing in the original "Amiga Hardware Manual" and can be found in the "Amiga Hardware Manual Errata", same link as mentioned above.
Anyway a very interesting site with lots of good amiga books for downloading. Many thanks, Toni.

[Jobbo]

Hi

I'm resurrecting this thread because I'm looking to do something alone similar lines.

I have a background thread that's busy doing work as fast as possible.
I also have a frame update thread called from the vertb handler.
The copper is pretty busy so I don't want to use that for blits.
What I'd like is for the frame update to start a queue of blits, which will be continued by a handler each time the blitter finishes, leaving the frame update to do it's thing.

Anyway the suggested method seems to be to put the frame update inside a soft interrupt handler so this frees up the level-3 handler for repondsing to the blitter interrupts.

My main question is if this seems like the most reasonable approach, and if that has been successful for others? I'll certainly give it a try but wanted to hear if anyone run into trouble?

Thanks

[Antiriad_UK]

Originally Posted by Jobbo

Hi

I'm resurrecting this thread because I'm looking to do something alone similar lines.

I have a background thread that's busy doing work as fast as possible.
I also have a frame update thread called from the vertb handler.
The copper is pretty busy so I don't want to use that for blits.
What I'd like is for the frame update to start a queue of blits, which will be continued by a handler each time the blitter finishes, leaving the frame update to do it's thing.

Anyway the suggested method seems to be to put the frame update inside a soft interrupt handler so this frees up the level-3 handler for repondsing to the blitter interrupts.

My main question is if this seems like the most reasonable approach, and if that has been successful for others? I'll certainly give it a try but wanted to hear if anyone run into trouble?

Thanks

There's a thread somewhere on here where I did 3 different approaches for blitting bobs (copper, interrupt, "normal"). And that used a soft int for the main work and blit queue interrupt on lev 3. Worked fine. I thought I'd put the code on github but can't find it. You're welcome to it if I dig it out.

My current framework is mostly lev1 soft int and the copper triggering the lev 1 so that if I ever want to add some blit queue stuff I don't have to redesign.

[Jobbo]

Thanks, I mostly wanted to hear if anyone ran into problems or had better suggestions.

I successfully got my own version working.

I moved the frame update loop into a level 1 handler which I trigger from the level 3 handler when there's a vertb interrupt. My level 3 handler then also responds to blit interrupts.

This means my frame update loop can queue up blits and keep going. Meanwhile in the background I can do whatever processing I need that isn't part of the frame update and the copper can also do whatever I want without the complexity of interleaving blits.

For my particular case this is exactly what I need. The level 1 set up seems to be the most straight forward and stable solution for getting there.

I've seen some other suggestions, such as handling nested interrupts but that didn't sound nearly as simple.

I'm not really sure if I'm missing some downside with this level 1 approach, other than it's tricky to get it working at first! I spent quite a while confused by deadlocks and/or run away blits.

[defor]

Out of curiosity. Is there any need to have the main loop in the supervisor mode (lev1 interrupt)? Isn't it unnecessary to spend 20+ CPU cycles just to go inside supervisor and (another cycles) to go back? I get the concept of Blitter job queue and hence the lev3 interrupt handler (I guess it's mainly usable for large blits only), but the main loop? Although I guess some interrupt handler (vblank or soft-int triggered by Copper) is always handy if one needs to count frames.

[Jobbo]

My render update is in the interrupt handler because the main user mode code needs to churn through other work that isn't easily divided up each frame.

Currently I'm triggering a soft interrupt from the vertb interrupt handler, which is double the cost.

I hadn't considered triggering the soft interrupt using the copper, will have to check if that's possible?

[defor]

Originally Posted by Jobbo

I hadn't considered triggering the soft interrupt using the copper, will have to check if that's possible?

It's quite common.