4 ms·

Nvidia's "Blob" approach does have an advantage when it comes to supporting random OSes. It's less of a driver and more of an operating system. Basically self-

by phire 6y ago

Nvidia's "Blob" approach does have an advantage when it comes to supporting random OSes. It's less of a driver and more of an operating system. Basically self-contained with all the support libraries it needs. Super easy to port to a new operating system and any driver improvement work on all OSes. But the approach also has many downsides. It's big. It ignores all the native stuff (like linux's GEM interface). It also has random issues with locking up the entire system. Like if you are debugging a process with the linux drivers, a breakpoint or a pause in the wrong place can deadlock the system.

magic_quotes 6y ago
Native Linux stuff is not at all native for FreeBSD. If Nvidia suddenly decides to open their driver (to merge it into Linux), FreeBSD and Solaris support will be the first thing thrown out.
loeg 6y ago
You say that, but: Nvidia's "blob" driver doesn't have CUDA, NVENC/NVDEC, nor DDC I2C support on FreeBSD — despite all of this functionality being specific to Nvidia's own hardware, and the support being present in the Linux blob, which runs on a relatively similar platform. If the only differing bits were the portability framework, this would just be a matter of adding missing support. But it isn't — the FreeBSD object file Nvidia publishes lacks the internal symbols used by the Linux driver.
- magic_quotes 6y ago
  > If the only differing bits were the portability framework, this would just be a matter of adding missing support. But it isn't — the FreeBSD object file Nvidia publishes lacks the internal symbols used by the Linux driver. In fact it is. For Linux and FreeBSD Nvidia distributes exactly the same blob for compilation into nvidia.ko; the blobs for nvidia-modeset.ko are slightly different. (Don't take my word for it, download both drivers and compare kernel/nvidia/nv-kernel.o_binary with src/nvidia/nv-kernel.o.) Nothing is locked in the closed source part.
  - loeg 6y ago
    The userspace CUDA/NVENC libraries are distributed as pre-compiled artifacts in the Linux driver, and no such FreeBSD library is distributed in the FreeBSD driver package.

by phire 6y ago

magic_quotes 6y ago

Native Linux stuff is not at all native for FreeBSD. If Nvidia suddenly decides to open their driver (to merge it into Linux), FreeBSD and Solaris support will be the first thing thrown out.

loeg 6y ago

You say that, but: Nvidia's "blob" driver doesn't have CUDA, NVENC/NVDEC, nor DDC I2C support on FreeBSD — despite all of this functionality being specific to Nvidia's own hardware, and the support being present in the Linux blob, which runs on a relatively similar platform. If the only differing bits were the portability framework, this would just be a matter of adding missing support. But it isn't — the FreeBSD object file Nvidia publishes lacks the internal symbols used by the Linux driver.

magic_quotes 6y ago
> If the only differing bits were the portability framework, this would just be a matter of adding missing support. But it isn't — the FreeBSD object file Nvidia publishes lacks the internal symbols used by the Linux driver. In fact it is. For Linux and FreeBSD Nvidia distributes exactly the same blob for compilation into nvidia.ko; the blobs for nvidia-modeset.ko are slightly different. (Don't take my word for it, download both drivers and compare kernel/nvidia/nv-kernel.o_binary with src/nvidia/nv-kernel.o.) Nothing is locked in the closed source part.
- loeg 6y ago
  The userspace CUDA/NVENC libraries are distributed as pre-compiled artifacts in the Linux driver, and no such FreeBSD library is distributed in the FreeBSD driver package.