Re: [Intel-gfx] [PATCH 4/6] drm/i915: Add a struct dma_fence_work timeline

["Thomas Hellström" <thomas.hellstrom@linux.intel.com>]

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