Re: [Intel-gfx] [PATCH 5/7] dma-buf: Add an API for exporting sync files (v11)

From: Daniel Vetter <daniel@ffwll.ch>
To: "Christian König" <christian.koenig@amd.com>
Cc: Simon Ser <contact@emersion.fr>,
	intel-gfx <intel-gfx@lists.freedesktop.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	Sumit Semwal <sumit.semwal@linaro.org>
Subject: Re: [Intel-gfx] [PATCH 5/7] dma-buf: Add an API for exporting sync files (v11)
Date: Thu, 27 May 2021 12:33:52 +0200	[thread overview]
Message-ID: <YK91kB0ikqxurHN1@phenom.ffwll.local> (raw)
In-Reply-To: <a9de44fc-aa7c-60d7-d7ed-2229d41fb306@amd.com>

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@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.

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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx