| Message ID | 20220421113813.30796-4-ramalingam.c@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Flat-CCS eviction enhancements | expand |
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@intel.com> > --- > 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? /Thomas > */ > > static inline u32 *i915_flush_dw(u32 *cmd, u32 flags)
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@intel.com> > > --- > > 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) >
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. */ static inline u32 *i915_flush_dw(u32 *cmd, u32 flags)
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@intel.com> --- drivers/gpu/drm/i915/gt/intel_migrate.c | 36 ++++++++++++++++++------- 1 file changed, 27 insertions(+), 9 deletions(-)