DE112018007596T5

DE112018007596T5 - Vorrichtung und verfahren für merkmalspunktverfolgung unter verwendung von inter-frame-voraussage

Info

Publication number: DE112018007596T5
Application number: DE112018007596.6T
Authority: DE
Inventors: Hao Liu
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2018-08-29
Filing date: 2018-08-29
Publication date: 2021-03-04
Also published as: US20210160536A1; CN112956203A; US11470343B2; WO2020041999A1

Abstract

Vorrichtung und Verfahren zur Inter-Frame-Voraussage. Beispielsweise enthält eine Ausführungsform eines Verfahrens Extrahieren eines ersten Satzes von Schlüsselpunkten aus einem laufenden Frame und eines zweiten Satzes von Schlüsselpunkten aus einem Referenzframe; Projizieren eines Schlüsselpunkts p in den Referenzframe als p' basierend auf einem Bewegungsvektor, der mit einem Bereich im laufenden Frame assoziiert ist, in welchem der Schlüsselpunkt p gefunden wird; Lokalisieren von n Schlüsselpunkten im Referenzframe, die p' am nächsten liegen; und Abstimmen von einem der n Schlüsselpunkte im Referenzframe mit dem Schlüsselpunkt p im laufenden Frame basierend auf Deskriptordistanzen zwischen jedem der n Schlüsselpunkte und p '.

Description

STAND DER TECHNIK
Gebiet der Erfindung
Diese Erfindung betrifft im Allgemeinen das Gebiet von Grafikprozessoren. Insbesondere betrifft die Erfindung eine Vorrichtung und ein Verfahren zum Verfolgen von Merkmalspunkten in Videobildern unter Verwendung von Inter-Frame-Voraussage.
Beschreibung des Stands der Technik
Merkmalspunktverfolgung ist eine Technik, die in zahlreichen Videoverarbeitungs- und Grafikgebieten benutzt wird, wie etwa Structure from Motion (SFM) und Panoramaverarbeitung (wie beispielsweise für virtuelle Realitätsimplementierungen verwendet). Der erste Schritt für jegliche Implementierung ist Kamerakalibration, unter Verwendung von Merkmalspunktverfolgung zum Bestimmen der extrinsischen Parameter der Kamera, was ein komplexes Problem darstellt.
Merkmalspunktverfolgungs- und -abstimmungstechniken sollen Merkmalspunkte aus jedem Bild- oder Videostromframe erkennen. Merkmalspunkte werden dann zwischen Paaren von Bildern abgestimmt. Für jedes Paar von Bildern können Schlüsselpunktdeskriptoren unter Verwendung des Approximate Nearest Neighbor-Verfahrens zwischen dem Paar abgestimmt werden.
Figurenliste
Ein besseres Verständnis der vorliegenden Erfindung ist aus der folgenden detaillierten Beschreibung in Verbindung mit den folgenden Zeichnungen zu gewinnen; es zeigen:

1 ein Blockdiagramm einer Ausführungsform eines Computersystems mit einem Prozessor, der einen oder mehr Prozessorkerne und Grafikprozessoren aufweist;
2 ein Blockdiagramm einer Ausführungsform eines Prozessors mit einem oder mehr Prozessorkernen, einer integrierten Speichersteuerung und einem integrierten Grafikprozessor;
3 ein Blockdiagramm einer Ausführungsform eines Grafikprozessors, der eine diskrete Grafikverarbeitungseinheit sein kann oder ein Grafikprozessor sein kann, der mit mehreren Verarbeitungskernen integriert ist;
4 ein Blockdiagramm einer Ausführungsform einer Grafikverarbeitungsmaschine für einen Grafikprozessor;
5 ein Blockdiagramm einer anderen Ausführungsform eines Grafikprozessors;
6 ein Blockdiagramm von Threadausführungslogik, die ein Array von Verarbeitungselementen enthält;
7 ein Grafikprozessorausführungseinheit-Anweisungsformat gemäß einer Ausführungsform;
8 ein Blockdiagramm einer anderen Ausführungsform eines Grafikprozessors, der eine Grafikpipeline, eine Medienpipeline, eine Anzeigenmaschine, Threadausführungslogik und eine Renderausgabepipeline enthält,
9A ein Blockdiagramm, das ein Grafikprozessorbefehlsformat gemäß einer Ausführungsform darstellt;
9B ein Blockdiagramm, das eine Grafikprozessorbefehlssequenz gemäß einer Ausführungsform darstellt;
10 eine beispielhafte Grafiksoftwarearchitektur für ein Datenverarbeitungssystem gemäß einer Ausführungsform;
11 ein beispielhaftes IP-Kernentwicklungssystem, das zum Herstellen einer integrierten Schaltung zum Ausführen von Vorgängen benutzt werden kann, gemäß einer Ausführungsform;
12 eine integrierte System-on-a-Chip-Schaltung, die unter Benutzung von einem oder mehr IP-Kernen gefertigt werden kann, gemäß einer Ausführungsform;
13 einen beispielhaften Grafikprozessor einer integrierten System-on-a-Chip-Schaltung, der unter Benutzung von einem oder mehr IP-Kernen gefertigt werden kann;
14 einen zusätzlichen beispielhaften Grafikprozessor einer integrierten System-on-a-Chip-Schaltung, der unter Benutzung von einem oder mehr IP-Kernen gefertigt werden kann;
15 ein Blockdiagramm, das ein Computersystem darstellt, welches zum Implementieren von einem oder mehr Aspekten der hierin beschriebenen Ausführungsformen konfiguriert ist;
16A bis 16D Parallelprozessorkomponenten gemäß einer Ausführungsform;
17A bis 17B Blockdiagramme von Grafikmultiprozessoren gemäß Ausführungsformen;
18A bis 18F eine beispielhafte Architektur, in der mehrere GPUs kommunikationstechnisch an mehrere Mehrkernprozessoren gekoppelt sind;
19 eine Grafikverarbeitungspipeline gemäß einer Ausführungsform;
20 Schlüsselpunktabbildungstechniken;
21 Bewegungsvektoren, die mit Interblöcken eines Videostroms assoziiert sind;
22 einen Interblock, der basierend auf einem Bewegungsvektor von einem ersten Frame auf einen zweiten Frame abgebildet wird,
23 eine Ausführungsform einer Architektur zum Abbilden von Schlüsselpunkten unter Benutzung von Bewegungsvektoren von Interblöcken;
24 eine Ausführungsform eines Verfahrens zum Abbilden von Schlüsselpunkten unter Benutzung von Bewegungsvektoren von Interblöcken; und
25 ein Beispiel zum Zeigen von abgestimmten Punktpaaren zwischen einem derzeitigen Frame und einem Referenzframe.

DETAILLIERTE BESCHREIBUNG
In der folgenden Beschreibung sind zahlreiche spezifische Details zu Erläuterungszwecken dargelegt, um ein gründliches Verständnis der unten beschrieben Ausführungsformen der Erfindung vorzusehen. Es ist für den Fachmann jedoch ersichtlich, dass die Ausführungsformen der Erfindung ohne manche dieser spezifischen Details praktisch umgesetzt werden können. In anderen Fällen sind allgemein bekannte Strukturen und Geräte in Blockdiagrammform gezeigt, um Verunklaren der zugrunde liegenden Prinzipien der Ausführungsformen der Erfindung zu vermeiden.
BEISPIELHAFTE GRAFIKPROZESSORARCHITEKTUREN UND
DATENTYPEN
Systemübersicht
1 ist ein Blockdiagramm eines Verarbeitungssystems 100 gemäß einer Ausführungsform. In verschiedenen Ausführungsformen enthält das System 100 einen oder mehr Prozessoren 102 und einen oder mehr Grafikprozessoren 108 und kann ein Einzelprozessor-Desktopsystem, ein Multiprozessor-Workstationsystem oder ein Serversystem mit einer hohen Anzahl von Prozessoren 102 oder Prozessorkernen 107 sein. In einer Ausführungsform ist das System 100 eine Verarbeitungsplattform, die innerhalb einer System-on-a-Chip-Schaltung (SoC-Schaltung) zur Benutzung in mobilen, handgehaltenen oder eingebetteten Geräten eingegliedert ist.
Eine Ausführungsform von System 100 kann eine serverbasierte Spieleplattform, eine Spielkonsole, darunter eine Spiel- und Medienkonsole, eine mobile Spielkonsole, eine handgehaltene Spielkonsole oder eine Online-Spielkonsole, enthalten oder darin eingegliedert sein. In manchen Ausführungsformen ist das Systems 100 ein Mobiltelefon, ein Smartphone, ein Tablet-Rechengerät oder ein mobiles Internetgerät. Das Datenverarbeitungssystem 100 kann außerdem ein tragbares Gerät, wie etwa ein tragbares Smartwatch-Gerät, intelligentes Brillengerät, Augmented-Reality-Gerät oder Virtual-Reality-Gerät, beinhalten, daran gekoppelt sein oder darin integriert sein. In manchen Ausführungsformen ist das Datenverarbeitungssystem 100 ein Fernseh- oder Set-Top-Box-Gerät mit einem oder mehr Prozessoren 102 und einer grafischen Oberfläche, die durch einen oder mehr Grafikprozessoren 108 erzeugt wird.
In manchen Ausführungsformen kann der eine oder mehr Prozessoren 102 jeweils einen oder mehr prozessorkerne 107 zum Verarbeiten von Anweisungen enthalten, die, wenn sie ausgeführt werden, Vorgänge für System- und Benutzersoftware ausführen. In manchen Ausführungsformen ist jeder des einen oder mehr Prozessorkerne 107 zum Verarbeiten eines spezifischen Anweisungssatzes 109 konfiguriert. In manchen Ausführungsformen kann der Anweisungssatz 109 Complex Instruction Set Computing (CISC), Reduced Instruction Set Computing (RISC) oder Rechnen über ein Very Long Instruction Word (VLIW) ermöglichen. Mehrfache Prozessorkerne 107 können jeweils einen unterschiedlichen Anweisungssatz 109 verarbeiten, der Anweisungen zum Ermöglichen der Emulation von anderen Anweisungssätzen enthalten kann. Der Prozessorkern 107 kann außerdem andere Verarbeitungsgeräte enthalten, wie etwa einen digitalen Signalprozessor (DSP).
In manchen Ausführungsformen enthält der Prozessor 102 einen Cachespeicher 104. Abhängig von der Architektur kann der Prozessor 102 einen einzelnen internen Cache oder mehrfache interne Cacheebenen aufweisen. In manchen Ausführungsformen wird der Cachespeicher von verschiedenen Komponenten des Prozessors 102 gemeinsam benutzt. In manchen Ausführungsformen nutzt der Prozessor 102 außerdem einen externen Cache (beispielsweise einen Level-3-Cache (L3) oder Last Level Cache (LLC)) (nicht gezeigt), der von den Prozessorkernen 107 unter Nutzung von bekannten Cachekohärenztechniken gemeinsam benutzt werden kann. Eine Registerdatei 106 ist zusätzlich im Prozessor 102 enthalten, die verschiedene Typen von Registern zum Speichern von verschiedenen Datentypen enthalten kann (beispielsweise Ganzzahlregister, Gleitkommaregister, Statusregister und ein Befehlszeigerregister). Manche Register können Mehrzweckregister sein, während andere Register spezifisch für die Gestaltung des Prozessors 102 sein können.
In manchen Ausführungsformen ist der Prozessor 102 mit einem Prozessorbus 110 zum Übertragen von Kommunikationssignalen, wie etwa Adress-, Daten- oder Steuersignale, zwischen dem Prozessor 102 und anderen Komponenten im System 100 verkoppelt. In einer Ausführungsform nutzt das System 100 eine beispielhafte „Hub“-Systemarchitektur, darunter ein Speichersteuerungshub 116 und ein Ein-/Ausgabesteuerungshub (E/A-Steuerungshub) 130. Ein Speichersteuerungshub 116 ermöglicht Kommunikation zwischen einem Speichergerät und anderen Komponenten des Systems 100, während ein E/A-Steuerungshub (ICH) 130 Verbindungen zu E/A-Geräten über einen lokalen E/A-Bus bereitstellt. In einer Ausführungsform ist die Logik des Speichersteuerungshubs 116 im Prozessor integriert.
Das Speichergerät 120 kann ein Speichergerät mit wahlfreiem Zugriff (DRAM), ein statisches Direktzugriffsspeichergerät (SRAM), ein Flashspeichergerät, ein Phasenänderungsspeichergerät oder ein anderes Speichergerät mit geeigneter Leistungsfähigkeit zum Dienen als Prozessspeicher sein. In einer Ausführungsform kann das Speichergerät 120 als Systemspeicher für das System 100 arbeiten, zum Speichern von Daten 122 und Anweisungen 121 zum Gebrauch, wenn der eine oder mehr Prozessoren 102 eine Anwendung oder einen Prozess ausführen. Der Speichersteuerungshub 116 koppelt außerdem an einen optionalen externen Grafikprozessor 112 an, der mit dem einen oder mehr Grafikprozessoren 108 in den Prozessoren 102 zum Ausführen von Grafik- und Medienvorgängen kommunizieren kann.
In manchen Ausführungsformen ermöglicht der ICH 130, dass sich Peripheriegeräte mit dem Speichergerät 120 und dem Prozessor 102 über einen Hochgeschwindigkeits-E/A-Bus verbinden. Die E/A-Peripheriegeräte beinhalten u.a. eine Audiosteuerung 146, eine Firmwareschnittstelle 128, einen drahtlosen Transceiver 126 (beispielsweise Wi-Fi, Bluetooth), ein Datenspeichergerät 124 (beispielsweise Festplattenlaufwerk, Flashspeicher usw.) und eine Legacy-E/A-Steuerung 140 zum Koppeln von älteren Geräten (beispielsweise Personal System 2 (PS/2)) an das System. Eine oder mehr Universal Serial Bus-Steuerungen (USB-Steuerungen) 142 verbinden Eingabegeräte, wie etwa eine Tatstatur- und Mauskombination 144. Eine Netzwerksteuerung 134 kann außerdem mit dem ICH 130 verkoppelt sein. In manchen Ausführungsformen ist eine Hochleistungsnetzwerksteuerung (nicht gezeigt) mit dem Prozessorbus 110 verkoppelt. Man wird erkennen, dass das System 100 beispielhaft und nicht einschränkend gezeigt ist, da andere Arten von Datenverarbeitungssystemen, die anders konfiguriert sind, ebenfalls benutzt werden können. Beispielsweise kann der E/A-Steuerungshub 130 im einen oder mehr Prozessoren 102 integriert sein, oder der Speichersteuerungshub 116 und der E/A-Steuerungshub 130 können in einen diskreten externen Grafikprozessor integriert sein, wie etwa den externen Grafikprozessor 112.
2 ist ein Blockdiagramm einer Ausführungsform eines Prozessors 200, der einen oder mehr Prozessorkerne 202A bis 202N, eine integrierte Speichersteuerung 214 und einen integrierten Grafikprozessor 208 aufweist. Jene Elemente von 2, die dieselben Bezugszeichen (oder - bezeichnungen) wie die Elemente jeglicher anderen Figur hierin aufweisen, können auf jegliche Art und Weise arbeiten oder funktionieren wie jene, die an anderer Stelle hierin beschrieben ist, sind jedoch nicht darauf beschränkt. Der Prozessor 200 kann zusätzliche Kerne bis zum und einschließlich des zusätzlichen Kerns 202N enthalten, die durch die gestrichelt gezeichneten Kästen dargestellt sind. Jeder der Prozessorkerne 202A bis 202N enthält eine oder mehr interne Cacheeinheiten 204A bis 204N. In manchen Ausführungsformen weist jeder Prozessorkern außerdem Zugriff auf eine oder mehr gemeinsam benutzte Cacheeinheiten 206.
Die internen Cacheeinheiten 204A bis 204N und die gemeinsam benutzten Cacheeinheiten 206 stellen eine Cachespeicherhierarchie innerhalb des Prozessors 200 dar. Die Cachespeicherhierarchie kann mindestens ein Anweisungs- und Datencachelevel innerhalb jeden Prozessorkerns und ein oder mehr gemeinsam benutzte, mittlere Cachelevel, wie etwa Level 2 (L2), Level 3 (L3), Level 4 (L4), oder andere Cachelevel enthalten, wobei das höchste Cachelevel vor externem Speicher als LLC klassifiziert ist. In manchen Ausführungsformen erhält Cachekohärenzlogik Kohärenz zwischen den verschiedenen Cacheeinheiten 206 und 204A bis 204N aufrecht.
In manchen Ausführungsformen kann der Prozessor 200 außerdem einen Satz von einer oder mehr Bussteuerungseinheiten 216 und einen Systemdienstkern 210 enthalten. Die eine oder mehr Bussteuerungseinheiten 216 verwalten einen Satz von peripheren Bussen, wie etwa einen oder mehr Peripheral Component Interconnect-Busse (beispielsweise PCI, PCI Express). Der Systemdienstkern 210 sieht Verwaltungsfunktionalität für die verschiedenen Prozessorkomponenten vor. In manchen Ausführungsformen enthält der Systemdienstkern 210 eine oder mehr integrierte Speichersteuerungen 214 zum Verwalten von Zugriff auf die verschiedenen externen Speichergeräte (nicht gezeigt).
In manchen Ausführungsformen enthält einer oder mehr der Prozessorkerne 202A bis 202N Unterstützung für simultanes Multithreading. In derartigen Ausführungsformen enthält der Systemdienstkern 210 Komponenten zum Koordinieren und Betreiben der Kerne 202A bis 202N während Multithreadverarbeitung. Der Systemdienstkern 210 kann zusätzlich eine Leistungssteuereinheit (PCU) enthalten, die Logik und Komponenten zum Regulieren des Leistungszustands der Prozessorkerne 202A bis 202N und des Grafikprozessors 208 enthält.
In manchen Ausführungsformen enthält der Prozessor 200 zusätzlich den Grafikprozessor 208 zum Ausführen von Grafikverarbeitungsvorgängen. In manchen Ausführungsformen ist der Grafikprozessor 208 mit dem Satz von gemeinsam benutzten Cacheeinheiten 206 und dem Systemdienstkern 210 verkoppelt, darunter die eine oder mehr integrierten Speichersteuerungen 214. In manchen Ausführungsformen ist eine Anzeigensteuerung 211 zum Übermitteln von Grafikprozessorausgabe an eine oder mehr angekoppelte Anzeigen mit dem Grafikprozessor 208 verkoppelt. In manchen Ausführungsformen kann die Anzeigensteuerung 211 ein separates Modul sein, das mit dem Grafikprozessor über mindestens eine Zusammenschaltung verkoppelt ist, oder sie kann im Grafikprozessor 208 oder Systemdienstkern 210 integriert sein.
In manchen Ausführungsformen ist eine ringbasierte Zusammenschaltungseinheit 212 zum Verkoppeln der internen Komponenten des Prozessors 200 benutzt. Es kann jedoch eine alternative Zusammenschaltungseinheit benutzt sein, wie etwa eine Punkt-zu-Punkt-Zusammenschaltung, eine geschaltete Zusammenschaltung oder andere Techniken, darunter im Fachgebiet allgemein bekannte Techniken. In manchen Ausführungsformen ist der Grafikprozessor 208 über eine E/A-Verbindung 213 mit der Ringzusammenschaltung 212 verkoppelt.
Die beispielhafte E/A-Verbindung 213 stellt mindestens eine von mehreren Arten von E/A-Zusammenschaltungen dar, darunter eine On-Package-E/A-Zusammenschaltung, die Kommunikation zwischen verschiedenen Prozessorkomponenten und einem eingebetteten Hochleistungsspeichermodul 218 ermöglicht, wie etwa einem eDRAM-Modul. In manchen Ausführungsformen benutzen jeder der Prozessorkerne 202A bis 202N und der Graphikprozessor 208 eingebettete Speichermodule 218 als gemeinsam benutzten Last Level Cache.
In manchen Ausführungsformen sind die Prozessorkerne 202A bis 202N homogene Kerne, die dieselbe Anweisungssatzarchitektur ausführen. In einer anderen Ausführungsform sind die Prozessorkerne 202A bis 202N hinsichtlich der Anweisungssatzarchitektur (ISA) heterogen, wobei einer oder mehr der Prozessorkerne 202A bis 202N einen ersten Anweisungssatz ausführen, während mindestens einer der anderen Kerne einen Teilsatz des ersten Anweisungssatzes oder einen anderen Anweisungssatz ausführt. In einer Ausführungsform sind die Prozessorkerne 202A bis 202N hinsichtlich einer Mikroarchitektur heterogen, wobei einer oder mehr Kerne mit einem verhältnismäßig höheren Leistungsverbrauch mit einem oder mehr Leistungskernen mit einem niedrigeren Leistungsverbrauch verkoppelt sind. Zudem kann der Prozessor 200 auf einem oder mehr Chips oder als eine integrierte SoC-Schaltung mit den dargestellten Komponenten, zusätzlich zu anderen Komponenten, implementiert sein.
3 ist ein Blockdiagramm eines Grafikprozessors 300, der eine integrierte Grafikverarbeitungseinheit sein kann oder ein Grafikprozessor sein kann, der mit mehreren Prozessorkernen integriert sein kann. In manchen Ausführungsformen kommuniziert der Grafikprozessor über eine im Speicher abgebildete E/A-Schnittstelle mit Registern im Grafikprozessor und mit Befehlen, die im Prozessorspeicher angeordnet sind. In manchen Ausführungsformen enthält der Grafikprozessor 300 eine Speicherschnittstelle 314 für Speicherzugriff. Die Speicherschnittstelle 314 kann eine Schnittstelle zu lokalem Speicher, einem oder mehr internen Caches, einem oder mehr gemeinsam benutzten, externen Caches und/oder zum Systemspeicher sein.
In manchen Ausführungsformen enthält der Grafikspeicher 300 außerdem eine Anzeigensteuerung 302 zum Übermitteln von Anzeigenausgabedaten an ein Anzeigengerät 320. Die Anzeigensteuerung enthält Hardware für eine oder mehr Überlagerungsebenen für die Anzeige und die Zusammenstellung von mehrfachen Schichten von Video- oder Benutzeroberflächenelementen. In manchen Ausführungsformen enthält der Grafikprozessor eine Videocodecmaschine 306 zum Codieren, Decodieren oder Transcodieren von Medien in, aus oder zwischen einem oder mehr Mediencodierformaten, darunter u.a. Moving Picture Experts Group-Formate (MPEG-Formate), wie etwa MPEG-2, Advanced Video Coding-Formate (AVC-Formate), wie etwa H.264/MPEG-4 AVC, sowie die Society of Motion Picture & Television Engineers- (SMPTE) 421M/VC-1 und Joint Photographic Experts Group-Formate (JPEG-Formate), wie etwa JPEG, und Motion JPEG-Formate (MJPEG- Formate).
In manchen Ausführungsformen enthält der Grafikprozessor 300eine Blockbildtransfermaschine (BLIT-Maschine) 304 zum Ausführen von zweidimensionalen (2D) Rasterervorgängen, darunter beispielsweise Bitgrenzenblocktransfers. In einer Ausführungsform werden 2D-Grafikvorgänge jedoch unter Benutzung von einer oder mehr Komponenten einer Grafikverarbeitungsmaschine (GPE) 310 ausgeführt. In manchen Ausführungsformen ist die GPE 310 eine Rechenmaschine zum Ausführen von Grafikvorgängen, darunter dreidimensionale (3D) Grafikvorgänge und Medienvorgänge.
In manchen Ausführungsformen enthält die GPE 310 eine 3D-Pipeline zum Ausführen von 3D-Vorgängen, wie etwa Rendern von dreidimensionalen Bildern und Szenen unter Benutzung von Verarbeitungsfunktionen, die auf primitive 3D-Formen (beispielsweise Rechteck, Dreieck usw.) einwirken. Die 3D-Pipeline 312 enthält programmierbare Elemente und Elemente mit festgelegter Funktion, die verschiedene Aufgaben innerhalb des Elements ausführen und/oder Ausführungsthreads in einem 3D/Mediensubsystem 315 ablegen. Während die 3D-Pipeline 312 zum Ausführen von Medienvorgängen benutzt werden kann, enthält eine Ausführungsform der GPE 310 außerdem eine Medienpipeline 316, die spezifisch zum Ausführen von Medienvorgängen benutzt wird, wie etwa Videonachbearbeitung und Bildoptimierung.
In manchen Ausführungsformen enthält die Medienpipeline 316 Logikeinheiten mit festgelegter Funktion oder programmierbare Logikeinheiten zum Ausführen von einem oder mehr spezialisierten Medienvorgängen, wie etwa Videodecodierbeschleunigung, Videozeilenentflechtung und Videocodierbeschleunigung, anstelle der oder für die Videocodecmaschine 306. In manchen Ausführungsformen enthält die Medienpipeline 316 zusätzlich eine Threadablegeeinheit zum Ablegen von Threads zur Ausführung auf dem 3D/Mediensubsystem 315. Die abgelegten Threads führen Rechnungen für die Medienvorgänge auf einer oder mehr Grafikausführungseinheiten aus, die im 3D/Mediensubsystem 315 enthalten sind.
In manchen Ausführungsformen enthält das 3D/Mediensubsystem 315 Logik zum Ausführen von Threads, die durch die 3D-Pipeline 312 und die Medienpipeline 316 abgelegt wurden. In einer Ausführungsform senden die Pipelines Threadausführungsanforderungen an das 3D/Mediensubsystem 315, das Threadverteilungslogik zum Vermitteln und Verteilen der verschiedenen Anforderungen auf verfügbare Threadausführungsressourcen enthält. Die Ausführungsressourcen enthalten ein Array von Grafikausführungseinheiten zum Verarbeiten der 3D- und Medienthreads. In manchen Ausführungsformen enthält das 3D/Mediensubsystem 315 einen oder mehr interne Caches für Threadanweisungen und -daten. In manchen Ausführungsformen enthält das Subsystem außerdem gemeinsamen Speicher, darunter Register und adressierbaren Speicher, zum gemeinsamen Benutzen von Daten unter Threads, und zum Speichern von Ausgabedaten.
Grafikverarb eitungsmas chine
4 ist ein Blockdiagramm einer Grafikverarbeitungsmaschine 410 eines Grafikprozessors gemäß manchen Ausführungsformen. In einer Ausführungsform ist die Grafikverarbeitungsmaschine (GPE) 410 eine Version der GPE 310, die in 3 gezeigt ist. Elemente von 4 mit dieselben Bezugszeichen (oder -bezeichnungen) wie die Elemente jeglicher anderen Figur hierin können auf jegliche Art und Weise arbeiten oder funktionieren wie jene, die an anderer Stelle hierin beschrieben ist, sind jedoch nicht darauf beschränkt. Beispielsweise sind die 3D-Pipeline 312 und die Medienpipeline 316 von 3 dargestellt. Die Medienpipeline 316 ist in manchen Ausführungsformen der GPE 410 optional und könnte nicht ausdrücklich innerhalb der GPE 410 enthalten sein. Beispielsweise, und in mindestens einer Ausführungsform, ist ein separater Medien- und/oder Bildprozessor an die GPE 410 gekoppelt.
In manchen Ausführungsformen ist die GPE 410 mit einer Befehlsstromvorrichtung 403 verkoppelt oder enthält diese, die der 3D-Pipeline 312 und/oder den Medienpipelines 316 einen Befehlsstrom zuführt. In manchen Ausführungsformen ist die Befehlsstromvorrichtung 403 mit einem Speicher verkoppelt, der ein Systemspeicher sein kann, oder eines oder mehr von internem Cachespeicher und gemeinsam benutztem Cachespeicher. In manchen Ausführungsformen empfängt die Befehlsstromvorrichtung 403 Befehle vom Speicher und sendet die Befehle an die 3D-Pipeline 312 und/oder Medienpipeline 316. Die Befehle sind Anordnungen, die aus einem Ringpuffer abgerufen werden, der Befehle für die 3D-Pipeline 312 und Medienpipeline 316 speichert. In einer Ausführungsform kann der Ringpuffer zusätzlich Batchbefehlspuffer enthalten, die Batches von mehrfachen Befehlen speichern. Die Befehle für die 3D-Pipeline 312 können außerdem Verweise auf im Speicher gespeicherte Daten enthalten, wie etwa u.a. Scheitelpunkt- und Geometriedaten für die 3D-Pipeline 312 und/oder Bilddaten und Speicherobjekte für die Medienpipeline 316. Die 3D-Pipeline 312 und Medienpipeline 316 verarbeiten die Befehle und Daten durch Ausführen von Vorgängen über Logik innerhalb der jeweiligen Pipelines oder durch Absenden von einem oder mehr Ausführungsthreads an ein Grafikkernarray 414.
In verschiedenen Ausführungsformen kann die 3D-Pipeline 312 ein oder mehr Shaderprogramme ausführen, wie etwa Scheitelpunktshader, Geometrieshader, Pixelshader, Fragmentshader, Rechenshader oder andere Shaderprogramme, durch Verarbeiten der Anweisungen und Absenden von Ausführungsthreads an das Grafikkernarray 414. Das Grafikkernarray 414 sieht einen vereinheitlichten Block von Ausführungsressourcen. Mehrzweckausführungslogik (beispielsweise Ausführungseinheiten) innerhalb des Grafikkernarrays 414 enthält Unterstützung für verschiedene 3D-API-Shadersprachen und kann mehrfache simultane Ausführungsthreads ausführen, die mit mehrfachen Shadern assoziiert sind.
In manchen Ausführungsformen enthält das Grafikkernarray 414 außerdem Ausführungslogik zum Ausführen von Medienfunktionen, wie etwa Video- und/oder Bildverarbeitung. In einer Ausführungsform enthalten die Ausführungseinheiten zusätzlich Mehrzwecklogik, die zum Ausführen von parallelen Mehrzweckrechenvorgängen zusätzlich zu Grafikverarbeitungsvorgängen programmierbar ist. Die Mehrzwecklogik kann Verarbeitungsvorgänge parallel zu oder in Verbindung mit Mehrzwecklogik innerhalb des Prozessorkerns bzw. der Prozessorkerne 107 von 1 oder Kern 202A bis 202N, wie in 2, ausführen.
Ausgabedaten, die durch Threads erstellt werden, welche auf dem Grafikkernarray 414 laufen, können Daten an einen Speicher in einem vereinigten Rückgabepuffer (URB) 418 ausgeben. Der URB 418 kann Daten für mehrfache Threads speichern. In manchen Ausführungsformen kann der URB 418 zum Senden von Daten zwischen verschiedenen Threads benutzt werden, die auf dem Grafikkernarray 414 laufen. In manchen Ausführungsformen kann der URB 418 zusätzlich für Synchronisation zwischen Threads auf dem Grafikkernarray und Logik mit festgelegter Funktion innerhalb der Logik 420 mit gemeinsam benutzter Funktion benutzt werden.
In manchen Ausführungsformen ist das Grafikkernarray 414 skalierbar, sodass das Array eine variable Anzahl von Grafikkernen enthält, die jeweils eine variable Anzahl von Ausführungseinheiten basierend auf der Zielleistung und der Leistungsebene der GPE 410 aufweisen. In einer Ausführungsform sind die Ausführungsressourcen dynamisch skalierbar, sodass Ausführungsressourcen nach Bedarf aktiviert oder deaktiviert werden können.
Das Grafikkernarray 414 ist mit der Logik 420 mit gemeinsam benutzter Funktion verkoppelt, die mehrfache Ressourcen enthält, die von den Grafikkernen im Grafikkernarray gemeinsam benutzt werden. Die gemeinsam benutzten Funktionen innerhalb der Logik 420 mit gemeinsam benutzter Funktion sind Hardwarelogikeinheiten, die das Grafikkernarray 414 mit spezialisierter ergänzender Funktionalität versehen. In verschiedenen Ausführungsformen enthält die Logik 420 mit gemeinsam benutzter Funktion u.a. Abtasterlogik 421, Mathematiklogik 422 und Interthreadkommunikationslogik 423. Zusätzlich implementieren manche Ausführungsformen einen oder mehr Caches 425 innerhalb der Logik 420 mit gemeinsam benutzter Funktion. Eine gemeinsam benutzte Funktion wird implementiert, wo der Bedarf an einer gegebenen Spezialfunktion für die Einbeziehung innerhalb des Grafikkernarrays 414 ungenügend ist. Stattdessen wird eine einzelne Instantiierung dieser Spezialfunktion als eine eigenständige Einheit in der Logik 420 mit gemeinsam benutzter Funktion implementiert und von den Ausführungsressourcen innerhalb des Grafikkernarrays 414 gemeinsam benutzt. Der genaue Satz von Funktionen, die vom Grafikkernarray 414 gemeinsam benutzt werden und innerhalb des Grafikkernarrays 414 enthalten sind, variiert von Ausführungsform zu Ausführungsform.
5 ist ein Blockdiagramm einer anderen Ausführungsform eines Grafikprozessors 500. Elemente von 5 mit dieselben Bezugszeichen (oder -bezeichnungen) wie die Elemente jeglicher anderen Figur hierin können auf jegliche Art und Weise arbeiten oder funktionieren wie jene, die an anderer Stelle hierin beschrieben ist, sind jedoch nicht darauf beschränkt.
In manchen Ausführungsformen enthält der Grafikprozessor 500 eine Ringzusammenschaltung 502, ein Pipeline-Frontend 504, eine Medienmaschine 537 und Grafikkerne 580A bis 580N. In manchen Ausführungsformen koppelt die Ringzusammenschaltung 502 den Grafikprozessor an andere Verarbeitungseinheiten, darunter andere Grafikprozessoren oder ein oder mehr Mehrzweckprozessorkerne. In manchen Ausführungsformen ist der Grafikprozessor einer von zahlreichen Prozessoren, die innerhalb eines Mehrkernverarbeitungssystems integriert sind.
In manchen Ausführungsformen empfängt der Grafikprozessor 500 Befehlsbatches über die Ringzusammenschaltung 502. Die eingehenden Befehle werden durch eine Befehlsstromvorrichtung 503 im Pipeline-Frontend 504 interpretiert. In manchen Ausführungsformen enthält der Grafikprozessor 500 skalierbare Ausführungslogik zum Ausführen von 3D-Geometrieverarbeitung und Medienverarbeitung über den (die) Grafikkern(e) 580A bis 580N. Für 3D-Geometrieverarbeitungsbefehle führt die Befehlsstromvorrichtung 503 einer Geometriepipeline 536 Befehle zu. Für mindestens einige Medienverarbeitungsbefehle führt die Befehlsstromvorrichtung 503 die Befehle einem Video-Frontend 534 zu, das mit einer Medienmaschine 537 verkoppelt ist. In manchen Ausführungsformen enthält die Medienmaschine 537 eine Videoqualitätsmaschine (VQE) 530 für Video- und Bildnachbearbeitung und eine Mehrformat-Codierungs-/Decodierungs(MFX)-Maschine 533, um hardwarebeschleunigte Mediendatencodierung und -decodierung bereitzustellen. In manchen Ausführungsformen erzeugt sowohl die Geometriepipeline 536 als auch die Medienpipeline 537 Ausführungsthreads für die Threadausführungsressourcen, die von zumindest einem Grafikkern 580A bereitgestellt werden.
In manchen Ausführungsformen enthält der Grafikprozessor 500 skalierbare Threadausführungsressourcen, die modulare Kerne 580A bis 580N (manchmal als Kernscheiben bezeichnet) aufweisen, welche jeweils mehrfache Teilkerne 550A bis 550N, 560A bis 560N (manchmal als Kernteilscheiben bezeichnet) aufweisen. In manchen Ausführungsformen kann der Grafikprozessor 500 jegliche Anzahl von Grafikkernen 580A bis 580N aufweisen. In manchen Ausführungsformen enthält der Grafikprozessor 500 einen Grafikkern 580A mit mindestens einem ersten Teilkern 550A und einem zweiten Teilkern 560A. In anderen Ausführungsformen ist der Grafikprozessor ein Prozessor mit niedriger Leistung mit einem einzelnen Teilkern (beispielsweise 550A). In manchen Ausführungsformen enthält der Grafikkern 500 mehrfache Grafikkerne 580A bis 580N, die jeweils einen Satz von ersten Teilkernen 550A bis 550N und einen Satz von zweiten Teilkernen 560A bis 560N enthalten. Jeder Teilkern im Satz von ersten Teilkernen 550A bis 550N enthält mindestens einen ersten Satz von Ausführungseinheiten 552A bis 552N und Medien-/Texturabtastern 554A bis 554N. Jeder Teilkern im Satz von zweiten Teilkernen 560A bis 560N enthält mindestens einen zweiten Satz von Ausführungseinheiten 562A bis 562N und Abtastern 564A bis 564N. In manchen Ausführungsformen teilt jeder Teilkern 550A bis 550N, 560A bis 560N einen Satz von gemeinsam benutzten Ressourcen 570A bis 570N. In manchen Ausführungsformen enthalten die gemeinsam benutzten Ressourcen gemeinsam benutzten Cachespeicher und Pixelbetriebslogik. Andere gemeinsam benutzte Ressourcen können ebenfalls in verschiedenen Ausführungsformen des Graphikprozessors enthalten sein.
Ausführungseinheiten
6 stellt Threadausführungslogik 600 dar, die ein Array von Verarbeitungselementen enthält, welche in manchen Ausführungsformen einer GPE eingesetzt werden. Elemente von 6 mit dieselben Bezugszeichen (oder -bezeichnungen) wie die Elemente jeglicher anderen Figur hierin können auf jegliche Art und Weise arbeiten oder funktionieren wie jene, die an anderer Stelle hierin beschrieben ist, sind jedoch nicht darauf beschränkt.
In manchen Ausführungsformen enthält die Threadausführungslogik 600 einen Shaderprozessor 602, einen Threadverteiler 604, einen Anweisungscache 606, ein skalierbares Ausführungseinheitsarray mit mehreren Ausführungseinheiten 608A bis 608N, einen Abtaster 610, einen Datencache 612 und einen Datenport 614. In einer Ausführungsform kann das skalierbare Ausführungseinheitsarray durch Aktivieren oder Deaktivieren von einer oder mehr Ausführungseinheiten (beispielsweise jegliche Ausführungseinheit 608A, 608B, 608C, 608D bis 608N-1 und 608N) basierend auf den Rechenanforderungen einer Arbeitslast dynamisch skalieren. In einer Ausführungsform sind die enthaltenen Komponenten über eine Zusammenschaltungsstruktur zusammengeschaltet, die mit jeder der Komponenten verbindet. In manchen Ausführungsformen enthält die Threadausführungslogik 600 eine oder mehr Verbindungen mit dem Speicher, wie etwa Systemspeicher oder Cachespeicher, über eines oder mehr von Anweisungscache 606, Datenport 614, Abtaster 610 und Ausführungseinheiten 608A bis 608N. In manchen Ausführungsformen ist jede Ausführungseinheit (beispielsweise 608A) eine eigenständige programmierbare Mehrzweckrecheneinheit, die zum Ausführen von mehrfachen simultanen Hardwarethreads während des parallelen Verarbeitens von mehrfachen Datenelementen für jeden Thread imstande ist. In verschiedenen Ausführungsformen ist das Array von Ausführungseinheiten 608A bis 608N zum Beinhalten von jeglicher Anzahl von individuellen Ausführungseinheiten skalierbar.
In manchen Ausführungsformen werden die Ausführungseinheiten 608A bis 608N vornehmlich zum Ausführen von Shaderprogrammen benutzt. Ein Shaderprozessor 602 kann die verschiedenen Shaderprogramme verarbeiten und Ausführungsthreads, die mit den Shaderprogrammen assoziiert sind, über einen Threadverteiler 604 verteilen. In einer Ausführungsform enthält der Threadverteiler Logik zum Vermitteln von Threadinitiierungsanforderungen von den Grafik- und Medienpipelines und Instantiieren der angeforderten Threads auf einer oder mehr Ausführungseinheiten der Ausführungseinheiten 608A bis 608N. Beispielsweise kann die Geometriepipeline (beispielsweise 536 von 5) Scheitelpunkt-, Tesselierungs- oder Geometrieshader an die Threadausführungslogik 600 (6) zum Verarbeiten verteilen. In manchen Ausführungsformen kann der Threadverteiler 604 außerdem Threadablegeanforderungen von den laufenden Shaderprogrammen in der Laufzeit verarbeiten.
In manchen Ausführungsformen unterstützen die Ausführungseinheiten 608A bis 608N einen Anweisungssatz, der native Unterstützung für zahlreiche standardmäßige 3D-Grafikshaderanweisungen enthält, sodass Shaderprogramme von Grafikbibliotheken (beispielsweise Direct 3D und OpenGL) mit einer minimalen Übersetzung ausgeführt werden. Die Ausführungseinheiten unterstützen Scheitelpunkt- und Geometrieverarbeitung (Beispielsweise Scheitelpunktprogramme, Geometrieprogramme, Scheitelpunktshader), Pixelverarbeitung (beispielsweise Pixelshader, Fragmentshader) und Mehrzweckverarbeitung (beispielsweise Rechen- und Medienshader). Jede der Ausführungseinheiten 608A bis 608N ist zu bereichsübergreifender Single Instruction Multiple Data-Verarbeitung (SIMD-Verarbeitung) imstande, und Multithreadbetrieb ermöglicht eine effiziente Ausführungsumgebung angesichts Speicherzugriffen mit höherer Latenz. Jeder Hardwarethread innerhalb jeder Ausführungseinheit weist eine dedizierte Registerdatei mit hoher Bandbreite und assoziierten unabhängigen Threadzustand auf. Die Ausführung ist bereichsübergreifend pro Takt zu Pipelines, die zu Ganzzahl-, Gleitkommavorgängen mit einfacher und doppelter Genauigkeit, SIMD-Verzweigungsfähigkeit, logischen Vorgängen, transzendenten Vorgängen und anderen vermischten Vorgängen imstande sind. Während des Wartens auf Daten vom Speicher oder einer der gemeinsam benutzten Funktionen bewirkt Abhängigkeitslogik innerhalb der Ausführungseinheiten 608A bis 608N, dass ein wartender Thread in den Schlafmodus geht, bis die angeforderten Daten zurückgeliefert wurden. Während der wartende Thread im Schlafmodus ist, können Hardwareressourcen dem Verarbeiten von anderen Threads gewidmet werden. Beispielsweise kann während einer Verzögerung, die mit einem Scheitelpunktshadervorgang assoziiert ist, eine Ausführungseinheit Vorgänge für einen Pixelshader, Fragmentshader oder eine andere Art von Shaderprogramm, darunter ein anderer Scheitelpunktshader, ausführen.
Jede Ausführungseinheit der Ausführungseinheiten 608A bis 608N wirkt auf Arrays von Datenelementen ein. Die Anzahl von Datenelementen ist die „Ausführungsgröße“ oder die Anzahl von Kanälen für die Anweisung. Ein Ausführungskanal ist eine logische Ausführungseinheit für Datenelementzugriff, Maskierung und Flusssteuerung innerhalb von Anweisungen. Die Anzahl von Kanälen kann von der Anzahl von physikalischen Arithmetiklogikeinheiten (ALUs) oder Gleitkommaeinheiten (FPUs) für einen bestimmten Grafikprozessor abhängen. In manchen Ausführungsformen unterstützen die Ausführungseinheiten 608A bis 608N Ganzzahl- und Gleitkommadatentypen.
Der Ausführungseinheitsanweisungssatz enthält SIMD-Anweisungen. Die verschiedenen Datenelemente können als ein gepackter Datentyp in einem Register gespeichert werden, und die Ausführungseinheit verarbeitet die verschiedenen Elemente basierend auf der Datengröße der Elemente. Beispielsweise werden beim Bearbeiten eines 256 Bit breiten Vektors die 256 Bits des Vektors in einem Register gespeichert, und die Ausführungseinheit bearbeitet den Vektor als vier separate 64-Bit-gepackte Datenelemente (Datenelemente in Vierfachwortgröße (QW)), acht separate 32-Bit-gepackte Datenelemente (Datenelemente in Doppelwortgröße (DW)), sechzehn separate 16-Bit-gepackte Datenelemente (Datenelemente in Wortgröße (W)) oder zweiunddreißig separate 8-Bit-Datenelemente (Datenelemente in Bytegröße (B)). Es sind jedoch andere Vektorbreiten und Registergrößen möglich.
Ein oder mehr interne Anweisungscaches (beispielsweise 606) sind in der Threadausführungslogik 600 zum Zwischenspeichern von Threadanweisungen für die Ausführungseinheiten enthalten. In manchen Ausführungsformen sind ein oder mehr Datencaches (beispielsweise 612) zum Zwischenspeichern von Threaddaten während der Threadausführung enthalten. In manchen Ausführungsformen ist ein Abtaster 610 zum Vorsehen von Texturabtastung für 3D-Vorgänge und Medienabtastung für Medienvorgänge enthalten. In manchen Ausführungsformen enthält der Abtaster 610 spezialisierte Textur- oder Medienabtastfunktionalität zum Verarbeiten von Textur- oder Mediendaten während des Abtastprozesses vor dem Zuführen der abgetasteten Daten zu einer Ausführungseinheit.
Während der Ausführung senden die Grafik- und Medienpipelines Threadinitiationsanforderungen über Threadablege- und -verteilungslogik an die Threadausführungslogik 600. Wenn eine Gruppe von geometrischen Objekten verarbeitet und in Pixeldaten gerastert wurde, wird Pixelprozessorlogik (beispielsweise Pixelshaderlogik, Fragmentshaderlogik usw.) innerhalb des Shaderprozessors 602 zum weiteren Errechnen von Ausgabeinformation und Bewirken, dass Ergebnisse in Ausgabeflächen (beispielsweise Farbpuffer, Tiefenpuffer, Stencil-Puffer usw.) geschrieben werden, aufgerufen. In manchen Ausführungsformen berechnet ein Pixelshader oder Fragmentshader die Werte der verschiedenen Scheitelpunktattribute, die über das gerasterte Objekt hinweg interpoliert werden sollen. In manchen Ausführungsformen führt dann Pixelprozessorlogik innerhalb des Shaderprozessors 602 ein von der Anwendungsprogrammierschnittstelle (API) geliefertes Pixel- oder Fragmentshaderprogramm aus. Zum Ausführen des Shaderprogramms verteilt der Shaderprozessor 602 Threads über den Threadverteiler 604 an eine Ausführungseinheit (beispielsweise 608A). In manchen Ausführungsformen benutzt der Pixelshader 602 Texturabtastlogik im Abtaster 610 zum Zugreifen auf Texturdaten in Texturkarten, die im Speicher gespeichert sind. Arithmetische Vorgänge auf die Texturdaten und die eingegebenen Geometriedaten errechnen Pixelfarbdaten für jedes geometrische Fragment oder Streichen einen oder mehr Pixel aus der weiteren Verarbeitung.
In manchen Ausführungsformen sieht der Datenport 614 einen Speicherzugriffsmechanismus für die Threadausführungslogik 600 zum Ausgeben von verarbeiteten Daten an den Speicher zur Verarbeitung in einer Grafikprozessorausgabeleitung vor. In manchen Ausführungsformen enthält der Datenport 614 einen oder mehr Cachespeicher (beispielsweise Datencache 612), oder ist damit verkoppelt, zum Zwischenspeichern von Daten für Speicherzugriff über den Datenport.
7 ist ein Blockdiagramm, das Grafikprozessoranweisungsformate 700 gemäß manchen Ausführungsformen darstellt. In einer oder mehr Ausführungsformen unterstützen die Grafikprozessorausführungseinheiten einen Anweisungssatz mit Anweisungen in mehrfachen Formaten. Die Kästen mit durchgezogener Linie stellen die Komponenten dar, die im Allgemeinen in einer Ausführungseinheitsanweisung enthalten sind, während die gestrichelten Linien Komponenten enthalten, die optional sind, oder die nur in einem Teilsatz der Anweisungen enthalten sind. In manchen Ausführungsformen ist das beschriebene und dargestellte Anweisungsformat 700 dahingehend Makroanweisungen, dass sie Anweisungen sind, die der Ausführungseinheit zugeführt werden, im Gegensatz zu Mikrovorgängen, die aus Anweisungsdecodierung resultieren, sobald die Anweisung verarbeitet ist.
In manchen Ausführungsformen unterstützen die Grafikprozessorausführungseinheiten nativ in einem 128-Bit-Anweisungsformat 710. Ein komprimiertes 64-Bit-Anweisungsformat 730 ist für manche Anweisungen basierend auf der ausgewählten Anweisung, Anweisungsoptionen und Anzahl von Operanden verfügbar. Das native 128-Bit-Anweisungsformat 710 sieht Zugriff auf alle Anweisungsoptionen vor, während manche Optionen und Vorgänge im 64-Bit-Anweisungsformat 730 beschränkt sind. Die nativen Anweisungen, die im 64-Bit-Anweisungsformat 730 verfügbar sind, variieren je nach Ausführungsform. In manchen Ausführungsformen wird die Anweisung zum Teil unter Benutzung eines Satzes von Indexwerten in einem Indexfeld 713 komprimiert. Die Ausführungseinheitshardware bezieht sich auf einen Satz von Komprimierungstabellen basierend auf den Indexwerten und benutzt die Komprimierungstabellenausgaben zum Rekonstruieren einer nativen Anweisung im 128-Bit-Anweisungsformat 710.
Für jedes Format definiert Anweisungsoperationscode 712 den Vorgang, den die Ausführungseinheit ausführen soll. Die Ausführungseinheiten führen jede Anweisung parallel über die mehrfachen Datenelemente von jedem Operanden hinweg aus. Beispielsweise führt die Ausführungseinheit in Reaktion auf eine Addieren-Anweisung einen simultanen Addier-Vorgang über jeden Farbkanal hinweg aus, der ein Texturelement oder Bildelement darstellt. Vorgabemäßig führt die Ausführungseinheit jede Anweisung über alle Datenkanäle der Operanden hinweg aus. In manchen Ausführungsformen ermöglicht ein Anweisungssteuerfeld 714 Steuerung von bestimmten Ausführungsoptionen, wie etwa Kanalauswahl (beispielsweise Voraussage) und Datenkanalreihenfolge (beispielsweise Wiederordnen). Für Anweisungen im 128-Bit-Anweisungsformat 710 begrenzt ein Exec-Größenfeld 716 die Anzahl von Datenkanälen, die parallel ausgeführt werden. In manchen Ausführungsformen ist das Exec-Größenfeld 716 zur Benutzung im 64-Bit-Komprimierungsanweisungsformat 730 nicht verfügbar.
Manche Ausführungseinheitsanweisungen weisen bis zu drei Operanden auf, darunter zwei Quelloperanden, src0 720, srcl 722, und ein Ziel 718. In manchen Ausführungsformen unterstützen die Ausführungseinheiten duale Zielanweisungen, wenn eines der Ziele beinhaltet ist. Datenmanipulationsanweisungen können einen dritten Quelloperanden (beispielsweise SRC2 724) aufweisen, wenn der Anweisungsoperationscode 712 die Anzahl von Quelloperanden bestimmt. Der letzte Quelloperand einer Anweisung kann ein unmittelbarer (beispielsweise hartcodierter) Wert sein, der mit der Anweisung weitergegeben wird.
In manchen Ausführungsformen enthält das 128-Bit-Anweisungsformat 710 ein Zugriffs-/Adressmodusfeld 726, das beispielsweise spezifiziert, ob direkter Registeradressmodus oder indirekter Registeradressmodus benutzt wird. Wenn direkter Registeradressmodus benutzt wird, wird die Registeradresse von einem oder mehr Operanden direkt durch Bits in der Anweisung vorgesehen.
In manchen Ausführungsformen enthält das 128-Bit-Anweisungsformat 710 ein Zugriffs-/Adressmodusfeld 726, das einen Adressmodus und/oder einen Zugriffsmodus für die Anweisung spezifiziert. In einer Ausführungsform wird der Zugriffsmodus zum Definieren einer Datenzugriffsausrichtung für die Anweisung benutzt. Manche Ausführungsformen unterstützen Zugriffsmodi, die einen ausgerichteten 16-Byte-Zugriffsmodus und einen ausgerichteten 1-Byte-Zugriffsmodus enthalten, wobei die Byteausrichtung des Zugriffsmodus die Zugriffsausrichtung der Anweisungsoperanden bestimmt. Beispielsweise kann die Anweisung, wenn sie in einem ersten Modus ist, byte-ausgerichtetes Adressieren für Quell- und Zieloperanden benutzen, und wenn sie in einem zweiten Modus ist, kann die Anweisung 16-byte-ausgerichtetes zum Adressieren für alle Quell- und Zieloperanden benutzen.
In einer Ausführungsform bestimmt der Adressmodusabschnitt des Zugriffs-/Adressmodusfelds 726, ob die Anweisung direktes oder indirektes Adressieren benutzen soll. Wenn direkter Registeradressiermodus benutzt wird, sehen Bits in der Anweisung die Registeradresse von einem oder mehr Operanden direkt vor. Wenn indirekter Registeradressmodus benutzt wird, kann die Registeradresse von einem oder mehr Operanden basierend auf einem Adressregisterwert und einem unmittelbaren Adressfeld in der Anweisung errechnet werden.
In manchen Ausführungsformen sind Anweisungen basierend auf Bitfeldern des Operationscodes 712 zum Vereinfachen von Operationscodedecodieren 740 gruppiert. Für einen 8-Bit-Operationscode ermöglichen es die Bits 4, 5 und 6 der Ausführungseinheit, den Operationscodetyp zu bestimmen. Die genaue, gezeigte Operationscodegruppierung ist lediglich ein Beispiel. In manchen Ausführungsformen enthält eine Bewegungs- und Logikoperationscodegruppe 742 Datenbewegung und logische Anweisungen (beispielsweise bewegen (mov), vergleichen (cmp)). In manchen Ausführungsformen teilt sich die Bewegungs- und Logikgruppe 742 die fünf wichtigsten Bits (MSB), wobei Bewegungsanweisungen (mov) in der Form von 0000xxxxb sind und Logikanweisungen in der Form von 0001xxxxb sind. Eine Flusssteueranweisungsgruppe 744 (beispielsweise aufrufen, springen (jmp)) enthält Anweisungen in der Form von 0010xxxxb (beispielsweise 0x20). Eine vermischte Anweisungsgruppe 746 enthält eine Mischung von Anweisungen, darunter Synchronisationsanweisungen (beispielsweise warten, senden) in der Form von 0011xxxxb (beispielsweise 0x30). Eine parallele Mathematikanweisungsgruppe 748 enthält komponentenweise Arithmetikanweisungen (beispielsweise addieren, multiplizieren (mul)) in der Form von 0100xxxxb (beispielsweise 0x40). Die parallele Mathematikgruppe 148 führt die arithmetischen Vorgänge parallel über Datenkanäle hinweg aus. Die Vektormathematikgruppe 750 enthält arithmetische Anweisungen (beispielsweise dp4) in der Form von 0101xxxxb (beispielsweise 0x50). Die Vektormathematikgruppe führt Arithmetik, wie etwa Skalarproduktberechnungen, auf Vektoroperanden aus.
Grafikpipeline
8 ist ein Blockdiagramm einer anderen Ausführungsform eines Grafikprozessors 800. Elemente von 8 mit dieselben Bezugszeichen (oder -bezeichnungen) wie die Elemente jeglicher anderen Figur hierin können auf jegliche Art und Weise arbeiten oder funktionieren wie jene, die an anderer Stelle hierin beschrieben ist, sind jedoch nicht darauf beschränkt.
In manchen Ausführungsformen enthält der Grafikprozessor 800 eine Grafikpipeline 820, eine Medienpipeline 830, eine Anzeigenmaschine 840, Threadausführungslogik 850 und eine Renderausgabepipeline 870. In manchen Ausführungsformen ist der Grafikprozessor 800 ein Grafikprozessor innerhalb eines Mehrkernausführungssystems, das einen oder mehr Mehrzweckverarbeitungskerne enthält. Der Grafikprozessor wird durch Registerschreiben in ein oder mehr Steuerregister (nicht gezeigt) oder über Befehle gesteuert, die über eine Ringzusammenschaltung 802 an den Grafikprozessor 800 ausgegeben werden. In manchen Ausführungsformen koppelt die Ringzusammenschaltung 802 den Grafikprozessor 800 an andere Verarbeitungskomponenten, wie etwa andere Grafikprozessoren oder Mehrzweckprozessoren. Befehle von der Ringzusammenschaltung 802 werden durch eine Befehlsstromvorrichtung 803 interpretiert, die individuellen Komponenten der Grafikpipeline 820 oder Medienpipeline 830 Anweisungen zuführt.
In manchen Ausführungsformen leitet die Befehlsstromvorrichtung 803 den Betrieb eines Scheitelpunktabholers 805, der Scheitelpunktdaten aus dem Speicher ausliest und Scheitelpunktverarbeitungsbefehle ausführt, die von der Befehlsstromvorrichtung 803 zugeführt werden. In manchen Ausführungsformen führt der Scheitelpunktabholer 805 Scheitelpunktdaten einem Scheitelpunktshader 807 zu, der Koordinatenraumtransformation und Beleuchtungsvorgänge auf jeden Scheitelpunkt ausführt. In manchen Ausführungsformen führen der Scheitelpunktabholer 805 und der Scheitelpunktshader 807 Scheitelpunktverarbeitungsanweisungen durch Verteilen von Ausführungsthreads auf Ausführungseinheiten 852A bis 852B über einen Threadverteiler 831 aus.
In manchen Ausführungsformen sind die Ausführungseinheiten 852A bis 852B ein Array von Vektorprozessoren mit einem Anweisungssatz zum Ausführen von Grafik- und Medienvorgängen. In manchen Ausführungsformen weisen die Ausführungseinheiten 852A bis 852B einen beigefügten L1-Cache 851 auf, der für jedes Array spezifisch ist oder von den Arrays gemeinsam benutzt wird. Der Cache kann als Datencache, Anweisungscache oder einzelner Cache konfiguriert sein, der zum Enthalten von Daten und Anweisungen in verschiedenen Partitionen partitioniert ist.
In manchen Ausführungsformen enthält die Grafikpipeline 820 Tesselierungskomponenten zum Ausführen von hardwarebeschleunigter Tesselierung von 3D-Objekten. In manchen Ausführungsformen konfiguriert ein programmierbarer Rumpfshader 811 die Tesselierungsvorgänge. Ein programmierbarer Domainshader 817 versieht Backend-Bewertung von Tesselierungsausgabe. Ein Tesselator 813 arbeitet unter der Leitung des Rumpfshaders 811 und enthält spezielle Logik zum Erzeugen eines Satzes von detaillierten geometrischen Objekten basierend auf einem groben geometrischen Modell, der der Grafikpipeline 820 als Eingabe zugeführt wird. In manchen Ausführungsformen können, wenn keine Tesselierung benutzt wird, Tesselierungskomponenten (beispielsweise der Rumpfshader 811, Tesselator 813 und Domainshader 817) umgangen werden.
In manchen Ausführungsformen können komplette geometrische Objekte durch einen Geometrieshader 819 über einen oder mehr Threads, die an die Ausführungseinheiten 852A bis 852B verteilt werden, verarbeitet werden oder direkt zum Clipper 829 weitergeleitet werden. In manchen Ausführungsformen wirkt der Geometrieshader auf gesamte geometrische Objekte ein, statt auf Scheitelpunkte oder Patches von Scheitelpunkten wie in vorhergehenden Stufen der Grafikpipeline. Wenn die Tesselierung deaktiviert ist, empfängt der Geometrieshader 819 Eingabe vom Scheitelpunktshader 807. In manchen Ausführungsformen ist der Geometrieshader 819 durch ein Geometrieshaderprogramm zum Ausführen von Geometrietesselierung programmierbar, wenn die Tesselierungseinheiten deaktiviert sind.
Vor der Rasterung verarbeitet ein Clipper 829 Scheitelpunktdaten. Der Clipper 829 kann ein Clipper mit festgelegter Funktion oder ein Clipper mit Clip- und Geometrieshaderfunktionen sein. In manchen Ausführungsformen verteilt eine Rasterer- und Tiefentestkomponente 873 in der Renderausgabepipeline 870 Pixelshader zum Umwandeln der geometrischen Objekte in ihre Pro-Pixel-Darstellungen. In manchen Ausführungsformen ist Pixelshaderlogik in der Threadausführungslogik 850 enthalten. In manchen Ausführungsformen kann eine Anwendung die Rasterer- und Tiefentestkomponente 873 umgehen und über eine Stromausgangseinheit 823 auf nicht gerasterte Scheitelpunktdaten zugreifen.
Der Grafikprozessor 800 weist einen Zusammenschaltungsbus, eine Zusammenschaltungsstruktur oder einen anderen Zusammenschaltungsmechanismus, der Daten- und Nachrichtenweiterleitung unter den hauptsächlichen Komponenten des Prozessors ermöglicht. In manchen Ausführungsformen sind die Ausführungseinheiten 852A bis 852B und (ein) assoziierte(r) Cache(s) 851, ein Textur- und Medienabtaster 854 und ein Textur- /Abstastercache 858 über einen Datenport 856 zum Ausführen von Speicherzugriff und Kommunizieren mit Renderausgabepipelinekomponenten des Prozessors zusammengeschaltet. In manchen Ausführungsformen weisen der Abtaster 854, die Caches 851, 858 und die Ausführungseinheiten 852A bis 852B jeweils separate Speicherzugriffspfade auf.
In manchen Ausführungsformen enthält die Renderausgabepipeline 870 eine Rasterer- und Tiefentestkomponente 873, die scheitelpunktbasierte Objekte in assoziierte pixelbasierte Darstellung umwandelt. In manchen Ausführungsformen enthält die Rastererlogik eine Windower-/Maskierereinheit zum Ausführen von Dreiecks- und Linienrasterung mit festgelegter Funktion. Ein assoziierter Rendercache 878 und Tiefencache 879 sind in manchen Ausführungsformen ebenfalls verfügbar. Eine Pixelvorgangskomponente 877 führt pixelbasierte Vorgänge auf die Daten aus, obwohl in manchen Fällen Pixelvorgänge, die mit 2D-Vorgängen assoziiert sind (beispielsweise Bitblockbildtransfers mit Abmischen), durch die 2D-Maschine 841 ausgeführt werden oder zur Anzeigezeit durch die Anzeigensteuerung 843 unter Benutzung von Überlagerungsanzeigeebenen ersetzt werden. In manchen Ausführungsformen ist ein gemeinsam benutzter L3-Cache 875 für alle Grafikkomponenten verfügbar, wodurch die gemeinsame Benutzung von Daten ohne die Benutzung eines Systemhauptspeichers ermöglicht ist.
In manchen Ausführungsformen enthält die Grafikprozessormedienpipeline 830 eine Medienmaschine 837 und ein Video-Frontend 834. In manchen Ausführungsformen empfängt das Video-Frontend 834 Pipelinebefehle von der Befehlsstromvorrichtung 803. In manchen Ausführungsformen enthält die Medienpipeline 830 eine separate Befehlsstromvorrichtung. In manchen Ausführungsformen verarbeitet das Video-Frontend 834 Medienbefehle vor dem Senden des Befehls an die Medienmaschine 837. In manchen Ausführungsformen enthält die Medienmaschine 837 Threadablegefunkionalität zum Ablegen von Threads zur Verteilung an die Threadausführungslogik 850 über den Threadverteiler 831.
In manchen Ausführungsformen enthält der Grafikprozessor 800 eine Anzeigenmaschine 840. In manchen Ausführungsformen ist die Anzeigenmaschine 840 extern zum Prozessor 800 und ist mit dem Grafikprozessor über die Ringzusammenschaltung 802 oder eine/n andere/n Zusammenschaltungsbus oder -struktur verkoppelt. In manchen Ausführungsformen enthält die Anzeigenmaschine 840 eine 2D-Maschine 841 und eine Anzeigensteuerung 843. In manchen Ausführungsformen enthält die Anzeigenmaschine 840 spezielle Logik, die zum unabhängigen Betreiben der 3D-Pipeline imstande ist. In manchen Ausführungsformen ist die Anzeigensteuerung 843 mit einem Anzeigengerät (nicht gezeigt) verkoppelt, das ein systemintegriertes Anzeigengerät sein kann, wie etwa in einem Laptopcomputer, oder ein externes Anzeigengerät, das über einen Anzeigengerätverbinder angeschlossen ist.
In manchen Ausführungsformen sind die Grafikpipeline 820 und die Medienpipeline 830 zum Ausführen von Vorgängen basierend auf mehrfachen Grafik- und Medienprogrammierschnittstellen konfigurierbar und für keinerlei Anwendungsprogrammierschnittstelle (API) spezifisch. In manchen Ausführungsformen übersetzt Treibersoftware für den Grafikprozessor API-Aufrufe, die für eine bestimmte Grafik- oder Medienbibliothek spezifisch sind, in Befehle, die durch den Grafikprozessor verarbeitet werden können. In manchen Ausführungsformen ist Unterstützung für die Open Graphics Library (OpenGL), Open Computing Language (OpenCL) und/oder Vulkan Grafik- und rechen-API, alle von der Khronos Group, vorgesehen. In manchen Ausführungsformen kann außerdem Unterstützung für die Direct3D-Bibliothek der Microsoft Corporation vorgesehen. In manchen Ausführungsformen kann eine Kombination dieser Bibliotheken unterstützt werden. Außerdem kann Unterstützung für die Open Source Computer Vision Library (OpenCV) vorgesehen sein. Eine künftige API mit einer kompatiblen 3D-Pipeline würde ebenfalls unterstützt werden, wenn eine Abbildung von der Pipeline der künftigen API auf die Pipeline des Grafikprozessors erzeugt werden kann.
Grafikpipelineprogrammierung
9A ist ein Blockdiagramm, das ein Grafikprozessorbefehlsformat 900 gemäß manchen Ausführungsformen darstellt. 9B ist ein Blockdiagramm, das eine Grafikprozessorbefehlssequenz 910 gemäß einer Ausführungsform darstellt. Die Kästen mit durchgezogenen Linien in 9A stellen die Komponenten dar, die im Allgemeinen in einem Grafikbefehl enthalten sind, während die gestrichelten Linien Befehle enthalten, die optional sind oder nur in einem Teilsatz der Grafikbefehle enthalten sind. Das beispielhafte Grafikprozessorbefehlsformat 900 von 9A enthält Datenfelder zum Identifizieren eines Zielclient 902 des Befehls, eines Befehlsoperationscodes (Opcode) 904 und der relevanten Daten 906 für den Befehl. Ein Sub-Opcode 905 und eine Befehlsgröße 908 sind ebenfalls in manchen Befehlen enthalten.
In manche Ausführungsformen spezifiziert der Client 902 die Clienteinheit des Grafikgeräts, das die Befehlsdaten verarbeitet. In manchen Ausführungsformen prüft ein Grafikprozessorbefehlsparser das Clientfeld jeden Befehls, um das weitere Verarbeiten des Befehls zu konditionieren und die Befehlsdaten an die zweckdienliche Clienteinheit zu leiten. In manchen Ausführungsformen enthalten die Grafikprozessorclienteinheiten eine Speicherschnittstelleneinheit, eine Rendereinheit, eine 2D-Einheit, eine 3D-Einheit und eine Medieneinheit. Jede Clienteinheit weist eine entsprechende Verarbeitungseinheit auf, die die Befehle verarbeitet. Wenn der Befehl durch die Clienteinheit empfangen wird, liest die Clienteinheit den Opcode 904 und, falls vorhanden, den Sub-Opcode 905 zum Bestimmen des auszuführenden Vorgangs aus. Die Clienteinheit führt den Befehl unter Benutzung von Information im Datenfeld 906 aus. Für manche Befehle wird eine explizite Befehlsgröße 908 zum Spezifizieren der Größe des Befehls erwartet. In manchen Ausführungsformen bestimmt der Befehlsparser die Größe von mindestens einigen der Befehle basierend auf dem Befehls-Opcode automatisch. In manchen Ausführungsformen sind Befehle über ein Mehrfaches eines Doppelworts ausgerichtet.
Das Ablaufdiagramm in 9B zeigt eine beispielhafte Grafikprozessorbefehlssequenz 910. In manchen Ausführungsformen nutz Software oder Firmware eines Datenverarbeitungssystems, das eine Ausführungsform eines Grafikprozessors aufweist, eine Version der gezeigten Befehlssequenz zum Einstellen, Ausführen und Beenden eines Satzes von Grafikvorgängen. Eine Abtastbefehlssequenz ist nur zu Beispielszwecken gezeigt und beschrieben, da Ausführungsformen nicht auf diese spezifischen Befehle oder auf diese Befehlssequenz beschränkt sind. Zudem können die Befehle als Befehlsbatch in einer Befehlssequenz ausgegeben werden, sodass der Grafikprozessor die Befehlssequenz in zumindest teilweise Gleichzeitigkeit verarbeitet.
In manchen Ausführungsformen kann die Grafikprozessorbefehlssequenz 910 mit einem Pipelineräumungsbefehl 912 beginnen, um zu bewirken, dass jegliche aktive Grafikpipeline die derzeit anhängigen Befehle für die Pipeline zu vollenden. In manchen Ausführungsformen arbeiten die 3D-Pipeline 922 und die Medienpipeline 924 nicht gleichzeitig. Die Pipelineräumung wird ausgeführt, um zu bewirken, dass die aktive Grafikpipeline jegliche anhängigen Befehle vollendet. In Reaktion auf eine Pipelineräumung pausiert der Befehlsparser für den Grafikprozessor die Befehlsverarbeitung, bis die aktiven Zeichenmaschinen anhängige Vorgänge abschließen und die relevanten Lesecaches annulliert sind. Optional können jegliche Daten, die im Rendercache als „unrein“ markiert sind, zum Speicher geräumt werden. In manchen Ausführungsformen kann der Pipelineräumungsbefehl für Pipelinesynchronisation oder vor dem Versetzen des Grafikprozessors in einen Zustand mit niedriger Leistung benutzt werden.
In manchen Ausführungsformen wird ein Pipelineauswahlbefehl 913 benutzt, wenn eine Befehlssequenz erfordert, dass der Grafikprozessor explizit zwischen Pipeline umschaltet. In manchen Ausführungsformen ist ein Pipelineauswahlbefehl 913 nur einmal innerhalb eines Ausführungskontexts vor dem Ausgeben von Pipelinebefehlen erforderlich, solange der Kontext nicht zum Ausgeben von Befehlen für beide Pipelines dient. In manchen Ausführungsformen ist ein Pipelineräumungsbefehl 912 unmittelbar vor einer Pipelineumschaltung über den Pipelineauswahlbefehl 913 erforderlich.
In manchen Ausführungsformen konfiguriert ein Pipelinesteuerbefehl 914 eine Grafikpipeline für den Betrieb und wird zum Programmieren der 3D-Pipeline 922 und der Medienpipeline 924 benutzt. In manchen Ausführungsformen konfiguriert der Pipelinesteuerbefehl 914 den Pipelinezustand für die aktive Pipeline. In einer Ausführungsform wird der Pipelinesteuerbefehl 914 für Pipelinesynchronisation und zum Löschen von Daten aus einem oder mehr Cachespeichern innerhalb der aktiven Pipeline vor dem Verarbeiten eines Befehlsbatchs benutzt.
In manchen Ausführungsformen werden Befehle für den Rückgabepufferzustand 916 zum Konfigurieren eines Satzes von Rückgabepuffern für die jeweiligen Pipelines zum Schreiben von Daten benutzt. Manche Pipelinevorgänge erfordern die Zuteilung, Auswahl oder Konfiguration von einem oder mehr Rückgabepuffern, in die die Vorgänge Zwischendaten während des Verarbeitens schreiben. In manchen Ausführungsformen benutzt der Grafikprozessor außerdem einen oder mehr Rückgabepuffer zum Speichern von Ausgabedaten und zum Ausführen von Cross-Thread-Kommunikation. In manchen Ausführungsformen beinhaltet Konfigurieren des Rückgabepufferzustands 916 Auswählen der Größe und Anzahl von Rückgabepuffern zur Benutzung für einen Satz von Pipelinevorgängen.
Die restlichen Befehle in der Befehlssequenz unterscheiden sich basierend auf der aktiven Pipeline für Vorgänge. Basierend auf einer Pipelinebestimmung 920 ist die Befehlssequenz darauf zugeschnitten, dass die 3D-Pipeline 922 mit dem 3D-Pipelinezustand 930 beginnt oder die Medienpipeline 924 am Medienpipelinezustand 940 beginnt.
Die Befehle zum Konfigurieren des 3D-Pipelinezustands 930 enthalten 3D-Zustandseinestellungsbefehle für Scheitelpunktpufferzustands-, Scheitelpunktelementzustands-, Konstantfarbzustands-, Tiefenpufferzustands- und andere Zustandsvariablen, die konfiguriert werden müssen, bevor 3D-Primitivbefehle verarbeitet werden. Die Werte diese Befehle werden mindestens teilweise basierend auf der bestimmten API in Gebrauch bestimmt. In manchen Ausführungsformen sind Befehle des 3D-Pipelinezustands 930 außerdem zum selektiven Deaktivieren oder Umgehen von bestimmten Pipelineelementen imstande, wenn diese Elemente nicht benutzt werden.
In manchen Ausführungsformen wird der 3D-Primitivbefehl 932 zum Einsenden von 3D-Primitiven benutzt, die durch die 3D-Pipeline verarbeitet werden sollen. Befehle und assoziierte Parameter, die dem Grafikprozessor über den 3D-Primitivbefehl zugeführt werden, werden an die Scheitelpunktabholfunktion in der Grafikpipeline weitergeleitet. Die Scheitelpunktabholfunktion benutzt die Daten des 3D-Primitivbefehls 932 zum Erzeugen von Scheitelpunktdatenstrukturen. Die Scheitelpunktdatenstrukturen werden in einem oder mehr Rückgabepuffern gespeichert. In manchen Ausführungsformen wird der 3D-Primitivbefehl 932 zum Ausführen von Scheitelpunktvorgängen auf 3D-Primitive über Scheitelpunktshader benutzt. Zum Verarbeiten von Scheitelpunktshadern verteilt die 3D-Pipeline 922 Shaderausführungsthreads an Grafikprozessorausführungseinheiten.
In manchen Ausführungsformen wird die 3D-Pipeline 922 über einen Ausführungsbefehl 934 oder -ereignis angesteuert. In manchen Ausführungsformen löst Schreiben ins Register Befehlsausführung aus. In manchen Ausführungsformen wird Ausführung über einen „Go“- oder „Kick“-Befehl in der Befehlssequenz ausgelöst. In einer Ausführungsform wird Befehlsausführung unter Benutzung eines Pipelinesynchronisationsbefehls zum Räumen der Befehlssequenz durch die Grafikpipeline ausgelöst. Die 3D-Pipeline führt Geometrieverarbeitung für die 3D-Primitive aus. Sobald die Vorgänge abgeschlossen sind, werden die resultierenden geometrischen Objekte gerastert, und die Pixelmaschine färbt die resultierenden Pixel. Zusätzliche Befehle zum Steuern von Pixelschattierung und Pixel-Backendvorgängen können ebenfalls für diese Vorgänge enthalten sein.
In manchen Ausführungsformen folgt die Grafikprozessorbefehlssequenz 910 dem Pfad der Medienpipeline 924 beim Ausführen von Medienvorgängen. Im Allgemeinen hängt die spezifische Benutzung und Art und Weise des Programmierens für die Medienpipeline 924 von den Medien- oder Rechenvorgängen ab, die ausgeführt werden sollen. Spezifische Mediendecodiervorgänge können während des Mediendecodierens zur Medienpipeline ausgelagert werden. In manchen Ausführungsformen kann die Medienpipeline außerdem umgangen werden, und Mediendecodieren kann insgesamt oder zum Teil unter Benutzung von Ressourcen ausgeführt werden, die durch einen oder mehr Mehrzweckverarbeitungskerne vorgesehen sind. In einer Ausführungsform enthält die Medienpipeline außerdem Elemente für Vorgänge einer Mehrzweckgrafikprozessoreinheit (GPGPU), wobei der Grafikprozessor zum Ausführen von SIMD-Vektorvorgängen unter Benutzung von rechnergestützten Shaderprogrammen benutzt wird, die das Rendern von Grafikprimitiven nicht explizit betreffen.
In manchen Ausführungsformen ist die Medienpipeline 924 ähnlich konfiguriert wie die 3D-Pipeline 922. Ein Satz von Befehlen zum Konfigurieren des Medienpipelinezustands 940 wird an eine Befehlswarteschlange vor den Medienobjektbefehlen 942 verteilt oder darin angeordnet. In manchen Ausführungsformen enthalten Befehle für den Medienpipelinezustand 940 Daten zum Konfigurieren der Medienpipelineelemente, die zum Verarbeiten der Medienobjekte benutzt werden. Dies beinhaltet Daten zum Konfigurieren der Videodecodier- und -codierlogik innerhalb der Medienpipeline, wie etwa Codier- oder Decodierformat. In manchen Ausführungsformen unterstützen Befehle für den Medienpipelinezustand 940 außerdem die Benutzung von einem oder mehr Zeigern zu „indirekten“ Zustandselementen, die einen Batch von Zustandseinstellungen enthalten.
In manchen Ausführungsformen liefern Medienobjektbefehle 942 Zeiger zu Medienobjekten zum Verarbeiten durch die Medienpipeline. Die Medienobjekte enthalten Speicherpuffer, die Videodaten enthalten, welche verarbeitet werden sollen. In manchen Ausführungsformen müssen alle Pipelinezustände vor dem Ausgeben eines Medienobjektbefehls 942 gültig sein. Sobald der Pipelinezustand konfiguriert ist und Medienobjektbefehle 942 in der Warteschlange angeordnet sind, wird die Medienpipeline 924 über einen Ausführungsbefehl 944 oder ein äquivalentes Ausführungsereignis (beispielsweise Registerschreiben) angesteuert. Ausgabe von der Medienpipeline 924 kann dann durch Vorgänge nachbearbeitet werden, die durch die 3D-Pipeline 922 oder die Medienpipeline 924 vorgesehen sind. In manchen Ausführungsformen werden GPGPU-Vorgänge ähnlich wie Medienvorgänge konfiguriert und ausgeführt.
Grafiksoftwarearchitektur
10 stellt eine beispielhafte Grafiksoftwarearchitektur für ein Datenverarbeitungssystem 1000 gemäß manchen Ausführungsformen dar. In manchen Ausführungsformen enthält die Softwarearchitektur eine 3D-Grafikanwendung 1010, ein Betriebssystem 1020 und mindestens einen Prozessor 1030. In manchen Ausführungsformen enthält der Prozessor 1030 einen Grafikprozessor 1032 und einen oder mehr Mehrzweckprozessorkern(e) 1034. Die Grafikanwendung 1010 und das Betriebssystem 1020 laufen jeweils im Systemspeicher 1050 des Datenverarbeitungssystems.
In manchen Ausführungsformen enthält die 3D-Grafikanwendung 1010 ein oder mehr Shaderprogramme mit Shaderanweisungen 1012. Die Shadersprachanweisungen können in Shadersprache auf hoher Ebene sein, wie etwa die High Level Shader Language (HLSL) oder die OpenGL Shader Language (GLSL). Die Anwendung enthält außerdem ausführbare Anweisungen 1014 in einer Maschinensprache, die zur Ausführung durch den Mehrzweckprozessorkern 1034 geeignet ist. Die Anwendung enthält außerdem Grafikobjekte 1016, die durch Scheitelpunktdaten definiert sind.
In manchen Ausführungsformen ist das Betriebssystem 1020 ein Microsoft® Windows® der Microsoft Corporation, ein proprietäres UNIX-ähnliches Betriebssystem oder ein UNIX-ähnliches Open-Source-Betriebssystem unter Benutzung einer Variante des Linux-Kernels. Das Betriebssystem 1020 kann eine Grafik-API 1022 unterstützen, wie etwa die Direct3D API, die OpenGL API oder die Vulkan API. Wenn die Direct3D API in Gebrauch ist, benutzt das Betriebssystem 1020 einen Frontend-Shadercompiler 1024 zum Kompilieren jeglicher Shaderanweisungen 1012 in HLSL in eine Shadersprache auf niedrigerer Ebene. Die Kompilation kann eine bedarfsorientierte (Just-in-Time; JIT) Kompilation sein, oder die Anwendung kann Shadervorkompilation ausführen. In manchen Ausführungsformen werden Shader auf hoher Ebene während der Kompilation der 3D-Grafikanwendung 1010 in Shader auf niedriger Ebene kompiliert. In manchen Ausführungsformen sind die Shaderanweisungen 1012 in einer Zwischenform vorgesehen, wie etwa einer Version des Standard Portable Intermediate Representation (SPIR), die von der Vulkan API benutzt wird.
In manchen Ausführungsformen enthält ein Benutzermodusgrafiktreiber 1026 einen Backend-Shadercompiler 1027 zum Umwandeln der Shaderanweisungen 1012 in eine hardwarespezifische Darstellung. Wenn die OpenGL API in Gebrauch ist, werden die Shaderanweisungen 1012 in der GLSL-Sprache auf hoher Ebene einem Benutzermodusgrafiktreiber 1026 zur Kompilation übergeben. In manchen Ausführungsformen benutzt der Benutzermodusgrafiktreiber 1026 Betriebssystemkernelmodusfunktionen 1028 zum Kommunizieren mit einem Kernelmodusgrafiktreiber 1029. In manchen Ausführungsformen kommuniziert der Kernelmodusgrafiktreiber 1029 mit dem Grafikprozessor 1032 zum Verteilen von Befehlen und Anweisungen.
IP- Kernimplementierungen
Ein oder mehr Aspekte von mindestens einer Ausführungsform kann/können durch auf einem maschinenlesbaren Medium gespeicherten, repräsentativen Code implementiert sein, der Logik innerhalb einer integrierten Schaltung, wie etwa einem Prozessor, darstellt und/oder definiert. Beispielsweise kann das maschinenlesbare Medium Anweisungen enthalten, die verschiedene Logik innerhalb des Prozessors darstellt. Wenn sie durch eine Maschine ausgelesen werden, können die Anweisungen bewirken, dass die Maschine die Logik zum Ausführen der hierin beschriebenen Schritte erzeugt. Derartige Darstellungen, als „IP-Kerne“ bekannt, sind wiederverwendbare Einheiten von Logik für eine integrierte Schaltung, die auf einem materiellen, maschinenlesbaren Medium als ein Hardwaremodell gespeichert werden kann, welches die Struktur der integrierten Schaltung beschreibt. Das Hardwaremodell kann verschiedenen Kunden oder Produktionsstätten geliefert werden, die das Hardwaremodell auf Fertigungsmaschinen laden, welche die integrierte Schaltung herstellen. Die integrierte Schaltung kann derart gefertigt werden, dass die Schaltung Vorgänge ausführt, die in Assoziation mit jeglicher der hierin beschriebenen Ausführungsformen beschrieben sind.
11 ist ein Blockdiagramm, das ein IP-Kernentwicklungssystem 1100 darstellt, welches zum Herstellen einer integrierten Schaltung zum Ausführen von Vorgängen gemäß einer Ausführungsform benutzt werden kann. Das IP-Kernentwicklungssystem 1100 kann zum Erzeugen von modularen, wiederverwendbaren Gestaltungen benutzt werden, die in eine größere Gestaltung eingegliedert oder zum Bauen einer gesamten integrierten Schaltung (beispielsweise einer integrierten SOC-Schaltung) benutzt werden können. Eine Gestaltungseinrichtung 1130 kann eine Softwaresimulation 1110 einer IP-Kernentwicklung in einer Programmiersprache auf hoher Ebene (beispielsweise C/C++) erzeugen. Die Softwaresimulation 1110 kann zum Gestalten, Testen und Verifizieren des Verhaltens des IP-Kerns unter Benutzung eines Simulationsmodells 1112 benutzt werden. Das Simulationsmodell 1112 kann Funktions-, Verhaltens- und/oder Timingsimulationen beinhalten. Es kann dann eine Registertransferebenengestaltung (RTL-Gestaltung) 1115 aus dem Simulationsmodell 1112 geschaffen oder synthetisiert werden. Die RTL-Gestaltung 1115 ist eine Abstraktion des Verhaltens der integrierten Schaltung, die den Fluss von digitalen Daten zwischen Hardwareregistern modelliert, darunter die assoziierte Logik, die die modellierten digitalen Signale benutzt. Zusätzlich zu einer RTL-Gestaltung 1115 können Gestaltungen auf niedrigerer Ebene auf der Logikebene oder Transistorebene ebenfalls geschaffen, gestaltet oder synthetisiert werden. Daher können bestimmte Details der anfänglichen Gestaltung und Simulation variieren.
Die RTL-Gestaltung 1115 oder das Äquivalent kann durch die Gestaltungseinrichtung weiter zu einem Hardwaremodell 1120, das in einer Hardwarebeschreibungssprache (HDL) sein kann, oder einer anderen Darstellung von physikalischen Gestaltungsdaten synthetisiert werden. Die HDL kann zum Verifizieren der IP-Kerngestaltung weiter simuliert oder getestet werden. Die IP-Kerngestaltung kann zur Lieferung zu einer Fertigungsstätte 1165 Dritter unter Benutzung eines nichtflüchtigen Speichers 1140 (beispielsweise Festplatte, Flashspeicher oder jegliches nichtflüchtige Speichermedium) gespeichert werden. Alternativ kann die IP-Kerngestaltung (beispielsweise über das Internet) über eine verdrahtete Verbindung 1150 oder drahtlose Verbindung 1160 übertragen werden. Die Fertigungsstätte 1165 kann dann eine integrierte Schaltung fertigen, die mindestens zum Teil auf der IP-Kerngestaltung basiert. Die gefertigte integrierte Schaltung kann dann zum Ausführen von Vorgängen gemäß mindestens einer, hierin beschriebenen Ausführungsform konfiguriert werden.
Beispielhafte integrierte System-on-a-Chip-Schaltung
12 bis 14 stellen beispielhafte integrierte Schaltungen und assoziierte Grafikprozessoren, die unter Benutzung von einem oder mehr IP-Kernen gefertigt werden können, gemäß verschiedenen, hierin beschriebenen Ausführungsformen dar. Neben dem Dargestellten können andere Logik und Schaltungen enthalten sein, darunter zusätzliche Grafikprozessoren/-kerne, periphere Schnittstellensteuerungen oder Mehrzweckprozessorkerne.
12 ist ein Blockdiagramm einer beispielhaften integrierten System-on-a-Chip-Schaltung 1200, die unter Benutzung von einem oder mehr IP-Kernen gefertigt sein kann, gemäß einer Ausführungsform. Die beispielhafte integrierte Schaltung 1200 enthält einen oder mehr Anwendungsprozessor(en) 1205 (beispielsweise Prozessoren), mindestens einen Grafikprozessor 1210, und kann einen Bildprozessor 1215 und/oder einen Videoprozessor 1120 enthalten, von denen jeder ein modularer IP-Kern von derselben oder mehrfachen verschiedenen Gestaltungseinrichtungen sein kann. Die integrierte Schaltung 1200 enthält periphere oder Buslogik, darunter eine USB-Steuerung 1225, UART-Steuerung 1230, eine SPI/SDIO-Steuerung 1235 und eine I2S/I2C-Steuerung 1240. Zudem kann die integrierte Schaltung ein Anzeigengerät 1245 enthalten, das an eines oder mehr einer High-Definition Multimedia Interface-Steuerung (HDMI-Steuerung) 1250 und einer Mobile Industry Processor Interface-Anzeigenschnittstelle (MIPI-Anzeigenschnittstelle) 1255 gekoppelt ist. Speicherung kann durch ein Flashspeichersubsystem 1260 mit einem Flashspeicher und einer Flashspeichersteuerung vorgesehen sein. Eine Speicherschnittstelle kann über eine Speichersteuerung 1265 für Zugriff auf SDRAM- oder SRAM-Speichergeräte vorgesehen sein. manche integrierte Schaltungen enthalten zusätzlich eine eingebettete Sicherheitsmaschine 1270.
13 ist ein Blockdiagramm, das einen beispielhaften Grafikprozessor 1310 einer integrierten System-on-a-Chip-Schaltung, die unter Benutzung von einem oder mehr IP-Kernen gefertigt sein kann, gemäß einer Ausführungsform darstellt. Der Grafikprozessor 1310 kann eine Variante des Grafikprozessors 1210 von 12 sein. Der Grafikprozessor 1310 enthält einen Scheitelpunktprozessor 1305 und einen oder mehr Fragmentprozessor(en) 1315A bis 1315N (beispielsweise 1315A, 1315B, 1315C, 1315D bis 1315N-1 und 1315N). Der Grafikprozessor 1310 kann verschiedene Shaderprogramme über separate Logik ausführen, sodass der Scheitelpunktprozessor 1305 zum Ausführen von Vorgängen für Scheitelpunktshaderprogramme optimiert ist, während der eine oder mehr Fragmentprozessor(en) 1315A bis 1315N Fragmentschattierungsvorgänge (beispielsweise Pixelschattierungsvorgänge) für Fragment- oder Pixelshaderprogramme ausführt (ausführen). Der Scheitelpunktprozessor 1305 führt die Scheitelpunktverarbeitungsphase der 3D-Grafikpipeline aus und erzeugt Primitiv- und Scheitelpunktdaten. Der (die) Fragmentprozessor(en) 1315A bis 1315N benutzt (benutzen) die Primitiv- und Scheitelpunktdaten, die durch den Scheitelpunktprozessor 1305 erzeugt werden, zum Erzeugen eines Framepuffers, der auf einem Anzeigengerät angezeigt wird. In einer Ausführungsform wird der (werden die) Fragmentprozessor(en) 1315A bis 1315N zum Ausführen von Fragmentshaderprogrammen, wie sie in der OpenGL API vorgesehen sind, optimiert, die zum Ausführen von ähnlichen Vorgängen wie ein Pixelshaderprogramm benutzt werden, wie sie in der Direct 3D API vorgesehen sind.
Der Grafikprozessor 1310 enthält eine oder mehr Speicherverwaltungseinheiten (MMUs) 1320A bis 1320B, Cache(s) 1325A bis 1325B und Schaltungszusammenschaltung(en) 1330A bis 1330B. Die eine oder mehr MMU(s) 1320A bis 1320B sehen virtuelle zu physikalische Addressabbildung für den Grafikprozessor 1310 vor, darunter für den Scheitelpunktprozessor 1305 und/oder den (die) Fragmentprozessor(en) 1315A bis 1315N, die Scheitelpunkt- oder Bild-/Texturdaten, welche im Speicher gespeichert sind, zusätzlich zu Scheitelpunkt- oder Bild-/Texturdaten, welche in dem einen oder mehr Cache(s) 1325A bis 1325B gespeichert sind, referenzieren. In einer Ausführungsform können mit anderen MMUs innerhalb des Systems synchronisiert sein, darunter eine oder mehr MMUs, die mit dem einen oder mehr Anwendungsprozessor(en) 1205, Bildprozessor 1215 und/oder Videoprozessor 1220 von 12 assoziiert sind, sodass jeder Prozessor 1205 bis 1220 in einem gemeinsam benutzten oder vereinigten virtuellen Speichersystem teilnehmen kann. Die eine oder mehr Schaltungszusammenschaltung(en) 1330A bis 1330B ermöglichen es dem Grafikprozessor 1310, sich mit anderen IP-Kernen innerhalb des SoC zu verbinden, entweder über einen internen Bus des SoC oder über eine direkte Verbindung, gemäß Ausführungsformen.
14 ist ein Blockdiagramm, das einen zusätzlichen beispielhaften Grafikprozessor 1410 einer intergierten System-on-a-Chip-Schaltung, die unter Benutzung von einem oder mehr IP-Kernen gefertigt werden kann, gemäß einer Ausführungsform darstellt. Der Grafikprozessor 1410 kann eine Variante des Grafikprozessors 1210 von 12 sein. Der Grafikprozessor 1410 enthält die eine oder mehr MMU(s) 1320A bis 1320B, Cache(s) 1325A bis 1325B und Schaltungszusammenschaltung(en) 1130A bis 1330B der integrierten Schaltung 1300 von 13.
Der Grafikprozessor 1410 enthält einen oder mehr Shaderkern(e) 1415A bis 1415N (beispielsweise 1415A, 1415B, 1415C, 1415D, 1415E, 1415F bis 1315N-1 und 1315N), was eine vereinigte Shaderkernarchitektur vorsieht, in der ein einzelner Kern oder Typ von Kern alle Typen von programmierbarem Shadercode ausführen kann, darunter Shaderprogrammcode zum Implementieren von Scheitelpunktshadern, Fragmentshadern und/oder Rechenshadern. Die genaue Anzahl von vorhandenen Shaderkernen kann unter Ausführungsformen und Implementierungen variieren. Zudem enthält der Grafikprozessor 1410 einen Interkernaufgabenverwalter 1405, der als Threadverteiler zum Verteilen von Ausführungsthreads an einen oder mehr Shaderkern(e) 1415A bis 1415N und eine Kacheleinheit 1418 zum Beschleunigen von Kachelvorgängen für kachelbasiertes Rendern wirkt, bei dem Rendervorgänge für eine Szene im Bildraum unterteilt werden, beispielsweise zum Ausnutzen von lokaler räumlicher Kohärenz innerhalb einer Szene oder zum Optimieren der Benutzung von internen Caches.
BEISPIELHAFTE GRAFIKMIKROARCHITEKTUREN
In manchen Ausführungsformen ist eine Grafikverarbeitungseinheit (GPU) zum Beschleunigen von Grafikvorgängen, Maschinenlernvorgängen, Musteranalysevorgängen und verschiedenen Mehrzweck-GPU-Funktionen (GPGPU-Funktionen) kommunikationstechnisch an Host-/Prozessorkerne gekoppelt. Die GPU kann über einen Bus oder eine andere Zusammenschaltung (beispielsweise eine Hochgeschwindigkeitszusammenschaltung wie etwa PCIe oder NVLink) kommunikationstechnisch an die Host-/Prozessorkerne gekoppelt sein. In andere Ausführungsformen kann die GPU auf derselben Packung oder demselben Chip wie die Kerne integriert sein und über eine/n interne/n Prozessorbus/Zusammenschaltung (d.h. intern zur Packung oder zum Chip) kommunikationstechnisch an die Kerne gekoppelt sein. Ungeachtet der Art und Weise, in der die GPU verbunden ist, können die Prozessorkerne der GPU Arbeit in der Form von Sequenzen von Befehlen/Anweisungen, die in einem Arbeitsdeskriptor enthalten sind, zuweisen. Die GPU benutzt dann dedizierte Schaltung/Logik zum effizienten Verarbeiten dieser Befehle/Anweisungen.
In der folgenden Beschreibung sind zahlreiche spezifische Details dargelegt, um zu einem gründlicheren Verständnis zu verhelfen. Es ist für den Fachmann jedoch ersichtlich, dass die hierin beschriebenen Ausführungsformen ohne ein oder mehr dieser spezifischen Details praktisch umgesetzt werden können. In anderen Fällen wurden allgemein bekannte Merkmale nicht beschrieben, um Verunklaren der Details der vorliegenden Ausführungsformen zu vermeiden.
Systemübersicht
15 ist ein Blockdiagramm, das ein Rechensystem 1500 darstellt, welches zum Implementieren von einem oder mehr Aspekten der hierin beschriebenen Ausführungsformen konfiguriert ist. Das Rechensystem 1500 enthält ein Verarbeitungssubsystem 1501 mit einem oder mehr Prozessor(en) 1502 und einem Systemspeicher 1504, die über einen Zusammenschaltungspfad kommunizieren, der einen Speicherhub 1505 enthalten kann. Der Speicherhub 1505 kann eine separate Komponente innerhalb einer Chipsatzkomponente sein oder innerhalb des einen oder mehr Prozessors (Prozessoren) 1502 integriert sein. Der Speicherhub 1505 ist mit einem E/A-Subsystem 1511 über eine Kommunikationsverbindung 1506 verkoppelt. Das E/A-Subsystem 1511 enthält einen E/A-Hub 1507, der es dem Rechensystem 1500 ermöglichen kann, Eingabe von einem oder mehr Eingabegerät(en) 1508 zu empfangen. Zudem kann der E/A-Hub 1507 es einer Anzeigensteuerung, die in dem einen oder mehr Prozessor(en) 1502 enthalten sein kann, ermöglichen, einem oder mehr Ausgabegerät(en) 1510A Ausgaben zuzuführen. In einer Ausführungsform kann das eine oder mehr mit dem E/A-Hub 1507 gekoppelte Anzeigengerät(e) 1510A ein lokales, internes oder eingebettetes Anzeigengerät enthalten.
In einer Ausführungsform enthält das Verarbeitungssubsystem 1501 einen oder mehr parallele Prozessor(en) 1512, der/die über einen Bus oder eine andere Kommunikationsverbindung 1513 an den Speicherhub 1505 gekoppelt ist/sind. Die Kommunikationsverbindung 1513 kann eine von jeglicher Anzahl von auf Standards basierenden Kommunikationsverbindungstechnologien oder - protokollen sein, darunter u.a. PCI Express, oder kann eine herstellerspezifische Kommunikationsschnittstelle oder Kommunikationsstruktur sein. In einer Ausführungsform bildet/bilden der eine oder mehr parallele Prozessor(en) 1512 ein rechentechnisch fokussiertes Parallel- oder Vektorverarbeitungssystem aus, das eine hohe Anzahl von Verarbeitungskernen und/oder Verarbeitungsclustern enthalten kann, wie etwa einen Many Integrated Core-Prozessor (MIC-Prozessor). In einer Ausführungsform bildet/bilden der eine oder mehr parallele Prozessor(en) 1512 ein Grafikverarbeitungssubsystem aus, das Pixel an das eine oder mehr Anzeigengerät(e) 1510A ausgeben kann, das (die) über den E/A-Hub 1507 verkoppelt ist (sind). Der eine oder mehr parallele Prozessor(en) 1512 kann (können) außerdem eine Anzeigensteuerung und Anzeigenschnittstelle (nicht gezeigt) enthalten, um eine direkte Verbindung mit einem oder mehr Anzeigengerät(en) 1510B zu ermöglichen.
Innerhalb des E/A-Subsystems 1511 kann eine Systemspeichereinheit 1514 zum Vorsehen eines Speichermechanismus für das Rechensystem 1500 mit dem E/A-Hub 1507 verbunden sein. Ein E/A-Schalter 1516 kann zum Vorsehen eines Schnittstellenmechanismus zum Ermöglichen von Verbindungen zwischen dem E/A-Hub 1507 und anderen Komponenten, wie etwa ein Netzwerkadapter 1518 und/oder drahtloser Netzwerkadapter 1519, die in der Plattform integriert sein können, und verschiedenen anderen Geräten, die über ein oder mehr Zusatzgerät(e) 1520 hinzugefügt sein können, benutzt werden. Der Netzwerkadapter 1518 kann ein Ethernet-Adapter oder ein anderer verdrahteter Adapter sein. Der drahtlose Netzwerkadapter 1519 kann eines oder mehr eines Wi-Fi-, Bluetooth-, Nahfeldkommunikations- (NFC-) oder anderen Netzwerkgeräts enthalten, das ein oder mehr drahtlose Funkgeräte enthält.
Das Rechensystem 1500 kann andere Komponenten, die nicht ausdrücklich gezeigt sind, enthalten, darunter USB- oder andere Portverbindungen, optische Speicherlaufwerke, Videoerfassungsgeräte und dergleichen, die ebenfalls mit dem E/A-Hub 1507 verbunden sein können. Kommunikationspfade, die die verschiedenen Komponenten in 15 zusammenschalten, können unter Benutzung von jeglichen geeigneten Protokollen, wie etwa PCI- (Peripheral Component Interconnect-) basierte Protokolle (beispielsweise PCI-Express), oder von jeglichen anderen Bus- oder Punkt-zu-Punkt-Kommunikationsschnittstellen und/oder Protokoll(en), wie etwa der NVLink-Hochgeschwindigkeitszusammenschaltung, oder Zusammenschaltungsprotokollen, die im Fachgebiet bekannt sind, implementiert sein.
In einer Ausführungsform gliedert der (die) eine oder mehr parallele Prozessor(en) 1512 Schaltungen ein, die für Grafik- und Videoverarbeitung optimiert sind, darunter beispielsweise Videoausgabeschaltungen, und bildet (bilden) eine Grafikverarbeitungseinheit (GPU). In einer anderen Ausführungsform gliedert (gliedern) der eine oder mehr parallele Prozessor(en) 1512 Schaltungen ein, die für Mehrzweckverarbeitung optimiert sind, während die zugrunde liegende Rechenarchitektur erhalten bleibt, die hierin in größerem Detail beschrieben ist. In wieder einer anderen Ausführungsform können Komponenten des Rechensystems 1500 mit einem oder mehr anderen Systemelementen auf einer einzelnen integrierten Schaltung integriert sein. Beispielsweise kann (können) der eine oder mehr parallele Prozessor(en) 1512, Speicherhub 1505, Prozessor(en) 1502 und E/A-Hub 1507 in einer integrierten System-auf-Chip-Schaltung (SoC-Schaltung) integriert sein. Alternativ können die Komponenten des Rechensystems 1500 in einer einzelnen Verpackung zum Ausbilden einer System-in-Verpackung-Konfiguration (SIP-Konfiguration) integriert sein. In einer Ausführungsform kann mindestens ein Anteil der Komponenten des Rechensystems 1500 in einem Mehrchipmodul (MCM) integriert sein, das mit anderen Mehrchipmodulen in einem modularen Rechensystem zusammengeschaltet sein kann.
Man wird erkennen, dass das hierin gezeigte Rechensystem 1500 veranschaulichend ist, und dass Variationen und Modifikationen möglich sind. Die Verbindungstopologie, darunter die Anzahl und Anordnung von Brücken, die Anzahl von Prozessoren 1502 und die Anzahl von parallelen Prozessoren 1512, kann wie gewünscht modifiziert werden. Beispielsweise ist in manchen Ausführungsformen der Systemspeicher 1504 direkt mit dem (den) Prozessor(en) 1502 verbunden, statt über eine Brücke, während andere Geräte mit dem Systemspeicher 1504 über den Speicherhub 1505 und den (die) Prozessor(en) 1502 kommunizieren. In anderen alternativen Topologien ist (sind) der (die) parallele Prozessor(en) 1502 mit dem E/A-Hub 1507 oder direkt mit einem des einen oder mehr Prozessors (Prozessoren) 1502 verbunden, statt mit dem Speicherhub 1505. In anderen Ausführungsformen können der E/A-Hub 1507 und der Speicherhub 1505 in einem einzelnen Chip integriert sein. Manche Ausführungsformen können zwei oder mehr Sätze von Prozessoren 1502 enthalten, die über mehrfache Buchsen angebracht sind und mit zwei oder mehr Elementen des (der) parallelen Prozessors (Prozessoren) 1512 verkoppelt sein können.
Einige der hierin gezeigten, besonderen Komponenten sind optional und könnten nicht in allen Implementierungen des Rechensystems 1500 enthalten sein. Beispielsweise kann jegliche Anzahl von Zusatzkarten oder Peripheriegeräten unterstützt werden, oder einige Komponenten können ausgeschlossen sein. Zudem können manche Architekturen andere Terminologie für Komponenten verwenden, die den in 15 dargestellten gleichen. Beispielsweise kann der Speicherhub 1505 in manchen Architekturen als Northbridge bezeichnet sein, während der E/A-Hub 1507 als Southbridge bezeichnet sein kann.
16A stellt einen parallelen Prozessor 1600 gemäß einer Ausführungsform dar. Die verschiedenen Komponenten des parallelen Prozessors 1600 können unter Benutzung von einem oder mehr integrierten Schaltungsgeräten implementiert sein, wie etwa programmierbare Prozessoren, anwendungsspezifische integrierte Schaltungen (ASICs) oder feldprogrammierbare Gate-Arrays (FPGA). Der dargestellte parallele Prozessor 1600 ist eine Variante des/der einen oder mehr parallelen Prozessors (Prozessoren) 1512, der/die in 15 gezeigt ist/sind, gemäß einer Ausführungsform.
In einer Ausführungsform enthält der parallele Prozessor 1600 eine parallele Verarbeitungseinheit 1602. Die parallele Verarbeitungseinheit eine E/A-Einheit 1604, die Kommunikation mit anderen Geräten ermöglicht, darunter andere Elemente der parallelen Verarbeitungseinheit 1602. Die E/A-Einheit 1604 kann direkt mit anderen Geräten verbunden sein. In einer Ausführungsform ist die E/A-Einheit 1604 mit anderen Geräten über die Benutzung einer Hub- oder Schaltschnittstelle verbunden, wie etwa dem Speicherhub 1505. Die Verbindungen zwischen dem Speicherhub 1505 und der E/A-Einheit 1604 bilden eine Kommunikationsverbindung 1513. Innerhalb der parallelen Verarbeitungseinheit 1602 ist die E/A-Einheit 1604 mit einer Hostschnittstelle 1606 und einer Speicherkreuzschiene 1616 verbunden, wobei die Hostschnittstelle 1606 Befehle empfängt, die sich an das Ausführen von Verarbeitungsvorgängen richten, und die Speicherkreuzschiene 1616 Befehle empfängt, die sich an das Ausführen von Speichervorgängen richten.
Wenn die Hostschnittstelle 1606 einen Befehlspuffer über die E/A-Einheit 1604 empfängt, kann die Hostschnittstelle 1606 Arbeitsvorgänge zum Ausführen dieser Befehle an ein Frontend 1608 leiten. In einer Ausführungsform ist das Frontend 1608 mit einem Scheduler 1610 verkoppelt, der zum Verteilen von Befehlen oder anderen Arbeitselementen an ein Verarbeitungsclusterarray 1612 konfiguriert ist. In einer Ausführungsform gewährleistet der Scheduler 1610, dass das Verarbeitungsclusterarray 1612 richtig konfiguriert und in einem gültigen Zustand ist, bevor Aufgaben an die Verarbeitungscluster des Verarbeitungsclusterarrays verteilt werden. In einer Ausführungsform ist der Scheduler 1610 über Firmwarelogik implementiert, die auf einem Mikrokontroller läuft. Der über Mikrokontroller implementierte Scheduler 1610 ist zum Ausführen von komplexen Zeitplanungs- und Arbeitsverteilungsvorgängen mit grober und feiner Granularität konfigurierbar, wodurch rasche Präemption und Kontextumschalten von Threads ermöglicht ist, die auf dem Verarbeitungsarray 1612 laufen. In einer Ausführungsform kann die Hostsoftware Arbeitslasten zum zeitlichen Einplanen auf dem Verarbeitungsarray 1612 über eine von mehreren Grafikverarbeitungstürklingeln nachweisen. Die Arbeitslasten können dann durch die Logik des Schedulers 1610 innerhalb des Schedulermikrokontrollers automatisch über das Verarbeitungsarray 1612 verteilt werden.
Das Verarbeitungsclusterarray 1612 kann bis zu „N“ Verarbeitungscluster enthalten (beispielsweise Cluster 1614A, Cluster 1614B bis Cluster 1614N). Jeder Cluster 1614A bis 1614N des Verarbeitungsclusterarrays 1612 kann eine hohe Anzahl von gleichzeitig laufenden Threads ausführen. Der Scheduler 1610 kann den Clustern 1614A bis 1614N des Verarbeitungsclusterarrays 1612 Arbeit unter Benutzung von verschiedenen Zeitplanungs- und/oder Arbeitsverteilungsalgorithmen zuweisen, die abhängig von der Arbeitslast, welche für jede Art von Programm oder Rechnung entsteht, variieren kann. Die zeitliche Einplanung kann dynamisch durch den Scheduler 1610 gehandhabt werden oder teilweise durch Compilerlogik während der Kompilation von Programmlogik, die zur Ausführung durch das Verarbeitungsclusterarray 1612 konfiguriert ist, unterstützt werden. In einer Ausführungsform können verschiedene Cluster 1614A bis 1614N des Verarbeitungsclusterarrays 1612 zum Verarbeiten von verschiedenen Arten von Programmen oder zum Ausführen von verschiedenen Arten von Rechnungen zugewiesen werden.
Das Verarbeitungsclusterarray 1612 kann zum Ausführen von verschiedenen Arten von parallelen Verarbeitungsvorgängen konfiguriert sein. In einer Ausführungsform ist das Verarbeitungsclusterarray 1612 zum Ausführen von parallelen Mehrzweckrechenvorgängen konfiguriert. Beispielsweise kann das Verarbeitungsclusterarray 1612 Logik zum Ausführen von Verarbeitungsaufgaben, die Filtern von Video- und/oder Audiodaten enthalten, zum Ausführen von Modellierungsvorgängen, darunter physikalische Vorgänge, und zum Ausführen von Datentransformationen enthalten.
In einer Ausführungsform ist das Verarbeitungsclusterarray 1612 zum Ausführen von parallelen Grafikverarbeitungsvorgängen konfiguriert. In Ausführungsformen, in denen der parallele Prozessor 1600 zum Ausführen von Grafikverarbeitungsvorgängen konfiguriert ist, kann das Verarbeitungsclusterarray 1612 zusätzliche Logik zum Unterstützen der Ausführung von derartigen Grafikverarbeitungsvorgängen enthalten, darunter u.a. Texturabtastlogik zum Ausführen von Texturvorgängen sowie Tesselierungslogik und andere Scheitelpunktverarbeitungslogik. Zudem kann das Verarbeitungsclusterarray 1612 zum Ausführen von grafikverarbeitungsbezogenen Shaderprogrammen konfiguriert sein, darunter u.a. Scheitelpunktshader, Tesselierungsshader, Geometrieshader und Pixelshader. Die parallele Verarbeitungseinheit 1602 kann Daten vom Systemspeicher über die E/A-Einheit 1604 zum Verarbeiten übertragen. Während der Verarbeitung können die übertragenen Daten auf einem On-Chip-Speicher (beispielsweise paralleler Prozessorspeicher 1622) während der Verarbeitung gespeichert werden, dann zurück in den Systemspeicher geschrieben werden.
In einer Ausführungsform kann, wenn die parallele Verarbeitungseinheit 1602 zum Ausführen von Grafikverarbeitung benutzt wird, der Scheduler 1610 zum Aufteilen der Verarbeitungslast in ungefähr gleich große Aufgaben benutzt werden, um eine Verteilung der Grafikverarbeitungsvorgänge auf mehrere Cluster 1614A bis 1614N des Verarbeitungsclusterarrays 1612 besser zu ermöglichen. In manchen Ausführungsformen können Abschnitte des Verarbeitungsclusterarrays 1612 zum Ausführen von verschiedenen Arten von Verarbeitung konfiguriert sein. Beispielsweise kann ein erster Abschnitt zum Ausführen von Scheitelpunktschattierung und Topologieerzeugung konfiguriert sein, ein zweiter Abschnitt zum Ausführen von Tesselierung und Geometrieschattierung konfiguriert sein und ein dritter Abschnitt zum Ausführen von Pixelschattierung oder anderen Bildschirmraumvorgängen zum Erzeugen eines gerenderten Bilds zur Anzeige konfiguriert sein. Zwischendaten, die durch einen oder mehr der Cluster 1614A bis 1614N erzeugt werden, können in Puffern gespeichert werden, um zu ermöglichen, dass die Zwischendaten zwischen den Clustern 1614A bis 1614N zur weiteren Verarbeitung übertragen werden.
Während des Betriebs kann das Verarbeitungsclusterarray 1612 Verarbeitungsaufgaben, die ausgeführt werden sollen, über den Scheduler 1610 empfangen, der Befehle, die die Verarbeitungsaufgaben definieren, vom Frontend 1608 empfängt. Für Grafikverarbeitungsvorgänge können Verarbeitungsaufgaben Indizes von Daten, die verarbeitet werden sollen, beispielsweise Oberflächen-(Patch-) Daten, Primitivdaten, Scheiteldaten und/oder Pixeldaten sowie Zustandsparameter und Befehle enthalten, die definieren, wie die Daten verarbeitet werden sollen (beispielsweise welches Programm ausgeführt werden soll). Der Scheduler 1610 kann zum Abholen der Indizes, die den Aufgaben entsprechen, konfiguriert sein oder die Indizes vom Frontend 1608 empfangen. Das Frontend 1608 kann zum Gewährleisten konfiguriert sein, dass das Verarbeitungsclusterarray 1612 auf einen gültigen Zustand konfiguriert ist, bevor die Arbeitslast, die durch eingehende Befehlspuffer (beispielsweise Batchpuffer, Push-Puffer usw.) spezifiziert ist, initiiert wird.
Jedes der einen oder mehr Elemente der parallelen Verarbeitungseinheit 1602 kann mit dem parallelen Prozessorspeicher 1622 verkoppelt sein. Auf den parallelen Prozessorspeicher 1622 kann über die Speicherkreuzschiene 161 zugegriffen werden, die Speicheranforderungen vom Verarbeitungsclusterarray 1612 sowie von der E/A-Einheit 1604 empfangen kann. Die Speicherkreuzschiene 1616 kann über eine Speicherschnittstelle 1618 auf den parallelen Prozessorspeicher 1622 zugreifen. Die Speicherschnittstelle 1618 kann mehrfache Partitionseinheiten (beispielsweise Partitionseinheit 1620A, Partitionseinheit 1620B bis Partitionseinheit 1620N) enthalten, die jede an einen Abschnitt (beispielsweise Speichereinheit) des parallelen Prozessorspeichers 1622 angekoppelt sein können. In einer Ausführungsform ist die Anzahl der Partitionseinheiten 1620A bis 1620N derart konfiguriert, dass sie gleich der Anzahl von Speichereinheiten ist, sodass eine erste Partitionseinheit 1620A eine entsprechende erste Speichereinheit 1624A aufweist, eine zweite Partitionseinheit 1620B eine entsprechende Speichereinheit 1624B aufweist und eine N-te Partitionseinheit 1620N eine entsprechende N-te Speichereinheit 1624N aufweist. In anderen Ausführungsformen könnte die Anzahl von Partitionseinheiten 1620A bis 1620N nicht gleich der Anzahl von Speichergeräten sein.
In verschiedenen Ausführungsformen können die Speichereinheiten 1624A bis 1624N verschiedene Arten von Speichergeräten enthalten, darunter dynamischer Direktzugriffsspeicher (DRAM) oder Grafikdirektzugriffsspeicher, wie etwa synchroner Grafikdirektzugriffsspeicher (SGRAM), darunter Grafikspeicher mit doppelter Datenrate (GDDR-Speicher). In einer Ausführungsform können die Speichereinheiten 1624A bis 1624N außerdem gestapelten 3D-Speicher enthalten, darunter u.a. Speicher mit hoher Bandbreite (HBM). Der Fachmann wird erkennen, dass die spezifische Implementierung der Speichereinheiten 1624A bis 1624N variieren kann und aus einer von verschiedenen herkömmlichen Gestaltungen ausgewählt sein kann. Renderziele, wie etwa Framepuffer oder Texturkarten, können in den Speichereinheiten 1624A bis 1624N durchwegs gespeichert sein, wodurch es den Partitionseinheiten 1620A bis 1620N ermöglicht ist, Abschnitte von jedem Renderziel parallel zu schreiben, um die verfügbare Bandbreite des parallelen Prozessorspeicher 1622 effizient zu nutzen. In manchen Ausführungsformen kann ein lokales Element des parallelen Prozessorspeichers 1622 zugunsten einer vereinigten Speichergestaltung ausgeschlossen sein, die den Systemspeicher in Verbindung mit lokalem Cachespeicher nutzt.
In einer Ausführungsform kann jeglicher der Cluster 1614A bis 1614N des Verarbeitungsclusterarrays 1612 Daten verarbeiten, die in jegliche der Speichereinheiten 1624A bis 1624N innerhalb des parallelen Prozessorspeichers 1622 geschrieben werden. Die Speicherkreuzschiene 1616 kann zum Übertragen der Ausgabe jeden Clusters 1614A bis 1614N an jegliche Partitionseinheit 1620A bis 1620N oder an einen anderen Cluster 1614A bis 1614N konfiguriert sein, der zusätzliche Verarbeitungsvorgänge auf die Ausgabe ausführen kann. Jeder Cluster 1614A bis 1614N kann mit der Speicherschnittstelle 1618 über die Speicherkreuzschiene 161 zum Auslesen aus oder Schreiben in verschiedene externe Speichergeräte kommunizieren. In einer Ausführungsform weist die Speicherkreuzschiene 1616 eine Verbindung mit der Speicherschnittstelle 161 zum Kommunizieren mit der E/A-Einheit 1604 sowie eine Verbindung mit einem lokalen Element des parallelen Prozessorspeichers 1622 auf, wodurch es den Verarbeitungseinheiten innerhalb der verschiedenen Verarbeitungscluster 1614A bis 1614N ermöglicht ist, mit dem Systemspeicher oder einem anderen Speicher zu kommunizieren, der nicht lokal zur parallelen Verarbeitungseinheit 1602 ist. In einer Ausführungsform kann die Speicherkreuzschiene 1616 virtuelle Kanäle zum Trennen von Verkehrsströmen zwischen den Clustern 1614A bis 1614N und den Partitionseinheiten 1620A bis 1620N benutzen.
Während eine einzelne parallele Verarbeitungseinheit 1602 innerhalb des parallelen Prozessors 1600 dargestellt ist, kann jegliche Anzahl von Elementen der parallelen Verarbeitungseinheit 1602 enthalten sein. Beispielsweise können mehrfache Elemente der parallelen Verarbeitungseinheit 1602 auf einer einzelnen Zusatzkarte vorgesehen sein, oder es können mehrfache Zusatzkarten zusammengeschaltet sein. Die verschiedenen Elemente der parallelen Verarbeitungseinheit 1602 können zum Zusammenarbeiten konfiguriert sein, auch wenn die verschiedenen Elemente unterschiedliche Anzahlen von Verarbeitungskernen, unterschiedliche Mengen von lokalem parallelem Prozessorspeicher und/oder andere Konfigurationsunterschiede aufweisen. Zum Beispiel, und in einer Ausführungsform, können manche Elemente der parallelen Verarbeitungseinheit 1602 Gleitkommaeinheiten mit höherer Präzision in Bezug zu anderen Elementen enthalten. Systeme, die ein oder mehr Elemente der parallelen Verarbeitungseinheit 1602 oder des parallelen Prozessors 1600 eingliedern, können in vielerlei Konfigurationen und Formfaktoren implementiert sein, darunter u.a. Desktop-, Laptop- oder handgehaltene Personal Computer, Server, Arbeitsstationen, Spielkonsolen und/oder eingebettete Systeme.
16B ist ein Blockdiagramm einer Partitionseinheit 1620 gemäß einer Ausführungsform. In einer Ausführungsform ist die Partitionseinheit 1620 ein Element von einer der Partitionseinheiten 1620A bis 1620N von 16A. Wie dargestellt enthält die Partitionseinheit 1620 einen L2-Cache 1621, eine Framepufferschnittstelle 1625 und eine ROP 1626 (Rastervorgangseinheit). Der L2-Cache 1621 ist ein Lese-/Schreibcache, der zum Ausführen von Lade- und Speichervorgängen konfiguriert ist, die von der Speicherkreuzschiene 1616 und der ROP 1626 empfangen werden. Lesefehlgriffe und dringende Rückschreibanforderungen werden durch den L2-Cache 1621 an die Framepufferschnittstelle 1625 zur Verarbeitung ausgegeben. Aktualisierungen können ebenfalls über die Framepufferschnittstelle 1625 an den Framepuffer zur Verarbeitung gesendet werden. In einer Ausführungsform ist die Framepufferschnittstelle 1625 mit einer der Speichereinheiten im parallelen Prozessorspeicher verbunden, wie etwa den Speichereinheiten 1624A bis 1624N von 16 (beispielsweise innerhalb des parallelen Prozessorspeichers 1622).
In Grafikanwendungen ist die ROP 1626 eine Verarbeitungseinheit, die Rastervorgänge ausführt, wie etwa Stencil, Z-Test, Mischen und dergleichen. In manchen Ausführungsformen enthält die ROP 1626 Komprimierungslogik zum Komprimieren von Tiefen- oder Farbdaten, die in den Speicher geschrieben werden, und Dekomprimieren von Tiefen- oder Farbdaten, die aus dem Speicher ausgelesen werden. Die Komprimierungslogik kann verlustfreie Komprimierungslogik sein, die von einem oder mehr von mehrfachen Komprimierungsalgorithmen Gebrauch macht. Der Kompressionstyp, der durch die ROP 1626 ausgeführt wird, kann basierend auf den statistischen Kennzeichen der Daten, die komprimiert werden, variieren. Beispielsweise wird in einer Ausführungsform Deltafarbkomprimierung auf Tiefen- und Farbdaten auf einer Pro-Kachel-Basis ausgeführt.
In manchen Ausführungsformen ist die ROP 1626 innerhalb jeden Verarbeitungsclusters (beispielsweise Cluster 1614A bis 1614N von 16) statt innerhalb der Partitionseinheit 1620 enthalten. In einer derartigen Ausführungsform werden Lese- und Schreibanforderungen nach Pixeldaten anstelle von Pixelfragmentdaten über die Speicherkreuzschiene 1616 übertragen. Die verarbeiteten Grafikdaten können auf einem Anzeigengerät, wie etwa einem des einen oder mehr Anzeigengeräts (Anzeigengeräte) 1510 von 15, angezeigt werden, zur weiteren Verarbeitung durch den (die) Prozessor(en) 1502 geleitet werden oder zur weiteren Verarbeitung durch eine der Verarbeitungseinheiten innerhalb des parallelen Prozessors 1600 von 16A geleitet werden.
16C ist ein Blockdiagramm eines Verarbeitungsclusters 1614 innerhalb einer parallelen Verarbeitungseinheit gemäß einer Ausführungsform. In einer Ausführungsform ist der Verarbeitungscluster ein Element von einem der Verarbeitungscluster 1614A bis 1614N von 16. Der Verarbeitungscluster 1614 kann zum parallelen Ausführen von zahlreichen Threads konfiguriert sein, wobei sich der Begriff „Thread“ auf ein Element eines bestimmten Programms bezieht, das auf einem bestimmten Satz von Eingabedaten läuft. In manchen Ausführungsformen werden Single Instruction Multiple Data-Anweisungsausgabetechniken (SIMD-Anweisungsausgabetechniken) zum Unterstützen von paralleler Ausführung einer hohen Anzahl von Threads ohne Bereitstellung von mehrfachen unabhängigen Anweisungseinheiten benutzt. In anderen Ausführungsformen werden Single Instruction Multiple Thread-Techniken (SIMT-Techniken) zum Unterstützen von paralleler Ausführung einer hohen Anzahl von im Allgemeinen synchronisierten Threads benutzt, unter Benutzung einer gemeinsamen Anweisungseinheit, die zum Ausgeben von Anweisungen an einen Satz von Verarbeitungsmaschinen innerhalb von jedem der Verarbeitungscluster konfiguriert ist. Unähnlich einem SIMD-Ausführungsbetriebszustand, in dem alle Verarbeitungsmaschinen typischerweise identische Anweisungen ausführen, ermöglicht SIMT-Ausführung, dass verschiedene Threads divergierenden Ausführungspfaden durch ein jeweiliges Threadprogramm leichter folgen. Der Fachmann wird verstehen, dass ein SIMD-Ausführungsbetriebszustand einen funktionalen Teilsatz eines SIMT-Ausführungsbetriebszustands darstellt.
Betrieb des Verarbeitungsclusters 1614 kann über einen Pipelineverwalter 1632 gesteuert werden, der Verarbeitungsaufgaben auf parallele SIMT-Prozessoren verteilt. Der Pipelineverwalter 1632 empfängt Anweisungen vom Scheduler 1610 von 16 und verwaltet die Ausführung dieser Anweisungen über einen Grafikmultiprozessor 1634 und/oder eine Textureinheit 1636. Der dargestellte Grafikmultiprozessor 1634 ist ein beispielhaftes Element eines parallelen SIMT-Prozessors. Es können jedoch verschiedene Arten von parallelen SIMT-Prozessoren mit unterschiedlichen Architekturen innerhalb des Verarbeitungsclusters 1614 enthalten sein. Ein oder mehr Elemente des Grafikmultiprozessors 1634 können innerhalb eines Verarbeitungsclusters 1614 enthalten sein. Der Grafikmultiprozessor 1634 kann Daten verarbeiten, und eine Datenkreuzschiene 1640 kann zum Verteilen der verarbeiteten Daten auf eines von mehrfachen möglichen Zielen benutzt sein, darunter andere Shadereinheiten. Der Pipelineverwalter 1632 kann die Verteilung von verarbeiteten Daten durch Spezifizieren von Zielen für verarbeitete Daten, die über die datenkreuzschiene 1640 verteilt werden sollen, erleichtern.
Jeder Grafikmultiprozessor 1634 innerhalb des Verarbeitungsclusters 1614 kann einen identischen Satz von funktionaler Ausführungslogik enthalten (beispielsweise arithmetische Logikeinheiten, Lade-Speicher-Einheiten usw.). Die funktionale Ausführungslogik kann pipelineartig konfiguriert sein, wobei neue Anweisungen ausgegeben werden können, bevor vorherige Anweisungen komplettiert sind. Die funktionale Ausführungslogik unterstützt eine Vielfalt von Vorgängen, darunter ganzzahl- und Gleitkommaarithmetik, Vergleichsvorgänge, Boolesche Operationen, Bitverschiebung und Errechnung von verschiedenen algebraischen Funktionen. In einer Ausführungsform kann dieselbe Funktionseinheitshardware zum Ausführen von verschiedenen Vorgängen wirksam eingesetzt sein, und es kann jegliche Kombination von Funktionseinheiten vorhanden sein.
Die Anweisungen, die an den Verarbeitungscluster 1614 übertragen werden, bilden einen Thread. Ein Satz von Threads, der über den Satz von parallelen Verarbeitungsmaschinen hinweg läuft, ist eine Threadgruppe. Eine Threadgruppe führt dasselbe Programm auf verschiedene Eingabedaten aus. Jeder Thread innerhalb einer Threadgruppe kann einer anderen Verarbeitungsmaschine innerhalb eines Grafikmultiprozessors 1634 zugeteilt werden. Eine Threadgruppe kann weniger Threads als die Anzahl von Verarbeitungsmaschinen innerhalb des Grafikmultiprozessors 1634 enthalten. Wenn eine Threadgruppe weniger Threads als die Anzahl von Verarbeitungsmaschinen enthält, kann eine oder mehr der Verarbeitungsmaschinen während Zyklen untätig sein, in denen diese Threadgruppe verarbeitet wird. Eine Threadgruppe kann außerdem mehr Threads als die Anzahl von Verarbeitungsmaschinen innerhalb des Grafikmultiprozessors 1634 enthalten. Wenn die Threadgruppe mehr Threads als die Anzahl von Verarbeitungsmaschinen innerhalb des Grafikmultiprozessors 1634 enthält, kann die Verarbeitung über aufeinanderfolgende Taktzyklen hinweg ausgeführt werden. In einer Ausführungsform können mehrfache Threadgruppen gleichzeitig auf einem Grafikmultiprozessor 1634 ausgeführt werden.
In einer Ausführungsform enthält der Grafikmultiprozessor 1634 einen internen Cachespeicher zum Ausführen von Lade- und Speichervorgängen. In einer Ausführungsform kann der Grafikmultiprozessor 1634 auf einen internen Cachespeicher verzichten und einen Cachespeicher (beispielsweise L1-Cache 308) innerhalb des Verarbeitungsclusters 1614 benutzen. Jeder Grafikmultiprozessor 1634 hat außerdem Zugriff auf L2-Caches innerhalb der Partitionseinheiten (beispielsweise Partitionseinheiten 1620A bis 1620N von 16), die von allen Verarbeitungsclustern 1614 gemeinsam benutzt werden und zum Übertragen von Daten zwischen Threads benutzt werden können. Der Grafikmultiprozessor 1634 kann außerdem auf globalen Off-Chip-Speicher zugreifen, der einen oder mehr von lokalem parallelem Prozessorspeicher und/oder Systemspeicher enthalten kann. Jeglicher Speicher, der extern zur parallelen Verarbeitungseinheit 1602 ist, kann als globaler Speicher benutzt werden. Ausführungsformen, in denen der Verarbeitungscluster 1614 mehrfache Elemente des Grafikmultiprozessors 1634 enthält, können gemeinsame Anweisungen und Daten teilen, die im L1-Cache 1708 gespeichert sein können.
Jeder Verarbeitungscluster 1614 kann eine MMU 1645 (Speicherverwaltungseinheit) enthalten, die zum Abbilden von virtuellen Adressen auf physikalische Adressen konfiguriert ist. In anderen Ausführungsformen können ein oder mehr Elemente der MMU 1645 innerhalb der Speicherschnittstelle 1618 von 16 residieren. Die MMU 1645 enthält einen Satz von Seitentabelleneinträgen (PTEs), die zum Abbilden einer virtuellen Adresse auf eine physikalische Adresse einer Kachel (zu Kacheln später mehr) benutzt werden, und optional einen Cachezeilenindex. Die MMU 1645 kann Adressumsetzpuffer (TLB) oder Caches enthalten, die innerhalb des Grafikmultiprozessors 1634 oder des L1-Cache oder Verarbeitungsclusters 1614 residieren können. Die physikalische Adresse wird zum Verteilen von Oberflächendatenzugriffslokalitäten verarbeitet, um effiziente Anforderungsverschachtelung unter Partitionseinheiten zu ermöglichen. Der Cachezeilenindex kann zum Bestimmen benutzt werden, ob eine Anforderung einer Cachezeile ein Treffer oder ein Fehlgriff ist.
In Grafik- und Rechenanwendungen kann ein Verarbeitungscluster 1614 derart konfiguriert sein, dass jeder Grafikmultiprozessor 1634 an eine Textureinheit 1636 zum Ausführen von Texturabbildungsvorgängen gekoppelt ist, beispielsweise Bestimmen von Texturabtastpositionen, Lesen von Texturdaten und Filtern der Texturdaten. Texturdaten werden aus einem internen L1-texturcache (nicht gezeigt) oder in manchen Ausführungsformen aus dem L1-Cache innerhalb des Grafikmultiprozessors 1634 ausgelesen und nach Bedarf aus einem L2-Cache, lokalen parallelen Prozessorspeicher oder Systemspeicher abgeholt. Jeder Grafikmultiprozessor 1634 gibt verarbeitete Aufgaben an die Datenkreuzschiene 1640 zum Zuführen der verarbeiteten Aufgabe zu einem anderen Verarbeitungscluster 1614 zur weiteren Verarbeitung oder zum Speichern der verarbeiteten Aufgabe in einem L2-Cache, lokalen parallelen Prozessorspeicher oder Systemspeicher über die Speicherkreuzschiene 1616 aus. Eine PreROP 1642 (Vorrastervorgangseinheit) ist zum Empfangen von Daten vom Grafikmultiprozessor 1634, Leiten von Daten zu ROP-Einheiten, die mit Partitionseinheiten wie hierin beschrieben (beispielsweise Partitionseinheiten 1620A bis 1620N von 16) verortet sein können, konfiguriert. Die PreROP-Einheit 1642 kann Optimierungen für Farbabmischungen ausführen, Pixelfarbdaten organisieren und Adressumsetzungen ausführen.
Es versteht sich, dass die hierin beschriebene Kernarchitektur veranschaulichend ist, und dass Variationen und Modifikationen möglich sind. Jegliche Anzahl von Verarbeitungseinheiten, beispielsweise der Grafikmultiprozessor 1634, die Textureinheiten 1636, PreROPs 1642 usw., können innerhalb eines Verarbeitungsclusters 1614 enthalten sein. Ferner kann, während nur ein Verarbeitungscluster 1614 gezeigt ist, eine parallele Verarbeitungseinheit, wie sie hierin beschrieben ist, jegliche Anzahl von Elementen des Verarbeitungsclusters 1614 enthalten. In einer Ausführungsform kann jeder Verarbeitungscluster 1614 zum unabhängigen Betreiben von anderen Verarbeitungsclustern 1614 unter Benutzung von separaten und individuellen Verarbeitungseinheiten, L1-Caches usw. konfiguriert sein.
16D zeigt einen Grafikmultiprozessor 1634 gemäß einer Ausführungsform. In einer derartigen Ausführungsform ist der Grafikmultiprozessor 1634 mit dem Pipelineverwalter 1632 des Verarbeitungsclusters 1614 verkoppelt. Der Grafikmultiprozessor 1634 weist eine Ausführungspipeline auf, die u.a. einen Anweisungscache 1652, eine Anweisungseinheit 1654, eine Adressabbildungseinheit 1656, einer Registerdatei 1658, einen oder mehr Mehrzweckgrafikverarbeitungseinheitskerne (GPGPU-Kerne) 1662 und eine oder mehr Lade-/Speichereinheiten 1666 enthält. Die GPGPU-Kerne 1662 und Lade-/Speichereinheiten 1666 sind über eine Speicher- und Cachezusammenschaltung 1668 mit einem Cachespeicher 1672 und gemeinsam benutzten Speicher 1670 verkoppelt.
In einer Ausführungsform empfängt der Anweisungscache 1652 einen Strom von auszuführenden Anweisungen vom Pipelineverwalter 1632. Die Anweisungen werden im Anweisungscache 1652 zwischengespeichert und zur Ausführung durch die Anweisungseinheit 1654 verteilt. Die Anweisungseinheit 1654 kann Anweisungen als Threadgruppen (beispielsweise Warps) verteilen, wobei jeder Thread der Threadgruppe einer anderen Ausführungseinheit innerhalb des GPGPU-Kerns 1662 zugewiesen wird. Eine Anweisung kann auf jeglichen eines lokalen, gemeinsam benutzten oder globalen Adressraums durch Spezifizieren einer Adresse innerhalb eines vereinigten Adressraums zugreifen. Die Adressabbildungseinheit 1656 kann zum Umsetzen von Adressen im vereinigten Adressraum in eine individuelle Speicheradresse benutzt werden, auf die durch die Lade-/Speichereinheiten 1666 zugegriffen werden kann.
Die Registerdatei 1658 sieht einen Satz von Registern für die Funktionseinheiten des Grafikmultiprozessors 1724 vor. Die Registerdatei 1658 versieht vorübergehende Speicherung für Operanden, die mit den Datenpfaden der Funktionseinheiten (beispielsweise GPGPU-Kerne 1662, Lade-/Speichereinheiten 1666) des Grafikmultiprozessors 1724 verbunden sind. In einer Ausführungsform ist die Registerdatei 1658 derart zwischen jeder der Funktionseinheiten aufgeteilt, dass jeder Funktionseinheit ein dedizierter Abschnitt der Registerdatei 1658 zugewiesen ist. In einer Ausführungsform ist die Registerdatei 1658 zwischen den verschiedenen Warps aufgeteilt, die durch den Grafikmultiprozessor 1724 ausgeführt werden.
Die GPGPU-Kerne 1662 können jeder Gleitkommaeinheiten (FPUs) und/oder Ganzzahlarithmetiklogikeinheiten (ALUs) enthalten, die zum Ausführen von Anweisungen des Grafikmultiprozessors 1724 benutzt werden. Die GPGPU-Kerne 1662 können gemäß Ausführungsformen in der Architektur ähnlich sein oder in der Architektur abweichen. Beispielsweise, und in einer Ausführungsform, kann ein erster Abschnitt der GPGPU-Kerne 1662 eine FPU mit einfacher Genauigkeit und eine Ganzzahl-ALU enthalten, während ein zweiter Abschnitt der GPGPU-Kerne eine FPU mit doppelter Genauigkeit enthält. In einer Ausführungsform können die FPUs den IEEE 754-2008 Standard für Gleitkommaarithmetik implementieren oder Gleitkommaarithmetik mit variabler Genauigkeit ermöglichen. Der Grafikmultiprozessor 1724 kann zusätzlich eine oder mehr Einheiten mit festgelegter Funktion oder mit Spezialfunktion zum Ausführen von spezifischen Funktionen wie etwa Rechteckkopier- oder Pixelmischvorgänge enthalten. In einer Ausführungsform können ein oder mehr GPGPU-Kerne außerdem Logik mit festgelegter oder Spezialfunktion enthalten.
In einer Ausführungsform enthalten die GPGPU-Kerne 1662 SIMD-Logik, die zum Ausführen einer einzelnen Anweisung auf mehrfache Sätze von Daten imstande ist. In einer Ausführungsform können die GPGPU-Kerne 1662 SIMD4-, SIMD8- und SIMD16-Anweisungen physikalisch ausführen und SIMD1-, SIMD2- und SIMD32-Answeisungen logisch ausführen. Die SIMD-Anweisungen für die GPGPU-Kerne können zum Zeitpunkt des Kompilierens durch einen Shadercompiler erzeugt werden oder beim Ausführen von Programmen automatisch erzeugt werden, die für Single Program Multiple Data-Architekturen (SPMD-Architekturen) oder SIMT-Architekturen geschrieben und kompiliert sind. Mehrfache Threads eines Programms, das für das SIMT-Ausführungsmodell konfiguriert ist, können über eine einzelne SIMD-Anweisung ausgeführt werden. Beispielsweise, und in einer Ausführungsform, können acht SIMT-Threads, die dieselben oder ähnliche Vorgänge ausführen, parallel über eine einzelne SIMD8-Logikeinheit ausgeführt werden.
Die Speicher- und Cachezusammenschaltung 1668 ist ein Zusammenschaltungsnetzwerk, das jede der Funktionseinheiten des Grafikmultiprozessors 1724 mit der Registerdatei 1658 und dem gemeinsam benutzten Speicher 1670 verbindet. In einer Ausführungsform ist die Speicher- und Cachezusammenschaltung 1668 eine Kreuzschienenzusammenschaltung, die es der Lade-/Speichereinheit 1666 ermöglicht, Lade- und Speichervorgänge zwischen dem gemeinsam benutzten Speicher 1670 und der Registerdatei 1658 zu implementieren. Die Registerdatei 1658 kann auf derselben Frequenz wie die GPGPU-Kerne 1662 arbeiten, weswegen der Datentransfer zwischen den GPGPU-Kernen 1662 und der Registerdatei 1662 sehr niedrige Latenz aufweist. Der gemeinsam benutzte Speicher 1670 kann zum Ermöglichen von Kommunikation zwischen Threads benutzt werden, die auf den Funktionseinheiten innerhalb des Grafikmultiprozessors 1634 laufen. Der Cachespeicher 1672 kann als ein Datencache benutzt werden, beispielsweise zum Zwischenspeichern von Texturdaten, die zwischen den Funktionseinheiten und der Textureinheit 1636 übermittelt werden. Der gemeinsam benutzte Speicher 1670 kann außerdem als ein programmverwalteter Cache benutzt werden. Threads, die auf den GPGPU-Kernen 1662 laufen, können Daten innerhalb des gemeinsam benutzten Speichers zusätzlich zu den automatisch zwischengespeicherten Daten, welche im Cachespeicher 1672 gespeichert sind, programmatisch speichern.
17A bis 17B stellen zusätzliche Grafikmultiprozessoren gemäß Ausführungsformen dar. Die dargestellten Grafikmultiprozessoren 1725, 1750 sind Varianten des Grafikmultiprozessors 1634 von 16C. Die dargestellten Grafikmultiprozessoren 1725, 1750 können als ein Streaming-Multiprozessor (SM) konfiguriert sein, der zum simultanen Ausführen einer hohen Anzahl von Ausführungsthreads imstande ist
17A zeigt einen Grafikmultiprozessor 1725 gemäß einer zusätzlichen Ausführungsform. Der Grafikmultiprozessor 1725 enthält bezüglich des Grafikmultiprozessors 1634 von 16D mehrfache zusätzliche Elemente von Ausführungsressourceneinheiten. Beispielsweise kann der Grafikmultiprozessor 1725 mehrfache Elemente der Anweisungseinheit 1732A bis 1732B, Registerdatei 1734A bis 1734B und Textureinheit(en) 1744A bis 1744B enthalten. Der Grafikmultiprozessor 1725 enthält außerdem mehrfache Sätze von Grafik- oder Rechenausführungseinheiten (beispielsweise GPGPU-Kern 1736A bis 1736B, GPGPU-Kern 1737A bis 1737B, GPGPU-Kern 1738A bis 1738B) und mehrfache Sätze von Lade-/Speichereinheiten 1740A bis 1740B. In einer Ausführungsform weisen die Ausführungsressourceneinheiten einen gemeinsamen Anweisungscache 1730, Textur- und/oder Datencachespeicher 1742 und gemeinsam benutzten Speicher 1746 auf.
Die verschiedenen Komponenten können über eine Zusammenschaltungsstruktur 1727 kommunizieren. In einer Ausführungsform enthält die Zusammenschaltungsstruktur 1727 einen oder mehr Kreuzschienenschalter zum Ermöglichen von Kommunikation zwischen den verschiedenen Komponenten des Grafikmultiprozessors 1725. In einer Ausführungsform ist die Zusammenschaltungsstruktur 1727 eine separate Hochgeschwindigkeitsnetzwerkstrukturschicht, auf die jede Komponente des Grafikmultiprozessors 1725 gestapelt ist. Die Komponenten des Grafikmultiprozessors 1725 kommunizieren mit entlegenen Komponenten über die Zusammenschaltungsstruktur 1727. Beispielsweise können die GPGPU-Kerne 1736A bis 1736B, 1737A bis 1737B und 1738A bis 1738B jeder über die Zusammenschaltungsstruktur 1727 mit dem gemeinsam benutzten Speicher 1746 kommunizieren. Die Zusammenschaltungsstruktur 1727 kann Kommunikation innerhalb des Grafikmultiprozessors 1725 vermitteln, um eine faire Bandbreitenzuweisung zwischen Komponenten zu gewährleisten.
17B zeigt einen Grafikmultiprozessor 1750 gemäß einer zusätzlichen Ausführungsform. Der Grafikprozessor enthält mehrfache Sätze von Ausführungsressourcen 1756A bis 1756D, wobei jeder Satz von Ausführungsressourcen mehrfache Anweisungseinheiten, Registerdateien, GPGPU-Kernen und Ladespeichereinheiten enthält, wie in 16D und 17A dargestellt. Die Ausführungsressourcen 1756A bis 1756D können in Übereinstimmung mit Textureinheit(en) 1760A bis 1760D für Texturvorgänge arbeiten, während sie einen Anweisungscache 1754 und gemeinsam benutzten Speicher 1762 gemeinsam benutzen. In einer Ausführungsform können die Ausführungsressourcen 1756A bis 1756D einen Anweisungscache 1754 und gemeinsam benutzten Speicher 1762 sowie mehrfache Elemente eines Textur- und/oder Datencachespeicher 1758A bis 1758B gemeinsam benutzen. Die verschiedenen Komponenten können über eine Zusammenschaltungsstruktur 1752 kommunizieren, die der Zusammenschaltungsstruktur 1727 von 17A ähnelt.
Der Fachmann wird verstehen, dass die Architektur, die in 15, 16A bis 16D und 17A bis 17B beschrieben ist, hinsichtlich des Anwendungsbereichs der vorliegenden Ausführungsformen erläuternd und nicht einschränkend ist. Daher können die hierin beschriebenen Techniken auf jeglicher angemessen konfigurierten Verarbeitungseinheit implementiert werden, darunter ohne Einschränkung ein oder mehr Anwendungsprozessoren, eine oder mehr zentrale Desktop- oder Serververarbeitungseinheiten (CPUs), darunter Mehrkern-CPUs, eine oder mehr parallele Verarbeitungseinheiten, wie etwa die parallele Verarbeitungseinheit 1602 von 16, sowie ein oder mehr Grafikprozessoren oder Verarbeitungseinheiten für besondere Zwecke, ohne Abweichung vom Anwendungsbereich der hierin beschriebenen Ausführungsformen.
In manchen Ausführungsformen ist ein paralleler Prozessor oder eine GPGPU, wie hierin beschrieben, zum Beschleunigen von Grafikvorgängen, Maschinenlernvorgängen, Musteranalysevorgängen und verschiedenen Mehrzweck-GPU-Funktionen (GPGPU-Funktionen) kommunikationstechnisch an Host-/Prozessorkerne gekoppelt. Die GPU kann über einen Bus oder eine andere Zusammenschaltung (beispielsweise eine Hochgeschwindigkeitszusammenschaltung wie etwa PCIe oder NVLink) kommunikationstechnisch an die Host-/Prozessorkerne gekoppelt sein. In anderen Ausführungsformen kann die GPU auf demselben Paket oder Chip wie die Kerne integriert sein und über eine/n interne/n Prozessorbus/Zusammenschaltung (d.h. intern zum Paket oder Chip) kommunikationstechnisch an die Kerne gekoppelt sein. Ungeachtet der Art und Weise, in der die GPU verbunden ist, können die Prozessorkerne der GPU Arbeit in der Form von Sequenzen von Befehlen/Anweisungen zuweisen, die in einem Arbeitsdeskriptor enthalten sind. Die GPU benutzt dann dedizierte Schaltungen/Logik zum effizienten Verarbeiten dieser Befehle/Anweisungen.
Techniken für GPU-Hostprozessor-Zusammenschaltung
18A stellt eine beispielhafte Architektur dar, in der mehrere GPUs 1810 bis 1813 kommunikationstechnisch über Hochgeschwindigkeitsverbindungen 1840 bis 1843 (beispielsweise Busse, Punktzu-Punkt-Zusammenschaltungen usw.) an mehrere Mehrkernprozessoren 1805 bis 1806 gekoppelt sind. In einer Ausführungsform unterstützen die Hochgeschwindigkeitsverbindungen 1840 bis 1843 abhängig von der Implementierung einen Kommunikationsdurchsatz von 4 GB/s, 30 GB/s, 80 GB/s oder höher. Es können verschiedene Zusammenschaltungsprotokolle benutzt werden, darunter u.a. PCIe 4.0 oder 5.0 und NVLink 2.0. Die zugrundeliegenden Prinzipien der Erfindung sind jedoch auf keinerlei bestimmtes Kommunikationsprotokoll oder Durchsatz beschränkt.
Zudem sind in einer Ausführungsform zwei oder mehr der GPUs 1810 bis 1813 über Hochgeschwindigkeitsverbindungen 1844 bis 1845 zusammengeschaltet, die unter Benutzung derselben oder anderer Protokolle/Verbindungen als jenen, die für die Hochgeschwindigkeitsverbindungen 1840 bis 1843 benutzt werden, implementiert sein können. Gleicherweise können zwei oder mehr der Mehrkernprozessoren 1805 bis 1806 über eine Hochgeschwindigkeitsverbindung 1833 verbunden sein, die symmetrische Multiprozessorbusse (SMP-Busse) sein können, die auf 20 GB/s, 30 GB/s, 120 GB/s oder höher arbeiten. Alternativ kann die gesamte Kommunikation zwischen den verschiedenen Systemkomponenten, die in 18A gezeigt sind, unter Benutzung derselben Protokolle/Verbindungen (beispielsweise über eine gemeinsame Zusammenschaltungsstruktur) erreicht werden. Wie angegeben sind die zugrundeliegenden Prinzipien der Erfindung jedoch auf keinerlei bestimmte Art von Zusammenschaltungstechnologie beschränkt.
In einer Ausführungsform ist jeder Mehrkernprozessor 1805 bis 1806 jeweils kommunikationstechnisch über Speicherzusammenschaltungen 1830 bis 1831 an einen Prozessorspeicher 1801 bis 1802 gekoppelt und jede GPU 1810 bis 1813 jeweils kommunikationstechnisch über GPU-Speicherzusammenschaltungen 1850 bis 1853 an einen GPU-Speicher 1820 bis 1823 gekoppelt. Die Speicherzusammenschaltungen 1830 bis 1831 und 1850 bis 1853 können dieselben oder unterschiedliche Speicherzugriffstechnologien benutzen. Als Beispiel, und nicht als Einschränkung, können die Prozessorspeicher 1801 bis 1802 und GPU-Speicher 1820 bis 1823 flüchtige Speicher sein, wie etwa dynamische Direktzugriffsspeicher (DRAMs) (darunter gestapelte DRAMs), Grafik-DDR-SDAM (GDDR) (beispielsweise GDDR5, GDDR6) oder Speicher mit hoher Bandbreite (HBM), und/oder nichtflüchtige Speicher sein, wie etwa 3D XPoint oder Nano-Ram. In einer Ausführungsform kann ein Abschnitt der Speicher flüchtiger Speicher und ein anderer Abschnitt nichtflüchtiger Speicher sein (beispielsweise unter Benutzung einer Zweiebenenspeicherhierarchie (2LM-Hierarchie)).
Wie unten beschrieben, kann, obgleich die verschiedenen Prozessoren 1805 bis 1806 und GPUs 1810 bis 1813 jeweils physikalisch an einen bestimmten Speicher 1801 bis 1802, 1820 bis 1823 gekoppelt sein können, eine vereinigte Speicherarchitektur implementiert sein, in der derselbe virtuelle Systemadressraum (auch als der „effektive Adressraum“ bezeichnet) unter allen den verschiedenen physikalischen Speichern verteilt ist. Beispielsweise können die Prozessorspeicher 1801 bis 1802 jeder 64 GB des Systemspeicheradressraums aufweisen, und die GPU-Speicher 1820 bis 1823 können jeder 32 GB des Systemspeicheradressraums aufweisen (resultierend in insgesamt 256 GB von adressierbarem Speicher in diesem Beispiel).
18B stellt zusätzliche Details für eine Zusammenschaltung zwischen einem Mehrkernprozessor 1807 und einem Grafikbeschleunigungsmodul 1846 gemäß einer Ausführungsform dar. Das Grafikbeschleunigungsmodul 1846 kann einen oder mehr GPU-Chips enthalten, die auf einer Leitungskarte integriert sind, welche über die Hochgeschwindigkeitsverbindung 1840 an den Prozessor 1807 gekoppelt ist. Alternativ kann das Grafikbeschleunigungsmodul 1846 auf demselben Paket oder Chip wie der Prozessor 1807 integriert sein.
Der dargestellte Prozessor 1807 enthält mehrere Kerne 1860A bis 1860D, jeder mit einem Adressenübersetzungspuffer 1861A bis 1861D und einem oder mehr Caches 1862A bis 1862D. Die Kerne können verschiedene andere Komponenten zum Ausführen von Anweisungen und Verarbeiten von Daten enthalten, die nicht dargestellt sind, um Verunklaren der zugrundeliegenden Prinzipien der Erfindung zu vermeiden (beispielsweise Anweisungsabholeinheiten, Abzweigungsvoraussageeinheiten, Decodierer, Ausführungseinheiten, Neuordnungspuffer usw.). Die Caches 1862A bis 1862D können Level-1- und Level-2-Caches (L1- und L2-Caches) aufweisen. Zudem können ein oder mehr gemeinsam benutzte Caches 1826 in der Zwischenspeicherhierarchie enthalten sein und von Sätzen der Kerne 1860A bis 1860D gemeinsam benutzt werden. Beispielsweise enthält eine Ausführungsform des Prozessors 1807 24 Kerne, jeder mit seinem eigenen L1-Cache, zwölf gemeinsam benutzten L2-Caches und zwölf gemeinsam benutzten L3-Caches. In dieser Ausführungsform wird einer der L2- und L3-Caches von zwei benachbarten Kernen gemeinsam benutzt. Der Prozessor 1807 und das Grafikbeschleunigungsintegrationsmodul 1846 sind mit dem Systemspeicher 1841 verbunden, der die Prozessorspeicher 1801 bis 1802 enthalten kann.
Kohärenz wird für Daten und Anweisungen, die in den verschiedenen Caches 1862A bis 1862D, 1856 und dem Systemspeicher 1841 gespeichert sind, über Interkernkommunikation über einen Kohärenzbus 1864 aufrechterhalten. Beispielsweise kann jeder Cache damit assoziierte Cachekohärenzlogik/-schaltungen zum Kommunizieren dorthin über den Kohärenzbus 1864 in Reaktion auf erkanntes Lesen oder Schreiben in bestimmte Cachezeilen aufweisen. In einer Implementierung ist ein Cache-Snooping-Protokoll über den Kohärenzbus 1864 zum Nachforschen nach Cachezugriffen implementiert. Cache-Snooping-/-kohärenztechniken sind dem Fachmann allgemein bekannt und werden hier nicht im Detail beschrieben, um Verunklaren der zugrundeliegenden Prinzipien der Erfindung zu vermeiden.
In einer Ausführungsform koppelt eine Proxy-Schaltung 1825 das Grafikbeschleunigungsmodul 1846 kommunikationstechnisch an den Kohärenzbus 1864, wodurch ermöglicht ist, dass das Grafikbeschleunigungsmodul 1846 im Cachekohärenzprotokoll als ein Gleichgestellter der Kerne teilnimmt. Insbesondere versieht eine Schnittstelle 1835 die Proxy-Schaltung 1825 über die Hochgeschwindigkeitsverbindung 1840 (beispielsweise ein PCIe-Bus, NVLink usw.) mit Konnektivität, und eine Schnittstelle 1837 verbindet das Grafikbeschleunigungsmodul 1846 mit der Verbindung 1840.
In einer Implementierung sieht eine Beschleunigerintergrationsschaltung 1836 Cacheverwaltung, Speicherzugriff, Kontextverwaltung und Verwaltungsunterbrechungsdienste für mehrere Grafikverarbeitungsmaschinen 1831, 1832, N des Grafikbeschleunigungsmoduls 1846 vor. Die Grafikverarbeitungsmaschinen 1831, 1832, N können jede eine separate Grafikverarbeitungseinheit (GPU) aufweisen. Alternativ können die Grafikverarbeitungsmaschinen 1831, 1832, N verschiedene Arten von Grafikverarbeitungsmaschinen innerhalb einer GPU aufweisen, wie etwa Grafikausführungseinheiten, Medienverarbeitungsmaschinen (beispielsweise Videocodierer/-decodierer), Abtaster und Blit-Maschinen. Anders gesagt kann das Grafikbeschleunigungsmodul eine GPU mit mehreren Grafikverarbeitungsmaschinen 1831 bis 1832, N sein, oder die Grafikverarbeitungsmaschinen 1831 bis 1832, N können individuelle GPUs sein, die auf einem gemeinsamen Paket, Leitungskarte oder Chip integriert sind.
In einer Ausführungsform enthält die Beschleunigerintegrationsschaltung 1836 eine Speicherverwaltungseinheit (MMU) 1839 zum Ausführen von verschiedenen Speicherverwaltungsfunktionen, wie etwa virtuelle/physikalische Speicherumsetzungen (auch als effektive/reale Speicherumsetzungen bezeichnet) und Speicherzugriffsprotokolle zum Zugreifen auf den Systemspeicher 1841. Die MMU 1839 kann außerdem einen Adressumsetzpuffer (TLB) (nicht gezeigt) zum Zwischenspeichern von virtuellen/effektiven zu physikalischen/realen Adressumsetzungen enthalten. In einer Implementierung speichert ein Cache 1838 Befehle und Daten für effizienten Zugriff durch die Grafikverarbeitungsmaschinen 1831 bis 1832, N. In einer Ausführungsform werden die Daten, die im Cache 1838 und den Grafikspeichern 1833 bis 1834, N gespeichert sind, mit den Kerncaches 1862A bis 1862D, 1856 und dem Systemspeicher 1811 kohärent gehalten. Wie angegeben kann dies über die Proxyschaltung 1825 erreicht werden, die im Cachekohärenzmechanismus für den Cache 1838 und die Speicher 1833 bis 1834, N teilnimmt (beispielsweise Senden von Aktualisierungen an den Cache 1838, die Modifikationen/Zugriffe von Cachezeilen in den Prozessorcaches 1862A bis 1862D, 1856 betreffen, und Empfangen von Aktualisierungen vom Cache 1838).
Ein Satz von Registern 1845 speichert Kontextdaten für Threads, die durch die Grafikverarbeitungsmaschinen 1831 bis 1832, N ausgeführt werden, und eine Kontextverwaltungsschaltung 1848 verwaltet die Threadkontexte. Beispielsweise kann die Kontextverwaltungsschaltung 1848 Sicherungs- und Rückspeichervorgänge zum Sichern und Rückspeichern von Kontexten der verschiedenen Threads während Kontextumschaltungen ausführen (wobei beispielsweise ein erster Thread gesichert wird und ein zweiter Thread gespeichert wird, sodass der zweite Thread durch eine Grafikverarbeitungsmaschine ausgeführt werden kann). beispielsweise kann bei einer Kontextumschaltung die Kontextverwaltungsschaltung 1848 laufende Registerwerte in einen designierten Bereich im Speicher (beispielsweise durch einen Kontextzeiger identifiziert) speichern. Sie kann dann die Registerwerte bei der Rückkehr zum Kontext rückspeichern. In einer Ausführungsform empfängt und verwaltet eine Verwaltungsunterbrechungsschaltung 1847 Unterbrechungen, die von Systemgeräten empfangen werden.
In einer Implementierung werden virtuelle/effektive Adressen von einer Grafikverarbeitungsmaschine 1831 durch die MMU 1839 in reale/physikalische Adressen im Systemspeicher 1811 umgesetzt. Eine Ausführungsform der Beschleunigerintegrationsschaltung 1836 unterstützt mehrfache (beispielsweise 4, 8, 16) Grafikbeschleunigermodule 1846 und/oder andere Beschleunigergeräte. Das Grafikbeschleunigermodul 1846 kann für eine einzelne Anwendung, die auf dem Prozessor 1807 ausgeführt wird, dediziert sein oder von mehrfachen Anwendungen gemeinsam benutzt werden. In einer Ausführungsform ist eine virtualisierte Grafikausführungsumgebung dargestellt, in der die Ressourcen der Grafikverarbeitungsmaschinen 1831 bis 1832, N mit mehrfachen Anwendungen oder virtuellen Maschinen (VMs) geteilt werden. Die Ressourcen können in „Slices“ unterteilt werden, die verschiedenen VMs und/oder Anwendungen basierend auf den Verarbeitungsanforderungen und Prioritäten, welche mit den VMs und/oder Anwendungen assoziiert sind, zugewiesen werden.
Daher wirkt die Beschleunigerintegrationsschaltung als eine Brücke zum System für das Grafikbeschleunigungsmodul 1846 und versieht Adressumsetzungs- und Systemspeichercachedienste. Zudem kann die Beschleunigerintegrationsschaltung 1836 Virtualisierungseinrichtungen für den Hostprozessor zum Verwalten von Virtualisierung der Grafikverarbeitungsmaschinen, Unterbrechungen und Speicherverwaltung vorsehen.
Da Hardwareressourcen der Grafikverarbeitungsmaschinen 1831 bis 1832, N explizit auf den realen Adressraum, den der Hostprozessor 1807 sieht, abgebildet sind, kann jeglicher Hostprozessor diese Ressourcen direkt unter Benutzung eines effektiven Adresswerts aufrufen. Eine Funktion der Beschleunigerintegrationsschaltung 1836 ist in einer Ausführungsform die physikalische Trennung der Grafikverarbeitungsmaschinen 1831 bis 1832, N, sodass sie dem System als unabhängige Einheiten erscheinen.
Wie angegeben sind in der dargestellten Ausführungsform ein oder mehr Grafikspeicher 1833 bis 1834, M jeweils an jede der Grafikverarbeitungsmaschinen 1831 bis 1832, N gekoppelt. Die Grafikspeicher 1833 bis 1834, M speichern Anweisungen und Daten, die durch jede der Grafikverarbeitungsmaschinen 1831 bis 1832, N verarbeitet werden. Die Grafikspeicher 1833 bis 1834, M können flüchtige Speicher sein, wie etwa dynamische Direktzugriffsspeicher (DRAMs) (darunter gestapelte DRAMs), GDDR-Speicher (beispielsweise GDDR5, GDDR6) oder HBM, und/oder nichtflüchtige Speicher sein, wie etwa 3D XPoint oder Nano-Ram.
In einer Ausführungsform werden, um Datenverkehr über die Verbindung 1840 zu reduzieren, Vorspanntechniken benutzt, um zu gewährleisten, dass die Daten, die in den Grafikspeichern 1833 bis 1834, M gespeichert sind, Daten sind, die am häufigsten durch die Grafikverarbeitungsmaschinen 1831 bis 1832, M benutzt werden und vorzugsweise nicht durch die Kerne 1860A bis 1860D benutzt werden (zumindest nicht häufig). Gleicherweise versucht der Vorspannmechanismus, Daten, die von den Kernen (und vorzugsweise nicht von den Grafikverarbeitungsmaschinen 1831 bis 1832, M) benötigt werden, innerhalb der Caches 1862A bis 1862D der Kerne und des Systemspeichers 1811 zu halten.
18C stellt eine andere Ausführungsform dar, in der die Beschleunigerintegrationsschaltung 1836 innerhalb des Prozessors 1807 integriert ist. In dieser Ausführungsform kommunizieren die Grafikverarbeitungsmaschinen 1831 bis 1832, M direkt über die Hochgeschwindigkeitsverbindung 1840 zur Beschleunigerintegrationsschaltung 1836 über die Schnittstelle 1837 und die Schnittstelle 1835 (die wiederum jegliche Form von Bus oder Schnittstellenprotokoll nutzen können). Die Beschleunigerintegrationsschaltung 1836 kann dieselben Vorgänge wie jene ausführen, die bezüglich 18B beschrieben sind, jedoch potentiell mit einem höheren Durchsatz aufgrund ihrer engen Nähe zum Kohärenzbus 1862 und den Caches 1862A bis 1862D, 1826.
Eine Ausführungsform unterstützt unterschiedliche Programmiermodelle, darunter ein dediziertes Prozessprogrammiermodel (keine Grafikbeschleunigungsmodulvirtualisierung) und gemeinsame Programmiermodelle (mit Virtualisierung). Die Letzteren können Programmiermodelle beinhalten, die durch die Beschleunigerintegrationsschaltung 1836 gesteuert werden, und Programmiermodelle, die durch das Grafikbeschleunigungsmodul 1846 gesteuert werden.
In einer Ausführungsform des dedizierten Prozessmodells sind die Grafikverarbeitungsmaschinen 1831 bis 1832, N für eine einzelne Anwendung oder einen einzelnen Prozess unter einem einzelnen Betriebssystem dediziert. Die einzelne Anwendung kann andere Anwendungsanforderungen zu den Grafikmaschinen 1831 bis 1832, N schleusen, wodurch Virtualisierung innerhalb einer VM/Partition vorgesehen ist.
In den dedizierten Prozessprogrammiermodellen können die Grafikverarbeitungsmaschinen 1831 bis 1832, N durch mehrfache VM-/Anwendungspartitionen gemeinsam benutzt werden. Die gemeinsam benutzten Modelle erfordern einen Systemhypervisor zum Virtualisieren der Grafikverarbeitungsmaschinen 1831 bis 1832, N zum Ermöglichen von Zugriff durch jedes Betriebssystem. Für Einzelpartitionssysteme ohne Hypervisor gehören die Grafikverarbeitungsmaschinen 1831 bis 1832, N dem Betriebssystem. In beiden Fällen kann das Betriebssystem die Grafikverarbeitungsmaschinen 1831 bis 1832, N zum Vorsehen von Zugriff auf jeden Prozess oder jede Anwendung virtualisieren.
Für das gemeinsame Programmiermodell wählt das Grafikbeschleunigungsmodul 1846 oder eine individuelle Grafikverarbeitungsmaschine 1831 bis 1832, N ein Prozesselement unter Benutzung eines Prozesshandles aus. In einer Ausführungsform sind Prozesselemente im Systemspeicher 1811 gespeichert und unter Benutzung der hierin beschriebenen Umsetzungstechniken von effektiver Adresse zu realer Adresse aufrufbar. Das Prozesshandle kann ein implementierungsspezifischer Wert sein, der dem Hostprozess zugeführt wird, wenn er seinen Kontext in der Grafikverarbeitungsmaschine 1831 bis 1832, N registriert (d.h. Systemsoftware zum Hinzufügen des Prozesselements zur prozesselementverlinkten Liste aufruft). Die niedrigeren 16-Bits des Prozesshandles können der Versatz des Prozesselements innerhalb der prozesselementverlinkten Liste sein.
18D stellt ein beispielhaftes Beschleunigerintegrationsslice 1890 dar. Wie hierin verwendet, umfasst ein „Slice“ einen spezifizierten Abschnitt der Verarbeitungsressourcen der Beschleunigerintegrationsschaltung 1836. Anwendungseffektiver Adressraum 1882 innerhalb des Systemspeichers 1811 speichert Prozesselemente 1883. In einer Ausführungsform werden die Prozesselemente in Reaktion auf GPU-Aufrufe 1881 von Anwendungen 1880, die auf dem Prozessor 1807 laufen, gespeichert. Ein Prozesselement 1883 enthält den Prozesszustand für die entsprechende Anwendung 1880. Ein Arbeitsdeskriptor (WD) 1884, der im Prozesselement 1883 enthalten ist, kann eine einzelne Arbeitsaufgabe sein, die durch eine Anwendung angefordert wird, oder kann einen Zeiger zu einer Warteschlange von Arbeitsaufgaben enthalten. Im letzteren Fall ist der WD 1884 ein Zeiger zur Arbeitsaufgaben-Anforderungswarteschlange im Adressraum 1882 der Anwendung.
Das Grafikbeschleunigungsmodul 1846 und/oder die individuellen Grafikverarbeitungsmaschinen 1831 bis 1832, N können von allen oder einem Teilsatz der Prozesse im System gemeinsam benutzt werden. Ausführungsformen der Erfindung beinhalten eine Infrastruktur zum Einrichten des Prozesszustands und Senden eines WD 1884 an ein Grafikbeschleunigungsmodul 1846 zum Beginnen einer Arbeitsaufgabe in einer virtualisierten Umgebung.
In einer Implementierung ist das dedizierte Prozessprogrammierungsmodell implementierungsspezifisch. In diesem Modell besitzt ein einzelner Prozess das Grafikbeschleunigungsmodul 1846 oder eine individuelle Grafikverarbeitungsmaschine 1831. Da das Grafikbeschleunigungsmodul 1846 einem einzelnen Prozess gehört, initialisiert der Hypervisor die Beschleunigerintegrationsschaltung 1836 für die innehabende Partition, und das Betriebssystem initialisiert die Beschleunigerintegrationsschaltung 1836 für den innehabenden Prozess zu der Zeit, zu der das Grafikbeschleunigungsmodul 1846 zugeordnet wird.
Im Betrieb holt eine WD-Abholeinheit 1891 im Beschleunigerintegrationsslice 1890 den nächsten WD 1884 ab, der eine Anzeige der Arbeit enthält, die durch eine der Grafikverarbeitungsmaschinen des Grafikbeschleunigungsmoduls 1846 erledigt werden soll. Daten vom WD 1884 können in Registern 1845 gespeichert werden und durch die MMU 1839, Verwaltungsunterbrechungsschaltung 1847 und/oder Kontextverwaltungsschaltung 1846 benutzt werden, wie dargestellt. Beispielsweise enthält eine Ausführungsform der MMU 1839 Segment-/Seitenlaufschaltungen zum Zugreifen auf Segment-/Seitentabellen 1886 innerhalb des virtuellen Adressraums 1885 des OS. Die Verwaltungsunterbrechungsschaltung 1847 kann Unterbrechungsereignisse 1892 verarbeiten, die vom Grafikbeschleunigungsmodul 1846 empfangen werden. Beim Ausführen von Grafikvorgängen wird eine effektive Adresse 1893, die durch eine Grafikverarbeitungsmaschine 1831 bis 1832, N erzeugt wird, durch die MMU 1839 in eine reale Adresse umgesetzt.

In einer Ausführungsform wird derselbe Satz von Registern 1845 für jede Grafikverarbeitungsmaschine 1831 bis 1832, N und/oder das Grafikbeschleunigungsmodul 1846 dupliziert und kann durch den Hypervisor oder das Betriebssystem initialisiert werden. Jedes dieser duplizierten Register kann in einem Beschleunigerintegrationsslice 1890 aufgenommen werden. Beispielhafte Register, die durch den Hypervisor initialisiert werden können, sind in Tabelle 1 gezeigt. Tabelle 1 - Durch Hypervisor initialiserte Register

1	Slicesteuerregister
2	Bereichszeiger für für Realadressen (RA) eingeplante Prozesse
3	Autoritätsmaskenaufhebungsregister
4	Vektorunterbrechungstabelleneintragsversatz
5	Vektorunterbrechungstabelleneintragsgrenze
6	Zustandsregister
7	Logische Partition s-ID
8	Realadressen- (RA-) Hypervisorbeschleunigernutzungs-Eintragszeiger
9	Speicherbeschreibungsregister

Beispielhafte Register, die durch das Betriebssystem initialisiert werden können, sind in Tabelle 2 gezeigt. Tabelle 2 - Durch Betriebssystem initialisierte Register

1	Prozess- und Threadidentifikation
2	Effektivadressen- (EA-) Kontextsicherungs-/-rückspeicherzeiger
3	Virtuelladressen- (VA-) Beschleunigernutzungseintragszeiger
4	Virtuelladressen- (VA-) Speichersegmenttabellenzeiger
5	Autoritätsmaske
6	Arbeitsdeskriptor

In einer Ausführungsform ist jeder WD 1884 für ein bestimmtes Grafikbeschleunigungsmodul 1846 und/oder eine bestimmte Grafikverarbeitungsmaschine 1831 bis 1832, N spezifisch. Er enthält die gesamte Information, die eine Grafikverarbeitungsmaschine 1831 bis 1832, N zur Erledigung ihrer Arbeit erfordert, oder er kann ein Zeiger zu einer Speicherstelle sein, an der die Anwendung eine Befehlswarteschlange für Arbeit, die fertiggestellt werden soll, eingerichtet hat.
18E stellt zusätzliche Details für eine Ausführungsform eines gemeinsamen Modells dar. Diese Ausführungsform enthält einen Hypervisorrealadressraum 1898, in dem eine Prozesselementliste 1899 gespeichert ist. Der Hypervisorrealadressraum 1898 ist über einen Hypervisor 1896 zugänglich, der die Grafikbeschleunigungsmodulmaschinen für das Betriebssystem 1895 virtualisiert.
Die gemeinsamen Programmiermodelle ermöglichen es allen oder einem Teilsatz von Prozessen von allen oder einem Teilsatz von Partitionen im System, ein Grafikbeschleunigungsmodul 1846 zu benutzen. Es gibt zwei Programmiermodelle, bei denen das Grafikbeschleunigungsmodul 1846 gemeinsam von mehrfachen Prozessen und Partitionen benutzt wird: Zeitslice gemeinsam oder grafikgeleitet gemeinsam.
In diesem Modell besitzt der Systemhypervisor 1896 das Grafikbeschleunigungsmodul 1846 und macht seine Funktion für alle Betriebssysteme 1895 verfügbar. Damit ein Grafikbeschleunigungsmodul 1846 Virtualisierung durch den Systemhypervisor 1896 unterstützt, kann sich das Grafikbeschleunigungsmodul 1846 an die folgenden Anforderungen halten: 1) Eine Arbeitsaufgabenanforderung einer Anwendung muss autonom sein (d.h., der Zustand muss zwischen Arbeitsaufgaben nicht beibehalten werden), oder das Grafikbeschleunigungsmodul 1846 muss einen Kontextsicherungs- und - rückspeichermechanismus vorsehen. 2) Es wird vom Grafikbeschleunigungsmodul 1846 garantiert, dass eine Arbeitsaufgabe einer Anwendung in einer spezifizierten Zeitdauer abgeschlossen wird, einschließlich jeglicher Umsetzungsfehler, oder das Grafikbeschleunigungsmodul 1846 sieht die Fähigkeit zum Vorbelegen der Verarbeitung der Arbeitsaufgabe vor. 3) Dem Grafikbeschleunigungsmodul 1846 muss Fairness zwischen Prozessen garantiert sein, wenn es im geleiteten gemeinsamen Programmiermodell arbeitet.
In einer Ausführungsform wird für das gemeinsame Modell von der Anwendung 1880 erfordert, einen Systemaufruf des Betriebssystems 1895 mit einem Typ des Grafikbeschleunigungsmoduls 1846, einem Arbeitsdeskriptor (WD), einem Autoritätsmaskenregisterwert (AMR-Wert) und einem Kontextsicherungs-/-rückspeicherbereichszeiger (CSRP) durchzuführen. Der Typ des Grafikbeschleunigungsmoduls 1846 beschreibt die als Ziel gesetzte Beschleunigungsfunktion für den Systemaufruf. Der Typ des Grafikbeschleunigungsmoduls 1846 kann ein systemspezifischer Wert sein. Der WD ist spezifisch für das Grafikbeschleunigungsmodul 1846 formatiert und kann in der Form eines Befehls des Grafikbeschleunigungsmoduls 1846, eines Effektivadresszeigers zu einer benutzerdefinierten Struktur, eines Effektivadresszeigers zu einer Warteschlange von Befehlen oder jeglicher anderen Datenstruktur zum Beschreiben der Arbeit, die durch das Grafikbeschleunigungsmodul 1846 erledigt werden soll, sein. In einer Ausführungsform ist der AMR-Wert der AMR-Zustand, der für den laufenden Prozess zu benutzen ist. Der Wert, der dem Betriebssystem zugeführt wird, ähnelt einer Anwendungseinstellung des AMR. Wenn die Implementierungen der Beschleunigerintegrationsschaltung 1836 und des Grafikbeschleunigungsmoduls 1846 ein Benutzerautoritätsmaskenaufhebungsregister (UAMOR) nicht unterstützen, kann das Betriebssystem den laufenden UAMOR-Wert vor dem Leiten des AMR in den Hypervisoraufruf auf den AMR-Wert anwenden. Der Hypervisor 1896 kann optional den laufenden Autoritätsmaskenaufhebungsregisterwert (AMOR-Wert) vor dem Platzieren des AMR in das Prozesselement 1883 anwenden. In einer Ausführungsform ist der CSRP eines der Register 1845, das die effektive Adresse eines Bereichs im Adressraum 1882 der Anwendung für das Grafikbeschleunigungsmodul 1846 zum Sichern und Rückspeichern des Kontextzustands enthält. Dieser Zeiger ist optional, wenn es für keinen Zustand erforderlich ist, zwischen Arbeitsaufgaben gesichert zu werden, oder wenn eine Arbeitsaufgabe vorbelegt ist. Der Kontextsicherungs-/-rückspeicherbereich kann fixierter Systemspeicher sein.

Nach dem Empfangen des Systemaufrufs kann das Betriebssystem 1895 verifizieren, dass die Anwendung 1880 registriert wurde und ihr die Autorität zum Benutzen des Grafikbeschleunigungsmoduls 1846 verliehen wurde. Das Betriebssystem 1895 ruft dann den Hypervisor 1896 mit der Information auf, die in Tabelle 3 gezeigt ist. Tabelle 3 - OS-an-Hypervisor-Aufrufparameter

1	Ein Arbeitsdeskriptor (WD)
2	Ein Autoritätsmaskenregisterwert (AMR-Wert) (potentiell maskiert)
3	Ein Effektivadressen- (EA-) Kontextsicherungs-/- rückspeicherbereichszeiger (CSRP)
4	Eine Prozess-ID (PID) und optionale Thread-ID (TID)
5	Ein Virtuelladressen- (VA-) Beschleunigernutzungseintragszeiger (AURP)
6	Die virtuelle Adresse des Speichersegmenttabellenzeigers (SSTP)
7	Eine logische Unterbrechungsdienstzahl (LISN)

Nach dem Empfangen des Hypervisoraufrufs verifiziert der Hypervisor 1896, dass das Betriebssystem 1895 registriert wurde und ihm die Autorität zum Benutzen des Grafikbeschleunigungsmoduls 1846 verliehen wurde. Der Hypervisor 1896 gibt dann das Prozesselement 1883 in die prozesselementverlinkte Liste für den entsprechenden Typ des Grafikbeschleunigungsmoduls 1846. Das Prozesselement kann die Information enthalten, die in Tabelle 4 gezeigt ist. Tabelle 4 - Prozesselementinformation

1	Ein Arbeitsdeskriptor (WD)
2	Ein Autoritätsmaskenregisterwert (AMR-Wert) (potentiell maskiert)
3	Ein Effektivadressen- (EA-) Kontextsicherungs-/- rückspeicherbereichszeiger (CSRP)
4	Eine Prozess-ID (PID) und optionale Thread-ID (TID)
5	Ein Virtuelladressen- (VA-) Beschleunigernutzungseintragszeiger (AURP)
6	Die virtuelle Adresse des Speichersegmenttabellenzeigers (SSTP)
7	Eine logische Unterbrechungsdienstzahl (LISN)
8	Vektorunterbrechungstabelle, abgeleitet von den Hypervisoraufrufparametern
9	Ein Zustandsregisterwert (SR-Wert)
10	Eine logische Partitions-ID (LPID)
11	Ein Realadressen- (RA-) Hypervisorbeschleunigernutzungs-Eintragszeiger
12	Das Speicherdeskriptorregister (SDR)

In einer Ausführungsform initialisiert der Hypervisor mehrere Register 1845 von Beschleunigerintegrationsslices 1890.
Wie in 18F dargestellt, setzt eine Ausführungsform der Erfindung einen vereinigten Speicher ein, der über einen gemeinsamen virtuellen Speicheradressraum aufrufbar ist, welcher zum Zugriff auf die physikalischen Prozessorspeicher 1801 bis 1802 und GPU-Speicher 1820 bis 1823 benutzt wird. In dieser Implementierung nutzen Vorgänge, auf den GPUs 1810 bis 1830 ausgeführt werden, denselben virtuellen/effektiven Speicheradressraum zum Zugreifen auf die Prozessorspeicher 1801 bis 1802 und umgekehrt, wodurch Programmierbarkeit vereinfacht wird. In einer Ausführungsform wird ein erster Abschnitt des virtuellen/effektiven Adressraums dem Prozessorspeicher 1801 zugewiesen, ein zweiter Abschnitt dem zweiten Prozessorspeicher 1802, ein dritter Abschnitt dem GPU-Speicher 1820, usw. Der gesamte virtuelle/effektive Speicherraum (manchmal auch als der effektive Adressraum bezeichnet) wird dadurch über jeden der Prozessorspeicher 1801 bis 1802 und GPU-Speicher 1820 bis 1823 hinweg verteilt, wodurch es jeglichem Prozessor oder jeglicher GPU ermöglicht ist, auf jeglichen physikalischen Speicher mit einer virtuellen Adresse, die auf diesen Speicher abgebildet ist, zuzugreifen.
In einer Ausführungsform gewährleisten Vorspann-/Kohärenzverwaltungsschaltungen 1894A bis 1894E innerhalb einer oder mehr der MMUs 1839A bis 1839E Cachekohärenz zwischen den Caches der Hostprozessoren (beispielsweise 1805) und der GPUs 1810 bis 1813 und implementieren Vorspanntechniken, die die physikalischen Speicher anzeigen, in denen bestimmte Typen von Daten gespeichert werden sollten. Während mehrfache Elemente von Vorspann-/Kohärenzverwaltungsschaltungen 1894A bis 1894E in 18F dargestellt sind, können die Vorspann-/Kohärenzverwaltungsschaltungen innerhalb der MMU von einem oder mehr Hostprozessoren 1805 und/oder innerhalb der Beschleunigerintegrationsschaltung 1836 implementiert sein.
Eine Ausführungsform ermöglicht dem der GPU beigefügten Speicher 1820 bis 1823, dass er als Teil des Systemspeichers abgebildet wird und unter Benutzung von gemeinsamer virtueller Speichertechnologie (SVM-Technologie) auf ihn zugegriffen wird, jedoch ohne die typischen Ausführungsmängel zu erfahren, die mit völliger Systemcachekohärenz assoziiert sind. Die Fähigkeit, dass auf den der GPU beigefügten Speicher 1820 bis 1823 als Systemspeicher ohne lästigen Cachekohärenzoverhead zugegriffen wird, stellt eine günstige Betriebsumgebung für GPU-Auslagerung bereit. Diese Anordnung ermöglicht, dass die Software des Hostprozessors 1805 Operanden und Zugriffsrechnungsergebnisse ohne den Overhead von herkömmlichen E/A-DMA-Datenkopien einstellt. Derartige herkömmliche Kopien beinhalten Treiberaufrufe, Unterbrechungen und speicherabgebildete E/A- (MMIO-) Zugriffe, die alle relativ zu einfachen Speicherzugriffen ineffizient sind. Dabei kann die Fähigkeit zum Zugreifen auf die der GPU beigefügten Speicher 1820 bis 1823 ohne Cachekohärenzoverheads kritisch für die Ausführungszeit einer ausgelagerten Rechnung sein. In Fällen mit erheblichem Streaming-Schreibspeicherverkehr kann Cachekohärenzoverhead beispielsweise die effektive Schreibbandbreite, die von einer GPU 1810 bis 1813 gesehen wird, erheblich reduzieren. Die Effizienz von Operandeneinrichtung, die Effizienz von Ergebniszugriff und die Effizienz von GPU-Rechnung spielen alle eine Rolle beim Bestimmen der Effektivität von GPU-Auslagerung.
In einer Implementierung wird die Auswahl zwischen GPU-Vorspannung und Hostprozessorvorspannung durch eine Vorspannungsverfolgungsdatenstruktur betrieben. Es kann beispielsweise eine Vorspannungstabelle benutzt werden, die eine seitengranulare Struktur (d.h. gesteuert an der Granularität einer Speicherseite) sein kann, welche 1 oder 2 Bits pro der GPU beigefügten Speicherseite enthalten kann. Die Vorspannungstabelle kann in einem gestohlenen Speicherbereich von einem oder mehr, der GPU beigefügten Speichern 1810 bis 1813 implementiert sein, mit oder ohne einen Vorspannungscache in der GPU 1810 bis 1813 (beispielsweise zum Zwischenspeichern von häufig/kürzlich benutzten Einträgen der Vorspannungstabelle). Alternativ kann die gesamte Vorspannungstabelle innerhalb der GPU gehalten sein.
In einer Implementierung wird auf den Vorspannungstabelleneintrag, der mit jedem Zugriff auf den der GPU beigefügten Speicher 1820 bis 1823 assoziiert ist, vor dem tatsächlichen Zugriff auf den GPU-Speicher zugegriffen, wodurch die folgenden Vorgänge bewirkt werden. Zunächst werden lokale Anforderungen von der GPU 1810 bis 1813, die ihre Seite in der GPU-Vorspannung finden, direkt zu einem entsprechenden GPU-Speicher 1820 bis 1823 weitergeleitet. Lokale Anforderungen von der GPU, die ihre Seite in der Hostvorspannung finden, werden an den Prozessor 1805 weitergeleitet (beispielsweise über eine Hochgeschwindigkeitsverbindung, wie oben besprochen). In einer Ausführungsform vervollständigen Anforderungen vom Prozessor 1805, die die angeforderte Seite in der Hostprozessorvorspannung finden, die Anforderung wie eine normale Speicherauslesung. Alternativ können Anforderungen, die an eine durch die GPU vorgespannte Seite gerichtet sind, zur GPU 1810 bis 1813 weitergeleitet werden. Die GPU kann dann die Seite zu einer Hostprozessorvorspannung überführen, wenn sie die Seite derzeit nicht benutzt.
Der Vorspannungszustand einer Seite kann entweder durch einen softwarebasierten Mechanismus, einen hardwaregestützten softwarebasierten Mechanismus oder, für einen begrenzten Satz von Fällen, einen rein hardwarebasierten Mechanismus geändert werden.
Ein Mechanismus zum Ändern des Vorspannungszustands setzt einen API-Aufruf (beispielsweise OpenCL) ein, der seinerseits den Gerätetreiber der GPU aufruft, welcher seinerseits eine Nachricht an die GPU sendet (oder einen Befehlsdeskriptor in eine Warteschlange einreiht), die die GPU anweist, den Vorspannungszustand zu ändern und, für manche Übergänge, einen Cacheräumungsvorgang im Host auszuführen. Der Cacheräumungsvorgang ist für einen Übergang von der Vorspannung des Hostprozessors 1805 zur GPU-Vorspannung erforderlich, jedoch für den entgegengesetzten Übergang nicht erforderlich.
In einer Ausführungsform wird Cachekohärenz durch vorübergehendes Rendern von GPU-basierten Seiten beibehalten, die durch den Hostprozessor 1805 nicht zwischenspeicherbar sind. Zum Zugriff auf diese Seiten kann der Prozessor 1805 Zugriff von der GPU 1810 anfordern, die sofortigen Zugriff gewähren kann oder nicht, abhängig von der Implementierung. Daher ist es zum Verringern von Kommunikation zwischen dem Prozessor 1805 und der GPU 1810 günstig zu gewährleisten, dass GPU-basierte Seiten jene sind, die durch die GPU, jedoch nicht den Hostprozessor 1805 angefordert werden, und umgekehrt.
Grafikverarbeitungspipeline
19 stellt eine Grafikverarbeitungspipeline 1900 gemäß einer Ausführungsform dar. In einer Ausführungsform kann ein Grafikprozessor die dargestellte Grafikverarbeitungspipeline 1900 implementieren. Der Grafikprozessor kann innerhalb der parallelen Verarbeitungssubsysteme, wie hierin beschrieben, enthalten sein, wie etwa der parallele Prozessor 1600 von 16, der, in einer Ausführungsform eine Variante des parallelen Prozessors (der parallelen Prozessoren) 1512 von 15 ist. Die verschiedenen parallelen Verarbeitungssubsysteme können die Grafikverarbeitungspipeline 1900 über ein oder mehr Elemente der parallelen Verarbeitungseinheit (beispielsweise die parallele Verarbeitungseinheit 1602 von 16), wie hierin beschrieben, implementieren. Beispielsweise kann eine Shadereinheit (beispielsweise der Grafikmultiprozessor 1634 von 17) zum Ausführen der Funktionen von einer oder mehr einer Scheitelpunktverarbeitungseinheit 1904, einer Tesselierungssteuerungsverarbeitungseinheit 1908, einer Tesselierungsbewertungsverarbeitungseinheit 1912, einer Geometrieverarbeitungseinheit 1916 und einer Fragment-/Pixelverarbeitungseinheit 1924 konfiguriert sein. Die Funktionen eines Datenassemblers 1902, von Primitvassemblern 1906, 1914, 1918, einer Tesselierungseinheit 1910, eines Rasterers 1922 und einer Rasterbetriebseinheit 1926 können außerdem durch andere Verarbeitungsmaschinen innerhalb eines Verarbeitungsclusters (beispielsweise der Verarbeitungscluster 1614 von 17) und eine entsprechende Partitionseinheit (beispielsweise die Partitionseinheit 220A bis 220N von 16) ausgeführt werden. Die Grafikverarbeitungspipeline 1900 kann außerdem unter Benutzung von dedizierten Verarbeitungseinheiten für eine oder mehr Funktionen implementiert sein. In einer Ausführungsform können ein oder mehr Abschnitte der Grafikverarbeitungspipeline 1900 durch parallele Verarbeitungslogik innerhalb eines Mehrzweckprozessors (beispielsweise CPU) ausgeführt werden. In einer Ausführungsform können ein oder mehr Abschnitte der Grafikverarbeitungspipeline 1900 auf einen On-Chip-Speicher (beispielsweise der parallele Prozessorspeicher 1622, wie in 16) über eine Speicherschnittstelle 1928 zugreifen, die ein Element der Speicherschnittstelle 1618 von 16 sein kann.
In einer Ausführungsform ist der Datenassembler 1902 eine Verarbeitungseinheit, die Scheitelpunktdaten für Oberflächen und Primitive sammelt. Der Datenassembler 1902 gibt dann die Scheitelpunktdaten, darunter die Scheitelpunktattribute, an die Scheitelpunktverarbeitungseinheit 1904 aus. Die Scheitelpunktverarbeitungseinheit 1904 ist eine programmierbare Ausführungseinheit, die Scheitelpunktshaderprogramme ausführt, wodurch Scheitelpunktdaten wie durch die Scheitelpunktshaderprogramme spezifiziert beleuchtet und transformiert werden. Die Scheitelpunktverarbeitungseinheit 1904 liest Daten aus, die in Cache, lokalem oder Systemspeicher zum Gebrauch beim Verarbeiten der Scheitelpunktdaten gespeichert sind, und kann zum Transformieren der Scheitelpunktdaten von einer objektbasierten Koordinatendarstellung in einen Weltbereichskoordinatenraum oder einen normalisierten gerätekoordinatenraum programmiert sein.
Ein erstes Element eines Primitivassemblers 1906 empfängt Scheitelpunktattribute von der Scheitelpunktverarbeitungseinheit 1904. Der Primitivassembler 1906 liest gespeicherte Scheitelpunktattribute nach Bedarf aus und konstruiert Grafikprimitive zum Verarbeiten durch die Tesselierungssteuerungsverarbeitungseinheit 1908. Die Grafikprimitive enthalten Dreiecke, Liniensegmente, Punkte, Patches usw., wie sie durch verschiedene grafikverarbeitende Anwendungsprogrammierschnittstellen (APIs) unterstützt werden.
Die Tesselierungssteuerungsverarbeitungseinheit 1908 behandelt die Eingabescheitelpunkte als Steuerpunkte für einen geometrischen Patch. Die Steuerpunkte werden aus einer Eingabedarstellung vom Patch (beispielsweise den Basen des Patchs) in eine Darstellung transformiert, die zum Gebrauch in Oberflächenbewertung durch die Tesselierungsbewertungsverarbeitungseinheit 1912 geeignet ist. Die Tesselierungssteuerungsverarbeitungseinheit 1908 kann außerdem Tesselierungsfaktoren für Kanten von geometrischen Patches errechnen. Ein Tesselierungsfaktor gilt für eine einzelne Kante und quantifiziert eine ansichtsabhängige Detailebene, die mit der Kante assoziiert ist. Eine Tesselierungseinheit 1910 ist zum Empfangen der Tesselierungsfaktoren für Kanten eines Patchs und zum Tesselieren des Patchs in mehrfache geometrische Primitive, wie etwa Linien-, Dreiecks- oder Vierseitprimitive, konfiguriert, die an eine Tesselierungsbewertungsverarbeitungseinheit 1912 übertragen werden. Die Tesselierungsbewertungsverarbeitungseinheit 1912 wirkt auf parametrisierte Koordinaten des unterteilten Patchs ein, um eine Oberflächendarstellung und Scheitelpunktattribute für jeden Scheitelpunkt, der mit den geometrischen Primitiven assoziiert ist, zu erzeugen.
Ein zweites Element eines Primitivassemblers 1914 empfängt Scheitelpunktattribute von der Tesselierungsbewertungsverarbeitungseinheit 1912, liest gespeicherte Scheitelpunktattribute nach Bedarf aus und konstruiert Grafikprimitive zum Verarbeiten durch die Geometrieverarbeitungseinheit 1916. Die Geometrieverarbeitungseinheit 1916 ist eine programmierbare Ausführungseinheit, die Geometrieshaderprogramme zum Transformieren von Grafikprimitiven, die vom Primitivassembler 1814 empfangen werden, wie durch die Geometrieshaderprogramme spezifiziert ausführt. In einer Ausführungsform ist die Geometrieverarbeitungseinheit 1916 zum Unterteilen der Grafikprimitiven in ein oder mehr neue Grafikprimitive und Berechnen von Parametern programmiert, die zum Rastern der neuen Grafikprimitiven benutzt werden.
In manchen Ausführungsformen kann die Geometrieverarbeitungseinheit 1916 Elemente im Geometriestrom hinzufügen oder daraus löschen. Die Geometrieverarbeitungseinheit 1916 gibt die Parameter und Scheitelpunkte, die neue Grafikprimitive spezifizieren, an den Primitivassembler 1918 aus. Der Primitivassembler 1918 empfängt die Parameter und Scheitelpunkte von der Geometrieverarbeitungseinheit 1916 und konstruiert Grafikprimitive zur Verarbeitung durch eine Ansichtsfensterskalierungs-, Aussonderungs- und Clip-Einheit 1920. Die Geometrieverarbeitungseinheit 1916 liest Daten aus, die im parallelen Prozessorspeicher oder Systemspeicher zum Gebrauch beim Verarbeiten der Geometriedaten gespeichert sind. Die Ansichtsfensterskalierungs-, Aussonderungs- und Clip-Einheit 1920 führt Clippen, Aussondern und Ansichtsfensterskalieren aus und gibt verarbeitete Grafikprimitive an einen Rasterer 1922 aus.
Der Rasterer 1922 führt Tiefenaussondern und andere tiefenbasierte Optimierungen aus. Der Rasterer 1922 führt außerdem Scan-Konversion auf die neuen Grafikprimitive zum Erzeugen von Fragmenten und Ausgeben dieser Fragmente und von assoziierten Deckungsdaten an die Fragment-/Pixelverarbeitungseinheit 1924 aus. Die Fragment-/Pixelverarbeitungseinheit 1924 ist eine programmierbare Ausführungseinheit, die zum Ausführen von Fragmentshaderprogrammen oder Pixelshaderprogrammen konfiguriert ist. Die Fragment-/Pixelverarbeitungseinheit 1924 transformiert Fragmente oder Pixel, die vom Rasterer 1922 empfangen werden, wie durch die Fragment- oder Pixelshaderprogramme spezifiziert. Beispielsweise kann die Fragment-/Pixelverarbeitungseinheit 1924 zum Ausführen von Vorgängen, darunter u.a. Texturabbildung, Schattieren, Mischen, Texturkorrektur und Perspektivenkorrektur, zum Erzeugen von schattierten Fragmenten oder Pixeln, die an eine Rasterbetriebseinheit 1926 ausgegeben werden, programmiert sein. Die Fragment-/Pixelverarbeitungseinheit 1924 kann Daten auslesen, die entweder im parallelen Prozessorspeicher oder im Systemspeicher zum Gebrauch beim Verarbeiten der Fragmentdaten gespeichert sind. Fragment- oder Pixelshaderprogramme können zum Schattieren auf Abtast-, Pixel-, Kachel- oder anderen Granularitäten abhängig von der Abtastrate, die für die Verarbeitungseinheiten konfiguriert ist, konfiguriert sein.
Die Rasterbetriebseinheit 1926 ist eine Verarbeitungseinheit, die Rastervorgänge ausführt, darunter u.a. Stencil, Z-Test, Mischen und dergleichen, und Pixeldaten als verarbeitete Daten zur Speicherung im Grafikspeicher (beispielsweise der parallele Prozessorspeicher 1622, wie in 16, und/oder der Systemspeicher 1504, wie in 15), zur Anzeige auf dem einen oder mehr Anzeigengerät(en) 1510 oder zur weiteren Verarbeitung durch einen des einen oder mehr Prozessor(en) 1502 oder parallelen Prozessor(en) 1512 ausgibt. In manchen Ausführungsformen ist die Rasterbetriebseinheit 1926 zum Komprimieren von Z- oder Farbdaten, die in den Speicher geschrieben werden, oder Dekomprimieren von Z- oder Farbdaten, die aus dem Speicher ausgelesen werden, konfiguriert.
VORRICHTUNG UND VERFAHREN FÜR MERKMALSPUNKTVERFOLGUNG UNTER VERWENDUNG VON INTER-FRAME-VORAUSSAGE
Merkmalspunktverfolgung ist eine Technik, die in zahlreichen Videoverarbeitungs- und Grafikbereichen benutzt wird, wie etwa Structure from Motion (SFM) und Panoramaverarbeitung (wie beispielsweise für virtuelle Realitätsimplementierungen verwendet). Der erste Schritt für jegliche Implementierung ist Kamerakalibration, unter Verwendung von Merkmalspunktverfolgung zum Bestimmen der extrinsischen Parameter der Kamera, was ein komplexes Problem darstellt.
Merkmalspunktverfolgungs- und -abstimmungstechniken sollen Merkmalspunkte aus jedem Bild- oder Videostromframe erkennen. Merkmalspunkte werden dann zwischen Paaren von Bildern abgestimmt. Für jedes Paar von Bildern können Schlüsselpunktdeskriptoren unter Verwendung des Approximate Nearest Neighbor-Verfahrens zwischen dem Paar abgestimmt werden. 20 stellt einen beispielhaften Satz von Punkten aus einem ersten Bildframe 2001 dar, der auf einen zweiten Bildframe 2002 abgebildet ist, wie durch die Linien gezeigt, die die Punkte aus den zwei Bildframes verbinden. Statt Codieren des gesamten zweiten Frames können Vektoren zum Spezifizieren von Bewegung von Pixeln oder Sätzen von Pixeln vom ersten Bildframe 2001 zum zweiten Bildframe 2002 benutzt werden.
Decodierer-Inter-Frame-Voraussage ist eine weit verbreitete Technik zum Komprimieren von Videoströmen. Ein Voraussagewert wird aus dem laufenden Frame unter Benutzung eines vorher decodierten Frames oder Satzes von Frames abgeleitet. Moderne komprimierte Videobitstreamformate, wie etwa VP9, benutzen Inter-Frame-Voraussagetechniken. Ein Inter-Frame enthält mehrere Interblöcke, von denen jeder einen Bewegungsvektor enthält, der einen Versatz für einen Abschnitt des vorhergehenden Frames enthält, welcher als eine Voraussage für den laufenden Frame benutzt wird. Ein Beispiel ist in 21 dargestellt, die Blöcke mit unterschiedlichen Größen und entsprechenden Vektor-/Versatzdaten zeigt, welche Bewegung der Blöcke zwischen Frames anzeigen.
Eine Ausführungsform der Erfindung wendet Decodierer-Inter-Frame-Voraussagetechniken zum Verfolgen von Merkmalspunkten über verschiedene Bilder in einer Bildsequenz hinweg an. Durch Benutzung dieser Techniken wird der Suchbereich für Punktvergleiche und -abstimmung erheblich verringert. Da die Größe eines Interblocks typischerweise viel geringer als ein gesamter Frame ist, können diese Techniken zum Verringern der Rechenkomplexität des Merkmalspunktverfolgungsproblems benutzt werden.
In herkömmlichen Abstimmungsverfahren soll jeder Merkmalspunkt, der in Frame 0 erkannt wird, mit jedem Merkmalspunkt von Frame 1 verglichen werden. Obgleich eine Hochleistungsmatrixmultiplikation das Problem optimieren kann, bleibt die Rechenkomplexität hoch.
Wenn die Eingabedaten des Videostroms bewertet werden, bieten Inter-Frame-Techniken einen Weg zum Vereinfachen des Merkmalspunktabstimmungsproblems. Beispielsweise soll, wie 22 zeigt, wenn Frame 2201 ein Inter-Frame ist, Block b0 vom Referenzframe 2200 in Block b1 im laufenden Frame 1 gemäß einem assoziierten Bewegungsvektor überführt werden. Eine Ausführungsform der Erfindung erkennt, dass jegliche Merkmalspunkte, die in b0 liegen, ebenfalls in b1 überführt werden. Unter Benutzung dieser Inter-Frame- und Bewegungsvektordaten werden die Schlüsselpunkte zwischen zwei Inter-Frames nicht einer nach dem anderen miteinander verglichen. Stattdessen erscheinen die Schlüsselpunktpaare nur in Interblockpaaren zwischen Inter-Frames.
Die Größe eines Interblocks ist erheblich geringer als die Größe des gesamten Frames. Unter Verwendung von VP9 als Beispiel variiert die Größe eines Interblocks von 4x4 bis 64x64 Pixel. Aufgrund der erheblichen Größenunterschiede zwischen einem Frame und einem Interblock wird die Suche nach Merkmalspunktpaaren dramatisch vereinfacht.
Im Gegensatz zu herkömmlichen Merkmalspunktverfolgungsmechanismen projiziert eine Ausführungsform der Erfindung einen Schlüsselpunktkandidaten aus dem laufenden Frame durch den Bewegungsvektor auf den Referenzframe, findet dann seine n nächsten Punkte in seinem relativen Interblock im Referenzframe und berechnet nur seine Distanz zu diesen n nächsten Punkten. In einer Ausführungsform ist die „Distanz“ die Deskriptordistanz. Ein skaleninvarianter Merkmalstransformationsmerkmalspunkt (SIFT-Merkmalspunkt) weist einen 128-Bit-Längenmerkmalsvektor auf, der Werte für mehrfache Merkmale aufweisen kann. Daher umfasst die „Distanz“ zwischen zwei Punkten die Differenzen zwischen diesen Merkmalsvektoren.
23 stellt eine Ausführungsform einer Vorrichtung zum Implementieren dieser Techniken für einen laufenden Frame 2301 unter Benutzung eines Referenzframes 2300 und von assoziierten Bewegungsdaten 2305 (beispielsweise Interblockvektoren) dar. Die Komponenten, die in 23 dargestellt sind, können in Schaltungen, Software oder jeglicher Kombination davon implementiert sein. In einer Implementierung sind die dargestellten Komponenten innerhalb einer GPU integriert, wie etwa dem Grafikprozessor 800 in 8 (beispielsweise in einer Videodecodiereinheit innerhalb der GPU). In einer Ausführungsform sind manche der Komponenten innerhalb der Medienpipeline 830 implementiert und manche Komponenten unter Benutzung von Software implementiert, die auf der Ausführungslogik 850 ausgeführt wird. Die zugrundeliegenden Prinzipien der Erfindung sind jedoch auf keinerlei bestimmte Architekturanordnung beschränkt.
Ein Schlüsselpunktextraktor 2310 extrahiert Schlüsselpunkte aus dem laufenden Frame 2301 und einem Referenzframe 2300. Die Referenzframeschlüsselpunkte können in einer vorherigen Iteration extrahiert worden sein. Ein Punktprojektor 2320 benutzt die Bewegungsdaten 2305 zum Projizieren von Punkt p aus dem laufenden Frame 2301 auf Punkt p' im Referenzframe 2300 unter Benutzung des Bewegungsvektors für den assoziierten Interblock 2302A bis B.
Ein Nachbaridentifizierer 2330 identifiziert die n nächsten Merkmalspunkte von p' (beispielsweise p1 bis p5), und ein Punktfilter 2340 streicht jegliche dieser Punkte, die nicht auf demselben Interblock 2302A sind. Ein Distanzrechner bestimmt die Deskriptordistanz zwischen den ungefilterten Punkten und p'. In einer Ausführungsform wählt ein Vergleicher 2360 den Punkt 2370 aus, der die kürzeste Deskriptordistanz vom Punkt p' darstellt. Es kann außerdem eine Schwelle 2375 benutzt werden, sodass der Vergleicher 2360 bestimmt, ob jeder Punkt innerhalb einer definierten Schwellendistanz 2375 liegt, um den abgestimmten Punkt 2370 zu identifizieren.
Ein Verfahren gemäß einer Ausführungsform ist in 24 dargestellt. Das Verfahren kann auf der hierin beschriebenen System-/Prozessorarchitektur ausgeführt werden, ist jedoch auf keinerlei bestimmte System-/Prozessorarchitektur beschränkt.
Bei 2400 und 2401 werden Schlüsselpunkte aus Rahmen f0 bzw. f1 extrahiert. Bei 2402 wird ein Punkt p in den Rahmen f0 als p' unter Benutzung eines Bewegungsvektors projiziert, der mit dem Interblock von Punkt p assoziiert ist. Bei 2304 werden die 5 nächsten Merkmalspunkte p1 bis p5 von p' im Rahmen f0 identifiziert. Während in dieser Ausführungsform 5 Merkmalspunkte benutzt werden, können verschiedene andere Anzahlen benutzt werden, während die zugrundeliegenden Prinzipien der Erfindung immer noch erfüllt sind.
Bei 2404 werden jegliche Punkte, die nicht im entsprechenden Interblock (d.h. demselben Interblock wie p') liegen, gestrichen. Bei 2405 wird die Deskriptordistanz zwischen p' und einem oder mehr von p1 bis p5 (wobei diese Punkte bei 2404 nicht gestrichen wurden) berechnet. Bei 2406 werden Punkte, die eine spezifizierte Distanzschwelle erfüllen, identifiziert, und ein Punkt wird bei 2407 als eine Abstimmung identifiziert. Wie angegeben ist in einer Ausführungsform der abgestimmte Punkt 2407 der Punkt, der p' am nächsten liegt. In dieser Ausführungsform wird die Schwelle auf die derzeit kürzeste Distanz zwischen p' und einem von p1 bis p5 eingestellt. Wenn nachfolgend eine kürzere Distanz gemessen wird, wird die Schwelle durch diese Distanz ersetzt. Am Ende wird der nächste Punkt bei 2407 identifiziert.
Eine Simulation dieser Ausführungsform erbrachte die folgenden Ergebnisse, die die Effektivität und Leistungsfähigkeit dieser Techniken demonstrieren. Skaleninvariante Merkmalstransformation (SIFT) wird als das Schlüsselpunkterkennungsverfahren benutzt. Die Laufzeitumgebung ist MATLAB, und VP9 wird als das Videobitstromformat benutzt, wobei die ersten 100 Frames aus einem Videobitstrom extrahiert werden.
Nach dem Ausführen des SIFT-Schlüsselpunkterkennungsverfahrens auf 100 Frames und dem herkömmlichen Abstimmungsprozess wurden 29751 Punktpaare in sequentiellen Framepaaren aufgefunden. 25 stellt ein Beispiel zum Zeigen der abgestimmten Punktpaare zwischen einem laufenden Frame 2501 und seinem referenzierten Frame 2502 dar. Bezeichnenderweise waren 27462 Paare unter dem gesamten Satz von 29751 Paaren (92,3%) in entsprechenden Interblöcken, die durch Bewegungsvektoren abgestimmt wurden.

Beim Implementieren der Ausführungsformen der Erfindung wurden für das erste Framepaar (Frame 1 und Frame 2) 1270 bzw. 1226 Schlüsselpunktkandidaten gefunden, und 306 Paare waren abgestimmt. Die herkömmlichen Verfahren benötigten 0,118786 Sekunden zum Abstimmen, während die Ausführungsformen der Erfindung nur 0,015110 Sekunden benötigten. Die untenstehende Tabelle A zeigt die Daten der ersten Paare von Frames, wobei die durchschnittliche Beschleunigung 9,37 beträgt. TABELLE A

Framepaar	Zeitaufwand für herkömmliches Verfahren (/s)	Zeitaufwand für neues Verfahren (/s)	Beschleunigung (Male)
1-2	0,118786	0,015110	7,86
2-3	0,111996	0,013021	8,60
3-4	0,092141	0,012698	7,26
4-5	0,091761	0,009611	9,55
5-6	0,092317	0,010092	9,15
6-7	0,093795	0,010018	9,36
7-8	0,100225	0,009983	10,04
8-9	0,101731	0,009795	10,39
9-10	0,101489	0,008906	11,40
10-11	0,092331	0,009188	10,05
Gesamt			9,37

Zum Vereinfachen der Simulation werden alle Frames beginnend ab dem zweiten als Inter-Frames behandelt, die Nicht-Interblöcke werden gestrichen. In der Praxis können herkömmliche Abstimmungstechniken auf die Punkte in diesen Nicht-Inter-Frames und Nicht-Interblöcken zum Erzielen einer Genauigkeit von über 92,3% ausgeführt werden.
Es wird außerdem vorausgesetzt, dass die Referenzframes alle vorhergehende Frames sind, was nicht immer der Fall ist. Eine Ausführungsform der Erfindung benutzt dieselbe Referenzstrategie zum Aufzeichnen von mehrfachen Referenzframes wie bestehende Videodecodierer. Jedoch sind, da sich die meisten der 100 Frames in der Simulation auf einen vorhergehenden Frame beziehen, die Ergebnisse robust.
Zum Bewältigen von Verfolgungs-/Abstimmungsfehlgriffproblemen, in der Bedeutung, dass die Paare durch herkömmliche Verfahren erkannt würden, durch die Ausführungsformen der Erfindung jedoch nicht erkannt würden, erweitert eine Implementierung den Suchbereich im Referenzframe um einen spezifizierten Betrag außerhalb des Interblocks. In einer Ausführungsform wird davon ausgegangen, dass, wenn einige „Punktpaare“ in einem „Blockpaar“ gefunden werden, dann alle verwandten „Punktpaare“ existieren sollten. Der Suchbereich wird dann ausgeweitet, bis alle Punktpaare identifiziert sind.
Unter Benutzung dieser Techniken wurden weitere 460 Paare in der Simulation abgestimmt, wodurch die Genauigkeit auf 93,9% stieg. Zum Implementieren der hierin beschriebenen Techniken können ein SIFT-Schlüsselpunkterkennungsprozess und ein Verfolgungs-/Abstimmungsverfahren in einen Videostromdecodierer (beispielsweise in eine Medienverarbeitungseinheit einer GPU, wie etwa einen FPGA usw.) hinzugegeben werden.
Ausführungsformen der Erfindung können verschiedene Schritte enthalten, die oben beschrieben wurden. Die Schritte können in maschinenausführbaren Anweisungen verkörpert sein, die zum Veranlassen benutzt werden können, dass ein Mehrzweck- oder Spezialzweckprozessor die Schritte ausführt. Alternativ können diese Schritte durch spezifische Hardwarekomponenten, die festverdrahtete Logik zum Ausführen der Schritte enthalten, oder durch jegliche Kombination von programmierten Computerkomponenten und maßgearbeiteten Hardwarekomponenten ausgeführt werden.
Wie hierin beschrieben können sich Anweisungen auf spezifische Konfigurationen von Hardware beziehen, wie etwa anwendungsspezifische integrierte Schaltungen (ASICs), die zum Ausführen von bestimmten Vorgängen konfiguriert sind oder eine vorbestimmte Funktionalität oder Softwareanweisungen aufweisen, welche in einem Speicher gespeichert sind, der in einem nichtflüchtigen computerlesbaren Medium verkörpert ist. Daher können die Techniken, die in den Figuren gezeigt sind, unter Benutzung von Code und Daten, welche auf einem oder mehr elektronischen Geräten (beispielsweise einer Endstation, einem Netzwerkelement usw.) gespeichert und ausgeführt werden, implementiert werden. Derartige elektronische Geräte speichern und kommunizieren (intern und/oder mit anderen elektronischen Geräten über ein Netzwerk) Code und Daten unter Benutzung von maschinenlesbaren Computermedien, wie etwa nichtflüchtige maschinenlesbare Computerspeichermedien (beispielsweise Magnetplatten, optische Platten, Direktzugriffsspeicher, Festwertspeicher, Flashspeichergeräte, Phasenänderungsspeicher) und flüchtige maschinenlesbare Computerkommunikationsmedien (beispielsweise elektrische, optische, akustische oder eine andere Form von Ausbreitungssignalen - wie etwa Trägerwellen, Infrarotsignale, digitale Signale usw.).
Zudem enthalten derartige elektronische Geräte typischerweise einen Satz von einem oder mehr Prozessoren, die an eine oder mehr andere Komponenten gekoppelt sind, wie etwa ein oder mehr Speichergeräte (nichtflüchtige maschinenlesbare Speichermedien), Benutzereingabe-/- ausgabegeräte (beispielsweise eine Tastatur, ein Berührungsbildschirm und/oder eine Anzeige) und Netzwerkverbindungen. Die Verkopplung des Satzes von Prozessoren und anderen Komponenten erfolgt typischerweise über einen oder mehr Busse und Brücken (auch als Bussteuerungen bezeichnet). Das Speichergerät und Signale, die den Netzwerkverkehr tragen, repräsentieren jeweils ein oder mehr maschinenlesbare Speichermedien und maschinenlesbare Kommunikationsmedien. Daher speichert das Speichergerät eines jeweiligen elektronischen Geräts typischerweise Code und/oder Daten zur Ausführung auf dem Satz von einem oder mehr Prozessoren dieses elektronischen Geräts. Natürlich können ein oder mehr Teile einer Ausführungsform der Erfindung unter Benutzung von anderen Kombinationen von Software, Firmware und/oder Hardware implementiert werden. In dieser detaillierten Beschreibung wurden zu Erläuterungszwecken durchwegs zahlreiche spezifische Details dargelegt, um zu einem gründlichen Verständnis der vorliegenden Erfindung zu verhelfen. Es ist jedoch für den Fachmann offensichtlich, dass die Erfindung ohne manche dieser spezifischen Details praktisch umgesetzt werden kann. In bestimmten Fällen wurden allgemein bekannte Strukturen und Funktionen nicht in ausführlichem Detail beschrieben, um Verunklaren des Gegenstands der vorliegenden Erfindung zu vermeiden. Dementsprechend ist Wesen und Umfang der Erfindung hinsichtlich der folgenden Ansprüche zu beurteilen.

Claims

Verfahren, aufweisend: Extrahieren eines ersten Satzes von Schlüsselpunkten aus einem laufenden Frame und eines zweiten Satzes von Schlüsselpunkten aus einem Referenzframe; Projizieren eines Schlüsselpunkts p in den Referenzframe als p' basierend auf einem Bewegungsvektor, der mit einem Bereich im laufenden Frame assoziiert ist, in welchem der Schlüsselpunkt p gefunden wird; Lokalisieren von n Schlüsselpunkten im Referenzframe, die p' am nächsten liegen; und Abstimmen von einem der n Schlüsselpunkte im Referenzframe mit dem Schlüsselpunkt p im laufenden Frame basierend auf Deskriptordistanzen zwischen jedem der n Schlüsselpunkte und p'.
Verfahren nach Anspruch 1, wobei das Abstimmen Erzeugen von Deskriptordistanzen zwischen allen oder einem Teilsatz der n Schlüsselpunkte und Punkt p' und Identifizieren von einem der n Schlüsselpunkte, für den die Deskriptordistanz am kürzesten ist, enthält.
Verfahren nach Anspruch 2, ferner aufweisend: Streichen von einem oder mehr der n Schlüsselpunkte, die sich nicht in einem designierten Bereich des Referenzframes befinden.
Verfahren nach Anspruch 3, wobei der Bereich im laufenden Frame einen Interblock im laufenden Frame aufweist.
Verfahren nach Anspruch 4, wobei der designierte Bereich einen Interblock des Referenzframes aufweist, der dem Interblock des laufenden Frames entspricht.
Verfahren nach Anspruch 4, wobei der designierte Bereich einen Interblock des Referenzframes, der dem Interblock des laufenden Frames entspricht, und einen spezifizierten Bereich außerhalb eines Umfangs des Interblocks des Referenzframes aufweist.
Verfahren nach Anspruch 1, wobei das Abstimmen Erzeugen von Deskriptordistanzen zwischen allen oder einem Teilsatz der n Schlüsselpunkte und Punkt p' und Vergleichen von jeder der Deskriptordistanzen mit einer Schwelle enthält.
Verfahren nach Anspruch 7, wobei die Schwelle auf eine derzeit kürzeste Deskriptordistanz zwischen einem der n Schlüsselpunkte und Punkt p' eingestellt wird.
Verfahren nach Anspruch 1, ferner aufweisend: Projizieren von einem oder mehr zusätzlichen Schlüsselpunkten in den Referenzframe basierend auf Bewegungsvektoren, die mit Bereichen assoziiert sind, in welchen der eine oder mehr zusätzliche Schlüsselpunkte gefunden wird, und Abstimmen des einen oder mehr zusätzlichen Schlüsselpunkte im laufenden Frame mit einem oder mehr Schlüsselpunkten im Referenzframe basierend auf den Bewegungsvektoren.
Maschinenlesbares Medium mit darauf gespeichertem Programmcode, der, wenn er durch eine Maschine ausgeführt wird, veranlasst, dass die Maschine folgende Vorgänge ausführt: Extrahieren eines ersten Satzes von Schlüsselpunkten aus einem laufenden Frame und eines zweiten Satzes von Schlüsselpunkten aus einem Referenzframe; Projizieren eines Schlüsselpunkts p in den Referenzframe als p' basierend auf einem Bewegungsvektor, der mit einem Bereich im laufenden Frame assoziiert ist, in welchem der Schlüsselpunkt p gefunden wird; Lokalisieren von n Schlüsselpunkten im Referenzframe, die p' am nächsten liegen; und Abstimmen von einem der n Schlüsselpunkte im Referenzframe mit dem Schlüsselpunkt p im laufenden Frame basierend auf Deskriptordistanzen zwischen jedem der n Schlüsselpunkte und p'.
Maschinenlesbares Medium nach Anspruch 10, wobei das Abstimmen Erzeugen von Deskriptordistanzen zwischen allen oder einem Teilsatz der n Schlüsselpunkte und Punkt p' und Identifizieren von einem der n Schlüsselpunkte, für den die Deskriptordistanz am kürzesten ist, enthält.
Maschinenlesbares Medium nach Anspruch 11, ferner aufweisend Programmcode zum Veranlassen, dass die Maschine die folgenden Vorgänge ausführt: Streichen von einem oder mehr der n Schlüsselpunkte, die sich nicht in einem designierten Bereich des Referenzframes befinden.
Maschinenlesbares Medium nach Anspruch 12, wobei der Bereich im laufenden Frame einen Interblock im laufenden Frame aufweist.
Maschinenlesbares Medium nach Anspruch 13, wobei der designierte Bereich einen Interblock des Referenzframes aufweist, der dem Interblock des laufenden Frames entspricht.
Maschinenlesbares Medium nach Anspruch 13, wobei der designierte Bereich einen Interblock des Referenzframes, der dem Interblock des laufenden Frames entspricht, und einen spezifizierten Bereich außerhalb eines Umfangs des Interblocks des Referenzframes aufweist.
Maschinenlesbares Medium nach Anspruch 10, wobei das Abstimmen Erzeugen von Deskriptordistanzen zwischen allen oder einem Teilsatz der n Schlüsselpunkte und Punkt p' und Vergleichen von jeder der Deskriptordistanzen mit einer Schwelle enthält.
Maschinenlesbares Medium nach Anspruch 16, wobei die Schwelle auf eine derzeit kürzeste Deskriptordistanz zwischen einem der n Schlüsselpunkte und Punkt p' eingestellt ist.
Maschinenlesbares Medium nach Anspruch 10, ferner aufweisend Programmcode zum Ausführen der folgenden Vorgänge: Projizieren von einem oder mehr zusätzlichen Schlüsselpunkten in den Referenzframe basierend auf Bewegungsvektoren, die mit Bereichen assoziiert sind, in welchen der eine oder mehr zusätzliche Schlüsselpunkte gefunden wird, und Abstimmen des einen oder mehr zusätzlichen Schlüsselpunkte im laufenden Frame mit einem oder mehr Schlüsselpunkten im Referenzframe basierend auf den Bewegungsvektoren.
Vorrichtung, aufweisend: einen Schlüsselpunktextraktor zum Extrahieren eines ersten Satzes von Schlüsselpunkten aus einem laufenden Frame und eines zweiten Satzes von Schlüsselpunkten aus einem Referenzframe; einen Punktprojektor zum Projizieren eines Schlüsselpunkts p in den Referenzframe als p' basierend auf einem Bewegungsvektor, der mit einem Bereich im laufenden Frame assoziiert ist, in welchem der Schlüsselpunkt p gefunden wird; einen Nachbaridentifizierer zum Lokalisieren von n Schlüsselpunkten im Referenzframe, die p' am nächsten liegen; und einen Schlüsselpunktabstimmer zum Abstimmen von einem der n Schlüsselpunkte im Referenzframe mit dem Schlüsselpunkt p im laufenden Frame basierend auf Deskriptordistanzen zwischen jedem der n Schlüsselpunkte und p'.
Vorrichtung nach Anspruch 19, wobei das Abstimmen Erzeugen von Deskriptordistanzen zwischen allen oder einem Teilsatz der n Schlüsselpunkte und Punkt p' und Identifizieren von einem der n Schlüsselpunkte, für den die Deskriptordistanz am kürzesten ist, enthält.
Vorrichtung nach Anspruch 20, ferner aufweisend: Streichen von einem oder mehr der n Schlüsselpunkte, die sich nicht in einem designierten Bereich des Referenzframes befinden.
Vorrichtung nach Anspruch 21, wobei der Bereich im laufenden Frame einen Interblock im laufenden Frame aufweist.
Vorrichtung nach Anspruch 22, wobei der designierte Bereich einen Interblock des Referenzframes aufweist, der dem Interblock des laufenden Frames entspricht.
Vorrichtung nach Anspruch 22, wobei der designierte Bereich einen Interblock des Referenzframes, der dem Interblock des laufenden Frames entspricht, und einen spezifizierten Bereich außerhalb eines Umfangs des Interblocks des Referenzframes aufweist.
Vorrichtung nach Anspruch 19, wobei das Abstimmen Erzeugen von Deskriptordistanzen zwischen allen oder einem Teilsatz der n Schlüsselpunkte und Punkt p' und Vergleichen von jeder der Deskriptordistanzen mit einer Schwelle enthält.
Vorrichtung nach Anspruch 25, wobei die Schwelle auf eine derzeit kürzeste Deskriptordistanz zwischen einem der n Schlüsselpunkte und Punkt p' eingestellt ist.
Vorrichtung nach Anspruch 19, wobei der Punktprojektor zum Projizieren von einem oder mehr zusätzlichen Schlüsselpunkten in den Referenzframe basierend auf Bewegungsvektoren, die mit Bereichen assoziiert sind, in welchen der eine oder mehr zusätzliche Schlüsselpunkte gefunden wird, dient und der Punktabstimmer zum Abstimmen des einen oder mehr zusätzlichen Schlüsselpunkte im laufenden Frame mit einem oder mehr Schlüsselpunkten im Referenzframe basierend auf den Bewegungsvektoren dient.