<div dir="ltr"><div><div>Neil,<br></div>Thanks for cracking away at this. I've been kicking it around and I'm wondering if we're going in the wrong direction. I apologize if what I'm about to say has already been thought about and discarded for some reason. I don't remember everything that was considered.<br> <br>It seems to me as if the default should always be to just send the event. It's a "release" event after all and not sending it seems like a break of protocol. Instead, it seems as if we should look at delaying it as an optimization that we only do if it makes sense. I've kicked around a number of different ideas for how to detect this but haven't found anything bulletproof yet. I'll keep kicking it around and mail again if I find something.<br> <br>One non-automatic to do this would be to have a lazy_release flag that you can set on a surface if you don't want to be woken up. (Note that this is opt-in not opt-out). Then Mesa or whoever can assume that, unless the client has set lazy_release, it will get all its buffer release events. The obvious downside here is that this is an extra step required for otherwise simple clients to get an obvious optimization.<br> <br></div><div>There may also be a way that we can sidestep the whole issue. (I suggested this to Axel Davy [mannerov] and it worked for him in his wlglamor DDX.) We can identify buffer release events in weston as coming from one of three sources:<br> <br></div><div>1) wl_surface.commit<br></div><div>2) surface_flush_damage (the gl renderer releases SHM buffers here)<br></div><div>3) random releases from the backdend/renderer<br><br></div><div>Number 2 above happens during the redraw loop so we can just post the event and won't get a double-wakeup. Number 3 is something we can't really control; I'd personally lean towards posting the event here, but it's probably at most one reference per surface so we can probably get away with queueing. (Also, if the backend knows when it would release in the render cycle, it may be able to optimize this better than some compositor-general solution.) For these two, we can add an argument to weston_buffer_reference to set the release event type.<br> <br>Number 1 above is the source of the vast majority of out release events. This includes all buffers in the pixman renderer, EGL buffers for the gl renderer, and any time you commit a buffer before the previous one gets a chance to hit the screen. The good news is that we can, from a client perspective, deal with this one easily. The solution is to send a wl_display.sync request immediately after the commit. This will force any queued wl_buffer.release events to get sent out immediately. The client can even destroy the returned proxy immediately and completely ignore the resulting event. This seems a bit hackish, but this is exactly the kind of thing the sync request is intended for: flushing the stream.<br> <br></div><div>In any case, dummy sync and frame requests (you may need both) will allow you to achieve glSwapInterval(0) without server-side support. If you decide to go ahead with the proposed interface, you can use this stunt in the case where the wl_surface version < 4.<br> <br></div><div>Hope this is useful.<br></div><div>--Jason Ekstrand<br> </div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Oct 23, 2013 at 2:01 PM, Neil Roberts <span dir="ltr"><<a href="mailto:neil@linux.intel.com" target="_blank">neil@linux.intel.com</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">Neil Roberts <<a href="mailto:neil@linux.intel.com">neil@linux.intel.com</a>> writes:<br> <br> > Currently the only proposed complete solution is just to add a request<br> > to explicitly disable the queuing mechanism.<br> <br> </div>I started writing this patch but I've hit a stumbling block while trying<br> to make use of it in Mesa. Adding the new request requires altering the<br> version of the wl_compositor and wl_surface interfaces. The problem is<br> that Mesa can't really use the new request unless the wl_surface object<br> is using the new version. However, the version of the interface that is<br> actually in use is determined by the application when it binds the<br> compositor object. As far as I can tell, there is no way for Mesa to<br> determine what version the surface proxy object is using. Potentially we<br> could add some API to query this, but I think even that wouldn't be<br> ideal because really Mesa wants to know the interface version number<br> right up front when the display is initialised so that it can determine<br> the value to report for EGL_MIN_SWAP_INTERVAL.<br> <br> I'm not sure how to proceed with this. It seems like ideally Mesa should<br> be able to make requests on the surface using its own binding of the<br> compositor object so that it's not tied to the version of the interface<br> that the application is using. I guess that would imply that it would<br> have some way to get its own resource for the surface. That seems like<br> quite a packed can of worms though.<br> <br> Anyone have any ideas?<br> <br> I'll attach the work in progress patches anyway just for good measure.<br> <br> Regards,<br> - Neil<br> <div class="HOEnZb"><div class="h5">_______________________________________________<br> wayland-devel mailing list<br> <a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a><br> <a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br> </div></div></blockquote></div><br></div>