> That's not true; you can post back a sync token every time the client > buffer is used by the compositor. Technically, yes but it's very cumbersome and invasive to the point where it becomes impractical. Explicit sync is much cleaner solution. > For instance, Mesa adds the `wl_drm` extension, which is > used for bidirectional communication between the EGL implementations > in the client and compositor address spaces, without modifying either. Broadcom driver adds "wl_nexus" extension which servers similar purpose for both EGL and Vulkan WSI > OK. As it stands, everyone else has the kernel mechanism (e.g. via > dmabuf resv), so in this case if you are reinventing the underlying > platform in a proprietary stack, you get to solve the same problems > yourselves. That's an important point. In the explicit synchronisation scenario the sync token is passed with the buffer. It becomes irrelevant where the token originated from, as long as it's a commonly used type of token, i.e. dma_fence in kernel space or sync_fd in user space. That allows for greater flexibility and works with and without dma reservation objects. Cheers, Tomek _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
