nettester I can't really speak for AMD as i have little experience with their drivers
Here's the source code for amdgpu in the Linux kernel. You can browse the rest of the drm/kms stack by going backward in the directory path.
Intel and AMD are among the top 5 single corporate entities to contribute most to the Linux kernel yearly, and have employees specifically set to develop and maintain the Linux drivers.
These developers actively cooperate with freedesktop.org (home of Mesa3D, libdrm, libGL, X11, nouveau) through their mailing list.
Unsurprisingly Intel and AMD are, respectively, platinum and gold members of the Linux Foundation.
Nouveau is a reverse-engineered driver whose reason of being lies in the fact that for a long time Nvidia not only kept their drivers proprietary, but also refused (with a growing number of exceptions over the years) to release any documentation around the chips they manufactured. The kind of performance you can get with nouveau is poor if compared against that of the proprietary nvidia driver or that of amdgpu on comparably powerful graphics. This is due to the reverse-engineered nature of the driver.
All BSDs have their drm/kms stack entirely ported from Linux. Porting is orders of magnitude more time-effective than re-writing drivers of such complexity from scratch and ensures that still BSDs have good-quality drivers, from a performance and security standpoint (in spite of the considerably smaller amount of contributors, and their mostly non-paid volunteering activity).
Linux modules obviously can't be loaded "as-is" and the "official" driver is mostly closed source
Since mid-2022, Nvidia GPU Kernel Modules are mostly opensource and MIT/GPL double-licensed, with the exception of user-stack components relative to Vulkan and CUDA support.
As i understand it Nvidias (kernel) driver is structured like this: On one side there is the "real" driver code which is a closed source binary blob but then on the other side there is some glue code to avoid directly linking against Linux kernel API (probably to avoid triggering the GPL and also not have their blob tied to a specific kernel version).
You're probably referring to the kernel interface layer. For the FreeBSD counterpart (see below), untar the latest FreeBSD driver version and have a look into src/nvidia
i am not sure if it's still around but for some time an official FreeBSD Nvidia driver was a thing
Nvidia still officially releases drivers for FreeBSD (alongside Windows, Linux and Solaris). Vulkan is supported on FreeBSD since 2021.
From my experience (which spans across several years of parallel use of Linux and FreeBSD with Nvidia), nvidia proprietary drivers are much easier to use and deal with on FreeBSD than they are on Linux. No separate non-free repositories to manage, no troublesome DKMS, no broken drivers at each minor kernel update (unlike Linux, BSDs keep a stable kernel ABI within each major release), no having to mess with blacklisting nouveau , no trouble setting up a second monitors....it just works.
From my understanding Nvidias glue code is basically a very specific "emulation" layer. In it's official form it implements Nvidias API on top of the Linux kernel API and given that the relevant functionality provided by NetBSDs kernel would probably be pretty similar it doesn't seem "that" far fetched to adjust it.
What throws me off is mostly that if it where "so" easy (patching glue code) why didn't anyone think of it beforehand? I am very likely not the first person to have read the source of the open part for Nvidias driver. I am almost certain that i have to be missing some important points here. The open part of Nvidias driver is actually quite huge and i didn't study it in detail.
Many installed components, among which required shared objects (basically anything installed under $PREFIX/lib, the nvidia_drv.so X display driver and its extensions), are shipped as binary blobs, dynamically linked for the target platform (e.g. FreeBSD, or Linux). I'm unsure whether the NetBSD's compat_linux would have been capable of handling this. Besides that, the large OS-agnostic components of the
nvidia-modeset kernel modules also come pre-compiled as object files for the target platform they're meant to be linked onto. These would have been unusable on NetBSD. The are probably also LICENSE/TOS concerns to take into account...
Such issues could be considered sorted out now with the opensource nvidia driver version.
However, try browse the Nvidia GPU drivers code and perform a recursive case-insensitive grep for
linux. You'll find out that OS-specific support is scattered in the code in a more pervasive way than if simply confined to a separate compat layer bundled with the driver.
Porting something as big as a drm driver to a news OS takes a lot of time, skill and effort. After which you'll be presented with a significant number of bugs and edge-cases to deal with before being able to deliver if to the end-user (see the number of PRs in the GNATS database concerning the drm/kms update in NetBSD-10 and delaying its release).
FreeBSD uses the linux(4) compat layer, optionally in conjunction with x11/linux-nvidia-libs to support the nvidia driver.
So why haven't the BSDs ported the Open GPU Kernel Modules yet?
FreeBSD have a fully functional implementation of what is now largely and opensource driver. So they're probably not interested in maintaining a downstream fork.
OpenBSD would most likely reject the idea of a closed-source third party software being added to the memory image of the running kernel. Now that drivers are opensource, they might change their mind.
I think NetBSD devs wouldn't have liked the idea of binary blobs either. Moreover, NetBSD is the only BSD to have ported nouveau and to provide in-kernel support for nvidia chips as of today. I think that the project and the community are fine with nouveau at least until (and if ever) the official nvidia opensource drivers don't become a de facto standard on Linux. In perspective, nouveau development may also benefit from having nvidia code at hand.