On 2018-10-03 04:25 AM, Mike Lothian wrote: > Hi > > I'm curious to know whether this will/could work over PRIME >
I don't see why this shouldn't work over PRIME as long as the presenting GPU supports the new variable refresh rate API, but I know very little about prime, so maybe someone else can chime in and give a better opinion. Harry > If the discrete card is rendering slower than the display's frequency could > the frequency be dropped on integrated display? I think there are laptops > that have freesync now > > Cheers > > Mike > > On Mon, 1 Oct 2018 at 08:15 Daniel Vetter <dan...@ffwll.ch > <mailto:dan...@ffwll.ch>> 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 > <mailto: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-de...@lists.freedesktop.org <mailto:dri-de...@lists.freedesktop.org> > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > _______________________________________________ > 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
