On Wed, Oct 13, 2021 at 04:21:43PM +0200, Thomas Hellström wrote: > On Wed, 2021-10-13 at 14:43 +0200, Daniel Vetter wrote: > > On Fri, Oct 08, 2021 at 03:35:28PM +0200, Thomas Hellström wrote: > > > The TTM managers and, possibly, the gtt address space managers will > > > need to be able to order fences for async operation. > > > Using dma_fence_is_later() for this will require that the fences we > > > hand > > > them are from a single fence context and ordered. > > > > > > Introduce a struct dma_fence_work_timeline, and a function to > > > attach > > > struct dma_fence_work to such a timeline in a way that all previous > > > fences attached to the timeline will be signaled when the latest > > > attached struct dma_fence_work signals. > > > > > > Signed-off-by: Thomas Hellström <thomas.hellstrom@xxxxxxxxxxxxxxx> > > > > I'm not understanding why we need this: > > > > - if we just want to order dma_fence work, then an ordered workqueue > > is > > what we want. Which is why hand-rolling is better than reusing > > dma_fence_work for absolutely everything. > > > > - if we just need to make sure the public fences signal in order, > > then > > it's a dma_fence_chain. > > Part of the same series that needs reworking. > > What we need here is a way to coalesce multiple fences from various > contexts (including both gpu and work fences) into a single fence and > then attach it to a timeline. I thought dma_fence_chain does this for you, including coelescing on the same timeline. Or at least it's supposed to, because if it doesn't you can produce some rather epic chain explosions with vulkan :-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
