Linux-Kongreß97


Das 'General Graphics Interface'

Steffen Seeger
Institut für Physik
Technische Universität Chemnitz-Zwickau

and

Andreas Beck
Fakultät für Physik
Universität Düsseldorf

Unser Vortrag soll eine Einführung in die Konzepte und Ideen hinter dem 'General Graphics Interface Project' geben. Das Hauptziel unseres Projektes ist die Implementierung einer sicheren, schnellen und einfach zu handhabenden Programmier-Schnittstelle für Geräte zur Mensch-Maschine Interaktion und leistungsfähiger Grafikhardware unter Unix-ähnlichen Betriebssystemen. Im Gegensatz zum aktuellen Design der Interaktion mit Linux ist GGI vollständig Nutzerorientiert und wesentlich leistungsfähiger in Bezug auf Sicherheit und Portabilität. Es erlaubt normalen Applikationen den direkten Zugriff auf die vorhandene Grafikhardware wann immer das vernünftig möglich ist. Ebenso werden die effiziente Nutzung von Beschleunigerfunktionen und sinnvolle Mehrschirm-Lösungen möglich.

In unserem Vortrag möchten wir darlegen, warum wir der Auffassung sind, daß GGI neue Einsatzmöglichkeiten für Linux erschließen wird und die nötigen änderungen am Kernel begründen. Dies wurde bereits in den Entwicklungsforen diskutiert und wir stellen oft fest, daß die grundsätzlichen Ideen, welche entscheidende Voraussetzungen für die Entwicklung leistungsfähiger Grafiksysteme sind, nicht bekannt sind oder falsch verstanden werden.

Wir hoffen neben dem Überblick über GGI auch erste Bechmarkergebnisse geben zu können, die zeigen, daß GGI auch in Bezug auf die erzielbare Grafikleistung vergleichbar zum bisherigen Design ist.

1. Motivation

Linux erfreut sich immer mehr wachsender Beliebtheit, vor allem weil es einige Vorteile gegenüber anderen Systemen bietet. Diese sind den Autoren bestens bekannt, sollen hier aber nicht behandelt werden. Besonders im Bereich der Unterstützung von Grafikhardware und Eingabegeräten fehlen Linux bestimmte grundlegende Eigenschaften die in modernen Betriebssystemen zu finden sind. Vor noch nicht allzu langer Zeit war der sinnvolle Einsatz Unix-ähnlicher Betriebssysteme an speziell dafür entwickelte Hardware gebunden. Linux unterscheidet sich hier von traditionellen Unix-Varianten grundsätzlich, da es besonders im Bereich von Grafikhardware eine grosse Anzahl verschiedener Hardware zu unterstützen gilt. Dadurch sind herkömmliche Konzepte für das Design z.B. der Grafikunterstützung nicht unbedingt die besten Lösungen für Linux. Abgesehen davon hat die aktuelle Implementierung der Ansteuerung von Grafikkarten einige wohlbekannte Nachteile und konzeptionelle Schwächen, die Probleme in Bezug auf Stabilität, Sicherheit und Leistung des Systems verursachen. Das GGI Projekt versucht eine Lösung zu finden, die einen sicheren, schnellen und einfach zu handhabenden Zugriff auf Hardware für die Mensch-Maschine Interaktion bietet.

Es kann nicht oft genug betont werden, daß das 'General Graphics Interface' nicht 'noch irgendein Grafik API' ist, sondern eher ein für Linux neues Konzept wie der Zugriff auf nutzerbezogene Hardware implementiert wird. Viele der von GGI verwendeten Prinzipien bilden die Grundlage für hohe Grafikleistung und sind bei Herstellern von Hochleistungssystemen bestens bekannt und werden dort bereits seit Jahren angewendet. Im Gegensatz zu den Systemen die Linux unterstützen muß, sind diese Hochleistungssysteme jedoch in enger Zusammenarbeit von Hard- und Softwareingenieuren entworfen worden.

2. Grundlegende Konzepte

Die grundlegende Regel bei der Entwicklung von GGI ist, daß Maschinen für Menschen gebaut wurden und nicht umgekehrt. Da moderne Betriebssysteme mehrbenutzer- und multitaskingfähig sind ergibt sich die Anforderung, daß GGI die gleichzeitige interaktive Benutzung eines Computers durch mehrere Nutzer konzeptionell nicht verbieten sollte. Hier ist nicht die 'remote' Nutzung über Netzwerke gemeint, sondern die Nutzung über zwei Konsolen, die im Moment in Linux nicht einfach realisiert werden kann. Das ist kein Problem der Hardware, da diese Mehrschirmlösungen und mehrere Eingabegeräte problemlos unterstützt. Mit GGI ist das problemlos möglich, da eine Konsole als ein Paar mit einem Eingabegerät und mindestens einem Ausgabegerät definiert wird und eine praktisch beliebige Anzahl an Ein- und Ausgabegeräten unterstützt wird. Die zweite Regel ist, daß eine Grafikschnittstelle sicher und fehlertolerant implementiert werden sollte. Das schließt ein, daß -- außer in wirklich extremen Fällen wie Systemkonfiguration und -wartung -- die Betriebsfähigkeit des Systems nicht durch fehlerhafte oder 'boshafte' Applikationen eingeschränkt werden sollte. Im Moment können Linux-Applikationen das System in einen Zustand versetzen, von dem man nur durch Ausschalten und Neustart wieder zu einem arbeitsfähigem System kommen kann. Ob ein Programmierfehler, falsche Anwendung oder Mißbrauch eines Programms zu diesem Zustand geführt haben ist für den Anwender dabei nebensächlich. Weiterhin sollte ein modernes Betriebsystem die Privatsphäre seiner Nutzer und 'seiner selbst' sicherstellen können. Wenn einer Applikation uneingeschränkter Zugriff auf das gesamte System gegeben werden muß, nur weil sie direkten Zugriff auf die Grafikhardware benötigt, beeinträchtigt das die Systemsicherheit erheblich. Ein weiteres Problem bereitet die Tatsache, das Linux sich auf Applikationen verläßt um den Zustand der Hardware wiederherzustellen. Das mag akzeptabel sein für singletasking Systeme, aber es ist eine sehr schlechte Idee für multitasking Umgebungen. Verschiedene Hardwaretreiber, wie z.B. SVGAlib und XFree Server, können die Hardware leicht in einem undefinierten Zustand versetzen, was in der Tat auch häufig beobachtet wird. Um diese Probleme zu lösen benötigt GGI Kernel-Unterstützung, der für nahezu jede andere Hardware als 'Stand der Technik' akzeptiert ist. Die dritte Regel ist, daß jede Maschine einfach zu handhaben sein sollte und nicht tiefes Verständniss der internen Vorgänge für den alltäglichen Gebrauch erfordert. Diese Forderung kann aufgehoben werden für Systemkonfiguration und Systemwartung, aber da auf PC's der Systemadministrator meistens auch gleichzeitig der Nutzer ist, sollte dies auch dort gelten. GGI versucht dies zu lösen, indem es dem Nutzer mißbräuchliche Nutzung der Hardware verbietet. Dadurch werden undefinierte Systemzustände vermieden, die die Betriebsfähigkeit beeinträchtigen oder gar die Hardware beschädigen könnten. Letztlich sollte die Ansteuerung jeder Hardware in einer effizienten Art und Weise implementiert werden, wobei alle Möglichkeiten der Hardware unterstützt werden. 'Effizienz' bezeichnet dabei nicht nur die Leistung die erreicht wird, sondern auch die Ressourcen die benötigt werden um diese Implementation zu erstellen und zu nutzen. GGI erlaubt effizient programmierte Hardwareunterstützung, da nur Treiber für die installierte Hardware vorhanden sein müssen, nicht für jede mögliche Hardware. Ebenso wird es möglich sein, daß Hardwarehersteller ihre aktuellen Produkte auch mit Treibern für Linux ausstatten können.

3. Implementation

Aufgrund der starken konzeptionellen Unterschiede, dem schlecht gewählten Aufbau des Konsole-Codes und der Hardwaretreiber in SVGAlib und XFree bei Projektstart hatten wir uns entschieden den Konsole-Code und die Displaytreiber mit einer komplett neu geschriebenen Implementation zu ersetzten. Wie auch immer, es wurde große Sorgfalt darauf gelegt, den Kernelteil von GGI so klein wie möglich zu halten und nur sicherheitskritische Teile des Hardwarezugriffs in den Kernel zu verlegen. Zusätzlich sind noch einige andere Komponenten im Kernel nötig um Kompatibilität zum bisherigen Konzept zu gewährleisten.

3.1 KGI - Das Kernel Graphics Interface

Der Kernelteil von GGI besteht im wesentlichen aus zwei Teilen, einem der notwendig in den Kern eincompiliert werden muß, und Modulen, die zur Laufzeit geladen werden und den Kern um die nötigen Hardwaretreiber ergänzen. Der feste Bestandteil des Kerns unterteilt sich dabei nochmals in:

Mit Außnahme des KGI-manager sind diese Dienste auch im aktuellen Linux-Kernel implementiert, obwohl diese sehr stark voneinander abhängig und nicht gerade ein Musterbeispiel strukturierter und portabler Programmierung sind. Der KGI-manager muss in den Kern compiliert werden, weil er sicherstellen muß, daß die Hardware nur mit dem Einverständnis der Displaytreiber direkt programmiert werden kann. Da der alte Code zu großen Teil ersetzt wird ist der Kernel nicht wesentlich größer. Eine Ausnahme bilden eventuell zusätzliche Terminalemulatoren, aber zusätzliche Funktionalität erfordert nun einmal meistens auch zusätzliche Software. Die Teile, die dynamisch nachgeladen werden können sind:

Ohne einen (boot)-Displaytreiber wird der KGI Code Zugriff auf ein Display verweigern. So ist sichergestellt, daß Applikationen nicht 'versehentlich' kritische Hardwareregister (z.B. für das Monitortiming) ändern können. Ebenso müssen Displaytreiber in der Lage sein, jederzeit einen neuen Modus zu setzen, so daß der Kern immer in der Lage ist einen definierten Zustand zu erzwingen. So kann immer eine Konsole initialisiert oder zurückgesetzt werden.

3.2 libGGI - Die Grafikbibliothek

Die Bibliothek implementiert die eigentliche Schnittstelle zu Applikationen, insbesondere die Zeichenoperationen. Die Bibliothek wird, wenn immer sicher und sinnvoll möglich, die Hardware direkt benutzen. Sie dient auch dazu hardwarespezifische Gegebenheiten von Applikationen zu isolieren. Trotzdem können hardwarespezifische Applikationen auch direkt mit dem Kerneltreiber kommunizieren, sind dann aber zumindest vom gegebenen Treiber abhängig. Das widerspricht nicht der 'Generalität' die GGI für sich in Anspruch nimmt, da eine allgemeine Programmierschnittstelle konzeptionell nicht die Nutzung besonderer Funktionen der Hardware weder verbieten noch erzwingen sollte -- ein Punkt den nur sehr wenige API's erfüllen. Hohe Grafikleistung und einfache Handhabung sind die Hauptziele für die Bibliothek, weshalb hier auch viel Optimierung nötig sein wird. Hochoptimierter Code ist aber nur eine Voraussetzung für gute Leistung, und es gibt andere die unter Linux mit dem aktuellen Design nicht erfüllt werden können. Wir werden nun eine (sicher unvollständige) Liste einiger dieser Faktoren geben und erklären wie GGI diese erfüllen kann:

4. Status und Zukunftspläne

Während der vergangenen Jahre der Entwicklung hat das GGI Projekt sich im wesentlichen auf die Entwicklung der Konzepte konzentriert, die jetzt implementiert werden. Die letzte 'offizielle' Version zeigte, daß das Hauptziel -- sicherer, einfacher und schneller Zugriff auf Grafikhardware -- erreicht werden kann. Sie hat auch gezeigt, daß Kompatibilitäts-Bibliotheken geschrieben werden können und das die Implementation eines X Servers auf GGI einfach möglich ist. Im Moment arbeiten wir an einer sauberen, portablen und erweiterbaren Neuimplementation der Bibliothek und der Grafikgerätetreiber. Die gesteckten Ziele Sicherheit, Stabliltät und einfache Handwabung werden einfach zu erreichen sein, und wir hoffen auf dem Linux-Kongress zeigen zu können, daß es auch unsere Erwartungen in Bezug auf die erreichbare Grafikleistung zumindest erfüllen wird. GGI bietet die Möglichkeit Applikationen zu entwickeln, die die gegebene Hardware optimal nutzen, ohne die Notwendigkeit der Vergabe von 'root' Rechten an die Applikation nur um Grafikhardware nutzen zu können. Es wird so die Entwicklung von neuen Nutzeroberflächen oder Spielen überhaupt erst möglich machen und Linux zu einer attraktiven Platform für Grafik-, Animations- und Spielesoftware machen. Um dies zu zeigen, arbeiten wir mit dem Berlin und GSDK Projekt zusammen.

5. Danksagung

Die Autoren möchten allen Menschen, die am GGI Projekt mitarbeiten, herzlich danken für ihre fortwährende Unterstützung. Insbesondere möchten wir danken (in alphabetischer Ordnung): Todd T. Fries, John M. Mecham, Jason McMullan, Jon M. Taylor, Irish und den vielen anderen Menschen von der GGI mailing-list. Bedanken möchten wir uns auch bei S3 Incorporated für die freundliche Unterstützung mit Dokumentation, bei der Stone Group Asia Pacific und bei der ELSA GmbH für die Unterstützung mit Hardware für die Entwicklung.