DE3924774A1 - Datenverarbeitungsanlage fuer fenster-orientierte rastergraphik-systeme - Google Patents

Description

Die vorliegende Erfindung bezieht sich auf eine Datenverar­ beitungsanlage für fenster-orientierte Rastergraphik-Systeme gemäß dem Oberbegriff Anspruch 1 und beschreibt eine neuar­ tige Framebuffer-Architektur, die Rastergraphiksysteme mit integriertem Window-Management-System optimal unterstützt. Unter Frame wird der zeitliche Rahmen, in dem sich der Bildaufbau für die auf einem Monitor darzustellenden Bilder bzw. in einem Speicher abgelegten Informationen (auch die nicht dargestellten) abspielt, verstanden. Unter Framebuffer werden dann solche Speicher, die diese Frames speichern, verstanden, unter window = Fenster, Bild oder Bildaus­ schnitt.

Unter Nutzung moderner Video-Speicherbausteine können große Pixelmengen in dem Teil des Framebuffers, der die auf dem Monitor sichtbare Bildinformation enthält, unter Realzeit­ bedingung mit Bit-Block-Transfer-Funktionen (im nachfolgen­ den BitBlT) manipuliert und kopiert werden, ohne Rechenzeit des angeschlossenen Graphik- bzw. Renderingprozessors zu beanspruchen und ohne dessen evtl. gleichzeitige Zugriffe auf den Framebuffer zu verhindern.

Die technischen Anwendungsgebiete liegen in allen Bereichen, die direkt oder indirekt mit Computern graphische Ausgabe erzeugen.

Technische Anwendungsgebiete sind u.a.: Computergraphik, Computer bzw. Workstations mit graphischer Ausgabe, Rastergraphiksysteme, Dokumentengraphik, Computer­ animation, Visualisierung von Supercomputerdaten, Window­ orientierte Graphiksysteme, Multi-Media-Workstation.

Stand der Technik; Nachteile des Standes der Technik: Der Framebuffer eines Raster-Graphik-Systems enthält als zentralen Bestandteil den On-Screen-Speicher. In diesem sind alle Pixel gespeichert, die periodisch entsprechend der Bild­ wiederholrate zeilenweise ausgelesen und auf dem Monitor dargestellt werden (Screen-Refresh). Der hingegen in vielen Anwendungen erforderliche Off-Screen-Speicher trägt nicht direkt mit einem seriellen Pixelstrom zum Bildaufbau bei, sondern wird z.B. von Window-Management-Systemen als Zwi­ schenspeicher zum schnellen Restaurieren ehemals verdeckter Windows benutzt, dient zum Speichern von Textfonts oder ent­ hält Teilergebnisse eines Rendering-Prozesses, die vor ihrer Darstellung auf dem Monitor weiterer Verarbeitung bedürfen. Für die Realisierung des Off-Screen-Speichers werden auf­ grund der notwendigen Speichertiefe dynamische Speicher (DRAM) (Dynamic = Random-Access-Memory) verwendet.

Der On-Screen-Speicher wird mit Video-RAM-Chips (VRAM) auf­ gebaut, die in Erweiterung zu den DRAM-Chips mit jeweils einem weiteren seriellen Port (Ein- bzw. Ausgang) den zugriffsintensiven Screen-Refresh von den Schreib- und Lesezugriffen des Graphikprozessors zeitlich entkoppeln. Der Graphikprozessor trägt die mit entsprechenden Rendering- Algorithmen generierten Pixel über das RAM-Port unter der gewünschten Adresse in die Speichermatrix des VRAMs ein. Zusätzlich zu einem DRAM kann jedoch mit jeweils einem ge­ sonderten Adreßzugriff der gesamte Inhalt einer Matrixzeile in ein auf dem VRAM integriertes Serial Access Memory (SAM) geschrieben oder von dort geladen werden. Die im SAM gespei­ cherten Pixel können ab einer beliebigen Stelle (SAM-Start­ adresse) seriell über das SAM-Port ein- oder ausgelesen wer­ den.

Stand der Technik herkömmlicher Framebuffer-Architekturen ist die ausschließliche Nutzung der VRAM-Chips für den Screen-Refresh. Wie in Skizze 1 angedeutet, werden in kon­ ventionellen Framebuffer-Architekturen die SAM-Ports (meh­ rere Chips für die Farbtiefe notwendig, z.B. 3×8 bit = 24 bit) des On-Screen-Speichers ständig jeweils als Ausgang geschaltet und an die Digital-Analogwandler (D/A) geführt, die aus dem seriellen, binär codierten Pixelstrom (z.B. 3×8 bit) die analogen Rot-, Gelb-, Blau-Signale (RGB) für den Monitor erzeugen. Die Steuerung übernimmt das Video- Steuergerät (Video-Controller), indem es am Ende jeder dargestellten Bildschirmzeile den Adreßbus kurzzeitig vom Graphikprozessor trennt und selbst belegt, um die SAMs der VRAM-Chips mit den Pixelwerten der nächsten Bildzeile zu laden. Während des sichtbaren Anteils jeder Bildzeile generiert der Video-Controller den seriellen Takt SC (Serial Clock), mit dem der Pixelstrom aus den SAM-Ports den D/A-Wandlern zugeführt wird.

Der Nachteil der dem Stand der Technik entsprechenden Frame­ buffer-Architekturen ist darin begründet, daß die seriellen VRAM-Ports (SAM-Ports), obwohl sie bei modernen VRAM-Chips (z.B. 1 Mbit-VRAM) gegenüber den RAM-Ports eine 3- bis 6­ fach höhere Datentransferrate ermöglichen, nicht für eine schnellere Datenverarbeitung von dem angeschlossenen Pro­ zessor verwendet werden können, da sie ausschließlich für den Screen-Refresh genutzt werden.

Der Verlust der mit den SAM-Ports eigentlich möglichen Ge­ schwindigkeitssteigerung wirkt sich vor allem bei Systemen nachteilig aus, die häufig Bit-Block-Transfer-Operationen (BitBlT) verwenden (z.B. Window-Manager).

In konventionellen Framebuffer-Architekturen hingegen muß der Graphikprozessor BitBlT-Operationen mit Speicherzugrif­ fen über die langsameren RAM-Ports ausführen, da die SAM- Ports für den Screen-Refresh belegt sind. Der Nachteil der dadurch langsameren Speicherzugriffe wird in bestehenden Systemen oft durch eine möglichst hohe Parallelverarbeitung der Pixel kompensiert. Dies führt jedoch zwangsläufig zu aufwendigen und daher teuren Systemen, da alle Datenwege verbreitert und Speicherorganisationen mit höherer Chip- Anzahl gewählt werden müssen.

Window-orientierte Graphiksysteme verwenden die BitBlT- Operation auch, um es dem Benutzer zu ermöglichen, auf dem Bildschirm dargestellte Windows interaktiv in Realzeit zu verschieben. Graphiksysteme, die die herkömmliche BitBlT-Operation über die RAM-Ports der VRAM-Chips ausfüh­ ren, können oftmals keine Windows mit komplettem Inhalt in Realzeit verschieben. Sie bewegen interaktiv lediglich einen Window-Rahmen und füllen diesen mit dem Window-Inhalt erst nach Abschluß des interaktiven Verschiebe-Prozesses durch den Benutzer. Dies hat jedoch den Nachteil, daß das Window nicht relativ zu darin enthaltenen Details positioniert wer­ den kann. Verschiebt der Graphikprozessor Windows mit BitBlT-Opera daß wertvolle Rechenzeit des Prozessors für einfache Ko­ pieroperationen, die bei Nutzung der SAM-Ports auch ein Hardware-Steuerwerk mit geringem Aufwand ausführen könnte, verschwendet wird.

Aufgabe der Erfindung ist es, diese Nachteile zu vermeiden und insbesondere die Geschwindigkeit der Bearbeitung zu er­ höhen. Erfindungsgemäß geschieht dies durch die Datenverar­ beitungsanlage nach Anspruch 1; vorteilhafte Ausgestaltungen sind in den Unteransprüchen angegeben.

Die dieser Erfindung zugrundeliegende neue Framebuffer- Architektur ermöglicht erstmals, die seriellen VRAM-Ports (SAM-Ports) nicht nur für den Screen-Refresh zu verwenden, sondern auch deren gegenüber den RAM-Ports um den Faktor 3 bis 6 erhöhte Datentransferrate für beschleunigte BitBlT- Operationen zu nutzen. Obwohl dadurch teilweise die zum Bildaufbau auf dem Monitor benötigten Datenwege benutzt werden, können ohne Beanspruchung eines Graphikprozessors BitBlT-Operationen, bei denen das Pixelfeld eines Operanden und das Ergebnis-Pixelfeld im sichtbaren Teil des Framebuf­ fer-Speichers (On-Screen) liegen, ohne Störungen des gerade angezeigten Monitorbildes ausgeführt werden. Die Pixel des anderen Bit-BlT-Operanden können einer externen Quelle (z.B. Video), einer zweiten On-Screen-Speicherbank (Double Buffe­ ring) oder dem Off-Screen-Speicher, sofern dieser mit VRAM- Chips realisiert wird, entnommen werden.

Die Bit-BlT-Operation wird unabhängig von der Größe des da­ von betroffenen Pixelfeldes in einer konstanten Zeit, die zur Darstellung eines Vollbildes auf dem Monitor benötigt wird (1 Frame), durchgeführt. Die Änderung des Bildinhaltes auf dem Monitor erfolgt im darauffolgenden zweiten Frame. Die BitBlT-Zykluszeit entspricht somit der Dauer zweier Frames. Die Bildänderung erfolgt jedoch innerhalb eines Frames, so daß diese der Benutzer bei sehr großen Pixelfel­ dern als "schlagartig" wahrnimmt.

Window-orientierte Graphiksysteme mit einer auf dieser Er­ findung basierenden Framebuffer-Architektur erlauben dem Anwender, mehrere beliebig geformte Windows gleichzeitig interaktiv zu bewegen und relativ zum jeweiligen Inhalt zu positionieren. Da die dafür ständig notwendigen Kopiervor­ gänge der Windows jeweils nur die Zeit von zwei Frames be­ nötigen, werden sie, bei genügend kleinen Schritten, vom Benutzer als kontinuierliche Bewegung empfunden.

Eine weitere wesentliche Verbesserung der auf dieser Erfin­ dung beruhenden Framebuffer-Architektur ist die Ausführung von BitBlT- und Window-Kopier-Operationen über die seriellen Ports der VRAM-Chips gleichzeitig mit der Darstellung des aktuellen Bildes auf dem Monitor und parallel zu den vom angeschlossenen Graphikprozessor gerade zu bearbeitenden Graphikalgorithmen. Da der Graphikprozessor gegenüber her­ kömmlichen Systemen nicht mehr selbst aktiv die BitBlT- oder Kopier-Operation ausführt sondern lediglich anstößt, kann er für die gesamte Zeitdauer dieser Operation selbst auf die­ jenigen Speicher-Chips zurückgreifen, die von der jeweiligen Operation betroffen sind. Dies hat in vielen Anwendungsfäl­ len, in denen nicht auf das Ergebnis der BitBlT-Operation gewartet werden muß, den Vorteil, daß auch die Graphikalgo­ rithmen bereits parallel zu dem laufenden Bit-Block-Transfer (weiter)bearbeitet werden können, die ständigen Zugriff auf den Framebuffer verlangen.

Dieser Vorteil kommt z.B. stark in Window-Managment-Systemen zum Tragen. Möchte der Benutzer ein auf dem Monitor angezeig­ tes Window verschieben, kann der Graphikprozessor bereits den vom Window zuvor verdeckten Hintergrund restaurieren, während der Window-Inhalt automatisch an die Zielposition kopiert wird.

Da die BitBlT- oder Window-Kopier-Operation synchron mit dem Screen-Refresh abläuft, hängt deren Ausführungszeit direkt von der Bildwiederhol- bzw. horizontalen Zeilenablenkfre­ quenz des Monitors ab und ist damit von der Größe des zu bearbeitenden Pixelfeldes unabhängig. Enthält der Framebuf­ fer für jedes Pixel zusätzlich zu der Farbinformation noch weitere Masken-Bits, ist die Ausführungszeit der BitBlT- Operation bei Auswertung dieser Bits auch von der Form der Pixelfläche unabhängig. Dies ist ein weiterer Vorteil, da die nach dem Stand der Technik auf die RAM-Ports der VRAM- Chips angewendeten BitBlT-Operationen nur für rechteckige Pixelfelder definiert sind.

Framebuffer, die Window-Management-Systeme unterstützen, enthalten ohnehin solche zusätzlichen Masken-Bits in Form einer Window-Identifizierungsnummer (ID). Wird diese Zusatzinformation während einer Window-Kopier-Operation aus­ gewertet, können gleichzeitig mehrere Windows verschoben werden, d.h. deren Ausführungszeit ist auch unabhängig von der Anzahl der zu kopierenden Windows. Dies ist in Window- Management-Systemen von großem Vorteil, da dort oftmals eine Einheit aus mehreren verschieden großen Windows manipuliert werden muß.

Die Ausführungszeit einer BitBlT- oder Window-Kopier-Ope­ ration entspricht der Dauer eines Frames, d.h. der Zeit, in der ein Bild auf dem Monitor dargestellt wird. Exakt be­ rechnet sie sich aus der Anzahl der dargestellten Bildzeilen geteilt durch die horizontale Ablenkfrequenz. Die Wiederhol­ rate aufeinanderfolgender BitBlT-Operationen ist gleich der halben Bildwiederholrate. Mit üblichen Bildwiederholraten größer gleich 50 Hz kann die BitBlT-Operation somit externe Video- oder Fernsehbilder mit dem On-Screen-Speicherinhalt unter Realzeitbedingungen verknüpfen und das Ergebnis an beliebiger Stelle sowohl in den On-Screen-Speicher zurück­ schreiben als auch auf dem Monitor anzeigen.

Eine BitBlT-Operation verknüpft mit einer logischen Funktion zwei im Framebuffer gespeicherte gleich große rechteckige Pixelfelder miteinander und legt das Ergebnis-Pixelfeld wieder im Framebuffer ab. Da hierbei sehr viele Pixeldaten hintereinander gelesen und geschrieben werden, kann gerade diese serielle Pixelverarbeitung mit BitBlTs durch die Ver­ wendung der seriellen VRAM-Ports optimal unterstützt werden.

Im folgenden wird die Erfindung anhand der Skizzen 2-4 erläutert.

Die Grundidee der in dieser Erfindung beschriebenen Frame­ buffer-Architektur beruht auf der Tatsache, daß alle im On-Screen-Bereich gespeicherten Pixel, die mit BitBlT- oder Window-Kopier-Operationen manipuliert werden sollen, ohne­ hin zeilenweise an den seriellen VRAM-Ports ausgegeben werden, um sie auf dem Bildschirm darstellen zu können. Der serielle Pixelstrom läßt sich zusätzlich zu den D/A-Wandlern auch zu einer logischen Einheit 4 leiten, dort pixelseriell verarbeiten und in einem weiteren mit VRAM-Chips aufgebauten Speicher ab der geforderten Zieladresse einschreiben. Um die Operationen auf vom Benutzer vorgegebene Pixelfelder zu begrenzen, müssen die seriell verarbeiteten Pixel selektiv in den Zielspeicher eingetragen werden, d. h. sie dürfen nur dann eingeschrieben werden, wenn sie aus Pixeln des abgegrenzten Pixelfeldes erzeugt wurden. Auf diese Weise lassen sich beliebige Pixel des On-Screen-Speichers unter Benutzung der bereits vorhandenen seriellen Datenwege zu den D/A- Wandlern bearbeiten, ohne die Random-Access-Ports der On-Screen-VRAM- Chips zu benötigen und ohne den Screen-Refresh zu stören.

Skizze 2 verdeutlicht mit einem Blockdiagramm die Framebuffer-Architektur dieser Erfindung, in dem zur Vereinfachung nur die in diesem Zusammenhang wichtigen Datenpfade eingezeichnet sind. Es enthält in Erweiterung zu der in Skizze 1 dargestellten konventionellen Framebuffer-Architektur vier weitere Blöcke.

Eine BitBlT-Operation benötigt definitionsgemäß zwei Pixel-Quellen und einen Zielspeicher, in dem das Ergebnis abgelegt wird. Eine Quelle ist der On-Screen- Speicher, dessen Pixel ja manipuliert werden sollen. Die 2. BitBlT-Quelle stellt ein weiterer Speicher 3 dar, der in gleicher Weise wie der On-Screen-Speicher mit VRAM-Chips aufgebaut wird. Diese kann eine externe Quelle (z. B. Videobild) sein, aus dem in vielen Systemen für Computer-Animationen benötigten Double-Buffer stammen oder einem Teil des Off-Screen-Speichers entnommen werden, sofern dieser mit VRAM-Chips aufgebaut ist.

Eine logische Einheit 4 führt die gewünschte BitBlT-Operation durch, indem sie die Pixel aus dem On-Screen-Speicher und der 2. BitBlT-Quelle seriell verknüpft und in den Zielspeicher einträgt.

Der Zielspeicher, ebenfalls mit VRAM-Chips realisiert, ist in Skizze 2 mit Display-Speicher bezeichnet, da er nicht nur die mit der BitBlT-Operation modifizierten Pixel sammelt, sondern daraufhin diese auch für die Dauer eines Bildes auf dem Monitor darstellt (s. u.).

Der vierte neue in Skizze 2 eingezeichnete Block ist mit X-Switch bezeichnet und symbolisiert einen Kreuzschienen-Verteiler. Dieser kann von jedem beliebigen der an ihn angeschlossenen drei Datenpfade Pixel einlesen und an einen oder zwei der beiden übrigen Datenpfade verteilen. Die gewünschte Konfiguration kann über Steuerleitungen (in Skizze 2 nicht eingezeichnet) eingestellt werden.

Solange keine BitBlT-Operationen ausgeführt werden, gelangen die zeilenweise aus dem On-Screen-Speicher ausgelesenen Pixel zur Darstellung auf dem Monitor über den X-Switch an die D/A-Wandler und gleichzeitig zu den jeweils auf Eingang geschalteten SAM-Ports des Display-Speichers. Die Ausgänge der logischen Verknüpfungseinheit sind in dieser Phase abgeschaltet. Dadurch kann das jeweils aktuelle Bild parallel zu dessen Darstellung zeilenweise in den Display-Speicher eingelesen werden. Die auf diese Weise gewonnene Kopie des On-Screen-Speichers ist eine notwendige Voraussetzung für die im folgenden beschriebene BitBlT-Operation:

Die gewünschte BitBlT-Operation wird mit dem Beginn des nächsten Bildaufbaus gestartet. Während der Dauer dieses ersten Frames der Operation werden die Ausgänge der logischen Einheit aktiviert und die damit ebenfalls verbundenen X-Switch-Ports abgeschaltet. Dadurch können (wie zu Anfang dieses Kapitels beschrieben) die Pixel aus dem On-Screen-Speicher mit denen der 2. BitBlT-Quelle modifiziert und selektiv in den Display-Speicher ab der gewünschten Startadresse eingetragen werden. Die geeignete Wahl der Startadresse legt den Ort fest, an dem die durch die BitBlT-Funktion bearbeiteten Pixel danach auf dem Monitor dargestellt werden. Da die Kopie des zuvor im Display-Speicher abgelegten Bildes nur selektiv mit den modifizierten Pixeln überschrieben wird, enthält der Display-Speicher bereits nach einem Frame das neue Gesamtbild. Das selektive Überschreiben muß ein Steuerwerk durchführen, indem es z. B. im On-Screen-Bereich pro Pixel zusätzlich gespeicherte Masken-Bits auswertet. Für die Dauer dieses ersten Frames liefert der On-Screen-Speicher die Bildinformation, so daß die Änderung durch die BitBlT-Operation auf dem Monitor noch nicht zu sehen ist.

Während des zweiten Frames der BitBlT-Operation werden die SAM-Ports des Display-Speichers jeweils auf Ausgang und die des On-Screen-Speichers jeweils auf Eingang gestellt. Die logische Einheit schaltet ihre Ausgänge ab, der X- Switch leitet den Pixelstrom aus dem Display- zum On-Screen-Speicher und zu den D/A-Wandlern. Dadurch wird das geänderte Bild (erstmals) auf dem Monitor dargestellt und gleichzeitig in den On-Screen-Speicher zurückgeschrieben. Die im On-Screen-Bereich des Framebuffers geforderte BitBlT-Operation ist somit ausgeführt und die Voraussetzung gleicher Inhalte von On-Screen- und Display-Speicher für die nächste Operation erfüllt.

Kennzeichnend für die in dieser neuen Framebuffer-Architektur durchgeführten BitBlT-Operation sind drei Eigenschaften:

• 1. Sie bedarf zu ihrer Ausführung weder eines Prozessors, noch arbeitet sie mit den Random-Access-Ports (RAM-Ports) des On-Screen-Speichers. Dadurch kann der daran angeschlossene Graphikprozessor parallel zu der BitBlT- Operation bereits die folgenden Graphikalgorithmen unter Benutzung der RAM-Ports bearbeiten.
• 2. Sie erfolgt synchron zur zeilenweisen Darstellung des Monitorbildes. Die benötigte Ausführungszeit ist damit nicht von der Anzahl der zu bearbeitenden Pixel sondern nur von der Horizontal- und Vertikalfrequenz des angeschlossenen Monitors abhängig.
  Ein für den heutigen Stand der Technik typischer hochauflösender Monitor, der 1280 × 1024 Pixel mit 70 Hz (flimmerfrei) darstellen kann, arbeitet mit ca. 75 kHz Zeilenablenkfrequenz. Diese Werte lassen sich unter der Annahme, daß eine BitBlT-Operation ein Drittel bzw. die Hälfte des Bildinhaltes bearbeitet, auf Pixel-Update-Raten von 31 MPixel/sec bzw. 48 MPixel/sec umrechnen. Die Bearbeitung des gesamten Bildes führt gar zu Pixel-Update- Raten von 96 MPixel/sec.
• 3. Der Graphikprozessor kann auf das Ergebnis einer BitBlT-Operation bereits nach einem Frame über die RAM-Ports des Display-Speichers zugreifen. Aufeinander folgende BitBlT-Operationen können alle 2 Frames neu gestartet werden.

Ausführungsbeispiel

Im folgenden werden die Vorgänge innerhalb eines auf dieser Erfindung basierenden Framebuffers detailierter beschrieben. Zur Vereinfachung wird jedoch die BitBlT-Operation auf den darin enthaltenen Spezialfall des Kopierens von Pixelflächen reduziert. Dieser ist in Rastergraphik-Systemen von großer Bedeutung, in denen ein Window-Manager unterstützt werden soll. In solchen Systemen müssen große Pixelmengen, die zusammen ein Window auf dem Bildschirm darstellen, als Folge von Benutzereingaben (z. B. Maus) in Realzeit verschoben werden. Hierfür ist die nur in dieser Framebuffer-Architektur mögliche Window-Kopier-Operation eine gute Anwendung. Deren Ablauf entspricht genau dem Ablauf der im vorigen Kapitel beschriebenen BitBlT-Operation mit der Ausnahme, daß die Pixel nicht modifiziert sondern nur kopiert werden.

Skizze 3 zeigt das gegenüber Skizze 2 weiter detailliertere Blockschaltbild. Die 2. BitBlT-Quelle und die logische Verknüpfungseinheit können für Window- Kopier-Operation entfallen. On-Screen- und Display-Speicher sind mit jeweils fünf Datenpfaden, von denen jeder aus jeweils einer der gewünschten Farbtiefe entsprechende Anzahl von Leitungen (z. B. 24) besteht, über den Kreuzschienen-Verteiler (X-Switch) miteinander und mit dem mit RAM-DAC bezeichneten Block verbunden. Beide Speicher bestehen daher jeweils aus fünf mit VRAM-Chips aufgebauten Bänken. Die Parallelisierung über fünf Datenpfade vereinfacht die Handhabung der bei hochauflösenden Rastersystemen (z. B. 1280 × 1024 Pixel) auftretenden hohen Pixelfrequenzen von über 100 MHz, da innerhalb jedes Datenpfades dann nur ein Fünftel der Pixelfrequenz verarbeitet werden muß. (DAC = D/A Controller = D/A Wandler u. Steuergerät)

Der RAM-DAC-Baustein liest aus den fünf anstehenden seriellen Pixelströmen zu jedem Zeitpunkt fünf Pixel parallel in ein internes Register ein und gibt diese mittels eines internen Multiplexers über ein ebenfalls intern vorhandenes Umsetz-RAM (für diese Beschreibung ohne Bedeutung) mit der fünffach höheren Pixelfrequenz an die integrierten D/A-Wandler weiter. Am Ausgang liefert der RAM-DAC-Baustein schließlich die für einen Farbmonitor benötigten drei R-, G-, B-Analogsignale.

Die Funktion des Kreuzschienen-Verteilers wird erst in diesem detaillierteren Schaltbild vollständig ersichtlich. In den fünf Bänken des On-Screen- und des Display-Speichers sind jeweils fünf auf dem Monitor hintereinander angezeigte Pixel abgelegt. Soll ein Window nicht um Vielfache von Fünf sondern z. B. nur um ein Pixel horizontal verschoben werden, müssen die Datenpfade von On- Screen- und Display-Speicher zyklisch um eins verschoben miteinander verbunden, die zu dem RAM-DAC-Baustein führenden Datenpfade jedoch direkt 1 : 1 an die des On-Screen-Speichers geschaltet werden. Dies kann nur ein programmierbarer X-Switch leisten.

Der Datenbus des Graphikprozessors ist direkt mit den RAM-Ports des Off- Screen-, des On-Screen- und des Display-Speichers verbunden. Der Adreßbus hingegen wird zum On-Screen- und Display-Speicher über einen Zweikanal- Multiplexer (MUX) geführt.

Der in Skizze 3 eingezeichnete Window-Copy-Controller steuert sowohl die normale Darstellung des im On-Screen-Speicher enthaltenen Bildes auf dem Monitor als auch die Window-Kopier-Operation. Zu diesem Zweck erhält dieser in jedem horizontalen Strahlrücklauf des Bildschirms über einen Zweikanal- Multiplexer Zugriff auf den Adreßbus des On-Screen- und des Display- Speichers, um die VRAM-Chips für die nächste Bildzeile mit der jeweils benötigten Datenrichtung und Startadresse für die Verarbeitung der Pixel über die seriellen Ports zu programmieren. Für die gesamte übrige Zeit erhält der Graphikprozessor Zugriff auf die beiden Adreßbusse. Weiterhin generiert der Window-Copy-Controller den Takt SC (Serial Clock), mit dem die Pixel in die SAM-Ports der VRAM-Chips ein- bzw. ausgelesen werden und steuert mit dem Signal SE (Serial Enable), ob die Pixel den Speicherinhalt überschreiben dürfen. Dadurch wird das für die Window-Kopier-Operation notwendige selektive Einschreiben in den Display-Speicher realisiert. Die dafür erforderliche Information gewinnt der Window-Copy-Controller aus der im On-Screen-Speicher zusätzlich zu jedem Pixel enthaltenen Window-ID (in Skizze 3 nicht eingezeichnet). Weitere Signale steuern den Zweikanal-Multiplexer, den RAM-DAC- Baustein und den Monitor (SYNC-Signale).

Der Ablauf der Window-Kopier-Operation und deren Anwendung soll im folgenden noch einmal anhand eines Beispiels mit den Skizzen 4.a bis 4.c erläutert werden. Die Skizzen zeigen jeweils die Inhalte des On-Screen- und des Display- Speichers und das zugehörige Monitorbild am Ende eines Frames, d. h. zum Zeitpunkt des vertikalen Strahlrücklaufs. In dem Beispiel sollen die Windows W1 und W2 von der linken oberen Bildschirmecke in Richtung der rechten unteren Ecke verschoben werden. Dabei liegt Window W2 über W1, und beide können ein drittes Window W3 und den restlichen Hintergrund verdecken.

Skizze 4.a zeigt die Ausgangssituation. Der Inhalt des On-Screen-Speichers erscheint auf dem Monitor und ist gleichzeitig in den Display-Speicher kopiert worden, um die Vorbedingung gleicher Inhalte vor einer Window-Kopier- Operation zu erfüllen.

Skizze 4.b zeigt die Situation am Ende des ersten Frames der Window-Kopier- Operation. Immer noch erscheint der On-Screen-Speicher-Inhalt auf dem Monitor, während die Windows W1 und W2 im Display-Speicher bereits selektiv an der Zielposition kopiert worden sind. Der serielle Datenstrom in den Display-Speicher wird durch zwei Parameter gesteuert. Die jedem Pixel zugeordnete Window-ID entscheidet, ob ein Pixel den Display-Speicher-Inhalt überschreiben soll. Der zweite Parameter ist die Startadresse des Display-Speichers, die aus einem vom Window-Manager vorgegebenen Verschiebe-Vektor berechnet wird.

Der Graphikprozessor hat während dieses ersten Frames bereits im Display- Speicher über dessen Random-Access-Ports die vom Window W1 an der ursprünglichen Position verdeckte Fläche restauriert. Der Inhalt des On-Screen- Speichers bleibt jedoch unverändert, da er in diesem ersten Frame als Quelle dient (s. Skizze 4.b).

Skizze 4.c zeigt die Situation am Ende des zweiten und letzten Frames der Window-Kopier-Operation. Der Inhalt des Display-Speichers ist ausgelesen, auf dem Monitor dargestellt und gleichzeitig vollständig in den On-Screen-Speicher zurückgeschrieben worden.

Die in Skizze 4.c dargestellte Situation setzt voraus, daß der Graphikprozessor während dieses zweiten Frames durch parallele Zugriffe auf den On-Screen- und Display-Speicher in beiden die vom Window W2 ehemals verdeckte Fläche restauriert hat. Der Prozessor muß parallel in beiden Speichern die Änderungen eintragen, damit am Ende der Kopier-Operation in beiden Speichern die gleiche Information steht. Greift der Prozessor auf Speicherzellen des On-Screen- Bereichs zu, die auch gerade über die SAM-Ports beschrieben werden sollen, wird dieser angehalten, bis die gesamte zugehörige Bildzeile in die Serial-Access- Memories (SAMs) der VRAM-Chips eingelesen und in deren Speichermatrix zurückgeschrieben worden sind.

Claims (6)

1. Datenverarbeitungsanlage für fensterorientierte Raster­ graphiksysteme mit einem Graphikprozessor, in dem gra­ phische Objekte verarbeitet und in eine Datenmenge überführt werden, und diese in einem On-Screen-Speicher gespeichert werden, und die gespeicherten Daten über einen D/A-Wandler auf einen Monitor gegeben werden, dadurch gekennzeichnet, daß zur schnelleren Datenübertragung von dem Graphik­ prozessor zu verarbeitende graphische Objekte, die be­ reits als Datenmenge vorliegen, von dem On-Screen-Spei­ cher nachgeschalteten Einrichtungen (1, 2, 3, 4) bearbeitbar sind.

2. Datenverarbeitungsanlage nach Anspruch 1, dadurch gekennzeichnet, daß, während ein erstes Bild von dem On-Screen-Speicher auf den Monitor eingelesen wird, von den Einrichtungen (1-4) das erste Bild bearbeitet und danach ein Zwischenbild erzeugt wird, das als zweites Bild auf den Monitor eingelesen wird und gleichzeitig in den On-Screen-Speicher zurückgeschrieben wird und dieses zweite Bild vom On-Screen-Speicher als drittes Bild auf den Monitor eingelesen wird.

3. Datenverarbeitungsanlage nach Anspruch 2, dadurch gekennzeichnet, daß der Graphikprozessor seinerseits noch das zweite Bild bearbeitet und dieses als drittes Bild auf den Monitor eingelesen wird.

4. Datenverarbeitungsanlage nach Anspruch 2, dadurch gekennzeichnet, daß von dem Graphikprozessor der Befehl für einen Ko­ piervorgang von Teilbildern an die Einrichtung 1 ge­ schaltet wird und die Kopie als Zwischenbild in dem Displayspeicher 2 zwischengespeichert und dann als zweites Bild auf den Monitor eingelesen wird.

5. Datenverarbeitungsanlage nach den Ansprüchen 1-2, dadurch gekennzeichnet, daß Bit-Block-Transfer-Operationen von der logischen Einheit 4 durch Verknüpfung von mindestens zwei Daten­ quellen (On-Screen-Speicher + 3) und Einschreibung in den Display-Speicher durchgeführt werden.

6. Datenverarbeitungsanlage nach den Ansprüchen 1-5, dadurch gekennzeichnet, daß ein Kreuzschienenverteiler (X-Switch) vorgesehen ist, der die Datenmengen auf die Datenpfade verteilt.