DE202017101012U1

DE202017101012U1 - Compilerverwalteter Speicher für Bildprozessor

Info

Publication number: DE202017101012U1
Application number: DE202017101012.0U
Authority: DE
Original assignee: Google LLC
Current assignee: Google LLC
Priority date: 2016-02-26
Filing date: 2017-02-23
Publication date: 2017-05-29
Anticipated expiration: 2027-02-24
Also published as: CN107133908B; TW201737201A; EP3420528B1; CN107133908A; GB2567757B; WO2017147020A1; JP6726752B2; DE102017103764A1; US20170287105A1; GB2576117B; GB2567757A; GB2549578B; EP3420528A1; US20190188824A1; KR20180100374A; TWI628618B; KR102050899B1; GB201820155D0; GB2549578A; GB201912713D0

Abstract

Maschinenlesbares Speichermedium, das einen Programmcode enthält, der bei Verarbeitung durch einen Prozessor bewirkt, dass ein Verfahren ausgeführt wird, wobei das Verfahren das wiederholte Ausführen von Folgendem umfasst: Laden eines nächsten Bilddatenblattes von einem ersten Ort eines Speichers in eine zweidimensionale Schieberegistermatrix, wobei der Speicher lokal mit der zweidimensionalen Schieberegistermatrix und einer Ausführungsbahnmatrix gekoppelt ist, die eine kleinere Abmessung als die zweidimensionale Schieberegistermatrix entlang mindestens einer Matrixachse aufweist, wobei das geladene nächste Bilddatenblatt in einem Bildbereich der zweidimensionalen Schieberegistermatrix bleibt; Bestimmen von Ausgabewerten für das nächste Bilddatenblatt durch Ausführen von Programmcodebefehlen entlang jeweiliger Bahnen der Ausführungsbahnmatrix, wobei eine Schablonengröße, die bei der Bestimmung der Ausgabewerte verwendet wird, nur Bildpunkte umfasst, die innerhalb der zweidimensionalen Schieberegistermatrix liegen; Bewegen eines nächsten Bilddatenblattes, das vollständig in die zweidimensionale Schieberegistermatrix zu laden ist, von einem zweiten Ort des Speichers zu dem ersten Ort des Speichers.

Description

Gebiet der Erfindung
Das Gebiet der Erfindung betrifft im Allgemeinen die Bildverarbeitung und insbesondere einen compilerverwalteten Speicher für einen Bildprozessor.
Allgemeiner Stand der Technik
Die Bildverarbeitung beinhaltet in der Regel die Verarbeitung von Bildpunktwerten, die in einer Matrix angeordnet sind. Hierbei erfasst eine räumlich angeordnete zweidimensionale Matrix die zweidimensionale Beschaffenheit der Bilder (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 Bewegungsbilder zu erfassen. Herkömmliche Bildprozessoren fallen in der Regel unter eines 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 Anwendungssoftware-Entwicklungsplattform bereitstellt, resultiert dessen Verwendung feinerer Datenstrukturen kombiniert mit den zugehörigen Verwaltungsdaten (z. B. Befehlsabruf und -dekodierung, Handhabung von chipinternen und chipexternen Daten, spekulative Ausführung) letztendlich in einem Verbrauch größerer Energiemengen pro Dateneinheit während der Ausführung des 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 Funktionsschaltkreisen 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
Es wird ein Verfahren beschrieben. Das Verfahren beinhaltet das wiederholte Laden eines nächsten Bilddatenblattes von einem ersten Ort eines Speichers in eine zweidimensionale Schieberegistermatrix. Der Speicher ist lokal mit der zweidimensionalen Schieberegistermatrix und einer Ausführungsbahnmatrix gekoppelt, die eine kleinere Abmessung als die zweidimensionale Schieberegistermatrix entlang mindestens einer Matrixachse aufweist. Das geladene nächste Bilddatenblatt bleibt innerhalb eines Bildbereichs der zweidimensionalen Schieberegistermatrix. Das Verfahren beinhaltet zudem das wiederholte Bestimmen von Ausgabewerten für das nächste Bilddatenblatt durch Ausführen von Programmcodebefehlen entlang jeweiliger Bahnen der Ausführungsbahnmatrix, wobei eine Schablonengröße, die bei der Bestimmung der Ausgabewerte verwendet wird, nur Bildpunkte umfasst, die innerhalb der zweidimensionalen Schieberegistermatrix liegen. Das Verfahren beinhaltet zudem das wiederholte Bewegen eines nächsten Bilddatenblattes, das vollständig in die zweidimensionale Schieberegistermatrix zu laden ist, von einem zweiten Ort des Speichers zu dem ersten Ort des Speichers.
Figurenverzeichnis
Die folgende Beschreibung und begleitenden Zeichnungen dienen dazu, Ausführungsformen der Erfindung zu veranschaulichen. In den Zeichnungen:
zeigt 1 eine Ausführungsform einer Bildprozessor-Hardwarearchitektur;
Die 2a, 2b, 2c, 2d und 2e zeigen das Parsen von Bilddaten in eine Zeilengruppe, das Parsen einer Zeilengruppe in ein Blatt und die an einem Blatt mit überlappenden Schablonen durchgeführte Operation;
3a zeigt eine Ausführungsform eines Schablonenprozessors;
3b zeigt eine Ausführungsform eines Befehlswortes des Schablonenprozessors;
4 zeigt eine Ausführungsform einer Datenberechnungseinheit innerhalb eines Schablonenprozessors;
Die 5a, 5b, 5c, 5d, 5e, 5f, 5g, 5h, 5i, 5j und 5k zeigen ein Beispiel für die Verwendung einer zweidimensionalen Verschiebungsmatrix und einer Ausführungsbahnmatrix, um ein Paar angrenzender Ausgangsbildpunktwerte mit überlappenden Schablonen zu bestimmen;
6 zeigt eine Ausführungsform einer Einheitszelle für eine integrierte Ausführungsbahnmatrix und eine zweidimensionale Verschiebungsmatrix;
Die 7a–7c betreffen einen compilerverwalteten Speicherzugriffsansatz für eine Bildprozessor-Datenberechnungseinheit;
8 zeigt ein Speicherzugriffsverfahren für einen Bildprozessor;
Die 9a und 9b betreffen einen Befehl, der verwendet wird, um eine Speicheradresse zu erzeugen;
10 betrifft einen weiteren compilerverwalteten Speicherzugriffsansatz;
11 zeigt eine Ausführungsform eines Computersystems.
Ausführliche Beschreibung
a. Bildprozessor-Hardware-Architektur und -Betrieb
1 zeigt eine Ausführungsform einer Architektur 100 für einen in Hardware implementierten Bildprozessor. Der Bildprozessor 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 1 dargestellt, beinhaltet die Architektur 100 eine Vielzahl von Zeilenpuffereinheiten 101_1 bis 101_M, die mit einer Vielzahl von Schablonenprozessoreinheiten 102_1 bis 102_N und entsprechenden Blattgeneratoreinheiten 103_1 bis 103_N über ein Netzwerk 104 (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 jede Zeilenpuffereinheit mit jedem Blattgenerator und einem entsprechenden Schablonenprozessor über das Netzwerk 104 verbunden sein.
In einer Ausführungsform wird der Programmcode kompiliert und auf einen entsprechenden Schablonenprozessor 102 geladen, um die zuvor von einem Softwareentwickler definierten Bildverarbeitungsoperationen auszuführen (der Programmcode kann je nach Design und Implementierung auch auf den zugehörigen Blattgenerator des Schablonenprozessors 103 geladen werden). In zumindest einigen Fällen kann eine Bildverarbeitungspipeline realisiert werden, indem ein erstes Kernprogramm für eine erste Pipelinephase in einen ersten Schablonenprozessor 102_1 geladen, ein zweites Kernprogramm für eine zweite Pipelinephase in einen zweiten Schablonenprozessor 102_2, geladen wird usw., wobei das erste Kernsystem die Funktionen der ersten Pipelinephase durchführt, das zweite Kernsystem die Funktionen der zweiten Pipelinephase durchführt usw., und zusätzliche Steuerflussverfahren installiert werden, um Ausgabebilddaten von einer Pipelinephase zur nächsten Pipelinephase zu leiten.
In anderen Konfigurationen kann der Bildprozessor als eine parallele Maschine realisiert sein, die zwei oder mehr Schablonenprozessoren 102_1, 102_2 aufweist, die auf demselben Kernprogrammcode 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 Steuerfluss-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 105 empfangen und zu einer oder mehreren der Zeilenpuffereinheiten 101 auf einer Frame-per-Frame-Basis übermittelt. 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 104 zu einem bestimmten Blattgenerator. 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 Blattgenerator parst ferner die Zeilengruppe von Bilddaten in einen kleineren Bereich von Bilddaten, der als „Blatt” bezeichnet wird, und präsentiert das Blatt seinem entsprechenden Schablonenprozessor.
Im Falle einer Bildverarbeitungspipeline oder eines DAG-Ablaufs mit einem einzigen Eingang werden im Allgemeinen Eingabeframes an die gleiche Zeilenpuffereinheit 101_1 geleitet, die die Bilddaten in Zeilengruppen parst und die Zeilengruppen zu dem Blattgenerator 103_1 leitet, dessen entsprechender Schablonenprozessor 102_1 den Code des ersten Kernsystems in der Pipeline/dem DAG ausführt. Nach Beendigung der Operationen durch den Schablonenprozessor 102_1 an den von ihm verarbeiteten Zeilengruppen sendet der Blattgenerator 103_1 Ausgabezeilengruppen an eine „nachgelagerten” Zeilenpuffereinheit 101_2 (in manchen Anwendungsfällen kann die Ausgabezeilengruppe zurück an die gleiche Zeilenpuffereinheit 101_1 gesendet werden, die zuvor die Eingabezeilengruppen gesendet hatte).
Ein oder mehrere „Abnehmerkernsysteme”, die die nächste Phase/Operation in der Pipeline/dem DAG darstellen, die auf deren eigenen jeweiligen anderen Blattgenerator und Schablonenprozessor (z. B. Blattgenerator 103_2 und Schablonenprozessor 102_2) ausführt werden, empfangen anschließend die von dem ersten Schablonenprozessor 102_1 erzeugten Bilddaten von der nachgelagerten Zeilenpuffereinheit 101_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äß des Designs der gesamten Pipeline oder des DAGs ausführt.
Ein Schablonenprozessor 102 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 Blattes. Hier arbeiten innerhalb eines Schablonenprozessors 102 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, Blätter von Bilddaten in eine zweidimensionale Registermatrixstruktur innerhalb des Schablonenprozessors 102 geladen. Es wird davon ausgegangen, dass die Verwendung von Blättern und die zweidimensionale Registermatrixstruktur für effektive Energieverbrauchsverbesserungen sorgen, indem eine große Datenmenge in einen großen Registerbereich bewegt wird, so wird beispielsweise eine einzelne Ladeoperation mit direkt an den Daten ausgeführten Verarbeitungsschritten unmittelbar danach durch eine Ausführungsbahnmatrix durchgeführt. Zudem stellt die Verwendung einer Ausführungsbahnmatrix und einer entsprechenden Registermatrix verschiedene Schablonengrößen bereit, die leicht programmierbar/konfigurierbar sind.
Die 2a bis 2e veranschaulichen umfassend Ausführungsformen sowohl der Parsing-Aktivität einer Zeilenpuffereinheit 101 als auch der feineren Parsing-Aktivität einer Blattgeneratoreinheit 103 sowie der Schablonenverarbeitungsaktivität des Schablonenprozessors 102, der mit der Blatterzeugereinheit 103 gekoppelt ist.
2a zeigt eine Ausführungsform eines Eingabeframes der Bilddaten 201. 2a zeigt zudem einen Umriss drei überlappender Schablonen 202 (die jeweils eine Abmessung von 3 Bildpunkten × 3 Bildpunkten aufweisen), für deren Betrieb ein Schablonenprozessor ausgelegt ist. Der Ausgabebildpunkt, für den jede Schablone jeweils die Ausgabebilddaten erzeugt, wird in schwarzer Farbe hervorgehoben. Der Einfachheit halber sind die drei überlappenden Schablonen 202 nur in vertikaler Richtung überlappend dargestellt. Es ist relevant, zu erkennen, dass ein Schablonenprozessor in Wirklichkeit so ausgelegt sein kann, dass dieser sowohl in vertikaler als auch in horizontaler Richtung überlappende Schablonen aufweist.
Aufgrund der vertikalen überlappenden Schablonen 202 innerhalb des Schablonenprozessors, wie in 2a dargestellt, gibt es ein breites Band von Bilddaten innerhalb des Frames, das ein einzelner Schablonenprozessor betreiben kann. Wie nachfolgend näher beschrieben, verarbeiten die Schablonenprozessoren in einer Ausführungsform innerhalb ihrer überlappenden Schablonen Daten von links nach rechts über alle Bilddaten (und wiederholen den Vorgang dann für die nächste Gruppe von Zeilen in der Reihenfolge von oben nach unten). Somit nimmt, während die Schablonenprozessoren mit ihrer Operation fortfahren, die Anzahl der schwarzen Ausgabebildpunktblöcke horizontal nach rechts zu. Wie oben erwähnt, ist eine Zeilenpuffereinheit 101 für das Parsen einer Zeilengruppe von Eingabebilddaten aus einem eingehenden Frame verantwortlich, der für die Schablonenprozessoren ausreichend ist, um eine erweiterte Anzahl anstehender Zyklen zu betreiben. Eine exemplarische Darstellung einer Zeilengruppe ist als schattierter Bereich 203 dargestellt. In einer Ausführungsform kann die Zeilenpuffereinheit 101 unterschiedliche Dynamiken zum Senden/Empfangen einer Zeilengruppe an einen/von einem Blattgenerator umfassen. Beispielsweise werden gemäß einem Modus, der als „vollständige Gruppe” bezeichnet wird, die gesamten Bilddatenzeilen mit voller Breite zwischen einer Zeilenpuffereinheit und einem Blattgenerator übermittelt. Gemäß einem zweiten Modus, der als „virtuell groß” bezeichnet wird, wird eine Zeilengruppe zunächst mit einer Teilmenge 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 203 der Eingabebilddaten durch die Zeilenpuffereinheit definiert und an die Blattgeneratoreinheit übermittelt worden ist, parst die Blattgeneratoreinheit die Zeilengruppe ferner in feinere Blä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 innerhalb ihrer eigenen jeweiligen Schablone an Daten 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 Blätter Oberflächenbereiche von Eingabebilddaten, die die zweidimensionale Schieberegistermatrix „ausfüllen” oder anderweitig in dieselbe geladen werden.
Wie nachfolgend näher beschrieben, gibt es in verschiedenen Ausführungsformen tatsächlich mehrere Schichten von zweidimensionalen Registerdaten, die bei jedem Zyklus verschoben werden können. Zur Vereinfachung verwendet ein Großteil der vorliegenden Beschreibung einfach den Begriff „zweidimensionales Schieberegister” und dergleichen, um auf Strukturen zu verweisen, die eine oder mehrere dieser Schichten zweidimensionaler Registerdaten aufweisen, die verschoben werden können.
Wie in 2b dargestellt, parst der Blattgenerator ein Anfangsblatt 204 von der Zeilengruppe 203 und stellt es dem Schablonenprozessor zur Verfügung (hier entspricht das Datenblatt dem schattierten Bereich, der im Allgemeinen mit der Bezugsnummer 204 gekennzeichnet ist). Wie in den 2c und 2d dargestellt, arbeitet der Schablonenprozessor an dem Blatt der eingegebenen Bilddaten durch effektives Bewegen der überlappenden Schablonen 202 von links nach rechts über das Blatt. Wie in 2d ist die Anzahl der Bildpunkte, für die ein Ausgabewert aus den Daten innerhalb des Blattes berechnet werden könnte, erschöpft (keine anderen Bildpunktpositionen können einen Ausgabewert haben, der aus den Informationen innerhalb des Blattes bestimmt wird). Zur Vereinfachung wurden die Randbereiche des Bildes ignoriert.
Wie in 2e dargestellt, liefert der Blattgenerator dann ein nächstes Blatt 205 für den Schablonenprozessor, um die Operationen fortzusetzen. Zu beachten ist, dass die Anfangspositionen der Schablonen, wenn sie mit der Operation an dem nächsten Blatt beginnen, der nächsten Progression (wie zuvor in 2d dargestellt) vom Erschöpfungspunkt nach rechts auf dem ersten Blatt entsprechen. Mit dem neuen Blatt 205 bewegen sich die Schablonen einfach weiter nach rechts, während der Schablonenprozessor auf dem neuen Blatt auf die gleiche Weise arbeitet wie bei der Verarbeitung des ersten Blattes.
Zu beachten ist, dass zwischen den Daten des ersten Blattes 204 und den Daten des zweiten Blattes 205 aufgrund der Randbereiche der Schablonen, die einen Ausgabebildpunktort umgeben, eine gewisse Überlappung vorliegt. Die Überlappung könnte einfach gehandhabt werden, indem der Blattgenerator die überlappenden Daten zweimal überträgt. In alternativen Implementierungen kann, um dem Schablonenprozessor ein nächstes Blatt zuzuführen, der Blattgenerator damit fortfahren, ausschließlich neue Daten an den Schablonenprozessor zu senden, während der Schablonenprozessor die überlappenden Daten aus dem vorhergehenden Blatt verwendet.
b. Schablonenprozessordesign und -betrieb
3a zeigt eine Ausführungsform einer Schablonenprozessorarchitektur 300. Wie in 3a dargestellt, beinhaltet der Schablonenprozessor eine Datenberechnungseinheit 301, einen Skalarprozessor 302 und einen zugehörigen Speicher 303, sowie eine E-/A-Einheit 304. Die Datenberechnungseinheit 301 beinhaltet eine Matrix von Ausführungsbahnen 305, eine zweidimensionale Verschiebungsmatrixstruktur 306 und getrennte Direktzugriffsspeicher 307, die mit bestimmten Zeilen oder Spalten der Matrix verbunden sind.
Die E-/A-Einheit 304 ist verantwortlich für das Laden von „eingegebenen” Datenblättern, die von dem Blattgenerator empfangen wurden, in die Datenberechnungseinheit 301, sowie das Speichern der von dem Schablonenprozessor „ausgegebenen” Blätter im Blattgenerator. In einer Ausführungsform umfasst das Laden von Blattdaten in die Datenberechnungseinheit 301 das Parsen eines empfangenen Blattes in die Zeilen/Spalten der Bilddaten sowie das Laden der Zeilen/Spalten der Bilddaten in die zweidimensionale Schieberegisterstruktur 306 oder in die jeweiligen Direktzugriffsspeicher 307 der Zeilen/Spalten der Ausführungsbahnmatrix (wie nachfolgend näher beschrieben). Wird das Blatt anfänglich in die Speicher 307 geladen, können die einzelnen Ausführungsbahnen innerhalb der Ausführungsbahnmatrix 305 dann die Blattdaten, sofern geeignet (z. B. als Ladebefehl kurz vor der Operation der Blattdaten), in die zweidimensionale Schieberegisterstruktur 306 der Direktzugriffsspeicher 307 laden. Nach Beendigung des Ladens eines Datenblattes in die Registerstruktur 306 (ob direkt aus einem Blattgenerator oder aus den Speichern 307) arbeiten die Ausführungsbahnen der Ausführungsbahnmatrix 305 an den Daten und „schreiben” letztendlich die fertigen Daten als ein Blatt direkt „zurück” in den Blattgenerator oder in die Direktzugriffsspeicher 307. Im letzteren Fall ruft die E/A-Einheit 304 die Daten aus den Direktzugriffsspeichern 307 ab, um ein Ausgabeblatt zu bilden, das dann an den Blattgenerator weitergeleitet wird.
Der Skalarprozessor 302 beinhaltet einen Programmcontroller 309, der die Befehle des Programmcodes des Schablonenprozessors aus dem Skalarspeicher 303 liest und die Befehle an die Ausführungsbahnen in der Ausführungsbahnmatrix 305 ausgibt. In einer Ausführungsform wird ein einzelner Befehl auf alle Ausführungsbahnen innerhalb der Matrix 305 übertragen, um ein SIMD-ähnliches Verhalten der Datenberechnungseinheit 301 zu bewirken. In einer Ausführungsform beinhaltet das Befehlsformat der Befehle, die aus dem Skalarspeicher 303 gelesen und an die Ausführungsbahnen der Ausführungsbahnmatrix 305 ausgegeben werden, ein sehr langes Befehlswortformat (VLIW), welches mehr als einen Operationscode pro Befehl beinhaltet. In einer weiteren Ausführungsform beinhaltet das VLIW-Format sowohl einen ALU-Operationscode, der eine mathematische Funktion anweist, die von der ALU einer Ausführungsbahn ausgeführt wird (wobei, wie nachstehend beschrieben, in einer Ausführungsform mehr als eine herkömmliche ALU-Operation angegeben sein kann), als auch einen Speicheroperationscode (der eine Speicheroperation für eine spezifische Ausführungsbahn oder eine Gruppe von Ausführungsbahnen anweist).
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 beinhalten, 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 305) implementiert werden.
Die Kombination einer Ausführungsbahnmatrix 305, eines Programmcontrollers 309 und einer zweidimensionalen Schieberegisterstruktur 306 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 Abmessungen (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 eines beliebigen Ausgabematrixorts zuzugreifen.
Abgesehen davon, dass sie als Datenspeicher für Bilddaten genutzt werden, die durch die Ausführungsbahnmatrix 305 betrieben werden, können die Direktzugriffsspeicher 307 zudem eine oder mehrere Nachschlagetabellen beibehalten. In verschiedenen Ausführungsformen können eine oder mehrere skalare Nachschlagetabellen auch innerhalb des skalaren Speichers 303 instanziiert werden.
Ein skalarer Nachschlagevorgang beinhaltet das Übermitteln desselben Datenwertes aus derselben Nachschlagetabelle von demselben Index an sämtliche Ausführungsbahnen innerhalb der Ausführungsbahnmatrix 305. In verschiedenen Ausführungsformen wird das oben beschriebene VLIW-Befehlsformat erweitert, um auch einen skalaren Operationscode einzuschließen, der eine vom Skalarprozessor ausgeführte Nachschlageoperation in eine skalare Nachschlagetabelle leitet. Der für die Verwendung mit dem Operationscode angegebene Index kann ein unmittelbarer Operand sein oder von einem anderen Datenspeicherort abgerufen werden. Unabhängig davon umfasst in einer Ausführungsform ein Nachschlagevorgang in einer skalaren Nachschlagetabelle innerhalb des skalaren Speichers im Wesentlichen das Senden desselben Datenwertes an alle Ausführungsbahnen innerhalb der Ausführungsbahnmatrix 305 während desselben Taktzyklus. Weitere Details zur Verwendung und Operation von Nachschlagetabellen werden nachfolgend bereitgestellt.
3b fasst die oben beschriebenen VLIW-Befehlswort-Ausführungsformen zusammen. Wie in 3b dargestellt, beinhaltet das VLIW-Befehlswortformat Felder für drei separate Befehle: 1) einen Skalarbefehl 351, der durch den Skalarprozessor ausgeführt wird; 2) einen ALU-Befehl 352, der von den jeweiligen ALUs innerhalb der Ausführungsbahnmatrix an SIMD-Weise gesendet und ausgeführt wird; und 3) einen Speicherbefehl 353, der auf partielle SIMD-Weise gesendet und ausgeführt wird (z. B. wenn Ausführungsbahnen entlang derselben Zeile in der Ausführungsbahnmatrix einen gleichen Direktzugriffsspeicher teilen, anschließend wird der Befehl von einer Ausführungsbahn aus jeder der verschiedenen Zeilen tatsächlich ausgeführt (das Format des Speicherbefehls 353 kann einen Operanden beinhalten, der identifiziert, von welcher Ausführungsbahn aus jeder Zeile der Befehl ausgeführt wird).
Ein Feld 354 für einen oder mehrere unmittelbare Operanden ist ebenfalls enthalten. Welche der Befehle 351, 352, 353 welche unmittelbaren Operandeninformationen verwenden, kann im Befehlsformat identifiziert sein. Jeder der Befehle 351, 352, 353 beinhaltet zudem seine eigenen Eingabeoperanden sowie resultierende Informationen (z. B. lokale Register für ALU-Operationen und ein lokales Register sowie eine Speicheradresse für Speicherzugriffsbefehle). In einer Ausführungsform wird der Skalarbefehl 351 durch den Skalarprozessor ausgeführt, bevor die Ausführungsbahnen innerhalb der Ausführungsbahnmatrix einen der anderen Befehle 352, 353 ausführen. Das heißt, die Ausführung des VLIW-Wortes beinhaltet einen ersten Zyklus, bei dem der Skalarbefehl 351 ausgeführt wird, gefolgt von einem zweiten Zyklus, bei dem die anderen Befehle 352, 353 ausgeführt werden können (ist ist zu beachten, dass in verschiedenen Ausführungsformen die Befehle 352 und 353 parallel ausgeführt werden können).
In einer Ausführungsform beinhalten die Skalarbefehle, die von dem Skalarprozessor ausgeführt werden, Befehle, die an den Blattgenerator ausgegeben werden, um Blätter von/in die Speicher oder 2D-Schieberegister der Datenberechnungseinheit zu laden/zu speichern. Hier kann der Betrieb des Blattgenerators von der Operation der Zeilenpuffereinheit oder von anderen Variablen abhängig sein, die ein Vorlaufzeitverständnis der Anzahl von Zyklen verhindern, die der Blattgenerator ausführen wird, um einen Befehl zu beenden, der von dem Skalarprozessor ausgegeben wird. Dementsprechend beinhaltet in einer Ausführungsform jedes beliebige VLIW-Wort, dessen Skalarbefehl 351 dem Befehlsblockgenerator entspricht oder anderweitig einen Befehl ausgibt, auch Nicht-Operations-(NOOP-)Befehle in den anderen zwei Befehlsfeldern 352, 353. Der Programmcode gibt dann eine Schleife von NOOP-Befehlen für Befehlsfelder 352, 353 ein, bis der Blattgenerator seine Ladung von/Speicherung unter der Datenberechnungseinheit beendet. Hier kann bei der Ausgabe eines Befehls an den Blattgenerator der Skalarprozessor ein Bit eines Verriegelungsregisters setzen, das der Blattgenerator nach Beendigung des Befehls zurücksetzt. Während der NOOP-Schleife überwacht der Skalarprozessor das Bit des Verriegelungsbits. Sobald der Skalarprozessor erkennt, dass der Blattgenerator seinen Befehl beendet hat, beginnt die normale Ausführung erneut.
4 zeigt eine Ausführungsform einer Datenberechnungskomponente 401. Wie in 4 dargestellt, beinhaltet die Datenberechnungskomponente 401 eine Matrix von Ausführungsbahnen 405, die logisch „oberhalb” einer zweidimensionalen Schieberegistermatrixstruktur 406 positioniert sind. Wie oben beschrieben, wird in verschiedenen Ausführungsformen ein von einem Blattgenerator bereitgestelltes Bilddatenblatt in das zweidimensionale Schieberegister 406 geladen. Die Ausführungsbahnen arbeiten dann an den Blattdaten aus der Registerstruktur 406.
Die Ausführungsbahnmatrix 405 und die Schieberegisterstruktur 406 sind in Bezug zueinander fixiert. Die Daten innerhalb der Schieberegistermatrix 406 verschieben sich jedoch in einer strategischen und koordinierten Weise, um zu bewirken, dass jede Ausführungsbahn in der Ausführungsbahnmatrix eine andere Schablone innerhalb der Daten verarbeitet. Demgemäß bestimmt jede Ausführungsbahn den Ausgabebildwert für einen anderen Bildpunkt in dem erzeugten Ausgabeblatt. Aus der Architektur von 4 sollte klar sein, dass überlappende Schablonen nicht nur vertikal, sondern auch horizontal angeordnet sind, da die Ausführungsbahnmatrix 405 vertikal angrenzende Ausführungsbahnen sowie horizontal angrenzende Ausführungsbahnen aufweist.
Einige zu beachtende architektonische Merkmale der Datenberechnungseinheit 401 beinhalten die Schieberegisterstruktur 406, die breitere Abmessungen als die Ausführungsbahnmatrix 405 aufweist. Das heißt, es gibt einen „Ring” von Registern 409 außerhalb der Ausführungsbahnmatrix 405. Obwohl der Ring 409 auf zwei Seiten der Ausführungsbahnmatrix dargestellt ist, kann der Ring je nach Implementierung auf weniger (einer) oder mehr (drei oder vier) Seiten der Ausführungsbahnmatrix 405 existieren. Der Ring 405 dient dazu, einen „Überlaufraum” für Daten bereitzustellen, die außerhalb der Grenzen der Ausführungsbahnmatrix 405 überlaufen, wenn die Daten „unterhalb” der Ausführungsbahnen 405 verschoben werden. In einem einfachen Fall benötigt eine 5 × 5-Schablone, die am rechten Rand der Ausführungsbahnmatrix 405 zentriert ist, vier Ringregisterorte weiter nach rechts, wenn die linksseitigen Bildpunkte der Schablone verarbeitet werden. Zur Vereinfachung der Zeichnung zeigt 4 die Register der rechten Seite des Rings mit nur horizontalen Schiebeverbindungen und Registern der Unterseite des Rings, da nur vertikale Schiebeverbindungen vorhanden sind, wenn in einer nominalen Ausführungsform die Register auf beiden Seiten (rechts, unten) sowohl horizontale als auch vertikale Verbindungen aufweisen würden.
Zusätzlicher Überlaufraum wird durch Direktzugriffsspeicher 407 bereitgestellt, die mit jeder Zeile und/oder jeder Spalte in der Matrix oder Teilen davon gekoppelt sind (z. B. kann ein Direktzugriffsspeicher einer „Region” der Ausführungsbahnmatrix zugewiesen werden, die reihenweise 4 Ausführungsbahnen und spaltenweise 2 Ausführungsbahnen überspannt. Zur Vereinfachung bezieht sich der Rest der Anwendung hauptsächlich auf zeilen- und/oder spaltenbasierte Zuordnungsschemen). Wenn die Kernsystemoperationen einer Ausführungsbahn es erfordern, Bildpunktwerte außerhalb der zweidimensionalen Schieberegistermatrix 406 zu verarbeiten (was einige Bildverarbeitungsroutinen ggf. erfordern), kann die Ebene der Bilddaten z. B. vom Ringbereich 409 in den Direktzugriffsspeicher 407 weiter überlaufen. Betrachten wir zum Beispiel eine 6 × 6-Schablone, bei der die Hardware einen Ringbereich von nur vier Speicherelementen rechts von einer Ausführungsbahn am rechten Rand der Ausführungsbahnmatrix beinhaltet. In diesem Fall müssten die Daten vom rechten Rand des Rings 409 weiter nach rechts verschoben werden, um die Schablone vollständig zu verarbeiten. Daten, die außerhalb des Ringbereichs 409 verschoben werden, würden dann in den Direktzugriffsspeicher 407 überlaufen. Andere Anwendungen der Direktzugriffsspeicher 407 und des Schablonenprozessors aus 3 werden nachfolgend bereitgestellt.
Die 5a bis 5k zeigen ein Ausführungsbeispiel für die Art und Weise, in der die Bilddaten, wie oben angedeutet, innerhalb der zweidimensionalen Schieberegistermatrix „unterhalb” der Ausführungsbahnmatrix verschoben werden. Wie in 5a dargestellt, sind die Dateninhalte der zweidimensionalen Verschiebungsmatrix in einer ersten Matrix 507 dargestellt, während die Ausführungsbahnmatrix durch ein Frame 505 dargestellt ist. Außerdem sind innerhalb der Ausführungsbahnmatrix vereinfacht zwei angrenzende Ausführungsbahnen 510 dargestellt. In dieser vereinfachten Darstellung 510 beinhaltet jede Ausführungsbahn ein Register R1, das Daten aus dem Schieberegister akzeptieren kann, Daten von einer ALU-Ausgabe akzeptieren (z. B. sich durch Zyklen als Akkumulator verhalten) kann oder Ausgabedaten in ein Ausgabeziel schreiben kann.
Jede Ausführungsbahn verfügt zudem in einem lokalen Register R2 über den Inhalt „darunter” in der zweidimensionalen Verschiebungsmatrix. Somit ist R1 ein physisches Register der Ausführungsbahn, während R2 ein physisches Register der zweidimensionalen Schieberegistermatrix ist. Die Ausführungsbahn beinhaltet eine ALU, die mit Operanden arbeiten kann, die von R1 und/oder R2 bereitgestellt werden. Wie weiter nachfolgend näher beschrieben wird, wird in einer Ausführungsform das Schieberegister tatsächlich mit mehreren (einer „Tiefe” von) Speicher-/Registerelementen pro Matrixort implementiert, die Verschiebungsaktivität ist jedoch auf eine Ebene von Speicherelementen begrenzt (z. B. kann sich nur eine Ebene von Speicherelementen pro Zyklus verschieben). Die 5a bis 5k stellen eine dieser tieferen Registerorte dar, wie sie verwendet werden, um das resultierende X aus den jeweiligen Ausführungsbahnen zu speichern. Zur Veranschaulichung wird das tiefere resultierende Register neben anstatt unter dessen Gegenstückregister R2 gezogen.
Die 5a bis 5k konzentrieren sich auf die Berechnung von zwei Schablonen, deren zentrale Position mit dem Paar von Ausführungsbahnpositionen 511 ausgerichtet ist, die in der Ausführungsbahnmatrix dargestellt sind. Zur Vereinfachung der Darstellung wird das Paar von Ausführungsbahnen 510 als horizontal aneinander angrenzend gezeichnet, obgleich sie nach dem folgenden Beispiel tatsächlich vertikal aneinander angrenzend sind.
Wie anfangs in 5a dargestellt, sind die Ausführungsbahnen auf deren zentralen Schablonenorte zentriert. 5b zeigt den Objektcode, der von beiden Ausführungsbahnen ausgeführt wird. Wie in 5b dargestellt, bewirkt der Programmcode beider Ausführungsbahnen, dass sich die Daten innerhalb der Schieberegistermatrix eine Position nach unten und eine Position nach rechts verschieben. Damit werden beide Ausführungsbahnen an der oberen linken Ecke ihrer jeweiligen Schablonen ausgerichtet. Der Programmcode bewirkt dann, dass sich die Daten (in R2) an ihren jeweiligen Stellen in R1 laden lassen.
Wie in 5c dargestellt, bewirkt der Programmcode als Nächstes, dass das Paar von Ausführungsbahnen die Daten innerhalb der Schieberegistermatrix um eine Einheit nach links verschiebt, wodurch bewirkt wird, dass der Wert rechts von der jeweiligen Position der jeweiligen Ausführungsbahn in die jeweilige Position der Ausführungsbahn verschoben wird. Der Wert in R1 (vorheriger Wert) wird dann mit dem neuen Wert addiert, der sich in die Position der Ausführungsbahn (in R2) verschoben hat. Das Ergebnis wird in R1 geschrieben. Wie in 5d dargestellt, wird der gleiche Prozess wie oben für 5c wiederholt, wodurch bewirkt wird, dass das Ergebnis R1 nun den Wert A + B + C in der oberen Ausführungsbahn und F + G + H in der unteren Ausführungsbahn beinhaltet. Zu diesem Zeitpunkt haben beide Ausführungsbahnen die obere Reihe ihrer jeweiligen Schablonen verarbeitet. Zu beachten ist der Überlauf in einen Ringbereich auf der linken Seite der Ausführungsbahnmatrix (falls einer auf der linken Seite existiert) oder in einen Direktzugriffsspeicher, wenn auf der linken Seite der Ausführungsbahnmatrix kein Ringbereich existiert.
Wie in 5e dargestellt, bewirkt der Programmcode als Nächstes, dass sich die Daten innerhalb der Schieberegistermatrix eine Einheit nach oben verschieben, wodurch bewirkt wird, dass beide Ausführungsbahnen am rechten Rand der mittleren Reihe ihrer jeweiligen Schablonen ausgerichtet sind. Register R1 der beiden Ausführungsbahnen beinhaltet derzeit die Summe der oberen Zeile der Schablone und den rechten Wert der mittleren Zeile. Die 5f und 5g zeigen weitere Fortschritte beim Bewegen über die mittlere Reihe der beiden Schablonen der Ausführungsbahn nach links. Die kumulative Addition setzt sich fort, sodass am Ende der Verarbeitung von 5g beide Ausführungsbahnen die Summe der Werte der obersten Reihe und der mittleren Reihe ihrer jeweiligen Schablonen beinhalten.
5h zeigt eine weitere Verschiebung, um jede Ausführungsbahn an der nächsten Zeile ihrer entsprechenden Schablonen auszurichten. Die 5i und 5j zeigen eine fortlaufende Verschiebung zur vollständigen Verarbeitung über den Verlauf der Schablonen der beiden Ausführungsbahnen. 5k zeigt eine zusätzliche Verschiebung, um jede Ausführungsbahn an ihrer korrekten Position im Datenfeld auszurichten und das Ergebnis in dasselbe zu schreiben.
In dem Beispiel aus 5a–5k ist zu beachten, dass der Objektcode für die Verschiebungsoperationen ein Befehlsformat beinhalten kann, das die Richtung und die Größe der in (X, Y)-Koordinaten ausgedrückten Verschiebung identifiziert. Der Objektcode für eine Verschiebung um eine Position nach oben kann im Objektcode beispielsweise als SHIFT 0, +1 ausgedrückt werden. Als weiteres Beispiel kann eine Verschiebung um eine Position nach rechts im Objektcode als SHIFT +1, 0 ausgedrückt werden. Darüber hinaus können in verschiedenen Ausführungsformen Verschiebungen größerer Größe im Objektcode (z. B. SHIFT 0, +2) spezifiziert werden. Wenn die 2D-Schieberegister-Hardware hier nur Verschiebungen um eine Position pro Zyklus unterstützt, kann der Befehl der Maschine so interpretiert werden, dass eine Mehrfachzyklus-Ausführung erfordert wird, oder die 2D-Schieberegister-Hardware kann so ausgelegt sein, dass sie Verschiebungen um mehr als eine Position pro Zyklus unterstützt. Ausführungsformen der letzteren Variante werden nachfolgend näher beschrieben.
6a zeigt eine weitere, detailliertere Darstellung der Einheitszelle für die Ausführungsbahnmatrix und die Schieberegisterstruktur (Register im Ringbereich beinhalten keine entsprechende Ausführungsbahn). Die Ausführungsbahn und der Registerbereich, die jeder Position in der Ausführungsbahnmatrix zugeordnet sind, werden in einer Ausführungsform implementiert, indem der in 6a ersichtliche Schaltkreis an jedem Knoten der Ausführungsbahnmatrix instanziiert wird. Wie in 6a dargestellt, beinhaltet die Einheitszelle eine Ausführungsbahn 601, die mit einer Registerdatei 602 gekoppelt ist, die aus vier Registern R2 bis R5 besteht. Während eines Zyklus kann die Ausführungsbahn 601 von einem Register R1 bis R5 lesen oder in diese schreiben. Für Befehle, die zwei Eingangsoperanden erfordern, kann die Ausführungsbahn beide Operanden von einem beliebigen R1 bis R5 abrufen.
In einer Ausführungsform wird die zweidimensionale Schieberegisterstruktur implementiert, indem es während eines einzigen Zyklus erlaubt wird, dass der Inhalt eines beliebigen (nur) eines der Register R2 bis R4 zu einer seiner angrenzenden Registerdateien durch den Ausgangsmultiplexer 603 „heraus” verschoben wird, und der Inhalt eines beliebigen von (nur) eines der Register R2 bis R4 durch den Inhalt ersetzt wird, der von einem entsprechenden Nachbarn durch den Eingangsmultiplexer 604 „hinein” verschoben wird, sodass Verschiebungen zwischen den Nachbarn in gleicher Richtung (z. B. alle Ausführungsbahnen nach links, alle Ausführungsbahnen nach rechts usw.) erfolgen. Obwohl es für ein gleiches Register üblich sein kann, dass sein Inhalt verschoben und durch den Inhalt ersetzt wird, der in demselben Zyklus verschoben wird, erlaubt die Multiplexeranordnung 603, 604 unterschiedliche Schiebequellen- und Schiebezielregister innerhalb einer gleichen Registerdatei während eines gleichen Zyklus.
Wie in 6a dargestellt, ist zu beachten, dass während einer Verschiebungssequenz eine Ausführungsbahn den Inhalt aus ihrer Registerdatei 602 zu deren jeweiligen linken, rechten, oberen und unteren Nachbarn verschiebt. In Verbindung mit derselben Verschiebungssequenz verschiebt die Ausführungsbahn zudem den Inhalt in deren Registerdatei von einem bestimmten seiner linken, rechten, oberen und unteren Nachbarn. Das Heraus-Verschiebungsziel und die Herein-Verschiebungsquelle sollten wiederum mit einer gleichen Verschiebungsrichtung für alle Ausführungsbahnen übereinstimmen (wenn z. B. die Verschiebung heraus zum rechten Nachbarn erfolgt, sollte die Verschiebung herein vom linken Nachbarn erfolgen).
Obwohl in einer Ausführungsform der Inhalt von nur einem Register pro Ausführungsbahn pro Zyklus verschoben werden darf, können andere Ausführungsformen zulassen, dass der Inhalt von mehr als einem Register herein-/herausverschoben wird. Beispielsweise kann der Inhalt von zwei Registern während eines gleichen Zyklus heraus/herein verschoben werden, wenn eine zweite Instanz der in 6a beobachteten Multiplexerschaltung 603, 604 in das Design von 6a eingefügt wird. Selbstverständlich können bei Ausführungsformen, bei denen der Inhalt von nur einem Register pro Zyklus verschoben werden kann, Verschiebungen von mehreren Registern zwischen mathematischen Operationen stattfinden, indem mehr Taktzyklen für Verschiebungen zwischen mathematischen Operationen verbraucht werden (z. B. kann der Inhalt von zwei Registern zwischen mathematischen Operationen verschoben werden, indem zwei Verschiebungsoperationen zwischen den mathematischen Operationen verbraucht werden).
Falls weniger als der gesamte Inhalt der Registerdateien einer Ausführungsbahn während einer Verschiebungssequenz verschoben wird, ist zu beachten, dass der Inhalt der nicht verschobenen Register jeder Ausführungsbahn an Ort und Stelle bleibt (nicht verschoben wird). Dementsprechend bleibt jeder nicht verschobene Inhalt, der nicht durch verschobenen Inhalt ersetzt wird, durch den Verschiebungszyklus hinweg lokal auf der Ausführungsbahn. Die in jeder Ausführungsbahn beobachtete Speichereinheit („M”) wird verwendet, um Daten von/zu dem Direktzugriffsspeicher zu laden/zu speichern, der mit der Zeile und/oder Spalte der Ausführungsbahn innerhalb der Ausführungsbahnmatrix Verbunden ist. Hier fungiert die M-Einheit als Standard-M-Einheit, indem sie häufig zum Laden/Speichern von Daten verwendet wird, die nicht von/in den eigenen Registerbereich der Ausführungsbahn geladen/gespeichert werden können. In verschiedenen Ausführungsformen besteht die primäre Operation der M-Einheit darin, Daten von einem lokalen Register in den Speicher zu schreiben und Daten aus dem Speicher zu lesen und in ein lokales Register zu schreiben.
In Bezug auf die von der ALU-Einheit der Hardware-Ausführungsbahn 601 unterstützten ISA-Operationscodes sind in verschiedenen Ausführungsformen die von der Hardware-ALU unterstützten mathematischen Operationscodes integral (d. h. im Wesentlichen gleich) mit den von den unterstützten mathematischen Operationscodes verbunden, die eine virtuelle Ausführungsbahn unterstützen (z. B. ADD, SUB, MOV, MUL, MAD, ABS, DIV, SHL, SHR, MIN/MAX, SEL, ODER, XOR, NOT). Wie oben beschrieben, können Speicherzugriffsbefehle von der Ausführungsbahn 601 ausgeführt werden, um Daten von/zu ihrem zugehörigen Direktzugriffsspeicher abzurufen/zu speichern. Zudem unterstützt die Hardware-Ausführungsbahn 601 Verschiebungsoperationen (nach rechts, links, oben, unten), um Daten innerhalb der zweidimensionalen Schieberegisterstruktur zu verschieben. Wie oben beschrieben, werden Programmsteuerbefehle weitgehend durch den Skalarprozessor des Schablonenprozessors ausgeführt.
c. Compilerverwalteter Schablonen-Prozessorspeicher
Unter erneuter Bezugnahme auf 4, wird an die Existenz eines Ringbereichs der Register 409 erinnert, der sich in der spezifischen Ausführungsform aus 4 um den rechten und unteren Rand der Ausführungsbahnmatrix 405 herum befindet (andere Ausführungsformen können Ringregister auf mehr oder weniger Seiten der Ausführungsbahnmatrix beinhalten). In den vorangegangenen Erörterungen wurde ein „Blatt” als eine Matrix von Bildinformationen verstanden, die den internen Schieberegisterbereich verbrauchte, der die Abmessungen der Ausführungsbahnmatrix 405 aufweist. In verschiedenen Ausführungsformen beinhalten die Registerorte im Ring 409 hier keine zugeordneten ALU-Einheiten zum Ausführen von Bildverarbeitungsbefehlen an den Bilddaten – vielmehr dient der Ringbereich 409 beispielsweise dazu, „Überlauf”-Daten von der Verschiebungsaktivität innerhalb des Ausführungsbahnmatrixbereichs zu akkumulieren. Demgemäß entspricht der Bereich der Bilddaten, der verarbeitet werden kann, dem Bereich 405, während ein „Blatt” so als koextensiv mit dem Bereich 405 zu verstehen ist. Das Laden eines Blattes in die Registermatrix 406 beinhaltet das Laden von Bilddaten in den Bereich 405.
Ein Compiler ist für das Einfügen von Befehlen in den Programmcode verantwortlich, die im Wesentlichen das Laden von Blättern von Information von/zu dem Blattgenerator zu/von dem internen RAM 407 der Datenberechnungseinheit 401 eines Schablonenprozessors steuern. Demgemäß ist in verschiedenen Ausführungsformen der Compiler dafür verantwortlich, zu bestimmen, welche Blätter aus dem Blattgenerator in den RAM 407 geladen werden sollen, und wann die besagten Blätter geladen werden sollen. Zusätzlich ist der Compiler dafür verantwortlich, zu bestimmen, welches Blatt in dem Schablonenprozessor-RAM 407 in die zweidimensionale Verschiebungsmatrix 406 geladen werden soll. Es ist zu beachten, dass der RAM 407 in getrennte Bänke zerlegt werden kann, wobei jede Bank einem bestimmten Bereich des Bildes in Bezug auf die Schieberegistermatrix zugeordnet ist (z. B. beinhalten die RAM-Bänke 407_1 Bilddaten für die erste Zeile der Schieberegistermatrix, die RAM-Bänke 407_2 beinhalten Bilddaten für die zweite Zeile der Schieberegistermatrix usw.).
Hierbei sollte das „Neuladen” von gleichen Datenblättern in den RAM 407 aus dem Blattgenerator und/oder das Neuladen von gleichen Datenblättern aus RAM 407 in das zweidimensionale Schieberegister 406 wo möglich vermieden werden, um z. B. den Energieverbrauch des Bildprozessors zu minimieren. Wie weiter unten ausführlicher erläutert, können Ineffizienzen vermieden werden, wenn der Compiler das Vorhandensein des Ringbereichs 409 erkennt, obwohl die Basiseinheit der Bilddaten als Datenblätter verstanden wird, die dem kleineren Bereich der Ausführungsbahnmatrix 405 entspricht. Die vermiedenen Ineffizienzen sind besonders ausgeprägt, wenn der Bildverarbeitungsalgorithmus Daten verarbeitet, die sich außerhalb des Rings für irgendwelche Ausgabebildpunkte innerhalb der Ausführungsbahnmatrix 405 erstrecken.
Die 7a–7d zeigen ein grundlegendes Beispiel. Wie in 7a dargestellt, entspricht ein Blatt von Eingabebilddaten dem Bereich 701 eines größeren Eingabebildes. Zur Vereinfachung wird in den 7a–7d davon ausgegangen, dass das Eingabeblatt die gleichen Abmessungen wie die Ausführungsbahnmatrix aufweist. Obwohl die besagte Anordnung oft zweckmäßig sein kann, ist sie nicht erforderlich. Beispielsweise können in Fällen, in denen sich die Auflösung der Eingabefläche von der der Ausgabefläche unterscheidet (z. B. durch das Hochsampeln oder Heruntersampeln), die Blätter andere Abmessungen aufweisen als die Ausführungsbahnmatrix. Beispielsweise können in einem Prozessor mit einer Ausführungsbahnmatrix von 16×16, 2 × heruntergesampelte Eingabedatenblätter eine Abmessung von 32×32 aufweisen, während 2 × hochgesampelte Eingabedatenblätter eine Abmessung von 8 × 8 aufweisen können.
Wenn unter dem Eingabebild nicht nur das Blatt 701, sondern auch die umgebenden Bilddaten, die in den Ringbereich passen könnten, verstanden wird, würde die Gesamtmenge der eingegebenen Bilddaten den schattierten Bereich 720 verbrauchen. Bei der Bestimmung von Ausgangsbildpunktwerten für Bildpunkte innerhalb des Blattes 701 können zumindest einige Algorithmen entworfen werden, um Eingabebilddaten außerhalb des Ringbereichs, beispielsweise über dem größeren Bereich 730, zu verarbeiten.
Wenn die Abmessungen der Ausführungsbahnmatrix 405 beispielsweise 16 Bildpunktorte mal 16 Bildpunktorte betragen und die Größe des Ringbereichs zusätzliche 4 Bildpunktorte entlang der X-Achse und 4 Bildpunktorte entlang der Y-Achse beträgt, würde Blatt 701 eine Abmessung von 16 Bildpunktorten mal 16 Bildpunktorten und der Bereich 720 eine Abmessung von 20 Bildpunktorten mal 20 Bildpunktorten aufweisen. Wenn der Algorithmus, der die Ausgangsbildpunktwerte für Bildpunkte innerhalb des Blattes 701 bestimmt, über Schablonen mit einer Abmessung von 18 Bildpunkten mal 18 Bildpunkten verarbeitet, würde sich der Oberflächenbereich, der für das Blatt 701 verarbeitet werden müsste, von dem Bereich 720 nach außen erstrecken, um den Bereich innerhalb der Grenze 730 einzuschließen. Um beispielsweise die Verarbeitung für den Bildpunktort an der unteren rechten Ecke des Blattes 701 aufzunehmen, wäre ein Bildpunkt in der unteren rechten Ecke des durch die Grenze 730 begrenzten Bereichs erforderlich. Somit erfordert die Verarbeitung des Blattes 701 erhebliche Datenmengen aus den Blättern 702, 703 und 704.
In einer Ausführungsform ist der Compiler so ausgelegt, dass er das Layout der mehreren Blätter innerhalb eines Eingabebildes, die Abmessungen der Ausführungsbahnmatrix, die Abmessungen des Rings und die Größe der zu verarbeitenden Schablone für einen bestimmten Ausgabebildpunkt innerhalb des Ausführungsbahnmatrixbereichs erfassen kann. Der Compiler fährt dann damit fort, Speicherladebefehle an geeigneten Positionen in dem Code einzufügen, die ein nächstes Blatt von dem Blattgenerator in den Datenberechnungseinheits-RAM 407 laden.
Zusätzlich fügt der Compiler, wie nachfolgend näher beschrieben, auch Datenbewegungsbefehle ein, um Blätter innerhalb des Direktzugriffsspeichers 407 der Datenberechnungseinheit zu bewegen, um so deren Wiederverwendung zu verbessern und dadurch das doppelte Laden derselben Blätter in den Direktzugriffsspeicher 407 aus dem Blattgenerator zu verringern.
7b zeigt eine durch den Compiler konstruierte Sequenz von Befehlen 740, welche bewirkt, dass der Blattgenerator anfänglich den Direktzugriffsspeicher 407 mit einer ausreichenden Anzahl von Blättern lädt, um den Algorithmus für jeden der Bildpunktorte des ersten Blattorts 701 vollständig auszuführen. Wie in 7b dargestellt, werden die Daten aus vier Blättern 701 bis 704 geladen, wonach ihnen logische Blattkennungen (Lsheet_0, Lsheet_1, LSheet_2, LSheet_3) zugeordnet werden. Hierbei entspricht die Anzahl der Blätter, die geladen werden, der Anzahl der Blätter, die der Bildverarbeitungsalgorithmus erreicht, wenn die gesamte Schieberegistermatrix 406, einschließlich des Ringbereichs, 409 in Betracht gezogen wird. Wie aus den Erörterungen der 3a und 3b hervorgeht, führt der in verschiedenen Ausführungsformen dem Skalarprozessor 302 zugeordnete Programmcontroller 309 Befehle aus, die Befehlen des Blattgenerators entsprechen, um Datenblätter zu/von der Datenberechnungseinheit 301 zu laden/zu speichern. Demgemäß können Befehle 740 durch den Skalarprozessor 302 ausgeführt werden.
Der Compiler konstruiert zudem die nachfolgenden Befehle 750, 760, um die Schieberegistermatrix 406 mit dem Inhalt aus den vier Blättern zu laden, die gerade in RAM (MEM LOAD) geladen wurden. Befehl 750 füllt den Schieberegisterbereich, der mit der Ausführungsbahnmatrix 405 mit dem Inhalt von LSheet_0 (Inhalt des Bildbereichs 701) koextensiv ist. Gleichermaßen kann der Skalarprozessor 302 in Übereinstimmung mit den obigen Erörterungen auch Befehle 750, 760 ausführen.
Befehl 760 füllt den Ringbereich. Das heißt, Befehl 760 führt Folgendes aus: 1) Laden der linken Seite (LHS) des Blattes 702 (Lsheet_1) in den Ringbereich 409, der direkt außerhalb des rechten Randes der Ausführungsbahnmatrix 405 liegt, 2) Laden des oberen Bereichs (UPR) des Blattes 704 (Lsheet_3) in den Ringbereich 409, der direkt unterhalb des unteren Randes der Ausführungsbahnmatrix 405 liegt, 3) Laden der oberen linken Ecke des Blattes 705 (Lsheet_4) in den Ringbereich von der unteren rechten Ecke der Ausführungsbahnmatrix 405. Nachdem diese Ladevorgänge durchgeführt wurden, wird der Inhalt der gesamten Schieberegistermatrix, einschließlich des Ringbereichs (Bereich 720 in 7a), mit ordnungsgemäß positionierten Eingabebilddaten geladen.
Unter Bezugnahme auf 4 sollte hier beachtet werden, dass jede Position der Ausführungsbahnmatrix eine Speicherzugriffseinheit (M) zum Ausführen eines Speicherladebefehls (MEM LOAD) enthält, um Bilddaten aus dem Direktzugriffsspeicher 407 abzurufen. Obwohl in 4 nicht dargestellt, beinhaltet jede der Positionen im Ringbereich 409 in verschiedenen Ausführungsformen zudem eine Speicherzugriffseinheit, sodass Bilddatenwerte aus dem Direktzugriffsspeicher 407 in den Ringbereich 409 geladen werden können. Wiederum jedoch enthalten in verschiedenen Ausführungsformen die Ringbereichsorte keine ALU-Einheit, sodass die tatsächliche Bildverarbeitung auf Bilddaten innerhalb der Ausführungsbahnmatrix 405 beschränkt bleibt. Somit entspricht der Befehl 750 einem Speicherladebefehl, der einzeln an jeder Position der Ausführungsbahnmatrix ausgeführt wird, jedoch unterschiedliche Eingabeoperanden-Daten (die die zu ladenden Bilddaten definieren) basierend auf deren Position in der Matrix aufweist, während der MEM LOAD-Befehl 760 gleichermaßen einem Speicherladebefehl entspricht, der einzeln an bestimmten Positionen innerhalb des Ringbereichs 409 ausgeführt wird, jedoch unterschiedliche Eingabeoperanden-Daten (die die zu ladenden Bilddaten definieren) basierend auf deren Position um die Ausführungsbahnmatrix aufweist. Techniken zur Angabe der Adresse für diese Befehle werden nachfolgend näher beschrieben.
Der Compiler konstruiert zudem einen folgenden Befehlssatz 770, um den Bildverarbeitungsalgorithmus bzw. die Bildverarbeitungsalgorithmen durchzuführen, der bzw. die die Ausgabebildpunktwerte für die Bildpunktorte innerhalb der LSheet_0-Position bestimmt bzw. bestimmen. In Übereinstimmung mit den obigen Erörterungen beinhalten die Berechnungen das Arbeiten über einem Schablonenbereich für jeden Bildpunktort, die durch Verschieben des Inhalts innerhalb der zweidimensionalen Schieberegistermatrix bewirkt wird. Der Compiler konstruiert daher Befehle, um nicht nur die mathematischen Berechnungen über der Schablone, sondern auch die entsprechenden Registerverschiebungsbefehle durchzuführen.
In dem derzeit erörterten Beispiel ist zu bedenken, dass die zu verarbeitende Schablone für jeden Bildpunktort innerhalb von LSheet_0 eine Abmessung von 18 × 18 beträgt. Infolgedessen erfolgt ein „Überlauf” von Bilddaten von der oberen und linken Seite der Ausführungsbahnmatrix 405 in den Direktzugriffsspeicher 407. Das heißt, Verschiebungen von Daten nach links führen dazu, dass Daten aus dem Blatt 702 (LSheet_1) und dem Blatt 703 (LSheet_2) innerhalb des durch die Grenze 720 begrenzten Bereichs, jedoch außerhalb des durch die Grenze 701 begrenzten Bereichs in den rechten Rand des Ringbereichs 409 geladen werden. Das Laden der Daten in den rechten Rand des Ringbereichs 409 schiebt „Überlauf”-Daten von dem linken Rand der Ausführungsbahnmatrix und dem linken Rand des Ringbereichs 409, der sich direkt unterhalb der Ausführungsbahnmatrix 405 befindet, effektiv aus dem Schieberegister. Die übergelaufenen/herausgeschobenen Daten werden in den Direktzugriffsspeicher 407 geschrieben.
Gleichermaßen bewirken Verschiebungen der Daten „nach oben”, dass Daten aus dem Blatt 704 (LSheet_3) und dem Blatt 703 (LSheet_2) innerhalb des durch die Grenze 720 begrenzten Bereichs, jedoch außerhalb des Ausführungsbahnbereichs, in den unteren Rand des Ringbereichs 409 geladen werden. Das Laden der Daten in den unteren Rand des Ringbereichs 409 schiebt „Überlauf”-Daten von dem oberen Rand der Ausführungsbahnmatrix 409 und dem oberen Rand des Ringbereichs, der sich rechts von der Ausführungsbahnmatrix 405 befindet, effektiv aus dem Schieberegister. Die übergelaufenen/herausgeschobenen Daten werden zudem in den Direktzugriffsspeicher 407 geschrieben. Um hingegen die Verschiebung zu bewirken, konstruiert der Compiler den Code für das gesamte Laden von neuen Daten aus RAM 407 in das Schieberegister und das Schreiben von herausgeschobenen Daten aus dem Schieberegister zurück in den RAM 407.
Nachdem alle Verschiebungen und Berechnungen 770 für das Blatt 701 (LSheet_0) durchgeführt wurden, tastet der Prozess weiterhin rasterartig nach rechts ab (ein Ausgabeblatt für den Bereich 701 kann zur Weiterleitung an den Blattgenerator auch in den Direktzugriffsspeicher 407 geschrieben werden). Um eine rasterartige Abtastung des Algorithmus zu erreichen, ist lediglich eine Neuzuordnung der logischen Blätter erforderlich, nach der derselbe Programmcode wieder ausgeführt werden kann, um Ausgabewerte für die Bildpunkte eines nächsten Blattes zu verarbeiten. Demgemäß kann das Ausführen des Algorithmus durch den Compiler durch Abtasten über dem Bild als Software-Schleife konstruiert werden. Hierbei können interne Zeiger im Schleifenprogramm mit jeder neuen Iteration der Schleife aktualisiert werden. Wenn die Kernroutine erkennt, dass sie ganz „rechts” der Daten angekommen ist, die für die sofortige Rekursion geladen werden sollen, erkennt sie insbesondere ebenfalls, dass eine nächste Rekursion unmittelbar bevorsteht.
Wie in 7c dargestellt, konstruiert der Compiler hier einen zusätzlichen Befehlssatz 780, der die Maschine vorbereitet, um den Algorithmus auf dem nächsten Blatt in der Rasterabtastung zu verarbeiten. Die Befehle beinhalten das Bewegen (MOV) des Inhalts von LSheet_1 in LSheet_0 und das Bewegen des Inhalts von LSheet_2 in LSheet_3. Zusätzlich beinhalten die Befehle 780 Befehle, um das nächste Lsheet_1 (Blatt 705) und das nächste LSheet_2 (Blatt 706) aus dem Blattgenerator in den RAM 407 zu laden. Nachdem diese Befehle 780 ausgeführt wurden, unterscheidet sich der Kontext der Maschine nicht von dem der Maschine aus 7b vor der Ausführung der Befehle 770, es sei denn, die Position des zu verarbeitenden Blattes ist die eines Blattes rechts daneben (d. h. Blatt 702 anstelle von Blatt 701). Wichtig ist, dass Blätter, die bereits in den RAM 407 geladen wurden (d. h. die Blätter 702 und 703), nicht aus dem Blattgenerator in den RAM 407 geladen werden. Dementsprechend wird jede Ineffizienz vermieden, die sich ergeben würde, wenn die Blätter 702 und 703 neu in den RAM 407 geladen werden würden.
Es ist zu beachten, dass das Laden von LSheet_1 (Blatt 705) und LSheet_2 (Blatt 706) in RAM 740 aus dem Blattgenerator, wie durch die SG-Befehle innerhalb der Befehle 780 angegeben, z. B. während der Operationen 770 durchgeführt und anschließend in RAM zu Sheet_1- und Sheet_2-Positionen bewegt werden kann, nachdem der frühere Inhalt dieser Blätter jeweils in Lsheet_0 bzw. LSheet_3 bewegt wurde. Dementsprechend können die SG-LOAD-Befehle der Befehle 780 tatsächlich als zusätzliche MOV-Befehle innerhalb des RAM 407 implementiert werden. In einer Ausführungsform sind die Bewegungs-(MOV-)Befehle der Befehle 780 tatsächliche physische Datenbewegungen innerhalb des RAM 407. Demgemäß handelt es sich bei den Adressen für LSheet_0 bis LSheet_3, wie im Programmcode angegeben, um feste Adressen.
Obwohl das oben skizzierte Verfahren mit Bezug auf die 7a bis 7c auf ein Beispiel gerichtet war, in welchem die Schablonengröße, die für Bildpunkte innerhalb des Blattes 701 verarbeitet werden sollte, groß genug war, um Bildpunkte einzuschließen, die sich außerhalb des Ringbereichs befinden, gilt das Verfahren als optimal für Anwendungen, bei denen die zu verarbeitende Schablonengröße für Bildpunkte innerhalb des Blattes 701 (d. h. innerhalb der Ausführungsbahnmatrix) klein genug ist, sodass alle zu verarbeitenden Bildpunkte innerhalb des Ringbereichs liegen (d. h. Bildpunkte außerhalb der Grenze 720 und innerhalb der Grenze 730 oder darüber hinaus nicht erforderlich sind). In diesem Fall wird das Laden zusätzlicher Bilddaten in das zweidimensionale Schieberegister (z. B. entlang dem rechten Rand des Ringbereichs) vermieden.
8 zeigt ein oben beschriebenes Verfahren. Das Verfahren beinhaltet wiederholtes 801 Ausführen des Folgenden. Das Laden eines nächsten Bilddatenblattes von einem ersten Ort eines Speichers in eine zweidimensionale Schieberegistermatrix 802. Der Speicher ist lokal mit der zweidimensionalen Schieberegistermatrix und einer Ausführungsbahnmatrix gekoppelt, die eine kleinere Abmessung als die zweidimensionale Schieberegistermatrix entlang mindestens einer Matrixachse aufweist. Das geladene nächste Bilddatenblatt bleibt innerhalb eines Bildbereichs der zweidimensionalen Schieberegistermatrix. Das Bestimmen von Ausgabewerten für das nächste Bilddatenblatt durch Ausführen von Programmcodebefehlen entlang jeweiliger Bahnen der Ausführungsbahnmatrix, wobei eine Schablonengröße, die bei der Bestimmung der Ausgabewerte verwendet wird, nur Bildpunkte umfasst, die in der zweidimensionalen Schieberegistermatrix 803 liegen. Bewegen eines nächsten Bilddatenblattes, das vollständig in die zweidimensionale Schieberegistermatrix zu laden ist, von einem zweiten Ort des Speichers zu dem ersten Ort des Speichers 804.
Aus der vorstehenden Erörterung geht hervor, dass bei der Ausführung der Befehle 750, 760 und 770 Bilddaten aus dem RAM 407 in das zweidimensionale Schieberegister 406 geladen werden können. Hier wird angenommen, dass jede einzelne Position im zweidimensionalen Schieberegister 406 (Ringbereich eingeschlossen) eine Speicherzugriffseinheit zum lokalen Ausführen eines Speicherladebefehls beinhaltet, sodass Daten einzeln aus dem RAM 407 in den lokalen Registerbereich geladen werden können. In einer Ausführungsform fixiert der Compiler eine Basisadressenkomponente für LSheet_0 in den RAM 407, während die durch den Compiler erkannten Adressen der zusätzlichen logischen Blätter zur Durchführung der Schleife (z. B. LSheet_1, LSheet_2 und LSheet_3) Adressabstände in Bezug auf die Basisadressenkomponente aufweisen. Wenn zum Beispiel die Adresse in dem RAM 407 für LSheet_0 [base] entspricht, ist die Adresse für LSheet_1 +1, die Adresse für LSheet_2 [base] +2 und die Adresse für LSheet_3 [base] +3.
Um eine umfassend programmierbare Umgebung zu unterstützen, unterstützt die Befehlssatzarchitektur der Ausführungseinheiten in der Ausführungsbahnmatrix und im Ringbereich einen Befehl, der den korrekten Adressabstand für den jeweiligen Schieberegistermatrixort erzeugt. Der Adressabstand kann dann nachfolgend verwendet werden, um z. B. die richtige Adresse zu erzeugen. Hier ist es relevant, darauf hinzuweisen, dass das Beispiel der 7a bis 7c in dem Sinne vereinfacht war, dass die Blattabmessung mit der Abmessung der Ausführungsbahnmatrix identisch war. Das heißt, sowohl die Blätter als auch die Ausführungsbahnmatrix hatten eine Abmessung von 16 Bildpunktorten x 16 Bildpunktorten.
Andere Ausführungsformen können z. B. wählen, eine Blattgröße aufzuweisen, die größer oder kleiner als die Ausführungsbahnmatrix entlang einer oder beider Abmessungen ist. Im ersteren Fall erstreckt sich z. B. LSheet_0 in den Ringbereich, wohingegen im letzteren Fall z. B. LSheet_1 und/oder LSheet_3 zunächst in die Abmessungen der Ausführungsbahnmatrix 405 geladen wird. Zur Vereinfachung bezieht sich die Erörterung der 9a und 9b auf den vereinfachten Fall, bei dem die Blattabmessungen die gleichen sind wie die Abmessungen der Ausführungsbahnmatrix. Jedoch kann die generische Operation des Befehls, wie es deutlicher gemacht wird, für Ausführungsformen verwendet werden, bei denen sich die Abmessungen unterscheiden.
9a zeigt im Wesentlichen eine Vergrößerung der Darstellung von 7a, wobei die volle Größe der zweidimensionalen Schieberegistermatrix, einschließlich deren Ringbereichs, als ein schattierter Bereich ersichtlich ist. 9b zeigt das Ergebnis eines speziellen Befehls (QUADRANT), der an jedem Matrixort ausgeführt wird. Hier berechnet der QUADRANT-Befehl für jeden Schieberegistermatrixort den korrekten Adressabstand, der der Basisspeicheradresse hinzugefügt werden soll, wenn der Inhalt aus dem RAM 407 in den jeweiligen Verschiebungsmatrixort geladen wird.
In dem besonderen Beispiel von 9b, bei dem die Blattabmessungen die gleichen wie die Abmessungen der Ausführungsbahnmatrix sind, werden alle Matrixorte, die dem Ausführungsbahnmatrixbereich zugeordnet sind, LSheet_0 mit einem Adressabstand von 0 laden. Im Gegensatz dazu werden die Matrixorte in dem Ringbereich bis zur unmittelbaren rechten Seite der Ausführungsbahnmatrix aus LSheet_1 mit einem Adressabstand von +1 geladen, wobei die Matrixorte in dem Ringbereich unmittelbar unterhalb der Ausführungsbahnmatrix aus LSheet_3 mit einem Adressabstand von +3 geladen werden, während die Matrixorte im Ringbereich außerhalb des Randes der Ausführungsbahnmatrix aus LSheet_2 mit einem Adressabstand von +2 geladen werden.
In einer Ausführungsform akzeptiert der Befehl als Eingabeparameter sowohl die X- als auch die Y-Abmessungen des Blattes (Xs, Ys) und der X- und Y-Koordinaten, die die Position in der Matrix (Xa, Ya) angeben. Mit diesen Werten kann der QUADRANT-Befehl den Adressabstand wie folgt berechnen: Adressabstand = 0 wenn (Xa ≤ Xs) UND (Ya ≤ Ys) = WAHR 1 wenn (Xa > Xs) UND (Ya ≤ Ys) = WAHR 2 wenn (Xa > Xs) UND (Ya > Ys) = WAHR 3 wenn (Xa ≤ Xs) UND (Va > Ys) = WAHR
In verschiedenen Ausführungsformen erzeugt der Compiler eine Matrix von Xa-, Ya-Koordinatenpaaren, die im Wesentlichen den Matrixort identifizieren, der das Koordinatenpaar einliest und Xs und Ys als unmittelbare Operanden spezifiziert, da diese über alle Ausführungen des QUADRANT-Befehls hinweg konstant sind. Die Xa- und Ya-Koordinatenpaare werden vor der Ausführung des Befehls als Eingabe-Operandeninformation in den jeweiligen Matrixort geladen. In einer weiteren Ausführungsform akzeptiert der Befehl zusätzlich den [base]-Adresswert als Eingabeoperand, sodass der vollständige Adresswert [base]+Adressabstand als Ergebnis des QUADRANT-Befehls bereitgestellt werden kann. Der [base]-Operand kann als unmittelbarer Operand angegeben werden oder der Programmcode kann so konstruiert sein, dass er den [base]-Wert dynamisch ermittelt und als zusätzliche Eingabeoperanden an die Matrixorte übermittelt.
Es ist zu beachten, dass der QUADRANT-Befehl spezifisch für eine Betriebsumgebung ist, in der der Algorithmus, der Ausgabebildpunktwerte bestimmt, bei Bildpunktwerten über vier Blätter hinweg arbeitet. Für Betriebsumgebungen, z. B. wenn der Algorithmus über neun Blätter hinweg arbeitet, kann ein anderer Befehl HECTANT in die Befehlssatzarchitektur eingebaut werden, die berechnet, welche von neun verschiedenen Adressabständen für irgendeinen bestimmten Matrixort verwendet werden soll.
10 zeigt eine Darstellung einer alternativen Ausführungsform des oben beschriebenen Rasterabtastverarbeitungsansatzes mit Bezug auf die 7a bis 7c. Sollte die Abtastung in dem Ansatz aus 10 nach rechts erfolgen, wird die rechte Seite des Ringbereichs zunächst nicht geladen. Stattdessen wird nur der Teil des Rings direkt unter der Ausführungsbahn geladen. Während der Operation des Algorithmus werden in dem Maße, in dem neue Werte von LSheet_1 benötigt werden, um z. B. eine Verschiebung nach links zu bewirken, die Werte entlang dem rechten Rand der Ausführungsbahnmatrix anstatt entlang dem rechten Rand des Rings geladen. Der Ansatz aus 10 ist besonders nützlich in Fällen, in denen der Algorithmus nicht außerhalb des Ringbereichs arbeitet und effektiv Code mit weniger Ladebefehlen erzeugt.
d. Implementierungsausführungsformen
Es ist wichtig, darauf hinzuweisen, dass die oben beschriebenen verschiedenen Merkmale der Bildprozessorarchitektur 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 Bildprozessor neu charakterisiert wird oder auch nicht. Wenn beispielsweise eines der vorstehend beschriebenen verschiedenen Merkmale der Bildprozessorarchitektur bei der Erstellung und/oder Erzeugung und/oder Wiedergabe von Animationen anstatt bei der Verarbeitung von tatsächlichen Kamerabildern verwendet werden soll, kann der Bildprozessor als grafische Verarbeitungseinheit charakterisiert sein. Zudem können die oben beschriebenen Architekturmerkmale des Bildprozessors in anderen technischen Anwendungen, wie in der Videoverarbeitung, Bildverarbeitung, Bilderkennung und/oder dem maschinellen Lernen, angewendet werden. Auf diese Weise kann der Bildprozessor (z. B. als Koprozessor) in einen allgemeineren Universalprozessor (z. B. als Teil einer CPU 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 Schaltkreisdesigns zur letztendlichen Ausrichtung auf einen Halbleiterherstellungsprozess enthalten sein. Im letzteren Fall können diese 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 Bildprozessor, wie oben beschrieben, in der Hardware auf einem Computersystem (z. B. als Teil eines Handgerätsystems an Chip (SOC), das Daten von der Kamera des Handgerätes verarbeitet) enthalten sein kann. In Fällen, in denen der Bildprozessor als Hardware-Schaltung ausgebildet ist, ist zu beachten, dass die Bilddaten, die von dem Bildprozessor verarbeitet werden, direkt von einer Kamera empfangen werden können. Hier kann der Bildprozessor Teil einer diskreten Kamera oder Teil eines Computersystems mit einer integrierten Kamera sein. Im letzteren Fall 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 Bildprozessor an den Systemspeicher). Zu beachten ist auch, dass viele der in den vorangehenden Abschnitten beschriebenen Merkmale auf eine Bildprozessoreinheit (zur Darstellung von Animationen) anwendbar sind.
11 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 Bildprozessor (z. B. einem Handgerät, wie etwa einem Smartphone oder Tablet-Computer) anwendbar. Fachleute auf dem Gebiet werden leicht zwischen beiden unterscheiden können.
Wie in 11 dargestellt, kann das grundlegende Computersystem eine zentrale Verarbeitungseinheit 1101 (die beispielsweise eine Vielzahl von Universal-Verarbeitungskernsystemen 1115_1 bis 1115_N und einen auf einem Multikernprozessor oder einem Anwendungsprozessor angeordneten Hauptspeichercontroller 1117 beinhalten kann), Systemspeicher 1102, ein Display 1103 (z. B. Touchscreen, Flachbildschirm), eine lokal verdrahtete Punkt-zu-Punkt-Verbindung (z. B. eine USB-Schnittstelle) 1104, verschiedene Netzwerk-E-/A-Funktionen 1105 (wie z. B. eine Ethernet-Schnittstelle und/oder ein Mobilfunkmodem-Teilsystem), ein drahtloses lokales Netzwerk (z. B. WLAN) 1106, eine drahtlose Punkt-zu-Punkt-Verbindung (z. B. Bluetooth-Schnittstelle) 1107 und eine globale Positionierungssystemschnittstelle 1108, verschiedene Sensoren 1109_1 bis 1109_N, eine oder mehrere Kameras 1110, eine Batterie 1114, eine Energieverwaltungssteuereinheit 1112, einen Lautsprecher und ein Mikrofon 1113 sowie einen Audio-Kodierer/Dekodierer 1114 beinhalten.
Ein Anwendungsprozessor oder Multikernprozessor 1150 kann einen oder mehrere Universalprozessorkerne 1115 innerhalb seiner CPUs 1101, eine oder mehrere grafische Verarbeitungseinheiten 1116, eine Speicherverwaltungsfunktion 1117 (z. B. einen Speichercontroller), eine E-/A-Steuerfunktion 1118 und eine Bildverarbeitungseinheit 1119 beinhalten. Die Universalverarbeitungskerne 1115 führen in der Regel das Betriebssystem und die Anwendungssoftware des Computersystems aus. Die Grafikverarbeitungseinheiten 1116 führen in der Regel grafikintensive Funktionen aus, um z. B. Grafikdaten zu erzeugen, die auf dem Display 1103 dargestellt werden. Die Speichersteuerfunktion 1117 ist mit dem Systemspeicher 1102 verbunden, um Daten in den Systemspeicher 1102 zu schreiben bzw. aus diesem einzulesen. Die Leistungsverwaltungssteuereinheit 1112 steuert im Allgemeinen den Energieverbrauch des Systems 1100.
Die Bildverarbeitungseinheit 1119 kann gemäß einer der oben in den vorangehenden Abschnitten beschriebenen Ausführungsformen der Bildverarbeitungseinheit implementiert sein. Alternativ dazu oder in Kombination kann die IPU 1119 mit einer oder sowohl der GPU 1116 als auch dem CPU 1101 als Koprozessor derselben gekoppelt sein. Darüber hinaus kann in verschiedenen Ausführungsformen die GPU 1116 mit einem der oben beschriebenen Prozessormerkmale implementiert sein.
Das Touchscreen-Display 1103, die Kommunikationsschnittstellen 1104–1107, die GPS-Schnittstelle 1108, die Sensoren 1109, die Kamera 1110 und der Lautsprecher/Mikrofon-Codec 1113, 1114 können alle 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. die eine oder mehrere Kameras 1110). Je nach Implementierung können verschiedene dieser E-/A-Komponenten auf dem Anwendungsprozessor/Multikernprozessor 1150 integriert sein oder sich außerhalb des Chips oder außerhalb des Pakets des Anwendungsprozessors/Multikernprozessors 1150 befinden.
In einer Ausführungsform beinhalten eine oder mehrere Kameras 1110 eine Tiefenkamera, die in der Lage ist, die Tiefe zwischen der Kamera und einem Objekt in dessen 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 Befehlen enthalten sein. Die Befehle können dazu verwendet werden, einen Universalprozessor oder Spezialprozessor dazu zu veranlassen, bestimmte Prozesse auszuführen. Alternativ dazu können die diese 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 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, die für die Speicherung von elektronischen Befehlen geeignet sind, beinhalten. 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 in einem 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 Spezifikation 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 dem in den beigefügten Ansprüchen dargelegten Geist und Umfang der Erfindung abzuweichen. Die Beschreibung und die Zeichnungen sind daher in einem veranschaulichenden und nicht in einem einschränkenden Sinne zu betrachten.

Claims

Maschinenlesbares Speichermedium, das einen Programmcode enthält, der bei Verarbeitung durch einen Prozessor bewirkt, dass ein Verfahren ausgeführt wird, wobei das Verfahren das wiederholte Ausführen von Folgendem umfasst: Laden eines nächsten Bilddatenblattes von einem ersten Ort eines Speichers in eine zweidimensionale Schieberegistermatrix, wobei der Speicher lokal mit der zweidimensionalen Schieberegistermatrix und einer Ausführungsbahnmatrix gekoppelt ist, die eine kleinere Abmessung als die zweidimensionale Schieberegistermatrix entlang mindestens einer Matrixachse aufweist, wobei das geladene nächste Bilddatenblatt in einem Bildbereich der zweidimensionalen Schieberegistermatrix bleibt; Bestimmen von Ausgabewerten für das nächste Bilddatenblatt durch Ausführen von Programmcodebefehlen entlang jeweiliger Bahnen der Ausführungsbahnmatrix, wobei eine Schablonengröße, die bei der Bestimmung der Ausgabewerte verwendet wird, nur Bildpunkte umfasst, die innerhalb der zweidimensionalen Schieberegistermatrix liegen; Bewegen eines nächsten Bilddatenblattes, das vollständig in die zweidimensionale Schieberegistermatrix zu laden ist, von einem zweiten Ort des Speichers zu dem ersten Ort des Speichers.
Maschinenlesbares Speichermedium nach Anspruch 1, wobei die Ausführungsbahnmatrix und die zweidimensionale Schieberegistermatrix Komponenten eines Bildprozessors sind und der Bildprozessor eine Komponente eines Systems auf einem Chip ist, das mehrere Universalprozessorkerne umfasst.
Maschinenlesbares Medium nach Anspruch 1 oder 2, wobei die Ausführungsbahnmatrix eine kleinere Abmessung als die zweidimensionale Schieberegistermatrix entlang zwei Matrixachsen aufweist.
Maschinenlesbares Medium nach einem der vorangehenden Ansprüche, wobei das Verfahren ferner das wiederholte Laden eines nächsten angrenzenden Bilddatenblattes mit einem Bildinhalt, der an den Bildinhalt des nächsten Blattes angrenzt, in die Peripherieregisterorte der zweidimensionalen Schieberegistermatrix umfasst.
Maschinenlesbares Medium nach Anspruch 4, wobei das Verfahren ferner das wiederholte Lesen des nächsten angrenzenden Bilddatenblattes von einem dritten Ort des Speichers umfasst.
Maschinenlesbares Medium nach Anspruch 4, wobei das nächste angrenzende Bilddatenblatt auch das nächste Bilddatenblatt ist, das vollständig in die zweidimensionale Schieberegistermatrix zu laden ist, und die zweiten und dritten Speicherorte gleiche Speicherorte sind.
Maschinenlesbares Medium nach Anspruch 1, wobei das Verfahren ferner das wiederholte Laden eines nächsten Eckblattes von Bilddaten mit einem Bildinhalt, der außerhalb einer Ecke des Bildinhaltes des nächsten Blattes liegt, in die Eckregisterorte der zweidimensionalen Schieberegistermatrix umfasst.
Maschinenlesbares Speichermedium, das einen Programmcode enthält, der bei Verarbeitung durch einen Prozessor bewirkt, dass ein Verfahren ausgeführt wird, wobei das Verfahren das Konstruieren des Programmcodes nach einem der vorstehenden Ansprüche umfasst.
Computersystem, umfassend: a) eine Vielzahl von Universalprozessorkernen; b) einen Systemspeicher; c) einen zwischen dem Systemspeicher und der Vielzahl von Prozessorkernen gekoppelten Speichercontroller; d) einen Bildprozessor, der einen Speicher umfasst, der lokal mit einer zweidimensionalen Ausführungsbahnmatrix und einer zweidimensionalen Schieberegistermatrix gekoppelt ist, wobei die zweidimensionale Ausführungsbahnmatrix eine kleinere Abmessung als die zweidimensionale Schieberegistermatrix aufweist; e) ein maschinenlesbares Speichermedium, das einen Programmcode enthält, der von dem Bildprozessor ausgeführt werden soll, sodass der Bildprozessor ein Verfahren ausführt, umfassend: wiederholtes Ausführen des Folgenden: Laden eines nächsten Bilddatenblattes von einem ersten Ort des Speichers in der zweidimensionalen Schieberegistermatrix, wobei das geladene nächste Bilddatenblatt innerhalb eines Bildbereichs der zweidimensionalen Schieberegistermatrix bleibt; Bestimmen von Ausgabewerten für das nächste Bilddatenblatt durch Ausführen von Programmcodebefehlen entlang jeweiliger Bahnen der Ausführungsbahnmatrix, wobei eine Schablonengröße, die bei der Bestimmung der Ausgabewerte verwendet wird, nur Bildpunkte umfasst, die innerhalb der zweidimensionalen Schieberegistermatrix liegen; Bewegen eines nächsten Bilddatenblattes, das vollständig in die zweidimensionale Schieberegistermatrix zu laden ist, von einem zweiten Ort des Speichers zu dem ersten Ort des Speichers.
Computersystem nach Anspruch 9, wobei die Ausführungsbahnmatrix eine kleinere Abmessung als die zweidimensionale Schieberegistermatrix entlang von zwei Matrixachsen aufweist.
Computersystem nach Anspruch 9 oder 10, wobei das Verfahren ferner das wiederholte Laden eines nächsten angrenzenden Bilddatenblattes mit einem Bildinhalt, der an den Bildinhalt des nächsten Blattes angrenzt, in die Peripherieregisterorte der zweidimensionalen Schieberegistermatrix umfasst.
Computersystem nach Anspruch 11, wobei das Verfahren ferner das wiederholte Lesen des nächsten angrenzenden Bilddatenblattes von einem dritten Ort des Speichers umfasst.
Computersystem nach Anspruch 11, wobei das nächste angrenzende Bilddatenblatt auch das nächste Bilddatenblatt ist, das vollständig in die zweidimensionale Schieberegistermatrix zu laden ist, und die zweiten und dritten Speicherorte gleiche Speicherorte sind.
Computersystem nach Anspruch 9, wobei das Verfahren ferner das wiederholte Laden eines nächsten Eckblattes von Bilddaten mit einem Bildinhalt, der außerhalb einer Ecke des Bildinhaltes des nächsten Blattes liegt, in die Eckregisterorte der zweidimensionalen Schieberegistermatrix umfasst.