Re: Adding synchronization to the WM spec

[James Jones <jajones nvidia com>]

I'm trying to make time to read through your proposals/code in more 
detail, but my record in the "making time for things" area is pretty 
abysmal, so some brief initial comments on the un-implemented fence-sync 
portion of the spec below:

On 10/29/11 9:29 AM, Owen Taylor wrote:
> 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:
>
>   * 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.

I don't consider this messy.  Fence syncs were always meant to be used 
as companions to counters.  My sample compiz code bundles them together 
as well to optimize their usage (I know, I'm nearly a year late on 
publishing this now.  I'll get it out soon*).

>   * A message _NET_WM_SYNC_DRAWN that is sent when the compositor
>     has drawn the frame.
>
>   * A property _NET_WM_SYNC_FENCES that can be combined with the
>     counter value to find an appropriate fence to wait on.
>
> 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:
>
>   * The bundling of the a legacy counter and a new counter into
>     _NET_WM_SYNC_REQUEST counter could be considered messy
>     It does save fetching another property at startup, and the behavior
>     described here tightly couples the two counters to avoid excessive
>     duplication and unclear interactions.
>
>   * I'm not really sure how the fence synchronization is supposed
>     to work for the case of a direct rendering GL client. Is the combination
>     of glXSwapBuffers() and XSyncTriggerFence() sufficient?

Good point.  This is messy specification-wise, but in practice, I think 
this is indeed sufficient.  Our implementation always sends damage 
events for GL rendering only after the rendering that generates the 
damage has been completed on the GPU, and from what I understand, open 
source implementations order their accesses to the surfaces implicitly 
and/or do the swap operation in the GLX server anyway, so the 
XSyncTriggerFence() isn't strictly necessary, but it isn't particularly 
harmful if you want to leave it to keep the design clean.  The composite 
manager will wait for both the fence sync and the damage event I assume, 
so even though the fence trigger doesn't execute in the right GPU 
thread, it will work out right.

At some point I would like to add a second GL extension that allows 
triggering the X Sync Fence objects from GL so this could be done 
properly, but it's low priority given the above.  I omitted it from the 
initial spec because it's much harder to implement efficiently.

One problem I see with your spec:  When are the fence sync objects 
reset?  In the current form, it will only run properly for "L" 
iterations.  I've found this non-trivial to solve efficiently in my code 
(but very doable).  The solution you'll need is slightly different, 
since the consumer and producer of fence sync triggers are separate 
applications.

Thanks,
-James

>   * It's unclear to me exactly what timing information (if any) it's
>     useful to include in _NET_WM_SYNC_DRAWN. I've just omitted all
>     information in this draft, I'll try to work through the various
>     use cases and come up with a proposal later.
>
> 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

nv-public

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------