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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

Cheers,
Daniel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux