On Wed, Jul 12, 2017 at 9:45 AM, Christian König <deathsimple@xxxxxxxxxxx> 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.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
