> > I also generally agree with Simaâ??s comments about having a somewhat > > generic preempt fence (Christian refers to this as an eviction fence) > > as well. > > Well that is really a bike-sheet. > > I don't care if we call it preempt fence or eviction fence as long as > everybody understands what that thing is supposed to do. > > Probably something we should document. > Agree something common / documented would be good given how tricky this will be to get correct. > > Additionally, Iâ??m thinking it might be beneficial for us to add a new > > 'preempt' dma-resv slot to track these, which would make it easier to > > enforce the ordering of submission fence signaling before preempt > > fences. > > That's exactly what DMA_RESV_USAGE_BOOKKEEP is good for. > We can move this specific discussion to the RFC I posted. Saw you replied there and will respond shortly / once I have followed up on a few things on my end. > And yes, I spend really *a lot of time* planning this :) > I've looked at the list and bunch of patches are on there modifying code which is not merged to drm-tip. e.g. This patch [1]. Trying to piece together what AMD is doing compared to what I had in mind is bit difficult without being able to directly look at the code. Any chance you have a public repo I can look at? [1] https://patchwork.freedesktop.org/patch/622074/?series=140648&rev=1 > > Depending on bandwidth, I may post an RFC to the list soon. Iâ??ll also > > gauge the interest and bandwidth from our Mesa team to begin UMD work. > > Please loop me in as well. > Will do. Coming together pretty quick so it shouldn't be too long until I can post something or push a public branch. I think the Mesa side is going to be the more difficult piece and unsure how much interest there be to move this along. Matt > Regards, > Christian. > > > > > Matt > > > > > Note that the completion fence is only deadlock free if userspace is > > > really, really careful. Which in practice means you need the very > > > carefully constructed rules for e.g. vulkan winsys fences, otherwise you > > > do indeed deadlock. > > > > > > But if you keep that promise in mind, then it works, and step 2 is > > > entirely option, which means we can start userspace in a pure long-running > > > compute mode where there's only eviction/preemption fences. And then if > > > userspace needs a vulkan winsys fence, we can create that with step 2 as > > > needed. > > > > > > But the important part is that you need really strict rules on userspace > > > for when step 2 is ok and won't result in deadlocks. And those rules are > > > uapi, which is why I think doing this in panthor without the shrinker and > > > eviction fences (i.e. steps 3&4 above) is a very bad mistake. > > > > > > > This way you can still do your memory management inside the kernel (e.g. > > > > move BOs from local to system memory) or even completely suspend and resume > > > > applications without their interaction, but as Sima said it is just horrible > > > > complicated to get right. > > > > > > > > We have been working on this for like two years now and it still could be > > > > that we missed something since it is not in production testing yet. > > > Ack. > > > -Sima > > > -- > > > Simona Vetter > > > Software Engineer, Intel Corporation > > > http://blog.ffwll.ch >
