On Fri, 9 Jul 2010 18:07:25 +0200 Mario Kleiner <[email protected]> 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 _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
