On Wed, Jul 5, 2017 at 10:53 AM, Chris Wilson <ch...@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
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
