| Message ID | 20161027140516.22435-9-chris@chris-wilson.co.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Thu, Oct 27, 2016 at 03:05:16PM +0100, 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. Not in mesa yet, but use case would in supporting 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." i.e. PRIORITY_HIGH -> 1023 [privileged, will failback to 0] PRIORITY_MED -> 0 [default] PRIORITY_LOW -> -1023 Does anyone has a real use for this? On the transcode side? -Chris
On Thu, Oct 27, 2016 at 04:22:31PM +0100, Chris Wilson wrote: > On Thu, Oct 27, 2016 at 03:05:16PM +0100, 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. > > Not in mesa yet, but use case would in supporting 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." > > i.e. > PRIORITY_HIGH -> 1023 [privileged, will failback to 0] > PRIORITY_MED -> 0 [default] > PRIORITY_LOW -> -1023 > > Does anyone has a real use for this? On the transcode side? Also applies to VkQueue as each can have a distinct priority. Queues need a bit more work in the anv implmentation to marry the spec to a kernel context, mostly working out the details of QueueFamilies and the like and seeing if we require new abi. -Chris
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index e3b4412d0241..2da5ecad1f35 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -948,6 +948,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 34daef828dca..8df216eba490 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 */ dev_priv->kernel_context = ctx; DRM_DEBUG_DRIVER("%s context support initialized\n", @@ -1095,6 +1096,9 @@ int i915_gem_context_getparam_ioctl(struct drm_device *dev, void *data, case I915_CONTEXT_PARAM_NO_ERROR_CAPTURE: args->value = !!(ctx->flags & CONTEXT_NO_ERROR_CAPTURE); break; + case I915_CONTEXT_PARAM_PRIORITY: + args->value = ctx->priority; + break; default: ret = -EINVAL; break; @@ -1150,6 +1154,23 @@ int i915_gem_context_setparam_ioctl(struct drm_device *dev, void *data, ctx->flags &= ~CONTEXT_NO_ERROR_CAPTURE; } break; + + case I915_CONTEXT_PARAM_PRIORITY: + { + int priority = args->value; + + if (args->size) + ret = -EINVAL; + else if (priority >= I915_PRIORITY_MAX || + priority <= -I915_PRIORITY_MAX) + ret = -EINVAL; + else if (priority > 0 && !capable(CAP_SYS_ADMIN)) + ret = -EPERM; + else + ctx->priority = priority; + } + break; + default: ret = -EINVAL; break; diff --git a/drivers/gpu/drm/i915/i915_gem_request.c b/drivers/gpu/drm/i915/i915_gem_request.c index fabd29fde175..4bfccb3d0c2c 100644 --- a/drivers/gpu/drm/i915/i915_gem_request.c +++ b/drivers/gpu/drm/i915/i915_gem_request.c @@ -844,7 +844,7 @@ void __i915_add_request(struct drm_i915_gem_request *request, bool flush_caches) * run at the earliest possible convenience. */ if (engine->schedule) - engine->schedule(request, 0); + engine->schedule(request, request->ctx->priority); local_bh_disable(); i915_sw_fence_commit(&request->submit); diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h index f51d429feaae..9fa5eee64f6b 100644 --- a/include/uapi/drm/i915_drm.h +++ b/include/uapi/drm/i915_drm.h @@ -404,6 +404,8 @@ typedef struct drm_i915_irq_wait { /* Query whether DRM_I915_GEM_EXECBUFFER2 supports user defined execution * priorities and the driver will attempt to execute batches in priority order. + * The initial priority for each batch is supplied by the context and is + * controlled via I915_CONTEXT_PARAM_PRIORITY. */ #define I915_PARAM_HAS_SCHEDULER 43 @@ -1283,6 +1285,7 @@ struct drm_i915_gem_context_param { #define I915_CONTEXT_PARAM_NO_ZEROMAP 0x2 #define I915_CONTEXT_PARAM_GTT_SIZE 0x3 #define I915_CONTEXT_PARAM_NO_ERROR_CAPTURE 0x4 +#define I915_CONTEXT_PARAM_PRIORITY 0x5 __u64 value; };
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. Signed-off-by: Chris Wilson <chris@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(-)