RADV vs. AMDVLK Vulkan Drivers Continue Stiff Performance Battle

[M@GOid]

I'm going to reiterate what I said before. I do not like having 2 drivers for the same thing. Yes they are OSS both, yes they can be "swapped at runtime" even. Yes they create competition.

But they also create confusion. Everyone seems to be forgetting about game developers/porters who are already facing a big mess when it comes to linux (which distro? X11 or Wayland? which cards?)

Now they get another 2x to the already 100+ choice matrix to fill in and continue monitoring. "Your recently AAA ported title will work on Ubuntu version X nvidia and maybe AMD but we're not sure if RADV or AMDVK". Or maybe just "Nvidia only".

Right now AMDVK is having the same problem fglrx had several years ago: people are developing with a target at the other driver and theirs did not get optimizations on games. To make things worse, they didn't have a easy way to dumb users like myself to deploy it on their distros and, to add insult to injury, they did not have a good way to receive contributions on AMDVLK right now.

Or AMD take action right now to fix things, or they will see people adopting the other driver more and more to the point of no return. Valve and Feral are not contributing to AMDLVK. That is a good thing for AMD to correct first.

[SethDusek]

I'm going to reiterate what I said before. I do not like having 2 drivers for the same thing. Yes they are OSS both, yes they can be "swapped at runtime" even. Yes they create competition.

But they also create confusion. Everyone seems to be forgetting about game developers/porters who are already facing a big mess when it comes to linux (which distro? X11 or Wayland? which cards?)

Now they get another 2x to the already 100+ choice matrix to fill in and continue monitoring. "Your recently AAA ported title will work on Ubuntu version X nvidia and maybe AMD but we're not sure if RADV or AMDVK". Or maybe just "Nvidia only".

Maybe if they follow the vulkan spec properly instead of doing driver-specific hacks, that AAA game will work fine on pretty much any driver?

[nomadewolf]

So, it seems it's basically like this:
1080p > RADV
4K > AMDVLK

[MagicMyth]

I get where AMD is coming from with wanting to share their driver across platforms. Generally this makes the most sense as you can say that doing this means on a given platform you get 90% of the work done already with the other 10% covering the platform specific bits. Normally this makes sense but on the Linux ecosystem you now have a very well developed driver framework (Mesa) that seems to have 90% of what is needed for a Vulkan driver already there just wanting to be glued together as evidence by the early lion share of development for Radv being done by just two devs and with it being in the open from day 1 a few other regulars are also contributing to it.

Sharing a code base is all about saving man hours at the end of the day. However, in this situation you have to wonder which saves more time? A platform shared codebase (AMDVLK) or using a platform's mature framework (Mesa)? Going by how far Radv has come on such limited dev power I would say AMD should seriously consider re-tasking its Linux devs onto Mesa and save themselves some effort.

Still this situation is sooooo much better than what we had a decade ago!

[humbug]

Looks like RadV is stronger in lower resolutions when CPU limited.
amdvlk is often ahead at 4K.

AMD's comments on their github page suggest that there are upcoming performance improvements for both CPU limited and GPU limited scenarios

https://github.com/GPUOpen-Drivers/AMDVLK

Gonna be a fun battle going forward.

To make things worse, they didn't have a easy way to dumb users like myself to deploy it on their distros

This should be a priority for AMD. Get people using their Vulkan driver in popular distros somehow... Right now everybody just uses RadV.
amdvlk seems to be improving nicely, but it also needs a userbase.

[humbug]

The competition shows where each driver can be improved - perhaps this naturally originated competitive situation is better than at first sight.

Maybe it is, I can never make up my mind on this.
Sometimes I think the competition is good.
But then I also think about the potential combined talent pool where if you had the AMD devs, Red Hat guys, Valve guys, and Feral all working on the same driver would we have a driver that is better than either?

[Herem]

From these Vulkan Linux gaming tests today, the RADV driver overall remains faster than the official AMDVLK driver most commonly when running at 4K and in other more CPU bound scenarios. However, at 4K and in the more GPU-demanding environments is where RADV does tend to perform about the same as AMDVLK or sometimes better, particularly with the newer Vega GPU.

@Michael the first couple of sentences of the last paragraph don't seem to make sense, I think it was meant to read something like:

The results of today's Vulkan Linux gaming tests show that at 1080p and in more CPU bound scenarios the RADV driver usually outperforms the official AMDVLK driver; however, at 4K and in more GPU-demanding scenarios AMDVLK's performance is generally comparable and in some cases better than RADV, particularly with the newer Vega GPU.

[humbug]

Herem is correct

[tomtomme]

I get where AMD is coming from with wanting to share their driver across platforms. Generally this makes the most sense as you can say that doing this means on a given platform you get 90% of the work done already with the other 10% covering the platform specific bits. Normally this makes sense but on the Linux ecosystem you now have a very well developed driver framework (Mesa) that seems to have 90% of what is needed for a Vulkan driver already there just wanting to be glued together as evidence by the early lion share of development for Radv being done by just two devs and with it being in the open from day 1 a few other regulars are also contributing to it.

Sharing a code base is all about saving man hours at the end of the day. However, in this situation you have to wonder which saves more time? A platform shared codebase (AMDVLK) or using a platform's mature framework (Mesa)? Going by how far Radv has come on such limited dev power I would say AMD should seriously consider re-tasking its Linux devs onto Mesa and save themselves some effort.

Still this situation is sooooo much better than what we had a decade ago!

But amdvlk is largely Amds windows driver. Only very limited manpower is needed to drop the new windows Vulkan driver code every week once the Linux build system for the driver was up and running. Legal review was likely what took them so long

[tomtomme]

Guys. Most of you seem to forget that amdvlk has a big userbase on windows.