News Nvidia unter Linux: Freie Kernel-Module kommen mit GeForce-Treiber-Serie 560

Wo ist denn da der Zusammenhang? Denn es gab die Lösungen und den Support für Linux und auch übrigens die Verbreitung von Nvidia Produkten dort ja schon seit Jahr(zehnt)en, nur nicht Open Source. Die aktuellen großen Sprachmodelle sind ja nicht vom Himmel gefallen. Das große Geschäft damit läuft doch schon auf Hochtouren. Möglich, dass es für Nvidia Vorteile bietet, aber einen direkten Zusammenhang sehe ich da nicht. Support muss ja weiterhin geleistet werden.
Die etlichen Cluster, die jetzt und früher schon mit Nvidia Chips laufen und liefen, tun das seit je her mit dem Closed Source Treiber. Zum Bleistift der Kollege hier: https://www.top500.org/system/180269/ der hier gerade im heutigen Leitartikel beleuchtet wird https://www.computerbase.de/2024-05...setzt-deutschen-jedi-auf-den-effizienz-thron/

Aber auch seine Kollegen für Wetterdaten, Renderfarmen, such dir was aus, laufen damit, sofern sie Nvidia Hardware verwenden, und das sind nicht wenige. Um reinen Linux Support geht es hier doch gar nicht. Oder um ein in Richtung Linux bewegen. Da ist Nvidia schon lange. Und wenn es um Chips für Nicht-Windows geht, siehe halt auch Switch, oder früher die PS3, oder sämtliche Android Geräte mit Nvidia Hardware. Die Liste lässt sich beliebig fortsetzen. Alles mit closed source Treiber.
 
Zuletzt bearbeitet:
Termy schrieb:
Aber eben auch völlig zurecht. Wenn die Lizenz vorsieht, dass proprietärer Code besitmmte Schnittstellen im Kernel nicht nutzen darf, dann hat sich NVidia daran zu halten. Wenn sie das nicht tun, dann würde ich die Reaktion darauf weniger "Steine in den Weg legen" nennen als "Lizenzbestimmungen durchsetzen" ;)
Die GPL erschöpft sich, wenn man API Calls auf entsprechenden Code nutzt, aber nicht den GPL-Code[1]. Die Lizenz sieht es entsprechend auch nicht vor, dass separat bereitgestellte Kernelmodule der GPL entsprechen müssen:
Code:
GPLv2
If [your modules] are not derived from the [kernel], and can reasonably be considered independent and separate works in themselves, then this License, and its terms, do not apply to those [modules] when you distribute them as separate works.
Und "reasonable" wird da normalerweise so verstanden, dass Datenstrukturen, die die APIs bereitstellen auch im Werk Dritter genutzt werden können, ohne dass sofort die GPL greift.

Die Symbol Exports auf "Symbol Export GPL" umzustellen ist kein Durchsetzen der GPL! Es ist ein durchsetzen von "uns gehen eure Binärblobs auf den Sack, deswegen erzwingen wir GPL Code!". Letzteres finde ich verständlich. Software entwickeln, deren APIs von Dritten genutzt wird, während die Kunden dieser Dritten nerven, wenn man die eigenen APIs ändert weil es notwendig ist und mit allen Anderen, kooperativeren Partnern besser klappt.

[1]Es ist wie immer komplizierter, der Anspruch ist aber gerade nicht einen Aufsatz zu schreiben.
Ergänzung ()

Grimba schrieb:
Aber da wird auch weniger religiös zur Werke gegangen.
Das ist weit weniger inhomogen als du dir vorstellen magst. Allein die Kernel/Mesa Entwickler zeigen sich die letzten Jahre ja als hartgesonnen aus und sitzen allesamt bei IT-Firmen mit Namen. Auch die Betreiber von Rechenzentren sind da mitunter Meinungsstark. Wenn da ein Treiberstack das Einführern eines neuen Kernels verhindert, der neue Kernel aber Effizienzgewinne verspricht grummelt es schonmal.

aid0nex schrieb:
Hot Take: Der einzige Grund warum Nvidia sich aktuell in Richtung freier Treiber bzw. Linux Support bewegt ist, dass Nvidia die meisten Chips an Rechenzentren Betreiber und AI Firmen verkauft, die ihre Cluster mit Linux betreiben und nicht mit Windows.
Der Grund ist, die Kernelmaintainer haben Symbol_Export() an vielen Stellen auf Symbol_Export_GPL() umgestellt und gleichzeitig auch damit angefangen gar keine Rücksicht mehr auf Nvidias Blob zu nehmen, wenn sie interne APIs geändert haben.
Das Ganze schwelt bereits ein paar Jahre:
https://www.phoronix.com/news/Linux-6.6-Illicit-NVIDIA-Change
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Grimba und Termy
Piktogramm schrieb:
Das ist weit weniger inhomogen als du dir vorstellen magst.
Mag sein, aber einen nennenswerten Impact auf die Verbreitung von Nvidia Chips in Linux Rechenzentren hatte das bisher offenbar nicht.

Das mit den Kerneländerungen war an mir vorbeigegangen, das ist dann allerdings wirklich sehr nachvollziehbar. Offenbar scheint das dann ja gefruchtet zu haben. Wurde ja auch mal Zeit.
 
Zuletzt bearbeitet:
@Grimba
Man kann das Ganze ja seit einiger Zeit beobachten. Nvidia reagiert im Maßstab großer Firmen recht zügig auf die Kernelentwicklung und bedingt auch aufs Geraune der Großkunden. Die >90% Martkanteil im Datacenter hat die Firma ja auch, weil sie jedem Promille Marktanteil hinterherjagen. Wenn da ein paar Kunden in Richtung Intel oder AMD schauen, weil ein Aspekt der Softwareinfrastruktur passender erscheint, dann bewegt sich was bei Nvidia.

Anderes Beispiel. AMDs RoCm + HIP gebastel ist Imho eine Zumutung und ich würde mir schwer tun das irgendwem im Produktivbetrieb zuzumuten. Es hat aber ein paar Verkäufe für AMD gebracht und Nvidia rüstet sich entsprechend:
https://www.techpowerup.com/319984/...da-translation-layers-changes-licensing-terms
 
Wie gesagt, wenn das jetzt nach all den Jahren dazu geführt hat, dass man hier ein paar Mauern einreißt, umso besser. Haben wir ja alle was von :) Es bliebe ja sonst nur noch, den Kernel zu forken und sein eigenes OS herauszubringen. Aber das wäre vom Risiko und Aufwand vermutlich absolut untragbar.
 
Kaito Kariheddo schrieb:
Man könnte aber auch nur die Kerne Module nehmen und mit einem freien Vulkan Treiber (NVK) kombinieren um ohne den Nvidia Treiber auszukommen
Nein kann man nicht. NVK arbeitet mit dem nouveau Kernel Modul. Nur die Firmware Dateien von Nvidia werden genutzt.
 
Kaito Kariheddo schrieb:
Man könnte aber auch nur die Kerne Module nehmen und mit einem freien Vulkan Treiber (NVK) kombinieren um ohne den Nvidia Treiber auszukommen
Hate01 schrieb:
Nein kann man nicht. NVK arbeitet mit dem nouveau Kernel Modul. Nur die Firmware Dateien von Nvidia werden genutzt.
Das nouveau Kernel Module zugunsten Nvidia's open-gpu-kernel-module aufzugeben ist keine gute Idee, solange letzterer nicht im Kernel ist. Und das kann so schnell nicht passieren. Ferner glaube ich auch nicht dass Nvidia das überhaupt möchte. Sie müssten dann den Programmierstil des Kernels nutzen und sich nach deren Entwicklungsprozessen und -zyklen richten. Das Problem an einem externen Modul ist dass die Entwickler ihre Schnittstellen ohne Vorwarnung ändern können. Für fremde Userspace-Treiber ist das eine ständige Aufholjagd. Module im Kernel müssen Linus' hohe Anforderungen an Stabilität erfüllen.

Selbst wenn Nvidia's open-gpu-kernel-module irgendwann im Kernel landet, dann kann das Teil ja nur Turing+ (RTX20xx/GTX16xx) während nouveau noch die Riva TNT unterstützt. (Support-Matrix, Code-Names)

Außerdem kommen das open-gpu-kernel-module und der GSP nouveau zu Gute: nouveau's größtes Problem, das Power Management/Reclocking funktioniert nach vielen Generationen erstmalig vollständig auf Turing+
 
Marco01_809 schrieb:
Das nouveau Kernel Module zugunsten Nvidia's open-gpu-kernel-module aufzugeben ist keine gute Idee, solange letzterer nicht im Kernel ist. Und das kann so schnell nicht passieren. Ferner glaube ich auch nicht dass Nvidia das überhaupt möchte. Sie müssten dann den Programmierstil des Kernels nutzen und sich nach deren Entwicklungsprozessen und -zyklen richten. Das Problem an einem externen Modul ist dass die Entwickler ihre Schnittstellen ohne Vorwarnung ändern können. Für fremde Userspace-Treiber ist das eine ständige Aufholjagd. Module im Kernel müssen Linus' hohe Anforderungen an Stabilität erfüllen.
Ist mir alles bekannt, ich hab nur der vorrigen Aussage widersprochen. Der "open source Nvidia Treiber" hat mit NVK nichts zu tun.
 
Dann kann ich wieder einmal Linux mit meinem Gaming-PC probieren :-)
Ergänzung ()

Bei 8Watt wird die wohl auch etwas wärmer im Plastikgehäuse.
 
Zuletzt bearbeitet:
Zurück
Oben