In case you have forgotten, this issue was first reported in August 2024: that’s considerably longer than 3 weeks…
- The real work on the issue really started in the 2nd half on 2025 with the Vulkan spec effort. Nvidia could have started this waaay earlier.
- Nvidia could have assigned a few engineers (like 2-3) to help with DXVK and VKD3D-proton implementations. This would have improved both staffing of these projects as well as exchange of information with their Vulkan driver team as they all would have been NV engs. This has never happened and all the work is being done by a group of open-source volunteers.
- Nvidia’s Linux desktop team is criminally understaffed.
All these things could have been easily resolved with waaay less than a trillion $.
Excuse me? Exactly what made you think so, because my impression is exactly the opposite:
- Nvidia does not intend to open-source their driver
- …nor even make their kernel modules a part of the mainline kernel. As a result, there’s zero quality control over them and even a slightest problem (like one of GPUs in your array failing) causes them to throw a tantrum and destabilize the whole kernel, forcing you to reboot.
- Even freakin module initialization error codes are proprietary, so in case you get the infamous
rmInitAdapterFailed, all you can do is to post the error code to this forum and watch it being ignored… (due to lack of resources by the desktop team mentioned earlier)
I haven’t seen any blaming of the open-source engineers working on DXVK and VKD3D-proton (please correct me if I’m wrong), just the opposite. I haven’t even seen direct blaming of Nvidia engs: only of the company’s corporate attitude. UPDATE: I have seen exactly one instance of direct blaming of NV engs and I personally intervened against doing so at that time.