Found that nvidia released new Production Branch of driver, 570.124.04. Upgrade corresponding ports for it. x11/nvidia-driver x11/linux-nvidia-libs graphics/nvidia-drm-[510|515|61|66]-kmod and unlike usual upgrades, to address the issue that X11 cannot acquire modesetting permission, graphics/nvidia-drm-kmod (Makefile.common) needs fix.
Created attachment 258264 [details] Patch for everything without x11/linux-nvidia-libs Patch to upgrade x11/nvidia-driver graphics/nvidia-drm-kmod graphics/nvidia-drm-[510|515|61|66]-kmod to latest Production Branch of driver 570.124.04. See https://www.nvidia.com/en-us/drivers/details/241090/ for details. Patch for x11/linux-nvidia-libs is provided individually for this upgrade with some reason.
Created attachment 258265 [details] Bare-minimal patch for x11/linux-nvidia-libs Patch for x11/linux-nvidia-libs to latest Production Branch of the drivers, 570.124.04. This includes updated distinfo and chasing libraries bumps for already existing in pkg-plist that have individual versions other than NVIDIA_DISTVERSION. Note that, in this release, nvidia added some new libraries and corelated jsons. But this patch doesn't handle them at all, including 32bit compatibility support for the NVIDIA GBM backend. See https://www.nvidia.com/en-us/drivers/details/241089/ for details.
Additional notes for x11/linux-nvidia-libs: Looking into already-linked Release Highlights, README for Linux version https://us.download.nvidia.com/XFree86/Linux-x86_64/570.124.04/README/index.html and private discussion (via email) with Austin started from 570 series was still Beta, newly added file seemed to be categorized as below. 1. 32 bit compatibility support for the NVIDIA GBM backend. 2. EGL backends for Xlib and XCB with their 32bit versions. 3. Supports for VulkanSC. 4. Supports for container runtime environments. I'm still working on the category 1 thrugh 3, but needs for 3 seems to be doubtful on FreeBSD, so it would be stopped investigating unless there are some quite strong (almost forcing) requests. For category 4, would not be worked on as of differences in containerization mechanisms within FreeBSD and Linux.
Both of these changes seem good to me so far. I made a release tag for 1.1.18 so the egl-wayland port should probably be updated to that as well.
Created attachment 258289 [details] Patch to upgrade graphics/egl-wayland to 1.1.18 graphics/egl-wayland: update to 1.1.18 Changes: https://github.com/NVIDIA/egl-wayland/releases/tag/1.1.18 https://github.com/NVIDIA/egl-wayland/releases/tag/1.1.17 https://github.com/NVIDIA/egl-wayland/releases/tag/1.1.16 https://github.com/NVIDIA/egl-wayland/releases/tag/1.1.15 https://github.com/NVIDIA/egl-wayland/releases/tag/1.1.14 Reported by: Library version of the Linux version of driver package
(In reply to Austin Shafer from comment #4) OK. Thanks! Uploaded patch to upgrade graphics/egl-wayland to 1.1.18 to sync with Linux version in x11/linux-nvidia-libs. As the consumers in-tree are nvidia[-secondary]-driver[-470] according to FreshPorts, https://www.freshports.org/graphics/egl-wayland/ and there's no maintainer, avoided filing another PR for it. The patch is quite trivial. Tested that the upgrade doesn't harm on starting X11 and running some Wayland-dependent apps (Alacritty, Kitty) on stable/14, amd64 at commit 76fdef764db9b21f913e56eea571172fe1608c4b.
(In reply to Tomoaki AOKI from comment #3) Reply to post by myself. I'll stop investigating category 3 and will focus on 1 and 2. The reason: Looking for informations about VulkanSC available on Internet, *SC stands for "Safety Critical", *For SC drivers, users would strongly want assurances that FreeBSD project and/or FreeBSD Foundation cannot provide, thus, I considered it would not fit for "emulated" Linuxulator environment. If native FreeBSD versions of libraries and tools are officially provided by nvidia, supporting them in x11/nvida-driver would be quite nice (if any use-cases exists on FreeBSD).
I think for VulkanSC we could just continue to place the library in /compat/linux but not worry about testing it. It would be available if for some reason someone needed it. Afaik it should theoretically work, it's a vulkan library simplified to some degree. I don't think emulation is a problem for it, I think it's more that there would be no reason for regular users to use it. It's used for autonomous vehicles and medical equipment and the like.
(In reply to Austin Shafer from comment #8) FreeBSD is used on embedded appliances, too. Not sure autonomous vehicles and/or medical appliances are included or not, though. For those use cases, IIUC, possibly VulkanSC is wanted unlike other use-cases. But OTOH, for those use-cases, footprint of OS (not only kernel but also base system) running usually matters. This is another reason I considered VulkanSC supports in x11/linux-nvidia-libs are not strongly needed (Linuxulator surely increases memory and disk footprints compared with native drivers/libraries/apps). Anyway, if anyone want it and possible to test popps in, I'll work on it after completing category 1 and 2. And what I can test for x11/linux-nvidia-libs is checking whether it builds and installs fine, as I currently don't have anything requiring the functionalities of x11/linux-nvidia-libs. Just trying to keep it in sync with x11/nvidia-driver (which would be mandatory like with nvidia-drm-*-kmod ports, my guess).
Created attachment 258306 [details] Patch for x11/linux-nvidia-libs Patch for x11/linux-nvidia-libs to latest Production Branch of the drivers, 570.124.04. This includes *updated distinfo, *chase library bumps that have individual versions other than NVIDIA_DISTVERSION, *add 32bit compatibility support for nvidia GBM backend, *add newly introduced libraries and corelated *.json files excluding VulkanSC support and sandboxing support. See https://www.nvidia.com/en-us/drivers/details/241089/ for details.
Opened differential revision D49245 on Phablicator for this. https://reviews.freebsd.org/D49245
Created attachment 258454 [details] Patch for everything without x11/linux-nvidia-libs (v2) Updated patch just to be sync with the one on Phablicator. This is a comment-only update in graphics/nvidia-drm-kmod/Makefile.common. Everythin others are unchanged.
For the most part, I have not run into issues with this version of the driver. The patches worked for me. My environment is 14.2-STABLE and X11. The only issue I have seen is when playing a game (Rocket League) via Wine. It either locks at the initialization of the game, shortly after starting training or playing a match. Killing the game and restarting does the same thing. However, removing ~/.cache/nvidia prior to starting the game lets it play without issues from that point until the game is restarted. This occurs whether or not I am running the picom compositor or not. There are many variables around this (Nvidia environment variables + Wine + DXVK), so I am hesitant to say that will affect anyone else. Other games (Xonotic, Red Eclipse, Luanti) and applications (xscreensaver OpenGL saver, Firefox and MPV) are not locking up.
(In reply to Sean Farley from comment #13) IIUC, ~/.cache/nvidia is for shader cache. If it matters, disabling (somehow) it could help. But sorry, I've never configured it. If the game has configuration about it, disable it or increase/decrease the amount could help. Reading README to confirm something you configured are still available or not could be a good idea. https://us.download.nvidia.com/XFree86/FreeBSD-x86_64/570.124.04/README/index.html And can you provide more info (using graphics/nvidia-drm-[510|515|61]-kmod or not, using x11/linux-nvidia-libs or not, what configuration for nvidia driver [xorg configuration files, sysctl], etc.)? It could help addressing the issue by someone other than me (hopefully nvidia insiders).
On commit f2cc91f4b56eaa5da41a712b3c42be874161c1c9 through f7f46d1b58279326de0760ce1fee71631af40cae and following commit e3d1e7c048d0c909e3f67bc4e2dba558f4c17781, graphics/drm-[515|61|66]-kmod are bumped in preparation for flipping debug.link_elf_leak_locals from 1 (allow local symbols to participate in global module symbol resolution) to 0 (disallow). So this PR need to follow the updated distfiles. But as graphics/drm-510-kmod is not bumped yet (not sure somehow delayed or not needed), I'll wait a while for it. And need testing whether the flip affects nvidia-driver and nvidia-drm-*-kmod or not. If affected, need determining whether it can be done on ports or not. If not, we should need waiting nvidia to reroll official tarball (or upcoming version). Anyway, patches here and D49245 should no longer applicable on ports tree at commit f2cc91f4b56eaa5da41a712b3c42be874161c1c9 and later.
(In reply to Tomoaki AOKI from comment #15) Updated ports tree to commit f828c72a96e34c8bd65214f6331ab6445f568bdb and applied (not yet uploded) updated patch, rebuild/reinstall and restarted with tunable debug.link_elf_leak_locals=0 (flipped) in /boot/loader.conf went without issue. *On stable/14, amd64 at commit e7d1f208fde82c85b061ce792f20a4aa178ec82f, only graphics/drm-61-kmod with x11/nvidia-driver is tested. This should (hopefully) mean graphics/nvidia-drm-*-kmod and x11/nvidia-driver are OK as-is after debug.link_elf_leak_locals is flipped from 1 to 0. Meanwhile, x11/nvidia-driver/Makefile got commit aa1da009b4081b25bb162b0c4177e872ca0b81a3 by bapt@. This does not affect my patchset. Built and installed fine. But as I have no 32bit apps installed for now, tests are wanted by someone possible. I'll upload updated patches Saturday (or Sunday) JST to see graphics/[nvidia-]drm-510-kmod gets update by manu@ or not.
Created attachment 258708 [details] Patch for everything without x11/linux-nvidia-libs (v3) In preparation for review D47742 "kernel linker: Disable local sym resolution by default" to be landed, commits f2cc91f4b56eaa5da41a712b3c42be874161c1c9 (for graphics/[nvidia-]drm-515-kmod) 8b4b66d94b8ff86c1c764094c38273313dd5f2d3 (for graphics/[nvidia-]drm-61-kmod) f7f46d1b58279326de0760ce1fee71631af40cae (for graphics/drm-66-kmod) and e3d1e7c048d0c909e3f67bc4e2dba558f4c17781 (for graphics/nvidia-drm-66-kmod) are landed. To chase these, updated patch for graphics/nvidia-drm-[515|61|66]-kmod. This patch is updated for distinfo parts only. Note that commit aa1da009b4081b25bb162b0c4177e872ca0b81a3 does not affect, as no updates are needed for x11/nvidia-driver/Makefile. Tested with "debug.link_elf_leak_locals=0" in /boot/loader.conf on: stable/14, amd64 at commit 7215aed7974cc4b7d3197ca5e5fcf545d3a28c0f main, amd64 at commit 780a4667bbde0daa90db900bb0f93f6337d6208b using graphics/nvidia-drm-61-kmod with ports tree at commit 1a6d0749a55c1e35a42e943429ec043e6a1c625c and X11 started fine. No tests on other variants and Wayland.
(In reply to Tomoaki AOKI from comment #17) Additional note: graphics/drm-510-kmod and graphics/nvidia-drm-510-kmod aren't updated for review D47742. I considered this should indicate that review D47742 are not planned for MFC (main [aka Current] only) not to violate POLA, so I've uploaded the current state of the patch. (graphics/drm-510-kmod has "IGNORE_FreeBSD_15= not supported anymore" in its Makefile, so this should be unrelated with review D47742 unless MFCs are planned.)
Committed as ports 0de17c4dce28156a28cb89db200db0b804ebff65 by ashafer@ (approved by kbowling@). As not auto-closed (because mentioned only corresponding review D49245), close as FIXED. Thanks, Austin and Kevin, and everyone looking into this!
Found new Production Branch of the driver 570.133.07 is released just the next day from commit. https://www.nvidia.com/en-us/drivers/details/242274/ Trying on stable/14, amd64 at b429d50df97bc6f85373d4bd4ffca7e7078b3fe8 for x11/nvidia-driver x11/linux-nvidia-libs and graphics/nvidia-drm-61-kmod went fine with overriding version by backing up and editing x11/nvidia-driver/Makefile.version, with specifying NO_CHECKSUM=YES on build as usual. So currently having no plan to submit new patch for upgrading for now. (And no new New Feature branch and/or Beta branch of drivers now.) Another reason this time is that as per a request from a person to address Bug285069 and already uploaded patch there (waiting for the test result from him, as I'm no longer using 470 series of drivers, thus, tested build and package only).