glXSwapBuffers fix for moving between crtcs is not following the OML_sync_control specification
Jesse Barnes
jbarnes at virtuousgeek.org
Fri Jul 9 09:11:22 PDT 2010
On Fri, 9 Jul 2010 18:07:25 +0200
Mario Kleiner <mario.kleiner at tuebingen.mpg.de> wrote:
> On Jul 9, 2010, at 3:40 PM, Michel Dänzer wrote:
> > I agree there *should* be such a single MSC, the question is how it
> > should be calculated when the CRTCs don't all have the same vertical
> > refresh rate.
>
> I guess OML_sync_control was specified at a time when systems with
> multiple-displays for one screen didn't exist, at least not ones with
> different refresh rates for the same screen. If you think about how
> applications would use the extension to precisely schedule swaps, i
> think the assumption is that the drawable will usually not move
> between crtc's or that all crtc's work perfectly synchronized with
> the same refresh rate, e.g., for multi-display virtual reality
> applications.
>
> >
> > 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.
Sounds like another case where we need a Mesa extension to specify
specific behavior...
--
Jesse Barnes, Intel Open Source Technology Center
More information about the xorg-devel
mailing list