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

[John Kåre Alsaker]

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.

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

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

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

>
>> 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.
I don't think it's more misleading than SwapBuffers. The only thing
it's required to do is call wl_surface.commit
and wait n frames depending on EGL's configuration. We may also drop
this function since it's only intended for games,
which won't do much damage tracking anyway. Games may still use
wl_egl_window_take_buffer for subsurface decorations
followed by eglSwapBuffers which commits all of the surfaces with my
suggested commit scheme.

>
>> 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