On Wed, 2017-09-27 at 17:44 +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. > > 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). > > v2: s/CAP_SYS_ADMIN/CAP_SYS_NICE/ > v3: Report min/max user priorities as defines in the uapi, and rebase > internal priorities on the exposed values. > > Testcase: igt/gem_exec_schedule > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> We should be good to go once Mesa is. Reviewed-by: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx> Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
