On 2022-04-21 at 19:07:29 +0530, Hellstrom, Thomas wrote:
> On Thu, 2022-04-21 at 17:08 +0530, Ramalingam C wrote:
> > Capture the eviction details for Flat-CCS capable lmem only objects
> > and
> > lmem objects with smem residency. This also captures the impact of
> > eviction on object's memory residency and Flat-CCS compression
> > state.
> >
> > Signed-off-by: Ramalingam C <ramalingam.c@xxxxxxxxx>
> > ---
> > drivers/gpu/drm/i915/gt/intel_migrate.c | 36 ++++++++++++++++++-----
> > --
> > 1 file changed, 27 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c
> > b/drivers/gpu/drm/i915/gt/intel_migrate.c
> > index 463a6a14b5f9..9d0d18950e76 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_migrate.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
> > @@ -485,16 +485,34 @@ static bool wa_1209644611_applies(int ver, u32
> > size)
> > * 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 exhaust 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.
> > + * when we exhaust the lmem, we need to handle two types of flat-ccs
> > capable
> > + * objects for its eviction.
> > + * 1) lmem only objects
> > + * 2) lmem objects with smem residency option
> > *
> > - * 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.
> > + * 1) lmem only objects:
> > + *
> > + * lmem backing memory can be temporarily evicted to smem, along
> > with the
> > + * auxiliary CCS state, where it can be potentially swapped-out at a
> > later point,
> > + * if required. If userspace later touches the evicted pages, then
> > we always move
> > + * the backing memory back to lmem, which includes restoring the
> > saved CCS state,
> > + * and potentially performing any required swap-in.
> > + *
> > + * In this scenario, objects' backing memory class and Flat-CCS
> > state doesn't
> > + * change.
> > + *
> > + * 2) lmem objects with smem residency option
> > + *
> > + * Lmem object with smem region in it's placement list, will be
> > migrated into
> > + * smem by decompressing the content. I915 doesn't handle this kind
> > of
> > + * migration for Flat-CCS compressed objects yet.
> > + *
> > + * In this scenario, objects' backing memory class and Flat-CCS
> > state changed,
> > + * and userspace is not aware of it.
> > + *
> > + * In summary, when a userspace wants to be sure about the objects
> > memory
> > + * residency and flat-ccs compression state, then placement list
> > can't have
> > + * the lmem and smem together. Instead, object has to be lmem
> > resident only.
>
> For 2) I was under the impression that with flat CCS, these objects
> need to be always uncompressed, since the kernel doesn't have the
> needed information to decompress / compress. Or has this been changed
> recently?
Sorry. I have overlooked the lack of inputs required for decompression
at kernel. So yes we can't support the compression on the lmem objects
with {lmem, smem} as placement preferences. I will update the
documentation accordingly.
Ram.
>
> /Thomas
>
>
>
>
> > */
> >
> > static inline u32 *i915_flush_dw(u32 *cmd, u32 flags)
>
