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

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

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

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