On Mon, Apr 12, 2021 at 05:49:50PM +0200, Thomas Hellström wrote:
On Mon, 2021-04-12 at 17:43 +0200, Daniel Vetter wrote:
On Mon, Apr 12, 2021 at 04:21:37PM +0200, Christian König wrote:
Am 12.04.21 um 16:16 schrieb Thomas Hellström:
Hi, Christian,
On 4/12/21 4:01 PM, Christian König wrote:
Hi Thomas,
well in general a good idea, but I'm working on a different plan for a while now.
My idea here is that instead of the BO the resource object is kept on a double linked lru list.
The resource objects then have a pointer to either the BO or a fence object.
When it is a fence object we can just grab a reference to it and wait for it to complete.
If it is a BO we evict it the same way we currently do.
This allows to remove both the delayed delete, individualization of BOs, ghost objects etc...
Hmm, ok. So in that case, what would trigger the final release of the buffer object in the absence of a delayed delete list? Would we use a fence callback for that?
Key point is you don't need any final release of the BO any more. When the BOs reference count becomes zero it can be destructed immediately.
Only the resource object is kept around and protected by a fence until it can be released finally.
I was reading dma_resv here for a second, and wondered how we figure out the refcounting for that. But since you aim for a fence, that's refcounted,
Hmm, Good point. What about objects with multiple shared fences?
Package it up into a new fence as part of the privatization step. We already have the helpers for that I think.
It does mean a memory allocation in there, but I /think/ that's fine. -Daniel