On Mon, Jun 07, 2021 at 06:25:42PM +0200, Christian König wrote: > > > Am 07.06.21 um 17:09 schrieb Daniel Vetter: > > On Mon, Jun 07, 2021 at 11:59:11AM +0200, Christian König wrote: > > > Am 07.06.21 um 10:58 schrieb Daniel Vetter: > > > > Hi Christian, > > > > > > > > So unfortunately I got distracted with some i915 bugs and fun last > > > > week completely, so didn't get around to it. > > > > > > > > On Sun, Jun 6, 2021 at 12:03 PM Christian König > > > > <ckoenig.leichtzumerken@xxxxxxxxx> wrote: > > > > > Hi Daniel, > > > > > > > > > > as discussed here are the patches which change the handle around exclusive fence handling. > > > > > > > > > > The main problem seems to have been the dma_resv_test_signaled() function which ignored the exclusive fence when shared fences where present. This was already rather inconsistent since dma_fence_wait_timeout() takes the exclusive one into account even if shared ones are present. > > > > > > > > > > The second patch then fixes nouveu to also always take the exclusive fence into account. > > > > > > > > > > The third then removes the workaround in amdgpu around the VM page table clearing handling. Since I'm not sure if there are no other places which relies on the existing behavior I will hold this one back for a while. > > > > > > > > > > Is that what you had in mind as well? > > > > I think from the semantics something where we treat the exclusive > > > > fence as an IPC mechanism that the kernel doesn't care much about > > > > (exceptions apply), and but more consistently count all access from > > > > any CS as a shared fence. So in a way what you've done here, and also > > > > what you've done in the earlier series with setting the read/write > > > > flags on shared fences. > > > Yeah, I think that this will work for me as well. > > > > > > > For actual approach what I've picked is a bit of what amdgpu does + > > > > what other drivers do with NO_IMPLICIT, but with the bugs fixed > > > > (there's a bunch of them): Essentially we try to always set the shared > > > > fences, and exclusive fences are set additionally on top when the > > > > implicit sync IPC calls for that. And on the depdendency side we do > > > > clever logic to only take in the exclusive fence when required. > > > > Currently for amdgpu this means introspecting the fence owner (there's > > > > some nasty tricks there I think to do to make this work and not be a > > > > security bug), for others that's done with the NO_IMPLICIT flag (but > > > > again some nasty corners there, which I think a bunch of drivers get > > > > wrong). > > > For amdgpu I have been pondering on the following idea last week to make it > > > behave the same as the other drivers: > > > > > > 1. We allow setting the explicit fence without touching the shared fences. > > > As far as I understand it this is also part of your idea above. > > > > > > 2. During command submission amdgpu uses a dma_fence_chain node to chain > > > together the new CS with the existing explicit sync. > > > > > > 3. During command synchronization amdgpu takes a look at the explicit fence > > > and walks the dma_fence_chain history. > > > Submissions from the same process (the owner) are not synced to (e.g. > > > same behavior as of today), but as soon as we see something which doesn't > > > fit into the amdgpu CS model we sync to the remaining chain. > > > > > > That would give us both keeping the current amdgpu CS behavior (which we > > > then can extend) as well as setting the explicit fence according to the > > > DMA-buf rules. > > So what I had in mind is: > > > > 1. we reserve 3 additional shared slots (so one more than currently) > > > > 2. when we pull in depedencies we ignore exclusive fences when they're an > > amdgpu/amdkfd one, only when it's a OWNER_UNKNOWN do we take it > > > > 3. above obviously breaks buffer moves, to fix that we always add the > > ttm_bo->moving fence. If amggpu would support a "ignore implicit fencing" > > flag like other drivers with NO_IMPLICIT, then we'd also need to overrule > > that for a dynamically shared dma-buf (since for those we don't have a > > ->moving fence slot). Non-dynamic dma-buf aren't a problem since they are > > guaranteed to be pinned, so can't move. > > > > 4. When we add fences we > > - always add the exclusive fence (like in my patch) > > - keep the current set of shared fences > > - add our own fences also as a shared one (so that amdpug can ignore the > > exclusive fence for any sync against amdgpu, whether same owner or other > > owner). This is the critical piece to make sure the current uapi for > > amdgpu isn't changed > > - add the previous exclusive fence if a) there is one and b) it's not an > > amdgpu/kfd one. This is where we need the additional fence slot > > That won't work. The problem is that you have only one exclusive slot, but > multiple submissions which execute out of order and compose the buffer > object together. > > That's why I suggested to use the dma_fence_chain to circumvent this. > > But if you are ok that amdgpu sets the exclusive fence without changing the > shared ones than the solution I've outlined should already work as well. Uh that's indeed nasty. Can you give me the details of the exact use-case so I can read the userspace code and come up with an idea? I was assuming that even with parallel processing there's at least one step at the end that unifies it for the next process. If we can't detect this somehow then it means we do indeed have to create a fence_chain for the exclusive slot for everything, which would be nasty. Or a large-scale redo across all drivers, which is probaly even more nasty. -Daniel > > Regards, > Christian. > > > > > At first glance this throws away foreign exclusive fences, which could > > break implicit sync. But by moving foreign exclusive fences to the shared > > slot, we can rely on the amdgpu implicit sync logic of only looking at the > > owner (and not whether a fence is exclusive of shared), and we get the > > right implicit fencing even on subsequent CS. > > > > And for foreign drivers it also all works, because the exlusive fence is > > always set, and because amdgpu doesn't ignore foreign fences (even if > > they're set as shared we force a sync iirc) there's a dependency chain > > that makes sure everything is correct and ordered. Same for dma-buf > > poll/sync_file export, that would then work on amdgpu correctly too > > because the exclusive slot is set. > > > > The only downside here is that amdgpu always sets the exclusive fence > > slot, but that can't be fixed without an uapi revision since the kernel > > simply doesn't know that. But amdgpu isn't the only driver, panfrost does > > the same so *shrugh*. > > > > So I think this should work but > > - it's a hellalot of auditing to make sure I didn't miss anything > > - and it's like attempt no 5 or so of me trying to slice this knot without > > breaking anything, or changing the current dma_resv rules. > > > > > > There's two reasons I'm more leaning in that direction: > > > > - The annoying thing is that the audit on the dependency side is a lot > > > > trickier since everyone rolls their own dependency handling. > > > Yes, absolutely agree. That's why I said we need to have use case based > > > functionality here. > > > > > > In other words what we need is something like an > > > dma_resv_for_each_sync_fence(for_write) macro. > > > > > > E.g. drivers then only do something like: > > > > > > dma_resv_for_each_sync_fence(resv, for_write, fence) > > > driver_specific_syncing_to_fence(fence); > > > > > > And not every driver calling the underlying functions on it's own and then > > > doing whatever it pleases. > > Yeah, but amdgpu can't use those, so we're back to square one. amdgpu > > currently has zero information from userspace about which CS are writes > > and which are not. Other drivers (aside from panfrost) generally have > > that, so they can do smarter things here. > > > > Also we could fairly trivially fix this by adding new uapi so that amdgpu > > would know this, and just oversyncing on old uerspace. But you made it > > pretty clear when I proposed that that this option isn't on the table. > > > > So for now we need to be more clever to get amdgpu aligned. And then when > > that's done we (well you guys, maybe using the patches from Jason + a CS > > flag to not do implicit sync at all) can add the uapi to make this > > smarter. > > > > Then, and only then, do we have the pieces to look into smarter/use-case > > dependent dma_resv helpers. > > > > Also, some of these helpers already exist, and are used by the drivers > > derived from v3d. But amdgpu can't use them, because the "just oversync > > for current userspace" approach you nacked. So you'll have to live with > > your own quirks. I don't want to make helpers for that because then other > > drivers might come up with the idea to use them :-) > > > > > > If we don't change (for now at least) the rules around dma_resv then an > > > > oversight in the audit isn't going to be a huge problem. > > > > - Wording becomes inconsistent: An exclusive fence which is also a > > > > shared is a bit confusing. I think it's better if we stick to the > > > > current rules for dma_resv, change the semantics we want in drivers (I > > > > think that's doable, at maybe some code cost e.g. Jason's import ioctl > > > > would be simpler with your changed rules, but still doable with the > > > > current dma_resv rules). And then when we have that, we figure out > > > > what to change with the dma_resv struct/rules. > > > But then at least do the minimal change so that we can get amdgpu in line > > > with all other drivers like I outlined above. > > > > > > We can keep that as a hack in amdgpu if that makes you feel better. Chaining > > > the exclusive fence together is roughly 4 times slower than the shared > > > approach, but I think that this is negligible compared to all the other > > > stuff we do. > > Yeah I was pondering on the chaining, and for the intentional sync it's > > not a problem because it's just 1 winsys buffer we touch like this. So > > totally fine in Jason's approach. But not for amdgpu, where with the > > current uapi means you have to annotate _all_ buffers as written to. > > > > So not great, and which is why I've thrown a few variants of this idea out > > already as unpractical. Hence the current idea I'm toying with above. > > > > Cheers, Daniel > > > > > > > Regards, > > > Christian. > > > > > > > Wrt the patches: Good thing is that what you change here and what I've > > > > found thus far is 100% not overlapping, so at least we didn't waste > > > > time auditing the same code :-) > > > > > > > > Cheers, Daniel > > > > > Regards, > > > > > Christian. > > > > > > > > > > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
