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<ramalinga...@intel.com>
cc: Matthew Auld<matthew.a...@intel.com>
cc: Thomas Hellstrom<thomas.hellst...@linux.intel.com>
cc: Daniel Vetter<daniel.vet...@ffwll.ch>
cc: Jon Bloomfield<jon.bloomfi...@intel.com>
cc: Lionel Landwerlin<lionel.g.landwer...@intel.com>
cc: Kenneth Graunke<kenn...@whitecape.org>
cc:mesa-...@lists.freedesktop.org
cc: Jordan Justen<jordan.l.jus...@intel.com>
cc: Tony Ye<tony...@intel.com>
Reviewed-by: Matthew Auld<matthew.a...@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.jus...@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
|

Reply via email to