Linux Documentation
 help / color / mirror / Atom feed
From: Julian Orth <ju.orth@gmail.com>
To: "Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Maxime Ripard" <mripard@kernel.org>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"David Airlie" <airlied@gmail.com>,
	"Simona Vetter" <simona@ffwll.ch>,
	"Sumit Semwal" <sumit.semwal@linaro.org>,
	"Christian König" <christian.koenig@amd.com>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Shuah Khan" <skhan@linuxfoundation.org>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>
Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	 linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org,
	 linux-doc@vger.kernel.org, wayland-devel@lists.freedesktop.org,
	 ju.orth@gmail.com
Subject: [PATCH 00/12] misc/syncobj: add /dev/syncobj device
Date: Sat, 16 May 2026 13:06:03 +0200	[thread overview]
Message-ID: <20260516-jorth-syncobj-v1-0-88ede9d98a81@gmail.com> (raw)

This series adds a new device /dev/syncobj that can be used to create
and manipulate DRM syncobjs. Previously, these operations required the
use of a DRM device and the device needed to support the DRIVER_SYNCOBJ
and DRIVER_SYNCOBJ_TIMELINE features.

There are several issues with the existing API:

- Syncobjs are the only explicit sync mechanism available on wayland.
  Most compositors do not use GPU waits. Instead, they use the
  DRM_IOCTL_SYNCOBJ_EVENTFD ioctl to perform a CPU wait. Being tied to
  DRM devices means that compositors cannot consistently offer this
  feature even though no device-specific logic is involved.
- llvmpipe currently cannot offer syncobj interop because it does not
  have access to a DRM device. This means that applications using
  llvmpipe cannot present images before they have finished rendering,
  despite llvmpipe using threaded rendering.
- Clients that do not use the Vulkan WSI need to manually probe /dev/dri
  for devices that support the syncobj ioctls in order to use the
  wayland syncobj protocol.
- Similarly, clients that want to use screen capture have no equivalent
  to the WSI and are therefore forced into that path.
- Having to keep a DRM device open has potentially negative interactions
  with GPU hotplug.
- Having to translate between syncobj FDs and handles is troublesome in
  the compositor usecase since syncobjs come and go frequently and need
  to be cleaned up when clients disconnect.

/dev/syncobj solves these issues by providing all syncobj ioctls under a
consistent path that is not tied to any DRM device. It also operates
directly on file descriptors instead of syncobj handles.

The series starts with a number of small refactorings in drm_syncobj.c
to make its functionality available outside of the file and without the
need for drm_file/handle pairs.

The last commit adds the /dev/syncobj module. I've added it as a misc
device but maybe this should instead live somewhere under gpu/drm.

An application using the new interface can be found at [1].

[1]: https://github.com/mahkoh/jay/pull/947

---
Julian Orth (12):
      drm/syncobj: add drm_syncobj_from_fd
      drm/syncobj: add drm_syncobj_fence_lookup
      drm/syncobj: make drm_syncobj_array_wait_timeout public
      drm/syncobj: add drm_syncobj_register_eventfd
      drm/syncobj: have transfer functions accept drm_syncobj directly
      drm/syncobj: add drm_syncobj_transfer
      drm/syncobj: add drm_syncobj_timeline_signal
      drm/syncobj: add drm_syncobj_query
      drm/syncobj: fix resource leak in drm_syncobj_import_sync_file_fence
      drm/syncobj: add drm_syncobj_import_sync_file
      drm/syncobj: add drm_syncobj_export_sync_file
      misc/syncobj: add new device

 Documentation/userspace-api/ioctl/ioctl-number.rst |   1 +
 drivers/gpu/drm/drm_syncobj.c                      | 374 ++++++++++++++-----
 drivers/misc/Kconfig                               |  10 +
 drivers/misc/Makefile                              |   1 +
 drivers/misc/syncobj.c                             | 404 +++++++++++++++++++++
 include/drm/drm_syncobj.h                          |  21 ++
 include/uapi/linux/syncobj.h                       |  75 ++++
 7 files changed, 795 insertions(+), 91 deletions(-)
---
base-commit: 6916d5703ddf9a38f1f6c2cc793381a24ee914c6
change-id: 20260516-jorth-syncobj-d4d374c8c61b

Best regards,
--  
Julian Orth <ju.orth@gmail.com>


             reply	other threads:[~2026-05-16 11:06 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-16 11:06 Julian Orth [this message]
2026-05-16 11:06 ` [PATCH 01/12] drm/syncobj: add drm_syncobj_from_fd Julian Orth
2026-05-16 11:06 ` [PATCH 02/12] drm/syncobj: add drm_syncobj_fence_lookup Julian Orth
2026-05-16 11:06 ` [PATCH 03/12] drm/syncobj: make drm_syncobj_array_wait_timeout public Julian Orth
2026-05-16 11:06 ` [PATCH 04/12] drm/syncobj: add drm_syncobj_register_eventfd Julian Orth
2026-05-16 11:06 ` [PATCH 05/12] drm/syncobj: have transfer functions accept drm_syncobj directly Julian Orth
2026-05-16 11:06 ` [PATCH 06/12] drm/syncobj: add drm_syncobj_transfer Julian Orth
2026-05-16 11:06 ` [PATCH 07/12] drm/syncobj: add drm_syncobj_timeline_signal Julian Orth
2026-05-16 11:06 ` [PATCH 08/12] drm/syncobj: add drm_syncobj_query Julian Orth
2026-05-16 11:06 ` [PATCH 09/12] drm/syncobj: fix resource leak in drm_syncobj_import_sync_file_fence Julian Orth
2026-05-16 11:06 ` [PATCH 10/12] drm/syncobj: add drm_syncobj_import_sync_file Julian Orth
2026-05-16 11:06 ` [PATCH 11/12] drm/syncobj: add drm_syncobj_export_sync_file Julian Orth
2026-05-16 11:06 ` [PATCH 12/12] misc/syncobj: add new device Julian Orth
2026-05-16 11:37   ` Greg Kroah-Hartman
2026-05-16 11:38   ` Greg Kroah-Hartman
2026-05-16 12:08     ` Julian Orth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260516-jorth-syncobj-v1-0-88ede9d98a81@gmail.com \
    --to=ju.orth@gmail.com \
    --cc=airlied@gmail.com \
    --cc=arnd@arndb.de \
    --cc=christian.koenig@amd.com \
    --cc=corbet@lwn.net \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=simona@ffwll.ch \
    --cc=skhan@linuxfoundation.org \
    --cc=sumit.semwal@linaro.org \
    --cc=tzimmermann@suse.de \
    --cc=wayland-devel@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox