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