<!DOCTYPE html><html><head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body> Am 13.11.24 um 03:30 schrieb Matthew Brost: <blockquote type="cite" cite="mid:ZzQPYocTEvnJVgQ1@lstrano-desk.jf.intel.com">[SNIP] <blockquote type="cite"> <blockquote type="cite"> <pre class="moz-quote-pre" wrap=""></pre> </blockquote> </blockquote> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">If you're using gpuvm, just call drm_gpuvm_resv_add_fence. I assume AMD has a similarly simple call. </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> Nope, we try to avoid locking all BOs in the VM as hard as we can. </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> Why? Calling in to perform fence conversion shouldn't be all that frequent and simplifies things. Also, it's likely that only a few locks are involved, as not too many external BOs are mapped within a VM (i.e., most BOs share the VM's dma-resv lock).</pre> </blockquote> </blockquote> The most common use case are multi GPU systems which share a lot of data in a NUMA cluster. This configuration has almost all BOs shared between GPUs making locking the whole VM a task with massive overhead which should be avoided as much as possible. <blockquote type="cite" cite="mid:ZzQPYocTEvnJVgQ1@lstrano-desk.jf.intel.com"> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">Now the ordering works inherently in dma-resv and the scheduler. e.g. No need to track the last completion fences explictly in preempt fences. </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> I really don't think that this is a good approach. Explicitly keeping the last completion fence in the pre-emption fence is basically a must have as far as I can see. The approach you take here looks like a really ugly hack to me. </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> Well, I have to disagree; it seems like a pretty solid, common design.</pre> </blockquote> </blockquote> What you basically do is to move the responsibility to signal fences in the right order from the provider of the fences to the consumer of it. Since we have tons of consumers of that stuff this is not even remotely a defensive design. <blockquote type="cite" cite="mid:ZzQPYocTEvnJVgQ1@lstrano-desk.jf.intel.com"> <blockquote type="cite"> <pre class="moz-quote-pre" wrap=""> Anyway, I think I have this more or less working. I want to run this by the Mesa team a bit to ensure I haven't missed anything, and will likely post something shortly after. We can discuss this more after I post and perhaps solicit other opinions, weighing the pros and cons of the approaches here. I do think they function roughly the same, so something commonly agreed upon would be good. Sharing a bit of code, if possible, is always a plus too.</pre> </blockquote> </blockquote> Well to make it clear that will never ever get a green light from my side as DMA-buf maintainer. What you suggest here is extremely fragile. Why not simply wait for the pending completion fences as dependency for signaling preemption fences? That should work for all drivers and is trivial to implement as far as I can see. Regards, Christian. <blockquote type="cite" cite="mid:ZzQPYocTEvnJVgQ1@lstrano-desk.jf.intel.com"> <blockquote type="cite"> <pre class="moz-quote-pre" wrap=""> Matt </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">Regards, Christian. </pre> </blockquote> </blockquote> </blockquote> </body> </html>