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
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
