[PATCH wayland-protocols] sysroot prefix

[Tomek Bury]

Hi,

I've attached a trivial patch we discussed yesterday on #wayland channel.
The patch adds a sysroot prefix to the "pkgdatadir" variable. The
pkg-config automatically adds sysroot to paths returned by --cflags and
--libs but *NOT* to --variable.

The "pkgdatadir" in wayland-protocols.pc is actually a path pointing to the
protocol installation directory on the target system but in a
cross-compilation scenario we need pkg-config to return a temporary
location in the staging area on the build system just as it does for
--cflags and --libs.

The change only influences builds with PKG_CONFIG_SYSROOT_DIR environment
variable set.

There's another pkg-confing variable containing a path to the
wayland-scanner tool but I'm not sure how to handle that one correctly in
cross-compilation scenario.  The cross-compiled wayland-scanner is likely
to be useless on the build system. The pre-existing wayland-scanner on the
build system, if any, is also likely to be useless. The only scanner that
would actually work is the scanner compiled from wayland sources for the
build system architecture and installed somewhere with its own .pc file.
This implies that libs using scanner would need 2 independent pkg-config
setups.

My call would be to get rid of that variable and add
--with-wayland-scanner=/path/to/the/right/wayland-scanner config variable
to xkbcommon, wayland, weston and whatever uses wayland-scanner.

Cheers,
Tomek
From c09eed841ca77a3960aeb09428f97672900e8f77 Mon Sep 17 00:00:00 2001
From: Tomek Bury <tomek.b...@broadcom.com>
Date: Tue, 4 Jul 2017 13:14:17 +0100
Subject: [PATCH] Use sysroot prefix for pkgdatadir variable

The pc_sysroot is automatically added to cflags and libs but not
to 'pkg-config --variable'
---
 wayland-protocols.pc.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/wayland-protocols.pc.in b/wayland-protocols.pc.in
index a26744c..08c8fa7 100644
--- a/wayland-protocols.pc.in
+++ b/wayland-protocols.pc.in
@@ -1,6 +1,6 @@
 prefix=@prefix@
 datarootdir=@datarootdir@
-pkgdatadir=@datadir@/@PACKAGE@
+pkgdatadir=${pc_sysrootdir}/@datadir@/@PACKAGE@
 
 Name: Wayland Protocols
 Description: Wayland protocol files
-- 
1.9.1

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH] Use sysroot prefix for pkgdatadir variable

[Tomek Bury]

From: Tomek Bury <tomek.b...@broadcom.com>

The pc_sysroot is automatically added to cflags and libs but not
to 'pkg-config --variable'
---
 wayland-protocols.pc.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/wayland-protocols.pc.in b/wayland-protocols.pc.in
index a26744c..379be06 100644
--- a/wayland-protocols.pc.in
+++ b/wayland-protocols.pc.in
@@ -1,6 +1,6 @@
 prefix=@prefix@
 datarootdir=@datarootdir@
-pkgdatadir=@datadir@/@PACKAGE@
+pkgdatadir=${pc_sysrootdir}@datadir@/@PACKAGE@
 
 Name: Wayland Protocols
 Description: Wayland protocol files
-- 
2.7.4

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols] sysroot prefix

[Tomek Bury]

Sorry for a delay, broke my leg :(

I'll send a patch without the extra "/" using git send-mail as soon as I
got that one configured.

Cheers,
Tomek


On Thu, Jul 20, 2017 at 10:45 AM Quentin Glidic <
sardemff7+wayl...@sardemff7.net> wrote:

> On 7/20/17 11:25 AM, Daniel Stone wrote:
> > Hi,
> >
> > On 20 July 2017 at 10:14, Quentin Glidic
> >  wrote:
> >> Using ${pc_sysrootdir} sounds like the correct thing to do. However,
> your
> >> patch introduces a triple / when PKG_CONFIG_SYSROOT_DIR is not set.
> >> Having two / is already trouble on some platform (though the one we
> >> currently work on should be fine, I think), three / would break even
> more.
> >> Please just use "${pc_sysrootdir}@datadir@".
> >
> > Yeah, this all LGTM, and gets my:
> > Reviewed-by: Daniel Stone 
> >
> >> Also, using this variable should be in prefix=, IMO, since all the paths
> >> should be fixed.
> >
> > I'm wary of doing that, if only because it establishes a pattern. It's
> > fine for wayland-protocols itself, but when doing sysroot builds,
> > includedir/libdir/etc already get prefixed by the compiler/linker. So
> > I wouldn't want anyone to look at wayland-protocols and blindly copy
> > the prepend to prefix. Containing it to just variables we know will be
> > used and queried directly seems more safe.
>
> pkg-config already prepends PKG_CONFIG_SYSROOT_DIR to --cflags and
> --libs (and properly handle it if you put it in prefix, i.e. no
> dublicate), so it is completely safe to have in all variables.
>
> --
>
> Quentin “Sardem FF7” Glidic
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH] Use sysroot prefix for pkgdatadir variable

[Tomek Bury]

The pc_sysroot is automatically added to cflags and libs but not
to 'pkg-config --variable'
---
 wayland-protocols.pc.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/wayland-protocols.pc.in b/wayland-protocols.pc.in
index a26744c..379be06 100644
--- a/wayland-protocols.pc.in
+++ b/wayland-protocols.pc.in
@@ -1,6 +1,6 @@
 prefix=@prefix@
 datarootdir=@datarootdir@
-pkgdatadir=@datadir@/@PACKAGE@
+pkgdatadir=${pc_sysrootdir}@datadir@/@PACKAGE@
 
 Name: Wayland Protocols
 Description: Wayland protocol files
-- 
2.7.4

___
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

[Tomek Bury]

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 +0000, 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

[Tomek Bury]

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

[Tomek Bury]

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

[Tomek Bury]

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

[Tomek Bury]

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

[Tomek Bury]

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 +0000
> 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 nam

Re: [PATCH wayland-protocols v7] Add zwp_linux_explicit_synchronization_v1

[Tomek Bury]

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

Re: [PATCH wayland-protocols v7] Add zwp_linux_explicit_synchronization_v1

[Tomek Bury]

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 var

Re: [PATCH wayland-protocols v7] Add zwp_linux_explicit_synchronization_v1

[Tomek Bury]

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

[Tomek Bury]

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: Plumbing explicit synchronization through the Linux ecosystem

[Tomek Bury]

Hi Jason,

I've been wrestling with the sync problems in Wayland some time ago, but
only with regards to 3D drivers.

The guarantee given by the GL/GLES spec is limited to a single graphics
context. If the same buffer is accessed by 2 contexts the outcome is
unspecified. The cross-context and cross-process synchronisation is not
guaranteed. It happens to work on Mesa, because the read/write locking is
implemented in the kernel space, but it didn't work on Broadcom driver,
which has read-write interlocks in user space.

 A Vulkan client makes it even worse because of conflicting requirements:
Vulkan's vkQueuePresentKHR() passes in a number of semaphores but disallows
waiting. Wayland WSI requires wl_surface_commit() to be called from
vkQueuePresentKHR() which does require a wait, unless a synchronisation
primitive representing Vulkan samaphores is passed between Vulkan client
and the compositor.

The most troublesome part was Wayland buffer release mechanism, as it only
involves a CPU signalling over Wayland IPC, without any 3D driver
involvement. The choices were: explicit synchronisation extension or a
buffer copy in the compositor (i.e. compositor textures from the copy, so
the client can re-write the original), or some implicit synchronisation in
kernel space (but that wasn't an option in Broadcom driver).

With regards to V4L2, I believe it could easily work the same way as 3D
drivers, i.e. pass a buffer+fence pair to the next stage. The encode always
succeeds, but for capture or decode, the main problem is the uncertain
outcome, I believe? If we're fine with rendering or displaying an
occasional broken frame, then buffer+fence pair would work too. The broken
frame will go into the pipeline, but application can drain the pipeline and
start over once the capture works again.

To answer some points raised by Laurent (although I'm unfamiliar with the
camera drivers):

> you don't know until capture complete in which buffer the frame has
been captured
Surely you do, you only don't know in advance if the capture will be
successful

> but if an error occurs during capture, they can be recycled internally
and put to the back of the queue.
That would have to change in order to use explicit synchronisation. Every
started capture becomes immediately available as a buffer+fence pair. Fence
is signalled once the capture is finished (successfully or otherwise). The
buffer must not be reused until it's released, possibly with another fence
- in that case the buffer must not be reused until the release fence is
signalled.

Cheers,
Tomek

On Mon, 16 Mar 2020 at 10:20, Laurent Pinchart <
laurent.pinch...@ideasonboard.com> wrote:

> On Wed, Mar 11, 2020 at 04:18:55PM -0400, Nicolas Dufresne wrote:
> > (I know I'm going to be spammed by so many mailing list ...)
> >
> > Le mercredi 11 mars 2020 à 14:21 -0500, Jason Ekstrand a écrit :
> > > On Wed, Mar 11, 2020 at 12:31 PM Jason Ekstrand 
> wrote:
> > > > All,
> > > >
> > > > Sorry for casting such a broad net with this one. I'm sure most
> people
> > > > who reply will get at least one mailing list rejection.  However,
> this
> > > > is an issue that affects a LOT of components and that's why it's
> > > > thorny to begin with.  Please pardon the length of this e-mail as
> > > > well; I promise there's a concrete point/proposal at the end.
> > > >
> > > >
> > > > Explicit synchronization is the future of graphics and media.  At
> > > > least, that seems to be the consensus among all the graphics people
> > > > I've talked to.  I had a chat with one of the lead Android graphics
> > > > engineers recently who told me that doing explicit sync from the
> start
> > > > was one of the best engineering decisions Android ever made.  It's
> > > > also the direction being taken by more modern APIs such as Vulkan.
> > > >
> > > >
> > > > ## What are implicit and explicit synchronization?
> > > >
> > > > For those that aren't familiar with this space, GPUs, media encoders,
> > > > etc. are massively parallel and synchronization of some form is
> > > > required to ensure that everything happens in the right order and
> > > > avoid data races.  Implicit synchronization is when bits of work (3D,
> > > > compute, video encode, etc.) are implicitly based on the absolute
> > > > CPU-time order in which API calls occur.  Explicit synchronization is
> > > > when the client (whatever that means in any given context) provides
> > > > the dependency graph explicitly via some sort of synchronization
> > > > primitives.  If you're still confused, consider the following
> > > > examples:
> > > >
> > > > With OpenGL and EGL, almost everything is implicit sync.  Say you
> have
> > > > two OpenGL contexts sharing an image where one writes to it and the
> > > > other textures from it.  The way the OpenGL spec works, the client
> has
> > > > to make the API calls to render to the image before (in CPU time) it
> > > > makes the API calls which texture from the image.  As long as it does
> > > > this 

Re: Plumbing explicit synchronization through the Linux ecosystem

[Tomek Bury]

>  As long as we can fall back to not using fences then we should be fine.
Buffers written by the camera are trivial because you control what
happens - just don't attach fence, so that the capture can be used
immediately. For recycled buffers there's an extra bit of work to do
because won't  be up to camera driver to decide whether the buffer
comes back with or without fence.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Plumbing explicit synchronization through the Linux ecosystem

[Tomek Bury]

> GL and GLES are not relevant. What is relevant is EGL, which defines
> interfaces to make things work on the native platform.
Yes and no. This is what EGL spec says about sharing a texture between contexts:

"OpenGL and OpenGL ES makes no attempt to synchronize access to
texture objects. If a texture object is bound to more than one
context, then it is up to the programmer to ensure that the contents
of the object are not being changed via one context while another
context is using the texture object for rendering. The results of
changing a texture object while another context is using it are
undefined."

There are similar statements with regards to the lack of
synchronisation guarantees for EGL images or between GL and native
rendering, etc. But the main thing here is that EGL and Vulkan differ
significantly. The eglSwapBuffers() is expected to post an unspecified
"back buffer" to the display system using some internal driver magic.
EGL driver is then expected to obtain another back buffer at some
unspecified point in the future. Vulkan on the other hand is very
specific and explicit. The vkQueuePresentKHR() is expected to post a
specific vkImage with an explicit set of set of semaphores. Another
image is obtained through vkAcquireNextImageKHR() and it's the
application's decision whether it wants a fence, a semaphore, both or
none with the acquired buffer. The implicit synchronisation doesn't
mix well with Vulkan drivers and requires a lot of extra plumbing  in
the WSI code.

> If you are using EGL_WL_bind_wayland_display, then one of the things
> it is explicitly allowed/expected to do is to create a Wayland
> protocol interface between client and compositor, which can be used to
> pass buffer handles and metadata in a platform-specific way. Adding
> synchronisation is also possible.
Only one-way synchronisation is possible with this mechanism. There's
a standard protocol for recycling buffers - wl_buffer_release() so
buffer hand-over from the compositor to client remains unsynchronised
- see below.

> > The most troublesome part was Wayland buffer release mechanism, as it only 
> > involves a CPU signalling over Wayland IPC, without any 3D driver 
> > involvement. The choices were: explicit synchronisation extension or a 
> > buffer copy in the compositor (i.e. compositor textures from the copy, so 
> > the client can re-write the original), or some implicit synchronisation in 
> > kernel space (but that wasn't an option in Broadcom driver).
>
> You can add your own explicit synchronisation extension.
I could but that requires implementing in in the driver and in a
number of compositors, therefore a standard extension
zwp_linux_explicit_synchronization_v1 is much better choice here than
a custom one.

> In every cross-process and cross-subsystem usecase, synchronisation is
> obviously required. The two options for this are to implement kernel
> support for implicit synchronisation (as everyone else has done),
That would require major changes in driver architecture or a 2nd
mechanisms doing the same thing but in kernel space - both are
non-starters.

> or implement generic support for explicit synchronisation (as we have
> been working on with implementations inside Weston and Exosphere at
> least),
The zwp_linux_explicit_synchronization_v1 is a good step forward. I'm
using this extension as a main synchronisation mechanism in EGL and
Vulkan driver whenever available. I remember that Gustavo Padovan was
working on explicit sync support in the display system some time ago.
I hope it got merged into kernel by now, but I don't know to what
extend it's actually being used.

> or implement private support for explicit synchronisation,
If everything else fails, that would be the last resort scenario, but
far from ideal and very costly in terms of implementation and
maintenance as it would require maintaining custom patches for various
3rd party components or littering them with multiple custom explicit
synchronisation schemes.

> or do nothing and then be surprised at the lack of synchronisation.
Thank you, but no, thank you :)

Cheers,
Tomek
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Plumbing explicit synchronization through the Linux ecosystem

[Tomek Bury]

> vkAcquireNextImageKHR() [...] it's the application's decision whether it 
> wants a fence, a semaphore, both or none
Correction: "or none" is not allowed
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Plumbing explicit synchronization through the Linux ecosystem

[Tomek Bury]

> That's not true; you can post back a sync token every time the client
> buffer is used by the compositor.
Technically, yes but it's very cumbersome and invasive to the point
where it becomes impractical. Explicit sync is much cleaner solution.

> For instance, Mesa adds the `wl_drm` extension, which is
> used for bidirectional communication between the EGL implementations
> in the client and compositor address spaces, without modifying either.
Broadcom driver adds "wl_nexus" extension which servers similar
purpose for both EGL and Vulkan WSI

> OK. As it stands, everyone else has the kernel mechanism (e.g. via
> dmabuf resv), so in this case if you are reinventing the underlying
> platform in a proprietary stack, you get to solve the same problems
> yourselves.
That's an important point. In the explicit synchronisation scenario
the sync token is passed with the buffer. It becomes irrelevant where
the token originated from, as long as it's a commonly used type of
token, i.e. dma_fence in kernel space or sync_fd in user space. That
allows for greater flexibility and works with and without dma
reservation objects.

Cheers,
Tomek
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel