How do I wait for vertical retrace?

[Jesse Barnes]

On Tuesday, May 06, 2008 10:13 am Carsten Haitzler wrote:
> On Tue, 06 May 2008 12:53:50 -0400 Chuck Robey <chuckr at chuckr.org> babbled:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Carsten Haitzler (The Rasterman) wrote:
> > > On Tue, 6 May 2008 18:43:52 +0200 Nicolas George
> > >
> > > <nicolas.george at normalesup.org> babbled:
> > >> L'octidi 18 floréal, an CCXVI, Johan Walles a écrit :
> > >>> I don't care about vertical retrace in itself, waiting for vertical
> > >>> retrace would only be a way for me to achieve flicker-free animation
> > >>> in a 2D application.
> > >>
> > >> DOUBLE-BUFFER is no good for that: when used for continuous animation
> > >> (such as video), it causes exactly as much tearing as a simple bitmap
> > >> copy. At least it was true in November 2006.
> > >
> > > it's been pretty much true as long as i have done anything with x
> > > (since about 1995...). i have yet to see is not tear...
> >
> > Well, I guess the Xorg command to swap buffers, while it certainly does
> > accomplish an immediate changing of any or all of the data in your screen
> > buffers, it also does automatically do retrace sync.  You'd want to
> > change your sits quite quickly as one requirements, but you'd want the
> > data to be swapper NOT in the middle of writing a screen, no matter how
> > fast it can happen.  You don't have to worry about syncing, OpenGL does
> > that for you without your direct involvement.
>
> opengl CAN vsync - IF you:
>
> 1. dont use a multihead xinerama/zaphod/twinview/whatever (1 root window
> across all screens) display. (in my experience this instantly disables any
> vsync) 2. if you gl buffer is a fullscreen window you get a buffer swap if
> the driver knows this and is smart - it just flips pointers for next
> retrace to pick up 3. if not u need to use the glx wait for vsync extension
> which means u will likely sit in a polling loop waiting for vsync (not
> being able to do anything else in your main loop while waiting).
>
> it *IS* possible to do it with - if you take care. you could use the glx
> vsync stuff in combination with 2d x and thus get close to vsync (as if u
> are fats enough from vsync to actually sending your request to copy from
> pixmap to window u'll do it before the trace hits the window).
>
> so this is how to do it. as such we really could do with a standard 2d
> vsync signal from x that is reliable and works the vast majority of the
> time and doesn't involve anyone sitting and polling/spinning. :) i can
> dream... :)

That's typically what I do for testing.  I put together this dead simple test 
program while I was working on vblank code in the DRM & Mesa drivers awhile 
back, but the approach should generally work (btw even across multiple heads:  
Mesa will figure out how much of the window is on each head and sync to the 
monitor displaying the most).

Note that this is far from ideal; it's much better to do actual GL buffer 
swaps (as mentioned earlier in this thread), but I'm not sure how well that 
works these days, nor what the ideal GL sequence is for that approach.

Jesse
-------------- next part --------------
A non-text attachment was scrubbed...
Name: glsync.c
Type: text/x-csrc
Size: 5638 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20080506/83b66123/attachment.c>