From: "Ville Syrjälä" <ville.syrjala-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
To: "Kazlauskas,
Nicholas" <nicholas.kazlauskas-5C7GfCeVMHo@public.gmane.org>
Cc: Aric.Cyr-5C7GfCeVMHo@public.gmane.org,
nicolai.haehnle-5C7GfCeVMHo@public.gmane.org,
michel-otUistvHUpPR7s880joybQ@public.gmane.org,
amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
Christian.Koenig-5C7GfCeVMHo@public.gmane.org,
manasi.d.navare-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
daniel-/w4YWyX8dFk@public.gmane.org,
Alexander.Deucher-5C7GfCeVMHo@public.gmane.org,
harry.wentland-5C7GfCeVMHo@public.gmane.org,
Marek.Olsak-5C7GfCeVMHo@public.gmane.org
Subject: Re: [PATCH v2 2/3] drm: Add variable refresh property to DRM CRTC
Date: Mon, 24 Sep 2018 23:26:55 +0300 [thread overview]
Message-ID: <20180924202655.GA9144@intel.com> (raw)
In-Reply-To: <4aa1583c-2be0-8cec-2857-6c3e489965b4-5C7GfCeVMHo@public.gmane.org>
On Mon, Sep 24, 2018 at 03:06:02PM -0400, Kazlauskas, Nicholas wrote:
> On 09/24/2018 02:38 PM, Ville Syrjälä wrote:
> > On Mon, Sep 24, 2018 at 02:15:36PM -0400, Nicholas Kazlauskas wrote:
> >> Variable refresh rate algorithms have typically been enabled only
> >> when the display is covered by a single source of content.
> >>
> >> This patch introduces a new default CRTC property that helps
> >> hint to the driver when the CRTC composition is suitable for variable
> >> refresh rate algorithms. Userspace can set this property dynamically
> >> as the composition changes.
> >>
> >> Whether the variable refresh rate algorithms are active will still
> >> depend on the CRTC being suitable and the connector being capable
> >> and enabled by the user for variable refresh rate support.
> >>
> >> It is worth noting that while the property is atomic it isn't filtered
> >> from legacy userspace queries. This allows for Xorg userspace drivers
> >> to implement support in non-atomic setups.
> >>
> >> Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
> >> ---
> >> drivers/gpu/drm/drm_atomic_helper.c | 1 +
> >> drivers/gpu/drm/drm_atomic_uapi.c | 6 ++++++
> >> drivers/gpu/drm/drm_crtc.c | 2 ++
> >> drivers/gpu/drm/drm_mode_config.c | 6 ++++++
> >> include/drm/drm_crtc.h | 13 +++++++++++++
> >> include/drm/drm_mode_config.h | 8 ++++++++
> >> 6 files changed, 36 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> >> index 3cf1aa132778..b768d397a811 100644
> >> --- a/drivers/gpu/drm/drm_atomic_helper.c
> >> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> >> @@ -3473,6 +3473,7 @@ void __drm_atomic_helper_crtc_duplicate_state(struct drm_crtc *crtc,
> >> state->planes_changed = false;
> >> state->connectors_changed = false;
> >> state->color_mgmt_changed = false;
> >> + state->variable_refresh_changed = false;
> >
> > Another bool just to check if one bool changed seems a bit excessive.
> > Is there a reason you can't directly check if the other bool changed?
>
> It's nice for an atomic driver to be able to check if the property has
> changed to steer control flow.
>
> The driver could just check if the old crtc variable refresh value isn't
> equal to the new one itself, but there's already precedent set to
> provide flags like these instead.
Generally the changed flags are for more complicated things. Not
sure we want to start adding them for every little thing. Though
I suppose active_changed blows a hole in that theory.
>
> It also lets the driver change it as needed during atomic commits.
> You'll see many drivers making use of the other flags like
> connectors_changed, mode_changed, etc.
>
> >
> > Actually I don't understand why this per-crtc thing is being added at
> > all. You already have the prop on the connector. Why do we want to
> > make life more difficult by requiring the thing to be set on both the
> > crtc and connector?
>
> It doesn't make much sense without both.
>
> The user can globally enable or disable the variable_refresh_enabled on
> the connector. This is the user's preference.
>
> What they don't control is the variable_refresh - the content hint that
> userspace specifies when the CRTC contents are suitable for enabling
> variable refresh features (like adaptive sync). This is userspace's
> preference.
By userspace I guess you mean the compositor/display server. I don't
really see why the kernel has to be involved like this in a userspace
policy matter. If the compositor doesn't think vrr is a good idea then
it could simply choose to disable the prop on the connector even when
requested by its clients.
>
> When both preferences agree, only then will variable refresh features be
> enabled.
>
> The reasoning for the split is because not all content is suitable for
> variable refresh. Desktop environments, web browsers, etc only typically
> flip when needed - which will result in display flickering.
>
> The userspace integration as part of these patches demonstrates enabling
> variable_refresh on the CRTC selectively.
>
> >
> >> state->zpos_changed = false;
> >> state->commit = NULL;
> >> state->event = NULL;
> >> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
> >> index 0bb27a24a55c..32a4cf8a01c3 100644
> >> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> >> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> >> @@ -433,6 +433,10 @@ static int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
> >> ret = drm_atomic_set_mode_prop_for_crtc(state, mode);
> >> drm_property_blob_put(mode);
> >> return ret;
> >> + } else if (property == config->prop_variable_refresh) {
> >> + if (state->variable_refresh != val)
> >> + state->variable_refresh_changed = true;
> >> + state->variable_refresh = val;
> >> } else if (property == config->degamma_lut_property) {
> >> ret = drm_atomic_replace_property_blob_from_id(dev,
> >> &state->degamma_lut,
> >> @@ -491,6 +495,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
> >> *val = state->active;
> >> else if (property == config->prop_mode_id)
> >> *val = (state->mode_blob) ? state->mode_blob->base.id : 0;
> >> + else if (property == config->prop_variable_refresh)
> >> + *val = state->variable_refresh;
> >> else if (property == config->degamma_lut_property)
> >> *val = (state->degamma_lut) ? state->degamma_lut->base.id : 0;
> >> else if (property == config->ctm_property)
> >> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> >> index 5f488aa80bcd..ca33d6fb90ac 100644
> >> --- a/drivers/gpu/drm/drm_crtc.c
> >> +++ b/drivers/gpu/drm/drm_crtc.c
> >> @@ -340,6 +340,8 @@ int drm_crtc_init_with_planes(struct drm_device *dev, struct drm_crtc *crtc,
> >> drm_object_attach_property(&crtc->base, config->prop_mode_id, 0);
> >> drm_object_attach_property(&crtc->base,
> >> config->prop_out_fence_ptr, 0);
> >> + drm_object_attach_property(&crtc->base,
> >> + config->prop_variable_refresh, 0);
> >> }
> >>
> >> return 0;
> >> diff --git a/drivers/gpu/drm/drm_mode_config.c b/drivers/gpu/drm/drm_mode_config.c
> >> index ee80788f2c40..1287c161d65d 100644
> >> --- a/drivers/gpu/drm/drm_mode_config.c
> >> +++ b/drivers/gpu/drm/drm_mode_config.c
> >> @@ -310,6 +310,12 @@ static int drm_mode_create_standard_properties(struct drm_device *dev)
> >> return -ENOMEM;
> >> dev->mode_config.prop_mode_id = prop;
> >>
> >> + prop = drm_property_create_bool(dev, 0,
> >> + "VARIABLE_REFRESH");
> >> + if (!prop)
> >> + return -ENOMEM;
> >> + dev->mode_config.prop_variable_refresh = prop;
> >> +
> >> prop = drm_property_create(dev,
> >> DRM_MODE_PROP_BLOB,
> >> "DEGAMMA_LUT", 0);
> >> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> >> index b21437bc95bf..32b77f18ce6d 100644
> >> --- a/include/drm/drm_crtc.h
> >> +++ b/include/drm/drm_crtc.h
> >> @@ -168,6 +168,12 @@ struct drm_crtc_state {
> >> * drivers to steer the atomic commit control flow.
> >> */
> >> bool color_mgmt_changed : 1;
> >> + /**
> >> + * @variable_refresh_changed: Variable refresh support has changed
> >> + * on the CRTC. Used by the atomic helpers and drivers to steer the
> >> + * atomic commit control flow.
> >> + */
> >> + bool variable_refresh_changed : 1;
> >>
> >> /**
> >> * @no_vblank:
> >> @@ -290,6 +296,13 @@ struct drm_crtc_state {
> >> */
> >> u32 pageflip_flags;
> >>
> >> + /**
> >> + * @variable_refresh:
> >> + *
> >> + * Indicates whether the CRTC is suitable for variable refresh rate.
> >> + */
> >> + bool variable_refresh;
> >> +
> >> /**
> >> * @event:
> >> *
> >> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> >> index 928e4172a0bb..1290191cd96e 100644
> >> --- a/include/drm/drm_mode_config.h
> >> +++ b/include/drm/drm_mode_config.h
> >> @@ -639,6 +639,14 @@ struct drm_mode_config {
> >> * connectors must be of and active must be set to disabled, too.
> >> */
> >> struct drm_property *prop_mode_id;
> >> + /**
> >> + * @prop_variable_refresh: Default atomic CRTC property to indicate
> >> + * whether the CRTC is suitable for variable refresh rate support.
> >> + *
> >> + * This is only an indication of support, not whether variable
> >> + * refresh is active on the CRTC.
> >> + */
> >> + struct drm_property *prop_variable_refresh;
> >>
> >> /**
> >> * @dvi_i_subconnector_property: Optional DVI-I property to
> >> --
> >> 2.19.0
> >
>
> Nicholas Kazlauskas
--
Ville Syrjälä
Intel
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
next prev parent reply other threads:[~2018-09-24 20:26 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-24 18:15 [PATCH v2 0/3] A DRM API for adaptive sync and variable refresh rate support Nicholas Kazlauskas
[not found] ` <20180924181537.12092-1-nicholas.kazlauskas-5C7GfCeVMHo@public.gmane.org>
2018-09-24 18:15 ` [PATCH v2 1/3] drm: Add variable refresh rate properties to connector Nicholas Kazlauskas
2018-09-24 18:32 ` Ville Syrjälä
2018-10-01 7:05 ` Daniel Vetter
2018-09-24 18:15 ` [PATCH v2 3/3] drm/amd/display: Set FreeSync state using DRM VRR properties Nicholas Kazlauskas
2018-09-24 18:15 ` [PATCH v2 2/3] drm: Add variable refresh property to DRM CRTC Nicholas Kazlauskas
2018-09-24 18:38 ` Ville Syrjälä
2018-09-24 19:06 ` Kazlauskas, Nicholas
[not found] ` <4aa1583c-2be0-8cec-2857-6c3e489965b4-5C7GfCeVMHo@public.gmane.org>
2018-09-24 20:26 ` Ville Syrjälä [this message]
[not found] ` <20180924202655.GA9144-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2018-09-25 13:28 ` Michel Dänzer
[not found] ` <2158aa72-9156-5592-822a-c815f373fd53-otUistvHUpPR7s880joybQ@public.gmane.org>
2018-09-25 14:04 ` Ville Syrjälä
[not found] ` <20180925140433.GH9144-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2018-09-25 14:35 ` Michel Dänzer
2018-09-25 15:28 ` Ville Syrjälä
[not found] ` <20180925152817.GK9144-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2018-10-01 7:10 ` Daniel Vetter
2018-09-25 13:51 ` Kazlauskas, Nicholas
2018-10-05 8:10 ` Pekka Paalanen
2018-10-05 16:21 ` Kazlauskas, Nicholas
[not found] ` <fdc195dd-9650-8194-3a16-393f61bb2eee-5C7GfCeVMHo@public.gmane.org>
2018-10-05 16:56 ` Michel Dänzer
2018-10-05 17:48 ` Kazlauskas, Nicholas
2018-10-08 10:57 ` Michel Dänzer
2018-10-10 7:14 ` Pekka Paalanen
2018-10-10 13:35 ` Kazlauskas, Nicholas
[not found] ` <3bb5e05d-f7e6-8e44-cfae-202191d64245-5C7GfCeVMHo@public.gmane.org>
2018-10-12 7:23 ` Pekka Paalanen
2018-10-12 7:35 ` Koenig, Christian
[not found] ` <894d12d3-aa0b-c0f6-6347-7d13e58e651a-5C7GfCeVMHo@public.gmane.org>
2018-10-12 9:21 ` Pekka Paalanen
2018-10-12 11:20 ` Koenig, Christian
2018-10-12 12:58 ` Kazlauskas, Nicholas
2018-10-15 13:57 ` Pekka Paalanen
2018-10-15 16:02 ` Kazlauskas, Nicholas
[not found] ` <52103366-510d-15a6-61d2-26196a4f0e57-5C7GfCeVMHo@public.gmane.org>
2018-10-16 7:36 ` Pekka Paalanen
2018-10-01 7:15 ` [PATCH v2 0/3] A DRM API for adaptive sync and variable refresh rate support Daniel Vetter
2018-10-02 14:49 ` Harry Wentland
2018-10-03 8:41 ` Daniel Vetter
[not found] ` <20181003084120.GP11082-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>
2018-10-03 18:35 ` Manasi Navare
2018-10-11 19:37 ` Harry Wentland
2018-10-11 19:41 ` Harry Wentland
2018-10-03 8:25 ` Mike Lothian
[not found] ` <CAHbf0-HhjG2xc1sAjHBR=Ep11LzumO6tdyzBcKSZ8h82H28Zbg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-10-11 19:44 ` Harry Wentland
2018-10-12 8:26 ` Michel Dänzer
[not found] ` <ac5b5865-6bb0-08e8-d83c-26893e75b11e-otUistvHUpPR7s880joybQ@public.gmane.org>
2018-10-12 8:31 ` Koenig, Christian
[not found] ` <84c4a243-ca2c-49a7-9e2c-22666292aea9-5C7GfCeVMHo@public.gmane.org>
2018-10-25 17:57 ` Wentland, Harry
[not found] ` <1c3d19a7-3afa-6de5-59e0-37a19d73848b-5C7GfCeVMHo@public.gmane.org>
2018-10-26 9:33 ` Michel Dänzer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180924202655.GA9144@intel.com \
--to=ville.syrjala-vuqaysv1563yd54fqh9/ca@public.gmane.org \
--cc=Alexander.Deucher-5C7GfCeVMHo@public.gmane.org \
--cc=Aric.Cyr-5C7GfCeVMHo@public.gmane.org \
--cc=Christian.Koenig-5C7GfCeVMHo@public.gmane.org \
--cc=Marek.Olsak-5C7GfCeVMHo@public.gmane.org \
--cc=amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=daniel-/w4YWyX8dFk@public.gmane.org \
--cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=harry.wentland-5C7GfCeVMHo@public.gmane.org \
--cc=manasi.d.navare-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=michel-otUistvHUpPR7s880joybQ@public.gmane.org \
--cc=nicholas.kazlauskas-5C7GfCeVMHo@public.gmane.org \
--cc=nicolai.haehnle-5C7GfCeVMHo@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox