From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 9C0DBC433F5 for ; Mon, 16 May 2022 07:47:57 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 3F6A211250F; Mon, 16 May 2022 07:47:51 +0000 (UTC) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by gabe.freedesktop.org (Postfix) with ESMTPS id 04ADD10FE7C; Mon, 16 May 2022 07:47:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1652687270; x=1684223270; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to; bh=SIhYFzm2FFD27O3PChvRlLGYBQfPM9Ojq71ndlPxLxQ=; b=INVg9sY1+gUBxGw5/HaLjDlDu9LVtdAKHRdDAzTQVIvg4VotnCcZPC2s EPhHu7QT1A/9ucVNn9Xj2Mf58ciQTgxCkYXIydhdK1hYbim6wR5VsAJ5q lk/RiLqk8HAz15n1myk84HKdzDG1vnh2nxf/be5bW9uIMOkbyhMj003wj sEOlJweeT/74v/FrIejY8DiMUbBDsxuUgP/ZcqNfsd1MWKXicKYCPPuuZ dAH5AZje4uKv6IPVtBrZRqtgVn1wBqiXbc4/4EHPsccXO19EucDT2wUQO UJgfbTCO9Apg6l7DML9gRRf19bOWlTekCVlS2txCnfu0XdOA3BSUdaFIQ w==; X-IronPort-AV: E=McAfee;i="6400,9594,10348"; a="357167622" X-IronPort-AV: E=Sophos;i="5.91,229,1647327600"; d="scan'208,217";a="357167622" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 May 2022 00:47:49 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.91,229,1647327600"; d="scan'208,217";a="672235349" Received: from linux.intel.com ([10.54.29.200]) by fmsmga002.fm.intel.com with ESMTP; 16 May 2022 00:47:48 -0700 Received: from [10.249.144.170] (unknown [10.249.144.170]) by linux.intel.com (Postfix) with ESMTP id B9C74580AFE; Mon, 16 May 2022 00:47:44 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------tAeg05Edtp7XePSR0Kz8qz4o" Message-ID: Date: Mon, 16 May 2022 10:47:43 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: [PATCH v3] uapi/drm/i915: Document memory residency and Flat-CCS capability of obj Content-Language: en-US To: Jordan Justen , Ramalingam C , dri-devel , intel-gfx References: <20220502141508.2327-1-ramalingam.c@intel.com> <08039c07-a32e-7725-bc98-db49eefb3e86@intel.com> <165247597144.852381.16262736277926454494@jljusten-skl> From: Lionel Landwerlin In-Reply-To: <165247597144.852381.16262736277926454494@jljusten-skl> X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Tony Ye , Thomas Hellstrom , Nanley Chery , Daniel Vetter , Kenneth Graunke , Jon Bloomfield , Matthew Auld , mesa-dev@lists.freedesktop.org Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" This is a multi-part message in MIME format. --------------tAeg05Edtp7XePSR0Kz8qz4o Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 14/05/2022 00:06, Jordan Justen wrote: > On 2022-05-13 05:31:00, Lionel Landwerlin wrote: >> 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 >>> cc: Matthew Auld >>> cc: Thomas Hellstrom >>> cc: Daniel Vetter >>> cc: Jon Bloomfield >>> cc: Lionel Landwerlin >>> cc: Kenneth Graunke >>> cc:mesa-dev@lists.freedesktop.org >>> cc: Jordan Justen >>> cc: Tony Ye >>> Reviewed-by: Matthew Auld >>> --- >>> 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? >> > Acked-by: Jordan Justen > > I think Nanley has accounted for this on iris with: > > https://gitlab.freedesktop.org/mesa/mesa/-/commit/42a865730ef72574e179b56a314f30fdccc6cba8 > > -Jordan Thanks Jordan, We might want to through in an additional : assert((|flags &||BO_ALLOC_SMEM) == 0); in the CCS case | | | |-Lionel | --------------tAeg05Edtp7XePSR0Kz8qz4o Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
On 14/05/2022 00:06, Jordan Justen wrote:
On 2022-05-13 05:31:00, Lionel Landwerlin wrote:

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?


Acked-by: Jordan Justen <jordan.l.justen@intel.com>

I think Nanley has accounted for this on iris with:

https://gitlab.freedesktop.org/mesa/mesa/-/commit/42a865730ef72574e179b56a314f30fdccc6cba8

-Jordan

Thanks Jordan,


We might want to through in an additional : assert((flags & BO_ALLOC_SMEM) == 0); in the CCS case


-Lionel

--------------tAeg05Edtp7XePSR0Kz8qz4o-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 9ADFFC433EF for ; Mon, 16 May 2022 07:47:51 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id E40EC112378; Mon, 16 May 2022 07:47:50 +0000 (UTC) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by gabe.freedesktop.org (Postfix) with ESMTPS id 04ADD10FE7C; Mon, 16 May 2022 07:47:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1652687270; x=1684223270; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to; bh=SIhYFzm2FFD27O3PChvRlLGYBQfPM9Ojq71ndlPxLxQ=; b=INVg9sY1+gUBxGw5/HaLjDlDu9LVtdAKHRdDAzTQVIvg4VotnCcZPC2s EPhHu7QT1A/9ucVNn9Xj2Mf58ciQTgxCkYXIydhdK1hYbim6wR5VsAJ5q lk/RiLqk8HAz15n1myk84HKdzDG1vnh2nxf/be5bW9uIMOkbyhMj003wj sEOlJweeT/74v/FrIejY8DiMUbBDsxuUgP/ZcqNfsd1MWKXicKYCPPuuZ dAH5AZje4uKv6IPVtBrZRqtgVn1wBqiXbc4/4EHPsccXO19EucDT2wUQO UJgfbTCO9Apg6l7DML9gRRf19bOWlTekCVlS2txCnfu0XdOA3BSUdaFIQ w==; X-IronPort-AV: E=McAfee;i="6400,9594,10348"; a="357167622" X-IronPort-AV: E=Sophos;i="5.91,229,1647327600"; d="scan'208,217";a="357167622" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 May 2022 00:47:49 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.91,229,1647327600"; d="scan'208,217";a="672235349" Received: from linux.intel.com ([10.54.29.200]) by fmsmga002.fm.intel.com with ESMTP; 16 May 2022 00:47:48 -0700 Received: from [10.249.144.170] (unknown [10.249.144.170]) by linux.intel.com (Postfix) with ESMTP id B9C74580AFE; Mon, 16 May 2022 00:47:44 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------tAeg05Edtp7XePSR0Kz8qz4o" Message-ID: Date: Mon, 16 May 2022 10:47:43 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Content-Language: en-US To: Jordan Justen , Ramalingam C , dri-devel , intel-gfx References: <20220502141508.2327-1-ramalingam.c@intel.com> <08039c07-a32e-7725-bc98-db49eefb3e86@intel.com> <165247597144.852381.16262736277926454494@jljusten-skl> From: Lionel Landwerlin In-Reply-To: <165247597144.852381.16262736277926454494@jljusten-skl> Subject: Re: [Intel-gfx] [PATCH v3] uapi/drm/i915: Document memory residency and Flat-CCS capability of obj X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Thomas Hellstrom , Daniel Vetter , Kenneth Graunke , Matthew Auld , mesa-dev@lists.freedesktop.org Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" This is a multi-part message in MIME format. --------------tAeg05Edtp7XePSR0Kz8qz4o Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 14/05/2022 00:06, Jordan Justen wrote: > On 2022-05-13 05:31:00, Lionel Landwerlin wrote: >> 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 >>> cc: Matthew Auld >>> cc: Thomas Hellstrom >>> cc: Daniel Vetter >>> cc: Jon Bloomfield >>> cc: Lionel Landwerlin >>> cc: Kenneth Graunke >>> cc:mesa-dev@lists.freedesktop.org >>> cc: Jordan Justen >>> cc: Tony Ye >>> Reviewed-by: Matthew Auld >>> --- >>> 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? >> > Acked-by: Jordan Justen > > I think Nanley has accounted for this on iris with: > > https://gitlab.freedesktop.org/mesa/mesa/-/commit/42a865730ef72574e179b56a314f30fdccc6cba8 > > -Jordan Thanks Jordan, We might want to through in an additional : assert((|flags &||BO_ALLOC_SMEM) == 0); in the CCS case | | | |-Lionel | --------------tAeg05Edtp7XePSR0Kz8qz4o Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
On 14/05/2022 00:06, Jordan Justen wrote:
On 2022-05-13 05:31:00, Lionel Landwerlin wrote:

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?


Acked-by: Jordan Justen <jordan.l.justen@intel.com>

I think Nanley has accounted for this on iris with:

https://gitlab.freedesktop.org/mesa/mesa/-/commit/42a865730ef72574e179b56a314f30fdccc6cba8

-Jordan

Thanks Jordan,


We might want to through in an additional : assert((flags & BO_ALLOC_SMEM) == 0); in the CCS case


-Lionel

--------------tAeg05Edtp7XePSR0Kz8qz4o--