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

    http://www.phoronix.com/scan.php?pag...oposed-Blocker

  • #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 humbug View Post
          Is it already working with amdvlk?
          AMDVLK does not support freesync.
          Last edited by debianxfce; 04-17-2019, 07:01 AM.

          Comment


          • #6
            Originally posted by kuco View Post
            Great news! Will FreeSync be usable with DXVK?
            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.

            Last edited by debianxfce; 04-17-2019, 07:17 AM.

            Comment


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


              • #8
                Originally posted by skeevy420 View Post
                Code:
                <application name="Civilization 6" executable="Civ6" type="OpenGl">
                <application name="Civilization 6" executable="Civ6" type="Vulkan">
                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.
                Last edited by debianxfce; 04-17-2019, 08:24 AM.

                Comment


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


                  • #10
                    Originally posted by Veerappan View Post

                    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.
                    RADV does not use those settings. Let us continue code and write bullshit and not have the 27 line radv freesync patch mainlined.

                    Comment

                    Working...
                    X