DE102020130184A1

DE102020130184A1 - Optimierungsmechanismus mit spärlich besetzten matrizen

Info

Publication number: DE102020130184A1
Application number: DE102020130184.7A
Authority: DE
Inventors: Namita Sharma; Supratim Pal; Biju Puthur Simon; Tovinakere D. Vivek
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2019-12-11
Filing date: 2020-11-16
Publication date: 2021-06-17
Also published as: KR20210074173A; CN112950448A; BR102020019652A2; US11127108B2; JP2021093131A; TW202122994A; US20220092723A1; US20210183002A1; US11443407B2

Abstract

Offenbart ist eine Vorrichtung zum Erleichtern von Matrixverarbeitung. Die Vorrichtung umfasst einen Matrixbeschleuniger, um Eingabematrixdaten zu empfangen, die Eingabematrixdaten in eine Vielzahl von Teilblöcken zu transformieren, einen ersten Block der Teilblöcke zu untersuchen, um zu bestimmen, ob der erste Block spärliche Daten umfasst, eine erste Kachelgröße auszuwählen, wenn bestimmt wird, dass der erste Block spärliche Daten umfasst, und Ausgabematrixdaten auf Grundlage der ersten Kachelgröße zu erzeugen.

Description

HINTERGRUND
Ein neuronales Netz kann als Sammlungen von Neuronen modelliert werden, die in einem azyklischen Graphen verbunden sind. Ein neuronales Netz kann eine Eingabe (einen einzelnen Vektor) empfangen und diese durch eine Reihe verborgener Schichten (hidden layers) umwandeln. Jede verborgene Schicht besteht aus einem Satz von Neuronen, wobei jedes Neuron vollständig mit allen Neuronen in der vorangehenden Schicht verbunden ist und wobei Neuronen in einer einzelnen Schicht vollkommen unabhängig funktionieren und keine Verbindungen gemeinsam nutzen. Ein neuronales Faltungsnetz (CNN, convolutional neural network) ähnelt einem normalen neuronalen Netz. Jedes Neuron empfängt einige Eingaben, führt ein Punktprodukt (dot product) aus und folgt diesem wahlweise mit einer Nichtlinearität. Ein CNN ist jedoch speziell für den Umgang mit eingegebenen Bilddaten konzipiert. Auf Grundlage einer Rohbilddateneingabe gibt das Netz eine Klassifizierungsbewertung für die Eingabedaten aus.
Ein Paralleldatenverarbeitungssystem, das dafür konfiguriert ist, Verarbeitung als neuronales Netz durchzuführen, kann einen Grafikprozessor aufweisen, der dafür konfiguriert sein kann, an Grafikdaten bestimmte Operationen wie beispielsweise Linearinterpolation, Tesselation, Rasterung, Texturabbildung (texture mapping), Tiefenprüfung (depth testing) usw. durchzuführen. Teile solcher Grafikprozessoren können programmierbar gemacht sein, wodurch solche Prozessoren ein breites Spektrum an Operationen zur Verarbeitung von Vertex- und Fragmentdaten unterstützen können. Vollständig programmierbare Ausführungseinheiten innerhalb eines Grafikprozessors können vorteilhaft genutzt werden, um eine Vielfalt paralleler Verarbeitungsoperationen durchzuführen. Um den Durchsatz zu maximieren, können Grafikprozessoren jedoch einige Operationen mittels spezialisierter Logikeinheiten mit fester Funktion durchführen.
Figurenliste
Zum besseren Verständnis der vorstehend genannten Merkmale der vorliegenden Ausführungsformen folgt eine eingehendere Beschreibung der vorstehend kurz zusammengefassten Ausführungsformen unter Bezugnahme auf Ausführungsformen, von denen einige in den beiliegenden Zeichnungen veranschaulicht sind. Es wird jedoch angemerkt, dass die beiliegenden Zeichnungen lediglich typische Ausführungsformen veranschaulichen und daher nicht als den Umfang einschränkend zu verstehen sind.

1 ist ein Blockschaubild eines Verarbeitungssystems gemäß einer Ausführungsform;
2A bis 2D veranschaulichen Datenverarbeitungssysteme und Grafikprozessoren, die durch vorliegend beschriebene Ausführungsformen bereitgestellt werden;
3A bis 3C veranschaulichen Blockschaubilder weiterer Grafikprozessor- und Rechenbeschleuniger-Architekturen, die durch Ausführungsformen bereitgestellt werden;
4 ist ein Blockschaubild einer Grafikverarbeitungs-Engine eines Grafikprozessors gemäß einigen Ausführungsformen;
5A bis 5B veranschaulichen Thread-Ausführungslogik 500 einschließlich eines Arrays in einem Grafikprozessor eingesetzter Verarbeitungselemente gemäß Ausführungsformen;
6 veranschaulicht eine weitere Ausführungseinheit 600 gemäß einer Ausführungsform;
7 ist ein Blockschaubild, das Anweisungsformate eines Grafikprozessors gemäß einigen Ausführungsformen veranschaulicht;
8 ist ein Blockschaubild eines Grafikprozessors gemäß einer weiteren Ausführungsform;
9A & 9B veranschaulichen ein Befehlsformat und eine Befehlssequenz eines Grafikprozessors gemäß einigen Ausführungsformen;
10 veranschaulicht eine beispielhafte Grafiksoftwarearchitektur für ein Datenverarbeitungssystem gemäß einigen Ausführungsformen;
11A bis 11D veranschaulichen eine Package-Baugruppe für eine integrierte Schaltung gemäß einer Ausführungsform;
12 ist ein Blockschaubild, das eine beispielhafte, als Ein-Chip-System (system on a chip) ausgebildete integrierte Schaltung gemäß einer Ausführungsform veranschaulicht;
13A & 13B sind Blockschaubilder, die einen weiteren beispielhaften Grafikprozessor veranschaulichen;
14 veranschaulicht einen Software-Stack für maschinelles Lernen gemäß einer Ausführungsform;
15A bis 15B veranschaulichen Schichten beispielhafter tiefer neuronaler Netze (deep neural networks);
16 veranschaulicht ein beispielhaftes rekurrentes neuronales Netz (recurrent neural network);
17 veranschaulicht Training und Einsatz eines tiefen neuronalen Netzes;
18 ist ein Blockschaubild, das verteiltes Lernen (distributed learning) veranschaulicht;
19 ist ein Blockschaubild eines Datenverarbeitungssystems gemäß einer Ausführungsform;
20 veranschaulicht eine von einer Anweisungspipeline durchgeführte Matrix-Operation gemäß einer Ausführungsform;
21 veranschaulicht eine Ausführungsform gekachelter Matrix-Daten;
22A bis 22C veranschaulichen Ausführungsformen von Teilblöcken;
23A & 23B veranschaulichen Ausführungsformen einer systolischen Pipeline; und
24 ist ein Flussdiagramm, das eine Ausführungsform zum Durchführen von Kachelungsoptimierung veranschaulicht.

AUSFÜHRLICHE BESCHREIBUNG
In Ausführungsformen untersucht ein Matrix-Beschleuniger empfangene Matrix-Daten und optimiert auf Grundlage der Spärlichkeit (sparsity) der Daten eine Verarbeitungskachelgröße.
Systemübersicht
1 ist ein Blockschaubild eines Verarbeitungssystems 100 gemäß einer Ausführungsform. Das System 100 kann in einem Einzelprozessor-Desktop-System, einem Multiprozessor-Workstation-System oder einem Server-System mit einer großen Anzahl an Prozessoren 102 oder Prozessorkernen 107 verwendet werden. In einer Ausführungsform ist das System 100 eine Verarbeitungsplattform, die in einer integrierten Ein-Chip-System- (SoC-) Schaltung für den Einsatz in mobilen, tragbaren oder eingebetteten Einrichtungen wie beispielsweise in Internet-of-Things- (IoT-) Einrichtungen mit drahtgebundener oder drahtloser Konnektivität zu einem lokalen oder einem Weitverkehrsnetz integriert ist.
In einer Ausführungsform kann das System 100 Folgendes aufweisen, damit gekoppelt oder darin integriert sein: eine Server-basierte Spielplattform; eine Spielkonsole, darunter eine Spiel- und Medienkonsole; eine mobile Spielkonsole, eine tragbare Spielkonsole oder eine Online-Spielkonsole. In einigen Ausführungsformen ist das System 100 Teil eines Mobiltelefons, eines Smartphones, einer Tablet-Datenverarbeitungseinrichtung oder einer mobilen Einrichtung mit Internet-Anbindung wie beispielsweise eines Laptops mit geringer interner Speicherkapazität. Das Verarbeitungssystem 100 kann auch Folgendes aufweisen, damit gekoppelt oder darin integriert sein: eine tragbare Einrichtung wie beispielsweise eine Smartwatch; eine intelligente Brille oder Kleidung, die mit Augmented-Reality- (AR-) oder Virtual-Reality- (VR-) Funktionen erweitert ist, um visuelle, akustische oder taktile Ausgaben bereitzustellen, um visuelle, akustische oder taktile Erfahrung der realen Welt zu ergänzen oder anderweitig Text, Audio, Grafiken, Video, holografische Bilder oder Video- oder taktiles Feedback bereitzustellen; eine andere Augmented-Reality- (AR-) Einrichtung; oder eine andere Virtual-Reality- (VR-) Einrichtung. In einigen Ausführungsformen weist das Verarbeitungssystem 100 eine Femseh- oder Set-Top-Box-Einrichtung auf oder ist ein Teil davon. In einer Ausführungsform kann das System 100 ein selbstfahrendes Fahrzeug wie beispielsweise einen Bus, einen Sattelschlepper, ein Auto, ein Motor- oder Elektrorad, ein Flugzeug oder ein Gleitflugzeug (oder eine beliebige Kombination aus diesen) aufweisen, mit diesen gekoppelt oder in diese integriert sein. Das selbstfahrende Fahrzeug kann das System 100 verwenden, um die um das Fahrzeug herum erfasste Umgebung zu verarbeiten.
In einigen Ausführungsformen weisen der eine oder die mehreren Prozessoren 102 jeweils einen oder mehrere Prozessorkerne 107 zur Verarbeitung von Befehlen auf, die bei ihrer Ausführung Operationen für System- oder Nutzersoftware durchführen. In einigen Ausführungsformen ist mindestens einer des einen oder der mehreren Prozessorkerne 107 dafür konfiguriert, einen bestimmten Befehlssatz 109 auszuführen. In einigen Ausführungsformen kann der Befehlssatz 109 Datenverarbeitung mit komplexem Befehlssatz (Complex Instruction Set Computing, CISC), Datenverarbeitung mit reduziertem Befehlssatz (Reduced Instruction Set Computing, RISC) oder Datenverarbeitung über ein überlanges Befehlswort (Very Long Instruction Word, VLIW) erleichtern. Ein oder mehrere Prozessorkerne 107 können einen anderen Befehlssatz 109 verarbeiten, der Anweisungen zum Erleichtern der Emulation anderer Befehlssätze aufweisen kann. Der Prozessorkern 107 kann zudem andere Verarbeitungseinrichtungen aufweisen, beispielsweise einen digitalen Signalprozessor (DSP).
In einigen Ausführungsformen weist der Prozessor 102 Cachespeicher 104 auf. Je nach Architektur kann der Prozessor 102 über einen einzigen internen Cache oder mehrere interne Cache-Level verfügen. In einigen Ausführungsformen wird der Cachespeicher von verschiedenen Komponenten des Prozessors 102 gemeinsam genutzt. In einigen Ausführungsformen verwendet der Prozessor 102 zudem einen externen Cache (z.B. einen Level-3- (L3-) Cache oder Last-Level-Cache (LLC)) (nicht gezeigt), der von Prozessorkernen 107 mittels bekannter Cache-Kohärenz-Methoden gemeinsam verwendet werden kann. Zusätzlich kann in dem Prozessor 102 eine Registerdatei 106 umfasst sein, die verschiedene Registertypen zum Speichern verschiedener Datentypen (z.B. Ganzzahlenregister, Gleitkommaregister, Statusregister und ein Befehlszeigerregister) aufweist. Bei einigen Registern kann es sich um Allzweckregister handeln, während andere Register spezifisch für den Aufbau des Prozessors 102 sein können.
In einigen Ausführungsformen sind ein oder mehrere Prozessoren 102 mit einem oder mehreren Schnittstellenbussen 110 gekoppelt, um Kommunikationssignale wie beispielsweise Adress-, Daten- oder Steuersignale zwischen dem Prozessor 102 und anderen Komponenten im System 100 zu übertragen. In einer Ausführungsform kann es sich bei dem Schnittstellenbus 110 um einen Prozessorbus wie beispielsweise eine Version des Direct-Media-Interface- (DMI-) Busses handeln. Prozessorbusse sind jedoch nicht auf den DMI-Bus eingeschränkt und können einen oder mehrere Peripheral-Component-Interconnect-Busse (z.B. PCI, PCI Express), Speicherbusse oder andere Arten von Schnittstellenbussen umfassen. In einer Ausführungsform weisen der oder die Prozessoren 102 einen integrierten Speichercontroller 116 und einen Platform Controller Hub 130 auf. Der Speichercontroller 116 erleichtert Kommunikation zwischen einer Speichereinrichtung und anderen Komponenten des Systems 100, während der Platform Controller Hub (PCH) 130 Verbindungen mit E/A-Einrichtungen über einen lokalen E/A-Bus bereitstellt.
Die Speichereinrichtung 120 kann eine dynamische Direktzugriffsspeicher- (DRAM-) Einrichtung, eine statische Direktzugriffsspeicher-(SRAM-) Einrichtung, eine Flashspeichereinrichtung, eine Phasenänderungsspeichereinrichtung oder eine andere Speichereinrichtung mit geeigneter Leistung sein, um als Prozessspeicher zu dienen. In einer Ausführungsform kann die Speichereinrichtung 120 als Systemspeicher für das System 100 arbeiten, um Daten 122 und Anweisungen 121 zur Verwendung zu speichern, wenn der eine oder die mehreren Prozessoren 102 eine Anwendung oder einen Prozess ausführen. Der Speichercontroller 116 ist zudem mit einem optionalen externen Grafikprozessor 118 gekoppelt, der mit dem einen oder den mehreren Grafikprozessoren 108 in den Prozessoren 102 kommunizieren kann, um Grafik- und Medienoperationen durchzuführen. In einigen Ausführungsformen können Grafik-, Medien- und/oder Rechenoperationen durch einen Beschleuniger 112 unterstützt werden, bei dem es sich um einen Koprozessor handelt, der dafür konfiguriert sein kann, einen spezialisierten Satz von Grafik-, Medien- oder Rechenoperationen durchzuführen. Beispielsweise handelt es sich in einer Ausführungsform bei dem Beschleuniger 112 um einen Matrix-Multiplikationsbeschleuniger, der verwendet wird, um Maschinenlern- oder Rechenoperationen zu optimieren. In einer Ausführungsform handelt es sich bei dem Beschleuniger 112 um einen Strahlverfolgungs- (Ray-Tracing-) Beschleuniger, der verwendet werden kann, um zusammen mit dem Grafikprozessor 108 Strahlverfolgungsoperationen durchzuführen. In einer Ausführungsform kann anstelle des oder zusammen mit dem Beschleuniger 112 ein externer Beschleuniger 119 verwendet werden.
In einigen Ausführungsformen kann eine Anzeigeeinrichtung 111 mit dem oder den Prozessoren 102 verbunden sein. Bei der Anzeigeeinrichtung 111 kann es sich um eine interne Anzeigeeinrichtung wie in einer mobilen elektronischen Einrichtung oder einer Laptop-Einrichtung und/oder um eine über eine Anzeigenschnittstelle (z.B. DisplayPort usw.) angeschlossene externe Anzeigeeinrichtung handeln. In einer Ausführungsform kann es sich bei der Anzeigeeinrichtung 111 um eine am Kopf befestigbare Anzeige (head mounted display, HMD) wie beispielsweise eine stereoskopische Anzeigeeinrichtung zur Verwendung in Virtual-Reality- (VR-) Anwendungen oder Augmented-Reality- (AR-) Anwendungen handeln.
In einigen Ausführungsformen ermöglicht der Platform Controller Hub 130 die Verbindung von Peripheriegeräten mit der Speichereinrichtung 120 und dem Prozessor 102 über einen Hochgeschwindigkeits-E/A-Bus. Zu den E/A-Peripheriegeräten zählen, ohne jedoch hierauf eingeschränkt zu sein, ein Audiocontroller 146, ein Netzwerkcontroller 134, eine Firmware-Schnittstelle 128, ein drahtloser Sendeempfänger 126, Berührungssensoren 125, eine Datenspeichereinrichtung 124 (z.B. nichtflüchtiger Speicher, flüchtiger Speicher, Festplattenlaufwerk, Flashspeicher, NAND, 3D-NAND, 3D-XPoint usw.). Die Datenspeichereinrichtung 124 kann über eine Speicherschnittstelle (z.B. SATA) oder über einen Peripheriebus wie beispielsweise einen Peripheral-Component-Interconnect-Bus (z.B. PCI, PCI express) verbunden sein. Zu den Berührungssensoren 125 können Touchscreen-Sensoren, Drucksensoren oder Fingerabdrucksensoren zählen. Bei dem drahtlosen Sendeempfänger 126 kann es sich um einen WiFi-Sendeempfänger, einen Bluetooth-Sendeempfänger oder einen Mobilnetzwerk-Sendeempfänger wie beispielsweise einen 3G-, 4G-, 5G- oder Long-Term-Evolution- (LTE-) Sendeempfänger handeln. Die Firmware-Schnittstelle 128 ermöglicht Kommunikation mit System-Firmware und kann beispielsweise eine vereinheitlichte erweiterbare Firmware-Schnittstelle (Unified Extensible Firmware Interface, UEFI) sein. Der Netzwerkcontroller 134 kann eine Netzwerkverbindung zu einem drahtgebundenen Netzwerk ermöglichen. In einigen Ausführungsformen ist mit dem Schnittstellenbus 110 ein Hochleistungs-Netzwerkcontroller (nicht gezeigt) gekoppelt. Bei dem Audiocontroller 146 handelt es sich in einer Ausführungsform um einen Mehrkanal-High-Definition-Audiocontroller. In einer Ausführungsform weist das System 100 einen optionalen Legacy-E/A-Controller 140 zum Koppeln von Legacy-(z.B. Personal System 2 (PS/2)) Einrichtungen an das System auf Der Platform Controller Hub 130 kann zudem mit einem oder mehreren Universal-Serial-Bus- (USB-) Controllern 142 verbunden sein, um Eingabeeinrichtungen wie beispielsweise Tastatur- und Maus- 143 Kombinationen, eine Kamera 144 oder andere USB-Eingabeeinrichtungen zu verbinden.
Es versteht sich, dass das gezeigte System 100 beispielhaft und nicht einschränkend ist, da auch andere Arten von Datenverarbeitungssystemen mit anderer Konfiguration verwendet werden können. So können etwa in einem Beispiel der Speichercontroller 116 und der Platform Controller Hub 130 in einen diskreten externen Grafikprozessor wie beispielsweise den externen Grafikprozessor 118 integriert sein. In einer Ausführungsform können der Platform Controller Hub 130 und/oder der Speichercontroller 116 außerhalb des einen oder der mehreren Prozessoren 102 liegen. Beispielsweise kann das System 100 einen externen Speichercontroller 116 und einen externen Platform Controller Hub 130 aufweisen, die als Speichercontroller-Hub und Peripheriecontroller-Hub in einem System-Chipsatz konfiguriert sein können, der mit dem oder den Prozessoren 102 in Kommunikation steht.
Beispielsweise können Platinen („Schlitten“) verwendet werden, auf denen Komponenten wie beispielsweise CPUs, Speicher und andere Komponenten platziert werden und die für erhöhte thermische Leistungsfähigkeit ausgelegt sind. In einigen Beispielen befinden sich verarbeitende Komponenten wie beispielsweise die Prozessoren auf einer Oberseite eines Schlittens, während sich prozessornaher Speicher wie beispielsweise DIMMs auf einer Unterseite des Schlittens befindet. Aufgrund der durch diese Ausgestaltung bereitgestellten verbesserten Luftströmung können die Komponenten mit höheren Taktraten und Leistungspegeln als in typischen Systemen arbeiten, wodurch die Leistungsfähigkeit erhöht wird. Des Weiteren sind die Schlitten für Blindkopplung mit Leistungs- und Datenübertragungskabeln in einem Rack konfiguriert, was ihre Fähigkeit zur schnellen Entnahme, Aufrüstung, Neuinstallation und/oder Auswechslung steigert. Ebenso sind auf den Schlitten befindliche einzelne Komponenten wie beispielsweise Prozessoren, Beschleuniger, Kurzzeitspeicher und Datenspeicherlaufwerke aufgrund ihrer erhöhten Beabstandung zueinander für einfache Aufrüstung konfiguriert. In der veranschaulichenden Ausführungsform beinhalten die Komponenten zusätzlich Hardware-Attestiermerkmale, um deren Authentizität zu belegen.
Ein Datenzentrum kann eine einzige Netzarchitektur („Fabric“) verwenden, die mehrere andere Netzwerkarchitekturen einschließlich Ethernet und Omni-Path unterstützt. Die Schlitten können über Glasfaser, die höhere Bandbreiten und geringere Latenz bietet als typische Kabel mit verdrillten Aderpaaren (z.B. Kategorie 5, Kategorie 5e, Kategorie 6 usw.), mit Switches gekoppelt sein. Aufgrund der Verschaltungen und Netzarchitektur mit hoher Bandbreite und geringer Latenz kann das Datenzentrum im Betrieb Ressourcen wie beispielsweise Kurzzeitspeicher, Beschleuniger (z.B. GPUs, Grafikbeschleuniger, FPGAs, ASICs, mit neuronalen Netzen und/oder künstlicher Intelligenz arbeitende Beschleuniger usw.) und Datenspeicherlaufwerke, die physisch getrennt sind, zusammenschließen und diese nach Bedarf an Rechenressourcen (z.B. Prozessoren) bereitstellen, was den Rechenressourcen ermöglicht, auf die zusammengeschlossenen Ressourcen so zuzugreifen, als wären diese lokal.
Eine Leistungsversorgung oder -quelle kann dem System 100 oder einer beliebigen Komponente oder einem beliebigen System, die vorliegend beschrieben werden, Spannung und/oder Strom bereitstellen. In einem Beispiel weist die Stromversorgung einen AC/DC- (Wechselstrom-zu-Gleichstrom-) Adapter zum Einstecken in eine Wandsteckdose auf. Eine solche AC-Leistungsquelle kann eine erneuerbare Energiequelle (z. B. Solarstrom) sein. In einem Beispiel weist die Leistungsquelle eine Gleichstromquelle wie beispielsweise einen externen Wechselstrom-Gleichstrom-Wandler auf. In einem Beispiel weist die Leistungsquelle oder Leistungsversorgung Hardware für drahtloses Aufladen zum Aufladen über Nähe zu einem Ladefeld auf. In einem Beispiel kann die Leistungsquelle eine interne Batterie, eine Wechselstromversorgung, eine bewegungsbasierte Leistungsversorgung, eine Solarstromversorgung oder eine Brennstoffzellenquelle umfassen.
2A bis 2D veranschaulichen Datenverarbeitungssysteme und Grafikprozessoren, die durch vorliegend beschriebene Ausführungsformen bereitgestellt werden. Die Elemente der 2A bis 2D, die gleiche Bezugszeichen (oder Namen) wie die Elemente einer anderen Figur aufweisen, können in ähnlicher Weise wie der vorliegend an anderer Stelle beschriebenen arbeiten oder fungieren, sind hierauf jedoch nicht eingeschränkt.
2A ist ein Blockschaubild einer Ausführungsform eines Prozessors 200 mit einem oder mehreren Prozessorkernen 202A bis 202N, einem integrierten Speichercontroller 214 und einem integrierten Grafikprozessor 208. Der Prozessor 200 kann weitere Kerne bis einschließlich dem weiteren Kern 202N aufweisen, wie durch die gestrichelten Kästen dargestellt. Jeder der Prozessorkerne 202A bis 202N weist eine oder mehrere interne Cache-Einheiten 204A bis 204N auf. In einigen Ausführungsformen hat zudem jeder Prozessor Zugriff auf eine oder mehrere gemeinsam genutzte Cache-Einheiten 206. Die internen Cache-Einheiten 204A bis 204N und die gemeinsam genutzten Cache-Einheiten 206 repräsentieren eine Cachespeicher-Hierarchie innerhalb des Prozessors 200. Die Cachespeicher-Hierarchie kann mindestens eine Ebene („Level“) von Befehls- und Daten-Cache innerhalb jedes Prozessorkerns und eine oder mehrere Ebenen von gemeinsam genutztem Mid-Level-Cache wie beispielsweise eine Level-2-(L2-), Level-3- (L3-), Level-4- (L4-) oder andere Cache-Ebenen umfassen, wobei die höchste Cache-Ebene vor dem externen Speicher als LLC klassifiziert wird. In einigen Ausführungsformen bewahrt Cache-Kohärenzlogik die Kohärenz zwischen den verschiedenen Cache-Einheiten 206 und 204A bis 204N.
In einigen Ausführungsformen kann der Prozessor 200 zudem einen Satz aus einer oder mehreren Buscontroller-Einheiten 216 und einen Systemagenten-Kern 210 aufweisen. Die eine oder die mehreren Buscontroller-Einheiten 216 verwalten einen Satz von Peripheriebussen wie beispielsweise einen oder mehrere PCI- oder PCI-express-Busse. Der Systemagenten-Kern 210 stellt Verwaltungsfunktionalität für die verschiedenen Prozessorkomponenten bereit. In einigen Ausführungsformen weist der Systemagenten-Kern 210 einen oder mehrere integrierte Speichercontroller 214 auf, um den Zugriff auf verschiedene externe Speichereinrichtungen (nicht gezeigt) zu verwalten.
In einigen Ausführungsformen umfassen einer oder mehrere der Prozessorkerne 202A bis 202N Unterstützung für gleichzeitiges Multi-Threading. In einer solchen Ausführungsform weist der Systemagenten-Kern 210 Komponenten zum Koordinieren und Betreiben der Kerne 202A bis 202N während der Multi-Threading-Verarbeitung auf. Der Systemagenten-Kern 210 kann zusätzlich eine Leistungssteuereinheit (Power Control Unit, PCU) aufweisen, die Logik und Komponenten zum Regulieren des Leistungszustands der Prozessorkerne 202A bis 202N und des Grafikprozessors 208 aufweist.
In einigen Ausführungsformen weist der Prozessor 200 zusätzlich einen Grafikprozessor 208 zum Ausführen von Grafikverarbeitungsoperationen auf. In einigen Ausführungsformen ist der Grafikprozessor 208 mit dem Satz gemeinsam genutzter Cache-Einheiten 206 und dem Systemagenten-Kern 210 einschließlich des einen oder der mehreren integrierten Speichercontroller 214 gekoppelt. In einigen Ausführungsformen weist der Systemagenten-Kern 210 zudem einen Anzeigecontroller 211 zum Steuern der Ausgabe des Grafikprozessors an eine oder mehrere gekoppelte Anzeigen auf. In einigen Ausführungsformen kann es sich beim Anzeigecontroller 211 auch um ein separates Modul handeln, das über mindestens eine Verbindung mit dem Grafikprozessor gekoppelt ist, oder er kann in den Grafikprozessor 208 integriert sein.
In einigen Ausführungsformen wird eine Ring-basierte Verbindungseinheit 212 verwendet, um die internen Komponenten des Prozessors 200 zu koppeln. Es kann jedoch auch eine alternative Verbindungseinheit verwendet werden, beispielsweise eine Punkt-zu-Punkt-Verbindung, eine geschaltete Verbindung oder andere Methoden einschließlich im Fachgebiet bekannter Methoden. In einigen Ausführungsformen ist der Grafikprozessor 208 mit der Ringverbindung 212 über eine E/A-Verbindung 213 gekoppelt.
Die beispielhafte E/A-Verbindung 213 stellt wenigstens eine von mehreren Varianten von E/A-Verbindungen dar, darunter eine On-Package-E/A-Verbindung, welche die Kommunikation zwischen verschiedenen Prozessorkomponenten und einem eingebetteten Hochleistungs-Speichermodul 218 wie beispielsweise einem eDRAM-Modul erleichtert. In einigen Ausführungsformen können jeder der Prozessorkerne 202A bis 202N und der Grafikprozessor 208 eingebettete Speichermodule 218 als gemeinsamen Last-Level-Cache verwenden.
In einigen Ausführungsformen handelt es sich bei den Prozessorkernen 202A bis 202N um homogene Kerne, die dieselbe Befehlssatzarchitektur ausführen. In einer weiteren Ausführungsform sind die Prozessorkerne 202A bis 202N hinsichtlich der Befehlssatzarchitektur (Instruction Set Architecture, ISA) heterogen, wobei ein oder mehrere Prozessorkerne 202A bis 202N einen ersten Befehlssatz ausführen, während mindestens einer der anderen Kerne einen Teilsatz des ersten Befehlssatzes oder einen anderen Befehlssatz ausführt. In einer Ausführungsform sind die Prozessorkerne 202A bis 202N hinsichtlich der Mikroarchitektur heterogen, wobei ein oder mehrere Kerne mit einer relativ höheren Leistungsaufnahme mit einem oder mehreren Leistungskernen mit einer geringeren Leistungsaufnahme gekoppelt sind. In einer Ausführungsform sind die Prozessorkerne 202A bis 202N hinsichtlich der Rechenleistung heterogen. Zudem kann der Prozessor 200 auf einem oder mehreren Chips oder als integrierte SoC-Schaltung implementiert sein, die neben den veranschaulichten Komponenten auch über andere Komponenten verfügt.
2B ist ein Blockschaubild von Hardware-Logik eines Grafikprozessorkerns 219 gemäß einigen vorliegend beschriebenen Ausführungsformen. Elemente aus 2B, die gleiche Bezugszeichen (oder Namen) wie die Elemente einer anderen Figur aufweisen, können in ähnlicher Weise wie der vorliegend an anderer Stelle beschriebenen arbeiten oder fungieren, sind hierauf jedoch nicht eingeschränkt. Bei dem Grafikprozessor 219, welcher manchmal auch als Kernbaustein bezeichnet wird, kann es sich um einen oder mehrere Grafikkerne innerhalb eines modularen Grafikprozessors handeln. Der Grafikprozessorkern 219 steht beispielhaft für einen Grafikkernbaustein, und ein Grafikprozessor wie vorliegend beschrieben kann je nach angestrebten Energie- und Leistungshüllkurven mehrere Grafikkernbausteine aufweisen. Jeder Grafikprozessorkern 219 kann einen Festfunktionsblock 230 aufweisen, der mit mehreren Teilkernen 221A bis 221F, auch bezeichnet als Teilbausteine, gekoppelt ist, die modulare Blöcke aus Allzwecklogik und Logik mit fester Funktion aufweisen.
In einigen Ausführungsformen weist der Festfunktionsblock 230 eine Geometrie-/Festfunktionspipeline 231 auf, die von allen Teilkernen im Grafikprozessorkern 219 gemeinsam genutzt werden kann, beispielsweise in Grafikprozessor-Implementierungen mit geringerer Leistung und/oder geringerem Stromverbrauch. In verschiedenen Ausführungsformen umfasst die Geometrie-/Festfunktionspipeline 231 eine 3D-Festfunktionspipeline (z.B. 3D-Pipeline 312 wie in 3 und 4 wie nachstehend beschrieben), eine Video-Front-End-Einheit, einen Thread-Spawner und Thread-Dispatcher sowie einen Unified-Return-Buffer-Manager, der vereinheitlichte Rücksprungpuffer (unified return buffer) verwaltet (z.B. den vereinheitlichten Rücksprungpuffer 418 in 4 wie nachstehend beschrieben).
In einer Ausführungsform weist der Festfunktionsblock 230 zudem eine Grafik-SoC-Schnittstelle 232, einen Grafik-Mikrocontroller 233 und eine Medienpipeline 234 auf. Die Grafik-SoC-Schnittstelle 232 stellt eine Schnittstelle zwischen dem Grafikprozessorkern 219 und anderen Prozessorkernen innerhalb einer integrierten Ein-Chip-System-Schaltung bereit. Bei dem Grafik-Mikrocontroller 233 handelt es sich um einen programmierbaren Teilprozessor, der konfigurierbar ist, um verschiedene Funktionen des Grafikprozessorkerns 219 zu verwalten, darunter Thread-Dispatch, Planung und Zurückstellung. Die Medienpipeline 234 (z.B. die Medienpipeline 316 aus 3 und 4 weist Logik auf, um die Decodierung, Codierung, Vorverarbeitung und/oder Nachbearbeitung von Multimedia-Daten, darunter Bild- und Videodaten, zu erleichtern. Die Medienpipeline 234 implementiert Medienoperationen über Anfragen an Rechen- oder Abtastlogik innerhalb der Teilkerne 221 bis 221F.
In einer Ausführungsform ermöglicht die SoC-Schnittstelle 232 dem Grafikprozessorkern 219 die Kommunikation mit Prozessorkemen für Allzweckanwendungen (z.B. CPUs) und/oder anderen Komponenten innerhalb eines SoC, darunter Speicherhierarchieelemente wie beispielsweise ein gemeinsamer Last-Level-Cachespeicher, der System-RAM und/oder eingebetteter On-Chip- oder On-Package-DRAM. Die SoC-Schnittstelle 232 kann auch die Kommunikation mit Festfunktionseinrichtungen innerhalb des SoC ermöglichen, wie beispielsweise Kamera-Bildgebungspipelines, und ermöglicht die Verwendung von und/oder implementiert globale Speicher-Atome, die zwischen dem Grafikprozessorkem 219 und CPUs innerhalb des SoC gemeinsam genutzt werden können. Die SoC-Schnittstelle 232 kann zudem Energieverwaltungssteuerungen für den Grafikprozessorkern 219 implementieren und eine Schnittstelle zwischen einem Taktbereich des Grafikkerns 219 und anderen Taktbereichen innerhalb des SoC ermöglichen. In einer Ausführungsform ermöglicht die SoC-Schnittstelle 232 den Empfang von Befehlspuffern von einem Befehls-Streamer und globalen Thread-Dispatcher, die dafür konfiguriert sind, Befehle und Anweisungen an jeden von einem oder mehreren Grafikkernen innerhalb eines Grafikprozessors bereitzustellen. Die Befehle und Anweisungen können an die Medienpipeline 234 geschickt werden, wenn Medienoperationen durchgeführt werden sollen, oder an eine Geometrie- und Festfunktionspipeline (z.B. Geometrie- und Festfunktionspipeline 231, Geometrie- und Festfunktionspipeline 237), wenn Grafikverarbeitungsoperationen durchgeführt werden sollen.
Der Grafik-Mikrocontroller 233 kann dafür konfiguriert sein, verschiedene Planungs- und Verwaltungsaufgaben für den Grafikprozessorkern 219 durchzuführen. In einer Ausführungsform kann der Grafik-Mikrocontroller 233 die Grafik- und/oder Rechenlastplanung auf den verschiedenen parallelen Grafik-Engines innerhalb der Arrays 222A bis 222F, 224A bis 224F der Ausführungseinheiten (execution unit, EU) innerhalb der Teilkerne 221A bis 221F durchführen. In diesem Planungsmodell kann Host-Software, die auf einem CPU-Kern eines den Grafikprozessorkern 219 aufweisenden SoC ausgeführt wird, Arbeitslasten bereitstellen, die einer von mehreren Grafikprozessoren anfragt, was eine Planungsoperation auf der entsprechenden Grafik-Engine aktiviert. Zu Planungsoperationen zählen Bestimmen, welche Arbeitslast als nächstes ausgeführt werden soll, Liefern einer Arbeitslast an einen Befehls-Streamer, Zurückstellen bestehender Arbeitslasten, die auf einer Engine ausgeführt werden, Überwachen des Fortschritts einer Arbeitslast und Benachrichtigen einer Host-Software, wenn eine Arbeitslast abgeschlossen ist. In einer Ausführungsform kann der Grafik-Mikrocontroller 233 auch stromsparende oder Leerlaufzustände für den Grafikprozessorkern 219 erleichtern, indem er dem Grafikprozessorkern 219 die Möglichkeit gibt, Register innerhalb des Grafikprozessorkerns 219 über stromsparende Zustandsübergänge hinweg unabhängig vom Betriebssystem und/oder der Grafiktreibersoftware auf dem System zu speichern und wiederherzustellen.
Der Grafikprozessorkern 219 kann mehr als oder weniger als die dargestellten Teilkerne 221A bis 221F aufweisen, bis zu N modulare Teilkerne. Für jeden Satz aus NTeilkernen kann der Grafikprozessorkern 219 auch eine gemeinsam genutzte Funktionslogik 235, einen gemeinsam genutzten und/oder Cache-Speicher 236, eine Geometrie-/Festfunktionspipeline 237 sowie eine zusätzliche Festfunktionslogik 238 zur Beschleunigung verschiedener Grafik- und Rechenverarbeitungsoperationen aufweisen. Die gemeinsam genutzte Funktionslogik 235 kann Logikeinheiten aufweisen, die mit der gemeinsam genutzten Funktionslogik 420 aus 4 verbunden sind (z.B. Sampler-, Mathematik- und/oder Inter-Thread-Kommunikationslogik), die von allen N Teilkernen innerhalb des Grafikprozessorkerns 219 gemeinsam genutzt werden können. Der gemeinsam genutzte und/oder Cache-Speicher 236 kann ein Last-Level-Cache für den Satz aus N Teilkernen 221A bis 221F innerhalb des Grafikprozessorkerns 219 sein und kann zudem als gemeinsam genutzter Speicher dienen, auf den mehrere Teilkerne zugreifen können. Die Geometrie-/Festfunktionspipeline 237 kann anstelle der Geometrie-/Festfunktionspipeline 231 innerhalb des Festfunktionsblocks 230 umfasst sein und kann dieselben oder ähnliche Logikeinheiten aufweisen.
In einer Ausführungsform weist der Grafikprozessorkern 219 zusätzliche Festfunktionslogik 238 auf, die verschiedene Festfunktions-Beschleunigungslogik zur Verwendung durch den Grafikprozessorkern 219 aufweisen kann. In einer Ausführungsform weist die zusätzliche Festfunktionslogik 238 eine zusätzliche Geometriepipeline zur Verwendung für reine Positionsschattierung (position only shading) auf. Bei reiner Positionsschattierung existieren zwei Geometriepipelines, die vollständige Geometriepipeline innerhalb der Geometrie-/Festfunktionspipeline 238, 231 und eine Sortierpipeline (cull pipeline), bei der es sich um eine zusätzliche Geometriepipeline handelt, die in der zusätzlichen Festfunktionslogik 238 umfasst sein kann. In einer Ausführungsform handelt es sich bei der Sortierpipeline um eine abgespeckte Version der vollständigen Geometriepipeline. Die vollständige Pipeline und die Sortierpipeline können verschiedene Instanzen der gleichen Anwendung ausführen, wobei jede Instanz einen separaten Kontext hat. Reine Positionsschattierung kann lange Sortierdurchläufe verworfener Dreiecke verbergen, wodurch die Schattierung in einigen Instanzen früher abgeschlossen werden kann. Zum Beispiel und in einer Ausführungsform kann die Sortierpipeline-Logik innerhalb der zusätzlichen Festfunktionslogik 238 Positionsschattierer (position shaders) parallel zur Hauptanwendung ausführen und generiert im Allgemeinen kritische Ergebnisse schneller als die vollständige Pipeline, da die Sortierpipeline nur das Positionsattribut der Vertices abruft und schattiert, ohne Rasterung und Rendern der Pixel in den Rahmenpuffer (frame buffer) durchzuführen. Die Sortierpipeline kann die erzeugten kritischen Ergebnisse verwenden, um Sichtbarkeitsinformationen für alle Dreiecke zu berechnen, unabhängig davon, ob diese Dreiecke aussortiert werden. Die vollständige Pipeline (die in diesem Fall als Replay-Pipeline bezeichnet werden kann) kann die Sichtbarkeitsinformationen aufnehmen, um die aussortierten Dreiecke zu überspringen und nur die sichtbaren Dreiecke zu schattieren, die schließlich an die Rasterungsphase übergeben werden.
In einer Ausführungsform kann die zusätzliche Festfunktionslogik 238 zudem Maschinenlern-Beschleunigungslogik umfassen, beispielsweise Festfunktions-Matrixmultiplikationslogik, für Implementierungen, die Optimierungen für Maschinenlemtraining oder Inferenzfindung umfassen.
Im Inneren weist jeder Grafik-Teilkern 221A bis 221F einen Satz Ausführungsressourcen auf, die verwendet werden können, um in Reaktion auf Anfragen von Grafikpipeline-, Medienpipeline- oder Schattierprogrammen Grafik-, Medien- und Rechenoperationen durchzuführen. Die Grafik-Teilkerne 221A bis 221F weisen mehrere EU-Arrays 222A bis 222F, 224A bis 224F, Thread-Dispatch- und Inter-Thread-Kommunikations- (TD/IC-) Logik 223A bis 223F, einen 3D- (z.B. Textur-) Sampler 225A bis 225F, einen Mediensampler 206A bis 206F, einen Schattierprozessor 227A bis 227F und gemeinsam genutzten lokalen Speicher (shared local memory, SLM) 228A bis 228F auf. Die EU-Arrays 222A bis 222F, 224A bis 224F weisen jeweils mehrere Ausführungseinheiten auf, bei denen es sich um Allzweck-Grafikverarbeitungseinheiten handelt, die in der Lage sind, Gleitkomma- und Ganzzahl-/Festkomma-Logikoperationen im Dienste einer Grafik-, Medien- oder Rechenoperation durchzuführen, einschließlich Grafik-, Medien- oder Schattierrechenprogrammen. Die TD/IC-Logik 223A bis 223F führt lokalen Thread-Dispatch und Thread-Steueroperatioinen für die Ausführungseinheiten innerhalb eines Teilkerns aus und erleichtert Kommunikation zwischen auf den Ausführungseinheiten des Teilkerns ausgeführten Threads. Der 3D-Sampler 225A bis 225F kann Textur- oder andere 3D-Grafik betreffende Daten in den Speicher lesen. Der 3D-Sampler kann Texturdaten auf Grundlage eines konfigurierten Abtaststatus und des Texturformats, das einer bestimmten Textur zugeordnet ist, unterschiedlich lesen. Der Mediensampler 206A bis 206F kann auf Grundlage des den Mediendaten zugehörigen Typs und Formats ähnliche Leseoperationen durchführen. In einer Ausführungsform kann jeder Grafik-Teilkern 221A bis 221F alternativ einen kombinierten 3D- und Mediensampler aufweisen. Threads, die auf den Ausführungseinheiten in jedem der Teilkerne 221A bis 221F ausgeführt werden, können den gemeinsamen lokalen Speicher 228A bis 228F in jedem Teilkern nutzen, damit Threads, die innerhalb einer Thread-Gruppe ausgeführt werden, einen gemeinsamen Pool von On-Chip-Speicher nutzen können.
2C veranschaulicht eine Grafikverarbeitungseinheit (Graphics Processing Unit, GPU) 239, die dedizierte Sätze aus Grafikverarbeitungsressourcen aufweist, die in Mehrkerngruppen 240A bis 240N angeordnet sind. Zwar sind nur die Einzelheiten einer einzigen Mehrkerngruppe 240A angegeben, jedoch versteht es sich, dass die anderen Mehrkerngruppen 240B bis 240N mit den gleichen oder ähnlichen Sätzen aus Grafikverarbeitungsressourcen ausgestattet sein können.
Wie veranschaulicht, kann eine Mehrkerngruppe 240A einen Satz aus Grafikkernen 243, einen Satz aus Tensorkernen 244 und einen Satz aus Strahlverfolgungskernen 245 aufweisen. Ein Planer/Dispatcher 241 plant und verschickt die Grafik-Threads zur Ausführung auf den verschiedenen Kernen 243, 244, 245. Ein Satz Registerdateien 242 speichert während des Ausführens der Grafik-Threads von den Kernen 243, 244, 245 verwendete Operandenwerte. Hierzu können beispielsweise Ganzzahlenregister zum Speichern von Ganzzahlwerten, Gleitkommaregister zum Speichern von Gleitkommawerten, Vektorregister zum Speichern gepackter Datenelemente (Ganzzahl- und/oder Gleitkomma-Datenelemente) und Kachelregister zum Speichern von Tensor-/Matrixwerten zählen. In einer Ausführungsform sind die Kachelregister als kombinierte Sätze aus Vektorregistern implementiert.
Ein oder mehrere kombinierte Level-1-Caches (L1) und gemeinsam genutzte Speichereinheiten 247 speichern Grafikdaten wie Texturdaten, Vertexdaten, Pixeldaten, Strahldaten, Bounding-Volume-Daten usw. lokal innerhalb jeder Mehrkerngruppe 240A. Eine oder mehrere Textureinheiten 247 können zudem verwendet werden, um Texturieroperationen wie beispielsweise Texturabbildung und -abtastung durchzuführen. Ein Level-2- (L2-) Cache 253, der von allen oder einem Teilsatz der Mehrkerngruppen 240A bis 240N verwendet wird, speichert Grafikdaten und/oder Anweisungen für mehrere gleichzeitige Grafik-Threads. Wie veranschaulicht, kann der L2-Cache 253 von einer Vielzahl von Mehrkerngruppen 240A bis 240N gemeinsam verwendet werden. Ein oder mehrere Speichercontroller 248 koppeln die GPU 239 an einen Speicher 249, bei dem es sich um einen Systemspeicher (z.B. DRAM) und/oder einen dedizierten Grafikspeicher (z.B. GDDR6-Speicher) handeln kann.
Eingabe/Ausgabe- (E/A-) Schalttechnik 250 koppelt die GPU 239 an eine oder mehrere E/A-Einrichtungen 252 wie beispielsweise digitale Signalprozessoren (DSPs), Netzwerkcontroller oder Nutzereingabeeinrichtungen. Eine On-Chip-Verbindung kann verwendet werden, um die E/A-Einrichtungen 252 an die GPU 239 und den Speicher 249 zu koppeln. Eine oder mehrere E/A-Speicherverwaltungseinheiten (I/O memory management units, IOMMUs) 251 der E/A-Schalttechnik 250 koppeln die E/A-Einrichtungen 252 direkt an den Systemspeicher 249. In einer Ausführungsform verwaltet die IOMMU 251 mehrere Sätze von Seitentabellen, um virtuelle Adressen auf physische Adressen im Systemspeicher 249 abzubilden. In dieser Ausführungsform können die E/A-Einrichtungen 252, die CPU(s) 246 und die GPU(s) 239 den gleichen virtuellen Adressraum gemeinsam nutzen.
In einer Implementierung unterstützt die IOMMU 251 Virtualisierung. In diesem Fall kann sie einen ersten Satz von Seitentabellen verwalten, um virtuelle Gast-/Grafikadressen auf physische Gast-/Grafikadressen abzubilden, und einen zweiten Satz von Seitentabellen, um die physischen Gast-/Grafikadressen auf physikalische System-/Hostadressen abzubilden (z.B. im Systemspeicher 249). Die Basisadressen des ersten und zweiten Satzes von Seitentabellen können jeweils in Steuerregistern gespeichert und bei einem Kontextwechsel ausgelagert werden (z.B. damit der neue Kontext Zugriff auf den entsprechenden Satz von Seitentabellen erhält). Auch wenn dies in 2C nicht dargestellt ist, kann jeder der Kerne 243, 244, 245 und/oder die Multikerngruppen 240A bis 240N Übersetzungs-Lookaside-Puffer (Translation Lookaside Buffers, TLBs) aufweisen, um virtueller-Gast-zu-physischer-Gast-Übersetzungen, physischer-Gast-zu-physischer-Host-Übersetzungen und virtueller-Gast-zu-physischer-Host-Übersetzungen zu cachen.
In einer Ausführungsform sind die CPUs 246, GPUs 239 und E/A-Einrichtungen 252 auf einem einzigen Halbleiterchip und/oder Chip-Package integriert. Der veranschaulichte Speicher 249 kann auf dem gleichen Chip integriert sein oder kann über eine Off-Chip-Schnittstelle an die Speichercontroller 248 gekoppelt sein. In einer Implementierung umfasst der Speicher 249 GDDR6-Speicher, der sich denselben virtuellen Adressraum wie andere physische Speicher auf Systemebene teilt, obwohl die zugrunde liegenden Prinzipien der Erfindung nicht auf diese konkrete Implementierung eingeschränkt sind.
In einer Ausführungsform weisen die Tensorkerne 244 eine Vielzahl von Ausführungseinheiten auf, die speziell für die Durchführung von Matrixoperationen ausgelegt sind, welche die grundlegende Rechenoperation zur Durchführung von Deep-Learning-Operationen sind. Beispielsweise können gleichzeitige Matrixmultiplikationsoperationen für das Training neuronaler Netze und für Inferenzfindung verwendet werden. Die Tensorkerne 244 können die Matrixverarbeitung unter Verwendung einer Vielzahl von Operandenpräzisionen durchführen, einschließlich Gleitkomma mit einfacher Präzision (z.B. 32 Bit), Gleitkomma mit halber Präzision (z.B. 16 Bit), Ganzzahlwörter (16 Bit), Bytes (8 Bit) und Halbbytes (4 Bit). In einer Ausführungsform extrahiert eine neuronale Netzwerkimplementierung Merkmale jeder gerenderten Szene, wobei möglicherweise Details aus mehreren Frames kombiniert werden, um ein qualitativ hochwertiges Endbild zu konstruieren.
In Deep-Learning-Implementierungen kann parallele Matrixmultiplikationsarbeit für die Ausführung auf den Tensorkernen 244 geplant werden. Insbesondere das Training neuronaler Netze erfordert eine beträchtliche Anzahl an Matrix-Punktproduktoperationen. Um eine Innenprodukt-Formulierung einer N x N x N-Matrixmultiplikation zu verarbeiten, können die Tensorkerne 244 mindestens N Punktprodukt-Verarbeitungselemente aufweisen. Bevor die Matrixmultiplikation beginnt, wird eine vollständige Matrix in Kachelregister geladen und mindestens eine Spalte einer zweiten Matrix jeden Zyklus für N Zyklen geladen. Jeden Zyklus werden N Punktprodukte verarbeitet.
Je nach der jeweiligen Implementierung werden Matrixelemente mit verschiedenen Präzisionen gespeichert, darunter 16-Bit-Wörter, 8-Bit-Bytes (z.B. INT8) und 4-Bit-Halbbytes (z.B. INT4). Für die Tensorkerne 244 können unterschiedliche Präzisionsmodi festgelegt werden, um sicherzustellen, dass für unterschiedliche Arbeitslasten die effizienteste Präzision verwendet wird (wie beispielsweise Inferenzfindungsarbeitslasten, die eine Quantisierung in Bytes und Halbbytes tolerieren können).
In einer Ausführungsform beschleunigen die Strahlverfolgungskerne 245 Strahlverfolgungsoperationen für sowohl Echtzeit-Strahlverfolgungs- als auch Nicht-Echtzeit-Strahlverfolgungsimplementierungen. Insbesondere weisen die Strahlverfolgungskerne 245 Schalttechnik für Strahldurchquerung/-schneidung unter Verwendung von Hüllkörperhierarchien (Bounding Volume Hierarchies, BVHs) und die Identifizierung von Schneidungen zwischen Strahlen und Primitiven auf, die in den BVH-Volumina enthalten sind. Die Strahlverfolgungskerne 245 können zudem Schalttechnik zum Durchführen von Tiefenprüfung und Sortierung (z.B mittels einer Z-Puffer- oder einer ähnlichen Anordnung) aufweisen. In einer Implementierung können die Strahlverfolgungskerne 245 Durchquerungs- und Schneidungsoperationen zusammen mit den vorliegend beschriebenen Bildrauschminderungsmethoden durchführen, von denen zumindest ein Teil auf den Tensorkernen 244 ausgeführt werden kann. Beispielsweise implementieren in einer Ausführungsform die Tensorkerne 244 ein neuronales Deep-Learning-Netz, um Rauschminderung an durch die Strahlverfolgungskerne 245 erzeugten Frames durchzuführen. Jedoch können auch die CPU(s) 246, Grafikkerne 243 und/oder Strahlverfolgungskerne 245 die Rauschminderungs- und/oder Deep-Learning-Algorithmen ganz oder teilweise implementieren.
Zudem kann, wie vorstehend beschrieben, ein verteilter Ansatz für die Rauschminderung eingesetzt werden, bei dem sich die GPU 239 in einer Datenverarbeitungseinrichtung befindet, die über eine Netzwerk- oder Hochgeschwindigkeitsverbindung an andere Datenverarbeitungseinrichtungen gekoppelt ist. In dieser Ausführungsform verwenden die untereinander verbundenen Datenverarbeitungseinrichtungen Lern-/Trainingsdaten des neuronalen Netzes, um die Geschwindigkeit zu verbessern, mit der das Gesamtsystem lernt, Rauschminderung für verschiedene Arten von Bildrahmen und/oder verschiedene Grafikanwendungen durchzuführen.
In einer Ausführungsform verarbeiten die Strahlverfolgungskerne 245 alle BVH-Durchquerungen und Strahl-Primitiv-Schneidungen, so dass die Grafikkerne 243 nicht mit tausenden von Anweisungen pro Strahl überlastet werden. In einer Ausführungsform weist jeder Strahlverfolgungskern 245 einen ersten Satz spezialisierter Schalttechnik zur Durchführung von Hüllquaderprüfungen (Bounding Box Tests) (z.B. für Durchquerungsoperationen) und einen zweiten Satz spezialisierter Schalttechnik zur Durchführung der Strahl-Dreieck-Schneidungsprüfungen (z.B. schneidende Strahlen, die durchquert wurden) auf. In einer Ausführungsform können die Mehrkerngruppen 240A somit einfach eine Strahlsonde aussenden, und die Strahlverfolgungskerne 245 führen unabhängig Strahldurchquerung und -schneidung durch und liefern Trefferdaten (z.B. Treffer, kein Treffer, mehrere Treffer usw.) an den Thread-Kontext zurück. Die anderen Kerne 243, 244 sind frei, um andere Grafik- oder Rechenarbeit durchzuführen, während die Strahlverfolgungskerne 245 die Durchquerungs- und Schneidungsoperationen durchführen.
In einer Ausführungsform weist jeder Strahlverfolgungskern 245 eine Durchquerungseinheit zum Durchführen von BVH-Prüfoperationen und eine Schneidungseinheit auf, die Strahl-Primitiv-Schneidungsprüfungen durchführt. Die Schneidungseinheit erzeugt eine „Treffer“-, „kein Treffer“- oder „mehrere Treffer“-Antwort, die sie dem geeigneten Thread bereitstellt. Während der Durchquerungs- und Schneidungsoperationen sind die Ausführungsressourcen der anderen Kerne (z.B. Grafikkerne 243 und Tensorkerne 244) frei, um andere Formen von Grafikarbeit auszuführen.
In einer bestimmten, nachstehend beschriebenen Ausführungsform wird ein hybrider Rasterung/Strahlverfolgung-Ansatz verwendet, bei dem Arbeit zwischen den Grafikkernen 243 und Strahlverfolgungskernen 245 aufgeteilt wird.
In einer Ausführungsform weisen die Strahlverfolgungskerne 245 (und/oder andere Kerne 243, 244) Hardwareunterstützung für einen StrahlverfolgungsBefehlssatz wie DirectX Ray Tracing (DXR) von Microsoft, der einen DispatchRays-Befehl sowie Strahlerzeugung, Closest-Hit-, Any-Hit- und Miss-Shader enthält, die die Zuweisung eindeutiger Sätze von Shadern und Texturen für jedes Objekt ermöglichen. Eine weitere Strahlverfolgungsplattform, die von den Strahlverfolgungskernen 245, Grafikkernen 243 und Tensorkernen 244 unterstützt werden kann, ist Vulkan 1.1.85. Es ist jedoch zu beachten, dass die zugrunde liegenden Prinzipien der Erfindung auf keine bestimmte Strahlverfolgungs-ISA eingeschränkt sind.
Im Allgemeinen können die verschiedenen Kerne 245, 244, 243 einen Strahlverfolgungsbefehlssatz unterstützen, der Befehle/Funktionen für Strahlerzeugung, Closest Hit, Any Hit, Strahl-Primitiv-Schneidung, pro Primitiv und hierarchisch erfolgende Konstruktion von Hüllquadern, Miss, Visit und Ausnahmen umfasst. Konkret umfasst eine Ausführungsform Strahlverfolgungsanweisungen zum Durchführen der folgenden Funktionen:
Strahlerzeugung - Strahlerzeugungsanweisungen können für jedes Pixel, jede Abtastung oder einen anderen nutzerdefinierten Arbeitsauftrag ausgeführt werden.
Closest Hit - Eine Closest-Hit-Anweisung kann ausgeführt werden, um den nächstliegenden Schnittpunkt eines Strahls mit Primitiven in einer Szene zu lokalisieren.
Any Hit - Eine Any-Hit-Anweisung identifiziert mehrere Schneidungen zwischen einem Strahl und Primitiven in einer Szene, potenziell zur Identifizierung eines neuen nächstliegenden Schnittpunkts.
Intersection - Eine Intersection-Anweisung führt eine Strahl-Primitiv-Schneidungsprüfung durch und gibt ein Ergebnis aus.
Pro Primitiv erfolgende Hüllquaderkonstruktion - Diese Anweisung erstellt einen Hüllquader um ein gegebenes Primitiv oder Gruppe von Primitiven (z.B. beim Erstellen einer neuen BVH- oder anderen Beschleunigungsdatenstruktur).
Miss - Zeigt an, dass ein Strahl die gesamte Geometrie innerhalb einer Szene oder eine festgelegte Region einer Szene verfehlt.
Visit - Zeigt an, welche Nachfolgevolumina ein Strahl durchqueren wird.
Ausnahmen - Umfasst mehrere Typen von Ausnahmebehandlungsroutinen (z.B. für verschiedene Fehlerbedingungen aufgerufen).
2D ist ein Blockschaubild einer Allzweck-Grafikverarbeitungseinheit (General Purpose Graphics Processing Unit, GPGPU) 270, die als Grafikprozessor und/oder Rechenbeschleuniger konfiguriert sein kann, gemäß vorliegend beschriebenen Ausführungsformen. Die GPGPU 270 kann über ein oder mehrere System- und/oder Speicherbusse mit Hostprozessoren (z.B. einer oder mehreren CPU(s) 246) und einem Speicher 271, 272 verbunden sein. In einer Ausführungsform handelt es sich bei dem Speicher 271 um Systemspeicher, der mit der einen oder den mehreren CPU(s) 246 gemeinsam verwendet werden kann, während es sich bei dem Speicher 272 um Einrichtungsspeicher handelt, der speziell für die GPGPU 270 bestimmt ist. In einer Ausführungsform können Komponenten innerhalb der GPGPU 270 und des Einrichtungsspeichers 272 in Speicheradressen abgebildet werden, auf die die eine oder die mehreren CPU(s) 246 zugreifen können. Der Zugriff auf die Speicher 271 und 272 kann über einen Speichercontroller 268 erleichtert werden. In einer Ausführungsform weist der Speichercontroller 268 einen internen Speicherdirektzugriffscontroller 269 (Direct Memory Access, DMA) auf oder kann Logik zur Durchführung von Operationen aufweisen, die sonst von einem DMA-Controller durchgeführt würden.
Die GPGPU 270 weist mehrere Cache-Speicher auf, darunter einen L2-Cache 253, einen L1-Cache 254, einen Anweisungscache 255 und gemeinsamen Speicher 256, von dem zumindest ein Teil ebenfalls als Cachespeicher partitioniert sein kann. Die GPGPU 270 weist zudem mehrere Recheneinheiten 260A bis 260N auf. Jede Recheneinheit 260A bis 260N weist einen Satz aus Vektorregistern 261, Skalarregistern 262, Vektorlogikeinheiten 263 und Skalarlogikeinheiten 264 auf. Die Recheneinheiten 260A bis 260N können zudem lokalen gemeinsamen Speicher 265 und einen Programmzähler 266 aufweisen. Die Recheneinheiten 260A bis 260N können an einen Konstant-Cache 267 gekoppelt sein, der zum Speichern konstanter Daten verwendet werden kann, d.h. von Daten, die sich während der Ausführung des Kernel- oder Shader-Programms, das auf der GPGPU 270 ausgeführt wird, nicht ändern. In einer Ausführungsform ist der Konstant-Cache 267 ein skalarer Datencache, und zwischengespeicherte Daten können direkt in die Skalarregister 262 abgerufen werden.
Während des Betriebs können die eine oder die mehreren CPU(s) 246 Befehle in Register oder Speicher in der GPGPU 270 schreiben, die in einen zugänglichen Adressraum abgebildet wurden. Die Befehlsprozessoren 257 können die Befehle aus Registern oder Speicher lesen und bestimmen, wie diese Befehle in der GPGPU 270 verarbeitet werden. Ein Thread-Dispatcher 258 kann dann verwendet werden, um Threads an die Recheneinheiten 260A bis 260N zu verschicken, um diese Befehle auszuführen. Jede Recheneinheit 260A bis 260N kann Threads unabhängig von den anderen Recheneinheiten ausführen. Zusätzlich kann jede Recheneinheit 260A bis 260N unabhängig für bedingte Berechnungen konfiguriert sein und kann die Ergebnisse der Berechnungen bedingt an den Speicher ausgeben. Die Befehlsprozessoren 257 können die eine oder die mehreren CPU(s) 246 unterbrechen, wenn die gegebenen Befehle abgeschlossen sind.
3A bis 3C veranschaulichen Blockschaubilder weiterer Grafikprozessor- und Rechenbeschleuniger-Architekturen, die durch vorliegend beschriebene Ausführungsformen bereitgestellt werden. Die Elemente der 3A bis 3C, die gleiche Bezugszeichen (oder Namen) wie die Elemente einer anderen Figur aufweisen, können in ähnlicher Weise wie der vorliegend an anderer Stelle beschriebenen arbeiten oder fungieren, sind hierauf jedoch nicht eingeschränkt.
3A ist ein Blockschaubild eines Grafikprozessors 300, bei dem es sich um eine diskrete Grafikverarbeitungseinheit oder um einen Grafikprozessor handeln kann, der mit einer Vielzahl von Verarbeitungskemen oder anderen Halbleitereinrichtungen wie beispielsweise, ohne jedoch hierauf eingeschränkt zu sein, Speichereinrichtungen oder Netzwerkschnittstellen integriert sein kann. In einigen Ausführungsformen kommuniziert der Grafikprozessor über eine speicherabgebildete E/A-Schnittstelle mit Registern auf dem Grafikprozessor und mit Befehlen, die im Prozessorspeicher abgelegt sind. In einigen Ausführungsformen weist der Grafikprozessor 300 eine Speicherschnittstelle 314 auf, um auf Speicher zuzugreifen. Bei der Speicherschnittstelle 314 kann es sich um eine Schnittstelle mit lokalem Speicher, einem oder mehreren internen Caches, einem oder mehreren gemeinsamen externen Caches und/oder mit Systemspeicher handeln.
In einigen Ausführungsformen weist der Grafikprozessor 300 zudem einen Anzeigecontroller 302 auf, um Anzeigeausgabedaten an eine Anzeigeeinrichtung 318 auszugeben. Der Anzeigecontroller 302 weist Hardware für eine oder mehrere Überlagerungsebenen zur Anzeige und Zusammensetzung mehrerer Ebenen von Video- oder Nutzerschnittstellenelementen auf Bei der Anzeigeeinrichtung 318 kann es sich um eine interne oder eine externe Anzeigeeinrichtung handeln. In einer Ausführungsform handelt es sich bei der Anzeigeeinrichtung 318 um eine am Kopf befestigbare Anzeigeeinrichtung wie beispielsweise eine Virtual-Reality- (VR-) Anzeigeeinrichtung oder eine Augmented-Reality- (AR-) Anzeigeeinrichtung. In einigen Ausführungsformen weist der Grafikprozessor 300 eine Videocodec-Engine 306 zum Codieren, Decodieren oder Transcodieren von Medien in, aus oder zwischen einem oder mehreren Mediencodierformaten auf, darunter, ohne jedoch hierauf eingeschränkt zu sein, MPEG-Formate (Moving Picture Experts Group) wie MPEG-2, AVC-Formate (Advanced Video Coding) wie H.264 /MPEG-4 AVC, H.265/HEVC, Alliance for Open Media (AOMedia) VP8, VP9, sowie Society of Motion Picture & Television Engineers (SMPTE) 421M/VC-1 und JPEG-Formate (Joint Photographic Experts Group) wie JPEG und Motion-JPEG- (MJPEG-) Formate.
In einigen Ausführungsformen weist der Grafikprozessor 300 eine Block-Image-Transfer- (BLIT-) Engine 304 auf, um zweidimensionale (2D-) Rasteroperationen durchzuführen, darunter beispielsweise Bit-Boundary Block Transfers. In einer Ausführungsform werden jedoch 2D-Grafikoperationen mittels einer oder mehrerer Komponenten der Grafikverarbeitungs-Engine (GPE) 310 durchgeführt. In einigen Ausführungsformen ist die GPE 310 eine Rechen-Engine zum Durchführen von Grafikoperationen, darunter dreidimensionale (3D-) Grafikoperationen und Medienoperationen.
In einigen Ausführungsformen weist die GPE 310 eine 3D-Pipeline 312 zur Durchführung von 3D-Operationen, wie beispielsweise Rendem dreidimensionaler Bilder und Szenen unter Verwendung von Verarbeitungsfunktionen, die auf 3D-Primitivformen (z.B. Rechteck, Dreieck usw.) wirken. Die 3D-Pipeline 312 weist programmierbare und Festfunktionselemente auf, die verschiedene Aufgaben innerhalb des Elements ausführen und/oder Ausführungs-Threads an ein 3D/Media-Teilsystem 315 weiterleiten. Während die 3D-Pipeline 312 zur Durchführung von Medienoperationen verwendet werden kann, weist eine Ausführungsform von GPE 310 auch eine Medienpipeline 316 auf, die speziell zur Durchführung von Medienoperationen wie beispielsweise Videonachbearbeitung und Bildverbesserung verwendet wird.
In einigen Ausführungsformen weist die Medienpipeline 316 Festfunktions- oder programmierbare Logikeinheiten auf, um anstelle oder im Auftrag der Videocodec-Engine 306 eine oder mehrere spezialisierte Medienoperationen wie beispielsweise Videodecodierbeschleunigung, Video-De-Interlacing und Videocodierbeschleunigung durchzuführen. In einigen Ausführungsformen weist die Medienpipeline 316 zusätzlich eine Thread-Spawning-Einheit zum Erzeugen von Threads zur Ausführung auf dem 3D/Medienteilsystem 315 auf Die erzeugten Threads führen Berechnungen für die Medienoperationen auf einer oder mehreren in dem 3D/Medienteilsystem 315 umfassten Grafikausfiihrungseinheiten durch.
In einigen Ausführungsformen weist das 3D/Medienteilsystem 315 Logik zum Ausführen von durch die 3D-Pipeline 312 und die Medienpipeline 316 erzeugten Threads auf. In einer Ausführungsform senden die Pipelines Thread-Ausführungsanfragen an das 3D/Medienteilsystem 315, das eine Thread-Dispatch-Logik für die Vermittlung und Verteilung der verschiedenen Anfragen an verfügbare Thread-Ausführungsressourcen aufweist. Die Ausführungsressourcen umfassen ein Array aus Grafikausfiihrungseinheiten zur Verarbeitung der 3D- und Medien-Threads. In einigen Ausführungsformen weist das 3D/Medienteilsystem 315 einen oder mehrere interne Caches für Thread-Anweisungen und -Daten auf. In einigen Ausführungsformen weist das Teilsystem zudem gemeinsamen Speicher auf, darunter Register und adressierbaren Speicher, um Daten zwischen Threads zu teilen und Ausgabedaten zu speichern.
3B veranschaulicht einen Grafikprozessor 320 mit einer gekachelten Architektur gemäß vorliegend beschriebenen Ausführungsformen. In einer Ausführungsform umfasst der Grafikprozessor 320 einen Grafikverarbeitungs-Engine-Cluster 322 mit mehreren Instanzen der Grafikverarbeitungs-Engine 310 aus 3A innerhalb einer Grafik-Engine-Kachel 310A bis 310D. Die Grafik-Engine-Kacheln 310A bis 310D können über einen Satz von Kachelverbindungen 323A bis 323F jeweils untereinander verbunden sein. Die Grafik-Engine-Kacheln 310A bis 310D können zudem über Speicherverbindungen 325A bis 325D jeweils mit einem Speichermodul oder einer Speichereinrichtung 326A bis 326D verbunden sein. Die Speichereinrichtungen 326A bis 326D können eine beliebige Grafikspeichertechnologie verwenden. Beispielsweise kann es sich bei den Speichereinrichtungen 326A bis 326D um GDDR- (Graphics Double Data Rate) Speicher handeln. Bei den Speicherbausteinen 326A bis 326D handelt es sich in einer Ausführungsform um HBM-Module (High-Bandwidth Memory), die sich mit ihrer jeweiligen Grafik-Engine-Kachel 310A bis 310D On-Die befinden können. In einer Ausführungsform handelt es sich bei den Speichereinrichtungen 326A bis 326D um gestapelte Speichereinrichtungen, die auf ihre jeweilige Grafik-Engine-Kachel 310A bis 310D gestapelt sein können. In einer Ausführungsform befinden sich jede Grafik-Engine-Kachel 310A bis 310D und der zugehörige Speicher 326A bis 326D auf separaten Chiplets, die mit einem Basis-Die oder Basissubstrat verbunden sind, wie in 11B bis 11D näher beschrieben.
Der Grafikverarbeitungs-Engine-Cluster 322 kann mit einer On-Chip- oder On-Package-Fabric-Verbindung 324 verbunden sein. Die Fabric-Verbindung 324 kann Kommunikation zwischen Grafik-Engine-Kacheln 310A bis 310D und Komponenten wie beispielsweise der Videocodec- 306 und einer oder mehreren Kopier-Engines 304 ermöglichen. Die Kopier-Engines 304 können verwendet werden, um Daten aus, in und zwischen den Speichereinrichtungen 326A bis 326D und dem Speicher, der sich außerhalb des Grafikprozessors 320 befindet (z.B. Systemspeicher), zu verschieben. Die Fabric-Verbindung 324 kann zudem verwendet werden, um die Grafik-Engine-Kacheln 310A bis 310D untereinander zu verbinden. Der Grafikprozessor 320 kann wahlweise einen Anzeigecontroller 302 aufweisen, um eine Verbindung mit einer externen Anzeigeeinrichtung 318 zu ermöglichen. Der Grafikprozessor kann zudem als Grafik- oder Rechenbeschleuniger konfiguriert sein. In der Beschleuniger-Konfiguration können der Anzeigecontroller 302 und die Anzeigeeinrichtung 318 wegfallen.
Der Grafikprozessor 320 kann über eine Hostschnittstelle 328 mit einem Hostsystem verbunden sein. Die Hostschnittstelle 328 kann Kommunikation zwischen dem Grafikprozessor 320, dem Systemspeicher und/oder anderen Systemkomponenten ermöglichen. Bei der Hostschnittstelle 328 kann es sich beispielsweise um einen PCIexpress-Bus oder eine andere Art von Hostsystem-Schnittstelle handeln.
3C veranschaulicht einen Rechenbeschleuniger 330 gemäß vorliegend beschriebenen Ausführungsformen. Der Rechenbeschleuniger 330 kann architektonische Ähnlichkeiten mit dem Grafikprozessor 320 aus 3B aufweisen und ist für Rechenbeschleunigung optimiert. Ein Rechen-Engine-Cluster 332 kann einen Satz Rechen-Engine-Kacheln 340A bis 340D aufweisen, die Ausführungslogik aufweisen, die für parallele oder vektorbasierte Allzweck-Rechenoperationen optimiert ist. In einigen Ausführungsformen weisen die Rechen-Engine-Kacheln 340A bis 340D keine Festfunktions-Grafikverarbeitungslogik auf, obwohl in einer Ausführungsform eine oder mehrere der Rechen-Engine-Kacheln 340A bis 340D Logik zum Durchführen von Medienbeschleunigung aufweisen können. Die Rechen-Engine-Kacheln 340A bis 340D können über Speicherverbindungen 325A bis 325D mit dem Speicher 326A bis 326D verbunden sein. Beim Speicher 326A bis 326D und der Speicherverbindungen 325A bis 325D kann es sich um ähnliche Technologie wie im Grafikprozessor 320 oder um andere Technologie handeln. Die Grafik-Rechen-Engine-Kacheln 340A bis 340D können zudem über einen Satz Kachelverbindungen 323A bis 323F untereinander verbunden sein und können mit einer Fabric-Verbindung 324 verbunden oder durch diese untereinander verbunden sein. In einer Ausführungsform weist der Rechenbeschleuniger 330 einen großen L3-Cache 336 auf, der als einrichtungsweiter Cache konfiguriert sein kann. Der Rechenbeschleuniger 330 kann zudem in ähnlicher Weise wie der Grafikprozessor 320 aus 3B über eine Hostschnittstelle 328 mit einem Hostprozessor und Speicher verbunden sein.
Grafikverarbeitungs-Engine
4 ist ein Blockschaubild einer Grafikverarbeitungs-Engine 410 eines Grafikprozessors gemäß einigen Ausführungsformen. In einer Ausführungsform ist die Grafikverarbeitungs-Engine (GPE) 410 eine Version der in 3A gezeigten GPE 310 und kann zudem eine Grafik-Engine-Kachel 310A bis 310D aus 3B repräsentieren. Elemente aus 4, die gleiche Bezugszeichen (oder Namen) wie die Elemente einer anderen Figur aufweisen, können in ähnlicher Weise wie der vorliegend an anderer Stelle beschriebenen arbeiten oder fungieren, sind hierauf jedoch nicht eingeschränkt. Beispielsweise sind die 3D-Pipeline 312 und die Medienpipeline 316 aus 3A veranschaulicht. Die Medienpipeline 316 ist in einigen Ausführungsformen der GPE 410 optional und ist gegebenenfalls nicht explizit in der GPE 410 enthalten. Beispielsweise und in mindestens einer Ausführungsform ist ein separater Medien- und/oder Bildprozessor an die GPE 410 gekoppelt.
In einigen Ausführungsformen ist die GPE 410 mit einem Befehlsstreamer 403 gekoppelt oder weist diesen auf, der der 3D-Pipeline 312 und/oder den Medienpipelines 316 einen Befehlsstrom bereitstellt. In einigen Ausführungsformen ist der Befehlsstreamer 403 mit Speicher gekoppelt, bei dem es sich um Systemspeicher oder um internen Cachespeicher und/oder gemeinsamen Cachespeicher handeln kann. In einigen Ausführungsformen empfängt der Befehlsstreamer 403 Befehle vom Speicher und sendet die Befehle an die 3D-Pipeline 312 und/oder die Medienpipeline 316. Bei den Befehlen handelt es sich um Direktiven, die aus einem Ringpuffer abgerufen werden, der Befehle für die 3D-Pipeline 312 und die Medienpipeline 316 speichert. In einer Ausführungsform kann der Ringpuffer zusätzlich Batch-Befehlspuffer aufweisen, die Batches aus mehreren Befehlen speichern. Die Befehle für die 3D-Pipeline 312 können auch Verweise auf Daten enthalten, die im Speicher gespeichert sind, beispielsweise, ohne jedoch hierauf eingeschränkt zu sein, Vertex- und Geometriedaten für die 3D-Pipeline 312 und/oder Bilddaten und Speicherobjekte für die Medienpipeline 316. Die 3D-Pipeline 312 und die Medienpipeline 316 verarbeiten die Befehle und Daten, indem sie Operationen über Logik innerhalb der jeweiligen Pipelines durchführen oder einen oder mehrere Ausführungs-Threads an ein Grafikkern-Array 414 verschicken. In einer Ausführungsform weist das Grafikkern-Array 414 einen oder mehrere Blöcke aus Grafikkernen (z.B. Grafikkern(e) 415A, Grafikkern(e) 415B) auf, wobei jeder Block einen oder mehrere Grafikkerne aufweist. Jeder Grafikkern weist einen Satz aus Grafikausführungsressourcen auf, der Allzweck- und grafikspezifische Ausführungslogik zum Durchführen von Grafik- und Rechenoperationen sowie Festfunktions-Texturverarbeitungs- und/oder Maschinenlern- und KI-Beschleunigungslogik aufweist.
In verschiedenen Ausführungsformen kann die 3D-Pipeline 312 Festfunktions- und programmierbare Logik enthalten, um ein oder mehrere Schattierprogramme wie beispielsweise Vertex-Shader, Geometrie-Shader, Pixel-Shader, Fragment-Shader, Rechen-Shader oder andere Schattierprogramme zu verarbeiten, indem die Anweisungen verarbeitet und Ausführungs-Threads an das Grafikkern-Array 414 verschickt werden. Das Grafikkern-Array 414 stellt einen vereinheitlichten Block aus Ausführungsressourcen zur Verwendung bei der Verarbeitung dieser Schattierprogramme bereit. Mehrzweck-Ausführungslogik (z.B. Ausführungseinheiten) innerhalb des oder der Grafikkerne 415A bis 414B des Grafikkern-Arrays 414 umfasst Unterstützung für verschiedene 3D-API-Shader-Sprachen und kann mehrere gleichzeitige Ausführungs-Threads ausführen, die mit mehreren Shadem verbunden sind.
In einigen Ausführungsformen weist das Grafikkern-Array 414 Ausführungslogik zum Durchführen von Medienfunktionen wie beispielsweise Video- und/oder Bildverarbeitung auf. In einer Ausführungsform enthalten die Ausführungseinheiten Allzwecklogik, die so programmiert werden kann, dass sie zusätzlich zu den Grafikverarbeitungsoperationen parallele Allzweck-Rechenoperationen durchführt. Die Allzwecklogik kann Verarbeitungsoperationen parallel zu oder zusammen mit Allzwecklogik in dem oder den Prozessorkernen 107 aus 1 oder dem Kern 202A bis 202N aus 2A durchführen.
Ausgabedaten, die von Threads erzeugt werden, die auf dem Grafikkern-Array 414 ausgeführt werden, können in einem vereinheitlichten Rückgabepuffer (Unified Return Buffer, URB) 418 an den Speicher ausgegeben werden. Der URB 418 kann Daten für mehrere Threads speichern. In einigen Ausführungsformen kann der URB 418 verwendet werden, um Daten zwischen verschiedenen auf dem Grafikkern-Array 414 ausgeführten Threads zu senden. In einigen Ausführungsformen kann der URB 418 zusätzlich für Synchronisierung zwischen Threads auf dem Grafikkern-Array und Festfunktionslogik innerhalb der gemeinsamen Funktionslogik 420 verwendet werden.
In einigen Ausführungsformen ist das Grafikkern-Array 414 skalierbar, derart, dass das Array eine variable Anzahl an Grafikkernen aufweist, die jeweils über eine variable Anzahl an Ausführungseinheiten verfügen, basierend auf der Zielleistung und dem Leistungsniveau der GPE 410. In einer Ausführungsform sind die Ausführungsressourcen dynamisch skalierbar, derart, dass die Ausführungsressourcen nach Bedarf aktiviert und deaktiviert werden können.
Das Grafikkern-Array 414 ist mit gemeinsamer Funktionslogik 420 gekoppelt, die mehrere Ressourcen aufweist, die von den Grafikkernen im Grafikkern-Array gemeinsam verwendet werden. Bei den gemeinsam verwendeten Funktionen innerhalb der gemeinsamen Funktionslogik 420 handelt es sich um Hardware-Logikeinheiten, die dem Grafikkern-Array 414 spezialisierte ergänzende Funktionalität bereitstellen. In verschiedenen Ausführungsformen umfasst die gemeinsame Funktionslogik 420, ohne jedoch hierauf eingeschränkt zu sein, Sampler- 421, Mathe-422 und Inter-Thread-Kommunikations- (ITC-) 423 Logik. Zusätzlich implementieren einige Ausführungsformen einen oder mehrere Caches 425 innerhalb der gemeinsamen Funktionslogik 420.
Eine gemeinsam verwendete Funktion wird zumindest in dem Fall implementiert, in dem die Nachfrage nach einer bestimmten spezialisierten Funktion nicht ausreicht, um sie in das Grafikkern-Array 414 aufzunehmen. Stattdessen wird eine einzelne Instantiierung dieser spezialisierten Funktion als eigenständige Einheit in der gemeinsamen Funktionslogik 420 implementiert und von den Ausführungsressourcen innerhalb des Grafikkern-Arrays 414 gemeinsam verwendet. Der genaue Satz aus Funktionen, die innerhalb des Grafikkern-Arrays 414 gemeinsam verwendet werden und in dem Grafikkern-Array 414 umfasst sind, variiert je nach Ausführungsform. In einigen Ausführungsformen können bestimmte gemeinsam verwendete Funktionen innerhalb der gemeinsamen Funktionslogik 420, die von dem Grafikkern-Array 414 intensiv genutzt werden, in der gemeinsamen Funktionslogik 416 innerhalb des Grafikkern-Arrays 414 umfasst sein. In verschiedenen Ausführungsformen kann die gemeinsame Funktionslogik 416 innerhalb des Grafikkern-Arrays 414 einen Teil der oder die gesamte Logik innerhalb der gemeinsamen Funktionslogik 420 umfassen. In einer Ausführungsform können alle in der gemeinsamen Funktionslogik 420 befindlichen Elemente innerhalb der gemeinsamen Funktionslogik 416 des Grafikkern-Arrays 414 dupliziert werden. In einer Ausführungsform wird die gemeinsame Funktionslogik 420 zugunsten der gemeinsamen Funktionslogik 416 innerhalb des Grafikkern-Arrays 414 ausgeschlossen.
Ausführungseinheiten
5A bis 5B veranschaulichen Thread-Ausführungslogik 500 einschließlich eines Arrays in einem Grafikprozessorkern eingesetzter Verarbeitungselemente gemäß vorliegend beschriebenen Ausführungsformen. Elemente der 5A bis 5B, die gleiche Bezugszeichen (oder Namen) wie die Elemente einer anderen Figur aufweisen, können in ähnlicher Weise wie der vorliegend an anderer Stelle beschriebenen arbeiten oder fungieren, sind hierauf jedoch nicht eingeschränkt. Die 5A bis 5B veranschaulichen eine Übersicht einer Thread-Ausführungslogik 500, die repräsentativ für mit jedem Teilkern 221A bis 221F der 2B veranschaulichte Hardware-Logik sein kann. 5A repräsentiert eine Ausführungseinheit innerhalb eines Allzweck-Grafikprozessors, während 5B eine Ausführungseinheit repräsentiert, die innerhalb eines Rechenbeschleunigers verwendet werden kann.
Wie in 5A veranschaulicht ist, weist in einigen Ausführungsformen die Thread-Ausführungslogik 500 einen Schattierprozessor 502, einen Thread-Dispatcher 504, Anweisungscache 506, ein skalierbares Ausführungseinheiten-Array mit einer Vielzahl von Ausführungseinheiten 508A bis 508N, einen Sampler 510, einen gemeinsamen lokalen Speicher 511, einen Datencache 512 und einen Datenport 514 auf. In einer Ausführungsform kann das skalierbare Ausführungseinheiten-Array auf Grundlage der Rechenanforderungen einer Arbeitslast durch Aktivieren oder Deaktivieren einer oder mehrerer Ausführungseinheiten (z.B. beliebiger der Ausführungseinheiten 508A, 508B, 508C, 508D bis 508N-1 und 508N) dynamisch skalieren. In einer Ausführungsform sind die umfassten Komponenten über ein Verbindungs-Fabric, die mit jeder der Komponenten verbunden ist, untereinander verbunden. In einigen Ausführungsformen weist die Thread-Ausführungslogik 500 eine oder mehrere Verbindungen mit Speicher, beispielsweise dem Systemspeicher oder Cachespeicher, durch einen Anweisungscache 506, einen Datenport 514, einen Sampler 510 und/oder Ausführungseinheiten 508A bis 508N auf. In einigen Ausführungsformen handelt es sich bei jeder Ausführungseinheit (z.B. 508A) um eine eigenständige programmierbare Allzweck-Recheneinheit, die in der Lage ist, mehrere gleichzeitige Hardware-Threads auszuführen und dabei mehrere Datenelemente parallel für jeden Thread zu verarbeiten. In verschiedenen Ausführungsformen ist das Array aus Ausführungseinheiten 508A bis 508N so skalierbar, dass es eine beliebige Anzahl individueller Ausführungseinheiten aufweist.
In einigen Ausführungsformen werden die Ausführungseinheiten 508A bis 508N primär verwendet, um Schattierprogramme auszuführen. Ein Schattierprozessor 502 kann die verschiedenen Schattierprogramme verarbeiten und den Schattierprogrammen zugehörige Ausführungs-Threads über einen Thread-Dispatcher 504 verschicken. In einer Ausführungsform weist der Thread-Dispatcher Logik auf, um Thread-Initiierungsanfragen von den Grafik- und Medienpipelines zu vermitteln und die angefragten Threads auf einer oder mehreren Ausführungseinheiten in den Ausführungseinheiten 508A bis 508N zu instantiieren. Beispielsweise kann eine Geometriepipeline Vertex-, Tesselations- oder Geometrie-Shader an die Thread-Ausführungslogik zur Verarbeitung verschicken. In einigen Ausführungsformen kann der Thread-Dispatcher 504 zudem zur Laufzeit von den ausgeführten Schattierprogrammen erfolgende Thread-Erzeugungsanfragen verarbeiten.
In einigen Ausführungsformen unterstützen die Ausführungseinheiten 508A bis 508N einen Befehlssatz, der native Unterstützung für viele standardmäßige 3D-Grafik-Schattieranweisungen umfasst, derart, dass Schattierprogramme aus Grafikbibliotheken (z.B. Direct 3D und OpenGL) mit minimaler Übersetzung ausgeführt werden. Die Ausführungseinheiten unterstützen Vertex- und Geometrieverarbeitung (z.B. Vertexprogramme, Geometrieprogramme, Vertex-Shader), Pixelverarbeitung (z.B. Pixel-Shader, Fragment-Shader) und Allzweckverarbeitung (z.B. Rechen- und Medien-Shader). Jede der Ausführungseinheiten 508A bis 508N ist in der Lage, Mehrfachausgabe-SIMD (Single Instruction Multiple Data) auszuführen, und der Multi-Thread-Betrieb ermöglicht eine effiziente Ausführungsumgebung angesichts von Speicherzugriffen mit höherer Latenz. Jeder Hardware-Thread innerhalb jeder Ausführungseinheit hat eine dedizierte Registerdatei mit hoher Bandbreite und einen zugehörigen unabhängigen Thread-Status. Die Ausführung erfolgt in Mehrfachausgabe pro Takt an Pipelines, die Ganzzahl-, einfach und doppelt präzise Gleitkommaoperationen, SIMD-Verzweigung, logische Operationen, transzendente Operationen und verschiedene andere Operationen ausführen können. Während des Wartens auf Daten aus dem Speicher oder einer der gemeinsam genutzten Funktionen veranlasst Abhängigkeitslogik innerhalb der Ausführungseinheiten 508A bis 508N einen wartenden Thread zum Schlafen, bis die angefragten Daten zurückgegeben wurden. Während der wartende Thread schläft, können sich Hardware-Ressourcen der Verarbeitung anderer Threads widmen. Beispielsweise kann während einer Verzögerung in Zusammenhang mit einer Operation eines Vertex-Shaders eine Ausführungseinheit Operationen für einen Pixel-Shader, Fragment-Shader oder eine andere Art von Schattierprogramm einschließlich eines anderen Vertex-Shaders ausführen. Verschiedene Ausführungsformen können die Ausführung unter Verwendung von SIMT (Single Instruction Multiple Thread) als Alternative zur Verwendung von SIMD oder zusätzlich zur Verwendung von SIMD betreffen. Bezugnahmen auf einen SIMD-Kern oder -Betrieb können ebenso SIMT oder SIMD in Kombination mit SIMT betreffen.
Jede Ausführungseinheit der Ausführungseinheiten 508A bis 508N arbeitet mit Anordnungen aus Datenelementen. Die Anzahl an Datenelementen ist die „Ausführungsgröße“ oder die Anzahl an Kanälen für die Anweisung. Ein Ausführungskanal ist eine logische Ausführungseinheit für Datenelementzugriff, Maskierung und Flusskontrolle innerhalb von Anweisungen. Die Anzahl an Kanälen kann unabhängig von der Anzahl physischer arithmetisch-logischer Einheiten (Arithmetic Logic Units, ALUs) oder Gleitkommaeinheiten (Floating Point Units, FPUs) für einen bestimmten Grafikprozessor sein. In einigen Ausführungsformen unterstützen die Ausführungseinheiten 508A bis 508N Ganzzahl- und Gleitkomma-Datentypen.
Der Befehlssatz für die Ausführungseinheiten umfasst SIMD-Anweisungen. Die verschiedenen Datenelemente können als gepackter Datentyp in einem Register gespeichert werden, und die Ausführungseinheit wird die verschiedenen Elemente auf Grundlage der Datengröße der Elemente verarbeiten. Wenn beispielsweise ein 256 Bit breiter Vektor bearbeitet wird, werden die 256 Bits des Vektors in einem Register gespeichert, und die Ausführungseinheit bearbeitet den Vektor als vier separate gepackte 54-Bit-Datenelemente (Datenelemente der Größe Quad-Word (QW)), acht separate gepackte 32-Bit-Datenelemente (Datenelemente der Größe Double Word (DW)), sechzehn separate gepackte 16-Bit-Datenelemente (Datenelemente der Größe Word (W)) oder zweiunddreißig separate 8-Bit-Datenelemente (Datenelemente der Größe Byte (B)). Es sind jedoch auch andere Vektorbreiten und Registergrößen möglich.
In einer Ausführungsform können eine oder mehrere Ausführungseinheiten zu einer verschmolzenen Ausführungseinheit 509A bis 509N mit Thread-Steuerlogik (507A bis 507N) kombiniert werden, die den verschmolzenen EUs gemeinsam ist. Mehrere EUs können zu einer EU-Gruppe verschmolzen werden. Jede EU in der verschmolzenen EU-Gruppe kann dafür konfiguriert sein, einen separaten SIMD-Hardware-Thread auszuführen. Die Anzahl an EUs in einer verschmolzenen EU-Gruppe kann gemäß Ausführungsformen variieren. Zusätzlich können pro EU verschiedene SIMD-Breiten durchgeführt werden, darunter, ohne jedoch hierauf eingeschränkt zu sein, SIMD8, SIMD16 und SIMD32. Jede verschmolzene Grafikausführungseinheit 509A bis 509N weist mindestens zwei Ausführungseinheiten auf. Beispielsweise weist die verschmolzene Ausführungseinheit 509A eine erste EU 508A, eine zweite EU 508B und Thread-Steuerlogik 507A auf, die der ersten EU 508A und der zweiten EU 508B gemeinsam ist. Die Thread-Steuerlogik 507A steuert auf der verschmolzenen Grafikausführungseinheit 509A ausgeführte Threads, wodurch jede EU innerhalb der verschmolzenen Ausführungseinheiten 509A bis 509N mittels eines gemeinsamen Befehlszeigerregisters ausgeführt werden kann.
In der Thread-Ausführungslogik 500 sind ein oder mehrere interne Anweisungscaches (z.B. 506) umfasst, um Thread-Anweisungen für die Ausführungseinheiten zwischenzuspeichern. In einigen Ausführungsformen sind ein oder mehrere Datencaches (z.B. 512) umfasst, um Thread-Daten während der Thread-Ausführung zwischenzuspeichern. Auf der Ausführungslogik 500 ausgeführte Threads können zudem explizit verwaltete Daten im gemeinsamen lokalen Speicher 511 speichern. In einigen Ausführungsformen ist ein Sampler 510 umfasst, um Textursampling (-abtastung) für 3D-Operationen und Mediensampling (-abtastung) für Medienoperationen bereitzustellen. In einigen Ausführungsformen weist der Sampler 510 spezialisierte Textur- oder Mediensampling-Funktionalität auf, um Textur- oder Mediendaten während des Samplingprozesses zu verarbeiten, bevor die gesampelten Daten einer Ausführungseinheit bereitgestellt werden.
Während der Ausführung senden die Grafik- und Medienpipelines über Thread-Erzeugungs- und -Dispatch-Logik Thread-Initiierungsanfragen an die Thread-Ausführungslogik 500. Sobald eine Gruppe geometrischer Objekte verarbeitet und in Pixeldaten gerastert wurde, wird Pixelprozessorlogik (z.B. Pixel-Shader-Logik, Fragment-Shader-Logik usw.) innerhalb des Schattierprozessors 502 aufgerufen, um Ausgabeinformationen weiter zu berechnen und zu veranlassen, dass Ergebnisse in Ausgabeflä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 interpoliert werden sollen. In einigen Ausführungsformen führt anschließend Pixelprozessorlogik innerhalb des Schattierprozessors 502 ein durch eine Anwendungsprogrammierschnittstelle (Application Programming Interface, API) bereitgestelltes Pixel- oder Fragment-Schattierprogramm aus. Zur Ausführung des Schattierprogramms verschickt der Schattierprozessor 502 über einen Thread-Dispatcher 504 Threads an eine Ausführungseinheit (z.B. 508A). In einigen Ausführungsformen verwendet der Schattierprozessor 502 Textursamplinglogik im Sampler 510, um auf Texturdaten in Texturkarten zuzugreifen, die im Speicher gespeichert sind. Arithmetische Operationen an den Texturdaten und den Eingangsgeometriedaten berechnen Pixelfarbdaten für jedes geometrische Fragment oder verwerfen ein oder mehrere Pixel von der weiteren Verarbeitung.
In einigen Ausführungsformen stellt der Datenport 514 einen Speicherzugriffsmechanismus bereit, damit die Thread-Ausführungslogik 500 verarbeitete Daten zur weiteren Verarbeitung auf einer Grafikprozessor-Ausgabepipeline an den Speicher ausgeben kann. In einigen Ausführungsformen weist der Datenport 514 einen oder mehrere Cachespeicher (z.B. den Datencache 512) auf oder ist mit diesen gekoppelt, um Daten für Speicherzugriff über den Datenport zwischenzuspeichern.
In einer Ausführungsform kann die Ausführungslogik 500 zudem einen Strahlverfolger 505 aufweisen, der Beschleunigungsfunktionalität für Strahlverfolgung bereitstellen kann. Der Strahlverfolger 505 kann einen Strahlverfolgungsbefehlssatz unterstützen, der Anweisungen/Funktionen für Strahlerzeugung umfasst. Der Strahlverfolgungsbefehlssatz kann dem von den Strahlverfolgungskernen 245 in
2C unterstützten Strahlverfolgungsbefehlssatz ähneln oder sich von diesem unterscheiden.
5B veranschaulicht beispielhafte interne Einzelheiten einer Ausführungseinheit 508 gemäß Ausführungsformen. Eine Grafikausführungseinheit 508 kann eine Anweisungsabrufeinheit 537, ein Allgemeinregisterdatei-Array (General Register File, GRF) 524, ein Architekturregisterdatei-Array (Architectural Register File Array, ARF) 526, einen Thread-Vermittler 522, eine Sendeeinheit 530, eine Verzweigungseinheit 532, einen Satz SIMD-Gleitkommaeinheiten (FPUs) 534 und in einer Ausführungsform einen Satz dedizierter Ganzzahl-SIMD-ALUs 535 aufweisen. Das GRF 524 und das ARF 526 weisen den Satz aus Allgemeinregisterdateien und Architekturregisterdateien auf, der zu jedem simultanen Hardware-Thread gehört, der in der Grafikausführungseinheit 508 aktiv sein kann. In einer Ausführungsform wird ein Architekturstatus pro Thread im ARF 526 behalten, während im GRF 524 während der Thread-Ausführung verwendete Daten gespeichert werden. Der Ausführungsstatus jedes Threads, einschließlich der Anweisungszeiger für jeden Thread, kann in Threadspezifischen Registern im ARF 526 gehalten werden.
In einer Ausführungsform verfügt die Grafikausführungseinheit 508 über eine Architektur, bei der es sich um eine Kombination aus gleichzeitigem Multi-Threading (Simultaneous Multi-Threading, SMT) und feinkörnigem verschachteltem Multi-Threading (fine-grained Interleaved Multi-Threading, IMT) handelt. Die Architektur verfügt über eine modulare Konfiguration, die zur Entwurfszeit auf Grundlage einer Zielanzahl gleichzeitiger Threads und einer Anzahl an Registern pro Ausführungseinheit feinabgestimmt werden kann, wobei Ressourcen der Ausführungseinheit auf zum Ausführen mehrerer gleichzeitiger Threads verwendete Logik aufgeteilt werden. Die Anzahl logischer Threads, die von der Grafikausführungseinheit 508 ausgeführt werden können, ist nicht auf die Anzahl an Hardware-Threads begrenzt, und jedem Hardware-Thread können mehrere logische Threads zugewiesen werden.
In einer Ausführungsform kann die Grafikausführungseinheit 508 mehrere Anweisungen zusammen ausgeben, bei denen es sich um verschiedene Anweisungen handeln kann. Der Thread-Vermittler 522 der Grafikausführungseinheit 508 kann die Anweisungen zur Ausführung an entweder die Sendeeinheit 530, die Verzweigungseinheit 532 oder die SIMD-FPU(s) 534 verschicken. Jeder Ausführungs-Thread kann auf 128 Allzweckregister innerhalb des GRF 524 zugreifen, wobei jedes Register 32 Bytes speichern kann, die als SIMD-8-Element-Vektor aus 32-Bit-Datenelementen verfügbar sind. In einer Ausführungsform hat jeder Thread der Ausführungseinheit Zugriff auf 4 Kbytes innerhalb des GRF 524, wobei Ausführungsformen hierauf jedoch nicht eingeschränkt sind und in anderen Ausführungsformen mehr oder weniger Registerressourcen bereitgestellt sein können. In einer Ausführungsform ist die Grafikausführungseinheit 508 in sieben Hardware-Threads partitioniert, die unabhängig Rechenoperationen durchführen können, wobei jedoch die Anzahl an Threads pro Ausführungseinheit ebenfalls je nach Ausführungsform variieren kann. Beispielsweise werden in einer Ausführungsform bis zu 16 Hardware-Threads unterstützt. In einer Ausführungsform, in der sieben Threads auf 4 Kbytes zugreifen können, kann das GRF 524 insgesamt 28 Kbytes speichern. Wenn 16 Threads auf 4 Kbytes zugreifen können, kann das GRF 524 insgesamt 64 Kbytes speichern. Flexible Adressierungsmodi können es erlauben, Register gemeinsam zu adressieren, um effektiv breitere Register zu bilden oder um abgemessene rechteckige Blockdatenstrukturen darzustellen.
In einer Ausführungsform werden Speicheroperationen, Sampleroperationen und andere Systemkommunikationen mit längerer Latenzzeit über „Sende“-Anweisungen verschickt, die von der Nachrichten weiterleitenden Sendeeinheit 530 ausgeführt werden. In einer Ausführungsform werden Verzweigungsanweisungen an eine dedizierte Verzweigungseinheit 532 verschickt, um SIMD-Divergenz und schließlich Konvergenz zu erleichtern.
In einer Ausführungsform weist die Grafikausführungseinheit 508 eine oder mehrere SIMD-Gleitkommaeinheiten (FPU(s)) 534 auf, um Gleitkommaoperationen durchzuführen. In einer Ausführungsform unterstützen die eine oder die mehreren FPUs 534 zudem Ganzzahlberechnung. In einer Ausführungsform können die eine oder die mehreren FPUs 534 eine Anzahl von bis zu M 32-Bit-Gleitkomma- (oder Ganzzahl-) Operationen SIMD-ausführen oder bis zu 2M 16-Bit-Ganzzahl- oder 16-Bit-Gleitkommaoperationen SIMD-ausführen. In einer Ausführungsform bietet mindestens eine der FPU(s) erweiterte mathematische Fähigkeiten, um transzendente mathematische Funktionen mit hohem Durchsatz und 54-Bit-Gleitkomma mit doppelter Präzision zu unterstützen. In einigen Ausführungsformen ist zudem ein Satz aus 8-Bit-Ganzzahl-SIMD-ALUs 535 vorhanden, der speziell zur Durchführung von Operationen in Zusammenhang mit Maschinenlernberechnungen optimiert ist.
In einer Ausführungsform können Arrays aus mehreren Instanzen der Grafikausführungseinheit 508 in einer Grafikteilkerngruppierung (z.B. einem Teilbaustein) instantiiert werden. Für Skalierbarkeit können Produktarchitekten die genaue Anzahl an Ausführungseinheiten pro Teilkerngruppierung wählen. In einer Ausführungsform kann die Ausführungseinheit 508 Anweisungen über eine Vielzahl von Ausführungskanälen hinweg ausführen. In einer weiteren Ausführungsform wird jeder auf der Grafikausführungseinheit 508 ausgeführte Thread auf einem anderen Kanal ausgeführt.
6 veranschaulicht eine weitere Ausführungseinheit 600 gemäß einer Ausführungsform. Bei der Ausführungseinheit 600 kann es sich um eine rechenoptimierte Ausführungseinheit zur Verwendung in beispielsweise einer Rechen-Engine-Kachel 340A bis 340D wie in 3C handeln, ist jedoch hierauf nicht eingeschränkt. Varianten der Ausführungseinheit 600 können zudem in einer Grafik-Engine-Kachel 310A bis 310D wie in 3B verwendet werden. In einer Ausführungsform weist die Ausführungseinheit 600 eine Thread-Steuereinheit 601, eine Thread-Statuseinheit 602, eine Anweisungsabruf/-vorabrufeinheit 603 und eine Anweisungsdecodiereinheit 604 auf. Die Ausführungseinheit 600 weist zusätzlich eine Registerdatei 606 auf, die Register speichert, die Hardware-Threads innerhalb der Ausführungseinheit zugewiesen werden können. Die Ausführungseinheit 600 weist zusätzlich eine Sendeeinheit 607 und eine Verzweigungseinheit 608 auf. In einer Ausführungsform können die Sendeeinheit 607 und die Verzweigungseinheit 608 ähnlich wie die Sendeeinheit 530 und eine Verzweigungseinheit 532 der Grafikausführungseinheit 508 aus 5B arbeiten.
Die Ausführungseinheit 600 weist zudem eine Recheneinheit 610 auf, die mehrere verschiedene Arten von Funktionseinheiten umfasst. In einer Ausführungsform weist die Recheneinheit 610 eine ALU-Einheit 611 auf, die ein Array aus arithmetischlogischen Einheiten aufweist. Die ALU-Einheit 611 kann dafür konfiguriert sein, 64-Bit-, 32-Bit- und 16-Bit-Ganzzahl- und Gleitkommaoperationen durchzuführen. Ganzzahl- und Gleitkommaoperationen können gleichzeitig durchgeführt werden. Die Recheneinheit 610 kann zudem ein systolisches Array 612 und eine Matheeinheit 613 aufweisen. Das systolische Array 612 weist ein W breites und D tiefes Netzwerk aus Datenverarbeitungseinheiten auf, das verwendet werden kann, um Vektor- und andere datenparallele Operationen systolisch durchzuführen. In einer Ausführungsform kann das systolische Array 612 dafür konfiguriert sein, Matrixoperationen wie beispielsweise Matrix-Punktproduktoperationen durchzuführen. In einer Ausführungsform unterstützt das systolische Array 612 16-Bit-Gleitkommaoperationen sowie 8-Bit- und 4-Bit-Ganzzahloperationen. In einer Ausführungsform kann das systolische Array 612 dafür konfiguriert sein, Maschinenlernoperationen zu beschleunigen. In solchen Ausführungsformen kann das systolische Array 612 mit Unterstützung für das bfloat-16-Bit-Gleitkommaformat konfiguriert sein. In einer Ausführungsform kann eine Matheeinheit 613 umfasst sein, um einen bestimmten Teilsatz mathematischer Operationen effizient und stromsparender als die ALU-Einheit 611 durchzuführen. Die Matheeinheit 613 kann eine Variante einer Mathelogik umfassen, die in gemeinsamer Funktionslogik einer Grafikverarbeitungs-Engine zu finden sein kann, die durch andere Ausführungsformen bereitgestellt ist (z.B. der Mathelogik 422 der gemeinsamen Funktionslogik 420 aus 4) In einer Ausführungsform kann die Mathelogik 613 dafür konfiguriert sein, 32-Bit- und 64-Bit-Gleitkommaoperationen durchzuführen.
Die Thread-Steuereinheit 601 weist Logik zum Steuern der Ausführung von Threads innerhalb der Ausführungseinheit auf. Die Thread-Steuereinheit 601 kann Thread-Vermittlungslogik aufweisen, um die Ausführung von Threads innerhalb der Ausführungseinheit 600 zu starten, zu stoppen und zurückzustellen. Die Thread-Statuseinheit 602 kann verwendet werden, um einen Thread-Status für zur Ausführung auf der Ausführungseinheit 600 zugewiesene Threads zu speichern. Das Speichern des Thread-Status innerhalb der Ausführungseinheit 600 ermöglicht die schnelle Zurückstellung von Threads, wenn diese Threads blockiert oder untätig werden. Die Anweisungsabruf/-vorabrufeinheit 603 kann Anweisungen aus einem Anweisungscache einer übergeordneten Ausführungslogik (z.B. Anweisungscache 506 wie in 5A) abrufen. Die Anweisungsabruf/-vorabrufeinheit 603 kann auch auf Grundlage einer Analyse aktuell ausgeführter Threads Vorabrufanfragen für Anweisungen ausgeben, die in den Anweisungscache geladen werden sollen. Die Anweisungsdecodiereinheit 604 kann verwendet werden, um von den Recheneinheiten auszuführende Anweisungen zu decodieren. In einer Ausführungsform kann die Anweisungsdecodiereinheit 604 als sekundärer Decodierer verwendet werden, um komplexe Anweisungen in einzelne Mikrooperationen zu decodieren.
Die Ausführungseinheit 600 weist zusätzlich eine Registerdatei 606 auf, die von auf der Ausführungseinheit 600 ausgeführten Hardware-Threads verwendet werden kann. Register in der Registerdatei 606 können auf die zum Ausführen mehrerer gleichzeitiger Threads innerhalb der Recheneinheit 610 der Ausführungseinheit 600 verwendete Logik aufgeteilt werden. Die Anzahl logischer Threads, die von der Grafikausführungseinheit 600 ausgeführt werden können, ist nicht auf die Anzahl an Hardware-Threads begrenzt, und jedem Hardware-Thread können mehrere logische Threads zugewiesen werden. Die Größe der Registerdatei 606 kann je nach Ausführungsform auf Grundlage der Anzahl unterstützter Hardware-Threads variieren. In einer Ausführungsform kann Registerumbenennung verwendet werden, um Register dynamisch Hardware-Threads zuzuteilen.
7 ist ein Blockschaubild, das Anweisungsformate 700 eines Grafikprozessors gemäß einigen Ausführungsformen veranschaulicht. In einer oder mehreren Ausführungsformen unterstützen die Grafikprozessor-Ausführungseinheiten einen Befehlssatz mit Anweisungen in mehreren Formaten. Die Kästen mit durchgehenden Linien veranschaulichen die Komponenten, die grundsätzlich in einer Anweisung einer Ausführungseinheit umfasst sind, während die gestrichelten Linien Komponenten umfassen, die optional sind oder die nur in einem Teilsatz der Anweisungen umfasst sind. In einigen Ausführungsformen handelt es sich bei dem beschriebenen und abgebildeten Anweisungsformat 700 um Makroanweisungen, d.h. um Anweisungen, die der Ausführungseinheit zugeführt werden, im Gegensatz zu Mikrooperationen, die sich aus der Anweisungsdecodierung ergeben, sobald die Anweisung verarbeitet wurde.
In einigen Ausführungsformen unterstützen die Grafikprozessor-Ausführungseinheiten nativ Anweisungen in einem 128-Bit-Anweisungsformat 710. Auf Grundlage der ausgewählten Anweisung, der Anweisungsoptionen und der Anzahl an Operanden ist für einige Anweisungen ein komprimiertes 64-Bit-Anweisungsformat 730 verfügbar. 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 zum Teil anhand eines Satzes von Indexwerten in einem Indexfeld 713 komprimiert. Die Hardware der Ausführungseinheit referenziert einen Satz von Komprimierungstabellen auf Grundlage der Indexwerte und verwendet die Ausgaben der Komprimierungstabellen, um eine native Anweisung im 128-Bit-Anweisungsformat 710 zu rekonstruieren. Es können auch andere Anweisungsgrößen und -formate verwendet werden.
Für jedes Format definiert ein Anweisungs-Opcode 712 die Operation, die die Ausführungseinheit durchführen soll. Die Ausführungseinheiten führen jede Anweisung parallel über die mehreren Datenelemente jedes Operanden hinweg aus. Beispielsweise führt in Reaktion auf eine Addieranweisung die Ausführungseinheit eine gleichzeitige Addieroperation auf jedem Farbkanal durch, der ein Texturelement oder Bildelement darstellt. Standardmäßig führt die Ausführungseinheit jede Anweisung über alle Datenkanäle der Operanden hinweg durch. In einigen Ausführungsformen ermöglicht ein Anweisungssteuerfeld 714 die Steuerung bestimmter Ausführungsoptionen wie beispielsweise Kanalauswahl (z.B. Prädikation) und die Datenkanalreihenfolge (z.B. Swizzling). Für Anweisungen im 128-Bit-Anweisungsformat 710 begrenzt ein Ausf.-Größe-Feld 716 die Anzahl an Datenkanälen, die parallel ausgeführt werden. In einigen Ausführungsformen ist das Ausf.-Größe-Feld 716 nicht für die Verwendung im komprimierten 64-Bit-Anweisungsformat 730 verfügbar.
Einige Anweisungen der Ausführungseinheiten verfügen über bis zu drei Operanden, darunter zwei Quelloperanden src0 720, src1 722 sowie einen Zieloperanden 718. In einigen Ausführungsformen unterstützen die Ausführungseinheiten Anweisungen mit zwei Zielen, wobei eines der Ziele implizit ist. Datenmanipulationsanweisungen können über einen dritten Quelloperanden (z.B. SRC2 724) verfügen, wobei der Anweisungs-Opcode 712 die Anzahl an Quelloperanden bestimmt. Beim letzten Quelloperanden einer Anweisung kann es sich um einen unmittelbaren (z.B. hartcodierten) Wert handeln, der mit der Anweisung weitergegeben wird.
In einigen Ausführungsformen weist das 128-Bit-Anweisungsformat 710 ein Feld 726 für den Zugriffs-/Adressierungsmodus auf, das beispielsweise angibt, ob der direkte Registeradressierungsmodus oder der indirekte Registeradressierungsmodus verwendet wird. Wenn der direkte Registeradressierungsmodus verwendet wird, wird die Registeradresse eines oder mehrerer Operanden direkt durch Bits in der Anweisung angegeben.
In einigen Ausführungsformen weist das 128-Bit-Anweisungsformat 710 ein Feld 726 für den Zugriffs-/Adressierungsmodus auf, das einen Adressierungsmodus 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, die einen 16-Byte-ausgerichteten Zugriffsmodus und einen 1-Byte-ausgerichteten Zugriffsmodus umfassen, wobei die Byte-Ausrichtung des Zugriffsmodus die Zugriffsausrichtung der Anweisungsoperanden bestimmt. Beispielsweise kann in einem ersten Modus die Anweisung Byte-ausgerichtete Adressierung für Quell- und Zieloperanden verwenden, und in einem zweiten Modus kann die Anweisung 16-Byte-ausgerichtete Adressierung für alle Quell- und Zieloperanden verwenden.
In einer Ausführungsform bestimmt der Adressierungsmodusabschnitt des Felds 726 für den Zugriffs-/Adressierungsmodus, ob die Anweisung direkte oder indirekte Adressierung verwenden soll. Wenn der direkte Registeradressierungsmodus verwendet wird, geben Bits in der Anweisung direkt die Registeradresse eines oder mehrerer Operanden an. Wenn der indirekte Registeradressierungsmodus verwendet wird, kann die Registeradresse eines oder mehrerer Operanden auf Grundlage eines Adressregisterwerts und eines unmittelbaren Adressfelds in der Anweisung berechnet werden.
In einigen Ausführungsformen werden Anweisungen auf Grundlage von Opcode- 712 Bitfeldern gruppiert, um Opcode-Decodierung 740 zu vereinfachen. Für einen 8-Bit-Opcode ermöglichen die Bits 4, 5 und 6 der Ausführungseinheit, den Opcode-Typ zu bestimmen. Die konkret gezeigte Opcode-Gruppierung ist lediglich beispielhaft. In einigen Ausführungsformen umfasst eine Verschiebungs- und Logik-Opcode-Gruppe 742 Datenverschiebungs- und Logikanweisungen (z.B. Verschiebe (mov), Vergleiche (cmp)). In einigen Ausführungsformen teilt sich die Verschiebungs- und Logikgruppe 742 die fünf höchstwertigen Bits (Most Significant Bits, MSBs), wobei Verschiebe- (mov-) Anweisungen in der Form 0000xxxxb und Logikanweisungen in der Form 0001xxxxb vorliegen. Eine Anweisungsgruppe 744 für Flusssteuerung (z.B. Rufe auf, Springe (jmp)) umfasst Anweisungen in der Form 0010xxxxb (z.B. 0x20). Eine Anweisungsgruppe 746 für Verschiedenes umfasst eine Mischung aus Anweisungen, darunter Synchronisierungsanweisungen (z.B. Warte, Sende) in der Form 001 1xxxxb (z.B. 0x30). Eine Parallelmathe-Anweisungsgruppe 748 umfasst komponentenweise arithmetische Anweisungen (z.B. Addiere, Multipliziere (mul)) in der Form 0100xxxxb (z.B. 0x40). Die Parallelmathe-Gruppe 748 führt die arithmetischen Operationen über Datenkanäle hinweg parallel durch. Die Vektormathegruppe 750 umfasst arithmetische Anweisungen (z.B. dp4) in der Form 0101xxxxb (z.B. 0x50). Die Vektormathegruppe führt arithmetische Berechnungen wie beispielsweise Punktproduktberechnungen an Vektoroperanden durch. In einer Ausführungsform kann die veranschaulichte Opcode-Decodierung 740 verwendet werden, um zu bestimmen, welcher Abschnitt einer Ausführungseinheit verwendet wird, um eine decodierte Anweisung auszuführen. Beispielsweise können einige Anweisungen als systolische Anwendungen bestimmt werden, die von einem systolischen Array durchgeführt werden. Andere Anweisungen wie beispielsweise Strahlverfolgungsanweisungen (nicht gezeigt) können zu einem Strahlverfolgungskern oder einer Strahlverfolgungslogik innerhalb eines Bausteins oder einer Partition der Ausführungslogik geleitet werden.
Grafikpipeline
8 ist ein Blockschaubild einer weiteren Ausführungsform eines Grafikprozessors 800. Elemente aus 8, die gleiche Bezugszeichen (oder Namen) wie die Elemente einer anderen Figur aufweisen, können in ähnlicher Weise wie der vorliegend an anderer Stelle beschriebenen arbeiten oder fungieren, sind hierauf jedoch nicht eingeschränkt.
In einigen Ausführungsformen weist der Grafikprozessor 800 eine Geometriepipeline 820, eine Medienpipeline 830, eine Anzeige-Engine 840, Thread-Ausführungslogik 850 und eine Render-Ausgabepipeline 870 auf. In einigen Ausführungsformen handelt es sich bei dem Grafikprozessor 800 um einen Grafikprozessor innerhalb eines Mehrkern-Verarbeitungssystems, das einen oder mehrere Allzweck-Verarbeitungskerne aufweist. Der Grafikprozessor wird durch Register-Schreibvorgänge in ein oder mehrere Steuerregister (nicht gezeigt) oder über Befehle gesteuert, die über eine Ringverbindung 802 an den Grafikprozessor 800 ausgegeben werden. In einigen Ausführungsformen koppelt die Ringverbindung 802 den Grafikprozessor 800 an andere Verarbeitungskomponenten wie beispielsweise andere Grafikprozessoren oder Allzweckprozessoren. Von der Ringverbindung 802 kommende Befehle werden von einem Befehlsstreamer 803 interpretiert, der Anweisungen an einzelne Komponenten der Geometriepipeline 820 oder der Medienpipeline 830 liefert.
In einigen Ausführungsformen lenkt der Befehlsstreamer 803 den Betrieb eines Vertexabrufers 805, der Vertexdaten aus dem Speicher liest und vom Befehlsstreamer 803 bereitgestellte Vertexverarbeitungsbefehle ausführt. In einigen Ausführungsformen stellt der Vertexabrufer 805 Vertexdaten an einen Vertex-Shader 807 bereit, der an jedem Vertex Koordinatenraumtransformation und Beleuchtungsoperationen durchführt. In einigen Ausführungsformen führen der Vertexabrufer 805 und der Vertex-Shader 807 Vertexverarbeitungsanweisungen aus, indem sie Ausführungs-Threads über einen Thread-Dispatcher 831 an Ausführungseinheiten 852A bis 852B verschicken.
In einigen Ausführungsformen handelt es sich bei den Ausführungseinheiten 852A bis 852B um ein Array aus Vektorprozessoren mit einem Befehlssatz zum Durchführen von Grafik- und Medienoperationen. In einigen Ausführungsformen verfügen die Ausführungseinheiten 852A bis 852B über einen angebundenen L1-Cache 851, der spezifisch für jedes Array ist oder von den Arrays gemeinsam verwendet wird. Der Cache kann als Datencache, Anweisungscache oder ein einziger Cache konfiguriert sein, der so partitioniert ist, dass er Daten und Anweisungen in verschiedenen Partitionen enthält.
In einigen Ausführungsformen weist die Geometriepipeline 820 Tesselationskomponenten auf, um Hardware-beschleunigte Tesselation von 3D-Objekten durchzuführen. In einigen Ausführungsformen konfiguriert ein programmierbarer HüllenShader 811 die Tesselationsoperationen. Ein programmierbarer Domain-Shader 817 sorgt für die Back-End-Auswertung der Tesselationsausgabe. Ein Tesselierer 813 arbeitet nach Anweisung des Hüllen-Shaders 811 und enthält Speziallogik zum Erzeugen eines Satzes detaillierter geometrischer Objekte auf Grundlage eines groben geometrischen Modells, das als Eingabe an die Geometriepipeline 820 bereitgestellt wird. In einigen Ausführungsformen können Tesselationskomponenten (z.B. der Hüllen-Shader 811, der Tesselierer 813 und der Domain-Shader 817) umgangen werden, wenn keine Tesselation verwendet wird.
In einigen Ausführungsformen können komplette geometrische Objekte von einem Geometrie-Shader 819 über einen oder mehrere Threads verarbeitet werden, die an die Ausführungseinheiten 852A bis 852B verschickt werden, oder sie können direkt an den Clipper 829 weitergeleitet werden. In einigen Ausführungsformen arbeitet der Geometrie-Shader an ganzen geometrischen Objekten anstatt an Vertices oder Vertexausschnitten wie in früheren Stufen der Grafikpipeline. 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 Geometrietesselation durchzuführen, wenn die Tesselationseinheiten deaktiviert sind.
Vor der Rasterung verarbeitet ein Clipper 829 Vertexdaten. Bei dem Clipper 829 kann es sich um einen Clipper mit fester Funktion oder einen programmierbaren Clipper mit Clipping- und Geometrie-Shader-Funktionen handeln. In einigen Ausführungsformen verschickt eine Raster- und Tiefenprüfkomponente 873 in der Render-Ausgabepipeline 870 Pixel-Shader, um die geometrischen Objekte in Pro-Pixel-Repräsentationen umzuwandeln. In einigen Ausführungsformen ist in der Thread-Ausführungslogik 850 Pixel-Shader-Logik umfasst. In einigen Ausführungsformen kann eine Anwendung die Raster- und Tiefenprüfkomponente 873 umgehen und über eine Stream-out-Einheit 823 auf ungerasterte Vertexdaten zugreifen.
Der Grafikprozessor 800 weist einen Verbindungsbus, ein Verbindungs-Fabric oder einen anderen Verbindungsmechanismus auf, der die Weitergabe von Daten und Nachrichten unter den Hauptkomponenten des Prozessors ermöglicht. In einigen Ausführungsformen sind Ausführungseinheiten 852A bis 852B und zugehörige Logikeinheiten (z.B. LI-Cache 851, Sampler 854, Texturcache 858 usw.) über einen Datenport 856 untereinander verbunden, um Speicherzugriffe durchzuführen und mit Render-Ausgabepipeline-Komponenten des Prozessors zu kommunizieren. In einigen Ausführungsformen verfügen der Sampler 854, die Caches 851, 858 und die Ausführungseinheiten 852A bis 852B jeweils über separate Speicherzugriffspfade. In einer Ausführungsform kann der Texturcache 858 auch als Sampler-Cache konfiguriert sein.
In einigen Ausführungsformen enthält die Render-Ausgabepipeline 870 eine Raster- und Tiefenprüfkomponente 873, die vertexbasierte Objekte in zugehörige pixelbasierte Repräsentationen umwandelt. In einigen Ausführungsformen weist die Rasterlogik eine Fensterbildungs-/Maskiereinheit auf, um Festfunktions-Dreieck- und Linienrasterung durchzuführen. Zudem sind in einigen Ausführungsformen ein zugehöriger Render-Cache 878 und Tiefencache 879 verfügbar. Eine Pixeloperationskomponente 877 führt pixelbasierte Operationen an den Daten durch, obwohl in einigen Fällen Pixeloperationen, die mit 2D-Operationen verbunden sind (z.B. Bitblock-Bildübertragungen mit Überblendung), von der 2D-Engine 841 durchgeführt oder zur Anzeigezeit vom Display-Controller 843 unter Verwendung von Überlagerungsanzeigeebenen ersetzt werden. In einigen Ausführungsformen ist ein gemeinsamer L3-Cache 875 für alle Grafikkomponenten verfügbar, wodurch die gemeinsame Nutzung von Daten ohne Verwendung von Hauptsystemspeicher ermöglicht wird.
In einigen Ausführungsformen weist die Grafikprozessor-Medienpipeline 830 eine Medien-Engine 837 und ein Video-Front-End 834 auf. In einigen Ausführungsformen empfängt das Medien-Front-End 834 Pipelinebefehle vom Befehlsstreamer 803. In einigen Ausführungsformen weist die Medienpipeline 830 einen separaten Befehlsstreamer auf. In einigen Ausführungsformen verarbeitet das Video-Front-End 834 Medienbefehle, bevor es den Befehl an die Medien-Engine 837 sendet. In einigen Ausführungsformen weist die Medien-Engine 837 Thread-Erzeugungsfunktionalität auf, um Threads zur Versendung an die Thread-Ausführungslogik 850 über den Thread-Dispatcher 831 zu erzeugen.
In einigen Ausführungsformen weist der Grafikprozessor 800 eine Anzeige-Engine 840 auf. In einigen Ausführungsformen befindet sich die Anzeige-Engine 840 außerhalb des Prozessors 800 und ist über die Ringverbindung 802 oder einen anderen Verbindungsbus oder ein Verbindungs-Fabric mit dem Grafikprozessor gekoppelt. In einigen Ausführungsformen weist die Anzeige-Engine 840 eine 2D-Engine 841 und einen Anzeigecontroller 843 auf. In einigen Ausführungsformen enthält die Anzeige-Engine 840 Speziallogik, die in der Lage ist, unabhängig von der 3D-Pipeline zu arbeiten. In einigen Ausführungsformen ist der Anzeigecontroller 843 mit einer Anzeigeeinrichtung (nicht gezeigt) gekoppelt, bei der es sich um eine systemintegrierte Anzeigeeinrichtung wie in einem Laptop-Computer oder um eine über einen Anzeigeeinrichtungsverbinder angeschlossene externe Anzeigeeinrichtung handeln kann.
In einigen Ausführungsformen sind die Geometriepipeline 820 und die Medienpipeline 830 so konfigurierbar, dass sie Operationen auf Grundlage mehrerer Grafik- und Medienprogrammierschnittstellen durchführen und nicht spezifisch für eine Anwendungsprogrammierschnittstelle (API) sind. In einigen Ausführungsformen übersetzt Treibersoftware für den Grafikprozessor API-Aufrufe, die für eine bestimmte Grafik- oder Medienbibliothek spezifisch sind, in Befehle, die vom Grafikprozessor verarbeitet werden können. In einigen Ausführungsformen wird die Open Graphics Library (OpenGL), Open Computing Language (OpenCL) und/oder Vulkan-Grafik- und Rechen-API, alle von der Khronos Group, unterstützt. In einigen Ausführungsformen kann zudem die Direct3D-Bibliothek der Microsoft Corporation unterstützt werden. In einigen Ausführungsformen kann eine Kombination dieser Bibliotheken unterstützt werden. Zudem kann die Open Source Computer Vision Library (OpenCV) unterstützt werden. Eine künftige API mit einer kompatiblen 3D-Pipeline würde ebenfalls unterstützt werden, sofern die Pipeline der künftigen API auf die Pipeline des Grafikprozessors abgebildet werden kann.
Grafikpipelineprogrammierung
9A ist ein Blockschaubild, das ein Befehlsformat 900 eines Grafikprozessors gemäß einigen Ausführungsformen veranschaulicht. 9B ist ein Blockschaubild, das eine Befehlssequenz 910 eines Grafikprozessors gemäß einer Ausführungsform veranschaulicht. Die Kästen mit durchgehenden Linien in 9A veranschaulichen die Komponenten, die grundsätzlich in einem Grafikbefehl umfasst sind, während die gestrichelten Linien Komponenten umfassen, die optional sind oder die nur in einem Teilsatz der Grafikbefehle umfasst sind. Das beispielhafte Grafikprozessor-Befehlsformat 900 aus 9A weist Datenfelder auf, um einen Client 902, einen Befehlsoperationscode (Opcode) 904 und Daten 906 für den Befehl zu identifizieren. In einigen Befehlen sind zudem ein Teil-Opcode 905 und eine Befehlsgröße 908 umfasst.
In einigen Ausführungsformen gibt der Client 902 die Client-Einheit der Grafikeinrichtung an, die die Befehlsdaten verarbeitet. In einigen Ausführungsformen untersucht ein Grafikprozessor-Befehlsparser das Client-Feld jedes Befehls, um die weitere Verarbeitung des Befehls zu konditionieren und die Befehlsdaten an die geeignete Client-Einheit zu leiten. In einigen Ausführungsformen weisen die Grafikprozessor-Client-Einheiten eine Speicherschnittstelleneinheit, eine Render-Einheit, eine 2D-Einheit, eine 3D-Einheit und eine Medieneinheit auf Jede Client-Einheit weist eine entsprechende Verarbeitungspipeline auf, die die Befehle verarbeitet. Sobald der Befehl von der Client-Einheit empfangen wird, liest die Client-Einheit den Opcode 904 und, sofern vorhanden, den Teil-Opcode 905, um die durchzuführende Operation zu bestimmen. Die Client-Einheit führt den Befehl mittels Informationen im Datenfeld 906 aus. Für einige Befehle wird eine explizite Befehlsgröße 908 erwartet, um die Größe des Befehls anzugeben. In einigen Ausführungsformen bestimmt der Befehlsparser automatisch die Größe zumindest einiger der Befehle auf Grundlage des Befehls-Opcodes. In einigen Ausführungsformen sind Befehle über Vielfache eines Doppelworts ausgerichtet. Es können auch andere Befehlsformate verwendet werden.
Das Flussdiagramm in 9B veranschaulicht eine beispielhafte Befehlssequenz 910 eines Grafikprozessors. In einigen Ausführungsformen verwendet Software oder Firmware eines Datenverarbeitungssystems, das über eine Ausführungsform eines Grafikprozessors verfügt, eine Version der gezeigten Befehlssequenz zum Einrichten, Ausführen und Beenden eines Satzes von Grafikoperationen. Eine Beispiel-Befehlssequenz wird nur zu Beispielzwecken gezeigt und beschrieben, da die Ausführungsformen nicht auf diese konkreten Befehle oder diese Befehlssequenz eingeschränkt sind. Darüber hinaus können die Befehle als Batch aus Befehlen in einer Befehlssequenz ausgegeben werden, so dass der Grafikprozessor die Befehlssequenz zumindest teilweise gleichzeitig verarbeitet.
In einigen Ausführungsformen kann die Grafikprozessor-Befehlssequenz 910 mit einem Pipelineleerungsbefehl 912 beginnen, um dafür zu sorgen, dass etwaige aktive Grafikpipelines die aktuell anstehenden Befehle für die Pipeline abschließen. In einigen Ausführungsformen arbeiten die 3D-Pipeline 922 und die Medienpipeline 924 nicht gleichzeitig. Die Pipelineleerung wird durchgeführt, um dafür zu sorgen, dass die aktive Grafikpipeline alle anstehenden Befehle abschließt. Als Reaktion auf eine Pipelineleerung pausiert der Befehlsparser für den Grafikprozessor die Befehlsverarbeitung, bis die aktiven Zeichen-Engines die anstehenden Operationen abgeschlossen haben und die entsprechenden Lesecaches ungültig gemacht wurden. Wahlweise können alle Daten im Render-Cache, die als „schmutzig“ markiert sind, in den Speicher geleert werden. In einigen Ausführungsformen kann der Pipelineleerungsbefehl 912 für Pipelinesynchronisierung verwendet werden oder bevor der Grafikprozessor in einen Stromsparmodus versetzt wird.
In einigen Ausführungsformen wird ein Pipelineauswahlbefehl 913 verwendet, wenn eine Befehlssequenz es erfordert, dass der Grafikprozessor explizit zwischen Pipelines umschaltet. In einigen Ausführungsformen ist ein Pipelineauswahlbefehl 913 nur einmal innerhalb eines Ausführungskontexts erforderlich, bevor Pipelinebefehle ausgegeben werden, es sei denn, der Kontext soll Befehle für beide Pipelines ausgeben. In einigen Ausführungsformen ist ein Pipelineleerungsbefehl 912 unmittelbar vor einem Pipelinewechsel über den Pipelineauswahlbefehl 913 erforderlich.
In einigen Ausführungsformen konfiguriert ein Pipelinesteuerbefehl 914 eine Grafikpipeline für den Betrieb und wird verwendet, um die 3D-Pipeline 922 und die Medienpipeline 924 zu programmieren. In einigen Ausführungsformen konfiguriert der Pipelinesteuerbefehl 914 den Pipelinestatus für die aktive Pipeline. In einer Ausführungsform wird der Pipelinesteuerbefehl 914 für Pipelinesynchronisierung verwendet und um Daten aus einem oder mehreren Cachespeichern innerhalb der aktiven Pipeline zu löschen, bevor ein Batch aus Befehlen verarbeitet wird.
In einigen Ausführungsformen werden Rückgabepufferstatusbefehle 916 verwendet, um einen Satz Rückgabepuffer für die jeweiligen Pipelines zum Schreiben von Daten zu konfigurieren. Einige Pipelineoperationen erfordern die Zuteilung, Auswahl oder Konfigurierung eines oder mehrerer Rückgabepuffer, in die die Operationen während der Verarbeitung Zwischendaten schreiben. In einigen Ausführungsformen verwendet der Grafikprozessor zudem einen oder mehrere Rückgabepuffer, um Ausgabedaten zu speichern und Thread-übergreifende Kommunikation durchzuführen. In einigen Ausführungsformen umfasst der Rückgabepufferstatus 916 Auswählen der Größe und Anzahl an Rückgabepuffern, die für einen Satz von Pipelineoperationen verwendet werden sollen.
Die übrigen Befehle in der Befehlssequenz unterscheiden sich je nach der aktiven Pipeline für Operationen. Auf Grundlage einer Pipelinebestimmung 920 wird die Befehlssequenz auf die 3D-Pipeline 922 beginnend mit dem 3D-Pipelinestatus 930 oder die Medienpipeline 924 beginnend mit dem Medienpipelinestatus 940 zugeschnitten.
Die Befehle zum Konfigurieren des 3D-Pipelinestatus 930 umfassen 3D-Statuseinstellungsbefehle für Vertexpufferstatus, Vertexelementstatus, Konstantfarbenstatus, Tiefenpufferstatus und andere Statusvariablen, die zu konfigurieren sind, bevor 3D-Primitiv-Befehle verarbeitet werden. Die Werte dieser Befehle werden zumindest teilweise auf Grundlage der jeweils verwendeten 3D-API bestimmt. In einigen Ausführungsformen können 3D-Pipelinestatus- 930 Befehle auch selektiv bestimmte Pipelineelemente deaktivieren oder umgehen, falls diese Elemente nicht verwendet werden.
In einigen Ausführungsformen wird der Befehl 3D-Primitiv 932 verwendet, um durch die 3D-Pipeline zu verarbeitende 3D-Primitive zu übermitteln. Befehle und zugehörige Parameter, die über den Befehl 3D-Primitiv 932 an den Grafikprozessor übergeben werden, werden an die Vertexabruffunktion in der Grafikpipeline weitergeleitet. Die Vertexabruffunktion verwendet die Befehlsdaten des Befehls 3D-Primitiv 932, um Vertexdatenstrukturen zu erzeugen. Die Vertexdatenstrukturen werden in einem oder mehreren Rückgabepuffern gespeichert. In einigen Ausführungsformen wird der Befehl 3D-Primitiv 932 verwendet, um über Vertex-Shader Vertexoperationen an 3D-Primitiven durchzuführen. Um Vertex-Shader zu verarbeiten, verschickt die 3D-Pipeline 922 Shader-Ausführungs-Threads an Grafikprozessor-Ausführungseinheiten.
In einigen Ausführungsformen wird die 3D-Pipeline 922 über einen Ausführungs- 934 Befehl oder ein Ausführungsereignis ausgelöst. In einigen Ausführungsformen löst ein Registerschreibvorgang die Befehlsausführung aus. In einigen Ausführungsformen wird die Ausführung über einen „Go“- oder „Kick“-Befehl in der Befehlssequenz ausgelöst. In einer Ausführungsform wird die Befehlsausführung mittels eines Pipelinesynchronisierungsbefehls zum Leeren der Befehlssequenz durch die Grafikpipeline ausgelöst. Die 3D-Pipeline führt Geometrieverarbeitung für die 3D-Primitive durch. Sobald die Operationen abgeschlossen sind, werden die resultierenden geometrischen Objekte gerastert und die Pixel-Engine färbt die resultierenden Pixel. Für diese Operationen können auch zusätzliche Befehle zum Steuern von Pixelschattierung und Pixel-Back-End-Operationen umfasst sein.
In einigen Ausführungsformen folgt die Grafikprozessor-Befehlssequenz 910 bei der Durchführung von Medienoperationen dem Pfad der Medienpipeline 924. Grundsätzlich hängen die konkrete Verwendung und Art der Programmierung für die Medienpipeline 924 von den durchzuführenden Medien- oder Rechenoperationen ab. Bestimmte Mediendecodieroperationen können während der Mediendecodierung auf die Medienpipeline abgeladen werden. In einigen Ausführungsformen kann die Medienpipeline auch umgangen werden, und Mediendecodierung kann ganz oder teilweise mittels Ressourcen durchgeführt werden, die durch einen oder mehrere Allzweck-Verarbeitungskerne bereitgestellt werden. In einer Ausführungsform weist die Medienpipeline zudem Elemente für Operationen einer Allzweck-Grafikprozessoreinheit (GPGPUs) auf, wobei der Grafikprozessor verwendet wird, um SIMD-Vektoroperationen mittels Rechen-Shader-Programmen durchzuführen, die nicht explizit mit dem Rendern von Grafikprimitiven zusammenhängen.
In einigen Ausführungsformen ist die Medienpipeline 924 in ähnlicher Weise wie die 3D-Pipeline 922 konfiguriert. Ein Satz von Befehlen zum Konfigurieren des Medienpipelinestatus 940 wird vor den Medienobjektbefehlen 942 verschickt oder in einer Warteschlange platziert. In einigen Ausführungsformen umfassen Befehle für den Medienpipelinestatus 940 Daten zum Konfigurieren der Medienpipelineelemente, die verwendet werden, um die Medienobjekte zu verarbeiten. Dies umfasst Daten zum Konfigurieren der Videodecodier- und Videocodierlogik innerhalb der Medienpipeline, wie beispielsweise Codier- oder Decodierformat. In einigen Ausführungsformen unterstützen Befehle für den Medienpipelinestatus 940 zudem die Verwendung eines oder mehrerer Zeiger auf „indirekte“ Statuselemente, die ein Batch aus Statuseinstellungen enthalten.
In einigen Ausführungsformen liefern Medienobjektbefehle 942 Zeiger auf Medienobjekte zur Verarbeitung durch die Medienpipeline. Die Medienobjekte umfassen Speicherpuffer, die zu verarbeitende Videodaten enthalten. In einigen Ausführungsformen müssen alle Medienpipelinestatus gültig sein, bevor ein Medienobjektbefehl 942 ausgegeben wird. Sobald der Pipelinestatus konfiguriert ist und die Medienobjektbefehle 942 in die Warteschlange eingereiht sind, wird die Medienpipeline 924 über einen Ausführungsbefehl 944 oder ein äquivalentes Ausführungsereignis (z.B. einen Registerschreibvorgang) ausgelöst. Eine Ausgabe aus der Medienpipeline 924 kann dann durch Operationen nachbearbeitet werden, die durch die 3D-Pipeline 922 oder die Medienpipeline 924 bereitgestellt werden. In einigen Ausführungsformen werden GPGPU-Operationen in ähnlicher Weise konfiguriert und ausgeführt wie Medienoperationen.
Grafiksoftwarearchitektur
10 veranschaulicht eine beispielhafte Grafiksoftwarearchitektur für ein Datenverarbeitungssystem 1000 gemäß einigen Ausführungsformen. In einigen Ausführungsformen weist eine Softwarearchitektur eine 3D-Grafikanwendung 1010, ein Betriebssystem 1020 und mindestens einen Prozessor 1030 auf In einigen Ausführungsformen weist der Prozessor 1030 einen Grafikprozessor 1032 und einen oder mehrere Allzweck-Prozessorkerne 1034 auf. Die Grafikanwendung 1010 und das Betriebssystem 1020 werden jeweils im Systemspeicher 1050 des Datenverarbeitungssystems ausgeführt.
In einigen Ausführungsformen enthält die 3D-Grafikanwendung 1010 ein oder mehrere Shaderprogramme, die Schattieranweisungen 1012 umfassen. Die Anweisungen in der Shader-Sprache können in höherer Shader-Sprache vorliegen, beispielsweise High-Level Shader Language (HLSL) von Direct3D, OpenGL Shader Language (GLSL) usw. Die Anwendung umfasst zudem ausführbare Anweisungen 1014 in einer Maschinensprache, die sich zur Ausführung durch den Allzweck-Prozessorkern 1034 eignet. Die Anwendung umfasst zudem durch Vertexdaten definierte Grafikobjekte 1016.
In einigen Ausführungsformen handelt es sich bei dem Betriebssystem 1020 um ein Microsoft®-Windows®-Betriebssystem der Microsoft Corporation, ein proprietäres UNIX-ähnliches Betriebssystem oder ein UNIX-ähnliches Open-Source-Betriebssystem, das eine Variante des Linux-Kernels verwendet. Das Betriebssystem 1020 kann eine Grafik-API 1022 wie beispielsweise die Direct3D-API, die OpenGL-API oder die Vulkan-API unterstützen. Wenn die Direct3D-API verwendet wird, verwendet das Betriebssystem 1020 einen Front-End-Shader-Compiler 1024, um alle Shader-Anweisungen 1012 in HLSL in eine Shader-Sprache niedrigerer Ebene zu kompilieren. Bei der Kompilierung kann es sich um Just-in-Time- (JIT-) Kompilierung handeln, oder die Anwendung kann Shader-Vorkompilierung durchführen. In einigen Ausführungsformen werden während der Kompilierung der 3 D-Grafikanwendung 1010 Shader höherer Ebene in Shader niedrigerer Ebene kompiliert. In einigen Ausführungsformen werden die Shader-Anweisungen 1012 in einer Zwischenform bereitgestellt, beispielsweise einer Version der Standard Portable Intermediate Representation (SPIR), wie sie von der Vulkan-API verwendet wird.
In einigen Ausführungsformen enthält ein Nutzermodus-Grafiktreiber 1026 einen Back-End-Shader-Compiler 1027, um die Shader-Anweisungen 1012 in eine hardwarespezifische Darstellung zu konvertieren. Wenn die OpenGL-API in Verwendung ist, werden Schattieranweisungen 1012 in der höheren GLSL-Sprache zur Kompilierung an einen Nutzermodus-Grafiktreiber 1026 übergeben. In einigen Ausführungsformen verwendet der Nutzermodus-Grafiktreiber 1026 Betriebssystem-Kernelmodusfunktionen 1028, um mit einem Kernelmodus-Grafiktreiber 1029 zu kommunizieren. In einigen Ausführungsformen kommuniziert der Kernelmodus-Grafiktreiber 1029 mit dem Grafikprozessor 1032, um Befehle und Anweisungen zu verschicken.
IP-Kern-Implementierungen
Ein oder mehrere Aspekte mindestens einer Ausführungsform können durch auf einem maschinenlesbaren Medium gespeicherten repräsentativen Code implementiert werden, der Logik innerhalb einer integrierten Schaltung wie beispielsweise eines Prozessors repräsentiert oder definiert. Beispielsweise kann das maschinenlesbare Medium Anweisungen aufweisen, die verschiedene Logik innerhalb des Prozessors repräsentieren. Wenn sie von einer Maschine gelesen werden, können die Anweisungen die Maschine veranlassen, die Logik zur Durchführung der vorliegend beschriebenen Methoden zu fertigen. Solche Repräsentationen, die als „IP-Kerne“ bezeichnet werden, sind wiederverwendbare Logikeinheiten für eine integrierte Schaltung, die auf einem greifbaren, maschinenlesbaren Medium als Hardwaremodell gespeichert werden können, das die Struktur der integrierten Schaltung beschreibt. Das Hardwaremodell kann an verschiedene Kunden oder Herstellungseinrichtungen geliefert werden, die das Hardwaremodell auf Fertigungsmaschinen laden, die die integrierte Schaltung herstellen. Die integrierte Schaltung kann so gefertigt werden, dass die Schaltung Operationen durchführt, die in Zusammenhang mit einer der vorliegend beschriebenen Ausführungsformen beschrieben werden.
11A ist ein Blockschaubild, das ein IP-Kern-Entwicklungssystem 1100 veranschaulicht, das verwendet werden kann, um eine integrierte Schaltung zur Durchführung von Operationen gemäß einer Ausführungsform herzustellen. Das IP-Kern-Entwicklungssystem 1100 kann verwendet werden, um modulare, wiederverwendbare Entwürfe zu erzeugen, die in einen größeren Entwurf integriert oder zum Konstruieren einer vollständigen integrierten Schaltung (z.B. einer integrierten SOC-Schaltung) verwendet werden können. Eine Entwurfseinrichtung 1130 kann eine Softwaresimulation 1110 eines IP-Kern-Entwurfs in einer höheren Programmiersprache (z.B. C/C++) erzeugen. Die Softwaresimulation 1110 kann verwendet werden, um das Verhalten des IP-Kerns mittels eines Simulationsmodells 1112 zu entwerfen, zu prüfen und zu verifizieren. Das Simulationsmodell 1112 kann Funktions-, Verhaltens- und/oder Zeitsteuerungssimulationen umfassen. Anschließend kann aus dem Simulationsmodell 1112 ein Register-Transfer-Level- (RTL-) Entwurf 1115 erstellt werden. Bei dem RTL-Entwurf 1115 handelt es sich um eine Abstraktion des Verhaltens der integrierten Schaltung, die den Fluss digitaler Signale zwischen Hardwareregistern modelliert, einschließlich der zugehörigen Logik, die mittels der modellierten digitalen Signale ausgeführt wird. Zusätzlich zu einem RTL-Entwurf 1115 können auch Entwürfe niedrigerer Ebenen auf Logikebene oder Transistorebene erstellt, entworfen oder synthetisiert werden. Daher können die einzelnen Details des ursprünglichen Entwurfs und der Simulation variieren.
Der RTL-Entwurf 1115 oder ein Äquivalent kann von der Entwurfseinrichtung weiter in ein Hardwaremodell 1120 synthetisiert werden, das in einer Hardware-Beschreibungssprache (Hardware Description Language, HDL) oder einer anderen Darstellung physikalischer Entwurfsdaten vorliegen kann. Die HDL kann ferner simuliert oder geprüft werden, um den IP-Kern-Entwurf zu verifizieren. Der IP-Kern-Entwurf kann mittels nichtflüchtigen Speichers 1140 (z.B. Festplatte, Flashspeicher oder ein beliebiges nichtflüchtiges Speichermedium) zur Lieferung an eine Fertigungseinrichtung 1165 Dritter gespeichert werden. Alternativ kann der IP-Kern-Entwurf (z.B. über das Internet) über eine drahtgebundene Verbindung 1150 oder eine drahtlose Verbindung 1160 übertragen werden. Die Fertigungseinrichtung 1165 kann dann eine integrierte Schaltung fertigen, die zumindest teilweise auf dem IP-Kern-Entwurf basiert. Die gefertigte integrierte Schaltung kann dafür konfiguriert sein, Operationen gemäß mindestens einer vorliegend beschriebenen Ausführungsform durchzuführen.
11B veranschaulicht eine seitliche Querschnittsansicht einer Package-Baugruppe 1170 für eine integrierte Schaltung gemäß einigen vorliegend beschriebenen Ausführungsformen. Die Package-Baugruppe 1170 für die integrierte Schaltung veranschaulicht eine Implementierung einer oder mehrerer Prozessor- oder Beschleunigereinrichtungen wie vorliegend beschrieben. Die Package-Baugruppe 1170 weist mehrere Hardwarelogikeinheiten 1172, 1174 auf, die mit einem Substrat 1180 verbunden sind. Die Logik 1172, 1174 kann zumindest teilweise in konfigurierbarer Logik oder Festfunktions-Logikhardware implementiert sein und kann einen oder mehrere Abschnitte eines der Prozessorkern(e), Grafikprozessor(en) oder anderen Beschleunigereinrichtungen wie vorliegend beschrieben umfassen. Jede Logikeinheit 1172, 1174 kann innerhalb eines Halbleiter-Dies implementiert und über eine Verbindungsstruktur 1173 mit dem Substrat 1180 gekoppelt sein. Die Verbindungsstruktur 1173 kann dafür konfiguriert sein, elektrische Signale zwischen der Logik 1172, 1174 und dem Substrat 1180 zu leiten, und kann Verbindungen wie beispielsweise, ohne jedoch hierauf eingeschränkt zu sein, Kontakthügel oder -säulen aufweisen. In einigen Ausführungsformen kann die Verbindungsstruktur 1173 dafür konfiguriert sein, elektrische Signale wie beispielsweise Eingangs-/Ausgangs- (E/A-) Signale und/oder Stromversorgungs- oder Erdungssignale, die mit dem Betrieb der Logik 1172, 1174 verbunden sind, zu leiten. In einigen Ausführungsformen handelt es sich bei dem Substrat 1180 um ein laminiertes Substrat auf Epoxidbasis. In anderen Ausführungsformen kann das Substrat 1180 andere geeignete Arten von Substraten umfassen. Die Package-Baugruppe 1170 kann über eine Package-Verbindung 1183 mit anderen elektrischen Einrichtungen verbunden sein. Die Package-Verbindung 1183 kann an eine Oberfläche des Substrats 1180 gekoppelt sein, um elektrische Signale an andere elektrische Einrichtungen wie beispielsweise ein Motherboard, einen anderen Chipsatz oder ein Mehrchipmodul zu leiten.
In einigen Ausführungsformen sind die Logikeinheiten 1172, 1174 elektrisch mit einer Brücke 1182 gekoppelt, die dafür konfiguriert ist, elektrische Signale zwischen der Logik 1172, 1174 zu leiten. Bei der Brücke 1182 kann es sich um eine dichte Verbindungsstruktur handeln, die einen Weg für elektrische Signale bereitstellt. Die Brücke 1182 kann ein aus Glas oder einem geeigneten Halbleitermaterial zusammengesetztes Brückensubstrat aufweisen. Auf dem Brückensubstrat können elektrische Leitungsmerkmale gebildet sein, um eine Chip-zu-Chip-Verbindung zwischen der Logik 1172, 1174 bereitzustellen.
Zwar sind zwei Logikeinheiten 1172, 1174 und eine Brücke 1182 veranschaulicht, jedoch können vorliegend beschriebene Ausführungsformen mehr oder weniger Logikeinheiten auf einem oder mehreren Dies aufweisen. Der eine oder die mehreren Dies können durch null oder mehr Brücken verbunden sein, da die Brücke 1182 wegfallen kann, wenn die Logik auf einem einzigen Die enthalten ist. Alternativ können mehrere Dies oder Logikeinheiten durch eine oder mehr Brücken verbunden sein. Zudem können mehrere Logikeinheiten, Dies und Brücken in anderen möglichen Konfigurationen zusammengeschlossen sein, einschließlich dreidimensionalen Konfigurationen.
11C veranschaulicht eine Package-Baugruppe 1190, die mehrere Einheiten aus Hardwarelogik-Chiplets aufweist, die mit einem Substrat 1180 (z.B. Basis-Die) verbunden sind. Eine Grafikverarbeitungseinheit, ein Parallelprozessor und/oder ein Rechenbeschleuniger wie vorliegend beschrieben können aus verschiedenen Silicium-Chiplets zusammengesetzt sein, die separat hergestellt werden. In diesem Kontext handelt es sich bei einem Chiplet um eine zumindest teilweise verpackte integrierte Schaltung, die einzelne Logikeinheiten aufweist und die mit anderen Chiplets zu einem größeren Package zusammengebaut werden kann. Ein vielfältiger Satz aus Chiplets mit unterschiedlicher IP-Kern-Logik kann zu einer einzigen Einrichtung zusammengebaut werden. Zusätzlich können die Chiplets mittels Active-Interposer-Technologie in einen Basis-Die oder ein Basis-Chiplet integriert werden. Die vorliegend beschriebenen Konzepte ermöglichen die Verbindung und Kommunikation zwischen den verschiedenen Formen von IP innerhalb der GPU. IP-Kerne können mit unterschiedlichen Prozesstechnologien hergestellt und während der Fertigung zusammengesetzt werden, wodurch die Komplexität der Konvergenz mehrerer IPs, insbesondere bei einem großen SoC mit mehreren verschiedenen IPs, auf denselben Fertigungsprozess vermieden wird. Die Verwendung mehrerer Prozesstechnologien verbessert die Markteinfiihrungszeit und bietet eine kostengünstige Möglichkeit, mehrere Produkt-SKUs zu erstellen. Zudem lassen sich die disaggregierten IPs besser unabhängig voneinander mit Strom versorgen, und Komponenten, die für eine bestimmte Arbeitslast nicht verwendet werden, können abgeschaltet werden, was den Gesamtstromverbrauch reduziert.
Die Hardwarelogik-Chiplets können Spezial-Hardwarelogik-Chiplets 1172, Logik- oder E/A-Chiplets 1174 und/oder Speicher-Chiplets 1175 umfassen. Die Hardwarelogik-Chiplets 1172 und Logik- oder E/A-Chiplets 1174 können zumindest teilweise in konfigurierbarer Logik oder Festfunktions-Logikhardware implementiert sein und können einen oder mehrere Abschnitte eines der Prozessorkern(e), Grafikprozessor(en), Parallelprozessoren oder anderen Beschleunigereinrichtungen wie vorliegend beschrieben umfassen. Bei den Speicher-Chiplets 1175 kann es sich um DRAM- (z.B. GDDR-, HBM-) Speicher oder Cache- (SRAM-) Speicher handeln.
Jedes Chiplet kann als separater Halbleiter-Die gefertigt und über eine Verbindungsstruktur 1173 mit dem Substrat 1180 gekoppelt werden. Die Verbindungsstruktur 1173 kann dafür konfiguriert sein, elektrische Signale zwischen den verschiedenen Chiplets und der Logik innerhalb des Substrats 1180 zu leiten. Die Verbindungsstruktur 1173 kann Verbindungen wie beispielsweise, ohne jedoch hierauf eingeschränkt zu sein, Kontakthügel oder -säulen umfassen. In einigen Ausführungsformen kann die Verbindungsstruktur 1173 dafür konfiguriert sein, elektrische Signale wie beispielsweise Eingangs-/Ausgangs- (E/A-) Signale und/oder Stromversorgungs- oder Erdungssignale, die mit dem Betrieb der Logik-, E/A- und Speicher-Chiplets verbunden sind, zu leiten.
In einigen Ausführungsformen handelt es sich bei dem Substrat 1180 um ein laminiertes Substrat auf Epoxidbasis. In anderen Ausführungsformen kann das Substrat 1180 andere geeignete Arten von Substraten umfassen. Die Package-Baugruppe 1190 kann über eine Package-Verbindung 1183 mit anderen elektrischen Einrichtungen verbunden sein. Die Package-Verbindung 1183 kann an eine Oberfläche des Substrats 1180 gekoppelt sein, um elektrische Signale an andere elektrische Einrichtungen wie beispielsweise ein Motherboard, einen anderen Chipsatz oder ein Mehrchipmodul zu leiten.
In einigen Ausführungsformen können ein Logik- oder E/A-Chiplet 1174 und ein Speicher-Chiplet 1175 elektrisch über eine Brücke 1187 gekoppelt sein, die dafür konfiguriert ist, elektrische Signale zwischen dem Logik- oder E/A-Chiplet 1174 und einem Speicher-Chiplet 1175 zu leiten. Bei der Brücke 1187 kann es sich um eine dichte Verbindungsstruktur handeln, die einen Weg für elektrische Signale bereitstellt. Die Brücke 1187 kann ein aus Glas oder einem geeigneten Halbleitermaterial zusammengesetztes Brückensubstrat aufweisen. Auf dem Brückensubstrat können elektrische Leitungsmerkmale gebildet sein, um eine Chip-zu-Chip-Verbindung zwischen dem Logik- oder E/A-Chiplet 1174 und einem Speicher-Chiplet 1175 bereitzustellen. Die Brücke 1187 kann auch als Siliciumbrücke oder Interconnect-Brücke bezeichnet werden. Beispielsweise handelt es sich bei der Brücke 1187 in einigen Ausführungsformen um eine Embedded Multi-Die Interconnect Bridge (EMIB). In einigen Ausführungsformen kann es sich bei der Brücke 1187 schlicht um eine direkte Verbindung von einem Chiplet zu einem anderen Chiplet handeln.
Das Substrat 1180 kann Hardwarekomponenten für E/A- 1191, Cachespeicher- 1192 und andere Hardwarelogik 1193 handeln. In das Substrat 1180 kann ein Fabric 1185 eingebettet sein, um Kommunikation zwischen den verschiedenen Logik-Chiplets und der Logik 1191, 1193 innerhalb des Substrats 1180 zu ermöglichen. In einer Ausführungsform können die E/A- 1191, Fabric- 1185, Cache-, Brücken- und andere Hardwarelogik 1193 in einen Basis-Die integriert sein, der auf das Substrat 1180 aufgeschichtet ist.
In verschiedenen Ausführungsformen kann eine Package-Baugruppe 1190 eine kleinere oder größere Anzahl an Komponenten und Chiplets aufweisen, die durch ein Fabric 1185 oder eine oder mehrere Brücken 1187 untereinander verbunden sind. Die Chiplets innerhalb der Package-Baugruppe 1190 können in einer 3D- oder 2,5D-Anordnung angeordnet sein. Grundsätzlich können Brückenstrukturen 1187 verwendet werden, um eine Punkt-zu-Punkt-Verbindung zwischen beispielsweise Logik- oder E/A-Chiplets und Speicherchiplets zu erleichtern. Das Fabric 1185 kann verwendet werden, um die verschiedenen Logik- und/oder E/A-Chiplets (z.B. Chiplets 1172, 1174, 1191, 1193) mit anderen Logik- und/oder E/A-Chiplets zu verbinden. In einer Ausführungsform kann der Cachespeicher 1192 innerhalb des Substrats als globaler Cache für die Package-Baugruppe 1190, Teil eines verteilten globalen Caches oder als dedizierter Cache für das Fabric 1185 fungieren.
11D veranschaulicht eine Package-Baugruppe 1194 mit austauschbaren Chiplets 1195 gemäß einer Ausführungsform. Die austauschbaren Chiplets 1195 können in standardisierte Slots auf einem oder mehreren Basis-Chiplets 1196, 1198 montiert werden. Die Basis-Chiplets 1196, 1198 können über eine Brückenverbindung 1197 gekoppelt werden, die den anderen vorliegend beschriebenen Brückenverbindungen ähneln und beispielsweise eine EMIB sein kann. Zudem können Speicher-Chiplets über eine Brückenverbindung mit Logik- oder E/A-Chiplets verbunden werden. E/A- und Logik-Chiplets können über ein Verbindungs-Fabric kommunizieren. Die Basis-Chiplets können jeweils einen oder mehrere Slots in einem standardisierten Format für Logik oder E/A oder Speicher/Cache unterstützen.
In einer Ausführungsform können SRAM- und Stromversorgungsschaltungen in einem oder mehreren der Basis-Chiplets 1196, 1198 hergestellt werden, die mit einer anderen Prozesstechnologie hergestellt werden können als die austauschbaren Chiplets 1195, die auf die Basis-Chiplets gestapelt werden. Beispielsweise können die Basis-Chiplets 1196, 1198 mittels einer größeren Prozesstechnologie gefertigt werden, während die austauschbaren Chiplets mittels einer kleineren Prozesstechnologie hergestellt werden können. Bei einem oder mehreren der austauschbaren Chiplets 1195 kann es sich um Speicher- (z.B. DRAM-) Chiplets handeln. Für die Package-Baugruppe 1194 können unterschiedliche Speicherdichten ausgewählt werden, je nach der angestrebten Leistung und/oder Performance für das Produkt, das die Package-Baugruppe 1194 verwendet. Zudem können zum Zeitpunkt der Montage je nach der für das Produkt angestrebten Leistung und/oder Performance Logik-Chiplets mit einer anderen Anzahl verschiedener Arten von Funktionseinheiten ausgewählt werden. Zusätzlich können Chiplets, die IP-Logikkerne unterschiedlicher Typen enthalten, in die austauschbaren Chiplet-Slots eingesetzt werden, was hybride Prozessor-Designs ermöglicht, die IP-Blöcke verschiedener Technologien mischen und anpassen können.
Beispielhafte integrierte Ein-Chip-System-Schaltung
12 bis 13 veranschaulichen beispielhafte integrierte Schaltungen und zugehörige Grafikprozessoren, die mittels eines oder mehrerer IP-Kerne gefertigt werden können, gemäß verschiedenen vorliegend beschriebenen Ausführungsformen. Zusätzlich zum Dargestellten können andere Logik und Schaltungen umfasst sein, darunter zusätzliche Grafikprozessoren/-kerne, Peripherieschnittstellen-Controller oder Allzweck-Prozessorkerne.
12 ist ein Blockschaubild, das eine beispielhafte integrierte Ein-Chip-System-Schaltung 1200, die mittels eines oder mehrerer IP-Kerne gefertigt werden kann, gemäß einer Ausführungsform veranschaulicht. Die beispielhafte integrierte Schaltung 1200 weist einen oder mehrere Anwendungsprozessoren 1205 (z.B. CPUs) und mindestens einen Grafikprozessor 1210 auf und kann zusätzlich einen Bildprozessor 1215 und/oder einen Videoprozessor 1220 aufweisen, bei denen es sich jeweils um einen modularen IP-Kern aus der gleichen oder aus mehreren verschiedenen Entwurfseinrichtungen handeln kann. Die integrierte Schaltung 1200 weist Peripherie- oder Buslogik einschließlich eines USB-Controllers 1225, eines UART-Controllers 1230, eines SPI/SDIO-Controllers 1235 und eines I²S/I²C-Controllers 1240 auf. Zusätzlich kann die integrierte Schaltung eine Anzeigeeinrichtung 1245 aufweisen, die an einen High-Definition-Multimedia-Interface- (HDMI-) Controller 1250 und/oder eine Mobile-Industry-Processor-Interface- (MIPI-) Anzeigeschnittstelle 1255 gekoppelt ist. Speicherung kann durch ein Flashspeicher-Teilsystem 1260 bereitgestellt werden, das Flashspeicher und einen Flashspeicher-Controller aufweist. Für Zugriff auf SDRAM- oder SRAM-Speichereinrichtungen kann eine Speicherschnittstelle über einen Speichercontroller 1265 bereitgestellt werden. Einige integrierte Schaltungen weisen zusätzlich eine eingebettete Sicherheits-Engine 1270 auf.
13A bis 13B sind Blockschaubilder, die beispielhafte Grafikprozessoren zur Verwendung in einem SoC gemäß vorliegend beschriebenen Ausführungsformen veranschaulichen. 13A veranschaulicht einen beispielhaften Grafikprozessor 1310 einer integrierten Ein-Chip-System-Schaltung, die mittels eines oder mehrerer IP-Kerne gefertigt werden kann, gemäß einer Ausführungsform. 13B veranschaulicht einen weiteren beispielhaften Grafikprozessor 1340 einer integrierten Ein-Chip-System-Schaltung, die mittels eines oder mehrerer IP-Kerne gefertigt werden kann, gemäß einer Ausführungsform. Bei dem Grafikprozessor 1310 aus 13A handelt es sich um ein Beispiel eines Grafikprozessorkerns mit geringem Stromverbrauch. Bei dem Grafikprozessor 1340 aus 13B handelt es sich um ein Beispiel eines Grafikprozessorkerns mit höherer Leistung. Bei jedem der Grafikprozessoren 1310, 1340 kann es sich um Varianten des Grafikprozessors 1210 aus 12 handeln.
Wie in 13A gezeigt, weist der Grafikprozessor 1310 einen VertexProzessor 1305 und einen oder mehrere Fragmentprozessoren 1315A bis 1315N (z.B. 1315A, 1315B, 1315C, 1315D bis 1315N-1 und 1315N) auf. Der Grafikprozessor 1310 kann über separate Logik verschiedene Schattierprogramme ausführen, so dass der Vertexprozessor 1305 dafür optimiert ist, Operationen für Vertexschattierprogramme auszuführen, während der eine oder die mehreren Fragmentprozessoren 1315A bis 1315N Fragment- (z.B. Pixel-) Schattieroperationen für Fragment- oder Pixelschattierprogramme ausführen. Der Vertexprozessor 1305 führt die Vertexverarbeitungsstufe der 3D-Grafikpipeline durch und erzeugt Primitive- und Vertexdaten. Der oder die Fragmentprozessoren 1315A bis 1315N verwenden die vom Vertexprozessor 1305 erzeugten Primitiv- und Vertexdaten, um einen Rahmenpuffer zu erzeugen, der auf einer Anzeigeeinrichtung angezeigt wird. In einer Ausführungsform sind der oder die Fragmentprozessoren 1315A bis 1315N für die Ausführung von Fragmentschattierprogrammen optimiert, wie sie in der OpenGL-API vorgesehen sind, die verwendet werden können, um ähnliche Operationen wie ein Pixelschattierprogramm durchzuführen, wie es in der Direct-3D-APIvorgesehen ist.
Der Grafikprozessor 1310 weist zusätzlich eine oder mehrere Speicherverwaltungseinheiten (Memory Management Units, MMUs) 1320A bis 1320B, einen oder mehrere Caches 1325A bis 1325B und eine oder mehrere Schaltungsverbindungen 1330A bis 1330B auf. Die eine oder die mehreren MMUs 1320A bis 1320B sorgen für Abbildung virtueller auf physische Adressen für den Grafikprozessor 1310, darunter für den Vertexprozessor 1305 und/oder den oder die Fragmentprozessoren 1315A bis 1315N, der zusätzlich zu in dem einen oder den mehreren Caches 1325A bis 1325B gespeicherten Vertex- oder Bild-/Texturdaten im Speicher gespeicherte Vertex oder Bild-/Texturdaten referenzieren kann. In einer Ausführungsform können die eine oder die mehreren MMUs 1320A bis 1320B mit anderen MMUs innerhalb des Systems synchronisiert werden, darunter eine oder mehrere MMUs, die zu dem einen oder den mehreren Anwendungsprozessoren 1205, dem Bildprozessor 1215 und/oder dem Videoprozessor 1220 aus 12 gehören, so dass jeder Prozessor 1205 bis 1220 an einem gemeinsam genutzten oder vereinheitlichten virtuellen Speichersystem teilhaben kann. Die eine oder die mehreren Schaltungsverbindungen 1330A bis 1330B ermöglichen es dem Grafikprozessor 1310, sich mit anderen IP-Kernen innerhalb des SoC zu verbinden, entweder über einen internen Bus des SoC oder über eine direkte Verbindung, je nach Ausführungsform.
Wie in 13B gezeigt, weist der Grafikprozessor 1340 die eine oder die mehreren MMUs 1320A bis 1320B, den einen oder die mehreren Caches 1325A bis 1325B und die eine oder die mehreren Schaltungsverbindungen 1330A bis 1330B des Grafikprozessors 1310 aus 13A auf. Der Grafikprozessor 1340 umfasst einen oder mehrere Shader-Kerne 1355A bis 1355N (z.B. 1455A, 1355B, 1355C, 1355D, 1355E, 1355F bis 1355N-1 und 1355N), wodurch eine einheitliche Shader-Kern-Architektur bereitgestellt wird, bei der ein einziger Kern oder Typ oder Kern alle Arten von programmierbarem Shader-Code ausführen kann, einschließlich Schattierprogrammcode zur Implementierung von Vertex-Shadern, Fragment-Shadern und/oder Rechen-Shadern. Die genaue Anzahl vorhandener Shader-Kerne kann in verschiedenen Ausführungsformen und Implementierungen variieren. Zusätzlich umfasst der Grafikprozessor 1340 einen Inter-Core-Task-Manager 1345, der als Thread-Dispatcher fungiert, um Ausführungs-Threads an einen oder mehrere Shader-Kerne 1355A bis 1355N zu verteilen, sowie eine Kachel-Einheit 1358 zur Beschleunigung von Kacheloperationen für das kachelbasierte Rendering, bei dem Rendering-Operationen für eine Szene im Bildraum unterteilt werden, um beispielsweise die lokale räumliche Kohärenz innerhalb einer Szene auszunutzen oder die Nutzung interner Caches zu optimieren.
Übersicht maschinelles Lernen
Ein Algorithmus für maschinelles Lernen ist ein Algorithmus, der auf Grundlage eines Datensatzes lernen kann. Ausführungsformen von Algorithmen für maschinelles Lernen können dafür konzipiert sein, hochgradige Abstraktionen innerhalb eines Datensatzes zu modellieren. Zum Beispiel können Bilderkennungsalgorithmen verwendet werden, um zu bestimmen, zu welcher von mehreren Kategorien eine gegebene Eingabe gehört, Regressionsalgorithmen können einen numerischen Wert angesichts einer Eingabe ausgeben, und Mustererkennungsalgorithmen können verwendet werden, um übersetzten Text zu generieren oder Text-zu-Sprache und/oder Spracherkennung durchzuführen.
Ein beispielhafter Typ eines Algorithmus für maschinelles Lernen ist ein neuronales Netz. Es gibt viele Arten von neuronalen Netzen; ein einfacher Typ von neuronalen Netzen ist ein Feedforward-Netz. Ein Feedforward-Netz kann als azyklischer Graph implementiert werden, in dem die Knoten in Schichten angeordnet sind. Typischerweise umfasst eine Feedforward-Netztopologie eine Eingabeschicht und eine Ausgabeschicht, die durch mindestens eine verborgene Schicht getrennt sind. Die verborgene Schicht wandelt durch die Eingabeschicht empfangene Eingaben in eine Repräsentation um, die zum Generieren von Ausgaben in der Ausgabeschicht von Nutzen ist. Die Netzknoten sind über Kanten zu den Knoten in angrenzenden Schichten vollständig verbunden, jedoch gibt es zwischen Knoten innerhalb jeder Schicht keine Kanten. Daten, die an den Knoten einer Eingabeschicht eines Feedforward-Netzes empfangen werden, werden über eine Aktivierungsfunktion, die die Zustände der Knoten jeder aufeinanderfolgenden Schicht im Netz auf der Grundlage von Koeffizienten („Gewichtungen“) berechnet, die jeweils mit jeder der die Schichten verbindenden Kanten verbunden sind, an die Knoten der Ausgabeschicht propagiert (d.h. „vorwärtsgeführt‟). Je nach dem durch den ausgeführten Algorithmus repräsentierten konkreten Modell können die Ausgaben aus dem Algorithmus des neuronalen Netzes verschiedene Formen annehmen.
Bevor ein Algorithmus für maschinelles Lernen verwendet werden kann, um ein bestimmtes Problem zu modellieren, wird der Algorithmus mittels eines Trainingsdatensatzes trainiert. Das Training eines neuronalen Netzes beinhaltet die Auswahl einer Netztopologie, die Verwendung eines Satzes von Trainingsdaten, die ein Problem darstellen, das durch das Netz modelliert wird, und die Anpassung der Gewichtungen, bis das Netzmodell mit einem minimalen Fehler für alle Instanzen des Trainingsdatensatzes arbeitet. Zum Beispiel wird während eines Trainingsprozesses mit überwachtem Lernen für ein neuronales Netz die Ausgabe, die durch das Netz als Reaktion auf die eine Instanz in einem Trainingsdatensatz darstellende Eingabe erzeugt wird, mit der als „korrekt“ gekennzeichneten Ausgabe für diese Instanz verglichen, ein Fehlersignal, das die Differenz zwischen der Ausgabe und der gekennzeichneten Ausgabe darstellt, wird berechnet, und die Gewichtungen, die mit den Verbindungen verbunden sind, werden angepasst, um diesen Fehler zu minimieren, während das Fehlersignal rückwärts durch die Schichten des Netzes propagiert wird. Das Netz wird als „trainiert“ betrachtet, wenn die Fehler für jede der aus den Instanzen des Trainingsdatensatzes erzeugten Ausgaben minimiert sind.
Die Genauigkeit eines Algorithmus für maschinelles Lernen kann erheblich von der Qualität des zum Trainieren des Algorithmus verwendeten Datensatzes beeinflusst werden. Der Trainingsprozess kann rechenintensiv sein und auf einem herkömmlichen Allzweckprozessor eine erhebliche Zeitspanne in Anspruch nehmen. Dementsprechend wird Parallelverarbeitungshardware zum Trainieren vieler Arten von Algorithmen für maschinelles Lernen verwendet. Dies ist besonders nützlich für die Optimierung des Trainings von neuronalen Netzen, da sich die Berechnungen, die bei der Anpassung der Koeffizienten in neuronalen Netzen durchgeführt werden, natürlich für parallele Implementierungen eignen. Insbesondere wurden viele Algorithmen und Softwareanwendungen für maschinelles Lernen so angepasst, dass sie die Parallelverarbeitungshardware in Allzweck-Grafikverarbeitungseinrichtungen nutzen können.
14 ist ein verallgemeinertes Schaubild eines Software-Stacks 1400 für maschinelles Lernen. Eine Maschinenlemanwendung 1402 kann so konfiguriert werden, dass sie ein neuronales Netz anhand eines Trainingsdatensatzes trainiert oder ein trainiertes tiefes neuronales Netz verwendet, um maschinelle Intelligenz zu implementieren. Die Maschinenlemanwendung 1402 kann Trainings- und Inferenzfunktionen für ein neuronales Netz und/oder spezialisierte Software enthalten, die zum Trainieren eines neuronalen Netzes vor dem Einsatz verwendet werden kann. Die Maschinelernanwendung 1402 kann jede Art von maschineller Intelligenz implementieren, einschließlich, ohne jedoch hierauf eingeschränkt zu sein, Bilderkennung, Kartierung und Lokalisierung, autonome Navigation, Sprachsynthese, medizinische Bildgebung oder Sprachübersetzung.
Die Hardwarebeschleunigung für die Maschinenlemanwendung 1402 kann über ein Maschinenlern-Framework 1404 aktiviert werden. Das Maschinenlern-Framework 1404 kann eine Bibliothek mit Primitiven für maschinelles Lernen bereitstellen. Primitive für maschinelles Lernen sind grundlegende Operationen, die häufig von Algorithmen für maschinelles Lernen ausgeführt werden. Ohne das Framework 1404 für maschinelles Lernen müssten Entwickler von Algorithmen für maschinelles Lernen die mit dem Algorithmus für maschinelles Lernen verbundene Hauptrechenlogik erstellen und optimieren und dann die Rechenlogik erneut optimieren, wenn neue Parallelprozessoren entwickelt werden. Stattdessen kann die Maschinenlemanwendung so konfiguriert werden, dass sie die erforderlichen Berechnungen unter Verwendung der vom Framework 1404 für maschinelles Lernen bereitgestellten Primitive durchführt. Zu beispielhaften Primitiven gehören Tensorfaltungen, Aktivierungsfunktionen und Pooling, d.h. Rechenoperationen, die während des Trainings eines neuronalen Faltungsnetzes (Convolutional Neural Network, CNN) durchgeführt werden. Das Framework 1404 für maschinelles Lernen kann auch Primitive bereitstellen, um grundlegende Teilprogramme für lineare Algebra zu implementieren, die von vielen Algorithmen für maschinelles Lernen ausgeführt werden, wie beispielsweise Matrix- und Vektoroperationen.
Das Framework 1404 für maschinelles Lernen kann von der Anwendung 1402 für maschinelles Lernen empfangene Eingabedaten verarbeiten und die entsprechende Eingabe für ein Rechen-Framework 1406 erzeugen. Das Rechen-Framework 1406 kann die zugrunde liegenden Anweisungen abstrahieren, die dem GPGPU-Treiber 1408 zur Verfügung gestellt werden, um es dem Framework 1404 für maschinelles Lernen zu ermöglichen, die Vorteile der Hardwarebeschleunigung über die GPGPU-Hardware 1410 zu nutzen, ohne dass das Framework 1404 für maschinelles Lernen genaue Kenntnisse über die Architektur der GPGPU-Hardware 1410 haben muss. Zusätzlich kann das Rechen-Framework 1406 Hardwarebeschleunigung für das Framework 1404 für maschinelles Lernen über eine Vielzahl von Typen und Generationen der GPGPU-Hardware 1410 ermöglichen.
Implementierungen Neuronaler Netze für Maschinelles Lernen
Die Computerarchitektur, die durch vorliegend beschriebene Ausführungsformen bereitgestellt wird, kann dafür konfiguriert sein, die Arten von Parallelverarbeitung durchführt, die sich besonders für das Training und den Einsatz neuronaler Netze für maschinelles Lernen eignen. Ein neuronales Netz kann als ein Netz aus Funktionen verallgemeinert werden, die in einer Graphenbeziehung stehen. Wie im Fachgebiet bekannt ist, gibt es viele Arten der Implementierung neuronaler Netze, die beim maschinellen Lernen verwendet werden. Ein beispielhafter Typ eines neuronalen Netzes ist das Feedforward-Netz, wie zuvor beschrieben.
Ein zweiter beispielhafter Typ eines neuronalen Netzes ist das neuronale Faltungsnetz (CNN). Ein CNN ist ein spezialisiertes neuronales Feedforward-Netz zur Verarbeitung von Daten mit einer bekannten, gitterartigen Topologie, wie beispielsweise Bilddaten. Dementsprechend werden CNNs üblicherweise für die Berechnung von Bildverarbeitungs- und Bilderkennungsanwendungen eingesetzt, sie können aber auch für andere Arten der Mustererkennung wie beispielsweise die Verarbeitung gesprochener und geschriebener Sprache verwendet werden. Die Knoten in der CNN-Eingabeschicht sind in einem Satz von „Filtern“ organisiert (Merkmalsdetektoren, die von den rezeptiven Feldern in der Netzhaut inspiriert sind), und die Ausgabe jedes Satzes von Filtern wird an Knoten in aufeinanderfolgenden Schichten des Netzes propagiert. Die Berechnungen für ein CNN umfassen die Anwendung der mathematischen Operation „Faltung“ auf jedes Filter, um die Ausgabe dieses Filters zu erzeugen. Die Faltung ist eine spezielle Art der mathematischen Operation, bei der zwei Funktionen eine dritte Funktion erzeugen, die eine modifizierte Version einer der beiden ursprünglichen Funktionen ist. In der Terminologie von Faltungsnetzen kann die erste Funktion der Faltung als Eingabe bezeichnet werden, während die zweite Funktion als Faltungskernel bezeichnet werden kann. Die Ausgabe kann als Merkmalskarte bezeichnet werden. Die Eingabe für eine Faltungsschicht kann beispielsweise ein mehrdimensionales Array von Daten sein, das die verschiedenen Farbkomponenten eines Eingabebilds definiert. Der Faltungskernel kann ein mehrdimensionales Array von Parametern sein, wobei die Parameter durch den Trainingsprozess für das neuronale Netz angepasst werden.
Rekurrente neuronale Netze (RNNs) sind eine Familie von neuronalen Feedforward-Netzen, die Feedback-Verbindungen zwischen Schichten umfassen. RNNs ermöglichen die Modellierung sequenzieller Daten, indem sie Parameterdaten über verschiedene Teile des neuronalen Netzes hinweg teilen. Die Architektur für ein RNN weist Zyklen auf. Die Zyklen stellen den Einfluss eines gegenwärtigen Wertes einer Variablen auf ihren eigenen Wert zu einem zukünftigen Zeitpunkt dar, da zumindest ein Teil der Ausgabedaten des RNN als Feedback für die Verarbeitung nachfolgender Eingaben in einer Sequenz verwendet wird. Diese Eigenschaft macht RNNs besonders nützlich für die Sprachverarbeitung, da Sprachdaten sehr variabel zusammengesetzt sein können.
Die nachfolgenden Figuren zeigen beispielhafte Feedforward-, CNN- und RNN-Netze und beschreiben einen allgemeinen Prozess für das jeweilige Training und den Einsatz jedes dieser Netztypen. Es versteht sich, dass diese Beschreibungen beispielhaft und nicht einschränkend für jede vorliegend beschriebene konkrete Ausführungsform sind und die dargestellten Konzepte grundsätzlich auf tiefe neuronale Netze und Methoden des maschinellen Lernens im Allgemeinen angewendet werden können.
Die vorstehend beschriebenen beispielhaften neuronalen Netze können verwendet werden, um Deep Learning durchzuführen. Deep Leaming ist maschinelles Lernen mit tiefen neuronalen Netzen. Die beim Deep Learning verwendeten tiefen neuronalen Netze sind künstliche neuronale Netze, die aus mehreren verborgenen Schichten bestehen, im Gegensatz zu flachen neuronalen Netzen, die nur eine einzige verborgene Schicht aufweisen. Tiefere neuronale Netze sind im Allgemeinen rechenintensiver zu trainieren. Die zusätzlichen verborgenen Schichten des Netzes ermöglichen jedoch eine mehrstufige Mustererkennung, die im Vergleich zu flachen maschinellen Lernverfahren zu einem geringeren Ausgabefehler führt.
Tiefe neuronale Netze, die beim Deep Learning verwendet werden, umfassen typischerweise ein Front-End-Netz zur Durchführung der Merkmalserkennung, das mit einem Back-End-Netz gekoppelt ist, das ein mathematisches Modell darstellt, das Operationen (z.B. Objektklassifizierung, Spracherkennung usw.) auf Grundlage der dem Modell bereitgestellten Merkmalsdarstellung durchführen kann. Deep Learning ermöglicht maschinelles Lernen, ohne dass für das Modell eine manuelle Merkmalskonstruktion durchgeführt werden muss. Stattdessen können tiefe neuronale Netze Merkmale basierend auf statistischen Strukturen oder Korrelationen innerhalb der Eingabedaten lernen. Die gelernten Merkmale können einem mathematischen Modell bereitgestellt werden, das die erkannten Merkmale auf eine Ausgabe abbilden kann. Das mathematische Modell, das vom Netzwerk verwendet wird, ist in der Regel auf die jeweilige Aufgabe spezialisiert, und es werden unterschiedliche Modelle für unterschiedliche Aufgaben verwendet.
Sobald das neuronale Netz strukturiert ist, kann ein Lernmodell auf das Netz angewendet werden, um das Netz für die Ausführung bestimmter Aufgaben zu trainieren. Das Lernmodell beschreibt, wie die Gewichtungen innerhalb des Modells angepasst werden, um den Ausgabefehler des Netzes zu verringern. Rückwärtspropagation von Fehlern ist ein gängiges Verfahren zum Trainieren neuronaler Netze. Ein Eingabevektor wird dem Netz zur Verarbeitung bereitgestellt. Die Ausgabe des Netzes wird mit Hilfe einer Verlustfunktion mit der gewünschten Ausgabe verglichen, und für jedes der Neuronen in der Ausgabeschicht wird ein Fehlerwert berechnet. Die Fehlerwerte werden dann rückwärts propagiert, bis jedes Neuron einen zugehörigen Fehlerwert hat, der in etwa seinen Beitrag zur ursprünglichen Ausgabe darstellt. Das Netz kann dann aus diesen Fehlern lernen, indem es einen Algorithmus wie beispielsweise den stochastischen Gradientenabstiegsalgorithmus verwendet, um die Gewichtungen des neuronalen Netzes zu aktualisieren.
15A bis 15B veranschaulichen ein beispielhaftes neuronales Faltungsnetz. 15A veranschaulicht verschiedene Schichten innerhalb eines CNN. Wie in 15A gezeigt, kann ein beispielhaftes CNN, das zur Modellierung der Bildverarbeitung verwendet wird, eine Eingabe 1502 empfangen, die die Rot-, Grün- und Blau- (RGB-) Komponenten eines Eingabebilds beschreibt. Die Eingabe 1502 kann von mehreren Faltungsschichten verarbeitet werden (z.B. erste Faltungsschicht 1504, zweite Faltungsschicht 1506). Die Ausgabe der mehreren Faltungsschichten kann wahlweise von einem Satz vollständig verbundener Schichten 1508 verarbeitet werden. Neuronen in einer vollständig verbundenen Schicht haben vollständige Verbindungen zu allen Aktivierungen in der vorherigen Schicht, wie vorstehend für ein Feedforward-Netz beschrieben. Die Ausgabe der vollständig verbundenen Schichten 1508 kann verwendet werden, um ein Ausgabeergebnis des Netzes zu erzeugen. Die Aktivierungen innerhalb der vollständig verbundenen Schichten 1508 können durch Matrixmultiplikation statt durch Faltung berechnet werden. Nicht alle CNN-Implementierungen verwenden vollständig verbundene Schichten 1508. In einigen Implementierungen kann zum Beispiel die zweite Faltungsschicht 1506 die Ausgabe für das CNN erzeugen.
Die Faltungsschichten sind spärlich verbunden, was sich von der traditionellen Konfiguration neuronaler Netze unterscheidet, die in den voll verbundenen Schichten 1508 zu finden ist. Traditionelle neuronale Netzschichten sind vollständig verbunden, so dass jede Ausgabeeinheit mit jeder Eingabeeinheit interagiert. Die Faltungsschichten sind jedoch spärlich verbunden, da die Ausgabe der Faltung eines Feldes (anstelle des jeweiligen Statuswertes jedes der Knoten im Feld) in die Knoten der nachfolgenden Schicht eingegeben wird, wie dargestellt. Die zu den Faltungsschichten gehörenden Kernel führen Faltungsoperationen durch, deren Ausgabe an die nächste Schicht gesendet wird. Die Dimensionalitätsreduktion, die innerhalb der Faltungsschichten durchgeführt wird, ist ein Aspekt, der es dem CNN ermöglicht, zur Verarbeitung großer Bilder zu skalieren.
15B zeigt beispielhafte Rechenstufen innerhalb einer Faltungsschicht eines CNN. Die Eingabe in eine Faltungsschicht 1512 eines CNN kann in drei Stufen einer Faltungsschicht 1514 verarbeitet werden. Die drei Stufen können eine Faltungsstufe 1516, eine Detektorstufe 1518 und eine Pooling-Stufe 1520 umfassen. Die Faltungsschicht 1514 kann dann Daten an eine nachfolgende Faltungsschicht ausgeben. Die letzte Faltungsschicht des Netzes kann Ausgabe-Merkmalskartendaten generieren oder Eingaben für eine vollständig verbundene Schicht bereitstellen, beispielsweise um einen Klassifizierungswert für die Eingabe in das CNN zu erzeugen.
In der Faltungsstufe 1516 werden mehrere Faltungen parallel durchgeführt, um einen Satz linearer Aktivierungen zu erzeugen. Die Faltungsstufe 1516 kann eine affine Transformation enthalten, d.h. eine beliebige Transformation, die als lineare Transformation plus eine Translation angegeben werden kann. Affine Transformationen umfassen Rotationen, Translationen, Skalierungen und Kombinationen dieser Transformationen. Die Faltungsstufe berechnet die Ausgabe von Funktionen (z.B. Neuronen), die mit bestimmten Regionen in der Eingabe verbunden sind, die als die dem Neuron zugeordnete lokale Region bestimmt werden können. Die Neuronen berechnen ein Punktprodukt zwischen den Gewichtungen der Neuronen und der Region in der lokalen Eingabe, mit der die Neuronen verbunden sind. Die Ausgabe der Faltungsstufe 1516 definiert einen Satz linearer Aktivierungen, die von aufeinanderfolgenden Stufen der Faltungsschicht 1514 verarbeitet werden.
Die linearen Aktivierungen können von einer Detektorstufe 1518 verarbeitet werden. In der Detektorstufe 1518 wird jede lineare Aktivierung durch eine nichtlineare Aktivierungsfunktion verarbeitet. Die nichtlineare Aktivierungsfunktion erhöht die nichtlinearen Eigenschaften des Gesamtnetzes, ohne die rezeptiven Felder der Faltungsschicht zu beeinflussen. Es können verschiedene Arten von nichtlinearen Aktivierungsfunktionen verwendet werden. Ein spezieller Typ ist die gleichgerichtete lineare Einheit (Rectified Linear Unit, ReLU), die eine Aktivierungsfunktion verwendet, die als f(x) = max(0, x) definiert ist, so dass die Aktivierung bei Null begrenzt wird.
Die Pooling-Stufe 1520 verwendet eine Pooling-Funktion, die die Ausgabe der zweiten Faltungsschicht 1506 durch eine zusammenfassende Statistik der nahegelegenen Ausgaben ersetzt. Die Pooling-Funktion kann verwendet werden, um Translationsinvarianz in das neuronale Netz einzuführen, so dass kleine Translationen der Eingabe die gepoolten Ausgaben nicht verändern. Die Invarianz gegenüber lokaler Translation kann in Szenarien nützlich sein, in denen das Vorhandensein eines Merkmals in den Eingabedaten wichtiger ist als die genaue Position des Merkmals. Während der Pooling-Stufe 1520 können verschiedene Arten von Pooling-Funktionen verwendet werden, darunter Max-Pooling, Average-Pooling und L2-Norm-Pooling. Zudem weisen einige CNN-Implementierungen keine Pooling-Stufe auf. Stattdessen ersetzen solche Implementierungen eine zusätzliche Faltungsstufe, die eine erhöhte Schrittweite relativ zu den vorherigen Faltungsstufen hat.
Die Ausgabe der Faltungsschicht 1514 kann dann von der nächsten Schicht 1522 verarbeitet werden. Die nächste Schicht 1522 kann eine zusätzliche Faltungsschicht oder eine der vollständig verbundenen Schichten 1508 sein. Zum Beispiel kann die erste Faltungsschicht 1504 aus 15A an die zweite Faltungsschicht 1506 ausgegeben werden, während die zweite Faltungsschicht an eine erste Schicht der vollständig verbundenen Schichten 1508 ausgegeben werden kann.
16 veranschaulicht ein beispielhaftes rekurrentes neuronales Netz. In einem rekurrenten neuronalen Netz (RNN) beeinflusst der vorherige Status des Netzes die Ausgabe des aktuellen Status des Netzes. RNNs können auf verschiedene Weise mit verschiedenen Funktionen aufgebaut werden. Bei der Verwendung von RNNs geht es im Allgemeinen um die Verwendung mathematischer Modelle zur Vorhersage der Zukunft auf Grundlage einer vorherigen Sequenz von Eingaben. Ein RNN kann beispielsweise zur statistischen Sprachmodellierung verwendet werden, um ein kommendes Wort anhand einer vorherigen Wortfolge vorherzusagen. Das abgebildete RNN 1600 kann so beschrieben werden, dass es eine Eingabeschicht 1602, die einen Eingabevektor empfängt, verborgene Schichten 1604, um eine rekurrente Funktion zu implementieren, einen Feedback-Mechanismus 1605, um einen „Speicher“ für vorherige Status zu ermöglichen, und eine Ausgabeschicht 1606 hat, um ein Ergebnis auszugeben. Das RNN 1600 arbeitet auf Grundlage von Zeitschritten. Der Status des RNN zu einem bestimmten Zeitschritt wird auf Grundlage des vorherigen Zeitschritts über den Feedback-Mechanismus 1605 beeinflusst. Für einen bestimmten Zeitschritt wird der Status der verborgenen Schichten 1604 durch den vorherigen Status und die Eingabe im aktuellen Zeitschritt definiert. Eine anfängliche Eingabe (x₁) in einem ersten Zeitschritt kann von der verborgenen Schicht 1604 verarbeitet werden. Eine zweite Eingabe (x₂) kann von der verborgenen Schicht 1604 unter Verwendung von Zustandsinformationen verarbeitet werden, die bei der Verarbeitung der anfänglichen Eingabe (x₁) bestimmt wurden. Ein gegebener Status kann berechnet werden als s_t = f(Ux_t + Ws_t-1), wobei U und W Parametermatrizen sind. Die Funktion f ist in der Regel eine Nichtlinearität, wie beispielsweise die hyperbolische Tangensfunktion (Tanh) oder eine Variante der Gleichrichterfunktion f(x) = max(0, x). Die konkrete mathematische Funktion, die in den verborgenen Schichten 1604 verwendet wird, kann jedoch abhängig von den konkreten Implementierungsdetails des RNN 1600 variieren.
Zusätzlich zu den beschriebenen grundlegenden CNN- und RNN-Netzen können auch Variationen dieser Netze aktiviert werden. Ein Beispiel für eine RNN-Variante ist das Long-Short-Term-Memory- (LSTM-) RNN. LSTM-RNNs sind in der Lage, langfristige Abhängigkeiten zu lernen, die für die Verarbeitung längerer Sprachsequenzen notwendig sein können. Eine Variante des CNN ist ein Convolutional Deep Belief Network, das eine ähnliche Struktur wie ein CNN hat und auf ähnliche Weise wie ein Deep Belief Network trainiert wird. Ein Deep Belief Network (DBN) ist ein generatives neuronales Netz, das aus mehreren Schichten von stochastischen (zufälligen) Variablen besteht. DBNs können schichtweise mit Greedy Unsupervised Learning trainiert werden. Die gelernten Gewichtungen des DBN können dann zum Vortraining von neuronalen Netzen verwendet werden, indem ein optimaler Anfangssatz von Gewichtungen für das neuronale Netz bestimmt wird.
17 veranschaulicht Training und Einsatz eines tiefen neuronalen Netzes. Nachdem ein gegebenes Netz für eine Aufgabe strukturiert wurde, wird das neuronale Netz anhand eines Trainingsdatensatzes 1702 trainiert. Es wurden verschiedene Trainings-Frameworks entwickelt, die eine Hardwarebeschleunigung des Trainingsprozesses ermöglichen. Zum Beispiel kann das Maschinenlern-Framework 1404 aus 14 als Trainings-Framework 1704 konfiguriert werden. Das Trainings-Framework 1704 kann sich in ein untrainiertes neuronales Netz 1706 einklinken und ermöglichen, dass das untrainierte neuronale Netz mit den vorliegend beschriebenen parallelen Verarbeitungsressourcen trainiert wird, um ein trainiertes neuronales Netz 1708 zu erzeugen. Um den Trainingsprozess zu starten, können die Anfangsgewichtungen zufällig oder durch Vortraining mit einem Deep Belief Network gewählt werden. Der Trainingszyklus kann dann entweder überwacht oder unüberwacht durchgeführt werden.
Überwachtes Lernen ist eine Lernmethode, bei der das Training als vermittelte Operation durchgeführt wird, z.B. wenn der Trainingsdatensatz 1702 Eingaben enthält, die mit der gewünschten Ausgabe für die Eingabe gepaart sind, oder wenn der Trainingsdatensatz Eingaben mit bekannter Ausgabe enthält und die Ausgabe des neuronalen Netzes manuell bewertet wird. Das Netz verarbeitet die Eingaben und vergleicht die resultierenden Ausgaben mit einem Satz von erwarteten oder gewünschten Ausgaben. Fehler werden dann durch das System zurück propagiert. Das Trainings-Framework 1704 kann sich anpassen, um die Gewichtungen anzupassen, die das untrainierte neuronale Netz 1706 steuern. Das Trainings-Framework 1704 kann Werkzeuge bereitstellen, um zu überwachen, wie gut das untrainierte neuronale Netz 1706 zu einem Modell hin konvergiert, das geeignet ist, korrekte Antworten auf der Grundlage bekannter Eingabedaten zu erzeugen. Der Trainingsprozess findet wiederholt statt, da die Gewichtungen des Netzwerks angepasst werden, um die vom neuronalen Netz generierte Ausgabe zu verfeinern. Der Trainingsprozess kann fortgesetzt werden, bis das neuronale Netz eine statistisch gewünschte Genauigkeit erreicht, die mit einem trainierten neuronalen Netz 1708 verbunden ist. Das trainierte neuronale Netz 1708 kann dann eingesetzt werden, um eine beliebige Anzahl von Maschinenlernoperationen zu implementieren, um ein Inferenzergebnis 814 basierend auf der Eingabe neuer Daten 812 zu erzeugen.
Unüberwachtes Lernen ist eine Lemmethode, bei der das Netz versucht, sich selbst anhand von nicht gekennzeichneten Daten zu trainieren. Beim unüberwachten Lernen umfasst der Trainingsdatensatz 1702 also Eingabedaten ohne zugehörige Ausgabedaten. Das untrainierte neuronale Netz 1706 kann Gruppierungen innerhalb der ungekennzeichneten Eingaben lernen und bestimmen, wie einzelne Eingaben mit dem Gesamtdatensatz zusammenhängen. Unüberwachtes Training kann verwendet werden, um eine selbstorganisierende Karte zu erzeugen, die eine Art trainiertes neuronales Netz 1708 ist, das in der Lage ist, nützliche Operationen zur Reduzierung der Dimensionalität von Daten durchzuführen. Unüberwachtes Training kann auch zur Erkennung von Anomalien verwendet werden, was die Identifizierung von Datenpunkten in einem Eingabedatensatz ermöglicht, die von den normalen Mustern der Daten abweichen.
Es können auch Variationen von überwachtem und unüberwachtem Training eingesetzt werden. Semi-überwachtes Lernen ist eine Methode, bei der der Trainingsdatensatz 1702 eine Mischung aus gekennzeichneten und ungekennzeichneten Daten mit gleicher Verteilung umfasst. Inkrementelles Lernen ist eine Variante des überwachten Lernens, bei der die Eingabedaten kontinuierlich verwendet werden, um das Modell weiter zu trainieren. Inkrementelles Lernen ermöglicht es dem trainierten neuronalen Netz 1708, sich an die neuen Daten 1712 anzupassen, ohne das Wissen zu vergessen, das dem Netz beim anfänglichen Training vermittelt wurde.
Ob überwacht oder unüberwacht, der Trainingsprozess für besonders tiefe neuronale Netze kann für einen einzelnen Rechenknoten zu rechenintensiv sein. Anstatt einen einzelnen Rechenknoten zu verwenden, kann ein verteiltes Netz aus Rechenknoten verwendet werden, um den Trainingsprozess zu beschleunigen.
18 ist ein Blockschaubild, das verteiltes Lernen veranschaulicht. Verteiltes Lernen ist ein Trainingsmodell, das mehrere verteilte Rechenknoten verwendet, um ein überwachtes oder unüberwachtes Training eines neuronalen Netzes durchzuführen. Die verteilten Rechenknoten können jeweils einen oder mehrere Hostprozessoren und einen oder mehrere der Allzweck-Verarbeitungsknoten umfassen. Wie dargestellt, kann verteiltes Lernen mit Modellparallelität 1802, Datenparallelität 1804 oder einer Kombination aus Modell- und Datenparallelität 1804 durchgeführt werden.
Bei der Modellparallelität 1802 können verschiedene Rechenknoten in einem verteilten System Trainingsberechnungen für verschiedene Teile eines einzelnen Netzes durchführen. Zum Beispiel kann jede Schicht eines neuronalen Netzes von einem anderen Verarbeitungsknoten des verteilten Systems trainiert werden. Zu den Vorteilen der Modellparallelität gehört die Möglichkeit, auf besonders große Modelle zu skalieren. Die Aufteilung der Berechnungen, die mit verschiedenen Schichten des neuronalen Netzes verbunden sind, ermöglicht das Training von sehr großen neuronalen Netzen, bei denen die Gewichteungen aller Schichten nicht in den Speicher eines einzelnen Rechenknotens passen würden. In einigen Fällen kann die Modellparallelität besonders nützlich sein, um ein unüberwachtes Training großer neuronaler Netze durchzuführen.
Bei der Datenparallelität 1804 haben die verschiedenen Knoten des verteilten Netzes eine vollständige Instanz des Modells, und jeder Knoten erhält einen anderen Teil der Daten. Die Ergebnisse aus den verschiedenen Knoten werden dann kombiniert. Obwohl verschiedene Ansätze zur Datenparallelität möglich sind, erfordern alle datenparallelen Trainingsansätze eine Methode zur Kombination der Ergebnisse und zur Synchronisierung der Modellparameter zwischen den einzelnen Knoten. Beispielhafte Ansätze zum Kombinieren von Daten sind Parameter-Mittelwertbildung und aktualisierungsbasierte Datenparallelität. Die Parameter-Mittelwertbildung trainiert jeden Knoten auf einen Teilsatz der Trainingsdaten und setzt die globalen Parameter (z.B. Gewichtungen, Verzerrungen) auf den Mittelwert der Parameter von jedem Knoten. Die Parameter-Mittelwertbildung verwendet einen zentralen Parameterserver, der die Parameterdaten pflegt. Die aktualisierungsbasierte Datenparallelität ist ähnlich wie die Parameter-Mittelwertbildung, außer dass anstelle der Übertragung von Parametern von den Knoten zum Parameterserver die Aktualisierungen des Modells übertragen werden. Zusätzlich kann die aktualisierungsbasierte Datenparallelität dezentral durchgeführt werden, wobei die Aktualisierungen komprimiert und zwischen den Knoten übertragen werden.
Die kombinierte Modell- und Datenparallelität 1806 kann beispielsweise in einem verteilten System implementiert werden, in dem jeder Rechenknoten mehrere GPUs aufweist. Jeder Knoten kann eine vollständige Instanz des Modells haben, wobei separate GPUs innerhalb jedes Knotens verwendet werden, um verschiedene Teile des Modells zu trainieren.
Verteiltes Training hat einen erhöhten Overhead im Vergleich zum Training auf einem einzelnen Rechner. Die vorliegend beschriebenen Parallelprozessoren und GPGPUs können jedoch jeweils verschiedene Methoden implementieren, um den Overhead des verteilten Trainings zu reduzieren, einschließlich Methoden, die eine Datenübertragung von GPU zu GPU mit hoher Bandbreite und eine beschleunigte Remote-Datensynchronisierung ermöglichen.
Beispielhafte Maschinenlemanwendungen
Maschinelles Lernen kann zur Lösung einer Vielzahl von technologischen Problemen eingesetzt werden, darunter, ohne jedoch hierauf eingeschränkt zu sein, auf Computer Vision, autonomes Fahren und Navigation, Erkennung gesprochener Sprache und Sprachverarbeitung. Computer Vision ist traditionell eines der aktivsten Forschungsgebiete für Maschinenlernanwendungen. Die Anwendungen von Computer Vision reichen von der Reproduktion menschlicher visueller Fähigkeiten, wie z.B. dem Erkennen von Gesichtern, bis hin zur Schaffung neuer Kategorien visueller Fähigkeiten. Zum Beispiel können Computer-Vision-Anwendungen so konfiguriert werden, dass sie Schallwellen aus den Vibrationen erkennen, die in den in einem Video sichtbaren Objekten induziert werden. Parallelprozessor-beschleunigtes maschinelles Lernen ermöglicht es, Computer-Vision-Anwendungen mit wesentlich größeren Trainingsdatensätzen zu trainieren, als dies bisher möglich war, und ermöglicht es, Inferenzfindungssysteme mit Parallelprozessoren mit geringem Stromverbrauch einzusetzen.
Parallelprozessor-beschleunigtes maschinelles Lernen hat Anwendungen für autonomes Fahren, einschließlich Fahrspur- und Verkehrszeichenerkennung, Hindernisvermeidung, Navigation und Fahrkontrolle. Beschleunigte maschinelle Lernverfahren können zum Trainieren von Fahrmodellen auf der Grundlage von Datensätzen verwendet werden, die die entsprechenden Reaktionen auf bestimmte Trainingseingaben definieren. Die vorliegend beschriebenen Parallelprozessoren können ein schnelles Training der immer komplexeren neuronalen Netze ermöglichen, die für Lösungen zum autonomen Fahren verwendet werden, und ermöglichen den Einsatz von Inferenzfindungsprozessoren mit geringem Stromverbrauch in einer mobilen Plattform, die für die Integration in autonome Fahrzeuge geeignet ist.
Parallelprozessor-beschleunigte tiefe neuronale Netze haben Maschinenlernansätze für die automatische Spracherkennung (Automatic Speech Recognition, ASR) ermöglicht. ASR umfasst die Erstellung einer Funktion, die die wahrscheinlichste sprachliche Sequenz angesichts einer akustischen Eingabesequenz berechnet. Beschleunigtes maschinelles Lernen mit tiefen neuronalen Netzen hat es ermöglicht, die bisher für ASR verwendeten Hidden-Markov-Modelle (HMMs) und Gaußschen Mischmodelle (GMMs) zu ersetzen.
Parallelprozessor-beschleunigtes maschinelles Lernen kann auch zur Beschleunigung der Verarbeitung natürlicher Sprache verwendet werden. Automatische Lernverfahren können statistische Inferenzalgorithmen nutzen, um Modelle zu erzeugen, die robust gegenüber fehlerhaften oder ungewohnten Eingaben sind. Beispielhafte Anwendungen für natürliche Sprachprozessoren sind die automatische maschinelle Übersetzung zwischen menschlichen Sprachen.
Die für maschinelles Lernen verwendeten Parallelverarbeitungsplattformen können in Trainingsplattformen und Einsatzplattformen unterteilt werden. Trainingsplattformen sind in der Regel hochgradig parallel und umfassen Optimierungen zur Beschleunigung von Multi-GPU-Einzelknoten-Training und Multi-Node-Multi-GPU-Training, während eingesetzte Plattformen für maschinelles Lernen (z.B. Inferenzfindung) in der Regel Parallelprozessoren mit geringerem Stromverbrauch aufweisen, die für den Einsatz in Produkten wie Kameras, autonomen Robotern und autonomen Fahrzeugen geeignet sind.
GPGPU mit Matrixbeschleunigungslogik
19 ist ein Blockschaubild eines Datenverarbeitungssystems 1900 gemäß einer Ausführungsform. Das Datenverarbeitungssystem 1900 ist ein heterogenes Verarbeitungssystem mit einem Prozessor 1902, einem vereinheitlichten Speicher 1910 und einer GPGPU 1920, die eine Beschleunigungslogik für maschinelles Lernen aufweist. Der Prozessor 1902 und die GPGPU 1920 können beliebige der vorliegend beschriebenen Prozessoren und GPGPU/Parallelprozessoren sein. Der Prozessor 1902 kann Anweisungen für einen Compiler 1915 ausführen, der im Systemspeicher 1912 gespeichert ist. Der Compiler 1915 wird auf dem Prozessor 1902 ausgeführt, um Quellcode 1914A in kompilierten Code 1914B zu kompilieren. Der kompilierte Code 1914B kann Anweisungen, die vom Prozessor 1902 ausgeführt werden können, und/oder Anweisungen aufweisen, die von der GPGPU 1920 ausgeführt werden können. Während der Kompilierung kann der Compiler 1915 auf Grundlage des kompilierten Codes 1914B Operationen zum Einfügen von Metadaten durchführen, einschließlich Hinweisen zum Grad der Datenparallelität, die im kompilierten Code 1914B vorhanden ist, und/oder Hinweisen zur Datenlokalität, die mit zu verschickenden Threads verbunden ist. Der Compiler 1915 kann die notwendigen Informationen zur Durchführung solcher Operationen aufweisen oder die Operationen können mit Hilfe einer Laufzeitbibliothek 1916 durchgeführt werden. Die Laufzeitbibliothek 1916 kann auch den Compiler 1915 bei der Kompilierung des Quellcodes 1914A unterstützen und kann auch Anweisungen enthalten, die zur Laufzeit mit dem kompilierten Code 1914B verknüpft werden, um die Ausführung der kompilierten Anweisungen auf der GPGPU 1920 zu erleichtern.
Der vereinheitlichte Speicher 1910 stellt einen einheitlichen Adressraum dar, auf den der Prozessor 1902 und die GPGPU 1920 zugreifen können. Der vereinheitlichte Speicher kann sowohl den Systemspeicher 1912 als auch den GPGPU-Speicher 1918 umfassen. Der GPGPU-Speicher 1918 ist ein Speicher innerhalb eines Adressraums der GPGPU 1920 und kann einen Teil des oder den gesamten Systemspeicher 1912 umfassen. In einer Ausführungsform kann der GPGPU-Speicher 1918 zudem zumindest einen Teil eines beliebigen Speichers enthalten, der ausschließlich für die Verwendung durch die GPGPU 1920 bestimmt ist. In einer Ausführungsform kann der kompilierte Code 1914B, der im Systemspeicher 1912 gespeichert ist, in den GPGPU-Speicher 1918 für den Zugriff durch die GPGPU 1920 abgebildet werden.
Die GPGPU 1920 weist mehrere Rechenblöcke 1924A bis 1924N auf, die eine oder mehrere der vorliegend beschriebenen Recheneinheiten oder Ausführungselemente aufweisen können. In einer Ausführungsform weist die GPGPU 1920 zusätzlich einen Matrixbeschleuniger 1923 auf, der eine oder mehrere Spezialfunktions-Recheneinheiten aufweisen kann, die zur Beschleunigung eines Teilsatzes von Matrixoperationen (z.B. Punktprodukt usw.) ausgelegt sind. Die GPGPU 1920 kann zudem einen Satz von Ressourcen aufweisen, die von den Rechenblöcken 1924A bis 1924N und dem Matrixbeschleuniger 1923 gemeinsam genutzt werden können, darunter, ohne jedoch hierauf eingeschränkt zu sein, einen Satz von Registern 1925, ein Stromversorgungs- und Leistungsmodul 1926 und einen Cache 1927. In einer Ausführungsform umfassen die Register 1925 direkt und indirekt zugängliche Register, wobei die indirekt zugänglichen Register für die Verwendung durch den Matrixbeschleuniger 1923 optimiert sind. Das Stromversorgungs- und Leistungsmodul 1926 kann so konfiguriert werden, dass es die Stromzufuhr und die Taktfrequenzen für die Rechenblöcke 1924A bis 1924N anpasst, um inaktive Komponenten innerhalb der Rechenblöcke 1924A bis 1924N mit Strom zu versorgen. In verschiedenen Ausführungsformen kann der Cache 1927 einen Anweisungscache und/oder einen Datencache einer unteren Ebene umfassen.
Die GPGPU 1920 kann zusätzlich einen L3-Datencache 1930 aufweisen, der dazu verwendet werden kann, Daten zu cachen, auf die der Matrixbeschleuniger 1923 und/oder die Rechenelemente innerhalb der Rechenblöcke 1924A bis 1924N aus dem vereinheitlichten Speicher 1910 zugreifen. In einer Ausführungsform umfasst der L3-Datencache 1930 einen gemeinsam genutzten lokalen Speicher 1932, der von den Rechenelementen innerhalb der Rechenblöcke 1924A bis 1924N und dem Matrixbeschleuniger 1923 gemeinsam genutzt werden kann.
In einer Ausführungsform weist die GPGPU 1920 eine Logik zur Anweisungsverarbeitung auf, wie beispielsweise eine Abruf- und Decodiereinheit 1921 und einen Scheduler-Controller 1922. Die Abruf- und Decodiereinheit 1921 weist eine Abrufeinheit und eine Decodiereinheit zum Abrufen und Decodieren von Befehlen zur Ausführung durch einen oder mehrere der Rechenblöcke 1924A bis 1924N oder den Matrixbeschleuniger 1923 auf. Die Anweisungen können über den Scheduler-Controller 1922 an die entsprechende Funktionseinheit innerhalb des Rechenblocks 1924A bis 1924N oder des Matrixbeschleunigers geplant werden. In einer Ausführungsform ist der Scheduler-Controller 1922 eine ASIC, die so konfiguriert werden kann, dass sie erweiterte Planungsoperationen durchführt. In einer Ausführungsform ist der Scheduler-Controller 1922 ein Mikrocontroller oder ein Verarbeitungskern mit geringem Stromverbrauch, der in der Lage ist, Scheduler-Befehle auszuführen, die von einem Firmware-Modul geladen wurden.
In einer Ausführungsform können einige von den Rechenblöcken 1924A bis 1924N auszuführende Funktionen direkt in den Matrixbeschleuniger 1923 eingeplant oder dorthin abgeladen werden. In verschiedenen Ausführungsformen weist der Matrixbeschleuniger 1923 eine Verarbeitungselementlogik auf, die so konfiguriert ist, dass sie effizient Matrixberechnungsoperationen durchführt, wie beispielsweise Multiplikations- und Additionsoperationen und Punktproduktoperationen, die von 3D-Grafik- oder Rechen-Shader-Programmen verwendet werden. In einer Ausführungsform kann der Matrixbeschleuniger dafür konfiguriert sein, von Maschinenlem-Frameworks verwendete Operationen zu beschleunigen. In einer Ausführungsform ist der Matrixbeschleuniger 1923 eine anwendungsspezifische integrierte Schaltung, die explizit für die Durchführung eines bestimmten Satzes von parallelen Matrixmultiplikations- und/oder -additionsoperationen konfiguriert ist. In einer Ausführungsform ist der Matrixbeschleuniger 1923 ein feldprogrammierbares Gate-Array (FPGA), das eine Festfunktionslogik bereitstellt, die zwischen Arbeitslasten aktualisiert werden kann. Die Menge der Matrixoperationen, die vom Matrixbeschleuniger 1923 ausgeführt werden können, kann relativ zu den Operationen, die vom Rechenblock 1924A bis 1924N ausgeführt werden können, begrenzt sein. Der Matrixbeschleuniger 1923 kann diese Operationen jedoch mit einem deutlich höheren Durchsatz im Vergleich zum Rechenblock 1924A bis 1924N durchführen.
20 zeigt eine Ausführungsform einer Matrixoperation 2005, die von einer Befehlspipeline 2000 durchgeführt wird, gemäß einer Ausführungsform. Die Befehlspipeline 2000 kann dafür konfiguriert sein, eine Matrixoperation 2005 durchzuführen, wie beispielsweise, ohne jedoch hierauf eingeschränkt zu sein, eine Punktproduktoperation. Das Punktprodukt aus zwei Vektoren ist ein skalarer Wert, der gleich der Summe der Produkte entsprechender Komponenten der Vektoren ist. Das Punktprodukt kann wie in Gleichung (1) unten dargestellt 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 Punktprodukt kann in einer Faltungsoperation für ein neuronales Faltungsnetz (CNN) verwendet werden. 19 veranschaulicht eine zweidimensionale (2D-) Faltung unter Verwendung einer Matrixoperation 2005 einschließlich einer Punktproduktoperation. Während die 2D-Faltung dargestellt ist, kann die N-dimensionale Faltung auf einem N-dimensionalen Volumen mit N-dimensionalen Filtern durchgeführt werden. Eine Rezeptionsfeldkachel 2002 hebt einen Teil eines Eingabevolumens in einem Eingabevolumenpuffer 2004 hervor. Der Eingangsvolumenpuffer kann im Speicher 2030 gespeichert werden. Eine Punktmatrixoperation 2005 kann zwischen den Daten innerhalb der Rezeptionsfeldkachel 2002 und einem Faltungsfilter durchgeführt werden, um einen Datenpunkt innerhalb des Ausgabepuffers 2006 zu erzeugen, der auch im Speicher 2030 gespeichert werden kann. Der Speicher 2030 kann jeder der vorliegend beschriebenen Speicher sein, einschließlich des Systemspeichers 1912, des GPGPU-Speichers 1918 oder eines oder mehrerer Cachespeicher 1927, 1930 wie in 19.
Die Kombination der Datenpunkte im Ausgangspuffer 2006 stellt eine durch die Faltungsoperation erzeugte Aktivierungskarte dar. Jeder Punkt innerhalb der Aktivierungskarte wird durch Verschieben der Rezeptionsfeldkachel über den Eingabevolumenpuffer 2004 erzeugt. Die Daten der Aktivierungskarte können in eine Aktivierungsfunktion eingegeben werden, um einen Ausgangsaktivierungswert zu bestimmen. In einer Ausführungsform kann die Faltung des Eingangsvolumenpuffers 2004 in einem Framework als Matrixoperation 1705 einer höheren Ebene definiert werden. Die Matrixperationen höherer Ebene können über primitive Operationen ausgeführt werden, wie z.B. eine BLAS-Operation (Basic Linear Algebra Subprogram). Die primitiven Operationen können über Hardwareanweisungen beschleunigt werden, die von der Anweisungspipeline 2000 ausgeführt werden.
Die Anweisungspipeline 2000, die zur Beschleunigung von Hardwareanweisungen verwendet wird, kann die Anweisungsabruf- und -decodiereinheit 1921, die Hardwareanweisungen abrufen und decodieren kann, und den Scheduler-Controller 1922 aufweisen, der decodierte Anweisungen an eine oder mehrere Ausführungseinheiten innerhalb der Rechenblöcke 1924A bis 1924N und/oder den Matrixbeschleuniger 1923 planen kann. In einer Ausführungsform kann eine Hardwareanweisung an die Rechenblöcke 1924A bis 1924N geplant und an den Matrixbeschleuniger 1923 ausgelagert werden. Die eine oder die mehreren Hardwareanweisungen und die zugehörigen Daten zur Durchführung der Matrixoperation 2005 können im Speicher 2030 gespeichert werden. Die Ausgabe der Hardwareanweisung kann auch im Speicher 2030 abgelegt werden.
In einer Ausführungsform kann der Matrixbeschleuniger 1923 eine oder mehrere Hardwareanweisungen ausführen, um die Matrixoperation 2005 unter Verwendung der integrierten Punktproduktlogik 2008 (DP-Logik) durchzuführen. Die Punktproduktlogik 2008 kann eine Kombination aus programmierbarer und Festfunktionshardware aufweisen, die für die Durchführung von Punktproduktoperationen konfigurierbar ist. Während Funktionseinheiten innerhalb der Rechenblöcke 1924A bis 1924N auch so konfiguriert werden können, dass sie Punktproduktoperationen durchführen, kann die Punktproduktlogik 2008 so konfiguriert werden, dass sie einen begrenzten Teilsatz von Punktproduktoperationen mit einem deutlich höheren Durchsatz im Vergleich zum Rechenblock 1924A bis 1924N durchführt.
Bei der Verarbeitung von Matrixmultiplikationsoperationen für CNN, wie z.B. Residual Neural Network (ResNet)-50, gibt es einen signifikanten Prozentsatz an Spärlichkeit (z.B. Nullwerte) in den Aktivierungsmatrizen über die Schichten hinweg. Tatsächlich kann die Spärlichkeit in einigen Fällen bis zu 99,9 % betragen. Ein solch hoher Anteil an spärlichen Matrizen bietet die Möglichkeit für Verarbeitungsoptimierungen, einschließlich einer Umgehung von redundanten Speicherzugriffen und Berechnungen. So kann der Energieverbrauch durch Einsparung unnötiger Verarbeitung reduziert werden.
Gemäß einer Ausführungsform bietet der Matrixbeschleuniger 1923 eine Kacheloptimierung, die es ermöglicht, mehrere Kacheloperationen für dünn besetzte Matrizen zu überspringen (oder zu umgehen). In einer solchen Ausführungsform können die Matrixdaten als Kacheln verarbeitet werden, deren Größe so gewählt wird, dass die Ausnutzung der Spärlichkeit maximiert wird, indem eine maximale Anzahl von Kacheln mit nur „0en“ enthalten ist. Je höher die Anzahl der Kacheln mit nur Nullen (z.B. Anzahl der Nullkacheln), desto mehr Operationen der Faltungsmatrix können umgangen werden, was zu einer Leistungssteigerung führt.
In einer Ausführungsform empfängt der Matrixbeschleuniger 1923 Eingangsmatrixdaten und untersucht die Daten, um die Spärlichkeit zu bestimmen. In einer solchen Ausführungsform wählt der Matrixbeschleuniger 1923 eine Kachelgröße (z. B. 4x4 oder 8x8) aus, um die Ausnutzung der Spärlichkeit auf Grundlage der ermittelten Spärlichkeit zu maximieren. 21 zeigt eine Ausführungsform von Eingangsmatrixdaten 2100 mit verschiedenen Kachelkonfigurationen. Wie in 21 gezeigt, können die Matrixdaten 2100 8x8-Kacheln 2110 (z.B. 2110a und 2110b) und 4x4-Kacheln 2120 (z.B. 2120a und 2120b) aufweisen. Obwohl als 4x4- und 8x8-Implementierung gezeigt, können andere Ausführungsformen andere Kachelgrößen implementieren.
Gemäß einer Ausführungsform transformiert der Matrixbeschleuniger 1923 die empfangenen Matrixdaten in Teilblöcke (z.B. in der Größe 4x4) und untersucht zusammenhängende Teilblöcke (z.B. 4), um die Spärlichkeit der Daten zu bestimmen und eine Kachelgröße für die Verarbeitung auszuwählen (z.B. 4x4 oder 8x8). In einer solchen Ausführungsform werden Bitmap-Daten mit den Matrixdaten empfangen und im Speicher gespeichert, um die Ausgangsmatrizen über die Faltungsschichten zu schreiben.
22A veranschaulicht eine Ausführungsform einer Bitmap, die einem Teilblock aus Matrixdaten entspricht.
In einer Ausführungsform ist jeder Bitwert in der Bitmap (oder Teilblock-Bit) mit einem Teilblock aus Matrixdaten verbunden. In einer weiteren Ausführungsform untersucht der Matrixbeschleuniger 1923 jedes Bit des Teilblocks, um festzustellen, ob der Teilblock spärliche Daten (z.B. nur Nullen) umfasst. In einer solchen Ausführungsform wird ein Bit auf „high“ (z.B. logisch 1) gesetzt, wenn der zugehörige Teilblock nur Nullwerte aufweist, und auf „low“ (z.B. logisch 0), wenn der Teilblock mindestens einen Nicht-Nullwert enthält.
In einer weiteren Ausführungsform untersucht der Matrixbeschleuniger 1923 Teilblock-Bits, die mit einem Block aus vier zusammenhängenden (oder benachbarten) Teilblöcken verbunden sind, um die zu verarbeitende Kachelgröße zu bestimmen. In dieser Ausführungsform wählt der Matrixbeschleuniger 1923 eine 8x8-Kachelgröße für einen Block aus Teilblöcken aus, wenn er feststellt, dass jedes der zugehörigen Teilblock-Bits auf „high“ gesetzt ist (z.B. Bit0-Bit3 = 1111). Somit wird eine 8x8-Kachelgröße gewählt, wenn festgestellt wird, dass alle 4 Blöcke nur Null-Daten aufweisen. Eine Auswahl der Kachelgröße von 8x8 führt dazu, dass Ausgabematrixdaten durch Überspringen von Operationen erzeugt werden können, da die Kachel nur spärlichen Daten enthält. 22B veranschaulicht eine Ausführungsform der als 8x8-Kachelgröße zu verarbeitenden Teilblockdaten.
In einer weiteren Ausführungsform wählt der Matrixbeschleuniger 1923 eine 4x4-Kachelgröße für die Verarbeitung aus, wenn festgestellt wird, dass mindestens eines der Teilblock-Bits nicht auf „high“ gesetzt ist (z.B. Bit0-Bit3 = 0111, 1011, 0001 usw.). So wird eine 4x4-Kachelgröße für die Verarbeitung der Blöcke gewählt, um Ausgabedaten zu erzeugen, wenn festgestellt wird, dass mindestens einer der Teilblöcke Daten ungleich Null hat. 22C veranschaulicht eine Ausführungsform der als 4x4-Kachelgrößen zu verarbeitenden Teilblockdaten. Gemäß einer Ausführungsform wird die oben beschriebene Bitmusterprüfung während des Schreibens in den Speicher durchgeführt und erfordert daher kein Lesen und Schreiben von Daten/Matrizen in und aus dem Speicher.
23A und 23B veranschaulichen Ausführungsformen einer systolischen Pipeline, die zur Verarbeitung der Blockmatrixdaten implementiert wird. 23A veranschaulicht eine Ausführungsform der systolischen Pipeline 2300, die im Matrixbeschleuniger 192 implementiert wird. Wie in 23A gezeigt, umfasst die systolische Pipeline 2300 8 Stufen zur Verarbeitung eines systolischen 8x8-Arrays aus Matrixdaten. Jede Stufe verarbeitet Eingangsmatrixdaten, die in Registerdateiregistern geladen sind, was zu Ausgangsdaten führt, die in anderen Registern gespeichert sind (z.B. r24[0_7]-r31[0_7]).
Gemäß einer Ausführungsform kann die systolische Pipeline 2300 so konfiguriert sein, dass sie 4x4-Kacheln verarbeitet. In einer solchen Ausführungsform wird die 8-stufige Pipeline 2300 als 4+4-Konfiguration implementiert, um eine Kachelgröße von 4x4 zu verarbeiten. 23B zeigt eine Ausführungsform der 4+4-Konfiguration. Wie in 23B dargestellt, wird die Pipeline 2300 in zwei systolische Pipelines mit jeweils „4“ Stufen umgewandelt. In einer Ausführungsform werden zusätzliche „Additions“-Operationen implementiert, um die Ausgabe zu erzeugen, die zwei „8x4“-Pipeline-Ausgaben entspricht. In dieser Ausführungsform implementiert die Pipeline-Transformation bis zu 6 Lese- (oder „RD“-) Ports und bis zu 2 Schreib- (oder „WR“-) Ports pro Zyklus. Mehr als 4 „RD“-Anschlüsse und 2 „WR“-Anschlüsse sind nur für die Fälle erforderlich, in denen diagonale Nicht-Null-Teilblöcke oder nur ein einziger nicht-spärlicher Block auftreten.
24 ist ein Flussdiagramm, das eine Ausführungsform eines Prozesses zum Durchführen von Kachelungsoptimierung veranschaulicht. Im Verarbeitungsblock 2410 werden Eingangsmatrixdaten empfangen. Im Verarbeitungsblock 2420 werden die Matrixdaten in Teilblöcke (z.B. 4x4) transformiert. Im Verarbeitungsblock 2430 werden die mit den Matrixdaten verbundenen Bitmap-Daten abgerufen. Im Verarbeitungsblock 2440 werden die Teilblock-Bits in der Bitmap für einen Block aus benachbarten Teilblöcken untersucht.
Im Entscheidungsblock 2450 wird festgestellt, ob alle Teilblock-Bits auf „high“ gesetzt sind (z.B. Bit0-Bit4 = 1111). Wenn dies der Fall ist, wird eine erste Kachelgröße der Matrixdaten ausgewählt, die die benachbarten Teilblöcke repräsentieren (z.B. 8x8), Verarbeitungsblock 2460. Im Verarbeitungsblock 2470 werden Ausgabematrixdaten unter Verwendung der 8x8-Kachel spärlicher Daten erzeugt. Dadurch können Matrixoperationen, die zur Erzeugung von Ausgabematrixdaten implementiert sind, umgangen werden. Wenn im Entscheidungsblock 2450 festgestellt wird, dass eines oder mehrere der Kachel-Bits nicht auf „high“ gesetzt sind, wird eine zweite Kachelgröße ausgewählt, die der Größe jedes Teilblocks entspricht (z.B. 4x4), Verarbeitungsblock 2480. Im Verarbeitungsblock 2470 werden Matrixoperationen an den 4x4-Kacheln durchgeführt, um die Ausgabematrixdaten zu erzeugen.
Die Ausführungsformen können als beliebige der Folgenden oder eine Kombination aus diesen implementiert werden: ein oder mehrere Mikrochips oder integrierte Schaltungen, die über eine Hauptplatine miteinander verbunden sind, festverdrahtete Logik, Software, die in einer Speichervorrichtung gespeichert ist und von einem Mikroprozessor ausgeführt wird, Firmware, anwendungsspezifische integrierte Schaltung (ASIC) und/oder feldprogrammierbares Gate-Array (FPGA). Der Begriff „Logik“ kann beispielsweise Software oder Hardware und/oder Kombinationen aus Software und Hardware umfassen.
Ausführungsformen können beispielsweise als Computerprogrammprodukt bereitgestellt werden, das ein oder mehrere maschinenlesbare Medien mit darauf gespeicherten maschinenausführbaren Befehlen enthalten kann, die bei Ausführung durch eine oder mehrere Maschinen wie beispielsweise einen Computer, ein Computemetzwerk oder andere elektronische Geräte dazu führen können, dass die eine oder die mehreren Maschinen Operationen in Übereinstimmung mit den vorliegend beschriebenen Ausführungsformen ausführen. Ein maschinenlesbares Medium kann, ohne jedoch hierauf eingeschränkt zu sein, Floppy-Disketten, optische Platten, CD-ROMs (Compact-Disc-Nur-Lese-Speicher) und magnetooptische Platten, ROMs, RAMs, EPROMs (löschbare programmierbare Nur-Lese-Speicher), EEPROMs (elektrisch löschbare programmierbare Nur-Lese-Speicher), magnetische oder optische Karten, Flashspeicher oder andere Arten von Medien/maschinenlesbaren Medien umfassen, die zum Speichern von maschinenausführbaren Befehlen geeignet sind.
Darüber hinaus können Ausführungsformen als Computerprogrammprodukt heruntergeladen werden, wobei das Programm von einem entfernten Computer (z.B. einem Server) zu einem anfragenden Computer (z.B. einem Client) mittels eines oder mehrerer Datensignale, die in einer Trägerwelle oder einem anderen Ausbreitungsmedium verkörpert und/oder durch diese moduliert sind, über eine Kommunikationsverbindung (z.B. ein Modem und/oder eine Netzwerkverbindung) übertragen werden kann.
Die nachfolgenden Klauseln und/oder Beispiele betreffen weitere Ausführungsformen oder Beispiele. In den Beispielen enthaltene Einzelheiten können überall in einer oder mehreren Ausführungsformen verwendet werden. Die verschiedenen Merkmale der unterschiedlichen Ausführungsformen oder Beispiele können auf unterschiedliche Weise kombiniert werden, wobei einige Merkmale eingeschlossen und andere ausgeschlossen werden können, um eine Vielzahl unterschiedlicher Anwendungen zu ermöglichen. Beispiele können Gegenstände wie beispielsweise ein Verfahren, Mittel zum Durchführen von Handlungsschritten des Verfahrens, mindestens ein maschinenlesbares Medium, das Anweisungen enthält, die bei Ausführung durch eine Maschine die Maschine veranlassen, Handlungsschritte des Verfahrens durchzuführen, oder eine Vorrichtung oder ein System zum Erleichtern hybrider Kommunikation gemäß vorliegend beschriebenen Ausführungsformen und Beispielen beinhalten.
Einige Ausführungsformen beziehen sich auf Beispiel 1, das eine Vorrichtung zum Erleichtern von Matrixverarbeitung umfasst, die einen Matrixbeschleuniger umfasst, um Eingabematrixdaten zu empfangen, die Eingabematrixdaten in eine Vielzahl von Teilblöcken zu transformieren, einen ersten Block der Teilblöcke zu untersuchen, um zu bestimmen, ob der erste Block spärliche Daten umfasst, eine erste Kachelgröße auszuwählen, wenn bestimmt wird, dass der erste Block spärliche Daten umfasst, und Ausgabematrixdaten auf Grundlage der ersten Kachelgröße zu erzeugen.
Beispiel 2 umfasst den Gegenstand nach Beispiel 1, wobei die erste Kachelgröße eine Größe des ersten Blocks umfasst.
Beispiel 3 umfasst den Gegenstand nach Beispiel 1 und 2, wobei der Matrixbeschleuniger eine zweite Kachelgröße auswählt, wenn festgestellt wird, dass der erste Block keine spärlichen Daten umfasst.
Beispiel 4 umfasst den Gegenstand der Beispiele 1 bis 3, wobei die zweite Kachelgröße eine Größe eines Teilblocks umfasst.
Beispiel 5 umfasst den Gegenstand der Beispiele 1 bis 4, wobei der Matrixbeschleuniger Bitmap-Daten mit einer Vielzahl von Teilblock-Bits abruft, die jeweils einem der Vielzahl von Teilblöcken zugeordnet sind.
Beispiel 6 umfasst den Gegenstand der Beispiele 1 bis 5, wobei das Untersuchen des ersten Blocks das Untersuchen eines Teilblock-Bits umfasst, das jedem Teilblock in dem ersten Block zugeordnet ist, um zu bestimmen, ob jeder Teilblock spärliche Daten umfasst.
Beispiel 7 umfasst den Gegenstand der Beispiele 1 bis 6, wobei der Matrixbeschleuniger die erste Kachelgröße auswählt, wenn festgestellt wird, dass jeder Teilblock im ersten Block spärliche Daten umfasst.
Beispiel 8 umfasst den Gegenstand der Beispiele 1 bis 7, wobei der Matrixbeschleuniger die zweite Kachelgröße auswählt, wenn festgestellt wird, dass mindestens ein Teilblock im ersten Block keine spärlichen Daten umfasst.
Einige Ausführungsformen beziehen sich auf Beispiel 9, das ein Verfahren zum Erleichtern von Matrixverarbeitung umfasst, umfassend Empfangen von Eingabematrixdaten, Transformieren der Eingabematrixdaten in eine Vielzahl von Teilblöcken, Untersuchen eines ersten Blocks der Teilblöcke, um zu bestimmen, ob der erste Block spärliche Daten umfasst, Auswählen einer ersten Kachelgröße, wenn bestimmt wird, dass der erste Block spärliche Daten umfasst, und Erzeugen von Ausgabematrixdaten auf Grundlage der ersten Kachelgröße.
Beispiel 10 umfasst den Gegenstand nach Beispiel 9, wobei die erste Kachelgröße eine Größe des ersten Blocks umfasst.
Beispiel 11 umfasst den Gegenstand nach Beispiel 9 und 10, ferner umfassend Auswählen einer zweiten Kachelgröße, wenn festgestellt wird, dass der erste Block keine spärlichen Daten umfasst.
Beispiel 12 umfasst den Gegenstand der Beispiele 9 bis 11, ferner umfassend Abrufen von Bitmap-Daten mit einer Vielzahl von Teilblock-Bits, die jeweils einem der Vielzahl von Teilblöcken zugeordnet sind.
Beispiel 13 umfasst den Gegenstand der Beispiele 9 bis 12, wobei das Untersuchen des ersten Blocks das Untersuchen eines Teilblock-Bits umfasst, das jedem Teilblock in dem ersten Block zugeordnet ist, um zu bestimmen, ob jeder Teilblock spärliche Daten umfasst.
Beispiel 14 umfasst den Gegenstand der Beispiele 9 bis 13, ferner umfassend Auswählen der ersten Kachelgröße, wenn festgestellt wird, dass jeder Teilblock im ersten Block spärliche Daten umfasst, und Auswählen der zweiten Kachelgröße, wenn festgestellt wird, dass mindestens ein Teilblock im ersten Block keine spärlichen Daten umfasst.
Einige Ausführungsformen beziehen sich auf Beispiel 15, das einen Grafikprozessor umfasst, um Eingabematrixdaten zu empfangen, die Eingabematrixdaten in eine Vielzahl von Teilblöcken zu transformieren, einen ersten Block der Teilblöcke zu untersuchen, um zu bestimmen, ob der erste Block spärliche Daten umfasst, eine erste Kachelgröße auszuwählen, wenn bestimmt wird, dass der erste Block spärliche Daten umfasst, und eine systolische Pipeline, um Ausgabematrixdaten auf Grundlage der ersten Kachelgröße zu erzeugen.
Beispiel 16 umfasst den Gegenstand nach Beispiel 15, wobei die erste Kachelgröße eine Größe des ersten Blocks umfasst.
Beispiel 17 umfasst den Gegenstand nach Beispiel 15 und 16, wobei der Matrixbeschleuniger eine zweite Kachelgröße auswählt, wenn festgestellt wird, dass der erste Block keine spärlichen Daten umfasst, wobei die zweite Kachelgröße eine Größe eines Teilblocks umfasst.
Beispiel 18 umfasst den Gegenstand der Beispiele 15 bis 17, wobei der Matrixbeschleuniger Bitmap-Daten mit einer Vielzahl von Teilblock-Bits abruft, die jeweils einem der Vielzahl von Teilblöcken zugeordnet sind.
Beispiel 19 umfasst den Gegenstand der Beispiele 15 bis 18, wobei das Untersuchen des ersten Blocks das Untersuchen eines Teilblock-Bits umfasst, das jedem Teilblock in dem ersten Block zugeordnet ist, um zu bestimmen, ob jeder Teilblock spärliche Daten umfasst.
Beispiel 20 umfasst den Gegenstand der Beispiele 15 bis 19, wobei der Matrixbeschleuniger die erste Kachelgröße auswählt, wenn festgestellt wird, dass jeder Teilblock im ersten Block spärliche Daten umfasst, und die zweite Kachelgröße auswählt, wenn festgestellt wird, dass mindestens ein Teilblock im ersten Block keine spärlichen Daten umfasst.
Die vorstehende Beschreibung und die Zeichnungen als veranschaulichend und nicht einschränkend anzusehen. Ein Fachmann versteht, dass verschiedene Modifikationen und Änderungen an den vorliegend beschriebenen Ausführungsformen vorgenommen werden können, ohne vom allgemeinen Grundgedanken und Umfang der Erfindung wie in den beiliegenden Ansprüchen angegeben abzuweichen.

Claims

Vorrichtung zum Erleichtern von Matrixverarbeitung, umfassend: einen Matrixbeschleuniger, um Eingabematrixdaten zu empfangen, die Eingabematrixdaten in eine Vielzahl von Teilblöcken zu transformieren, einen ersten Block der Teilblöcke zu untersuchen, um zu bestimmen, ob der erste Block spärliche Daten umfasst, eine erste Kachelgröße auszuwählen, wenn bestimmt wird, dass der erste Block spärliche Daten umfasst, und Ausgabematrixdaten auf Grundlage der ersten Kachelgröße zu erzeugen.
Vorrichtung nach Anspruch 1, wobei die erste Kachelgröße eine Größe des ersten Blocks umfasst.
Vorrichtung nach Anspruch 1 oder 2, wobei der Matrixbeschleuniger eine zweite Kachelgröße auswählt, wenn festgestellt wird, dass der erste Block keine spärlichen Daten umfasst.
Vorrichtung nach den Ansprüchen 1 bis 3, wobei die zweite Kachelgröße eine Größe eines Teilblocks umfasst.
Vorrichtung nach den Ansprüchen 1 bis 4, wobei der Matrixbeschleuniger Bitmap-Daten mit einer Vielzahl von Teilblock-Bits abruft, die jeweils einem der Vielzahl von Teilblöcken zugeordnet sind.
Vorrichtung nach den Ansprüchen 1 bis 5, wobei das Untersuchen des ersten Blocks das Untersuchen eines Teilblock-Bits umfasst, das jedem Teilblock in dem ersten Block zugeordnet ist, um zu bestimmen, ob jeder Teilblock spärliche Daten umfasst.
Vorrichtung nach den Ansprüchen 1 bis 6, wobei der Matrixbeschleuniger die erste Kachelgröße auswählt, wenn festgestellt wird, dass jeder Teilblock im ersten Block spärliche Daten umfasst.
Vorrichtung nach den Ansprüchen 1 bis 7, wobei der Matrixbeschleuniger die zweite Kachelgröße auswählt, wenn festgestellt wird, dass mindestens ein Teilblock im ersten Block keine spärlichen Daten umfasst.
Verfahren zum Erleichtern von Matrixverarbeitung, umfassend: Empfangen von Eingabematrixdaten, Transformieren der Eingabematrixdaten in eine Vielzahl von Teilblöcken, Untersuchen eines ersten Blocks der Teilblöcke, um zu bestimmen, ob der erste Block spärliche Daten umfasst, Auswählen einer ersten Kachelgröße, wenn bestimmt wird, dass der erste Block spärliche Daten umfasst, und Erzeugen von Ausgabematrixdaten auf Grundlage der ersten Kachelgröße.
Verfahren nach Anspruch 9, wobei die erste Kachelgröße eine Größe des ersten Blocks umfasst.
Verfahren nach Anspruch 9 oder 10, ferner umfassend Auswählen einer zweiten Kachelgröße, wenn festgestellt wird, dass der erste Block keine spärlichen Daten umfasst.
Verfahren nach den Ansprüchen 9 bis 11, ferner umfassend Abrufen von Bitmap-Daten mit einer Vielzahl von Teilblock-Bits, die jeweils einem der Vielzahl von Teilblöcken zugeordnet sind.
Verfahren nach den Ansprüchen 9 bis 12, wobei das Untersuchen des ersten Blocks das Untersuchen eines Teilblock-Bits umfasst, das jedem Teilblock in dem ersten Block zugeordnet ist, um zu bestimmen, ob jeder Teilblock spärliche Daten umfasst.
Verfahren nach den Ansprüchen 9 bis 13, ferner umfassend: Auswählen der ersten Kachelgröße, wenn bestimmt wird, dass jeder Teilblock in dem ersten Block spärliche Daten umfasst, und Auswählen der zweiten Kachelgröße, wenn festgestellt wird, dass mindestens ein Teilblock im ersten Block keine spärlichen Daten umfasst.
Grafikprozessor, umfassend: einen Matrixbeschleuniger, um Eingabematrixdaten zu empfangen, die Eingabematrixdaten in eine Vielzahl von Teilblöcken zu transformieren, einen ersten Block der Teilblöcke zu untersuchen, um zu bestimmen, ob der erste Block spärliche Daten umfasst, eine erste Kachelgröße auszuwählen, wenn bestimmt wird, dass der erste Block spärliche Daten umfasst, und eine systolische Pipeline, um Ausgabematrixdaten auf Grundlage der ersten Kachelgröße zu erzeugen.
Grafikprozessor nach Anspruch 15, wobei die erste Kachelgröße eine Größe des ersten Blocks umfasst.
Grafikprozessor nach Anspruch 15 oder 16, wobei der Matrixbeschleuniger eine zweite Kachelgröße auswählt, wenn festgestellt wird, dass der erste Block keine spärlichen Daten umfasst, wobei die zweite Kachelgröße eine Größe eines Teilblocks umfasst.
Grafikprozessor nach den Ansprüchen 15 bis 17, wobei der Matrixbeschleuniger Bitmap-Daten mit einer Vielzahl von Teilblock-Bits abruft, die jeweils einem der Vielzahl von Teilblöcken zugeordnet sind.
Grafikprozessor nach den Ansprüchen 15 bis 18, wobei das Untersuchen des ersten Blocks das Untersuchen eines Teilblock-Bits umfasst, das jedem Teilblock in dem ersten Block zugeordnet ist, um zu bestimmen, ob jeder Teilblock spärliche Daten umfasst.
Grafikprozessor nach den Ansprüchen 15 bis 19, wobei der Matrixbeschleuniger die erste Kachelgröße auswählt, wenn festgestellt wird, dass jeder Teilblock im ersten Block spärliche Daten umfasst, und die zweite Kachelgröße auswählt, wenn festgestellt wird, dass mindestens ein Teilblock im ersten Block keine spärlichen Daten umfasst.
Grafikprozessor nach den Ansprüchen 15 bis 20, wobei der Matrixbeschleuniger einen zweiten Block der Teilblöcke untersucht, um festzustellen, ob der zweite Block spärliche Daten umfasst, eine zweite Kachelgröße auswählt, wenn festgestellt wird, dass der zweite Block keine spärlichen Daten umfasst, und Ausgabematrixdaten auf Grundlage der zweiten Kachelgröße erzeugt.