From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mout-p-102.mailbox.org (mout-p-102.mailbox.org [80.241.56.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 74B7822A1D4 for ; Tue, 17 Feb 2026 14:35:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=80.241.56.152 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771338943; cv=none; b=U+6kWugLgQ0t/uwLLlSCcg1U4yzjKGEglrMUqp5g9ihu+FWF1VEcqkZdiAfPU3FYH/z62rAWPG4/Vko7uhIFa2y9e3ZxWuPZjFA3MH6mu2kyChhqUIwBVCcOCUCrssHCha0cufq5hzsApcqqv2bMO65RgXkt8szFURdB0op7o1E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771338943; c=relaxed/simple; bh=zdRcl083tpVjzyV9nr8+1CRjWjuYy/BgyAyzkKizFIc=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=nd0fdQ5bg6mq9HtO6BQhzXyalKQNTr5kSjVKR6p7etDpN6md7/J49cZnoIMfDUJoiCfEwOEhqHNdqXBxtenJCOxYu25OfmEvC8b4ZFq6UPl5oTwScfkH2bgPaFBToqMzk3/qx1ZlgR2pR/Q6o0IEhwX67JqmmFLCFwmC8PZcITk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=mailbox.org; spf=pass smtp.mailfrom=mailbox.org; dkim=pass (2048-bit key) header.d=mailbox.org header.i=@mailbox.org header.b=HQ3nWvvr; arc=none smtp.client-ip=80.241.56.152 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=mailbox.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=mailbox.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=mailbox.org header.i=@mailbox.org header.b="HQ3nWvvr" Received: from smtp2.mailbox.org (smtp2.mailbox.org [IPv6:2001:67c:2050:b231:465::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-102.mailbox.org (Postfix) with ESMTPS id 4fFhyD14ncz9vCR; Tue, 17 Feb 2026 15:35:32 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailbox.org; s=mail20150812; t=1771338932; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=A0dHkxmFy7+DKPcEgpCbUndQJ65vJ+JUT/5C+W5zYGQ=; b=HQ3nWvvrm7pYOEgtTcxu+A3sgFQ6ta+EnDaSXuGU0rnoBUvG4DyEJzuVbMA6CdEYGbwFF7 wAQ5LYp/GXpthN+kV2brh2rzIb58DteJgvINS/f+l9kutBjycpAP6IiAFRK3l4C5q6NTAN Qi3B5XIX1ySmnCa5xtNzRAa+Uu/dFBCgfEI71TO6vliZ9Z8krQ6DvmnXGtTlCQiOLuoI3o I7G54VQaAjVdQzLrezBBA8elaDjwNKAMt9TxpvoVRqAD1RAXtSN0kw99toFP2gwjvvZL2K eYMqRwdRTjcSc5Va10MdDyiahSQuNLoT73F7KTkkxdA0n1E72QYe1IBJc0wMrg== Message-ID: Date: Tue, 17 Feb 2026 15:35:29 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [RFC PATCH v1 1/2] drm/syncobj: Add DRM_IOCTL_SYNCOBJ_QUERY_ERROR to query fence error status To: =?UTF-8?Q?Christian_K=C3=B6nig?= , Yicong Hui 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 References: <20260213120836.81283-1-yiconghui@gmail.com> <20260213120836.81283-2-yiconghui@gmail.com> From: =?UTF-8?Q?Michel_D=C3=A4nzer?= Content-Language: en-CA In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-MBO-RS-ID: c999ce441b44b3a0f8d X-MBO-RS-META: 69nbhqzmgfcbwhjpzmuqbbhz33ppwgbk Adding the wayland-devel list for Wayland compositor developers. Also adding the mesa-dev list for Mesa developers, though note that this list isn't really active anymore. You might want to create an MR or Gitlab issue to get feedback from Mesa developers. 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. Xwayland uses drmSyncobjTimelineWait to check if a syncobj timeline point has a fence / has signalled, it also uses drmSyncobjEventfd similarly to mutter though. -- Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast