On Thursday, May 27th, 2021 at 12:33 PM, Daniel Vetter daniel@ffwll.ch wrote:
The sync_file is also import/exportable to a certain drm_syncobj timeline point (or as binary signal). So no big deal, we are all compatible here :) I just thought that it might be more appropriate to return a drm_syncobj directly instead of a sync_file.
I think another big potential user for this is a vk-based compositor which needs to interact/support implicit synced clients. And compositor world I think is right now still more sync_file (because that's where we started with atomic kms ioctl).
Yeah, right now compositors can only deal with sync_file. I have a Vulkan pull request for wlroots [1] that would benefit from this, I think.
Also it seems like drm_syncobj isn't necessarily going to be the the sync primitive that ends them all with all that user-space fence discussion, so long-term I guess we'll need a conversion anyways.
[1]: https://github.com/swaywm/wlroots/pull/2771
Plus you can convert them to the other form anyway, so really doesn't matter much. But for the above reasons I'm leaning slightly towards sync_file. Except if compositor folks tell me I'm a fool and why :-)
sync_file is fine from my PoV.