<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jul 5, 2017 at 10:53 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">Quoting Jason Ekstrand (2017-07-05 18:21:08)<br>
<span class="">>  static void<br>
>  anv_cmd_buffer_process_relocs(<wbr>struct anv_cmd_buffer *cmd_buffer,<br>
>                                struct anv_reloc_list *list)<br>
> @@ -1450,6 +1484,14 @@ anv_cmd_buffer_execbuf(struct anv_device *device,<br>
>           impl->fd = -1;<br>
>           break;<br>
><br>
> +      case ANV_SEMAPHORE_TYPE_DRM_<wbr>SYNCOBJ:<br>
> +         result = anv_execbuf_add_syncobj(&<wbr>execbuf, impl->syncobj,<br>
> +                                          I915_EXEC_FENCE_WAIT,<br>
> +                                          &device->alloc);<br>
<br>
</span>A wait on an uninitialized fence is invalid (it's a user error in the Vk<br>
spec, right?). Similarly, I understood the spec to imply that once a<br>
fence was used for waiting, it was consumed and invalid until it was<br>
reinitialized via a signal operation later. Do you want to tell the<br>
kernel to clear/reset the fence back to uninitialized after a wait?<br>
(i.e. something like FENCE_WAIT | FENCE_UNSIGNAL)<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>That isn't needed because the fence will get automatically "reset" as part of the next execbuf operation which signals it.  The Vulkan API restriction allows for a variety of implementations, one of which is to do the reset as part of signaling.  We're not required to provide any sort of error if they wait on the same fence multiple times.  It's perfectly valid driver behavior for that to just work.<br><br></div><div>--Jason<br></div></div></div></div>