2010/7/9 Mario Kleiner <[email protected]>: > On Jul 9, 2010, at 6:15 PM, Michel Dänzer wrote: >> >> [...] >> >>>> 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. >> > > I can see that maintaining a per-drawable virtual msc counter could work, > although you'd need to do very careful forward and backward mappings from > virtual <-> real crtc in various places, e.g., translate to true vblank > counts for scheduling vblank events in the kernel and then translating back > at swap completion for glXWaitForSbcOML and the new INTEL_swap_events > extension, taking possible movements of the drawable between scheduling the > swap and completing the swap into account. I think the asynchronous nature > of the new dri2 sync & swap bits can cause a couple of new headaches here. > > One problem i can see is if you have multiple drawables synced to/on the > same crtc and you want to schedule them to swap in sync or at specific msc > offsets to each other. As long as all msc values refer to the same real msc > of the crtc, everything is fine. If each drawable has its own virtualized > msc, e.g., initialized to zero at drawable creation time and then > monotonically incrementing, you have different reference points - msc counts > are no longer comparable and meaningful between drawables. > > -mario > >
Problem with multiple MSC values running in parallel is that we will have 99% applications hitting same multi-crtc problems. To avoid that OML_sync_control specification has that one single sentence requiring to use screen 0 MSC in-depend of actual location of target drawable. That translates in current day to first CRTC. Problem providing multiple MSC values with OML_sync_control is that application can't quarantine anyway that MSC haven't changed suddenly causing application freeze. Pauli _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
