AMDVLK vs. RADV Radeon Vulkan Driver Performance For Linux Gaming On Ubuntu 19.04

[Ashark]

The proprietary AMD Vulkan driver wasn't tested this round since Radeon Software (AMDGPU-PRO) isn't yet supported by Ubuntu 19.04 nor is it likely to be supported soon since AMD doesn't tend to support the non-LTS releases these days with their hybrid driver model.

I have made it possible to install amdgpu-pro in Ubuntu 19.04 with this script: https://bugs.freedesktop.org/show_bug.cgi?id=110795
Also, see this video on how to install it: https://youtu.be/97fj4bGJxVM
However, I did not tested it with vulkan yet. You may try it and if it succeeds, add comparison results to the article.

[boxie]

Definitely see benefit here, and it does get discussed between HW vendors and distros from time to time. A few people have tried leading the initiative at various times (including us IIRC) but everyone seems to get sucked back into more urgent work before being able to get very far.

It would be a great topic for the next XDC... which IIRC is actually in Canada this year.

EDIT - yep - Montreal, Oct 2-4. Everyone is going to have to learn how to speak Canadian.

Ay? Sorry! </canadian>

It certainly would be a good talk to watch / discussion to be had!

[bridgman]

Do you see any benefit in some sort of common initiative to get the latest and greatest out to the desktops and can you see AMD leading this effort?

Definitely see benefit here, and it does get discussed between HW vendors and distros from time to time. A few people have tried leading the initiative at various times (including us IIRC) but everyone seems to get sucked back into more urgent work before being able to get very far.

It would be a great topic for the next XDC... which IIRC is actually in Canada this year.

EDIT - yep - Montreal, Oct 2-4. Everyone is going to have to learn how to speak Canadian.

[boxie]

Try my distribution before you judge it. Many people have liked it.


A rolling release OS with latest possible GPU drivers is the way to go.



There are hundreds of Linux distributions. AMD binary packages are for the most popular distributions.

again, you are missing the point. I am not after each distro implementing some bespoke variation of driver choice.

I am looking at the whole ecosystem.

I want (those that want to) to adopt a common strategy towards gaming by the industry and distros so that we always have the latest and greatest features supported.

AMD release windows drivers more than once a month, these drivers come with fixes and optimisations. The current development models do not allow for this.

[boxie]

You can create and use a distribution that is up to date with Debian simple-cdd easily. https://www.youtube.com/watch?v=fKJ-IatUfis

That's not what I want. That's not what my gamer mates want. It is certainly not what Joe Public wants.

At most I want to be presented with a choice of "Best Performance and newest features" or "Long Term Stability".

Yes, I know that distro's would need to get on board - but first there needs to be a common graphics setup that all distros can pull from.

[boxie]

The challenge is that the Vulkan driver supports multiple OSes and the core code (PAL) supports multiple APIs as well, some of which more-or-less require closed source, so having the master copy in Mesa would be tricky. It would require agreement to use Mesa for all the other OSes as well, which does not feel very likely at the moment.

Splitting the problem into three parts makes answering the question easier - maybe, no and yes:

Vulkan API layer - supports multiple OSes but not multiple APIs so not too closely tied to the HW. Changes relatively slowly (new extensions/versions) so not impossible to maintain a separate Linux-specific copy in Mesa, and in the meantime OS differences have largely been abstracted out already and we only publish the Linux bits.

Hardware layer (PAL) - supports multiple OSes and multiple APIs - APIs are much harder to abstract out than OSes because they end up having to be visible all the way down to the code banging on HW. Maintaining a separate Linux-specific copy in Mesa with identical behaviour looks to be quite expensive.

Shader compiler - any non-LLVM bits could probably be maintained in Mesa fairly easily and we are constantly pushing updates to llvm upstream - probably the easiest to make community friendly (and arguably mostly there already) although "upstream" in this case is llvm rather than mesa.

As always the tradeoff is between perceived benefits from code sharing via abstraction layers (over-rated in most cases IMO) vs the efficiency of small, single-use code bases with some consideration for sharing low-level code snippets, and people have been disagreeing about that for as long as any of us have been alive.

It's probably no surprise that teams working with Linux lean towards the "helper functions rather than abstraction layers" model while teams that have to write bottom-to-top code for Windows anyways lean towards the idea of finding ways to re-use that code rather than maintaining a separate copy for Linux.

First up - Thank you for your time in responding and as always providing excellent information!

Your explanation makes sense - the way AMD is setup to develop code is not 100% open source friendly so you do what you can given the constraints you have.

I guess the root of the problem is fragmentation across various distributions and that makes it harder for a developer to target something. And the story is complicated by required kernel and various driver repo's to get the latest support/features/fixes - and this being left up to the distro's to put in when they feel like it.

As the Linux desktop gets more and more gaming ability I feel that the current model is a little disjointed - for example:
* You want the latest perf? add this PPA/COPR to get the latest mesa
* Oh you have AMD, add this repo to get some extra stuff
* and if you want to configure something add this adriconf flatpak
* oh you care about latest feature X, please compile that kernel or install it from a PPA/COPR).

The distros to their best to get a cut every 6 months or 2 years - but that's a long time between updates.

There may be an opportunity here though to streamline things though - AMD and Intel are going to both face this problem.

My ideal solution would be to enable "Gaming Updates" on my desktop/distro of choice and forget about it. Its the sort of frictionless polish that would be awesome to have.

My question to you bridgman, if you would be so kind, Is :

Do you see any benefit in some sort of common initiative to get the latest and greatest out to the desktops and can you see AMD leading this effort?

Thanks again for your time!

[bridgman]

bridgman is there a chance that AMD VLK will make it into mesa and the powers of RADV and AMDVLK combined? It certainly would help with messaging to game devs/porters and be a net benefit to the community

The challenge is that the Vulkan driver supports multiple OSes and the core code (PAL) supports multiple APIs as well, some of which more-or-less require closed source, so having the master copy in Mesa would be tricky. It would require agreement to use Mesa for all the other OSes as well, which does not feel very likely at the moment.

Splitting the problem into three parts makes answering the question easier - maybe, no and yes:

Vulkan API layer - supports multiple OSes but not multiple APIs so not too closely tied to the HW. Changes relatively slowly (new extensions/versions) so not impossible to maintain a separate Linux-specific copy in Mesa, and in the meantime OS differences have largely been abstracted out already and we only publish the Linux bits.

Hardware layer (PAL) - supports multiple OSes and multiple APIs - APIs are much harder to abstract out than OSes because they end up having to be visible all the way down to the code banging on HW. Maintaining a separate Linux-specific copy in Mesa with identical behaviour looks to be quite expensive.

Shader compiler - any non-LLVM bits could probably be maintained in Mesa fairly easily and we are constantly pushing updates to llvm upstream - probably the easiest to make community friendly (and arguably mostly there already) although "upstream" in this case is llvm rather than mesa.

As always the tradeoff is between perceived benefits from code sharing via abstraction layers (over-rated in most cases IMO) vs the efficiency of small, single-use code bases with some consideration for sharing low-level code snippets, and people have been disagreeing about that for as long as any of us have been alive.

It's probably no surprise that teams working with Linux lean towards the "helper functions rather than abstraction layers" model while teams that have to write bottom-to-top code for Windows anyways lean towards the idea of finding ways to re-use that code rather than maintaining a separate copy for Linux.

[boxie]

They definitely could do a per-game thing. But let's be honest, which driver is more stable, open and well supported with dxvk? If you were going to tell developers to target Linux you would choose RADV every time.

If google have any driver issues, they will be in a better place to fix them with RADV then AMDVLK.

RADV has 2 main devs who volunteered to undertake a project that got it working.
AMD has teams of devs who are paid to make their stuff work.

AMD and Google have a vested interest in making this happen.

AMD has the industry contacts and do some of the engineering to help game engines to work on their platform.

Both implementations are open source. Mesa has a more open contribution model AFAIK.

While I would prefer a "meeting of the minds" and a single implementation that everyone can focus on as the way forward - I am not involved in the creation of either of these systems, so my say is very small - about 2c worth.

bridgman is there a chance that AMD VLK will make it into mesa and the powers of RADV and AMDVLK combined? It certainly would help with messaging to game devs/porters and be a net benefit to the community

[JAYL]

From here:

https://stadia.dev/blog/welcome-to-stadia/

Both AMDVLK and RADV are open source. If anything, that source would indicate google is using AMDVLK because it links to https://gpuopen.com/games-cgi/ and the open source driver listed there is AMDVLK https://gpuopen.com/gaming-product/a...er-for-vulkan/ (github at the bottom)

[LeJimster]

Why not both?

They definitely could do a per-game thing. But let's be honest, which driver is more stable, open and well supported with dxvk? If you were going to tell developers to target Linux you would choose RADV every time.

If google have any driver issues, they will be in a better place to fix them with RADV then AMDVLK.