Raspberry Pi double buffer support for SDL

From other threads it seems that to get the best results from a double buffered screen on a Raspberry Pi, the wait for vsync needs to be after the bank switch instead of before.
i.e. in SDL1.2 it currently does

 _kernel_swi_regs regs;
   regs.r[0] = 19;

   FULLSCREEN_SetDisplayBank(this->hidden->current_bank);
   this->hidden->current_bank ^= 1;
   FULLSCREEN_SetWriteBank(this->hidden->current_bank);
   surface->pixels = this->hidden->bank[this->hidden->current_bank];

   /* Wait for Vsync */
   _kernel_swi(OS_Byte, &regs, &regs);

Whereas for the Raspberry Pi it should do:

 _kernel_swi_regs regs;
   regs.r[0] = 19;

   /* Wait for Vsync */
   _kernel_swi(OS_Byte, &regs, &regs);

   FULLSCREEN_SetDisplayBank(this->hidden->current_bank);
   this->hidden->current_bank ^= 1;
   FULLSCREEN_SetWriteBank(this->hidden->current_bank);
   surface->pixels = this->hidden->bank[this->hidden->current_bank];

This leads me to three questions:
1. Is my understanding above correct?
2. How do I detect I’m on the Pi so I know to modify the order?
3. What happens with the other new machines?

IIRC (bearing in mind it was probably 2014 when I last looked at this), providing you can issue your bank switch request before the magic half-frame deadline, the request will then be acted on by the GPU during the next VSync. If you wait for VSync and then do the bank switch then you’ll end up with one frame of lag; the VSync interrupt RISC OS receives is too late for any bank switches (and palette switches?) to be acted on by the GPU (even if the message buffering in BCMVideo was removed).

I believe all OMAP/TI machines have a 1-frame delay as well (again, due to the VSync interrupt occurring after the hardware has decided what frame to display next), and I’ve had inconsistent behaviour with the Iyonix as well, so generally I recommend that people use triple buffering instead of double buffering.

I did write a program which would visible display the screen bank & palette switch delay of the system; I’ll try and remember to upload a copy when I get home, since it might be useful to people.

http://www.phlamethrower.co.uk/riscos/banktest.zip

It wants to use a minimum of six screen banks @ 640×480, so for the Pi you’ll have to set max_framebuffer_height to at least 1440 in config.txt (the firmware effectively limits the number of screen banks to max_framebuffer_height*2/mode_height).

I might spend some time on it tomorrow, polishing it up so that the frame lag is shown in columns (similar to the palette lag) so that it’s easier to see any temporary glitches.

Thanks Jeffrey,

It sounds like my understanding is wrong. I’d be better off leaving the code as it is for double buffering as the GPU will switch the banks on the vsync and by waiting afterwards I can be sure the banks are changed before I start drawing again.

Triple buffering does sound like the way to go in the future, but for now I just wanted to see if the library needs anything for double buffering for now.

Somewhat off topic Alan, but do you have any interest in genealogy?
I have a connection to some Buckleys, probably not your line but stranger things…

Steve,

I’ve not really looked in to genealogy myself, but I’ve an aunt that has looked into a bit of the family history. Feel free to email me with a few details and I can ask her.