On 2023-02-20 11:14, Rob Clark wrote: > On Mon, Feb 20, 2023 at 12:53 AM Pekka Paalanen <ppaalanen@xxxxxxxxx> wrote: >> >> On Sat, 18 Feb 2023 13:15:49 -0800 >> Rob Clark <robdclark@xxxxxxxxx> wrote: >> >>> From: Rob Clark <robdclark@xxxxxxxxxxxx> >>> >>> Allow userspace to use the EPOLLPRI/POLLPRI flag to indicate an urgent >>> wait (as opposed to a "housekeeping" wait to know when to cleanup after >>> some work has completed). Usermode components of GPU driver stacks >>> often poll() on fence fd's to know when it is safe to do things like >>> free or reuse a buffer, but they can also poll() on a fence fd when >>> waiting to read back results from the GPU. The EPOLLPRI/POLLPRI flag >>> lets the kernel differentiate these two cases. >>> >>> Signed-off-by: Rob Clark <robdclark@xxxxxxxxxxxx> >> >> Hi, >> >> where would the UAPI documentation of this go? >> It seems to be missing. > > Good question, I am not sure. The poll() man page has a description, > but my usage doesn't fit that _exactly_ (but OTOH the description is a > bit vague). > >> If a Wayland compositor is polling application fences to know which >> client buffer to use in its rendering, should the compositor poll with >> PRI or not? If a compositor polls with PRI, then all fences from all >> applications would always be PRI. Would that be harmful somehow or >> would it be beneficial? > > I think a compositor would rather use the deadline ioctl and then poll > without PRI. Otherwise you are giving an urgency signal to the fence > signaller which might not necessarily be needed. > > The places where I expect PRI to be useful is more in mesa (things > like glFinish(), readpix, and other similar sorts of blocking APIs) Hi, Hmm, but then user-space could do the opposite, namely, submit work as usual--never using the SET_DEADLINE ioctl, and then at the end, poll using (E)POLLPRI. That seems like a possible usage pattern, unintended--maybe, but possible. Do we want to discourage this? Wouldn't SET_DEADLINE be enough? I mean, one can call SET_DEADLINE with the current time, and then wouldn't that be equivalent to (E)POLLPRI? -- Regards, Luben