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

[Daniel Vetter]

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