Adding synchronization to the WM spec (original) (raw)

There are quite a few outstanding issues related to synchronization between applications and the compositor. We want the compositor to avoid drawing a window when it is only half done with an update, we want to throttle the drawing rate in the application, and we need to incorporate NVIDIA's fence sync objects if we want to get composited drawing correct with their driver.

This update to the window manager specification attempts to address these needs in a unified way. What I'm basically proposing here is:

I did implementations of the first two for Mutter a while ago to validate the ideas; the third portion is, so far, just speculative.

The details are found in the attached patch to the WM Spec. (I've filed a bug against freedesktop sysadmin to get the wm-spec moved over to git.)

What the patch is about is basically "frames", but I've avoided the term in the spec, because of confusion with window decoration frames.

Potential issues:

Some references:

I originally brought up the need to be able to do an atomic frame: http://mail.gnome.org/archives/wm-spec-list/2009-June/msg00002.html

The idea of using two counters in the _NET_WM_SYNC_REQUEST comes from Denis Dzyubenko: http://mail.gnome.org/archives/wm-spec-list/2009-July/msg00005.html

Information about how the sync fence objects are used for GPU-level synchronization can be found in: http://lists.x.org/archives/xorg-devel/2010-December/016510.html

The relevant additions to the Sync extension for fences are found in: http://cgit.freedesktop.org/xorg/proto/xextproto/commit/?id=9ba2065b63ea0e61a17b8221ad454c02a1755373

And are used with: http://www.opengl.org/registry/specs/ARB/sync.txt http://www.opengl.org/registry/specs/EXT/x11_sync_object.txt

From 6c2e603ca62b32bf87185ff6ba9fdb22459b93e8 Mon Sep 17 00:00:00 2001 From: "Owen W. Taylor" Date: Fri, 28 Oct 2011 19:08:11 -0400 Subject: [PATCH] Add support for deliminating updates

To support an application marking the beginning and end of the frame, add a new form of _NET_WM_SYNC_REQUEST where a client can update the counter to an odd value saying "I'm starting the frame" and to an even value to end the frame.

On top of that are built:

wm-spec.xml | 192 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++-- 1 files changed, 185 insertions(+), 7 deletions(-)

diff --git a/wm-spec.xml b/wm-spec.xml index 98f9f9b..55b7325 100644 --- a/wm-spec.xml +++ b/wm-spec.xml @@ -1,7 +1,7 @@ - + + ]>
@@ -1594,9 +1594,19 @@ the library documentation) to let client and window manager synchronize the repaint of the window manager frame and the client window. A client indicates that it is willing to participate in the protocol by listing _NET_WM_SYNC_REQUEST in the WM_PROTOCOLS property -of the client window and storing the XID of an XSync counter in the -property _NET_WM_SYNC_REQUEST_COUNTER. The initial value of this -counter is not defined by this specification. +of the client window and setting the _NET_WM_SYNC_REQUEST_COUNTER +property on a window. There are two forms of the protocol, a basic +form and an extended form. A client indicates support for the extended form +by setting _NET_WM_SYNC_REQUEST_COUNTER to a property containing two counters; +if _NET_WM_SYNC_REQUEST_COUNTER contains only a single counter, the window +manager must use the basic form of the protocol. + + + Basic form + +The initial value of the counter (which is the first value in +_NET_WM_SYNC_REQUEST_COUNTER if it contains two values, and the only +value if it contains one value) is not defined by the specification. A window manager uses this protocol by preceding a ConfigureNotify @@ -1617,7 +1627,7 @@ other data.l[] elements = 0 After receiving one or more such message/ConfigureNotify pairs, and having handled all repainting associated with the ConfigureNotify -events, the client MUST set the _NET_WM_SYNC_REQUEST_COUNTER to the 64 +events, the client MUST set the counter to the 64 bit number indicated by the data.l[2] and data.l[3] fields of the last client message received. @@ -1636,7 +1646,48 @@ this specification, the window manager MAY set the value of the XSync counter at any time, and MUST do so when it first manages a new window. - + + + Extended form + +In the extended form of the protocol, the counter used is the second +value that the client stores in _NET_WM_SYNC_REQUEST_COUNTER and the +first value is ignored. The initial value of this second counter is is +initialized by the client to a value of its choosing before it requests +the window to be mapped. + + +The added feature of the extended form of the protocol is that a +client can at any point increment value of the second counter; +this is used to deliminate updates. + + +If a window manager supports the extended form, when it discovers a +_NET_WM_SYNCf_REQUEST_COUNTER property with two values, it should use +the second value in the property as the counter for the protocol. The +window must track the value of this property by reading an initial +value using XSyncQueryCounter() and then using an an Alarm to watch +for subsequent changes. + + +Handling of _NET_WM_SYNC_REQUEST is largely the same as for the basic +form of the protoocol, but with small changes on the client and window +manager side: When the window manager sends a _NET_WM_SYNC_REQUEST message, +it should choose the value in the message by picking an even number at +least 100 greater than the last value it has seen for the counter. +(The number 100 here is arbitrary - it is chosen to be large enough +so that updates done spontaneously by the client will not cause conflicts.) + + +A client supporting the extended form of the protocol handles a +_NET_WM_SYNC_REQUEST_COUNTER message by, after handling all painting +associated with the following ConfigureNotify message, setting the +first counter to the newly received value, and the second counter to +the next even number equal to or greater than the newly received +value. + + + _NET_WM_FULLSCREEN_MONITORS + +In addition to sending one message at the end of each update, the window +manager must send one message for each newly mapped window that uses the +extended form of _NET_WM_SYNC_REQUEST after the window is first drawn, +even if the initial value that the window manager reads from the counter +is even. + + + + _NET_WM_SYNC_FENCES + +On some systems with loose synchronization between different clients using +the graphics system, simply waiting for notification from the X server +that the client has ended an update is not sufficient, and a GL-based +compositing manager must also insert GL-level synchronization to ensure +correct drawing. + + +The _NET_WM_SYNC_FENCES property is set on a toplevel by an +application and contains a list of XSync fence objects. Before ending +an update by setting the XSync counter to an even value N, the application, +must use XSyncTriggerFence() to trigger the fence object stored in the property +at index (N / 2) % L, where L is the number of counters in property. If +an application waits for the _NET_WM_SYNC_DRAWN message before making +a new update, 2 is a sufficiently large value for L. + + +When the window is mapped, the GL-based compositor must import the fences +in _NET_WM_SYNC_FENCES as GL sync objects using the ImportSyncEXT() +procedure from the EXT_x11_sync_object. +After receiving a frame update ending with counter value N, the next time +that the window is redrawn, the compositing manager should use glWaitSync() +on the fence at index (N / 2) % L. + + +Note that if an application window doesn't export _NET_WM_SYNC_FENCES, or +draws outside a frame update, the compositing manager still has to ensure +correct synchronization. If the compositing manager has received damage +events not part of any frame update, then before redrawing the screen, +the compositing manager must use XSyncTriggerFence() trigger an X fence it +has created itself and then wait for that with glWaitSync(). + + Implementation notes @@ -2174,6 +2330,18 @@ int net_get_hostname (char *buf, size_t maxlen) + + [x11_sync_object] + + + Piers Daniell, Pierre-Loup Griffais, James Jones, Aaron Plattner, + "EXT_x11_sync_object". + <ulink url="http://www.opengl.org/registry/specs/EXT/x11_sync_object.txt";> + http://www.opengl.org/registry/specs/EXT/x11_sync_object.txt + + + + @@ -2240,6 +2408,16 @@ OR OTHER DEALINGS IN THE SOFTWARE. Change history + + Changes since 1.4draft + + +Added extended form of the _NET_WM_SYNC_REQUEST protocol, along with +_NET_WM_SYNC_DRAWN and _NET_WM_SYNC_FENCES, to allow applications to +deliminate updates. + + + Changes since 1.3

1.7.7

[Date Prev][Date Next] [Thread Prev][Thread Next] [Thread Index] [Date Index] [Author Index]