Am 12.10.2018 um 09:23 schrieb Pekka Paalanen: > 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. To summarize what information should be provided by the driver stack to make applications happy: 1. The minimum time a frame can be displayed, in other words the maximum frame rate. 2. The maximum time a frame can be displayed, in other words the minimum frame rate. 3. How much change of frame timing is allowed between frames to avoid luminescence flickering. Number 1 and 2 can also be used to signal the availability of VRR to applications, e.g. if they are identical we don't support VRR at all. Regards, Christian. > > 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 _______________________________________________ amd-gfx mailing list amd-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/amd-gfx
