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:

Administrativen Code, der als 'KGI manager' bezeichnet wird. dieser stellt hauptsächlich Mechanismen zum dynamischen Nachladen von Hardwaretreibern und der Verwaltung der virtuellen Konsolen bereit. Später kann dies noch erweitert werden um Hardwarekonflikte bei Mehrschirmlösungen aufzulösen, aber dazu benötigt Linux eine richtige Ressourcenverwaltung. Im Moment ist diese nur in minimalster Funktionalität vorhanden obwohl sie eigentlich -- nicht nur für GGI -- dringend notwendig wäre.
die Bootdisplaytreiber, die minimalen Hardwaresupport bereitstellen, um die Ausgabe von Kernel-Meldungen während dem Start zu ermöglichen. Dieser Code stellt ebenfalls Methoden für Ausgabe auf virtuelle Konsolen im 'Hintergrund' bereit.
den Konsole Treiber, der eine abstrakte Textausgabe implementiert. Diese Routinen werden von den Terminaltreibern benutzt um auf die Konsolen zu schreiben. Sobald ein eigener Terminalserver auf GGI implementiert werden kann ist dieser Code im Kern überflüssig, aber dazu sind umfassende änderungen im der Kernel-Boot Reihenfolge nötig.
evtl. optional der Grafikgeräte Treiber, der auch als Modul kompiliert werden kann. (siehe unten)
die Terminalemulatoren, die die Ausgabe von Applikationen auf ein Konsole TTY parsen und entsprechende Aktionen auslösen, wie z.B. Scrolling usw. Diese sind vollkommen unabhängig von der Ausgabehardware und könnten ebenfalls als Module geschrieben werden, aber im Moment gibt es wichtigere Dinge zu tun. Selbstverständlich kann jede Konsole ihren eigenen Terminalemulator, eigenen Videomodus, Farbpalette, Font usw. haben.

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:

der Grafik Gerätedatei Treiber, der die Kerneldienste bereitstellt um sicheren direkten Zugriff auf die Hardware für normale Applikationen zu erlauben. Das sind im wesentlichen die gerätespezifischen Operationen und die Routinen für schnelle Verwaltung von I/O-Speicherbereichen.
Treiber für die Grafikkarte(n) im System, welche das nötige 'Wissen' bereitstellen um undefinierte Hardwarezustände zu vermeiden bzw. zu beseitigen. Diese Treiber stellen auch Informationen bereit welche Teile der Hardware von Applikationen direkt genutzt werden können.
Treiber für die Eingabegeräte, welche Nutzeraktionen in Ereignisse umwandeln die an die Applikationen oder Terminalemulatoren weitergeleitet werden. Diese sind sehr einfach zu schreiben und ersetzen die bisherigen Treiber, z.B. für nicht-serielle Mäuse usw.

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:

richtig entworfene Hardware, die ein gute Programmierschnittstelle hat. Insbesondere vollständig einstellbare Hardware ressourcen, strikt voneinander getrennte kritische und nicht-kritische Register, so dass Applikationen einfach Zugriff auf nicht-kritische Register gewährt werden kann bzw. kritische Register vor unbeabsichtigtem oder unbefugten Zugriff geschützt werden können. Hier kann GGI nicht viel tun, dies ist aber unabhängig von GGI und wird sich sicher bessern.
direkter Zugriff auf die Hardware. Dies ist eine wichtige Voraussetzung für hohe Grafikleistung. Wann immer die Hardware dies sicher erlaubt, wird GGI direkt auf die Hardware zugreifen. Dazu ist intesive Hilfe durch die virtuelle Speicherverwaltung des Prozessors nötig und diese 'Art' der Verwendung ist bisher in Linux nicht implementiert, aber nicht nur für GGI sinnvoll.
effiziente Nutzung von Hardwarebeschleunigung ist nötig um eine gute Gesamtleistung des Systems zu erreichen. Das setzt voraus, daß Beschleuniger parallel zu den Hauptprozessoren eingesetzt werden und daß 'idle'-Zeiten so gering wie möglich gehalten werden. Moderne Grafikbeschleuniger unterstützen Kommandopuffer und Interuptgenerierung bei 'Puffer-leer' Situationen. Diese Eigenschaften können unter Linux bisher nicht genutzt werden, da hier Kernelunterstützung nötig ist. Das bisherige Design ist aber konzeptionell nicht in der Lage diese zu bieten. GGI kann und wird dies einfach unterstützen, da der Kernelteil intensiven Gebrauch aller erweiterten Möglichkeiten der Karte machen kann. Allerdings bedarf die Speicherverwaltung des Kerns noch einiger Änderungen bevor auch DMA sinnvoll unterstütz werden kann. Die Verwendung von DMA auf neueren Karten ist mit den bisherigen Konzepten nicht möglich oder sogar höchst gefährlich.
transparente Nutzung von Beschleunigerfunktionen, zumindest aus der Sicht von Applikaitonen ist nötig um Applikationen Platformunabhängig zu halten. Die Bibliothek wird volle Funktionalität nur mit einem linearem Framebuffer bieten können, aber auch das automatische Nachladen von auf die speziellen Karten optimierten Treibern erlauben. So müssen Hardwarehersteller nur für ihre Karte optimierte Treiber bereitstellen, nicht komplette Applikationen. Ein weiterer Vorteil ist, daß automatisch alle Applikationen von einem Treiberupdate profitieren, nicht nur SVGAlib oder XFree.
Das API darf die Verwendung kartenspezifischer Funktionen und direkten Zugriff auf die Hardware nicht konzeptionell unmöglich machen. Neue Applikationen wie z.B. Spiele, Videoplayer, 3D Bibliotheken oder was auch immer können und werden Optimierungen auf niedrigerer Ebene benötigen als existierende Standards, z.B. das X Protokoll, erlauben. Diese Möglichkeit erlaubt nicht nur atemberaubende Spiele, sondern auch die Entwicklung neuer Benutzeroberflächen, Eingabehardware oder Hardwaretechnologie.

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.