Am 26.05.21 um 15:12 schrieb Daniel Stone:
Hi,
On Wed, 26 May 2021 at 13:46, Christian König christian.koenig@amd.com 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.
Regards, Christian.
Cheers, Daniel