All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bruno Milreu <bmilreu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
Subject: Re: [PATCH] drm/amd/display: Use vrr friendly pageflip throttling in DC
Date: Fri, 22 Feb 2019 00:30:17 -0300	[thread overview]
Message-ID: <CAHryUMfZXZDUwr=Ykoj5eBtkvSDJukNXCuyogfjsPohnyHCmmQ@mail.gmail.com> (raw)


[-- Attachment #1.1: Type: text/plain, Size: 3224 bytes --]

On 2/9/19 1:52 AM, 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 at gmail.com>
> Cc: <stable at vger.kernel.org>
> Cc: Nicholas Kazlauskas <nicholas.kazlauskas at amd.com>
> Cc: Harry Wentland <harry.wentland at amd.com>
> Cc: Alex Deucher <alexander.deucher at amd.com>
> Cc: Michel Dänzer <michel at daenzer.net>

This gets rid of stuttering with FreeSync for me. The current behavior
shows constant periodic stutters at lower than maximum framerates. Please
try pushing this into 5.1.

Tested-by: Bruno Filipe<bmilreu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

[-- Attachment #1.2: Type: text/html, Size: 3946 bytes --]

[-- Attachment #2: Type: text/plain, Size: 153 bytes --]

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

             reply	other threads:[~2019-02-22  3:30 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-22  3:30 Bruno Milreu [this message]
  -- strict thread matches above, loose matches on Subject: below --
2019-02-09  6:52 [PATCH] drm/amd/display: Use vrr friendly pageflip throttling in DC Mario Kleiner
2019-02-09  6:52 ` Mario Kleiner
2019-02-11 14:38 ` Kazlauskas, Nicholas
2019-02-11 14:38   ` Kazlauskas, Nicholas
     [not found] ` <20190209065255.9480-1-mario.kleiner.de-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2019-02-11 15:01   ` Michel Dänzer
     [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='CAHryUMfZXZDUwr=Ykoj5eBtkvSDJukNXCuyogfjsPohnyHCmmQ@mail.gmail.com' \
    --to=bmilreu-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
    --cc=amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.