Mesa RADV vs. AMDVLK Radeon Vulkan Performance For July 2021

[obri]

AMD Gfx Drivers seem to be a mess to me.

Three different drivers all with pros and cons but not one with Raytraycing?

Isn't that weird and a waste of resources?
IMHO the end user should get one driver that works well.

[aufkrawall]

Does that mean Nvidia's shader compiler has comparable performance to ACO?
I don't have Nvidia, but from my own testing of the three compilers, the pro compiler is much closer to ACO than LLVM in compile time performance.

Yes, my impression is that in terms of CPU shader compile speed, ACO and Nvidia are closer than ACO and amdvlk-pro are. When you play Heroes of the Storm with flushed driver shader cache (but existent and well populated DXVK state cache), the shader compile stutter is much less harsh with ACO and Nvidia vs. amdvlk-pro. amdvlk-open is probably less terrible than it used to be, but still really, really bad in comparison (no idea if the game actually starts with it in its current state). One could also stop the time when the high CPU load from compiling shaders from DXVK's state cache in the game's main menu ceases with flushed driver shader cache, I think it would confirm this.

Edit: As it might seem confusing: The game still has shader compile stutter, despite of DXVK's state cache, as the game developers screwed up to make sure really all shaders (the game has a shipton) are compiled ahead in time.

[Venemo]

AMD Gfx Drivers seem to be a mess to me.

Three different drivers all with pros and cons but not one with Raytraycing?

Isn't that weird and a waste of resources?
IMHO the end user should get one driver that works well.

If you look at the FOSDEM presentation by Nicolai, you can see that the only difference between PRO and AMDVLK is that one uses a proprietary shader compiler and the other uses LLVM. Otherwise they are the same driver.

So, in fact you only have 2 different drivers: AMDVLK (and its PRO variant) that is backed by AMD and shares code with their Windows drivers, and RADV which is funded mostly by Valve and shares code with other Mesa drivers.

[F.Ultra]

Please note Kisak build is a build of mesa, there is no such thing as an official Mesa build, you either use your distro default or an external source like a ppa/AUR/etc. but unless whatever Mesa source you are using(distro or external) explicitly ask you not to report bugs to mesa(mostly because those build may contain extra patches) it is 100% perfectly fine to report bugs in Mesa.

If you are having issues make bug report here https://gitlab.freedesktop.org/mesa/mesa/-/issues

Well at the time Kisak backported the metro fix so the version that I tested way back was indeed very custom. But I'll try again with 21.1.5 and see how it works.

[xxmitsu]

If you look at the FOSDEM presentation by Nicolai, you can see that the only difference between PRO and AMDVLK is that one uses a proprietary shader compiler and the other uses LLVM. Otherwise they are the same driver.

So, in fact you only have 2 different drivers: AMDVLK (and its PRO variant) that is backed by AMD and shares code with their Windows drivers, and RADV which is funded mostly by Valve and shares code with other Mesa drivers.

It might be that strategy has changed..
I'm considering the following:

• Amdvlk-pro had raytracing right? Does the amdvlk-open have the required frontend RT bits except the backend compiler support?

I think not.

• Were some recent releases of the amdvlk open, launched after the pro RT support, implementing recent khronos vk extensions? so it just doesn't look like the -open is behind with releases, but instead it receives new features that are not in -pro yet?

Looks like they somehow treat them as separate projects with separate priorities in terms of what variant receives what and when...

[aufkrawall]

Amdvlk-pro had raytracing right? Does the amdvlk-open have the required frontend RT bits except the backend compiler support?
I think not.

I'd assume that they have an internal (PAL) branch (as it's developed behind the fence...) with RT support and so far they have only made it public precompiled with the -pro driver and the bits for the open compiler are severely lagging behind.
It's not that surprising actually, given how poorly even the Windows (D3D12) driver works with "RTX" games. When it's just slow without being stuttery or without visual corruption, you can already consider yourself lucky.

[bridgman]

AMD Gfx Drivers seem to be a mess to me.

Three different drivers all with pros and cons but not one with Raytraycing?

The - pro driver has included raytracing for a few months now, starting with the 21.10 release:

https://www.phoronix.com/scan.php?pa...vulkanrt&num=1

[smitty3268]

I'd assume that they have an internal (PAL) branch (as it's developed behind the fence...) with RT support and so far they have only made it public precompiled with the -pro driver and the bits for the open compiler are severely lagging behind.

I don't think you can assume that at all. I mean, it might be true.

But I think it's equally likely that their proprietary driver's RT code uses some kind of licensed/patented algorithms which are what's causing them to not release the code in the OSS driver, and they might not have any plans of ever fixing that. There's certainly never been any kind of message from AMD that it's coming, anyway.

[theriddick]

Please open a bug report in the mesa issue tracker for each game issue you find. We can only fix issues that we know about. Thank you.

Yeah I normally do. Sometimes it can be hard to track down the exact cause/feature being the problem.

[user1]

Don't like AMDVLK, don't use it. No one is forcing you to. There are some customers that want it. Would you prefer if it were closed source? And before someone suggests it, getting rid of AMDVLK does not suddenly free up a pile of developers to work on something else. That team still has to support other OSes and APIs; Linux is just a small part of what they work on. PAL for example is used by more than just Vulkan.

Out of curiosity, are there any customers that benefit from the fact that AMDVLK is open source? Do they make their own contributions to AMDVLK? I mean as already mentioned, it's not open-developed unlike Mesa drivers, so for most users it's probably not that big of a difference compared to AMDVLK-pro.