Synchronization with CRT refresh

[Jim Gettys]

On Tue, 2005-05-03 at 11:58 -0400, Adam Jackson wrote: 
> On Tuesday 03 May 2005 11:02, Jim Gettys wrote:
> > Unfortunately, this has never been implemented on Linux.
> >
> > Volunteers gratefully accepted...
> 
> I looked at doing this for i128 a while ago, and there's a few issues involved 
> in getting it right.  The simple first one is actually wiring up the sync 
> counter from the driver, afaict there's no existing driver infrastructure for 
> this.  Is there any sample implementation of a driver that exports a sync 
> counter?
> 

Not commonly available: we did implementations on closed source UNIX in
the early 1990's. Alan Cox started on a kernel framework for this for
Linux to plug into just before he went to graduate school; I don't know
what happened to the code.

> There's an issue on multi-card servers: how do you determine which sync 
> counter to use?  Key off the screen number, I suppose.  Now think about 
> Xinerama systems, you can have two refresh rates per screen, and they might 
> never properly sync.  Eew.  Guess you'll just flicker when moving across the 
> Xinerama boundary.  (Although in the compmgr case this doesn't happen.)  
> Either way you need a convention for naming these counters.

If you need simultaneous update, then you need to gen-lock the monitors;
high end systems allow for this.

> 
> It wasn't entirely clear to me from reading the spec what the semantics are 
> for syncing.  Is it: server gets sync notification from hardware, pokes 
> clients, clients draw in a mad rush, server blasts stuff to screen hoping 
> we're still in the vblank time?  That would be terrible, but it looks like 
> that's what XSyncAwait does.

Yes, but more interestingly is for smooth animation and/or buffer
switching on double or multibuffered systems.


> 
> I was hoping for something more along the lines of: clients queue operations 
> to the server with an associated counter value, server holds these as display 
> lists and fires them on vblank.  If nothing else, this lets you meaningfully 
> vsync clients running on remote hosts (where the round trip latency exceeds 
> the vblank interval).  If all your clients are on the local machine the mad 
> dash approach might work, but.

Exactly.  Sync is designed for this case, so that operations can be
queued in the server's buffers and be local when they need execution,
without a round trip.

Clients can get events to keep them generating more requests, that will
block awaiting the next counter increment. 
> 
> So basically I want:
> 
> XSyncBegin(trigger_type);
>     XPutImage(blah);
> XSyncEnd();
> 
> Finally just as a trivial note, it's not clear to me how to express the idiom 
> of "wait for the next increment of this counter, without caring what its 
> value is".  For simple apps where you don't care about getting animation 
> exactly timed, this is precisely the vsync semantics you want.
> 
> Am I totally misinformed here?

Yes, you can get this, IIRC; it is a bit obscure.

Getting these idioms documented would be good....

> 
> - ajax