On 09/01/2025 14:44, Michel Dänzer wrote:
On 2025-01-09 14:31, Tvrtko Ursulin wrote:
On 09/01/2025 11:38, Michel Dänzer wrote:
On 2024-12-30 17:52, Tvrtko Ursulin wrote:
diff --git a/drivers/gpu/drm/scheduler/sched_fence.c b/drivers/gpu/drm/scheduler/sched_fence.c
index 0f35f009b9d3..dfc7f50d4e0d 100644
--- a/drivers/gpu/drm/scheduler/sched_fence.c
+++ b/drivers/gpu/drm/scheduler/sched_fence.c
@@ -168,6 +168,8 @@ static void drm_sched_fence_set_deadline_finished(struct dma_fence *f,
spin_unlock_irqrestore(&fence->lock, flags);
+ drm_sched_entity_set_deadline(fence->entity, deadline);
AFAICT sync_file_ioctl_set_deadline passes through the unmodified deadline from user space. If the scheduler uses that directly, all user space can fake unlimited high priority for its jobs via the ioctl?
Yes, that wouldn't be great. I could only allow high priority contexts/entities to have their deadlines respected.
FWIW, there are more wrinkles here:
The user-space entity which sets the fence deadline isn't necessarily the one which submitted the corresponding GPU job, e.g. it could be the Wayland compositor. Not sure offhand whether the scheduling priority of the GPU job submitter and/or fence deadline setter should be taken into account in this case.
Hmm excellent point. Is that how things typically work? Compositors
setting deadlines on fences received from clients?
If the fence deadline is later than the original scheduler deadline based on job submission time and scheduling priority, should the scheduling deadline be moved back or not?
In the RFC I only pull in if fence deadline is sooner which I think
makes more sense.
I hope the uapi side of deadlines did not make any hard promises. Well obviously it did not since it is not wired up at the moment anyway.
Right, I guess it's essentially a hint by when user space would like the fence to have signalled if possible.
I also need to improve it and pull in the internal deadline to some time before the userspace one.
Because the internal deadline corresponds to when the job starts executing, whereas the fence deadline to when it finishes? Not sure how that can be accounted for though, not knowing how long the job will take to execute.
Yes exactly. It would have to be heuristics. But likely something would
be better than nothing.
In summary, I'm not sure using the fence deadline for the scheduler one really makes sense after all.
IMO it doesn't have to be perfect. Just if we find a clean way which
improves real uses cases.
Regards,
Tvrtko
