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

[Pauli Nieminen]

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