[PATCH 15/57] drm/i915: Introduce the scheduling mode

[Chris Wilson]

Quoting Tvrtko Ursulin (2021-02-05 16:47:37)
> 
> On 05/02/2021 01:18, Chris Wilson wrote:
> > +/**
> > + * enum i915_sched_mode - how the scheduler may reorder requests
> > + *
> > + * The foundational principle of scheduling is that it controls the order
> > + * of execution of tasks within the system. Given a set of ready requests,
> > + * we may choose not to reorder them [FIFO] or submit them in a priority
> > + * order. The basic ordering is by user assigned priority [PRIORITY], the
> > + * highest priority requests are executed first. A revision of that is
> > + * to execute them in order of a virtual deadline, which is a fair, budget
> > + * conserving exection order [DEADLINE]. In both PRIORITY and DEADLINE, we
> > + * have to consider priority inversion that may arise when higher priority
> > + * work depends on low priority work, and so we track the work dependencies
> > + * and when we need to execute higher priority work, we raise the priority
> > + * of all of its dependecies so that it is not block.
> > + *
> > + * With no active scheduler [NONE], the execution order is fixed by order of
> > + * submission, due to ordering via a global resource such as the legacy
> > + * shared ringbuffer. Since we cannot reorder the requests at all, we
> > + * mark this as an inactive scheduler, and do not track any dependencies.
> > + */
> > +enum i915_sched_mode {
> > +     I915_SCHED_MODE_NONE = -1, /* inactive, no bubble prevention */
> > +     I915_SCHED_MODE_FIFO, /* pass-through of ready, first in first out */
> > +     I915_SCHED_MODE_PRIORITY, /* reorder strictly by priority */
> > +};
> 
> No deadline yet (mentioned in the comment), however would deadline even 
> be the right enum to use. What would you set it as GuC?

GuC, at the moment, would select FIFO. Since it is just using the queue
to passthrough requests, so we only use the extra lists if we want to
suspend submission using the scheduler, or if we exhaust the guc and
need to queue while waiting for resources.

(I put a couple of bypasses into the scheduler so we opt out of either
the DFS for deadlines or priorities.)

Now I remember that I need to separate the caps reported to userspace
from the mode.

> And why would userspace need to know anything more than FIFO or "some 
> smarter reordering"? Maybe timeslicing. Those three sound like generic 
> concepts. Can scheduler re-order, can it timeslice. And actually if it 
> can't re-order then it is FIFO by implication so two flags might be enough.

Currently, we use the scheduler.caps & PRIORITY as the switch for
allowing gem_context_set_priority(). That does make sense, as we use
that also to determine if we support context priorities in GL and
Vulkan. I think compute gained something similar.

Priority seems useful.

Timeslicing (as the superset of preemption + semaphores) I thought was
useful as it is the indicator as to whether or not it is truly safe to
use semaphores in userspace.

> I am definitely not sure about deadline flag later in the series. I mean 
> as exposed to userspace at any level more serious than debugfs.

I called the cap FAIR to try not to say anything about the implementation
but the intention. This was just a nice to know (i.e. something we
advertise to big tenant customers for them to quickly check if all is ok),
I don't have a plan on how to use it, apart from including it in bug
reports just in case. Other than I foresee the guc seeing that flag as an
excuse to skip gem_exec_fair :(
-Chris