Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

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

    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

  • #2
    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.

    Comment


    • #3
      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

      Comment


      • #4
        Originally posted by ms178 View Post
        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.

        Originally posted by rhysperry111 View Post
        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.

        Comment


        • #5
          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.

          Comment


          • #6
            Originally posted by Chewi View Post
            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.
            Last edited by skeevy420; 25 August 2022, 10:32 AM.

            Comment


            • #7
              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.

              Comment


              • #8
                Originally posted by clouddrop View Post
                Very nice, thank you Simon
                Simor?

                Originally posted by phoronix
                Simor Ser sent out this patch series with "gaming use-cases" in mind.
                Michael

                Comment


                • #9
                  Originally posted by MrCooper View Post
                  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.)

                  Comment


                  • #10
                    Originally posted by yump View Post

                    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.

                    Comment

                    Working...
                    X