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