Some may have seen this article: https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-Kernel-Driver-Source. I know it was posted a few days ago on HN and dismissed as the `nvgpu` driver (the source tree for nvgpu, at least from a preliminary search, is not even close to what was released yesterday). Curious for myself, I downloaded the driver and investigated.<p>When you download a regular desktop NVIDIA driver on Linux, you get a file called `nv-kernel.o_binary`. This is the binary blob, to my knowledge, that is used over a shim that is FOSS (to get around Linux licensing restrictions). When I downloaded this new Tegra driver, it had a modified version of the `nv-kernel.o_binary`'s source code. As in, if I run make in the directory, it compiles all the files and gives me an `nv-kernel.o`. Furthermore, looking through the actual code, there seem to be implementations of several functions that are in the binary blob that I can read in physical, hard C code.<p>To (perhaps) prove to you this isn't just some ordinary thing, look at a reverse-engineered file of NVIDIA ioctl structs: https://github.com/envytools/envytools/blob/master/demmt/nvrm_mthd.h#L46.<p>File `src/common/sdk/nvidia/inc/ctrl/ctrl0000/ctrl0000system.h` from the new Tegra driver (remember, this is MIT licensed, you can download the code yourself, it's at https://developer.nvidia.com/embedded/jetson-linux-r341), line 112;<p><pre><code> #define NV0000_CTRL_CMD_SYSTEM_GET_BUILD_VERSION (0x101) /* finn: Evaluated from "(FINN_NV01_ROOT_SYSTEM_INTERFACE_ID << 8) | NV0000_CTRL_SYSTEM_GET_BUILD_VERSION_PARAMS_MESSAGE_ID" */
#define NV0000_CTRL_SYSTEM_GET_BUILD_VERSION_PARAMS_MESSAGE_ID (0x1U)
typedef struct NV0000_CTRL_SYSTEM_GET_BUILD_VERSION_PARAMS {
NvU32 sizeOfStrings;
NV_DECLARE_ALIGNED(NvP64 pDriverVersionBuffer, 8);
NV_DECLARE_ALIGNED(NvP64 pVersionBuffer, 8);
NV_DECLARE_ALIGNED(NvP64 pTitleBuffer, 8);
NvU32 changelistNumber;
NvU32 officialChangelistNumber;
} NV0000_CTRL_SYSTEM_GET_BUILD_VERSION_PARAMS;
</code></pre>
Notice how the sizeof's of each struct, whether the reverse engineered one or the new one are the same (EDIT they're not, but they're similar in size which could be an RE error, and the operation hex code is the same). Not only do we know what this undocumented ioctl does now, we also have its struct members' names and purposes that you'd pass when trying to issue that ioctl (NVIDIA ioctl structure has an argument parameter (second ioctl param) and then a structure (third ioctl param) that has all the data including these op_types I'm talking about here.<p>Another example (this time you can see the RE'ed and the official driver match). Try finding this code online, you'll only find a Gist with the name (NVIDIA driver going OSS):<p>https://github.com/envytools/envytools/blob/master/demmt/nvrm_mthd.h#L136 vs. src/common/sdk/nvidia/inc/ctrl/ctrl0080/ctrl0080gpu.h (line 260):<p><pre><code> #define NV0080_CTRL_CMD_GPU_MODIFY_SW_STATE_PERSISTENCE (0x800287) /* finn: Evaluated from "(FINN_NV01_DEVICE_0_GPU_INTERFACE_ID << 8) | NV0080_CTRL_GPU_MODIFY_SW_STATE_PERSISTENCE_PARAMS_MESSAGE_ID" */
/* Possible values of persistentSwState */
#define NV0080_CTRL_GPU_SW_STATE_PERSISTENCE_ENABLED (0x00000000)
#define NV0080_CTRL_GPU_SW_STATE_PERSISTENCE_DISABLED (0x00000001)
#define NV0080_CTRL_GPU_MODIFY_SW_STATE_PERSISTENCE_PARAMS_MESSAGE_ID (0x87U)
typedef struct NV0080_CTRL_GPU_MODIFY_SW_STATE_PERSISTENCE_PARAMS {
NvU32 newState;
} NV0080_CTRL_GPU_MODIFY_SW_STATE_PERSISTENCE_PARAMS;
</code></pre>
In addition, I found other evidence of a possible open-source NVIDIA driver. A prior HN article: https://www.collabora.com/news-and-blog/blog/2022/03/23/how-to-write-vulkan-driver-in-2022/, clearly highlights that Collabora is working on a FOSS Mesa Vulkan driver for NVIDIA GPUs.<p>> I'm going to pick on NVIDIA because... Why not? Such a driver is clearly missing and really should happen soon. (Hint! Hint!)<p>Furthermore, https://blogs.gnome.org/uraeus/2022/02/01/getting-rid-of-the-need-for-the-usecase-linux-distribution/.<p>> while I am not at liberty to mention any details I think I can at least mention that we are meeting with our engineering counterparts at NVidia on almost a weekly basis to discuss how to improve things, not just for graphics, but around compute and other shared areas of interest. The most recent public result of that collaboration was of course the XWayland support in recent NVidia drivers, but I promise you that this is something we keep focusing on and I expect that we will be able to share more cool news and important progress over the course of the year, both for users of the NVidia binary driver and for users of Nouveau.<p>Why would NVIDIA take their binary blob and open source at least some of it under MIT (revealing new details about how their GPUs work)? Their Tegra driver is clearly not the old one, it has references to enterprise GPUs and features like vGPU, GRID, and VMware ESXi. Why is Collabora working on a FOSS NVIDIA Vulkan driver? Why are people saying something regarding NVIDIA is under wraps?