On Jul 9, 2010, at 3:40 PM, Michel Dänzer wrote:
On Fre, 2010-07-09 at 16:20 +0300, Pauli Nieminen wrote:
This commit assumes that MSC maybe different depending on where the
drawable is. While specification says "For a multi-monitor system,
the
monitor used to determine MSC is screen 0 of <display>." which IMO
means that there should be single MSC everywhere were target drawable
can move. So correct fix would be making MSC value in-depend of CRTC
where drawable is.
That commit only fixes the glXSwapBuffers() case, which is not
defined in the OML_sync_control extension. I couldn't find any
specification of how glXSwapBuffers should behave wrt. drawable on
different crtc's, e.g., SGI_swap_control doesn't talk about such
multi-monitor issues. In that sense the patch doesn't violate a
specification, because the behaviour is unspecified.
Currently we have proper behaviour while the drawable is on a given
crtc - it obeys swap_interval. For the swap that happens between a
move of the drawable from one crtc to the other, we have a small
timing glitch: The swap_interval setting is ignored for that swap -
it swaps on the next retrace, as if swap_interval is 1. But then a
swap_interval of 1 is the default setting and probably what almost
all "standard" client apps use anyway.
We could do a bit better and avoid that single glitch by mapping msc
count from the crtc where the drawable was to the crtc where the
drawable is now. But that would need us to keep track of the previous
crtc of a drawable and we'd need new DDX entry points to query the
current msc of any given crtc and the current crtc of a given
drawable from within the server. Currently this info is only
available in the DDX itself. Something like (pseudo-code):
if (current_crtc != previous_crtc)
last_swap_target = last_swap_target + (msc(current_crtc) - msc
(previous_crtc));
Not sure if avoiding this small glitch is worth the hassle of two new
entry points?
If you use the glXSwapBuffersMscOML() command or other
OML_sync_control commands then the commit doesn't apply. Currently it
is up to the client application to find out if a drawable moved
between crtc's inbetween swaps and handle this in a app specific manner.
From the perspective of a toolkit developer i like this "do it
yourself" behaviour for glXSwapBuffersMscOML(). OML_sync_control
provides all the neccessary tools for a client app to detect and
handle such situations in a way that leaves the application in
control. Apps that use OML_sync_control will likely care very much
about very precise visual timing. Some automagic corrections like the
above for glXSwapBuffers() could spoil the day of someone (e.g.,
me ;) ) that needs very precise timing control and uses
OML_sync_control for that purpose.
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.
*********************************************************************
Mario Kleiner
Max Planck Institute for Biological Cybernetics
Spemannstr. 38
72076 Tuebingen
Germany
e-mail: [email protected]
office: +49 (0)7071/601-1623
fax: +49 (0)7071/601-616
www: http://www.kyb.tuebingen.mpg.de/~kleinerm
*********************************************************************
"For a successful technology, reality must take precedence
over public relations, for Nature cannot be fooled."
(Richard Feynman)
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
