On Wed, 10 Oct 2018 09:35:50 -0400 "Kazlauskas, Nicholas" <nicholas.kazlauskas@xxxxxxx> wrote: > The patches I've put out target this use case mostly because of the > benefit for a relatively simple interface. VRR can and has been used in > more ways that this, however. > > An example usecase that differs from this would actually be video > playback. The monitor's refresh rate likely doesn't align with the video > content rate. An API that exposes direct control over VRR (like the > range, refresh duration, presentation timestamp) could allow the > application to specify the content rate directly to deliver a smoother > playback experience. For example, if you had a 24fps video and the VRR > range was 40-60Hz you could target 48Hz via some API here. The way that has been discussed to be implemented is that DRM page flips would carry a target timestamp, which the driver will then meet as good as it can. It is better to define an absolute target timestamp than a frequency, because a timestamp can be used to synchronize with audio and more. Mario Kleiner can tell you all about scientific use cases that require accurate display timing, not just frequency. A timestamp will naturally lend itself to arbitrary on-demand screen updates as well. However, userspace still needs to know if the target timestamp it is contemplating on could realistically be met, so that e.g. a video player can choose between showing video frames as is vs. needing to interpolate for the presentation times it actually can achieve. I suppose we agree on the above. Btw. would a video player even need explicit controls if it knows the display will adapt to the player's refresh rate? It could just use the original video rate and from what I understood, the display will soon end up refreshing at exactly that rate. The player can still use the realized page flip timestamps to synchronize with audio, since it can assume the refresh rate is stable and can predict the next few flips. But, this would only work if the video player knows that VRR will adapt to its rate. While we are talking about predictability of page flips, Weston is already relying on a prediction to reduce the desktop latency to screen. However, it should be possible to modify Weston to implement the kind of VRR support for fullscreen exclusive windows like you are proposing just fine. Just like the X11 window property you mentioned for marking windows as eligible for VRR in Xorg, Wayland will need a similar protocol extension. I'm happy to see work being done for VRR. Thanks, pq
Attachment:
pgpHoEsWIVAtn.pgp
Description: OpenPGP digital signature
_______________________________________________ amd-gfx mailing list amd-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/amd-gfx
