Announcement

Collapse
No announcement yet.

AMDVLK Radeon Vulkan Driver Updated With A Slew Of Additions

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

  • AMDVLK Radeon Vulkan Driver Updated With A Slew Of Additions

    Phoronix: AMDVLK Radeon Vulkan Driver Updated With A Slew Of Additions

    It had been more than two weeks since the last time AMD developers updated their public source trees making up the official AMDVLK Vulkan driver but unfortunately that has now changed. Given the time since the last commit, there is a lot of goodies with this new AMDVLK driver refresh...

    http://www.phoronix.com/scan.php?pag...K-Mid-Okt-2018

  • #2
    No transform feedback though?

    Comment


    • #3
      unfortunately?

      Comment


      • #4
        Originally posted by phoronix View Post
        Phoronix: AMDVLK Radeon Vulkan Driver Updated With A Slew Of Additions

        It had been more than two weeks since the last time AMD developers updated their public source trees making up the official AMDVLK Vulkan driver but unfortunately that has now changed...

        http://www.phoronix.com/scan.php?pag...K-Mid-Okt-2018
        @Michael: Why unfortunately?

        Comment


        • #5
          Originally posted by FireBurn View Post
          unfortunately?
          Whoops, meant 'fortunately'.... Early morning and busy as hell day today...
          Michael Larabel
          http://www.michaellarabel.com/

          Comment


          • #6
            Originally posted by tichun
            Do you think it will ever take off, or will we have both radv and amdvlk?
            Brother Celsius says unfortunately yes, while brother Fahrenheit fortunately no

            To be or not to be (in Mesa) - that is the question
            Last edited by dungeon; 10-19-2018, 06:39 AM.

            Comment


            • #7
              Originally posted by tichun
              Do you think it will ever take off, or will we have both radv and amdvlk?
              Considering we are talking about two projects doing the same job with no real difference in purpose or fundamental philosophy it should be obvious that one should be retried as the duplication of effort slows down driver development and causes unnecessary headaches for application developers. However the issue is that neither of them is going to be pushed into retiring their efforts and focusing on helping out the other very easily. Being developed by Mesa developers RADV is obviously going to be favored by much of the linux graphics driver community simply because of it's origins. AMDVLK is a common codebase project with the Windows driver and is what's going to be what Vulkan-using professional applications will be using due to the shared codebase and reluctance to add driver-specific codepaths for another driver, thus making an fglrx-type "unkillable" driver.

              Personally I've always considered RADV to be a temporary measure at best and an unnecessary duplication of efforts for the most part. We knew that AMDVLK was going to be open sourced and start receiving regular commits since RADV development started, meaning that it's development only made sense for as long as we were still waiting on AMDVLK being made open source. After that happened it's really just been an unnecessary duplication of effort driven by the developers' personal pride and paranoia of companies who haven't been dedicated to open source since the beginning.

              Comment


              • #8
                Originally posted by L_A_G View Post

                Considering we are talking about two projects doing the same job with no real difference in purpose or fundamental philosophy it should be obvious that one should be retried as the duplication of effort slows down driver development and causes unnecessary headaches for application developers. However the issue is that neither of them is going to be pushed into retiring their efforts and focusing on helping out the other very easily. Being developed by Mesa developers RADV is obviously going to be favored by much of the linux graphics driver community simply because of it's origins. AMDVLK is a common codebase project with the Windows driver and is what's going to be what Vulkan-using professional applications will be using due to the shared codebase and reluctance to add driver-specific codepaths for another driver, thus making an fglrx-type "unkillable" driver.

                Personally I've always considered RADV to be a temporary measure at best and an unnecessary duplication of efforts for the most part. We knew that AMDVLK was going to be open sourced and start receiving regular commits since RADV development started, meaning that it's development only made sense for as long as we were still waiting on AMDVLK being made open source. After that happened it's really just been an unnecessary duplication of effort driven by the developers' personal pride and paranoia of companies who haven't been dedicated to open source since the beginning.
                Wut?

                When RADV was available , there was no AMDVLK at all.

                So people should have waited for it instead of RADV? That leads Vulkan would be only available for Nvidia and Intel users.

                On a much bigger effect , DXVK simply wouldn't be there. So Linux would end up with only OGL in their hands like before.

                Comment


                • #9
                  Originally posted by L_A_G View Post

                  Considering we are talking about two projects doing the same job with no real difference in purpose or fundamental philosophy it should be obvious that one should be retried as the duplication of effort slows down driver development and causes unnecessary headaches for application developers. However the issue is that neither of them is going to be pushed into retiring their efforts and focusing on helping out the other very easily. Being developed by Mesa developers RADV is obviously going to be favored by much of the linux graphics driver community simply because of it's origins. AMDVLK is a common codebase project with the Windows driver and is what's going to be what Vulkan-using professional applications will be using due to the shared codebase and reluctance to add driver-specific codepaths for another driver, thus making an fglrx-type "unkillable" driver.

                  Personally I've always considered RADV to be a temporary measure at best and an unnecessary duplication of efforts for the most part. We knew that AMDVLK was going to be open sourced and start receiving regular commits since RADV development started, meaning that it's development only made sense for as long as we were still waiting on AMDVLK being made open source. After that happened it's really just been an unnecessary duplication of effort driven by the developers' personal pride and paranoia of companies who haven't been dedicated to open source since the beginning.
                  I think the problem is that since RADV had such a head start, by the time AMDVLK was released it was by far the inferior driver. It's less effort for developers like Feral, Valve or DXVK to get their software working in RADV and submit patches or fixes where necessary than to wait for AMD to fix AMDVLK, so until AMDVLK catches up there's little reason to drop RADV.

                  Comment


                  • #10
                    Originally posted by L_A_G View Post

                    Considering we are talking about two projects doing the same job with no real difference in purpose or fundamental philosophy it should be obvious that one should be retried as the duplication of effort slows down driver development and causes unnecessary headaches for application developers. However the issue is that neither of them is going to be pushed into retiring their efforts and focusing on helping out the other very easily. Being developed by Mesa developers RADV is obviously going to be favored by much of the linux graphics driver community simply because of it's origins. AMDVLK is a common codebase project with the Windows driver and is what's going to be what Vulkan-using professional applications will be using due to the shared codebase and reluctance to add driver-specific codepaths for another driver, thus making an fglrx-type "unkillable" driver.

                    Personally I've always considered RADV to be a temporary measure at best and an unnecessary duplication of efforts for the most part. We knew that AMDVLK was going to be open sourced and start receiving regular commits since RADV development started, meaning that it's development only made sense for as long as we were still waiting on AMDVLK being made open source. After that happened it's really just been an unnecessary duplication of effort driven by the developers' personal pride and paranoia of companies who haven't been dedicated to open source since the beginning.
                    there is not that much duplication.
                    As AMDVLK is essentially their windows driver, it can't be dropped, as you said yourself.
                    RADV is where currently most game-specific tuning is happening by valve and other developers.
                    A merge of the AMDVLK-PRO shader compiler would be nice though, as that is superior atm but NOT open source. So AMDVLK is not completely open source yet.
                    RADV could only be dropped if all game/perf tuning would be transported to AMDVLK and if the shader compiler would go open source and then this thing would need to be accepted by the wider community as supperior.

                    Comment

                    Working...
                    X