On 2018-10-03 04:41 AM, 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 :-) >
Not really familiar with vgem and prime but this sounds like a good approach. > 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. > What's the "magic spinning batch support" and where can I find out more about it. This could be very useful for VRR debug and testing. Harry > Neither needs driver hacks or debugfs. > > Cheers, Daniel >> >> 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 >>>> >>> > _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
