Clarifying 560 series drivers' open sourced'ness vs kernel-module-type=proprietary

@aplattner @aritger @ekurzinger

  1. AFAIK your open source driver lacked some features that the proprietary driver had, is this still the case? Have they reached feature parity?
  2. Where should bugs be reported? Github or here?
  3. The open driver is not meant to be mainlined, are you eventually going to support nouveau/NVK?
  4. Can nouveau support your closed user space including CUDA, AI, RT/PT, DLSS, Optix, etc.? Will you add this support?
  5. Will various monitoring/configuration features (nvapi/nvidia-smi) work with nouveau?
  6. Will NVIDIA employees start hacking nouveau?
  7. Will Pascal and previous generation architectures support be open sourced or people will have to continue to utilize your closed driver?
  8. Are you going to release (more) parts of your user space as open source or it will be kept proprietary indefinitely?
  9. What prompted you to make this decision?
1 Like

Hi @birdie.

  1. AFAIK your open source driver lacked some features that the proprietary driver had, is this still the case? Have they reached feature parity?

In general, by release 560, the open kernel modules should have approximate feature parity with the proprietary kernel modules. I would categorize things into several buckets:

  • There have been a few lingering features that have taken us a while to address (e.g., notebook vrr) that will be in place with the open kernel modules by release 560.

  • Run Time D3 (RTD3) with the open kernel modules will only be supported on Ampere and later (with the closed kernel modules, we are able to support RTD3 on Turing, too). I doubt we will be able to enable RTD3 on Turing with the open kernel modules.

  • GPU initialization time, and GPU power utilization related things where the open kernel modules should have pretty close parity to the closed kernel modules in release 560, and we’ll continue to improve over time.

  1. Where should bugs be reported? Github or here?

In general, report bugs here on the forum. I would save the github issue tracker specifically for issues with the open kernel module source code itself (e.g., problems found by static analysis, etc).

  1. The open driver is not meant to be mainlined,

Correct.

are you eventually going to support nouveau/NVK?

The open out-of-tree kernel modules and proprietary user mode driver components are the production solution we recommend.

For nouveau/nvk, we try to provide some hardware documentation on GitHub - NVIDIA/open-gpu-doc: Documentation of NVIDIA chip/hardware interfaces, and provide some patches to NVK and nouveau. But, that help is pretty modest, so I can’t currently call that “support”.

  1. Can nouveau support your closed user space including CUDA, AI, RT/PT, DLSS, Optix, etc.? Will you add this support?

It is not currently possible to run our closed user space components on the nouveau kernel module. I don’t know if that would be possible in the future.

  1. Will various monitoring/configuration features (nvapi/nvidia-smi) work with nouveau?

Not currently, no.

(Well, at least not in general… we relicensed the nvapi API definition a while ago, to allow wine/proton to reimplement some nvapi entry points that were called by games run through dxvk, but that’s a fairly narrow case).

  1. Will NVIDIA employees start hacking nouveau?

It is currently modest, but several NVIDIA employees already work on nouveau and participate in Nouveau mailing list discussions.

  1. Will Pascal and previous generation architectures support be open sourced or people will have to continue to utilize your closed driver?

We will not be able to support pre-Turing with the open kernel modules. Users with Volta or older GPUs will need to continue to use the closed kernel modules.

  1. Are you going to release (more) parts of your user space as open source or it will be kept proprietary indefinitely?

I am not aware of any plans to publish the source code to other parts of our GPU driver stack.

  1. What prompted you to make this decision?

Which decision are you asking about?

For the decision to make the open kernel modules in the first place: I should refer back to the NVIDIA marketing blogpost when we first released it in 515: NVIDIA Releases Open-Source GPU Kernel Modules | NVIDIA Technical Blog

For the decision to make the open kernel modules the default: it was largely about testing. It is expensive to execute all of our test plans in each configuration of

  • closed kernel modules
  • closed kernel modules with GSP offload
  • open kernel modules

The open kernel modules are more desirable in general, so it makes sense to focus more of our testing there. And if that is where we focus our testing, that is the configuration we should encourage our users to use.

6 Likes

Thanks a ton for your answers!

Yeah, these mostly impact laptops, don’t they?

  • Preserving video memory across power management events.

This seems to be worst limitation at this time. Luckily, s0ix-based suspend (video memory refresh) still works just fine, so I’m able to daily drive the open flavour these days.

Is this final, or there’s still a chance Turing GPUs might get RTD3 support with the open modules?

I actually talked about this with someone that has a Turing gpu, and, apparently, RTD3 is working properly for Turing on Nouveau, both with and without GSP.

That leaves me pretty confused. If Nouveau is able to implement RTD3, why is Nvidia’s own driver not able to do so?

2 Likes

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.