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 -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
