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.
