On Sun, 3 Mar 2013 02:26:10 +0100 John Kåre Alsaker <[email protected]> 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 _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
