[RFC 0/4] New wayland-egl functions for swapping

[Pekka Paalanen]

On Sun,  3 Mar 2013 02:26:10 +0100
John Kåre Alsaker <john.kare.alsaker at gmail.com> wrote:

> This patchset introduces wl_egl_window_take_buffer and wl_egl_window_commit to the native wayland-egl platform.
> 
> wl_egl_window_take_buffer gives a way to get a wl_buffer from an wl_egl_window.
> The application is expected to attach this to one or multiple wl_surfaces and the EGL implementation
> will listen to it's release event before it reuses the buffer.
> 
> This has a couple of advantages over eglSwapBuffers:
>  - It's always non-blocking, clients doesn't have to ensure swap interval is 0

Where do you synchronize the GPU?
Does wl_egl_window_take_buffer imply a glFinish(), with a real wait for
GPU to finish rendering?

An advantage of eglSwapBuffers, if I understand right, is that it can
schedule a "swap", and return early. The actual wait for GPU to finish
rendering happens in the compositor, when it tries to use the buffer
provided by a client as a texture. Or rather, it might not wait;
instead just queue more rendering commands, and the GPU's pipeline and
hw synchronization primitives will synchronice automatically, without
stalling any process on a CPU.

Can you preserve that with this proposal?

To me it looks like your patch 2/4 explicitly breaks this by waiting
for the frame event right after sending a buffer. The client is forced
to stall, until rendering of *current* frame hits the screen, as
opposed to the rendering of the previous frame.

I'm not familiar enough with the Mesa code to see everything from the
patches.

I think this will also be effected by when does the compositor actually
send frame callback events, on starting repaint as it is now, or when
the frame has actually hit the screen. At least for me that is still an
open question.

>  - Client are in control of the damage, attach and commit requests.
>    I find that to be cleaner and wouldn't require an extension to specify damage.

With the buffer age extension, that makes sense, especially for nested
compositors and other 2D-ish apps.

>  - You can attach a wl_buffer to multiple wl_surfaces.
>    For example you could use a single buffer for 4 window decorations subsurfaces and
>    perhaps even draw decorations with a single draw call.

How do you intend the example would work? Are you assuming something
from scaling & clipping extension?

>  - We can remove the ugly commit mode setting in the subsurfaces proposal.
>    It's no longer required since EGL won't do commit on subsurfaces.

Can you explain why it could be removed? What kind of commit mode would
be the only commit mode then, and how it can a) offer a way for
guarateed atomic update of several sub-surfaces, and b) allow a
sub-surface to be updated without a parent surface commit when wanted?

> wl_egl_window_commit will commit the surface and use EGL's policy regarding waiting on frames.

If wl_egl_window_commit is going to commit and block until the frame
has been displayed, I think the function name is misleading as "commit"
is usually just a kick here, not a roundtrip. Perhaps a different verb
would be in place.

> wl_egl_window_take_buffer followed by wl_egl_window_commit is equivalent to eglSwapBuffers
> only that you can specify damage without an extensions. It's more of a natural complement of
> wl_egl_window_take_buffer than a required function.
> 


Thanks,
pq