1. 07 4月, 2020 1 次提交
  2. 03 4月, 2020 1 次提交
  3. 27 3月, 2020 1 次提交
  4. 20 3月, 2020 1 次提交
  5. 17 3月, 2020 1 次提交
    • L
      drm/i915/perf: introduce global sseu pinning · 11ecbddd
      Lionel Landwerlin 提交于
      On Gen11 powergating half the execution units is a functional
      requirement when using the VME samplers. Not fullfilling this
      requirement can lead to hangs.
      
      This unfortunately plays fairly poorly with the NOA requirements. NOA
      requires a stable power configuration to maintain its configuration.
      
      As a result using OA (and NOA feeding into it) so far has required us
      to use a power configuration that can work for all contexts. The only
      power configuration fullfilling this is powergating half the execution
      units.
      
      This makes performance analysis for 3D workloads somewhat pointless.
      
      Failing to find a solution that would work for everybody, this change
      introduces a new i915-perf stream open parameter that punts the
      decision off to userspace. If this parameter is omitted, the existing
      Gen11 behavior remains (half EU array powergating).
      
      This change takes the initiative to move all perf related sseu
      configuration into i915_perf.c
      
      v2: Make parameter priviliged if different from default
      
      v3: Fix context modifying its sseu config while i915-perf is enabled
      
      v4: Always consider global sseu a privileged operation (Tvrtko)
          Override req_sseu point in intel_sseu_make_rpcs() (Tvrtko)
          Remove unrelated changes (Tvrtko)
      
      v5: Some typos (Tvrtko)
          Process sseu param in read_properties_unlocked() (Tvrtko)
      
      v6: Actually commit the bits from v5...
          Fixup some checkpath warnings
      
      v7: Only compare engine uabi field (Chris)
      Signed-off-by: NLionel Landwerlin <lionel.g.landwerlin@intel.com>
      Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200317132222.2638719-3-lionel.g.landwerlin@intel.com
      11ecbddd
  6. 13 3月, 2020 1 次提交
  7. 12 3月, 2020 2 次提交
  8. 04 3月, 2020 1 次提交
  9. 27 2月, 2020 1 次提交
  10. 26 2月, 2020 1 次提交
  11. 21 2月, 2020 1 次提交
  12. 18 2月, 2020 1 次提交
  13. 12 2月, 2020 1 次提交
  14. 08 2月, 2020 1 次提交
  15. 04 2月, 2020 1 次提交
  16. 31 1月, 2020 1 次提交
  17. 27 1月, 2020 2 次提交
  18. 24 1月, 2020 1 次提交
  19. 23 1月, 2020 1 次提交
  20. 09 1月, 2020 1 次提交
  21. 08 1月, 2020 1 次提交
  22. 24 12月, 2019 1 次提交
  23. 23 12月, 2019 1 次提交
  24. 22 12月, 2019 1 次提交
  25. 20 12月, 2019 2 次提交
  26. 18 12月, 2019 2 次提交
  27. 07 12月, 2019 1 次提交
    • C
      drm/i915/gem: Pin gen6_ppgtt prior to constructing the request · aef82079
      Chris Wilson 提交于
      All pinning must be done prior to i915_request_create, to avoid
      timeline->mutex inversions.
      
      Here we slightly abuse the context_barrier_task stages to utilise the
      'skip' decision as an opportunity to acquire the pin on the new ppgtt.
      Consider it s/skip/prepare/. At the moment, we only have on user of
      context_barrier_task, so it might be worth breaking it down for the
      specific task of set-vm and refactor it later if we find a second
      purpose.
      
      <4> [402.377487] WARNING: possible circular locking dependency detected
      <4> [402.377493] 5.4.0-rc8-CI-CI_DRM_7491+ #1 Tainted: G     U
      <4> [402.377497] ------------------------------------------------------
      <4> [402.377502] gem_exec_parall/2506 is trying to acquire lock:
      <4> [402.377507] ffff888403cdac70 (&kernel#2){+.+.}, at: i915_request_create+0x16/0x1c0 [i915]
      <4> [402.377593]
      but task is already holding lock:
      <4> [402.377597] ffff88835efad550 (&ppgtt->pin_mutex){+.+.}, at: gen6_ppgtt_pin+0x4d/0x110 [i915]
      <4> [402.377660]
      which lock already depends on the new lock.
      
      <4> [402.377664]
      the existing dependency chain (in reverse order) is:
      <4> [402.377668]
      -> #1 (&ppgtt->pin_mutex){+.+.}:
      <4> [402.377674]        __mutex_lock+0x9a/0x9d0
      <4> [402.377713]        gen6_ppgtt_pin+0x4d/0x110 [i915]
      <4> [402.377756]        emit_ppgtt_update+0x1dc/0x370 [i915]
      <4> [402.377801]        context_barrier_task+0x176/0x310 [i915]
      <4> [402.377844]        ctx_setparam+0x400/0xb10 [i915]
      <4> [402.377886]        i915_gem_context_setparam_ioctl+0xc8/0x160 [i915]
      <4> [402.377891]        drm_ioctl_kernel+0xa7/0xf0
      <4> [402.377895]        drm_ioctl+0x2e1/0x390
      <4> [402.377899]        do_vfs_ioctl+0xa0/0x6f0
      <4> [402.377903]        ksys_ioctl+0x35/0x60
      <4> [402.377906]        __x64_sys_ioctl+0x11/0x20
      <4> [402.377910]        do_syscall_64+0x4f/0x210
      <4> [402.377914]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      <4> [402.377917]
      -> #0 (&kernel#2){+.+.}:
      <4> [402.377923]        __lock_acquire+0x1328/0x15d0
      <4> [402.377926]        lock_acquire+0xa7/0x1c0
      <4> [402.377930]        __mutex_lock+0x9a/0x9d0
      <4> [402.377977]        i915_request_create+0x16/0x1c0 [i915]
      <4> [402.378013]        intel_engine_flush_barriers+0x4c/0x100 [i915]
      <4> [402.378062]        i915_ggtt_pin+0x7d/0x130 [i915]
      <4> [402.378108]        gen6_ppgtt_pin+0x9c/0x110 [i915]
      <4> [402.378148]        ring_context_pin+0x2e/0xc0 [i915]
      <4> [402.378183]        __intel_context_do_pin+0x6b/0x190 [i915]
      <4> [402.378226]        i915_gem_do_execbuffer+0x180c/0x26b0 [i915]
      <4> [402.378268]        i915_gem_execbuffer2_ioctl+0x11b/0x460 [i915]
      <4> [402.378272]        drm_ioctl_kernel+0xa7/0xf0
      <4> [402.378275]        drm_ioctl+0x2e1/0x390
      <4> [402.378279]        do_vfs_ioctl+0xa0/0x6f0
      <4> [402.378282]        ksys_ioctl+0x35/0x60
      <4> [402.378286]        __x64_sys_ioctl+0x11/0x20
      <4> [402.378289]        do_syscall_64+0x4f/0x210
      <4> [402.378292]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      <4> [402.378295]
      other info that might help us debug this:
      
      <4> [402.378299]  Possible unsafe locking scenario:
      
      <4> [402.378302]        CPU0                    CPU1
      <4> [402.378305]        ----                    ----
      <4> [402.378307]   lock(&ppgtt->pin_mutex);
      <4> [402.378310]                                lock(&kernel#2);
      <4> [402.378314]                                lock(&ppgtt->pin_mutex);
      <4> [402.378317]   lock(&kernel#2);
      <4> [402.378320]
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NAndi Shyti <andi.shyti@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20191206105527.1130413-4-chris@chris-wilson.co.uk
      aef82079
  28. 02 12月, 2019 1 次提交
  29. 30 11月, 2019 1 次提交
  30. 28 11月, 2019 1 次提交
  31. 25 11月, 2019 1 次提交
  32. 18 11月, 2019 1 次提交
  33. 16 11月, 2019 1 次提交
  34. 13 11月, 2019 1 次提交
  35. 11 11月, 2019 2 次提交