From: "Kazlauskas, Nicholas" <Nicholas.Kazlauskas@amd.com>
To: Manasi Navare <manasi.d.navare@intel.com>
Cc: "daniel.vetter@ffwll.ch" <daniel.vetter@ffwll.ch>,
"michel@daenzer.net" <michel@daenzer.net>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"amd-gfx@lists.freedesktop.org" <amd-gfx@lists.freedesktop.org>,
"Deucher, Alexander" <Alexander.Deucher@amd.com>,
"Olsak, Marek" <Marek.Olsak@amd.com>
Subject: Re: [PATCH v4 3/4] drm: Document variable refresh properties
Date: Fri, 26 Oct 2018 20:06:11 +0000 [thread overview]
Message-ID: <f9b412fd-7cf6-8ae6-c253-26d4f417eafb@amd.com> (raw)
In-Reply-To: <20181026191324.GI30384@intel.com>
On 10/26/18 3:13 PM, Manasi Navare wrote:
> On Fri, Oct 26, 2018 at 05:34:15PM +0000, Kazlauskas, Nicholas wrote:
>> On 10/26/18 10:53 AM, Ville Syrjälä wrote:
>>> On Fri, Oct 26, 2018 at 02:49:31PM +0000, Kazlauskas, Nicholas wrote:
>>>> On 10/26/18 7:37 AM, Pekka Paalanen wrote:
>>>>> On Thu, 11 Oct 2018 12:39:41 -0400
>>>>> Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> wrote:
>>>>>
>>>>>> These include the drm_connector 'vrr_capable' and the drm_crtc
>>>>>> 'vrr_enabled' properties.
>>>>>>
>>>>>> Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
>>>>>> ---
>>>>>> Documentation/gpu/drm-kms.rst | 7 +++++++
>>>>>> drivers/gpu/drm/drm_connector.c | 22 ++++++++++++++++++++++
>>>>>> 2 files changed, 29 insertions(+)
>>>>>>
>>>>>> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
>>>>>> index 4b1501b4835b..8da2a178cf85 100644
>>>>>> --- a/Documentation/gpu/drm-kms.rst
>>>>>> +++ b/Documentation/gpu/drm-kms.rst
>>>>>> @@ -575,6 +575,13 @@ Explicit Fencing Properties
>>>>>> .. kernel-doc:: drivers/gpu/drm/drm_atomic_uapi.c
>>>>>> :doc: explicit fencing properties
>>>>>>
>>>>>> +
>>>>>> +Variable Refresh Properties
>>>>>> +---------------------------
>>>>>> +
>>>>>> +.. kernel-doc:: drivers/gpu/drm/drm_connector.c
>>>>>> + :doc: Variable refresh properties
>>>>>> +
>>>>>> Existing KMS Properties
>>>>>> -----------------------
>>>>>>
>>>>>> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
>>>>>> index f0deeb7298d0..2a12853ca917 100644
>>>>>> --- a/drivers/gpu/drm/drm_connector.c
>>>>>> +++ b/drivers/gpu/drm/drm_connector.c
>>>>>> @@ -1254,6 +1254,28 @@ int drm_mode_create_scaling_mode_property(struct drm_device *dev)
>>>>>> }
>>>>>> EXPORT_SYMBOL(drm_mode_create_scaling_mode_property);
>>>>>>
>>>>>> +/**
>>>>>> + * DOC: Variable refresh properties
>>>>>> + *
>>>>>> + * Variable refresh rate control is supported via properties on the
>>>>>> + * &drm_connector and &drm_crtc objects.
>>>>>> + *
>>>>>> + * "vrr_capable":
>>>>>> + * Optional &drm_connector boolean property that drivers should attach
>>>>>> + * with drm_connector_attach_vrr_capable_property() on connectors that
>>>>>> + * could support variable refresh rates. Drivers should update the
>>>>>> + * property value by calling drm_connector_set_vrr_capable_property().
>>>>>> + *
>>>>>> + * Absence of the property should indicate absence of support.
>>>>>> + *
>>>>>> + * "vrr_enabled":
>>>>>> + * Default &drm_crtc boolean property that notifies the driver that the
>>>>>> + * variable refresh rate adjustment should be enabled for the CRTC.
>>>>>
>>>>> Hi,
>>>>>
>>>>> where is the documentation that explains how drivers must implement
>>>>> "variable refresh rate adjustment"?
>>>>>
>>>>> What should and could userspace expect to get if it flicks this switch?
>>>>>
>>>>> I also think the kernel documentation should include a description of
>>>>> what VRR actually is and how it conceptually works as far as userspace
>>>>> is concerned.
>>>>>
>>>>> That is, the kernel documentation should describe what this thing does,
>>>>> so that we avoid every driver implementing a different thing. For
>>>>> example, one driver could prevent the luminance flickering itself by
>>>>> tuning the timings while another driver might not do that, which means
>>>>> that an application tested on the former driver will look just fine
>>>>> while it is unbearable to watch on the latter.
>>>>>
>>>>>
>>>>> Thanks,
>>>>> pq
>>>>
>>>> I felt it was best to leave this more on the vague side to not impose
>>>> restrictions yet on what a driver must do.
>>>>
>>>> If you think it's worth defining what the "baseline" expectation is for
>>>> userspace, I would probably describe it as "utilizing the monitor's
>>>> variable refresh rate to reduce stuttering or tearing that can occur
>>>> during flipping". This is currently what the amdgpu driver has enabled
>
> I would also mention that without VRR, the display engine processes the flips
> independently of the rendering speed which might result into stuttering or tearing.
>
> Might also be worth giving a quick example with numbers in the documentation.
> Something like: For Eg if the rendering speed is 40Hz, without VRR, display engine
> will flip at constant 60Hz, which means that same frame will be displayed twice which
> will be observed as stutter/repetition.
> With VRR enabled, the vertical front porch will be extended and the flip will
> be processed when its ready or at max blanking time resulting a smooth transition without repetition.
Good points about mentioning the problems it solves in the documentation.
>
>>>> for support. The implementation also isn't much more complex than just
>>>> passing the variable refresh range to the hardware.
>>>>
>>>> I wouldn't want every driver to be forced to implement some sort of
>>>> luminance flickering by default. It's not noticeable on many panels and
>>>> any tuning would inherently add latency to the output. It would probably
>>>> be better left as a new property or a driver specific feature.
>>>>
>>>> In general I would imagine that most future VRR features would end up as
>>>> new properties. Anything that's purely software could be implemented as
>>>> a drm helper that every driver can use. I think the target presentation
>>>> timestamp feature is a good example for that.
>>>
>>> Speaking of timestamps. What is the expected behaviour of vblank
>>> timestamps when vrr is enabled?
>>>
>>
>> When vrr is enabled the duration of the vertical front porch will be
>> extended until flip or timeout occurs. The vblank timestamp will vary
>> based on duration of the vertical front porch. The min/max duration for
>> the front porch can be specified by the driver via the min/max range.
>
> This min max range that is read from monitor descriptor is only used to program
> the HW registers right? Its not exposed to the userspace, correct?
>
> Manasi
Currently the range isn't exposed to userspace.
I think I wouldn't mind having them for testing purposes but that can
just be done via debugfs. They might make more sense as properties but I
don't have any integration patches to utilize them in userspace.
>
>>
>> No changes to vblank timestamping handling should be necessary to
>> accommodate variable refresh rate.
>>
>> I think it's probably best to update the documentation for vrr_enable
>> with some of the specifics I described above. That should help clarify
>> userspace expectations as well.
>>
>> Nicholas Kazlauskas
Nicholas Kazlauskas
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2018-10-26 20:06 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-11 16:39 [PATCH v4 0/4] A DRM API for adaptive sync and variable refresh rate support Nicholas Kazlauskas
2018-10-11 16:39 ` [PATCH v4 2/4] drm: Add vrr_enabled property to drm CRTC Nicholas Kazlauskas
2018-10-11 16:39 ` [PATCH v4 3/4] drm: Document variable refresh properties Nicholas Kazlauskas
[not found] ` <20181011163942.28267-4-nicholas.kazlauskas-5C7GfCeVMHo@public.gmane.org>
2018-10-26 11:37 ` Pekka Paalanen
2018-10-26 14:49 ` Kazlauskas, Nicholas
[not found] ` <bdda3a3b-c912-98bf-8dbd-29a5b58086df-5C7GfCeVMHo@public.gmane.org>
2018-10-26 14:53 ` Ville Syrjälä
[not found] ` <20181026145321.GV9144-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2018-10-26 17:34 ` Kazlauskas, Nicholas
[not found] ` <f21251f7-10e2-e0f7-702d-bd3868ac8edc-5C7GfCeVMHo@public.gmane.org>
2018-10-26 17:59 ` Ville Syrjälä
2018-10-29 16:37 ` Michel Dänzer
[not found] ` <481ae686-adda-5857-5538-2b0af2e25427-otUistvHUpPR7s880joybQ@public.gmane.org>
2018-10-29 18:03 ` Ville Syrjälä
[not found] ` <20181029180341.GN9144-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2018-10-29 19:11 ` Kazlauskas, Nicholas
[not found] ` <3b03a13a-5418-b4fc-137f-2f917b3947d3-5C7GfCeVMHo@public.gmane.org>
2018-10-30 9:07 ` Michel Dänzer
2018-10-30 9:29 ` Michel Dänzer
2018-10-30 15:34 ` Kazlauskas, Nicholas
[not found] ` <1c1c0f6f-ccbd-bfc2-f249-a01f6fc997ec-5C7GfCeVMHo@public.gmane.org>
2018-10-31 13:38 ` Kazlauskas, Nicholas
[not found] ` <311638a8-eb8a-cb8d-3f7a-109aaa4b046b-5C7GfCeVMHo@public.gmane.org>
2018-10-31 14:12 ` Michel Dänzer
2018-10-31 14:41 ` Kazlauskas, Nicholas
2018-10-31 16:20 ` Michel Dänzer
2018-10-31 17:54 ` Kazlauskas, Nicholas
2018-11-01 8:37 ` Pekka Paalanen
[not found] ` <87bcab42-e377-259c-13ea-0cfe9c675cf9-5C7GfCeVMHo@public.gmane.org>
2018-11-01 10:58 ` Michel Dänzer
[not found] ` <99214cf0-9717-3c23-9457-791288d4d252-otUistvHUpPR7s880joybQ@public.gmane.org>
2018-11-01 14:58 ` Kazlauskas, Nicholas
2018-11-01 17:05 ` Michel Dänzer
[not found] ` <8617ac72-ec32-8146-cead-e28e78067ec0-otUistvHUpPR7s880joybQ@public.gmane.org>
2018-11-01 17:19 ` Kazlauskas, Nicholas
2018-10-26 19:13 ` Manasi Navare
2018-10-26 20:06 ` Kazlauskas, Nicholas [this message]
2018-10-26 20:58 ` Manasi Navare
2018-10-29 8:36 ` Pekka Paalanen
2018-10-29 14:31 ` Kazlauskas, Nicholas
[not found] ` <20181011163942.28267-1-nicholas.kazlauskas-5C7GfCeVMHo@public.gmane.org>
2018-10-11 16:39 ` [PATCH v4 1/4] drm: Add vrr_capable property to the drm connector Nicholas Kazlauskas
2018-10-11 16:39 ` [PATCH v4 4/4] drm/amd/display: Set FreeSync state using drm VRR properties Nicholas Kazlauskas
[not found] ` <20181011163942.28267-5-nicholas.kazlauskas-5C7GfCeVMHo@public.gmane.org>
2018-10-11 20:39 ` Harry Wentland
[not found] ` <42b237df-9c30-4cd0-0891-d0b05b54533e-5C7GfCeVMHo@public.gmane.org>
2018-10-11 20:56 ` Kazlauskas, Nicholas
2018-10-11 21:24 ` Harry Wentland
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=f9b412fd-7cf6-8ae6-c253-26d4f417eafb@amd.com \
--to=nicholas.kazlauskas@amd.com \
--cc=Alexander.Deucher@amd.com \
--cc=Marek.Olsak@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=manasi.d.navare@intel.com \
--cc=michel@daenzer.net \
/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;
as well as URLs for NNTP newsgroup(s).