<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Feb 28, 2017 at 9:14 AM, Chris Wilson <span dir="ltr"><<a href="mailto:chris@chris-wilson.co.uk" target="_blank">chris@chris-wilson.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, Feb 28, 2017 at 08:56:45AM -0800, Jason Ekstrand wrote:<br>
> This implementation allocates a 4k BO for each semaphore that can be<br>
> exported using OPAQUE_FD and uses the kernel's already-existing<br>
> synchronization mechanism on BOs.<br>
> ---<br>
</span><span class="">>  VkResult<br>
>  anv_cmd_buffer_execbuf(struct anv_device *device,<br>
> -                       struct anv_cmd_buffer *cmd_buffer)<br>
> +                       struct anv_cmd_buffer *cmd_buffer,<br>
> +                       const VkSemaphore *in_semaphores,<br>
> +                       uint32_t num_in_semaphores,<br>
> +                       const VkSemaphore *out_semaphores,<br>
> +                       uint32_t num_out_semaphores)<br>
>  {<br>
>     struct anv_execbuf execbuf;<br>
>     anv_execbuf_init(&execbuf);<br>
><br>
> +   for (uint32_t i = 0; i < num_in_semaphores; i++) {<br>
> +      ANV_FROM_HANDLE(anv_semaphore, semaphore, in_semaphores[i]);<br>
> +      assert(semaphore->temporary.<wbr>type == ANV_SEMAPHORE_TYPE_NONE);<br>
> +      struct anv_semaphore_impl *impl = &semaphore->permanent;<br>
> +<br>
> +      switch (impl->type) {<br>
> +      case ANV_SEMAPHORE_TYPE_BO:<br>
> +         anv_execbuf_add_bo(&execbuf, &impl->bo, NULL, 0, &device->alloc);<br>
> +         break;<br>
> +      default:<br>
> +         break;<br>
> +      }<br>
> +   }<br>
<br>
</span>Do the in/out semaphores[] have any constraints against repeated use? If<br>
you pass in the same handle twice into the execbuf, it will EINVAL.<br>
(Both within the in/out arrays and between them.)<br></blockquote><div><br></div><div>Yes.  The way Vulkan defines the wait/signaling semantics, you can't use the same semaphore twice in a command buffer submission<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Or does execbuf_add_bo do a repeated use check?<span class=""><br></span></blockquote><div><br></div><div>Yes it does.  Well, mostly.  There appear to still be a few issues there thanks to no longer having a direct GEM BO -> anv_bo mapping which need to be sorted out.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> +   for (uint32_t i = 0; i < num_out_semaphores; i++) {<br>
> +      ANV_FROM_HANDLE(anv_semaphore, semaphore, out_semaphores[i]);<br>
> +      assert(semaphore->temporary.<wbr>type == ANV_SEMAPHORE_TYPE_NONE);<br>
> +      struct anv_semaphore_impl *impl = &semaphore->permanent;<br>
> +<br>
> +      switch (impl->type) {<br>
> +      case ANV_SEMAPHORE_TYPE_BO:<br>
> +         anv_execbuf_add_bo(&execbuf, &impl->bo, NULL, EXEC_OBJECT_WRITE,<br>
> +                            &device->alloc);<br>
> +         break;<br>
> +      default:<br>
> +         break;<br>
> +      }<br>
> +   }<br>
<br>
</span>Seperate in/out arrays curtains the issues I could see with the implicit<br>
fences accidentally serialising input-only semaphores.<br>
<span class="HOEnZb"><font color="#888888">-Chris<br>
<br>
--<br>
Chris Wilson, Intel Open Source Technology Centre<br>
</font></span></blockquote></div><br></div></div>