DE102019101118A1

DE102019101118A1 - Anweisung und Logik für systolisches Skalarprodukt mit Akkumulation

Info

Publication number: DE102019101118A1
Application number: DE102019101118.3A
Authority: DE
Inventors: Ashutosh Garg; Chandra S. Gurram; Guei-Yuan Lueh; Jorge E. Parra; Junjie Gu; Konrad TRIFUNOVIC; Mike B. MacPherson; Shubh B. Shah; Shubra Marwaha; Stephen Junkins; Subramaniam Maiyuran; Supratim Pal; Timothy R. Bauer; Varghese George; WeiYu Chen; Hong Bin Liao
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2018-04-19
Filing date: 2019-01-17
Publication date: 2019-10-24
Also published as: US20210303299A1; CN110389783A; US20230297373A1; US11640297B2; US11042370B2; US20190324746A1

Abstract

Die hierin beschriebenen Ausführungsformen stellen bereit, dass eine Anweisung und die zugeordnete Logik GPGPU-Programmcode ermöglichen, auf Spezial-Hardwarelogik zuzugreifen, um Skalarproduktoperationen zu beschleunigen. Eine Ausführungsform stellt eine Grafikverarbeitungseinheit bereit, die eine Abrufeinheit zum Abrufen einer Anweisung zur Ausführung und eine Entschlüsselungseinheit zum Entschlüsseln der Anweisung in eine entschlüsselte Anweisung umfasst. Die entschlüsselte Anweisung ist ein Matrixanweisung, um die Grafikprozessoreinheit zu veranlassen, eine parallele Skalarproduktoperation durchzuführen. Die GPGPU umfasst auch eine systolische Skalarprodukteinheit zum Ausführen der entschlüsselten Anweisung in einer oder mehreren SIMD-Spuren unter Verwendung mehrerer systolischer Schichten, wobei zum Ausführen der entschlüsselten Anweisung ein auf einer ersten systolischen Schicht berechnetes Skalarprodukt an eine zweite systolische Schicht ausgegeben werden soll, wobei jede systolische Schicht einen oder mehrere Sätze von miteinander verbundenen Multiplizierern und Addierern umfasst, wobei jeder Satz von Multiplizierern und Addierern dazu dient, ein Skalarprodukt zu erzeugen.

Description

HINTERGRUND
Ein Modell eines neuronalen Netzwerks kann als Ansammlung von Neuronen dargestellt werden, die in einem azyklischen Diagramm verbunden sind. Ein neuronales Netzwerk kann eine Eingabe (einen Einzelvektor) empfangen und sie über eine Reihe verdeckter Schichten umwandeln. Jede verdeckte Schicht besteht aus einem Satz von Neuronen, wobei jedes Neuron vollständig mit allen Neuronen in der vorhergehenden Schicht verbunden ist und wobei Neuronen in einer einzelnen Schicht vollständig unabhängig funktionieren und keine Verbindungen miteinander aufweisen. Ein konvolutionelles neuronales Netzwerk (CNN) ist einem herkömmlichen neuronalen Netzwerk ähnlich. Jedes Neuron empfängt Eingaben, führt ein Skalarprodukt aus, worauf gegebenenfalls eine NichtLinearität folgt. Ein CNN ist jedoch ausdrücklich darauf ausgelegt, eingegebene Bilddaten zu bearbeiten. Auf Grundlage von der Eingabe von Rohbilddaten gibt das Netzwerk für die Eingabedaten eine Klassifikationswertung aus.
Ein paralleles Datenverarbeitungssystem, das konfiguriert ist, um neuronale Netzwerkverarbeitung durchzuführen, kann einen Grafikprozessor umfassen, der konfiguriert sein kann, um spezifische Operationen in Bezug auf Grafikdaten durchzuführen, wie z.B. lineare Interpolation, Tesselation, Rasterisierung, Texturmapping, Tiefentests usw. Teile von Grafikprozessoren können programmierbar gemacht werden, so dass solche Prozessoren eine große Vielfalt an Operationen für die Verarbeitung von Vertex- und Fragmentdaten unterstützen können. Vollständig programmierbare Ausführungseinheiten innerhalb eines Grafikprozessors können genutzt werden, um verschiedene parallele Verarbeitungsoperationen durchzuführen. Zur Maximierung des Durchsatzes können Grafikprozessoren einige Operationen jedoch unter Verwendung spezialisierter Logikeinheiten mit fixer Funktion durchführen.
Figurenliste
Damit die Merkmale der vorliegenden Erfindung im Detail verstanden werden, steht eine ausführlichere Beschreibung unter Bezugnahme auf Ausführungsformen zur Verfügung, von welchen einige in den beigefügten Zeichnungen veranschaulicht sind. Es ist jedoch zu beachten, dass die beigefügten Zeichnungen nur typische Ausführungsformen darstellen und daher nicht als Einschränkung des Umfangs aller Ausführungsformen zu verstehen sind.

1 ist ein Blockdiagramm eines Verarbeitungssystems gemäß einer Ausführungsform;
2 ist ein Blockdiagramm eines Prozessors gemäß einer Ausführungsform;
3 ist ein Blockdiagramm eines Grafikprozessors gemäß einer Ausführungsform;
4 ist ein Blockdiagramm eines Grafikverarbeitungsengines eines Grafikprozessors gemäß einigen Ausführungsformen;
5 ist ein Blockdiagramm einer Hardwarelogik eines Grafikprozessorkerns gemäß einigen hierin beschriebenen Ausführungsformen;
6A-6B veranschaulichen die Thread-Ausführungslogik, die ein Array von Verarbeitungselementen umfasst, die in einem Grafikprozessorkern gemäß den hierin beschriebenen Ausführungsformen verwendet werden;
7 ist ein Blockdiagramm, das Grafikprozessoranweisungsformate gemäß einigen Ausführungsformen veranschaulicht;
8 ist ein Blockdiagramm eines Grafikprozessors gemäß einer weiteren Ausführungsform;
9A-9B veranschaulichen ein Grafikprozessor-Anweisungsformat und eine Befehlssequenz gemäß einigen Ausführungsformen;
10 veranschaulicht ein Beispiel für eine Grafiksoftwarearchitektur für ein Datenverarbeitungssystem gemäß einigen Ausführungsformen;
11A ist ein Blockdiagramm, das ein IP-Kernentwicklungssystem gemäß einer Ausführungsform veranschaulicht;
11B veranschaulicht eine Querschnittsseitenansicht einer integrierten Schaltungsgehäuseanordnung gemäß einigen hierin beschriebenen Ausführungsformen;
12 ist ein Blockdiagramm, das ein Beispiel einer integrierten System-on-a-Chip-Schaltung gemäß einer Ausführungsform veranschaulicht;
13A-13B sind Blockdiagramme, die Beispiele für Grafikprozessoren zur Verwendung in einem SoC gemäß den hierin beschriebenen Ausführungsformen veranschaulichen;
14A-14B veranschaulichen ein zusätzliches Beispiel für eine Grafikprozessorlogik gemäß den hierin beschriebenen Ausführungsformen;
15 ist ein Blockdiagramm eines Datenverarbeitungssystems gemäß einer Ausführungsform;
16 veranschaulicht eine Matrixoperation, die von einer Anweisungs-Pipeline gemäß einer Ausführungsform durchgeführt wird;
17A-17B veranschaulichen Details einer hardwarebasierten Skalarproduktlogik gemäß einigen Ausführungsformen;
18A-18B veranschaulichen eine Anweisung, der von der Skalarproduktlogik gemäß den hierin beschriebenen Ausführungsformen ausgeführt werden kann;
19 veranschaulicht einen Programmcodekompilierungsprozess gemäß einer Ausführungsform;
20 veranschaulicht einen Prozess zum Ausführen einer Skalarproduktanweisung innerhalb einer Anweisungsausführungs-Pipeline gemäß den hierin beschriebenen Ausführungsformen;
21 veranschaulicht ein Verfahren, durch das Hardwarelogik einer Funktionseinheit eine Anweisung ausführen kann, um ein systolisches Skalarprodukt mit einem Akkumulator gemäß einer Ausführungsform durchzuführen; und
22 ist ein Blockdiagramm einer Rechenvorrichtung gemäß hierin beschriebenen Ausführungsformen.

BESCHREIBUNG VON AUSFÜHRUNGSFORMEN
Bestehende Grafik- und Rechen-Shader-Programme können zur Durchführung von Operationen unter Verwendung von Anweisungen kompiliert werden, die auf universellen Grafikausführungseinheiten innerhalb einer universellen Grafikverarbeitungseinheit (GPGPU) ausgeführt werden. Für einige spezialisierte Operationen, wie z.B. für maschinelles Lernen spezifische Operationen, können universelle Ausführungseinheiten innerhalb einer GPGPU durch eine spezielle Hardwarelogik erweitert werden, um bestimmte Operationen zu beschleunigen. Die hierin beschriebenen Ausführungsformen stellen bereit, dass eine Anweisung und die zugeordnete Logik ermöglichen, dass auf GPGPU-Ausführung ausgerichteter Programmcode auf Spezial-Hardwarelogik zugreift, um Skalarproduktoperationen zu beschleunigen.
Zur Erläuterung sind zahlreiche spezifische Details angeführt, um ein umfassendes Verständnis der verschiedenen nachstehend beschriebenen Ausführungsformen zu ermöglichen. Fachleuten auf dem Gebiet der Erfindung ist jedoch klar, dass die Ausführungsformen ohne einige dieser spezifischen Details ausgeführt werden können. In anderen Fällen werden bekannte Strukturen und Vorrichtungen in Blockdiagrammform dargestellt, um die zugrunde liegenden Prinzipien klar darzulegen und ein umfassenderes Verständnis der Ausführungsformen bereitzustellen. Obwohl einige der folgenden Ausführungsformen unter Bezugnahme auf einen Grafikprozessor beschrieben sind, können die hierin beschriebenen Verfahren und Lehren auf verschiedene Arten von Schaltungen oder Halbleitervorrichtungen angewendet werden, einschließlich universelle Verarbeitungsvorrichtungen oder Grafikverarbeitungsvorrichtungen. Die Bezugnahme auf „eine Ausführungsform“ bedeutet, dass das jeweilige Merkmal, die jeweilige Struktur oder die jeweilige Eigenschaft, das/die in Verbindung mit der Ausführungsform beschrieben ist, Teil von zumindest einer solcher Ausführungsformen sein kann. Die Vorkommen des Ausdrucks „in einer Ausführungsform“ an verschiedenen Stellen in der Beschreibung beziehen sich jedoch nicht unbedingt auf dieselbe Ausführungsform.
In der nachstehenden Beschreibung und den nachstehenden Ansprüchen können die Begriffe „gekoppelt“ und „verbunden“ sowie deren Ableitungen verwendet werden. Es sollte klar sein, dass diese Begriffe nicht synonym verwendet werden. „Gekoppelt“ wird verwendet, um anzugeben, dass zwei oder mehr Elemente, die in direktem physischem oder elektrischem Kontakt miteinander stehen können oder nicht, zusammenwirken oder miteinander interagieren. „Verbunden“ wird verwendet, um die Herstellung von Kommunikation zwischen zwei oder mehr Elementen anzuzeigen, die miteinander gekoppelt sind.
In der nachstehenden Beschreibung stellen die 1 bis 14 einen Überblick über beispielhafte Datenverarbeitungssysteme und Grafikprozessorlogiken bereit, die die verschiedenen Ausführungsformen beinhalten oder sich auf diese beziehen. Die 15 bis 22 stellen spezifische Details zu den verschiedenen Ausführungsformen bereit. Einige Aspekte der nachstehenden Ausführungsformen sind mit Bezug auf einen Grafikprozessor beschrieben, während andere Aspekte mit Bezug auf einen Universalprozessor, wie beispielsweise eine zentrale Verarbeitungseinheit (CPU), beschrieben werden. Ähnliche Verfahren und Lehren können auf andere Arten von Schaltungen oder Halbleitervorrichtungen angewendet werden, einschließlich, aber nicht beschränkt auf einen Prozessor mit vielen integrierten Kernen, einen GPU-Cluster oder eine oder mehrere Instanzen eines feldprogrammierbaren Gate-Arrays (FPGA). Im Allgemeinen gelten die Lehren für jeden Prozessor oder jede Maschine, die Bilder (z.B. Muster, Pixel), Vertex-Daten oder Geometriedaten manipuliert oder verarbeitet.
Systemübersicht
1 ist ein Blockdiagramm eines Verarbeitungssystems 100 gemäß einer Ausführungsform. In verschiedenen Ausführungsformen umfasst das System 100 einen oder mehrere Prozessoren 102 und einen oder mehrere Grafikprozessoren 108 und kann ein Desktop-System mit einem einzelnen Prozessor, ein Multiprozessor-Workstation-System oder ein Serversystem mit einer großen Anzahl von Prozessoren 102 oder Prozessorkernen 107 sein. In einer Ausführungsform ist das System 100 eine Verarbeitungsplattform, die in eine integrierte System-on-a-Chip- (SoC-) Schaltung zur Verwendung in mobilen, Handheld- oder eingebetteten Vorrichtungen integriert ist.
In einer Ausführungsform kann das System 100 eine serverbasierte Spieleplattform, eine Spielekonsole, einschließlich eine Spiel- und Medienkonsole, eine mobile Spielekonsole, eine Handheld-Spielekonsole oder eine Online-Spielekonsole, umfassen oder in diese integriert sein. In manchen Ausführungsformen ist das System 100 ein Mobiltelefon, ein Smartphone, eine Tablet-Rechenvorrichtung oder eine mobile Internetvorrichtung. Das Verarbeitungssystem 100 kann auch eine tragbare Vorrichtung, wie z.B. eine tragbare Smart-Watch-Vorrichtung, eine smarte Brillenvorrichtung, eine Augmented-Reality-Vorrichtung oder eine Virtual-Reality-Vorrichtung, umfassen, mit dieser gekoppelt oder in diese integriert sein. In einigen Ausführungsformen ist das Verarbeitungssystem 100 eine TV- oder Set-Top-Box-Vorrichtung mit einem oder mehreren Prozessoren 102 und einer von einem oder mehreren Grafikprozessoren 108 generierten grafischen Schnittstelle.
In einigen Ausführungsformen umfasst der eine Prozessor 102/umfassen die mehreren Prozessoren 102 jeweils einen oder mehrere Prozessorkerne 107 zur Verarbeitung von Anweisungen, die, wenn sie ausgeführt werden, Operationen für System- und Benutzersoftware ausführen. In einigen Ausführungsformen ist jeder der einen oder mehreren Prozessorkerne 107 konfiguriert, um einen spezifischen Anweisungssatz 109 zu verarbeiten. In einigen Ausführungsformen kann der Anweisungssatz 109 Complex Instruction Set Computing (CISC), Reduced Instruction Set Computing (RISC) oder das Rechnen über ein Very Long Instruction Word (VLIW) ermöglichen. Mehrere Prozessorkerne 107 können jeweils einen anderen Anweisungssatz 109 verarbeiten, der Anweisungen umfassen kann, um die Emulation anderer Anweisungssätze zu ermöglichen. Der Prozessorkern 107 kann auch andere Verarbeitungsvorrichtungen umfassen, wie z.B. einen digitalen Signalprozessor (DSP).
In einigen Ausführungsformen umfasst der Prozessor 102 den Cache-Speicher 104. Je nach Architektur kann der Prozessor 102 einen einzelnen internen Cache oder mehrere Ebenen eines internen Cache aufweisen. In einigen Ausführungsformen ist der Cache-Speicher zwischen verschiedenen Komponenten des Prozessors 102 geteilt. In einigen Ausführungsformen verwendet der Prozessor 102 auch einen externen Cache (z.B. einen Level-3- (L3-) Cache oder Last-Level-Cache (LLC)) (nicht dargestellt), der unter Verwendung bekannter Cache-Kohärenztechniken unter den Prozessorkernen 107 geteilt werden kann. Zusätzlich dazu ist eine Registerdatei 106 im Prozessor 102 enthalten, die verschiedenen Arten von Registern zum Speichern verschiedener Datentypen umfassen kann (z.B. Ganzzahlregister, Gleitkommaregister, Statusregister und ein Anweisungszeigerregister). Einige Register können Universalregister sein, während andere Register spezifisch für das Design des Prozessors 102 sein können.
In einigen Ausführungsformen ist ein Prozessor 102/sind mehrere Prozessoren 102 mit einem oder mehreren Schnittstellenbus(sen) 110 gekoppelt, um Kommunikationssignale, wie z.B. Adressen, Daten oder Steuersignale zwischen dem Prozessor 102 und anderen Komponenten in dem System 100 zu übertragen. Der Schnittstellenbus 110 kann in einer Ausführungsform ein Prozessorbus sein, wie z.B. eine Version des Direct-Media-Interface-(DMI-) Bus. Prozessorbusse sind jedoch nicht auf den DMI-Bus beschränkt und können einen oder mehrere Peripheriekomponenten-Verbindungsbusse (z.B. PCI, PCI Express), Speicherbusse oder andere Arten von Schnittstellenbussen einschließen. In einer Ausführungsform schließt der Prozessor 102/schließen die Prozessoren 102 eine integrierte Speichersteuerungsvorrichtung 116 und einen Plattformsteuerungsvorrichtungshub 130 ein. Die Speichersteuerungsvorrichtung 116 ermöglicht die Kommunikation zwischen einer Speichervorrichtung und anderen Komponenten des Systems 100, während der Plattformsteuerungsvorrichtungshub (Platform Controller Hub, PCH) 130 Verbindungen zu I/O-Geräten über einen lokalen I/O-Bus bereitstellt.
Die Speichervorrichtung 120 kann eine dynamische Random-Access-Memory-(DRAM-) Vorrichtung, eine statische Random-Access-Memory- (SRAM-) Vorrichtung, eine Flash-Speichervorrichtung, eine Phasenänderungsspeichervorrichtung oder eine andere Speichervorrichtung mit geeigneter Leistung sein, um als Prozessspeicher zu dienen. In einer Ausführungsform kann die Speichervorrichtung 120 als Systemspeicher für das System 100 dienen, um Daten 122 und Anweisungen 121 zu speichern, die verwendet werden, wenn der eine Prozessor 102 oder die mehreren Prozessoren 102 eine Anwendung oder einen Prozess ausführt/ausführen. Die Speichersteuerungsvorrichtung 116 wird auch mit einem optionalen externen Grafikprozessor 112 gekoppelt, der mit einem oder mehreren Grafikprozessoren 108 in Prozessoren 102 kommunizieren kann, um Grafik- und Medienoperationen durchzuführen. In einigen Ausführungsformen kann eine Anzeigevorrichtung 111 mit dem/den Prozessor/en 102 verbunden werden. Die Anzeigevorrichtung 111 kann eine oder mehrere von einer internen Anzeigevorrichtung, wie in einer mobilen elektronischen Vorrichtung oder einer Laptopvorrichtung, oder einer externen Anzeigevorrichtung sein, die über eine Anzeigeschnittstelle (z.B. DisplayPort usw.) verbunden ist. In einer Ausführungsform kann die Anzeigevorrichtung 111 ein Datenhelm (Head-Mounted Display, HMD) sein, wie z.B. eine stereoskopische Anzeigevorrichtung für den Einsatz in Virtual-Reality- (VR-) Anwendungen oder Augmented-Reality- (AR-) Anwendungen.
In einigen Ausführungsformen ermöglicht der Plattformsteuerungsvorrichtungshub 130 die Verbindung von Peripheriegeräten mit der Speichervorrichtung 120 und dem Prozessor 102 über einen Hochgeschwindigkeits-I/O-Bus. Die I/O-Peripheriegeräte umfassen, ohne auf diese beschränkt zu sein, eine Audiosteuerungsvorrichtung 146, eine Netzwerksteuerungsvorrichtung 134, eine Firmware-Schnittstelle 128, einen Drahtlos-Sender-Empfänger 126, Berührungssensoren 125, eine Datenspeichervorrichtung 124 (z.B. Festplattenlaufwerk, Flash-Speicher usw.). Die Datenspeichervorrichtung 124 kann über eine Speicherschnittstelle (z.B. SATA) oder über einen Peripheriebus, wie z.B. einen Peripheral-Component-Interconnect-Bus (z.B. PCI, PCI-Express), verbunden werden. Die Berührungssensoren 125 können Touchscreen-Sensoren, Drucksensoren oder Fingerabdrucksensoren einschließen. Der Drahtlos-Sender-Empfänger 126 kann ein WiFi-Sender-Empfänger, ein Bluetooth-Sender-Empfänger oder ein Mobilfunk-Sender-Empfänger wie ein 3G-, 4G- oder Long-Term-Evolution- (LTE-) Sender-Empfänger sein. Die Firmware-Schnittstelle 128 ermöglicht die Kommunikation mit der System-Firmware und kann beispielsweise eine einheitliche erweiterbare Firmware-Schnittstelle (UEFI) sein. Die Netzwerksteuerungsvorrichtung 134 kann eine Netzwerkverbindung zu einem drahtgebundenen Netzwerk aktivieren. In einigen Ausführungsformen wird eine leistungsstarke Netzwerksteuerungsvorrichtung (nicht dargestellt) mit dem Schnittstellenbus 110 gekoppelt. Die Audiosteuerungsvorrichtung 146 ist in einer Ausführungsform eine mehrkanalige, hochauflösende Audiosteuerungsvorrichtung. In einer Ausführungsform umfasst das System 100 eine optionale Legacy-I/O-Steuerungsvorrichtung 140 zur Kopplung von Legacy-Geräten (z.B. Personal System 2 (PS/2)) an das System. Der Plattformsteuerungsvorrichtungshub 130 kann auch an eine oder mehrere Universal-Serial-Bus- (USB-) Steuerungsvorrichtungen 142 angeschlossen werden, die Eingabevorrichtungen wie Kombinationen von Tastatur und Maus 143, eine Kamera 144 oder andere USB-Eingabegeräte anschließen.
Es ist zu beachten, dass das dargestellte System 100 ein Beispiel darstellt und nicht einschränkend ist, da auch andere Arten von Datenverarbeitungssystemen verwendet werden können, die anders konfiguriert sind. So kann beispielsweise eine Instanz der Speichersteuerungsvorrichtung 116 und des Plattformsteuerungsvorrichtungshubs 130 in einen diskreten externen Grafikprozessor, wie beispielsweise den externen Grafikprozessor 112, integriert werden. In einer Ausführungsform kann der Plattformsteuerungsvorrichtungshub 130 und/oder die Speichersteuerungsvorrichtung 160 extern in Bezug auf einen oder mehrere Prozessoren 102 vorliegen. Beispielsweise kann das System 100 eine externe Speichersteuerungsvorrichtung 116 und einen Plattformsteuerungsvorrichtungshub 130 umfassen, die als Speichersteuerungsvorrichtungshub und Peripheriegerätesteuerungsvorrichtungshub innerhalb eines System-Chipsatzes konfiguriert werden können, der mit dem/den Prozessor/en 102 in Kommunikation steht.
2 ist ein Blockdiagramm einer Ausführungsform eines Prozessors 200 mit einem oder mehreren Prozessorkernen 202A-202N, einer integrierten Speichersteuerungsvorrichtung und einem integrierten Grafikprozessor 208. Jene Elemente aus 2, die dieselben Bezugszeichen (oder Bezeichnungen) aufweisen wie die Elemente in irgendeiner anderen Figur, können in ähnlicher Weise wie an anderer Stelle hierin beschrieben betrieben werden oder funktionieren, sind aber nicht darauf beschränkt. Der Prozessor 200 kann zusätzliche Kerne bis hin zu und einschließlich des zusätzlichen Kerns 202N umfassen, die durch die gestrichelten Kästchen dargestellt sind. Jeder der Prozessorkerne 202A-202N umfasst eine oder mehrere interne Cache-Einheiten 204A-204N. In einigen Ausführungsformen hat auch jeder Prozessorkern Zugriff auf eine oder mehrere gemeinsam genutzte Cache-Einheiten 206.
Die internen Cache-Einheiten 204A-204N und die gemeinsam genutzten Cache-Einheiten 206 stellen eine Cache-Speicherhierarchie innerhalb des Prozessors 200 dar. Die Cache-Speicherhierarchie kann zumindest eine Ebene des Anweisungs- und Daten-Cache innerhalb jedes Prozessorkerns und eine oder mehrere Ebenen eines gemeinsam genutzten Mid-Level-Cache-Speichers umfassen, wie z.B. eine Ebene 2 (L2), Ebene 3 (L3), Ebene 4 (L4) oder andere Cache-Ebenen, wobei die höchste Cache-Ebene vor dem externen Speicher als LLC klassifiziert ist. In einigen Ausführungsformen gewährleistet die Cache-Kohärenzlogik die Kohärenz zwischen den verschiedenen Cache-Einheiten 206 und 204A-204N.
In einigen Ausführungsformen kann der Prozessor 200 auch einen Satz von einer oder mehreren Bussteuereinheiten 216 und einen Systemagentenkern 210 umfassen. Die eine oder mehrere Bussteuereinheiten 216 verwalten einen Satz von Peripheriebussen, wie z.B. einen oder mehrere PCI- oder PCI-Express-Busse. Der Systemagentenkern 210 stellt Verwaltungsfunktionen für die verschiedenen Prozessorkomponenten bereit. In einigen Ausführungsformen umfasst der Systemagentenkern 210 einen oder mehrere integrierte Speichersteuerungsvorrichtung 214, um den Zugriff auf verschiedene externe Speichervorrichtungen (nicht dargestellt) zu verwalten.
In einigen Ausführungsformen umfassen einer oder mehrere der Prozessorkerne 202A-202N Unterstützung für gleichzeitiges Multithreading. In einer solchen Ausführungsform umfasst der Systemagentenkern 210 Komponenten zur Koordination und zum Betrieb der Kerne 202A-202N während der Multithread-Verarbeitung. Der Systemagentenkern 210 kann zusätzlich dazu eine Energiesteuereinheit (PCU) umfassen, die Logik und Komponenten zum Regeln des Energiestatus der Prozessorkerne 202A-202N und des Grafikprozessors 208 umfassen.
In einigen Ausführungsformen umfasst der Prozessor 200 zusätzlich dazu den Grafikprozessor 208, um Grafikverarbeitungsoperationen auszuführen. In einigen Ausführungsformen wird der Grafikprozessor 208 mit dem Satz der gemeinsamen Cache-Einheiten 206 und dem Systemagentenkern 210, einschließlich der einen oder den mehreren integrierten Speichersteuerungsvorrichtungen 214, gekoppelt. In einigen Ausführungsformen umfasst der Systemagentenkern 210 auch eine Anzeigesteuerungsvorrichtung 211, um die Grafikprozessorausgabe auf eine oder mehrere gekoppelte Anzeigen zu steuern. In einigen Ausführungsformen kann die Anzeigesteuerungsvorrichtung 211 auch ein separates Modul sein, das über zumindest eine Verbindung mit dem Grafikprozessor gekoppelt ist oder in den Grafikprozessor 208 integriert sein kann.
In einigen Ausführungsformen wird eine ringbasierte Verbindungseinheit 212 verwendet, um die internen Komponenten des Prozessors 200 zu koppeln. Es kann jedoch eine alternative Verbindungseinheit verwendet werden, wie z.B. eine Punkt-zu-Punkt-Verbindung, eine geschaltete Verbindung oder andere Techniken, einschließlich auf dem Gebiet der Erfindung bekannte Techniken. In einigen Ausführungsformen wird der Grafikprozessor 208 über eine I/O-Verknüpfung 213 mit der Ringverbindung 212 gekoppelt.
Die exemplarische I/O-Verknüpfung 213 stellt mindestens eine von zahlreichen Varianten von I/O-Verbindungen dar, einschließlich einer On-Package-I/O-Verbindung, die die Kommunikation zwischen verschiedenen Prozessorkomponenten und einem leistungsstarken integrierten Speichermodul 218, wie z.B. einem eDRAM-Modul, ermöglicht. In manchen Ausführungsformen verwenden jeder der Prozessorkerne 202A-202N und der Grafikprozessor 208 eingebettete Speichermodule 218 als gemeinsamen Last-Level-Cache.
In einigen Ausführungsformen sind die Prozessorkerne 202A-202N homogene Kerne, die dieselbe Anweisungssatzarchitektur ausführen. In einer weiteren Ausführungsform sind die Prozessorkerne 202A-202N heterogen in Bezug auf die Anweisungssatzarchitektur (ISA), wobei einer oder mehrere der Prozessorkerne 202A-202N einen ersten Anweisungssatz ausführen, während zumindest einer der anderen Kerne einen Teilsatz des ersten Anweisungssatzes oder einen anderen Anweisungssatz ausführt. In einer Ausführungsform sind die Prozessorkerne 202A-202N heterogen in Bezug auf die Mikroarchitektur, wobei ein oder mehrere Kerne mit einem relativ höheren Energieverbrauch mit einem oder mehreren Leistungskernen mit einem niedrigeren Energieverbrauch gekoppelt sind. Zusätzlich dazu kann der Prozessor 200 auf einem oder mehreren Chips oder als integrierte SoC-Schaltung mit den dargestellten Komponenten zusätzlich zu anderen Komponenten ausgeführt sein.
3 ist ein Blockdiagramm eines Grafikprozessors 300, der eine diskrete Grafikverarbeitungseinheit oder ein mit einer Vielzahl von Verarbeitungskernen integrierter Grafikprozessor sein kann. In einigen Ausführungsformen kommuniziert der Grafikprozessor über eine speicherabgebildete IIO-Schnittstelle mit Registern auf dem Grafikprozessor und mit in dem Prozessorspeicher platzierten Befehlen. In einigen Ausführungsformen umfasst der Grafikprozessor 300 eine Speicherschnittstelle 314 zum Zugriff auf den Speicher. Die Speicherschnittstelle 314 kann eine Schnittstelle zum lokalen Speicher, einem oder mehreren internen Cache-Speichern, einem oder mehreren gemeinsamen externen Cache-Speichern und/oder zum Systemspeicher sein.
In einigen Ausführungsformen umfasst der Grafikprozessor 300 auch eine Anzeigesteuerungsvorrichtung 302, um die Anzeigeausgabedaten zu einer Anzeigevorrichtung 320 zu steuern. Die Anzeigesteuerungsvorrichtung 302 umfasst Hardware für eine oder mehrere Überlagerungsebenen zur Anzeige und Zusammensetzung mehrerer Ebenen von Video- oder Anwenderschnittstellenelementen. Die Anzeigevorrichtung 320 kann eine interne oder externe Anzeigevorrichtung sein. In einer Ausführungsform ist die Anzeigevorrichtung 320 ein Datenhelm, wie z.B. eine Virtual-Reality- (VR-) Anzeigevorrichtung oder eine Augmented-Reality- (AR-) Anzeigevorrichtung. In einigen Ausführungsformen umfasst der Grafikprozessor 300 einen Video-Codec-Engine 306 zum Verschlüsseln, Entschlüsseln oder Umschlüsseln von Medien in, aus oder zwischen einem oder mehreren Mediencodierungsformaten, einschließlich, aber nicht beschränkt auf, Moving-Picture-Experts-Group- (MPEG-) Formaten wie MPEG-2, Advanced-Video-Coding- (AVC-) Formaten wie H.264/MPEG-4 AVC sowie Formaten der Society of Motion Picture & Television Engineers (SMPTE) 421M/VC-1 und den Formaten der Joint Photographic Experts Group (JPEG) wie JPEG und Motion JPEG (MJPEG).
In einigen Ausführungsformen umfasst der Grafikprozessor 300 einen Blockbildübertragungsengine (BLIT) 304, um zweidimensionale (2D-) Rasterisierungsoperationen durchzuführen, z.B. einschließlich bitgebundener Blockübertragungen. In einer Ausführungsform werden jedoch 2D-Grafikoperationen unter Verwendung einer oder mehreren Komponenten des Grafikverarbeitungsengines (GPE) 310 durchgeführt. In einigen Ausführungsformen ist GPE 310 ein Rechenengine zur Durchführung von Grafikoperationen, einschließlich dreidimensionaler (3D-) Grafikoperationen und Medienoperationen.
In einigen Ausführungsformen umfasst GPE 310 eine 3D-Pipeline 312 zur Durchführung von 3D-Operationen, wie z.B. dem Rendern von dreidimensionalen Bildern und Szenen unter Verwendung von Bearbeitungsfunktionen, die auf Grundlage primitiver 3D-Formen (z.B. Rechteck, Dreieck usw.) funktionieren. Die 3D-Pipeline 312 umfasst programmierbare und fixe Funktionselemente, die verschiedene Aufgaben innerhalb der Element- und/oder Spawn-Ausführungs-Threads zu einem 3D/Medien-Subsystem 315 ausführen. Während die 3D-Pipeline 312 zur Durchführung von Medienoperationen verwendet werden kann, umfasst eine Ausführungsform der GPE 310 auch eine Medien-Pipeline 316, die speziell zur Durchführung von Medienoperationen, wie z.B. Videonachbearbeitung und Bildverbesserung, verwendet wird.
In einigen Ausführungsformen umfasst die Medien-Pipeline 316 Logikeinheiten mit fixer Funktion oder programmierbare Logikeinheiten, um eine oder mehrere spezialisierte Medienoperationen durchzuführen, wie z.B. Videoentschlüsselungsbeschleunigung, Video-Deinterlacing und Videoverschlüsselungsbeschleunigung anstelle von oder im Auftrag der Video-Codec-Engine 306. In einigen Ausführungsformen umfasst die Medien-Pipeline 316 zusätzlich dazu eine Thread-Spawning-Einheit zum Hervorbringen von Threads zur Ausführung auf dem 3D/Medien-Subsystem 315. Die hervorgebrachten Threads führen Berechnungen für die Medienoperationen auf einer oder mehreren Grafikausführungseinheiten durch, die Teil des 3D/Medien-Subsystems 315 sind.
In einigen Ausführungsformen umfasst das 3D/Medien-Subsystem 315 eine Logik zur Ausführung von Threads, die durch die 3D-Pipeline 312 und die Medien-Pipeline 316 hervorgebracht wurden. In einer Ausführungsform senden die Pipelines Thread-Ausführungsanfragen an das 3D/Medien-Subsystem 315, das eine Thread-Dispatch-Logik zum Vermitteln und Zuweisen der verschiedenen Anfragen an verfügbare Thread-Ausführungsressourcen umfasst. Die Ausführungsressourcen umfassen ein Array von Grafikausführungseinheiten zur Verarbeitung der 3D- und Medien-Threads. In einigen Ausführungsformen umfasst das 3D/Medien-Subsystem 315 einen oder mehrere interne Cache-Speicher für Thread-Anweisungen und -Daten. In einigen Ausführungsformen umfasst das Subsystem auch gemeinsamen Speicher, einschließlich Registern und adressierbarem Speicher, um Daten zwischen Threads zu teilen und Ausgabedaten zu speichern.
Grafikverarbeitungsengine
4 ist ein Blockdiagramm eines Grafikverarbeitungsengines 410 eines Grafikprozessors gemäß einigen Ausführungsformen. In einer Ausführungsform ist die Grafikverarbeitungsengine (GPE) 410 eine Version der in 3 dargestellten GPE 310. Elemente aus 4, die dieselben Bezugszeichen (oder Bezeichnungen) aufweisen wie die Elemente in irgendeiner anderen Figur, können in ähnlicher Weise wie an anderer Stelle hierin beschrieben betrieben werden oder funktionieren, sind aber nicht darauf beschränkt. So sind beispielsweise die 3D-Pipeline 312 und die Medien-Pipeline 316 aus 3 dargestellt. Die Medien-Pipeline 316 ist in manchen Ausführungsformen der GPE 410 optional, und es kann sein, dass sie nicht explizit Teil der GPE 410 ist. Beispielsweise und in zumindest einer Ausführungsform ein separater Medien- und/oder Bildprozessor mit der GPE 410 gekoppelt.
In einigen Ausführungsformen ist die GPE 410 mit einem Befehlsstreamer 403 gekoppelt oder beinhaltet diesen, der der 3D-Pipeline 312 und/oder den Medien-Pipelines 316 einen Befehlsstrom bereitstellt. In einigen Ausführungsformen ist der Befehlsstreamer 403 mit dem Speicher gekoppelt, der Systemspeicher oder einer oder mehrere von internem Cache-Speicher und gemeinsamem Cache-Speicher sein kann. In einigen Ausführungsformen empfängt der Befehlsstreamer 403 Befehle aus dem Speicher und sendet die Befehle an die 3D-Pipeline 312 und/oder die Medien-Pipeline 316. Die Befehle sind Befehlen, die aus einem Ringpuffer abgerufen werden, der Befehle für die 3D-Pipeline 312 und die Medien-Pipeline 316 speichert. In einer Ausführungsform kann der Ringspeicher zusätzlich dazu Batch-Befehlspuffer umfassen, die Batches mehrerer Befehle speichern. Die Befehle für die 3D-Pipeline 312 können auch Verweise auf im Speicher gespeicherte Daten umfassen, wie z.B. Vertex- und Geometriedaten für die 3D-Pipeline 312 und/oder Bilddaten und Speicherobjekte für die Medien-Pipeline 316. Die 3D-Pipeline 312 und die Medien-Pipeline 316 verarbeiten die Befehle und Daten, indem sie Operationen über Logik innerhalb der jeweiligen Pipelines ausführen oder indem sie einen oder mehrere Ausführungs-Threads an ein Grafikkernarray 414 vermitteln. In einer Ausführungsform umfasst das Grafikkernarray 414 einen oder mehrere Grafikkernblöcke (z.B. Grafikkern(e) 415A, Grafikkern(e) 415B), wobei jeder Block einen oder mehrere Grafikkerne umfasst. Jeder Grafikkern umfasst einen Satz von Grafikausführungsressourcen, der eine universelle und eine grafikspezifische Ausführungslogik zur Ausführung von Grafik- und Rechenoperationen sowie eine Texturverarbeitung mit fixer Funktion und/oder Beschleunigungslogik für maschinelles Lernen und für künstliche Intelligenz umfasst.
In verschiedenen Ausführungsformen umfasst die 3D-Pipeline 312 eine fixe Funktion und programmierbare Logik, um ein oder mehrere Shader-Programme wie Vertex-Shader, Geometrie-Shader, Pixel-Shader, Fragment-Shader, Compute-Shader oder andere Shader-Programme zu verarbeiten, indem die Anweisungen verarbeitet und Ausführungs-Threads an das Grafikkernarray 414 vermittelt werden. Das Grafikkernarray 414 stellt einen einheitlichen Block von Ausführungsressourcen zur Verwendung in der Verarbeitung dieser Shader-Programme bereit. Die multifunktionale Ausführungslogik (z.B. Ausführungseinheiten) innerhalb des Grafikkerns/der Grafikkerne 415A-414B des Grafikkernarrays 414 umfasst Unterstützung für verschiedene 3D-API-Shader-Sprachen und kann mehrere gleichzeitige Ausführungs-Threads ausführen, die mehreren Shadern zugeordnet sind.
In einigen Ausführungsformen umfasst das Grafikkernarray 414 auch eine Ausführungslogik zur Ausführung von Medienfunktionen wie Video- und/oder Bildverarbeitung. In einer Ausführungsform umfassen die Ausführungseinheiten zusätzlich dazu eine Universallogik, die programmierbar ist, um parallele Universalrechenoperationen zusätzlich zu den Grafikverarbeitungsoperationen durchzuführen. Die Universallogik kann Verarbeitungsoperationen parallel oder in Verbindung mit der Universallogik innerhalb des Prozessorkerns/der Prozessorkernes 107 aus 1 oder des Kerns 202A-202N wie in 2 durchführen.
Ausgabedaten, die von Threads erzeugt werden, die auf dem Grafikkernarray 414 ausgeführt werden, können Daten an den Speicher in einem Unified Return Buffer (URB) 418 ausgeben. Der URB 418 kann Daten für mehrere Threads speichern. In einigen Ausführungsformen kann der URB 418 verwendet werden, um Daten zwischen verschiedenen Threads zu versenden, die auf dem Grafikkernarray 414 ausgeführt werden. In einigen Ausführungsformen kann der URB 418 zusätzlich dazu zur Synchronisation zwischen Threads auf dem Grafikkernarray und der Logik mit fixer Funktion innerhalb der gemeinsamen Funktionslogik 420 verwendet werden.
In einigen Ausführungsformen ist das Grafikkernarray 414 skalierbar, so dass das Array eine variable Anzahl von Grafikkernen umfasst, die jeweils eine variable Anzahl von Ausführungseinheiten basierend auf dem Zielenergie- und -leistungsniveau von GPE 410 aufweisen. In einer Ausführungsform sind die Ausführungsressourcen dynamisch skalierbar, so dass Ausführungsressourcen nach Bedarf aktiviert oder deaktiviert werden können.
Das Grafikkernarray 414 wird mit der gemeinsamen Funktionslogik 420 gekoppelt, die mehrere Ressourcen umfasst, die unter den Grafikkernen in dem Grafikkernarray gemeinsam genutzt werden. Die gemeinsam genutzten Funktionen innerhalb der gemeinsam genutzten Funktionslogik 420 sind Hardware-Logikeinheiten, die eine spezielle ergänzende Funktionalität für das Grafikkernarray 414 bereitstellen. In verschiedenen Ausführungsformen umfasst die gemeinsam genutzte Funktionslogik 420 Sampler- 421, Mathematik- 422 und Inter-Thread-Communication- (ITC-) 423 Logik, ohne auf diese beschränkt zu sein. Zusätzlich dazu implementieren einige Ausführungsformen einen oder mehrere Cache-Speicher 425 innerhalb der gemeinsam genutzten Funktionslogik 420.
Eine gemeinsam genutzte Funktion wird implementiert, wenn der Bedarf in Bezug auf eine bestimmte spezialisierte Funktion nicht ausreicht, um sie in dem Grafikkernarray 414 aufzunehmen. Stattdessen wird eine einzelne Instanziierung dieser spezialisierten Funktion als eigenständige Einheit in der gemeinsam genutzten Funktionslogik 420 implementiert und unter den Ausführungsressourcen innerhalb des Grafikkernarrays 414 geteilt. Der genaue Satz von Funktionen, die zwischen dem Grafikkernarray 414 geteilt und in dem Grafikkernarray 414 beinhaltet sind, variiert je nach Ausführungsform. In einigen Ausführungsformen können spezifische gemeinsam genutzte Funktionen innerhalb der gemeinsam genutzten Funktionslogik 420, die von dem Grafikkernarray 414 umfassend verwendet werden, in die gemeinsam genutzte Funktionslogik 416 innerhalb des Grafikkernarrays 414 aufgenommen werden. In verschiedenen Ausführungsformen kann die gemeinsame Funktionslogik 416 innerhalb des Grafikkernarrays 414 einen Teil der oder die vollständige Logik innerhalb der gemeinsamen Funktionslogik 420 umfassen. In einer Ausführungsform können alle Logikelemente innerhalb der gemeinsam genutzten Funktionslogik 420 innerhalb der gemeinsam genutzten Funktionslogik 416 des Grafikkernarrays 414 dupliziert werden. In einer Ausführungsform wird die gemeinsam genutzte Funktionslogik 420 zugunsten der gemeinsam genutzten Funktionslogik 416 innerhalb des Grafikkernarrays 414 ausgeschlossen.
5 ist ein Blockdiagramm einer Hardwarelogik eines Grafikprozessorkerns 500 gemäß einigen hierin beschriebenen Ausführungsformen. Elemente aus 5, die dieselben Bezugszeichen (oder Bezeichnungen) aufweisen wie die Elemente in irgendeiner anderen Figur, können in ähnlicher Weise wie an anderer Stelle hierin beschrieben betrieben werden oder funktionieren, sind aber nicht darauf beschränkt. Der veranschaulichte Grafikprozessorkern 500 ist in einigen Ausführungsformen Teil des Grafikkernarrays 414 aus 4. Bei dem Grafikprozessorkern 500, manchmal auch als Kernelement („Slice“) bezeichnet, kann es sich um einen oder mehrere Grafikkerne innerhalb eines modularen Grafikprozessors handeln. Der Grafikprozessorkern 500 ist ein Beispiel für ein Grafikkernelement, und ein Grafikprozessor, wie hierin beschrieben, kann mehrere Grafikkernelementen basierend auf der Zielleistungs- und den -energiehüllkurven umfassen. Jeder Grafikkern 500 kann einen festen Block mit fixer Funktion 530 umfassen, der mit mehreren Subkernen 501A-501F gekoppelt ist, die auch als Subelemente bezeichnet werden und modulare Blöcke mit Universallogik und Logik mit fixer Funktion umfassen.
In einigen Ausführungsformen umfasst der Block mit fixer Funktion 530 eine Geometrie-/Fixfunktions-Pipeline 536, die von allen Subkernen im Grafikprozessor 500 gemeinsam genutzt werden kann, beispielsweise bei Implementierungen von Grafikprozessoren mit geringerer Leistung und/oder geringerem Energieverbrauch. In verschiedenen Ausführungsformen beinhaltet die Geometrie/Fixfunktions-Pipeline 536 eine 3D-Pipeline mit fixer Funktion (z.B. 3D-Pipeline 312 wie in 3 und 4), eine Video-Frontend-Einheit, einen Thread-Spawner und Thread-Dispatcher sowie einen Unified-Return-Puffer-Manager, der Unified Return Buffer, wie z.B. den Unified Return Buffer 418 aus 4, verwaltet.
In einer Ausführungsform umfasst der Block mit fixer Funktion 530 auch eine Grafik-SoC-Schnittstelle 537, eine Grafikmikrosteuerungsvorrichtung 538 und eine Medien-Pipeline 539. Die Grafik-SoC-Schnittstelle 537 stellt eine Schnittstelle zwischen dem Grafikkern 500 und anderen Prozessorkernen innerhalb einer integrierten System-on-a-Chip-Schaltung bereit. Die Grafikmikrosteuerungsvorrichtung 538 ist ein programmierbarer Subprozessor, der konfiguriert werden kann, um verschiedene Funktionen des Grafikprozessors 500 zu verwalten, einschließlich Thread-Dispatch-, Scheduling- und Preemption-Funktionen. Die Medien-Pipeline 539 (z.B. Medien-Pipeline 316 aus 3 und 4) umfasst Logik, um das Entschlüsseln, Verschlüsseln, die Vorverarbeitung und/oder Nachbearbeitung von Multimedia-Daten, einschließlich Bild- und Videodaten, zu ermöglichen. Die Medien-Pipeline 539 implementiert Medienoperationen über Anfragen zur Berechnung oder Abtastung der Logik innerhalb der Subkerne 501-501F.
In einer Ausführungsform ermöglicht die SoC-Schnittstelle 537 dem Grafikkern 500 die Kommunikation mit Universalanwendungsprozessorkernen (z.B. CPUs) und/oder anderen Komponenten innerhalb eines SoC, einschließlich Speicherhierarchieelementen wie einem gemeinsamen Last-Level-Cache-Speicher, dem System-RAM und/oder eingebettetem On-Chip- oder On-Package-DRAM. Die SoC-Schnittstelle 537 kann auch die Kommunikation mit Vorrichtungen mit fixer Funktion innerhalb des SoC ermöglichen, wie z.B. Kamerabildgebungs-Pipelines, und ermöglicht die Verwendung und/oder Implementierung von globalen Speicheratomen, die zwischen dem Grafikkern 500 und CPUs innerhalb des SoC geteilt werden können. Die SoC-Schnittstelle 537 kann auch Energieverwaltungssteuervorrichtungen für den Grafikkern 500 implementieren und eine Schnittstelle zwischen einer Taktdomäne des Grafikkerns 500 und anderen Taktdomänen innerhalb des SoC aktivieren. In einer Ausführungsform ermöglicht die SoC-Schnittstelle 537 den Empfang von Befehlspuffern von einem Befehlsstreamer und einem globalen Thread-Dispatcher, die konfiguriert sind, um Befehle und Anweisungen an jeden einzelnen des einen oder der mehreren Grafikkerne innerhalb eines Grafikprozessors bereitzustellen. Die Befehle und Anweisungen können an die Medien-Pipeline 539 vermittelt werden, wenn Medienoperationen durchgeführt werden sollen, oder an eine Geometrie- und Fixunktions-Pipeline (z.B. Geometrie- und Fixfunktions-Pipeline 536, Geometrie- und Fixfunktions-Pipeline 514), wenn Grafikverarbeitungsoperationen durchgeführt werden sollen.
Die Grafikmikrosteuerungsvorrichtung 538 kann konfiguriert werden, um verschiedene Planungs- und Verwaltungsaufgaben für den Grafikkern 500 durchzuführen. In einer Ausführungsform kann die Grafikmikrosteuerungsvorrichtung 538 Grafik- und/oder Rechenarbeitslastplanung auf den verschiedenen parallelen Grafikengines innerhalb des Arrays von Ausführungseinheiten (EU) 502A-502F, 504A-504F innerhalb der Subkerne 501A-501F durchführen. In diesem Planungsmodell kann die Host-Software, die auf einem CPU-Kern eines SoC, die den Grafikkern 500 umfasst, ausgeführt wird, Arbeitslasten an eine von mehreren Grafikprozessor-Doorbells übermitteln, wodurch eine Planungsoperation auf dem entsprechenden Grafikengine aufgerufen wird. Zu den Planungssoperationen gehören das Bestimmen der als nächstes auszuführenden Arbeitslast, das Übermitteln einer Arbeitslast an einen Befehlsstreamer, das Vorwegnehmen bestehender Arbeitslasten, die auf einem Engine ausgeführt werden, das Überwachen des Fortschritts einer Arbeitslast und das Benachrichtigen der Host-Software, wenn eine Arbeitslast abgeschlossen ist. In einer Ausführungsform kann die Grafikmikrosteuerungsvorrichtung 538 auch Niedrigenergie- oder Leerlaufzustände für den Grafikkern 500 ermöglichen und dem Grafikkern 500 die Möglichkeit bereitstellen, Register innerhalb des Grafikkerns 500 über Statusübergänge mit niedrigem Stromverbrauch unabhängig vom Betriebssystem und/oder der Grafiktreibersoftware auf dem System zu speichern und wiederherzustellen.
Der Grafikkern 500 kann mehr oder weniger als die dargestellten Subkerne 501A-501F bis hin zu N modularen Subkernen aufweisen. Für jeden Satz von N Subkernen kann der Grafikkern 500 auch eine gemeinsam genutzte Funktionslogik 510, einen gemeinsam genutzten und/oder Cache-Speicher 512, eine Geometrie-/Fixfunktions-Pipeline 514 sowie eine zusätzliche Logik mit fixer Funktion 516 zur Beschleunigung verschiedener Grafik- und Rechenoperationen umfassen. Die gemeinsam genutzte Funktionslogik 510 kann Logikeinheiten umfassen, die der gemeinsamen Funktionslogik 420 aus 4 zugeordnet sind (z.B. Sampler-, Mathematik- und/oder Inter-Thread-Kommunikationslogik), die von jedem der N Subkerne innerhalb des Grafikkerns 500 gemeinsam genutzt werden können. Der gemeinsam genutzte und/oder Cache-Speicher 512 kann ein Last-Level-Cache-Speicher für den Satz von N Subkernen 501A-501F innerhalb des Grafikkerns 500 sein und auch als gemeinsam genutzter Speicher dienen, auf den mehrere Subkerne zugreifen können. Die Geometrie-/Fixfunktions-Pipeline 514 kann anstelle der Geometrie-/Fixfunktions-Pipeline 536 im Block mit fixer Funktion 530 beinhaltet sein und kann dieselben oder ähnliche Logikeinheiten umfassen.
In einer Ausführungsform umfasst der Grafikkern 500 eine zusätzliche Logik mit fixer Funktion 516, die verschiedene Beschleunigungslogiken mit fixer Funktion zur Verwendung durch den Grafikkern 500 umfassen. In einer Ausführungsform umfasst die zusätzliche Logik mit fixer Funktion 516 eine zusätzliche Geometrie-Pipeline zur Verwendung für Position-Only-Shading. Beim Position-Only-Shading gibt es zwei Geometrie-Pipelines, die vollständige Geometrie-Pipeline innerhalb der Geometrie-/Fixfunktions-Pipeline 516, 536 und eine Cull-Pipeline, die eine zusätzliche Geometrie-Pipeline ist, die Teil der zusätzlichen Logik mit fixer Funktion 516 sein kann. In einer Ausführungsform ist die Cull-Pipeline eine reduzierte 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 eigenen Kontext aufweist. Position-Only-Shading kann lange Cull-Durchläufe von verworfenen Dreiecken ausblenden, so dass das Shading in einigen Fällen früher abgeschlossen werden kann. Beispielsweise und in einer Ausführungsform kann die Cull-Pipeline-Logik innerhalb der zusätzlichen Logik mit fixer Funktion 516 parallel zur Hauptanwendung Positions-Shader ausführen und erzeugt im Allgemeinen wesentliche Ergebnisse rascher als die vollständige Pipeline, da die Cull-Pipeline nur das Positionsattribut der Vertizes abfragt und schattiert, ohne eine Rasterisierung und ein Rendern der Pixel im Frame-Puffer durchzuführen. Die Cull-Pipeline kann die erzeugten wesentlichen Ergebnisse verwenden, um Sichtbarkeitsinformationen für alle Dreiecke zu berechnen, ohne Rücksicht darauf, ob diese Dreiecke ausgewählt werden. Die vollständige Pipeline (die in diesem Fall als Replay-Pipeline bezeichnet werden kann) kann die Sichtbarkeitsinformationen verwenden, um die ausgewählten Dreiecke zu überspringen und nur die sichtbaren Dreiecke zu schattieren, die schließlich an die Rasterisierungsphase übergeben werden.
In einer Ausführungsform kann die zusätzliche Logik mit fixer Funktion 516 auch Beschleunigungslogik für maschinelles Lernen, wie z.B. eine Matrixmultiplikationslogik mit fixer Funktion, für Implementierungen wie Optimierungen für das Training von maschinellem Lernen oder Inferieren umfassen.
Jeder Grafiksubkern 501A-501F umfasst einen Satz von Ausführungsressourcen, die verwendet werden können, um Grafik-, Medien- und Rechenoperationen als Reaktion auf Anfragen von Grafik-, Medien- oder Shader-Programmen durchzuführen. Die Grafiksubkerne 501A-501F umfassen mehrere EU-Arrays 502A-502F, 504A-504F, Thread-Dispatch- und Inter-Thread-Kommunikationslogik (TD/IC) 503A-503F, einen 3D- (z.B. Textur-) Sampler 505A-505F, einen Medien-Sampler 506A-506F, einen Shader-Prozessor 507A-507F und einen gemeinsam genutzten lokalen Speicher (SLM) 508A-508F. Die EU-Arrays 502A-502F, 504A-504F umfassen jeweils mehrere Ausführungseinheiten, die Universalgrafikverarbeitungseinheiten sind, die in der Lage sind, Gleitkomma- und Ganzzahl-/Festkomma-Logikoperationen im Dienst einer Grafik-, Medien- oder Rechenoperation durchzuführen, einschließlich Grafik-, Medien- oder Rechen-Shader-Programme. Die TD/IC-Logik 503A-503F führt lokale Thread-Dispatch- und Thread-Steuervorgänge für die Ausführungseinheiten innerhalb eines Subkerns durch und ermöglicht eine Kommunikation zwischen Threads, die auf den Ausführungseinheiten des Subkerns ausgeführt werden. Der 3D-Sampler 505A-505F kann Texturen oder andere 3D-Grafikdaten in den Speicher lesen. Der 3D-Sampler kann Texturdaten unterschiedlich lesen, basierend auf einem konfigurierten Sample-Status und dem Texturformat, das einer bestimmten Textur zugeordnet ist. Der Medien-Sampler 506A-506F kann ähnliche Leseoperationen durchführen, basierend auf Art und Format der Mediendaten. In einer Ausführungsform kann jeder Grafiksubkern 501A-501F abwechselnd einen einheitlichen 3D- und Medien-Sampler umfassen. Threads, die auf den Ausführungseinheiten innerhalb jedes der Subkerne 501A-501F ausgeführt werden, können den gemeinsamen lokalen Speicher 508A-508F innerhalb jedes Subkerns nutzen, um es Threads, die innerhalb einer Thread-Gruppe ausgeführt werden, zu ermöglichen, unter Nutzung eines gemeinsamen On-Chip-Speicherpools auszuführen.
Ausführungseinheiten
6A-6B veranschaulichen Thread-Ausführungslogik 600, die ein Array von Verarbeitungselementen umfasst, die in einem Grafikprozessorkern gemäß hierin beschriebenen Ausführungsformen verwendet werden. Elemente aus 6A-6B, die dieselben Bezugszeichen (oder Bezeichnungen) aufweisen wie die Elemente in irgendeiner anderen Figur, können in ähnlicher Weise wie an anderer Stelle hierin beschrieben betrieben werden oder funktionieren, sind aber nicht darauf beschränkt. 6A zeigt eine Übersicht über die Thread-Ausführungslogik 600, die eine Variante der mit jedem Subkern 501A-501F aus 5 dargestellten Hardwarelogik umfassen kann. 6B zeigt Beispiele für interne Details einer Ausführungseinheit.
Wie in 6A dargestellt, umfasst die Thread-Ausführungslogik 600 in einigen Ausführungsformen einen Shader-Prozessor 602, einen Thread-Dispatcher 604, einen Anweisungs-Cache-Speicher 606, ein skalierbares Ausführungseinheiten-Array mit einer Vielzahl von Ausführungseinheiten 608A-608N, einen Sampler 610, einen Daten-Cache-Speicher 612 und einen Datenport 614. In einer Ausführungsform kann das skalierbare Array von Ausführungseinheiten dynamisch skaliert werden, indem eine oder mehrere Ausführungseinheiten (z.B. eine der Ausführungseinheiten 608A, 608B, 608C, 608D bis 608N-1 und 608N) basierend auf den Rechenanforderungen einer Arbeitslast aktiviert oder deaktiviert werden. In einer Ausführungsform sind die enthaltenen Komponenten über ein Verbindungsgefüge miteinander verbunden, das mit jeder der Komponenten verknüpft ist. In einigen Ausführungsformen umfasst die Thread-Ausführungslogik 600 eine oder mehrere Verbindungen zum Speicher, wie z.B. dem Systemspeicher oder Cache-Speicher, über ein oder mehrere Elemente aus Anweisungs-Cache-Speicher 606, Datenport 614, Sampler 610 und Ausführungseinheiten 608A-608N. In einigen Ausführungsformen ist jede Ausführungseinheit (z.B. 608A) eine eigenständige, programmierbare, Universalrecheneinheit, die in der Lage ist, mehrere gleichzeitige Hardware-Threads auszuführen und gleichzeitig mehrere Datenelemente für jeden Thread parallel zu verarbeiten. In verschiedenen Ausführungsformen ist das Array der Ausführungseinheiten 608A-608N skalierbar, um eine beliebige Anzahl einzelner Ausführungseinheiten zu umfassen.
In einigen Ausführungsformen werden die Ausführungseinheiten 608A-608N vorwiegend zum Ausführen von Shader-Programmen verwendet. Ein Shader-Prozessor 602 kann die verschiedenen Shader-Programme verarbeiten und Ausführungs-Threads, die den Shader-Programmen zugeordnet sind, über einen Thread-Dispatcher 604 vermitteln. In einer Ausführungsform umfasst der Thread-Dispatcher eine Logik, um Thread-Initiierungsanfragen aus den Grafik- und Medien-Pipelines zu vermitteln und die angefragten Threads auf einer oder mehreren Ausführungseinheiten in den Ausführungseinheiten 608A-608N zu instanziieren. Beispielsweise kann eine Geometrie-Pipeline Vertex-, Tesselations- und Geometrie-Shader zur Verarbeitung an die Thread-Ausführungslogik vermitteln. In einigen Ausführungsformen kann der Thread-Dispatcher 604 auch Laufzeit-Thread-Spawning-Anfragen von den ausführenden Shader-Programmen verarbeiten.
In einigen Ausführungsformen unterstützen die Ausführungseinheiten 608A-608N einen Anweisungssatz, der die native Unterstützung für viele Standard-3D-Grafik-Shader-Anweisungen umfasst, so dass 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 Universalverarbeitung (z.B. Rechen- und Media-Shader). Jede der Ausführungseinheiten 608A-608N ist in der Lage, mehrere Multi-Issue-SIMD- (Single Instruction Multiple Data) Ausführungen auszuführen, und Multithread-Operationen ermöglichen eine effiziente Ausführungsumgebung bei Speicherzugriffen mit höherer Latenz. Jeder Hardware-Thread innerhalb jeder Ausführungseinheit weist eine dedizierte Registerdatei mit hoher Bandbreite und einen zugehörigen unabhängigen Thread-Status auf. Die Ausführung erfolgt mit Multi-Issue-Ansatz pro Takt an Pipelines, die in der Lage sind, Gleitkommaoperationen mit ganzen Zahlen, einfacher und doppelter Genauigkeit, SIMD-Kapazität aufweisen, logische Operationen, transzendente Operationen und andere verschiedene Operationen durchzuführen. Während des Wartens auf Daten aus dem Speicher oder einer der gemeinsamen Funktionen bewirkt die Abhängigkeitslogik innerhalb der Ausführungseinheiten 608A-608N, dass ein wartender Thread schläft, bis die angeforderten Daten zurückgegeben wurden. Während der wartende Thread schläft, können Hardware-Ressourcen für die Verarbeitung anderer Threads verwendet werden. Während einer Verzögerung, die mit einer Vertex-Shader-Operation in Zusammenhang steht, kann eine Ausführungseinheit beispielsweise Operationen für einen Pixel-Shader, Fragment-Shader oder eine andere Art von Shader-Programm durchführen, einschließlich einem anderen Vertex-Shader.
Jede Ausführungseinheit in den Ausführungseinheiten 608A-608N arbeitet mit 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 den Zugriff auf Datenelemente, die Maskierung und die Flusssteuerung innerhalb von Anweisungen. Die Anzahl der Kanäle kann von der Anzahl der physischen arithmetischen Logikeinheiten (ALUs) oder Gleitkommaeinheiten (FPUs) für einen bestimmten Grafikprozessor unabhängig sein. In einigen Ausführungsformen unterstützen die Ausführungseinheiten 608A-608N Ganzzahl- und Gleitkomma-Datentypen.
Der Anweisungssatz der Ausführungseinheit umfasst SIMD-Anweisungen. Die verschiedenen Datenelemente können als gepackter Datentyp in einem Register gespeichert werden, und die Ausführungseinheit verarbeitet die verschiedenen Elemente basierend auf der Datengröße der Elemente. Wenn beispielsweise ein 256-Bit breiter Vektor verwendet wird, werden die 256 Bit des Vektors in einem Register gespeichert und die Ausführungseinheit bearbeitet den Vektor als vier separate gepackte 64-Bit-Datenelemente (Datenelemente in Quad-Word- (QW-) Größe), acht separate gepackte 32-Bit-Datenelemente (Datenelemente in Double-Word- (DW-) Größe), sechzehn separate gepackte 16-Bit-Datenelemente (Datenelemente in Word- (W-) Größe) oder zweiunddreißig separate 8-Bit-Datenelemente (Datenelemente in Byte- (B-) Größe). Es sind jedoch unterschiedliche Vektorbreiten und Registergrößen möglich.
In einer Ausführungsform können eine oder mehrere Ausführungseinheiten zu einer fusionierten Ausführungseinheit 609A-609N mit einer Thread-Steuerungslogik (607A-607N) kombiniert werden, die durch die fusionierten EUs gemeinsam genutzt wird. Mehrere EUs können zu einer EU-Gruppe fusioniert werden. Jede EU in der fusionierten EU-Gruppe kann konfiguriert werden, um einen separaten SIMD-Hardware-Thread auszuführen. Die Anzahl der EUs in einer fusionierten EU-Gruppe kann je nach Ausführungsform variieren. Zusätzlich dazu können verschiedene SIMD-Breiten pro EU durchgeführt werden, einschließlich, aber nicht beschränkt auf, SIMD8, SIMD16 und SIMD32. Jede fusionierte Grafikausführungseinheit 609A-609N umfasst zumindest zwei Ausführungseinheiten. So umfasst beispielsweise die fusionierte Ausführungseinheit 609A eine erste EU 608A, eine zweite EU 608B und eine Thread-Steuerungslogik 607A, die durch die erste EU 608A und die zweite EU 608B gemeinsam genutzt wird. Die Thread-Steuerungslogik 607A steuert Threads, die auf der fusionierten Grafikausführungseinheit 609A ausgeführt werden, so dass jede EU innerhalb der fusionierten Ausführungseinheiten 609A-609N mit einem gemeinsamen Anweisungszeigerregister ausgeführt werden kann.
Ein oder mehrere interne Anweisungs-Cache-Speicher (z.B. 606) sind in der Thread-Ausführungslogik 600 enthalten, um Thread-Anweisungen für die Ausführungseinheiten zwischenzuspeichern. In einigen Ausführungsformen sind ein oder mehrere Daten-Cache-Speicher (z.B. 612) beinhaltet, um Thread-Daten während der Thread-Ausführung zwischenzuspeichern. In einigen Ausführungsformen ist ein Sampler 610 beinhaltet, der Texturproben für 3D-Operationen und Medien-Samples für Medienoperationen bereitstellt. In einigen Ausführungsformen umfasst der Sampler 610 eine spezielle Textur- oder Medien-Sampling-Funktionalität, um Textur- oder Mediendaten während des Sampling-Vorgangs zu verarbeiten, bevor die gesampelten Daten einer Ausführungseinheit bereitgestellt werden.
Während der Ausführung senden die Grafik- und Medien-Pipelines Thread-Initiierungsanfragen über Thread-Spawning und Dispatch-Logik an die Thread-Ausführungslogik 600. Sobald eine Gruppe geometrischer Objekte verarbeitet und in Pixeldaten gerastert wurde, wird die Pixelprozessorlogik (z.B. Pixel-Shader-Logik, Fragment-Shader-Logik usw.) innerhalb des Shader-Prozessors 602 aufgerufen, um die Ausgabeinformationen weiter zu berechnen und zu bewirken, dass Ergebnisse auf die Ausgabeoberflächen (z.B. Farbpuffer, Tiefenpuffer, Schablonenpuffer usw.) geschrieben werden. In einigen Ausführungsformen berechnet ein Pixel-Shader oder Fragment-Shader die Werte der verschiedenen Vertex-Attribute, die über das gerasterte Objekt hinweg interpoliert werden sollen. In einigen Ausführungsformen führt die Pixelprozessorlogik innerhalb des Shader-Prozessors 602 dann ein von der Anwendungsprogrammierschnittstelle (API) bereitgestelltes Pixel- oder Fragment-Shader-Programm aus. Zur Ausführung des Shader-Programms vermittelt der Shader-Prozessor 602 über den Thread-Dispatcher 604 Threads an eine Ausführungseinheit (z.B. 608A). In einigen Ausführungsformen verwendet der Shader-Prozessor 602 die Textur-Sampling-Logik im Sampler 610, um auf Texturdaten in im Speicher gespeicherten Texturabbildungen zuzugreifen. Durch arithmetische Operationen in Bezug auf die Texturdaten und die Eingabegeometriedaten werden Pixelfarbdaten für jedes geometrische Fragment berechnet oder ein oder mehrere Pixel für die Weiterverarbeitung verworfen.
In einigen Ausführungsformen stellt der Datenport 614 einen Speicherzugriffmechanismus für die Thread-Ausführungslogik 600 für die Ausgabe verarbeiteter Daten an den Speicher für die weitere Verarbeitung auf einer Grafikprozessorausgabe-Pipeline bereit. In einigen Ausführungsformen umfasst der Datenport 614 einen oder mehrere Cache-Speicher (z.B. DatenCache-Speicher 612), um Daten für Speicherzugriff über den Datenport zwischenzuspeichern, oder ist an diese gekoppelt.
Wie in 6B dargestellt, kann eine Grafikausführungseinheit 608 eine Anweisungsabrufeinheit 637, ein General Register File Array (GRF) 624, ein Architectural Register File Array (ARF) 626, einen Thread-Arbiter 622, eine Sendeeinheit 630, eine Verzweigungseinheit 632, einen Satz SIMD-Gleitkommaeinheiten (FPUs) 634 und in einer Ausführungsform einen Satz dedizierter ganzzahliger SIMD ALUs 635 umfassen. Die GRF 624 und ARF 626 umfassen den Satz allgemeiner Registerdateien und Architekturregisterdateien, die jedem gleichzeitigen Hardware-Thread zugeordnet sind, der in der Grafikausführungseinheit 608 aktiv sein kann. In einer Ausführungsform wird der Architekturstatus pro Thread im ARF 626 beibehalten, während die während der Thread-Ausführung verwendeten Daten im GRF 624 gespeichert werden. Der Ausführungsstatus jedes Threads, einschließlich der Anweisungszeiger für jeden Thread, kann in Threadspezifischen Registern in der ARF 626 festgehalten werden.
In einer Ausführungsform weist die Grafikausführungseinheit 608 eine Architektur auf, die eine Kombination von Simultaneous Multi-Threading (SMT) und feinkörnigem Interleaved Multi-Threading (IMT) ist. Die Architektur weist eine modulare Konfiguration auf, die zum Zeitpunkt der Gestaltung auf Grundlage einer Zielanzahl gleichzeitiger Threads und einer Zielanzahl von Registern pro Ausführungseinheit feinabgestimmt werden kann, wobei die Ausführungseinheitsressourcen auf die Logik, die zur Ausführung mehrerer gleichzeitiger Threads verwendet wird, aufgeteilt sind.
In einer Ausführungsform kann die Grafikausführungseinheit 608 mehrere Anweisungen gemeinsam ausgeben, die jeweils unterschiedliche Anweisungen sein können. Der Thread-Arbiter 622 des Grafikausführungseinheits-Threads 608 kann die Anweisungen zur Ausführung an eine der Sendeeinheit 630, Verzweigungseinheit 642 oder SIMD FPU(s) 634 vermitteln. Jeder Ausführungs-Thread kann auf 128 Universalregister innerhalb des GRF 624 zugreifen, wobei jedes Register 32 Bytes speichern kann, auf die als SIMD-8-Elementvektor von 32-Bit-Datenelementen zugegriffen werden kann. In einer Ausführungsform hat jeder Thread der Ausführungseinheit Zugriff auf 4 KByte innerhalb des GRF 624, wenngleich die Ausführungsformen nicht darauf beschränkt sind und in anderen Ausführungsformen mehr oder weniger Registerressourcen bereitgestellt werden können. In einer Ausführungsform können bis zu sieben Threads gleichzeitig ausgeführt werden, wenngleich die Anzahl der Threads pro Ausführungseinheit auch je nach Ausführungsform variieren kann. In einer Ausführungsform, in der sieben Threads auf 4 KByte zugreifen können, kann das GRF 624 insgesamt 28 KByte speichern. Flexible Adressierungsmodi können es ermöglichen, dass Register gemeinsam angesprochen werden, um effektiv breitere Register aufzubauen oder geschichtete rechteckige Blockdatenstrukturen darzustellen.
In einer Ausführungsform werden Speicheroperationen, Sampler-Operationen und andere Systemkommunikationen mit längerer Latenz über „Senden“-Anweisungen vermittelt, die durch die Nachrichtenaustauschsendeeinheit 630 ausgeführt werden. In einer Ausführungsform werden Verzweigungsanweisungen an eine dedizierte Verzweigungseinheit 632 vermittelt, um SIMD-Divergenz und letztliche Konvergenz zu ermöglichen.
In einer Ausführungsform umfasst die Grafikausführungseinheit 608 eine oder mehrere SIMD-Gleitkommaeinheiten (FPU(s)) 634, um Gleitkommaoperationen durchzuführen. In einer Ausführungsform unterstützt/unterstützen die FPU(s) 634 auch Ganzzahlberechnungen. In einer Ausführungsform kann/können die FPU(s) 634 SIMD bis zu einer Anzahl M von 32-Bit Gleitkomma- (oder Ganzzahl-) Operationen ausführen, oder SIMD führen bis zu 2M 16-Bit-Ganzzahl- oder 16-Bit-Gleitkommaoperationen aus. In einer Ausführungsform stellt zumindest eine der FPU(s) erweiterte mathematische Kapazitäten zur Unterstützung von transzendentalen mathematischen Hochdurchsatzfunktionen und doppeltgenauem 64-Bit-Gleitkomma bereit. In einigen Ausführungsformen ist auch ein Satz von 8-Bit-Ganzzahl-SIMD-ALUs 635 vorhanden, der speziell optimiert werden kann, um Operationen in Zusammenhang mit Berechnungen zum maschinellen Lernen durchzuführen.
In einer Ausführungsform können Arrays von mehreren Instanzen der Grafikausführungseinheit 608 in einer Grafiksubkerngruppierung (z.B. einem Subelement) instanziiert sein. Um Skalierbarkeit zu bieten, können Produktarchitekten die genaue Anzahl an Ausführungseinheiten pro Subkerngruppierung auswählen. In einer Ausführungsform kann die Ausführungseinheit 608 Anweisungen in einer Vielzahl von Ausführungskanälen ausführen. In einer weiteren Ausführungsform wird jeder auf der Grafikausführungseinheit 608 ausgeführte Thread auf einem anderen Kanal ausgeführt.
7 ist ein Blockdiagramm, das die Anweisungsformate 700 eines Grafikprozessors gemäß einigen Ausführungsformen veranschaulicht. In einer oder mehreren Ausführungsformen unterstützen die Ausführungseinheiten des Grafikprozessors einen Anweisungssatz mit Anweisungen in mehreren Formaten. Die durchgehend umrandeten Felder zeigen die Komponenten, die im Allgemeinen in einer Anweisung für eine Ausführungseinheit eingeschlossen sind, während die Komponenten mit gestrichelten Linien Komponenten umfassen, die optional sind oder nur in einem Teilsatz der Anweisungen eingeschlossen sind. In einigen Ausführungsformen ist das beschriebene und veranschaulichte Anweisungsformat 700 eine Makroanweisung, da es sich um Anweisungen handelt, die an die Ausführungseinheit geliefert werden, im Gegensatz zu Mikrooperationen, die sich aus der Entschlüsselung von Anweisungen ergeben, sobald die Anweisung verarbeitet wurde.
In einigen Ausführungsformen unterstützen die Grafikprozessorausführungseinheiten nativ Anweisungen in einem 128-Bit-Anweisungsformat 710. Für einige Anweisungen steht ein 64-Bit-komprimiertes Anweisungsformat 730 zur Verfügung, das auf der ausgewählten Anweisung, den Anweisungsoptionen und der Anzahl der Operanden basiert. Das native 128-Bit-Anweisungsformat 710 bietet Zugriff auf alle Anweisungsoptionen, während einige Optionen und Operationen im 64-Bit-Format 730 eingeschränkt sind. Die im 64-Bit-Format 730 verfügbaren nativen Anweisungen variieren je nach Ausführungsform. In einigen Ausführungsformen wird die Anweisung teilweise mit einem Satz von Indexwerten in einem Indexfeld 713 konsolidiert. Die Hardware der Ausführungseinheit referenziert einen Satz von Konsolidierungstabellen basierend auf den Indexwerten und rekonstruiert mit Hilfe der Konsolidierungstabellenausgaben eine native Anweisung im 128-Bit-Anweisungsformat 710.
Der Anweisungsoperationscode 712 definiert für jedes Format die Operation, die die Ausführungseinheit ausführen soll. Die Ausführungseinheiten führen jede Anweisung parallel für die mehreren Datenelemente jedes Operanden aus. Als Reaktion auf eine Addieranweisung führt die Ausführungseinheit beispielsweise eine gleichzeitige Addieroperation für jeden Farbkanal durch, der ein Texturelement oder Bildelement darstellt. Standardmäßig führt die Ausführungseinheit jede Anweisung für alle Datenkanäle der Operanden aus. In einigen Ausführungsformen ermöglicht das Anweisungssteuerungsfeld 714 die Steuerung bestimmter Ausführungsoptionen, wie z.B. Kanalauswahl (z.B. Prädikation) und Datenkanalreihenfolge (z.B. Swizzle). Bei Anweisungen im 128-Bit-Anweisungsformat 710 begrenzt ein Feld 716 in Exec-Größe die Anzahl der Datenkanäle, die parallel ausgeführt werden. In einigen Ausführungsformen ist das Feld 716 in Exec-Größe nicht für die Verwendung im 64-Bit-Kompaktausführungsformat 730 verfügbar.
Einige Ausführungseinheitsbefehle weisen bis zu drei Operanden auf, einschließlich zwei Quelloperanden, src0 720, src1 722, und ein Ziel 718. In manchen Ausführungsformen unterstützen die Ausführungseinheiten Anweisungen mit zwei Zielen, wobei eines der Ziele implizit ist. Datenmanipulationsanweisungen können einen dritten Quelloperanden aufweisen (z.B. SRC2 724), wobei der Anweisungsoperationscode 712 die Anzahl an Quelloperanden bestimmt. Der letzte Quelloperand einer Anweisung kann ein direkter (z.B. fest kodierter) Wert sein, der mit der Anweisung übermittelt wird.
In manchen Ausführungsformen umfasst das 128-Bit-Anweisungsformat 710 ein Zugriffs-/Adressmodusfeld 726, das beispielsweise angibt, ob ein direkter Registeradressierungsmodus oder ein indirekter Registeradressierungsmodus angewendet wird. Wird ein direkter Registeradressierungsmodus verwendet, wird die Registeradresse von einem oder mehreren Operanden durch Bits in der Anweisung direkt bereitgestellt.
In einigen Ausführungsformen umfasst das 128-Bit-Anweisungsformat 710 ein Zugriffs-/Adressmodusfeld 726, das einen Adressmodus und/oder einen Zugriffsmodus für die Anweisung angibt. In einer Ausführungsform wird der Zugriffsmodus verwendet, um eine Datenzugriffsausrichtung für die Anweisung zu definieren. Einige Ausführungsformen unterstützen Zugriffsmodi, einschließlich eines ausgerichteten 16-Byte-Zugriffsmodus und eines ausgerichteten 1-Byte-Zugriffsmodus, wobei die Byteausrichtung des Zugriffsmodus die Zugriffsausrichtung der Anweisungsoperanden bestimmt. In einem ersten Modus kann die Anweisung beispielsweise eine byte-ausgerichtete Adressierung für Quell- und Zieloperanden verwenden, und in einem zweiten Modus kann die Anweisung eine 16-Byte-ausgerichtete Adressierung für alle Quell- und Zieloperanden verwenden.
In einer Ausführungsform bestimmt der Adressmodusteil des Zugriffs-/Adressmodusfelds 726, ob die Anweisung direkte oder indirekte Adressierung verwenden soll. Wird der direkte Registeraddressierungsmodus verwendet, stellen Bits in der Anweisung die Registeradresse von einem oder mehreren Operanden direkt bereit. Wird der indirekte Registeradressierungsmodus verwendet, kann die Registeradresse von einem oder mehreren Operanden auf Grundlage eines Adressregisterwerts und eines Adressdirektfelds in der Anweisung berechnet werden.
In einigen Ausführungsformen werden Anweisungen basierend auf Operationscode-712-Bit-Feldern gruppiert, um die Operationscode-Entschlüsselung 740 zu vereinfachen. Bei einem 8-Bit-Operationscode ermöglichen die Bits 4, 5 und 6 der Ausführungseinheit das Bestimmen der Art des Operationscodes. Die dargestellte genaue Operationscodegruppierung ist nur ein Beispiel. In einigen Ausführungsformen umfasst eine Verschiebungs- und Logik-Operationscodegruppe 742 Datenübertragung und Logikanweisungen (z.B. Verschieben (mov), Vergleichen (cmp)). In einigen Ausführungsformen teilt sich die Verschiebungs- und Logikgruppe 742 die fünf höchstwertigen Bits (MSB), wobei die Verschiebungs- (mov) Anweisungen in Form von 0000xxxxb und die Logikanweisungen in Form von 0001xxxxb vorliegen. Eine Flusssteuerungsanweisungsgruppe 744 (z.B. Aufruf, Überspringen (jmp)) umfasst Anweisungen in Form von 0010xxxxb (z.B. 0x20). Eine sonstige Anweisungsgruppe 746 umfasst gemischte Anweisungen, einschließlich Synchronisationsanweisungen (z.B. Warten, Senden) in Form von 001 Ixxxxb (z.B. 0x30). Eine parallele mathematische Anweisungsgruppe 748 umfasst komponentenweise arithmetische Anweisungen (z.B. addieren, multiplizieren (mul)) in Form von 0100xxxxb (z.B. 0x40). Die parallele Mathematikgruppe 748 führt die arithmetischen Operationen parallel für alle Datenkanälen durch. Die Vektor-Mathematikgruppe 750 umfasst arithmetische Anweisungen (z.B. dp4) in Form von 0101xxxxb (z.B. 0x50). Die Vektor-Mathematik-Gruppe führt arithmetische Vorgänge wie z.B. Skalarproduktberechnungen an Vektoroperanden durch.
Grafik-Pipeline
8 ist ein Blockdiagramm einer weiteren Ausführungsform eines Grafikprozessors 800. Elemente aus 8, die dieselben Bezugszeichen (oder Bezeichnungen) aufweisen wie die Elemente in irgendeiner anderen Figur, können in ähnlicher Weise wie an anderer Stelle hierin beschrieben betrieben werden oder funktionieren, sind aber nicht darauf beschränkt.
In einigen Ausführungsformen umfasst der Grafikprozessor 800 eine Geometrie-Pipeline 820, eine Medien-Pipeline 830, ein Anzeigeengine 840, eine Thread-Ausführungslogik 850 und eine Renderausgabe-Pipeline 870. In einigen Ausführungsformen ist der Grafikprozessor 800 ein Grafikprozessor innerhalb eines Multicore-Verarbeitungssystems, das einen oder mehrere Universalverarbeitungskerne umfasst. Der Grafikprozessor wird durch das Schreiben von Registern in ein oder mehrere Steuerregister (nicht dargestellt) oder durch an den Grafikprozessor 800 ausgegebene Befehle über eine Ringverbindung 802 gesteuert. In einigen Ausführungsformen koppelt die Ringverbindung 802 den Grafikprozessor 800 mit anderen Verarbeitungskomponenten, wie beispielsweise anderen Grafikprozessoren oder Universalprozessoren. Befehle aus der Ringverbindung 802 werden durch einen Befehlsstreamer 803 interpretiert, der Anweisungen zu einzelnen Komponenten der Geometrie-Pipeline 820 oder der Medien-Pipeline 830 zuführt.
In einigen Ausführungsformen leitet der Befehlsstreamer 803 die Operation einer Vertex-Abrufvorrichtung 805, der Vertex-Daten aus dem Speicher ausliest und Befehle zur Vertex-Verarbeitung ausführt, die vom Befehlsstreamer 803 bereitgestellt werden. In einigen Ausführungsformen stellt die Vertex-Abrufvorrichtung 805 Vertex-Daten einem Vertex-Shader 807 zur Verfügung, der Koordinatenraumtransformations- und Beleuchtungsoperationen an jedem Vertex durchführt. In einigen Ausführungsformen führen die Vertex-Abrufvorrichtung 805 und der Vertex-Shader 807 Vertex-Verarbeitungsanweisungen aus, indem sie Ausführungs-Threads über einen Thread-Dispatcher 831 an die Ausführungseinheiten 852A-852B vermitteln.
In manchen Ausführungsformen sind Ausführungseinheiten 852A-852B ein Array von Vektorprozessoren mit einem Anweisungssatz zur Durchführung von Grafik- und Medienoperationen. In manchen Ausführungsformen weisen die Ausführungseinheiten 852A-852B einen angeschlossenen L1-Cache-Speicher 851 auf, der für jedes Array spezifisch ist oder von den Arrays gemeinsam genutzt wird. Der Cache-Speicher kann als Daten-Cache-Speicher, als Anweisungs-Cache-Speicher oder als einzelner Cache-Speicher konfiguriert sein, der partitioniert wird, um Daten und Anweisungen in unterschiedlichen Partitionen zu enthalten.
In einigen Ausführungsformen umfasst die Geometrie-Pipeline 820 Tesselationskomponenten, um hardwarebeschleunigte Tesselationen von 3D-Objekten durchzuführen. In einigen Ausführungsformen konfiguriert ein programmierbarer Hull-Shader 811 die Tesselationsoperationen. Ein programmierbarer Domain-Shader 817 ermöglicht die Backend-Auswertung der Tesselationsausgabe. Ein Tessellator 813 arbeitet in Richtung des Hull-Shaders 811 und enthält eine spezielle Logik, um einen Satz detaillierter geometrischer Objekte basierend auf einem groben geometrischen Modell zu erzeugen, das als Eingabe an der Geometrie-Pipeline 820 bereitgestellt ist. In einigen Ausführungsformen können Tesselationskomponenten (z.B. Hull-Shader 811, Tessellator 813 und Domain-Shader 817) umgangen werden, wenn keine Tesselation angewendet wird.
In einigen Ausführungsformen können vollständige geometrische Objekte von einem Geometrie-Shader 819 über einen oder mehrere Threads verarbeitet werden, die an die Ausführungseinheiten 852A-852B vermittelt werden, oder direkt zum Clipper 829 weitergeleitet werden. In einigen Ausführungsformen arbeitet der Geometrie-Shader mit vollständigen geometrischen Objekten und nicht mit Vertizes oder Vertex-Teilen wie in bei früheren Schritten entlang der Grafik-Pipeline. Wenn die Tesselation deaktiviert ist, empfängt der Geometrie-Shader 819 Eingaben vom Vertex-Shader 807. In einigen Ausführungsformen ist der Geometrie-Shader 819 durch ein Geometrie-Shader-Programm programmierbar, um eine Geometrie-Tesselation durchzuführen, wenn die Tessellationseinheiten deaktiviert sind.
Vor der Rasterisierung kann ein Clipper 829 Vertex-Daten verarbeiten. Der Clipper 829 kann ein Clipper mit fixer Funktion oder ein programmierbarer Clipper mit Clipping- und Geometrie-Shader-Funktionen sein. In einigen Ausführungsformen vermittelt eine Raster- und eine Tiefenprüfkomponente 873 in der Renderausgabe-Pipeline 870 Pixel-Shader, um die geometrischen Objekte in Pro-Pixel-Darstellungen zu konvertieren. In einigen Ausführungsformen ist die Pixel-Shader-Logik Teil der Thread-Ausführungslogik 850. In einigen Ausführungsformen kann eine Anwendung die Raster- und Tiefenprüfkomponente 873 umgehen und über eine Stream-Out-Einheit 823 auf nicht gerasterte Vertex-Daten zugreifen.
Der Grafikprozessor 800 weist einen Verbindungsbus, ein Verbindungsgefüge oder einen anderen Verbindungsmechanismus auf, der den Daten- und Nachrichtenaustausch zwischen den Hauptkomponenten des Prozessors ermöglicht. In einigen Ausführungsformen verbinden sich die Ausführungseinheiten 852A-852B und die zugehörigen Logikeinheiten (z.B. L1-Cache 851, Sampler 854, Textur-Cache 858 usw.) über einen Datenport 856, um Speicherzugriff durchzuführen und mit den Komponenten der Renderausgabe-Pipeline des Prozessors zu kommunizieren. In einigen Ausführungsformen weisen Sampler 854, Cache-Speicher 851, 858 und Ausführungseinheiten 852A-852B jeweils separate Speicherzugriffspfade auf. In einer Ausführungsform kann der Textur-Cache-Speicher 858 auch als Sampler-Cache-Speicher konfiguriert sein.
In einigen Ausführungsformen umfasst die Renderausgabe-Pipeline 870 eine Raster- und Tiefenprüfkomponente 873, die vertexbasierte Objekte in eine entsprechende pixelbasierte Darstellung umwandelt. In einigen Ausführungsformen umfasst die Rasterlogik eine Windower-/Maskierungseinheit, um eine Dreiecks- und Linienrasterung mit fixer Funktion durchzuführen. Ein zugehöriger Render-Cache-Speicher 878 und Tiefen-Cache-Speicher 879 sind in einigen Ausführungsformen ebenfalls verfügbar. Eine Pixeloperationenkomponente 877 führt pixelbasierte Operationen in Bezug auf die Daten durch, obwohl in einigen Fällen Pixeloperationen, die 2D-Operationen zugeordnet sind (z.B. Bitblockbildübertragungen mit Blending), von dem 2D-Engine 841 durchgeführt oder durch die Anzeigesteuerungvorrichtung 843 unter Verwendung von Überlagerungsanzeigeebenen zum Zeitpunkt des Anzeigens ersetzt werden. In einigen Ausführungsformen steht allen Grafikkomponenten ein gemeinsamer L3-Cache-Speicher 875 zur Verfügung, der die gemeinsame Nutzung von Daten ohne Verwendung des Hauptsystemspeichers ermöglicht.
In einigen Ausführungsformen umfasst die Grafikprozessor-Medien-Pipeline 830 einen Medienengine 837 und ein Video-Frontend 834. In einigen Ausführungsformen empfängt das Video-Frontend 834 Pipeline-Befehle von dem Befehlsstreamer 803. In einigen Ausführungsformen umfasst die Medien-Pipeline 830 einen separaten Befehlsstreamer. In einigen Ausführungsformen verarbeitet das Video-Frontend 834 Medienbefehle, bevor es den Befehl an den Medienengine 837 sendet. In einigen Ausführungsformen umfasst den Medienenginee 837 eine Thread-Spawning-Funktionalität zum Initiieren von Threads für die Vermittlung über den Thread-Dispatcher 831 an die Thread-Ausführungslogik 850.
In einigen Ausführungsformen umfasst der Grafikprozessor 800 einen Anzeigeengine 840. In einigen Ausführungsformen liegt der Anzeigeengine 840 extern in Bezug auf den Prozessor 800 vor und ist über die Ringverbindung 802 oder einen anderen Verbindungsbus oder ein anderes Verbindungsgefüge mit dem Grafikprozessor gekoppelt. In einigen Ausführungsformen umfasst der Anzeigeengine 840 einen 2D-Engine 841 und eine Anzeigesteuerungvorrichtung 843. In einigen Ausführungsformen umfasst der Anzeigeengine 840 eine spezielle Logik, die unabhängig von der 3D-Pipeline arbeiten kann. In einigen Ausführungsformen ist die Anzeigesteuerungvorrichtung 843 mit einer Anzeigevorrichtung (nicht dargestellt) gekoppelt, die eine systemintegrierte Anzeigevorrichtung, wie in einem Laptop, oder eine externe Anzeigevorrichtung sein kann, die über eine Anzeigevorrichtungsverbindungsvorrichtung angeschlossen ist.
In einigen Ausführungsformen sind die Geometrie-Pipeline 820 und die Medien-Pipeline 830 konfigurierbar, um Operationen auf der Grundlage von mehreren Grafik- und Medienprogrammierschnittstellen durchzuführen, und sind nicht spezifisch für eine einzige Anwendungsprogrammierschnittstelle (API). In einigen Ausführungsformen übersetzt die Treibersoftware für den Grafikprozessor API-Aufrufe, die spezifisch für eine bestimmte Grafik- oder Medienbibliothek sind, in Befehle, die durch den Grafikprozessor verarbeitet werden können. In einigen Ausführungsformen werden die Open Graphics Library (OpenGL), Open Computing Language (OpenCL) und/oder Vulkan Graphics and Compute API, alle von der Khronos Group, unterstützt. In einigen Ausführungsformen kann auch die Direct3D-Bibliothek der Microsoft Corporation unterstützt werden. In einigen Ausführungsformen kann eine Kombination dieser Bibliotheken unterstützt werden. Auch die Open Source Computer Vision Library (OpenCV) kann unterstützt werden. Eine zukünftige API mit einer kompatiblen 3D-Pipeline würde auch unterstützt werden, wenn von der Pipeline der zukünftigen API eine Zuordnung zu der Pipeline des Grafikprozessors vorgenommen werden kann.
Grafik-Pipeline-Programmierung
9A ist ein Blockdiagramm, das ein Grafikverarbeitungsbefehlsformat 900 gemäß manchen Ausführungsformen veranschaulicht. 9B ist ein Blockdiagramm, das eine Grafikverarbeitungsbefehlssequenz 910 gemäß einer Ausführungsform veranschaulicht. Die mit durchgezogenen Linien gezeichneten Kästen in 9A veranschaulichen die Komponenten, die allgemein in einen Grafikbefehl eingebunden sind, während die gestrichelten Linien Komponenten umfassen, die optional sind, oder die nur in einem Subsatz der Grafikbefehle umfasst sind. Das beispielhafte Grafikverarbeitungsbefehlsformat 900 aus 9A umfasst Datenfelder, um einen Client 902 zu identifizieren, einen Befehlsoperationscode (Opcode) 904 und Daten 906 für den Befehl. Ein Sub-Opcode 905 und eine Befehlsgröße 908 sind auch in manchen Befehlen umfasst.
In manchen Ausführungsformen spezifiziert Client 902 die Client-Einheit der Grafikvorrichtung, die die Befehlsdaten verarbeitet. In manchen Ausführungsformen untersucht ein Grafikverarbeitungsbefehlsparser das Client-Feld jedes Befehls, um das weitere Verarbeiten des Befehls zu bestimmen und um die Befehlsdaten zu der geeigneten Client-Einheit zu leiten. In manchen Ausführungsformen umfassen die Grafikverarbeitungs-Client-Einheiten eine Speicherschnittstelleneinheit, eine Render-Einheit, eine 2D-Einheit, eine 3D-Einheit und eine Medieneinheit. Jede Client-Einheit weist eine entsprechende Verarbeitungs-Pipeline auf, die die Befehle verarbeitet. Wurde der Befehl von der Client-Einheit empfangen, liest die Client-Einheit den Opcode 904 und, wenn vorhanden, den Sub-Opcode 905 aus, um die auszuführende Operation zu bestimmen. Die Client-Einheit führt den Befehl unter Verwendung von Informationen in dem Datenfeld 906 aus. Für solche Befehle wird eine explizite Befehlsgröße 908 erwartet, um die Größe des Befehls zu spezifizieren. In manchen Ausführungsformen bestimmt der Befehlsparser automatisch die Größe von zumindest einem der Befehle, basierend auf dem Befehls-Opcode. In manchen Ausführungsformen werden Befehle über ein Vielfaches eines Doppelworts abgeglichen.
Das Flussdiagramm in 9B veranschaulicht eine beispielhafte Grafikverarbeitungsbefehlssequenz 910. In manchen Ausführungsformen verwendet Software oder Firmware eines Datenverarbeitungssystems, das eine Ausführungsform eines Grafikprozessors enthält, eine Version der Befehlssequenz, die angezeigt wird, um einen Satz von Grafikoperationen einzurichten, auszuführen und zu beenden. Eine Beispielbefehlssequenz wird nur als Beispiel gezeigt und beschrieben und ist nicht auf diese spezifischen Befehle oder auf diese Befehlssequenz eingeschränkt. Darüber hinaus können Befehle als Stapelbefehle in einer Befehlssequenz ausgegeben werden, sodass der Grafikprozessor die Befehlssequenz in zumindest teilweise Übereinstimmung verarbeitet.
In manchen Ausführungsformen kann die Grafikverarbeitungskommandosequenz 910 mit einem Befehl zum Leeren der Pipeline 912 beginnen, um zu bewirken, dass eine beliebige aktive Grafik-Pipeline die aktuell ausstehenden Befehle für die Pipeline durchführt. In manchen Ausführungsformen arbeiten die 3D-Pipeline 922 und die Medien-Pipeline 924 nicht gleichzeitig. Das Leeren der Pipeline wird durchgeführt, um zu bewirken, dass die aktive Grafik-Pipeline beliebige ausstehende Befehle durchführt. Als Reaktion auf ein Leeren der Pipeline pausiert der Befehlsparser für den Grafikprozessor die Befehlsverarbeitungseinheit, bis die nächsten aktiven Zeichenengines ausstehende Operationen durchführen und die relevanten LeseCache-Speichern invalidiert sind. Gegebenenfalls können beliebige Daten in dem Render-Cache, die als „schmutzig“ markiert sind, zum Speicher übertragen werden. In manchen Ausführungsformen kann ein Befehl zum Leeren der Pipeline 912 für eine Pipeline-Synchronisierung verwendet werden, oder bevor der Grafikprozessor in einen Niedrigleistungszustand gebracht wird.
In manchen Ausführungsformen wird ein Pipeline-Auswahlbefehl 913 verwendet, wenn eine Befehlssequenz erfordert, dass der Grafikprozessor explizit zwischen Pipelines wechselt. In manchen Ausführungsformen ist ein Pipeline-Auswahlbefehl 913 nur einmal in einem Ausführungskontext erforderlich, bevor Pipeline-Befehle ausgegeben werden, es sei denn, der Kontext ist es, Befehle für beide Pipelines auszugeben. In manchen Ausführungsformen ist ein Befehl zum Leeren der Pipeline 912 unmittelbar vor einem Pipelinewechsel über den Pipeline-Auswahlbefehl 913 erforderlich.
In manchen Ausführungsformen konfiguriert ein Pipelinesteuerungsbefehl 914 eine Grafik-Pipeline für den Betrieb und wird verwendet, um die 3D-Pipeline 922 und die Medien-Pipeline 924 zu programmieren. In manchen Ausführungsformen konfiguriert der Pipelinesteuerungsbefehl 914 den Pipeline-Status für die aktive Pipeline. In einer Ausführungsform wird der Pipelinesteuerungsbefehl 914 für die Pipeline-Synchronisierung verwendet, und um Daten innerhalb der aktiven Pipeline aus einem oder mehreren Cache-Speichern zu löschen, bevor ein Stapel von Befehlen verarbeitet wird.
In manchen Ausführungsformen werden Rückgabepuffer-Statusbefehle 916 verwendet, um einen Satz von Rückgabepuffern für die entsprechenden Pipelines zu konfigurieren, um Daten zu schreiben. Manche Pipelineoperation erfordern die Zuweisung, Auswahl oder Konfiguration eines oder mehrere Rückgabepuffer in die die Operationen während der Verarbeitung Zwischendaten schreiben. In manchen Ausführungsformen verwendet der Grafikprozessor auch einen oder mehrere Rückgabepuffer, um Ausgabedaten zu speichern und um Cross-Thread-Kommunikation durchzuführen. In manchen Ausführungsformen umfasst der Rückgabepufferstatus 916 die Auswahl der Größe und der Anzahl von Rückgabepuffern, die für einen Satz von Pipeline-Operationen verwendet werden.
Die verbleibenden Befehle in der Befehlssequenz unterscheiden sich basierend auf der aktiven Pipeline für Operationen. Basierend auf einer Pipeline-Bestimmung 920 ist die Befehlssequenz auf die 3D-Pipeline 922, die mit dem 3D-Pipelinestatus 930 beginnt oder die Medien-Pipeline 924 zugeschnittene die bei dem Medien-Pipelinestatus 940 beginnt.
Die Befehle, um den 3D-Pipelinestatus 930 zu konfigurieren, umfassen 3D-Statuseinstellungsbefehle für den Vertex-Pufferstatus, Vertex-Elementstatus, konstanten Farbstatus, Tiefenpufferstatus und andere Statusvariablen, die zu konfigurieren sind, bevor 3D-Grundkörper-Befehle verarbeitet werden. Die Werte diese Befehle werden zumindest teilweise basierend auf der spezifischen verwendeten 3D-API bestimmt. In manchen Ausführungsformen sind 3D-Pipelinestatus- 930 Befehle auch in der Lage, selektiv bestimmte Pipelineelemente zu deaktivieren oder zu umgehen, wenn diese Elemente nicht verwendet werden.
In manchen Ausführungsformen wird ein 3D-Grundkörper 932 -Befehl verwendet, um 3D-Grundkörper vorzulegen, die von der 3D-Pipeline zu verarbeiten sind. Befehle und damit verbundene Parameter, die über den 3D-Grundkörper 932 -Befehl an den Grafikprozessor geleitet werden, werden an die Vertex-Abruf-Funktion in der Grafik-Pipeline weitergeleitet. Die Vertex-Abruf-Funktion verwendet die 3D-Grundkörper- 932 - Befehlsdaten, um Vertex-Datenstrukturen zu erzeugen. Die Vertex-Datenstrukturen werden in einem oder mehreren Rückgabepuffern gespeichert. In manchen Ausführungsformen wird ein 3D-Grundkörper 932 -Befehl verwendet, um Vertex-Operationen auf 3D-Grundkörpern mittels Vertex-Shader durchzuführen. Um Vertex-Shader zu verarbeiten, sendet die 3D-Pipeline 922 Shader-Ausfiihrungsthreads an Grafikverarbeitungsausführungseinheiten.
In manchen Ausführungsformen wird die 3D-Pipeline 922 über einen Ausführungsbefehl 934 oder ein Ereignis getriggert. In manchen Ausführungsformen löst ein Registerschreiben die Befehlsausführung aus. In manchen Ausführungsformen wird die Ausführung durch einen „Los“- oder „Start“-Befehl in der Befehlssequenz ausgelöst. In einer Ausführungsform wird die Befehlsausführung unter Verwendung eines Pipeline-Synchronisierungsbefehls ausgelöst, um die Befehlssequenz durch die Grafik-Pipeline zu leiten. Die 3D-Pipeline führt eine Geometrieverarbeitung für die 3D-Grundkörper durch. Sind die Operationen vollständig, werden die resultierenden geometrischen Objekte gerastert und der Pixel-Engine färbt die resultierenden Pixel. Zusätzliche Befehle, um die Pixelfarbe und Pixel-Backend-Operationen zu steuern, können auch für diese Operationen umfasst sein.
In manchen Ausführungsformen folgt die Grafikverarbeitungsbefehlssequenz 910 dem Medien-Pipeline- 924 -Pfad, wenn Medienoperationen durchgeführt werden. Allgemein hängt die spezifische Verwendung und Programmierungsart für die Medien-Pipeline 924 von den durchzuführenden Medien- oder Rechenoperationen ab. Spezifische Medien-Entschlüsselungsoperationen können während der Medien-Entschlüsselung auf die Medien-Pipeline abgeladen werden. In manchen Ausführungsformen kann die Medien-Pipeline auch umgangen werden und es kann eine Medien-Entschlüsselung vollständig oder teilweise unter Verwendung von Ressourcen durchgeführt werden, die von einem oder mehreren universellen Verarbeitungskernen bereitgestellt sind. In einer Ausführungsform umfasst die Medien-Pipeline auch Elemente für universelle Grafikverarbeitungseinheits- (GPGPU) -Operationen, wo der Grafikprozessor verwendet wird, um SIMD-Vektor-Operationen unter Verwendung von rechnergestützten Shader-Programmen durchzuführen, die nicht explizit in Verbindung Rendern von Grafik-Grundkörpern stehen.
In manchen Ausführungsformen ist die Medien-Pipeline 924 auf ähnliche Weise wie die 3D-Pipeline 922 konfiguriert. Ein Satz von Befehlen, um den Medien-Pipelinestatus 940 zu konfigurieren, wird versendet oder vor den Medienobjektbefehlen 942 in eine Befehlsschlange platziert. In manchen Ausführungsformen umfassen Befehle für den Medien-Pipelinestatus 940 Daten, um die Medien-Pipeline-Elemente zu konfigurieren, die verwendet werden, um die Medienobjekte zu verarbeiten. Dies umfasst Daten, um die Video-Entschlüsselungs- und Video-Kodier-Logik innerhalb der Medien-Pipeline zu konfigurieren, wie z. B. das Kodier- oder Entschlüsselungsformat. In manchen Ausführungsformen unterstützen Befehle für den Medien-Pipeline-Status 940 auch die Verwendung einer oder mehrerer Hinweisadressen zu „indirekten“ Statuselemente, die einen Stapel von Statuseinstellungen enthalten.
In manchen Ausführungsformen stellen Medienobjektbefehle 942 Hinweisadressen zu Medienobjekten zur Verarbeitung durch die Medien-Pipeline bereit. Die Medienobjekte umfassen Speicherpuffer, die zu verarbeitende Videodaten enthalten. In manchen Ausführungsformen müssen alle Medien-Pipeline-Status gültig sein, bevor ein Medienobjektbefehl 942 ausgegeben wird. Wurde der Pipeline-Status konfiguriert und die Medienobjektbefehle 942 gereiht, wird die Medien-Pipeline 924 durch einen Ausführungsbefehl 944 oder ein äquivalentes Durchführungsereignis (z. B. Registierungsschreiben) getriggert. Die Ausgabe der Medien-Pipeline 924 kann dann durch Operationen nachverarbeitet werden, die von der 3D-Pipeline 922 oder der Medien-Pipeline 924 bereitgestellt sind. In manchen Ausführungsformen werden GPGPU-Operationen auf ähnliche Weise wie Medienoperationen konfiguriert und ausgeführt.
Grafik- Softwarearchitektur
10 veranschaulicht eine beispielhafte Grafik-Softwarearchitektur für ein Datenverarbeitungssystem 1000 gemäß manchen Ausführungsformen. In manchen Ausführungsformen umfasst die Softwarearchitektur eine 3D-Grafikanwendung 1010, ein Betriebssystem 1020 und zumindest einen Prozessor 1030. In manchen Ausführungsformen umfasst Prozessor 1030 einen Grafikprozessor 1032 und einen oder mehrere universelle Verarbeitungskerne 1034. Die Grafikanwendung 1010 und das Betriebssystem 1020 führen beide in dem Systemspeicher 1050 des Datenverarbeitungssystems aus.
In manchen Ausführungsformen enthält die 3D-Grafikanwendung 1010 ein oder mehrere Shader-Programm einschließlich Shader-Anweisungen 1012. Die Shader-Sprachanweisungen können in einer High-Level-Shader-Sprache (HLSL) oder der OpenGL-Shader-Sprache (GLSL) vorliegen. Die Anwendung umfasst auch ausführbare Anweisungen 1014 in einer Maschinensprache, die für die Ausführung durch den universellen Verarbeitungskern 1034 geeignet ist. Die Anwendung umfasst auch Grafikobjekte 1016, die durch Vertex-Daten definiert sind.
In manchen Ausführungsformen ist das Betriebssystem 1020 ein Microsoft® Windows®-Betriebssystem der Microsoft Corporation, ein proprietäres UNIX-ähnliches Betriebssystem oder ein Open-Source-UNIX-ähnliches Betriebssystem, das eine Variante des Linux-Kernel verwendet. Das Betriebssystem 1020 kann eine Grafik-API 1022 wie z. B. die Direct3D-API, die OpenGL-API, oder die Vulkan-API unterstützen. Ist die Direct3D-API in Verwendung, verwendet das Betriebssystem 1020 einen Front-End-Shader-Compiler 1024, um beliebige Shader-Anweisungen 1012 in HLSL in eine untergeordnete Shader-Sprache zu kompilieren. Die Kompilierung kann eine Just-in-Time(JIT)-Kompilierung sein oder die Anwendung kann eine Shader-Vor-Kompilierung durchführen. In manchen Ausführungsformen werden High-Level-Shader während der Kompilierung der 3D-Grafikanwendung 1010 in Low-Level-Shader kompiliert. In manchen Ausführungsformen werden die Shader-Anweisungen 1012 in einer Zwischenform bereitgestellt, wie z. B. einer Version von der Vulkan-API verwendeten Standard-Portable-Intermediate-Repräsentation (SPIR).
In manchen Ausführungsformen enthält der Benutzermodus-Grafiktreiber 1026 einen Back-End-Shader-Compiler 1027, um die Shader-Anweisungen 1012 in eine Hardwarespezifische Darstellung zu konvertieren. Ist die OpenGL-API in Verwendung, werden Shader-Anweisungen 1012 in der GLSL-High-Level-Sprache für die Kompilierung in einen Benutzermodus-Grafiktreiber 1026 geleitet. In manchen Ausführungsformen verwendet der Benutzermodus-Grafiktreiber 1026 Betriebssystem-Kernel-Modusfunktionen 1028, um mit einem Kernel-Modus-Grafiktreiber 1029 zu kommunizieren. In manchen Ausführungsformen kommuniziert der Kernel-Modus-Grafiktreiber 1029 mit dem Grafikprozessor 1032, um Befehle und Anwendungen abzusenden.
IP-Core-Implementierungen
Ein oder mehrere Aspekte zumindest 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 z. B. eines Prozessors repräsentiert und/oder definiert. Beispielsweise kann das maschinenlesbare Medium Anweisungen umfassen, die verschiedene Logik innerhalb des Prozessors darstellen. Werden sie von einer Maschine ausgelesen, können die Anweisungen bewirken, dass die Maschine die Logik herstellt, um die hierin beschriebenen Techniken durchzuführen. Solche Repräsentationen, bekannt als „IP-Cores“ sind wiederverwendbare Logikeinheiten für eine integrierte Schaltung, die auf einem greifbaren, maschinenlesbaren Medium als Hardwaremodell gespeichert werden, das die Struktur der integrierten Schaltung beschreibt. Das Hardware-Modell kann unterschiedlichen Kunden oder Fertigungseinrichtungen bereitgestellt werden, die das Hardwaremodell auf Fertigungsmaschinen laden, die die integrierte Schaltung fertigen. Die integrierte Schaltung kann so erstellt werden, dass die Schaltung Operationen durchführt, die in Verbindung mit einer beliebigen der hierin beschriebenen Ausführungsformen beschrieben werden.
11A ist ein Blockdiagramm, das ein IP-Core-Entwicklungssystem 1100 veranschaulicht, das verwendet werden kann, um eine integrierte Schaltung zu fertigen, die Operationen gemäß einer Ausführungsform durchführt. Das IP-Core-Entwicklungssystem 1100 kann verwendet werden, um modulare, wiederverwendbare Designs herzustellen, die in ein größeres Design inkorporiert werden können, um eine ganze integrierte Schaltung (z. B. eine SOC-integrierte Schaltung) zu konstruieren. Eine Designeinrichtung 1130 kann eine Software-Simulation 1110 eines IP-Core-Designs in einer High-Level-Programmiersprache (z. B. C/C++) generieren. Die Software-Simulation 1110 kann verwendet werden, um das Verhalten des IP-Cores unter Verwendung eines Simulationsmodells 1112 zu gestalten, zu testen und zu verifizieren. Das Simulationsmodell 1112 kann Funktions-, Verhaltens- und/oder Timing-Simulationen umfassen. Ein Registertransferebenen(RTL)-Design 1115 kann dann aus dem Simulationsmodell 1112 erstellt oder synthetisiert werden. Das RTL-Design 1115 ist eine Abstraktion des Verhaltens der integrierten Schaltung, die den Strom von digitalen Signalen zwischen Hardwareregistern modellieren, einschließlich der assoziierten Logik, die unter Verwendung der modellierten digitalen Signale durchgeführt wird. Zusätzlich zu einem RTL-Design 1115 können auch Designs einer niedrigeren Ebene auf der Logikebene oder der Transistorebene hergestellt, entworfen oder synthetisiert werden. Daher können die bestimmten Details des anfänglichen Designs oder der Simulation variieren.
Das RTL-Design 1115 oder ein Äquivalent kann weiters durch die Designeinrichtung in ein Hardwaremodell 1120 synthetisiert werden, das in einer Hardwarebeschreibungssprache (HDL) sein kann, oder durch eine andere Darstellung von physikalischen Designdaten. Die HDL kann ferner simuliert oder getestet werden, um das IP-Core-Design zu verifizieren. Das IP-Core-Design kann für die Lieferung an eine Drittparteienfertigungseinrichtung 1165 unter Verwendung eines nicht volatilen Speichers 1140 (z.B. Festplatte, FLASH-Speicher oder eines beliebigen nichtflüchtigen Speichermediums) gespeichert werden. Alternativ dazu kann das IP-Core-Design (z. B. über das Internet) über eine verdrahtete Verbindung 1150 oder eine drahtlose Verbindung 1160 übertragen werden. Die Fertigungseinrichtung 1165 kann dann eine integrierte Schaltung fertigen, die zumindest teilweise auf dem IP-Core-Design basiert. Die gefertigte integrierte Schaltung kann konfiguriert sein, um Operationen gemäß zumindest einer hierin beschriebenen Ausführungsform durchführen.
11B veranschaulicht eine Querschnittsseitenansicht einer integrierten Schaltungsgehäuseanordnung 1170 gemäß manchen hierin beschriebenen Ausführungsformen. Die integrierte Schaltungsgehäuseanordnung 1170 veranschaulicht eine Implementierung eines oder mehrerer Prozessoren oder Beschleunigungsvorrichtungen wie hierin beschrieben. Die Gehäuseanordnung 1170 umfasst mehrere Einheiten von Hardwarelogik 1172, 1174, die mit einem Substrat 1180 verbunden ist. Die Logik 1172, 1174 kann zumindest teilweise in konfigurierbare Logik oder Logik-Hardware mit fester Funktionalität implementiert werden und kann eine oder mehrere Abschnitte eines beliebigen der Prozessorkerne, Grafikprozessoren oder anderen hierin beschriebenen Beschleunigungsvorrichtungen umfassen. Jede Logikeinheit 1172, 1174 kann mit einem Halbleiterchip implementiert sein und mit dem Substrat 1180 über eine Verbindungsstruktur 1173 gekoppelt sein. Die Verbindungsstruktur 1173 kann konfiguriert sein, um elektrische Signale zwischen der Logik 1172, 1174 und dem Substrat 1180 zu leiten und kann Verbindungen wie z. B. Höcker und Säulen umfassen, sind jedoch nicht darauf eingeschränkt. In manchen Ausführungsformen kann die Verbindungsstruktur 1173 konfiguriert sein, um elektrische Signale, wie z, B. Eingabe/Ausgabe- (I/O)- Signale und/oder Leistungs- oder Massesignale, die der Operation der Logik 1172, 1174 zugeordnet sind, zu leiten. In manchen Ausführungsformen ist das Substrat 1180 ein Epoxy-basiertes Laminatsubstrat. Das Gehäusesubstrat 1180 kann andere geeignete Substrattypen in anderen Ausführungsformen umfassen. Die Gehäuseanordnung 1170 kann mit anderen elektrischen Vorrichtungen über eine Gehäuseverbindung 1183 verbunden sein. Die Gehäuseverbindung 1183 kann mit einer Oberfläche des Substrats 1180 gekoppelt sein, um elektrische Signale zu anderen elektrischen Vorrichtungen zu leiten, wie z. B. einer Hauptplatine, einem anderen Chipsatz oder einem Multi-Chip-Modul.
In manchen Ausführungsformen sind die Logikeinheiten 1172, 1174 elektrisch mit einer Brücke 1182 gekoppelt, die konfiguriert ist, um elektrische Signale zwischen der Logik 1172, 1174 zu leiten. Die Brücke 1182 kann eine dichte Verbindungsstruktur sein, die einen Pfad für elektrische Signale bereitstellt. Die Brücke 1182 kann ein Brückensubstrat umfassen, das aus Glas oder einem geeigneten Halbleitermaterial besteht. Elektrische Routing-Funktionen können auf dem Brückensubstrat gebildet werden, um eine Chip-an-Chip-Verbindung zwischen der Logik 1172, 1174 bereitzustellen.
Obwohl zwei Logikeinheiten 1172, 1174 und eine Brücke 1182 veranschaulicht sind, können hierin beschriebene Ausführungsformen mehr oder weniger Logikeinheiten auf mehr oder weniger Chips umfassen. Der eine oder die mehreren Chips können über null oder mehr Brücken verbunden sein, da die Brücke 1182 ausgeschlossen werden kann, wenn die Logik auf einem einzelnen Chip umfasst ist. Alternativ dazu können mehrere Chips oder Logikeinheiten über ein oder mehrere Brücken verbunden sein. Zusätzlich dazu können mehrere. Logikeinheiten, Chips und Brücken zusammen in anderen möglichen Konfigurationen verbinden sein, einschließlich dreidimensionaler Konfigurationen.
Beispielhaftes System auf einer integrierten Chip-Schaltung
12-14 veranschaulichen beispielhafte integrierte Schaltungen und verbundene Grafikprozessoren, die gemäß verschiedenen hierin beschriebenen Ausführungsformen unter Verwendung eines oder mehrere IP-Cores gefertigt werden können. Zusätzlich zu dem Veranschaulichten können andere Logiken und Schaltungen umfasst sein, einschließlich zusätzlicher Grafikprozessoren/Cores, peripherer Schnittstellensteuereinrichtungen oder universelle Verarbeitungskerne.
12 ist ein Blockdiagramm, das ein beispielhaftes System auf einer integrierten Chipschaltung 1200 veranschaulicht, das unter Verwendung einer oder mehrerer IP-Cores gefertigt werden kann, gemäß einer Ausführungsform. Die beispielhafte integrierte Schaltung 1200 umfasst einen oder mehrere Anwendungsprozessoren 1205 (z. B. CPUs), zumindest einen Grafikprozessor 1210 und kann zusätzlich einen Bildprozessor 1215 und/oder einen Videoprozessor 1220 umfassen, wobei ein beliebiger davon ein modularer IP-Core von derselben oder mehrerer unterschiedlicher Designeinrichtungen sein kann. Die integrierte Schaltung 1200 umfasst eine periphere oder Bus-Logik, einschließlich einer USB-Steuereinrichtung 1225, UART-Steuereinrichtung 1230, einer SPI/SDIO-Steuereinrichtung 1235 und einer I²S/I²C-Steuereinrichtung 1240. Zusätzlich dazu kann die integrierte Schaltung eine Anzeigevorrichtung 1245 umfassen, die an eine oder mehrere einer High-Definition-Multimedia-Schnittstelle(HDMI)-Steuereinrichtung 1250 und eine mobile Industrie-Verarbeitungsschnittstellen(MIPI)-Anzeigeschnittstelle 1255 gekoppelt ist. Der Speicher kann durch ein Flash-Speicher-Subsystem 1260 einschließlich eines Flash-Speichers und einer Flash-Speicher-Steuereinrichtung bereitgestellt sein. Die Speicherschnittstelle kann über eine Speichersteuereinrichtung 1265 für den Zugang zu SDRAM- oder SRAM-Speichervorrichtungen bereitgestellt sein. Manche integrierte Schaltungen umfassen zusätzlich dazu einen eingebetteten Sicherheitsengine 1270.
13A-13B sind Blockdiagramme, die beispielhafte Grafikprozessoren für die Verwendung innerhalb einer SoC bereitstellen, gemäß den hierin beschriebenen Ausführungsformen. 13A veranschaulicht einen beispielhaften Grafikprozessor 1310 eines Systems auf einer Chip-integrierten Schaltung, die unter Verwendung einer oder mehrerer IP-Cores gefertigt werden kann, gemäß einer Ausführungsform. 13B veranschaulicht einen zusätzlichen beispielhaften Grafikprozessor 1340 eines Systems auf einer Chip-integrierten Schaltung, die unter Verwendung einer oder mehrerer IP-Cores gefertigt werden kann, gemäß einer Ausführungsform. Grafikprozessor 1310 aus 13A ist ein Beispiel für einen Niedrigleistungs-Grafikprozessorkern. Der Grafikprozessor 1340 aus 13B ist ein Beispiel für einen Grafikprozessorkern mit höherer Leistung. Jeder der Grafikprozessoren 1310, 1340 kann eine Variante des Grafikprozessors 1210 aus 12 sein.
Wie in 13A gezeigt, umfasst der Grafikprozessor 1310 einen Vertex-Prozessor 1305 und einen oder mehrere Fragmentprozessoren 1315A-1315N (z. B. 1315A, 1315B, 1315C, 1315D, bis 1315N-1 und 1315N). Der Grafikprozessor 1310 kann unterschiedliche Shader-Programme über eine getrennte Logik ausführen, sodass der Vertex-Prozessor 1305 optimiert ist, Operationen für Vertex-Shader-Programme auszuführen, während der eine oder die mehreren Fragmentprozessoren 1315A-1315N Fragment- (z.B. Pixel)-Shading-Operationen für Fragment- oder Pixel-Shader-Programme durchführen. Der Vertex-Prozessor 1305 führt die Vertex-Verarbeitungsstufe der 3D-Grafik-Pipeline durch und erzeugt Grundkörper- und Vertex-Daten. Fragmentprozessor(en) 1315A-1315N verwenden die von dem Vertex-Prozessor 1305 erzeugte Grundkörper- und Vertex-Daten, um einen Framepuffer herzustellen, der auf einer Anzeigevorrichtung angezeigt wird. In einer Ausführungsform sind die Fragmentprozessoren 1315A-1315N optimiert, um Fragment-Shader-Programme auszuführen, wie sie in der OpenGL-API bereitgestellt sind, die verwendet werden kann, um ähnliche Operationen wie ein Pixel-Shader-Programm durchzuführen, wie es in der Direct-3D-API bereitgestellt ist.
Der Grafikprozessor 1310 umfasst zusätzlich eine oder mehrere Speicher-Verwaltungseinheiten (MMUs) 1320A-1320B, Cache 1325A-1325B und Schaltungsverbindungen 1330A-1330B. Die eine oder die mehreren MMUs 1320A-1320B stellen für eine Adressabbildung von virtuell zu physikalisch für den Grafikprozessor 1310 bereit, einschließlich des Vertex-Prozessors 1305 und/oder Fragmentprozessors/der Fragmentprozessoren 1315A-1315N, der in einem Speicher gespeicherte Vertex- oder Bild/Textur-Daten, zusätzlich zu in dem einen oder den mehreren Cache-Speichern 1325A-1325B gespeicherten Vertex- oder Bild/Texturdaten, referenzieren kann. In einer Ausführungsform können die eine oder die mehreren MMU(s) 1320A-1320B mit anderen MMUs innerhalb des Systems synchronisiert sein, einschließlich einer oder mehrerer MMUs, die dem einen oder mehreren Anwendungsprozessoren 1205, Bildprozessor 1215 und/oder Videoprozessor 1220 von 12 zugeordnet sind, sodass jeder Prozessor 1205-1220 an einem gemeinsam genutzten oder einheitlichen virtuellen Speichersystem teilnehmen kann. Der eine oder die mehreren Schaltungsverbindungen 1330A-1330B befähigen den Grafikprozessor 1310 dazu, mit anderen IP-Cores innerhalb der SoC, entweder über einen internen Bus der SoC oder über eine Direktverbindung in Übereinstimmung mit Ausführungsformen eine Schnittstelle zu bilden.
Wie in 13B gezeigt, umfasst der Grafikprozessor 1340 die eine oder die mehreren MMUs 1320A-1320B, Cache-Speichern 1325A-1325B und die Schaltungsverbindungen 1330A-1330B des Grafikprozessors 1310 von 13A. Der Grafikprozessor 1340 umfasst ein oder mehrere Shader-Cores 1355A-1355N (z. B. 1455A, 1355B, 1355C, 1355D, 1355E, 1355F bis 1355N-1 und 1355N), die eine einheitliche Shader-Core-Architektur bereitstellen, bei der ein einzelner Core oder Typ oder Core alle Arten von programmierbarem Shader-Code ausführen kann, einschließlich Shader-Programm-Code, um Vertex-Shader, Fragment-Shader und/oder Computer-Shader zu implementieren. Die exakte Anzahl an vorliegenden Shader-Cores kann nach den Ausführungsformen und Implementierungen variieren. Zusätzlich dazu umfasst der Grafikprozessor 1340 einen Inter-Core-Aufgabenmanager 1345, der als Thread-Dispatcher dient, um Ausführungs-Threads an einen oder mehrere Shader-Cores 1355A-1355N und eine Tiling-Einheit 1358 abzusenden, um Tiling-Operationen für Tile-basiertes Rendering zu beschleunigen, bei denen Operationen für eine Szene in einen Bildraum unterteilt werden, um beispielsweise lokale räumliche Kohärenz innerhalb einer Szene auszunutzen oder die Nutzung interner Cache-Speichern zu optimieren.
14A-14B veranschaulichen beispielhafte Grafikprozessorlogik gemäß hierin beschriebenen Ausführungsformen. 14A veranschaulicht einen Grafik-Core 1400, der in dem Grafikprozessor 1210 von 12 umfasst sein kann und der ein einheitlicher Shader-Core 1355A-1355N wie in 13B sein kann. 14B veranschaulicht eine hochparallele universelle Grafikverarbeitungseinheit 1430, die für den Einsatz auf einem Multi-Chip-Modul geeignet ist.
Wie in 14A gezeigt, umfasst der Grafik-Core 1400 einen gemeinsam genutzten Anweisungscache 1402, eine Textureinheit 1418 und einen Cache/gemeinsamen Speicher 1420, die den Ausführungsressourcen innerhalb des Grafik-Cores 1400 gemeinsam sind. Der Grafik-Core 1400 kann mehrere Prozessorelemente 1401A-1401N oder Partition für jeden Core umfassen und ein Grafikprozessor kann mehrere Varianten des Grafik-Cores 1400 umfassen. Die Prozessorelemente 1401A-1401N können Unterstützungslogik einschließlich eines lokalen Anweisungs-Cache-Speichers 1404A-1404N, eines Thread-Planers 1406A-1406N, eines Thread-Dispatchers 1408A-1408N und einen Satz von Registern 1410A umfassen. Um Logikoperationen durchzuführen, können die Prozessorelemente 1401A-1401N einen Satz von zusätzlichen Funktionseinheiten (AFUs 1412A-1412N), Gleitkommaeinheiten (FPU 1414A-1414N), ganzzahlige arithmetische Logikeinheiten (ALUs 1416-1416N), Adressberechnungseinheiten (ACU 1413A-1413N), doppelgenaue Gleitkommaeinheiten (DPFPU 1415A-1415N) und Matrixverarbeitungseinheiten (MPU 1417A-1417N) umfassen.
Manche der Berechnungseinheiten arbeiten mit einer spezifischen Genauigkeit. Beispielsweise können die FPUs 1414A-1414N Gleitkommaoperationen mit einfacher Genauigkeit (32-Bit) und halber Genauigkeit (16-Bit) durchführen, während die DPFPUs 1415A-1415N Gleitkommaoperationen mit doppelter Genauigkeit (64-bit) durchführen. Die ALUs 1416A-1416N Ganzzahlenoperationen mit variabler Genauigkeit mit 8-Bit, 16-Bit und 32-Bit durchführen und können für Operationen mit gemischter Genauigkeit konfiguriert sein. Die MPUs 1417A-1417N können auch für Matrixoperationen mit gemischter Genauigkeit konfiguriert sein, einschließlich Gleitkommaoperationen mit halber Genauigkeit und ganzzahliger Operationen mit 8 Bit. Die MPUs 1417-1417N können eine Vielzahl von Matrixoperationen durchführen, um die Frameworks für maschinelle Lernanwendungen zu beschleunigen, einschließlich der Unterstützung für die beschleunigte allgemeine Matrix-zu-Matrix-Multiplikation (GEMM). Die AFUs 1412A-1412N können zusätzliche Logikoperationen durchführen, die nicht von den Gleitkomma- oder ganzzahligen Einheiten unterstützt werden, einschließlich trigonometrischer Operationen (z. B. Sinus, Cosinus etc.).
Wie in 14B gezeigt, kann eine universelle Verarbeitungseinheit (GPGPU) 1430 konfiguriert sein, um hochparallele Rechenoperationen durch ein Array von Grafikverarbeitungseinheiten durchführen zu können. Zusätzlich dazu kann die GPGPU 1430 direkt mit anderen Varianten der GPGPU verbunden sein, um ein Multi-GPU-Cluster zu bilden, um die Trainingsgeschwindigkeit für bestimmte tiefe neuronale Netzwerke zu verbessern. Die GPGPU 1430 umfasst eine Host-Schnittstelle 1432, um eine Verbindung mit einem Host-Prozessor zu ermöglichen. In einer Ausführungsform ist die Host-Schnittstelle 1432 eine PCI-Express-Schnittstelle. Jedoch kann die Host-Schnittstelle auch eine herstellerspezifische Kommunikationsschnittstelle oder Kommunikationsstruktur sein. Die GPGPU 1430 erhält von dem Host-Prozessor Befehle und verwendet einen globalen Planer 1434, um Ausführungs-Threads, die mit diesen Befehlen in Verbindung stehen, an einen Satz von Berechnungsclustern 1436A-1436H zu verteilen. Die Berechnungscluster 1436A-1436H benutzen einen Cache-Speicher 1438 gemeinsam. Der Cache-Speicher 1438 kann als übergeordneter Cache für Cache-Speicher innerhalb der Rechencluster 1436A-1436H dienen.
Die GPGPU 1430 kann Speicher 1434A-1434B umfassen, der mit den Berechnungsclustern 1436A-1436H über einen Satz von Speichersteuereinrichtungen 1442A-1442B verbunden ist. In verschiedenen Ausführungsformen kann der Speicher 1434A-1434B unterschiedliche Arten von Speichervorrichtungen umfassen, einschließlich dynamischer Direktzugriffsspeicher (DRAM) oder Grafikdirektzugriffsspeicher, wie z. B synchroner grafischer Direktzugriffsspeicher (SGRAM), einschließlich eines Grafikspeichers mit doppelter Datenrate (GDDR).
In einer Ausführungsform umfassen die Berechnungscluster 1436A-1436H jeweils einen Satz von Grafik-Cores, wie z. B. den Grafik-Core 1400 von 14A, der mehrere Arten von ganzzahligen und Gleitkomma-Logikeinheiten umfassen kann, die Berechnungsoperationen mit einer Reihe von Genauigkeitsstufen durchführen kann, einschließlich solcher, die für Maschinenlernberechnungen geeignet sind. Beispielsweise und in einer Ausführungsform kann zumindest ein Subsatz der Gleitkommaeinheiten in jedem der Berechnungscluster 1436A-1436H konfiguriert sein, um 16-Bit oder 32-Bit-Gleitkommaoperationen durchzuführen, während ein unterschiedlicher Subsatz der Gleitkommaoperationen konfiguriert sein kann, um 64-Bit-Gleitkommaoperationen durchzuführen.
Mehrere Varianten der GPGPU 1430 können konfiguriert sein, um als ein Berechnungscluster zu arbeiten. Der von dem Berechnungscluster für die Synchronisation und den Datenaustausch verwendete Kommunikationsmechanismus variiert je nach Ausführungsform. In einer Ausführungsform kommunizieren die mehreren Varianten der GPGPU 1430 über die Host-Schnittstelle 1432. In einer Ausführungsform umfasst die GPGPU 1430 einen I/O-Hub 1439, der die GPGPU 1430 mit einer GPU-Verlinkung 1440 koppelt, der eine direkte Verbindung zu anderen Varianten der GPGPU ermöglicht. In einer Ausführungsform ist die GPU-Verlinkung 1440 an eine zugehörige GPU-zu-GPU-Brücke gekoppelt, die die Kommunikation und Synchronisation zwischen mehreren Varianten der GPGPU 1430 ermöglicht. In einer Ausführungsform koppelt die GPU-Verlinkung 1440 mit einer Hochgeschwindigkeitsverbindung, um Daten an andere GPGPUs oder parallele Prozessoren zu senden und zu empfangen. In einer Ausführungsform sind die mehreren Varianten der GPGPU 1430 in getrennten Datenverarbeitungssystemen angeordnet und kommunizieren über eine Netzwerkvorrichtung, die über die Host-Schnittstelle 1432 zugänglich ist. In einer Ausführungsform kann die GPU-Verlinkung 1440 konfiguriert sein, um eine Verbindung mit einem Host-Prozessor zu ermöglichen, zusätzlich zu oder als Alternative zu der Host-Schnittstelle 1432.
Während die veranschaulichte Konfiguration der GPGPU 1430 konfiguriert sein kann, um neuronale Netzwerke zu trainieren, stellt eine Ausführungsform eine alternative Konfiguration der GPGPU 1430 bereit, die für den Einsatz innerhalb einer Hochleistungs- oder Niedrigleistungs-Inferenzplattform konfiguriert sein kann. In einer Interferenzkonfigurierung umfasst die GPGPU 1430 weniger der Berechnungscluster 1436A-1436H in Bezug auf die Trainingskonfigurierung. Zusätzlich kann sich die Speichertechnologie, die dem Speicher 1434A-1434B zugeordnet ist, zwischen den Inferenz- und Trainingskonfigurierungen unterscheiden, mit Speichertechnologien mit höherer Bandbreite, die für Trainingskonfigurationen vorgesehen sind. In einer Ausführungsform kann die Inferenzkonfigurierung der GPGPU 1430 die Inferenzierung spezifischer Anweisungen unterstützen. Beispielsweise kann die Inferenzkonfigurierung Unterstützung für eine oder mehrere ganzzahlige 8-Bit-Ganzzahl-Skalarproduktanweisungen bereitstellen, die häufig bei Inferenzierungsoperationen für eingesetzte neuronale Netze verwendet werden.
GPGPU mit Matrix-Beschleunigungslogik
15 ist ein Blockdiagramm eines Datenverarbeitungssystems 1500 gemäß einer Ausführungsform. Das Datenverarbeitungssystem 1500 ist ein heterogenes Verarbeitungssystem mit einem Prozessor 1502, einem einheitlichen Speicher 1510 und einer GPGPU 1520, die eine Beschleunigungslogik für maschinelles Lernen umfasst. Der Prozessor 1502 und die GPGPU 1520 können ein beliebiger der hierin beschriebenen Prozessoren und GPGPU/parallelen Prozessoren sein. Der Prozessor 1502 kann Anweisungen für einen Compiler 1515, der in dem Systemspeicher 1512 gespeichert ist, ausführen. Der Compiler 1515 führt Anweisungen auf dem Prozessor 1502 aus, um Quellcode 1514A in den kompilierten Code 1514B zu kompilieren. Der kompilierte Code 1514B kann Anweisungen, die durch den Prozessor 1502 ausgeführt werden können und/oder Anweisungen umfassen, die von der GPGPU 1520 ausgeführt werden. Während der Kompilierung kann der Computer 1515 Operationen zum Einfügen von Metadaten durchführen, einschließlich Hinweisen auf die Ebene der Datenparallelität im kompilierten Code 1514B und/oder Hinweisen auf den Datenstandort, der dem zu versendenden Threads basierend auf dem kompilierten Code 1514B zugeordnet ist. Der Compiler 1515 kann die Informationen umfassen, die notwendig sind, um solche Operationen durchzuführen, oder die Operationen können unter der Mithilfe einer Laufzeitbibliothek 1516 durchgeführt werden. Die Laufzeitbibliothek 1516 kann auch dem Compiler 1515 bei der Kompilierung des Quellendes 1514A assistieren und kann auch Anweisungen umfassen, die bei der Laufzeit mit dem kompilierten Code 1514B verbunden sind, um die Ausführung der kompilierten Anweisungen auf der GPGPU 1520 zu erleichtern.
Der einheitliche Speicher 1510 stellt einen einheitlichen Adressraum dar, auf den von dem Prozessor 1502 und der GPGPU 1520 zugegriffen werden kann. Der einheitliche Speicher kann den Systemspeicher 1512 sowie den GPGPU-Speicher 1518 umfassen. Der GPGPU-Speicher 1518 ist ein Speicher innerhalb einer Adressgeschwindigkeit der GPGPU 1520 und kann manche oder alle Systemspeicher 1512 umfassen. In einer Ausführungsform kann der GPGPU-Speicher 1518 auch zumindest einen Abschnitt eines beliebigen Speichers umfassen, der der ausschließlichen Verwendung durch die GPGPU 1520 gewidmet ist. In einer Ausführungsform kann der kompilierte Code 1514B, der in dem Systemspeicher 1512 gespeichert ist, für den Zugriff durch die GPGPU 1520 in den GPGPU-Speicher 1518 abgebildet werden.
Die GPGPU 1520 umfasst mehrere Berechnungsblöcke 1524A-1524N, die eine oder mehrere einer Vielzahl von hierin beschriebenen Berechnungseinheiten oder Ausführungselementen umfassen können. In einer Ausführungseinheit umfasst die GPGPU 1520 zusätzlich einen Matrixbeschleuniger 1523, der eine oder mehrere Berechnungseinheiten mit speziellen Funktionen umfassen kann, die konzipiert sind, um einen Subsatz von Matrixoperationen (z. B. Skalarprodukt etc.) zu beschleunigen. Die GPGPU 1520 kann auch einen Satz von Ressourcen umfassen, die von den Berechnungsblöcken 1524A-1524N und dem Matrixbeschleuniger 1523 geteilt werden können, einschließlich, aber ohne darauf eingeschränkt zu sein, eines Satzes von Registern 1525, eines Energie- und Leistungsmoduls 1526 und eines Cache-Speichern 1527. In einer Ausführungsform umfassen die Register 1525 direkt oder indirekt zugängliche Register, wobei die indirekt zugänglichen Register für die Verwendung durch den Matrixbeschleuniger 1523 optimiert sind. Das Energie- und Leistungsmodul 1526 kann konfiguriert sein, um die Leistungsabgabe und die Taktfrequenzen für die Berechnungsblöcke 1524A-1524N anzupassen, um Leerlaufkomponenten des Gates innerhalb der Berechnungsblöcke 1524A-1524N zu versorgen. In verschiedenen Ausführungsformen kann der Cache 1527 einen Anweisungs-Cache und/oder einen Daten-Cache auf unterer Ebene umfassen.
Die GPGPU 1520 kann zusätzlich einen L3-Daten-Cache 1530 umfassen, der verwendet werden kann, um Daten, auf die von dem einheitlichen Speicher 1510 über den Matrixbeschleuniger 1523 und/oder die Berechnungselemente innerhalb der Berechnungsblöcke 1524A-1524N zugegriffen wurde, zwischenzuspeichern. In einer Ausführungsform umfasst der L3-Daten-Cache 1530 den gemeinsam genutzten lokalen Speicher 1532, der von den Berechnungselementen innerhalb der Berechnungsblöcke 1524A-1524N und dem Matrixbeschleuniger 1523 gemeinsam genutzt sein kann.
In einer Ausführungsform umfasst die GPGPU 1520 Anweisungsverarbeitungslogik, wie z. B. eine Abruf- und Entschlüsselungseinheit 1521 und eine Planer-Steuerungsvorrichtung 1522. Die Abruf- und Entschlüsselungseinheit 1521 umfasst eine Abruf- und Entschlüsselungseinheit, um Anweisungen zur Durchführung durch einen oder mehrere der Berechnungsblöcke 1524A-1524N oder den Matrixbeschleuniger 1523 abzurufen und zu entschlüsseln. Die Anweisungen können für die entsprechende Funktionseinheit innerhalb des Berechnungsblocks 1524A-1524N oder den Matrixbeschleuniger über die Planer-Steuerungsvorrichtung 1522 geplant werden. In einer Ausführungsform ist die Planer-Steuerungsvorrichtung 1522 eine ASIC, die konfigurierbar ist, um fortgeschrittene Planungsoperationen durchzuführen. In einer Ausführungsform ist die Planer-Steuerungsvorrichtung 1522 eine Mikro-Steuerungsvorrichtung oder ein Core mit niedriger Energie pro Anweisung, der in der Lage ist, Planer-Befehle auszuführen, die von einem Firmware-Modul geladen werden.
In einer Ausführungsform können manche von den Berechnungsblöcken 1524A-1524N auszuführende Funktionen direkt geplant oder an den Matrixbeschleuniger 1523 abgeladen werden. In verschiedenen Ausführungsformen umfasst der Matrixbeschleuniger 1523 eine Verarbeitungselementlogik die konfiguriert ist, um effizient Matrixberechnungsoperationen durchzuführen, wie z. B. das Multiplizieren und Addieren von Operationen und Skalarproduktoperationen, die von 3D-Grafiken oder Berechnungs-Shader-Programmen verwendet werden. In einer Ausführungsform kann der Matrixbeschleuniger 1523 konfiguriert sein, um Operationen zu beschleunigen, die von Maschinenlern-Frameworks verwendet werden. In einer Ausführungsform ist der Matrixbeschleuniger 1523 eine anwendungsspezifische integrierte Schaltung, die explizit konfiguriert ist, um einen spezifischen Satz von parallelen Matrixmultiplikation- und/oder Additionsoperationen durchzuführen. In einer Ausführungsform ist der Matrixbeschleuniger 1523 eine im Feld programmierbare Gatter-Anordnung (FPGA), die eine fixierte Funktionslogik bereitstellet, die zwischen den Arbeitslasten aktualisiert werden kann. Der Satz von Matrix-Operationen, der von dem Matrixbeschleuniger 1523 durchgeführt werden kann, kann in Bezug auf die Operationen, die von den Berechnungsblöcken 1524A-1524N durchgeführt werden können, eingeschränkt sein. Jedoch kann der Matrixbeschleuniger 1523 diese Operationen mit einem signifikant höheren Datendurchlauf in Bezug auf die Berechnungsblöcke 1524A-1524N durchgeführt werden.
16 veranschaulicht eine Matrixoperation 1605 gemäß einer Ausführungsform, die von einer Anweisungs-Pipeline 1600 durchgeführt wird. Die Anweisungs-Pipeline 1600 kann konfiguriert sein, um eine Matrixoperation 1605 durchzuführen, wie z. B., ohne jedoch darauf eingeschränkt zu sein, eine Skalarproduktoperation. Das Skalarprodukt zweier Vektoren ist ein Skalarwert, der der Summe von Produkten von entsprechenden Komponenten der Vektoren entspricht. Das Skalarprodukt kann wie in der nachstehenden Gleichung (1) gezeigt berechnet werden. $\vec{a} \cdot \vec{b} = \sum_{i = 1}^{n} a_{i} b_{i} = a_{1} b_{1} + \dots + a_{n} b_{n}$
Das Skalarprodukt kann in einer Faltungsoperation für ein konvolutionelles neuronales Netzwerk (CNN) verwendet werden. 16 veranschaulicht eine zweidimensionale (2D)-Faltung unter Verwendung einer Matrixoperation 1605, einschließlich einer Skalarproduktoperation. Während die 2D-Faltung veranschaulicht ist, kann eine N-dimensionale Faltung auf einem N-dimensionalen Volumen unter Verwendung von N-dimensionalen Filtern durchgeführt werden. Ein Rezeptionsfeld-Tile 1602 markiert einen Abschnitt eines Eingangsvolumens in einem Eingangsvolumenpuffer 1604. Der Eingangsvolumenpuffer kann in Speicher 1630 gespeichert sein. Eine Punktmatrixoperation 1605 kann zwischen den Daten innerhalb des Rezeptionsfeld-Tiles 1602 und einem Faltungsfilter durchgeführt werden, um einen Datenpunkt innerhalb des Ausgangspuffers 1606 zu erzeugen, der auch in Speicher 1630 gespeichert sein kann. Der Speicher 1630 kann ein beliebiger der hierin beschriebenen Speicher sein, einschließlich Systemspeicher 1512, GPGPU-Speicher 1518 oder ein oder mehrere Cache-Speicher 1527, 1530 wie in 15.
Die Kombination der Datenpunkte innerhalb des Ausgangspuffers 1606 stellt eine Aktivierungsabbildung dar, die von der Faltungsoperation erzeugt wird. Jeder Punkt innerhalb der Aktivierungsabbildung wird erzeugt, indem das Rezeptionsfeld-Tile über den Eingangsvolumenpuffer 1604 gezogen wird. Die Aktivierungsabbildungsdaten können in eine Aktivierungsfunktion eingegeben werden, um einen Ausgabeaktivierungswert zu bestimmen. In einer Ausführungsform kann die Faltung des Eingangsvolumenpuffers 1604 innerhalb eines Frameworks als High-Level-Matrixoperation 1705 definiert sein. Die High-Level-Matrixoperationen können über Grundkörperoperationen durchgeführt werden, wie z. B. eine Basic-Linear-Algebra-Subprogram(BLAS)-Operation. Die Grundkörperoperationen können über Hardwareanweisungen beschleunigt werden, die durch die Anweisungs-Pipeline 1600 ausgeführt werden.
Die Anweisungs-Pipeline 1600, die verwendet wird, um Hardware-Anweisungen zu beschleunigen, können die Anweisungsabruf- und -Entschlüsselungseinheit 1521 umfassen, die Hardwareanweisungen abrufen und entschlüsseln kann, und die Planer-Steuerungsvorrichtung 1522, die entschlüsselte Anweisungen für eine oder mehrere Ausführungseinheiten innerhalb der Berechnungsblöcke 1524A-1524N und/oder dem Matrixbeschleuniger 1523 zu planen. In einer Ausführungsform kann eine Hardwareanweisung für die Berechnungsblöcke 1524A-1524N geplant werden und kann an den Matrixbeschleuniger 1523 abgeladen werden. Die eine oder die mehreren Hardwareanweisungen und verbundenen Daten, um die Matrixoperation 1605 durchzuführen, kann in dem Speicher 1630 gespeichert werden. Die Ausgabe der Hardwareanweisung kann auch in dem Speicher 1630 gespeichert werden.
In einer Ausführungsform kann der Matrixbeschleuniger 1523 eine oder mehrere Hardwareanweisungen ausführen, um die Matrixoperation 1605 unter Verwendung von integrierter Skalarproduktlogik 1608 (DP-Logik) durchzuführen. Die Skalarproduktlogik 1608 kann eine Kombination von programmierbarer Hardware und Hardware mit fixer Funktion, die konfigurierbar ist, um Skalarproduktoperation durchzuführen, umfassen. Während Funktionseinheiten innerhalb der Berechnungsblöcke 1524A-1524N auch konfiguriert sein können, um Skalarproduktoperationen durchzuführen, kann die Skalarproduktlogik 1608 konfiguriert sein, um einen eingeschränkten Subsatz von Skalarproduktoperationen bei einem signifikant höheren Datendurchlauf relativ zu dem Berechnungsblock 1524A-1524N durchzuführen.
17A-17B veranschaulichen Details von Hardware-basierter Skalarproduktlogik 1608 gemäß manchen Ausführungsformen. 17A umfasst ein Raster von mehreren Funktionseinheiten, die konfigurierbar sind, um mehrere Skalarproduktoperationen innerhalb eines einzigen Taktzyklus. 17B veranschaulicht eine einzelne beispielhafte Funktionseinheit.
Wie in 17A gezeigt ist die Skalarproduktlogik 1608 in einer Ausführungsform konfigurierbar, um einen Satz von parallelen Skalarproduktoperationen unter Verwendung von Funktionseinheiten durchzuführen. Das Skalarprodukt kann auf eine „systolische“ Weise durchgeführt werden, bei der SIMD-Daten über mehrere Schichten von Funktionseinheiten gepumpt werden. In einer Ausführungsform kann die Skalarproduktlogik 1608 eine konfigurierbare Anzahl von SIMD-Kanälen von Daten unter Verwendung einer konfigurierbaren systolischen Tiefe verarbeiten. Für eine gegebene Anweisung, kann eine SIMD-Breite und eine systolische Tiefe ausgewählt werden, um einen Satz von Quellendaten zu verarbeiten. Die systolische Tiefe definiert die Anzahl von systolischen Schichten von Hardwarelogik, die verwendet wird, um eine Anweisung zu verarbeiten. Eine systolische Schicht ist eine Gruppe von Multiplizier- und Additionslogikeinheiten mit einer variablen SIMD-Breite, wobei die systolische Schicht einen anfänglichen Akkumulatorwert als Eingabe empfangen kann und einen Skalarproduktwert für eine Ausgabe an eine nachfolgende systolische Schicht oder an ein Ausgaberegister generiert.
In manchen Ausführungsformen können drei Quellen verarbeitet werden, wobei jede Quelle ein Vektorregister oder ein Sofortregister sein kann. In einer Ausführungsform kann eine Quelle 1700 (SRC0) ein oder mehrere anfängliche Akkumulatorwerte sein, die ein Einzelwert oder ein Vektor von Akkumulatorwerten sein können. Der anfängliche Akkumulatorwert wird zu dem ersten Satz von Skalarprodukten, die von jeder Funktionseinheit berechnet werden, innerhalb der ersten systolischen Schicht addiert. Das Skalarprodukt, das von einer Funktionseinheit berechnet wird, kann der nächsten systolischen Schicht für den gegebenen SIMD-Kanal bereitgestellt werden. Die Skalarprodukte können basierend auf Quelle 1701 (SRC1) und Quelle 1702 (SRC2) berechnet werden, die Vektorregister sind, die einen oder mehr Kanäle von paketierten Daten enthalten können, wobei jeder Kanal einen Vektor mit vier Elementen enthält. In einer Ausführungsform ist jeder Kanal 32 Bits breit und stellt vier 8-Bit-Vektorelemente bereit. Manche Ausführungsformen sind konfigurierbar, um Skalarprodukte von Eingabevektoren mit 8-Bit-Elementen, 4-Bit-Elementen und/oder 2-Bit-Elementen zu berechnen. In einer Ausführungsform können Operationen mit gemischter Genauigkeit unter Verwendung einer beliebigen Kombination von unterstützten Elementgrößen durchgeführt werden (z. B. 8-Bit x 2-Bit, 8-Bit x 4-Bit, 4-Bit x 4-Bit, etc.). In einer Ausführungsform ist die Skalarproduktlogik 1608 für die ganzzahlige Berechnung konfiguriert, obwohl in einigen Ausführungsformen der automatische Festkomma-Betrieb konfigurierbar ist. Obwohl die hierin beschriebene Anweisung ein Skalarprodukt mit vier Elementen ist, kann die Skalarproduktlogik 1608 in manchen Ausführungsformen auch konfiguriert sein, um Gleitkomma-Skalarproduktberechnungen auf einer unterschiedlichen Anzahl von Elementen pro Vektor zu konfigurieren.
In einer Ausführungsform können mehrere Kanäle von Vektoren mit vier Elementen in ein einzelnes Vektorregister mit unterschiedlichen Breiten paketiert werden (z. B. 64-Bit, 128-Bit, 256-Bit, 512-Bit, etc.). Simultane Skalarprodukte können über die Skalarproduktlogik 1608 für mehrere Kanäle von Vektorelementen, die über Quelle 1701 und Quelle 1702 bereitgestellt sind, berechnet werden. Die Anzahl von Kanälen von zu verarbeitenden Vektorelementen kann basierend auf einer ausgewählten Ausführungsgröße und systolischen Tiefe für die Skalarproduktberechnung konfiguriert sein. In einer Ausführungsform können Quellenvektoren, die breiter als die spezifizierte Ausführungsgröße und/oder systolische Tiefe sind, unter Verwendung von mehreren Zyklen der Skalarproduktlogik 1608 berechnet werden.
Die Anzahl an Berechnungen, die mit einem gegeben Taktzyklus durchgeführt werden kann, kann basierend auf der Anzahl von SIMD-Spuren und systolischen Schichten durchgeführt werden. Die Skalarproduktlogik 1608 kann wie veranschaulicht sechzehn Skalarprodukte pro SIMD-Datendurchlaufspur unter Verwendung einer systolischen Tiefe von vier durchführen. Ist sie für acht SIMD-Spuren konfiguriert, kann die Logik 128 ganzzahlige acht-Bit (INT8) -Skalarprodukte innerhalb eines gegebenen Zyklus durchgeführt werden. Ist sie für acht SIMD-Spuren und eine systolische Tiefe von acht konfiguriert, kann jede Spur 32 ganzzahlige acht-Bit (INT8)-Skalarprodukte und 256 Skalarprodukte insgesamt durchführen. Diese spezifische Anzahl an Operationen ist beispielhaft für eine Ausführungsform und andere Ausführungsformen variieren in ihrem Datendurchlauf. Darüber hinaus wird die Anzahl an Operationen basierend auf den unterschiedlichen Datentypen skaliert, wenn die Datentypen unterschiedlich sind.
Bei jeder Funktionseinheit wird ein Skalarprodukt mittels Multiplizierer- und Addiererlogik berechnet, und das Skalarprodukt wird zu einem Akkumulatorwert addiert. Die resultierenden Daten können eine Ausgabe an ein Zielregister sein oder an den Akkumulator der nächsten systolischen Schicht bereitstellen. Details einer Funktionseinheit 1712 werden in 17B gezeigt.
Wie in 17B gezeigt, kann eine Funktionseinheit 1712 einen Satz von Eingabedatenpuffern 1704, 1706 und einen Akkumulator 1722 umfassen, die alle Eingabedaten aufnehmen können. In einer Ausführungsform kann der Datenpuffer 1706 die Quelle 1702 (SRC2) aufnehmen, die ein gepackter Vektor von Eingabedaten sein kann. Eingabedatenpuffer 1704 kann eine Quelle 1701 (SRC1) aufnehmen, die auch ein gepackter Vektor von Eingabedaten sein kann. Der Akkumulator 1722 kann Quelle 1700 (SRC0) aufnehmen, die einen anfänglichen Akkumulatorwert für die Funktionseinheit 1712 bereitstellt. Der anfängliche Akkumulatorwert wird zu dem Skalarprodukt, das von den Elementen von Quelle 1701 und Quelle 1702 berechnet wird, addiert. Das Skalarprodukt wird über eine elementweise Multiplikation der Quellvektoren unter Verwendung eines Satzes von Multiplikatoren 1723A-1723D und einen Addierer 1724 berechnet. Die Multiplizierer 1723A-1723D werden verwendet, um einen Produktsatz zu berechnen. Eine Summe des Produktsatzes wird von dem Addierer 1724 berechnet. Die Summe kann mit einem beliebigen anfänglichen Wert, der von Quelle 1700 bereitgestellt wird, akkumuliert werden (z. B. dazu addiert werden). In einer Ausführungsform kann dieser akkumulierte Wert als Eingabewert 1726 an den nächsten Akkumulator bereitgestellt werden, der sich in einer nachfolgenden systolischen Schicht befindet. In einer Ausführungsform kann die Quelle 1701 mehrere Kanäle von Eingabedaten umfassen. Zusätzliche Kanäle von Quelle 1701 können als SRC1-Eingabe an zusätzliche SIMD-Spuren 1728 weitergeleitet werden. In einer Ausführungsform kann die Quelle 1702 mehrere Kanäle von Eingabedaten umfassen. Zusätzliche Kanäle von Quelle 1702 können als SRC2- Eingabedaten an Logikeinheiten mit zusätzlichen systolischen Tiefen verwendet werden. In einer Ausführungsform kann Quelle 1700 gegebenenfalls mehrere Kanäle umfassen, wobei zusätzliche Kanäle als Eingabe an den Akkumulator mit zusätzlichen Funktionseinheiten bereitgestellt sind. In einer Ausführungsform kann Quelle 1700 ein Einzelwert sein, der zu jedem Akkumulator in jeder Funktionseinheit der anfänglichen systolischen Schicht hinzugefügt wird.
18A-18B veranschaulichen eine Anweisung 1800, die durch die Skalarproduktlogik ausführbar ist, gemäß hierin beschriebenen Ausführungsformen. 18A veranschaulicht Felder eines Skalarprodukts mit vier Elementen mit einer Akkumulationsanweisung, die durch eine systolische Matrixlogik ausführbar ist, die von einer Ausführungsform bereitgestellt wird. 18B veranschaulicht elementweise Berechnungen, die durchgeführt werden, während das Skalarprodukt mit vier Elementen mit einer Akkumulation unter Verwendung der systolischen Matrixlogik berechnet wird.
18A veranschaulicht Felder eines Skalarprodukts mit vier Feldern mit einer Akkumulationsanweisung 1800, die, wenn sie ausgeführt wird, bewirkt, dass ein systolischer Matrixbeschleuniger ein Skalarprodukt mit vier Elementen mit Akkumulation durchführt. In einer Ausführungsform umfasst die Anweisung 1800 ein Prädikatsfeld 1802, ein Opcodefeld 1804, ein bedingtes Modifikatorfeld 1806, ein Ausführungsgrößenfeld 1808 und Operandenfelder zur Angabe eines Ziels 1810, eine nullte Quelle 1812 (src0), eine erste Quelle 1814 (src1), eine zweite Quelle 1816 (src2) und eine systolische Tiefe 1818 (sdepth).
Das Prädikatsfeld 1802 kann eine Prädikatsmaske spezifizieren. Die Prädikatsmaske kann verwendet werden, um einen SIMD-Ausführungskanal der Anweisung zu aktivieren oder zu deaktivieren. In verschiedenen Ausführungsformen kann ein deaktivierter Kanal eine Ausführung umgehen oder kann sie ausführen, während die Ausführungslogik davon abgehalten wird, den Architekturstatus, der mit dem deaktivierten Kanal verbunden ist, zu modifizieren. In einer Ausführungsform kann die Ausgabe der Ausführung kann die Ausgabe der Ausführung verworfen werden, ohne eingeben zu werden.
Das Opcodefeld 1804 kann einen Opcode spezifizieren, der die Anweisung 1800 zur Ausführungslogik identifiziert. In einer Ausführungsform umfasst das Opcode-Feld 1804 ein oder mehrere Bits, die, wenn sie aktiviert sind, angeben, dass die Anweisung von einem Matrixbeschleuniger (z. B. Matrixbeschleuniger 1523) durchzuführen ist. In einer Ausführungsform kann das Opcode-Feld 1804 auch ein oder mehrere Bits umfassen, die spezifizieren, dass die Anweisung 1800 von einer speziellen Skalarproduktlogik, wie z. B. der Skalarproduktlogik (z. B. Skalarproduktlogik 1608) innerhalb eines Matrixbeschleunigers durchzuführen ist.
Das bedingte Modifikatorfeld 1806 kann verwendet werden, um ein Kennzeichenregister basierend auf den internen bedingten Signalen, die von der Ausführungsleitung ausgegeben werden, wie Vorzeichen, Null, Überlauf, Nicht-Nummer (NaN), etc. einzustellen. Wenn dieses Feld auf 0000 eingestellt wird, werden keine Kennzeichenregister aktualisiert. In einer Ausführungsform umfassen unterstützte Bedingungen, ohne jedoch darauf eingeschränkt zu sein, Null oder gleich, nicht Null oder nicht gleich, größer als, größer als, größer als oder gleich, kleiner als, kleiner als oder gleich, Überlauf und ungeordnet mit berechnetem NaN. Darüber hinaus kann in manchen Konfigurationen ein Quellenmodifikatorfeld aktiviert sein.
Die Ausführungsgröße 1808 (exec_size) spezifiziert die Anzahl von Ausführungskanälen für die Anweisung 1800. In dem Fall einer Skalarproduktanweisung mit vier Elementen, kann in einer Ausführungsform die Anzahl von Ausführungskanälen verwendet werden, um eine Anzahl von Paaren von Vektoren mit vier Elementen zu spezifizieren, über die die Berechnung durchgeführt wird.
Das Ziel 1810, die nullte Quelle 1812 (src0), erste Quelle 1814 (src1), zweite Quelle 1816 (src2) kann verwendet werden, um ein Ziel zu spezifizieren, zu dem eine Berechnung geschrieben wird und ein Ort, von dem Quellendaten erhalten werden können. In einer Ausführungsform kann das Ziel 1810 ein Register spezifizieren, zu dem die Daten geschrieben werden sollen. In einer Ausführungsform kann das Ziel 1810 ein Skalarregister sein, obwohl in manchen Ausführungsformen das Ziel auch ein Vektorregister sein, das eine Ausgabe von mehreren Kanälen speichert. Wo beispielsweise ein einzelner Kanal mit vier Elementen spezifiziert wird, kann ein einzelnes Skalarprodukt zu einem einzelnen Ausgabekanal an dem Ziel geschrieben werden. Wo mehrere Kanäle mit vier Elementen spezifiziert werden, können mehrere Skalarprodukte zu einem Vektorzielregister geschrieben werden. Die nullte Quelle 1812, erste Quelle 1814 und die zweite Quelle 1816 können Register- oder Sofortwerte sein, die einen oder mehrere Kanäle von Quelldatei umfassen, wobei jeder Kanal vier Elemente aufweist, die von der Skalarproduktlogik zu verarbeiten sind, wie bei Quelle 1700, Quelle 1701 und Quelle 1702 wie in 17A-17B. Die systolische Tiefe 1818 (sdepth) kann verwendet werden, um die Anzahl systolischen Schichten zu spezifizieren, die zu verwenden sind, um die Eingabedaten zu verarbeiten. In einer Ausführungsform kann die systolische Tiefe 1818 als ein Sofortwert bereitgestellt sein.
In manchen Ausführungsformen können zusätzliche Felder abgesehen von den veranschaulichten vorliegen. Beispielsweise ist in einer Ausführungsform ein Quellenmodifikatorfeld vorhanden, das die numerische Modifikation eines Quellenoperanden spezifiziert. Der Wert jedes Datenelements eines Quelloperanden kann gegebenenfalls vor der Übergabe an die Ausführungs-Pipeline mit seinem Absolutwert und/oder seinem Vorzeichen invertiert werden. Der Absolutwertmodifikator kann vor dem Negativmodifikator angewendet werden, so dass ein garantierter negativer Wert erzeugt werden kann. In einer Ausführungsform ist ein Sättigungsfeld vorhanden, mit dem die Zielsättigung gesteuert werden kann. Wenn die Sättigung aktiviert ist, sind die Ausgabedaten im Zielregister gesättigt. Die spezifische Sättigungsoperation hängt vom Zieldatentyp ab. Die Sättigung ist eine Operation, die alle Daten, die außerhalb des Sättigungszielbereichs für den Datentyp liegen, in den nächstgelegenen darstellbaren Wert mit dem Zielbereich umwandelt.
Elementweise Operationen der Anweisung 1800 sind in 18B gezeigt. In einer Ausführungsform können ein Hardwarepuffer, ein temporäres Register oder ein internes Register einer Funktionseinheit innerhalb von Skalarproduktlogik eines systolischen Matrixbeschleunigers Elemente A3-A0 von einem Kanal 1824 der ersten Quelle 1814 speichern. Ein zusätzlicher Hardwarepuffer oder ein temporäres Register kann Elemente B3-B0 eines Kanals 1826 der zweiten Quelle 1816 speichern. Die Elemente können in eine Funktionseinheit (z. B. Funktionseinheit 1712 von 17A) der Skalarproduktlogik (z. B. Skalarproduktlogik 1608 von 16 und 17A) geladen werden. Ein Satz von Multiplizierern (z. B. Multiplizierer 1723A-1723D von 17B) kann einen Satz von Produkten 1834 erzeugen. Der Satz von Produkten kann in einen Addierer (z. B. Addierer 1724 von 17B) geladen werden.
Der Addierer kann eine Summe des Satzes von Produkten 1835 erzeugen, der mit einem existierenden Akkumulatorwert 1822 (z. B. C0) akkumuliert werden kann. Der existierende Akkumulatorwert 1822 kann ein anfänglicher Akkumulatorwert sein, der über die Anweisung 1800 bereitgestellt wird oder er kann ein Akkumulatorwert sein, der von einer früheren systolischen Schicht bereitgestellt ist. Die akkumulierte Summe dieses Satzes von Produkten 1835 kann dann eine Ausgabe an ein Ziel 1838 sein, das das Ziel 1810 sein kann, das von der Anweisung 1800 spezifiziert wird oder sie kann als der anfängliche Akkumulatorwert 1836 der nächsten systolischen Schicht geladen werden.
19 veranschaulicht einen Programmcode-Kompilierungsvorgang 1900 gemäß einer Ausführungsform. In einer Ausführungsform wird eine Quellcode-Ebenenbeschreibung 1901 eines Softwareprogramms bei einem Compiler 1902 kompiliert, der mehrere Kompilierungsebenen einschließen kann, bis zu einer Ebene mit einer Operation 1903, die ein von Verarbeitungslogik durchzuführendes Skalarprodukt spezifiziert. Die Operation 1903 kann eine Operation sein, die in einer Zwischensprache spezifiziert ist, oder sie kann Programmcode sein, der einen Grundkörper eines Berechnungsframeworks referenziert, wie z. B. einen Grundkörper, der von einem Maschinenlernframework bereitgestellt wird. Die Operation 1903, die ein Skalarprodukt umfasst oder spezifiziert, kann dann ferner durch einen zusätzlichen Compiler 1904, der ein Shader-Compiler sein kann, in Maschinenebenen-Objektcode 1905 kompiliert werden, der eine Skalarproduktangabe enthält, die von einem Beschleuniger für Matrixoperationen durchzuführen ist, wie hierin beschrieben.
20 veranschaulicht einen Vorgang 2000, um eine Skalarproduktanweisung innerhalb einer Anweisungsausführungs-Pipeline durchzuführen, gemäß einer hierin beschriebenen Ausführungsform. Der Vorgang 2000 kann unter Verwendung von Berechnungslogik eines hierin beschriebenen Datenverarbeitungssystems durchgeführt werden, ist jedoch nicht auf das Datenverarbeitungssystem 1500 aus 15 eingeschränkt. In einer Ausführungsform kann die Abruf- und Entschlüsselungslogik (z. B. Abruf- und Entschlüsselungslogik 1521) eine einzelne, innerhalb der GPGPU auszuführende Anweisung abrufen und entschlüsseln, wobei die einzelne Anweisung in eine entschlüsselte Matrixanweisung entschlüsselt wird, wie in Block 2002 gezeigt. Die entschlüsselte Anweisung kann bewirken, dass die GPGPU eine parallele Skalarproduktoperation, wie hierin beschrieben, durchführt. Wie in Block 2004 gezeigt, kann der Vorgang 2000 bewirken, dass die Ausführungs-Pipeline einen Satz von aufzuführenden Pipeline-Befehlen bestimmt, um die entschlüsselte Matrixanweisung auf einem Matrixbeschleuniger durchzuführen, wie z. B. dem Matrixbeschleuniger 1523, der in 15 und 16 gezeigt wird. Wie bei Block 2006 gezeigt, umfasst der Vorgang 2000 das Planen des Satzes von Pipeline-Befehlen für eine systolische Skalarprodukt-Pipeline, wie z. B. die hierin beschriebene Skalarproduktlogik 1608, um die entschlüsselte Matrixanweisung aufzuführen. Wie bei Block 2008 gezeigt, umfasst der Vorgang 2000 zusätzlich das Zurückziehen der Matrixanweisung als Reaktion auf die Fertigstellung des Satzes von Pipeline-Befehlen.
21 veranschaulicht ein Verfahren 2100, durch das die Hardwarelogik bei einer Funktionseinheit eine Anweisung ausführen kann, um ein systolisches Skalarprodukt mit Akkumulation gemäß einer Ausführungsform durchzuführen. Das Verfahren 2100 kann, wie hierin beschrieben, über eine Hardware-basierte systolische Skalarproduktberechnungslogik durchgeführt werden (z. B. Skalarproduktlogik 1608).
In einer Ausführungsform umfasst das Verfahren 2100 in Bezug auf die Hardware-basierte systolische Skalarproduktberechnungslogik das Abrufen von Quellenwerten und einer Berechnungstiefe für eine durch einen Matrixbeschleuniger einer GPGPU durchzuführende Anweisung, wie z. B. bei Block 2102 gezeigt. Die Berechnungstiefe kann eine Anzahl von systolischen Schichten spezifizieren, die zur Berechnung des Skalarprodukts verwendet werden sollen. Die Skalarproduktlogik kann gegebenenfalls einen anfänglichen Akkumulatorwert abrufen und den anfänglichen Wert an einen Akkumulator speichern, wie in Block 2104 gezeigt. Jedoch kann der anfängliche Wert ein Nullwert sein, in Abhängigkeit von den an die Anweisung gelieferten Operanden. In einer Ausführungsform ist der anfängliche Wert eine Wertausgabe aus einer Funktionseinheit einer anderen systolischen Schicht.
Wie in Block 2106 gezeigt, umfasst das Verfahren 2100 für jede spezifizierte Berechnungsschicht in Bezug auf die Salarproduktlogik das Evaluieren einer Schreibfreigabemaske, um einen Satz von aktivierten Parallelverarbeitungskanälen zu bestimmen. Die Schreibfreigabemaske kann verwendet werden, um die Berechnung von spezifischen SIMD-Kanälen zu deaktivieren. In einer Ausführungsform ist die Schreibfreigabemaske zumindest teilweise basierend auf einer Prädikatsmaske konfiguriert, die mit den auszuführenden Anweisungen versorgt ist.
Wie in Block 2108 gezeigt, umfasst das Verfahren 2100 zusätzlich in Bezug auf die Skalarproduktlogik das Erzeugen eines Satzes von Produkten für jeden aktivierten parallelen Verarbeitungskanal in der systolischen Schicht, basierend auf einer elementweisen Multiplikation von Quelleneingabeelementen. Für das Skalarprodukt mit vier Elementen von manchen hierin beschriebenen Ausführungsformen sind vier Elemente von zwei Quellen multipliziert, um den Satz von Produkten zu erzeugen. Bei Block 2110 umfasst das Verfahren 2100 in Bezug auf die Skalarproduktlogik, eine Summe des Satzes von Produkten zu berechnen und die Summe zu einem Wert in dem Akkumulator zu addieren. Der Wert in dem Akkumulator kann ein anfänglicher Wert sein, der bei Block 2104 abgerufen wird, oder er kann ein Wert sein, der von einer Funktionseinheit von einer unterschiedlichen systolischen Schicht bereitgestellt ist.
In einer Ausführungsform, wo das Verfahren 2100 an einer Funktionseinheit durchgeführt wird, die in der letzten Berechnungsschicht ist, wie in Block 2111 gezeigt, kann die Funktionseinheit das berechnete Skalarprodukt an ein spezifiziertes Zielregister ausgeben. Wenn das Verfahren 2100 nicht an einer Funktionseinheit in der letzten Berechnungsschicht durchgeführt wird, kann die Funktionseinheit das berechnete Skalarprodukt an den Akkumulator der nächsten Schicht ausgeben, wie in Block 2112 gezeigt.
Jede Schicht kann während jedes Zyklus Berechnungen unter Verwendung von bereitgestellten Quelldaten durchführen. In einer Ausführungsform werden Berechnungen für eine gegebene Anweisung auf Pipeline-Weise durchgeführt. In Abhängigkeit von der für eine Anweisung spezifizierten Ausführungsgröße und systolischen Tiefe kann die Skalarproduktlogik Operationen für eine oder mehrere Anweisungen parallel durchführen. Alternativ dazu kann eine einzelne Anweisung mehrere Zyklen erfordern, um abgeschlossen zu sein.
In einer Ausführungsform kann das Verfahren 2100 aus 21 durch Hardwarelogik durchgeführt werden, die basierend auf dem in der nachstehenden Tabelle 1 gezeigten Pseudocode.
In dem Pseudocode von Tabelle 1 sind Src0, Src1 und Src2 Register, die Operandendaten speichern, die der nullten Quelle 1812 (src0), der ersten Quelle 1814 (src1) und der zweiten Quelle 1816 (src2) wie in 18A entsprechen. Ferner, bezugnehmend auf 18A, entspricht sdepth der systolischen Tiefe 1818, exec_size entspricht der Ausführungsgröße 1808, und dst entspricht Ziel 1810. In dem Pseudocode referenzieren die identifizierten Register RegNum- und SubregNumfelder. Das RegNumfeld stellt die Registeranzahl für den Operanden bereit. Das subregNumfeld stellt die Subregisteranzahl für den Operanden bereit. Das SubregNumfeld stellt zusammen mit dem entsprechenden RegNumfeld eine byteweise ausgerichtete Adresse für den Ursprung des Registerbereichs bereit. Für manche Anweisungen stellt dieses Feld Bits [4:0] der Byteadresse bereit, während das RegNumfeld Bits [12:5] bereitstellt.
22 ist ein Blockdiagramm einer Rechenvorrichtung 2200 einschließlich eines Grafikprozessors 2204 gemäß einer Ausführungsform. Die Rechenvorrichtung 2200 kann eine Rechenvorrichtung wie z. B. das Datenverarbeitungssystem 100 wie das in 1 sein. Die Rechenvorrichtung 2200 kann auch eine Kommunikationsvorrichtung wie z. B. eine Set-Top-Box (z. B. internetbasierte Kabelfernseh-Set-Top-Boxen etc.), Vorrichtungen auf Basis des Global-Positioning-Systems (GPS), etc. sein oder kann darin umfasst sein. Die Rechenvorrichtung 2200 kann auch eine mobile Rechenvorrichtung wie z. B. Mobiltelefone, Smartphones, Personal Digital Assistants (PDAs), Tablet-Computer, Laptop-Computer, E-Reader, Smart Television, Fernsehplattformen, tragbare Geräte (z.B. Brillen, Uhren, Armbänder, Smartcards, Schmuck, Kleidungsstücke usw.), Media-Player usw. sein oder darin umfasst sein. Beispielsweise umfasst die Rechenvorrichtung 2200 eine mobile Rechenvorrichtung, die eine integrierte Schaltung („IC“) einsetzt, wie z. B. ein System auf einem Chip („SoC“ oder „SOC“), integrierte verschiedene Hardware- und/oder Softwarekomponenten von Rechenvorrichtung 2200 auf einem einzelnen Chip.
Die Rechenvorrichtung 2200 umfasst einen Grafikprozessor 2204. Der Grafikprozessor 2204 stellt einen beliebigen hierin beschriebenen Grafikprozessor bereit. Der Grafikprozessor umfasst einen oder mehrere Grafikengines, Grafikprozessorkerne und andere Grafikausführungsressourcen wie hierin beschrieben. Solche Grafikausführungsressourcen können, ohne jedoch darauf eingeschränkt zu sein, in Form von Ausführungseinheiten, Shader-Maschinen, Fragmentprozessoren, Vertexprozessoren, Streaming-Multiprozessoren, Grafikprozessorclustern oder einer beliebigen Sammlung von Rechenressourcen dargestellt sein, die für die Verarbeitung von Grafikressourcen oder Bildressourcen oder für universelle Rechenoperationen in einem heterogenen Prozessor geeignet sein.
In einer Ausführungsform umfasst der Grafikprozessor 2204 einen Cache 2214, der ein einzelner Cache sein kann oder in mehrere Cache-Speicher-Segmente unterteilt sein kann, einschließlich, ohne jedoch darauf eingeschränkt zu sein, einer beliebigen Anzahl von L1, L2, L3 oder L4-Cache-Speichern, Render-Cache-Speichern, Tiefen-Cache-Speichern, Sampler-Cache-Speichern und/oder Shader-Einheit-Cache-Speichern. In manchen Ausführungsformen umfasst der Grafikprozessor 2204 eine Arbeitslasteinheit 2224, eine Matrixeinheit 2234 und einen GPGPU-Engine 2244. Die Arbeitslasteinheit 2224 kann Arbeitslastoperationen für die Durchführung an der Matrixeinheit 2234 und dem GPGPU-Engine 2244 planen. Die Arbeitslasteinheit 2224 kann Hardwarelogikeinheiten aufweisen, einschließlich, aber ohne darauf eingeschränkt zu sein, der Planersteuereinrichtung 1522 aus 15. Die Matrixeinheit 2234 umfasst in einer Ausführungsform den Matrixbeschleuniger 1523 wie in 15. Die Matrixeinheit 2234 kann eine Skalarproduktbeschleunigungslogik umfassen, einschließlich der hierin beschriebenen systolischen Skalarproduktlogik, ohne jedoch darauf eingeschränkt zu sein.
Wie veranschaulicht kann die Rechenvorrichtung 2200 in einer Ausführungsform und zusätzlich zu dem Grafikprozessor 2204 weiters eine beliebige Anzahl und beliebige Art von Hardwarekomponenten und/oder Softwarekomponenten umfassen, einschließlich eines Anwendungsprozessors 2206, eines Speichers 2208 und Eingabe/Ausgabe(I/O)-Quellen 2210, ohne jedoch darauf eingeschränkt zu sein. Der Anwendungsprozessor 2206 kann mit einer Hardware-Grafik-Pipeline interagieren, wie in Bezug auf 3 veranschaulicht, um eine Grafik-Pipeline-Funktionalität zu teilen. Verarbeitete Daten werden in einem Puffer in der Hardware-Grafik-Pipeline gespeichert und Statusinformationen werden in Speicher 2208 gespeichert. Die resultierenden Daten können auf eine Anzeigesteuereinrichtung für die Ausgabe über eine Anzeigevorrichtung übertragen werden, wie z. B. die Anzeigevorrichtung 320 von 3. Die Anzeigevorrichtung kann von unterschiedlichem Typ sein, wie z. B. Kathodenstrahlröhre (CRT), Dünnfilmtransistor (TFT), Flüssigkristallanzeige (LCD), Organische Leuchtdioden (OLED) etc. und kann konfiguriert sein, um einem Benutzer Anzeigeinformationen über eine grafische Benutzerschnittstelle anzuzeigen.
Der Anwendungsprozessor 2206 kann einen oder mehrere Prozessoren umfassen, wie z. B. Prozessor(en) 102 aus 1 und kann die zentral Verarbeitungseinheit (CPU) sein, die zumindest teilweise verwendet wird, um ein Betriebssystem (OS) 2202 für die Rechenvorrichtung 2200 auszuführen. Das OS 2202 kann als Schnittstelle zwischen Hardware- und/oder physikalischen Ressourcen der Rechenvorrichtung 2200 und einem oder mehreren Benutzern dienen. Das OS 2202 kann eine Treiberlogik für verschiedene Hardwarevorrichtungen in der Rechenvorrichtung 2200 umfassen, einschließlich Grafiktreiberlogik 2222, wie z. B. den Benutzermodusgrafiktreiber 1026 und/oder Kernel-Modus-Grafiktreiber 1029 aus 10.
Es wird in Betracht gezogen, dass der Grafikprozessor 2204 in manchen Ausführungsformen als Teil des Anwendungsprozessors 2206 (wie z. B. als Teil eines physikalischen CPU-Pakets) existieren kann, wobei in diesem Fall zumindest ein Teil des Speichers 2208 von dem Anwendungsprozessor 2206 und dem Grafikprozessor 2204 geteilt werden kann, obwohl zumindest ein Teil des Speichers 2208 exklusiv für den Grafikprozessor 2204 sein kann oder der Grafikprozessor 2204 einen separaten Speicherplatz haben kann. Der Speicher 2208 kann eine vorab zugeordnete Region eines Puffers (z. B. eines Framepuffers) umfassen; jedoch sollten Fachleute auf dem Gebiet der Erfindung verstehen, dass die Ausführungsformen nicht so eingeschränkt sind und dass ein beliebiger Speicher, auf den von der unteren Grafik-Pipeline zugegriffen werden kann, verwendet werden kann. Der Speicher 2208 kann unterschiedliche Formen von Direktzugriffsspeichern (RAM) (z. B. SDRAM, SRAM etc.) umfassen, die eine Anwendung umfassen, die den Grafikprozessor 2204 verwendet, um eine Desktop- oder 3D-Grafikszene zu rendern. Ein Speichersteuereinrichtungshub, wie z. B. eine Speichersteuerungsvorrichtung 116 aus 1 kann auf Daten in dem Speicher 2208 zugreifen und sie an den Grafikprozessor 2204 für die Grafik-Pipeline-Verarbeitung weiterleiten. Der Speicher 2208 kann für andere Komponenten innerhalb der Rechenvorrichtung 2200 verfügbar sein. Beispielsweise können beliebige Daten (z. B. Eingabegrafikdaten), die von unterschiedlichen I/O-Quellen 2210 der Rechenvorrichtung 2200 erhalten werden, temporär in den Speicher 2208 eingereiht werden, bevor sie von einem oder mehreren Prozessoren (z. B. Anwendungsprozessor 2206) in der Implementierung eines Softwareprogramms oder Anwendung verarbeitet werden. Ebenso sollten Daten, die ein Softwareprogramm bestimmt von der Rechenvorrichtung 2200 durch eine der Rechensystemschnittstellen an eine externe Einheit gesendet oder in einem internen Speicherelement gespeichert werden, sie werden oft vorübergehend im Speicher 2208 in die Warteschlange gestellt, bevor sie übertragen oder gespeichert werden.
Die I/O-Quellen können Vorrichtungen wie z. B. Touchscreens, Touchpanels, Touchpads, virtuelle oder reguläre Tastaturen, virtuelle oder reguläre Mäuse, Ports, Steckverbinder, Netzwerkgeräte oder dergleichen umfassen und können über einen Plattform-Steuereinrichtungs-Hub 130 angeschlossen werden, wie in 1 angegeben. Zusätzlich dazu können die I/O-Quellen 2210 eine oder mehrere I/O-Vorrichtungen umfassen, die zum Übertragen von Daten an und/oder von der Rechenvorrichtung 2200 (z. B. einem Netzwerkadapter) implementiert sind; oder für einen groß angelegten nichtflüchtigen Speicher innerhalb der Rechenvorrichtung 2200 (z. B. eine Festplatte). Benutzereingabevorrichtungen, einschließlich alphanumerischer und anderer Tasten, können verwendet werden, um Informationen und Befehlsauswahl an Grafikprozessor 2204 zu kommunizieren. Eine weitere Art von Benutzereingabevorrichtung ist die Cursor-Steuerung, wie z. B. eine Maus, ein Trackball, ein Touchscreen, ein Touchpad oder Cursor-Richtungstasten, um Richtungsinformationen und Befehlsauswahlen an die GPU zu kommunizieren und um die Cursorbewegung auf der Anzeigevorrichtung zu steuern. Kamera- und Mikrofonarrays der Rechenvorrichtung 2200 können eingesetzt werden, um Gesten zu beobachten, Audio und Video auszunehmen und um visuelle und Audiobefehle zu empfangen und zu übertragen.
I/O-Quellen 2210, die als Netzwerkschnittstellen konfiguriert sind, können Zugang zu einem Netzwerk, wie z. B. einem LAN, einem Wide-Area-Netzwerk (WAN), einem Metropolitan-Area-Netzwerk (MAN), einem Personal-Area- Netzwerk (PAN), Bluetooth, einem Cloud-Netzwerk, ein Mobilfunknetz (z.B. 3. Generation (3G), 4. Generation (4G), etc.), einem Intranet, dem Internet, etc. bereitstellen. Netzwerkschnittstelle(n) können beispielsweise eine drahtlose Netzwerkschnittstelle mit einer oder mehreren Antennen umfassen. Netzwerkschnittstelle(n) können auch beispielsweise eine drahtgebundene Netzwerkschnittstelle umfassen, um mit entfernten Vorrichtungen über ein Netzwerkkabel zu kommunizieren, das beispielsweise ein Ethernet-Kabel, ein Koaxialkabel, ein Glasfaserkabel, ein serielles Kabel oder ein paralleles Kabel sein kann.
Netzwerkschnittstelle(n) können Zugang zu einem LAN bereitstellen, beispielsweise, indem IEEE 802.11 -Standards entsprochen wird und/oder das die drahtlose Netzwerkschnittstelle kann Zugang zu einem Personal-Area-Netzwerk bereitstellen, beispielsweise, indem Bluetooth-Standards entsprochen wird. Andere drahtlose Netzwerkschnittstellen und/oder Protokolle, einschließlich früherer und nachfolgender Versionen der Standards können auch unterstützt werden. Zusätzlich zu oder anstatt der Kommunikation über die drahtlosen LAN-Standards können Netzwerk-Schnittstelle(n) eine drahtlose Kommunikation bereitstellen, beispielswiese unter Verwendung von Zeitmultiplex, Multiple Access (TDMA)-Protokollen, Global Systems for Mobile Communications (GSM)-Protokolle, Code Division, Multiple Access (CDMA)-Protokollen und/oder jeder andere Art von drahtlosen Kommunikationsprotokollen.
Es ist zu verstehen, dass ein weniger oder mehr ausgestattetes System als das zuvor beschriebene Beispiel für bestimmte Implementierungen bevorzugt werden kann. Daher kann die Konfiguration der Rechenvorrichtung 2200 von Implementierung zu Implementierung in Abhängigkeit von zahlreichen Faktoren, wie z. B. Preisbeschränkungen, Leistungsanforderungen, technologische Verbesserungen oder anderen Umständen variieren. Beispiele umfassen (ohne Einschränkung) eine mobile Vorrichtung, einen Personal Digital Assistant, eine mobile Rechenvorrichtung, ein Smartphone, ein Mobiltelefon, ein Handset, einen Einweg-Pager, einen Zweiweg-Pager, ein Messaging-Gerät, einen Computer, einen Personal-Computer (PC), einen Desktop-Computer, einen Laptop-Computer, einen Notebook-Computer, einen Handheld-Computer, einen Tablet-Computer, einen Server, ein Server-Array oder eine Serverfarm, einen Web-Server, einen Netzwerkserver, einen Internet-Server, eine Arbeitsstation, einen Mini-Computer, einen Hauptrechner, einen Supercomputer, ein Netzwerkgerät, ein Webgerät, ein verteiltes Computersystem, Multiprozessorsysteme, prozessorbasierte Systeme, Unterhaltungselektronik, programmierbare Unterhaltungselektronik, Fernsehen, digitales Fernsehen, eine Set-Top-Box, einen drahtloser Zugangspunkt, eine Basisstation, eine Teilnehmerstation, mobile Teilnehmerzentrale, eine Funknetzsteuerung, einen Router, einen Hub, einen Gateway, eine Brücke, einen Schalter, eine Maschine oder Kombinationen davon.
Ausführungsformen können als ein beliebiges oder eine Kombination von Folgendem implementiert werden: Ein oder mehrere Mikrochips oder integrierte Schaltungen, die unter Verwendung einer übergeordneten Platine, fest verdrahteter Logik, Software, die von einer Speichervorrichtung gespeichert und von einem Mikroprozessor, einer Firmware, einer anwendungsspezifischen integrierten Schaltung (ASIC) und/oder einer feldprogrammierbaren Gateanordnung (FPGA) ausgeführt wird, verbunden sind. Der Begriff „Logik“ kann beispielsweise Software oder Hardware und/oder Kombinationen von Software und Hardware umfassen.
Ausführungsformen können beispielsweise al sein Computerprogrammprodukt bereitgestellt sein, das ein oder mehrere maschinenlesbare Medien umfasst, auf denen maschinenausführbare Anweisungen gespeichert sind, die, wenn sie durch eine oder mehrere Maschinen wie z. B. einen Computer, ein Netzwerk von Computern oder anderen elektronische Vorrichtungen ausgeführt werden, darin resultieren können, dass die eine oder die mehreren Maschinen Operationen gemäß hierin beschriebenen Ausführungsformen ausführen. Ein maschinenlesbares Medium kann, ohne jedoch darauf eingeschränkt zu sein, Disketten, optische Disketten, CD-ROMs (Compact Disc-Read-Only-Memories) und magneto-optische Disketten, ROMs, RAMs, EPROMs (Erasable- Programmable-Read-Only-Memories), EEPROMs (Electrically-Erasable- Programmable-Read-Only-Memories), magnetische oder optische Karten, Flash-Speicher oder andere Arten von nicht-flüchtigen maschinenlesbaren Medien, die zur Speicherung maschinenausführbarer Anweisungen geeignet sind, umfassen.
Darüber hinaus können Ausführungsformen als ein Computerprogrammprodukt heruntergeladen werden, wobei das Programm von einem entfernten Computer (z. B. einem Server) über ein oder mehrere Datensignale an einen anfragenden Computer (z. B. einen Client) übertragen werden kann, die in die in einer Trägerwelle oder einem anderen Ausbreitungsmedium über eine Kommunikationsverknüpfung (z.B. ein Modem und/oder eine Netzwerkverbindung) enthalten sind und/oder moduliert werden.
Hierin beschriebene Ausführungsformen sind für eine Anweisung und assoziierte Logik bereitgestellt, um einen GPGPU-Programmcode zu aktivieren, um auf Hardware-Logik für spezielle Zwecke zuzugreifen, um Skalarproduktoperationen zu beschleunigen. Die folgenden Abschnitte und/oder Beispiele betreffen spezifische Ausführungsformen oder Beispiele davon. Spezifika in den Beispielen können überall in einer oder mehreren Ausführungsformen verwendet werden. Die unterschiedlichen Merkmale der unterschiedlichen Ausführungsformen oder Beispiele können auf unterschiedliche Weise mit manchen umfassten und anderen ausgeschlossenen Merkmalen kombiniert werden, um eine Vielzahl von unterschiedlichen Anwendungen zu bedienen. Beispiele können Gegenstände wie z. B. ein Verfahren, Mittel zur Durchführung von Aktionen des Verfahrens, zumindest ein maschinenlesbares Medium einschließlich Anweisungen, die, wenn sie von einer Maschine durchgeführt werden, bewirken, dass die Maschine Aktionen des Verfahrens oder einer Apparatur oder eines Systems gemäß hierin beschriebenen Ausführungsformen und Beispielen durchführt. Verschiedene Komponenten können ein Mittel zum Durchführen der beschriebenen Operationen oder Funktionen sein.
Eine Ausführungsform stellt eine Grafikverarbeitungseinheit, die eine Abrufeinheit umfasst, bereit, um eine Anweisung für die Durchführung abzurufen, und eine Entschlüsselungseinheit, um die Anweisung in eine entschlüsselte Anweisung zu entschlüsseln. Die entschlüsselte Anweisung ist eine Matrixanweisung, um zu bewirken, dass die Grafikverarbeitungseinheit eine parallele Skalarproduktoperation durchführt. Die GPGPU umfasst auch eine systolische Skalarprodukteinheit, um die entschlüsselte Anweisung unter Verwendung von mehreren systolischen Schichten über eine oder mehrere SIMD-Spuren auszuführen, wobei ein Skalarprodukt, das an einer ersten systolischen Schicht berechnet wird, um die entschlüsselte Anweisung auszuführen an eine zweite systolische Schicht ausgegeben werden muss, wobei jede systolische Schicht einen oder mehrere Sätze von verbundenen Multiplizierern und Addierern, jeden Satz von Multiplizierern und Addierern, um ein Skalarprodukt zu erzeugen, umfasst.
Eine Ausführungsform stellt für ein Verfahren zum Ausführen einer Anweisung bereit, um ein Skalarprodukt von einem oder mehreren Sätzen von Vektoren mit vier Elementen innerhalb einer universellen Grafikverarbeitungseinheit (GPGPU) zu berechnen. Das Verfahren umfasst, dass eine einzelne, innerhalb der GPGPU auszuführende Anweisung abgerufen und entschlüsselt wird, dass die einzelne, in eine entschlüsselte Matrixanweisung entschlüsselte Anweisung bewirkt, dass die GPGPU eine parallele Skalarproduktoperation durchführt; Bestimmen eines Satzes von durchzuführenden Pipeline-Befehlen, um die entschlüsselte Matrixanweisung auf einem Matrixbeschleuniger durchzuführen; und Planen des Satzes von Pipeline-Befehlen für eine systolische Skalarprodukt-Pipeline des Matrixbeschleunigers, um die entschlüsselte Matrixanweisung auszuführen.
Eine Ausführungsform stellt für ein Datenverarbeitungssystem bereit, das einen oder mehrere Prozessoren umfasst, wobei zumindest einer des einen oder der mehreren Prozessoren eine Grafikverarbeitungseinheit umfasst, die Grafikverarbeitungseinheit Hardwarelogik umfasst, um Matrixoperationen zu beschleunigen, wobei die Hardwarelogik eine systolische Skalarprodukteinheit einschließlich mehrerer systolischer Schichten umfasst, wobei jede systolische Schicht einen oder mehrere Sätze von verbundenen Multiplizierern und Addierern umfasst, jeden Satz von Multiplizierern und Addierern, um ein Skalarprodukt zu erzeugen; und ein nichttransitorisches, maschinenlesbares Medium, das Anweisungen zur Durchführung durch die systolische Skalarprodukteinheit speichert, wobei zumindest eine Anweisung, wenn sie entschlüsselt ist, bewirken soll, dass die systolische Punktprodukteinheit eine parallele Punkproduktberechnung unter Verwendung einer oder mehrerer Single-Instruction-Multiple-Data(SIMD)-Spuren durchführt.
Fachleute auf dem Gebiet der Erfindung verstehen aus der vorangegangenen Beschreibung, dass die breit gefächerten Techniken der Ausführungsformen in einer Vielzahl von Formen implementiert werden können. Daher soll, obwohl die Ausführungsformen in Verbindung mit bestimmten Beispielen dafür beschrieben wurden, der wahre Schutzumfang der Erfindung nicht so eingeschränkt sein, da Fachleuten nach dem Studium der Zeichnungen, der Beschreibung und der nachfolgenden Ansprüche andere Änderungen ersichtlich werden.

Claims

Grafikprozessoreinheit, die Folgendes umfasst: eine Abrufeinheit zum Abrufen einer Anweisung zur Ausführung; eine Entschlüsselungseinheit zum Entschlüsseln der Anweisung in eine entschlüsselte Anweisung, wobei die entschlüsselte Anweisung eine Matrixanweisung ist, um die Grafikprozessoreinheit zu veranlassen, eine parallele Skalarproduktoperation durchzuführen; und eine systolische Skalarprodukteinheit zum Ausführen der entschlüsselten Anweisung in einer oder mehreren SIMD- (Single Instruction Multiple Data) Spuren unter Verwendung mehrerer systolischer Schichten, wobei zum Ausführen der entschlüsselten Anweisung ein auf einer ersten systolischen Schicht berechnetes Skalarprodukt an eine zweite systolische Schicht ausgegeben werden soll, wobei jede systolische Schicht einen oder mehrere Sätze von miteinander verbundenen Multiplizierern und Addierern umfasst, wobei jeder Satz von Multiplizierern und Addierern dazu dient, ein Skalarprodukt zu erzeugen.
Grafikverarbeitungseinheit nach Anspruch 1, wobei das auf der ersten systolischen Schicht berechnete Skalarprodukt zu einem Ausgangsakkumulationswert zu addieren ist.
Grafikverarbeitungseinheit nach Anspruch 2, wobei die entschlüsselte Anweisung den Ausgangsakkumulationswert bereitstellt.
Grafikverarbeitungseinheit nach Anspruch 2 oder 3, wobei das Skalarprodukt, das an die zweite systolische Schicht auszugeben ist, in einen Akkumulator der zweiten systolischen Schicht als Ausgangsakkumulationswert für die zweite systolische Schicht einzugeben ist.
Grafikverarbeitungseinheit nach Anspruch 4, wobei die systolische Skalarprodukteinheit zusätzlich dazu zumindest einen Akkumulator für jede systolische Schicht umfasst.
Grafikverarbeitungseinheit nach einem der Ansprüche 1 bis 5, wobei die entschlüsselte Anweisung einer Prädikationsmaske zugeordnet ist, wobei die Prädikationsmaske einen oder mehrere Kanäle einer oder mehrerer SIMD-Spuren aktiviert oder deaktiviert.
Grafikverarbeitungseinheit nach Anspruch 6, wobei jeder Kanal einem oder mehreren Vier-Element-Vektoren zugeordnet ist.
Grafikverarbeitungseinheit nach Anspruch 7, wobei die entschlüsselte Anweisung die systolische Tiefe angibt, wobei die systolische Tiefe eine Anzahl an systolischen Schichten angibt, die zur Berechnung des Skalarprodukts zu verwenden sind.
Grafikverarbeitungseinheit nach Anspruch 7 oder 8, wobei die entschlüsselte Anweisung eine Ausführungsgröße angibt, wobei die Ausführungsgröße eine Anzahl an SIMD-Kanälen angibt, die zur Berechnung des Skalarprodukts zu verwenden sind.
Verfahren zum Ausführen einer Anweisung zur Berechnung eines Skalarprodukts von einem oder mehreren Sätzen von Vier-Element-Vektoren innerhalb einer Universalgrafikverarbeitungseinheit (GPGPU), wobei das Verfahren Folgendes umfasst: das Abrufen und Entschlüsseln einer einzelnen Anweisung, die innerhalb der GPGPU ausgeführt werden soll, wobei die einzelne Anweisung in eine entschlüsselte Matrixanweisung entschlüsselt wird, um die GPGPU zu veranlassen, eine parallele Skalarproduktoperation durchzuführen; das Bestimmen eines Satzes von Pipeline-Befehlen, die auszuführen sind, um die entschlüsselte Matrixanweisung auf einem Matrixbeschleuniger auszuführen; und das Planen des Satzes von Pipeline-Befehlen in eine systolische Skalarprodukt-Pipeline des Matrixbeschleunigers zur Ausführung der entschlüsselten Matrixanwei sung.
Verfahren nach Anspruch 10, das zusätzlich dazu das Aussortieren der entschlüsselten Matrixanweisung als Reaktion auf das Abschließen des Satzes von Pipeline-Befehlen auf dem Matrixbeschleuniger umfasst.
Verfahren nach Anspruch 10 oder 11, das zusätzlich dazu Folgendes umfasst: das Abrufen von Quellwerten und einer Berechnungstiefe für die entschlüsselte Matrixanweisung, wobei die Berechnungstiefe eine Anzahl von systolischen Schichten der systolischen Skalarprodukt-Pipeline angibt, die für die Durchführung der parallelen Skalarproduktoperation zu verwenden sind; das Abrufen eines Ausgangswerts für einen Akkumulator; und das Speichern des Ausgangswerts in einem Akkumulator einer systolischen Schicht der systolischen Skalarprodukt-Pipeline.
Verfahren nach einem der Ansprüche 10 bis 12, wobei der Satz von Pipeline-Befehlen, die auszuführen sind, um die entschlüsselte Matrixanweisung auf einem Matrixbeschleuniger auszuführen, die systolische Skalarprodukt-Pipeline des Matrixbeschleunigers veranlasst, eine Schreibaktivierungsmaske auszuwerten, um einen Satz von aktivierten Parallelverarbeitungskanälen zu bestimmen und für jeden aktivierten Parallelverarbeitungskanal einen Satz von Produkten basierend auf einer elementweisen Multiplikation von Quelleingabeelementen zu generieren.
Verfahren nach Anspruch 13, wobei der Satz von Pipeline-Befehlen zusätzlich dazu veranlasst, dass die systolische Skalarprodukt-Pipeline eine Summe des Satzes von Produkten berechnet und die Summe zu einem Wert in einem Akkumulator einer Ebene der systolischen Skalarprodukt-Pipeline addiert, und wobei das Verfahren zusätzlich dazu die Ausgabe eines Skalarprodukts an den Akkumulator einer nachfolgenden Ebene der systolischen Skalarprodukt-Pipeline oder an ein Zielregister basierend auf einer Berechnungstiefe für die entschlüsselte Matrixanweisung umfasst.
System, das Mittel zum Ausführen eines Verfahrens nach einem der Ansprüche 10 bis 14 umfasst.