From: "Hellstrom, Thomas" <thomas.hellstrom@intel.com> To: "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>, "C, Ramalingam" <ramalingam.c@intel.com>, "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org> Cc: "Auld, Matthew" <matthew.auld@intel.com> Subject: Re: [PATCH 3/4] drm/i915/gt: Extend doc on Flat-CCS obj eviction Date: Thu, 21 Apr 2022 13:37:29 +0000 [thread overview] Message-ID: <249408791057852ef445c0a8795f3486ef45b151.camel@intel.com> (raw) In-Reply-To: <20220421113813.30796-4-ramalingam.c@intel.com> 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)
WARNING: multiple messages have this Message-ID (diff)
From: "Hellstrom, Thomas" <thomas.hellstrom@intel.com> To: "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>, "C, Ramalingam" <ramalingam.c@intel.com>, "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org> Cc: "Auld, Matthew" <matthew.auld@intel.com> Subject: Re: [Intel-gfx] [PATCH 3/4] drm/i915/gt: Extend doc on Flat-CCS obj eviction Date: Thu, 21 Apr 2022 13:37:29 +0000 [thread overview] Message-ID: <249408791057852ef445c0a8795f3486ef45b151.camel@intel.com> (raw) In-Reply-To: <20220421113813.30796-4-ramalingam.c@intel.com> 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)
next prev parent reply other threads:[~2022-04-21 13:37 UTC|newest] Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-04-21 11:38 [PATCH 0/4] Flat-CCS eviction enhancements Ramalingam C 2022-04-21 11:38 ` [Intel-gfx] " Ramalingam C 2022-04-21 11:38 ` [PATCH 1/4] drm/i915/gt: GEM_BUG_ON unexpected NULL at scatterlist walking Ramalingam C 2022-04-21 11:38 ` [Intel-gfx] " Ramalingam C 2022-04-21 13:27 ` Hellstrom, Thomas 2022-04-21 13:27 ` [Intel-gfx] " Hellstrom, Thomas 2022-04-21 14:04 ` Ramalingam C 2022-04-21 14:04 ` [Intel-gfx] " Ramalingam C 2022-04-21 11:38 ` [Intel-gfx] [PATCH 2/4] drm/i915/gt: optimize the ccs_sz calculation per chunk Ramalingam C 2022-04-21 11:38 ` Ramalingam C 2022-04-21 11:38 ` [Intel-gfx] [PATCH 3/4] drm/i915/gt: Extend doc on Flat-CCS obj eviction Ramalingam C 2022-04-21 11:38 ` Ramalingam C 2022-04-21 13:37 ` Hellstrom, Thomas [this message] 2022-04-21 13:37 ` [Intel-gfx] " Hellstrom, Thomas 2022-04-22 8:43 ` Ramalingam C 2022-04-22 8:43 ` [Intel-gfx] " Ramalingam C 2022-04-21 11:38 ` [PATCH 4/4] uapi/drm/i915: Update the placement list impact on obj residency Ramalingam C 2022-04-21 11:38 ` [Intel-gfx] " Ramalingam C 2022-04-21 13:40 ` Hellstrom, Thomas 2022-04-21 13:40 ` [Intel-gfx] " Hellstrom, Thomas 2022-04-21 14:20 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for Flat-CCS eviction enhancements (rev2) Patchwork 2022-04-21 14:48 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork 2022-04-21 18:50 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=249408791057852ef445c0a8795f3486ef45b151.camel@intel.com \ --to=thomas.hellstrom@intel.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=intel-gfx@lists.freedesktop.org \ --cc=matthew.auld@intel.com \ --cc=ramalingam.c@intel.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.