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

[duby229]

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.

[davidbepo]

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

[lucasbekker]

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?

[edoantonioco]

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.

[davidbepo]

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

[lucasbekker]

wrong, HBM has lower latency than gddr5

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

[davidbepo]

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

gladly:

https://techreport.com/review/28294/amd-high-bandwidth-memory-explained/2

[abott]

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.

[pal666]

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

[pal666]

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