On Tue, 26 Oct 2010 19:19:11 +0300 Pauli Nieminen <[email protected]> wrote: > SGI_video_sync: > "The kernel maintains a video sync counter for > each physical hardware pipe in a system; the counter is incremented > upon the completion of the display of each full frame of video data. An > OpenGL context always corresponds to a pipe."
Right, this is the rule we break; we don't have a 1:1 correspondence between gfx pipes and display pipes. > "The single video sync counter is shared by all GLXContexts." > > Yes. You have to extent both OML_sync_control and SGI_video_sync to expose > separate MSC for different CRTCs. > > I can see race condition even with events. > > * Client checks for event (none yet in queue) > * Client prepares to call some blocking msc call > * Window manager decides to move the window > * xserver send MSC change event > * Client calls blocking MSC call > > But maybe there is solution. All blocking calls could fail if MSC base > changes. Client would have to query for new base and rate before trying to > issue same request again. Yeah, that might work; I agree there's a race even with events that we'll need to handle. But even with that race handled I'd like the server to fail gracefully rather than hanging the app if an old MSC value is passed in (though in that case we could print an error message since we could assume an app error as long as the app was using the extended version of the spec). > For swap interval it would be enough if DDX would notify DRI2 about crtc > changes with offset (msc_for_new_crtc - msc_for_old_crtc) that can be applied > to swaptarget. Yeah, just jumping to the new value might be ok in general. Hardcore libraries like Mario's can do something fancier with the extensions above to avoid unintended behavior. Thanks again for all your work on this. These are good improvements. -- 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
