Re: [PATCH v3] uapi/drm/i915: Document memory residency and Flat-CCS capability of obj
Media driver never creates a BO with more than one backing regions. Acked-by: Tony Ye 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 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 _i915_gem_create_ext.handle, * along with the final object size in _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. */
Re: [PATCH v3] uapi/drm/i915: Document memory residency and Flat-CCS capability of obj
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 > > > 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 > > > _i915_gem_create_ext.handle, > > >* along with the final object size in _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 Thank you Jordan for the Ack! Ram > > I think Nanley has accounted for this on iris with: > > https://gitlab.freedesktop.org/mesa/mesa/-/commit/42a865730ef72574e179b56a314f30fdccc6cba8 > > -Jordan
Re: [PATCH v3] uapi/drm/i915: Document memory residency and Flat-CCS capability of obj
On 2022-05-16 00:47:43, Lionel Landwerlin wrote: > On 14/05/2022 00:06, Jordan Justen wrote: >> >> Acked-by: Jordan Justen >> >> I think Nanley has accounted for this on iris with: >> >> >> https://gitlab.freedesktop.org/mesa/mesa/-/commit/42a865730ef72574e179b56a314f30fdccc6cba8 >> > > Thanks 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
Re: [PATCH v3] uapi/drm/i915: Document memory residency and Flat-CCS capability of obj
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 _i915_gem_create_ext.handle, * along with the final object size in _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 |
Re: [PATCH v3] uapi/drm/i915: Document memory residency and Flat-CCS capability of obj
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 > > _i915_gem_create_ext.handle, > >* along with the final object size in _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
Re: [PATCH v3] uapi/drm/i915: Document memory residency and Flat-CCS capability of obj
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 _i915_gem_create_ext.handle, * along with the final object size in _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. */
[PATCH v3] uapi/drm/i915: Document memory residency and Flat-CCS capability of obj
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 _i915_gem_create_ext.handle, * along with the final object size in _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. */ -- 2.20.1