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

[Pekka Paalanen]

On Fri, 5 Oct 2018 12:21:20 -0400
"Kazlauskas, Nicholas" <nicholas.kazlauskas at amd.com> wrote:

> On 10/05/2018 04:10 AM, Pekka Paalanen wrote:
> > Hi,
> > 
> > I have a somewhat of my own view on what would be involved with VRR,
> > and I'd like to hear what you think of it. Comments inline.
> > 
> > 
> > On Tue, 25 Sep 2018 09:51:37 -0400
> > "Kazlauskas, Nicholas" <nicholas.kazlauskas at amd.com> wrote:
> >   
> >> On 09/24/2018 04:26 PM, Ville Syrjälä wrote:  
> >>> On Mon, Sep 24, 2018 at 03:06:02PM -0400, Kazlauskas, Nicholas wrote:  
> >>>> On 09/24/2018 02:38 PM, Ville Syrjälä wrote:  
> >>>>> On Mon, Sep 24, 2018 at 02:15:36PM -0400, Nicholas Kazlauskas wrote:  
> >>>>>> Variable refresh rate algorithms have typically been enabled only
> >>>>>> when the display is covered by a single source of content.
> >>>>>>
> >>>>>> This patch introduces a new default CRTC property that helps
> >>>>>> hint to the driver when the CRTC composition is suitable for variable
> >>>>>> refresh rate algorithms. Userspace can set this property dynamically
> >>>>>> as the composition changes.
> >>>>>>
> >>>>>> Whether the variable refresh rate algorithms are active will still
> >>>>>> depend on the CRTC being suitable and the connector being capable
> >>>>>> and enabled by the user for variable refresh rate support.
> >>>>>>
> >>>>>> It is worth noting that while the property is atomic it isn't filtered
> >>>>>> from legacy userspace queries. This allows for Xorg userspace drivers
> >>>>>> to implement support in non-atomic setups.
> >>>>>>
> >>>>>> Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas at amd.com>  

...

> >> Whenever I mentioned variable refresh "features", what I really meant
> >> was operating in one of two modes:
> >>
> >> (1) Letting the driver and hardware adjust refresh automatically based
> >> on the flip rate on a CRTC from a single application
> >>
> >> (2) Setting a fixed frame duration based on the flip rate on a CRTC from
> >> a single application  
> > 
> > I wonder if that's too much magic in the kernel... what would be wrong
> > with simply flipping ASAP when VRR is active?
> > 
> > How will userspace be able to predict coming flip opportunities if the
> > kernel does so much magic?  
> 
> The kernel driver doesn't need to do much more than let the hardware 
> know the variable refresh range. The "magic" is performed by hardware.
> 
> Most games would like to render as fast as possible to deliver a more 
> responsive and smoother image to the user. Many of these are also 
> resource intensive and won't always be able to render at the fixed 
> refresh rate of the panel (especially for higher refresh rates like 
> 144Hz). The user will experience stuttering if the game takes too long 
> to render and misses the vblank window for the flip.
> 
> Dynamic VRR adjustment can resolve this problem. The hardware can lower 
> the refresh rate and increase the vblank window in response to this so 
> the user doesn't experience stuttering (or latency).
> 
> Userspace shouldn't predict anything.

...

> >>>> The reasoning for the split is because not all content is suitable for
> >>>> variable refresh. Desktop environments, web browsers, etc only typically
> >>>> flip when needed - which will result in display flickering.  
> > 
> > Flickering? What do you mean?  
> 
> This is a property of how panels work.
> 
> The luminance for a panel will vary based on how long the vrefresh is. 
> Since the vrefresh length is changing as part of VRR you're more likely 
> to notice the difference in luminance the bigger the difference is.
> 
> The difference will be largest when switching from the min vrefresh to 
> the max vrefresh duration.
> 
> Large differences can occur for applications that render on demand like 
> a web browser (and why you wouldn't want VRR enabled for those). The 
> hardware would continuously wait for a flip that isn't coming. Then if 
> the user moves their cursor or the page updates it's going to happen 
> "randomly" in that window and the hardware will adjust to that.

Hi Nicholas,

it seems I have very much mis-guessed what VRR aims to achieve, and the
effect on luminance sounds horrible.

People have worked for years to make display timings more explicit,
giving better control and predictability over them. It sounds like VRR
is not an improvement that allows new smarter software to take control
of timings even better. Instead, VRR seems to be a step backwards,
introducing more uncertainty into the timings. The expectation of a
fixed unknown refresh rate must be built into software for the software
to work reasonably while VRR is active.

From your comments I understood that the VRR hardware still very much
depends on a consistent refresh rate, except the hardware (not the
software!) can additionally slew the refresh rate over time. Abrupt
changes in frame timings must still be prevented, but I wasn't quite
sure if you meant the hardware will do that or if the software must do
that, since you are worried about on-demand updating applications
causing flickering.

Hence, VRR looks like a band-aid for old and simple applications that
use brute force (more fps, maximize the work load) in an attempt to
make things smoother and to reduce latency. There are lots of such
applications, so VRR has its place. It is my mistake of assuming it
could do more. Yes, I am disappointed to realize this.

I believe that future display servers and applications that actually
care about display timings will just opt out from VRR to gain better
predictability.

I also believe that you will need to blacklist applications like video
players whose developers have spent a great deal of effort in making a
smart scheduling algorithm for fixed rate display. I assume that a
smart sheduling algorithm that is based on prediciting the next display
time instant will interact poorly with VRR. A video player will need to
know if it is getting fixed rate or VRR to choose the appropriate
timing algorithm - wherther it needs to adapt to the display rate or
will the display rate adapt to it.

In summary, VRR is only good for exactly the use cases you listed, and
for other uses it can be harmful, just like you said.

Given the above, I think we are now very much on the same page about
what the KMS UABI should look like.


> Most compositors function well under this stack. It will vary
> depending on compositor support for window unredirection to let the
> window flip via the Present extension. Mutter handles this without
> any configuration and kwin can be configured to work with these
> patches. Compton can be configured to support unredirection as well.

You are thinking about the applications. What about the compositor
itself? Is the COW not hitting the Present direct scanout path,
triggering VRR, when what is actually showing is the desktop with
on-demand randomly updating windows?

> These (among others) are covered as part of the blacklist for the
> mesa patches. They do need to be explicitly excluded.

Right, you blacklist all compositing managers to prevent them from
regressing. That feels a bit ugly to me, needing exceptions to not
regress things, but maybe that's business as usual in Mesa?

Fortunately that problem with compositing managers won't exist with
Wayland.

In any case, there must also be a way for an application to explicitly
say if it supports VRR or not and to know if it gets VRR or not. Are
there no EGL or Vulkan extensions for that?


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20181010/daa56530/attachment.sig>