Fwd: [PATCH wayland-protocols v6] Add zwp_linux_explicit_synchronization_v1

Daniel Stone daniel at fooishbar.org
Thu Nov 8 14:12:24 UTC 2018


Hi,

On Thu, 8 Nov 2018 at 13:01, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> On Wed, 07 Nov 2018 20:22:38 +0000 Simon Ser <contact at emersion.fr> wrote:
> > I missed this before, but: is there a reason why the "linux" prefix has been
> > dropped here? Maybe it should be renamed to
> > zwp_linux_surface_synchronization_v1? What about zwp_buffer_release_v1?
>
> That's a good question, because these names are kind of global. Not
> really global, but it could cause some name conflicts if the same
> program or a compilation unit needed to use two different but
> same-named interfaces. They are less global than the same of the global
> interface though, which needs to be unique per platform for real.
>
> The stable names would be wp_surface_synchronization and
> wp_buffer_release, with the root interface being
> wp_linux_explicit_synchronization.
>
> The dmabuf extension relies of the Linux definition of a dmabuf. This
> extension relies on the Linux definition of a fence, AFAIU.

There's precedence in Vulkan's external-sharing interfaces: one of the
semaphore import/export types is an 'opaque FD' which has
implementation-defined meaning. On the other hand, when this came up
last, NVIDIA said that it was only intended for reusable semaphores
whose lifetime roughly matched swapchain images. Apparently on their
driver stack, doing per-frame import of syncpoint-style fences has
crippling performance implications, so given that this extension's
semantics are so clearly tied to sync_file, it wouldn't be a good
match.

Wildcard option: if we could export DRM syncobjs between processes,
maybe that would be a better long-term solution than sync_file.

Cheers,
Daniel


More information about the wayland-devel mailing list