Message ID | 20210830121006.2978297-1-maarten.lankhorst@linux.intel.com (mailing list archive) |
---|---|
Headers | show |
Series | drm/i915: Short-term pinning and async eviction. | expand |
On 8/30/21 2:09 PM, Maarten Lankhorst wrote: > Remove some parts of the i915_vma api, ensure obj->vma always exists, > and finally force the object lock to be taken when calling i915_vma_unbind > is called. Should this be vma->obj? > > With this, locking is a lot cleaner, and we no longer need all the if (!obj->vma) checks. > We kill off the locking around i915_vma->set/get pages, and kill off the short-term > pinning/unpinning in execbuf. > > After this, we go 1 step further, populate obj->moving where required, and add support > for async eviction/clearing. Does the async eviction / clearing depend on the vma cleanup? If not can we move that into a separate series? Thanks, Thomas > > Maarten Lankhorst (19): > drm/i915: Move __i915_gem_free_object to ttm_bo_destroy > drm/i915: Remove unused bits of i915_vma/active api > drm/i915: Slightly rework EXEC_OBJECT_CAPTURE handling > drm/i915: Remove gen6_ppgtt_unpin_all > drm/i915: Create a dummy object for gen6 ppgtt > drm/i915: Create a full object for mock_ring > drm/i915: vma is always backed by an object. > drm/i915: Fix runtime pm handling in i915_gem_shrink > drm/i915: Change shrink ordering to use locking around unbinding. > Move CONTEXT_VALID_BIT check > drm/i915: Remove resv from i915_vma > drm/i915: Remove pages_mutex and intel_gtt->vma_ops.set/clear_pages > members > drm/i915: Take object lock in i915_ggtt_pin if ww is not set > drm/i915: Add i915_vma_unbind_unlocked, and take obj lock for > i915_vma_unbind > drm/i915: Remove support for unlocked i915_vma unbind > drm/i915: Remove short-term pins from execbuf > drm/i915: Add functions to set/get moving fence > drm/i915: Add support for asynchronous moving fence waiting > drm/i915: Add accelerated migration to ttm > > drivers/gpu/drm/i915/display/intel_display.c | 2 +- > drivers/gpu/drm/i915/display/intel_dpt.c | 2 - > .../gpu/drm/i915/gem/i915_gem_execbuffer.c | 94 ++-- > drivers/gpu/drm/i915/gem/i915_gem_internal.c | 44 +- > drivers/gpu/drm/i915/gem/i915_gem_object.c | 15 + > drivers/gpu/drm/i915/gem/i915_gem_object.h | 6 + > drivers/gpu/drm/i915/gem/i915_gem_pages.c | 10 + > drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 63 ++- > drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 111 ++-- > .../gpu/drm/i915/gem/selftests/huge_pages.c | 4 +- > .../i915/gem/selftests/i915_gem_client_blt.c | 2 +- > .../drm/i915/gem/selftests/i915_gem_mman.c | 6 + > drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 148 +++-- > drivers/gpu/drm/i915/gt/gen6_ppgtt.h | 2 - > drivers/gpu/drm/i915/gt/intel_context.c | 2 +- > drivers/gpu/drm/i915/gt/intel_engine_pm.c | 5 +- > drivers/gpu/drm/i915/gt/intel_ggtt.c | 366 ++---------- > drivers/gpu/drm/i915/gt/intel_gtt.c | 13 - > drivers/gpu/drm/i915/gt/intel_gtt.h | 7 - > drivers/gpu/drm/i915/gt/intel_ppgtt.c | 12 - > .../gpu/drm/i915/gt/intel_ring_submission.c | 2 +- > drivers/gpu/drm/i915/gt/mock_engine.c | 35 +- > drivers/gpu/drm/i915/i915_active.c | 28 +- > drivers/gpu/drm/i915/i915_active.h | 17 +- > drivers/gpu/drm/i915/i915_drv.h | 11 +- > drivers/gpu/drm/i915/i915_gem.c | 29 +- > drivers/gpu/drm/i915/i915_gem_evict.c | 74 ++- > drivers/gpu/drm/i915/i915_gem_gtt.h | 1 + > drivers/gpu/drm/i915/i915_gpu_error.c | 9 +- > drivers/gpu/drm/i915/i915_request.c | 9 +- > drivers/gpu/drm/i915/i915_request.h | 7 +- > drivers/gpu/drm/i915/i915_vma.c | 522 ++++++++++++++---- > drivers/gpu/drm/i915/i915_vma.h | 15 +- > drivers/gpu/drm/i915/i915_vma_types.h | 2 - > drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 34 +- > drivers/gpu/drm/i915/selftests/i915_vma.c | 2 +- > drivers/gpu/drm/i915/selftests/mock_gtt.c | 4 - > 37 files changed, 899 insertions(+), 816 deletions(-) >
Op 16-09-2021 om 11:40 schreef Thomas Hellström (Intel): > > On 8/30/21 2:09 PM, Maarten Lankhorst wrote: >> Remove some parts of the i915_vma api, ensure obj->vma always exists, >> and finally force the object lock to be taken when calling i915_vma_unbind >> is called. > > Should this be vma->obj? > Correct, missed that. > >> >> With this, locking is a lot cleaner, and we no longer need all the if (!obj->vma) checks. >> We kill off the locking around i915_vma->set/get pages, and kill off the short-term >> pinning/unpinning in execbuf. >> >> After this, we go 1 step further, populate obj->moving where required, and add support >> for async eviction/clearing. > > Does the async eviction / clearing depend on the vma cleanup? If not can we move that into a separate series? It kind of does. We cannot always require vma->obj to be locked and remove vma locks if we don't have vma->obj all the time.