<div dir="ltr">On 2/9/19 1:52 AM, Mario Kleiner wrote:<br>> In VRR mode, keep track of the vblank count of the last<br>> completed pageflip in amdgpu_crtc->last_flip_vblank, as<br>> recorded in the pageflip completion handler after each<br>> completed flip.<br>> <br>> Use that count to prevent mmio programming a new pageflip<br>> within the same vblank in which the last pageflip completed,<br>> iow. to throttle pageflips to at most one flip per video<br>> frame, while at the same time allowing to request a flip<br>> not only before start of vblank, but also anywhere within<br>> vblank.<br>> <br>> The old logic did the same, and made sense for regular fixed<br>> refresh rate flipping, but in vrr mode it prevents requesting<br>> a flip anywhere inside the possibly huge vblank, thereby<br>> reducing framerate in vrr mode instead of improving it, by<br>> delaying a slightly delayed flip requests up to a maximum<br>> vblank duration + 1 scanout duration. This would limit VRR<br>> usefulness to only help applications with a very high GPU<br>> demand, which can submit the flip request before start of<br>> vblank, but then have to wait long for fences to complete.<br>> <br>> With this method a flip can be both requested and - after<br>> fences have completed - executed, ie. it doesn't matter if<br>> the request (amdgpu_dm_do_flip()) gets delayed until deep<br>> into the extended vblank due to cpu execution delays. This<br>> also allows clients which want to regulate framerate within<br>> the vrr range a much more fine-grained control of flip timing,<br>> a feature that might be useful for video playback, and is<br>> very useful for neuroscience/vision research applications.<br>> <br>> In regular non-VRR mode, retain the old flip submission<br>> behavior. This to keep flip scheduling for fullscreen X11/GLX<br>> OpenGL clients intact, if they use the GLX_OML_sync_control<br>> extensions glXSwapBufferMscOML(, ..., target_msc,...) function<br>> with a specific target_msc target vblank count.<br>> <br>> glXSwapBuffersMscOML() or DRI3/Present PresentPixmap() will<br>> not flip at the proper target_msc for a non-zero target_msc<br>> if VRR mode is active with this patch. They'd often flip one<br>> frame too early. However, this limitation should not matter<br>> much in VRR mode, as scheduling based on vblank counts is<br>> pretty futile/unusable under variable refresh duration<br>> anyway, so no real extra harm is done.<br>> <br>> According to some testing already done with this patch by<br>> Nicholas on top of my tests, IGT tests didn't report any<br>> problems. If fixes stuttering and flickering when flipping<br>> at rates below the minimum vrr refresh rate.<br>> <br>> Fixes: bb47de736661 ("drm/amdgpu: Set FreeSync state using drm VRR<br>> properties")<br>> Signed-off-by: Mario Kleiner <<a href="http://mario.kleiner.de">mario.kleiner.de</a> at <a href="http://gmail.com">gmail.com</a>><br>> Cc: <stable at <a href="http://vger.kernel.org">vger.kernel.org</a>><br>> Cc: Nicholas Kazlauskas <nicholas.kazlauskas at <a href="http://amd.com">amd.com</a>><br>> Cc: Harry Wentland <harry.wentland at <a href="http://amd.com">amd.com</a>><br>> Cc: Alex Deucher <alexander.deucher at <a href="http://amd.com">amd.com</a>><br>> Cc: Michel Dänzer <michel at <a href="http://daenzer.net">daenzer.net</a>><div><br><div>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.</div><div><br></div><div>Tested-by: Bruno Filipe<<a href="mailto:bmilreu@gmail.com">bmilreu@gmail.com</a>></div></div></div>