*The nvidia driver is already fully native.* nvidia.ko (from the nvidia-driver pkg) is a genuine FreeBSD kernel module; it has nothing to do with the Linuxulator. To "activate" it you do pkg install nvidia-driver + kldload nvidia, and that's it — zero Linuxulator. That was never the problem.
Shkhln's shim (libc6-shim + uvm_ioctl_override.c) is *not* the Linuxulator. It's the opposite. By design it loads CUDA's Linux .so files into a *native FreeBSD* process, translating the glibc calls — it does not emulate Linux syscalls, and the process doesn't need linux.ko active. You said it yourself on the forum back in 2022: "I'm out of any jail and I don't use the Linuxulator," with blender/obs via nv-sglrun. So the path you're after already exists: nv-sglrun with that uvm_ioctl_override.c in LD_PRELOAD. *The honest boundary* — and here I have to be precise, because it's the difference between "you can do it" and "you can't." "CUDA functionality without the Linuxulator" works when *the application consuming CUDA is a native FreeBSD binary* (or a .so that libc6-shim can host). The demonstrated native cases are OpenCL (clinfo sees the CUDA platform), NVENC/NVDEC, OpenGL, nvidia-smi. What pulls you back into the Linuxulator *is not UVM and not the driver* — it's the application itself when it's Linux-only. Example: PyTorch runs on Linux Python, and *that* is Linux userspace you don't have natively, so you're back to Linuxulator/container. Not because of the GPU, but because the app is Linux. *What consumes CUDA on your side?* If it's native FreeBSD code (or things libc6-shim can host: OpenCL, NVENC, ffmpeg, your own executable linking libcuda) → you're already Linuxulator-free, and the shim + nv-sglrun is all you need, no port. If instead it's a full Linux app like PyTorch/Python → the Linuxulator (or a container) is needed for *the app*, and no GPU-side work removes that — neither the shim nor the port. On Sun, Jun 21, 2026 at 8:07 PM Mario Marietto <[email protected]> wrote: > The FreeBSD NVIDIA driver *does* expose the underlying UVM (unified > memory) kernel interface CUDA needs. shkhln's libc6-shim translates the > ioctls, which is why people have gotten CUDA workloads running — and the > route that's matured most is running a Linux user space under the > Linuxulator. As of 2026 there's active work (NapoleonWils0n's freebsd-cuda) > running Linux CUDA applications on FreeBSD by mounting the host's > Linuxulator NVIDIA libraries into Podman/Rocky Linux containers, so the > driver lives on the FreeBSD side and the container doesn't need its own. > Ollama, PyTorch, and similar have been confirmed working that way. So > CUDA-on-FreeBSD effectively exists today, but as a Linux-compat > construction rather than a native toolkit — fine for headless/batch, > clunkier as a clean desktop Blender story. FreeBSD > <https://forums.freebsd.org/tags/cuda/> > > ROCm and oneAPI are in worse shape than CUDA, not better. ROCm depends on > AMD's amdkfd kernel compute driver, which isn't in drm-kmod, and the > userspace is famously bolted to specific Linux kernel versions. oneAPI > needs Level Zero plus intel-compute-runtime, again Linux-kernel-coupled. > Neither has a FreeBSD port, and there's no upstream effort I'm aware of to > make one. > Mario. > > > On Sun, Jun 21, 2026 at 6:59 PM mghackerlady <[email protected]> > wrote: > >> Ah, silly me. Correct me if I'm wrong, but isn't it running in a >> linuxulator? Not a massive issue if so, but I was interested in native >> support >> >> On 2026-06-19 16:23, Mario Marietto wrote: >> >> ---> Hello! I'd love to run FreeBSD as a workstation OS, and am wondering >> if there are any plans to support CUDA >> >> FreeBSD already gained the support for CUDA : >> >> >> https://forums.freebsd.org/threads/can-cuda-be-installed-on-freebsd-now.85879/ >> >> On Fri, Jun 19, 2026 at 11:15 PM Maple <[email protected]> wrote: >> >> Hello! I'd love to run FreeBSD as a workstation OS, and am wondering if >> there are any plans to support CUDA or some other GPU compute platform like >> oneAPI or ROCm? It'd be useful for blender users like myself, and while I >> doubt there are many people considering FreeBSD for CAD or video editing >> workloads, it'd give FreeBSD a foot in the door there. >> >> I can also see FreeBSD being used for render farms should one of these >> technologies be adopted, but I am a desktop user interested in other things >> (hence the desktop mailing list) so perhaps there's something else that >> would prevent that >> >> >> >> -- >> Mario. >> >> >> > > -- > Mario. > -- Mario.
