Glad to hear this, but I won’t be jumping for joy just yet
1 Like
And Nvidia proves their sense of timing is way off AND their tonedeafness by providing a tacky April fools joke only 40 days late to the party. 
… Yes, I’m kidding. This just made Nvidia a serious contender for my next GPU purchase again! Awesome news! 
1 Like
When you say “Teslas” do you mean the workstation cards, or the cars? If you meant the cars, are they not (already open source) Tegras?
The server cards, the Maxwell cards are cheap enough
1 Like
Don’t they get toasty when they’re not in a server rack? Most of them don’t have their own fans.
I have a thread, basically I was hoping for a more turn key solution on Linux with a script if they opened up the driver
2 Likes
That does not sound like it is the case here; whereas the old, pre-GSP (GPU Support Processor) implementation was:
Pre-Turing: userland code → kernel code → hardware
The GSP driver architecture moves more tasks to the GPU itself:
Turing/Ampere: userland code → kernel code → GSP code → hardware
Note that there was still a microcontroller called Falcon/FUC/FΜC/fµc before the GSP, but it appears to have done far less.
Of that chain of code, only the kernel part has been open sourced, userland is still completely proprietary:
NVIDIA’s user-space libraries and OpenGL / Vulkan / OpenCL / CUDA drivers remain closed-source – today’s announcement is just about all the excitement in kernel space.
Though there is some hope regarding nouveau userland:
Asking about it to NVIDIA, they say that hopefully Nouveau will be able to utilize the GSP firmware / open kernel modules but first will likely take time for the GSP firmware interface to be stabilized and other factors. Thus in the future when this kernel driver is in better shape, Nouveau’s Mesa code may end up interfacing with this kernel driver as an alternative to the Nouveau DRM kernel driver that is in rather rough shape for hardware newer than the GTX 600/700 Kepler series.
As if for maximum confusion, was there not also a Tesla microarchitecture?
3 Likes
You’ll be telling me there was a man next xD
4 Likes
Of course not; the man is fictitious. The legend of Nikola Tesla was created as part of a legal argument by disgruntled employees of General Electric in the 1930s. After they lost the intellectual property case, the story was basically forgotten, except as an aspirational tale Serbian-American parents sometimes told their children.
It was only decades later when the legend had basically died out that Tesla Motors used the name of the character to brand itself; using mythical stories to brand companies being hardly a rare phenomena, as “Oracle” would attest. Some years later, Tesla Motors brought the story back into the limelight when, as a publicity stunt, it posed an abandoned property as the site of Tesla’s laboratory, and arranged a funding campaign to “save” the property and in so doing promote the Tesla brand. Rumours are that the whole stunt even turned a profit.
wearing this tin-foil hat was kind of fun
2 Likes
On a more serious note, Phoronix does have an initial performance comparison between the open and proprietary kernel components of the Nvidia 515.43.04 driver:
1 Like
Hmm, after the initial excitement, I am revising my statement. AMD is still the preferred Linux vendor for me, and will be for at least the current and next generation. This is because it will take time to get this driver to maturity, but at least we got one now.
To be clear, I am still waiting for four things to happen before I can seriously consider Nvidia;
- Open Source kernel module
- … Upstreamed into main kernel tree, the way AMD is
- … With proper power management
- … And proper Mesa driver support (Zink + Kopper + Vulkan = AWESOMENESS)
Unfortunately Nvidia only (barely) provides #1 right now. It is a large step in the right direction, but once it is upstreamed and power management implemented, then Mesa can take care of the rest. 
So, my analysis; Awesome job Nvidia, it is a start and if you keep up this pace, by 2024 you should be a worthy competitor to AMD / Intel on the Linux side, instead of always having to play second fiddle in terms of user experience.
2 Likes
Unfortunately they won’t be supported. That’s the big letdown of many Maxwell and Pascal Quadro or Tesla cards.
I’m certain once we have standardized EGL and GL shared libraries a lot of the nightmares of Nvidia and Flatpak will basically be gone.
LLVM on Nvidia is a interesting prospect too for Vulkan and OpenCL.
Could you elaborate? I am unfamiliar with GL/EGL/Flatpak issues on Nvidia, or any trouble with LLVM; I thought LLVM was mandatory for SPIR-V, which replaces GLSL in Vulkan (optionally in OpenGL as well I think).
Personally, I will still prefer AMD, since as far as I know, more of the full stack will still be open than Nvidia even if Nvidia userland is made open source.
I want the maximum possible control over the running code and behaviour of hardware that I buy. Though I am probably representing a minority viewpoint; if I had the money for it, I would be moving to POWER9.
What about volta? It was a weird in-between one
Not familiar with Nvidia + Flatpak issues specifically, but an educated guess is that the Flatpak is required to dynamically link to the Nvidia symbols, and suspecting Nvidia Linux drivers don’t really have a stable ABI due to kernel not having a stable ABI.
Could be wrong here, this is just an educated guess from a low level embedded dev.
This is the kind of stuff that an open kernel module would let you do, adding new interfaces to expose existing functionality:
2 Likes
It’s kinda cool to already see a ton of Pull Requests going into this, IMO Already over 30 bug fixes and 40-or-so other contributions and optimizations, ranging from “Fixed up the punctuation here” to “I reduced this loop from taking 5s to 2.5s”.
I mean, these last four days alone, Nvidia got the equivalent of like, at least two man-years of engineering time.
And people say opening the source doesn’t give you anything…
2 Likes
Just check if it has the RISC-V coprocessor. If it doesn’t, you can’t use these drivers.
Most poorly configured Flatpaks use libGL from Flatpak rather than NVIDIA’s special snowflake one. This is the root cause of why VLC blank screens when using the Flatpak on NVIDIA.