From: "Michel Dänzer" <michel-otUistvHUpPR7s880joybQ@public.gmane.org>
To: "Ville Syrjälä" <ville.syrjala-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Cc: "daniel.vetter-/w4YWyX8dFk@public.gmane.org"
<daniel.vetter-/w4YWyX8dFk@public.gmane.org>,
"Olsak, Marek" <Marek.Olsak-5C7GfCeVMHo@public.gmane.org>,
"dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
<dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
"manasi.d.navare-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org"
<manasi.d.navare-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
"amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
<amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
"Deucher,
Alexander" <Alexander.Deucher-5C7GfCeVMHo@public.gmane.org>,
"Kazlauskas,
Nicholas" <Nicholas.Kazlauskas-5C7GfCeVMHo@public.gmane.org>
Subject: Re: [PATCH v4 3/4] drm: Document variable refresh properties
Date: Tue, 30 Oct 2018 10:29:06 +0100 [thread overview]
Message-ID: <13a934a2-5cea-3d1b-ec57-bf5488698129@daenzer.net> (raw)
In-Reply-To: <20181029180341.GN9144-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
On 2018-10-29 7:03 p.m., Ville Syrjälä wrote:
> On Mon, Oct 29, 2018 at 05:37:49PM +0100, Michel Dänzer wrote:
>> On 2018-10-26 7:59 p.m., Ville Syrjälä 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:
>>>>>
>>>>> 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.
>>>>
>>>> No changes to vblank timestamping handling should be necessary to
>>>> accommodate variable refresh rate.
>>>
>>> The problem is that the timestamp is supposed to correspond to the first
>>> active pixel. And since we don't know how long the front porch will be
>>> we can't realistically report the true value. So I guess just assuming
>>> min front porch length is as good as anything else?
>>
>> That (and documenting that the timestamp corresponds to the earliest
>> possible first active pixel, not necessarily the actual one, with VRR)
>> might be good enough for the actual vblank event timestamps.
>>
>>
>> However, I'm not so sure about the timestamps of page flip completion
>> events. Those could be very misleading if the flip completes towards the
>> timeout, which could result in bad behaviour of applications which use
>> them for animation timing.
>>
>> Maybe the timestamp could be updated appropriately (yes, I'm hand-waving
>> :) in drm_crtc_send_vblank_event?
>
> Hmm. Updated how? Whether it's a page flip event or vblank even we won't
> know when the first active pixel will come. Although I suppose if
> there is some kind of vrr slew rate limit we could at least account
> for that to report a more correct "this is the earliest you migth be
> able to see your frame" timestamp.
>
> Oh, or are you actually saying that shceduling a new flip before the
> timeout is actually going to latch that flip immediately? I figured
> that the flip would get latched on the next start of vblank regardless,
> and the act of scheduling a flip will just kick the hardware to start
> scanning the previously latched frame earlier.
>
> scanout A | ... vblank | scanout A | ... vblank | scanout B | ... vblank
> ^ ^ ^ ^
> | | flip C latch C
> flip B latch B
This would kind of defeat the point of VRR, wouldn't it? If a flip was
scheduled after the start of vblank, the vblank would always time out,
resulting in the minimum refresh rate.
> scanout A | ... vblank | scanout B | ... vblank | scanout C | ... vblank
> ^ ^ ^ ^
> | latch B | latch C
> flip B flip C
So this is what happens.
Regardless, when the flip is latched, AMD hardware generates a "pflip"
interrupt, and its handler calls drm_crtc_send_vblank_event (and in the
case of DC drm_crtc_accurate_vblank_count before that). So the time when
drm_crtc_send_vblank_event is called might be a good approximation of
when scanout of the next frame starts.
Another possibility might be to wait for the hardware vline counter to
wrap around to 0 before calling drm_crtc_accurate_vblank_count, then the
calculations should be based on 0 instead of crtc_vtotal.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
next prev parent reply other threads:[~2018-10-30 9:29 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 [this message]
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
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=13a934a2-5cea-3d1b-ec57-bf5488698129@daenzer.net \
--to=michel-otuistvhuppr7s880joybq@public.gmane.org \
--cc=Alexander.Deucher-5C7GfCeVMHo@public.gmane.org \
--cc=Marek.Olsak-5C7GfCeVMHo@public.gmane.org \
--cc=Nicholas.Kazlauskas-5C7GfCeVMHo@public.gmane.org \
--cc=amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=daniel.vetter-/w4YWyX8dFk@public.gmane.org \
--cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=manasi.d.navare-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=ville.syrjala-VuQAYsv1563Yd54FQh9/CA@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;
as well as URLs for NNTP newsgroup(s).