[PATCH v2] Post buffer release events instead of queue when no frame callback
jason at jlekstrand.net
Wed Oct 2 12:20:09 PDT 2013
On Oct 2, 2013 10:06 AM, "Neil Roberts" <neil at linux.intel.com> wrote:
> I don't think this function would help in cases where the buffer is
> released after the frame is drawn but the compositor is not drawing
> anything else. Ie, if the events were like this:
> 1 - client attaches a buffer and waits for the next release
> 2 - compositor redraws a frame
> 3 - the redraw completes so the compositor flushes all event queues
> 4 - the swap completes and the compositor queues a release event
> If nothing else causes the compositor to queue a redraw the release
> event will just sit in the event queue forever and the client will still
> be blocked waiting for it.
If the backend is going to send the release from the swap, shouldn't it
just post instead of queue anyway? The reason for queueing in the first
place is to simply delay the event until the render. Perhaps I am
misunderstanding what you mean.
Also, I can really only envision two cases for buffer releasing:
1. Where the compositor can release the buffer as soon as it is on the card
(the current case with shm and the go renderer). In this case we can send
the release during the render or earlier.
2. Where the compositor cannot release the buffer until it is done with the
render (go client in a DRM plane). In this case you can't release until
the client commits another buffer (causing a repaint) because you might
need it for a second render. In order to handle handle this case, we may
have to post instead of queue in the case where the client is off screen.
Am I missing any cases? If I am then the current system is probably
fundamentally broken anyway. In that case, what you have is probably the
> I think this doesn't actually happen at the moment because as far as I
> can tell the gl-renderer immediately queues the buffer release when you
> attach a new one rather than waiting for the swap to actually complete.
> I think that would mean you could cause tearing if you are using
> eglSwapInterval(0) because you could write into the released buffer
> while the GPU is actually still rendering the previous frame using the
> buffer in a texture.
I recall there being a good reason why this isn't a problem. Something
about the way the drivers are implemented but I don't remember the details.
> I will try an experiment to check this. If that's right then we should
> probably add an extra buffer reference in the gl-renderer whenever it
> uses a texture to draw and then only release it when the frame is
> - Neil
> Jason Ekstrand <jason at jlekstrand.net> writes:
> > All,
> > Perhaps a simpler approach would be better. We could add a function to
> > wayland-server called wl_client_post_event_queue which would simply set
> > wants_flush flag on the client connection. This function would be fast
> > ,require no I/O, and safe to call multiple times so Weston could simply
> > call it on all clients with surfaces visible on the output in question
> > the time when it would call frame events. Then, when the event loop
> > flushes the clients, the release events will get sent out.
> > --Jason Ekstrand
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the wayland-devel