Re: [RFC 1/8] dma-buf/fence: add fence_collection fences

[Gustavo Padovan]

Hi Christian,

2016-05-18 Christian König <christian.koenig@xxxxxxx>:

> Am 15.04.2016 um 21:25 schrieb Daniel Vetter:
> > On Fri, Apr 15, 2016 at 11:27:50AM -0700, Gustavo Padovan wrote:
> > > 2016-04-15 Christian König <christian.koenig@xxxxxxx>:
> > > > Amdgpu also has an implementation for a fence collection which uses a a
> > > > hashtable to keep the fences grouped by context (e.g. only the latest fence
> > > > is keept for each context). See amdgpu_sync.c for reference.
> > > > 
> > > > We should either make the collection similar in a way that you can add as
> > > > many fences as you want (like the amdgpu implementation) or make it static
> > > > and only add a fixed number of fences right from the beginning.
> > > > 
> > > > I can certainly see use cases for both, but if you want to stick with a
> > > > static approach you should probably call the new object fence_array instead
> > > > of fence_collection and do as Daniel suggested.
> > > Maybe we can go for something in between. Have fence_collection_init()
> > > need at least two fences to create the fence_collection. Then
> > > fence_collection_add() would add more dinamically.
> > The problem with adding fences later on is that it makes it trivial to add
> > deadlocks and loops. Just add the fence collection to itself, boom. From
> > that pov it's an unsafe api, and hence something to avoid.
> > -Daniel
> 
> Any conclusion on this? Did any version of the patch made it upstream?
> 
> I'm in the need of an array based fence collection right now as well. Any
> objection that I just take the patch proposed here and fix the comments or
> are you still else working on this right now?

I have a new version of this patch that I didn't send upstream yet
because it is part of a bigger patchset. But I can split it and send
what I have for fence_collection later today.

	Gustavo