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

[Jesse Barnes]

On Fri, 9 Jul 2010 18:07:25 +0200
Mario Kleiner <mario.kleiner at tuebingen.mpg.de> wrote:
> On Jul 9, 2010, at 3:40 PM, Michel Dänzer wrote:
> > 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.

Sounds like another case where we need a Mesa extension to specify
specific behavior...

-- 
Jesse Barnes, Intel Open Source Technology Center