STRUCT DRM_SCHED_FENCE(9)

💅 struct drm_sched_fence(9) — the Kernel API Manual glow-up

okay bestie, so you're poking around in drm_sched_fence(9) — that's the DRM scheduler fence page, and honestly? It's giving "unsung hero of job scheduling" and we're gonna stan. ✨

This page lives in the Kernel API Manual, and it's all about the fences corresponding to the scheduling of a job. That's the whole NAME situation right there. 🎀

---

✨ SYNOPSIS ✨

no cap, here's the struct in all its glory — copy it exactly, don't touch a single character:

struct drm_sched_fence {
    struct dma_fence                scheduled;
    struct dma_fence                finished;
    ktime_t deadline;
    struct dma_fence                *parent;
    struct drm_gpu_scheduler        *sched;
    spinlock_t lock;
    void *owner;
    uint64_t drm_client_id;
 };

she's structured, she's specific, she's iconic. 💅

---

🫶 Members 🫶

the way each of these fields has a whole personality… let's go one by one:

• scheduled — this fence is what will be signaled by the scheduler when the job is scheduled. early vibes, first signal, main character energy for the "we're doing this" moment. 🌸
• finished — this fence is what will be signaled by the scheduler when the job is completed. the grand finale, the "ate and left no crumbs" fence. 🎀

ok so listen — when you're setting up an out fence for the job, use this one, because it's available immediately upon drm_sched_job_init. meanwhile the fence returned by the driver from run_job won't even be created until the dependencies have resolved. so yeah, finished is right there from the jump and that's why she's the one you want for an out fence. 🦋

• deadline — a ktime_t deadline set on drm_sched_fence.finished which potentially needs to be propagated to drm_sched_fence.parent. so she's not just a deadline, she's a deadline with responsibilities, potentially. ⏰
• parent — the fence returned by drm_sched_backend_ops.run_job when scheduling the job on hardware. we signal the drm_sched_fence.finished fence once parent is signalled. it's literally the whole "wait for your elder to move first" situation. 👑
• sched — the scheduler instance to which the job having this struct belongs to. your job's home base, its little scheduler family. 🏠
• lock — the lock used by the scheduled and the finished fences. shared custody of the lock, and honestly? mutual respect. 🔒
• owner — job owner for debugging. so when things go weird you know who did this. 💀
• drm_client_id — the client_id of the drm_file which owns the job. the receipts, the paper trail, the whole "iykyk" of job ownership. 🧾

---

🌈 SEE ALSO 🌈

go read these next, bestie, they're all part of the same friend group:

• Kernel file ./include/drm/gpu_scheduler.h
• DRM_SCHED_FENCE_DONT_PIPELINE(9)
• DRM_SCHED_FENCE_FLAG_HAS_DEADLINE_BIT(9)
• struct drm_sched_entity(9)
• struct drm_sched_rq(9)
• struct drm_sched_job(9)
• enum drm_gpu_sched_stat(9)
• struct drm_sched_backend_ops(9)
• struct drm_gpu_scheduler(9)
• struct drm_sched_init_args(9)
• struct drm_sched_pending_job_iter(9)
• drm_sched_for_each_pending_job(9)

---

fr fr: every field above is doing real work and none of them are optional reading. slay responsibly. 💖

---

and that's the whole page, bestie — sourced from ./include/drm, dated October 2026, and yeah, struct drm_sched_fence(9) absolutely ate. periodt. 💅✨🦋💜