Re: [RFC PATCH] drm/ttm: Simplify the delayed destroy locking

["Thomas Hellström" <thomas.hellstrom@linux.intel.com>]

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?

/Thomas


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel