On Thursday, May 27th, 2021 at 12:33 PM, Daniel Vetter <daniel@xxxxxxxx> 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. _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
