On 2023-02-22 04:49, Pekka Paalanen wrote: > On Tue, 21 Feb 2023 09:53:56 -0800 > Rob Clark <robdclark@xxxxxxxxx> wrote: > >> On Tue, Feb 21, 2023 at 8:48 AM Luben Tuikov <luben.tuikov@xxxxxxx> wrote: >>> >>> 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? >> >> Yeah, (E)POLLPRI isn't strictly needed if we have SET_DEADLINE. It is >> slightly more convenient if you want an immediate deadline (single >> syscall instead of two), but not strictly needed. OTOH it piggy-backs >> on existing UABI. > > In that case, I would be conservative, and not add the POLLPRI > semantics. An UAPI addition that is not strictly needed and somewhat > unclear if it violates any design principles is best not done, until it > is proven to be beneficial. That is my sentiment as well. Moreover, on hard-realtime systems, one would want to set the deadline at the outset and not at poll time. -- Regards, Luben
