On 24/02/2023 09:26, Pekka Paalanen wrote:
On Thu, 23 Feb 2023 10:51:48 -0800
Rob Clark <robdclark@xxxxxxxxx> wrote:
On Thu, Feb 23, 2023 at 1:38 AM Pekka Paalanen <ppaalanen@xxxxxxxxx> wrote:
On Wed, 22 Feb 2023 07:37:26 -0800
Rob Clark <robdclark@xxxxxxxxx> wrote:
On Wed, Feb 22, 2023 at 1:49 AM Pekka Paalanen <ppaalanen@xxxxxxxxx> 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
