glXSwapBuffers fix for moving between crtcs is not following the OML_sync_control specification

[Michel Dänzer]

On Fre, 2010-07-09 at 18:07 +0200, Mario Kleiner wrote: 
> On Jul 9, 2010, at 3:40 PM, Michel Dänzer wrote:
> 
> > On Fre, 2010-07-09 at 16:20 +0300, Pauli Nieminen wrote:
> >>
> >> This commit assumes that MSC maybe different depending on where the
> >> drawable is. While specification says "For a multi-monitor system,  
> >> the
> >> monitor used to determine MSC is screen 0 of <display>." which IMO
> >> means that there should be single MSC everywhere were target drawable
> >> can move. So correct fix would be making MSC value in-depend of CRTC
> >> where drawable is.
> 
> That commit only fixes the glXSwapBuffers() case, which is not  
> defined in the OML_sync_control extension. I couldn't find any  
> specification of how glXSwapBuffers should behave wrt. drawable on  
> different crtc's, e.g., SGI_swap_control doesn't talk about such  
> multi-monitor issues. In that sense the patch doesn't violate a  
> specification, because the behaviour is unspecified.
> 
> Currently we have proper behaviour while the drawable is on a given  
> crtc - it obeys swap_interval. For the swap that happens between a  
> move of the drawable from one crtc to the other, we have a small  
> timing glitch: The swap_interval setting is ignored for that swap -  
> it swaps on the next retrace, as if swap_interval is 1. But then a  
> swap_interval of 1 is the default setting and probably what almost  
> all "standard" client apps use anyway.
> 
> We could do a bit better and avoid that single glitch by mapping msc  
> count from the crtc where the drawable was to the crtc where the  
> drawable is now. But that would need us to keep track of the previous  
> crtc of a drawable and we'd need new DDX entry points to query the  
> current msc of any given crtc and the current crtc of a given  
> drawable from within the server. Currently this info is only  
> available in the DDX itself. Something like (pseudo-code):
> 
> if (current_crtc != previous_crtc)
> 	last_swap_target = last_swap_target + (msc(current_crtc) - msc 
> (previous_crtc));
> 
> Not sure if avoiding this small glitch is worth the hassle of two new  
> entry points?
> 
> 
> If you use the glXSwapBuffersMscOML() command or other  
> OML_sync_control commands then the commit doesn't apply. Currently it  
> is up to the client application to find out if a drawable moved  
> between crtc's inbetween swaps and handle this in a app specific manner.
> 
>  From the perspective of a toolkit developer i like this "do it  
> yourself" behaviour for glXSwapBuffersMscOML(). OML_sync_control  
> provides all the neccessary tools for a client app to detect and  
> handle such situations in a way that leaves the application in  
> control. Apps that use OML_sync_control will likely care very much  
> about very precise visual timing. Some automagic corrections like the  
> above for glXSwapBuffers() could spoil the day of someone (e.g.,  
> me ;) ) that needs very precise timing control and uses  
> OML_sync_control for that purpose.

[...]

> > For the old intel DRI1 swap scheduling hack, I solved this by  
> > making the
> > MSC not correspond to any specific CRTC counter directly but making  
> > it a
> > 'virtual' counter which increases at the same rate as the CRTC the
> > window is currently being synchronized to. Looking at the
> > GLX_OML_sync_control spec again, I think this solution should still be
> > feasible in general, as all the extension calls take a drawable
> > parameter.
> 
> Hmm. I'm not sure if i as a toolkit developer would like that kind of  
> virtualization. What i do is i have a given target system time at  
> which the swap should happen - as close to that time as possible. I  
> use the msc count and the associated ust timestamp together with the  
> known video refresh rate and my given target time to translate the  
> target time into a target_msc. I use these counts and timestamps to  
> synchronize with other modalities like sound, various i/o etc. and  
> often need sub-millisecond accurate timing. Sometimes i need to  
> synchronize swaps across multiple displays. If such a virtualized  
> counter wouldn't be very accurate or if the associated ust timestamps  
> wouldn't be very accurate, i'd be in trouble and the OML_sync_control  
> extension would lose most of its value to me.

The accuracy should be the same, and sophisticated apps / toolkits such
as yours can still do the same things when the window moves between
CRTCs. However, I suspect most apps / toolkits won't be as
sophisticated, and would be more likely to work sensibly.


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer