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?
> 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'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.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
