Linux Documentation
 help / color / mirror / Atom feed
From: "Michel Dänzer" <michel.daenzer@mailbox.org>
To: "Christian König" <christian.koenig@amd.com>,
	"Xaver Hugl" <xaver.hugl@kde.org>
Cc: Julian Orth <ju.orth@gmail.com>,
	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>,
	Jonathan Corbet <corbet@lwn.net>,
	Shuah Khan <skhan@linuxfoundation.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	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
Subject: Re: [PATCH 00/12] misc/syncobj: add /dev/syncobj device
Date: Wed, 20 May 2026 10:13:42 +0200	[thread overview]
Message-ID: <385a4d4f-fe22-41a7-8d4b-4dc6bc9930d3@mailbox.org> (raw)
In-Reply-To: <dff60378-4e47-4753-8878-feec6e1c2690@amd.com>

On 5/19/26 18:00, Christian König wrote:
> On 5/19/26 17:31, Xaver Hugl wrote:
>> Am Di., 19. Mai 2026 um 15:29 Uhr schrieb Christian König
>> <christian.koenig@amd.com>:
>>>> 1. This series makes the ability to manipulate syncobjs available
>>>> independently of attached hardware.
>>>> 2. It makes it available under a consistent path /dev/syncobj.
>>>
>>> Exactly that is a big no-go. This has to be under /dev/dri.
>> FWIW udmabuf is also under /dev directly, but I don't think any
>> compositor developer would complain about a different path.
>> What are the rules for that? Could this simply be put in /dev/dri/syncobj?
> 
> The syncobj are actually the DRM specific way of doing things. The general kernel wide way is to use sync files (see drivers/dma-buf/sync_file.c).
> 
> But there has already been tons of problems with those sync files. E.g. they doesn't support your use case at all since they don't have wait before submit behavior.
> 
> So there are already ways to do this, but the Linux kernel so far told everybody that this is forbidden. The DRM syncobj wait before signal functionality is much better, but then basically the second try to do this.

I'm not quite sure what you're getting at here, just to be clear though:

While the syncobj Wayland protocol extension supports wait-before-submit behaviour at the Wayland protocol level, it doesn't need or cause wait-before-submit behaviour for DMA fences in the kernel. The usual rules apply to fences attached to syncobj timeline points. The wait-before-submit behaviour at the Wayland protocol level comes from allowing submit before a fence is attached to the acquire timeline point.

(It took me a while to realize this distinction, before which I mistakenly thought the kernel's DMA fence rules would prohibit wait-before-submit behaviour at the Wayland protocol level as well)


-- 
Earthling Michel Dänzer       \        GNOME / Xwayland / Mesa developer
https://redhat.com             \               Libre software enthusiast

  parent reply	other threads:[~2026-05-20  8:13 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-16 11:06 [PATCH 00/12] misc/syncobj: add /dev/syncobj device Julian Orth
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-19  8:22   ` Christian König
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
2026-05-18 12:06   ` Christian König
2026-05-18 12:10     ` Julian Orth
2026-05-18 11:58 ` [PATCH 00/12] misc/syncobj: add /dev/syncobj device Christian König
2026-05-18 12:02   ` Julian Orth
2026-05-18 12:41     ` Christian König
2026-05-18 12:58       ` Julian Orth
2026-05-19  8:18         ` Christian König
2026-05-19 13:19           ` Julian Orth
2026-05-19 13:28             ` Christian König
2026-05-19 15:31               ` Xaver Hugl
2026-05-19 16:00                 ` Christian König
2026-05-19 17:08                   ` Xaver Hugl
2026-05-20  8:08                     ` Christian König
2026-05-20 12:33                       ` Xaver Hugl
2026-05-20 14:06                         ` Christian König
2026-05-20 15:27                           ` Xaver Hugl
2026-05-20  8:13                   ` Michel Dänzer [this message]
2026-05-20 11:21                     ` Christian König
2026-05-20 11:46                       ` Julian Orth
2026-05-18 14:59       ` Michel Dänzer
2026-05-18 15:06         ` Christian König

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=385a4d4f-fe22-41a7-8d4b-4dc6bc9930d3@mailbox.org \
    --to=michel.daenzer@mailbox.org \
    --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=ju.orth@gmail.com \
    --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 \
    --cc=xaver.hugl@kde.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