[Intel-gfx] [PATCH v2 09/11] drm/i915/scheduler: Support user-defined priorities

[Chris Wilson]

On Thu, Nov 10, 2016 at 01:02:08PM +0000, Tvrtko Ursulin wrote:
> 
> On 07/11/2016 13:59, Chris Wilson wrote:
> >Use a priority stored in the context as the initial value when
> >submitting a request. This allows us to change the default priority on a
> >per-context basis, allowing different contexts to be favoured with GPU
> >time at the expense of lower importance work. The user can adjust the
> >context's priority via I915_CONTEXT_PARAM_PRIORITY, with more positive
> >values being higher priority (they will be serviced earlier, after their
> >dependencies have been resolved). Any prerequisite work for an execbuf
> >will have its priority raised to match the new request as required.
> >
> >Normal users can specify any value in the range of -1023 to 0 [default],
> >i.e. they can reduce the priority of their workloads (and temporarily
> >boost it back to normal if so desired).
> >
> >Privileged users can specify any value in the range of -1023 to 1023,
> >[default is 0], i.e. they can raise their priority above all overs and
> >so potentially starve the system.
> >
> >Note that the existing schedulers are not fair, nor load balancing, the
> >execution is strictly by priority on a first-come, first-served basis,
> >and the driver may choose to boost some requests above the range
> >available to users.
> >
> >This priority was originally based around nice(2), but evolved to allow
> >clients to adjust their priority within a small range, and allow for a
> >privileged high priority range.
> >
> >For example, this can be used to implement EGL_IMG_context_priority
> >https://www.khronos.org/registry/egl/extensions/IMG/EGL_IMG_context_priority.txt
> >
> >	EGL_CONTEXT_PRIORITY_LEVEL_IMG determines the priority level of
> >        the context to be created. This attribute is a hint, as an
> >        implementation may not support multiple contexts at some
> >        priority levels and system policy may limit access to high
> >        priority contexts to appropriate system privilege level. The
> >        default value for EGL_CONTEXT_PRIORITY_LEVEL_IMG is
> >        EGL_CONTEXT_PRIORITY_MEDIUM_IMG."
> >
> >so we can map
> >
> >	PRIORITY_HIGH -> 1023 [privileged, will failback to 0]
> >	PRIORITY_MED -> 0 [default]
> >	PRIORITY_LOW -> -1023
> >
> >They also map onto the priorities used by VkQueue (and a VkQueue is
> >essentially a timeline, our i915_gem_context under full-ppgtt).
> >
> >Testcase: igt/gem_exec_schedule
> >Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> >---
> > drivers/gpu/drm/i915/i915_drv.h         |  1 +
> > drivers/gpu/drm/i915/i915_gem_context.c | 21 +++++++++++++++++++++
> > drivers/gpu/drm/i915/i915_gem_request.c |  2 +-
> > include/uapi/drm/i915_drm.h             |  3 +++
> > 4 files changed, 26 insertions(+), 1 deletion(-)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> >index 5c658c6d06e4..d253aeee0fb2 100644
> >--- a/drivers/gpu/drm/i915/i915_drv.h
> >+++ b/drivers/gpu/drm/i915/i915_drv.h
> >@@ -949,6 +949,7 @@ struct i915_gem_context {
> > 	/* Unique identifier for this context, used by the hw for tracking */
> > 	unsigned int hw_id;
> > 	u32 user_handle;
> >+	int priority; /* greater priorities are serviced first */
> >
> > 	u32 ggtt_alignment;
> >
> >diff --git a/drivers/gpu/drm/i915/i915_gem_context.c b/drivers/gpu/drm/i915/i915_gem_context.c
> >index 6dd475735f0a..48b5aacf5fc2 100644
> >--- a/drivers/gpu/drm/i915/i915_gem_context.c
> >+++ b/drivers/gpu/drm/i915/i915_gem_context.c
> >@@ -476,6 +476,7 @@ int i915_gem_context_init(struct drm_device *dev)
> > 		return PTR_ERR(ctx);
> > 	}
> >
> >+	ctx->priority = -I915_PRIORITY_MAX; /* lowest priority; idle task */
> 
> Does this matter at all? What are we submitting from the kernel
> context? If we are some things then is it even correct?

We idle from the kernel context, we issue rc6 setup in case userspace
hasn't. Yes, everything we do today is of lowest priority, and
arbitrarily boosting a request is not a problem for the kernel (but we
don't support deboosting).
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre