kernel/git/stable/linux.git/include/drm/gpu_scheduler.h, branch master

BackMerge tag 'v7.2' into drm-next

2026-08-20T00:58:44+00:00

Linux 7.2 There was a lot of conflicts this round between fixes and next, and I'd like to get the merge resolutions that we have in drm-tip. Signed-off-by: Dave Airlie

Revert "drm/sched: Remove FIFO and RR and simplify to a single run queue"

2026-08-11T16:34:10+00:00

This reverts commit 77a6809f1dc39376116f8d769a0d2630dc95ad79. Signed-off-by: Tvrtko Ursulin Cc: Luke.Wildhardt@proton.me Cc: Matthew Brost Cc: Danilo Krummrich Cc: Philipp Stanner Cc: Christian König Signed-off-by: Tvrtko Ursulin Link: https://lore.kernel.org/r/20260811163139.99746-18-tvrtko.ursulin@igalia.com

Revert "drm/sched: Embed run queue singleton into the scheduler"

2026-08-11T16:34:06+00:00

This reverts commit 16e7698bc04d3dd19d95a688e4b0297a0e28a93b. Signed-off-by: Tvrtko Ursulin Cc: Luke.Wildhardt@proton.me Cc: Matthew Brost Cc: Danilo Krummrich Cc: Philipp Stanner Cc: Christian König Signed-off-by: Tvrtko Ursulin Link: https://lore.kernel.org/r/20260811163139.99746-17-tvrtko.ursulin@igalia.com

Revert "drm/sched: Remove drm_sched_init_args->num_rqs"

2026-08-11T16:34:00+00:00

This reverts commit d09339388b778f04dd9e638befa2594c9cb4290b. Signed-off-by: Tvrtko Ursulin Cc: Luke.Wildhardt@proton.me Cc: Matthew Brost Cc: Danilo Krummrich Cc: Philipp Stanner Cc: Christian König Signed-off-by: Tvrtko Ursulin Link: https://lore.kernel.org/r/20260811163139.99746-2-tvrtko.ursulin@igalia.com

drm/sched: Remove relic from entity docu

2026-07-06T08:53:51+00:00

commit 4827d6d83f07 ("drm/sched: Remove racy hack from drm_sched_fini()") removed the necessity to mark an entity as stopped in drm_sched_fini(). The documentation, however, still details that. Update sched_entity's documentation. Acked-by: Danilo Krummrich Signed-off-by: Philipp Stanner Link: https://patch.msgid.link/20260629083631.2547199-2-phasta@kernel.org

drm/sched: Remove drm_sched_init_args->num_rqs

2026-04-17T12:43:30+00:00

Remove member no longer used by the scheduler core and the drivers. Signed-off-by: Tvrtko Ursulin Cc: Christian König Cc: Danilo Krummrich Cc: Matthew Brost Cc: Philipp Stanner Acked-by: Danilo Krummrich Tested-by: Vitaly Prosyak Signed-off-by: Philipp Stanner Link: https://patch.msgid.link/20260417103744.76020-30-tvrtko.ursulin@igalia.com

drm/sched: Embed run queue singleton into the scheduler

2026-04-17T12:43:29+00:00

Now that the run queue to scheduler relationship is always 1:1 we can embed it (the run queue) directly in the scheduler struct and save on some allocation error handling code and such. Signed-off-by: Tvrtko Ursulin Cc: Christian König Cc: Danilo Krummrich Cc: Matthew Brost Cc: Philipp Stanner Acked-by: Danilo Krummrich Tested-by: Vitaly Prosyak Signed-off-by: Philipp Stanner Link: https://patch.msgid.link/20260417103744.76020-15-tvrtko.ursulin@igalia.com

drm/sched: Remove FIFO and RR and simplify to a single run queue

2026-04-17T12:43:29+00:00

Since the new FAIR policy is in general better than FIFO and almost as good as round-robin in interactive use cases, plus the latter has not been the default policy in a long time, we can afford to remove both and leave just FAIR. By doing so we can simplify the scheduler code by making the scheduler to run queue relationship always 1:1 and remove some code. Also, now that the FIFO policy is gone the tree of entities is not a FIFO tree any more so rename it to just the tree. Signed-off-by: Tvrtko Ursulin Cc: Christian König Cc: Danilo Krummrich Cc: Matthew Brost Cc: Philipp Stanner Acked-by: Danilo Krummrich Tested-by: Vitaly Prosyak Signed-off-by: Philipp Stanner Link: https://patch.msgid.link/20260417103744.76020-14-tvrtko.ursulin@igalia.com

drm/sched: Favour interactive clients slightly

2026-04-17T12:43:28+00:00

GPUs do not always implement preemption and DRM scheduler definitely does not support it at the front end scheduling level. This means execution quanta can be quite long and is controlled by userspace, consequence of which is picking the "wrong" entity to run can have a larger negative effect than it would have with a virtual runtime based CPU scheduler. Another important consideration is that rendering clients often have shallow submission queues, meaning they will be entering and exiting the scheduler's runnable queue often. Relevant scenario here is what happens when an entity re-joins the runnable queue with other entities already present. One cornerstone of the virtual runtime algorithm is to let it re-join at the head and rely on the virtual runtime accounting and timeslicing to sort it out. However, as explained above, this may not work perfectly in the GPU world. Entity could always get to overtake the existing entities, or not, depending on the submission order and rbtree equal key insertion behaviour. Allow interactive jobs to overtake entities already queued up for the limited case when interactive entity is re-joining the queue after being idle. This gives more opportunity for the compositors to have their rendering executed before the GPU hogs even if they have been configured with the same scheduling priority. To classify a client as interactive we look at its average job duration versus the average for the whole scheduler. We can track this easily by plugging into the existing job runtime tracking and applying the exponential moving average window on the past submissions. Then, all other things being equal, we let the more interactive jobs go first. Signed-off-by: Tvrtko Ursulin Cc: Christian König Cc: Danilo Krummrich Cc: Matthew Brost Cc: Philipp Stanner Cc: Pierre-Eric Pelloux-Prayer Acked-by: Danilo Krummrich Tested-by: Vitaly Prosyak Signed-off-by: Philipp Stanner Link: https://patch.msgid.link/20260417103744.76020-12-tvrtko.ursulin@igalia.com

drm/sched: Add fair scheduling policy

2026-04-17T12:43:28+00:00

The FAIR scheduling policy is built upon the same concepts as the well known CFS CPU scheduler - entity run queue is sorted by the virtual GPU time consumed by entities in a way that the entity with least vruntime runs first. It is able to avoid total priority starvation, which is one of the problems with FIFO, and it also does not need for per priority run queues. As it scales the actual GPU runtime by an exponential factor as the priority decreases, the virtual runtime for low priority entities grows faster than for normal priority, pushing them further down the runqueue order for the same real GPU time spent. Apart from this fundamental fairness, fair policy is especially strong in oversubscription workloads where it is able to give more GPU time to short and bursty workloads when they are running in parallel with GPU heavy clients submitting deep job queues. Signed-off-by: Tvrtko Ursulin Cc: Christian König Cc: Danilo Krummrich Cc: Matthew Brost Cc: Philipp Stanner Cc: Pierre-Eric Pelloux-Prayer Acked-by: Danilo Krummrich Tested-by: Vitaly Prosyak Signed-off-by: Philipp Stanner Link: https://patch.msgid.link/20260417103744.76020-11-tvrtko.ursulin@igalia.com