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

[Pekka Paalanen]

On Mon, 4 Mar 2013 11:12:23 +0100
John Kåre Alsaker <john.kare.alsaker at gmail.com> wrote:

> On Mon, Mar 4, 2013 at 9:48 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> > 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?
> Yes, that will work exactly the same way.
> 
> >
> > 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.
> That patch waits for the frame callback after it has committed the
> frame instead of before, which reduces input latency.

This, and your reply above are contradictory.

The point is, can the client do any useful work between sending a
frame, and waiting for it to show. Before your changes, eglSwapBuffers
returned, and will wait on the next call, leaving the chance to do work
between sending a buffer and waiting for it to be processed. Therefore,
part of the time that must pass between frames, can be spent on
computing in the client.

If I read your patch 2/4 right, after your changes, you first send a
buffer, commit, and then wait for the frame callback of that commit to
arrive, before returning from eglSwapBuffers. Hence the client is
completely synchronized to and blocked by the server, guaranteeing the
maximal waste of time. If we had only uniprocessor systems, this
would probably not be too bad, since the two processes couldn't run at
the same time anyway.

Also, being blocked inside EGL does not allow any Wayland events, except
those for the EGL itself, to be processed, so there is no escape.

> > 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.
> I don't think that affects this proposal versus eglSwapBuffers.

It affects what happens: does sending the frame callbacks wait for the
compositor's rendering to finish and hit vblank for the flip, or not.
We should keep the whole stack in mind, otherwise we probably overlook
some interactions.

If your tests currently show no bad effects, that may change, if the
frame callback handing in the server is changed. Therefore I would be
very careful before doing any changes to EGL APIs until the server
behaviour has been decided.

Assuming any changes to EGL APIs are possible at all...

> >>  - 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?
> Yeah, you'd need clipping to do that.

How can there be any savings compared to using just one surface for all
decorations? Or what was the motive for 4 sub-surfaces if not saving
buffer space?

> >>  - 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?
> My suggestion there is to have wl_surface.commit commit all child surfaces too.
> Then you can update all surfaces in a group or just sub-surfaces.
> I don't see a need for something more elaborate, but nested
> sub-surface could offer more control.

Ok.


Thanks,
pq