Az NVIDIA megnyitotta a GPU-i kernelmoduljainak forráskódját!

Címkék

Azok után, hogy a Linux kernel fejlesztői év(tized)eket küzdöttek azért, hogy az NVIDIA megnyissa GPU kernelmoduljainak forráskódját, azokat ne binary-only blob-ok formájában terjessze, amik debug-rémálomként "szennyezett" (tainted) kernelt eredményeznek, azután, hogy Linus középső ujjat mutatott a vállalatnak a hozzáállásáért, végül a GPU-gyártó MEGNYITOTTA GPU-i kernelmoduljainak forráskódját kettős, GPL/MIT licenc feltételei szerint:

NVIDIA is now publishing Linux GPU kernel modules as open source with dual GPL/MIT license, starting with the R515 driver release. You can find the source code for these kernel modules in the NVIDIA Open GPU Kernel Modules repo on GitHub.

This release is a significant step toward improving the experience of using NVIDIA GPUs in Linux, for tighter integration with the OS and for developers to debug, integrate, and contribute back. For Linux distribution providers, the open-source modules increase ease of use. They also improve the out-of-the-box user experience to sign and distribute the NVIDIA GPU driver. Canonical and SUSE are able to immediately package the open kernel modules with Ubuntu and SUSE Linux Enterprise Distributions.

A forráskódok megtalálhatók a GitHub repójukban. Az NVIDIA nem csak megnyitotta, de ígéretet is tett arra, hogy mostantól a nyílt forráskódokat karban is tartja. További részletek az NVIDIA driver README dokumentumában.

Ugyan az user space programjuk egyelőre még zárt forráskódú maradt, de ez mindenképpen egy óriási lépés az NVIDIA-tól a helyes irányba! Bő lére eresztve a részletek megtalálhatók a Phoronix cikkében.

Hozzászólások

Azok után, hogy a HUP-pal végigkövettem az open source világ elmúlt 2 évtizedének történéseit, nem hittem volna, hogy erre a napra ennyit kell várni / valaha eljön-e egyáltalán. Újabb erős bástyája dőlt le a zárt forráskódú, proprietary világnak. Nem sok ilyen erős bástya áll már. Kíváncsi leszek a következő két évtized milyen meglepetéseket tartogat még :)

trey @ gépház

Vagy csak arrol van szo, hogy a gpu mar nem csak jatekra valo, es a cloud computing vilagaban kifejezetten hatrany a zart forrassal kinlodni (tensorflow es tarsai?)?

Vagy az amd annyira feljott, hogy mar nem engedhetik meg maguknak, hogy szivozzanak?

 

Mondjuk ez a Lapsus$ tores se piskota. Vittek azok mindent. 2 ev es kiderul...

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Vagy az amd annyira feljott, hogy mar nem engedhetik meg maguknak, hogy szivozzanak?

Max játék fronton lehetne ilyenről beszélni, de az egyrészt Linux alapon továbbra se tényező (Steam statisztikák kezdetektől fogva hibahatár alatti Linuxos játékos közösséget mutatnak), computing téren pedig továbbra is durva lemaradásban van az AMD.

Szerintem csak egyszerűen kiszámolták mennyibe kerül maintainelni a privát blobjaikat meg mennyibe kerülne, ha megnyitnák a forráskódot és kijött, hogy olcsóbb lenne. Arra meg már elég kiterjedt tapasztalat van, hogy a források megnyitása nem dönti be a céget, lásd konkurencia.

Egyébként ez tényleg piszok nagy hír, ha most lesz végre az amdshez hasonló minőségű nyílt driver, akkor AMD-t végre el lehet felejteni a hülye problémáival. Mezei workstationhöz elég az Intel IGP, komolyabb feladatokhoz meg végre ott lesznek a zöldek problémák nélkül.

Mezei workstationhöz elég az Intel IGP, komolyabb feladatokhoz meg végre ott lesznek a zöldek problémák nélkül.

Azt hogyan kell elképzelnem, amikor például egy AMD CPU lapkára Intel GPU-t tervez az AMD? :) Van egy 8 magos Ryzen 7 a gépemben, s talán nem is az amdgpu, hanem az i915 kernel modul való hozzá?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nemtom, ha az egyszeri irodistát arra kéred, kommentáljon egy átlagos Figma fájlt az intel IGP-vel, a két munkanapos határidő alatt egyáltalán bezoomolnia sikerül-e a kérdéses keretre.

Az IGP kiválóan alkalmas backend kódereknek meg hogy kiírja a BIOS (UEFI) a hibát ha valaki cs.szett normális videókártyát rakni a gépbe, de továbbra is mellőzném irodai munkához (aminek ma már meglepően nagy részében kell nagyméretű, többrétegű képekkel dolgozni).

Ez attól függ, hogy kinek. Sokunknak eljött már sok évvel ezelőtt. Nagyon windowsos normiknak meg lehet soha nem fog eljönni, hanem a Windows desktop éve fog elmúlni, ha a MS ilyen ütemben zülleszti tovább. Aki komolyan linuxozik, vagy egyáltalán nem csak Windowsban gondolkodik, az eddig is AMD GPU-kat vett (hacsak nem volt elég neki az integrált GPU). Az oka, hogy nem csak Linux alatt jobb, de pl. az AMD megy BSD-k alatt, még OpenBSD-n is, ahol az NV meg se nyikkan, FreeBSD-n is zárt driver kell hozzá, ahogy Linuxon. Hardvert venni általános stratégia, és nem csak az árat kell nézni, meg nem csak azt, hogy benchmarkokban, játékokban hány fps-t tud. Nem csak maga az OS ellátottság, driver nyíltság, hanem pl. a régi GPU-k támogatásában is jobban áll az AMD, a NV a zárt driverekben rendszeresen, mesterségesen elavultat régi GPU-kat, míg az AMD a zárt driverben is lassaban operál ilyennel, tovább tart, míg egy kártya támogatott, és a támogatási idő lejártával is lehet szépen hajtani nyílt driverrel. Ez se lényegtelen különbség sok embernek.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Jo kerdes, hogy ez mennyire motivalta az Nvida-t. Evekkel ezelott (amikor legutobb videokartyat vettem) az NVidia Linux tamogatasa egyertelmuen jobb volt Linuxon, de ido kozben az AMD nyilt forrasra valtott es ezzel fordult a kocka. Bar nem tudom, hogy az 1%-os Linux desktop piac igazabol mennyire szol bele ebbe a jatekba es nem masrol van-e szo (crypto banyaszat, GPU processing, ilyesmi).

Kozben a Phoronix cikkben megtalaltam ezt, amibol egyertelmuen lejon, hogy nem a Linux desktop volt a fo motivacio:

NVIDIA's open kernel modules is already considered "production ready, opt-in" for data center GPUs. For GeForce and workstation GPUs, the open kernel module code is considered "alpha quality" but will be ramped up moving forward with future releases.

Es meg:

Only Turing and newer GPUs will be supported by this open-source kernel driver. Pre-Turing GPUs are left to using the existing proprietary kernel drivers or the Nouveau DRM driver for that matter.

Épp ezen gondolkodtam, hogy ez talán arról is szól, hogy újabb érvet adjanak új(abb) videókártya vásárlásához. Itt vagyok pl. én a csiszolt kőkori GTX 650Ti-jommal, amihez (ha jól értem) nem lesz szabad driver. Szabad driver csak újabb kártyához jár, a magamfajták meg "minek mentek oda". =) Ja, és az érem másik oldala, hogy ezzel talán felgyorsíthatják a régebbi kártyák kikopását is. (Hamarabb dobhatják a támogatást...?)

Nekem is regebbi a kartyam, de szerintem emiatt senki nem fog valtani. Ha eddig mukodott a regi a zart koddal akkor miert koltenel penzt, csak hogy elmondhasd, hogy most mar nyilt a driver? Viszont uj kartya vasarlasnal ez nagyon is szempont lehet. DE ahogy az elozoekbol kiderult nem a Linux desktop userek huzzak ezt a piacot. :D

miert koltenel penzt, csak hogy elmondhasd, hogy most mar nyilt a driver?

Azért ha rms megjelenne a hátam mögött ("Let me interject for a moment..."), akkor lehet, hogy megérné a pénzt a nyílt driveres kártya. :D Viccen kívül, nyilván csak ezért nem fogok új kártyát venni, de pl. az év elején beszerzett Subanutica is is megérne egy új kártyát, most itt a lehetőségem, hogy (részben) nyílt driveres NVidiát vegyek. ("Költsd a pénzed!.. Költsd!.. Pörgesd a gazdaságot!.." :P)

Meg is jelent az első NVIDIA driver bétája a fentiek szerint:

Linux x64 (AMD64/EM64T) Display Driver 515.43.04 BETA

  • Published the source code to a variant of the NVIDIA Linux kernel modules dual-licensed as MIT/GPLv2. The source is available here:
    https://github.com/NVIDIA/open-gpu-kernel-modules and will be updated each driver release. Please see the "Open Linux Kernel Modules" chapter in the README for details.
  • Added support for the VK_EXT_external_memory_dma_buf and VK_EXT_image_drm_format_modifier Vulkan extensions. To use this functionality, the nvidia-drm kernel module must be loaded with DRM KMS mode setting enabled. See the DRM KMS section of the README for guidance on enabling mode setting.
  • Changed nvidia-suspend.service, nvidia-resume.service, and nvidia-hibernate.service to use WantedBy= rather than RequiredBy=dependencies for systemd-suspend.service and systemd-hibernate.service.This avoids a problem where suspend or hibernate fails if the NVIDIA driver is uninstalled without disabling these services first.
    See https://github.com/systemd/systemd/issues/21991
    If these services were manually enabled, it may be necessary to update their dependencies by running sudo systemctl reenable nvidia-suspend.service nvidia-resume.service nvidia-hibernate.service
  • Interlaced modes are now disabled when active stereo is enabled.
  • NVIDIA X Server Settings will now display the quit confirmation dialog automatically if only there are pending changes that need to be manually saved. The corresponding configuration option to control the appearance of the quit dialog was thus also removed.
  • Removed the warning message about mismatches between the compiler used to build the Linux kernel and the compiler used to build the NVIDIA kernel modules from nvidia-installer. Modern compilers are less likely to cause problems when this type of mismatch occurs, and it has become common in many distributions to build the Linux kernel with a different compiler than the default system compiler.
  • Updated nvidia-installer to skip test-loading the kernel modules on systems where no supported NVIDIA GPUs are detected.
  • Updated nvidia-installer to avoid a race condition which could cause the kernel module test load to fail due to udev automatically loading kernel modules left over from an existing NVIDIA driver installation. This failure resulted in an installation error message "Kernel module load error: File exists".
  • Updated the RTD3 Video Memory Utilization Threshold (NVreg_DynamicPowerManagementVideoMemoryThreshold) maximum value from 200 MB to 1024 MB.

trey @ gépház

"The proprietary flavor supports the GPU architectures Maxwell, Pascal, Volta, Turing, Ampere, and forward."

- bahh...

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Wow. Just wow!

Ez most komolyan azt jelenti, hogy lesz rendes, karbantartott 3D gyorsítás linuxon Nvidia-val? Hogy nem lesz mindenféle nouveau bug, hogy az eddigi zárt driver teljes funkcionalitását megkapjuk?

Erre long time AMD userként is legurítok egy felest.

Szerkesztve: 2022. 05. 12., cs – 12:16

Én meg 1 sört meló után, mint Ős Nvidia felhasználó. Eljön még a non-free repo mentes Debian is egyszer.
Erre többet kell várni. Milyen kommentek vannak phoronixon ... :)

> Ugyan az user space programjuk egyelőre még zárt forráskódú maradt, de ez mindenképpen egy óriási lépés az NVIDIA-tól a helyes irányba!

Nem akarok ünneprontó lenni, de nem a zárt forráskódú userspace-ben van a lényeg? Továbbra sem lesz triviális az open source drivert fejleszteni, nem? Mondjuk az órajel állítás és hasonló problémák meg fognak oldódni a szabad driverben, de a shaderek fordításában megmarad a verseny. Ami nem feltétlenül baj, ha a szükséges dokumentáció rendelkezésre áll a szabad szoftveresek számára. Van aki ismeri ezt közelebbről?

A nagy dolog, hogy

  • nem lesz tainted a kernel a modult betöltve
  • könnyebb lesz debugolni
  • mivel GPL a kernelmodulok forrásának licence, akár a mainline kernelben is karban lehet tartani
  • az NVIDIA jelezte, hogy szándékában is áll karbantartani
  • hozzá lehet járulni kóddal a fejlesztéshez
  • még a legszigorúbb irányelveket valló disztribútorok gond nélkül szállíthatják

Ezek eddig nem létező dolgok voltak.

trey @ gépház

Továbbra sem lesz triviális az open source drivert fejleszteni, nem?

Ezt nem nagyon ertem. Egyreszt de, hiszen forkolhatod a (most mar) open drivert. DE a nagyobb kerdes, hogy miert tennel ilyet ha egyszer mar van egy open driver (emi velhetoleg jol karbantartott es koveti az uj GPU-kat). Az intel driver pl a kezdetektol open de soha nem hallottam meg forkrol...

Úgy értem, hogy teljesítményben még jóval gyengébb a szabad driver ismereteim szerint. Ezen nem fog segíteni ez a nyitás, ha jól sejtem.

Dehogynem fog. Ha jol sejtem the a Novueau drivert hivod nyiltnak, ami kb egy hobbi projekt, de most arrol van szo, hogy az Nvidia a sajat driveret nyitja meg, szoval perszehogy tobbet fog tudni a jelenlegi nyit drivernel (=novueau).

De ez csak a fele, pl. a X11-hez ott van a nvidia_drv.so és a libglxserver_nvidia.so, ezek továbbra is zártak. Vagy a libcuda.so, ha nem csak rajzolgatni akarsz.

A kernel oldalának megnyitása annyit segít, hogy talán így azonnal leköveti az épp aktuális agymenéseket, pl. mennyi ideig nem volt KMS az nvidián, most meg az ilyen jövőbeli featurek azonnal támogatva lehetnek.

 

Úgy értem, hogy teljesítményben még jóval gyengébb a szabad driver ismereteim szerint

Nem ez a fő baj a szabad driverrel, hanem hogy a friss hw támogatása olyan lassan kerül használható állapotba, hogy gyakorlatilag csak elavult vasakon tudod használni. Laptopnál pl. ez azt jelenti, hogy a laptopmodell, ami diszkrét GPU-val rendelkezik, azt kidobod, mire lesz rendesen működő támogatás a szabad driverben. Ergó aki ilyet vesz, az binary-only tainted kernellel tudja csak a Linuxot használni.

Szokás szerint a túlélés érdekében tették. Aki sokáig szopat, a végén még megszopja. Jól is van ez így.

robyboy

Szerkesztve: 2022. 05. 12., cs – 15:50

És ennek biztosan nincs semmi köze a dologhoz?
https://mashable.com/article/nvidia-ransomware-hackers-cryptocurrency-m…

Ha már ellopták a forráskódokat és megfenyegették őket, hogy nyilvánosságra hozzák, akkor jobb ha ezt megelőzve ők maguk hozzák nyilvánosságra.

Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

És akkor most Linus betekeri a középső ujját? :-)

Ahogy a másik topikban már írtam, azért korai az öröm. Nem tudni mikorra forrja ki magát, mi lesz benne (firmware terjesztési jogi, userland control panel, stb.), plusz csak a GTX 16xx, 20xx és újabb GPU-khoz lesz jó, a legnépszerűbb 7xx-10xx-es GPU-khoz továbbra is csak zárt driver lesz. Így én még Torvalds helyében nem tekerném vissza olyan gyorsan a középső ujjakat, meg nem rohannék NV GPU-t venni, biztonságosabb vétel még mindig az AMD.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Az h. ott van mellette egy 34 megás .bin is a csomagban, az amúgy milyen hatással van az aktuálisan nagy örömre?

Abban nem tudom konkrétan mi van, mármint, hogy a zárt firmware mennyi funcionalitást fed le, de önmagában ezzel probléma nincs. Az AMD se nyitotta meg a firmware részét. Ez a gyártóknál szokás, hogy a driver hiába opensource, a firmware nem az. Nyilván jobb lenne, ha azt a kódot is megnyitnák, de nem lehet telhetetlennek lenni.

Ami engem inkább aggaszt, hogy sokan azt írják, hogy csak félig lesz a driver nyílt. Csak a kerneldriver része, a többi rész zárt marad, a firmware-en felül is. Kb. ahogy most az amdgpu-pro driver, amihez az alapot a nyílt amdgpu adja, és erre épül rá a zárt pro, és azt mondják, hogy az Nvidiával is így lesz, de ott kötelező lesz a „pro”-nak megfelelő userspace driver, míg AMD-nél opcionális.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Igazából nem érdekes az nVidia firmware-e, ha specifikálják, milyen címre mit kell írni, onnan olvasva melyik bit mit jelent, s ennek hatására mi történik. Ha van egy mikrokontrollernek egy perifériája, s az regiszter szinten dokumentálva van, nem kell tudnom annak a kapcsolási rajzát. Doksi alapján használom a perifériát, s ha nem bugos, akkor működni fog.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

IMHO ezek ennél kicsit bonyolultabban működnek. Bár őszintén szólva nem ismerem a grafikus processzorok belsejét, azon kívül hogy masszívan párhuzamos végrehajtásra vannak optimalizálva. Egyszerű műveleteket tud csak végezni, de attól még processzor.

Plusz régebben azért is nem nyitották meg a teljes forráskódot (és valószínűleg most sem fogják teljesen), mert rengeteg szabadalmaztatott technológia meg trade secret van benne.

Mondjuk hogy azt a nyavalyás power management-et miért nem lehet publikálni, azt én sem tudom. Ugye a nouveau ezzel küzd, hogy a 900-as széria felett nem tud órajelet/feszültséget állítani, úgyhogy a kártya a leglassabb órajelen megy csak.

Szerintem ez nem függ a bonyolultságtól. A mondandóm lényege, hogy a firmware által működik valahogyan a GPU, de van egy interface, amelyen keresztül elérhető a szerkezet. Ezt az interface-t kell nagyon jól definiálni, s onnantól kezdve igazából az sem fontos, hogy valami hardware, FPGA valósítja meg a működést, vagy egy hardware-en futó firmware. Nekem mindegy, csak az történjen, amit a doksiban írtak, s a doksi legyen minden részletre kiterjedő, pontos.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ez egy jó ötlet lenne, OS-függetlenné lehetne tenni a drivereket, de vannak hátrányai is. Pl. ami kapásból eszembe jut, hogy így nem tudnád az adott drivert az adott OS-re optimalizálni. Csak a firmware-t külön, igaz ez egyben némi fokú előny is, mert ha azt optimalizálják, akkor azzal egyben minden platformra optimálisabb lesz egyszerre. A másik hátránya, hogy ha tényleg a drivernek szinte az egészét besuvasszák a firmware-be, akkor lényegében azzal zárt driver használatára kényszerítenek, és esély sincsen arra, hogy valaki bugokat, biztonsági réseket keressen, javítson, saját maga optimalizáljon.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Ezt az interface-t hívják OpenGL-nek meg DirextX-nek, az vele a baj a tapasztalat szerint, hogy nem ad versenyzési lehetőséget a gyártóknak. Ez általában is igaz a szabványosításra sajnos, hogy bár elméletben jól hangzik, hogy a dolgok szabványosak, és kicserélhetőek egymással, a gyakorlatban a gyártónak az az érdeke, hogy ne tudják lecserélni egy konkurens termékre.

Maga a GPU fejlesztés elég drága, 3-4 lényegi szereplővel (nVidia, AMD, Intel, meg esetleg az Apple meg a mindenféle ARM SoC szörnyek), nekik kb. az az érdekük, hogy persze, az office 365 az induljon el a bármin, de ha 60+ fps akar valaki játszani, akkor már dolgozni kelljen a fejlesztőknek, meg versenyezzenek egymással a gépek, ne legyen tökmindegy, hogy neked mid van.

Ezt értem, de beszélhetünk egyedi, low level interface-ről is. Tehát ha megmondják, hogy milyen címre mit írok, akkor mi történik, hol olvassam a státuszt, annak a bitjei mit jelentenek, akkor felőlem lehet zárt a firmware, ha úttörő becsületszóra az történik, amit leírtak a specifikációban.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Mindjárt meghatódom.

Azt is számoljuk hozzá, hány videókártyát kellett emiatt újravásárolni (kidobni) a 2 évtized alatt.