[RFC weston] Add a release_type argument to weston_buffer_reference (the problem)

[Pekka Paalanen]

On Wed, 04 Dec 2013 20:24:34 -0800
Bill Spitzak <spitzak at gmail.com> wrote:

> However there is no guarantee that repaint will release the old
> buffers. It sounds like the Raspberry Pi does this. Also isn't this
> true of overlay and fullscreen surfaces on some devices?

On RaspberryPi, all surfaces are always on a "hw" overlay. If the
wl_buffer comes from EGL, the buffer will be scanned out directly,
zero-copy.

> Jason Ekstrand wrote:
> > The second case is if compositor is releasing buffers at 
> > strange times or if there is some significant advantage in the
> > client geting woken up the moment it has a free buffer.  This is
> > what Tomeu wants to do with the Raspberry Pi (Buffers get released
> > at strange times and doing so allows them to save a buffer).

On Rpi, EGL-based buffers get released on "strange times" because, we
have to wait for the "nuclear pageflip" to complete after posting the
pageflips to the hw. Otherwise we risk releasing a buffer too early,
and a client might draw into a buffer while it is still being scanned
out.

Note, that this situation is quite different on Linux DRM drivers,
where I think the DRM infrastucture is set up to avoid this race, at
least when only one gfx device is involved. Or so I believe. (Rpi does
not use DRM at all.)

> I believe this is exactly the same problem I am trying to solve. But
> the difference is that I only want to get "woken up the moment it has
> a free buffer" after an event has triggered a redraw. It sounds like
> Tomeu wants to be woken whether or not an event has happened.

What we want is to have at least simple-egl running reliably. It does
not set swapInterval=0, but keeps the default 1. And it uses the frame
callback manually.

Simple-egl renders continuously, and it uses the frame request to
trigger the next repaint. However, due to the above mentioned reason,
the release of the old front buffer happens only some time after the
frame callback event has been sent. That means that simple-egl will try
to repaint, while it still has the old-front kept by the compositor,
and the new-front from the recently completed rendering just committed
to the compositor, and no third buffer to draw into. So it has to wait
for the release event.

The problem is, if the compositor does not flush out the release event
that is sent (queued) when the nuclear pageflip completes, simple-egl
will have to wait until something triggers the flush in the compositor.
Usually that is an input event, that might never come. So, simple-egl
stalls for an indefinite time.

Also, if eglSwapBuffers did a wl_display.sync right after
wl_surface.commit, the compositor will first reply to the sync, then
send the frame callback, and later "send" the release. So that does not
help.

If simple-egl did a wl_display.sync when it gets the frame callback,
the compositor will reply to the sync before the nuclear pageflip
completes and "sends" the release. So that does not help either.

*This* is the problem, once again. Furthermore, even though simple-egl
does use the frame callback to trigger repaint, a game might not do
that itself, but just render in a loop, and we do not want it to stall
indefinitely in that case either. A third case would be swapInterval=0,
but there using 3 buffers is probably justified, because otherwise it
would be no different to swapInterval=1 on Rpi.

Input events are totally uninteresting here, the client could repaint on
any reason.

- pq