1. 07 Oct, 2017 6 commits
  2. 06 Oct, 2017 19 commits
  3. 05 Oct, 2017 7 commits
  4. 04 Oct, 2017 8 commits
    • Chris Wilson's avatar
      drm/i915/scheduler: Support user-defined priorities · ac14fbd4
      Chris Wilson authored
      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: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Reviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171003203453.15692-9-chris@chris-wilson.co.uk
      ac14fbd4
    • Chris Wilson's avatar
      drm/i915/execlists: Preemption! · beecec90
      Chris Wilson authored
      When we write to ELSP, it triggers a context preemption at the earliest
      arbitration point (3DPRIMITIVE, some PIPECONTROLs, a few other
      operations and the explicit MI_ARB_CHECK). If this is to the same
      context, it triggers a LITE_RESTORE where the RING_TAIL is merely
      updated (used currently to chain requests from the same context
      together, avoiding bubbles). However, if it is to a different context, a
      full context-switch is performed and it will start to execute the new
      context saving the image of the old for later execution.
      
      Previously we avoided preemption by only submitting a new context when
      the old was idle. But now we wish embrace it, and if the new request has
      a higher priority than the currently executing request, we write to the
      ELSP regardless, thus triggering preemption, but we tell the GPU to
      switch to our special preemption context (not the target). In the
      context-switch interrupt handler, we know that the previous contexts
      have finished execution and so can unwind all the incomplete requests
      and compute the new highest priority request to execute.
      
      It would be feasible to avoid the switch-to-idle intermediate by
      programming the ELSP with the target context. The difficulty is in
      tracking which request that should be whilst maintaining the dependency
      change, the error comes in with coalesced requests. As we only track the
      most recent request and its priority, we may run into the issue of being
      tricked in preempting a high priority request that was followed by a
      low priority request from the same context (e.g. for PI); worse still
      that earlier request may be our own dependency and the order then broken
      by preemption. By injecting the switch-to-idle and then recomputing the
      priority queue, we avoid the issue with tracking in-flight coalesced
      requests. Having tried the preempt-to-busy approach, and failed to find
      a way around the coalesced priority issue, Michal's original proposal to
      inject an idle context (based on handling GuC preemption) succeeds.
      
      The current heuristic for deciding when to preempt are only if the new
      request is of higher priority, and has the privileged priority of
      greater than 0. Note that the scheduler remains unfair!
      
      v2: Disable for gen8 (bdw/bsw) as we need additional w/a for GPGPU.
      Since, the feature is now conditional and not always available when we
      have a scheduler, make it known via the HAS_SCHEDULER GETPARAM (now a
      capability mask).
      v3: Stylistic tweaks.
      v4: Appease Joonas with a snippet of kerneldoc, only to fuel to fire of
      the preempt vs preempting debate.
      Suggested-by: default avatarMichal Winiarski <michal.winiarski@intel.com>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Michal Winiarski <michal.winiarski@intel.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Cc: Ben Widawsky <benjamin.widawsky@intel.com>
      Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
      Cc: Zhi Wang <zhi.a.wang@intel.com>
      Reviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171003203453.15692-8-chris@chris-wilson.co.uk
      beecec90
    • Chris Wilson's avatar
      drm/i915: Expand I915_PARAM_HAS_SCHEDULER into a capability bitmask · bf64e0b0
      Chris Wilson authored
      In the next few patches, we wish to enable different features for the
      scheduler, some which may subtlety change ABI (e.g. allow requests to be
      reordered under different circumstances). So we need to make sure
      userspace is cognizant of the changes (if they care), by which we employ
      the usual method of a GETPARAM. We already have an
      I915_PARAM_HAS_SCHEDULER (which notes the existing ability to reorder
      requests to avoid bubbles), and now we wish to extend that to be a
      bitmask to describe the different capabilities implemented.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171003203453.15692-7-chris@chris-wilson.co.uk
      bf64e0b0
    • Chris Wilson's avatar
      drm/i915/execlists: Keep request->priority for its lifetime · 1f181225
      Chris Wilson authored
      With preemption, we will want to "unsubmit" a request, taking it back
      from the hw and returning it to the priority sorted execution list. In
      order to know where to insert it into that list, we need to remember
      its adjust priority (which may change even as it was being executed).
      
      This also affects reset for execlists as we are now unsubmitting the
      requests following the reset (rather than directly writing the ELSP for
      the inflight contexts). This turns reset into an accidental preemption
      point, as after the reset we may choose a different pair of contexts to
      submit to hw.
      
      GuC is not updated as this series doesn't add preemption to the GuC
      submission, and so it can keep benefiting from the early pruning of the
      DFS inside execlists_schedule() for a little longer. We also need to
      find a way of reducing the cost of that DFS...
      
      v2: Include priority in error-state
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Michał Winiarski <michal.winiarski@intel.com>
      Reviewed-by: default avatarMichał Winiarski <michal.winiarski@intel.com>
      Reviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171003203453.15692-6-chris@chris-wilson.co.uk
      1f181225
    • Chris Wilson's avatar
      drm/i915/execlists: Move bdw GPGPU w/a to emit_bb · 3ad7b52d
      Chris Wilson authored
      Move the re-enabling of MI arbitration from a per-bb w/a buffer to the
      emission of the batch buffer itself.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171003203453.15692-5-chris@chris-wilson.co.uk
      3ad7b52d
    • Chris Wilson's avatar
      drm/i915: Introduce a preempt context · e7af3116
      Chris Wilson authored
      Add another perma-pinned context for using for preemption at any time.
      We cannot just reuse the existing kernel context, as first and foremost
      we need to ensure that we can preempt the kernel context itself, so
      require a distinct context id. Similar to the kernel context, we may
      want to interrupt execution and switch to the preempt context at any
      time, and so it needs to be permanently pinned and available.
      
      To compensate for yet another permanent allocation, we shrink the
      existing context and the new context by reducing their ringbuffer to the
      minimum.
      
      v2: Assert that we never allocate a request from the preemption context.
      v3: Limit perma-pin to engines that may preempt.
      v4: Onion cleanup for early driver death
      v5: Onion ordering in main driver cleanup as well.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarMichał Winiarski <michal.winiarski@intel.com>
      Reviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171003203453.15692-4-chris@chris-wilson.co.uk
      e7af3116
    • Chris Wilson's avatar
      drm/i915/execlists: Distinguish the incomplete context notifies · d6c05113
      Chris Wilson authored
      Let the listener know that the context we just scheduled out was not
      complete, and will be scheduled back in at a later point.
      
      v2: Handle CONTEXT_STATUS_PREEMPTED in gvt by aliasing it to
      CONTEXT_STATUS_OUT for the moment, gvt can expand upon the difference
      later.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: "Zhenyu Wang" <zhenyuw@linux.intel.com>
      Cc: "Wang, Zhi A" <zhi.a.wang@intel.com>
      Cc: Michał Winiarski <michal.winiarski@intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Reviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171003203453.15692-3-chris@chris-wilson.co.uk
      d6c05113
    • Michał Winiarski's avatar
      drm/i915/preempt: Default to disabled mid-command preemption levels · 5152defe
      Michał Winiarski authored
      Supporting fine-granularity preemption levels may require changes in
      userspace batch buffer programming. Therefore, we need to fallback to
      safe default values, rather that use hardware defaults. Userspace is
      still able to enable fine-granularity, since we're whitelisting the
      register controlling it in WaEnablePreemptionGranularityControlByUMD.
      
      v2: Extend w/a to cover Cannonlake
      v3: Fix commentary to include both fake w/a names.
      Signed-off-by: default avatarMichał Winiarski <michal.winiarski@intel.com>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171003203453.15692-2-chris@chris-wilson.co.uk
      5152defe