Atomic Async Page Flips Proposed, Valve's Gamescope Compositor Has Support Pending

[phoronix]

Phoronix: Atomic Async Page Flips Proposed, Valve's Gamescope Compositor Has Support Pending

Async page flipping via DRM_MODE_PAGE_FLIP_ASYNC has been available with the Direct Rendering Manager's legacy API but hasn't been supported by the atomic mode-setting interface. However, a proposed patch series would add that atomic async flip support and wire it up initially for the AMDGPU DRM driver. Meanwhile Valve's Gamescope compositor in user-space would be ready to make use of it...

https://www.phoronix.com/news/Atomic-Async-Page-Flips

[ms178]

Would you get screen tearing even if you have Freesync enabled within the supported Freesync range? I would assume not which would make this patch series more attractive.

[rhysperry111]

Could someone give me a quick rundown of what this patch would actually allow for? I understand VSYNC and all that, but there doesn't seem to be a nice explanation of what this actually does

[MrCooper]

Would you get screen tearing even if you have Freesync enabled within the supported Freesync range? I would assume not which would make this patch series more attractive.

You assume correctly. With VRR enabled, there will generally only be tearing if the application frame rate is outside of the refresh rate range.

Could someone give me a quick rundown of what this patch would actually allow for?

It allows a display server which uses the atomic KMS API to submit page flips which take effect ASAP and may tear.

[Chewi]

Good stuff. I tried out Gamescope, and while it didn't meet my needs, I can see how it can be useful. The current lag is certainly noticeable though.

[skeevy420]

Good stuff. I tried out Gamescope, and while it didn't meet my needs, I can see how it can be useful. The current lag is certainly noticeable though.

FWIW, it's actually pretty good on a PC to TV setup where you're limited to 60hz and the 16.6ms latency inherent to that setup. As long as everything finishes within that 16.6ms window you're all good. For me the biggest benefits are the scaling methods Gamescope brings since you can't use the various Proton and Wine scaling methods with native Linux games. When your PC to TV setup includes both a 4GB RX 580 and a 4K TV scaling becomes your friend.

[clouddrop]

Very nice, thank you Simon/emersion.
Went back to check on that old wayland-protocols MR and it has been mentioned there as well. While I probably will not need it personally it is nice to have options for those that do. Less input lag vs no tearing.

[tildearrow]

Very nice, thank you Simon

Simor?

Simor Ser sent out this patch series with "gaming use-cases" in mind.

Michael

[yump]

It allows a display server which uses the atomic KMS API to submit page flips which take effect ASAP and may tear.

Can the cursor plane be moved asyncronously too? Something I noticed back when I was using X11 and pointing high frame rate cameras at my screen, was that in the case of some ultra-lightweight latency-optimized clients like XTerm, a dragged window actually moved ahead of the mouse cursor. I assume that the cause was the hardware cursor getting synced to vblank somehow, and I spent an afternoon or so trying to figure out how to make it not do that. Since the cursor is so small compared to height of the screen, an un-vsync'd cursor should only tear very rarely, and it would save half a frame of mouse latency on average.

(Cursors aside, this will be a big boon to graphics tablet users.)

[MrCooper]

Can the cursor plane be moved asyncronously too? Something I noticed back when I was using X11 and pointing high frame rate cameras at my screen, was that in the case of some ultra-lightweight latency-optimized clients like XTerm, a dragged window actually moved ahead of the mouse cursor. I assume that the cause was the hardware cursor getting synced to vblank somehow, and I spent an afternoon or so trying to figure out how to make it not do that.

In the current proposal, the flag applies to an atomic commit as a whole, so it would affect all planes including cursor planes in principle.

I know that at least some older GPUs were capable of moving the cursor outside of vertical blank, but I'm not sure if that's still the case with current GPUs, or if the drivers are making use of that capability.

Since the cursor is so small compared to height of the screen, an un-vsync'd cursor should only tear very rarely

It should be possible to completely avoid tearing, e.g. by internally delaying the update if the cursor is already visible on the current scanlines. Though that could still result in the cursor being visible at multiple vertical locations in the same refresh cycle.