[Mesa-dev] [PATCH 3/3] anv: Use DRM sync objects for external semaphores when available

[Jason Ekstrand]

On Wed, Jul 5, 2017 at 10:53 AM, Chris Wilson <chris at chris-wilson.co.uk>
wrote:

> Quoting Jason Ekstrand (2017-07-05 18:21:08)
> >  static void
> >  anv_cmd_buffer_process_relocs(struct anv_cmd_buffer *cmd_buffer,
> >                                struct anv_reloc_list *list)
> > @@ -1450,6 +1484,14 @@ anv_cmd_buffer_execbuf(struct anv_device *device,
> >           impl->fd = -1;
> >           break;
> >
> > +      case ANV_SEMAPHORE_TYPE_DRM_SYNCOBJ:
> > +         result = anv_execbuf_add_syncobj(&execbuf, impl->syncobj,
> > +                                          I915_EXEC_FENCE_WAIT,
> > +                                          &device->alloc);
>
> A wait on an uninitialized fence is invalid (it's a user error in the Vk
> spec, right?). Similarly, I understood the spec to imply that once a
> fence was used for waiting, it was consumed and invalid until it was
> reinitialized via a signal operation later. Do you want to tell the
> kernel to clear/reset the fence back to uninitialized after a wait?
> (i.e. something like FENCE_WAIT | FENCE_UNSIGNAL)
>

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.

--Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170705/2b25706d/attachment-0001.html>