On 2019-02-12 9:39 a.m., Mario Kleiner via dri-devel wrote:
> On Mon, Feb 11, 2019 at 4:01 PM Michel Dänzer <michel@xxxxxxxxxxx> wrote:
>>
>> 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@xxxxxxxxx>
>>> Cc: <stable@xxxxxxxxxxxxxxx>
>>> Cc: Nicholas Kazlauskas <nicholas.kazlauskas@xxxxxxx>
>>> Cc: Harry Wentland <harry.wentland@xxxxxxx>
>>> Cc: Alex Deucher <alexander.deucher@xxxxxxx>
>>> Cc: Michel Dänzer <michel@xxxxxxxxxxx>
>>
>> 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.
>>
> If DisplayCore would implement the page_flip_target hook, one could do
> the same implementation in userspace, ie. tracking msc of last
> completed flip and setting target msc accordingly to throttle. But i
> don't think we'd be better of with that. Same solution, but now we'd
> have to let userspace know if the crtc is currently in VRR active mode
> or not.
I don't think so.
xf86-video-amdgpu is already telling the kernel which MSC is being
targeted by a flip, using DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE/RELATIVE.
This information is used by the non-DC code to decide whether the flip
can be submitted during a vertical blank period or not.
This should work with VRR as well, as the target MSC should always be <=
the current one.
> And implement page_flip_target hook in DC.
Well, DC should really make use of the target MSC information anyway. :)
> And implement the tracking logic in every userspace driver that wants
> good performance from VRR, e.g., also the modesetting ddx and all
> wayland compositors in addition to amdgpu ddx.
They don't have any VRR support yet, not sure this would make adding it
significantly harder.
That said, it would require adding target MSC support to the atomic KMS
UAPI as well. And I agree that functionally, there would be no
significant difference in the VRR case at the end of the day. I do think
it would be cleaner / less "hackish" though, making use of the same
logic with or without VRR.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
