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

[qarium]

The issue is AMD isn't half-assing 2 FOSS drivers.
They're half-assing 1 FOSS driver. radv isn't supported by them at all, only amdvlk.
So full-assing 1 driver would require more money/effort than they are apparently willing to spend.

right this is what bridgman always tells us... thes spend less money on AMDVLK than any effort on RADV would cost them.
and there is a simple solution for the linux community: buy more Valve steam deck ... AMD already hired 2 linux driver developers only because of the massive valve steam deck sales.
in the end capitalism in the computer sector is simple the companies invest in what the people buy.

the joke about this is steam deck costs 400-700 dollars i did spend like 9000 dollars on my 2 threadripper+vega64 systems but officially AMD did not count them as linux sales.
but they count the steam deck as linux sales.

this is also valves fault because they could sell valve steam laptop and valve steam desktop and valve steambox and valve steam touchscreen tabled and so one and so one.

we need a company like valve to sell all these products with linux and then we need to buy these product and then AMD count it as linux sales and they hire more linux driver devs thats very simple.

[smitty3268]

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.

The issue is AMD isn't half-assing 2 FOSS drivers.

They're half-assing 1 FOSS driver. radv isn't supported by them at all, only amdvlk.

So full-assing 1 driver would require more money/effort than they are apparently willing to spend.

[schmidtbag]

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.

Sure but with divided resources, fixing such issues would take longer. If the resources were pooled, then such those issues might not have come up in the first place, especially since there would be more eyes on the project to find them before they get published. That's one of the things that makes the Linux kernel so stable and secure, because there are so many people prodding it that nothing slips past anyone. Unlike a kernel, GPU drivers have limited functionality, and while individual functions may be complex, it's a lot simpler as a whole.

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.

Typically, such conflicts are due to design choices or appeasing shareholders. GPU drivers are a bit more... abstract, I guess you could say. There's not really much room for opinion or innovation, because you're limited by what the hardware and the APIs can do, which is finite. There can be arguments over the most efficient method or which feature should get attention first, but to me that should be obvious: fix what is broken before you add anything else, and otherwise cater to the largest affected audience possible.
So, while you're right that a unified project can lead to such conflicts, I don't think this is one of them, especially since there are pretty big businesses involved to help keep priorities straight.

[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.

[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

[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.

[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.

[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.

[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.

[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