An error occurred fetching the project authors.
  1. 02 Apr, 2019 1 commit
  2. 31 Mar, 2019 1 commit
  3. 27 Mar, 2019 1 commit
  4. 25 Mar, 2019 1 commit
  5. 24 Mar, 2019 1 commit
  6. 22 Mar, 2019 3 commits
  7. 21 Mar, 2019 4 commits
  8. 19 Mar, 2019 1 commit
  9. 15 Mar, 2019 1 commit
  10. 09 Mar, 2019 1 commit
  11. 08 Mar, 2019 6 commits
  12. 06 Mar, 2019 1 commit
  13. 05 Mar, 2019 1 commit
  14. 28 Feb, 2019 1 commit
  15. 20 Feb, 2019 1 commit
  16. 19 Feb, 2019 1 commit
    • Chris Wilson's avatar
      drm/i915: Use time based guilty context banning · 7f4127c4
      Chris Wilson authored
      Currently, we accumulate each time a context hangs the GPU, offset
      against the number of requests it submits, and if that score exceeds a
      certain threshold, we ban that context from submitting any more requests
      (cancelling any work in flight). In contrast, we use a simple timer on
      the file, that if we see more than a 9 hangs faster than 60s apart in
      total across all of its contexts, we will ban the client from creating
      any more contexts. This leads to a confusing situation where the file
      may be banned before the context, so lets use a simple timer scheme for
      each.
      
      If the context submits 3 hanging requests within a 120s period, declare
      it forbidden to ever send more requests.
      
      This has the advantage of not being easy to repair by simply sending
      empty requests, but has the disadvantage that if the context is idle
      then it is forgiven. However, if the context is idle, it is not
      disrupting the system, but a hog can evade the request counting and
      cause much more severe disruption to the system.
      
      Updating ban_score from request retirement is dubious as the retirement
      is purposely not in sync with request submission (i.e. we try and batch
      retirement to reduce overhead and avoid latency on submission), which
      leads to surprising situations where we can forgive a hang immediately
      due to a backlog of requests from before the hang being retired
      afterwards.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Reviewed-by: default avatarMika Kuoppala <mika.kuoppala@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190219122215.8941-2-chris@chris-wilson.co.uk
      7f4127c4
  17. 18 Feb, 2019 1 commit
  18. 05 Feb, 2019 4 commits
    • Chris Wilson's avatar
      drm/i915: Pull i915_gem_active into the i915_active family · 21950ee7
      Chris Wilson authored
      Looking forward, we need to break the struct_mutex dependency on
      i915_gem_active. In the meantime, external use of i915_gem_active is
      quite beguiling, little do new users suspect that it implies a barrier
      as each request it tracks must be ordered wrt the previous one. As one
      of many, it can be used to track activity across multiple timelines, a
      shared fence, which fits our unordered request submission much better. We
      need to steer external users away from the singular, exclusive fence
      imposed by i915_gem_active to i915_active instead. As part of that
      process, we move i915_gem_active out of i915_request.c into
      i915_active.c to start separating the two concepts, and rename it to
      i915_active_request (both to tie it to the concept of tracking just one
      request, and to give it a longer, less appealing name).
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190205130005.2807-5-chris@chris-wilson.co.uk
      21950ee7
    • Tvrtko Ursulin's avatar
      drm/i915/selftests: Context SSEU reconfiguration tests · c06ee6ff
      Tvrtko Ursulin authored
      Exercise the context image reconfiguration logic for idle and busy
      contexts, with the resets thrown into the mix as well.
      
      Free from the uAPI restrictions this test runs on all Gen9+ platforms
      with slice power gating.
      
      v2:
       * Rename some helpers for clarity.
       * Include subtest names in error logs.
       * Remove unnecessary function export.
      
      v3:
       * Rebase for RUNTIME_INFO.
      
      v4:
       * Fix incomplete unexport from v2. (Chris Wilson)
      
      v5:
       * Rebased for runtime pm api changes.
      
      v6:
       * Rebased for i915_reset.c.
      
      v7:
       * Tidy checkpatch warnings.
       * Consolidate error checking and logging a bit.
       * Skip idle test phase if something failed before it.
      
      v8:
       (Chris Wilson)
       * Fix i915_request_wait error handling.
       * No need to PIN_HIGH the VMA.
       * Remove pointless GEM_BUG_ON before pointer dereference.
      
      v9:
       * Avoid rq leak if rpcs query fails. (Chris)
      Signed-off-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> # v6
      Link: https://patchwork.freedesktop.org/patch/msgid/20190205095032.22673-5-tvrtko.ursulin@linux.intel.com
      c06ee6ff
    • Tvrtko Ursulin's avatar
      drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only) · e46c2e99
      Tvrtko Ursulin authored
      We want to allow userspace to reconfigure the subslice configuration on a
      per context basis.
      
      This is required for the functional requirement of shutting down non-VME
      enabled sub-slices on Gen11 parts.
      
      To do so, we expose a context parameter to allow adjustment of the RPCS
      register stored within the context image (and currently not accessible via
      LRI).
      
      If the context is adjusted before first use or whilst idle, the adjustment
      is for "free"; otherwise if the context is active we queue a request to do
      so (using the kernel context), following all other activity by that
      context, which is also marked as barrier for all following submission
      against the same context.
      
      Since the overhead of device re-configuration during context switching can
      be significant, especially in multi-context workloads, we limit this new
      uAPI to only support the Gen11 VME use case. In this use case either the
      device is fully enabled, and exactly one slice and half of the subslices
      are enabled.
      
      Example usage:
      
      	struct drm_i915_gem_context_param_sseu sseu = { };
      	struct drm_i915_gem_context_param arg = {
      		.param = I915_CONTEXT_PARAM_SSEU,
      		.ctx_id = gem_context_create(fd),
      		.size = sizeof(sseu),
      		.value = to_user_pointer(&sseu)
      	};
      
      	/* Query device defaults. */
      	gem_context_get_param(fd, &arg);
      
      	/* Set VME configuration on a 1x6x8 part. */
      	sseu.slice_mask = 0x1;
      	sseu.subslice_mask = 0xe0;
      	gem_context_set_param(fd, &arg);
      
      v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu()
          (Lionel)
      
      v3: Add ability to program this per engine (Chris)
      
      v4: Move most get_sseu() into i915_gem_context.c (Lionel)
      
      v5: Validate sseu configuration against the device's capabilities (Lionel)
      
      v6: Change context powergating settings through MI_SDM on kernel context
          (Chris)
      
      v7: Synchronize the requests following a powergating setting change using
          a global dependency (Chris)
          Iterate timelines through dev_priv.gt.active_rings (Tvrtko)
          Disable RPCS configuration setting for non capable users
          (Lionel/Tvrtko)
      
      v8: s/union intel_sseu/struct intel_sseu/ (Lionel)
          s/dev_priv/i915/ (Tvrtko)
          Change uapi class/instance fields to u16 (Tvrtko)
          Bump mask fields to 64bits (Lionel)
          Don't return EPERM when dynamic sseu is disabled (Tvrtko)
      
      v9: Import context image into kernel context's ppgtt only when
          reconfiguring powergated slice/subslices (Chris)
          Use aliasing ppgtt when needed (Michel)
      
      Tvrtko Ursulin:
      
      v10:
       * Update for upstream changes.
       * Request submit needs a RPM reference.
       * Reject on !FULL_PPGTT for simplicity.
       * Pull out get/set param to helpers for readability and less indent.
       * Use i915_request_await_dma_fence in add_global_barrier to skip waits
         on the same timeline and avoid GEM_BUG_ON.
       * No need to explicitly assign a NULL pointer to engine in legacy mode.
       * No need to move gen8_make_rpcs up.
       * Factored out global barrier as prep patch.
       * Allow to only CAP_SYS_ADMIN if !Gen11.
      
      v11:
       * Remove engine vfunc in favour of local helper. (Chris Wilson)
       * Stop retiring requests before updates since it is not needed
         (Chris Wilson)
       * Implement direct CPU update path for idle contexts. (Chris Wilson)
       * Left side dependency needs only be on the same context timeline.
         (Chris Wilson)
       * It is sufficient to order the timeline. (Chris Wilson)
       * Reject !RCS configuration attempts with -ENODEV for now.
      
      v12:
       * Rebase for make_rpcs.
      
      v13:
       * Centralize SSEU normalization to make_rpcs.
       * Type width checking (uAPI <-> implementation).
       * Gen11 restrictions uAPI checks.
       * Gen11 subslice count differences handling.
       Chris Wilson:
       * args->size handling fixes.
       * Update context image from GGTT.
       * Postpone context image update to pinning.
       * Use i915_gem_active_raw instead of last_request_on_engine.
      
      v14:
       * Add activity tracker on intel_context to fix the lifetime issues
         and simplify the code. (Chris Wilson)
      
      v15:
       * Fix context pin leak if no space in ring by simplifying the
         context pinning sequence.
      
      v16:
       * Rebase for context get/set param locking changes.
       * Just -ENODEV on !Gen11. (Joonas)
      
      v17:
       * Fix one Gen11 subslice enablement rule.
       * Handle error from i915_sw_fence_await_sw_fence_gfp. (Chris Wilson)
      
      v18:
       * Update commit message. (Joonas)
       * Restrict uAPI to VME use case. (Joonas)
      
      v19:
       * Rebase.
      
      v20:
       * Rebase for ce->active_tracker.
      
      v21:
       * Rebase for IS_GEN changes.
      
      v22:
       * Reserve uAPI for flags straight away. (Chris Wilson)
      
      v23:
       * Rebase for RUNTIME_INFO.
      
      v24:
       * Added some headline docs for the uapi usage. (Joonas/Chris)
      
      v25:
       * Renamed class/instance to engine_class/engine_instance to avoid clash
         with C++ keyword. (Tony Ye)
      
      v26:
       * Rebased for runtime pm api changes.
      
      v27:
       * Rebased for intel_context_init.
       * Wrap commit msg to 75.
      
      v28:
       (Chris Wilson)
       * Use i915_gem_ggtt.
       * Use i915_request_await_dma_fence to show a better example.
      
      v29:
       * i915_timeline_set_barrier can now fail. (Chris Wilson)
      
      v30:
       * Capture some acks.
      
      v31:
       * Drop the WARN_ON from use controllable paths. (Chris Wilson)
       * Use overflows_type for all checks.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107634
      Issue: https://github.com/intel/media-driver/issues/267Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarLionel Landwerlin <lionel.g.landwerlin@intel.com>
      Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Zhipeng Gong <zhipeng.gong@intel.com>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Tony Ye <tony.ye@intel.com>
      Signed-off-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Acked-by: default avatarTimo Aaltonen <timo.aaltonen@canonical.com>
      Acked-by: default avatarTakashi Iwai <tiwai@suse.de>
      Acked-by: default avatarStéphane Marchesin <marcheu@chromium.org>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190205095032.22673-4-tvrtko.ursulin@linux.intel.com
      e46c2e99
    • Lionel Landwerlin's avatar
      drm/i915: Record the sseu configuration per-context & engine · 87f1ef22
      Lionel Landwerlin authored
      We want to expose the ability to reconfigure the slices, subslice and
      eu per context and per engine. To facilitate that, store the current
      configuration on the context for each engine, which is initially set
      to the device default upon creation.
      
      v2: record sseu configuration per context & engine (Chris)
      
      v3: introduce the i915_gem_context_sseu to store powergating
          programming, sseu_dev_info has grown quite a bit (Lionel)
      
      v4: rename i915_gem_sseu into intel_sseu (Chris)
          use to_intel_context() (Chris)
      
      v5: More to_intel_context() (Tvrtko)
          Switch intel_sseu from union to struct (Tvrtko)
          Move context default sseu in existing loop (Chris)
      
      v6: s/intel_sseu_from_device_sseu/intel_device_default_sseu/ (Tvrtko)
      
      Tvrtko Ursulin:
      
      v7:
       * Pass intel_sseu by pointer instead of value to make_rpcs.
       * Rebase for make_rpcs changes.
      
      v8:
       * Rebase for RPCS edit on pin.
      
      v9:
       * Rebase for context image setup changes.
      
      v10:
       * Rename dev_priv to i915. (Chris Wilson)
      
      v11:
       * Rebase.
      
      v12:
       * Rebase for IS_GEN changes.
      
      v13:
       * Rebase for RUNTIME_INFO.
      
      v14:
       * Rebase for intel_context_init.
      
      v15:
       * Rebase for drm-tip changes.
      
      v16:
       * Moved struct intel_sseu definition to i915_gem_context.h.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarLionel Landwerlin <lionel.g.landwerlin@intel.com>
      Signed-off-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Reviewed-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/20190205095032.22673-1-tvrtko.ursulin@linux.intel.com
      87f1ef22
  19. 29 Jan, 2019 1 commit
    • Chris Wilson's avatar
      drm/i915: Replace global breadcrumbs with per-context interrupt tracking · 52c0fdb2
      Chris Wilson authored
      A few years ago, see commit 688e6c72 ("drm/i915: Slaughter the
      thundering i915_wait_request herd"), the issue of handling multiple
      clients waiting in parallel was brought to our attention. The
      requirement was that every client should be woken immediately upon its
      request being signaled, without incurring any cpu overhead.
      
      To handle certain fragility of our hw meant that we could not do a
      simple check inside the irq handler (some generations required almost
      unbounded delays before we could be sure of seqno coherency) and so
      request completion checking required delegation.
      
      Before commit 688e6c72, the solution was simple. Every client
      waiting on a request would be woken on every interrupt and each would do
      a heavyweight check to see if their request was complete. Commit
      688e6c72 introduced an rbtree so that only the earliest waiter on
      the global timeline would woken, and would wake the next and so on.
      (Along with various complications to handle requests being reordered
      along the global timeline, and also a requirement for kthread to provide
      a delegate for fence signaling that had no process context.)
      
      The global rbtree depends on knowing the execution timeline (and global
      seqno). Without knowing that order, we must instead check all contexts
      queued to the HW to see which may have advanced. We trim that list by
      only checking queued contexts that are being waited on, but still we
      keep a list of all active contexts and their active signalers that we
      inspect from inside the irq handler. By moving the waiters onto the fence
      signal list, we can combine the client wakeup with the dma_fence
      signaling (a dramatic reduction in complexity, but does require the HW
      being coherent, the seqno must be visible from the cpu before the
      interrupt is raised - we keep a timer backup just in case).
      
      Having previously fixed all the issues with irq-seqno serialisation (by
      inserting delays onto the GPU after each request instead of random delays
      on the CPU after each interrupt), we can rely on the seqno state to
      perfom direct wakeups from the interrupt handler. This allows us to
      preserve our single context switch behaviour of the current routine,
      with the only downside that we lose the RT priority sorting of wakeups.
      In general, direct wakeup latency of multiple clients is about the same
      (about 10% better in most cases) with a reduction in total CPU time spent
      in the waiter (about 20-50% depending on gen). Average herd behaviour is
      improved, but at the cost of not delegating wakeups on task_prio.
      
      v2: Capture fence signaling state for error state and add comments to
      warm even the most cold of hearts.
      v3: Check if the request is still active before busywaiting
      v4: Reduce the amount of pointer misdirection with list_for_each_safe
      and using a local i915_request variable inside the loops
      v5: Add a missing pluralisation to a purely informative selftest message.
      
      References: 688e6c72 ("drm/i915: Slaughter the thundering i915_wait_request herd")
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Reviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190129205230.19056-2-chris@chris-wilson.co.uk
      52c0fdb2
  20. 24 Jan, 2019 1 commit
  21. 22 Jan, 2019 1 commit
  22. 09 Jan, 2019 1 commit
  23. 13 Dec, 2018 1 commit
  24. 07 Dec, 2018 1 commit
  25. 04 Dec, 2018 1 commit
  26. 19 Oct, 2018 1 commit
    • Xiong Zhang's avatar
      drm/i915: Add ppgtt to GVT GEM context · 4f15665c
      Xiong Zhang authored
      Currently the guest couldn't boot up under GVT-g environment as the
      following call trace exists:
      [  272.504762] BUG: unable to handle kernel NULL pointer dereference at 0000000000000100
      [  272.504834] Call Trace:
      [  272.504852]  execlists_context_pin+0x2b2/0x520 [i915]
      [  272.504869]  intel_gvt_scan_and_shadow_workload+0x50/0x4d0 [i915]
      [  272.504887]  intel_vgpu_create_workload+0x3e2/0x570 [i915]
      [  272.504901]  intel_vgpu_submit_execlist+0xc0/0x2a0 [i915]
      [  272.504916]  elsp_mmio_write+0xc7/0x130 [i915]
      [  272.504930]  intel_vgpu_mmio_reg_rw+0x24a/0x4c0 [i915]
      [  272.504944]  intel_vgpu_emulate_mmio_write+0xac/0x240 [i915]
      [  272.504947]  intel_vgpu_rw+0x22d/0x270 [kvmgt]
      [  272.504949]  intel_vgpu_write+0x164/0x1f0 [kvmgt]
      
      GVT GEM context is created by i915_gem_context_create_gvt() which
      doesn't allocate ppgtt. So GVT GEM context structure doesn't have
      a valid i915_hw_ppgtt.
      
      This patch create ppgtt table at GVT GEM context creation, then assign
      shadow ppgtt's root table address to this ppgtt when shadow ppgtt will
      be used on GPU. So GVT GEM context has valid ppgtt address. But note
      that this ppgtt only contain valid ppgtt root table address, the table
      entry in this ppgtt structure are invalid.
      
      Fixes:4a3d3f67("drm/i915: Match code to comment and enforce ppgtt for execlists")
      Signed-off-by: default avatarXiong Zhang <xiong.y.zhang@intel.com>
      Reviewed-by: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Link: https://patchwork.freedesktop.org/patch/msgid/1539841231-3157-1-git-send-email-xiong.y.zhang@intel.com
      4f15665c
  27. 01 Oct, 2018 1 commit