[Intel-gfx] [PATCH 6/7] drm/i915/ttm, drm/ttm: Introduce a TTM i915 gem object backend

[Christian König]

Am 11.05.21 um 16:06 schrieb Thomas Hellström (Intel):
>
> On 5/11/21 3:58 PM, Christian König wrote:
>> Am 11.05.21 um 15:25 schrieb Thomas Hellström:
>>> Most logical place to introduce TTM buffer objects is as an i915
>>> gem object backend. We need to add some ops to account for added
>>> functionality like delayed delete and LRU list manipulation.
>>>
>>> Initially we support only LMEM and SYSTEM memory, but SYSTEM
>>> (which in this case means evicted LMEM objects) is not
>>> visible to i915 GEM yet. The plan is to move the i915 gem system region
>>> over to the TTM system memory type in upcoming patches.
>>>
>>> We set up GPU bindings directly both from LMEM and from the system 
>>> region,
>>> as there is no need to use the legacy TTM_TT memory type. We reserve
>>> that for future porting of GGTT bindings to TTM.
>>>
>>> There are some changes to TTM to allow for purging system memory buffer
>>> objects and to refuse swapping of some objects: Unfortunately i915 gem
>>> still relies heavily on short-term object pinning, and we've chosen to
>>> keep short-term-pinned buffer objects on the TTM LRU lists for now,
>>> meaning that we need some sort of mechanism to tell TTM they are not
>>> swappable. A longer term goal is to get rid of the short-term pinning.
>>
>> Well just use the eviction_valuable interface for this.
>
> Yes, we do that for vram/lmem eviction, but we have nothing similar 
> for system swapping. Do I understand you correctly that you want me to 
> add a call to eviction_valuable() also for that instead of 
> swap_possible()?

You should already have that. eviction_valuable is called in both cases.

>
>
>>
>> In general please make separate patches for the TTM changes and for 
>> the i915 changes using them for easier review.
>
> I'll respin with a split. Do you want me to do the same also for the 
> other two patches that minmally touch TTM?

Yes, that makes it much easier to review the general usefulness of 
interface changes.

Thanks,
Christian.

>
> Thanks,
>
> Thomas
>
>