[Wayland-bugs] [Bug 98766] We need fences support in Wayland compositors

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=98766

--- Comment #10 from Jason Ekstrand <jason at jlekstrand.net> ---
(In reply to James Jones from comment #9)
> Yes, the overhead is in the ioctls needed to instantiate a sync object into
> a usermode driver or another command queue in our kernel driver.  It's
> relatively expensive on NV hardware when not using a global GPU virtual
> address space.

I agree that there are some ways in which the sync file ioctls could be more
efficient.  Our driver does N-1 sync file merge operations ioctls on each
submit which isn't great especially if the compositor has dozens of clients
each handing it sync files.  If we had a multi-merge ioctl, maybe a bunch of
this overhead would go away.

> There's an API to import general Vulkan sync primitives (Including dma
> fences/sync FDs, but also persistent-style Vulkan semaphores) directly to GL
> via the GL/Vulkan interop extensions which I believe Mesa supports.

Some mesa drivers support it but not all.

In general, we seem to be getting back to the same discussion as EGLStreams
about whether we build Wayland on top of Khronos APIs or Linux APIs.  Even if
both Vulkan and GL support said extension, what about KMS?  What about some
video encode API?  The advantage of sync_file is that it's supported everywhere
and allows multiple components from multiple vendors to synchronize between
each other.  Fun fact: at one point in time, there was a KMS-only (no 3D API
involved) Weston back-end for the raspberry pi.

> KMS may need sync FDs, but not all compositing happens in KMS.  There's also
> the hypothetical-at-this-point Vulkan-only compositor implementation that
> doesn't use KMS.  Having Weston/Mesa/Mutter/etc. support only KMS and even
> only sync FDs/dma-fences is the current design norm, but baking that
> assumption in the protocol is another thing.

We have to bake some set of assumptions in.  We can bake in Linux/Android
assumptions around sync_file or we can bake in Khronos API assumptions around
GL, Vulkan, EGL, etc.  The question isn't if we bake in assumptions, it's which
assumptions we bake in.  When we already have fairly well standardized APIs for
modesetting and cross-component synchronization, why is the answer to keep
wrapping them in more and more layers of Khronos APIs until EGL rules the
world?

By the way, I'm not arguing that you don't have a real problem which really
needs solving.  I'm well aware of the problem and it badly needs solving!  I
just question the solution of adding more EGL (or Vulkan WSI).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-bugs/attachments/20180604/41d73b87/attachment.html>