Radeon Vulkan Driver Benchmarks: AMDVLK 2018.4.2 vs. AMDGPU-PRO 18.40 vs. Mesa 18.2/19.0

[phoronix]

Phoronix: Radeon Vulkan Driver Benchmarks: AMDVLK 2018.4.2 vs. AMDGPU-PRO 18.40 vs. Mesa 18.2/19.0

Released this week was AMDVLK 2018.4.2 having been released this past week as the newest open-source AMD Vulkan driver code derived from their official Vulkan driver code-base but with using the AMDGPU LLVM compiler back-end over their proprietary shader compiler. For your latest Vulkan benchmark viewing pleasure is a look at this newest AMDVLK release compared to AMDGPU-PRO 18.40 (the same fundamental Vulkan driver but with the closed-source shader compiler) and then the RADV Vulkan drivers in the form of Mesa 18.2 stable and the now in-development Mesa 19.0. These four AMD Radeon Vulkan driver combinations were tested on Fiji, Polaris, and Vega graphics processors.

http://www.phoronix.com/vr.php?view=27155

[clapbr]

I'll be keeping amdvlk as main driver with radv as alternate for now. Most games running a bit better on it atm. Compiling amdvlk is a bit of a pita though, mainly because it need its own llvm and that takes ages to build.

[M@GOid]

I'm using AMDVLK for a couple days now. Things look good so far.

[Xaero_Vincent]

Ugh, all these AMD Vulkan driver implementations seem like a waste of developer resources. Why not consolidate development effort around one and make it the best?

[humbug]

Ugh, all these AMD Vulkan driver implementations seem like a waste of developer resources. Why not consolidate development effort around one and make it the best?

I would love to see them consolidate and collaborate rather than duplicating efforts.

But the thing is the community decided they could not wait for AMD to release their driver. So Red Hat started making RadV, now it's fairly mature and other people like Valve make big contributions to it. Both RedHat and Valve devs are now very familiar with it and regular contributors. And all the distros use it as the default Vulkan driver for AMD. Game devs too target and test their games against it.

By the time AMD released amdvlk all of the above had already happened. But AMD too won't adopt RadV because they focus on maintaining their official driver as a cross-platform Vulkan driver across windows and Linux. This is understandable and makes sense.

The only hope is if the community like Red Hat, Valve etc start contributing to amdvlk and it starts getting used by gamers. Right now few people use it and it's inconvenient as it's not the default. Also hopefully it can catch up to the proprietary driver performance.

[ThoreauHD]

At least there's a reason to install the proprietary driver now, besides freesync. It's kinda strange that mesa git and stable weren't very far apart, with stable pulling ahead in some.

[schmidtbag]

How would you know if it is the best achievable one if there was just a single Vulkan implementation?

Competition is good.

A few things:
1. Cooperation is better than competition.
2. Since the closed-source drivers are anti-cooperation, that's where competition is necessary, and a good thing.
3. With proper cooperation, everyone would know what the best achievable implementation would be.
4. IIRC, RADV copied a lot of code from amdvlk. Clearly, amdvlk has a good implementation.

[smitty3268]

amdvlk is starting to look pretty good, honestly.

How's the compatibility with dxvk? It used to be really buggy, but if that's fixed and most games are now working then it deserves to start being taken seriously, finally.

Also, what's the story with it's LLVM use? I assume it's still using a fork, right? Guess the question is once they merge that back upstream if radv will also speed up or not.

radv seems to be having serious issues optimizing Vega performance, which is probably to be expected given that the radesonsi drivers also have really slow performance for those cards and they share so much code.

[markorm]

How's the compatibility with dxvk?

I tried AMDVLK over this weekend with Hitman Season 2, there were no noticeable performance improvements, but it did manage to fix the cloth physics bugs which were incredibly annoying.

[M@yeulC]

A few things:
1. Cooperation is better than competition.
2. Since the closed-source drivers are anti-cooperation, that's where competition is necessary, and a good thing.
3. With proper cooperation, everyone would know what the best achievable implementation would be.
4. IIRC, RADV copied a lot of code from amdvlk. Clearly, amdvlk has a good implementation.

The solution would be to make the two codebases gradually closer, and ending up with exactly one codebase.

But the way AMDVLK is developed with regular code drops isn't really open source friendly, as far as development goes.