From Newsgroup: muc.lists.freebsd.ports

On Sat, 28 Dec 2024 11:52:23 +0900
Tomoaki AOKI <junchoon@dec.sakura.ne.jp> wrote:

On Thu, 26 Dec 2024 14:23:52 +0100
Baptiste Daroussin <bapt@freebsd.org> wrote:

On Thu 26 Dec 13:26, Andriy Gapon wrote:

On 13/12/2024 16:28, Baptiste Daroussin wrote:

On Fri 13 Dec 07:24, Alan Somers wrote:

Success! With drm-61-kmod-6.1.92.1402000_3 I can kldload 915kms on FreeBSD 14.2. Before switching to this repo, kldload would hang.

Also, in addition to kmods, there are a few other ports that must be rebuilt for every minor version. devel/py-libzfs is one. Could that be added to the new repository?

Right now and until we have a thin repository support in poudriere: no :(.

One of the limitation is everything is cross build from amd64 so I cannot get
much things in that repo considering that in 2024 perl is still not cross build
friendly and last I checked python wasn't either.

I guess that's also the reason why nvidia driver packages are not built for
the kmod repo?
Because they bundle kernel and userland code in the same port?

Yes !
It seems they can be easily split, but I don't have the time to split them now.
And I don't have any nvidia device to test

Bapt

Hi.

Bug 288314 is filed that stating, for 14.3, there are no pkg of graphics/nvidia-drm-kmod in FreeBSD-kmods repo.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=288314

Is it a temporary delay?

Or does it (as it is metaport to choose actual nvidia-drm-*-kmod, it
would be one of graphics/nvidia-drm-*-kmod, though) because of kmod
parts of x11/nvidia-driver* are NOT splitted from them and graphics/nvidia-drm-*-kmod ports are depending on
x11/nvidia-driver[-devel]?

If so, I'll try to
*split kmod parts from x11/nvidia-driver[-304|-340|-390|-470|-devel]
and create corresponding x11/nvidia-kmod[-304|-340|-390|-470|-devel],

*let x11/nvidia-driver[-304|-340|-390|-470|-devel] to depend on
corresponding kmod port,

and

*switch dependency of graphics/nvidia-drm-*-kmod[-devel] from
x11/nvidia-driver[-devel] to corresponding x11/nvidia-kmod[-devel].

Note that, other than graphics/nvidia-drm-*-kmod[-devel], science/linux-ai-ml-env alone depends on x11/nvidia-driver,
but it isn't kmod port and would want library parts, thus,
no plan to modify it (if something is needed to do, it would be
to allow choosing proper version that support wanted GPU).

TBH, I've already started investigating if it is actually possible
or not, but not finished.

Any insights and/or thoughts?


Another thing to mention.
All legacy versions of nvidia driver supporting i386 (called x86
upstream) are already deprecated upstream.

https://nvidia.custhelp.com/app/answers/detail/a_id/3142

and dissappeared from top page for Unix drivers.

https://www.nvidia.com/en-us/drivers/unix/

Actually, any older versions for amd64 (x86_64) can be
tracked from Archive link.

https://download.nvidia.com/XFree86/FreeBSD-x86_64/

Fortunately, there is still

https://download.nvidia.com/XFree86/FreeBSD-x86/

for i386 (just cannot tracked via links) and fetchable.
But once nvidia decided to delete them, we have no way
to fetch i386 versions and we cannot know when it is.

I'm planning to send heads-up for the deprecation,
but still a bit wondering whether we should explicitly
DEPRECATE legacy versions other than still supported -470
or send heads-up alone and remove affected ports once
it becomes unfetchable.

Anyway, I wouldn't set EXPIRATION_DATE even if DEPRECATE'ing
affected ports, as when to be unfetchable is unknown.

Regards.

x11/nvidia-driver port is quite complicated with conditionals and
reinplaces to support legacy (and unofficially new feature and beta)
drivers. (x11/nvidia-driver is the master port of x11/nvidia-driver-*
having all required supports/workarounds per-version differences).

And it strongly depends on bundled pre-compiled (proprietary) large
blobs, so possibly even splitting it into kmod parts and libraries part
would not help cross compiling.

And more, graphics/nvidia-drm-[510|515|61]-kmod depends on it and corresponding graphics/drm-[510|515|61]-kmod ports, could make it more complicated.

But one possibly good news would be that native i386 is terminated on
newer than 390 branch of drivers, and chasing Xorg ABI changes like at
1.20 for legacy drivers are not 100% promised.

https://forums.developer.nvidia.com/t/x-wont-start-on-xorg-server-1-20-and-nvidia-legacy-390-new-abi/61219

https://forums.developer.nvidia.com/t/unix-graphics-feature-deprecation-schedule/60588

So once the Xorg ABI changes again, nvidia decides to chase it only
on production, new feature and beta branches at the moment and xorg
related ports on FreeBSD switches to newer version, we can (forcibly)
drop supports for legacy drivers supporting i386.

*Running 32bit i386 apps on compat supports of amd64 OS is still
supported at least currently.

And, Ugh, should we consider using --kernel-module-type=proprietary
option for x11/linux-nvidia-libs depending on its version (560 and
later only)?
My current assumption is that what affected by this are kernel modules
only and other components x11/linux-nvidia-libs installs are not
affected. But I'm not a nvidia insider and cannot be sure.

Anyway, currently we give "--extract-only" flag to *.run in x11/linux-nvidia-libs/Makefile, so anything required to be run for
detecting GPU to choose module flavor (proprietary or open) shouldn't
work here.

--
Tomoaki AOKI <junchoon@dec.sakura.ne.jp>

--
Tomoaki AOKI <junchoon@dec.sakura.ne.jp>


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2