Anforderungen an ein zukünftiges Grafik-Terminal:

Bit-Slice-Hardware ist ein möglicher Weg

17.10.1986

Die Anforderungen an ein durchschnittlich teures Grafik-Terminal (Preisklasse 20000 bis 50000 Mark) versuchen Ivan Hermann und Uwe Schüle von der Insotec Consult, München, zu definieren. Implementationsprobleme behandeln die Autoren nicht. Diese Anforderungsspezifikationen sollen nur als grober Rahmen dessen angesehen werden, was ein durchschnittlicher Käufer bei diesen Preisen erwarten kann und was, basierend auf dem gegenwärtigen Wissensstand, realisierbar ist.

Es ist heute eine selbstverständliche Forderung, daß bei der Definition der Basis-Grafik-Funktionalität eines Terminals anstelle eines selbstdefinierten Satzes von Grafikfunktionen die Implementation eines bereits existierenden Standards vorgenommen wird. Gegenwärtig gibt es zwei Kandidaten, die hierfür in Frage kommen, nämlich CGI und GKS.

CGI (Computer Graphics Interface) ist ein in der Entwicklung befindlicher ISO-Standard, dessen Ziel es ist, die Grafik-Schnittstelle von Grafikgeräten zu definieren (zum Beispiel eines Terminals). Die Autoren glauben jedoch, daß die Funktionalitätsebene für den obengenannten Preis wesentlich höher sein sollte als die die durch CGI definiert wird. Darum sollten die Standardfunktionen dieses Grafik-Terminals um GKS konzentriert sein.

GKS ist ein internationaler Standard für zweidimensionale Grafiken. Die durch GKS zur Verfügung gestellten Funktionen sind mehr oder weniger als übergeordnete Ebene von CGI zu betrachten. Diese Grafikschnittstelle ist unter Grafikanwendern bereits weitverbreitet und stellt deshalb einen natürlichen Bewerber dar, der als Grafik-Basisschnittstelle für ein gutes Terminal genutzt werden kann. Diese Idee ist natürlich nicht völlig neu.

Es sind bereits Terminals auf dem Markt, die diese Funktionalität bieten. Auch eine immer größere Zahl von Baugruppen- und Chip-Herstellern bietet GKS-Software entweder auf der Baugruppe (Grafik-Controller) oder als zusätzliche Software zur Unterstützung des Grafikprozessors an. Das Gawain-System für Controller, die auf dem AM95C60-Grafikprozessor von AMD basieren, stellt ein gutes Beispiel hierfür dar,

Die dritte Dimension

Der größte Nachteil von GKS ist, daß es nur ein 2D-Standard ist. Während dies für Anwendungen im Bereich der Geschäftsgrafik oder Elektronik-CAD ausreicht, wird die dritte Dimension für eine Reihe anderer Anwendungen benötigt. Glücklicherweise existiert bereits eine Erweiterung des GKS-Standards für dreidimensionale Anwendungen.

Obwohl diese Erweiterungen noch nicht zu einem ISO-Standard geworden sind, kann der technische Inhalt größtenteils als vollständig angesehen werden. Diese Spezifikation von Funktionen (GKS-3D genannt) ist eine Obermenge von GKS-2D. Alle zweidimensionalen GKS-Aufrufe stehen auch hier zur Verfügung, und alle Programme, die in einer 2D-GKS-Umgebung ablaufen können ohne Veränderung auch in einer 3D-GKS-Umgebung ablaufen, wobei derselbe visuelle Effekt erzielt wird.

Es ist deshalb ganz natürlich, die Funktionalität unseres Terminals durch das Einbeziehen der GKS-3D-Funktionen zuerweitern. Die Entscheidung, ein 3D-Paket in unserem Terminal zu implementieren, zieht natürlich, was das Hardware-Design anbelangt, schwerwiegende Folgen nach sich. So können beispielsweise einige zeitkritische Operationen durch Verwendung vonganzzahligen Werten in zweidimensionalen Anwendungen gelöst werden, die bei, dreidimensionalen Anwendungen durch Gleitkommazahlen gelöst werden sollten (zum Beispiel Teile des Clipping). Dies führt dazu, daß eine sehr gute Gleitkomma-Hardware notwendig wird.

Hidden Line und Shading

Obwohl das GKS-3D-Dokument existiert, ist es nicht sicher, daß seine einfachen dreidimensionalen Funktionen wirklich für eine gegebene Applikation ausreichen. Ein Hauptproblem stellt die Entwicklung eines realistischen Bildes durch den Benutzer dar, wobei Hidden-Line-/Surface-Techniken und/oder eine Art Shading-Technik verwendet werden. GKS-3D stellt Freiraum für Hidden-Line/Surface zur Verfügung. Es beinhaltet damit eine Kontrolle über sogenannte HLHSR-Methoden, bei der die exakten Algorithmen, die durchgeführt werden, nicht spezifiziert sind.

Andererseits wird nichts über Shading ausgesagt. Es ist jedoch eine Tatsache, daß eine Reihe von hochentwickelten Anwendungen, diese Techniken heute nutzen. Außerdem wird es oft als ganz natürlich angesehen, daß zum Beispiel mechanische CAD-Systeme ein realistisches Bild der gezeichneten Objekte zeigen. Andererseits werden die dreidimensionalen Möglichkeiten desTerminals mehr oder weniger nutzlos, wenn das kontrollierende, System diese Algorithmen selbst durchführen, also die ganze dreidimensionale Viewing-Pipeline selbst (durch den Host) rekonstruieren muß.

Daraus ergibt sich die Notwendigkeit, eine mögliche Lösung dieser Probleme im Terminal zu implementieren. Soweit es die Probleme der verdeckten Linien und Flächen (Hidden Line/Surface) betrifft, scheint die Verwirklichung eines Z-Puffer-Algorithmus die günstigste Lösung zu sein. Diese Methode führt in den, meisten praktischen Fällen zu guten. Resultaten und ist vor allem relativ einfach zu implementieren.

Für Shading ist ein einfaches Beleuchtungsmodell und ein Gouraud Shading für spezielle Polygone (in GKS-Terminologie: Fill Areas) notwendig. Da dieses Terminal nicht auf echte Animation abzielt, scheint eine höherentwickelte Shading-Methode (beispielsweise Phong-Shading) überflüssig zu sein. Mit Hilfe dieser Werkzeuge können jedoch ziemlich realistische Bilder für CAD oder chemische Anwendungen realisiert werden.

Ausgabe-Funktionen

Der Satz an Standard-Ausgabe-Funktionen (Output Primitives) von GKS und von GKS-3D ist relativ klein. Er besteht aus Polyline, Polymarker, Fill Area, Fill Area Sets (wobei die letzten zwei zur Definition von Fill Polygons beitragen), Text und Cell Array. Es liegt jedoch auf der Hand, daß ein komplexerer Satz an Ausgabe-Funktionen sehr nützlich wäre.

Die Generierung von Ausgabe-Funktionen, die stellenweise durch die Nutzung der gerätespezifischen Möglichkeitenermöglicht wird, dürfte die Generierungszeit von Objekten erheblich verkürzen (ohne die Tatsache zu berücksichtigen, daß hierdurch die zu transferierende Datenmenge zum Terminal viel kleiner wird). Die GKS-Spezifikation bietet eine gute Grundlage für diesen Zweck in Form von sogenannten GDPs (Generalized Drawing Primitives). Die Autoren glauben, daß es notwendig ist, die Funktionalität des Terminals auch in diesem Bereich auszudehnen.

Einige dieser zusätzlichen Funktionen sind relativ einfach. Es handelt sich dabei um Kreise und Ellipsen in Form von Kurven und gefüllten Bereichen; kreisförmige und elliptische Bögen ebenfalls in Form von Kurven und gefüllten Bereichen. Sogenannte Profiles können auch von Bedeutung sein; diese bestehen aus einem gefüllten Bereich, dessen Bereichsgrenzen durch Liniensegmente und kreisförmige Bögen gebildet werden.

Es kann auch ein großer Satz an Funktionen vorhanden sein, der auf einigen allgemein akzeptierten Kurven- und Flächennäherungs-Methoden basiert (kubische und B-Spline-Näherungen von Kurven, Tensor-Produkt-Flächen, Rotation und "Sweep" Surfaces etc.). Der Nutzen dieser Funktionen ist jedoch sehr fraglich. Tatsache ist, daß ein CAD-System, das am Hostabläuft, gezwungen sein könnte, diese Näherungen selbst zu entwickeln und die Daten in der eigenen Datenbasis als Teil der eigenen Modelling-Methode zu halten.

Außerdem ist der Satz an möglichen Algorithmen, der benutzt wird, sehr groß und ändert sich ständig, Selbstverständlichkönnen die benötigten Funktionen von der Natur der Anwendung selbst abhängen. Dennoch ist die Benutzung dieser Funktionen in zweifacher Hinsicht von Vorteil.

Zum einen kann ihre Generierung von Grund auf schneller sein als eine entsprechende Generierung am Modell, und der visuelle Effekt zusammen mit den lokalen Shading-Möglichkeiten kann viel ansprechender sein; zum anderen sind diese Funktionen in einigen einfachen Fällen sehr nützlich, was sie selbst anbelangt (so kann zum Beispiel die kubische Näherung eines Satzes von Punkten in einer Ebene oder einem Gitter aus Punkten im Raum als ein Werkzeug für die Darstellung großer Datenmengen dienen).

Unabhängig von Dimensionsproblemen besteht einer der wichtigsten Nachteile des GKS-Funktionssatzes in dem sehr einfachen Modell der Segmentverwaltung, das hier benutzt wird. Obwohl die Grafikinformation in GKS in Form von Segmenten gespeichert werden kann (das heißt im Terminal), können diese Segmente, wenn sie einmal kreiert worden sind, nicht mehr geändert werden, sie können sich nicht auf andere beziehen etc. Das bringt erhebliche Probleme mit sich, wenn beispielsweise ein interaktives Drafting-System realisiert werden soll.

Die Lösung dieses Problems besteht im Gebrauch von sogenannten Strukturen, die als eine vollendete Form von Segmenten angesehen werden können. Grafikinformation kann nicht nur gespeichert, sondern auch einzeln geändert und gelöscht werden; eine Struktur kann sich auf eine andere beziehen, wobei eine das Modell reflektiert, das betrachtet wird. Die Autoren glauben, daß es möglich ist, als eine weitere Funktionseinheit die strukturbehandelnden Möglichkeiten in diesem Terminal zu realisieren. Die Implementation von Strukturen ist von der Hardware abhängig.

Die exakte Wahl des Funktionssatzes, was die Strukturen anbelangt, ist zur Zeit noch nicht absolut klar. Ein alternativen Standard, PHIGS genannt, befindet sich in der Definitionsphase bei ISO; dieses System ähnelt GKS-3D, aber beinhaltet zusätzlich die Idee der Strukturen. Der größte Nachteil von PHIGS ist, daß er nicht mit GKS kompatibel ist (nicht einmal auf der zweidimensionalen Ebene). Dies kann zu großen Schwierigkeiten bei der Nutzung dieses Funktionssatzes führen.

Eingabe: Das Terminal soll die durch GKS definierten Eingabegeräte unterstützen. Hier kommen Geräte wie die Tastatur plus Funktionstasten, eine Maus und/oder ein Digitizer als nützliche Eingabewerkzeuge in Frage.

Hardcopy: Eine Möglichkeit, den aktuellen Bildinhalt in Form einer Hardcopy auf einem grafikfähigen Drucker ausgeben zu können, sollte ebenfalls von dem Terminal zur Verfügung gestellt werden.

Lokales Betriebssystem: Wichtig ist auch die Entscheidung, ob das Terminal ein eigenes Betriebssystem haben soll oder nicht, anders ausgedrückt, ob das Terminal auch alleine arbeiten kann. Grundsätzlich lautet die Antwort: Ja. Obwohl die Maschine hauptsächlich als Terminal genutzt werden soll, kann ihr lokaler Gebrauch in einigen Fällen sehr hilfreich sein.

Auch eine lokale Winchester oder eine Floppy-Disk gehören zur Konfiguration und sollten durch einen der Hauptprozessoren erreichbar sein. Das Betriebssystem selbst sollte ein Unix-System sein, das zum De-facto-Standard der 32-Bit-Mikro-Welt wird. Es muß jedoch erwähnt werden, daß die Konfiguration nicht zum Ziel hat, hauptsächlich im Lokalmodus zu arbeiten; es sollte deshalb eher als ein Gerät betrachtet werden, das zur Lösung dieses Problems beiträgt.

Pool von Prozessoren

Die Spezifikation des Funktionsumfangs dieses Terminals hat ernsthafte Folgen für das Design der Terminal-Hardware. Die wohl beste Methode, eine leistungsfähige Hardware zu realisieren, ist der Einsatz eines Pools von Prozessoren der in einer Pipeline-Architektur arbeitet. Auf diese Weise können die GDP-Generierung und Segmentverwaltung, die Viewing-Pipeline und das Clipping unabhängig behandelt werden. Ein sehr großer Speicher ist für die Behandlung der Strukturen ebenso wie für den Z-Puffer notwendig.

Unglücklicherweise ist ein konventioneller Grafikprozessor zum einen wegen des Z-Puffers und zum anderen wegen des Shading nicht nutzbar. Der Einsatz von Bit-Slice-Hardware als Grafikprozessor erscheint dagegen als ein möglicher Weg für die Realisierung eines Controllers.