[repost] drm sync objects cleaned up
airlied at gmail.com
Tue Apr 18 23:54:35 UTC 2017
On 19 April 2017 at 07:55, Jason Ekstrand <jason at jlekstrand.net> wrote:
> A few thoughts (from the anv perspective) that I put on IRC but may be
> better in a mail. In no particular order:
> 1. Having the fd exported from a syncobj be a valid sync_file seems like a
> fairly pointless feature to me. If we can make things more sane by throwing
> that out, I'm all for it.
> 2. As far as sync_file interactions go, I think the far more useful thing
> would be for you to be able to export a sync_file from a syncobj which would
> create a sync_file that waits on the last submitted signal operation on the
> syncobj and then have a way of creating a temporary syncobj that has the
> fence from a sync_file. Not sure how this would interact with future
> fences. If we can't figure it out, let's just forget it and not have any
> defined interaction.
> 3. I'd like to also be able to use syncobj for implementing VkFence
> sharing. Really, all this means is a drm_syncobj_wait ioctl. Yes, with the
> current sync_file stuff, you could turn it into a sync_file and poll but I'd
> rather not burn the file descriptors.
Okay this seems like a good goal.
> 4. It would be a neat trick if drm_syncobj_wait could take a list of
> syncobjs and wait on one or all of them as requested by the user. That
> said, this would be an optimization at best and I'm fine with waiting on
> them one at a time.
> 5. I'd like to better define what happens when someone tries to wait twice.
> I'm a big fan of the semantics of dma-buf dependencies: Each wait operation
> waits on the most recently queued signal operation. That seems better to me
> than waiting causing an implicit reset and waiting twice being invalid.
> Among other things, it means that we don't have to worry bout the semantics
> of exactly how execbuf fails if you ask it to wait on the same sync file
> twice. That said, it can be anything we want, I just want it to be
I've been thinking about this, and I think you are right, the fact that sems
are 1:1 signal:waiter is probably not necessary to enforce in kernel space,
if we don't replace the backing fence on a sem with NULL after waiting, I don't
think it should break a working userspace, and it will just make things simpler,
I can't see any real way a broken userspace can do much damage here either.
More information about the dri-devel