AMDVLK 2022.Q3.1 Released With Fixes, Minor Enhancements

[phoronix]

Phoronix: AMDVLK 2022.Q3.1 Released With Fixes, Minor Enhancements

AMD today published AMDVLK 2022.Q3.1 as their latest snapshot of this open-source Radeon Vulkan driver for Linux systems...

https://www.phoronix.com/scan.php?page=news_item&px=AMDVLK-2022.Q3.1-Released

[clockwork]

I never understood why the fracturing in Mesa vs AMD open source drivers. Wouldn't AMD's Linux efforts be better served if they join the rest of the community and fully support Mesa? Instead of half assing 2 FOSS drivers, they could full ass 1.

[schmidtbag]

I never understood why the fracturing in Mesa vs AMD open source drivers. Wouldn't AMD's Linux efforts be better served if they join the rest of the community and fully support Mesa? Instead of half assing 2 FOSS drivers, they could full ass 1.

Yes. But as you soon might find out, people here are likely going to rip you a new one for sharing such an opinion. Around here, it doesn't matter if there are better priorities. It doesn't matter if yields another fork or divides finite resources. It doesn't even matter if it adds more work in the long run. So long as it isn't faulty or malicious code, if it's an open-source project, you better support the effort or otherwise commit changes yourself, because as far as this community is concerned, all FLOSS efforts are infallible . There are a handful of exceptions but the vast majority people will defend all commits.

But anyway, RADV isn't necessarily AMD's project. I think AMD maintains both, don't quote me on that though.

[qarium]

Yes. But as you soon might find out, people here are likely going to rip you a new one for sharing such an opinion. Around here, it doesn't matter if there are better priorities. It doesn't matter if yields another fork or divides finite resources. It doesn't even matter if it adds more work in the long run. So long as it isn't faulty or malicious code, if it's an open-source project, you better support the effort or otherwise commit changes yourself, because as far as this community is concerned, all FLOSS efforts are infallible . There are a handful of exceptions but the vast majority people will defend all commits.

But anyway, RADV isn't necessarily AMD's project. I think AMD maintains both, don't quote me on that though.

i also vote for abadon AMDVLK but you know bridgman always tells us theat AMDVLK is only the windows driver dropped on github... with nearly zero costs for amd.
and join RADV would cost amd much more.

so maybe the solution is that [email protected] just stop reporting news on AMDVLK...

most people would not even know that AMDVLK exists if there where no news on phoronix.com about AMDVLK

[Svyatko]

i also vote for abadon AMDVLK but you know bridgman always tells us theat AMDVLK is only the windows driver dropped on github... with nearly zero costs for amd.
and join RADV would cost amd much more.

so maybe the solution is that [email protected] just stop reporting news on AMDVLK...

most people would not even know that AMDVLK exists if there where no news on phoronix.com about AMDVLK

No, thanks, I prefer to have a choice.
Users often get support for new hardware and new features faster with AMD drivers.

[aufkrawall]

No, thanks, I prefer to have a choice.
Users often get support for new hardware and new features faster with AMD drivers.

Not really true when AMD officially supports Mesa, like they do with RadeonSI.
Uneducated guess: Hiring 1-2 more people with AMD internal short wire to hardware guys should do the trick to support everything day 1 (or before) for RADV.

[schmidtbag]

No, thanks, I prefer to have a choice.
Users often get support for new hardware and new features faster with AMD drivers.

But that's kind of the point that was made earlier: if there was only one driver then all resources are pooled into it. So, not only would the one driver get the latest hardware and features sooner, but it also gets optimized faster. It's also less confusing to anyone not knowing which driver to pick from. Maintaining 2 separate projects that effectively accomplish the exact same goal is a lose-lose situation for the users.

The only advantage we get from having 2 parallel projects like this is we get to see how one driver might perform better than another under certain workloads, which highlights inefficiencies. If all devs were to work on the same project, we might not see such discrepancies, but we also would just get better overall results.

[skeevy420]

No, thanks, I prefer to have a choice.
Users often get support for new hardware and new features faster with AMD drivers.

Not via AMDVLK, but AMDGPU-Pro (which contains a 2nd version of AMDVLK, BTW) with its updated* AMDGPU module and is only applicable for specific versions of Ubuntu, RHEL, and SUSE (ditto with official AMDVLK releases). Everybody else has to get new AMD drivers just like Intel folks -- New Kernel and Mesa.

*updated in relation to the AMDGPU module shipped with those old to ancient kernels that LTS distributions use; Pro can actually be older than mainline or RC Linux when AMD goes a few months or longer between AMDGPU-Pro updates.

[skeevy420]

But that's kind of the point that was made earlier: if there was only one driver then all resources are pooled into it. So, not only would the one driver get the latest hardware and features sooner, but it also gets optimized faster. It's also less confusing to anyone not knowing which driver to pick from. Maintaining 2 separate projects that effectively accomplish the exact same goal is a lose-lose situation for the users.

The only advantage we get from having 2 parallel projects like this is we get to see how one driver might perform better than another under certain workloads, which highlights inefficiencies. If all devs were to work on the same project, we might not see such discrepancies, but we also would just get better overall results.

One driver to rule them all
One driver to find them
One driver to bring them all
And in the darkness bind them

[kiffmet]

AFAIK AMDVLK is a byproduct from AMD providing a (for some distros validated) PRO driver. The only difference is that the non-PRO version does not use AMD's proprietary shader- and pipeline compiler, while both build on top of a platform abstraction layer to allow as much code sharing between Windows and Linux as possible.

I think it's great to have multiple options in that regard, as this may very well help projects like DXVK and VKD3D with comparing results and diagnosing issues, aswell as users who can switch between the stacks on a per-application basis with environment variables in order to quickly have a workaround should something be broken or regressed.

Both RADV, aswell as AMDVLK have a more than reasonable development pace and with Valve officially supporting the RADV driver, it's IMO not detrimental to have these options. Also, everything that lands in the amdgpu kernel module automatically benefits all drivers for recent-ish AMD graphics cards anyways.

In a hypothetical scenario where all of the people involved work together on a single, unified driver, I can imagine that there would be conflicts about which approach to take when it comes to implementing features and functions. Many ideas that could yield long-term benefits wouldn't even be tried out, actually hurting innovation and the development of new general concepts in graphics driver programming. Things are fine the way they are.