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. */ struct drm_i915_gem_create_ext_memory_regions { /** @base: Extension link. See struct i915_user_extension. */
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. */
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/42a865730ef72574e179b56a31...
-Jordan
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 Cramalingam.c@intel.com cc: Matthew Auldmatthew.auld@intel.com cc: Thomas Hellstromthomas.hellstrom@linux.intel.com cc: Daniel Vetterdaniel.vetter@ffwll.ch cc: Jon Bloomfieldjon.bloomfield@intel.com cc: Lionel Landwerlinlionel.g.landwerlin@intel.com cc: Kenneth Graunkekenneth@whitecape.org cc:mesa-dev@lists.freedesktop.org cc: Jordan Justenjordan.l.justen@intel.com cc: Tony Yetony.ye@intel.com Reviewed-by: Matthew Auldmatthew.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 Justenjordan.l.justen@intel.com
I think Nanley has accounted for this on iris with:
https://gitlab.freedesktop.org/mesa/mesa/-/commit/42a865730ef72574e179b56a31...
-Jordan
Thanks Jordan,
We might want to through in an additional : assert((|flags &||BO_ALLOC_SMEM) == 0); in the CCS case |
| |
|-Lionel |
On 2022-05-16 00:47:43, Lionel Landwerlin wrote:
On 14/05/2022 00:06, Jordan Justen wrote:
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/42a865730ef72574e179b56a314f30fdccc6cba8Thanks Jordan,
We might want to through in an additional : assert((flags & BO_ALLOC_SMEM) == 0); in the CCS case
Yeah. I noticed this potential for concern when looking at the small-bar uapi on iris. I added an assert, and I haven't seen it get triggered yet.
-Jordan
On 2022-05-13 at 14:06:11 -0700, 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
Thank you Jordan for the Ack!
Ram
I think Nanley has accounted for this on iris with:
https://gitlab.freedesktop.org/mesa/mesa/-/commit/42a865730ef72574e179b56a31...
-Jordan
Media driver never creates a BO with more than one backing regions.
Acked-by: Tony Ye tony.ye@intel.com
Thanks,
Tony
On 5/2/2022 7:15 AM, 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
*/ struct drm_i915_gem_create_ext_memory_regions { /** @base: Extension link. See struct i915_user_extension. */
- I915_MEMORY_CLASS_DEVICE regions.
dri-devel@lists.freedesktop.org
-
Jordan Justen -
Lionel Landwerlin -
Ramalingam C -
Ye, Tony