Can anyone ELI5 this for me?
Does this mean NVidia GPUs don't need the proprietary driver anymore? Does this put NVidia on par with Radeon via amdgpu/RADV regarding OSS Linux support?
Nice, it's getting closer to Linux gamers with Nvidia GPUs ditching the blob and switching to Nouveau + Mesa.
I'm not a GPU driver or graphics programmer, so I'll do my best. Hopefully someone more knowledgeable can chime in if I mess something up.
* Last May, Nvidia open-sourced their proprietary kernel module, after moving their proprietary bits into a firmware blob that runs on the GPU itself. As is, this module is not suitable for being mainlined into the Linux kernel, but acts as a starting point for a proper FOSS module.
* Nouveau developers have been able to use code and knowledge from the open-sourced Nvidia module to improve their mainlined kernel module (more low level hardware access, the ability to load said firmware blob, and the ability to control clock speeds/power states).
* The improved, actually useful Nouveau has allowed for the development of a performant user-space Vulkan driver for Nvidia called NVK, which was mainlined into Mesa a few months ago.
* Today's news is that NVK is now Vulkan 1.0 conformant, which means properly written apps that use the Vulkan 1.0 featureset should work and be performant using Nouveau and NVK/Mesa
> Last May, Nvidia open-sourced their proprietary kernel module, after moving their proprietary bits into a firmware blob that runs on the GPU itself. As is, this module is not suitable for being mainlined into the Linux kernel, but acts as a starting point for a proper FOSS module.
There will probably be no new kernel driver. Nouveau can get the job done now via the proprietary GSP.
> The improved, actually useful Nouveau has allowed for the development of a performant user-space Vulkan driver for Nvidia called NVK, which was mainlined into Mesa a few months ago.
It's faster now, but still slow as a brick. A lot of optimization work is required, but I guess the developers will focus on reaching conformance with more Vulkan versions. By implementing some additional extensions, modern OpenGL versions and OpenCL can then run via Zink and RustiCL. This will make the driver actually useful, hopefully attract users, and help to find bugs and optimization opportunities. Eventually, a native OpenGL driver [edit: actually a Mesa State Tracker] might be required since Zink has a lot of overhead.
How big of a deal would proper native OpenGL support actually be? My understanding is that OpenGL is more or less deprecated, and any performance heavy graphics applications have long since switched to Vulkan. I would think the performance overhead of a translation layer like Zink would go largely unnoticed when running software old enough to need it on a modern GPU.
OpenGL is deprecated on MacOS only. It remains fully relevant on many platforms, else OpenGL 4.6 would have never happened. Existing heavily optimized legacy applications (especially games) are unlikely to ever switch to Vulkan if no clear advantages can be demonstrated.
Zink is very useful and maybe the best option if existing drivers are buggy or not that performant. But the performance impact is usually very apparent.
I know OpenGL is still used, but it's not used much for performance intensive applications like AAA video games, it's used for things like desktop compositors, largely because the spec hasn't been improved or changed since 2014.
Maybe Zink is uniquely inefficient, but my frame of reference for how fast these translation layers can be is DXVK, which in some cases is even faster than native when translating DX11 to Vulkan.
I think there is already an OpenGL implementation over Nouveau (4.5 level)? So that can exists as is, or Zink can be an option. And remaining 4.6 parts are Vulkan related, so may be it can reach 4.6 without Zink too now.
What is slow in this case? 1% of the NVidia driver performance or 70%? I could stomach some hit to performance to drop the binary blob.
It was ~5% because there was no reclocking whatsoever without GSP support.
Nouveau was never most performant driver, but developers still been able to achieve something like 50-80% performance on 6xx 7xx series cards before Nvidia started to signed firmware shenanigans.
It's not like I defending the driver performance, but considering for decades it was purely reverse engineering effort by skeleton team < 10 people their achievements are outstanding.
https://www.phoronix.com/forums/forum/linux-graphics-x-org-d...
It depended a LOT on the workload.
valley? 20%
glmark2? 91%
vkmark? 11%
To some degree this is probably just the vulkan driver and compiler being really, really immature. I expect that the gap will become a LOT closer in the next 6 months, or whenever they get past implementing vulkan 1.3 in the compiler and can put some work into cleanup.
If you only get 5% of the power of the device why not simply use the CPUs?
Ouch. That's a bit more than I am willing to handle.
Can they reclock the memory and processing cores to the rated speeds, voltages to the rated voltages, and fans to the speeds that prevent things from melting? That's been _the_ stumbling block for a long time, although maybe that's changed in the last year or two.
Pretty sure they can when it comes to much older cards and those Turing+. I think there's a weird time in between uhmm generations (like Maxwell maybe) in which it's not possible. I don't think it's possible with my 960M for example, although I might be wrong.
Yes, this is indeed a replacement for the proprietary driver. However, Vulkan 1.0 is the most basic version of Vulkan. Right now we are at 1.3, plus there are many Vulkan extensions which need to be implemented aside from the core version.
In other words, this is a good start, but with only Vulkan 1.0 you won't be able to use something like DXVK, for running DirectX games with Proton/Wine.
For what it is worth, the blog post claims that 1.3 compatibility is not too far away, "We're not very far off from being able to advertise Vulkan 1.3 but it's all compiler work between here and there."
Vulkan > History: https://en.wikipedia.org/wiki/Vulkan
DXVK: https://github.com/doitsujin/dxvk
Tbh, I'm more eagerly watching the development of rusticl on nvidia hardware. While I use graphics APIs more often, not needing nvidia's drivers for their CUDA support would be really nice.
Say what you will about openCL, but openCL is a WAY BETTER IDEA than ROCm. AMD are getting their asses handed to them in card support right now because ROCm requires you to compile your application all the way down to shader binaries. That makes applications supporting their cards VERY non-portable. Nvidia on the other hand supports PTX which is portable across a wide range of cards and drivers.
OpenCL mirrors this by allowing you to write compute kernels in normal shader languages to be compiled by the driver. It doesn't matter what card you want to run something on, with rusticl ALL cards can run the same code, including across vendors. AMD, nvidia, intel, raspi, apple AGX, doesn't matter. You can even run it on top of zink in case all you have is a proprietary vulkan driver.