On Mon, Mar 9, 2020 at 11:21 AM Christian König christian.koenig@amd.com wrote:
Am 05.03.20 um 16:54 schrieb Jason Ekstrand:
On Thu, Mar 5, 2020 at 7:06 AM Christian König christian.koenig@amd.com wrote:
[SNIP] Well as far as I can see this won't work because it would break the semantics of the timeline sync.
I'm not 100% convinced it has to. We already have support for the seqno regressing and we ensure that we still wait for all the fences. I thought maybe we could use that but I haven't spent enough time looking at the details to be sure. I may be missing something.
That won't work. The seqno regression works by punishing userspace for doing something stupid and undefined.
Be we can't do that under normal circumstances.
I can prototype that if you want, shouldn't be more than a few hours of hacking anyway.
If you'd like to, go for it. I'd be happy to give it a go as well but if you already know what you want, it may be easier for you to just write the patch for the cursor.
Send you two patches for that a few minutes ago. But keep in mind that those are completely untested.
No worries. They were full of bugs but I think I've got them sorted out now. The v2's I'm about to send seem to work. I'm going to leave a Vulkan demo running all night long just to make sure I'm not leaking memory like mad.
--Jason
Two more questions:
- Do you want this collapsing to happen every time we create a
dma_fence_array or should it be a special entrypoint? Collapsing all the time likely means doing extra array calculations instead of the dma_fence_array taking ownership of the array that's passed in. My gut says that cost is ok; but my gut doesn't spend much time in kernel space.
In my prototype implementation that is a dma_resv function you call and get either a single fence or a dma_fence_array with the collapsed fences in return.
But I wouldn't add that to the general dma_fence_array_init function since this is still a rather special case. Well see the patches, they should be pretty self explaining.
- When we do the collapsing, should we call dma_fence_is_signaled()
to avoid adding signaled fences to the array? It seems like avoiding adding references to fences that are already signaled would let the kernel clean them up faster and reduce the likelihood that a fence will hang around forever because it keeps getting added to arrays with other unsignaled fences.
I think so. Can't think of a good reason why we would want to add already signaled fences to the array.
Christian.
--Jason