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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
