From: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
To: Ramalingam C <ramalingam.c@intel.com>,
intel-gfx <intel-gfx@lists.freedesktop.org>,
dri-devel <dri-devel@lists.freedesktop.org>
Cc: Thomas Hellstrom <thomas.hellstrom@linux.intel.com>,
Daniel Vetter <daniel.vetter@ffwll.ch>,
Kenneth Graunke <kenneth@whitecape.org>,
Matthew Auld <matthew.auld@intel.com>,
mesa-dev@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v3] uapi/drm/i915: Document memory residency and Flat-CCS capability of obj
Date: Fri, 13 May 2022 15:31:00 +0300 [thread overview]
Message-ID: <08039c07-a32e-7725-bc98-db49eefb3e86@intel.com> (raw)
In-Reply-To: <20220502141508.2327-1-ramalingam.c@intel.com>
On 02/05/2022 17:15, Ramalingam C wrote:
> Capture the impact of memory region preference list of the objects, on
> their memory residency and Flat-CCS capability.
>
> v2:
> Fix the Flat-CCS capability of an obj with {lmem, smem} preference
> list [Thomas]
> v3:
> Reworded the doc [Matt]
>
> Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
> cc: Matthew Auld <matthew.auld@intel.com>
> cc: Thomas Hellstrom <thomas.hellstrom@linux.intel.com>
> cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> cc: Jon Bloomfield <jon.bloomfield@intel.com>
> cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
> cc: Kenneth Graunke <kenneth@whitecape.org>
> cc: mesa-dev@lists.freedesktop.org
> cc: Jordan Justen <jordan.l.justen@intel.com>
> cc: Tony Ye <tony.ye@intel.com>
> Reviewed-by: Matthew Auld <matthew.auld@intel.com>
> ---
> include/uapi/drm/i915_drm.h | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> index a2def7b27009..b7e1c2fe08dc 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -3443,6 +3443,22 @@ 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.
> + *
> + * Note that userspace has no means of knowing the current backing region
> + * for objects where @num_regions is larger than one. The kernel will only
> + * ensure that the priority order of the @regions array is honoured, either
> + * when initially placing the object, or when moving memory around due to
> + * memory pressure
> + *
> + * On Flat-CCS capable HW, compression is supported for the objects residing
> + * in I915_MEMORY_CLASS_DEVICE. When such objects (compressed) has other
> + * memory class in @regions and migrated (by I915, due to memory
> + * constrain) to the non I915_MEMORY_CLASS_DEVICE region, then I915 needs to
> + * decompress the content. But I915 dosen't have the required information to
> + * decompress the userspace compressed objects.
> + *
> + * So I915 supports Flat-CCS, only on the objects which can reside only on
> + * I915_MEMORY_CLASS_DEVICE regions.
I think it's fine to assume Flat-CSS surface will always be in lmem.
I see no issue for the Anv Vulkan driver.
Maybe Nanley or Ken can speak for the Iris GL driver?
-Lionel
> */
> struct drm_i915_gem_create_ext_memory_regions {
> /** @base: Extension link. See struct i915_user_extension. */
next prev parent reply other threads:[~2022-05-13 12:31 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-02 14:15 [Intel-gfx] [PATCH v3] uapi/drm/i915: Document memory residency and Flat-CCS capability of obj Ramalingam C
2022-05-02 14:29 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for " Patchwork
2022-05-02 14:54 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-05-02 17:46 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2022-05-13 12:31 ` Lionel Landwerlin [this message]
2022-05-13 21:06 ` [Intel-gfx] [PATCH v3] " Jordan Justen
2022-05-16 7:47 ` Lionel Landwerlin
2022-05-16 8:07 ` Jordan Justen
2022-05-18 6:52 ` Ramalingam C
2022-05-18 18:41 ` Ye, Tony
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=08039c07-a32e-7725-bc98-db49eefb3e86@intel.com \
--to=lionel.g.landwerlin@intel.com \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=kenneth@whitecape.org \
--cc=matthew.auld@intel.com \
--cc=mesa-dev@lists.freedesktop.org \
--cc=ramalingam.c@intel.com \
--cc=thomas.hellstrom@linux.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