Open-Source NVIDIA "Nouveau" CRC Support Ready For Linux 5.9

[phoronix]

Phoronix: Open-Source NVIDIA "Nouveau" CRC Support Ready For Linux 5.9

Stemming from documentation released by NVIDIA last year, the forthcoming Linux 5.9 kernel will feature CRC support on the display side thanks to the development work by Red Hat...

http://www.phoronix.com/scan.php?page=news_item&px=Nouveau-CRC-For-Linux-5.9

[kpedersen]

It is nice to see at least some news on Nouveau.

I was reading up on it and in particular this part from the web page.

• Little hope of reclocking becoming available for GM20x and newer GPUs as firmware now needs to be signed by NVIDIA to have the necessary access.

I can't remember why and I am sure there is a technical issue but what is the reason we can't just extract the signed firmware out of the proprietary driver? Yes it would become less free but we wouldn't be breaking agreement if it was done at runtime like the old Broadcom fw_cutter and would still allow us to benefit from all the advantages of an in-kernel-tree driver, such as KMS, Wayland and continued support for older cards. All of these areas, the proprietary blob is lagging behind in.

[FireBurn]

I'm not sure the quotes around Nouveau were really required and probably made more sense around NVIDIA if anything

[cl333r]

They're working on Nouveau reclocking support, should be ready by 2032.

[yoshi314]

It is nice to see at least some news on Nouveau.

I was reading up on it and in particular this part from the web page.

• Little hope of reclocking becoming available for GM20x and newer GPUs as firmware now needs to be signed by NVIDIA to have the necessary access.

I can't remember why and I am sure there is a technical issue but what is the reason we can't just extract the signed firmware out of the proprietary driver? Yes it would become less free but we wouldn't be breaking agreement if it was done at runtime like the old Broadcom fw_cutter and would still allow us to benefit from all the advantages of an in-kernel-tree driver, such as KMS, Wayland and continued support for older cards. All of these areas, the proprietary blob is lagging behind in.

one of devs said that firmware upload process is much more difficult to track now, so each driver release would be a tedious process wrt fw extraction.

that, and they were hoping nvidia would eventually release the firmware.

[imirkin]

It is nice to see at least some news on Nouveau.

I was reading up on it and in particular this part from the web page.

• Little hope of reclocking becoming available for GM20x and newer GPUs as firmware now needs to be signed by NVIDIA to have the necessary access.

I can't remember why and I am sure there is a technical issue but what is the reason we can't just extract the signed firmware out of the proprietary driver?

Feel free to peruse my comment from some time back which covers this:

https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source-nvidia-linux-nouveau/998310-nouveau-persevered-in-2017-for-open-source-nvidia-but-2018-could-be-much-better?p=998427#post998427

Note that nouveau does support kms/wayland/etc -- just not reclocking.

[vb_linux]

Though without reclocking and power management, the driver is a joke. This is despite the best efforts of Nouveau developers. I am not sure what keeps them going despite these tremendous odds against them. So, kudos and cheers to them.

On a side note what happened to Nvidia's open-source announcement? It was supposed to be in March. I know "COVID happened" but this situation has not really impacted their software solutions and neither has it impacted their product release. Seems like another empty promise.

[Guest]

one of devs said that firmware upload process is much more difficult to track now, so each driver release would be a tedious process wrt fw extraction.

that, and they were hoping nvidia would eventually release the firmware.

I'm assuming there's more to it than that, but I'd be content with just being able to extract firmware once from any modern driver. Assuming the needed firmware would just handle re-clocking, it shouldn't change too much between driver releases, at least with Maxwell.

But I wonder if there's another way to go about this. If re-clocking is the only issue, what about a VBIOS mod that just straight-up removes all clocks aside from the highest one? Not elegant, but I have a laptop, and can just turn the NVIDIA GPU off when I'm not using it. If I'm using it, I want the full power out of it anyway, and I assume nouveau isn't limited by the VBIOS needing to be signed or valid.

[c117152]

On a side note what happened to Nvidia's open-source announcement? It was supposed to be in March. I know "COVID happened" but this situation has not really impacted their software solutions and neither has it impacted their product release. Seems like another empty promise.

They hoped to stop relying on trade secrets and release Ampere with FOSS drivers assuming the new patents in AI, VR, Ray Tracing, and Automotive will be enough to protect themselves. But, since those, outside HPC, sorta sucked, they gave up.

Regardless, most of the core GPU patents are past protection with multiple players at all sizes developing their own cores so it won't be long before closed source graphics won't be an issue.

[imirkin]

But I wonder if there's another way to go about this. If re-clocking is the only issue, what about a VBIOS mod that just straight-up removes all clocks aside from the highest one? Not elegant, but I have a laptop, and can just turn the NVIDIA GPU off when I'm not using it. If I'm using it, I want the full power out of it anyway, and I assume nouveau isn't limited by the VBIOS needing to be signed or valid.

The tables in the VBIOS are just that -- tables. The list of power levels in them doesn't affect the current setting of the GPU. A complete driver can use the data in the VBIOS to perform actions which cause the various clocks to change. But merely changing things in the VBIOS data tables doesn't really do much. The GPU boots up however it boots up, and the fixed init sequence in the VBIOS does whatever it does, not dynamic based on power table contents.