Signed-off-by: Alexandros Frantzis <alexandros.frant...@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 <reve...@chromium.org> +Daniel Stone <dani...@collabora.com> +Alexandros Frantzis <alexandros.frant...@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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel