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. /Thomas
