Am 18.05.21 um 17:20 schrieb Thomas Hellström:
On 5/18/21 5:18 PM, Christian König wrote:
Am 18.05.21 um 17:15 schrieb Thomas Hellström:
On 5/18/21 10:26 AM, Thomas Hellström wrote:
We are calling the eviction_valuable driver callback at eviction
time to
determine whether we actually can evict a buffer object.
The upcoming i915 TTM backend needs the same functionality for
swapout,
and that might actually be beneficial to other drivers as well.
Add an eviction_valuable call also in the swapout path. Try to keep
the
current behaviour for all drivers by returning true if the buffer
object
is already in the TTM_PL_SYSTEM placement. We change behaviour for the
case where a buffer object is in a TT backed placement when swapped
out,
in which case the drivers normal eviction_valuable path is run.
Finally export ttm_tt_unpopulate() and don't swap out bos
that are not populated. This allows a driver to purge a bo at
swapout time if its content is no longer valuable rather than to
have TTM swap the contents out.
Cc: Christian König <christian.koenig@xxxxxxx>
Signed-off-by: Thomas Hellström <thomas.hellstrom@xxxxxxxxxxxxxxx>
Christian,
Here we have a ttm_tt_unpopulate() export as well at the end. I
figure you will push back on that one. What we really need is a
functionality to just drop the bo contents and end up in system
memory unpopulated. Should I perhaps add a utility function to do
that instead? like ttm_bo_purge()?
We already have that. Just call ttm_bo_validate() without any place
to put the buffer.
See how ttm_bo_pipeline_gutting() is used.
Christian.
OK, so is that reentrant from the move() or swap_notify() callback.
That sounds like a design bug to me since you should never need to do this.
When you want to destroy the backing store of a buffer during eviction
you should just do this by returning an empty placement from the
evict_flags callback.
It is TTMs job to deal with the buffer placement and drivers are no
longer allowed to mess with that.
Regards,
Christian.
/Thomas
Thanks,
Thomas
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
