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 _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
