This updates the NVIDIA ports to the latest stable production branch.
Also bump graphics/egl-wayland to the latest 1.1.19 to match with
the one in x11/linux-nvidia-libs.
PR: 286307
Details
Details
- Reviewers
kbowling ashafer - Group Reviewers
x11 - Commits
- R11:9b6b1bf17269: x11/nvidia-driver, x11/linux-nvidia-libs, graphics/nvidia-drm-kmod: Update to…
Diff Detail
Diff Detail
- Repository
- R11 FreeBSD ports repository
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
| graphics/nvidia-drm-515-kmod/Makefile | ||
|---|---|---|
| 2 | Just removing the whole line is fine, no need to explicitly set to 0. | |
| x11/linux-nvidia-libs/Makefile | ||
|---|---|---|
| 144 | With our new upstream process for releasing egl-wayland I think we will continue to have very frequent version bumps. It would probably be worthwhile looking into simplifying this to reduce duplication. Something like declaring NV_EGL_WAYLAND_VERSION based on NVVERSION, and then having only one stanza such as: LINUX_LIBS+= libnvidia-egl-wayland.so.1.1.${NV_EGL_VERSION}
LINUX_LINKS+= libnvidia-egl-wayland.so.1.1.${NV_EGL_VERSION} libnvidia-egl-wayland.so.1
LINUX32_LIBS+= libnvidia-egl-wayland.so.1.1.${NV_EGL_VERSION}
... | |
| graphics/nvidia-drm-515-kmod/Makefile | ||
|---|---|---|
| 2 | For example, x11/nvidia-driver-470, which is a slave port of x11/nvidia-driver, has comment in its Makefile as below.
This port (including other graphics/nvidia-drm-[510|515|61|66]-kmod) includes graphics/nvidia-drm-kmod/Makefile.common, which has its own PORTREVISION. So I think the same should be applicable here, too. But thanks for noting this. I've found that PORTREVISION of graphics/nvidia-drm-kmod/Makefile.common is not being reset, and defined with "=", not "?=". So I'll fix it on next update incorporatiing ashafer's idea for x11/linux-nvidia-libs. | |
Comment Actions
Fixed PORTREVISION in graphics/nvidia-drm-kmod/Makefile.common.
Simplified x11/linux-nvidia-libs/Makefile a bit for frequently-upgraded parts (graphics/egl-wayland related and Linux-only egl-x[cb|lib] stuff).
Others seems to be upgraded per-major-version or fewer.
| x11/linux-nvidia-libs/Makefile | ||
|---|---|---|
| 144 | Done, with egl-x[cb|lib] staff, which seem to be upgraded at the same time as egl-wayland. | |
| x11/linux-nvidia-libs/Makefile | ||
|---|---|---|
| 148 | What does this comment mean? I'm not sure this is necessary. | |
Comment Actions
A couple minor nits but overall looks good
| x11/linux-nvidia-libs/Makefile | ||
|---|---|---|
| 144 | We can purge all the interm steps, i.e. there is no reason to carry 495.0205 to 570.12400 in the ports tree, and likewise with the legacy drivers. Only shipping or future (nfb/beta) drivers should be spelled out. If someone is offroading with some older version they can figure it out easily enough with an older tree. | |
| 271 | Same here I think, this should not be necessary or committed to handle a previous version. But the pattern here might be useful for i.e. 570 production vs 575 nfb as we get there. | |
| x11/linux-nvidia-libs/Makefile | ||
|---|---|---|
| 144 | Why keeping intermediate steps is to avoid hard-to-track problems depending on specific versions. And recently, not related with nvidia, there are some reports that graphics/drm-61-kmod has some problems but graphics/drm-515-kmod works, on iGPUs supported by both. I just want to avoid such a kind of things by not dropping intermediate versions. Dropping older than 304 branch (oldest existing in-tree) is OK, but they are already non-existent in this Makefile. | |
| 148 | Just a note why this ".else" exists. As I'm not currently setting default NV_EGL_[W|X]_VERSION, clearint it is basically a mess. But just for the preparation of the cases setting any default (intentionally or missingly) in the future when all of us resigned maintaining this. And "Fool proof (Poka-yoke)" is strongly suggested in automotive industry I'm $working on (maybe far more stricker in aerospace industry). | |
Comment Actions
Can we have an updated version string in the dmesg? On current with nvidia-drm-66-kmod, I get:
Initialized nvidia-drm 0.0.0 20160202 for nvidia0 on minor 1
| x11/linux-nvidia-libs/Makefile | ||
|---|---|---|
| 144 | I do understand the concern but this is not the norm in ports (and as compared to something like Gentoo). If you are chasing some hw issue and you know how to build a port, it's reasonable to be able to edit or revert the tree to get where you want to go. But we don't build up a legacy for that because the support matrix and noise increases. To be clear I am not advocating for the removal of any of the legacy driver branches (470, 390, 340, 304).. these should remain indefinitely unless they cannot be reasonably built in the future or there is some broader support removal (i.e. 304 will eventually have to go away when the last i386 stable branch is retired). Only intermediate version code that is not used by any live port. | |
Comment Actions
Cannot find related codes in nvidia side of src in quick glance, but found in drm-*-kmod part.
(I'm working on stable/14, so cannot test graphics/*drm-66-kmod. But string in dmesg looks same.
Austin, do you have any insight?
/usr/ports/graphics/nvidia-drm-61-kmod/work/drm-kmod-drm_v6.1.128_1/drivers/gpu/drm/drm_drv.c- ret = drm_modeset_register_all(dev);
/usr/ports/graphics/nvidia-drm-61-kmod/work/drm-kmod-drm_v6.1.128_1/drivers/gpu/drm/drm_drv.c- if (ret)
/usr/ports/graphics/nvidia-drm-61-kmod/work/drm-kmod-drm_v6.1.128_1/drivers/gpu/drm/drm_drv.c- goto err_unload;
/usr/ports/graphics/nvidia-drm-61-kmod/work/drm-kmod-drm_v6.1.128_1/drivers/gpu/drm/drm_drv.c- }
/usr/ports/graphics/nvidia-drm-61-kmod/work/drm-kmod-drm_v6.1.128_1/drivers/gpu/drm/drm_drv.c-
/usr/ports/graphics/nvidia-drm-61-kmod/work/drm-kmod-drm_v6.1.128_1/drivers/gpu/drm/drm_drv.c: DRM_INFO("Initialized %s %d.%d.%d %s for %s on minor %d\n",
/usr/ports/graphics/nvidia-drm-61-kmod/work/drm-kmod-drm_v6.1.128_1/drivers/gpu/drm/drm_drv.c- driver->name, driver->major, driver->minor,
/usr/ports/graphics/nvidia-drm-61-kmod/work/drm-kmod-drm_v6.1.128_1/drivers/gpu/drm/drm_drv.c- driver->patchlevel, driver->date,
/usr/ports/graphics/nvidia-drm-61-kmod/work/drm-kmod-drm_v6.1.128_1/drivers/gpu/drm/drm_drv.c- dev->dev ? dev_name(dev->dev) : "virtual device",
/usr/ports/graphics/nvidia-drm-61-kmod/work/drm-kmod-drm_v6.1.128_1/drivers/gpu/drm/drm_drv.c- dev->primary->index);
/usr/ports/graphics/nvidia-drm-61-kmod/work/drm-kmod-drm_v6.1.128_1/drivers/gpu/drm/drm_drv.c-
Comment Actions
It is defined in the NVIDIA driver, i.e., src/nvidia-drm/nvidia-drm-drv.c. Just search 20160202.
Comment Actions
The file is extracted in WRKDIR as in x11/nvidia-driver.
And driver version string (570.144 here) is specified in graphics/nvidia-drm-61-kmod/work/NVIDIA-FreeBSD-x86_64-570.144/src/nvidia-drm/Makefile as CFLAGS += -DNV_VERSION_STRING=\"570.144\", thus, incorporated in nvidia-drm.kmod. But not exposed to graphics/drm-*-kmod part.
| x11/linux-nvidia-libs/Makefile | ||
|---|---|---|
| 144 | Basically agreed. So my proposal is that: *This time, commit without pruning. *Post headsup at least to freebsd-ports ML and Forums for anyone objects for pruning to give time to pop in, and if necessary, keep support for the specific version(s) having valid reasons. *After the deadline noted in the headsup arrives, prune now-unneeded intermediate versions. This could be multiple steps (simplified ones first, and remaining complexed ones later). | |
Comment Actions
Rebase to chase graphics/drm-[61|66]-kmod upgrades.
This update is the rebase only, putting anything others in discussion aside.
Comment Actions
On headsup for pruning intermediate versions, we should clarify:
*Keeping conditionals only the top of master port and each slave (legacy, currently) ports and initial version of each conditionals as a record, or *Keeping latest ones for each of major versions (starting from 304, but do not add existing upstream but not in ports Makefile).
Kevin, do you imagine the former?
And also need to decide how long we should give to pop in for anyone having reasons that needs specific version.
Comment Actions
Looking into x11/nvidia-driver/Makefile and x11/linux-nvidia-libs/Makefile thoroughly, there seems to be no more candidates for conditionals to be pruned, if I'm not overlooking something.
The closest candidate would be pop up when 13.x branch is totally EoL'ed. But only single conditional.
Closed conditionals seems to contain any of main or latest legacy branch within their version ranges.
Comment Actions
Pending rebase after D50048 landed as commit 13636d8b58f662e12d1513333d1e981a59620109 for now, as D50053 should land first. Would rebase after it lands.
Comment Actions
Turned out that use-cases requiring intermediate versions exists.
https://forums.freebsd.org/threads/how-to-install-the-nvidia-drm-kmod-for-the-driver-nvidia-525-78-01-on-freebsd-14-2-to-be-able-to-run-comfyui.97741/ https://www.reddit.com/r/freebsd/comments/10ysy6m/how_to_install_on_freebsd_131release_a_different/
The latter is linked from the former (the same Op). Not exactly same, but what he did before.
The Op want to use 525.78.01 for compatibility with a specific Linux application (here, ComfyUI) and it requires Linux version of libnvidia-egl-wayland.so.1.1.10.
Not sure why I've missed (would have been forgot to test building x11/linux-nvidia-libs at the moment, but x11/nvidia-driver only), support for 1.1.10 was not there, so I've provided hot fix for him.
This would indicate that pruning intermediate versions could be problematic in some specific cases.
Some Linux apps in binary-only seems to be linked against specific version of nvidia libraries.
(This was what I suspected but not sure it really exists or not.)
If we decide not pruning (at least for now), I'll include the hot fix (modified to fit current form) on next rebase.
Note that the Op himself was confused so me too confused to clarify what actually he needs and why.
He seems to mis-understanding Linuxulator as native FreeBSD environment, although it's emulated kernel features for Linux userland supports.
Comment Actions
The Op want to use 525.78.01 for compatibility with a specific Linux application (here, ComfyUI) and it requires Linux version of libnvidia-egl-wayland.so.1.1.10
Applications should never be doing this, this is incorrect behavior and we should not worry about intermediate version support to help fix broken apps. If the user needs to make a symlink or set up an old driver to work around a buggy application they are welcome to do so, egl-wayland is independent of the driver and an old one can be installed on top of any driver version. Because egl-wayland can be installed separately I think that's a good case for why keeping intermediate versions around is not worth it. Op also clearly has some setup issues from using the raw tarball so I would take the feedback with a grain of salt when deciding what is best for all users.
| x11/linux-nvidia-libs/Makefile | ||
|---|---|---|
| 144 | I would just go ahead and prune now. The list should look like this: .if ${NVVERSION} >= 570.14400 # 570.144 | |
Comment Actions
Because egl-wayland can be installed separately I think that's a good case for why keeping intermediate versions around is not worth it.
For x11/nvidia-driver, yes.
But for x11/linux-nvidia-libs, we don't build anything but distributing files into proper places of stage and fix temporary plist. So the situation is different from native x11/nvidia-driver. libnvidia-egl-wayland.so.* are simply extracted from upstream *.run for x11/linux-nvidia-libs.
If libraries provided from nvidia are backward-compatible unless any GPUs are dropped, telling users of abused binaries to symlink or libmap would be sufficient.
Comment Actions
Rebase after commit 637e9e68f1a2ce587e5107b0fd296abd16f061a0 "x11/nvidia-driver: Fix too aggressive disabling of GSP firmware".
While here, pruned intermediate versions of libnvidia-egl-wayland.
Also refactored libnvidia-egl-gbm with the same way.
Comment Actions
Thanks, I think this seems reasonable now.
But for x11/linux-nvidia-libs, we don't build anything but distributing files into proper places of stage and fix temporary plist
Either way, we should not design the package around incorrect app behavior. It should be on the developer to properly link the app.
Comment Actions
Some notes for the future:
If new legacy branch is created upstream from pre-570.144, we would need to add back conditionals for it.
And once we add -devel for New Feature Branch of drivers (to support cutting edge GPUs), we would or wouldn't need to add conditionals (depending on whether the additions/upgrades are trivial or not).
And if any GPU are dropped from within a major version (basically unlikely, though) but no legacy branch is created for it upstream, we would need to prepare FreeBSD-specific legacy branch (latest production driver for the dropped GPUs).
But it would'nt be updated unless new versions supporting dropped GPUs are supported. (Major version could change.)
Anyway, it would be much trivial than before, thanks to ashafer's idea.
| x11/linux-nvidia-libs/Makefile | ||
|---|---|---|
| 144 | Pruned old versions (entry of the initial version the library appeared is intentionally kept to record the fact not to be forgotton, with comments). While here, refactored for libnvidia-egl-gbm, too. | |