DE112018002568T5

DE112018002568T5 - Verfahren, Systeme und Vorrichtung zur Reduzierung von Speicherlatenz beim Abrufen von Pixelkernen

Info

Publication number: DE112018002568T5
Application number: DE112018002568.3T
Authority: DE
Inventors: Richard Boyd; Richard RICHMOND
Original assignee: Movidius Ltd Ireland; Movidius Ltd Netherland
Current assignee: Movidius Ltd Ireland; Movidius Ltd Netherland
Priority date: 2017-05-19
Filing date: 2018-05-18
Publication date: 2020-02-27
Also published as: CN111108527A; WO2018211122A1; CN111108527B; CN116881180A; KR102636925B1; US20220188969A1; US11170463B2; US20200175646A1; KR20200020704A; US11620726B2

Abstract

Verfahren, Systeme, Vorrichtungen und Herstellungsgegenstände zum Reduzieren von Pixelübertragungslatenz beim Abrufen von Pixelkern sind offenbart. Eine Beispielvorrichtung enthält eine Prefetch-Kern-Abrufeinrichtung zum Erzeugen eines Block-Tags basierend auf einer ersten Anforderung von einem Hardwarebeschleuniger, wobei die erste Anforderung erste Koordinaten eines ersten Pixels enthält, das in einem ersten Bildblock angeordnet ist, eine Speicherschnittstellen-Maschine zum Speichern des ersten Bildblocks, der eine Vielzahl von Pixeln enthält, die das Pixel enthalten, in einen Cache-Speicher basierend auf dem Block-Tag, und eine Kern-Abrufeinrichtung zum Zugreifen auf zwei oder mehr Speichervorrichtungen, die im Cache-Speicher enthalten sind, parallel zum Übertragen einer Vielzahl von Bildblöcken, die den ersten Bildblock enthalten, wenn eine zweite Anforderung empfangen wird, die zweite Koordinaten eines zweiten Pixels enthält, das im ersten Bildblock angeordnet ist.

Description

VERWANDTE ANMELDUNG
Dieses Patent ergibt sich aus einer Anmeldung, die den Vorteil der provisorischen US-Patentanmeldung mit Nummer 62/508,886 beansprucht, die am 19. Mai 2017 eingereicht wurde. Die provisorische US-Patentanmeldung mit Nummer 62/508,886 wird hierin durch Verweis in ihrer Gesamtheit aufgenommen. Die Priorität der provisorischen US-Patentanmeldung mit Nummer 62/508,886 wird hiermit beansprucht.
GEBIET DER OFFENBARUNG
Diese Offenbarung bezieht sich im Allgemeinen auf Bildverarbeitung und insbesondere auf Verfahren, Systeme und Vorrichtungen zur Reduzierung von Speicherlatenz beim Abrufen von Pixelkernen.
HINTERGRUND
In den letzten Jahren ist die Nachfrage nach Bildverarbeitungsmöglichkeiten über leistungsstarke dedizierte Desktop-Hardware hinausgegangen und zu einer Erwartung für persönliche und/oder anderweitig mobile Geräte geworden. Mobile Geräte enthalten typischerweise Verarbeitungsmöglichkeiten, die durch Größenbeschränkungen, Temperaturverwaltungsbeschränkungen und/oder Stromversorgungsbeschränkungen eingeschränkt sind.
Figurenliste

1 ist eine schematische Darstellung eines exemplarischen Pre-Fetch-Block-Caches (PFBC) zur Implementierung der hierin offenbarten Beispiele.
2 ist ein Blockdiagramm einer exemplarischen Implementierung einer exemplarischen Prefetch-Maschine zur Implementierung des exemplarischen PFBC von 1.
3 stellt ein exemplarisches Eingabebild dar, das auf einen Cache-Speicher basierend auf der Morton-Ordnung abgebildet ist.
4 stellt das Eingabebild von 3 dar, das auf den Cache-Speicher basierend auf der Spalten-Hauptordnung abgebildet ist.
5 zeigt schematische Darstellungen von exemplarischen Blockorganisationen, die vom Beispiel PFBC von 1 und/oder der exemplarischen Prefetch-Maschine von 2 verwendet werden, um Daten aus dem Cache-Speicher zu lesen.
6 stellt eine Beispieltabelle dar, die Beispielsignale beschreibt, die dem PFBC von 1 zugeordnet sind.
7 stellt ein exemplarisches Zeitdiagramm dar, das dem PFBC von 1 im Betrieb entspricht.
8 stellt eine weitere Beispieltabelle dar, die Beispielsignale beschreibt, die dem PFBC von 1 zugeordnet sind.
9 zeigt ein weiteres exemplarisches Zeitdiagramm, das dem PFBC von 1 im Betrieb entspricht.
10 stellt ein exemplarisches Tag dar, um Pixelkoordinaten auf zwischengespeicherte Daten basierend auf Morton-Ordnung und einer Pixelgröße von 2 Bytes (2B) abzubilden.
11 stellt ein exemplarisches Tag dar, um Pixelkoordinaten auf zwischengespeicherte Daten basierend auf Morton-Ordnung und einer Pixelgröße von 1 Byte (1B) abzubilden.
12 stellt ein exemplarisches Tag dar, um Pixelkoordinaten auf zwischengespeicherte Daten basierend auf Set-Organisation gemäß Spalten-Hauptordnung und einer Pixelgröße von 2 Byte (2B) abzubilden.
13 stellt ein exemplarisches Tag dar, um Pixelkoordinaten auf zwischengespeicherte Daten basierend auf der Set-Organisation gemäß Spalten-Hauptordnung und einer Pixelgröße von 1 Byte (1B) abzubilden.
14 stellt einen exemplarischen Tag-Speicher-Eintrag für einen exemplarischen 4-Way-Cache dar.
15 stellt eine exemplarische spekulative Build-Anforderung dar, um Daten aus dem exemplarischen Speicher abzurufen.
16 veranschaulicht ein Blockdiagramm einer exemplarischen Implementierung eines exemplarischen Warp-Filters, der den PFBC von 1 enthält.
17 ist eine exemplarische Fischaugen-Transformation, die durch den exemplarischen Warp-Filter von 16 verarbeitet wird, um Verzerrungen zu entfernen.
18 ist eine schematische Darstellung von exemplarischen, expandierten Gitterpunkten.
19 veranschaulicht ein Beispielbild, das durch den exemplarischen Warp-Filter von 16 in gleiche Kacheln aufgeteilt wurde.
20 stellt eine exemplarische Speicherorganisation von Gitterpunkten im FP32-Format dar.
21 stellt eine exemplarische Speicherorganisation von Gitterpunkten im 16-Bit-Format dar.
22 stellt eine exemplarische Speicherorganisation von vorab expandierten Gitterpunkten dar.
23 zeigt ein Beispiel für Blöcke und Superblöcke, die im exemplarischen PFBC im Beispiel von 16 verwendet werden.
24 ist ein Flussdiagramm, das exemplarische maschinenlesbare Anweisungen darstellt, die ausgeführt werden können, um den exemplarischen PFBC von 1 und/oder die exemplarische Prefetch-Maschine von 2 zu implementieren, um eine exemplarische Anforderung zu verarbeiten, die an einer exemplarischen Prefetch-Schnittstelle empfangen wurde.
25 ist ein Flussdiagramm, das exemplarische maschinenlesbare Anweisungen darstellt, die ausgeführt werden können, um den exemplarischen PFBC von 1 und/oder die exemplarische Prefetch-Maschine von 2 zu implementieren, um ein exemplarisches Tag im exemplarischen Tag-Speicher zu speichern.
26 ist ein Flussdiagramm, das exemplarische maschinenlesbare Anweisungen darstellt, die ausgeführt werden können, um den exemplarischen PFBC von 1 und/oder die exemplarische Prefetch-Maschine von 2 zu implementieren, um eine exemplarische Anforderung zu verarbeiten, die an einer exemplarische Anforderung-Schnittstelle empfangen wurde.
27 ist ein Flussdiagramm, das exemplarische maschinenlesbare Anweisungen darstellt, die ausgeführt werden können, um den exemplarischen PFBC von 1 und/oder die exemplarische Prefetch-Maschine von 2 zu implementieren, um exemplarische spekulative Block-Anforderungen zu erstellen.
28 ist ein Blockdiagramm einer exemplarischen Prozessorplattform, die so aufgebaut ist, dass sie die exemplarischen maschinenlesbaren Anweisungen von mindestens 24-27 ausführt, um den exemplarischen PFBC von 1 zu implementieren.
29 ist ein Blockdiagramm einer exemplarischen Prozessorplattform, die so aufgebaut ist, dass sie die exemplarischen maschinenlesbaren Anweisungen von mindestens 24-27 ausführt, um die exemplarische Prefetch-Maschine von 2 zu implementieren.

Die Figuren sind nicht maßgerecht. Im Allgemeinen werden in den gesamten Zeichnung(en) und in der dazugehörigen schriftlichen Beschreibung dieselben Bezugszeichen verwendet, um auf dieselben oder ähnliche Teile zu verweisen.
DETAILLIERTE BESCHREIBUNG
Typische Computersysteme, einschließlich persönlicher und/oder anderweitig mobiler Geräte, verwenden fortschrittliche Bildverarbeitungs- oder Computer-Vision-Algorithmen, um Aufgaben zu automatisieren, die menschliche visuelle Systeme ausführen können. Zu Computer-Vision-Aufgaben gehören Erfassen, Verarbeiten, Analysieren und Verstehen von digitalen Bildern, was zum Teil Extraktion von Dimensionsdaten aus den digitalen Bildern zur Erzeugung numerischer und/oder symbolischer Information erleichtert. Computer-Vision-Algorithmen können die numerischen und/oder symbolische Information verwenden, um Entscheidungen zu treffen und/oder anderweitig Operationen durchzuführen, die unter anderem mit dreidimensionaler (3-D) Stellungsschätzung, Ereigniserfassung, Objekterkennung, Videonachverfolgung etc. verbunden sind.
Um digitale Bilder zu verarbeiten, holt die Computerhardware Bilddaten, die mit Pixeln in den digitalen Bildern verknüpft sind, um einen Pixelkern zu füllen. Pixel können die kleinste Komponente eines digitalen Bildes oder das kleinste steuerbare Element einer Anzeige darstellen (z. B. eine Flüssigkristallanzeige (LCD), eine organische Leuchtdiodenanzeige (OLED) etc.). Wie hierin verwendet, bezieht sich der Begriff „Pixelkern“ auf eine Zusammensetzung aus zwei oder mehr Pixeln (z. B. eine Pixelmatrix), die ein Pixel an gegebenen Koordinaten in einem Eingabebild (z. B. ein Kamerabild, ein Videobild usw.) und eine Menge von Pixeln um das Pixel herum enthält, die für die Verarbeitung des Pixels erforderlich ist. Pixelkerne können eine Matrix von Pixeln darstellen (z. B. ein 1×1 Pixelkern, ein 2x2 Pixelkern, ein 1x4 Pixelkern etc.). Die Menge der Pixel in Breite und die Menge der Pixel in Höhe des Pixelkerns wird als Stütze des Kerns bezeichnet. In einigen Fällen enthalten die Bilddaten Pixeldaten, die einem oder mehreren Pixeln einschließlich Pixelkoordinaten zugeordnet sind. Pixelkoordinaten können einen physikalischen Punkt oder eine Lokalisierung eines Pixels in einem Bild (z. B. einem Rasterbild) oder eine Komponente einer Anzeige identifizieren.
In früheren Implementierungen speicherte die Computerhardware einige benachbarte Pixel eines Bildes im Speicher mit räumlicher Lokalität, während andere benachbarte Pixel ohne räumliche Lokalität gespeichert wurden. Räumliche Lokalität bezieht sich auf ein Konzept, bei dem auf Datenelemente, die zusammen gespeichert sind, höchstwahrscheinlich gemeinsam zugegriffen wird. In Fällen, in denen benachbarte Pixel im Bild mit räumlicher Lokalität gespeichert werden, konnte die Computerhardware einen Pixelkern aus einem einzigen gelesenen Speicher rekonstruieren. In Fällen, in denen benachbarte Pixel im Bild nicht mit räumlicher Lokalität gespeichert werden (z. B. ein erstes Pixel befindet sich in einer ersten Adresszeile eines Speichers und ein zweites Pixel in einer zweiten Adresszeile des Speichers), muss die Computerhardware mehrere Speicherlesungen durchführen, um den Pixelkern zur Verarbeitung zu rekonstruieren, was zu einer Erhöhung der Speicherlatenz der Computerhardware führt.
Die hierin offenbarten Beispiele reduzieren Speicherlatenz und verbessern Pixeldaten-Übertragung zwischen Speichervorrichtungen und Pixelverarbeitungshardware (z. B. Bildverarbeitungshardware, Computer-Vision-Hardware etc.). Beispiele, die hierin offenbart werden, rufen Daten vorab aus dem Hauptspeicher (z. B. dynamischem RAM (DRAM), Verbindungsmatrix (CMX)-Speicher usw.) ab, verarbeiten die Daten zu Blöcken von Bilddaten gemäß der räumlichen Lokalität und speichern die Blöcke von Bilddaten oder Datenblöcke im Cache-Speicher. Die hierin offenbarten Beispiele arbeiten mit Blöcken von Pixeln oder Pixelkernen als Grundeinheit, um sie aus dem Cache-Speicher abzurufen.
In einigen offenbarten Beispielen ruft ein Pre-Fetch-Block-Cache (PFBC) (z. B. eine Vorrichtung) vorab Daten, die von einem Computersystem angefordert werden, aus dem Hauptspeicher des Computersystems ab. In einigen offenbarten Beispielen sind die angeforderten Daten Bilddaten (z. B. Pixeldaten) an angeforderten Pixelkoordinaten, die den Pixeln eines Eingabebildes entsprechen, das vom Computersystem verarbeitet wird. In einigen offenbarten Beispielen bildet der PFBC die angeforderten Pixelkoordinaten auf Bildblöcke ab und speichert die Bildblöcke im Cache-Speicher, der im PFBC enthalten ist. In einigen offenbarten Beispielen bildet der PFBC die Pixelkoordinaten auf die Bildblöcke ab, indem er Tags basierend auf den Pixelkoordinaten erzeugt und die Tags im Tag-Speicher speichert, der im PFBC enthalten ist. In einigen offenbarten Beispielen ist der PFBC dazu eingerichtet, spekulativ eine Menge anderer Bildblöcke links und/oder rechts von einem angeforderten Bildblock anzufordern. Alternativ kann der exemplarische PFBC dazu eingerichtet sein, spekulativ eine Menge anderer Bildblöcke über und/oder unter einem angeforderten Bildblock anzufordern.
Wenn der exemplarische PFBC bestimmt, dass ein angeforderter Bildblock im Cache-Speicher zwischengespeichert ist, organisiert der PFBC die den angeforderten Daten zugeordneten Bildblöcke einschließlich des angeforderten Bildblocks in einer Burst-Übertragung (z. B. eine einzelne Takt-Burst-Übertragung) und überträgt die angeforderten Bildblöcke zur Verarbeitung an externe Hardware. In einigen offenbarten Beispielen enthalten die übertragenen Bildblöcke Bilddaten, die den angeforderten Daten durch das Computersystem zugeordnet sind, und/oder die Bilddaten, die den spekulativ angeforderten Blöcken zugeordnet sind.
In einigen offenbarten Beispielen kann der PFBC verwendet werden, um Arten von Verzerrungen in Quellbildern, Quellvideobildern usw. zu entfernen. Beispielsweise können Quellbilder und/oder Quellvideobilder manchmal unerwünschte Verzerrungen enthalten. Vorherige Ansätze zur Beseitigung von Verzerrungen verwenden typischerweise Dynamic Random Access Memory (DRAM) auf eine Weise, die eine erhebliche Latenzzeit beinhaltet. Um Arten von Verzerrungen wie zum Beispiel Fischaugenverzerrung zu entfernen, enthalten die hierin offenbarten Beispiele Transformationsalgorithmen, Anweisungen und/oder Hardware, einschließlich des exemplarischen PFBC, um die bei vorherigen Ansätzen beobachtete Latenz zu reduzieren.
1 ist eine schematische Darstellung eines exemplarischen Prefetch-Block-Caches (Pre-Fetch Block Cache, PFBC) 100 zur Reduzierung und/oder anderweitigen Eliminierung von Pixelübertragungslatenz während Bildverarbeitungsvorgängen, Computer-Vision-Operationen etc. Der exemplarische PFBC 100 von 1 beinhaltet eine exemplarische Speicherschnittstelle 102, um die Datenübertragung zwischen dem PFBC 100 und der Hardware des Computersystems zu erleichtern (z. B. einen Speichercontroller, eine Zentraleinheit (CPU), einen Hardwarebeschleuniger etc.). Im veranschaulichten Beispiel von 1 ist die Speicherschnittstelle 102 eine 128-Bit-Speicher(bus)-Schnittstelle. So kann beispielsweise die Speicherschnittstelle 102 des PFBC 100 eine 128-Bit-AXI-Masterschnittstelle, eine 128-Bit-AMC-Lese-IIF-Schnittstelle usw. sein. Alternativ kann der exemplarische PFBC 100 eine Schnittstelle aufweisen, die einer beliebigen Anzahl von Bits zugeordnet ist (z. B. eine 64-Bit-Speicherschnittstelle, eine 256-Bit-Speicherschnittstelle usw.).
In dem veranschaulichten Beispiel von 1 beinhaltet die Speicherschnittstelle 102 eine exemplarische Prefetch-Schnittstelle 104, eine exemplarische Anforderungsschnittstelle 106 und eine exemplarische Datenschnittstelle 108. In dem veranschaulichten Beispiel von 1 beinhaltet die Speicherschnittstelle 102 die Prefetch-Schnittstelle 104, um Leseanforderungen (z. B. Burst-Leseanforderungen) aus exemplarischen Hauptspeicher 110 eines Computersystems auszuführen. Im veranschaulichten Beispiel von 1 ist der Hauptspeicher 110 DRAM. Alternativ kann der Hauptspeicher 110 auch ein CMX-Speicher oder eine andere Art von nichtflüchtigem oder flüchtigem Speicher sein. Die exemplarische Prefetch-Schnittstelle 104 von 1 fragt ab, empfängt und/oder ruft anderweitig Daten (z. B. Bilddaten, Pixeldaten, Pixelkoordinaten etc.) aus dem Hauptspeicher 110 ab und überträgt die abgerufenen Daten an eine exemplarische Prefetch-Einrichtung (Prefetcher) 112. Im veranschaulichten Beispiel von 1 bezieht die Prefetch-Schnittstelle 104 Pixelkoordinaten aus dem Hauptspeicher 110. Alternativ kann die exemplarische Prefetch-Schnittstelle 104 andere Information aus dem Hauptspeicher 110 erhalten, die einem Eingabebild zugeordnet ist.
Im veranschaulichten Beispiel von 1 bestimmt die Prefetch-Schnittstelle 104 Bilddaten, einschließlich Pixelkoordinaten, die aus dem Hauptspeicher 110 basierend auf einem Befehl oder einer Anweisung von einem exemplarischen Hardwarebeschleuniger 114 zu erhalten sind. So steuert beispielsweise ein Kontroller oder ein Steuerblock des Hardwarebeschleunigers 114 die Prefetch-Schnittstelle 104, um Daten aus dem Hauptspeicher 110 zu erhalten. Im veranschaulichten Beispiel von 1 ist der Hardwarebeschleuniger 114 ein Hardwarebeschleuniger für Bildverarbeitung. Alternativ kann der exemplarische Hardwarebeschleuniger 114 auch ein 3D-Beschleuniger, ein kryptographischer Beschleuniger usw. sein. Alternativ kann der exemplarische Hardwarebeschleuniger 114 als Teil einer universellen Zentraleinheit (CPU) oder in einer separaten Einheit wie einer Grafikprozessoreinheit (GPU) integriert sein.
In dem veranschaulichten Beispiel von 1 identifiziert und/oder anderweitig bestimmt der Hardwarebeschleuniger 114 Pixelkoordinaten von einem oder mehreren Pixeln, die einem Eingabebild zugeordnet sind, das von der Prefetch-Schnittstelle 104 vorab abgerufen werden soll. So kann beispielsweise der Hardwarebeschleuniger 114 Pixelkoordinaten an die Prefetch-Schnittstelle 104 übertragen, um die Prefetch-Schnittstelle 104 so zu steuern, dass sie die den Pixelkoordinaten zugeordneten Bildblöcke abruft, bevor der Hardwarebeschleuniger 114 die Pixelkoordinaten an die Datenschnittstelle 108 sendet, um die Datenschnittstelle 108 anzuweisen, die von der Prefetch-Schnittstelle 104 abgerufenen Bildblöcke zu erhalten. So kann beispielsweise der Hardwarebeschleuniger 114 Pixelkoordinaten eines Pixels identifizieren und die Prefetch-Schnittstelle 104 anweisen oder instruieren, den Hauptspeicher 110 nach den Pixelkoordinaten abzufragen. Als Reaktion darauf, dass der Hauptspeicher 110 die Abfrage empfängt, sendet der Hauptspeicher 110 die Pixelkoordinaten an die Prefetch-Schnittstelle 104, um das Abrufen von Bildblöcken zu initialisieren, die den Pixelkoordinaten zugeordnet sind.
In einigen Beispielen stellt der Hardwarebeschleuniger 114 von 1 sicher, dass eine Anforderung nach Pixelkoordinaten auf der Anforderungsschnittstelle 106 nicht vor der Anforderung durch die Prefetch-Schnittstelle 104 erfolgt. So sollte beispielsweise eine Ordnung der Pixelkoordinaten an der Anforderungsschnittstelle 106 mit der Ordnung an der Prefetch-Schnittstelle 104 übereinstimmen. In einigen Beispielen beinhaltet die Anforderungsschnittstelle 106 einen FIFO-Puffer, um die an der Anforderungsschnittstelle 106 empfangenen Pixelkoordinaten zu puffern. In solchen Beispielen werden die Pixelkoordinaten im Wesentlichen zeitgleich mit der Übernahme der gleichen Pixelkoordinaten durch die Prefetch-Schnittstelle 104 in den FIFO-Puffer geschoben. In solchen Beispielen kann die Anforderungsschnittstelle 106 die FIFO-Puffergröße so bemessen, dass sie einer typischen oder in einigen Fällen einem ungünstigsten Fall entsprechenden Latenz entspricht, die an der Speicherschnittstelle 102 oder an dem in dem PFBC 100 enthaltenen Speicher (z. B. DRAM) gesehen wird.
In einigen Beispielen erzeugt der Hardwarebeschleuniger 114 von 1 Pixelkoordinaten, die außerhalb eines Eingabebildes liegen. So kann beispielsweise der Hardwarebeschleuniger 114 die Prefetch-Schnittstelle 104 und/oder die Anforderungsschnittstelle 106 anweisen, den Zugriff auf negative Pixelkoordinaten zu ermöglichen. In solchen Beispielen klemmt die Prefetch-Schnittstelle 104 und/oder die Anforderungsschnittstelle 106 die nicht unterstützten Anforderungen auf null und/oder lässt die Anforderungen anderweitig fallen. So kann beispielsweise der PFBC 100 nur positive (ohne Vorzeichen) Eingabepixelkoordinaten unterstützen. Alternativ kann der PFBC 100 auch andere Arten von Pixelkoordinaten unterstützen.
In dem veranschaulichten Beispiel von 1 überträgt die Prefetch-Schnittstelle 104 die erhaltenen Pixelkoordinaten an ein exemplarisches Pixeldaten-First-In-First-Out (FIFO)-Puffer 116, um die von der Prefetch-Schnittstelle 104 erhaltene Pixelkoordinate (temporär) zu speichern. Der Pixeldaten-FIFO-Puffer 116 von 1 ist ein Hardware-Schieberegister. So kann beispielsweise der Pixeldaten-FIFO-Puffer 116 Frame-Puffer implementieren. Alternativ kann der Pixeldaten-FIFO-Puffer 116 ein Ringspeicher oder eine andere Art von Warteschlangenstruktur sein, die mit hardware- oder maschinenlesbaren Anweisungen implementiert ist. Der Pixeldaten-FIFO-Puffer 116 von 1 überträgt (z. B. überträgt asynchron) die Pixelkoordinaten auf einer First-In-First-Out-Basis an die Prefetch-Einrichtung 112.
Im veranschaulichten Beispiel von 1 erzeugt und speichert die Prefetch-Einrichtung 112 exemplarische Tag(s) 120 im exemplarischen Tag-Speicher 122 und/oder holt spekulativ Bildblöcke basierend auf Pixelkoordinaten, die über die Prefetch-Schnittstelle 104 erhalten wurden. Im veranschaulichten Beispiel von 1 beinhalten die Tags 120 Block-Tag-Felder, die verwendet werden, um angeforderte Pixelkoordinaten auf gespeicherte Bildblockdaten im PFBC 100 abzubilden. So können beispielsweise die Tags 120 einem in den 10-13 dargestellten exemplarischen Tag 1000, 1100, 1200, 1300 entsprechen. So können beispielsweise die Block-Tag-Felder einem in den 10-13 dargestellten exemplarischen Block-Tag-Feld 1002, 1102, 1202, 1202, 1302 entsprechen. Die exemplarische Prefetch-Einrichtung 112 beinhaltet eine exemplarische Tag-Abbildungseinrichtung (Tag-Mapper) 124 und eine exemplarische Erstellungseinrichtung für spekulative Blockanforderung (Speculative Block Request (SBR) Builder) 126. Die exemplarische Prefetch-Einrichtung 112 beinhaltet die exemplarische Tag-Abbildungseinrichtung 124, um Pixelkoordinaten in die exemplarischen Tags 120 zu übersetzen und/oder anderweitig zu konvertieren und die Tags 120 im exemplarischen Tag-Speicher 122 zu speichern. In einigen Beispielen beinhalten die Tags 120 ein oder mehrere Block-Tag-Bits und/oder ein oder mehrere Indexfelder (z. B. ein Set-Indexfeld, ein Pixel-Indexfeld- etc.), wobei jedes Indexfeld ein oder mehrere Indexbits (z. B. ein oder mehrere Set-Indexbits, ein oder mehrere Pixel-Indexbits etc.) enthält.
Im veranschaulichten Beispiel von 1 beinhaltet der Tag-Speicher 122 vier exemplarische Tag-Datenspeicher 128. Obwohl in 1 vier Tag-Speicher 128 dargestellt sind, können weniger oder mehr als vier Tag-Datenspeicher 128 verwendet werden. In 1 ist der exemplarische Tag-Speicher 122 als Register implementiert, um die Einfachheit von mehrfachen, im Wesentlichen parallelen Zugriff zu ermöglichen. Alternativ kann der Tag-Speicher 122 CMX, DRAM usw. oder jede andere Art von nichtflüchtigem Speicher oder flüchtigem Speicher sein. Die exemplarische Prefetch-Schnittstelle 104 und/oder die exemplarische Anforderungsschnittstelle 106 können gleichzeitig und/oder anderweitig im Wesentlichen gleichzeitig auf jeden der vier Tag-Datenspeicher 128 parallel zugreifen. Die exemplarische Prefetch-Schnittstelle 104 und/oder die exemplarische Anforderungsschnittstelle 106 können einen der exemplarischen Tag-Datenspeicher 128 basierend auf den beiden niederwertigsten Bits eines Set-Index auswählen, der in einem Tag enthalten ist, der basierend auf den angeforderten Pixelkoordinaten erzeugt ist. So kann beispielsweise die Tag-Abbildungseinrichtung 124 Pixelkoordinaten in ein Tag mit einem Block-Set-Index umwandeln. Die exemplarische Tag-Abbildungseinrichtung 124 kann die beiden niederwertigsten Bits des Block-Set-Index auf ein erstes der in einem ersten der Tag-Datenspeicher 128 enthaltenen Tag 120 abbilden.
In dem veranschaulichten Beispiel von 1 beinhaltet jeder der Tag-Datenspeicher 128 acht exemplarische Einträge 130, wobei jeder Eintrag vier exemplarische Abschnitte 132 enthält, die einem anderen Weg entsprechen. Jeder exemplarische Abschnitt 132 enthält das entsprechende Tag 120, ein exemplarisches Zählfeld (COUNT) 134 und ein exemplarisches Pending-Feld (PEND) 135. So kann beispielsweise das Zählfeld 134 einem exemplarischen Zählfeld 1412 entsprechen, das in 14 dargestellt ist. So kann beispielsweise das Pending-Feld 135 einem exemplarischen Pending-Feld 1414 entsprechen, das in 14 dargestellt ist. So kann beispielsweise das Pending-Feld 135 ein 1-Bit-Feld (z. B. ein binäres Schaltfeld) sein, das einen Wert von entweder null oder eins hat. Wenn das Pending-Feld 135 null ist, ist das Pending-Feld 135 deaktiviert, und wenn das Pending-Feld 135 eins ist, ist das Pending-Feld 135 aktiviert. Zusätzlich oder alternativ kann der exemplarische Abschnitt 132 weniger oder mehr Tags, Felder usw. enthalten. So kann beispielsweise der Abschnitt 132 ein exemplarisches Validierungsfeld beinhalten, das einem exemplarischen Validierungsfeld 1416 entspricht, das in 14 dargestellt ist. Der exemplarische Tag-Speicher 122 beinhaltet 32 der Einträge 130, wobei jeder entsprechende Eintrag 130 vier der Tags 120 beinhaltet. Alternativ kann jeder der Tag-Datenspeicher 128 weniger oder mehr als acht Einträge 130 beinhalten. Alternativ kann jeder Eintrag 130 weniger oder mehr als vier Abschnitte 132 beinhalten.
Wie hierin verwendet, ist ein Weg (wie in N-Wege) die Anzahl der verschiedenen Wege (z. B. Speicherorientierungen, Speicherkonfigurationen, Abbildungsordnungen etc.), auf die ein bestimmter Block zwischengespeichert werden kann. Beispielsweise werden mehrere Blöcke (z. B. aus dem Hauptspeicher 110) auf die gleiche Blocklokalisierung innerhalb eines Sets abgebildet, wenn der Cache N-Wege-Set assoziativ ist, können bis zu N Blöcke, die auf die gleiche Blocklokalisierung innerhalb eines Sets abgebildet werden, zwischengespeichert werden. Wie hierin verwendet, ist ein Block (z. B. ein Bildblock) eine zweidimensionale Anordnung von Pixeln. Wie hierin verwendet, ist ein Set eine zweidimensionale Anordnung von Blöcken. Wie hierin verwendet, ist ein Pixel-Index die niederwertigsten Bits von X und Y einer Pixelkoordinaten-Sets, die zusammen einen Index für die Lokalisierung dieses Pixels innerhalb eines Blocks ergeben. Wie hierin verwendet, ist ein Blocklokalisierung-Index oder ein Set-Index eine spezifische Abbildung bestimmter Bits aus einem Pixelkoordinaten-Set, die einen Index zu der Lokalisierung liefert, an der sich der Bildblock, der dieses Pixel enthält, in einem Set befindet. Wie hierin verwendet, ist ein Block-Tag oder ein Tag die wichtigsten Bits von X und Y eines Pixelkoordinaten-Sets, die einen Block eindeutig in Bezug auf andere Blöcke identifizieren, die an der gleichen Blocklokalisierung innerhalb eines Sets zwischengespeichert werden können.
In dem veranschaulichten Beispiel von 1 durchsucht die Tag-Abbildungseinrichtung 124 als Reaktion darauf, dass die Prefetch-Schnittstelle 104 die Pixelkoordinaten empfängt, jeden der Tag-Datenspeicher 128 parallel, um eine anfängliche Entscheidung in einem einzigen Taktzyklus (z. B. eine Treffer-Entscheidung in einem einzigen Taktzyklus, eine Fehler-Entscheidung in einem einzigen Taktzyklus usw.) für bis zu N Blöcke zu erzeugen, um einen Pixelkern von N Blöcken (z. B. mit N 4, 8, 16 usw.) zu erzeugen, der erforderlich sein kann, um das Pixel an den Pixelkoordinaten zu verarbeiten. In einigen Beispielen entspricht die Treffer-Entscheidung Bilddaten, die den Pixelkoordinaten zugeordnet sind, die bereits vom PFBC 100 zwischengespeichert wurden. In einigen Beispielen entspricht die Fehler-Entscheidung Bilddaten, die den Pixelkoordinaten zugeordnet sind, die nicht bereits vom PFBC 100 zwischengespeichert wurden.
In einigen Beispielen implementiert der PFBC 100 einen Sicherheitsmechanismus, um sicherzustellen, dass ein oder mehrere Bildblöcke, die einer Anforderung an der Prefetch-Schnittstelle 104 oder der Anforderungsschnittstelle 106 entsprechen, während nachfolgender Taktzyklen des PFBC 100 zwischengespeichert werden und nicht ersetzt werden, bis die entsprechende Anforderung auf der Datenschnittstelle 108 erfüllt ist. In solchen Beispielen verwenden die Tag-Abbildungseinrichtung 124 und/oder eine exemplarische Lese-Tag-Abbildungseinrichtung 152 das Zählfeld 134, um den Sicherheitsmechanismus zu implementieren. So erhöht beispielsweise die Tag-Abbildungseinrichtung 124 das Zählfeld 134 für ein entsprechendes Tag 120 jedes Mal, wenn Bilddaten, die dem Tag 120 zugeordnet sind, an der Prefetch-Schnittstelle 104 angefordert werden. In anderen Beispielen verringert die Lese-Tag-Abbildungseinrichtung 152 das Zählfeld 134 für das entsprechende Tag 120 jedes Mal, wenn Bilddaten, die dem Tag 120 zugeordnet sind, an der Anforderungsschnittstelle 106 angefordert werden. Infolgedessen können die in einem exemplarischen Cache-Datenspeicher 148 gespeicherten Bilddaten ersetzt werden, wenn und nur wenn das entsprechende Zählfeld 134 für die gespeicherten Bilddaten null und das Pending-Feld 135 für die gespeicherten Bilddaten null ist (z. B. die gespeicherten Bilddaten stehen nicht zur Verarbeitung an).
In einigen Beispielen, wenn das Zählfeld 134 nicht null ist, dann wurden einige Anforderungen, die an der Prefetch-Schnittstelle 104 akzeptiert wurden, von der Datenschnittstelle 108 noch nicht erfüllt, so dass die entsprechenden in einem exemplarischen Cache-Speicher 146 gespeicherten Bildblockdaten beibehalten werden müssen. So kann beispielsweise der entsprechende Bildblock nicht verworfen, überschrieben, ersetzt usw. werden, bis das Zählfeld 134 null wird. In einigen Beispielen, wenn das Zählfeld 134 null ist, aber das Pending-Feld 135 gesetzt ist (z. B. auf 1), dann wurden die Bildblockdaten von der SBR-Erstellungseinrichtung 126 spekulativ vorab abgerufen. In solchen Beispielen können die Bildblockdaten nie angefordert werden, sondern wurden spekulativ abgerufen, um eine Effizienz beim Erfüllen einer zukünftigen Anforderung zu verbessern, die die spekulativ abgerufenen Bildblockdaten benötigte.
In einigen Beispielen, wenn das Pending-Feld 135, das in einem der Einträge 130 enthalten ist, gesetzt ist und das entsprechende Zählfeld 134 null ist, wurde der entsprechende Eintrag 130 spekulativ geholt, wird aber derzeit im Cache-Speicher 146 zwischengespeichert. So ist beispielsweise der spekulativ geholte Eintrag 130 kein Ersetzungskandidat ist, solange die dem Eintrag 130 zugeordneten Bildblockdaten zwischengespeichert sind. Als Reaktion auf die im Cachespeicher 146 zwischengespeicherten Bildblockdaten löscht eine exemplarische Cache-Fülleinrichtung (cache filler) 144 das Pending-Feld 135 und setzt ein im Eintrag 130 enthaltenes Validierungsfeld (z. B. setzt auf 1). Als Reaktion auf das Löschen des Pending-Feldes 135 und das Setzen des Validierungsfeldes wird der Eintrag 130 zum Ersetzungskandidaten.
Die exemplarische SBR-Erstellungseinrichtung 126 von 1 erzeugt nach einer Fehler-Entscheidung einen oder mehrere SBRs. Die exemplarische SBR-Erstellungseinrichtung 126 erzeugt einen oder mehrere SBRs, um längere Burst-Transaktionen auf der Speicherschnittstelle 102 zu ermöglichen und/oder Zugriff auf Bildblöcke zu erhalten, die im Voraus zur Verarbeitung durch das Computersystem benötigt werden. Die exemplarische SBR-Erstellungseinrichtung 126 erzeugt und sendet SBRs an einen exemplarischen SBR-FIFO 136. Der exemplarische SBR-FIFO 136 von 1 überträgt die SBR-Anforderungen der SBR-Erstellungseinrichtung 126 auf einer First-In-First-Out-Basis an eine exemplarische Block-Abrufeinrichtung 138. Die exemplarische Block-Abrufeinrichtung 138 von 1 ruft ab und/oder anderweitig erlangt Blöcke von Bilddaten aus dem Hauptspeicher 110 über eine exemplarische Block-Abrufeinrichtungsschnittstelle 140, die in der Speicherschnittstelle 102 enthalten ist, basierend auf Pixelkoordinaten, die von der Prefetch-Schnittstelle 104 empfangen werden. In einigen Beispielen erhält die Block-Abrufeinrichtung 138 Bildblöcke, die den Pixelkoordinaten entsprechen, die von der Prefetch-Schnittstelle 104 über die Block-Abrufeinrichtungsschnittstelle 140 empfangen werden. In einigen Beispielen erhält die Block-Abrufeinrichtung 138 über die Block-Abrufeinrichtungsschnittstelle 140 einen Bildblock auf der linken oder rechten Seite (z. B. ein benachbarter Bildblock) des Bildblocks, der den Pixelkoordinaten entspricht. Alternativ kann die exemplarische Block-Abrufeinrichtung 138 dazu einrichtet sein, einen Bildblock über oder unter dem Bildblock, der den Pixelkoordinaten entspricht, über die Block-Abrufeinrichtungsschnittstelle 140 zu erhalten
In dem veranschaulichten Beispiel von 1 beinhaltet die Block-Abrufeinrichtung 138 einen exemplarischen Adressgenerator 142, um eine Adresse (z. B. eine Adresszeile) des Hauptspeichers 110 zu erzeugen, die einer Lokalisierung eines Bildblocks von Interesse im Hauptspeicher 110 entspricht. So kann beispielsweise der Adressgenerator 142 bestimmen, dass sich ein Bildblock, der den Pixelkoordinaten eines von der Prefetch-Schnittstelle 104 empfangenen angeforderten Pixels entspricht, an einer Adresse des Hauptspeichers 110 befindet. In solchen Beispielen kann der Adressgenerator 142 die Adresse erzeugen und die Block-Abrufeinrichtungsschnittstelle 140 anweisen, den Bildblock an der erzeugten Adresse aus dem Hauptspeicher 110 abzurufen.
In dem veranschaulichten Beispiel von 1 beinhaltet die Block-Abrufeinrichtung 138 die exemplarische Cache-Fülleinrichtung 144, um einen Bildblock aus dem Hauptspeicher 110, der von der Block-Abrufeinrichtungsschnittstelle 140 angefordert wurde, an einer vom Adressgenerator 142 erzeugten Adresse abzurufen und/oder anderweitig zu erhalten. Als Reaktion auf das Empfangen des angeforderten Bildblocks speichert die exemplarische Cache-Fülleinrichtung 144 den Bildblock im exemplarischen Cache-Speicher 146. So kann beispielsweise die Cache-Fülleinrichtung 144 den Bildblock in einem der Cache-Datenspeicher (z. B. RAM[0], RAM[1], RAM[2], RAM[3]) 148 im Cache-Speicher 146 speichern. Alternativ kann der Cache-Speicher 146 auch weniger oder mehr als vier Cache-Datenspeicher 148 beinhalten.
In einigen Beispielen empfängt die Cache-Fülleinrichtung 144 Blöcke aus dem Hauptspeicher 110 in der gleichen Ordnung, in der die Bildblöcke von der SBR-Erstellungseinrichtung 126 angefordert werden. So kann beispielsweise eine erste und letzte Datenzeile für jeden Block in der gleichen Ordnung empfangen werden, in der die Bildblöcke angefordert werden. In einigen Beispielen speichert die Cache-Fülleinrichtung 144 die abgerufenen Daten im Cache-Speicher 146 basierend auf den Pixelkoordinaten des ersten Blocks der Anforderung und dem Takt (beat) der gelesenen Daten. So kann beispielsweise die Cache-Fülleinrichtung 144 die X-Koordinate des Bildblocks mit jedem Takt von jedem Burst um eins erhöhen. Zu Beginn jedes Bursts wird die X-Koordinate des Bildblocks auf die des ersten Blocks der Anforderung zurückgesetzt, während die Y-Koordinate aller Blöcke der Anforderung gleich ist.
In einigen Beispielen schreibt die Cache-Fülleinrichtung 144 die Bildblockdaten in den Cache-Speicher 146 basierend auf einer von der SBR-Erstellungseinrichtung 126 erzeugten SBR. So kann beispielsweise der Burst-Takt-Zähler verwendet werden, um die SBR zu indexieren und den Weg zu lesen, in welchen Block entsprechend dem aktuellen Takt geschrieben wird. In einigen Beispielen schreibt die Cache-Fülleinrichtung 144 die aus dem Hauptspeicher 110 abgerufenen Bildblockdaten in den Cache-Speicher 146 basierend auf den niederwertigsten Bits des Set-Index, der in dem entsprechenden Tag 120 enthalten ist. Zum Beispiel wird für einen gegebenen Takt eines Bursts der richtige Cache-Datenspeicher 148, in den die Bildblockdaten zu schreiben sind, durch die niederwertigsten Bits des Set-Index ausgewählt wird, wobei der Rest der Adresse auf den restlichen Bits des Set-index und dem Weg basiert.
In einigen Beispielen schreibt die Cache-Fülleinrichtung 144 nur eine Zeile von Pixeln eines Blocks für jeden Takt eines Bursts. Die Burst-Nummer wird beispielsweise verwendet, um eine Byte/Bit-Schreib-Aktivierungsmaske für jeden Takt zu steuern, wobei insgesamt acht Bursts zur Vervollständigung einer SBR verwendet werden können. In einigen Beispielen wechselt die Aktivierungsmaske nur zwischen den Bursts, da die Aktivierungsmaske zwischen den Takten innerhalb des Bursts konstant ist. In einigen Beispielen aktualisiert die Cache-Fülleinrichtung 144 das entsprechende Tag 120 im Tag-Speicher 122 auf den letzten Burst. Wenn beispielsweise die letzte Zeile von Daten für jeden Block empfangen und in den Cache-Speicher 146 geschrieben wird, löscht die Cache-Fülleinrichtung 144 das Pending-Feld 135 und setzt das Validierungsfeld des Tags 120.
In einigen Beispielen aktualisiert und/oder anderweitig benachrichtigt die Cache-Fülleinrichtung 144 eine exemplarische Blockdaten-Leseeinrichtung 150, dass ein Bildblock im Cache-Speicher 146 gespeichert wurde, der den empfangenen Pixelkoordinaten durch die Anforderungsschnittstelle 106 entspricht. In einigen Beispielen aktualisiert die Cache-Fülleinrichtung 144 eines der Tags 120, das im Tag-Speicher 122 enthalten ist, entsprechend dem Bildblock. So kann beispielsweise die Cache-Fülleinrichtung 144 das Tag 120 aktualisieren, um das Tag 120 an einer Lokalisierung des Bildblocks im Cache-Speicher 146 zuzuordnen.
In dem veranschaulichten Beispiel von 1 bezieht die Block-Abrufeinrichtung 138 Bilddaten aus dem Hauptspeicher 110 basierend auf Konfigurationsinformation, die von einem exemplarischen Pixelkern-Konfigurator 147 empfangen wurden. Der exemplarische Pixelkern-Konfigurator 147 überträgt Konfigurationsinformation an die Block-Abrufeinrichtung 138, einschließlich einer Basisadresse zum Ausrichten der Block-Abrufeinrichtungsschnittstelle 140 an die Speicherschnittstelle 102 Datenbreite in Bytes, einem Zeilenschritt in Bytes, der ein Vielfaches der Datenbreite der Speicherschnittstelle 102 ist, einer Rahmenbreite, einer Rahmenhöhe und einer Menge von Bytes pro Pixel. In einigen Beispielen, wenn die Block-Abrufeinrichtungsschnittstelle 140 im Ringpuffermodus arbeitet, beinhalten die Konfigurationsinformation eine Menge von abzurufenden Adresszeilen und eine aktuelle Adresszeile, die angibt, welche Zeile des Ringpuffers aktuell die oberste Zeile ist. In einigen Beispielen basiert die Menge der abzurufenden Adresszeilen auf einer Zweierpotenz. Als Reaktion auf das Empfangen der Konfigurationsinformation kann die Block-Abrufeinrichtung 138 die Block-Abrufeinrichtungsschnittstelle 140 konfigurieren, um basierend auf der Konfigurationsinformation Bildblockdaten aus dem Hauptspeicher abzurufen.
Im veranschaulichten Beispiel von 1 konfiguriert der Pixelkern-Konfigurator 147 die Block-Abrufeinrichtung 138 mit Stütze des Kerns (z.B. den Kern des Hardwarebeschleunigers 114). So kann beispielsweise der Pixelkern-Konfigurator 147 Konfigurationsinformation an die Block-Abrufeinrichtung 138 einschließlich der Stütze des Kerns übertragen. Als Reaktion auf den Empfang der Stütze des Kerns kann die Block-Abrufeinrichtung 138 mindestens einen der Adressgeneratoren 142 oder die Cache-Fülleinrichtung 144 konfigurieren, um die Stütze zur Y-Koordinate des angeforderten Pixels hinzuzufügen, das an der Prefetch-Schnittstelle 104 empfangen wird. In einigen Beispielen, wenn ein Pixel mit Pixelkoordinaten (X, Y+Stütze) auf einen anderen Block abbildet als ein Block mit Pixelkoordinaten (X, Y), dann ruft die Block-Abrufeinrichtung 138 den anderen Block zusätzlich zu dem Bildblock ab, der das Pixel beinhaltet. So kann beispielsweise die Stütze der Menge von Pixeln in Breite und der Menge von Pixeln in Höhe des Pixelkerns entsprechen. So kann beispielsweise ein erstes Pixel mit ersten Pixelkoordinaten (X, Y+Stütze) auf einen ersten Block eines ersten Pixelkerns abgebildet werden, verglichen mit einem zweiten Pixel mit zweiten Pixelkoordinaten (X, Y), das auf einen zweiten Block eines zweiten Pixelkerns abgebildet wird.
Im veranschaulichten Beispiel von 1 beinhaltet der Cache-Speicher 146 vier Cache-Datenspeicher 148. Alternativ kann der exemplarische Cache-Speicher 146 weniger oder mehr als vier Cache-Datenspeicher 148 beinhalten. Die exemplarischen Cache-Datenspeicher 148 sind statische RAM (SRAM). Alternativ können die exemplarischen Cache-Datenspeicher 148 auch jede andere Art von nichtflüchtigem oder flüchtigem Speicher sein. Die exemplarischen Cache-Datenspeicher 148 von 1 speichern 8x8 Pixelblöcke, wobei jedes Pixel 2 Byte beträgt und somit eine Größe der Einträge (oder Wörter) der Cache-Datenspeicher 148 128 Byte oder 1024 Bit beträgt (z. B. 128 Byte = 8 Blöcke × 8 Pixel/Block × 2 Byte/Pixel). Alternativ können die exemplarischen Cache-Datenspeicher 148 eine Eingabegröße von 16×8 Pixeln speichern, wobei jedes Pixel 1 Byte ist, oder 4×8 Pixelblöcke, wobei jedes Pixel 4 Byte Speichergröße hat.
Im veranschaulichten Beispiel von 1 kann jeder der Cache-Datenspeicher 148 ein Viertel der Bildblöcke für jedes Set speichern, das einem angeforderten Pixel zugeordnet ist. Jeder der Cache-Datenspeicher 148 kann basierend auf den mindestens zwei signifikanten Bits eines Set-Index ausgewählt werden, der in den Tags 120 enthalten ist. Jeder der exemplarischen Cache-Datenspeicher 148 weist zwei Ports auf, die den Zugriff (z. B. gleichzeitiger Zugriff, im Wesentlichen gleichzeitiger Zugriff etc.) durch die Block-Abrufeinrichtung 138 und die Blockdaten-Leseeinrichtung 150 ermöglichen. So kann beispielsweise die Block-Abrufeinrichtung 138 einen ersten der Ports verwenden, um Bildblöcke oder Bildblockdaten in einen der Cache-Datenspeicher 148 zu schreiben. In solchen Beispielen kann die Block-Abrufeinrichtung 138 jeweils nur in einen der Cache-Datenspeicher 148 schreiben (z. B. unter der Annahme, dass eine Busbreite der Cache-Datenspeicher 148 gleich der Breite der Bildblöcke ist, d. h. 16 Bytes) und/oder es wird jeweils nur eine Zeile eines ausgewählten Bildblocks geschrieben. In einigen Beispielen, wenn die Breite der Bildblöcke größer ist als die Breite der Cache-Datenspeicher 148 ist, können dann zwei der Cache-Datenspeicher 148 gleichzeitig geschrieben werden. In anderen Beispielen kann die Blockdaten-Leseeinrichtung 150 einen zweiten der Ports verwenden, um Bildblöcke oder Bildblockdaten aus einem der Cache-Datenspeicher 148 abzurufen. In solchen Beispielen kann die Blockdaten-Leseeinrichtung 150 von einem bis vier der Cache-Datenspeicher 148 parallel und/oder anderweitig gleichzeitig lesen.
In dem veranschaulichten Beispiel von 1 bestimmt die Blockdaten-Leseeinrichtung 150, ob Bildblockdaten, die den Pixelkoordinaten eines von der Anforderungsschnittstelle 106 empfangenen angeforderten Pixels entsprechen, im Cache-Speicher 146 gespeichert sind, basierend auf Abbilden der Pixelkoordinaten auf eines der im Tag-Speicher 122 enthaltenen Tags 120. Als Reaktion auf Bestimmen, dass die Bildblockdaten im Cache-Speicher 146 gespeichert sind, überträgt die Blockdaten-Leseeinrichtung 150 die Bildblockdaten aus dem Cache-Speicher 146 an die Datenschnittstelle 108.
Im veranschaulichten Beispiel von 1 wird die Anforderungsschnittstelle 106 durch den Hardwarebeschleuniger 114 gesteuert. In einigen Beispielen steuert ein arithmetischer Datenpfad des Hardwarebeschleunigers 114 die Anforderungsschnittstelle 106. So erzeugt oder liest beispielsweise ein Steuerblock oder eine Steuereinrichtung des Hardwarebeschleunigers 114 aus dem Hauptspeicher 110 eine Folge von Pixelkoordinaten, auf die zur Verarbeitung oder Transformation durch den arithmetischen Datenpfad des Hardwarebeschleunigers 114 zugegriffen werden soll.
Die exemplarische Blockdaten-Leseeinrichtung 150 von 1 beinhaltet die exemplarische Lese-Tag-Abbildungseinrichtung 152, um die von der Anforderungsschnittstelle 106 empfangenen Pixelkoordinaten abzubilden und die Pixelkoordinaten auf die im Tag-Speicher 122 enthaltenen Tags 120 abzubilden. In einigen Beispielen bestimmt die Lese-Tag-Abbildungseinrichtung 152, dass Bildblockdaten, die den empfangenen Pixelkoordinaten entsprechen, nicht im Cache-Speicher 146 gespeichert sind, basierend auf Information, die in dem Tag 120 enthalten sind. In solchen Beispielen wartet die Lese-Tag-Abbildungseinrichtung 152 bis die Bildblockdaten abgerufen und von der Block-Abrufeinrichtung 138 im Cache-Speicher 146 gespeichert werden. In einigen Beispielen liest die Lese-Tag-Abbildungseinrichtung 152 den Tag-Speicher 122 nicht kontinuierlich, bis die Bildblockdaten abgerufen sind. So kann beispielsweise die Lese-Tag-Abbildungseinrichtung 152 den Betrieb unterbrechen oder blockieren, bis die Cache-Fülleinrichtung 144 die Lese-Tag-Abbildungseinrichtung 152 anweist, den Tag-Speicher 122 aufzuwecken und/oder anderweitig wieder zu lesen, wenn die Cache-Fülleinrichtung 144 einen neuen Block zwischenspeichert.
Die exemplarische Blockdaten-Leseeinrichtung 150 von 1 beinhaltet die exemplarische Cache-Zugriffeinrichtung 154 zum Abrufen und/oder anderweitigen Erhalten von Bildblockdaten aus dem Cache-Speicher 146, wenn die Lese-Tag-Abbildungseinrichtung 152 bestimmt, dass die Bildblockdaten im Cache-Speicher 146 gespeichert sind. In einigen Beispielen bildet die Lese-Tag-Abbildungseinrichtung 152 Pixelkoordinaten auf eines der Tags 120 ab und bestimmt, dass die den Pixelkoordinaten zugeordneten Bildblockdaten im Cache-Speicher 146 gespeichert werden und bestimmt eine Lokalisierung der Bildblockdaten in einem der Cache-Datenspeicher 148. Als Reaktion auf das Bestimmen der Lokalisierung der Bildblockdaten ruft die Cache-Zugriffeinrichtung 154 die Bildblockdaten aus dem Cache-Speicher 146 ab und sendet die Bildblockdaten an die Datenschnittstelle 108.
Im Betrieb empfängt die Prefetch-Schnittstelle 104 Pixelkoordinaten für ein Pixel, das einem Eingabebild zugeordnet ist. Die Prefetch-Schnittstelle 104 überträgt die Pixelkoordinaten über den Pixeldaten-FIFO-Puffer 116 an die Tag-Abbildungseinrichtung 124. Die Tag-Abbildungseinrichtung 124 erzeugt basierend auf den Pixelkoordinaten ein Block-Tag und durchsucht jeden der Tag-Datenspeicher 128 parallel, um festzustellen, ob das erzeugte Block-Tag mit einem der Tags 120 übereinstimmt. In einigen Beispielen beinhaltet ein oder mehrere der Tag-Datenspeicher 128 ein oder mehrere Tags 120, die zuvor von der Tag-Abbildungseinrichtung 124 als Reaktion auf frühere Operationen der Prefetch-Schnittstelle 104 erzeugt und gespeichert wurden.
Als Reaktion auf eines der Tags 120, das mit dem erzeugten Block-Tag übereinstimmt, liest die Tag-Abbildungseinrichtung 124 einen Wert, der im entsprechenden Zählfeld 134 des Tags 120 im Tag-Speicher 122 gespeichert ist, erhöht den Wert und schreibt den erhöhten Wert zurück in das Zählfeld 134. Als Reaktion darauf, dass keines der Tags 120 mit dem erzeugten Block-Tag übereinstimmt, identifiziert die Tag-Abbildungseinrichtung 124 einen ersten der Abschnitte 132, der frei und/oder anderweitig verfügbar ist, und führt Folgendes aus: 1) liest einen Wert des entsprechenden Zählfeldes 134, erhöht den Wert und schreibt den inkrementierten Wert zurück in das Zählfeld 134 (z.B. erhöht er einen Zählfeldwert von 0 bis 1); 2) setzt einen Wert des Tags 120 auf das Block-Tag; 3) setzt ein in dem Abschnitt 132 enthaltenes Validierungsfeld auf null und/oder löscht das Validierungsfeld anderweitig; und 4) setzt das in dem Abschnitt 132 enthaltene Pending-Feld 135 auf 1 und/oder aktiviert anderweitig das Pending-Feld.
Im veranschaulichten Beispiel von 1 erzeugt und überträgt die SBR-Erstellungseinrichtung 126 als Reaktion darauf, dass die Tag-Abbildungseinrichtung 124 das im Tag-Speicher 122 enthaltene Tag 120 auf das Block-Tag setzt, eine oder mehrere SBRs zur Block-Abrufeinrichtung 138 über den SBR-FIFO 136. Als Reaktion auf Empfangen der einen oder mehreren SBRs erzeugt der Adressgenerator 142 eine oder mehrere Adresszeilen für die Cache-Fülleinrichtung 144, die aus dem Hauptspeicher 110 abgerufen werden können. Als Reaktion auf Abrufen der Bildblockdaten an einer oder mehreren Adresszeilen über die Block-Abrufeinrichtungsschnittstelle 140 führt die Cache-Fülleinrichtung 144 Folgendes aus: 1) liest einen Wert des Pending-Feldes des Abschnitts 132, der dem Block-Tag entspricht, löscht den Wert und schreibt den gelöschten Wert zurück in das Pending-Feld; 2) liest einen Wert des Validierungsfeldes des Abschnitts 132, der dem Block-Tag entspricht, erhöht den Wert und/oder setzt anderweitig den Bitwert des Validierungsfeldes und schreibt den Wert zurück in das Validierungsfeld; und 3) speichert die Bilddaten in einem der Cache-Datenspeicher 148, der auf das Block-Tag abgebildet ist.
Im Betrieb leitet die Blockdaten-Leseeinrichtung 150 eine Suche im Tag-Speicher 122 ein, wenn die Anforderungsschnittstelle 106 eine Anforderung zum Abrufen von Bilddaten empfängt, die einem oder mehreren Pixeln eines Eingabebildes zugeordnet sind. In 1 empfängt die Anforderungsschnittstelle 106 Pixelkoordinaten, die dem Pixel von Interesse zugeordnet sind. Als Reaktion auf Empfangen der angeforderten Pixelkoordinaten erzeugt die Lese-Tag-Abbildungseinrichtung 152 ein Block-Tag basierend auf den Pixelkoordinaten und sucht im Tag-Speicher 122 nach einer Übereinstimmung mit dem Block-Tag. So kann beispielsweise die Lese-Tag-Abbildungseinrichtung 152 einen bis vier der Tag-Datenspeicher 128 parallel lesen, da aufgrund der angeforderten Pixelkoordinaten ein bis vier Bildblöcke benötigt werden können.
Als Reaktion auf eines der Tags 120, das mit dem von der Lese-Tag-Abbildungseinrichtung 152 erzeugten Block-Tag übereinstimmt, führt die Lese-Tag-Abbildungseinrichtung 152 Folgendes aus: 1) liest einen Wert des Zählfeldes 134 eines übereinstimmenden der Tags 120, verringert den Wert und schreibt den dekrementierten Wert zurück in das Zählfeld 134; und 2) weist die Cache-Zugriffeinrichtung 154 an, einen bis vier der Cache-Datenspeicher 148 parallel zu lesen, um die dem übereinstimmenden der Tags 120 zugeordneten Bildblockdaten abzurufen. Als Reaktion auf Abrufen der Bildblockdaten aus einem der Cache-Datenspeicher 148 durch die Cache-Zugriffeinrichtung 154 überträgt die Cache-Zugriffeinrichtung 154 die Bildblockdaten zur weiteren Verarbeitung an die Datenschnittstelle 108. Als Reaktion darauf, dass das eine der Tags 120 nicht mit dem von der Lese-Tag-Abbildungseinrichtung 152 erzeugten Block-Tag übereinstimmt, blockiert oder akzeptiert die Anforderungsschnittstelle 106 keine zusätzlichen Anforderungen, bis die angeforderten Bildblockdaten im Cache-Speicher 146 gespeichert sind und eines oder mehrere der im Tag-Speicher 122 enthaltenen Tags 120 mit einer Lokalisierung der Bildblockdaten im Cache-Speicher 146 aktualisiert wird.
Während eine exemplarische Art der Implementierung des PFBC 100 in 1 dargestellt ist, kann eines oder mehrere der in 1 dargestellten Elemente, Prozesse und/oder Vorrichtungen kombiniert, geteilt, neu angeordnet, weggelassen, eliminiert und/oder auf andere Weise implementiert werden. Weiterhin ist die exemplarische Speicherschnittstelle 102, die exemplarische Prefetch-Schnittstelle 104, die exemplarische Anforderungsschnittstelle 106, die exemplarische Datenschnittstelle 108, die exemplarische Prefetch-Einrichtung 112, der exemplarische Pixeldaten-FIFO-Puffer 116, der exemplarische Tag-Speicher 122, die exemplarische Tag-Abbildungseinrichtung 124, die exemplarische SBR-Erstellungseinrichtung 126, der exemplarische SBR-FIFO 136, die exemplarische Block-Abrufeinrichtung 138, die exemplarische Block-Abrufeinrichtungsschnittstelle 140, den exemplarischen Adressgenerator 142, die exemplarische Cache-Fülleinrichtung 144, den exemplarischen Cache-Speicher 146, die exemplarische Blockdaten-Leseeinrichtung 150, die exemplarische Lese-Tag-Abbildungseinrichtung 152, die exemplarische Cache-Zugriffeinrichtung 154 und/oder ganz allgemein kann das Beispiel PFBC 100 von 1 durch Hardware, Software, Firmware und/oder eine beliebige Kombination von Hardware, Software und/oder Firmware implementiert werden. So ist beispielsweise eine der exemplarischen Speicherschnittstellen 102, die exemplarische Prefetch-Schnittstelle 104, die exemplarische Anforderungsschnittstelle 106, die exemplarische Datenschnittstelle 108, die exemplarische Prefetch-Einrichtung 112, der exemplarische Pixeldaten-FIFO-Puffer 116, der exemplarische Tag-Speicher 122, die exemplarische Tag-Abbildungseinrichtung 124, die exemplarische SBR-Erstellungseinrichtung 126, das exemplarische SBR-FIFO 136, die exemplarische Block-Abrufeinrichtung 138, die exemplarische Block-Abrufeinrichtungsschnittstelle 140, der exemplarische Adressgenerator 142, die exemplarische Cache-Fülleinrichtung 144, der exemplarische Cache-Speicher 146, die exemplarische Blockdaten-Leseeinrichtung 150, die exemplarische Lese-Tag-Abbildungseinrichtung 152, die exemplarische Cache-Zugriffeinrichtung 154 und/oder, allgemeiner gesagt, könnte der exemplarische PFBC 100 durch eine oder mehrere analoge oder digitale Schaltungen, Logikschaltungen, programmierbare Prozessoren implementiert werden, programmierbare Steuerung(en), Grafikverarbeitungseinheit(en) (GPU(s)), digitaler Signalprozessor(en) (DSP(s)), anwendungsspezifische integrierte Schaltung(en) (ASIC(s)), programmierbare Logikvorrichtung(en) (PLD(s)) und/oder feldprogrammierbare Logikvorrichtung(en) (FPLD(s)). Beim Lesen eines der Vorrichtungs- oder Systemansprüche dieses Patents, eine reine Software- und/oder Firmware-Implementierung abzudecken, wird mindestens eine der exemplarischen Speicherschnittstellen 102, die exemplarische Prefetch-Schnittstelle 104, die exemplarische Anforderungsschnittstelle 106, die exemplarische Datenschnittstelle 108, die exemplarische Prefetch-Einrichtung 112, der exemplarische Pixeldaten-FIFO-Puffer 116, der exemplarische Tag-Speicher 122, die exemplarische Tag-Abbildungseinrichtung 124, die exemplarische SBR-Erstellungseinrichtung 126, das exemplarische SBR-FIFO 136, die exemplarische Block-Abrufeinrichtung 138, die exemplarische Block-Abrufeinrichtungsschnittstelle 140, der exemplarische Adressgenerator 142, die exemplarische Cache-Fülleinrichtung 144, der exemplarische Cache-Speicher 146, die exemplarische Blockdaten-Leseeinrichtung 150, die exemplarische Lese-Tag-Abbildungseinrichtung 152, die exemplarische Cache-Zugriffeinrichtung 154 ist/sind hiermit ausdrücklich definiert, um eine nichtflüchtige computerlesbare Speichervorrichtung oder Speicherplatte wie einen Speicher, eine Digital Versatile Disc (DVD), eine Compact Disc (CD), eine Blu-ray Disc etc. aufzunehmen., einschließlich der Software und/oder Firmware. Weiterhin kann der exemplarische PFBC 100 von 1 ein oder mehrere Elemente, Prozesse und/oder Vorrichtungen zusätzlich zu oder anstelle von den in 1 dargestellten beinhalten und/oder mehr als eines der dargestellten Elemente, Prozesse und Vorrichtungen beinhalten.
2 ist ein Blockdiagramm einer exemplarischen Implementierung einer exemplarischen Prefetch-Maschine 200 zur Implementierung des PFBC 100 aus 1. Die Prefetch-Maschine 200 von 2 kann Bilddaten erhalten, verarbeiten, organisieren und speichern, die den Pixelkoordinaten eines oder mehrerer Pixel eines Eingabebildes entsprechen, bevor sie für eine Berechnungsaufgabe wie Bildverarbeitung, Computervision usw. angefordert wird. Die Prefetch-Maschine 200 von 2 beinhaltet eine exemplarische Prefetch-Kern-Abrufeinrichtung 202, eine exemplarische Speicherschnittstellen-Maschine 204 und eine exemplarische Kern-Abrufeinrichtung 206.
In dem veranschaulichten Beispiel von 2 beinhaltet die Prefetch-Maschine 200 die Prefetch-Kern-Abrufeinrichtung 202, um Bilddaten zu erhalten, die den Pixelkoordinaten entsprechen, bevor die Bilddaten von der Kern-Abrufeinrichtung 206 angefordert werden. In dem veranschaulichten Beispiel von 2 implementiert die Prefetch-Kern-Abrufeinrichtung 202 ein Mittel zum Erzeugen von Block-Tags basierend auf Pixelkoordinaten und ein Mittel zum Abrufen von Bildblöcken basierend auf den Block-Tags. Die Prefetch-Kern-Abrufeinrichtung 202 kann der Prefetch-Einrichtung 112 von 1 entsprechen. So kann beispielsweise die Prefetch-Kern-Abrufeinrichtung 202 eine oder mehrere Funktionen bis zu mindestens einer Gesamtheit der in Verbindung mit der Prefetch-Einrichtung 112 von 1 oben beschriebenen Funktionen implementieren. In einigen Beispielen bestimmt die Prefetch-Kern-Abrufeinrichtung 202, ob eine Anforderung zum Abrufen von Bilddaten von der Prefetch-Maschine 200 akzeptiert wurde. Wenn nicht, überwacht die Prefetch-Kern-Abrufeinrichtung 202 weiterhin auf einen oder mehrere Anforderungen. Als Reaktion auf das Erkennen einer Anforderung bestimmt die Prefetch-Kern-Abrufeinrichtung 202 entsprechende Information, die mit der Anforderung verbunden ist. Zu der entsprechenden Information gehören unter anderem Pixelkoordinaten, horizontale Stütze, vertikale Stütze und/oder Morton-Ordnung-Statusinformation. Wie hierin verwendet, bezieht sich die Morton-Ordnung auf eine Abbildung eines N-dimensionalen Raumes zu einer linearen Liste von Zahlen. Wenn beispielsweise die Morton-Ordnung auf Koordinaten angewendet wird, definiert sie eine raumfüllende Kurve, die Z-förmig ist, um multidimensionale Daten auf eine Dimension abzubilden und gleichzeitig die Lokalität der Datenpunkte zu erhalten.
In einigen Beispielen bildet die Prefetch-Kern-Abrufeinrichtung 202 Pixelkoordinaten einer Blockabbildung ab, die auf der Stütze des Pixelkerns basiert. So können beispielsweise empfangene Pixelkoordinaten einer linken oberen Ecke eines Pixelkerns entsprechen, wie nachfolgend in Verbindung mit den 3 und/oder 4 beschrieben. In solchen Beispielen kann die Prefetch-Kern-Abrufeinrichtung 202 die Pixelkoordinaten basierend auf den Eingabepixelkoordinaten (X, Y), einer horizontalen Stütze von W-Pixeln, einer vertikalen Stütze von H-Pixeln, einer Morton-Set-Organisation und/oder einer Konfiguration abbilden, um der Prefetch-Maschine 200 zu ermöglichen, 8x8 Pixelblöcke zwischen zu speichern.
In einigen Beispielen führt die Prefetch-Kern-Abrufeinrichtung 202 das Abbilden für alle Ecken des Pixelkerns basierend auf Berechnungen unter Verwendung eines oder mehrerer der Beispiele für Gleichungen (1)-(4) durch, wie nachfolgend beschrieben: $B l o c k 0 = (X ≫ 3, Y ≫ 3)$
$B l o c k 1 = ((X + W) ≫ 3, Y ≫ 3)$
$B l o c k 2 = (X ≫ 3, (Y + H) ≫ 3)$
$B l o c k 3 = ((X + W) ≫ 3, (Y + H) ≫ 3)$
In den veranschaulichten Beispielen der obigen Gleichungen (1)-(4) bezieht sich „>>“ auf einen Verschiebeoperation nach rechts. Als solche stellt „X >> 3“ eine Verschiebung einer X-Koordinate eines Pixels um 3 Bit nach rechts dar. In einigen Beispielen durchsucht die Prefetch-Kern-Abrufeinrichtung 202 einen oder mehrere Tag-Speicher (z. B. die exemplarischen Tag-Datenspeicher 128 von 1), um Treffer-/Fehler-Entscheidungen mit einem einzigen Taktzyklus zu erzeugen. Die Prefetch-Kern-Abrufeinrichtung 202 von 2 bestimmt, ob Bilddaten, die den Pixelkoordinaten entsprechen, die einer Anforderung zugeordnet sind, bereits im Cache (z. B. der Cache-Speicher 146 von 1) gespeichert wurden. Als Reaktion auf Bestimmen, dass die Bilddaten bereits zwischengespeichert wurden, ruft die exemplarische Kern-Abrufeinrichtung 206 die Bilddaten aus dem Cache ab. Als Reaktion auf Bestimmen, dass die Bilddaten nicht zwischengespeichert wurden, erzeugt die exemplarische Prefetch-Kern-Abrufeinrichtung 202 ein Tag (z. B. eines der Tags 120 von 1), das einem Speicherort der Bilddaten im Cache entspricht, und weist die exemplarische Speicherschnittstellen-Maschine 204 an, die Bilddaten im Cache am Speicherort abzurufen und zu speichern.
In dem veranschaulichten Beispiel von 2 beinhaltet die Prefetch-Maschine 200 die Speicherschnittstellen-Maschine 204, um basierend auf der Morton-Ordnung der Tags auf separate RAMs zuzugreifen, wodurch parallele Speichertransaktionen effizienter gefördert und der Stromverbrauch im Zusammenhang mit der Blockzugriffsmechanik reduziert wird. In dem veranschaulichten Beispiel von 2 implementiert die Speicherschnittstellen-Maschine 204 ein Mittel zum Abrufen von Bildblöcken aus einem Speicher und zum Speichern der abgerufenen Bildblöcke in einem Cache-Speicher. Die Speicherschnittstellen-Maschine 204 kann der Block-Abrufeinrichtung 138 von 1 entsprechen. So kann beispielsweise die Speicherschnittstellen-Maschine 204 eine oder mehrere Funktionen bis zu mindestens einer Gesamtheit der in Verbindung mit der Block-Abrufeinrichtung 138 von 1 oben beschriebenen Funktionen implementieren.
In einigen Beispielen erhält die Speicherschnittstellen-Maschine 204 Bilddaten, die einer von der Prefetch-Kern-Abrufeinrichtung 202 verarbeiteten Anforderung zugeordnet sind, und speichert die Bilddaten im Cache (z. B. den Cache-Speicher 146 von 1). In solchen Beispielen alarmiert die Speicherschnittstellen-Maschine 204 die Prefetch-Kern-Abrufeinrichtung 202 und/oder die Kern-Abrufeinrichtung 206, dass die Bilddaten im Cache gespeichert wurden. So aktualisiert beispielsweise die Speicherschnittstellen-Maschine 204 eines der von der Prefetch-Kern-Abrufeinrichtung 202 erzeugten Tags 120, um anzuzeigen, dass die mit dem Tag 120 verbundenen Bilddaten im Cache gespeichert sind. In anderen Beispielen aktualisiert und/oder warnt die Speicherschnittstellen-Maschine 204 die Kern-Abrufeinrichtung 206, dass die von der Kern-Abrufeinrichtung 206 abzurufenden Bilddaten im Cache verfügbar sind.
Im veranschaulichten Beispiel von 2 beinhaltet die Prefetch-Maschine 200 die Kern-Abrufeinrichtung 206, um eine Anforderung zum Erhalten von Bilddaten zu empfangen, die Pixelkoordinaten eines oder mehrerer Pixel zugeordnet sind, die in einem Eingabebild enthalten sind. In dem veranschaulichten Beispiel von 2 implementiert die Kern-Abrufeinrichtung 206 ein Mittel zum Erzeugen eines Block-Tags basierend auf Pixelkoordinaten, zum Durchsuchen eines Tag-Speichers basierend auf dem erzeugten Block-Tag und/oder zum Abrufen von Bildblöcken basierend auf der Suche des Tag-Speichers. Die Kern-Abrufeinrichtung 206 kann der Blockdaten-Leseeinrichtung 150 von 1 entsprechen. So kann beispielsweise die Kern-Abrufeinrichtung 206 eine oder mehrere Funktionen bis zu mindestens einer Gesamtheit der in Verbindung mit der Blockdaten-Leseeinrichtung 150 aus 1 oben beschriebenen Funktionen implementieren.
In einigen Beispielen bestimmt die Kern-Abrufeinrichtung 206, ob sich die Bilddaten im Cache befinden. So kann beispielsweise die Kern-Abrufeinrichtung 206 die Pixelkoordinaten auf eines der Tags 120 von 1 abbilden. Als Reaktion darauf, dass die Kern-Abrufeinrichtung 206 bestimmt, dass sich die Bilddaten nicht im Cache befinden, wartet die Kern-Abrufeinrichtung 206, bis die Bilddaten im Cache gespeichert sind. Als Reaktion darauf, dass die Kern-Abrufeinrichtung 206 bestimmt, dass sich die Bilddaten im Cache befinden, ruft die Kern-Abrufeinrichtung 206 die Bilddaten aus dem Cache ab.
Das exemplarische Mittel der Prefetch-Kern-Abrufeinrichtung, das exemplarische Mittel der Speicherschnittstellen-Maschine und/oder das Mittel der Kern-Abrufeinrichtung des veranschaulichten Beispiels von 1 wird/werden durch Software implementiert, die auf einem Hardware-Prozessor ausgeführt wird. Zusätzlich oder alternativ könnten die exemplarischen Mittel der Prefetch-Kern-Abrufeinrichtung, das exemplarische Mittel der Speicherschnittstellen-Maschine und/oder das exemplarische Mittel der Kern-Abrufeinrichtung stattdessen durch eine Logikschaltung implementiert werden, die so aufgebaut ist, dass sie logische Operationen durchführt, um die gewünschte Funktionalität zu erreichen, wie beispielsweise ein ASIC, ein FPGA oder dergleichen und/oder eine Kombination aus solchen Schaltungen und Software und/oder Firmware.
Während eine exemplarische Art der Implementierung der Prefetch-Maschine 200 in 2 dargestellt ist, können eines oder mehrere der in 2 dargestellten Elemente, Prozesse und/oder Vorrichtungen kombiniert, geteilt, neu angeordnet, weggelassen, eliminiert und/oder auf andere Weise implementiert werden. Weiterhin kann die exemplarische Prefetch-Kern-Abrufeinrichtung 202, die exemplarische Speicherschnittstellen-Maschine 204, die exemplarische Kern-Abrufeinrichtung 206 und/oder ganz allgemein die exemplarische Prefetch-Maschine 200 aus 2 durch Hardware, Software, Firmware und/oder eine beliebige Kombination von Hardware, Software und/oder Firmware implementiert werden. So kann beispielsweise die exemplarischen Prefetch-Kern-Abrufeinrichtung 202, die exemplarische Speicherschnittstellen-Maschine 204, die exemplarische Kern-Abrufeinrichtung 206 und/oder ganz allgemein die exemplarische Prefetch-Maschine 200 jeweils durch eine oder mehrere analoge oder digitale Schaltung(en), logische Schaltungen, programmierbare(r) Prozessor(en), programmierbare(r) Controller, Grafikprozessor(en) (GPU(s)), digitale Signalprozessor(en) (DSP(s)), anwendungsspezifische integrierte Schaltung(en) (ASIC(s)), programmierbare(r) Logikgerät(e) (PLD(e)) und/oder feldprogrammierbare(r) Logikgerät(e) (FPLD(e)) implementiert sein. Beim Lesen eines der Vorrichtungs- oder Systemansprüche dieses Patents, um eine reine Software- und/oder Firmware-Implementierung abzudecken, wird die exemplarische Prefetch-Kern-Abrufeinrichtung 202, die exemplarische Speicherschnittstellen-Maschine 204 und/oder die exemplarische Kern-Abrufeinrichtung 206 hiermit ausdrücklich definiert, um eine nichtflüchtige computerlesbare Speichervorrichtung oder Speicherplatte wie einen Speicher, eine Digital Versatile Disc (DVD), eine Compact Disc (CD), eine Blu-ray Disc usw. einschließlich der Software und/oder Firmware zu beinhalten. Weiterhin kann die exemplarische Prefetch-Maschine 200 von 2 ein oder mehrere Elemente, Prozesse und/oder Vorrichtungen zusätzlich zu oder anstelle von den in 2 dargestellten beinhalten und/oder mehr als eines der dargestellten Elemente, Prozesse und Vorrichtungen beinhalten. Wie hierin verwendet, umfasst der Begriff „in Kommunikation“, einschließlich seiner Variationen, die direkte Kommunikation und/oder indirekte Kommunikation über eine oder mehrere Zwischenkomponenten und erfordert keine direkte physische (z. B. drahtgebundene) Kommunikation und/oder konstante Kommunikation, sondern zusätzlich eine selektive Kommunikation in periodischen Intervallen, geplanten Intervallen, aperiodischen Intervallen und/oder einmaligen Ereignissen.
3 stellt ein exemplarisches Eingabebild 300 dar, das auf den Cache-Speicher 146 von 1 basierend auf der Morton-Ordnung abgebildet ist. Das Eingabebild 300 kann einem Kamerabild, einem Videobild usw. entsprechen. Das Eingabebild 300 ist in einem exemplarischen Set 302 organisiert. Das Set 302 ist eine zweidimensionale Anordnung von exemplarischen Blöcken (z. B. Pixelblöcke) 304. In dem veranschaulichten Beispiel von 3 stellt jeder der Blöcke 304 eine zweidimensionale Anordnung von exemplarischen Pixeln 306 dar. Die exemplarischen Blöcke 304 sind Bildblöcke (z. B. Bilddatenblöcke). In 3 beinhaltet das exemplarische Eingabebild 300 2048 Pixel (z. B. 2048 Pixel = 64 Pixel in Breite × 32 Pixel in Höhe). Alternativ kann das Eingabebild 300 weniger oder mehr als 2048 Pixel aufweisen.
Im veranschaulichten Beispiel von 3 sind die Koordinaten der Pixel 306 entsprechend der linken oberen Ecke eines Pixelkerns eines entsprechenden Hardwarebeschleunigers (z.B. des Hardwarebeschleunigers 114 von 1). So weist beispielsweise jedes der Pixel 306 eine X-Koordinate und eine Y-Koordinate auf, die eine Lokalisierung des Pixels 306 im Eingabebild 300 darstellen. In 3 können die Pixel 306 eine X-Bild-Koordinate in einem Bereich von 0 bis 64 aufweisen, die einer Breite des Eingabebildes 300 von 64 Pixeln entspricht. In 3 wird die X-Bild-Koordinate durch 2 Bytes oder 16 Bit dargestellt, um eine maximale Bildbreite von 65.536 Bit zu erhalten. In 3 können die Pixel 306 eine Y-Bild-Koordinate in einem Bereich von 0 bis 32 aufweisen, die einer Höhe des Eingabebildes 300 von 32 Pixeln entspricht. In 3 wird die Y-Bild-Koordinate durch 2 Bytes oder 16 Bit dargestellt, um eine maximale Bildhöhe von 65.536 Bit zu erhalten. In 3 befindet sich ein exemplarischer Ursprung (z. B. eine Lokalisierung mit Bildkoordinaten (X,Y) von (0,0)) 308 der Bildkoordinaten in der linken oberen Ecke des Eingabebildes 300.
Im veranschaulichten Beispiel von 3 sind die Pixel 306 des Eingabebildes 300 in den Bildblöcken 304 basierend auf einer 2x2 Blockorganisation angeordnet. So sind beispielsweise eines der Pixel 306, die in den Bildbereichen 0, 1, 2 und 3 enthalten sind, in einem ersten 2x2-Block, eines der Pixel 306, die in den Bildbereichen 4, 5, 6 und 7 enthalten sind, in einem zweiten 2x2-Block etc. angeordnet. So befindet sich beispielsweise ein erstes Pixel 310 mit Bildkoordinaten von X=8 und Y=8 im Bildblock 0. In 3 kann das erste Pixel 310 auf einen exemplarischen Pixelkern 312 abgebildet werden, der Bildblock 0 und Bildblöcke 1, 2 und 3 in Bezug auf den Bildblock 0 beinhaltet.
In 3 ist das Set 302 eine 8x4-Anordnung, die acht Bildblöcke in Breite und vier Bildblöcke in Höhe ist. So beinhaltet beispielsweise ein erster Block 314 acht Beispielreihen 316 und acht Beispielspalten 318, wobei jede der Zeilen 316 und Spalten 318 acht Pixel 306 beinhaltet. Jedes Beispielpixel 306 hat eine Speichergröße von zwei Bytes oder sechzehn Bits, wodurch der erste Block 314 eine Speichergröße von 128 Bytes oder 1024 Bits hat (z. B. 128 Bytes = (8 Pixel/Zeile × 8 Zeilen) × (2 Bytes/Pixel)). Alternativ kann jedes Pixel 306 eine beliebige andere Speichergröße wie ein Byte, vier Bytes usw. aufweisen.
In dem veranschaulichten Beispiel von 3 ist das Eingabebild 300 in 32 der Bildblöcke 304 organisiert, wobei jeder der Bildblöcke 304 ein 8x8 Pixelblock ist (z. B. ein Bildblock mit acht Zeilen 316 und acht Spalten 318 mit je acht Pixeln 306), wodurch das Eingabebild 300 eine Größe von 4 Kilobyte (kB) oder 4.096 Bit (z. B. 4 kB = (8 Bildblöcke × 4 Bildblöcke) × (64 Pixel/Bildblock) × (2 Byte/Pixel) hat, wenn es im Speicher gespeichert ist.
Im veranschaulichten Beispiel von 3 erzeugt der PFBC 100 von 1 und/oder die Prefetch-Maschine 200 von 2 einen Pixel-Index, einen Blocklokalisierung-Index und ein Block-Tag basierend auf der Lokalisierung(en) der Pixel 306, die im Eingabebild 300 enthalten sind. So können beispielsweise die Tags 120 von 1 den Pixel-Index, den Blocklokalisierung-Index und das Block-Tag beinhalten. Ein exemplarisches Block-Tag wird basierend auf {Y[15:5], X[15:6]} erzeugt, wobei die oberen elf Bits der Y-Koordinate (z. B. 11 Bits = (15-5) + 1) und die oberen zehn Bits der X-Koordinate (z. B. 10 Bits = (15-6)+1) zur Erzeugung des Block-Tags verwendet werden. So kann beispielsweise die Tag-Abbildungseinrichtung 124 von 1 einen ersten Abschnitt von Bits der Y-Koordinate und einen zweiten Abschnitt von Bits der X-Koordinate, wobei der erste und der zweite Abschnitt unterschiedlich sein können, verwenden, um eine eindeutige Kennung zu erzeugen und einem Set von Pixelkoordinaten (z. B. einem X- und Y-Koordinatenpaar) zuzuweisen. In solchen Beispielen kann die Tag-Abbildungseinrichtung 124 bestimmen, ob die eindeutige Kennung im Tag-Speicher 122 enthalten ist. Alternativ kann das Block-Tag auch basierend auf einer anderen Anzahl von X-Koordinatenbits und/oder einer anderen Anzahl von Y-Koordinatenbits erzeugt werden.
In einer exemplarischen Operation kann die Tag-Abbildungseinrichtung 124 von 1 eine Lokalisierung eines der Pixel 306 an den Koordinaten Y=257 (dezimal) und X=1020 (dezimal) erhalten. Die Tag-Abbildungseinrichtung 124 kann die Y- und X-Koordinaten in Binärdaten umwandeln, wobei Y=b000000_0001_000000_0000_0001 und X=b000000_0011_111111_111100. Die exemplarische Tag-Abbildungseinrichtung 124 nimmt die oberen elf Bits der Y-Koordinate, um einen ersten Binärwert von b0000000001000 zu erhalten, und nimmt die oberen zehn Bits der X-Koordinate, um einen zweiten Binärwert von b00000000111111 zu erhalten. Die exemplarische Tag-Abbildungseinrichtung 124 verkettet den ersten und zweiten Binärwert, um einen dritten Binärwert von b000000000100000000000000000001111 oder einen Hex-Wert von h200F zu erzeugen. Die exemplarische Tag-Abbildungseinrichtung 124 speichert das Block-Tag von h200F im Speicher (z.B. den Tag-Speicher 122 von 1). Die exemplarische Tag-Abbildungseinrichtung 124 und/oder die exemplarische Lese-Tag-Abbildungseinrichtung 152 verwendet das Block-Tag von h200F, um zu bestimmen, ob einer der Blöcke 304, der das Pixel an den Koordinaten Y=257 und X=1020 beinhaltet, im Cache vorhanden ist oder nicht.
Im veranschaulichten Beispiel von 3, wird ein Blocklokalisierung-Index basierend auf {X[5], Y[4], X[4], Y[3], X[3]} basierend auf der Morton-Ordnung erzeugt, wobei ein fünftes Bit der X-Koordinate (X[5]), ein viertes Bit der Y-Koordinate (Y[4]), ein viertes Bit der X-Koordinate (X[4]), ein drittes Bit der Y-Koordinate (Y[3]) und ein drittes Bit der X-Koordinate (X[3]) zusammengeführt werden, um den Blocklokalisierung-Index aufzubauen. Alternativ kann jede andere Anzahl von Bits und/oder Bitlokalisierungen der X- und/oder Y-Koordinaten verwendet werden, um den Blocklokalisierung-Index aufzubauen. In der obigen exemplarischen Operation, bei der der Binärwert der Y-Koordinate von 257 (dezimal) b000000_0001_000000_0000_0001 und der Binärwert der X-Koordinate von 1020 (dezimal) b0000_0011_11111111_1100 ist, erzeugt die Tag-Abbildungseinrichtung 124 von 1 den entsprechenden Blocklokalisierung-Index als b10101. Der Blocklokalisierung-Index identifiziert einen der Blöcke 304 im Set 302 (z. B. das Set 8x4), das die Pixelkoordinaten von Interesse enthält. So entspricht beispielsweise der Blocklokalisierung-Index von b10101 einem der Blöcke 304, der das Pixel 306 an den Koordinaten X=1020 (dezimal) und Y=257 (dezimal) beinhaltet.
Im veranschaulichten Beispiel von 3 wird ein Pixel-Index basierend auf {Y[2:0], X[2:0]} erzeugt, wobei die unteren drei Bits der Y-Koordinate (z. B. 3 Bits = (2-0) + 1) und die unteren drei Bits der X-Koordinate (z. B. 3 Bits = (2-0) + 1) miteinander verknüpft werden, um den Pixel-Index aufzubauen. Alternativ kann jede andere Anzahl von Bits und/oder Bitlokalisierungen der X- und/oder Y-Koordinaten verwendet werden, um den Pixel-Index aufzubauen. In der obigen exemplarischen Operation, bei der der Binärwert der Y-Koordinate von 257 (dezimal) b000000_0001_000000_0000_0001 ist und der Binärwert der X-Koordinate von 1020 (dezimal) b0000_0011_111111_111100 ist, kann die Tag-Abbildungseinrichtung 124 den entsprechenden Pixel-Index erzeugen, der b001100 lautet.
Im veranschaulichten Beispiel von 3 erzeugt der PFBC 100 von 1 und/oder die Prefetch-Maschine 200 von 2 einen RAM-Auswahl-Index und eine RAM-Adresse basierend auf den Pixelkoordinaten. So kann beispielsweise die Tag-Abbildungseinrichtung 124 den Blocklokalisierung-Index verwenden, um den RAM-Auswahl-Index (RAM SELECT) und die RAM-Adresse aufzubauen. Der exemplarische RAM-Auswahl-Index basiert auf dem Index[1:0], wobei die unteren beiden Bits des Blocklokalisierung-Index verwendet werden, um einen der Blockdaten-Datenspeicher 148 aus 1 auszuwählen. Alternativ kann jede andere Anzahl von Bits und/oder Bitlokalisierungen des Blocklokalisierung-Index verwendet werden, um den Pixel-Index aufzubauen. In der obigen exemplarischen Operation, die den Blocklokalisierung-Index von b10101 erzeugt hat, ist der entsprechende RAM-Auswahl-Index b01. Der exemplarische RAM-Auswahl-Index von b01 entspricht einer Auswahl von RAM[1], wobei b00 einer Auswahl von RAM[0] entspricht, b10 einer Auswahl von RAM[2] und b11 einer Auswahl von RAM[3].
Im veranschaulichten Beispiel von 3 erzeugt der PFBC 100 und/oder die Prefetch-Maschine 200 die RAM-Adresse basierend auf dem Blocklokalisierung-Index und einer Verfügbarkeit eines Index in einem ersten exemplarischen Weg (WEG 0) 320 oder einem zweiten exemplarischen Weg (WEG 1) 322. Die exemplarische RAM-Adresse basiert auf dem Index[5:2], wobei (1) das höchstwertige Bit der RAM-Adresse einem der Wege 320, 322 von 3 entspricht und (2) die niederwertigsten Bits der RAM-Adresse die oberen drei Bits des Blocklokalisierung-Index sind. Alternativ kann jede andere Anzahl von Bits und/oder Bitlokalisierungen des Blocklokalisierung-Index verwendet werden, um die RAM-Adresse aufzubauen. In 3 wird das höchstwertige Bit der RAM-Adresse basierend auf der Verfügbarkeit des Indexes bestimmt, der durch die oberen drei Bits des Blocklokalisierung-Index beschrieben wird.
In der obigen exemplarischen Operation, die den Blocklokalisierung-Index von b10101 erzeugt hat, verwendet die Tag-Abbildungseinrichtung 148 die unteren beiden Bits des Blocklokalisierung-Index (z. B. b01), um RAM[1] des Tag-Speichers 148 und die oberen drei Bits des Blocklokalisierung-Indexes (z.B. b101) auszuwählen, um entweder Index 5 (dezimal) des RAM[1] entsprechend b0101 oder Index 13 (dezimal) des RAM[1] entsprechend b1010 auszuwählen. So bestimmt beispielsweise die Tag-Abbildungseinrichtung 148, ob der Index 5 des ersten Weges 320 von RAM[1] verfügbar ist. Wenn verfügbar, generiert die Tag-Abbildungseinrichtung 148 die RAM-Adresse b0101. Wenn nicht verfügbar, bestimmt die Tag-Abbildungseinrichtung 148, ob der Index 5 des zweiten Weges 322 (z. B. Index 13 von RAM[1]) verfügbar ist. Wenn verfügbar, generiert die Tag-Abbildungseinrichtung 148 die RAM-Adresse b1101. Wenn nicht verfügbar, identifiziert die Tag-Abbildungseinrichtung 148 die Bildblockdaten entweder im Index 5 des ersten Weges 320 oder im Index 5 des zweiten Weges 322, um sie zu entfernen und/oder anderweitig aus dem RAM[1] zu entfernen. Als Reaktion auf Entfernen der Bildblockdaten aus dem Index 5 des ersten Weges 320 erzeugt die Tag-Abbildungseinrichtung 148 die RAM-Adresse b0101, um Bilddaten zu speichern, die der Y-Koordinate von 257 (dezimal) und der X-Koordinate von 1020 (dezimal) zugeordnet sind, in Index 5 des ersten Weges 320 von RAM[1].
Im veranschaulichten Beispiel von 3 bildet der PFBC 100 und/oder die Prefetch-Maschine 200 einen oder mehrere der Blöcke 304 des Sets 302 auf den Cache-Speicher 146 von 1 basierend auf der Morton-Ordnung ab. So liegen beispielsweise die Blöcke 0, 1, 2 und 3 im Set 302 nahe beieinander, befinden sich aber in verschiedenen Block-Datenspeichern 148. So ist beispielsweise eine erste Vielzahl von Pixeln in Block 0 nahe an einer zweiten Vielzahl von Pixeln in Block 1, eine dritte Vielzahl von Pixeln in Block 2 und eine vierte Vielzahl von Pixeln in Block 3. Durch das Speichern jedes der Bildblöcke 0, 1, 2 und 3 in verschiedenen Blockdaten-Datenspeichern 148 kann der PFBC 100 und/oder die Prefetch-Maschine 200 jeden von ihnen parallel abrufen, um parallele Speichertransaktionen in effizienter Art und Weise zu verbessern und/oder anderweitig zu fördern und den Stromverbrauch im Zusammenhang mit Blockzugriffsmechaniken zu reduzieren.
4 stellt das exemplarische Eingabebild 300 von 3 dar, das auf den Cache-Speicher 146 von 1 basierend auf der Spalten-Hauptordnung abgebildet ist. Das exemplarische Eingabebild 300 ist in einem exemplarischen Set 402 organisiert. Das Set 402 von 4 ist eine zweidimensionale Anordnung der Bildblöcke 304 von 3. In 4 ist die zweidimensionale Anordnung eine 8x4-Anordnung, die acht Bildblöcke in Breite und vier Bildblöcke in Höhe ist, wobei jeder der Bildblöcke 304 64 Pixel beinhaltet.
Im veranschaulichten Beispiel von 4 sind die Bildblöcke 304 auf der Grundlage einer Spalten-Hauptorganisation angeordnet. So sind beispielsweise die Bildblöcke 0, 1, 2 und 3 in einem ersten 1×4-Block, die Bildblöcke 4, 5, 6 und 7 in einem zweiten 1x4-Block usw. angeordnet. So befindet sich beispielsweise ein erstes Pixel 404 mit Bildkoordinaten von X=4 und Y=9 im Bildblock 1. Das exemplarische erste Pixel 404 kann auf einen exemplarischen Pixelkern 406 abgebildet werden, der den Bildblock 1 und die Bildblöcke 0, 2 und 3 in Bezug auf den Bildblock 1 basierend auf der Spalten-Hauptorganisation beinhaltet.
Im veranschaulichten Beispiel von 4 bildet der PFBC 100 von 1 und/oder die Prefetch-Maschine 200 von 2 das Set 402 auf den Cache-Speicher 146 von 1 basierend auf der Spalten-Hauptordnung ab. So liegen beispielsweise die Bildblöcke 0, 1, 2 und 3 im Set 302 nebeneinander, befinden sich aber in verschiedenen Block-Datenspeichern 148. Durch Speichern jedes der Bildblöcke 0, 1, 2 und 3 in verschiedenen Blockdaten-Datenspeichern 148 kann der PFBC 100 und/oder die Prefetch-Maschine 200 jeden der Bildblöcke 0, 1, 2 und 3 parallel abrufen, um den Pixeldaten-Übertragung in Berechnungsaufgaben wie Bildverarbeitung, Computervision usw. zu verbessern. Alternativ kann der PFBC 100 und/oder die Prefetch-Maschine 200 das Eingabebild 300 auf den Cache-Speicher 146 basierend auf der Zeilen-Hauptordnung abbilden.
5 zeigt schematische Darstellungen von exemplarischen Blockorganisationen, die vom PFBC 100 von 1 und/oder der Prefetch-Maschine 200 verwendet werden, um Daten aus dem Cache-Speicher 146 von 1 zu lesen. Im veranschaulichten Beispiel von 5 ist ein erstes Beispiel für die Blockorganisation 502 eine 2x2 Blockorganisation. Die erste exemplarische Blockorganisation 502 entspricht der PFBC 100 und/oder der Prefetch-Maschine 200, die Bildblöcke auf den Cache-Speicher 146 basierend auf der Morton-Ordnung abbildet, wie vorstehend in Verbindung mit 3 beschrieben. Ein zweites Beispiel für die Blockorganisation 504 ist eine 1x4 Blockorganisation. Die zweite exemplarische Blockorganisation 504 entspricht der PFBC 100 und/oder der Prefetch-Maschine 200, die Bildblöcke auf den Cache-Speicher 146 basierend auf der oben in Verbindung mit 4 beschriebenen Spalten-Hauptordnung abbildet. Eine dritte exemplarische Blockorganisation 506 entspricht der PFBC 100 und/oder der Prefetch-Maschine 200, die Bildblöcke auf den Cache-Speicher 146 basierend auf der Zeilen-Hauptordnung abbildet. Alternativ können auch andere Blockorganisationen verwendet werden (z. B. eine 4×4 Blockorganisation, eine 2x8 Blockorganisation, eine 8×2 Blockorganisation etc.). So kann beispielsweise jede andere Blockorganisation, die auf einer 2×2, 1×4 oder 4×1 Blockorganisation basiert, verwendet werden.
In einigen Beispielen empfängt die Anforderungsschnittstelle 106 von 1 und/oder die Kern-Abrufeinrichtung 206 von 2 Pixelkoordinaten und leitet die Lese-Tag-Abbildungseinrichtung 152 und/oder die Prefetch-Kern-Abrufeinrichtung 202, um die Pixelkoordinaten auf eines oder mehrere der im Tag-Speicher 122 von 1 enthaltenen Tags 120 abzubilden. So kann beispielsweise der Lese-Tag-Abbildungseinrichtung 152 die Pixelkoordinaten auf den Bildblock 0 und anschließend auf die Bildblöcke 1, 2 und 3 basierend auf einer Lokalisierungsrelativität zu den Bildblöcken 1, 2 und 3 in Bezug auf den Bildblock 0 basierend auf einer der Blockorganisationen 502, 504, 506 von 5 abbilden.
6 stellt eine exemplarische Tabelle 600 dar, die exemplarische Signale beschreibt, die der Prefetch-Schnittstelle 104 von 1 zugeordnet sind. In der Tabelle 600 können ein exemplarisches Anforderungssignal 602, ein exemplarisches Pixel-X-Koordinatensignal 604 und ein exemplarisches Pixel-Y-Koordinatensignäl 606 über die Prefetch-Schnittstelle 104 empfangen werden. So kann beispielsweise die Prefetch-Schnittstelle 104 das Anforderungssignal 602, das Pixel-X-Koordinatensignal 604 und/oder das Pixel-Y-Koordinatensignal 606 vom Hardwarebeschleuniger 114 von 1 empfangen. In der exemplarischen Tabelle 600 von 6 kann über die Prefetch-Schnittstelle 104 ein exemplarisches Genehmigungssignal 608 erzeugt werden. Alternativ kann die Prefetch-Schnittstelle 104 weniger oder mehr Signale empfangen und/oder erzeugen, als in der Tabelle 600 dargestellt.
Das Anforderungssignal 602 von 6 ist ein 4-Bit-Signal mit einer Eingaberichtung (z. B. empfängt die Prefetch-Schnittstelle 104 das Anforderungssignal 602 vom Hardwarebeschleuniger 114). Das Anforderungssignal 602 stellt einen Blockanforderungsvektor dar, wobei Bit 0 dem Block 0 entspricht, Bit 1 dem Block 1 etc. In 6 ist das Anforderungssignal 602 HIGH aktiv. Im Anforderungssignal 602 von 6 gibt es X Bits pro Anforderung, die angeben, wie viel inkrementiert werden muss, um einen Zähleintrag, der im Tag 120 von 1 für den/die angeforderten Block(e) enthalten ist. Das Pixel-X-Koordinatensignal 604 von 6 (COORDS.X) ist ein 16-Bit-Signal mit einer Eingaberichtung, die eine X-Koordinate eines angeforderten Pixels darstellt. Das Pixel-Y-Koordinatensignal 606 von 6 (COORDS.Y) ist ein 16-Bit-Signal mit einer Eingaberichtung, die eine Y-Koordinate des gewünschten Pixels darstellt. Das Genehmigungssignal 608 von 6 ist ein 1-Bit-Signal mit einer Ausgaberichtung (z. B. erzeugt die Prefetch-Schnittstelle 104 das Genehmigungssignal 608). In 6 wird das Genehmigungssignal 608 auf aktiv HIGH gesetzt, wenn die Prefetch-Einrichtung 112 von 1 die gewünschten Pixelkoordinaten zur Verarbeitung akzeptiert hat.
7 stellt ein exemplarisches Zeitdiagramm 700 dar, das der Prefetch-Schnittstelle 104 von 1 im Betrieb entspricht. Zu einem exemplarischen ersten Zeitpunkt (T₁ ) 702 wird das Anforderungssignal (REQ) 602 von 6 als HIGH angenommen, was anzeigt, dass volle ganzzahlige Pixelkoordinaten angefordert werden (z. B. leitet der Hardwarebeschleuniger 114 die Prefetch-Schnittstelle 104, um Bildblöcke abzurufen, die den angeforderten Pixelkoordinaten zugeordnet sind). Beim exemplarischen ersten Zeitpunkt 702 wird das Genehmigungssignal (GNT) 608 von 6 als HIGH angenommen, was darauf hinweist, dass die Prefetch-Einrichtung 112 von 1 die Anforderung annehmen kann. Zu einem exemplarischen zweiten Zeitpunkt (T₂ ) 704 empfängt die Prefetch-Schnittstelle 104 nach drei ansteigenden Kanten eines exemplarischen Taktsignals (CLK) 706 Daten, die dem Pixel-X-Koordinatensignal 604 und dem Pixel-Y-Koordinatensignal 606 zugeordnet sind. Zum Beispiel empfängt die Prefetch-Schnittstelle 104 zum zweiten Zeitpunkt 704 Daten, die den Pixelkoordinaten zugeordnet sind, die von der Prefetch-Einrichtung 112 von 1 verarbeitet werden sollen.
Im Zeitdiagramm 700 von 7 wird zu einem exemplarischen dritten Zeitpunkt (T₃ ) 708 das Genehmigungssignal 608 LOW angegeben, was anzeigt, dass die aktuelle Anforderung gehalten werden soll. Wie im Zeitdiagramm 700 dargestellt, wird die Prefetch-Schnittstelle 104 so pipelineartig geleitet, dass standardmäßig das Genehmigungssignal 608 zunächst HIGH (z. B. das Genehmigungssignal 608 ist beim ersten Zeitpunkt 702 HIGH) und nach einer ersten Anforderung für einen oder mehrere Zyklen des Taktsignals 706 LOW beansprucht wird, während die Prefetch-Einrichtung 112 die Anforderung bearbeitet.
8 stellt eine exemplarische Tabelle 800 dar, die exemplarische Signale beschreibt, die der Anforderungsschnittstelle 106 von 1 zugeordnet sind. In der exemplarischen Tabelle 800 von 8 kann ein exemplarisches Anforderungssignal 802, ein exemplarisches Pixel-X-Koordinatensignal 804 und ein exemplarisches Pixel-Y-Koordinatensignal 806 über die Anforderungsschnittstelle 106 empfangen werden. So kann beispielsweise die Anforderungsschnittstelle 106 das Anforderungssignal 802, das Pixel-X-Koordinatensignal 804 und/oder das Pixel-Y-Koordinatensignal 806 vom Hardwarebeschleuniger 114 von 1 empfangen. In der exemplarischen Tabelle 800 von 8 kann ein exemplarisches Genehmigungssignal 808, ein exemplarisches erstes Datenblocksignal 810, ein exemplarisches zweites Datenblocksignal 812, ein exemplarisches drittes Datenblocksignal 814, ein exemplarisches viertes Datenblocksignal 816 und ein exemplarisches Gültigkeitssignal 818 über die Anforderungsschnittstelle 106 erzeugt werden. Alternativ kann die Anforderungsschnittstelle 106 weniger oder mehr Signale empfangen und/oder erzeugen, als in der Tabelle 800 dargestellt.
Das Anforderungssignal 802 von 8 ist ein 4-Bit-Signal mit einer Eingaberichtung (z. B. empfängt die Anforderungsschnittstelle 106 das Anforderungssignal 802). Das Anforderungssignal 802 stellt einen Blockanforderungsvektor dar, wobei Bit 0 dem Block 0 entspricht, Bit 1 dem Block 1 etc. In 8 ist das Anforderungssignal 802 aktiv HIGH. Im Anforderungssignal 802 von 8 gibt es zwei Bits pro Anforderung, die angeben, wie stark ein Zähleintrag, der im Tag 120 von 1 für den/die angeforderten Block(e) enthalten ist, dekrementiert werden soll. Das Pixel-X-Koordinatensignal 804 von 8 (COORDS.X) ist ein 16-Bit-Signal mit einer Eingaberichtung, die eine X-Koordinate eines angeforderten Pixels darstellt. Das Pixel-Y-Koordinatensignal 806 von 8 (COORDS.Y) ist ein 16-Bit-Signal mit einer Eingaberichtung, die eine Y-Koordinate des gewünschten Pixels darstellt.
In der Tabelle 800 von 8 ist das Genehmigungssignal 808 ein 1-Bit-Signal mit einer Ausgaberichtung (z. B. erzeugt die Anforderungsschnittstelle 106 das Genehmigungssignal 808). In 8 wird das Genehmigungssignal 808 auf aktiv HIGH gesetzt, wenn die Blockdaten-Leseeinrichtung 150 von 1 die angeforderten Pixelkoordinaten zur Verarbeitung akzeptiert hat. In 8 sind die Datenblocksignale 810, 812, 814, 816 256-Bit-Signale mit einer Ausgaberichtung. Das erste Datenblocksignal 810 entspricht dem Block 0, der das angeforderte Pixel beinhaltet. So kann beispielsweise Block 0 dem Block 0 der ersten Blockorganisation 502, der zweiten Blockorganisation 504 oder der dritten Blockorganisation 506 von 5 entsprechen. Ebenso entspricht das zweite Datenblocksignal 812 dem Block 1, das dritte Datenblocksignal 814 dem Block 2 und das vierte Datenblocksignal 816 dem Block 3. So können beispielsweise die Blöcke 1-3 den Blöcken 103 der ersten Blockorganisation 502, der zweiten Blockorganisation 504 oder der dritten Blockorganisation 506 von 5 entsprechen. In 8 ist das Gültigkeitssignal 818 ein 1-Bit-Signal mit einer Ausgaberichtung, die HIGH aktiv ist, wenn Daten für eine zuvor erteilte Anforderung als gültig bestimmt wurden.
9 stellt ein exemplarisches Zeitdiagramm 900 dar, das der Anforderungsschnittstelle 106 von 1 im Betrieb entspricht. Bei einem exemplarischen ersten Zeitpunkt (T₁ ) 902 wird das Anforderungssignal (REQ) 802 von 8 als HIGH eingestuft, was anzeigt, dass volle ganzzahlige Pixelkoordinaten angefordert werden. Beim ersten Zeitpunkt 902 wird das Genehmigungssignal (GNT) 808 von 8 als HIGH angenommen, was anzeigt, dass die Blockdaten-Leseeinrichtung 150 von 1 die Anforderung annehmen kann.
Zu einem exemplarischen zweiten Zeitpunkt (T₂ ) 904 empfängt die Anforderungsschnittstelle 106 nach drei ansteigenden Kanten eines exemplarischen Taktsignals (CLK) 906 Daten, die dem Pixel-X-Koordinatensignal 804 und dem Pixel-Y-Koordinatensignal 806 zugeordnet sind. Zum Beispiel empfängt die Anforderungsschnittstelle 106 zum zweiten Zeitpunkt 904 Daten, die den Pixelkoordinaten zugeordnet sind, die von der Blockdaten-Leseeinrichtung 150 von 1 verarbeitet werden sollen. Zum zweiten Zeitpunkt 904 interpretiert die Anforderungsschnittstelle 106 die Pixelkoordinaten, die durch das Pixel-X-Koordinatensignal 804 und das Pixel-Y-Koordinatensignal 806 dargestellt werden, als auf Block 0 abgebildet und die Blöcke 1-3 in Bezug auf Block 0, wie sie durch die Blockorganisationen 502, 504, 506 von 5 dargestellt werden.
Im Zeitdiagramm 900 von 9 wird zu einem exemplarischen dritten Zeitpunkt (T₃ ) 908 das Genehmigungssignal 808 LOW angegeben, was anzeigt, dass die aktuelle Anforderung gehalten werden soll. Wie im Zeitdiagramm 900 dargestellt, ist die Anforderungsschnittstelle 106 so pipelineartig geleitet, dass standardmäßig das Genehmigungssignal 808 zunächst HIGH (z. B. ist das Genehmigungssignal 808 beim ersten Zeitpunkt 902 und/oder beim Leerlauf der Anforderungsschnittstelle 106 HIGH) und nach einer ersten Anforderung für einen oder mehrere Zyklen des Taktsignals 906 LOW angegeben wird, während die Blockdaten-Leseeinrichtung 150 die Anforderung bearbeitet.
Zum dritten Zeitpunkt 908 kann die Blockdaten-Leseeinrichtung 150 die dem Pixel-X-Koordinatensignal 804 und dem Pixel-Y-Koordinatensignal 806 zugeordneten Pixelkoordinaten in eines der Tags 120 von 1 konvertieren. Die Blockdaten-Leseeinrichtung 150 liest die Tag-Datenspeicher 128 von 1, um zu bestimmen, ob die angeforderten Blöcke zwischengespeichert sind. Als Reaktion auf Bestimmen, dass die angeforderten Blöcke zwischengespeichert sind, bestimmt die Blockdaten-Leseeinrichtung 150, welcher der Blockdaten-Datenspeicher 148 die angeforderten Blöcke speichert. Als Reaktion auf Bestimmen, dass einer oder mehrere der angeforderten Blöcke nicht zwischengespeichert sind, wartet und/oder wird die Blockdaten-Leseeinrichtung 150 anderweitig blockiert, bis die angeforderten Blöcke verarbeitet und im Cache durch die Prefetch-Einrichtung 112 von 1 gespeichert werden. Als Reaktion auf Warten der Blockdaten-Leseeinrichtung 150, bis die angeforderten Blöcke im Cache gespeichert sind, wird das Genehmigungssignal 808 LOW gesetzt, bis die Blockdaten-Leseeinrichtung 150 verfügbar ist, um Anforderungen von der Anforderungsschnittstelle 106 zu empfangen.
In einigen Beispielen beträgt die minimale Latenz für einen Treffer drei Taktzyklen. Wenn beispielsweise zum dritten Zeitpunkt 908 die erste Koordinate auf dem Pixel-X-Koordinatensignal 804 und dem Pixel-Y-Koordinatensignal 806 empfangen wird, leitet die Blockdaten-Leseeinrichtung 150 eine Tag-Speichersuche im Tag-Speicher 122 ein. Sind die angeforderten Blöcke zwischengespeichert, so leitet die Blockdaten-Leseeinrichtung 150 im folgenden Zyklus zu einem exemplarischen vierten Zeitpunkt (T₄ ) 910 das Lesen der Blockdaten-Datenspeicher 148 ein. Im folgenden Zyklus, zu einem exemplarischen fünften Zeitpunkt (T₅ ) 912, bewirkt die Blockdaten-Leseeinrichtung 150, dass die zwischengespeicherten Daten auf der Datenschnittstelle 108 verfügbar sind. So kann beispielsweise die Blockdaten-Leseeinrichtung 150 den Cache-Speicher 146 anweisen, die zwischengespeicherten Daten in die Ausgaberegister der Datenschnittstelle 108 zu übertragen.
In einigen Beispielen werden die angeforderten Blockdaten in Registern dargestellt, so dass die Logik (z. B. Hardware, computerlesbare Anweisungen usw.), die die Datenschnittstelle 108 liest, die angeforderten Blockdaten direkt auf dem Datenpfad der Logik verwenden oder die angeforderten Blockdaten ohne zeitliche Schwierigkeiten oder Probleme an die weitere Muxing-Logik übergeben kann. In einigen Beispielen werden die angeforderten Blockdaten auf der Datenschnittstelle 108 von einer auf der Anforderungsschnittstelle 106 empfangenen Anforderung zur nächsten gehalten, so dass weitere Lesezugriffe (aus den Blockdaten-Datenspeichern 148) nicht erforderlich sind, wenn beispielsweise alle für die Verarbeitung der nächsten Pixelkoordinaten (oder mehr) erforderlichen Daten zuvor bei einer früheren Anforderung erreicht wurden.
10 stellt ein exemplarisches Tag 1000 dar, um Pixelkoordinaten, die einem Pixel zugeordnet sind, das in einem Eingabebild enthalten ist, zu zwischengespeicherten Daten im Cache-Speicher basierend auf der Morton-Ordnung und einer Pixelgröße von 2 Byte (2B) abzubilden. So basiert beispielsweise das Tag 1000 von 10 auf der Morton-Ordnung, wobei eine 2x2-Anordnung von Blöcken auf der Anforderungsschnittstelle 106 gelesen werden kann, wobei jeder Block 8x8 Pixel und jedes Pixel 2 Byte Speichergröße beträgt.
Das Tag 1000 von 10 beinhaltet ein exemplarisches Block-Tag 1002, einen exemplarischen Set-Index 1004 und einen exemplarischen Pixel-Index 1006. Das Block-Tag 1002 von 10 ist 21 Bit in der Speichergröße, basierend auf den elf höchstwertigen Bits der Y-Koordinate und den zehn höchstwertigen Bits der X-Koordinate eines angeforderten Pixels. Der Set-Index 1004 von 10 ist fünf Bits in Speichergröße und basiert auf einer Verkettung von einem fünften Bit der X-Koordinate, einem vierten Bit der Y- und X-Koordinate und einem dritten Bit der Y- und X-Koordinate. Der Pixel-Index 1006 von 10 ist sechs Bit in der Speichergröße und basiert auf den drei niederwertigsten Bits der Y- und X-Koordinaten.
11 stellt ein exemplarisches Tag 1100 dar, um Pixelkoordinaten, die einem Pixel zugeordnet sind, das in einem Eingabebild enthalten ist, zu zwischengespeicherten Daten im Cache-Speicher basierend auf der Morton-Ordnung und einer Pixelgröße von 1 Byte (1B) abzubilden. So basiert beispielsweise das Tag 1100 von 11 auf der Morton-Ordnung, wobei eine 2x2-Anordnung von Blöcken auf der Anforderungsschnittstelle 106 gelesen werden kann, wobei jeder Block 16x8 Pixel und jedes Pixel 1 Byte Speichergröße beträgt.
Das Tag 1100 von 11 beinhaltet ein exemplarisches Block-Tag 1102, einen exemplarischen Set-Index 1104 und einen exemplarischen Pixel-Index 1106. Das Block-Tag 1102 von 11 ist 20 Bit in der Speichergröße, basierend auf den elf höchstwertigen Bits der Y-Koordinate und den neun höchstwertigen Bits der X-Koordinate eines angeforderten Pixels. Der Set-Index 1104 von 11 ist fünf Bits in Speichergröße und basiert auf einer Verkettung eines sechsten Bits der X-Koordinate, eines vierten Bits der Y-Koordinate, eines fünften Bits der X-Koordinate, eines dritten Bits der Y-Koordinate und eines vierten Bits der X-Koordinate. Der Pixel-Index 1106 von 11 ist sieben Bit in Speichergröße und basiert auf den drei niederwertigsten Bits der Y-Koordinate und den vier niederwertigsten Bits der X-Koordinate.
12 stellt ein exemplarisches Tag 1200 dar, um Pixelkoordinaten, die einem Pixel zugeordnet sind, das in einem Eingabebild enthalten ist, zu zwischengespeicherten Daten im Cache-Speicher basierend auf der Set-Organisation der Spalten-Hauptordnung und einer Pixelgröße von 2 Bytes (2B) abzubilden. So basiert beispielsweise das Tag 1200 von 12 auf der Set-Organisation der Spalten-Hauptordnung, wobei eine 1x4-Anordnung von Blöcken auf der Anforderungsschnittstelle 106 gelesen werden kann, wobei jeder Block 8x8 Pixel und jedes Pixel 2 Byte Speichergröße beträgt.
Das Tag 1200 von 12 beinhaltet ein exemplarisches Block-Tag 1202, einen exemplarischen Set-Index 1204 und einen exemplarischen Pixel-Index 1206. Das Block-Tag 1202 von 12 ist 21 Bit in der Speichergröße, basierend auf den elf höchstwertigen Bits der Y-Koordinate und den zehn höchstwertigen Bits der X-Koordinate eines angeforderten Pixels. Der Set-Index 1204 von 12 ist fünf Bits in der Speichergröße und basiert auf einer Verkettung von einem fünften, vierten und einem dritten Bit der X-Koordinate und einem vierten und dritten Bit der Y-Koordinate. Der Pixel-Index 1206 von 12 ist sechs Bit in der Speichergröße und basiert auf den drei niederwertigsten Bits der Y- und X-Koordinaten.
13 stellt ein exemplarisches Tag 1300 dar, um Pixelkoordinaten, die einem Pixel zugeordnet sind, das in einem Eingabebild enthalten ist, zu zwischengespeicherten Daten im Cache-Speicher basierend auf der Set-Organisation der Spalten-Hauptordnung und einer Pixelgröße von 1 Byte (1B) abzubilden. So basiert beispielsweise das Tag 1300 von 13 auf der Set-Organisation der Spalten-Hauptordnung, wobei eine 1x4-Anordnung von Blöcken auf der Anforderungsschnittstelle 106 gelesen werden kann, wobei jeder Block 16x8 Pixel und jedes Pixel 1 Byte Speichergröße beträgt.
Das Tag 1300 von 13 beinhaltet ein exemplarisches Block-Tag 1302, einen exemplarischen Set-Index 1304 und einen exemplarischen Pixel-Index 1306. Das Block-Tag 1302 von 13 ist 20 Bit in der Speichergröße, basierend auf den elf höchstwertigen Bits der Y-Koordinate und den neun höchstwertigen Bits der X-Koordinate eines angeforderten Pixels. Der Set-Index 1304 von 13 ist fünf Bit in der Speichergröße und basiert auf einer Verkettung eines sechsten, fünften und vierten Bits der X-Koordinate und eines vierten und dritten Bits der Y-Koordinate. Der Pixel-Index 1306 von 13 ist sieben Bit in der Speichergröße und basiert auf den drei niederwertigsten Bits der Y-Koordinate und den vier niederwertigsten Bits der X-Koordinate.
14 stellt einen exemplarischen Tag-Speichereintrag 1400 für einen 4-Wege-Cache dar. So kann beispielsweise der Tag-Speichereintrag 1400 den Tag-Speichereinträgen 120 von 1 entsprechen. Der Tag-Speichereintrag 1400 von 14 beinhaltet einen exemplarischen ersten Weg-Index (WEG 0) 1402, einen exemplarischen zweiten Weg-Index (WEG 1) 1404, einen exemplarischen dritten Weg-Index (WEG 2) 1406 und einen exemplarischen vierten Weg-Index (WEG 3) 1408. Jeder der Indizes 1402, 1404, 1406, 1408 beinhaltet ein exemplarisches Tag-Feld 1410, ein exemplarisches Zählfeld (COUNT) 1412, ein exemplarisches Pending-Feld (P) 1414 und ein exemplarisches Validierungsfeld (V) 1416.
Im veranschaulichten Beispiel von 14 ist das Tag-Feld 1410 das Tag des auf dem entsprechenden Weg zwischengespeicherten Bildblocks. Das Tag-Feld 1410 von 14 beträgt 19 Bit bei einer Pixelspeichergröße von zwei Bytes und 20 Bit bei einer Pixelspeichergröße von einem Byte. Das Zählfeld 1412 ist ein 7-Bit-Feld, das eine Anzahl einer Reihe von ausstehenden Prefetch-Anforderungen für einen Block ist. So wird beispielsweise das Zählfeld 1412 bei jeder Anforderung eines Blocks auf der Prefetch-Schnittstelle 104 von 1 erhöht. Wenn das Zählfeld 1412 einen Maximalwert aufweist (z. B. b111111111 für ein 7-Bit-Feld), dann bleibt die Prefetch-Schnittstelle 104 stehen, bis das Zählfeld 1412 dekrementiert wird. In anderen Beispielen wird das Zählfeld 1412 jedes Mal dekrementiert, wenn eine Anforderung für den Bildblock auf der Anforderungsschnittstelle 106 erfüllt ist.
Das Pending-Feld 1414 ist ein 1-Bit-Feld, das signalisiert, dass der Bildblock, der dem im Tag-Feld 1410 enthaltenen Tag entspricht, gerade abgerufen wird (z. B. ausstehend) und in nachfolgenden Taktzyklen auf den entsprechenden Weg des Cache-Speichers 146 zwischengespeichert wird. Das Validierungsfeld 1416 ist ein 1-Bit-Feld, das signalisiert, dass der dem Tag entsprechende Bildblock im Tag-Feld 1410 auf den entsprechenden Weg in einem der Datenblock-Datenspeicher 148 zwischengespeichert wird. In einigen Beispielen können alle Validierungsfelder 1416, die in den Tags 120 des Tag-Speichers 122 enthalten sind, gelöscht werden, um den Cache zu invalidieren und/oder anderweitig zu leeren. Alternativ kann der Tag-Speichereintrag 1400 weniger oder mehr als die in 14 dargestellten Felder aufweisen. Alternativ können das Tag-Feld 1410, das Zählfeld 1412, das Pending-Feld 1414 und/oder das Validierungsfeld 1416 eine beliebige andere Anzahl von Bits aufweisen. Alternativ kann der Tag-Speichereintrag 1400 mit separaten Registern implementiert werden.
15 zeigt eine exemplarische SBR 1500 zum Abrufen von Blöcken aus dem Hauptspeicher 110. In einigen Beispielen erzeugt die Prefetch-Einrichtung 112 und/oder die Prefetch-Kern-Abrufeinrichtung 202 von 2 die SBR 1500, um Bildblockdaten abzurufen, die den angeforderten Pixelkoordinaten zugeordnet sind, die sich derzeit nicht im Cache befinden. In einigen Beispielen erzeugt die Prefetch-Einrichtung 112 und/oder die Prefetch-Kern-Abrufeinrichtung 202 von 2 die SBR 1500, um spekulativ Bildblockdaten abzurufen, die mit nicht angeforderten Pixelkoordinaten verbunden sind, die sich derzeit nicht im Cache befinden.
Die SBR 1500 von 15 beinhaltet ein exemplarisches Koordinatenfeld (BLK_COORD) 1502, ein exemplarisches Blockmengenfeld 1504 und exemplarische Wegfelder 1506. Das Koordinatenfeld 1502 von 15 entspricht den Pixelkoordinaten eines ersten zu holenden Blocks aus dem Hauptspeicher 110. Das Blockmengenfeld 1504 von 15 entspricht einer Gesamtzahl von zusätzlichen Blöcken, die links vom ersten Block geholt werden sollen. Alternativ kann das Blockmengenfeld 1504 einer Gesamtzahl von zusätzlichen Blöcken entsprechen, die über, unter oder rechts vom ersten Block geholt werden sollen. Das Blockmengenfeld 1504 hat eine Speichergröße von 3 Bit, um eine Anzahl von auszuwählenden Blöcken weniger eins zu berücksichtigen (z. B. Anzahl der Blöcke = N - 1). Alternativ kann das Blockmengenfeld 1504 verwendet werden, um eine Gesamtzahl von zusätzlichen Blöcken darzustellen, die rechts neben dem ersten Block abgerufen werden sollen. In Beispielen, in denen die SBR 1500 zum Suchen rechts vom ersten Block verwendet wird, wird der letzte Block, der von der Tag-Abbildungseinrichtung 124 von 1 im Cache-Speicher 146 von 1 zwischengespeichert wurde, zum ersten Block der Anforderung, so dass Speicherzugriffe, die mehrere Blöcke umfassen, immer inkrementiert und somit zu einem Burst zusammensetzbar werden.
In 15 stellen die Felder 1506 eine Liste dar, die den Weg, in welchen jeder von der SBR 1500 angeforderte Block zwischengespeichert wird, in den Cache-Datenspeichern 148 des Cache-Speichers 146 beinhaltet. Im Betrieb bestimmen die Prefetch-Einrichtung 112 und/oder die Prefetch-Kern-Abrufeinrichtung 202, dass ein oder mehrere SBRs 1500 basierend auf einer Suche im Tag-Speicher 122 von 1 erzeugt werden. Wenn beispielsweise die Tag-Abbildungseinrichtung 124 von 1 bestimmt, dass alle für die angeforderten Pixelkoordinaten benötigten Blöcke Treffer sind, dann generiert die SBR-Erstellungseinrichtung 126 die SBR 1500 nicht. So kann beispielsweise die SBR-Erstellungseinrichtung 126 die SBR 1500 nicht erzeugen, wenn jedes von der Tag-Abbildungseinrichtung 124 basierend auf den Pixelkoordinaten erzeugte Block-Tag in den Tag-Datenspeichern 128 von 1 gefunden wird und entweder das Pending-Feld 135 oder das Validierungsfeld der entsprechenden Einträge 130 gesetzt ist. In anderen Beispielen, in denen ein oder mehrere Blöcke fehlen (z. B. Block-Tags befinden sich nicht in den Tag-Datenspeichern 128 und die Bildblöcke befinden sich nicht im Cache-Speicher 146), generiert die SBR-Erstellungseinrichtung 126 die SBR 1500 und schiebt die SBR 1500 in den SBR-FIFO 136 von 1 zur Verarbeitung durch die Block-Abrufeinrichtung 138 von 1.
In einigen Beispielen erzeugt die SBR-Erstellungseinrichtung 126 eine oder mehrere der SBR 1500, ohne spekulative Anforderungen zu stellen. So kann beispielsweise die SBR-Erstellungseinrichtung 126 für jeden Block, der abgerufen und im Cache-Speicher 146 gespeichert werden soll, eine der SBR 1500 erstellen. In solchen Beispielen erstellt die SBR-Erstellungseinrichtung 126 für jeden Block eine der SBR 1500 von 15, indem sie die Pixelkoordinaten des Bildblocks von Interesse in das Koordinatenfeld 1502 einfügt, das Blockmengenfeld 1504 auf null setzt und ein erstes der Wegfelder (W0) 1506 auf die Nummer des Weges, in welchen der Bildblock zwischengespeichert wird, in einem der Cache-Datenspeicher 148 setzt.
In einigen Beispielen erzeugt die SBR-Erstellungseinrichtung 126 eine oder mehrere der SBR 1500, um spekulative Anforderungen zu stellen. In einigen Beispielen erzeugt die SBR-Erstellungseinrichtung 126 bei spekulativen Anforderungen maximal zwei SBR 1500 mit einer Mindestmenge von zwei Blöcken, die in jeder SBR angefordert werden. In solchen Beispielen enthält eine erste der SBR 1500 Information für Block 0 und Block 1. So kann beispielsweise die SBR-Erstellungseinrichtung 126 die Koordinaten für Block 0 dem Koordinatenfeld 1502 zuweisen, das Blockmengenfeld 1504 auf einen Wert setzen, der zwei Blöcken entspricht, um weniger als einen zu holen, und das erste und zweite der Wegfelder (W0, W1) auf die Nummern der Wege, auf denen Block 0 und Block 1 zwischengespeichert werden, im Cache-Datenspeicher 148 einstellen. Eine zweite der SBR 1500 kann Information für Block 2 und Block 3 enthalten. So kann beispielsweise die SBR-Erstellungseinrichtung 126 die Koordinaten für Block 2 dem Koordinatenfeld 1502 zuordnen, das Blockmengenfeld 1504 auf einen Wert setzen, der zwei Blöcken entspricht, um weniger als einen zu holen, und das erste und zweite der Wegfelder (W0, W1) auf die Nummern der Wege, auf denen Block 2 und Block 3 zwischengespeichert werden, im Cache-Datenspeicher 148 einstellen.
16 veranschaulicht ein Blockdiagramm einer exemplarischen Implementierung eines exemplarischen Warp-Filters 1600, der den PFBC 100 aus 1 beinhaltet. Der exemplarische Warp-Filter 1600 aus 16 führt geometrische Operationen auf Bildern unter Verwendung von bikubischer Abtastung durch. Grundsätzlich nimmt der Warp-Filter 1600 ein Eingabebild auf, das er mit Hilfe eines Gitters „verzerrt“, um ein Ausgabebild zu erzeugen. In 16 ist der Warp-Filter 1600 ein Speicher-zu-Speicher-Block und beinhaltet drei exemplarische Speicherschnittstellen 1602, 1604, 1606. Die erste Speicherschnittstelle 1602 von 16 ist eine Lese-Speicherschnittstelle für Gitter-Speicher oder eine Gitter-Leseschnittstelle. Die zweite Speicherschnittstelle 1604 von 16 ist eine Lese-Speicherschnittstelle für Pixelspeicher oder eine Block-Cache-Pixel-Leseschnittstelle. Die dritte Speicherschnittstelle 1606 von 16 ist eine Schreib-Speicherschnittstelle zum Pixelspeicher (z. B. eine 128-Bit-Speicher-Rückschreib-Schnittstelle) oder eine Pixel-Schreibschnittstelle.
17 ist eine exemplarische Fischaugen-Transformation 1700, die vom Warp-Filter 1600 aus 16 verarbeitet wird, um Verzerrungen zu entfernen. Der Warp-Filter 1600 entfernt Fischaugenverzerrungen aus einem exemplarischen Eingabebild 1702 unter Verwendung eines exemplarischen Gitters 1704, um ein exemplarisches Ausgabebild 1706 zu erzeugen. Die Verzerrungsaktion kann als eine Aktion betrachtet werden, die das Ausgabebild auf Pixelbasis modifiziert. Das exemplarische „Gitter“ (mesh) ist ein Satz von Koordinaten, die die Ausgabepixel auf Lokalisierungen im Eingabebild abbilden. Das exemplarische Gitter kann entweder ein spärliches Gitter oder ein vorgedehntes Gitter sein. Im Falle eines spärlichen Gitters expandiert der Warp-Filter 1600 von 16 das Gitter intern, um für jedes Pixel im Ausgabebild einen expandierten Gitterpunkt zu erzeugen. Bei einem vorgedehnten Gitter ist das Gitter bereits vollständig expandiert. Der expandierte Gitterpunkt ist im Grunde genommen eine (X,Y)-Lokalisierung im Eingabebild.
Ein exemplarisches Gitter wird verwendet, um die Transformation zu definieren. Jeder Punkt im Gitter enthält (X,Y)-Paar von Abtastkoordinaten. Das Gitter wird zur Laufzeit mit bilinearer Abtastwiederholung (Resampling) abgetastet, um X- und Y-Abtastkoordinaten pro Pixel in der Ausgabebildauflösung zu erzeugen. Das Eingabebild wird dann an diesen Koordinaten mit bikubischer Abtastung abgetastet, um die Ausgabebildpunkte zu erzeugen. Anwendungsbeispiele für den bikubischen Warp-Filter sind die Fischaugenverzerrungskorrektur sowie die Nadelkissen- und Trommelverzerrungskorrektur.
18 ist eine schematische Darstellung von exemplarischen expandierten Gitterpunkten. In 18 ist jeder große Punkt auf der linken Seite ein exemplarischer spärlichen Gitterpunkt 1802. Im veranschaulichten Beispiel von 18 gibt es 4 spärliche Gitterpunkte 1802, die auf 88 exemplarische Gitterpunkte 1804 auf der rechten Seite expandiert werden (dargestellt als kleinere Punkte). Jeder der kleineren Punkte auf der rechten Seite kann als Pixelpunkt im Ausgabebild betrachtet werden und hat einen (X,Y)-Vektor zu einer Lokalisierung im Eingabebild. Jeder der kleineren Punkte auf der rechten Seite kann auf eine beliebige Stelle im Eingabebild abgebildet werden.
Wenn der exemplarische Warp-Filter 1600 aus 16 ein bestimmtes Ausgabepixel berechnet, erhält der Warp-Filter 1600 das Pixel und die erforderlichen umgebenden Kern-Pixel innerhalb des Eingaberahmens, auf den der expandierte Gitterpunkt zeigt. Der Warp-Filter 1600 führt dann entweder bikubische oder bilineare Filterung auf dem Pixelkern durch, um das eigentliche Ausgabepixel zu erzeugen. Der Warp-Filter 1600 durchläuft das definierte Ausgabebild und erzeugt Ausgabepixel, indem er nach den Kernen filtert, auf die das expandierte Gitter zeigt. Auf diese Weise kann aus einem Eingaberahmen und einem Gitter ein ganzer Ausgaberahmen erzeugt werden.
19 veranschaulicht ein exemplarisches Bild 1900, das durch den Warp-Filter 1600 aus 16 in gleiche Kacheln (Tiles) 1902 zerlegt wurde. Das Bild 1900 von 19 beinhaltet 32 Pixel × 16 Zeilen, die in 4 gleiche Kacheln 1902 aufgeteilt sind. Der Warp-Filter 1600 aus 16 arbeitet jeweils auf einer Verarbeitungskachel 1902. Die Kacheln 1902 beziehen sich auf das Ausgabebild und können als Kacheln innerhalb des Ausgabebildes betrachtet werden. Mit anderen Worten, der Warp-Filter 1600 ist konfiguriert, um ein Ausgabebild zu erzeugen, das aus einer Anzahl von Kacheln besteht (z. B. die Kacheln 1902). Die aktuelle Verarbeitungskachel wird abgeschlossen, bevor zur nächsten Verarbeitungskachel gewechselt wird. Die Abmessungen der Kacheln sind vom Host konfigurierbar und können in Höhe und Breite eine der folgenden sein: 8, 16, 32, 64, 128. In einigen Beispielen gibt es aus Hardware-Sicht keine Abhängigkeit zwischen Kachelhöhe und Kachelbreite.
Zurück zu 16, werden die Speicherschnittstellen 1602, 1604, 1606 über vom Host zugängliche Register gesteuert und/oder konfiguriert. So kann beispielsweise der Warp-Filter 1600 durch vom Host konfigurierbare Register so gesteuert werden, dass die Konfigurierbarkeit erhalten bleibt, aber die Notwendigkeit von Unterbrechungen und Hostinterventionen reduziert wird. In einigen Beispielen erfolgt die vollständige Konfiguration, bevor der Host den Warp-Filter 1600 anweist, den Betrieb aufzunehmen. So muss beispielsweise der Host sicherstellen, dass im Eingabebild-Puffer eine ausreichende Anzahl von Eingabezeilen vorhanden ist, um die Vielzahl von Gitterpunkten im Eingabegitter (entweder vorgedehnt oder spärlich) vor dem Start des Warp-Filters 1600 zu bedienen. Alle Gitterpunkte, die außerhalb des Eingabebild-Puffers liegen, können dazu führen, dass das nächstgelegene Kantenpixel mit Padding verwendet wird, um den vollständigen 4x4-bikubischen Kern zu erstellen.
In einigen Beispielen konfiguriert der Host die Kachelgröße und die Anzahl der Kacheln, mit denen der Warp-Filter 1600 arbeitet, bevor er eine Unterbrechung erzeugt. Im Allgemeinen ist die Anzahl der Kacheln im Lauf eine ganze Kachelreihe, aber nicht unbedingt so. Der Host kann auch die Startposition einer Kachel innerhalb des Ausgabebildes angeben. Die Ausgabeposition kann in Form eines (X[15:0],Y[15:0])-Versatzes von der linken oberen Pixelposition in einem Bild vorliegen, das als Position (0,0) angenommen wird.
In einigen Beispielen wird ein Ringspeicher für den Eingabebild-Puffer zum Warp-Filter 1600 verwendet. In solchen Beispielen kann der Host den Speicher-Versatz und die Anzahl der Zeilen im Ringspeicher programmieren. Wie bereits erwähnt, kann das Verhalten des Warp-Filters 1600 undefiniert sein, wenn die Gitterpunkte außerhalb des Ringspeichers liegen. Die Hardware kann eine Position innerhalb des Ringspeichers verfolgen und von absoluten Speicheradressen anfordern.
In dem veranschaulichten Beispiel von 16 beinhaltet der Warp-Filter 1600 eine exemplarische Gitter-Expansionseinrichtung 1608, um ein spärliches Gitter aufzunehmen und das spärliche Gitter zu expandieren, um es auf ein Ausgabebild abzubilden, wie vorstehend in Verbindung mit 18 beschrieben. Die hierin offenbarten exemplarischen Gitter-Expansionen beinhalten ein Eingabedaten-Format mit spärlichen Gitterpunkten in FP32 oder Mischpunkt 16-Bit-Mischpunkt (programmierbare Dezimalposition), wobei der Wert relativ zum (0,0)-Ursprung mit 1/Granularität und 20-Bit-Nichtganzzahl U(0,20) ist. Zusätzlich hat ein exemplarisches Ausgabedaten-Format expandierte Gitterpunkte in FP32.
Die exemplarische Gitter-Expansionseinrichtung 1608 aus 16 greift auf den Hauptspeicher zu, um die spärlichen Gitterpunkte zu holen, so dass sie für die nachfolgende Logik expandiert werden können. Die Gitterpunkte werden normalerweise im PF32-Format gehalten, aber auch andere Formate wie Mischkomma 16-Bit-Mischkomma können unterstützt werden. Für Gitterpunkte, die in einem anderen Format als FP32 gespeichert sind, kann die Gitter-Expansionseinrichtung 1608 diese Formate vor jeder Interpolation in FP32 konvertieren. In 16 sind die Eingabegitterpunkte absolute Positionen (z. B. sind die Eingabegitterpunkte nicht relativ zur aktuellen Ausgabekoordinatenposition).
Die Interpolation in der exemplarischen Gitter-Expansionseinrichtung 1608 ist bilinear. Die Granularität der exemplarischen Gitter-Expansionseinrichtung 1608 ist als 20-Bit-Nichtganzzahl 1/Granularität programmiert, um kostspielige Teiler in der Hardware zu vermeiden. Die Berechnung der Alpha- und Beta-Komponenten (z. B. die nichtganzzahlige Position der zwei linearen Filter) kann im Festkomma U(16,20) durchgeführt werden, so dass Alpha und Beta beide als 20-Bit-Nichtganzzahl dargestellt werden. In 16 erfolgt die Umwandlung von Alpha und Beta von 20-Bit-Nichtganzzahl auf FP32 vor der bilinearen Interpolation der Gitterpunkte. Die bilineare Interpolation des Gitterpunktes erfolgt in FP32. Die Ordnung der Interpolation ist vertikal, gefolgt von horizontal. Das Packen der Gitterpunkte in das Speicherwort hängt vom Format der Gitterpunkte ab. Zwei exemplarische Optionen für Gitterpunkt-Formate sind entweder FP32 oder Mischkomma 16 Bit. Diese exemplarischen Optionen werden im Folgenden beschrieben.
Für Beispiele im Zusammenhang mit FP32 enthält jedes Wort zwei spärliche Gitterpunkte, von denen jeder aus einer FP32-X- und einer FP32-Y-Komponente besteht. Die oberen 32 Bit des Speicherwortes halten die X-Komponente und die unteren 32 Bit enthalten die Y-Komponente. Eine exemplarische Speicherorganisation von Gitterpunkten im FP32-Format 2000 ist in 20 dargestellt.
Für Beispiele, die sich auf einen 16-Bit-Festkomma mit programmierbarer Dezimalstelle beziehen, enthält jedes zurückkommende Speicherwort 4 spärliche Gitterpunkte, die den Gitterpunkt für Lokalisierung A und die Lokalisierungen direkt rechts - Lokalisierung A + 1, Lokalisierung A+2 und Lokalisierung A+3 - darstellen. Die unteren 32 Bits enthalten die X- und Y-Komponenten für die Lokalisierung A, die nächsten 32 Bits die X- und Y-Komponenten für die Lokalisierung A+1 und so weiter bis zur Lokalisierung A+3. Eine exemplarische Speicherorganisation von Gitterpunkten im 16-Bit-Format 2100 ist in 21 dargestellt. Bei Gittern, die keine Breite von einem Vielfachen von 4 haben, wird der Wert an unbenutzten Lokalisierungen nicht definiert.
Ein Beispiel für den Modus vorgedehntes Gitter ist ein alternativer Pfad zu Gitter-Expansion. Der eine oder andere Pfad wird innerhalb des Warps genommen. Die Auswahl des vorgedehnten Modus über die Gitter-Expansion erfolgt durch Setzen des Bits PREEXPANDED_MODE auf 1 im Register WARP_MESH. Der vorgedehnte Gitter-Modus beinhaltet ein Eingabedatenformat als expandiertes Gitter in Mischkomma 16 Bit, eine programmierbare Dezimalposition, bezogen auf die Ausgabepixelposition, und ein Ausgabedatenformat als expandierter Gitterpunkt in FP32 absolut.
Im Modus vorgedehntes Gitter wird ein vorgedehntes Gitter aus dem Speicher geholt. In solchen Beispielen wird die Gitter-Expansionseinrichtung 1608 umgangen und die vorgedehnten Gitterpunkte werden in FP32 an eine exemplarische Gitter-Transformationseinrichtung 1610 ausgegeben. Der Eingabemodus ist der Mischpunkt 16 Bit für die Gitterpunkte und diese Gitterpunkte sind relativ zur aktuellen Pixelposition. So wird beispielsweise der 16-Bit-Eingabegitterpunktvektor zur aktuellen Pixelposition hinzugefügt, um den endgültigen absoluten Gitterpunktvektor zu erhalten. Die Dezimalposition der eingegebenen 16 Bit ist programmierbar, so dass eine Vielzahl von Genauigkeiten und Bildgrößen berücksichtigt werden.
Die expandierten Gitterpunkte sind in 128 Bit gepackt, wobei jedes Wort aus vier Gitterpunkten besteht. Jeder Gitterpunkt wird durch eine X- und Y-Komponente repräsentiert. Diese X- und Y-Komponenten sind mit den höchsten 16 Bit, die die FP16-X-Komponente darstellen, und den niedrigsten 16 Bit, die die FP16-Y-Komponente enthalten, gepackt. Eine exemplarische Speicherorganisation der vorgedehnten Gitterpunkte 2200 ist in 22 dargestellt. Die Ausgabe der vorgedehnten Teilblöcke ist FP32.
In einigen Beispielen kann das vorgedehnte Teilmodul konfiguriert sein, um ein Bypass-Gitter auszugeben. Ein Bypass-Gitter ist ein exemplarisches Gitter, bei dem die Gitterpunktwerte alle gleich der (X, Y)-Position im Ausgabebild sind. Um den Warp so zu konfigurieren, dass ein Bypass-Gitter erzeugt wird, schreibt die exemplarische Anwendung ein 1'b1 in das Feld MESH_BYPASS des Registers WARP_MESH und setzt gleichzeitig die Felder PREEXPANDED_MODE = 1'b1, RELATIVE = 1'b1 und DEC_POSN = 4'b0 (auch in WARP_MESH).
In dem veranschaulichten Beispiel von 16 beinhaltet der Warp-Filter 1600 die Gitter-Transformationseinrichtung 1610, um die FP32 expandierten Gitterpunkte als Eingabe zu nehmen, und erzeugt S(16,8) transformierte Gitterpunkte als Ausgabe der Gitter-Transformationseinrichtung 1610. Intern in der Gitter-Transformationseinrichtung 1610 ist der Datenpfad vollständig FP32, mit Ausnahme der endgültigen Umwandlung von FP32 in S(16,8). Ein exemplarisches Eingabedatenformat für die Gitter-Transformationseinrichtung 1610 kann ein expandiertes Gitter mit FP32 sein, und ein Ausgabeformat kann ein transformiertes Gitter mit S(16,8) sein. In einigen Beispielen beinhaltet die Gitter-Transformationseinrichtung 1610 einen Bypass-Modus, bei dem Gitterpunkte bis auf die endgültige Transformation von FP32 nach S(16,8) unbeeinflusst durchlaufen werden. Der Bypass-Modus ist nicht zu verwechseln mit dem Bypass-Gitter. In einigen Beispielen beinhaltet die Gitter-Transformationseinrichtung 1610 einen Teiler-Bypass-Modus, um die Teiler auszuschalten (zur Energieeinsparung), wenn der Host nur eine Teilung durch 1 benötigt. Der Teiler-Bypass (XFORM_DIV_BYPASS) und der gesamte Transformations-Bypass (XFORM_BYPASS) können durch ein Register des Warp-Filters 1600 (z. B. einem Register WARP_MODE) konfiguriert werden.
Die exemplarische Gitter-Transformationseinrichtung 1610 aus 16 kann mindestens drei Hauptoperationen durchführen. Eine erste exemplarische Operation beinhaltet eine exemplarische 3x3-Matrixtransformation, bei der die FP32-Eingabegitterpunkte durch eine 3x3-Matrix geleitet werden, für die die Gitter-Transformationseinrichtung 1610 Anweisungen (z. B. maschinenlesbare Anweisungen, Hardwarelogik usw.) ausführt, die dem Pseudocode entsprechen, der durch die Beispiele der Gleichungen (4)-(6) unten dargestellt wird: $x = (m (0,0) * mx) + (m (0,1) * my) + m (0,2)$
$y = (m (1,0) * mx) + (m (1,1) * my) + m (1,2)$
$z = (m (2,0) * mx) + (m (2,1) * my) + m (2,2)$
In den Beispielen der obigen Gleichungen (4)-(6) stellt m die 3x3-Matrix dar, mx stellt die FP32-x-Komponente des Gitterpunktes dar und my stellt die FP32-y-Komponente des Gitterpunktes dar. Die Ausgaben sind x, y und z. Die Multiplikations- und Additionsvorgänge werden im FP32 durchgeführt. Die Matrixkoeffizienten werden über ein oder mehrere Register (z. B. die Register WARP_MAT0 (m(0,0)) bis WARP_MAT8 (m(2,2))) konfiguriert.
Ein zweites Beispiel für eine Operation, die mit der Gitter-Transformationseinrichtung 1610 aus 16 durchgeführt werden kann, ist eine Division durch z-Operation. So können beispielsweise x und y durch z geteilt werden, wobei x, y und z die Ausgaben der Matrixtransformationen der Beispiele der obigen Gleichungen (4)-(6) sind. So kann beispielsweise die Gitter-Transformationseinrichtung 1610 Anweisungen ausführen, die dem Pseudocode entsprechen, der durch die Beispiele der Gleichungen (7)-(8) dargestellt wird, wie nachfolgend beschrieben: $x' = x / z$
$y' = y / z$
Die Gitter-Transformationseinrichtung 1610 kann die resultierenden x' und y' von FP32 in einen 16-Bit-Integer mit Vorzeichen mit 8-Bit-Nichtganzzahl (S(16,8)) umwandeln.
In dem veranschaulichten Beispiel von 16 beinhaltet der Warp-Filter 1600 den PFBC 100 von 1, um das Prefetching von Pixeln aus dem Hauptspeicher durchzuführen. Der Warp-Filter 1600 verwendet den PFBC 100, um die Speicherlatenz, die im Falle von DRAM eine erhebliche Verzögerung darstellen kann, effektiv zu eliminieren. In einigen Beispielen wird nur der Integer-Teil des Eingabegitterpunktes verwendet, um den benötigten 4x4-Pixelkern aus dem AMC-Speichersystem zu holen. Der nichtganzzahlige 8-Bit-Teil wird an den nächsten Teilblock in der Pipeline weitergeleitet: den bikubischen Resampler-Teilblock. In einigen Beispielen wird ein Eingabedatenformat des PFBC 100 erweitert, transformiert Gitterpunkt - S(16,8) und Eingabepixel aus dem Hauptspeicher in U8 oder U16. In einigen Beispielen ist ein Ausgabedatenformat des PFBC 100 ein 4x4-Pixelkern in U16.
Der PFBC 100 von 1 ist ein 4-Wege Prefetch Block Cache. In einigen Beispielen besteht jeder Block aus 128 Bit × 8 Zeilen. In einigen Beispielen besteht jedes Set aus 8 Blöcken × 4 Blockreihen. Der im Warp-Filter 1600 enthaltene PFBC 100 arbeitet mit Pixelblöcken als Basiseinheit für den Abruf aus DRAM oder CMX. In einigen Beispielen beträgt die Größe der Bildblöcke entweder 8x8 Pixel im 16-Bit-Pixelmodus oder 16x8 Pixel im 8-Bit-Pixelmodus. 23 zeigt ein Beispiel für Blöcke und Superblöcke 2300, die im PFBC 100 im Beispiel von 16 verwendet werden. Per Definition wird sich immer mindestens ein Kern-Pixel irgendwo innerhalb von Blk0 von Superblock0 befinden.
In einigen Beispielen kann der PFBC 100 angepasst werden, um die maximale Menge, die der PFBC 100 spekulativ per Prefetch abgerufen wird, jederzeit durch Anpassung eines oder mehrerer Register zu ändern (z.B. das Feld SPEC_REQUEST_MODE des Registers WARP_PFBC). Beispielsweise kann ein Register wie das Feld SPEC_REQUEST_MODE auf:
(A) 3'd0 bedeutet, dass kein spekulatives Prefetching stattfindet und der PFBC 100 nur die Bildblöcke (bis zu 4) holt, die zur Erfüllung des aktuell angeforderten Kerns erforderlich sind. Im Falle der in 23 dargestellten Kernposition würde der PFBC 100 alle 4 Blöcke von Superblock0 2302 holen, um den angeforderten Kern zu erfüllen.
(B) 3'd1 bedeutet, dass ein Superblock, der den angeforderten Kern enthält (wenn bestimmte Bedingungen erfüllt sind, siehe Hinweis unten), geholt wird, auch wenn der Kern nicht in ihn hineinragt. Das heißt, es wird ein spekulatives Prefetching für 4 Blöcke geben, was notationsgemäß als Superblock0 2302 in 23 bezeichnet ist.
(C) 3'd2 bedeutet, dass zwei Superblöcke abgerufen werden (wenn bestimmte Bedingungen erfüllt sind, siehe Hinweis unten). Das heißt, es wird ein spekulatives Prefetching für die 8 Blöcke geben, was notationsgemäß als Superblock0 2302 und Superblock1 2304 in 23 bezeichnet ist.
(D) 3'd3 bedeutet, dass drei Superblöcke abgerufen werden (wenn bestimmte Bedingungen erfüllt sind, siehe Hinweis unten). Das heißt, es wird ein spekulatives Prefetching für die 8 Blöcke geben, was notationsgemäß als Superblock0 2302, Superblock1 2304 und Superblock2 2306 in 23 bezeichnet ist.
(E) 3'd4 bedeutet, dass vier Superblöcke abgerufen werden (wenn bestimmte Bedingungen erfüllt sind, siehe Hinweis unten). Das heißt, es wird ein spekulatives Prefetching für die 8 Blöcke geben, was notationsgemäß als Superblock0 2302, Superblock1 2304, Superblock2 2306 und Superblock3 2308 in 23 bezeichnet ist.
In einigen Beispielen kann ein Register (z.B. das Feld PID_DEDUPE des Registers WARP MODE) des Warp-Filters 1600 verwendet werden, um die Duplizierung von Kernen, die in den PFBC 100 eingegeben werden, zu entfernen. So kann beispielsweise das Register verwendet werden, um Speicherzugriffe innerhalb des PFBC 100 mit dem Ziel der Leistungsreduzierung zu reduzieren.
Ein Beispiel für einen bikubischen Resampler beinhaltet ein Eingabedatenformat von 4x4-Pixelkernen in U16 und eine 8-Bit-Nichtganzzahl und ein Ausgabedatenformat von U16-Ausgabepixeln. Es gibt zwei exemplarische Betriebsarten für den Resampler-Teilblock - bikubisch und bilinear. Der bikubische Modus verwendet einen 4x4-Pixelkern im U16-Format; der bilineare Modus verwendet einen 2x2-Pixelkern im U16-Format. Wenn der Eingabekem zufällig nah ist und über die Kante des Bildes hängt (z. B. liegen nicht alle Pixel im Kern innerhalb der Eingabebildgrenze), werden diese nicht vorhandenen Pixel entweder mit dem gleichen Wert wie ihr nächster Nachbar oder mit einer vom Host definierten Farbe gefüllt. Diese Kantenbetriebsart ist Host konfigurierbar. So kann beispielsweise die horizontale Operation zuerst ausgeführt werden, gefolgt von der vertikalen.
In einigen Beispielen werden die bikubischen Koeffizienten aus der 8-Bit-Nichtganzzahl-Eingabe generiert und können wie folgt berechnet werden:
$A : (- 1 / 2 * t + t 2 - 1 / 2 * t 3);$
$B : (1 - 5 / 2 * t 2 + 3 / 2 * t 3);$
$C : (1 / 2 * t + 2 * t 2 - 3 / 2 * t 3); und$
$D : (- 1 / 2 * t 2 + 1 / 2 * t 3),$
wobei t die 8-Bit-Nichtganzzahl-Eingabe ist, t2 t*t ist und t3 t*t*t*t ist. In einigen Beispielen ist t entweder aus X bei der Berechnung der Koeffizienten für die horizontale Operation oder aus Y bei der Berechnung der Koeffizienten für die vertikale Operation. Die Koordinate im expandierten Gitter entspricht K11 im Kern unten. Ein exemplarischer Eingabepixelkern kann wie folgt dargestellt werden:

K00 K10 K20 K30
K01 K11 K21 K31
K02 K12 K22 K32
K03 K13 K23 K33

Ein Beispiel für bikubischen Pseudocode kann wie folgt dargestellt werden: $\begin{matrix} H 0 = A * K 00 + \\ B * K 10 + \\ C * K 20 + \\ D * K 30; \end{matrix}$
$\begin{matrix} H 1 = A * K 01 + \\ B * K 11 + \\ C * K 21 + \\ D * K 31; \end{matrix}$
$\begin{matrix} H 2 = A * K 02 + \\ B * K 12 + \\ C * K 22 + \\ D * K 32; \end{matrix}$
$\begin{matrix} H 3 = A * K 03 + \\ B * K 13 + \\ C * K 23 + \\ D * K 33; \end{matrix}$
Und eine Beispielausgabe kann dargestellt werden als: $\begin{array}{l} A * H 0 + \\ B * H 1 + \\ C * H 2 + \\ D * H 3; \end{array}$
In einigen Beispielen kann ein bikubischer Modus aktiviert werden, indem ein Register (z. B. das Feld BICUBICMODE des Registers WARP_MODE) des Warp-Filters 1600 gesetzt wird. In einigen Beispielen werden die bilinearen Koeffizienten aus der 8-Bit-Nichtganzzahl-Eingabe generiert und können wie folgt berechnet werden: $A : (1 - t);$
$B : t,$
wobei ‚t‘ entweder aus X bei der Berechnung der Koeffizienten für die horizontale Operation oder aus Y bei der Berechnung der Koeffizienten für die vertikale Operation stammt. Die Koordinate im expandierten Gitter entspricht K11 im Kern unten.
Ein Beispiel für einen Eingabepixelkern:

K00 K10 K20 K30
K01 K11 K21 K31
K02 K12 K22 K32
K03 K13 K23 K33

H 1 = (A * K 11) + (B * K 21);

H 2 = (A * K 12) + (B * K 22);

Ausgabe = (A * H 1) + (B * H 2);

In einigen Beispielen wird der bilineare Modus aktiviert, indem das Feld BILINEAR_MODE im Register WARP_MODE des Warp-Filters 1600 gesetzt wird.
In einigen Beispielen erhält der Warp-Filter 1600 von 16 die folgende grundlegende Konfigurationsinformation: Rahmen-BASE-Adresse für 3 Speicherports, STRIDE für 3 Speicherports, Ringpuffer/Rahmenpuffer-Modus für 3 Speicherports, X,Y-Kachel-Startpunkt im Rahmen (z. B. (0,0) können für die meisten Anwendungen verwendet werden) und/oder eine Anzahl von zu verarbeitenden Kacheln (z. B. entweder alle im Bild oder eine Teilmenge ausgehend vom Rahmen-Startpunkt, oder auf 0 gesetzt, um einen ganzen Rahmen zu verarbeiten). Zusätzlich oder alternativ kann der Warp-Filter 1600 grundlegende Konfigurationsinformation wie X,Y-Dimensionen, Eingaberahmendimensionen (INFRAMELIMIT), Ausgaberahmendimensionen (TILE_START und OUTFRAMELIM) und/oder X-Granularität-Kehrwert und Y-Granularität-Kehrwert in U(0,20) erhalten. Die X- und Y-Granularität-Kehrwerte sind 1/Gx im Festkomma-(0,20)-Format und Granularität ist (Pixel aus / Pixel ein). In einigen Beispielen kann der Registerwert als (1/G * 2^20) berechnet werden. In einigen Beispielen kann es Einschränkungen für das Verhältnis zwischen G und Kachelbreite oder -höhe geben. Eine exemplarische Einschränkung kann sein, dass G größer oder gleich der (Kachel_Größe)/2 sein muss, wobei Kachel Größe Kachelbreite oder Kachelhöhe ist.
Zusätzlich oder alternativ kann der Warp-Filter 1600 eine grundlegende Konfiguration erhalten, die die Gitterausgabeposition in ganzzahligen und nichtganzzahligen Werten (z. B. (0,0, 0,0) kann man für die meisten Anwendungen verwenden), programmierbare Koeffizienten für den 3x3-Matrixbetrieb (9 x FP32) in der Gitter-Transformationseinrichtung 1610, eine Auswahl an bilinearem oder bikubischem Resampling, eine Auswahl an Kantenmodi (z. B, was passiert, wenn der Filterkern über Rand des Bildes hängt (z. B. durch ein Pad mit Kantenpixel auflösen oder konstante Farbe verwenden)), und/oder eine Farbe für den Kantenmodus bei Verwendung des konstanten Farbmodus.
Im veranschaulichten Beispiel von 16 beinhaltet der Warp-Filter 1600 die drei Schnittstellen 1602, 1604, 1606. So können beispielsweise die drei Schnittstellen 1602, 1604, 1606 AMC-Master-Schnittstellen sein. Die Gitter-Leseschnittstelle 1602 ist ein relativ bandbreitenschwacher Port und kann bis zu neun 64-Bit-(X,Y)-Gitterpunkte (im FP32,FP32-Format) pro Ausgabekachel abrufen. Die Bandbreite dieser exemplarischen Schnittstelle hängt von der Granularität und der eingestellten Kachelgröße ab. Die Granularität ist auf nicht weniger als die Kachelgröße beschränkt, um die Anzahl der Gitterabrufe auf vernünftige Werte zu beschränken. Für eine Granularität und Kachelgröße von 32x32 holt die Gitterpunkt-Abrufeinrichtung alle 1024 Zyklen 9 64-Bit-Wörter. Diese Gitterpunkte werden an zusammenhängenden Speicherplätzen gehalten. Dieser Speicherport liest auch vorgedehnte Gitterpunkte mit hoher Bandbreite aus dem Speichersystem.
Die Block-Cache-Speicherschnittstelle 1604 von 16 unterstützt Lesebursts von bis zu 8 Worten. In einigen Beispielen ist die Größe des Bursts durch die Anzahl der Blöcke begrenzt, die in einem einzigen SBR (Speculative Block Request)-Wort angefordert werden können (maximal 8). Die Pixel-Schreibschnittstelle 1606 erhält Pixel-Rückschreibungen, die alle ganze Wörter von 128 Bit sind, und in einigen Beispielen wird Byte-Maskierung nicht unterstützt. Die Pixel-Schreibschnittstelle 1606 von 16 unterstützt Schreibbursts von bis zu 16.
Flussdiagramme, die für exemplarische Hardwarelogik, maschinenlesbare Anweisungen, hardwareimplementierte Zustandsmaschinen und/oder deren Kombinationen zur Implementierung des PFBC 100 von 1 und/oder der Prefetch-Maschine 200 von 2 stehen, sind in den 24-27 dargestellt. Die maschinenlesbaren Anweisungen können ein ausführbares Programm oder ein Teil eines ausführbaren Programms zur Ausführung durch einen oder mehrere Computerprozessoren sein, wie beispielsweise den Prozessor 2812 von 28, der in der exemplarischen Prozessorplattform 2800 dargestellt ist, die nachstehend in Verbindung mit 28 und/oder den Prozessor 2912 von 29, der in der exemplarischen Prozessorplattform 2900 dargestellt ist, die nachstehend in Verbindung mit 29 erläutert wird. Das Programm kann in Software verkörpert sein, die auf einem nichttransitorischen computerlesbaren Speichermedium gespeichert ist, wie beispielsweise einer CD-ROM, einer Diskette, einer Festplatte, einer DVD, einer Blu-ray Disc oder einem Speicher, der den Prozessoren 2812, 2912 zugeordnet ist, aber das gesamte Programm und/oder Teile davon können alternativ von einer anderen Vorrichtung als den Prozessoren 2812, 2912 und/oder in Firmware oder spezieller Hardware ausgeführt werden. Obwohl das exemplarische Programm mit Bezug auf die in den 24-27 dargestellten Flussdiagramme beschrieben ist, können alternativ viele andere Methoden zur Implementierung des exemplarischen PFBC 100 und/oder der Prefetch-Maschine 200 verwendet werden. So kann beispielsweise die Ordnung der Ausführung der Blöcke geändert werden und/oder einige der beschriebenen Blöcke können geändert, eliminiert oder kombiniert werden. Zusätzlich oder alternativ können einzelne oder alle Blöcke durch eine oder mehrere Hardwareschaltungen (z. B. diskrete und/oder integrierte analoge und/oder digitale Schaltungen, ein FPGA, ein ASIC, ein Vergleicher, ein Operationsverstärker (Operationsverstärker), eine Logikschaltung usw.) implementiert werden, die so aufgebaut sind, dass sie den entsprechenden Vorgang ohne Ausführung von Software oder Firmware durchführen.
Wie vorstehend erwähnt, können die exemplarischen Prozesse der 24-27 unter Verwendung ausführbarer Anweisungen (z. B. computer- und/oder maschinenlesbare Anweisungen) implementiert werden, die auf einem nichtflüchtigen computer- und/oder maschinenlesbaren Medium gespeichert sind, wie z. B. einer Festplatte, einem Flash-Speicher, einem Nur-Lese-Speicher, einer Compact Disc, einer Digital Versatile Disc, einem Cache, einem Direktzugriffsspeicher und/oder jeder anderen Speichervorrichtung oder Speicherplatte, auf der Informationen für eine beliebige Dauer gespeichert sind (z. B. für längere Zeiträume, dauerhaft, für kurze Zeiträume, für die Zwischenspeicherung und/oder für das Zwischenspeichern der Information). Wie hierin verwendet, wird der Begriff nichtflüchtiges, computerlesbares Medium ausdrücklich definiert, um jede Art von computerlesbarer Speichervorrichtung und/oder Speicherplatte zu erfassen und Verbreitungssignale auszuschließen und Übertragungsmedien auszuschließen.
„Einschließlich“ und „umfassend“ (und alle Formen und Zeitformen davon) werden hierin als offene Begriffe verwendet. Wenn also ein Anspruch irgendeine Form von „beinhalten“ oder „umfassen“ (z. B. umfasst, beinhaltet, umfassend, enthaltend, aufweisend etc.) als Präambel oder innerhalb eines Anspruchsrezitation jeglicher Art verwendet, ist zu verstehen, dass zusätzliche Elemente, Begriffe usw. vorhanden sein können, ohne dass sie aus dem Anwendungsbereich des entsprechenden Anspruchs oder der entsprechenden Rezitation fallen. Wie hierin verwendet, wenn der Ausdruck „mindestens“ als Übergangsbegriff in z. B. einer Präambel eines Anspruchs verwendet wird, ist er offen und endet auf die gleiche Weise wie der Begriff „umfassend“ und „enthaltend“ offen sind. Der Begriff „und/oder“, wenn er beispielsweise in einer Form wie A, B und/oder C verwendet wird, bezieht sich auf jede Kombination oder Teilmenge von A, B, C wie (1) A allein, (2) B allein, (3) C allein, (4) A mit B, (5) A mit C, (6) B mit C und (7) A mit B und C.
24 ist ein Flussdiagramm, das exemplarisch für maschinenlesbare Anweisungen 2400 steht, die ausgeführt werden können, um den PFBC 100 von 1 und/oder die Prefetch-Maschine 200 von 2 zur Verarbeitung einer an einer Prefetch-Schnittstelle empfangenen Anforderung zu implementieren. So können beispielsweise die maschinenlesbaren Anweisungen 2400 die Prefetch-Schnittstelle 104 von 1 und/oder die Prefetch-Kern-Abrufeinrichtung 202 von 2 implementieren, der eine Anforderung von einem Hardwarebeschleuniger (z. B. dem Hardwarebeschleuniger 114 von 1) erhält, um Pixelkoordinaten zu verarbeiten, die einem Pixel eines Eingabebildes zugeordnet sind.
Die exemplarischen maschinenlesbaren Anweisungen 2400 von 24 beginnen bei Block 2402, bei dem der PFBC 100 bestimmt, ob eine Anforderung (z. B. eine Anforderung des Hardwarebeschleunigers 114) an einer Prefetch-Schnittstelle angenommen wurde. So kann beispielsweise die Prefetch-Schnittstelle 104 von 1 bestimmen, ob eine Anforderung mit Pixelkoordinaten vom Hardwarebeschleuniger 114 akzeptiert wurde. Wenn nicht, wartet der PFBC 100 weiterhin auf ein solches Ereignis. Als Reaktion darauf, dass der PFBC 100 eine Anforderungsannahme erkennt, erhält der PFBC 100 dann bei Block 2404 Pixelkoordinaten an der Prefetch-Schnittstelle. So kann beispielsweise die Prefetch-Schnittstelle 104 Pixelkoordinaten eines in einem Eingabebild enthaltenen Pixel empfangen. Zusätzlich oder alternativ kann der Hardwarebeschleuniger 114 horizontale Stütz-, vertikale Stütz- und/oder Morton-Ordnung-Information beinhalten, die den Pixelkoordinaten in der Anforderung zugeordnet ist, die von der Prefetch-Schnittstelle 104 empfangen wird.
Bei Block 2406 erzeugt der PFBC 100 ein Tag basierend auf den Pixelkoordinaten. So kann beispielsweise die Tag-Abbildungseinrichtung 124 ein Tag mit einem Block-Tag basierend auf den Pixelkoordinaten erzeugen, die von der Prefetch-Schnittstelle 104 empfangen werden. Als Reaktion auf das Erzeugen des Tags durchsucht der PFBC 100 den Tag-Speicher basierend auf dem Tag bei Block 2408. So kann beispielsweise die Tag-Abbildungseinrichtung 124 jeden der Tag-Datenspeicher 128, die im Tag-Speicher 122 von 1 enthalten sind, parallel durchsuchen, um festzustellen, ob das erzeugte Block-Tag bereits im Tag-Speicher 122 gespeichert ist.
Bei Block 2410 bestimmt der PFBC 100, ob sich das Tag im Tag-Speicher befindet. So kann beispielsweise die Tag-Abbildungseinrichtung 124 bestimmen, dass sich das Block-Tag nicht in einem der Tags 120 befindet, was darauf hindeutet, dass sich die den Pixelkoordinaten zugeordneten Bildblockdaten nicht im Cache-Speicher 146 von 1 befinden. So kann beispielsweise die Tag-Abbildungseinrichtung 124 bestimmen, dass ein den Pixelkoordinaten zugeordneter Bildblock nicht im Cache-Speicher 146 gespeichert wurde, und weist die SBR-Erstellungseinrichtung 126 von 1 als Reaktion auf mindestens die Bestimmung an, einen oder mehrere SBRs zu erzeugen, um den Bildblock aus dem Hauptspeicher 110 von 1 abzurufen. In anderen Beispielen kann die Tag-Abbildungseinrichtung 124 bestimmen, dass das Block-Tag bereits in einem der Tags 120 gespeichert ist, was anzeigt, dass die den Pixelkoordinaten zugeordneten Bildblockdaten bereits im Cache-Speicher 146 zwischengespeichert wurden.
Wenn der PFBC 100 bei Block 2410 bestimmt, dass sich das Tag nicht im Tag-Speicher befindet, dann speichert der PFBC 100 bei Block 2412 das Tag im Tag-Speicher. Ein exemplarischer Prozess, der zur Implementierung von Block 2412 verwendet werden kann, wird im Folgenden in Verbindung mit 26 beschrieben. Als Reaktion auf das Speichern des Tags im Tag-Speicher ruft der PFBC 100 fehlende Blöcke aus dem Speicher bei Block 2416 ab. So kann beispielsweise die Block-Abrufeinrichtung 138 von 1 die Bilddatenblöcke, die den Pixelkoordinaten zugeordnet sind, die nicht bereits im Cache-Speicher 146 gespeichert sind, aus dem Hauptspeicher 110 von 1 abrufen.
Wenn der PFBC 100 bei Block 2410 bestimmt, dass sich das Tag im Tag-Speicher befindet, dann bestimmt der PFBC 100 bei Block 2414, ob alle mit den Pixelkoordinaten verbundenen Blöcke im Cache gespeichert sind. So kann beispielsweise die Tag-Abbildungseinrichtung 124 bestimmen, dass alle Bilddatenblöcke, die zum Aufbau des den Pixelkoordinaten zugeordneten Pixelkerns erforderlich sind, im Cache-Speicher 146 gespeichert werden. In anderen Beispielen kann die Tag-Abbildungseinrichtung 124 bestimmen, dass nicht alle Bilddatenblöcke, die zum Aufbau des den Pixelkoordinaten zugeordneten Pixelkerns erforderlich sind, im Cache-Speicher 146 gespeichert sind.
Wenn der PFBC 100 bei Block 2414 bestimmt, dass alle den Pixelkoordinaten zugeordneten Blöcke im Cache gespeichert sind, fährt die Steuerung mit Block 2420 fort, um auf die den Pixelkoordinaten zugeordneten Blöcke im Cache zuzugreifen. Wenn der PFBC 100 bei Block 2414 bestimmt, dass nicht alle den Pixelkoordinaten zugeordneten Blöcke im Cache gespeichert sind, ruft der PFBC 100 bei Block 2416 die fehlenden Blöcke aus dem Speicher ab. So kann beispielsweise die Block-Abrufeinrichtung 138 einen oder mehrere Bilddatenblöcke, die den Pixelkoordinaten zugeordnet sind, aus dem Hauptspeicher 110 abrufen. In solchen Beispielen kann die Block-Abrufeinrichtung 138 den einen oder die mehreren abgerufenen Bilddatenblöcke in einem oder mehreren der Cache-Datenspeicher 148 speichern, die im Cache-Speicher 146 von 1 enthalten sind.
Als Reaktion auf das Abrufen der fehlenden Blöcke aus dem Speicher aktualisiert der PFBC 100 das Tag im Tag-Speicher bei Block 2418. So kann beispielsweise die Block-Abrufeinrichtung 138 den entsprechenden Eintrag 130 mit dem Tag 120 mit einem Speicherort der abgerufenen Bilddatenblöcke aktualisieren.
Als Reaktion auf das Aktualisieren des Tags im Tag-Speicher greift der PFBC 100 auf die den Pixelkoordinaten zugeordneten Blöcke im Cache zu. So kann beispielsweise die Anforderungsschnittstelle 106 eine Anforderung für die Pixelkoordinaten empfangen, die an der Prefetch-Schnittstelle 104 empfangen werden. Der Lese-Tag-Abbildungseinrichtung 152 kann ein Block-Tag basierend auf den Pixelkoordinaten erzeugen und bestimmen, dass die den Pixelkoordinaten zugeordneten Bilddatenblöcke im Cache-Speicher 146 basierend auf dem Block-Tag gespeichert werden, der einem Block-Tag in einem der im Tag-Speicher 122 gespeicherten Tags 120 entspricht. Als Reaktion auf mindestens die Bestimmung kann der Lese-Tag-Abbildungseinrichtung 152 die Cache-Zugriffeinrichtung 154 anweisen, die Bilddatenblöcke aus dem Cache-Speicher 146 abzurufen und die Bilddatenblöcke zur weiteren Verarbeitung auf die Datenschnittstelle 108 von 1 auszugeben. So ist beispielsweise die Cache-Zugriffeinrichtung 154, die die Bilddatenblöcke aus dem Cache-Speicher 146 abruft, im Vergleich zum Abrufen von Bilddatenzeilen aus dem Hauptspeicher 110 ein wesentlich schnellerer und effizienterer Vorgang, da weniger Lese-Operationen durchgeführt werden.
Als Reaktion auf den Zugriff auf die den Pixelkoordinaten zugeordneten Blöcke im Cache aktualisiert der PFBC 100 das Tag im Tag-Speicher bei Block 2422. So kann beispielsweise der Lese-Tag-Abbildungseinrichtung 152 das Zählfeld 134 des entsprechenden Eintrags 130 dekrementieren, was anzeigt, dass die dem Eintrag 130 zugeordneten Bildblockdaten aus dem Cache-Speicher 146 abgerufen wurden.
Bei Block 2424 bestimmt der PFBC 100, ob die Überwachung auf Anforderungen fortgesetzt werden soll. Wenn der PFBC 100 bestimmt, die Überwachung auf Anforderungen fortzusetzen, kehrt die Steuerung zu Block 2402 zurück, um zu bestimmen, ob eine Anforderung empfangen wurde, andernfalls schließen die maschinenlesbaren Anweisungen 2400 von 24 ab.
25 ist ein Flussdiagramm, das für exemplarische maschinenlesbare Anweisungen 2412 steht, die ausgeführt werden können, um den PFBC 100 von 1 und/oder die Prefetch-Maschine 200 von 2 zu implementieren, um ein Tag im Tag-Speicher zu speichern. Die maschinenlesbaren Anweisungen 2412 von 25 beginnen bei Block 2502, bei dem der PFBC 100 einen Eintrag von Interesse im Tag-Speicher zur Verarbeitung auswählt. So kann beispielsweise die Tag-Abbildungseinrichtung 124 einen ersten der Einträge 130 in einem ersten der Tag-Datenspeicher 128 des Tag-Speichers 122 zur Verarbeitung auswählen.
Bei Block 2504 wählt der PFBC 100 einen Weg von Interesse in dem Tag-Speicher zur Verarbeitung aus. So kann beispielsweise die Tag-Abbildungseinrichtung 124 einen ersten der in dem ersten der Einträge 130 zur Verarbeitung enthaltenen Wege auswählen.
Bei Block 2506 bestimmt der PFBC 100, ob das Zählfeld null ist. So kann beispielsweise die Tag-Abbildungseinrichtung 124 bestimmen, ob das Zählfeld 134, das in dem gewählten Weg enthalten ist, null ist. In solchen Beispielen kann die Tag-Abbildungseinrichtung 124 bestimmen, dass ein dem ausgewählten Weg zugehöriger Bildblock spekulativ geholt wurde, wenn das Zählfeld 134 null ist, und kann bestimmen, dass der Bildblock einer Anforderung zugeordnet ist, die von der Prefetch-Schnittstelle 104 empfangen wurde (z. B. eine zuvor empfangene Anforderung von der Prefetch-Schnittstelle 104), wenn das Zählfeld 134 ungleich null ist.
Wenn der PFBC 100 bei Block 2506 bestimmt, dass das Zählfeld ungleich null ist, fährt die Steuerung mit Block 2514 fort, um zu bestimmen, ob sie eine anderen Weg von Interesse im Tag-Speicher zur Verarbeitung wählen soll. Wenn der PFBC 100 bei Block 2506 bestimmt, dass das Zählfeld null ist, dann bestimmt der PFBC 100 bei Block 2508, ob das Pending-Feld null ist. So kann beispielsweise die Tag-Abbildungseinrichtung 124 bestimmen, ob das Pending-Feld 135 von 1, das in dem gewählten Weg enthalten ist, null ist. In solchen Beispielen kann die Tag-Abbildungseinrichtung 124 bestimmen, dass ein dem ausgewählten Weg zugehöriger Bildblock spekulativ geholt wurde, aber gerade geholt wird und nicht ersetzt oder überschrieben werden kann, wenn das Zählfeld 134 null und das Pending-Feld 135 eins ist und/oder anderweitig aktiviert ist. So kann beispielsweise der PFBC 100 einen spekulativ geholten Bildblock vor der Speicherung im Cache 146 nicht ersetzen. In anderen Beispielen kann die Tag-Abbildungseinrichtung 124 bestimmen, dass der dem ausgewählten Weg zugeordnete Bildblock spekulativ geholt wurde und ersetzt werden kann, wenn das Zählfeld 134 null und das Pending-Feld 135 null ist, da der Bildblock nicht abgerufen werden kann.
Wenn der PFBC 100 bei Block 2508 bestimmt, dass das Pending-Feld nicht null ist, fährt die Steuerung mit Block 2514 fort, um zu bestimmen, ob sie einen anderen Weg von Interesse im Tag-Speicher zur Verarbeitung auswählen soll. Wenn der PFBC 100 bei Block 2508 bestimmt, dass das Pending-Feld null ist, identifiziert der PFBC 100 bei Block 2510 einen Block, der dem ausgewählten Weg zugeordnet ist, als spekulativen Block. So kann beispielsweise die Tag-Abbildungseinrichtung 124 bestimmen, dass ein Bilddatenblock, der dem ersten der Wege des ersten der Einträge 130 zugeordnet ist, ein spekulativ geholter Block ist und zuvor nicht zur Speicherung im Cache-Speicher 146 angefordert wurde.
Als Reaktion darauf, dass der dem ausgewählten Weg zugeordnete Block als spekulativer Block identifiziert wird, ersetzt der PFBC 100 bei Block 2512 ein Tag im ausgewählten Weg durch das erzeugte Tag. So kann beispielsweise die Tag-Abbildungseinrichtung 124 ein Block-Tag speichern, das basierend auf Pixelkoordinaten erzeugt wird, die von der Prefetch-Schnittstelle 104 empfangen werden, im Block-Tag-Feld des Tags 120 beim gewählten Weg. In solchen Beispielen kann die Tag-Abbildungseinrichtung 124 das vorhandene Tag 120 überschreiben und/oder anderweitig durch das erzeugte Tag basierend auf den empfangenen Pixelkoordinaten ersetzen.
Bei Block 2514 bestimmt der PFBC 100, ob er einen anderen Weg von Interesse in dem Tag-Speicher zur Verarbeitung wählen soll. Wenn der PFBC 100 bei Block 2514 bestimmt, einen anderen Weg von Interesse in dem Tag-Speicher zur Verarbeitung auszuwählen, kehrt die Steuerung zu Block 2504 zurück, um einen anderen Weg von Interesse in dem Tag-Speicher zur Verarbeitung auszuwählen. Wenn der PFBC 100 bei Block 2514 bestimmt, dass er keinen anderen Weg von Interesse in dem Tag-Speicher zur Verarbeitung auswählt, dann bestimmt der PFBC 100 bei Block 2516, ob er einen anderen Eintrag von Interesse in dem Tag-Speicher zur Verarbeitung auswählen soll. Wenn der PFBC 100 bei Block 2514 bestimmt, keinen weiteren Eintrag von Interesse in dem Tag-Speicher zur Verarbeitung auszuwählen, kehrt die Steuerung zu Block 2502 zurück, um einen anderen Eintrag von Interesse in dem Tag-Speicher zur Verarbeitung auszuwählen. Als Reaktion darauf, dass kein weiterer Eintrag von Interesse in dem Tag-Speicher zur Verarbeitung ausgewählt wurde, kehren die maschinenlesbaren Anweisungen 2412 von 25 zu Block 2416 der maschinenlesbaren Anweisungen 2400 von 24 zurück, um die fehlenden Blöcke aus dem Speicher zu holen.
26 ist ein Flussdiagramm, das für exemplarische maschinenlesbare Anweisungen 2600 steht, die ausgeführt werden können, um den PFBC 100 von 1 und/oder die Prefetch-Maschine 200 von 2 zur Verarbeitung einer an einer Anforderungsschnittstelle empfangenen Anforderung zu implementieren. Die maschinenlesbaren Anweisungen 2600 von 26 beginnen bei Block 2602, bei dem der PFBC 100 bestimmt, ob eine Anforderung an einer Anforderungsschnittstelle angenommen wurde. So kann beispielsweise die Anforderungsschnittstelle 106 von 1 bestimmen, ob eine Anforderung angenommen wurde. Wenn nicht, wartet der PFBC 100 weiterhin auf ein solches Ereignis. Als Reaktion darauf, dass der PFBC 100 eine Anforderungsannahme an der Anforderungsschnittstelle 106 erkennt, erhält der PFBC 100 dann bei Block 2604 Pixelkoordinaten an der Anforderungsschnittstelle 106. So kann beispielsweise die Anforderungsschnittstelle 106 Pixelkoordinaten eines in einem Eingabebild enthaltenen Pixels empfangen.
Bei Block 2606 erzeugt der PFBC 100 ein Tag basierend auf den Pixelkoordinaten. So kann beispielsweise der Lese-Tag-Abbildungseinrichtung 152 ein Tag mit einem Block-Tag basierend auf den von der Anforderungsschnittstelle 106 empfangenen Pixelkoordinaten erzeugen. Als Reaktion auf das Erzeugen des Tags durchsucht der PFBC 100 den Tag-Speicher basierend auf dem Tag bei Block 2608. So kann beispielsweise der Lese-Tag-Abbildungseinrichtung 152 jeden der Tag-Datenspeicher 128, die im Tag-Speicher 122 von 1 enthalten sind, parallel durchsuchen, um zu bestimmen, ob die den Pixelkoordinaten zugeordneten Bildblockdaten im Cache-Speicher 146 gespeichert sind.
Bei Block 2610 bestimmt der PFBC 100, ob sich das Tag im Tag-Speicher befindet. So kann beispielsweise die Lese-Tag-Abbildungseinrichtung 152 bestimmen, dass sich das Block-Tag nicht in einem der Tags 120 befindet, was darauf hindeutet, dass sich die den Pixelkoordinaten zugeordneten Bildblockdaten nicht im Cache-Speicher 146 von 1 befinden. In anderen Beispielen kann die Lese-Tag-Abbildungseinrichtung 152 bestimmen, dass das Block-Tag bereits in einem der Tags 120 gespeichert ist, was anzeigt, dass die den Pixelkoordinaten zugeordneten Bildblockdaten bereits im Cache-Speicher 146 zwischengespeichert wurden. In solchen Beispielen kann die Cache-Zugriffeinrichtung 154 leicht einen oder mehrere Bildblöcke aus dem Cache 146 abrufen, die den gewünschten Pixelkoordinaten zugeordnet sind. So kann beispielsweise die Cache-Zugriffeinrichtung 154 eine Leistungssteigerung beim Abrufen der einen oder mehreren Bildblöcke im Vergleich zum Abrufen einer oder mehrerer Zeilen von Bilddaten aus dem Hauptspeicher 110 erreichen, indem er eine Anzahl von Lese-Operationen reduziert, die mit den Bilddaten verbunden sind, um die angeforderten Pixelkoordinaten zu verarbeiten.
Wenn der PFBC 100 bei Block 2610 bestimmt, dass sich das Tag nicht im Tag-Speicher befindet, fährt die Steuerung mit Block 2618 fort, um die Überwachung auf Anforderungen fortzusetzen. So kann beispielsweise die Lese-Tag-Abbildungseinrichtung 152 warten, bis die den empfangenen Pixelkoordinaten zugeordneten Bildblockdaten im Cache-Speicher 146 gespeichert sind. In solchen Beispielen wartet die Lese-Tag-Abbildungseinrichtung 152, bis die Bildblockdaten gespeichert sind, um eine Leistungssteigerung gegenüber früheren Implementierungen zu erreichen, bei denen eine erhöhte Anzahl von Lese-Operationen auf dem Hauptspeicher 110 durchgeführt wird, um eine Vielzahl von Zeilen von Bilddaten im Vergleich zum Abrufen von Bilddatenblöcken abzurufen.
Wenn der PFBC 100 bei Block 2610 bestimmt, dass sich das Tag im Tag-Speicher befindet, dann bestimmt der PFBC 100 bei Block 2612, ob alle mit den Pixelkoordinaten verbundenen Blöcke im Cache gespeichert sind. So kann beispielsweise der Lese-Tag-Abbildungseinrichtung 152 bestimmen, dass alle Bilddatenblöcke, die zum Aufbau des den Pixelkoordinaten zugeordneten Pixelkerns erforderlich sind, im Cache-Speicher 146 gespeichert sind. In anderen Beispielen kann die Lese-Tag-Abbildungseinrichtung 152 bestimmen, dass nicht alle Bilddatenblöcke, die zum Aufbau des den Pixelkoordinaten zugeordneten Pixelkerns erforderlich sind, im Cache-Speicher 146 gespeichert sind.
Wenn der PFBC 100 bei Block 2612 bestimmt, dass nicht alle den Pixelkoordinaten zugeordneten Bildblöcke im Cache gespeichert sind, wartet der PFBC 100 weiterhin darauf, dass die Bildblöcke im Cache gespeichert werden.
Wenn der PFBC 100 bei Block 2612 bestimmt, dass alle den Pixelkoordinaten zugeordneten Blöcke im Cache gespeichert werden, greift der PFBC 100 bei Block 2614 auf die den Pixelkoordinaten zugeordneten Bildblöcke im Cache zu. So kann beispielsweise die Cache-Zugriffeinrichtung 154 die Bilddatenblöcke aus den im Cache-Speicher 146 enthaltenen Cache-Datenspeichern 148 abrufen und die Bilddatenblöcke an die Datenschnittstelle 108 ausgeben.
Als Reaktion auf den Zugriff auf die Bildblöcke im Cache aktualisiert der PFBC 100 das Tag im Tag-Speicher bei Block 2616. So kann beispielsweise die Lese-Tag-Abbildungseinrichtung 152 das Zählfeld 134 auf dem entsprechenden Weg des entsprechenden Eintrags 130 dekrementieren.
Bei Block 2618 bestimmt der PFBC 100, ob die Überwachung auf Anforderungen fortgesetzt werden soll. Wenn der PFBC 100 bestimmt, die Überwachung auf Anforderungen fortzusetzen, kehrt die Steuerung zu Block 2602 zurück, um festzustellen, ob eine Anforderung empfangen wurde, andernfalls schließen die maschinenlesbaren Anweisungen 2600 von 26 ab.
27 ist ein Flussdiagramm, das exemplarische maschinenlesbare Anweisungen 2700 darstellt, die vom PFBC 100 von 1 und/oder der Prefetch-Maschine 200 von 2 ausgeführt werden können, um exemplarische spekulative Blockanforderungen zu bilden. Die maschinenlesbaren Anweisungen 2700 beginnen bei Block 2702, bei dem der PFBC 100 einen Bildblock (X+N, Y) im Tag-Speicher nachschlägt, wobei X und Y Pixelkoordinaten sind und N das Blockmengenfeld 1504 von 15 ist, das eine Menge von Bildblöcken auf der linken oder rechten Seite eines Bildblocks einschließlich der zu holenden X- und Y-Pixelkoordinaten darstellt. So kann beispielsweise die Tag-Abbildungseinrichtung 124 bestimmen, dass ein Bilddatenblock im Cache-Speicher 146 von 1 gespeichert ist, basierend auf der Abbildung der Pixelkoordinaten auf eines der im Tag-Speicher 122 enthaltenen Tags 120.
Bei Block 2704 bestimmt der PFBC 100, ob ein Bildblock ansteht. So entspricht beispielsweise ein ausstehender Bildblock einem Bildblock, der aus dem Hauptspeicher 110 abgerufen und im Cache 146 gespeichert ist. Als Reaktion auf das Bestimmen, dass ein Bildblock ansteht, initialisiert der PFBC 100 einen Abrufvorgang des Bildblocks aus dem Hauptspeicher 110. Als Reaktion auf das Bestimmen, dass der Bildblock nicht ansteht, initialisiert der PFBC 100 den Aufbau einer oder mehrerer SBRs, um den Abrufvorgang zu initialisieren. So kann beispielsweise die Tag-Abbildungseinrichtung 124 von 1 die Pixelkoordinaten auf eines der Tags 120 abbilden. Die Tag-Abbildungseinrichtung 124 kann bestimmen, dass ein entsprechendes Pending-Feld aktiviert ist, was anzeigt, dass ein den Pixelkoordinaten zugeordneter Bilddatenblock aus dem Hauptspeicher 110 von 1 abgerufen wird.
Wenn der PFBC 100 bei Block 2704 bestimmt, dass der Bildblock ausstehend ist, plant der PFBC 100 eine Anforderung für N Bildblöcke aus dem Block (X, Y) bei Block 2706. So kann beispielsweise die SBR-Erstellungseinrichtung 126 eine oder mehrere SBRs erzeugen und die Block-Abrufeinrichtung 138 anweisen, N Bilddatenblöcke links oder rechts vom Bilddatenblock einschließlich der X- und Y-Koordinaten aus dem Hauptspeicher 110 abzurufen. Als Reaktion auf die Planung der Anforderung schließen die maschinenlesbaren Anweisungen 2700 ab. So hat beispielsweise der PFBC 100 angeforderte Pixelkoordinaten empfangen, die Pixelkoordinaten auf einen oder mehrere Bildblöcke im Hauptspeicher 110 abgebildet und einen Abruf der einen oder mehreren Bildblöcke aus dem Hauptspeicher 110 initiiert und die einen oder mehreren Bildblöcke im Cache 146 zur beschleunigten Verarbeitung durch den Hardwarebeschleuniger 114 und/oder andere hardware- oder maschinenlesbare Anweisungen speichert. So kann beispielsweise der Hardwarebeschleuniger 114 einen oder mehrere Bildblöcke im Vergleich zu einer oder mehreren Zeilen von Bilddaten verarbeiten.
Wenn der PFBC 100 bei Block 2704 bestimmt, dass der Block nicht ausstehend ist (z. B. ist ein Wert eines Pending-Feldes null und/oder anderweitig deaktiviert), fährt die Steuerung mit Block 2708 fort, um zu bestimmen, ob der mit dem in Block 2702 identifizierten Tag 120 verbundene Weg frei ist. So entspricht beispielsweise ein freier Weg einem oder mehreren Indizes eines entsprechenden der Cache-Datenspeicher 148 von 1, der für die Speicherung von Bildblocks zur Verfügung steht oder Bildblöcke enthält, die durch neue Bildblöcke ersetzt werden können. So kann beispielsweise die Tag-Abbildungseinrichtung 124 bestimmen, dass der Weg nicht frei ist, basierend auf einem Wert ungleich null des Zählfeldes 134.
Wenn der PFBC 100 bei Block 2708 bestimmt, dass der Weg nicht frei ist, dann bestimmt der PFBC 100 bei Block 2710, ob N auf null gesetzt werden soll. So kann beispielsweise die SBR-Erstellungseinrichtung 126 N auf null setzen, um anzuzeigen, dass keine Blöcke links oder rechts von den X- und Y-Koordinaten geholt werden sollen (z. B. dürfen keine Bilddatenblöcke spekulativ geholt werden).
Wenn der PFBC 100 bei Block 2710 bestimmt, N auf null zu setzen, fährt die Steuerung mit Block 2706 fort, um eine Anforderung für 0 Blöcke zu planen, wodurch die maschinenlesbaren Anweisungen 2700 abgeschlossen werden. Wenn der PFBC 100 bei Block 2710 beschließt, N nicht auf null zu setzen, kehrt die Steuerung zu Block 2708 zurück, um festzustellen, ob der Weg frei ist. So kann beispielsweise die SBR-Erstellungseinrichtung 126 so lange blockieren, bis der gewünschte Slot verfügbar ist. So kann beispielsweise die SBR-Erstellungseinrichtung 126 die Verarbeitung einer Anforderung für einen ersten Bilddatenblock blockieren, bis die Tag-Abbildungseinrichtung 124 den entsprechenden Weg im Tag-Speicher 122 bereitstellt.
Wenn der PFBC 100 bei Block 2708 bestimmt, dass der Weg frei ist, fährt die Steuerung mit Block 2712 fort, um N zu erhöhen. So kann beispielsweise die SBR-Erstellungseinrichtung 126 bestimmen, dass sie spekulativ einen Bilddatenblock holt, der den Pixelkoordinaten zugeordnet ist, um einen freien der Wege zu füllen. Als Reaktion auf das Inkrementieren von N bestimmt der PFBC 100, ob N=M bei Block 2714. So kann beispielsweise N zunächst null und M ein programmierbarer Wert in einem Bereich von 1 bis 8 sein. Wenn der PFBC 100 bei Block 2714 bestimmt, dass die Anzahl der Blöcke, die spekulativ geholt werden sollen (N), ungleich einer spekulativen Abrufschwelle (M) ist, fährt die Steuerung mit Block 2702 fort, um den Block (X+N, Y) im Tag-Speicher nachzuschlagen. Wenn der PFBC 100 bei Block 2714 bestimmt, dass die Anzahl der Blöcke, die spekulativ geholt werden sollen (N), gleich einer spekulativen Abrufschwelle (M) ist, fährt die Steuerung mit Block 2706 fort, um die Anforderung zu planen, spekulativ N Blöcke links oder rechts von dem den Pixelkoordinaten zugeordneten Bilddatenblock abzurufen. Alternativ kann die Anforderung auch das spekulative Abrufen von N Blöcken über oder unter dem den Pixelkoordinaten zugeordneten Bilddatenblock beinhalten.
28 ist ein Blockdiagramm einer exemplarischen Prozessorplattform 2800, die so aufgebaut ist, dass sie die Anweisungen der 24-27 zur Implementierung des PFBC 100 von 1 ausführt. Die Prozessorplattform 2800 kann beispielsweise ein Server, ein Personalcomputer, eine Workstation, eine selbstlernende Maschine (z. B. ein neuronales Netzwerk), eine mobile Vorrichtung (z. B. ein Mobiltelefon, ein Smartphone, ein Tablet wie ein iPad™), ein Personal Digital Assistant (PDA), ein Internetgerät, ein DVD-Player, ein CD-Player, ein digitaler Videorecorder, ein Blu-ray-Player, eine Spielkonsole, ein Personal Video Recorder, eine Set-Top-Box, ein Headset oder eine andere tragbare Vorrichtung oder eine andere Art von Computergerät sein.
Die Prozessorplattform 2800 des veranschaulichten Beispiels beinhaltet einen Prozessor 2812. Der Prozessor 2812 des veranschaulichten Beispiels ist Hardware. So kann beispielsweise der Prozessor 2812 durch eine oder mehrere integrierte Schaltungen, Logikschaltungen, Mikroprozessoren, GPUs, DSPs oder Controller einer beliebigen Familie oder eines beliebigen Herstellers implementiert werden. Der Hardware-Prozessor kann eine halbleiterbasierte (z.B. siliziumbasierte) Vorrichtung sein. In diesem Beispiel implementiert der Prozessor 2812 die exemplarische Prefetch-Einrichtung 112, den exemplarischen Pixeldaten-FIFO-Puffer 116, die exemplarische Tag-Abbildungseinrichtung 124, die exemplarische SBR-Erstellungseinrichtung 126, den exemplarischen SBR-FIFO 136, die exemplarische Block-Abrufeinrichtung 138, den exemplarischen Adressgenerator 142, die exemplarische Cache-Fülleinrichtung 144, die exemplarische Blockdaten-Leseeinrichtung 150, die exemplarische Lese-Tag-Abbildungseinrichtung 152 und die exemplarische Cache-Zugriffeinrichtung 154.
Der Prozessor 2812 des veranschaulichten Beispiels beinhaltet einen lokalen Speicher 2813 (z. B. einen Cache). Der Prozessor 2812 des veranschaulichten Beispiels steht in Verbindung mit einem Hauptspeicher mit einem flüchtigen Speicher 2814 und einem nichtflüchtigen Speicher 2816 über einen Bus 2818. Der flüchtige Speicher 2814 kann durch Synchronous Dynamic Random Access Memory (SDRAM), Dynamic Random Access Memory (DRAM), RAMBUS® Dynamic Random Access Memory (RDRAM®) und/oder jede andere Art von Direktzugriffsspeichervorrichtung implementiert werden. Der nichtflüchtige Speicher 2816 kann durch Flash-Speicher und/oder jede andere gewünschte Art von Speichervorrichtung implementiert werden. Der Zugriff auf den Hauptspeicher 2814, 2816 wird durch einen Speichercontroller gesteuert. In diesem Beispiel implementiert der flüchtige Speicher 2814 den exemplarischen Tag-Speicher 122 und den exemplarischen Cache-Speicher 146. Alternativ kann der nichtflüchtige Speicher 2816 den exemplarischen Tag-Speicher 122 und/oder den exemplarischen Cache-Speicher 146 implementieren.
Die Prozessorplattform 2800 des veranschaulichten Beispiels beinhaltet auch eine Schnittstellenschaltung 2820. Die Schnittstellenschaltung 2820 kann durch jede Art von Schnittstellenstandard implementiert werden, wie beispielsweise eine Ethernet-Schnittstelle, einen universellen seriellen Bus (USB), eine Bluetooth®-Schnittstelle, eine Nahfeldkommunikationsschnittstelle (NFC) und/oder eine PCI-Express-Schnittstelle.
Im dargestellten Beispiel sind eine oder mehrere Eingabevorrichtungen 2822 an die Schnittstellenschaltung 2820 angeschlossen. Die Eingabevorrichtung(en) 2822 erlauben es einem Benutzer, Daten und/oder Befehle in den Prozessor 2812 einzugeben. Die Eingabevorrichtung(en) 2822 können beispielsweise durch einen Audiosensor, ein Mikrofon, eine Kamera (Standbild oder Video), eine Tastatur, eine Taste, eine Maus, einen Touchscreen, ein Track-Pad, einen Trackball, eine Isopunktvorrichtung und/oder ein Spracherkennungssystem implementiert werden.
Eine oder mehrere Ausgabevorrichtungen 2824 sind ebenfalls an die Schnittstellenschaltung 2820 des dargestellten Beispiels angeschlossen. Die Ausgabevorrichtungen 2824 können beispielsweise durch Anzeigevorrichtungen (z. B. eine Leuchtdiode (LED), eine organische Leuchtdiode (OLED), eine Flüssigkristallanzeige (LCD), eine Kathodenstrahlröhrenanzeige (CRT), eine In-Place-Switching (IPS)-Anzeige, einen Touchscreen usw.), eine taktile Ausgabevorrichtung, einen Drucker und/oder Lautsprecher realisiert werden. Die Schnittstellenschaltung 2820 des veranschaulichten Beispiels beinhaltet somit typischerweise eine Grafiktreiberkarte, einen Grafiktreiberchip und/oder einen Grafiktreiberprozessor.
Die Schnittstellenschaltung 2820 des veranschaulichten Beispiels beinhaltet auch eine Kommunikationsvorrichtung wie einen Sender, einen Empfänger, einen Sender-Empfänger, ein Modem, ein Kabelmodem, einen drahtlosen Zugangspunkt und/oder eine Netzwerkschnittstelle, um den Datenaustausch mit externen Maschinen (z. B. Rechenvorrichtungen jeglicher Art) über ein Netzwerk 2826 zu erleichtern. Die Kommunikation kann beispielsweise über eine Ethernet-Verbindung, eine digitale Teilnehmeranschlussleitung (DSL), eine Telefonleitungsverbindung, ein Koaxialkabelsystem, ein Satellitensystem, ein drahtloses Standortsystem, ein Mobilfunksystem usw. erfolgen. In diesem Beispiel implementiert die Schnittstellenschaltung 1020 die exemplarische Speicherschnittstelle 102, die exemplarische Prefetch-Schnittstelle 104, die exemplarische Anforderungsschnittstelle 106, die exemplarische Datenschnittstelle 108 und die exemplarische Block-Abrufeinrichtungsschnittstelle 140.
Die Prozessorplattform 2800 des veranschaulichten Beispiels beinhaltet auch ein oder mehrere Massenspeichergeräte 2828 zum Speichern von Software und/oder Daten. Beispiele für solche Massenspeichergeräte 2828 sind Diskettenlaufwerke, Festplatten, Compact-Disc-Laufwerke, Blu-ray-Laufwerke, redundante Anordnung von unabhängigen Festplatten (RAID-Systeme) und Digital Versatile Disc (DVD)-Laufwerke.
Die maschinenausführbaren Anweisungen 2832 der 24-27 können in der Massenspeichervorrichtung 2828, im flüchtigen Speicher 2814, im nichtflüchtigen Speicher 2816 und/oder auf einem entfernbaren, nichtflüchtigen, computerlesbaren Speichermedium wie einer CD oder DVD gespeichert werden.
29 ist ein Blockdiagramm einer exemplarischen Prozessorplattform 2900, die aufgebaut ist, um die Anweisungen der 24-27 auszuführen, um die exemplarische Prefetch-Maschine 200 von 2 zu implementieren. Die Prozessorplattform 2900 kann beispielsweise ein Server, ein Personalcomputer, eine Workstation, eine selbstlernende Maschine (z. B. ein neuronales Netzwerk), eine mobile Vorrichtung (z. B. ein Mobiltelefon, ein Smartphone, ein Tablet wie ein iPad™), ein Personal Digital Assistant (PDA), ein Internetgerät, ein DVD-Player, ein CD-Player, ein digitaler Videorecorder, ein Blu-ray-Player, eine Spielkonsole, ein Personal Video Recorder, eine Set-Top-Box, ein Headset oder eine andere tragbare Vorrichtung oder eine andere Art von Computergerät sein.
Die Prozessorplattform 2900 des veranschaulichten Beispiels beinhaltet einen Prozessor 2912. Der Prozessor 2912 des veranschaulichten Beispiels ist Hardware. So kann beispielsweise der Prozessor 2912 durch eine oder mehrere integrierte Schaltungen, Logikschaltungen, Mikroprozessoren, GPUs, DSPs oder Controller einer beliebigen Familie oder eines beliebigen Herstellers implementiert werden. Der Hardware-Prozessor kann eine halbleiterbasierte (z.B. siliziumbasierte) Vorrichtung sein. In diesem Beispiel implementiert der Prozessor 2912 die exemplarische Prefetch-Kern-Abrufeinrichtung 202, die exemplarische Speicherschnittstellen-Maschine 204 und die exemplarische Kern-Abrufeinrichtung 206.
Der Prozessor 2912 des veranschaulichten Beispiels beinhaltet einen lokalen Speicher 2913 (z. B. einen Cache). Der Prozessor 2912 des veranschaulichten Beispiels steht in Verbindung mit einem Hauptspeicher mit einem flüchtigen Speicher 2914 und einem nichtflüchtigen Speicher 2916 über einen Bus 2918. Der flüchtige Speicher 2914 kann durch Synchronous Dynamic Random Access Memory (SDRAM), Dynamic Random Access Memory (DRAM), RAMBUS® Dynamic Random Access Memory (RDRAM®) und/oder jede andere Art von Direktzugriffsspeichervorrichtung implementiert werden. Der nichtflüchtige Speicher 2916 kann durch Flash-Speicher und/oder jede andere gewünschte Art von Speichervorrichtung implementiert werden. Der Zugriff auf den Hauptspeicher 2914, 2916 wird durch einen Speichercontroller gesteuert.
Die Prozessorplattform 2900 des veranschaulichten Beispiels beinhaltet auch eine Schnittstellenschaltung 2920. Die Schnittstellenschaltung 2920 kann durch jede Art von Schnittstellenstandard implementiert werden, wie beispielsweise eine Ethernet-Schnittstelle, einen universellen seriellen Bus (USB), eine Bluetooth®-Schnittstelle, eine Nahfeldkommunikationsschnittstelle (NFC) und/oder eine PCI-Express-Schnittstelle.
Im dargestellten Beispiel sind eine oder mehrere Eingabevorrichtungen 2922 an die Schnittstellenschaltung 2920 angeschlossen. Die Eingabevorrichtung(en) 2922 erlauben es einem Benutzer, Daten und/oder Befehle in den Prozessor 2912 einzugeben. Die Eingabevorrichtung(en) 2922 können beispielsweise durch einen Audiosensor, ein Mikrofon, eine Kamera (Standbild oder Video), eine Tastatur, eine Taste, eine Maus, einen Touchscreen, ein Track-Pad, einen Trackball, eine Isopunktvorrichtung und/oder ein Spracherkennungssystem implementiert werden.
Eine oder mehrere Ausgabevorrichtungen 2924 sind ebenfalls an die Schnittstellenschaltung 2920 des dargestellten Beispiels angeschlossen. Die Ausgabevorrichtungen 2924 können beispielsweise durch Anzeigevorrichtungen (z. B. eine Leuchtdiode (LED), eine organische Leuchtdiode (OLED), eine Flüssigkristallanzeige (LCD), eine Kathodenstrahlröhrenanzeige (CRT), ein In-Place-Switching (IPS)-Display, einen Touchscreen usw.), eine taktile Ausgabevorrichtung, einen Drucker und/oder Lautsprecher realisiert werden. Die Schnittstellenschaltung 2920 des veranschaulichten Beispiels beinhaltet somit typischerweise eine Grafiktreiberkarte, einen Grafiktreiberchip und/oder einen Grafiktreiberprozessor .
Die Schnittstellenschaltung 2920 des veranschaulichten Beispiels beinhaltet auch eine Kommunikationsvorrichtung wie einen Sender, einen Empfänger, einen Sender-Empfänger, ein Modem, ein Kabelmodem, einen drahtlosen Zugangspunkt und/oder eine Netzwerkschnittstelle, um den Datenaustausch mit externen Maschinen (z. B. Rechenvorrichtungen jeglicher Art) über ein Netzwerk 2926 zu erleichtern. Die Kommunikation kann beispielsweise über eine Ethernet-Verbindung, eine digitale Teilnehmeranschlussleitung (DSL), eine Telefonleitungsverbindung, ein Koaxialkabelsystem, ein Satellitensystem, ein drahtloses Standortsystem, ein Mobilfunksystem usw. erfolgen.
Die Prozessorplattform 2900 des veranschaulichten Beispiels beinhaltet auch ein oder mehrere Massenspeichergeräte 2928 zum Speichern von Software und/oder Daten. Beispiele für solche Massenspeichergeräte 2928 sind Diskettenlaufwerke, Festplatten, Compact-Disc-Laufwerke, Blu-ray-Laufwerke, redundante Anordnung von unabhängigen Festplatten (RAID-Systeme) und Digital Versatile Disc (DVD)-Laufwerke.
Die maschinenausführbaren Anweisungen 2932 der 24-27 können in der Massenspeichervorrichtung 2928, im flüchtigen Speicher 2914, im nichtflüchtigen Speicher 2916 und/oder auf einem entfernbaren, nichtflüchtigen, computerlesbaren Speichermedium wie einer CD oder DVD gespeichert werden.
Aus dem Vorstehenden ist zu entnehmen, dass exemplarische Verfahren, Vorrichtungen und Herstellungsgegenstände offenbart wurden, die die Speicherlatenz reduzieren und die Pixeldatenübertragung verbessern. Die hierin offenbarte exemplarische Prefetch-Block-Cache-Vorrichtung optimiert den Zugriff auf Bilddatenblöcke und nicht auf Speicherzeilen. Die hierin offenbarten Beispiele bieten einen blockbasierten Zugriff auf Puffer von Bilddaten mit hoher Speicherbandbreite für die Hardwarebeschleunigung der Bildverarbeitung oder Computer Vision Algorithmen. Die hierin offenbarten Beispiele bieten eine verbesserte Schnittstelle zu Bilddaten, die für Beschleuniger von Algorithmen geeignet sind, bei denen Zugriffsmuster eine räumliche Lokalisierung aufweisen, aber nicht von einem Bild (oder einer Kachel oder einem Schnitt davon) oder Pixel zum nächsten vorbestimmt oder festgelegt sind. Die hierin offenbarten Beispiele holen spekulativ Bilddatenblöcke aus dem Speicher und speichern sie im ungenutzten Cache-Speicher, um eine höhere Effizienz bei zukünftigen Anforderungen nach den spekulativ abgerufenen Bilddatenblöcken zu erreichen. Die hierin offenbarten Beispiele verbessern die Effizienz von Warp-Transformationen durch die Implementierung der hierin offenbarten Prefetch-Block-Cache-Vorrichtung.
Beispiel 1 enthält eine Vorrichtung zum Reduzieren von Pixelübertragungslatenz, wobei die Vorrichtung eine Prefetch-Kern-Abrufeinrichtung zum Erzeugen eines Block-Tags basierend auf einer ersten Anforderung von einem Hardwarebeschleuniger, wobei die erste Anforderung erste Koordinaten eines ersten Pixels enthält, das in einem ersten Bildblock angeordnet ist, eine Speicherschnittstellen-Maschine zum Speichern des ersten Bildblocks, der eine Vielzahl von Pixeln enthält, die das Pixel enthalten, in einen Cache-Speicher basierend auf dem Block-Tag, und eine Kern-Abrufeinrichtung zum Zugreifen auf zwei oder mehr Speichervorrichtungen umfasst, die im Cache-Speicher enthalten sind, parallel zum Übertragen einer Vielzahl von Bildblöcken, die den ersten Bildblock enthalten, wenn eine zweite Anforderung empfangen wird, die zweite Koordinaten eines zweiten Pixels enthält, das im ersten Bildblock angeordnet ist.
Beispiel 2 enthält die Vorrichtung nach Beispiel 1, wobei die Prefetch-Kern-Abrufeinrichtung zum Erzeugen des Block-Tags durch Verketten einer ersten Menge von Bits einer ersten der ersten Koordinaten und einer zweiten Menge von Bits einer zweiten der ersten Koordinaten ist.
Beispiel 3 enthält die Vorrichtung nach Beispiel 1, wobei die Prefetch-Kern-Abrufeinrichtung zum Durchsuchen eines Tag-Speichers, um innerhalb eines einzigen Taktzyklus zu identifizieren, ob das Block-Tag mit einem einer Vielzahl von in dem Tag-Speicher gespeicherten Block-Tags übereinstimmt, und Erzeugen einer spekulativen Build-Anforderung zum Abrufen des ersten Bildblocks aus Speicher ist, wenn das Block-Tag nicht mit einem der Vielzahl von Block-Tags übereinstimmt, und wobei die Speicherschnittstellen-Maschine zum Aktualisieren eines Eintrags im Tag-Speicher ist, wenn der erste Bildblock gespeichert ist.
Beispiel 4 enthält die Vorrichtung nach Beispiel 3, wobei die Speicherschnittstellen-Maschine zum Aktualisieren des Eintrags durch Speichern des Block-Tags in einem Tag-Feld, Speichern eines ersten Wertes in einem Pending-Feld und/oder Speichern eines zweiten Wertes in einem Validierungsfeld ist, wobei sich der erste Wert vom zweiten Wert unterscheidet.
Beispiel 5 enthält die Vorrichtung nach Beispiel 1, wobei die Vielzahl von Pixeln eine erste Vielzahl von Pixeln ist und die Vorrichtung ferner die Speicherschnittstellen-Maschine zum Abrufen eines zweiten Bildblocks, der eine zweite Vielzahl von Pixeln enthält, wobei die erste Vielzahl von Pixeln in der Nähe der zweiten Vielzahl von Pixeln in einem Bild liegt, wobei der zweite Bildblock nicht in der Anforderung enthalten ist, und Speichern des zweiten Bildblocks im Cache-Speicher basierend auf dem Block-Tag enthält, und wobei die Kern-Abrufeinrichtung zum Übertragen der Vielzahl von Blöcken, die den ersten Bildblock und den zweiten Bildblock enthalten, an den Hardwarebeschleuniger ist.
Beispiel 6 enthält die Vorrichtung nach Beispiel 1, wobei Speichern des ersten Blocks auf einer Morton-Ordnung, einer Spalten-Hauptordnung oder eine Zeilen-Hauptordnung basiert.
Beispiel 7 enthält die Vorrichtung nach Beispiel 1, wobei das Block-Tag ein erstes Block-Tag ist und wobei die Prefetch-Kern-Abrufeinrichtung zum Bestimmen, ob ein erster Eintrag im Tag-Speicher ein erstes Zählfeld mit einem Nicht-Null-Wert enthält, Bestimmen, ob ein zweiter Eintrag im Tag-Speicher ein zweites Zählfeld mit einem Nicht-Null-Wert enthält, wenn das erste Zählfeld einen Nicht-Null-Wert hat, und Ersetzen eines zweiten Block-Tags des zweiten Eintrags durch das erste Block-Tag ist, wenn das zweite Zählfeld keinen Nicht-Null-Wert hat.
Beispiel 8 enthält die Vorrichtung nach Beispiel 7, wobei die Prefetch-Kern-Abrufeinrichtung das zweite Block-Tag ersetzt, wenn ein Pending-Feld des zweiten Eintrags einen Null-Wert hat.
Beispiel 9 enthält die Vorrichtung nach Beispiel 1, wobei der Hardwarebeschleuniger ein Bildverarbeitungshardwarebeschleuniger, ein dreidimensionaler (3-D) Hardwarebeschleuniger oder ein kryptographischen Hardwarebeschleuniger ist.
Beispiel 10 enthält ein nichtflüchtiges, computerlesbares Speichermedium, umfassend Anweisungen, die, wenn sie ausgeführt werden, eine Maschine dazu veranlassen, mindestens ein Block-Tag basierend auf einer ersten Anforderung von einem Hardwarebeschleuniger zu erzeugen, wobei die erste Anforderung erste Koordinaten eines ersten Pixels enthalten, das in einem ersten Bildblock angeordnet ist, den ersten Bildblock, der eine Vielzahl von Pixeln enthält, die das Pixel enthalten, in einem Cache-Speicher basierend auf dem Block-Tag zu speichern, und auf zwei oder mehr Speichervorrichtungen, die im Cache-Speicher enthalten sind, parallel zu Übertragen einer Vielzahl von Bildblöcken, die den ersten Bildblock enthalten, zuzugreifen, wenn eine zweite Anforderung empfangen wird, die zweite Koordinaten eines zweiten Pixels enthält, das im ersten Bildblock angeordnet ist.
Beispiel 11 enthält das nichtflüchtige, computerlesbare Speichermedium nach Beispiel 10, ferner enthaltend Anweisungen, die, wenn sie ausgeführt werden, die Maschine dazu veranlassen, mindestens eine erste Menge von Bits einer ersten der ersten Koordinaten und eine zweite Menge von Bits einer zweiten der ersten Koordinaten zu verketten.
Beispiel 12 enthält das nichtflüchtige, computerlesbare Speichermedium nach Beispiel 10, ferner enthaltend Anweisungen, die, wenn sie ausgeführt werden, die Maschine dazu veranlassen, mindestens einen Tag-Speicher zu durchsuchen, um innerhalb eines einzigen Taktzyklus zu identifizieren, ob das Block-Tag mit einem von einer Vielzahl von in dem Tag-Speicher gespeicherten Block-Tags übereinstimmt, eine spekulative Build-Anforderung zum Abrufen des ersten Bildblocks aus dem Speicher zu erzeugen, wenn das Block-Tag nicht mit einem der Vielzahl von Block-Tags übereinstimmt, und einen Eintrag im Tag-Speicher zu aktualisieren, wenn der erste Bildblock gespeichert ist.
Beispiel 13 enthält das nichtflüchtige, computerlesbare Speichermedium nach Beispiel 12, ferner enthaltend Anweisungen, die, wenn sie ausgeführt werden, die Maschine dazu veranlassen, mindestens den Eintrag durch Speichern des Block-Tags in einem Tag-Feld, Speichern eines ersten Wertes in einem Pending-Feld und/oder Speichern eines zweiten Wertes in einem Validierungsfeld zu aktualisieren, wobei sich der erste Wert vom zweiten Wert unterscheidet.
Beispiel 14 enthält das nichtflüchtige, computerlesbare Speichermedium nach Beispiel 10, wobei die Vielzahl von Pixeln eine erste Vielzahl von Pixeln ist und ferner Anweisungen enthält, die, wenn sie ausgeführt werden, die Maschine dazu veranlassen, mindestens einen zweiten Bildblock abzurufen, der eine zweite Vielzahl von Pixeln enthält, wobei die erste Vielzahl von Pixeln in der Nähe der zweiten Vielzahl von Pixeln in einem Bild ist, wobei der zweite Bildblock nicht in der Anforderung enthalten ist, den zweiten Bildblock im Cache-Speicher basierend auf dem Block-Tag zu speichern, und die Vielzahl von Bildblöcken, die den ersten Bildblock und den zweiten Bildblock enthalten, an den Hardwarebeschleuniger zu übertragen.
Beispiel 15 enthält das nichtflüchtige, computerlesbare Speichermedium nach Beispiel 10, wobei Speichern des ersten Blocks auf einer Morton-Ordnung, einer Spalten-Hauptordnung oder einer Zeilen-Hauptordnung basiert.
Beispiel 16 enthält das nichtflüchtige, computerlesbare Speichermedium nach Beispiel 10, wobei das Block-Tag ein erstes Block-Tag ist und ferner Anweisungen enthält, die, wenn sie ausgeführt werden, die Maschine dazu veranlassen, mindestens zu bestimmen, ob ein erster Eintrag im Tag-Speicher ein erstes Zählfeld mit einem Nicht-Null-Wert enthält, zu bestimmen, ob ein zweiter Eintrag im Tag-Speicher ein zweites Zählfeld mit einem Nicht-Null-Wert enthält, wenn das erste Zählfeld einen Nicht-Null-Wert hat, und ein zweites Block-Tag des zweiten Eintrags durch das erste Block-Tag zu ersetzen, wenn das zweite Zählfeld keinen Nicht-Null-Wert hat.
Beispiel 17 enthält das nichtflüchtige, computerlesbare Speichermedium nach Beispiel 16, ferner enthaltend Anweisungen, die, wenn sie ausgeführt werden, die Maschine dazu veranlassen, mindestens zu bestimmen, ob ein Pending-Feld, das in dem zweiten Eintrag enthalten ist, einen Nicht-Null-Wert hat, und das zweite Block-Tag des zweiten Eintrags durch das erste Block-Tag zu ersetzen, wenn ein Pending-Feld des zweiten Eintrags einen Null-Wert hat.
Beispiel 18 enthält ein Verfahren zum Reduzieren von Pixelübertragungslatenz, wobei das Verfahren Erzeugen eines Block-Tags basierend auf einer ersten Anforderung von einem Hardwarebeschleuniger, wobei die erste Anforderung erste Koordinaten eines ersten Pixels enthält, das in einem ersten Bildblock angeordnet ist, Speichern des ersten Bildblocks, der eine Vielzahl von Pixeln enthält, die das Pixel enthalten, in einen Cache-Speicher basierend auf dem Block-Tag, und Zugreifen auf zwei oder mehr Speichervorrichtungen umfasst, die im Cache-Speicher enthalten sind, parallel zum Übertragen einer Vielzahl von Bildblöcken, die den ersten Bildblock enthalten, wenn eine zweite Anforderung empfangen wird, die zweite Koordinaten eines zweiten Pixels enthält, das im ersten Bildblock angeordnet ist.
Beispiel 19 enthält das Verfahren nach Beispiel 18, wobei Erzeugen des Block-Tags Verketten einer ersten Menge von Bits einer ersten der ersten Koordinaten und eine zweite Menge von Bits einer zweiten der ersten Koordinaten enthält.
Beispiel 20 enthält das Verfahren nach Beispiel 18, ferner enthaltend Durchsuchen eines Tag-Speichers, um innerhalb eines einzigen Taktzyklus zu identifizieren, ob das Block-Tag mit einem einer Vielzahl von im Tag-Speicher gespeicherten Block-Tags übereinstimmt, Erzeugen einer spekulativen Build-Anforderung zum Abrufen des ersten Bildblocks aus Speicher, wenn das Block-Tag nicht mit einem der Vielzahl von Block-Tags übereinstimmt, und Aktualisieren eines Eintrags im Tag-Speicher, wenn der erste Bildblock gespeichert ist.
Beispiel 21 enthält das Verfahren nach Beispiel 20, wobei Aktualisieren des Eintrags Speichern des Block-Tags in einem Tag-Feld, Speichern eines ersten Wertes in einem Pending-Feld und/oder Speichern eines zweiten Wertes in einem Validierungsfeld enthält, wobei sich der erste Wert vom zweiten Wert unterscheidet.
Beispiel 22 enthält das Verfahren nach Beispiel 18, wobei die Vielzahl von Pixeln eine erste Vielzahl von Pixeln ist und das Verfahren ferner Abrufen eines zweiten Bildblocks, der eine zweite Vielzahl von Pixeln enthält, wobei die erste Vielzahl von Pixeln in der Nähe der zweiten Vielzahl von Pixeln in einem Bild ist, wobei der zweite Bildblock nicht in der Anforderung enthalten ist, Speichern des zweiten Bildblocks im Cache-Speicher basierend auf dem Block-Tag, und Übertragen der Vielzahl von Bildblöcken enthält, die den ersten Bildblock und den zweiten Bildblock enthalten, an den Hardwarebeschleuniger.
Beispiel 23 enthält das Verfahren nach Beispiel 18, wobei Speichern des ersten Bildblocks auf einer Morton-Ordnung, einer Spalten-Hauptordnung oder einer Zeilen-Hauptordnung basiert.
Beispiel 24 enthält das Verfahren nach Beispiel 18, wobei das Block-Tag ein erstes Block-Tag ist und Speichern des ersten Bildblocks Bestimmen, ob ein erster Eintrag im Tag-Speicher ein erstes Zählfeld mit einem Nicht-Null-Wert enthält, als Reaktion auf Bestimmen, dass das erste Zählfeld einen Nicht-Null-Wert hat, Bestimmen, ob ein zweiter Eintrag im Tag-Speicher ein zweites Zählfeld mit einem Nicht-Null-Wert enthält, und als Reaktion auf Bestimmen, dass das zweite Zählfeld keinen Nicht-Null-Wert hat, Ersetzen eines zweiten Block-Tags des zweiten Eintrags durch das erste Block-Tag enthält.
Beispiel 25 enthält das Verfahren nach Beispiel 24, wobei Ersetzen des zweiten Block-Tags Bestimmen, ob ein Pending-Feld, das in dem zweiten Eintrag enthalten ist, einen Nicht-Null-Wert hat, und als Reaktion darauf, dass das Pending-Feld einen Null-Wert hat, Ersetzen des zweiten Block-Tags des zweiten Eintrags durch das erste Block-Tag enthält.
Beispiel 26 enthält eine Vorrichtung zum Reduzieren der Pixelübertragungslatenz, wobei die Vorrichtung ein erstes Mittel zum Erzeugen eines Block-Tags basierend auf einer ersten Anforderung von einem Hardwarebeschleuniger, wobei die erste Anforderung erste Koordinaten eines ersten Pixels enthält, das in einem ersten Bildblock angeordnet ist, ein zweites Mittel zum Speichern des ersten Bildblocks, der eine Vielzahl von Pixeln enthält, die das Pixel enthalten, in einem Cache-Speicher basierend auf dem Block-Tag, und ein drittes Mittel zum Zugreifen auf zwei oder mehr Speichervorrichtungen umfasst, die im Cache-Speicher enthalten sind, parallel zum Übertragen einer Vielzahl von Bildblöcken, die den ersten Bildblock enthalten, wenn eine zweite Anforderung empfangen wird, die zweite Koordinaten eines zweiten Pixels enthält, das im ersten Bildblock angeordnet ist.
Beispiel 27 enthält die Vorrichtung von Beispiel 26, wobei das erste Mittel Verketten einer ersten Menge von Bits einer ersten der ersten Koordinaten und eine zweite Menge von Bits einer zweiten der ersten Koordinaten enthält.
Beispiel 28 enthält die Vorrichtung von Beispiel 26, ferner enthaltend: ein viertes Mittel zum Durchsuchen eines Tag-Speichers, um innerhalb eines einzigen Taktzyklus zu identifizieren, ob das Block-Tag mit einem einer Vielzahl von im Tag-Speicher gespeicherten Block-Tags übereinstimmt, ein fünftes Mittel zum Erzeugen einer spekulativen Build-Anforderung zum Abrufen des ersten Bildblocks aus Speicher, wenn das Block-Tag nicht mit einem der Vielzahl von Block-Tags übereinstimmt, und ein sechstes Mittel zum Aktualisieren eines Eintrags im Tag-Speicher, wenn der erste Bildblock gespeichert ist.
Beispiel 29 enthält die Vorrichtung von Beispiel 28, wobei das sechste Mittel mindestens Speichern des Block-Tags in einem Tag-Feld, Speichern eines ersten Wertes in einem Pending-Feld und/oder Speichern eines zweiten Wertes in einem Validierungsfeld enthält, wobei sich der erste Wert vom zweiten Wert unterscheidet.
Beispiel 30 enthält die Vorrichtung von Beispiel 26, wobei die Vielzahl von Pixeln eine erste Vielzahl von Pixeln ist und die Vorrichtung ferner ein viertes Mittel zum Abrufen eines zweiten Bildblocks, der eine zweite Vielzahl von Pixeln enthält, wobei die erste Vielzahl von Pixeln in der Nähe der zweiten Vielzahl von Pixeln in einem Bild ist, wobei der zweite Bildblock nicht in der Anforderung enthalten ist, ein fünftes Mittel zum Speichern des zweiten Bildblocks im Cache-Speicher basierend auf dem Block-Tag, und ein sechstes Mittel zum Übertragen der Vielzahl von Bildblöcken enthält, die den ersten Bildblock und den zweiten Bildblock enthalten.
Beispiel 31 enthält die Vorrichtung von Beispiel 26, wobei das zweite Mittel auf einer Morton-Ordnung, einer Spalten-Hauptordnung oder eine Zeilen-Hauptordnung basiert.
Beispiel 32 enthält die Vorrichtung von Beispiel 26, wobei das Block-Tag ein erstes Block-Tag ist und das zweite Mittel ein viertes Mittel zum Bestimmen, ob ein erster Eintrag im Tag-Speicher ein erstes Zählfeld mit einem Nicht-Null-Wert enthält, ein fünftes Mittel zum Bestimmen, ob ein zweiter Eintrag im Tag-Speicher ein zweites Zählfeld mit einem Nicht-Null-Wert enthält, wenn das erste Zählfeld einen Nicht-Null-Wert hat, und ein sechstes Mittel zum Ersetzen eines zweiten Block-Tags des zweiten Eintrags durch das erste Block-Tag enthält, wenn das zweite Zählfeld keinen Nicht-Null-Wert hat.
Beispiel 33 enthält die Vorrichtung von Beispiel 32, wobei das sechste Mittel siebte Mittel zum Bestimmen, ob ein Pending-Feld, das in dem zweiten Eintrag enthalten ist, einen Nicht-Null-Wert hat, und achte Mittel zum Ersetzen des zweiten Block-Tags des zweiten Eintrags durch das erste Block-Tag enthält, wenn ein Pending-Feld des zweiten Eintrags einen Null-Wert hat.
Die hierin offenbarten Beispiele können sich auf Internet-der-Dinge (IoT)-Netze beziehen, die über Verbindungen zu jeweiligen Gateways gekoppelt sind. Das Internet der Dinge (IoT) ist ein Konzept, bei dem eine große Anzahl von Berechnungsgeräten miteinander und mit dem Internet verbunden ist, um Funktionalität und Datenerfassung auf sehr niedrigem Niveau zu ermöglichen. So kann ein IoT-Gerät, wie hierin verwendet, ein halbautonomes Gerät enthalten, das eine Funktion durchführt, wie unter anderem zum Beispiel das Erfassen oder Steuern in Verbindung mit anderen IoT-Geräten und einem weiteren Netzwerk, wie zum Beispiel dem Internet.
Häufig sind IoT-Geräte in Bezug auf Speicher, Größe oder Funktionalität begrenzt, was erlaubt, größere Mengen zu ähnlichen Kosten wie kleinere Mengen größerer Geräte bereitzustellen. Ein IoT-Gerät kann jedoch ein Smartphone, ein Laptop, ein Tablet oder ein PC oder ein anderes größeres Gerät sein. Darüber hinaus kann ein IoT-Gerät ein virtuelles Gerät sein, wie beispielsweise eine Anwendung auf einem Smartphone oder einem anderen Berechnungsgerät. IoT-Geräte können IoT-Gateways enthalten, die zur Kopplung von IoT-Geräten mit anderen IoT-Geräten und mit Cloud-Anwendungen, zur Datenspeicherung, Prozesssteuerung und dergleichen verwendet werden.
Netzwerke von IoT-Geräten können kommerzielle und haustechnische Automationsgeräte enthalten, wie zum Beispiel Wasserverteilungssysteme, elektrische Energieverteilungssysteme, Pipelinesteuerungssysteme, Anlagensteuerungssysteme, Lichtschalter, Thermostate, Schlösser, Kameras, Alarme, Bewegungssensoren und dergleichen. Die IoT-Geräte können über entfernte Computer, Server und andere Systeme zugänglich sein, zum Beispiel zur Steuerung von Systemen oder zum Zugriff auf Daten.
Das zukünftige Wachstum des Internets und ähnlicher Netzwerke kann sehr viele IoT-Geräte betreffen. Dementsprechend werden im Rahmen der hierin diskutierten Techniken eine Reihe von Innovationen für eine solche zukünftige Vernetzung der Notwendigkeit Rechnung tragen, dass alle diese Schichten ungehindert wachsen, verbundene Ressourcen entdecken und zugänglich machen und die Fähigkeit unterstützen, verbundene Ressourcen zu verstecken und zu unterteilen. Es können beliebig viele Netzwerkprotokolle und Kommunikationsstandards verwendet werden, wobei jedes Protokoll und jeder Standard so konzipiert ist, dass er spezifische Ziele erfüllt. Darüber hinaus sind die Protokolle Teil der Struktur des Netzes zur Unterstützung von Diensten, die für Menschen zugänglich sind und unabhängig von Ort, Zeit und Ort funktionieren. Zu den Innovationen gehören die Bereitstellung von Diensten und dazugehöriger Infrastruktur, wie Hard- und Software, Sicherheitsverbesserungen und die Bereitstellung von Diensten auf der Grundlage von Quality of Service (QoS)-Bedingungen, die in Service-Level- und Service-Bereitstellungs-Vereinbarungen festgelegt sind.
Backbone-Verbindungen können eine beliebige Anzahl von kabelgebundenen oder drahtlosen Technologien enthalten, einschließlich optischer Netzwerke, und können Teil eines lokalen Netzwerks (LAN), eines Weiterverkehrsnetzwerks (WAN) oder des Internets sein. Darüber hinaus erleichtern solche Kommunikationsverbindungen optische Signalwege sowohl zwischen IoT-Geräten als auch zwischen Gateways, einschließlich der Verwendung von MUX/DeMUXing-Komponenten, die die Verbindung der verschiedenen Geräte erleichtern.
Die Netzwerktopologie kann eine beliebige Anzahl von IoT-Netzwerken beinhalten, wie beispielsweise ein Mesh-Netzwerk, das mit dem Netzwerk über Bluetooth-Low-Energy (BLE)-Verbindungen ausgestattet ist. Andere Arten von IoT-Netzwerken, die vorhanden sein können, enthalten ein WLAN-Netzwerk (Wireless Local Area Network), das zur Kommunikation mit IoT-Geräten über IEEE 802.11 (Wi-Fi®)-Verbindungen verwendet wird, ein Mobilfunknetz, das zur Kommunikation mit IoT-Geräten über ein LTE/LTE-A- (4G) oder 5G-Mobilfunknetz verwendet wird, und ein Low-Power-Weitverkehrsnetz (LPWA), beispielsweise ein LPWA-Netz, das mit der von der LoRa-Allianz veröffentlichten LoRaWan-Spezifikation kompatibel ist, oder ein IPv6-über-Low-Power-Weitverkehrsnetz (LPWAN), das mit einer von der Internet Engineering Task Force (IETF) veröffentlichten Spezifikation kompatibel ist. Darüber hinaus können die jeweiligen IoT-Netzwerke mit einem externen Netzbetreiber (z. B. einem Tier-2- oder Tier-3-Provider) über eine beliebige Anzahl von Kommunikationsverbindungen kommunizieren, wie zum Beispiel eine LTE-Mobilfunkverbindung, eine LPWA-Verbindung oder eine Verbindung nach dem IEEE-Standard 802.15.4, wie zum Beispiel Zigbee®. Die jeweiligen IoT-Netzwerke können auch mit der Verwendung einer Vielzahl von Netzwerk- und Internet-Anwendungsprotokollen wie dem Constrained Application Protocol (CoAP) arbeiten. Die jeweiligen IoT-Netzwerke können auch mit Koordinatorgeräten integriert werden, die eine Kette von Verbindungen bilden, die einen Cluster-Baum aus verbundenen Geräten und Netzwerken bildet.
Jedes dieser IoT-Netze kann Möglichkeiten für neue technische Merkmale bieten, wie sie hierin beschrieben sind. Die verbesserten Technologien und Netze können ein exponentielles Wachstum von Geräten und Netzwerken ermöglichen, einschließlich der Nutzung von IoT-Netzen als Fog-Geräte oder -Systeme. Mit zunehmendem Einsatz dieser verbesserten Technologien können die IoT-Netzwerke für Selbstmanagement, funktionale Evolution und Zusammenarbeit entwickelt werden, ohne dass direkte menschliche Eingriffe erforderlich sind. Die verbesserten Technologien können es sogar ermöglichen, dass IoT-Netzwerke ohne zentrale Steuerungssysteme funktionieren. Dementsprechend können die hierin beschriebenen verbesserten Technologien zur Automatisierung und Verbesserung von Netzwerkmanagement- und Betriebsfunktionen weit über die derzeitigen Implementierungen hinaus eingesetzt werden.
In einem Beispiel kann die Kommunikation zwischen IoT-Geräten, beispielsweise über die Backbone-Verbindungen, durch ein dezentrales System zur Authentifizierung, Autorisierung und Abrechnung (AAA) geschützt werden. In einem dezentralen AAA-System können verteilte Zahlungs-, Kredit-, Audit-, Autorisierungs- und Authentifizierungssysteme über eine vernetzte heterogene Netzwerkinfrastruktur implementiert werden. Dies ermöglicht es Systemen und Netzwerken, sich in Richtung autonome Operationen zu bewegen. Bei diesen Arten von autonomen Operationen können Maschinen sogar Verträge über menschliche Ressourcen abschließen und Partnerschaften mit anderen Maschinennetzwerken aushandeln. Dies kann die Erreichung gemeinsamer Ziele und eine ausgewogene Leistungserbringung im Vergleich zu skizzierten, geplanten Service-Level- Vereinbarungen sowie Lösungen ermöglichen, die Zähler, Messungen, Nachvollziehbarkeit und Rückverfolgbarkeit bieten. Die Schaffung neuer Lieferkettenstrukturen und -methoden kann es ermöglichen, eine Vielzahl von Dienstleistungen zu schaffen, wertschöpfend abzubauen und ohne menschliche Beteiligung zusammenzufassen.
Solche IoT-Netze können durch die Integration von Sensortechnologien wie Schall, Licht, elektronischer Verkehr, Gesichts- und Mustererkennung, Geruch, Vibration in die autonomen Organisationen unter den IoT-Geräten weiter verbessert werden. Die Integration sensorischer Systeme kann eine systematische und autonome Kommunikation und Koordination der Leistungserbringung im Hinblick auf vertragliche Serviceziele, Orchestrierung und Quality of Service (QoS) basierte Schwärmung und Fusion von Ressourcen ermöglichen.
Cluster von IoT-Geräten können für die Kommunikation mit anderen IoT-Geräten sowie mit einem Cloud-Netzwerk ausgestattet werden. Dadurch können die IoT-Geräte ein Ad-hoc-Netzwerk zwischen den Geräten bilden, so dass sie als ein einziges Gerät fungieren können, das als Fog-Gerät bezeichnet werden kann.
Ein Cloud-Computing-Netzwerk in Verbindung mit einem Mesh-Netzwerk von IoT-Geräten kann als Fog-Gerät am Rande des Cloud-Computing-Netzwerks betrieben werden. Das Mesh-Netzwerk von IoT-Geräten kann als Fog bezeichnet werden, der am Rande der Cloud arbeitet.
Der Fog kann als ein stark miteinander verbundenes Netzwerk betrachtet werden, bei dem eine Reihe von IoT-Geräten miteinander kommunizieren, beispielsweise über Funkverbindungen. Als ein Beispiel kann dieses Verbundnetz durch eine Verbindungsspezifikation erleichtert werden, die von der Open Connectivity Foundation™ (OCF) veröffentlicht wurde. Dieser Standard ermöglicht es Geräten, sich gegenseitig zu entdecken und eine Kommunikation für Verbindungen herzustellen. Es können auch andere Verbindungsprotokolle verwendet werden, wie unter anderem beispielsweise das Optimized Link State Routing (OLSR)-Protokoll, das Routingprotokoll für besseren Ansatz mobiler Ad-hoc-Vernetzung (better approach to mobile ad-hoc networking, B.A.T.M.A.N.) oder das OMA Lightweight M2M (LWM2M)-Protokoll.
Drei Arten von IoT-Geräten umfassen Gateways, Datenaggregatoren und Sensoren, wobei jedoch jede Kombination von IoT-Geräten und -Funktionalität verwendet werden kann. Die Gateways können Grenzgeräte sein, die die Kommunikation zwischen der Cloud und dem Fog ermöglichen, und können auch die Backend-Prozess-Funktion für Daten von Sensoren bereitstellen, wie beispielsweise Bewegungsdaten, Strömungsdaten, Temperaturdaten und dergleichen. Die Datenaggregatoren können Daten von beliebig vielen Sensoren sammeln und die Backend-Verarbeitungsfunktion für die Analyse ausführen. Die Ergebnisse, Rohdaten oder beides können über die Gateways an die Cloud weitergeleitet werden. Bei den Sensoren kann es sich beispielsweise um vollwertige IoT-Geräte handeln, die sowohl Daten erfassen als auch verarbeiten können. In einigen Fällen können die Sensoren in ihrer Funktionalität eingeschränkter sein, zum Beispiel beim Sammeln der Daten und beim Ermöglichen der Datenaggregatoren oder Gateways, die Daten zu verarbeiten.
Kommunikationen von jedem IoT-Gerät kann über einen geeigneten Weg (z. B. einen bequemsten Weg) zwischen jedem der IoT-Geräte erfolgen, um die Gateways zu erreichen. In diesen Netzen bietet die Anzahl der Verbindungen eine erhebliche Redundanz, so dass die Kommunikation auch bei Verlust einer Reihe von IoT-Geräten aufrechterhalten werden kann. Darüber hinaus kann die Verwendung eines Mesh-Netzwerks die Verwendung von IoT-Geräten ermöglichen, die sehr stromsparend sind oder sich in einer Entfernung von der Infrastruktur befinden, da die Reichweite für die Verbindung zu einem anderen IoT-Gerät viel geringer sein kann als die Reichweite für die Verbindung zu den Gateways.
Der von diesen IoT-Geräten bereitgestellte Fog kann den Geräten in der Cloud, wie beispielsweise einem Server, als ein einziges Gerät an der Grenze der Cloud, z. B. ein Fog-Gerät, präsentiert werden. In diesem Beispiel können die von dem Fog-Gerät ausgehenden Warnungen gesendet werden, ohne dass identifiziert werden kann, dass sie von einem bestimmten IoT-Gerät innerhalb des Fogs stammen. Auf diese Weise kann der Fog als eine verteilte Plattform betrachtet werden, die Rechen- und Speicherressourcen zur Verfügung stellt, um Verarbeitungs- oder datenintensive Aufgaben wie unter anderem Datenanalyse, Datenaggregation und Maschinenlernen durchzuführen.
In einigen Beispielen können die IoT-Geräte mit einem imperativen Programmierstil konfiguriert werden, z. B. wobei jedes IoT-Gerät eine bestimmte Funktion und Kommunikationspartner hat. Die IoT-Geräte, die das Fog-Gerät bilden, können jedoch in einem deklarativen Programmierstil konfiguriert werden, der es den IoT-Geräten ermöglicht, ihre Operationen und Kommunikationen neu zu konfigurieren, um beispielsweise die benötigten Ressourcen als Reaktion auf Bedingungen, Abfragen und Geräteausfälle zu bestimmen. Eine Abfrage eines Benutzers auf einem Server nach den Vorgängen einer Teilmenge von Geräten, die von den IoT-Geräten überwacht werden, kann beispielsweise dazu führen, dass das Fog-Gerät die IoT-Geräte, wie beispielsweise bestimmte Sensoren, auswählt, die zur Beantwortung der Abfrage benötigt werden. Die Daten dieser Sensoren können dann durch eine beliebige Kombination von Sensoren, Datenaggregatoren oder Gateways aggregiert und analysiert werden, bevor sie von dem Fog-Gerät an den Server gesendet werden, um die Anforderung zu beantworten. In diesem Beispiel können IoT-Geräte im Fog die verwendeten Sensoren basierend auf der Abfrage auswählen, wie z. B. das Hinzufügen von Daten von Strömungssensoren oder Temperatursensoren. Wenn einige der IoT-Geräte nicht betriebsbereit sind, können andere IoT-Geräte in dem Fog-Gerät, falls vorhanden, analoge Daten liefern.
Obwohl bestimmte exemplarische Verfahren, Vorrichtungen und Herstellungsgegenstände hierin offenbart wurden, ist der Geltungsbereich dieses Patents nicht darauf beschränkt. Dieses Patent umfasst im Gegensatz dazu alle Verfahren, Vorrichtungen und Herstellungsgegenstände, die in den Bereich der Ansprüche dieses Patents fallen.

Claims

Vorrichtung zum Reduzieren von Pixelübertragungslatenz, wobei die Vorrichtung umfasst: eine Prefetch-Kern-Abrufeinrichtung zum Erzeugen eines Block-Tags basierend auf einer ersten Anforderung von einem Hardwarebeschleuniger, wobei die erste Anforderung erste Koordinaten eines ersten Pixels enthält, das in einem ersten Bildblock angeordnet ist; eine Speicherschnittstellen-Maschine zum Speichern des ersten Bildblocks, der eine Vielzahl von Pixeln enthält, die das Pixel enthalten, in einen Cache-Speicher basierend auf dem Block-Tag; und eine Kern-Abrufeinrichtung zum Zugreifen auf zwei oder mehr Speichervorrichtungen, die im Cache-Speicher enthalten sind, parallel zum Übertragen einer Vielzahl von Bildblöcken, die den ersten Bildblock enthalten, wenn eine zweite Anforderung empfangen wird, die zweite Koordinaten eines zweiten Pixels enthält, das im ersten Bildblock angeordnet ist.
Vorrichtung nach Anspruch 1, wobei die Prefetch-Kern-Abrufeinrichtung zum Erzeugen des Block-Tags durch Verketten einer ersten Menge von Bits einer ersten der ersten Koordinaten und einer zweiten Menge von Bits einer zweiten der ersten Koordinaten ist.
Vorrichtung nach Anspruch 1, wobei die Prefetch-Kern-Abrufeinrichtung ist zum: Durchsuchen eines Tag-Speichers, um innerhalb eines einzigen Taktzyklus zu identifizieren, ob das Block-Tag mit einem einer Vielzahl von in dem Tag-Speicher gespeicherten Block-Tags übereinstimmt; und Erzeugen einer spekulativen Build-Anforderung zum Abrufen des ersten Bildblocks aus Speicher, wenn das Block-Tag nicht mit einem der Vielzahl von Block-Tags übereinstimmt; und wobei die Speicherschnittstellen-Maschine zum Aktualisieren eines Eintrags im Tag-Speicher ist, wenn der erste Bildblock gespeichert ist.
Vorrichtung nach Anspruch 3, wobei die Speicherschnittstellen-Maschine zum Aktualisieren des Eintrags durch Speichern des Block-Tags in einem Tag-Feld, Speichern eines ersten Wertes in einem Pending-Feld und/oder Speichern eines zweiten Wertes in einem Validierungsfeld ist, wobei sich der erste Wert vom zweiten Wert unterscheidet.
Vorrichtung nach Anspruch 1, wobei die Vielzahl von Pixeln eine erste Vielzahl von Pixeln ist und die Vorrichtung ferner enthält: die Speicherschnittstellen-Maschine zum: Abrufen eines zweiten Bildblocks, der eine zweite Vielzahl von Pixeln enthält, wobei die erste Vielzahl von Pixeln in der Nähe der zweiten Vielzahl von Pixeln in einem Bild liegt, wobei der zweite Bildblock nicht in der Anforderung enthalten ist; und Speichern des zweiten Bildblocks im Cache-Speicher basierend auf dem Block-Tag; und wobei die Kern-Abrufeinrichtung zum Übertragen der Vielzahl von Blöcken, die den ersten Bildblock und den zweiten Bildblock enthalten, an den Hardwarebeschleuniger ist.
Vorrichtung nach Anspruch 1, wobei Speichern des ersten Blocks auf einer Morton-Ordnung, einer Spalten-Hauptordnung oder eine Zeilen-Hauptordnung basiert.
Vorrichtung nach Anspruch 1, wobei das Block-Tag ein erstes Block-Tag ist und wobei die Prefetch-Kern-Abrufeinrichtung ist zum: Bestimmen, ob ein erster Eintrag im Tag-Speicher ein erstes Zählfeld mit einem Nicht-Null-Wert enthält; Bestimmen, ob ein zweiter Eintrag im Tag-Speicher ein zweites Zählfeld mit einem Nicht-Null-Wert enthält, wenn das erste Zählfeld einen Nicht-Null-Wert hat; und Ersetzen eines zweiten Block-Tags des zweiten Eintrags durch das erste Block-Tag, wenn das zweite Zählfeld keinen Nicht-Null-Wert hat.
Vorrichtung nach Anspruch 7, wobei die Prefetch-Kern-Abrufeinrichtung das zweite Block-Tag ersetzt, wenn ein Pending-Feld des zweiten Eintrags einen Null-Wert hat.
Vorrichtung nach Anspruch 1, wobei der Hardwarebeschleuniger ein Bildverarbeitungshardwarebeschleuniger, ein dreidimensionaler (3-D) Hardwarebeschleuniger oder ein kryptographischen Hardwarebeschleuniger ist.
Nichtflüchtiges, computerlesbares Speichermedium, umfassend Anweisungen, die, wenn sie ausgeführt werden, eine Maschine dazu veranlassen, mindestens: ein Block-Tag basierend auf einer ersten Anforderung von einem Hardwarebeschleuniger zu erzeugen, wobei die erste Anforderung erste Koordinaten eines ersten Pixels enthalten, das in einem ersten Bildblock angeordnet ist; den ersten Bildblock, der eine Vielzahl von Pixeln enthält, die das Pixel enthalten, in einem Cache-Speicher basierend auf dem Block-Tag zu speichern; und auf zwei oder mehr Speichervorrichtungen, die im Cache-Speicher enthalten sind, parallel zu Übertragen einer Vielzahl von Bildblöcken, die den ersten Bildblock enthalten, zuzugreifen, wenn eine zweite Anforderung empfangen wird, die zweite Koordinaten eines zweiten Pixels enthält, das im ersten Bildblock angeordnet ist.
Nichtflüchtiges, computerlesbares Speichermedium nach Anspruch 10, ferner enthaltend Anweisungen, die, wenn sie ausgeführt werden, die Maschine dazu veranlassen, mindestens eine erste Menge von Bits einer ersten der ersten Koordinaten und eine zweite Menge von Bits einer zweiten der ersten Koordinaten zu verketten.
Nichtflüchtiges, computerlesbares Speichermedium nach Anspruch 10, ferner enthaltend Anweisungen, die, wenn sie ausgeführt werden, die Maschine dazu veranlassen, mindestens: einen Tag-Speicher zu durchsuchen, um innerhalb eines einzigen Taktzyklus zu identifizieren, ob das Block-Tag mit einem von einer Vielzahl von in dem Tag-Speicher gespeicherten Block-Tags übereinstimmt; eine spekulative Build-Anforderung zum Abrufen des ersten Bildblocks aus dem Speicher zu erzeugen, wenn das Block-Tag nicht mit einem der Vielzahl von Block-Tags übereinstimmt; und einen Eintrag im Tag-Speicher zu aktualisieren, wenn der erste Bildblock gespeichert ist.
Nichtflüchtiges, computerlesbares Speichermedium nach Anspruch 12, ferner enthaltend Anweisungen, die, wenn sie ausgeführt werden, die Maschine dazu veranlassen, mindestens den Eintrag durch Speichern des Block-Tags in einem Tag-Feld, Speichern eines ersten Wertes in einem Pending-Feld und/oder Speichern eines zweiten Wertes in einem Validierungsfeld zu aktualisieren, wobei sich der erste Wert vom zweiten Wert unterscheidet.
Nichtflüchtiges, computerlesbares Speichermedium nach Anspruch 10, wobei die Vielzahl von Pixeln eine erste Vielzahl von Pixeln ist und ferner Anweisungen enthält, die, wenn sie ausgeführt werden, die Maschine dazu veranlassen, mindestens: einen zweiten Bildblock abzurufen, der eine zweite Vielzahl von Pixeln enthält, wobei die erste Vielzahl von Pixeln in der Nähe der zweiten Vielzahl von Pixeln in einem Bild ist, wobei der zweite Bildblock nicht in der Anforderung enthalten ist; den zweiten Bildblock im Cache-Speicher basierend auf dem Block-Tag zu speichern; und die Vielzahl von Bildblöcken, die den ersten Bildblock und den zweiten Bildblock enthalten, an den Hardwarebeschleuniger zu übertragen.
Nichtflüchtiges, computerlesbares Speichermedium nach Anspruch 10, wobei Speichern des ersten Blocks auf einer Morton-Ordnung, einer Spalten-Hauptordnung oder einer Zeilen-Hauptordnung basiert.
Nichtflüchtiges, computerlesbares Speichermedium nach Anspruch 10, wobei das Block-Tag ein erstes Block-Tag ist und ferner Anweisungen enthält, die, wenn sie ausgeführt werden, die Maschine dazu veranlassen, mindestens: zu bestimmen, ob ein erster Eintrag im Tag-Speicher ein erstes Zählfeld mit einem Nicht-Null-Wert enthält; zu bestimmen, ob ein zweiter Eintrag im Tag-Speicher ein zweites Zählfeld mit einem Nicht-Null-Wert enthält, wenn das erste Zählfeld einen Nicht-Null-Wert hat; und ein zweites Block-Tag des zweiten Eintrags durch das erste Block-Tag zu ersetzen, wenn das zweite Zählfeld keinen Nicht-Null-Wert hat.
Nichtflüchtiges, computerlesbares Speichermedium nach Anspruch 16, ferner enthaltend Anweisungen, die, wenn sie ausgeführt werden, die Maschine dazu veranlassen, mindestens: zu bestimmen, ob ein Pending-Feld, das in dem zweiten Eintrag enthalten ist, einen Nicht-Null-Wert hat; und das zweite Block-Tag des zweiten Eintrags durch das erste Block-Tag zu ersetzen, wenn ein Pending-Feld des zweiten Eintrags einen Null-Wert hat.
Verfahren zum Reduzieren von Pixelübertragungslatenz, wobei das Verfahren umfasst: Erzeugen eines Block-Tags basierend auf einer ersten Anforderung von einem Hardwarebeschleuniger, wobei die erste Anforderung erste Koordinaten eines ersten Pixels enthält, das in einem ersten Bildblock angeordnet ist; Speichern des ersten Bildblocks, der eine Vielzahl von Pixeln enthält, die das Pixel enthalten, in einen Cache-Speicher basierend auf dem Block-Tag; und Zugreifen auf zwei oder mehr Speichervorrichtungen, die im Cache-Speicher enthalten sind, parallel zum Übertragen einer Vielzahl von Bildblöcken, die den ersten Bildblock enthalten, wenn eine zweite Anforderung empfangen wird, die zweite Koordinaten eines zweiten Pixels enthält, das im ersten Bildblock angeordnet ist.
Verfahren nach Anspruch 18, wobei Erzeugen des Block-Tags Verketten einer ersten Menge von Bits einer ersten der ersten Koordinaten und eine zweite Menge von Bits einer zweiten der ersten Koordinaten enthält.
Verfahren nach Anspruch 18, ferner enthaltend: Durchsuchen eines Tag-Speichers, um innerhalb eines einzigen Taktzyklus zu identifizieren, ob das Block-Tag mit einem einer Vielzahl von im Tag-Speicher gespeicherten Block-Tags übereinstimmt; Erzeugen einer spekulativen Build-Anforderung zum Abrufen des ersten Bildblocks aus Speicher, wenn das Block-Tag nicht mit einem der Vielzahl von Block-Tags übereinstimmt; und Aktualisieren eines Eintrags im Tag-Speicher, wenn der erste Bildblock gespeichert ist.
Verfahren nach Anspruch 20, wobei Aktualisieren des Eintrags Speichern des Block-Tags in einem Tag-Feld, Speichern eines ersten Wertes in einem Pending-Feld und/oder Speichern eines zweiten Wertes in einem Validierungsfeld enthält, wobei sich der erste Wert vom zweiten Wert unterscheidet.
Verfahren nach Anspruch 18, wobei die Vielzahl von Pixeln eine erste Vielzahl von Pixeln ist und das Verfahren ferner enthält: Abrufen eines zweiten Bildblocks, der eine zweite Vielzahl von Pixeln enthält, wobei die erste Vielzahl von Pixeln in der Nähe der zweiten Vielzahl von Pixeln in einem Bild ist, wobei der zweite Bildblock nicht in der Anforderung enthalten ist; Speichern des zweiten Bildblocks im Cache-Speicher basierend auf dem Block-Tag; und Übertragen der Vielzahl von Bildblöcken, die den ersten Bildblock und den zweiten Bildblock enthalten, an den Hardwarebeschleuniger.
Verfahren nach Anspruch 18, wobei Speichern des ersten Bildblocks auf einer Morton-Ordnung, einer Spalten-Hauptordnung oder einer Zeilen-Hauptordnung basiert.
Verfahren nach Anspruch 18, wobei das Block-Tag ein erstes Block-Tag ist und Speichern des ersten Bildblocks enthält: Bestimmen, ob ein erster Eintrag im Tag-Speicher ein erstes Zählfeld mit einem Nicht-Null-Wert enthält; als Reaktion auf Bestimmen, dass das erste Zählfeld einen Nicht-Null-Wert hat, Bestimmen, ob ein zweiter Eintrag im Tag-Speicher ein zweites Zählfeld mit einem Nicht-Null-Wert enthält; und als Reaktion auf Bestimmen, dass das zweite Zählfeld keinen Nicht-Null-Wert hat, Ersetzen eines zweiten Block-Tags des zweiten Eintrags durch das erste Block-Tag.
Verfahren nach Anspruch 24, wobei Ersetzen des zweiten Block-Tags enthält: Bestimmen, ob ein Pending-Feld, das in dem zweiten Eintrag enthalten ist, einen Nicht-Null-Wert hat; und als Reaktion darauf, dass das Pending-Feld einen Null-Wert hat, Ersetzen des zweiten Block-Tags des zweiten Eintrags durch das erste Block-Tag.
Vorrichtung zum Reduzieren der Pixelübertragungslatenz, wobei die Vorrichtung umfasst: ein erstes Mittel zum Erzeugen eines Block-Tags basierend auf einer ersten Anforderung von einem Hardwarebeschleuniger, wobei die erste Anforderung erste Koordinaten eines ersten Pixels enthält, das in einem ersten Bildblock angeordnet ist; ein zweites Mittel zum Speichern des ersten Bildblocks, der eine Vielzahl von Pixeln enthält, die das Pixel enthalten, in einem Cache-Speicher basierend auf dem Block-Tag; und ein drittes Mittel zum Zugreifen auf zwei oder mehr Speichervorrichtungen, die im Cache-Speicher enthalten sind, parallel zum Übertragen einer Vielzahl von Bildblöcken, die den ersten Bildblock enthalten, wenn eine zweite Anforderung empfangen wird, die zweite Koordinaten eines zweiten Pixels enthält, das im ersten Bildblock angeordnet ist.
Vorrichtung nach Anspruch 26, wobei das erste Mittel Verketten einer ersten Menge von Bits einer ersten der ersten Koordinaten und eine zweite Menge von Bits einer zweiten der ersten Koordinaten enthält.
Vorrichtung nach Anspruch 26, ferner enthaltend: ein viertes Mittel zum Durchsuchen eines Tag-Speichers, um innerhalb eines einzigen Taktzyklus zu identifizieren, ob das Block-Tag mit einem einer Vielzahl von im Tag-Speicher gespeicherten Block-Tags übereinstimmt; ein fünftes Mittel zum Erzeugen einer spekulativen Build-Anforderung zum Abrufen des ersten Bildblocks aus Speicher, wenn das Block-Tag nicht mit einem der Vielzahl von Block-Tags übereinstimmt; und ein sechstes Mittel zum Aktualisieren eines Eintrags im Tag-Speicher, wenn der erste Bildblock gespeichert ist.
Vorrichtung nach Anspruch 28, wobei das sechste Mittel mindestens Speichern des Block-Tags in einem Tag-Feld, Speichern eines ersten Wertes in einem Pending-Feld und/oder Speichern eines zweiten Wertes in einem Validierungsfeld enthält, wobei sich der erste Wert vom zweiten Wert unterscheidet.
Vorrichtung nach Anspruch 26, wobei die Vielzahl von Pixeln eine erste Vielzahl von Pixeln ist und die Vorrichtung ferner enthält: ein viertes Mittel zum Abrufen eines zweiten Bildblocks, der eine zweite Vielzahl von Pixeln enthält, wobei die erste Vielzahl von Pixeln in der Nähe der zweiten Vielzahl von Pixeln in einem Bild ist, wobei der zweite Bildblock nicht in der Anforderung enthalten ist; ein fünftes Mittel zum Speichern des zweiten Bildblocks im Cache-Speicher basierend auf dem Block-Tag; und ein sechstes Mittel zum Übertragen der Vielzahl von Bildblöcken, die den ersten Bildblock und den zweiten Bildblock enthalten.
Vorrichtung nach Anspruch 26, wobei das zweite Mittel auf einer Morton-Ordnung, einer Spalten-Hauptordnung oder eine Zeilen-Hauptordnung basiert.
Vorrichtung nach Anspruch 26, wobei das Block-Tag ein erstes Block-Tag ist und das zweite Mittel enthält: ein viertes Mittel zum Bestimmen, ob ein erster Eintrag im Tag-Speicher ein erstes Zählfeld mit einem Nicht-Null-Wert enthält; ein fünftes Mittel zum Bestimmen, ob ein zweiter Eintrag im Tag-Speicher ein zweites Zählfeld mit einem Nicht-Null-Wert enthält, wenn das erste Zählfeld einen Nicht-Null-Wert hat; und ein sechstes Mittel zum Ersetzen eines zweiten Block-Tags des zweiten Eintrags durch das erste Block-Tag, wenn das zweite Zählfeld keinen Nicht-Null-Wert hat.
Vorrichtung nach Anspruch 32, wobei das sechste Mittel enthält: siebte Mittel zum Bestimmen, ob ein Pending-Feld, das in dem zweiten Eintrag enthalten ist, einen Nicht-Null-Wert hat; und achte Mittel zum Ersetzen des zweiten Block-Tags des zweiten Eintrags durch das erste Block-Tag, wenn ein Pending-Feld des zweiten Eintrags einen Null-Wert hat.