[PATCH] drm/syncobj: Allow wait for submit and signal behavior (v2)

Christian König deathsimple at vodafone.de
Thu Aug 10 12:26:48 UTC 2017


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
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel




More information about the dri-devel mailing list