Mesa RADV vs. AMDVLK Radeon Vulkan Performance For July 2021

[xxmitsu]

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.

We are the customers that benefit for amdvlk being open source. Often times, it serves as source of documentation/workarounds for hardware bugs. Those are afterwards adapted to mesa.

By being open sorce, mesa developers can use it as a source of inspiration, benefiting mesa users.

[user1]

We are the customers that benefit for amdvlk being open source. Often times, it serves as source of documentation/workarounds for hardware bugs. Those are afterwards adapted to mesa.

By being open sorce, mesa developers can use it as a source of inspiration, benefiting mesa users.

Yeah, I know that Radv developers sometimes benefit from it. For example, I know they've recently looked into why Doom Eternal is slightly faster on AMDVLK than Radv.
But I was referring to customers that are not regular users like us, for example Stadia, or maybe some enterprise users.

[aufkrawall]

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.

Then this would be a devestating blow to AMD's FOSS strategy. I don't think being that pessimistic is justified (yet). The lack of communication is worrying (and more...), but on the other hand not that untypical for AMD either.

[Venemo]

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

You don't need to track down what exactly causes the issue, just let us know about the issues you see.

[user1]

I've read that AMD's public documentation on the ray-tracing instructions in the ISA is so poor to the point that RADV developers had to use reverse engineering methods in order to support it in RADV. Maybe there really is some licensed stuff in it and that's probably why AMDVLK-open still doesn't support it.

[Venemo]

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.

Please don't bash AMDVLK (PAL, XGL, LLPC). It's a good thing that it exists and that we can read its code. There is a lot of helpful documentation and comments in there.

[Venemo]

I've read that AMD's public documentation on the ray-tracing instructions in the ISA is so poor to the point that RADV developers had to use reverse engineering methods in order to support it in RADV. Maybe there really is some licensed stuff in it and that's probably why AMDVLK-open still doesn't support it.

The Ray tracing API is complicated and the shader compiler side is extremely involved. (There are several new shader stages and several features that were not needed in the traditional pipine.)

I don't wanna speculate, but I think maybe they simply haven't had time to implement all of it yet in LLVM.

[user1]

Please don't bash AMDVLK (PAL, XGL, LLPC). It's a good thing that it exists and that we can read its code. There is a lot of helpful documentation and comments in there.

I'm not bashing it and I do recognize the fact that you sometimes need to rely on it to benefit RADV, since it's not the official driver that AMD supports. I'm just curious how do customers that are not regular users benefit from AMDVLK-open. That's why I asked that question.

[smitty3268]

I don't wanna speculate, but I think maybe they simply haven't had time to implement all of it yet in LLVM.

You're right, that's very possible as well. If that's true, I believe it shows that they have zero interest in the driver for individual consumer purposes, though. And basically LLVM RT support will come whenever their ROCm compute team decides they need to support it, and not before.

Given how well their ROCm support has gone so far, that's deeply troubling. But certainly better than the alternative, if true.

[pal666]

But aren't we talking about AMDVLK-open which is exclusively for Linux? I think that's what he meant.

it's built for linux, but it's built from cross-platform code