[repost] drm sync objects cleaned up

[Dave Airlie]

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.

And this.

>
>  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
> well-defined.

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.

Dave.