[News] Nvidia blockiert OpenSource-Treiber-Entwicklung

[oooverclocker]

Aus dem folgenden, englischsprachigen Artikel geht hervor, dass Nvidia die Entwicklung von anständigen OpenSource-Treibern durch das Zurückhalten von Firmware behindert.
Nouveau Developers Remain Blocked By NVIDIA From Advancing Open-Source Driver - Phoronix

Demnach bestand Kontakt zwischen dem Team hinter dem OpenSource-Treiber Nouveau und einem Nvidia-Mitarbeiter. Dieser hat das Unternehmen jedoch verlassen, sodass aktuell wohl überhaupt kein Kontakt mehr besteht.
Zudem wird beklagt, dass Nvidia Anfragen fast völlig ignoriert. Nouveau ist in einer guten Verfassung und konnte von den Radeontreibern für AMD-Hardware und den IGP-Treibern für Intel-Hardware profitieren, sodass sogar OpenGL 4.5 fast komplett unterstützt wird - der Treiber wäre also nur knapp hinter AMD und Intel zurückliegend, wenn er Zugriff auf die Firmware hätte.

Nvidia begründet dies wohl mit einem eigenen OpenSource-Treiber "NVGPU". Dieser wird aber den Informationen zufolge nur für Tegra-PCs entwickelt und steht somit gar nicht im Konflikt mit Nouveau. Die Community ist sich zudem absolut einig, dass es viele Gründe dafür gibt, dass NVGPU niemals in einem Kernel landen kann.

Das Standing von Nvidia war in der Geschichte der Linuxgemeinschaft schon häufiger mit Reibung verbunden, weil Nvidia jede Zusammenarbeit mit Linux-Projekten verweigerte. Das führte nicht zuletzt zum bekannten Zitat von Linux Torvalds

Nvidia, FUCK YOU!

AMD hat vor wenigen Jahren durch OpenSourcing den gegenteiligen Weg eingeschlagen und der OpenGL-Treiber hat sich so gut entwickelt, dass er in vielen Benchmarks mehr Leistung bringt, als der Windows-Treiber. Beklagt wird allerdings auch, dass der quelloffene Vulkan-Treiber noch nicht die Leistung abliefert, die er sollte und dass die OpenCL-Funktionalität aufwändig nachinstalliert werden muss. Edit: Dies wird sich - und das sollte man fairerweise erwähnen - aber in nicht allzu ferner Zukunft schon ändern und ist nur ein temporäres Problem.

Wird das Duell AMD vs. Nvidia dadurch mehr und mehr zu einem Duell zwischen Offenheit und Protektionismus? Oder wird Nvidia irgendwann nachgeben müssen?

 

[DragonTear]

Sache ist, Open-Source ist kein Allheilmittel. Wenn sich der Hersteller der am meisten vom Produkt profitiert, nicht der Sache annimmt (weil er sich nicht sicher sein kann, den gesamten Profit einzustreichen), hinkt unter Umständen alles hinterher. Aktuellstes Beispiel ist das ARkit von Apple in iOS 11. Da wurde Android mal eben überrumpelt obwohl Technik in Form von Projekt Tango dagewesen wäre.
Jetzt muss Google selbst eine Alternative puschen (AR Core), denn thirdparty Hersteller haben es trotz Open Source Platform nicht (so gut) hinbekommen.

Natürlich ist es aus Kunden- und auch aus Entwicklersicht nicht besonders schön was NV macht, aber für den gesammten Fortschritt ist es oft nicht so schlimm wie man zunächst vermuten würde.

 

[sTOrM41]

wenn man bei nvidia kein bock auf dieses linux gefrickel hat, dann sollte man das wohl am besten einfach so akzeptieren.

 

[oooverclocker]

Ich verstehe die Kritik - aber in dem Fall wäre das "Gefrickel" leider vor allem, dass man zusätzliche Treiber installieren muss. Der Vorteil von OpenSource-Treibern ist, dass man einfach ein Betriebssystem installiert(z.B. Ubuntu) und die Hardware läuft komplett - so jedenfalls aktuell bei AMD. Wenn Nvidia darauf "keinen Bock" hat, stellt das natürlich ein Problem für den Nutzer dar, weil er dann den proprietären Treiber braucht, der zum einen nicht von so vielen Leuten betreut wird(weil wenige darauf Zugriff haben) und zum anderen bei einem Update des Kernels beispielsweise Probleme verursachen kann.

Es wäre schon gut, wenn Nvidia einfach die Firmware freigeben würde, damit Nouveau sich weiter entwickeln kann. Dass man das verweigert, ist schon ein Schlag ins Gesicht der Leute, die ihre Freizeit opfern, um Nouveau weiterzuentwickeln. Und natürlich auch der Nutzer, die keine proprietären Treiber installieren möchten, sondern einfach ein funktionsfähiges System ohne Eingriffe wollen.

 

[fax668]

Das ist schon OK so. Ich hatte sehr viele Jahre nur NVidia in meinen Linuxbüchsen, jetzt wird's halt AMD. Wobei ich damit schon vor zwei Jahren angefangen habe, als NVidia die Hardwarebeschleunigung in VMs abgeschaltet hat. So Scherze macht man mit mir nur einmal.

 

[Morpheus2200]

Nix neues. Nvidia bescheidet bei den treibern wo es geht. Sei es um quadro Karten, die quasi den gtx gleichen mit einer 0 mehr auf dem preisschild zu verkaufen, oder die künstliche Beschneidung von transcoding streams selbst auf den teuren quadro Karten, obwohl Leistung noch genug da wäre. Einer der Gründe, warum ich bei Grafikkarten eher im roten Lager schau...

Gesendet von meinem LG-D855 mit Tapatalk

 

[jdl]

Ich verstehe die Kritik - aber in dem Fall wäre das "Gefrickel" leider vor allem, dass man zusätzliche Treiber installieren muss. Der Vorteil von OpenSource-Treibern ist, dass man einfach ein Betriebssystem installiert(z.B. Ubuntu) und die Hardware läuft komplett - so jedenfalls aktuell bei AMD. Wenn Nvidia darauf "keinen Bock" hat,

Ich betreibe seit Jahren eine Linux Workstation mit nVidia Karte. In dieser Zeit hatte ich zweimal ein Problem, weil das Paket von Ubuntu fehlerhaft war, und man den Treiber nochmals installieren musste.

Ubuntu installiert automatisch den Treiber nach, wenn man das System frisch installiert hat. Es gibt Gründe weshalb ein FOSS Treiber im Prinzip besser wäre, aber bisher ist dieser Zustand auch bei AMD noch nicht erreicht. Als ich das System gekauft habe war AMD eine einzige Frickelei. nVidia pflegt übrigens den proprietären Treiber länger als AMD den FOSS Treiber! Das mag nun bei den neuen Karten anders sein, aber AMD hat den Support für viele ältere Karte de facto eingestellt.

 

[oooverclocker]

Das stimmt, AMD selbst supportet mit AMDGPU beispielsweise nur GCN-Karten. Es kommt sehr selten vor, dass mal ein von AMD bezahlter Entwickler noch Patches für den älteren macht. Aber AMDs Ressourcen wachsen auch nicht auf Bäumen und irgendwo musste man den Cut dann machen

Für eine Workstation braucht man aktuell auch bei AMD noch die proprietären Treiber, wegen OpenCL(Es sei denn, man bastelt ein wenig Zeug zusammen, was es so gibt). Sehr schön ist aber, dass nun wahrscheinlich in Kernel 4.15 der neue Displaytreiber landet, sodass alle Consumer-Ansprüche damit abgedeckt werden und auch Vega out of the Box laufen wird. Außerdem wird man die Vulkan-Implementation irgendwann opensourcen, wobei RADV schon deutliche Fortschritte gemacht hat, sodass es sein kann, dass RADV trotzdem der Standard-OpenSource-Treiber bleibt und noch ein wenig durch die anderen Bauteile getunt wird.
Dann fehlt nur noch OpenCL, das AMD auch in Form von ROCm in den Kernel integrieren wird.

Das Problem bei DC war, dass es zuerst abgelehnt wurde, weil Dinge, die im Kernel landen wirklich eine top Qualität haben müssen. Möglicherweise hat das massive Stück Software aus Kernel-Sicht noch immer Ecken und Kanten, aber die wird man auch noch nachträglich schleifen können.
Das ist halt anders, wenn Du sowieso nur Binaries rausgibst, dann kannst Du am schlechten Tag auch mal irgendwas hinrotzen, völlig ohne Kommentar und Formatierung und Deine Buddys auf der Arbeit nicken es dann so halb geistesabwesend ab Der Korrektheitsfanatismus im Kernel ist vor allem eine Sicherheitsfrage, damit man Backdoors etc. weniger verstecken kann, aber auch um neuen Entwicklern einen reibungslosen Einstieg zu ermöglichen, schließlich lebt OpenSource davon.

 

[jdl]

Ich habe einen ziemlichen dicken Hals wegen Torvalds und der fehlenden stabilen API des Linux Kernels. Ich hatte schon das Problem erlebt, dass FOSS Projekte mit weniger Man Power Kernelextension entwickelt haben und dann wegen der Instabilitäten auch bei Minor Releases des Kernels sie nicht mehr funktionieren. Als ich noch Linux auf PowerPC Hardware am laufen hatte, hatte ich regelmäßig das Problem, dass APIs so verändert wurden, dass auf PowerPC bestimmte Dinge zwischen verschiedenen Minor Releases nicht mehr liefen. Z.B. ließen sich nur bis zu einem bestimmten 2.4.x Kernel Release PowerPC PreP Systeme booten, danach ging das ohne Vorankündigung nicht mehr.

Die FOSS Extension um die es ging war für Checkpoint/Restart, was für HPC sehr essentiell ist. D.h. man kann ein laufendes Programm auf die Platte schreiben und auf einem anderen System wieder starten. Das ist von Vorteil, wenn HPC-Knoten bei lang laufenden Berechnungen crashen und man so nur einige Stunden verliert und nicht Tage oder Wochen an Rechnung. Leider konnte man das nur auf einem RHEL installieren, wenn man selbst die Kernelextension patched und sich in wichtige Details der verschiedenen Kernelminorversionen einliest. Es ging da konkret um 2.6.2x bis 2.6.3x Versionen, d.h. relativ zeitnahen Releases des Kernels. Dazu haben die RHEL Kernel nicht ohne Grund eine weitere Zählweise, da es massenweise Backports gibt.