Nouveau NVIDIA GSP Firmware Support Merged For Linux 6.7

[dragon321]

Yes and no idea. I don't really do much benchmarks here. It's faster than it was is all I got.

Thanks. I'll try that on my 3060 when Linux 6.7 will be released.

[Khrundel]

https://www.phoronix.com/review/nouveau-summer-2018/3

Redhat/IBM have been willing to invest large amounts of development into having having working nouveau drivers for a long time.

You've already caught lying about nvidia publishing hardware specs and nvidia trying to opensource its drivers and now you expecting anybody will take your word for this? No, they will never waste money to give you your beloved opensource driver.

Valve started working with Intel GPU before AMD. Valve would have worked on Nvidia drivers to get wayland support working if they had access to the source code and firmware. Valve saw no point at this stage of working on nouveau because the firmware was crippled this has changed a bit after the GSP shared firmware.

You can try to shape reality in a way to conform your theories, but real reason Valve do not touch nouveau is because nobody need it when there is a vendor supported blob.

Its normally not 2 years before release for consumer cards.

It took 2 years when all stars were in a perfect position to support RT. You can't expect quicker implementation next time something similar will come out.

Think your ultrahigh end Nvidia gpu you know the 2 thousand dollar+ cards these even under Windows come with buggy drivers for at least 12 months from release.

And you are lying again. When vendor supports linux you can play portal rtx at day0. And I don't want to loose that kind of support because of some morons' wishes. Morons who don't have a nvidia card and who want to cripple other people experience.

AMD and Intel normally gives the specifications to community at least 12 months before into Linux kernel 3 to 6 months before. This would be more than enough with Nvidia hardware.

And still AMD has given RDNA2 specifications 2 years later then it should to support linux users as first class citizens. It is maybe ok for you but not for me.

AMD and Intel does not make the Ultrahigh end. So you could argue that AMD/Intel need to release their specifications and documentation a little sooner. Yes Nvidia releasing specifications when AMD and Intel does now on GPU would be good enough. Yes 12 months before first product of a line release. For silicon mass production your silicon order has to be in with the fab 18 months before. 2 years is not really common sense thinking up until 18 months before release of cards the silicon design could be changed. But after the design is sent to fab to production keep it secret has limited advantage and has disadvantage.


Also please think for one min if GPU vendors don't give out the specifications of their cards early how can software be ready at release to take advantage of what the card is going to offer users. So it harmful to end users GPU vendors hiding what they are going to release.

12 months before product release is a reasonable time frame to expect GPU/CPU vendors to release specifications. This would get rid of many of the so called leaks about upcoming AMD and Intel cards by what people find in the Linux kernel.(yes by time media sites find this happens to be over 9 months old from what mesa side knew about).

I'm glad you have your pink fantasies about how business should work, but in real world this will never happen.. Neither AMD nor Intel will ever publish their specs so long before release, just not to give competitors space for price maneuver. Nvidia, being unchallenged technology leader, spending billions on R&D just to be a couple of years ahead, especially won't publish any know-hows of their upcoming products. So no, the only thing opensource driver could offer you is a fate of permanent beggar, asking "when will we get features we've paid for".

[Khrundel]

What a troll. My bad to have initially taken you seriously.

I am a troll because I've pointed you how in reality opensource driver development works? Mkay.

[oiaohm]

You've already caught lying about nvidia publishing hardware specs and nvidia trying to opensource its drivers and now you expecting anybody will take your word for this? No, they will never waste money to give you your beloved opensource driver.

God darn blocked post due to too may links..

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

https://nvidia.github.io/open-gpu-doc/manuals/turing/tu104/

The Nvidia open-gpu-doc is being added to and not by the same problem. We have the same problem here as we had with AMD early on in the open sourcing process.

So here was not caught lieing. Instead you were caught being incompetent but the incompetence shows how Nvidia documentation releases are a mess at this stage..

LOL. Nvidia can sign its drivers itself.

Remember you wrote this. This is a lie because this does not work under the new requirements of secureboot..

https://learn.microsoft.com/en-us/wi...sta-and-later-
Starting with Windows 10, version 1607, Windows will not load any new kernel-mode drivers which are not signed by the Dev Portal. To get your driver signed, first Register for the Windows Hardware Dev Center program. Note that an EV code signing certificate is required to establish a dashboard account.

The rules are for secureboot since Windows 10 version 1607 is the following
1) Must kernel driver be signed by the OS vendor.
2) Must be audited by the OS vendor by some amount against defects. Method chosen is up to the OS vendor.
If not OS vendor risk their secureboot key being revoked.

Yes Windows drivers since Windows 10 version 1607 are signed with two certificates not one. Yes Nvidia signing their driver with their own key with Windows 10 version 1607 and latter equals Nvidia driver not loading at all because the driver is not signed with a OS vendor key.

This is not a Linux only problem. Rules of secureboot do change things. Yes to come into align with these new rules Nvidia kernel mode driver for Linux has to be open source and why Nvidia is working on open sourcing their driver. Linux distributions only sign software they build. The build process has the compiler audit the code/driver to some extent so meeting the secure boot requirement. Yes parties like Redhat and debian don't want to sign the driver if they don't get the source code.

Audit code does not equal perfect or that a human has to do it.

The future for kernel mode drivers on Linux is open source. Yes this is why Nvidia is moving their trade secrets into the GSP/firmware that runs on their card.

[oiaohm]

You can try to shape reality in a way to conform your theories, but real reason Valve do not touch nouveau is because nobody need it when there is a vendor supported blob.

https://www.gamingonlinux.com/2022/0...os-steam-deck/
First you need to note who Valve pays todo low level linux driver work that Collabora

https://www.phoronix.com/news/Mesa-NVK-Vulkan-Merged

Then you note Collabora is working on nouveau and this starts in 2020 with GSP firmware access confirm. Valve does touch nouveau like it or not.

Also you need to remember Valve funds directly the development of zink due to opengl issues from vendor drivers. That right all vendor drivers all platforms have issues that bad that is worth Valve funding development of a wrapper.

It took 2 years when all stars were in a perfect position to support RT. You can't expect quicker implementation next time something similar will come out.

That a presume. Intel got their working RT support out in Mesa 22.3 2022-11-30 and the working Nvidia raytracing support is 510.60.02 2022.3.22

Yes the Intel the hardware was released 2022 3 30. So when all stars align somewhat 7 months for a new feature to be implemented.

The 2 years on AMD hardware you have to remember early AMD closed source raytracing support was also unstable on windows. Yes AMD did had over the specifications to implement hardware ray tracing but then you hit a problem. AMD submits raytrace code to mesa3d development branch and it gets rejected guess why automated tools said code was defective. Turned out AMD had goofed up their ray tracing implementation at a hardware level. So the ray trace example of 2 years is when the stars don't line up.

And still AMD has given RDNA2 specifications 2 years later then it should to support linux users as first class citizens. It is maybe ok for you but not for me..

This has you ignoring that the AMD experience with ray tracing on Windows with their closed source drivers was also bad for that complete time. Segment faults and other memory management faults. The faults that the mesa3d development branch rejected their code for.

Maybe AMD should let their code be peer reviewed before they ship hardware to anyone. Guess what AMD after the RDNA2 mess with the closed source driver on windows being broken and the mesa3d refusing code because the code was broken AMD came around that this would be a good idea.

RDNA2 mess turned out not only to be a problem for Linux users. Windows users was also caught up in it. Linux kernels got drivers for RDNA2 that did not cause the OS to kernel panic. Yes the RDNA2 drivers for Windows managed to cause red screens of death yes the Windows 10 and newer kernel panics while trying to play ray tracing games.

Sometimes keep stuff hidden means you don't have your code reviewed enough so you end up harming your customers.

Neither AMD nor Intel will ever publish their specs so long before release, just not to give competitors space for price maneuver.

Except no matter how you argue this is not true.

AMD has started doing modular design lot like Intel. The advantage of the more modular method is that you can release the code to all the parts on the card but not release what the cards going to consumer mix of those parts will be. Spec on the card tells the driver what modules in the driver should be enabled.

AMD and Intel publish quite a lot of specifications over 12 months before their GPU/CPU release. Yes RDNA3 is start to move to module design driver so they can release more specification earlier.

Seeing the feature list in the highest end version before release does not really help competitor because 99.999% of sales will not be this. 1 in 100000 sales at best is the highest end card.

Publishing the specifications required for driver development can be just the highest end card with every feature. Competition is still left guessing what mix the lower end cards that people really buy will be. In fact it can cause your competition on over spec their low end cards.

There is a balance between how much GPU card specification should be hidden before product release and how much should be released in advance to make sure you design is not goofed up. When you get this wrong you end up at worse with the likes of RDNA2 goof up where every user has issues of some form.

Some specifications for driver development is really good to release 2 years before hardware release to have a peer review to make sure that the GPU feature coming out will not be not usable junk before you press the silicon. There are a lot of features in Nvidia and AMD gpus that have been put in the silicon that are not usable junk and have had to be disabled for the complete life of the card due to some minor mistake.

Cost growing cost of silicon fab production these days means these minor mistakes could become company breaking. Yes the balance point of what is value for a GPU company to keep secret and remain in business has moved and will keep on moving as cost of production increases. I can see a point were GPU vendors start reselling GPUs before they are produced in the fab because the cost of fab space is so high they cannot afford the mistake of making a card with a broken feature that they have not presold. Yes preselling will require releasing more feature information sooner.

[tabicat]

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

It's also now merged into the upstream linux-firmware repo: https://git.kernel.org/pub/scm/linux...-firmware.git/

[Khrundel]

God darn blocked post due to too may links..


The Nvidia open-gpu-doc is being added to and not by the same problem. We have the same problem here as we had with AMD early on in the open sourcing process.

So here was not caught lieing. Instead you were caught being incompetent but the incompetence shows how Nvidia documentation releases are a mess at this stage..

Ye, sure. Some moron at nvidia didn't noticed he forgot to add files to a directory and nobody told nvidia about this fuckup for 5 years.
Or, maybe, nvidia had published exactly what they wanted, an interrupt table to make easier to implement some basic support, and opening low level docs about their CUDA cores, tensor cores, scheduling, RT cores etc was not in their plan.

Remember you wrote this. This is a lie because this does not work under the new requirements of secureboot..


The rules are for secureboot since Windows 10 version 1607 is the following
1) Must kernel driver be signed by the OS vendor.
2) Must be audited by the OS vendor by some amount against defects. Method chosen is up to the OS vendor.
If not OS vendor risk their secureboot key being revoked.

So you suggest any chinese laptop manufacturer who builds with nvidia gpu should audit nvidia driver? Looks like you do not understand what you're talking about.

https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-secure-boot

UEFI checks signatures of UEFI drivers, EFI apps and OS and then just loads OS loader. Signatures only. I mean who would assume MS suggests OEM builders to audit windows source code? And if they do not audit windows kernel why they should audit videocard driver? And I doubt nvidia ships UEFI drivers, generic SVGA is enough to display UEFI UI.
The only purpose of secure boot is to ensure nobody have messed with OS loader and nobody have installed a hypervisor.

Yes Windows drivers since Windows 10 version 1607 are signed with two certificates not one. Yes Nvidia signing their driver with their own key with Windows 10 version 1607 and latter equals Nvidia driver not loading at all because the driver is not signed with a OS vendor key.

Strictly speaking that is not secure boot. Driver signing requirement was added decades ago and now they've just changed some policies. And it nothing to do with Linux, from linux perspective secure boot is about having signed GRUB. And GRUB should not install a hypervisor when running windows or their key will be revoked.

This is not a Linux only problem. Rules of secureboot do change things. Yes to come into align with these new rules Nvidia kernel mode driver for Linux has to be open source and why Nvidia is working on open sourcing their driver. Linux distributions only sign software they build. The build process has the compiler audit the code/driver to some extent so meeting the secure boot requirement. Yes parties like Redhat and debian don't want to sign the driver if they don't get the source code.

OK, lets assume all this is not another bullshit, how you suggest all these works? UEFI secureboot checks signature of nvidia blob? Like parses your new fancy bcachefs partition finds a directory with kernel modules and checks their signatures? LOL
No, that does not work like this. Linux is not using secure boot. Can it implement in some future? Yes, but this will require to change everything. You won't be able to compile your own kernel. DKSM will not work anymore. The only thing which won't be harmed is... nvidia blob. Nvidia will just sign its blob drivers and all formal requirements of secure boot will be filled.

The future for kernel mode drivers on Linux is open source.

bullshit. At least while Linus is alive.
And would that changed, nvidia will just make another "GPL condom".

Yes this is why Nvidia is moving their trade secrets into the GSP/firmware that runs on their card.

No, nvidia do not change their products to please possible future of 1% of its customers. GSP was added to have realtime control over videocard, not to be depended on OS functioning well.

[tabicat]

GSP was added to have realtime control over videocard

Really?

[Khrundel]

...
First you need to note who Valve pays todo low level linux driver work that Collabora
...

Then you note Collabora is working on nouveau and this starts in 2020 with GSP firmware access confirm. Valve does touch nouveau like it or not.

And where are crab people on your chart? You can't expose conspiracy while you not found crab people.

Collabora works on several projects and only thing you can be sure is they did not work on nouveau drivers for steamdeck. Guess why

Also you need to remember Valve funds directly the development of zink due to opengl issues from vendor drivers. That right all vendor drivers all platforms have issues that bad that is worth Valve funding development of a wrapper.

Nice guess. So, I was right, Valve do not develop or fund nouveau. And will not while nvidia supports linux itself.

That a presume. Intel got their working RT support out in Mesa 22.3 2022-11-30 and the working Nvidia raytracing support is 510.60.02 2022.3.22

So Michael was hallucinating when he had benchmarked amdgpu/nvidia RT in august 2021? Or it was there, but "not working"?

Yes the Intel the hardware was released 2022 3 30. So when all stars align somewhat 7 months for a new feature to be implemented.

The 2 years on AMD hardware you have to remember early AMD closed source raytracing support was also unstable on windows. Yes AMD did had over the specifications to implement hardware ray tracing but then you hit a problem. AMD submits raytrace code to mesa3d development branch and it gets rejected guess why automated tools said code was defective. Turned out AMD had goofed up their ray tracing implementation at a hardware level. So the ray trace example of 2 years is when the stars don't line up.

This is funny when you stretch history. I doubt intel had anything working in so short time, remembering news about their driver catastrophe on windows.
But OK, lets take your words for this. This mean Intel did some in home development for unknown period of time and released implementation 7 month after cards hit shelves. Pretty long for me. And AMD fucked up and their code was garbage, so RADV team had to implement from the scratch and it took 2 years.
And how all these is a pro FOSS-driver argument? You still have to wait 2 years before you will get feature you've paid for. And no, in home development is not an option: in your fantasies you've suggested nvidia will drop linux support and ibm/redhad (and now collabora) will develop nouveau. So, they will get hardware and specs not long before videocard release.

Maybe AMD should let their code be peer reviewed before they ship hardware to anyone.

Yep, you starting to understand what trade secrets mean.
Unfortunately AMD almost dropped their linux support with all this "lets opensource driver, some guys living at parent's home basement will do our work for us and we will save money" bullshit. That looked like a great Idea in 2006. Now they have to develop 2 drivers and both of them has great disadvantages.

RDNA2 mess turned out not only to be a problem for Linux users. Windows users was also caught up in it. Linux kernels got drivers for RDNA2 that did not cause the OS to kernel panic. Yes the RDNA2 drivers for Windows managed to cause red screens of death yes the Windows 10 and newer kernel panics while trying to play ray tracing games.

Another fantasies from you. If AMD fucked up with linux lets assume it fucked up everywhere.

Sometimes keep stuff hidden means you don't have your code reviewed enough so you end up harming your customers.

Or you can just do your job yourself without expecting somebody else will do it for you. Imagine a world where instead of radv there is always fresh and high-performant amdgpu pro driver. In this world amd linux customers do not have to wait 2 years or switch drivers between amdgpupro and radv.

AMD and Intel publish quite a lot of specifications over 12 months before their GPU/CPU release. Yes RDNA3 is start to move to module design driver so they can release more specification earlier.

RDNA3 is just another CGN gpu. It is 10 years old architecture, that is why you do not notice driver development lag.

Seeing the feature list in the highest end version before release does not really help competitor because 99.999% of sales will not be this. 1 in 100000 sales at best is the highest end card.

4090 sales beats most more cheaper 40th series cards. Yes, this is special case when there are plenty pastgen cards on market, but still, not 1 in 100000 and even not 1 in 100. With pastgen 1 3090 to 20 3060.

Publishing the specifications required for driver development can be just the highest end card with every feature. Competition is still left guessing what mix the lower end cards that people really buy will be. In fact it can cause your competition on over spec their low end cards.

fortunately nobody will listen to you so we will have good support for linux. Let wayland geeks play with their 2 generation past videocards while we, gamers will play.

There is a balance between how much GPU card specification should be hidden before product release and how much should be released in advance to make sure you design is not goofed up. When you get this wrong you end up at worse with the likes of RDNA2 goof up where every user has issues of some form.

When you are a technology leader you want to hide exactly same features of your hardware which will give your product an upper hand. For example look at ada lovelace. One of its new features is a transparency map which allow to skip many shaders execution when determining if ray is obscured by texture. It is a very simple solution, I assume AMD could add it to RX7*00 series would they knew about it an year before release. And nvk driver developers should've know about it to predict overall performance.
What do you think, does nvidia want to give competitors such advantage?

So no, your fantasies will remain fantasies. And if some time later Linux marketshare will become bigger and AMD will start to take it more seriously and overall GPU innovation also, I expect them to shift toward closed source drivers development, leaving radv for obsolete hardware.

Opensource driver development for bleeding edge products is a one of the dumbest idea ever invented. Honestly, I was expecting everyone will understand this after I've pointed to radv RT situation. I mean how masochistic you should be to allow Stallman's dellusions to deprive your of most features of your new expensive videocard you've paid for? But looks like I've underestimated foss zealotry. "Maybe not 2 years but an year and a half" is enough argument for you.

[oiaohm]

Ye, sure. Some moron at nvidia didn't noticed he forgot to add files to a directory and nobody told nvidia about this fuckup for 5 years.
Or, maybe, nvidia had published exactly what they wanted, an interrupt table to make easier to implement some basic support, and opening low level docs about their CUDA cores, tensor cores, scheduling, RT cores etc was not in their plan.

No 5 years ago they published something very early on in the legal review of documents. The manual folder is a latter release. If you look closely it everything that you had found in the first folder then more.

AMD early documentation releases were the same. Status normal Nvidia starts doing documentation serousally in 2019 with more and more detail releases following as those documents go through internal review to make sure they don't release anything that could get them into trouble with non disclosure agreements with third parties.

So you suggest any chinese laptop manufacturer who builds with nvidia gpu should audit nvidia driver? Looks like you do not understand what you're talking about.
ll.

I was clear OS vendor not chinese laptop vendor..

And it nothing to do with Linux, from linux perspective secure boot is about having signed GRUB. And GRUB should not install a hypervisor when running windows or their key will be revoked.

Why that is the case is because the key that grub is signed with is key issue by Microsoft for third party OS bootloaders Its not the chinese laptop maker who revokes this key. The party setting the rules on what you have todo when you use this key to sign your bootloader for your OS is Microsoft. If you don't like it have your customers change the secure boot keys in their device.

You do not understand what you are talking about.

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.

Microsoft puts a list of requirements on anyone who uses the third party OS CA they provide. That includes what I sated before that not compatible with Nvidia closed source kernel space driver.

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.

Collabora works on several projects and only thing you can be sure is they did not work on nouveau drivers for steamdeck. Guess why

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.

So Michael was hallucinating when he had benchmarked amdgpu/nvidia RT in august 2021? Or it was there, but "not working"?

Go back and read that.

Thus for now that leases the AMD Radeon Vulkan packaged (closed-source) driver on Linux

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.

Imagine a world where instead of radv there is always fresh and high-performant amdgpu pro driver. In this world amd linux customers do not have to wait 2 years or switch drivers between amdgpupro and radv.

Why people end up changing to radv is higher test suite conformance. Lets just think we are in a world where Nvidia stop getting in the way of third party driver development. Now we used to have the same thing happen with nouveau when where you would have lower performance but high pass on the conformance testsuite when Nvidia was not being pain with firmware.

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

One of its new features is a transparency map which allow to skip many shaders execution when determining if ray is obscured by texture.

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 assume AMD could add it to RX7*00 series would they knew about it an year before release.

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.

This is the thing a lot of the new features in GPU are not new features instead combinations of old existing features sometimes given new names.