[PATCH v2] Post buffer release events instead of queue when no frame callback

[Pekka Paalanen]

On Mon, 16 Sep 2013 16:28:31 +0100
Neil Roberts <neil at linux.intel.com> wrote:

> Pekka Paalanen wrote:
> 
> > Instead of all this, could you not have made Weston simply use
> > wl_resource_post_event() instead of wl_resource_queue_event()?
> 
> Yes, posting the event rather than queuing it when there are no frame
> callbacks (is that what you meant?) is a lot simpler than having the
> queue disabling mechanism. I'm not sure why I didn't think of that.

Yeah :-)

> Otherwise if you meant using post all of the time, then that was
> discussed here and it doesn't seem like such a good idea:
> 
> http://lists.freedesktop.org/archives/wayland-devel/2013-September/010987.html

Yes, I'm aware.

The main loop for a compositor is:

while (1) {
	flush clients;
	dispatch idle handlers; /* repaint begin */
	epoll_wait();
	event loop dispatch; /* commit, repaint finish */
	post_dispatch;
}

Hmm, Weston begins repaints from an idle handler, and finishes when a
related event arrives (e.g. DRM page flip event). Yes, looks like there
indeed is the double-wake-up of clients, if commit immediately releases
an old buffer, and the release event is posted, not queued, and then
compositor enters repaint, sending frame events. Frame events are sent
in repaint begin, but usually flushed out only when something has woken
the compositor up from epoll... that seems kind of strange, no?

When looking at WAYLAND_DEBUG=server dumps, one thing to keep in mind
is, are the events timestamped and printed when they are "sent" or
actually flushed out. On client side, events are printed when they are
dispatched (a missing listener for an object causes events not to be
printed at all).

And the double-wake-up also happens if repaint finish posts a release,
I guess...

If we look at client EGL buffers, that are not scanout, so they will be
GL textures, an immediate release of the old buffer can happen only, if
the compositor is not in the middle of repaint. Otherwise it would be
releasing buffers that might still be textured from. If the compositor
is waiting for a previous repaint to finish, the old buffer release
should be postponed to the end of repaint (finish_frame). This applies,
when the compositor is in a rendering loop, which is what a client with
swapinterval 0 will cause, i.e. the case where the buffer releases are
needed ASAP.

Another thing I'm not sure about is when possible input events are
posted to clients. The goal anyway is to group all event sending into
one flush per output frame, at least when the compositor is
continuously repainting.

I'm not sure what I'm trying to say. I'm also not sure if Weston
currently postpones the release of an EGL buffer used as a texture
properly, if a repaint is on-going.

> > I can't say if that is a good heuristic or not, to assume that
> > surfaces where a client is not interested in frame callbacks need
> > buffer releases ASAP. Apart from an explicit request, I have no
> > better suggestions.
> 
> As far as I understand, the queuing mechanism is specifically an
> optimisation aimed at the frame callback mechanism to avoid waking up
> the client twice. Therefore disabling it when there are no frame
> callbacks seems like quite a natural thing to do in my mind. It's not
> that the clients want the event ‘ASAP’ but rather that without the
> patch the compositor will never send the events no matter how long the
> client waits.

Mm, maybe you are right. All the interactions are just too much for me
to think quickly without spending a whole day.


Thanks,
pq