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

  • pal666
    replied
    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

    Leave a comment:


  • abott
    replied
    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.

    Leave a comment:


  • davidbepo
    replied
    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

    Leave a comment:


  • lucasbekker
    replied
    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...

    Leave a comment:


  • davidbepo
    replied
    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

    Leave a comment:


  • edoantonioco
    replied
    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.

    Leave a comment:


  • lucasbekker
    replied
    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?

    Leave a comment:


  • davidbepo
    replied
    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

    Leave a comment:


  • duby229
    replied
    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.

    Leave a comment:


  • duby229
    replied
    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.

    Leave a comment:

Working...
X