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 4/4] uapi/drm/i915: Update the placement list impact on obj residency
Date: Thu, 21 Apr 2022 13:40:08 +0000 [thread overview]
Message-ID: <02e045db12a0887104d24625943dacf2956ed1eb.camel@intel.com> (raw)
In-Reply-To: <20220421113813.30796-5-ramalingam.c@intel.com>
On Thu, 2022-04-21 at 17:08 +0530, Ramalingam C wrote:
> Object created with list of memory classes as placement preferences,
> can
> be backed with any memory class of the list as per kernel's migration
> policy for the memory contrain situation. Userspace won't be notified
> of
> the memory residency change at this scenario.
>
> And also Flat-CCS compression is supported only on objects of
> I915_MEMORY_CLASS_DEVICE. When the Flat-CCS compressed objects
> migrates
> out of I915_MEMORY_CLASS_DEVICE, due to memory constrain, content
> will
> be decompressed without notifying the userpsace.
userspace
>
> Record these details in Kernel documentation.
>
> Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
> ---
> include/uapi/drm/i915_drm.h | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/include/uapi/drm/i915_drm.h
> b/include/uapi/drm/i915_drm.h
> index 35ca528803fd..8b25dd6a157a 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -3393,6 +3393,20 @@ struct drm_i915_gem_create_ext {
> * At which point we get the object handle in
> &drm_i915_gem_create_ext.handle,
> * along with the final object size in
> &drm_i915_gem_create_ext.size, which
> * should account for any rounding up, if required.
> + *
> + * If an object is created with list of memory classes as their
> placement
> + * preference, kernel could use one of the memory class as the
> backing storage
> + * based on the memory availability. At memory pressure kernel could
> migrate the
> + * objects content from one memory class to another, given in the
> placement list.
> + *
> + * With placement preference list, userpace can't be sure about the
> object's memory
> + * residence.
> + *
> + * Flat-CCS compression is supported only for objects of
> I915_MEMORY_CLASS_DEVICE.
> + * If the object has other placement preferences, and if the content
> is
> + * migrated (by kernel due to memory constrain) to a memory class
> which is other
> + * than I915_MEMORY_CLASS_DEVICE, object content will be
> decompressed by kernel.
> + * Userpace will be ignorant of this Flat-CCS state change.
Same question here as for previous commit.
> */
> struct drm_i915_gem_create_ext_memory_regions {
> /** @base: Extension link. See struct i915_user_extension. */
next prev parent reply other threads:[~2022-04-21 13:40 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-21 11:38 [Intel-gfx] [PATCH 0/4] Flat-CCS eviction enhancements Ramalingam C
2022-04-21 11:38 ` [Intel-gfx] [PATCH 1/4] drm/i915/gt: GEM_BUG_ON unexpected NULL at scatterlist walking Ramalingam C
2022-04-21 13:27 ` Hellstrom, Thomas
2022-04-21 14:04 ` 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 ` [Intel-gfx] [PATCH 3/4] drm/i915/gt: Extend doc on Flat-CCS obj eviction Ramalingam C
2022-04-21 13:37 ` Hellstrom, Thomas
2022-04-22 8:43 ` Ramalingam C
2022-04-21 11:38 ` [Intel-gfx] [PATCH 4/4] uapi/drm/i915: Update the placement list impact on obj residency Ramalingam C
2022-04-21 13:40 ` Hellstrom, Thomas [this message]
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=02e045db12a0887104d24625943dacf2956ed1eb.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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox