Radeon Software 18.20 vs. Mesa 18.2 RadeonSI/RADV Linux Driver Performance

[smitty3268]

The proprietary vulkan driver seems to be superior to RadV in terms of performance.

but very poor showing from AMD that 3 Vulkan games did not work: Thrones of Brittania, F1 2017 and Dawn of War. It's not like there are hundreds of Vulkan games to test with. These issues should have been ironed out..

The perf advantage comes from the proprietary shader compiler, and hopefully that's in the process of getting added into the LLVM open source one. Right now amdvlk is a lot like fglrx back in the day (sometimes fast, often buggy, limited support), and that's really not a good comparison for AMD. It looks like they are focused heavily on Vega there, because a lot of the bugs seem to affect only older hardware (older as in anything non-vega) so i could see amdvlk making sense for someone who just got a Vega 64 and wanted to max it out. Windows would probably make a ton more sense in that case, though.

[Tomin]

It seems rather daft to test AMDGPU Pro with the 4.15 kernel against 18.20 Mesa and the 4.17 kernel. Pair the Mesa 18.2 with the 4.15 linux kernel for a baseline.

I think it makes a lot of sense. With Mesa you want to use a recent kernel (at least I do but I'm running Fedora not Ubuntu) but AMDGPU-PRO probably doesn't support it. It wouldn't support even 4.15 if it wasn't for Ubuntu 18.04 LTS. It's also a fair comparison featurewise because AMDGPU-PRO bundles dkms kernel driver that is closer to 4.17 than 4.15, I think.

[Michael]

It seems rather daft to test AMDGPU Pro with the 4.15 kernel against 18.20 Mesa and the 4.17 kernel. Pair the Mesa 18.2 with the 4.15 linux kernel for a baseline.

AMDGPU-PRO doesn't build against Linux 4.17.... But only 4.15... Also, the PRO DKMS kernel module is a newer snapshot of what is likely either 4.17~4.18 DRM AMDGPU state.

[oleyska]

at this point I'm a bit unsure why we need radv for much longer but people seem to want it?
Like, another year to reach maturity for amdvlk but two seperate drivers doesn't seem beneficial for amd on Linux.
I've tested both and I faced no issues with either vulkan implementation on my vega at least.
If amd's open source is almost on point to 18.20 pro and community could contribute to it it'd be better ?

[humbug]

The perf advantage comes from the proprietary shader compiler, and hopefully that's in the process of getting added into the LLVM open source one. Right now amdvlk is a lot like fglrx back in the day (sometimes fast, often buggy, limited support), and that's really not a good comparison for AMD. It looks like they are focused heavily on Vega there, because a lot of the bugs seem to affect only older hardware (older as in anything non-vega) so i could see amdvlk making sense for someone who just got a Vega 64 and wanted to max it out. Windows would probably make a ton more sense in that case, though.

The biggest problem for amdvlk is that people are not using it, both consumers and developers. Very limited pool for bug reporting and feedback. The delay in Open sourcing it allowed RadV to become the default Vulkan driver for AMD users. Now devs also target that driver including the likes of Valve and Feral. So it's not surprising that some games don't work on AMD's own driver. Probably the devs didn't test it as they were Targetting RadV.

Wonder what AMD's plan is to rectify this situation...

[Azpegath]

Previously I've seen some signs that AMDGPU Pro takes the lead (especially for Vulkan-based games) when increasing fidelity to "High" or "Ultra" (depending on game), even though RADV is performing better for the more moderate settings.
Is this caused by anti-aliasing or do you have any other leads, airlied?

[humbug]

at this point I'm a bit unsure why we need radv for much longer but people seem to want it?
Like, another year to reach maturity for amdvlk but two seperate drivers doesn't seem beneficial for amd on Linux.
I've tested both and I faced no issues with either vulkan implementation on my vega at least.
If amd's open source is almost on point to 18.20 pro and community could contribute to it it'd be better ?

Yep ideally it would be nice if all the smart people were contributing to the same driver. But unfortunately the smart people at Red Hat and Valve work on RadV while the smart people at AMD work on amdvlk. Both sides have their reasons though, nobody is wrong, it's unfortunate but not an unusual thing in the Linux world.. 🙂

AMD has to maintain their own driver cause they need it for windows. But the rest of the community could not just sit and wait for AMD to open source it, so they came up with RadV and now they are heavily invested in that driver.

[wizard69]

I actually see this as a good thing. Smart people often do the samething in different ways. In the end that can lead to finding the best common way.

Beyond that im expecting more of AMD's driver to be open sourced. That should lead to the type of cooperation that benefits both parties. Also being a GPU driver i think it is safe to say that they are never truely done. Compare that to say a UART driverthat can remain stable for decades, with little maintenance.

I see no problem with two drivers at this point. Maybe they will converge when Vulkan, OpenGL and the like are frozen standards.

Yep ideally it would be nice if all the smart people were contributing to the same driver. But unfortunately the smart people at Red Hat and Valve work on RadV while the smart people at AMD work on amdvlk. Both sides have their reasons though, nobody is wrong, it's unfortunate but not an unusual thing in the Linux world.. 🙂

AMD has to maintain their own driver cause they need it for windows. But the rest of the community could not just sit and wait for AMD to open source it, so they came up with RadV and now they are heavily invested in that driver.

[mphuZ]

It's a huge shame that developers, Valve and Feral don't support the official AMDVLK driver.
RADV brings discord and misunderstanding among new developers and users of Linux.

[Faalagorn]

It would be nice to see the new tests with Basemark in addition to Unigine Superposition, as a (the only one?) synthetic Vulkan benchmark for Linux – though I don't think it's in Phoronix suite yet (though I think it support automation)?