On Wed, Jul 12, 2017 at 9:45 AM, Christian König <deathsimple at vodafone.de> wrote: > Am 12.07.2017 um 17:53 schrieb Jason Ekstrand: > > [SNIP] > > >> Is that easier than just waiting in the kernel, I'm not sure how >> optimised we need this path to be. >> > > I don't think so. I think it's more-or-less the same code regardless of > how it's done. The advantage of doing it in the kernel is that it's > standardized (we don't have to both go write that userspace code) and it > doesn't have the problems stated above. > > > Ok, I'm convinced. The next price question is then how do we do it? > > I mean writing an IOCTL to wait for a fence to appear is simple, but do we > also need to wait for a fence to change? > I don't think so. Taking a page from the Vulkan book, I think the "right" thing to do would be to have a reset ioctl that simply deletes the dma_fence and replaces it with NULL. Then the only behavior you care about is "wait for a fence to appear". The usage pattern becomes: 1) Submit work to signal the syncobj 2) Wait on the syncobj (this may happen before the submit) 3) Once everyone is done waiting, reset the syncobj If someone does a wait on a stale syncobj that has completed and not yet been reset, they return immediately. Yes, there is a possible race between 2 and 3, especially if 2 is waiting on multiple syncobjs. Ideally, we'd make it so that a reset in the middle of someone else's wait wouldn't cause them to wait until that syncobj gets triggerd a second time. However, I don't think it's a deal-breaker as any client that sets the "wait for submit" flag should know that it's liable to wait forever and set a timeout. -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20170712/c0251bd3/attachment.html>
