Am 27.05.21 um 12:33 schrieb Daniel Vetter:
On Wed, May 26, 2021 at 03:23:01PM +0200, Christian König wrote:
Am 26.05.21 um 15:12 schrieb Daniel Stone:
Hi,
On Wed, 26 May 2021 at 13:46, Christian König <christian.koenig@xxxxxxx> wrote:
Am 26.05.21 um 13:31 schrieb Daniel Stone:
How would we insert a syncobj+val into a resv though? Like, if we pass
an unmaterialised syncobj+val here to insert into the resv, then an
implicit-only media user (or KMS) goes to sync against the resv, what
happens?
Well this is for exporting, not importing. So we don't need to worry
about that.
It's just my thinking because the drm_syncobj is the backing object on
VkSemaphore implementations these days, isn't it?
Yeah, I can see that to an extent. But then binary vs. timeline
syncobjs are very different in use (which is unfortunate tbh), and
then we have an asymmetry between syncobj export & sync_file import.
You're right that we do want a syncobj though. This is probably not
practical due to smashing uAPI to bits, but if we could wind the clock
back a couple of years, I suspect the interface we want is that export
can either export a sync_file or a binary syncobj, and further that
binary syncobjs could transparently act as timeline semaphores by
mapping any value (either wait or signal) to the binary signal. In
hindsight, we should probably just never have had binary syncobj. Oh
well.
Well the later is the case IIRC. Don't ask me for the detail semantics, but
in general the drm_syncobj in timeline mode is compatible to the binary
mode.
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).
The other slight nudge is that drm_syncobj is a drm thing, so we'd first
need to lift it out into drivers/dma-buf (and hand-wave the DRM prefix
away) for it to be a non-awkward fit for dma-buf.
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 :-)
Yeah as discussed with a Jason already that drm_syncobj is DRM specific
is the killer argument here. So sync_file is fine with me.
Christian.
-Daniel
