AMDGPU X.Org 22.0 Driver Released With AsyncFlipSecondaries, GLAMOR Fixes

[phoronix]

Phoronix: AMDGPU X.Org 22.0 Driver Released With AsyncFlipSecondaries, GLAMOR Fixes

For those relying upon the open-source AMD Linux graphics driver stack and continuing to use an X.Org Server rather than Wayland and not using the generic xf86-video-modesetting DDX driver, xf86-video-amdgpu 22.0 is out today to improve the X.Org experience for Radeon graphics...

https://www.phoronix.com/scan.php?page=news_item&px=xf86-video-amdgpu-22.0

[binarybanana]

What I don't get is why a sync flip would have to sync over ALL outputs in the first place, unless a window spanned more than one monitor, or outputs scanned out overlapping parts of the framebuffer. In every other case there is no reason it would have to introduce tearing on any monitor anyway. But even then there is a parameter to specify which crtc to use as target, fhich should be enough to solve this problem. At least on the Intel driver it seems to work right without setting this option. In my testing when, for example, I move a glxgears window across monitors it clearly changes the frame rate according to the monitor refresh rate, so it's clearly not syncing to every output.

[agd5f]

What I don't get is why a sync flip would have to sync over ALL outputs in the first place, unless a window spanned more than one monitor, or outputs scanned out overlapping parts of the framebuffer. In every other case there is no reason it would have to introduce tearing on any monitor anyway. But even then there is a parameter to specify which crtc to use as target, fhich should be enough to solve this problem. At least on the Intel driver it seems to work right without setting this option. In my testing when, for example, I move a glxgears window across monitors it clearly changes the frame rate according to the monitor refresh rate, so it's clearly not syncing to every output.

From the commit message:

"If a sync_flip is requested for the present, then the current implementation will synchronize each pageflip to the vblank of its associated crtc. This provides tear-free image presentation across all outputs, but introduces a different artifact, if not all outputs run at the same refresh rate with perfect synchrony: The slowest output throttles the presentation rate, and present completion is delayed to flip completion of the "latest" output to complete. This means degraded performance, e.g., a dual-display setup with a 144 Hz monitor and a 60 Hz monitor will always be throttled to at most 60 fps. It also means non-constant present rate if refresh cycles drift against each other, creating complex "beat patterns", tremors, stutters and periodic slowdowns - quite irritating!"

[binarybanana]

Sure, but different outputs use different crtcs, even when overlapping regions of the framebuffer are scanned out (each output is driven by its own crtc, by definition). At least on intel hardware with xf86-video-intel. You can check in /sys/kernel/debug/drm and see it even allocates multiple frame·buffers for the whole X screen and also for individual regions of a monitor. If it didn't, buffer flipping wouldn't be possible at all for non-clone scenarios (where framebuffer is larger than a single scanout region) and generally even less so would buffer flipping work without tearing at all in any case, unless the driver waited until vblank on all monitors happened concurrently. But in that case frame rate would be limited much more than to match the slowest output. Which is not what I see happening on Intel and IIRC also Nvidia (with nouveau, but I need to retest to make sure), where frame rate even dynamically adjusts to the monitor the window is on, as shown by glxgears.

[agd5f]

Multi-head in X always uses a single logical surface for the entire desktop. It's a limitation in X. Each display can flip independently, but you are flipping between single logical surface buffers (i.e., buffers large enough to cover the entire desktop). The issue is that because the displays can be flipping asynchronously if the timing is not aligned, you may sense incongruity between the displays because each one may be scanning out of a different buffer at any given time. This just avoids that incongruity in favor of tearing on one of the displays.

[Ph42oN]

Could this possibly help on getting proper multimonitor freesync support?

I thought this was thing that would need to be fixed in compositors, i run no compositor and i never had that issue. I always had it so i have tearing on desktop but its barely noticeable at high refresh rates.