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 :-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
