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@linux.intel.com
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