Bryan Cantrill talked extensively about how long it took for Sun Microsystems to open source Solaris, and a lot came from code that was often outsources because it was "boring" and basically non-core tech (the example was i18n/l10n)
AMD is something like 10% of the total Linux kernel size now which is ridiculous. But their commitment in recent years is admirable as hell
NVIDIA need to pull their fucking head out and just start working on Nouveau
The driver code itself also has lots of code duplication. It's just strange.
I've had enough issues with ideologues precenting any meaning full progress
- it is a driver, not a core module
- the constants are implementation details of the driver
- active maintenance of code is a necessary condition for inclusion in the Kernel. The other Kernel developers are not supposed to maintain and refactor code dumps.
Intel's stack is already pretty open on Linux.
There was no hardware at all on which you could rely on it, on top of it being much worse than CUDA.
Me memory isn't perfect, but IIRC the situation was roughly the following: We were quite short on resources (both devtime and money), which meant that we had to choose our scope wisely. Optimally we would have implemented both CUDA and OpenCL 2.0, but we had to settle for OpenCL 1.2 (which offered reduced performance, but was "good enough" for inference). IIRC OpenCL 2.0 was very very similar in what capabilities it assumed and offered to the CUDA version at the time, and cards like the GTX Titan X had "compute capabilities" that supported features like shared virtual memory between CPU and GPU in CUDA at the time. In fact the advances around memory management (and async copying) that were present in CUDA and not in OpenCL 1.x were the main source for the performance differences between the two.
From everything that I can tell at that point in time, if NVIDIA would have wanted to support OpenCL 2.0 they could have done so based on technical requirements. What the reason for not doing so is, is just pure speculation (lack of internal resources due to focusing on devtools?), but to me it always looked like they were using the edge they got via their proprietary libraries like cuDNN to get a foot into the field of ML and then purposefully neglected OpenCL to prevent any competitors from catching up. Classic Embrace, Extend, Extinguish.
Then again, it sounds like OpenCL 2.0 required some flexibility the nvidia drivers or hardware wasn't able to provide.
It's pretty hard to speculate to which degree nvidia was intentionally sandbagging here, and to which degree it really was stuck.
However, it's a member of khronos, and it's hard to believe they as such a major manufacturer could not have either said beforehand that the spec was a problem or simply complied with it; as both AMD and intel did.
Also, given CUDA's success it's all rather convenient for nVidia - at the very least it looks like they didn't mind leveraging their market position for continued market dominance, even if it's unclear whether that was an intentionally anti-competitive aim from the get go, or simply a fortunate happenstance they didn't try to avoid.
Then again; with antitrust enforcement mostly remaining in vaporware mode it's a little hard to blame them.