AMDVLK Open-Source Radeon Driver Arrives With Vulkan 1.1 Support

[BNieuwenhuizen]

Good to see compliance submission for recent cards with radv. Do you plan to cover more than just a few?

The question is really about what you see as representative. We only have a few cards to test on. We could probably claim support for all cards in a generation by just putting them all there even though we tested one, but since we are not in the business of selling GPUs I didn't see the point. So these are just the cards that I had easily available. SI cards might not pass everything I'm not sure about CIK.

[R41N3R]

Sorry for being late, I was waiting for Intel to publish their patches as we depend on them, but RADV is very much conformant for 1.1 with the published patches:

https://www.khronos.org/conformance/...submission_308

Thank you! This is the best news about Vulkan 1.1 :-)

[geearf]

You mean it's still development quality? I thought it has been considered released for a while already.

I mean there is no release tarball, it's just commits in git with no tag or stable branch.
I believe it also still depends on a fork of llvm, which distributions may not want to incorporate.

[lu_tze]

Is there some effort to package amdvlk in Debian and other distros?

For Fedora, a package is here: https://copr.fedorainfracloud.org/coprs/tkov/amdvlk/

[lu_tze]

I mean there is no release tarball, it's just commits in git with no tag or stable branch.
I believe it also still depends on a fork of llvm, which distributions may not want to incorporate.

They do not need to incorporate the fork of llvm; it is compiled into the driver statically.

It is not going to be anytime soon, that the official llvm and the driver forks converge; even when the changes are being merged for the next release, when that comes out, it will be hopelessly obsolete.

The distributions will have accept that there will be multiple forks shipping, at least for foreseable future. AMDVLK, ROCm, Swift and Rust need their forks. Only some packages, like Mesa or Kotlin-native are able to run with upstream llvm.

[stompcrash]

The most exciting thing about this release to me is the multi GPU support. I would really like to see benchmarks done with multiple GPUs in a system to see how well that feature scales. I think this doesn't need any SLI or Crossfire to work, too.

Though I guess this is just academic interest as graphics cards are much too expensive for me to justify the purchase.

[airlied]

Michael do we need to tell you in advance to get mentioned :-P

[Michael]

Michael do we need to tell you in advance to get mentioned :-P

Saw Bas' email when he ended up sending out the patches but was preoccupied in some other work... should be up now.

[dfx.]

Will AMD ever stop fiddling around with its 3 half-baked copies of the same thing and just make Mesa/LLVM function-complete for any of its cards ? They better off replacing their Windows abomination with it too. And drop artificial market division and just sell few purpose-based non-overclocked (for TDP 100-200W) models for 5 years long generations. Like "workstation" (WX 9100), "render-farm", "consumer" (Vega 64) and "miser" (Raven Ridge). Otherwise developers always have to target lowest and shittiest model while power of the proper ones goes underutilized.

[geearf]

It is not going to be anytime soon, that the official llvm and the driver forks converge; even when the changes are being merged for the next release, when that comes out, it will be hopelessly obsolete.

Why is that? What's preventing them from upstreaming the changes and then keeping it up to date?