Original-URL des Artikels: https://www.golem.de/news/opengl-ersatz-vulkan-bringt-sehr-viel-fuer-open-source-1602-118839.html    Veröffentlicht: 01.02.2016 09:57    Kurz-URL: https://glm.io/118839

OpenGL-Ersatz

Vulkan bringt sehr viel (für) Open Source

Für Linux-Nutzer werde die Grafik-API Vulkan einige Vorteile bringen, erklärt ein Intel-Entwickler, und Programmierer können sich auf ziemlich viel Open-Source-Code rund um Vulkan freuen. Doch genauso ist mit Problemen zu rechnen - und womöglich Jahren des Wartens.

Vulkan ist kein "OpenGL++", das stellt der Intel-Mitarbeiter Jason Ekstrand gleich zu Beginn seines Vortrages auf der Konferenz Fosdem klar. Die neue Grafik-API sei keine simple Weiterführung bisheriger Konzepte, sondern ein kompletter Neuanfang. Das bringt Linux-Nutzern und Open-Source-Enthusiasten ebenso wie Entwicklern gleich mehrere praktische Vorteile.

Proprietäre und freie Treiber nebeneinander

Mit Vulkan soll sich der Aufbau des Grafikstacks auch unter Linux grundlegend ändern. Bisher ist die Bibliothek LibGL aus Mesa Teil der eigentlichen Grafiktreiber, um 3D-Darstellungen zu ermöglichen. Sie kann aber nur exakt einmal auf dem System existieren, so dass etwa der proprietäre Nvidia-Treiber seine eigene Version davon installiert und eine andere eventuell vorhandene löschen muss. Ein einfacher Wechsel zwischen dem freien Nouveau-Treiber und dem proprietären Nvidia-Treiber ist damit nicht mehr möglich.

Auf einem System, das zusätzlich zu einer dedizierten Nvidia-Grafikkarte noch eine integrierte Intel-Grafik hat, wird der Intel-Treiber völlig lahmgelegt und ist nicht mehr benutzbar. Diese Situation und der Umgang mit dem Problem führten im Jahr 2012 zu einem Wutausbruch von Linus Torvalds und den eindeutigen Worten: "Fuck you, Nvidia!".

Bei dem Einsatz von Vulkan wird es nur eine kleine Bibliothek geben, die je nach Einsatzzweck den eigentlichen Treiber lädt, genannt Loader. Die Treiber können so in beliebigen Pfaden gespeichert werden, womit der Wechsel zwischen verschiedenen 3D-Treibern - frei oder proprietär - zumindest theoretisch problemlos möglich sein sollte. Dazu ist nicht einmal ein Neustart des Rechners notwendig.

Dank dieser Technik werde außerdem das Erstellen von Paketen der Treiber für Linux-Distributionen und deren Verteilung deutlich einfacher, als dies derzeit der Fall ist, sagt Ekstrand.

Spiele einfach portierbar

Vulkan wird durch weite der Teile der Industrie unterstützt. Diese kollaboriere viel mehr, als das noch vor Jahren möglich gewesen wäre, kommentiert Ekstrand, so dass Vulkan wohl tatsächlich eine einheitliche plattformübergreifende API werden könnte. Das Nebeneinander von Direct3D auf Windows einerseits und OpenGL auf anderen Systemen andererseits könnte durch Vulkan mittelfristig wohl überwunden werden.

Das gelte zunächst vor allem für Anwendungen mit sehr intensiven 3D-Berechnungen wie eben Spielen. Ekstrand erwartet, dass eine Vielzahl neuer Spiele auf Vulkan setzen wird, da die API gegenüber den derzeit verfügbaren klare Vorteile für die Spieleentwickler biete.

Falls eine Anwendung für die Verwendung mit Vulkan geschrieben worden ist, sei der Port auf andere Plattformen als das zurzeit dominierende Windows aber nur noch "ein kleiner Sprung". Veröffentlichungen von Spielen für Mac OS X und Linux sollten so wesentlich häufiger geschehen als bisher.

Open-Source-Werkzeuge und Jahre an Entwicklung

Die Kollaboration der beteiligten Unternehmen ist aber nicht nur auf das Erstellen einer neuen Spezifikation beschränkt. Ekstrand zufolge öffne sich die gesamte Industrie den Open-Source-Ideen und setze diese auch aktiv um.

Um etwa Treiber offiziell auf die Konformität zu der OpenGL-Spezifikation testen zu können, sind diverse rechtliche und finanzielle Voraussetzungen zu erfüllen. Für die freien Linux-Grafiktreiber ist dies allerdings nicht umsetzbar, so dass sich die Linux-Hacker mit Piglit ein eigenes Werkzeug dafür schreiben mussten, das laut Ekstrand aber einige Probleme habe.

Für Vulkan werde aber eine Konformität-Testsuite von der Khronos-Gruppe als Open Source bereitgestellt, versichert Ekstrand. Damit können auch die Entwickler der freien Treiber diese problemlos testen.

Offenlegung von Werkzeugen und Treibern geplant

Sowohl Intel als auch AMD haben bereits angekündigt, ihre Vulkan-Treiber für Linux offenzulegen, was bei beiden Unternehmen keine echte Überraschung ist. Immerhin pflegen beide schon jetzt freie Treiber für Linux.

Darüber hinaus sollen aber auch verschiedene Werkzeuge für die Arbeit mit Vulkan als Open Source zur Verfügung gestellt werden. Khronos selbst hat bereits einen Compiler veröffentlicht, mit dem GLSL-Shader in SPIR-V überführt werden. Letztere ist eine Zwischensprache, die üblicherweise in Binärform ausgetauscht wird und Teil des aktuellen OpenCL 2.1 sowie von Vulkan selbst ist.

Die in Zusammenarbeit mit Valve bei dem Grafikspezialisten LunarG entstandenen Werkzeuge zum Debuggen der Anwendungen und Treiber sollen laut Ekstrand ebenfalls Open Source werden. Diese stehen vermutlich nur deshalb noch nicht bereit, weil die Vulkan-Spezifikation erst noch veröffentlicht werden muss.

Freiheiten und Probleme für Entwickler

Nicht nur die Werkzeuge, sondern auch Vulkan selbst gibt den Entwicklern künftig große Freiheiten bei ihrer Arbeit. Denn die Idee von Vulkan ist es, möglichst viel Zugriff auf die Grafikhardware zu bekommen. Beispielhaft sei hier erwähnt, dass Anwendungen die Speicherverwaltung auf der Grafikhardware selbst vornehmen.

OpenGL fühle sich für den Entwickler dagegen eher wie eine Blackbox an, sagt Ekstrand. Diese API sei auch ursprünglich so gestaltet worden, dass die Vorgänge auf der Hardware versteckt werden. Mit Vulkan kann aktiv eingegriffen werden.

Doch während OpenGL über eine eingebaute Validierung verfügt und falsche Aufforderungen schlicht nicht umsetzt, kann bei Vulkan theoretisch sehr viel kaputt gemacht werden. So könnten Speicherbereiche wieder freigegeben werden, obwohl noch ein Objekt auf die darin abgelegten Daten zugreift. Künftig wird es Aufgabe der Treiber sein, solche Fehler aufzuspüren und diese zu verhindern, was einige Schwierigkeiten für deren Programmierer bedeutet.

Noch offene Aufgaben

Wie Ekstrand zugeben muss, ist ein viel größeres Problem allerdings, dass bis jetzt nur Khronos-Mitglieder überhaupt Zugriff auf Vulkan haben. Das heißt: Außerhalb dieser klar abgegrenzten Gruppe hat noch niemand Zugriff auf diese Technik. Was auch eine vergleichsweise kleine verfügbare Dokumentation zum Zeitpunkt der Veröffentlichung zur Folge haben wird.

Die mehr als 20 Jahre Erfahrung und Austausch im Umgang mit OpenGL werden so schnell nicht aufzuholen sein. Erschwert wird ein schneller Einstieg vieler Interessierter wohl auch dadurch, dass Vulkan im Vergleich zu OpenGL zunächst viel schwerer zu erlernen sein soll. Statt Tage wie bei OpenGL werden wohl Wochen vergehen, bis Programmierer mit Hilfe von Vulkan einfache Formen auf ein Display zeichnen können.

Bis Vulkan abseits von Spielen zum Einsatz kommt, werden wohl noch einige Jahre vergehen. So müssen die Toolkits wie Qt oder GTK, die zum Erstellen von grafischen Anwendungen genutzt werden, um Vulkan-Unterstützung erweitert werden. Letztlich muss auch ein Weg gefunden werden, wie OpenGL und Vulkan parallel zueinander auf einem Rechner eingesetzt werden können. Laut Ekstrand arbeitet Nvidia inzwischen an einer möglichen Lösung dafür.

Nach den Toolkits werden wohl Basisbibliotheken und typische Middlelayer-Software nach und nach Vulkan nutzen können, so dass das Einsatzgebiet von Vulkan stetig wachsen wird. Da gibt sich Ekstrand sehr sicher. Er sagt aber auch: "OpenGL wird nicht einfach verschwinden".  (sg)


Verwandte Artikel:
Lennart Poettering: Systemd implementiert DNSSEC trotz Bedenken   
(31.01.2016, https://glm.io/118834 )
Open-Source-Unternehmen: Startups sterben, Nextcloud startet neu   
(05.02.2018, https://glm.io/132577 )
Grafikschnittstelle: Vulkan 1.1 unterstützt DRM und Multi-GPU   
(08.03.2018, https://glm.io/133208 )
Optane SSD 800p: Intel bringt 3D Xpoint in die Mittelklasse   
(08.03.2018, https://glm.io/133229 )
Linux: AMDs Vega mit freiem Treiber deutlich schneller   
(15.08.2017, https://glm.io/129481 )

© 1997–2019 Golem.de, https://www.golem.de/