Re: [Intel-gfx] [Linaro-mm-sig] [RFC PATCH 1/2] dma-fence: Avoid establishing a locking order between fence classes

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

On 12/3/21 15:26, Christian König wrote:
> [Adding Daniel here as well]
>
> Am 03.12.21 um 15:18 schrieb Thomas Hellström:
>> [SNIP]
>>> Well that's ok as well. My question is why does this single dma_fence
>>> then shows up in the dma_fence_chain representing the whole
>>> migration?
>> What we'd like to happen during eviction is that we
>>
>> 1) await any exclusive- or moving fences, then schedule the migration
>> blit. The blit manages its own GPU ptes. Results in a single fence.
>> 2) Schedule unbind of any gpu vmas, resulting possibly in multiple
>> fences.
>> 3) Most but not all of the remaining resv shared fences will have been
>> finished in 2) We can't easily tell which so we have a couple of shared
>> fences left.
>
> Stop, wait a second here. We are going a bit in circles.
>
> Before you migrate a buffer, you *MUST* wait for all shared fences to 
> complete. This is documented mandatory DMA-buf behavior.
>
> Daniel and I have discussed that quite extensively in the last few month.
>
> So how does it come that you do the blit before all shared fences are 
> completed?

Well we don't currently but wanted to... (I haven't consulted Daniel in 
the matter, tbh).

I was under the impression that all writes would add an exclusive fence 
to the dma_resv. If that's not the case or this is otherwise against the 
mandatory DMA-buf bevhavior, we can certainly keep that part as is and 
that would eliminate 3).

/Thomas