Announcement

Collapse
No announcement yet.

RADV vs. AMDVLK vs. Radeon Software Vulkan Driver Performance - October 2018 Linux Gaming

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

  • #11
    Originally posted by humbug View Post
    Proprietary driver rocks performance wise. In general Vega has a reputation of not delivering on Linux (compared to it's windows performance). Seems like the proprietary driver goes some way in alleviating that.

    Those extremely bad vkmark numbers for RadV on vega: is it some application specific quirk or is it exposing some weakness in RadV?
    Proprietary drivers are specifically known to cheat on benchmarks. I wouldn't be at all surprised if this was the direct result of a bunch of binary specific optimization.

    Comment


    • #12
      Originally posted by duby229 View Post

      Proprietary drivers are specifically known to cheat on benchmarks. I wouldn't be at all surprised if this was the direct result of a bunch of binary specific optimization.
      cheat != optimization

      Comment


      • #13
        Originally posted by duby229 View Post
        I want to comment that Mesa development has taken years to come this far. And as such in comparison to earlier generations, Vega's performance and compatibility is actually really f-ing good. These performance numbers are likely due to a combination of compiler optimizations and binary specific optimizations. In some scenario's Vega on Radv may never achieve the same raw FPS as the proprietary driver. Looking at past history for precedence reminds me of the VLIW-4 architecture cards performance with the R600g driver. Really good drivers for really good cards but they never really did achieve their performance potential. The same thing may well be true for Vega, I don't know.
        I suspect that the problem might be due to the use of HBM2, previous AMD cards that used HBM also performed sub par. Maybe the problem lies with the increased latency of HBM(2) versus GDDR5?

        Comment


        • #14
          Why do we need RADV when we already have the official opensource implementation AMDVLK? RADV devs should just drop the development of it and help AMDVLK instead. There is no reason to have 2 opensource drivers and split efforts.

          All of this specially considering how the propietary driver is faster, they are in no position to affort reinventing the hot water with 2 opensource drivers.

          Comment


          • #15
            Originally posted by lucasbekker View Post

            I suspect that the problem might be due to the use of HBM2, previous AMD cards that used HBM also performed sub par. Maybe the problem lies with the increased latency of HBM(2) versus GDDR5?
            wrong, HBM has lower latency than gddr5

            Comment


            • #16
              Originally posted by davidbepo View Post

              wrong, HBM has lower latency than gddr5
              Could you point me to a source of that? a quick search didn't turn one up...

              Comment


              • #17
                Originally posted by lucasbekker View Post

                Could you point me to a source of that? a quick search didn't turn one up...
                gladly:

                https://techreport.com/review/28294/...ry-explained/2

                Comment


                • #18
                  Originally posted by edoantonioco View Post
                  Why do we need RADV when we already have the official opensource implementation AMDVLK? RADV devs should just drop the development of it and help AMDVLK instead. There is no reason to have 2 opensource drivers and split efforts.

                  All of this specially considering how the propietary driver is faster, they are in no position to affort reinventing the hot water with 2 opensource drivers.
                  You mean AMD shouldn't have even bothered with AMDVLK. RADV has a huge reason to exist, it doesn't rely on AMD. AMD fucked this up by not getting their driver released before Dave and Bas got too busy waiting with all the tools in front of them already.

                  RADV will continue to exist, and probably will replace all of AMD's efforts because of how long it took to get them out. Just like Mesa is in general compared to any proprietary driver.

                  Comment


                  • #19
                    Originally posted by abott View Post
                    You mean AMD shouldn't have even bothered with AMDVLK
                    only idiot could mean that amd should't bother writing driver for 99% of their windows customers

                    Comment


                    • #20
                      i wonder whether it was serious sam optimized for radv, or radv optimized for serious sam

                      Comment

                      Working...
                      X