DE112016001866T5

DE112016001866T5 - Zeilenpuffereinheit für Bildprozessor

Info

Publication number: DE112016001866T5
Application number: DE112016001866.5T
Authority: DE
Inventors: Neeti Desai; Albert Meixner; Qiuling Zhu; Jason Rupert Redgrave; Ofer Shacham; Daniel Fredric Finchelstein
Original assignee: Google LLC
Current assignee: Google LLC
Priority date: 2015-04-23
Filing date: 2016-03-31
Publication date: 2018-01-25
Also published as: US20160316157A1; CN107533751B; US20200275040A1; US10321077B2; US20170257585A1; US10638073B2; WO2016171869A1; JP2018513476A; JP2019053736A; EP3286723B1; US11190718B2; US20190327433A1; JP6408717B2; KR102013404B1; US9756268B2; JP6793162B2; KR20170125392A; CN107533751A; EP3286723A1

Abstract

Es wird eine Vorrichtung beschrieben, die eine Zeilenpuffereinheit umfasst, die aus einer Vielzahl von Zeilenpuffer-Schnittstelleneinheiten besteht. Jede Zeilenpuffer-Schnittstelleneinheit dient zur Verarbeitung von einer oder mehreren Anforderungen durch einen entsprechenden Erzeuger, um eine entsprechende Zeilengruppe in einem Speicher zu speichern, und zur Verarbeitung von einer oder mehreren Anforderungen von einem entsprechenden Abnehmer, um die entsprechenden Zeilengruppe aus dem Speicher abzurufen und bereitzustellen. Die Zeilenpuffereinheit verfügt über einen programmierbaren Speicherplatz, dessen Informationen eine Zeilengruppengröße bestimmen, sodass verschiedene Zeilengruppengrößen für verschiedene Bildgrößen im Speicher gespeichert werden können.

Description

Gebiet der Erfindung
Das Gebiet der Erfindung betrifft im Allgemeinen die Bildverarbeitung und insbesondere eine Zeilenpuffereinheit 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 gegliederte 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 angeordneten 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 Schaltungen auf viel größere Datenblöcke an. Die Verwendung von größeren (im Gegensatz zu feineren) Datenblöcken, die direkt auf benutzerdefinierte Schaltungen angewendet werden, verringert den Energieverbrauch pro Dateneinheit erheblich. Jedoch führt die Verwendung von benutzerdefinierten stationären Funktionsschaltungen 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 assoziiert 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 eine Vorrichtung beschrieben, die eine Zeilenpuffereinheit beinhaltet, die aus einer Vielzahl von Zeilenpuffer-Schnittstelleneinheiten besteht. Jede Zeilenpuffer-Schnittstelleneinheit dient zur Verarbeitung von einer oder mehreren Anforderungen durch einen Erzeuger, um eine entsprechende Zeilengruppe in einem Speicher zu speichern, und zur Verarbeitung von einer oder mehreren Anforderungen von einem entsprechenden Abnehmer, um die entsprechenden Zeilengruppe aus dem Speicher abzurufen und bereitzustellen. Die Zeilenpuffereinheit verfügt über einen programmierbaren Speicherplatz, dessen Informationen eine Zeilengruppengröße bestimmen, sodass verschiedene Zeilengruppengrößen für verschiedene Bildgrößen im Speicher gespeichert werden können.
Figurenverzeichnis
Die folgende Beschreibung und begleitenden Zeichnungen dienen dazu, Ausführungsformen der Erfindung zu veranschaulichen. In den Zeichnungen:
1 zeigt verschiedene Komponenten einer Technologieplattform;
2a zeigt eine Ausführungsform einer Anwendungssoftware, die mit Kerneln aufgebaut ist;
2b zeigt eine Ausführungsform der Struktur eines Kernels;
3 zeigt eine Ausführungsform des Betriebs eines Kernels;
4 zeigt eine Ausführungsform einer Bildprozessor-Hardwarearchitektur;
5a, 5b, 5c, 5d und 5e zeigen das Parsen von Bilddaten in eine Zeilengruppe, das Parsen einer Zeilengruppe in ein Blatt und die an einem Blatt mit sich überschneidenden Schablonen durchgeführte Operation;
6 zeigt eine Ausführungsform eines Schablonenprozessors;
7 zeigt eine Ausführungsform der Konfiguration und Programmierung eines Bildprozessors;
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 Bildprozessors;
10a und 10b zeigen eine virtuell große Betriebsart;
11a und 11b zeigen Ausführungsformen einer Zeilenpuffer-Schnittstelleneinheit;
12 zeigt eine Ausführungsform eines Computersystems. 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 Blätter, wie weiter unten beschrieben) verwendet, um für eine verbesserte Energieeffizienz zu sorgen.
1.0 Anwendungssoftware-Entwicklungsumgebung a. Anwendung und Struktur von Kerneln
1 zeigt eine umfassende Ansicht einer Bildprozessortechnologieplattform, die eine virtuelle Bildverarbeitungsumgebung 101, die eigentliche Bildverarbeitungshardware 103 und einen Compiler 102 beinhaltet, um einen für die virtuelle Verarbeitungsumgebung 101 geschriebenen höheren Code in Objektcode zu übersetzen, den die eigentliche Hardware 103 physisch ausgeführt. Wie nachfolgend näher beschrieben wird, ist die virtuelle Verarbeitungsumgebung 101 in Bezug auf die Anwendungen, die entwickelt werden können, vielseitig und auf eine einfache Visualisierung der einzelnen 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 auf die eigentliche Hardware 103 zugeschnitten ist.
2a zeigt eine beispielhafte Ausführungsform der Struktur und Form, welche eine 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 Eingabebilddaten 201 verarbeitet, um eine Gesamttransformation an den Eingabebilddaten 201 zu bewirken. Die Transformation wird mit dem Betrieb eines oder mehrerer Kernels des Programmcodes 202 realisiert, die an den Eingabebilddaten in einer abgestimmten Sequenz arbeiten, welche von dem Entwickler artikuliert wird.
Wie in 2a erkennbar, wird die Gesamttransformation durch eine erste Verarbeitung von jedem Eingabebild mit einem ersten Kernel K1 bewirkt. An den vom Kernel K1 erzeugten Ausgabebildern arbeitet dann der Kernel 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 Kernel K3_1 und K3_2 können identische Kernel sein, die derart ausgelegt sind, dass sie die Gesamtverarbeitung beschleunigen, indem sie eine Parallelverarbeitung in der K3-Stufe auferlegen, oder sie können unterschiedliche Kernel sein (z. B. arbeitet der Kernel K3_1 an Eingabebildern eines ersten spezifischen Typs und der Kernel K3_2 arbeitet an Eingabebildern eines zweiten unterschiedlichen Typs).
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 tatsächlich eine Darstellung des Programmcodes als solches, der entwickelt wird, anzuzeigen. Kernels können von einem Entwickler einzeln entwickelt und/oder von einer Entität bereitgestellt werden, die jegliche darunterliegende Technologie liefert (wie z. B. die eigentliche Signalprozessorhardware und/oder ein Design derselben), und/oder durch einen Dritten (z. B. einen Anbieter von für die Entwicklungsumgebung geschriebene Kernelsoftware). Als solches wird davon ausgegangen, dass eine nominale Entwicklungsumgebung eine „Bibliothek“ von Kerneln einschließt, die von Entwicklern in verschiedenen Weisen „verbunden“ werden können, um den Gesamtablauf ihres größeren Entwicklungsaufwands herbeizuführen. Einige grundlegende Kernel, von denen erwartet wird, dass sie Teil einer solchen Bibliothek sind, können Kernel beinhalten, um eine oder mehrere der folgenden grundlegenden Bildverarbeitungstasks bereitzustellen: Faltungen, Entrauschen, Farbraumumwandlungen, Rand- und Eckenerfassung, Schärfen, Weißabgleich, Gammakorrektur, Tonemapping, Matrixmultiplikation, Bildregistrierung, Pyramidenbau, Wavelet-Transformation, blockweise diskrete Kosinus- und Fourier-Transformationen.
2b zeigt eine beispielhafte Darstellung der Struktur eines Kernels 203, der von einem Entwickler in Betracht gezogen werden kann. Wie in 2b dargestellt, kann der Kernel 203 als eine Anzahl von parallelen Threads von Programmcode („Threads“) 204 betrachtet werden, die jeweils auf einem entsprechenden zugrundeliegenden Prozessor 205 arbeiten, wobei jeder Prozessor 205 auf einen bestimmten Ort in einer Ausgabematrix 206 (z. B. einen bestimmten Bildpunktort in dem von dem Kernel generierten Ausgabebild) ausgerichtet ist. Der Einfachheit halber sind in 2b nur drei Prozessoren und entsprechende Threads dargestellt. Bei verschiedenen Ausführungsformen würde jeder dargestellte Ausgabematrixort einen eigenen fest zugeordneten Prozessor und einen entsprechenden Thread aufweisen. Das heißt, dass für jeden Bildpunkt in der Ausgabematrix 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 zugrundeliegenden 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 Bildframes. Bei verschiedenen Ausführungsformen kann sich der Entwickler im Klaren darüber sein, dass die Hardware auf Zeilengruppen arbeitet, oder die Entwicklungsumgebung kann eine Abstraktion darstellen, in der es einen separaten Prozessor und einen Thread für beispielsweise jeden Bildpunkt in dem Ausgabeframe gibt (z. B. jeder Bildpunkt in einem Ausgabeframe generiert durch einen eigenen fest zugeordneten Prozessor und Thread). 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 bei einer Ausführungsform, 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 Bildpunkt-für-Bildpunkt-Verarbeitung leicht zu visualisieren. Die Fähigkeit, einen beliebigen Eingabematrixort in Kombination mit einer vollständigen ISA herkömmlicher mathematischer und Programmsteuerungsmaschinenbefehle 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 ISA der virtuellen Prozessoren („virtuelle ISA“) bei einer Ausführungsform einen speziellen Datenladebefehl und einen speziellen Datenspeicherbefehl. Der Datenladebefehl ist in der Lage, von jedem Ort innerhalb einer Eingabematrix von Bilddaten zu lesen. Der Datenspeicherbefehl ist in der Lage an einen beliebigen Ort innerhalb der Ausgabematrix von Bilddaten zu schreiben. Der letztgenannte Befehl ermöglicht es, mehrere Instanzen des gleichen Prozessors problemlos verschiedenen Ausgabebildpunktorten zuzuordnen (jeder Prozessor schreibt in einen anderen Bildpunkt in der Ausgabematrix). 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 Zielmatrixorte vereinfacht als X- und Y-Koordinaten angegeben werden.
Unabhängig davon können durch Instanziieren eines getrennten Prozessors für jede von mehreren Orten in der Ausgabematrix die Prozessoren ihre jeweiligen Threads parallel ausführen, sodass z. B. die jeweiligen Werte für alle Orte in der Ausgabematrix 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 bei einer Ausführungsform der Entwicklungsumgebung davon ausgegangen, dass jeder Prozessor identisch ist und den gleichen 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 beispielhafte Ausführungsform der Verarbeitungsumgebung für zwei virtuelle Prozessoren, die identischen Code für zwei unterschiedliche Bildpunktpositionen in einer Ausgabematrix verarbeiten. 3 zeigt eine Ausgabematrix 304, die einem Ausgabebild entspricht, das generiert wird. Hier verarbeitet ein erster virtueller Prozessor den Code des Threads 301, um einen Ausgabewert am Ort X1 der Ausgabematrix 304 zu generieren, und ein zweiter virtueller Prozessor verarbeitet den Code des Threads 302, um einen Ausgabewert am Ort X2 der Ausgabematrix 304 zu generieren. Bei 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 zeigt 3 lediglich zwei davon). Jedoch muss der Entwickler (aufgrund der SIMD-ähnlichen Beschaffenheit der Maschine) bei verschiedenen Ausführungsformen nur Code für einen Prozessor und Thread entwickeln.
Wie auf dem Fachgebiet bekannt, wird ein Ausgabebildpunktwert oft durch die Verarbeitung der Bildpunkte einer Eingabematrix bestimmt, welche die entsprechende Ausgabebildpunktposition beinhaltet und umgibt. Wie aus 3 ersichtlich, entspricht der Ort X1 der Ausgabematrix 304 beispielsweise dem Ort E der Eingabematrix 303. Die Schablone der Bildpunktwerte der Eingabematrix 303, die verarbeitet werden würden, um den Ausgabewert X1 zu bestimmen, würde daher den Eingabewerten ABCDEFGHI entsprechen. Ähnlich würde die Schablone der Eingabematrixbildpunkte, die verarbeitet werden würden, um den Ausgabewert X2 zu bestimmen, den Eingabewerten DEFGHIJKL entsprechen.
3 zeigt eine beispielhafte Ausführungsform eines entsprechenden Programmcodes einer virtuellen Umgebung für ein Thread-Paar 301, 302, das verwendet werden könnte, um die Ausgabewerte X1 bzw. X2 zu berechnen. Im Beispiel von 3 sind beide Code-Paare identisch und entsprechen durchschnittlich einer Schablone von neun Eingabematrixwerten, um einen entsprechenden Ausgabewert zu bestimmen. Der einzige Unterschied zwischen den beiden Threads sind die Variablen, die aus der Eingabematrix aufgerufen werden, und der Ort der Ausgabematrix, in die geschrieben wird. Speziell arbeitet der Thread, der in die Ausgabeposition X1 schreibt, an der Schablone ABCDEFGHI und der Thread, der in die Ausgabeposition X2 schreibt, an der Schablone DEFGHIJKL.
Wie aus dem jeweiligen Programmcode von dem Thread-Paar 301, 302 ersichtlich, beinhaltet jeder virtuelle Prozessor mindestens die internen Register R1 und R2 und unterstützt mindestens die folgenden Befehle: 1) einen LADE-Befehl aus der Eingabematrix in R1; 2) einen LADE-Befehl aus der Eingabematrix in R2; 3) einen ADDIER-Befehl, der den Inhalt von R1 und R2 addiert und die Resultante in R2 einfügt; 4) einen DIVIDIER-Befehl, der den Wert innerhalb R2 durch den unmittelbaren Operanden 9 teilt; und, 5) einen SPEICHER-Befehl, der den Inhalt von R2 in die Ausgabematrixposition speichert, zu der der Thread zugeordnet ist. Obwohl in 3 nur zwei Ausgabematrixpositionen und nur zwei Threads und entsprechende Prozessoren dargestellt sind, könnte jedem Ort in der Ausgabematrix durchaus ein virtueller Prozessor und ein entsprechender Thread zugewiesen werden, der diese Funktionen ausführt. Bei verschiedenen Ausführungsformen werden die mehreren 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 Prozessor-Speichermodell
Bei verschiedenen Ausführungsformen ist ein zugehöriges Merkmal der virtuellen Prozessoren ihr Speichermodell. Wie auf dem Fachgebiet bekannt, liest ein Prozessor Daten aus einem Speicher, arbeitet an diesen Daten und schreibt neue Daten in den Speicher zurück. Ein Speichermodell ist die Perspektive oder Sicht, die ein Prozessor von der Art und Weise hat, in der Daten im Speicher organisiert sind. In einer Ausführungsform beinhaltet das Speichermodell der virtuellen Prozessoren sowohl Eingabe- als auch Ausgabematrixbereiche. Eingabebildpunktwerte für Threads werden im Eingabematrixbereich gespeichert und Ausgabebildpunktwerte, die durch Threads erzeugt werden, werden im Ausgabematrixbereich gespeichert.
In einer Ausführungsform wird ein neuartiges Speicheradressierschema verwendet, um zu definieren, welche bestimmten Eingabewerte von einem Eingabematrixbereich des Speichermodells des virtuellen Prozessors aufgerufen werden sollen. Genauer gesagt wird ein „positionsbezogenes“ Adressierungsschema verwendet, das die gewünschten Eingabedaten 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 Eingabematrix mit einer X-Komponente und einer Y-Komponente identifiziert. Als solches wird ein zweidimensionales Koordinatensystem verwendet, um Speicher für Eingabewerte zu adressieren, die von der Eingabematrix gelesen 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 vorstehend erwähnt, ermöglicht die, eine beliebige Eingabematrixposition in Kombination mit einer vollständigen ISA herkömmlicher mathematischer und Programmsteuerungsmaschinenbefehle 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 leicht zu definieren. Verschiedene Befehlsformat-Ausführungsformen für Befehle, die ein positionsbezogenes Adressierungsschema übernehmen, sowie Ausführungsformen anderer Merkmale der unterstützten ISA werden nachfolgend näher beschrieben.
Die Ausgabematrix enthält die Ausgabebilddaten, für deren Generierung die Threads verantwortlich sind. Die Ausgabebilddaten 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 nachfolgender Kernel der Gesamtbildverarbeitungssequenz als Eingabebilddateninformationen verwendet. Virtuelle Prozessoren konkurrieren wiederum in der Regel jedoch nicht um Ausgabedatenelemente, da sie während eines gleichen Zyklus in verschiedene Bildpunktpositionen der Ausgabebilddaten schreiben.
Bei einer Ausführungsform wird das positionsbezogene Adressierungsschema auch für Schreibvorgänge in die Ausgabematrix verwendet. Dementsprechend beinhaltet die ISA für jeden virtuellen Prozessor einen Speicherbefehl, dessen Befehlsformat anstelle einer herkömmlichen Speicherung mit wahlfreiem Zugriff einen adressierten Schreibort im Speicher als eine zweidimensionale X, Y-Koordinate definiert.
2.0 Hardwarearchitektur-Ausführungsformen
a. Bildprozessor-Hardwarearchitektur und -Betrieb
4 zeigt eine Ausführungsform einer Architektur 400 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 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 jede Zeilenpuffereinheit mit jedem Blattgenerator 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 Blattgenerator des Schablonenprozessors 403 geladen werden). In zumindest einigen Fällen kann eine Bildverarbeitungspipeline realisiert werden, indem ein erstes Kernelprogramm für eine erste Pipelinestufe in einen ersten Schablonenprozessor 402_1 geladen, ein zweites Kernelprogramm für eine zweite Pipelinestufe in einen zweiten Schablonenprozessor 402_2 geladen wird usw., wobei der erste Kernel die Funktionen der ersten Pipelinestufe durchführt, der zweite Kernel die Funktionen der zweiten Pipelinestufe durchführt usw., und zusätzliche Steuerablaufverfahren installiert werden, um Ausgabebilddaten von einer Pipelinestufe zur nächsten Pipelinestufe weiterzugeben.
In anderen Konfigurationen kann der Bildprozessor als eine parallele Maschine realisiert sein, die zwei oder mehr Schablonenprozessoren 402_1, 402_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.
Bei noch anderen Konfigurationen kann im Wesentlichen jeder DAG von Kerneln auf den Hardwareprozessor geladen werden, indem jeweilige Schablonenprozessoren mit deren eigenen jeweiligen Kernel von Programmcode konfiguriert und geeignete Steuerablauf-Hooks in die Hardware konfiguriert werden, um Ausgabebilder von einem Kernel an den Eingang eines nächsten Kernels im DAG-Design 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 ü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 404 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 einer einzigen Eingabe werden im Allgemeinen Eingabeframes an die gleiche Zeilenpuffereinheit 401_1 geleitet, die die Bilddaten in Zeilengruppen parst und die Zeilengruppen zu dem Blattgenerator 403_1 leitet, dessen entsprechender Schablonenprozessor 402_1 den Code des ersten Kernsystems in der Pipeline/dem DAG ausführt. Nach Beendigung der Operationen durch den Schablonenprozessor 402_1 an den von ihm verarbeiteten Zeilengruppen sendet der Blattgenerator 403_1 Ausgabezeilengruppen an eine „nachgelagerten“ 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/Operation in der Pipeline/dem DAG darstellen, die auf deren eigenen jeweiligen anderen Blattgenerator und Schablonenprozessor (z. B. Blattgenerator 403_2 und Schablonenprozessor 402_2) ausgefü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äß dem Design der gesamten Pipeline oder des DAGs ausführt.
Ein Schablonenprozessor 402 ist dafür ausgelegt, gleichzeitig an mehreren sich überschneidenden Schablonen von Bilddaten zu arbeiten. Die mehreren sich überschneidenden Schablonen und die interne Hardwareverarbeitungskapazität des Schablonenprozessors bestimmen effektiv die Größe eines Blattes. Hier arbeiten innerhalb eines Schablonenprozessors 402 Matrizen von Ausführungsbahnen zusammen, um gleichzeitig den Bilddatenoberflächenbereich zu verarbeiten, der von den mehreren sich überschneidenden Schablonen bedeckt ist.
Wie nachstehend näher beschrieben, werden in verschiedenen Ausführungsformen, Blätter von Bilddaten in eine zweidimensionale Registermatrixstruktur innerhalb des Schablonenprozessors 402 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.
5a bis 5e veranschaulichen umfassend Ausführungsformen sowohl der Parsing-Aktivität einer Zeilenpuffereinheit 401 als auch der feineren Parsing-Aktivität einer Blattgeneratoreinheit 403 sowie der Schablonenverarbeitungsaktivität des Schablonenprozessors 402, der mit der Blatterzeugereinheit 403 gekoppelt ist.
5a zeigt eine Ausführungsform eines Eingabeframes der Bilddaten SOL. 5a zeigt zudem einen Umriss drei überlappender Schablonen 502 (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 502 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 überschneidende Schablonen aufweist.
Aufgrund der sich, wie in 5a dargestellt, vertikal überschneidenden Schablonen 502 innerhalb des Schablonenprozessors gibt es ein breites Band von Bilddaten innerhalb des Frames, das von einem einzelnen Schablonenprozessor bearbeitet werden kann. Wie nachfolgend näher beschrieben, verarbeiten die Schablonenprozessoren in einer Ausführungsform innerhalb ihrer sich überschneidenden Schablonen Daten von links nach rechts über sämtliche 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 401 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 bearbeiten. Eine exemplarische Darstellung einer Zeilengruppe ist als schattierter Bereich 503 dargestellt. Bei einer weiteren Ausführungsform kann wie nachstehend weiter beschrieben die Zeilenpuffereinheit 401 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 503 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 in 5b dargestellt, parst der Blattgenerator 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 der Bezugsnummer 504 gekennzeichnet ist). Wie in den 5c und 5d dargestellt, arbeitet der Schablonenprozessor an dem Blatt der eingegebenen Bilddaten durch effektives Bewegen der überlappenden Schablonen 502 in einer Weise von links nach rechts über das Blatt. Wie in 5d 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 5e ersichtlich, liefert der Blattgenerator dann ein nächstes Blatt 505 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 5d dargestellt) vom Erschöpfungspunkt nach rechts auf dem ersten Blatt entsprechen. Mit dem neuen Blatt 505 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 504 und den Daten des zweiten Blattes 505 aufgrund der Randbereiche der Schablonen, die einen Ausgabebildpunktort umgeben, eine gewisse Überschneidung vorliegt. Die Überschneidung könnte einfach gehandhabt werden, indem der Blattgenerator die sich überschneidenden 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 sich überschneidenden Daten aus dem vorhergehenden Blatt verwendet.
b. Schablonenprozessordesign 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 Laden von „eingegebenen“ Datenblättern, die von dem Blattgenerator empfangen wurden, in die Datenberechnungseinheit 601 sowie das Speichern der von dem Schablonenprozessor „ausgegebenen“ Blätter im Blattgenerator. In einer Ausführungsform umfasst das Laden von Blattdaten in die Datenberechnungseinheit 601 das Parsen eines empfangenen Blattes in die Zeilen/Spalten der Bilddaten sowie das Laden der Zeilen/Spalten der Bilddaten in die zweidimensionale Schieberegisterstruktur 606 oder in die jeweiligen Arbeitsspeicher 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 Direktzugriffsspeichern 607 ab, um ein Ausgabeblatt zu bilden, das dann an den Blattgenerator weitergeleitet wird.
Der Skalarprozessor 602 beinhaltet einen Programmcontroller 609, der die Befehle des Programmcodes des Schablonenprozessors aus dem Skalarspeicher 603 einliest 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 Befehle, 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 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 prozessorähnlichere Funktionen und nicht 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 verteilter 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 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 einer beliebigen Ausgabematrixposition zuzugreifen.
Abgesehen davon, dass diese als Datenspeicher für Bilddaten genutzt werden, die durch die Ausführungsbahnmatrix 605 bearbeitet werden, können die Arbeitsspeicher 607 zudem eine oder mehrere Wertetabellen verwalten. In verschiedenen Ausführungsformen können eine oder mehrere skalare Wertetabellen auch innerhalb des skalaren Speichers 603 instanziiert werden.
Ein skalarer Nachschlagevorgang beinhaltet das Übermitteln desselben Datenwertes aus derselben Wertetabelle 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 darüber hinaus einen skalaren Operationscode einzuschließen, der eine vom Skalarprozessor ausgeführte Nachschlageoperation in eine skalare Wertetabelle 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 Suchvorgang in einer skalaren Wertetabelle 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. Hier sind die N Zeilengruppen 801_1, 801_2 bis 801_N in einem Bild 801 zu sehen. 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 Konfiguration, die als „virtuell groß“ bezeichnet und nachstehend näher beschrieben wird, leitet die Zeilenpuffereinheit 701 anfänglich nur einen ersten oberen Bereich einer Zeilengruppe als Reihen mit voller Breite von Bilddaten weiter. 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 Pl 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 Zeilenpufferschaltungseinheit 901 gekoppelt ist. Die Zeilenpufferschaltungseinheit 901 kann beispielsweise mit einer speziell dafür vorgesehenen Logikschaltung ausgestattet sein. Innerhalb der Zeilenpufferschaltungseinheit 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 Zeilenpufferschaltungseinheit 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 Pl, 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 Zeilenpufferschaltungseinheit 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 Zeilenpufferschaltungseinheit 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 Zeilenpufferschaltungseinheit 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 potenzielle 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 große“ 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 Zeilenpufferschaltungseinheit 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 Zeilenpufferschaltungseinheit ein effektives Multitasking zu ermöglichen.
Eine erste Form von Multitasking befindet sich innerhalb einer DAG- oder Software-Pipeline, die auf dem Bildprozessor 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 Bildprozessor-Hardware implementiert sind. Beispielsweise könnte ein Bildprozessor 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 Zeilenpufferschaltungseinheit (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 Zeilenpufferschaltungseinheit 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 Informationsaufbewahrungsschaltungen aufbewahrt werden.
c. Zeilenpuffereinheit-Ausführungsformen und Modus „Vollzeilengruppe“ im Vergleich zum Modus „Virtuell groß“
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 groß“ 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 Sequenz des Modus „Virtuell groß“. 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ächsten unteren 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 untere 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.).
11a zeigt eine erste (vereinfachtere) Ausführungsform der Schaltung in der Zeilenpuffer-Schnittstelleneinheit 1104. Wie in 11a dargestellt, beinhaltet die Zeilenpuffer-Schnittstelleneinheit eine Adressen-Übersetzungsschaltung 1106, um die Identität einer Zeilengruppe oder eines Abschnitts dieser Gruppe (wie beispielsweise den unteren Abschnitt 1004_2 von 10b), die bzw. der durch einen oder mehrere X, Y-Koordinatenwerte identifiziert wird, in eine lineare Adresse für den Zugriff auf den Speicher der Zeilenpuffereinheit zu konvertieren. Das heißt Zeilengruppen können als im Speicher der Zeilenpuffereinheit zugeordnet angesehen werden. Die Übersetzungsschaltung 1106 erfasst diese Zuordnung im Wesentlichen in Form von X, Y-Werten und kann diese in bestimmte lineare Speicheradressen konvertieren.
Die Fähigkeit zur Erfassung der Zuordnung basiert auf Informationen im Konfigurationsregisterbereich 1105, von dem eine Ausführungsform zuvor in 9d beschrieben wurde. Mit Kenntnis von Row_Width 924, FB_Rows 926 und FB_Base_Address 931 kann hier die Übersetzungseinheit die Größe und Position der Vollzeilengruppe im Speicher „erfassen“. Als solches reicht beispielsweise im Modus „Virtuell groß“ eine Anforderung für einen unteren Abschnitt basierend auf einem X-Koordinatenwert (z. B. wenn relativ zur Zeilengruppe auf den unteren Abschnitt verwiesen wird) oder einer X, Y-Koordinatenposition (z. B. wenn relativ zum Bildframe auf den unteren Abschnitt verwiesen wird) auf, um zu identifizieren, auf welchen Abschnitt der Blattgenerator verweist. Darüber hinaus legen die Felder Vb_Rows 927 und Vb_Cols 928 im Wesentlichen die Dimensionen der unteren Abschnitte fest. Mit Kenntnis der Dimensionen der oberen und unteren Bereiche ist auch die Menge an Daten, die aus dem Pufferspeicher abgerufen oder dort gespeichert werden sollen, leicht bestimmbar. Die gleichen Konzepte gelten möglicherweise auch für Zeilengruppen mit voller Breite. Eine Zeilengruppe mit voller Breite kann beispielsweise durch ihre X, Y-Position in einem Bild identifiziert werden. Darüber hinaus kann eine Zeilengruppe mit voller Breite in einigen Ausführungsformen über das Netzwerk in Form einer Sequenz von atomaren Anforderungen/Antworten übertragen werden, die mithilfe von X- und/-oder Y-Koordinatenwerten auf kleinere Blöcke einer Zeilengruppe mit voller Breite verweisen.
Die Übersetzungsschaltung 1106 könnte auch in einem Abstraktadressiermodus verwendet werden, in dem das Base_Address_Field 931 nicht ausgefüllt wird und die Blattgeneratoren auf die Zeilengruppen in Form von X, Y-Koordinaten in einem Bildframe verweisen. Wenn in diesem Fall die Übersetzungsschaltung 1006 mit einigen der Informationen im globalen Registerbereich von 9e (z. B. Image_Size, Stencil_Size) verknüpft ist oder diese anderweitig erhält, könnte die Übersetzungsschaltung 1106 alle sachbezogenen Informationen für die Zeilengruppe (ihre Dimensionen und Position innerhalb des Frames) berechnen und diese in lineare Adressen konvertierten, die für den Zugriff auf den Speicher der Zeilenpuffereinheit verwendet werden. In einer anderen Ausführungsform bestimmt die Übersetzungsschaltung 1106 den Wert Base_Address_Field 931 sofort (basierend auf den globalen Informationen und einer oder mehreren X, Y-Koordinaten, die die Zeilengruppe beschreiben) und lädt diesen in den eigenen Registerbereich 1105.
Die Ausführungsform der Zeilenpuffer-Schnittstelleneinheit von 11a unterstützt zudem einen linearen Adressiermodus, in dem keine X, Y-Koordinatenwerte verwendet werden, um eine Zeilengruppe zu verweisen (stattdessen werden herkömmliche lineare Adressen verwendet). Im linearen Adressiermodus umgehen die Bypass-Pfade 1140 die Adressenübersetzungsschaltung 1106. In einer Ausführungsform stellt die Zeilenpuffer-Schnittstelleneinheit unabhängig davon, welcher Adressiermodus am Eingang der Zeilenpuffer-Schnittstelleneinheit verwendet wird, standardmäßige, lineare Speicheradressen zur Adressierung des Speichers der Zeilenpuffereinheit bereit. Erneut kurz bezugnehmend auf 9b werden die linearen Adressen einem Arbiter bereitgestellt. Die Speicherschnittstelle 908 löst kollidierende Speicherzugriffsanforderungen auf und greift auf den Speicher der Zeilenpuffereinheit 902 zu.
Wie zuvor ausführlich beschrieben kann ein Blattgenerator mit einem oder mehreren X, Y-Koordinatenwerten auf eine Zeilengruppe verweisen. In einer anderen Ausführungsform können die Blattgeneratoren, anstatt eine nächste Zeilengruppe im Modus „Vollzeilengruppen“ oder einen nächsten unteren Abschnitt im Modus „Virtuell groß“ zu identifizieren, einfach eine Anforderung ausgeben, die der Anforderung „Nächste(n)“ ähnelt (die Anforderung zeigt z. B. nur an, dass ohne Koordinaten auf die „nächste“ Vollzeilengruppe, den „nächsten“ untere Abschnitt oder die „nächsten“ Bilddaten innerhalb derselben vollen/virtuell großen Zeilengruppe verwiesen wird).
Um diesen Kommunikationsweg zu unterstützen, beinhaltet/beinhalten die Zeilenpuffereinheit und/oder die Zeilenpuffer-Schnittstelleneinheit einen Zustandsregisterbereich, um erfassen zu können, welches die nächste Zeilengruppe bzw. der nächste Abschnitt ist. 11b zeigt eine erweiterte Ausführungsform einer Zeilenpuffer-Schnittstelleneinheit, die Zeigerstatusinformationen speichert, sodass die Blattgeneratoren einfach auf einen „nächsten“ unteren Abschnitt einer Zeilengruppe im Modus „Virtuell groß“ verweisen können, anstatt dessen Position mithilfe von X, Y-Koordinaten festlegen zu müssen. Hier wird ein Schreibzeiger 1141 von der Zeigersteuerlogikschaltung 1143 gespeichert, die die unteren Abschnitte nachverfolgt, die vom erzeugenden Blattgenerator bereitgestellt wurden. Im Wesentlichen speichert der Schreibzeiger 1141 die Position des „nächsten“ Abschnitts, den der Erzeuger laut Planung bereitstellen soll. Darüber hinaus gestatten die Zeigerstatusinformationen den Blattgeneratoren, nur auf eine „nächste“ Zeilengruppe mit voller Breite (im Moduls „Volle Breite“) zu verweisen, ohne X, Y-Koordinaten festlegen zu müssen (da die Zeilenpuffer-Speichereinheit bestimmen kann, wo sich die nächste Zeilengruppe mit voller Breite für das Bild befindet).
In einer Ausführungsform wird der Zeiger als eine oder mehrere X, Y-Koordinaten artikuliert und die Übersetzungsschaltung konvertiert diese in eine lineare Adresse. Wenn der nächste Abschnitt empfangen wird, wird der Zeiger 1141 von der Zeigersteuerlogikschaltung 1143 aktualisiert, um auf den Abschnitt zu zeigen, der dem gerade empfangenen Abschnitt folgt. Lesezeiger 1142 funktionieren ähnlich, nur dass ein separater Lesezeiger für jeden Abnehmer gespeichert wird (erneut wird der Bequemlichkeit halber nur ein Erzeuger vorausgesetzt).
Im Modus „Vollzeilengruppe“ ist die Position der „nächsten“ Zeilengruppe mit voller Breite anhand der globalen Registerinformationen und einer ähnlichen Anordnung von Zeigern bestimmbar, die auf globaler Ebene gespeichert werden.
d. Ausführungsformen zur Implementierung
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 z. B. in der Videoverarbeitung, Bildverarbeitung, Bilderkennung und/oder dem maschinellen Lernen, angewendet werden. Auf diese Weise kann der Bildprozessor (z. B. als Coprozessor) 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 Schaltungsdesigns zur letztendlichen Ausrichtung auf einen Halbleiterherstellungsprozess enthalten sein. Im letzteren Fall können diese Schaltungsbeschreibungen die Form von Schaltungsbeschreibungen auf höherer/verhaltensorientierter Ebene (z. B. VHDL-Beschreibung) oder Schaltungsbeschreibungen auf unterer Ebene (z. B. Beschreibung auf Registertransferebene (RTL, Register Transfer Level), Beschreibung auf Transistorebene oder Maskenbeschreibung) oder verschiedener Kombinationen davon 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 on 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.
12 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 z. B. einem Smartphone oder Tablet-Computer) anwendbar. Fachleute auf dem Gebiet werden leicht zwischen beiden unterscheiden können.
Wie in 12 dargestellt, kann das grundlegende Computersystem eine zentrale Verarbeitungseinheit 1201 (die beispielsweise eine Vielzahl von Universal-Verarbeitungskernsystemen 1215_1 bis 1215_N und einen auf einem Multikernprozessor oder einem Anwendungsprozessor angeordneten Hauptspeichercontroller 1217 beinhalten kann), Systemspeicher 1202, ein Display 1203 (z. B. Touchscreen, Flachbildschirm), eine lokal verdrahtete Punkt-zu-Punkt-Verbindung (z. B. eine USB-Schnittstelle) 1204, verschiedene Netzwerk-E-/A-Funktionen 1205 (wie z. B. eine Ethernet-Schnittstelle und/oder ein Mobilfunkmodem-Teilsystem), ein drahtloses lokales Netzwerk (z. B. WLAN) 1206, eine drahtlose Punkt-zu-Punkt-Verbindung (z. B. Bluetooth-Schnittstelle) 1207 und eine globale Positionierungssystemschnittstelle 1208, verschiedene Sensoren 1209_1 bis 1209_N, eine oder mehrere Kameras 1210, eine Batterie 1211, eine Energieverwaltungssteuereinheit 1212, einen Lautsprecher und ein Mikrofon 1213 sowie einen Audio-Kodierer/Dekodierer 1214 beinhalten.
Ein Anwendungsprozessor oder Multikernprozessor 1250 kann einen oder mehrere Universalprozessorkerne 1215 innerhalb seiner CPUs 1201, eine oder mehrere grafische Verarbeitungseinheiten 1216, eine Speicherverwaltungsfunktion 1217 (z. B. einen Speichercontroller), eine E/A-Steuerfunktion 1218 und eine Bildverarbeitungseinheit 1219 beinhalten. Die Universalverarbeitungskerne 1215 führen in der Regel das Betriebssystem und die Anwendungssoftware des Computersystems aus. Die Grafikverarbeitungseinheiten 1216 führen in der Regel grafikintensive Funktionen aus, um z. B. Grafikdaten zu erzeugen, die auf dem Display 1203 dargestellt werden. Die Speichersteuerfunktion 1217 ist mit dem Systemspeicher 1202 verbunden, um Daten in den Systemspeicher 1202 zu schreiben bzw. aus diesem einzulesen. Die Leistungsmanagementsteuereinheit 1212 steuert generell den Energieverbrauch des Systems 1200.
Die Bildverarbeitungseinheit 1219 kann gemäß einer der oben in den vorangehenden Abschnitten beschriebenen Ausführungsformen der Bildverarbeitungseinheit implementiert sein. Alternativ dazu oder in Kombination kann die IPU 1219 mit einer oder sowohl der GPU 1216 als auch der CPU 1201 als Coprozessor derselben gekoppelt sein. Darüber hinaus kann in verschiedenen Ausführungsformen die GPU 1216 mit einem der oben beschriebenen Prozessormerkmale implementiert sein.
Das Touchscreen-Display 1203, die Kommunikationsschnittstellen 1204–1207, die GPS-Schnittstelle 1208, die Sensoren 1209, die Kamera 1210 und der Lautsprecher/Mikrofon-Codec 1213, 1214 können alle als unterschiedliche Formen der 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 1210). Je nach Implementierung können verschiedene dieser E/A-Komponenten auf dem Anwendungsprozessor/Multikernprozessor 1250 integriert sein oder sich außerhalb des Chips oder außerhalb des Pakets des Anwendungsprozessors/Multikernprozessors 1250 befinden.
In einer Ausführungsform beinhalten eine oder mehrere Kameras 1210 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 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/maschinenlesbare 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 Erfindungsgedanken 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

Vorrichtung, umfassend: eine Zeilenpuffereinheit, die aus einer Vielzahl von Zeilenpuffer-Schnittstelleneinheiten besteht, wobei jede Zeilenpuffer-Schnittstelleneinheit zur Verarbeitung von einer oder mehreren Anforderungen durch einen entsprechenden Erzeuger, um eine entsprechende Zeilengruppe in einem Speicher zu speichern, und zur Verarbeitung von einer oder mehreren Anforderungen von einem entsprechenden Abnehmer dient, um die entsprechenden Zeilengruppe aus dem Speicher abzurufen und bereitzustellen, und wobei die Zeilenpuffereinheit über einen programmierbaren Speicherplatz verfügt, dessen Informationen eine Zeilengruppengröße bestimmen, sodass verschiedene Zeilengruppengrößen für verschiedene Bildgrößen im Speicher gespeichert werden können.
Vorrichtung nach Anspruch 1, wobei diese Zeilengruppe eine Steuerlogikschaltung beinhaltet, um: eine Zeilenpuffer-Schnittstelleneinheit einem freien Pool hinzuzufügen, nachdem die Zeilenpuffer-Schnittstelleneinheit den letzten Abnehmer bedient hat; und anschließend diese Zeilenpuffer-Schnittstelleneinheit einer anderen Zeilengruppe zuzuweisen.
Vorrichtung nach Anspruch 1, wobei die Zeilenpuffereinheit eine Schaltung beinhaltet, um einen Ausdruck von mindestens einer X, Y-Position innerhalb eines Bildframes zu erfassen.
Vorrichtung nach Anspruch 1, wobei mindestens eine der Zeilenpuffer-Schnittstelleneinheiten eine Schaltung beinhaltet, um einen Ausdruck von mindestens einer X, Y-Position innerhalb eines Bildframes zu erfassen und den Ausdruck in eine lineare Speicheradresse zu konvertieren.
Vorrichtung nach Anspruch 1, wobei mindestens eine der Zeilenpuffereinheiten einen Modus „Vollzeilengruppe“ unterstützt.
Vorrichtung nach Anspruch 1, wobei mindestens eine der Zeilenpuffereinheiten einen Modus „Virtuell große Zeilengruppe“ unterstützt.
Vorrichtung nach Anspruch 1, wobei mindestens eine der Zeilenpuffer-Schnittstelleneinheiten verknüpft ist, um etwaige der folgenden Informationen von einem Konfigurationsregisterbereich zu empfangen: a) Anzahl der Kanäle in Bildinformationen; b) Anzahl der Abnehmer einer Zeilengruppe; c) Breite einer Gruppeneinheit mit voller Zeile; d) Höhe einer Gruppe mit voller Zeile; e) eine Dimension eines kleineren Abschnitts einer Zeilengruppe.
Vorrichtung nach Anspruch 1, wobei die Zeilenpuffereinheit einen Registerbereich beinhaltet, um eine Basisadresse für eine Zeilengruppe zu speichern.
Vorrichtung nach Anspruch 1, wobei die Zeilenpuffereinheit eine Schaltung beinhaltet, um eine Basisadresse für eine Zeilengruppe basierend auf X, Y-Koordinateninformationen zu bestimmen, die von einer Software-Entwicklungsumgebung abgeleitet werden.
Vorrichtung nach Anspruch 1, wobei die Zeilenpuffereinheit eine Zeigerschaltung beinhaltet, um zu erfassen, wo sich die nächsten abzurufenden Bilddaten im Speicher befinden.
Maschinenlesbares Speichermedium, das eine Beschreibung eines elektronischen Stromkreises beinhaltet, wobei dieser elektronische Stromkreis Folgendes umfasst: eine Zeilenpuffereinheit, die aus einer Vielzahl von Zeilenpuffer-Schnittstelleneinheiten besteht, wobei jede Zeilenpuffer-Schnittstelleneinheit zur Verarbeitung von einer oder mehreren Anforderungen durch einen entsprechenden Erzeuger, um eine entsprechende Zeilengruppe in einem Speicher zu speichern, und zur Verarbeitung von einer oder mehreren Anforderungen von einem entsprechenden Abnehmer, um die entsprechenden Zeilengruppe aus dem Speicher abzurufen und bereitzustellen dient, und wobei die Zeilenpuffereinheit über einen programmierbaren Speicherplatz verfügt, dessen Informationen eine Zeilengruppengröße bestimmen, sodass verschiedene Zeilengruppengrößen für verschiedene Bildgrößen im Speicher gespeichert werden können.
Maschinenlesbares Speichermedium nach Anspruch 11, wobei diese Zeilengruppe eine Steuerlogikschaltung beinhaltet, um: eine Zeilenpuffer-Schnittstelleneinheit einem freien Pool hinzuzufügen, nachdem die Zeilenpuffer-Schnittstelleneinheit den letzten Abnehmer bedient hat; und anschließend diese Zeilenpuffer-Schnittstelleneinheit einer anderen Zeilengruppe zuzuweisen.
Maschinenlesbares Speichermedium nach Anspruch 11, wobei die Zeilenpuffereinheit eine Schaltung beinhaltet, um einen Ausdruck von mindestens einer X, Y-Position innerhalb eines Bildframes zu erfassen.
Maschinenlesbares Speichermedium nach Anspruch 11, wobei mindestens eine der Zeilenpuffer-Schnittstelleneinheiten eine Schaltung beinhaltet, um einen Ausdruck von mindestens einer X, Y-Position innerhalb eines Bildframes zu erfassen und den Ausdruck in eine lineare Speicheradresse zu konvertieren.
Maschinenlesbares Speichermedium nach Anspruch 11, wobei mindestens eine der Zeilenpuffereinheiten einen Modus „Vollzeilengruppe“ unterstützt.
Maschinenlesbares Speichermedium nach Anspruch 11, wobei mindestens eine der Zeilenpuffereinheiten einen Modus „Virtuell große Zeilengruppe“ unterstützt.
Maschinenlesbares Speichermedium nach Anspruch 11, wobei mindestens eine der Zeilenpuffer-Schnittstelleneinheiten verknüpft ist, um etwaige der folgenden Informationen von einem Konfigurationsregisterbereich zu empfangen: a) Anzahl der Kanäle in Bildinformationen; b) Anzahl der Abnehmer einer Zeilengruppe; c) Breite einer Gruppeneinheit mit voller Zeile; d) Höhe einer Gruppe mit voller Zeile; e) eine Dimension eines kleineren Abschnitts einer Zeilengruppe.
Maschinenlesbares Speichermedium nach Anspruch 11, wobei die Zeilenpuffereinheit einen Registerbereich beinhaltet, um eine Basisadresse für eine Zeilengruppe zu speichern.
Maschinenlesbares Speichermedium nach Anspruch 11, wobei die Zeilenpuffereinheit eine Schaltung beinhaltet, um eine Basisadresse für eine Zeilengruppe basierend auf X, Y-Koordinateninformationen zu bestimmen, die von einer Software-Entwicklungsumgebung abgeleitet werden.
Maschinenlesbares Speichermedium nach Anspruch 11, wobei die Zeilenpuffereinheit eine Zeigerschaltung beinhaltet, um zu erfassen, wo sich die nächsten abzurufenden Bilddaten im Speicher befinden.
Computersystem, umfassend: eine Vielzahl von Prozessorkernen; einen Bildprozessor, wobei dieser Bildprozessor eine Zeilenpuffereinheit umfasst, die aus einer Vielzahl von Zeilenpuffer-Schnittstelleneinheiten besteht, wobei jede Zeilenpuffer-Schnittstelleneinheit zur Verarbeitung von einer oder mehreren Anforderungen durch einen entsprechenden Erzeuger, um eine entsprechende Zeilengruppe in einem Speicher zu speichern, und zur Verarbeitung von einer oder mehreren Anforderungen von einem entsprechenden Abnehmer, um die entsprechenden Zeilengruppe aus dem Speicher abzurufen und bereitzustellen dient, und wobei die Zeilenpuffereinheit über einen programmierbaren Speicherplatz verfügt, dessen Informationen eine Zeilengruppengröße bestimmen, sodass verschiedene Zeilengruppengrößen für verschiedene Bildgrößen im Speicher gespeichert werden können.
Computersystem nach Anspruch 21, wobei diese Zeilengruppe eine Steuerlogikschaltung beinhaltet, um: eine Zeilenpuffer-Schnittstelleneinheit einem freien Pool hinzuzufügen, nachdem die Zeilenpuffer-Schnittstelleneinheit den letzten Abnehmer bedient hat; und anschließend diese Zeilenpuffer-Schnittstelleneinheit einer anderen Zeilengruppe zuzuweisen.
Computersystem nach Anspruch 21, wobei die Zeilenpuffereinheit eine Schaltung beinhaltet, um einen Ausdruck von mindestens einer X, Y-Position innerhalb eines Bildframes zu erfassen.
Computersystem nach Anspruch 21, wobei mindestens eine der Zeilenpuffer-Schnittstelleneinheiten eine Schaltung beinhaltet, um einen Ausdruck von mindestens einer X, Y-Position innerhalb eines Bildframes zu erfassen und den Ausdruck in eine lineare Speicheradresse zu konvertieren.
Computersystem nach Anspruch 21, wobei mindestens eine der Zeilenpuffereinheiten einen Modus „Vollzeilengruppe“ unterstützt.
Computersystem nach Anspruch 21, wobei mindestens eine der Zeilenpuffer-Schnittstelleneinheiten verknüpft ist, um etwaige der folgenden Informationen von einem Konfigurationsregisterbereich zu empfangen: a) Anzahl der Kanäle in Bildinformationen; b) Anzahl der Abnehmer einer Zeilengruppe; c) Breite einer Gruppeneinheit mit voller Zeile; d) Höhe einer Gruppe mit voller Zeile; e) eine Dimension eines kleineren Abschnitts einer Zeilengruppe.
Computersystem nach Anspruch 22, wobei die Zeilenpuffereinheit eine Zeigerschaltung beinhaltet, um zu erfassen, wo sich die nächsten abzurufenden Bilddaten im Speicher befinden.