[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 #12 from Daniel Stone <daniel at fooishbar.org> ---
(In reply to James Jones from comment #9, and also comment #11)
> 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.
> 
> 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.

Sure, but the overhead of importing a semaphore into a Vulkan context,
exporting that as an opaque FD, importing that into GL and then using it, seems
higher than just importing a fence? Those extensions are also only synced for
big GL: there's a question at the end concluding that there's no use for
EGL/ES, since you can already import dma-fence FDs into EGLSync objects.

In a pure-Vulkan world, I can see the use for the equivalent of in-fences (from
the compositor's PoV, what would be the signal semaphore of vkQueuePresentKHR's
operation) to associate with wl_surface_attach using sync objects; it seems
pretty obvious that the client would create it early (unsignaled), queue one
signaling operation, and then the compositor would queue at least one wait
operation.

But for the equivalent of out-fences (semaphore parameter to
vkAcquireNextImageKHR, associated with wl_buffer_release), not so much? The
compositor may queue at least one operation which would be the semaphore for
the image inside vkAcquireNextImage. This might be an EGLSync/dma-fence
signaling after the last EGL/GLES operation sourcing from the buffer, or a
dma-fence from KMS, or a VkSemaphore from Vulkan composition. It looks like
we'd need new API for the kernel, which would signal a syncobj when a
particular collection of dma-fences had all signaled.

The compositor can't just take the client's wl_vk_semaphore object and instruct
all operations using the buffer to signal the semaphore: there may be more than
one (e.g. scanout + media encode), and the compositor doesn't necessarily know
when queuing those operations that they will be the last operations queued on
that buffer either. I assume that API of delayed fence -> syncobj signal
chaining would still be prohibitively expensive for you though?

> -Explicitly name the type of the FD being registered.  If dma-fence/sync FD
> is the only type available in rev1, that's fine, but it's an easily
> extensible API.

It sounds like the protocol would need to encode a preference: 'I can take
dma-fences but it's going to reduce your framerate' vs. 'I can take syncobjs
but I'm just going to export them straight to fences'. And I have no idea which
side should 'win' if the compositor prefers one synchronisation model and the
client prefers another.

> 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. 

To be honest, it's not really clear to me at the moment what a Vulkan
composition model would look like, so it's hard to say. For example, as far as
I can tell there's no way to directly present VkImages with VK_KHR_display,
only the result of the compositor's own Vulkan rendering, which means we can't
usefully use overlay planes in a compositor yet.

Also, without either a totally omniscient planner ('here's how to recognise
your scene graph and I guarantee this will work'), or the brute-force model we
use with atomic KMS where we just throw potential configurations at the wall in
a test-only mode until it finally sticks, we can't really hoist things into
overlays. There's also the need for atomic modesetting, hotplug notifications,
and so forth.

Maybe standing up a demo of how a VK_KHR_display-based compositor could look
would be enlightening.

-- 
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/c0a2847b/attachment-0001.html>