Neil, After further consideration, I think your approach is exactly what we need. Not only are there more possible (backend-dependant) release algorithms than the two I listed but determining whether to queue or post may be more complicated. For instance, if a frame is offscreen it may have frame callbacks pending that will not get sent. Should we make sure the regular gets sent anyway? I don't think this last issue is a showstopper as the patch is no worse than the current implementation. I'd say we apply this now and get the pi backend working. We can fix release of offscreen surfaces later. -- Jason Ekstrand <div class="gmail_quote">On Oct 2, 2013 2:20 PM, "Jason Ekstrand" <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On Oct 2, 2013 10:06 AM, "Neil Roberts" <<a href="mailto:neil@linux.intel.com" target="_blank">neil@linux.intel.com</a>> 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 best solution. > 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 > complete. > > Regards, > - Neil > > Jason Ekstrand <<a href="mailto:jason@jlekstrand.net" target="_blank">jason@jlekstrand.net</a>> 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 the > > 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 at > > 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. > </blockquote></div>