On Tue, 2011-11-01 at 22:43 -0700, James Jones wrote: > 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:
Thanks for the response here - it's very useful even at a high level. [...] > > * 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. Hmm, does the wait for the GPU occur at the time that buffers or swapped, or are damage events emitted at some later point? If the damage events are done asynchronously later than the WM manager would see: Counter Update to Odd Value Counter Update to Even Value Damage event Things should still display correctly, but the way I've written things the compositor is supposed to fall back to doing it's own XSyncTriggerFence() in that case, which would spoil the point of the exercise from an efficiency point of view. And frame completion clien messages wouldn't work 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. I guess the question is the migration path - how do you go from a world where a GL app can do anything it wants to damage the front buffer, to a world where apps can optionally pass fence information to the compositor and get useful performance improvements from that. > 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. You are certainly correct this is something that needs to be discussed in the specification. If I read the sync spec correctly, one easy answer is that the client just does: XsyncAwaitFence() XSyncResetFence() XSyncTriggerFece() <update counter> right in a row when it finishes a frame. When the window manager sees the updated counter via an AlarmNotify event, the ResetFence is guaranteed to have been handled by the X server, since ResetFence is done "immediately". The client can potentially omit the AwaitFence if it's already gotten a _NET_WM_SYNC_DRAWN for the previous usage of the fence back from the window manager. I don't have enough of an idea about implemention of fences to know whether that's worthwhile optimization or not - what is the expected cost of waiting for an already triggered fence. - Owen _______________________________________________ wm-spec-list mailing list wm-spec-list@gnome.org http://mail.gnome.org/mailman/listinfo/wm-spec-list
