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

[puleglot]

Those extremely bad vkmark numbers for RadV on vega: is it some application specific quirk or is it exposing some weakness in RadV?

RADV with drm-next looks good:
https://www.phoronix.com/scan.php?pa...next-420&num=3
I wonder how these drm changes affects AMDVLK and PRO performance.

[jrch2k8]

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.

Hell no, RADV should stay and AMDVLK should go(assuming the idea that only 1 vulkan FOSS driver should exist), besides don't get cheated thinking AMDVLK is better because in few handpicked games seems to be barely faster because in reality it fails a freaking lot specially with thing like DXVK(and other Vulkan games/apps like MPV) plus is very unlikely that it will handle properly Integration with OpenGL 4.6(SPRIV side) with Mesa, Whereas RADV integrates damn well with Mesa already, share a lot of code with intel ANV(WSI+NIR+SPIRV side of things) and will prolly handle really well OpenGL 4.6 integration that is already very advanced(bunch of patches pending on patchworks) for both Intel and RadeonSI(NIR wise).

Additionally RADV works like a charm in most AMD GPUs even on GCN 1.0(My TAHITI card works flawlessly for example) where AMDVLK seem to behave properly mostly on Polaris and VEGA(even tho still fails a lot outside few games)

Also code wise RADV is a lot cleaner(and a lot more supervised by community people like Super Marek, Bas, timothy, jason, samuel, etc.) than AMDVLK where you mostly get huge patches every now and then without much community input(or at all)

[humbug]

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.

How can it replace all of AMD's efforts, it doesn't work on windows. AMD's vulkan driver is derived from a cross platform code base by design.

the key difference with the mesa openGL drivers is that AMD is a key contributer to them. The problem now with the vulkan ecosystem is that the devlopment talent across AMD, Red Hat, Valve etc is split between two different drivers duplicating effort for the same hardware. And a big problem is nobody is using AMD's driver, RadV became the defacto driver cause we couldn't just wait around for amdvlk.

[juno]

Why do we need RADV when we already have the official opensource implementation AMDVLK?

Why do we need AMDVLK when we already had radv a long time ago?

only idiot could mean that amd should't bother writing driver for 99% of their windows customers

AMDVLK != amdgpu-pro Vulkan driver != Windows Vulkan driver.

the devlopment talent across AMD, Red Hat, Valve etc is split between two different drivers duplicating effort for the same hardware. And a big problem is nobody is using AMD's driver, RadV became the defacto driver cause we couldn't just wait around for amdvlk.

I haven't seen anyone from RedHat (or anything else) contribute to AMDVLK. And I don't think it's attractive for any community dev to contribute to it when there is radv in Mesa.

Also, radv is more efficient on the CPU side and it can still benefit in GPU performance from open-sourced AMDVLK.

[M@yeulC]

AMD is currently working on improving their opensource compiler, which should benefit both AMDVLK and RADV, so argumenting about which one is better/gets more love is kind of besides the point.

I would like to see RADV ported to Windows, at some point, if that's possible. The good thing is that AMD should be using a driver interface quite similar to the one of the first DAL (DC) code drop.

[oleid]

AMDVLK != amdgpu-pro Vulkan driver

Afaik the most important difference is the shader compiler. The rest is basically the same.

[aufkrawall]

Well, at least amdvlk seems to be getting faster, it was terribly slow in some older benchmarks. They also seem to be committed to fix app issues, so let's not bash them for providing a good FOSS driver...

[GruenSein]

No company in their right mind will ever go Mesa only. The reason for this has been made obvious. They cannot make themselves dependent on some outside maintainer who might block their feature work for months if not years as we saw happening with DAL. Yes, there may have been good reasons for it but for AMD it doesn’t matter that much, how well their code integrates with the rest of the Mesa codebase, that supports competing hardware. They need to be able to deliver their hardware features ASAP on their own terms. Additionally, it does not make sense to support a driver which is not supported on their main selling plattform (Windows). I think, the Linux community should be very happy that AMD is providing all the complex modules of a driver as open source (such as the kernel driver, the compiler etc.). Without this, RADV wouldn’t have been possible. So, RADV might be a good driver but AMDVLK is not going to go away any time soon. Any push to unite AMD Vulkan driver efforts can only be based on AMDVLK. Unfortunately, I don’t expect this to happen.

Also, the long wait until AMDVLK went open source was certainly not in their interest but is far from a screw up. This community just needs to realize that from AMD‘s perspective, it was not a big priority and didn’t justify the cost of putting more manpower behind it

[pal666]

AMDVLK !=amdgpu-proVulkan driver != Windows Vulkan driver.

they are written by same people. so the only way to "not bother" is to not release windows driver
and that's ignoring such little uninteresting detail as code flowing from amdvlk to radv (via radeonsi until release)

I haven't seen anyone from RedHat (or anything else) contribute to AMDVLK. And I don't think it's attractive for any community dev to contribute to it when there is radv in Mesa.

so what? how does it make for "amd shouldn't bother releasing windows driver while redhat and anything else spent several man-years to duplicate slower driver"?

Also, radv is more efficient on the CPU side and it can still benefit in GPU performance from open-sourced AMDVLK.

you can't have it both ways. if amd wouldn't release it, radv wouldn't benefit from it

[smitty3268]

they are written by same people. so the only way to "not bother" is to not release windows driver

That's not true. A lot of effort went into the amdvlk release, where AMD had to refactor their driver to allow them to opensource it. At least, that's what bridgman always says took them so long. They may be mostly the same these days, but that wasn't the case with what existed when they started working on amdvlk.