Buffer release events (was: Add support for eglSwapInterval)

[Jason Ekstrand]

Neil,
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.

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.

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.

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:

1) wl_surface.commit
2) surface_flush_damage (the gl renderer releases SHM buffers here)
3) random releases from the backdend/renderer

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.

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.

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.

Hope this is useful.
--Jason Ekstrand


On Wed, Oct 23, 2013 at 2:01 PM, Neil Roberts <neil at linux.intel.com> wrote:

> Neil Roberts <neil at linux.intel.com> writes:
>
> > Currently the only proposed complete solution is just to add a request
> > to explicitly disable the queuing mechanism.
>
> I started writing this patch but I've hit a stumbling block while trying
> to make use of it in Mesa. Adding the new request requires altering the
> version of the wl_compositor and wl_surface interfaces. The problem is
> that Mesa can't really use the new request unless the wl_surface object
> is using the new version. However, the version of the interface that is
> actually in use is determined by the application when it binds the
> compositor object. As far as I can tell, there is no way for Mesa to
> determine what version the surface proxy object is using. Potentially we
> could add some API to query this, but I think even that wouldn't be
> ideal because really Mesa wants to know the interface version number
> right up front when the display is initialised so that it can determine
> the value to report for EGL_MIN_SWAP_INTERVAL.
>
> I'm not sure how to proceed with this. It seems like ideally Mesa should
> be able to make requests on the surface using its own binding of the
> compositor object so that it's not tied to the version of the interface
> that the application is using. I guess that would imply that it would
> have some way to get its own resource for the surface. That seems like
> quite a packed can of worms though.
>
> Anyone have any ideas?
>
> I'll attach the work in progress patches anyway just for good measure.
>
> Regards,
> - Neil
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20131023/16d39410/attachment.html>