glXSwapBuffers fix for moving between crtcs is not following the OML_sync_control specification

[Michel Dänzer]

On Sam, 2010-07-10 at 00:08 +0300, Pauli Nieminen wrote: 
> 2010/7/9 Mario Kleiner <mario.kleiner at tuebingen.mpg.de>:
> > 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,

IIRC I used a delta value for conversion between the two.

> > taking possible movements of the drawable between scheduling the
> > swap and completing the swap into account.

Stick to the same CRTC until the end?

> > I think the asynchronous nature of the new dri2 sync & swap bits can
> > cause a couple of new headaches here.

It's a complex situation, the complexity needs to be dealt with
somewhere. :) Just leaving it all to the apps / toolkits doesn't seem
like a great plan.

> > 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.

That can be unavoidable anyway if the drawables are ever on different
CRTCs. Otherwise it should be possible to keep this working, e.g. by
starting from the raw value of the initial CRTC.


> 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.

That just doesn't make too much sense to me. What good is a 60 Hz MSC
for an app running on an 85 Hz 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.

The 'virtual' MSC discussed above would increase monotonically, so
unless I'm misunderstanding you this shouldn't be an issue.


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer