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

[Mario Kleiner]

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.

>
> I agree there *should* be such a single MSC, the question is how it
> should be calculated when the CRTCs don't all have the same vertical
> refresh rate.

I guess OML_sync_control was specified at a time when systems with  
multiple-displays for one screen didn't exist, at least not ones with  
different refresh rates for the same screen. If you think about how  
applications would use the extension to precisely schedule swaps, i  
think the assumption is that the drawable will usually not move  
between crtc's or that all crtc's work perfectly synchronized with  
the same refresh rate, e.g., for multi-display virtual reality  
applications.

>
> 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.

*********************************************************************
Mario Kleiner
Max Planck Institute for Biological Cybernetics
Spemannstr. 38
72076 Tuebingen
Germany

e-mail: mario.kleiner at tuebingen.mpg.de
office: +49 (0)7071/601-1623
fax:    +49 (0)7071/601-616
www:    http://www.kyb.tuebingen.mpg.de/~kleinerm
*********************************************************************
"For a successful technology, reality must take precedence
over public relations, for Nature cannot be fooled."
(Richard Feynman)