On Tue, 16 Aug 2016 10:46:13 +0900 Michel Dänzer <michel@xxxxxxxxxxx> 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/presentation-time 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.
Attachment:
pgp67D4mgshRG.pgp
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
