From: "Chen, Junjia" <junjia.chen@intel.com>
To: intel-xe@lists.freedesktop.org
Cc: matthew.brost@intel.com, thomas.hellstrom@linux.intel.com,
rodrigo.vivi@intel.com, "Chen, Junjia" <junjia.chen@intel.com>
Subject: [PATCH] drm/xe: Unwrap sync fences before adding them as job dependencies
Date: Mon, 26 Oct 2026 10:07:21 +0800 [thread overview]
Message-ID: <20261026020721.973291-1-junjia.chen@intel.com> (raw)
A timeline syncobj point is a dma_fence_chain node that carries its own
fence context, separate from the contexts of the fences it wraps.
xe_sync_entry_add_deps() passed that container straight to
drm_sched_job_add_dependency().
drm_sched_entity_add_dependency_cb() only drops a dependency when the
fence context is one of the entity's own (fence_context or
fence_context + 1). A chain node never matches, so a wait on a point
whose inner fence is the finished fence of an earlier job on the same
exec queue is treated like a cross-queue dependency: the job is held
until the previous job has completed on the GPU. Every job queued
behind it waits too, and the ring drains before the next batch of jobs
is released.
Unwrap the fence with dma_fence_unwrap_for_each() and add each
unsignaled underlying fence as a dependency, so drm_sched sees the real
fence contexts and ignores same-entity fences. Dependencies on other
exec queues still wait for completion. drm_sched_job_add_dependency()
keeps only the latest fence per context, so the dependency array does
not grow with the length of the chain.
Signed-off-by: Chen, Junjia <junjia.chen@intel.com>
---
drivers/gpu/drm/xe/xe_sync.c | 28 +++++++++++++++++++++++++---
1 file changed, 25 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/xe/xe_sync.c b/drivers/gpu/drm/xe/xe_sync.c
index 06b1c913588a..73fe7f05ba16 100644
--- a/drivers/gpu/drm/xe/xe_sync.c
+++ b/drivers/gpu/drm/xe/xe_sync.c
@@ -6,6 +6,7 @@
#include "xe_sync.h"
#include <linux/dma-fence-array.h>
+#include <linux/dma-fence-unwrap.h>
#include <linux/kthread.h>
#include <linux/sched/mm.h>
#include <linux/uaccess.h>
@@ -233,9 +234,30 @@ ALLOW_ERROR_INJECTION(xe_sync_entry_parse, ERRNO);
int xe_sync_entry_add_deps(struct xe_sync_entry *sync, struct xe_sched_job *job)
{
- if (sync->fence)
- return drm_sched_job_add_dependency(&job->drm,
- dma_fence_get(sync->fence));
+ struct dma_fence_unwrap iter;
+ struct dma_fence *fence;
+ int err;
+
+ if (!sync->fence)
+ return 0;
+
+ /*
+ * Unwrap fence containers (e.g. dma_fence_chain from a timeline
+ * syncobj) so the scheduler sees the underlying fences. That lets it
+ * drop dependencies on jobs from the same entity and only wait for
+ * jobs on the same scheduler to be scheduled, rather than waiting for
+ * the container, which forces a full GPU completion wait and drains
+ * the queue.
+ */
+ dma_fence_unwrap_for_each(fence, &iter, sync->fence) {
+ if (dma_fence_is_signaled(fence))
+ continue;
+
+ err = drm_sched_job_add_dependency(&job->drm,
+ dma_fence_get(fence));
+ if (err)
+ return err;
+ }
return 0;
}
--
2.51.0
next reply other threads:[~2026-10-26 2:08 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-26 2:07 Chen, Junjia [this message]
2026-10-26 2:16 ` ✓ CI.KUnit: success for drm/xe: Unwrap sync fences before adding them as job dependencies Patchwork
2026-10-26 2:24 ` [PATCH] " sashiko-bot
2026-10-27 17:12 ` Matthew Brost
2026-10-26 2:51 ` ✓ Xe.CI.BAT: success for " Patchwork
2026-10-26 3:59 ` ✗ Xe.CI.FULL: failure " Patchwork
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=20261026020721.973291-1-junjia.chen@intel.com \
--to=junjia.chen@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=matthew.brost@intel.com \
--cc=rodrigo.vivi@intel.com \
--cc=thomas.hellstrom@linux.intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.