Clarification on GPU support for Maxwell/Pascal archs and binary/OS relationship

[BlueGoliath]

Maxwell and Pascal architecture GPUs are still capable of handling modern gaming, computing, encoding, decoding, etc workloads. Is there no way support could be extended to these GPUs?

If not, what is going to be the relationship between this driver and the binary one? Will there be no more feature updates for the binary release(Vulkan, OpenGL, etc) and be solely a "legacy" driver?

[aritger]

Thanks for asking.

Maxwell, Pascal and Volta are definitely still important GPUs with a large user base; we aren't abandoning those GPUs!

Unfortunately, the open kernel modules here rely on the GSP (GPU System Processor), which was first introduced in Turing. That is why the open kernel modules can't support pre-Turing.

Fortunately, NVIDIA's internal code base is organized such that we share a lot of code between the open kernel modules in this repository and the proprietary kernel modules that are needed for pre-Turing GPUs. So, many/most changes to the open kernel modules will also apply and benefit the proprietary kernel modules. It is not as if the proprietary kernel modules will be ignored and allowed to bitrot.

For the foreseeable future, NVIDIA will continue to support both: the proprietary kernel modules and the open kernel modules. The two sets of kernel modules share a lot of code, they provide the same interfaces to the user-mode driver components like OpenGL, Vulkan, and CUDA, and they will continue to evolve together.

Users will need to choose at install time which set of kernel modules to install: if you're using pre-Turing GPUs, continue to use the binary kernel modules. If you're using Turing or later, and the current features/performance of the open kernel modules meet your needs, use the open kernel modules. Over the next several releases, we're working to close the feature/performance gap, such that the open kernel modules are as featureful and performant as the binary kernel modules.

Long term, yes, as pre-Turing GPUs age out, the focus will be on the open kernel modules. The open kernel modules will also evolve new features not possible in the binary kernel modules. I don't know timelines, but that is long term. Pre-Turing is definitely not considered "legacy" today.

Does that help clarify things?

[zfsbot]

i'm not sure if it was there half an hour ago when this question was asked, but in the How to Contribute section it says:

Note that when submitting a pull request, you will be prompted to accept a Contributor License Agreement.

This code base is shared with NVIDIA's proprietary drivers, and various processing is performed on the shared code to produce the source code that is published here. This has several implications for the foreseeable future:

The github repository will function mostly as a snapshot of each driver release.

We do not expect to be able to provide revision history for individual changes that were made to NVIDIA's shared code base. There will likely only be one git commit per driver release.

We may not be able to reflect individual contributions as separate git commits in the github repository.

Because the code undergoes various processing prior to publishing here, contributions made here require manual merging to be applied to the shared code base. Therefore, large refactoring changes made here may be difficult to merge and accept back into the shared code base. If you have large refactoring to suggest, please contact us in advance, so we can coordinate.

sounds like even if you contribute via pull-request here it will take a while to be reflected in the 'master' branch and the commit log will be obfuscated so that we can't easily git bisect the issues.

it's unfortunate, overall.

is NVIDIA planning on upstreaming this driver to kernel.org ?

[BlueGoliath]

It does clarify things somewhat. I just wish there was a roadmap on when Nvidia plans on dropping support for those cards. Graphics cards aren't cheap and the performance of Maxwell/Pascal/Volta is still very good.

If you can answer them, here are a few more questions:

If Nvidia was to drop support for all non-GSP firmware archs, would it be at the same time in order to unify behind the OS driver?

Does Nvidia have any plans on providing a way to make use of these GPUs past their legacy support, maybe via utilizing their VRAM as an extension of a support GPUs VRAM?

Does Nvidia have any plans to introduce OS exclusive CUDA or NVML functions or features? It sounds like support is the same regardless of driver, but to clarify, is it true that an application using CUDA/NVML will continue to work under the OS driver as it does currently with the binary one?

Edit, another question:

Will the nvidia-settings application, both in GUI and CLI, work with this OS driver? What about overclocking, is that possible with this OS driver?

Thanks for any answers!

[wyatt8740]

Long term, yes, as pre-Turing GPUs age out, the focus will be on the open kernel modules. The open kernel modules will also evolve new features not possible in the binary kernel modules. I don't know timelines, but that is long term. Pre-Turing is definitely not considered "legacy" today.

So, is this implying that "having open kernel modules" and "being on Pascal or Maxwell architectures" will continue to be mutually exclusive, and that there are no plans to open, say, Maxwell or Pascal modules in the near future?

Does Nvidia have any plans on providing a way to make use of these GPUs past their legacy support?

That is my biggest concern.

I have GPU's from the late 90's and early 2000's that I can use on a modern kernel, but it seems as though my current card is still destined for the rubbish bin or being mothballed on an old kernel (and bound to x86_64 and some rounding errors). Maybe there'll be hope if Nouveau can get some firmware signed, at the very least.

[AdrianVovk]

@aritger So how would a image-based distro handle this? Are we stuck either using the proprietary driver or losing support for those GPU generations? Or is there some way to parallel install the two drivers and only use the proprietary driver for the GPUs the open source one doesn't support?

[wyatt8740]

@AdrianVovk my understanding is that yes. for older cards, the moment that nvidia stops releasing binary updates for new kernels, or we want to use an unsupported CPU architecture (RISC-V, SPARC...) we lose support for those GPU generations.

And on supported cards, you can't get a fully working system with only free software still; the userland stuff (libGL, X server) continue to be binary-only. So you'd still need to install nonfree components. I don't think distros need to be worrying about this yet, unless the code gets mainlined into the kernel and some other problems regarding the non-free software that is still required are solved (if the code is adapted to use mesa/X.org, for instance).

Eventually it may have to be something left to user discretion, at least for systems like Debian. There could be an nvidia-module-free and an nvidia-module-nonfree package, or something like that, in the meantime, where nonfree grabs the non-free packages from Nvidia and has the user go through the EULA(s).

[aritger]

i'm not sure if it was there half an hour ago when this question was asked, but in the How to Contribute section it says:

Note that when submitting a pull request, you will be prompted to accept a Contributor License Agreement.
This code base is shared with NVIDIA's proprietary drivers, and various processing is performed on the shared code to produce the source code that is published here. This has several implications for the foreseeable future:
The github repository will function mostly as a snapshot of each driver release.
We do not expect to be able to provide revision history for individual changes that were made to NVIDIA's shared code base. There will likely only be one git commit per driver release.
We may not be able to reflect individual contributions as separate git commits in the github repository.
Because the code undergoes various processing prior to publishing here, contributions made here require manual merging to be applied to the shared code base. Therefore, large refactoring changes made here may be difficult to merge and accept back into the shared code base. If you have large refactoring to suggest, please contact us in advance, so we can coordinate.

sounds like even if you contribute via pull-request here it will take a while to be reflected in the 'master' branch and the commit log will be obfuscated so that we can't easily git bisect the issues.

it's unfortunate, overall.

is NVIDIA planning on upstreaming this driver to kernel.org ?

The important word in the How to Contribute section is may. We'll try to merge pull requests directly, and have done so for a few pull requests so far:

https://github.com/NVIDIA/open-gpu-kernel-modules/commits

But, in some cases where changes require more complex merging back into NVIDIA's internal shared code base, we can't guarantee that a pull request will always get reflected directly in the git history. We'll do our best, though.

I agree it is unfortunate. Having to reconcile changes here with an internal shared code base is the tradeoff we made in order to share code so that pre-Turing GPUs can continue to receive as much support as possible.

And, no: we don't plan to attempt to upstream the driver here as-is.

[aritger]

If you can answer them, here are a few more questions:

If Nvidia was to drop support for all non-GSP firmware archs, would it be at the same time in order to unify behind the OS driver?

I don't know. But, based on past history, we haven't dropped support for that many GPU architectures in one shot. E.g., Volta is much newer than Maxwell, so I doubt we would drop support for all of those together.

Does Nvidia have any plans on providing a way to make use of these GPUs past their legacy support, maybe via utilizing their VRAM as an extension of a support GPUs VRAM?

I'm not aware of any plans there.

Does Nvidia have any plans to introduce OS exclusive CUDA or NVML functions or features? It sounds like support is the same regardless of driver, but to clarify, is it true that an application using CUDA/NVML will continue to work under the OS driver as it does currently with the binary one?

It is the goal that an application using CUDA/NVML will continue to work under the OS driver as it does currently with the binary one. Anywhere that goal is not satisfied is a bug.

Edit, another question:

Will the nvidia-settings application, both in GUI and CLI, work with this OS driver? What about overclocking, is that possible with this OS driver?

Yes, nvidia-settings works with this OS driver.

I don't know the current state of overclocking support, though.

Thanks for any answers!

[aritger]

@aritger So how would a image-based distro handle this? Are we stuck either using the proprietary driver or losing support for those GPU generations? Or is there some way to parallel install the two drivers and only use the proprietary driver for the GPUs the open source one doesn't support?

I don't have great solutions to offer for an image-based distro. The open kernel modules (a) will only support Turing and newer GPUs, and (b) have the same kernel module names and provide the same interfaces as the proprietary kernel modules. Maybe an image-based distro could do something clever with having both sets of kernel modules on the file system, and choose which ones to use based on the hardware it detects, but there isn't any facility for that in the NVIDIA drivers.

[gnud]

@aritger So how would a image-based distro handle this? Are we stuck either using the proprietary driver or losing support for those GPU generations? Or is there some way to parallel install the two drivers and only use the proprietary driver for the GPUs the open source one doesn't support?

I don't have great solutions to offer for an image-based distro. The open kernel modules (a) will only support Turing and newer GPUs, and (b) have the same kernel module names and provide the same interfaces as the proprietary kernel modules. Maybe an image-based distro could do something clever with having both sets of kernel modules on the file system, and choose which ones to use based on the hardware it detects, but there isn't any facility for that in the NVIDIA drivers.

https://www.nvidia.com/en-eu/geforce/graphics-cards/gtx-1650/ In this card it says it is based from "NVIDIA Turing™ architecture", so does this means I can use(try) these drivers for my laptop?

[mtijanic]

@gnud Architecturally, your mobile GPU does have the needed hardware. However, this was not part of the test matrix for this release and there are definitely notebook-specific features that are not supported in the current release. I don't expect you'll have a good time using the current driver on a laptop, so I can't recommend it.

Notebook support will come in one of the future releases.

[a1batross]

So for NVIDIA it is either to add support for legacy firmware here, either port GSP to older cards?

Or do nothing and just wait for old cards to die :)

[mtijanic]

@a1batross The GSP is a new microcontroller on the GPU that was added with Turing. It is not possible to "port it to older cards" as those simply do not have that HW at all. Therefore it is simply not possible for this new driver architecture to support pre-Turing.

And, to be clear, while we do share a lot of the code here with the proprietary driver, this is a significantly different driver architecture. There are currently no plans to either drop support, or to open source the proprietary driver which supports Maxwell and later.

[a1batross]

@mtijanic I see, thanks for details.