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.

[walterav1984]

@gnud

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?

Maybe supported with optional kernel parameter?

http://us.download.nvidia.com/XFree86/Linux-x86_64/515.43.04/README/kernel_open.html

    options nvidia NVreg_OpenRmEnableUnsupportedGpus=1

https://github.com/NVIDIA/open-gpu-kernel-modules/issues/20
https://github.com/NVIDIA/open-gpu-kernel-modules/issues/87

[Newbytee]

Since we're on the topic of supporting older GPUs, is there any chance that you could release the firmware necessary to enable reclocking and reasonable fan curves on Maxwell and Pascal in such a manner that Nouveau can make use of it? It would be great since these GPUs are in a sort of no man's land of neither being usable with Nouveau nor being supported by this new open driver. I understand the classic driver still will support Maxwell and Pascal for the foreseeable future, but I'm concerned about what happens after that. If it's not possible for one reason or another, I understand, but it would be great to see this finally happen.

[stalkerg]

I totally agree with @Newbytee that for older GPUs signed firmware's with reclocking and some documentation will be enough.

[Daasin]

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.

Really hoping for something like this for Pascal's GTX10 series, open-sourced resources would be seriously helpful

[nekoteai]

will this driver keep update with the proprietary one?

[mtijanic]

will this driver keep update with the proprietary one?

Yes, we expect that every subsequent release of the proprietary driver comes with a fresh code drop to this repository.
There might be cases where a minor bugfix release in the proprietary driver is not relevant for open-gpu-kernel-modules (or Linux in general) so we might skip that particular one.

[smxi]

aritger, that was a useful clarification, thanks. It sounds to me then like Maxwell, Pascal, Volta microarchitectures can be assumed to also be the basis for the next Legacy driver? That would make for a logical cutoff point then. Since there are as far as I know no lists published of device product ID => microarchitecture names, trying to add in support for this before the next legacy driver release, which will then list the product ids that will be legacy for that series will be tricky, since the only turing/ampere tables I know of are in the nvidia wikipedia page, and those don't list product ids, just product names/series names.

But bit by bit. This must be a lot of work, and difficult balancing act to maintain between the open kernel module code, and the nonfree module code, I don't envy you. Hopefully you wont' have to try to maintain that balance too long. I appreciate your work, I've waited for this for a long time, and realize we're probably looking at year plus to get the desktop linux userspace module code open, and the desktop module out of alpha state, but it's a great start, has to start somewhere. As the chinese proverb goes, best time to plant a tree: 20 years ago. Second best time: today.

[krbroten]

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?

I would suggest decoupling modules for non-gps and gps cards. Some users are multi gpu users. and would like to remain as open source as possible. Allow current gen cards to have the open source module installed. plus offer a non-gsp module as a additional proprietary module if you need additional legacy card support. the prepackaged proprietary drive would include both until non-gps support is dropped eventually.

Nvidia x server settings app needs way more fine controls. with configurations for features/overrides of openGL, and Vulkan behaviors exposed. and fan curve and over clocks.

[krbroten]

sh ./NVIDIA-Linux-[...].run --use-open-kernel-modules should be added. this would install the non-gsp module, but leave compiled open module in place. of course the gsp and non-gsp support would need to be decoupled to do this. compiling instructions could be printed to cli output at end of install.

additionally the installer could have switches to select a proprietary gsp only install. sh ./NVIDIA-Linux-[...].run --use-gps-kernel-modules

[dylanmtaylor]

@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.

I tested this driver for fun on my mobile workstation with an Turing-based Quadro T1000 Mobile. It works great, but definitely has issues. Namely, it doesn't resume from sleep correctly. Reverting to the proprietary driver solves the issue.

[dylanmtaylor]

will this driver keep update with the proprietary one?

Yes, we expect that every subsequent release of the proprietary driver comes with a fresh code drop to this repository. There might be cases where a minor bugfix release in the proprietary driver is not relevant for open-gpu-kernel-modules (or Linux in general) so we might skip that particular one.

Wouldn't it make more sense to have the open source component be the upstream and then pull that into the proprietary driver? That way you wouldn't have to release changes in 'drops' without history.

[wyatt8740]

Yes, we expect that every subsequent release of the proprietary driver comes with a fresh code drop to this repository. There might be cases where a minor bugfix release in the proprietary driver is not relevant for open-gpu-kernel-modules (or Linux in general) so we might skip that particular one.

Wouldn't it make more sense to have the open source component be the upstream and then pull that into the proprietary driver? That way you wouldn't have to release changes in 'drops' without history.

Yes, but I get the impression Nvidia probably has existing internal infrastructure that isn't tooled towards a free software project, and is used to doing things a certain way.

I think it also shows where Nvidia's priorities currently are. Sharing stuff with free licenses hasn't been a very common occurrence for them in the past, and the corporate mentality seems to be geared towards the proprietary stuff. It reminds me of Android open source code drops that some phone manufacturers do (or did) - obeying the letter of the law, but not really fully committing to the principles of free software. They might just be testing the waters.

Hopefully this is just a transitional phase, and things will just get better from here on out as the wrinkles get ironed out.

[Zigler]

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?

Why don't you all just virtualize and or emulate the GSP as a compatibility interface to the older architecture's? Be it an intermediate layer it would allow reverse compatibility for these older architecture's.

[gardotd426]

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.

@zfsbot This is 100% in line with how analogous projects from other manufacturers work. AMD does this exact thing for the open-source Linux Vulkan driver they develop (AMDVLK, they don't provide any development on Mesa's RADV). Only actually, it's even more extreme. The AMDVLK GitHub repository has zero commits outside of README updates and occasional Vulkan spec bumps to the ICD json file. See for yourself:

What Nvidia is proposing here goes far beyond that. But the reasoning in both instances is the same, and @aritger is right in saying that that's just how it is with the way this and AMD's AMDVLK projects work. In both cases, the open source projects share the majority of their code base with proprietary software - in this instance, it's obviously the binary kernel modules, with AMDVLK, it's AMD's proprietary Vulkan driver, AKA vulkan-amdgpu-pro - and development is pretty much exclusively done in-house (I don't even think AMD even accepts any PRs of any note for AMDVLK).

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

That's never going to happen, and it shouldn't. The "right" way of doing things vis a vis kernel modules - open sourcing them under a compatible license and upstreaming them to become a part of the Linux kernel - is a holdover from a bygone era, and following that methodology causes a ton of headaches when it comes to certain hardware, especially GPUs. GPUs need to be able to release driver updates immediately to push bugfixes, functionality required for newly released games, etc. Upstreaming the modules means you're locked into the Linux kernel release schedule. Which means you need to get your code merged 9-10 weeks ahead of when you want/need it to be available in a stable kernel release. Which is why new AMD GPUs often don't work on Linux on their release day period, unless you have another GPU or iGPU with which you can build the latest RC kernel from source, install that, and then install the new GPU. I've experienced it with multiple AMD GPUs that I bought on release. Meanwhile Nvidia GPUs work on day 1, without exception, because they release a driver update providing support for the new GPU on or before launch.

Since Nvidia produces the entire driver stack for their GPUs, unlike AMD (well, AMD do produce an entire functional driver stack, but no one uses their userspace drivers, everyone uses Mesa), they need to be able to release driver updates as a whole, which is incompatible with upstreaming the kernel modules.

[eatcosmos]

To understand GPU working principle by reading this repo's code, Can I directly do experience with this open-gpu-kernel-modules on my working ubuntu 20.04 with GeForce GTX 750Ti? To replace my ubuntu's X.Org X server - Nouveau display driver?
Will this repo debug behavior destroy my working ubuntu 20.04?

[a1batross]

@eatcosmos it's useless without userspace part and this module also only supports new cards that have GSP microcontroller, like physically.

That was explained in the replies above.

[tanguofu]

As the title Clarification on GPU support for Maxwell/Pascal archs and binary/OS relationship #19 , the Volta arch will be support ?

[marcan]

Why don't you all just virtualize and or emulate the GSP as a compatibility interface to the older architecture's? Be it an intermediate layer it would allow reverse compatibility for these older architecture's.

Because the GSP exists so that Nvidia could move most of the driver into firmware. This repository isn't actually a full driver, it's only part of a driver, the majority (dozens of megabytes) is in GSP. Emulating the GSP would make its code part of the "open" driver, which means they would actually have to open source everything (which they don't want to), or they would have to keep it as a binary linked blob which means giving up using Linux features that can only be used by properly GPL-compliant open source drivers (like DMA-BUF). Having the closed source bits run on another CPU is a convenient licensing workaround that allows Nvidia to publish an "open" driver without actually opening up most of their code, and still get to use GPL-only features.

Make of that what you will. Every other GPU manufacturer has no problem maintaining an open source kernel side driver without megabytes of blobs, but it seems Nvidia seems to have trouble with the concept.

(Put another way, they already have a driver that "emulates" GSP, i.e. does everything that it does. It's their proprietary driver. And they want to keep it, the proper, full driver, proprietary. If they were okay with open sourcing things they would just open source that one, but instead they built this whole GSP mechanism just to avoid having to do that! Nvidia is so committed to not open sourcing their driver that they added an entirely new CPU to their cards just to run it.)

[smxi]

That's a depressingly accurate summation.

[mcirsta]

I just like how the questions about re-clocking and firmware support for Pascal were dodged. It means that's a we're no allowed to talk about it and most likely nothing will happen.
Having bought a GTX 1060 because it was the only one I could find at the time at a decent price I regret this entire behavior by Nvidia.
I will sell it and get one from companies that actually have not gone out of business even though the have open source Linux drivers.
It's like Nvidia has some secrets that can change mankind in those damn drivers because we can't get proper open source support for out cards.

[PAR2020]

How the monolithic and open kernel modules interact with the various GPU families has been answered, along with which GPUs (with GSP FW) support the open kernel modules - both in issues and discussions. We will close this issue as a result.

As has been mentioned many times, NVIDIA has just begun the journey into open source, with the help of the user community. Please do continue to participate in discussion topics to allow your voice to be heard, and to report new issues and suggestions as the driver evolves. In the coming months, full laptop functionality will roll out with new open kernel module releases. We thank you all for your patience and support!

[Daasin]

May this issue perhaps be converted into an opened discussion instead of all issues/discussions on the topic being closed outright? 😕 🙏

[mtijanic]

May this issue perhaps be converted into an opened discussion instead of all issues/discussions on the topic being closed outright? confused pray

Please feel free to open a new discussion thread if there are unanswered topics. This issue is already filled with a ton of digressions and is hard to follow. Ideally, it would have been several separate discussion topics from the start, but that ship has sailed unfortunately.

[SpidFightFR]

So in conclusion: the only hope for an open source driver on Linux (for the gtx 1080 ti and below) is the xorg nouveau driver? Since nvidia decided to just give up on open source driver for pre-turing…
Not very reassuring, if you ask me.

[itsTyrion]

Is there any chance of UNDERvolting for Pre-Turing coming or not?

[Daasin]

May this issue perhaps be converted into an opened discussion instead of all issues/discussions on the topic being closed outright? confused pray

Please feel free to open a new discussion thread if there are unanswered topics. This issue is already filled with a ton of digressions and is hard to follow. Ideally, it would have been several separate discussion topics from the start, but that ship has sailed unfortunately.

#366 - Done, although wasn't able to link to this due to me not creating this issue.

[sl1pkn07]

@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.

maybe a modchip?

greetings

[johnnynunez]

If switching to open module, experimental support for GeForce and Quadro SKUs can be enabled with:

echo "options nvidia NVreg_OpenRmEnableUnsupportedGpus=1" | sudo tee /etc/modprobe.d/nvidia-gsp.conf

[Dani3I]

If switching to open module, experimental support for GeForce and Quadro SKUs can be enabled with:

echo "options nvidia NVreg_OpenRmEnableUnsupportedGpus=1" | sudo tee /etc/modprobe.d/nvidia-gsp.conf

Wait, what does that mean? Does it have something to do with maxwell and pascal architectures?

[timur-tabi]

Does it have something to do with maxwell and pascal architectures?

No, it's because some Turing or later GPUs aren't supported without this option enabled.

[johnnynunez]

Basically, turing and forward have GPU System Processor (GSP). https://download.nvidia.com/XFree86/Linux-x86_64/510.39.01/README/gsp.html