<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - We need fences support in Wayland compositors" href="https://bugs.freedesktop.org/show_bug.cgi?id=98766#c12">Comment # 12</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - We need fences support in Wayland compositors" href="https://bugs.freedesktop.org/show_bug.cgi?id=98766">bug 98766</a> from <a class="email" href="mailto:daniel@fooishbar.org" title="Daniel Stone <daniel@fooishbar.org>"> Daniel Stone</a> <pre>(In reply to James Jones from <a href="show_bug.cgi?id=98766#c9">comment #9</a>, and also <a href="show_bug.cgi?id=98766#c11">comment #11</a>) > 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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>