On Tue, 16 Aug 2016 10:46:13 +0900 Michel Dänzer michel@daenzer.net wrote:
On 16/08/16 10:32 AM, Mario Kleiner wrote:
Cc'ing Daniel Stone and Pekka Paalanen, because this relates to wayland.
Wrt. having a new pageflip parameter struct, i wonder if it wouldn't make sense to then already prepare some space in it for specifying an absolute target time, e.g., in u64 microseconds? Or make this part of the atomic pageflip framework?
I feel like this is too much hassle for the DRM_IOCTL_MODE_PAGE_FLIP ioctl, probably makes sense to only deal with this in the atomic API.
In Wayland we now have the presentation_feedback extension (maybe it got a new name?), which is great to get feedback when and how presentation was completed, essentially the equivalent of X11's GLX_INTEL_swap_events
- some useful extra info / the feedback half of OML_sync_control.
That was supposed to be complemented by a presentation_queue extension which would provide the other half of OML_sync_control, the part where an app can tell the compositor when and how to present surface updates. I remember that a year ago inclusion of that extension was blocked on some other more urgent important blocker bugs? Did this make progress?
Hi,
sorry, I'm pretty poor at following dri-devel@.
Yeah, the Wayland extension for queueing frames to be presented at specific times has not been going anywhere for a long time. IIRC the blockers have since been resolved, now it would need dusting off and seeing how it interacts with those protocol additions. I wasn't too happy with the design at the time, either, because of the question of which state to queue and which not.
Nowadays presentation_feedback lives in https://cgit.freedesktop.org/wayland/wayland-protocols/tree/stable/presentat... and has been declared stable.
For timing sensitive applications such an extension is even more important in a wayland world than under X11. On X11 most desktops allow unredirecting fullscreen windows, so an app can drive the flip timing rather direct. At least on Weston as i remember it from my last tests a year ago, that wasn't possible, and an app that doesn't want to present at each video refresh, but at specific target times had to guess what the specific compositors scheduling strategy might be and then "play games" wrt. to timing surface commit's to trick the compositor into sort of doing the right thing - very fragile.
Anyway, the idea of presentation_queue was to specify the requested time of presentation as actual time, not as a target vblank count. This because applications that care about precise presentation timing, like my kind of neuroscience/medical visual stimulation software, or also video players, or e.g., at least the VDPAU video presentation api "think" in absolute time, not in refresh cycles. Also a target vblank count for presentation is less meaningful than a target time for things like variable framerate displays/adaptive sync, or displays which don't have a classic refresh cycle at all. It might also be useful if one thinks about something like VR compositors, where precise timing control could help for some of the tricks ("time warping" iirc?) they use to hide/cope with latency from head tracking -> display.
It would be nice if the kernel could help compositors which would implement presentation_queue or similar to be robust/precise in face of future stuff like Freesync, or of added delays due to Optimus/Prime hybrid-graphics setups. If we wanted to synchronize presentation of multiple displays in a Freesync type display setup, absolute target times could also be helpful.
I agree with all of this though.
I'm very happy to hear the idea has support!
Thanks, pq
I'd like to add that the X11 Present extension specification already includes support for specifying a target time instead of a target refresh cycle. This isn't implemented yet though, but it should be relatively straightforward to implement using the kind of kernel API you describe.