https://bugs.freedesktop.org/show_bug.cgi?id=98766
--- Comment #15 from Daniel Stone <dan...@fooishbar.org> ---
(In reply to James Jones from comment #13)
> > 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.
>
> 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.
My reading of support for semaphore usage in GL_EXT_external_objects is that it
requires GL_EXT_semaphore to be present; the spec asserts that
'GL_EXT_semaphore requires OpenGL 1.0' with (unlike the others) no mention of
GLES.
The 'question at the end' bit came from GL_EXT_external_objects_fd, which notes
that only opaque objects are supported for import, and that dma-fence FDs are
better handled through EGLSync. That implies that we can only exchange
semaphores when the client and compositor are running on the same device and
version-locked, which isn't really the direction I was hoping to go in.
I don't think 'import/export/import' actually applies; please disregard that.
> > 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?
>
> 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).
Right, I'm fine with a set of pre-created 'sync object things'. I'm just trying
to figure out if the act of making the sync-object-thing (specifically created
by client & compositor co-operating) be signalled by another sync-object thing
(maybe a fence, maybe a VkSemaphore, maybe something else) which was created by
the compositor, would have the same overhead you were talking about.
IOW, if passing back a dma-fence from the compositor's blit operation or the
KMS scanout operation is too high overhead, I'm not seeing why chaining that
fence into a client semaphore would be less overhead? It seems like they're
semantically the same from a low level; the only difference is the use of an
intermediate Wayland protocol object which should have no influence on the
lower levels of the display stack.
> > 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.
>
> 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.
I guess it's more of an interop thing. Right now we have dmabuf which works as
well as it can within the constraints, e.g. linear only when sharing between
different vendors. One of the explicit goals of the dmabuf extension, and of
this one as well, was to extend that same sharing model to fences. Rather than
just plumbing opaque FDs between version-locked drivers for the same device, it
aimed to extend functionality to multiple disjoint GPUs, display controllers,
media encode/decode engines, and so on.
That being said, I don't see a problem with specifically adding a type enum for
anything which might come up in the future.
(In reply to Tomek Bury from comment #14)
> I was wandering how (if?) are you going to implement the new buffer release
> mechanism in Weston GL renderer.
>
> Where do you get the dma_fence object from? If I understand correctly, the
> dma_fence has to be signalled by the GL driver after the last glDraw
> involving wl_buffer has finished executing on the GPU.
>
> I checked quickly GL and EGL extensions but I can't see anything that would
> export dma_fence object the compositor could return with the wl_buffer.
We can create an EGLSync object, request that it be signalled when the most
recently submitted command has fully retired, and then use the Android
native_fence_fd extension to get a dma-fence from that. The compositor then
keeps around the fence used for its last GL composition per output (and for the
last completed KMS scene), and we can pass whichever is applicable back to the
client as a release fence. (Or embed it within another kind of sync object.)
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
wayland-bugs mailing list
wayland-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-bugs
