[RFC,0/5] Add basic support for flat-CCS bo evictions

Message

Adrián Larumbe Jan. 21, 2022, 10:22 p.m. UTC

This series is a first attempt at handling the eviction of flat-CCS
compressed lmem-placed bo's.

The official specification of flat CCS behaviour dictates that:

"Flat CCS data needs to be cleared when a lmem object is allocated.  And CCS
data can be copied in and out of CCS region through XY_CTRL_SURF_COPY_BLT. CPU
can't access the CCS data directly.
                                                                             
When we exaust the lmem, if the object's placements support smem, then we can
directly decompress the compressed lmem object into smem and start using it from
smem itself.
                                                                             
But when we need to swapout the compressed lmem object into a smem region though
objects' placement doesn't support smem, then we copy the lmem content as it is
into smem region along with ccs data (using XY_CTRL_SURF_COPY_BLT).  When the
object is referred, lmem content will be swaped in along with restoration of the
CCS data (using XY_CTRL_SURF_COPY_BLT) at corresponding location."

Design decisions:

 - A separate GEM bo of type `ttm_bo_type_kernel` is created to hold the
 contents of the CCS block when an lmem-only object is evicted onto smem. This
 is because this bo should never be mmap'able onto user space.

 - Whether a bo is meant to contain flat-CCS compressed data is marked by adding
 specific surface modifiers that describe a FB object which contains the
 relevant bo. This is done through a specific DRM library call.

 - At an eviction event, the bo's buffer data and its corresponding CCS block
 have to be moved between smem and lmem in two separate blit operations. Because
 of my poor knowledge of the blit unit, it's very likely that the way I
 programmed it is somehow wrong.

 - At the moment, migrating a flat-CCS lmem-only object from smem back onto lmem
 will fail if its flat-CCS swap bo had not been created. However, a bo lifecycle
 begins in smem when it's created, even its original placement specifies lmem
 only. Between the time that a bo is freshly created and an execbuf2 ioctl
 actually moves it onto lmem and allocates its backing storage, the user might've
 called mmap on it, a scenario which I haven't yet accounted for.

Part of the blitting engine code was borrowed from Ramalingam C <[e-mail]>,
who has been working in parallel on the same problem, although in a slightly
different approach.

For testing, a flat-CCS driver self-test is under preparation.

Adrian Larumbe (5):
  drm/i915/flat-CCS: Add GEM BO structure fields for flat-CCS
  drm/i915/flat-CCS: Add flat CCS plane capabilities and modifiers
  drm/i915/flat-CCS: move GET_CCS_SIZE macro into driver-wide header
  drm/i915/flat-CCS: handle CCS block blit for bo migrations
  drm/i915/flat-CCS: handle creation and destruction of flat CCS bo's

 drivers/gpu/drm/i915/display/intel_fb.c       |  36 ++-
 drivers/gpu/drm/i915/display/intel_fb.h       |   1 +
 .../gpu/drm/i915/gem/i915_gem_object_types.h  |  10 +
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c       |  11 +
 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c  |  78 ++++-
 drivers/gpu/drm/i915/gt/intel_migrate.c       | 289 ++++++++++++------
 drivers/gpu/drm/i915/gt/intel_migrate.h       |   2 +
 drivers/gpu/drm/i915/gt/selftest_migrate.c    |   3 +-
 drivers/gpu/drm/i915/i915_drv.h               |   5 +
 9 files changed, 342 insertions(+), 93 deletions(-)