Nouveau NVIDIA GSP Firmware Support Merged For Linux 6.7

[toughy]

For those looking to try this out, I posted changes to linux-firmware here: https://github.com/NVIDIA/linux-firm...a8e6fdf0d9866d

I'm working on getting this merged into the real linux-firmware repo.

Did these files actually work for you ?

I have extracted the same files as well, but the latest nouveau would not work with them on my TU102 chip, and airlied already said previously in this thread nouveau needs some slightly modified firmware for the new GSP code path

[tabicat]

Did these files actually work for you ?

Yes. I am the person responsible for making the firmware images that Nouveau needs available.

I have extracted the same files as well, but the latest nouveau would not work with them on my TU102 chip, and airlied already said previously in this thread nouveau needs some slightly modified firmware for the new GSP code path

Are you sure you're using the driver from 6.7-rc1? Did you install the firmware images correctly? Did you boot with the correct command-line parameters?

[Khrundel]

I was clear OS vendor not chinese laptop vendor.

I don't care what you was "clear" about. Microsoft says about OEM builders and their obligations. Chinese laptop makers included. And these obligations start and end with signature checking, so you lied again when you told audit is a required by MS. MS do not require any audit. If some party adds such requirements from itself, well, it is a problem of that party. Good luck them trying.

https://thenewstack.io/linux-kernel-finally-gets-its-lockdown/

The Linux kernel it self is a hypervisor so you end up with a LSM auto turning on in secureboot mode again at Microsoft request.

So what? How special kernel mode for special use case is related to nvidia driver? You know, kernel has many different applications, including IoT for example, does nvidia driver has to be compatible with them all? Are you planning to play games on a hypervisor, or maybe you will just pass gpus to guest systems? And, assuming there will be some real need in working nvidia drivers on a hypervisor, don't you think this petty problem can be negotiated to something like "ok, locked down kernel could accept kernel modules signed by nvidia too" or "by nvidia and microsoft simultaneously".

Can't you write a single post without lying?

Think about it Khrundel how can you confirm Linux kernel hypervisor functionality is disabled while loading a third party closed source kernel module into it. GRUB should not install a hypervisor has some major knock on effects.

It works right now. I mean you can open docs from redhat for example and see how it suggest to work with secureboot, including module signing. Spoiler: you can install trusted certificates so there won't be any problem with nvidia signature.
Secure boot is not designed to somehow "confirm" security, it only ensures all parties belong same "covenant" and in case of found problem you can find responsible for breaking a covenant rules.

That not in fact true they did make sure that nouveau would work over the m.2 port of the steamdeck. Collabora does work on lots of different projects for Valve.

Another fantasies from you. Steamdeck is a cheap play device not intended for upgrade. It even doesn't support ssd replacement in lower edition. And now you suggest valve wants their customer to take off deck's cover, make hole in it to pass wires to connect nvidia card. And pays for nouveau development for this corner case instead of just install nvidia blob.

That 2021 is using the AMD closed source driver on LInux. Its not working right. Clear sign of trouble in that set of benchmarks is the Quake RTX performance has improved. These benchmarks don't run the Conformance test suite for vulkan. RADV submit code has to pass the conformance test suite for the standard.

Stop playing fool. You've told nvidia had no "working raytracing" before march 2022, and I've proved you lied again.

Why people end up changing to radv is higher test suite conformance.

No.
Nobody cares about any stupid test suite conformance, you fool. The only reason people switch to radv is game compatibility and support (meaning issues will be fixed faster than "next year or a year after next". Would amd offer decent support nobody would care developing or using radv. I had an amd card before and I remember problems of fglrx, when AMD used to promise to release updated driver at least 4 times a year and always break this promise. That is the reason of radv existance, not mythical standard conformance.

There is a problem here. high-performant does not mean standard conforming driver.

Old fairytales about magic standard conforming. In reality no implementation conforms all standard features and nvidia always had greater conformance.
What nvidia lacks is DRI conformance, but this is not its problem.

Fun part: while talking about unix way and importance of open standards, linux community had invented their own wddm/directX stack and now bashing nvidia for implementing open standards itself instead of using single blessed library mesa. And one of the reason of this criticism is wayland problems. But why wayland is so important? Well, because everybody is tired of X11 and its single blessed xorg. So, to get rid of single monstrous xorg faster we need to create single monstrous mesa. And that idiots, when they did initial planning for wayland, have injected internal mesa features and didn't noticed an irony of that. And now they blame nvidia because their new project is not compatible with nvidia drivers.

Is that a new feature... No Opacity Micro Maps not that was in the nvidia data center GPUs 2 years before that under a different name as a CUDA item.

I don't know and I don't care. Maybe it is an application of some old technology, all that matter is it is good and nvidia has it but amd not.

This is why it does not pay to assume. AMD did know about the feature over a year before release due to the data center cards. The high end data center cards documented ray tracing errors from using the Opacity Micro Maps functionality. For exact simulations this level of error is not tolerable.

AMD did not know that Nvidia was bring the feature to the lower end cards and that the errors were minor from game user point of view.

Its the old legal trick with discovery of provide way too much information and miss leading information in the hope the other side cannot find the critical stuff this also makes the other side process a stack of garbage.

I'm glad you've invented some story explaining why AMD lacks that feature, but it doesn't object my point. Using your words, all you've written is garbage intended to hide my argument without answering it. And argument stays: you can't give 3rd party opensource developers all information needed to make effective implementation of drivers for your new product without giving up your new tricks to competitors.

So whole opensource driver idea is bullshit. Some legacy product support - maybe, but nothing more.

[oiaohm]

It works right now. I mean you can open docs from redhat for example and see how it suggest to work with secureboot, including module signing. Spoiler: you can install trusted certificates so there won't be any problem with nvidia signature.

What works right now and what are the future requirements are two different things.

https://developer.nvidia.com/blog/nvidia-releases-open-source-gpu-kernel-modules/

This release is a significant step toward improving the experience of using NVIDIA GPUs in Linux, for tighter integration with the OS, and for developers to debug, integrate, and contribute back. For Linux distribution providers, the open-source modules increase ease of use. They also improve the out-of-the-box user experience to sign and distribute the NVIDIA GPU driver. Canonical and SUSE can immediately package the open kernel modules with Ubuntu and SUSE Linux Enterprise Distributions.

That install trusted certificate would mean Nvidia driver would be outside the main distribution repo in future remember how people are told not to use the drivers straight from Nvidia when their distribution has a tested version due to the kernel patches distributions have applied... Yes Nvidia mentions right here that part of open sourcing the driver is so it can be signed. Not signed by Nvidia but signed by Redhat/SUSE/Canonical. This links back to the secureboot requirement pushed on them.

So the future on Linux does not have a closed source NVIDIA kernel module.

Another fantasies from you. Steamdeck is a cheap play device not intended for upgrade. It even doesn't support ssd replacement in lower edition.

https://www.youtube.com/watch?v=GSvdsic4_dk

No this is you lieing. Valve worked with ifix to write instructions how to upgrade the ssd. Valve does intend for users to upgrade/replace parts in the steamdeck.

And now you suggest valve wants their customer to take off deck's cover, make hole in it to pass wires to connect nvidia card. And pays for nouveau development for this corner case instead of just install nvidia blob.

That a no on the nvidia blob working. Nvidia closed source driver in fact errors out when GPU is connected to PCI that should be M.2. Yes the Nvidia direct i/o feature support coming back to bite.
Developer testing of game issues it would have been good to be able to get a Nvidia GPU connected as well. Yes getting the open source nouveau driver working confirmed that the Nvidia card could in fact work with the PCIe signals being sent out the M.2 slot of the steamdeck so isolating it to a Nvidia binary blob issue.

Yes if this had worked there may have been a custom back-plate for developers made there is a mark in the cad files valve provided of the steam deck case for the slot required to let the PCIe break out cable out.

Nobody cares about any stupid test suite conformance, you fool. The only reason people switch to radv is game compatibility

One problem this is confirmed by Valve zink work. Game compatibility and test suite conformance is in fact linked.

Old fairytales about magic standard conforming. In reality no implementation conforms all standard features and nvidia always had greater conformance.

https://www.khronos.org/conformance/adopters/conformant-products/opengl

Not in fact true that Nvidia has greater conformance. Really pays to read the above site. Notice for Linux Nvidia conformance tests their latest on their arm platforms but on x86 linux they don't conformance test more than once.

Yes AMD notes new opengl test suite version opengl-cts-4.6.3.2 then proceeds to retest.

Nvidia does not have greater conformance to opengl and vulkan standards. You will notice that major releases of the AMD closed source drivers align with the test suite updates at khronos.

As part of khronos as Nvidia is they are meant to by the rules publish their conformance test suite runs. Many bugs get into the Nvidia closed source drivers that should have been detected by the conformance testsuite so they must not be running it on every driver major build like AMD does.

The Nvidia embedded product developers run the Khronos conformance test suites all the time.

Some of the issues with Intel closed source drivers is also clear as day when you look at the khronos group conformance suite test result publishing. Clear markers of not retesting everything and not telling anyone what hardware they have and have not tested. Yes and note arc GPU how there is a Linux test yet no Windows test.

Really when it comes to conformance testing both Intel and Nvidia could serous-ally lift their game. I will give you that Nvidia needs to lift it less than Intel does.

AMD has the greatest conformance out of all GPU vendors when it comes to opengl and vulkan and this is because they do invest the resources running the tests..

you can't give 3rd party opensource developers all information needed to make effective implementation of drivers for your new product without giving up your new tricks to competitors.

Atomicbios from AMD is about addressing this issue. AMD is able to release modules that no production GPU will ever have.

Yes you might give new tricks to your competitors but you also can give a bunch of dead end as well.

[toughy]

I tried the new firmware files 535.113.01 with latest kernel 6.7.0-rc0 build 311 from Fedora, on my TU102 chip.

Nouveau stills does not work with them. glxinfo shows "DRI3 not enabled" and uses llvmpipe. Same for vulkaninfo, it shows "No DRI3 support detected"

[toughy]

Yes. I am [...] making the firmware images that Nouveau needs available.

Are you sure you're using the driver from 6.7-rc1? Did you install the firmware images correctly? Did you boot with the correct command-line parameters?

tabicat airlied Do you guys maybe know why I get "DRI3 not enabled" on my Fedora and openSUSE installations, when I enable the kernel parameter for GSP, but other users report success using Arch Linux, plus it works for you as well ?

I am now using kernel 6.7-rc2, and I compiled mesa 24.0 from git, and installed it under my home directory, and compiled libdrm from git, and installed it under both my home directory and /usr/local/.

dmesg shows nouveau loading the GSP firmware with no message of a missing file:

nouveau 0000:41:00.0: gsp:msg fn:4123 len:0x24/0x4 res:0x0 resp:0x0

and my openSUSE also shows:

[ 560.624304] nouveau 0000:41:00.0: gsp: cli:0xc1d00002 obj:0x00730000 ctrl cmd:0x00731341 failed: 0x0000ffff
[ 560.625089] nouveau 0000:41:00.0: gsp: cli:0xc1d00002 obj:0x00730000 ctrl cmd:0x00731341 failed: 0x0000ffff

Does it matter that I also have an AMD Radeon RX 5700 XT card (with no monitors) next to my RTX 2080 Ti ?

[tabicat]

Offhand I don't know, but this does look like something that needs to be debugged. Unfortunately, we don't really have any good ways to field-debug GSP issues with Nouveau.