DE102012213631B4

DE102012213631B4 - Zwischenspeichern von Kontextdatenstrukturen in einer Vektorregisterdatei zum Beibehalten von Zustandsdaten in einer Multithread-Bildverarbeitungs-Pipeline

Info

Publication number: DE102012213631B4
Application number: DE102012213631.2A
Authority: DE
Inventors: Eric O. Mejdrich; Paul E. Schardt; Robert A. Shearer; Matthew R. Tubbs
Original assignee: International Business Machines Corp
Current assignee: Samsung Electronics Co Ltd
Priority date: 2011-08-18
Filing date: 2012-08-02
Publication date: 2019-03-07
Anticipated expiration: 2032-08-03
Also published as: CN103092772B; US20130044117A1; CN103092772A; GB2493808B; GB201209171D0; GB2493808A; DE102012213631A1; US8836709B2

Abstract

In einer Multithread-Grafikverarbeitungsarchitektur verwendete, häufig genutzte Zustandsdaten werden in einer Vektorregisterdatei einer Verarbeitungseinheit zwischengespeichert, um Zugriffe auf die Zustandsdaten zu optimieren und die damit verbundene Verwendung des Speicherbusses zu minimieren. Eine Verarbeitungseinheit kann eine Festkomma-Ausführungseinheit sowie eine Vektor-Gleitkomma-Ausführungseinheit enthalten, und eine von der Vektor-Gleitkomma-Ausführungseinheit verwendete Vektorregisterdatei kann dazu verwendet werden, von der Festkomma-Ausführungseinheit verwendete und nach Bedarf in die Universalregister übertragene Zustandsdaten zwischenzuspeichern, wodurch der Bedarf für das wiederholte Abrufen und Zurückschreiben der Zustandsdaten von und in einen L1-Cachespeicher oder einen Cachespeicher auf niedrigerer Ebene, auf den die Festkomma-Ausführungseinheit zugreift, verringert wird.

Description

Gebiet der Erfindung
Die Erfindung betrifft allgemein die Datenverarbeitung und insbesondere die grafische Bildverarbeitung und Wiedergabe (rendering).
Hintergrund der Erfindung
Der Prozess des Wiedergebens von zweidimensionalen Bildern aus dreidimensionalen Szenen wird häufig Bildverarbeitung genannt. Mit zunehmender Entwicklung der modernen Computerindustrie entwickelt sich auch die Bildverarbeitung weiter. Ein bestimmtes Ziel bei der Entwicklung der Bildverarbeitung besteht darin, zweidimensionale Simulationen bzw. Darstellungen von dreidimensionalen Szenen so realistisch wie möglich zu gestalten. Eine Einschränkung beim Wiedergeben realistischer Bilder besteht darin, dass moderne Bildschirme Bilder durch die Verwendung von Pixeln anzeigen.
Bei einem Pixel handelt es sich um die kleinste Fläche, die auf einem Bildschirm beleuchtet werden kann. Die meisten modernen Computerbildschirme verwenden eine Kombination aus hunderttausenden bzw. Millionen von Pixeln, um die gesamte Anzeige bzw. wiedergegebene Szene zusammenzusetzen. Die einzelnen Pixel sind in einem Gitterraster angeordnet und decken gemeinsam den gesamten Sichtbereich des Bildschirms ab. Jedes einzelne Pixel kann beleuchtet werden, um ein endgültiges Bild zum Betrachten wiederzugeben.
Eine Technik zum Wiedergeben einer realen dreidimensionalen Szene auf einem zweidimensionalen Bildschirm unter Verwendung von Pixeln ist die Rasterung. Bei der Rasterung handelt es sich um den Prozess des Umwandelns eines in Vektorformat (mathematische Darstellung von geometrischen Objekten in einer Szene) dargestellten zweidimensionalen Bildes in einzelne Pixel zum Anzeigen auf dem Bildschirm. Die Rasterung ist effektiv beim schnellen Wiedergeben von Grafik unter Verwendung von relativ geringen Mengen an Rechenleistung; allerdings leidet die Rasterung unter mehreren Nachteilen. Die Rasterung leidet zum Beispiel häufig unter mangelhaftem Realismus, da sie nicht auf den physischen Eigenschaften von Licht beruht, sondern stattdessen auf der Form von dreidimensionalen geometrischen Objekten in einer auf eine zweidimensionale Ebene abgebildeten Szene beruht. Des Weiteren skaliert die zum Wiedergeben einer Szene durch Rasterung benötigte Rechenleistung direkt mit einer Erhöhung der Komplexität der wiederzugebenden Szene. Mit immer realistischerer Bildverarbeitung werden auch wiedergegebene Szenen komplexer. Deshalb leidet die Rasterung unter der Entwicklung der Bildverarbeitung, da die Rasterung direkt mit der Komplexität skaliert.
Beruhend auf realistischerer physischer Modellierung wurden mehrere alternative Techniken entwickelt, die eine reale dreidimensionale Szene auf einem zweidimensionalen Bildschirm unter Verwendung von Pixeln wiedergeben. Eine derartige Technik zur physischen Wiedergabe wird punktweise Betrachtung genannt. Die Technik der punktweisen Betrachtung verfolgt die Ausbreitung imaginärer Strahlen, sich gleichartig wie Lichtstrahlen verhaltender Strahlen, in einer dreidimensionalen Szene, die auf einem Computerbildschirm wiederzugeben ist. Die Strahlen stammen von dem Auge/den Augen eines hinter dem Computerbildschirm sitzenden Betrachters und laufen durch Pixel, die den Computerbildschirm bilden, in Richtung der dreidimensionalen Szene. Jeder verfolgte Strahl rückt in die Szene vor und kann andere Objekte innerhalb der Szene schneiden. Wenn ein Strahl ein Objekt in der Szene schneidet, werden Eigenschaften des Objekts und mehrere andere entscheidende Faktoren dazu verwendet, die Farb- und Lichtmenge bzw. das Nichtvorhandensein selbiger zu berechnen, welcher der Strahl ausgesetzt wird. Diese Berechnungen werden dann zum Bestimmen der endgültigen Farbe des Pixels verwendet, das der verfolgte Strahl durchlaufen hat.
Der Prozess des Verfolgens von Strahlen wird für eine Szene viele Male ausgeführt. Ein einzelner Strahl kann zum Beispiel für jedes Pixel in der Anzeige verfolgt werden. Sobald eine ausreichend hohe Anzahl von Strahlen verfolgt wurde, um die Farbe aller Pixel zu bestimmen, welche die zweidimensionale Anzeige des Computerbildschirms bilden, kann dem Betrachter die zweidimensionale Synthese der dreidimensionalen Szene auf dem Computerbildschirm angezeigt werden.
Die punktweise Betrachtung gibt reale dreidimensionale Szenen üblicherweise realistischer wieder als die Rasterung. Dies liegt teilweise daran, dass die punktweise Betrachtung simuliert, wie sich Licht fortbewegt und in einer realen Umgebung verhält, anstatt einfach eine dreidimensionale Form auf eine zweidimensionale Ebene abzubilden, wie es bei der Rasterung durchgeführt wird. Deshalb bildet eine durch punktweise Betrachtung wiedergegebene Grafik genauer auf einem Bildschirm ab, was unsere Augen in der Realität zu sehen gewohnt sind.
Des Weiteren bewältigt die punktweise Betrachtung auch Steigerungen in der Komplexität einer Szene besser als die Rasterung, wenn Szenen komplexer werden. Die punktweise Betrachtung skaliert logarithmisch mit der Komplexität einer Szene. Der Grund dafür liegt darin, dass dieselbe Anzahl von Strahlen in eine Szene geworfen werden kann, selbst wenn die Szene komplexer wird. Deshalb leidet die punktweise Betrachtung nicht wie die Rasterung in Bezug auf Rechenleistungsanforderungen bei komplexeren Szenen.
Ein wesentlicher Nachteil der punktweisen Betrachtung liegt jedoch in der großen Anzahl von Berechnungen und somit der Verarbeitungsleistung, die zum Wiedergeben von Szenen erforderlich sind. Dies führt zu Problemen, wenn eine schnelle Wiedergabe benötigt wird, z.B. wenn ein Bildverarbeitungssystem Grafiken zum Zwecke der Animation wie in einer Spielkonsole in Echtzeit wiedergeben muss. Auf Grund der höheren Rechenanforderungen für die punktweise Betrachtung ist es schwierig, eine Animation schnell genug wiederzugeben, damit diese realistisch erscheint (eine realistische Animation liegt bei etwa zwanzig bis vierundzwanzig Einzelbildern pro Sekunde).
Mit zunehmenden Verbesserungen in der Halbleitertechnologie in Bezug auf Taktgeschwindigkeit und durch die vermehrte Nutzung von Parallelverarbeitung wird die Rasterung jedoch für komplexere Bilder umsetzbar, und die Wiedergabe von Szenen in Echtzeit unter Verwendung von physischen Wiedergabetechniken wie punktweise Betrachtung wird zu einer praktischeren Alternative zur Rasterung. Auf Chip-Ebene werden häufig mehrere Prozessorkerne auf demselben Chip angeordnet, die auf im Wesentlichen gleiche Weise wie separate Prozessor-Chips bzw. zu einem gewissen Maße wie vollständig separate Computer funktionieren. Außerdem wird selbst innerhalb von Kernen Parallelverarbeitung durch die Verwendung von mehreren Ausführungseinheiten eingesetzt, die darauf spezialisiert sind, bestimmte Arten von Arbeitsschritten zu bewältigen. Auf Hardware beruhendes Pipelining wird auch in vielen Fällen eingesetzt, damit bestimmte Arbeitsschritte, deren Ausführung mehrere Taktzyklen benötigen kann, in Stufen aufgeteilt werden, wodurch es möglich wird, andere Arbeitsschritte vor dem Abschluss früherer Arbeitsschritte zu beginnen. Multithreading wird auch eingesetzt, um das parallele Verarbeiten mehrerer Anweisungsströme zu ermöglichen, wodurch mehr allgemeine Aufgaben in jedem beliebigen Taktzyklus durchgeführt werden können.
Unabhängig davon, ob zum Wiedergeben von Bilddaten für eine Szene eine auf Rastern beruhende oder eine physische Wiedergabe durchgeführt wird, stellt die häufigere Verwendung von Parallelverarbeitung einige Herausforderungen in Bezug darauf dar, in einer parallelisierten Multithread-Architektur einen kohärenten Zustand beizubehalten. Als Beispiel sind herkömmliche Grafik-Software-Schnittstelle zur Anwendungsprogrammierung (APIs), bei denen es sich um die Bibliotheken von Routinen handelt, die von Anwendungsprogrammen zum Steuern des Wiedergabeprozesses aufgerufen werden (z.B. OpenGLTM und DirectXTM), nicht speziell auf das Verwalten von Zustandsdaten in einer Multithread-Umgebung ausgelegt. Einzelthread-Grafikcode geht (aus Sicht eines Anwendungsprogramms) für jeden Arbeitsschritt von einem einzelnen einheitlichen Zustand aus, und als solches erwarten herkömmliche Grafik-Software-APIs üblicherweise, dass beim Ausführen von Funktionsaufrufen die richtige Reihenfolge eingehalten wird, was wiederum erfordert, dass Funktionsaufrufe mit gemischten Zustandsvariablen und Funktionsaufrufe zum Zeichnen in der richtigen Reihenfolge bleiben.
Als Beispiel kann ein Einzel-Thread-Anwendungsprogramm beim Zeichnen eines Basiselements die folgenden Funktionsaufrufe durchführen:
In diesem Code wird jeder Scheitelpunkt (vertex) eines Dreiecks, das durch den Funktionsaufruf glVertex3f() festgelegt ist, gemäß des vorhergehenden Funktionsaufrufs glColor() auf eine unterschiedliche Farbe gesetzt. Der erste Scheitelpunkt wird somit auf grün gesetzt, der zweite Scheitelpunkt wird auf blau gesetzt, und der dritte Scheitelpunkt wird auf rot gesetzt.
In einer Einzel-Thread-Hardware-Umgebung stellt das Verarbeiten des oben genannten Codes keine Kohärenzprobleme dar, da als Ergebnis des vorhergehenden Funktionsaufrufs glColor() der erste Scheitelpunkt festgelegt wird, nachdem die Farbe auf grün gesetzt wird, und der zweite Scheitelpunkt festgelegt wird, nachdem die Farbe auf blau geändert wurde. Die Zustandsänderung von einer grünen Scheitelpunktfarbe zu einer blauen Scheitelpunktfarbe wird als Ergebnis der seriellen Verarbeitung der Funktionsaufrufe in dem Code sichergestellt.
In einer Multithread-Hardware-Umgebung kann es jedoch wünschenswert sein, dass unterschiedliche Funktionsaufrufe in parallelen Hardware-Threads bewältigt werden, um den Gesamtdurchsatz zu erhöhen, wünschenswerterweise ohne irgendeine spezielle Thread-Verwaltung durch ein Anwendungsprogramm zu erfordern. Auf der Grundlage der Arbeitslast des Thread kann die Reihenfolge, in der bestimmte Funktionsaufrufe in unterschiedlichen Threads ausgeführt werden, nicht garantiert werden, woraus sich mögliche Kohärenzprobleme ergeben.
Folglich kann die Verwendung von Parallelverarbeitung in dem oben genannten Code die Möglichkeit bereitstellen, jeden Scheitelpunkt für das Basiselement in separaten Threads festzulegen und somit die zum Festlegen des Basiselements benötigte Zeit zu verkürzen. Die Scheitelpunktfarbe stellt jedoch einen gemeinsam genutzten Zustand bzw. Kontext dar, da das Setzen der Farbe mit einem Funktionsaufruf glColor() die für alle nachfolgenden Funktionsaufrufe verwendete Farbe setzt, bis die Farbe durch einen anderen Funktionsaufruf glColor() geändert wird. Deshalb müssen Schritte ergriffen werden, um zum Beispiel sicherzustellen, dass die auf jeden Scheitelpunkt angewendete Scheitelpunktfarbe gemäß den durch das Anwendungsprogramm ausgegebenen Funktionsaufrufen korrekt ist. Andernfalls könnte zum Beispiel der zweite Funktionsaufruf glColor(), der die Scheitelpunktfarbe von grün zu blau ändert, möglicherweise die Scheitelpunktfarbe ändern, bevor der erste Scheitelpunkt durch den Funktionsaufruf glVertex() festgelegt wird, was dazu führt, dass der erste Scheitelpunkt auf die falsche Farbe gesetzt wird.
Obgleich Synchronisierung verwendet werden kann, um Arbeitsschritte in serielle Reihenfolge zu bringen und einen kohärenten Zustand beizubehalten, schränkt dies die möglichen Verbesserungen der Leistungsfähigkeit ein, die andernfalls als Folge von Parallelverarbeitung erzielt werden könnten, insbesondere dann, wenn ein bestimmter Thread darauf warten muss, dass andere Threads bestimmte Punkte erreichen, bevor dieser Thread fortfahren kann. Deshalb gibt es nach dem Stand der Technik einen Bedarf für eine verbesserte Art des Beibehaltens von kohärenten Zustandsdaten in einer Multithread-Grafikverarbeitungsarchitektur.
Des Weiteren können auf Grund von mit dem Zugriff auf Zustandsdaten durch mehrere Threads verbundenen Einschränkungen der Speicherbandbreite zusätzliche Probleme mit der Leistungsfähigkeit auftreten, selbst wenn Probleme mit der seriellen Reihenfolge in Bezug auf Zustandsdaten angegangen werden. Insbesondere kann das in einer Multithread-Grafikverarbeitungsarchitektur verwendete Lesen und Schreiben von häufig genutzten Zustandsdaten für Speicherbusse eine erhebliche Last mit sich bringen und die für andere Aktivitäten verfügbare Bandbreite verringern. Deshalb gibt es auch einen erheblichen Bedarf für eine Art und Weise zum Verringern der mit dem Zugreifen auf Zustandsdaten in einer Multithread-Grafikverarbeitungsarchitektur verbundenen Speicherbandbreite.
Die US 2009/0 231 349 A1 betrifft eine Pipeline-Architektur mit Multithread-Rendering-Software mit einer rollenden Kontextdatenstruktur, die zum Speichern mehrerer Kontexte verwendet wird, die verschiedenen Bildelementen zugeordnet sind, die in der Software-Pipeline verarbeitet werden. Jeder Kontext speichert Zustandsdaten für ein bestimmtes Bildelement, und die Zuordnung jedes Bildelements zu einem Kontext wird beibehalten, wenn das Bildelement von Stufe zu Stufe der Software-Pipeline weitergegeben wird, wodurch sichergestellt wird, dass der von den verschiedenen Stufen der Die Software-Pipeline bleibt bei der Verarbeitung des Bildelements kohärent, unabhängig von Zustandsänderungen, die für andere Bildelemente vorgenommen werden, die von der Software-Pipeline verarbeitet werden. Somit sind Zustandsdaten in einem Kontext, der einem Bildelement zugeordnet ist, in Reaktion auf eine Änderung an Zustandsdaten in einem anderen Kontext, der während der Verarbeitung des anderen Bildelements durch die Multithread-Rendering-Software-Pipeline einem anderen Bildelement zugeordnet ist, in der Regel unverändert.
Ein Kontext ist üblicherweise einem oder mehreren in ein wiedergegebenes Bild zu platzierenden Bildelementen wie Basiselementen, Scheitelpunkten, Objekten usw. zugehörig und wird dazu verwendet, einen kohärenten Zustand für diese Bildelemente beizubehalten, wenn auf diese Bildelemente in unterschiedlichen Stufen einer Software-Pipeline Arbeitsschritte ausgeführt werden. Ein Kontext wird üblicherweise nicht zwischen Stufen einer Pipeline im Datenstrom übertragen, sondern wird stattdessen in einem gemeinsam genutzten Speicher beibehalten, auf den die Stufen der Pipeline zugreifen können.
Die US 2009 / 0 231 349 A1 offebart jedoch nicht die Anwendung von Zwischenspeichern von Kontextdaten in einer Vektorregisterdatei zur Optimierung von Zugriff auf Kontextdaten sowie auf andere von einer Multithread-Grafikverarbeitungsarchitektur verwendete Zustandsdaten. Auf diese Herangehensweise wird im Kapitel „Zwischenspeichern von Kontextdaten in einer Vektorregisterdatei“ weiter unten eingegangen.
Zusammenfassung der Erfindung
Die Erfindung geht diese und andere dem Stand der Technik zugehörige Probleme an, indem sie in einer Multithread-Grafikverarbeitungsarchitektur verwendete, häufig genutzte Zustandsdaten in einer Vektorregisterdatei einer Verarbeitungseinheit zwischenspeichert, um Zugriffe auf die Zustandsdaten zu optimieren und die damit verbundene Verwendung des Speicherbusses zu minimieren. In Ausführungsformen in Übereinstimmung mit der Erfindung kann eine Schaltkreisanordnung eine Verarbeitungseinheit und ein Speicher umfassen, der mit der Verarbeitungseinheit verbunden ist und zum Zwischenspeichern von Daten dient, wobei die Verarbeitungseinheit eine Festkomma-Ausführungseinheit sowie eine Vektor-Gleitkomma-Ausführungseinheit enthalten kann, und eine von der Vektor-Gleitkomma-Ausführungseinheit verwendete Vektorregisterdatei kann dazu verwendet werden, von der Festkomma-Ausführungseinheit verwendete Zustandsdaten zwischenzuspeichern, darunter Nicht-Gleitkomma-Zustandsdaten, so dass die Zustandsdaten nach Bedarf in die Universalregister über einen zugewiesenen Bus zwischen der Vektorregisterdatei und den mehreren Universalregistern übertragen werden können, auf welche die Festkomma-Ausführungseinheit zugreifen kann, wodurch der Bedarf für das wiederholte Abrufen und Zurückschreiben der Zustandsdaten von und in einen L1-Cachespeicher oder einen Cachespeicher auf niedrigerer Ebene, auf den die Festkomma-Ausführungseinheit zugreift, verringert wird. Insbesondere in Anwendungen, in denen eine Vektorregisterdatei für bestimmte Aufgaben nicht ausgelastet ist, können sonst ungenutzte Vektorregister anderweitig zur Verwendung als kurzzeitige Zwischenspeicher verwendet werden und den mit derartigen Zustandsdaten verbundenen Speicherverwaltungsaufwand erheblich verringern. Des Weiteren kann durch die Verwendung von Anweisungen zum Packen/Entpacken und durch schnelle Verschiebungen zwischen den Universalregistern und der Vektorregisterdatei in einigen Ausführungsformen der Erfindung der Verbrauch von wertvollem Registerspeicher und die mit dem Zugreifen auf Zustandsdaten verbundene Latenzzeit außerdem minimiert werden.
Ein weiterer Aspekt der Erfindung betrifft ein Verfahren zum Zwischenspeichern von Zustandsdaten in einer Verarbeitungseinheit, die mit einem Speicher verbunden ist, und die eine Festkomma- Ausführungseinheit und eine Vektor-Gleitkommaeinheit enthält, wobei die Festkomma-Ausführungseinheit eine Vielzahl von Universalregistern enthält und die Vektor-Gleitkommaeinheit eine Vektorregisterdatei enthält, wobei das Verfahren Folgendes umfasst:

Zwischenspeichern von Zustandsdaten, darunter von der Festkomma-Ausführungseinheit verwendete Nicht-Gleitkomma-Zustandsdaten, in der Vektorregisterdatei;
Kopieren der Nicht-Gleitkomma-Zustandsdaten von der Vektorregisterdatei in mindestens ein Universalregister aus der Vielzahl von Universalregistern über einen zugewiesenen Bus zwischen der Vektorregisterdatei und den mehreren Universalregistern; und
Ausführen von Arbeitsschritten mit den in dem mindestens einen Universalregister gespeicherten Nicht-Gleitkomma-Zustandsdaten.

Gemäß einer Ausführungsform der Erfindung umfasst das Verfahren ferner eine Abänderung der in dem mindestens einen Universalregister gespeicherten Nicht-Gleitkomma-Zustandsdaten, wobei die Nicht-Gleitkomma-Zustandsdaten von dem mindestens einen Universalregister in die Vektorregisterdatei kopiert werden.
Gemäß einer Ausführungsform der Erfindung sind die Zustandsdaten einer Kontextdatenstruktur zur Verwendung beim Speichern von Zustandsdaten zugehörig, die von einer Vielzahl von Stufen in einer Multithread-Wiedergabe-Software-Pipeline in einer Grafikverarbeitungsarchitektur gemeinsam genutzt werden, wobei das Verfahren ferner das Ausführen von mindestens einem Thread für die Multithread-Wiedergabe-Software-Pipeline in der Verarbeitungseinheit umfasst, und wobei eine Kopie der Kontextdatenstruktur in einem Speicher behalten wird, mit dem die Verarbeitungseinheit verbunden ist.
Gemäß einer Ausführungsform der Erfindung umfasst das Verfahren ferner das Synchronisieren von zumindest einem Teil der in der Vektorregisterdatei gespeicherten Kontextdatenstruktur mit der Kopie der in dem Speicher gespeicherten Kontextdatenstruktur durch Schreiben des Teils der in der Vektorregisterdatei gespeicherten Kontextdatenstruktur zurück in den Speicher.
Gemäß einer Ausführungsform der Erfindung umfasst das Verfahren ferner das Ermitteln, ob sich der Teil der in der Vektorregisterdatei gespeicherten Kontextdatenstruktur vor dem Schreiben des Teils der Kontextdatenstruktur zurück in den Speicher geändert hat, wobei das Schreiben des Teils der Kontextdatenstruktur zurück in den Speicher als Reaktion auf das Ermitteln, dass sich der Teil der in der Vektorregisterdatei gespeicherten Kontextdatenstruktur nicht geändert hat, unterdrückt wird.
Gemäß einer Ausführungsform der Erfindung umfasst das Verfahren ferner das Komprimieren von Daten aus der in dem Speicher gespeicherten Kontextdatenstruktur beim Zwischenspeichern der Zustandsdaten in der Vektorregisterdatei und das Dekomprimieren von Daten aus der Kontextdatenstruktur in der Vektorregisterdatei beim Zurückschreiben von Daten aus der Kontextdatenstruktur in den Speicher.
Gemäß einer Ausführungsform der Erfindung enthält die Kontextdatenstruktur eine rollierende (rolling) Kontextdatenstruktur, auf die von der Vielzahl von Stufen in der Multithread-Wiedergabe-Software-Pipeline zugegriffen werden kann, wobei die rollierende Kontextdatenstruktur so konfiguriert ist, dass sie eine Vielzahl von Kontexten speichern kann, wobei jeder Kontext so konfiguriert ist, dass er Zustandsdaten für mindestens ein Bildelement speichert, während das mindestens eine Bildelement durch die Vielzahl von Stufen der Multithread-Wiedergabe-Software-Pipeline verarbeitet wird, wobei das Verfahren ferner das Zuordnen eines Kontexts in der rollierenden Kontextdatenstruktur zu jedem Bildelement umfasst, so dass Zustandsdaten in einem ersten Kontext, der einem ersten Bildelement zugehörig ist, als Reaktion auf eine durchgeführte Änderung von Zustandsdaten in einem zweiten Kontext, der einem zweiten Bildelement zugehörig ist, während des Verarbeitens des zweiten Bildelements durch die Multithread-Wiedergabe-Software-Pipeline unverändert bleiben.
Gemäß einer Ausführungsform der Erfindung wird das zweite Bildelement durch die Multithread-Wiedergabe-Software-Pipeline nach dem ersten Bildelement empfangen, wobei das Verfahren ferner Folgendes umfasst:

als Reaktion auf das Empfangen des zweiten Bildelements durch die Multithread-Wiedergabe-Software-Pipeline das anfängliche Verknüpfen des zweiten Bildelements mit dem ersten Kontext; und
als Reaktion auf einen Versuch der Änderung der Zustandsdaten für das zweite Bildelement, während der erste Kontext für das erste Bildelement verwendet wird, das Kopieren der Zustandsdaten von dem ersten Kontext in den zweiten Kontext, das Verknüpfen des zweiten Bildelements mit dem zweiten Kontext und das Abändern der in dem zweiten Kontext gespeicherten Zustandsdaten.

Gemäß einer Ausführungsform der Erfindung umfasst das Verfahren ferner das Kennzeichnen des ersten Kontexts als verwendet als Reaktion darauf, dass die Zustandsdaten in dem ersten Kontext durch die Multithread-Wiedergabe-Software-Pipeline für das erste Bildelement verwendet werden, und das Kopieren der Zustandsdaten von dem ersten Kontext in den zweiten Kontext sowie das Verknüpfen des zweiten Bildelements mit dem zweiten Kontext als Reaktion auf das Ermitteln, dass der erste Kontext als verwendet gekennzeichnet ist.
Gemäß einer Ausführungsform der Erfindung enthalten die in jedem Kontext gespeicherten Zustandsdaten eine Vielzahl von Zustandsattributen, die aus der Gruppe ausgewählt wurden, die aus einem Verweis auf einen Farbpuffer, einem Verweis auf ein Kugelabbild, einem Verweis auf ein Texturabbild, ein Drehattribut, ein Beleuchtungsattribut, ein Mischattribut, eine Bildschirmverschiebung und Kombinationen daraus besteht.
Deshalb enthält eine Verarbeitungseinheit in Übereinstimmung mit einem Aspekt der Erfindung eine Festkomma-Ausführungseinheit und eine Vektor-Gleitkommaeinheit, wobei die Festkomma-Ausführungseinheit eine Vielzahl von Universalregistern enthält, und die Vektor-Gleitkommaeinheit eine Vektorregisterdatei enthält. Die Verarbeitungseinheit ist so konfiguriert, dass sie Zustandsdaten, darunter von der Festkomma-Ausführungseinheit verwendete Nicht-Gleitkomma-Zustandsdaten in der Vektorregisterdatei zwischenspeichert, und die Nicht-Gleitkomma-Zustandsdaten von der Vektorregisterdatei in mindestens ein Universalregister aus der Vielzahl von Universalregistern kopiert. Die Festkomma-Ausführungseinheit ist so konfiguriert, dass sie mit den in dem mindestens einen Universalregister gespeicherten Nicht-Gleitkomma-Zustandsdaten arbeitet.
Figurenliste
Bevorzugte Ausführungsformen der vorliegenden Erfindung werden nun lediglich beispielhaft unter Bezugnahme auf die beigefügten Zeichnungen beschrieben. Es zeigen:

1 ein Blockschaltbild einer beispielhaften automatisierten Datenverarbeitungsmaschine, die einen beispielhaften Computer enthält, der für die Datenverarbeitung in Übereinstimmung mit Ausführungsformen der vorliegenden Erfindung nützlich ist;
2 ein Blockschaltbild eines beispielhaften NOC, das in dem Computer aus 1 umgesetzt ist;
3 ein Blockschaltbild, das eine beispielhafte Umsetzung eines Knotens des NOC aus 2 ausführlicher veranschaulicht;
4 ein Blockschaltbild, das eine beispielhafte Umsetzung des IP-Blocks des NOC aus 2 veranschaulicht;
5 ein Blockschaltbild einer Thread-Pipeline-Software-Engine, die zum Umsetzen in dem NOC aus 2 geeignet ist;
6 ein Blockschaltbild einer beispielhaften Software-Pipeline, die zum Umsetzen in der Thread-Pipeline-Software-Engine aus 5 geeignet ist;
7 ein Blockschaltbild einer Verarbeitungseinheit, die eine rollierende Kontextdatenstruktur in Übereinstimmung mit der Erfindung enthält und zur Umsetzung in der Thread-Pipeline-Software-Engine aus 5 geeignet ist;
8 ein Blockschaubild einer beispielhaften Umsetzung der Wiedergabekontexttabelle, auf die in 7 Bezug genommen wird;
9 einen Ablaufplan, der den Programmablauf einer durch die Verarbeitungseinheit aus 7 ausgeführten Befehlsverarbeitungsroutine veranschaulicht;
10 ein Blockdiagramm einer beispielhaften Verarbeitungseinheit, die zur Umsetzung des Zwischenspeicherns von Zustandsdaten in Vektorregisterdateien in Übereinstimmung mit der Erfindung geeignet ist;
11 einen Ablaufplan, der eine beispielhafte Folge von Arbeitsschritten zum Laden von Zustandsdaten in die Verarbeitungseinheit aus 10 veranschaulicht; und
12 einen Ablaufplan, der eine beispielhafte Folge von Arbeitsschritten zum Speichern von Zustandsdaten in der Verarbeitungseinheit aus 10 veranschaulicht.

Ausführliche Beschreibung der bevorzugten Ausführungsform
Ausführungsformen in Übereinstimmung mit der Erfindung speichern in einer Multithread-Grafikverarbeitungsarchitektur verwendete, häufig genutzte Zustandsdaten in einer Vektorregisterdatei einer Verarbeitungseinheit zwischen, um Zugriffe auf die Zustandsdaten zu optimieren und die damit verbundene Verwendung des Speicherbusses zu minimieren. Dadurch kann der mit dem Abrufen und/oder Speichern von Zustandsdaten verbundene Verbrauch von Speicherbandbreite zwischen Verarbeitungseinheiten und Cachespeichern und Speichern auf niedrigerer Ebene erheblich verringert werden.
In Ausführungsformen in Übereinstimmung mit der Erfindung enthält eine in einer Multithread-Grafikverarbeitungsarchitektur verwendete Verarbeitungseinheit eine Festkomma-Ausführungseinheit mit einem oder mehreren Universalregistern, die mit einer Vektorausführungseinheit mit einer Vektorregisterdatei, wie zum Beispiel einer Vektor-Gleitkommaeinheit, verbunden sind. Zustandsdaten werden in einem oder mehreren Vektorregistern in der Vektorregisterdatei zwischengespeichert und nach Bedarf an ein oder mehrere Universalregister zur Verwendung durch die Festkomma-Ausführungseinheit übertragen. Als solche werden Übertragungen von Zustandsdaten zu und von einem L1-Cachespeicher oder einem Cachespeicher auf niedrigerer Ebene verringert, wodurch Speicherbandbreite für andere Aktivitäten aufrechterhalten wird und die Latenzzeit beim Zugreifen auf Zustandsdaten minimiert wird.
In einigen Ausführungsformen werden schnelle Verschiebungsarbeitsschritte angewendet, um Zustandsdaten direkt zwischen einer Vektorregisterdatei und Universalregistern zu übertragen. Außerdem können in einigen Ausführungsformen Zustandsdaten in einer Vektorregisterdatei komprimiert werden, und Anweisungen zum Packen bzw. Entpacken können dazu verwendet werden, in einer Vektorregisterdatei zwischengespeicherte Zustandsdaten zu komprimieren und zu dekomprimieren. Des Weiteren kann in einigen Ausführungsformen der Verbrauch von Speicherbandbreite weiter verringert werden, indem ermittelt wird, ob Zustandsdaten vor dem Zurückschreiben der Daten in den Speicher wie einen Cachespeicher geändert wurden.
In einer beispielhaften Ausführungsform der Erfindung wird das Zwischenspeichern in einer Vektorregisterdatei in Verbindung mit einer rollierenden Kontextdatenstruktur verwendet, die zum Speichern mehrerer Kontexte verwendet wird, die unterschiedlichen Bildelementen zugehörig sind, die in einer Multithread-Wiedergabe-Software-Pipeline verarbeitet werden. Jeder Kontext speichert Zustandsdaten für ein bestimmtes Bildelement, und die Verknüpfung jedes Bildelements mit einem Kontext wird beibehalten, wenn das Bildelement von Stufe zu Stufe in der Software-Pipeline geleitet wird, wodurch sichergestellt wird, dass der von den unterschiedlichen Stufen der Software-Pipeline beim Verarbeiten des Bildelements verwendete Zustand unabhängig von für andere durch die Software-Pipeline verarbeitete Bildelemente durchgeführten Zustandsänderungen kohärent bleibt. Als solche bleiben Zustandsdaten in einem Kontext, der einem Bildelement zugehörig ist, infolge einer Änderung von Zustandsdaten in einem anderen Kontext, der einem anderen Bildelement zugehörig ist, während des Verarbeitens des anderen Bildelements durch die Multithread-Wiedergabe-Software-Pipeline üblicherweise unverändert.
Ein Kontext ist üblicherweise einem oder mehreren in ein wiedergegebenes Bild zu platzierenden Bildelementen wie Basiselementen, Scheitelpunkten, Objekten usw. zugehörig und wird dazu verwendet, einen kohärenten Zustand für diese Bildelemente beizubehalten, wenn auf diese Bildelemente in unterschiedlichen Stufen einer Software-Pipeline Arbeitsschritte ausgeführt werden. Ein Kontext wird üblicherweise nicht zwischen Stufen einer Pipeline im Datenstrom übertragen, sondern wird stattdessen in einem gemeinsam genutzten Speicher beibehalten, auf den die Stufen der Pipeline zugreifen können. Separat durch die Software-Pipeline verarbeitete Bildelemente können so lange denselben Kontext teilen, wie alle Bildelemente denselben Zustand aufweisen; jedes Mal, jedoch, wenn der Zustand für ein bestimmtes Bildelement geändert werden muss, während dieses in der Software-Pipeline verarbeitet wird, und wenn diese Zustandsänderung nicht andere durch die Pipeline verarbeitete Bildelemente betrifft, kann der Zustand wünschenswerterweise in einen neuen Kontext kopiert werden, der nachfolgend für dieses Bildelement verwendet wird, wobei der ursprüngliche Kontext zur Verwendung mit den anderen Bildelementen beibehalten wird. Folglich werden für verschiedene Bildelemente effektiv separate Zustände beibehalten, wenn die Bildelemente in der Pipeline verarbeitet werden, wodurch Probleme bezüglich der Synchronisierung und/oder Kontextbeibehaltung in der Pipeline verringert werden und ein paralleleres und unabhängigeres Verarbeiten von Bildelementen ermöglicht wird. Durch Kombination mit einer hoch parallelen Multithread-Software-Wiedergabe-Pipeline kann man üblicherweise einen höheren Durchsatz von Bildelementen erhalten.
Die Zustandsdaten, die in einem Kontext beibehalten werden können, können beliebige Attribute bzw. Daten enthalten, die einen Zustand oder einen Kontext angeben, der wünschenswerterweise für ein Bildelement oder eine Gruppe von Bildelementen beibehalten wird, während das Element bzw. die Gruppe durch die Stufen einer Software-Wiedergabe-Pipeline geleitet werden. Die in jedem Kontext gespeicherten Zustandsdaten können zum Beispiel Attribute wie Verweise auf Farbpuffer, Verweise auf Kugelabbilder, Verweise auf Texturabbilder, Drehattribute, Beleuchtungsattribute, Mischattribute, Bildschirmverschiebungen und Kombinationen daraus enthalten. Diese Liste ist nicht erschöpfend, und als solche darf die Erfindung nicht auf die bestimmten, hierin beschriebenen Attribute beschränkt werden. Außerdem können Zustandsdaten für andere Arbeitsschritte in einer Multithread-Grafikverarbeitungsarchitektur verwendet werden, so dass die Erfindung nicht auf die speziellen Arten von Zustandsdaten beschränkt ist, die in den hierin erörterten Ausführungsformen verwendet werden.
Für einen Fachmann werden andere Abwandlungen und Abänderungen ersichtlich sein. Deshalb ist die Erfindung nicht auf die speziellen hierin erörterten Ausführungen beschränkt.
Hardware- und Software-Umgebung
Wenden wir uns nun den Zeichnungen zu, in denen gleiche Zahlen gleiche Teile in den mehreren Ansichten angeben, so veranschaulicht 1 eine beispielhafte automatisierte Datenverarbeitungsmaschine, die einen beispielhaften Computer 10 enthält, der für die Datenverarbeitung in Übereinstimmung mit Ausführungsformen der vorliegenden Erfindung nützlich ist. Der Computer 10 aus 1 enthält mindestens einen Computerprozessor 12 bzw. eine ,CPU‘ sowie den Direktzugriffsspeicher 14 (,RAM‘), der über einen Hochgeschwindigkeits-Speicherbus 16 und den Busadapter 18 mit dem Prozessor 12 und mit anderen Komponenten des Computers 10 verbunden ist.
In dem RAM 14 ist ein Anwendungsprogramm 20 gespeichert, ein Modul mit Computerprogrammanweisungen auf Benutzerebene zum Ausführen bestimmter Datenverarbeitungsaufgaben wie Textverarbeitung, Tabellenkalkulation, Datenbankoperationen, Videospiele, Aktienmarktsimulationen, atomare Quanten-Verarbeitungssimulationen oder andere Anwendungen auf Benutzerebene. In dem RAM 14 ist ebenfalls ein Betriebssystem 22 gespeichert. Zu Betriebssystemen, die in Verbindung mit Ausführungsformen der Erfindung nützlich sind, gehören UNIXTM, LinuxTM, Microsoft Windows XPTM, AIXTM, IBMs i5/OSTM und andere, wie einem Fachmann klar sein wird. Das Betriebssystem 22 und die Anwendung 20 in dem Beispiel aus 1 sind in dem RAM 14 gezeigt, wobei viele Komponenten derartiger Software üblicherweise auch in nichtflüchtigem Speicher, z.B. auf einem Plattenlaufwerk 24, gespeichert sind.
Wie nachfolgend besser ersichtlich wird, können mit der Erfindung übereinstimmende Ausführungsformen in Network-on-Chip- (NOC-) integrierten Schaltkreiseinheiten bzw. Chips umgesetzt werden, und als solches ist der Computer 10 als zwei beispielhafte NOCs enthaltend dargestellt: einen Videoadapter 26 und einen Coprozessor 28. Bei dem NOC-Video-Adapter 26, der alternativ Grafikadapter genannt werden kann, handelt es sich um einen E/A-Adapter, der speziell für die Grafikausgabe an eine Anzeigeeinheit 30 wie einen Anzeigeschirm oder Computerbildschirm entworfen wurde. Der NOC-Video-Adapter 26 ist mit dem Prozessor 12 über einen Hochgeschwindigkeits-Videobus 32, den Busadapter 18 und den Front-Side-Bus 34 verbunden, bei dem es sich auch um einen Hochgeschwindigkeitsbus handelt. Der NOC-Coprozessor 28 ist mit dem Prozessor 12 über den Busadapter 18 und die Front-Side-Busse 34 und 36 verbunden, bei denen es sich auch um einen Hochgeschwindigkeitsbus handelt. Der NOC-Coprozessor aus 1 kann zum Beispiel so optimiert sein, dass er bestimmte Datenverarbeitungsaufgaben auf Geheiß des Hauptprozessors 12 beschleunigt.
Der beispielhafte NOC-Video-Adapter 26 und der NOC-Coprozessor 28 aus 1 enthalten jeweils ein NOC, die integrierte Prozessor- (,IP‘-) Blöcke, Router, Speicher-Datenübertragungs-Steuereinheit und Netzwerkschnittstellen-Steuereinheiten enthalten, deren Einzelheiten ausführlicher in Zusammenhang mit den 2 bis 3 erörtert werden. Der NOC-Video-Adapter und der NOC-Coprozessor sind jeweils für Programme optimiert, die eine parallele Verarbeitung verwenden und auch einen schnellen Direktzugriff auf gemeinsam genutzten Speicher benötigen. Mit Unterstützung der vorliegenden Darlegung wird ein Fachmann jedoch verstehen, dass die Erfindung in anderen Einheiten und Einheitenarchitekturen als NOC-Einheiten und NOC-Einheitenarchitekturen umgesetzt werden kann. Die Erfindung ist deshalb nicht auf eine Umsetzung in einer NOC-Einheit beschränkt.
Der Computer 10 aus 1 enthält den Plattenlaufwerksadapter 38, der über einen Erweiterungsbus 40 und den Busadapter 18 mit dem Prozessor 12 und anderen Komponenten des Computers 10 verbunden ist. Der Plattenlaufwerksadapter 38 verbindet nichtflüchtigen Datenspeicher mit dem Computer 10 in Form der Plattenlaufwerke 24 und kann zum Beispiel unter Verwendung von IDE-Adaptern (Festplatten-Schnittstelle - Integrated Drive Electronics), SCSI-Adaptern (Kleinrechner-Schnittstelle - Small Computer System Interface) u.a. umgesetzt werden, wie einem Fachmann klar sein wird. Nichtflüchtiger Computerspeicher kann auch als optisches Plattenlaufwerk, elektrisch löschbarer programmierbarer Nur-Lese-Speicher (sogenannter ,EEPROM‘ bzw. ,Flash‘-Speicher), RAM-Laufwerke usw. umgesetzt werden, wie einem Fachmann klar sein wird.
Der Computer 10 enthält auch einen oder mehrere Eingabe/Ausgabe- (,E/A‘-) Adapter 42, die eine benutzerorientierte Eingabe/Ausgabe zum Beispiel durch Software-Treiber und Computer-Hardware zum Steuern einer Ausgabe an Anzeigeeinheiten wie Computeranzeigeschirme sowie Benutzereingaben von den Benutzereingabeeinheiten 44 wie Tastaturen und Mäusen umsetzen. Außerdem enthält der Computer 10 einen Datenübertragungsadapter 46 für den Datenaustausch mit anderen Computern 48 und für den Datenaustausch mit einem Datenübertragungsnetzwerk 50. Derartige Datenübertragungen können seriell über RS-232-Verbindungen, über externe Busse wie einen universellen seriellen Bus (,USB‘), über Datenübertragungsnetzwerke wie IP-Datenübertragungsnetzwerke und auf andere Arten ausgeführt werden, wie einem Fachmann klar sein wird. Datenübertragungsadapter setzen die Hardware-Ebene der Datenübertragung um, durch die ein Computer Datenübertragungen direkt oder über ein Datenübertragungsnetzwerk an andere Computer sendet. Zu Beispielen von Datenübertragungsadaptern, die zur Verwendung in dem Computer 10 geeignet sind, gehören Modems für drahtgebundene Einwähldatenübertragungen, Ethernet-(IEEE 802.3-) Adapter für drahtgebundene Datenübertragungs-Netzwerkdatenübertragungen sowie 802.11-Adapter für drahtlose Datenübertragungs-Netzwerkdatenübertragungen.
Zur näheren Erläuterung legt 2 ein Funktionsblockschaltbild eines beispielhaften NOC 102 gemäß Ausführungsformen der vorliegenden Erfindung dar. Das NOC in 2 ist auf einem ,Chip‘ 100 umgesetzt, d.h., auf einem integrierten Schaltkreis. Das NOC 102 enthält die integrierten Prozessor- (,IP‘-) Blöcke 104, die Router 110, die Speicher-Datenübertragungs-Steuereinheiten 106 und die Netzwerkschnittstellen-Steuereinheiten 108, die in zusammengeschaltete Knoten gruppiert sind. Jeder IP-Block 104 ist über eine Speicher-Datenübertragungs-Steuereinheit 106 und eine Netzwerkschnittstellen-Steuereinheit 108 mit einem Router 110 verbunden. Jede Speicher-Datenübertragungs-Steuereinheit steuert den Datenaustausch zwischen einem IP-Block und Speicher, und jede Netzwerkschnittstellen-Steuereinheit 108 steuert IP-Block-übergreifende Datenübertragungen über die Router 110.
In dem NOC 102 stellt jeder IP-Block eine wiederverwendbare Einheit mit einer synchronen oder asynchronen Logikstruktur dar, die als Modul für die Datenverarbeitung in dem NOC verwendet wird. Der Begriff ,IP-Block‘ wird manchmal als ,geistiger Eigentumsblock‘ ausgeschrieben, was einen IP-Block effektiv als eine Konstruktion kennzeichnet, die einer Partei gehört, d.h. das geistige Eigentum einer Partei zum Lizenzieren an andere Benutzer oder Entwickler von Halbleiter-Schaltkreisen darstellt. Im Umfang der vorliegenden Erfindung gibt es jedoch keine Notwendigkeit, dass IP-Blöcke irgendeinem Eigentumsrecht unterliegen müssen, so dass der Begriff in dieser Beschreibung immer als ,integrierter Prozessorblock‘ ausgeschrieben wird. Bei den hier beschriebenen IP-Blöcken handelt es sich um wiederverwendbare Einheiten eines Logik-, Zellen- oder Chip-Layout-Entwurfs, die einem geistigen Eigentum unterliegen können, aber nicht müssen. Bei IP-Blöcken handelt es sich um Logikkerne, die als ASIC-Chip-Entwürfe bzw. FPGA-Logikentwürfe gebildet werden können.
Eine Art zum Beschreiben von IP-Blöcken durch Analogien lautet, dass IP-Blöcke für NOC-Entwürfe das darstellen, was eine Bibliothek für das Programmieren von Computern darstellt oder was eine einzelne Komponente einer integrierten Schaltung für die Konstruktion von Leiterplatten bedeuten. In mit Ausführungsformen der vorliegenden Erfindung übereinstimmenden NOCs können IP-Blöcke als allgemeine Gatternetzlisten, als vollständige Spezial- oder Universal-Mikroprozessoren oder auf andere Arten umgesetzt werden, wie einem Fachmann klar sein wird. Bei einer Netzliste handelt es sich um eine boolesche Algebra-Darstellung (Gatter, Standardzellen) einer Logikfunktion eines IP-Blocks, analog einer Assembler-Code-Liste für eine höhere Programmanwendung. NOCs können zum Beispiel auch in synthetisierbarer Form umgesetzt werden, beschrieben in einer Hardware-Beschreibungssprache wie Verilog oder VHDL. Außer Umsetzungen als Netzliste und synthetisierbar, können NOCs auch in physischen Beschreibungen auf niedrigerem Niveau bereitgestellt werden. Analoge IP-Block-Elemente wie SERDES, PLL, DAC, ADC usw. können in einem Transistoranordnungsformat wie GDSII verteilt werden. Digitale Elemente von IP-Blöcken werden manchmal auch in Anordnungsformat (layout format) angeboten. Man wird auch verstehen, dass IP-Blöcke sowie andere Logikschaltungen, die in Übereinstimmung mit der Erfindung umgesetzt sind, in Form von Computerdatendateien wie Logikdefinitions-Programmcode verteilt werden können, welche die Funktionalität und/oder die Anordnung der eine derartige Logik umsetzenden Schaltkreisanordnungen in unterschiedlichen Detailstufen festlegen. Obwohl die Erfindung in Zusammenhang mit Schaltkreisanordnungen beschrieben wurde und nachfolgend beschrieben wird, die in voll funktionsfähigen integrierten Schaltungseinheiten, derartige Einheiten nutzenden Datenverarbeitungssystemen und anderen greifbaren, physischen Hardware-Schaltungen umgesetzt sind, wird ein Fachmann mit Unterstützung der vorliegenden Darlegung verstehen, dass die Erfindung auch in einem Programmprodukt umgesetzt werden kann, und dass die Erfindung gleichermaßen Anwendung findet, unabhängig von einer bestimmten Art von durch einen Computer lesbaren Speichermedium, das zum Verteilen des Programmprodukts verwendet wird. Zu Beispielen von durch einen Computer lesbaren Speichermedien gehören physische, beschreibbare Medien wie flüchtige und nichtflüchtige Speichereinheiten, Floppy-Disketten, Festplattenlaufwerke, CD-ROMs und DVDs (und andere), jedoch nicht darauf beschränkt.
Jeder IP-Block 104 in dem Beispiel aus 2 ist über eine Speicher-Datenübertragungs-Steuereinheit 106 mit einem Router 110 verbunden. Bei jeder Speicher-Datenübertragungs-Steuereinheit handelt es sich um eine Anhäufung synchroner und asynchroner Logikschaltungen, die dafür geeignet sind, Datenübertragungen zwischen einem IP-Block und Speicher bereitzustellen. Zu Beispielen für derartige Datenübertragungen zwischen IP-Blöcken und Speicher gehören Ladeanweisungen für einen Speicher und Speicheranweisungen für einen Speicher. Die Speicher-Datenübertragungs-Steuereinheiten 106 werden nachfolgend in Bezug auf 3 ausführlicher beschrieben. Jeder IP-Block 104 ist über eine Netzwerkschnittstellen-Steuereinheit 108, der die Datenübertragungen durch die Router 110 zwischen den IP-Blöcken 104 steuert, ebenfalls mit einem Router 110 verbunden. Zu Beispielen für Datenübertragungen zwischen IP-Blöcken gehören Nachrichten, die Daten und Anweisungen zum Verarbeiten der Daten zwischen IP-Blöcken in parallelen Anwendungen und in Pipeline-Anwendungen tragen. Die Netzwerkschnittstellen-Steuereinheiten 108 werden nachfolgend in Bezug auf 3 ebenfalls ausführlicher beschrieben.
Die Router 110 und die entsprechenden Verbindungen 118 zwischen diesen setzen die Netzwerkoperationen des NOC um. Bei den Verbindungen 118 kann es sich um Paketstrukturen handeln, die auf physischen, parallelen, sämtliche Router verbindenden Drahtbussen umgesetzt sind. Das heißt, jede Verbindung kann auf einem Drahtbus umgesetzt werden, der breit genug ist, um gleichzeitig ein gesamtes Datenvermittlungspaket aufzunehmen, das sämtliche Kopfzeilendaten und Nutzdaten beinhaltet. Wenn eine Paketstruktur zum Beispiel 64 Bytes enthält, darunter eine Kopfzeile mit acht Bytes und 56 Bytes an Nutzdaten, ist der Drahtbus gegenüber jeder Verbindung 64 Bytes breit, 512 Drähte. Außerdem kann jede Verbindung bidirektional sein, so dass der Drahtbus tatsächlich 1024 Drähte zwischen jedem Router und jedem seiner Nachbarn in dem Netzwerk enthält, wenn die Verbindungspaketstruktur 64 Bytes enthält. In einer derartigen Ausführung könnte eine Nachricht mehr als ein Paket enthalten, wobei jedes Paket aber genau auf die Breite des Drahtbusses passen würde. Alternativ kann eine Verbindung auf einem Drahtbus realisiert werden, der nur breit genug ist, um einen Teil eines Pakets aufzunehmen, so dass ein Paket in mehrere Teile (beats) aufgeteilt würde, z.B. so, dass ein 64-Byte-Paket in vier Teile aufgeteilt werden könnte, wenn eine Verbindung als 16 Bytes breit bzw. mit 128 Drähten umgesetzt wird. Man wird verstehen, dass verschiedene Ausführungen beruhend auf praktischen physischen Grenzen sowie auf gewünschten Leistungseigenschaften unterschiedliche Busbreiten verwenden können. Wenn die Verbindung zwischen dem Router und jedem Abschnitt des Drahtbusses Anschluss (port) genannt wird, enthält jeder Router fünf Anschlüsse, einen für jede der vier Richtungen einer Datenübertragung in dem Netzwerk und einen fünften Anschluss zum Anschließen des Routers an einen bestimmten IP-Block über eine Speicher-Datenübertragungs-Steuereinheit und eine Netzwerkschnittstellen-Steuereinheit.
Jede Speicher-Datenübertragungs-Steuereinheit 106 steuert Datenübertragungen zwischen einem IP-Block und Speicher. Zu Speicher kann chipexterner Haupt-RAM 112, über eine Speicher-Datenübertragungs-Steuereinheit 106 direkt mit einem IP-Block verbundener Speicher 114, chipintegrierter, als IP-Block freigegebener Speicher 116 sowie chipintegrierter Cachespeicher zählen. In dem NOC 102 kann einer der chipintegrierten Speicher 114, 116 zum Beispiel als chipintegrierter Cachespeicher umgesetzt sein. All diese Speicherformen können sich in demselben Adressraum befinden, als physische Adressen oder virtuelle Adressen, was sogar für den direkt mit einem IP-Block verbundenen Speicher gilt. Deshalb können speicheradressierte Nachrichten in Bezug auf IP-Blöcke vollständig bidirektional sein, da derartiger Speicher direkt von jedem beliebigen IP-Block irgendwo in dem Netzwerk aufgerufen werden kann. Der Speicher 116 in einem IP-Block kann von diesem IP-Block oder von jedem beliebigen anderen IP-Block in dem NOC aufgerufen werden. Der direkt mit einer Speicher-Datenübertragungs-Steuereinheit verbundene Speicher 114 kann durch den IP-Block aufgerufen werden, der durch diese Speicher-Datenübertragungs-Steuereinheit mit dem Netzwerk verbunden ist - und er kann ebenfalls von jedem beliebigen anderen IP-Block irgendwo in dem NOC aufgerufen werden.
Das NOC 102 enthält zwei Speicherverwaltungseinheiten (,MMUs', memory management units) 120, 122, die zwei alternative Speicherarchitekturen für NOCs in Übereinstimmung mit Ausführungsformen der vorliegenden Erfindung veranschaulichen. Die MMU 120 ist innerhalb eines IP-Blocks umgesetzt und ermöglicht es einem Prozessor innerhalb des IP-Blocks Arbeitsschritte in virtuellem Speicher durchzuführen, während die gesamte restliche Architektur des NOC Arbeitsschritte in einem physischen Speicheradressraum durchführt. Die MMU 122 ist chipextern umgesetzt und mit dem NOC über einen Datenübertragungsanschluss 124 verbunden. Der Anschluss 124 enthält die Anschlussstifte und andere zum Leiten von Signalen zwischen dem NOC und der MMU benötigte Anschlüsse sowie eine ausreichend hohe Intelligenz, um Nachrichtenpakete von dem NOC-Paketformat in das von der externen MMU 122 benötigte Busformat umzuwandeln. Die externe Lage der MMU bedeutet, dass sämtliche Prozessoren in sämtlichen IP-Blöcken der NOC Arbeitsschritte in virtuellem Speicheradressraum durchführen können, wobei sämtliche Umwandlungen in physische Adressen des chipexternen Speichers durch die chipexterne MMU 122 bewältigt werden.
Zusätzlich zu den beiden durch die Verwendung der MMUs 120, 122 veranschaulichten Speicherarchitekturen veranschaulicht der Datenübertragungsanschluss 126 eine dritte Speicherarchitektur, die in NOCs nützlich ist, die in Ausführungsformen der vorliegenden Erfindung verwendet werden können. Der Anschluss 126 stellt eine direkte Verbindung zwischen dem IP-Block 104 des NOC 102 und dem chipexternen Speicher 112 bereit. Ohne MMU in dem Verarbeitungspfad stellt diese Architektur die Verwendung eines physischen Adressraums durch sämtliche IP-Blöcke des NOC bereit. Durch das gemeinsame Nutzen des Adressraums auf bidirektionale Weise können sämtliche IP-Blöcke des NOC über durch den direkt mit dem Anschluss 126 verbundenen IP-Block geleitete, speicheradressierte Nachrichten, darunter Ladevorgänge und Speichervorgänge, auf Speicher in dem Adressraum zugreifen. Der Anschluss 126 enthält die Anschlussstifte und andere zum Leiten von Signalen zwischen dem NOC und dem chipexternen Speicher 112 benötigte Anschlüsse sowie eine ausreichend hohe Intelligenz, um Nachrichtenpakete von dem NOC-Paketformat in das von dem chipexternen Speicher 112 benötigte Busformat umzuwandeln.
In dem Beispiel aus 2 ist einem der IP-Blöcke ein Host-Schnittstellen-Prozessor 128 zugewiesen. Ein Host-Schnittstellen-Prozessor 128 stellt eine Schnittstelle zwischen dem NOC und einem Host-Computer 10 bereit, in dem das NOC installiert werden kann, und stellt ebenfalls den anderen IP-Blöcken in dem NOC Datenverarbeitungsdienste bereit, darunter zum Beispiel das Empfangen und Senden der NOC-Datenverarbeitungsanforderungen von dem Host-Computer zwischen den IP-Blöcken. Ein NOC kann zum Beispiel einen Videografikadapter 26 oder einen Coprozessor 28 auf einem größeren Computer 10 als oben in Bezug auf 1 beschrieben realisieren. In dem Beispiel aus 2 ist der Host-Schnittstellen-Prozessor 128 mit dem größeren Host-Computer durch einen Datenübertragungsanschluss 130 verbunden. Der Anschluss 130 enthält die Anschlussstifte und andere zum Leiten von Signalen zwischen dem NOC und dem Host-Computer benötigte Anschlüsse sowie eine ausreichend hohe Intelligenz, um Nachrichtenpakete von dem NOC-Paketformat in das von dem Host-Computer 10 benötigte Busformat umzuwandeln. In dem Beispiel des NOC-Coprozessors in dem Computer aus 1 würde ein derartiger Anschluss eine Übersetzung von Datenübertragungsformaten zwischen der Verbindungsstruktur des NOC-Coprozessors 28 und dem für den Front-Side-Bus 36 zwischen dem NOC-Coprozessor 28 und dem Busadapter 18 benötigten Protokoll bereitstellen.
Als nächstes veranschaulicht 3 ein Funktionsblockschaltbild, das die innerhalb eines IP-Blocks 104, der Speicher-Datenübertragungs-Steuereinheit 106, der Netzwerkschnittstellen-Steuereinheit 108 und des Routers 110 in dem NOC 102 umgesetzten Komponenten, die bei 132 gemeinsam veranschaulicht sind, ausführlicher veranschaulicht. Der IP-Block 104 enthält einen Computerprozessor 134 und die E/A-Funktionalität 136. In diesem Beispiel wird der Computerspeicher durch ein Segment des Direktzugriffsspeichers (,RAM‘) 138 in dem IP-Block 104 dargestellt. Wie oben in Bezug auf 2 beschrieben wurde, kann der Speicher Segmente eines physischen Adressraums belegen, dessen Inhalte in jedem IP-Block aufrufbar sind und auf die von jedem IP-Block in dem NOC zugegriffen werden kann. Die Prozessoren 134, die E/A-Funktionen 136 und der Speicher 138 in jedem IP-Block setzen in ihrer Wirkung die IP-Blöcke als allgemein programmierbare Mikrocomputer um. Wie oben erläutert stellen IP-Blöcke im Umfang der vorliegenden Erfindung jedoch allgemein wiederverwendbare Einheiten mit synchroner bzw. asynchroner Logik dar, die als Module für die Datenverarbeitung innerhalb eines NOC verwendet werden. Das Umsetzen von IP-Blöcken als allgemein programmierbare Mikrocomputer ist deshalb keine Einschränkung der vorliegenden Erfindung, obwohl es sich dabei um eine gebräuchliche Ausführungsform handelt, die zum Zwecke der Erläuterung nützlich ist.
In dem NOC 102 aus 3 enthält jede Speicher-Datenübertragungs-Steuereinheit 106 eine Vielzahl von Speicher-Datenübertragungs-Ausführungssteuerkomponenten (memory communications execution engines) 140. Jede Speicher-Datenübertragungs-Ausführungssteuerkomponente 140 ist in der Lage, Speicher-Datenübertragungsanweisungen von einem IP-Block 104 auszuführen, darunter der bidirektionale Speicher-Datenübertragungs-Anweisungsfluss 141, 142, 144 zwischen dem Netzwerk und dem IP-Block 104. Die von der Speicher-Datenübertragungs-Steuereinheit ausgeführten Speicher-Datenübertragungsanweisungen können nicht nur von dem IP-Block stammen, der über eine bestimmte Speicher-Datenübertragungs-Steuereinheit mit einem Router verbunden ist, sondern auch von jedem beliebigen IP-Block 104 irgendwo in dem NOC 102. Das heißt, jeder beliebige IP-Block in dem NOC kann eine Speicher-Datenübertragungsanweisung erzeugen und diese Speicher-Datenübertragungsanweisung über die Router des NOC an eine andere, einem anderen IP-Block zugehörige Speicher-Datenübertragungs-Steuereinheit übertragen, damit diese Speicher-Datenübertragungsanweisung ausgeführt wird. Zu derartigen Speicher-Datenübertragungsanweisungen können zum Beispiel Steueranweisungen für Adressumsetzpuffer (translation lookaside buffer), Steueranweisungen für Zwischenspeicher, Sperranweisungen sowie Lade- und Speicheranweisungen für einen Speicher gehören.
Jede Speicher-Datenübertragungs-Ausführungssteuerkomponente 140 ist in der Lage, eine vollständige Speicher-Datenübertragungsanweisung einzeln und parallel mit anderen Speicher-Datenübertragungs-Ausführungssteuerkomponenten durchzuführen. Die Speicher-Datenübertragungs-Ausführungssteuerkomponenten setzen einen skalierbaren Speichertransaktionsprozessor um, der für den gleichzeitigen Durchsatz von Speicher-Datenübertragungsanweisungen optimiert ist. Die Speicher-Datenübertragungs-Steuereinheit 106 unterstützt mehrere Speicher-Datenübertragungs-Ausführungssteuerkomponenten 140, die alle gleichzeitig laufen, um mehrere Speicher-Datenübertragungsanweisungen gleichzeitig auszuführen. Eine neue Speicher-Datenübertragungsanweisung wird von der Speicher-Datenübertragungs-Steuereinheit 106 einer Speicher-Datenübertragungs-Steuerkomponente 140 zugeordnet, und die Speicher-Datenübertragungs-Ausführungssteuerkomponente 140 kann mehrere Antwortereignisse gleichzeitig annehmen. In diesem Beispiel sind sämtliche Speicher-Datenübertragungs-Ausführungssteuerkomponenten 140 identisch. Deshalb wird ein Skalieren der Anzahl von Speicher-Datenübertragungsanweisungen, die durch eine Speicher-Datenübertragungs-Steuereinheit 106 gleichzeitig bewältigt werden können, durch Skalieren der Anzahl von Speicher-Datenübertragungs-Ausführungssteuerkomponenten 140 umgesetzt.
In dem NOC 102 aus 3 ist jede Netzwerkschnittstellen-Steuereinheit 108 in der Lage, Datenübertragungsanweisungen von Befehlsformat in Netzwerkpaketformat zur Übertragung zwischen den IP-Blöcken 104 über die Router 110 umzuwandeln. Die Datenübertragungsanweisungen können von dem IP-Block 104 oder der Speicher-Datenübertragungs-Steuereinheit 106 in Befehlsformat formuliert und der Netzwerkschnittstellen-Steuereinheit 108 in Befehlsformat bereitgestellt werden. Bei dem Befehlsformat kann es sich um ein natives Format handeln, das Architektur-Register-Dateien des IP-Blocks 104 und der Speicher-Datenübertragungs-Steuereinheit 106 entspricht. Bei dem Netzwerkpaketformat handelt es sich üblicherweise um das Format, das für das Übertragen über die Router 110 des Netzwerks benötigt wird. Jede derartige Nachricht besteht aus einem oder mehreren Netzwerkpaketen. Zu Beispielen für derartige Datenübertragungsanweisungen, die in der Netzwerkschnittstellen-Steuereinheit von Befehlsformat in Paketformat umgewandelt werden, gehören Ladeanweisungen für einen Speicher und Speicheranweisungen für einen Speicher zwischen IP-Blöcken und Speicher.
Derartige Datenübertragungsanweisungen können auch Datenübertragungsanweisungen enthalten, die Nachrichten zwischen IP-Blöcken senden, die Daten und Anweisungen zum Verarbeiten der Daten zwischen IP-Blöcken in parallelen Anwendungen und in Pipeline-Anwendungen tragen.
In dem NOC 102 aus 3 ist jeder IP-Block in der Lage, auf Speicheradressen beruhende Datenübertragungen zu und von dem Speicher durch die Speicher-Datenübertragungs-Steuereinheit des IP-Blocks und dann auch durch dessen Netzwerkschnittstellen-Steuereinheit an das Netzwerk zu senden. Bei einer auf Speicheradressen beruhenden Datenübertragung handelt es sich um eine Speicherzugriffsanweisung wie eine Ladeanweisung oder eine Speicheranweisung, die von einer Speicher-Datenübertragungs-Ausführungssteuerkomponente einer Speicher-Datenübertragungs-Steuereinheit eines IP-Blocks ausgeführt wird. Derartige auf Speicheradressen beruhende Datenübertragungen stammen ursprünglich von einem IP-Block, sind in Befehlsformat formuliert und werden an eine Speicher-Datenübertragungs-Steuereinheit zur Ausführung übergeben.
Viele auf Speicheradressen beruhende Datenübertragungen werden mit Nachrichtenverkehr ausgeführt, da sich jeder beliebige Speicher, auf den zuzugreifen ist, irgendwo in dem physischen Speicheradressraum befinden kann, chipintegriert oder chipextern, direkt mit einer beliebigen Speicher-Datenübertragungs-Steuereinheit in dem NOC verbunden, oder auf den letztendlich von jedem beliebigen IP-Block des NOC zugegriffen werden kann - unabhängig davon, von welchem IP-Block irgendeine bestimmte auf Speicheradressen beruhende Datenübertragung stammt. Somit werden in dem NOC 102 sämtliche auf Speicheradressen beruhenden Datenübertragungen, die mit Nachrichtenverkehr ausgeführt werden, von der Speicher-Datenübertragungs-Steuereinheit an eine zugehörige Netzwerkschnittstellen-Steuereinheit zum Umwandeln von Befehlsformat in Paketformat und zum Senden über das Netzwerk in einer Nachricht weitergeleitet. Beim Umwandeln in Paketformat identifiziert die Netzwerkschnittstellen-Steuereinheit ebenfalls eine Netzwerkadresse für das Paket in Abhängigkeit von der Speicheradresse bzw. den Speicheradressen, auf die von einer auf Speicheradressen beruhenden Datenübertragung zugegriffen werden soll. Auf Speicheradressen beruhende Nachrichten werden mit Speicheradressen aufgerufen. Jede Speicheradresse wird von den Netzwerkschnittstellen-Steuereinheiten auf eine Netzwerkadresse abgebildet, üblicherweise die Netzwerkposition einer Speicher-Datenübertragungs-Steuereinheit, die für einen gewissen Bereich von physischen Speicheradressen zuständig ist. Bei der Netzwerkposition einer Speicher-Datenübertragungs-Steuereinheit 106 handelt es sich natürlich auch um die Netzwerkposition des dieser Speicher-Datenübertragungs-Steuereinheit zugehörigen Routers 110, der Netzwerkschnittstellen-Steuereinheit 108 und des IP-Blocks 104. Die Anweisungsumwandlungslogik 150 innerhalb jeder Netzwerkschnittstellen-Steuereinheit ist in der Lage, Speicheradressen in Netzwerkadressen umzuwandeln, um auf Speicheradressen beruhende Datenübertragungen über die Router eines NOC zu übertragen.
Beim Empfangen von Nachrichtenverkehr von den Routern 110 des Netzwerks untersucht jede Netzwerkschnittstellen-Steuereinheit 108 jedes Paket auf Speicheranweisungen. Jedes eine Speicheranweisung enthaltende Paket wird an die der empfangenden Netzwerkschnittstellen-Steuereinheit zugehörige Speicher-Datenübertragungs-Steuereinheit 106 übergeben, welche die Speicheranweisung ausführt, bevor die restlichen Nutzdaten des Pakets an den IP-Block zur weiteren Verarbeitung gesendet werden. Auf diese Weise sind Speicherinhalte immer darauf vorbereitet, die Datenverarbeitung durch einen IP-Block zu unterstützen, bevor der IP-Block mit dem Ausführen der Anweisungen aus einer von einem bestimmten Speicherinhalt abhängenden Nachricht beginnt.
In dem NOC 102 aus 3 ist jeder IP-Block 104 in der Lage, seine Speicher-Datenübertragungs-Steuereinheit 106 zu umgehen und die IP-Block-übergreifenden, netzwerkadressierten Datenübertragungen 146 über die Netzwerkschnittstellen-Steuereinheit 108 des IP-Blocks direkt an das Netzwerk zu senden. Bei netzwerkadressierten Datenübertragungen handelt es sich um Nachrichten, die von einer Netzwerkadresse an einen anderen IP-Block geleitet werden. Derartige Nachrichten übertragen Arbeitsdaten in Pipeline-Anwendungen, mehrere Daten zur Einzelprogrammverarbeitung zwischen IP-Blöcken in einer SIMD-Anwendung usw., wie einem Fachmann klar sein wird. Derartige Nachrichten unterscheiden sich von auf Speicheradressen beruhenden Datenübertragungen dadurch, dass sie von Anfang an von dem Ursprungs-IP-Block netzwerkadressiert sind, der die Netzwerkadresse kennt, an welche die Nachricht über Router des NOC zu leiten ist. Derartige netzwerkadressierte Datenübertragungen werden von dem IP-Block in Befehlsformat über die E/A-Funktionen 136 direkt an die Netzwerkschnittstellen-Steuereinheit des IP-Blocks weitergeleitet, dann durch die Netzwerkschnittstellen-Steuereinheit in Paketformat umgewandelt und über Router des NOC an einen anderen IP-Block übertragen. Derartige netzwerkadressierte Datenübertragungen 146 sind bidirektional, wobei sie in Abhängigkeit ihrer Verwendung in einer beliebigen bestimmten Anwendung möglicherweise zu und von jedem IP-Block des NOC vorrücken. Jede Netzwerkschnittstellen-Steuereinheit ist jedoch in der Lage, derartige Datenübertragungen an einen und von einem zugehörigen Router sowohl zu senden als auch zu empfangen, und jede Netzwerkschnittstellen-Steuereinheit ist in der Lage, derartige Datenübertragungen sowohl direkt an einen zugehörigen IP-Block zu senden als auch direkt von diesem zu empfangen und dadurch eine zugehörige Speicher-Datenübertragungs-Steuereinheit 106 zu umgehen.
Jede Netzwerkschnittstellen-Steuereinheit 108 in dem Beispiel aus 3 ist ebenfalls in der Lage, virtuelle Kanäle in dem Netzwerk umzusetzen und Netzwerkpakete nach Typ zu kennzeichnen. Jede Netzwerkschnittstellen-Steuereinheit 108 enthält die virtuelle Kanalumsetzungslogik 148, die jede Datenübertragungsanweisung nach Typ einordnet und den Typ der Anweisung in einem Feld des Netzwerkpaketformats einträgt, bevor die Anweisung in Paketform an einen Router 110 zum Übertragen an das NOC übergeben wird. Zu Beispielen von Datenübertragungs-Anweisungstypen gehören IP-Block-übergreifende, auf Netzwerkadressen beruhende Nachrichten, Anforderungsnachrichten, Antworten auf Anforderungsnachrichten, Annullieren von an Cachespeicher gerichtete Nachrichten; Lade- und Speichernachrichten für Speicher; sowie Antworten auf Speicherladenachrichten usw.
Jeder Router 110 in dem Beispiel aus 3 enthält die Weiterleitungslogik 152, die virtuelle Kanalsteuerungslogik 154 sowie die virtuellen Kanalpuffer 156. Die Weiterleitungslogik ist üblicherweise als Netzwerk von synchroner und asynchroner Logik umgesetzt, die einen Datenübertragungsprotokoll-Stapel zur Datenübertragung in dem Netzwerk umsetzt, der durch die Router 110, die Verbindungen 118 und die Busdrähte zwischen den Routern gebildet wird. Die Weiterleitungslogik 152 enthält die Funktionalität, die ein Fachmann mit Routing-Tabellen in chipexternen Netzwerken in Verbindung bringen kann, wobei Routing-Tabellen zumindest in einigen Ausführungsformen für zu langsam und hinderlich zur Verwendung in einem NOC erachtet werden. Eine als Netzwerk von synchroner und asynchroner Logik umgesetzte Weiterleitungslogik kann so konfiguriert sein, dass sie Routing-Entscheidungen sogar in nur einem einzelnen Taktzyklus trifft. Die Weiterleitungslogik in diesem Beispiel leitet Pakete weiter, indem sie einen Anschluss zum Weiterleiten jedes in einem Router empfangenen Pakets auswählt. Jedes Paket enthält eine Netzwerkadresse, an die das Paket zu leiten ist.
In der obigen Beschreibung von auf Speicheradressen beruhenden Datenübertragungen wurde jede Speicheradresse so beschrieben, dass sie durch Netzwerkschnittstellen-Steuereinheiten auf eine Netzwerkadresse, eine Netzwerkposition einer Speicher-Datenübertragungs-Steuereinheit, abgebildet werden. Bei der Netzwerkposition einer Speicher-Datenübertragungs-Steuereinheit 106 handelt es sich natürlich auch um die Netzwerkposition des dieser Speicher-Datenübertragungs-Steuereinheit zugehörigen Routers 110, der Netzwerkschnittstellen-Steuereinheit 108 und des IP-Blocks 104. Bei IP-Block-übergreifenden bzw. auf Speicheradressen beruhenden Datenübertragungen ist es daher auch üblich, dass die Datenverarbeitung auf Anwendungsebene Netzwerkadressen als die Position eines IP-Blocks innerhalb des durch die Router, die Verbindungen sowie die Busdrähte des NOC gebildeten Netzwerks ansehen. 2 veranschaulicht, dass eine Organisation eines derartigen Netzwerks ein Netz (mesh) aus Reihen und Spalten darstellt, in dem jede Netzwerkadresse zum Beispiel entweder als eine eindeutige Kennung für jeden Satz aus zugehörigem Router, zugehörigem IP-Block, zugehöriger Speicher-Datenübertragungs-Steuereinheit sowie zugehöriger Netzwerkschnittstellen-Steuereinheit des Netzes oder als X-, Y-Koordinaten jedes derartigen Satzes in dem Netz umgesetzt werden kann.
In dem NOC 102 aus 3 setzt jeder Router 110 zwei oder mehr virtuelle Datenübertragungskanäle um, wobei jeder virtuelle Datenübertragungskanal durch einen Datenübertragungstyp gekennzeichnet ist. Zu Datenübertragungs-Anweisungstypen und somit zu virtuellen Kanaltypen gehören die oben erwähnten: IP-Block-übergreifende, auf Netzwerkadresse beruhende Nachrichten, Anforderungsnachrichten, Antworten auf Anforderungsnachrichten, Annullieren von an Cachespeicher gerichtete Nachrichten; Lade- und Speichernachrichten für Speicher; sowie Antworten auf Speicherladenachrichten usw. Zur Unterstützung von virtuellen Kanälen enthält jeder Router 110 in dem Beispiel aus 3 auch die virtuelle Kanalsteuerungslogik 154 sowie die virtuellen Kanalpuffer 156. Die virtuelle Kanalsteuerungslogik 154 untersucht jedes empfangene Paket auf dessen zugehörigen Datenübertragungstyp und platziert jedes Paket in einen abgehenden virtuellen Kanalpuffer für diesen Datenübertragungstyp zum Übertragen an einen benachbarten Router in dem NOC über einen Anschluss.
Jeder virtuelle Kanalpuffer 156 weist einen endlichen Speicherplatz auf. Beim Empfangen von vielen Paketen in einer kurzen Zeitspanne kann sich ein virtueller Kanalpuffer füllen - so dass keine weiteren Pakete mehr in dem Puffer platziert werden können. In anderen Protokollen würden Pakete verworfen, die auf einem virtuellen Kanal ankommen, dessen Puffer voll ist. Jeder virtuelle Kanalpuffer 156 in diesem Beispiel ist jedoch durch Steuersignale der Busdrähte in der Lage, über die virtuelle Kanalsteuerlogik umliegende Router anzuweisen, das Übertragen auf einem virtuellen Kanal zu unterbrechen, d.h., das Übertragen von Paketen eines bestimmten Datenübertragungstyps zu unterbrechen. Wenn ein virtueller Kanal derart unterbrochen wird, bleiben sämtliche anderen virtuellen Kanäle davon unbeeinflusst - und können weiterhin mit voller Kapazität arbeiten. Die Steuersignale sind über jeden Router bis hin zu der jedem Router zugehörigen Netzwerkschnittstellen-Steuereinheit 108 verbunden. Jede Netzwerkschnittstellen-Steuereinheit ist so konfiguriert, dass sie beim Empfangen eines derartigen Signals von ihrer zugehörigen Speicher-Datenübertragungs-Steuereinheit 106 bzw. von ihrem zugehörigen IP-Block 104 die Annahme von Datenübertragungsanweisungen für den unterbrochenen virtuellen Kanal verweigern kann. Auf diese Weise beeinträchtigt eine Unterbrechung eines virtuellen Kanals die gesamte Hardware, die den virtuellen Kanal umsetzt, bis hin zu den Ursprungs-IP-Blöcken.
Eine Auswirkung des Unterbrechens von Paketübertragungen in einem virtuellen Kanal besteht darin, dass keine Pakete jemals verworfen werden. Wenn ein Router auf eine Situation trifft, in der ein Paket in irgendeinem unzuverlässigen Protokoll wie dem Internet-Protokoll möglicherweise verworfen werden würde, können die Router in dem Beispiel aus 3 über ihre virtuellen Kanalpuffer 156 und ihre virtuelle Kanalsteuerlogik 154 sämtliche Übertragungen von Paketen auf einem virtuellen Kanal so lange unterbrechen, bis wieder Platz im Puffer zur Verfügung steht, wodurch die Notwendigkeit des Verwerfens von Paketen beseitigt wird. Das NOC aus 3 kann deshalb hoch zuverlässige Netzwerk-Datenübertragungsprotokolle mit einer äußerst dünnen Hardware-Schicht umsetzen.
Das beispielhafte NOC aus 3 kann auch so konfiguriert sein, dass es die Cachespeicher-Kohärenz zwischen Cachespeichern von sowohl chipintegrierten als auch chipexternen Speichern aufrechterhält. Jedes NOC kann mehrere Cachespeicher unterstützen, die jeweils in Abhängigkeit von demselben zu Grunde liegenden Speicheradressraum funktionieren. Cachespeicher können zum Beispiel durch IP-Blöcke, durch Speicher-Datenübertragungs-Steuereinheiten bzw. durch Cachespeicher-Steuereinheiten außerhalb des NOC gesteuert werden. Jeder der chipintegrierten Speicher 114, 116 in dem Beispiel aus 2 kann auch als chipintegrierter Cachespeicher umgesetzt werden, und im Rahmen der vorliegenden Erfindung kann Cachespeicher auch chipextern umgesetzt werden.
Jeder in 3 veranschaulichte Router 110 enthält fünf Anschlüsse, die vier Anschlüsse 158A bis D, die über die Busdrähte 118 mit anderen Routern verbunden sind, und einen fünften Anschluss 160, der jeden Router über eine Netzwerkschnittstellen-Steuereinheit 108 und eine Speicher-Datenübertragungs-Steuereinheit 106 mit dessen zugehörigem IP-Block 104 verbindet. Wie aus den Veranschaulichungen in den 2 und 3 ersichtlich ist, bilden die Router 110 und die Verbindungen 118 des NOC 102 ein Netzwerk (mesh network) mit vertikalen und horizontalen Verbindungen, die vertikale und horizontale Anschlüsse in jedem Router verbinden. In der Veranschaulichung aus 3 sind die Anschlüsse 158A, 158C und 160 als vertikale Anschlüsse benannt, und die Anschlüsse 158B und 158D sind als horizontale Anschlüsse benannt.
Als nächstes veranschaulicht 4 auf eine andere Weise eine beispielhafte Ausführung eines IP-Blocks 104 in Übereinstimmung mit der Erfindung, umgesetzt als ein Verarbeitungselement, das in eine Anweisungseinheit (IU) 162, eine Ausführungseinheit (XU) 164 und eine Hilfsausführungseinheit (AXU) 166 aufgeteilt ist. In der veranschaulichten Ausführung enthält die IU 162 eine Vielzahl von Anweisungspuffern 168, die Anweisungen von einem L1-Anweisungs-Cachespeicher (iCACHE) 170 empfangen. Jeder Anweisungspuffer 168 ist speziell für einen aus einer Vielzahl, z.B. vier, symmetrischer Multithread- (SMT-) Hardware-Threads vorgesehen. Eine Effektiv-Real-Übersetzungseinheit (iERAT) 172 ist mit dem iCACHE 170 verbunden und wird dazu verwendet, Anweisungsabrufanforderungen von einer Vielzahl von Thread-Abruf-Sequencern 174 in reale Adressen zu übersetzen, um Anweisungen aus Speicher niedrigerer Ordnung abzurufen. Jeder Thread-Abruf-Sequencer 174 ist speziell für einen bestimmten Hardware-Thread vorgesehen und wird dazu verwendet sicherzustellen, dass durch den zugehörigen Thread auszuführende Anweisungen in den iCACHE abgerufen werden, um sie an die entsprechende Ausführungseinheit zu senden. Wie ebenfalls in 4 gezeigt ist, können in den Anweisungspuffer 168 abgerufene Anweisungen ebenfalls durch die Verzweigungsvorhersagelogik 176 überwacht werden, die jedem Thread-Abruf-Sequencer 174 Hinweise gibt, um sich nicht im Cachespeicher befindliche Anweisungen (instruction cache misses), die sich aus Verzweigungen in ausführenden Threads ergeben, zu minimieren.
Die IU 162 enthält ebenfalls einen Abhängigkeits/Ausgabe-Logikblock 178, der speziell für jeden Hardware-Thread vorgesehen und so konfiguriert ist, dass er Abhängigkeiten auflöst und die Ausgabe von Anweisungen aus dem Anweisungspuffer 168 an die XU 164 steuert. Außerdem wird in der veranschaulichten Ausführungsform in der AXU 166 eine separate Abhängigkeits/Ausgabe-Logik 180 bereitgestellt, wodurch es ermöglicht wird, separate Anweisungen durch verschiedene Threads gleichzeitig an die XU 164 und die AXU 166 auszugeben. In einer alternativen Ausführungsform kann sich die Logik 180 in der IU 162 befinden oder vollständig weggelassen werden, so dass die Logik 178 Anweisungen an die AXU 166 ausgibt.
Die XU 164 ist als eine Festkomma-Ausführungseinheit umgesetzt und enthält eine Reihe von Universalregistern (GPRs, general purpose registers) 182, die mit der Festkommalogik 184, der Verzweigungslogik 186 und der Lade/Speicher-Logik 188 verbunden sind. Die Lade/Speicher-Logik 188 ist mit einem L1-Datencachespeicher (dCACHE) 190 verbunden, wobei eine Effektiv-Real-Übersetzung durch die dERAT-Logik 192 bereitgestellt wird. Die XU 164 kann so konfiguriert sein, dass sie praktisch jede Reihe von Anweisungen ausführen kann, z.B. alle oder einen Teil einer Reihe von 32b- bzw. 64b-PowerPC-Anweisungen.
Die AXU 166 fungiert als Hilfsausführungseinheit, welche die speziell vorgesehene Abhängigkeits/Ausgabe-Logik 180 gemeinsam mit einem oder mehreren Ausführungsblöcken 194 enthält. Die AXU 166 kann jede beliebige Anzahl von Ausführungsblöcken enthalten und praktisch jede beliebige Art von Ausführungseinheit umsetzen, z.B. eine Gleitkommaeinheit oder eine oder mehrere spezialisierte Ausführungseinheiten wie Verschlüsselungs/Entschlüsselungs-Einheiten, Coprozessoren, Vektorverarbeitungseinheiten, Grafikverarbeitungseinheiten, XML-Verarbeitungseinheiten usw. In der veranschaulichten Ausführungsform enthält die AXU 166 eine Hochgeschwindigkeits-Hilfsschnittstelle mit der XU 164, z.B. um direkte Verschiebungen zwischen AXU-zweckgestaltetem Zustand und XUzweckgestaltetem Zustand zu unterstützen.
Der Datenaustausch mit dem IP-Block 104 kann auf die oben in Zusammenhang mit 2 erörterte Weise über eine mit dem NOC 102 verbundene Netzwerkschnittstellen-Steuereinheit 108 verwaltet werden. Auf Adressen beruhende Datenübertragung, z.B. zum Zugreifen auf L2-Cachespeicher, kann gemeinsam mit auf Nachrichten beruhender Datenübertragung bereitgestellt werden. Jeder IP-Block 104 kann zum Beispiel einen speziell vorgesehenen Eingang und/oder Ausgang enthalten, um knotenübergreifende Datenübertragungen zwischen IP-Blöcken zu bewältigen.
Ausführungsformen der vorliegenden Erfindung können in der in Zusammenhang mit den 1 bis 4 oben beschriebenen Hardware- und Software-Umgebung umgesetzt werden. Mit Unterstützung der vorliegenden Darlegung wird ein Fachmann jedoch verstehen, dass die Erfindung in einer Vielzahl von verschiedenen Umgebungen umgesetzt werden kann, und dass andere Abwandlungen an der oben erwähnten Hardware- und Software-Ausführungsform vorgenommen werden können, ohne von dem Gedanken und dem Umfang der Erfindung abzuweichen. Als solche ist die Erfindung nicht auf die bestimmte hierin dargelegte Hardware- und Software-Umgebung beschränkt.
Software-Pipelining
Wenden wir uns nun 5 zu, in der das NOC 102 in einigen Ausführungsformen zum Umsetzen einer auf Software beruhenden Pipeline verwendet werden kann. Insbesondere veranschaulicht 5 eine beispielhafte Verarbeitungseinheit 200, die eine Thread-Pipeline-Software-Steuerkomponente 202 enthält, die zum Umsetzen und Ausführen einer oder mehrerer Software-Pipelines 204 auf einer NOC-Architektur verwendet werden kann. Jede Pipeline 204 ist üblicherweise einer oder mehreren Datenstrukturen 206 in einem gemeinsam genutzten Speicher 208 zugeordnet, um verschiedene Stufen einer Pipeline zum Austauschen von Daten zu ermöglichen. Des Weiteren wird ein Unterbrechungsmechanismus 210 bereitgestellt, um es Stufen einer Pipeline zu ermöglichen, sich gegenseitig über anstehende durchzuführende Aufgaben zu benachrichtigen.
In der Steuerkomponente 202 werden auch ein oder mehrere Host-Schnittstellen-Prozessoren (HIPs, host interface processors) 212 bereitgestellt, um die Ausgabe von Aufgaben an die Software-Pipelines 204 zu bewältigen. Es werden ein oder mehrere Aussendepuffer (push buffer) 214 bereitgestellt, damit jeder HIP 212 eine Schnittstelle zu einer Software-Anwendung 216 und dem Treiber 218 aufweist, die sich außerhalb der Steuerkomponente befinden. Zum Einleiten einer Aufgabe in einer Pipeline gibt eine Software-Anwendung 216 über einen entsprechenden Treiber 218 Anforderungen in Form von API-Aufrufen aus, woraufhin entsprechende Anforderungen für den HIP erzeugt und die Anforderungen in einem Aussendepuffer 214 gespeichert werden. Der HIP 212 für die entsprechende Pipeline ruft Aufgabenanforderungen aus dem Aussendepuffer 214 ab und leitet das Verarbeiten der Anforderung durch die zugehörige Pipeline ein.
In der veranschaulichten Ausführungsform und wie in einem NOC 102 umgesetzt führt eine Software-Pipeline 204 eine Funktion aus, die in eine Reihe von Modulen bzw. ,Stufen‘ von Computerprogrammanweisungen eingeteilt ist, die miteinander zusammenarbeiten, um eine Reihe von Datenverarbeitungsaufgaben der Reihe nach auszuführen. Jede Stufe in einer Pipeline besteht aus einem flexibel konfigurierbaren Modul mit Computerprogrammanweisungen, das für jede auf einem Ausführungs-Thread in einem IP-Block 104 eines NOC 102 ausgeführte Stufe durch eine Stufenkennung identifiziert wird. Die Stufen sind dahingehend flexibel konfigurierbar, dass jede Stufe mehrere Instanzen der Stufe unterstützen kann, so dass eine Pipeline skaliert werden kann, indem zusätzliche Instanzen einer Stufe instanziiert werden, wie in Abhängigkeit von der Arbeitslast benötigt wird. Da jede Stufe durch in einem IP-Block 104 eines NOC 102 ausgeführte Computerprogrammanweisungen umgesetzt wird, ist jede Stufe in der Lage, über eine Speicher-Datenübertragungs-Steuereinheit 106 auf aufgerufenen Speicher zuzugreifen. Außerdem ist mindestens eine Stufe in der Lage, auf Netzwerkadressen beruhende Datenübertragungen zwischen anderen Stufen zu senden, wobei die auf Netzwerkadressen beruhenden Datenübertragungen die Paketreihenfolge beibehalten.
Die auf Netzwerkadressen beruhenden Datenübertragungen können zum Beispiel unter Verwendung von „Eingängen“ in jeder Stufe umgesetzt werden, die Daten und/oder Befehle von vorausgehenden Stufen in der Pipeline empfangen. Die auf Netzwerkadressen beruhenden Datenübertragungen behalten die Paketreihenfolge bei, und es handelt sich bei ihnen um Datenübertragungen derselben Art, die in der Lage sind, durch denselben virtuellen Kanal wie oben beschrieben zu fließen. Jedes Paket in derartigen Datenübertragungen wird auf die oben beschriebene Weise durch einen Router 110 weitergeleitet, wobei es der Reihe nach in einen virtuellen Kanalpuffer eintritt und diesen in FIFO-Reihenfolge verlässt, wodurch die Paketreihenfolge strikt eingehalten und die Unversehrtheit der Nachrichten geschützt wird.
Jede Stufe setzt eine Produzenten/Konsumenten-Beziehung mit einer nächsten Stufe um. Die erste Stufe empfängt Arbeitsanweisungen und Arbeitsstückdaten (work piece data) über einen HIP 212, führt ihre vorgesehenen Datenverarbeitungsaufgaben an dem Arbeitsstück durch, erzeugt Ausgabedaten und sendet die erzeugten Ausgabedaten an die nächste Stufe in der Pipeline, welche die erzeugten Ausgabedaten von der ersten Stufe durch Ausführen ihrer vorgesehenen Datenverarbeitungsaufgaben an den erzeugten Ausgabedaten von der ersten Stufe konsumiert, wodurch Ausgabedaten erzeugt werden, die anschließend an eine nächste Stufe in der Pipeline gesendet werden. Diese Folge von Arbeitsschritten wird bis zur letzten Stufe der Pipeline fortgeführt, die dann ihre erzeugten Ausgabedaten in einer Ausgabedatenstruktur speichert, damit sie letztendlich über den HIP 212 an die Ursprungsanwendung 216 zurückgesendet werden.
Die Anordnung von Stufen in einer Pipeline kann in verschiedenen Ausführungsformen sowie zum Durchführen verschiedener Funktionen in verschiedenen Anwendungen variieren. 6 veranschaulicht zum Beispiel eine beispielhafte Software-Pipeline 220, die eine Vielzahl von Stufeninstanzen 222 enthält, ebenfalls separat als Instanzen A bis I gekennzeichnet, von denen jede einen in einem IP-Block in dem NOC 102 ausgeführten Ausführungs-Thread darstellt. Die Stufeninstanzen 222 sind in der Pipeline 220 in fünf Stufen angeordnet, einer ersten Stufe mit der Instanz A, einer zweiten Stufe mit den Instanzen B und C, einer dritten Stufe mit den Instanzen D, E und F, einer vierten Stufe mit den Instanzen G und H und einer fünften Stufe mit der Instanz I. Wie aus 6 ersichtlich ist, können Instanzen eine eins-zu-eins, eine eins-zu-vielen und/oder eine viele-zu-eins Beziehung mit anderen Instanzen in der Pipeline haben. Instanzen können in einer bestimmten Stufe gemeinsam miteinander arbeiten, um parallele Aufgaben auszuführen und die Arbeitslast zu teilen, wodurch der Gesamtdurchsatz der Stufe beim Durchführen der Aufgabe verbessert wird. Instanzen in einer Stufe können auch voneinander unterschiedliche Aufgaben durchführen, um das parallele Durchführen verschiedener Aufgaben zu ermöglichen. Instanzen können Daten an mehr als eine Instanz liefern, während andere Instanzen von mehreren Instanzen Daten sammeln und Daten verarbeiten können.
In der veranschaulichten Ausführungsform ist jede Instanz jeder Stufe einer Pipeline üblicherweise als ein Modul auf Anwendungsebene von in einem separaten IP-Block in einem NOC ausgeführten Computerprogrammanweisungen umgesetzt, und jede Stufe ist einem Ausführungs-Thread in einem IP-Block eines NOC zugewiesen. Jeder Stufe ist eine Stufenkennung zugewiesen, und jeder Instanz einer Stufe ist eine Kennung zugewiesen. Der HIP 212 (5) baut die Pipeline üblicherweise durch Konfigurieren jeder Stufe mit einer gewünschten Anzahl von Instanzen auf, wobei die Netzwerkposition jeder Instanz jeder Stufe anderen Instanzen anderer Stufen mitgeteilt wird, um es jeder Instanz zu ermöglichen, ihre sich ergebende Arbeitslast an die richtige Instanz in der nächsten Stufe zu senden, frühere und/oder spätere Stufe 3, für die eine Instanz von Stufe 2 berechtigt ist, ihre sich ergebende Arbeitslast zu senden. Mehrere Instanzen können einer bestimmten Stufe zugewiesen werden, um zusätzliche Verarbeitungsressourcen bezogen auf andere Stufen bereitzustellen, z.B. damit Aufgaben so effizient wie möglich durch die Pipeline fließen und keine einzelne Stufe einen Leistungsengpass darstellt. Man wird auch verstehen, dass ein Überwachen der Arbeitslast während der Laufzeit durchgeführt werden kann, und dass Instanzen dynamisch einer Stufe hinzugefügt oder davon entfernt werden können, wie zum Ausgleichen der Last unter den Stufen der Pipeline benötigt wird.
Jede Stufe ist mit einer Stufenkennung für jede Instanz einer nächsten Stufe konfiguriert, die auch die Anzahl von Instanzen in der nächsten Stufe sowie die Netzwerkposition jeder Instanz davon enthalten kann. Durch das Konfigurieren einer Stufe mit Kennungen für Instanzen einer nächsten Stufe werden der Stufe die Informationen bereitgestellt, die zum Ausführen eines Lastenausgleichs zwischen Stufen benötigt werden. Ein derartiger Lastenausgleich kann zum Beispiel durch Überwachen der Leistungsfähigkeit der Stufen und Instanziieren mehrerer Instanzen jeder Stufe in Abhängigkeit von der Leistungsfähigkeit einer oder mehrerer Stufen ausgeführt werden. Das Überwachen der Leistungsfähigkeit der Stufen kann ausgeführt werden, indem jede Stufe so konfiguriert wird, dass sie Leistungsfähigkeitsstatistiken an eine separate Überwachungsanwendung berichtet, die wiederum in einem anderen Ausführungs-Thread in einem IP-Block oder einem HIP läuft. Leistungsfähigkeitsstatistiken können zum Beispiel die zum Ausführen einer Datenverarbeitungsaufgabe benötigte Zeit, eine Anzahl von in einer bestimmten Zeitspanne ausgeführten Datenverarbeitungsaufgaben usw. enthalten, wie einem Fachmann klar sein wird. Das Instanziieren mehrerer Instanzen jeder Stufe in Abhängigkeit von der Leistungsfähigkeit einer oder mehrerer der Stufen kann dadurch ausgeführt werden, dass ein HIP eine neue Instanz einer Stufe instanziiert, wenn die überwachte Leistungsfähigkeit auf den Bedarf für eine neue Instanz hindeutet.
Multithread-Wiedergabe-Pipeline-Architektur mit rollierender Kontextdatenstruktur
Wenden wir uns nun 7 zu, die eine Umsetzung einer Verarbeitungseinheit 200 veranschaulicht, die so konfiguriert ist, dass sie eine Multithread-Pipeline-Wiedergabe-Architektur in Übereinstimmung mit der Erfindung umsetzen kann. Insbesondere veranschaulicht 7 eine Multithread-Wiedergabe-Pipeline 230, die eine Grouper-Stufe mit einer oder mehreren Grouper-Einheiten 232, eine Geometrie-Engine-Stufe mit einer oder mehreren Geometrie-Engines 234, eine Nach-Geometrie-Engine- (Nach-GE-) Stufe, die eine oder mehrere Nach-GE-Einheiten 236 enthält, eine Rasterungsstufe, die eine oder mehrere Rasterisierungseinheiten (rasterizers) 238 enthält, und eine Pixel-Shader-Stufe, die einen oder mehrere Pixel-Shader 240 enthält, beinhaltet.
Jedes Verarbeitungselement bzw. jede Einheit 232, 234, 236, 238, 240 ist wünschenswerterweise innerhalb eines IP-Blocks in einem Knoten in dem NOC 102 umgesetzt, wobei jeder derartigen Einheit mindestens ein dedizierter Hardware-Thread zugewiesen ist. Jede Einheit befindet sich üblicherweise auf einem separaten Knoten, obwohl sich in anderen Ausführungsformen mehrere Einheiten in einem einzelnen Knoten befinden können. Außerdem können in manchen Ausführungsformen jeder Einheit mehrere Ausführungs-Threads zugeordnet sein. In einigen Ausführungsformen kann auch auf Zeitscheiben beruhendes Software-Multithreading umgesetzt werden, obwohl es in der veranschaulichten Ausführungsform wünschenswert ist, dass mehrere Einheiten nicht vollständig in demselben auf Hardware beruhenden Thread umgesetzt sind.
Jede Grouper-Einheit 232 wird zum Gruppieren von Daten verwendet, welche die Pipeline hinunter im Datenstrom übertragen werden, z.B. durch Abrufen verwandter Scheitelpunkte von einer Objektanordnung (object array). Jede Geometrie-Engine 234 wird üblicherweise dafür verwendet, Objektumwandlungen durchzuführen und die geometrischen Basiselemente zu erzeugen, während jede Nach-GE-Einheit 236 so konfiguriert ist, dass sie eine Nachbearbeitung der geometrischen Basiselemente wie Perspektivenaufteilungen, Filterung (culling), Sortierung, Auflösen von Geometrie usw. durchführen kann.
Jede Rasterisierungseinheit 238 ist so konfiguriert, dass sie als Pixelfragmenterzeuger funktionieren kann, um aus einem der Rasterisierungseinheit zugeführten Basiselement einen Datenstrom von Pixelfragment-Datensätzen zu erzeugen, die ein Pixel, einen Teil eines Pixels oder mehr als ein Pixel beschreiben. Neben anderen Arbeitsschritten führt jede Rasterisierungseinheit üblicherweise eine Abtastlinienumwandlung für Koordinaten in einem Basiselement in (u, v) Texturkoordinaten in einer auf das Basiselement anzuwendenden Textur durch. Jeder Pixel-Shader 240 verwendet wiederum die Pixelfragment-Datensätze und wendet die Farben eines oder mehrerer Pixel in einem Einzelbildpuffer 242 an bzw. aktualisiert diese, üblicherweise unter Verwendung von Texturfilterung und anderen Shading-Techniken. Man wird verstehen, dass die durch die Einheiten 232, 234, 236, 238 und 240 im Sinne des Umsetzens einer Bilddaten für eine Szene wiedergebenden, auf Rastern beruhenden Wiedergabe-Pipeline durchgeführten spezifischen Arbeitsschritte jede beliebige Anzahl bekannter Wiedergabetechniken, - verbesserungen und -algorithmen anwenden können, und dass die Umsetzung derartiger Techniken in den entsprechenden Einheiten im Rahmen der Fähigkeiten eines gewöhnlichen Fachmanns mit Unterstützung der vorliegenden Darlegung läge. Man wird auch verstehen, dass in einer Multithread-Pipeline in Übereinstimmung mit der Erfindung auch andere Wiedergabealgorithmen, zum Beispiel die Verwendung physischer Wiedergabetechniken wie punktweise Betrachtung oder Photonen-Abbildung, umgesetzt werden können und dass derartige Techniken von anderen und/oder zusätzlichen Pipeline-Stufen abhängen können, die nicht in 7 veranschaulicht sind. Deshalb ist die Erfindung nicht auf die bestimmte, in 7 dargestellte auf Rastern beruhende Wiedergabe-Pipeline-Architektur beschränkt.
Befehle und Daten können in der Pipeline 230 von Stufe zu Stufe geleitet werden, während einige Daten, darunter gemeinsam genutzter Kontext oder Zustandsdaten nicht direkt von Stufe zu Stufe geleitet werden, sondern stattdessen in dem gemeinsam genutzten Speicher 208 beibehalten werden und jede Stufe nach Bedarf darauf zugreift. Zu diesen gemeinsam genutzten Daten kann eine rollierende Kontextdatenstruktur gehören, die in 7 als Wiedergabe-Kontext-Tabelle 244 umgesetzt ist.
Wie in 8 gezeigt ist, enthält eine Umsetzung der Wiedergabe-Kontext-Tabelle 244 eine Vielzahl von Einträgen 246, die jeweils ein Schlüssel- bzw. Indexfeld 248, ein oder mehrere Attributfelder 250 sowie ein Verwendet-Feld 252 enthalten. Das Schlüssel- bzw. Indexfeld 248 stellt eine eindeutige Kennung für dessen entsprechenden Eintrag 246 bereit, und in der veranschaulichten Ausführungsform speichert das Feld 248 einen ganzzahligen Index, so dass ein Wiedergabekontextzeiger 254 über einen ganzzahligen Wert auf einen bestimmten Eintrag 246 verweisen kann. In einigen Ausführungsformen kann das Feld 248 weggelassen werden, z.B. wenn jeder Eintrag 246 eine feste Größe aufweist, so dass der Index für jeden Eintrag beruhend auf dessen Position in dem Speicher angedeutet wird. Man wird auch verstehen, dass andere Kennungen zum Identifizieren eines Eintrags in der Tabelle 244 verwendet werden können, und die Erfindung ist nicht auf die Verwendung eines ganzzahligen Eintrags zum Identifizieren eines Eintrags in einer Tabelle beschränkt.
Jedes Feld 250 speichert einem bestimmten Kontext bzw. Zustand zugehörige Attributdaten, die durch den entsprechenden Eintrag 246 dargestellt werden. In jedem Eintrag kann eine feste oder veränderbare Anzahl von Feldern 250 bereitgestellt werden, und jedes Feld kann ein Attributdatenverzeichnis und/oder Verweise auf andere relevante Attributdaten enthaltende Datenstrukturen speichern. Für den Zweck der grafischen Bildverarbeitung können zu den Arten von Zustandsdaten, die in einem Eintrag einer Wiedergabekontexttabelle beibehalten werden können, Folgende zählen: Verweise auf Farbpuffer, Verweise auf Kugelabbilder, Verweise auf Texturabbilder, Drehattribute, Beleuchtungsattribute, Mischattribute, Bildschirmverschiebungen usw., aber nicht darauf beschränkt.
Das Verwendet-Feld 252 für jeden Eintrag 246 wird dazu verwendet darzustellen, ob ein bestimmter Eintrag gegenwärtig verwendet wird oder zur Abänderung und/oder Verwendung zum Speichern eines anderen Wiedergabekontexts zur Verfügung steht. Es können verschiedene Arten der Darstellung des Status eines Eintrags in Übereinstimmung mit der Erfindung verwendet werden, darunter ein einzelnes Bit bzw. Flag oder ein anderer numerischer Wert. Außerdem könnte zum Speichern des Status jedes Eintrags in der Tabelle 244 eine separate Datenstruktur verwendet werden.
Auf einen Verwendet-Eintrag 246 in der Tabelle 244 wird üblicherweise von einem oder mehreren Wiedergabekontextzeigern 254 verwiesen. Ein Wiedergabekontextzeiger 254 ist üblicherweise mit einem bestimmten Bildelement bzw. einer Reihe oder Gruppe von Bildelementen verknüpft, für die das Beibehalten eines bestimmten Zustands wünschenswert ist. Wenn jeder Eintrag zum Beispiel durch eine ganze Zahl identifiziert wird, kann ein Wiedergabekontextzeiger 254 einen ganzzahligen Wert aus einem Umlaufindex speichern, der für jeden neuen Wiedergabekontext erhöht wird und der jedes Mal dann, wenn der letzte Eintrag in der Tabelle erreicht wird, überspringt, um auf den ersten Eintrag zu verweisen. Wie nachfolgend ausführlicher erörtert wird, wird jedes Mal, wenn ein neuer Zustand benötigt und ein neuer Eintrag 246 verwendet wird, ein Wiedergabekontextzeiger 254 so gesetzt, dass er auf den neuen Eintrag verweist, und er wird gemeinsam mit jeglichen im Datenstrom übertragenen Daten für das bestimmte Bildelement bzw. die Gruppe von Bildelementen weitergeleitet, so dass auf den Zustand zugegriffen werden kann, während die im Datenstrom übertragenen Daten zwischen den Stufen der Software-Pipeline weitergeleitet werden. Somit wird für jedes einmalige Bildelement bzw. jede Gruppe von Bildelementen, die einen gemeinsamen Zustand teilen, ein separater Wiedergabekontextzeiger 254 beibehalten, um einen Mechanismus zum Zugreifen auf den Zustand bereitzustellen. Man wird verstehen, dass ein Wiedergabekontextzeiger auf mehrere Arten dargestellt und gemeinsam mit im Datenstrom übertragenen Daten im Datenstrom übertragen oder in anderen Ausführungsformen der Erfindung in gemeinsam genutztem Speicher gespeichert werden kann.
Man wird verstehen, dass die Wiedergabekontexttabelle 244 lediglich eine von unzähligen verschiedenen Datenstrukturen ist, die zum gleichzeitigen Speichern mehrerer „Schnappschüsse“ von in einer Multithread-Software-Pipeline verwendeten Zustandsdaten verwendet werden kann. Deshalb ist die Erfindung nicht auf die bestimmte, in 8 veranschaulichte Umsetzung beschränkt.
Als nächstes veranschaulicht 9 einen Teil einer durch die Verarbeitungseinheit 200 ausgeführten Befehlsverarbeitungsroutine 270, welche die Verwaltung von Wiedergabekontexten in der Multithread-Wiedergabe-Software-Pipeline 230 aus 7 veranschaulicht. Befehle werden üblicherweise durch den HIP 212 (7) von dem Einheitentreiber 218 als Reaktion auf durch die Anwendung 216 erzeugte Funktionsaufrufe empfangen, und bestimmte derartige Befehle erfordern üblicherweise entweder die Verwendung oder die Abänderung des Wiedergabekontexts. Diese Befehle werden in der Routine 270 verarbeitet, um sicherzustellen, dass für ein oder mehrere Bildelemente ein einheitlicher Wiedergabekontext bzw. Zustand beibehalten wird, während derartige Elemente durch die Pipeline 230 verarbeitet werden.
In der veranschaulichten Ausführungsform werden die in 9 veranschaulichten Schritte durch den HIP 212 durchgeführt; in anderen Ausführungsformen können jedoch einige oder alle der Schritte durch eine andere Logik durchgeführt werden, z.B. in einer bestimmten Stufe in der Multithread-Wiedergabe-Software-Pipeline 230.
In der Software-Pipeline 230 werden Bilddaten von Stufe zu Stufe in Form von einem oder mehreren Bildelementen im Datenstrom übertragen. Ein Bildelement kann so grundlegend wie ein Scheitelpunkt sein, oder es kann sich dabei um eine Sammlung von Scheitelpunkten handeln, die ein Basiselement bzw. Objekt darstellt. Mehrere Bildelemente können auch in eine Gruppe zusammengefasst und gemeinsam durch die Pipeline verarbeitet werden. Bildelemente werden anfänglich durch einen HIP 212 einem aktuellen Wiedergabekontext zugewiesen, bevor derartige Bildelemente in der Software-Pipeline verarbeitet werden. Durch den Einheitentreiber 218 werden Befehle erzeugt, die für bestimmte Bildelemente bzw. Gruppen von Bildelementen relevant sind und dazu führen, dass der HIP 212 das Durchführen derartiger Befehle durch verschiedene Stufen in der Pipeline einleitet.
Folglich wird in der Routine 270 in Block 272 durch den HIP 212 ein Befehl von dem Einheitentreiber 218 empfangen. In Block 274 wird festgestellt, ob der Befehl den aktuellen Wiedergabekontext ändern wird. Bei einem einen Wiedergabekontext ändernden Befehl handelt es sich üblicherweise um einen Befehl, der einige einem Bildelement oder einer Gruppe von Bildelementen zugehörige Zustandsdaten ändert, für die ein gemeinsamer Zustand hergestellt wird, während derartige Elemente durch die Pipeline 230 verarbeitet werden. Befehle wie zum Beispiel glRotate, glTranslate und glColor3f u.a. können Wiedergabekontexte abändern, wenn sie ausgeführt werden.
Wenn der Befehl den aktuellen Wiedergabekontext ändert, wird die Steuerung an den Block 276 übergeben, um zu ermitteln, ob der aktuelle Wiedergabekontext gegenwärtig verwendet wird, z.B. durch Überprüfen des Verwendet-Felds 252 für den Eintrag 246 in der Wiedergabekontexttabelle, auf den durch den Wiedergabekontextzeiger 254 verwiesen wird, der dem bzw. den dem Befehl zugehörigen Bildelementen zugehörig ist (8). Falls ermittelt wird, dass der aktuelle Wiedergabekontext nicht verwendet wird, wird die Steuerung an den Block 278 übergeben, um den Wiedergabekontext beruhend auf dem Befehl zu ändern. Wenn der aktuelle Wiedergabekontext nicht verwendet wird, kann die Änderung des Wiedergabekontexts ebenfalls das Zurücksetzen der Daten und/oder das Initialisieren der Daten in dem zugehörigen Eintrag 246 in der Wiedergabekontexttabelle enthalten. Die Routine 270 beendet dann, wie in Block 292 gezeigt, das Verarbeiten des Befehls.
Das Setzen eines Wiedergabekontexts auf „verwendet“ wird als Reaktion auf einen Befehl durchgeführt, der versucht, einen Wiedergabekontext wie glVertex zu verwenden. Zurück zu Block 274, wo somit, wenn der Befehl den aktuellen Wiedergabekontext nicht ändern wird, die Steuerung an den Block 280 übergeben wird, um zu ermitteln, ob der Befehl den Wiedergabekontext verwenden wird. Wenn dem so ist, wird die Steuerung an den Block 282 weitergeleitet, um den Wiedergabekontext „verwendet“ durch Setzen des Verwendet-Felds 252 in dem Tabelleneintrag 246 zu kennzeichnen, auf den der dem bestimmten Bildelement bzw. den bestimmten Bildelementen zugehörige Wiedergabekontextzeiger verweist, woraufhin die Verarbeitung des Befehls in Block 292 fortgeführt wird.
Zurück zu Block 276, wo, wenn ein Befehl den aktuellen Wiedergabekontext ändern wird und dieser Wiedergabekontext aktuell verwendet wird, der Block 276 die Steuerung an den Block 284 übergibt, um den aktuellen Wiedergabekontext in seiner Gesamtheit zu kopieren, z.B. durch Kopieren der Daten in dem aktuellen Eintrag 246 in der Wiedergabekontexttabelle in den nächsten ungenutzten Eintrag 246 in der Wiedergabekontexttabelle in der Tabelle 244. Der Block 286 aktualisiert dann den Wiedergabekontextzeiger für das Bildelement bzw. die Bildelemente, die dem aktuellen Befehl zugehörig sind, damit diese auf den neuen Wiedergabekontext verweisen, und die Steuerung wird an den Block 278 übergeben, um den neuen Wiedergabekontext wie für den Befehl geeignet abzuändern. Folglich behält der ursprüngliche Wiedergabekontext, der durch eine andere Gruppe von in der Pipeline verarbeiteten Bildelementen verwendet wird, seinen ursprünglichen Zustand, und ein neuer, abgeänderter Zustand wird für die aktuelle Gruppe von Bildelementen erzeugt. Man wird verstehen, dass in einigen Ausführungsformen die Verwendung des neuen Wiedergabekontexts für eine Gruppe von Bildelementen es nicht erfordert, dass der aktuelle Wiedergabekontext in den neuen Wiedergabekontext kopiert wird. Man wird auch verstehen, dass jedes Mal, wenn beim Suchen nach einem unbenutzten Wiedergabekontext ein letzter Wiedergabekontexteintrag 246 in der Tabelle 244 erreicht wird, die Suche auf den ersten Eintrag in der Tabelle überspringt. Außerdem kann in einigen Ausführungsformen ein Versuch der Abänderung eines Wiedergabekontexts dadurch verarbeitet werden, dass der bestehende Wiedergabekontext abgeändert wird, nachdem dieser Wiedergabekontext in seiner Gesamtheit kopiert wurde, um einen neuen Wiedergabekontext zu erstellen.
Zur weiteren Veranschaulichung der Verwendung und Erstellung der Wiedergabekontexte wird der oben erörterte beispielhafte OpenGI-Code nachfolgend wiedergegeben:
Angenommen, dass beim Einleiten der Ausführung dieses Codes aktuell kein Wiedergabekontext verwendet wird. Beim Empfangen eines dem Aufruf glColor(0,255,0,255) zugehörigen Befehls kann ermittelt werden, dass der Befehl den aktuellen Wiedergabekontext durch Setzen der aktuellen Farbe auf grün ändert. Demzufolge kann die Routine 270 durch den Pfad der Blöcke 272, 274, 276 und 278 fortfahren, um den aktuellen Wiedergabekontext zu ändern und die aktuelle Farbe auf grün zu setzen. Beim Empfangen eines Befehls zum Festlegen eines Scheitelpunkts beruhend auf dem Aufruf glVertex3f(100.0f, 100.0f, 0.0f) kann die Routine 270 durch den Pfad der Blöcke 272, 274, 280 und 282 fortfahren und den aktuellen Wiedergabekontext auf „verwendet“ setzen, da der Aufruf glVertex3f() ein Bildelement erstellt, das nun den aktuellen Wiedergabekontext verwendet.
Beim Empfangen eines dem Aufruf glColor(0,255,0,255) zugehörigen Befehls kann als nächstes ermittelt werden, dass der Befehl den aktuellen Wiedergabekontext durch Setzen der aktuellen Farbe auf blau ändert. Da der aktuelle Wiedergabekontext jetzt jedoch als verwendet gekennzeichnet ist, kann die Routine 270 durch die Blöcke 272, 274, 276, 284, 286 und 278 fortfahren und einen neuen Wiedergabekontext erstellen, die Zustandsdaten von dem bestehenden Wiedergabekontext in den neuen Wiedergabekontext kopieren, den Wiedergabekontextzeiger so aktualisieren, dass er auf den neuen Wiedergabekontext verweist, und den neuen Wiedergabekontext so ändern, dass er die aktuelle Farbe auf blau setzt. Beim Empfangen eines Befehls zum Festlegen eines Scheitelpunkts beruhend auf dem Aufruf glVertex3f(150.0f, 100.0f, 0.0f) kann die Routine 270 wiederum durch den Pfad der Blöcke 272, 274, 280 und 282 fortfahren und den neuen Wiedergabekontext auf „verwendet“ setzen, da der Aufruf glVertex3f() ein zweites Bildelement erstellt, das nun den neuen Wiedergabekontext verwendet, in dem die Farbe auf blau gesetzt ist. Auf ähnliche Weise wird für die Aufrufe glColor(255,0,0,255) und Vertex3f(125.0f, 50.0f, 0.0f) ein neuer Wiedergabekontext mit einem Zustand erstellt, in dem die aktuelle Farbe auf rot gesetzt ist, und das dritte Bildelement verwendet diesen Kontext, was zur Folge hat, dass jeder der drei Scheitelpunkte durch die Pipeline mit separaten und unabhängigen Zuständen verarbeitet wird.
Man wird verstehen, dass vom Standpunkt einer Multithread-Wiedergabe-Software-Pipeline aus die Funktion der Routine 270 durch Verarbeiten von Befehlen von dem Einheitentreiber 218 sicherstellt, dass Bildelemente an verschiedene Stufen und Instanzen von Stufen in der Pipeline geleitet werden können, ohne Sorge, dass das Verarbeiten von anderen Bildelementen den für derartige Bildelemente verwendeten Kontext bzw. Zustand ändern wird. Deshalb können verschiedene Bildelemente parallel und in vielen Fällen ohne Sorge um die Reihenfolge der Ausführung verarbeitet werden, wodurch der Durchsatz durch die Pipeline maximiert und Konflikte bezüglich der seriellen Reihenfolge und beim Konkurrenzbetrieb minimiert werden. Die Routine 270 und die Hardware, auf der die Routine umgesetzt ist, agieren folglich als Steuerlogik, die jedes Bildelement mit einem Wiedergabekontext in der Wiedergabekontexttabelle verknüpft, so dass Zustandsdaten in einem ersten Kontext, der einem ersten Bildelement zugehörig ist, infolge einer Änderung von Zustandsdaten in einem zweiten Kontext, der einem zweiten Bildelement zugehörig ist, während des Verarbeitens des zweiten Bildelements durch die Multithread-Wiedergabe-Software-Pipeline unverändert bleiben.
Zurück zu Block 280 aus 9, wo die Steuerung an den Block 288 übergeben wird, wenn ein Befehl einen Wiedergabekontext nicht verwendet oder ändert, um zu ermitteln, ob ein Wiedergabekontext freigegeben werden sollte. Wenn dem so ist, wird die Steuerung an den Block 290 übergeben, um den entsprechenden Eintrag in der Wiedergabekontexttabelle als nicht verwendet zu kennzeichnen, wodurch die Steuerung dann an den Block 292 übergeben wird. Wenn kein Wiedergabekontext freigegeben werden soll, umgeht der Block 288 den Block 290 und übergibt die Steuerung direkt an den Block 292.
Zum Freigeben von Wiedergabekontexten können mehrere Techniken verwendet werden. Es kann zum Beispiel ein spezifischer Befehl erzeugt werden, um einen Wiedergabekontext freizugeben, wenn bekannt ist, dass der Wiedergabekontext nicht mehr verwendet werden wird. Ein derartiger Befehl kann explizit als Folge eines Funktionsaufrufs durch eine Anwendung erzeugt werden, oder alternativ kann die Tatsache, dass ein Wiedergabekontext nicht mehr verwendet werden wird, erkannt und dafür verwendet werden, den Wiedergabekontext automatisch freizugeben. Der HIP 212 kann zum Beispiel erkennen, dass ein späterer Befehl den aktuellen Wiedergabekontext verändern wird, und einen aktuellen Befehl kennzeichnen, um anzugeben, dass der Befehl der letzte Befehl sein wird, der den aktuellen Wiedergabekontext verwendet. Die Blöcke 288 und 290 aus 9 können zum Beispiel in einer bestimmten Stufe in der Pipeline 230 umgesetzt werden, z.B. in der Rasterisierungseinheit 238, so dass die Rasterisierungseinheit 238 beim Erkennen eines Befehls, der durch den HIP als letzter den aktuellen Wiedergabekontext verwendender Befehl gekennzeichnet wurde, den Wiedergabekontext automatisch auf die oben beschriebene Weise freigibt. Alternativ kann die Rasterisierungseinheit 238 einen späteren Befehl entdecken, der den Wiedergabekontext ändert. Als weitere Alternative kann der HIP ein „Säuberungs-“ („flush“) Paket die Pipeline hinunter senden, um einen bestimmten Wiedergabekontext freizugeben. Man wird auch verstehen, dass andere Stufen für das Freigeben von nicht verwendeten Wiedergabekontexten verantwortlich sein können, obwohl es in vielen Fällen wünschenswert ist, Wiedergabekontexte in der letzten Stufe freizugeben, in der die durch einen Wiedergabekontext dargestellten Zustandsdaten verwendet werden können.
Als weitere Alternative können ein oder mehrere Zähler zum Verfolgen der Verwendung jedes Wiedergabekontexts verwendet werden. Ein HIP kann zum Beispiel jedes Mal dann, wenn ein Wiedergabekontext durch einen Befehl verwendet wird, einen „Verwendet“-Zähler erhöhen, während jede Rasterisierungseinheit jedes Mal dann einen „Frei“-Zähler erhöht, wenn ein den Wiedergabekontext verwendender Befehl abgeschlossen wurde. Jede Rasterisierungseinheit kann dann die Verwendet- und Frei-Zähler vergleichen und jedes Mal dann einen Wiedergabekontext automatisch freigeben, wenn die beiden Zähler gleich sind. In anderen Ausführungsformen kann an Stelle von separaten Zählern ein einzelner Zähler verwendet werden, der jedes Mal dann erhöht wird, wenn ein Befehl den Wiedergabekontext verwendet, und jedes Mal dann um eine Einheit vermindert wird, wenn ein den Wiedergabekontext verwendender Befehl abgeschlossen wurde. Andere Mechanismen zum Erkennen und Freigeben von nicht verwendeten Wiedergabekontexten sind für einen gewöhnlichen Fachmann mit Unterstützung der vorliegenden Darlegung ersichtlich.
Zwischenspeichern von Kontextdaten in einer Vektorregisterdatei
In einigen Ausführungsformen kann der Zugriff auf Kontextdaten sowie auf andere von einer Multithread-Grafikverarbeitungsarchitektur verwendete Zustandsdaten optimiert werden, indem derartige Daten in einer Vektorregisterdatei in einer Verarbeitungseinheit zwischengespeichert werden und die Vektorregisterdatei in ihrer Wirkung als Software-Speicher-Kombinations-Warteschlange verwendet wird. Man hat insbesondere herausgefunden, dass in einigen in Bildverarbeitungsanwendungen verwendeten Verarbeitungseinheiten Vektorregister möglicherweise nicht ausgelastet sind, wenn derartige Verarbeitungseinheiten derartige Aufgaben durchführen. In einer Verarbeitungseinheit, die sowohl eine skalare Festkomma-Ausführungseinheit als auch eine Vektor-Gleitkomma-Ausführungseinheit enthält, können bestimmte Aufgaben festkomma-intensiv sein, und folglich wird die Vektorregisterdatei in der Vektor-Gleitkomma-Ausführungseinheit möglicherweise während der Durchführung derartiger Aufgaben nicht verwendet und kann somit in bestimmten Situationen anders verwendet werden, um Zustandsdaten vorübergehend zwischenzuspeichern, die von der Festkomma-Ausführungseinheit verwendet werden können.
10 veranschaulicht zum Beispiel eine beispielhafte Vorrichtung 300, die eine mit einem Speicher 304 verbundene Verarbeitungseinheit 302 enthält. Die Verarbeitungseinheit 302 enthält eine Anweisungseinheit 306, eine skalare Festkomma-Ausführungseinheit (XU) 308 und eine Vektor-Gleitkomma-Ausführungseinheit (AXU) 310. In der veranschaulichten Ausführungsform kann die Verarbeitungseinheit als IP-Block, wie zum Beispiel der IP-Block 104 aus 4, umgesetzt sein und sich gemeinsam mit einer Vielzahl von anderen IP-Blöcken in einer NOC-Anordnung, wie zum Beispiel in der integrierten Schaltungseinheit 100 aus 2, befinden. Man wird jedoch verstehen, dass die Grundgedanken der Erfindung für eine Vielzahl von anderen Konfigurationen von Verarbeitungseinheiten gelten können, die Festkomma- und Vektor-Gleitkomma-Ausführungseinheiten enthalten, und als solche ist die Erfindung nicht auf die bestimmten hierin dargelegten Konfigurationen beschränkt.
Die Festkomma-Ausführungseinheit 308 enthält eine Registerdatei, die eine Vielzahl von Universalregistern (GPRs) 312 enthält, während die Vektor-Gleitkomma-Ausführungseinheit 310 eine Vektorregisterdatei enthält, die eine Vielzahl von Vektor-Gleitkomma-Registern 314 enthält. Man wird verstehen, dass die Register 314 üblicherweise viel breiter als die GPRs 312 sind, und Datenübertragungen zwischen der Vektorregisterdatei und dem Speicher 304 werden über breitere Datenpfade als Datenübertragungen zwischen der Festkomma-Ausführungseinheit-Registerdatei und dem Speicher 304 durchgeführt. Als solches benötigt das Übertragen einer gleichwertigen Datenmenge zwischen dem Speicher 304 und der Vektor-Gleitkomma-Ausführungseinheit 310 üblicherweise weniger Zyklen als zwischen dem Speicher 304 und der Festkomma-Ausführungseinheit 308.
Außerdem kann es wünschenswert sein, schnelle Verschiebungen zwischen den Registerdateien der Ausführungseinheiten 308, 310 durch Bereitstellung eines speziell dafür vorgesehenen Busses zwischen den Ausführungseinheiten 308, 310 zu unterstützen. Es kann zum Beispiel wünschenswert sein, dass der Anweisungssatz der Verarbeitungseinheit 302 Anweisungen zum schnellen Verschieben zum Übertragen von Daten zwischen Quell- und Zielregistern unterstützt.
In der veranschaulichten Ausführungsform sind die in der Vektorregisterdatei zwischengespeicherten Zustandsdaten in Wiedergabekontexte organisiert, z.B. wie oben in Verbindung mit den 7 bis 9 beschrieben, und werden von einer Multithread-Software-Pipeline verwendet. Eine Wiedergabekontexttabelle 316 kann zum Beispiel in dem Speicher 304 gespeichert sein und mehrere Wiedergabekontexte 318 enthalten. Man wird verstehen, dass der Speicher 304 verschiedene Ebenen von Zwischenspeichern und Hauptspeicher darstellen kann, und dass die Wiedergabekontexte 318 jederzeit gesamt oder teilweise in einem oder mehreren Cachespeichern zwischengespeichert werden können. Man hat jedoch herausgefunden, dass insbesondere in einer in einem NOC integrierten Verarbeitungseinheit mehrere Threads in einer Software-Pipeline, die versuchen auf Wiedergabekontexte zuzugreifen, eine erhebliche Menge an Speicherbandbreite in einer mehrstufigen Speicherarchitektur verbrauchen können, insbesondere wenn Durchschreibcaches, wie am häufigsten üblich L1-Cachespeicher, verwendet werden.
Ausführungsformen in Übereinstimmung mit der Erfindung verringern andererseits den Verbrauch an Speicherbandbreite durch Zwischenspeichern eines Wiedergabekontexts gesamt oder teilweise in einem oder mehreren Vektor-Gleitkomma-Registern 314, wie bei 320 veranschaulicht ist. Vor allem enthält zumindest ein Teil eines Wiedergabekontexts üblicherweise Nicht-Gleitkommadaten (z.B. ganzzahlige Daten, Zeichendaten, Festkommadaten usw.), und diese Nicht-Gleitkommadaten werden effektiv in einem Register zwischengespeichert, das normalerweise in Verbindung mit dem Speichern von Gleitkommadaten verwendet wird. Man wird jedoch verstehen, dass Gleitkommadaten auch in einem Wiedergabekontext enthalten sein können, so dass sowohl Gleitkomma- als auch Nicht-Gleitkommadaten in einigen Ausführungsformen als Wiedergabekontext zwischengespeichert werden können.
Jedes Mal, wenn die Festkomma-Ausführungseinheit 308 auf die Nicht-Gleitkommadaten aus einem Wiedergabekontext zugreifen muss, kopiert die Verarbeitungseinheit 302 die Nicht-Gleitkommadaten von der Vektorregisterdatei in ein oder mehrere Universalregister 312, wie zum Beispiel bei 322 veranschaulicht ist. Wie oben erwähnt können Anweisungen zum schnellen Verschieben verwendet werden, um die notwendigen Übertragungen in einigen Ausführungsformen durchzuführen. Sobald die Daten in den entsprechenden Universalregistern gespeichert sind, kann die Festkomma-Ausführungseinheit 308 mit den Daten arbeiten.
Als nächstes können jedes Mal dann, wenn die Kontextdaten durch die Festkomma-Ausführungseinheit aktualisiert werden, die aktualisierten Kontextdaten mit der in der Vektorregisterdatei gespeicherten Kopie sowie mit der in dem Speicher 304 beibehaltenen Originalkopie synchronisiert werden. In einigen Ausführungsformen kann es jedoch wünschenswert sein, Cachespeicher-Kohärenz-Techniken zu integrieren, um unnötige Aktualisierungen der Vektorregisterdatei und/oder des Speichers 304 zu minimieren, z.B. so, dass jegliche Speichervorgänge in den Kontextdaten, welche die Daten nicht ändern, es nicht erfordern, dass in der Speicherarchitektur eine Speichertransaktion durchgeführt wird.
In einigen Ausführungsformen in Übereinstimmung mit der Erfindung kann das Zwischenspeichern in einer Vektorregisterdatei umgesetzt werden, indem in dem Anweisungssatz der Verarbeitungseinheit festgelegte Anweisungen verwendet werden, so dass das Zwischenspeichern in einer Vektorregisterdatei effektiv durch eine Anwendung, eine Firmware, ein Betriebssystem, einen Kernel usw. umgesetzt wird, und die zum Umsetzen einer derartigen Funktionalität benötigten Anweisungen können durch einen Kompilierer oder ein anderes automatisiertes Tool erzeugt werden. In anderen Ausführungsformen kann die zum Umsetzen des Zwischenspeicherns in einer Vektorregisterdatei benötigte Funktionalität jedoch z.B. unter Verwendung eines Sequencer oder einer anderen speziell dafür vorgesehenen Logik direkt in der Verarbeitungseinheit 304 umgesetzter Schaltkreislogik umgesetzt werden. Deshalb kann die Erfindung üblicherweise unter Verwendung verschiedener Kombinationen aus Hardware und Software umgesetzt werden und ist somit nicht auf die bestimmte hierin dargelegte Umsetzung beschränkt.
Die 11 bis 12 veranschaulichen zum Beispiel die Routinen 330, 340 zum Laden bzw. Speichern von Kontextdaten, und für die Zwecke dieser Routinen kann angenommen werden, dass Wiedergabekontexte vollständig in der Vektorregisterdatei zwischengespeichert werden. In anderen Ausführungsformen werden möglicherweise lediglich Teile von Wiedergabekontexten zwischengespeichert. In einer Ausführungsform in Übereinstimmung mit der Erfindung sind Kontexte ungefähr 2 kB groß, und Vektor-Gleitkomma-Register sind 16 Byte breit, so dass ein Wiedergabekontext in 128 Registern ohne Komprimierung zwischengespeichert werden kann.
Wie in 11 gezeigt ist, beginnt die Routine 330 zum Laden von Kontextdaten, die zum Beispiel jedes Mal dann aufgerufen werden kann, wenn die Festkomma-Ausführungseinheit mit diesen Daten arbeiten muss, in dem Block 332 mit dem Ermitteln, ob der Wiedergabekontext, in dem die angeforderten Daten organisiert sind, bereits in der Vektorregisterdatei zwischengespeichert ist. Wenn dem nicht so ist, wird die Steuerung an den Block 334 übergeben, um den Wiedergabekontext in einen Satz Vektor-Gleitkomma-Register zu laden. Außerdem kann es in einigen Ausführungsformen wünschenswert sein, die Daten in einem Wiedergabekontext unter Verwendung einer Packanweisung zu komprimieren, so dass der Wiedergabekontext in weniger Registern gespeichert werden kann.
Als nächstes wird die Steuerung an den Block 336 übergeben, sobald der Wiedergabekontext in Block 334 in der Vektorregisterdatei zwischengespeichert wurde oder wenn der Block 332 ermittelt, dass der Wiedergabekontext bereits zwischengespeichert ist, um die angeforderten Kontextdaten von der Vektorregisterdatei in ein oder mehrere Universalregister in der Registerdatei der Festkomma-Ausführungseinheit zu verschieben. Danach sind die Kontextdaten zur Verwendung durch die Festkomma-Ausführungseinheit verfügbar, und die Routine 330 ist abgeschlossen.
12 veranschaulicht die Routine 340 zum Speichern von Kontextdaten, die zum Beispiel jedes Mal dann aufgerufen wird, wenn es wünschenswert ist, Kontextdaten nach der Änderung durch die Festkomma-Ausführungseinheit zu speichern. Die Routine 340 beginnt in dem Block 342 durch Vergleichen des/der relevanten Universalregister(s) mit den entsprechenden Daten in der Vektorregisterdatei. Der Block 344 ermittelt dann, ob die Daten geändert wurden. Wenn dem nicht so ist, besteht keine Notwendigkeit zum Synchronisieren der Kontextdaten in dem/den Universalregister(n) mit der Vektorregisterdatei bzw. dem Speicher, so dass der Block 344 die Routine 340 beenden kann.
Andernfalls übergibt der Block 344 die Steuerung an den Block 346, um die Kontextdaten von dem/den GPR(s) in die Vektorregisterdatei zu verschieben, und dann an den Block 348, um die geänderten Daten in der Kopie des Wiedergabekontexts in dem Speicher zu speichern. Außerdem kann eine Entpackanweisung zum Dekomprimieren der Daten vor dem Zurückspeichern in den Speicher verwendet werden, wenn die Daten in der Vektorregisterdatei komprimiert sind. Die Routine 340 ist dann abgeschlossen.
Man wird deshalb verstehen, dass insbesondere in Anwendungen, in denen eine Vektorregisterdatei für bestimmte Aufgaben nicht ausgelastet ist, sonst ungenutzte Vektorregister anderweitig zur Verwendung als kurzzeitige Zwischenspeicher verwendet werden und den mit derartigen Zustandsdaten verbundenen Speicherverwaltungsaufwand erheblich verringern können. Des Weiteren kann durch die Verwendung von Anweisungen zum Packen/Entpacken und durch schnelle Verschiebungen zwischen den Universalregistern und der Vektorregisterdatei in einigen Ausführungsformen der Erfindung der Verbrauch von wertvollem Registerspeicher und die mit dem Zugreifen auf Zustandsdaten verbundene Latenzzeit außerdem minimiert werden. Außerdem wird durch die üblicherweise mit Vektorregisterdateien verbundenen breiteren Datenpfade die Anzahl von Zyklen, die zum Übertragen von Daten zwischen dem Speicher und der Vektorregisterdatei benötigt werden, im Vergleich zu der Anzahl von Zyklen verringert, die benötigt würden, um dieselbe Menge an Daten zwischen dem Speicher und den durch die Festkomma-Ausführungseinheit verwendeten Universalregistern zu übertragen.
Man wird auch verstehen, dass es in einigen Ausführungsformen wünschenswert sein kann, eine Funktionalität zum Löschen von in den Universalregistern und/oder der Vektorregisterdatei gespeicherten Kontextdaten beruhend auf Platzeinschränkungen zu integrieren, ähnlich wie bei herkömmlichen Cachespeichern. Es können außerdem verschiedene andere Abänderungen vorgenommen werden, ohne von dem Umfang der Erfindung abzuweichen. Deshalb liegt die Erfindung in den nachfolgend beigefügten Ansprüchen.

Claims

Schaltkreisanordnung, die Folgendes umfasst: eine Verarbeitungseinheit, die eine Festkomma-Ausführungseinheit und eine Vektor-Gleitkommaeinheit enthält, wobei die Festkomma-Ausführungseinheit eine Vielzahl von Universalregistern enthält und die Vektor-Gleitkommaeinheit eine Vektorregisterdatei enthält; und ein Speicher, der mit der Verarbeitungseinheit verbunden ist und zum Zwischenspeichern von Daten dient, wobei die Verarbeitungseinheit so konfiguriert ist, dass sie Zustandsdaten, darunter von der Festkomma-Ausführungseinheit verwendete Nicht-Gleitkomma-Zustandsdaten in der Vektorregisterdatei zwischenspeichert, wobei die Verarbeitungseinheit ferner so konfiguriert ist, dass sie die Nicht-Gleitkomma-Zustandsdaten von der Vektorregisterdatei in mindestens ein Universalregister aus der Vielzahl von Universalregistern über einen zugewiesenen Bus zwischen der Vektorregisterdatei und den mehreren Universalregistern kopiert, und wobei die Festkomma-Ausführungseinheit so konfiguriert ist, dass sie mit den in dem mindestens einen Universalregister gespeicherten Nicht-Gleitkomma-Zustandsdaten arbeitet.
Schaltkreisanordnung nach Anspruch 1, bei welcher der Programmcode ferner so konfiguriert ist, dass er nach einer Abänderung der in dem mindestens einen Universalregister gespeicherten Nicht-Gleitkomma-Zustandsdaten die Nicht-Gleitkomma-Zustandsdaten von dem mindestens einen Universalregister in die Vektorregisterdatei kopiert.
Schaltkreisanordnung nach Anspruch 1 oder 2, bei der die Zustandsdaten einer Kontextdatenstruktur zur Verwendung beim Speichern von Zustandsdaten zugehörig sind, die von einer Vielzahl von Stufen in einer Multithread-Wiedergabe-Software-Pipeline in einer Grafikverarbeitungsarchitektur gemeinsam genutzt werden, wobei die Verarbeitungseinheit so konfiguriert ist, dass sie mindestens einen Thread für die Multithread-Wiedergabe-Software-Pipeline ausführt, und wobei eine Kopie der Kontextdatenstruktur in dem Speicher behalten wird, mit dem die Verarbeitungseinheit verbunden ist.
Schaltkreisanordnung nach einem der vorhergehenden Ansprüche, bei welcher der Programmcode ferner so konfiguriert ist, dass er zumindest einen Teil der in der Vektorregisterdatei gespeicherten Kontextdatenstruktur mit der Kopie der in dem Speicher gespeicherten Kontextdatenstruktur durch Schreiben des Teils der in der Vektorregisterdatei gespeicherten Kontextdatenstruktur zurück in den Speicher synchronisiert.
Schaltkreisanordnung nach einem der vorhergehenden Ansprüche, bei der die Verarbeitungseinheit so konfiguriert ist, dass sie ermittelt, ob sich der Teil der in der Vektorregisterdatei gespeicherten Kontextdatenstruktur vor dem Schreiben des Teils der Kontextdatenstruktur zurück in den Speicher geändert hat, wobei die Verarbeitungseinheit ferner so konfiguriert ist, dass sie das Schreiben des Teils der Kontextdatenstruktur zurück in den Speicher als Reaktion auf das Ermitteln, dass sich der Teil der in der Vektorregisterdatei gespeicherten Kontextdatenstruktur nicht geändert hat, unterdrückt.
Schaltkreisanordnung nach einem der vorhergehenden Ansprüche 3 bis 5, bei der die Verarbeitungseinheit so konfiguriert ist, dass sie beim Zwischenspeichern der Zustandsdaten in der Vektorregisterdatei Daten aus der in dem Speicher gespeicherten Kontextdatenstruktur komprimiert, und wobei die Verarbeitungseinheit so konfiguriert ist, dass sie beim Schreiben von Daten aus der Kontextdatenstruktur zurück in den Speicher Daten aus der Kontextdatenstruktur in der Vektorregisterdatei dekomprimiert.
Schaltkreisanordnung nach einem der vorhergehenden Ansprüche 3 bis 6, bei der die Kontextdatenstruktur eine rollierende Kontextdatenstruktur enthält, auf die von der Vielzahl von Stufen in der Multithread-Wiedergabe-Software-Pipeline zugegriffen werden kann, wobei die rollierende Kontextdatenstruktur so konfiguriert ist, dass sie eine Vielzahl von Kontexten speichern kann, wobei jeder Kontext so konfiguriert ist, dass er Zustandsdaten für mindestens ein Bildelement speichert, wenn das mindestens eine Bildelement durch die Vielzahl von Stufen der Multithread-Wiedergabe-Software-Pipeline verarbeitet wird, und wobei die Verarbeitungseinheit so konfiguriert ist, dass sie jedem Bildelement einen Kontext in der rollierenden Kontextdatenstruktur zuordnet, so dass Zustandsdaten in einem ersten Kontext, der einem ersten Bildelement zugehörig ist, als Reaktion auf eine durchgeführte Änderung von Zustandsdaten in einem zweiten Kontext, der einem zweiten Bildelement zugehörig ist, während des Verarbeitens des zweiten Bildelements durch die Multithread-Wiedergabe-Software-Pipeline unverändert bleiben.
Schaltkreisanordnung nach Anspruch 7, bei der das zweite Bildelement nach dem ersten Bildelement durch die Multithread-Wiedergabe-Software-Pipeline empfangen wird, und bei der die Verarbeitungseinheit so konfiguriert ist, dass sie: als Reaktion auf das Empfangen des zweiten Bildelements durch die Multithread-Wiedergabe-Software-Pipeline das zweite Bildelement anfänglich mit dem ersten Kontext verknüpft; und als Reaktion auf einen Versuch der Änderung der Zustandsdaten für das zweite Bildelement, während der erste Kontext für das erste Bildelement verwendet wird, die Zustandsdaten von dem ersten Kontext in den zweiten Kontext kopiert, das zweite Bildelement mit dem zweiten Kontext verknüpft und die in dem zweiten Kontext gespeicherten Zustandsdaten abändert.
Schaltkreisanordnung nach Anspruch 8, bei der die Verarbeitungseinheit ferner so konfiguriert ist, dass sie als Reaktion darauf, dass die Zustandsdaten in dem ersten Kontext durch die Multithread-Wiedergabe-Software-Pipeline für das erste Bildelement verwendet werden, den ersten Kontext als verwendet kennzeichnet, und bei der die Verarbeitungseinheit so konfiguriert ist, dass sie die Zustandsdaten von dem ersten Kontext in den zweiten Kontext kopiert und als Reaktion auf das Ermitteln, dass der erste Kontext als verwendet gekennzeichnet ist, das zweite Bildelement mit dem zweiten Kontext verknüpft.
Schaltkreisanordnung nach einem der vorhergehenden Ansprüche 7 bis 9, bei der die in jedem Kontext gespeicherten Zustandsdaten eine Vielzahl von Zustandsattributen enthalten, die aus der Gruppe ausgewählt wurden, die aus einem Verweis auf einen Farbpuffer, einem Verweis auf ein Kugelabbild, einem Verweis auf ein Texturabbild, ein Drehattribut, ein Beleuchtungsattribut, ein Mischattribut, eine Bildschirmverschiebung und Kombinationen daraus besteht.
Integrierte Schaltkreiseinheit, welche die Schaltkreisanordnung nach einem der vorhergehenden Ansprüche enthält.
Programmprodukt, das ein durch einen Computer lesbares Medium und sich auf dem durch einen Computer lesbaren Medium befindlichen Logikdefinitions-Programmcode enthält, der die Schaltkreisanordnung nach einem der vorhergehenden Ansprüche festlegt.
Verfahren zum Zwischenspeichern von Zustandsdaten in einer Verarbeitungseinheit, die mit einem Speicher verbunden ist, und die eine Festkomma-Ausführungseinheit und eine Vektor-Gleitkommaeinheit enthält, wobei die Festkomma-Ausführungseinheit eine Vielzahl von Universalregistern enthält und die Vektor-Gleitkommaeinheit eine Vektorregisterdatei enthält, wobei das Verfahren Folgendes umfasst: Zwischenspeichern von Zustandsdaten, darunter von der Festkomma-Ausführungseinheit verwendete Nicht-Gleitkomma-Zustandsdaten, in der Vektorregisterdatei; Kopieren der Nicht-Gleitkomma-Zustandsdaten von der Vektorregisterdatei in mindestens ein Universalregister aus der Vielzahl von Universalregistern über einen zugewiesenen Bus zwischen der Vektorregisterdatei und den mehreren Universalregistern; und Ausführen von Arbeitsschritten mit den in dem mindestens einen Universalregister gespeicherten Nicht-Gleitkomma-Zustandsdaten.
Verfahren nach Anspruch 13, das ferner nach einer Abänderung der in dem mindestens einen Universalregister gespeicherten Nicht-Gleitkomma-Zustandsdaten das Kopieren der Nicht-Gleitkomma-Zustandsdaten von dem mindestens einen Universalregister in die Vektorregisterdatei umfasst.
Verfahren nach Anspruch 13 oder 14, bei dem die Zustandsdaten einer Kontextdatenstruktur zur Verwendung beim Speichern von Zustandsdaten zugehörig sind, die von einer Vielzahl von Stufen in einer Multithread-Wiedergabe-Software-Pipeline in einer Grafikverarbeitungsarchitektur gemeinsam genutzt werden, wobei das Verfahren ferner das Ausführen von mindestens einem Thread für die Multithread-Wiedergabe-Software-Pipeline in der Verarbeitungseinheit umfasst, und wobei eine Kopie der Kontextdatenstruktur in dem Speicher behalten wird, mit dem die Verarbeitungseinheit verbunden ist.