Package Details: opencl-nvidia-390xx 390.157-13

Git Clone URL: https://aur.archlinux.org/nvidia-390xx-utils.git (read-only, click to copy)
Package Base: nvidia-390xx-utils
Description: OpenCL implemention for NVIDIA
Upstream URL: https://www.nvidia.com/
Licenses: custom
Conflicts: opencl-nvidia
Provides: opencl-driver, opencl-nvidia
Submitter: svenstaro
Maintainer: jonathon (vnctdj)
Last Packager: vnctdj
Votes: 61
Popularity: 3.45
First Submitted: 2020-03-11 17:29 (UTC)
Last Updated: 2024-11-25 23:34 (UTC)

Dependencies (2)

Required by (67)

Sources (16)

Pinned Comments

jonathon commented on 2022-05-26 09:46 (UTC)

Please don't flag this package out-of-date unless a new version has been released by NVIDIA.

jonathon commented on 2021-12-26 22:44 (UTC) (edited on 2021-12-26 22:44 (UTC) by jonathon)

The DKMS package guidelines are explicit that linux-headers should not be a dependency of any DKMS package.

As a concrete example of why including that as a hard dependency is a bad idea, what happens when linux is not an installed kernel?

jonathon commented on 2020-10-19 12:41 (UTC) (edited on 2021-05-11 14:18 (UTC) by jonathon)

PACKAGE NEEDS LONG TERM MAINTAINER

I have adopted the 390xx packages to keep them secure. I do not run any 390xx hardware so will not notice any breakages and cannot test any changes.

Until such time as someone else steps up to maintain these packages - ideally someone who actually has 390xx hardware - I have to rely on you to tell me what changes are needed.

Don't expect a response if you post only "this doesn't work", and do not email me to complain about the package not working!

Use this forum thread for discussion: https://bbs.archlinux.org/viewtopic.php?pid=1946926

A binary package is also available in my kernel-lts unofficial user repository.

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 .. 27 Next › Last »

susanne commented on 2024-05-20 11:57 (UTC)

thanks a lot for all efforts, with canolucas' patch the driver builds fine for kernel, kernel-lts and kernel-rt-lts

duht commented on 2024-05-20 10:15 (UTC) (edited on 2024-05-20 10:16 (UTC) by duht)

I just ment it's confusing for people, because they think that both patches are needed- one for kernel6.9 and another for gcc14, but they do the same (gcc14) job, so you should choose only ONE of them. Kernel6.9 as is- doesn't need any additional patch.

Great thanks to everyone who was involved in these patches!

drankinatty commented on 2024-05-20 03:19 (UTC)

Oh, you can name the patch posted by @canolucas anything you want. I just keep track of the patches by a simple convention of what prompted them. So I named the initial patch required for gcc-14 (gcc-14.patch) and the patch @canolucas kernel-6.9.patch. As noted they can be reduced to one. But call them whatever you like - I'm just glad they work!

duht commented on 2024-05-19 14:03 (UTC) (edited on 2024-05-19 14:05 (UTC) by duht)

@drankinatty naming this patch kernel-6.9.patch is quite confusing 'cause it does nothing to make NV drivers work with kernel 6.9. It just adds -fpermissive flag as workaround for gcc14 compilation errors. if you compile 6.9 kernel and NV drivers with older gcc- no patch is needed. In my opinion "oryginal gcc14.patch" is better solution because it adds workaround only for buggy conftest.sh instead of adding -fpermissive flag globally in Kbuild.

Halano commented on 2024-05-19 08:36 (UTC) (edited on 2024-05-19 09:07 (UTC) by Halano)

@drankinatty @canolucas Thanks for the patch works fine on 6.9 and 6.6.x lts

LukeMe commented on 2024-05-18 19:39 (UTC)

if it can be of any help, the patch posted by drankinatty does work with both the latest linux and linux-lts kernels

canolucas commented on 2024-05-18 14:43 (UTC) (edited on 2024-05-18 14:44 (UTC) by canolucas)

@drankinatty does this driver work applying only the gcc-14 patch ? Is that case, maybe we can avoid using -fpermissive to make the maintainance easier in the future. I agree that it can be tedious to rely on enabling and disabling this flag for debugging future kernel updates. I would add -fpermissive as a last resort, only if there is no other alternative.

drankinatty commented on 2024-05-18 00:39 (UTC)

Building with both patches worked flawlessly. The 6.9.1 hit today, the dkms module rebuild went without issue and the Nvidia driver is happy (of course Virtualbox broke -- but you can't win them all...)

I incorporated both the original gcc-14 patch (largely unneeded now that -fpermissive was added by the kernel-6.9.patch), and the kernel-6.9.patch, as shown below and it worked fine.

Thanks to @canolucas for the kernel-6.9.patch.

drankinatty commented on 2024-05-17 15:25 (UTC)

The good news, as with you, with both patches (the gcc-14.patch) and the kernel-6.9.patch, the driver build is fine for both the current 6.8.9 and 6.6.30 LTS kernels. All we need now is the 6.9 kernel to see if that holds true on reboot after update.

Long term -fpermissive is a Bandaid that we will have to deal with at some time. We will need to remove it, let the build fail, get a good log and then develop a proper patch that brings the 390.xx code up to build in the current environment. I had to do that once for KDE with the kernel-4.6 changes way back when in the 2011? timeframe. Just tedious...

canolucas commented on 2024-05-17 04:35 (UTC) (edited on 2024-05-17 04:42 (UTC) by canolucas)

@drankinatty you are right, the patch posted by @rodrigorc is missing the changes in conftest.sh however this package built fine anyways.

From what I see in the docs:

-fpermissive

Downgrades some diagnostics about nonconformant code from errors to warnings.

https://gcc.gnu.org/onlinedocs/gcc-4.0.4/gcc/C_002b_002b-Dialect-Options.html#index-fpermissive-140

-Wno-implicit-function-declaration -Wno-strict-prototypes -Wno-incompatible-pointer-types

Suppresses different types of warnings

So I guess all these flags are meant to work together to: First, convert the errors to warnings and secondly supress those warnings.

« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 .. 27 Next › Last »