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

[Mario Kleiner]

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