Am 22.09.2016 um 16:11 schrieb Christian König: > Am 22.09.2016 um 13:16 schrieb Gustavo Padovan: >> 2016-09-22 Christian König <christian.koenig at amd.com>: >> >>> Dropping the rest of the patch, cause that really doesn't make sense >>> any >>> more. >>> >>> Am 22.09.2016 um 12:40 schrieb Gustavo Padovan: >>>>> E.g. for example it is illegal to do something like >>>>>> "while(!fence_is_signaled(f)) sleep();" without enabling >>>>>> signaling before >>>>>> doing this. >>>>>> >>>>>> Could just be a misunderstanding, but the comments on your patch >>>>>> actually >>>>>> sounds a bit like somebody is trying to do exactly that. >>>> I think the usecase in mind here is poll(fd, timeout=0) >>> Exactly as I feared. Even if userspace polls with timeout=0 you >>> still need >>> to call enable_signaling(). >>> >>> Otherwise you can run into a situation where userspace only uses >>> timeout=0 >>> and so never activates the signaling check in the driver. >>> >>> This would in turn result in an endless loop on implementations >>> where the >>> driver never signals fences on their own. >> Polling is optional, userspace may never call it. And DRM/KMS or GPU >> drivers will be doing fence_wait() themselves so signaling is enabled at >> some point. > > No they won't. We have an use case where we clearly want to avoid that > as much as possible because and so the driver never calls > enable_signaling() on it's own.
Sorry hitting send to soon. That should read "because of the extreme overhead". Christian. > > Exposing this poll function to userspace without enabling signaling is > a clear NAK from my side. > > Christian. > >> >> Gustavo >> >