Mesa RADV vs. AMDVLK Radeon Vulkan Performance For July 2021

[user1]

I don't consider tests with Proton, since neither the developers nor Valve themselves have lifted a finger to fix errors with AMDVLK.

Actually, Valve devs DO care about how Proton/DXVK works on AMDVLK. For example, see the following issue reported by DXVK dev: https://github.com/GPUOpen-Drivers/AMDVLK/issues/203.
Also, why do you think Valve devs should fix broken driver themselves? The issue is in the driver, not in DXVK and it's the driver dev's job to fix it, since this is the "official" AMD Vulkan driver.

[mphuZ]

Also, why do you think Valve devs should fix broken driver themselves? The issue is in the driver, not in DXVK and it's the driver dev's job to fix it.

I'm not interested in minor mistakes (but it's also cool). Everyone says about them that AMDVLK is bad, but for some reason no one does anything.

Maybe because it's Open Source? Or is "it something else"? I don't remember one PR from them in AMDVLK/XGL/PAL.
Please, just don't talk about the closed development model. Valve is not a bunch of students writing code for a portfolio. They can always agree with AMD on joint development, especially considering that they have developed a chip for a future console together.

[user1]

I'll tell you a little secret: there are no problems with AMDVLK when developing native games on Stadia. Just like in Windows for many years.
Therefore, developers do not focus on Phoronix tests, because 80% of the games from the test are launched with Proton.

Like it or not, Proton is now a central part of Linux gaming and it's Valve's central focus with the upcoming Steam Deck. And that's the problem with AMDVLK devs. They simply don't give an F about Linux gamer's needs and mainly focus on Stadia. Hence all the brokenness of AMDVLK with most Linux games.

[JoshuaAshton]

Therefore, developers do not focus on Phoronix tests, because 80% of the games from the test are launched with Proton.

What's wrong with that? Why should DXVK or translation layers not be a target? It's not like games API usage will be so incredibly different that it's a waste of time.

I don't consider tests with Proton, since neither the developers nor Valve themselves have lifted a finger to fix errors with AMDVLK.

What do you want me to do here? It's not our bug!
Valve already fund one driver, do you want them to work on both of them now?

[JoshuaAshton]

I'm not interested in minor mistakes (but it's also cool). Everyone says about them that AMDVLK is bad, but for some reason no one does anything.

Maybe because it's Open Source? Or is "it something else"? I don't remember one PR from them in AMDVLK/XGL/PAL.
Please, just don't talk about the closed development model. Valve is not a bunch of students writing code for a portfolio. They can always agree with AMD on joint development, especially considering that they have developed a chip for a future console together.

I have actually done a PAL PR before and it was painful and not worth my time for the amount of effort involved really.
The reason nobody does anything is because pretty much nobody outside of AMD wants to work on it.
Open Source != People lining up to do free (or contracted) work for your project.

Any time I would spend working on AMDVLK would be infinitely better spent (both from mine and users perspectives) on literally anything else.

[mphuZ]

What's wrong with that? Why should DXVK or translation layers not be a target? It's not like games API usage will be so incredibly different that it's a waste of time.

I'm probably more of a fan of native games. And I just don't want Proton to completely replace native games in the future. But for old and non-ported games, I agree, Proton and the driver should work without errors.

Valve already fund one driver, do you want them to work on both of them now?

Yes, they could help AMD. Why not?

Any time I would spend working on AMDVLK would be infinitely better spent (both from mine and users perspectives) on literally anything else.

I am very sad to hear this. But, it's your choice.

[mphuZ]

And that's the problem with AMDVLK devs. They simply don't give an F about Linux gamer's needs and mainly focus on Stadia. Hence all the brokenness of AMDVLK with most Linux games.

Aren't drivers developed according to standards? It sounds strange that "developing a driver for Stadia" worsens its performance for other games.

[ResponseWriter]

Does anyone else experience a cycle of GPU resets with recent LLVM 13.0 dev builds? LLVM builds prior to around a month ago (when this started happening) seem to work even if I use git builds elsewhere. Using KDE, kernel 5.13 and mesa-git on a 6800 XT.

[tomas]

mphuZ

"I'll tell you a little secret: there are no problems with AMDVLK when developing native games on Stadia."

I'm sorry but this I find very hard to believe. There are and has been been pure Vulkan benchmarks among the tests that Phoronix has done through the years comparing AMDVLK with RADV. Since long, the native Vulkan performance of RADV has been superior to that of AMDVLK. In fact, I call upon anyone that can show a benchmark showing the opposite, that AMDVLK can outperform RADV. Yes, in this case the burden of proof lies on those claiming AMDVLK can be competitive with RADV. Although the pure Vulkan benchmarks done by Phoronix has been few they have nevertheless shown RADV to have superior performance compared to AMDVLK. Until someone can show the opposite I'm calling BS. For some unknown reason Google choose AMDVLK even though RADV would have been superior for Stadia. Either that or Stadia is in fact using something that is different from AMDVLK.

[R41N3R]

It's interesting to see the comparison between these 2 drivers! But in all these years I've not bothered once to install AMDVLK. The quality and performance of RADV was always to good to try anything else, plus there is ACO now. I don't think both drivers compete, RADV is the default and superior in gaming, AMDVLK is for special cases (like Stadia) and it is good to have it as a reference.