1. 14 11月, 2019 1 次提交
  2. 13 11月, 2019 1 次提交
  3. 12 11月, 2019 1 次提交
  4. 24 10月, 2019 1 次提交
  5. 18 10月, 2019 1 次提交
  6. 08 10月, 2019 1 次提交
  7. 05 10月, 2019 1 次提交
  8. 04 10月, 2019 1 次提交
    • C
      drm/i915: Pull i915_vma_pin under the vm->mutex · 2850748e
      Chris Wilson 提交于
      Replace the struct_mutex requirement for pinning the i915_vma with the
      local vm->mutex instead. Note that the vm->mutex is tainted by the
      shrinker (we require unbinding from inside fs-reclaim) and so we cannot
      allocate while holding that mutex. Instead we have to preallocate
      workers to do allocate and apply the PTE updates after we have we
      reserved their slot in the drm_mm (using fences to order the PTE writes
      with the GPU work and with later unbind).
      
      In adding the asynchronous vma binding, one subtle requirement is to
      avoid coupling the binding fence into the backing object->resv. That is
      the asynchronous binding only applies to the vma timeline itself and not
      to the pages as that is a more global timeline (the binding of one vma
      does not need to be ordered with another vma, nor does the implicit GEM
      fencing depend on a vma, only on writes to the backing store). Keeping
      the vma binding distinct from the backing store timelines is verified by
      a number of async gem_exec_fence and gem_exec_schedule tests. The way we
      do this is quite simple, we keep the fence for the vma binding separate
      and only wait on it as required, and never add it to the obj->resv
      itself.
      
      Another consequence in reducing the locking around the vma is the
      destruction of the vma is no longer globally serialised by struct_mutex.
      A natural solution would be to add a kref to i915_vma, but that requires
      decoupling the reference cycles, possibly by introducing a new
      i915_mm_pages object that is own by both obj->mm and vma->pages.
      However, we have not taken that route due to the overshadowing lmem/ttm
      discussions, and instead play a series of complicated games with
      trylocks to (hopefully) ensure that only one destruction path is called!
      
      v2: Add some commentary, and some helpers to reduce patch churn.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20191004134015.13204-4-chris@chris-wilson.co.uk
      2850748e
  9. 20 9月, 2019 1 次提交
    • C
      drm/i915: Mark i915_request.timeline as a volatile, rcu pointer · d19d71fc
      Chris Wilson 提交于
      The request->timeline is only valid until the request is retired (i.e.
      before it is completed). Upon retiring the request, the context may be
      unpinned and freed, and along with it the timeline may be freed. We
      therefore need to be very careful when chasing rq->timeline that the
      pointer does not disappear beneath us. The vast majority of users are in
      a protected context, either during request construction or retirement,
      where the timeline->mutex is held and the timeline cannot disappear. It
      is those few off the beaten path (where we access a second timeline) that
      need extra scrutiny -- to be added in the next patch after first adding
      the warnings about dangerous access.
      
      One complication, where we cannot use the timeline->mutex itself, is
      during request submission onto hardware (under spinlocks). Here, we want
      to check on the timeline to finalize the breadcrumb, and so we need to
      impose a second rule to ensure that the request->timeline is indeed
      valid. As we are submitting the request, it's context and timeline must
      be pinned, as it will be used by the hardware. Since it is pinned, we
      know the request->timeline must still be valid, and we cannot submit the
      idle barrier until after we release the engine->active.lock, ergo while
      submitting and holding that spinlock, a second thread cannot release the
      timeline.
      
      v2: Don't be lazy inside selftests; hold the timeline->mutex for as long
      as we need it, and tidy up acquiring the timeline with a bit of
      refactoring (i915_active_add_request)
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190919111912.21631-1-chris@chris-wilson.co.uk
      d19d71fc
  10. 18 9月, 2019 1 次提交
  11. 10 9月, 2019 1 次提交
  12. 31 8月, 2019 1 次提交
  13. 19 8月, 2019 1 次提交
    • C
      drm/i915: Always wrap the ring offset before resetting · 6a736ebf
      Chris Wilson 提交于
      We were passing in an unwrapped offset into intel_ring_reset() on
      unpinning. Sooner or later that had to land on ring->size.
      
      <3> [314.872147] intel_ring_reset:1237 GEM_BUG_ON(!intel_ring_offset_valid(ring, tail))
      <4> [314.872272] ------------[ cut here ]------------
      <2> [314.872276] kernel BUG at drivers/gpu/drm/i915/gt/intel_ringbuffer.c:1237!
      <4> [314.872320] invalid opcode: 0000 [#1] PREEMPT SMP PTI
      <4> [314.872331] CPU: 1 PID: 3466 Comm: i915_selftest Tainted: G     U            5.3.0-rc4-CI-Patchwork_14061+ #1
      <4> [314.872346] Hardware name: Hewlett-Packard HP Compaq 8000 Elite CMT PC/3647h, BIOS 786G7 v01.02 10/22/2009
      <4> [314.872477] RIP: 0010:intel_ring_reset+0x51/0x70 [i915]
      <4> [314.872487] Code: 9e db 51 e0 48 8b 35 b6 c7 22 00 49 c7 c0 f8 d9 d6 a0 b9 d5 04 00 00 48 c7 c2 70 5b d4 a0 48 c7 c7 6c fc c0 a0 e8 cf be 58 e0 <0f> 0b 89 77 20 89 77 1c 89 77 24 e9 4f ed ff ff 0f 1f 44 00 00 66
      <4> [314.872512] RSP: 0018:ffffc9000034fa98 EFLAGS: 00010282
      <4> [314.872523] RAX: 0000000000000010 RBX: ffff8881019412c8 RCX: 0000000000000000
      <4> [314.872534] RDX: 0000000000000001 RSI: 0000000000000008 RDI: 0000000000000f20
      <4> [314.872545] RBP: ffff888104e0f740 R08: 0000000000000000 R09: 0000000000000f20
      <4> [314.872557] R10: 0000000000000000 R11: ffff888117094518 R12: ffffffffa0d3d2c0
      <4> [314.872569] R13: ffffffffa0e2a250 R14: ffffffffa0e2a1e0 R15: ffffc9000034fe88
      <4> [314.872581] FS:  00007fe6d49f6e40(0000) GS:ffff888117a80000(0000) knlGS:0000000000000000
      <4> [314.872595] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      <4> [314.872605] CR2: 000055e3283e9cc8 CR3: 0000000108842000 CR4: 00000000000406e0
      <4> [314.872616] Call Trace:
      <4> [314.872701]  intel_ring_unpin+0x1a/0x220 [i915]
      <4> [314.872787]  ring_destroy+0x48/0xc0 [i915]
      <4> [314.872870]  intel_engines_cleanup+0x24/0x40 [i915]
      <4> [314.872964]  i915_gem_driver_release+0x1b/0xf0 [i915]
      <4> [314.872984]  i915_driver_release+0x1c/0x80 [i915]
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190819075835.20065-2-chris@chris-wilson.co.uk
      6a736ebf
  14. 16 8月, 2019 1 次提交
  15. 12 8月, 2019 2 次提交
  16. 11 8月, 2019 1 次提交
  17. 10 8月, 2019 3 次提交
  18. 09 8月, 2019 1 次提交
  19. 03 8月, 2019 1 次提交
    • C
      drm/i915: Hide unshrinkable context objects from the shrinker · 1aff1903
      Chris Wilson 提交于
      The shrinker cannot touch objects used by the contexts (logical state
      and ring). Currently we mark those as "pin_global" to let the shrinker
      skip over them, however, if we remove them from the shrinker lists
      entirely, we don't event have to include them in our shrink accounting.
      
      By keeping the unshrinkable objects in our shrinker tracking, we report
      a large number of objects available to be shrunk, and leave the shrinker
      deeply unsatisfied when we fail to reclaim those. The shrinker will
      persist in trying to reclaim the unavailable objects, forcing the system
      into a livelock (not even hitting the dread oomkiller).
      
      v2: Extend unshrinkable protection for perma-pinned scratch and guc
      allocations (Tvrtko)
      v3: Notice that we should be pinned when marking unshrinkable and so the
      link cannot be empty; merge duplicate paths.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190802212137.22207-1-chris@chris-wilson.co.uk
      1aff1903
  20. 30 7月, 2019 3 次提交
  21. 29 7月, 2019 1 次提交
  22. 23 7月, 2019 1 次提交
  23. 18 7月, 2019 1 次提交
  24. 13 7月, 2019 1 次提交
  25. 12 7月, 2019 1 次提交
  26. 10 7月, 2019 1 次提交
  27. 05 7月, 2019 1 次提交
  28. 04 7月, 2019 1 次提交
  29. 26 6月, 2019 1 次提交
  30. 22 6月, 2019 2 次提交
  31. 21 6月, 2019 4 次提交