mbox series

[00/19] drm/i915: Short-term pinning and async eviction.

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

Message

Maarten Lankhorst Aug. 30, 2021, 12:09 p.m. UTC
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.

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.

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(-)

Comments

Thomas Hellström (Intel) Sept. 16, 2021, 9:40 a.m. UTC | #1
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(-)
>
Maarten Lankhorst Sept. 16, 2021, 11:24 a.m. UTC | #2
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.