Announcement

Collapse
No announcement yet.

Former Nouveau Lead Developer Joins NVIDIA, Continues Working On Open-Source Driver

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

  • #91
    Originally posted by oiaohm View Post

    The issues Nvidia has to over come means solution is not just around the corner. AMD when their aquired ATI had to overcome the same problems leading up to AMDGPU driver.

    arabek there is problem here. The windows driver the firmware and os driver being locked with each other is fine so no ABI here not a problem. Linux mainline drivers are just a different beast. Think about it mainline kernel is shipped out to distributions this could be 2 years old effectively and a user is attempting to use a new card how are you going to make this work. AMD and Intel have a solution the firmware and fireware ABI. Where is Nvidia right now with this problem.

    Not using mainline driver allows keeping the windows behavior of firmware and driver locked to each other.
    You're delusional. NVidia already pushed all the needed firmware to initialize post GSP cards to the linux-firmware.git and it's beeing distributed the same as AMDGPU and/or Intel firmware. Again, beacuse you seem to not comprehend the whole topic: what NVidia needs to do right now is to enable running their closed source usermode libraries on the nouveau kernel driver and that's it! Granted it'll take them some time to rework the closed source user mode binaries/libraries, but thats about all the things they actually need to do. They won't have to develop their closed-source kernel driver anymore. As for new cards, it'll be the same as with any AMD or Intel cards, all the development kernel side will be in the Nouveau repo (alongside an upfront firmware push for newer models to linux-firmware.git).

    Comment


    • #92
      Originally posted by clippy View Post
      Well, I suppose this is one way to prevent him from reverse-engineering NVIDIA hardware ever again. Even if he left there tomorrow, all his future contributions would now be tainted by internal knowledge and thus legally untenable.
      You assume he doesn't know that. What if he signed an employment contract that gave him leeway if he decided to continue working on Nouveau if he left NVIDIA?

      Comment


      • #93
        Originally posted by arabek View Post
        You're delusional. NVidia already pushed all the needed firmware to initialize post GSP cards to the linux-firmware.git same as AMDGPU and/or Intel firmware.
        This is not the same. AMD and Intel firmwares have a defined stable ABI.
        There are plans for nouveau to support using the NVIDIA supplied GSP firmware in order to support new hardware going forward The nouveau pro...


        The developers with nouveau are very clear. Nvidia firmware does not have stable way of detect version loaded into card or a stable ABI to fall back on..

        AMDGPU and Intel firmware can in fact be updated without needing to rebuild your kernel to use the newer firmware with cards in majority of cases.



        Firmware files shall be designed in a way that it allows checking for firmware ABI version changes. It is recommended that firmware files be versioned with at least a major/minor version. It is suggested that the firmware files in linux-firmware be named with some device specific name, and just the major version. The firmware version should be stored in the firmware header, or as an exception, as part of the firmware file name, in order to let the driver detact any non-ABI fixes/changes. The firmware files in linux-firmware should be overwritten with the newest compatible major version. Newer major version firmware shall remain compatible with all kernels that load that major number.
        AMDGPU and Intel firmware have functional major numbers with minor version being minor fixes that do not break the Firmware provided ABI to kernel.

        This does keep Linux firmware provide by kernel.org from growing out of control due to AMD and Intel firmwares . Yes a AMD or Intel firmware minor version update can expand the number of AMD/Intel GPU an older Linux kernel supports it also means only latest minor version has to be kept installed.

        There is a difference between having firmware in linux-firmware.git and it being quality firmware that will be useful for older kernels. The reality is Nvidia firmware unstable ABI means to use newer Nvidia GSP firmware equals need newer kernel. AMD and Intel you can use newer firmware with older kernel as long as the Major version still matches. Intel and AMD major versions of their firmware have habit of lasting years. The stable ABI firmware behavior by AMD and Intel applies to everything they make.



        There are some quite interesting thing that both AMD and Intel do so they can maintain stable ABI interface on their firmware so older drivers can use newer firmware. It took AMD a few years to get these frameworks designed tested and in place after they acquired ATI..

        Question is the firmwares being submitted to linux-firmwares for Nvidia support to the standard the Linux kernel rules say it should be. Reality is reading firmware guidelines absolutely not. Nvidia firmwares don't have a major number defining the ABI of the firmware as it should have to be to kernel rules.

        Comment


        • #94
          Originally posted by arabek View Post
          You're delusional. NVidia already pushed all the needed firmware to initialize post GSP cards to the linux-firmware.git and it's beeing distributed the same as AMDGPU and/or Intel firmware.
          You and oiaohm may be talking about two different things - oiaohm's post was about managing the interface between driver and firmware in an environment where driver and firmware can be updated independently, not just publishing the firmware.

          Test signature

          Comment


          • #95
            Originally posted by oiaohm View Post
            This is not the same. AMD and Intel firmwares have a defined stable ABI.
            At the risk of nitpicking, my understanding is that the interface is versioned rather than stable, at least for AMD. The driver code looks at the version number for each firmware image and takes different code paths as required.

            You talk about versioning further down in your post so I'm mostly challenging the specific line quoted above so it doesn't end up getting quoted out of context somewhere else - it seems out of sync with the rest of your post. I'm guessing that your intent was to say "stable ABI as long as major version is the same" ?
            Test signature

            Comment


            • #96
              Originally posted by bridgman View Post
              You and oiaohm may be talking about two different things - oiaohm's post was about managing the interface between driver and firmware in an environment where driver and firmware can be updated independently, not just publishing the firmware.

              (...)

              At the risk of nitpicking, my understanding is that the interface is versioned rather than stable, at least for AMD. The driver code looks at the version number for each firmware image and takes different code paths as required.
              Exactly my point albeit maybe not voiced properly. Don't see a reason why Nvidia and in turn Nouveau couldn't take the same approach handling the fw / kernel driver stuff in the future.

              Comment


              • #97
                Originally posted by arabek View Post
                Exactly my point albeit maybe not voiced properly. Don't see a reason why Nvidia and in turn Nouveau couldn't take the same approach handling the fw / kernel driver stuff in the future.
                The bit you cut off is important.

                "stable ABI as long as major version is the same" ?

                Say a firmware has a minor mistake like a GPU max clock value in firmware is set incorrect. Both AMD and Intel can release a minor version of a firmware to fix something like this no kernel driver change. Nvidia firmware development at the moment this is new firmware with new ABI to fix something this simple so requiring another lot of driver code.

                arabek this is updating firmware and allowing to happen with older kernels where the driver is not changing. This is something you require being mainline because users will not be using the latest drivers all the time under the Linux kernel delivery model.

                Nvidia does not even have framework in place to validate if X firmware and Y firmware happens to have the same ABI by luck. Kernel driver and firmware version number 100 percent sync is something that does not make sense with the Linux kernel driver delivery method.

                I really do see Nvidia keeping their out of mainline driver around and users having to use it so their cards work due to the firmware issue of Nvidia.

                Next thing to remember the in kernel Nvidia driver is having to cherry pick the Nvidia firmware to include in firmware git because they are not small. This is another advantage of the major version on firmware means to pick a major number then keep the latest minor version of that major number. Firmware storage reduction.

                Comment


                • #98
                  Can anyone tell me unequivocally if a 710 (PCI-e) is fully supported by nouveau on 'distro x' these days?

                  It was my impression this was the last of the nVidia dGPU's fully supported by nouveau/Linux
                  Hi

                  Comment


                  • #99
                    Originally posted by stiiixy View Post
                    Can anyone tell me unequivocally if a 710 (PCI-e) is fully supported by nouveau on 'distro x' these days?

                    It was my impression this was the last of the nVidia dGPU's fully supported by nouveau/Linux
                    That one is many cursed. Nvidia has made. There more than 1 Geforce GT 710.

                    NVD7 (GF117) Geforce GT 710M that a NVC0 family (Fermi) that is fully supported.
                    NVE7 (GK107) Geforce GT 710M that is NVE0 family (Kepler) that is only part supported no automatic re-clocking.
                    Both are made in PCIe forms. Both in fact from many Nvidia board partners have the close to the heatsinks(without taking them off the board they are absolutely identical) on them came in the same printed cardboard box can with the same driver disc.... So it depend on what chip the Nvidia board partners had in stock when they were making their 710M what chip you got. You cannot go by date of production of the board because Fermi cards and Kepler cards for the 710M were manufactured at the same time.

                    Retail branding and what the card is with Nvidia in may cases don't line up 1 to 1 for the lower cards. There are lots of cases of Nvidia having cards being made with silicon from two complete different generations of Nvidia silicon with the same retail name at the same time with the board partners putting them in close to absolutely identical packaging. This Geforce GT 710M is not a one off. This is something that AMD and Intel has avoided doing at this stage and I hope they always do.

                    Nvidia retail branding is between 1 to 3 different silicon chip across 1 to 2 generations of silicon and that the way it is in the older cards

                    Newer cards since the absolute annoyed users with Maxwell cards with this problem that caused what was same box what appeared to be the same card one would run particular games and the other would not and the problem was the different silicon chip so since then Nvidia been good doing Retail brand equals 1 silicon chip. Lets hope they stay that way. Yes there were a lot of returned Maxwell cards because users thought they were defective. Of course that made worse that series 1 Maxwell allows load your own firmware and series 2 Maxwell the firmware must be signed and Nvidia has not released the firmware to open source drivers to use series 2 Maxwell cards.

                    Comment


                    • Originally posted by mdedetrich View Post

                      Yes for Vulkan specifically however due to the nature of how the linux graphics stack works, explicit sync needs to be added in many parts of the system and Erik made a significant amount if work in the core Wayland protocol.
                      Apparently Nvidia opened a pull request.

                      This was big time news. Like its never been done before.

                      Phoronix: NVIDIA Developer Opens Feature Pull Request For Open-Source NVK Driver If your interest didn't pique enough when the former Nouveau lead developer joined NVIDIA and sent out a big patch series for this originally-reverse-engineered, open-source NVIDIA kernel driver, here's another plot twist: another NVIDIA engineer


                      In any case, wherever Nvidia did some work and the code was released you're the only person who noticed. But didn't give a link. So you're still the only one who knows.

                      Comment

                      Working...
                      X