FreeBSD Experimenting with a Port of Nvidia's Linux Open DRM Kernel Driver | Hacker News Reader

FreeBSD Experimenting with a Port of Nvidia's Linux Open DRM Kernel Driver

phoronix.com

125 pointsmikece44 comments

Direct to the source, if that kind of thing interests you more than Phoronix: https://github.com/amshafer/nvidia-driver

I always do a double-take when reading "Open DRM". I wonder if those choosing the acronym did so on purpose.

It's a dumb name, to be sure, especially in an open-source context where everyone knows what "DRM" is and will have an overwhelmingly negative reaction to it.

Anyone who uses linux/freebsd will know what DRM actually means in this context

Doesn't make it any less annoying, from my own perception anyway. I have known about DRM standing for Direct Rendering Manager for years, but it's really annoying even today.

Sure, but it'll take a little longer to recognize the context, because the acronym is overloaded. It's like IPC. Or how "inflammable" means both "not flammable" and "extremely flammable".

Except DRM in this context is a Direct Rendering Manager [1] which is a slightly different struggle getting pixels onto the screen.

1. https://en.m.wikipedia.org/wiki/Direct_Rendering_Manager

Let's take a survey and ask people what "DRM" stands for.

I would bet a decent amount of money that the copyguarding one wins out over the rendering-manager one.

Unless you have a time machine, we can't go back and rename the subsystem.

How prominent was the phrase 'digital rights management' when Linux's direct rendering manager was created (Wikipedia says 1999)? The FSF's 'Defective by Design' anti-DRM campaign didn't start until 2006.

not at all, I recall that no one (outside of the music industry perhaps) used the phrase 'digital rights management' until iTunes added DRM to music in 2003/2004, other things like the copy protection for videotapes/DVDs/games were just generically called copyprotection, or other domain specific terms such as activation (in the case of things like windows XP), not DRM.

The "DRM" acronym for Direct Rendering Manager goes all the way back to the 1999 Linux driver for 3dfx graphics cards. It predates the "Digital Rights Management" acronym by at least 5 years.

I've always associated DRM with the [DMCA](https://en.wikipedia.org/wiki/Digital_Millennium_Copyright_A...) which was signed into law in 1998. Do you have a source for Digital Rights Management originating in the mid-2000s?

For what it's worth, the Oxford English Dictionary gives two citations for the phrase, one from January 1996 and one from May 2005. It's not obvious to me from the quoted text whether the 1996 citation actually has quite the same meaning as we're talking about here.

It's from something in PR Newswire, and it says: "As an industry consultant Bob has been a leader in developing business strategies and cooperative relationships in the area of digital rights management and content distribution."

And what's not clear to me is whether that's "digital (rights management)" -- i.e., using computer technology to enforce copyright etc., the usual present-day use of the term -- or "(digital rights) management" -- i.e., everything to do with handling copyright etc. in the specific context of digital data.

Neither DRM or Digital Rights Management are mentioned in the actual DMCA legislation. This terminology emerged later IIRC.

https://www.copyright.gov/legislation/dmca.pdf

Google Books Ngram Viewer shows 'digital rights management' taking off around 1996.

It's close though. An annoying clash that can't be fixed now.

https://books.google.com/ngrams/graph?content=digital+rights...

I'm not so sure about this claim. Here's a Microsoft press release from April '99 about digital rights management, which uses the DRM acronym throughout: https://news.microsoft.com/1999/04/13/microsoft-and-reciproc...

Seems like they filed for a patent that same month using the same terminology https://patents.google.com/patent/US7103574B1/en

Now what? FreeBSD and Nvidia? Dont threaten me with a good time. FreeBSD is so clean that i would love to build a sleek custom variant even if just for my own use, but i need graphics drivers. A “proper” nvidia driver would be amazing.

NVIDIA does have "official" freebsd drivers (including display drivers/etc) but it's obviously not as easy as with AMD. I've never tried using NVIDIA (or graphics at all) on freebsd tbh and I don't know whether the experience works well or not.

I do know there is no nvenc though oddly. because that's built around linux APIs too lol.

but yeah freebsd is pleasantly uneventful and well-documented, and the handbook tells you like 90% of the sysadmin job too. and it's well-integrated with zfs and time-tested.

it's a shame that docker is built around linux, that's where all the inertia is these days.

> it's a shame that docker is built around linux

There is some interesting work happening to get an OCI-compatible runtime working

https://github.com/samuelkarp/runj

theoretically this is a job for branded zones too, BSD actually solved this problem better a long time ago! just write a shim that hooks whatever linux layer to the kernel layer.

smartOS and proxmox both fill that niche for "hyperv, but it's application containers" niche perfectly. Or full VMs if you want too!

https://docs.oracle.com/cd/E19455-01/817-1592/gepea/index.ht...

https://en.wikipedia.org/wiki/SmartOS

https://en.wikipedia.org/wiki/Proxmox_Virtual_Environment

but for both the "making docker work with BSD" and "making BSD work with docker" approaches, the question is how much time a company will spend on an alternative, upstart tech for something as foundational as their container deployments, without a really compelling reason. the answer is likely "zero" and justifiably so. it doesn't matter that you can run a linux vm, it won't matter that zones work with docker or that docker can use OCI. nobody wants to discover a whole new set of bugs and footguns with a niche technology stack.

netflix really ran with it, but even they did not put application servers/containers on BSD, they just used it as a NAS store. which is fine, and that's something that can be encapsulated without letting BSD escape into the rest of your ecosystem. but even though the linux ecosystem is in a state of constant meltdown and rebirth, it's at least the enemy you know.

I wonder if that will change now that redhat has slammed the door on non-commercial users. like where do you even go after that? ubuntu is clownshoes (and the snapd stuff has offended a lot of users). Debian I guess, or OpenSUSE. But SUSE is quite niche as well. Debian is probably the "sufficiently boring" answer, but freebsd could be a good alternative too if places gave it a chance.

as I said it's very impressive how boring freebsd is. Most likely the thing you are trying to do will be either building/loading some module in /etc/rc.conf, or editing some config file in /etc/, or copying some template from /usr/local. And you just do it, there's no surprises, and you move on.

I ran FreeBSD on my nvidia laptop for around a year some time ago and the display drivers seems to work, as long as it was only as a display driver. It was an issue if you wanted vulkan, but that was recently added to the driver. Though if you wanted to play games or get hardware accel to work you would have to run it through a hacked glibc

https://github.com/shkhln/libc6-shim

Thanks for sharing. It would appear i was seriously out of date with the freebsd world, particularly nvidia drivers. I might dual boot linux and freebsd. As my first love, freebsd is the only os out there that i can say to me looks the most logical. I am curious if my wifi and sound speakers (infamous cirrus amps for which i had to modify my acpi tables to work in linux, trivial but not sure how in freebsd) work.

For me this post is very awkward because nVidia is the hassle-free graphics solution for the last two decades.

https://www.freshports.org/x11/nvidia-driver/

"Port Added: 2003-01-20 07:29:31"

As a FreeBSD user I haven't run anything else since 2005 and that has been the foundation of my workstation builds. Intel CPU/chipset and nVidia. FreeBSD driver was a bit slower to update to new version, and it never received any of the supplementary software, but that came along the line.

Edit : the summary of quality of drivers is right in the last paragraph in the article.

Great post. I feel the same. I look at the heroics done to make the linux Intel and AMD drivers work, and it seems like the current nvidia driver is far simpler. Eg, a binary blob with native wrappers. The only time it breaks is when the wrappers are stale; eg the kernel APIs that it depends on have changed. I run current, and I've only had an issue around the driver failing to compile or run correctly a handful of times in 2 decades, which is saying a lot for an out-of-tree driver.

Absolutely. And those hoops that occasionally happened through the years would happen to any 3rd party kmod package, regardless.

Nowadays for workstation usage RELEASE is good because it has quarterly. No need to track other branches to stay current with the packages, 4 times per year is enough for 99.9% of desktop users. So those kmod hoops are largely gone.

> Edit : the summary of quality of drivers is right in the last paragraph in the article.

yeah, honestly the problem with linux is the unstable kernel ABI, which BSD does not suffer from. And BSD also doesn't have the copyleft "can't link to anything not GPL'd" problem either.

it's not that NVIDIA's linux teams aren't good, actually they do a pretty good job with the linux driver, has a working GPGPU userland, etc (although the UI makes the windows one look futuristic, and there's been some spats around wayland etc). it's that the linux kernel doesn't care about ABI because of aggressive in-tree'ing of compatible modules, and proprietary binary modules will never be compatible with GPL unless there's some kind of a shim (like they've added). which does not apply to freebsd.

as I said, freebsd is astonishingly boring with how competently engineered and well-documented and stable the whole thing is, and it's a shame that docker/k8s is where the momentum is going. Jails are a great option (and docker is only just now starting to tackle some of the security theoretically open up a lot of support for linux applications/etc. it's just something that most orgs (rightly) won't devote even a minute to looking into, because it's not where the momentum is going.

not talking about backend services/etc here, but, if I had to design a long-life appliance where it needs to run for a long time with minimal supervision and oversight, and have minimal support costs, freebsd+zfs open up some neat options. FreeBSD is stable and long-life, so you're not going to find some critical system component churned out from under you by poettering or someone like that. And ZFS lets you deploy system updates as images/snapshots and do rollbacks to a known-safe version if something goes wrong or it fails to boot etc.

Nvidia has provided a native FreeBSD driver since basically forever.

It would appear i have been living under a rock. I always thought freebsd had zero working drivers for nvidia.

20+ years under rock.

Time flies. That coincides roughly with my switch to linux server side and macos desktop wise. But each time i gave freebsd a try somehow my gpu didnt work well. Have to try this again. I can run linux in a vm for docker and such but hope drivers work for my wifi and sound.

You are shifting goal posts!

I just realised those might be an issue :-) Going to test anyway. Hard to forget one's first love.

The only time I had problems with the Nvidia driver on FreeBSD was when KMS was introduced because it broke my existing configuration (visible screen tearing during video playback with mplayer in a floating window managed by i3). The solution wasn't pretty, but works to this day.

Would it allow CUDA support?

My question exactly :>

Long time FreeBSD'r myself going back to 2.2 and this has been the sticking point of the last couple of years for my org. Everything seems to depend on CUDA these days!

Yeah, I just built a system that I would love to have used FreeBSD on, but the driver (and CUDA) situation. It's a rough spot to be in.

I've returned to FreeBSD after many years, and I just built 14.0 to get CUDA working. CUDA doesn't need this to run AFAIK. This is about the kernel providing a module that allows a direct rendering interface. CUDA doesn't render to the screen. IIRC, DRI/drm are kernel drivers for graphics that map the GPU video memory window into your process so you don't have to copy data or send it though a pipe or some such nonsense. it was a video optimization from the early days of Linux graphics when copying

https://forums.developer.nvidia.com/t/cuda-and-nv-un-registe...

My only wish is to access RTX card from by FreeBSD or Ubuntu VirtualBox VM for ML/DL stuff on my windows 11 laptop.

That's supported in WSL, why not use that?

Thank you.

It would be cool if gpu passthrough worked.

Make LLMs write an eGPU driver for RTX cards over ThunderBolt!

Reply on news.ycombinator.com