Re: [PATCH v2 2/3] drm: Add variable refresh property to DRM CRTC

[Pekka Paalanen <ppaalanen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

[-- Attachment #1.1: Type: text/plain, Size: 2648 bytes --]

On Wed, 10 Oct 2018 09:35:50 -0400
"Kazlauskas, Nicholas" <nicholas.kazlauskas-5C7GfCeVMHo@public.gmane.org> 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 #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx