Thanks for the explanation. I wasn't considering the fullscreen case where the compositor is directly scanning out from the client's buffers. I think for the non-fullscreen case the compositor would only hold on to a single buffer, right? In that case the sync request is enough.
I think in an ideal world you would still only need three buffers in the fullscreen case. Ie, you have one buffer that is currently used for scanout, one buffer that is pending and one buffer that you are rendering to. When you are finished rendering to that last buffer ideally the compositor would be able to cancel that pending buffer and instead queue the new buffer. As far as I understand, there is currently no way to cancel that pending buffer in KMS so that is why we need a fourth buffer. I'm not sure whether using four or more buffers is a good idea because that seems like quite a lot considering these are fullscreen buffers. Maybe in that case we should just give up and block. I guess it depends on whether we expect to be able to change KMS to allow cancelling the pending buffer, but it sounds like that could be quite hard. As for flushing the delayed buffer release event, maybe we could add a way to disable the event queuing if Weston knows that the client doesn't have a frame callback installed? I am about to attach two patches that would implement that. Regards, - Neil Pekka Paalanen <[email protected]> writes: > No, you generally don't get the release event as an immediate reply to a > commit request. > > 1. When you commit a new buffer, compositor schedules a repaint, and > continues processing your requests. If you simply asked for one > wl_display.sync right after the commit, it is acked now. > > 2. Some time later, the compositor actually enters repaint. It submits > a command stream to the GPU, and schedules a page flip onto the screen. > At this point the compositor sends the frame callbacks, if you > requested one. Then the compositor continues processing requests in the > mean time. > > 3. Some more time later, the GPU is done, and the page flip is done. > The compositor gets an async notification that the page flip is > complete. Only at *this point* is the compositor able to send a release > for the old buffers. > > So you see, step 3 comes much later than your sync for the commit. The > compositor cannot signal the release of any buffers before the page > flip is done, because the GPU or scanout may be using the buffers > still, and you risk re-using a buffer while it being read. > > The step 3 is pratically guaranteed to come, the wait for it is not > indefinite, but it is not immediate either. It is not synchronized to > the Wayland protocol, like many other replies are. > > The only time when you could get the release for the old buffer as an > immediate reply is, when the old buffer has never been on screen yet. > Provided you also did a wl_display.sync after the commit. > > Also don't forget about sub-surfaces, which may hold one additional > buffer indefinitely (until the parent surface is committed). > > Unfortunately, I do not have any good suggestions how to solve this, > other than sending the release with 'post', not 'queue'. Could we > perhaps use the hypothetical presentation time stamp event, that would > be fired at step 3, to flush out the release events for a client? > > (To complement the frame callback which tells when a client should > start preparing a new frame, there was a plan to add a presentation > timestamp callback to be used for AV-sync etc. telling the time the > frame actually turned into light. I don't know what the status of that > proposal is nowadays.) > > > Hmm, or could we simply rely on the "never been on screen" behaviour? > Does that make the wl_display.sync proposition work after all? > I'm a little sceptical, but can't think far enough... > > Re-thinking again, I would need to re-check the code whether the "never > been on screen" actually applies for non-sub-surfaces. In theory it > should. > > > Thanks, > pq --------------------------------------------------------------------- Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
