AMDVLK 2019.Q4.2 Brings Several More Extensions, Game Tuning

[bridgman]

RADV is the community Vulkan Driver started before AMD have any open source support for Vulkan on Linux

Minor correction above...

[jrch2k8]

Minor correction above...

Thanks i forgot AMDGPU-PRO existed at that time.

[Marc Driftmeyer]

Basically, this is what happened:

1. AMDVLK is the official AMD opensource vulkan driver but it took way too long to release and by that time the community created RADV and was already in excellent shape.
2. RADV is the community Vulkan Driver started before AMD have any support for Vulkan on Linux.
3. AMDGPU-PRO basically AMD closed(ISH) driver for Linux and is basically meant for Enterprise and Enterprise Distros like RedHat(it can work on other distros of course)

What should you use?:

1. RADV is the best of the lot and is the official driver that Valve and Co uses for testing, also the official driver used by DXVK/D9VK devs on AMD. Also usually receive bug fixes very very fast from a huge miriad of developers and is integrated on Mesa and available OOB. If you want the faster compiler for games just export RADV_PERFTEST=aco and that is all(you need Mesa 19.2+)
2. AMDVLK it goes from totally broken to somewhat useful in some games/GPU depending the release version, Only developed by AMD developers, very broken for DXVK/D9VK in a huge list of games, not tested by anyone by default, huge delays on bug fixes BUT with some GPUs it may help until RADV catch up but i usually don't find it worth it because is very annoying to switch back and forth and usually RADV catches up very fast.
3. AMDGPU-PRO honestly haven't bothered too much with it and last time i tried was extremely broken for 100% of my DXVK/D9VK games and my Native Vulkan games have all kind of issues as well but could have changed at some point. To be fair this driver is meant for Enterprise operation not gaming.

Rule of thumb for an easy live:

USE MESA's RADV/RADEONSI, that's it. for 99.99% of the case is the best driver hands down.

Compute Rule of Thumb

Install all the LLVM packages and a bare minimum set of packages by hand from the AMDGPU-PRO stack to get OpenCL cranking out in Blender. ROCm is a bag of hurt for that.

[ermo]

So in summary, AMDVLK has basically become something thrown over the fence for the RADV devs to inspect and the rest of us to ignore or frown at? Sort of a 'driver resource' or 'documentation' more than a driver anyone really expects to work?

If this is the case, perhaps someone can shed some light on why the people in charge of AMD driver decisions curiously don't seem to 'get' the benefits of a true 'open development' model as Dave Airlie put it...? What other factors might influence such a decision? Vendor control and cadence?

[skeevy420]

So in summary, AMDVLK has basically become something thrown over the fence for the RADV devs to inspect and the rest of us to ignore or frown at? Sort of a 'driver resource' or 'documentation' more than a driver anyone really expects to work?

If this is the case, perhaps someone can shed some light on why the people in charge of AMD driver decisions curiously don't seem to 'get' the benefits of a true 'open development' model as Dave Airlie put it...? What other factors might influence such a decision? Vendor control and cadence?

From AMD's perspective, it's an open source driver that they have 100% control over and can do whatever they want with whereas the Mesa driver isn't necessarily the case.

Here's the Mesa license table:

Main Mesa code    src/mesa/              MIT

Device drivers    src/mesa/drivers/*     MIT, [B]generally[/B]

Gallium code      src/gallium/           MIT

Ext headers       include/GL/glext.h     Khronos
                  include/GL/glxext.h

GLX client code   src/glx/               SGI Free Software License B

C11 thread        include/c11/threads*.h Boost ([B]permissive[/B])
emulation

It's those "generally" and "permissive" parts may cause issues with closed source drivers they have on Linux, Windows, Xbox 1, PS4, the next gen consoles, etc and having AMDVLK rids them of any such worry.

[BNieuwenhuizen]

From AMD's perspective, it's an open source driver that they have 100% control over and can do whatever they want with whereas the Mesa driver isn't necessarily the case.

Here's the Mesa license table:

Main Mesa code src/mesa/ MIT

Device drivers src/mesa/drivers/* MIT, [B]generally[/B]

Gallium code src/gallium/ MIT

Ext headers include/GL/glext.h Khronos
include/GL/glxext.h

GLX client code src/glx/ SGI Free Software License B

C11 thread include/c11/threads*.h Boost ([B]permissive[/B])
emulation

It's those "generally" and "permissive" parts may cause issues with closed source drivers they have on Linux, Windows, Xbox 1, PS4, the next gen consoles, etc and having AMDVLK rids them of any such worry.

Not sure that'd be really an issue. src/mesa/drivers contains nothing AMD would ever ship in binary form (just some legacy drivers you can disable during build time), and Boost is a permissive license like MIT (and you can build without if you have a C11 compiler which I hope everyone does these days ...).

(not saying there won't be other potential skeletons in the closet. I personally find the entire SGI software licensing stuff quite confusing at times myself)

[mphuZ]

so you need so many drivers to play 1 game?

Only one. But AMD and Valve cannot agree.

[skeevy420]

Not sure that'd be really an issue. src/mesa/drivers contains nothing AMD would ever ship in binary form (just some legacy drivers you can disable during build time), and Boost is a permissive license like MIT (and you can build without if you have a C11 compiler which I hope everyone does these days ...).

(not saying there won't be other potential skeletons in the closet. I personally find the entire SGI software licensing stuff quite confusing at times myself)

It's the best guess that I have -- something that's 100% theirs for all their proprietary needs -- because there aren't that many reasons that make sense outside of lawyers and licenses and proprietary, oh my (especially with how open source and Linux friendly AMD is).

I suppose bridgman or agd5f may be able to answer "Why AMDVLK?" better, but "100% theirs with no legal worries" is the most logical.

Personally, I like multiple options from multiple sources. If you're playing a game with an Nvidia GPU and it doesn't work, that's it. If you're playing a game with an AMD GPU, you have a few more things to try before giving up as well as you can report to a project like DXVK that one works and one doesn't which can potentially help due to having two open source drivers to reference to see how they're doing things.

[aufkrawall]

It's quite ironic that SotTR just crashes for me with amdvlk-open, while the changelog of the new version is advertising improvements for the older RotTR. Meanwhile, it just runs on radv and even months old amdvlk-pro without issues.

[bridgman]

So in summary, AMDVLK has basically become something thrown over the fence for the RADV devs to inspect and the rest of us to ignore or frown at? Sort of a 'driver resource' or 'documentation' more than a driver anyone really expects to work?

If this is the case, perhaps someone can shed some light on why the people in charge of AMD driver decisions curiously don't seem to 'get' the benefits of a true 'open development' model as Dave Airlie put it...? What other factors might influence such a decision? Vendor control and cadence?

This question comes up a couple of times a year.

If you think of AMDVLK as just an open source Vulkan driver for Linux then it seems obvious that a fully open development model would make sense. The point though is we're not talking about just a Linux Vulkan driver - AMDVLK+PAL is a periodic open source extract from a larger (closed source) code base that supports multiple OSes and multiple APIs, some of which we can't even talk about let alone expose.

The question then becomes something more like "would it make sense for AMD to fork AMDVLK away from the common code and maintain it independently just for Linux Vulkan ?" and so far the answer to that question has been "no".