[PATCH wayland-protocols v2] Add zwp_linux_explicit_synchronization

Discussion:

[PATCH wayland-protocols v2] Add zwp_linux_explicit_synchronization_v1

Alexandros Frantzis

2018-10-09 15:11:22 UTC

Signed-off-by: Alexandros Frantzis <***@collabora.com>
---

patch v1 here: https://patchwork.freedesktop.org/patch/177866/
Changes since patch v1:
- Add NO_SURFACE error for zwp_surface_synchronization_v1 requests.
- Remove restriction to destroy a zwp_surface_synchronization_v1 object
after the associated wl_surface is destroyed.
- Clarify which buffer the acquire fence is associated with.
- Clarify 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 | 222 ++++++++++++++++++
3 files changed, 229 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 0000000..f13b404
--- /dev/null
+++ b/unstable/linux-explicit-synchronization/README
@@ -0,0 +1,6 @@
+Linux explicit synchronization (dma-fence) protocol
+
+Maintainers:
+David Reveman <***@chromium.org>
+Daniel Stone <***@collabora.com>
+Alexandros Frantzis <***@collabora.com>
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 0000000..11ef3f0
--- /dev/null
+++ b/unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml
@@ -0,0 +1,222 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="zwp_linux_explicit_synchronization_unstable_v1">
+
+ <copyright>
+ 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 Software without restriction, including without limitation
+ the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ and/or sell copies of the Software, and to permit persons to whom the
+ Software is furnished to do so, subject to the following conditions:
+
+ The above copyright notice and this permission notice (including the next
+ paragraph) shall be included in all copies or substantial portions of the
+ Software.
+
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ DEALINGS IN THE SOFTWARE.
+ </copyright>
+
+ <interface name="zwp_linux_explicit_synchronization_v1" version="1">
+ <description summary="protocol for providing explicit synchronization">
+ This global is a factory interface, allowing clients to request
+ explicit synchronization for buffers on a per-surface basis.
+
+ See zwp_surface_synchronization_v1 for more information.
+
+ This interface is derived from Chromium's
+ zcr_linux_explicit_synchronization_v1.
+
+ Warning! The protocol described in this file is experimental and
+ backward incompatible changes may be made. Backward compatible changes
+ may be added together with the corresponding interface version bump.
+ Backward incompatible changes are done by bumping the version number in
+ the protocol and interface names and resetting the interface version.
+ Once the protocol is to be declared stable, the 'z' prefix and the
+ version number in the protocol and interface names are removed and the
+ interface version number is reset.
+ </description>
+
+ <request name="destroy" type="destructor">
+ <description summary="destroy explicit synchronization factory object">
+ Destroy this explicit synchronization factory object. Other objects,
+ including zwp_surface_synchronization_v1 objects created by this
+ factory, shall not be affected by this request.
+ </description>
+ </request>
+
+ <enum name="error">
+ <entry name="synchronization_exists" value="0"
+ summary="the surface already has a synchronization object associated"/>
+ </enum>
+
+ <request name="get_synchronization">
+ <description summary="extend surface interface for explicit synchronization">
+ Instantiate an interface extension for the given wl_surface to
+ provide explicit synchronization.
+
+ If the given wl_surface already has an explicit synchronization object
+ associated, the synchronization_exists protocol error is raised.
+ </description>
+
+ <arg name="id" type="new_id" interface="zwp_surface_synchronization_v1"
+ summary="the new synchronization interface id"/>
+ <arg name="surface" type="object" interface="wl_surface"
+ summary="the surface"/>
+ </request>
+ </interface>
+
+ <interface name="zwp_surface_synchronization_v1" version="1">
+ <description summary="per-surface explicit synchronization support">
+ This object implements per-surface explicit synchronization.
+
+ Explicit synchronization refers to co-ordination of pipelined
+ operations performed on buffers. Most GPU clients will schedule
+ an asynchronous operation to render to the buffer, then immediately
+ send the buffer to the compositor to be attached to a surface.
+ Ensuring that the rendering operation is complete before the
+ compositor displays the buffer is an implementation detail handled
+ by either the kernel or userspace graphics driver. This is referred
+ to as 'implicit synchronization'.
+
+ By contrast, explicit synchronization takes dma_fence objects as a
+ marker of when the asynchronous operations are complete. The fence
+ provided by the client will be waited on before the compositor
+ accesses the buffer. Conversely, in place of wl_buffer.release
+ events, the Wayland server will inform the client when the buffer
+ can be destructively accessed through a zwp_buffer_release_v1
+ object.
+
+ This interface cannot be instantiated multiple times for a single
+ surface, and as such should only be used by the component which
+ performs the wl_surface.attach request. Whenever control of
+ buffer attachments is released, the releasing component should
+ ensure it destroys the zwp_surface_synchronization_v1 object.
+ </description>
+
+ <request name="destroy" type="destructor">
+ <description summary="destroy synchronization object">
+ Destroy this explicit synchronization object.
+
+ Any fence set with set_acquire_fence in this commit cycle will
+ be invalidated in the server.
+
+ zwp_buffer_release_v1 objects created by this object are not affected
+ by this request.
+ </description>
+ </request>
+
+ <enum name="error">
+ <entry name="invalid_fence" value="0"
+ summary="the fence specified by the client could not be imported"/>
+ <entry name="duplicate_fence" value="1"
+ summary="multiple fences added for a single surface commit"/>
+ <entry name="duplicate_release" value="2"
+ summary="multiple releases added for a single surface commit"/>
+ <entry name="no_surface" value="3"
+ summary="the associated wl_surface was destroyed"/>
+ </enum>
+
+ <request name="set_acquire_fence">
+ <description summary="set the acquire fence">
+ Set the acquire fence that must be signaled before the compositor
+ may sample from the buffer attached with wl_buffer_attach. The fence
+ is a dma_fence kernel object.
+
+ The acquire fence is double-buffered state, and will be applied on the
+ next wl_surface.commit request for the associated surface. Thus, it
+ applies only to the buffer that is attached to the surface at commit
+ time.
+
+ If the fence could not be imported, an INVALID_FENCE error is signaled
+ to the client.
+
+ If a fence has already been attached during the same commit cycle,
+ a DUPLICATE_FENCE error is signaled to the client.
+
+ If the associated wl_surface was destroyed, a NO_SURFACE error
+ is signaled to the client.
+ </description>
+ <arg name="fd" type="fd" summary="acquire fence fd"/>
+ </request>
+
+ <request name="get_release">
+ <description summary="release fence for last-attached buffer">
+ Create a listener for the release of the buffer attached by the
+ client with wl_buffer.attach. See zwp_buffer_release_v1
+ documentation for more information.
+
+ The release object is double-buffered state, and will be applied
+ on the next wl_surface.commit request for the associated surface.
+
+ If a zwp_buffer_release_v1 object has already been requested for
+ the surface in the same commit cycle, a DUPLICATE_RELEASE error
+ is signaled to the client.
+
+ If the associated wl_surface was destroyed, a NO_SURFACE error
+ is signaled to the client.
+ </description>
+
+ <arg name="release" type="new_id" interface="zwp_buffer_release_v1"
+ summary="new zwp_buffer_release_v1 object"/>
+ </request>
+ </interface>
+
+ <interface name="zwp_buffer_release_v1" version="1">
+ <description summary="buffer release explicit synchronization">
+ This object is instantiated in response to a
+ zwp_surface_synchronization_v1 request.
+
+ It provides an alternative to wl_buffer.release events, providing
+ a unique release from a single wl_surface.commit request. The release
+ event also supports explicit synchronization, providing a fence FD
+ where relevant for the client to synchronize against before reusing
+ the buffer.
+
+ Exactly one event, either a fenced_release or an immediate_release,
+ will be emitted for each wl_surface.commit request.
+
+ This event does not replace wl_buffer.release events; servers are still
+ required to send those events.
+ </description>
+
+ <request name="destroy" type="destructor">
+ <description summary="destroy buffer release synchronization object">
+ Destroy this buffer release explicit synchronization object. The object
+ may be destroyed at any time.
+ </description>
+ </request>
+
+ <event name="fenced_release">
+ <description summary="release buffer with fence">
+ Sent when the compositor has finalised its usage of the associated
+ buffer, providing a dma_fence which will be signaled when all
+ operations by the compositor on that buffer have finished.
+
+ Clients must not perform any destructive operations (e.g. clearing or
+ rendering) on the buffer until that fence has passed. They may,
+ however, destroy the wl_buffer object.
+ </description>
+ <arg name="fence" type="fd" summary="fence for last operation on buffer"/>
+ </event>
+
+ <event name="immediate_release">
+ <description summary="release buffer immediately">
+ Sent when the compositor has finalised its usage of the associated
+ buffer, and either performed no operations using it, or has a
+ guarantee that all its operations have finished and no more external
+ effects will be observed from these operations.
+ </description>
+ </event>
+ </interface>
+
+</protocol>

--
2.19.1

Pekka Paalanen

2018-10-12 12:24:30 UTC

Permalink

Hi,

this is a good specification, all my comments are clarifications or
minor adjustments. The fundamental design looks fine to me.

On Tue, 9 Oct 2018 18:11:22 +0300

Post by Alexandros Frantzis
---
patch v1 here: https://patchwork.freedesktop.org/patch/177866/
- Add NO_SURFACE error for zwp_surface_synchronization_v1 requests.
- Remove restriction to destroy a zwp_surface_synchronization_v1 object
after the associated wl_surface is destroyed.
- Clarify which buffer the acquire fence is associated with.
- Clarify 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 | 222 ++++++++++++++++++
3 files changed, 229 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 0000000..f13b404
--- /dev/null
+++ b/unstable/linux-explicit-synchronization/README
@@ -0,0 +1,6 @@
+Linux explicit synchronization (dma-fence) protocol
+
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 0000000..11ef3f0
--- /dev/null
+++ b/unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml
@@ -0,0 +1,222 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="zwp_linux_explicit_synchronization_unstable_v1">
+
+ <copyright>
+ 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 Software without restriction, including without limitation
+ the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ and/or sell copies of the Software, and to permit persons to whom the
+
+ The above copyright notice and this permission notice (including the next
+ paragraph) shall be included in all copies or substantial portions of the
+ Software.
+
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ DEALINGS IN THE SOFTWARE.
+ </copyright>
+
+ <interface name="zwp_linux_explicit_synchronization_v1" version="1">
+ <description summary="protocol for providing explicit synchronization">
+ This global is a factory interface, allowing clients to request
+ explicit synchronization for buffers on a per-surface basis.
+
+ See zwp_surface_synchronization_v1 for more information.
+
+ This interface is derived from Chromium's
+ zcr_linux_explicit_synchronization_v1.
+
+ Warning! The protocol described in this file is experimental and
+ backward incompatible changes may be made. Backward compatible changes
+ may be added together with the corresponding interface version bump.
+ Backward incompatible changes are done by bumping the version number in
+ the protocol and interface names and resetting the interface version.
+ Once the protocol is to be declared stable, the 'z' prefix and the
+ version number in the protocol and interface names are removed and the
+ interface version number is reset.
+ </description>
+
+ <request name="destroy" type="destructor">
+ <description summary="destroy explicit synchronization factory object">
+ Destroy this explicit synchronization factory object. Other objects,
+ including zwp_surface_synchronization_v1 objects created by this
+ factory, shall not be affected by this request.
+ </description>
+ </request>
+
+ <enum name="error">
+ <entry name="synchronization_exists" value="0"
+ summary="the surface already has a synchronization object associated"/>
+ </enum>
+
+ <request name="get_synchronization">
+ <description summary="extend surface interface for explicit synchronization">
+ Instantiate an interface extension for the given wl_surface to
+ provide explicit synchronization.
+
+ If the given wl_surface already has an explicit synchronization object
+ associated, the synchronization_exists protocol error is raised.
+ </description>
+
+ <arg name="id" type="new_id" interface="zwp_surface_synchronization_v1"
+ summary="the new synchronization interface id"/>
+ <arg name="surface" type="object" interface="wl_surface"
+ summary="the surface"/>
+ </request>
+ </interface>
+
+ <interface name="zwp_surface_synchronization_v1" version="1">
+ <description summary="per-surface explicit synchronization support">
+ This object implements per-surface explicit synchronization.
+
+ Explicit synchronization refers to co-ordination of pipelined

Strike "Explicit"? It's odd because this starts with "explicit
synchronization refers to..." and then ends saying this is "implicit
synchronization.

Post by Alexandros Frantzis
+ operations performed on buffers. Most GPU clients will schedule
+ an asynchronous operation to render to the buffer, then immediately
+ send the buffer to the compositor to be attached to a surface.

Should there be a paragraph break here?

Post by Alexandros Frantzis
+ Ensuring that the rendering operation is complete before the
+ compositor displays the buffer is an implementation detail handled
+ by either the kernel or userspace graphics driver. This is referred
+ to as 'implicit synchronization'.
+
+ By contrast, explicit synchronization takes dma_fence objects as a
+ marker of when the asynchronous operations are complete. The fence
+ provided by the client will be waited on before the compositor
+ accesses the buffer. Conversely, in place of wl_buffer.release
+ events, the Wayland server will inform the client when the buffer
+ can be destructively accessed through a zwp_buffer_release_v1
+ object.

So this guarantees that no more wl_buffer.release events can be triggered
by commits that used explicit sync?

Post by Alexandros Frantzis
+
+ This interface cannot be instantiated multiple times for a single
+ surface, and as such should only be used by the component which
+ performs the wl_surface.attach request. Whenever control of
+ buffer attachments is released, the releasing component should
+ ensure it destroys the zwp_surface_synchronization_v1 object.

Is the last sentence necessary? It might confuse things as it can
easily be read as if zwp_surface_synchronization_v1 was a one-shot
thing.

This means that if zwp_surface_synchronization_v1 object is
destroyed before issuing wl_surface.commit, then the pending acquire
fence is discarded by the server, right?

Post by Alexandros Frantzis
+
+ zwp_buffer_release_v1 objects created by this object are not affected
+ by this request.

And after wl_surface.commit, destruction has no effect on the commit.

Post by Alexandros Frantzis
+ </description>
+ </request>
+
+ <enum name="error">
+ <entry name="invalid_fence" value="0"
+ summary="the fence specified by the client could not be imported"/>
+ <entry name="duplicate_fence" value="1"
+ summary="multiple fences added for a single surface commit"/>
+ <entry name="duplicate_release" value="2"
+ summary="multiple releases added for a single surface commit"/>
+ <entry name="no_surface" value="3"
+ summary="the associated wl_surface was destroyed"/>
+ </enum>
+
+ <request name="set_acquire_fence">
+ <description summary="set the acquire fence">
+ Set the acquire fence that must be signaled before the compositor
+ may sample from the buffer attached with wl_buffer_attach. The fence
+ is a dma_fence kernel object.
+
+ The acquire fence is double-buffered state, and will be applied on the
+ next wl_surface.commit request for the associated surface. Thus, it
+ applies only to the buffer that is attached to the surface at commit
+ time.
+
+ If the fence could not be imported, an INVALID_FENCE error is signaled
+ to the client.

"... error is raised." There is no need to be able to recover from a
failed fence import, disconnection is fine, right?

Post by Alexandros Frantzis
+
+ If a fence has already been attached during the same commit cycle,
+ a DUPLICATE_FENCE error is signaled to the client.
+
+ If the associated wl_surface was destroyed, a NO_SURFACE error
+ is signaled to the client.
+ </description>
+ <arg name="fd" type="fd" summary="acquire fence fd"/>
+ </request>
+
+ <request name="get_release">
+ <description summary="release fence for last-attached buffer">
+ Create a listener for the release of the buffer attached by the
+ client with wl_buffer.attach. See zwp_buffer_release_v1
+ documentation for more information.
+
+ The release object is double-buffered state, and will be applied
+ on the next wl_surface.commit request for the associated surface.
+
+ If a zwp_buffer_release_v1 object has already been requested for
+ the surface in the same commit cycle, a DUPLICATE_RELEASE error
+ is signaled to the client.
+
+ If the associated wl_surface was destroyed, a NO_SURFACE error
+ is signaled to the client.
+ </description>
+
+ <arg name="release" type="new_id" interface="zwp_buffer_release_v1"
+ summary="new zwp_buffer_release_v1 object"/>
+ </request>
+ </interface>
+
+ <interface name="zwp_buffer_release_v1" version="1">
+ <description summary="buffer release explicit synchronization">
+ This object is instantiated in response to a
+ zwp_surface_synchronization_v1 request.
+
+ It provides an alternative to wl_buffer.release events, providing
+ a unique release from a single wl_surface.commit request. The release
+ event also supports explicit synchronization, providing a fence FD
+ where relevant for the client to synchronize against before reusing
+ the buffer.
+
+ Exactly one event, either a fenced_release or an immediate_release,
+ will be emitted for each wl_surface.commit request.
+
+ This event does not replace wl_buffer.release events; servers are still
+ required to send those events.

Ok. The introduction lead me to believe otherwise, that should probably
be worded differently.

Post by Alexandros Frantzis
+ </description>
+
+ <request name="destroy" type="destructor">
+ <description summary="destroy buffer release synchronization object">
+ Destroy this buffer release explicit synchronization object. The object
+ may be destroyed at any time.
+ </description>

Is it inconceivable to ever add other requests in this interface?

Could there ever be a benefit from destroying this object before it has
sent an event?

Could this object ever be used as an argument to a request?

If not, this seems like the perfect candidate for destroy-on-event
behaviour, similar to wp_presentation_feedback. But if there is any
suspicion about extending this interface, then it's better to keep the
destroy request.

Post by Alexandros Frantzis
+ </request>
+
+ <event name="fenced_release">
+ <description summary="release buffer with fence">
+ Sent when the compositor has finalised its usage of the associated
+ buffer, providing a dma_fence which will be signaled when all
+ operations by the compositor on that buffer have finished.
+
+ Clients must not perform any destructive operations (e.g. clearing or
+ rendering) on the buffer until that fence has passed. They may,
+ however, destroy the wl_buffer object.

"...without any visible effects" I would add. Clients may destroy a
wl_buffer at any time, but at a "wrong" time it may lead to visual
glitches. This even here says that no glitches can happen. Unless, of
course, the wl_buffer has been submitted again or elsewhere already.

Or maybe just remove the note about destroying the wl_buffer? Strictly
speaking this event alone is not sufficient, there must not be other
unreleased uses of the wl_buffer.

Post by Alexandros Frantzis
+ </description>
+ <arg name="fence" type="fd" summary="fence for last operation on buffer"/>
+ </event>
+
+ <event name="immediate_release">
+ <description summary="release buffer immediately">
+ Sent when the compositor has finalised its usage of the associated
+ buffer, and either performed no operations using it, or has a
+ guarantee that all its operations have finished and no more external
+ effects will be observed from these operations.

Right. Should there be explicit wording that this applies to the
specific commit, and not the buffer's usage in general?

After all, this is the extension that makes it well-defined to use a
wl_buffer again (with its contents intact) before it has been released,
providing a solution to
https://gitlab.freedesktop.org/wayland/wayland/issues/46 .

Post by Alexandros Frantzis
+ </description>
+ </event>
+ </interface>
+
+</protocol>

Thanks,
pq

Alexandros Frantzis

2018-10-15 14:15:13 UTC

Permalink

Signed-off-by: Alexandros Frantzis <***@collabora.com>
---

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.

patch v1 here: https://patchwork.freedesktop.org/patch/177866/

Makefile.am | 1 +
.../linux-explicit-synchronization/README | 6 +
...x-explicit-synchronization-unstable-v1.xml | 219 ++++++++++++++++++
3 files changed, 226 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 0000000..f13b404
--- /dev/null
+++ b/unstable/linux-explicit-synchronization/README
@@ -0,0 +1,6 @@
+Linux explicit synchronization (dma-fence) protocol
+
+Maintainers:
+David Reveman <***@chromium.org>
+Daniel Stone <***@collabora.com>
+Alexandros Frantzis <***@collabora.com>
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 0000000..c2f44a9
--- /dev/null
+++ b/unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml
@@ -0,0 +1,219 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="zwp_linux_explicit_synchronization_unstable_v1">
+
+ <copyright>
+ 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 Software without restriction, including without limitation
+ the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ and/or sell copies of the Software, and to permit persons to whom the
+ Software is furnished to do so, subject to the following conditions:
+
+ The above copyright notice and this permission notice (including the next
+ paragraph) shall be included in all copies or substantial portions of the
+ Software.
+
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ DEALINGS IN THE SOFTWARE.
+ </copyright>
+
+ <interface name="zwp_linux_explicit_synchronization_v1" version="1">
+ <description summary="protocol for providing explicit synchronization">
+ This global is a factory interface, allowing clients to request
+ explicit synchronization for buffers on a per-surface basis.
+
+ See zwp_surface_synchronization_v1 for more information.
+
+ This interface is derived from Chromium's
+ zcr_linux_explicit_synchronization_v1.
+
+ Warning! The protocol described in this file is experimental and
+ backward incompatible changes may be made. Backward compatible changes
+ may be added together with the corresponding interface version bump.
+ Backward incompatible changes are done by bumping the version number in
+ the protocol and interface names and resetting the interface version.
+ Once the protocol is to be declared stable, the 'z' prefix and the
+ version number in the protocol and interface names are removed and the
+ interface version number is reset.
+ </description>
+
+ <request name="destroy" type="destructor">
+ <description summary="destroy explicit synchronization factory object">
+ Destroy this explicit synchronization factory object. Other objects,
+ including zwp_surface_synchronization_v1 objects created by this
+ factory, shall not be affected by this request.
+ </description>
+ </request>
+
+ <enum name="error">
+ <entry name="synchronization_exists" value="0"
+ summary="the surface already has a synchronization object associated"/>
+ </enum>
+
+ <request name="get_synchronization">
+ <description summary="extend surface interface for explicit synchronization">
+ Instantiate an interface extension for the given wl_surface to provide
+ explicit synchronization.
+
+ If the given wl_surface already has an explicit synchronization object
+ associated, the synchronization_exists protocol error is raised.
+ </description>
+
+ <arg name="id" type="new_id" interface="zwp_surface_synchronization_v1"
+ summary="the new synchronization interface id"/>
+ <arg name="surface" type="object" interface="wl_surface"
+ summary="the surface"/>
+ </request>
+ </interface>
+
+ <interface name="zwp_surface_synchronization_v1" version="1">
+ <description summary="per-surface explicit synchronization support">
+ This object implements per-surface explicit synchronization.
+
+ Synchronization refers to co-ordination of pipelined operations performed
+ on buffers. Most GPU clients will schedule an asynchronous operation to
+ render to the buffer, then immediately send the buffer to the compositor
+ to be attached to a surface.
+
+ In implicit synchronization, ensuring that the rendering operation is
+ complete before the compositor displays the buffer is an implementation
+ detail handled by either the kernel or userspace graphics driver.
+
+ By contrast, in explicit synchronization, dma_fence objects mark when the
+ asynchronous operations are complete. When submitting a buffer, the
+ client provides an acquire fence which will be waited on before the
+ compositor accesses the buffer. The Wayland server, through a
+ zwp_buffer_release_v1 object, will inform the client with an event which
+ may be accompanied by a release fence, when the buffer can be
+ destructively accessed.
+
+ Each surface can be associated with only one object of this interface at
+ any time.
+ </description>
+
+ <request name="destroy" type="destructor">
+ <description summary="destroy synchronization object">
+ Destroy this explicit synchronization object.
+
+ Any fence set by this object with set_acquire_fence since the last
+ commit will be discarded by the server. Any fences set by this object
+ before the last commit are not affected.
+
+ zwp_buffer_release_v1 objects created by this object are not affected
+ by this request.
+ </description>
+ </request>
+
+ <enum name="error">
+ <entry name="invalid_fence" value="0"
+ summary="the fence specified by the client could not be imported"/>
+ <entry name="duplicate_fence" value="1"
+ summary="multiple fences added for a single surface commit"/>
+ <entry name="duplicate_release" value="2"
+ summary="multiple releases added for a single surface commit"/>
+ <entry name="no_surface" value="3"
+ summary="the associated wl_surface was destroyed"/>
+ </enum>
+
+ <request name="set_acquire_fence">
+ <description summary="set the acquire fence">
+ Set the acquire fence that must be signaled before the compositor
+ may sample from the buffer attached with wl_buffer_attach. The fence
+ is a dma_fence kernel object.
+
+ The acquire fence is double-buffered state, and will be applied on the
+ next wl_surface.commit request for the associated surface. Thus, it
+ applies only to the buffer that is attached to the surface at commit
+ time.
+
+ If the fence could not be imported, an INVALID_FENCE error is raised.
+
+ If a fence has already been attached during the same commit cycle, a
+ DUPLICATE_FENCE error is raised.
+
+ If the associated wl_surface was destroyed, a NO_SURFACE error is
+ raised.
+ </description>
+ <arg name="fd" type="fd" summary="acquire fence fd"/>
+ </request>
+
+ <request name="get_release">
+ <description summary="release fence for last-attached buffer">
+ Create a listener for the release of the buffer attached by the
+ client with wl_buffer.attach. See zwp_buffer_release_v1
+ documentation for more information.
+
+ The release object is double-buffered state, and will be applied
+ on the next wl_surface.commit request for the associated surface.
+
+ If a zwp_buffer_release_v1 object has already been requested for
+ the surface in the same commit cycle, a DUPLICATE_RELEASE error
+ is signaled to the client.
+
+ If the associated wl_surface was destroyed, a NO_SURFACE error
+ is signaled to the client.
+ </description>
+
+ <arg name="release" type="new_id" interface="zwp_buffer_release_v1"
+ summary="new zwp_buffer_release_v1 object"/>
+ </request>
+ </interface>
+
+ <interface name="zwp_buffer_release_v1" version="1">
+ <description summary="buffer release explicit synchronization">
+ This object is instantiated in response to a
+ zwp_surface_synchronization_v1.get_release request.
+
+ It provides an alternative to wl_buffer.release events, providing a unique
+ release from a single wl_surface.commit request. The release event also
+ supports explicit synchronization, providing a fence FD where relevant for
+ the client to synchronize against before reusing the buffer.
+
+ Exactly one event, either a fenced_release or an immediate_release, will
+ be emitted for each wl_surface.commit request.
+
+ This event does not replace wl_buffer.release events; servers are still
+ required to send those events.
+ </description>
+
+ <request name="destroy" type="destructor">
+ <description summary="destroy buffer release synchronization object">
+ Destroy this buffer release explicit synchronization object. The object
+ may be destroyed at any time.
+ </description>
+ </request>
+
+ <event name="fenced_release">
+ <description summary="release buffer with fence">
+ Sent when the compositor has finalised its usage of the associated
+ buffer for the relevant commit, providing a dma_fence which will be
+ signaled when all operations by the compositor on that buffer for that
+ commit have finished.
+
+ Clients must not perform any destructive operations (e.g. clearing or
+ rendering) on the buffer until that fence has signaled.
+ </description>
+ <arg name="fence" type="fd" summary="fence for last operation on buffer"/>
+ </event>
+
+ <event name="immediate_release">
+ <description summary="release buffer immediately">
+ Sent when the compositor has finalised its usage of the associated
+ buffer for the relevant commit, and either performed no operations
+ using it, or has a guarantee that all its operations on that buffer for
+ that commit have finished, and any destructive operations on the buffer
+ will have no external effects.
+ </description>
+ </event>
+ </interface>
+
+</protocol>

--
2.19.1

Alexandros Frantzis

2018-10-18 13:48:53 UTC

Permalink

Signed-off-by: Alexandros Frantzis <***@collabora.com>
---

Changes in patch v4:
- Guarantee protocol compatibility only with zwp_linux_dmabuf buffers.
- Add 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.

patch v1 here: https://patchwork.freedesktop.org/patch/177866/

Makefile.am | 1 +
.../linux-explicit-synchronization/README | 6 +
...x-explicit-synchronization-unstable-v1.xml | 232 ++++++++++++++++++
3 files changed, 239 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 0000000..f13b404
--- /dev/null
+++ b/unstable/linux-explicit-synchronization/README
@@ -0,0 +1,6 @@
+Linux explicit synchronization (dma-fence) protocol
+
+Maintainers:
+David Reveman <***@chromium.org>
+Daniel Stone <***@collabora.com>
+Alexandros Frantzis <***@collabora.com>
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 0000000..4800756
--- /dev/null
+++ b/unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml
@@ -0,0 +1,232 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="zwp_linux_explicit_synchronization_unstable_v1">
+
+ <copyright>
+ 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 Software without restriction, including without limitation
+ the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ and/or sell copies of the Software, and to permit persons to whom the
+ Software is furnished to do so, subject to the following conditions:
+
+ The above copyright notice and this permission notice (including the next
+ paragraph) shall be included in all copies or substantial portions of the
+ Software.
+
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ DEALINGS IN THE SOFTWARE.
+ </copyright>
+
+ <interface name="zwp_linux_explicit_synchronization_v1" version="1">
+ <description summary="protocol for providing explicit synchronization">
+ This global is a factory interface, allowing clients to request
+ explicit synchronization for buffers on a per-surface basis.
+
+ See zwp_surface_synchronization_v1 for more information.
+
+ This interface is derived from Chromium's
+ zcr_linux_explicit_synchronization_v1.
+
+ Warning! The protocol described in this file is experimental and
+ backward incompatible changes may be made. Backward compatible changes
+ may be added together with the corresponding interface version bump.
+ Backward incompatible changes are done by bumping the version number in
+ the protocol and interface names and resetting the interface version.
+ Once the protocol is to be declared stable, the 'z' prefix and the
+ version number in the protocol and interface names are removed and the
+ interface version number is reset.
+ </description>
+
+ <request name="destroy" type="destructor">
+ <description summary="destroy explicit synchronization factory object">
+ Destroy this explicit synchronization factory object. Other objects,
+ including zwp_surface_synchronization_v1 objects created by this
+ factory, shall not be affected by this request.
+ </description>
+ </request>
+
+ <enum name="error">
+ <entry name="synchronization_exists" value="0"
+ summary="the surface already has a synchronization object associated"/>
+ </enum>
+
+ <request name="get_synchronization">
+ <description summary="extend surface interface for explicit synchronization">
+ Instantiate an interface extension for the given wl_surface to provide
+ explicit synchronization.
+
+ If the given wl_surface already has an explicit synchronization object
+ associated, the synchronization_exists protocol error is raised.
+ </description>
+
+ <arg name="id" type="new_id" interface="zwp_surface_synchronization_v1"
+ summary="the new synchronization interface id"/>
+ <arg name="surface" type="object" interface="wl_surface"
+ summary="the surface"/>
+ </request>
+ </interface>
+
+ <interface name="zwp_surface_synchronization_v1" version="1">
+ <description summary="per-surface explicit synchronization support">
+ This object implements per-surface explicit synchronization.
+
+ Synchronization refers to co-ordination of pipelined operations performed
+ on buffers. Most GPU clients will schedule an asynchronous operation to
+ render to the buffer, then immediately send the buffer to the compositor
+ to be attached to a surface.
+
+ In implicit synchronization, ensuring that the rendering operation is
+ complete before the compositor displays the buffer is an implementation
+ detail handled by either the kernel or userspace graphics driver.
+
+ By contrast, in explicit synchronization, dma_fence objects mark when the
+ asynchronous operations are complete. When submitting a buffer, the
+ client provides an acquire fence which will be waited on before the
+ compositor accesses the buffer. The Wayland server, through a
+ zwp_buffer_release_v1 object, will inform the client with an event which
+ may be accompanied by a release fence, when the buffer can be
+ destructively accessed.
+
+ Each surface can be associated with only one object of this interface at
+ any time.
+
+ Explicit synchronization is guaranteed to be supported only for buffers
+ created with any version of the zwp_linux_dmabuf buffer factory.
+ </description>
+
+ <request name="destroy" type="destructor">
+ <description summary="destroy synchronization object">
+ Destroy this explicit synchronization object.
+
+ Any fence set by this object with set_acquire_fence since the last
+ commit will be discarded by the server. Any fences set by this object
+ before the last commit are not affected.
+
+ zwp_buffer_release_v1 objects created by this object are not affected
+ by this request.
+ </description>
+ </request>
+
+ <enum name="error">
+ <entry name="invalid_fence" value="0"
+ summary="the fence specified by the client could not be imported"/>
+ <entry name="duplicate_fence" value="1"
+ summary="multiple fences added for a single surface commit"/>
+ <entry name="duplicate_release" value="2"
+ summary="multiple releases added for a single surface commit"/>
+ <entry name="no_surface" value="3"
+ summary="the associated wl_surface was destroyed"/>
+ <entry name="unsupported_buffer" value="4"
+ summary="the buffer does not support explicit synchronization"/>
+ </enum>
+
+ <request name="set_acquire_fence">
+ <description summary="set the acquire fence">
+ Set the acquire fence that must be signaled before the compositor
+ may sample from the buffer attached with wl_buffer_attach. The fence
+ is a dma_fence kernel object.
+
+ The acquire fence is double-buffered state, and will be applied on the
+ next wl_surface.commit request for the associated surface. Thus, it
+ applies only to the buffer that is attached to the surface at commit
+ time.
+
+ If the fence could not be imported, an INVALID_FENCE error is raised.
+
+ If a fence has already been attached during the same commit cycle, a
+ DUPLICATE_FENCE error is raised.
+
+ If the associated wl_surface was destroyed, a NO_SURFACE error is
+ raised.
+
+ If at surface commit time the attached buffer does not support explicit
+ synchronization, or there is no buffer attached, an UNSUPPORTED_BUFFER
+ error is raised.
+ </description>
+ <arg name="fd" type="fd" summary="acquire fence fd"/>
+ </request>
+
+ <request name="get_release">
+ <description summary="release fence for last-attached buffer">
+ Create a listener for the release of the buffer attached by the
+ client with wl_buffer.attach. See zwp_buffer_release_v1
+ documentation for more information.
+
+ The release object is double-buffered state, and will be applied
+ on the next wl_surface.commit request for the associated surface.
+
+ If a zwp_buffer_release_v1 object has already been requested for
+ the surface in the same commit cycle, a DUPLICATE_RELEASE error
+ is signaled to the client.
+
+ If the associated wl_surface was destroyed, a NO_SURFACE error
+ is signaled to the client.
+
+ If at surface commit time the attached buffer does not support
+ explicit synchronization, or there is no buffer attached, an
+ UNSUPPORTED_BUFFER error is raised.
+ </description>
+
+ <arg name="release" type="new_id" interface="zwp_buffer_release_v1"
+ summary="new zwp_buffer_release_v1 object"/>
+ </request>
+ </interface>
+
+ <interface name="zwp_buffer_release_v1" version="1">
+ <description summary="buffer release explicit synchronization">
+ This object is instantiated in response to a
+ zwp_surface_synchronization_v1.get_release request.
+
+ It provides an alternative to wl_buffer.release events, providing a unique
+ release from a single wl_surface.commit request. The release event also
+ supports explicit synchronization, providing a fence FD where relevant for
+ the client to synchronize against before reusing the buffer.
+
+ Exactly one event, either a fenced_release or an immediate_release, will
+ be emitted for each wl_surface.commit request.
+
+ This event does not replace wl_buffer.release events; servers are still
+ required to send those events.
+ </description>
+
+ <request name="destroy" type="destructor">
+ <description summary="destroy buffer release synchronization object">
+ Destroy this buffer release explicit synchronization object. The object
+ may be destroyed at any time.
+ </description>
+ </request>
+
+ <event name="fenced_release">
+ <description summary="release buffer with fence">
+ Sent when the compositor has finalised its usage of the associated
+ buffer for the relevant commit, providing a dma_fence which will be
+ signaled when all operations by the compositor on that buffer for that
+ commit have finished.
+
+ Clients must not perform any destructive operations (e.g. clearing or
+ rendering) on the buffer until that fence has signaled.
+ </description>
+ <arg name="fence" type="fd" summary="fence for last operation on buffer"/>
+ </event>
+
+ <event name="immediate_release">
+ <description summary="release buffer immediately">
+ Sent when the compositor has finalised its usage of the associated
+ buffer for the relevant commit, and either performed no operations
+ using it, or has a guarantee that all its operations on that buffer for
+ that commit have finished, and any destructive operations on the buffer
+ will have no external effects.
+ </description>
+ </event>
+ </interface>
+
+</protocol>

--
2.19.1

Pekka Paalanen

2018-10-31 11:22:41 UTC

Permalink

On Thu, 18 Oct 2018 16:48:53 +0300

Hi Alf,

looks even better! Just few details below I'd still like to clarify.

Post by Alexandros Frantzis
Makefile.am | 1 +
.../linux-explicit-synchronization/README | 6 +
...x-explicit-synchronization-unstable-v1.xml | 232 ++++++++++++++++++
3 files changed, 239 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 0000000..f13b404
--- /dev/null
+++ b/unstable/linux-explicit-synchronization/README
@@ -0,0 +1,6 @@
+Linux explicit synchronization (dma-fence) protocol
+
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 0000000..4800756
--- /dev/null
+++ b/unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml
@@ -0,0 +1,232 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="zwp_linux_explicit_synchronization_unstable_v1">
+
+ <copyright>
+ 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 Software without restriction, including without limitation
+ the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ and/or sell copies of the Software, and to permit persons to whom the
+
+ The above copyright notice and this permission notice (including the next
+ paragraph) shall be included in all copies or substantial portions of the
+ Software.
+
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ DEALINGS IN THE SOFTWARE.
+ </copyright>
+
+ <interface name="zwp_linux_explicit_synchronization_v1" version="1">
+ <description summary="protocol for providing explicit synchronization">
+ This global is a factory interface, allowing clients to request
+ explicit synchronization for buffers on a per-surface basis.
+
+ See zwp_surface_synchronization_v1 for more information.
+
+ This interface is derived from Chromium's
+ zcr_linux_explicit_synchronization_v1.
+
+ Warning! The protocol described in this file is experimental and
+ backward incompatible changes may be made. Backward compatible changes
+ may be added together with the corresponding interface version bump.
+ Backward incompatible changes are done by bumping the version number in
+ the protocol and interface names and resetting the interface version.
+ Once the protocol is to be declared stable, the 'z' prefix and the
+ version number in the protocol and interface names are removed and the
+ interface version number is reset.
+ </description>
+
+ <request name="destroy" type="destructor">
+ <description summary="destroy explicit synchronization factory object">
+ Destroy this explicit synchronization factory object. Other objects,
+ including zwp_surface_synchronization_v1 objects created by this
+ factory, shall not be affected by this request.
+ </description>
+ </request>
+
+ <enum name="error">
+ <entry name="synchronization_exists" value="0"
+ summary="the surface already has a synchronization object associated"/>
+ </enum>
+
+ <request name="get_synchronization">
+ <description summary="extend surface interface for explicit synchronization">
+ Instantiate an interface extension for the given wl_surface to provide
+ explicit synchronization.
+
+ If the given wl_surface already has an explicit synchronization object
+ associated, the synchronization_exists protocol error is raised.
+ </description>
+
+ <arg name="id" type="new_id" interface="zwp_surface_synchronization_v1"
+ summary="the new synchronization interface id"/>
+ <arg name="surface" type="object" interface="wl_surface"
+ summary="the surface"/>
+ </request>
+ </interface>
+
+ <interface name="zwp_surface_synchronization_v1" version="1">
+ <description summary="per-surface explicit synchronization support">
+ This object implements per-surface explicit synchronization.
+
+ Synchronization refers to co-ordination of pipelined operations performed
+ on buffers. Most GPU clients will schedule an asynchronous operation to
+ render to the buffer, then immediately send the buffer to the compositor
+ to be attached to a surface.
+
+ In implicit synchronization, ensuring that the rendering operation is
+ complete before the compositor displays the buffer is an implementation
+ detail handled by either the kernel or userspace graphics driver.
+
+ By contrast, in explicit synchronization, dma_fence objects mark when the
+ asynchronous operations are complete. When submitting a buffer, the
+ client provides an acquire fence which will be waited on before the
+ compositor accesses the buffer. The Wayland server, through a
+ zwp_buffer_release_v1 object, will inform the client with an event which
+ may be accompanied by a release fence, when the buffer can be
+ destructively accessed.

Since this is actually handled per-commit, unlike the old
wl_buffer.release event which is defined as "can be destructively
accessed", the wording here could be more like:

"when the compositor will no longer access the buffer contents due to
the specific commit that requested the release event."

It's hard to word clearly and conscisely, but I hope you get the idea
of how this different from "can be destructively accessed" which is a
global concept rather than tied to a specific commit. A client may do
several commits on same or different wl_surfaces, and only after they
all have signalled the explicit fence release, the destructive access is
harmless.

The reason why https://gitlab.freedesktop.org/wayland/wayland/issues/46
is essentially unsolvable without new protocol is that
wl_buffer.release is not tied to a specific commit. If a client commits
the same buffer several times (same or different wl_surfaces), it
cannot know how many wl_buffer.release events it needs before the
buffer really is free due to asynchronicity of the protocol.

Therefore to me the point that the new release event is scoped only to
the specific commit is very important.

Post by Alexandros Frantzis
+
+ Each surface can be associated with only one object of this interface at
+ any time.
+
+ Explicit synchronization is guaranteed to be supported only for buffers
+ created with any version of the zwp_linux_dmabuf buffer factory.

Maybe this limitation should be for set_acquire_fence only? See below
about get_release.

Post by Alexandros Frantzis
+ </description>
+
+ <request name="destroy" type="destructor">
+ <description summary="destroy synchronization object">
+ Destroy this explicit synchronization object.
+
+ Any fence set by this object with set_acquire_fence since the last
+ commit will be discarded by the server. Any fences set by this object
+ before the last commit are not affected.
+
+ zwp_buffer_release_v1 objects created by this object are not affected
+ by this request.
+ </description>
+ </request>
+
+ <enum name="error">
+ <entry name="invalid_fence" value="0"
+ summary="the fence specified by the client could not be imported"/>
+ <entry name="duplicate_fence" value="1"
+ summary="multiple fences added for a single surface commit"/>
+ <entry name="duplicate_release" value="2"
+ summary="multiple releases added for a single surface commit"/>
+ <entry name="no_surface" value="3"
+ summary="the associated wl_surface was destroyed"/>
+ <entry name="unsupported_buffer" value="4"
+ summary="the buffer does not support explicit synchronization"/>
+ </enum>
+
+ <request name="set_acquire_fence">
+ <description summary="set the acquire fence">
+ Set the acquire fence that must be signaled before the compositor
+ may sample from the buffer attached with wl_buffer_attach. The fence
+ is a dma_fence kernel object.
+
+ The acquire fence is double-buffered state, and will be applied on the
+ next wl_surface.commit request for the associated surface. Thus, it
+ applies only to the buffer that is attached to the surface at commit
+ time.
+
+ If the fence could not be imported, an INVALID_FENCE error is raised.

Should we allow raising INVALID_FENCE on wl_surface.commit, or are we
sure the import happens in full at set_acquire_fence time?

Post by Alexandros Frantzis
+
+ If a fence has already been attached during the same commit cycle, a
+ DUPLICATE_FENCE error is raised.
+
+ If the associated wl_surface was destroyed, a NO_SURFACE error is
+ raised.
+
+ If at surface commit time the attached buffer does not support explicit
+ synchronization, or there is no buffer attached, an UNSUPPORTED_BUFFER
+ error is raised.
+ </description>
+ <arg name="fd" type="fd" summary="acquire fence fd"/>
+ </request>
+
+ <request name="get_release">
+ <description summary="release fence for last-attached buffer">
+ Create a listener for the release of the buffer attached by the
+ client with wl_buffer.attach. See zwp_buffer_release_v1
+ documentation for more information.
+
+ The release object is double-buffered state, and will be applied
+ on the next wl_surface.commit request for the associated surface.
+
+ If a zwp_buffer_release_v1 object has already been requested for
+ the surface in the same commit cycle, a DUPLICATE_RELEASE error
+ is signaled to the client.
+
+ If the associated wl_surface was destroyed, a NO_SURFACE error
+ is signaled to the client.
+
+ If at surface commit time the attached buffer does not support
+ explicit synchronization, or there is no buffer attached, an
+ UNSUPPORTED_BUFFER error is raised.

Is UNSUPPORTED_BUFFER error actually necessary here? Why would the
buffer type affect whether the compositor can service a
zwp_buffer_release object or not?

In the worst case, the compositor will not be able to provide release
fence fd, in which case it can always rely on immediate_release event.

If we allow get_release for all buffer types, immediate_release becomes
like wl_buffer.release but scoped to the specific commit, fixing
https://gitlab.freedesktop.org/wayland/wayland/issues/46 for everything.

It will be up to the client to decide to use get_release on whether it
can handle both immediate_release and fenced_release.

Post by Alexandros Frantzis
+ </description>
+
+ <arg name="release" type="new_id" interface="zwp_buffer_release_v1"
+ summary="new zwp_buffer_release_v1 object"/>
+ </request>
+ </interface>
+
+ <interface name="zwp_buffer_release_v1" version="1">
+ <description summary="buffer release explicit synchronization">
+ This object is instantiated in response to a
+ zwp_surface_synchronization_v1.get_release request.
+
+ It provides an alternative to wl_buffer.release events, providing a unique
+ release from a single wl_surface.commit request. The release event also
+ supports explicit synchronization, providing a fence FD where relevant for
+ the client to synchronize against before reusing the buffer.
+
+ Exactly one event, either a fenced_release or an immediate_release, will
+ be emitted for each wl_surface.commit request.

Should we add something like: "The compositor can choose release by
release which event it uses."

Just to underline that clients really need to be prepared to deal with
both kinds if they use get_release?

Or is already clear enough?

Post by Alexandros Frantzis
+
+ This event does not replace wl_buffer.release events; servers are still
+ required to send those events.
+ </description>
+
+ <request name="destroy" type="destructor">
+ <description summary="destroy buffer release synchronization object">
+ Destroy this buffer release explicit synchronization object. The object
+ may be destroyed at any time.
+ </description>
+ </request>

We can keep the destroy request for now, removing it would be just a
minor optimization.

Post by Alexandros Frantzis
+
+ <event name="fenced_release">
+ <description summary="release buffer with fence">
+ Sent when the compositor has finalised its usage of the associated
+ buffer for the relevant commit, providing a dma_fence which will be
+ signaled when all operations by the compositor on that buffer for that
+ commit have finished.
+
+ Clients must not perform any destructive operations (e.g. clearing or
+ rendering) on the buffer until that fence has signaled.
+ </description>
+ <arg name="fence" type="fd" summary="fence for last operation on buffer"/>
+ </event>
+
+ <event name="immediate_release">
+ <description summary="release buffer immediately">
+ Sent when the compositor has finalised its usage of the associated
+ buffer for the relevant commit, and either performed no operations
+ using it, or has a guarantee that all its operations on that buffer for
+ that commit have finished, and any destructive operations on the buffer
+ will have no external effects.
+ </description>
+ </event>
+ </interface>
+
+</protocol>

Thanks,
pq

Simon Ser

2018-11-01 22:10:40 UTC

Permalink

Hi Alexandros,

Here are a few comments about someone who doesn't know a lot about
explicit synchronization. Let me know if I got something wrong. :)

Overall this looks pretty good.

Post by Alexandros Frantzis
---
- Guarantee protocol compatibility only with zwp_linux_dmabuf buffers.
- Add the UNSUPPORTED_BUFFER error.
- 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.
- 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.
patch v1 here: https://patchwork.freedesktop.org/patch/177866/
Makefile.am | 1 +
.../linux-explicit-synchronization/README | 6 +
...x-explicit-synchronization-unstable-v1.xml | 232 ++++++++++++++++++
3 files changed, 239 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 0000000..f13b404
--- /dev/null
+++ b/unstable/linux-explicit-synchronization/README
@@ -0,0 +1,6 @@
+Linux explicit synchronization (dma-fence) protocol
+

diff --git a/unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml > b/unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml

Post by Alexandros Frantzis
new file mode 100644
index 0000000..4800756
--- /dev/null
+++ b/unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml
@@ -0,0 +1,232 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="zwp_linux_explicit_synchronization_unstable_v1">
+
+ <copyright>
+ 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 Software without restriction, including without limitation
+ the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ and/or sell copies of the Software, and to permit persons to whom the
+
+ The above copyright notice and this permission notice (including the next
+ paragraph) shall be included in all copies or substantial portions of the
+ Software.
+
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ DEALINGS IN THE SOFTWARE.
+ </copyright>
+
+ <interface name="zwp_linux_explicit_synchronization_v1" version="1">
+ <description summary="protocol for providing explicit synchronization">
+ This global is a factory interface, allowing clients to request
+ explicit synchronization for buffers on a per-surface basis.
+
+ See zwp_surface_synchronization_v1 for more information.
+
+ This interface is derived from Chromium's
+ zcr_linux_explicit_synchronization_v1.
+
+ Warning! The protocol described in this file is experimental and
+ backward incompatible changes may be made. Backward compatible changes
+ may be added together with the corresponding interface version bump.
+ Backward incompatible changes are done by bumping the version number in
+ the protocol and interface names and resetting the interface version.
+ Once the protocol is to be declared stable, the 'z' prefix and the
+ version number in the protocol and interface names are removed and the
+ interface version number is reset.
+ </description>
+
+ <request name="destroy" type="destructor">
+ <description summary="destroy explicit synchronization factory object">
+ Destroy this explicit synchronization factory object. Other objects,
+ including zwp_surface_synchronization_v1 objects created by this
+ factory, shall not be affected by this request.
+ </description>
+ </request>
+
+ <enum name="error">
+ <entry name="synchronization_exists" value="0"
+ summary="the surface already has a synchronization object associated"/>
+ </enum>
+
+ <request name="get_synchronization">
+ <description summary="extend surface interface for explicit synchronization">
+ Instantiate an interface extension for the given wl_surface to provide
+ explicit synchronization.
+
+ If the given wl_surface already has an explicit synchronization object
+ associated, the synchronization_exists protocol error is raised.
+ </description>
+
+ <arg name="id" type="new_id" interface="zwp_surface_synchronization_v1"
+ summary="the new synchronization interface id"/>
+ <arg name="surface" type="object" interface="wl_surface"
+ summary="the surface"/>
+ </request>
+ </interface>
+
+ <interface name="zwp_surface_synchronization_v1" version="1">
+ <description summary="per-surface explicit synchronization support">
+ This object implements per-surface explicit synchronization.
+
+ Synchronization refers to co-ordination of pipelined operations performed
+ on buffers. Most GPU clients will schedule an asynchronous operation to
+ render to the buffer, then immediately send the buffer to the compositor
+ to be attached to a surface.
+
+ In implicit synchronization, ensuring that the rendering operation is
+ complete before the compositor displays the buffer is an implementation
+ detail handled by either the kernel or userspace graphics driver.
+
+ By contrast, in explicit synchronization, dma_fence objects mark when the
+ asynchronous operations are complete. When submitting a buffer, the
+ client provides an acquire fence which will be waited on before the
+ compositor accesses the buffer. The Wayland server, through a
+ zwp_buffer_release_v1 object, will inform the client with an event which
+ may be accompanied by a release fence, when the buffer can be
+ destructively accessed.
+
+ Each surface can be associated with only one object of this interface at
+ any time.
+
+ Explicit synchronization is guaranteed to be supported only for buffers
+ created with any version of the zwp_linux_dmabuf buffer factory.

I think we can drop the "z" prefix here.

wl_buffer.attach

I wonder if failures to import a fence should really be protocol errors.
Protocol errors are meant to be used for protocol violations. I understand that
a client can send an invalid fence, but are there other reasons why a fence
cannot be imported? Maybe we could change this to "if the file descriptor isn't
a dma_fence"?

Post by Alexandros Frantzis
+ If a fence has already been attached during the same commit cycle, a
+ DUPLICATE_FENCE error is raised.
+
+ If the associated wl_surface was destroyed, a NO_SURFACE error is
+ raised.
+
+ If at surface commit time the attached buffer does not support explicit
+ synchronization, or there is no buffer attached, an UNSUPPORTED_BUFFER
+ error is raised.
+ </description>
+ <arg name="fd" type="fd" summary="acquire fence fd"/>
+ </request>
+
+ <request name="get_release">
+ <description summary="release fence for last-attached buffer">
+ Create a listener for the release of the buffer attached by the
+ client with wl_buffer.attach. See zwp_buffer_release_v1
+ documentation for more information.
+
+ The release object is double-buffered state, and will be applied
+ on the next wl_surface.commit request for the associated surface.

"will be applied" is a little bit strange for this request. Maybe change to
"will provide release information about the next wl_surface.commit request"?

Post by Alexandros Frantzis
+ If a zwp_buffer_release_v1 object has already been requested for
+ the surface in the same commit cycle, a DUPLICATE_RELEASE error
+ is signaled to the client.
+
+ If the associated wl_surface was destroyed, a NO_SURFACE error
+ is signaled to the client.
+
+ If at surface commit time the attached buffer does not support
+ explicit synchronization, or there is no buffer attached, an
+ UNSUPPORTED_BUFFER error is raised.

I agree with pq here. It would be nice to be able to use this request on any
buffer type.

Post by Alexandros Frantzis
+ </description>
+

Extra line here

Post by Alexandros Frantzis
+ <arg name="release" type="new_id" interface="zwp_buffer_release_v1"
+ summary="new zwp_buffer_release_v1 object"/>
+ </request>
+ </interface>
+
+ <interface name="zwp_buffer_release_v1" version="1">
+ <description summary="buffer release explicit synchronization">
+ This object is instantiated in response to a
+ zwp_surface_synchronization_v1.get_release request.
+
+ It provides an alternative to wl_buffer.release events, providing a unique
+ release from a single wl_surface.commit request. The release event also
+ supports explicit synchronization, providing a fence FD where relevant for
+ the client to synchronize against before reusing the buffer.
+
+ Exactly one event, either a fenced_release or an immediate_release, will
+ be emitted for each wl_surface.commit request.

This makes it sound like this object can be used for multiple commits. Maybe we
can change the wording to "will be emitted after the wl_surface.commit request".

Post by Alexandros Frantzis
+ This event does not replace wl_buffer.release events; servers are still
+ required to send those events.
+ </description>
+
+ <request name="destroy" type="destructor">
+ <description summary="destroy buffer release synchronization object">
+ Destroy this buffer release explicit synchronization object. The object
+ may be destroyed at any time.
+ </description>
+ </request>
+
+ <event name="fenced_release">
+ <description summary="release buffer with fence">
+ Sent when the compositor has finalised its usage of the associated
+ buffer for the relevant commit, providing a dma_fence which will be
+ signaled when all operations by the compositor on that buffer for that
+ commit have finished.
+
+ Clients must not perform any destructive operations (e.g. clearing or
+ rendering) on the buffer until that fence has signaled.

We should probably add to this request and to immediate_release something among

Post by Alexandros Frantzis
Upon receiving this event, the client should destroy this object.
+ </description>
+ <arg name="fence" type="fd" summary="fence for last operation on buffer"/>
+ </event>
+
+ <event name="immediate_release">
+ <description summary="release buffer immediately">
+ Sent when the compositor has finalised its usage of the associated
+ buffer for the relevant commit, and either performed no operations
+ using it, or has a guarantee that all its operations on that buffer for
+ that commit have finished, and any destructive operations on the buffer
+ will have no external effects.
+ </description>
+ </event>
+ </interface>
+
+</protocol>
--
2.19.1
_______________________________________________
wayland-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Alexandros Frantzis

2018-11-02 16:40:54 UTC

Permalink

Post by Simon Ser
Hi Alexandros,
Here are a few comments about someone who doesn't know a lot about
explicit synchronization. Let me know if I got something wrong. :)
Overall this looks pretty good.

Hi Simon,

thanks for the review. My comments are below. I agree with everything I
have left out.

Post by Simon Ser

Post by Alexandros Frantzis
+ Explicit synchronization is guaranteed to be supported only for buffers
+ created with any version of the zwp_linux_dmabuf buffer factory.

I think we can drop the "z" prefix here.

Hmm, not sure about this. We would be using a protocol prefix/name
combination that doesn't exist (yet). Of course the intention is clear,
but I think it would be better to update this to, e.g.,
(z)wp_linux_dmabuf, when linux_dmabuf actually becomes stable.

Post by Simon Ser

Yes, the this is all about having a valid fence (and that's how it's
implemented in the WIP branch). Requiring something more from this
request would be asking too much, both from the server and the client. I
will rephrase.

It's unlikely that we won't be able to use valid fence at a later point.
If this happens it's most likely a driver issue (or we have messed up in
weston), in which case I think disconnecting the client is a valid
option (compared to allowing bad data on screen), but that's a different
case and error.

Post by Simon Ser

Post by Alexandros Frantzis
+ <request name="get_release">
+ <description summary="release fence for last-attached buffer">
+ Create a listener for the release of the buffer attached by the
+ client with wl_buffer.attach. See zwp_buffer_release_v1
+ documentation for more information.
+
+ The release object is double-buffered state, and will be applied
+ on the next wl_surface.commit request for the associated surface.

"will be applied" is a little bit strange for this request. Maybe change to
"will provide release information about the next wl_surface.commit request"?

"will be applied" tries to convey that the release will be associated
with the buffer that is attached at commit time (instead of any
intermediate attachments).

So, perhaps "will be associated with the buffer that is attached to the
surface at wl_surface.commit time"?

Post by Simon Ser

Post by Alexandros Frantzis
+ <interface name="zwp_buffer_release_v1" version="1">
+ <description summary="buffer release explicit synchronization">
+ This object is instantiated in response to a
+ zwp_surface_synchronization_v1.get_release request.
+
+ It provides an alternative to wl_buffer.release events, providing a unique
+ release from a single wl_surface.commit request. The release event also
+ supports explicit synchronization, providing a fence FD where relevant for
+ the client to synchronize against before reusing the buffer.
+
+ Exactly one event, either a fenced_release or an immediate_release, will
+ be emitted for each wl_surface.commit request.

This makes it sound like this object can be used for multiple commits. Maybe we
can change the wording to "will be emitted after the wl_surface.commit request".

Perhaps "will be emitted for the wl_surface.commit request", instead? My
concern is that "after" may be misread as the commit immediately
triggering an event (which, to be fair, doesn't make sense in this
context).

Post by Simon Ser

Post by Alexandros Frantzis
+ <event name="fenced_release">
+ <description summary="release buffer with fence">
+ Sent when the compositor has finalised its usage of the associated
+ buffer for the relevant commit, providing a dma_fence which will be
+ signaled when all operations by the compositor on that buffer for that
+ commit have finished.
+
+ Clients must not perform any destructive operations (e.g. clearing or
+ rendering) on the buffer until that fence has signaled.

We should probably add to this request and to immediate_release something among

Post by Alexandros Frantzis
Upon receiving this event, the client should destroy this object.

In v5 I am changing zwp_buffer_release to use destroy-on-event, so this
doesn't apply any more. Of course, the client should still destroy the
proxy, but I don't think this is something we need to explicitly state.

Thanks,
Alexandros

Simon Ser

2018-11-03 14:44:53 UTC