Hacker News Reader

Comment by LargoLasskhyfv | Hacker News Reader

By NVIDIA supporting FreeBSD you mean that half-assed thing with binary drivers allowing you to get a picture, but no CUDA?

Or is that old information which i should forget?

View on HN

Sure, the factual parts of that are accurate. Your opinion colors some of the adjectives. OpenGL works well, for example. No CUDA, no NVENC/DEC.

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.

https://github.com/shkhln/nvshim

While i respectfully congratulate the authors of that shim for their ingenuity, that is no support.

Nothing drastically changed since Torvalds had sended his gratitude[0].

[0] https://youtu.be/MShbP3OpASA?t=2997 (time coded)

I concur.

Wayland support fiasco, changes in driver's EULA to deny the usage of consumer-grade GPUs in VMs are 2 things off the top of my head.

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.

> changes in driver's EULA to deny the usage of consumer-grade GPUs in VMs

Which changes? Where? I'm looking at said EULA right now and I don't see anything related.

My bad, it was a silently added "feature" in Windows driver[0].

[0] https://wiki.archlinux.org/index.php/PCI_passthrough_via_OVM...

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.

> FreeBSD easily achieves binary compatibility with earlier versions. So no need to mess around with DKMS

Binary compatibility is for userspace programs, not kernel modules.

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.

This is unrelated to COMPAT_FREEBSD.

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.

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.

If anyone has any clout to get this to happen, John Carmack perhaps would.

Unfortunately, half-assed vendor support is still quite compelling compared to no vendor support.

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.

> Even AMD is often supported in a better way, be it opensourced, or relying on their binary blob.

AMD binary blob? You mean that amdgpu-pro thing? That doesn't exist on FreeBSD.

Maybe not the latest and greatest "Pro", but otherwise?

https://wiki.freebsd.org/Graphics/AMD-GPU-Matrix

edit: maybe should have added https://www.x.org/wiki/RadeonFeature/#index5h2 too

Reply on news.ycombinator.com