Messages in this thread | | | Date | Fri, 24 Feb 2023 09:41:46 +0000 | Subject | Re: [PATCH v4 06/14] dma-buf/sync_file: Support (E)POLLPRI | From | Tvrtko Ursulin <> |
| |
On 24/02/2023 09:26, Pekka Paalanen wrote: > On Thu, 23 Feb 2023 10:51:48 -0800 > Rob Clark <robdclark@gmail.com> wrote: > >> 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 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. > > It will stop being a hint once it has been implemented and used in the > wild long enough. The kernel userspace regression rules make sure of > that.
Yeah, tricky and maybe a gray area in this case. I think we eluded elsewhere in the thread that renaming the thing might be an option.
So maybe instead of deadline, which is a very strong word, use something along the lines of "present time hint", or "signalled time hint"? Maybe reads clumsy. Just throwing some ideas for a start.
Regards,
Tvrtko
> See the topic of implementing triple-buffering in Mutter in order to > put more work to the GPU in order to have the GPU ramp up clocks in > order to not miss rendering deadlines. I don't think that patch set has > landed in Mutter upstream, but I hear distributions in downstream are > already carrying it. > > https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1383 > https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1441 > > Granted, GPU clocks are just one side of that story it seems, and > triple-buffering may have other benefits. > > If SET_DEADLINE would fix that problem without triple-buffering, it is > definitely userspace observable, expected and eventually required > behaviour. > > > Thanks, > pq
| |