A Closer Look At The AMDVLK vs. RADV vs. AMDGPU-PRO Vulkan Performance

[airlied]

airlied

Basically it should be possible to package AMDVLK relatively easy. It is always good to have got a 2nd choice - the question is just how to select the default Vulkan driver.

Btw. is OpenCL for Polaris 12/Vega already fully open source and packaged for Debian - had problems installing 17.50 with in compute mode with Debian Stretch. With a mesa+llvm backport at least OpenGL+Vulkan works.

For something like Fedora and even worse something like RHEL, packaging new drivers when there is already one shipping in the tree. Supporting a second driver for all installed apps in a distro is messy.

But it's early days yet, I wouldn't recommend serious packaging of amdvlk until it starts not requiring it's own llvm, and until the development model is sorted out.

Dave.

[stalkerg]

airlied I agree, they just made the driver as open source and not open/free community driver. At least it's a good source for RADV driver.
PS did you try to use they LLVM with RADV? with Dota2?

[GruenSein]

It makes a difference if AMD want people to ship their driver. I think most distros dislike shipping thrown over the wall code for many reasons, and until there is a development model for the amdvlk driver, it's hard to want to invest much in it.

Dave.

Agreed. You raised some valid questions regarding external code contributions especially since there is an internal tree at AMD that needs to stay in sync. Also, I am not saying to drop RADV. It is pretty impressive and has attracted developer contributions from other companies for good reasons. All I am saying is that it is not really an option for AMD to drop everything and go RADV like some people seem to think. Their code has now been available for about a week. Let’s wait and see how they handle code contributions before the complaints towards them start.

[duby229]

Agreed. You raised some valid questions regarding external code contributions especially since there is an internal tree at AMD that needs to stay in sync. Also, I am not saying to drop RADV. It is pretty impressive and has attracted developer contributions from other companies for good reasons. All I am saying is that it is not really an option for AMD to drop everything and go RADV like some people seem to think. Their code has now been available for about a week. Let’s wait and see how they handle code contributions before the complaints towards them start.

That's easy enough to say now, but what about just 2 weeks ago, or more realistically a year ago?And what does this precedence mean for next week, or more realistically next year?I can tell you for certain we can look at past years to get a ood idea what the answer is. It's not good.

[GruenSein]

That's easy enough to say now, but what about just 2 weeks ago, or more realistically a year ago?And what does this precedence mean for next week, or more realistically next year?I can tell you for certain we can look at past years to get a ood idea what the answer is. It's not good.

Or we could conclude that it took a while because it is a lot of work but finally they came through with exactly what they promised. Just sayin'

[Almindor]

The main issue is not shipping or packaging but game devs. NOBODY wants to support two of the same especially if neither is "industry standard". I'm afraid this typical AMD driver situation is going to result in game devs simply not supporting Vulkan on Linux for AMD cards. Sad but logical. They'll just go "meh", use GL where possible on linux and stick to DX12 on windows.

I suppose we can hope that the linux community sticks to shipping just one of the two and the other "dies" out of that.

And I realize that both provide "the same thing" but engine devs go deep and find bugs and perf. issues with drivers all the time. Doing that work twice is not thinkable for a platform with laughable market share.