| Message ID | 20220502141508.2327-1-ramalingam.c@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v3] uapi/drm/i915: Document memory residency and Flat-CCS capability of obj | expand |
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/42a865730ef72574e179b56a314f30fdccc6cba8 -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 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 |
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/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
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/42a865730ef72574e179b56a314f30fdccc6cba8 > > -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 > + * I915_MEMORY_CLASS_DEVICE regions. > */ > struct drm_i915_gem_create_ext_memory_regions { > /** @base: Extension link. See struct i915_user_extension. */
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. */
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(+)