Call For Testing: nvidia-drm kernel module

Unfortunately, it's not relevant here. nvidia-drm.ko itself is not built yet.
My assumption reading Release Highlights of 550.40.07 is that it builds nvidia-drm.ko by itself, by default to be available. But it turned out that it's not currently true at least building via x11/nvidia-driver port.

Possibly overlooked, but as I couldn't find any prerequisites or special method to build nvidia-drm.ko, I thought nvidia added all actually required codes in driver package, regardless incorporating codes by 3rd parties (licensed) or developed by themselves, and it is built without additional external dependencies as-is.
 
Ah, sorry, I overlooked the beta context despite your mention:

550.40.07 … BETA …

(/boot/modules/nvidia-drm.ko is listed at <https://www.freshports.org/graphics/nvidia-drm-510-kmod/#pkg-plist> and <https://www.freshports.org/graphics/nvidia-drm-515-kmod/#pkg-plist>.)




NVIDIA graphics libraries and programs (Linux version)

Not documented:

Code:
% rg linux-nvidia-libs /usr/doc/documentation/content/en
%

What is the purpose of this port? I have one of its slaves installed, but I don't know why, I probably took a lucky dip approach in relation to some bugs.

<https://www.freshports.org/x11/linux-nvidia-libs#requiredby> it's not required by any other port. Is it recommended, or required, for things that use the Linuxulator?
 
Yes, I know. What I wondered is that it is now incorporated into official (beta) driver package or not. I'm puzzled with this.
Currently, ashafer is creating his upstream distfile and update the port when x11/nvidia-driver and x11/linux-nvidia-libs are updated.
Anyway, even if it becomes buildable, it's on maintainers (danfe@, x11@ and ashafer) how these should be handled. I'd be able to help, but have no authority for it.

What is the purpose of this port? I have one of its slaves installed, but I don't know why, I probably took a lucky dip approach in relation to some bugs.
It's for Linux apps working on top of linuxulator.
Even if nothing in ports tree needs it, anyone manually installing Linux apps (without using ports) needs nvidia proprietary libraries provided by this port should need it.
And as its contents comes from nvidia driver package for Linux and should better in sync with driver for FreeBSD (a bunch of libraries provided are unavailable for FreeBSD native ones, especially CUDA-related ones).
 
Yes the nvidia-drm patches are now incorporated into the official driver. No they are not built by default, you'll have to cd into src/nvidia-drm and make + make install there. It's not built by default because it requires having a copy of drm-kmod to reference during the build, and this way we don't have to suddenly update every testing system to be set up for DRM usage/builds and break existing flows.

For the average user this won't matter as I'll update the nvidia-drm-*-kmod ports to build nvidia-drm from the release tarball and get rid of my github patch distribution thing (finally!). Nobody should really be building the driver outside of ports anyway. I've been waiting for the 550 driver to get picked up by the nvidia-driver port, I see you created bug 277028 so I guess I should go ahead and start doing this.
 
Yes the nvidia-drm patches are now incorporated into the official driver. No they are not built by default, you'll have to cd into src/nvidia-drm and make + make install there. It's not built by default because it requires having a copy of drm-kmod to reference during the build, and this way we don't have to suddenly update every testing system to be set up for DRM usage/builds and break existing flows.

For the average user this won't matter as I'll update the nvidia-drm-*-kmod ports to build nvidia-drm from the release tarball and get rid of my github patch distribution thing (finally!). Nobody should really be building the driver outside of ports anyway. I've been waiting for the 550 driver to get picked up by the nvidia-driver port, I see you created bug 277028 so I guess I should go ahead and start doing this.
Thanks for the clarification! So same distfile is used for both x11/nvidia-driver and graphics/nvidia-drm-*-kmod once 550 or later becomes production, but kept separately not to confuse existing users who don't need drm features.

Yes, I've filed PR 277028 basically for allowing x11/linux-nvidia-libs to be built overriding DISTVERSION to 550.40.07.
For not to be rejected, updates for latest production branch driver is incorporated (usually, patches only for beta and/or new feature branch is not accepted).
 
Will this patch make it into packages? At present, with nvidia-drm-515-kmod-535.146.02 (from packages) I am unable to get Wayland working on my machine with an NVidia card.
Even though for me, Wayland is more a curiosity than anything else, thank all of you for your work on this.
 
Will this patch make it into packages? At present, with nvidia-drm-515-kmod-535.146.02 (from packages) I am unable to get Wayland working on my machine with an NVidia card.
Even though for me, Wayland is more a curiosity than anything else, thank all of you for your work on this.
Maybe unlikely.
Almost just after I posted my previous comment, nvidia released driver 550.54.14 as production Latest Production Branch Version.
I'll update again (dropping nvidia-drm-*-kmod part) with subject line after some casual testing, if no new fatal-to-me breakage is found.

For graphics/nvidia-drm-*-kmod, ashafer would be investigating how to implemet for this new framework from 550.* now as he posted at #55 here.
There seems to be no plan to migrate graphics/nvidia-drm-*-kmod ports into x11/nvidia-driver port, not to bother who don't need drm support.
 
Uploaded patch to updating to new production branch driver 550.54.14 at PR 277028. Edited its Summary: field to reflect the switch of production branch.
Note that patches for graphics/nvidia-drm-*-kmod are not included for now, as it requires ashafer's work to finish.
For this reason, previous patch for 535.154.05 #2 is kept. Please be patient until ashafer's work is to be finished.
 
NVIDIA's pages for new feature branch 555.58.02 and beta 560.28.03 state:

… designs with switchable (hybrid) or Optimus graphics will not work if means to disable the integrated graphics in hardware are not available. …

If I understand correctly, that statement is outdated.

1722770545894.pngPictured: 2019 documentation for 435.17 on Linux-x86 included a chapter for PRIME render offload.

Can documentation for 560.28.03 on FreeBSD gain a relevant chapter, or is it too late in the beta?

TIA
 
Chapter 4 in README for 560.28.03 beta driver is outdated, too.

Although Release Highlights states that "GSP firmware is now supported on FreeBSD. See the chapter "GSP Firmware" in the README for more details.", no firmware modules are listed in it. But I'm not a nvidia insider, so I can do nothing with it.

Trying build, there were 2 new *.ko files (nvidia_gsp_ga10x_fw.ko and nvidia_gsp_tu10x_fw.ko) in x11/nvidia-driver/work/stage/boot/modules/ working directory. But they aren't installed. Makefile and pkg-plist needs updates for it.

Actually, I already have patch for it (as an update to 550.107.02 production driver, because patches for new feature branches and beta branches should never been accepted by the maintainer). I need to check if there's some more new files needed or not, but I cannot promise when I can do it and file a PR.

If anyone want to try it reagardless the current state, I've posted it to freebsd-stable ML for a person bitten by UEFI firmware updates, with a quite little hope that Lenovo somehow broke video FW in it and any changes to the driver could fix it.

Note that if you want to try 555 (new feature) or 560 (beta) series of drivers with graphics/nvidia-drm-*-kmod ports, you need editing x11/nvidia-driver/Makefile.version to override driver version. If you need only x11/nvidia-driver and x11/linux-nvidia-libs only, the usual method should work fine.
 
Other outdated chapters (I know, documentation is a chore) include:
  • Known Issues (the GNOME bug that's mentioned was fixed more than eleven years ago …)
  • Configuring a Notebook (hot docking works for me with 470.161.03, I assume that it also works with 560.28.03; and the point about hibernation having bad interactions in some cases seems nonsensical, because when I last checked, FreeBSD did not support hibernation in any case …).
 
Back
Top