Well it is a bit of a grey zone but I have gotten Vulkan to work and I think at least NVENC works as well. The solution is rather hacky though. It extracts libraries from the Linux driver and loads them when you run programs. A look at the code make it seems like cuda is getting loaded as well so it may work.
Nvshim is an amazing project, but it is a far cry from official Nvidia support for CUDA/NVENC/NVDEC.
(All Nvidia would have to do is build another binary; it's still chatting with the same driver blob internally so it's not really clear to me why they don't bother compiling it for FreeBSD.)
They could even do it with less churn, because of https://github.com/freebsd/freebsd/blob/master/sys/conf/opti... FreeBSD easily achieves binary compatibility with earlier versions. So no need to mess around with DKMS or their own thing. Or at least less so.
Ahem. Tell that to all the binary drivers for network cards and raid controllers which relied on that functionality, which i happened to use not all that long ago.
GP's link is to the COMPAT_FREEBSD binary compatibility for earlier versions of FreeBSD, oddly. I don't think it (or linux emulation) has anything to do with Nvidia's needs re: CUDA/NVENC.
It means you have a module from some vendor, or something similar to the NVIDIA installer for linux, which technically is nothing else than a batch compiled makefile, spitting out a kernel-module made for version 1.2.3 while you are running 2.4.5. It worked. I don't know why it shouldn't now.
Edit: I'm not having any FreeBSD systems in use right now, so i don't know if they changed the defaults. What i remember is at least the last two versions were compiled into GENERIC, so you didn't even had to compile your own kernel when that range backwards was enough.
Similar thing in NetBSD, a loooong time ago, even their own driver for 3Com905 relied on the equivalent of that functionality. That caught me by surprise, because i used NetBSD like Gentoo, found some Compat foobarjurassicBSD, wondered why i should use that at all, and had no working net. Fun! :-)
That's not how the nvidia binary blob works in FreeBSD. Instead, there is some compiled-from-source-code OS portability glue, which is compiled against the target version of the FreeBSD kernel. Then the binary blob links the portability glue.
I believe something similar is done in Linux. The difference in experience may come from FreeBSD maintaining a stable KBI over a release version (e.g., stable/12), while Linux aggressively does not maintain any KBI stability; hence the need for DKMS/akmods.
Sigh. Been typing too fast as usual. I know thats not the way the Nvidia-thing works, instead doing the glue-thing which interfaces to the binary blob like you mentioned. But it could (instead of that)! That's what i meant to say.
There was actually some period of time when the Tegra division (I think) contributed to Nouveau a bit (!) but that didn't really grow into anything good.
It depends on your use-case, i guess. If my intent would be using FreeBSD as my daily-driver "desktop/laptop-OS" i'd avoid NVIDIA like the plague, becaue without CUDA their unique selling point does not exist, but the hassle of some "switcheroo-black-magic" possibly persists.
Which i wouldn't have with an intel-gpu, also less power draw. Even AMD is often supported in a better way, be it opensourced, or relying on their binary blob.
Or is that old information which i should forget?