Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • varikonniemi
    replied
    no surprise it's nvidia that is bloating like this

    Leave a comment:


  • bridgman
    replied
    Originally posted by oiaohm View Post
    Opps sorry dyslexia or typo won that round bridgman. I have corrected post.
    No worries... at least it was clear what you meant. I have been playing with hands-free speech-to-text IM'ing in the car... it's remarkable how many different ways there are to interpret the spoken word.

    The infuriating part is that the first text to appear is often correct, then after a few seconds of further reflection the text gets updated to something totally different.
    Last edited by bridgman; 26 November 2023, 01:30 PM.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by avis View Post
    NVIDIA having out of tree modules can release fixes whenever they want/can/must.
    Is this true since mandatory signing by Microsoft portal with Windows 10 and newer the answer is no.

    Originally posted by avis View Post
    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?
    This is the thing


    All hardware submissions to the dashboard will be processed within 5 business days or less, depending on whether the submission requires manual review. Manual review may be required if your submission's tests fail, if it doesn't have a valid filter applied, or due to an internal business policy.
    There is a very big dark side to this text. Your submission's tests fail. Guess what the tests used by the Microsoft portal are not publicly published.

    Yes the Microsoft worst case for being signed is 5 days and that is also the worst case to find out that Microsoft has added some test and opps your updated driver is no longer good enough. This has been the cause of a few cases of the Linux Nvidia driver being out before the windows driver by up to 30 days.

    Yes the 5 days on the manual review + the coding to fix the issue why driver end up in manual review and resubmit there is 30 days gone. Please also note that 5 business days. So you submit Friday you might only find out it failed next Friday. Might as well be real here 5 business days is basically 7 days written in way that sounds a little better..

    Yes submitting to the dashboard with Microsoft to get signed also puts your driver in the que.

    Greg KH delay on LTS branchs like it or not in the ball park of the delays you end up having with windows signing drivers. Of course as a person submitting drivers you do have the advantage with Linux of having the test suite Greg KH is going to use so not end up with the problem of darn the tester updated the test suite so wasting my time.

    Processing time with Greg KH like it or not is in the ballpark of the processing time to get Microsoft to second sign driver so you can use it with Windows 10/11.

    Would I like to see LTS release cycles be shorter yes I would but there is a upper limit.

    Yes I like the internal business policy. Lets say Microsoft processing que for new drivers gets too full(it has happened) what do you think Microsoft internal policy reads. That right reject the driver and tell the hardware vendor to resubmit the driver in a few days/weeks. Yes rejected is still processed.

    avis like it or not secure boot requirements have changes things a lot. Getting out of tree module signed by OS as required for secureboot equals like it or not hardware vendor cannot release new driver whenever they want instead they have to be on the OS makers timelines for approval.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by bridgman View Post
    Birdman ?
    Opps sorry dyslexia or typo won that round bridgman. I have corrected post.

    Its is close enough mistake to be typo the i and r out order(with the i and r being left and right hand with touch typing and fail to type the g and you end up with birdman.from bridgman.

    Leave a comment:


  • bridgman
    replied
    Birdman ?

    Leave a comment:


  • oiaohm
    replied
    Originally posted by Sonadow View Post
    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.

    Originally posted by avis View Post
    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.
    Last edited by oiaohm; 25 November 2023, 06:41 PM.

    Leave a comment:


  • avis
    replied
    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".
    Last edited by avis; 23 November 2023, 03:47 AM.

    Leave a comment:


  • Sonadow
    replied
    Originally posted by oiaohm View Post

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




    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.
    Last edited by Sonadow; 22 November 2023, 05:15 AM.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by Sonadow View Post
    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.


    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.

    Originally posted by Sonadow View Post
    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?

    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.

    Originally posted by Sonadow View Post
    ​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.

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite


    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.

    Leave a comment:


  • avis
    replied
    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.

    Leave a comment:

Working...
X