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.