Am 09.08.2017 um 23:31 schrieb Chris Wilson:
Quoting Jason Ekstrand (2017-08-09 18:00:54)+static signed long drm_syncobj_array_wait_timeout(struct drm_syncobj **syncobjs, + uint32_t count, + uint32_t flags, + signed long timeout, + uint32_t *idx) +{ + struct syncobj_wait_entry *entries; + struct dma_fence *fence; + signed long ret; + uint32_t signaled_count, i; + + if (timeout == 0) { + signaled_count = 0; + for (i = 0; i < count; ++i) { + ret = drm_syncobj_signaled(syncobjs[i], flags); + if (ret < 0) + return ret; + if (ret == 0) + continue; + if (signaled_count == 0 && idx) + *idx = i; + signaled_count++; + } + + if (flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL) + return signaled_count == count ? 1 : 0; + else + return signaled_count > 0 ? 1 : 0;There's a very annoying laxness in the dma_fence API here, in that backends are not required to automatically report when a fence is signaled prior to fence->ops->enable_signaling() being called. So here if we fail to match signaled_count, we need to fallthough and try a 0 timeout wait!Christian, dma_fence_wait_any_timeout() has this same bug you told me off for, e.g. commit 698c0f7ff216 ("dma-buf/fence: revert "don't wait when specified timeout is zero" (v2)")!
Thanks for pointing this out, going to take care of this issue. Christian.
-Chris _______________________________________________ dri-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________ dri-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/dri-devel
