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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am 11.05.21 um 16:28 schrieb Thomas Hellström:

On 5/11/21 4:09 PM, Christian König wrote:


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.

Hmm. I can only see it called from ttm_mem_evict_first() which is not in the swapping path? Or do I miss something?

Mhm, looks like my recollection was wrong. We should probably move the call into the ttm_bo_evict_swapout_allowable() function.

Christian.


Thanks,

Thomas




_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux