Für Wayland-Unterstützung: Linux-Team von Nvidia arbeitet an einheitlichem Speicher-API
Noch ist die Wayland-Unterstützung im proprietären Nvidia-Treiber eine Eigenlösung - doch das Team will das ändern und dabei auch gleich mit der Community die Probleme von Google und anderen lösen. Erste Arbeiten dazu gibt es auf Github.
Um einen Wayland-Compositor auch mit dem proprietären Nvidia-Treiber einsetzen zu können, muss dieser speziell angepasst werden, da Nvidia hierfür eine Eigenlösung erstellt hat. Dies stieß bei der Entwicklercommunity der freien Linux-Treiber zunächst auf große Ablehnung. Gelöst werden sollte dieser Zwiespalt durch eine Diskussion, die vom Intel-Angestellten Martin Peres angestoßen wurde und auf der X.org Developers Conference (XDC) vor knapp zwei Wochen auf sehr großes Interesse stieß. Erste Lösungsansätze dazu hat der Nvidia-Angestellte James Jones auf Github veröffentlicht.
Zuweisung und Verwaltung von Speicher ist unterschiedlich
Anders als für die freien Treiber nutzt Nvidia nicht den in der Userspace-Bibliothek Mesa enthaltenen Generic Buffer Manager (GBM), welcher Buffer zwischen Wayland-Client und -Compositor verwaltet. Stattdessen setzt Nvidia dafür auf die Verwendung von EGL-Erweiterungen, den sogenannten EGL-Streams. Letzteres erzwingt die Veränderungen an einem Compositor.
Auf der XDC stellte Jones in einem ausführlichen Vortrag die Ansätze sowie Vor- und Nachteile dieser Lösungen vor. Allerdings konzentrierte sich Jones dabei nicht nur auf GBM und EGL-Streams, sondern zählte auch weitere Möglichkeiten auf, Speicher für die Buffer zuzuweisen und zu verwalten. Die bekannteste und wohl am weitesten verbreitete ist wohl Gralloc, das Google in Android einsetzt. Ebenso bietet das Grafik-API Vulkan einige Fähigkeiten für diesen Zweck.
Arbeiten an einheitlichem API begonnen
An der Diskussion auf der XDC haben etwa 20 Personen von verschiedenen Unternehmen und Projekten teilgenommen, um eine hoffentlich einvernehmliche Lösung zu finden, die künftig von allen genutzt werden könnte. Die Diskussion bildete laut Jones den Beginn eines "Design-Vorschlags für eine Bibliothek, die als geräte- und prozessübergreifender Allocator für Surfaces dienen kann", wie er in der Ankündigungsmail schreibt. Als Surfaces werden die darzustellenden Inhalte bezeichnet, und diese werden in einem Buffer gespeichert.
Die Notizen der Diskussion hat Jones zu einem konkreten Vorschlag zusammengefasst, der das geplante Design beschreibt, wobei die Bibliothek als Schnittstelle sowohl für Anwendungen wie die Compositoren wie auch für Treiberbackends dienen soll. Zusätzlich zur eigentlichen Dokumentation hat Jones auch eine noch nicht einsetzbare Header-Datei erstellt, die die geplanten Methoden und Schnittstellen in C-Code annäherungsweise darstellen soll.
Jones weist explizit darauf hin, dass weder der Code noch das Design zurzeit abgeschlossen seien. Interessierte werden jedoch dazu aufgefordert, an dem neuen Projekt teilzunehmen.
Oder nutzen Sie das Golem-pur-Angebot
und lesen Golem.de
- ohne Werbung
- mit ausgeschaltetem Javascript
- mit RSS-Volltext-Feed
