On Thu, Feb 23, 2023 at 1:38 AM Pekka Paalanen ppaalanen@gmail.com wrote:
On Wed, 22 Feb 2023 07:37:26 -0800 Rob Clark robdclark@gmail.com wrote:
On Wed, Feb 22, 2023 at 1:49 AM Pekka Paalanen ppaalanen@gmail.com wrote:
On Tue, 21 Feb 2023 09:53:56 -0800 Rob Clark robdclark@gmail.com wrote:
On Tue, Feb 21, 2023 at 8:48 AM Luben Tuikov luben.tuikov@amd.com wrote:
On 2023-02-20 11:14, Rob Clark wrote:
On Mon, Feb 20, 2023 at 12:53 AM Pekka Paalanen ppaalanen@gmail.com wrote: > > On Sat, 18 Feb 2023 13:15:49 -0800 > Rob Clark robdclark@gmail.com wrote: > >> From: Rob Clark robdclark@chromium.org >> >> 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@chromium.org > > 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.
Besides, a Wayland compositor does not necessary need to add the fd to its main event loop for poll. It could just SET_DEADLINE, and then when it renders simply check if the fence passed or not already. Not polling means the compositor does not need to wake up at the moment the fence signals to just record a flag.
poll(POLLPRI) isn't intended for wayland.. but is a thing I want in mesa for fence waits. I _could_ use SET_DEADLINE but it is two syscalls and correspondingly more code ;-)
But is it actually beneficial? "More code" seems quite irrelevant.
Would there be a hundred or more of those per frame? Or would it be always limited to one or two? Or totally depend on what the application is doing? Is it a significant impact?
In general, any time the CPU is waiting on the GPU, you have already lost. So I don't think the extra syscall is too much of a problem. Just less convenient.
On another matter, if the application uses SET_DEADLINE with one timestamp, and the compositor uses SET_DEADLINE on the same thing with another timestamp, what should happen?
The expectation is that many deadline hints can be set on a fence. The fence signaller should track the soonest deadline.
You need to document that as UAPI, since it is observable to userspace. It would be bad if drivers or subsystems would differ in behaviour.
It is in the end a hint. It is about giving the driver more information so that it can make better choices. But the driver is even free to ignore it. So maybe "expectation" is too strong of a word. Rather, any other behavior doesn't really make sense. But it could end up being dictated by how the hw and/or fw works.
BR, -R
Thanks, pq