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
