Mesa RADV vs. AMDVLK Radeon Vulkan Performance For July 2021

[tomas]

arQon

"Do you imagine that if - ie when - something goes wrong with a game on Stadia because of a driver problem, Google will pull the game, file a ticket on GitHub, and just sit back and jerk off for a few weeks while the bug gets looked at, fixed, and eventually rolled out into a new release the following quarter?"

No, why would they do that? Either they could put in resources themselves to fix the bug or performance problem in RADV or they could hire someone to do it for them like Colabora:

https://www.collabora.com/about-us/our-expertise.html

Or some other software consulting company with expertise in Mesa.

[tomas]

arQon

BTW, if what you say would be true, that Google are completely incompetent and unable to fix problems themselves in open source thus "file a ticket on GitHub, and just sit back and jerk off...",
then Android would not be based on the Linux kernel and ChromeOS especially would not exist.

[Venemo]

I'm using the unofficial Kisak build of mesa so cannot file a bug for the official version since I have never run that.

Feel free to report bugs in mesa. This is fine, just mention which version you use.

[Venemo]

I've found some graphical corruption issues with RADV in some games and had to use AMDVLK ICD.

While performance can be great there are still some issues under the hood with radv.

Please open a bug report in the mesa issue tracker for each game issue you find. We can only fix issues that we know about. Thank you.

[aufkrawall]

Don't like AMDVLK, don't use it. No one is forcing you to.

Well, on Windows you are actually forced to use the -pro driver with API wrappers, as AMD's D3D11 driver is bad and D3D9 driver terrible.

[chocolate]

Perhaps RADV is simply more catered to translation layer scenarios. AMDVLK seems to work fine in native titles that behave like any Vulkan-native code should.

Does LLVM still lose to ACO when shaders are pre-compiled?
What is the shader format Steam uses when downloading shader pre-caching content? How can automatic shader compilation be handled with separate drivers, if an alternative ICD is present? Do you just launch Steam with an appropriate environment variable?

Is there a benchmark that lets us test whether AMDVLK+LLVM produces "better" shaders than RADV+ACO when compile time doesn't matter?

Bottom line is: thanks to everyone involved! I bought an AMD GPU precisely to let it shine on GNU/Linux and I'm happy with Mesa. Just curious about the technical merits of each option.
Cheers and happy gaming to everyone.

[aufkrawall]

Perhaps RADV is simply more catered to translation layer scenarios. AMDVLK seems to work fine in native titles that behave like any Vulkan-native code should.

Also native Vulkan games regress an awful lot with amdvlk-open. I suppose Michael's benchmark systems have rather populated DXVK state caches, so ACO doesn't boost the avg fps much due to CPU shader compile time. When it is faster, it is mostly so because the generated shader binaries are actually better than amdvlk-llvm's.

When something doesn't work that works with other drivers, it's a foul excuse that this is due to the different intended use cases for a driver. RADV ACO suits most things well, as does the Nvidia driver (yes, I haven't yet seen a single case of visual corruption in any game I throw at Nvidia with DXVK/VKD3D-Proton and current Ampere drivers, and it has of course much faster shader compile times than amdvlk-pro...).

[user1]

Perhaps RADV is simply more catered to translation layer scenarios. AMDVLK seems to work fine in native titles that behave like any Vulkan-native code should.

Even when AMDVLK works properly (doesn't regress), Radv/ACO still outperforms it in many cases in native Vulkan games.

[chocolate]

Also native Vulkan games regress an awful lot with amdvlk-open. I suppose Michael's benchmark systems have rather populated DXVK state caches, so ACO doesn't boost the avg fps much due to CPU shader compile time. When it is faster, it is mostly so because the generated shader binaries are actually better than amdvlk-llvm's.

When something doesn't work that works with other drivers, it's a foul excuse that this is due to the different intended use cases for a driver. RADV ACO suits most things well, as does the Nvidia driver (yes, I haven't yet seen a single case of visual corruption in any game I throw at Nvidia with DXVK/VKD3D-Proton and current Ampere drivers, and it has of course much faster shader compile times than amdvlk-pro...).

Thank you! I went through the results again. You're right, there are Linux-native titles such as SotTR showing signs of CPU bottlenecks with AMDVLK that go away at 4K max settings when the game becomes more GPU-bottlenecked. The strangest one is The Talos Principle. It's both native to Linux and has a dedicated Vulkan renderer that is written from scratch, no? And yet AMDVLK kind of tanks there. While Feral ports can't be pinned down to a particular Vulkan implementation technique.

Strange Brigade with its Vulkan renderer is kind of a mixed bag in terms of min/max frames per second between AMDVLK and RADV, while AMDVLK comes on top in every average regardless of detail settings. Makes you wonder what is going on with all these engines and which parts of a Vulkan driver they seem to exercise more.

I agree, RADV+ACO suits most things well and that's why I'm happy with not tinkering with my gaming setup and am happy with Mesa as stated previously. Cheers!

Even when AMDVLK works properly (doesn't regress), Radv/ACO still outperforms it in many cases in native Vulkan games.

Had a deeper look at it. Thanks!

[user1]

and it has of course much faster shader compile times than amdvlk-pro...).

Does that mean Nvidia's shader compiler has comparable performance to ACO?
I don't have Nvidia, but from my own testing of the three compilers, the pro compiler is much closer to ACO than LLVM in compile time performance.