From: "Michel Dänzer" <michel-otUistvHUpPR7s880joybQ@public.gmane.org>
To: Mario Kleiner <mario.kleiner.de-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
Nicholas Kazlauskas
<nicholas.kazlauskas-5C7GfCeVMHo@public.gmane.org>
Subject: Re: [PATCH] drm/amd/display: Use vrr friendly pageflip throttling in DC.
Date: Mon, 11 Feb 2019 16:01:12 +0100 [thread overview]
Message-ID: <5df863c3-2008-b644-a07f-e34b5f9c1ad2@daenzer.net> (raw)
In-Reply-To: <20190209065255.9480-1-mario.kleiner.de-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 2019-02-09 7:52 a.m., Mario Kleiner wrote:
> In VRR mode, keep track of the vblank count of the last
> completed pageflip in amdgpu_crtc->last_flip_vblank, as
> recorded in the pageflip completion handler after each
> completed flip.
>
> Use that count to prevent mmio programming a new pageflip
> within the same vblank in which the last pageflip completed,
> iow. to throttle pageflips to at most one flip per video
> frame, while at the same time allowing to request a flip
> not only before start of vblank, but also anywhere within
> vblank.
>
> The old logic did the same, and made sense for regular fixed
> refresh rate flipping, but in vrr mode it prevents requesting
> a flip anywhere inside the possibly huge vblank, thereby
> reducing framerate in vrr mode instead of improving it, by
> delaying a slightly delayed flip requests up to a maximum
> vblank duration + 1 scanout duration. This would limit VRR
> usefulness to only help applications with a very high GPU
> demand, which can submit the flip request before start of
> vblank, but then have to wait long for fences to complete.
>
> With this method a flip can be both requested and - after
> fences have completed - executed, ie. it doesn't matter if
> the request (amdgpu_dm_do_flip()) gets delayed until deep
> into the extended vblank due to cpu execution delays. This
> also allows clients which want to regulate framerate within
> the vrr range a much more fine-grained control of flip timing,
> a feature that might be useful for video playback, and is
> very useful for neuroscience/vision research applications.
>
> In regular non-VRR mode, retain the old flip submission
> behavior. This to keep flip scheduling for fullscreen X11/GLX
> OpenGL clients intact, if they use the GLX_OML_sync_control
> extensions glXSwapBufferMscOML(, ..., target_msc,...) function
> with a specific target_msc target vblank count.
>
> glXSwapBuffersMscOML() or DRI3/Present PresentPixmap() will
> not flip at the proper target_msc for a non-zero target_msc
> if VRR mode is active with this patch. They'd often flip one
> frame too early. However, this limitation should not matter
> much in VRR mode, as scheduling based on vblank counts is
> pretty futile/unusable under variable refresh duration
> anyway, so no real extra harm is done.
>
> According to some testing already done with this patch by
> Nicholas on top of my tests, IGT tests didn't report any
> problems. If fixes stuttering and flickering when flipping
> at rates below the minimum vrr refresh rate.
>
> Fixes: bb47de736661 ("drm/amdgpu: Set FreeSync state using drm VRR
> properties")
> Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
> Cc: <stable@vger.kernel.org>
> Cc: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
> Cc: Harry Wentland <harry.wentland@amd.com>
> Cc: Alex Deucher <alexander.deucher@amd.com>
> Cc: Michel Dänzer <michel@daenzer.net>
I wonder if this couldn't be solved in a simpler / cleaner way by making
use of the target MSC passed to the page_flip_target hook.
--
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:[~2019-02-11 15:01 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-09 6:52 [PATCH] drm/amd/display: Use vrr friendly pageflip throttling in DC Mario Kleiner
[not found] ` <20190209065255.9480-1-mario.kleiner.de-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2019-02-11 14:38 ` Kazlauskas, Nicholas
2019-02-11 15:01 ` Michel Dänzer [this message]
[not found] ` <5df863c3-2008-b644-a07f-e34b5f9c1ad2-otUistvHUpPR7s880joybQ@public.gmane.org>
2019-02-11 18:44 ` Kazlauskas, Nicholas
[not found] ` <6fc4d9c5-e5aa-5879-6f05-09a8aceb56de-5C7GfCeVMHo@public.gmane.org>
2019-02-12 9:03 ` Mario Kleiner via amd-gfx
2019-02-13 9:53 ` Daniel Vetter
2019-02-13 10:54 ` Michel Dänzer
[not found] ` <a4511303-9e4a-3a6c-73dc-855b94622198-otUistvHUpPR7s880joybQ@public.gmane.org>
2019-02-13 12:54 ` Daniel Vetter
2019-02-12 8:39 ` Mario Kleiner via dri-devel
[not found] ` <CAEsyxyh=B56BjZqRD-1EUMR9m2O573=TpzGirjvpnyGmW6XY9Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-02-12 9:24 ` 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=5df863c3-2008-b644-a07f-e34b5f9c1ad2@daenzer.net \
--to=michel-otuistvhuppr7s880joybq@public.gmane.org \
--cc=amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=mario.kleiner.de-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=nicholas.kazlauskas-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