Hooking into vblank irq for draw?

[bogglez]

Recently I've been looking into the assembly programming of KOS and read more hardware documentation, and was curious about the vblank interrupt.

In a normal game loop, we do something like this:

Code: Select all

while(1) {
  update();
  draw();
  swap(); // waits for vblank
}

So the CPU is blocked, although we could already perform the next update() or other busy-work.
Would it make sense to instead use draw() as a vblank interrupt handler, in order to get asynchronous behavior without threads which have their own overhead?

[BlueCrab]

There's actually stuff in KOS to schedule things to happen on vblank: link.

Just remember that these will run in the IRQ context of the vbl interrupt (i.e, interrupts disabled), so you shouldn't be doing lots of stuff in them.

[bogglez]

Yeah, that function is what I was referring to. Rendering does take a considerable amount of time of the frame (but not more than 1/60th or 1/30th of a second). Why would it be a bad idea to do things there? Would 1/30s in a worst case mess with the disc, audio, etc. components of KOS?
I assume rendering would be faster because the game state would be updated during the time that we usually wait for the vblank. The interrupt handler would basically just copy the TA render command list to the PVR or perform minor work in order to create such a render command list and copy it over.

[BlueCrab]

It would be a bad idea to do things there because IRQs are disabled during the time when any interrupt is being serviced in KOS (KOS doesn't allow nested interrupts). Thus, you will screw up a lot of things by doing anything time intensive in that function. Timing, network communications, even parts of video rendering can rely on interrupts.

Plus, anything that would potentially cause you to sleep (memory allocation, for instance) will either not work properly or will hang the system entirely. This is since it'll be waiting on a lock that it will never be able to acquire unless another thread gets swapped in -- which can't happen until a timer interrupt -- which can't happen while IRQs are disabled.