On 10/13/21 16:33, Daniel Vetter wrote:
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@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.
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 :-)
I'll take a look to see if I can use dma_fence_chain for this case.
Thanks,
/Thomas
-Daniel