On Thu, 5 Mar 2026 01:10:06 -0800 Matthew Brost <[email protected]> wrote:
> I can't say I agree with either of you here. > > In about an hour, I seemingly have a bypass path working in DRM sched + > Xe, and my diff is: > > 108 insertions(+), 31 deletions(-) First of all, I'm not blindly rejecting the approach, see how I said "I'm not thrilled" not "No way!". So yeah, if you have something to propose, feel free to post the diff here or as an RFC on the ML. Secondly, I keep thinking the fast-path approach doesn't quite fix the problem at hand where we actually want queuing/dequeuing operations to match the priority of the HW/FW context, because if your HW context is high prio but you're struggling to fill the HW queue, it's not truly high prio. Note that it's problem that was made more evident with FW scheduling (and the 1:1 entity:sched association), before that we just had one thread that was dequeuing from entities and pushing to HW queues based on entities priorities, so priority was somehow better enforced. So yeah, even ignoring the discrepancy that might emerge from this new fast-path-run_job (and the potential maintenance burden we mentioned), saying "you'll get proper queueing/dequeuing priority enforcement only if you have no deps, and the pipeline is not full" is kinda limited IMHO. I'd rather we think about a solution that solves the entire problem, which both the kthread_work[er] and workqueue(RT) proposals do.
