[Mesa-dev] [PATCH v5 0/5] Mesa integration for DRM variable refresh rate API

[Nicholas Kazlauskas]

These patches are part of a proposed new interface for supporting variable refresh rate via DRM properties.

It adds a new option for supporting adaptive sync to drirc along with the implementation of notifying the window manager/DDX of the support via a window property.

The option is enabled by default for radeonsi so included is an initial blacklist of applications that shouldn't have this option enabled.

In order to catch some of these applications a patch to the program name detection was needed to ignore arguments for some Linux applications.

=== Changes from v4 ===

* "adaptive_sync_enable" shortened to now "adaptive_sync"
* Reordered patches for more logical bisection
* Replaced suspicious pointer arithmetic in get program name path to better clarify intent
* Errors are now discarded when setting/destroying variable refresh property
* Updated formatting in dri3 loader patch

=== Changes from v3 ===

* Blacklist updated to include more desktop environments
* Variable refresh property is now deleted when adaptive_sync_enable is false during loader init - this should resolve a potential issue with reusing windows with blacklisted applications.

=== Changes from v2 ===

* A patch to add the option to the drirc was missing from the v2 patchset. That patch is now included in v3.
* The method to fix program name detection for Chromium based applications for the drirc was modified to not break detection for 32-bit/64-bit WINE applications.

=== Adaptive sync and variable refresh rate ===

Adaptive sync is part of the DisplayPort specification and allows for graphics adapters to drive displays with varying frame timings.

Variable refresh rate (VRR) is essentially the same, but defined for HDMI.

=== Use cases for variable refresh rate ===

Variable frame (flip) timings don't align well with fixed refresh rate displays. This results in stuttering, tearing and/or input lag. By adjusting the display refresh rate dynamically these issues can be reduced or eliminated.

However, not all content is suitable for dynamic refresh adaptation. The user may experience "flickering" from differences in panel luminance at different refresh rates. Content that flips at an infrequent rate or demand is more likely to cause large changes in refresh rate that result in flickering.

Userland needs a way to let the driver know when the screen content is suitable for variable refresh rates.

=== DRM API to support variable refresh rates ===

This patch introduces a new API via atomic properties on the DRM connector and CRTC.

The drm_connector has one new optional boolean property:

* bool vrr_capable - set by the driver if the hardware is capable of supporting variable refresh rates

The drm_crtc has one new default boolean property:

* bool vrr_enabled - set by userspace indicating that variable refresh rate should be enabled

== Overview for DRM driver developers ===

Driver developers can attach the "vrr_capable" property by calling drm_connector_attach_vrr_capable_property(). This should be done on connectors that could be capable of supporting variable refresh rates (such as DP or HDMI).

The "vrr_capable" can then be updated accordingly by calling drm_connector_set_vrr_capable_property().

The "vrr_enabled" property can be checked from the drm_crtc_state object.

=== Overview for Userland developers ==

The "vrr_enabled" property on the CRTC should be set to true when the CRTC is suitable for variable refresh rates.

To demonstrate the suitability of the API for variable refresh and dynamic adaptation there are additional patches using this API that implement adaptive variable refresh across kernel and userland projects:

* DRM (dri-devel)
* amdgpu DRM kernel driver (amd-gfx)
* xf86-video-amdgpu (https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu)
* mesa (mesa-dev)

These patches enable adaptive variable refresh on X for AMD hardware. Support for variable refresh is disabled by default in xf86-video-amdgpu and will require additional user configuration.

The patches have been tested as working on upstream userland with the GNOME desktop environment under a single monitor setup. They also work on KDE in a single monitor setup with the compositor disabled.

The patches require that suitable applications flip via the Present extension to xf86-video-amdgpu for the entire Screen. Some compositors may interfere with this if they are unable to unredirect the window.

Full implementation details for these changes can be reviewed in their respective mailing lists and the xf86-video-amdgpu GitLab.

=== Previous discussions ===

These patches are based upon feedback from previous threads on the subject. These are linked below for reference:

https://lists.freedesktop.org/archives/amd-gfx/2018-April/021047.html
https://lists.freedesktop.org/archives/dri-devel/2017-October/155207.html
https://lists.freedesktop.org/archives/dri-devel/2018-September/189404.html
https://lists.freedesktop.org/archives/dri-devel/2018-September/190910.html
https://lists.freedesktop.org/archives/mesa-dev/2018-September/205001.html
https://lists.freedesktop.org/archives/mesa-dev/2018-September/205883.html
https://lists.freedesktop.org/archives/mesa-dev/2018-October/206486.html
https://lists.freedesktop.org/archives/mesa-dev/2018-October/206802.html

Nicholas Kazlauskas (5):
  util: Get program name based on path when possible
  util: Add adaptive_sync driconf option
  drirc: Initial blacklist for adaptive sync
  loader/dri3: Enable adaptive_sync via _VARIABLE_REFRESH property
  radeonsi: Enable adaptive_sync by default for radeon

 .../drivers/radeonsi/driinfo_radeonsi.h       |  4 +
 src/loader/loader_dri3_helper.c               | 47 ++++++++++-
 src/loader/loader_dri3_helper.h               |  2 +
 src/util/00-mesa-defaults.conf                | 82 +++++++++++++++++++
 src/util/u_process.c                          | 23 +++++-
 src/util/xmlpool/t_options.h                  |  5 ++
 6 files changed, 161 insertions(+), 2 deletions(-)

-- 
2.19.1