Am 26.09.23 um 22:24 schrieb Carlos E. R.:

On 2023-09-26 22:11, Xu Zhao wrote:

...

Hello all,

I am a 5-years Tumbleweed user. I am also the maintainer of many Tumbeweed packages such as telegram-desktop, chezscheme, amdvlk, and yacreader. I have both AMD and NVIDIA desktops with openSUSE Tumbleweed installed.

NVidia closed-source GPU driver integration has always been a pain for rolling release like Tumbleweed because:

1) kernel's API keeps changing and it often takes NVidia 1~2 weeks to follow-up the latest kernel release in their new driver version (see http://rglinuxtech.com/ ); 2) people who don't care about NVidia do not want to slow down the rolling of kernel versions

For example, even today the version of nvidia-open-driver-G06-signed-kmp-default(https://build.opensuse.org/package/show/openSUSE:Factory/nvidia-open-driver-..., 535.113.01) is not compatible with nvidia-video-G06 (https://download.nvidia.com/opensuse/tumbleweed/x86_64/, 535.104) on Tumbleweed.

I am wondering if we can attract some users to Slowroll if it only releases snapshots whose kernel version is compatible with the NVidia GPU driver? At least I will be very interested to try it out on my Nvidia desktop. Similar case should apply for VMWare kernel modules, but if it takes too much additional efforts, I think we should priortize NVidia module integrity.

I don't think there can be priorities.

It is very important for Slowroll to be compatible with all commercial packages that are now compatible with Leap, in order to be able to claim the post as replacement.

I hope so, I'm using amdgpu-pro with Leap because of openCL. Darktable is about 35% faster on my computer with some operations when openCL is active. Peter

I will be interested to help and contribute if Slowroll claims that its kernel should support a selected group of close-sourced drivers (NVidia, AMDGPU Pro, VMWare), including adding testing, adding patches, etc. Of course, we can add a cadence that if a module blocks kernel upgrade for too long (say 2 weeks), we should drop it. I also feel that without this claim, Slowroll is much less attractive to me. Best, Xu -- Xu Zhao i@xuzhao.net On Wed, Sep 27, 2023, at 11:52 AM, Axel Braun wrote:

Hi,

Am Dienstag, 26. September 2023, 22:11:45 CEST schrieb Xu Zhao:

...

I am wondering if we can attract some users to Slowroll if it only releases snapshots whose kernel version is compatible with the NVidia GPU driver? At least I will be very interested to try it out on my Nvidia desktop.

I feel this could be one of the *real* benefits, to keep a working kernel until Nvidia wakes up and fixes their drivers for a newer kernel. This mainly up to the kernel maintainers to decide

Cheers

Axel

*Attachments:* • signature.asc

Am Mittwoch, 27. September 2023, 21:23:18 CEST schrieb Malcolm:

My understanding for the nvidia rpm's use dkms to rebuild for the kernel in use?

No idea, but in today's snapshot war a Nvidia kernel module for the current kernel (after the download.nvdia.com was not available yesteray)

I use the run file here without issues, there in no broken driver for any of the recent kernels for me. I'm currently using 535.113.01.

Still using the 470.xx driver Cheers Axel

My point is, even with dkms, it is possible that nvidia kernel driver does not build with the kernel version or have runtime issues. dkms works most of the times, but it could still break. If we hold the kernel version upgrade until nvidia kernel driver builds, we can avoid this problem completely. Best, Xu -- Xu Zhao i@xuzhao.net On Wed, Sep 27, 2023, at 11:38 PM, Andrei Borzenkov wrote:

On 27.09.2023 22:23, Malcolm wrote:

...

My understanding for the nvidia rpm's use dkms to rebuild for the kernel in use?

No, they do not.

Thanks for the response. I agree that Slowroll can definitely cover this use case under its release period, but my point is, in Slowroll we should *validate* the kernel version would build on NVIDIA/3rd party drivers *before* releasing a new Slowroll snapshot. Otherwise, if we don't test it, it means in the worst case, Slowroll is even worse than Tumbleweed, in which case it would stay on a kernel version that doesn't compile with NVIDIA/3rd party drivers for 20 days. I am thinking to have some CI/GH Action service to test the support the matrix of [kernel version x NVIDIA driver version], but don't have bandwidth to do it. I can update if there is any update. I feel kernel-lts flavor is an overkill for this purpose - it complicates the idea of slowroll. We only need to apply a filtering on the selection of Tumbleweed snapshots. It only needs to know if a Tumbleweed snapshot supports a selection of 3rd party kernel drivers, and if it doesn't, we skip it. Cheers, Xu -- Xu Zhao i@xuzhao.net On Tue, Oct 3, 2023, at 12:58 AM, Bernhard M. Wiedemann wrote:

On 26/09/2023 22.11, Xu Zhao wrote:

...

NVidia closed-source GPU driver integration has always been a pain for rolling release like Tumbleweed because:

1) kernel's API keeps changing and it often takes NVidia 1~2 weeks to follow-up the latest kernel release in their new driver version (see http://rglinuxtech.com/ ); 2) people who don't care about NVidia do not want to slow down the rolling of kernel versions

For example, even today the version of nvidia-open-driver-G06-signed-kmp-default(https://build.opensuse.org/package/show/openSUSE:Factory/nvidia-open-driver-..., 535.113.01) is not compatible with nvidia-video-G06 (https://download.nvidia.com/opensuse/tumbleweed/x86_64/, 535.104) on Tumbleweed.

I am wondering if we can attract some users to Slowroll if it only releases snapshots whose kernel version is compatible with the NVidia GPU driver? At least I will be very interested to try it out on my Nvidia desktop. Similar case should apply for VMWare kernel modules, but if it takes too much additional efforts, I think we should priortize NVidia module integrity.

For the previous cycle, the 6.4.x kernel was in Slowroll for 20 days longer than in Tumbleweed, so it should easily cover those 1-2 weeks for NVidia.

If you have some auto-updated web-page that tells about the status of those 3rd party drivers building / working with the lastest Tumbleweed kernel, I can take that into consideration. Bonus points if there is also a machine-readable variant.

We also have a dozen out-of-tree kmps such as virtualbox in OBS that can also fail to build with a new version: https://github.com/bmwiedemann/reproducibleopensuse/blob/devel/exceptions/na...

We might also get some kernel-lts flavor in the future that can help there.

Ciao Bernhard M.

Hi everyone, so do I understand correctly that the current download.nvidia.com/opensuse/tumbleweed/ repo is also compatible with Slowroll? What happens if the Slowroll kernel version gets behind the Tumbleweed kernel? Will the NVidia repo maintain multiple copies of the packages that were compiled for older kernel versions? For example right now they have three kernel-specific packages, but some are for k6.6.2 and another is for k6.5.9.

No, I don't think it will be compatible with Slowroll if Slowroll kernel version gets behind the Tumbleweed kernel. I am working on a GitHub actions repo (https://github.com/xuzhao9/opensuse-tw-nvidia-validator) to validate specific NVIDIA drivers on the opensuse Tumbleweed snapshots, and generate a matrix like: [(tw_snapshot, kernel_version) x nvidia_driver_version] Currently I am blocked by using Qemu kvm to kick of specific tumbleweed snapshot image and test nvidia driver compile (sth like open build system). If anyone knows how to do that, or simply give code pointers on how OBS runs Qemu KVM, that would be very much appreciated. Best, Xu -- Xu Zhao i@xuzhao.net On Mon, Dec 18, 2023, at 7:51 AM, S. wrote:

Hi everyone, so do I understand correctly that the current download.nvidia.com/opensuse/tumbleweed/ repo is also compatible with Slowroll? What happens if the Slowroll kernel version gets behind the Tumbleweed kernel? Will the NVidia repo maintain multiple copies of the packages that were compiled for older kernel versions? For example right now they have three kernel-specific packages, but some are for k6.6.2 and another is for k6.5.9.

Hi Bernhard, Thanks for your response! See my comments below: On Tue, Dec 19, 2023, at 3:24 AM, Bernhard M. Wiedemann via openSUSE Factory wrote:

On 19/12/2023 05.25, Xu Zhao wrote:

...

Currently I am blocked by using Qemu kvm to kick of specific tumbleweed snapshot image and test nvidia driver compile (sth like open build system). If anyone knows how to do that, or simply give code pointers on how OBS runs Qemu KVM, that would be very much appreciated.

https://github.com/nektos/act says

...

GitHub Actions are running in fully virtualized machines

so you probably cannot get KVM working there. But chroot or containers should be an option. Chroot or plain containers will not work because NVIDIA driver will not build when the host kernel gcc version is incompatible with the container kernel header. https://forums.developer.nvidia.com/t/conftest-failed-error-while-trying-to-... Conftest will fail when I was trying to cross-compile from a different kernel header files than the host kernel.

I was about to try https://github.com/docker/setup-qemu-action, since Docker claims that they could run QEMU on GitHub Action runners. However, I am not sure how to proceed (e.g., should I use tumbleweed:latest docker image or tumbleweed ISO).

OBS workers OTOH run on bare metal and thus have access to hardware needed for KVM.

Still, I am interested in what openSUSE Tumbleweed image is used in KVM. In the worst case, I could run self-hosted GitHub runner on my own bare-metal workstation, and run openSUSE Tumbleweed KVM images on it with GitHub actions.

Attachments: * OpenPGP_signature.asc

Best, Xu