Announcement

Collapse
No announcement yet.

Mesa 19.1 Likely To See Radeon "RADV" Vulkan FreeSync/Adaptive-Sync Support

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

  • Mesa 19.1 Likely To See Radeon "RADV" Vulkan FreeSync/Adaptive-Sync Support

    Phoronix: Mesa 19.1 Likely To See Radeon "RADV" Vulkan FreeSync/Adaptive-Sync Support

    Mesa 19.1 is now even more exciting as RADV's co-lead, Bas Nieuwenhuizen has requested the Radeon Vulkan's FreeSync/Adaptive-Sync support be a blocker bug for this quarterly Mesa update...

    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
    Great news! Will FreeSync be usable with DXVK?

    Comment


    • #3
      Typo:

      Originally posted by phoronix View Post
      where this variable rate refresh technology could intefere and to only enable FreeSync/Adaptive-Sync for full-screen games

      Comment


      • #4
        Is it already working with amdvlk?

        Comment


        • #5
          Originally posted by debianxfce View Post

          Yes, it is working already. By the way, I did a patch for the config system first. But Bas want own config file for RADV and not use the opengl config what would be logical, because an app can use opengl or vulkan. Duplicate work is stupid, but it is so typical with Linux and more code make it more complex. Code reuse is the way to go when you can, not copy pasting new code. Bas is really an artist, first naming the freesync patch as hack and non missing config system is a bug now. I have been thinking to move to use win10 because of people who blocks fully working features. Beginning from the CIK experimental status in the kernel to the radv freesync support.
          FWIW, I've read the comments on your patch that was submitted and, while a single config may seem logical to you, I think the Mesa devs are anticipating a scenario where OpenGL and Vulkan programs need different defaults defined.

          IMHO, I can see 3 possible scenarios: the current 00-mesa-defaults.conf should be renamed to 00-mesa-ogl-defaults.conf and a new 00-mesa-vk-defualts.conf created, a new type="graphics api" variable could be created like:
          Code:
          <application name="Civilization 6" executable="Civ6" type="OpenGl">
          <application name="Civilization 6" executable="Civ6" type="Vulkan">
          or take the existing defaults.conf and create separate OpenGL and Vulkan subsections.

          Personally, I'd rather have separate configs because throwing it all in one config file will result in one huge file that could become difficult to read and upkeep...though, with subsections, one file wouldn't be that bad if some of the boilerplate could be removed.

          From one AMD user to another -- thanks for trying to help us out.

          Comment


          • #6
            Originally posted by debianxfce View Post

            When an application does not work well with opengl freesync, it does not do that with vulkan freesync either. That is why a single config file is the best. We have tons of config files in the system already. It is simpler to have just one setting for an application and combine common things. This is called object oriented software design. https://en.wikipedia.org/wiki/Object...ed_programming

            Bas is a programmer who copy pastes new code only. A real pro reuses code as much as possible.
            I think the poster you were responding to was thinking of other settings that also might conflict for a given game in different APIs. Things like threaded shader compilation, force enabling extensions, enabling GL, threading, forcing AA/AF, etc, or tweaks to accommodate incompatibilities with the spec.

            Just because freesync probably would work the same doesn't mean all features will, especially the extension enabling.

            Comment


            • #7
              Originally posted by debianxfce View Post

              When an application does not work well with opengl freesync, it does not do that with vulkan freesync either. That is why a single config file is the best. We have tons of config files in the system already. It is simpler to have just one setting for an application and combine common things. This is called object oriented software design. https://en.wikipedia.org/wiki/Object...ed_programming

              Bas is a programmer who writes new code only. A real pro reuses code as much as possible.
              It's about more than just freesync. Things like AMD_DEBUG flags are set there too. It's very possible that a Vulkan game might need nir, it's OpenGL version doesn't, and now regardless of OpenGL or Vulkan they'd be reading from the same config that doesn't care what API the game uses.

              For a made-up example that is freesync, say there's a weird bug and Mad Max doesn't work with OpenGL freesync but it does with Vulkan freesync -- with one config file in its current state and if the Vulkan and OpenGL version have the same binary names, there would be no way for Mesa to determine if Mad Max should use freesync because all it does is check the filename -- that's where subsections, a new variable, and split configs could come into play. There's also Wine and DXVK/WineD3D to consider -- one is Vulkan, the other is OpenGL, both use the same file name.

              What you did by complete accident is show how the current config method is outdated.

              Comment


              • #8
                Originally posted by debianxfce View Post

                RADV uses nir only

                You do not need blacklist freesync for games, as you see in the current config file. Many games just do not activate freesync when you hope they do.
                I wasn't sure on the nir part due to seeing this at the bottom of the conf for Civ6.

                Code:
                <option name="radeonsi_enable_nir" value="true"/>

                I seem to recall something about nir becoming the default eventually, but I wasn't sure if that's actually happened since it's still labeled as experimental under R600_DEBUG=help with Mesa 19.
                Last edited by skeevy420; 17 April 2019, 09:08 AM.

                Comment


                • #9
                  Originally posted by debianxfce View Post
                  It is simpler to have just one setting for an application and combine common things. This is called object oriented software design. https://en.wikipedia.org/wiki/Object...ed_programming
                  No it is called code reuse.

                  Object Oriented programming is another unrelated thing.

                  Comment


                  • #10
                    But will XFCE on Debian support FreeSync with RADV?

                    Comment

                    Working...
                    X