On 23/05/2019 14:59, Chris Wilson wrote:
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
Right,
I see this changes the behavior for existing drm_syncobjs, which was not
intended.
For timeline drm-syncobjs, we're aware this will block and might fail if
the fence doesn't materialize.
The Vulkan spec doesn't give a specific amount of time of which the
submit fails, apart from it being non zero.
Will fix, thanks a lot for pointing this out.
-Lionel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
