All of lore.kernel.org
 help / color / mirror / Atom feed
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: Tony Ye <tony.ye@intel.com>,
	Thomas Hellstrom <thomas.hellstrom@linux.intel.com>,
	Nanley Chery <nanley.g.chery@intel.com>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	Kenneth Graunke <kenneth@whitecape.org>,
	Jon Bloomfield <jon.bloomfield@intel.com>,
	Matthew Auld <matthew.auld@intel.com>,
	Jordan Justen <jordan.l.justen@intel.com>,
	mesa-dev@lists.freedesktop.org
Subject: Re: [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. */



WARNING: multiple messages have this Message-ID (diff)
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. */



  parent reply	other threads:[~2022-05-13 12:31 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-02 14:15 [PATCH v3] uapi/drm/i915: Document memory residency and Flat-CCS capability of obj Ramalingam C
2022-05-02 14:15 ` [Intel-gfx] " 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 12:31   ` [Intel-gfx] [PATCH v3] " Lionel Landwerlin
2022-05-13 21:06   ` Jordan Justen
2022-05-13 21:06     ` [Intel-gfx] " Jordan Justen
2022-05-16  7:47     ` Lionel Landwerlin
2022-05-16  7:47       ` [Intel-gfx] " Lionel Landwerlin
2022-05-16  8:07       ` Jordan Justen
2022-05-16  8:07         ` [Intel-gfx] " Jordan Justen
2022-05-18  6:52     ` Ramalingam C
2022-05-18  6:52       ` [Intel-gfx] " Ramalingam C
2022-05-18 18:41 ` Ye, Tony
2022-05-18 18:41   ` [Intel-gfx] " 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=jon.bloomfield@intel.com \
    --cc=jordan.l.justen@intel.com \
    --cc=kenneth@whitecape.org \
    --cc=matthew.auld@intel.com \
    --cc=mesa-dev@lists.freedesktop.org \
    --cc=nanley.g.chery@intel.com \
    --cc=ramalingam.c@intel.com \
    --cc=thomas.hellstrom@linux.intel.com \
    --cc=tony.ye@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 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.