Quoting Tvrtko Ursulin (2021-02-04 15:18:31)
>
> On 01/02/2021 08:56, Chris Wilson wrote:
> > Whether a scheduler chooses to implement timeslicing is up to it, and
> > not an underlying property of the HW engine. The scheduler does depend
> > on the HW supporting preemption.
>
> Therefore, continuing on the comment I made in the previous patch, if we
> had a helper with which engine would request scheduling (setting the
> tasklet), if it passed in a pointer to itself, scheduler would then be
> able to inspect if the engine supports preemption and so set its own
> internal flag. Makes sense? It would require something like:
Actually not keen on pushing the inspection into the core scheduler and
would rather have the backend turn it on for itself. Because it's not
just about the engine supporting preemption, it's about whether or not
the backend wants to bother implement timeslicing itself.
If we skip to the end, it looks like this for execlists:
i915_sched_init(&el->sched, i915->drm.dev,
engine->name, engine->mask,
&execlists_ops, engine);
if (IS_ACTIVE(CONFIG_DRM_I915_TIMESLICE_DURATION) &&
intel_engine_has_preemption(engine))
__set_bit(I915_SCHED_TIMESLICE_BIT, &el->sched.flags);
if (intel_engine_has_preemption(engine)) {
__set_bit(I915_SCHED_BUSYWAIT_BIT, &el->sched.flags);
__set_bit(I915_SCHED_PREEMPT_RESET_BIT, &el->sched.flags);
}
with the virtual scheduler:
ve->base.sched =
i915_sched_create(ve->base.i915->drm.dev,
ve->base.name,
ve->base.mask,
&virtual_ops, ve);
if (!ve->base.sched) {
err = -ENOMEM;
goto err_put;
}
ve->base.sched->flags |= sched; /* override submission method */
I think the virtual scheduler suggests that we can't rely on the
scheduler core to dtrt by itself. And if you are still awake by the time
we get to this point, how to avoid ve->base.sched->flags |= sched are
welcome.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
