DE69028259T2

DE69028259T2 - Verfahren und Einrichtung zur Beschleunigung von Bildfenstern in graphischen Systemen

Info

Publication number: DE69028259T2
Application number: DE69028259T
Authority: DE
Inventors: Byron A Alcorn; Darel N Emmot; Ronald D Larson; David Pinedo; Desi Rhoden
Original assignee: Hewlett Packard Co
Current assignee: Hewlett Packard Development Co LP
Priority date: 1989-07-28
Filing date: 1990-07-27
Publication date: 1997-01-23
Anticipated expiration: 2010-07-28
Also published as: EP0617401A2; EP0410783B1; EP0617402B1; DE69033283D1; EP0617400B1; DE69033158T2; EP0617402A2; EP0617400A2; DE69033283T2; DE69028259D1; EP0617402A3; EP0617400A3; EP0617401A3; EP0410783A3; DE69033158D1; EP0410783A2

Description

Gebiet der Erfindung

Diese Erfindung bezieht sich auf Computer-Workstation-Fenstersysteme. Insbesondere bezieht sich diese Erfindung auf ein Verfahren und eine Vorrichtung zur Beschleunigung der Graphik-Grundelementaufbereitung auf Mehrprogrammbetrieb- Workstations, die Graphik-Pipelines verwenden.

Hintergrund der Erfindung

Computer-Workstations liefern Systembenutzern leistungsstarke Werkzeuge zur Unterstützung einer Anzahl von Funktionen. Ein Beispiel einer der nützlicheren Funktionen, die Workstations liefern, ist die Fähigkeit, hochdetaillierte Graphiksimulationen fur eine Vielzahl von Anwendungen durchzuführen. Graphiksimulationen sind besonders für Ingenieure und Entwickler nützlich, die rechnergestützte Entwurfs- (CAD; CAD = computer aided design) und rechnergestützte Verwaltungs- (CAM; CAM = computer aided management) Aufgaben durchführen.
Moderne Workstations weisen Graphikfähigkeiten auf, die "Fenster"-Systeme verwenden, um Graphikmanipulationen zu erreichen. Ein aufkommender Standard für Graphikfenstersysteme ist das "X"-Fenstersystem, das im Massachusetts Institute of Technology entwickelt wurde. Das X-Fenstersystem ist bei K. Akeley und T. Jermoluk, "High-Performance Polygon Rendering", Computer Graphics, 239 bis 246, (August 1988), beschrieben. Neuere Fenstersysteme in Graphik-Workstations müssen eine Vielzahl von Hochleistungsfenstern liefern, und noch ein hohes Maß an Benutzerinteraktivität mit der Workstation beibehalten. Früher wurden Softwarelösungen zum Liefern einer erhöhten Benutzerinteraktivität mit dem Fenstersystem in Graphik-Workstations implementiert. Jedoch tendieren Softwarelösungen, die die Benutzerinteraktivität mit dem System erhöhen, dazu, die Prozessor-Arbeitszeit zu erhöhen, wodurch die Zeit erhöht wird, in der Graphikaufbereitungen für den Bildschirm in der Workstation erreicht werden können.
Eine primäre Funktion von Fenstersystemen in Graphik-Workstations besteht darin, dem Benutzer einen gleichzeitigen Zugriff auf mehrere Prozesse auf der Workstation zu liefern. Jedoch schafft jeder dieser Prozesse durch seine eigene Fläche auf der Workstation-Anzeige eine Schnittstelle zu dem Benutzer. Das Gesamtergebnis ist eine Erhöhung der Benutzerproduktivität, da der Benutzer mit mehreren Fenstern mehr als eine Aufgabe auf einmal verwalten kann. Jedoch sieht jeder Prozeß, der einem Fenster zugeordnet ist, die Betriebsmittel der Workstation, als ob er der einzige Besitzer wäre. Folglich müssen die Betriebsmittel, beispielsweise die Verarbeitungseinheit, der Speicher, die Peripher- und Graphik- Hardware von diesen Prozessen auf eine Art und Weise gemeinsam verwendet werden, die Zwischenprozeßkonflikte auf der Workstation verhindert.
Graphik-Workstations verwenden allgemein Graphik-"Pipelines", die die verschiedenen Komponenten des Systems verbinden. Eine Graphik-Pipeline ist eine Reihe von Datenverarbeitungselementen, die Graphikbefehle durch das Graphiksystem leiten. Heutzutage entwickeln sich Graphik-Pipelines und Fenstersysteme dahingehend, daß sie Mehrprogrammbetrieb-Workstations unterstützen.
Die typische Graphik-Pipeline verbindet einen "Host"-Prozessor mit dem Graphiksystem, das die verschiedenen Graphikbefehle, die für das System verfügbar sind und die ferner eine Schnittstelle zu dem Benutzer bilden, liefert. Der Hostprozessor ist durch die Graphik-Pipeline schnittstellenmäßig mit einer "Transformationsmaschine" verbunden, die im allgemeinen eine Anzahl von parallelen Gleitkomma-Prozessoren aufweist. Die Transformationsmaschine führt eine Vielzahl von Systemaufgaben durch, einschließlich einer Kontext-Verwaltung, Matrix-Transformationsberechnungen, Lichtmodellierungs- und Effektivstrahlungs-Berechnungen und einer Steuerung der Vektor- und Polygon-Aufbereitungshardware.
Bei Graphiksystemen muß ein bestimmtes Schema implementiert sein, um Graphikgrundelemente für den Systembildschirm "aufzubereiten" oder auf denselben zu zeichnen. Ein "Graphikgrundelement" weist eine elementare Komponente eines Graphikbildes, beispielsweise ein Polygon oder einen Vektor, auf. Alle Graphikbilder sind aus Kombinationen dieser Graphikgrundelemente gebildet. Viele Schemata können verwendet werden, um eine Graphik-Grundelementaufbereitung durchzuführen. Ein solches Schema ist das "Spline-Mosaik"-Schema, das in den TURBO-SRX-Graphiksystemen von der Hewlett-Packard Company Graphics Technology Division, Fort Collins, Colorado, verwendet ist. Ungeachtet des Typs des Graphikaufbereitungsschemas, das durch die Graphik-Workstation verwendet wird, ist die Transformationsmaschine bei der Verwaltung der Graphikaufbereitung notwendig.
Ein Graphik-"Rahmenpuffer" ist dem Hostprozessor und der Transformationsmaschine in der Pipeline in dem Graphikfenstersystem schnittstellenmäßig nachgeschaltet. Ein "Rahmenpuffer" weist im allgemeinen eine Mehrzahl von Video-Direktzugriffsspeicher-Computerchips (VRAM; VRAM = video random access memory) auf, die Informationen speichern, die die Pixelaktivierung auf der Anzeige betreffen, die den speziellen Graphikgrundelementen, die auf dem Bildschirm aufbereitet werden, entspricht. Im allgemeinen enthält der Rahmenpuffer alle Daten-Graphikinformationen, die in die Fenster geschrieben werden, und speichert diese Informationen, bis das Graphiksystem vorbereitet ist, um diese Informationen auf dem Bildschirm der Workstation wiederzugeben. Der Rahmenpuffer ist im allgemeinen dynamisch und wird periodisch aufgefrischt, bis die Informationen, die in demselben gespeichert sind, auf dem Bildschirm wiedergegeben werden. Der Host und der Rahmenpuffer weisen zugeordnete Bandbreiten auf. Die Bandbreite ist ein Maß der Rate des Datenflusses über einen Datenweg.
Um mehrere Prozesse bei einem Graphiksystem zu beschleunigen, muß die Graphik-Pipeline in der Lage sein, mehrere "Kontexte" zu handhaben. Ein Graphikkontext besteht aus dem momentanen Satz von Attributen, dem Matrixstapel, den Lichtquellen, der Schattierungssteuerung, den Spline-Basismatrizen und anderen Hardwarezustands-Informationen. Frühere Graphiksysteme waren im allgemeinen nur in der Lage, einen einzelnen Graphikkontext zu einer Zeit zu unterstützen und benötigten die Host-Software, um das Schalten zwischen allen Kontexten durchzuführen. Bei diesen Systemen erfordert das Software-Kontextschalten, daß der Host den Kontext für jeden aktiven Prozeß in einem virtuellen Speicher speichert, den Kontext in das Gerät schreibt, wenn der Prozeß aktiv ist und den Kontext in das System zurückliest. Dieser Prozeß ist extrem zeitaufwendig und wenig effizient und unterstützt Hochpegel-Graphikoperationen in dem Graphiksystem nicht adäquat.
Mehrere Probleme existieren bei bekannten Graphikfenstersysternen, die Graphik-Pipelines verwenden. Eine wesentliche bekannte Schwierigkeit entsteht, wenn mehrere Kontexte durch die Pipeline geschaltet werden müssen. Immer wenn ein Fensterkontext geändert oder durch die Graphik-Pipeline "geschaltet" werden muß, muß die Pipeline "geräumt" werden. Das Räumen erfordert, daß die Pipeline von Daten geleert wird, um zu bestimmen, ob alle Daten, die dem vorherigen Kontext zugeordnet sind, durch die Pipeline zu dem Rahmenpuffer geleitet wurden.
Dieses Verfahren des Kontextschaltens ist mit Problemen verbunden. Da alle Daten aus der Pipeline geleert werden müssen, um zu bestimmen, ob der vorherige Kontext zu dem Rahmenpuffer durchgeleitet wurde, bevor der nächste Kontext von dem Host in die Pipeline eingegeben werden kann, werden schwerwiegende Begrenzungen bei der Aufbereitung von Graphikgrundelementen für den Bildschirm in einer zeitlichen Form eingeführt, wobei das System signifikant verlangsamt ist. Ferner erhöht die Host-Verwaltung dieser Form des Kontextschaltens die Zusatzbelastung des Hosts stark, wodurch der Host-Wirkungsgrad verringert wird, und wodurch die Host-Prozessorzeit erhöht wird, die Aufgaben zugewiesen ist, die nicht der aktiven Aufbereitung von Daten zu dem Rahmenpuffer zugeordnet sind. Folglich ist das Räumen der Graphik-Pipeline ein unzulängliches und ineffizienten Verfahren, um in neueren Fenstersystemen, die Graphik-Pipelines verwenden, ein Kontextschalten zu erreichen.
Aus der GB-A-2211706 ist es bekannt, einen FIFO-Speicher unter den Pipeline-Stufen zu verteilen. Ein Latch vor jeder Pipeline-Stufe wirkt als ein FIFO der Tiefe Eins, um die Daten zu speichern, die von der vorherigen Stufe gesendet werden, wenn die momentane Stufe nicht bereit ist, dieselben zu empfangen. Ein Register ist jeder Stufe hinzugefügt, um das momentane Halte-Signal zwischenzuspeichern, das von einer folgenden Stufe gesendet wird, bevor es zu der vorherigen Stufe gesendet wird. Das Halte-Signal einer Stufe bewirkt, daß ein Halte-Signal durch die nächste vorherige Stufe erzeugt wird, während sich der Prozeß des Zwischenspeicherns der Daten und des Übertragens der Halte-Signale durch die Pipeline fortsetzt.
Weitere Zeitprobleme existieren in Fenstersystemen, die Graphik-Pipelines verwenden. Alle Graphik-Pipelines erfahren eine Pipeline-"Latenz", die als die Zeit definiert ist, die erforderlich ist, damit ein einzelnes Grundelement die Pipeline durchläuft. Eine signifikante Schwierigkeit wird während des Kontextschaltens in Graphik-Pipelines als ein Ergebnis der Pipeline-Latenz angetroffen, da die Pipeline-Latenz die Ansprechempfindlichkeit und die Benutzerinteraktivität des Fenstersystems verringert. Ferner benötigen komplexe Grundelemente eine signifikante Verarbeitungszeit zum Aufbereiten und zwingen daher andere Grundelemente dazu, einen Wartezustand in der Pipeline anzunehmen, bis dieselben vollständig für den Bildschirm aufbereitet sind.
Somit zwingen Fensteroperationen, die theoretisch interaktiv mit dem Benutzer sein sollten, den Benutzer häufig dazu, zu warten, während Graphikgrundelemente aufbereitet werden. Da sich Graphik-Pipelines und Graphik-Workstations dahingehend entwickeln, daß sie komplexere Grundelemente und längere Pipelines unterstützen, liefern die Pipeline-Latenz und das Pipeline-Räumen nun untragbare Probleme bei der anhaltenden Bemühung nach einem zunehmenden Pipeline-Durchsatz und -Wirkungsgrad.
Es existiert folglich ein seit langem bekannter Bedarf in der Technik nach Graphik-Pipeline-Architekturen, die die Notwendigkeit eines Pipeline-Räumens beseitigen und die Pipeline-Latenz reduzieren. Außerdem existiert ein seit langem bekannter Bedarf in der Technik nach Pipeline-Graphiksystemen, die ein Schalten zwischen mehreren Kontexten unterstützen. Ferner existiert in der Technik ein seit langem bekannter Bedarf nach Graphiksystemen, die mehrere Kontexte unterstützen, jedoch den Bedarf nach einer komplexen Hostverwaltung und einer Prozessor-Zusatzbelastung reduzieren. Diese Bedürfnisse wurden bisher in der Graphikfenstertechnik durch keine momentanen Softwareimplementierungen, die gegenwärtig in Verwendung sind, erfüllt.
Die Erfindung besteht aus einem Computersystem gemäß Anspruch 1 und einem Verfahren gemäß Anspruch 5.

Kurze Beschreibung der Zeichnungen

Fig. 1 ist ein Blockdiagramm eines Fenstergraphiksystems, das eine Graphik-Pipeline und eine Graphik-Pipeline-Umgehung verwendet.
Fig. 2 ist ein Blockdiagramm eines Fenstergraphiksystems, das eine Graphik-Pipeline, eine Graphik-Pipeline- Umgehung, ein Markierungsregister und ein Stoppmarkierungsregister verwendet.
Fig. 3 ist ein Flußdiagramm eines Verfahrens, das gemäß dieser Erfindung unter Verwendung von Markierungsregistern und Stoppmarkierungsregistern geschaffen ist.
Fig. 4 ist ein Blockdiagramm eines Fenstergraphiksystems, bei dem eine Fenster-bezogene Adressierung durchgeführt wird.
Fig. 5 ist ein Flußdiagramm eines Verfahrens, das gemäß dieser Erfindung für eine Fenster-bezogene Adressierung und für eine Implementierung von virtuellen Fenstern geschaffen ist.
Fig. 6 ist ein Blockdiagramm eines Fenstergraphiksystems, das eine Graphik-Pipeline und eine Graphik-Pipeline-Umgehung zum Bewegen von Blockdaten durch die Graphik-Pipeline-Umgehung zu einem Rahmenpuffer verwendet.
Fig. 7 ist ein Flußdiagramm eines Verfahrens, das gemäß dieser Erfindung zum Bewegen von Blockdaten und zum Aufbereiten der Blockdaten in einem Rahmenpuffer gemäß den Rahmenpuffer-bezogenen Adressen geschaffen ist.
Fig. 8 ist ein Blockdiagramm eines Graphikfenstersystems zum Übertragen großer Datenblöcke von einem Hostprozessor durch einen Bündelblock, der FIFO-Register verwendet, zu einem Rahmenpuffer.
Fig. 9A ist ein Flußdiagramm eines Verfahrens, das gemäß dieser Erfindung zum Übertragen großer Datenblöcke entlang einer Pipeline-Umgehung von einem Hostprozessor zu einem Bündelblock geschaffen ist.
Fig. 9B ist ein Flußdiagramm eines Verfahrens, das gemäß dieser Erfindung zum Übertragen von Daten von einem Bündelblock zu einem Pixel-Cache geschaffen ist.

Detaillierte Beschreibung der bevorzugten Ausführungsbeispiele

Die Erfinder des hierin beanspruchten und offenbarten Gegenstands lösten die oben genannten, in der Technik seit langem bekannten Bedürfnisse durch das Implementieren eines Graphikfenstersystems unter Verwendung einer Graphik-Pipeline mit einem getrennten Weg für Befehle und Daten, die kein Durchlaufen der Graphik-Pipeline erfordern. Dieser getrennte Weg ist hierin als ein "Pipeline-Umgehungsbus" definiert und liefert Daten-Befehlen und Blöcken einen direkten Zugriff auf den Datenpuffer ohne ein Durchlaufen des Pipeline-Busses. Der Pipeline-Umgehungsbus unterstützt Blockbewegungen, Block-Lese- und -Schreib-Operationen ebenso wie andere hardwaremäßige, und nicht softwaremäßige, Datenübertragungsfunktionen.
Der Pipeline-Umgehungsbus liefert ferner einen schnellen Zugriff auf den Rahmenpuffer für vergleichsweise einfache Befehle, die von dem Host-Prozessor stammen. Ferner reduziert der Pipeline-Umgehungsbus die Graphik-Pipeline-Zusatzbelastung und liefert Dienste, die für das Fenstersystem erforderlich sind, die andernfalls durch den Pipeline-Bus verarbeitet werden müßten. Während der Pipeline-Bus eine Hochleistungs-Aufbereitung liefert, liefert der Pipeline-Umgehungsbus schnelle Blockoperationen und einen direkten Rahmenpufferzugriff auf die Datenausgabe durch den Hostprozessor.
Wie in Fig. 1 gezeigt ist, besteht ein Graphiksystem aus einem Hostprozessor 20, der schnittstellenmäßig 30 mit einer Transformationsmaschine 40 verbunden ist. Die Pipeline 50 verbindet den Hostprozessor 20 und die Transformationsmaschine 40 schnittstellenmäßig mit einer Aufbereitungsschaltung 60. Die Pipeline so ist ein Graphikprozessor, der eine Vielzahl von Aufgaben in dem Graphikfenstersystem durchführt. Diese Aufgaben schließen das Leiten von Daten durch das Graphiksystem und das Verarbeiten der Graphikbefehle durch verschiedene Hardwareblöcke und Softwarefunktionen ein. Die Ausdrücke Pipeline, Pipeline-Bus und Pipeline-Prozessor sind durchgehend austauschbar verwendet, um den Graphik-Pipeline-Prozessor zu bezeichnen. Eine Fensterschaltung 65 weist bei bevorzugten Ausführungsbeispielen eine Graphikhardware auf, die gemäß dieser Erfindung vorgesehen ist, um Graphikgrundelemente auf Fenstern zu dem Rahmenpuffer 70 aufzubereiten. Die Fensterschaltung ist schnittstellenmäßig mit dem Rahmenpuffer 70 und der Aufbereitungsschaltung 60 verbunden. Diese Graphikgrundelemente, ebenso wie andere Graphikbefehle, werden von dem Hostprozessor 20 ausgegeben und durch die Transformationsmaschine 40 durch die Graphik- Pipeline 50 für eine Übergabe an den Rahmenpuffer 70 manipuliert. Nachdem die Aufbereitungsschaltung 60 ein Fenster mit einem speziellen Kontext durch die Fensterschaltung 65 für den Rahmenpuffer 70 aufbereitet hat, wird das Fenster auf einer Rasteranzeige 80 ausgegeben.
Ein Pipeline-Umgehungsbus 90 ist schnittstellenmäßig 30 mit dem Hostprozessor 20 und dem Rahmenpuffer 70 verbunden. Der Pipeline-Umgehungsbus 90 liefert einen getrennten Datenweg von dem Hostprozessor 20 zu dem Rahmenpuffer 70. Wenn Daten durch den Pipeline-Umgehungsbus 90 zu dem Rahmenpuffer 70 geleitet werden, wird folglich kein zusätzlicher Zeitaufwand durch die Graphik-Pipeline eingeführt. Der Pipeline-Umgehungsbus 90 liefert schnelle Blockübertragungsoperationen und einen direkten Rahmenpufferzugriff für eine Datenausgabe von dem Hostprozessor 20.
Bei den bevorzugten Ausführungsbeispielen werden gemäß dieser Erfindung Hardwarelösungen geschaffen, die den Bedarf nach einem Pipeline-Räumen beseitigen und die die Pipeline- Latenz reduzieren, wodurch die Fensterbeschleunigung durch das System erhöht ist. Bei weiteren bevorzugten Ausführungsbeispielen ermöglichen Hardwareimplementierungen die Speicherung mehrerer Graphikkontexte auf dem Graphiksystem.
Außerdem können bei den Verfahren und Vorrichtungen, die gemäß dieser Erfindung geschaffen sind, Fenster in dem Graphiksystem als "virtuelle" Vorrichtungen betrachtet werden. Eine virtuelle Vorrichtung arbeitet gemäß den Fenster-bezogenen Adressen durch die Graphik-Pipeline unabhängig von Adressen&sub1; die dem Rahmenpuffer oder der Rasteranzeige entsprechen. Da die Fenster und das Fensterkontextschalten folglich gemäß den Fenster-bezogenen Adressen aufbereitet werden können, ist der Bedarf nach einer Pipeline-Räumung beseitigt und die Pipeline-Latenz ist signifikant reduziert. Folglich kann jedes Fenster in dem Fenstersystem die Graphik-Pipeline als ein ausschließliches Betriebsmittel betrachten, da Zeit-verbrauchende Manipulationen des Fensters, die die Pipeline-Latenz erhöhen, beseitigt sind. Folglich erfüllen die Verfahren und Vorrichtungen, die gemäß der vorliegenden Erfindung geschaffen werden, einen in der Technik lange bekannten Bedarf nach Graphiksystemen, die mehrere Fensterkontexte unterstützen und den Bedarf nach einer Pipeline-Räumung beseitigen.
Gemäß Fig. 2 ist ein Hostprozessor 20 entlang der Pipeline 50 schnittstellenmäßig mit einer Aufbereitungsschaltung 60 verbunden. Zwischen der Aufbereitungsschaltung 60 und einem Rahmenpuffer 70 ist ein Markierungsregister 100 angeordnet. Bei den bevorzugten Ausführungsbeispielen wird von dem Hostprozessor durch den Pipeline-Bus 50 auf das Pipeline-Markierungsregister 100 zugegriffen, ohne den Datenfluß durch die Pipeline zu beeinflussen. Das Markierungsregister 100 verhindert eine unnötige Pipeline-Räumung, wenn es erwünscht ist, einen Fensterkontext zu ändern.
Eine Fensterkontextänderung erfordert häufig ein Wechseln der Systembetriebsmittel, wie z.B. der Fenster-Abschneidungsebenen oder der Fenster-Anzeigemodus-Ebenen. Ferner müssen diese Systembetriebsmittel häufig während des Kontextschaltens gewechselt werden, da dieselben ein begrenztes Betriebsmittel sind und von mehreren Prozessen gemeinsam verwendet werden. Das Markierungsregister 100 liefert, verglichen mit früheren Softwarelösungen, die dazu tendieren könnten, den Bedarf nach einer Pipeline-Räumung zu reduzieren, denselben jedoch nicht beseitigen -- und nicht beseitigen können, ein bevorzugtes Betriebsmittel zum Schalten von Kontexten.
Bei den bevorzugten Ausführungsbeispielen verfolgt das Markierungsregister 100 momentan aktive Kontexte, die die Graphik-Pipeline 50 von dem Hostprozessor 20 durchlaufen. Bei weiteren bevorzugten Ausführungsbeispielen wird eine "Markierung" zwischen jedem Kontextschalten von dem Hostprozessor 20 entlang der Pipeline 50 gesendet. Das Markierungsregister wird jedesmal inkrementiert, wenn ein Kontext die Pipeline durchläuft, derart, daß eine Tabelle von Kontexten, die gegenwärtig in der Pipeline sind, durch das System in dem Markierungsregister 100 gehalten wird. Die Tabelle zeigt die Kontextnummer, die Fensterabschneidungsebenen, die Fensteridentifikation und die Markierungsnummern für jeden aktiven Kontext in der Pipeline. Während die Kontexte durch den Pipeline-Bus 50 verarbeitet werden, wird das Pipeline- Markierungsregister 100 automatisch jedesmal aktualisiert, wenn eine Markierung das Ende des Pipeline-Busses 50 erreicht.
Ein Stoppmarkierungsregister 110 ist schnittstellenmäßig zwischen dem Hostprozessor 20 und dem Rahmenpuffer 70 in den Pipeline-Umgehungsbus 90 geschaltet. Bei weiteren bevorzugten Ausführungsbeispielen ist das Stoppmarkierungsregister 110 gemäß der speziellen Anwendung, die durch den Hostprozessor 20 und den Benutzer spezifiziert ist, mit einem speziellen Wert eingestellt. Wenn ein Kontextschalten stattfindet, kann das Fenstersystem den Wert des Markierungsregisters 100 lesen und diesen mit dem vorbestimmten Wert in dem Stoppmarkierungsregister 110 vergleichen, um zu bestimmen, welche Kontexte noch in der Pipeline sind. Wenn der Markierungsregister-Wert gleich dem Stoppmarkierungsregister-Wert ist, wird das Fenstersystem warten, bis der momentane Kontext durch das System verarbeitet wurde und an den Rahmenpuffer 70 übergeben wurde. Wenn der Stoppmarkierungsregister-Wert nicht gleich dem Markierungsregister-Wert ist, ist der Kontext, der gewechselt wird, nicht in der Pipeline, wobei das Kontextschalten und Abschneidungsebenen-Änderungen unmittelbar stattfinden können. Daher wird es unter keinen Umständen notwendig sein, den Datenfluß in der Pipeline anzuhalten, oder zu verhindern, daß der Hostprozessor fortgesetzt Befehle und Daten auf der Pipeline plaziert. Folglich ist der Bedarf nach einem Pipeline-Räumen beseitigt.
In Fig. 3 ist ein Flußdiagramm eines bevorzugten Ausführungsbeispiels eines Verfahrens, das das Markierungs/Stoppmarkierungs-System von Fig. 2 implementiert, dargestellt. Das System initialisiert in einem Schritt 120 ein Stoppmarkierungsregister durch die Pipeline-Umgehung. Es ist danach erwünscht, die Pipeline in einem Schritt 125 "zu öffnen" ("unplug"). Das System initialisiert in einem Schritt 130 ein Markierungsregister durch die Pipeline und sendet Datenbefehlssegmente in einem Schritt 135 durch die Pipeline.
Der Hostprozessor fragt in einem Schritt 140 das System ab, um zu bestimmen, ob die Pipeline "geschlossen" ("plugged") ist. Der Ausdruck "geschlossen", der hierin verwendet ist, bedeutet, daß keine Daten und Graphikbefehle durch die Pipeline fließen. Wenn die Pipeline geschlossen ist, führt das System in einem Schritt 150 die Aufgabe durch, für die der Stopp oder das Schließen erwünscht war. Das System initialisiert danach in einem Schritt 155 die nächste Stoppmarkierung durch die Pipeline-Umgehung und macht die Pipeline in einem Schritt 160 frei.
Wenn die Pipeline nicht geschlossen war, fragt das System in einem Schritt 145, ob die Pipeline gefüllt ist. Wenn die Pipeline gefüllt ist, kehrt das System zum Schritt 140 zurück. Wenn die Pipeline jedoch nicht gefüllt ist, kehrt das System zum Schritt 125 zurück, in dem sie die Pipeline öffnet.
Gleichzeitig mit dem Schritt 125 fragt der Hostprozessor das System ab, um in einem Schritt 165 zu bestimmen, ob der Markierungsregister-Wert gleich dem Stoppmarkierungsregister- Wert ist. Wenn der Stoppmarkierungsregister-Wert gleich dem Markierungsregister-Wert ist, beendet das System den Pixeldatenfluß zu dem Rahmenpuffer oder "schließt" die Pipeline in einem Schritt 170. Der Hostprozessor fragt dann das System ab, um zu bestimmen, ob die Pipeline in einem Schritt 175 geöffnet wurde. Wenn die Pipeline nicht geöffnet wurde, wartet das System.
Wenn das System offen ist, fragt der Hostprozessor das System im Schritt 165 wiederum ab, um zu bestimmen, ob der Markierungs-Wert gleich dem Stoppmarkierungs-Wert ist. Wenn der Stoppmarkierungs-Wert nicht gleich dem Markierungs-Wert ist, gibt der Hostprozessor im Schritt 180 einen Befehl aus, der ermöglicht, daß der Pixel-Cache Daten in den Rahmenpuffer schreibt.
Andernfalls schließt der Hostprozessor die Pipeline im Schritt 170 zu der Zeit, zu der der Hostprozessor das System abfragt, um im Schritt 140 zu bestimmen, ob die Pipeline geschlossen ist. Folglich wurde der Bedarf danach, die Pipeline zu räumen, beseitigt, da das Schließen der Pipeline nur für relativ kurze Zeitperioden zwischen dem Pixel-Cache und dem Rahmenpuffer stattfinden muß, während eine komplexe Verarbeitung und eine Matrixtransformation vorher in der Pipeline stattfindet. Dieses vorteilhafte Ergebnis wird erreicht, da das Markierungs- und das Stoppmarkierungsregister dem Graphiksystern mitteilen, wann der Pixeldatenfluß zu dem Rahmenpuffer warten muß, da ein spezieller Kontext noch nicht an den Rahmenpuffer übergeben wurde.
Das Kontextschalten unter Verwendung der Markierungs- und Stoppmarkierungs-Hardware, das gemäß dieser Erfindung geschaffen ist, beseitigt folglich den Bedarf nach einer Pipe line-Räumung, da die Graphik-Pipeline niemals von Daten geleert werden muß, um zu bestimmen, ob ein momentaner Kontext zu dem Rahmenpuffer übergeben wurde. Auf diese Weise kann ein extrem schnelles und wirkungsvolles Kontextschalten erreicht werden, wodurch das Gesamtgraphiksystem signifikant verbessert wird. Die Markierungsregister- und Stoppmarkierungsregister-Hardware, die gemäß dieser Erfindung geschaffen ist, erfüllt den in der Technik seit langem bekannten Bedarf nach einem Kontextschalten in Graphiksystemen unter Verwendung eines Pipeline-Busses und eines Pipeline-Umgehungsbusses.
Die Erfinder des hierin beanspruchten und offenbarten Gegenstands entdeckten, daß alle Graphikanwendungen schneller ablaufen, wenn dieselben sich selbst als den einzigen Besitzer des Graphiksystems betrachten. Dies ist eine Folge der Tatsache, daß, wenn eine Graphikanwendung ein Fenster anfordert, der entsprechende Rahmenpufferspeicher dieser Anwendung für eine Graphikausgabe zugewiesen wird. Folglich würde eine ideale Umgebung für eine Graphikaufbereitung ermöglichen, daß jeder Graphikprozeß das Fenster als eine "alleinstehende" oder virtuelle Graphikvorrichtung behandelt.
Frühere Graphiksysteme erforderten üblicherweise, daß der Graphikprozeß modifiziert wird, um innerhalb eines Fensters abzulaufen. Diese Systeme erfordern, daß die Anwendung "Fenster-intelligent" ist, sowie eine Nachverarbeitung der Anwendungsausgabe, um durch das Hinzufügen von Fensterversätzen oder das Abschneiden auf Fenstergrenzen mit der Fensterumgebung zusammenzupassen. Eine Software, die diese Funktionen durchführt, reduziert das Gesamtsystemverhalten beträchtlich, da eine übermäßige Hostprozessor-Zeitmenge erforderlich ist, um diese Aufgaben durchzuführen. Die Erfinder des hierin beanspruchten und offenbarten Gegenstands implementierten Graphikfunktionen hardwaremäßig, die ermöglichen, daß Grundelemente in dem Pipeline-Bus relativ zu dem Fenster-Ursprung spezifiziert sind.
Bei den bevorzugten Ausführungsbeispielen ist der Fensterursprung ein Bezug für die Graphikgrundelernente, die für das Fenster aufbereitet werden. Die Übersetzung in Bildschirmbezogene oder "Rahmenpuffer-bezogene Adressen" findet nach der Abtastwandlung gemäß den Fenster-bezogenen Adressen und vor dem Rahmenpufferzugriff statt. Folglich behandelt die Anwendung das Fenster als eine "virtuelle" Vollschirmvorrichtung, das das Graphiksystem die Grundelernente aufbereitet, als ob das Fenster den gesamten Rahmenpuffer umfaßt.
Operationen dieser Beschaffenheit können durch eine Transformationsmatrix durchgeführt werden. Wenn der Fensterversatz in dem Matrixstapel enthalten ist, muß die Pipeline jedoch jedesmal geräumt werden, wenn das Fenster bewegt oder geändert wird. Nach dem Räumen der Pipeline kann der neue Fensterversatz zu der Transformationsmatrix hinzugefügt werden, und die Pipeline muß wieder gefüllt werden. Folglich besteht eine bevorzugtere Lösung darin, zu ermöglichen, daß die Anwendung auf das Fenster zugreift, als ob dieselbe den gesamten Bildschirm oder Rahmenpuffer besitzt, und dann eine Hardware zu liefern, die die Fensterversatzdaten entsprechend den Rahmenpuffer-bezogenen Adressen empfängt, so daß das Fenster, das die Graphikgrundelemente enthält, entsprechend den Rahmenpuffer-bezogenen Adressen für den Rahmenpuffer aufbereitet werden kann.
Durch das Aufbereiten der Grundelemente in Fenster-bezogenen Koordinaten und das Durchführen der Umwandlung von Fensterbezogen auf Bildschirm-bezogen in der Verarbeitungsrichtung hinter der Aufbereitungshardware in der Pipeline ist der Bedarf danach, die Pipeline zu räumen, um ein Fenster für den Rahmenpuffer aufzubereiten, beseitigt. Die Fensterübersetzung, die somit hardwaremäßig erreicht wird, ist für die Anwendung vollständig transparent. Die Versatzoperationen werden parallel zu anderen Pipeline-Operationen durch den Pipeline-Umgehungsbus durchgeführt, so daß keine Verhaltensnachteile für die verschiedenen Blockoperationen oder Kontextschaltungen in das Fenstergraphiksystem eingeführt werden.
Gemäß Fig. 4 ist ein Hostprozessor 20 schnittstellenmäßig mit einer Aufbereitungsschaltung 60 verbunden. Bei bevorzugten Ausführungsbeispielen weist die Aufbereitungsschaltung 60 eine Transformationsmaschine 210 und einen Abtastwandler 220 auf. Vorzugsweise ist der Abtastwandler ein Raster-Abtastwandler. Mit dem Abtastwandler ist entlang des Pipeline-Busses 50 ein Pixel-Cache 230 schnittstellenmäßig verbunden. Der Pixel-Cache 230 ist ferner schnittstellenmäßig mit einem Rahmenpuffer 70 verbunden. Bei weiteren bevorzugten Ausführungsbeispielen weist ein Video-Direktzugriffsspeicher VRAM 240 den adressierbaren Rahmenpuffer für das System auf. Ein Adreßmanipulator 250 ist auf einem Pipeline-Umgehungsbus 90 schnittstellenmäßig verschaltet. Der Adreßmanipulator 250 ist entlang des Pipeline-Umgehungsbusses 90 zwischen dem Hostprozessor 20 und dem Rahmenpuffer 70 angeordnet.
Bei weiteren bevorzugten Ausführungsbeispielen weist der Adreßmanipulator 250 Datenregister zum Empfangen von Versatzadressen für jedes Fenster von dem Hostprozessor 20, eine Fenster-bezogene Umwandlungsschaltung und ein Datenregister zum Speichern der Fensteridentifikation auf. Die Fensterversätze werden durch den Adreßmanipulator 250 auf jedes Fenster angewendet, bevor die Fenster, die Graphikgrundelemente enthalten, an den Rahmenpuffer 70 übergeben werden. Da die Fensterversätze durch den Pipeline-Umgehungsbus 90 in den Adreßmanipulator 250 geschrieben werden, können dieselben asynchron aktualisiert werden. Die Fenster können folglich zu der gleichen Zeit, zu der die Fenster-bezogene Aufbereitung der Graphikgrundelemente an dem Abtastwandler 220 durch den Pipeline-Bus 50 stattfindet, durch die Pipeline-Umgehung 90 zu dem Rahmenpuffer bewegt oder gemischt werden. Graphik-Anwendungen und -Prozesse können daher auf dem Graphik-Pipeline-Bus 50 ohne die explizite Kenntnis ihres schließlichen Fensterorts in dem Rahmenpuffer ablaufen. Folglich wirken die Fenster in den Graphiksystemen, die gemäß dieser Erfindung geschaffen sind, wahrlich als virtuelle Vorrichtungen, da dieselben in der Lage sind, die Graphik-Pipeline während Fenster-bezogener Aufbereitungsoperationen als ein ausschließliches Betriebsmittel zu betrachten.
-Vorzugsweise ist der Pixel-Cache 230 schnittstellenmäßig durch einen zentralen Bus 240 mit einem Adreßmanipulator verbunden. Der Pixel-Cache 230 enthält Fenster-bezogene Adressen 245 der Graphikgrundelemente, die auf dem Fenster bezüglich des Fensterursprungs aufbereitet wurden. Da Fensterversatzdaten durch den Pipeline-Umgehungsbus 90 in den Adreßmanipulator 250 geschrieben werden, steht der Pixel- Cache 230 schnittstellenmäßig mit dem Adreßmanipulator 250 in Verbindung 245, um die Fenster-bezogenen Daten, die in dem Adreßmanipulator mit den Fensterversatzadressen kombiniert werden, zu liefern. Der Adreßmanipulator 250 ist ferner mit dem Rahmenpuffer 70 schnittstellenmäßig verbunden, so daß die Graphikfenster entsprechend den Rahmenpuffer-bezogenen Adressen 255 an den Rahmenpuffer übergeben werden können.
Da der Adreßmanipulator 250 die Fensterversätze auf die Graphikgrundlemente, die Fenster-bezogen adressiert sind, anwendet, ist der Bedarf danach, die Graphik-Pipeline 50 zu räumen, wenn Kontextänderungen auftreten, beseitigt, und die Pipeline-Latenz für die Graphiksysterne ist stark reduziert. Diese vorteilhaften Ergebnisse werden erhalten, da die komplexe Manipulation, die der Aufbereitung der Graphikgrundelemente in den Rahmenpuffer-bezogenen Adressen direkt durch die Graphik-Pipeline zugeordnet ist, bei Systemen und Verfahren, die gemäß dieser Erfindung geschaffen sind, beseitigt ist.
Ein Flußdiagramm, um eine Fenster-bezogene Aufbereitung bei den Fenstergraphiksystemen, die gemäß dieser Erfindung geschaffen sind, zu erreichen, ist in Fig. 5 gezeigt. Ein Pipeline-Fensterverwalter verarbeitet eine Anwendung durch die Pipeline. Die Anwendung fordert in einem Schritt 260 eine Fenster-ID an. Der Fensterverwalter bestimmt, ob in einem Schritt 265 eine neue Fenster-ID angefordert wurde. Wenn keine neue Fenster-ID angefordert wurde, bestimmt der Fensterverwalter in einem Schritt 270, ob eine Fensterbewegung angefordert wurde. Wenn keine Fensterbewegung angefordert wurde, springt der Prozeß zum Schritt 265 zurück. Wenn jedoch eine Fensterbewegung angefordert wurde, schließt der Fensterverwalter die Pipeline in einem Schritt 275.
Der Fensterverwalter berechnet dann in einem Schritt 280 einen neuen Fensterort und bewegt das Fenster. Ferner schreibt der Fensterverwalter den Fensterversatz in einem Schritt 285 in den Adreßmanipulator und öffnet die Pipeline in einem Schritt 290. Der Prozeß springt dann zum Schritt 265 zurück, um zu bestimmen, ob eine neue Fenster-ID angefordert wurde. Da an diesem Punkt keine neue Fenster-ID angefordert wurde, weist der Fensterverwalter in einem Schritt 295 eine Fenster-ID zu und schließt die Pipeline in einem Schritt 300.
Der Hostprozessor fragt dann das System in einem Schritt 305 ab, um zu bestimmen, ob die neue Fenster-ID empfangen wurde. Wenn die neue Fenster-ID nicht empfangen wurde, wartet das System, bis der Fensterverwalter eine neue Fenster-ID sendet. Wenn jedoch eine neue Fenster-ID empfangen wurde, sendet der Hostprozessor die Anwendung, die Daten- oder Befehls-Segmente für die zugewiesene Fenster-ID aufweist, in einem Schritt 310 durch die Pipeline. Der Hostprozessor bestimmt dann in einem Schritt 315, ob die Anwendung beendet ist. Wenn die Anwendung nicht beendet ist, sendet der Hostprozessor in dem Schritt 310 zusätzliche Daten- oder Befehls-Segmente durch die Pipeline. Wenn die Anwendung jedoch beendet ist, kann gesagt werden, daß das Fenster aufbereitet wurde, und daß der Fensterverwalter das Fenster im Schritt 280 an seinen neuen Ort bewegt haben wird. Der Prozeß endet dann bei 320, bis ein weiteres Fenster die Pipeline durchläuft.
Eine Fenster-bezogene Aufbereitung, die durch die Verfahren, die in Fig. 5 dargestellt sind, erreicht wird, beseitigt den Bedarf nach einer Pipeline-Räumung. Der Fensterverwalter wendet unabhängig Fensterversatzadressen auf Fenster-bezogene Daten an, während die Pipeline gleichzeitig Fenster gemäß den Fenster-bezogenen Adressen verarbeiten kann. Dies wurde bisher in der Technik noch nicht erreicht und erhöht die Geschwindigkeit und die Aktualität der Übergabe von Graphikgrundelementen an den Rahmenpuffer signifikant.
Graphikfenstersysteme müssen Blockbewegungsoperationen unterstützen, um das Systemverhalten zu maximieren. Außerdem unterstützen Blockbewegungsoperationen im allgemeinen elementare Fenstergrundelemente, die Raster-Texte und -Symbole einschließen. Andere Typen von Graphikblockbewegungen, beispielsweise Mischungen (shuffles) und Block-"Skalierungen", müssen ebenfalls einen Nutzen aus den Blockbewegungsfähigkeiten des Systems ziehen.
Ein "Block" kann als ein gesamtes Fenster oder nur ein Teil eines Fensters, der einen Satz von Graphikgrundelementen auf dem Graphiksystem aufweist, betrachtet werden. Blockbewegungen sind in einer Fensterumgebung besonders schwierig zu handhaben, da Fensterversatzadressen bei diesen Operationen eingeschlossen sein müssen, welche typischerweise als Bildschirmadressen-bezogen implementiert sind. Im Gegensatz dazu müssen Blockbewegungsoperationen innerhalb eines Fensters Fenster-bezogen sein, so daß das Erzwingen, daß alle Blockbewegungen in dem Graphiksystem Fenster-bezogen sind, weder eine adäquate noch eine vielseitige Lösung ist. Der Grund dafür, daß Blockbewegungsoperationen innerhalb eines Fensters Fenster-bezogen sein müssen, liegt darin, daß viele Objekte, beispielsweise Fonts, in einem Außerhalb-Des-Bildschirms-Speicher in dem Rahmenpuffer gespeichert sind, weshalb diese Objekte ausschließlich entsprechend Rahmenpuffer-bezogenen Adressen identifiziert sind.
Die Erfinder des hierin beanspruchten und offenbarten Gegenstands entdeckten, daß die hardwaremäßige Implementierung einer Graphikblock-Bewegungseinrichtung ermöglicht, daß das Graphiksystem mehrere unterschiedliche Arten von Blockbewegungsoperationen handhabt. Bei bevorzugten Ausführungsbeispielen weist die hardwaremäßige Implementierung der Blockbewegungsvorrichtung ein Register auf, das die Fähigkeit besitzt, ein Bit für jede Operandenausgabe von dem Hostprozessor zu speichern, das spezifiziert, ob der Operand Fensteradressen-bezogen oder Bildschirmadressen-bezogen ist. Blockbewegungen, die durch Verfahren und Systeme gemäß dieser Erfindung geschaffen sind, können folglich Fenster-bezogen, Bildschirm-bezogen oder irgendeine Kombination derselben sein.
Fenstersysteme gemäß dieser Erfindung können eine Blockbewegungshardware aufweisen, die Fensterversätze durch einen Pipeline-Umgehungsbus für Fenster, die Graphikgrundelemente aufweisen, die gemäß den Fenster-bezogenen Adressen aufbereitet sind, auf denselben aufweisen, liefert. Bei weiteren bevorzugten Ausführungsbeispielen schreiben Blockbewegungen, die gemäß dieser Erfindung eingeleitet werden, die Blockquelle und Bestimmungsadressen, die Block-Breite und -Höhe und eine spezielle Ersetzungsregel durch den Pipeline-Umgehungsbus vor der Einleitung der Blockbewegung in den Adreßmanipulator.
Folglich erfordert eine Blockbewegung, die gemäß dieser Erfindung geliefert wird, nicht, daß das Fenster Entscheidungen über sein spezielles Koordinatensystem trifft, wenn dasselbe die Graphik-Pipeline durchläuft. Dies beseitigt die Notwendigkeit, daß sich das Fenstersystem eine zusätzliche Prozessorzusatzbelastung zuzieht, während Graphikgrundelemente gemäß den Rahmen-bezogenen Adressen manipuliert werden, was notwendigerweise parallel zu der Verarbeitung der Anwendung oder des Kontexts stattfinden würde. Wenn ein Block in dem Arbeitsbereich des Rahmenpuffers außerhalb des Bildschirms ist, kann bei bevorzugten Ausführungsbeispielen automatisch angenommen werden, daß derselbe Bildschirm-bezogen ist. Wenn der Block in dem aktiven Bildschirmbereich des Rahmenpuffers angezeigt wird, kann jedoch angenommen werden, daß derselbe Fenster-bezogen adressiert ist.
Wie in Fig. 6 gezeigt ist, gibt ein Hostprozessor 20 Graphikbefehle entlang eines Pipeline-Busses 50 zu einer Schaltung 330 für eine Fenster-bezogene Aufbereitung aus. Die Schaltung 330 für eine Fenster-bezogene Aufbereitung weist im allgemeinen eine Raster-Abtasteinrichtung und eine Pixel-Cache-Puffereinrichtung, wie sie in den vorherigen Figuren veranschaulicht wurde, auf. Die Schaltung für eine Fenster-bezogene Aufbereitung 330 bereitet Graphikgrundelemente für das Fenster gemäß den Fenster-bezogenen Adressen auf.
Die Schaltung 330 für eine Fenster-bezogene Aufbereitung ist ferner schnittstellenmäßig mit einem Rahmenpuffer 70 verbunden. Bei bevorzugten Ausführungsbeispielen ist der Rahmenpuffer 70 ein VRAM. Der Rahmenpuffer 70 kann konzeptionell in zwei Teile geteilt sein. Der erste Teil 340 entspricht den Bildschirmadressen, d.h. positioniert dort auf dem Videobildschirm, wo Graphikgrundelemente tatsächlich angezeigt werden. Der zweite Teil des Rahmenpuffers 350 entspricht einem "Außerhalb-des-Bildschirms" -Arbeitsbereich. Der Außerhalb-des-Bildschirms-Arbeitsbereich 350 ist ein Bereich, in dem Fenster oder Blöcke, die nicht auf dem Videobildschirrn des Graphiksystems aufbereitet wurden, ausschließlich entsprechend den Rahmenpuffer-bezogenen Adressen existieren. Blöcke, die auf dem ersten Abschnitt des Rahmenpuffers 340 erscheinen, können relativ zu dem Bildschirm in den Rahmenpuffer-bezogenen Adressen oder den Fenster-bezogenen Adressen adressiert sein, während sie durch die Pipeline verarbeitet werden.
Bei den bevorzugten Ausführungsbeispielen kann ein Quellenblock 360 von dem Arbeitsbereich 350 zu dem Bestimmungs-Fenster oder -Block 370 in dem ersten Abschnitt 340 des Rahmenpuffers 70 bewegt werden. Es ist für Fachleute offensichtlich, daß die Quellen- und Bestimmungs-Adressen ausgetauscht sein könnten, derart, daß Blöcke Fenster-bezogen, Bildschirm-bezogen oder in einer beliebigen Kombination derselben bewegt werden können.
Um Blöcke zwischen einer Bestimmung und einer Quelle zu bewegen, gibt der Hostprozessor 20 Fensterversatzinformationen über den Pipeline-Umgehungsbus 90 zu einer Vielzahl von Datenregistern aus, die der Adreßmanipulator 250 aufweist. Ein Bestimmungsregister 380 ist angepaßt, um die Bestimmungsadresse des Blocks, der von dem Hostprozessor 20 ausgegeben wird, zu speichern. Ein Quellenadreßregister 390 ist angepaßt, um die Quellenadresse des Blocks über die Pipeline-Umgehung 90, welche durch den Hostprozessor 20 ausgegeben wird, zu empfangen. Bei weiteren bevorzugten Ausführungsbeispielen ist es erwünscht, die Blockgröße in das Blockgrößenregister 400 zu schreiben. Bei noch weiteren bevorzugten Ausführungsbeispielen weist die Blockgröße die Block-Breite und die -Höhe auf, so daß der Block exakt an den geeigneten Bestimmungsort in dem Rahmenpuffer geschrieben werden kann.
Das Spezifikatorregister 410 ist angepaßt, um Daten von dem Hostprozessor 20 durch den Pipeline-Umgehungsbus 90 zu empfangen, die spezifizieren, ob der Block, der bewegt werden soll, gegenwärtig Fensteradreß-bezogen oder Rahmenpufferadreß-bezogen ist. Bei weiteren bevorzugten Ausführungsbeispielen spezifiziert ein einzelnes Bit des Operanden, das von dem Hostprozessor 20 empfangen und in dem Spezifikatorregister 410 gespeichert wird, ob der Block Fenster- oder Bildschirm-bezogen ist. Folglich können mit den Verfahren und Vorrichtungen gemäß dieser Erfindung Blöcke, die Fensteradreß-bezogen oder Bildschirmadreß-bezogen sind, zwischen Quellen und Bestimmungsorten, die Fenster-bezogen adressiert oder Rahmenpuffer-bezogen adressiert sind, bewegt werden.
In gleicher Weise können die Quellenadressen und Bestimmungsadressen entweder gemäß den Fenster-bezogenen Adressen oder den Rahmenpuffer-bezogenen Adressen adressiert sein, und Blöcke können gleichzeitig zwischen Quellen- und Bestimmungs-Adressen entweder innerhalb von Fenstern oder in und um den Rahmenpuffer bewegt werden. Systeme und Verfahren, die gemäß dieser Erfindung geliefert werden, erfüllen daher einen in der Technik seit langem bekannten Bedarf nach einer hochwirksamen und vielseitigen Blockbewegungsschaltung in Graphikfenstersystemen, die Graphik-Pipelines verwenden.
In Fig. 7 ist ein Flußdiagramm eines Blockbewegungsverfahrens, das gemäß dieser Erfindung geliefert wird, gezeigt. Bei bevorzugten Ausführungsbeispielen wird ein Block in einem Schritt 420 gemäß Fenster-bezogenen Adressen durch eine Graphik-Pipeline aufbereitet. Die Quellenadressen des Blocks werden durch die Pipeline-Umgehung in einem Schritt 430 in das Quellenadreßregister geschrieben. In gleicher Weise werden die Bestimmungsadressen des Blocks in einem Schritt 440 durch den Pipeline-Umgehungsbus in das Bestimmungsadressenregister geschrieben. Es ist erwünscht, die Blockgröße in einem Schritt 450 durch den Pipeline-Umgehungsbus in das Blockgrößenregister zu schreiben.
Der Hostprozessor fragt in einem Schritt 460 ein Spezifikatorregister ab, um zu bestimmen, ob ein Bestimmungsblock gemäß Fenster-bezogenen Adressen oder Rahmenpuffer-bezogenen Adressen adressiert wurde. In gleicher Weise fragt der Hostprozessor in einem Schritt 465 ein Spezifikatorregister ab, um zu bestimmen, ob ein Quellenblock gemäß Fenster-bezogenen oder Rahmenpuffer-bezogenen Adressen adressiert wurde. Wenn die Blöcke gemäß den Rahmenpuffer-bezogenen Adressen adressiert wurden, wird in einem Schritt 470 ein "Null"-Fensterversatz angewendet, der die Blockadressen effektiv nicht ändert, da der Block als Rahmenpuffer-bezogen adressiert betrachtet wird.
Wenn das Spezifikatorregister jedoch anzeigt, daß die Blöcke Fensteradreß-bezogen sind, werden Fensterversatzadressen in einem Schritt 480 auf den Block angewendet, so daß die Blöcke korrekt gemäß den Rahmenpuffer-bezogenen Adressen adressiert sind, bevor die Blöcke zu dem Bestimmungsort in dem Systemrahmenpuffer oder dem Bildschirm übergeben werden. Nachdem die Fensterversätze auf die Fenster-bezogenen adressierten Blöcke angewendet wurden, können die Blöcke in einem Schritt 490 zu ihren Bestimmungsorten in dem Rahmenpuffer übergeben werden.
Bei weiteren bevorzugten Ausführungsbeispielen werden die Blockfenster-Versatzadressen durch den Pipeline-Umgehungsbus in den Adreßmanipulator geschrieben, und nicht durch den Graphik-Pipelinebus. Daher wird der Graphik-Pipelinebus nicht verwendet, um den Block relativ zu dem Rahmenpuffer zu adressieren und ist folglich frei, um Graphik-Grundelementaufbereitungen für Blöcke und Fenster vollständig gemäß den Fenster-bezogenen Adressen durchzuführen.
Verfahren und Systeme, die gemäß dieser Erfindung geliefert werden, reduzieren die Pipeline-Latenz, da jedes Fenster tatsächlich als eine virtuelle Vorrichtung in dem System behandelt wird. Außerdem lösen Verfahren und Vorrichtungen, die gemäß der vorliegenden Erfindung geschaffen sind, einen in der Technik seit langem bekannten Bedarf nach Graphik- Pipelines, die den Bedarf nach einer Pipeline-Räumung beseitigen, da die Zeit-verbrauchende Aufgabe des Addierens von Fensterversätzen zu Fenster-bezogen adressierten Blöcken und des Erhaltens von Rahmenpuffer-bezogen adressierten Blöcken beseitigt ist. Dieses Ziel wird durch das Implementieren eines Graphik-Pipelinebusses erreicht, der eine Hardware aufweist, die angepaßt ist, um diese Aufgaben durchzuführen.
Neuere Graphikfenstersysteme mit Graphik-Pipelines zeigen einen Bedarf nach der Fähigkeit, große Pixeldatenmengen zu und von dem Systemspeicher zu bewegen. Softwarelösungen, die früheren Graphiksystemen die Fähigkeit gaben, große Datenmengen auf diese Weise zu bewegen, benötigen eine übermäßige Prozessorzeitmenge, um diese Funktion zu erreichen. Folglich erfüllen frühere Fenstersysteme, die eine Graphik-Pipeline mit einer Spezialzweck-Software verwenden, um die Fähigkeit der Bewegung großer Datenblöcke zu liefern, den in der Technik seit langem bekannten Bedarf nach Graphikfenstersystemen, die große Datenblöcke wirksam bewegen können, ohne den Hostprozessor und die Graphik-Pipeline übermäßig zu belasten, nicht.
-Wie in Fig. 8 gezeigt ist, ist gemäß dieser Erfindung ein "Bündel"-Daten-Hardwareblock 500 vorgesehen, der schnittstellenmäßig in einem Pipeline-Umgehungsbus 90 verschaltet und zwischen dem Hostprozessor 20 und dem Pixel-Cache 230 angeordnet ist. Der Datenblock 500 wird als ein "Bündel"- Datenblock bezeichnet, da der Hostprozessor 20 den Datenblock 500 mit extrem großen Blöcken von Daten durch den Pipeline-Umgehungsbus 90 laden kann. Im allgemeinen können diese großen Blöcke von Daten Graphik-Animationsdaten aufweisen, die in den Rahmenpuffer geschrieben werden. Diese großen Blöcke von Daten sind als mehrere Reihen von Pixeln, die als "Abtastlinien" bezeichnet werden, organisiert. Die Daten sind in dem Hostprozessorspeicher als ein Array von Daten organisiert, wobei die erste Date das äußerste linke Pixel der ersten Abtastlinie ist, dann fortschreitend entlang der Abtastlinie zu dem äußersten rechten Pixel der ersten Abtastlinie, dann zurück zu dem äußersten linken Pixel der zweiten Abtastlinie, usw. Dies bildet ein zweidimensionales Array von Pixeldaten, die zu dem Rahmenpuffer gesendet werden sollen.
Das Bündel besteht aus einer Anzahl von Zuerst-Hinein-Zuerst-Heraus-Registern (FIFO-Registern), die bei 510 gezeigt sind. Die FIFOs sind in Bänken organisiert. Es existieren von 1 bis "n" Bänke von FIFOs. Jede FIFO-Bank puffert Pixel entlang der Abtastlinie. Die Anzahl von Pixeln, die entlang einer Abtastlinie gepuffert wird, ist abhängig von der Tiefe der FIFOs. Mehrere Abtastlinien, gleich der Anzahl von FIFO-Bänken, können gepuffert werden. Das Eingangstor und das Ausgangstor der FIFOs arbeiten unabhängig. Daten werden von dem Hostprozessor 20 unabhängig zu den FIFO-Eingangstoren übertragen und parallel zu Daten, die von den FIFO-Ausgangstoren zu dem Pixel-Cache 230 übertragen werden.
Die Bänke sind parallel verschaltet, wie aus dem Pipeline- Umgehungsbus 90 zu sehen ist. der Hostprozessor 20 schreibt Daten von einer Abtastlinie von Daten in das Eingangstor von einer der FIFO-Bänke, bis diese FIFO-Bank voll ist. Der Hostprozessor schreibt dann Daten von der nächsten Abtastlinie von Daten in das Eingangstor der nächsten FIFO-Bank.
Wenn in allen FIFO-Bänken Daten verfügbar sind, kann die Datenübertragung von dem Ausgangstor der FIFOs 510 zu dem Pixel-Cache beginnen. Dies geschieht parallel zu dem Senden von Daten des Hostprozessors 20 zu dem Eingangstor der FIFOs 510. Der Pixel-Cache 230 ist schnittstellenmäßig mit dem VRAM 70 verbunden, um zu ermglichen, daß Daten in dem Bündel 500 in den Rahmenpuffer geschrieben werden.
Die Graphik-Pipeline 50 wird dann geschlossen und die Pixeldatenübertragung von der Graphik-Pipeline 50 in den Rahmenpuffer 70 wird ausgesetzt, während die Datenübertragung von dem Bündel 500 aktiv ist. Da das Bündel 500 durch den Pipeline-Umgehungsbus 90 schnittstellenmäßig mit dem Pixel-Cache 230 verbunden ist, ist der Bedarf danach, die Graphik-Pipeline zu räumen, beseitigt.
Wenn nur eine Unter-Region "Unter-Block" des zweidimensionalen Bereichs von Pixeldaten zu dem Rahmenpuffer gesendet werden soll, ist eine Möglichkeit, um Daten von dem linken und dem rechten Rand abzuschneiden, vorgesehen. Zwei zusätzliche Versatzoperanden von dem Hostprozessor werden in den Adreßmanipulator 230 geschrieben. Die Versätze spezifizieren die Anzahl von Pixeln entlang einer Abtastlinie von dem Beginn der Abtastlinie zu dem rechten Rand und dem linken Rand des gewünschten Unter-Blocks von Daten. Diese Versätze weisen den Adreßmanipulator an, die Daten, die von den FIFOs 510 zu dem Pixel-Cache 230 übertragen werden, abzuschneiden; d.h. rechts oder links von dem gewünschten Unter-Block von Daten.
Bei bevorzugten Ausführungsbeispielen besteht das Bündel 500 aus einer Anzahl von Zuerst-Hinein-Zuerst-Heraus-Registern (FIFO-Registern), die allgemein bei 510 gezeigt sind. Die FIFOs 510 sind in dem Bündelblock 500 parallel miteinander verbunden. Die FIFOs 510 sind mit dem Pipeline-Umgehungsbus 90 schnittstellenmäßig verbunden, so daß der Hostprozessor 20 große Datenblöcke parallel zu jedem der FIFOs 510 bewegen kann. Die Datenmenge, die von dem Hostprozessor 20 zu dem Bündel 500 geleitet wird, ist nur durch die Anzahl von FIFOs begrenzt, die parallel in dem Bündelblock verschaltet sind.
Das Bündel 500 ist schnittstellenmäßig mit dem Pixel-Cache 230 verbunden, so daß dasselbe die Daten in den FIFOs 510 zu dem Pixel-Cache 230 übertragen kann, nachdem der Hostprozessor 20 die gewünschten Daten in die FIFOs 510 geschrieben hat. Der Pixel-Cache 230 ist schnittstellenmäßig mit dem VRAM 70 verbunden, um zu ermöglichen, daß Daten in dem Bündel 500 an den Rahmenpuffer übergeben werden. Da das Bündel 500 schnittstellenmäßig durch den Pipeline-Umgehungsbus 90 mit dem Pixel-Cache verbunden ist, ist die Graphik-Pipeline 50 frei, um eine Fenster-bezogene Aufbereitung anderer Graphikgrundelemente, die von dem Hostprozessor ausgegeben werden, durchzuführen. Daher reduziert die Verwendung des Bündels 500, das schnittstellenmäßig mit dem Graphik-Pipeline- Umgehungsbus 90 verbunden ist, die Graphik-Pipeline-Latenz und beseitigt den Bedarf danach, die Pipeline 50 zu räumen, wenn ein Kontextschalten für die Daten in dem Bündel 500 erwünscht ist.
Bei weiteren bevorzugten Ausführungsbeispielen ist der Adreßmanipulator 250 vorgesehen, der schnittstellenmäßig auf dem Pipeline-Umgehungsbus 90 verschaltet und zwischen dem Hostprozessor 20 und dem VRAM 70 angeordnet ist. Der Adreßmanipulator wirkt wie oben beschrieben und bereitet die Daten in dem Bündel 500 gemäß den Rahmenpuffer-bezogenen Adressen in dem VRAM 70 auf. Es ist notwendig, den Adreßmanipulator 250 zu verwenden, da die Daten, die von dem Hostprozessor 20 in die FIFOs 510 in dem Bündel 500 geschrieben werden, in Fenster-bezogenen Adressen auftreten können. Folglich schreibt der Hostprozessor 20 Fensterversatzadressen für die Daten in den FIFOs 510 in ein Datenregister in dem Adreßrnanipulator, so daß der Adreßmanipulator 250 die Daten in den FIFOs 510 gemäß den Rahmenpuffer-bezogenen Adressen in dem VRAM 70 aufbereiten kann.
Der Adreßmanipulator 250 richtet ferner Daten, die in die FIFOs 510 geschrieben sind, auf den Rahmenpuffer aus. Die Ausrichtung wird durch einen zusätzlichen Versatzoperanden von dem Hostprozessor 20 erreicht, der in den Adreßmanipulator 250 geschrieben wird, welcher den Adreßmanipulator anweist, Daten in den FIFOs 510 abzuschneiden, die in den Pixel-Cache 230 eingegeben werden und die aus den spezifizierten Blöcken in dem Rahmenpuffer 240 fallen, wenn die Daten aufbereitet werden. Bei bevorzugten Ausführungsbeispielen ist das Abschneiden notwendig, da die Blockdatenausgabe von dem Bündel 500 möglicherweise groß genug ist, um aus den speziellen Bestimmungsadressen in dem Rahmenpuffer zu fallen.
In Fig. 9A ist ein Flußdiagramm eines bevorzugten Ausführungsbeispiels der Übertragung von großen Datenblöcken von einem Hostprozessor zu einem Bündelblock gezeigt. Die Blockbestimmungsadressen werden durch die Pipeline-Umgehung in einem Schritt 520 in den Adreßmanipulator geschrieben. In gleicher Weise wird die Blockgröße in einem Schritt 530 durch den Pipeline-Umgehungsbus von dem Hostprozessor in den Adreßrnanipulator geschrieben. Es ist dann erwünscht, die Versätze des linken Rands und des rechten Rands durch die Pipeline-Umgehung in einem Schritt 540 in den Adreßmanipulator zu schreiben.
Die Versätze des linken Rands und des rechten Rands werden dann in einem Schritt 540 durch den Pipeline-Umgehungsbus in den Adreßmanipulator geschrieben. In einem Schritt 550 fragt der Hostprozessor die FIFOs ab, um zu bestimmen, ob in den FIFOs Platz ist. Wenn in den FIFOs kein Platz existiert, muß der Prozeß warten. Wenn jedoch Platz in den FIFOs existiert, fragt der Hostprozessor, ob Daten existieren, die in einem Schritt 560 übertragen werden sollen. Wenn keine Daten existieren, die übertragen werden sollen, endet der Prozeß. Wenn jedoch Daten existieren, die übertragen werden sollen, wird in einem Schritt 570 eine einzelne Date übertragen. Auf diese Weise können Daten von dem Hostprozessor in den Bündelblock übertragen werden.
In Fig. 9B ist ein bevorzugtes Ausführungsbeispiel eines Flußdiagramms zum Übertragen von Daten von einem Bündelblock zu einem Pixel-Cache gezeigt. Der Hostprozessor fragt den Bündelblock in einem Schritt 580 ab, um zu bestimmen, ob Daten in allen FIFOs verfügbar sind. Wenn nicht Daten von allen FIFOs verfügbar sind, muß der Prozeß warten. Wenn jedoch Daten von allen FIFOs verfügbar sind, werden Übertragungen einer einzelnen Date von dem Bündelblock zu dem Pixel-Cache in einem Schritt 590 durchgeführt. Der Hostprozessor fragt dann das System in einem Schritt 600 ab, um zu bestimmen, ob alle Daten übertragen wurden. Wenn alle Datenübertragungen stattgefunden haben, endet der Prozeß.
Wenn der Block nicht ausgerichtet ist, müssen die Daten, die aus dem Fenster fallen, von dem Block abgeschnitten werden, so daß dieselben nicht unerlaubterweise außerhalb des Fensters auf dem Bildschirm aufbereitet werden. Auf diese Weise können die Bündeldaten durch die Pipeline-Umgehung an den Rahmenpuffer übergeben werden, wodurch die Graphik-Pipeline von Operationen einer hohen Zusatzbelastung befreit wird. Daher erfüllen die Bündelübertragungsoperationen, die gemäß dieser Erfindung geliefert werden, einen in der Technik seit langem bekannten Bedarf nach Fenstersystemen, die die Fähigkeit aufweisen, eine große Pixeldatenmenge auf eine wirksame Art und Weise durch das System zu bewegen.
Verfahren und Vorrichtungen, die gemäß dieser Erfindung geliefert werden, die Hardwarelösungen für Pipeline-Umgehungsbusse in Fenstersystemen, die eine Graphik-Pipeline verwenden, implementieren, erfüllen einen in der Technik seit langem bekannten Bedarf nach Verfahren und Systemen, die den Bedarf nach einer Pipeline-Räurnung beseitigen und die Pipeline-Latenz reduzieren. Diese seit langem bekannten Bedürfnisse wurden durch frühere Graphikfenstersysteme, die Softwarelösungen verwenden, in der Technik nicht erfüllt. Graphikfenstersysteme gemäß dieser Erfindung, die Graphik-Pipelines verwenden, zeigen eine wesentliche Verbesserung verglichen mit früheren neuartigen Systemen, die Graphikgrundelemente für einen Rahmenpuffer oder einen Bildschirm aufbereiten. Die Graphikfenstersysterne, die gemäß dieser Erfindung geschaffen werden, behandeln Fenster als virtuelle Graphikvorrichtungen, wodurch der Bedarf nach einer Pipeline- Räumung während eines Kontextschaltens beseitigt ist und die Pipeline-Latenz stark reduziert ist.

Claims

1. Ein Computersystem zum Beseitigen des Bedarfs nach einer Pipeline-Räumung durch das Unterbrechen eines Datenflusses zwischen einer Aufbereitungsschaltung (60) und einem Rahmenpuffer (70), wobei das Computersystem ein Graphikuntersystem mit einem Rahmenpuffer und einer Pipeline (50) aufweist, wobei der Rahmenpuffer und die Aufbereitungsschaltung mit der Pipeline verbunden sind, wobei die Vorrichtung folgende Merkmale aufweist:

ein Markierungsregister (100), das zwischen die Aufbereitungsschaltung und den Rahmenpuffer in der Pipeline verschaltet ist, zum Verfolgen der mehreren Graphikkontexte, die die Pipeline durchlaufen, durch das Verfolgen von Markierungen, die die Pipeline durchlaufen;

einen Host (20), der mit der Pipeline verbunden ist, zum (i) Erzeugen von Graphikgrundelementen, (ii) Erzeugen von Graphikkontexten, und (iii) Erzeugen von Markierungen, wobei die Graphikgrundelemente, die Kontexte und die Markierungen zu der Pipeline geliefert werden, wobei eine Markierung zwischen jedem Graphikkontext vorgesehen ist; zum Abfragen des Markierungsregisters; und zum Unterbrechen des Datenflusses durch die Pipeline zu dem Rahmenpuffer als Reaktion auf das Verfolgen der mehreren Kontexte durch die Abfrage des Markierungsregisters durch den Host; und

eine Pipeline-Umgehung (90), die den Host mit dem Rahmenpuffer verbindet, und ein Stoppmarkierungsregister (110), das schnittstellenmäßig mit der Pipeline-Umgehung verbunden ist, zum Speichern eines vorbestimmten Werts, wobei der Wert zum Bestimmen dessen, welche der mehreren Kontexte in der Pipeline sind, verwendet wird.

2. Das System gemäß Anspruch 1, bei dem das Markierungsregister einen Markierungs-Wert zwischen jedem Kontextschalten speichert, und der Host den Datenfluß unterbricht, wenn der Stoppmarkierungs-Wert gleich dem Markierungs-Wert ist.

3. Das System gemäß Anspruch 2, bei dem das Stoppmarkierungsregister durch die Pipeline-Umgehung zwischen dem Host und dem Rahmenpuffer initialisiert wird.

4. Das System gemäß Anspruch 1, bei dem das Markierungsregister automatisch durch eine Markierung aktualisiert wird, die zwischen dem Host und dem Rahmenpuffer entlang der Pipeline gesendet wird.

5. Ein Verfahren zum Verfolgen von Daten oder Befehlen in einem Computergraphiksystem mit einer Pipeline und einem Rahmenpuffer, um eine Pipeline-Räumung zu beseitigen, wobei das Verfahren folgende Schritte aufweist:

Erzeugen von Daten oder Befehlen und Liefern der Daten oder Befehle zu der Pipeline;

Erzeugen von Markierungen, wobei jede der Markierungen einen Markierungs-Wert aufweist, und Liefern der Markierungen zu der Pipeline, derart, daß eine Markierung zwischen jeden Daten oder Befehlen vorgesehen ist, wobei die Markierungen die Pipeline durchlaufen;

Einrichten eines Stoppmarkierungs-Werts;

Überwachen der Pipeline an einem vorbestimmten Punkt in der Pipeline durch Zurkenntnisnahme nehmen der Markierungswerte, während die Markierungen die Pipeline durchlaufen;

durch das Bestimmen, ob eine Markierung, die einen Wert aufweist, der gleich dem Stoppmarkierungs-Wert ist, den vorbestimmten Punkt passiert hat, durch das Abfragen der zur Kenntnis genommenen Markierungs-Werte; und

Abfragen des Datenflusses durch die Pipeline zu dem Rahmenpuffer als Reaktion auf die Abfrage der zur Kenntnis genommenen Markierungs-Werte.

6. Das Verfahren gemäß Anspruch 5 zum Überwachen der Daten oder Befehle, das ferner folgende Schritte aufweist:

Positionieren eines Markierungsregisters in der Pipeline an dem vorbestimmten Punkt;

Aufzeichnen des Werts der Markierungen, die das Markierungsregister passieren, in dem Markierungsregister;

Überprüfen des Markierungsregisters an dem vorbestimmten Punkt; und

Halten der Daten oder Befehle in dem Rahmenpuffer, wenn der Wert, der in dem Markierungsregister gespeichert ist, gleich dem Stoppmarkierungs-Wert ist.

7. Das Verfahren gemäß Anspruch 6, bei dem der Schritt des Erzeugens von Markierungen folgenden Schritt aufweist:

Inkrementieren des Markierungs-Werts um einen vorbestimmten Betrag zu der Zeit, zu der jede Markierung erzeugt wird.

8. Das Verfahren gemäß Anspruch 7, bei dem das Pipelinesystem in einem Graphikfenstersystern verwendet wird.

9. Das Verfahren gemäß Anspruch 8, bei dem der Stoppmarkierungs-Wert in einem Stoppmarkierungsregister gespeichert wird.

10. Das Verfahren gemäß Anspruch 9, bei dem die Daten oder Befehle Graphikkontexte sind.