Double Buffering, FB_WaitVBL, and FBCON

Adam_Meyerowitz · December 8, 2001, 7:35pm

Hello,

I was wondering what the state of double buffering was for FBCON. Looking
through the code in SDL_fbvideo.c I see this:

static void FB_WaitVBL(_THIS)
{
#ifdef FBIOWAITRETRACE /* Heheh, this didn’t make it into the
main kernel */
ioctl(console_fd, FBIOWAITRETRACE, 0);
#endif
return;
}

I can’t find the FBIOWAITRETRACE in any of the linux system header files so I
have to assume that the comment…Hehe, this didn’t make it into the
main kernel, is correct. So am I correct in concluding that double buffering
does not work when using FBCON since the function just returns if
FBIOWAITRETRACE is not defined. If that is the case, is there any other way
to achieve smooth animation?

Thanks in advance,
Adam Meyerowitz

M_R_Brown · December 8, 2001, 8:29pm

Adam Meyerowitz on Sat, Dec 08, 2001:

I can’t find the FBIOWAITRETRACE in any of the linux system header files so I
have to assume that the comment…Hehe, this didn’t make it into the
main kernel, is correct. So am I correct in concluding that double buffering
does not work when using FBCON since the function just returns if
FBIOWAITRETRACE is not defined. If that is the case, is there any other way
to achieve smooth animation?

http://www.libsdl.org/pipermail/sdl/1999-December/023002.html

Found by searching for FBIOWAITRETRACE in Google.

M. R.
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20011208/2647141b/attachment.pgp

M_R_Brown · December 8, 2001, 8:57pm

M. R. Brown <@M_R_Brown> on Sat, Dec 08, 2001:

Adam Meyerowitz on Sat, Dec 08, 2001:

I can’t find the FBIOWAITRETRACE in any of the linux system header files so I
have to assume that the comment…Hehe, this didn’t make it into the
main kernel, is correct. So am I correct in concluding that double buffering
does not work when using FBCON since the function just returns if
FBIOWAITRETRACE is not defined. If that is the case, is there any other way
to achieve smooth animation?

One more thing … why do you think this prevents you from achieving smooth
animation? Also in SDL_fbvideo.c you’ll find (in FB_FlipHWSurface()) that
SDL does do surface flipping (hardware is implied if the underlying fb
driver supports it) - why do you think it doesn’t work?

M. R.
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20011208/83cc20df/attachment.pgp

Adam_Meyerowitz · December 8, 2001, 9:07pm

Yes, but let’s take a look at FB_FlipHWSurface:

static int FB_FlipHWSurface(_THIS, SDL_Surface surface)
{
/ Wait for vertical retrace and then flip display /
cache_vinfo.yoffset = flip_pagesurface->h;
wait_vbl(this);
if ( ioctl(console_fd, FBIOPAN_DISPLAY, &cache_vinfo) < 0 ) {
SDL_SetError(“ioctl(FBIOPAN_DISPLAY) failed”);
return(-1);
}
flip_page = !flip_page;

surface->pixels = flip_address[flip_page];
return(0);

}

Notice that in that function wait_vbl(this) is called. I believe that
wait_vbl() will eventually call FB_WaitVBL() and FB_WaitVBL() just returns if
FBIOWAITRETRACE is not defined. So I think we are back at the same spot.

However, I am completely new at SDL even though a while back (probably a good
2 years ago) I did contribute some small code changes to the project. So I
can be completely off base.

So in your opinion, if there is no way to sync to the vertical retrace how
can smooth animation be achieved? I open to any and all suggestions.

I was thinking of using RTLinux by first polling for the retrace and then
setting a timer to be called. Once the timer is called I can check if indeed
the vga is in retrace and then signal the usermode thread to update the
display. I prefer not to go this route but if that’s what I have to do then
so be it.

Regards,
AdamOn Saturday 08 December 2001 11:56 pm, you wrote:

M. R. Brown <mrbrown at 0xd6.org> on Sat, Dec 08, 2001:

Adam Meyerowitz on Sat, Dec 08, 2001:

I can’t find the FBIOWAITRETRACE in any of the linux system header
files so I have to assume that the comment…Hehe, this didn’t
make it into the main kernel, is correct. So am I correct in
concluding that double buffering does not work when using FBCON since
the function just returns if FBIOWAITRETRACE is not defined. If that
is the case, is there any other way to achieve smooth animation?

One more thing … why do you think this prevents you from achieving smooth
animation? Also in SDL_fbvideo.c you’ll find (in FB_FlipHWSurface()) that
SDL does do surface flipping (hardware is implied if the underlying fb
driver supports it) - why do you think it doesn’t work?

M_R_Brown · December 8, 2001, 9:17pm

Adam Meyerowitz on Sun, Dec 09, 2001:

Yes, but let’s take a look at FB_FlipHWSurface:

static int FB_FlipHWSurface(_THIS, SDL_Surface surface)
{
/ Wait for vertical retrace and then flip display /
cache_vinfo.yoffset = flip_pagesurface->h;
wait_vbl(this);
if ( ioctl(console_fd, FBIOPAN_DISPLAY, &cache_vinfo) < 0 ) {
SDL_SetError(“ioctl(FBIOPAN_DISPLAY) failed”);
return(-1);
}
flip_page = !flip_page;

surface->pixels = flip_address[flip_page];
return(0);
}

Notice that in that function wait_vbl(this) is called. I believe that
wait_vbl() will eventually call FB_WaitVBL() and FB_WaitVBL() just returns if
FBIOWAITRETRACE is not defined. So I think we are back at the same spot.

wait_vbl() will only fall back on FB_WaitVBL() if the framebuffer isn’t
Matrox, Riva, or 3DFx based. And even if you have an unsupported
HW-accelerated framebuffer and wait_vbl() is a nop - so what? That doesn’t
necessarily mean you can’t get smooth animation. Get out of the DOS mode
of thinking. Vertical retrace is definitely a good thing to have, but it
isn’t guaranteed on every platform.

So in your opinion, if there is no way to sync to the vertical retrace how
can smooth animation be achieved? I open to any and all suggestions.

Do it the same way that everyone else who doesn’t rely on vertical retrace
does it. Search the list archives for more than enough info.

I was thinking of using RTLinux by first polling for the retrace and then
setting a timer to be called. Once the timer is called I can check if indeed
the vga is in retrace and then signal the usermode thread to update the
display. I prefer not to go this route but if that’s what I have to do then
so be it.

Overkill … non-portable … RTLinux sucks … :).

M. R.
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20011208/b1403247/attachment.pgp

Adam_Meyerowitz · December 8, 2001, 9:26pm

wait_vbl() will only fall back on FB_WaitVBL() if the framebuffer isn’t
Matrox, Riva, or 3DFx based. And even if you have an unsupported
HW-accelerated framebuffer and wait_vbl() is a nop - so what? That doesn’t
necessarily mean you can’t get smooth animation. Get out of the DOS mode
of thinking. Vertical retrace is definitely a good thing to have, but it
isn’t guaranteed on every platform.

I should have mentioned that i’m using the standard VESA frame buffer.

So in your opinion, if there is no way to sync to the vertical retrace
how can smooth animation be achieved? I open to any and all suggestions.

Do it the same way that everyone else who doesn’t rely on vertical retrace
does it. Search the list archives for more than enough info.

Will do but why don’t you humor me with a couple of ways.

I was thinking of using RTLinux by first polling for the retrace and then
setting a timer to be called. Once the timer is called I can check if
indeed the vga is in retrace and then signal the usermode thread to
update the display. I prefer not to go this route but if that’s what I
have to do then so be it.

Overkill … non-portable … RTLinux sucks … :).

Well, I’d have to disagree but that’s not really relevant here. I’ve used it
and it does what it claims.

Regards,
Adam

David_Olofson · December 11, 2001, 9:11am

[…]

wait_vbl() will only fall back on FB_WaitVBL() if the framebuffer isn’t
Matrox, Riva, or 3DFx based. And even if you have an unsupported
HW-accelerated framebuffer and wait_vbl() is a nop - so what? That
doesn’t necessarily mean you can’t get smooth animation.

Right - provided the video card does retrace sync’ed page flips (pretty
much guaranteed if it does h/w page flipping at all) and there is a way
to keep applications in sync with the refresh rate. (That is not
necessarily in sync with the retrace - very important difference!)

Really smooth animation requires exactly one frame per refresh, and
without an RTOS, the only way to get that is using triple buffering (or
using just a fraction of the frame duration for rendering…) and some
method of synchronizing with the refresh rate, so you don’t drop any
video or game frames.

Get out of the DOS mode of thinking.

I have to agree there - but only to the point of not synchronizing the
application with every retrace, like most games did back then.

Vertical retrace is definitely a good thing
to have, but it isn’t guaranteed on every platform.

Or; every platform isn’t capable of producing high quality animation. We
can either deal with it, or try to fix it.

So in your opinion, if there is no way to sync to the vertical
retrace how can smooth animation be achieved? I open to any and all
suggestions.

Do it the same way that everyone else who doesn’t rely on vertical
retrace does it. Search the list archives for more than enough info.

I was thinking of using RTLinux by first polling for the retrace and
then setting a timer to be called. Once the timer is called I can
check if indeed the vga is in retrace and then signal the usermode
thread to update the display. I prefer not to go this route but if
that’s what I have to do then so be it.

Overkill … non-portable … RTLinux sucks … :).

Sure, it’s non-portable, but who cares if it’s an embedded system in a
arcade machine or something? If there’s no other way to get the video
card to pump out a steady stream of frames, it’s not overkill.

And finally, RTLinux - as well as RTAI - work great, and provide
scheduling accuracy down to the very limits of the hardware - but they’re
not meant for much higher level stuff than in this case, guaranteeing
that exactly one page is shown for each video refresh. You don’t run a
full game as RTL/RTAI threads.

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Sunday 09 December 2001 06:16, M. R. Brown wrote: