AMDVLK 2021.Q2.4 Released With Two More Extensions Added

[Sethox]

I understand Ubuntu. I don't understand why AMD makes RHEL and CentOS packages. Contractual reasons? The overlap of RHEL/CentOS users and people using AMDVLK has to be next to none.

I mean, who TF plays games on RHEL/CentOS?

And this is coming from somebody who seriously, seriously considered installing RHEL yesterday and would have been using it for the occasional game. I went with Fedora.

Is it weird to think that AMDVLK is not always used for gaming? As far as I am aware, it's the Vulkan portion from AMDVLK-Pro just open sourced. But the difference between Pro and open source is that Open source you get to help to improve. So I suppose that improvement gets to be added in into Pro version (I assume this because the Open Source version gets more releases sometimes, while Pro only get the occasional stable releases).

[smitty3268]

amdvlk-pro is actually exactly for gaming, as it's the ~same driver as on Windows. It's pretty much always faster and more stable than amdvlk-open, even though some FOSS zealots might not want to hear that.

I'm sure I'm wrong, but I don't think any FOSS zealots like amdvlk-open at all. It's basically code thrown over a wall, not a real open source project.

[smitty3268]

Is it weird to think that AMDVLK is not always used for gaming? As far as I am aware, it's the Vulkan portion from AMDVLK-Pro just open sourced. But the difference between Pro and open source is that Open source you get to help to improve. So I suppose that improvement gets to be added in into Pro version (I assume this because the Open Source version gets more releases sometimes, while Pro only get the occasional stable releases).

The main difference between pro and open is that the pro drivers use AMD's proprietary shader compiler (shared with their windows drivers), while the open drivers use the open source LLVM compiler.

The proprietary shader compiler seems to be much better - or at least, much faster at compiling shaders, and much more up to date with the latest tech that AMD adds like ray tracing which hasn't been added into LLVM yet.

[skeevy420]

Is it weird to think that AMDVLK is not always used for gaming? As far as I am aware, it's the Vulkan portion from AMDVLK-Pro just open sourced. But the difference between Pro and open source is that Open source you get to help to improve. So I suppose that improvement gets to be added in into Pro version (I assume this because the Open Source version gets more releases sometimes, while Pro only get the occasional stable releases).

From what I understand, the way the open source model is released makes it hard to contribute towards. How the releases are basically just code dumps from behind closed doors into multiple open repositories. That seems to be what people around here say anyways.

[zxy_thf]

amdvlk-pro is actually exactly for gaming, as it's the ~same driver as on Windows. It's pretty much always faster and more stable than amdvlk-open, even though some FOSS zealots might not want to hear that.

AMD's Windows driver only gained such reputation in some parallel world.

[aufkrawall]

AMD's Windows driver only gained such reputation in some parallel world.

Probably true for the Windows kernel mode driver, yet amdvlk-pro often shows very good performance vs. Nvidia in AAA games.

[bridgman]

There's an AMD driver in the kernel that AMD does (and numerous other volunteers) and a MESA driver on the software side that AMD doesn't. That driver, MESA's RADV, competes with AMD's AMDVLK.

re: "a Mesa driver on the software side that AMD doesn't"... Mesa supports multiple APIs including OpenGL and video encode/decode, and AMD is the primary contributor to all of the Mesa drivers except RADV, although RADV leverages code from the Mesa OpenGL driver.

[skeevy420]

re: "a Mesa driver on the software side that AMD doesn't"... Mesa supports multiple APIs including OpenGL and video encode/decode, and AMD is the primary contributor to all of the Mesa drivers except RADV, although RADV leverages code from the Mesa OpenGL driver.

The first half of that was supposed to be done in a RADV/AMDVLK context and I meant to stop there but kept on writing (my curse).