From: "Michel Dänzer" <michel.daenzer@mailbox.org>
To: "Christian König" <christian.koenig@amd.com>,
"Yicong Hui" <yiconghui@gmail.com>
Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
skhan@linuxfoundation.org, david.hunter.linux@gmail.com,
wayland-devel@lists.freedesktop.org,
mesa-dev@lists.freedesktop.org
Subject: Re: [RFC PATCH v1 1/2] drm/syncobj: Add DRM_IOCTL_SYNCOBJ_QUERY_ERROR to query fence error status
Date: Wed, 18 Feb 2026 15:49:49 +0100 [thread overview]
Message-ID: <e750ca62-8a2e-47e2-b154-c7cdaf5e270e@mailbox.org> (raw)
In-Reply-To: <0e7c3ee9-54b1-4ecc-b960-6e2fda6ab3ae@amd.com>
On 2/17/26 15:45, Christian König wrote:
> On 2/17/26 15:35, Michel Dänzer wrote:
>> On 2/17/26 11:29, Christian König wrote:
>>>>
>>>> @@ -732,6 +732,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
>>>> DRM_IOCTL_DEF(DRM_IOCTL_MODE_LIST_LESSEES, drm_mode_list_lessees_ioctl, DRM_MASTER),
>>>> DRM_IOCTL_DEF(DRM_IOCTL_MODE_GET_LEASE, drm_mode_get_lease_ioctl, DRM_MASTER),
>>>> DRM_IOCTL_DEF(DRM_IOCTL_MODE_REVOKE_LEASE, drm_mode_revoke_lease_ioctl, DRM_MASTER),
>>>> + DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_QUERY_ERROR, drm_syncobj_query_error_ioctl,
>>>> + DRM_RENDER_ALLOW),
>>>
>>> My educated guess is that userspace doesn't want to call this IOCTL separately because of performance reasons.
>>>
>>> Instead add some additional flag to DRM_SYNCOBJ_WAIT_FLAGS_* so that the IOCTL aborts the wait and returns an error as soon as it sees any fence with an error.
>>>
>>> Another DRM_SYNCOBJ_QUERY_FLAGS_* is potentially also useful to query the error on a number of drm_syncobjs at the same time.
>>>
>>> But in general since this is not a HW feature the userspace developers need to voice their requirements and explain how they want to have that implemented.
>>
>> mutter currently doesn't use the syncobj-specific ioctls to wait for a syncobj (timeline point) to signal / check if it has. Instead, it uses drmSyncobjEventfd / drmSyncobjExportSyncFile to get an eventfd / sync_file representing the timeline point / fence, then checks the status of the fd and waits for it to signal using generic poll()-style functionality. So unless the error condition can be communicated via the latter (and plumbed through glib APIs), mutter would need to check for fence errors separately.
>
> Good point, poll() has a POLLERR flag for that but I have no idea if eventfd supports that in any way. So potentially doable as well but a bit more work.
>
> Using a new DRM_SYNCOBJ_QUERY_FLAGS_ERROR on all signaled syncobj as separate way to query if there was an error should work for you in the meantime?
Yeah should be fine, though if POLLERR is possible, that might save constantly calling into the kernel to check for an error status that won't happen the vast majority of the time?
The bigger question might be what user space can do with the error status. I wrote down some ideas for mutter in https://gitlab.gnome.org/GNOME/mutter/-/issues/4624 .
--
Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer
https://redhat.com \ Libre software enthusiast
next prev parent reply other threads:[~2026-02-18 14:50 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-13 12:08 [RFC PATCH v1 0/2] Starter task: Querying errors from Yicong Hui
2026-02-13 12:08 ` [RFC PATCH v1 1/2] drm/syncobj: Add DRM_IOCTL_SYNCOBJ_QUERY_ERROR to query fence error status Yicong Hui
2026-02-17 10:29 ` Christian König
2026-02-17 11:35 ` Yicong Hui
2026-02-17 14:35 ` Michel Dänzer
2026-02-17 14:45 ` Christian König
2026-02-18 14:49 ` Michel Dänzer [this message]
2026-02-19 0:15 ` Yicong Hui
2026-02-19 7:31 ` Christian König
2026-02-13 12:08 ` [RFC PATCH v1 2/2] drm/syncobj/doc: Remove starter task from todo list Yicong Hui
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=e750ca62-8a2e-47e2-b154-c7cdaf5e270e@mailbox.org \
--to=michel.daenzer@mailbox.org \
--cc=christian.koenig@amd.com \
--cc=david.hunter.linux@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mesa-dev@lists.freedesktop.org \
--cc=skhan@linuxfoundation.org \
--cc=wayland-devel@lists.freedesktop.org \
--cc=yiconghui@gmail.com \
/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
all inboxes | Powered by JetHome®