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

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #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
              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 2560x1440@90hz, 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; 24 April 2019, 07:01 AM.

              Comment


              • #8
                Originally posted by Brisse View Post
                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
                That's weird, I use a custom edid with Polaris and a non-VRR monitor for over a year without issues.
                Are you sure the path is correctly set in your bootloader config? Making changes to initramfs shouldn't be required without early KMS, but it works here too. To do so, simply add the path to the edid in mkinitcpio.conf FILES=() and regen initramfs. It will always be included from now on.

                Comment


                • #9
                  Originally posted by aufkrawall View Post
                  That's weird, I use a custom edid with Polaris and a non-VRR monitor for over a year without issues.
                  Are you sure the path is correctly set in your bootloader config? Making changes to initramfs shouldn't be required without early KMS, but it works here too. To do so, simply add the path to the edid in mkinitcpio.conf FILES=() and regen initramfs. It will always be included from now on.
                  That's for Arch, not Ubuntu. I almost posted the same thing

                  Comment


                  • #10
                    Originally posted by Brisse View Post
                    snip
                    I'm bored if you feel like posting your hook script....but something like this should work...

                    /usr/share/initramfs-tools/hooks/custom_edid

                    Code:
                     #!/bin/sh -e
                    PREREQS=""
                    
                    case $1 in
                            prereqs) echo "${PREREQS}"; exit 0;;
                    esac
                    . /usr/share/initramfs-tools/hook-functions
                    cp [B]/path/to/edid[/B] $DESTDIR[B]/path/to/edid[/B]
                    Fix the bold parts to what you need, add the edid kernel command line to Grub, maybe some xorg.conf tweaks (below), and you should be good to go...

                    Code:
                        Option         "ConnectedMonitor" "DVI-I-0"
                        Option         "CustomEDID" "DVI-I-0:[B]/path/to/edid[/B]"
                        Option         "IgnoreEDID" "false"
                        Option         "UseEDID" "true"
                        Option         "VariableRefresh" "true"
                    EDIT: That . /usr/blah/de/blah line might not even be needed. AFAICT all it does is source some functions that hooks may or may not use. There aren't any used in that script above.
                    Last edited by skeevy420; 24 April 2019, 08:14 AM.

                    Comment

                    Working...
                    X