<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <br>
    <br>
    <div class="moz-cite-prefix">Am 31.10.23 um 15:14 schrieb Michel
      Dänzer:<br>
    </div>
    <blockquote type="cite" cite="mid:454e7d7f-8a23-58bd-8822-55c13beba97f@mailbox.org">
      <pre class="moz-quote-pre" wrap="">On 10/31/23 14:40, Tatsuyuki Ishi wrote:
</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">In Vulkan, it is the application's responsibility to perform adequate
synchronization before a sparse unmap, replace or BO destroy operation.
Until now, the kernel applied the same rule as implicitly-synchronized
APIs like OpenGL, which with per-VM BOs made page table updates stall the
queue completely. The newly added AMDGPU_VM_EXPLICIT_SYNC flag allows
drivers to opt-out of this behavior, while still ensuring adequate implicit
sync happens for kernel-initiated updates (e.g. BO moves).

We record whether to use implicit sync or not for each freed mapping. To
avoid increasing the mapping struct's size, this is union-ized with the
interval tree field which is unused after the unmap.

The reason this is done with a GEM ioctl flag, instead of being a VM /
context global setting, is that the current libdrm implementation shares
the DRM handle even between different kind of drivers (radeonsi vs radv).
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
Different drivers always use separate contexts though, even with the same DRM file description, don't they?</pre>
    </blockquote>
    <br>
    Separate contexts don't help here since the VA space is shared
    between the two.<br>
    <br>
    <blockquote type="cite" cite="mid:454e7d7f-8a23-58bd-8822-55c13beba97f@mailbox.org">
      <pre class="moz-quote-pre" wrap="">

FWIW, RADV will also want explicit sync in the CS ioctl.</pre>
    </blockquote>
    <span style="white-space: pre-wrap">
You can replace that with the DMA-buf IOCTLs like Faith is planning to do for NVK.

Regards,
Christian.
</span><br>
  </body>
</html>