Re: [PATCH wayland-protocols v7] Add zwp_linux_explicit_synchronization_v1
Hi Jason, I use it in Broadcom EGL and Vulkan WSI implementations and "It Just Works (TM)". I've asked to include the opaque EGL buffers as a valid type of buffer that can be explicitly synchronised and this change was merged too, quite some time ago. Weston 6.0.0 definitely has it, not sure about earlier version. Cheers, Tomek On Tue, 4 Feb 2020 at 05:27, Jason Ekstrand wrote: > Sorry to drag up ancient threads, but what's the status of this? I see > rumors that it's in Weston. Is it stable? Is it implemented anywhere > else? It'd be great, for the sake of Vulkan, if we could get this stable > and everywhere. > > --Jason > > On Mon, Dec 17, 2018 at 11:25 AM Tomek Bury wrote: > >> Thanks! That looks better than my patch. >> >> On Mon, 17 Dec 2018 at 15:37, Alexandros Frantzis < >> alexandros.frant...@collabora.com> wrote: >> >>> On Monday, December 17, 2018 12:44 GMT, Tomek Bury >>> wrote: >>> > On Wed, 28 Nov 2018 at 14:35, Tomek Bury wrote: >>> > > Hi Pekka, >>> > > >>> > > > I suppose the compositor-side copy of buffers you mentioned is for >>> the >>> > > > lack of release fences, not acquire fences? >>> > > Yes, the lack of release fences is the very reason for the copy. I >>> could >>> > > cook something up for the acquire fence, but that wouldn't >>> synchronise the >>> > > buffer access anyway. The only way I can be sure the client doesn't >>> > > overwrite a buffer still in use by the GPU was to texture from a >>> copy and >>> > > let the compositor release the original without waiting for the GPU >>> and >>> > > without a fence. >>> > > >>> > > Cheers, >>> > > Tomek >>> > > >>> > Hi Pekka, Alexandros, >>> > >>> > Here's a patch containing all I had to do in order to test the explicit >>> > sync support Alexandros has implemented in Weston. >>> > >>> > Thanks, >>> > Tomek >>> >>> Hi Tomek, >>> >>> I have now updated the weston explicit-sync gitlab MR [1] to support, >>> among other things, minor version 2 of the protocol. Instead of >>> completely removing the checks, I have updated them to check for and >>> accept all non-SHM buffers, which is adequate for current needs. There >>> are other ways to deal with these checks if we think we need a more >>> versatile approach (e.g., asking the renderer to tell us if it support >>> fences >>> for a particular buffer). Please see the MR comments for more info and >>> discussion. >>> >>> Thanks, >>> Alexandros >>> >>> [1] https://gitlab.freedesktop.org/wayland/weston/merge_requests/32 >>> >>> ___ >> wayland-devel mailing list >> wayland-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/wayland-devel >> > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v7] Add zwp_linux_explicit_synchronization_v1
On 4/02/20 10:16 pm, Pekka Paalanen wrote: On Mon, 3 Feb 2020 23:26:55 -0600 Jason Ekstrand wrote: Sorry to drag up ancient threads, but what's the status of this? I see rumors that it's in Weston. Is it stable? Is it implemented anywhere else? It'd be great, for the sake of Vulkan, if we could get this stable and everywhere. --Jason On Mon, Dec 17, 2018 at 11:25 AM Tomek Bury wrote: Thanks! That looks better than my patch. On Mon, 17 Dec 2018 at 15:37, Alexandros Frantzis < alexandros.frant...@collabora.com> wrote: [1] https://gitlab.freedesktop.org/wayland/weston/merge_requests/32 Hi, the above MR is merged, the code is in Weston and is supposed to work. I have a vague recollection that the implementation might not be "totally optimal" in all cases, meaning that it may choose to deliver `immediate_release` rather than `fenced_release` even if the latter was theoretically possible. I don't know about other compositors, we don't have the extension information site up yet. The protocol itself is in unstable: https://gitlab.freedesktop.org/wayland/wayland-protocols/tree/master/unstable/linux-explicit-synchronization This does not mean that we can break it at will. The committed protocol is stable in the sense that we cannot break it anymoe, but unstable in the sense that zwp_linux_explicit_synchronization_v1 is not the final name. IOW, it is safe to look for Wayland extension zwp_linux_explicit_synchronization_v1 and use it. If we need changes that cannot be made backward-compatible, a new extension with name zwp_linux_explicit_synchronization_v2 will be created. Once we are sure we do not need backward-incompatible changes anymore, the extension will be renamed to wp_linux_explicit_synchronization which will be the final change that all servers and clients should very much implement. Both compositors and clients are encouraged to implement all major versions of the extension if possible for maximum compatibility. TL;DR: If you find a Wayland compositor advertising zwp_linux_explicit_synchronization_v1 via wl_registry, feel free to use it and expect it to not break from under you. Thanks, pq Just as a follow up, I plan to add support in wlroots. I want to go with a much more elaborate implementation than Weston's one, which changes some of our fundamental assumptions about surface state, and requires a lot of changes, which is why it has been slow to get implemented. I have a description about it here [1] that other compositors might be interested in. Scott [1]: https://github.com/swaywm/wlroots/issues/894#issuecomment-465096345 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v7] Add zwp_linux_explicit_synchronization_v1
On Mon, 3 Feb 2020 23:26:55 -0600 Jason Ekstrand wrote: > Sorry to drag up ancient threads, but what's the status of this? I see > rumors that it's in Weston. Is it stable? Is it implemented anywhere > else? It'd be great, for the sake of Vulkan, if we could get this stable > and everywhere. > > --Jason > > On Mon, Dec 17, 2018 at 11:25 AM Tomek Bury wrote: > > > Thanks! That looks better than my patch. > > > > On Mon, 17 Dec 2018 at 15:37, Alexandros Frantzis < > > alexandros.frant...@collabora.com> wrote: > >> [1] https://gitlab.freedesktop.org/wayland/weston/merge_requests/32 Hi, the above MR is merged, the code is in Weston and is supposed to work. I have a vague recollection that the implementation might not be "totally optimal" in all cases, meaning that it may choose to deliver `immediate_release` rather than `fenced_release` even if the latter was theoretically possible. I don't know about other compositors, we don't have the extension information site up yet. The protocol itself is in unstable: https://gitlab.freedesktop.org/wayland/wayland-protocols/tree/master/unstable/linux-explicit-synchronization This does not mean that we can break it at will. The committed protocol is stable in the sense that we cannot break it anymoe, but unstable in the sense that zwp_linux_explicit_synchronization_v1 is not the final name. IOW, it is safe to look for Wayland extension zwp_linux_explicit_synchronization_v1 and use it. If we need changes that cannot be made backward-compatible, a new extension with name zwp_linux_explicit_synchronization_v2 will be created. Once we are sure we do not need backward-incompatible changes anymore, the extension will be renamed to wp_linux_explicit_synchronization which will be the final change that all servers and clients should very much implement. Both compositors and clients are encouraged to implement all major versions of the extension if possible for maximum compatibility. TL;DR: If you find a Wayland compositor advertising zwp_linux_explicit_synchronization_v1 via wl_registry, feel free to use it and expect it to not break from under you. Thanks, pq pgpOReqHfDL0S.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v7] Add zwp_linux_explicit_synchronization_v1
Sorry to drag up ancient threads, but what's the status of this? I see rumors that it's in Weston. Is it stable? Is it implemented anywhere else? It'd be great, for the sake of Vulkan, if we could get this stable and everywhere. --Jason On Mon, Dec 17, 2018 at 11:25 AM Tomek Bury wrote: > Thanks! That looks better than my patch. > > On Mon, 17 Dec 2018 at 15:37, Alexandros Frantzis < > alexandros.frant...@collabora.com> wrote: > >> On Monday, December 17, 2018 12:44 GMT, Tomek Bury >> wrote: >> > On Wed, 28 Nov 2018 at 14:35, Tomek Bury wrote: >> > > Hi Pekka, >> > > >> > > > I suppose the compositor-side copy of buffers you mentioned is for >> the >> > > > lack of release fences, not acquire fences? >> > > Yes, the lack of release fences is the very reason for the copy. I >> could >> > > cook something up for the acquire fence, but that wouldn't >> synchronise the >> > > buffer access anyway. The only way I can be sure the client doesn't >> > > overwrite a buffer still in use by the GPU was to texture from a copy >> and >> > > let the compositor release the original without waiting for the GPU >> and >> > > without a fence. >> > > >> > > Cheers, >> > > Tomek >> > > >> > Hi Pekka, Alexandros, >> > >> > Here's a patch containing all I had to do in order to test the explicit >> > sync support Alexandros has implemented in Weston. >> > >> > Thanks, >> > Tomek >> >> Hi Tomek, >> >> I have now updated the weston explicit-sync gitlab MR [1] to support, >> among other things, minor version 2 of the protocol. Instead of >> completely removing the checks, I have updated them to check for and >> accept all non-SHM buffers, which is adequate for current needs. There >> are other ways to deal with these checks if we think we need a more >> versatile approach (e.g., asking the renderer to tell us if it support >> fences >> for a particular buffer). Please see the MR comments for more info and >> discussion. >> >> Thanks, >> Alexandros >> >> [1] https://gitlab.freedesktop.org/wayland/weston/merge_requests/32 >> >> ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v7] Add zwp_linux_explicit_synchronization_v1
Thanks! That looks better than my patch. On Mon, 17 Dec 2018 at 15:37, Alexandros Frantzis < alexandros.frant...@collabora.com> wrote: > On Monday, December 17, 2018 12:44 GMT, Tomek Bury > wrote: > > On Wed, 28 Nov 2018 at 14:35, Tomek Bury wrote: > > > Hi Pekka, > > > > > > > I suppose the compositor-side copy of buffers you mentioned is for > the > > > > lack of release fences, not acquire fences? > > > Yes, the lack of release fences is the very reason for the copy. I > could > > > cook something up for the acquire fence, but that wouldn't synchronise > the > > > buffer access anyway. The only way I can be sure the client doesn't > > > overwrite a buffer still in use by the GPU was to texture from a copy > and > > > let the compositor release the original without waiting for the GPU and > > > without a fence. > > > > > > Cheers, > > > Tomek > > > > > Hi Pekka, Alexandros, > > > > Here's a patch containing all I had to do in order to test the explicit > > sync support Alexandros has implemented in Weston. > > > > Thanks, > > Tomek > > Hi Tomek, > > I have now updated the weston explicit-sync gitlab MR [1] to support, > among other things, minor version 2 of the protocol. Instead of > completely removing the checks, I have updated them to check for and > accept all non-SHM buffers, which is adequate for current needs. There > are other ways to deal with these checks if we think we need a more > versatile approach (e.g., asking the renderer to tell us if it support > fences > for a particular buffer). Please see the MR comments for more info and > discussion. > > Thanks, > Alexandros > > [1] https://gitlab.freedesktop.org/wayland/weston/merge_requests/32 > > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v7] Add zwp_linux_explicit_synchronization_v1
On Monday, December 17, 2018 12:44 GMT, Tomek Bury wrote: > On Wed, 28 Nov 2018 at 14:35, Tomek Bury wrote: > > Hi Pekka, > > > > > I suppose the compositor-side copy of buffers you mentioned is for the > > > lack of release fences, not acquire fences? > > Yes, the lack of release fences is the very reason for the copy. I could > > cook something up for the acquire fence, but that wouldn't synchronise the > > buffer access anyway. The only way I can be sure the client doesn't > > overwrite a buffer still in use by the GPU was to texture from a copy and > > let the compositor release the original without waiting for the GPU and > > without a fence. > > > > Cheers, > > Tomek > > > Hi Pekka, Alexandros, > > Here's a patch containing all I had to do in order to test the explicit > sync support Alexandros has implemented in Weston. > > Thanks, > Tomek Hi Tomek, I have now updated the weston explicit-sync gitlab MR [1] to support, among other things, minor version 2 of the protocol. Instead of completely removing the checks, I have updated them to check for and accept all non-SHM buffers, which is adequate for current needs. There are other ways to deal with these checks if we think we need a more versatile approach (e.g., asking the renderer to tell us if it support fences for a particular buffer). Please see the MR comments for more info and discussion. Thanks, Alexandros [1] https://gitlab.freedesktop.org/wayland/weston/merge_requests/32 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v7] Add zwp_linux_explicit_synchronization_v1
Hi Pekka, Alexandros,
Here's a patch containing all I had to do in order to test the explicit
sync support Alexandros has implemented in Weston.
Thanks,
Tomek
On Wed, 28 Nov 2018 at 14:35, Tomek Bury wrote:
> Hi Pekka,
>
> > I suppose the compositor-side copy of buffers you mentioned is for the
> > lack of release fences, not acquire fences?
> Yes, the lack of release fences is the very reason for the copy. I could
> cook something up for the acquire fence, but that wouldn't synchronise the
> buffer access anyway. The only way I can be sure the client doesn't
> overwrite a buffer still in use by the GPU was to texture from a copy and
> let the compositor release the original without waiting for the GPU and
> without a fence.
>
> Cheers,
> Tomek
>
>
From ee74382c9a9b04c0fd7ca30bee9a3b98a314e942 Mon Sep 17 00:00:00 2001
From: Tomek Bury
Date: Mon, 17 Dec 2018 12:33:07 +
Subject: [PATCH] clients: Support explicit synchronization in opaque EGL
buffers
Signed-off-by: Tomek Bury
---
libweston/compositor.c | 9 -
libweston/gl-renderer.c | 3 ---
2 files changed, 12 deletions(-)
diff --git a/libweston/compositor.c b/libweston/compositor.c
index d939b833..d6860362 100644
--- a/libweston/compositor.c
+++ b/libweston/compositor.c
@@ -3418,15 +3418,6 @@ surface_commit(struct wl_client *client, struct wl_resource *resource)
wl_resource_get_id(resource));
return;
}
-
- if (!linux_dmabuf_buffer_get(surface->pending.buffer->resource)) {
- fd_clear(>pending.acquire_fence_fd);
- wl_resource_post_error(surface->synchronization_resource,
-ZWP_LINUX_SURFACE_SYNCHRONIZATION_V1_ERROR_UNSUPPORTED_BUFFER,
-"wl_surface@%"PRIu32" unsupported buffer for synchronization",
-wl_resource_get_id(resource));
- return;
- }
}
if (surface->pending.buffer_release_ref.buffer_release &&
diff --git a/libweston/gl-renderer.c b/libweston/gl-renderer.c
index 18858949..ac490322 100644
--- a/libweston/gl-renderer.c
+++ b/libweston/gl-renderer.c
@@ -895,9 +895,6 @@ ensure_surface_buffer_is_ready(struct gl_renderer *gr,
/* We should only get a fence if we support EGLSyncKHR, since
* we don't advertise the explicit sync protocol otherwise. */
assert(gr->has_native_fence_sync);
- /* We should only get a fence for zwp_linux_dmabuf buffers, since
- * surface commit would have failed otherwise. */
- assert(linux_dmabuf_buffer_get(buffer->resource) != NULL);
attribs[1] = dup(surface->acquire_fence_fd);
if (attribs[1] == -1) {
--
2.17.1
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v7] Add zwp_linux_explicit_synchronization_v1
Hi Pekka, > I suppose the compositor-side copy of buffers you mentioned is for the > lack of release fences, not acquire fences? Yes, the lack of release fences is the very reason for the copy. I could cook something up for the acquire fence, but that wouldn't synchronise the buffer access anyway. The only way I can be sure the client doesn't overwrite a buffer still in use by the GPU was to texture from a copy and let the compositor release the original without waiting for the GPU and without a fence. Cheers, Tomek ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v7] Add zwp_linux_explicit_synchronization_v1
On Tue, 27 Nov 2018 18:25:04 +0200 Alexandros Frantzis wrote: > On Tue, Nov 27, 2018 at 05:17:40PM +0200, Alexandros Frantzis wrote: > > On Tue, Nov 27, 2018 at 10:53:45AM +0200, Pekka Paalanen wrote: > > > Yes, we probably should have some wording that if a client is letting > > > something like EGL to commit the buffers, it must not attempt to use > > > the fence extension on that wl_surface itself because EGL will probably > > > be using the extension already. > > > > > > Alf? > > > > Hi Pekka and Tomek, > > > > I will send a patch with a proposal for the discussed wording updates to > > the list soon (probably tomorrow). > > > > I agree it's fine for the spec to be relaxed for the opaque EGL buffers. > > As Pekka mentioned, we explicitly limited the spec to support only > > zwp_linux_dmabuf to avoid the problem of having to deal with unsupported > > buffer/fence combinations, and opaque EGL buffers are not likely to pose > > problems in this regard. > > Note that this will require a v2 of this protocol since we will be > requiring more from implementations compared to v1 (unless we can cheat > and not bump?). The current protocol says: It's not a backwards incompatible change, so I think there is no need for a major bump. You can do a minor bump if you want, it would be strictly correct. > > "Explicit synchronization is guaranteed to be supported only for buffers > > created with any version of the wp_linux_dmabuf buffer factory." > > which upon rereading isn't clear enough about if implementations are > required to support *only* linux_dmabuf, or if implementations need > to support *at least* linux_dmabuf. I think the "guaranteed" makes it "at least". > > If we don't want to commit to general opaque EGL buffer support, > perhaps an option here would be to change this to the more clear: > > "Explicit synchronization is only guaranteed to be supported for buffers > > created with any version of the wp_linux_dmabuf buffer factory, but > implementations are free to also support it for other buffer types." > > This allows us to stay at v1 without explicitly naming out opaque EGL > buffers, while still allowing Weston to support opaque EGL buffers. It would not help clients to know what they can use though. It would leave them in the dark even after the protocol was stabilized. The fence support for opaque EGL buffers depends on the compositor implementation, not on EGL implementation. So it varies across compositors even on the same platform or system. > > I guess it depends if we think the explicit sync + opaque EGL buffer > case will be interesting enough to be used outside of environments with > a controlled compositor and clients. I believe it is. Thanks, pq pgpKWNgZrznqp.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v7] Add zwp_linux_explicit_synchronization_v1
On Tue, 27 Nov 2018 14:57:07 + Tomek Bury wrote: > Hi Pekka, > > I'm just trying to figure out how to use this extension in a driver. > Without this extension the only option I have is to take a copy if each > wl_buffer on the compositor-side. I can't really do implicit sync so I'm > really happy with anything that allows for explicit sync. Ah, ok. So for both acquire and release fences: In your client-side implementation of EGL or Vulkan, in the case where you, the implementation, will be calling wl_surface.attach and wl_surface.commit, you will be the exclusive user of the explicit sync extension on that wl_surface. Go wild. :-) If the sync extension is not available from the compositor, then you have to do without on the client-side. In the server-side implementation, you don't need to do anything. The compositor will implement the explicit sync protocol and translate it into EGL etc. calls. I suppose in the server-side implementation you *cannot* do anything unless you can infer whether the compositor is actually supporting the explicit sync extension or not. > > Is it possible to have some variant of glTexImage2D wait for an EGLSync > > before it actually reads from the source? > I don't think so. The glTexImage2D mustn't hold onto any client pointers. > GLES3 buffers require mmap and CPU copy. Pixmaps are unsupported so EGL > images are the only remaining thing I can think of. > > > It would be enough for the fence spec to > > define what "opaque EGL buffer" is and then say that they also work in > > addition to zwp_linux_dmabuf buffers. > Yup, that works for me. > > > If a client wants to, it could start with wl_shm and CPU-rendered > > content, then switch to EGL managed surface, then shut down EGL and > > switch back to wl_shm all on the very same wl_surface, for example. > Hmmm, perhaps the set_acquire_fence() should be a buffer operation, not a > surface operation then? What you wrote means to me that the compositor > knows of every buffer the client created but doesn't know which buffer the > client is going to attach next. The earliest moment the compositor learns > about the buffer for the next frame is when the attach request reaches the > compositor. And that would be most likely after the attach/damage/commit > gets flushed at the end of frame by the client. But that's a battle for > another day. Correct, the compositor cannot know which buffer a client might attach to which surface at any time. There is absolutely no connection between which buffer goes with which surface, there has never been, and from protocol perspective clients could use the same buffer on multiple surfaces too. For technical reasons, we cannot add any wl_buffer requests or events. It would have to be done with another interface that takes the wl_buffer as an argument. I guess that would be possible, but I'm not sure what the difference would be. Your EGL implementation cannot expose the same interface as the compositor does for dmabufs. So you would have buffer-type specific interfaces for adding acquire fences. Maybe that's not actually a bad idea, given that the acquire fences are so closely related to buffer types. It would also allow to split the release event and fence into their own extension, to be shared across all buffer types including wl_shm. OTOH, it's more typing to implement. If we did the buffer-type specific explicit sync interfaces design, then a compositor itself would implement set_acquire_fence for dmabufs, and a compositor-side EGL implementation could implement set_acquire_fence for opaque EGL buffers which would be proprietary to the EGL implementation, but that is ok because the client-side of the same is too. In fact, you could have implemented an explicit sync extension for acquire fences inside your EGL implementation since day one. It is just the release fence side which probably wouldn't work out too well as hidden inside EGL. I suppose the compositor-side copy of buffers you mentioned is for the lack of release fences, not acquire fences? Thanks, pq pgplIVBgjyt0p.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v7] Add zwp_linux_explicit_synchronization_v1
On Tue, Nov 27, 2018 at 05:17:40PM +0200, Alexandros Frantzis wrote: > On Tue, Nov 27, 2018 at 10:53:45AM +0200, Pekka Paalanen wrote: > > Yes, we probably should have some wording that if a client is letting > > something like EGL to commit the buffers, it must not attempt to use > > the fence extension on that wl_surface itself because EGL will probably > > be using the extension already. > > > > Alf? > > Hi Pekka and Tomek, > > I will send a patch with a proposal for the discussed wording updates to > the list soon (probably tomorrow). > > I agree it's fine for the spec to be relaxed for the opaque EGL buffers. > As Pekka mentioned, we explicitly limited the spec to support only > zwp_linux_dmabuf to avoid the problem of having to deal with unsupported > buffer/fence combinations, and opaque EGL buffers are not likely to pose > problems in this regard. Note that this will require a v2 of this protocol since we will be requiring more from implementations compared to v1 (unless we can cheat and not bump?). The current protocol says: "Explicit synchronization is guaranteed to be supported only for buffers created with any version of the wp_linux_dmabuf buffer factory." which upon rereading isn't clear enough about if implementations are required to support *only* linux_dmabuf, or if implementations need to support *at least* linux_dmabuf. If we don't want to commit to general opaque EGL buffer support, perhaps an option here would be to change this to the more clear: "Explicit synchronization is only guaranteed to be supported for buffers created with any version of the wp_linux_dmabuf buffer factory, but implementations are free to also support it for other buffer types." This allows us to stay at v1 without explicitly naming out opaque EGL buffers, while still allowing Weston to support opaque EGL buffers. I guess it depends if we think the explicit sync + opaque EGL buffer case will be interesting enough to be used outside of environments with a controlled compositor and clients. Thanks, Alexandros ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v7] Add zwp_linux_explicit_synchronization_v1
On Tue, Nov 27, 2018 at 10:53:45AM +0200, Pekka Paalanen wrote:
> Yes, we probably should have some wording that if a client is letting
> something like EGL to commit the buffers, it must not attempt to use
> the fence extension on that wl_surface itself because EGL will probably
> be using the extension already.
>
> Alf?
Hi Pekka and Tomek,
I will send a patch with a proposal for the discussed wording updates to
the list soon (probably tomorrow).
I agree it's fine for the spec to be relaxed for the opaque EGL buffers.
As Pekka mentioned, we explicitly limited the spec to support only
zwp_linux_dmabuf to avoid the problem of having to deal with unsupported
buffer/fence combinations, and opaque EGL buffers are not likely to pose
problems in this regard.
In practice we can probably support all buffers that can be imported
into the graphics API without requiring a client-side wait in the
compositor ("client" from a graphics API perspective) for proper use,
but that's harder to specify. There were discussions about allowing
everything other than wl_shm, but we decided against it, since that
would make the protocol too fragile.
Relaxing the spec further will probably require more radical changes,
though, e.g., advertising supported buffer types, or similar.
I will also add some notes/warnings about using this protocol with
graphics APIs that handle buffers internally.
This is also a good chance to propose some other clarifications to the
spec I have been thinking about.
Thanks,
Alexandros
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v7] Add zwp_linux_explicit_synchronization_v1
Hi Pekka, > I suppose that applies to the opaque EGL buffers only? Sort of. As far as I understand it, the divide is between wl_surface managed by EGL/WSI vs. wl_surface managed directly by the client application. For EGL case the wl_surface managed by EGL would be set-up more or less like this: struct wl_egl_window *window = wl_egl_window_create(surface, w, h); EGLDisplay dpy = eglGetPlatformDisplay(EGL_PLATFORM_WAYLAND_EXT, ...); EGLSurface surface = eglCreatePlatformWindowSurface(dpy, config, window); With this setup EGL becomes responsible for managing the swapchain buffers, keeping up with window resizes, sending wl_buffers to compositor when client app calls eglSwapBuffers() etc. This is how weston-simple-egl works. > Otherwise, a client could use e.g. EGL in a different way to get dmabuf, > send those manually to the compositor and set up fences manually as > well. weston-simple-dmabuf-egl in the MR is one variant of that. Of > course, it depends on the EGL stack supporting dmabuf to begin with, so > if yours doesn't then it's not possible. Yes, exactly. This is the example where the application manages the Wayland window directly and the EGL driver is not involved. EGL is only used to set up rendering into an off-screen buffer(s) of some description. In both cases the compositor receives a wl_buffer and has to figure out how to render the contents of such buffer. In both cases the wl_buffer could encapsulate dma-buf and the compositor wouldn't be able to tell whether it came directly from application (weston-simple-dmabuf-egl) or from the EGL driver (weston-simple-egl). in fact the Waylad client could choose dma-buf, prime, flink, shm, something else, regardless of how the wl_surface is managed, whether it's done directly by the application, by the EGL or Vulkan driver. And some of those wl_buffer types will be known to the compositor, some to the 3D driver and perhaps some to both. At least that's my understanding. Cheers, Tomek On Tue, 27 Nov 2018 at 08:53, Pekka Paalanen wrote: > On Mon, 26 Nov 2018 15:14:45 + > Tomek Bury wrote: > > > Hi Pekka, > > > > Yes, sorry, I was writing specifically about Weston implementation. In > the > > merge request from Alexandros the actual compatibility check is in the > main > > compositor, while compositor doesn't have enough information to decide > > whether the selected renderer can handle buffer+fence combination or not. > > > > As for the opaque wl_buffer, that's an internal implementation detail of > > Vulkan WSI or EGL so different drivers can choose to do different things > > here. It's the 3D driver, and *NOT* the client application, that creates > > those buffers and sends attach/damage/commit sequence to the compositor. > > The 3D driver makes a decision what type of buffer to use, an EGL or > Vulkan > > client application doesn't have any means of accessing wl_buffer objects, > > it's all hidden away. > > Hi Tomek, > > I suppose that applies to the opaque EGL buffers only? > > Otherwise, a client could use e.g. EGL in a different way to get dmabuf, > send those manually to the compositor and set up fences manually as > well. weston-simple-dmabuf-egl in the MR is one variant of that. Of > course, it depends on the EGL stack supporting dmabuf to begin with, so > if yours doesn't then it's not possible. > > However, in the fence protocol extension specification we must take all > possible use cases into account. The client side of the fence extension > is not exclusive to EGL implementations, and the server side is even > less, because the server side implementation cannot be an EGL > implementation detail. > > This is why I'm talking about protocol spec - the Weston implementation > just reflects the spec, or at least attempts to. > > > On the compositor side buffers are received through one of the protocol > > extensions you've mentioned. The compositor has a choice to make. It can > > either probe the wl_buffer for known buffer types or leave that task to > the > > EGL implementation. Let's say a client-side driver uses dma-buf buffers > for > > its swapchain images. If the compositor knows how to handle dma-buf, it > can > > either directly access those buffers or it can hand them over to the > > compositor-side 3D driver through > > eglCreateImage(dpy, EGL_LINUX_DMA_BUF_EXT, ...). If the compositor > doesn't > > know the particular type of buffer, it can check if EGL can handle it > > either through eglCreateImage(dpy, EGL_WAYLAND_BUFFER_WL, ...) or > > eglQueryWaylandBufferWL(...). > > If the client and compositor use the same 3D driver (that's the most > likely > > scenario) this is bound to work. In multiple-GPU configurations your > > mileage may vary though. > > Right. > > A wl_buffer can be used with either EGL_WAYLAND_BUFFER_WL or as a > dmabuf via EGL_LINUX_DMA_BUF, but there is no choice for a compositor > to make as at most only one these can work for a given wl_buffer. > > > If the EGL implementation can use the type
Re: [PATCH wayland-protocols v7] Add zwp_linux_explicit_synchronization_v1
On Mon, 26 Nov 2018 15:14:45 + Tomek Bury wrote: > Hi Pekka, > > Yes, sorry, I was writing specifically about Weston implementation. In the > merge request from Alexandros the actual compatibility check is in the main > compositor, while compositor doesn't have enough information to decide > whether the selected renderer can handle buffer+fence combination or not. > > As for the opaque wl_buffer, that's an internal implementation detail of > Vulkan WSI or EGL so different drivers can choose to do different things > here. It's the 3D driver, and *NOT* the client application, that creates > those buffers and sends attach/damage/commit sequence to the compositor. > The 3D driver makes a decision what type of buffer to use, an EGL or Vulkan > client application doesn't have any means of accessing wl_buffer objects, > it's all hidden away. Hi Tomek, I suppose that applies to the opaque EGL buffers only? Otherwise, a client could use e.g. EGL in a different way to get dmabuf, send those manually to the compositor and set up fences manually as well. weston-simple-dmabuf-egl in the MR is one variant of that. Of course, it depends on the EGL stack supporting dmabuf to begin with, so if yours doesn't then it's not possible. However, in the fence protocol extension specification we must take all possible use cases into account. The client side of the fence extension is not exclusive to EGL implementations, and the server side is even less, because the server side implementation cannot be an EGL implementation detail. This is why I'm talking about protocol spec - the Weston implementation just reflects the spec, or at least attempts to. > On the compositor side buffers are received through one of the protocol > extensions you've mentioned. The compositor has a choice to make. It can > either probe the wl_buffer for known buffer types or leave that task to the > EGL implementation. Let's say a client-side driver uses dma-buf buffers for > its swapchain images. If the compositor knows how to handle dma-buf, it can > either directly access those buffers or it can hand them over to the > compositor-side 3D driver through > eglCreateImage(dpy, EGL_LINUX_DMA_BUF_EXT, ...). If the compositor doesn't > know the particular type of buffer, it can check if EGL can handle it > either through eglCreateImage(dpy, EGL_WAYLAND_BUFFER_WL, ...) or > eglQueryWaylandBufferWL(...). > If the client and compositor use the same 3D driver (that's the most likely > scenario) this is bound to work. In multiple-GPU configurations your > mileage may vary though. Right. A wl_buffer can be used with either EGL_WAYLAND_BUFFER_WL or as a dmabuf via EGL_LINUX_DMA_BUF, but there is no choice for a compositor to make as at most only one these can work for a given wl_buffer. > If the EGL implementation can use the type of the wl_buffer and can import > the fence fd, you're home. Having said that, I can't think of a way of > figuring out ahead of time what type of wl_buffer the client-side driver is > going to use for its swapchain and whether this particular type will be > accepted by the compositor-side driver. There is no need for the compositor to know in advance. Instead, the client must know what the compositor supports, since the client is making the decisions on buffer allocation etc. (or the decision to use EGL or Vulkan and not care about buffers explicitly, in which case the EGL/WSI implementation must know). The opaque EGL buffers already rely on using the same EGL implementation on both compositor and client, so if a compositor also exposes the fence extension, the client-side EGL implementation can be sure it can use the fence extension with the opaque EGL buffers (or if it cannot, the client-side EGL implementation already knows that because it knows the details of the compositor-side EGL implementation). That is, if we write that down in the fence extension spec. I think we should. > This is how I use it at the moment: I've written a custom Weston backend > because the code runs on top of an embedded middleware. My backend always > uses GL renderer. The GL renderer has to call eglBindWaylandDisplayWL() at > startup, and the implementation of that API in the 3D driver adds a custom > Wayland protocol extension for sharing buffers. Now the scene is set. When > a Wayland client application starts, the EGL or Vulkan WSI implementation > driver goes for that extension and bails out if unavailable. This way > swapchain buffers from EGL and Vulkan client can be used by Weston's GL > renderer without any knowledge of the embedded platform details. Yup, that is how the "opaque EGL buffer" type is supposed to work. > With regards to using fences directly by the client app, I guess it's the > same principle as drawing into the window. Either client app does > everything "by hand" or lets the Vulkan or EGL/GLES do it. If the app is in > charge, the app manages the window swap chain buffers and synchronization, > otherwise the
Re: [PATCH wayland-protocols v7] Add zwp_linux_explicit_synchronization_v1
Hi Pekka, Yes, sorry, I was writing specifically about Weston implementation. In the merge request from Alexandros the actual compatibility check is in the main compositor, while compositor doesn't have enough information to decide whether the selected renderer can handle buffer+fence combination or not. As for the opaque wl_buffer, that's an internal implementation detail of Vulkan WSI or EGL so different drivers can choose to do different things here. It's the 3D driver, and *NOT* the client application, that creates those buffers and sends attach/damage/commit sequence to the compositor. The 3D driver makes a decision what type of buffer to use, an EGL or Vulkan client application doesn't have any means of accessing wl_buffer objects, it's all hidden away. On the compositor side buffers are received through one of the protocol extensions you've mentioned. The compositor has a choice to make. It can either probe the wl_buffer for known buffer types or leave that task to the EGL implementation. Let's say a client-side driver uses dma-buf buffers for its swapchain images. If the compositor knows how to handle dma-buf, it can either directly access those buffers or it can hand them over to the compositor-side 3D driver through eglCreateImage(dpy, EGL_LINUX_DMA_BUF_EXT, ...). If the compositor doesn't know the particular type of buffer, it can check if EGL can handle it either through eglCreateImage(dpy, EGL_WAYLAND_BUFFER_WL, ...) or eglQueryWaylandBufferWL(...). If the client and compositor use the same 3D driver (that's the most likely scenario) this is bound to work. In multiple-GPU configurations your mileage may vary though. If the EGL implementation can use the type of the wl_buffer and can import the fence fd, you're home. Having said that, I can't think of a way of figuring out ahead of time what type of wl_buffer the client-side driver is going to use for its swapchain and whether this particular type will be accepted by the compositor-side driver. This is how I use it at the moment: I've written a custom Weston backend because the code runs on top of an embedded middleware. My backend always uses GL renderer. The GL renderer has to call eglBindWaylandDisplayWL() at startup, and the implementation of that API in the 3D driver adds a custom Wayland protocol extension for sharing buffers. Now the scene is set. When a Wayland client application starts, the EGL or Vulkan WSI implementation driver goes for that extension and bails out if unavailable. This way swapchain buffers from EGL and Vulkan client can be used by Weston's GL renderer without any knowledge of the embedded platform details. With regards to using fences directly by the client app, I guess it's the same principle as drawing into the window. Either client app does everything "by hand" or lets the Vulkan or EGL/GLES do it. If the app is in charge, the app manages the window swap chain buffers and synchronization, otherwise the 3D driver does it. You shouldn't allow more than one thing managing the Wayland window at the same time. Perhaps you could use wording similar to Vulkan WSI or EGL window surface when describing what is and what isn't allowed when it comes to Wayland windows. Cheers, Tomek On Mon, 26 Nov 2018 at 09:22, Pekka Paalanen wrote: > On Fri, 23 Nov 2018 16:26:19 + > Tomek Bury wrote: > > > Hi Pekka, > > > > > I presume you have a driver stack that relies on the opaque EGL > buffers > > and not zwp_linux_dmabuf any time soon? > > Yes, exactly. I've added a protocol extension for sharing those buffers > and > > our eglCreateImage() implementation can import such buffers into the > driver > > on the compositor end. The buffers are carried by an fd to the compositor > > that's the only similarity. They're not dma-buf. > > > > > Yeah, support for opaque EGL buffers could be added, just need to > think > > of a good wording, since acquire fences do not make sense for all buffer > > types. > > > Isn't that renderer's and/or backend's decision? The GL renderer can > accept > > fence with any buffer it can send to the 3D driver, so, effectively, > > anything backed by available EGL image extensions. Someone may add a > custom > > backend and/or renderer using whatever hardware or API they have at > hand. A > > Vulkan renderer could potentially use fences with anything a Vulkan > driver > > is capable of importing. A renderer that does the CPU wait could be > useful > > at least for debugging. So I wouln't block the explicit sync at the > > compositor level based on the white list. > > Hi Tomek, > > fences do not make sense to all buffer types to begin with, today. My > objection is to allowing fencing buffer types that cannot be sent to > the 3D driver, e.g. wl_shm which is usually copied through glTexImage2D > and friends. We cannot ignore those in the spec language. > > A renderer (a compositor really, we're not talking about just Weston) > decides what buffer types it accepts, yes. This is communicated to >
Re: [PATCH wayland-protocols v7] Add zwp_linux_explicit_synchronization_v1
On Fri, 23 Nov 2018 16:26:19 + Tomek Bury wrote: > Hi Pekka, > > > I presume you have a driver stack that relies on the opaque EGL buffers > and not zwp_linux_dmabuf any time soon? > Yes, exactly. I've added a protocol extension for sharing those buffers and > our eglCreateImage() implementation can import such buffers into the driver > on the compositor end. The buffers are carried by an fd to the compositor > that's the only similarity. They're not dma-buf. > > > Yeah, support for opaque EGL buffers could be added, just need to think > of a good wording, since acquire fences do not make sense for all buffer > types. > Isn't that renderer's and/or backend's decision? The GL renderer can accept > fence with any buffer it can send to the 3D driver, so, effectively, > anything backed by available EGL image extensions. Someone may add a custom > backend and/or renderer using whatever hardware or API they have at hand. A > Vulkan renderer could potentially use fences with anything a Vulkan driver > is capable of importing. A renderer that does the CPU wait could be useful > at least for debugging. So I wouln't block the explicit sync at the > compositor level based on the white list. Hi Tomek, fences do not make sense to all buffer types to begin with, today. My objection is to allowing fencing buffer types that cannot be sent to the 3D driver, e.g. wl_shm which is usually copied through glTexImage2D and friends. We cannot ignore those in the spec language. A renderer (a compositor really, we're not talking about just Weston) decides what buffer types it accepts, yes. This is communicated to clients through which buffer factory interface globals are being advertised. Each type is a different protocol extension. The fence extension OTOH is just a single extension, and currently there is no protocol to negotiate which buffer types are usable with acquire fences. The first attempt is to define in the spec language what will always be supported, provided the buffer factory exists. The opaque EGL buffer type is really just one type in practise: compositors and clients use it through a well-known, single API: EGL. It does not matter that there are multiple incompatible EGL implementations, it all looks like just one opaque buffer type to compositors. I think this makes it easier to extend the fence spec wording to require opaque EGL buffers to be supported. Either the fence protocol spec needs to be clear on what works, or we need advertisement events to let clients know in advance what the compositor supports. A client sending a fence that the compositor cannot use must not be possible; compositor, client, EGL, driver, etc. bugs notwithstanding. Btw. I just realized that if client-side EGL uses the fence extension internally, that means the client app code must not attempt to add or request fences of its own, because the spec disallows multiple acquire fences and multiple release notification requests. I suppose that's fine? Alf, can you come up with changes to the spec wording and Weston to require opaque EGL buffers are supported? On one hand it is actually a little strange to couple opaque EGL buffers (a private, EGL implementation specific protocol interface) with a generic fencing extension, but maybe that is necessary because there is not enough compositor-side GBM and EGL API so that the EGL implementation could handle it all in an EGL implementation specific interface? Thanks, pq > On Fri, 23 Nov 2018 at 13:47, Pekka Paalanen wrote: > > > On Fri, 23 Nov 2018 13:07:37 + > > Tomek Bury wrote: > > > > > Hi Alexandros, > > > > > > Sorry for a delay. I've finally got an end-to-end system to test it out. > > It > > > took some time because Weston backend I wrote a while back needed serious > > > rework to catch up with latest changes. > > > > > > There's one thing that didn't work for me. In compositor you reject > > > anything that isn't a DMA buffer and then in glrenderer you put an extra > > > assertion. Why? All you do is use an EGL extension in order to import > > > external fence_fd. There's no dmabuf dependency there. As long as the EGL > > > implementation exposes EGL_SYNC_NATIVE_FENCE_ANDROID extension this > > should > > > "just work" (tm) for the GL renderer. It certainly did for me. CPU-based > > > renderers can poll() to wait. > > > > Hi Tomek, > > > > with Weston it was decided not to implement a poll() based wait at > > first as implementing that properly (not blocking the compositor) would > > be a big hassle and no-one could see the benefit of it given what > > clients could actually produce. > > > > Therefore the acquire fence can only apply to buffers which can be > > pipelined to a GPU. Mesa EGL is using zwp_linux_dmabuf, but the support > > could be extended to opaque EGL buffers very well. We just chose to > > start small and bring up the infrastructure around fences first. > > > > Restrictions on buffer types etc. can certainly be lifted in the
Re: [PATCH wayland-protocols v7] Add zwp_linux_explicit_synchronization_v1
Hi Pekka, > I presume you have a driver stack that relies on the opaque EGL buffers and not zwp_linux_dmabuf any time soon? Yes, exactly. I've added a protocol extension for sharing those buffers and our eglCreateImage() implementation can import such buffers into the driver on the compositor end. The buffers are carried by an fd to the compositor that's the only similarity. They're not dma-buf. > Yeah, support for opaque EGL buffers could be added, just need to think of a good wording, since acquire fences do not make sense for all buffer types. Isn't that renderer's and/or backend's decision? The GL renderer can accept fence with any buffer it can send to the 3D driver, so, effectively, anything backed by available EGL image extensions. Someone may add a custom backend and/or renderer using whatever hardware or API they have at hand. A Vulkan renderer could potentially use fences with anything a Vulkan driver is capable of importing. A renderer that does the CPU wait could be useful at least for debugging. So I wouln't block the explicit sync at the compositor level based on the white list. Cheers, Tomek On Fri, 23 Nov 2018 at 13:47, Pekka Paalanen wrote: > On Fri, 23 Nov 2018 13:07:37 + > Tomek Bury wrote: > > > Hi Alexandros, > > > > Sorry for a delay. I've finally got an end-to-end system to test it out. > It > > took some time because Weston backend I wrote a while back needed serious > > rework to catch up with latest changes. > > > > There's one thing that didn't work for me. In compositor you reject > > anything that isn't a DMA buffer and then in glrenderer you put an extra > > assertion. Why? All you do is use an EGL extension in order to import > > external fence_fd. There's no dmabuf dependency there. As long as the EGL > > implementation exposes EGL_SYNC_NATIVE_FENCE_ANDROID extension this > should > > "just work" (tm) for the GL renderer. It certainly did for me. CPU-based > > renderers can poll() to wait. > > Hi Tomek, > > with Weston it was decided not to implement a poll() based wait at > first as implementing that properly (not blocking the compositor) would > be a big hassle and no-one could see the benefit of it given what > clients could actually produce. > > Therefore the acquire fence can only apply to buffers which can be > pipelined to a GPU. Mesa EGL is using zwp_linux_dmabuf, but the support > could be extended to opaque EGL buffers very well. We just chose to > start small and bring up the infrastructure around fences first. > > Restrictions on buffer types etc. can certainly be lifted in the future > if there are good use cases. I presume you have a driver stack that > relies on the opaque EGL buffers and not zwp_linux_dmabuf any time soon? > > Would anyone ever use an acquire fence with wl_shm buffers? That sounds > fundamentally wrong to me as one cannot create fences to be signalled > by userspace AFAIK. Therefore buffers whose wait cannot be pipelined to > the GPU or the display device do not make much sense to me. > > > The type of buffer used is an orthogonal problem. The > > EGL_WL_bind_wayland_display > > extension takes care of GL clients' buffers in GL renderer, for anything > > else the renderer needs to know how to get pixels and use whatever means > to > > put those pixels on screen. > > Yeah, support for opaque EGL buffers could be added, just need to think > of a good wording, since acquire fences do not make sense for all > buffer types. A compositor must be allowed to raise protocol errors for > fence+buffer combinations it cannot use, which means that clients must > know in advance what they cannot use. > > > Thanks, > pq > > > On Tue, 13 Nov 2018 at 09:33, Tomek Bury wrote: > > > > > Thanks! > > > > > > On Tue, Nov 13, 2018 at 9:08 AM Alexandros Frantzis < > > > alexandros.frant...@collabora.com> wrote: > > > > > >> On Mon, Nov 12, 2018 at 12:39:58PM +, Tomek Bury wrote: > > >> > On Mon, Nov 12, 2018 at 11:15 AM Daniel Stone > > > >> wrote: > > >> > > > >> > > On Fri, 9 Nov 2018 at 10:48, Pekka Paalanen > > > >> wrote: > > >> > > > I can add that while pushing upstream, if there are no other > changes > > >> > > > coming. > > >> > > > > > >> > > > Reviewed-by: Pekka Paalanen > > >> > > > > > >> > > > You have ensured that the C files generated from this revision > build > > >> > > > fine in Weston, right? > > >> > > > > > >> > > > David, Daniel, since your name is in the maintainers, can I > have > > >> your > > >> > > > R-b, please? > > >> > > > > >> > > The protocol is: > > >> > > Reviewed-by: Daniel Stone > > >> > > > > >> > > The Weston implementation looks pretty good so far, though > there's no > > >> > > full implementation of release yet. > > >> > > > > >> > > Cheers, > > >> > > Daniel > > >> > > ___ > > >> > > wayland-devel mailing list > > >> > > wayland-devel@lists.freedesktop.org > > >> > > https://lists.freedesktop.org/mailman/listinfo/wayland-devel > > >> > > > > >> > > > >> > HI
Re: [PATCH wayland-protocols v7] Add zwp_linux_explicit_synchronization_v1
On Fri, 23 Nov 2018 13:07:37 + Tomek Bury wrote: > Hi Alexandros, > > Sorry for a delay. I've finally got an end-to-end system to test it out. It > took some time because Weston backend I wrote a while back needed serious > rework to catch up with latest changes. > > There's one thing that didn't work for me. In compositor you reject > anything that isn't a DMA buffer and then in glrenderer you put an extra > assertion. Why? All you do is use an EGL extension in order to import > external fence_fd. There's no dmabuf dependency there. As long as the EGL > implementation exposes EGL_SYNC_NATIVE_FENCE_ANDROID extension this should > "just work" (tm) for the GL renderer. It certainly did for me. CPU-based > renderers can poll() to wait. Hi Tomek, with Weston it was decided not to implement a poll() based wait at first as implementing that properly (not blocking the compositor) would be a big hassle and no-one could see the benefit of it given what clients could actually produce. Therefore the acquire fence can only apply to buffers which can be pipelined to a GPU. Mesa EGL is using zwp_linux_dmabuf, but the support could be extended to opaque EGL buffers very well. We just chose to start small and bring up the infrastructure around fences first. Restrictions on buffer types etc. can certainly be lifted in the future if there are good use cases. I presume you have a driver stack that relies on the opaque EGL buffers and not zwp_linux_dmabuf any time soon? Would anyone ever use an acquire fence with wl_shm buffers? That sounds fundamentally wrong to me as one cannot create fences to be signalled by userspace AFAIK. Therefore buffers whose wait cannot be pipelined to the GPU or the display device do not make much sense to me. > The type of buffer used is an orthogonal problem. The > EGL_WL_bind_wayland_display > extension takes care of GL clients' buffers in GL renderer, for anything > else the renderer needs to know how to get pixels and use whatever means to > put those pixels on screen. Yeah, support for opaque EGL buffers could be added, just need to think of a good wording, since acquire fences do not make sense for all buffer types. A compositor must be allowed to raise protocol errors for fence+buffer combinations it cannot use, which means that clients must know in advance what they cannot use. Thanks, pq > On Tue, 13 Nov 2018 at 09:33, Tomek Bury wrote: > > > Thanks! > > > > On Tue, Nov 13, 2018 at 9:08 AM Alexandros Frantzis < > > alexandros.frant...@collabora.com> wrote: > > > >> On Mon, Nov 12, 2018 at 12:39:58PM +, Tomek Bury wrote: > >> > On Mon, Nov 12, 2018 at 11:15 AM Daniel Stone > >> wrote: > >> > > >> > > On Fri, 9 Nov 2018 at 10:48, Pekka Paalanen > >> wrote: > >> > > > I can add that while pushing upstream, if there are no other changes > >> > > > coming. > >> > > > > >> > > > Reviewed-by: Pekka Paalanen > >> > > > > >> > > > You have ensured that the C files generated from this revision build > >> > > > fine in Weston, right? > >> > > > > >> > > > David, Daniel, since your name is in the maintainers, can I have > >> your > >> > > > R-b, please? > >> > > > >> > > The protocol is: > >> > > Reviewed-by: Daniel Stone > >> > > > >> > > The Weston implementation looks pretty good so far, though there's no > >> > > full implementation of release yet. > >> > > > >> > > Cheers, > >> > > Daniel > >> > > ___ > >> > > wayland-devel mailing list > >> > > wayland-devel@lists.freedesktop.org > >> > > https://lists.freedesktop.org/mailman/listinfo/wayland-devel > >> > > > >> > > >> > HI Daniel, > >> > > >> > Where can I find the work-in-progress implementation? I'd like to try it > >> > out with Broadcom driver which doesn't have implicit cross-process > >> sync. I > >> > can add the explicit sync protocol implementation on the driver side but > >> > I'd need a reference to test it against. > >> > > >> > Cheers, > >> > Tomek > >> > >> Hi Tomek, > >> > >> the WIP implementation can be found here [1]. I hope to push an update, > >> including some zwp_buffer_release_v1 correctness fixes, in the following > >> days. > >> > >> Thanks, > >> Alexandros > >> > >> [1] https://gitlab.freedesktop.org/wayland/weston/merge_requests/32 > >> > > pgpDgo_NXdONY.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v7] Add zwp_linux_explicit_synchronization_v1
Hi Alexandros, Sorry for a delay. I've finally got an end-to-end system to test it out. It took some time because Weston backend I wrote a while back needed serious rework to catch up with latest changes. There's one thing that didn't work for me. In compositor you reject anything that isn't a DMA buffer and then in glrenderer you put an extra assertion. Why? All you do is use an EGL extension in order to import external fence_fd. There's no dmabuf dependency there. As long as the EGL implementation exposes EGL_SYNC_NATIVE_FENCE_ANDROID extension this should "just work" (tm) for the GL renderer. It certainly did for me. CPU-based renderers can poll() to wait. The type of buffer used is an orthogonal problem. The EGL_WL_bind_wayland_display extension takes care of GL clients' buffers in GL renderer, for anything else the renderer needs to know how to get pixels and use whatever means to put those pixels on screen. Cheers, Tomek On Tue, 13 Nov 2018 at 09:33, Tomek Bury wrote: > Thanks! > > On Tue, Nov 13, 2018 at 9:08 AM Alexandros Frantzis < > alexandros.frant...@collabora.com> wrote: > >> On Mon, Nov 12, 2018 at 12:39:58PM +, Tomek Bury wrote: >> > On Mon, Nov 12, 2018 at 11:15 AM Daniel Stone >> wrote: >> > >> > > On Fri, 9 Nov 2018 at 10:48, Pekka Paalanen >> wrote: >> > > > I can add that while pushing upstream, if there are no other changes >> > > > coming. >> > > > >> > > > Reviewed-by: Pekka Paalanen >> > > > >> > > > You have ensured that the C files generated from this revision build >> > > > fine in Weston, right? >> > > > >> > > > David, Daniel, since your name is in the maintainers, can I have >> your >> > > > R-b, please? >> > > >> > > The protocol is: >> > > Reviewed-by: Daniel Stone >> > > >> > > The Weston implementation looks pretty good so far, though there's no >> > > full implementation of release yet. >> > > >> > > Cheers, >> > > Daniel >> > > ___ >> > > wayland-devel mailing list >> > > wayland-devel@lists.freedesktop.org >> > > https://lists.freedesktop.org/mailman/listinfo/wayland-devel >> > > >> > >> > HI Daniel, >> > >> > Where can I find the work-in-progress implementation? I'd like to try it >> > out with Broadcom driver which doesn't have implicit cross-process >> sync. I >> > can add the explicit sync protocol implementation on the driver side but >> > I'd need a reference to test it against. >> > >> > Cheers, >> > Tomek >> >> Hi Tomek, >> >> the WIP implementation can be found here [1]. I hope to push an update, >> including some zwp_buffer_release_v1 correctness fixes, in the following >> days. >> >> Thanks, >> Alexandros >> >> [1] https://gitlab.freedesktop.org/wayland/weston/merge_requests/32 >> > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v7] Add zwp_linux_explicit_synchronization_v1
Thanks! On Tue, Nov 13, 2018 at 9:08 AM Alexandros Frantzis < alexandros.frant...@collabora.com> wrote: > On Mon, Nov 12, 2018 at 12:39:58PM +, Tomek Bury wrote: > > On Mon, Nov 12, 2018 at 11:15 AM Daniel Stone > wrote: > > > > > On Fri, 9 Nov 2018 at 10:48, Pekka Paalanen > wrote: > > > > I can add that while pushing upstream, if there are no other changes > > > > coming. > > > > > > > > Reviewed-by: Pekka Paalanen > > > > > > > > You have ensured that the C files generated from this revision build > > > > fine in Weston, right? > > > > > > > > David, Daniel, since your name is in the maintainers, can I have your > > > > R-b, please? > > > > > > The protocol is: > > > Reviewed-by: Daniel Stone > > > > > > The Weston implementation looks pretty good so far, though there's no > > > full implementation of release yet. > > > > > > Cheers, > > > Daniel > > > ___ > > > wayland-devel mailing list > > > wayland-devel@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/wayland-devel > > > > > > > HI Daniel, > > > > Where can I find the work-in-progress implementation? I'd like to try it > > out with Broadcom driver which doesn't have implicit cross-process sync. > I > > can add the explicit sync protocol implementation on the driver side but > > I'd need a reference to test it against. > > > > Cheers, > > Tomek > > Hi Tomek, > > the WIP implementation can be found here [1]. I hope to push an update, > including some zwp_buffer_release_v1 correctness fixes, in the following > days. > > Thanks, > Alexandros > > [1] https://gitlab.freedesktop.org/wayland/weston/merge_requests/32 > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v7] Add zwp_linux_explicit_synchronization_v1
On Mon, Nov 12, 2018 at 12:39:58PM +, Tomek Bury wrote: > On Mon, Nov 12, 2018 at 11:15 AM Daniel Stone wrote: > > > On Fri, 9 Nov 2018 at 10:48, Pekka Paalanen wrote: > > > I can add that while pushing upstream, if there are no other changes > > > coming. > > > > > > Reviewed-by: Pekka Paalanen > > > > > > You have ensured that the C files generated from this revision build > > > fine in Weston, right? > > > > > > David, Daniel, since your name is in the maintainers, can I have your > > > R-b, please? > > > > The protocol is: > > Reviewed-by: Daniel Stone > > > > The Weston implementation looks pretty good so far, though there's no > > full implementation of release yet. > > > > Cheers, > > Daniel > > ___ > > wayland-devel mailing list > > wayland-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/wayland-devel > > > > HI Daniel, > > Where can I find the work-in-progress implementation? I'd like to try it > out with Broadcom driver which doesn't have implicit cross-process sync. I > can add the explicit sync protocol implementation on the driver side but > I'd need a reference to test it against. > > Cheers, > Tomek Hi Tomek, the WIP implementation can be found here [1]. I hope to push an update, including some zwp_buffer_release_v1 correctness fixes, in the following days. Thanks, Alexandros [1] https://gitlab.freedesktop.org/wayland/weston/merge_requests/32 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v7] Add zwp_linux_explicit_synchronization_v1
On Mon, 12 Nov 2018 11:15:25 + Daniel Stone wrote: > On Fri, 9 Nov 2018 at 10:48, Pekka Paalanen wrote: > > I can add that while pushing upstream, if there are no other changes > > coming. > > > > Reviewed-by: Pekka Paalanen > > > > You have ensured that the C files generated from this revision build > > fine in Weston, right? > > > > David, Daniel, since your name is in the maintainers, can I have your > > R-b, please? > > The protocol is: > Reviewed-by: Daniel Stone > > The Weston implementation looks pretty good so far, though there's no > full implementation of release yet. Pushed: 18032f6..19ec5dc master -> master I dropped Reveman from the maintainers due to lack of R-b or S-o-b. I welcome a patch to add him back if he wants to. Thanks, pq pgp4iRmRaVHUY.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v7] Add zwp_linux_explicit_synchronization_v1
HI Daniel, Where can I find the work-in-progress implementation? I'd like to try it out with Broadcom driver which doesn't have implicit cross-process sync. I can add the explicit sync protocol implementation on the driver side but I'd need a reference to test it against. Cheers, Tomek On Mon, Nov 12, 2018 at 11:15 AM Daniel Stone wrote: > On Fri, 9 Nov 2018 at 10:48, Pekka Paalanen wrote: > > I can add that while pushing upstream, if there are no other changes > > coming. > > > > Reviewed-by: Pekka Paalanen > > > > You have ensured that the C files generated from this revision build > > fine in Weston, right? > > > > David, Daniel, since your name is in the maintainers, can I have your > > R-b, please? > > The protocol is: > Reviewed-by: Daniel Stone > > The Weston implementation looks pretty good so far, though there's no > full implementation of release yet. > > Cheers, > Daniel > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v7] Add zwp_linux_explicit_synchronization_v1
On Fri, Nov 09, 2018 at 04:24:56PM +0200, Alexandros Frantzis wrote: > On Fri, Nov 09, 2018 at 12:48:09PM +0200, Pekka Paalanen wrote: > > On Fri, 9 Nov 2018 09:46:36 +0200 > > Alexandros Frantzis wrote: > > > > > Signed-off-by: Alexandros Frantzis > > > > Hi Alf, > > Hi Pekka, > > thanks for the review! > > > could you come up with some rationale to put in the commit message on > > why this extension is being added? > > > > I can add that while pushing upstream, if there are no other changes > > coming. > > How about: > > This protocol enables explicit synchronization of asynchronous graphics > operations on buffers on a per-commit basis. Support is currently > limited to dmabuf buffers and dma_fence fence FDs. > > Explicit synchronization provides a more versatile notification > mechanism for buffer readiness and availability, and can be used to > improve efficiency by integrating with related functionality in display > and graphics APIs. > > Finally, the per-commit nature of the release events provided by this > protocol offer a solution to a deficiency of the wl_buffer.release event > (see https://gitlab.freedesktop.org/wayland/wayland/issues/46). v2 of the text, with some more ChromeOS related information: This protocol enables explicit synchronization of asynchronous graphics operations on buffers on a per-commit basis. Support is currently limited to dmabuf buffers and dma_fence fence FDs. Explicit synchronization provides a more versatile notification mechanism for buffer readiness and availability, and can be used to improve efficiency by integrating with related functionality in display and graphics APIs. This protocol is also useful in ChromeOS ARC++ (running Android apps inside ChromeOS, using Wayland as the communication protocol), where it can enable integration of the ChromeOS compositor with the explicit synchronization mechanisms of the Android display subsystem. Finally, the per-commit nature of the release events provided by this protocol potentially offers a solution to a deficiency of the wl_buffer.release event (see https://gitlab.freedesktop.org/wayland/wayland/issues/46). Thanks, Alexandros ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v7] Add zwp_linux_explicit_synchronization_v1
On Fri, 9 Nov 2018 at 10:48, Pekka Paalanen wrote: > I can add that while pushing upstream, if there are no other changes > coming. > > Reviewed-by: Pekka Paalanen > > You have ensured that the C files generated from this revision build > fine in Weston, right? > > David, Daniel, since your name is in the maintainers, can I have your > R-b, please? The protocol is: Reviewed-by: Daniel Stone The Weston implementation looks pretty good so far, though there's no full implementation of release yet. Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v7] Add zwp_linux_explicit_synchronization_v1
On Fri, Nov 09, 2018 at 12:48:09PM +0200, Pekka Paalanen wrote: > On Fri, 9 Nov 2018 09:46:36 +0200 > Alexandros Frantzis wrote: > > > Signed-off-by: Alexandros Frantzis > > Hi Alf, Hi Pekka, thanks for the review! > could you come up with some rationale to put in the commit message on > why this extension is being added? > > I can add that while pushing upstream, if there are no other changes > coming. How about: This protocol enables explicit synchronization of asynchronous graphics operations on buffers on a per-commit basis. Support is currently limited to dmabuf buffers and dma_fence fence FDs. Explicit synchronization provides a more versatile notification mechanism for buffer readiness and availability, and can be used to improve efficiency by integrating with related functionality in display and graphics APIs. Finally, the per-commit nature of the release events provided by this protocol offer a solution to a deficiency of the wl_buffer.release event (see https://gitlab.freedesktop.org/wayland/wayland/issues/46). > Reviewed-by: Pekka Paalanen > > You have ensured that the C files generated from this revision build > fine in Weston, right? Yes, I have been working locally with this revision in Weston, and everything builds and runs fine. Thanks, Alexandros ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v7] Add zwp_linux_explicit_synchronization_v1
On Fri, 9 Nov 2018 09:46:36 +0200 Alexandros Frantzis wrote: > Signed-off-by: Alexandros Frantzis Hi Alf, could you come up with some rationale to put in the commit message on why this extension is being added? I can add that while pushing upstream, if there are no other changes coming. Reviewed-by: Pekka Paalanen You have ensured that the C files generated from this revision build fine in Weston, right? David, Daniel, since your name is in the maintainers, can I have your R-b, please? I aim to land this on Monday, so if anyone has anything to say, try to be quick. Jonas told me more than a week ago that he is looking to make a wayland-protocols release soon. If anyone has opinions on whether this should or should not make that release, let us know. Thanks, pq > --- > > Changes in patch v7: > - Added linux_ prefix to interface names. > > Changes in patch v6: > - Fixed wl_buffer.attach -> wl_surface.attach typos. > - Added NO_BUFFER error and update request descriptions. > - Consistently used "error is raised" phrasing. > - Add comment about buffer_release object destruction in event > descriptions. > > Changes in patch v5: > - Further clarified the per-commit nature of buffer_release. > - Used the wp_linux_dmabuf name to refer to all versions of that protocol. > - Fixed wl_buffer.attach typo. > - Clarified when an INVALID_FENCE error is raised. > - Improved wording explaining the double-buffer state of buffer_release. > - Allowed get_release requests on all non-null buffers. > - Clarified that the compositor is free to select buffer_release events > on a release by release basis. > - Changed buffer_release to be self-destroyed after it emits an event. > > Changes in patch v4: > - Guaranteed protocol compatibility only with zwp_linux_dmabuf buffers. > - Added the UNSUPPORTED_BUFFER error. > > Changes in patch v3: > - Reworded implicit/explicit synchronization intro in > zwp_surface_synchronization_v1 description. > - Removed confusing mention of wl_buffer.release in > zwp_surface_synchronization_v1 description. > - Clarified which fences are affected on sync object destruction. > - Removed unclear mention about wl_buffer destruction > in fenced_release description. > - Clarified that the release events and their guarantees apply to > the relevant commit only. > - Reformatted text. > > Changes in patch v2: > - Added NO_SURFACE error for zwp_surface_synchronization_v1 requests. > - Removed restriction to destroy a zwp_surface_synchronization_v1 object > after the associated wl_surface is destroyed. > - Clarified which buffer the acquire fence is associated with. > - Clarified that exactly one event, either a fenced_release or a > immediate_release, will be emitted for each commit. > > Makefile.am | 1 + > .../linux-explicit-synchronization/README | 6 + > ...x-explicit-synchronization-unstable-v1.xml | 235 ++ > 3 files changed, 242 insertions(+) > create mode 100644 unstable/linux-explicit-synchronization/README > create mode 100644 > unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml > > diff --git a/Makefile.am b/Makefile.am > index 6394e26..7dfbb9e 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -21,6 +21,7 @@ unstable_protocols = > \ > unstable/xdg-output/xdg-output-unstable-v1.xml > \ > unstable/input-timestamps/input-timestamps-unstable-v1.xml \ > unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ > + > unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml > \ > $(NULL) > > stable_protocols = > \ > diff --git a/unstable/linux-explicit-synchronization/README > b/unstable/linux-explicit-synchronization/README > new file mode 100644 > index 000..f13b404 > --- /dev/null > +++ b/unstable/linux-explicit-synchronization/README > @@ -0,0 +1,6 @@ > +Linux explicit synchronization (dma-fence) protocol > + > +Maintainers: > +David Reveman > +Daniel Stone > +Alexandros Frantzis > diff --git > a/unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml > > b/unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml > new file mode 100644 > index 000..db36284 > --- /dev/null > +++ > b/unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml > @@ -0,0 +1,235 @@ > + > + > + > + > +Copyright 2016 The Chromium Authors. > +Copyright 2017 Intel Corporation > +Copyright 2018 Collabora, Ltd > + > +Permission is hereby granted, free of charge, to any person obtaining a > +copy of this software and associated documentation files (the > "Software"), > +to deal in the
Re: [PATCH wayland-protocols v7] Add zwp_linux_explicit_synchronization_v1
Reviewed-by: Simon Ser Thanks! ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
