DE112020000464T5

DE112020000464T5 - Mehrfachkachel-grafikprozessor-rendering

Info

Publication number: DE112020000464T5
Application number: DE112020000464.3T
Authority: DE
Inventors: Prasoonkumar Surti; Arthur Hunter; Kamal Sinha; Scott Janus; Brent Insko; Vasanth Ranganathan; Lakshminarayanan Striramassarma
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2019-03-15
Filing date: 2020-02-12
Publication date: 2021-11-25
Also published as: US20220058852A1; CN113424229A; US11145105B2; WO2020190432A1; US20200294301A1

Abstract

Ausführungsformen betreffen im Allgemeinen das Mehrkachel-Grafikprozessor-Rendering. Eine Ausführungsform einer Einrichtung beinhaltet Folgendes: einen Speicher zur Speicherung von Daten; und einen oder mehrere Prozessoren einschließlich einer Grafikverarbeitungseinheit (GPU) zum Verarbeiten von Daten, wobei die GPU mehrere GPU-Kacheln beinhaltet, wobei die Einrichtung, nachdem geometrische Daten jeder mehrerer Bildschirmkacheln zugewiesen wurden, die geometrischen Daten an die mehreren GPU-Kacheln übertragen soll.

Description

VERWANDTE ANMELDUNGEN
Diese Anmeldung beansprucht den Nutzen der US-Anmeldung Nr. 16/355,364 , eingereicht am 15. März 2019, deren gesamter Inhalt hiermit durch Bezugnahme aufgenommen wird.
TECHNISCHES GEBIET
Hierin beschriebene Ausführungsformen betreffen im Allgemeinen das Gebiet elektronischer Vorrichtungen und insbesondere Mehrfachkachel-Grafikprozessor-Rendering.
HINTERGRUND
Die aktuelle parallele Grafikdatenverarbeitung beinhaltet Systeme und Verfahren, die entwickelt wurden, um spezielle Operationen an Grafikdaten auszuführen, wie beispielsweise lineare Interpolation, Tessellation, Rasterung, Texturabbildung, Tiefentestung usw. Traditionell haben Grafikprozessoren Festfunktions-Recheneinheiten verwendet, um Grafikdaten zu verarbeiten; in jüngster Zeit wurden Teile von Grafikprozessoren jedoch programmierbar gemacht, wodurch ermöglicht wurde, dass solche Prozessoren eine größere Vielfalt an Operationen zur Verarbeitung von Vertex- und Fragmentdaten unterstützen.
Um die Leistungsfähigkeit weiter zu verbessern, implementieren Grafikprozessoren typischerweise Verarbeitungstechniken wie Pipelining, bei denen versuchet wird, parallel so viele Grafikdaten wie möglich in den verschiedenen Teilen der Grafik-Pipeline zu verarbeiten. Parallele Grafikprozessoren mit SIMT-Architekturen (SIMT: Single Instruction, Multiple Thread) sind darauf ausgelegt, das Ausmaß der Parallelverarbeitung in der Grafik-Pipeline zu maximieren. In einer SIMT-Architektur versuchen Gruppen von parallelen Threads, Programmanweisungen so oft wie möglich synchron gemeinsam auszuführen, um die Verarbeitungseffizienz zu erhöhen. Eine allgemeine Übersicht über Software und Hardware für SIMT-Architekturen findet sich in Shane Cook, CUDA Programming Kapitel 3, Seiten 37-51 (2013).
Bei der Entwicklung neuer Grafikprozessoren kann ein Prozessor so gestaltet sein, dass er mehrere Kacheln (die auch als Chiplets bezeichnet werden können) anstelle eines einzigen Computer-Die enthält. Die herkömmliche Speicherung geometrischer Daten kann jedoch problematisch sein, wenn der Grafikprozessor aus mehreren Kacheln besteht. Beispielsweise müssen Nach-Raster-Geometriedaten in der Rasterreihenfolge zusammengestellt werden. Wenn herkömmliche Technologien auf die mehrere Kacheln erweitert werden, können Attributdaten aus verschiedenen Kacheln gezogen werden, wenn die Geometrie über Kacheln hinweg zerstückelt werden darf. Dies ist verschwenderisch, um Daten von Kachel zu Kachel zu verschieben, und eine Backend-Engine wäre erforderlich, um eine Latenz von einem Kachel-zu-Kachel-Abruf zu verbergen.
Figurenliste
Hier beschriebene Ausführungsformen sind beispielhaft und nicht einschränkend in den Figuren der beigefügten Zeichnungen veranschaulicht, in denen sich gleiche Bezugszeichen auf ähnliche Elemente beziehen.

1 ist ein Blockdiagramm, das ein Computersystem veranschaulicht, das zum Implementieren eines oder mehrerer Aspekte der hierin beschriebenen Ausführungsformen konfiguriert ist;
2A-2D veranschaulichen parallele Prozessorkomponenten gemäß einer Ausführungsform;
3A-3C sind Blockdiagramme von Grafikmultiprozessoren und multiprozessorbasierten GPUs gemäß Ausführungsformen;
4A-4F veranschaulichen eine beispielhafte Architektur, in der mehrere GPUs kommunikativ mit mehreren Mehrkernprozessoren gekoppelt sind;
5 veranschaulicht eine Grafikverarbeitungs-Pipeline gemäß einer Ausführungsform;
6 veranschaulicht einen Maschinenlern-Softwarestapel gemäß einer Ausführungsform;
7 veranschaulicht eine Mehrzweckgrafikverarbeitungseinheit gemäß einer Ausführungsform;
8 veranschaulicht ein Multi-GPU-Rechensystem gemäß einer Ausführungsform;
9A-9B veranschaulichen Schichten beispielhafter tiefer neuronaler Netze;
10 veranschaulicht ein beispielhaftes rekurrentes neuronales Netz;
11 veranschaulicht Training und Einsatz eines tiefen neuronalen Netzes;
12 ist ein Blockdiagramm, das verteiltes Lernen veranschaulicht;
13 veranschaulicht ein beispielhaftes Inferenzsystem auf einem Chip (SOC), das zum Durchführen einer Inferenz unter Verwendung eines trainierten Modells geeignet ist;
14A ist eine Darstellung eines Mehrfachkachel-Grafikprozessors gemäß manchen Ausführungsformen;
14B ist eine Darstellung einer Mehrfachkachel-GPU, die Geometrie-Hashing über Kacheln mit Zeichnungs- oder Objektgranularität bereitstellt, gemäß manchen Ausführungsformen,
15A ist eine Darstellung einer geometrischen Datenverteilung in einer Mehrfachkachel-GPU gemäß manchen Ausführungsformen;
15B ist eine Darstellung einer Kachel basierend auf dem Sammeln von Dreiecken pro Kachel gemäß manchen Ausführungsformen;
16A ist eine Veranschaulichung einer mehrstufigen GPU-Architektur zur Skalierung der Leistungsfähigkeit mit Mesh-Shading;
16B ist eine Darstellung eines Stream-Out von Mesh-Shader-Daten zur Kompression gemäß manchen Ausführungsformen;
17 ist ein Blockdiagramm eines Verarbeitungssystems gemäß einer Ausführungsform;
18 ist ein Blockdiagramm eines Prozessors gemäß einer Ausführungsform;
19 ist ein Blockdiagramm einer Grafikprozessors gemäß einer Ausführungsform;
20 ist ein Blockdiagramm einer Grafikverarbeitungs-Engine eines Grafikprozessors gemäß manchen Ausführungsformen;
21 ist ein Blockdiagramm einer Hardwarelogik eines Grafikprozessorkerns gemäß manchen hierin beschriebenen Ausführungsformen;
22A-22B veranschaulichen eine Thread-Ausführungslogik einschließlich eines Arrays von Verarbeitungselementen, die in einem Grafikprozessorkern verwendet werden, gemäß hierin beschriebenen Ausführungsformen;
23 ist ein Blockdiagramm, das Grafikprozessoranweisungsformate gemäß manchen Ausführungsformen veranschaulicht;
24 ist ein Blockdiagramm eines Grafikprozessors gemäß einer anderen Ausführungsform;
25A-25B veranschaulichen ein Grafikprozessor-Befehlsformat und - Befehlssequenz gemäß manchen Ausführungsformen;
26 veranschaulicht eine beispielhafte Grafiksoftwarearchitektur für ein Datenverarbeitungssystem gemäß manchen Ausführungsformen;
27A ist ein Blockdiagramm, das ein IP-Kern-Entwicklungssystem gemäß einer Ausführungsform veranschaulicht;
27B veranschaulicht eine Querschnittsseitenansicht einer Package-Baugruppe einer integrierten Schaltung gemäß manchen hierin beschriebenen Ausführungsformen,
28 ist ein Blockdiagramm, das eine beispielhafte integrierte Systemauf-Chip-Schaltung gemäß einer Ausführungsform veranschaulicht; und
29A-29B sind Blockdiagramme, die beispielhafte Grafikprozessoren zur Verwendung in einem SoC gemäß hierin beschriebenen Ausführungsformen veranschaulichen.

AUSFÜHRLICHE BESCHREIBUNG
Hierin beschriebene Ausführungsformen betreffen im Allgemeinen das Mehrkachel-Grafikprozessor-Rendering.
Eine Mehrfachkachel-Grafikprozessorarchitektur kann eine Möglichkeit bieten, die dreidimensionale (3D-) Rendering-Leistungsfähigkeit zu skalieren, indem ein Geometrie-Hash über Kacheln hinweg verwendet wird. Während jedoch Geometriedaten lokal auf der Kachel behalten werden, benötigt das Raster Daten von verschiedenen Kacheln, da die Geometrie zum Rasterzeitpunkt teilweise vollständig im Besitz der gegebenen Kachel sein kann und die Position der tatsächlichen Geometriedaten möglicherweise nicht lokal ist. Dies stört die Skalierungsleistungsfähigkeit für einen Mehrfachkachel-Grafikprozessor.
Bei manchen Ausführungsformen stellt eine Einrichtung, ein System oder ein Prozess eines oder mehrere von Folgendem bereit:

(1) Geometrie-Hashing über Kacheln mit Zeichnungs- oder Objektgranularität.
(2) Geometriedaten pro Kachel, die sich lokal in jeder der mehreren Kacheln befinden.
(3) Kachelbasiertes Rendering zum Sammeln aller Dreiecke pro Kachelzuordnung zu einer oder mehreren bildschirmausgerichteten Kacheln aus demselben Rendering-Durchgang.
(4) Mehrstufige GPU-Architektur zur Skalierung der Leistungsfähigkeit mit Mesh-Shading; und
(5) Stream-Out von Mesh-Shader-Daten.

Bei manchen Ausführungsformen ist eine Grafikverarbeitungseinheit (GPU) kommunikativ mit Host-/Prozessorkernen gekoppelt, um Grafikoperationen, Maschinenlernoperationen, Musteranalyseoperationen und verschiedene Mehrzweck-GPU(GPGPU)-Funktionen zu beschleunigen. Die GPU kann über einen Bus oder einen anderen Interconnect (z. B. ein Hochgeschwindigkeits-Interconnect, wie PCIe oder NVLink) kommunikativ mit dem Hostprozessor/Kernen verbunden sein. In anderen Ausführungsformen kann die GPU auf demselben Package oder Chip wie die Kerne integriert sein und über einen internen Prozessorbus/Interconnect(d. h. innerhalb des Packages oder Chips) kommunikativ mit den Kernen gekoppelt sein. Unabhängig von der Art und Weise, auf welche die GPU verbunden ist, können die Prozessorkerne der GPU Arbeit in Form von in einem Arbeitsdeskriptor enthaltenen Sequenzen von Befehlen/Anweisungen zuweisen. Die GPU verwendet dann eine dedizierte Schaltungsanordnung/Logik zum effizienten Verarbeiten dieser Befehle/Anweisungen.
In der folgenden Beschreibung werden zahlreiche spezielle Einzelheiten dargelegt, um ein umfassenderes Verständnis bereitzustellen. Fachleute werden jedoch erkennen, dass die hierin beschriebenen Ausführungsformen ohne eine oder mehrere dieser speziellen Einzelheiten in die Praxis umgesetzt werden können. In anderen Fällen wurden wohlbekannte Merkmale nicht beschrieben, um die Einzelheiten der vorliegenden Ausführungsformen nicht unklar zu machen.
Systemübersicht
1 ist ein Blockdiagramm, das ein Rechensystem 100 veranschaulicht, das dazu ausgelegt ist, einen oder mehrere Aspekte der hierin beschriebenen Ausführungsformen zu implementieren. Das Rechensystem 100 beinhaltet ein Verarbeitungssubsystem 101 mit einem oder mehreren Prozessor(en) 102 und einem Systemspeicher 104, die über einen Interconnect-Pfad, der einen Speicherhub 105 aufweisen kann, kommunizieren. Der Speicherhub 105 kann eine separate Komponente innerhalb einer Chipsatzkomponente sein oder kann in dem einen oder den mehreren Prozessor(en) 102 integriert sein. Der Speicherhub 105 ist über eine Kommunikationsverbindung 106 mit einem E/A-Subsystem 111 gekoppelt. Das E/A-Subsystem 111 beinhaltet einen E/A-Hub 107, der ermöglichen kann, dass das Rechensystem 100 eine Eingabe von einer oder mehreren Eingabevorrichtung(en) 108 empfängt. Außerdem kann der E/A-Hub 107 ermöglichen, dass eine Anzeigesteuerung, die in dem einen oder den mehreren Prozessor(en) 102 enthalten sein kann, einer oder mehreren Anzeigevorrichtung(en) 110A Ausgaben bereitstellt. In einer Ausführungsform können die eine oder die mehreren Anzeigevorrichtung(en) 110A, die mit dem E/A-Hub 107 gekoppelt sind, eine lokale, interne oder eingebettete Anzeigevorrichtung beinhalten.
In einer Ausführungsform beinhaltet das Verarbeitungssubsystem 101 einen oder mehrere Parallelprozessor(en) 112, die über einen Bus oder eine andere Kommunikationsverbindung 113 mit dem Speicherhub 105 gekoppelt sind. Die Kommunikationsverbindung 113 kann eine/eines von einer beliebigen Anzahl von auf Standards basierenden Kommunikationsverbindungstechnologien oder -protokollen sein, wie unter anderem PCI Express, oder kann eine anbieterspezifische Kommunikationsschnittstelle oder Kommunikations-Fabric sein. In einer Ausführungsform bilden der eine oder die mehreren Parallelprozessor(en) 112 ein rechnerisch fokussiertes Parallel- oder Vektorverarbeitungssystem, das eine große Anzahl von Verarbeitungskernen und/oder Verarbeitungsclustern beinhalten kann, wie etwa einen MIC-Prozessor (MIC: Many Integrated Core). In einer Ausführungsform bilden der eine oder die mehreren Parallelprozessor(en) 112 ein Grafikverarbeitungssubsystem, das Pixel an eine der einen oder mehreren Anzeigevorrichtung(en) 110A, die über den E/A-Hub 107 gekoppelt sind, ausgeben kann. Der eine oder die mehreren Parallelprozessor(en) 112 können auch eine Anzeigesteuerung und eine Anzeigeschnittstelle (nicht dargestellt) aufweisen, um eine direkte Verbindung mit einer oder mehreren Anzeigevorrichtung(en) 110B zu ermöglichen.
Innerhalb des E/A-Subsystems 111 kann eine Systemspeicherungseinheit 114 eine Verbindung mit dem E/A-Hub 107 herstellen, um einen Speicherungsmechanismus für das Rechensystem 100 bereitzustellen. Ein E/A-Schalter 116 kann verwendet werden, um einen Schnittstellenmechanismus bereitzustellen, um Verbindungen zwischen dem E/A-Hub 107 und anderen Komponenten, wie etwa einem Netzwerkadapter 118 und/oder einem drahtlosen Netzwerkadapter 119, die in der Plattform integriert sein können, und verschiedenen anderen Vorrichtungen, die über eine oder mehrere Add-In-Vorrichtung(en) 120 hinzugefügt werden können, zu ermöglichen. Der Netzwerkadapter 118 kann ein Ethernet-Adapter oder ein anderer drahtgebundener Netzwerkadapter sein. Der drahtlose Netzwerkadapter 119 kann eine oder mehrere einer Wi-Fi-, Bluetooth-, Nahfeldkommunikations(NFC)- oder einer anderen Netzwerkvorrichtung beinhalten, die eine oder mehrere drahtlose Funkgeräte aufweist.
Das Rechensystem 100 kann andere Komponenten beinhalten, die nicht explizit gezeigt sind, darunter USB- oder andere Port-Verbindungen, optische Speicherungslaufwerke, Videoaufnahmevorrichtungen und dergleichen, die auch mit dem E/A-Hub 107 verbunden sein können. Kommunikationswege, die die verschiedenen Komponenten in 1 miteinander verbinden, können unter Verwendung beliebiger geeigneter Protokolle implementiert werden, wie etwa PCI(Peripheral-Component-Interconnect)-basierte Protokolle (zum Beispiel PCI-Express) oder beliebige andere Bus- oder Punkt-zu-Punkt-Kommunikationsschnittstellen und/oder -Protokoll(e), wie etwa der NV-Link-Hochgeschwindigkeits-Interconnect oder im Stand der Technik bekannte Interconnect-Protokolle.
In einer Ausführungsform umfassen der eine oder die mehreren Parallelprozessor(en) 112 eine Schaltungsanordnung, die für Grafik- und Videoverarbeitung optimiert ist, darunter beispielsweise eine Videoausgabeschaltungsanordnung, und eine Grafikverarbeitungseinheit (GPU) bildet. In einer anderen Ausführungsform umfassen der eine oder die mehreren Parallelprozessor(en) 112 eine Schaltungsanordnung, die zur Mehrzweckverarbeitung optimiert ist, während die zugrundeliegende Rechenarchitektur erhalten bleibt, die hier ausführlicher beschrieben wird. In noch einer anderen Ausführungsform können Komponenten des Rechensystems 100 mit einem oder mehreren anderen Systemelementen auf einer einzigen integrierten Schaltung integriert sein. Zum Beispiel können der eine oder die mehreren Parallelprozessor(en) 112, Speicherhub 105, Prozessor(en) 102 und E/A-Hub 107 in einer integrierten System-auf-Chip(SoC)-Schaltung integriert sein. Alternativ können die Komponenten des Rechensystems 100 in einem einzigen Package integriert sein, um eine System-in-Package(SIP)-Konfiguration zu bilden. Bei einer Ausführungsform kann mindestens ein Teil der Komponenten des Rechensystems 100 in einem Multi-Chip-Modul (MCM) integriert sein, das mit anderen Multi-Chip-Modulen zu einem modularen Rechensystem verschaltet sein kann.
Es versteht sich, dass das hier gezeigte Rechensystem 100 veranschaulichend ist und dass Variationen und Modifikationen möglich sind. Die Verbindungstopologie, einschließlich der Anzahl und Anordnung von Brücken, der Anzahl von Prozessor(en) 102 und der Anzahl von Parallelprozessor(en) 112, kann wie gewünscht modifiziert werden. Zum Beispiel ist der Systemspeicher 104 bei manchen Ausführungsformen anstatt über eine Brücke direkt mit dem/den Prozessor(en) 102 verbunden, während andere Vorrichtungen über den Speicherhub 105 und den/die Prozessor(en) 102 mit dem Systemspeicher 104 kommunizieren. In anderen alternativen Topologien sind der/die Parallelprozessor(en) 112 mit dem E/A-Hub 107 oder direkt mit einem des einen oder der mehreren Prozessor(en) 102 anstatt mit dem Speicherhub 105 verbunden. In anderen Ausführungsformen können der E/A-Hub 107 und der Speicherhub 105 in einem einzigen Chip integriert sein. manche Ausführungsformen können zwei oder mehrere Sätze von Prozessor(en) 102 beinhalten, die über mehrere Sockel verbunden sind, die mit zwei oder mehr Instanzen des/der Parallelprozessor(en) 112 gekoppelt werden können.
manche der hierin gezeigten speziellen Komponenten sind optional und müssen nicht in allen Implementierungen des Rechensystems 100 enthalten sein. Zum Beispiel kann eine beliebige Anzahl von Add-in-Karten oder Peripheriegeräten unterstützt werden, oder manche Komponenten können entfernt werden. Darüber hinaus können manche Architekturen eine andere Terminologie für Komponenten verwenden, die denen ähnlich sind, die in 1 dargestellt sind. Zum Beispiel kann der Speicherhub 105 in manchen Architekturen als eine Northbridge bezeichnet werden, während der E/A-Hub 107 als eine Southbridge bezeichnet werden kann.
2A veranschaulicht einen Parallelprozessor 200 gemäß einer Ausführungsform. Die verschiedenen Komponenten des Parallelprozessors 200 können unter Verwendung einer oder mehrerer integrierter Schaltungsvorrichtungen implementiert sein, wie etwa programmierbare Prozessoren, anwendungsspezifische integrierte Schaltungen (ASICs) oder feldprogrammierbare Gate-Arrays (FPGA). Der veranschaulichte Parallelprozessor 200 ist eine Variante des einen oder der mehreren in 1 gezeigten Parallelprozessor(en) 112 gemäß einer Ausführungsform.
In einer Ausführungsform beinhaltet der Parallelprozessor 200 eine Parallelverarbeitungseinheit 202. Die Parallelverarbeitungseinheit beinhaltet eine E/A-Einheit 204, die eine Kommunikation mit anderen Vorrichtungen, darunter andere Instanzen der Parallelverarbeitungseinheit 202, ermöglicht. Die E/A-Einheit 204 kann direkt mit anderen Vorrichtungen verbunden sein. In einer Ausführungsform stellt die E/A-Einheit 204 über die Verwendung einer Hub- oder Switch-Schnittstelle, wie etwa des Speicherhubs 105, eine Verbindung mit anderen Vorrichtungen her. Die Verbindungen zwischen dem Speicherhub 105 und der E/A-Einheit 204 bilden einen Kommunikations-Link 113. Innerhalb der Parallelverarbeitungseinheit 202 ist die E/A-Einheit 204 mit einer Host-Schnittstelle 206 und eine Speicher-Crossbar 216 verbunden, wobei die Host-Schnittstelle 206 Befehle zum Durchführen von Verarbeitungsoperationen empfängt und die Speicher-Crossbar 216 Befehle zum Durchführen von Speicheroperationen empfängt.
Wenn die Host-Schnittstelle 206 einen Befehlspuffer über die E/A-Einheit 204 empfängt, kann die Host-Schnittstelle 206 Arbeitsoperationen zum Durchführen dieser Befehle an ein Frontend 208 leiten. In einer Ausführungsform ist das Frontend 208 mit einem Scheduler 210 gekoppelt, der dazu konfiguriert ist, Befehle oder andere Arbeitselemente an ein Verarbeitungscluster-Array 212 zu verteilen. In einer Ausführungsform stellt der Scheduler 210 sicher, dass das Verarbeitungscluster-Array 212 ordnungsgemäß konfiguriert und in einem gültigen Zustand ist, bevor Aufgaben an die Verarbeitungscluster des Verarbeitungscluster-Arrays 212 verteilt werden. In einer Ausführungsform ist der Scheduler 210 über Firmwarelogik implementiert, die auf einem Mikrocontroller ausgeführt wird. Der Mikrocontrollerimplementierte Scheduler 210 ist dazu konfigurierbar, komplexe Scheduling- und Arbeitsverteilungsoperationen mit Grob- und Feingranularität auszuführen, was eine schnelle Präemption und einen schnellen Kontextwechsel von Threads ermöglicht, die auf dem Verarbeitungsarray 212 ausgeführt werden. In einer Ausführungsform kann die Host-Software Arbeitslasten zum Scheduling auf dem Verarbeitungsarray 212 über eine von mehreren Grafikverarbeitungs-Doorbells nachweisen. Die Arbeitslasten können dann automatisch durch die Logik des Schedulers 210 innerhalb des Scheduler-Mikrocontrollers über das Verarbeitungsarray 212 hinweg verteilt werden.
Das Verarbeitungscluster-Array 212 kann bis zu „N“ Verarbeitungscluster (z. B. Cluster 214A, Cluster 214B bis Cluster 214N) beinhalten. Jeder Cluster 214A-214N des Verarbeitungscluster-Arrays 212 kann eine große Anzahl gleichzeitiger Threads ausführen. Der Scheduler 210 kann den Clustern 214A-214N des Verarbeitungscluster-Arrays 212 unter Verwendung verschiedener Scheduling- und/oder Arbeitsverteilungsalgorithmen, die je nach der Arbeitslast variieren können, die für jede Art von Programm oder Berechnung auftritt, Arbeit zuweisen. Das Scheduling kann dynamisch durch den Scheduler 210 gehandhabt werden oder kann teilweise durch eine Compiler-Logik während eines Kompilierens einer Programmlogik, die zur Ausführung durch das Verarbeitungscluster-Array 212 konfiguriert ist, unterstützt werden. In einer Ausführungsform können verschiedene Cluster 214A-214N des Verarbeitungscluster-Arrays 212 zum Verarbeiten verschiedener Arten von Programmen oder zum Durchführen verschiedener Arten von Berechnungen zugewiesen werden.
Das Verarbeitungclusterarray 212 kann dazu konfiguriert sein, verschiedene Arten von parallelen Verarbeitungsoperationen durchzuführen. In einer Ausführungsform ist das Verarbeitungscluster-Array 212 dazu konfiguriert, parallele Mehrzweckrechenoperationen durchzuführen. Zum Beispiel kann das Verarbeitungscluster-Array 212 eine Logik zum Durchführen von Verarbeitungsaufgaben, darunter Filtern von Video- und/oder Audiodaten, Durchführen von Modellierungsoperationen einschließlich physischer Operationen und Durchführen von Datentransformationen, beinhalten.
In einer Ausführungsform ist das Verarbeitungscluster-Array 212 dazu konfiguriert, parallele Grafikverarbeitungsoperationen durchzuführen. In Ausführungsformen, in denen der Parallelprozessor 200 zum Ausführen von Grafikverarbeitungsoperationen konfiguriert ist, kann das Verarbeitungscluster-Array 212 zusätzliche Logik aufweisen, um die Ausführung solcher Grafikverarbeitungsoperationen zu unterstützen, darunter unter anderem eine Texturabtastlogik zum Durchführen von Texturoperationen sowie eine Tessellationslogik und andere Vertex-Verarbeitungslogik. Zusätzlich kann das Verarbeitungscluster-Array 212 dazu konfiguriert sein, mit der Grafikverarbeitung in Zusammenhang stehende Shader-Programme auszuführen, wie etwa unter anderem Vertex-Shader, Tessellations-Shader, Geometrie-Shader und Pixel-Shader. Die Parallelverarbeitungseinheit 202 kann Daten aus dem Systemspeicher über die E/A-Einheit 204 zur Verarbeitung übertragen. Während der Verarbeitung können die übertragenen Daten während der Verarbeitung in einem On-Chip-Speicher (z. B. Parallelprozessorspeicher 222) gespeichert und dann in den Systemspeicher zurückgeschrieben werden.
In einer Ausführungsform kann, wenn die Parallelverarbeitungseinheit 202 zum Durchführen einer Grafikverarbeitung verwendet wird, der Scheduler 210 dazu konfiguriert sein, die Verarbeitungsarbeitslast in ungefähr gleich große Aufgaben aufzuteilen, um eine Verteilung der Grafikverarbeitungsoperationen auf mehrere Cluster 214A-214N des Verarbeitungscluster-Arrays 212 besser zu ermöglichen. Bei manchen Ausführungsformen können Teile des Verarbeitungscluster-Arrays 212 dazu konfiguriert sein, unterschiedliche Arten von Verarbeitung durchzuführen. Ein erster Abschnitt kann zum Beispiel dazu konfiguriert sein, Vertex-Shading und Topologieerzeugung durchzuführen, ein zweiter Abschnitt kann dazu konfiguriert sein, Tessellation und Geometrie-Shading durchzuführen, und ein dritter Abschnitt kann dazu konfiguriert sein, Pixel-Shading oder andere Screen-Space-Operationen durchzuführen, um ein gerendertes Bild zur Anzeige zu erzeugen. Zwischendaten, die durch ein oder mehrere der Cluster 214A-214N erzeugt werden, können in Puffern gespeichert werden, um zu ermöglichen, dass die Zwischendaten zwischen Clustern 214A-214N zur weiteren Verarbeitung übertragen werden.
Während des Betriebs kann das Verarbeitungscluster-Array 212 auszuführende Verarbeitungsaufgaben über den Scheduler 210 empfangen, der Befehle, die Verarbeitungsaufgaben definieren, vom Frontend 208 empfängt. Für Grafikverarbeitungsoperationen können Verarbeitungsaufgaben Indizes zu verarbeitender Daten, z. B. Oberflächen(Patch)-Daten, Primitivdaten, Vertex-Daten und/oder Pixeldaten, sowie Zustandsparameter und Befehle, die definieren, wie die Daten zu verarbeiten sind (z. B. welches Programm auszuführen ist), beinhalten. Der Scheduler 210 kann dazu konfiguriert sein, die den Aufgaben entsprechenden Indizes abzurufen, oder kann die Indizes von dem Frontend 208 empfangen. Das Frontend 208 kann dazu konfiguriert sein, sicherzustellen, dass das Verarbeitungscluster-Array 212 in einen gültigen Zustand konfiguriert ist, bevor die durch ankommende Befehlspuffer (z. B. Stapel-Puffer, Push-Puffer usw.) spezifizierte Arbeitslast initiiert wird.
Jede der einen oder mehreren Instanzen der Parallelverarbeitungseinheit 202 kann mit dem Parallelprozessorspeicher 222 gekoppelt sein. Auf den Parallelprozessorspeicher 222 kann über die Speicher-Crossbar 216 zugegriffen werden, die Speicheranfragen von dem Verarbeitungscluster-Array 212 sowie der E/A-Einheit 204 empfangen kann. Die Speicher-Crossbar 216 kann über eine Speicherschnittstelle 218 auf den Parallelprozessorspeicher 222 zugreifen. Die Speicherschnittstelle 218 kann mehrere Partitionseinheiten (z. B. Partitionseinheit 220A, Partitionseinheit 220B bis Partitionseinheit 220N) beinhalten, die jeweils mit einem Teil (z. B. einer Speichereinheit) des Parallelprozessorspeichers 222 gekoppelt sein können. Bei einer Implementierung ist die Anzahl von Partitionseinheiten 220A-220N so konfiguriert, dass sie gleich der Anzahl von Speichereinheiten ist, sodass eine erste Partitionseinheit 220A eine entsprechende erste Speichereinheit 224A aufweist, eine zweite Partitionseinheit 220B eine entsprechende Speichereinheit 224B aufweist und eine N-te Partitionseinheit 220N eine entsprechende N-te Speichereinheit 224N aufweist. In anderen Ausführungsformen ist die Anzahl von Partitionseinheiten 220A-220N möglicherweise nicht gleich der Anzahl von Speichervorrichtungen.
In verschiedenen Ausführungsformen können die Speichereinheiten 224A-224N verschiedene Arten von Speichervorrichtungen beinhalten, darunter dynamischer Direktzugriffsspeicher (DRAM) oder Grafik-Direktzugriffsspeicher, wie etwa synchroner Grafik-Direktzugriffsspeicher (SGRAM), einschließlich Grafikspeicher mit doppelter Datenrate (GDDR). In einer Ausführungsform können die Speichereinheiten 224A-224N auch 3D-Stapelspeicher aufweisen, darunter unter anderem Speicher mit hoher Bandbreite (HBM). Fachleute verstehen, dass die spezielle Implementierung der Speichereinheiten 224A-224N variieren kann und aus einer von verschiedenen herkömmlichen Gestaltungen ausgewählt werden kann. Rendering-Ziele, wie etwa Frame-Puffer oder Texturkarten, können über die Speichereinheiten 224A-224N hinweg gespeichert werden, wodurch ermöglicht wird, dass die Partitionseinheiten 220A-220N Abschnitte jedes Rendering-Ziels parallel schreiben, um die verfügbare Bandbreite des Parallelprozessorspeichers 222 effizient zu nutzen. Bei manchen Ausführungsformen kann eine lokale Instanz des Parallelprozessorspeichers 222 zugunsten eines vereinheitlichten Speicherdesigns, das einen Systemspeicher in Verbindung mit einem lokalen Cachespeicher nutzt, ausgeschlossen werden.
In einer Ausführungsform kann jeder beliebige der Cluster 214A-214N des Verarbeitungscluster-Arrays 212 Daten verarbeiten, die in eine beliebige der Speichereinheiten 224A-224N innerhalb des Parallelprozessorspeichers 222 geschrieben werden. Die Speicher-Crossbar 216 kann dazu konfiguriert sein, die Ausgabe jedes Clusters 214A-214N an eine beliebige Partitionseinheit 220A-220N oder an einen anderen Cluster 214A-214N zu übertragen, die zusätzliche Verarbeitungsoperationen an der Ausgabe ausführen können. Jeder Cluster 214A-214N kann mit der Speicherschnittstelle 218 über die Speicher-Crossbar 216 kommunizieren, um aus verschiedenen externen Speichervorrichtungen zu lesen oder in diese zu schreiben. Bei einer Ausführungsform weist die Speicher-Crossbar 216 eine Verbindung zu der Speicherschnittstelle 218 zum Kommunizieren mit der E/A-Einheit 204 sowie eine Verbindung mit einer lokalen Instanz des Parallelprozessorspeichers 222 auf, wodurch ermöglicht wird, dass die Verarbeitungseinheiten innerhalb der unterschiedlichen Verarbeitungscluster 214A-214N mit dem Systemspeicher oder einem anderen Speicher, der sich nicht lokal bei der Parallelverarbeitungseinheit 202 befindet, kommunizieren. In einer Ausführungsform kann die Speicher-Crossbar 216 virtuelle Kanäle verwenden, um Verkehrsströme zwischen den Clustern 214A-214N und den Partitionseinheiten 220A-220N zu trennen.
Obgleich eine einzige Instanz der Parallelverarbeitungseinheit 202 innerhalb des Parallelprozessors 200 veranschaulicht ist, kann eine beliebige Anzahl von Instanzen der Parallelverarbeitungseinheit 202 enthalten sein. Zum Beispiel können mehrere Instanzen der Parallelverarbeitungseinheit 202 auf einer einzigen Add-In-Karte bereitgestellt sein, oder mehrere Add-In-Karten können miteinander verbunden sein. Die verschiedenen Instanzen der Parallelverarbeitungseinheit 202 können dazu konfiguriert sein, miteinander zu arbeiten, selbst wenn die verschiedenen Instanzen unterschiedliche Anzahlen von Verarbeitungskernen, unterschiedliche Mengen von lokalem Parallelprozessorspeicher und/oder andere Konfigurationsunterschiede aufweisen. In einer Ausführungsform können zum Beispiel manche Instanzen der Parallelverarbeitungseinheit 202 Gleitkommaeinheiten mit höherer Genauigkeit relativ zu anderen Instanzen beinhalten. Systeme, die eine oder mehrere Instanzen der Parallelverarbeitungseinheit 202 oder des Parallelprozessors 200 umfassen, können in einer Vielzahl von Konfigurationen und Formfaktoren implementiert werden, darunter unter anderem Desktop-, Laptop- oder Handheld-Personal-Computer, Server, Workstations, Spielkonsolen und/oder eingebettete Systeme.
2B ist ein Blockdiagramm einer Partitionseinheit 220 gemäß einer Ausführungsform. In einer Ausführungsform ist die Partitionseinheit 220 eine Instanz einer der Partitionseinheiten 220A-220N von 2A. Wie veranschaulicht, beinhaltet die Partitionseinheit 220 einen L2-Cache 221, eine Framepufferschnittstelle 225 und eine ROP 226 (Raster Operations Unit - Rasteroperationseinheit). Der L2-Cachespeicher 221 ist ein Lese/Schreib-Cache, der zum Durchführen von Lade- und Speicheroperationen, die von der Speicher-Crossbar 216 und der ROP 226 empfangen werden, konfiguriert ist. Lesefehltreffer und dringende Rückschreibanforderungen werden durch den L2-Cache 221 an die Framepufferschnittstelle 225 zur Verarbeitung ausgegeben. Aktualisierungen können auch über die Framepufferschnittstelle 225 zur Verarbeitung an den Framepuffer gesendet werden. Bei einer Ausführungsform verbindet sich die Rahmenpufferschnittstelle 225 mit einer der Speichereinheiten im Parallelprozessorspeicher, wie etwa den Speichereinheiten 224 A-224 N aus 2 A (z. B. innerhalb des Parallelprozessorspeichers 222).
In Grafikanwendungen ist die ROP 226 eine Verarbeitungseinheit, die Rasteroperationen wie Stencil, z-Prüfung, Blending und dergleichen durchführt. Die ROP 226 gibt dann verarbeitete Grafikdaten aus, die im Grafikspeicher gespeichert sind. Bei manchen Ausführungsformen beinhaltet die ROP 226 eine Kompressionslogik zum Komprimieren von Tiefen- oder Farbdaten, die in den Speicher geschrieben werden, und zum Dekomprimieren von Tiefen- oder Farbdaten, die aus dem Speicher gelesen werden. Die Kompressionslogik kann eine verlustfreie Kompressionslogik sein, bei der ein oder mehrere Kompressionsalgorithmen verwendet werden. Die Art der Kompression, die durch die ROP 226 durchgeführt wird, kann basierend auf den statistischen Eigenschaften der zu komprimierenden Daten variieren. Zum Beispiel wird in einer Ausführungsform eine Delta-Farbkompression an Tiefen- und Farbdaten auf einer Pro-Kachel-Basis durchgeführt.
Bei manchen Ausführungsformen ist die ROP 226 in jedem Verarbeitungscluster (z. B. Cluster 214A-214N von 2A) anstatt in der Partitionseinheit 220 enthalten. In einer solchen Ausführungsform werden Lese- und Schreibanfragen für Pixeldaten über die Speicher-Crossbar 216 anstelle von Pixelfragmentdaten übertragen. Die verarbeiteten Grafikdaten können auf einer Anzeigevorrichtung wie einer der einen oder mehreren Anzeigevorrichtung(en) 110 aus 1 angezeigt werden, zur weiteren Verarbeitung durch den bzw. die Prozessor(en) 102 geroutet werden oder für die weitere Verarbeitung durch eine der Verarbeitungseinheiten innerhalb des Parallelprozessors 200 aus 2A geroutet werden.
2C ist ein Blockdiagramm eines Verarbeitungsclusters 214 innerhalb einer Parallelverarbeitungseinheit gemäß einer Ausführungsform. In einer Ausführungsform ist der Verarbeitungscluster eine Instanz eines der Verarbeitungscluster 214A-214N von 2A. Der Verarbeitungscluster 214 kann dazu konfiguriert sein, viele Threads parallel auszuführen, wobei sich der Begriff „Thread“ auf eine Instanz eines bestimmten Programms bezieht, das auf einem bestimmten Satz von Eingabedaten ausgeführt wird. Bei manchen Ausführungsformen werden SIMD-Anweisungsausgabetechniken (SIMD: Single Instruction, Multiple Data) angewendet, um eine parallele Ausführung einer großen Anzahl von Threads zu unterstützen, ohne mehrere unabhängige Anweisungseinheiten bereitzustellen. In anderen Ausführungsformen werden SIMT-Techniken /SIMT: Single Instruction, Multiple Thread) angewendet, um eine parallele Ausführung einer großen Anzahl von allgemein synchronisierten Threads zu unterstützen, wobei eine gemeinsame Anweisungseinheit verwendet wird, die dazu konfiguriert ist, Anweisungen an einen Satz von Verarbeitungs-Engines innerhalb jedes der Verarbeitungscluster auszugeben. Im Gegensatz zu einem SIMD-Ausführungsregime, bei dem alle Verarbeitungs-Engines in der Regel identische Anweisungen ausführen, ermöglicht eine SIMT-Ausführung, dass verschiedene Threads leichter divergenten Ausführungspfaden durch ein gegebenes Thread-Programm folgen. Fachleute werden verstehen, dass ein SIMD-Verarbeitungsregime eine funktionelle Teilmenge eines SIMT-Verarbeitungsregimes darstellt.
Der Betrieb des Verarbeitungsclusters 214 kann über einen Pipeline-Manager 232 gesteuert werden, der Verarbeitungsaufgaben an parallele SIMT-Prozessoren verteilt. Der Pipeline-Manager 232 empfängt Anweisungen vom Scheduler 210 von 2A und verwaltet die Ausführung dieser Anweisungen über einen Grafikmultiprozessor 234 und/oder eine Textureinheit 236. Der veranschaulichte Grafikmultiprozessor 234 ist eine beispielhafte Instanz eines SIMT-Parallelprozessors. Es können jedoch verschiedene Arten von SIMT-Parallelprozessoren unterschiedlicher Architekturen in dem Verarbeitungscluster 214 enthalten sein. Eine oder mehrere Instanzen des Grafikmultiprozessors 234 können in einem Verarbeitungscluster 214 enthalten sein. Der Grafikmultiprozessor 234 kann Daten verarbeiten und eine Daten-Crossbar 240 kann verwendet werden, um die verarbeiteten Daten an eines von mehreren möglichen Zielen, darunter andere Shader-Einheiten, zu verteilen. Der Pipeline-Manager 232 kann die Verteilung verarbeiteter Daten erleichtern, indem er Ziele für verarbeitete Daten spezifiziert, die über die Daten-Crossbar 240 verteilt werden sollen.
Jeder Grafikmultiprozessor 234 innerhalb des Verarbeitungsclusters 214 kann einen identischen Satz von Funktionalausführungslogik (z. B. arithmetische Logikeinheiten, Lade-Speicher-Einheiten usw.) aufweisen. Die Funktionalausführungslogik kann auf eine Pipeline-Art konfiguriert sein, in der neue Anweisungen ausgegeben werden können, bevor vorherige Anweisungen abgeschlossen sind. Die Funktionalausführungslogik unterstützt verschiedene Operationen, darunter Ganzzahl- und Gleitkommaarithmetik, Vergleichsoperationen, Boolesche Operationen, Bitverschiebung und Berechnung verschiedener algebraischer Funktionen. In einer Ausführungsform kann dieselbe Funktionseinheit-Hardware genutzt werden, um unterschiedliche Operationen durchzuführen, und es kann eine beliebige Kombination von Funktionseinheiten vorhanden sein.
Die an den Verarbeitungscluster 214 übertragenen Anweisungen bilden einen Thread. Eine Gruppe von Threads, die über den Satz Parallelverarbeitungs-Engines ausgeführt werden, ist eine Thread-Gruppe. Eine Thread-Gruppe führt dasselbe Programm an verschiedenen Eingangsdaten aus. Jeder Thread innerhalb einer Thread-Gruppe kann einer anderen Verarbeitungs-Engine innerhalb eines Grafikmultiprozessors 234 zugewiesen sein. Eine Thread-Gruppe kann weniger Threads als die Anzahl von Verarbeitungs-Engines innerhalb des Grafikmultiprozessors 234 aufweisen. Wenn eine Thread-Gruppe weniger Threads als die Anzahl der Verarbeitungs-Engines aufweist, können eine oder mehrere der Verarbeitungs-Engines während Zyklen, in denen diese Thread-Gruppe verarbeitet wird, inaktiv sein. Eine Thread-Gruppe kann auch mehr Threads als die Anzahl von Verarbeitungs-Engines innerhalb des Grafikmultiprozessors 234 beinhalten. Wenn die Thread-Gruppe mehr Threads beinhaltet als die Anzahl der Verarbeitungs-Engines innerhalb des Grafikmultiprozessors 234, kann die Verarbeitung über aufeinanderfolgende Taktzyklen durchgeführt werden. In einer Ausführungsform können mehrere Thread-Gruppen gleichzeitig auf einem Grafikmultiprozessor 234 ausgeführt werden.
In einer Ausführungsform beinhaltet der Grafikmultiprozessor 234 einen internen Cachespeicher, zum Durchführen von Lade- und Speicheroperationen. In einer Ausführungsform kann der Grafikmultiprozessor 234 auf einen internen Cache verzichten und einen Cachespeicher (z. B. L1-Cache 248) innerhalb des Verarbeitungsclusters 214 verwenden. Jeder Grafikmultiprozessor 234 hat auch Zugriff auf L2-Caches innerhalb der Partitionseinheiten (z. B. Partitionseinheiten 220A-220N von 2A), die durch alle Verarbeitungscluster 214 gemeinsam genutzt werden und zum Übertragen von Daten zwischen Threads verwendet werden können. Der Grafikmultiprozessor 234 kann auch auf einen chipexternen globalen Speicher zugreifen, der einen oder mehrere eines lokalen Parallelprozessorspeichers und/oder eines Systemspeichers beinhalten kann. Ein beliebiger Speicher außerhalb der Parallelverarbeitungseinheit 202 kann als globaler Speicher verwendet werden. Ausführungsformen, in denen der Verarbeitungscluster 214 mehrere Instanzen des Grafikmultiprozessors 234 beinhaltet, können gemeinsame Anweisungen und Daten, die in dem L1-Cache 248 gespeichert sein können, gemeinsam nutzen.
Jeder Verarbeitungscluster 214 kann eine MMU 245 (Speicherverwaltungseinheit) beinhalten, die dazu konfiguriert ist, virtuelle Adressen in physische Adressen abzubilden. In anderen Ausführungsformen können sich eine oder mehrere Instanzen der MMU 245 in der Speicherschnittstelle 218 von 2A befinden. Die MMU 245 enthält einen Satz von Seitentabelleneinträgen (PTEs), die verwendet werden, um eine virtuelle Adresse auf eine physische Adresse einer Kachel und optional einen Cachezeilenindex abzubilden. Die MMU 245 kann Adressenübersetzungspuffer (Adressen-TLB: Adressen-Translation-Lookaside-Buffer) oder Caches aufweisen, die sich innerhalb des Grafikmultiprozessors 234 oder des L1-Caches oder Verarbeitungsclusters 214 befinden können. Die physische Adresse wird verarbeitet, um die Oberflächendatenzugriffslokalität zu verteilen, um eine effiziente Anforderungsverschachtelung zwischen Partitionseinheiten zu ermöglichen. Der Cachezeilenindex kann verwendet werden, um zu bestimmen, ob eine Anforderung für eine Cachezeile ein Treffer oder ein Fehltreffer ist.
In Grafik- und Rechenanwendungen kann ein Verarbeitungscluster 214 derart konfiguriert sein, dass jeder Grafikmultiprozessor 234 mit einer Textureinheit 236 zur Durchführung von Texturabbildungsoperationen, z. B. Bestimmen von Texturabtastpositionen, Lesen von Texturdaten und Filtern der Texturdaten, gekoppelt ist. Texturdaten werden aus einem internen Textur-L1-Cache (nicht gezeigt) oder bei manchen Ausführungsformen aus dem L1-Cache innerhalb des Grafikmultiprozessors 234 gelesen und werden je nach Bedarf aus einem L2-Cache, einem lokalen Parallelprozessorspeicher oder einem Systemspeicher abgerufen. Jeder Grafikmultiprozessor 234 gibt verarbeitete Aufgaben an die Daten-Crossbar 240 aus, um die verarbeitete Aufgabe einem anderen Verarbeitungscluster 214 zur weiteren Verarbeitung bereitzustellen oder die verarbeitete Aufgabe über die Speicher-Crossbar 216 in einem L2-Cache, einem lokalen Parallelprozessorspeicher oder einem Systemspeicher zu speichern. Eine preROP 242 (Vor-Rasteroperationseinheit) ist dazu konfiguriert, Daten von dem Grafikmultiprozessor 234 zu empfangen, Daten an ROP-Einheiten zu leiten, die sich wie hierin beschrieben bei Partitionseinheiten (z. B. Partitionseinheiten 220A-220N von 2A) befinden können. Die preROP 242-Einheit kann Optimierungen für die Farbmischung ausführen, Pixelfarbdaten organisieren und Adressübersetzungen ausführen.
Es versteht sich, dass die hier beschriebene Kernarchitektur veranschaulichend ist und dass Variationen und Modifikationen möglich sind. Eine beliebige Anzahl von Verarbeitungseinheiten, z. B. Grafikmultiprozessor 234, Textureinheiten 236, preROPs 242 usw., kann in einem Verarbeitungscluster 214 enthalten sein. Wenngleich nur ein Verarbeitungscluster 214 dargestellt ist, kann ferner eine Parallelverarbeitungseinheit, wie hierin beschrieben, eine beliebige Anzahl von Instanzen des Verarbeitungsclusters 214 aufweisen. In einer Ausführungsform kann jeder Verarbeitungs-Cluster 214 dazu konfiguriert sein, unabhängig von anderen Verarbeitungs-Clustern 214 unter Verwendung separater und unterschiedlicher Verarbeitungseinheiten, L1-Caches usw. betrieben zu werden.
2D zeigt einen Grafikmultiprozessor 234 gemäß einer Ausführungsform. In einer solchen Ausführungsform ist der Grafikmultiprozessor 234 mit dem Pipeline-Manager 232 des Verarbeitungsclusters 214 gekoppelt. Der Grafikmultiprozessor 234 weist eine Ausführungs-Pipeline auf, die einen Anweisungscache 252, eine Anweisungseinheit 254, eine Adressabbildungseinheit 256, eine Registerbank 258, einen oder mehrere GPGPU-(Mehrzweckgrafikverarbeitungseinheit) Kerne 262 und einen oder mehr Lade/Speicher-Einheiten 266 aufweist. Die GPGPU-Kerne 262 und Lade/Speicher-Einheiten 266 sind über eine Speicher- und Cacheverbindung 268 mit dem Cachespeicher 272 und dem gemeinsam genutzten Speicher 270 gekoppelt. In einer Ausführungsform beinhaltet der Grafikmultiprozessor 234 zusätzlich Tensor- und/oder Strahlverfolgungskerne 263, die Hardwarelogik zum Beschleunigen von Matrix- und/oder Strahlverfolgungsoperationen beinhalten.
In einer Ausführungsform empfängt der Anweisungscache 252 einen Strom auszuführender Anweisungen von dem Pipeline-Manager 232. Die Anweisungen werden in dem Anweisungscache 252 zwischengespeichert und zur Ausführung durch die Befehlseinheit 254 verschickt. Die Befehlseinheit 254 kann Anweisungen als Thread-Gruppen (z. B. Warps) versenden, wobei jeder Thread der Thread-Gruppe einer anderen Ausführungseinheit innerhalb des GPGPU-Kerns 262 zugewiesen wird. Eine Anweisung kann auf einen beliebigen lokalen, gemeinsam genutzten oder globalen Adressraum zugreifen, indem sie eine Adresse in einem vereinheitlichten Adressraum spezifiziert. Die Adressenabbildungseinheit 256 kann verwendet werden, um Adressen in dem vereinheitlichten Adressraum in eine unterschiedliche Speicheradresse zu übersetzen, auf die von den Lade/Speicher-Einheiten 266 zugegriffen werden kann.
Die Registerbank 258 stellt einen Satz von Registern für die Funktionseinheiten des Grafikmultiprozessors 234 bereit. Die Registerbank 258 stellt einen temporären Speicher für Operanden bereit, die mit den Datenpfaden der Funktionseinheiten (z. B. GPGPU-Kerne 262, Lade/Speicher-Einheiten 266) des Grafikmultiprozessors 234 verbunden sind. In einer Ausführungsform ist die Registerbank 258 zwischen jeder der Funktionseinheiten aufgeteilt, sodass jeder Funktionseinheit ein dedizierter Abschnitt der Registerbank 258 zugewiesen ist. In einer Ausführungsform ist die Registerbank 258 zwischen den verschiedenen Warps aufgeteilt, die durch den Grafikmultiprozessor 234 ausgeführt werden.
Die GPGPU-Kerne 262 können jeweils Gleitkommaeinheiten (FPUs) und/oder arithmetische Ganzzahl-Logikeinheiten (ALUs) aufweisen, die zum Ausführen von Anweisungen des Grafikmultiprozessors 234 verwendet werden. Die GPGPU-Kerne 262 können gemäß Ausführungsformen eine ähnliche Architektur aufweisen oder können eine unterschiedliche Architektur aufweisen. Zum Beispiel und in einer Ausführungsform beinhaltet ein erster Teil der GPGPU-Kerne 262 eine Einzelpräzisions-FPU und eine Ganzzahl-ALU, während ein zweiter Teil der GPGPU-Kerne eine Doppelpräzisions-FPU beinhaltet. In einer Ausführungsform können die FPUs den IEEE-754-2008-Standard für Gleitkomma-Arithmetik implementieren oder Gleitkomma-Arithmetik mit variabler Präzision ermöglichen. Der Grafikmultiprozessor 234 kann außerdem eine oder mehrere Festfunktions- oder Spezialfunktionseinheiten beinhalten, um spezielle Funktionen wie Rechteckkopier- oder Pixelblendingoperationen durchzuführen. In einer Ausführungsform können einer oder mehrere der GPGPU-Kerne auch Fest- oder Spezialfunktionslogik beinhalten.
In einer Ausführungsform beinhalten die GPGPU-Kerne 262 eine SIMD-Logik, die in der Lage ist, eine einzelne Anweisung an mehreren Datensätzen auszuführen. In einer Ausführungsform können die GPGPU-Kerne 262 physisch SIMD4-, SIMD8- und SIMD16-Anweisungen ausführen und logisch SIMD1-, SIMD2- und SIMD32-Anweisungen ausführen. Die SIMD-Anweisungen für die GPGPU-Kerne können zur Kompilierungszeit von einem Shader-Compiler erzeugt oder automatisch erzeugt werden, wenn Programme ausgeführt werden, die für Single-Program-Multiple-Data(SPMD-) oder SIMT-Architekturen geschrieben und kompiliert werden. Mehrere Threads eines für das SIMT-Ausführungsmodell konfigurierten Programms können über eine einzige SIMD-Anweisung ausgeführt werden. Zum Beispiel können in einer Ausführungsform acht SIMT-Threads, die die gleichen oder ähnliche Operationen ausführen, parallel über eine einzige SIMD8-Logikeinheit ausgeführt werden.
Der Speicher- und Cache-Interconnect 268 ist ein Interconnect-Netzwerk, das jede der Funktionseinheiten des Grafikmultiprozessors 234 mit der Registerbank 258 und mit dem gemeinsam genutzten Speicher 270 verbindet. In einer Ausführungsform ist der Speicher- und Cache-Interconnect 268 ein Crossbar-Interconnect, die es der Lade/Speicher-Einheit 266 ermöglicht, Lade- und Speicheroperationen zwischen dem gemeinsam genutzten Speicher 270 und der Registerbank 258 zu implementieren. Die Registerbank 258 kann mit der gleichen Frequenz wie die GPGPU-Kerne 262 arbeiten, sodass die Datenübertragung zwischen den GPGPU-Kernen 262 und der Registerbank 258 eine sehr niedrige Latenz hat. Der gemeinsam genutzte Speicher 270 kann verwendet werden, um eine Kommunikation zwischen Threads zu ermöglichen, die auf den Funktionseinheiten innerhalb des Grafikmultiprozessors 234 ausgeführt werden. Der Cachespeicher 272 kann beispielsweise als ein Datencache verwendet werden, um Texturdaten, die zwischen den Funktionseinheiten und der Textureinheit 236 kommuniziert werden, zwischenzuspeichern. Der gemeinsam genutzte Speicher 270 kann auch als ein Programm mit Cacheverwaltung verwendet werden. Threads, die auf den GPGPU-Kernen 262 ausgeführt werden, können programmatisch Daten in dem gemeinsam genutzten Speicher zusätzlich zu den automatisch gecachten Daten speichern, die in dem Cachespeicher 272 gespeichert sind.
3A-3C veranschaulichen zusätzliche Grafikmultiprozessoren gemäß Ausführungsformen. 3A-3B veranschaulichen Grafikmultiprozessoren 325, 350, die Varianten des Grafikmultiprozessors 234 von 2C sind. 3C veranschaulicht eine Grafikverarbeitungseinheit (GPU) 380, die dedizierte Sätze von Grafikverarbeitungsressourcen beinhaltet, die in Mehrkerngruppen 365A-365N angeordnet sind. Die veranschaulichten Grafikmultiprozessoren 325, 350 und die Mehrkerngruppen 365A-365N können ein Streaming-Multiprozessor (SM) sein, der zur gleichzeitigen Ausführung einer großen Anzahl von Ausführungs-Threads in der Lage ist.
3A zeigt einen Grafikmultiprozessor 325 gemäß einer zusätzlichen Ausführungsform. Der Grafikmultiprozessor 325 beinhaltet mehrere zusätzliche Instanzen von Ausführungsressourceneinheiten relativ zu dem Grafikmultiprozessor 234 von 2D. Zum Beispiel kann der Grafikmultiprozessor 325 mehrere Instanzen der Befehlseinheit 332A-332B, der Registerbank 334A-334B und der Textureinheit(en) 344A-344B aufweisen. Der Grafikmultiprozessor 325 beinhaltet auch mehrere Sätze von Grafik- oder Rechenausführungseinheiten (z. B. GPGPU-Kern 336A-336B, Tensorkern 337A-337B, Strahlenverfolgungskern 338A-338B) und mehrere Sätze von Lade/Speicher-Einheiten 340A-340B. In einer Ausführungsform weisen die Ausführungsressourceneinheiten einen gemeinsamen Anweisungscache 330, einen Textur- und/oder Datencachespeicher 342 und einen gemeinsam genutzten Speicher 346 auf.
Die verschiedenen Komponenten können über ein Interconnect-Fabric 327 kommunizieren. In einer Ausführungsform beinhaltet das Interconnect-Fabric 327 einen oder mehrere Crossbar-Schalter, um eine Kommunikation zwischen den verschiedenen Komponenten des Grafikmultiprozessors 325 zu ermöglichen. In einer Ausführungsform ist das Interconnect-Fabric 327 eine separate Hochgeschwindigkeits-Netzwerk-Fabric-Schicht, auf der jede Komponente des Grafikmultiprozessors 325 gestapelt ist. Die Komponenten des Grafikmultiprozessors 325 kommunizieren mit fernen Komponenten über das Interconnect-Fabric 327. Zum Beispiel können die GPGPU-Kerne 336A-336B, 337A-337B und 3378A-338B jeweils mit dem gemeinsam genutzten Speicher 346 über das Interconnect-Fabric 327 kommunizieren. Das Interconnect-Fabric 327 kann die Kommunikation innerhalb des Grafikmultiprozessors 325 vermitteln, um eine faire Bandbreitenzuordnung zwischen den Komponenten sicherzustellen.
3B zeigt einen Grafik-Multiprozessor 350 gemäß einer zusätzlichen Ausführungsform. Der Grafikprozessor beinhaltet mehrere Sätze von Ausführungsressourcen 356A-356D, wobei jeder Satz von Ausführungsressourcen mehrere Anweisungseinheiten, Registerbänke, GPGPU-Kerne und Lade/Speicher-Einheiten beinhaltet, wie in 2D und 3A veranschaulicht. Die Ausführungsressourcen 356A-356D können mit Textureinheit(en) 360A-360D für Texturoperationen zusammenarbeiten, während sie einen Anweisungscache 354 und einen gemeinsam genutzten Speicher 353 gemeinsam nutzen. In einer Ausführungsform können die Ausführungsressourcen 356A-356D einen Anweisungscache 354 und einen gemeinsam genutzten Speicher 353 sowie mehrere Instanzen eines Textur- und/oder Datencachespeichers 358A-358B gemeinsam nutzen. Die verschiedenen Komponenten können über ein Interconnect-Fabric 352 ähnlich dem Interconnect-Fabric 327 von 3A kommunizieren.
Fachleute werden verstehen, dass die in 1, 2A-2D und 3A-3B beschriebenen Architekturen beschreibend sind und den Umfang der vorliegenden Ausführungsformen nicht einschränken. Somit können die hierin beschriebenen Techniken auf jeder ordnungsgemäß konfigurierten Verarbeitungseinheit implementiert werden, darunter, ohne Einschränkung, ein oder mehrere Mobilanwendungsprozessoren, eine oder mehrere Desktop- oder Server-Zentralverarbeitungseinheiten (CPUs), einschließlich Mehrkern-CPUs, eine oder mehrere Parallelverarbeitungseinheiten, wie etwa die Parallelverarbeitungseinheit 202 von 2A, sowie ein oder mehrere Grafikprozessoren oder Spezialverarbeitungseinheiten, ohne vom Umfang der hierin beschriebenen Ausführungsformen abzuweichen.
Bei manchen Ausführungsformen ist ein Parallelprozessor oder eine GPGPU, wie hierin beschrieben, kommunikativ mit Host-/Prozessorkernen gekoppelt, um Grafikoperationen, Maschinenlernoperationen, Musteranalyseoperationen und verschiedene Mehrzweck-GPU(GPGPU)-Funktionen zu beschleunigen. Die GPU kann über einen Bus oder einen anderen Interconnect (z. B. einen Hochgeschwindigkeits-Interconnect wie PCIe oder NVLink) kommunikativ mit dem Hostprozessor/den Hostkernen gekoppelt sein. In anderen Ausführungsformen kann die GPU auf demselben Package oder Chip wie die Kerne integriert sein und über einen internen Prozessorbus/Interconnect (d. h. innerhalb des Packages oder Chips) kommunikativ mit den Kernen gekoppelt sein. Unabhängig von der Art und Weise, auf welche die GPU verbunden ist, können die Prozessorkerne der GPU Arbeit in Form von in einem Arbeitsdeskriptor enthaltenen Sequenzen von Befehlen/Anweisungen zuweisen. Die GPU verwendet dann eine dedizierte Schaltungsanordnung/Logik zum effizienten Verarbeiten dieser Befehle/Anweisungen.
3C veranschaulicht eine Grafikverarbeitungseinheit (GPU) 380, die dedizierte Sätze von Grafikverarbeitungsressourcen beinhaltet, die in Mehrkerngruppen 365A-N angeordnet sind. Während die Einzelheiten lediglich einer einzigen Mehrkerngruppe 365A bereitgestellt sind, versteht es sich, dass die anderen Mehrkerngruppen 365B-365N mit den gleichen oder ähnlichen Sätzen von Grafikverarbeitungsressourcen ausgestattet sein können.
Wie veranschaulicht, kann eine Mehrkerngruppe 365A einen Satz von Grafikkernen 370, einen Satz von Tensorkernen 371 und einen Satz von Strahlverfolgungskernen 372 beinhalten. Ein Scheduler/Dispatcher 368 plant und sendet die Grafik-Threads zur Ausführung auf den verschiedenen Kernen 370, 371, 372 aus. Ein Satz von Registerbanken 369 speichert Operandenwerte, die von den Kernen 370, 371, 372 verwendet werden, wenn die Grafik-Threads ausgeführt werden. Hierzu können beispielsweise Ganzzahlregister zum Speichern ganzzahliger Werte, Gleitkommaregister zum Speichern von Gleitkommawerten, Vektorregister zum Speichern gekapselter Datenelemente (Ganzzahl- und/oder Gleitkommadatenelemente) und Kachelregister zum Speichern von Tensor-/Matrixwerten gehören. In einer Ausführungsform sind die Kachelregister als kombinierte Sätze von Vektorregistern implementiert.
Ein oder mehrere kombinierte Level-1(L1) -Caches und gemeinsam genutzte Speichereinheiten 373 speichern Grafikdaten, wie Texturdaten, Vertex-Daten, Pixeldaten, Strahlendaten, Begrenzungsvolumendaten usw., lokal innerhalb jeder Mehrkerngruppe 365A. Eine oder mehrere Textureinheiten 374 können auch verwendet werden, um Texturierungsoperationen, wie etwa Texturabbildung und Abtastung, durchzuführen. Ein Level-2(L2)-Cache 375, der durch alle oder eine Teilmenge der Mehrkerngruppen 365A-365N gemeinsam genutzt wird, speichert Grafikdaten und/oder Anweisungen für mehrere gleichzeitige Grafik-Threads. Wie veranschaulicht, kann der L2-Cache 375 über mehrere Mehrkerngruppen 365A-365N gemeinsam genutzt werden. Eine oder mehrere Speichersteuerungen 367 koppeln die GPU 380 mit einem Speicher 366, der ein Systemspeicher (z. B. DRAM) und/oder ein dedizierter Grafikspeicher (z. B. GDDR6-Speicher) sein kann.
Eine Eingabe/Ausgabe(E/A)-Schaltungsanordnung 363 koppelt die GPU 380 mit einer oder mehreren E/A-Vorrichtungen 362, wie etwa Digitalsignalprozessoren (DSPs), Netzwerksteuerungen oder Benutzereingabevorrichtungen. Ein On-Chip-Interconnect kann verwendet werden, um die E/A-Vorrichtungen 362 mit der GPU 380 und dem Speicher 366 zu koppeln. Eine oder mehrere E/A-Speicherverwaltungseinheiten (IOMMUs) 364 der E/A-Schaltungsanordnung 3195 koppeln die E/A-Vorrichtungen 362 direkt mit dem Systemspeicher 366. In einer Ausführungsform verwaltet die IOMMU 364 mehrere Sätze von Seitentabellen, um virtuelle Adressen auf physische Adressen im Systemspeicher 366 abzubilden. In dieser Ausführungsform können sich die E/A-Vorrichtungen 362, die CPU(s) 361 und die GPU(s) 380 denselben virtuellen Adressraum teilen.
In einer Implementierung unterstützt die IOMMU 364 Virtualisierung. In diesem Fall kann sie einen ersten Satz von Seitentabellen dahingehend verwalten, virtuelle Gast-/Grafikadressen auf physische Gast-/Grafikadressen abzubilden, und einen zweiten Satz von Seitentabellen dahingehend verwalten, die physischen Gast-/Grafikadressen auf physische System-/Hostadressen (z. B. innerhalb des Systemspeichers 366) abzubilden. Die Basisadressen sowohl des ersten als auch des zweiten Satzes von Seitentabellen können in Steuerregistern gespeichert werden und bei einem Kontextwechsel ausgelagert werden (z. B. sodass der neue Kontext Zugriff auf den relevanten Satz von Seitentabellen erhält). Obgleich dies in 3C nicht veranschaulicht ist, kann jede(r) der Kerne 370, 371, 372 und/oder Mehrkerngruppen 365A-365N Übersetzungspuffer (TLBs: Translation Lookaside Buffers) beinhalten, um Virtuell-Gast-zu-Physisch-Gast-Übersetzungen, Physisch-Gast-zu-Physisch-Host-Übersetzungen und Virtuell-Gast-zu-Physisch-Host-Übersetzungen zwischenzuspeichern.
In einer Ausführungsform sind die CPUs 361, GPUs 380 und E/A-Vorrichtungen 362 auf einem einzigen Halbleiter-Chip und/oder Chip-Package integriert. Der veranschaulichte Speicher 366 kann auf demselben Chip integriert sein oder kann über eine chip externe Schnittstelle mit den Speichersteuerungen 367 gekoppelt sein. Bei einer Implementierung umfasst der Speicher 366 einen GDDR6-Speicher, der denselben virtuellen Adressraum wie andere physische Systemebenenspeicher nutzt, obgleich die zugrundeliegenden Prinzipien der Erfindung nicht auf diese spezielle Implementierung beschränkt sind.
In einer Ausführungsform weisen die Tensorkerne 371 mehrere Ausführungseinheiten auf, die speziell zum Durchführen von Matrixoperationen, die die grundlegende Rechenoperation sind, die zum Durchführen von Deep-Learning-Operationen verwendet wird, ausgestaltet sind. Zum Beispiel können gleichzeitige Matrixmultiplikationsoperationen zum Trainieren neuronaler Netze und zur Inferenzfindung verwendet werden. Die Tensorkerne 371 können eine Matrixverarbeitung unter Verwendung einer Vielzahl von Operandenpräzisionen durchführen, darunter Gleitkomma mit einfacher Präzision (z. B. 32 Bit), Gleitkomma mit halber Präzision (z. B. 16 Bit), Ganzzahlwörter (16 Bit), Bytes (8 Bit) und Halbbytes (4 Bits). In einer Ausführungsform extrahiert eine Neuronalnetzimplementierung Merkmale jeder gerenderten Szene, wobei möglicherweise Details aus mehreren Frames kombiniert werden, um ein hochwertiges Endbild zu konstruieren.
Bei Implementierungen mit tiefem Lernen kann eine Parallelmatrixmultiplikationsarbeit zur Ausführung auf den Tensorkernen 371 geplant werden. Insbesondere erfordert das Training neuronaler Netze eine signifikante Anzahl an Matrixskalarproduktoperationen. Um eine Innenproduktformulierung einer NxNxN-Matrixmultiplikation zu verarbeiten, können die Tensorkerne 371 mindestens N Skalarproduktverarbeitungselemente beinhalten. Bevor die Matrixmultiplikation beginnt, wird für jeden Zyklus von n Zyklen eine gesamte Matrix in Kachelregister geladen und mindestens eine Spalte einer zweiten Matrix geladen. In jedem Zyklus gibt es N Skalarprodukte, die verarbeitet werden.
Matrixelemente können in Abhängigkeit von der speziellen Implementierung mit unterschiedlichen Präzisionen gespeichert werden, einschließlich 16-Bit-Wörter, 8-Bit-Bytes (z. B. INT8) und 4-Bit-Halbbytes (z. B. INT4). Verschiedene Präzisionsmodi können für die Tensorkerne 371 spezifiziert werden, um sicherzustellen, dass die effizienteste Präzision für verschiedene Arbeitslasten verwendet wird (z. B. Inferenzfindungsarbeitslasten, die eine Quantisierung in Bytes und Halbbytes tolerieren können).
In einer Ausführungsform beschleunigen die Strahlverfolgungskerne 372 Strahlverfolgungsoperationen sowohl für Echtzeitstrahlverfolgungs- als auch für Nicht-Echtzeit-Strahlverfolgungsimplementierungen. Insbesondere beinhalten die Strahlverfolgungskerne 372 eine Strahldurchquerungs-/-schnittpunktschaltungsanordnung zum Durchführen einer Strahldurchquerung unter Verwendung von Hüllkörperhierarchien (BVHs: Bounding Volume Hierarchies) und Identifizieren von Schnittpunkten zwischen Strahlen und Primitiven, die in den BVH-Volumina enthalten sind. Die Strahlverfolgungskerne 372 können auch eine Schaltungsanordnung zum Durchführen von Tiefenprüfung und Culling (z. B. unter Verwendung eines Z-Puffers oder einer ähnlichen Anordnung) beinhalten. Bei einer Implementierung führen die Strahlverfolgungskerne 372 Durchquerungs- und Schnittoperationen in Übereinstimmung mit den hierin beschriebenen Bild-Rauschentfernung-Techniken durch, von denen zumindest ein Teil auf den Tensorkernen 371 ausgeführt werden kann. In einer Ausführungsform implementieren die Tensorkerne 371 zum Beispiel ein neuronales Netz mit tiefem Lernen, um eine Rauschentfernung von Frames durchzuführen, die durch die Strahlverfolgungskerne 372 erzeugt werden. Die CPU(s) 361, Grafikkerne 370 und/oder Strahlverfolgungskerne 372 können jedoch auch alle oder einen Teil der Rauschentfernungs- und/oder Tiefes-Lernen-Algorithmen implementieren.
Zudem kann, wie oben beschrieben, ein verteilter Ansatz zur Rauschentfernung eingesetzt werden, bei dem sich die GPU 380 in einer Rechenvorrichtung befindet, die über ein Netzwerk oder einen Hochgeschwindigkeits-Interconnect mit anderen Rechenvorrichtungen gekoppelt ist. Bei dieser Ausführungsform teilen sich die miteinander verbundenen Rechenvorrichtungen Neuronalnetzlern-/-trainingsdaten, um die Geschwindigkeit zu verbessern, mit der das Gesamtsystem lernt, eine Rauschentfernung für unterschiedliche Arten von Bildframes und/oder unterschiedliche Grafikanwendungen durchzuführen.
In einer Ausführungsform verarbeiten die Strahlverfolgungskerne 372 alle BVH-Durchquerungen und Strahl-Primitiv-Schnittpunkte, wodurch verhindert wird, dass die Grafikkerne 370 mit tausenden Anweisungen pro Strahl überlastet werden. In einer Ausführungsform beinhaltet jeder Strahlverfolgungskern 372 einen ersten Satz spezialisierter Schaltungsanordnungen zum Durchführen von Hüllquaderprüfungen (z. B. für Durchquerungsoperationen) und einen zweiten Satz spezialisierter Schaltungsanordnungen zum Durchführen der Strahl-Dreieck-Schnittprüfungen (z. B. sich schneidende Strahlen, die durchquert wurden). Somit kann in einer Ausführungsform die Mehrkerngruppe 365A einfach eine Strahlsonde aussenden, und die Strahlverfolgungskerne 372 führen unabhängig Strahldurchquerung und -schneidung durch und geben Trefferdaten (z. B. ein Treffer, kein Treffer, mehrere Treffer usw.) an den Thread-Kontext zurück. Die anderen Kerne 370, 371 werden freigegeben, um andere Grafik- oder Rechenarbeit durchzuführen, während die Strahlverfolgungskerne 372 die Durchquerungs- und Schnittoperationen durchführen.
In einer Ausführungsform beinhaltet jeder Strahlverfolgungskern 372 eine Durchquerungseinheit zum Durchführen von BVH-Prüfungsoperationen und eine Schnittpunkteinheit, die eine Strahl-Primitiv-Schnittpunktprüfungen durchführt. Die Schnittpunkteinheit erzeugt eine „Treffer“-, „Kein-Treffer“- oder „Mehrfachtreffer“-Antwort, die sie an den entsprechenden Thread liefert. Während der Durchquerungs- und Schnittpunktoperationen werden die Ausführungsressourcen der anderen Kerne (z. B. Grafikkerne 370 und Tensorkerne 371) freigegeben, um andere Arten von Grafikarbeit durchzuführen.
In einer nachstehend beschriebenen speziellen Ausführungsform wird ein hybrider Rasterung/Strahlverfolgung-Ansatz verwendet, bei dem die Arbeit zwischen den Grafikkernen 370 und den Strahlverfolgungskernen 372 verteilt wird.
In einer Ausführungsform beinhalten die Strahlverfolgungskerne 372 (und/oder andere Kerne 370, 371) Hardwareunterstützung für einen Strahlverfolgungsanweisungssatz, wie etwa DirectX Ray Tracing (DXR) von Microsoft, der einen DispatchRays-Befehl beinhaltet, sowie Strahlerzeugung, Nächster-Treffer-, Beliebiger-Treffer- und Fehltreffer-Shader, die die Zuweisung eindeutiger Sätze von Shadern und Texturen für jedes Objekt ermöglichen. Eine andere Strahlverfolgungsplattform, die durch die Strahlverfolgungskerne 372, Grafikkerne 370 und Tensorkerne 371 unterstützt werden kann, ist Vulkan 1.1.85. Es sei jedoch angemerkt, dass die zugrundeliegenden Prinzipien der Erfindung nicht auf irgendeine spezielle Strahlverfolgungs-ISA beschränkt sind.
Im Allgemeinen können die verschiedenen Kerne 372, 371, 370 einen Strahlverfolgungsanweisungssatz unterstützen, der Anweisungen/Funktionen für Strahlerzeugung, Nächster-Treffer, Beliebiger-Treffer, Strahl-Primitiv-Schnittpunkt, Primitiv-weise und hierarchische Hüllquaderkonstruktion, Fehltreffer, Visit und Ausnahmen enthält. Genauer gesagt beinhaltet eine Ausführungsform Strahlverfolgungsanweisungen zum Durchführen der folgenden Funktionen:

Strahlerzeugung - Strahlerzeugungsanweisungen können für jedes Pixel, jede Abtastung oder jede andere benutzerdefinierte Arbeitszuweisung ausgeführt werden.
Nächster-Treffer - Eine Nächster-Treffer-Anweisung kann ausgeführt werden, um den nächstgelegenen Schnittpunkt eines Strahls mit Primitiven innerhalb einer Szene zu lokalisieren.
Beliebiger-Treffer - Eine Beliebiger-Treffer-Anweisung identifiziert mehrere Schnittpunkte zwischen einem Strahl und Primitiven innerhalb einer Szene, möglicherweise um einen neuen nächstgelegenen Schnittpunkt zu identifizieren.
Schnittpunkt - Eine Schnittpunktanweisung führt eine Strahl-Primitiv-Schnittpunktprüfung durch und gibt ein Ergebnis aus.
Primitiv-weise Hüllquaderkonstruktion - Diese Anweisung erstellt einen Hüllquader um ein gegebenes Primitiv oder eine Gruppe von Primitiven (z. B. beim Erstellen einer neuen BVH oder einer anderen Beschleunigungsdatenstruktur).
Fehltreffer - Gibt an, dass ein Strahl die gesamte Geometrie innerhalb einer Szene oder eines festgelegten Bereichs einer Szene verfehlt.
Visit - Gibt die Nachfolgevolumina an, die ein Strahl durchqueren wird.
Ausnahmen - Beinhaltet verschiedene Arten von Ausnahme-Handlers (z. B. für verschiedene Fehlerbedingungen aufgerufen).

Techniken zur Verbindung zwischen GPU und Hostprozessor
4A veranschaulicht eine beispielhafte Architektur, in der mehrere GPUs 410-413 kommunikativ mit mehreren Mehrkernprozessoren 405-406 über Hochgeschwindigkeits-Links 440A-440D (z. B. Busse, Punkt-zu-Punkt-Interconnects usw.) gekoppelt sind. Bei einer Ausführungsform unterstützen die Hochgeschwindigkeits-Links 440A-440D je nach Implementierung einen Kommunikationsdurchsatz von 4 GB/s, 30 GB/s, 80 GB/s oder mehr. Verschiedene Interconnect-Protokolle können verwendet werden, einschließlich unter anderem PCIe 4.0 oder 5.0 und NVLink 2.0. Die zugrundeliegenden Prinzipien der Erfindung sind jedoch nicht auf ein bestimmtes Kommunikationsprotokoll oder einen bestimmten Kommunikationsdurchsatz beschränkt.
Außerdem sind in einer Ausführungsform zwei oder mehr der GPUs 410-413 über Hochgeschwindigkeitsverbindungen 442A-442B miteinander verbunden, die unter Verwendung derselben oder anderer Protokolle/Verbindungen als jene, die für die Hochgeschwindigkeits-Links 440A-440D verwendet werden, implementiert werden können. In ähnlicher Weise können zwei oder mehrere der Mehrkernprozessoren 405-406 über einen Hochgeschwindigkeits-Link 443 verbunden sein, der Symmetrischer-Multiprozessor(SMP)-Busse sein kann, die mit 20 GB/s, 30 GB/s, 120 GB/s oder mehr arbeiten. Alternativ dazu kann die gesamte Kommunikation zwischen den verschiedenen in 4 A gezeigten Systemkomponenten unter Verwendung der gleichen Protokolle/Links (z. B. über ein gemeinsames Interconnect-Fabric) erreicht werden. Wie erwähnt, sind die zugrundeliegenden Prinzipien der Erfindung jedoch nicht auf eine bestimmte Art von Interconnect-Technologie beschränkt.
In einer Ausführungsform ist jeder Mehrkernprozessor 405-406 jeweils über Speicher-Interconnects 430A-430B kommunikativ mit einem Prozessorspeicher 401-402 gekoppelt, und jede GPU 410-413 ist jeweils über GPU-Speicher-Interconnects 450A-450D kommunikativ mit einem GPU-Speicher 420-423 gekoppelt. Die Speicher-Interconnects 430A-430B und 450A-450D können die gleiche oder unterschiedliche Speicherzugriffstechnologien nutzen. Beispielhaft und nicht einschränkend können die Prozessorspeicher 401-402 und die GPU-Speicher 420-423 flüchtige Speicher wie dynamische Direktzugriffsspeicher (DRAMs) (einschließlich gestapelter DRAMs), Grafik-DDR-SDRAM (GDDR) (z. B. GDDR5, GDDR6) oder Hochbandbreitenspeicher (HBM: High-Bandwidth-Memory) sein und/oder können nichtflüchtige Speicher wie 3D-XPoint- oder Nano-Ram sein. In einer Ausführungsform kann es sich bei einem Teil der Speicher um flüchtigen Speicher und bei einem anderen Teil um nichtflüchtigen Speicher handeln (z. B. unter Verwendung einer 2LM-Hierarchie (2LM: Two-Level Memory)).
Wie nachstehend beschrieben, kann, obgleich die verschiedenen Prozessoren 405-406 und GPUs 410-413 jeweils physisch mit einem bestimmten Speicher 401-402, 420-423 gekoppelt sein können, eine vereinheitlichte Speicherarchitektur implementiert werden, in der derselbe virtuelle Systemadressraum (auch als der „effektive Adressraum“ bezeichnet) unter sämtlichen verschiedenen physischen Speichern verteilt ist. Zum Beispiel können die Prozessorspeicher 401-402 jeweils 64 GB des Systemspeicheradressraums umfassen, und die GPU-Speicher 420-423 können jeweils 32 GB des Systemspeicheradressraums umfassen (was in diesem Beispiel zu insgesamt 256 GB adressierbaren Speichers führt).
4B veranschaulicht zusätzliche Einzelheiten für eine Verbindung zwischen einem Mehrkernprozessor 407 und einem Grafikbeschleunigungsmodul 446 gemäß einer Ausführungsform. Das Grafikbeschleunigungsmodul 446 kann einen oder mehrere GPU-Chips aufweisen, die auf einer Leitungskarte integriert sind, die über den Hochgeschwindigkeits-Link 440 mit dem Prozessor 407 gekoppelt ist. Alternativ dazu kann das Grafikbeschleunigungsmodul 446 auf dem gleichen Package oder Chip wie der Prozessor 407 integriert sein.
Der veranschaulichte Prozessor 407 weist mehrere Kerne 460A-460D mit jeweils einem Übersetzungspuffer 461A-461D und einem oder mehreren Caches 462A-462D auf. Die Kerne können verschiedene andere Komponenten zum Ausführen von Anweisungen und zum Verarbeiten von Daten beinhalten, die nicht veranschaulicht sind, um zu vermeiden, dass die zugrundeliegenden Prinzipien der Erfindung unklar werden (z. B. Anweisungsabrufeinheiten, Verzweigungsvorhersageeinheiten, Decodierer, Ausführungseinheiten, Neuordnungspuffer usw.). Die Caches 462A-462D können Level-1(L1)- und Level-2(L2)-Caches umfassen. Außerdem können ein oder mehrere gemeinsam genutzte Caches 456 in der Caching-Hierarchie enthalten sein und durch Sätze der Kerne 460A-460D gemeinsam genutzt werden. Zum Beispiel weist eine Ausführungsform des Prozessors 407 24 Kerne auf, jeweils mit seinem eigenen LI-Cache, zwölf gemeinsam genutzten L2-Caches und zwölf gemeinsam genutzten L3-Caches. In dieser Ausführungsform wird einer der L2- und L3-Caches von zwei benachbarten Kernen gemeinsam genutzt. Der Prozessor 407 und das Grafikbeschleunigerintegrationsmodul 446 sind mit dem Systemspeicher 441 verbunden, der Prozessorspeicher 401-402 beinhalten kann.
Die Kohärenz wird für Daten und Anweisungen, die in den verschiedenen Caches 462A-462D, 456 und dem Systemspeicher 441 gespeichert sind, über eine Inter-Kern-Kommunikation über einen Kohärenzbus 464 aufrechterhalten. Zum Beispiel kann jeder Cache eine mit diesem assoziierte Cachekohärenzlogik/-schaltungsanordnung aufweisen, um als Reaktion auf detektierte Lese- oder Schreibvorgänge in bestimmte Cachezeilen über den Kohärenzbus 464 zu kommunizieren. In einer Implementierung wird ein Cache-Snooping-Protokoll über den Kohärenzbus 464 implementiert, um Cachezugriffe zu snoopen. Cache-Snooping-/Kohärenztechniken sind Fachleuten gut bekannt und werden hier nicht detailliert beschrieben, um zu vermeiden, dass die zugrundeliegenden Prinzipien der Erfindung unklar werden.
In einer Ausführungsform koppelt eine Proxyschaltung 425 das Grafikbeschleunigungsmodul 446 kommunikativ mit dem Kohärenzbus 464, wodurch ermöglicht wird, dass das Grafikbeschleunigungsmodul 446 als ein Peer der Kerne am Cachekohärenzprotokoll teilnimmt. Insbesondere stellt eine Schnittstelle 435 eine Konnektivität zu der Proxyschaltung 425 über einen Hochgeschwindigkeits-Link 440 (z. B. einen PCIe-Bus, NVLink usw.) bereit und eine Schnittstelle 437 verbindet das Grafikbeschleunigungsmodul 446 mit dem Hochgeschwindigkeits-Link 440.
Bei einer Implementierung stellt eine Beschleunigerintegrationsschaltung 436 Cacheverwaltungs-, Speicherzugriffs-, Kontextverwaltungs- und Interrupt-Verwaltungsdienste für mehrere Grafikverarbeitungs-Engines 431, 432, N des Grafikbeschleunigungsmoduls 446 bereit. Die Grafikverarbeitungs-Engines 431, 432, N können jeweils eine separate Grafikverarbeitungseinheit (GPU) umfassen. Alternativ dazu können die Grafikverarbeitungs-Engines 431, 432, N verschiedene Arten von Grafikverarbeitungs-Engines in einer GPU umfassen, wie etwa Grafikausführungseinheiten, Medienverarbeitungs-Engines (z. B. Videocodierer/-decodierer), Sampler und Blit-Engines. Mit anderen Worten kann das Grafikbeschleunigungsmodul eine GPU mit mehreren Grafikverarbeitungs-Engines 431-432, N sein oder können die Grafikverarbeitungs-Engines 431-432, N einzelne GPUs sein, die auf einem gemeinsamen Package, einer Leitungskarte oder einem Chip integriert sind.
In einer Ausführungsform beinhaltet die Beschleunigerintegrationsschaltung 436 eine Speicherverwaltungseinheit (MMU: Memory Management Unit) 439 zum Durchführen verschiedener Speicherverwaltungsfunktionen wie Übersetzungen von virtuellem in physischen Speicher (auch als Übersetzungen von effektivem in realen Speicher bezeichnet) und Speicherzugriffsprotokolle zum Zugriff auf den Systemspeicher 441. Die MMU 439 kann auch einen Übersetzungspuffer (TLB) (nicht gezeigt) zum Zwischenspeichern der Übersetzungen von virtuellen/effektiven in physische/reale Adressen beinhalten. In einer Implementierung speichert ein Cache 438 Befehle und Daten für einen effizienten Zugriff durch die Grafikverarbeitungs-Engines 431-432, N. In einer Ausführungsform werden die in dem Cache 438 und den Grafikspeichern 433-434, M gespeicherten Daten kohärent mit den Kerncaches 462A-462D, 456 und dem Systemspeicher 411 gehalten. Wie erwähnt, kann dies über die Proxyschaltung 425 erreicht werden, die am Cachekohärenzmechanismus für den Cache 438 und die Speicher 433-434, M teilnimmt (z. B. Senden von Aktualisierungen an den Cache 438 in Bezug auf Modifikationen/Zugriffe auf Cachezeilen auf den Prozessor-Caches 462A-462D, 456 und Empfangen von Aktualisierungen vom Cache 438).
Ein Satz von Registern 445 speichert Kontextdaten für Threads, die durch die Grafikprozessor-Engines 431-432, N ausgeführt werden, und eine Kontextverwaltungsschaltung 448 verwaltet die Thread-Kontexte. Zum Beispiel kann die Kontextverwaltungsschaltung 448 Speicher- und Wiederherstellungsoperationen zum Speichern und Wiederherstellen von Kontexten der verschiedenen Threads während Kontextwechseln durchführen (z. B. wenn ein erster Thread gespeichert wird und ein zweiter Thread gespeichert wird, sodass der zweite Thread durch eine Grafikverarbeitungs-Engine ausgeführt werden kann). Zum Beispiel kann die Kontextverwaltungsschaltung 448 bei einem Kontextwechsel aktuelle Registerwerte in einem designierten Bereich im Speicher (z. B. durch einen Kontextzeiger identifiziert) speichern. Er kann dann die Registerwerte bei Rückkehr zu dem Kontext wiederherstellen. In einer Ausführungsform empfängt und verarbeitet eine Interrupt-Verwaltungsschaltung 447 von Systemvorrichtungen empfangene Interrupts.
In einer Implementierung werden virtuelle/effektive Adressen von einer Grafikverarbeitungs-Engine 431 durch die MMU 439 in reale/physische Adressen im Systemspeicher 411 übersetzt. Eine Ausführungsform der Beschleunigerintegrationsschaltung 436 unterstützt mehrere (z. B. 4, 8, 16) Grafikbeschleunigermodule 446 und/oder andere Beschleunigervorrichtungen. Das Grafikbeschleunigermodul 446 kann für eine einzelne Anwendung dediziert sein, die auf dem Prozessor 407 ausgeführt wird, oder kann von mehreren Anwendungen gemeinsam genutzt werden. In einer Ausführungsform ist eine virtualisierte Grafikausführungsumgebung dargestellt, in der die Ressourcen der Grafikverarbeitungs-Engines 431-432, N mit mehreren Anwendungen oder virtuellen Maschinen (VMs) gemeinsam genutzt werden. Die Ressourcen können in „Slices“ unterteilt sein, die verschiedenen VMs und/oder Anwendungen auf der Grundlage der mit den VMs und/oder den Anwendungen assoziierten Verarbeitungsanforderungen und -prioritäten zugewiesen sind.
Somit fungiert die Beschleunigerintegrationsschaltung als eine Brücke zu dem System für das Grafikbeschleunigungsmodul 446 und stellt Adressübersetzungs- und Systemspeichercachedienste bereit. Außerdem kann die Beschleunigerintegrationsschaltung 436 Virtualisierungseinrichtungen für den Host-Prozessor bereitstellen, um die Virtualisierung der Grafikverarbeitungs-Engines, Interrupts und Speicherverwaltung zu verwalten.
Da Hardwareressourcen der Grafikverarbeitungs-Engines 431-432, N explizit auf den realen Adressraum abgebildet werden, den der Hostprozessor 407 sieht, kann jeder Hostprozessor diese Ressourcen direkt unter Verwendung eines effektiven Adresswerts adressieren. Eine Funktion der Beschleunigerintegrationsschaltung 436 ist in einer Ausführungsform die physische Trennung der Grafikprozessor-Engines 431-432, N, sodass sie dem System als unabhängige Einheiten erscheinen.
Wie erwähnt, sind in der veranschaulichten Ausführungsform ein oder mehrere Grafikspeicher 433-434, M jeweils mit jeder der Grafikverarbeitungs-Engines 431-432, N verbunden. Die Grafikspeicher 433-434, M speichern Anweisungen und Daten, die durch jede der Grafikverarbeitungs-Engines 431-432, N verarbeitet werden. Die Grafikspeicher 433-434, M können flüchtige Speicher wie DRAMs (einschließlich gestapelter DRAMs), GDDR-Speicher (z. B. GDDR5, GDDR6) oder HBM sein und/oder können nichtflüchtige Speicher wie 3D-XPoint- oder Nano-Ram sein.
In einer Ausführungsform werden, um Datenverkehr über die Hochgeschwindigkeitsverbindung 440 zu reduzieren, Biasing-Techniken verwendet, um sicherzustellen, dass die in den Grafikspeichern 433-434, M gespeicherten Daten Daten sind, die am häufigsten durch die Grafikverarbeitungs-Engines 431-432, N verwendet werden und vorzugsweise nicht durch die Kerne 460A-460D (zumindest nicht häufig) verwendet werden. Gleichermaßen versucht der Biasing-Mechanismus, Daten, die von den Kernen (und vorzugsweise nicht den Grafikverarbeitungs-Engines 431-432, N) benötigt werden, in den Caches 462A-462D, 456 der Kerne und des Systemspeichers 411 zu halten.
4C veranschaulicht eine andere Ausführungsform, in der die Beschleunigerintegrationsschaltung 436 in dem Prozessor 407 integriert ist. In dieser Ausführungsform kommunizieren die Grafikverarbeitungs-Engines 431-432, N direkt über die Hochgeschwindigkeitsverbindung 440 mit der Beschleunigerintegrationsschaltung 436 über die Schnittstelle 437 und die Schnittstelle 435 (die wiederum irgendeine Form von Bus- oder Schnittstellenprotokoll nutzen kann). Die Beschleunigerintegrationsschaltung 436 kann die gleichen Operationen wie jene durchführen, die mit Bezug auf 4 B beschrieben sind, aber angesichts seiner unmittelbaren Nähe zu dem Kohärenzbus 464 und den Caches 462A-462D, 456 möglicherweise mit einem höheren Durchsatz.
Eine Ausführungsform unterstützt verschiedene Programmiermodelle, darunter ein Programmiermodell mit dedizierten Prozessen (keine Virtualisierung des Grafikbeschleunigungsmoduls) und gemeinsam genutzte Programmiermodelle (mit Virtualisierung). Letzteres kann Programmiermodelle beinhalten, die von der Beschleunigerintegrationsschaltung 436 gesteuert werden, und Programmiermodelle, die von dem Grafikbeschleunigungsmodul 446 gesteuert werden.
In einer Ausführungsform des dedizierten Prozessmodells sind die Grafikverarbeitungs-Engines 431-432, N einer einzigen Anwendung oder einem einzigen Prozess unter einem einzigen Betriebssystem zugeordnet. Die Einzelanwendung kann andere Anwendungsanfragen an die Grafik-Engines 431-432, N leiten, wobei eine Virtualisierung innerhalb einer VM/Partition bereitgestellt wird.
In den Programmiermodellen mit dedizierten Prozessen können die Grafikverarbeitungs-Engines 431-432, N, durch mehrere VM/Anwendungspartitionen gemeinsam genutzt werden. Die gemeinsam genutzten Modelle erfordern einen Systemhypervisor zur Virtualisierung der Grafikverarbeitungs-Engines 431-432, N, um einen Zugriff durch jedes Betriebssystem zu ermöglichen. Für Einzelpartitionssysteme ohne Hypervisor gehören die Grafikverarbeitungs-Engines 431-432, N dem Betriebssystem. In beiden Fällen kann das Betriebssystem die Grafikverarbeitungs-Engines 431-432, N virtualisieren, um Zugriff auf jeden Prozess oder jede Anwendung bereitzustellen.
Für das gemeinsam genutzte Programmiermodell wählt das Grafikbeschleunigungsmodul 446 oder eine einzelne Grafikverarbeitungs-Engine 431-432, N ein Prozesselement unter Verwendung eines Prozess-Handles aus. In einer Ausführungsform werden Prozesselemente in dem Systemspeicher 411 gespeichert und sind unter Verwendung der hierin beschriebenen Techniken zur Übersetzung von effektiven Adressen in reale Adressen adressierbar. Der Prozess-Handle kann ein implementierungsspezifischer Wert sein, der dem Hostprozess bereitgestellt wird, wenn sein Kontext bei der Grafikverarbeitungs-Engine 431-432, N registriert wird (das heißt, Systemsoftware aufgerufen wird, um das Prozesselement zu der verknüpften Prozesselement-Liste hinzuzufügen). Die unteren 16 Bit des Prozess-Handles können der Offset des Prozesselements innerhalb der verknüpften Prozesselement-Liste sein.
4D veranschaulicht ein beispielhaftes Beschleunigerintegrations-Slice 490. Wie hierin verwendet, umfasst ein „Slice“ einen festgelegten Abschnitt der Verarbeitungsressourcen der Beschleunigerintegrationsschaltung 436. Der anwendungseffektive Adressraum 482 im Systemspeicher 411 speichert Prozesselemente 483. In einer Ausführungsform werden die Prozesselemente 483 als Reaktion auf GPU-Aufrufe 481 von Anwendungen 480, die auf dem Prozessor 407 ausgeführt werden, gespeichert. Ein Prozesselement 483 enthält den Prozesszustand für die entsprechende Anwendung 480. Ein Arbeitsdeskriptor (WD: Work Descriptor) 484, der in dem Prozesselement 483 enthalten ist, kann ein einziger Arbeitsauftrag sein, der durch eine Anwendung angefordert wird, oder er kann einen Zeiger auf eine Warteschlange von Arbeitsaufträgen enthalten. Im letzteren Fall ist der WD 484 ein Zeiger auf die Arbeitsauftragsanforderungswarteschlange in dem Adressraum 482 der Anwendung.
Das Grafikbeschleunigungsmodul 446 und/oder die einzelnen Grafikverarbeitungs-Engines 431-432, N können durch alle oder eine Teilmenge der Prozesse in dem System gemeinsam genutzt werden. Ausführungsformen der Erfindung beinhalten eine Infrastruktur zum Einrichten des Prozesszustands und zum Senden eines WD 484 an ein Grafikbeschleunigungsmodul 446 zum Starten eines Arbeitsauftrags in einer virtualisierten Umgebung.
In einer Implementierung ist das Programmiermodell mit dedizierten Prozessen implementierungsspezifisch. In diesem Modell gehört das Grafikbeschleunigungsmodul 446 oder eine individuelle Grafikverarbeitungs-Engine 431 einem einzelnen Prozess. Da das Grafikbeschleunigungsmodul 446 einem einzelnen Prozess gehört, initialisiert der Hypervisor die Beschleunigerintegrationsschaltung 436 für die innehabende Partition und das Betriebssystem initialisiert die Beschleunigerintegrationsschaltung 436 für den innehabenden Prozess zu dem Zeitpunkt, zu dem das Grafikbeschleunigungsmodul 446 zugewiesen wird.
Während des Betriebs ruft eine WD-Abrufeinheit 491 im Beschleunigerintegrations-Slice 490 den nächsten WD 484 ab, der eine Indikation der von einer der Grafikverarbeitungs-Engines des Grafikbeschleunigungsmoduls 446 auszuführenden Arbeit beinhaltet. Daten von dem WD 484 können in Registern 445 gespeichert werden und durch die MMU 439, die Interrupt-Verwaltungsschaltung 447 und/oder die Kontextverwaltungsschaltung 448 wie veranschaulicht verwendet werden. Zum Beispiel beinhaltet eine Ausführungsform der MMU 439 eine Segment-/Seitenlaufschaltungsanordnung zum Zugreifen auf Segment-/Seitentabellen 486 innerhalb des virtuellen OS-Adressraums 485. Die Interrupt-Verwaltungsschaltung 447 kann von dem Grafikbeschleunigungsmodul 446 empfangene Interrupt-Ereignisse 492 verarbeiten. Beim Durchführen von Grafikoperationen wird eine durch eine Grafikverarbeitungs-Engine 431-432 erzeugte effektive Adresse 493 durch die MMU 439 in eine reale Adresse übersetzt.

In einer Ausführungsform wird der gleiche Satz von Registern 445 für jede Grafikverarbeitungs-Engine 431-432, N und/oder jedes Grafikbeschleunigungsmodul 446 dupliziert und kann durch den Hypervisor oder das Betriebssystem initialisiert werden. Jedes dieser duplizierten Register kann in einem Beschleunigerintegrations-Slice 490 enthalten sein. Beispielhafte Register, die von dem Hypervisor initialisiert werden können, sind in Tabelle 1 dargestellt. Tabelle 1 - Vom Hypervisor initialisierte Register

1	Slice-Steuerregister
2	Realadressen(RA)-Bereichszeiger für geplante Prozesse
3	Autoritätsmaskenüberschreibungsregister
4	Interrupt-Vektor-Tabelleneintrag-Offset
5	Interrupt-Vektor-Tabelleneintrag-Grenze
6	Zustandsregister
7	Logikpartition-ID
8	Realadressen(RA)-Hypervisorbeschleunigernutzungsaufzeichnungszeiger
9	Speicherungsbeschreibungsregister

Beispielhafte Register, die vom Betriebssystem initialisiert werden können, sind in Tabelle 2 dargestellt. Tabelle 2 - Vom Betriebssystem initialisierte Register

1	Prozess- und Thread-Identifizierung
2	Effektivadressen(EA)-Kontextspeicherung/-wiederherstellungszeiger
3	Virtuelladressen(VA)-Beschleunigernutzungsaufzeichnungszeiger
4	Virtuelladressen(VA)-Speicherungssegmenttabellenzeiger
5	Autoritätsmaske
6	Arbeitsdeskriptor

In einer Ausführungsform ist jeder WD 484 spezifisch für ein spezielles Grafikbeschleunigungsmodul 446 und/oder eine spezielle Grafikverarbeitungs-Engine 431-432, N. Er enthält alle Informationen, die eine Grafikverarbeitungs-Engine 431-432 benötigt, um ihre Arbeit zu verrichten, oder er kann ein Zeiger auf einen Speicherort sein, an dem die Anwendung eine Befehlswarteschlange für zu verrichtende Arbeit eingerichtet hat.
4E veranschaulicht zusätzliche Einzelheiten für eine Ausführungsform eines gemeinsam genutzten Modells. Diese Ausführungsform beinhaltet einen Hypervisor-Realadressraum 498, in dem eine Prozesselementliste 499 gespeichert ist. Der Hypervisor-Realadressraum 498 ist über einen Hypervisor 496 zugänglich, der die Grafikbeschleunigungsmodul-Engines für das Betriebssystem 495 virtualisiert.
Die gemeinsam genutzten Programmiermodelle ermöglichen, dass alle oder eine Teilmenge von Prozessen von allen oder einer Teilmenge von Partitionen in dem System ein Grafikbeschleunigungsmodul 446 verwenden. Es gibt zwei Programmiermodelle, bei denen das Grafikbeschleunigungsmodul 446 durch mehrere Prozesse und Partitionen gemeinsam genutzt wird: eine gemeinsame Nutzung nach Zeit-Slices und eine grafikgerichtete gemeinsame Nutzung.
In diesem Modell hat der Systemhypervisor 496 das Grafikbeschleunigungsmodul 446 inne und stellt dessen Funktion allen Betriebssystemen 495 zur Verfügung. Damit ein Grafikbeschleunigungsmodul 446 eine Virtualisierung durch den Systemhypervisor 496 unterstützt, kann das Grafikbeschleunigungsmodul 446 die folgenden Anforderungen erfüllen: 1) Eine Arbeitsauftragsanforderung einer Anwendung muss autonom sein (das heißt, der Zustand muss nicht zwischen Arbeitsaufträgen aufrechterhalten werden), oder das Grafikbeschleunigungsmodul 446 muss einen Kontextsicherungs- und -wiederherstellungsmechanismus bereitstellen. 2) Das Grafikbeschleunigungsmodul 446 garantiert, dass eine Arbeitsauftragsanforderung einer Anwendung innerhalb einer spezifizierten Zeitdauer abgeschlossen wird, einschließlich etwaiger Übersetzungsfehler, oder das Grafikbeschleunigungsmodul 446 stellt die Fähigkeit einer Präemption der Verarbeitung des Arbeitsauftrags bereit. 3) Dem Grafikbeschleunigungsmodul 446 muss Fairness zwischen Prozessen garantiert werden, wenn es in dem gerichteten gemeinsam genutzten Programmiermodell arbeitet.
In einer Ausführungsform muss die Anwendung 480 für das gemeinsam genutzte Modell einen Systemsystemaufruf des Betriebssystems 495 mit einem Typ eines Grafikbeschleunigungsmoduls 446, einem Arbeitsdeskriptor (WD), einem AMR-Wert (AMR Authority Mask Register) und einem Bereichszeiger für Kontextspeicherung/-wiederherstellung (Context Save/Restore Area Pointer - CSRP) durchführen. Der Typ des Grafikbeschleunigungsmoduls 446 beschreibt die Zielbeschleunigungsfunktion für den Systemaufruf. Der Typ des Grafikbeschleunigungsmodul 446 kann ein systemspezifischer Wert sein. Der WD ist speziell für das Grafikbeschleunigungsmodul 446 formatiert und kann in Form eines Befehls des Grafikbeschleunigungsmoduls 446, eines Effektivadresszeigers auf eine benutzerdefinierte Struktur, eines Effektivadresszeigers auf eine Warteschlange von Befehlen oder einer beliebigen anderen Datenstruktur zum Beschreiben der durch das Grafikbeschleunigungsmodul 446 zu verrichtenden Arbeit vorliegen. In einer Ausführungsform ist der AMR-Wert der AMR-Zustand, der für den aktuellen Prozess zu verwenden ist. Der an das Betriebssystem weitergebene Wert ähnelt einer Anwendung, die den AMR einstellt. Falls die Implementierungen der Beschleunigerintegrationsschaltung 436 und des Grafikbeschleunigungsmoduls 446 kein Benutzerautoritätsmaskenüberschreibungsregister (UAMOR: User-Authority-Mask-Override-Register) unterstützen, kann das Betriebssystem den aktuellen UAMOR-Wert auf den AMR-Wert anwenden, bevor der AMR in dem Hypervisor-Aufruf übergeben wird. Der Hypervisor 496 kann den aktuellen Autoritätsmaskenüberschreibungsregister(AMOR: Authority Mask Override Register)-Wert anwenden, bevor das AMR in das Prozesselement 483 platziert wird. In einer Ausführungsform ist der CSRP eines der Register 445, die die effektive Adresse eines Bereichs in dem Adressraum 482 der Anwendung für das Grafikbeschleunigungsmodul 446 zum Speichern und Wiederherstellen des Kontextstatus enthält. Dieser Zeiger ist optional, falls kein Status zwischen Arbeitsaufträgen gespeichert werden muss oder wenn ein Arbeitsauftrag zurückgestellt wird. Der Kontextspeicherungs-/-wiederherstellungsbereich kann ein festgelegter Systemspeicher sein.

Beim Empfang des Systemaufrufs kann das Betriebssystem 495 verifizieren, dass die Anwendung 480 registriert wurde und die Berechtigung zur Verwendung des Grafikbeschleunigungsmoduls 446 erhalten hat. Das Betriebssystem 495 ruft dann den Hypervisor 496 mit den in Tabelle 3 gezeigten Informationen auf. Tabelle 3 - OS-zu-Hypervisor-Aufrufparameter

1	Ein Arbeitsdeskriptor (WD)
2	Ein Autoritätsmaskenregister(AMR)-Wert (möglicherweise maskiert).
3	Ein Effektivadressen(EA)-Kontextspeicherungs-/- wiederherstellungsbereichszeiger (CSRP)
4	Eine Prozess-ID (PID) und optionale Thread-ID (TID)
5	Ein Virtuelladressen(VA)-Beschleunigernutzungsaufzeichnungszeiger (AURP)
6	Die virtuelle Adresse des Speicherungssegmenttabellenzeigers (SSTP)
7	Eine logische Interrupt-Dienstnummer (LISN)

Bei Empfang des Hypervisoraufrufs verifiziert der Hypervisor 496, dass das Betriebssystem 495 registriert wurde und die Berechtigung zur Verwendung des Grafikbeschleunigungsmoduls 446 erhalten hat. Der Hypervisor 496 fügt dann das Prozesselement 483 in die verknüpfte Prozesselementliste für den entsprechenden Typ des Grafikbeschleunigungsmoduls 446 ein. Das Prozesselement kann die in Tabelle 4 dargestellten Informationen enthalten. Tabelle 4 - Prozesselementinformationen

1	Ein Arbeitsdeskriptor (WD)
2	Ein Autoritätsmaskenregister(AMR)-Wert (möglicherweise maskiert).
3	Ein Effektivadressen(EA)-Kontextspeicherungs-/--wiederherstellungsbereichszeiger (CSRP)
4	Eine Prozess-ID (PID) und optionale Thread-ID (TID)
5	Ein Virtuelladressen(VA)-Beschleunigernutzungsaufzeichnungszeiger (AURP)
6	Die virtuelle Adresse des Speicherungssegmenttabellenzeigers (SSTP)
7	Eine logische Interrupt-Dienstnummer (LISN)
8	Interrupt-Vektortabelle, abgeleitet von den Hypervisoraufrufparametern.
9	Ein Zustandsregister(SR)-Wert
10	Eine Logikpartitions-ID (LPID)
11	Ein Realadressen(RA)-Hypervisorbeschleunigernutzungsaufzeichnungszeiger
12	Das Speicherungsdeskriptorregister (SDR)

In einer Ausführungsform initialisiert der Hypervisor mehrere Register 445 des Beschleunigerintegrations-Slices 490.
Wie in 4F veranschaulicht, verwendet eine Ausführungsform der Erfindung einen vereinheitlichten Speicher, der über einen gemeinsamen virtuellen Speicheradressraum adressierbar ist, der zum Zugriff auf die physischen Prozessorspeicher 401-402 und GPU-Speicher 420-423 verwendet wird. In dieser Implementierung nutzen auf den GPUs 410-413 ausgeführte Operationen den gleichen Virtuell-/Effektivspeicheradressraum, um auf die Prozessorspeicher 401-402 zuzugreifen, und umgekehrt, wodurch die Programmierbarkeit vereinfacht wird. In einer Ausführungsform ist ein erster Abschnitt des Virtuell-/Effektivspeicheradressraums dem Prozessorspeicher 401, ein zweiter Abschnitt dem zweiten Prozessorspeicher 402, ein dritter Abschnitt dem GPU-Speicher 420 usw. zugewiesen. Der gesamte Virtuell-/Effektivspeicherraum (mitunter als der Effektivadressraum bezeichnet) wird dadurch über jeden der Prozessorspeicher 401-402 und GPU-Speicher 420-423 verteilt, wodurch ermöglicht wird, dass jeder Prozessor oder jede GPU auf einen physischen Speicher mit einer auf diesen Speicher abgebildeten virtuellen Adresse zugreift.
In einer Ausführungsform stellt eine Bias-/Kohärenz-Verwaltungsschaltungsanordnung 494A-494E innerhalb einer oder mehrerer der MMUs 439A-439E eine Cachekohärenz zwischen den Caches der Hostprozessoren (z. B. 405) und der GPUs 410-413 sicher und implementiert Biasing-Techniken, die die physischen Speicher angeben, in denen bestimmte Arten von Daten gespeichert werden sollten. Obgleich mehrere Instanzen der Bias-/Kohärenz-Verwaltungsschaltungsanordnung 494A-494E in 4F veranschaulicht sind, kann die Bias-/Kohärenz-Schaltungsanordnung innerhalb der MMU eines oder mehrerer Hostprozessoren 405 und/oder innerhalb der Beschleunigerintegrationsschaltung 436 implementiert sein.
Eine Ausführungsform ermöglicht, dass der an die GPU angeschlossene Speicher 420-423 als Teil des Systemspeichers abgebildet wird und dass unter Verwendung einer SVM-Technologie (SVM: Shared Virtual Memory) auf ihn zugegriffen wird, ohne jedoch die typischen Leistungsnachteile zu erleiden, die mit vollständiger Systemcachekohärenz verbunden sind. Die Möglichkeit, auf den an die GPU angeschlossenen Speicher 420-423 als Systemspeicher ohne lästigen Cachekohärenz-Overhead zuzugreifen, bietet eine vorteilhafte Betriebsumgebung für GPU-Offload. Diese Anordnung ermöglicht es der Software des Hostprozessors 405, Operanden einzurichten und auf Berechnungsergebnisse zuzugreifen, ohne den Overhead herkömmlicher E/A-DMA-Datenkopien. Solche herkömmlichen Kopien beinhalten Treiberaufrufe, Interrupts und speicherabgebildete E/A-Zugriffe (MMIO-Zugriffe - Memory Mapped I/O), die alle in Bezug auf einfache Speicherzugriffe ineffizient sind. Gleichzeitig kann die Fähigkeit, ohne Cachekohärenz-Overhead auf den an die GPU angeschlossenen Speicher 420-423 zuzugreifen, entscheidend für die Ausführungszeit einer ausgelagerten Berechnung sein. In Fällen mit erheblichem Streaming-Schreibspeicherverkehr kann beispielsweise der Cachekohärenz-Overhead die effektive Schreibbandbreite, die eine GPU 410-413 sieht, erheblich reduzieren. Die Effizienz der Operandeneinrichtung, die Effizienz des Ergebniszugriffs und die Effizienz der GPU-Berechnung spielen alle eine Rolle bei der Bestimmung der Effektivität des GPU-Offloads.
In einer Implementierung wird die Auswahl zwischen GPU-Bias und Hostprozessor-Bias durch eine Bias-Tracker-Datenstruktur gesteuert. Beispielsweise kann eine Bias-Tabelle verwendet werden, die eine seitengranulare Struktur sein kann (d. h. mit der Granularität einer Speicherseite gesteuert werden kann), die 1 oder 2 Bits pro GPU-angeschlossener Speicherseite aufweist. Die Bias-Tabelle kann in einem gestohlenen Speicherbereich eines oder mehrerer GPU-angeschlossener Speicher 420-423 mit oder ohne Bias-Cache in der GPU 410-413 implementiert sein (z. B. um häufig/kürzlich verwendete Einträge der Bias-Tabelle zu cachen). Alternativ dazu kann die gesamte Bias-Tabelle in der GPU beibehalten werden.
In einer Implementierung wird auf den Bias-Tabelleneintrag, der mit jedem Zugriff auf den an die GPU angeschlossenen Speicher 420-423 assoziiert ist, vor dem eigentlichen Zugriff auf den GPU-Speicher zugegriffen, was die folgenden Operationen bewirkt. Zunächst werden lokale Anforderungen von der GPU 410-413, die ihre Seite in GPU-Bias finden, direkt an einen entsprechenden GPU-Speicher 420-423 weitergeleitet. Lokale Anforderungen von der GPU, die ihre Seite in Host-Bias finden, werden an den Prozessor 405 weitergeleitet (z. B. über einen Hochgeschwindigkeits-Link, wie oben erläutert). In einer Ausführungsform schließen Anforderungen von dem Prozessor 405, die die angeforderte Seite in Hostprozessor-Bias finden, die Anforderung wie einen normalen Speicherlesevorgang ab. Alternativ dazu können Anforderungen, die an eine Seite mit GPU-Bias gerichtet sind, an die GPU 410-413 weitergeleitet werden. Die GPU kann dann die Seite zu einem Hostprozessor-Bias überführen, wenn sie die Seite derzeit nicht verwendet.
Der Bias-Zustand 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 Bias-Zustands verwendet einen API-Aufruf (z. B. OpenCL), der wiederum den Vorrichtungstreiber der GPU aufruft, der wiederum eine Nachricht an die GPU sendet (oder einen Befehlsdeskriptor in eine Warteschlange einreiht), die sie anweist, den Bias-Zustand zu ändern und für manche Übergänge eine Cache-Flushing-Operation im Host durchzuführen. Die Cache-Flushing-Operation ist für einen Übergang vom Bias des Hostprozessors 405 zu GPU-Bias erforderlich, ist jedoch für den umgekehrten Übergang nicht erforderlich.
Die Cachekohärenz kann dadurch aufrechterhalten werden, dass bewirkt wird, dass Seiten mit GPU-Bias durch den Hostprozessor 405 vorübergehend nicht gecacht werden können. Um auf diese Seiten zuzugreifen, kann der Prozessor 405 Zugriff von der GPU 410 anfordern, die je nach der Implementierung einen sofortigen Zugriff gewähren kann oder nicht. Somit ist es zur Reduzierung einer Kommunikation zwischen dem Hostprozessor 405 und der GPU 410 vorteilhaft, sicherzustellen, dass Seiten mit GPU-Bias jene sind, die durch die GPU, jedoch nicht den Hostprozessor 405 benötigt werden, und umgekehrt.
Grafikverarbeitungs-Pipeline
5 veranschaulicht eine Grafikverarbeitungs-Pipeline 500 gemäß einer Ausführungsform. In einer Ausführungsform kann ein Grafikprozessor die dargestellte Grafikverarbeitungs-Pipeline 500 implementieren. Der Grafikprozessor kann in den hier beschriebenen Parallelverarbeitungssubsystemen enthalten sein, wie beispielsweise dem Parallelprozessor 200 von 2A, der in einer Ausführungsform eine Variante des Parallelprozessors bzw. der Parallelprozessoren 112 von 1 ist. Die verschiedenen Parallelverarbeitungssysteme können die Grafikverarbeitungs-Pipeline 500 über eine oder mehrere Instanzen der Parallelverarbeitungseinheit (z. B. Parallelverarbeitungseinheit 202 von 2A) implementieren, wie hierin beschrieben. Zum Beispiel kann eine Shader-Einheit (z. B. Grafikmultiprozessor 234 von 2C) dazu konfiguriert sein, die Funktionen einer oder mehrerer einer Vertex-Verarbeitungseinheit 504, einer Tessellationssteuerverarbeitungseinheit 508, einer Tessellationsauswertungsverarbeitungseinheit 512, einer Geometrieverarbeitungseinheit 516 und einer Fragment-/Pixelverarbeitungseinheit 524 auszuführen. Die Funktionen des Daten-Assemblers 502, der Primitiv-Assembler 506, 514, 518, der Tessellationseinheit 510, des Rasterisierers 522 und der Rasteroperationseinheit 526 können auch durch andere Verarbeitungs-Engines innerhalb eines Verarbeitungsclusters (z. B. Verarbeitungsclusters 214 von 2A) und einer entsprechenden Partitionseinheit (z. B. Partitionseinheit 220A-220N von 2A) durchgeführt werden. Die Grafikverarbeitungs-Pipeline 500 kann auch unter Verwendung dedizierter Verarbeitungseinheiten für eine oder mehrere Funktionen implementiert werden. In einer Ausführungsform können ein oder mehrere Abschnitte der Grafikverarbeitungs-Pipeline 500 durch Parallelverarbeitungslogik innerhalb eines Mehrzweckprozessors (z. B. CPU) durchgeführt werden. In einer Ausführungsform können ein oder mehrere Abschnitte der Grafikverarbeitungs-Pipeline 500 über eine Speicherschnittstelle 528, die eine Instanz der Speicherschnittstelle 218 von 2A sein kann, auf einen chipinternen Speicher (z. B. den Parallelprozessorspeicher 222 wie in 2A) zugreifen.
In einer Ausführungsform ist der Daten-Assembler 502 eine Verarbeitungseinheit, die Vertex-Daten für Oberflächen und Primitive sammelt. Der Daten-Assembler 502 gibt dann die Vertex-Daten einschließlich der Vertex-Attribute an die Vertex-Verarbeitungseinheit 504 aus. Die Vertex-Verarbeitungseinheit 504 ist eine programmierbare Ausführungseinheit, die Vertex-Shader-Programme ausführt und Vertex-Daten wie durch die Vertex-Shader-Programme spezifiziert beleuchtet und transformiert. Die Vertex-Verarbeitungseinheit 504 liest Daten, die im Cache-, Lokal- oder Systemspeicher gespeichert sind, zur Verwendung bei der Verarbeitung der Vertex-Daten und kann so programmiert sein, dass sie die Vertex-Daten von einer objektbasierten Koordinatendarstellung in einen Weltkoordinatenraum oder einen normalisierten Vorrichtungskoordinatenraum transformiert.
Eine erste Instanz eines Primitiv-Assemblers 506 empfängt Vertex-Attribute von der Vertex-Verarbeitungseinheit 504. Der Primitiv-Assembler 506 liest nach Bedarf gespeicherte Vertex-Attribute aus und konstruiert Grafikprimitive zur Verarbeitung durch die Tessellationssteuerverarbeitungseinheit 508. Die Grafikprimitive beinhalten Dreiecke, Liniensegmente, Punkte, Felder und so weiter, wie durch verschiedene Grafikverarbeitungs-Anwendungsprogrammierschnittstellen (APIs) unterstützt.
Die Tessellationssteuerungsverarbeitungseinheit 508 behandelt die Eingabe-Vertices als Steuerpunkte für ein geometrisches Feld. Die Steuerpunkte werden von einer Eingabedarstellung von dem Feld (z. B. den Basen des Felds) in eine Darstellung transformiert, die zur Verwendung bei der Oberflächenauswertung durch die Tessellationsauswertungsverarbeitungseinheit 512 geeignet ist. Die Tessellationssteuerverarbeitungseinheit 508 kann auch Tessellationsfaktoren für Kanten geometrischer Felder berechnen. Ein Tessellationsfaktor gilt für eine einzige Kante und quantifiziert einen mit der Kante assoziierten ansichtsabhängigen Detailgrad. Eine Tessellationseinheit 510 ist dazu konfiguriert, die Tessellationsfaktoren für Kanten eines Feldes zu empfangen und das Feld in mehrere geometrische Primitive wie Linien-, Dreieck- oder Viereck-Primitive zu tessellieren, die an eine Tessellationsauswertungsverarbeitungseinheit 512 übertragen werden. Die Tessellationsauswertungsverarbeitungseinheit 512 arbeitet mit parametrisierten Koordinaten des unterteilten Felds, um eine Oberflächendarstellung und Vertex-Attribute für jeden mit den geometrischen Primitiven assoziierten Vertex zu erzeugen.
Eine zweite Instanz eines Primitiv-Assemblers 514 empfängt Vertex-Attribute von der Tessellationsauswertungsverarbeitungseinheit 512, liest gespeicherte Vertex-Attribute nach Bedarf und konstruiert Grafikprimitive zur Verarbeitung durch die Geometrieverarbeitungseinheit 516. Die Geometrieverarbeitungseinheit 516 ist eine programmierbare Ausführungseinheit, die Geometrie-Shader-Programme ausführt, um Grafikprimitive, die von dem Primitiv-Assembler 514 empfangen werden, wie durch die Geometrie-Shader-Programme spezifiziert zu transformieren. In einer Ausführungsform ist die Geometrieverarbeitungseinheit 516 dazu programmiert, die Grafikprimitive in ein oder mehrere neue Grafikprimitive zu unterteilen und Parameter zu berechnen, die zur Rasterung der neuen Grafikprimitive verwendet werden.
Bei manchen Ausführungsformen kann die Geometrieverarbeitungseinheit 516 Elemente in dem Geometriestrom hinzufügen oder löschen. Die Geometrieverarbeitungseinheit 516 gibt die Parameter und Vertices, die neue Grafik-Primitive spezifizieren, an den Primitiv-Assembler 518 aus. Der Primitiv-Assembler 518 empfängt die Parameter und Vertices von der Geometrieverarbeitungseinheit 516 und konstruiert Grafikprimitive zur Verarbeitung durch eine Viewport-Skalierungs-, Cull- und Clip-Einheit 520. Die Geometrieverarbeitungseinheit 516 liest Daten, die im Parallelprozessorspeicher oder Systemspeicher gespeichert sind, zur Verwendung bei der Verarbeitung der Geometriedaten. Die Viewport-Skalierungs-, Cull- und Clip-Einheit 520 führt Clipping, Culling und Viewport-Skalierung durch und gibt verarbeitete Grafikprimitive an einen Rasterisierer 522 aus.
Der Rasterisierer 522 kann Tiefen-Culling und andere tiefenbasierte Optimierungen durchführen. Der Rasterisierer 522 führt auch eine Scankonvertierung an den neuen Grafikprimitiven durch, um Fragmente zu erzeugen und diese Fragmente und zugehörige Abdeckungsdaten an die Fragment-/Pixelverarbeitungseinheit 524 auszugeben. Die Fragment-/Pixelverarbeitungseinheit 524 ist eine programmierbare Ausführungseinheit, die dazu konfiguriert ist, Fragment-Shader-Programme oder Pixel-Shader-Programme auszuführen. Die Fragment-/Pixelverarbeitungseinheit 524 transformiert Fragmente oder Pixel, die von dem Rasterisierer 522 empfangen werden, wie durch die Fragment- oder Pixel-Shader-Programme spezifiziert. Zum Beispiel kann die Fragment-/Pixelverarbeitungseinheit 524 dazu programmiert sein, Operationen durchzuführen, darunter unter anderem Texturabbildung, Shading, Blending, Texturkorrektur und Perspektivenkorrektur, um schattierte Fragmente oder Pixel zu erzeugen, die an eine Rasteroperationseinheit 526 ausgegeben werden. Die Fragment-/Pixelverarbeitungseinheit 524 kann entweder in dem Parallelprozessorspeicher oder in dem Systemspeicher gespeicherte Daten zur Verwendung bei einer Verarbeitung der Fragmentdaten lesen. Fragment- oder Pixel-Shader-Programme können so konfiguriert sein, dass sie abhängig von der für die Verarbeitungseinheiten konfigurierten Abtastrate mit Sample-, Pixel-, Kachel- oder anderen Granularitäten schattieren.
Die Rasteroperationseinheit 526 ist eine Verarbeitungseinheit, die Rasteroperationen durchführt, darunter unter anderem Stencil, z-Test, Blending und dergleichen, und Pixeldaten als verarbeitete Grafikdaten ausgibt, die im Grafikspeicher (z. B. Parallelprozessorspeicher 222 wie in 2A und/oder Systemspeicher 104 wie in 1) gespeichert werden sollen, um auf der einen oder den mehreren Anzeigevorrichtung(en) 110 angezeigt zu werden, oder zur weiteren Verarbeitung durch einen des einen oder der mehreren Prozessor(en) 102 oder Parallelprozessor(en) 112. In manchen Ausführungsformen ist die Rasteroperationseinheit 526 dazu konfiguriert, z- oder Farbdaten, die in Speicher geschrieben werden, zu komprimieren und z- oder Farbdaten, die aus dem Speicher gelesen werden, zu dekomprimieren.
Überblick über das maschinelle Lernen
Die oben beschriebene Architektur kann angewendet werden, um Trainings- und Inferenzoperationen unter Verwendung von Maschinenlernmodellen durchzuführen. Maschinelles Lernen hat sich bei der Lösung vieler Arten von Aufgaben bewährt. Die Berechnungen, die beim Training und bei der Verwendung von Maschinenlernalgorithmen (z. B. neuronalen Netzen) anfallen, eignen sich in ihrer Natur für effiziente Parallelimplementierungen. Dementsprechend haben Parallelprozessoren wie Mehrzweckgrafikverarbeitungseinheiten (GPGPUs) eine bedeutende Rolle bei der praktischen Implementierung von tiefen neuronalen Netzen gespielt. Parallele Grafikprozessoren mit SIMT-Architekturen (SIMT: Single Instruction, Multiple Thread) sind dafür ausgelegt, das Ausmaß der Parallelverarbeitung in der Grafik-Pipeline zu maximieren. In einer SIMT-Architektur versuchen Gruppen von parallelen Threads, Programmanweisungen so oft wie möglich synchron gemeinsam auszuführen, um die Verarbeitungseffizienz zu erhöhen. Die Effizienz, die durch parallele Maschinenlernalgorithmusimplementierungen bereitgestellt wird, ermöglicht die Verwendung von Netzen mit hoher Kapazität und erlaubt es, diese Netze an größeren Datensätzen zu trainieren.
Ein Maschinenlernalgorithmus ist ein Algorithmus, der basierend auf einem Datensatz lernen kann. Ausführungsformen von Maschinenlernalgorithmen können dafür ausgelegt sein, hochgradige Abstraktionen innerhalb eines Datensatzes zu modellieren. Zum Beispiel können Bilderkennungsalgorithmen verwendet werden, um zu bestimmen, welche von mehreren Kategorien zu welcher gegebenen Eingabe gehören; Regressionsalgorithmen können bei einer Eingabe einen numerischen Wert ausgeben; und Mustererkennungsalgorithmen können verwendet werden, um übersetzten Text zu erzeugen oder eine Text-zu-Sprache- und/oder Spracherkennung durchzuführen.
Ein beispielhafter Typ eines Maschinenlernalgorithmus ist ein neuronales Netz. Es gibt viele Arten von neuronalen Netzen; ein einfacher Typ eines neuronalen Netzes ist ein vorwärtsgekoppeltes Netz. Ein vorwärtsgekoppeltes Netz kann als ein azyklischer Graph implementiert sein, in dem die Knoten in Schichten angeordnet sind. Typischerweise weist eine vorwärtsgekoppelte Netztopologie eine Eingabeschicht und eine Ausgabeschicht auf, die durch mindestens eine verborgene Schicht getrennt sind. Die verborgene Schicht wandelt durch die Eingabeschicht empfangene Eingaben in eine Repräsentation um, die zum Erzeugen von Ausgaben in der Ausgabeschicht nützlich ist. Die Netzknoten sind vollständig über Kanten mit den Knoten in angrenzenden Schichten verbunden, aber es gibt keine Kanten zwischen Knoten innerhalb jeder Schicht. Daten, die an den Knoten einer Eingabeschicht eines vorwärtsgekoppelten Netzes empfangen werden, werden über eine Aktivierungsfunktion, die die Zustände der Knoten jeder aufeinanderfolgenden Schicht in dem Netz auf der Grundlage von Koeffizienten („Gewichtungen“) berechnet, die jeweils mit jeder der die Schichten verbindenden Kanten assoziiert sind, an die Knoten der Ausgabeschicht propagiert (d. h. „vorwärts gekoppelt“). Abhängig von dem durch den ausgeführten Algorithmus repräsentierten speziellen Modell kann die Ausgabe von dem Neuronalnetzalgorithmus verschiedene Formen annehmen.
Bevor ein Maschinenlernalgorithmus verwendet werden kann, um ein bestimmtes Problem zu modellieren, wird der Algorithmus unter Verwendung eines Trainingsdatensatzes trainiert. Das Trainieren eines neuronalen Netzes beinhaltet das Auswählen einer Netztopologie, das Verwendung eines Satzes von Trainingsdaten, die ein durch das Netz modelliertes Problem repräsentieren, und das Anpassen der Gewichtungen, bis das Netzmodell für alle Instanzen des Trainingsdatensatzes mit einem minimalen Fehler arbeitet. Zum Beispiel wird während eines Trainingsprozesses mit überwachtem Lernen für ein neuronales Netz die Ausgabe, die durch das Netz als Reaktion auf die eine Instanz in einem Trainingsdatensatz repräsentierende Eingabe erzeugt wird, mit der als „korrekt“ gekennzeichneten Ausgabe für diese Instanz verglichen, ein Fehlersignal, das die Differenz zwischen der Ausgabe und der gekennzeichneten Ausgabe repräsentiert, wird berechnet, und die Gewichtungen, die mit den Verbindungen assoziiert sind, werden angepasst, um diesen Fehler zu minimieren, während das Fehlersignal rückwärts durch die Schichten des Netzes propagiert wird. Das Netz wird als „trainiert“ betrachtet, wenn die Fehler für jede der aus den Instanzen des Trainingsdatensatzes erzeugten Ausgaben minimiert sind.
Die Genauigkeit eines Maschinenlernalgorithmus kann durch die Qualität des zum Trainieren des Algorithmus verwendeten Datensatzes erheblich beeinflusst werden. Der Trainingsprozess kann rechenintensiv sein und kann einen erheblichen Zeitaufwand auf einem herkömmlichen Mehrzweckprozessor erfordern. Dementsprechend wird eine Parallelverarbeitungshardware verwendet, um viele Arten von Maschinenlernalgorithmen zu trainieren. Dies ist besonders zum Optimieren des Trainings von neuronalen Netzen nützlich, da die Berechnungen, die beim Anpassen der Koeffizienten in neuronalen Netzen durchgeführt werden, sich auf natürliche Weise für parallele Implementierungen eignen. Insbesondere wurden viele Maschinenlernalgorithmen und Softwareanwendungen dahingehend angepasst, die Parallelverarbeitungshardware in Mehrzweckgrafikverarbeitungsvorrichtungen zu verwenden.
6 ist ein verallgemeinertes Diagramm eines Softwarestapels 600 für maschinelles Lernen. Eine Maschinenlernanwendung 602 kann dazu konfiguriert sein, ein neuronales Netz unter Verwendung eines Trainingsdatensatzes zu trainieren oder ein trainiertes tiefes neuronales Netz zu verwenden, um Maschinenintelligenz zu implementieren. Die Maschinenlernanwendung 602 kann eine Trainings- und Inferenzfunktionalität für ein neuronales Netz und/oder spezialisierte Software beinhalten, die verwendet werden kann, um ein neuronales Netz vor dem Einsatz zu trainieren. Die Maschinenlernanwendung 602 kann eine beliebige Art von Maschinenintelligenz implementieren, darunter unter anderem Bilderkennung, Kartierung und Lokalisierung, autonome Navigation, Sprachsynthese, medizinische Bildgebung oder Sprachübersetzung.
Die Hardwarebeschleunigung für die Maschinenlernanwendung 602 kann über ein Maschinenlern-Framework 604 aktiviert werden. Das Maschinenlern-Framework 604 kann eine Bibliothek von Maschinenlernprimitiven bereitstellen. Maschinenlernprimitive sind grundlegende Operationen, die üblicherweise durch Maschinenlernalgorithmen durchgeführt werden. Ohne das Maschinenlern-Framework 604 müssten Entwickler von Maschinenlernalgorithmen die mit dem Maschinenlernalgorithmus assoziierte Hauptrechenlogik erstellen und optimieren und dann bei Entwicklung neuer Parallelprozessoren die Rechenlogik erneut optimieren. Stattdessen kann die Maschinenlernanwendung dazu konfiguriert sein, die notwendigen Berechnungen unter Verwendung der Primitive durchzuführen, die von dem Maschinenlern-Framework 604 bereitgestellt werden. Zu beispielhaften Primitiven gehören Tensorfaltungen, Aktivierungsfunktionen und Pooling, bei denen es sich um Rechenoperationen handelt, die während des Trainierens eines faltenden neuronalen Netzes (CNN: Convolutional Neural Network) durchgeführt werden. Das Maschinenlern-Framework 604 kann auch Primitive bereitstellen, um grundlegende Unterprogramme für lineare Algebra, die durch viele Maschinenlernalgorithmen durchgeführt werden, wie etwa Matrix- und Vektoroperationen, zu implementieren.
Das Maschinenlern-Framework 604 kann Eingabedaten, die von der Maschinenlernanwendung 602 empfangen werden, verarbeiten und die geeignete Eingabe in ein Rechen-Framework 606 erzeugen. Das Rechen-Framework 606 kann die dem GPGPU-Treiber 608 bereitgestellten zugrundeliegenden Anweisungen abstrahieren, um zu ermöglichen, dass das Maschinenlern-Framework 604 eine Hardwarebeschleunigung über die GPGPU-Hardware 610 nutzt, ohne dass das Maschinenlern-Framework 604 genaue Kenntnisse über die Architektur der GPGPU-Hardware 610 haben muss. Außerdem kann das Rechen-Framework 606 eine Hardwarebeschleunigung für das Maschinenlern-Framework 604 über viele verschiedene Arten und Generationen der GPGPU-Hardware 610 ermöglichen.
GPGPU-Beschleunigung für maschinelles Lernen
7 veranschaulicht eine Mehrzweckgrafikverarbeitungseinheit 700 gemäß einer Ausführungsform. In einer Ausführungsform kann die Mehrzweckverarbeitungseinheit (GPGPU) 700 derart konfiguriert sein, dass sie besonders effizient beim Verarbeiten der Art von Berechnungsarbeitslasten ist, die mit dem Trainieren von tiefen neuronalen Netzen assoziiert ist. Darüber hinaus kann die GPGPU 700 direkt mit anderen Instanzen der GPGPU verknüpft sein, um einen Multi-GPU-Cluster zu erstellen, um die Trainingsgeschwindigkeit für besonders tiefe neuronale Netze zu verbessern.
Die GPGPU 700 weist eine Hostschnittstelle 702 zum Ermöglichen einer Verbindung mit einem Hostprozessor auf. Bei einer Ausführungsform ist die Hostschnittstelle 702 eine PCI-Express-Schnittstelle. Die Hostschnittstelle kann jedoch auch eine anbieterspezifische Kommunikationsschnittstelle oder ein anbieterspezifisches Kommunikations-Fabric sein. Die GPGPU 700 empfängt Befehle von dem Hostprozessor und verwendet einen globalen Scheduler 704 zum Verteilen von Ausführungs-Threads, die mit diesen Befehlen assoziiert sind, auf einen Satz von Rechenclustern 706A-706H. Die Rechencluster 706A-706H nutzen einen Cachespeicher 708 gemeinsam. Der Cachespeicher 708 kann als Higher-Level-Cache für Cachespeicher innerhalb der Rechencluster 706A-706H dienen.
Die GPGPU 700 beinhaltet einen Speicher 714A-B, der über einen Satz von Speichersteuerungen 712A-712B mit den Rechenclustern 706A-H gekoppelt ist. In verschiedenen Ausführungsformen können die Speichereinheiten 714A-714B verschiedene Arten von Speichervorrichtungen beinhalten, darunter dynamischer Direktzugriffsspeicher (DRAM) oder Grafikdirektzugriffsspeicher, wie etwa synchroner Grafikdirektzugriffsspeicher (SGRAM), einschließlich Grafikspeicher mit doppelter Datenrate (GDDR). In einer Ausführungsform kann der Speicher 714A-714N auch gestapelten 3D-Speicher beinhalten, darunter unter anderem Hochbandbreitenspeicher (HBM).
In einer Ausführungsform beinhaltet jeder der Rechencluster 706A-706H einen Satz von Grafikmultiprozessoren, wie etwa den Grafikmultiprozessor 400 von 4A. Die Grafikmultiprozessoren des Rechenclusters beinhalten mehrere Arten von Ganzzahl- und Gleitkommalogikeinheiten, die Rechenoperationen mit einer Reihe von Präzisionen durchführen können, darunter auch solche, die sich für Berechnungen für maschinelles Lernen eignen. Zum Beispiel und in einer Ausführungsform kann mindestens eine Teilmenge der Gleitkommaeinheiten in jedem der Rechencluster 706A-H dazu konfiguriert sein, 16-Bit- oder 32-Bit-Gleitkommaoperationen durchzuführen, während eine andere Teilmenge der Gleitkommaeinheiten dazu konfiguriert sein kann, 64-Bit-Gleitkommaoperationen durchzuführen.
Mehrere Instanzen der GPGPU 700 können derart konfiguriert sein, dass sie als ein Rechencluster arbeiten. Der Kommunikationsmechanismus, der durch den Rechencluster zur Synchronisation und zum Datenaustausch verwendet wird, variiert zwischen Ausführungsformen. In einer Ausführungsform kommunizieren die mehreren Instanzen der GPGPU 700 über die Hostschnittstelle 702. In einer Ausführungsform beinhaltet die GPGPU 700 einen E/A-Hub 709, der die GPGPU 700 mit einem GPU-Link 710 koppelt, der eine direkte Verbindung mit anderen Instanzen der GPGPU ermöglicht. Bei einer Ausführungsform ist der GPU-Link 710 mit einer dedizierten GPU-zu-GPU-Brücke gekoppelt, die eine Kommunikation und Synchronisation zwischen mehreren Instanzen der GPGPU 700 ermöglicht. In einer Ausführungsform ist die GPU-Verbindung 710 mit einem Hochgeschwindigkeits-Interconnect gekoppelt, um Daten an andere GPGPUs oder Parallelprozessoren zu senden und zu empfangen. In einer Ausführungsform befinden sich die mehreren Instanzen der GPGPU 700 in separaten Datenverarbeitungssystemen und kommunizieren über eine Netzwerkvorrichtung, auf die über die Hostschnittstelle 702 zugegriffen werden kann. In einer Ausführungsform kann die GPU-Verbindung 710 dazu konfiguriert sein, eine Verbindung mit einem Hostprozessor zusätzlich zu oder als eine Alternative zu der Hostschnittstelle 702 zu ermöglichen.
Obgleich die veranschaulichte Konfiguration der GPGPU 700 zum Trainieren von neuronalen Netzen konfiguriert sein kann, stellt eine Ausführungsform eine alternative Konfiguration der GPGPU 700 bereit, die zum Einsatz in einer Inferenzfindungsplattform mit hoher Leistungsfähigkeit oder niedrigem Stromverbrauch konfiguriert sein kann. In einer Inferenzfindungskonfiguration beinhaltet die GPGPU 700 im Vergleich zu der Trainingskonfiguration weniger der Rechencluster 706A-706H. Außerdem kann sich die mit dem Speicher 714A-714B assoziierte Speichertechnologie zwischen Inferenzfindungs- und Trainingskonfigurationen unterscheiden. In einer Ausführungsform kann die Inferenzkonfiguration der GPGPU 700 Inferenzfindung spezieller Anweisungen unterstützen. Zum Beispiel kann eine Inferenzkonfiguration Unterstützung für eine oder mehrere 8-Bit-Ganzzahl-Skalarproduktanweisungen bereitstellen, die üblicherweise während Inferenzoperationen für implementierte neuronale Netze verwendet werden.
8 veranschaulicht ein Multi-GPU-Rechensystem 800 gemäß einer Ausführungsform. Das Multi-GPU-Rechensystem 800 kann einen Prozessor 802 beinhalten, der über einen Hostschnittstellen-Switch 804 mit mehreren GPGPUs 806A-806D gekoppelt ist. Der Hostschnittstellen-Switch 804 ist in einer Ausführungsform eine PCI-Express-Switch-Vorrichtung, die den Prozessor 802 mit einem PCI-Express-Bus koppelt, über den der Prozessor 802 mit dem Satz von GPGPUs 806A-806D kommunizieren kann. Jede der mehreren GPGPUs 806A-806D kann eine Instanz der GPGPU 700 von 7 sein. Die GPGPUs 806A-806D können über einen Satz von Hochgeschwindigkeits-Punkt-zu-Punkt-GPU-zu-GPU-Links 816 verbunden sein. Die Hochgeschwindigkeits-GPU-zu-GPU-Links können mit jeder der GPGPUs 806A-806D über einen dedizierten GPU-Link, wie etwa den GPU-Link 710 wie in 7, verbunden sein. Die P2P-GPU-Links 816 ermöglichen eine direkte Kommunikation zwischen jeder der GPGPUs 806A-806D, ohne dass eine Kommunikation über den Hostschnittstellenbus erforderlich ist, mit dem der Prozessor 802 verbunden ist. Wenn der GPU-zu-GPU-Verkehr auf die P2P-GPU-Links geleitet wird, bleibt der Hostschnittstellenbus für einen Systemspeicherzugriff oder zur Kommunikation mit anderen Instanzen des Multi-GPU-Rechensystems 800 verfügbar, beispielsweise über eine oder mehrere Netzwerkvorrichtungen. Während in der veranschaulichten Ausführungsform die GPGPUs 806A-D über den Hostschnittstellen-Switch 804 mit dem Prozessor 802 verbunden sind, beinhaltet der Prozessor 802 in einer Ausführungsform eine direkte Unterstützung für die P2P-GPU-Verbindungen 816 und kann direkt mit den GPGPUs 806A-806D verbunden sein.
Implementierungen neuronaler Netze für maschinelles Lernen
Die durch die hierin beschriebenen Ausführungsformen bereitgestellte Rechenarchitektur kann dazu konfiguriert sein, die Arten der parallelen Verarbeitung durchzuführen, die insbesondere zum Trainieren und Einsetzen von neuronalen Netzen für maschinelles Lernen geeignet sind. Ein neuronales Netz kann als ein Netz von Funktionen, die in einer Graphenbeziehung stehen, verallgemeinert werden. Wie im Stand der Technik bekannt, gibt es viele verschiedene Arten von Implementierungen neuronaler Netze, die beim maschinellen Lernen verwendet werden. Ein beispielhafter Typ eines neuronalen Netzes ist das vorwärtsgekoppeltes Netz, wie zuvor beschrieben.
Ein zweiter beispielhafter Typ eines neuronalen Netzes ist das faltende neuronale Netz (CNN: Convolutional Neural Network). Ein CNN ist ein spezialisiertes neuronales vorwärtsgekoppeltes Netz zum Verarbeiten von Daten mit einer bekannten gitterartigen Topologie, wie etwa Bilddaten. Dementsprechend werden CNNs üblicherweise für Computer-Vision- und Bilderkennungsanwendungen verwendet, sie können aber auch für andere Arten der Mustererkennung, wie etwa die Verarbeitung gesprochener und geschriebener Sprache, verwendet werden. Die Knoten in der CNN-Eingabeschicht sind in einem Satz von „Filtern“ organisiert (Merkmalsdetektoren, die von den rezeptiven Feldern in der Netzhaut inspiriert sind), und die Ausgabe jedes Filtersatzes wird an Knoten in aufeinanderfolgenden Schichten des Netzes propagiert. Die Berechnungen für ein CNN beinhalten das Anwenden der mathematischen Faltungsoperation auf jedes Filter, um die Ausgabe dieses Filters zu erzeugen. Die Faltung ist eine spezielle Art von mathematischer Operation, bei der zwei Funktionen eine dritte Funktion erzeugen, die eine modifizierte Version einer der beiden ursprünglichen Funktionen ist. In der Terminologie eines faltenden Netzes kann die erste Funktion der Faltung als Eingabe bezeichnet werden, während die zweite Funktion als Faltungskern bezeichnet werden kann. Die Ausgabe kann als Feature-Map bezeichnet werden. Die Eingabe in eine Faltungsschicht kann beispielsweise ein mehrdimensionales Array von Daten sein, das die verschiedenen Farbkomponenten eines Eingabebilds definiert. Der Faltungskern kann ein mehrdimensionales Array von Parametern sein, wobei die Parameter durch den Trainingsprozess für das neuronale Netz angepasst werden.
Rekurrente neuronale Netz (RNNs) sind eine Familie von neuronalen vorwärtsgekoppelten Netzen, die Rückkopplungsverbindungen zwischen Schichten enthalten. RNNs ermöglichen eine Modellierung sequenzieller Daten durch den Austausch von Parameterdaten über verschiedene Teile des neuronalen Netzes hinweg. Die Architektur für ein RNN umfasst Zyklen. Die Zyklen stellen den Einfluss eines gegenwärtigen Wertes einer Variablen auf ihren eigenen Wert zu einem zukünftigen Zeitpunkt dar, da zumindest ein Teil der Ausgangsdaten von dem RNN als eine Rückkopplung zum Verarbeiten einer nachfolgenden Eingabe in einer Sequenz verwendet wird. Diese Eigenschaft macht RNNs aufgrund der variablen Natur, in der Sprachdaten zusammengesetzt werden können, besonders nützlich für die Sprachverarbeitung.
Die nachstehend beschriebenen Figuren zeigen beispielhafte vorwärtsgekoppelte, CNN- und RNN-Netze und beschreiben einen allgemeinen Prozess zum jeweiligen Trainieren und Einsetzen jedes dieser Typen von Netzen dar. Es versteht sich, dass diese Beschreibungen beispielhaft und nicht einschränkend für beliebige spezielle hierin beschriebene Ausführungsform sind und die veranschaulichten Konzepte allgemein auf tiefe neuronale Netze und Maschinenlerntechniken im Allgemeinen angewendet werden können.
Die oben beschriebenen beispielhaften neuronalen Netze können zum Durchführen von tiefem Lernen verwendet werden. Tiefes Lernen ist maschinelles Lernen unter Verwendung von tiefen neuronalen Netzen. Die tiefen neuronalen Netze, die beim tiefen Lernen verwendet werden, sind künstliche neuronale Netze, die aus mehreren verborgenen Schichten bestehen, im Gegensatz zu flachen neuronalen Netzen, die nur eine einzige verborgene Schicht aufweisen. Tiefere neuronale Netze sind im Allgemeinen rechenintensiver zu trainieren. Die zusätzlichen verborgenen Schichten des Netzes ermöglichen jedoch eine mehrstufige Mustererkennung, die verglichen mit flachen Maschinenlerntechniken zu verringerten Ausgabefehlern führt.
Tiefe neuronale Netze, die beim tiefen Lernen verwendet werden, beinhalten in der Regel ein Frontend-Netz zur Durchführung einer Merkmalserkennung, das mit einem Backend-Netz gekoppelt ist, das ein mathematisches Modell repräsentiert, das Operationen (z. B. Objektklassifizierung, Spracherkennung usw.) basierend auf der dem Modell bereitgestellten Merkmalsrepräsentation durchführen kann. Tiefes Lernen ermöglicht ein Durchführen von maschinellem Lernen, ohne dass für das Modell eine manuelle Merkmalskonstruktion durchgeführt werden muss. Stattdessen können tiefe neuronale Netze Merkmale basierend auf einer statistischen Struktur oder Korrelation innerhalb der Eingabedaten lernen. Die gelernten Merkmale können einem mathematischen Modell bereitgestellt werden, das detektierte Merkmale auf eine Ausgabe abbilden kann. Das durch das Netz verwendete mathematische Modell ist im Allgemeinen für die spezielle durchzuführende Aufgabe spezialisiert, und andere Modelle werden verwendet, um andere Aufgaben durchzuführen.
Sobald das neuronale Netz strukturiert ist, kann ein Lernmodell auf das Netz angewendet werden, um das Netz dahingehend zu trainieren, spezielle Aufgaben durchzuführen. Das Lernmodell beschreibt, wie die Gewichtungen innerhalb des Modells anzupassen sind, um den Ausgabefehler des Netzes zu reduzieren. Fehlerrückpropagation ist ein übliches Verfahren zum Trainieren neuronaler Netze. Ein Eingabevektor wird dem Netz zur Verarbeitung bereitgestellt. Die Ausgabe des Netzes wird unter Verwendung einer Verlustfunktion mit der gewünschten Ausgabe verglichen, und für jedes der Neuronen in der Ausgabeschicht wird ein Fehlerwert berechnet. Die Fehlerwerte werden dann rückwärts propagiert, bis jedes Neuron einen zugehörigen Fehlerwert hat, der in etwa seinen Beitrag zur ursprünglichen Ausgabe repräsentiert. Das Netz kann dann aus diesen Fehlern lernen, indem es einen Algorithmus, wie etwa den stochastischen Gradientenabstiegsalgorithmus, verwendet, um die Gewichtungen des neuronalen Netzes zu aktualisieren.
9A-9B veranschaulichen ein beispielhaftes neuronales Faltungsnetz. 9A veranschaulicht verschiedene Schichten innerhalb eines CNN. Wie in 9A gezeigt, kann ein beispielhaftes CNN, das zum Modellieren einer Bildverarbeitung verwendet wird, eine Eingabe 902 empfangen, die die Rot-, Grün- und Blau(RGB)-Komponenten eines Eingabebilds beschreibt. Die Eingabe 902 kann durch mehrere Faltungsschichten (z. B. Faltungsschicht 904, Faltungsschicht 906) verarbeitet werden. Die Ausgabe von den mehreren Faltungsschichten kann gegebenenfalls durch einen Satz vollständig verbundener Schichten 908 verarbeitet werden. Neuronen in einer vollständig verbundenen Schicht weisen vollständige Verbindungen mit allen Aktivierungen in der vorherigen Schicht auf, wie zuvor für ein vorwärtsgekoppeltes Netz beschrieben. Die Ausgabe von den vollständig verbundenen Schichten 908 kann dazu verwendet werden, ein Ausgabeergebnis von dem Netz zu erzeugen. Die Aktivierungen innerhalb der vollständig verbundenen Schichten 908 können unter Verwendung einer Matrixmultiplikation anstelle einer Faltung berechnet werden. Nicht alle CNN-Implementierungen verwenden vollständig verbundene Schichten 908. Zum Beispiel kann in manchen Implementierungen die Faltungsschicht 906 eine Ausgabe für das CNN erzeugen.
Die Faltungsschichten sind spärlich verbunden, was sich von der herkömmlichen Neuronalnetzkonfiguration unterscheidet, die in den vollständig verbundenen Schichten 908 zu finden ist. Herkömmliche Neuronalnetzschichten sind vollständig verbunden, sodass jede Ausgabeeinheit mit jeder Eingabeeinheit interagiert. Die Faltungsschichten sind jedoch spärlich verbunden, da die Ausgabe der Faltung eines Feldes (anstatt des jeweiligen Zustandswertes jedes der Knoten in dem Feld) in die Knoten der nachfolgenden Schicht eingegeben wird, wie veranschaulicht. Die mit den Faltungsschichten assoziierten Kerne führen Faltungsoperationen durch, deren Ausgabe an die nächste Schicht gesendet wird. Die Dimensionalitätsreduzierung, die in den Faltungsschichten durchgeführt wird, ist ein Aspekt, der ermöglicht, dass das CNN zur Verarbeitung großer Bilder skaliert.
9B veranschaulicht beispielhafte Berechnungsstufen innerhalb einer Faltungsschicht eines CNN. Eine Eingabe in eine Faltungsschicht 912 eines CNN kann in drei Stufen einer Faltungsschicht 914 verarbeitet werden. Zu den drei Stufen können eine Faltungsstufe 916, eine Detektorstufe 918 und eine Pooling-Stufe 920 gehören. Die Faltungsschicht 914 kann dann Daten an eine nachfolgende Faltungsschicht ausgeben. Die letzte Faltungsschicht des Netzes kann Ausgabe-Feature-Map-Daten erzeugen oder eine Eingabe in eine vollständig verbundene Schicht bereitstellen, um beispielsweise einen Klassifizierungswert für die Eingabe in das CNN zu erzeugen.
In der Faltungsstufe 916 werden einige Faltungen parallel durchgeführt, um einen Satz linearer Aktivierungen zu erzeugen. Die Faltungsstufe 916 kann eine affine Transformation enthalten, bei der es sich um eine beliebige Transformation handelt, die als lineare Transformation plus eine Translation angegeben werden kann. Affine Transformationen beinhalten Rotationen, Translationen, Skalierungen und Kombinationen dieser Transformationen. Die Faltungsstufe berechnet die Ausgabe von Funktionen (z. B. Neuronen), die mit speziellen Regionen in der Eingabe verbunden sind, die als die mit dem Neuron assoziierte lokale Region bestimmt werden können. Die Neuronen berechnen ein Skalarprodukt zwischen den Gewichtungen der Neuronen und der Region in der lokalen Eingabe, mit der die Neuronen verbunden sind. Die Ausgabe von der Faltungsstufe 916 definiert einen Satz linearer Aktivierungen, die durch aufeinanderfolgende Stufen der Faltungsschicht 914 verarbeitet werden.
Die linearen Aktivierungen können durch eine Detektorstufe 918 verarbeitet werden. In der Detektorstufe 918 wird jede lineare Aktivierung durch eine nichtlineare Aktivierungsfunktion verarbeitet. Die nichtlineare Aktivierungsfunktion erhöht die nichtlinearen Eigenschaften des Gesamtnetzes, ohne die rezeptiven Felder der Faltungsschicht zu beeinflussen. Verschiedene Arten von nichtlinearen Aktivierungsfunktionen können verwendet werden. Eine spezielle Art ist die rektifizierte lineare Einheit (ReLU: Rectified Linear Unit), die eine Aktivierungsfunktion verwendet, die als ƒ(x) = max(0, x) definiert ist, sodass die Aktivierung bei null begrenzt wird.
Die Pooling-Stufe 920 verwendet eine Pooling-Funktion, die die Ausgabe der Faltungsschicht 906 durch eine Zusammenfassungsstatistik der nahegelegenen Ausgaben ersetzt. Die Pooling-Funktion kann dazu verwendet werden, eine Translationsinvarianz in das neuronale Netz einzuführen, sodass kleine Translationen der Eingabe die gepoolten Ausgaben nicht verändern. Die Invarianz gegenüber lokaler Translation kann in Szenarien nützlich sein, in denen das Vorhandensein eines Merkmals in den Eingabedaten wichtiger ist als die genaue Position des Merkmals. Während der Pooling-Stufe 920 können verschiedene Arten von Pooling-Funktionen verwendet werden, darunter Max-Pooling, Average-Pooling und L2-Norm-Pooling. Darüber hinaus beinhalten manche CNN-Implementierungen keine Pooling-Stufe. Stattdessen ersetzen solche Implementierungen eine zusätzliche Faltungsstufe, die eine erhöhte Schrittweite relativ zu vorherigen Faltungsstufen hat.
Die Ausgabe aus der Faltungsschicht 914 kann dann durch die nächste Schicht 922 verarbeitet werden. Die nächste Schicht 922 kann eine zusätzliche Faltungsschicht oder eine der vollständig verbundenen Schichten 908 sein. Zum Beispiel kann die erste Faltungsschicht 904 von 9A zu der zweiten Faltungsschicht 906 ausgeben, während die zweite Faltungsschicht zu einer ersten Schicht der vollständig verbundenen Schichten 908 ausgeben kann.
10 veranschaulicht ein beispielhaftes rekurrentes neuronales Netz 1000. In einem rekurrenten neuronalen Netz (RNN) beeinflusst der vorherige Zustand des Netzes die Ausgabe des aktuellen Zustands des Netzes. RNNs können auf vielfältige Weise unter Verwendung einer Vielzahl von Funktionen konstruiert werden. Bei der Verwendung von RNNs geht es im Allgemeinen um die Verwendung mathematischer Modelle zur Vorhersage der Zukunft auf Grundlage einer vorherigen Sequenz von Eingaben. Ein RNN kann beispielsweise zum Durchführen einer statistischen Sprachmodellierung verwendet werden, um ein kommendes Wort anhand einer vorherigen Wortfolge vorherzusagen. Das veranschaulichte RNN 1000 kann so beschrieben werden, dass es eine Eingabeschicht 1002, die einen Eingabevektor empfängt, verborgene Schichten 1004 zum Implementieren einer rekurrenten Funktion, einen Rückkopplungsmechanismus 1005 zum Ermöglichen eines „Memory“ von vorherigen Zuständen und eine Ausgabeschicht 1006 zum Ausgeben eines Ergebnisses aufweist. Das RNN 1000 arbeitet auf Grundlage von Zeitschritten. Der Zustand des RNN zu einem gegebenen Zeitschritt wird basierend auf dem vorherigen Zeitschritt über den Rückkopplungsmechanismus 1005 beeinflusst. Für einen gegebenen Zeitschritt wird der Zustand der verborgenen Schichten 1004 durch den vorherigen Zustand und die Eingabe in dem aktuellen Zeitschritt definiert. Eine anfängliche Eingabe (x₁) in einem ersten Zeitschritt kann durch die verborgene Schicht 1004 verarbeitet werden. Eine zweite Eingabe (x₂) kann durch die verborgene Schicht 1004 unter Verwendung von Zustandsinformationen, die während der Verarbeitung der anfänglichen Eingabe (x₁) bestimmt werden, verarbeitet werden. Ein gegebener Zustand kann als s_t = ƒ(Ux_t + Ws_{t_1}) berechnet werden, wobei U und W Parametermatrizen sind. Die Funktion ƒ ist im Allgemeinen eine Nichtlinearität, wie etwa die hyperbolische Tangensfunktion (Tanh) oder eine Variante der Gleichrichterfunktion ƒ(x) = max(0,x). Die spezielle mathematische Funktion, die in den verborgenen Schichten 1004 verwendet wird, kann jedoch abhängig von den speziellen Implementierungsdetails des RNN 1000 variieren.
Zusätzlich zu den beschriebenen grundlegenden CNN- und RNN-Netzen können Variationen dieser Netze ermöglicht werden. Eine beispielhafte RNN-Variante ist das Long-Short-Term-Memory(LSTM)-RNN. LSTM-RNNs sind in der Lage, langfristige Abhängigkeiten zu lernen, die für die Verarbeitung längerer Sprachsequenzen notwendig sein können. Eine Variante des CNN ist ein faltendes Deep-Belief-Netz, das eine ähnliche Struktur wie ein CNN aufweist und ähnlich wie ein Deep-Belief-Netz trainiert wird. Ein Deep-Belief-Netz (DBN) ist ein generatives neuronales Netz, das aus mehreren Schichten stochastischer (zufälliger) Variablen besteht. DBNs können Schicht für Schicht mittels unüberwachtem Lernen mit Greedy-Ansatz trainiert werden. Die gelernten Gewichtungen des DBN können dann verwendet werden, um neuronale Vortrainings-Netze bereitzustellen, indem ein optimaler Anfangssatz von Gewichtungen für das neuronale Netz bestimmt wird.
11 veranschaulicht das Training und den Einsatz eines tiefen neuronalen Netzes. Sobald ein gegebenes Netz für eine Aufgabe strukturiert wurde, wird das neuronale Netz unter Verwendung eines Trainingsdatensatzes 1102 trainiert. Verschiedene Trainings-Frameworks 1104 wurden entwickelt, um eine Hardwarebeschleunigung des Trainingsprozesses zu ermöglichen. Zum Beispiel kann das Maschinenlern-Framework 604 von 6 als ein Trainings-Framework 604 konfiguriert sein. Das Trainings-Framework 604 kann sich in ein untrainiertes neuronales Netz 1106 einklinken und ermöglichen, dass das untrainierte neuronale Netz unter Verwendung der hierin beschriebenen Parallelverarbeitungsressourcen trainiert wird, um ein trainiertes neuronales Netz 1108 zu erzeugen.
Um den Trainingsprozess zu beginnen, können die Anfangsgewichtungen zufällig oder durch Vortraining unter Verwendung eines Deep-Belief-Netzes gewählt werden. Der Trainingszyklus kann dann entweder auf überwachte oder auf unüberwachte Weise durchgeführt werden.
Überwachtes Lernen ist eine Lernmethode, bei der das Training als vermittelte Operation durchgeführt wird, z. B. wenn der Trainingsdatensatz 1102 Eingaben enthält, die mit der gewünschten Ausgabe für die Eingabe gepaart sind, oder wenn der Trainingsdatensatz Eingaben mit bekannter Ausgabe enthält und die Ausgabe des neuronalen Netzes manuell bewertet wird. Das Netz verarbeitet die Eingaben und vergleicht die resultierenden Ausgaben mit einem Satz von erwarteten oder gewünschten Ausgaben. Fehler werden dann zurück durch das System propagiert. Das Trainings-Framework 1104 kann die Gewichtungen anpassen, die das untrainierte neuronale Netz 1106 steuern. Das Trainings-Framework 1104 kann Werkzeuge bereitstellen, um zu überwachen, wie gut das untrainierte neuronale Netz 1106 zu einem Modell hin konvergiert, das zum Erzeugen korrekter Antworten auf der Grundlage bekannter Eingabedaten geeignet ist. Der Trainingsprozess findet wiederholt statt, während die Gewichtungen des Netzes angepasst werden, um die durch das neuronale Netz erzeugte Ausgabe zu verfeinern. Der Trainingsprozess kann fortgesetzt werden, bis das neuronale Netz eine mit einem trainierten neuronalen Netz 1108 assoziierte statistisch gewünschte Genauigkeit erreicht. Das trainierte neuronale Netz 1108 kann dann eingesetzt werden, um eine beliebige Anzahl von Maschinenlernoperationen zu implementieren, um ein Inferenzergebnis 1114 basierend auf einer Eingabe neuer Daten 1112 zu erzeugen.
Unüberwachtes Lernen ist eine Lernmethode, bei der das Netz versucht, sich selbst unter Verwendung nicht gekennzeichneter Daten zu trainieren. Somit wird der Trainingsdatensatz 1102 für unüberwachtes Lernen Eingabedaten ohne zugehörige Ausgabedaten enthalten. Das untrainierte neuronale Netz 1106 kann Gruppierungen innerhalb der nicht gekennzeichneten Eingabe lernen und kann bestimmen, wie einzelne Eingaben mit dem gesamten Datensatz in Zusammenhang stehen. Unüberwachtes Training kann verwendet werden, um eine selbstorganisierende Map zu erzeugen, die eine Art trainiertes neuronales Netz 1108 ist, das in der Lage ist, Operationen durchzuführen, die nützlich sind, um die Dimensionalität von Daten zu reduzieren. Unüberwachtes Training kann auch verwendet werden, um eine Anomaliedetektion auszuführen, die die Identifizierung von Datenpunkten in einem Eingabedatensatz ermöglicht, die von den normalen Mustern der Daten abweichen.
Es können auch Variationen von überwachtem und unüberwachtem Training eingesetzt werden. Semi-überwachtes Lernen ist eine Technik, bei der der Trainingsdatensatz 1102 eine Mischung aus gekennzeichneten und nicht gekennzeichneten Daten mit gleicher Verteilung beinhaltet. Inkrementelles Lernen ist eine Variante des überwachten Lernens, bei der die Eingabedaten kontinuierlich verwendet werden, um das Modell weiter zu trainieren.
Inkrementelles Lernen ermöglicht, dass das trainierte neuronale Netz 1108 sich an die neuen Daten 1112 anpasst, ohne das Wissen zu vergessen, das dem Netz bei einem anfänglichen Training vermittelt wurde.
Unabhängig davon, ob er überwacht oder unüberwacht ist, kann der Trainingsprozess für besonders tiefe neuronale Netze für einen einzelnen Rechenknoten zu rechenintensiv sein. Anstatt einen einzelnen Rechenknoten zu verwenden, kann ein verteiltes Netz von Rechenknoten verwendet werden, um den Trainingsprozess zu beschleunigen.
12 ist ein Blockdiagramm, das verteiltes Lernen veranschaulicht. Verteiltes Lernen ist ein Trainingsmodell, das mehrere verteilte Rechenknoten verwendet, um überwachtes oder unüberwachtes Training eines neuronalen Netzes durchzuführen. Die verteilten Rechenknoten können jeweils einen oder mehrere Hostprozessoren und einen oder mehrere der Mehrzweckverarbeitungsknoten umfassen, wie etwa die hochparallele Mehrzweckgrafikverarbeitungseinheit 700 wie in Figur 700. Wie veranschaulicht, kann verteiltes Lernen mit Modellparallelität 1202, Datenparallelität 1204 oder einer Kombination aus Modell- und Datenparallelität 1204 durchgeführt werden.
Bei der Modellparallelität 1202 können verschiedene Rechenknoten in einem verteilten System Trainingsberechnungen für verschiedene Teile eines einzelnen Netzes durchführen. Zum Beispiel kann jede Schicht eines neuronalen Netzes durch einen anderen Verarbeitungsknoten des verteilten Systems trainiert werden. Zu den Vorteilen der Modellparallelität gehört die Möglichkeit, auf besonders große Modelle zu skalieren. Die Aufteilung der Berechnungen, die mit verschiedenen Schichten des neuronalen Netzes assoziiert sind, ermöglicht das Trainieren von sehr großen neuronalen Netzen, bei denen die Gewichtungen aller Schichten nicht in den Speicher eines einzelnen Rechenknotens passen würden. Bei manchen Fällen kann die Modellparallelität besonders nützlich sein, um ein unüberwachtes Training großer neuronaler Netze durchzuführen.
Bei der Datenparallelität 1204 weisen die verschiedenen Knoten des verteilten Netzes eine vollständige Instanz des Modells auf, und jeder Knoten erhält einen anderen Teil der Daten. Die Ergebnisse von den verschiedenen Knoten werden dann kombiniert. Obgleich verschiedene Ansätze zur Datenparallelität möglich sind, erfordern alle datenparallele Trainingsansätze eine Technik zur Kombination von Ergebnissen und zur Synchronisierung der Modellparameter zwischen den einzelnen Knoten. Zu beispielhaften Ansätzen zum Kombinieren von Daten gehören Parametermittelwertbildung und aktualisierungsbasierte Datenparallelität. Die Parametermittelwertbildung trainiert jeden Knoten an einem Teilsatz der Trainingsdaten und setzt die globalen Parameter (z. B. Gewichtungen, Biases) auf den Mittelwert der Parameter von jedem Knoten. Die Parametermittelwertbildung verwendet einen zentralen Parameterserver, der die Parameterdaten verwaltet. Die aktualisierungsbasierte Datenparallelität ist ähnlich wie die Parametermittelwertbildung, außer dass anstelle der Übertragung von Parametern von den Knoten zu dem Parameterserver die Aktualisierungen des Modells übertragen werden. Zudem kann die aktualisierungsbasierte Datenparallelität dezentral durchgeführt werden, wobei die Aktualisierungen komprimiert und zwischen Knoten übertragen werden.
Die kombinierte Modell- und Datenparallelität 1206 kann beispielsweise in einem verteilten System implementiert werden, in dem jeder Rechenknoten mehrere GPUs beinhaltet. Jeder Knoten kann eine vollständige Instanz des Modells aufweisen, wobei separate GPUs innerhalb jedes Knotens dazu verwendet werden, verschiedene Teile des Modells zu trainieren.
Verteiltes Training hat einen erhöhten Overhead im Vergleich zum Training auf einer einzelnen Maschine. Die hier beschriebenen Parallelprozessoren und GPGPUs können jedoch jeweils verschiedene Techniken implementieren, um den Overhead des verteilten Trainings zu reduzieren, darunter Techniken zum Ermöglichen einer GPU-zu-GPU-Datenübertragung mit hoher Bandbreite und einer beschleunigten Ferndatensynchronisation.
Beispielhafte Maschinenlernanwendungen
Maschinelles Lernen kann zur Lösung einer Vielzahl von technologischen Problemen eingesetzt werden, darunter unter anderem Computer-Vision, autonomes Fahren und Navigation, Erkennung gesprochener Sprache und Sprachverarbeitung. Computer-Vision ist traditionell eines der aktivsten Forschungsgebiete für Maschinenlernanwendungen. Anwendungen von Computer-Vision reichen von der Reproduktion menschlicher visueller Fähigkeiten, wie etwa dem Erkennen von Gesichtern, bis hin zur Schaffung neuer Kategorien visueller Fähigkeiten. Zum Beispiel können Computer-Vision-Anwendungen dazu konfiguriert sein, Schallwellen aus den Vibrationen, die in den in einem Video sichtbaren Objekten induziert werden, erkennen. Parallelprozessor-beschleunigtes maschinelles Lernen ermöglicht es, Computer-Vision-Anwendungen unter Verwendung wesentlich größerer Trainingsdatensätze zu trainieren, als dies bisher möglich war, und ermöglicht es, Inferenzsysteme unter Verwendung von Niederleistungs-Parallelprozessoren einzusetzen.
Parallelprozessor-beschleunigtes maschinelles Lernen hat Anwendungen für autonomes Fahren, einschließlich Fahrspur- und Verkehrszeichenerkennung, Hindernisvermeidung, Navigation und Fahrkontrolle. Beschleunigte Maschinenlerntechniken können zum Trainieren von Fahrmodellen auf der Grundlage von Datensätzen verwendet werden, die die entsprechenden Reaktionen auf bestimmte Trainingseingaben definieren. Die vorliegend beschriebenen Parallelprozessoren können ein schnelles Training der zunehmend komplexen neuronalen Netze ermöglichen, die für Lösungen zum autonomen Fahren verwendet werden, und ermöglichen den Einsatz von Niederleistungs-Inferenzprozessoren in einer mobilen Plattform, die zur Integration in autonome Fahrzeuge geeignet ist.
Parallelprozessor-beschleunigte tiefe neuronale Netze haben Maschinenlernansätze für die automatische Spracherkennung (ASR: Automatic Speech Recognition) ermöglicht. ASR beinhaltet die Erstellung einer Funktion, die die wahrscheinlichste sprachliche Sequenz angesichts einer akustischen Eingabesequenz berechnet. Beschleunigtes maschinelles Lernen unter Verwendung tiefer neuronaler Netze hat es ermöglicht, die bisher für ASR verwendeten Hidden-Markov-Modelle (HMMs) und Gaußschen Mischmodelle (GMMs) zu ersetzen.
Parallelprozessor-beschleunigtes maschinelles Lernen kann auch zur Beschleunigung der Verarbeitung natürlicher Sprache verwendet werden. Automatische Lernverfahren können statistische Inferenzalgorithmen nutzen, um Modelle zu erzeugen, die robust gegenüber fehlerhaften oder ungewohnten Eingaben sind. Zu beispielhaften Anwendungen für natürliche Sprachprozessoren gehört die automatische maschinelle Übersetzung zwischen menschlichen Sprachen.
Die für maschinelles Lernen verwendeten Parallelverarbeitungsplattformen können in Trainingsplattformen und Einsatzplattformen unterteilt werden. Trainingsplattformen sind im Allgemeinen hochparallel und beinhalten Optimierungen zur Beschleunigung von Multi-GPU-Einzelknoten-Training und Multi-Knoten-Multi-GPU-Training. Zu beispielhaften Parallelprozessoren, die sich für das Training eignen, gehören die Mehrzweckgrafikverarbeitungseinheit 700 von Figur 700 und das Multi-GPU-Rechensystem 800 von Figur 800. Eingesetzte Maschinenlernpattformen beinhalten dagegen im Allgemeinen Niederleistungsparallelprozessoren, die zur Verwendung in Produkten wie Kameras, autonomen Robotern und autonomen Fahrzeugen geeignet sind.
13 veranschaulicht ein beispielhaftes Inferenzfindungssystem auf einem Chip (SOC) 1300, das zur Durchführung von Inferenzfindung unter Verwendung eines trainierten Modells geeignet ist. Das SOC 1300 kann Verarbeitungskomponenten integrieren, darunter einen Medienprozessor 1302, einen Bildverarbeitungsprozessor 1304, eine GPGPU 1306 und einen Mehrkernprozessor 1308. Das SOC 1300 kann zusätzlich einen On-Chip-Speicher 1305 beinhalten, der einen gemeinsam genutzten On-Chip-Datenpool ermöglichen kann, auf den jede der Verarbeitungskomponenten zugreifen kann. Die Verarbeitungskomponenten können für einen Niederleistungsbetrieb optimiert werden, um den Einsatz in einer Vielzahl von Maschinenlernplattformen zu ermöglichen, einschließlich autonomer Fahrzeuge und autonomer Roboter. Eine Implementierung des SOC 1300 kann zum Beispiel als Teil des Hauptsteuersystems für ein autonomes Fahrzeug verwendet werden. Wenn das SOC 1300 zur Verwendung in autonomen Fahrzeugen konfiguriert ist, ist das SOC dahingehend ausgelegt und konfiguriert, die relevanten funktionalen Sicherheitsstandards des Einsatzlandes zu erfüllen.
Während des Betriebs können der Medienprozessor 1302 und der Bildverarbeitungsprozessor 1304 zusammenarbeiten, um Computer-Vision-Operationen zu beschleunigen. Der Medienprozessor 1302 kann eine latenzarme Decodierung mehrerer hochauflösender Videoströme (z. B. 4K, 8K) ermöglichen. Die decodierten Videoströme können in einen Puffer in dem On-Chip-Speicher 1305 geschrieben werden. Der Vision-Prozessor 1304 kann dann das decodierte Video parsen und vorläufige Verarbeitungsoperationen an den Frames des decodierten Videos als Vorbereitung der Verarbeitung der Frames unter Verwendung eines trainierten Bilderkennungsmodells durchführen. Beispielsweise kann der Bildverarbeitungsprozessor 1304 die Faltungsoperationen für ein CNN beschleunigen, das zur Durchführung von Bilderkennung an den hochauflösenden Videodaten verwendet wird, während die Backend-Modellberechnungen durch die GPGPU 1306 durchgeführt werden.
Der Mehrkernprozessor 1308 kann eine Steuerlogik beinhalten, die bei der Sequenzierung und Synchronisierung von Datenübertragungen und gemeinsamen Speicheroperationen hilft, die durch den Medienprozessor 1302 und den Vision-Prozessor 1304 durchgeführt werden. Der Mehrkernprozessor 1308 kann zudem als Anwendungsprozessor fungieren, um Softwareanwendungen auszuführen, die die Inferenzrechenfähigkeit der GPGPU 1306 nutzen können. Zum Beispiel kann zumindest ein Teil der Navigations- und Fahrlogik in Software implementiert sein, die auf dem Mehrkernprozessor 1308 ausgeführt wird. Derartige Software kann direkt Rechenlasten an die GPGPU 1306 ausgeben oder die Rechenlasten können an den Mehrkernprozessor 1308 ausgegeben werden, der zumindest einen Teil dieser Operationen an die GPGPU 1306 auslagern kann.
Die GPGPU 1306 kann Rechencluster beinhalten, wie etwa eine Stromsparkonfiguration der Rechencluster 706A-706H innerhalb der Mehrzweckgrafikverarbeitungseinheit 700. Die Rechencluster innerhalb der GPGPU 1306 können Anweisungen unterstützen, die spezifisch zur Durchführung von Inferenzberechnungen in einem trainierten neuronalen Netz optimiert sind. Die GPGPU 1306 kann beispielsweise Anweisungen zur Durchführung von Berechnungen mit geringer Präzision wie 8-Bit- und 4-Bit-Ganzzahl-Vektoroperationen unterstützen.
Mehrfachkachel-Grafikprozessor-Rendering
Bei manchen Ausführungsformen stellt eine Einrichtung, ein System oder ein Prozess ein Mehrfachkachel-Prozessor-Rendering bereit.
14A ist eine Darstellung eines Mehrfachkachel-Grafikprozessors gemäß manchen Ausführungsformen. Bei manchen Ausführungsformen umfasst ein Grafikprozessor 1400 ein Substrat 1475 und anstelle eines einzigen Verarbeitungschips mehrere Kacheln 1405, die als Chiplets bezeichnet werden können. Bei manchen Ausführungsformen kann der Grafikprozessor 1400 ein Array von Kacheln beinhalten, wie zum Beispiel das 4-mal-4-Array von Kacheln 1405, das in 14A dargestellt ist. Ausführungsbeispiele sind jedoch nicht auf irgendeine bestimmte Anordnung von Kacheln mit dem Grafikprozessor beschränkt.
Bei manchen Ausführungsformen stellt der Grafikprozessor Operationen bereit, wie sie in 14B-16B dargestellt sind.
14B ist eine Darstellung einer Mehrfachkachel-GPU, die gemäß manchen Ausführungsformen Geometrie-Hashing über Kacheln mit Zeichnungs- oder Objektgranularität bereitstellt. In einer Mehrfachkachel-GPU 1400, wie etwa dem in 14A veranschaulichten Grafikprozessor 1400, ist ein Geometrie-Hashing über die mehreren Kacheln des Prozessors bei Zeichnungs- oder Objektgranularität erlaubt. Auf diese Weise ist ein feinkörniges Lastgleichgewicht für die Leistungsskalierung besser.
Wie in 14B veranschaulicht, beinhaltet ein Grafikprozessor 1400 mehrere Kacheln, wie etwa Kachel-0 1430, Kachel-1 1435, Kachel-2 1440 und Kachel-3 1445. In einer GPU einschließlich mehrerer Kacheln weisen Geometriedaten, über eine Geometrie hinaus verschoben werden, eine Je-Bildschirmkachel-Basis zu jeder GPU-Kachel auf. Jede GPU-Kachel arbeitet an einer bestimmten GPU-Kachel der mehreren GPU-Kacheln und arbeitet derart, dass Pixeldaten lokal auf der GPU-Kachel gehalten werden.
In manchen Ausführungsformen wird nur eine Geometrie mit geringer Bandbreite über die GPU-Kacheln 1430-1445 bewegt. Darüber hinaus ermöglicht der vereinheitlichte Speicher der Anzeige, Daten aus jeder Kachel zu ziehen, ohne die Daten der GPU-Kacheln zu konsolidieren.
15A ist eine Darstellung einer geometrischen Datenverteilung in einer GPU mit mehreren Kacheln gemäß manchen Ausführungsformen. Bei manchen Ausführungsformen sieht eine Einrichtung, ein System oder ein Prozess vor, dass geometrische Daten pro Bildschirmkachel übertragen werden, so dass sie sich lokal in jeder der mehreren Kacheln eines Grafikprozessors zu befinden.
15A veranschaulicht die Geometriedatenverteilung in einer Einrichtung, einem System oder einem Prozess. Bei manchen Ausführungsformen werden, sobald den geometrischen Daten 1510 eine bildschirmbasierte Kachel 1515 zugewiesen wurde, die als Zuweisung von geometrischen Daten zu Bildschirmkachel-0, Bildschirmkachel-1, Bildschirmkachel-2 und Bildschirmkachel-3 gezeigt ist, die lokalen Daten von einer verteilten Datenstruktur zu einer speichergestützten lokalen Kachel-Datenstruktur 1520 verschoben, um Pixeldaten lokal bei einer jeweiligen Kachel der GPU zu halten. Dies ist in 15 als eine Verteilung von der verteilten Datenspeicherung für Bildschirmkachel-0, Bildschirmkachel-1, Bildschirmkachel-2 und Bildschirmkachel-3 zur kachelbasierten Speicherung GPU-Kachel-0, GPU-Kachel-1, GPU-Kachel-2 und GPU-Kachel-3 veranschaulicht.
15B ist eine Darstellung einer Kachel basierend auf dem Sammeln von Dreiecken pro Kachel gemäß manchen Ausführungsformen. Bei manchen Ausführungsformen besteht das kachelbasierte Rendering in einer Multikachel-GPU 1550, die als mehrere Kacheln 1555 enthaltend gezeigt ist, darin, sämtliche Dreiecke pro Kachelzuordnung auf eine oder mehrere bildschirmausgerichtete Kacheln aus demselben Rendering-Durchgang zu sammeln. Dies ist in 15B als Rendering-Durchgang 1560 veranschaulicht, der zu einer Sammlung aller Dreiecke pro Bildschirmkachel 1570 führt, die den GPU-Kacheln 1575 zugeordnet sind.
Auf diese Weise schließen sich Pixeldaten (Farbe und Tiefe) an Kachel(Chiplet-)Grenzen jeweils gegenseitig aus. Erforderliche Attribute werden somit zusammen mit einer Sortierung von Dreiecken pro Kachel (Bildschirmplatzkachel) von dem Geometrie-Pipe in die lokale Kachel geschoben.
16A ist eine Veranschaulichung einer mehrstufigen GPU-Architektur zur Skalierung der Leistungsfähigkeit mit Mesh-Shading. Bei manchen Ausführungsformen soll eine Einrichtung, ein System oder ein Prozess eine Verbesserung der Mesh-Shader/Compute-Walker-Verteilung bereitstellen. Wie in 16A veranschaulicht, soll der Mesh-Shader mit mehreren Kacheln 1610 einer GPU arbeiten, wie beispielsweise den in 14A dargestellten Kacheln.
Bei manchen Ausführungsformen bezieht jede Kachel 1610 der Mehrfachkachel-GPU Geometriedaten für die Rasterverarbeitung. Jede Kachel arbeitet dann lokal auf der Kachel. Die Einrichtung, das System oder der Prozess soll im Wesentlichen ein kachelbasiertes Sofortmodus-Rendering (TBIMR) mit dem Mesh-Shader bereitstellen.
Vorteile einer Ausführungsform beinhalten Folgendes:

(a) Vermeidung teurer Verschiebungen von Daten über Kacheln.
(b) Ermöglichen einer Skalierung der Leistungsfähigkeit mit der Anzahl der GPU-Kacheln.
(c) TBIMR-Unterstützung mit einem Mesh-Shader.

16B ist eine Darstellung eines Stream-Out von Mesh-Shader-Daten zur Kompression gemäß manchen Ausführungsformen. Wie in Figur In 16B veranschaulicht, beziehen sich lokale Daten 1650 auf einen Speicher 1660, wobei sich Vertex-Daten und Primitivdaten auf VOR0 und v1r1 beziehen. Auch in 16B ist ein Mesh-Shader 1670 veranschaulicht, der Daten 1657 empfängt und sendet, mit einem/einer Stream-Out-Mechanismus oder -Schaltung 1680, um Daten an den Speicher zu liefern.
In einer herkömmlichen Architektur ist die Mesh-Shader-Ausgabe von Daten pro Vertex und pro Primitiv ein Array von Strukturen. Für Daten, die in einem komprimierten Format zu speichern sind, müssen die Daten in eine Struktur von Arrays transformiert werden. Bei manchen Ausführungsformen dient der/die Stream-Out-Mechanismus oder -Schaltung 1680 dazu, beliebige Mesh-Daten von dem Mesh-Shader 1670 zu lesen und solche Daten in einen Speicher in einer Struktur von Arrays zu schreiben.
Systemübersicht
17 ist ein Blockdiagramm eines Verarbeitungssystems 1700 gemäß einer Ausführungsform. Das System 1700 kann in einem Einzelprozessor-Desktop-System, einem Multiprozessor-Workstation-System oder einem Serversystem mit einer großen Anzahl von Prozessoren 1702 oder Prozessorkernen 1707 verwendet werden. In einer Ausführungsform ist das System 1700 eine Verarbeitungsplattform, die innerhalb einer integrierten System-on-Chip(SoC)-Schaltung zur Verwendung in mobilen, handgehaltenen oder eingebetteten Vorrichtungen, wie etwa innerhalb von Internet-der-Dinge(IoT)-Vorrichtungen mit drahtgebundener oder drahtloser Konnektivität zu einem Lokal- oder Weitbereichsnetzwerk, integriert ist.
In einer Ausführungsform kann das System 1700 Folgendes beinhalten, damit gekoppelt sein oder darin integriert sein: eine serverbasierte Gaming-Plattform; eine Spielkonsole, einschließlich einer Spiel- und Medienkonsole; eine Mobile-Gaming-Konsole, eine handgehaltene Spielkonsole oder eine Onlinespielkonsole. Bei manchen Ausführungsformen ist das System 1700 Teil eines Mobiltelefons, Smartphones, einer Tablet-Rechenvorrichtung oder eines mobilen internetverbundenen Vorrichtung, wie etwa eines Laptops mit geringer interner Speicherkapazität. Das Verarbeitungssystem 1700 kann auch Folgendes beinhalten, damit gekoppelt oder darin integriert sein: eine Wearable-Vorrichtung, wie etwa eine Smartwatch-Wearable-Vorrichtung; eine Datenbrille oder Smart-Kleidung, erweitert mit Augmented-Reality(AR)- oder Virtual-Reality(VR)-Merkmalen, um visuelle, Audio- oder taktile Ausgaben bereitzustellen, um visuelle, Audio- oder taktile reelle Erfahrungen zu ergänzen oder anderweitig Text, Audio, Grafiken, Video, holografische Bilder oder Video oder taktiles Feedback bereitzustellen; eine andere Augmented-Reality(AR)-Vorrichtung; oder eine andere Virtual-Reality(VR) -Vorrichtung. Bei manchen Ausführungsformen beinhaltet das Verarbeitungssystem 1700 eine Fernseher- oder Set-Top-Box-Vorrichtung oder ist Teil davon.
Bei manchen Ausführungsform kann das System 1700 ein selbstfahrendes Fahrzeug, wie etwa einen Bus, einen Traktoranhänger, ein Auto, ein Motorrad oder E-Bike, ein Flugzeug oder Segelflugzeug (oder eine beliebige Kombination davon), beinhalten, damit gekoppelt oder darin integriert sein. Das selbstfahrende Fahrzeug kann das System 1700 zur Verarbeitung der um das Fahrzeug herum erfassten Umgebung verwenden.
Bei manchen Ausführungsformen beinhalten der eine oder die mehreren Prozessoren 1702 jeweils einen oder mehrere Prozessorkerne 1707, um Anweisungen zu verarbeiten, die dann, wen sie ausgeführt werden, Operationen für System- und Anwender-Software durchführen. Bei manchen Ausführungsformen ist mindestens einer des einen oder der mehreren Prozessorkerne 1707 dazu konfiguriert, einen speziellen Anweisungssatz 1709 zu verarbeiten. Bei manchen Ausführungsformen kann der Anweisungssatz 1709 Berechnungen mit komplexem Anweisungssatz (CISC), Berechnung mit reduziertem Anweisungssatz (RISC) oder Berechnungen über ein sehr langes Befehlswort (VLIW) unterstützen. Ein oder mehrere Prozessorkerne 1707 können einen unterschiedlichen Anweisungssatz 1709 verarbeiten, der Anweisungen enthalten kann, um die Emulation anderer Anweisungsätze zu unterstützen. Der Prozessorkern 1707 kann auch andere Verarbeitungsvorrichtungen beinhalten, wie etwa einen Digitalsignalprozessor (DSP).
Bei manchen Ausführungsformen beinhaltet der Prozessor 1702 einen Cachespeicher 1704. In Abhängigkeit von der Architektur kann der Prozessor 1702 einen einzigen internen Cache oder mehrere Ebenen von internem Cache aufweisen. In manchen Ausführungsformen wird der Cachespeicher durch verschiedene Komponenten des Prozessors 1702 gemeinsam genutzt. Bei manchen Ausführungsformen verwendet der Prozessor 1702 auch einen externen Cache (z. B. einen Level-3(L3)-Cache oder einen Cache der letzten Ebene (LLC)) (nicht gezeigt), der durch Prozessorkerne 1707 unter Verwendung bekannter Cachekohärenztechniken gemeinsam genutzt wird. Eine Registerbank 1706 kann zusätzlich in dem Prozessor 1702 enthalten sein und kann verschiedene Arten von Registern zum Speichern verschiedener Arten von Daten (z. B. Ganzzahlregister, Gleitkommaregister, Statusregister und ein Anweisungszeigerregister) beinhalten. Manche Register können Mehrzweckregister sein, während andere Register speziell für die Gestaltung des Prozessors 1702 sein können.
Bei manchen Ausführungsformen sind der eine oder die mehreren Prozessor(en) 1702 mit einem oder mehreren Schnittstellenbus(sen) 1710 zum Übertragen von Kommunikationssignalen, wie etwa Adress-, Daten- oder Steuersignalen, zwischen dem Prozessor 1702 und anderen Komponenten in dem System 1700 gekoppelt. Der Schnittstellenbus 1710 kann in einer Ausführungsform ein Prozessorbus sein, wie etwa eine Version des DMI-Busses (DMI: Direct Media Interface). Prozessorbusse sind jedoch nicht auf den DMI-Bus beschränkt und können einen oder mehrere Peripheral-Component-Interconnect-Busse (z. B. PCI, PCI Express), Speicherbusse oder andere Arten von Schnittstellenbussen beinhalten. In einer Ausführungsform beinhalten der/die Prozessor(en) 1702 eine integrierte Speichersteuerung 1716 und einen Plattformsteuerungshub 1730. Die Speichersteuerung 1716 ermöglicht eine Kommunikation zwischen einer Speichervorrichtung und anderen Komponenten des Systems 1700, während der Plattformsteuerungshub (PCH: Plattform Controller Hub) 1730 Verbindungen zu E/A-Vorrichtungen über einen lokalen E/A-Bus bereitstellt.
Die Speichervorrichtung 1720 kann eine dynamische Direktzugriffsspeicher(DRAM)-Vorrichtung, eine statische Direktzugriffsspeicher(SRAM)-Vorrichtung, eine Flash-Speichervorrichtung, eine Phasenwechselspeichervorrichtung oder eine andere Speichervorrichtung sein, die eine geeignete Leistungsfähigkeit aufweist, um als ein Prozessspeicher zu dienen. In einer Ausführungsform kann die Speichervorrichtung 1720 als Systemspeicher für das System 1700 arbeiten, um Daten 1722 und Anweisungen 1721 zu speichern, die verwendet werden, wenn der eine oder die mehreren Prozessoren 1702 eine Anwendung oder einen Prozess ausführt. Die Speichersteuerung 1716 ist auch mit einem optionalen externen Grafikprozessor 1718 gekoppelt, der mit dem einen oder den mehreren Grafikprozessoren 1708 in den Prozessoren 1702 kommunizieren kann, um Grafik- und Medienoperationen durchzuführen. Bei manchen Ausführungsformen können Grafik-, Medien- und/oder Rechenoperationen durch einen Beschleuniger 1712 unterstützt werden, der ein Coprozessor ist, der dazu konfiguriert sein kann, einen spezialisierten Satz von Grafik-, Medien- oder Rechenoperationen durchzuführen. In einer Ausführungsform ist der Beschleuniger 1712 zum Beispiel ein Matrixmultiplikationsbeschleuniger, der verwendet wird, um Maschinenlern- oder Rechenoperationen zu optimieren. In einer Ausführungsform ist der Beschleuniger 1712 ein Strahlverfolgungsbeschleuniger, der verwendet werden kann, um Strahlverfolgungsoperationen in Abstimmung mit dem Grafikprozessor 1708 durchzuführen. Bei manchen Ausführungsformen kann eine Anzeigevorrichtung 1711 mit dem/den Prozessor(en) 1702 verbunden sein. Die Anzeigevorrichtung 1711 kann eine interne Anzeigevorrichtung, wie in einer mobilen elektronischen Vorrichtung oder einer Laptopvorrichtung, und/oder eine externe Anzeigevorrichtung sein, die über eine Anzeigeschnittstelle (z. B. DisplayPort usw.) angeschlossen ist. In einer Ausführungsform kann die Anzeigevorrichtung 1711 eine am Kopf befestigte Anzeige (HMD: Head Mounted Display) sein, wie etwa eine stereoskopische Anzeigevorrichtung zur Verwendung bei Virtual-Reality(VR)-Anwendungen oder Augmented-Reality(AR)-Anwendungen.
Bei manchen Ausführungsformen ermöglicht es der Plattformsteuerungshub 1730 Peripheriegeräten, sich über einen Hochgeschwindigkeits-E/A-Bus mit der Speichervorrichtung 1720 und dem Prozessor 1702 zu verbinden. Die E/A-Peripheriegeräte beinhalten unter anderem eine Audio Steuerung 1746, eine Netzwerksteuerung 1734, eine Firmware-Schnittstelle 1728, einen drahtlosen Sendeempfänger 1726, Berührungssensoren 1725, eine Datenspeicherungsvorrichtung 1724 (z. B. nichtflüchtigen Speicher, flüchtiger Speicher, Festplattenlaufwerk, Flash-Speicher, NAND, 3D-NAND, 3D-XPoint usw.). Die Datenspeicherungsvorrichtung 1724 kann über eine Speicherungsschnittstelle (z. B. SATA) oder über einen Peripheriebus, wie etwa einen Peripheral-Component-Interconnect-Bus (z. B. PCI, PCI Express), verbunden sein. Die Berührungssensoren 1725 können Touchscreen-Sensoren, Drucksensoren oder Fingerabdrucksensoren einschließen. Der drahtlose Sendeempfänger 1726 kann ein WiFi-Sendeempfänger, ein Bluetooth-Sendeempfänger oder ein Mobilnetz-Sendeempfänger sein, wie etwa ein 3G-, 4G-, 5G- oder Long-Term-Evolution(LTE)-Sendeempfänger. Die Firmwareschnittstelle 1728 ermöglicht die Kommunikation mit Systemfirmware und kann beispielsweise eine vereinheitlichte erweiterbare Firmwareschnittstelle (UEFI: Unified Extensible Firmware Interface) sein. Die Netzwerksteuerung 1734 kann eine Netzwerkverbindung zu einem drahtgebundenen Netzwerk ermöglichen. Bei manchen Ausführungsformen ist eine Hochleistungsnetzwerksteuerung (nicht gezeigt) mit dem Schnittstellenbus 1710 gekoppelt. Die Audiosteuerung 1746 ist in einer Ausführungsform eine Mehrkanal-High-Definition-Audiosteuerung. Bei einer Ausführungsform beinhaltet das System 1700 eine optionale Legacy-E/A-Steuerung 1740 zum Koppeln von Legacy(z. B. Personal System 2 (PS/2))-Vorrichtungen mit dem System. Der Plattformsteuerungshub 1730 kann auch mit einem oder mehreren USB(Universal Serial Bus)-Steuerungen 1742 verbunden sein, welche Eingabevorrichtungen, wie etwa Kombinationen aus Tastatur und Maus 1743, eine Kamera 1744 oder andere USB-Eingabevorrichtungen, verbinden.
Es versteht sich, dass das gezeigte System 1700 beispielhaft und nicht beschränkend ist, da andere Arten von Datenverarbeitungssystemen, die anders konfiguriert sind, ebenfalls verwendet werden können. Zum Beispiel kann eine Instanz der Speichersteuerung 1716 und des Plattformsteuerungshubs 1730 in einen diskreten externen Grafikprozessor, wie etwa dem externen Grafikprozessor 1718, integriert sein. In einer Ausführungsform können der Plattformsteuerungshub 1730 und/oder die Speichersteuerung 1716 extern zu dem einen oder den mehreren Prozessoren 1702 sein. Zum Beispiel kann das System 1700 eine externe Speichersteuerung 1716 und einen Plattformsteuerungshub 1730 beinhalten, die als ein Speichersteuerungshub und ein Peripheriesteuerungshub innerhalb eines Systemchipsatzes konfiguriert sein können, der mit dem einen oder den mehreren Prozessoren 1702 in Kommunikation steht.
Zum Beispiel können Leiterplatten („Schlitten“) verwendet werden, auf denen Komponenten, wie etwa CPUs, Speicher und andere Komponenten, platziert sind, die für eine erhöhte thermische Leistungsfähigkeit gestaltet sind. Bei manchen Beispielen befinden sich Verarbeitungskomponenten, wie etwa die Prozessoren, auf einer Oberseite eines Schlittens, während sich naher Speicher, wie etwa DIMMs, auf einer Unterseite des Schlittens befinden. Infolge des verbesserten Luftstroms, der durch diese Gestaltung bereitgestellt wird, können die Komponenten mit höheren Frequenzen und Leistungspegeln als in typischen Systemen arbeiten, wodurch die Leistungsfähigkeit erhöht wird. Des Weiteren sind die Schlitten dazu konfiguriert, blind mit Strom- und Datenkommunikationskabeln in einem Rack zusammenzupassen, wodurch ihre Fähigkeit verbessert wird, schnell entfernt, aufgerüstet, wieder installiert und/oder ersetzt zu werden. Gleichermaßen sind individuelle auf den Schlitten befindliche Komponenten wie Prozessoren, Beschleuniger, Speicher und Datenspeicherungslaufwerke so konfiguriert, dass sie sich dank ihrer größeren Beabstandung zueinander leicht aufrüsten lassen. In der veranschaulichenden Ausführungsform beinhalten die Komponenten zusätzlich Hardwareattestierungsmerkmale, um ihre Authentizität nachzuweisen.
Ein Datenzentrum kann eine einzelne Netzwerkarchitektur („Fabric“) nutzen, die mehrere andere Netzwerkarchitekturen unterstützt, darunter Ethernet und Omni-Path. Die Schlitten können über optische Fasern mit Schaltern gekoppelt sein, die eine höhere Bandbreite und eine niedrigere Latenz als eine typische Twisted-Pair-Verkabelung (z. B. Kategorie 5, Kategorie 5e, Kategorie 6 usw.) bereitstellen. Aufgrund der Interconnections mit hoher Bandbreiter und niedriger Latenz und der Netzwerkarchitektur kann das Datenzentrum im Gebrauch Ressourcen, wie etwa Speicher, Beschleuniger (z. B. GPUs, Grafikbeschleuniger, FPGAs, ASICs, Neuronalnetz- und/oder Künstliche-Intelligenz-Beschleuniger usw.) und Datenspeicherungslaufwerke, die physisch getrennt sind, zusammenschließen und sie Rechenressourcen (z. B. Prozessoren) nach Bedarf bereitstellen, wodurch ermöglicht wird, dass die Rechenressourcen auf die zusammengeschlossenen Ressourcen zugreifen, als wären sie lokal.
Eine Leistungsversorgung oder -quelle kann Spannung und/oder Strom an das System 1700 oder eine beliebige Komponente oder ein beliebiges System, die/das hierin beschrieben wird, liefern. In einem Beispiel beinhaltet die Leistungsversorgung einen AC/DC(Wechselstrom-zu-Gleichstrom)-Adapter zum Einstecken in eine Steckdose. Eine solche AC-Leistungsquelle kann eine Leistungsquelle mit erneuerbarer Energie (z. B. Solarenergie) sein. In einem Beispiel beinhaltet die Leistungsquelle eine DC-Leistungsquelle, wie etwa einen externen AC-DC-Wandler. In einem Beispiel beinhaltet eine Leistungsquelle oder eine Leistungsversorgung Drahtloseladehardware zum Laden über die Nähe zu einem Ladefeld. In einem Beispiel kann die Leistungsquelle eine interne Batterie, eine Wechselstromversorgung, eine bewegungsbasierte Leistungsversorgung, eine Solarenergieversorgung oder eine Brennstoffzellenquelle beinhalten.
18 ist ein Blockdiagramm einer Ausführungsform eines Prozessors 1800 mit einem oder mehreren Prozessorkernen 1802A-1802N, einer integrierten Speichersteuerung 1814 und einem integrierten Grafikprozessor 1808. Die Elemente von 18 mit den gleichen Bezugszeichen (oder Bezeichnungen) wie die Elemente einer beliebigen anderen Figur hierin können auf beliebige Weise ähnlich der an anderer Stelle hierin beschriebenen arbeiten oder funktionieren, sind aber nicht darauf beschränkt. Der Prozessor 1800 kann zusätzliche Kerne bis zu und einschließlich des zusätzlichen Kerns 1802N beinhalten, der durch die gestrichelten Kästchen dargestellt ist. Jeder der Prozessorkerne 1802A-1802N beinhaltet eine oder mehrere interne Cacheeinheiten 1804A-1804N. Bei manchen Ausführungsformen hat zudem jeder Prozessorkern Zugriff auf eine oder mehrere gemeinsam genutzte Cacheeinheiten 1806.
Die internen Cacheeinheiten 1804A-1804N und die gemeinsam genutzten Cacheeinheiten 1806 repräsentieren eine Cachespeicherhierarchie innerhalb des Prozessors 1800. Die Cachespeicherhierarchie kann mindestens eine Ebene („Level“) von Anweisungs- und Datencache innerhalb jedes Prozessorkerns und eine oder mehrere Ebenen von gemeinsam genutztem Mid-Level-Cache, wie etwa Level 2 (L2), Level 3 (L3), Level 4 (L4) oder andere Cacheebenen beinhalten, wobei die höchste Cacheebene vor dem externen Speicher als LLC klassifiziert wird. Bei manchen Ausführungsformen bewahrt eine Cachekohärenzlogik die Kohärenz zwischen den verschiedenen Cacheeinheiten 1806 und 1804A-1804N.
Bei manchen Ausführungsformen kann der Prozessor 1800 zudem einen Satz aus einer oder mehreren Bussteuerungseinheiten 1816 und einen Systemagentenkern 1810 aufweisen. Die eine oder die mehreren Bussteuerungseinheiten 1816 verwalten einen Satz von Peripheriebussen, wie etwa einen oder mehrere PCI- oder PCI-Express-Busse. Der Systemagentenkern 1810 stellt eine Verwaltungsfunktionalität für die verschiedenen Prozessorkomponenten bereit. Bei manchen Ausführungsformen beinhaltet der Systemagentenkern 1810 eine oder mehrere integrierte Speichersteuerungen 1814 zum Verwalten des Zugriffs auf verschiedene externe Speichervorrichtungen (nicht gezeigt).
Bei manchen Ausführungsformen beinhalten einer oder mehrere der Prozessorkerne 1802A-1802N eine Unterstützung für gleichzeitiges Multithreading. In einer solchen Ausführungsform beinhaltet der Systemagentenkern 1810 Komponenten zum Koordinieren und Betreiben der Kerne 1802A-1802N während der Multithreading-Verarbeitung. Der Systemagentenkern 1810 kann zusätzlich eine Leistungssteuereinheit (Power Control Unit, PCU) beinhalten, die Logik und Komponenten zum Regulieren des Leistungszustands der Prozessorkerne 1802A-1802N und des Grafikprozessors 1808 beinhaltet.
Bei manchen Ausführungsformen beinhaltet der Prozessor 1800 zusätzlich einen Grafikprozessor 1808 zum Ausführen von Grafikverarbeitungsoperationen. Bei manchen Ausführungsformen ist der Grafikprozessor 1808 mit dem Satz gemeinsam genutzter Cacheeinheiten 1806 und dem Systemagentenkern 1810 einschließlich der einen oder der mehreren integrierten Speichersteuerungen 1814 gekoppelt. Bei manchen Ausführungsformen beinhaltet der Systemagentenkern 1810 zudem eine Anzeigesteuerung 1811 zum Steuern der Ausgabe des Grafikprozessors an eine oder mehrere gekoppelte Anzeigen. Bei manchen Ausführungsformen kann es sich bei der Anzeigesteuerung 1811 auch um ein separates Modul handeln, das über mindestens einen Interconnect mit dem Grafikprozessor gekoppelt ist, oder sie kann in dem Grafikprozessor 1808 integriert sein.
Bei manchen Ausführungsformen wird eine ringbasierte Interconnect-Einheit 1812 verwendet, um die internen Komponenten des Prozessors 1800 zu koppeln. Es kann jedoch auch eine alternative Interconnect-Einheit verwendet werden, wie etwa ein Punkt-zu-Punkt-Interconnect, ein geschalteter Interconnect oder andere Techniken, einschließlich im Stand der Technik bekannter Techniken. Bei manchen Ausführungsformen ist der Grafikprozessor 1808 mit dem Ring-Interconnect 1812 über eine E/A-Verbindung 1813 gekoppelt.
Die beispielhafte E/A-Verbindung 1813 stellt mindestens eine von mehreren Varianten von E/A-Interconnects dar, darunter ein On-Package-E/A-Interconnect, der eine Kommunikation zwischen verschiedenen Prozessorkomponenten und einem eingebetteten Hochleistungsspeichermodul 1818 wie einem eDRAM-Modul erleichtert. Bei manchen Ausführungsformen können jeder der Prozessorkerne 1802A-1802N und der Grafikprozessor 1808 eingebettete Speichermodule 1818 als gemeinsam genutzten Last-Level-Cache verwenden.
Bei manchen Ausführungsformen handelt es sich bei den Prozessorkernen 1802A-1802N um homogene Kerne, die dieselbe Anweisungssatzarchitektur ausführen. In einer weiteren Ausführungsform sind die Prozessorkerne 1802A-1802N hinsichtlich der Anweisungssatzarchitektur (ISA: Instruction Set Architecture) heterogen, wobei einer oder mehrere der Prozessorkerne 1802A-1802N 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 1802A-1802N hinsichtlich der Mikroarchitektur heterogen, wobei ein oder mehrere Kerne mit einer relativ höheren Leistungsaufnahme mit einem oder mehreren Leistungskernen mit einer geringeren Leistungsaufnahme gekoppelt sind. In einer Ausführungsform sind die Prozessorkerne 1802A-1802N hinsichtlich der Rechenleistung heterogen. Außerdem kann der Prozessor 1800 auf einem oder mehreren Chips oder als eine integrierte SoC-Schaltung mit den veranschaulichten Komponenten zusätzlich zu anderen Komponenten implementiert sein.
19 ist ein Blockdiagramm eines Grafikprozessors 1900, der eine diskrete Grafikverarbeitungseinheit sein kann oder ein Grafikprozessor sein kann, der mit mehreren Verarbeitungskernen integriert ist, oder anderen Halbleitervorrichtungen, wie etwa unter anderem Speichervorrichtungen oder Netzwerkschnittstellen. Bei manchen Ausführungsformen kommuniziert der Grafikprozessor über eine speicherabgebildete E/A-Schnittstelle mit Registern auf dem Grafikprozessor und mit in den Prozessorspeicher platzierten Befehlen. Bei manchen Ausführungsformen beinhaltet der Grafikprozessor 1900 eine Speicherschnittstelle 1914, um auf Speicher zuzugreifen. Die Speicherschnittstelle 1914 kann eine Schnittstelle zu einem lokalem Speicher, einem oder mehreren internen Caches, einem oder mehreren gemeinsam genutzten externen Caches und/oder einem Systemspeicher sein.
Bei manchen Ausführungsformen beinhaltet der Grafikprozessor 1900 zudem eine Anzeigesteuerung 1902, um Anzeigeausgabedaten zu einer Anzeigevorrichtung 1918 zu steuern. Die Anzeigesteuerung 1902 beinhaltet Hardware für eine oder mehrere Überlagerungsebenen für die Anzeige und Zusammensetzung mehrerer Schichten von Video- oder Benutzeroberflächenelementen. Die Anzeigevorrichtung 1918 kann eine interne oder eine externe Anzeigevorrichtung sein. In einer Ausführungsform ist die Anzeigevorrichtung 1918 eine am Kopf befestigte Anzeigevorrichtung, wie etwa eine Virtual-Reality(VR)-Anzeigevorrichtung oder eine Augmented-Reality(AR)-Anzeigevorrichtung. Bei manchen Ausführungsformen beinhaltet der Grafikprozessor 1900 eine Video-Codec-Engine 1906 zum Codieren, Decodieren oder Transcodieren von Medien zu, von oder zwischen einem oder mehreren Mediencodierformaten, darunter unter anderem MPEG-Formate (MPEG: Moving Picture Experts Group) wie MPEG-2, AVC-Formate (AVC: Advanced Video Coding) wie H.264/MPEG-4 AVC, H.265/HEVC, Alliance for Open Media (AOMedia) VP8, VP9 sowie die SMPTE-421M/VC-1- (SMPTE: Society of Motion Picture & Television Engineers) und JPEG-(JPEG: Joint Photographic Experts Group) Formate wie JPEG- und Motion-JPEG(MJPEG)-Formate.
Bei manchen Ausführungsformen beinhaltet der Grafikprozessor 1900 eine Blockbildtransfer(BLIT)-Engine 1904, um zweidimensionale (2D-) Rasterisiereroperationen durchzuführen, einschließlich zum Beispiel Bitgrenzblocktransfers. In einer Ausführungsform werden jedoch 2D-Grafikoperationen unter Verwendung einer oder mehrerer Komponenten der Grafikverarbeitungs-Engine (GPE) 1910 durchgeführt. Bei manchen Ausführungsformen ist die GPE 1910 eine Rechen-Engine zum Durchführen von Grafikoperationen, einschließlich dreidimensionaler (3D-) Grafikoperationen und Medienoperationen.
Bei manchen Ausführungsformen beinhaltet die GPE 1910 eine 3D-Pipeline 1912 zum Durchführen von 3D-Operationen, wie etwa Rendering von dreidimensionalen Bildern und Szenen unter Verwendung von Verarbeitungsfunktionen, die auf 3D-Primitivformen (z. B. Rechteck, Dreieck usw.) wirken. Die 3D-Pipeline 1912 beinhaltet programmierbare und Festfunktionselemente, die verschiedene Aufgaben innerhalb des Elements durchführen und/oder Ausführungs-Threads zu einem 3D/Medien-Subsystem 1915 spawnen. Während die 3D-Pipeline 1912 zum Durchführen von Medienoperationen verwendet werden kann, beinhaltet eine Ausführungsform der GPE 1910 auch eine Medien-Pipeline 1916, die speziell zum Durchführen von Medienoperationen, wie etwa Videonachbearbeitung und Bildverbesserung, verwendet wird.
Bei manchen Ausführungsformen beinhaltet die Medien-Pipeline 1916 Festfunktions- oder programmierbare Logikeinheiten, um eine oder mehrere spezialisierte Medienoperationen, wie etwa Videodecodierungsbeschleunigung, Videoentschachtelung und Videocodierungsbeschleunigung, anstelle von oder im Auftrag der Video-Codec-Engine 1906 durchzuführen. Bei manchen Ausführungsformen beinhaltet die Medien-Pipeline 1916 außerdem eine Thread-Spawning-Einheit, um Threads zur Ausführung auf dem 3D/Medien-Subsystem 1915 zu spawnen. Die gespawnten Threads führen Berechnungen für die Medienoperationen auf einer oder mehreren Grafikausführungseinheiten durch, die in dem 3D/Medien-Subsystem 1915 enthalten sind.
Bei manchen Ausführungsformen weist das 3D/Medien-Subsystem 1915 eine Logik zum Ausführen von durch die 3D-Pipeline 1912 und die Medienpipeline 1916 gespawnten Threads auf. In einer Ausführungsform senden die Pipelines Thread-Ausführungsanforderungen an das 3D/Medien-Subsystem 1915, das eine Thread-Dispatch-Logik für die Vermittlung und Verteilung der verschiedenen Anforderungen an verfügbare Thread-Ausführungsressourcen beinhaltet. Die Ausführungsressourcen beinhalten ein Array von Grafikausführungseinheiten zum Verarbeiten der 3D- und Medien-Threads. Bei manchen Ausführungsformen weist das 3D/Medien-Subsystem 1915 einen oder mehrere interne Caches für Thread-Anweisungen und Daten auf. Bei manchen Ausführungsformen beinhaltet das Subsystem zudem gemeinsam genutzten Speicher, einschließlich Registern und adressierbarem Speicher, um Daten zwischen Threads gemeinsam zu nutzen und Ausgabedaten zu speichern.
Grafikverarbeitungs-Engine
20 ist ein Blockdiagramm einer Grafikverarbeitungs-Engine 2010 eines Grafikprozessors gemäß manchen Ausführungsformen. In einer Ausführungsform ist die Grafikverarbeitungsmaschine (GPE) 2010 eine Version der in 19 gezeigten GPE 1910. Elemente von 20 mit den gleichen Bezugszeichen (oder Namen) wie die Elemente jeder anderen Figur hierin können auf eine ähnliche Weise wie an anderer Stelle hierin beschrieben arbeiten oder funktionieren, sind aber nicht darauf beschränkt. Zum Beispiel sind die 3D-Pipeline 1912 und die Medien-Pipeline 1916 19 veranschaulicht. Die Medienpipeline 1916 ist bei manchen Ausführungsformen der GPE 2010 optional und ist möglicherweise nicht explizit in der GPE 2010 enthalten. Beispielsweise und in mindestens einer Ausführungsform ist ein separater Medien- und/oder Bildprozessor mit der GPE 2010 gekoppelt.
Bei manchen Ausführungsformen ist die GPE 2010 mit einem Befehlsstreamer 2003 gekoppelt oder beinhaltet diesen, der der 3D-Pipeline 1912 und/oder den Medien-Pipelines 1916 einen Befehlsstrom bereitstellt. Bei manchen Ausführungsformen ist der Befehls-Streamer 2003 mit einem Speicher, der ein Systemspeicher sein kann, oder einem internen Cachespeicher und/oder einem gemeinsam genutzten Cachespeicher gekoppelt. Bei manchen Ausführungsformen empfängt der Befehls-Streamer 2003 Befehle von dem Speicher und sendet die Befehle an die 3D-Pipeline 1912 und/oder die Medien-Pipeline 1916. Bei den Befehlen handelt es sich um Direktiven, die aus einem Ringpuffer abgerufen werden, der Befehle für die 3D-Pipeline 1912 und die Medien-Pipeline 1916 speichert. In einer Ausführungsform kann der Ringpuffer zusätzlich Batch-Befehlspuffer aufweisen, die Batches aus mehreren Befehlen speichern. Die Befehle für die 3D-Pipeline 1912 können auch Verweise auf Daten beinhalten, die im Speicher gespeichert sind, wie etwa unter anderem Vertex- und Geometriedaten für die 3D-Pipeline 1912 und/oder Bilddaten und Speicherobjekte für die Medien-Pipeline 1916. Die 3D-Pipeline 1912 und die Medien-Pipeline 1916 verarbeiten die Befehle und Daten, indem sie Operationen über eine Logik innerhalb der jeweiligen Pipelines durchführen oder indem sie einen oder mehrere Ausführungs-Threads an ein Grafikkern-Array 2014 versenden. In einer Ausführungsform beinhaltet das Grafikkern-Array 2014 einen oder mehrere Blöcke aus Grafikkernen (z. B. Grafikkern(e) 2015A, Grafikkern(e) 2015B), wobei jeder Block einen oder mehrere Grafikkerne beinhaltet. Jeder Grafikkern beinhaltet einen Satz von Grafikausführungsressourcen, der eine Mehrzweck- und grafikspezifische Ausführungslogik zum Durchführen von Grafik- und Rechenoperationen sowie Festfunktionstexturverarbeitung und/oder Maschinenlernen und eine Künstliche-Intelligenz-Beschleunigungslogik beinhaltet.
In verschiedenen Ausführungsformen kann die 3D-Pipeline 1912 Festfunktions- und programmierbare Logik beinhalten, um ein oder mehrere Shader-Programme, wie etwa Vertex-Shader, Geometrie-Shader, Pixel-Shader, Fragment-Shader, Rechen-Shader oder andere Shader-Programme zu verarbeiten, indem die Anweisungen verarbeitet und Ausführungs-Threads an das Grafikkern-Array 2014 versendet werden. Das Grafikkern-Array 2014 stellt einen vereinheitlichten Block von Ausführungsressourcen zur Verwendung bei der Verarbeitung dieser Shader-Programme bereit. Eine Mehrzweckausführungslogik (z. B. Ausführungseinheiten) innerhalb des/der mehreren Grafikkern(e) 2015A-2014B des Grafikkern-Arrays 2014 unterstützt verschiedene 3D-API-Shader-Sprachen und kann mehrere gleichzeitige Ausführungs-Threads ausführen, die mit mehreren Shadern assoziiert sind.
Bei manchen Ausführungsformen beinhaltet das Grafikkern-Array 2014 eine Ausführungslogik zum Durchführen von Medienfunktionen, wie etwa Video- und/oder Bildverarbeitung. In einer Ausführungsform beinhalten die Ausführungseinheiten eine Mehrzwecklogik, die dazu programmierbar ist, parallele Mehrzweckrechenoperationen durchzuführen, zusätzlich zu Grafikverarbeitungsoperationen. Die Mehrzwecklogik kann Verarbeitungsoperationen parallel oder in Verbindung mit der Mehrzwecklogik innerhalb des/der Prozessorkern(e) 1707 von 17 oder des Kerns 1802A-1802N wie in 18 durchführen.
Ausgabedaten, die durch Threads erzeugt werden, die auf dem Grafikkern-Array 2014 ausgeführt werden, können Daten an einen Speicher in einem vereinheitlichten Rückgabepuffer (URB) 2018 ausgeben. Der URB 2018 kann Daten für mehrere Threads speichern. Bei manchen Ausführungsformen kann der URB 2018 verwendet werden, um Daten zwischen verschiedenen Threads zu senden, die auf dem Grafikkern-Array 2014 ausgeführt werden. Bei manchen Ausführungsformen kann der URB 2018 zusätzlich zur Synchronisation zwischen Threads auf dem Grafikkern-Array und einer Festfunktionslogik innerhalb der Logik 2020 mit gemeinsam genutzter Funktion verwendet werden.
Bei manchen Ausführungsformen ist das Grafikkern-Array 2014 skalierbar, sodass das Array eine variable Anzahl von Grafikkernen mit jeweils einer variablen Anzahl an Ausführungseinheiten, die auf der Zielleistung und der Leistungsverhaltensstufe der GPE 2010 basiert, beinhaltet. In einer Ausführungsform sind die Ausführungsressourcen dynamisch skalierbar, sodass Ausführungsressourcen je nach Bedarf aktiviert oder deaktiviert werden können.
Das Grafikkern-Array 2014 ist mit Logik 2020 mit gemeinsam genutzter Funktion gekoppelt, die mehrere Ressourcen beinhaltet, die unter den Grafikkernen in dem Grafikkern-Array gemeinsam genutzt werden. Die gemeinsam genutzten Funktionen innerhalb der Logik 2020 mit gemeinsam genutzter Funktion sind Hardware-Logikeinheiten, die dem Grafikkern-Array 2014 eine spezialisierte Zusatzfunktionalität bereitstellen. In verschiedenen Ausführungsformen beinhaltet die Logik 2020 mit gemeinsam genutzter Funktion, ohne darauf beschränkt zu sein, eine Sampler- 2021, eine Mathe- 2022 und eine Inter-Thread-Kommunikations- (ITC: Inter-Thread Communication) 2023 Logik. Zusätzlich implementieren manche Ausführungsformen einen oder mehrere Cache(s) 2025 innerhalb der Logik 2020 mit gemeinsam genutzter Funktion.
Eine gemeinsam genutzte Funktion wird zumindest in dem Fall implementiert, in dem die Nachfrage nach einer gegebenen spezialisierten Funktion nicht ausreicht, um sie in das Grafikkern-Array 2014 aufzunehmen. Stattdessen wird eine einzelne Instanziierung dieser spezialisierten Funktion als eine eigenständige Entität in der Logik 2020 mit gemeinsam genutzter Funktion implementiert und unter den Ausführungsressourcen innerhalb des Grafikkern-Arrays 2014 gemeinsam genutzt. Der genaue Satz von Funktionen, die von dem Grafikkern-Array 2014 gemeinsam genutzt werden und in dem Grafikkern-Array 2014 enthalten sind, variiert zwischen Ausführungsformen. Bei manchen Ausführungsformen können bestimmte gemeinsam genutzte Funktionen innerhalb der Logik 2020 mit gemeinsam genutzter Funktion, die durch das Grafikkern-Array 2014 intensiv genutzt werden, in der Logik 2016 mit gemeinsam genutzter Funktion innerhalb des Grafikkern-Arrays 2014 enthalten sein. In verschiedenen Ausführungsformen kann die Logik 2016 mit gemeinsam genutzter Funktion innerhalb des Grafikkern-Arrays 2014 einen Teil der oder die gesamte Logik innerhalb der Logik 2020 mit gemeinsam genutzter Funktion beinhalten. In einer Ausführungsform können alle Logikelemente innerhalb der Logik 2020 mit gemeinsam genutzter Funktion innerhalb der Logik 2016 mit gemeinsam genutzter Funktion des Grafikkern-Arrays 2014 dupliziert werden. In einer Ausführungsform wird die Logik 2020 mit gemeinsam genutzter Funktion zugunsten der Logik 2016 mit gemeinsam genutzter Funktion innerhalb des Grafikkern-Arrays 2014 ausgeschlossen.
21 ist ein Blockdiagramm einer Hardwarelogik eines Grafikprozessorkerns 2100 gemäß manchen hierin beschriebenen Ausführungsformen. Elemente von 21 mit den gleichen Bezugszeichen (oder Namen) wie die Elemente jeder anderen Figur hierin können auf eine ähnliche Weise wie an anderer Stelle hierin beschrieben arbeiten oder funktionieren, sind aber nicht darauf beschränkt. Der veranschaulichte Grafikprozessorkern 2100 ist bei manchen Ausführungsformen innerhalb des Grafikkern-Arrays 2014 von 20 enthalten. Der Grafikprozessorkern 2100, der mitunter als Kern-Slice bezeichnet wird, kann ein oder mehrere Grafikkerne innerhalb eines modularen Grafikprozessors sein. Der Grafikprozessorkern 2100 ist beispielhaft für ein Grafikkern-Slice, und ein Grafikprozessor, wie hierin beschrieben, kann mehrere Grafikkern-Slices auf der Grundlage von Zielleistungs- und Leistungsverhaltenshüllkurven beinhalten. Jeder Grafikprozessorkern 2100 kann einen Festfunktionsblock 2130 beinhalten, der mit mehreren Unterkernen 2101A-2101F, auch als Unter-Slices bezeichnet, die modulare Blöcke von Mehrzweck- und Festfunktionslogik beinhalten, gekoppelt ist.
Bei manchen Ausführungsformen beinhaltet der Festfunktionsblock 2130 eine Geometrie/Festfunktions-Pipeline 2136, die durch alle Unterkerne in dem Grafikprozessorkern 2100 gemeinsam genutzt werden kann, zum Beispiel bei Grafikprozessorimplementierungen mit geringerer Leistungsfähigkeit und/oder geringerer Leistung. In verschiedenen Ausführungsformen umfasst die Geometrie-/Festfunktions-Pipeline 2136 eine 3D-Festfunktions-Pipeline (z. B. 3D-Pipeline 1912 wie in 19 und 20), eine Video-Frontend-Einheit, einen Thread-Spawner und Thread-Dispatcher und einen Vereinheitlichter-Rückgabepuffer-Manager, der vereinheitlichte Rückgabepuffer verwaltet, wie etwa den vereinheitlichten Rückgabepuffer 2018 von 20.
In einer Ausführungsform beinhaltet der Festfunktionsblock 2130 auch eine Grafik-SoC-Schnittstelle 2137, einen Grafik-Mikrocontroller 2138 und eine Medien-Pipeline 2139. Die Grafik-SoC-Schnittstelle 2137 stellt eine Schnittstelle zwischen dem Grafikprozessorkern 2100 und anderen Prozessorkernen innerhalb einer integrierten System-auf-Chip-Schaltung bereit. Der Grafik-Mikrocontroller 2138 ist ein programmierbarer Subprozessor, der dazu konfigurierbar ist, verschiedene Funktionen des Grafikprozessorkerns 2100 zu verwalten, einschließlich Threadversand, Scheduling und Präemption. Die Medien-Pipeline 2139 (z. B. die Medien-Pipeline 1916 von 19 und 20) beinhaltet eine Logik, um das Decodieren, Codieren, Vorverarbeiten und/oder Nachverarbeiten von Multimediadaten, einschließlich Bild- und Videodaten, zu erleichtern. Die Medien-Pipeline 2139 implementiert Medienoperationen über Anforderungen an Berechnungs- oder Abtastlogik innerhalb der Unterkerne 2101-2101F.
In einer Ausführungsform ermöglicht die SoC-Schnittstelle 2137 dem Grafikprozessorkern 2100 die Kommunikation mit Prozessorkernen für Mehrzweckanwendungen (z. B. CPUs) und/oder anderen Komponenten innerhalb eines SoC, darunter Speicherhierarchieelemente wie etwa ein gemeinsam genutzter Last-Level-Cachespeicher, der System-RAM und/oder eingebetteter On-Chip- oder On-Package-DRAM Die SoC-Schnittstelle 2137 kann auch die Kommunikation mit Festfunktionseinrichtungen innerhalb des SoC ermöglichen, wie etwa Kamerabildgebungs-Pipelines, und ermöglicht die Verwendung von und/oder implementiert globale Speicher-Atome, die zwischen dem Grafikprozessorkern 2100 und CPUs innerhalb des SoC gemeinsam genutzt werden können. Die SoC-Schnittstelle 2137 kann zudem Energieverwaltungssteuerungen für den Grafikprozessorkern 2100 implementieren und eine Schnittstelle zwischen einem Taktbereich des Grafikkerns 2100 und anderen Taktbereichen innerhalb des SoC ermöglichen. In einer Ausführungsform ermöglicht die SoC-Schnittstelle 2137 den Empfang von Befehlspuffern von einem Befehls-Streamer und globalen Thread-Dispatcher, die dafür konfiguriert sind, Befehle und Anweisungen an jeden von einem oder mehreren Grafikkernen innerhalb eines Grafikprozessors bereitzustellen. Die Befehle und Anweisungen können an die Medien-Pipeline 2139 geschickt werden, wenn Medienoperationen durchgeführt werden sollen, oder an eine Geometrie- und Festfunktions-Pipeline (z. B. Geometrie- und Festfunktions-Pipeline 2136, Geometrie- und Festfunktions-Pipeline 2114), wenn Grafikverarbeitungsoperationen durchgeführt werden sollen.
Der Grafik-Mikrocontroller 2138 kann dafür konfiguriert sein, verschiedene Scheduling- und Verwaltungsaufgaben für den Grafikprozessorkern 2100 durchzuführen. In einer Ausführungsform kann der Grafik-Mikrocontroller 2138 Grafik- und/oder Rechenlast-Scheduling auf den verschiedenen parallelen Grafik-Engines innerhalb der Arrays 2102A-2102F, 2104A-2104F der Ausführungseinheiten (EU) innerhalb der Unterkerne 2101A-2101F durchführen. In diesem Scheduling-Modell kann Host-Software, die auf einem CPU-Kern eines den Grafikprozessorkern 2100 beinhaltenden SoC ausgeführt wird, Arbeitslasten einer von mehreren Grafikprozessor-Doorbells liefern, was eine Scheduling-Operation auf der entsprechenden Grafik-Engine aktiviert. Zu Scheduling-Operation zählen Bestimmen, welche Arbeitslast als nächstes ausgeführt werden soll, Liefern einer Arbeitslast an einen Befehls-Streamer, Zurückstellen bestehender Arbeitslasten, die auf einer Engine ausgeführt werden, Überwachen des Fortschritts einer Arbeitslast und Benachrichtigen einer Host-Software, wenn eine Arbeitslast abgeschlossen ist. In einer Ausführungsform kann der Grafik-Mikrocontroller 2138 auch Niederleistungs- oder Leerlaufzustände für den Grafikprozessorkern 2100 ermöglichen, indem er dem Grafikprozessorkern 2100 die Möglichkeit gibt, Register innerhalb des Grafikprozessorkerns 2100 über Niederleistungszustandsübergänge hinweg unabhängig von dem Betriebssystem und/oder der Grafiktreibersoftware auf dem System zu speichern und wiederherzustellen.
Der Grafikprozessorkern 2100 kann mehr als oder weniger als die veranschaulichten Unterkerne 2101A-2101F aufweisen, bis zu N modulare Unterkerne. Für jeden Satz aus N Unterkernen kann der Grafikprozessorkern 2100 auch eine Logik 2110 mit gemeinsam genutzter Funktion, einen gemeinsam genutzten und/oder Cachespeicher 2112, eine Geometrie-/Festfunktions-Pipeline 2114 sowie eine zusätzliche Festfunktionslogik 2116 zur Beschleunigung verschiedener Grafik- und Rechenverarbeitungsoperationen beinhalten. Die Logik 2110 mit gemeinsam genutzter Funktion kann Logikeinheiten beinhalten, die mit der Logik 2020 mit gemeinsam genutzter Funktion von 20 assoziiert sind (z. B. Sampler-, Mathe- und/oder Inter-Thread-Kommunikationslogik), die durch jeden der N Unterkerne innerhalb des Grafikprozessorkerns 2100 gemeinsam genutzt werden können. Der gemeinsam genutzte und/oder Cachespeicher 2112 kann ein Last-Level-Cache für den Satz von N Unterkernen 2101A-2101F innerhalb des Grafikprozessorkerns 2100 sein und kann auch als gemeinsam genutzter Speicher dienen, auf den mehrere Unterkerne zugreifen können. Die Geometrie-/Festfunktions-Pipeline 2114 kann anstelle der Geometrie-/Festfunktions-Pipeline 2136 innerhalb des Festfunktionsblocks 2130 enthalten sein und dieselben oder ähnliche Logikeinheiten aufweisen.
In einer Ausführungsform beinhaltet der Grafikprozessorkern 2100 zusätzliche Festfunktionslogik 2116, die verschiedene Festfunktionsbeschleunigungslogik zur Verwendung durch den Grafikprozessorkern 2100 beinhalten kann. In einer Ausführungsform weist die zusätzliche Festfunktionslogik 2116 eine zusätzliche Geometrie-Pipeline zur Verwendung beim Nur-Positions-Shading auf. Beim Nur-Positions-Shading existieren zwei Geometrie-Pipelines, die vollständige Geometrie-Pipeline innerhalb der Geometrie-/Festfunktions-Pipeline 2116, 2136 und eine Cull-Pipeline, die eine zusätzliche Geometrie-Pipeline ist, die in der zusätzlichen Festfunktionslogik 2116 enthalten sein kann. In einer Ausführungsform ist die Cull-Pipeline eine abgespeckte Version der vollständigen Geometrie-Pipeline. Die vollständige Pipeline und die Cull-Pipeline können verschiedene Instanzen derselben Anwendung ausführen, wobei jede Instanz einen separaten Kontext aufweist. Das Nur-Positions-Shading kann lange Cull-Durchläufe von verworfenen Dreiecken verbergen, wodurch das Shading in manchen Fällen früher abgeschlossen werden kann. Zum Beispiel und in einer Ausführungsform kann die Cull-Pipeline-Logik innerhalb der zusätzlichen Festfunktionslogik 2116 Positions-Shader parallel zur Hauptanwendung ausführen und erzeugt im Allgemeinen kritische Ergebnisse schneller als die vollständige Pipeline, da die Cull-Pipeline nur das Positionsattribut der Vertices abruft und an diesen Shading durchführt, ohne Rasterung und Rendering der Pixel zum Framepuffer durchzuführen. Die Cull-Pipeline kann die erzeugten kritischen Ergebnisse verwenden, um Sichtbarkeitsinformationen für alle Dreiecke zu berechnen, ohne Rücksicht darauf, ob diese Dreiecke aussortiert werden. Die vollständige Pipeline (die in diesem Fall als Wiedergabe-Pipeline bezeichnet werden kann) kann die Sichtbarkeitsinformationen verbrauchen, um die aussortierten Dreiecke zu überspringen, um nur an den sichtbaren Dreiecken Shading durchzuführen, die schließlich an die Rasterungsphase übergeben werden.
Bei einer Ausführungsform kann die zusätzliche Festfunktionslogik 2116 auch eine Maschinenlernbeschleunigungslogik, wie etwa eine Festfünktionsmatrixmultiplikationslogik, für Implementierungen einschließlich Optimierungen für Maschinenlerntraining oder Inferenzfindung beinhalten.
Innerhalb jedes Grafikunterkerns 2101A-2101F ist ein Satz von Ausführungsressourcen enthalten, die verwendet werden können, um Grafik-, Medien- und Rechenoperationen als Reaktion auf Anforderungen durch eine Grafik-Pipeline, Medien-Pipeline oder Shader-Programme durchzuführen. Die Grafikunterkerne 2101A-2101F beinhalten mehrere EU-Arrays 2102A-2102F, 2104A-2104F, Thread-Dispatch- und Inter-Thread-Kommunikations(TD/IC)-Logik 2103A-2103F, einen 3D-Sampler (z. B. Textur-Sampler) 2105A-2105F, einen Medien-Sampler 2106A-2106F, einen Shader-Prozessor 2107A-2107F und einen gemeinsam genutzten lokalen Speicher (SLM: Shared Local Memory) 2108A-2108F. Die EU-Arrays 2102A-2102F, 2104A-2104F beinhalten jeweils mehrere Ausführungseinheiten, die Mehrzweckgrafikverarbeitungseinheiten sind, die Gleitkomma- und Ganzzahl-/Festkommalogikoperationen im Dienst einer Grafik-, Medien- oder Rechenoperation durchführen können, einschließlich Grafik-, Medien- oder Rechen-Shader-Programmen. Die TD/IC-Logik 2103A-2103F führt lokale Thread-Dispatch- und Thread-Steueroperationen für die Ausführungseinheiten innerhalb eines Unterkerns aus und ermöglicht die Kommunikation zwischen Threads, die auf den Ausführungseinheiten des Unterkerns ausgeführt werden. Der 3D-Sampler 2105A-2105F kann Textur- oder andere 3D-Grafik-bezogene Daten in den Speicher lesen. Der 3D-Sampler kann Texturdaten basierend auf einem konfigurierten Sample-Status und dem Texturformat, das mit einer gegebenen Textur assoziiert ist, unterschiedlich lesen. Der Medien-Sampler 2106A-2106F kann ähnliche Leseoperationen basierend auf der Art und dem Format durchführen, die mit den Mediendaten assoziiert sind. In einer Ausführungsform kann jeder Grafikunterkern 2101A-2101F abwechselnd einen einheitlichen 3D- und Medien-Sampler beinhalten. Threads, die auf den Ausführungseinheiten in jedem der Teilkerne 2101A-2101F ausgeführt werden, können den gemeinsam genutzten lokalen Speicher 2108A-2108F in jedem Unterkern verwenden, um Threads, die innerhalb einer Thread-Gruppe ausgeführt werden, zu ermöglichen, einen gemeinsam genutzten On-Chip-Speicher-Pool zu verwenden.
Ausführungseinheiten
22A-22B veranschaulichen Thread-Ausführungslogik 2200 einschließlich eines Arrays von Verarbeitungselementen, die in einem Grafikprozessorkern eingesetzt werden, gemäß hierin beschriebenen Ausführungsformen. Elemente von 22A-22B mit den gleichen Bezugszeichen (oder Bezeichnungen) wie die Elemente einer beliebigen anderen Figur hierin können auf beliebige Weise ähnlich der an anderer Stelle hierin beschriebenen arbeiten oder funktionieren, sind aber nicht darauf beschränkt. 22A veranschaulicht eine Übersicht über die Thread-Ausführungslogik 2200, die eine Variante der Hardwarelogik beinhalten kann, die mit jedem Unterkern 2101A-2101F von 21 veranschaulicht ist. 22B veranschaulicht beispielhafte interne Details einer Ausführungseinheit.
Wie in 22A veranschaulicht, beinhaltet die Thread-Ausführungslogik 2200 bei manchen Ausführungsformen einen Shader-Prozessor 2202, einen Thread-Dispatcher 2204, einen Anweisungscache 2206, ein skalierbares Ausführungseinheit-Array einschließlich mehrerer Ausführungseinheiten 2208A-2208N, einen Sampler 2210, einen Datencache 2212 und einen Datenport 2214. In einer Ausführungsform kann das skalierbare Ausführungseinheitenarray dynamisch skalieren, indem eine oder mehrere Ausführungseinheiten (e.g., eine beliebige der Ausführungseinheiten 2208A, 2208B, 2208C, 2208D bis 2208N-1 und 2208N) basierend auf den Rechenanforderungen einer Arbeitslast aktiviert oder deaktiviert werden. Bei einer Ausführungsform sind die enthaltenen Komponenten über ein Interconnect-Fabric, das mit jeder der Komponenten verknüpft ist, miteinander verbunden. Bei manchen Ausführungsformen beinhaltet die Thread-Ausführungslogik 2200 eine oder mehrere Verbindungen zum Speicher, wie etwa zum Systemspeicher oder Cachespeicher, über den Anweisungscache 2206 und/oder den Datenport 2214 und/oder den Sampler 2210 und/oder die Ausführungseinheiten 2208A-2208N. Bei manchen Ausführungsformen ist jede Ausführungseinheit (z. B. 2208A) eine selbständige programmierbare Mehrzweckrecheneinheit, die dazu in der Lage ist, mehrere gleichzeitige Hardware-Threads auszuführen, während sie mehrere Datenelemente parallel für jeden Thread verarbeitet. In verschiedenen Ausführungsformen kann das Array aus Ausführungseinheiten 2208A-2208N skalierbar sein, sodass es eine beliebige Anzahl einzelner Ausführungseinheiten enthält.
Bei manchen Ausführungsformen werden die Ausführungseinheiten 2208A-2208N hauptsächlich zum Ausführen von Shader-Programmen verwendet. Ein Shader-Prozessor 2202 kann die verschiedenen Shader-Programme verarbeiten und Ausführungs-Threads, die mit den Shader-Programmen assoziiert sind, über einen Thread-Dispatcher 2204 versenden. In einer Ausführungsform beinhaltet der Thread-Dispatcher Logik, um Thread-Initiierungsanforderungen von den Grafik- und Medien-Pipelines zu vermitteln und die angeforderten Threads auf einer oder mehreren Ausführungseinheiten in den Ausführungseinheiten 2208A-2208N zu instanziieren. Zum Beispiel kann eine Geometrie-Pipeline Vertex-, Tessellations- oder Geometrie-Shader an die Thread-Ausführungslogik versenden. In manchen Ausführungsformen kann der Thread-Dispatcher 2204 auch Laufzeit-Thread-Spawning-Anforderungen von den ausführenden Shader-Programmen verarbeiten.
Bei manchen Ausführungsformen unterstützen die Ausführungseinheiten 2208A-2208N einen Anweisungssatz, der native Unterstützung für viele Standard-3D-Grafik-Shader-Anweisungen beinhaltet, sodass Shader-Programme aus Grafikbibliotheken (z. B. Direct 3D und OpenGL) mit einer minimalen Übersetzung ausgeführt werden. Die Ausführungseinheiten unterstützen Vertex- und Geometrieverarbeitung (z. B. Vertex-Programme, Geometrieprogramme, Vertex-Shader), Pixelverarbeitung (z. B. Pixel-Shader, Fragment-Shader) und Mehrzweckverarbeitung (z. B. Rechen- und Medien-Shader). Jede der Ausführungseinheiten 2208A-2208N ist zu einer Mehrfach-Erteilungs-SIMD-Ausführung (SIMD: Single Instruction Multiple Data) fähig und eine Multithread-Operation ermöglicht eine effiziente Ausführungsumgebung angesichts von Speicherzugriffen mit höherer Latenz. Jeder Hardware-Thread innerhalb jeder Ausführungseinheit weist eine dedizierte Registerbank mit hoher Bandbreite und einen assoziierten unabhängigen Thread-Zustand auf. Die Ausführung ist eine Mehrfach-Erteilung pro Takt an Pipelines mit Gleitkomma-Operationen mit ganzzahliger, einfacher und doppelter Präzision, SIMD-Verzweigungskapazität, logischen Operationen, transzendenten Operationen und anderen sonstigen Operationen. Während auf Daten aus dem Speicher oder einer der gemeinsam genutzten Funktionen gewartet wird, bewirkt die Abhängigkeitslogik innerhalb der Ausführungseinheiten 2208A-2208N, dass ein wartender Thread in den Ruhezustand geht, bis die angeforderten Daten zurückgegeben worden sind. Während der wartende Thread im Ruhezustand ist, können sich Hardwareressourcen der Verarbeitung anderer Threads widmen. Zum Beispiel kann während einer Verzögerung, die mit einer Vertex-Shader-Operation assoziiert ist, eine Ausführungseinheit Operationen für einen Pixel-Shader, Fragment-Shader oder eine andere Art von Shader-Programm durchführen, einschließlich eines anderen Vertex-Shaders. Verschiedene Ausführungsformen können für die Verwendung einer Ausführung unter Verwendung von Single Instruction Multiple Thread (SIMT) als Alternative zur Verwendung von SIMD oder zusätzlich zur Verwendung von SIMD gelten. Eine Bezugnahme auf einen SIMD-Kern oder eine SIMD-Operation kann auch für SIMT gelten oder für SIMD in Kombination mit SIMT gelten.
Jede Ausführungseinheit in den Ausführungseinheiten 2208A-2208N arbeitet an Arrays von Datenelementen. Die Anzahl der Datenelemente ist die „Ausführungsgröße“ oder die Anzahl der Kanäle für die Anweisung. Ein Ausführungskanal ist eine logische Ausführungseinheit für einen Datenelementzugriff, eine Maskierung und eine Ablaufsteuerung innerhalb von Anweisungen. Die Anzahl der Kanäle kann unabhängig von der Anzahl physischer arithmetischer Logikeinheiten (ALUs) oder Gleitkommaeinheiten (FPUs) für einen speziellen Grafikprozessor sein. Bei manchen Ausführungsformen unterstützen die Ausführungseinheiten 2208A-2208N Ganzzahl- und Gleitkomma-Datentypen.
Der Ausführungseinheit-Anweisungssatz beinhaltet SIMD-Anweisungen. Die verschiedenen Datenelemente können als ein gepackter Datentyp in einem Register gespeichert werden und die Ausführungseinheit wird die verschiedenen Elemente basierend auf der Datengröße der Elemente verarbeiten. Wenn zum Beispiel mit einem 256 Bit breiten Vektor gearbeitet wird, werden die 256 Bit des Vektors in einem Register gespeichert, wobei die Ausführungseinheit am Vektor als vier separate gepackte 64-Bit-Datenelemente (Datenelemente in Vierfachwort(QW)-Größe), acht separate gepackte 32-Bit-Datenelemente (Datenelemente in Doppelwort(DW)-Größe), sechzehn separate gepackte 16-Bit-Datenelemente (Datenelemente in Wort(W)-Größe oder zweiunddreißig separate gepackte 8-Bit-Datenelemente (Datenelemente in Byte(B)-Größe) arbeitet. Es sind jedoch unterschiedliche Vektorbreiten und Registergrößen möglich.
Bei einer Ausführungsform können eine oder mehrere Ausführungseinheiten zu einer vereinigten Ausführungseinheit 2209A-2209N mit einer Thread-Steuerlogik (2207A-2207N) kombiniert werden, die den vereinigten EUs gemein ist. Mehrere EUs können zu einer EU-Gruppe vereinigt werden. Jede EU in der vereinigten EU-Gruppe kann derart konfiguriert sein, dass sie einen separaten SIMD-Hardware-Thread ausführt. Die Anzahl der EU in einer vereinigten EU-Gruppe kann je nach Ausführungsformen variieren. Außerdem können verschiedene SIMD-Breiten pro EU durchgeführt werden, einschließlich, jedoch nicht beschränkt auf, SIMD8, SIMD16 und SIMD32. Jede vereinigte Grafikausführungseinheit 2209A-2209N beinhaltet mindestens zwei Ausführungseinheiten. Zum Beispiel beinhaltet die vereinigte Ausführungseinheit 2209A eine erste EU 2208A, eine zweite EU 2208B und eine Thread-Steuerlogik 2207A, die der ersten EU 2208A und der zweiten EU 2208B gemein ist. Die Thread-Steuerlogik 2207A steuert Threads, die auf der vereinigten Grafikausführungseinheit 2209A ausgeführt werden, wodurch jeder EU innerhalb der vereinigten Ausführungseinheiten 2209A-2209N ermöglicht wird, unter Verwendung eines gemeinsam genutzten Anweisungszeigerregisters ausgeführt zu werden.
Ein oder mehrere interne Anweisungscaches (z. B. 2206) sind in der Thread-Ausführungslogik 2200 enthalten, um Thread-Anweisungen für die Ausführungseinheiten zu cachen. Bei manchen Ausführungsformen sind ein oder mehrere Datencaches (z. B. 2212) enthalten, um Thread-Daten während der Thread-Ausführung zu cachen. Bei manchen Ausführungsformen ist ein Sampler 2210 enthalten, um ein Textur-Sampling für 3D-Operationen und ein Medien-Sampling für Medienoperationen bereitzustellen. Bei manchen Ausführungsformen beinhaltet der Sampler 2210 eine spezielle Textur- oder Medien-Sampling-Funktionalität, um Textur- oder Mediendaten während des Sampling-Prozesses zu verarbeiten, bevor die gesampelten Daten einer Ausführungseinheit bereitgestellt werden.
Während der Ausführung senden die Grafik- und Medien-Pipelines Thread-Initiierungsanforderungen an die Thread-Ausführungslogik 2200 über die Thread-Spawning- und Dispatch-Logik. Sobald eine Gruppe geometrischer Objekte verarbeitet und zu Pixeldaten gerastert worden ist, wird Pixelprozessorlogik (z. B. Pixel-Shader-Logik, Fragment-Shader-Logik usw.) innerhalb des Shader-Prozessors 2202 aufgerufen, um Ausgabeinformationen weiter zu berechnen und zu bewirken, dass Ergebnisse auf Ausgabeoberflächen geschrieben werden (z. B. Farbpuffer, Tiefenpuffer, Schablonenpuffer usw.). In manchen Ausführungsformen berechnet ein Pixel-Shader oder Fragment-Shader die Werte der verschiedenen Vertex-Attribute, die über das gerasterte Objekt hinweg interpoliert werden sollen. Bei manchen Ausführungsformen führt die Pixelprozessorlogik innerhalb des Shader-Prozessors 2202 dann ein von einer Anwendungsprogrammierschnittstelle (API) geliefertes Pixel- oder Fragment-Shader-Programm aus. Um das Shader-Programm auszuführen, versendet der Shader-Prozessor 2202 Threads über den Thread-Dispatcher 2204 an eine Ausführungseinheit (z. B. 2208A). In manchen Ausführungsformen verwendet der Shader-Prozessor 2202 eine Textur-Sampling-Logik in dem Sampler 2210, um auf Texturdaten in im Speicher gespeicherten Texturabbildungen zuzugreifen. Arithmetische Operationen an den Texturdaten und den Eingabegeometriedaten berechnen Pixelfarbdaten für jedes geometrische Fragment oder verwerfen ein oder mehrere Pixel von der weiteren Verarbeitung.
Bei manchen Ausführungsformen stellt der Datenport 2214 einen Speicherzugriffsmechanismus für die Thread-Ausführungslogik 2200 bereit, um verarbeitete Daten an den Speicher zur weiteren Verarbeitung auf einer Grafikprozessorausgabe-Pipeline auszugeben. Bei manchen Ausführungsformen beinhaltet der Datenport 2214 einen oder mehrere Cachespeicher (z. B. Datencache 2212) oder ist damit gekoppelt, um Daten für einen Speicherzugriff über den Datenport zu cachen.
Wie in 22B veranschaulicht, kann eine Grafikausführungseinheit 2208 eine Anweisungsabrufeinheit 2237, ein Allgemeinregisterbank-Array (GRF) 2224, ein Architekturregisterbank-Array (ARF) 2226, einen Thread-Arbiter 2222, eine Sendeeinheit 2230, eine Verzweigungseinheit 2232, einen Satz von SIMD-Gleitkommaeinheiten (FPUs) 2234 und in einer Ausführungsform einen Satz von dedizierten ganzzahligen SIMD-ALUs 2235 beinhalten. Das GRF 2224 und das ARF 2226 beinhalten den Satz von Allgemeinregisterbänke und Architekturregisterbänke, die mit jedem gleichzeitigen Hardware-Thread assoziiert sind, der in der Grafikausführungseinheit 2208 aktiv sein kann. In einer Ausführungsform wird ein Architekturzustand pro Thread in dem ARF 2226 beibehalten, während Daten, die während der Thread-Ausführung verwendet werden, in dem GRF 2224 gespeichert werden. Der Ausführungszustand jedes Threads, einschließlich der Anweisungszeiger für jeden Thread, kann in Thread-spezifischen Registern im ARF 2226 gehalten werden.
In einer Ausführungsform weist die Grafikausführungseinheit 2208 eine Architektur auf, die eine Kombination von simultanem Multi-Threading (SMT) und feinkörnigem verschachteltem Multi-Threading (IMT) ist. Die Architektur weist eine modulare Konfiguration auf, die zur Gestaltungszeit basierend auf einer Zielanzahl von gleichzeitigen Threads und einer Anzahl von Registern pro Ausführungseinheit fein abgestimmt werden kann, wobei Ressourcen der Ausführungseinheit über die Logik aufgeteilt werden, die zum Ausführen mehrerer gleichzeitiger Threads verwendet wird.
In einer Ausführungsform kann die Grafikausführungseinheit 2208 mehrere Anweisungen gemeinsam ausgeben, die jeweils unterschiedliche Anweisungen sein können. Der Thread-Arbiter 2222 des Grafikausführungseinheit-Threads 2208 kann die Anweisungen an entweder die Sendeeinheit 2230, die Verzweigungseinheit 2232 oder die SIMD-FPU(s) 2234 zur Ausführung versenden. Jeder Ausführungs-Thread kann auf 128 Mehrzweckregister innerhalb der GRF 2224 zugreifen, wobei jedes Register 32 Bytes speichern kann, auf die als ein 8-Element-Vektor von 32-Bit-Datenelementen zugegriffen werden kann. In einer Ausführungsform hat jeder Ausführungseinheit-Thread Zugriff auf 4 kByte innerhalb des GRF 2224, obwohl die Ausführungsformen nicht darauf beschränkt sind und mehr oder weniger Registerressourcen in anderen Ausführungsformen bereitgestellt werden können. In einer Ausführungsform können bis zu sieben Threads gleichzeitig ausgeführt werden, obgleich die Anzahl an Threads pro Ausführungseinheit auch je nach Ausführungsform variieren kann. In einer Ausführungsform, bei der sieben Threads auf 4 kByte zugreifen können, kann das GRF 2224 insgesamt 28 kByte speichern. Flexible Adressierungsmodi können ermöglichen, dass Register zusammen adressiert werden, um effektiv breitere Register zu bilden oder um streifenförmige rechteckige Blockdatenstrukturen zu repräsentieren.
In einer Ausführungsform werden Speicheroperationen, Sampler-Operationen und andere Systemkommunikationen mit längerer Latenz über „send“ (Senden)-Anweisungen versendet, die durch die Nachrichtenweiterleitungssendeeinheit 2230 ausgeführt werden. In einer Ausführungsform werden Verzweigungsanweisungen an eine dedizierte Verzweigungseinheit 2232 versendet, um eine SIMD-Divergenz und letztliche Konvergenz zu ermöglichen.
In einer Ausführungsform beinhaltet die Grafikausführungseinheit 2208 eine oder mehrere SIMD-Gleitkommaeinheiten (FPU(s)) 2234 zum Durchführen von Gleitkommaoperationen. In einer Ausführungsform unterstützen die FPU(s) 2234 auch eine Ganzzahlberechnung. In einer Ausführungsform können die FPU(s) 2234 bis zu M Anzahl von 32-Bit Gleitkomma- (oder Ganzzahl-) Operationen SIMD-ausführen, oder bis zu 2 M 16-Bit Ganzzahl- oder 16-Bit Gleitkommaoperationen SIMD-ausführen. In einer Ausführungsform stellt mindestens eine der FPUs erweiterte mathematische Fähigkeiten bereit, um transzendentale mathematische Funktionen mit hohem Durchsatz und 64-Bit-Gleitkommazahl mit doppelter Präzision zu unterstützen. Bei manchen Ausführungsformen ist auch ein Satz von ganzzahligen 8-Bit-SIMD-ALUs 2235 vorhanden und kann speziell optimiert werden, um Operationen durchzuführen, die mit Maschinenlernberechnungen assoziiert sind.
In einer Ausführungsform können Arrays von mehreren Instanzen der Grafikausführungseinheit 2208 in einer Grafikunterkerngruppierung (z. B. einem Sub-Slice) instanziiert werden. Für die Skalierbarkeit können Produktarchitekten die exakte Anzahl an Ausführungseinheiten pro Unterkerngruppierung auswählen. Bei einer Ausführungsform kann die Ausführungseinheit 2208 Anweisungen über mehrere Ausführungskanäle ausführen. In einer weiteren Ausführungsform wird jeder Thread, der auf der Grafikausführungseinheit 2208 ausgeführt wird, auf einem anderen Kanal ausgeführt.
23 ist ein Blockdiagramm, das ein Grafikprozessoranweisungsformat 2300 gemäß manchen Ausführungsformen veranschaulicht. In einer oder mehreren Ausführungsformen unterstützen die Grafikprozessorausführungseinheiten einen Anweisungssatz mit Anweisungen in mehreren Formaten. Die Kästchen mit durchgezogenen Linien veranschaulichen die Komponenten, die allgemein in einer Ausführungseinheitenanweisung enthalten sind, während die gestrichelten Linien Komponenten enthalten, die optional sind oder die nur in einer Teilmenge der Anweisungen enthalten sind. Bei manchen Ausführungsformen sind die beschriebenen und veranschaulichten Anweisungsformate 2300 Makrobefehle, da sie Anweisungen sind, die der Ausführungseinheit zugeführt werden, im Gegensatz zu Mikrooperationen, die sich aus der Anweisungsdecodierung ergeben, sobald die Anweisung verarbeitet ist.
Bei manchen Ausführungsformen unterstützen die Grafikprozessorausführungseinheiten Anweisungen nativ in einem 128-Bit-Anweisungsformat 2310. Ein verdichtetes 64-Bit-Anweisungsformat 2330 ist für manche Anweisungen basierend auf der ausgewählten Anweisung, den Anweisungsoptionen und der Anzahl der Operanden verfügbar. Das native 128-Bit-Anweisungsformat 2310 bietet Zugriff auf alle Anweisungsoptionen, während manche Optionen und Operationen im 64-Bit-Format 2330 beschränkt sind. Die nativen Anweisungen, die im 64-Bit-Format 2330 verfügbar sind, variieren je nach Ausführungsform. Bei manchen Ausführungsformen wird die Anweisung teilweise unter Verwendung eines Satzes von Indexwerten in einem Indexfeld 2313 verdichtet. Die Ausführungseinheit-Hardware referenziert einen Satz von Verdichtungstabellen basierend auf den Indexwerten und verwendet die Verdichtungstabellenausgaben, um eine native Anweisung im 128-Bit-Anweisungsformat 2310 zu rekonstruieren. Andere Anweisungsgrößen und -formate können verwendet werden.
Für jedes Format definiert der Anweisungsopcode 2312 die Operation, die die Ausführungseinheit durchführen soll. Die Ausführungseinheiten führen jede Anweisung parallel über die mehreren Datenelemente jedes Operanden aus. Zum Beispiel führt die Ausführungseinheit als Reaktion auf eine Addieranweisung eine gleichzeitige Addieroperation über jeden Farbkanal durch, der ein Texturelement oder Bildelement repräsentiert. Standardmäßig führt die Ausführungseinheit jede Anweisung über alle Datenkanäle der Operanden durch. Bei manchen Ausführungsformen ermöglicht das Anweisungsteuerungsfeld 2314 die Steuerung bestimmter Ausführungsoptionen, wie die Kanalauswahl (z. B. Prädikation) und Datenkanalreihenfolge (z. B. Swizzle). Für Anweisungen im 128-Bit-Anweisungsformat 2310 begrenzt ein Ausführungsgrößenfeld 2316 die Anzahl an Datenkanälen, die parallel ausgeführt werden. Bei manchen Ausführungsformen ist das Ausführungsgröße-Feld 2316 nicht zur Verwendung in dem kompakten 64-Bit-Anweisungsformat 2330 verfügbar.
manche Ausführungseinheitsanweisungen haben bis zu drei Operanden einschließlich zwei Quelloperanden, src0 2320, src1 2322, und ein Ziel 2318. Bei manchen Ausführungsformen unterstützen die Ausführungseinheiten duale Zielanweisungen, wobei eines der Ziele impliziert ist. Datenmanipulationsanweisungen können einen dritten Quelloperanden aufweisen (z. B. SRC2 2324), wobei der Anweisungs-Opcode 2312 die Anzahl der Quelloperanden bestimmt. Der letzte Quelloperand einer Anweisung kann ein unmittelbarer (z. B. festcodierter) Wert sein, der mit der Anweisung übergeben wird.
Bei manchen Ausführungsformen beinhaltet das 128-Bit-Anweisungsformat 2310 ein Zugriffs-/Adressmodus-Feld 2326, das zum Beispiel angibt, ob der direkte Registeradressierungsmodus oder der indirekte Registeradressierungsmodus verwendet wird. Wenn der direkte Registeradressierungsmodus verwendet wird, wird die Registeradresse eines oder mehrerer Operanden direkt durch Bits in der Anweisung bereitgestellt.
Bei manchen Ausführungsformen beinhaltet das 128-Bit-Anweisungsformat 2310 ein Zugriffs-/Adressmodusfeld 2326, 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 verwendet. Manche Ausführungsformen unterstützen Zugriffsmodi einschließlich eines 16-Byte-ausgerichteten Zugriffsmodus und eines 1-Byte-ausgerichteten Zugriffsmodus, wobei die Byteausrichtung des Zugriffsmodus die Zugriffsausrichtung der Anweisungsoperanden bestimmt. Zum Beispiel kann die Anweisung, wenn sie sich in einem ersten Modus befindet, eine Byte-ausgerichtete Adressierung für Quellen und Zieloperanden verwenden, und, wenn sie sich in einem zweiten Modus befindet, kann die Anweisung eine 16-Byte-ausgerichtete Adressierung für alle Quellen und Zieloperanden verwenden.
In einer Ausführungsform bestimmt der Adressmodusabschnitt des Zugriffs-/Adressmodus-Feldes 2326, ob der Befehl eine direkte oder eine indirekte Adressierung verwenden soll. Wenn der direkte Registeradressierungsmodus verwendet wird, stellen die Bits in der Anweisung direkt die Registeradresse eines oder mehrerer Operanden bereit. Wenn der indirekte Registeradressierungsmodus verwendet wird, kann die Registeradresse eines oder mehrerer Operanden basierend auf einem Adressregisterwert und einem unmittelbaren Adressfeld in der Anweisung berechnet werden.
Bei manchen Ausführungsformen werden Anweisungen basierend auf Bitfeldern des Opcodes 2312 gruppiert, um die Opcode-Decodierung 2340 zu vereinfachen. Bei einem 8-Bit-Opcode ermöglichen die Bits 4, 5 und 6 der Ausführungseinheit, den Opcode-Typ zu bestimmen. Die gezeigte genaue Opcode-Gruppierung ist lediglich ein Beispiel. Bei manchen Ausführungsformen beinhaltet eine Bewegung-und-Logik-Opcode-Gruppe 2342 Datenbewegungs- und Logikanweisungen (z. B. move (mov), compare (cmp)). Bei manchen Ausführungsformen nutzt die Bewegungs- und Logikgruppe 2342 die fünf höchstwertigen Bits (MSB) gemeinsam, wobei move (mov) -Anweisungen die Form 0000xxxxb haben und Logikanweisungen die Form 0001xxxxb haben. Eine Flusssteueranweisungsgruppe 2344 (z. B. call, jump (jmp)) beinhaltet Anweisungen in Form von 0010xxxxb (z. B. 0x20). Eine gemischte Anweisungsgruppe 2346 beinhaltet eine Mischung von Anweisungen einschließlich Synchronisationsanweisungen (z. B. wait (Warten), send (Senden)) in der Form 001 Ixxxxb (z. B. 0x30). Eine parallele Mathematikanweisungsgruppe 2348 beinhaltet komponentenweise arithmetische Anweisungen (z. B. add, multiply (mul)) in der Form 0100xxxxb (z. B. 0x40). Die parallele Math.-Gruppe 2348 führt die arithmetischen Operationen parallel über Datenkanäle durch. Die Vektor-Mathematikgruppe 2350 beinhaltet arithmetische Befehle (z. B. dp4) in der Form 0101xxxxb (z. B. 0x50). Die Vektor-Mathematikgruppe führt eine Arithmetik wie z. B. Skalarproduktberechnungen an Vektoroperanden durch.
Grafik-Pipeline
24 ist ein Blockdiagramm einer anderen Ausführungsform eines Grafikprozessors 2400. Elemente aus 24, die die gleichen Bezugszeichen (oder Bezeichnungen) wie die Elemente einer beliebigen anderen Figur hierin können auf beliebige Weise ähnlich der an anderer Stelle hierin beschriebenen arbeiten oder funktionieren, sind aber nicht darauf beschränkt.
Bei manchen Ausführungsformen enthält der Grafikprozessor 2400 eine Geometrie-Pipeline 2420, eine Medien-Pipeline 2430, eine Anzeige-Engine 2440, eine Thread-Ausführungslogik 2450 und eine Rendering-Ausgabe-Pipeline 2470. Bei manchen Ausführungsformen ist der Grafikprozessor 2400 ein Grafikprozessor in einem Mehrkern-Verarbeitungssystem, das einen oder mehrere Mehrzweckverarbeitungskerne beinhaltet. Der Grafikprozessor wird durch Registerschreibvorgänge in ein oder mehrere Steuerregister (nicht gezeigt) oder über Befehle gesteuert, die über einen Ring-Interconnect 2402 an den Grafikprozessor 2400 ausgegeben werden. Bei manchen Ausführungsformen koppelt das Ring-Interconnect 2402 den Grafikprozessor 2400 mit anderen Verarbeitungskomponenten, wie etwa anderen Grafikprozessoren oder Allgemeinzweckprozessoren. Befehle von dem Ring-Interconnect 2402 werden von einem Befehls-Streamer 2403 interpretiert, der Anweisungen an einzelne Komponenten der Geometrie-Pipeline 2420 oder der Medien-Pipeline 2430 liefert.
Bei manchen Ausführungsformen leitet der Befehls-Streamer 2403 die Operation eines Vertex-Fetcher 2405, der Vertex-Daten aus einem Speicher liest, und führt Vertex-Verarbeitungsbefehle aus, die durch den Befehls-Streamer 2403 bereitgestellt werden. Bei manchen Ausführungsformen stellt die Vertex-Abrufkomponente 2405 Vertex-Daten einem Vertex-Shader 2407 bereit, der Koordinatenraumtransformationen und Beleuchtungsoperationen für jeden Vertex durchführt. Bei manchen Ausführungsformen führen die Vertex-Abrufer 2405 und der Vertex-Shader 2407 Vertex-Verarbeitungsanweisungen aus, indem sie Ausführungs-Threads über einen Thread-Dispatcher 2431 an die Ausführungseinheiten 2452A-2452B versenden.
Bei manchen Ausführungsformen sind die Ausführungseinheiten 2452A-2452B ein Array von Vektorprozessoren mit einem Anweisungssatz zum Durchführen von Grafik- und Medienoperationen. Bei manchen Ausführungsformen weisen die Ausführungseinheiten 2452A-2452B einen angehängten L1-Cache 2451 auf, der für jedes Array spezifisch ist oder von den Arrays gemeinsam genutzt wird. Der Cache kann als Datencache, als Anweisungscache oder als Einzelcache konfiguriert sein, der derart partitioniert ist, dass er Daten und Anweisungen in verschiedenen Partitionen enthält.
Bei manchen Ausführungsformen enthält die Geometrie-Pipeline 2420 Tessellationskomponenten, um eine hardwarebeschleunigte Tessellation von 3D-Objekten durchzuführen. Bei manchen Ausführungsformen konfiguriert ein programmierbarer Hüllen-Shader 2411 die Tesselationsoperationen. Ein programmierbarer Domänen-Shader 2417 stellt eine Backend-Auswertung der Tesselationsausgabe bereit. Ein Tessellator 2413 arbeitet in Richtung des Hüllen-Shaders 2411 und enthält eine Spezialzwecklogik zum Erzeugen eines Satzes detaillierter geometrischer Objekte basierend auf einem groben geometrischen Modell, das als Eingabe in die Geometrie-Pipeline 2420 bereitgestellt wird. Bei manchen Ausführungsformen können, falls keine Tessellation verwendet wird, Tessellationskomponenten (z. B. Hüllen-Shader 2411, Tessellator 2413 und Domänen-Shader 2417) umgangen werden.
Bei manchen Ausführungsformen können vollständige geometrische Objekte durch einen Geometrie-Shader 2419 über einen oder mehrere Threads verarbeitet werden, die an die Ausführungseinheiten 2452A-2452B versendet werden, oder sie können direkt zu dem Clipper 2429 weitergehen. Bei manchen Ausführungsformen arbeitet der Geometrie-Shader an ganzen geometrischen Objekten und nicht an Vertices oder Patches von Vertices wie in vorherigen Stufen der Grafik-Pipeline. Wenn die Parkettierung deaktiviert ist, empfängt der Geometrie-Shader 2419 eine Eingabe von dem Vertex-Shader 2407. Bei manchen Ausführungsformen ist der Geometrie-Shader 2419 durch ein Geometrie-Shader-Programm programmierbar, um eine Geometrietesselation durchzuführen, wenn die Tesselationseinheiten deaktiviert sind.
Vor der Rasterung verarbeitet ein Clipper 2429 Vertex-Daten. Der Clipper 2429 kann ein Festfunktions-Clipper oder ein programmierbarer Clipper mit Clipping und Geometrie-Shader-Funktionen sein. Bei manchen Ausführungsformen versendet eine Rasterisierer-und-Tiefenprüfung-Komponente 2473 in der Rendering-Ausgabe-Pipeline 2470 Pixel-Shader, um die geometrischen Objekte in Pro-Pixel-Repräsentationen umzuwandeln. Bei manchen Ausführungsformen ist eine Pixel-Shader-Logik in der Thread-Ausführungslogik 2450 enthalten. Bei manchen Ausführungsformen kann eine Anwendung die Rasterisierer-und-Tiefenprüfung-Komponente 2473 umgehen und über eine Stream-Out-Einheit 2423 auf nicht gerasterte Vertex-Daten zugreifen.
Der Grafikprozessor 2400 weist einen Interconnect-Bus, ein Interconnect-Fabric oder einen anderen Interconnect-Mechanismus auf, der ein Weitergeben von Daten und Nachrichten zwischen den Hauptkomponenten des Prozessors ermöglicht. Bei manchen Ausführungsformen sind die Ausführungseinheiten 2452A-2452B und die assoziierten Logikeinheiten (z. B. L1-Cache 2451, Sampler 2454, Textur-Cache 2458 usw.) über einen Datenport 2456 miteinander verbunden, um einen Speicherzugriff durchzuführen und mit Rendering-Ausgabe-Pipeline-Komponenten des Prozessors zu kommunizieren. Bei manchen Ausführungsformen weisen der Sampler 2454, der L1-Cache 2451, der Texturcache 2458 und die Ausführungseinheiten 2452A-2452B jeweils separate Speicherzugriffspfade auf. In einer Ausführungsform kann der Texturcache 2458 auch als ein Sampler-Cache konfiguriert sein.
Bei manchen Ausführungsformen enthält die Rendering-Ausgabe-Pipeline 2470 eine Rasterisierer-und-Tiefenprüfung-Komponente 2473, die Vertex-basierte Objekte in eine assoziierte pixelbasierte Repräsentation umwandelt. Bei manchen Ausführungsformen weist die Rasterisierer-Logik eine Windower/Maskierer-Einheit auf, um eine Dreiecks- und Linienrasterung mit fester Funktion durchzuführen. Ein assoziierter Rendering-Cache 2478 und Tiefencache 2479 sind bei manchen Ausführungsformen ebenfalls verfügbar. Eine Pixeloperationskomponente 2477 führt pixelbasierte Operationen an den Daten durch, obgleich in manchen Fällen Pixeloperationen, die mit 2D-Operationen assoziiert sind (z. B. Bitblockbildtransfers mit Mischen), durch die 2D-Engine 2441 durchgeführt oder zur Anzeigezeit durch die Anzeigesteuerung 2443 unter Verwendung von Overlay-Anzeigeebenen ersetzt werden. Bei manchen Ausführungsformen ist ein gemeinsam genutzter L3-Cache 2475 für alle Grafikkomponenten verfügbar, was die gemeinsame Nutzung von Daten ohne die Verwendung von Hauptsystemspeicher ermöglicht.
Bei manchen Ausführungsformen beinhaltet die Grafikprozessor-Medien-Pipeline 2430 eine Medien-Engine 2437 und ein Video-Frontend 2434. Bei manchen Ausführungsformen empfängt das Video-Frontend 2434 Pipeline-Befehle von dem Befehls-Streamer 2403. Bei manchen Ausführungsformen beinhaltet die Medien-Pipeline 2430 einen separaten Befehls-Streamer. Bei manchen Ausführungsformen verarbeitet das Video-Frontend 2434 Medienbefehle vor dem Senden des Befehls zu der Medien-Engine 2437. Bei manchen Ausführungsformen beinhaltet die Medien-Engine 2437 eine Thread-Spawning-Funktionalität, um Threads zum Versenden an die Thread-Ausführungslogik 2450 über den Thread-Dispatcher 2431 zu spawnen.
Bei manchen Ausführungsformen beinhaltet der Grafikprozessor 2400 eine Anzeige-Engine 2440. Bei manchen Ausführungsformen befindet sich die Anzeige-Engine 2440 außerhalb des Prozessors 2400 und ist über den Ring-Interconnect 2402 oder einen anderen Interconnect-Bus oder anderes Interconnect-Fabric mit dem Grafikprozessor gekoppelt. Bei manchen Ausführungsformen beinhaltet die Anzeige-Engine 2440 eine 2D-Engine 2441 und eine Anzeigesteuerung 2443. Bei manchen Ausführungsformen enthält die Anzeige-Engine 2440 eine Speziallogik, die dazu in der Lage ist, unabhängig von der 3D-Pipeline zu arbeiten. Bei manchen Ausführungsformen ist die Anzeigesteuerung 2443 mit einer Anzeigevorrichtung (nicht gezeigt) gekoppelt, die eine systemintegrierte Anzeigevorrichtung wie in einem Laptop-Computer oder eine externe Anzeigevorrichtung sein kann, die über ein Anzeigevorrichtungsverbindungselement angeschlossen ist.
Bei manchen Ausführungsformen sind die Geometrie-Pipeline 2420 und die Medien-Pipeline 2430 dazu konfigurierbar, Operationen basierend auf mehreren Grafik- und Medienprogrammierschnittstellen durchzuführen, und sind für keine Anwendungsprogrammierschnittstelle (API) spezifisch. Bei manchen Ausführungsformen übersetzt die 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. Bei manchen Ausführungsformen wird Unterstützung für Open Graphics Library (OpenGL), Open Computing Language (OpenCL) und/oder Vulkan Graphics und Rechen-API bereitgestellt, die alle von der Khronos Group sind. Bei manchen Ausführungsformen wird eine Unterstützung auch für die Direct3D-Bibliothek von der Microsoft Corporation bereitgestellt. Bei manchen Ausführungsformen kann eine Kombination dieser Bibliotheken unterstützt werden. Unterstützung kann auch für die Open-Source-Computer-Vision-Library (OpenCV) bereitgestellt werden. Eine zukünftige API mit einer kompatiblen 3D-Pipeline wird ebenfalls unterstützt, falls eine Abbildung von der Pipeline der zukünftigen API auf die Pipeline des Grafikprozessors vorgenommen werden kann.
Grafik-Pipeline-Programmierung
25A ist ein Blockdiagramm, das ein Grafikprozessorbefehlsformat 2500 gemäß manchen Ausführungsformen veranschaulicht. 25B ist ein Blockdiagramm, das eine Grafikprozessorbefehlssequenz 2510 gemäß einer Ausführungsform veranschaulicht. Die durchgezogenen Kästen in 25A veranschaulichen die Komponenten, die im Allgemeinen in einem Grafikbefehl enthalten sind, während die gestrichelten Linien Komponenten enthalten, die optional sind oder die nur in einer Teilmenge der Grafikbefehle enthalten sind. Das beispielhafte Grafikprozessorbefehlsformat 2500 aus 25A enthält Datenfelder zum Identifizieren eines Clients 2502, eines Befehlsoperationscodes (Opcodes) 2504 und von Daten 2506 für den Befehl. Ein Sub-Opcode 2505 und eine Befehlsgröße 2508 sind auch in manchen Befehlen enthalten.
Bei manchen Ausführungsformen spezifiziert der Client 2502 die Client-Einheit der Grafikvorrichtung, die die Befehlsdaten verarbeitet. Bei manchen Ausführungsformen untersucht ein Grafikprozessor-Befehls-Parser das Client-Feld jedes Befehls, um die weitere Verarbeitung des Befehls zu konditionieren und die Befehlsdaten an die geeignete Client-Einheit weiterzuleiten. Bei manchen Ausführungsformen weisen die Grafikprozessor-Client-Einheiten eine Speicherschnittstelleneinheit, eine Rendering-Einheit, eine 2D-Einheit, eine 3D-Einheit und eine Medieneinheit auf. Jede Client-Einheit weist eine entsprechende Verarbeitungs-Pipeline auf, die die Befehle verarbeitet. Sobald der Befehl durch die Client-Einheit empfangen wird, liest die Client-Einheit den Opcode 2504 und, falls vorhanden, den Sub-Opcode 2505, um die durchzuführende Operation zu bestimmen. Die Client-Einheit führt den Befehl unter Verwendung von Informationen in dem Datenfeld 2506 aus. Für manche Befehle wird eine explizite Befehlsgröße 2508 erwartet, die die Größe des Befehls angibt. Bei manchen Ausführungsformen bestimmt der Befehls-Parser automatisch die Größe von mindestens manchen der Befehle basierend auf dem Befehls-Opcode. Bei manchen Ausführungsformen werden Befehle über Vielfache eines Doppelwortes ausgerichtet. Andere Befehlsformate können verwendet werden.
Das Flussdiagramm in 25B veranschaulicht eine beispielhafte Grafikprozessorbefehlssequenz 2510. Bei manchen Ausführungsformen verwendet Software oder Firmware eines Datenverarbeitungssystems, das eine Ausführungsform eines Grafikprozessors aufweist, eine Version der gezeigten Befehlssequenz, um einen Satz von Grafikoperationen einzurichten, auszuführen und zu beenden. Eine beispielhafte Befehlssequenz wird nur zu Beispielszwecken gezeigt und beschrieben, da Ausführungsformen nicht auf diese speziellen Befehle oder auf diese Befehlssequenz beschränkt sind. Darüber hinaus können die Befehle als Batch von Befehlen in einer Befehlssequenz ausgegeben werden, sodass der Grafikprozessor die Befehlssequenz zumindest teilweise gleichzeitig verarbeiten wird.
Bei manchen Ausführungsformen kann die Grafikprozessor-Befehlssequenz 2510 mit einem Pipeline-Flush-Befehl 2512 beginnen, um zu bewirken, dass eine aktive Grafik-Pipeline die aktuell anstehenden Befehle für die Pipeline vervollständigt. In manchen Ausführungsformen arbeiten die 3D-Pipeline 2522 und die Medien-Pipeline 2524 nicht gleichzeitig. Der Pipeline-Flush wird durchgeführt, um die aktive Grafik-Pipeline zu veranlassen, alle ausstehenden Befehle abzuschließen. Als Reaktion auf einen Pipeline-Flush pausiert der Befehls-Parser für den Grafikprozessor die Befehlsverarbeitung, bis die aktiven Zeichnung-Engines ausstehende Operationen abschließen und die relevanten Lese-Caches ungültig gemacht werden. Optional können beliebige Daten in dem Rendering-Cache, die als „verschmutzt“ markiert sind, in den Speicher geflusht werden. Bei manchen Ausführungsformen kann der Pipeline-Flushing-Befehl 2512 zur Pipeline-Synchronisation oder vor dem Versetzen des Grafikprozessors in einen Stromsparzustand verwendet werden.
Bei manchen Ausführungsformen wird ein Pipeline-Auswahlbefehl 2513 verwendet, wenn eine Befehlssequenz erfordert, dass der Grafikprozessor explizit zwischen Pipelines umschaltet. Bei manchen Ausführungsformen wird ein Pipeline-Auswahlbefehl 2513 nur einmal in einem Ausführungskontext vor dem Ausgeben von Pipeline-Befehlen benötigt, es sei denn, der Kontext gibt Befehle für beide Pipelines aus. Bei manchen Ausführungsformen ist ein Pipeline-Flush-Befehl 2512 unmittelbar vor einem Pipeline-Umschalten über den Pipeline-Auswahlbefehl 2513 erforderlich.
Bei manchen Ausführungsformen konfiguriert ein Pipeline-Steuerbefehl 2514 eine Grafik-Pipeline für den Betrieb und wird verwendet, um die 3D-Pipeline 2522 und die Medien-Pipeline 2524 zu programmieren. Bei manchen Ausführungsformen konfiguriert der Pipeline-Steuerbefehl 2514 den Pipeline-Zustand für die aktive Pipeline. Bei einer Ausführungsform wird der Pipeline-Steuerbefehl 2514 für die Pipeline-Synchronisation und zum Löschen von Daten von einem oder mehreren Cachespeichern innerhalb der aktiven Pipeline verwendet, bevor ein Stapel von Befehlen verarbeitet wird.
Bei manchen Ausführungsformen werden Befehle zum Konfigurieren des Rücksprungpufferzustands 2516 verwendet, um einen Satz von Rückgabepuffer für die jeweiligen Pipelines zum Schreiben von Daten zu konfigurieren. Manche Pipeline-Operationen erfordern die Zuweisung, Auswahl oder Konfiguration eines oder mehrerer Rückgabepuffer, in die die Operationen Zwischendaten während der Verarbeitung schreiben. Bei manchen Ausführungsformen verwendet der Grafikprozessor auch einen oder mehrere Rückgabepuffer, um Ausgabedaten zu speichern und eine Cross-Thread-Kommunikation auszuführen. Bei manchen Ausführungsformen beinhaltet der Rückgabepufferzustand 2516 das Auswählen der Größe und Anzahl von Rückgabepuffern, die für einen Satz von Pipeline-Operationen zu verwenden sind.
Die verbleibenden Befehle in der Befehlssequenz unterscheiden sich basierend auf der aktiven Pipeline für Operationen. Basierend auf einer Pipeline-Bestimmung 2520 wird die Befehlssequenz auf die 3D-Pipeline 2522, beginnend mit dem 3D-Pipeline-Zustand 2530, oder auf die Medien-Pipeline 2524, beginnend mit dem Medien-Pipeline-Zustand 2540, zugeschnitten.
Die Befehle zum Konfigurieren des 3D-Pipeline-Zustands 2530 beinhalten 3D-Zustandseinstellbefehle für den Vertex-Pufferzustand, den Vertex-Elementzustand, den konstanten Farbzustand, den Tiefenpufferzustand und andere Zustandsvariablen, die zu konfigurieren sind, bevor 3D-Primitivenbefehle verarbeitet werden. Die Werte dieser Befehle werden zumindest teilweise basierend auf der jeweiligen verwendeten 3D-API bestimmt. Bei manchen Ausführungsformen sind Befehle zum 3D-Pipeline-Zustand 2530 auch in der Lage, bestimmte Pipeline-Elemente gezielt zu deaktivieren oder zu umgehen, falls diese Elemente nicht verwendet werden.
Bei manchen Ausführungsformen wird der 3D-Primitivenbefehl 2532 verwendet, um 3D-Primitive, die von der 3D-Pipeline verarbeitet werden sollen, zu versenden. Befehle und assoziierte Parameter, die über den 3D-Primitivenbefehl 2532 an den Grafikprozessor geleitet werden, werden an die Vertex-Abruffunktion in der Grafik-Pipeline weitergeleitet. Die Vertex-Abruffunktion verwendet die Daten des 3D-Primitivenbefehls 2532, um Vertex-Datenstrukturen zu erzeugen. Die Vertex-Datenstrukturen werden in einem oder mehreren Rückgabepuffern gespeichert. Bei manchen Ausführungsformen wird der 3D-Primitivbefehl 2532 verwendet, um Vertex-Operationen an 3D-Primitiven über Vertex-Shader durchzuführen. Um Vertex-Shader zu verarbeiten, versendet die 3D-Pipeline 2522 Shader-Ausführungs-Threads an Grafikprozessorausführungseinheiten.
Bei manchen Ausführungsformen wird die 3D-Pipeline 2522 über einen Ausführungsbefehl 2534 oder ein Ausführungsereignis ausgelöst. Bei manchen Ausführungsformen löst ein Registerschreibvorgang eine Befehlsausführung aus. Bei manchen Ausführungsformen wird die Ausführung über einen „go“ - oder „kick“ -Befehl in der Befehlsfolge ausgelöst. Bei einer Ausführungsform wird die Befehlsausführung unter Verwendung eines Pipeline-Synchronisationsbefehls ausgelöst, um die Befehlssequenz durch die Grafik-Pipeline zu flushen. Die 3D-Pipeline führt eine Geometrieverarbeitung für die 3D-Primitive aus. Sobald die Operationen abgeschlossen sind, werden die resultierenden geometrischen Objekte gerastert und färbt die Pixel-Engine die resultierenden Pixel. Zusätzliche Befehle zum Steuern des Pixel-Shadings und der Pixel-Backend-Operationen können ebenfalls für diese Operationen enthalten sein.
Bei manchen Ausführungsformen folgt die Grafikprozessorbefehlssequenz 2510 dem Pfad der Medien-Pipeline 2524, wenn Medienoperationen durchgeführt werden. Im Allgemeinen hängt die spezielle Verwendung und Art der Programmierung für die Medien-Pipeline 2524 von den durchzuführenden Medien- oder Rechenoperationen ab. Spezielle Mediendecodierungsoperationen können während der Mediendecodierung in die Medien-Pipeline ausgelagert werden. Bei manchen Ausführungsformen kann die Medien-Pipeline auch umgangen werden und kann die Mediendecodierung vollständig oder teilweise unter Verwendung von Ressourcen durchgeführt werden, die von einem oder mehreren Mehrzweckverarbeitungskernen bereitgestellt werden. In einer Ausführungsform beinhaltet die Medien-Pipeline auch Elemente für Operationen einer Mehrzweckgrafikprozessoreinheit (GPGPU: General-Purpose Graphics Processor Unit), wobei der Grafikprozessor verwendet wird, um SIMD-Vektoroperationen unter Verwendung von Rechen-Shader-Programmen, die nicht explizit mit dem Rendering von Grafikprimitiven in Zusammenhang stehen, durchzuführen.
Bei manchen Ausführungsformen ist die Medien-Pipeline 2524 auf ähnliche Weise wie die 3D-Pipeline 2522 konfiguriert. Ein Satz von Befehlen zum Konfigurieren des Medien-Pipeline-Zustands 2540 wird vor den Medienobjektbefehlen 2542 versendet oder in eine Befehlswarteschlange eingereiht. Bei manchen Ausführungsformen beinhalten Befehle für den Medien-Pipeline-Zustand 2540 Daten zum Konfigurieren der Medien-Pipeline-Elemente, die zum Verarbeiten der Medienobjekte verwendet werden. Dies schließt Daten zum Konfigurieren der Videodecodierungs- und Videocodierungslogik in der Medien-Pipeline wie etwa ein Codierungs- oder Decodierungsformat ein. Bei manchen Ausführungsformen unterstützen Befehle für den Medien-Pipeline-Zustand 2540 auch die Verwendung eines oder mehrerer Zeiger auf „indirekte“ Zustandselemente, die einen Stapel von Zustandseinstellungen enthalten.
Bei manchen Ausführungsformen liefern Medienobjektbefehle 2542 Zeiger auf Medienobjekte zur Verarbeitung durch die Medien-Pipeline. Die Medienobjekte beinhalten Speicherpuffer, die zu verarbeitende Videodaten enthalten. Bei manchen Ausführungsformen müssen alle Medien-Pipeline-Zustände gültig sein, bevor sie einen Medienobjektbefehl 2542 ausgeben. Sobald der Pipeline-Zustand konfiguriert ist und die Medienobjektbefehle 2542 in die Warteschlange eingereiht sind, wird die Medien-Pipeline 2524 über einen Ausführungsbefehl 2544 oder ein äquivalentes Ausführungsereignis (z. B. Registerschreibvorgang) ausgelöst. Die Ausgabe von der Medien-Pipeline 2524 kann dann durch Operationen nachbearbeitet werden, die durch die 3D-Pipeline 2522 oder die Medien-Pipeline 2524 bereitgestellt werden. Bei manchen Ausführungsformen werden GPGPU-Operationen auf ähnliche Art und Weise wie Medienoperationen konfiguriert und ausgeführt.
Grafik-Software-Architektur
26 veranschaulicht eine beispielhafte Grafiksoftwarearchitektur für ein Datenverarbeitungssystem 2600 gemäß manchen Ausführungsformen. Bei manchen Ausführungsformen beinhaltet die Softwarearchitektur eine 3D-Grafikanwendung 2610, ein Betriebssystem 2620 und mindestens einen Prozessor 2630. Bei manchen Ausführungsformen beinhaltet der Prozessor 2630 einen Grafikprozessor 2632 und einen oder mehrere Mehrzweckprozessorkerne 2634. Die Grafikanwendung 2610 und das Betriebssystem 2620 werden jeweils in dem Systemspeicher 2650 des Datenverarbeitungssystems ausgeführt.
Bei manchen Ausführungsformen enthält die 3D-Grafikanwendung 2610 ein oder mehrere Shader-Programme, einschließlich Shader-Anweisungen 2612. Die Shader-Sprache-Anweisungen können in einer High-Level-Shader-Sprache sein, wie etwa der High-Level-Shader-Sprache (HLSL) von Direc3D, der OpenGL Shader-Sprache (GLSL) und so weiter. Die Anwendung weist auch ausführbare Anweisungen 2614 in einer Maschinensprache auf, die zur Ausführung durch den Mehrzweckprozessorkern 2634 geeignet sind. Die Anwendung beinhaltet auch Grafikobjekte 2616, die durch Vertex-Daten definiert sind.
Bei manchen Ausführungsformen ist das Betriebssystem 2620 ein Microsoft® Windows® Betriebssystem der Microsoft Corporation, ein proprietäres UNIX-ähnliches Betriebssystem oder ein UNIX-ähnliches Betriebssystem mit offener Quelle, das eine Variante des Linux-Kernels verwendet. Das Betriebssystem 2620 kann eine Grafik-API 2622 unterstützen, wie etwa die Direct3D-API, die OpenGL-API oder die Vulkan-API. Wenn die Direct3D-API verwendet wird, verwendet das Betriebssystem 2620 einen Frontend-Shader-Kompilierer 2624, um alle Shader-Anweisungen 2612 in HLSL in eine Shader-Sprache niedrigerer Ebene zu kompilieren. Die Kompilierung kann eine Just-in-Time(JIT)-Kompilierung sein, oder die Anwendung kann eine Shader-Vorkompilierung durchführen. Bei manchen Ausführungsformen werden High-Level-Shader während der Kompilierung der 3D-Grafikanwendung 2610 zu Low-Level-Shaders kompiliert. Bei manchen Ausführungsformen werden die Shader-Anweisungen 2612 in einer Zwischenform bereitgestellt, wie etwa als eine Version der SPIR (Standard Portable Intermediate Representation), die durch die Vulkan-API verwendet wird.
Bei manchen Ausführungsformen enthält ein Benutzermodus-Grafiktreiber 2626 einen Backend-Shader-Kompilierer 2627, um die Shader-Anweisungen 2612 in eine hardwarespezifische Repräsentation umzuwandeln. Wenn die OpenGL-API verwendet wird, werden Shader-Anweisungen 2612 in der GLSL-Hochsprache zum Kompilieren an einen Benutzermodus-Grafiktreiber 2626 weitergegeben. Bei manchen Ausführungsformen verwendet der Benutzermodus-Grafiktreiber 2626 Betriebssystemkernelmodus-Funktionen 2628, um mit einem Kernelmodus-Grafiktreiber 2629 zu kommunizieren. Bei manchen Ausführungsformen kommuniziert der Kernelmodus-Grafiktreiber 2629 mit dem Grafikprozessor 2632, um Befehle und Anweisungen zu versenden.
IP-Kern-Implementierungen
Ein oder mehrere Aspekte mindestens einer Ausführungsform können durch einen repräsentativen Code implementiert werden, der auf einem maschinenlesbaren Medium gespeichert ist, das Logik innerhalb einer integrierten Schaltung, wie zum Beispiel einem Prozessor, repräsentiert und/oder definiert. Zum Beispiel kann das maschinenlesbare Medium Anweisungen beinhalten, die verschiedene Logik innerhalb des Prozessors repräsentieren. Wenn sie durch eine Maschine gelesen werden, können die Anweisungen bewirken, dass die Maschine die Logik herstellt, um die hier beschriebenen Techniken durchzuführen. Derartige Repräsentationen, die als „IP-Kerne“ bekannt sind, sind wiederverwendbare Logikeinheiten für eine integrierte Schaltung, die auf einem greifbaren, maschinenlesbaren Medium als ein Hardwaremodell gespeichert werden können, das die Struktur der integrierten Schaltung beschreibt. Das Hardwaremodell kann an verschiedene Kunden oder Herstellungsanlagen geliefert werden, die das Hardwaremodell auf Herstellungsmaschinen laden, die die integrierte Schaltung herstellen. Die integrierte Schaltung kann derart hergestellt sein, dass die Schaltung Operationen durchführt, die in Verbindung mit irgendeiner der hierin beschriebenen Ausführungsformen beschrieben sind.
27A ist ein Blockdiagramm, das ein IP-Kern-Entwicklungssystem 2700 veranschaulicht, das verwendet werden kann, um eine integrierte Schaltung herzustellen, um Operationen gemäß einer Ausführungsform durchzuführen. Das IP-Kern-Entwicklungssystem 2700 kann verwendet werden, um modulare, wiederverwendbare Designs zu erzeugen, die in ein größeres Design integriert oder verwendet werden können, um eine gesamte integrierte Schaltung (z. B. eine integrierte SOC-Schaltung) aufzubauen. Eine Designanlage 2730 kann eine Softwaresimulation 2710 eines IP-Kern-Designs in einer höheren Programmiersprache (z. B. C/C++) erzeugen. Die Softwaresimulation 2710 kann dazu verwendet werden, das Verhalten des IP-Kerns unter Verwendung eines Simulationsmodells 2712 zu entwerfen, zu testen und zu verifizieren. Das Simulationsmodell 2712 kann Funktions-, Verhaltens- und/oder Timing-Simulationen beinhalten. Ein Registertransferebene(RTL)-Design 2715 kann dann aus dem Simulationsmodell 2712 erzeugt oder synthetisiert werden. Das RTL-Design 2715 ist eine Abstraktion des Verhaltens der integrierten Schaltung, die den Fluss digitaler Signale zwischen Hardwareregistern modelliert, einschließlich der assoziierten Logik, die unter Verwendung der modellierten digitalen Signale durchgeführt wird. Neben einem RTL-Design 2715 können auch Designs auf niedrigerer Ebene auf der Logikebene oder der Transistorebene erzeugt, gestaltet oder synthetisiert werden. Daher können die speziellen Einzelheiten des anfänglichen Designs und der Simulation variieren.
Das RTL-Design 2715 oder ein Äquivalent kann ferner durch die Designeinrichtung in ein Hardwaremodell 2720 synthetisiert werden, das in einer Hardwarebeschreibungssprache (HDL) oder einer anderen Repräsentation von physischen Designdaten vorliegen kann. Die HDL kann weiter simuliert oder getestet werden, um den IP-Kern-Entwurf zu verifizieren. Die IP-Kern-Gestaltung kann zur Lieferung an eine Drittfertigungsanlage 2765 unter Verwendung eines nichtflüchtigen Speichers 2740 (z. B. einer Festplatte, eines Flash-Speichers oder eines beliebigen nichtflüchtigen Speichermediums) gespeichert werden. Alternativ kann das IP-Kern-Design über eine drahtgebundene Verbindung 2750 oder eine drahtlose Verbindung 2760 (z. B. über das Internet) übertragen werden. Die Fertigungsanlage 2765 kann dann eine integrierte Schaltung fertigen, die zumindest teilweise auf dem IP-Kern-Design basiert. Die gefertigte integrierte Schaltung kann dazu konfiguriert sein, Operationen gemäß wenigstens einer hier beschriebenen Ausführungsform durchzuführen.
27B veranschaulicht eine Querschnittsseitenansicht einer Package-Baugruppe 2770 einer integrierten Schaltung gemäß manchen hierin beschriebenen Ausführungsformen. Die Package-Baugruppe 2770 der integrierten Schaltung veranschaulicht eine Implementierung eines oder mehrerer Prozessoren oder einer oder mehrerer Beschleunigervorrichtungen, wie hier beschrieben. Die Package-Baugruppe 2770 beinhaltet mehrere Hardwarelogikeinheiten 2772, 2774, die mit einem Substrat 2780 verbunden sind. Die Logik 2772, 2774 kann zumindest teilweise in konfigurierbarer Logik- oder Festfunktionalitätslogikhardware implementiert werden und kann einen oder mehrere Teile beliebiger des/der Prozessorkern(e), des/der mehreren Grafikprozessor(en) oder anderer hierin beschriebener Beschleunigervorrichtungen beinhalten. Jede Logikeinheit 2772, 2774 kann in einem Halbleiter-Die implementiert und über eine Interconnect-Struktur 2773 mit dem Substrat 2780 gekoppelt sein. Die Interconnect-Struktur 2773 kann dazu ausgelegt sein, elektrische Signale zwischen der Logik 2772, 2774 und dem Substrat 2780 zu routen, und kann Interconnects, wie etwa unter anderem Kontakthügel oder Säulen, beinhalten. Bei manchen Ausführungsformen kann die Interconnect-Struktur 2773 dazu ausgelegt sein, elektrische Signale, zum Beispiel Eingabe/Ausgabe(E/A)-Signale und/oder Leistungs- oder Massesignale, zu routen, die mit dem Betrieb der Logik 2772, 2774 assoziiert sind. Bei manchen Ausführungsformen ist das Substrat 2780 ein epoxidbasiertes Laminatsubstrat. Das Substrat 2780 kann in anderen Ausführungsformen andere geeignete Arten von Substraten beinhalten. Die Package-Baugruppe 2770 kann über ein Package-Interconnect 2783 mit anderen elektrischen Vorrichtungen verbunden sein. Das Package-Interconnect 2783 kann mit einer Oberfläche des Substrats 2780 gekoppelt sein, um elektrische Signale zu anderen elektrischen Vorrichtungen, wie etwa einer Hauptplatine, einem anderen Chipsatz oder einem Mehrchipmodul zu routen.
Bei manchen Ausführungsformen sind die Logikeinheiten 2772, 2774 elektrisch mit einer Brücke 2782 gekoppelt, die dazu ausgelegt ist, elektrische Signale zwischen der Logik 2772, 2774 zu routen. Die Brücke 2782 kann eine dichte Interconnect-Struktur sein, die eine Route für elektrische Signale bereitstellt. Die Brücke 2782 kann ein Brückensubstrat beinhalten, das aus Glas oder einem geeigneten Halbleitermaterial gebildet ist. Elektrische Routing-Merkmale können auf dem Brückensubstrat ausgebildet sein, um eine Chip-zu-Chip-Verbindung zwischen der Logik 2772, 2774 bereitzustellen.
Obwohl zwei Logikeinheiten 2772, 2774 und eine Brücke 2782 veranschaulicht sind, können hier beschriebene Ausführungsformen mehr oder weniger Logikeinheiten auf einem oder mehreren Dies beinhalten. Der eine oder die mehreren Dies können durch keine oder mehr Brücken verbunden sein, da die Brücke 2782 ausgelassen werden kann, wenn die Logik auf einem einzelnen Die enthalten ist. Alternativ dazu können mehrere Dies oder Logikeinheiten durch eine oder mehrere Brücken verbunden sein. Zusätzlich dazu können mehrere Logikeinheiten, Dies und Brücken in anderen möglichen Konfigurationen, einschließlich dreidimensionaler Konfigurationen, miteinander verbunden sein.
Beispielhafte integrierte System-on-Chip-Schaltung
28-29B veranschaulichen beispielhafte integrierte Schaltungen und zugehörige Grafikprozessoren, die unter Verwendung eines oder mehrerer IP-Kerne gemäß verschiedenen hierin beschriebenen Ausführungsformen hergestellt werden können. Zusätzlich zu den Veranschaulichungen können andere Logik und Schaltungen enthalten sein, einschließlich zusätzlicher Grafikprozessoren/-kerne, Peripherieschnittstellensteuerungen oder Mehrzweckprozessorkerne.
28 ist ein Blockdiagramm, das ein beispielhaftes System auf einer integrierten Chip-Schaltung 2800 veranschaulicht, die gemäß einer Ausführungsform unter Verwendung eines oder mehrerer IP-Kerne hergestellt werden kann. Die beispielhafte integrierte Schaltung 2800 enthält einen oder mehrere Anwendungsprozessor(en) 2805 (z. B. CPUs), mindestens einen Grafikprozessor 2810 und kann zusätzlich einen Bildprozessor 2815 und/oder einen Videoprozessor 2820 enthalten, von denen jeder ein modularer IP-Kern aus derselben oder mehreren verschiedenen Designeinrichtungen sein kann. Die integrierte Schaltung 2800 enthält eine Peripherie oder Buslogik, einschließlich einer USB-Steuerung 2825, einer UART-Steuerung 2830, einer SPFSDIO-Steuerung 2835 und einer I²S/I²C-Steuerung 2840. Außerdem kann die integrierte Schaltung eine Anzeigevorrichtung 2845 beinhalten, die mit einer HDMI(High Definition Multimedia Interface)-Steuerung 2850 und/oder einer MIPI(Mobile Industry Processor Interface)-Anzeigeschnittstelle 2855 gekoppelt ist. Die Speicherung kann durch ein Flash-Speicher-Untersystem 2860 bereitgestellt werden, das einen Flash-Speicher und eine Flash-Speichersteuerung aufweist. Die Speicherschnittstelle kann über eine Speichersteuerung 2865 für den Zugriff auf SDRAM- oder SRAM-Speichervorrichtungen bereitgestellt sein. manche integrierte Schaltungen beinhalten zusätzlich eine eingebettete Sicherheits-Engine 2870.
29A-29B sind Blockdiagramme, die beispielhafte Grafikprozessoren zur Verwendung in einem SoC gemäß hierin beschriebenen Ausführungsformen veranschaulichen. 29A veranschaulicht einen beispielhaften Grafikprozessor 2910 einer integrierten System-on-Chip-Schaltung, der gemäß einer Ausführungsform unter Verwendung eines oder mehrerer IP-Kerne hergestellt werden kann. 29B veranschaulicht einen zusätzlichen beispielhaften Grafikprozessor 2940 einer integrierten System-on-Chip-Schaltung, der gemäß einer Ausführungsform unter Verwendung eines oder mehrerer IP-Kerne hergestellt werden kann. Der Grafikprozessor 2910 von 29A ist ein Beispiel für einen Grafikprozessorkern mit geringem Stromverbrauch. Der Grafikprozessor 2940 von 29B ist ein Beispiel für einen Grafikprozessorkern mit höherer Leistungsfähigkeit. Jeder der Grafikprozessoren 2910, 2940 kann Varianten des Grafikprozessors 2810 von 28 sein.
Wie in 29A gezeigt, beinhaltet der Grafikprozessor 2910 einen Vertex-Prozessor 2905 und einen oder mehrere Fragmentprozessoren 2915A-2915N (z. B. 2915A, 2915B, 2915C, 2915D bis 2915N-1 und 2915N). Der Grafikprozessor 2910 kann verschiedene Shader-Programme über separate Logik ausführen, sodass der Vertex-Prozessor 2905 zum Ausführen von Operationen für Vertex-Shader-Programme optimiert ist, während der eine oder die mehreren Fragment-Prozessor(en) 2915A-2915N Fragment(z. B. Pixel)-Shading-Operationen für Fragment- oder Pixel-Shader-Programme ausführen. Der Vertex-Prozessor 2905 führt die Vertex-Verarbeitungsstufe der 3D-Grafik-Pipeline aus und erzeugt Primitive und Vertex-Daten. Der/die Fragmentprozessor(en) 2915A-2915N verwendet/verwenden die durch den Vertex-Prozessor 2905 erzeugten Primitive und Vertex-Daten, um einen Frame-Puffer zu erzeugen, der auf einer Anzeigevorrichtung angezeigt wird. In einer Ausführungsform ist/sind der/die Fragment-Prozessor(en) 2915A-2915N dazu optimiert, Fragment-Shader-Programme, wie sie in der OpenGL-API bereitgestellt werden, auszuführen, die verwendet werden können, um ähnliche Operationen wie ein Pixel-Shader-Programm durchzuführen, wie es in der Direct-3D-API bereitgestellt wird.
Der Grafikprozessor 2910 enthält zusätzlich eine oder mehrere Speicher-Management-Einheiten (MMUs: Memory Management Units) 2920A-2920B, den/die Cache(s) 2925A-2925B und den/die Schaltung-Interconnect(s) 2930A-2930B. Die eine oder die mehreren MMU(s) 2920A-2920B stellen eine Abbildung von virtuellen auf physische Adressen für den Grafikprozessor 2910 bereit, einschließlich für den Vertex-Prozessor 2905 und/oder den/die Fragment-Prozessor(en) 2915A-2915N, die zusätzlich zu Vertex- oder Bild-/Texturdaten, die in dem einen oder den mehreren Caches 2925A-2925B gespeichert sind, Vertex- oder Bild-/Texturdaten referenzieren können, die im Speicher gespeichert sind. In einer Ausführungsform können die eine oder die mehreren MMU(s) 2920A-2920B mit anderen MMUs innerhalb des Systems synchronisiert werden, einschließlich einer oder mehrerer MMUs, die mit dem einen oder den mehreren Anwendungsprozessor(en) 2805, dem Bildprozessor 2815 und/oder dem Videoprozessor 2820 28 assoziiert sind, sodass jeder Prozessor 2805-2820 an einem gemeinsam genutzten oder vereinheitlichten virtuellen Speichersystem teilnehmen kann. Der eine oder die mehreren Schaltung-Interconnect(s) 2930A-2930B ermöglichen dem Grafikprozessor 2910 gemäß Ausführungsformen, sich mit anderen IP-Kernen innerhalb des SoC zu verbinden, entweder über einen internen Bus des SoC oder über eine direkte Verbindung.
Wie in 29B gezeigt, enthält der Grafikprozessor 2940 die eine oder mehrere MMU(s) 2920A-2920B, Cache(s) 2925A-2925B und Schaltung-Interconnect(s) 2930A-2930B des Grafikprozessors 2910 von 29A. Der Grafikprozessor 2940 beinhaltet einen oder mehrere Shader-Kerne 2955A-2955N (z. B. 2955A, 2955B, 2955C, 2955D, 2955E, 2955F, bis 2955N-1 und 2955N), was für eine vereinheitlichte Shader-Kernarchitektur sorgt, in der ein einzelner Kern oder Kerntyp alle Arten von programmierbarem Shader-Code ausführen kann, einschließlich Shader-Programmcode zur Implementierung von Vertex-Shadern, Fragment-Shadern und/oder Rechen-Shadern. Die genaue Anzahl vorhandener Shader-Kerne kann zwischen Ausführungsformen und Implementierungen variieren. Außerdem beinhaltet der Grafikprozessor 2940 einen Interkernaufgabenmanager 2945, der als ein Thread-Dispatcher zum Versenden von Ausführungs-Threads an einen oder mehrere Shader-Kerne 2955A-2955N und eine Kachelungseinheit 2958 zum Beschleunigen von Kacheloperationen für kachelbasiertes Rendering agiert, wobei die Rendering-Operationen für eine Szene in einen Bildraum unterteilt sind, um zum Beispiel lokale räumliche Kohärenz innerhalb einer Szene auszunutzen oder um die Verwendung von internen Caches zu optimieren.
Bei manchen Ausführungsformen beinhaltet eine Einrichtung Folgendes: einen Speicher zur Speicherung von Daten; und einen oder mehrere Prozessoren einschließlich einer Grafikverarbeitungseinheit (GPU) zum Verarbeiten von Daten, wobei die GPU mehrere GPU-Kacheln beinhaltet, wobei die Einrichtung, nachdem geometrische Daten jeder mehrerer Bildschirmkacheln zugewiesen wurden, die geometrischen Daten an die mehreren GPU-Kacheln übertragen soll.
Bei manchen Ausführungsformen werden die geometrischen Daten von einer verteilten Datenstruktur für die mehreren Bildschirmkacheln an eine kachelbasierte Speicherung der mehreren GPU-Kacheln übertragen.
Bei manchen Ausführungsformen sind die übertragenen geometrischen Daten lokal in den mehreren GPU-Kacheln zu verarbeiten.
Bei manchen Ausführungsformen beinhaltet die Einrichtung ferner eine Anzeige, wobei die Einrichtung ferner dazu ausgelegt ist, Daten von einer GPU-Kachel der mehreren GPU-Kacheln für die Anzeige abzurufen, ohne die Daten der mehreren GPU-Kacheln zu konsolidieren.
Bei manchen Ausführungsformen ist die Einrichtung zum Sammeln aller Dreiecke ausgelegt, die auf eine oder mehrere Bildschirmkacheln in einem einzigen Rendering-Durchlauf abgebildet werden.
Bei manchen Ausführungsformen beinhaltet die Einrichtung ferner einen Mesh-Shader zum Arbeiten mit den mehreren GPU-Kacheln, wobei der Mesh-Shader dazu ausgelegt ist, Daten von einer GPU-Kachel der mehreren GPU-Kacheln ohne Übertragung von Daten über GPU-Kacheln zu verarbeiten.
Bei manchen Ausführungsformen ist die Einrichtung zum Bereitstellen eines kachelbasierten Sofortmodus-Renderings (TBIMR) mit dem Mesh-Shader ausgelegt.
Bei manchen Ausführungsformen beinhaltet die Einrichtung ferner eine Stream-Out-Schaltung zum Auslesen von Mesh-Daten aus dem Mesh-Shader und Schreiben der Daten in einen Speicher in einer Struktur von Arrays zur Kompression der Mesh-Daten.
Bei manchen Ausführungsformen weisen ein oder mehrere nichtflüchtige computerlesbare Speicherungsmedien darauf gespeicherte ausführbare Computerprogrammanweisungen auf, die bei Ausführung durch einen oder mehrere Prozessoren, bewirken, dass der eine oder die mehreren Prozessoren Operationen durchführen, die Folgendes beinhalten: Zuweisen von geometrischen Daten für eine Grafikverarbeitung durch eine Grafikverarbeitungseinheit (GPU) zu mehreren Bildschirmkacheln, wobei die GPU mehrere GPU-Kacheln umfasst; und Übertragen der geometrischen Daten von den Bildschirmkacheln an die mehreren GPU-Kacheln der GPU.
Bei manchen Ausführungsformen werden die geometrischen Daten von einer verteilten Datenstruktur für die mehreren Bildschirmkacheln an eine kachelbasierte Speicherung der mehreren GPU-Kacheln übertragen.
Bei manchen Ausführungsformen beinhalten die Anweisungen ferner Anweisungen zum lokalen Verarbeiten der übertragenen geometrischen Daten in den mehreren GPU-Kacheln.
Bei manchen Ausführungsformen beinhalten die Anweisungen ferner Anweisungen zum Abrufen von Daten von einer GPU-Kachel der mehreren GPU-Kacheln für eine Anzeige, ohne die Daten der mehreren GPU-Kacheln zu konsolidieren.
Bei manchen Ausführungsformen beinhalten die Anweisungen ferner Anweisungen zum Sammeln aller Dreiecke, die auf eine oder mehrere Bildschirmkacheln in einem einzigen Rendering-Durchlauf abgebildet werden.
Bei manchen Ausführungsformen beinhalten die Anweisungen ferner Anweisungen zum Verarbeiten von Daten von einer GPU-Kachel der mehreren GPU-Kacheln unter Verwendung eines Mesh-Shaders ohne Übertragung von Daten über GPU-Kacheln.
Bei manchen Ausführungsformen beinhalten die Anweisungen ferner Anweisungen zum Bereitstellen eines kachelbasierten Sofortmodus-Renderings (TBIMR) mit dem Mesh-Shader.
Bei manchen Ausführungsformen beinhalten die Anweisungen ferner Anweisungen zum Auslesen von Mesh-Daten aus dem Mesh-Shader und Schreiben der Daten in einen Speicher in einer Struktur von Arrays zur Kompression der Mesh-Daten.
Bei manchen Ausführungsformen beinhaltet ein Verfahren Folgendes: Zuweisen von geometrischen Daten für eine Grafikverarbeitung durch eine Grafikverarbeitungseinheit (GPU) zu mehreren Bildschirmkacheln, wobei die GPU mehrere GPU-Kacheln umfasst; und Übertragen der geometrischen Daten von den Bildschirmkacheln an die mehreren GPU-Kacheln der GPU.
Bei manchen Ausführungsformen werden die geometrischen Daten von einer verteilten Datenstruktur für die mehreren Bildschirmkacheln an eine kachelbasierte Speicherung der mehreren GPU-Kacheln übertragen.
Bei manchen Ausführungsformen beinhaltet das Verfahren lokales Verarbeiten der übertragenen geometrischen Daten in den mehreren GPU-Kacheln.
Bei manchen Ausführungsformen beinhaltet das Verfahren Abrufen von Daten von einer GPU-Kachel der mehreren GPU-Kacheln für eine Anzeige, ohne die Daten der mehreren GPU-Kacheln zu konsolidieren.
Bei manchen Ausführungsformen beinhaltet das Verfahren Sammeln aller Dreiecke, die auf eine oder mehrere Bildschirmkacheln in einem einzigen Rendering-Durchlauf abgebildet werden.
Bei manchen Ausführungsformen beinhaltet das Verfahren Verarbeiten von Daten von einer GPU-Kachel der mehreren GPU-Kacheln unter Verwendung eines Mesh-Shaders ohne Übertragung von Daten über GPU-Kacheln.
Bei manchen Ausführungsformen beinhaltet das Verfahren Bereitstellen eines kachelbasierten Sofortmodus-Renderings (TBIMR) mit dem Mesh-Shader.
Bei manchen Ausführungsformen beinhaltet das Verfahren Auslesen von Mesh-Daten aus dem Mesh-Shader und Schreiben der Daten in einen Speicher in einer Struktur von Arrays zur Kompression der Mesh-Daten.
Bei manchen Ausführungsformen beinhaltet eine Einrichtung Folgendes: ein Mittel zum Zuweisen von geometrischen Daten für eine Grafikverarbeitung durch eine Grafikverarbeitungseinheit (GPU) zu mehreren Bildschirmkacheln, wobei die GPU mehrere GPU-Kacheln umfasst; und ein Mittel zum Übertragen der geometrischen Daten von den Bildschirmkacheln an die mehreren GPU-Kacheln der GPU.
Bei manchen Ausführungsformen werden die geometrischen Daten von einer verteilten Datenstruktur für die mehreren Bildschirmkacheln an eine kachelbasierte Speicherung der mehreren GPU-Kacheln übertragen.
Bei manchen Ausführungsformen beinhalten die Einrichtung ferner ein Mittel zum lokalen Verarbeiten der übertragenen geometrischen Daten in den mehreren GPU-Kacheln.
Bei manchen Ausführungsformen beinhalten die Einrichtung ferner ein Mittel zum Abrufen von Daten von einer GPU-Kachel der mehreren GPU-Kacheln für eine Anzeige, ohne die Daten der mehreren GPU-Kacheln zu konsolidieren.
Bei manchen Ausführungsformen beinhalten die Einrichtung ferner ein Mittel zum Sammeln aller Dreiecke, die auf eine oder mehrere Bildschirmkacheln in einem einzigen Rendering-Durchlauf abgebildet werden.
Bei manchen Ausführungsformen beinhalten die Einrichtung ferner ein Mittel zum Verarbeiten von Daten von einer GPU-Kachel der mehreren GPU-Kacheln unter Verwendung eines Mesh-Shaders ohne Übertragung von Daten über GPU-Kacheln.
Bei manchen Ausführungsformen beinhalten die Einrichtung ferner ein Mittel zum Bereitstellen eines kachelbasierten Sofortmodus-Renderings (TBIMR) mit dem Mesh-Shader.
Bei manchen Ausführungsformen beinhalten die Einrichtung ferner ein Mittel zum Auslesen von Mesh-Daten aus dem Mesh-Shader und Schreiben der Daten in einen Speicher in einer Struktur von Arrays zur Kompression der Mesh-Daten.
In der obigen Beschreibung werden zum Zweck der Erläuterung zahlreiche spezielle Einzelheiten dargelegt, um ein umfassendes Verständnis der beschriebenen Ausführungsformen bereitzustellen. Für den Fachmann ist jedoch offensichtlich, dass Ausführungsformen ohne manche dieser speziellen Details umgesetzt werden können. Bei anderen Fällen sind gut bekannte Strukturen und Einrichtungen in Blockdiagrammform gezeigt. Es kann eine Zwischenstruktur zwischen veranschaulichten Komponenten geben. Die hier beschriebenen oder veranschaulichten Komponenten können zusätzliche Eingänge oder Ausgänge aufweisen, die nicht veranschaulicht oder beschrieben sind.
Verschiedene Ausführungsformen können verschiedene Prozesse beinhalten. Diese Prozesse können durch Hardwarekomponenten durchgeführt werden oder können in Computerprogramm- oder maschinenausführbaren Anweisungen umgesetzt sein, die verwendet werden können, um zu bewirken, dass ein Mehrzweck- oder Spezialprozessor oder Logikschaltungen, die mit den Anweisungen programmiert sind, die Prozesse durchführen.
Alternativ dazu können die Prozesse durch eine Kombination von Hardware und Software durchgeführt werden.
Teile verschiedener Ausführungsformen können als Computerprogrammprodukt bereitgestellt sein, das ein computerlesbares Medium mit darauf gespeicherten Computerprogrammanweisungen beinhalten kann, die verwendet werden können, um einen Computer (oder andere elektronische Vorrichtungen) zur Ausführung durch einen oder mehrere Prozessoren zu programmieren, um einen Prozess gemäß bestimmten Ausführungsformen durchzuführen. Zu dem computerlesbaren Medium können unter anderem magnetische Platten, optische Platten, Nur-Lese-Speicher (ROM), Direktzugriffspeicher (RAM), EPROM (Erasable Programmable Read Only Memories: löschbarer programmierbarer Nurlesespeicher), EEPROM (Electrically Erasable Programmable Read Only Memories: elektrisch löschbarer programmierbarer Nurlesespeicher), magnetische oder optische Karten, Flash-Speicher oder eine andere Art von computerlesbaren Medien, die zum Speichern von elektronischen Anweisungen geeignet sind, zählen. Darüber hinaus können Ausführungsformen auch als Computerprogrammprodukt heruntergeladen werden, wobei das Programm von einem entfernten Computer zu einem anfordernden Computer übertragen werden kann. Bei manchen Ausführungsformen sind auf einem nichtflüchtigen computerlesbaren Speichermedium Daten gespeichert, die Anweisungssequenzen darstellen, die, wenn sie durch einen Prozessor ausgeführt werden, bewirken, dass der Prozessor bestimmte Operationen durchführt.
Viele der Verfahren werden in ihrer grundlegendsten Form beschrieben, aber Prozesse können zu jedem der Verfahren hinzugefügt oder daraus gelöscht werden, und Informationen können zu jeder der beschriebenen Nachrichten hinzugefügt oder daraus entfernt werden, ohne vom grundlegenden Schutzumfang der vorliegenden Ausführungsformen abzuweichen. Für Fachleute versteht sich, dass viele weitere Modifikationen und Anpassungen vorgenommen werden können. Die speziellen Ausführungsformen werden nicht bereitgestellt, um das Konzept einzuschränken, sondern um es zu veranschaulichen. Der Schutzumfang der Ausführungsformen soll nicht durch die oben bereitgestellten speziellen Beispiele bestimmt werden, sondern nur durch die unten aufgeführten Ansprüche.
Wenn gesagt wird, dass ein Element „A“ an oder mit Element „B“ gekoppelt ist, kann Element A direkt oder indirekt über beispielsweise Element C an Element B gekoppelt sein. Wenn in der Beschreibung oder den Ansprüchen angegeben ist, dass eine Komponente, ein Merkmal, eine Struktur, ein Prozess oder eine Charakteristik A eine Komponente, ein Merkmal, eine Struktur, einen Prozess oder eine Charakteristik B „verursacht“, bedeutet dies, dass „A“ zumindest eine Teilursache von „B“ ist, es aber auch mindestens eine andere Komponente, Merkmal, Struktur, Prozess oder Charakteristik geben kann, die dazu beiträgt, „B“ zu verursachen. Wenn die Beschreibung angibt, dass eine Komponente, ein Merkmal, eine Struktur oder eine Charakteristik enthalten sein „kann“ oder „könnte“, muss die spezielle Komponente, das spezielle Merkmal, die spezielle Struktur oder die spezielle Charakteristik nicht notwendigerweise enthalten sein. Wenn sich die Beschreibung oder der Anspruch auf „ein“ Element bezieht, bedeutet dies nicht, dass nur eines der Elemente vorhanden ist.
Eine Ausführungsform ist eine Implementierung oder ein Beispiel. In der Beschreibung bedeutet ein Bezug auf „eine Ausführungsform“, „manche Ausführungsformen“ oder „andere Ausführungsformen“, dass ein spezielles Merkmal, eine spezielle Struktur oder eine spezielle Charakteristik, das bzw. die in Verbindung mit den Ausführungsformen beschrieben wird, in zumindest manchen Ausführungsformen, aber nicht zwangsweise allen Ausführungsformen enthalten ist. Die verschiedenen Vorkommnisse von „einer Ausführungsform“ oder „manchen Ausführungsformen“ beziehen sich nicht immer notwendigerweise auf dieselben Ausführungsformen. Es versteht sich, dass in der vorstehenden Beschreibung beispielhafter Ausführungsformen verschiedene Merkmale mitunter in einer einzigen Ausführungsform, Figur oder Beschreibung davon zusammengefasst sind, um die Offenbarung zu straffen und zum Verständnis eines oder mehrerer der verschiedenen neuartigen Aspekte beizutragen. Diese Art der Offenbarung darf jedoch nicht als eine Absicht wiedergebend ausgelegt werden, dass die beanspruchten Ausführungsformen mehr Merkmale als ausdrücklich in jedem Anspruch erwähnt erfordern. Vielmehr liegen, wie in den folgenden Ansprüchen wiedergegeben, neuartige Aspekte in weniger als allen Merkmalen einer einzelnen offenbarten Ausführungsform. Somit werden die Ansprüche hiermit ausdrücklich in diese Beschreibung aufgenommen, wobei jeder Anspruch für sich allein als separate Ausführungsform steht.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 16/355364 [0001]

Claims

Einrichtung, die Folgendes umfasst: einen Speicher zur Speicherung von Daten; und einen oder mehrere Prozessoren einschließlich einer Grafikverarbeitungseinheit (GPU) zum Verarbeiten von Daten, wobei die GPU mehrere GPU-Kacheln beinhaltet; wobei die Einrichtung, nachdem geometrische Daten jeder mehrerer Bildschirmkacheln zugewiesen wurden, die geometrischen Daten an die mehreren GPU-Kacheln übertragen soll.
Einrichtung nach Anspruch 1, wobei die geometrischen Daten von einer verteilten Datenstruktur für die mehreren Bildschirmkacheln an eine kachelbasierte Speicherung der mehreren GPU-Kacheln übertragen werden.
Einrichtung nach Anspruch 2, wobei die übertragenen geometrischen Daten lokal in den mehreren GPU-Kacheln zu verarbeiten sind.
Einrichtung nach Anspruch 1, die ferner eine Anzeige umfasst, wobei die Einrichtung ferner dazu ausgelegt ist, Daten von einer GPU-Kachel der mehreren GPU-Kacheln für die Anzeige abzurufen, ohne die Daten der mehreren GPU-Kacheln zu konsolidieren.
Einrichtung nach Anspruch 1, wobei die Einrichtung zum Sammeln aller Dreiecke ausgelegt ist, die auf eine oder mehrere Bildschirmkacheln in einem einzigen Rendering-Durchlauf abgebildet werden.
Einrichtung nach Anspruch 1, die ferner einen Mesh-Shader zum Arbeiten mit den mehreren GPU-Kacheln umfasst, wobei der Mesh-Shader dazu ausgelegt ist, Daten von einer GPU-Kachel der mehreren GPU-Kacheln ohne Übertragung von Daten über GPU-Kacheln zu verarbeiten.
Einrichtung nach Anspruch 6, wobei die Einrichtung zum Bereitstellen eines kachelbasierten Sofortmodus-Renderings (TBIMR) mit dem Mesh-Shader ausgelegt ist.
Einrichtung nach Anspruch 6, die ferner eine Stream-Out-Schaltung zum Auslesen von Mesh-Daten aus dem Mesh-Shader und Schreiben der Daten in einen Speicher in einer Struktur von Arrays zur Kompression der Mesh-Daten umfasst.
Nichtflüchtiges computerlesbares Speicherungsmedium oder nichtflüchtige computerlesbare Speicherungsmedien mit darauf gespeicherten ausführbaren Computerprogrammanweisungen, die bei Ausführung durch einen oder mehrere Prozessoren, bewirken, dass der eine oder die mehreren Prozessoren Operationen durchführen, die Folgendes umfassen: Zuweisen von geometrischen Daten für eine Grafikverarbeitung durch eine Grafikverarbeitungseinheit (GPU) zu mehreren Bildschirmkacheln, wobei die GPU mehrere GPU-Kacheln umfasst; und Übertragen der geometrischen Daten von den Bildschirmkacheln an die mehreren GPU-Kacheln der GPU.
Computerlesbares Speicherungsmedium oder computerlesbare Speicherungsmedien nach Anspruch 9, wobei die geometrischen Daten von einer verteilten Datenstruktur für die mehreren Bildschirmkacheln an eine kachelbasierte Speicherung der mehreren GPU-Kacheln übertragen werden.
Computerlesbares Speicherungsmedium oder computerlesbare Speicherungsmedien nach Anspruch 10, das/die ferner Anweisungen zum lokalen Verarbeiten der übertragenen geometrischen Daten in den mehreren GPU-Kacheln umfasst/umfassen.
Computerlesbares Speicherungsmedium oder computerlesbare Speicherungsmedien nach Anspruch 9, das/die ferner Anweisungen zum Abrufen von Daten von einer GPU-Kachel der mehreren GPU-Kacheln für eine Anzeige umfasst/umfassen, ohne die Daten der mehreren GPU-Kacheln zu konsolidieren.
Computerlesbares Speicherungsmedium oder computerlesbare Speicherungsmedien nach Anspruch 9, das/die ferner Anweisungen zum Sammeln aller Dreiecke umfasst/umfassen, die auf eine oder mehrere Bildschirmkacheln in einem einzigen Rendering-Durchlauf abgebildet werden.
Computerlesbares Speicherungsmedium oder computerlesbare Speicherungsmedien nach Anspruch 9, das/die ferner Anweisungen zum Verarbeiten von Daten von einer GPU-Kachel der mehreren GPU-Kacheln unter Verwendung eines Mesh-Shaders ohne Übertragung von Daten über GPU-Kacheln umfasst/umfassen.
Computerlesbares Speicherungsmedium oder computerlesbare Speicherungsmedien nach Anspruch 14, das/die ferner Anweisungen zum Bereitstellen eines kachelbasierten Sofortmodus-Renderings (TBIMR) mit dem Mesh-Shader umfasst/umfassen.
Computerlesbares Speicherungsmedium oder computerlesbare Speicherungsmedien nach Anspruch 14, das/die ferner Anweisungen zum Auslesen von Mesh-Daten aus dem Mesh-Shader und Schreiben der Daten in einen Speicher in einer Struktur von Arrays zur Kompression der Mesh-Daten umfasst/umfassen.
Verfahren, das Folgendes umfasst: Zuweisen von geometrischen Daten für eine Grafikverarbeitung durch eine Grafikverarbeitungseinheit (GPU) zu mehreren Bildschirmkacheln, wobei die GPU mehrere GPU-Kacheln umfasst; und Übertragen der geometrischen Daten von den Bildschirmkacheln an die mehreren GPU-Kacheln der GPU.
Verfahren nach Anspruch 17, wobei die geometrischen Daten von einer verteilten Datenstruktur für die mehreren Bildschirmkacheln an eine kachelbasierte Speicherung der mehreren GPU-Kacheln übertragen werden.
Verfahren nach Anspruch 18, das ferner lokales Verarbeiten der übertragenen geometrischen Daten in den mehreren GPU-Kacheln umfasst.
Verfahren nach Anspruch 17, das ferner Anweisungen zum Abrufen von Daten von einer GPU-Kachel der mehreren GPU-Kacheln für eine Anzeige umfasst, ohne die Daten der mehreren GPU-Kacheln zu konsolidieren.