Quoting Lionel Landwerlin (2019-05-23 14:46:42)
> On 23/05/2019 12:52, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2019-05-23 12:46:20)
> >> - syncobj = drm_syncobj_find(file, fence.handle);
> >> - if (!syncobj) {
> >> - DRM_DEBUG("Invalid syncobj handle provided\n");
> >> - err = -ENOENT;
> >> - goto err;
> >> + if (user_fence.flags &
> >> __I915_EXEC_FENCE_UNKNOWN_FLAGS) {
> >> + err = -EINVAL;
> >> + goto err;
> >> + }
> >> +
> >> + if (user_fence.flags & I915_EXEC_FENCE_WAIT) {
> >> + err = drm_syncobj_find_fence(
> >> + file, user_fence.handle,
> >> user_fence.value,
> >> +
> >> DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT,
> >> + &syncobj, &fence);
> > Is this still a synchronous wait? That would be an unfortunate change in
> > behaviour and antithesis to having a scheduler.
> > -Chris
> >
> Not sure what you mean by synchronous wait.
drm_syncobj_find_fence() has an open-coded wait_event loop. That is
synchronous and inconsistent with using a scheduler; where one only need
to return a proxy fence that will be populated when the syncpt is known,
and be signaled as a result of that syncpt.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
