DE102016125846A1

DE102016125846A1 - Makro-E/A-Einheit für Grafikprozessor

Info

Publication number: DE102016125846A1
Application number: DE102016125846.6A
Authority: DE
Inventors: Albert Meixner; Neeti Desai; Dilan Manatunga; Jason Rupert Redgrave; William R. Mark
Original assignee: Google LLC
Current assignee: Google LLC
Priority date: 2016-02-28
Filing date: 2016-12-29
Publication date: 2017-08-31
Also published as: GB2577959A; US20170256230A1; TWI702840B; TWI745084B; GB2577959B; TW201921955A; GB2551412B; US10380969B2; GB2551412A; EP3420526A1; CN107133016A; CN107133016B; TW202112140A; US20170249921A1; US10733956B2; TWI650013B; JP2019509549A; JP6750022B2; GB201910667D0; US10504480B2

Abstract

Ein Grafikprozessor wird beschrieben. Der Grafikprozessor beinhaltet eine E-/A-Einheit zum Einlesen von Eingabebilddaten aus einem externen Speicher zur Verarbeitung durch den Grafikprozessor und zum Schreiben der Ausgabedaten aus dem Grafikprozessor in den externen Speicher. Die E-/A-Einheit beinhaltet mehrere logische Kanaleinheiten. Jede logische Kanaleinheit soll einen logischen Kanal zwischen dem externen Speicher und einer jeweiligen Erzeuger- oder Abnehmerkomponente innerhalb des Grafikprozessors bilden. Jede logische Kanaleinheit ist dafür ausgelegt, eine Umformatierungsschaltung und eine Adressierungsschaltung zu verwenden. Die Adressierungsschaltung dient dazu, Adressierungsschemata zu steuern, die auf dem externen Speicher angewendet werden, sowie eine Umformatierung der Bilddaten zwischen dem externen Speicher und der jeweiligen Erzeuger- oder Abnehmerkomponente zu steuern. Die Umformatierungsschaltung dient dazu, die Umformatierung durchzuführen.

Description

VERWEIS AUF VORANMELDUNG
Diese Anmeldung beansprucht die Priorität der provisorischen US-Anmeldung Nr. 62/300,880, „Makro-E/A-Einheit für Grafikprozessor“, eingereicht am 28. Februar 2016, die hiermit in ihrer Gesamtheit durch Bezugnahme aufgenommen ist.
Gebiet der Erfindung
Das Gebiet der Erfindung betrifft im Allgemeinen die Bildverarbeitung und insbesondere eine Makro-E/A-Einheit für einen Grafikprozessor.
Hintergrund
Die Bildverarbeitung beinhaltet in der Regel die Verarbeitung von Bildpunktwerten, die in einer Matrix gegliedert sind. Hierbei erfasst eine räumlich gegliederte zweidimensionale Matrix die zweidimensionale Natur von Bildern (zusätzliche Dimensionen können unter anderem Zeit (z. B. eine Sequenz von zweidimensionalen Bildern) und Datentyp (z. B. Farben) einschließen. In einem typischen Szenario werden die geordneten Bildpunktwerte von einer Kamera bereitgestellt, die ein Standbild oder eine Folge von Frames erzeugt hat, um die Bewegung in Bildern zu erfassen. Herkömmliche Grafikprozessoren fallen in der Regel auf eine Seite von zwei Extremen.
Ein erstes Extrem führt Bildverarbeitungsschritte als Softwareprogramme aus, die auf einem Universalprozessor oder einem universell verwendbaren Prozessor (z. B. einem Universalprozessor mit Vektorbefehlserweiterungen) ausgeführt werden. Obwohl das erste Extrem in der Regel eine vielseitig einsetzbare Anwendungs-Software-Entwicklungsplattform bereitstellt, resultiert dessen Verwendung feinerer Datenstrukturen, die mit den zugehörigen Verwaltungsdaten kombiniert werden (z. B. Befehlsabruf und -dekodierung, Handhabung von chipinternen und chipexternen Daten, spekulative Ausführung) letztendlich in einen Verbrauch größerer Energiemengen pro Dateneinheit während der Ausführung der Programmcodes.
Ein zweites, entgegengesetztes Extrem wendet stationäre, fest verdrahtete Schaltkreise auf viel größere Datenblöcke an. Die Verwendung von größeren (im Gegensatz zu feineren) Datenblöcken, die direkt auf benutzerdefinierte Schaltkreise angewendet werden, verringert den Energieverbrauch pro Dateneinheit erheblich. Jedoch führt die Verwendung von benutzerdefinierten stationären Funktionsschaltkreise im Allgemeinen zu einer begrenzten Menge von Arbeitsschritten, die der Prozessor ausführen kann. Dementsprechend fehlt im zweiten Extrem die vielseitige Programmierumgebung (die mit dem ersten Extrem verbunden ist).
Eine Technologieplattform, die sowohl vielseitige Anwendungssoftware-Entwicklungsmöglichkeiten als auch eine verbesserte Energieeffizienz pro Dateneinheit bietet, bleibt eine wünschenswerte und dennoch fehlende Lösung.
Kurzdarstellung
Ein Grafikprozessor wird beschrieben. Der Grafikprozessor beinhaltet eine E/A-Einheit zum Einlesen von Eingangsbilddaten aus einem externen Speicher, welche von dem Grafikprozessor verarbeitet und als Ausgabebilddaten von dem Grafikprozessor in den externen Speicher geschrieben werden. Die E/A-Einheit beinhaltet mehrere logische Kanaleinheiten. Jede logische Kanaleinheit dient dazu, einen logischen Kanal zwischen dem externen Speicher und einer jeweiligen Erzeuger- oder Abnehmerkomponente innerhalb des Grafikprozessors zu bilden. Jede logische Kanaleinheit ist dafür ausgelegt, eine Umformatierungs- und eine Adressierungsschaltung zu verwenden. Die Adressierungsschaltung dient zum Steuern von Adressierungsschemata, die auf den externen Speicher angewendet werden, und zum Umformatieren von Bilddaten zwischen dem externen Speicher und der jeweiligen Erzeuger- oder Abnehmerkomponente. Die Umformatierungsschaltung dient zur Durchführung der Umformatierung.
Eine Vorrichtung wird beschrieben. Die Vorrichtung beinhaltet ein Instrument, die eine logische Verbindung zu einer Abnehmerkomponente innerhalb eines Grafikprozessors ermöglicht. Die Vorrichtung beinhaltet zudem ein Instrument zum Einlesen einer Reihe von Bildbereichen mit begrenzter Breite aus einem Frame von Bilddaten, wobei jeder der Bildbereiche gemäß einem RGB-Format formatiert ist. Die Vorrichtung beinhaltet außerdem Instrumente zum Umformatieren der Reihe von Bildbereichen mit begrenzter Breite in Bilddatenblöcke mit derselben Farbe. Die Vorrichtung beinhaltet darüber hinaus ein Instrument zum Weiterleiten der Bilddatenblöcke, die dieselbe Farbe aufweisen, an die Abnehmerkomponente.
Figurenverzeichnis
Die folgende Beschreibung und begleitenden Zeichnungen dienen dazu, Ausführungsformen der Erfindung zu veranschaulichen. Für die Zeichnungen gilt:
1 zeigt verschiedene Komponenten einer Technologieplattform;
2a zeigt eine Ausführungsform einer Anwendungssoftware, die mit Systemkernen aufgebaut ist;
2b zeigt eine Ausführungsform der Struktur eines Systemkerns;
3 zeigt eine Ausführungsform des Betriebs eines Systemkerns;
4 zeigt eine Ausführungsform einer Grafikprozessor-Hardwarearchitektur;
5a, 5b, 5c, 5d und 5e zeigen das Parsen von Bilddaten in eine Zeilengruppe, das Parsen einer Zeilengruppe in ein Datenblatt und die an einem Datenblatt mit überlappenden Schablonen durchgeführte Operation;
6 zeigt eine Ausführungsform eines Schablonenprozessors;
7 zeigt eine Ausführungsform der Konfiguration und Programmierung eines Grafikprozessors
8 zeigt ein aus Zeilengruppen bestehendes Frame;
9a, 9b und 9c zeigen Konstruktions- und Ausführungsformen einer Zeilenpuffereinheit;
9d und 9e zeigen Ausführungsformen eines programmierbaren Registerbereichs eines Grafikprozessors;
10a und 10b zeigen eine virtuell schlanke Betriebsart;
11a und 11b zeigen Ausführungsformen der Makro-E/A-Einheiten;
12a und 12b zeigen eine erste Fähigkeit einer Ausführungsform einer Makro-E/A-Einheit;
13 zeigt eine zweite Fähigkeit einer Ausführungsform einer Makro-E/A-Einheit;
14 zeigt eine Methodik, die mithilfe einer Ausführungsform einer Makro-E/A-Einheit durchgeführt wird;
15 zeigt eine Ausführungsform eines Rechensystems.
Ausführliche Beschreibung
i. Einführung
Die nachfolgende Beschreibung beschreibt zahlreiche Ausführungsformen, die eine neue Bildverarbeitungstechnologieplattform betreffen, welche eine vielseitig einsetzbare Anwendungssoftware-Entwicklungsumgebung bereitstellt, die größere Datenblöcke (z. B. Zeilengruppen und Arbeitsblätter, wie weiter unten beschrieben) verwendet, um für eine verbesserte Energieeffizienz zu sorgen.
1.0 Anwendungssoftware-Entwicklungsumgebung
a. Anwendung und Struktur der Kernsysteme
1 zeigt eine umfassende Ansicht einer Grafikprozessortechnologieplattform, die eine virtuelle Bildverarbeitungsumgebung 101, die eigentliche Bildverarbeitungshardware 103 und einen Compiler 102 beinhaltet, um einen übergeordneten für die virtuelle Verarbeitungsumgebung 101 geschriebenen Code in Objektcode übersetzt, welcher von der eigentlichen Hardware 103 physisch ausgeführt wird. Wie nachfolgend näher beschrieben wird, ist die virtuelle Verarbeitungsumgebung 101 in Bezug auf die Anwendungen, die entwickelt werden können, vielseitig und für eine einfache Visualisierung der Prozesse einer Anwendung zugeschnitten. Nach Beendigung des Programmcode-Entwicklungsaufwands durch den Entwickler 104 übersetzt der Compiler 102 den Code, der in die virtuelle Verarbeitungsumgebung 101 geschrieben wurde, in einen Objektcode, der für die eigentliche Hardware 103 ausgerichtet ist.
2a zeigt eine exemplarische Ausführungsform der Struktur und Form, welche die Anwendungssoftware, die in die virtuelle Umgebung geschrieben wird, annehmen kann. Wie in 2a dargestellt, kann erwartet werden, dass der Programmcode ein oder mehrere Frames der Eingangsbilddaten 201 verarbeitet, um eine Gesamttransformation an den Eingangsbilddaten 201 zu bewirken. Die Transformation wird mit dem Betrieb eines oder mehrerer Kernsysteme des Programmcodes 202 realisiert, die an den Eingangsbilddaten in einer abgestimmten Sequenz arbeiten, welche von dem Entwickler gebildet wird.
Wie in 2a erkennbar, wird die Gesamttransformation durch eine erste Verarbeitung der jeweiligen Eingangsbilder mit einem ersten Kernsystem K1 beeinflusst. An den vom Kernsystem K1 erzeugten Ausgabebildern arbeitet dann das Kernsystem K2. An jedem der vom Kernsystem K2 erzeugten Ausgabebilder arbeitet dann das Kernsystem K3_1 oder K3_2 gearbeitet. An den vom bzw. von den Kernsystem(en) K3_1/K3_2 erzeugten Ausgabebildern arbeitet dann das Kernsystem K4. Die Kernsysteme K3_1 und K3_2 können identische Kernsysteme sein, die so beschaffen sind, dass sie die Gesamtverarbeitung beschleunigen, indem sie eine Parallelverarbeitung in der K3-Stufe auferlegen, oder können unterschiedliche Kernsysteme sein (z. B. wird das Kernsystem K3_1 auf Eingabebildern eines ersten spezifischen Typs und das Kernsystem K3_2 auf Eingabebildern eines zweiten, unterschiedlichen Typs betrieben).
Daher kann die größere Gesamtbildverarbeitungssequenz die Form einer Bildverarbeitungspipeline oder eines gerichteten azyklischen Graphen (DAG) annehmen und die Entwicklungsumgebung kann dafür ausgestattet sein, dem Entwickler eine tatsächliche Darstellung des entwickelten Programmcodes anzuzeigen. Kernsysteme können von einem Entwickler einzeln entwickelt und/oder von einer Einheit, die eine darunterliegende Technologie (wie z. B. die eigentliche Signalprozessor-Hardware und/oder eine Konstruktion derselben) und/oder durch einen Dritten (z. B. eine für die Entwicklungsumgebung geschriebene Kernsystem-Software) bereitgestellt werden. Dementsprechend wird davon ausgegangen, dass eine nominale Entwicklungsumgebung eine „Bibliothek“ von Kernsystemen einschließt, die von Entwicklern in verschiedenen Weisen „verbunden“ werden können, um den Gesamtablauf ihres größeren Entwicklungsaufwands herbeizuführen. Einige grundlegende Kernsysteme, von denen erwartet wird, dass sie Teil einer solchen Bibliothek sind, können Kernsysteme beinhalten, um eine oder mehrere der folgenden grundlegenden Bildverarbeitungsschritte bereitzustellen: Querwindungen, Entrauschung, Farbraumumwandlungen, Kanten- und Eckenerfassung, Schärfung, Weißabgleich, Gammakorrektur, Tonwertumsetzung, Matrix-Multiplikation, Bildregistrierung, Pyramidenbau, Wavelet-Transformation, blockweise diskrete Kosinus- und Fourier-Transformationen.
2b zeigt eine exemplarische Darstellung der Struktur eines Kernsystems 203, das von einem Entwickler in Betracht gezogen werden kann. Wie in 2b dargestellt, kann das Kernsystem 203 als eine Anzahl von parallelen Strängen von Programmcode („Threads“) 204 betrachtet werden, die jeweils auf einem entsprechenden zugrunde liegenden Prozessor 205 arbeiten, wobei jeder Prozessor 205 auf eine bestimmte Position in einem Ausgabefeld 206 (z. B. als eine bestimmte Bildpunktposition in dem von dem Kernsystem erzeugten Ausgabebild) ausgerichtet ist. Der Einfachheit halber sind in 2b nur drei Prozessoren und entsprechende Threads dargestellt. In verschiedenen Ausführungsformen weist jede dargestellte Ausgabefeldposition einen eigenen fest zugeordneten Prozessor und einen entsprechenden Thread auf. Das heißt, dass für jeden Bildpunkt im Ausgabefeld ein separater Prozessor und Thread zugewiesen werden kann.
Wie nachstehend näher beschrieben, arbeiten eine Matrix von Ausführungsbahnen und entsprechenden Threads in der tatsächlichen zugrunde liegenden Hardware in verschiedenen Ausführungsformen im Gleichklang (z. B. bei der Datenverarbeitung durch gleichzeitiges Anwenden eines einzigen Befehls auf mehrere Daten), um für einen Teil einer „Zeilengruppe“ des gerade verarbeiteten Frames Bildausgabedaten zu erzeugen. Eine Zeilengruppe ist ein zusammenhängender, beträchtlicher Abschnitt eines Frames. In verschiedenen Ausführungsformen kann sich der Entwickler im Klaren darüber sein, dass die Hardware auf Zeilengruppen arbeitet, oder die Entwicklungsumgebung eine Abstraktion darstellen kann, in der es einen separaten Prozessor und einen Thread für beispielsweise jeden Bildpunkt in dem Ausgabeframe (z. B. jeden durch einen eigenen fest zugeordneten Prozessor und Thread in einem Ausgabeframe erzeugten Bildpunkt) geben kann. Unabhängig davon versteht der Entwickler, dass das Kernsystem in verschiedenen Ausführungsformen einen einzelnen Thread für jeden Ausgabebildpunkt beinhaltet (unabhängig davon, ob das Ausgabefeld als vollständiger Ausgabeframe oder Abschnitt desselben visualisiert wird).
Wie nachfolgend näher beschrieben wird, weisen die Prozessoren 205, die dem Entwickler in der virtuellen Umgebung präsentiert werden, eine Befehlssatzarchitektur (ISA) auf, die nicht nur Standard-(z. B. RISC)Maschinenbefehle unterstützt, sondern auch speziell formatierte Datenzugriffsbefehle beinhaltet, die es dem Entwickler ermöglichen, die durchgeführte Bildpunktverarbeitung leicht zu visualisieren. Die Fähigkeit, eine beliebige Eingangsmatrixposition in Kombination mit einer vollständigen Befehlssatzarchitektur herkömmlicher mathematischer und programmgesteuerter Maschinenbefehle leicht zu definieren/zu visualisieren, ermöglicht eine extrem vielseitige Programmierumgebung, die es einem Anwendungsprogrammentwickler im Wesentlichen ermöglicht, im Idealfall jede gewünschte Funktion, die ausgeführt werden soll, auf einer beliebig großen Bildfläche zu definieren. Zum Beispiel kann im Idealfall jede mathematische Operation leicht programmiert und auf jede Schablonengröße angewendet werden.
Hinsichtlich der Datenzugriffsbefehle beinhaltet die Befehlssatzarchitektur der virtuellen Prozessoren („virtuelle ISA“) in einer Ausführungsform einen speziellen Datenladebefehl und einen speziellen Datenspeicherbefehl. Der Datenladebefehl ist in der Lage, jede Position innerhalb eines Eingangsfeldes von Bilddaten einzulesen. Der Datenspeicherbefehl kann an eine beliebige Stelle innerhalb des Ausgabefeldes von Bilddaten schreiben. Der letztgenannte Befehl ermöglicht es, mehrere Instanzen desselben Prozessors problemlos verschiedenen Ausgabebildpunktpositionen zuzuordnen (jeder Prozessor schreibt in einen anderen Bildpunkt in dem Ausgabefeld). Dementsprechend kann beispielsweise die Schablonengröße selbst (z. B. als Bildpunktbreite und Bildpunkthöhe ausgedrückt) zu einem leicht programmierbaren Merkmal gemacht werden. Die Visualisierung der Verarbeitungsvorgänge wird weiter vereinfacht, wobei jede der speziellen Lade- und Speicherbefehle ein spezielles Befehlsformat aufweist, wodurch Zielfeldpositionen vereinfacht als X- und Y-Koordinaten angegeben werden.
Unabhängig davon, können durch Instanziieren eines getrennten Prozessors für jede der Positionen in dem Ausgabefeld die Prozessoren ihre jeweiligen Threads parallel ausführen, so dass z. B. die jeweiligen Werte für alle Positionen in dem Ausgabefeld gleichzeitig erzeugt werden. Es ist zu beachten, dass viele Bildverarbeitungsroutinen in der Regel die gleichen Vorgänge an verschiedenen Bildpunkten des gleichen Ausgabebildes ausführen. Dementsprechend wird in einer Ausführungsform der Entwicklungsumgebung davon ausgegangen, dass jeder Prozessor identisch ist und denselben Thread-Programmcode ausführt. Somit kann die virtualisierte Umgebung als eine Art zweidimensionaler (2D) SIMD-Prozessor betrachtet werden, der aus einer 2D-Matrix von z. B. identischen Prozessoren besteht, die jeweils identischen Code im Sperrschritt ausführen.
3 zeigt eine ausführlichere exemplarische Ausführungsform der Verarbeitungsumgebung für zwei virtuelle Prozessoren, die identischen Code für zwei unterschiedliche Bildpunktpositionen in einem Ausgabefeld verarbeiten. 3 zeigt eine Ausgabematrix 304, die einem erzeugten Ausgabebild entspricht. Hier verarbeitet ein erster virtueller Prozessor den Code des Threads 301, um einen Ausgabewert an der Position X1 der Ausgabematrix 304 zu erzeugen, und ein zweiter virtueller Prozessor verarbeitet den Code des Threads 302, um einen Ausgabewert am Ort X2 der Ausgabematrix zu erzeugen 304. In verschiedenen Ausführungsformen würde der Entwickler wiederum verstehen, dass es einen separaten Prozessor und Thread für jede Bildpunktposition in der Ausgabematrix 304 gibt (der Einfachheit halber werden in 3 lediglich zwei derselben dargestellt). Jedoch muss der Entwickler (aufgrund der SIMD-ähnlichen Beschaffenheit der Maschine) in verschiedenen Ausführungsformen nur Code für einen Prozessor und einen Thread entwickeln.
Wie auf dem Fachgebiet bekannt ist, wird ein Ausgabebildpunktwert oft durch die Verarbeitung der Bildpunkte einer Eingangsmatrix bestimmt, die die entsprechende Ausgabebildpunktposition beinhaltet und umgibt. Beispielsweise entspricht, wie aus 3 ersichtlich, die Position X1 der Ausgabematrix 304 der Position E der Eingangsmatrix 303. Die Schablone der zu verarbeitenden Eingangsmatrix 303-Bildpunktwerte, um den Ausgabewert X1 zu bestimmen, würde daher den Eingangswerten ABCDEFGHI entsprechen. Ähnlich würde die Schablone der zu verarbeitenden Eingangsmatrixbildpunkte, um den Ausgabewert X2 zu bestimmen, den Eingangswerten DEFGHIJKL entsprechen.
3 zeigt eine exemplarische Ausführungsform eines entsprechenden virtuellen Umgebungsprogrammcodes für ein Thread-Paar 301, 302, das verwendet werden könnte, um die Ausgabewerte X1 bzw. X2 zu berechnen. In der exemplarischen Ausführungsform von 3 sind beide Code-Paare identisch und entsprechen durchschnittlich einer Schablone von neun Eingangsmatrixwerten, um einen entsprechenden Ausgabewert zu bestimmen. Der einzige Unterschied zwischen den beiden Threads sind die Variablen, die aus der Eingabematrix und der Position der zu beschreibenden Ausgabematrix aufgerufen werden. Insbesondere arbeitet der Thread, der die Ausgabeposition X1 schreibt, auf der Schablone ABCDEFGHI und der Thread, der die Ausgabeposition X2 schreibt, auf der Schablone DEFGHIJKL.
Wie aus dem jeweiligen Programmcode aus dem Thread-Paar 301, 302 ersichtlich, beinhaltet jeder virtuelle Prozessor zumindest die internen Register R1 und R2 und unterstützt zumindest folgende Befehle: 1) einen LADE-Befehl aus der Eingangsmatrix in R1; 2) einen LADE-Befehl aus dem Eingangsfeld in R2; 3) einen ADDIER-Befehl, der den Inhalt von R1 und R2 addiert und das Ergebnis in R2 einfügt; 4) einen DIVIDIER-Befehl, der den Wert innerhalb R2 durch den unmittelbaren Operanden 9 teilt; und, 5) ein SPEICHER-Befehl, der den Inhalt von R2 in die Ausgabematrixposition speichert, für die der Thread bestimmt ist. Obwohl in 3 nur zwei Ausgabematrixpositionen und nur zwei Threads und entsprechende Prozessoren dargestellt sind, könnte jeder Position in der Ausgabematrix durchaus ein virtueller Prozessor und ein entsprechender Thread zugewiesen werden, der diese Funktionen ausführt. In verschiedenen Ausführungsformen werden die Mehrfach-Threads im Einklang mit der SIMD-artigen Beschaffenheit der Verarbeitungsumgebung isoliert voneinander ausgeführt. Das heißt, es gibt keine Thread-Thread-Kommunikation zwischen virtuellen Prozessoren (ein SIMD-Kanal verhindert den Übergang in einen anderen SIMD-Kanal).
b. Virtuelles Prozessorspeichermodell
In verschiedenen Ausführungsformen ist ein wichtiges Merkmal der virtuellen Prozessoren ihr Speichermodell. Wie auf dem Fachgebiet bekannt ist, liest ein Prozessor Daten aus dem Speicher, arbeitet an diesen Daten und schreibt neue Daten in den Speicher zurück. Ein Speichermodell ist die Perspektive oder Ansicht, die ein Prozessor von der Art und Weise hat, in der die Daten im Speicher gegliedert sind. In einer Ausführungsform beinhaltet das Speichermodell der virtuellen Prozessoren sowohl Eingangs- als auch Ausgabematrixbereiche. Eingabebildpunktwerte für Threads werden in dem Eingangsmatrixbereich gespeichert, und Ausgabebildpunktwerte, die durch Threads erzeugt werden, werden in dem Ausgabematrixbereich gespeichert.
In einer Ausführungsform wird ein neuartiges Speicheradressierschema verwendet, um zu definieren, welche bestimmten Eingangswerte von einem Eingangsmatrixbereich des Speichermodells des virtuellen Prozessors aufgerufen werden sollen. Genauer gesagt, wird ein „positionsbezogenes“ Adressierungsschema verwendet, das die gewünschten Eingangsdaten anstatt einer herkömmlichen linearen Speicheradresse mit X-, Y-Koordinaten definiert. Dementsprechend beinhaltet der Ladebefehl der Befehlssatzarchitektur der virtuellen Prozessoren ein Befehlsformat, das eine spezifische Speicherposition innerhalb der Eingangsmatrix mit einer X-Komponente und einer Y-Komponente identifiziert. Daher wird ein zweidimensionales Koordinatensystem verwendet, um Speicher für Eingangswerte zu adressieren, die aus der Eingangsmatrix eingelesen werden.
Die Verwendung eines positionsbezogenen Speicheradressierungsansatzes ermöglicht es, dass der Bereich eines Bildes, an dem ein virtueller Prozessor arbeitet, für einen Entwickler leichter identifizierbar ist. Wie oben erwähnt, ermöglicht die Fähigkeit, eine beliebige Eingangsmatrixposition in Kombination mit einer gesamten Befehlssatzarchitektur von herkömmlichen mathematischen und programmgesteuerten Maschinenbefehlen leicht zu definieren/sichtbar zu machen, eine extrem vielseitige Programmierumgebung, die es im Wesentlichen ermöglicht, dass ein Anwendungsprogrammentwickler im Idealfall beliebig jede gewünschte Funktion definieren kann, die auf einer beliebigen Größe der Bildfläche durchgeführt werden soll. Verschiedene Befehlsformat-Ausführungsformen für Befehle, die ein positionsbezogenes Adressierungsschema übernehmen, sowie Ausführungsformen anderer Merkmale der unterstützten Befehlssatzarchitektur werden nachfolgend näher beschrieben.
Die Ausgabematrix enthält die Ausgabebilddaten, für deren Generierung die Threads verantwortlich sind. Die ausgegebenen Bilddaten können endgültige Bilddaten, wie z. B. die tatsächlichen Bilddaten, sein, die auf einem Display dargestellt werden, das der Gesamtbildverarbeitungssequenz folgt, oder es können Zwischenbilddaten sein, die ein nachfolgendes Kernsystem der Gesamtbildverarbeitungssequenz als Eingangsbilddateninformationen verwendet. Virtuelle Prozessoren konkurrieren in der Regel jedoch nicht für dieselben Ausgabedatenelemente, da sie während desselben Zyklus auf verschiedene Bildpunktpositionen der ausgegebenen Bilddaten schreiben.
In einer Ausführungsform wird das positionsbezogene Adressierungsschema auch für Schreibvorgänge in die Ausgabematrix verwendet. Dementsprechend beinhaltet die Befehlssatzarchitektur für jeden virtuellen Prozessor einen Speicherbefehl, dessen Befehlsformat anstelle einer herkömmlichen Speicherung mit wahlfreiem Zugriff eine zielgerichtete Schreibposition im Speicher als eine zweidimensionale XY-Koordinate definiert.
2.0 Hardwarearchitektur-Ausführungsformen
a. Grafikprozessor-Hardware-Architektur und -Betrieb
4 zeigt eine Ausführungsform einer Architektur 400 für einen in der Hardware implementierten Grafikprozessor. Der Grafikprozessor kann z. B. von einem Compiler angesteuert werden, der den Programmcode, der für einen virtuellen Prozessor geschrieben wurde, in einer simulierten Umgebung in Programmcode umwandelt, der von dem Hardwareprozessor tatsächlich ausgeführt wird. Wie in 4 dargestellt, beinhaltet die Architektur 400 eine Vielzahl von Zeilenpuffereinheiten 401_1 bis 401_M, die mit einer Vielzahl von Schablonenprozessoreinheiten 402_1 bis 402_N und entsprechenden Datenblattgeneratoreinheiten 403_1 bis 403_N über ein Netzwerk 404 (z. B. ein Netzwerk auf Chip (NOC), unter anderem auch ein Chip-Switch-Netzwerk, ein On-Chip-Ring-Netzwerk oder einer anderen Art von Netzwerk) verbunden ist. In einer Ausführungsform kann eine Zeilenpuffereinheit mit einem Datenblattgenerator und einem entsprechenden Schablonenprozessor über das Netzwerk 404 verbunden sein.
In einer Ausführungsform wird der Programmcode kompiliert und auf einen entsprechenden Schablonenprozessor 402 geladen, um die zuvor von einem Softwareentwickler definierten Bildverarbeitungsvorgänge auszuführen (der Programmcode kann je nach Konzipierung und Implementierung auch auf den zugehörigen Datenblattgenerator des Schablonenprozessors geladen werden 403). In zumindest einigen Fällen kann eine Bildverarbeitungsleitung realisiert werden, indem ein erstes Kernprogramm für eine erste Pipelinephase in einen ersten Schablonenprozessor 402_1 geladen, ein zweites Kernprogramm für eine zweite Pipelinephase in einen zweiten Schablonenprozessor 402_2, usw. geladen wird, wobei das erste Kernsystem die Funktionen der ersten Leitungsphase durchführt, das zweite Kernsystem die Funktionen der zweiten Pipelinephase usw. ausführt, und zusätzliche Steuerflussverfahren installiert werden, um Ausgabebilddaten von einer Pipelinephase zu der nächsten Leitungsphase zu leiten.
In anderen Konfigurationen kann der Grafikprozessor als eine parallele Maschine realisiert sein, die zwei oder mehr Schablonenprozessoren 402_1, 402_2 aufweist, die auf demselben Kernsystemprogrammcode betrieben werden. Zum Beispiel kann ein hochgradig dichter und hoher Datenratenstrom von Bilddaten verarbeitet werden, indem Frames über mehrere Schablonenprozessoren verteilt werden, von denen jeder dieselbe Funktion ausführt.
In noch anderen Konfigurationen kann im Wesentlichen jeder DAG von Kernsystemen auf den Hardwareprozessor geladen werden, indem jeweilige Schablonenprozessoren mit deren eigenen jeweiligen Kernsystemprogrammcodes konfiguriert und geeignete Ablaufsteuerungs-Hooks in die Hardware konfiguriert werden, um Ausgabebilder von einem Kernsystem an den Eingang eines nächsten Kernsystems in der DAG-Konstruktion zu leiten.
Bei einem allgemeinen Ablauf werden die Frames der Bilddaten von einer Makro-E/A-Einheit 405 empfangen und zu einer oder mehreren der Zeilenpuffereinheiten 401 auf einer Frame-per-Frame-Basis weitergeleitet. Eine bestimmte Zeilenpuffereinheit parst ihren Frame aus Bilddaten in einen kleineren Bereich von Bilddaten, der als „Zeilengruppe“ bezeichnet wird, und führt dann die Zeilengruppe durch das Netzwerk 404 zu einem bestimmten Datenblattgenerator. Eine vollständige oder „volle“ singuläre Zeilengruppe kann sich beispielsweise aus den Daten mehrerer zusammenhängender vollständiger Zeilen oder Spalten eines Frames zusammensetzen (der Einfachheit halber bezieht sich die vorliegende Beschreibung hauptsächlich auf zusammenhängende Zeilen). Der Datenblattgenerator parst des Weiteren die Zeilengruppe von Bilddaten in einen kleineren Bereich von Bilddaten, der als „Datenblatt“ bezeichnet wird, und präsentiert das Datenblatt seinem entsprechenden Schablonenprozessor.
Im Falle einer Bildverarbeitungspipeline oder eines DAG-Ablaufs mit einem einzigen Eingang werden im Allgemeinen Eingangsframes an die gleiche Zeilenpuffereinheit 401_1 geleitet, die die Bilddaten in Zeilengruppen parst und die Zeilengruppen zu dem Datenblattgenerator leitet 403_1, dessen entsprechender Schablonenprozessor 402_1 den Code des ersten Kernsystems in der Leitung/dem DAG ausführt. Nach Beendigung der Vorgänge an den durch den Schablonenprozessor 402_1 verarbeiteten Zeilengruppen sendet der Datenblattgenerator 403_1 Ausgabezeilengruppen an eine „nachgeschaltete“ Zeilenpuffereinheit 401_2 (in manchen Anwendungsfällen kann die Ausgabezeilengruppe zurück an die gleiche Zeilenpuffereinheit 401_1 gesendet werden, die zuvor die Eingabezeilengruppen gesendet hatte).
Ein oder mehrere „Abnehmerkernsysteme“, die die nächste Phase/den nächsten Vorgang in der Leitung/dem DAG darstellen, die auf deren eigenen anderen Datenblattgenerator und Schablonenprozessor (z. B. Datenblattgenerator 403_2 und Schablonenprozessor 402_2) ausführt werden, empfangen anschließend die von dem ersten Schablonenprozessor 402_1 erzeugten Bilddaten von der nachgelagerten Zeilenpuffereinheit 401_2. Auf diese Weise werden die Ausgabedaten eines „Erzeugerkernsystems“, das auf einem ersten Schablonenprozessor betrieben wird, an ein „Abnehmerkernsystem“ weitergeleitet, das auf einem zweiten Schablonenprozessor betrieben wird, wobei das Abnehmerkernsystem nach dem Erzeugerkernsystem den nächsten Satz von Arbeitsschritten gemäß der Konzipierung der gesamten Pipeline oder des DAGs ausführt.
Ein Schablonenprozessor 402 ist dafür ausgelegt, gleichzeitig an mehreren überlappenden Schablonen von Bilddaten zu arbeiten. Die mehreren überlappenden Schablonen und die interne Hardwareverarbeitungskapazität des Schablonenprozessors bestimmen effektiv die Größe eines Datenblattes. Hier arbeiten innerhalb eines Schablonenprozessors 402 Matrizen von Ausführungsbahnen zusammen, um gleichzeitig den Bilddatenoberflächenbereich zu bearbeiten, der von den mehreren überlappenden Schablonen bedeckt ist.
Wie nachstehend näher beschrieben, werden in verschiedenen Ausführungsformen, Datenblätter von Bilddaten in eine zweidimensionale Registermatrixstruktur innerhalb des Schablonenprozessors 402 geladen. Es wird davon ausgegangen, dass die Verwendung von Datenblättern und die zweidimensionale Registermatrixstruktur für effektive Energieverbrauchsverbesserungen sorgen, indem eine große Datenmenge in einen großen Registerbereich verschoben wird, so wird beispielsweise eine einzelne Ladeoperation mit direkt an den Daten ausgeführten Verarbeitungsschritten unmittelbar danach durch eine Ausführungsbahnmatrix verschoben. Zudem stellt die Verwendung einer Ausführungsbahnmatrix und einer entsprechenden Registermatrix verschiedene Schablonengrößen bereit, die leicht programmierbar/konfigurierbar sind.
5a bis 5e veranschaulichen umfassend Ausführungsformen sowohl der Parsing-Aktivität einer Zeilenpuffereinheit 401 als auch der feineren Parsing-Aktivität einer Datenblattgeneratoreinheit 403, sowie der Schablonenverarbeitungsaktivität des Schablonenprozessors 402, der mit der Datenblatt-Erzeugereinheit 403 gekoppelt ist.
5a zeigt eine Ausführungsform eines Eingabeframes der Bilddaten 501. 5a zeigt zudem einen Umriss drei überlappender Schablonen 502 (die jeweils eine Dimension von 3 Pixeln × 3 Pixeln aufweisen), die ein Schablonenprozessor ausgelegt ist, zu bedienen. Der Ausgabebildpunkt, für den jede Schablone die jeweiligen Ausgabebilddaten erzeugt, wird in schwarzer Farbe hervorgehoben. Der Einfachheit halber sind die drei überlappenden Schablonen 502 nur in vertikaler Richtung überlappend dargestellt. Es ist relevant, zu erkennen, dass ein Schablonenprozessor in Wirklichkeit so ausgestaltet sein kann, dass dieser sowohl in vertikaler als auch in horizontaler Richtung überlappende Schablonen aufweist.
Aufgrund der vertikalen überlappenden Schablonen 502 innerhalb des Schablonenprozessors, wie in 5a dargestellt, gibt es ein breites Band von Bilddaten innerhalb des Frames, das ein einzelner Schablonenprozessor bedienen kann. Wie nachfolgend näher beschrieben, verarbeiten die Schablonenprozessoren innerhalb ihrer überlappenden Schablonen Daten von links nach rechts quer durch die Bilddaten (und wiederholen den Vorgang dann für die nächste Gruppe von Zeilen in der Reihenfolge von oben nach unten). Somit wird, da die Schablonenprozessoren mit ihrem Betrieb fortfahren, die Anzahl der schwarzen Ausgabebildpunktblöcke horizontal nach rechts zunehmen. Wie oben erwähnt, ist eine Zeilenpuffereinheit 401 für das Parsen einer Zeilengruppe von Eingangsbilddaten aus einem eingehenden Frame verantwortlich, der für die Schablonenprozessoren ausreichend ist, um eine erweiterte Anzahl anstehender Zyklen zu bedienen. Eine exemplarische Darstellung einer Zeilengruppe ist als schattierter Bereich 503 dargestellt. In einer weiter unten beschriebenen Ausführungsform kann die Zeilenpuffereinheit 401 unterschiedliche Dynamiken zum Senden/Empfangen einer Zeilengruppe an einen/von einem Datenblattgenerator umfassen. Beispielsweise werden gemäß einem Modus, der als „vollständige Gruppe“ bezeichnet wird, die gesamten Bilddatenzeilen mit voller Breite zwischen einer Zeilenpuffereinheit und einem Datenblattgenerator übermittelt. Gemäß einem zweiten Modus, der als „virtuell schlank“ bezeichnet wird, wird eine Zeilengruppe zunächst mit einer Untermenge von Zeilen mit voller Breite übermittelt. Die verbleibenden Zeilen werden dann nacheinander in kleineren Stücken (mit weniger als voller Breite) übermittelt.
Wenn die Zeilengruppe 503 der Eingabebilddaten durch die Zeilenpuffereinheit definiert und an die Datenblattgeneratoreinheit übermittelt worden ist, parst die Datenblattgeneratoreinheit die Zeilengruppe weiter in feinere Datenblätter, die an die Hardwarebeschränkungen des Schablonenprozessors präziser angepasst sind. Insbesondere wird in einer Ausführungsform, wie nachfolgend näher beschrieben, jeder Schablonenprozessor aus einer zweidimensionalen Schieberegistermatrix gebildet. Die zweidimensionale Schieberegistermatrix verschiebt im wesentlichen Bilddaten „unterhalb“ einer Matrix von Ausführungsbahnen, wobei das Muster der Verschiebung bewirkt, dass jede Ausführungsbahn an Daten innerhalb ihrer eigenen Schablone arbeitet (d. h. jede Ausführungsbahn ihre eigene Schablone von Informationen verarbeitet, um eine Ausgabe für diese Schablone zu erzeugen). In einer Ausführungsform sind Datenblätter Oberflächenbereiche von Eingabebilddaten, die die zweidimensionale Schieberegistermatrix „ausfüllen“ oder anderweitig in dieselbe geladen werden.
Wie in 5b dargestellt, parst der Datenblattgenerator ein Anfangsblatt 504 von der Zeilengruppe 503 und stellt es dem Schablonenprozessor zur Verfügung (hier entspricht das Datenblatt dem schattierten Bereich, der im Allgemeinen mit dem Bezugszeichen 504 gekennzeichnet ist). Wie in den 5c und 5d dargestellt, arbeitet der Schablonenprozessor an dem Datenblatt der eingegebenen Bilddaten durch effektives Bewegen der überlappenden Schablonen 502 von links nach rechts über dem Datenblatt. Wie in 5d ist die Anzahl der Bildpunkte, für die ein Ausgabewert aus den Daten innerhalb des Datenblattes berechnet werden könnte, erschöpft (keine anderen Bildpunktpositionen können einen Ausgabewert haben, der aus den Informationen innerhalb des Datenblattes bestimmt wird). Zur Vereinfachung wurden die Randbereiche des Bildes ignoriert.
Wie in 5e dargestellt, liefert der Datenblattgenerator dann ein nächstes Datenblatt 505 für den Schablonenprozessor, um die Vorgänge fortzusetzen. Zu beachten ist, dass die Anfangspositionen der Schablonen, wenn sie mit der Bearbeitung an dem nächsten Datenblatt beginnen, der nächsten Progression (wie zuvor in 5d dargestellt) vom Erschöpfungspunkt nach rechts auf dem ersten Datenblatt entsprechen. Mit dem neuen Datenblatt 505 bewegen sich die Schablonen einfach weiter nach rechts, sofern der Schablonenprozessor auf dem neuen Datenblatt auf die gleiche Weise arbeitet wie bei der Verarbeitung des ersten Datenblattes.
Zu beachten ist, dass zwischen den Daten des ersten Datenblattes 504 und den Daten des zweiten Datenblattes 505 aufgrund der Randbereiche der Schablonen, die eine Ausgabebildpunktposition umgeben, eine gewisse Überlappung vorliegt. Die Überlappung könnte einfach gehandhabt werden, indem der Datenblattgenerator die überlappenden Daten zweimal überträgt. In alternativen Implementierungen kann, um dem Schablonenprozessor ein nächstes Datenblatt zuzuführen, der Datenblattgenerator damit fortfahren, ausschließlich neue Daten an den Schablonenprozessor zu senden, während der Schablonenprozessor die überlappenden Daten aus dem vorhergehenden Datenblatt verwendet.
b. Schablonenprozessorarchitektur und -betrieb
6 zeigt eine Ausführungsform einer Schablonenprozessorarchitektur 600. Wie in 6 dargestellt, beinhaltet der Schablonenprozessor eine Datenberechnungseinheit 601, einen Skalarprozessor 602 und einen zugehörigen Speicher 603, sowie eine E-/A-Einheit 604. Die Datenberechnungseinheit 601 beinhaltet eine Matrix von Ausführungsbahnen 605, eine zweidimensionale Verschiebungsfeldstruktur 606 und getrennte Speicher mit wahlfreiem Zugriff 607, die mit bestimmten Zeilen oder Spalten der Matrix assoziiert sind.
Die E-/A-Einheit 604 ist verantwortlich für das Einladen der „eingegebenen“ Datenblätter, die von dem Datenblattgenerator empfangen werden, in die Datenberechnungseinheit 601, sowie das Speichern der von dem Schablonenprozessor in den Datenblattgenerator „ausgegebenen“ Datenblätter. In einer Ausführungsform beinhaltet das Einladen von Blattdaten in die Datenberechnungseinheit 601 das Parsen eines empfangenen Datenblattes in die Zeilen/Spalten der Bilddaten, sowie das Einladen der Zeilen/Spalten der Bilddaten in die zweidimensionale Schieberegisterstruktur 606 oder in die jeweiligen Speicher mit wahlfreiem Zugriff 607 der Zeilen/Spalten der Ausführungsbahnmatrix (wie nachfolgend näher beschrieben). Wird das Datenblatt anfänglich in die Speicher 607 geladen, können die einzelnen Ausführungsbahnen innerhalb der Ausführungsbahnmatrix 605 dann die Blattdaten, sofern geeignet (z. B. als Ladebefehl kurz vor der Bearbeitung der Blattdaten) in die zweidimensionale Schieberegisterstruktur 606 der Speicher mit wahlfreiem Zugriff 607 einladen. Nach Beendigung des Einladens eines Datenblattes in die Registerstruktur 606 (ob direkt aus einem Datenblattgenerator oder aus den Speichern 607) arbeiten die Ausführungsbahnen der Ausführungsbahnmatrix 605 an den Daten und schreiben letztendlich die fertigen Daten als ein Blatt direkt „zurück“ in den Datenblattgenerator oder in die Speicher mit wahlfreiem Zugriff 607. Im letzteren Fall ruft die E/A-Einheit 604 die Daten aus den Speichern mit wahlfreiem Zugriff 607 ab, um ein Ausgabeblatt zu bilden, das dann an den Datenblattgenerator weitergeleitet wird.
Der Skalarprozessor 602 beinhaltet einen Programmcontroller 609, der die Befehle des Programmcodes des Schablonenprozessors aus dem Skalarspeicher 603 liest und die Befehle an die Ausführungsbahnen in der Ausführungsbahnmatrix 605 ausgibt. In einer Ausführungsform wird ein einzelner Befehl auf alle Ausführungsbahnen innerhalb der Matrix 605 übertragen, um ein SIMD-ähnliches Verhalten der Datenberechnungseinheit 601 zu bewirken. In einer Ausführungsform, beinhaltet das Befehlsformat der Anweisungen, die aus dem Skalarspeicher 603 gelesen und an die Ausführungsbahnen der Ausführungsbahnmatrix 605 ausgegeben werden, ein sehr langes Befehlswortformat (VLIW), welches mehr als einen Maschinenbefehl pro Anweisung beinhaltet. In einer weiteren Ausführungsform beinhaltet das VLIW-Format sowohl einen ALU-Maschinenbefehl, der eine mathematische Funktion ausführt, die von der ALU einer Ausführungsbahn ausgeführt wird (wie nachstehend beschrieben, kann in einer Ausführungsform mehr als ein herkömmlicher ALU-Vorgang angegeben sein) als auch einen Speichermaschinenbefehl (der einen Speichervorgang für eine spezifische Ausführungsbahn oder eine Gruppe von Ausführungsbahnen steuert).
Der Begriff „Ausführungsbahn“ bezieht sich auf eine Gruppe von einer oder mehreren Ausführungseinheiten, die einen Befehl ausführen können (z. B. eine Logikschaltung, die einen Befehl ausführen kann). Eine Ausführungsbahn kann in verschiedenen Ausführungsformen jedoch mehr Prozessor-ähnliche Funktionalität als nur Ausführungseinheiten beinhalten. Beispielsweise kann eine Ausführungsbahn neben einer oder mehreren Ausführungseinheiten auch Logikschaltungen beinhalten, die einen empfangenen Befehl dekodieren, oder für den Fall MIMD-ähnlicherer Architekturen eine Logikschaltung, die einen Befehl abruft und dekodiert. In Bezug auf MIMD-ähnliche Ansätze kann, obwohl ein zentraler Programmsteuerungsansatz hier weitgehend beschrieben wurde, auch ein verteilterer Ansatz in verschiedenen alternativen Ausführungsformen (z. B. unter anderem auch Programmcode und ein Programmcontroller innerhalb jeder Ausführungsbahn der Matrix 605) implementiert werden.
Die Kombination einer Ausführungsbahnmatrix 605, eines Programmcontrollers 609 und einer zweidimensionalen Schieberegisterstruktur 606 stellt eine weitgehend anpassbare/konfigurierbare Hardware-Plattform für ein breites Spektrum programmierbarer Funktionen bereit. Beispielsweise können Anwendungssoftwareentwickler in der Lage sein, Kernsysteme mit einem breiten Spektrum unterschiedlicher Funktionsfähigkeiten sowie Dimensionen (z. B. Schablonengrößen) zu programmieren, da die einzelnen Ausführungsbahnen in der Lage sind, eine breite Palette von Funktionen auszuführen und ohne Weiteres auf Eingabebilddaten in der Nähe einer beliebigen Ausgabefeldposition zuzugreifen.
Abgesehen davon, dass dieselben als Datenspeicher für Bilddaten genutzt werden, die durch die Ausführungsbahnmatrix 605 bedient werden, können die Speicher mit wahlfreiem Zugriff 607 zudem eine oder mehrere Nachschlagetabellen beibehalten. In verschiedenen Ausführungsformen können eine oder mehrere skalare Nachschlagetabellen auch innerhalb des skalaren Speichers 603 instanziiert werden.
Ein skalarer Suchvorgang beinhaltet das Übermitteln desselben Datenwerts aus der gleichen Nachschlagtabelle von demselben Index an sämtliche Ausführungsbahnen innerhalb der Ausführungsbahnmatrix 605. In verschiedenen Ausführungsformen wird das oben beschriebene VLIW-Befehlsformat erweitert, um auch einen skalaren Maschinenbefehl einzuschließen, der eine vom Skalarprozessor ausgeführte Nachschlageoperation in eine skalare Nachschlagetabelle leitet. Der für die Verwendung mit dem Maschinenbefehl angegebene Index kann ein unmittelbarer Operand sein oder von einem anderen Datenspeicherort abgerufen werden. Unabhängig davon umfasst in einer Ausführungsform ein Suchvorgang in einer skalaren Nachschlagetabelle innerhalb des skalaren Speichers im Wesentlichen das Senden des gleichen Datenwertes an alle Ausführungsbahnen innerhalb der Ausführungsbahnmatrix 605 während a des gleichen Taktzyklus.
3.0 Zeilenpuffereinheit-Ausführungsformen
a. Zeilenpuffereinheit-Übersicht
Aus der obigen Beschreibung in Abschnitt 1.0 wird entnommen, dass in verschiedenen Ausführungsformen der für die Hardwareplattform geschriebene Programmcode unter Verwendung eines einzigartigen virtuellen Codes geschrieben wird, der einen Befehlssatz mit Lade- und Speicherbefehlen beinhaltet, deren Befehlsformat die Eingabe- und Ausgabefeldpositionen z. B. als X-, Y-Koordinaten kennzeichnet. In verschiedenen Implementierungen können die X-, Y-Koordinateninformationen tatsächlich in die Hardwareplattform programmiert werden und von verschiedenen ihrer Komponenten erkannt/verstanden werden. Dies unterscheidet sich beispielsweise von der Übersetzung der X-, Y-Koordination (z. B. innerhalb des Compilers) in unterschiedliche Informationen. Im Fall der zweidimensionalen Schieberegisterstruktur innerhalb des Schablonenprozessors werden die X-, Y-Koordinateninformationen beispielsweise in Registerverschiebungsbewegungen übersetzt. Im Gegensatz dazu können andere Teile der Hardwareplattform die ursprünglich auf der höheren virtuellen Codeebene ausgedrückten X-, Y-Koordinateninformationen empfangen und verstehen.
Wie in 7 dargestellt und in Abschnitt 1.0 beschrieben, drückt ein Programmcode-Entwickler Datenpositionen als X-, Y-Koordinaten mit dem speziellen Befehlsformat auf der virtuellen Codeebene 710 aus. Während der Kompilierungsphase wird der virtuelle Code in Programmcode übersetzt, der genau genommen durch die Hardware (den Objektcode) und entsprechende Konfigurationsinformationen, die in den Hardwarekonfigurationsbereich (z. B. Registerregister) geladen werden, verarbeitet wird. Wie in 7 dargestellt, wird in einer Ausführungsform der Objektcode für ein bestimmtes Kernsystem in den Programmbereich des Skalarprozessors 705 des Schablonenprozessors geladen.
Im Rahmen des Konfigurationsprozesses lädt die auf dem Skalarprozessor 705 ausgeführte Konfigurationssoftware die entsprechenden Konfigurationsinformationen 711, 712 sowohl in die an den Schablonenprozessor 702 gekoppelte Datenblattgeneratoreinheit 703, als auch an die Zeilenpuffereinheit 701, die neue Datenblätter für den Schablonenprozessor 702 erzeugt, um an den von dem Schablonenprozessor 702 erzeugten Datenblättern zu arbeiten oder diese zu empfangen. Im Allgemeinen können die hierin genannten Datenblätter in Form von X-, Y-Koordinaten eines Gesamtbildes betrachtet werden. Das heißt, sobald ein Bild oder Frame (z. B. in Form einer Anzahl von Bildpunkten pro Zeile, Anzahl von Zeilen, Anzahl von Bildpunkten pro Spalte und Anzahl von Spalten) definiert ist, kann auf jeden Abschnitt bzw. jede Position des Bildes weiterhin mit X, Y-Koordinaten verwiesen werden.
Dementsprechend sind in verschiedenen Ausführungsformen entweder die Datenblattgeneratoreinheit 703 oder die Zeilenpuffereinheit 701 mit Informationen 711, 712 in ihrem jeweiligen Konfigurationsbereich 706, 707 konfiguriert, die eine Informationsplattform bilden, von der aus bestimmte Positionen und/oder Bereiche (z. B. Zeilengruppen, Datenblätter) eines Bildes oder Frames mit X-, Y-Koordinaten identifiziert werden. In verschiedenen Implementierungen/Anwendungen können die X, Y-Koordinaten dieselben X, Y-Koordinaten sein, die auf der Ebene des virtuellen Codes ausgedrückt werden.
Zu Beispielen für derartige Informationen zählen z. B. die Anzahl aktiver Zeilengruppen in der Zeilenpuffereinheit, die Bildgröße für jede Zeilengruppe (z. B. als eine Menge von vier X-, Y-Koordinaten (eine für jede Ecke) oder ein Paar von Zeilenpaaren X-, Y-Koordinaten (eine für eine untere näher gelegene Ecke und eine für eine obere weiter entfernte Ecke)), die absolute Bildbreite und Bildhöhe, die Schablonengröße (als X-, Y-Werte ausgedrückt, die die Größe einer einzelnen Schablone und/oder des Bereichs der überlappenden Schablonen des Schablonenprozessors definieren), die Datenblatt- und/oder Zeilengruppengröße (z. B. genauso angegeben wie eine Bildgröße, jedoch mit kleineren Abmessungen) usw. darüber hinaus kann zumindest die Zeilenpuffereinheit 701 mit zusätzlichen Konfigurationsinformationen, wie beispielsweise der Anzahl der Erzeugerkernsystem-Schreibvorgänge und der Anzahl der Abnehmerkernsysteme, die die von der Zeilenpuffereinheit 701 verwalteten Zeilengruppen einlesen, programmiert werden. Die Anzahl der Kanäle und/oder die den Bilddaten zugeordneten Abmessungen sind in der Regel auch als Konfigurationsinformationen enthalten.
8 zeigt die Verwendung von X-, Y-Koordinaten, um, nur um ein Beispiel anzuführen, Liniengruppen innerhalb eines Bildes zu definieren. Hierbei sind die N-Zeilengruppen 801_1, 801_2, ... 801_N innerhalb eines Bildes 801 erkennbar. Wie aus 8 ersichtlich, kann jede Zeilengruppe leicht durch Bezugnahme auf X-, Y-Koordinaten innerhalb des Bildes definiert werden, die z. B. einen oder mehrere Eckpunkte einer Zeilengruppe definieren. Somit kann in verschiedenen Ausführungsformen der Name einer Zeilengruppe oder eine andere Datenstruktur, die verwendet wird, um eine bestimmte Zeilengruppe zu definieren, X-, Y-Koordinatenpositionen beinhalten, die mit der Zeilengruppe verbunden sind, um speziell diese zu identifizieren.
Unter Bezugnahme auf 7 ist zu beachten, dass 7 zeigt, dass ein Datenblattgenerator 703 während der Laufzeit beispielsweise durch X-, Y-Koordinateninformationen, die den gewünschten Datenbereich definieren, von der Zeilenpuffereinheit 701 eine „nächste“ Zeilengruppe (oder einen Teil einer Zeilengruppe) anfordern kann. 8 zeigt nominelle Zeilengruppen „mit voller Breite“, die nur aus vollständigen Reihen von Bilddaten bestehen. In einer alternativen als „virtuell schlank“ bezeichneten Konfiguration, die weiter unten näher beschrieben wird, leitet die Zeilenpuffereinheit 701 anfänglich nur einen ersten oberen Abschnitt einer Zeilengruppe als Reihen mit voller Breite von Bilddaten durch. Die nachfolgenden unteren Reihen der Zeilengruppe werden dann vom Datenblattgenerator in zusammenhängenden Blöcken, die kleiner als eine Reihe mit voller Breite sind, speziell und gesondert angefordert. Daher werden Mehrfachanforderungen durch den Datenblattgenerator durchgeführt, um die vollständige Liniengruppe zu erhalten. Hier kann jede derartige Anforderung einen nächstniedrigeren Abschnitt durch X-, Y-Koordinaten definieren, die dem nächsten unteren Abschnitt zuzuordnen sind.
9a bis 9c zeigen verschiedene Merkmale einer Zeilenpuffereinheit-Ausführungsform 900. Wie in 9a dargestellt, beinhaltet eine Zeilenpuffereinheit einen Speicher 902, in dem Zeilengruppen 903_1 bis 903_N gespeichert sind (z. B. statischer oder dynamischer Direktzugriffsspeicher (SRAM oder DRAM)). 9a zeigt die Aktivität zwischen den verschiedenen Kernsystemen, die die Zeilengruppen 903_1 bis 903_N für ein bestimmtes Bild/einen bestimmten Frame innerhalb des Speichers 902 erzeugen und abnehmen.
Wie in 9a dargestellt, sendet ein Erzeugerkernsystem K1 über getrennte Zeitinstanzen P1, P2 bis PN neue Zeilengruppen an den Speicher 902. Das Erzeugerkernsystem K1 wird auf einem Schablonenprozessor ausgeführt, der neue Datenblätter erzeugt. Der Datenblattgenerator, der mit dem Schablonenprozessor gekoppelt ist, akkumuliert Datenblätter, um Zeilengruppen zu bilden, und leitet die Zeilengruppen an den Speicher 902 weiter.
Wie auch in 9a dargestellt, gibt es zwei Abnehmerkernsysteme K2, K3, die an den vom Abnehmerkernsystem K1 erzeugten Zeilengruppen 903_1 bis 903_N arbeiten. Hier empfangen die Abnehmerkernsysteme K2 und K3 die erste Zeilengruppe 903_1 zu den Zeitinstanzen C21 bzw. C31. Natürlich treten die Zeitinstanzen C21 und C31 nach der Zeitinstanz P1 auf. Andere Einschränkungen sind ggf. nicht vorhanden. Beispielsweise können C21 und/oder C31 vor oder nach einer der Zeitinstanzen P2 bis PN auftreten. Dabei fordern die jeweiligen Datenblattgeneratoren für die Kernsysteme K2 und K3 eine nächste Zeilengruppe zu einer Zeitinstanz an, die für deren jeweiliges Kernsystem geeignet ist. Wenn irgendeines der Kernsysteme K2, K3 die Zeilengruppe 903_1 vor der Zeitinstanz P1 anfordert, liegt die Anforderung im Leerlauf, bis die Zeilengruppe 903_1 tatsächlich in den Speicher 902 geschrieben ist. In vielen Implementierungen wird ein Erzeugerkernsystem auf einem anderen Schablonenprozessor betrieben als ein Abnehmerkernsystem.
Denkbar ist, dass Anforderungen von einem oder beiden der Kernsysteme K2 und K3 für alle Zeilengruppen 903_1 bis 903_N vor der Zeitinstanz P1 eintreffen können. Somit können von Abnehmerkernsystemen jederzeit Zeilengruppen angefordert werden. Die Zeilengruppen werden an die Abnehmerkernsysteme weitergeleitet, während diese von denselben angefordert werden, jedoch nur so schnell, wie das Erzeugerkernsystem K1 diese erzeugen kann. In verschiedenen Ausführungsformen erfordern Abnehmerkernsysteme Sequenzgruppen in Folge und empfangen diese ebenfalls in Folge (Kernsystem K2 empfängt Zeilengruppen 902_2 bis 902_N zu Zeitinstanzen C22 bis C2N in Folge). Der Einfachheit halber wird für eine spezielle Zeilengruppe nur ein Erzeugerkernsystem dargestellt. Es ist denkbar, dass verschiedene Ausführungsformen entworfen werden können, um es verschiedenen Erzeugern zu ermöglichen, auf eine gleiche Zeilengruppe zu schreiben (z. B. dann, wenn Erzeuger nicht gewartet werden dürfen, bis alle Erzeuger in die Zeilengruppe geschrieben haben).
In Fällen, in denen es kein Erzeugerkernsystem gibt (weil der oder die Abnehmerkernsysteme die ersten Kernsysteme im DAG-Prozessablauf des Prozessors sind), können die Frames der Bilddaten (beispielsweise über einen direkten Speicherzugriff (DMA) oder von einer Kamera) in den Speicher 902 übertragen und in Zeilengruppen geparst werden. In Fällen, in denen es kein(e) Abnehmerkernsystem(e) gibt (weil das Erzeugerkernsystem das letzte Kernsystem im gesamten Programmablauf des Prozessors ist), können resultierende Zeilengruppen kombiniert werden, um Ausgabeframes zu bilden.
9b zeigt eine detailliertere Ausführungsform einer gesamten Zeilenpuffereinheit 900. Zum Zwecke der Erklärung wird die Zeilenpuffereinheit 900 aus 9b mit der Aktivität aus 9a überlagert. Wie aus 9b ersichtlich, beinhaltet eine Zeilenpuffereinheit 900 einen Speicher 902, der mit der Zeilenpufferschaltkreiseinheit 901 gekoppelt ist. Die Zeilenpufferschaltkreiseinheit 901 kann beispielsweise mit einer speziell dafür vorgesehenen Logikschaltung ausgestattet sein. Innerhalb der Zeilenpufferschaltkreiseinheit 901 ist eine Zeilenpuffer-Schnittstelleneinheit 904_1 bis 904_N für jede Zeilengruppe 903_1 bis 903_N innerhalb des Speichers 902 reserviert. In verschiedenen Ausführungsformen gibt es eine feste Anzahl von Zeilenpuffer-Schnittstelleneinheiten 904_1 bis 904_N, die eine Obergrenze für die Anzahl von Zeilengruppen festlegt, die eine Zeilenpuffereinheit zu jeder Zeitinstanz verwalten kann (sind weniger als N Zeilengruppen aktiv, wird eine entsprechende kleinere Anzahl von Schnittstellen der Zeilenpuffereinheit aktiviert und zu einem beliebigen Zeitpunkt in Betrieb genommen).
Wie in 9b dargestellt, bearbeitet die Zeilenpuffereinheit 900 mit einer Gesamtanzahl von N Zeilenpuffer-Schnittstelleneinheiten 904 innerhalb der Zeilenpufferschaltkreiseinheit 901 eine maximale Anzahl von Zeilengruppen. Darüber hinaus kann bei einer größten zulässigen Zeilengruppengröße (bei der die Zeilengruppengröße ein konfigurierbarer Parameter ist) eine ungefähre Größe für den Speicher 902 bestimmt werden (um Hardware-Effizienz zu ermöglichen, kann natürlich ein kleinerer Speicherbedarf instanziiert werden, wobei N Zeilengruppen mit maximaler Größe nicht gleichzeitig zugelassen werden können).
Jede Zeilenpuffer-Schnittstelleneinheit 904_1 bis 904_N ist verantwortlich für die Verarbeitung der Erzeuger- und Abnehmeranforderungen für eine spezielle ihr zugewiesene Zeilengruppe. Beispielsweise verarbeitet die Zeilenpuffer-Schnittstelleneinheit 904_1 die Anfrage von dem Erzeuger K1 zu der Zeitinstanz P1, um die Zeilengruppe 903_1 zu speichern, und verarbeitet die Anforderungen von den Abnehmerkernsystemen K2 und K3 für die Zeilengruppe 903_1. In Reaktion auf den ersteren schreibt die Zeilenpuffer-Schnittstelleneinheit 904_1 die Zeilengruppe 903_1 in den Speicher 902. In Reaktion auf die letzteren führt die Zeilenpuffer-Schnittstelleneinheit 904_1 jeweilige Lesevorgänge der Zeilengruppe 903_1 aus dem Speicher 902 aus und leitet die Zeilengruppe 903_1 K3 jeweils zu den Zeitinstanzen C21 bzw. C31 an die Abnehmer K2 weiter.
Nachdem alle Abnehmer einer Zeilengruppe ihre Kopie der Zeilengruppe weitergeleitet haben, ist die Zeilenpuffer-Schnittstelleneinheit „frei“ und kann einer anderen Zeilengruppe zugeordnet werden. Wenn beispielsweise die Zeilengruppe 903_1 die erste Zeilengruppe innerhalb eines ersten Bildframes einer Folge von Frames darstellt, kann nach dem Weiterleiten der Zeilengruppe 903_1 an die Abnehmer K2 und K3 zu den Zeitinstanzen C21 und C31 die Zeilenpuffer-Schnittstelleneinheit 904_1 als nächstes zugeordnet werden, um die erste Zeilengruppe innerhalb des nächsten, zweiten Bildframes der Folge von Frames zu verarbeiten. Auf diese Weise kann die Zeilenpufferschaltkreiseinheit 901 als einen „Pool“ von Zeilenpuffer-Schnittstelleneinheiten 904 betrachtet werden, wobei jeder Schnittstelleneinheit eine neue Zeilengruppe zugewiesen wird, die zu verwalten ist, nachdem ihre unmittelbar vorangehende Zeilengruppe an ihren letzten Abnehmer geliefert wurde. Somit gibt es eine Rotation von Schnittstelleneinheiten, während diese wiederholt eintreffen und aus einem „freien Pool“ von Zeilenpuffer-Schnittstelleneinheiten, die ihren letzten Abnehmer bedient haben und auf ihre nächste Zeilengruppe warten, entfernt werden.
9c zeigt eine Ausführungsform der Rotation im Detail. Wie in 9c dargestellt, wird eine verfügbare Zeilenpuffer-Schnittstelleneinheit aus einem freien Pool von Zeilenpuffer-Schnittstelleneinheiten innerhalb der Zeilenpufferschaltkreiseinheit 910 ausgewählt. Die Zeilenpuffer-Schnittstelleneinheit wird dann mit geeigneten Konfigurationsinformationen 911 (z. B. X-, Y-Positionsdaten der neuen Zeilengruppe oder eines linearen Speicheradressenäquivalents) konfiguriert. Hier in 9b ist zu beachten, dass jede Zeilenpuffer-Schnittstelleneinheit einen Konfigurationsregisterbereich 905 aufweisen kann, in dem die besagten Konfigurationsinformationen aufbewahrt werden.
Die Zeilenpuffer-Schnittstelleneinheit fährt dann damit fort, Erzeuger- und Abnehmeranforderungen für ihre neu zugewiesene Zeilengruppe 912 zu verarbeiten. Nachdem der letzte Erzeuger in die Zeilengruppe geschrieben hat (in verschiedenen Ausführungsformen gibt es nur einen Erzeuger pro Zeilengruppe) und nachdem der letzte Abnehmer mit der Version der Zeilengruppe versehen wurde, die von ihrem bzw. ihren Erzeuger(n) geschrieben wurde, wird die Zeilenpuffer-Schnittstelleneinheit in den freien Pool zurückgeführt, und der Prozess 910 für eine nächste Zeilengruppe wiederholt. Die Steuerlogikschaltung innerhalb der Zeilenpufferschaltkreiseinheit 901, die den Steuerablauf von 9c überwacht, ist der Einfachheit halber in 9b nicht dargestellt.
b. programmierbare Registerbereichsausführungen
In Bezug auf die aktualisierte Konfigurationsinformationen 911, die im Rahmen der Zuweisung einer nächsten Zeilengruppe an einer Zeilenpuffer-Schnittstelleneinheit vorgesehen ist, verarbeitet die Zeilenpuffereinheit 900 selbst im Normalfall eine statische Anordnung von z. B. nur einem festen Erzeuger, der eine feste Gruppe von einem oder mehreren Abnehmern speist. In diesem Fall sind die primären Konfigurationsinformationen (z. B. die Zeilengruppengröße, die Anzahl der Abnehmer usw.) ebenfalls geeignet, statisch zu sein und werden sich von Zeilengruppe zu Zeilengruppe nicht ändern. Stattdessen identifizieren die an eine Zeilenpuffer-Schnittstelleneinheit gelieferten neuen Konfigurationsinformationen hauptsächlich die neue Zeilengruppe (z. B. die Position der Zeilengruppe im Speicher usw.). Kompliziertere potentielle Anordnungen/Entwürfe sind jedoch möglich. Einige davon werden nachfolgend näher beschrieben.
9d zeigt eine Ausführungsform des Inhalts des Registerbereichs einer Zeilenpuffer-Schnittstelleneinheit (z. B. des Inhalts des Registerbereichs 905_1 aus 9b). Eine Beschreibung einiger der Registerfelder folgt unmittelbar.
Das LB_Enable-Feld 921 aktiviert im Wesentlichen eine Zeilenpuffer-Schnittstelleneinheit und wird im Rahmen des Prozesses der Entnahme der Zeilenpuffer-Schnittstelleneinheit aus dem freien Pool „eingestellt“. Das Num_Channels-Feld 922 definiert die Anzahl der Kanäle innerhalb der Bilddaten der Zeilengruppe. In einer Ausführungsform kann das Num_Channels-Feld 922 verwendet werden, um die Gesamtmenge an Daten pro Zeilengruppe zu bestimmen. Beispielsweise beinhaltet ein Videostrom häufig eine Framesequenz aus roten (R) Bildpunkten, einer Framesequenz aus blauen (B) Bildpunkten und einer Framesequenz aus grünen (G) Bildpunkten. Somit gibt es für jede Zeilengruppe tatsächlich drei Zeilengruppen von Informationen (R, G und B).
Das Num_Consumers-Feld 923 beschreibt die Anzahl der Abnehmer, von denen die Zeilengruppe angefordert wird. In einer Ausführungsform wird die Zeilenpuffer-Schnittstelleneinheit in den freien Pool eingegeben, nachdem eine Zeilengruppeninstanz, die dem Wert in dem Num_Consumers-Feld 923 entspricht, einige Male geliefert wurde.
Das Row_Width-Feld 924 definiert die Breite einer Gruppe mit voller Zeile (z. B. in einer Anzahl von Bildpunkten). Zu beachten ist, dass der Wert „Row_Width 924“ als X-Koordinatenwert ausgedrückt werden kann, der vom Compiler bereitgestellt wird. Das FB_Rows-Feld 926 definiert die Höhe einer Gruppe mit voller Zeile (z. B. in einer Anzahl von Bildpunkten). Zu beachten ist, dass das FB_Rows-Feld 924 als ein Y-Koordinatenwert ausgedrückt werden kann, der von dem Compiler bereitgestellt wird.
Das Feld FB_Base_Address 930 definiert die Position der Zeilengruppe im Speicher der Zeilenpuffereinheit. In einem als „vollen“ Zeilengruppenmodus bezeichneten ersten Betriebsmodus wird im Speicher auf eine Zeilengruppe voller Größe zugegriffen (Zeilengruppen werden von den Erzeugern empfangen und mit der gesamten Menge ihrer jeweiligen Daten an die Abnehmer geliefert). Im vollen Zeilengruppenmodus können das Num_Channels-Feld 922, das Row_Width-Feld 924 und das FB_Rows-Feld 926 mit dem FB_Address-Feld 930 verwendet werden, um den Bereich von Adressen zu bestimmen, die auf den Speicher angewendet werden sollen, um auf eine volle Zeilengruppe vollständig zugreifen zu können. Zusätzlich können dieselben Parameter verwendet werden, um eine Anforderung von einem Datenblattgenerator zu „übersetzen“, der die Zeilengruppe in X-, Y-Koordinaten in eine lineare Speicheradresse angefordert hat.
Die VB_Enable-, VB_Rows-, VB_Cols-, Num_Reuse_Rows- und VB_Base_Address-Felder 925, 927, 928, 931 werden in einem anderen Betriebsmodus verwendet, der als der „virtuell schlanke“ Zeilengruppenmodus bezeichnet und weiter unten näher beschrieben wird.
Während 9d den Konfigurationsregisterbereich 905 für eine Einzelzeilenpuffer-Schnittstelleneinheit darstellte, zeigt 9e im Gegensatz dazu eine Ausführungsform des Inhalts des globalen Konfigurationsregisterbereichs 907 für die gesamte Zeilenpufferschaltkreiseinheit 901. Während der Puffer-Schnittstelleneinheit-Registerbereich pro Zeile von 9d auf eine bestimmte Zeilengruppe fokussiert ist, ist der globale Registerraum 907 aus 9e im Gegensatz dazu auf das Verständnis des Parsens verschiedener Zeilengruppen aus dem gleichen Bild, sowie anderer Informationen fokussiert, die für die Erzeuger-/Abnehmer-Kombination spezifisch und mit der Verarbeitung des Bildes verbunden sind.
Wie in 9e dargestellt, beinhaltet eine Ausführungsform des globalen Registerbereichs die Anzahl der Kanäle 932 und die Anzahl der Abnehmer 933 für ein bestimmtes Bild. Der Einfachheit halber wird in dem Registerbereich von 9e nur ein Bild mit einer Gruppe von Erzeugern und Abnehmern (z. B. nur einen einzigen Videostream und einen einzigen Punkt in einem DAG) betrachtet. Denkbar ist, dass mehrere Instanzen des Registerbereichs von 9e zugewiesen werden, um der Zeilenpufferschaltkreiseinheit ein effektives Multitasking zu ermöglichen.
Eine erste Form von Multitasking befindet sich innerhalb einer DAG- oder Software-Pipeline, die auf dem Grafikprozessor implementiert ist. Hier könnte die gleiche Zeilenpuffereinheit dafür konfiguriert sein, die Zeilengruppierung für zwei verschiedene Knoten innerhalb des DAG oder für zwei verschiedene Phasen der Pipeline zu behandeln (das heißt, eine einzelne Zeilenpuffereinheit könnte mehr als einen Schablonenprozessor unterstützen). Die verschiedenen Knoten/Phasen könnten leicht unterschiedliche Anzahlen von Abnehmern haben, in vielen Fällen sind jedoch die gleichen Bild- und Schablonengrößencharakteristiken wahrscheinlich. Eine zweite Form von Multitasking läuft über mehrere verschiedene DAGs und/oder mehrere unterschiedliche Pipelines, die auf der gleichen Grafikprozessor-Hardware implementiert sind. Beispielsweise könnte ein Grafikprozessor mit vier Schablonenprozessoren gleichzeitig zwei völlig unterschiedliche zweistufige Pipelines ausführen, die jeweils völlig unterschiedliche Bildgrößen mit völlig unterschiedlichen Schablonenabmessungen verarbeiten.
Unter erneuter Bezugnahme auf die spezielle Ausführungsform von 9e ist zu beachten, dass ein bestimmter Knoten in einem DAG oder zwischen Pipeline-Phasen durch die Anzahl von Kanälen im Bild, die Bildgröße, die Abmessungen der anwendbaren Schablone und die Anzahl der Abnehmer der Zeilengruppen umfassend charakterisiert werden kann (9e geht wiederum von einen Erzeuger pro Zeilengruppe aus, es können jedoch mehr als ein Erzeuger in eine einzige Zeilengruppe schreiben, wobei in diesem Fall der globale Registerbereich aus 9e auch ein Feld für die Anzahl der Erzeuger beinhalten würde). Die Felder Num_Channels und Num_Consumers 932, 933 sind im Wesentlichen die gleichen wie die entsprechenden Felder 922, 923 aus 9c.
Die Bildfelder 934, 935 für Image_Size und Stencil_Dimension beschreiben im Wesentlichen die Abmessungen des zu bearbeitenden Bildes und die Abmessungen der Schablone, die auf den Zeilengruppen arbeiten, die aus dem Bild geschnitzt werden sollen. Zu beachten ist, dass beide Felder 934, 935 in Form von X-, Y-Koordinatenwerten ausgedrückt und vom Compiler bereitgestellt werden können. Darüber hinaus verwendet in einer Ausführungsform die Steuerlogikschaltung innerhalb der Zeilenpufferschaltkreiseinheit (in 9b nicht dargestellt) die Image_Size- und Stencil_Dimension-Felder 934, 935, um die Row_Width- 924, FB_Rows- 926 und FB_Base_Address-Werte 930 zu bestimmen, die in einen Registerbereich einer Zeilenpuffer-Schnittstelle geladen werden, wenn die Zeilenpuffer-Schnittstelleneinheit zugeordnet ist, um Zeilengruppen von der Erzeuger-/Abnehmergruppe zu verarbeiten, auf die sich die globalen Informationen beziehen. In einer alternativen oder weiteren Ausführungsform wird die Bildgröße als zwei getrennte Werte, image_width und image_height ausgedrückt, die einen eigenen separat adressierbaren Registerbereich haben können. Ebenso kann die Schablonengröße als zwei getrennte Werte, stencil_width und stencil_height ausgedrückt werden, die einen eigenen separat adressierbaren Registerbereich haben können.
Row_Width 924 ist direkt aus den Informationen der Image_Size 934 erhältlich. Wenn beispielsweise Image_Size als das X-, Y-Koordinatenpaar am entferntesten Bildpunkt vom Bildursprung (obere rechte Ecke, wenn sich der Ursprung an der unteren linken Ecke befindet) ausgedrückt wird, kann Row_Width als der X-Koordinatenwert bestimmt werden.
Die Felder FB_Rows und FB_Base_Address 926, 930 können aus den Image_Size- und Stencil_Dimension-Feldern 934, 935 ermittelt werden. Hier kann insbesondere die Höhe jeder Zeilengruppe (FB_Rows 926) aus der Höhe des Bildes (Y-Koordinatenwert von Image_Size 934) und der Schablonenhöhe (Y-Koordinatenwert der Stencil_Dimension 935) berechnet werden. Sobald die Höhe der Zeilengruppen bekannt ist, kann auch die Anzahl der zu parsenden Zeilengruppen aus dem Bild und die Startlinearadresse für jede der besagten Zeilengruppen im Speicher (FB_Base_Adresse 930) bestimmt werden.
Wenn also in einer Ausführungsform eine Zeilenpuffereinheit damit beauftragt ist, eine Zeilengruppe für eine bestimmte Erzeuger-/Abnehmer-Kombination zu verarbeiten, deren globaler Registerbereich durch die Registerfelder von 9e gekennzeichnet ist, werden die oben beschriebenen Bestimmungen gleichzeitig berechnet und die jeweiligen FB_Width- 924, FB_Rows- 926, Base_Address-Werte 934 zusammen mit den direkt kopierten Num_Channels 922 und Num_Consumers 923 in den spezifischen Registerbereich der Zeilenpuffer-Schnittstelleneinheit geladen. Logikschaltungen und Datenpfade können daher zwischen dem globalen Registerbereich und jeder Instanz des Registerbereichs der Zeilenpuffer-Schnittstelleneinheit vorhanden sein, um die besagten Bestimmungen und Datenübertragungen auszuführen.
In einer alternativen Ausführungsform führt der Compiler die jeweiligen Berechnungen durch, wodurch ein Großteil, wenn nicht gar der gesamte globale Registerbereich beseitigt wird. Hier kann beispielsweise der Compiler für jede Zeilengruppe den Base_Address-Wert ermitteln und die Werte in eine Nachschlagetabelle innerhalb der Zeilenpufferschaltkreiseinheit einladen. Die Werte werden aus der Nachschlagetabelle abgerufen und, sobald die entsprechenden Zeilengruppen konfiguriert sind, in einen Registerbereich der Zeilenpuffer-Schnittstelleneinheit geladen. Es können auch verschiedene Kombinationen zwischen diesen beiden Extremen (Hardware-improvisiert und statisch von einem Compiler ermittelt) implementiert werden.
Obwohl die obigen Ausführungsformen das Aufbewahren der Konfigurationsinformationen in der Registerschaltung (dem „Registerbereich“) hervorgehoben haben, können in anderen oder kombinierten Ausführungsformen Konfigurationsinformationen im Speicher (wie z. B. einem Pufferspeicher) oder in anderen Speichern oder Informationsaufbewahrungsschaltkreis aufbewahrt werden.
c. Vollzeilen-Gruppen-Modus vs. virtuell schlanker Modus
Die obigen Erklärungen sind weitgehend auf den Modus „Vollzeilengruppe“ gerichtet, bei dem Zeilengruppen zwischen den Datenblattgeneratoren und der Zeilenpuffereinheit als vollständige, ganze Zeilengruppen bezeichnet und übermittelt werden. In einem anderen als „virtuell schlank“ bezeichneten Modus werden Zeilengruppen zwischen den Datenblattgeneratoren als oberer Abschnitt mit voller Breite und unterer Abschnitt, der in getrennten, diskreten Segmenten vervollständigt wird, bezeichnet und übermittelt.
10a und 10b zeigen eine Darstellung einer exemplarischen, virtuell schlanken Modus-Sequenz. Wie in 10a dargestellt, ist eine Zeilengruppe anfänglich als ein oberer Abschnitt 1003 von Reihen mit voller Breite und ein erster unterer Abschnitt 1004_1 mit nur einem ersten, kürzeren Breitensegment ausgebildet. Die anfängliche Bildung einer Zeilengruppe kann durch einen Erzeuger-Datenblattgenerator an eine Zeilenpuffereinheit oder durch eine Zeilenpuffereinheit an einen Abnehmer-Datenblattgenerator geliefert werden.
Im Fall eines Erzeugers wird die Zeilengruppe gebildet, nachdem die Schablonen 1002 über dem unteren Abschnitt 1004_1 die Verarbeitung abgeschlossen haben (die ungefähre Schablonenpositionierung ist in 10b zu sehen). Nachdem der Erzeuger-Schablonenprozessor über dem unteren Abschnitt 1004_1 die Verarbeitung abgeschlossen hat, fahren die Schablonen horizontal weiter nach rechts. Letztendlich werden diese über einem nächsten unteren Abschnitt 1004_2 die Verarbeitung fortsetzen. Nach Beendigung des nächstniedrigeren Abschnitts 1004_2 wird der nächste untere Abschnitt 1004_2 von dem Datenblattgenerator an die Zeilenpuffereinheit gesendet, die diesen in dem Speicher an der richtigen Position, z. B. „neben“ dem ersten unteren Abschnitt 1004_1, speichert. Der Vorgang wird fortgesetzt, bis die Zeilengruppe vollständig in den Zeilenpufferspeicher geschrieben ist.
Im Fall von Abnehmern wird die Zeilengruppe anfänglich, wie in 10a dargestellt, an den Datenblattgenerator geliefert. Der Schablonenprozessor arbeitet über dem ersten Abschnitt 1004_1 der Zeilengruppe. Nach Beendigung der Verarbeitung des ersten Abschnitts 1004_1 fordert der Datenblattgenerator den nächsten unteren Abschnitt 1004_2 an, der aus dem Speicher abgerufen und von der Zeilenpuffereinheit geliefert wird. Der Vorgang wird fortgesetzt, bis die Zeilengruppe vollständig verarbeitet ist.
Zu beachten ist, dass sowohl für Erzeuger als auch für Abnehmer niedrigere Abschnitte durch den Datenblattgenerator spezifisch identifiziert werden. Das heißt, sowohl im Erzeugerfall als auch im Abnehmerfall wird der untere Abschnitt 1004_2 durch den Datenblattgenerator spezifisch identifiziert, während die Zeilenpuffereinheit speziell auf den Speicher zugreift, um den unteren Abschnitt 1004_2 zu speichern/abzurufen. In einer Ausführungsform identifiziert der Datenblattgenerator den unteren Abschnitt 1004_2 durch X-, Y-Koordinatenwerte, die basierend auf den vom Compiler bereitgestellten Informationen betrachtet werden (beispielsweise eine der Ecken des unteren Abschnitts 1004_2, alle vier Ecken des unteren Abschnitts 1004_2, nur ein X-Koordinatenwert usw.).
4.0-Makro-E-/A-Ausführungsformen
Wie aus der Erklärung von 4 hervorgeht, leitet eine Makro-E-/A-Einheit 405 Frames der Bilddaten an eine Zeilenpuffereinheit 401, um dem Grafikprozessor Eingabebilddaten zuzuführen. Ebenso werden verarbeitete Ausgabeframes der Bilddaten von einer Zeilenpuffereinheit 401 an die Makro-E-/A-Einheit 405 übertragen, um von dem Grafikprozessor verarbeitete Bilddaten an jene Systemressource zu liefern, die von dem Grafikprozessor (z. B. einem Anwendungssoftwareprogramm, einem Display, einer Kamera usw.) Gebrauch macht.
11a zeigt eine Ausführungsform der Makro-E-/A-Einheit 1105 im Detail. Wie in 11a dargestellt, ist die Makro-E-/A-Einheit 1105 gemäß einer Ausführungsform mit dem Speicher 1106 gekoppelt, der sich außerhalb des Grafikprozessors 1101 befindet. Beispielsweise kann es sich bei dem externen Speicher 1106 um den Systemspeicher eines Computersystems, den lokalen Speicher für eine Kamera, einen Grafikprozessor, einen Beschleuniger und/oder einen Coprozessor handeln, bei dem der Grafikprozessor 1101 ein Bestandteil ist oder anderweitig zugeordnet ist. Als externer Speicher 1106 wird ein beliebiger Speicher verstanden, der von der Logik des Grafikprozessors 1101 selbst extern ist und sich daher von dem internen Speicher des Grafikprozessors unterscheidet (wie beispielsweise der Speicher, der gegenüber den Zeilenpuffereinheiten 401 oder den Datenblattgeneratoren 403 lokal ist).
Während des nominalen Betriebs werden von dem Grafikprozessor 1101 zu verarbeitende Eingabeframes von Bilddaten zunächst in den externen Speicher 1106 geschrieben. Die Makro-E-/A-Einheit 1105 liest dann die Bildframes aus dem externen Speicher 1106 und speist sie in den Grafikprozessor 1101. Nachdem der Grafikprozessor 1101 die Verarbeitung von ausreichenden Abschnitten eines oder mehrerer Frames abgeschlossen hat, schreibt die Makro-E-/A-Einheit die verarbeiteten Abschnitte als Ausgabe des Grafikprozessors in den externen Speicher 1006. Zu beachten ist, dass Abschnitte eines Frames in den externen Speicher geschrieben werden können, bevor der Frame vollständig verarbeitet wird.
11a zeigt eine umfassende Darstellung einer Ausführungsform der Makro-E-/A-Einheit 1105. Wie in 11a dargestellt, ist die Makro-E-/A-Einheit 1105 so ausgelegt, dass sie eine Anzahl von logischen Kanaleinheiten 1110_1 bis 1110_N beinhaltet, die jeweils für die Einrichtung eines logischen Kanals zwischen dem externen Speicher 1106 und einem internen Abnehmer der aus dem externen Speicher zu lesenden Bilddaten, die durch den Grafikprozessor verarbeitet werden, oder für die Einrichtung eines internen Erzeugers von Ausgabebilddaten verantwortlich ist, die aus dem Grafikprozessor in den externen Speicher 1106 geschrieben werden müssen.
In verschiedenen Ausführungsformen kann es sich bei den besagten Abnehmern oder Erzeugern um eine Zeilenpuffereinheit oder den Datenblattgenerator eines Schablonenprozessors handeln. Unter erneuter Bezugnahme auf 4, ist zu erkennen, dass die Makro-E-/A-Einheit 405 in einer Ausführungsform direkt mit dem Netzwerk 404 gekoppelt ist, um eine Kommunikation nicht nur zu mit den Zeilenpuffereinheiten 401, sondern auch mit einem Datenblattgenerator 403 eines speziellen Schablonenprozessors zu ermöglichen 402. In verschiedenen anderen Ausführungsformen ist das Netzwerk 404 in dem Sinne globaler, dass die Makro-E-/A-Einheit 405 mit den Zeilenpuffereinheiten 401 über das Netzwerk 404 anstatt, wie in 4 erklärt, direkt mit den Zeilenpuffereinheiten 401 kommuniziert.
11b zeigt eine Ausführungsform des Logikschaltungsentwurfs für eine logische Kanaleinheit 1110. Wie in 11b dargestellt, beinhaltet die logische Kanaleinheit 1110 eine Zustandsmaschinen-Logikschaltung 1111, einen Kontextregisterbereich 1112, eine Umformatierungslogik 1113, eine Eingabewarteschlange 1114, eine Ausgabewarteschlange 1115 und einen Kommunikationskanal mit anderen logischen Kanaleinheiten 1116. Zu beachten ist, dass in alternativen Ausführungsformen die Umformatierungslogik 1113 als ein einziger zentralisierter Block implementiert sein kann, der von mehreren logischen Kanaleinheiten gemeinsam genutzt wird, anstatt, dass, wie in 11b erklärt, jeder Kanal seine eigene dedizierte Umformatierungslogik aufweist. Der Einfachheit halber wird der Rest der Erklärung davon ausgehen, dass Umformatierungslogikblöcke pro Kanal implementiert worden sind, anstatt eine zentrale Umformatierung durchzuführen.
Bilddaten, die von der logischen Kanaleinheit 1110 empfangen werden, werden in der Eingabewarteschlange 1114 empfangen. Die in der Eingabewarteschlange 1114 residenten Bildpunkte der Eingabedaten werden durch Umformatieren der Logik 1113 oft selektiv ausgewählt, wodurch Einheiten von Ausgabedaten in der Ausgabewarteschlange 1115 gemäß einem anderen Format aufgebaut werden, das sich von dem Format unterscheidet, gemäß dem die Eingabebildpunkte in der Eingabewarteschlange 1114 formatiert werden. Das heißt, die Bildpunkte der Ausgabedaten werden in der Regel in der Ausgabewarteschlange 1115 gemäß einer anderen Formatstruktur angeordnet als die Eingabebildpunkte in der Eingabewarteschlange 1114.
Beispielsweise können im Fall, dass dem Grafikprozessor Eingabedaten aus dem externen Speicher zugeführt werden, die in dem externen Speicher residenten Eingangsbilddaten gemäß RGB-, RGB-, RGB-, Bildpunktdatenformat angeordnet werden. Der (die) Schablonenprozessor(en) kann (können) jedoch auf Datenblättern von Bildpunktdaten arbeiten, die dieselbe Farbe haben. Das heißt, der (die) Schablonenprozessor(en) kann (können) separat auf Datenblättern von R-Bildpunkten, Datenblättern von G-Bildpunkten und Datenblättern von B-Bildpunkten arbeiten. Um die eingegebenen Bilddaten aus ihrem Format in einem externen Speicher auf das von den Schablonenprozessoren verwendete Format vorzubereiten, wird die Umformatierungslogik 1113, z. B. R-Bildpunkte aus der Eingabewarteschlange 1114 auswählen, um Blöcke von R-Bildpunkten in der Ausgabewarteschlange 1115 zu erzeugen. Sobald ein Block von R-Bildpunkten von ausreichender Größe in der Ausgabewarteschlange 1115 erstellt worden ist, wird der Block an eine Zeilenpuffereinheit oder einen Datenblattgenerator eines Schablonenprozessors weitergeleitet.
Nachdem beispielsweise eine Einspeisung von R-Bildpunkten erschöpft ist und tiefer in den Grafikprozessor weitergeleitet wurde, kann die Umformatierungslogik 1113 nur G-Bildpunkte aus der Eingabewarteschlange 1114 auswählen, um Blöcke von G-Bildpunkten in der Ausgabewarteschlange 1115 zu erstellen. Wiederum wird, nachdem eine Einspeisung von G-Bildpunkten erschöpft ist und weitergeleitet wurde, die Umformatierungslogik 1113 B-Bildpunkte aus der Eingabewarteschlange 1114 auswählen, um Blöcke von B-Bildpunkten in der Ausgabewarteschlange 1105 zu erstellen und tiefer in den Grafikprozessor weiterzuleiten.
Gegenläufig werden in der umgekehrten Richtung, in der die Logikkanaleinheit 1110 verwendet wird, um das Schreiben von Ausgabebildern aus dem Grafikprozessor in einen externen Speicher zu unterstützen, Blöcke derselben Bildpunkttypen in die Eingabewarteschlange 1114 geladen. Das heißt, dass z. B. Blöcke von R-Bildpunkten, G-Bildpunkten und B-Bildpunkten an einer Eingabewarteschlange 1114 von einer Zeilenpuffereinheit oder einem Datenblattgenerator eines Schablonenprozessors empfangen werden. Die Umformatierungslogik 1113 wählt dann bestimmte dieser Bildpunkteaus, um Ausgabeblöcke mit der ursprünglichen RGB-, RGB-Formatstruktur in der Ausgabewarteschlange 1115 zu bilden und diese in den externen Speicher zu schreiben.
Die Zustandsmaschinenlogik 1111 steuert das Umformatierungsverhalten der Umformatierungslogik 1113, bestimmt, welche Adressen und/oder Adressierungsschemata beim Zugriff auf den externen Speicher zu verwenden sind, und versteht zudem, mit welcher Zeilenpuffereinheit oder welchem Datenblattgenerator diese bei der Bildung eines logischen Verbindungskanals mit dem externen Speicher kommuniziert.
In verschiedenen Ausführungsformen sind die Zustandsmaschinenlogik 1111 und die Umformatierungslogik 1113 mit einer dedizierten Logikschaltung implementiert. In anderen Ausführungsformen können die Zustandsmaschinenlogik 1111 und/oder die Umformatierungslogik 1113 als ein Mikrocontroller implementiert sein, der einen Programmcode ausführt, um die Zustandsmaschinen-/Umformatierungsfunktionen zu implementieren. In noch anderen Ausführungsformen kann die Zustandsmaschinenlogik 1111/Umformatierungslogik 1113 als eine Kombination aus programmierter und dedizierter Logikschaltung implementiert sein. Die dedizierte Logikschaltung kann als festverdrahtete und/oder programmierbare logische Schaltung (z. B. als programmierbare logische Schaltung, Universalschaltkreis (PLD) (FPGA) oder programmierbare logische Schaltung (PLAs) exemplarisch für letztere) implementiert sein.
Die Informationseinheit, auf die sich die Zustandsmaschine bezieht, um ihre verschiedenen Zuständigkeiten zu verstehen, wird in dem Kontextregisterbereich 1112 aufbewahrt, der anfänglich mit den entsprechenden Kontextinformationen für einen bestimmten DAG oder eine bestimmte Pipeline geladen wird, wenn z. B. der Grafikprozessor dafür konfiguriert ist, den DAG oder die Pipeline auszuführen. Nachfolgende Aktualisierungen des Registerbereichs 1112 während der Ausführung des DAG oder der Pipeline können durch die Zustandsmaschinenlogik 1111, anderweitiger Intelligenz innerhalb des Grafikprozessors (wie etwa den skalaren Prozessor innerhalb eines Schablonenprozessors und/oder das System, (z. B. Computer, Kamera usw.)) vorgenommen werden.
In einer Ausführungsform enthält der Kontextregisterbereich 1112 die folgenden Informationen: 1) die Basis-externe Speicheradresse des Frames von Bilddaten, die, für den Fall, dass dem Grafikprozessor Eingabedaten zugeführt werden, aus dem externen Speicher eingelesen werden soll, oder, für den Fall, dass Ausgabedaten aus dem Grafikprozessor geschrieben werden, in den externen Speicher geschrieben werden soll; 2) die Größe des Bildframes (z. B. in Form von Breite und Gewicht in Einheiten von Bildpunkten); 3) das Format der Daten im externen Speicher; 4) das Format der Daten, die innerhalb des Grafikprozessors verwendet werden; und 5) die Identität des jeweiligen Datenblattgenerators, Schablonenprozessors oder der Zeilenpuffereinheit, den bzw. die der Kanal mit dem externen Speicher logisch koppelt. In verschiedenen Ausführungsformen beinhalten unterstützte Bilddatenformate in beiden Richtungen RGB, alle eine Farbe und unter anderem gepackte RAW.
Wie in 11 dargestellt, beinhaltet die logische Kanaleinheit 1110 zudem eine Kommunikationsverbindung 1116, sodass sie den Zustand anderer logischer Kanäle verstehen und eine Koordination zwischen mehreren logischen Kanälen bewirken kann. Ein logischer Kanal, der dem Grafikprozessor Eingabedaten zuführt, kann beispielsweise dafür konfiguriert werden, nach anfänglichem Einladen der Bilddaten in den Grafikprozessor auf das Einladen eines nächsten Frames der Eingabebilddaten in den Grafikprozessor aus dem externen Speicher zu verzichten, bis ein nächster Ausgabebildframe aus dem Grafikprozessor in den externen Speicher geschrieben wurde. Ohne eine die besagte Koordination könnten die internen Speicherressourcen des Grafikprozessors beispielsweise für einige DAG- oder Pipeline-Entwürfe überfordert werden.
12a, b und 13 erläutern noch ein paar relevante Merkmale der Verarbeitungsvorgangsarten, die die Zustandsmaschine 1111 eines logischen Kanals bewirken kann. 12a und 12b betreffen spezielle Adressierungsverfahren des externen Speichers, die durch eine logische Kanaleinheit ausgeführt werden können, sodass eine logische Puffereinheit effizienter arbeiten kann.
Wie aus der Erklärung der 10a und 10b hervorging, kann eine Zeilenpuffereinheit gemäß einem „virtuell schlanken“ Modus arbeiten, bei dem zwei sich nicht über die gesamte Vollbildbreite erstreckende zweidimensionale Bildbereiche 1004_1, 1004_2 von einem Zeilenpuffer an einen Datenblattgenerator in Folge übermittelt werden, anstatt Zeilenpuffer mit voller Breite oder zu übermitteln oder die gesamte Framebreite per Rasterverfahren abzutasten, wobei die Daten aus einer nächsten Zeile nicht weitergeleitet werden, bis alle Daten aus einer vorherigen Zeile vollständig weitergeleitet worden sind.
12a und 12b zeigen ein Speicheradressierungsschema, das die Zustandsmaschinenlogik 1111 einer logischen Kanaleinheit 1110 implementieren kann, um die Weiterleitung der Daten an einen Datenblattgenerator gemäß einer Methode, wie z. B. „der virtuell schlanken“, an eine logische Puffereinheit zu ergänzen, wobei die Daten aus den nächsten Zeilen weitergeleitet werden, bevor alle Daten aus einer vorhergehenden Zeile vollständig weitergeleitet wurden. In 12a kann der Bildbereich 1201 beispielsweise als die Bilddaten, die die Bilddaten 1004_1 aus 10a beinhalten, gesehen werden.
Hier werden die Bilddaten 1201 innerhalb des Bildframes 1220 aus dem externen Speicher eingelesen und an die Zeilenpuffereinheit weitergeleitet, bevor die Zeilenpuffereinheit die Bilddaten 1004_1 an einen Datenblattgenerator weiterleitet. Um die Bilddaten 1201 an die Zeilenpuffereinheit weiterzuleiten, sollte beachtet werden, dass die Speicheradressierung auf das Einlesen über eine gesamte Datenzeile des Bildframes 1220 verzichten sollte und stattdessen eine begrenzte Ausdehnung einer Zeile 1210 einlesen und dann „nach unten rutschen“ sollte, um eine nächste begrenzte Ausdehnung einer nächstniedrigeren Reihe 1211 einzulesen.
Der Vorgang wird fortgesetzt, bis der gesamte Bereich 1201 aus dem externen Speicher eingelesen wird (der z. B. nach dem Einlesen der Zeile mit der begrenzten Ausdehnung 1212 abgeschlossen ist), sodass dieser an die Zeilenpuffereinheit übermittelt werden kann. Nachdem der Bildbereich 1201 an die Zeilenpuffereinheit übermittelt wurde, ist die Zeilenpuffereinheit in der Lage, die Bilddaten 1004_1 an einen Datenblattgenerator weiterzuleiten.
Mit dem gleichen Ansatz wie in 12b wird gemäß der gleichen Adressierungsmethode 1210, 1211...1212, wie weiter oben mit Bezug auf 12a und dem Bildbereich 1201 beschrieben, ein nächster Bildbereich 1202 aus dem externen Speicher eingelesen. Nachdem der Bildbereich 1202 gemäß dem speziellen Speicheradressierungsansatz aus dem externen Speicher eingelesen wurde, kann der Bildbereich 1202 an die Zeilenpuffereinheit weitergeleitet werden, wodurch diese in der Lage ist, die Bilddaten 1004_2 aus 10b an denselben Datenblattgenerator weiterzuleiten.
Dementsprechend kann die logische Kanaleinheit, die zwischen dem externen Speicher und der logischen Puffereinheit liegt, die Daten an die Zeilenpuffereinheit in einer Weise weiterleiten, die der Weise ähnelt, in der die Zeilenpuffereinheit die Bilddaten an einen Datenblattgenerator weiterleitet. Dadurch, dass die Eingabedaten der Logikpuffereinheit in einer Weise zugeführt werden, die der Weise ähnelt, in der die Zeilenpuffereinheit die Eingabedaten einem Datenblattgenerator zuführt, wird der Gesamtdurchsatz und die Effizienz der Zeilenpuffereinheit verbessert. Zu beachten ist, dass die logische Kanaleinheit darüber hinaus zwischen dem Einlesen der Eingabedaten aus dem externen Speicher und der Weiterleitung derselben an die Zeilenpuffereinheit die zuvor erwähnte Umformatierung (zum Beispiel RGB in ausschließlich R, ausschließlich G und ausschließlich B) durchführen kann.
Der spezielle Adressierungsmodus der 12a und 12b kann zudem in der Schreibrichtung der Ausgabedaten aus dem Grafikprozessor in den externen Speicher angewendet werden. Hier kann ein Datenblattgenerator im „virtuellen Zahlen“-Modus verarbeitete Ausgabebilddaten an einen Zeilenpuffer übermitteln, wodurch eine Zeilenpuffereinheit wiederum dazu veranlasst wird, Bilddatenbereiche mit begrenzter Ausdehnung ähnlich den Bereichen 1201, 1202 aus 12 an die logische Kanaleinheit weiterzuleiten. Als Reaktion darauf schreibt die logische Kanaleinheit gemäß demselben speziellen Adressierungsansatz 1210, 1211...1212 die Daten in den externen Speicher. Wiederum kann zwischen dem Empfang der Ausgabebilddaten aus einer Zeilenpuffereinheit und dem Schreiben derselben in den externen Speicher eine Umformatierung durch den logischen Kanal durchgeführt werden.
13 bezieht sich auf einen anderen speziellen Adressierungsansatz, bei dem z. B. ein auf einem Schablonenprozessor ausgeführtes Kernsystem besonders individuelle Oberflächenbereiche anfordert, die sich mehr zufällig oder ad hoc an ihrer Position innerhalb des Eingabeframes befinden, anstatt in Reihenfolge geordnet oder ausgerichtet zu werden. Beispielsweise kann, wie in 13 dargestellt, ein Schablonenprozessor die Bildbereiche 1301, 1302, 1303 und 1304 nacheinander anfordern, anstatt Daten in einem geordneten sequentiellen Modus auf der gesamten Breite des Eingabeframes (ob Zeilengruppe, virtuell schlank oder anderweitig) anzufordern. Hier wird jeder Bereich 1301 bis 1304 unter Verwendung des Adressierungsansatzes mit begrenzter Ausdehnung 1210, 1211...1212 der 12a, b, jedoch innerhalb der Begrenzungen der Ad-hoc-Bildbereiche 1301 bis 1304 eingelesen. Dementsprechend ist die Form des externen Speicherabrufbereichs konfigurierbar.
Die Verarbeitung von Bildbereichen in einer ad hoc anstatt einer geordneten Sequenz kann beispielsweise für Bewegungskompensationsroutinen (bei denen sich ein Merkmal in einem Bildstrom bewegt), für geometrische Verzerrungsroutinen (z. B. zum Kompensieren der Linse oder anderer Bildaufnahmen) für Mängel, bei denen der gesammelte Frame der Bilddaten verzerrt ist) und für Matrixmehrfach- oder Transponierungsoperationen nützlich sein.
In einer Ausführungsform verbraucht die Ad-hoc-Adressierung zwei logische Kanaleinheiten 1110 innerhalb der Makro-E-/A-Einheit 1105. Eine erste logische Kanaleinheit empfängt Basiskoordinatenwerte von jedem Ad-hoc-Bildbereich, die der Schablonenprozessor anfordert. Beispielsweise kann ein gewünschter Bildbereich durch den Schablonenprozessor spezifiziert werden, der die Höhe und Breite des Bereichs zusammen mit der Adresse der unteren linken Ecke des Bereichs identifiziert.
Unter der Annahme, dass der nominale Betrieb jeden gewünschten Bereich mit der gleichen Breite und Höhe aufweist, kann eine Sequenz von Ad-hoc-Bildbereichen identifiziert werden, indem die Koordinatenwerte der unteren linken Ecke jedes gewünschten Bereiches an die erste logische Kanaleinheit weitergeleitet werden (z. B. werden zunächst die Koordinatenwerte der unteren linken Ecke des Bereichs 1301 an die erste logische Kanaleinheit gesendet, und anschließend werden die Koordinatenwerte der unteren linken Ecke des Bereichs 1302 an die erste logische Kanaleinheit gesendet usw.). Die erste logische Kanaleinheit leitet dann die empfangenen Koordinatenwerte zu einer zweiten logischen Kanaleinheit (z. B. über einen Kommunikationskanal 1106 von 11a), der die gewünschten Bereiche aus dem externen Speicher einliest, umformatiert und diese dann an den anfordernden Schablonenprozessor weiterleitet. Zu beachten ist, dass die Möglichkeit besteht, dass die Ad-hoc-Bildbereiche einer Sequenz untereinander eine beträchtliche Überlappung aufweisen. Das heißt, dass ein erster Bildbereich viel von demselben Bildbereich verbrauchen kann, den ein zweiter Bildbereich ebenfalls verbraucht. In einer Ausführungsform ist ein Cache zwischen dem externen Speicher und den logischen Kanälen implementiert, um die Überlappung der Bilddaten zwischen mehreren Bildbereichen aufrechtzuerhalten, sodass mehrere Speicherzugriffe für dieselben Daten vermieden werden können.
14 zeigt eine Methodik, die, wie oben beschrieben, durch eine logische Kanaleinheit ausgeführt werden kann. Wie in 14 dargestellt, beinhaltet die Methodik das Ermöglichen einer logischen Verbindung mit einer Abnehmerkomponente innerhalb eines Grafikprozessors 1401. Das Verfahren beinhaltet zudem das Einlesen einer Reihe von Bildbereichen mit begrenzter Breite aus einem Frame von Bilddaten, wobei jeder der Bildbereiche gemäß einem RGB-Format 1402 formatiert ist. Darüber hinaus beinhaltet das Verfahren das Umformatieren der Serie von Bildbereichen mit begrenzter Breite in Bilddatenblöcke, die die gleiche Farbkomponente 1403 aufweisen. Außerdem beinhaltet das Verfahren das Weiterleiten der Bilddatenblöcke, die die gleiche Farbkomponente aufweisen, wie die Abnehmerkomponente 1404.
e. Implementierungsausführungsformen
Es ist wichtig, darauf hinzuweisen, dass die oben beschriebenen verschiedenen Merkmale der Grafikprozessorarchitektur nicht zwangsläufig auf die Bildverarbeitung im herkömmlichen Sinne beschränkt sind und daher auf andere Anwendungen angewendet werden können, die ggf. veranlassen, dass der Grafikprozessor neu charakterisiert wird oder auch nicht. Wenn beispielsweise eines der vorstehend beschriebenen verschiedenen Merkmale der Grafikprozessorarchitektur bei der Erstellung und/oder Erzeugung und/oder Wiedergabe von Animationen anstatt bei der Verarbeitung von tatsächlichen Kamerabildern verwendet werden soll, kann der Grafikprozessor als grafische Verarbeitungseinheit charakterisiert sein. Zudem können die oben beschriebenen Architekturmerkmale des Grafikprozessors in anderen technischen Anwendungen, wie in der Videoverarbeitung, Bildverarbeitung, Bilderkennung und/oder dem maschinellen Lernen, angewendet werden. Auf diese Weise kann der Grafikprozessor (z. B. als Coprozessor) in einen allgemeineren Universalprozessor (z. B. als Teil eines CPUs des Computersystems) mit integriert werden oder ein eigenständiger Prozessor innerhalb eines Computersystems sein.
Die oben beschriebenen Hardware-Ausführungsformen können in einem Halbleiterchip und/oder als Beschreibung eines Schaltkreisentwurfs zur letztendlichen Ausrichtung auf ein Halbleiterherstellungsverfahren enthalten sein. Im Falle des Letzteren können derartige Schaltkreisbeschreibungen die Form einer (z. B. VHDL oder Verilog) Beschreibung einer Registerüberleitungsschaltung (RTL), einer Torschaltung, einer Transistorschaltung oder einer Maske oder verschiedener Kombinationen derselben annehmen. Schaltungsbeschreibungen sind in der Regel auf einem computerlesbaren Speichermedium (wie z. B. einer CD-ROM oder einer anderen Art von Speichertechnologie) enthalten.
Aus den vorangehenden Abschnitten ist zu erkennen, dass ein Grafikprozessor, wie oben beschrieben, in der Hardware auf einem Computersystem (z. B. als Teil eines Handgerätsystems on Chip (SOC), das Daten von der Kamera des Handgerätes verarbeitet) enthalten sein kann. In Fällen, in denen der Grafikprozessor als Hardware-Schaltung ausgebildet ist, ist zu beachten, dass die Bilddaten, die von dem Grafikprozessor verarbeitet werden, direkt von einer Kamera empfangen werden können. Hier kann der Grafikprozessor Teil einer diskreten Kamera oder Teil eines Computersystems mit einer integrierten Kamera sein. In dem Fall des Letzteren können die Bilddaten direkt von der Kamera oder aus dem Systemspeicher des Computersystems empfangen werden (z. B. sendet die Kamera ihre Bilddaten anstatt an den Grafikprozessor an den Systemspeicher). Zu beachten ist auch, dass viele der in den vorangehenden Abschnitten beschriebenen Merkmale auf eine Grafikprozessoreinheit (zur Darstellung von Animationen) anwendbar sind.
15 zeigt eine exemplarische Darstellung eines Computersystems. Viele der Komponenten des nachstehend beschriebenen Computersystems sind auf ein Computersystem mit einer integrierten Kamera und einem zugehörigen Grafikprozessor (z. B. einem Handgerät, wie etwa einem Smartphone oder Tablet-Computer) anwendbar. Durchschnittliche Fachleute auf dem Gebiet werden leicht zwischen beiden unterscheiden können.
Wie in 15 dargestellt, kann das grundlegende Computersystem eine zentrale Verarbeitungseinheit 1501 (die beispielsweise eine Vielzahl von Universal-Verarbeitungskernsystemen 1515_1 bis 1515_N und einen auf einem Multikernprozessor oder einem Anwendungsprozessor angeordneten Hauptspeichercontroller 1517 enthalten kann), Systemspeicher 1502, ein Display 1503 (z. B. Touchscreen, Flachbildschirm), eine lokal verdrahtete Punkt-zu-Punkt-Verbindung (z. B. eine USB-Schnittstelle) 1504, verschiedene Netzwerk-E-/A-Funktionen 1505 (wie z. B. eine Ethernet-Schnittstelle und/oder ein Mobilfunkmodem-Teilsystem), ein drahtloses lokales Netzwerk (z. B. WLAN) 1506, eine drahtlose Punkt-zu-Punkt-Verbindung (z. B. Bluetooth-Schnittstelle) 1507 und eine globale Positionierungssystemschnittstelle 1508, verschiedene Sensoren 1509_1 bis 1509_N, eine oder mehrere Kameras 1510, eine Batterie 1511, eine Energieverwaltungssteuereinheit 1512, einen Lautsprecher und ein Mikrofon 1513, sowie einen Audio-Kodierer/Dekodierer 1514 beinhalten.
Ein Anwendungsprozessor oder Multikernprozessor 1550 kann einen oder mehrere Universalprozessorkerne 1515 innerhalb seiner CPU 1501, eine oder mehrere grafische Verarbeitungseinheiten 1516, eine Speicherverwaltungsfunktion 1517 (z. B. einen Speichercontroller), eine E-/A-Steuerfunktion 1518 und eine Bildverarbeitungseinheit 1519 beinhalten. Die Universalverarbeitungskerne 1515 führen in der Regel das Betriebssystem und die Anwendungssoftware des Computersystems aus. Die Grafikverarbeitungseinheiten 1516 führen in der Regel grafikintensive Funktionen aus, um z. B. Grafikdaten zu erzeugen, die auf dem Display 1503 dargestellt werden. Die Speichersteuerfunktion 1517 ist mit dem Systemspeicher 1502 verbunden, um Daten in den Systemspeicher 1502 zu schreiben bzw. aus demselben einzulesen. Die Leistungsverwaltungssteuereinheit 1512 steuert im Allgemeinen den Leistungsverbrauch des Systems 1500.
Die Bildverarbeitungseinheit 1519 kann gemäß einer der oben in den vorangehenden Abschnitten beschriebenen Ausführungsformen der Bildverarbeitungseinheit implementiert sein. Alternativ dazu oder in Kombination kann die IPU 1519 mit einer oder beiden der GPU 1516 und der CPU 1501 als Coprozessor derselben gekoppelt sein. Darüber hinaus kann in verschiedenen Ausführungsformen die GPU 1516 mit einem der oben beschriebenen Prozessormerkmale implementiert sein.
Das Touchscreen-Display 1503, die Kommunikationsschnittstellen 1504–1507, die GPS-Schnittstelle 1508, die Sensoren 1509, die Kamera 1510 und der Lautsprecher/Mikrofon-Codec 1513, 1514 können allesamt als unterschiedliche Formen von E/A (Eingabe und/oder Ausgabe) in Bezug auf das gesamte Rechensystem betrachtet werden, darunter auch gegebenenfalls ein integriertes Peripheriegerät (z. B. der einen oder mehreren Kameras 1510). Je nach Implementierung können verschiedene dieser E-/A-Komponenten auf dem Anwendungsprozessor/Multikernprozessor 1550 integriert sein oder sich außerhalb des Chips oder außerhalb des Pakets des Anwendungsprozessors/Multikernprozessors 1550 befinden.
In einer Ausführungsform beinhalten eine oder mehrere Kameras 1510 eine Tiefenkamera, die in der Lage ist, die Tiefe zwischen der Kamera und einem Objekt in seinem Sichtfeld zu messen. Anwendungssoftware, Betriebssystemsoftware, Gerätetreibersoftware und/oder Firmware, die auf einem universellen CPU-Kern (oder einem anderen Funktionsblock mit einer Befehlsausführungspipeline zum Ausführen eines Programmcodes) eines Anwendungsprozessors oder eines anderen Prozessors ausgeführt werden, können sämtliche der oben beschriebenen Funktionen ausführen.
Ausführungsformen der Erfindung können, wie oben dargelegt, verschiedene Verfahren beinhalten. Die Prozesse können in maschinenausführbaren Anweisungen enthalten sein. Die Anweisungen können dazu verwendet werden, einen Universalprozessor oder Spezialprozessor dazu zu veranlassen, bestimmte Prozesse auszuführen. Alternativ dazu können die besagten Prozesse von spezifischen Hardwarekomponenten ausgeführt werden, die eine fest verdrahtete Logik zum Ausführen der Prozesse oder eine beliebige Kombination von programmierten Computerkomponenten und benutzerdefinierten Hardwarekomponenten enthalten.
Elemente der vorliegenden Erfindung können darüber hinaus als maschinenlesbares Medium zum Speichern der maschinenausführbaren Befehle bereitgestellt sein. Das maschinenlesbare Medium kann unter anderem Floppy-Disketten, optische Platten, CD-ROMs und magneto-optische Platten, FLASH-Speicher, ROMs, RAMs, EPROMs, EEPROMs, magnetische oder optische Karten, Ausbreitungsmedien oder andere Arten von Medien/maschinenlesbaren Medien, geeignet für die Speicherung von elektronischen Befehlen einschließen. Die vorliegende Erfindung kann beispielsweise als ein Computerprogramm heruntergeladen werden, das von einem dezentralen Computer (z. B. einem Server) mittels eines in einer Trägerwelle oder einer anderen Ausbreitungsmedium enthaltenen Datensignals an einen anfordernden Computer (z. B. einen Client) über eine Kommunikationsverbindung (z. B. ein Modem oder eine Netzwerkverbindung) übertragen werden kann.
In der vorstehenden Beschreibung wurde die Erfindung unter Bezugnahme auf spezifische exemplarische Ausführungsformen derselben beschrieben. Es ist jedoch offensichtlich, dass verschiedene Modifikationen und Änderungen daran vorgenommen werden können, ohne von den in den beigefügten Ansprüchen dargelegten Erfindungsgedanken und Schutzumfang der Erfindung abzuweichen. Die Beschreibung und die Zeichnungen sind daher in einem veranschaulichenden und nicht in einem einschränkenden Sinne zu betrachten.

Claims

Grafikprozessor, der Folgendes umfasst: eine E-/A-Einheit zum Einlesen von Eingabebilddaten aus einem externen Speicher zur Verarbeitung durch den Grafikprozessor und zum Schreiben von Ausgabedaten aus dem Grafikprozessor in den externen Speicher, wobei die E-/A-Einheit Folgendes umfasst: mehrere logische Kanaleinheiten, wobei jede logische Kanaleinheit einen logischen Kanal zwischen dem externen Speicher und einer jeweiligen Erzeuger- oder Abnehmerkomponente innerhalb des Grafikprozessors bildet, und wobei jede logische Kanaleinheit dafür ausgelegt ist, Folgendes zu nutzen: eine Adressierungsschaltung zum Steuern von auf dem externen Speicher angewendeten Adressierungsschemata sowie einer Umformatierung von Bilddaten zwischen dem externen Speicher und der jeweiligen Erzeuger- oder Abnehmerkomponente; eine Umformatierungsschaltung zur Durchführung der Umformatierung.
Grafikprozessor nach Anspruch 1, wobei die Adressierungsschaltung in der Lage ist, den externen Speicher derart zu adressieren, dass Bereiche eines Eingabebildframes mit einer geringeren Breite als der Bildframe zwischen dem externen Speicher und der jeweiligen Erzeuger- oder Abnehmerkomponente übermittelt werden können.
Grafikprozessor nach Anspruch 2, wobei die Bereiche ad hoc über den gesamten Eingabebildframe ausgerichtet werden können.
Grafikprozessor nach Anspruch 1, wobei die Umformatierungsschaltung in der Lage ist, Bildpunktblöcke einer Farbe zu konstruieren und dem Grafikprozessor darzustellen.
Grafikprozessor nach Anspruch 4, wobei der Grafikprozessor mehrere interne Prozessoren enthält, die jeweils eine entsprechende zweidimensionale Schieberegistermatrixschaltungsstruktur aufweisen, die Datenblätter von gleichfarbigen Bildpunktwerten verarbeitet.
Grafikprozessor nach Anspruch 1, wobei die Umformatierungsschaltung in der Lage ist, RGB-formatierte Ausgabedaten zum Schreiben in den externen Speicher aus Blöcken von gleichfarbigen Bildpunktausgabedaten zu konstruieren, die von dem Bildprozessor erzeugt wurden.
Grafikprozessor nach Anspruch 6, wobei der Grafikprozessor mehrere interne Prozessoren enthält, die jeweils eine entsprechende zweidimensionale Schieberegistermatrixschaltungsstruktur aufweisen, die Datenblätter von gleichfarbigen Bildpunktwerten verarbeitet.
Computersystem, das Folgendes umfasst: einen oder mehrere Universalprozessoren; einen Systemspeicher; einen Speichercontroller, der mit dem Systemspeicher gekoppelt ist; einen Grafikprozessor, der Folgendes umfasst: eine E-/A-Einheit zum Einlesen von Eingabebilddaten aus einem externen Speicher zur Verarbeitung durch den Grafikprozessor und zum Schreiben von Ausgabedaten aus dem Grafikprozessor in den externen Speicher, wobei die E/A-Einheit Folgendes umfasst: mehrere logische Kanaleinheiten, wobei jede logische Kanaleinheit einen logischen Kanal zwischen dem externen Speicher und einer jeweiligen Erzeuger- oder Abnehmerkomponente innerhalb des Grafikprozessors bildet, und wobei jede logische Kanaleinheit dafür ausgelegt ist, Folgendes zu nutzen: eine Adressierungsschaltung zum Steuern von Adressierungsschemata, die auf dem externen Speicher angewendet werden, sowie einer Umformatierung von Bilddaten zwischen dem externen Speicher und der jeweiligen Erzeuger- oder Abnehmerkomponente; eine Umformatierungsschaltung zur Durchführung der Umformatierung.
Computersystem nach Anspruch 8, wobei die Adressierungsschaltung in der Lage ist, einen externen Speicher anzupassen, sodass Bereiche eines Eingabebildframes mit einer geringeren Breite als der Bildframe zwischen dem externen Speicher und der jeweiligen Erzeuger- oder Abnehmerkomponente übermittelt werden können.
Das Computersystem nach Anspruch 9, wobei die Bereiche ad hoc über den gesamten Bildframe ausgerichtet werden können.
Computersystem nach Anspruch 8, wobei die Umformatierungsschaltung in der Lage ist, Blöcke von Bildpunkten einer Farbe zu konstruieren und dem Grafikprozessor darzustellen.
Computersystem nach Anspruch 11, wobei der Grafikprozessor mehrere interne Prozessoren enthält, die jeweils eine entsprechende zweidimensionale Schieberegisterarrayschaltungsstruktur aufweisen, die Datenblätter von gleichfarbigen Bildpunktwerten verarbeitet.
Computersystem nach Anspruch 8, wobei die Umformatierungsschaltung in der Lage ist, RGB-formatierte Ausgabedaten zum Schreiben in den externen Speicher aus Blöcken gleichfarbiger Bildpunktausgabedaten zu konstruieren, die von dem Grafikprozessor erzeugt werden.
Computersystem nach Anspruch 13, wobei der Grafikprozessor mehrere interne Universalprozessoren enthält, die jeweils eine entsprechende zweidimensionale Schieberegisterarrayschaltungsstruktur aufweisen, die Datenblätter von gleichfarbigen Bildpunktwerten verarbeitet.
Computersystem nach Anspruch 13, wobei mindestens ein Teil des externen Speichers innerhalb des Systemspeichers liegt.
Verfahren, das Folgendes umfasst: das Ermöglichen einer logischen Verbindung mit einer Abnehmerkomponente innerhalb eines Grafikprozessors; das Einlesen einer Reihe von Bildbereichen mit begrenzter Breite aus einem Frame von Bilddaten, wobei jeder der Bildbereiche gemäß einem RGB-Format formatiert ist; das Umformatieren der Serie von Bildbereichen mit begrenzter Breite in Bilddatenblöcke mit derselben Farbkomponente; und, das Weiterleiten der Bilddatenblöcke, die dieselbe Farbkomponente aufweisen, an die Abnehmerkomponente.
Verfahren nach Anspruch 16, des Weiteren umfassend das Verarbeiten der Bilddatenblöcke, die dieselbe Farbe aufweisen, mit einer Anordnung von Ausführungsbahnen, die Eingabeoperanden von einer zweidimensionalen Schieberegistermatrixschaltungsstruktur empfangen und Ausgabeoperanden in dieselbe schreiben.
Verfahren nach Anspruch 17, wobei die zweidimensionale Schieberegistermatrixschaltungsstruktur Bilddatenblätter mit derselben Farbe enthält.
Verfahren nach Anspruch 17, wobei die Abnehmerkomponente eine Zeilenpuffereinheit ist, die den Ausführungsbahnen gleichfarbige Bereiche von Bilddaten zuführt.
Verfahren nach Anspruch 16, wobei die Bildbereiche mit begrenzter Breite in einer Ad-hoc-Weise über den gesamten Bildframe verteilt sind.