Happy Holidays: AMD Finally Pushing Out Open-Source Vulkan Driver

[schmidtbag]

At least for few months I expect whining in some distros because X or Y game is faster on X or Y driver but in the end I expect RADV for desktops like RadeonSI did for OpenGL(due to tighter integration) and AMD Vk to thrive on enterprise distro that are way too far behind on mesa releases to have proper RADV support(like Centos/Rhel).

Outside making RADV development faster I don't expect this Vulkan driver to change the status quo this late in the game, specially because I just don't see jimmy the noob user to go out of his way to install another vulkan driver when stuff just work OOB with any recent enough distro

I completely agree with this. As I said before, for now RADV still makes for a good alternative.

[jf33]

As there's a vulkan-icd-loader that allows multiple Vulkan implementations to co-exist on the same machine, I'm wondering whether it's possible to install both AMD's Vulkan driver and RADV in parallel. One could then decide on a per-application basis which driver to use.

[Sethox]

As regular desktops users (not using AMDGPU-PRO) that wants a Vulkan driver will be using RADV, everyone can agree on that.
But is there a way where people can start thinking that no matter what, AMD did open source their Vulkan code.. which means that EVERYONE can take a look at the code. Since it's official we can expect some improvement on the unofficial Vulkan driver. I have not seen the code myself (on either side) but at least it's open source and "SOME GUIDANCE" of sorts.

It's duplicated projects but on different needs/perspectives so why bother whining about that. In the end of the day we as users can now easily see how the code works on either side without thinking it's magic, post issues/suggestions, wait until people change it (or not) and have an alternative choice. It's understandable why people are cynical but there is no downside to this, just time and effort (AMD or RADV).

[sa666666]

It's not really duplication of effort, since the people working on RADV probably wouldn't be working on the AMD codebase anyway. At least now each side can learn from the other. Personally I hope RADV becomes the dominant one, and gets optimizations/ideas from AMD Vk. But if the latter ends up being better in most cases compared to RADV, I would have no trouble switching either. They're both open source, so there's that. My main concern going forward is which one will continue to be maintained.

And above all, I'd like to see benchmarks

[DrYak]

…the code they are pushing out was stripped down to just their Linux code
…and they will support third-party contributions to their driver

This calls a very important question that I hope bridgman and co could answer :
- What exactly was stiped down ?
- More precisely: how does the tree that will get published on github relate to the tree on the harddisk of devs at AMD ?
The future development of vulkan support on AMD hardware depends on it.

If this open-source drivers is basically the same code as Windows, etc. and the only reason it's not possible to rebuild the Windows driver is because, just like the Linux drivers needs to call into libdrm, amdgpu and llvm, the Windows driver needs to call into lower level component that aren't availble...
- i.e.: basically - you could compile "amd_vulkan.dll" but it won't work because you need several lower-level component which aren't on github (basically, whatever is the equivalent of libdrm on windows - "wddm" or whatever).
Then there is chance that it will also see development by the community and will get broader audience.
With some distros deciding to switch to that drivers instead of RADV.
And perhaps eventually one of the two drivers becoming dominant on the market, or perhaps various distro being split 50:50 among which is installed by default (and Gentoo and Arch advertising that you can very easily use either).

If this is only a sub-part of the whole driver, if it's a set of only those files of the vulkan drivers that are specifically need for Linux and any Windows specific part cut-out..
- i.e.: basically, only the files that are dependencies of "libamd_vk.so" are included on github, and you cannot even try to compile "amd_vulkan.dll" because the files aren't even there and several of the "#if / #ifdef" macros have been "flattened"-out before pushing to github.

Then this is going to be an obstacle. With any commit to github needing first to be remerge back into the "more full" upstream branch, and tested to see if it doesn't break the windows side.
Meaning that sending pull-request for Linux from the community are going to require some work for AMD, (and pull-request for Windows aren't even possible).
Meaning that the opensource Linux version is going to lag feature-wise to what's packaged inside the binary drivers (Linux's AMDGPU-PRO and official Windows drivers).

At that point, that "AMDVk" driver is probably going to only be used in AMDGPU-Pro only, with all the distros sticking to RADV, and only using the official driving for inspirations for what to optimise in radv.

Basically what jrch2k8 is suspecting.

On the other hand, maybe the official opensource driver is designed to play nicely along other "clients" of the amdgpu/libdrm stack. (After all, it's designed to play nicely with AMDGPU-PRO's GL library), and perhaps could play nicely while mesa is running.
Thus making it possible to run the official AMD vulkan together with mesa opensource openGL.
Thus people installing both RADV and the official and using tricks like "LD_PRELOAD" to select which to use before starting any game (depending on which game performs better with which driver).

[shmerl]

As there's a vulkan-icd-loader that allows multiple Vulkan implementations to co-exist on the same machine, I'm wondering whether it's possible to install both AMD's Vulkan driver and RADV in parallel. One could then decide on a per-application basis which driver to use.

You can simply use environment variable to point out which driver to pick. See VK_ICD_FILENAMES.

[theriddick]

The 17.40 Vulkan vs. RADV benchmarks will be up shortly

Nice, was there much change in 17.50? probably not. It will be good to see the performance differences between the vulkan drivers, I would much love it if they would rob performance code from each other so we can get a ultimate Vulkan driver like what NVIDIA have with their great performance atm.

[Michael]

Nice, was there much change in 17.50? probably not. It will be good to see the performance differences between the vulkan drivers, I would much love it if they would rob performance code from each other so we can get a ultimate Vulkan driver like what NVIDIA have with their great performance atm.

Vulkan 17.50 changes are outlined in: https://www.phoronix.com/scan.php?pa...eonSI-Features

Yes the 17.50 vs. RADV/RadeonSI results coming in the next few hours will have such tests.

[microcode]

Hope it's license-compatible with Mesa, that way you could basically look at individual pieces in it and pluck out the relevant code directly (then massage it into Mesa). Not sure how useful this would necessarily be, but if it is useful, it would be nice to have license alignment.

[Adarion]

Well. Now that will be interesting to see what the next weeks / months will bring.
It's good that it is done, eventually.

Now it is to hope that - if that is reasonably possible - the drivers (RADV and Radeon Open Vulkan) will merge to a certain extent. Having two drivers for the same purpose... um, sounds like a waste of precious development power.