On Mon, May 09, 2022 at 03:09:40PM +0200, Christian König wrote:
Hi everyone,
re-sending this because Daniel was requesting a background why this is useful.
Thanks a lot for typing this up. To make sure this isn't lost, could you add a patch to at least add this as a comment to ttm_buffer_object.resource, ideally rolling out the kerneldoc scaffolding for that file while at it and making it kerneldoc?
I think documenting that kind of why&how for key links like ttm_bo->ttm_resource is really important.
When TTM creates a buffer this object initially should not have any backing store and there no resource object associated with it. The same can happen when a driver requests that the backing store of an object is destroyed without allocating a new one.
This is really useful during initial buffer creation as well as temporary buffers and page tables which content doesn't need to be preserved when they are evicted.
Currently TTM allocates dummy system resources for that because drivers couldn't handle a NULL pointer there. Audit the drivers and then clean up TTM to stop making those dummy allocations.
Also I guess this is good prep work for going the other direction, i.e. allowing more than one ttm_resource per ttm_bo? Or is that all mostly orthogonal issues that bo:resource 1:N for N=0 has vs 1:N for N > 1?
Please review and comment,
I'll ... try. But maybe call in some favours from other i915 ttm folks because I'm just really bad at doing review timeline these days :-/ -Daniel