On 2018-10-03 02:35 PM, Manasi Navare wrote: > On Wed, Oct 03, 2018 at 10:41:20AM +0200, Daniel Vetter wrote: >> On Tue, Oct 02, 2018 at 10:49:17AM -0400, Harry Wentland wrote: >>> >>> >>> On 2018-10-01 03:15 AM, Daniel Vetter wrote: >>>> 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. >>>> >>> >>> Thanks for bringing up docs and igt. >>> >>> For igt if we expose a monitor's vmin/vmax through a debugfs we could >>> then do vrr flips at different points within that range and measure the >>> time until vblank notifications to check that they (roughly) align with >>> the vtotal. Not sure how difficult that'd be with igt. Wonder if Arek >>> has any ideas of a better approach. >> >> We can do much better: >> >> 1. allocate a bunch of buffers >> 2. share with vgem >> 3. use vgem fake fences to perfectly control the "rendering" of your fake >> workload >> 4. flip away, and check that vrr does what it's supposed to do. >> >> Even more evil than vrr, this would test prime+vrr :-) >> >> Plan b), but only works on intel: Use the magic spinning batch support we >> have for i915.ko, where a dword write from the cpu stops the spinning, and >> hence allows you to control how long the "rendering" takes very >> accurately. >> >> Neither needs driver hacks or debugfs. >> >> Cheers, Daniel > > I feel like adding debugfs information in general about VRR capabilities > like the VRR range supported by the panel is a good idea to invoke VRR > for various refresh rates from IGT or real applications and also > to be able to do checks for whether the actual vblank happened within the > maximum > blanking interval supported. >
I think it's good to have for testing and debugging purposes. Harry > And we already parse that information in the driver to set the Vblank min and > max values > for the registers so easy to expose that as well through debugfs. > > Manasi > >>> >>> Harry >>> >>>> 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-de...@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
