<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    Am 24.06.22 um 22:34 schrieb Daniel Vetter:<br>
    <blockquote type="cite" cite="mid:YrYfw6T4MGvifIco@phenom.ffwll.local">
      <pre class="moz-quote-pre" wrap="">Digging out of a hole, apologies to everyone.</pre>
    </blockquote>
    <br>
    No problem, I'm totally overworked as well.<br>
    <br>
    <blockquote type="cite" cite="mid:YrYfw6T4MGvifIco@phenom.ffwll.local">
      <pre class="moz-quote-pre" wrap="">On Fri, Jun 17, 2022 at 03:08:00PM +0200, Christian König wrote:
</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">Am 17.06.22 um 15:03 schrieb Bas Nieuwenhuizen:
</pre>
        <blockquote type="cite">
          <pre class="moz-quote-pre" wrap="">[SNIP]
</pre>
        </blockquote>
        <pre class="moz-quote-pre" wrap="">BOOKKEEP is exactly for that, but as discussed with Daniel that's not what
we want in the kernel.
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
Not sure which Daniel you talked to, but this wasn't me.</pre>
    </blockquote>
    <br>
    Hui what? Of course I'm talking about you.<br>
    <br>
    <blockquote type="cite" cite="mid:YrYfw6T4MGvifIco@phenom.ffwll.local">
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">When you mix implicit with explicit synchronization (OpenGL with RADV for
example) it should be mandatory for the OpenGL to wait for any RADV
submission before issuing an operation.

What you want to do is intentionally not supported.
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
vk is very intentional in it's rejecting of any implicit sync.</pre>
    </blockquote>
    <br>
    [SNIP]<br>
    <br>
    <blockquote type="cite" cite="mid:YrYfw6T4MGvifIco@phenom.ffwll.local">
      <pre class="moz-quote-pre" wrap="">We should probably also document this in the kerneldoc for the BOOKKEEPING
usage that this is the fence type that vulkan cs should use in all
drivers, otherwise this will become an endless mess of driver specific
hacks (i.e. the world we currently live in).</pre>
    </blockquote>
    <br>
    Well, Daniel somehow we are somehow not talking about the same thing
    here :)<br>
    <br>
    I've documented exactly what you describe above in the initial patch
    which added BOOKKEEPING (I've still called it OTHER in that
    iteration):<br>
    <br>
    <blockquote type="cite">
      <pre>><i> +        /**</i>
><i> +  * @DMA_RESV_USAGE_OTHER: No implicit sync.</i>
><i> +  *</i>
><i> +  * This should be used for operations which don't want to add an</i>
><i> +  * implicit dependency at all, but still have a dependency on memory</i>
><i> +  * management.</i>
><i> +  *</i>
><i> +  * This might include things like preemption fences as well as device</i>
><i> +  * page table updates or even userspace command submissions.</i>
><i> +  *</i>
><i> +  * The kernel memory management *always* need to wait for those fences</i>
><i> +  * before moving or freeing the resource protected by the dma_resv</i>
><i> +  * object.</i>
><i> +  */</i>
><i> + DMA_RESV_USAGE_OTHER</i></pre>
    </blockquote>
    <br>
    Later on I've even explicitly mentioned that this is for Vulkan
    submissions.<br>
    <br>
    But it was *you* who made me remove that with the explanation that
    we have to use READ for that or we break existing userspace.<br>
    <br>
    I mean that still makes a lot of sense to me because if I'm not
    completely mistaken we do have use cases which break, especially
    Vulkan+encoding.<br>
    <br>
    Regards,<br>
    Christian.<br>
    <br>
    <blockquote type="cite" cite="mid:YrYfw6T4MGvifIco@phenom.ffwll.local">
      <pre class="moz-quote-pre" wrap="">
-Daniel
</pre>
    </blockquote>
    <br>
  </body>
</html>