Solved Nvidia - Current status

J

jbo@

Developer
I'm a bit confused by the current state of support for nVidia GPUs with FreeBSD. I was hoping somebody could shed some light on the current situations.

From what I can tell, nVidia seems to provide drivers for FreeBSD for a wide variety of GPUs. As far as I can tell, these would work well with X11 but not with wayland. Is this correct?

I am running two desktop machines with Intel CPUs and nVidia quadro GPUs. As of today, I exclusively run Windows on these machines but I am getting somewhat frustrated with this experience. I'm looking into switching to FreeBSD as my primary desktop OS permanently. Unfortunately, I am really relying on these GPUs.
 
Not sure about Quadros, but "normal" Nvidia cards work fine. You need to be aware of the different versions of the driver and match that with your hardware.
Not sure about Wayland support, but X works fine. You may need to tweak X config, but a search here or asking should get you what you need.

I believe there is some level of support for quadros, but have never used them so can't be sure about support level.
 
Nvidia's proprietary drivers do support Wayland.

The problem is this:
Buffer APIGPU driver supportWayland compositor support
GBMAll except NVIDIAAll
EGLStreamsNVIDIAGNOME, KDE, Weston (with a third-party patch)

There are two competing APIs for compositors to talk to the graphics driver. Intel and AMD use GBM, Nvidia instead EGL. The reference implementation of a compositor also uses only GBM, so this is the preferred API by the creators of Wayland for this. But not every author of a compositor wants to implement two different APIs, so the number of compositors which do support Nvidia's proprietary driver are quite limited.

The compositors which only do support GBM, like e.g. Hikari, will tell you on Linux then if they detect Nvidia's proprietary driver that you need to switch over to Nouveau instead.

I have no idea what the equivalent driver for Nouveau on FreeBSD would be.
 
jbodenmann said:
nVidia quadro GPUs.
Click to expand...
I'm using a Thinkpad W520 running FreeBSD 12.2-RELEASE-p7 with a Nvidia Quadro 1000M GPU right now and have another running 12.1-RELEASE-p3 with the same GPU as my mp3 player.

I have those and a T61 with Nvidia Quadro NVS 140M in the screenshot thread.
 
hardworkingnewbie said:
I have no idea what the equivalent driver for Nouveau on FreeBSD would be.
Click to expand...
There isn't any equivalent on FreeBSD. We're lucky enough to be offered official drivers, so there's little motivation to write or port alternative drivers.

NetBSD is porting nouveau. They don't get drivers from nvidia so they do have a good incentive to do so, and it's probably the best thing they can do (writing their own reverse-engineered driver would be too much work for that rather small team). It's still ongoing work, not working well at the moment from what I could test, but this could once become a viable alternative to Linux on hardware that's too old to get official drivers.
 
Offcourse you can also just try out what works or not with your hardware.
Or buy a cheap accelerated intel/amd card known to work (and that is what I did, I switched my nvidia card for a cheap accelerated radeon card)
 
Thank you for the information you guys provided.

Do the nVidia drivers under FreeBSD only work under Linux mode (using linux.ko)? Or are the drivers provided by nVidia "native"? If using Linux mode, is there a considerable performance penalty?
 
Good question. Isn't drm-kmod used ? The DRM drivers ported from Linux to FreeBSD using LinuxKPI. And can we call this linux-mode ?
I'm not even certain linux.ko is not bypassed in both cases.
 
jbodenmann said:
Do the nVidia drivers under FreeBSD only work under Linux mode (using linux.ko)? Or are the drivers provided by nVidia "native"?
Click to expand...
They're native FreeBSD drivers. The biggest part of the driver (the closed source bit, the "blob") is actually exactly the same on Linux, FreeBSD, Windows and every other OS NVidia supports. There's just a bit of wrapper code around it to make it compatible for the kernel/OS. That's why the drivers for all the different supported OS'es have the same version and is the performance pretty much the same everywhere too.

If using Linux mode, is there a considerable performance penalty?
Click to expand...
There's very little overhead. Some report even a slight performance increase when compared to running it natively on Linux.

Just for the sake of clarity, the LINUX option on the x11/nvidia-driver is for making it possible to use the NVidia driver with the Linux compatibility layer. It's not required for the driver to function on FreeBSD natively. So, if you don't plan on using the Linux compatibility layer you can just switch the option off.

Alain De Vos said:
Good question. Isn't drm-kmod used ?
Click to expand...
Nope, not for the NVidia drivers.
 
Actually, there is one difference between the Linux and the FreeBSD drivers. CUDA is not supported in FreeBSD so if you really need OpenCL/CUDA support, you're out of luck. Apart from that, the NVidia driver is working (almost) flawless on FreeBSD.
 
Thanks again for all the valuable information presented in this topic!

I managed to successfully run i3 on FreeBSD 13.0 on two different machines with nVidia Quadro GPUs. Everything went extremely smoothly and from what I can tell so far there aren't any issues.

sciuro said:
Actually, there is one difference between the Linux and the FreeBSD drivers. CUDA is not supported in FreeBSD so if you really need OpenCL/CUDA support, you're out of luck. Apart from that, the NVidia driver is working (almost) flawless on FreeBSD.
Click to expand...
That's very good to know!
 
sciuro said:
Actually, there is one difference between the Linux and the FreeBSD drivers. CUDA is not supported in FreeBSD so if you really need OpenCL/CUDA support, you're out of luck. Apart from that, the NVidia driver is working (almost) flawless on FreeBSD.
Click to expand...
Well, opencl is possible with some patches, so not supported out of the box(and using emulators/libc6-shim)
Code: 
shim init
Mon Sep  6 21:30:53 2021       
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 470.63.01    Driver Version: 470.63.01    CUDA Version: 11.4     |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|                               |                      |               MIG M. |
|===============================+======================+======================|
|   0  NVIDIA GeForce ...  Off  | 00000000:01:00.0 Off |                  N/A |
| N/A   43C    P8    N/A /  N/A |      9MiB /  2004MiB |      0%      Default |
|                               |                      |                  N/A |
+-------------------------------+----------------------+----------------------+
                                                                               
+-----------------------------------------------------------------------------+
| Processes:                                                                  |
|  GPU   GI   CI        PID   Type   Process name                  GPU Memory |
|        ID   ID                                                   Usage      |
|=============================================================================|
|    0   N/A  N/A     60637      G   Unknown Error                       8MiB |
+-----------------------------------------------------------------------------+
See https://forums.developer.nvidia.com/t/cuda-and-nv-un-register-os-un-lock-user-pages/174678
for the actual patches.
Here an output of benchmarks/clpeak
Code: 
shim init

Platform: NVIDIA CUDA
  Device: NVIDIA GeForce GTX 960M
    Driver version  : 470.63.01 (FreeBSD)
    Compute units   : 5
    Clock frequency : 1176 MHz

    Global memory bandwidth (GBPS)
      float   : 68.72
      float2  : 70.68
      float4  : 72.16
      float8  : 70.53
      float16 : 52.77

    Single-precision compute (GFLOPS)
      float   : 994.16
      float2  : 1467.19
      float4  : 1496.11
      float8  : 1487.16
      float16 : 1482.27

    No half precision support! Skipped

    Double-precision compute (GFLOPS)
      double   : 48.06
      double2  : 48.01
      double4  : 47.91
      double8  : 47.73
      double16 : 47.36

    Integer compute (GIOPS)
      int   : 453.51
      int2  : 503.45
      int4  : 507.56
      int8  : 465.23
      int16 : 447.16

    Transfer bandwidth (GBPS)
      enqueueWriteBuffer         : 8.14
      enqueueReadBuffer          : 8.02
      enqueueMapBuffer(for read) : 11.08
        memcpy from mapped ptr   : 8.12
      enqueueUnmap(after write)  : 12.46
        memcpy to mapped ptr     : 8.35

    Kernel launch latency : 4.10 us
 
Hello.
A new nvidia driver version 470.74 for FreeBSD is available at nvidia.com.
When it will be available via standard "pkg" repository?
 
grahamperrin said:
If nvidia works, then is nvidia preferable to nvidia-modeset?

<https://www.freshports.org/x11/nvidia-driver/#message> appears to prioritise nvidia, e.g.

sysrc kld_list+=nvidia
Click to expand...
The message prioritizes reading comprehension: "Starting with version 358.09, some important functionality of the driver has been broken out into a separate kernel module, nvidia-modeset.ko.". That is because this a shared message for all nvidia-driver ports.
 
I think the news-like wording should change. It's old news, more than five years.

tl;dr the message implies nvidia-modeset only if things fail (as outlined in the message) with nvidia.

1638507640836.png


Last but not least, we're directed to /usr/local/share/doc/NVIDIA_GLX-1.0/README for more information. At a glance, the currently installed content <https://termbin.com/2n06> matches <https://http.download.nvidia.com/XFree86/FreeBSD-x86_64/470.86/README/README.txt> for 470.86 and:
  • no suggestion to use nvidia-modeset in case of hangs or the Validated MetaModes: … "NULL" message.
 
That module is always required. The port's message is overly carefully worded just in case. I wouldn't state it like that (I don't trust end users that much), but I'm not the maintainer.
 
You must log in or register to reply here.
Back
Top