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

[avis]

oiaohm

" The reality here Nvida has not had stability on Linux not at the same level as AMD."

"Nvida", right.

Now you're lying and I'm done discussing anything ever with you. Unlike you I frequent the kernel bug tracker and AMD's dri freedesktop bug tracker. The public evidence strongly shows that AMD GPUs have multiple stability issues right now in 6.5.11 and 6.6.1. I'm not going to post all the bug reports.

Since you're a huge fan of anecdotal evidence which instantly invalidates everything you say how about my evidence? Not third party you're so fond of because you don't even own an Nvidia GPU. Slamming the company in this case is outright despicable and insincere.

Gamma by default is broken for my 780m, a bug has now been known for over four months, nothing has been done to attempt to fix it. This is brand new rdna3 which must be top priority for AMD.

Open Source AMD drivers are choke full of known unresolved issues, some known for months if not years.

Again, I'm not continuing the discussion with the person who doesn't own an Nvidia GPU but who uses anecdotal evidence, hearsay, forum posts to prove his POV while very conveniently leaving aside all the bugs that AMD and Intel GPU drivers have.

"Note how you said vast majority of W11 drivers work on W10 not all. "

Out of 30+ drivers that my AMD laptop needs on Windows 10, none are windows 10 or 11 specific. W11 needs one driver less to install because w10 doesn't support usb4 out of the box. That's it. The rest of your insinuations are not confirmed by hard reality.

Please find more gullible people to preach to.

[oiaohm]

https://gitlab.freedesktop.org/drm/amd/-/issues/2706"

What the bug. There is a problem here this is not a bug from what I am reading. From what I am reading it just a user who is not willing to configure his system.

https://gitlab.freedesktop.org/drm/amd/-/issues/1513

Read bug you were referenced to. LUT size is meant to be 4096

At gamma value 0.8 I get what I am getting under Windows. I wonder what causes this and if this can be fixed.

<< So what wrong with having to set 0.8 gamma the answer is nothing in fact. Some monitors are out of specification so need gamma set to 0.8 to render correctly.

Not everyone with a Radeon 780M is complaining about this problem.

Gamma issues are not unique to AMD either.
https://bbs.archlinux.org/viewtopic.php?id=263668 notice this is Nvidia user running into exactly the same problem of having to adjust gamma so monitor looks right.

Windows you will find a lot of times gets display gamma information and sets default gamma so windows could be set

Yes setting 0.8 gamma is required with some monitors with Nvidia as well. Quite fun when it the built in laptop LCD screen that buggy this way.

Do check if you have a inf for your monitor installed under windows. You find a lot of Windows installed laptops come with a inf that sets built in monitor to 0.8 gamma and if you clean install the laptop you get washed out as well because you normally miss installing the laptop monitor inf. Yes installing Linux on a laptop not built for Linux you have to deal with these things.

Open Source AMD drivers are choke full of known unresolved issues, some known for months if not years.

So does Nvidia by the way. Nvidia forums make them a lot harder to track and locate. But there is also a lot of bugs in the open source bug list that AMD driver triage looks at and goes not a bug and moves on to something that is a bug and don't bother posting anything just in case they have miss read it.

There are some issues that are universal between AMD/Intel/Nvidia. The wrong gamma for the monitor is a universal.

Basically your bug is example of some of the junk bugs filling up the open source bug lists . Person does not understand that the issue they are complaining about is something functioning perfectly correctly.

The public evidence strongly shows that AMD GPUs have multiple stability issues right now in 6.5.11 and 6.6.1. I'm not going to post all the bug reports.

With the quality of the bug you just used to attempt to prove you point most likely no where near as strong as what you think. There is a common set of issues Nvidia, Intel and AMD users all report that are not driver bug but simple system configuration errors. Wrong gamma is one of these common issues.

By the way the 0.8 gamma correction is a common thing because its the amount of correction you need to take a P3 rated LCD/oled panel to look roughly like a srgb pannel. P3 color space is meant to look washed out compared to srgb. Please note I said roughly because if you do a color calibration test this correction has srgb still not displayed dark enough in places because P3 panel cannot do particular dark colors.

P3 panel is cheaper than a proper srgb or rec2020 panels. The new steam deck oled is a proper rec2020 HDR panel. Lot of monitors next to steam deck oled look like garbage..

[Rovano]

https://store.steampowered.com/hwsurvey/Steam-Hardware-Software-Survey-Welcome-to-Steam

We simply do not discuss, but we play. It just works.

[Sonadow]

This means you just want to stick you head in sand and ignore the user delivery problem. I did not say blame Nvidia. This is more you have to look method AMD and Nvidia is using on Linux and what one is being more successful at getting newest drivers delivered to users. AMD method on Linux like it or not is more successful than the Nvidia one.

Only a complete mental r3t@rD actually believes putting driver updates in Mesa and the kernel means getting new stuff out faster to users.

Who the hell compiles their own Mesa and kernel every few months? Most Linux users don't even know how to build a Hello World, let alone compile anything more complicated than one, yet they go around bragging that they know more about computing and computers just because they use Linux. Here's news for you; the average Windows user definitely knows a hell lot more about his computer and OS and keeps quiet about it than a Linux user self-proclaiming his tech savviness.

Again ignoring the delivery problem and the requirements at play. Lets say I wanted to release a new W10 driver today. Yes a pure W10 driver. I log into the Microsoft portal for signing drivers and attempt sign pure Windows 10 driver guess what rejected no sign for you. To sign a driver W11 driver ABI features have to be there is the error message. I want to release a pure W11 driver with no W10 compatibility parts log into the portal and attempt to sign it guess what again driver reject backwards compatible W10 ABI has to be there or you are not signing driver message now. Yes this is case you have to-do what Microsoft wants or you driver is not signed.

Note how you said vast majority of W11 drivers work on W10 not all. By the requirements to get driver signed in theory all W11 drivers should work on W10 but why don't they. That right the Windows 10 kernel can have been updated since the time W11 driver was signed so changing the ABI slightly so breaking the driver. Also you have a Windows 11 driver signed new Windows 11 kernel releases and the driver does not work correctly any more same issue slight ABI changes causing breakage.

This is another point you need to pull head out sand. Microsoft releases a new Window kernel. You have old Windows drivers manually installed MS Windows breaks. What is written stable api nonsense document effects Microsoft as well. New kernel releases bring nasty regressions because drivers have not been properly updates is a Windows, Linux, Mac OS ... problem.

Somehow to reduce this problem you have to lock driver version and kernel version with each other. What is written in the Linux kernel called stable-api-nonsense.rst is a stack of technical problems that you run into when you attempt to make a stable kernel ABI/API and use a monolithic kernel base this includes windows nt hybrid design. Microkernels that run there drivers in user-space don't have this problem but there is a performance cost to this. Microsoft Windows is effected by the issues listed in stable api nonsense and it very simple to find examples of proven it.

More whataboutism. And you can't even argue consistently, because you have no intelligence outside of making up stories and what-ifs. You can't even write consistently. Go back to playschool and learn how to form a sentence.

Real people are out there using drivers from the Windows Vista, Windows 7 and Windows 8-eras in Windows 11 and hardly even noticing how old they are. Because stable driver ABI proves itself.

[avis]

oiaohm

Tell me in all honesty what Xorg server settings can affect gamma? Because I see/have absolutely nothing. And here's my config file:

Section "Device"
    Identifier "Radeon 780M"
    Driver "amdgpu"
    Option "TearFree" "true"
    Option "VariableRefresh" "true"
EndSection

Yeah, by using it I absolutely change/configure/break some "LUT"s I've no fucking clue what they are. And, yes, I'm now using gammastep to reduce gamma to 0.8 on login because otherwise I get completely washed out colors. Other poor folks using HP's business laptops with 780m with Linux have no idea they get shit output by default.

So, again, you continue to bash NVIDIA for no fucking reasons while AMD cannot even properly make their display driver, you know, display output! Tell me more about "stability", LMAO.

And also, here's what Michael has to say about NVIDIA drivers: "NVIDIA's proprietary driver stack is terrific if you don't care about software licenses and just want all of the features and performance right now, but for those pursuing open-source drivers are better off with AMD Radeon or Intel Arc Graphics for now until the NVK/Nouveau support advances enough for end-users."

Looks like you're the only NVIDIA hater here because the actual haters here on Phoronix forums and even Reddit actually admit that NVIDIA proprietary drivers are excellent.

[avis]

Gamma issues are not unique to AMD either.
https://bbs.archlinux.org/viewtopic.php?id=263668 notice this is Nvidia user running into exactly the same problem of having to adjust gamma so monitor looks right.

Can you 1) read 2) stop making stuff up?

From the linked issue: "I just got a new monitor (which I use w/ my laptop) and it's default gamma is too high." The guy's monitor is factory configured incorrectly (or not to his taste). The issue has zero to do with NVIDIA. My laptop monitor output in Windows 10/11 is correct, I don't use any gamma applications in it. In Linux I have to apply 0.8 gamma correction. And 0.8 is huge. Try to apply 1.2 gamma on your Linux and see how "fine" it all becomes.

I'm tired of your lies, oiaohm. I don't know whether AMD or Intel pays you, but unlike you I've never dismissed serious issues with NVIDIA. See the next message in the thread.

[avis]

Over the past couple of years:

• They broke display refresh on Turing which took them over 4 months to fix: https://github.com/NVIDIA/open-gpu-k...les/issues/511
• It took them over three (!) years to fix I2C/DDC: https://forums.developer.nvidia.com/...play-ddc/63901
• They continue not to add RAM modules temperature monitoring citing "reasons": https://forums.developer.nvidia.com/...vml-api/168346
• You can check this and this fore more nagging issues: https://forums.developer.nvidia.com/...se&order=views https://github.com/NVIDIA/open-gpu-k...Acomments-desc

But please don't bullsh$t everyone here with AMD and Intel open source drivers "are more stable". That's a lie.

[avis]

Speaking of my monitor and how it's "incorrectly" calibrated and sh$t.

Check the review: "The panel is already very well calibrated in its delivery state. Our analysis with professional CalMAN software (X-Rite i1 Pro 2) reveals that the grayscale display is already on the reference level and no color cast is visible. In terms of colors, only blue is above the important deviation of 3, which are unable to correct via our own calibration. The P3 color space is fully covered, but there is no option to switch the color space to sRGB."

[oiaohm]

My laptop monitor output in Windows 10/11 is correct, I don't use any gamma applications in it. In Linux I have to apply 0.8 gamma correction. And 0.8 is huge. Try to apply 1.2 gamma on your Linux and see how "fine" it all becomes.

You have presumed windows has not already applied calibration https://www.makeuseof.com/windows-10-11-change-gamma/ You don't need to use third party gamma tools you only have to install a inf file that has set windows internal gamma corrections. Even more fun windows can automatically down these inf files windows checks for updates as well. Yes HP laptops installing windows

Speaking of my monitor and how it's "incorrectly" calibrated and sh$t.

Check the review: "The panel is already very well calibrated in its delivery state. Our analysis with professional CalMAN software (X-Rite i1 Pro 2) reveals that the grayscale display is already on the reference level and no color cast is visible. In terms of colors, only blue is above the important deviation of 3, which are unable to correct via our own calibration. The P3 color space is fully covered, but there is no option to switch the color space to sRGB."

Yes read this text again taking careful note of what I have put in bold avis. No option to switch to sRGB color space is because you have a P3 panel and the panel does not have a sRGB mode. Linux applications coloring is normally srgb so you have a problem. You need 0.8 gamma correction to get a P3 panel somewhat close to sRGB..

This laptop does not have a style of panel you will find from any decanted maker of Linux laptops. The difference is to have a sRGB mode and not in the pannel is mind numbing 10 cents USD per unit. Not worth the customer complaints.

Set the gamma value in x.org configuration exactly the same as you set it with Nvidia there is no difference here. Yes xrandr --gamma and x11 configure Gamma value. Or set the gamma value into the linux KMS by some KMS tool.

Your problem is not in fact the AMD GPU. It the panel it paired with and Linux distributions don't auto-configure the LUTs or gamma to correct this.

https://hub.displaycal.net/forums/topic/graphic-cards-lut-bit-depth/

LUT size information is for your color correction tools for the likes of applying icc profiles. Yes have LUT size values return of 0 from amdgpu is a reason why xrandr --gamma option will not work at all because of a broken amdgpu driver if those are displaying 4096 you don't have the Linux kernel with that broken driver.

Yes the difference between P3 and srgb is huge.

avis like or not that bug is a case nothing is in fact broken on the AMD side from what in the bug report. Yes what you have provided me confirms it another P3 panel issue and the user not finding way to set color correction.

P3 panel + amd/Intel/Nvidia all equal highly washed out under Linux without applying color correction of some form be it gamma or icc profile.

avis all that happened is the laptop monitor with Linux loaded with nothing adjusted just got send a pure srgb signal with washed out colors as the result because its a P3 panel. This is not a AMD unique issue. HP makes Nvidia GPU laptops with the same problem when you load Linux as well avis.

[oiaohm]

Who the hell compiles their own Mesa and kernel every few months? Most Linux users don't even know how to build a Hello World, let alone compile anything more complicated than one, yet they go around bragging that they know more about computing and computers just because they use Linux. Here's news for you; the average Windows user definitely knows a hell lot more about his computer and OS and keeps quiet about it than a Linux user self-proclaiming his tech savviness.

Yes what you wrote is right that Linux users normally don't build their own Mesa or Kernel instead use the Distribution provided kernel/mesa.. Linux Distributions push out kernel updates about once every

https://www.kernel.org/

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.

Real people are out there using drivers from the Windows Vista, Windows 7 and Windows 8-eras in Windows 11 and hardly even noticing how old they are. Because stable driver ABI proves itself.

https://support.microsoft.com/en-us/windows/devices-not-working-after-a-major-windows-update-a15667e6-baa1-4437-80aa-a77f08b3aaff

Windows Major update are kernel updates. At these kernel updates even Microsoft documentation tells you drivers break. Users don't notice many problems because Windows update in fact updates most drivers.

I like how you wrote hardly noticing. Users normally don't notice when Windows update rips out a old driver and replaces it with a new one. Lot of people think they are running old Windows vista/Windows 7 and Windows 8 drivers in Windows 11 but when you go in and check the driver history you find out almost insanity windows update replaced the driver with a newer windows 11/10 version. Yes having to submit drivers to Microsoft for signing with Windows 10 means Microsoft has all current copies of drivers for Windows update to push out.

People who in fact check what Windows is doing don't go around saying Stable ABI is why windows drivers works.

Windows 10 Microsoft really switched over to very close to a bundled with kernel driver model.

Windows Major update being kernel updates is between once every 12 months to once every 6 months lot slower than Linux distributions.