<html>
    <head>
      <base href="https://bugs.freedesktop.org/">
    </head>
    <body>
      <p>
        <div>
            <b><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#c13">Comment # 13</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 <span class="vcard"><a class="email" href="mailto:jajones@nvidia.com" title="James Jones <jajones@nvidia.com>"> <span class="fn">James Jones</span></a>
</span></b>
        <pre><span class="quote">> 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.</span >

I'm not sure where this import/export/import path comes from?  And no, these
are not BigGL only.  Can you point to the question you think implies this? 
Look at the extension's dependencies section, and the notes in the "functions
added" sections describing which apply to OpenGL Vs OpenGL ES only.  They're
explicitly designed for both GLES and GL.

<span class="quote">> 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?</span >

I think this is being over-thought.  For the out-fence, you've specified an
event that provides an FD to the client.  Instead, you'd probably have a
potentially "empty" wayland sync object thing (Let's please not try to make the
naming slant the debate) pre-associated with the surface at attach time, and
you could send an event when it was safe for the client to wait for it when
releasing as-is (implying it was non-empty when attached), or optionally
include an update to the object that associates a new FD with it (For the case
where it was previously empty, or just needs some new primitive to back it for
whatever reason).

<span class="quote">> 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.</span >

I hadn't imagined the client/server would claim support for less-than-ideal
primitives.  Similar to DRM-based buffers, you support sync-fd or you don't,
both as a compositor and a client.  Presumably this would only really be useful
with hardware-accelerated clients, and just like wl_drm stuff, you just keep
the client API binding (EGL, Vulkan WSI, etc.) and compositor in sync.  Apps
that don't reach down to do low-level buffer pushing themselves would be
oblivious, and the handful that hand-code this would support what they support.
 If sync fd gets embedded in enough hand-coded apps, it becomes a de-facto
standard for some market.  This hasn't actually been a problem with DRM buffers
thus far.  I'm just suggesting emulation of roughly that model for
synchronization as well.

<span class="quote">> 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.</span >

I'm really trying to avoid debating the merits of a Vulkan compositor (It was
just an example), but Vulkan direct-to-display has atomic modesetting (you can
atomically present multiple swapchains, share images between swapchains), and
display hotplug notification.

It would not be hard to write an extension that let's direct-to-display
swapchain images be shareable or client-allocated.  It's only hard to share
swapchain images in the general swapchain case, not for specific swapchain
backends/VkSurface types.  I may write this at some point anyway for other
reasons, but I've been waiting for an urgent use case to justify it.</pre>
        </div>
      </p>


      <hr>
      <span>You are receiving this mail because:</span>

      <ul>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>