Originally posted by oiaohm
View Post
Former Nouveau Lead Developer Joins NVIDIA, Continues Working On Open-Source Driver
Collapse
X
-
-
-
Originally posted by clippy View PostWell, 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.
Comment
-
-
Originally posted by arabek View PostYou'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.
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.
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
-
-
Originally posted by arabek View PostYou'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.
Test signature
Comment
-
-
Originally posted by oiaohm View PostThis is not the same. AMD and Intel firmwares have a defined stable ABI.
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
-
-
Originally posted by bridgman View PostYou 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.
Comment
-
-
Originally posted by arabek View PostExactly 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.
"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
-
-
Originally posted by stiiixy View PostCan 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
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.
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
-
Comment