glXSwapBuffers fix for moving between crtcs is not following the OML_sync_control specification
Michel Dänzer
michel at daenzer.net
Fri Jul 9 09:15:17 PDT 2010
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
More information about the xorg-devel
mailing list