The “let them cook” comment was specifically referring to the vkd3d-proton maintainers’ active work on the descriptor heap stuff. I don’t think anyone in this thread is necessarily defending Nvidia here, I think we’re all here because we’re not happy about the situation.
Yes, that’s what I mean - the work of the vkd3d-proton team alone is not enough to make NVIDIA underdeveloped drivers work properly.
More maintainers needed !
If I recall correctly, they hired Linux driver engineers a month ago, and that’s a pretty good news for linux users. Let’s be a bit more patient.
i think we need to stop pretending that Nvidia isnt a trillion dollar company and the largest by market cap in the ENTIRE WORLD. They couldve long afforded to not have their Linux drivers crap the bed as often as they do.
Keep in mind this isnt some attack on Nvidias devs, they have to follow corpo rules and release schedules. This is stating that there is absolutely zero reason for nvidia to have issues like not supporting an 8yr old api or the myriad of issues that the 50 series has seen since its launch, etc.
They have more money than God, and still Linux users get shafted more often than not…So while we have to wait, being patient isnt necessary. Microsoft doesnt get this kind of treatment, they get absolutely lambasted for poor software releases and theyre 1.7 trillion dollars smaller.
And this is a technical forum, not a complain forum. You have reddit for that.
My point is, stop pretending they’re some liittle guy who we gotta hold their hand while they get it together.
You can pretend this is a purely technical forum but its the closest thing for Linux users to communicate with nvidia at all. Complaining on reddit may as well scream into the void. There’s no git, no regular Linux forum like Windows users have, nothing. This is it.
On the topic of this thread, there is currently a large number of regressions with the driver heap implementation to the point that dxvk disables it entirely. Anyone testing right now should be aware its very broken ATM and even if it turns into a magic bullet (which it likely wont due to other driver problems) its gonna be some time before it happens.
Temper your expectations, and wait for at least the next driver released for testing (if youre not gonna do bug reports) as hopefully it’ll fix a number of the current issues.
Even if you ignore comments in this thread, the amount of technical discussions is like 1%. This is the expected general hub for bug reports and discussions whether anyone likes it or not.
The squeaky wheel gets the grease as they say. Complaints and reporting are the best tools to convey issues when done in a respectful and professional manner. A lot of companies beg for feedback and complaints. It gives them insight into what their customers are thinking and saying. Anyway, just wanted to throw that out there.
I’m talking about the non-Nvidia devs, like me, who are tired to read this kind of comments when trying to help, build feedbacks and follow what’s happening to report proper information in the same place. Getting mail notifications from this topic to read your complains is really annoying, as after more than 700 comments, we understood you’re pissed. No need to add more.
@aplattner can we get a clean up on this thread of all the off-topic chat please the back and forth is just childish and helps no one.
I think that is rather elitist of you to think that. People should be able to address their concerns especially if they paid good money, and hard earned at that, for a product.
@jeff.artik, while I understand your pain (I myself try to filter technical info from this forum, so that I can plan my deployments accordingly), @tda0626 has a point also: this is a general-audience forum and there’s no better place for non-tech users to post their valid complains than here. …As well as there’s no better place for technical ppl: thanks to Nvidia (as usually), that decided not to have a public bug-tracker… (sic!)
It is what it is folks and we need to learn to live with each other ;-)
Which is actually why we don’t have access to the internal bug trackers which some people here (and in other threads) have been requesting…
Additionally, from my perspective, and I previously wrote that somewhere, we shouldn’t expect a stable implementation between driver, DXVK, and/or vkd3d before Q4 2026 (and even then, performance optimization should always come after stabilization). I don’t get why people expect perfection of new interfaces right from the start when a feature lands, maybe give them two weeks to fix something, when the different projects are maintained by completely different parties.
Giving a broad audience access to incomplete implementations (i.e., the heap implementation branch of vkd3d) obviously isn’t helping: “hey I can use it and it isn’t working, let’s loudly complain”. Just because a company has a trillion dollars doesn’t mean it can fix complicated bugs or implement complex features reaching beyond their own source code boundaries in just 3 days or 3 weeks. Development just doesn’t work this way. Code won’t become better if 30 people work on a bug or feature at the same time - much like you don’t cook a soup with a bunch of chefs. And people can’t work 24h a day. A trillion dollars doesn’t change that.
I think we should understand that at the end, there are real people working on the code, and some statements here (not limited to any single thread but on the broader forums perspective) seem unfair to those real people. Yes, NVIDIA, as a company, could probably be more open and transparent, and I think during the last 1-2 years, it has become obvious that NVIDIA is going into that direction. Maybe they could do it faster, maybe not, but at the end of the line, none of the developers working on the code can do anything about that. And complaining loudly every few days/weeks doesn’t help the people who need to work with the forums, moderate them, and transfer info into the internal bug trackers.
And let’s face it: Part of those “trillion dollars” is those people who buy that hardware. In the world of such companies, money usually has a bigger impact than feedback. If you buy the product, you confirm that they are doing a good work. IOW, money is your impact.
That said, we probably need more competition on the market. But for now, let’s help NVIDIA stabilizing and improving the heap feature by giving valuable feedback instead of trying to force a feature because you paid for the hardware (you didn’t pay for the feature, it didn’t exist at that time). And for the next upgrade, decide whether you stay with NVIDIA (and then you probably have reasons for that and should question yourself “why”), or whether you support another vendor. I will certainly question that at (maybe) end of this year, if (hopefully) prices returned to normal…
I don’t say that people should not complain - they should, and they have a right to do so. But repeating the same complaints with repeated reasoning (money, trillion dollars, etc) over and over again, possibly in multiple threads, doesn’t help following the forums, neither for the moderators nor the users.
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.
You’re right that my “3 days / 3 weeks” wording was exaggerated - that was intentional to make a point, not to describe the actual timeline of the issue.
The problem itself has been known for much longer, no disagreement there. What I was referring to is more the point where things become visible and accessible to a broader audience - for example when experimental changes start showing up in Proton builds or distributions. That’s usually when expectations suddenly shift towards “this should work perfectly now”, even though the underlying work is still ongoing.
On the Vulkan side, I’d also assume that a lot of groundwork has been happening internally for quite some time before it became publicly visible.
Regarding staffing: I agree that NVIDIA could invest more into the Linux desktop stack and improve communication. That’s a fair criticism. I’m just not convinced that adding a few engineers would have linearly accelerated progress in something as complex as vkd3d-proton, which sits at the boundary between driver behavior, API semantics and actual game workloads.
Coming back to the original topic: descriptor heaps and their impact on DirectX 12 performance are a good example of why this is hard to “fix quickly”. They influence how resources are allocated, how descriptors are managed, and how efficiently work can be submitted to the GPU.
VRAM management ties into this as a secondary effect: inefficient descriptor usage or allocation patterns can increase memory pressure, which then amplifies the problem depending on how the driver handles residency and eviction. That’s why improvements in memory management (like the recent dmemcg-based prioritization work for AMD drivers) can still have a noticeable impact, even though they don’t directly change descriptor heap behavior. I hope we see some work from NVIDIA here soon, it will already solve a lot of performance problems.
On the open-source point, I think the situation is more nuanced than “no intention at all”. NVIDIA is clearly not open-sourcing their full stack, but things like the open kernel modules and their involvement in NVK show at least some movement, even if it’s slow and selective.
So yes, there are valid criticisms towards NVIDIA as a company. I just think it’s worth keeping in mind that issues like DX12 performance, descriptor heap handling and memory behavior span multiple layers of the stack, and aren’t something that can be fixed in isolation.
I also agree that most criticism is aimed at the company rather than individual engineers. Still, statements like “NVIDIA should just assign more engineers” can be a bit misleading from the outside, because they assume we can accurately judge how much effort is already going into this internally.
If you look at projects like DXVK or vkd3d-proton, there are already contributions from NVIDIA engineers, especially around driver-related issues. How much additional work happens behind the scenes (spec work, internal coordination, debugging) is something we simply don’t have visibility into.
Forum dynamics probably also skew perception a bit - more aggressive posts tend to get downvoted or hidden, so what remains visible is usually the more reasonable part of the discussion.
So I’d say it’s less about people explicitly blaming engineers, and more about how some arguments can unintentionally come across that way.
That said, I do agree with your core point that criticism of corporate decisions (staffing, priorities, transparency) is valid.
No one operating in good faith and who understands the technical details wants the driver in-tree. There is zero reason for most drivers to be in-tree. Being out of tree does not mean these things can’t be done.
AMD has had a long list of bugs that took months to fix and rollout to distros. I guess we’re at the amnesia part of the infinite cycle where the Linux community pretends that AMD is perfect or something. Give it a few weeks and there will be a nasty kernel bug introduced and you’ll go back to “well, it’s Open Source so fix it yourself” or “atleast it’s open so people can fix it” or something like that.
Edit: oh, I somehow forget about new hardware support which is consistently terrible under AMD because of out of tree drivers.
It seems there’s some new fixes on the VK_EXT_descriptor_heap from Nvidia’s side. Seems things are improving slowly but steadily. I hope before year’s end things will be a lot better.
If anyone’s tried this please let us know if it changes anything.
(Edit: I just recently upgraded to an RTX5070 all the way from a GTX970 last week so i’m kinda excited about any possible developments rn 🤠)
Since you are quoting the development re: 595.44.06, did you notice the latest Beta driver, which is 595.45.04 already? Maybe that one has something to offer for you, if you are keen on testing things out. :-)
They use different versioning. The vulkan beta is different (newer) than 45.
Good point. Thanks for the correction.