DE102020104651A1

DE102020104651A1 - Arbeitsspeicherkomprimierungs-Hashmechanismus

Info

Publication number: DE102020104651A1
Application number: DE102020104651.0A
Authority: DE
Inventors: Abhishek Appu; Altug Koker; Joydeep Ray; Niranjan Cooray; Prasoonkumar Surti; Sudhakar Kamma; Vasanth Ranganathan
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2019-03-18
Filing date: 2020-02-21
Publication date: 2020-09-24
Also published as: US20200301826A1; US10983906B2; US11593260B2; CN111708718A; US20210255951A1

Abstract

Es wird eine Einrichtung zum Ermöglichen einer Arbeitsspeicherdatenkomprimierung offenbart. Die Einrichtung enthält einen Arbeitsspeicher und weist eine Vielzahl von Bänken, um Hauptdaten und mit den Hauptdaten assoziierte Metadaten zu speichern, und eine Arbeitsspeicherverwaltungseinheit (MMU) auf, die an die Vielzahl von Bänken gekoppelt ist, um eine Hashfunktion durchzuführen, um auf virtuelle Adresspositionen im Arbeitsspeicher zeigende Indizes für die Hauptdaten und Metadaten zu berechnen und die virtuellen Metadaten-Adresspositionen anzupassen, um jede angepasste virtuelle Metadaten-Adressposition in einer Bank zu speichern, die die assoziierten Hauptdaten speichert.

Description

GEBIET DER ERFINDUNG
Diese Erfindung betrifft allgemein Grafikverarbeitung und insbesondere eine Arbeitsspeicherdatenkomprimierung.
HINTERGRUND DER BESCHREIBUNG
Grafikverarbeitungseinheiten (GPUs) sind Maschinen mit hoher Threadanzahl, in denen Hunderte von Threads eines Programms parallel ausgeführt werden, um einen höheren Durchsatz zu erzielen. GPU-Threadgruppen sind in Gitter-Shading-Anwendungen implementiert, um ein dreidimensionales (3D) Rendering durchzuführen. Da GPUs immer komplexer werden und umfangreiche Berechnungen anfordern, besteht die Herausforderung, mit den Anforderungen an die Arbeitsspeicherbandbreite Schritt zu halten. Deshalb ist eine Bandbreitenkomprimierung wesentlich geworden, um sicherzustellen, dass Hardware-/Arbeitsspeichersubsysteme eine erforderliche Bandbreite unterstützen können.
Figurenliste
Damit die Art und Weise, in der die oben genannten Merkmale der vorliegenden Erfindung im Detail verstanden werden können, kann eine detailliertere Beschreibung der Erfindung, die oben kurz zusammengefasst wurden, durch Bezugnahme auf Ausführungsformen erhalten werden, von denen einige in den beigefügten Zeichnungen veranschaulicht sind. Es ist jedoch anzumerken, dass die beigefügten Zeichnungen nur typische Ausführungsformen dieser Erfindung veranschaulichen und deshalb den Geltungsbereich nicht einschränken sollen, da die Erfindung andere gleichermaßen wirksame Ausführungsformen erlauben kann.

1 ist ein Blockdiagramm eines Verarbeitungssystems nach einer Ausführungsform;
2 ist ein Blockdiagramm eines Prozessors nach einer Ausführungsform;
3 ist ein Blockdiagramm eines Grafikprozessors nach einer Ausführungsform;
4 ist ein Blockdiagramm einer Grafikverarbeitungsengine eines Grafikprozessors in Übereinstimmung mit einigen Ausführungsformen;
5 ist ein Blockdiagramm eines Grafikprozessors, der durch eine zusätzliche Ausführungsform bereitgestellt wird;
6A und 6B veranschaulichen eine Threadausführungslogik, die eine Anordnung von Verarbeitungselementen enthält, die in einigen Ausführungsformen eingesetzt wird;
7 ist ein Blockdiagramm, das ein Grafikprozessoranweisungsformat nach einigen Ausführungsformen veranschaulicht;
8 ist ein Blockdiagramm eines Grafikprozessors nach einer anderen Ausführungsform;
9A und 9B veranschaulichen ein Grafikprozessorbefehlsformat und eine Befehlsfolge nach einigen Ausführungsformen;
10 veranschaulicht eine beispielhafte Grafiksoftwarearchitektur für ein Datenverarbeitungssystem nach einigen Ausführungsformen;
11A und 11B sind ein Blockdiagramm, das ein IP-Kernentwiclungssystem nach einer Ausführungsform veranschaulicht;
12 ist ein Blockdiagramm, das einen beispielhaften integrierten Ein-Chip-System-Schaltkreis nach einer Ausführungsform veranschaulicht;
13A und 13B sind ein Blockdiagramm, das einen zusätzlichen beispielhaften Grafikprozessor veranschaulicht;
14A und 14B sind ein Blockdiagramm, das einen zusätzlichen beispielhaften Grafikprozessor eines integrierten Ein-Chip-System-Schaltkreises nach einer Ausführungsform veranschaulicht;
15 veranschaulicht eine Ausführungsform einer Rechenvorrichtung;
16 veranschaulicht eine Ausführungsform einer Grafikverarbeitungseinheit;
17 veranschaulicht eine Ausführungsform eines Arbeitsspeicherraums;
18 veranschaulicht eine Ausführungsform eines umgepackten Arbeitsspeicherraums;
19 veranschaulicht eine Ausführungsform einer Arbeitsspeicherverwaltungseinheit; und
20 ist ein Ablaufdiagramm, das eine Ausführungsform eines Prozesses zum Durchführen von Komprimierungshashing veranschaulicht.

AUSFÜHRLICHE BESCHREIBUNG
In der folgenden detaillierten Beschreibung werden zahlreiche spezifische Details dargelegt, um ein gründlicheres Verständnis der vorliegenden Erfindung zu vermitteln. Es wird jedoch Fachleuten klar sein, dass die vorliegende Erfindung ohne eines oder mehrere dieser spezifischen Details ausgebildet werden kann. In anderen Fällen wurden wohlbekannte Merkmale nicht beschrieben, um zu vermeiden, dass die vorliegende Erfindung verschleiert wird.
In Ausführungsformen führt eine Arbeitsspeicherverwaltungseinheit eine Hashfunktion durch, um auf physische Adresspositionen im Arbeitsspeicher zeigende Indizes für die Hauptdaten und die Metadaten zu berechnen, und passt die physischen Metadaten-Adresspositionen an, um jede angepasste physische Metadaten-Adressposition in einer Bank zu speichern, die die zugehörigen Hauptdaten speichert.
1 ist ein Blockdiagramm eines Verarbeitungssystems 100 nach einer Ausführungsform. In verschiedenen Ausführungsformen enthält das System 100 einen oder mehrere Prozessoren 102 und einen oder mehrere Grafikprozessoren 108 und kann ein Einzelprozessor-Desktopsystem, ein Mehrprozessor-Arbeitsplatzrechnersystem oder ein Serversystem mit einer großen Anzahl an Prozessoren 102 oder Prozessorkernen 107 sein. In einer Ausführungsform ist das System 100 eine Verarbeitungsplattform, die in einen integrierten Ein-Chip-System-Schaltkreis (SoC-Schaltkreis) zur Verwendung in mobilen, tragbaren oder eingebetteten Vorrichtungen eingebunden ist.
In einer Ausführungsform kann das System 100 eine serverbasierte Spieleplattform, eine Spielekonsole, einschließlich einer Spiele- und Medienkonsole, einer mobilen Spielekonsole, einer tragbaren Spielekonsole oder einer Online-Spielekonsole, enthalten oder in eine solche eingebunden sein. In einigen Ausführungsformen ist das System 100 ein Mobiltelefon, ein Smartphone, eine Tabletrechenvorrichtung oder eine mobile Internetvorrichtung. Das Verarbeitungssystem 100 kann auch eine tragbare Vorrichtung, wie eine tragbare Smartwatch-Vorrichtung, eine smarte optische Vorrichtung, erweiterte Realitätsvorrichtung oder virtuelle Realitätsvorrichtung, enthalten, an eine solche koppeln oder in eine solche integriert sein. In einigen Ausführungsformen ist das Verarbeitungssystem 100 ein Fernseher oder eine Set-Top-Box-Vorrichtung mit einem oder mehreren Prozessoren 102 und einer grafischen Schnittstelle, die von einem oder mehreren Grafikprozessoren 108 generiert wird.
In einigen Ausführungsformen enthalten der eine oder die mehreren Prozessoren 102 jeweils einen oder mehrere Prozessorkerne 107, um Anweisungen zu verarbeiten, die bei Ausführung Operationen für System- und Benutzersoftware durchführen. In einigen Ausführungsformen ist jeder des einen oder der mehreren Prozessorkerne 107 ausgelegt, einen bestimmten Anweisungssatz 109 zu verarbeiten. In einigen Ausführungsformen kann der Anweisungssatz 109 ein Rechnen mit komplexem Anweisungssatz (CISC), ein Rechnen mit reduziertem Anweisungssatz (RISC) oder ein Rechnen über ein Very Long Instruction Word (VLIW) ermöglichen. Mehrere Prozessorkerne 107 können jeweils einen anderen Anweisungssatz 109 verarbeiten, der Anweisungen enthalten kann, um die Emulation anderer Anweisungssätze zu ermöglichen. Der Prozessorkern 107 kann auch andere Verarbeitungsvorrichtungen wie einen digitalen Signalprozessor (DSP) enthalten.
In einigen Ausführungsformen enthält der Prozessor 102 einen Zwischenspeicher 104. Abhängig von der Architektur kann der Prozessor 102 einen einzelnen internen Zwischenspeicher oder mehrere Ebenen von internen Zwischenspeichern aufweisen. In einigen Ausführungsformen wird der Zwischenspeicher unter verschiedenen Komponenten des Prozessors 102 gemeinsam genutzt. In einigen Ausführungsformen verwendet der Prozessor 102 auch einen externen Zwischenspeicher (z. B. einen Level-3(L3)-Zwischenspeicher oder einen Last-Level-Zwischenspeicher (LLC)) (nicht gezeigt), der von den Prozessorkernen 107 unter Verwendung bekannter Zwischenspeicherkohärenztechniken gemeinsam genutzt werden kann. Eine Registerdatei 106 ist zusätzlich im Prozessor 102 enthalten, die unterschiedliche Arten von Registern zum Speichern unterschiedlicher Datentypen enthalten kann (z. B. Ganzzahlregister, Gleitkommaregister, Statusregister und ein Anweisungszeigerregister). Einige Register können Universalregister sein, während andere Register für das Design des Prozessors 102 spezifisch sein können.
In einigen Ausführungsformen ist bzw. sind ein oder mehrere Prozessor(en) 102 an einen oder mehrere Schnittstellenbusse 110 gekoppelt, um Kommunikationssignale wie Adressen, Daten oder Steuersignale zwischen dem Prozessor 102 und anderen Komponenten im System 100 zu übertragen. Der Schnittstellenbus 110 kann in einer Ausführungsform ein Prozessorbus, zum Beispiel eine Version des Direct-Media-Interface(DMI)-Busses sein. Prozessorbusse sind jedoch nicht auf den DMI-Bus beschränkt und können einen oder mehrere Peripheral-Component-Interconnect-Busse (z. B. PCI, PCI Express), Arbeitsspeicherbusse oder andere Arten von Schnittstellenbussen enthalten. In einer Ausführungsform enthält bzw. enthalten der Prozessor bzw. die Prozessoren 102 eine integrierte Arbeitsspeichersteuerung 116 und einen Plattformsteuerungshub 130. Die Arbeitsspeichersteuerung 116 ermöglicht eine Kommunikation zwischen einer Arbeitsspeichervorrichtung und anderen Komponenten des Systems 100, während der Plattformsteuerungshub (PCH) 130 Verbindungen mit E/A-Vorrichtungen über einen lokalen E/A-Bus bereitstellt.
Die Arbeitsspeichervorrichtung 120 kann eine dynamische Arbeitsspeichervorrichtung mit wahlfreiem Zugriff (DRAM-Vorrichtung), eine statische Arbeitsspeichervorrichtung mit wahlfreiem Zugriff (SRAM-Vorrichtung), eine Flashspeichervorrichtung, eine Phasenwechselspeichervorrichtung oder eine andere Arbeitsspeichervorrichtung mit geeigneter Leistung sein, um als Prozessarbeitsspeicher zu dienen. In einer Ausführungsform kann die Arbeitsspeichervorrichtung 120 als Systemarbeitsspeicher für das System 100 arbeiten, um Daten 122 und Anweisungen 121 zur Verwendung speichern, wenn der eine oder die mehreren Prozessoren 102 eine Anwendung oder einen Prozess ausführen. Die Arbeitsspeichersteuerung 116 koppelt auch an einen optionalen externen Grafikprozessor 112, 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 kann eine Anzeigevorrichtung 111 mit dem bzw. den Prozessor(en) 102 verbunden sein. Die Anzeigevorrichtung 111 kann eine oder mehrere von einer internen Anzeigevorrichtung, wie zum Beispiel in einer mobilen elektronischen Vorrichtung oder einer Laptopvorrichtung, oder eine externe Anzeigevorrichtung sein, die über eine Anzeigeschnittstelle (z. B. DisplayPort usw.) angebunden ist. In einer Ausführungsform kann die Anzeigevorrichtung 111 eine am Kopf montierte Anzeige (HMD) wie eine stereoskopische Anzeigevorrichtung zur Verwendung in Anwendungen mit virtueller Realität (VR) oder Anwendungen mit erweiterter Realität (AR) sein.
In einigen Ausführungsformen ermöglicht der Plattformsteuerungshub 130, dass Peripherieeinrichtungen über einen Hochgeschwindigkeits-E/A-Bus mit der Arbeitsspeichervorrichtung 120 und dem Prozessor 102 verbunden werden. Die E/A-Peripherieeinrichtungen enthalten unter anderem eine Audiosteuerung 146, eine Netzwerksteuerung 134, eine Firmwareschnittstelle 128, einen drahtlosen Sende-Empfänger 126, Berührungssensoren 125, eine Datenspeichervorrichtung 124 (z. B. ein Festplattenlaufwerk, Flashspeicher usw.). Die Datenspeichervorrichtung 124 kann über eine Speicherschnittstelle (z. B. SATA) oder über einen peripheren Bus, wie einen Peripheral-Component-Interconnect-Bus (z. B. PCI, PCI Express) verbunden sein. Die Berührungssensoren 125 können Berührungsbildschirmsensoren, Drucksensoren oder Fingerabdrucksensoren enthalten. Der drahtlose Sende-Empfänger 126 kann ein WiFi-Sende-Empfänger, ein Bluetooth-Sende-Empfänger oder ein Sende-Empfänger für mobile Netzwerke sein, wie ein 3G-, 4G- oder Long-Term-Evolution(LTE)-Sende-Empfänger. Die Firmwareschnittstelle 128 ermöglicht eine Kommunikation mit Systemfirmware und kann beispielsweise eine vereinheitlichte erweiterbare Firmwareschnittstelle (UEFI) sein. Die Netzwerksteuerung 134 kann eine Netzwerkverbindung mit einem verdrahteten Netzwerk ermöglichen. In einigen Ausführungsformen koppelt eine Hochleistungsnetzwerksteuerung (nicht gezeigt) an den Schnittstellenbus 110. Die Audiosteuerung 146 ist in einer Ausführungsform eine hochauflösende Mehrkanal-Audiosteuerung. In einer Ausführungsform enthält das System 100 eine optionale Alt-E/A-Steuerung 140, um Alt-Vorrichthungen (z. B. Personal System 2 (PS/2) an das System zu koppeln. Der Plattformsteuerungshub 130 kann auch mit einer oder mehreren Universal-Serial-Bus(USB)-Steuerungen 142 verbunden sein, um Eingabevorrichtungen wie Tastatur- und Mauskombinationen 143, eine Kamera 144 oder andere USB-Eingabevorrichtungen anzubinden.
Es ist klar, dass das gezeigte System 100 beispielhaft und nicht einschränkend ist, da andere Arten von Datenverarbeitungssystemen, die unterschiedlich konfiguriert sind, ebenfalls verwendet werden können. Eine Instanz der Arbeitsspeichersteuerung 116 und des Plattformsteuerungshubs 130 kann zum Beispiel in einen diskreten externen Grafikprozessor, wie den externen Grafikprozessor 112 integriert sein. In einer Ausführungsform können der Plattformsteuerungshub 130 und/oder die Arbeitsspeichersteuerung 160 zum einen oder zu den mehreren Prozessoren 102 extern sein. Das System 100 kann zum Beispiel eine externe Arbeitsspeichersteuerung 116 und einen externen Plattformsteuerungshub 130 enthalten, die als ein Arbeitsspeichersteuerungshub und ein peripherer Steuerungshub innerhalb eines Systemchipsatzes konfiguriert sein, der in Kommunikation mit den Prozessoren 102 steht.
2 ist ein Blockdiagramm einer Ausführungsform eines Prozessors 200 mit einem oder mehreren Prozessorkernen 202A-202N, einer integrierten Arbeitsspeichersteuerung 214 und einem integrierten Grafikprozessor 208. Die Elemente von 2, die die gleichen Bezugsziffern (oder Namen) wie die Elemente einer beliebigen anderen Figur hierin aufweisen, können auf eine Weise arbeiten oder funktionieren, die der hierin anderswo beschriebenen ähnlich ist, aber nicht darauf beschränkt ist. Der Prozessor 200 kann zusätzliche Kerne bis zu und enthaltend einen zusätzlichen Kern 202N enthalten, die durch die gestrichelt umrandeten Kästchen dargestellt sind. Jeder der Prozessorkerne 202A-202N enthält eine oder mehrere interne Zwischenspeichereinheiten 204A-204N. In einigen Ausführungsformen weist jeder Prozessorkern auch Zugriff auf eine oder mehrere gemeinsam genutzte Zwischenspeichereinheiten 206 auf.
Die internen Zwischenspeichereinheiten 204A-204N und die gemeinsam genutzten Zwischenspeichereinheiten 206 stellen innerhalb des Prozessors 200 eine Zwischenspeicherhierarchie dar. Die Zwischenspeicherhierarchie kann mindestens eine Ebene von Anweisungs- und Datenzwischenspeicher innerhalb jedes Prozessorkerns und eine oder mehrere Ebenen von gemeinsam genutztem Zwischenspeicher einer mittleren Ebene, wie einen Level-2(L2)-, Level-3(L3)-, Level-4(L4)-Zwischenspeicher oder einen Zwischenspeicher anderer Ebenen, wobei die höchste Zwischenspeicherebene vor dem externen Arbeitsspeicher als LLC klassifiziert ist. In einigen Ausführungsformen hält Zwischenspeicherkohärenzlogik eine Kohärenz zwischen den verschiedenen Zwischenspeichereinheiten 206 und 204A-204N aufrecht.
In einigen Ausführungsformen kann der Prozessor 200 auch einen Satz von einem oder mehreren Bussteuereinheiten 216 und einen Systemagentenkern 210 enthalten. Die eine oder die mehreren Bussteuereinheiten 216 verwalten einen Satz von peripheren Bussen, wie einen oder mehrere PCI- oder PCI-Express-Busse. Der Systemagentenkern 210 bietet Verwaltungsfunktionalität für die verschiedenen Prozessorkomponenten. In einigen Ausführungsformen enthält der Systemagentenkern 210 einen oder mehrere integrierte Arbeitsspeichersteuerungen 214, um den Zugriff auf verschiedene externe Arbeitsspeichervorrichtungen (nicht gezeigt) zu verwalten.
In einigen Ausführungsformen enthalten einer oder mehrere der Kerne 202A-202N Unterstützung für gleichzeitiges Multithreading. In einer derartigen Ausführungsform enthält der Systemagentenkern 210 Komponenten zum Koordinieren und Betreiben der Kerne 202A-202N während einer Multithreadingverarbeitung. Der Systemagentenkern 210 kann zusätzlich eine Leistungssteuereinheit (PCU) enthalten, die Logik und Komponenten enthält, um den Leistungszustand der Prozessorkerne 202A-202N und des Grafikprozessors 208 zu regeln.
In einigen Ausführungsformen enthält der Prozessor 200 zusätzlich einen Grafikprozessor 208, um Grafikverarbeitungsoperationen auszuführen. In einigen Ausführungsformen koppelt der Grafikprozessor 208 an den Satz von gemeinsam genutzten Zwischenspeichereinheiten 206 und den Systemagentenkern 210, einschließlich des einen oder der mehreren integrierten Arbeitsspeichersteuerungen 214. In einigen Ausführungsformen enthält der Systemagentenkern 210 auch eine Anzeigesteuerung 211, um eine Grafikprozessorausgabe zu einer oder mehreren gekoppelten Anzeigen zu lenken. In einigen Ausführungsformen kann die Anzeigesteuerung 211 auch ein separates Modul sein, das über mindestens eine Zwischenverbindung an den Grafikprozessor gekoppelt ist, oder kann innerhalb des Grafikprozessors 208 integriert sein.
In einigen Ausführungsformen wird eine Zwischenverbindungseinheit auf Ringbasis 212 verwendet, um die internen Komponenten des Prozessors 200 zu koppeln. Es kann jedoch eine alternative Zwischenverbindungseinheit verwendet werden, wie zum Beispiel eine Punkt-zu-Punkt-Zwischenverbindung, eine geschaltete Zwischenverbindung oder andere Techniken, einschließlich von Techniken, wie sie auf dem Fachgebiet wohlbekannt sind. In einigen Ausführungsformen koppelt der Grafikprozessor 208 über eine E/A-Verknüpfung 213 an die Ringzwischenverbindung 212.
Die beispielhafte E/A-Verknüpfung 213 stellt mindestens eine von mehreren Varianten von E/A-Zwischenverbindungen dar, einschließlich einer gehäuseinternen E/A-Zwischenverbindung, die eine Kommunikation zwischen verschiedenen Prozessorkomponenten und einem eingebetteten Hochleistungsarbeitsspeichermodul 218 ermöglicht, wie einem eDRAM-Modul. In einigen Ausführungsformen verwenden jeder der Prozessorkerne 202A-202N und der Grafikprozessor 208 eingebettete Arbeitsspeichermodule 218 als einen gemeinsam genutzten Last-Level-Zwischenspeicher.
In einigen Ausführungsformen sind die Prozessorkerne 202A-202N homogene Kerne, die die gleiche Anweisungssatzarchitektur ausführen. In einer anderen Ausführungsform sind die Prozessorkerne 202A-202N in Bezug auf die Anweisungssatzarchitektur (ISA) heterogen, wobei einer oder mehrere der Prozessorkerne 202A-202N einen ersten Anweisungssatz ausführen, während mindestens einer der anderen Kerne eine Teilmenge des ersten Anweisungssatzes oder einen anderen Anweisungssatz ausführt. In einer Ausführungsform sind die Prozessorkerne 202A-202N in Bezug auf die Mikroarchitektur heterogen, wobei ein oder mehrere Kerne einen relativ hohen Leistungsverbrauch aufweisen, während ein oder mehrere Leistungskeme einen niedrigeren Leistungsverbrauch aufweisen. Zusätzlich kann der Prozessor 200 auf einem oder mehreren Chips oder als ein integrierter SoC-Schaltkreis implementiert werden, der zusätzlich zu anderen Komponenten die illustrierten Komponenten aufweist.
3 ist ein Blockdiagramm eines Grafikprozessors 300, der eine diskrete Grafikverarbeitungseinheit sein kann oder ein Grafikprozessor sein kann, der in eine Vielzahl von Verarbeitungskernen integriert ist. In einigen Ausführungsformen kommuniziert der Grafikprozessor über eine in den Arbeitsspeicher abgebildete E/A-Schnittstelle mit Registern auf dem Grafikprozessor und mit in den Prozessorarbeitsspeicher platzierten Befehlen. In einigen Ausführungsformen enthält der Grafikprozessor 300 eine Arbeitsspeicherschnittstelle 314, um auf den Arbeitsspeicher zuzugreifen. Die Arbeitsspeicherschnittstelle 314 kann eine Schnittstelle zu einem lokalen Arbeitsspeicher, einem oder mehreren internen Zwischenspeichern, einem oder mehreren gemeinsam genutzten externen Zwischenspeichern und/oder Systemarbeitsspeicher sein.
In einigen Ausführungsformen enthält der Grafikprozessor 300 auch eine Anzeigesteuerung 302, um eine Anzeigevorrichtung 320 mit Anzeigedaten anzusteuern. Die Anzeigesteuerung 302 enthält Hardware für eine oder mehrere Überlagerungsebenen für die Anzeige und für eine Zusammensetzung mehrerer Schichten von Video oder Benutzerschnittstellenelementen. Die Anzeigevorrichtung 320 kann eine interne oder externe Anzeigevorrichtung sein. In einer Ausführungsform kann die Anzeigevorrichtung 320 eine am Kopf montierte Anzeigevorrichtung wie eine Anzeigevorrichtung mit virtueller Realität (VR) oder eine Anzeigevorrichtung mit erweiterter Realität (AR) sein. In einigen Ausführungsformen enthält der Grafikprozessor 300 eine Videocodecengine 306, um Medien in ein oder mehrere Mediencodierformate zu codieren, aus diesen zu decodieren oder zwischen diesen transcodieren, einschließlich unter anderem Formaten der Moving Picture Experts Group (MPEG) wie MGEG-2, Advanced-Video-Coding(AVC)-Formaten wie H.264/MPEG-4 AVC sowie 421M/VC-1 der Society of Motion Picture & Television Engineers (SMPTE) und Formaten der Joint Photographic Experts Group (JPEG) wie JPEG- und Motion-JPEG(MJPEG)-Formate.
In einigen Ausführungsformen enthält der Grafikprozessor 300 eine Blockbildtransfer(BLIT)-Engine 304, um zweidimensionale (2D) Rasteroperationen einschließlich beispielsweise Bitgrenzen-Blocktransfers. In einer Ausführungsform werden 2D-Grafikoperationen jedoch unter Verwendung einer oder mehrerer Komponenten der Grafikverarbeitungsengine (GPE) 310 durchgeführt. In einigen Ausführungsformen ist GPE 310 eine Rechenengine zum Durchführen von Grafikoperationen, einschließlich von dreidimensionalen (3D) Grafikoperationen und Medienoperationen.
In einigen Ausführungsformen enthält die GPE 310 eine 3D-Pipeline 312 zum Durchführen von 3D-Operationen, wie Rendern von dreidimensionalen Bildern und Szenen unter Verwendung von Verarbeitungsfunktionen, die primitive 3D-Formen (z. B. Rechteck, Dreieck usw.) bearbeiten. Die 3D-Pipeline 312 enthält programmierbare und feste Funktionselemente, die verschiedene Aufgaben innerhalb des Elements durchführen und/oder Ausführungsthreads in einem 3D/Medien-Subsystem 315 zu erzeugen. Während die 3D-Pipeline 312 verwendet werden kann, um Medienoperationen durchzuführen, enthält eine Ausführungsform der GPE 310 auch eine Medienpipeline 316, die spezifisch verwendet wird, um Medienoperationen wie eine Video-Nachbearbeitung und Bildverbesserung durchzuführen.
In einigen Ausführungsformen enthält die Medienpipeline 316 feste Funktions- oder programmierbare Logikeinheiten, um statt der oder im Auftrag der Videocodecengine 306 eine oder mehrere spezialisierte Medienoperationen durchzuführen, wie eine Videocodecbeschleunigung, Videozeilenentflechtung und Videocodierbeschleunigung. In einigen Ausführungsformen enthält die Medienpipeline 316 zusätzlich eine Threaderzeugungseinheit, um Threads zur Ausführung im 3D-Medien-Subsystem 315 zu erzeugen. Die erzeugten Threads führen Berechnungen für die Medienoperationen auf einer oder mehreren Grafikausführungseinheiten durch, die im 3D/Medien-Subsystem 315 enthalten sind.
In einigen Ausführungsformen enthält das 3D/Medien-Subsystem 315 Logik zum Ausführen von Threads, die von der 3D-Pipeline 312 und der Medienpipeline 316 erzeugt wurden. In einer Ausführungsform senden die Pipelines Threadausführungsanforderungen an das 3D/Medien-Subsystem 315, das Threadversandlogik zum Vermitteln und Versenden der verschiedenen Anforderungen an verfügbare Threadausführungsressourcen enthält. Die Ausführungsressourcen enthalten eine Anordnung von Grafikausführungseinheiten, um die 3D- und Medienthreads zu verarbeiten. In einigen Ausführungsformen enthält das 3D/Medien-Subsystem 315 einen oder mehrere interne Zwischenspeicher für Threadanweisungen und Daten. In einigen Ausführungsformen enthält das Subsystem auch gemeinsam genutzten Arbeitsspeicher, einschließlich von Registern und adressierbarem Arbeitsspeicher, um Daten zwischen Threads zu übermitteln und Ausgabedaten zu speichern.
Grafikverarbeitungsengine
4 ist ein Blockdiagramm einer Grafikverarbeitungsengine 410 eines Grafikprozessors in Übereinstimmung mit einigen Ausführungsformen. In einer Ausführungsform ist die Grafikverarbeitungsengine (GPE) 410 eine Version der in 3 gezeigten GPE 310. Elemente von 4, die die gleichen Bezugsziffern (oder Namen) wie die Elemente einer beliebigen anderen Figur hierin aufweisen, können auf eine Weise arbeiten oder funktionieren, die der hierin anderswo beschriebenen ähnlich ist, aber nicht darauf beschränkt ist. Beispielsweise sind die 3D-Pipeline 312 und die Medienpipeline 316 von 3 veranschaulicht. Die Medienpipeline 316 ist in einigen Ausführungsformen der GPE 410 optional und ist möglicherweise nicht explizit in der GPE 410 enthalten. In mindestens einer Ausführungsform ist ein separater Medien- und/oder Bildprozessor an die GPE 410 gekoppelt.
In einigen Ausführungsformen koppelt die GPE 410 eine Befehlsstreamingeinheit 403, die der 3D-Pipeline 312 und/oder den Medienpipelines 316 einen Befehlsstrom bereitstellt. In einigen Ausführungsformen ist die Befehlsstreamingeinheit 403 an Arbeitsspeicher gekoppelt, der Systemarbeitsspeicher oder einer oder mehrerer von einem internen Zwischenspeicher und einem gemeinsam genutzten Zwischenspeicher sein kann. In einigen Ausführungsformen empfängt die Befehlsstreamingeinheit 403 Befehle vom Arbeitsspeicher und sendet die Befehle an die 3D-Pipeline 312 und/oder die Medienpipeline 316. Die Befehle sind Direktiven, die von einem Ringpuffer abgerufen wurden, der Befehle für die 3D-Pipeline 312 und die Medienpipeline 316 speichert. In einer Ausführungsform kann der Ringpuffer zusätzlich Batchbefehlspuffer enthalten, die Batches mehrerer Befehle speichern. Die Befehle für die 3D-Pipeline 312 können auch Bezüge auf im Arbeitsspeicher gespeicherte Daten enthalten, wie zum Beispiel unter anderem Vertex- und Geometriedaten für die 3D-Pipeline 312 und/oder Bilddaten und Arbeitsspeicherobjekte für die Medienpipeline 316. Die 3D-Pipeline 312 und die Medienpipeline 316 verarbeiten die Befehle und Daten durch Durchführen von Operationen durch Logik in den jeweiligen Pipelines oder durch Vergeben eines oder mehrerer Ausführungsthreads an eine Grafikkernanordnung 414. In einer Ausführungsform enthält die Grafikkernanordnung 414 einen oder mehrere Blöcke von Grafikkernen (z. B. Grafikkern(e) 415A, Grafikkern(e) 415B), wobei jeder Block einen oder mehrere Grafikkerne enthält. Jeder Grafikkern enthält einen Satz von Grafikausführungsressourcen, die Universal- und grafikspezifische Ausführungslogik enthalten, um Grafik- und Rechenoperationen durchzuführen, sowie feste Funktionslogik zur Texturverarbeitung und/oder für maschinelles Lernen und Beschleunigung künstlicher Intelligenz.
In verschiedenen Ausführungsformen enthält die 3D-Pipeline 312 feste Funktions- und programmierbare Logik, um ein oder mehrere Shaderprogramme zu verarbeiten, wie Vertexshadern, Geometrieshadern, Pixelshadern, Fragmentshadem, Rechenshadern oder andere Shaderprogramme, durch Verarbeiten der Anweisungen und Vergeben von Ausführungsthreads an die Grafikkernanordnung 414. Die Grafikkernanordnung 414 stellt einen einheitlichen Block mit Ausführungsressourcen zur Verwendung bei der Verarbeitung dieser Shaderprogramme bereit. Mehrzweckausführungslogik (z. B. Ausführungseinheiten) innerhalb des Grafikkerns bzw. der Grafikkerne 415A-414B der Grafikkernanordnung 414 enthält Unterstützung für verschiedene 3D-API-Shadersprachen und kann mehrere gleichzeitige Ausführungsthreads ausführen, die mit mehreren Shadern assoziiert sind.
In einigen Ausführungsformen enthält die Grafikkernanordnung 414 Ausführungslogik, um Medienfunktionen durchzuführen, wie Video- und/oder Bildverarbeitung. In einer Ausführungsform enthalten die Ausführungseinheiten zusätzlich Universallogik, die programmierbar ist, um zusätzlich zu Grafikverarbeitungsoperationen parallele Universalrechenoperationen durchzuführen. Die Universallogik kann Verarbeitungsoperationen parallel oder zusammen mit Universallogik im Prozessorkern bzw. in den Prozessorkernen 107 von 1 oder im Kern 202A-202N wie in 2 durchführen.
Ausgabedaten, die von Threads generiert werden, die auf der Grafikkernanordnung 414 ausgeführt werden, können Daten in den Arbeitsspeicher in einen vereinheitlichten Rückgabepuffer (URB) 418 ausgeben. Der URB 418 kann Daten für mehrere Threads speichern. In einigen Ausführungsformen kann der URB 418 verwendet werden, um Daten zwischen unterschiedlichen Threads zu senden, die auf der Grafikkernanordnung 414 ausgeführt werden. In einigen Ausführungsformen kann der URB 418 zusätzlich zur Synchronisierung zwischen Threads auf der Grafikkernanordnung und fester Funktionslogik in der gemeinsam genutzten Funktionslogik 420 verwendet werden.
In einigen Ausführungsformen ist die Grafikkernanordnung 414 skalierbar, sodass die Anordnung eine variable Anzahl von Grafikkernen enthält, die jeweils eine variable Anzahl von Ausführungseinheiten auf Grundlage der Zielleistung und des Leistungspegels der GEP 410 aufweisen. In einer Ausführungsform sind die Ausführungsressourcen dynamisch skalierbar, sodass die Ausführungsressourcen je nach Bedarf aktiviert oder deaktiviert werden können.
Die Grafikkernanordnung 414 koppelt an die gemeinsam genutzte Funktionslogik 420, die mehrere Ressourcen enthält, die unter den Grafikkernen in der Grafikkernanordnung gemeinsam genutzt werden. Die gemeinsam genutzten Funktionen in der gemeinsam genutzten Funktionslogik 420 sind Hardwarelogikeinheiten, die der Grafikkernanordnung 414 spezialisierte ergänzende Funktionalität bereitstellen. In verschiedenen Ausführungsformen enthält die gemeinsam genutzte Funktionslogik 420 unter anderem Abtaster 421, Mathematik- 422 und Zwischenthreadkommunikationslogik (ITC-Logik) 423. Zusätzlich implementieren einige Ausführungsformen einen oder mehrere Zwischenspeicher 425 in der gemeinsam genutzten Funktionslogik 420.
Eine gemeinsam genutzte Funktion ist implementiert, wenn der Bedarf an einer bestimmten spezialisierten Funktion zur Aufnahme in die Grafikkernanordnung 414 unzureichend ist. Stattdessen ist eine einzelne Instantiierung dieser spezialisierten Funktion als eine eigenständige Entität in der gemeinsam genutzten Funktionslogik 420 implementiert und von den Ausführungsressourcen in der Grafikkernanordnung 414 gemeinsam genutzt. Die genaue Funktionsgruppe, die in der Grafikkernanordnung 414 gemeinsam genutzt ist und in der Grafikkernanordnung 414 enthalten ist, variiert über Ausführungsformen. In einigen Ausführungsformen können bestimmte gemeinsam genutzte Funktionen in der gemeinsam genutzten Funktionslogik 420, die von der Grafikkernanordnung 414 umfangreich genutzt werden, in der gemeinsam genutzten Funktionslogik 416 in der Grafikkernanordnung 414 enthalten sein. In verschiedenen Ausführungsformen kann die gemeinsam genutzte Funktionslogik 416 in der Grafikkernanordnung 414 einige der oder die gesamte Logik in der gemeinsam genutzten Funktionslogik 420 enthalten. In einer Ausführungsform können alle Logikelemente in der gemeinsam genutzten Funktionslogik 420 in der gemeinsam genutzten Funktionslogik 416 der Grafikkernanordnung 414 dupliziert werden. In einer Ausführungsform ist die gemeinsam genutzte Funktionslogik 420 zugunsten der gemeinsam genutzten Funktionslogik 416 in der Grafikkernanordnung 414 ausgeschlossen.
5 ist ein Blockdiagramm von Hardwarelogik eines Grafikprozessorkerns 500 nach einigen hierin beschriebenen Ausführungsformen. Elemente von 5, die die gleichen Bezugsziffern (oder Namen) wie die Elemente einer beliebigen anderen Figur hierin aufweisen, können auf eine Weise arbeiten oder funktionieren, die der hierin anderswo beschriebenen ähnlich ist, aber nicht darauf beschränkt ist. Der illustrierte Grafikprozessorkern 500 ist in einigen Ausführungsformen in der Grafikkernanordnung 414 von 4 enthalten. Der Grafikprozessorkern 500, manchmal als ein Kernsegment bezeichnet, kann ein oder mehrere Grafikkerne in einem modularen Grafikprozessor sein. Der Grafikprozessorkern 500 ist beispielhaft für ein Grafikkernsegment, und ein Grafikprozessor wie hierin beschrieben kann mehrere Grafikkernsegmente auf Grundlage von Zielleistung und Leistungsprofil enthalten. Jeder Grafikkern 500 kann einen festen Funktionsblock 530 enthalten, der an mehrere Teilkerne 501A-501F gekoppelt ist, auch als Teilsegmente bezeichnet, die modulare Blöcke von Universal- und fester Funktionslogik enthalten.
In einigen Ausführungsformen enthält der feste Funktionsblock 530 eine Geometrie-/feste Funktionspipeline 536, die von allen Teilkernen im Grafikprozessor 500 gemeinsam genutzt werden kann, zum Beispiel in Grafikprozessorimplementierungen mit niedrigerer Leistung und/oder niedrigerer Energie. In verschiedenen Ausführungsformen enthält die Geometrie-/feste Funktionspipeline 536 eine feste 3D-Funktionspipeline (z. B. die 3D-Pipeline 312 wie in 3 und 4), eine Video-Front-End-Einheit, einen Threaderzeuger und einen Thread-Dispatcher und eine vereinheitlichte Rückgabepufferverwaltung, die vereinheitlichte Rückgabepuffer verwaltet, wie den vereinheitlichten Rückgabepuffer 418 von 4.
In einer Ausführungsform enthält der feste Funktionsblock 530 auch eine Grafik-SoC-Schnittstelle 537, einen Grafik-Mikrocontroller 538 und eine Medienpipeline 539. Die Grafik-SoC-Schnittstelle 537 bietet eine Schnittstelle zwischen dem Grafikkern 500 und anderen Prozessorkernen innerhalb eines integrierten Ein-Chip-System-Schaltkreises. Der Grafikmikrocontroller 538 ist ein programmierbarer Subprozessor, der konfigurierbar ist, um verschiedene Funktionen des Grafikprozessors 500, einschließlich von Threadversand, Planung und Vorwegnahme zu verwalten. Die Medienpipeline 539 (z. B. die Medienpipeline 316 von 3 und 4) enthält Logik, um das Decodieren, Codieren, Vorverarbeiten und/oder Nachbearbeiten von Multimediadaten, einschließlich Bild- und Videodaten zu ermöglichen. Die Medienpipeline 539 implementiert Medienoperationen über Anforderungen an Rechen- oder Abtastlogik in den Teilkernen 501-501F.
In einer Ausführungsform ermöglicht die SoC-Schnittstelle 537 dem Grafikkern 500, mit Universalanwendungsprozessorkernen (z. B. CPUs) und/oder anderen Komponenten innerhalb eines SoC, einschließlich Arbeitsspeicherhierarchieelementen wie eines gemeinsam genutzten Last-Level-Zwischenspeichers, des System-RAM und/oder eingebettetem chipinternem oder paketinternem DRAM, zu kommunizieren. Die SoC-Schnittstelle 537 kann auch eine Kommunikation mit festen Funktionsvorrichtungen im SoC, wie Kameraabbildungspipelines ermöglichen und ermöglicht die Verwendung von und/oder implementiert globale Arbeitsspeicheratomik, die unter dem Grafikkern 500 und CPUs innerhalb des SoC gemeinsam genutzt werden kann. Die SoC-Schnittstelle 537 kann auch Energieverwaltungssteuerungen für den Grafikkern 500 implementieren und eine Schnittstelle zwischen einer Taktdomäne des Grafikkerns 500 und anderen Taktdomänen innerhalb des SoC ermöglichen. In einer Ausführungsform ermöglicht die SoC-Schnittstelle 537 einen Empfang von Befehlspuffern von einer Befehlsstreamingeinheit und einem globalen Thread-Dispatcher, die ausgelegt sind, jedem von einem oder mehreren Grafikkernen innerhalb eines Grafikprozessors Befehle und Anweisungen bereitzustellen. Die Befehle und Anweisungen können an die Medienpipeline 539 vergeben werden, wenn Medienoperationen durchzuführen sind, oder an eine Geometrie- und feste Funktionspipeline (z. B. die Geometrie- und feste Funktionspipeline 536, die Geometrie- und feste Funktionspipeline 514), wenn Grafikverarbeitungsoperationen durchzuführen sind.
Der Grafikmikrocontroller 538 kann ausgelegt sein, verschiedene Planungs- und Verwaltungsaufgaben für den Grafikkern 500 durchzuführen. In einer Ausführungsform kann der Grafikmikrocontroller 538 eine Grafik- und/oder Rechenarbeitslastplanung an den verschiedenen parallelen Grafikengines innerhalb der Ausführungseinheitsanordnungen (EU-Anordnungen) 502A-502F, 504A-504F innerhalb der Sub-Kerne 501A-501F durchführen. In diesem Planungsmodell kann Hostsoftware, die auf einem CPU-Kern eines SoC ausgeführt wird, das den Grafikkern 500 enthält, Arbeitslasten an eine von mehreren Grafikprozessortürklingeln schicken, die eine Planungsoperation auf der jeweiligen Grafikengine aufruft. Planungsoperationen enthalten ein Ermitteln, welche Arbeitslast als Nächstes auszuführen ist, Übermitteln einer Arbeitslast an eine Befehlsstreamingeinheit, Vorbelegen von bestehenden Arbeitslasten, die auf einer Engine laufen, Überwachen eines Fortschritts einer Arbeitslast und Benachrichtigen einer Hostsoftware, wenn eine Arbeitslast abgeschlossen ist. In einer Ausführungsform kann der Grafikmikrocontroller 538 auch Niedrigenergie- oder Leerlaufzustände für den Grafikkern 500 ermöglichen, was dem Grafikkern 500 die Fähigkeit gibt, Register innerhalb des Grafikkerns 500 über Niedrigenergie-Übergänge hinweg unabhängig vom Betriebssystem und/oder der Grafiktreibersoftware auf dem System Register zu speichern und wiederherzustellen.
Der Grafikkern 500 kann mehr oder weniger als die veranschaulichten Subkerne 501A-501F aufweisen, bis zu N modulare Subkerne. Für jeden Satz von N Subkernen kann der Grafikkern 500 auch gemeinsam genutzte Funktionslogik 510, gemeinsam genutzten Arbeitsspeicher und/oder Zwischenspeicher 512, eine Geometrie-/feste Funktionspipeline 514 sowie zusätzliche feste Funktionslogik 516 enthalten, um verschiedene Grafik- und Rechenverarbeitungsoperationen zu beschleunigen. Die gemeinsam genutzte Funktionslogik 510 kann mit der gemeinsam genutzten Funktionslogik 420 von 4 assoziierte Logikeinheiten enthalten (z. B. Abtast-, Mathematik- und/oder Kommunikationslogik zwischen Threads), die von jedem der N Subkerne innerhalb des Grafikkerns 500 gemeinsam genutzt werden können. Der gemeinsam genutzte Arbeitsspeicher und/oder Zwischenspeicher 512 kann ein Last-Level-Zwischenspeicher für den Satz der N Subkerne 510A-501F innerhalb des Grafikkerns 500 sein und kann auch als gemeinsam genutzter Arbeitsspeicher dienen, auf den von mehreren Subkernen zugegriffen werden kann. Die Geometrie-/feste Funktionspipeline 514 kann anstatt der Geometrie-/festen Funktionspipeline 536 innerhalb des festen Funktionsblocks 530 enthalten sein und kann die gleichen oder ähnliche Logikeinheiten enthalten.
In einer Ausführungsform enthält der Grafikkern 500 eine zusätzliche feste Funktionslogik 516, die verschiedene feste Funktionsbeschleunigungslogik zur Verwendung durch den Grafikkern 500 enthalten kann. In einer Ausführungsform enthält die zusätzliche feste Funktionslogik 516 eine zusätzliche Geometriepipeline zur Verwendung bei Schattierung nur nach Position. Bei Schattierung nur nach Position gibt es zwei Geometriepipelines, die vollständige Geometriepipeline innerhalb der Geometrie-/festen Funktionspipeline 516, 536 und eine Auswahlpipeline, die eine zusätzliche Geometriepipeline ist, die in der zusätzlichen festen Funktionslogik 516 enthalten sein kann. In einer Ausführungsform ist die Auswahlpipeline eine verkürzte Version der vollständigen Geometriepipeline. Die vollständige Pipeline und die Auswahlpipeline können unterschiedliche Instanzen der gleichen Anwendung ausführen, wobei jede Instanz einen separaten Kontext aufweist. Schattierung nur nach Position kann lange Auswahlläufe verworfener Dreiecke verbergen, was in einigen Fällen ermöglicht, dass die Schattierung früher abgeschlossen wird. Beispielsweise und in einer Ausführungsform kann die Auswahlpipeline innerhalb der zusätzlichen festen Funktionslogik 516 Positionsshader parallel zur Hauptanwendung ausführen und erzeugt allgemein wichtige Ergebnisse schneller als die vollständige Pipeline, da die Auswahlpipeline nur das Positionsattribut der Vertices abruft und schattiert, ohne eine Rasterung und ein Rendern der Pixel im Framepuffer durchzuführen. Die Auswahlpipeline kann die erzeugten kritischen Ergebnisse verwenden, um Sichtbarkeitsinformationen für alle Dreiecke unabhängig davon zu berechnen, ob diese Dreiecke ausgewählt sind. Die vollständige Pipeline (die in diesem Fall als eine Wiederholungspipeline bezeichnet werden kann) kann die Sichtbarkeitsinformationen verbrauchen, um die ausgewählten Dreiecke zu überspringen und nur die sichtbaren Dreiecke zu schattieren, die schließlich an die Rasterungsphase weitergegeben werden.
In einer Ausführungsform kann die zusätzliche feste Funktionslogik 516 auch Beschleunigungslogik für maschinelles Lernen enthalten, wie eine feste Funktionsmatrixmultiplikationslogik, für Implementierungen, die Optimierungen zum Training bei maschinellem Lernen oder Schlussfolgerungen enthalten.
Innerhalb jedes Grafik-Subkerns 501A-501F ist ein Satz von Ausführungsressourcen enthalten, die verwendet werden können um Grafik-, Medien- und Rechenoperationen als Reaktion auf Anforderungen von einer Grafikpipeline, einer Medienpipeline oder Shaderprogrammen durchzuführen. Die Grafik-Subkerne 501A-501F enthalten mehrere EU-Anordnungen 502A-502F, 504A-504F, Thread-Dispatch- und Logik zur Kommunikation zwischen Threads (TD/IC) 503A-503F, einen 3D-Abtaster (z. B. Texturabtaster) 505A-505F, einen Medienabtaster 506A-506F, einen Shader-Prozessor 507A-507F und gemeinsam genutzten lokalen Arbeitsspeicher (SLM) 508A-508F. Die EU-Anordnungen 502A-502F, 504A-504F enthalten jeweils mehrere Ausführungseinheiten, die Universalgrafikverarbeitungseinheiten sind, die fähig sind, Gleitkomma- und Ganzzahl-/Fixpunktlogikoperationen im Dienst einer Grafik-, Medien- oder Rechenoperation durchzuführen, einschließlich Grafik-, Medien- oder Rechenshaderprogramme. Die TD/IC-Logik 503A-503F führt lokale Thread-Dispatch- und Threadsteueroperationen für die Ausführungseinheiten innerhalb eines Subkerns durch und ermöglichen eine Kommunikation zwischen Threads, die auf den Ausführungseinheiten des Subkerns ausgeführt werden. Der 3D-Abtaster 505A-505F kann eine Textur oder andere 3D-Grafik-bezogene Daten in einen Arbeitsspeicher lesen. Der 3D-Abtaster kann Texturdaten auf Grundlage eines konfigurierten Abtastzustands und dem mit einer bestimmten Textur assoziierten Texturformat unterschiedlich lesen. Der Medienabtaster 506A-506F kann ähnliche Leseoperationen auf Grundlage des mit Mediendaten assoziierten Typs und Formats durchführen. In einer Ausführungsform kann jeder Grafik-Subkern 501A-501F alternativ einen vereinheitlichten 3D- und Medienabtaster enthalten. Threads, die auf den Ausführungseinheiten in jedem der Subkerne 501A-501F ausgeführt werden, können den gemeinsam genutzten Arbeitsspeicher 508A-508F in jedem Subkern verwenden, um zu ermöglichen, dass Threads, die in einer Threadgruppe ausgeführt werden, unter Verwendung eines gemeinsamen chipinternen Arbeitsspeicherbestands ausgeführt werden.
Ausführungseinheiten
6A-6B veranschaulichen eine Threadausführungslogik 600, die eine Anordnung von Verarbeitungselementen enthält, die in einem Grafikprozessorkern nach hierin beschriebenen Ausführungsformen eingesetzt wird. Elemente von 6A-6B, die die gleichen Bezugsziffern (oder Namen) wie die Elemente einer beliebigen anderen Figur hierin aufweisen, können auf eine Weise arbeiten oder funktionieren, die der hierin anderswo beschriebenen ähnlich ist, aber nicht darauf beschränkt ist. 6A veranschaulicht eine Übersicht von Threadausführungslogik 600, die eine Variante der mit jedem Teilkern 501A-501F von 5 veranschaulichten Hardware enthalten kann. 6B veranschaulicht beispielhafte interne Details einer Ausführungseinheit.
Wie in 6A veranschaulicht, enthält die Threadausführungslogik 600 in einigen Ausführungsformen einen Shaderprozessor 602, einen Thread-Dispatcher 604, einen Anweisungszwischenspeicher 606, eine skalierbare Ausführungseinheitsanordnung, die eine Vielzahl von Ausführungseinheiten 608A-608N enthält, eine Abtasteinheit 610, einen Datenzwischenspeicher 612 und einen Datenanschluss 614. In einer Ausführungsform kann die skalierbare Ausführungseinheitsanordnung dynamisch durch Aktivieren oder Deaktivieren einer oder mehrerer Ausführungseinheiten (z. B. beliebige der Ausführungseinheiten 608A, 608B, 608C, 608D bis 608N-1 und 608N) auf Grundlage der rechnerischen Anforderungen einer Arbeitslast skaliert werden. In einer Ausführungsform sind die enthaltenen Komponenten über eine Zwischenverbindungsfabric verbunden, die mit jeder der Komponenten verknüpft ist. In einigen Ausführungsformen enthält die Threadausführungslogik 600 eine oder mehrere Verbindungen mit einem Arbeitsspeicher, wie einem Systemarbeitsspeicher oder einem Zwischenspeicher, über eines oder mehrere vom Anweisungszwischenspeicher 606, dem Datenanschluss 614, der Abtasteinheit 610 und den Ausführungseinheiten 608A-608N. In einigen Ausführungsformen ist jede Ausführungseinheit (z. B. 608A) eine eigenständige programmierbare Universalrecheneinheit, die fähig ist, mehrere gleichzeitige Hardwarethreads auszuführen, während mehrere Datenelemente parallel für jeden Thread verarbeitet werden. In verschiedenen Ausführungsformen ist die Anordnung von Ausführungseinheiten 608A-608N skalierbar, um eine beliebige Anzahl individueller Ausführungseinheiten aufzunehmen.
In einigen Ausführungsformen werden die Ausführungseinheiten 608A-608N hauptsächlich verwendet, um Shaderprogramme auszuführen. Ein Shaderprozessor 602 kann die verschiedenen Shaderprogramme verarbeiten und Ausführungsthreads, die mit den Shaderprogrammen assoziiert sind, über einen Thread-Dispatcher 604 versenden. In einer Ausführungsform enthält der Thread-Dispatcher Logik, um Threadinitiierungsanforderungen von den Grafik- und Medienpipelines zu vermitteln und die angeforderten Threads auf einer oder mehreren Ausführungseinheiten in den Ausführungseinheiten 608A-608N zu instanziieren. Eine Geometriepipeline kann zum Beispiel Vertex-, Parkettierungs- oder Geometrieshader an die Threadausführungslogik zur Verarbeitung vergeben. In einigen Ausführungsformen kann der Thread-Dispatcher 604 auch Laufzeit-Threaderzeugungsanforderungen von den ausgeführten Shaderprogrammen verarbeiten.
In einigen Ausführungsformen unterstützen die Ausführungseinheiten 608A-608N einen Anweisungssatz, der native Unterstützung für viele Standard-3D-Grafikshaderanweisungen enthält, sodass Shaderprogamme von Grafikbibliotheken (z. B. Direct 3D und OpenGL) mit einer minimalen Übersetzung ausgeführt werden. Die Ausführungseinheiten unterstützen eine Vertex- und Geometrieverarbeitung (z. B. Vertexprogramme, Geometrieprogramme, Vertexshader), eine Pixelverarbeitung (z. B. Pixelshader, Fragmentshader) und eine Universalverarbeitung (z. B. Rechen- und Medienshader). Jede der Ausführungseinheiten 608A-608N ist zu einer mehrfach erteilten Einzelanweisungs-Mehrfachdaten(SIMD)-Ausführung fähig, und eine Operation mit mehreren Threads ermöglicht eine effiziente Ausführungsumgebung angesichts Arbeitsspeicherzugriffe mit höherer Latenz. Jeder Hardwarethread in jeder Ausführungseinheit weist eine dedizierte Registerdatei mit hoher Bandbreite und einen zugehörigen unabhängigen Threadzustand auf. Die Ausführung erfolgt in mehrfacher Erteilung pro Takt an Pipelines, die zu Ganzzahl- und Gleitkommaoperationen mit einfacher und doppelter Genauigkeit, SIMD-Verzweigungsfähigkeit, logischen Operationen, transzendenten Operationen und anderen sonstigen Operationen fähig sind. Während des Wartens auf Daten aus dem Arbeitsspeicher oder von einer der gemeinsam genutzten Funktionen verursacht Abhängigkeitslogik in den Ausführungseinheiten 608A-608N, dass ein wartender Thread im Ruhezustand ist, bis die angeforderten Daten zurückgegeben wurden. Während sich der wartende Thread im Ruhezustand befindet, können Hardwareressourcen dem Verarbeiten anderer Threads gewidmet werden. Während einer mit einer Vertexshaderoperation assoziierten Verzögerung kann eine Ausführungseinheit beispielsweise Operationen für einen Pixelshader, Fragmentshader oder einen anderen Typ von Shaderprogramm durchführen, einschließlich eines anderen Vertexshaders.
Jede Ausführungseinheit in den Ausführungseinheiten 608A-608N arbeitet an Arrays von Datenelementen. Die Anzahl der Datenelemente ist die „Ausführungsgröße“ oder die Anzahl der Kanäle für die Anweisung. Ein Ausführungskanal ist eine logische Einheit der Ausführung zum Zugriff auf Datenelemente, zur Maskierung und Ablaufsteuerung innerhalb von Anweisungen. Die Anzahl der Kanäle kann von der Anzahl der physischen arithmetisch-logischen Einheiten (ALUs) oder Gleitkommaeinheiten (FPUs) für einen bestimmten Grafikprozessor unabhängig sein. In einigen Ausführungsformen unterstützen die Ausführungseinheiten 608A-608N Ganzzahl- und Gleitkomma-Datentypen.
Der Anweisungssatz der Ausführungseinheiten enthält SIMD-Anweisungen. Die verschiedenen Datenelemente können als ein gepackter Datentyp in einem Register gespeichert sein und die Ausführungseinheit verarbeitet die verschiedenen Elemente auf Grundlage der Datengröße der Elemente. Beim Arbeiten an einem 256-Bit breiten Vektor werden die 256 Bits des Vektors zum Beispiel in einem Register gespeichert und die Ausführungseinheit bearbeitet den Vektor als vier separate gepackte 64-Bit-Datenelemente (Datenelemente von Quadwort(QW)-Größe), acht separate gepackte 32-Bit-Datenelemente (Datenelemente von Doppelwort(DW)-Datengröße), sechzehn separate gepackte 16-Bit-Datenelemente (Datenelemente von Wort(W)-Größe) oder zweiunddreißig separate 8-Bit-Datenelemente (Datenelemente von Byte(B)-Größe). Unterschiedliche Vektorbreiten und Registergrößen sind jedoch möglich.
In einer Ausführungsform können eine oder mehrere Ausführungseinheiten in eine verschmolzene Ausführungseinheit 609A-609N mit Threadsteuerlogik (607A-607N) kombiniert werden, die den verschmolzenen EUs gemeinsam ist. Mehrere EUs können in eine EU-Gruppe verschmolzen werden. Jede EU in der verschmolzenen EU-Gruppe kann ausgelegt sein, einen separaten SIMD-Hardwarethread auszuführen. Die Anzahl der EUs in einer verschmolzenen EU-Gruppe kann je nach Ausführungsformen variieren. Darüber hinaus können verschiedene SIMD-Breiten pro EU durchgeführt werden, einschließlich unter anderem SIMD8, SIMD16 und SIMD32. Jede verschmolzene Grafikausführungseinheit 609A-609N enthält mindestens zwei Ausführungseinheiten. Die verschmolzene Ausführungseinheit 609A enthält zum Beispiel eine erste EU 608A, eine zweite EU 608B und Threadsteuerlogik 607A, die der ersten EU 608A und der zweiten EU 608B gemeinsam ist. Die Threadsteuerlogik 607A steuert Threads, die auf der verschmolzenen Grafikausführungseinheit 609A ausgeführt werden, was jeder EU innerhalb den verschmolzenen Ausführungseinheiten 609A-609N ermöglicht, unter Verwendung eines gemeinsamen Anweisungszeigerregisters ausgeführt zu werden.
Ein oder mehrere interne Anweisungszwischenspeicher (z. B. 606) sind in der Threadausführungslogik 600 enthalten, um Threadanweisungen für die Ausführungseinheiten zwischenzuspeichern. In einigen Ausführungsformen sind ein oder mehrere Datenzwischenspeicher (z. B. 612) enthalten, um Threaddaten während der Threadausführung zwischenzuspeichern. In einigen Ausführungsformen ist ein Abtaster 610 enthalten, um eine Texturabtastung für 3D-Operationen und Medienabtastung für Medienoperationen bereitzustellen. In einigen Ausführungsformen enthält der Abtaster 610 spezialisierte Textur- oder Medienabtastfunktionalität, um Textur- oder Mediendaten während des Abtastprozesses vor dem Bereitstellen der abgetasteten Daten an eine Ausführungseinheit zu verarbeiten.
Während der Ausführung senden die Grafik- und Medienpipelines Threadinitiierungsanforderungen über Threaderzeugungs- und Dispatch-Logik an die Threadausführungslogik 600. Sobald eine Gruppe geometrischer Objekte verarbeitet und in Pixeldaten rasterisiert worden ist, wird Pixelprozessorlogik (z. B. Pixelshaderlogik, Fragmentshaderlogik usw.) im Shaderprozessor 602 aufgerufen, um Ausgabeinformationen weiter zu berechnen und bewirken, dass Ergebnisse in Ausgabeflächen (z. B. Farbpuffer, Tiefenpuffer, Schablonenpuffer usw.) geschrieben werden. In einigen Ausführungsformen berechnet ein Pixelshader oder Fragmentshader die Werte der verschiedenen Vertexattribute, die über das rasterisierte Objekt zu interpolieren sind. In einigen Ausführungsformen führt dann Pixelprozessorlogik im Shaderprozessor 602 ein von einer Anwendungsprogrammierschnittstelle (API) geliefertes Pixel- oder Fragmentshaderprogramm durch. Um das Shaderprogramm auszuführen, vergibt der Shaderprozessor 602 Threads über den Thread-Dispatcher 604 an eine Ausführungseinheit (z. B. 608A). In einigen Ausführungsformen verwendet der Shaderprozessor 602 Texturabtastlogik im Abtaster 610, um auf Texturdaten in im Arbeitsspeicher gespeicherten Texturabbildungen zuzugreifen. Arithmetische Operationen an den Texturdaten und den Eingabegeometriedaten berechnen Pixelfarbdaten für jedes geometrische Fragment oder verwerfen ein oder mehrere Pixel von einer weiteren Verarbeitung.
In einigen Ausführungsformen bietet der Datenanschluss 614 einen Arbeitsspeicherzugriffsmechanismus für die Threadausführungslogik 600, um verarbeitete Daten in den Arbeitsspeicher zur weiteren Verarbeitung in einer Grafikprozessorausgabepipeline auszugeben. In einigen Ausführungsformen enthält der Datenanschluss 614 einen oder mehrere Zwischenspeicher (z. B. den Datenzwischenspeicher 612) oder koppelt an diese, um Daten für einen Arbeitsspeicherzugriff über den Datenanschluss zwischenzuspeichern.
Wie in 6B veranschaulicht, kann eine Grafikausführungseinheit 608 eine Anweisungsabrufeinheit 637, eine allgemeine Registerdateianordnung (GRF-Anordnung) 624, eine Architekturregisterdateianordnung (ARF-Anordnung) 626, einen Threadarbiter 622, eine Sendeeinheit 630, eine Verzweigungseinheit 632, einen Satz von SIMD-Gleitkommaeinheiten (FPUs) 634 und in einer Ausführungsform einen Satz von dedizierten Ganzzahl-SIMD-ALUs 635 enthalten. Die GRF 624 und ARF 626 enthalten den Satz von allgemeinen Registerdateien und Architekturregisterdateien, die mit jedem gleichzeitigen Hardwarethread assoziiert sind, die in der Grafikausführungseinheit 608 aktiv sein können. In einer Ausführungsform wird ein architektonischer Zustand pro Thread in der ARF 626 gepflegt, während Daten, die während der Threadausführung verwendet werden, in der GRF 624 gespeichert sind. Der Ausführungszustand jedes Threads, einschließlich der Anweisungszeiger für jeden Thread, kann in threadspezifischen Registern in der ARF 626 gehalten werden.
In einer Ausführungsform weist die Grafikausführungseinheit 608 eine Architektur auf, die eine Kombination von simultanem Multithreading (SMT) und feinkörnigem verschachteltem Multithreading (IMT) ist. Die Architektur weist eine modulare Konfiguration auf, die zum Zeitpunkt des Designs auf Grundlage einer Zielanzahl gleichzeitiger Threads und einer Anzahl von Registern pro Ausführungseinheit feinabgestimmt werden kann, wobei Ausführungseinheitsressourcen über Logik aufgeteilt werden, die verwendet wird, um mehrere gleichzeitige Threads auszuführen.
In einer Ausführungsform kann die Grafikausführungseinheit 608 gemeinsam mehrere Anweisungen erteilen, die jeweils unterschiedliche Anweisungen sein können. Der Threadarbiter 622 des Grafikausführungsthreads 608 kann die Anweisungen an eine der Sendeinheit 630, Verzweigungseinheit 642 oder SIMD-FPU(s) 634 zur Ausführung vergeben. Jeder Ausführungsthread kann auf Universalregister in der GRF 624 zugreifen 128, wo jedes Register 32 Bytes speichern kann, auf die als ein SIMD-8-Element-Vektor aus 32-Bit-Datenelementen zugegriffen werden kann. In einer Ausführungsform weist jeder Ausführungseinheitsthread Zugriff auf 4 kBytes innerhalb der GRF 624 auf, obwohl Ausführungsformen derart nicht eingeschränkt sind und in anderen Ausführungsformen mehr oder weniger Registerressourcen bereitgestellt werden können. In einer Ausführungsform können bis zu sieben Threads gleichzeitig ausgeführt werden, obwohl die Anzahl der Threads pro Ausführungseinheit ebenfalls in Übereinstimmung mit Ausführungsformen variieren kann. In einer Ausführungsform, in der sieben Threads auf 4 kBytes zugreifen können, kann die GRF 624 insgesamt 28 kBytes speichern. Flexible Adressierungsmodi können ermöglichen, dass Register gemeinsam adressiert werden, um effektiv breitere Register zu bilden oder schrittweise rechteckige Blockdatenstrukturen zu repräsentieren.
In einer Ausführungsform werden Arbeitsspeicheroperationen, Abtastoperationen und andere Systemkommunikationen mit längerer Latenz über „Sende“-Anweisungen versandt, die von der Nachrichten übermittelnden Sendeeinheit 630 ausgeführt werden. In einer Ausführungsform werden Verzweigungsanweisungen an eine dedizierte Verzweigungseinheit 632 versandt, um eine SIMD-Divergenz und schließliche Konvergenz zu ermöglichen.
In einer Ausführungsform enthält die Grafikausführungseinheit 608 eine oder mehrere SIMD-Gleitkommaeinheiten (FPU(s)) 634, um Gleitkommaoperationen durchzuführen. In einer Ausführungsform unterstützen die FPU(s) 634 auch eine ganzzahlige Berechnung. In einer Ausführungsform kann bzw. können die FPU(s) 634 bis zuM 32-Bit-Gleitkomma- (oder Ganzzahl-)Operationen via SIMD ausführen oder bis zu 2M 16-Bit-Ganzzahl- oder 16-Bit-Gleitkomma-Operationen via SIMD ausführen. In einer Ausführungsform bietet mindestens eine der FPU(s) erweiterte Mathematikfähigkeiten, um transzendente Mathematikfunktionen mit hohem Durchsatz und 64-Bit-Gleitkomma mit doppelter Genauigkeit zu unterstützen. In einigen Ausführungsformen ist auch eine Gruppe von 8-Bit-Ganzzahl-SIMD-ALUs 635 vorhanden und können spezifisch optimiert sein, um Operationen durchzuführen, die mit Berechnungen für maschinelles Lernen assoziiert sind.
In einer Ausführungsform können Anordnungen mehrerer Instanzen der Grafikausführungseinheit 608 in einer Grafik-Subkerngruppierung (z. B. eines Teilsegments) instanziiert sein. Zur Skalierbarkeit können Produktarchitekten die genaue Anzahl der Ausführungseinheiten pro Subkerngruppierung wählen. In einer Ausführungsform kann die Ausführungseinheit 608 Anweisungen über eine Vielzahl von Ausführungskanälen ausführen. In einer weiteren Ausführungsform wird jeder Thread, der auf der Grafikausführungseinheit 608 ausgeführt wird, in einem anderen Kanal ausgeführt.
7 ist ein Blockdiagramm, das Grafikprozessoranweisungsformate 700 nach einigen Ausführungsformen veranschaulicht. In einer oder mehreren Ausführungsformen unterstützen die Grafikprozessor-Ausführungseinheiten einen Anweisungssatz mit Anweisungen in mehreren Formaten. Die durchgezogen umrandeten Kästchen veranschaulichen die Komponenten, die allgemein in einer Ausführungseinheitsanweisung enthalten sind, während die gestrichelten Linien Komponenten enthalten, die optional sind oder die nur in einer Teilmenge der Anweisungen enthalten sind. In einigen Ausführungsformen des Anweisungsformats 700 sind Makroanweisungen beschrieben und veranschaulicht, dahingehend, dass sie Anweisungen sind, die der Ausführungseinheit geliefert werden, im Gegensatz zu Mikrooperationen, die sich aus einer Decodierung der Anweisung ergeben, sobald die Anweisung verarbeitet wurde.
In einigen Ausführungsformen unterstützen die Grafikprozessor-Ausführungseinheiten nativ Anweisungen in einem 128-Bit-Anweisungsformat 710. Ein kompaktes 64-Bit-Anweisungsformat 730 ist für einige Anweisungen verfügbar, auf Grundlage der ausgewählten Anweisung, der Anweisungsoptionen und der Anzahl der Operanden. 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 nativen Anweisungen, die im 64-Bit-Format 730 verfügbar sind, variieren nach Ausführungsform. In einigen Ausführungsformen wird die Anweisung teilweise unter Verwendung eines Satzes von Indexwerten in einem Indexfeld 713 komprimiert. Die Hardware der Ausführungseinheit nimmt auf Grundlage der Indexwerte auf einen Satz von Komprimierungstabellen Bezug und verwendet die Ausgaben der Komprimierungstabelle, um eine native Anweisung im 128-Bit-Anweisungsformat 710 zu rekonstruieren.
Für jedes Format definiert der Anweisungsopcode 712 die Operation, die die Ausführungseinheit durchzuführen hat. Die Ausführungseinheiten führen jede Anweisung parallel über die mehreren Datenelemente jedes Operanden aus. Beispielsweise führt die Ausführungseinheit als Reaktion auf eine Additionsanweisung eine gleichzeitige Additionsoperation über jeden Farbkanal durch, der ein Texturelement oder Bildelement repräsentiert. Standardmäßig führt die Ausführungseinheit jede Anweisung über alle Datenkanäle der Operanden durch. In einigen Ausführungsformen ermöglicht das Anweisungssteuerfeld 714 eine Steuerung bestimmter Ausführungsoptionen, wie eine Kanalauswahl (z. B. Prädikation) und Datenkanalreihenfolge (z. B. Swizzeln). Für Anweisungen im 128-Bit-Anweisungsformat 710 schränkt ein Ausführungsgrößenfeld 716 die Anzahl der Datenkanäle ein, die parallel ausgeführt werden. In einigen Ausführungsformen steht das Ausführungsgrößenfeld 716 nicht zur Verwendung im kompakten 64-Bit-Anweisungsformat 730 zur Verfügung.
Einige Ausführungseinheitsanweisungen weisen bis zu drei Operanden einschließlich zweier Quelloperanden src0 720, src1 722 und eines Ziels 718 auf. In einigen Ausführungsformen unterstützen die Ausführungseinheiten Anweisungen mit zwei Zielen, wobei eines der Ziele implizit ist. Datenmanipulationsanweisungen können einen dritten Quelloperanden aufweisen (z. B. SRC2 724), wobei der Anweisungsopcode 712 die Anzahl der Quelloperanden bestimmt. Ein letzter Quelloperand einer Anweisung kann ein unmittelbarer (z. B. fest codierter) Wert sein, der mit der Anweisung übergeben wird.
In einigen Ausführungsformen enthält das 128-Bit-Anweisungsformat 710 ein Zugriffs-/Adressmodusfeld 726, das beispielsweise angibt, ob ein direkter Registeradressierungsmodus oder ein indirekter Registeradressierungsmodus verwendet wird. Wenn ein direkter Registeradressierungsmodus verwendet wird, wird die Registeradresse eines oder mehrerer Operanden direkt durch Bits in der Anweisung bereitgestellt.
In einigen Ausführungsformen enthält das 128-Bit-Anweisungsformat 710 ein Zugriffs-/Adressmodusfeld 726, das einen Adressmodus und/oder einen Zugriffsmodus für die Anweisung spezifiziert. In einer Ausführungsform wird der Zugriffsmodus verwendet, um eine Datenzugriffsausrichtung für die Anweisung zu definieren. Einige Ausführungsformen unterstützen Zugriffsmodi, die einen ausgerichteten 16-Byte-Zugriffsmodus und einen ausgerichteten 1-Byte-Zugriffsmodus enthalten, wobei die Byteausrichtung des Zugriffsmodus die Zugriffsausrichtung der Anweisungsoperanden bestimmt. In einem ersten Modus kann die Anweisung zum Beispiel Byte-ausgerichtete Adressierung für Quell- und Zieloperanden verwenden und in einem zweiten Modus kann die Anweisung eine 16-Byte-ausgerichtete Adressierung für alle Quell- und Zieloperanden verwenden.
In einer Ausführungsform bestimmt der Adressmodusabschnitt des Zugriffs-/Adressmodusfelds 726, ob die Anweisung eine direkte oder eine indirekte Adressierung zu verwenden hat. Wenn ein direkter Registeradressierungsmodus verwendet wird, stellen Bits in der Anweisung direkt die Registeradresse eines oder mehrerer Operanden bereit. Wenn ein indirekter Registeradressierungsmodus verwendet wird, kann die Registeradresse eines oder mehrerer Operanden auf Grundlage eines Adressregisterwerts und eines Adressen-Direktfelds in der Anweisung berechnet werden.
In einigen Ausführungsformen werden Anweisungen auf Grundlage von Opcode-Bitfeldern 712 gruppiert, um eine Opcode-Decodierung 740 zu vereinfachen. Für einen 8-Bit-Opcode ermöglichen Bits 4, 5 und 6 der Ausführungseinheit, den Typ von Opcode zu ermitteln. Die präzise gezeigte Opcodegruppierung ist nur ein Beispiel. In einigen Ausführungsformen enthält eine Bewegungs- und Logik-Opcodegruppe 742 Anweisungen zur Datenbewegung und Logikanweisungen (z. B. Bewegen (mov), Vergleichen (cmp)). In einigen Ausführungsformen nutzt die Bewegungs- und Logikgruppe 742 die fünf höchstwertigen Bits (MSB) gemeinsam, wobei Bewegungsanweisungen (mov) die Form von 0000xxxxb haben und Logikanweisungen die Form von 0001xxxxb haben. Eine Ablaufsteuerungsanweisungsgruppe 744 (z. B. Aufruf, Springen (jmp)) enthält Anweisungen in der Form von 0010xxxxb (z. B. 0x20). Eine Gruppe für sonstige Anweisungen 746 enthält eine Mischung von Anweisungen, einschließlich Synchronisierungsanweisungen (z. B. Warten, Senden) in Form von OOllxxxxb (z. B. 0x30). Eine parallele Mathematikanweisungsgruppe 748 enthält komponentenweise arithmetische Anweisungen (z. B. Addieren, Multiplizieren (mul)) in Form von OlOOxxxxb (z. B. 0x40). Die Parallelmathematikgruppe 748 führt die arithmetischen Operationen parallel über Datenkanäle hinweg durch. Die Vektormathematikgruppe 750 enthält arithmetische Anweisungen (z. B. dp4) in Form von 0101xxxxb (z. B. 0x50). Die Vektormathematikgruppe führt Arithmetik wie Skalarproduktberechnungen an Vektoroperanden durch.
Grafikpipeline
8 ist ein Blockdiagramm einer anderen Ausführungsform eines Grafikprozessors 800. Elemente von 8, die die gleichen Bezugsziffern (oder Namen) wie die Elemente einer beliebigen anderen Figur hierin aufweisen, können auf eine Weise arbeiten oder funktionieren, die der hierin anderswo beschriebenen ähnlich ist, aber nicht darauf beschränkt ist.
In einigen Ausführungsformen enthält ein Grafikprozessor 800 eine Geometriepipeline 820, eine Medienpipeline 830, eine Anzeigeengine 840, Threadausführungslogik 850 und eine Ausgaberenderpipeline 870. In einigen Ausführungsformen ist der Grafikprozessor 800 ein Grafikprozessor in einem Mehrkernverarbeitungssystem, das einen oder mehrere Universalverarbeitungskerne enthält. Der Grafikprozessor wird durch Registerschreibvorgänge in ein oder mehrere Steuerregister (nicht gezeigt) oder durch 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 andere Grafikprozessoren oder Universalprozessoren. Befehle von der Ringverbindung 802 werden durch eine Befehlsstreamingeinheit 803 interpretiert, die Anweisungen an individuelle Komponenten der Geometriepipeline 820 oder der Medienpipeline 830 liefert.
In einigen Ausführungsformen leitet die Befehlsstreamingeinheit 803 die Operation einer Vertexabrufeinheit 805, die Vertexdaten aus dem Arbeitsspeicher liest und Vertexverarbeitungsbefehle ausführt, die von der Befehlsstreamingeinheit 803 bereitgestellt werden. In einigen Ausführungsformen stellt die Vertexabrufeinheit 805 einem Vertexshader 807 Vertexdaten bereit, der an jedem Vertex eine Koordinatenraumtransformation und Beleuchtungsoperationen durchführt. In einigen Ausführungsformen führen die Vertexabrufeinheit 805 und der Vertexshader 807 Vertexverarbeitungsanweisungen durch Vergeben von Ausführungsthreads über einen Thread-Dispatcher 831 an die Ausführungseinheiten 852A-852B aus.
In einigen Ausführungsformen sind die Ausführungseinheiten 852A-852B eine Anordnung von Vektorprozessoren mit einem Anweisungssatz zum Durchführen von Grafik- und Medienoperationen. In einigen Ausführungsformen weisen die Ausführungseinheiten 852A-852B einen zugehörigen L1-Zwischenspeicher 851 auf, der für jede Anordnung spezifisch ist oder unter den Anordnungen gemeinsam genutzt wird. Der Zwischenspeicher kann als ein Datenzwischenspeicher, ein Anweisungszwischenspeicher oder ein einzelner Zwischenspeicher konfiguriert sein, der partitioniert ist, um Daten und Anweisungen in unterschiedlichen Partitionen zu enthalten.
In einigen Ausführungsformen enthält die Geometriepipeline 820 Parkettierungskomponenten, um eine hardwarebeschleunigte Parkettierung von 3D-Objekten durchzuführen. In einigen Ausführungsformen konfiguriert ein programmierbarer Frameshader 811 die Parkettierungsoperationen. Ein programmierbarer Domänenshader 817 stellt eine Back-End-Auswertung der Parkettierungsausgabe bereit. Eine Parkettierungseinheit 813 arbeitet auf Anweisung des Frameshaders 811 und enthält Sonderlogik, um auf Grundlage eines groben geometrischen Modells, das als Eingabe in die Geometriepipeline 820 bereitgestellt wurde, einen Satz von detaillierten geometrischen Objekten zu erzeugen. In einigen Ausführungsformen, falls keine Parkettierung verwendet wird, können Parkettierungskomponenten (z. B. der Frameshader 811, die Parkettierungseinheit 813 und der Domänenshader 817) umgangen werden.
In einigen Ausführungsformen können vollständige geometrische Objekte durch einen Geometrieshader 819 über einen oder mehrere Threads verarbeitet werden, die an die Ausführungseinheiten 852A-852B vergeben werden, oder können direkt zum Clipper 829 weitergehen. In einigen Ausführungsformen arbeitet der Geometrieshader an geometrischen Gesamtobjekten anstatt an Vertices oder Gruppen von Vertices, wie in vorangehenden Phasen der Grafikpipeline. Falls die Parkettierung deaktiviert ist, empfängt der Geometrieshader 819 eine Eingabe vom Vertexshader 807. In einigen Ausführungsformen ist der Geometrieshader 819 durch ein Geometrieshaderprogramm programmierbar, um Geometrieparkettierungen durchzuführen, falls die Parkettierungseinheiten deaktiviert sind.
Vor einer Rasterung verarbeitet ein Clipper 829 Vertexdaten. Der Clipper 829 kann ein fester Funktionsclipper oder ein programmierbarer Clipper mit Clipping- und Geometrieshaderfunktionen sein. In einigen Ausführungsformen versendet eine Rasterungs- und Tiefentestkomponente 873 in der Ausgaberenderpipeline 870 Pixelshader, um die geometrischen Objekte in Darstellungen pro Pixel umzuwandeln. In einigen Ausführungsformen ist Pixelshaderlogik in der Threadausführungslogik 850 enthalten. In einigen Ausführungsformen kann eine Anwendung die Rasterungs- und Tiefentestkomponente 873 umgehen und über eine Ausgabestreamingeinheit 823 auf nicht gerasterte Vertexdaten zugreifen.
Der Grafikprozessor 800 weist einen Zwischenverbindungsbus, ein Zwischenverbindungsfabric oder einen anderen Zwischenverbindungsmechanismus auf, der ermöglicht, dass Daten und Nachrichten zwischen den Hauptkomponenten des Prozessors übermittelt werden. In einigen Ausführungsformen sind die Ausführungseinheiten 852A-852B und zugehörige Logikeinheiten (z. B. der L1-Zwischenspeicher 851, der Abtaster 854, der Texturzwischenspeicher 858 usw.) über einen Datenanschluss 856 verbunden, um auf Arbeitsspeicher zuzugreifen und mit Ausgaberenderpipelinekomponenten des Prozessors zu kommunizieren. In einigen Ausführungsformen weisen der Abtaster 854, die Zwischenspeicher 851, 858 und die Ausführungseinheiten 852A-852B jeweils separate Arbeitsspeicherzugriffspfade auf. In einer Ausführungsform kann der Texturzwischenspeicher 858 auch als ein Abtastzwischenspeicher konfiguriert sein.
In einigen Ausführungsformen enthält die Ausgaberenderpipeline 870 eine Rasterungs- und Tiefentestkomponente 873, die vertexbasierte Objekte in eine assoziierte pixelbasierte Darstellung umwandelt. In einigen Ausführungsformen enthält die Rasterungslogik eine Fenster-/Maskierungseinheit, um eine feste Funktions-Dreieck- und Linien-Rasterung durchzuführen. Ein assoziierter Renderzwischenspeicher 878 und Tiefenzwischenspeicher 879 sind ebenfalls in einigen Ausführungsformen verfügbar. Eine Pixeloperationskomponente 877 führt pixelbasierte Operationen an den Daten durch, obwohl mit 2D-Operationen assoziierte Pixeloperationen (z. B. Bitblockbildtransfers mit Mischen) in einigen Fällen von der 2D-Engine 841 durchgeführt werden oder zum Zeitpunkt der Anzeige von der Anzeigesteuerung 843 unter Verwendung von Überlagerungsanzeigeebenen substituiert werden. In einigen Ausführungsformen steht ein gemeinsam genutzter L3-Zwischenspeicher 875 allen Grafikkomponenten zur Verfügung, was das gemeinsame Nutzen von Daten ohne die Verwendung von Hauptsystemarbeitsspeicher ermöglicht.
In einigen Ausführungsformen enthält die Grafikprozessor-Medienpipeline 830 eine Medienengine 837 und ein Video-Front-End 834. In einigen Ausführungsformen empfängt das Video-Front-End 834 Pipelinebefehle von der Befehlsstreamingeinheit 803. In einigen Ausführungsformen enthält die Medienpipeline 830 eine separate Befehlsstreamingeinheit. In einigen Ausführungsformen verarbeitet das Video-Front-End 834 Medienbefehle, bevor es den Befehl an die Medienengine 837 sendet. In einigen Ausführungsformen enthält die Medienengine 837 Threaderzeugungsfunktionalität, um Threads zum Versand über den Thread-Dispatcher 831 an die Threadausführungslogik 850 zu erzeugen.
In einigen Ausführungsformen enthält der Grafikprozessor 800 eine Anzeigeengine 840. In einigen Ausführungsformen ist die Anzeigeengine 840 zum Prozessor 800 extern und koppelt über die Ringzwischenverbindung 802 oder einen anderen Zwischenverbindungsbus oder eine andere Zwischenverbindungsfabric an den Grafikprozessor. In einigen Ausführungsformen enthält die Anzeigeengine 840 eine 2D-Engine 841 und eine Anzeigesteuerung 843. In einigen Ausführungsformen enthält die Anzeigeengine 840 Sonderlogik, die fähig ist, unabhängig von der 3D-Pipeline zu arbeiten. In einigen Ausführungsformen koppelt die Anzeigesteuerung 843 an eine Anzeigevorrichtung (nicht gezeigt), die eine in das System integrierte Anzeigevorrichtung sein kann, wie in einem Laptopcomputer, oder eine externe Anzeigevorrichtung sein kann, die über einen Anzeigevorrichtungsanschluss angebunden ist.
In einigen Ausführungsformen sind die Geometriepipeline 820 und die Medienpipeline 830 konfigurierbar, um Operationen auf Grundlage mehrerer Grafik- und Medienprogrammierschnittstellen durchzuführen, und sind nicht für eine bestimmte Anwendungsprogrammierschnittstelle (API) spezifisch. 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 Unterstützung für die Open Graphics Library (OpenGL), Open Computing Language (OpenCL) und/oder Vulkan-Grafik- und Rechen-API, alle von der Khronos-Gruppe, bereitgestellt. In einigen Ausführungsformen kann Unterstützung auch für die Direct3D-Bibliothek von der Microsoft Corporation bereitgestellt werden. In einigen Ausführungsformen kann eine Kombination dieser Bibliotheken unterstützt werden. Unterstützung kann auch für die Open Source Computer Vision Library (OpenCV) bereitgestellt werden. Eine zukünftige API mit einer kompatiblen 3D-Pipeline würde ebenfalls unterstützt werden, falls eine Abbildung von der Pipeline der zukünftigen API auf die Pipeline des Grafikprozessors erstellt werden kann.
Programmierung der Grafikpipeline
9A ist ein Blockdiagramm, das ein Grafikprozessor-Befehlsformat 900 nach einigen Ausführungsformen veranschaulicht. 9B ist ein Blockdiagramm, das eine Grafikprozessor-Befehlsfolge 910 nach einer Ausführungsform veranschaulicht. Die durchgezogen umrandeten Kästchen in 9A veranschaulichen die Komponenten, die allgemein in einem Grafikbefehl enthalten sind, während die gestrichelten Linien Komponenten enthalten, die optional sind oder die nur in einer Teilmenge der Grafikbefehle enthalten sind. Das beispielhafte Grafikprozessor-Befehlsformat 900 von 9A enthält Datenfelder, um einen Client 902 zu identifizieren, einen Befehlsoperationscode (Opcode) 904 und Daten 906 für den Befehl. Ein Sub-Opcode 905 und eine Befehlsgröße 908 sind in einigen Befehlen ebenfalls enthalten.
In einigen Ausführungsformen gibt der Client 902 die Clienteinheit der Grafikvorrichtung an, die die Befehlsdaten verarbeitet. In einigen Ausführungsformen untersucht ein Grafikprozessor-Befehlsparser das Clientfeld jedes Befehls, um die weitere Verarbeitung des Befehls aufzubereiten und die Befehlsdaten an die passende Clienteinheit zu leiten. In einigen Ausführungsformen enthalten die Grafikprozessor-Clienteinheiten eine Arbeitsspeicherschnittstelleneinheit, eine Rendereinheit, eine 2D-Einheit, eine 3D-Einheit und eine Medieneinheit. Jede Clienteinheit weist eine entsprechende Verarbeitungspipeline auf, die die Befehle verarbeitet. Sobald der Befehl von der Clienteinheit empfangen wurde, liest die Clienteinheit den Opcode 904 und den Sub-Opcode 905, falls vorhanden, um die durchzuführende Operation zu ermitteln. Die Clienteinheit führt den Befehl unter Verwendung von Informationen im Datenfeld 906 durch. Für einige Befehle wird erwartet, dass eine explizite Befehlsgröße 908 die Größe des Befehls angibt. In einigen Ausführungsformen ermittelt der Befehlsparser die Größe von mindestens einigen der Befehle auf Grundlage des Befehlsopcodes. In einigen Ausführungsformen sind die Befehle über Mehrfache eines Doppelworts ausgerichtet.
Das Ablaufdiagramm in 9B veranschaulicht eine beispielhafte Grafikprozessor-Befehlsfolge 910. In einigen Ausführungsformen verwendet Software oder Firmware eines Datenverarbeitungssystems, das eine Ausführungsform eines Grafikprozessors umfasst, eine Version der gezeigten Befehlsfolge, um einen Satz von Grafikoperationen einzurichten, auszuführen und abzuschließen. Eine beispielhafte Befehlsfolge wird nur zu Beispielzwecken gezeigt, da Ausführungsformen nicht auf diese spezifischen Befehle oder auf diese Befehlsfolge beschränkt sind. Darüber hinaus können die Befehle als ein Batch von Befehlen in einer Befehlsfolge erteilt werden, sodass der Grafikprozessor die Befehlsfolge zumindest teilweise gleichzeitig verarbeitet.
In einigen Ausführungsformen kann die Grafikprozessor-Befehlsfolge 910 mit einem Pipelineleerungsbefehl 912 beginnen, um zu bewirken, dass alle aktiven Grafikpipelines die aktuell anstehenden Befehle für die Pipeline abschließen. In einigen Ausführungsformen können die 3D-Pipeline 922 und die Medienpipeline 924 nicht gleichzeitig arbeiten. Die Pipelineleerung wird durchgeführt, um zu veranlassen, dass die aktive Grafikpipeline alle anstehenden Befehle abschließt. Als Reaktion auf eine Pipelineleerung hält der Befehlsparser für den Grafikprozessor eine Befehlsverarbeitung an, bis die aktiven Zeichenengines anstehende Operationen abschließen und die relevanten Lesezwischenspeicher ungültig gemacht sind. Optional können alle Daten im Renderzwischenspeicher, die als verändert‘ markiert sind, in den Arbeitsspeicher geleert werden. In einigen Ausführungsformen kann der Pipelineleerungsbefehl 912 zur Pipelinesynchronisierung oder vor dem Platzieren des Grafikprozessors in einen Ruhezustand verwendet werden.
In einigen Ausführungsformen wird ein Pipelineauswahlbefehl 913 verwendet, wenn eine Befehlsfolge erfordert, dass der Grafikprozessor explizit zwischen Pipelines wechselt. In einigen Ausführungsformen ist ein Pipelineauswahlbefehl 913 nur einmal innerhalb eines Ausführungskontexts erforderlich, bevor Pipelinebefehle erteilt werden, es sei denn, der Kontext hat Befehle für beide Pipelines auszugeben. 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 zum Betrieb und wird verwendet, um die 3D-Pipeline 922 und die Medienpipeline 924 zu programmieren. In einigen Ausführungsformen konfiguriert der Pipelinesteuerbefehl 914 den Pipelinezustand für die aktive Pipeline. In einer Ausführungsform wird der Pipelinesteuerbefehl 914 zur Pipelinesynchronisierung und dazu verwendet, vor dem Verarbeiten eines Batchs von Befehlen Daten aus einem oder mehreren Zwischenspeichern in der aktiven Pipeline zu löschen.
In einigen Ausführungsformen werden Rückgabepufferzustandsbefehle 916 verwendet, um einen Satz von Rückgabepuffern für die jeweiligen Pipelines zum Schreiben von Daten zu konfigurieren. Einige Pipelineoperationen erfordern die Zuordnung, Auswahl oder Konfiguration eines oder mehrerer Rückgabepuffer, in die die Operationen während der Verarbeitung Zwischendaten schreiben. In einigen Ausführungsformen verwendet der Grafikprozessor auch einen oder mehrere Rückgabepuffer, um Ausgabedaten zu speichern und eine threadübergreifende Kommunikation durchzuführen. In einigen Ausführungsformen enthält der Rückgabepufferzustand 916 ein Auswählen der Größe und Anzahl der Rückgabepuffer, die für einen Satz von Pipelineoperationen zu verwenden sind.
Die verbleibenden Befehle in der Befehlsfolge unterscheiden sich auf Grundlage der aktiven Pipeline für Operationen. Auf Grundlage einer Pipelineermittlung 920 ist die Befehlsfolge auf die 3D-Pipeline 922, beginnend mit dem 3D-Pipelinezustand 930, oder die Medienpipeline 924, beginnend mit dem Medienpipelinezustand 940, zugeschnitten.
Die Befehle, um den 3D-Pipelinezustand 930 zu konfigurieren, enthalten Festlegungsbefehle für den 3D-Zustand für den Vertexpufferzustand, Vertexelementzustand, konstanten Farbzustand, Tiefenpufferzustand und andere Zustandsvariablen, die zu konfigurieren sind, bevor primitive 3D-Befehle verarbeitet werden. Die Werte dieser Befehle werden zumindest teilweise auf Basis der bestimmten 3D-API in Verwendung ermittelt. In einigen Ausführungsformen sind 3D-Pipelinezustandsbefehle 930 auch fähig, bestimmte Pipelineelemente selektiv zu deaktivieren oder zu umgehen, falls diese Elemente nicht verwendet werden.
In einigen Ausführungsformen wird ein primitiver 3D-Befehl 932 verwendet, um 3D-Primitiven zu übermitteln, die von der 3D-Pipeline zu verarbeiten sind. Befehle und zugehörige Parameter, die an den Grafikprozessor über den primitiven 3D-Befehl 932 übermittelt werden, werden an die Vertexabruffunktion in der Grafikpipeline weitergeleitet. Die Vertexabruffunktion verwendet die Daten des primitiven 3D-Befehls 932, um Vertexdatenstrukturen zu generieren. Die Vertexdatenstrukturen werden in einem oder mehreren Rückgabepuffern gespeichert. In einigen Ausführungsformen wird der primitive 3D-Befehl 932 verwendet, um über Vertexshader Vertexoperationen an 3D-Primitiven durchzuführen. Um Vertexshader zu verarbeiten, vergibt die 3D-Pipeline 922 Shaderausführungsthreads an Grafikprozessor-Ausführungseinheiten.
In einigen Ausführungsformen wird die 3D-Pipeline 922 über einen Ausführungsbefehl 934 oder ein Ereignis ausgelöst. In einigen Ausführungsformen löst ein Registerschreibvorgang eine Befehlsausführung aus. In einigen Ausführungsformen wird die Ausführung über einen ,Los'- oder ‚Anstoß‘-Befehl in der Befehlsfolge ausgelöst. In einer Ausführungsform wird die Befehlsausführung unter Verwendung eines Pipelinesynchronisationsbefehls ausgelöst, um die Befehlsfolge durch die Grafikpipeline zu spülen. Die 3D-Pipeline führt eine Geometrieverarbeitung für die 3D-Grundbefehle aus. Sobald die Vorgänge abgeschlossen sind, werden die resultierenden geometrischen Objekte gerastert und die Pixelengine färbt die resultierenden Pixel ein. Zusätzliche Befehle, um eine Pixelschattierung und Pixel-Hintergrundoperationen zu steuern, können für diese Operationen auch enthalten sein.
In einigen Ausführungsformen folgt die Grafikprozessor-Befehlsfolge 910 beim Durchführen von Medienoperationen dem Pfad der Medienpipeline 924. Im Allgemeinen hängen die bestimmte Verwendung und die Art der Programmierung für die Medienpipeline 924 von den durchzuführenden Medien- oder Rechenoperationen ab. Spezifische Mediendecodieroperationen können während der Mediendecodierung an die Medienpipeline ausgelagert werden. In einigen Ausführungsformen kann die Medienpipeline auch umgangen werden und eine Mediendecodierung kann gänzlich oder teilweise unter Verwendung von Ressourcen durchgeführt werden, die von einem oder mehreren Universalverarbeitungskernen bereitgestellt werden. In einer Ausführungsform enthält die Medienpipeline auch Elemente für Operationen einer Universalgrafikprozessoreinheit (GPGPU), wobei der Grafikprozessor verwendet wird, um SIMD-Vektoroperationen unter Verwendung von rechnerischen Shaderprogrammen durchzuführen, die nicht explizit mit dem Rendern von Grafikgrundtypen verbunden sind.
In einigen Ausführungsformen ist die Medienpipeline 924 auf eine ähnliche Weise wie die 3D-Pipeline 922 konfiguriert. Ein Befehlssatz, um den Zustand der Medienpipeline 940 zu konfigurieren, wird vor den Medienobjektbefehlen 942 in eine Befehlswarteschlange versandt oder platziert. In einigen Ausführungsformen enthalten die Befehle für den Medienpipelinezustand 940 Daten, um die Medienpipelineelemente zu konfigurieren, die verwendet werden, um die Medienobjekte zu verarbeiten. Dies enthält Daten, um die Videodecodier- und Videocodierlogik in der Medienpipeline zu konfigurieren, wie ein Codier- oder Decodierformat. In einigen Ausführungsformen unterstützen Befehle für den Medienpipelinezustand 940 auch die Verwendung von einem oder mehreren Zeigern auf „indirekte“ Zustandselemente, die eine Gruppe von Zustandseinstellungen enthalten.
In einigen Ausführungsformen liefern Medienobjektbefehle 942 Zeiger auf Medienobjekte zur Verarbeitung durch die Medienpipeline. Die Medienobjekte enthalten Speicherpuffer, die zu verarbeitende Videodaten enthalten. In einigen Ausführungsformen müssen alle Medienpipelinezustände gültig sein, bevor ein Medienobjektbefehl 942 erteilt wird. Sobald der Pipelinezustand konfiguriert ist und die Medienobjektbefehle 942 in die Warteschlange gereiht sind, wird die Medienpipeline 924 über einen Ausführungsbefehl 944 oder ein äquivalentes Ausführungsereignis (z. B. einen Registerschreibvorgang) ausgelöst. Eine Ausgabe von der Medienpipeline 924 kann dann durch von der 3D-Pipeline 922 oder der Medienpipeline 924 bereitgestellte Operationen nachbearbeitet werden. In einigen Ausführungsformen werden GPGPU-Operationen auf eine ähnliche Weise wie Medienoperationen konfiguriert und ausgeführt.
Grafiksoftwarearchitektur
10 veranschaulicht eine beispielhafte Grafiksoftwarearchitektur für ein Datenverarbeitungssystem 1000 nach einigen Ausführungsformen. In einigen Ausführungsformen enthält die Softwarearchitektur eine 3D-Grafikanwendung 1010, ein Betriebssystem 1020 und mindestens einen Prozessor 1030. In einigen Ausführungsformen enthält der Prozessor 1030 einen Grafikprozessor 1032 und einen oder mehrere Universalprozessorkerne 1034. Die Grafikanwendung 1010 und das Betriebssystem 1020 werden jeweils im Systemarbeitsspeicher 1050 des Datenverarbeitungssystems ausgeführt.
In einigen Ausführungsformen enthält die 3D-Grafikanwendung 1010 ein oder mehrere Shaderprogramme, die Shaderanweisungen 1012 enthalten. Die Shader-Sprachanweisungen können in einer höheren Shadersprache, wie der High Level Shader Language (HLSL) oder der OpenGL Shader Language (GLSL) sein. Die Anwendung enthält auch ausführbare Anweisungen 1014 in einer zur Ausführung durch den Universalprozessorkern 1034 geeigneten Maschinensprache. Die Anwendung enthält auch Grafikobjekte 1016, die durch Vertexdaten definiert sind.
In einigen Ausführungsformen ist das Betriebssystem 1020 ein Microsoft® Windows®-Betriebssystem von der Microsoft Corporation, ein proprietäres UNIX-ähnliches Betriebssystem oder ein quelloffenes UNIX-ähnliches Betriebssystem, das eine Variante des Linux-Kernels verwendet. Das Betriebssystem 1020 kann eine Grafik-API 1022 wie die Direct3D-API, die OpenGL-API oder die Vulkan-API unterstützen. Wenn die Direct3D-API in Verwendung ist, verwendet das Betriebssystem 1020 einen Front-End-Shader-Compiler 1024, um eine Shader-Anweisung 1012 in HLSL in eine niedrigere Shadersprache zu compilieren. Die Compilierung kann eine einsatzsynchrone (JIT) Compilierung sein oder die Anwendung kann eine Shader-Vorcompilierung durchführen. In einigen Ausführungsformen werden Shader auf hoher Ebene während der Compilierung der 3D-Grafikanwendung 1010 in Shader auf niedriger Ebene compiliert. In einigen Ausführungsformen werden die Shaderanweisungen 1012 in einer Zwischenform bereitgestellt, wie einer Version der von der Vulkan-API verwendeten Standard Portable Intermediate Representation (SPIR).
In einigen Ausführungsformen enthält ein Benutzermodus-Grafiktreiber 1026 einen Back-End-Shader-Compiler 1027, um die Shaderanweisungen 1012 in eine hardwarespezifische Darstellung umzuwandeln. Wenn die OpenGL-API in Verwendung ist, werden Shaderanweisungen 1012 in der GLSL-Sprache auf hoher Ebene an einen Benutzermodus-Grafiktreiber 1026 zur Compilierung weitergeleitet. In einigen Ausführungsformen verwendet der Benutzermodus-Grafiktreiber 1026 Betriebssystemkernelmodusfunktionen 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 versenden.
IP- Kern-Implementierungen
Ein oder mehrere Gesichtspunkte mindestens einer Ausführungsform können durch repräsentativen Code implementiert sein, der auf einem maschinenlesbaren Medium gespeichert ist, das Logik in einem integrierten Schaltkreis wie einem Prozessor repräsentiert und/oder definiert. Das maschinenlesbare Medium kann zum Beispiel Anweisungen enthalten, die verschiedene Logik im Prozessor repräsentiert. Wenn sie von einer Maschine gelesen werden, können die Anweisungen die Maschine veranlassen, die Logik zu erzeugen, um die hierin beschriebenen Techniken durchzuführen. Derartige Darstellungen, als „IP-Kerne“ bekannt, sind wiederverwendbare Logikeinheiten für einen integrierten Schaltkreis, die auf einem greifbaren, maschinenlesbaren Medium als ein Hardwaremodell gespeichert sein können, das die Struktur des integrierten Schaltkreises beschreibt. Das Hardwaremodell kann an verschiedene Kunden oder Fertigungsanlagen geliefert werden, die das Hardwaremodell in Fertigungsmaschinen laden, die den integrierten Schaltkreis herstellen. Der integrierte Schaltkreis kann so gefertigt werden, dass der Schaltkreis Operationen durchführt, die im Zusammenhang mit beliebigen der hierin beschriebenen Ausführungsformen beschrieben wurden.
11A ist ein Blockdiagramm, das ein IP-Kern-Entwicklungssystem 1100 veranschaulicht, das verwendet werden kann, um einen integrierten Schaltkreis herzustellen, um Operationen nach einer Ausführungsform durchzuführen. Das IP-Kern-Entwicklungssystem 1100 kann verwendet werden, um modulare, wiederverwendbare Designs zu erstellen, die in ein größeres Design eingebunden werden können oder verwendet werden können, um einen gesamten integrierten Schaltkreis (z. B. einen integrierten SOC-Schaltkreis) zu konstruieren. Eine Designanlage 1130 kann eine Softwaresimulation 1110 eines IP-Kern-Designs in einer höheren Programmiersprache (z. B. C/C++) generieren. Die Softwaresimulation 1110 kann verwendet werden, um das Verhalten des IP-Kerns unter Verwendung eines Simulationsmodells 1112 zu konstruieren, testen und zu verifizieren. Das Simulationsmodell 1112 kann funktionale, Verhaltens- und/oder Zeitgebungssimulationen enthalten. Ein Design auf Registertransferebene (RTL) 1115 kann dann erstellt oder aus dem Simulationsmodell 1112 zusammengesetzt werden. Das RTL-Design 1115 ist eine Abstraktion des Verhaltens des integrierten Schaltkreises, das den Fluss digitaler Signale zwischen Hardwareregistern modelliert, einschließlich der assoziierten Logik, die unter Verwendung der modellierten digitalen Signale durchgeführt wird. Zusätzlich zu einem RTL-Design 1115 können auch Designs niedrigerer Ebenen auf Logikebene oder Transistorebene erstellt, konstruiert oder zusammengesetzt werden. Deshalb können die bestimmten Details des anfänglichen Designs und der Simulation variieren.
Das RTL-Design 1115 oder ein äquivalentes können weiter von der Designanlage in ein Hardwaremodell 1120 zusammengesetzt werden, das in einer Hardwarebeschreibungssprache (HDL) oder einer anderen Darstellung von physikalischen Designdaten sein kann. Die HDL kann weiter simuliert oder getestet werden, um das IP-Kern-Design zu verifizieren. Das IP-Kern-Design kann zur Lieferung an eine Fertigungsanlage von Dritten 1165 unter Verwendung von nichtflüchtigem Speicher 1140 (z. B. einer Festplatte, Flashspeicher oder einem beliebigen nichtflüchtigen Speichermedium) gespeichert werden. Alternativ kann das IP-Kern-Design über eine verdrahtete Verbindung 1150 oder drahtlose Verbindung 1160 gesendet (z. B. über das Internet) werden. Die Fertigungsanlage 1165 kann dann einen integrierten Schaltkreis fertigen, der zumindest teilweise auf dem IP-Kern-Design basiert. Der gefertigte integrierte Schaltkreis kann konfiguriert sein, Operationen nach mindestens einer hierin beschriebenen Ausführungsform durchzuführen.
11B veranschaulicht eine seitliche Querschnittsansicht einer integrierten Schaltkreisgehäuseanordnung 1170 nach einigen hierin beschriebenen Ausführungsformen. Die integrierte Schaltkreisgehäuseanordnung 1170 veranschaulicht eine Implementierung eines oder mehrerer Prozessor- oder Beschleunigervorrichtungen, wie sie hierin beschrieben sind. Die Gehäuseanordnung 1170 enthält mehrere Einheiten von Hardwarelogik 1172, 1174, die mit einem Substrat 1180 verbunden sind. Die Logik 1172, 1174 kann zumindest teilweise in konfigurierbarer Logik oder Logikhardware mit fester Funktionalität implementiert sein und kann einen oder mehrere Abschnitte eines der Prozessoren(e), Grafikprozessor(en) oder anderer hierin beschriebenen Beschleunigervorrichtungen enthalten. Jede Logikeinheit 1172, 1174 kann in einem Halbleiterchip implementiert sein und über eine Zwischenverbindungsstruktur 1173 an das Substrat 1180 gekoppelt sein. Die Zwischenverbindungsstruktur 1173 kann konfiguriert sein, elektrische Signale zwischen der Logik 1172, 1174 und dem Substrat 1180 zu leiten und kann Zwischenverbindungen wie unter anderem Lötperlen oder Säulen enthalten. In einigen Ausführungsformen kann die Zwischenverbindungsstruktur 1173 konfiguriert sein, elektrische Signale wie beispielsweise Eingabe/Ausgabe(E/A)-Signale und/oder Leistungs- oder Erdungssignale zu leiten, die mit dem Betrieb der Logik 1172, 1174 assoziiert sind. In einigen Ausführungsformen ist das Substrat 1180 ein Laminatsubstrat auf Epoxidbasis. Die Gehäuseanordnung 1170 kann in anderen Ausführungsformen andere geeignete Typen von Substraten enthalten. Die Gehäuseanordnung 1170 kann über eine Gehäusezwischenverbindung 1183 mit anderen elektrischen Vorrichtungen verbunden sein. Die Gehäusezwischenverbindung 1183 kann an eine Oberfläche des Substrats 1180 gekoppelt sein, um elektrische Signale an andere elektrische Vorrichtungen zu leiten, wie eine Hauptplatine, einen anderen Chipsatz oder ein Mehrchipmodul.
In einigen Ausführungsformen sind die Logikeinheiten 1172, 1174 elektrisch an eine Brücke 1182 gekoppelt, die konfiguriert ist, elektrische Signale zwischen der Logik 1172, 1174 zu leiten. Die Brücke 1182 kann eine dichte Zwischenverbindungsstruktur sein, die eine Route für elektrische Signale bietet. Die Brücke 1182 kann ein Brückensubstrat enthalten, das aus Glas oder einem geeigneten Halbleitermaterial besteht. Elektrische Leitungselemente können auf dem Brückensubstrat gebildet werden, um eine Chip-zu-Chip-Verbindung zwischen der Logik 1172, 1174 bereitzustellen.
Obwohl zwei Logikeinheiten 1172, 1174 und eine Brücke 1182 veranschaulicht sind, können hierin beschriebene Ausführungsformen mehr oder weniger Logikeinheiten auf einem oder mehreren Chips enthalten. Der eine oder die mehreren Chips können durch null oder mehr Brücken verbunden sein, da die Brücke 1182 ausgeschlossen sein kann, wenn die Logik auf einem einzelnen Chip enthalten ist. Alternativ können mehrere Chips oder Logikeinheiten durch eine oder mehrere Brücken verbunden sein. Zusätzlich können mehrere Logikeinheiten und Brücken zusammen in anderen möglichen Konfigurationen verbunden sein, einschließlich dreidimensionaler Konfigurationen.
Beispielhafter integrierter Ein-Chip-System-Schaltkreis
12-14 veranschaulichen beispielhafte integrierte Schaltkreise und zugehörige Grafikprozessoren, die unter Verwendung eines oder mehrerer IP-Kerne nach verschiedenen hierin beschriebenen Ausführungsformen gefertigt werden können. Zusätzlich zu den illustrierten können andere Logik und Schaltkreise enthalten sein, einschließlich zusätzlicher Grafikprozessoren/Kerne, peripherer Schnittstellensteuerungen oder Universalprozessorkerne.
12 ist ein Blockdiagramm, das einen beispielhaften integrierten Ein-Chip-System-Schaltkreis 1200 nach einer Ausführungsform veranschaulicht, der unter Verwendung eines oder mehrerer IP-Kerne gefertigt werden kann. Der beispielhafte integrierte Schaltkreis 1200 enthält einen oder mehrere Anwendungsprozessor(en) 1205 (z. B. CPUs), mindestens einen Grafikprozessor 1210 und kann zusätzlich einen Bildprozessor 1215 und/oder einen Videoprozessor 1220 enthalten, von denen beliebige ein modularer IP-Kern von der gleichen oder mehreren verschiedenen Designanlagen sein können. Der integrierte Schaltkreis 1200 enthält periphere oder Buslogik, die eine USB-Steuerung 1225, eine UART-Steuerung 1230, eine SPI/SDIO-Steuerung 1235 und eine I²S/I²C-Steuerung 1240 enthält. Zusätzlich kann der integrierte Schaltkreis eine Anzeigevorrichtung 1245 enthalten, die an eine oder mehrere von einer High-Definition-Multimedia-Interface(HDMI)-Steuerung 1250 und eine Mobile-Industry-Processor-Interface(MIPI)-Anzeigeschnittstelle 1255 gekoppelt ist. Speicher kann durch ein Flashspeicher-Subsystem 1260 bereitgestellt werden, das Flasharbeitsspeicher und eine Flashspeichersteuerung enthält. Eine Arbeitsspeicherschnittstelle kann über eine Arbeitsspeichersteuerung 1265 zum Zugriff auf SDRAM- oder SRAM-Arbeitsspeichervorrichtungen bereitgestellt werden. Einige integrierte Schaltkreise enthalten zusätzlich eine eingebettete Sicherheitsengine 1270.
13A-13B sind Blockdiagramme, die beispielhafte Grafikprozessoren zur Verwendung innerhalb eines SoC nach hierin beschriebenen Ausführungsformen veranschaulichen. 13A veranschaulicht einen beispielhaften Grafikprozessor 1310 eines integrierten Ein-Chip-System-Schaltkreises nach einer Ausführungsform, der unter Verwendung eines oder mehrerer IP-Kerne gefertigt werden kann. 13B veranschaulicht einen weiteren beispielhaften Grafikprozessor 1340 eines integrierten Ein-Chip-System-Schaltkreises nach einer Ausführungsform, der unter Verwendung eines oder mehrerer IP-Kerne gefertigt werden kann. Der Grafikprozessor 1310 von 13A ist ein Beispiel eines Niedrigenergie-Grafikprozessorkerns. Der Grafikprozessor 1340 von 13B ist ein Beispiel eines Grafikprozessorkerns mit höherer Leistung. Jeder der Grafikprozessoren 1310, 1340 kann eine Variante des Grafikprozessors 1210 von 12 sein.
Wie in 13A gezeigt, enthält der Grafikprozessor 1310 einen Vertexprozessor 1305 und einen oder mehrere Fragmentprozessor(en) 1315A-1315N (z. B. 1315A, 1315B, 1315C, 1315D bis 1315N-1, und 1315N). Der Grafikprozessor 1310 kann über separate Logik unterschiedliche Shaderprogramme ausführen, sodass der Vertexprozessor 1305 optimiert ist, um Operationen für Vertexshaderprogramme auszuführen, während der eine oder die mehreren Fragmentprozessor(en) 1315A-1315N Fragmentschattierungsoperationen (z. B. Pixelschattierungsoperationen) für Fragment- oder Pixelshaderprogramme ausführen. Der Vertexprozessor 1305 führt die Vertexverarbeitungsphase der 3D-Grafikpipeline durch und erzeugt Grundbefehle und Vertexdaten. Der bzw. die Fragmentprozessor(en) 1315A-1315N verwendet bzw. verwenden die vom Vertexprozessor 1305 generierten Grundbefehls- und Vertexdaten, um einen Rahmenpuffer zu erzeugen, der auf einer Anzeigevorrichtung angezeigt wird. In einer Ausführungsform ist bzw. sind der bzw. die Fragmentprozessor(en) 1315A-1315N optimiert, um Fragmentshaderprogramme auszuführen, wie sie in der OpenGL-API vorgesehen sind, die verwendet werden können, um ähnliche Operationen wie ein Pixelshaderprogramm durchzuführen, wie es in der Direct3D-API vorgesehen ist.
Der Grafikprozessor 1310 enthält zusätzlich eine oder mehrere Arbeitsspeicherverwaltungseinheiten (MMUs) 1320A-1320B, Zwischenspeicher 1325A-1325B und Schaltkreiszwischenverbindung(en) 1330A-1330B. Die eine oder die mehreren MMU(s) 1320A-1320B stellen eine virtuelle auf physische Adressenabbildung für den Grafikprozessor 1310 bereit, einschließlich für den Vertexprozessor 1305 und/oder den bzw. die Fragmentprozessor(en) 1315A-1315N, die auf im Arbeitsspeicher gespeicherte Vertex- oder Bild-/Texturdaten Bezug nehmen können, zusätzlich zu in dem einen oder den mehreren Zwischenspeichern 1325A-1325B gespeicherten Vertex- oder Bild-/Texturdaten. In einer Ausführungsform können die eine oder die mehreren MMU(s) 1320A-1320B mit anderen MMUs im System synchronisiert sein, einschließlich einer oder mehreren MMUs, die mit dem einen oder den mehreren Anwendungsprozessor(en) 1205, dem Bildprozessor 1215 und/oder dem Videoprozessor 1220 von 12 assoziiert sind, sodass jeder Prozessor 1205-1220 an einem gemeinsam genutzten oder vereinheitlichten virtuellen Arbeitsspeichersystem teilnehmen kann. Der eine oder die mehreren Schaltkreiszwischenverbindung(en) 1330A-1330B ermöglichen dem Grafikprozessor 1310, an andere IP-Kerne im SoC anzubinden, entweder über einen internen Bus des SoC oder über eine direkte Verbindung, nach Ausführungsformen.
Wie in 13B gezeigt, enthält der Grafikprozessor 1340 eine oder mehrere MMU(s) 1320A-1320B, Zwischenspeicher 1325A-1325B und Schaltkreiszwischenverbindungen 1330A-1330B des Grafikprozessors 1310 von 13A. Der Grafikprozessor 1340 enthält einen oder mehrere Shaderkern(e) 1355A-1355N (z. B. 1455A, 1355B, 1355C, 1355D, 1355E, 1355F bis 1355N-1 und 1355N), was eine einheitliche Shaderkernarchitektur bereitstellt, in der ein einzelner Kern oder Typ oder Kern alle Arten von programmierbarem Shadercode ausführen kann, einschließlich Shaderprogrammcode, um Vertexshader, Fragmentshader und/oder Rechenshader zu implementieren. Die genaue Anzahl der vorhandenen Shaderkerne kann unter Ausführungsformen und Implementierungen variieren. Zusätzlich enthält der Grafikprozessor 1340 eine Zwischenkern-Aufgabenverwaltung 1345, die als ein Thread-Dispatcher fungiert, um Ausführungsthreads an einen oder mehrere Shaderkerne 1355A-1355N und eine Kacheleinheit 1358 zur Beschleunigung von Kacheloperationen für kachelbasiertes Rendering zu versenden, wobei Renderoperationen für eine Szene im Bildraum aufgeteilt werden, zum Beispiel, um eine lokale räumliche Kohärenz innerhalb einer Szene auszunutzen oder eine Verwendung von internen Zwischenspeichern zu optimieren.
14A-14B veranschaulichen zusätzliche beispielhafte Grafikprozessorlogik nach hierin beschriebenen Ausführungsformen. 14A veranschaulicht einen Grafikkern 1400, der im Grafikprozessor 1210 von 12 enthalten sein kann und wie in 13B ein vereinheitlichter Shaderkern 1355A-1355N sein kann. 14B veranschaulicht eine hoch parallele Universalgrafikverarbeitungseinheit 1430, die zum Einsatz in einem Mehrchipmodul geeignet ist.
Wie in 14A gezeigt, enthält der Grafikkern 1400 einen gemeinsam genutzten Anweisungszwischenspeicher 1402, eine Textureinheit 1418 und einen Zwischenspeicher/gemeinsam genutzten Arbeitsspeicher 1420, die den Ausführungsressourcen im Grafikkern 1400 gemeinsam sind. Der Grafikkern 1400 kann mehrere Segmente 1401A-1401N oder Partitionen für jeden Kern enthalten, und ein Grafikprozessor kann mehrere Instanzen des Grafikkerns 1400 enthalten. Die Segmente 1401A-1401N können Unterstützungslogik einschließlich eines lokalen Anweisungszwischenspeichers 1404A-1404N, eines Threadplaners 1406A-1406N, eines Thread-Dispatchers 1408A-1408N und eines Registersatzes 1410A enthalten. Um Logikoperationen durchzuführen, können die Segmente 1401A-1401N einen Satz von zusätzlichen Funktionseinheiten (AFUs 1412A-1412N), Gleitkommaeinheiten (FPU 1414A-1414N), Ganzzahlarithmetik-Logik-Einheiten (ALUs 1416-1416N), Adressenberechnungseinheiten (ACU 1413A-1413N), Gleitkommaeinheiten mit doppelter Genauigkeit (DPFPU 1415A-1415N) und Matrixverarbeitungseinheiten (MPU 1417A-1417N) enthalten.
Einige der Recheneinheiten arbeiten mit einer bestimmten Präzision. Die FPUs 1414A-1414N können beispielsweise Gleitkommaoperationen mit einfacher Genauigkeit (32 Bit) und halber Genauigkeit (16 Bit) durchführen, während die DPFPUs 1415A-1415N Gleitkommaoperationen mit doppelter Genauigkeit (64 Bit) durchführen. Die ALUs 1416A-1416N können Ganzzahloperationen mit variabler Genauigkeit mit 8-Bit-, 16-Bit- und 32-Bit-Genauigkeit durchführen und können für Operationen mit gemischter Genauigkeit konfiguriert sein. Die MPUs 1417A-1417N können auch für Matrixoperationen mit gemischter Genauigkeit konfiguriert sein, einschließlich Gleitkomma-Operationen mit halber Genauigkeit und 8-Bit-Ganzzahloperationen. Die MPUs 1417-1417N können eine Vielfalt von Matrixoperationen durchführen, um Anwendungsrahmen für maschinelles Lernen zu beschleunigen, einschließlich einer Ermöglichung von Unterstützung für beschleunigte allgemeine Matrix-auf-Matrix-Multiplikation (GEMM). Die AFUs 1412A-1412N können zusätzliche Logikoperationen durchführen, die nicht von den Gleitkomma- oder Ganzzahleinheiten unterstützt werden, einschließlich trigonometrischer Operationen (z. B. Sinus, Cosinus usw.).
Wie in 14B gezeigt, kann eine Universalverarbeitungseinheit (GPGPU) 1430 ausgelegt sein, zu ermöglichen, dass hoch parallele Rechenoperationen durch eine Anordnung von Grafikverarbeitungseinheiten durchgeführt werden. Zusätzlich kann die GPGPU 1430 direkt mit anderen Instanzen der GPGPU verknüpft werden, um ein Mehr-GPU-Cluster zu erzeugen, um eine Trainingsgeschwindigkeit für besonders tiefe neuronale Netzwerke zu verbessern. Die GPGPU 1430 enthält eine Hostschnittstelle 1432, um eine Verbindung mit einem Hostprozessor zu ermöglichen. In einer Ausführungsform ist die Hostschnittstelle 1432 eine PCI-Express-Schnittstelle. Die Hostschnittstelle kann jedoch auch eine anbieterspezifische Kommunikationsschnittstelle oder eine Kommunikationsfabric sein. Die GPGPU 1430 empfängt Befehle vom Hostprozessor und verwendet einen globalen Planer 1434, um Ausführungsthreads, die mit diesen Befehlen verbunden sind, an einen Satz von Rechenclustern 1436A-1436H zu verteilen. Die Rechencluster 1436A-1436H nutzen einen Zwischenspeicher 1438 gemeinsam. Der Zwischenspeicher 1438 kann für Zwischenspeicher in den Rechenclustern 1416A-1436H als ein Zwischenspeicher einer höheren Ebene fungieren.
Die GPGPU 1430 enthält Arbeitsspeicher 1434A-1434B, der über einen Satz von Arbeitsspeichersteuerungen an die Rechencluster 1436A-1436H gekoppelt ist. In verschiedenen Ausführungsformen kann der Arbeitsspeicher 1434A-1434B verschiedene Arten von Arbeitsspeichervorrichtungen enthalten, einschließlich dynamischem Arbeitsspeicher mit wahlfreiem Zugriff (DRAM) oder Grafikarbeitsspeicher mit wahlfreiem Zugriff, wie synchronen Grafikarbeitsspeicher mit wahlfreiem Zugriff (SGRAM), einschließlich Grafikarbeitsspeicher mit doppelter Datenrate (GDDR).
In einer Ausführungsform enthalten die Rechencluster 1436A-1436H jeweils einen Satz von Grafikkernen, wie den Grafikkern 1400 von 14A, der mehrere Typen von Ganzzahl- und Gleitkommalogikeinheiten enthalten kann, die Rechenoperationen in Genauigkeitsbereichen durchführen können, einschließlich derer, die für maschinelle Lernberechnungen geeignet sind. Zum Beispiel und in einer Ausführungsform kann zumindest eine Teilmenge der Gleitkommaeinheiten in jedem der Rechencluster 1436A-1436H ausgelegt sein, 16-Bit- oder 32-Bit-Gleitkommaoperationen durchzuführen, während eine andere Teilmenge der Gleitkommaeinheiten ausgelegt sein kann, 64-Bit-Gleitkommaoperationen durchzuführen.
Mehrere Instanzen der GPGPU 1430 können konfiguriert sein, als ein Rechencluster zu arbeiten. Der vom Rechencluster verwendete Kommunikationsmechanismus zur Synchronisierung und zum Datenaustausch variiert über Ausführungsformen hinweg. In einer Ausführungsform kommunizieren die mehreren Instanzen der GPGPU 1430 über die Hostschnittstelle 1432. In einer Ausführungsform enthält die GPGPU 1430 einen E/A-Hub 1439, der die GPGPU 1430 an eine GPU-Verknüpfung 1440 koppelt, die eine direkte Verbindung mit anderen Instanzen der GPGPU ermöglicht. In einer Ausführungsform ist die GPU-Verknüpfung 1440 an eine dedizierte GPU-zu-GPU-Brücke gekoppelt, die eine Kommunikation und Synchronisierung zwischen mehreren Instanzen der GPGPU 1430 ermöglicht. In einer Ausführungsform koppelt die GPU-Verknüpfung 1440 an eine Hochgeschwindigkeitszwischenverbindung, um Daten an andere GPGPUs oder Parallelprozessoren zu senden und empfangen. In einer Ausführungsform befinden sich die mehreren Instanzen der GPGPU 1430 in separaten Datenverarbeitungssystemen und kommunizieren über eine Netzwerkvorrichtung, die über die Hostschnittstelle 1432 zugänglich ist. In einer Ausführungsform kann die GPU-Verknüpfung 1440 ausgelegt sein, eine Verbindung mit einem Hostprozessor zusätzlich zu oder als Alternative zur Hostschnittstelle 1432 zu ermöglichen.
Während die illustrierte Konfiguration der GPGPU 1430 ausgelegt sein kann, neuronale Netze zu trainieren, stellt eine Ausführungsform eine alternative Konfiguration der GPGPU 1430 bereit, die zum Einsatz in einer Hochleistungs- oder Niedrigenergie-Inferenzplattform konfiguriert werden kann. In einer Inferenzkonfiguration enthält die GPGPU 1430 weniger der Rechencluster 1436A-1436H relativ zur Trainingskonfiguration. Zusätzlich kann die mit dem Arbeitsspeicher 1434A-1434B verbundene Arbeitsspeichertechnologie zwischen Inferenz- und Trainingskonfigurationen verschieden sein, wobei Arbeitsspeichertechnologien mit höherer Bandbreite für die Trainingskonfigurationen verwendet werden. In einer Ausführungsform kann die Inferenzkonfiguration der GPGPU 1430 eine Inferenz bestimmter Anweisungen unterstützen. Eine Inferenzkonfiguration kann zum Beispiel Unterstützung für eine oder mehrere 8-Bit-Ganzzahl-Skalarprodukt-Anweisungen bereitstellen, die üblicherweise während Inferenzoperationen für eingesetzte neuronale Netze verwendet werden.
15 veranschaulicht eine Ausführungsform eines Rechensystems 1500. Die Rechenvorrichtung 1500 (z. B. intelligente tragbare Vorrichtungen, Vorrichtungen für virtuelle Realität (VR), kopfmontierte Anzeigen (HMDs), mobile Computer, Vorrichtungen des Internet der Dinge (IdD), Laptopcomputer, Desktopcomputer, Servercomputer usw.) kann die gleiche wie das Verarbeitungssystem 100 von 1 sein und dementsprechend werden der Kürze, der Klarheit und des leichteren Verständnisses halber viele der oben in Bezug auf die 1-14 angegebenen Details hier nachfolgend nicht weiter besprochen oder wiederholt.
Die Rechenvorrichtung 1500 kann eine beliebige Anzahl und einen beliebigen Typ von Kommunikationsvorrichtungen enthalten, wie große Rechensysteme, wie Servercomputer, Desktopcomputer usw., und kann ferner Set-Top-Boxen (z. B. internetbasierte Kabelfernseh-Set-Top-Boxen usw.), Vorrichtungen auf Basis des Global Positioning System (GPS) usw. enthalten. Die Rechenvorrichtung 1500 kann mobile Rechenvorrichtungen enthalten, die als Kommunikationsvorrichtungen dienen, wie Mobiltelefone einschließlich Smartphones, Organizer (PDAs), Tabletcomputer, Laptopcomputer, E-Lesegeräte, Smart-Fernseher, Fernsehplattformen, tragbare Vorrichtungen (z. B. Brillen, Uhren, Armbänder, Smart-Karten, Schmuck, Kleidungsstücke usw.), Medienplayer usw. In einer Ausführungsform kann die Rechenvorrichtung 1500 zum Beispiel eine mobile Rechenvorrichtung enthalten, die eine Computerplattform einsetzt, die einen integrierten Schaltkreis („IC“), wie ein Ein-Chip-System („SoC“ oder „SOC“) hostet, der verschiedene Hardware- und/oder SoftwareKomponenten der Rechenvorrichtung 1500 auf einem einzigen Chip integriert.
Wie veranschaulicht kann die Rechenvorrichtung 1500 in einer Ausführungsform eine beliebige Anzahl und einen beliebigen Typ von Hardware- und/oder Softwarekomponenten enthalten, wie zum Beispiel (ohne Einschränkung) eine GPU 1514, einen Grafiktreiber (auch als „GPU-Treiber“, „Grafiktreiberlogik“, „Treiberlogik“, Benutzermodustreiber (UMD), UMD, Benutzermodus-Treiberframework (UMDF), UMDF oder einfach „Treiber“ bezeichnet) 1516, eine CPU 1512, einen Arbeitsspeicher 1508, Netzwerkvorrichtungen, Treiber oder dergleichen sowie Eingabe/Ausgabe(E/A)-Quellen 1504, wie Berührungsbildschirme, Berührungstafeln, Berührungsfelder, virtuelle oder normale Tastaturen, virtuelle oder normale Mäuse, Anschlüsse, Verbindungsstücke usw.
Die Rechenvorrichtung 1500 kann ein Betriebssystem (OS) 1506 enthalten, das als eine Schnittstelle zwischen Hardware- und/oder physischen Ressourcen der Computervorrichtung 1500 und einem Benutzer dient. Es wird erwogen, dass die CPU 1512 einen oder mehrere Prozessoren enthalten kann, während die GPU 1514 einen oder mehrere Grafikprozessoren enthalten kann.
Es ist anzumerken, dass Begriffe wie „Knoten“, „Rechenknoten“, „Server“, „Servervorrichtung“, „Cloud-Computer“, „Cloud-Server“, „Cloud-Servercomputer“, „Maschine“, „Hostmaschine“, „Vorrichtung“, „Rechenvorrichtung“, „Computer“, „Rechensystem“ und dergleichen in diesem gesamten Dokument austauschbar verwendet werden können. Es ist ferner anzumerken, dass Begriffe wie „Anwendung“, „Softwareanwendung“, „Programm“, „Softwareprogramm“, „Paket“, „Softwarepaket“ und dergleichen in diesem gesamten Dokument austauschbar verwendet werden können. Begriffe wie „Einzelvorgang“, „Eingabe“, „Anforderung“, „Nachricht“ und dergleichen können ebenfalls in diesem gesamten Dokument austauschbar verwendet werden.
Es wird erwogen, dass, wie weiter unter Bezugnahme auf die 1-14 beschrieben, einige Prozesse der Grafikpipeline wie oben beschrieben in Software implementiert sind, während der Rest in Hardware implementiert ist. Eine Grafikpipeline kann in einem Grafik-Coprozessordesign implementiert sein, wobei die CPU 1512 ausgelegt ist, mit der GPU 1514 zusammenzuarbeiten, die in der CPU 1512 enthalten oder zusammen mit dieser untergebracht sein kann. In einer Ausführungsform kann die GPU 1514 eine beliebige Anzahl und einen beliebigen Typ von herkömmlicher Software- und Hardwarelogik, um die herkömmlichen Funktionen durchzuführen, die mit Grafikrendering verbunden sind, sowie neuartige Software- und Hardwarelogik einsetzen, um eine beliebige Anzahl und einen beliebigen Typ von Anweisungen auszuführen.
Wie oben erwähnt, kann der Arbeitsspeicher 1508 einen Arbeitsspeicher mit wahlfreiem Zugriff (RAM) enthalten, der eine Anwendungsdatenbank mit Objektinformationen umfasst. Ein Arbeitsspeichersteuerungshub kann auf Daten im RAM zugreifen und diese an die GPU 1514 zur Verarbeitung durch die Grafikpipeline weiterleiten. Der RAM kann einen RAM mit doppelter Datenrate (DDR-RAM), einen RAM mit erweiterter Datenausgabe (EDO-RAM) usw. enthalten. Die CPU 1512 wechselwirkt mit einer Hardware-Grafikpipeline, um Grafikpipelinefunktionalität gemeinsam zu nutzen.
Verarbeitete Daten werden in einem Puffer in der Hardwaregrafikpipeline gespeichert und Zustandsinformationen werden im Arbeitsspeicher 1508 gespeichert. Das resultierende Bild wird dann an E/A-Quellen 1504, wie eine Anzeigekomponente zum Anzeigen des Bilds, übertragen. Es wird erwogen, dass die Anzeigevorrichtung von verschiedenen Typen sein kann, wie eine Kathodenstrahlröhre (CRT), ein Dünnschichttransistor (TFT), eine Flüssigkristallanzeige (LCD), eine Anordnung aus organischen Licht emittierenden Dioden (OLED) usw., um einem Benutzer Informationen anzuzeigen.
Der Arbeitsspeicher 1508 kann einen vorab zugeteilten Bereich eines Puffers (z. B. Bildspeicher) umfassen; es sollte Fachleuten jedoch klar sein, dass die Ausführungsformen nicht derart eingeschränkt sein können und dass ein beliebiger Arbeitsspeicher, der für die untere Grafikpipeline zugänglich ist, verwendet werden kann. Die Rechenvorrichtung 1500 kann ferner einen Plattformsteuerungshub (PCH) 130, wie er in 1 referenziert ist, als eine oder mehrere E/A-Quellen 1504 usw. enthalten.
Die CPU 1512 kann einen oder mehrere Prozessoren enthalten, um Anweisungen auszuführen, um alle Softwareroutinen durchzuführen, die das Rechensystem implementiert. Die Anweisungen involvieren häufig irgendeine Art von Operation, die an Daten durchgeführt wird. Sowohl Daten als auch Anweisungen können im Systemarbeitsspeicher 1508 und einem zugehörigen Zwischenspeicher gespeichert werden. Der Zwischenspeicher ist üblicherweise so konstruiert, dass er kürzere Latenzzeiten als der Systemarbeitsspeicher 1508 aufweist; der Zwischenspeicher könnte zum Beispiel auf den gleichen Siliziumchip bzw. die gleichen Siliziumchips wie der bzw. die Prozessor(en) integriert sein und/oder mit schnelleren statischen RAM-Zellen (SRAM-Zellen) konstruiert sein, während der Systemarbeitsspeicher 1508 mit langsameren dynamischen RAM-Zellen (DRAM-Zellen) konstruiert sein könnte. Mit der Tendenz, häufiger verwendete Anweisungen und Daten im Zwischenspeicher anstatt im Systemarbeitsspeicher 1508 zu speichern, verbessert sich die gesamte Leistungseffizienz der Rechenvorrichtung 1500. Es wird erwogen, dass die GPU 1514 in einigen Ausführungsformen als Teil der CPU 1512 (wie zum Beispiel als Teil eines physischen CPU-Gehäusepakets) existieren kann, wobei der Arbeitsspeicher 1508 von der CPU 1512 und der GPU 1514 gemeinsam genutzt werden kann oder getrennt gehalten werden kann.
Der Systemarbeitsspeicher 1508 kann anderen Komponenten in der Rechenvorrichtung 1500 zur Verfügung gestellt werden. Irgendwelche Daten (z. B. Eingabegrafikdaten), die von verschiedenen Schnittstellen zur Rechenvorrichtung 1500 (z. B. Tastatur und Maus, Druckeranschluss, lokaler Netzwerkanschluss (LAN-Anschluss), Modemanschluss usw.) empfangen werden oder aus einem internen Speicherelement der Computervorrichtung 1500 (z. B. einem Festplattenlaufwerk) abgerufen werden, werden zum Beispiel temporär in eine Warteschlange in den Systemarbeitsspeicher 1508 gestellt, bevor sie von dem einen oder mehreren Prozessor(en) in der Implementierung eines Softwareprogramms bearbeitet werden. Gleichermaßen, Daten, bei denen ein Softwareprogramm ermittelt, dass sie von der Rechenvorrichtung 1500 an eine Außenentität über eine der Rechensystemschnittstellen gesendet werden oder in ein internes Speicherelement gespeichert werden sollen, werden oft temporär in eine Warteschlange im Systemarbeitsspeicher 1508 gereiht, bevor sie gesendet oder gespeichert werden.
Ferner kann beispielsweise ein PCH verwendet werden, um sicherzustellen, dass derartige Daten richtig zwischen dem Systemarbeitsspeicher 1508 und seiner angemessenen entsprechenden Rechensystemschnittstelle (und internen Speichervorrichtung, falls das Rechensystem derart konstruiert ist) übermittelt werden, und er kann bidirektionale Punkt-zu-Punkt-Verknüpfungen zwischen sich selbst und den beobachteten E/A-Quellen/Vorrichtungen 1504 aufweisen. Gleichermaßen kann ein MCH zum Verwalten der verschiedenen konkurrierenden Anforderungen nach Zugriffen auf den Systemarbeitsspeicher 1508 unter der CPU 1512 und der GPU 1514, Schnittstellen und internen Speicherelementen verwendet werden, die zeitlich nahe in Bezug zueinander auftreten können.
Die E/A-Quellen 1504 können eine oder mehrere E/A-Vorrichtungen enthalten, die zum Transferieren von Daten zu und/oder von der Rechenvorrichtung 1500 implementiert sind (z. B. einen Netzwerkadapter); oder für einen großen nichtflüchtigen Speicher innerhalb der Rechenvorrichtung 1500 (z. B. ein Festplattenlaufwerk). Eine Benutzereingabevorrichtung, einschließlich alphanumerischer und anderer Schlüssel, kann verwendet werden, um Informationen und Befehlsauswahlen an die GPU 1514 zu kommunizieren. Eine weitere Art von Benutzereingabevorrichtung ist eine Cursorsteuerung, wie eine Maus, ein Trackball, ein Berührungsbildschirm, ein Touchpad oder Cursor-Richtungstasten, um Richtungsinformationen und Befehlsauswahlen an die GPU 1514 zu kommunizieren und eine Cursorbewegung auf der Anzeigevorrichtung zu steuern. Kamera- und Mikrofonanordnungen der Computervorrichtung 1500 können eingesetzt werden, um Gesten zu beobachten, Audio und Video aufzuzeichnen und um visuelle und Audio-Befehle zu senden.
Die Rechenvorrichtung 1500 kann ferner eine Netzwerkschnittstelle bzw. Netzwerkschnittstellen enthalten, um Zugang zu einem Netzwerk bereitzustellen, wie einem LAN, einem Weitverkehrsnetz (WAN), einem innerstädtischen Netzwerk (MAN), einem persönlichen Netzwerk (PAN), Bluetooth, einem Cloudnetzwerk, einem mobilen Netzwerk (z. B. der 3. Generation (3G), der 4. Generation (4G) usw.), einem Intranetz, dem Internet usw. Die Netzwerkschnittstelle(n) kann bzw. können zum Beispiel eine drahtlose Netzwerkschnittstelle mit einer Antenne enthalten, die eine oder mehrere Antennen repräsentieren kann. Die Netzwerkschnittstelle(n) kann bzw. können beispielsweise auch eine verdrahtete Netzwerkschnittstelle enthalten, um mit entfernten Vorrichtungen über ein Netzwerkkabel zu kommunizieren, das zum Beispiel ein Ethernetkabel, ein Koaxialkabel, ein Lichtwellenleiterkabel, ein serielles Kabel oder ein paralleles Kabel sein kann.
Die Netzwerkschnittstelle(n) kann bzw. können auch Zugang zu einem LAN bereitstellen, zum Beispiel, indem sie mit IEEE-802.11b- und/oder IEEE-802.11g-Standards konform sind, und/oder die drahtlose Netzwerkschnittstelle kann Zugang zu einem persönlichen Netzwerk bieten, zum Beispiel, indem sie mit Bluetooth-Standards konform ist. Andere drahtlose Netzwerkschnittstellen und/oder Protokolle, einschließlich vorangehender und nachfolgender Versionen der Standards, können ebenfalls unterstützt werden. Über eine Kommunikation über die drahtlosen LAN-Standards hinaus oder statt dieser kann eine bzw. können Netzwerkschnittstelle(n) eine drahtlose Kommunikation beispielsweise unter Verwendung von Zeitmultiplexprotokollen (TDMA), Global-Systems-for-Mobile-Communications(GSM)-Protokollen, Codemultiplexprotokollen (CDMA) und/oder eines beliebigen anderen Typs von drahtlosen Kommunikationsprotokollen bereitstellen.
Die Netzwerkschnittstelle(n) kann bzw. können eine oder mehrere Kommunikationsschnittstellen enthalten, wie ein Modem, eine Netzwerkschnittstellenkarte oder andere gut bekannte Schnittstellenvorrichtungen, wie diejenigen, die zum Koppeln an das Ethernet gekoppelt sind, Token Ring oder andere Arten von physischen verdrahteten oder drahtlosen Anbindungen, um eine Kommunikationsverbindung bereitzustellen, um beispielsweise ein LAN oder ein WAN zu unterstützen. Auf diese Weise kann das Computersystem auch über eine herkömmliche Netzwerkinfrastruktur, einschließlich zum Beispiel eines Intranets oder des Internets, an eine Anzahl von peripheren Vorrichtungen, Clients, Steuerflächen, Konsolen oder Server gekoppelt sein.
Es muss klar sein, dass ein weniger oder mehr ausgestattetes System als das oben beschriebene Beispiel für bestimmte Implementierungen bevorzugt werden kann. Deshalb kann die Konfiguration der Rechenvorrichtung 1500 von Implementierung zu Implementierung abhängig von zahlreichen Faktoren variieren, wie preisbedingte Einschränkungen, Leistungsanforderungen, technologischen Verbesserungen und anderen Umständen. Beispiele der elektronischen Vorrichtung oder des Computersystems 1500 können (ohne Einschränkung) eine mobile Vorrichtung, einen Organizer, eine mobile Rechenvorrichtung, ein Smartphone, ein Mobiltelefon, einen Handapparat, einen Einweg-Funkrufempfänger, einen Zweiweg-Funkrufempfänger, eine Nachrichtensendevorrichtung, einen Computer, einen Personalcomputer (PC), einen Desktopcomputer, einen Laptopcomputer, einen Notebookcomputer, einen tragbaren Computer, einen Tabletcomputer, einen Server, ein Serverarray oder eine Serverfarm, einen Webserver, einen Netzwerkserver, einen Internet-Server, eine Arbeitsstation, einen Minicomputer, einen Mainframecomputer, einen Supercomputer, ein Netzwerkgerät, ein Webgerät, ein verteiltes Rechensystem, Mehrprozessorsysteme, prozessorbasierte Systeme, Endverbraucherelektronik, programmierbare Endverbraucherelektronik, Fernseher, Digitalfernseher, eine Set-Top-Box, einen drahtlosen Zugangspunkt, eine Basisstation, eine Teilnehmerstation, ein mobiles Teilnehmerzentrum, eine Funknetzsteuerung, einen Router, einen Hub, ein Gateway, eine Brücke, einen Switch, eine Maschine oder Kombinationen davon enthalten.
Ausführungsformen können als ein beliebiges von oder eine Kombination von Folgendem implementiert sein: einem oder mehreren Mikrochips oder integrierten Schaltkreisen, die unter Verwendung einer übergeordneten Leiterplatte verbunden sind, festverdrahteter Logik, von einer Arbeitsspeichervorrichtung gespeicherter und von einem Mikroprozessor ausgeführter Software, Firmware, einem anwendungsspezifischen integrierten Schaltkreis (ASIC) und/oder einem feldprogrammierbaren Gatearray (FPGA). Der Begriff „Logik“ kann beispielsweise Software oder Hardware und/oder Kombinationen von Software und Hardware enthalten.
Ausführungsformen können zum Beispiel als ein Computerprogrammprodukt bereitgestellt werden, das ein oder mehrere maschinenlesbare Medien mit darauf gespeicherten maschinenausführbaren Anweisungen enthalten kann, die bei Ausführung durch eine oder mehrere Maschinen wie einem Computer, einem Netzwerk von Computern oder anderen elektronischen Vorrichtungen dazu führen können, dass die eine oder die mehreren Maschinen Operationen in Übereinstimmung mit hierin beschriebenen Ausführungsformen ausführen. Ein maschinenlesbares Medium kann unter anderem Disketten, optische Platten, CD-ROMs (schreibgeschützte Compact-Disc-Arbeitsspeicher) und magnetooptische Platten, ROMs, RAMs, EPROMs (löschbare programmierbare schreibgeschützte Arbeitsspeicher), EEPROMs (elektrisch löschbare programmierbare schreibgeschützte Arbeitsspeicher), magnetische oder optische Karten, Flash-Speicher oder einen anderen Typ von Medien/eines maschinenlesbaren Mediums enthalten, die bzw. das zum Speichern von maschinenausführbaren Anweisungen geeignet sind bzw. ist.
Darüber hinaus können Ausführungsformen als ein Computerprogrammprodukt heruntergeladen werden, wobei das Programm von einem entfernten Computer (z. B. einem Server) an einen anfordernden Computer (z. B. einem Client) über ein oder mehrere Datensignale übertragen werden kann, die in einer Trägerwelle oder einem anderen Ausbreitungsmedium über eine Kommunikationsverknüpfung (z. B. ein Modem und/oder eine Netzwerkverbindung) ausgebildet sind oder durch diese moduliert sind.
16 veranschaulicht eine Ausführungsform einer GPU 1514. Wie in 16 gezeigt, enthält die GPU 1514 eine Ausführungseinheit 1610 mit einer Vielzahl von Knoten (z. B. Knoten0-Knoten7), die über eine Fabric-Architektur angekoppelt sind. In einer Ausführungsform enthält jeder Knoten eine Vielzahl von Verarbeitungselementen, die über Fabric-Elemente 1605 an einen Arbeitsspeicher 1650 gekoppelt sind. In einer derartigen Ausführungsform ist jedes Fabric-Element 1605 an zwei Knoten und zwei Bänke im Arbeitsspeicher 1650 gekoppelt. Dementsprechend koppelt das Fabric-Element 1605A die Knoten 0 und 1 an die Bänke 0 und 1, das Fabric-Element 1605b koppelt die Knoten 2 und 3 an die Bänke 2 und 3, das Fabric-Element 1605c koppelt die Knoten 4 und 5 an die Bänke 4 und 5 und das Fabric-Element 1605d koppelt die Knoten 6 und 7 an die Bänke 6 und 7.
Nach einer Ausführungsform enthält jedes Fabric-Element 1605 eine MMU 1620, einen Steuerzwischenspeicher 1630 und einen Arbiter 1640. Die MMUs 1620 führen eine Arbeitsspeicherverwaltung durch, um virtuelle Adressräume zwischen den Arbeitsspeicherbänken 0-7 zu verwalten. In einer Ausführungsform verwaltet jede MMU 1620 den Transfer von Daten zu und von zugehörigen Arbeitsspeicherbänken im Arbeitsspeicher 1650. Der Arbiter 1640 vermittelt zwischen jedem assoziierten Knoten für einen Zugriff auf den Arbeitsspeicher 1650. Beispielsweise vermittelt der Arbiter 1640A zwischen den Verarbeitungsknoten 0 und 1 für den Zugriff auf die Bänke 0 und 1.
Der Steuerzwischenspeicher (CC) 1630 führt eine Komprimierung/Dekomprimierung von Arbeitsspeicherdaten durch. Beispielsweise komprimiert der CC 1630 Daten (z. B. Hauptoberflächendaten), die von einem Verarbeitungsknoten empfangen wurden, um in den Arbeitsspeicher 1650 geschrieben zu werden, und dekomprimiert aus dem Arbeitsspeicher 1650 gelesene Daten vor einer Sendung an einen Verarbeitungsknoten. Nach einer Ausführungsform enthalten an jeder Adresse im Arbeitsspeicher 1650 gespeicherte Daten zugehörige Metadaten, die einen Komprimierungszustand (z. B. wie die Hauptoberflächendaten zu komprimieren/dekomprimieren sind) der Daten anzeigen. In einer derartigen Ausführungsform berechnet die MMU 1620 direkt die Metadaten-Arbeitsspeicherposition auf Grundlage der physischen Adresse der Hauptoberflächendaten.
In einer weiteren Ausführungsform wird ein Abschnitt des Arbeitsspeichers auf Grundlage der Größe des Arbeitsspeichers reserviert. In einem Komprimierungsschema, in dem 1 Byte von Metadaten 256 Byte von Hauptoberflächendaten repräsentiert, werden zum Beispiel 1/256-tel des Arbeitsspeichers für die Metadaten reserviert. Deshalb implementiert eine Ausführungsform mit 8 GB von lokalem Arbeitsspeicher eine 32-MB-Zuteilung von Metadatenraum im Arbeitsspeicher 1650. In noch einer weiteren Ausführungsform berechnet die MMU 1620 die Metadatenadresse auf Grundlage der physischen Adresse unter Berücksichtigung von Hash-Auswirkungen. Als Ergebnis wird der endgültige Inhalt an den CC 1630 weitergeleitet.
Es tritt ein Problem beim Hashing auf, das dazu führt, dass die Metadaten fragmentiert werden (z. B. über den gesamten Arbeitsspeicherraum verteilt werden). 17 veranschaulicht eine Ausführungsform eines Arbeitsspeicherraums mit einer Trennung von 1 kB pro Knoten. Wie in 17 gezeigt, ist jedes 1 kB von Daten (z. B. Hauptoberflächendaten) mit 4 B von Metadaten assoziiert. In einer Ausführungsform werden Daten über eine Granularität von 1 kB gehasht. Deshalt führt Hashing dazu, dass Daten im linearen Raum nicht zusammenhängend gespeichert werden. Beispielsweise ist jedes kB in den ersten 8 kB von Daten über die Bänke 0-7 aufgeteilt. Deshalb residieren die 1., die 9., die 16. usw. Hauptoberflächendatenadresse in der gleichen Bank (wie in der obersten Zeile von Kästchen in 17 gezeigt). Für die zugehörigen 4 B von Metadaten (in der untersten Zeile der Kästchen gezeigt) führt die Hash-Granularität von 1 kB jedoch dazu, dass die Metadaten über die 8 Bänke aufgeteilt sind. Dementsprechend können Metadaten oft in einem von ihren zugehörigen Daten verschiedenen Pfad zum Arbeitsspeicher (z. B. einer anderen Bank) enden.
Nach einer Ausführungsform passen die MMUs 1620 Metadaten-Adresspositionen an (oder packen diese neu), nachdem eine Hashfunktion an den Hauptdaten und den Metadaten durchgeführt wurde. In einer derartigen Ausführungsform führt die Anpassung zur Ausrichtung von Metadaten, sodass jede 4 B von Metadaten in der gleichen Bank wie ihre zugehörigen 1 kB von gespeicherten Daten gespeichert werden. In einer weiteren Ausführungsform werden die Adresspositionen der gehashten Metadaten so angepasst, dass jede 4 B von assoziierten Metadaten als ein 32-B-Metadatenblock von Adressen in der Bank kombiniert wird (wie in 18 gezeigt). Beispielsweise kann Bank 0 Hauptoberflächendaten an der 1., 9., 16. usw. Adresse und einen 32-B-Metadatenblock der assoziierten Metadaten speichern. Beispielsweise kann Bank 1 Hauptoberflächendaten an der 2., 10., 17. usw. Adresse und einen zweiten 32-B-Metadatenblock mit den assoziierten Metadaten speichern.
19 veranschaulicht eine Ausführungsform einer MMU 1620. Die MMU 1620 enthält eine Hash-Engine 1920, die eine Hashtabelle 1922 implementiert, um eine Hashfunktion durchzuführen, um auf physische Adresspositionen im Arbeitsspeicher 1650 zeigende Indizes zu berechnen. In einer Ausführungsform führt die Hash-Engine 1920 das Hashing in Übereinstimmung mit einer unbearbeiteten Knoten-Hashfunktion durch. In einer derartigen Ausführungsform berücksichtigt die Hashfunktion bestimmte Bits der Adresse und leitet auf Grundlage dieser Bits eine bestimmte Bank-Adresse ab. Die Hashfunktion verteilt die Arbeitsspeicherzugriffe über alle der physischen Arbeitsspeicherbänke, wodurch ein paralleler Zugriff auf die Arbeitsspeicherbänke ermöglicht wird. Das Parallelisieren der Arbeitsspeicherzugriffe über unabhängige Arbeitsspeicherbänke hinweg hilft dabei, Arbeitsspeicherleistung im Vergleich dazu zu gewinnen, wenn alle Zugriffe auf eine einzelne Arbeitsspeicherbank erfolgen und eine Serialisierung an dieser Arbeitsspeicherbank verursachen. Als ein Beispiel, mit einer Hashing-Granularität von 1 kB über die Arbeitsspeicherbänke hinweg, veranschaulicht Tabelle 1 eine Ausführungsform eines Hashs, die verwendet werden kann. Tabelle 1

a[15] a[14] a[13] a[12] a[11]

Unbearbeiteter_Knoten[0] x x X

Unbearbeiteter_Knoten[1] x x x

Unbearbeiteter_Knoten [2] x x
KnotenID kann dann als {Unbearbeiteter_Knoten[0], Unbearbeiteter_Knoten[2], Unbearbeiteter_Knoten[1]} genommen werden.
Für diese bestimmte Ausführungsform (z. B. Hashing mit Granularität von 1 kB und Verwenden der obigen Hashfunktion) werden die Basisbits für den Arbeitsspeicherzugriff {a[12:10]}.
Die Hash-Engine 1920 enthält auch Abbildungslogik 1922 und Verpackungslogik 1924, um ein Hashing zu ermöglichen, das dazu führt, dass alle Metadaten (z. B. 32 B) in die gleiche Bank wie die zugehörigen Hauptdaten platziert werden. Die Abbildungslogik 1922 führt eine lineare Abbildung (z. B. 256-1-Abbildung) durch, um die Hauptdaten auf die Metadaten abzubilden. Die Verpackungslogik 1924 führt Verschiebungsoperationen durch, um die Metadaten in einen Metadatenblock in einer Bank zu kombinieren. Um mit der Granularität von 1 kB beim Hashing über Arbeitsspeicherbänke hinweg als Beispiel fortzufahren, wird die Metadatenadresse [39:0] dann folgendermaßen gebildet (unter der Annahme von 40 Adressbits, um allgemein auf den Arbeitsspeicher zuzugreifen): {8'b0, Main_Surf_Adr[39:21], Base_Bits[2:0], Main_Surf_Adr[20:17], Main_Surf_Adr[13:9,7]}, wobei Base_Bits a[12:10] von der Hashfunktion sind. Der Byteoffset innerhalb der Metadaten-Zwischenspeicherleitung ist durch metadata_adr[5:0] = Main_Surf_Adr[13:9,7] gegeben.
20 ist ein Ablaufdiagramm, das eine Ausführungsform eines Prozesses zum Durchführen von Komprimierungshashing veranschaulicht. Bei Verarbeitungsblock 2010 wird eine Hauptdatenadresse empfangen. Bei Verarbeitungsblock 2020 wird eine lineare Abbildung durchgeführt, um die Hauptdatenadresse auf eine zugehörige Metadatenadresse abzubilden. Bei Verarbeitungsblock 2030 wird eine Funktion an den Hauptdatenadressen und den Metadatenadressen durchgeführt. Bei Verarbeitungsblock 2040 wird eine Verschiebungsoperation durchgeführt, um die Metadaten innerhalb einer Bank zu verpacken. In einer Ausführungsform hängt die Verschiebungsoperation vom Typ der Hashfunktion ab, die implementiert wird.
Die folgenden Paragrafen und/oder Beispiele betreffen weitere Ausführungsformen oder Beispiele. Spezifisches in den Beispielen kann überall in einer oder mehreren Ausführungsformen verwendet werden. Die verschiedenen Merkmale der verschiedenen Ausführungsformen oder Beispiele können auf verschiedene Weise kombiniert werden, wobei einige Merkmale enthalten sind und andere ausgeschlossen sind, um einer Vielzahl unterschiedlicher Anwendungen zu genügen. Beispiele können einen Gegenstand umfassen, wie ein Verfahren, Mittel zum Durchführen von Handlungen des Verfahrens, mindestens ein maschinenlesbares Medium mit Anweisungen, die, wenn sie von einer Maschine ausgeführt werden, die Maschine dazu veranlassen, Handlungen des Verfahrens oder einer Einrichtung oder eines Systems zum Ermöglichen einer Hybridkommunikation nach hierin beschriebenen Ausführungsformen und Beispielen durchzuführen.
Einige Ausführungsformen betreffen Beispiel 1, das eine Einrichtung enthält, um eine Arbeitsspeicherdatenkomprimierung zu ermöglichen, die einen Arbeitsspeicher mit einer Vielzahl von Bänken zum Speichern von Hauptdaten und mit den Hauptdaten assoziierte Metadaten und eine Arbeitsspeicherverwaltungseinheit (MMU) umfasst, die an die Vielzahl von Bänken gekoppelt ist, um eine Hashfunktion durchzuführen, um auf virtuelle Adresspositionen im Arbeitsspeicher zeigende Indizes für die Hauptdaten und Metadaten zu berechnen und die virtuellen Metadaten-Adresspositionen anzupassen, um jede angepasste virtuelle Metadaten-Adressposition in einer Bank zu speichern, die die assoziierten Hauptdaten speichert.
Beispiel 2 enthält den Gegenstand von Beispiel 1, wobei das Anpassen der Adresspositionen der Metadaten durch die MMU ein Kombinieren der Metadaten umfasst, die in den Bänken zu speichern sind, um Metadatenblöcke zu erzeugen.
Beispiel 3 enthält den Gegenstand der Beispiele 1 und 2, wobei das Anpassen der Adresspositionen der Metadaten durch die MMU ferner ein Durchführen einer oder mehrerer Verschiebungsoperationen umfasst.
Beispiel 4 enthält den Gegenstand der Beispiele 1-3, wobei die MMU eine Vielzahl von MMUs umfasst, die jeweils an eine oder mehrere der Vielzahl von Bänken gekoppelt sind.
Beispiel 5 enthält den Gegenstand der Beispiele 1-4, wobei jede der Vielzahl von MMUs eine Hashtabelle umfasst, die implementiert ist, um die Hashfunktion durchzuführen.
Beispiel 6 enthält den Gegenstand der Beispiele 1-5, wobei jede der Vielzahl von MMUs ferner eine lineare Abbildung durchführt, um eine Hauptdatenadresse auf eine Metadatenadresse abzubilden.
Beispiel 7 enthält den Gegenstand der Beispiele 1-6, der ferner eine erste MMU, die an eine erste Bank gekoppelt ist, um einen ersten Satz von Hauptdaten und einen ersten Metadatenblock von mit dem ersten Satz von Hauptdaten assoziierten Metadaten zu speichern, und eine zweite MMU umfasst, die an eine zweite Bank gekoppelt ist, um einen zweiten Satz von Hauptdaten und einen zweiten Metadatenblock von mit dem zweiten Satz von Hauptdaten assoziierten Metadaten zu speichern.
Einige Ausführungsformen betreffen Beispiel 8, das ein Verfahren enthält, um eine Arbeitsspeicherdatenkomprimierung zu ermöglichen, das ein Durchführen einer Hashfunktion, um auf virtuelle Adresspositionen im Arbeitsspeicher zeigende Indizes für Hauptdaten und mit den Hauptdaten assoziierte Metadaten zu berechnen, ein Anpassen der virtuellen Metadaten-Adresspositionen und ein Speichern der Metadaten an den angepassten virtuellen Adresspositionen umfasst, wobei sich jede angepasste virtuelle Metadaten-Adressposition in einer Bank befindet, die die assoziierten Hauptdaten speichert.
Beispiel 9 enthält den Gegenstand von Beispiel 8, der ferner ein Empfangen einer Hauptdatenadresse und ein Abbilden der Hauptdatenadresse auf eine Metadatenadresse umfasst.
Beispiel 10 enthält den Gegenstand der Beispiele 8 und 9, wobei das Anpassen der Adresspositionen der Metadaten ferner ein Durchführen einer oder mehrerer Verschiebungsoperationen umfasst.
Beispiel 11 enthält den Gegenstand der Beispiele 8-10, der ferner ein Kombinieren der Metadaten umfasst, die in den Bänken zu speichern sind, um Metadatenblöcke zu erzeugen.
Beispiel 12 enthält den Gegenstand der Beispiele 8-11, der ferner ein Speichern eines ersten Satzes von Hauptdaten und eines ersten Metadatenblocks von mit dem ersten Satz von Hauptdaten assoziierten Metadaten an einer ersten Bank und Speichern eines zweiten Satzes von Hauptdaten und eines zweiten Metadatenblocks von mit dem zweiten Satz von Hauptdaten assoziierten Metadaten an einer zweiten Bank umfasst.
Einige Ausführungsformen betreffen Beispiel 13, das eine Grafikverarbeitungseinheit (GPU) enthält, die einen Arbeitsspeicher mit einer Vielzahl von Bänken zum Speichern von Hauptdaten und mit den Hauptdaten assoziierte Metadaten und eine Vielzahl von Fabric-Elementen umfasst, die an die Vielzahl von Bänken gekoppelt ist, wobei jedes Fabric-Element eine Arbeitsspeicherverwaltungseinheit (MMU) enthält, die an eine oder mehrere der Vielzahl von Bänken gekoppelt ist, um eine Hashfunktion durchzuführen, um auf virtuelle Adresspositionen im Arbeitsspeicher zeigende Indizes für die Hauptdaten und Metadaten zu berechnen und die virtuellen Metadaten-Adresspositionen anzupassen, um jede angepasste virtuelle Metadaten-Adressposition in einer Bank zu speichern, die die assoziierten Hauptdaten speichert.
Beispiel 14 enthält den Gegenstand von Beispiel 13, wobei das Anpassen der Adresspositionen der Metadaten durch die MMU ein Kombinieren der Metadaten umfasst, die in den Bänken zu speichern sind, um Metadatenblöcke zu erzeugen.
Beispiel 15 enthält den Gegenstand der Beispiele 13 und 14, wobei das Anpassen der Adresspositionen der Metadaten durch die MMU ferner ein Durchführen einer oder mehrerer Verschiebungsoperationen umfasst.
Beispiel 16 enthält den Gegenstand der Beispiele 13-15, wobei die MMU eine Hashtabelle umfasst, die implementiert ist, um die Hashfunktion durchzuführen.
Beispiel 17 enthält den Gegenstand der Beispiele 13-16, wobei die MMU ferner eine lineare Abbildung durchführt, um eine Hauptdatenadresse auf eine Metadatenadresse abzubilden.
Beispiel 18 enthält den Gegenstand der Beispiele 13-17, der ferner ein erstes Fabric-Element mit einer ersten MMU, die an eine erste Bank gekoppelt ist, um einen ersten Satz von Hauptdaten und einen ersten Metadatenblock von mit dem ersten Satz von Hauptdaten assoziierten Metadaten zu speichern, und ein zweites Fabric-Element mit einer zweiten MMU umfasst, die an eine zweite Bank gekoppelt ist, um einen zweiten Satz von Hauptdaten und einen zweiten Metadatenblock von mit dem zweiten Satz von Hauptdaten assoziierten Metadaten zu speichern.
Beispiel 19 enthält den Gegenstand der Beispiele 13-18, der ferner einen ersten Satz von einem oder mehreren an das erste Fabric-Element gekoppelten Verarbeitungsknoten und einen zweiten Satz von einem oder mehreren an das zweite Fabric-Element gekoppelten Knoten umfasst.
Beispiel 20 enthält den Gegenstand der Beispiele 13-19, wobei das erste Fabric-Element einen ersten Steuerzwischenspeicher umfasst, der zwischen dem ersten Satz von einem oder mehreren Verarbeitungsknoten und der ersten MMU gekoppelt ist, um eine Datenkomprimierung und -dekomprimierung durchzuführen, und das zweite Fabric-Element einen zweiten Steuerzwischenspeicher umfasst, der zwischen dem zweiten Satz von einem oder mehreren Verarbeitungsknoten und der zweiten MMU gekoppelt ist, um eine Datenkomprimierung und -dekomprimierung durchzuführen.
Die Erfindung wurde oben unter Bezugnahme auf bestimmte Ausführungsformen beschrieben. Fachleute verstehen jedoch, dass verschiedene Modifikationen und Änderungen daran vorgenommen werden können, ohne vom allgemeinen Gedanken und Umfang der Erfindung abzuweichen, wie in den beigefügten Ansprüchen dargelegt. Die vorstehende Beschreibung und die vorstehenden Zeichnungen sollen dementsprechend in einem illustrierenden Sinn statt in einem einschränkenden Sinn betrachtet werden.

Claims

Einrichtung zum Ermöglichen einer Arbeitsspeicherdatenkomprimierung, umfassend: einen Arbeitsspeicher mit einer Vielzahl von Bänken, um Hauptdaten und mit den Hauptdaten assoziierte Metadaten zu speichern; und eine Arbeitsspeicherverwaltungseinheit (MMU), die an die Vielzahl von Bänken gekoppelt ist, um eine Hashfunktion durchzuführen, um auf virtuelle Adresspositionen im Arbeitsspeicher zeigende Indizes für die Hauptdaten und die Metadaten zu berechnen, und die virtuellen Metadaten-Adresspositionen anzupassen, um jede angepasste virtuelle Metadaten-Adressposition in einer Bank zu speichern, die die zugehörigen Hauptdaten speichert.
Einrichtung nach Anspruch 1, wobei das Anpassen der Adresspositionen der Metadaten durch die MMU ein Kombinieren der Metadaten umfasst, die in den Bänken zu speichern sind, um Metadatenblöcke zu erzeugen.
Einrichtung nach Anspruch 2, wobei das Anpassen der Adresspositionen der Metadaten durch die MMU ferner ein Durchführen einer oder mehrerer Verschiebungsoperationen umfasst.
Einrichtung nach Anspruch 2 oder 3, wobei die MMU eine Vielzahl von MMUs umfasst, die jeweils an eine oder mehrere der Vielzahl von Bänken gekoppelt sind.
Einrichtung nach Anspruch 4, wobei jede der Vielzahl von MMUs eine Hashtabelle umfasst, die implementiert ist, um die Hashfunktion durchzuführen.
Einrichtung nach Anspruch 4 oder 5, wobei jede der Vielzahl von MMUs ferner eine lineare Abbildung durchführt, um eine Hauptdatenadresse auf eine Metadatenadresse abzubilden.
Einrichtung nach einem der Ansprüche 4 bis 6, ferner umfassend: eine an eine erste Bank gekoppelte erste MMU, um einen ersten Satz von Hauptdaten und einen ersten Metadatenblock von mit dem ersten Satz von Hauptdaten assoziierten Metadaten zu speichern; und eine an eine zweite Bank gekoppelte zweite MMU, um einen zweiten Satz von Hauptdaten und einen zweiten Metadatenblock von mit dem zweiten Satz von Hauptdaten assoziierten Metadaten zu speichern.
Verfahren zum Ermöglichen einer Arbeitsspeicherdatenkomprimierung, umfassend: Durchführen einer Hashfunktion, um auf virtuelle Adresspositionen im Arbeitsspeicher zeigende Indizes für Hauptdaten und mit den Hauptdaten assoziierte Metadaten zu berechnen; Anpassen der virtuellen Metadaten-Adresspositionen; und Speichern der Metadaten an den angepassten virtuellen Metadatenpositionen, wobei sich jede angepasste virtuelle Metadaten-Adressposition in einer Bank befindet, die die assoziierten Hauptdaten speichert.
Verfahren nach Anspruch 8, ferner umfassend: Empfangen einer Hauptdatenadresse; und Abbilden der Hauptdatenadresse auf eine Metadatenadresse.
Verfahren nach Anspruch 8 oder 9, wobei das Anpassen der Adresspositionen der Metadaten ferner ein Durchführen einer oder mehrerer Verschiebungsoperationen umfasst.
Verfahren nach Anspruch 10, das ferner ein Kombinieren der Metadaten umfasst, die in den Bänken zu speichern sind, um Metadatenblöcke zu erzeugen.
Verfahren nach einem der Ansprüche 8 bis 11, ferner umfassend: Speichern eines ersten Satzes von Hauptdaten und eines ersten Metadatenblocks von mit dem ersten Satz von Hauptdaten assoziierten Metadaten an einer ersten Bank; und Speichern eines zweiten Satzes von Hauptdaten und eines zweiten Metadatenblocks von mit dem zweiten Satz von Hauptdaten assoziierten Metadaten an einer zweiten Bank.
Grafikverarbeitungseinheit (GPU), umfassend: einen Arbeitsspeicher mit einer Vielzahl von Bänken, um Hauptdaten und mit den Hauptdaten assoziierte Metadaten zu speichern; und eine Vielzahl von Fabric-Elementen, die an die Vielzahl von Bänken gekoppelt ist, wobei jedes Fabric-Element eine Arbeitsspeicherverwaltungseinheit (MMU) enthält, die an eine oder mehrere der Vielzahl von Bänken gekoppelt ist, um eine Hashfunktion durchzuführen, um auf virtuelle Adresspositionen im Arbeitsspeicher zeigende Indizes für die Hauptdaten und die Metadaten zu berechnen, und die virtuellen Metadaten-Adresspositionen anzupassen, um jede angepasste virtuelle Metadaten-Adressposition in einer Bank zu speichern, die die zugehörigen Hauptdaten speichert.
GPU nach Anspruch 13, wobei das Anpassen der Adresspositionen der Metadaten durch die MMU ein Kombinieren der Metadaten umfasst, die in den Bänken zu speichern sind, um Metadatenblöcke zu erzeugen.
GPU nach Anspruch 13 oder 14, wobei das Anpassen der Adresspositionen der Metadaten durch die MMU ferner ein Durchführen einer oder mehrerer Verschiebungsoperationen umfasst.
GPU nach einem der Ansprüche 13 bis 15, wobei die MMU eine Hashtabelle umfasst, die implementiert ist, um die Hashfunktion durchzuführen.
GPU nach einem der Ansprüche 13 bis 16, wobei die MMU ferner eine lineare Abbildung durchführt, um eine Hauptdatenadresse auf eine Metadatenadresse abzubilden.
GPU nach einem der Ansprüche 13 bis 17, ferner umfassend: ein erstes Fabric-Element mit einer an eine erste Bank gekoppelten ersten MMU, um einen ersten Satz von Hauptdaten und einen ersten Metadatenblock von mit dem ersten Satz von Hauptdaten assoziierten Metadaten zu speichern; und ein zweites Fabric-Element mit einer an eine zweite Bank gekoppelten zweiten MMU, um einen zweiten Satz von Hauptdaten und einen zweiten Metadatenblock von mit dem zweiten Satz von Hauptdaten assoziierten Metadaten zu speichern.
GPU nach Anspruch 18, ferner umfassend: einen ersten Satz eines oder mehrerer an das erste Fabric-Element gekoppelter Verarbeitungsknoten; und einen zweiten Satz eines oder mehrerer an das zweite Fabric-Element gekoppelter Verarbeitungsknoten.
GPU nach Anspruch 18 oder 19, wobei das erste Fabric-Element einen ersten Steuerzwischenspeicher umfasst, der zwischen dem ersten Satz von einem oder mehreren Verarbeitungsknoten und der ersten MMU gekoppelt ist, um eine Datenkomprimierung und -dekomprimierung durchzuführen, und das zweite Fabric-Element einen zweiten Steuerzwischenspeicher umfasst, der zwischen dem zweiten Satz von einem oder mehreren Verarbeitungsknoten und der zweiten MMU gekoppelt ist, um eine Datenkomprimierung und -dekomprimierung durchzuführen.