Announcement

Collapse
No announcement yet.

RADV Vulkan Driver Lands FreeSync/Adaptive-Sync For Mesa 19.1

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

  • RADV Vulkan Driver Lands FreeSync/Adaptive-Sync For Mesa 19.1

    Phoronix: RADV Vulkan Driver Lands FreeSync/Adaptive-Sync For Mesa 19.1

    While on the kernel-side there has been FreeSync support with the AMDGPU DRM driver since Linux 5.0 and for the OpenGL driver with RadeonSI there has been this functionality in Mesa 19.0 when paired with a supported kernel, the Mesa Radeon Vulkan driver has missed out on this action until now. But landing just in time for the Mesa 19.1 feature freeze is now the FreeSync/Adaptive-Sync enablement for RADV...

    http://www.phoronix.com/scan.php?pag...Lands-FreeSync

  • #2
    Awesome, congrats and thank you to everyone who made this possible!! Also makes the upcoming Navi launch much more enticing for Linux gamers.

    I assume Low Framerate Compensation will work on supporting monitors just like in Windows?

    Michael- do you have freesync monitors to test?

    Comment


    • #3
      Nice work! Now Wayland needs to support FreeSync as well.

      Comment


      • #4
        Oibaf ppa is building.

        Comment


        • #5
          Originally posted by R41N3R View Post
          Nice work! Now Wayland needs to support FreeSync as well.
          KWin developers weren't enthusiastic about it. Sounds like it will take them years to implement.

          Comment


          • #6
            Originally posted by humbug View Post
            Awesome, congrats and thank you to everyone who made this possible!! Also makes the upcoming Navi launch much more enticing for Linux gamers.

            I assume Low Framerate Compensation will work on supporting monitors just like in Windows?

            Michael- do you have freesync monitors to test?
            It seems that Low Framerate Compensation works for the OpenGL driver - I run Unigine Valley @max on my 1440p, 35-72Hz monitor + reference RX480, and the in-bench FPS is half the monitor-reported refresh rate e.g. 27 (bench) => 54 (screen)) and since RADV essentially ported all the FreeSync bits from it, I would assume that yes, LFC should work.

            Comment


            • #7
              Originally posted by humbug View Post
              I assume Low Framerate Compensation will work on supporting monitors just like in Windows?
              LFC is a kernel feature and it is in use when freesync is active. See https://patchwork.freedesktop.org/pa...es=53559&rev=2

              Comment


              • #8
                Originally posted by Etherman View Post
                Oibaf ppa is building.
                Too bad it is using llvm 8 and not llvm 9 dev like Padoka ppa. LLVM 8 drops fps. The graphics stack must be in sync, Mesa git, LLVM git and the AMD wip kernel.

                Comment


                • #9
                  It took 2 months to merge 27 lines of freesync code to mainline mesa. A new world record in case of freesync merging. AMDVLK does not have the freesync support. Gaming people stress and tests graphics stacks best and are second class citizens for developers.

                  Comment


                  • #10
                    This is great news. I just recently got it working on RadeonSI and it works pretty good. I was surprised to see LFC already being implemented. As soon as 19.1 and RADV Freesync support is out there, I would say it's almost as good as on Windows which is cool considering how much issues there were on Windows in the beginning.

                    One problem I encountered is that I usually run my monitor on 120hz, but it's Freesync range is 35-90hz. On Windows, running it at 120hz disables Freesync entirely (assuming I'm not modifying EDID, which I do) but on GNU/Linux, it's still enabled (in theory, this is awesome) and as soon as I start a VRR enabled application, it drops into range and it's sort of working, but it seems to overshoot 90hz just slightly (by a few decimals probably) which is accompanied with horrible image corruption which occurs in the monitor whenever it goes outside of it's VRR range. If I set the display mode to [email protected], the artifacts goes away and it works as expected.

                    The other issue I have isn't directly related to VRR but does affect how VRR works for me. On Windows, I prefer to edit EDID so that the range is 44-120hz instead of 35-90hz. This is easy to do with a tool called Custom Resolution Utility and works great. I have tried loading the edited EDID on Linux with boot parameter drm.edid_firmware, but its not successful in loading the custom EDID binary during boot. Pretty sure because it's missing from my initramfs. Tried making a hook script which would automatically put it in initramfs whenever update-initramfs runs, but it's not working properly. I wish there was an easier way to do this

                    Also, due to some people previously saying mpv worked fine with VRR, I removed it from the blacklist out of curiosity. To little surprise, the refresh rate during video playback was all over the place, so no, it's not working properly despite what people say. In their defence though, the extra stuttering from this was barely noticeable and would probably pass a lot of people right over the head, unlike when I tried MPC-HC on Windows which was a complete stutterfest and slideshow with variable refresh. The default Windows 10 video player is thus still the only one able to handle VRR properly, and to do that it utilizes a special API call available on Windows to schedule vblanks ahead of time. We need something similar on GNU/Linux before VRR can be used for video.
                    Last edited by Brisse; 04-24-2019, 07:01 AM.

                    Comment

                    Working...
                    X