On Mon, Sep 24, 2018 at 02:15:34PM -0400, Nicholas Kazlauskas wrote: > These patches are part of a proposed new interface for supporting variable > refresh rate via DRM properties. > > === Changes from v1 === > > For drm: > > * The variable_refresh_capable property is now flagged as > DRM_MODE_PROP_IMMUTABLE > > For drm/gpu/amd/display: > > * Patches no longer pull in IOCTL/FreeSync refactoring code > * FreeSync enable/disable behavior has been modified to reflect changes in > userspace behavior from xf86-video-amdgpu and mesa > > === Adaptive sync and variable refresh rate === > > Adaptive sync is part of the DisplayPort spec 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. Content > that is flipped infrequently or at random intervals tends to fair poorly. > Multiple clients trying to flip under the same screen can similarly interfere > with prediction. > > Userland needs a way to let the driver know when the content on the screen is > suitable for variable refresh rate and if the user wishes to have the feature > enabled. > > === DRM API to support variable refresh rates === > > This patch introduces a new API via atomic properties on the DRM connector > and CRTC. > > The connector has two new optional properties: > > * bool variable_refresh_capable - set by the driver if the hardware is > capable of supporting variable refresh tech > > * bool variable_refresh_enabled - set by the user to enable variable refresh > adjustment over the connector > > The CRTC has one additional default property: > > * bool variable_refresh - a content hint to the driver specifying that the > CRTC contents are suitable for variable refresh adjustment > > == Overview for DRM driver developers === > > Driver developers can attach the optional connector properties via > drm_connector_attach_variable_refresh_properties on connectors that support > variable refresh (typically DP or HDMI). > > The variable_refresh_capable property should be managed as the output on the > connector changes. The property is read only from userspace. > > The variable_refresh_enabled property is intended to be a property controlled > by userland as a global on/off switch for variable refresh technology. It > should be checked before enabling variable refresh rate. > > === Overview for Userland developers == > > The variable_refresh property on the CRTC should be set to true when the > CRTCs are suitable for variable refresh rate. In practice this is probably an > application like a game - a single window that covers the whole CRTC surface > and is the only client issuing flips. > > 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 (amd-gfx) > * mesa (mesa-dev) > > These patches enable adaptive variable refresh on X for AMD hardware provided > that the user sets the variable_refresh_enabled property to true on supported > connectors (ie. using xrandr --set-prop). > > 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 > single monitor setup if the compositor is disabled. > > The patches require that the application window can issue screen flips via > the Present extension to xf86-video-amdgpu. Due to Present extension > limitations some desktop environments and multi-monitor setups are currently > not compatible. > > Full implementation details for these changes can be reviewed in their > respective mailing lists. > > === Previous discussions === > > These patches are based upon feedback from patches and feedback from two > previous threads on the subject which 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 > > Nicholas Kazlauskas > > Nicholas Kazlauskas (3): > drm: Add variable refresh rate properties to connector > drm: Add variable refresh property to DRM CRTC > drm/amd/display: Set FreeSync state using DRM VRR properties
Please include Manasi manasi.d.nav...@intel.com when resending, she's working on this from our side. Also some overview kernel-docs that document the uapi aspect of how the prorties are driven should be included. Probably best if you add a new "Variable Refresh Rate" section under https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#kms-properties with links to functions drivers should call to set up and everything. Best practice is to stuff all that into a DOC: comment. An igt testcase would be neat too. Cheers, Daniel > > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 232 +++++++++--------- > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 6 +- > drivers/gpu/drm/drm_atomic_helper.c | 1 + > drivers/gpu/drm/drm_atomic_uapi.c | 12 + > drivers/gpu/drm/drm_connector.c | 35 +++ > drivers/gpu/drm/drm_crtc.c | 2 + > drivers/gpu/drm/drm_mode_config.c | 6 + > include/drm/drm_connector.h | 27 ++ > include/drm/drm_crtc.h | 13 + > include/drm/drm_mode_config.h | 8 + > 10 files changed, 225 insertions(+), 117 deletions(-) > > -- > 2.19.0 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
