NVIDIA Pushes 62MB Of GSP Binary Firmware Blobs Into Linux-Firmware.Git

[avis]

oiaohm

Nice info, thanks, except Windows doesn't use/have any INF file for my laptop monitor, it's reported as Standard Something. I will reboot later and make a screenshot for you.

Here are all the screenshots:



-
color_management.webp

Nothing specific to my monitor is installed. No ICC profile either. Color Depth is set to 24 bit.

[oiaohm]

oiaohm

Nice info, thanks, except Windows doesn't use/have any INF file for my laptop monitor, it's reported as Standard Something. I will reboot later and make a screenshot for you.

Here are all the screenshots:

Nothing specific to my monitor is installed. No ICC profile either. Color Depth is set to 24 bit.

https://www.reddit.com/r/Windows10/comments/i52cfr/i_have_a_dci_p3_display_connected_but_i_didnt/

I had forgot a change in Windows. Windows 8 and 7 you would find the inf. Windows 10 and newer detect a p3 panel and auto apply a correction that is normally wrong that is still over saturated.

And of course windows does not tell you that you have a P3 panel.

As I said reading from setting required for a P3 panel nothing in your bug report appeared out of place.

avis the problem here this p3 panels bring out X11 limitation as well as Windows issues. Windows issues are less in face.

Yes X11 with no gamma correction throws you applications with a P3 panel straight into the P3 color space causing washed out. But if you want to display P3 content like majority of movies displays them correctly. You apply the 0.8 gamma or windows correction for p3 content you are now off.

This is why Wayland work on color space is important. P3 panels what you really do need is color space information per surface. So that output can know what is srgb and what is p3 and what is some other color space and apply the correct corrections..

Yes as you have seen throwing srgb out as p3 is really bad idea. Yes 0.8 gamma being what you need to go from srgb application image to p3 output yes it 1.2 gamma to attempt to display p3 application image on a srgb monitor.

Monitors are made with up to 4 different color profiles for 24 bit color. AdobeRGB, prophoto, P3 and srgb. Yes these are all different and these all cause your output to be wrong in different ways.

These monitor color profile things throwing your X11 desktop to hell if it anything other than srgb is generic to all graphics output on Linux. Yes does not matter if you are running AMD, Intel or Nvidia. This is why a lot of pro people are like Linux desktop has need a proper color management system yesterday because X11 color management for different applications attempt to output with different color-spaces and doing as correct as possible does not exist.

avis like it or not nothing about that bug report says that there is something wrong with the AMD driver. There are some major problems with X11 server itself that effects all GPU on Linux in this area. Yes there have been major problems with Wayland compositors as well when you have a P3 panel as well due to the same lack of color management support.

[Sonadow]

avis Are we going to continue wasting time with this mentally challenged dumbf*ck?

He can't even string a coherent argument together and keeps diverting the topic away.

First he says AMD putting the their drivers in Linux kernel + Mesa means people get driver updates faster. When pointed out what utter bullshit this is because most users don't even know how to build a new kernel or Mesa (taking into account that building a new mainline kernel is practically impossible for ARM systems because of the utter shittery that is DTB) he immediately changes the topic to something about Windows making kernel updates once a year only.

[Sonadow]

To all of those complaining that every new Nvidia driver release means new Nvidia GSP firmware blobs will be pushed;

I though stable ABI sucks? So much so that you all even point to the overused "stable_abi_nonsense" file that Linus left in the kernel? That unstable ABIs means developers have the "freedom" to break things in the name of improvement?

So why TF are you complaining? Nvidia is giving you the unstable ABI you all wanted and insisted on!

And why are you complaining that Qt6 breaks away from Qt5, or GTK4 breaks away from GTK3? Or when Python 3 breaks from Python 2 and every Perl release breaks an older one? After all, stable ABIs are all nonsense! Right?

[avis]

Sonadow

Let's not get personal? Thanks. Maybe Windows 10/11 indeed enables DCI P3 support behind the scenes (I have yet to see an official confirmation of that anywhere but I've not looked) without ever telling the user and it's possible that Wayland HDR support will tackle this.

[oiaohm]

avis Are we going to continue wasting time with this mentally challenged dumbf*ck?

He can't even string a coherent argument together and keeps diverting the topic away.

First he says AMD putting the their drivers in Linux kernel + Mesa means people get driver updates faster. When pointed out what utter bullshit this is because most users don't even know how to build a new kernel or Mesa (taking into account that building a new mainline kernel is practically impossible for ARM systems because of the utter shittery that is DTB) he immediately changes the topic to something about Windows making kernel updates once a year only.

People don't notice how often they are updating kernel under Linux. Most distributions push out a point release update to the kernel every few months with Linux.

Someone need to learn to read. I am not talking about arm customs with AMD and Nvidia GPU mostly, You are talking about x86 distributions.

Like or not there is workflow flow here you are ingoring.

You have the Linux mainline branch then the Linux LTS branches. Distributions mostly build their default kernel off the LTS branches. Mainline AMDGPU/radion drivers get backported into the LTS branch updates.

https://www.kernel.org/

mainline:	6.7-rc2	2023-11-19
stable:	6.6.2	2023-11-20
stable:	6.5.12	2023-11-20
longterm:	6.1.63	2023-11-20
longterm:	5.15.139	2023-11-20
longterm:	5.10.201	2023-11-20
longterm:	5.4.261	2023-11-20
longterm:	4.19.299	2023-11-20
longterm:	4.14.330	2023-11-20
linux-next:	next-20231122	2023-11-22

Notice here that fix patches that are going to be in 6.7 mainline release are already applied in point releases of all the longterm and stable kernels.

6.5 kernel was released 87/12

Nothing uncommon for the stable and longterm kernel in fact to be ahead of the mainline with amdgpu driver updates.

Next take 5.15 long term there are 139 versions of it. 5.15 was released 2021-10-31 that 752 days ago. 752/138 that a new release every 6 days. Stable 6.5 was released August 27 2023 there has been 12 updates that update every 7-8 days.

Yes Linux mainline is every 9 to 10 weeks.

So you are wanting to get your driver to user as fast as possible. Being part of mainline development of Linux puts you into direct contact with LTS kernel branch maintainers to get your driver back ported into those branches that the distributions base their kernels off of.

Most people don't notice that distributions are updating their Linux kernel faster than mainline linux kernel releases. Or that LTS kernel versions of Linux have newer AMD driver versions than what currently approved for mainline quite often.

Being part of mainline and next Linux development like AMD is allows AMD developers to get ahead of API/ABI changes of the kernel before the kernel comes stable then long term support versions. Nvidia closed source as regular cases of do not up date kernel because if you do our closed source driver will break most of these issues would be detected if Nvidia was in next and mainline.

Sonadow this is right installing mainline Linux kernel version may not get you newer AMD or Intel graphics driver with Linux. AMD and Intel being part of mainline Linux development gives them access to LTS maintainers to get their drivers out faster.

Reality when you serous-ally start looking at this and looking at how fast AMD and Intel kernel mode drivers with Linux are in fact getting to end users its a lot faster than most are guessing. Most incorrectly presume 9-10 week delay totally missing 5-14 days to get a fix into LTS/Stable kernels then from LTS/Stable kernels into distribution kernels that users are installing by updates. Yes 1 to 3 weeks for AMD or Intel on normally land a critical driver fix for their graphics to Linux end users who only use distribution provided kernels.

I though stable ABI sucks? So much so that you all even point to the overused "stable_abi_nonsense" file that Linus left in the kernel? That unstable ABIs means developers have the "freedom" to break things in the name of improvement?

https://www.kernel.org/doc/Documentation/process/stable-api-nonsense.rst

Pays to read the notes. Particular the next bit.

Please realize that this article describes the **in kernel** interfaces, not
the kernel to userspace interfaces.

Its a list of technical problems you run into when you have everything in the same memory space.

So why TF are you complaining? Nvidia is giving you the unstable ABI you all wanted and insisted on!

Firmware API/ABI is not in kernel interfaces they are like kernel to userspace interfaces from Linux kernel developer point of view. Intel found this out recently.

https://www.phoronix.com/news/Linux-6.1-Intel-GPU-FW-MTL-More

Lets take the Intel issue that was being addressed in Linux 6.1. Intel decided to break GPU firmware ABI compatibility where newer kernel could not use older firmware there is one problem for intel the new firmware did not fire up all the Intel hardware that the old GPU firmware could.

Your GPU does not work with a new Nvidia driver. The reality the problem could be the driver or could be the include firmware. But since the Nvidia driver and firmware are API/ABI locked to each other you cannot use older firmware with newer driver or newer firmware with older driver to locate if this is firmware or driver issue.

There is a reason why you want stable firmware ABI. It the same reason you want a stable kernel to userspace ABI. The issues detailed in stable api nonsense do not apply to kernel to userspace or kernel to firmware.

Yes the rule about firmware with Linux kernel should attempt to maintain a stable firmware was formally added to Linux kernel documentation back in 6.1 as well. Please note its not a absolute mandate but absolute mandate is new driver should be able to use old firmware is mandate.

There are many examples of newer vendor made firmware not working with older bits of hardware. Hardware compatibility for end users with the most up to date software possible is why Linux kernel developers end up wanting stable ABI from firmware to kernel or the min that new driver can load old drivers firmware as well as it own. Means to load old firmware if vendor as goofed new firmware user is not forced to load a old driver they have just wanted to replace because the driver had some secure update just because of a firmware issue.

Upset over nvidia firmware lack of ABI and lack of framework to use multi firmware is totally justified with how often old card does not work with new drivers because vendor screwed up the firmware image somehow. Yes stable firmware ABI or stable solution to use multi firmware versions either has the Linux kernel developers somewhat happy. The Linux kernel developers don't exactly mandate stable ABI from firmware but they do mandate more than what Nvidia currently doing.

[Sonadow]

. Mainline AMDGPU/radion drivers get backported into the LTS branch updates.

https://www.kernel.org/

Notice here that fix patches that are going to be in 6.7 mainline release are already applied in point releases of all the longterm and stable kernels.

6.5 kernel was released 87/12

Nothing uncommon for the stable and longterm kernel in fact to be ahead of the mainline with amdgpu driver updates.

No they do not. If that were the case 4.14 will have support for Navi cards and Intel Raptor Lake.

Your stupidity and ignorance are beyond that of a mentally challenged person such that you can't even lie without writing a full essay of complete bullshit.

[avis]

I have to side with Sonadow on this.

No one backports Intel/AMD GPU drivers for older kernels, not even RedHat because they have a ton of other stuff to take care of.

GPU drivers have become insanely huge and complicated to rely on the cadence of kernel releases. The situation with them will only get worse in the future.

NVIDIA having out of tree modules can release fixes whenever they want/can/must.

With the Linux kernel you are at the mercy of people who don't give a feck about your system and how well it's functioning.

Greg KH delayed 6.6.2 by at least a week? Who cares?
Greg KH has a massive backlog of stable fixes for 6.6 yet? Who cares?

Linux is fucking perfect, oiaohm - go find 150 reasons how "it's OK".

[oiaohm]

No they do not. If that were the case 4.14 will have support for Navi cards and Intel Raptor Lake.

Another incorrect presume. There is problem hardware Enablement and driver version are in fact two different things.

No one backports Intel/AMD GPU drivers for older kernels, not even RedHat because they have a ton of other stuff to take care of.

bridgman response to you with amdpro drivers how they bundle up current AMD drivers for old kernels. So no one backports Intel and AMD GPU drivers for older kernels is false. AMD does back-port out side mainline with hardware Enablement for older LTS kernels in the amdpro driver.

So yes you can use Navi cards with a 4.14 kernel with the amdgpu driver from the amdpro driver. Lets say you have a older AMD card that was supported by the 4.14 kernel is there any advantage to installing the amdpro kernel driver the answer is more often than no because all the fixes in the AMDpro provided kernel driver for the older card most cases has been backported in the LTS updates.

Basically the AMD and Intel gpu drivers in a 4.14.1 kernel vs a 4.14.330 kernel are vastly different due to how much has been backported into that kernel so updating those drivers. This is not the only drivers like this.

The large backlog on 6.6 does show how much those LTS kernels are in fact changing. While a kernel is called stable that is currently 6.6 and 6.5 you will see some hardware enablement patches.

There is a interesting catch. What one is faster the LTS AMD backported driver or the amdpro backported kernel driver? The answer is the LTS AMD backported driver why the amdpro driver uses a wrapper to take newer kernel functions and hook them up to older kernel functions and the LTS version using Semantic patching to make the backported driver kernel API usage exactly match old kernel API so not having wrapper overhead.

This is the reality with AMD and Intel on Linux. You are on a LTS kernel the most recent version you most likely have the best driver for that kernel for AMD and Intel GPU hardware as long as the hardware was supported by that kernel in the time it was a Stable kernel.

This is why AMD users don't go around installing amdpro kernel mode drivers that much because in lots of cases you are undermining your performance. Because the current driver with cut back hardware enablement is being back-ported to the LTS branches.

AMD does release out of tree kernel drivers for their GPU on Linux. Nvidia is not the only one who does that. AMD shows a performance cost to the out of tree driver and that more often than not this is a slower way to get updated driver to end users for LTS/stable supported hardware.

This is problem the idea that latest driver version has to also have the latest hardware support is not in fact true.

Yes it would be nice of hardware enablement was auto back-ported into older LTS kernels but then you would end up in the problem where people had no reason to update at all. Yes the choice not to backport hardware enablement on LTS branches is a choice LTS maintainers have made.

avis and Sonadow you have both come in with incorrect presumes. Mainline, stable and LTS branches work in very particular ways.

[bridgman]

Birdman ?