On Tue, 27 Nov 2018 14:57:07 +0000 Tomek Bury <tomek.b...@gmail.com> wrote:
> Hi Pekka, > > I'm just trying to figure out how to use this extension in a driver. > Without this extension the only option I have is to take a copy if each > wl_buffer on the compositor-side. I can't really do implicit sync so I'm > really happy with anything that allows for explicit sync. Ah, ok. So for both acquire and release fences: In your client-side implementation of EGL or Vulkan, in the case where you, the implementation, will be calling wl_surface.attach and wl_surface.commit, you will be the exclusive user of the explicit sync extension on that wl_surface. Go wild. :-) If the sync extension is not available from the compositor, then you have to do without on the client-side. In the server-side implementation, you don't need to do anything. The compositor will implement the explicit sync protocol and translate it into EGL etc. calls. I suppose in the server-side implementation you *cannot* do anything unless you can infer whether the compositor is actually supporting the explicit sync extension or not. > > Is it possible to have some variant of glTexImage2D wait for an EGLSync > > before it actually reads from the source? > I don't think so. The glTexImage2D mustn't hold onto any client pointers. > GLES3 buffers require mmap and CPU copy. Pixmaps are unsupported so EGL > images are the only remaining thing I can think of. > > > It would be enough for the fence spec to > > define what "opaque EGL buffer" is and then say that they also work in > > addition to zwp_linux_dmabuf buffers. > Yup, that works for me. > > > If a client wants to, it could start with wl_shm and CPU-rendered > > content, then switch to EGL managed surface, then shut down EGL and > > switch back to wl_shm all on the very same wl_surface, for example. > Hmmm, perhaps the set_acquire_fence() should be a buffer operation, not a > surface operation then? What you wrote means to me that the compositor > knows of every buffer the client created but doesn't know which buffer the > client is going to attach next. The earliest moment the compositor learns > about the buffer for the next frame is when the attach request reaches the > compositor. And that would be most likely after the attach/damage/commit > gets flushed at the end of frame by the client. But that's a battle for > another day. Correct, the compositor cannot know which buffer a client might attach to which surface at any time. There is absolutely no connection between which buffer goes with which surface, there has never been, and from protocol perspective clients could use the same buffer on multiple surfaces too. For technical reasons, we cannot add any wl_buffer requests or events. It would have to be done with another interface that takes the wl_buffer as an argument. I guess that would be possible, but I'm not sure what the difference would be. Your EGL implementation cannot expose the same interface as the compositor does for dmabufs. So you would have buffer-type specific interfaces for adding acquire fences. Maybe that's not actually a bad idea, given that the acquire fences are so closely related to buffer types. It would also allow to split the release event and fence into their own extension, to be shared across all buffer types including wl_shm. OTOH, it's more typing to implement. If we did the buffer-type specific explicit sync interfaces design, then a compositor itself would implement set_acquire_fence for dmabufs, and a compositor-side EGL implementation could implement set_acquire_fence for opaque EGL buffers which would be proprietary to the EGL implementation, but that is ok because the client-side of the same is too. In fact, you could have implemented an explicit sync extension for acquire fences inside your EGL implementation since day one. It is just the release fence side which probably wouldn't work out too well as hidden inside EGL. I suppose the compositor-side copy of buffers you mentioned is for the lack of release fences, not acquire fences? Thanks, pq
pgplIVBgjyt0p.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
