[PATCH v3] uapi/drm/i915: Document memory residency and Flat-CCS capability of obj

[Lionel Landwerlin]

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 at intel.com>
>>> cc: Matthew Auld<matthew.auld at intel.com>
>>> cc: Thomas Hellstrom<thomas.hellstrom at linux.intel.com>
>>> cc: Daniel Vetter<daniel.vetter at ffwll.ch>
>>> cc: Jon Bloomfield<jon.bloomfield at intel.com>
>>> cc: Lionel Landwerlin<lionel.g.landwerlin at intel.com>
>>> cc: Kenneth Graunke<kenneth at whitecape.org>
>>> cc:mesa-dev at lists.freedesktop.org
>>> cc: Jordan Justen<jordan.l.justen at intel.com>
>>> cc: Tony Ye<tony.ye at intel.com>
>>> Reviewed-by: Matthew Auld<matthew.auld at 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 at 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
|
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20220516/3e8182ce/attachment.htm>