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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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




[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux