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

[Pauli Nieminen]

2010/7/12 Michel Dänzer <michel at daenzer.net>:
> 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?
>

We can actually use CRTC 0 as source for MSC and then map the swap
request to closed vblank in others CRTCs. Of course this won't be
visually as good as having correct interval for MSC.

It doesn't but it doesn't also make sense that multiple drawables
can't be synchronized to each other using MSC. This would be required
for use case that Mario Kleiner pointer out that client would have
multiple drawables and would use sync control to keep them in sync.

But I guess we need better control extension for that kind of
application. Maybe timestamp based interface would work better for
multi-drawable multi-crtc use case.

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

I was just pointing out what is problem if not using virtual MSC. I
agree that it would be good solution to the problem.

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