DE102020131704A1

DE102020131704A1 - Multikachelspeicherverwaltungsmechanismus

Info

Publication number: DE102020131704A1
Application number: DE102020131704.2A
Authority: DE
Inventors: Zack S. Waters; Travis Schluessler; Michael Apodaca; Ankur Shah
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2020-02-26
Filing date: 2020-11-30
Publication date: 2021-08-26
Also published as: US20230244609A1; CN113313624A; US20210263853A1; US11960405B2; US11580027B2

Abstract

Grafikprozessoren zur Implementierung von Multikachelverwaltung sind offenbart. In einer Ausführungsform weist ein Grafikprozessor eine erste Grafikvorrichtung, die einen lokalen Speicher aufweist, eine zweite Grafikvorrichtung, die einen lokalen Speicher aufweist, und einen Grafiktreiber auf, um eine einzelne virtuelle Zuweisung mit einem gemeinsamen virtuellen Adressbereich bereitzustellen, um eine Ressource zu jedem lokalen Speicher der ersten und zweiten Grafikvorrichtung zu spiegeln.

Description

GEBIET
Ausführungsformen beziehen sich auf Datenverarbeitung und genauer darauf, einen Multikachelspeicherverwaltungsmechanismus in einer Grafikumgebung bereitzustellen.
STAND DER TECHNIK DER BESCHREIBUNG
Aktuelle parallele Grafikdatenverarbeitung weist Systeme und Verfahren auf, die entwickelt sind, bestimmte Betriebe an Grafikdaten durchzuführen, wie zum Beispiel lineare Interpolation, Tessellation, Rasterisierung, Texturabbildung, Tiefentestung usw. Herkömmliche Grafikprozessoren verwendeten fixierte Funktionsrecheneinheiten, um Grafikdaten zu verarbeiten; jedoch wurden kürzlich Abschnitte von Grafikprozessoren programmierbar gemacht, was solchen Prozessoren ermöglicht, eine breitere Vielfalt von Betrieben zur Verarbeitung von Scheitelpunkt- und Fragmentdaten zu unterstützen.
Um Arbeitsleistung weiter zu erhöhen, implementieren Grafikprozessoren für gewöhnlich Verarbeitungstechniken, wie Pipelining, die versuchen, so viele Grafikdaten wie möglich über die verschiedenen Teile der Grafikpipeline hinweg parallel zu verarbeiten. Parallele Grafikprozessoren mit Einzel-Anweisung-Mehrfach-Thread- (SIMT, Single Instruction Multiple Thread) Architekturen sind designt, die Menge paralleler Verarbeitung in der Grafikpipeline zu maximieren. In einer SIMT-Architektur versuchen Gruppen paralleler Threads, Programmanweisungen synchron gemeinsam so oft wie möglich auszuführen, um Verarbeitungseffizienz zu erhöhen. Eine allgemeine Übersicht von Software und Hardware für SIMT-Architekturen ist in Shane Cook, CUDA Programming Kapitel 3, Seiten 37-51 (2013) zu finden.
Figurenliste
Damit die Weise, auf die die zuvor genannten Merkmale der vorliegenden Ausführungsformen im Detail verstanden werden können, kann eine ausführlichere Beschreibung der Ausführungsformen, die zuvor knapp zusammengefasst wurden, in Bezug auf Ausführungsformen erhalten werden, von denen manche in den angehängten Zeichnungen veranschaulicht sind. Es wird angemerkt, dass die angehängten Zeichnungen jedoch nur typische Ausführungsformen veranschaulichen und deshalb nicht auszulegen sind, den Umfang zu begrenzen.

1 veranschaulicht ein Blockdiagramm eines Verarbeitungssystems 100 gemäß einer Ausführungsform.
2A-2D veranschaulichen Rechensysteme und Grafikprozessoren gemäß Ausführungsformen;
3A-3C sind Blockdiagramme zusätzlicher Grafikprozessoren und Rechenbeschleunigerarchitekturen gemäß Ausführungsformen;
4 ist ein Blockdiagramm einer Grafikverarbeitungs-Engine 410 eines Grafikprozessors in Übereinstimmung mit manchen Ausführungsformen;
5A-5B veranschaulichen Thread-Ausführungslogik 500, die ein Array von Verarbeitungselementen aufweist, die in einem Grafikprozessorkern eingesetzt sind, gemäß Ausführungsformen;
6 veranschaulicht eine zusätzliche Ausführungseinheit 600 gemäß einer Ausführungsform;
7 ist ein Blockdiagramm, das Grafikprozessoranweisungsformate 700 gemäß manchen Ausführungsformen veranschaulicht;
8 ist ein Blockdiagramm einer anderen Ausführungsform eines Grafikprozessors 800 gemäß einer Ausführungsform;
9A ist ein Blockdiagramm, das ein Grafikprozessorbefehlsformat 900 gemäß manchen Ausführungsformen veranschaulicht;
9B ist ein Blockdiagramm, das eine Grafikprozessorbefehlssequenz 910 gemäß einer Ausführungsform veranschaulicht.
10 veranschaulicht eine beispielhafte Grafiksoftwarearchitektur für ein Datenverarbeitungssystem 1000 gemäß manchen Ausführungsformen.
11A ist ein Blockdiagramm, das ein IP-Kern-Entwicklungssystem 1100, das verwendet werden kann, um eine integrierte Schaltung herzustellen, um Betriebe durchzuführen, gemäß einer Ausführungsform veranschaulicht;
11B veranschaulicht eine Querschnittseitenansicht einer integrierten Schaltung-Package-Anordnung 1170 gemäß manchen Ausführungsformen;
11C veranschaulicht eine Package-Anordnung 1190, die mehrere Einheiten von Hardware-Logikchiplets aufweist, die mit einem Substrat 1180 (z.B. Basis-Die) verbunden sind.
11D veranschaulicht eine Package-Anordnung 1194, die austauschbare Chiplets 1195 aufweist, gemäß einer Ausführungsform.
12 veranschaulicht eine beispielhafte integrierte Schaltung und 13A-13B veranschaulichen verknüpfte Grafikprozessoren, die unter Verwendung eines oder mehrerer IP-Kerne gefertigt sein können, gemäß unterschiedlicher hierin beschriebener Ausführungsformen.
14A und 14B veranschaulichen einen Ansatz für einen Anwendermodustreiber (UMD, User Mode Driver) (Z.B. UMD 1026), um ausdrücklich eine Ressource zu spiegeln, indem separat gespiegelte Zuweisungen von virtuellen Adressen erzeugt und entsprechende Kopierbefehle eingesetzt werden, um sicherzustellen, dass die Daten ordentlich repliziert werden.
15A und 15B veranschaulichen UMD-verwaltete gespiegelte Zuweisungen in Übereinstimmung mit einer Ausführungsform.
16A und 16B veranschaulichten KMD-Speicherverwalterunterstützung zum Spielen physischer Seiten von einem gemeinsamen virtuellen Adressbereich in Übereinstimmung mit einer Ausführungsform.
17A und 17B veranschaulichen verschachtelte physische Seiten für eine virtuelle Zuweisung über alle teilnehmenden Kacheln in Übereinstimmung mit einer Ausführungsform.
18A und 18B veranschaulichen farbige Zuweisung (verschiedene Schattierung), die mit einer Knotenmaske begrenzt ist, in Übereinstimmung mit einer Ausführungsform.
19A veranschaulicht Platzierung von Ressourcen in einen Heap 1992 in Übereinstimmung mit einer Ausführungsform.
19B veranschaulicht Abbildung eines Heaps, um Ressourcen in farbige (schattierte) Zuweisungen von Kacheln eines Grafikprozessors zu platzieren, in Übereinstimmung mit einer Ausführungsform.
20A und 20B veranschaulichen Partitionierung eines Renderziels für 4 Kacheln in Übereinstimmung mit einer Ausführungsform.
21A-21C veranschaulichen zusätzliche Grafikmultiprozessoren gemäß Ausführungsformen.

AUSFÜHRLICHE BESCHREIBUNG
In manchen Ausführungsformen ist eine Grafikverarbeitungseinheit (GPU, Graphics Processing Unit) kommunikativ mit Host-/Prozessorkernen gekoppelt, um Grafikbetriebe, Maschinenlernbetriebe, Strukturanalysebetriebe und unterschiedliche Allzweck-GPU- (GPGPU, General-Purpose GPU) Funktionen zu beschleunigen. Die GPU kann kommunikativ mit dem Host-Prozessor/den -Kernen über einen Bus oder eine andere Zwischenverbindung (z.B. eine Hochgeschwindigkeitszwischenverbindung, wie PCIe oder NVLink) gekoppelt sein. In anderen Ausführungsformen kann die GPU auf demselben Package oder Chip wie die Kerne integriert und kommunikativ mit den Kernen über einen internen Prozessorbus/eine Zwischenverbindung (z.B. intern von dem Package oder Chip) gekoppelt sein. Ungeachtet der Weise, auf die die GPU verbunden ist, können die Prozessorkerne Arbeit zu der GPU in der Form von Abfolgen von Befehlen/Anweisungen zuweisen, die in einem Arbeitsbeschreiber enthalten sind. Die GPU verwendet dann dedizierte Schaltkreise/Logik zur effizienten Verarbeitung dieser Befehle/Anweisungen.
In der folgenden Beschreibung werden zahlreiche bestimmte Details vorgebracht, um ein tiefgreifenderes Verständnis bereitzustellen. Jedoch wird einem Fachkundigen ersichtlich, dass die hierin beschriebenen Ausführungsformen ohne eines oder mehrere dieser bestimmten Details ausgeübt werden können. In anderen Instanzen wurden wohlbekannte Merkmale nicht beschrieben, um eine Verschleierung der Details der vorliegenden Ausführungsformen zu vermeiden.
Systemübersicht
1 ist ein Blockdiagramm eines Verarbeitungssystems 100 gemäß einer Ausführungsform. System 100 kann in einem Einzelprozessor-Desktopsystem, einem Multiprozessor-Workstationsystem oder einem Serversystem, das eine große Zahl von Prozessoren 102 oder Prozessorkernen 107 aufweist, verwendet werden. In einer Ausführungsform ist das System 100 eine Verarbeitungsplattform, die innerhalb einer System-auf-einem-Chip (SoC, System-on-a-Chip) integrierten Schaltung eingegliedert ist, zur Verwendung in mobilen, handgehaltenen oder eingebetteten Vorrichtungen, wie innerhalb von Internet-der-Dinge- (IoT, Internetof-Things) Vorrichtungen mit kabelgebundener oder kabelloser Konnektivität mit einem lokalen oder Weitverkehrsnetzwerk.
In einer Ausführungsform kann System 100 aufweisen, gekoppelt sein mit oder integriert sein in: eine serverbasierte Spieleplattform; eine Spielekonsole, aufweisend eine Spiele- und Medienkonsole; eine mobile Spielekonsole, eine handgehaltene Spielekonsole oder eine Online-Spielekonsole. In manchen Ausführungsformen ist das System 100 Teil eines Mobiltelefons, Smartphones, einer Tabletrechenvorrichtung oder mobilen internetverbundenen Vorrichtung, wie ein Laptop mit niedriger interner Datenspeicherkapazität. Verarbeitungssystem 100 kann auch aufweisen, sich koppeln mit oder integriert sein in: eine tragbare Vorrichtung, wie eine tragbare Smartwatch-Vorrichtung; smarte Brillen oder Bekleidung, die mit Merkmalen erweiterter Realität (AR, Augmented Reality) oder virtueller Realität (VR, Virtual Reality) erweitert sind, um visuelle, hörbare oder taktile Ausgänge bereitzustellen, um visuelle, hörbare oder taktile Erfahrungen der echten Welt zu unterstützen oder anderswie Text, Audio, Grafik, Video, holografische Bilder oder Video oder taktile Rückmeldung bereitzustellen; andere erweiterte Realität- (AR) Vorrichtung; oder andere virtuelle Realität- (VR) Vorrichtung. In manchen Ausführungsformen weist das Verarbeitungssystem 100 einen Fernseher oder eine Set-Top-Box-Vorrichtung auf oder ist Teil davon. In einer Ausführungsform kann System 100 aufweisen, sich koppeln mit oder integriert sein in ein(em) selbstfahrenden Fahrzeug, wie ein Bus, Traktoranhänger, Auto, Motor- oder Elektrorad, Flugzeug oder Gleiter (oder eine beliebige Kombination davon). Das selbstfahrende Fahrzeug kann System 100 verwenden, um die um das Fahrzeug wahrgenommene Umgebung zu verarbeiten.
In manchen Ausführungsformen weisen der eine oder die mehreren Prozessoren 102 jeweils einen oder mehrere Prozessorkerne 107 auf, um Anweisungen zu verarbeiten, die, wenn ausgeführt, Betriebe für System oder Anwendersoftware durchführen. In manchen Ausführungsformen ist mindestens einer des einen oder der mehreren Prozessorkerne 107 konfiguriert, einen bestimmten Anweisungssatz 109 zu verarbeiten. In manchen Ausführungsformen kann Anweisungssatz 109 komplexe Anweisungssatzberechnung (CISC, Complex Instruction Set Computing), reduzierte Anweisungssatzberechnung (RISC, Reduced Instruction Set Computing) oder Berechnung über ein sehr langes Anweisungswort (VLIW, Very Long Instruction Word) erleichtern. Ein oder mehrere Prozessorkerne 107 können einen verschiedenen Anweisungssatz 109 verarbeiten, der Anweisungen aufweisen kann, um die Emulation anderer Anweisungssätze zu erleichtern. Prozessorkern 107 kann auch andere Verarbeitungsvorrichtungen aufweisen, die einen Digitalsignalprozessor (DSP, Digital Signal Processor).
In manchen Ausführungsformen weist der Prozessor 102 Cachespeicher 104 auf. Abhängig von der Architektur kann der Prozessor 102 einen einzelnen internen Cache oder mehrere Level von internem Cache aufweisen. In manchen Ausführungsformen wird der Cachespeicher unter unterschiedlichen Komponenten des Prozessors 102 geteilt. In manchen Ausführungsformen verwendet der Prozessor 102 auch einen externen Cache (z.B. einen Level-3 (L3) Cache oder Letztes-Level-Cache (LLC, Last-Level-Cache)) (nicht gezeigt), der unter Prozessorkernen 107 unter Verwendung bekannter Cachekohärenztechniken geteilt werden kann. Eine Registerdatei 106 kann zusätzlich in Prozessor 102 aufgewiesen sein und kann verschiedene Typen von Registern zum Speichern verschiedener Typen von Daten aufweisen (z.B. Ganzzahlregister, Gleitkommaregister, Statusregister und ein Anweisungszeigerregister). Manche Register können Allzweckregister sein, während andere Register für das Design des Prozessors 102 bestimmt sein können.
In manchen Ausführungsformen sind ein oder mehrere Prozessor(en) 102 mit einem oder mehreren Schnittstellenbus(sen) 110 gekoppelt, um Kommunikationssignale zu übertragen, wie Adress-, Daten- oder Steuersignale zwischen Prozessor 102 und anderen Komponenten in dem System 100. Der Schnittstellenbus 110 kann in einer Ausführungsform ein Prozessorbus sein, wie eine Version des Direct Media Interface (DMI) Busses. Jedoch sind Prozessorbusse nicht auf den DMI-Bus begrenzt und können einen oder mehrere Peripheral Component Interconnect-Busse (z.B. PCI, PCI Express), Speicherbusse oder andere Typen von Schnittstellenbussen aufweisen. In einer Ausführungsform weisen der/die Prozessor(en) 102 eine integrierte Speichersteuerung 116 und einen Plattformsteuerungshub 130 auf. Die Speichersteuerung 116 erleichtert Kommunikation zwischen einer Speichervorrichtung und anderen Komponenten des Systems 100, während der Plattformsteuerungshub (PCH, Platform Controller Hub) 130 Verbindungen mit I/O-Vorrichtungen über einen lokalen I/O-Bus bereitstellt.
Die Speichervorrichtung 120 kann eine dynamische Direktzugriffspeicher-(DRAM, Dynamic Random-Access Memory) Vorrichtung, eine statische Direktzugriffspeicher- (SRAM, Static Random Access Memory) Vorrichtung, Flashspeichervorrichtung, Phasenänderungsspeichervorrichtung oder eine andere Speichervorrichtung, die geeignete Arbeitsleistung aufweist, um als Prozessspeicher zu dienen, sein. In einer Ausführungsform kann die Speichervorrichtung 120 als Systemspeicher für das System 100 arbeiten, um Daten 122 und Anweisungen 121 zur Verwendung zu speichern, wenn der eine oder die mehreren Prozessoren 102 eine Anwendung oder einen Prozess ausführen. Speichersteuerung 116 koppelt sich auch mit einem optionalen externen Grafikprozessor 118, der mit dem einen oder den mehreren Grafikprozessoren 108 in Prozessoren 102 kommunizieren kann, um Grafik- und Medienbetriebe durchzuführen. In manchen Ausführungsformen können Grafik-, Medien- und oder Rechenbetriebe von einem Beschleuniger 112 unterstützt werden, der ein Coprozessor ist, der konfiguriert sein kann, einen bestimmten Satz von Grafik- Medien- oder Rechenbetrieben durchzuführen. Zum Beispiel ist in einer Ausführungsform der Beschleuniger 112 ein Matrixmultiplikationsbeschleuniger, der verwendet wird, um Maschinenlern- oder Rechenbetriebe zu optimieren. In einer Ausführungsform ist der Beschleuniger 112 ein Raytracing-Beschleuniger, der verwendet werden kann, um Raytracing-Betriebe in Einklang mit dem Grafikprozessor 108 durchzuführen. In einer Ausführungsform kann ein externer Beschleuniger 119 anstelle von oder in Einklang mit dem Beschleuniger 112 verwendet werden.
In manchen Ausführungsformen kann sich eine Anzeigevorrichtung 111 mit dem/den Prozessor(en) 102 verbinden. Die Anzeigevorrichtung 111 kann eine oder mehrere einer internen Anzeigevorrichtung, wie in einer mobilen Elektronikvorrichtung oder einer Laptopvorrichtung, oder einer externen Anzeigevorrichtung, die über eine Anzeigeschnittstelle (z.B. DisplayPort usw.) angehängt ist, sein. In einer Ausführungsform kann die Anzeigevorrichtung 111 eine am Kopf befestigte Anzeige (HMD, Head Mounted Display) sein, wie eine stereoskopische Anzeigevorrichtung zur Verwendung in virtuellen Realität- (VR) Anwendungen oder erweiterten Realität- (AR) Anwendungen.
In manchen Ausführungsformen ermöglicht der Plattformsteuerungshub 130 Peripherie, sich mit Speichervorrichtung 120 und Prozessor 102 über einen Hochgeschwindigkeits-I/O-Bus zu verbinden. Die I/O-Peripherie weist auf, ist aber nicht begrenzt auf, eine Audiosteuerung 146, eine Netzwerksteuerung 134, eine Firmware-Schnittstelle 128, einen drahtlosen Sendeempfänger 126, Berührungssensoren 125, eine Datenspeichervorrichtung 124 (z.B. nichtflüchtigen Speicher, flüchtigen Speicher, Festplatte, Flashspeicher, NAND, 3D NAND, 3D XPoint usw.). Die Datenspeichervorrichtung 124 kann sich über eine Datenspeicherschnittstelle (z.B. SATA) oder über einen Peripheriebus, wie einen Peripheral Component Interconnect-Bus (z.B. PCI, PCI Express), verbinden. Die Berührungssensoren 125 können Berührungssensoren, Drucksensoren oder Fingerabdrucksensoren aufweisen. Der drahtlose Sendeempfänger 126 kann ein Wi-Fi-Sendeempfänger, ein Bluetooth-Sendeempfänger oder ein Mobilnetzsendeempfänger 126, wie ein 3G, 4G, 5G oder Long Term Evolution-(LTE) Sendeempfänger sein. Die Firmware-Schnittstelle 128 ermöglicht Kommunikation mit Systemfirmware und kann zum Beispiel eine vereinheitlichte erweiterbare Firmware-Schnittstelle (UEFI, Unified Extensible Firmware Interface) sein. Die Netzwerksteuerung 134 kann eine Netzwerkverbindung mit einem kabelgebundenen Netzwerk ermöglichen. In manchen Ausführungsformen koppelt sich eine Hocharbeitsleistungsnetzwerksteuerung (nicht gezeigt) mit dem Schnittstellenbus 110. Die Audiosteuerung 146 ist in einer Ausführungsform eine Multikanalhochdefinitionsaudiosteuerung. In einer Ausführungsform weist das System 100 eine optionale ältere I/O-Steuerung 140 zur Kopplung älterer (z.B. Personal System 2 (PS/2)) Vorrichtungen mit dem System auf. Die Plattformsteuerungshub 130 kann sich auch mit einer oder mehreren Universal Serial Bus- (USB) Steuerungen 142 verbinden, die Eingangsvorrichtungen, wie Tastatur und Maus 143 Kombinationen, eine Kamera 144 oder andere USB-Eingangsvorrichtungen verbinden.
Es wird begrüßt, dass das gezeigte System 100 beispielhaft und nicht begrenzend ist, da andere Typen von Datenverarbeitungssystemen, die verschieden konfiguriert sind, auch verwendet werden können. Zum Beispiel können eine Instanz der Speichersteuerung 116 und des Plattformsteuerungshubs 130 in einen diskreten externen Grafikprozessor integriert sein, wie den externen Grafikprozessor 118. In einer Ausführungsform können der Plattformsteuerungshub 130 und/oder die Speichersteuerung 116 extern von dem einen oder den mehreren Prozessor(en) 102 sein. Zum Beispiel kann das System 100 eine externe Speichersteuerung 116 und einen Plattformsteuerungshub 130, der als ein Speichersteuerungshub und Peripheriesteuerungshub innerhalb eines Systemchipsatzes konfiguriert sein kann, der in Kommunikation mit dem/den Prozessor(en) 102 ist, aufweisen.
Zum Beispiel können Schaltungsplatten („Sleds“) verwendet werden, auf denen Komponenten, wie CPUs, Speicher und andere Komponenten platziert sind, die für erhöhte Wärmearbeitsleistung designt sind. In manchen Beispielen liegen Verarbeitungskomponenten, wie die Prozessoren, an einer Oberseite eines Sleds, während naher Speicher, wie DIMMs, an einer Bodenseite des Sleds liegen. Als ein Resultat des verbesserten Luftstroms, der durch dieses Design bereitgestellt ist, können die Komponenten bei höheren Frequenzen und Leistungsleveln als in typischen Systemen arbeiten, wodurch die Arbeitsleistung erhöht wird. Darüber hinaus sind die Sleds konfiguriert, sich blind mit Leistungs- und Datenkommunikationskabeln in einem Rahmen zusammenzuschließen, wodurch deren Fähigkeit verbessert wird, schnell entfernt, aufgerüstet, neu installiert und/oder ersetzt zu werden. Ähnlich sind individuelle Komponenten, die auf den Sleds liegen, wie Prozessoren, Beschleuniger, Speicher und Datenspeicherlaufwerke, konfiguriert, aufgrund deren erhöhten Abstands voneinander leicht aufgerüstet werden zu können. In der veranschaulichten Ausführungsform weisen die Komponenten zusätzlich Hardwarebestätigungsmerkmale auf, um deren Authentizität zu belegen.
Ein Datenzentrum kann eine Einzelnetzwerkarchitektur („Fabric“) nutzen, die mehrere andere Netzwerkarchitekturen unterstützt, aufweisend Ethernet und Omni-Path. Die Sleds können mit Schaltern über optische Fasern gekoppelt sein, die höhere Bandbreite und niedrigere Latenz als herkömmliche verdrillte Kabel (z.B. Kategorie 5, Kategorie 5e, Kategorie 6 usw.) bereitstellen. Aufgrund der hohen Bandbreite, Niederlatenzzwischenverbindungen und Netzwerkarchitektur kann das Datenzentrum in Verwendung Ressourcen bündeln, wie Speicher, Beschleuniger (z.B. GPUs, Grafikbeschleuniger, FPGAs, ASICs, neurale Netzwerk- und/oder künstliche Intelligenzbeschleuniger usw.) und Datenspeicherlaufwerke, die physisch zerstreut sind, und sie Rechenressourcen (z.B. Prozessoren) nach Bedarf bereitstellen, was den Rechenressourcen ermöglicht, auf die gebündelten Ressourcen zuzugreifen, als ob sie lokal wären.
Ein Netzteil oder eine Stromquelle kann Spannung und/oder Strom an System 100 oder eine beliebige hierin beschriebene Komponente oder ein System bereitstellen. In einem Beispiel weist das Netzteil einen AC/DC- (Wechselstrom zu Gleichstrom (Alternating Current to Direct Current)) Adapter auf, der in eine Steckdose zu stecken ist. Dieser Wechselstrom kann eine Stromquelle aus erneuerbarer Energie sein (z.B. Solarstrom). In einem Beispiel weist eine Stromquelle eine Gleichstromquelle auf, wie einen externen AC/DC-Wandler. In einem Beispiel weist die Stromquelle oder das Netzteil drahtlose Ladehardware auf, um über Nähe zu einem Ladefeld zu laden. In einem Beispiel kann die Stromquelle eine interne Batterie, Wechselstromversorgung, bewegungsbasierte Stromversorgung, Solarstromversorgung oder Brennstoffzellenquelle aufweisen.
2A-2D veranschaulichen Rechensysteme und Grafikprozessoren, die durch hierin beschriebene Ausführungsformen bereitgestellt sind. Die Elemente von 2A-2D, die dieselben Bezugsnummern (oder Namen) wie die Elemente einer beliebigen anderen FIGUR hierin aufweisen, können auf eine ähnliche Weise wie hier an anderer Stelle beschrieben arbeiten oder funktionieren, sind aber nicht darauf begrenzt.
2A ist ein Blockdiagramm einer Ausführungsform eines Prozessors 200, der eine oder mehrere Prozessorkerne 202A-202N, eine integrierte Speichersteuerung 214 und einen integrierten Grafikprozessor 208 aufweist. Prozessor 200 kann zusätzliche Kerne bis zu und aufweisend zusätzlichen Kern 202N aufweisen, die durch die strichlierten Boxen dargestellt sind. Jeder der Prozessorkerne 202A-202N weist eine oder mehrere interne Cacheeinheiten 204A-204N auf. In manchen Ausführungsformen weist jeder Prozessorkern auch Zugriff auf eine oder mehrere geteilte zwischengespeicherte Einheiten 206 auf. Die internen Cacheeinheiten 204A-204N und geteilten Cacheeinheiten 206 stellen eine Cachespeicherhierarchie innerhalb des Prozessors 200 dar. Die Cachespeicherhierarchie kann mindestens ein Level von Anweisungs- und Datencache innerhalb jedes Prozessorkerns und ein oder mehrere Level geteilten Mittellevelcaches aufweisen, wie einen Level 2 (L2), Level 3 (L3), Level 4 (L4) oder andere Level von Cache, wo das höchste Level von Cache vor externem Speicher als der LLC klassifiziert ist. In manchen Ausführungsformen behält Cachekohärenzlogik Kohärenz zwischen den unterschiedlichen Cacheeinheiten 206 und 204A-204N bei.
In manchen Ausführungsformen kann Prozessor 200 auch einen Satz einer oder mehrerer Bussteuerungseinheiten 216 und einen Systemagentenkern 210 aufweisen. Die eine oder mehreren Bussteuerungseinheiten 216 verwalten einen Satz von Peripheriebussen, wie einen oder mehrere PCI oder PCI Express Busse. Systemagentenkern 210 stellt Verwaltungsfunktionalität für die unterschiedlichen Prozessorkomponenten bereit. In manchen Ausführungsformen weist Systemagentenkern 210 eine oder mehrere integrierte Speichersteuerungen 214 auf, um Zugriff auf unterschiedliche externe Speichervorrichtungen (nicht gezeigt) zu verwalten.
In manchen Ausführungsformen weisen ein oder mehrere der Prozessorkerne 202A-202N Unterstützung für gleichzeitiges Multithreading auf. In solch einer Ausführungsform weist der Systemagentenkern 210 Komponenten zum Koordinieren und Betreiben von Kernen 202A-202N während multigethreadeter Verarbeitung auf. Systemagentenkern 210 kann zusätzlich eine Leistungssteuereinheit (PCU, Power Control Unit) aufweisen, die Logik und Komponenten aufweisen kann, um den Stromzustand der Prozessorkerne 202A-202N und des Grafikprozessors 208 zu regulieren.
In manchen Ausführungsformen weist Prozessor 200 zusätzlich einen Grafikprozessor 208 auf, um Grafikverarbeitungsbetriebe auszuführen. In manchen Ausführungsformen koppelt der Grafikprozessor 208 mit dem Satz von geteilten Cacheeinheiten 206 und dem Systemagentenkern 210, der die eine oder mehreren integrierten Speichersteuerungen 214 aufweist. In manchen Ausführungsformen weist der Systemagentenkern 210 auch eine Anzeigesteuerung 211 auf, um Grafikprozessorausgabe zu einer oder mehreren gekoppelten Anzeigen zu treiben. In manchen Ausführungsformen kann Anzeigesteuerung 211 auch ein separates Modul sein, das über mindestens eine Zwischenverbindung mit dem Grafikprozessor gekoppelt ist, oder kann innerhalb des Grafikprozessors 208 integriert sein.
In manchen Ausführungsformen wird eine ringbasierte Zwischenverbindungseinheit 212 verwendet, um sich mit den internen Komponenten des Prozessors 200 zu koppeln. Jedoch kann eine alternative Zwischenverbindungseinheit verwendet werden, wie eine Punkt-zu-Punkt-Zwischenverbindung, eine geschaltete Zwischenverbindung oder andere Techniken, Techniken am Stand der Technik aufweisend. In manchen Ausführungsformen koppelt sich Grafikprozessor 208 mit der Ringzwischenverbindung 212 über einen I/O-Link 213.
Der beispielhafte I/O-Link 213 stellt mindestens eine von mehreren Arten von I/O-Zwischenverbindungen dar, eine I/O-Zwischenverbindung auf dem Package aufweisend, die Kommunikation zwischen unterschiedlichen Prozessorkomponenten erleichtert, und ein eingebettetes Hochleistungsspeichermodul 218, wie ein eDRAM-Modul. In manchen Ausführungsformen können alle der Prozessorkerne 202A-202N und Grafikprozessor 208 eingebettete Speichermodule 218 verwenden, wie einen geteilten Letztes-Level-Cache.
In manchen Ausführungsformen sind Prozessorkerne 202A-202N homogene Kerne, die dieselbe Anweisungssatzarchitektur ausführen. In einer anderen Ausführungsform sind Prozessorkerne 202A-202N im Sinne von Anweisungssatzarchitektur (ISA, Instruction Set Architecture) heterogen, wo ein oder mehrere Prozessorkerne 202A-202N einen ersten Anweisungssatz ausführen, während mindestens einer der anderen Kerne einen Teilsatz des ersten Anweisungssatzes oder einen verschiedenen Anweisungssatz ausführt. In einer Ausführungsform sind Prozessorkerne 202A-202N im Sinne von Mikroarchitektur heterogen, wo ein oder mehrere Kerne, die einen relativ höheren Leistungsverbrauch aufweisen, sich mit einem oder mehreren Leistungskernen koppeln, die einen niedrigeren Leistungsverbrauch aufweisen. In einer Ausführungsform sind Prozessorkerne 202A-202N im Sinne von Rechenkapazität heterogen. Zusätzlich kann Prozessor 200 auf einem oder mehreren Chips oder als eine SoC-integrierte Schaltung, die die veranschaulichten Komponenten aufweist, zusätzlich zu anderen Komponenten implementiert sein.
2B ist ein Blockdiagramm von Hardwarelogik eines Grafikprozessorkerns 219 gemäß manchen hierin beschriebenen Ausführungsformen. Elemente von 2B, die dieselben Referenznummern (oder Namen) wie die Elemente einer beliebigen anderen FIGUR hierin aufweisen, können auf eine beliebige Weise, ähnlich der sonst hierin beschriebenen arbeiten oder fungieren, sind aber nicht darauf begrenzt. Der Grafikprozessorkern 219, manchmal als ein Kernprozessorelement bezeichnet, kann ein oder können mehrere Grafikkerne innerhalb eines modularen Grafikprozessors sein. Der Grafikprozessorkern 219 ist beispielhaft für ein Grafikkernprozessorelement und ein Grafikprozessor, wie hierin beschrieben, kann mehrere Grafikkernprozessorelemente aufweisen, basierend auf Zielleistung und Arbeitsleistungshüllenkurven. Jeder Grafikprozessorkern 219 kann einen fixierten Funktionsblock 230 aufweisen, der mit den mehreren Teilkernen 221A-221F, auch als Teilprozessorelemente bezeichnet, gekoppelt ist, die modulare Blöcke von Allzweck- und fixierter Funktionslogik aufweisen.
In manchen Ausführungsformen weist der fixierte Funktionsblock 230 eine Geometrie-/fixierte Funktionspipeline 231 auf, die sich alle Teilkerne in dem Grafikprozessorkern 219 zum Beispiel in Niederarbeitsleistungs- und/oder Niederleistungsgrafikprozessorimplementierungen teilen können. In unterschiedlichen Ausführungsformen weist die Geometrie-/fixierte Funktionspipeline 231 eine 3Dfixierte Funktionspipeline (z.B. 3D-Pipeline 312 wie in 3 und 4 gezeigt, die unten beschrieben sind) eine Videofrontend-Einheit, einen Thread-Spawner und Thread-Dispatcher und einen vereinheitlichten Rückführungspufferverwalter auf, der vereinheitlichte Rückführpuffer (z.B. vereinheitlichte Rückführpuffer 418 in 4, wie unten beschrieben) verwaltet.
In einer Ausführungsform weist der fixierte Funktionsblock 230 auch eine Grafik-SoC-Schnittstelle 232, eine Grafikmikrosteuerung 233 und eine Medienpipeline 234 auf. Die Grafik-SoC-Schnittstelle 232 stellt eine Schnittstelle zwischen dem Grafikprozessorkern 219 und anderen Prozessorkernen innerhalb einer System-auf-einem-Chip-integrierten Schaltung bereit. Die Grafikmikrosteuerung 233 ist ein programmierbarer Teilprozessor, der konfigurierbar ist, unterschiedliche Funktionen des Grafikprozessorkerns 219 zu verwalten, aufweisend Thread-Einlastung, -Planung und -Vorberechtigung. Die Medienpipeline 234 (z.B. Medienpipeline 316 von 3 und 4) weist Logik auf, um die Decodierung, Codierung, Vorverarbeitung und/oder Nachbearbeitung von Multimediadaten, Bild- und Videodaten aufweisend, zu erleichtern. Die Medienpipeline 234 implementiert Medienbetriebe über Anfragen an Rechen- oder Abtastungslogik innerhalb der Teilkerne 221-221F.
In einer Ausführungsform ermöglicht die SoC-Schnittstelle 232 dem Grafikprozessorkern 219, mit Allzweckanwendungsprozessorkernen (z.B. CPUs) und/oder anderen Komponenten innerhalb eines SoC zu kommunizieren, aufweisend Speicherhierarchieelemente, wie geteilten Letztes-Level-Cachespeicher, den System-RAM und/oder auf dem Chip oder auf dem Package eingebetteten DRAM Die SoC-Schnittstelle 232 kann auch Kommunikation mit fixierten Funktionsvorrichtungen innerhalb des SoC ermöglichen, wie Kamerabildgebungspipelines, und ermöglicht die Verwendung von und/oder implementiert globale Speicher-Atomics, die zwischen dem Grafikprozessorkern 219 und CPUs innerhalb des SoC geteilt werden kann. Die SoC-Schnittstelle 232 kann auch Leistungsverwaltungssteuerungen für den Grafikprozessorkern 219 implementieren und eine Schnittstelle zwischen einer Taktdomäne des Grafikkerns 219 und anderen Taktdomänen innerhalb des SoC ermöglichen. In einer Ausführungsform ermöglicht die SoC-Schnittstelle 232 Empfang von Befehlspuffern von einem Befehlsstreamer und globalen Thread-Dispatcher, die konfiguriert sind, Befehle und Anweisungen an jeden eines oder mehrerer Grafikkerne innerhalb eines Grafikprozessors bereitzustellen. Die Befehle und Anweisungen können zu der Medienpipeline 234 eingelastet werden, wenn Medienbetriebe durchzuführen sind, oder zu einer Geometrie- und fixierte Funktionspipeline (z.B. Geometrie- und fixierte Funktionspipeline 231, Geometrie- und fixierte Funktionspipeline 237), wenn Grafikverarbeitungsbetriebe durchzuführen sind.
Die Grafikmikrosteuerung 233 kann konfiguriert sein, unterschiedliche Planungs- und Verwaltungsaufgaben für den Grafikprozessorkern 219 durchzuführen. In einer Ausführungsform kann die Grafikmikrosteuerung 233 Grafik- und/oder Rechennutzlastplanung an den unterschiedlichen parallelen Grafik-Engines innerhalb von Ausführungseinheit- (EU, Execution Unit) Arrays 222A-222F, 224A-224F innerhalb der Teilkerne 221A-221F durchführen. In diesem Planungsmodell kann Hostsoftware, die auf einem CPU-Kern eines SoC läuft, das den Grafikprozessorkern 219 aufweist, Arbeitslasten einem von mehreren Grafikprozessor-Doorbells vorlegen, was einen Planungsbetrieb auf der geeigneten Grafik-Engine aufruft. Planungsbetriebe weisen auf zu ermitteln, welche Arbeitslast als nächstes abzuspielen ist, eine Arbeitslast einem Befehlsstreamer vorzulegen, bestehende Arbeitslasten, die auf einer Engine laufen, vorab zu berechtigen, Fortschritt einer Arbeitslast zu überwachen und Hostsoftware zu benachrichtigen, wenn eine Arbeitslast abgeschlossen ist. In einer Ausführungsform kann die Grafikmikrosteuerung 233 auch Niederleistungs- oder inaktive Zustände für den Grafikprozessorkern 219 erleichtern, was dem Grafikprozessorkern 219 die Fähigkeit bereitstellt, Register innerhalb des Grafikprozessorkerns 219 über Niederleistungszustandsübergänge unabhängig von dem Betriebssystem und/oder der Grafiktreibersoftware auf dem System zu speichern und wiederherzustellen.
Der Grafikprozessorkern 219 kann mehr oder weniger als die veranschaulichten Teilkerne 221A-221F aufweisen, bis zu N modulare Teilkerne. Für jeden Satz von N Teilkernen kann der Grafikprozessorkern 219 auch geteilte Funktionslogik 235 und/oder Cachespeicher 236, eine Geometrie-/fixierte Funktionspipeline 237, wie auch zusätzliche fixierte Funktionslogik 238 aufweisen, um unterschiedliche Grafik- und Rechenverarbeitungsbetriebe zu beschleunigen. Die geteilte Funktionslogik 235 kann Logikeinheiten aufweisen, die mit der geteilten Funktionslogik 420 von 4 (z.B. Abtaster-, Mathematik- und/oder Zwischen-Thread-Kommunikationslogik) verknüpft sind, die durch jeden der N Teilkerne innerhalb des Grafikprozessorkerns 219 geteilt werden kann. Der geteilte und/oder Cachespeicher 236 kann ein Letztes-Level-Cache für den Satz von N Teilkernen 221A-221F innerhalb des Grafikprozessorkerns 219 sein und kann auch als geteilter Speicher dienen, der für mehrere Teilkerne zugänglich ist. Die Geometrie-/fixierte Funktionspipeline 237 kann stattdessen in der Geometrie-/fixierte Funktionspipeline 231 innerhalb des fixierten Funktionsblocks 230 aufgewiesen sein und kann dieselben oder ähnliche Logikeinheiten aufweisen.
In einer Ausführungsform weist der Grafikprozessorkern 219 zusätzliche fixierte Funktionslogik 238 auf, die unterschiedliche fixierte Funktionsbeschleunigungslogik zur Verwendung durch den Grafikprozessorkern 219 aufweisen kann. In einer Ausführungsform weist die zusätzliche fixierte Funktionslogik 238 eine zusätzliche Geometriepipeline zur Verwendung bei ausschließlicher Positionsschattierung auf. Bei ausschließlicher Positionsschattierung gibt es zwei Geometriepipelines, die vollständige Geometriepipeline innerhalb der Geometrie-/fixierte Funktionspipeline 238, 231, und eine Auslesepipeline, die eine zusätzliche Geometriepipeline ist, die innerhalb der zusätzlichen fixierte Funktionslogik 238 aufgewiesen sein kann. In einer Ausführungsform ist die Auslesepipeline eine reduzierte Version der vollständigen Geometriepipeline. Die vollständige Pipeline und die Auslesepipeline können verschiedene Instanzen derselben Anwendung ausführen, wobei jede Instanz einen separaten Kontext aufweist. Ausschließliche Positionsschattierung kann lange Auslesedurchläufe verworfener Dreieckte verstecken, was ermöglicht, Schattierung in manchen Instanzen früher abzuschließen. Zum Beispiel und in einer Ausführungsform kann die Auslesepipelinelogik innerhalb der zusätzlichen fixierten Funktionslogik 238 Positionsshader parallel mit der Hauptanwendung ausführen und im Allgemeinen kritische Ergebnisse schneller als die vollständige Pipeline erzeugen, da die Auslesepipeline nur das Positionsattribut der Scheitelpunkte abruft und schattiert, ohne Rasterisierung und Rendering der Pixel an dem Framepuffer durchzuführen. Die Auslesepipeline kann die erzeugten kritischen Ergebnisse verwenden, um Sichtbarkeitsinformationen über alle der Dreiecke zu berechnen, ohne zu berücksichtigen, ob diese Dreiecke ausgelesen sind. Die vollständige Pipeline (die in dieser Instanz als eine Wiedergabepipeline bezeichnet werden kann) kann die Sichtbarkeitsinformationen verwerten, um die ausgelesenen Dreiecke zu überspringen, um nur die sichtbaren Dreiecke zu schattieren, die letztlich zu der Rasterisierungsphase weitergegeben werden.
In einer Ausführungsform kann die zusätzliche fixierte Funktionslogik 238 auch Maschinenlernbeschleunigungslogik, wie fixierte Funktionsmatrixmultiplikationslogik, für Implementierungen aufweisen, die Optimierungen für Maschinenlerntraining oder Schlussfolgerung aufweisen.
Innerhalb jedes Grafikteilkerns 221A-221F ist ein Satz von Ausführungsressourcen aufgewiesen, die verwendet werden können, um Grafik-, Medien- und Rechenbetriebe in Antwort auf Anfragen durch Grafikpipeline, Medienpipeline oder Shader-Programme durchzuführen. Die Grafikteilkerne 221A-221F weisen mehrere EU-Arrays 222A-222F, 224A-224F, Thread-Einlastungs- und Zwischenthread-Kommunikations- (TD/IC) -logik 223A-223F, einen 3D (z.B. Textur) Abtaster 225A-225F, einen Medienabtaster 206A-206F, einen Shader-Prozessor 227A-227F und geteilten lokalen Speicher (SLM) 228A-228F auf. Die EU-Arrays 222A-222F, 224A-224F weisen jeweils mehrere Ausführungseinheiten auf, die Allzweckgrafikverarbeitungseinheiten sind, die im Stande sind Gleitkomma- und Ganzzahl-/Festpunktlogikbetriebe im Dienst eines Grafik-, Medien- oder Rechenbetriebs durchzuführen, aufweisend Grafik-, Medien- oder Rechenshader-Programme. Die TD/IC-Logik 223A-223F führt lokale Thread-Einlastung und Thread-Steuerungsbetriebe für die Ausführungseinheiten innerhalb eines Teilkerns durch und erleichtert Kommunikation zwischen Threads, die auf den Ausführungseinheiten des Teilkerns ausführen. Der 3D-Abtaster 225A-225F kann Textur oder andere 3D-Grafik bezüglich Daten in Speicher lesen. Der 3D-Abtaster kann Texturdaten basierend auf einem konfigurierten Abtastzustand und dem mit einer gegebenen Textur verknüpften Texturformat unterschiedlich lesen. Der Medienabtaster 206A-206F kann ähnliche Lesebetriebe basierend auf dem Typ und Format, die mit Mediendaten verknüpft sind, durchführen. In einer Ausführungsform kann jeder Grafikteilkern 221A-221F stattdessen einen vereinheitlichten 3D- und Medienabtaster aufweisen. Threads, die auf den Ausführungseinheiten innerhalb jedes der Teilkerne 221A-221F ausführen, können geteilten lokalen Speicher 228A-228F innerhalb jedes Teilkerns verwenden, um Threads zu ermöglichen, innerhalb einer Threadgruppe auszuführen, um unter Verwendung eines gemeinsamen Pools von Auf-dem-Chip-Speicher auszuführen.
2C veranschaulicht eine Grafikverarbeitungseinheit (GPU) 239, die dedizierte Sätze von Grafikverarbeitungsressourcen in Multikerngruppen 240A-240N eingerichtet aufweist. Während die Details nur einer einzelnen Multikerngruppe 240A bereitgestellt sind, wird begrüßt, dass die anderen Multikerngruppen 240B-240N mit denselben oder ähnlichen Sätzen von Grafikverarbeitungsressourcen ausgestattet sein können.
Wie veranschaulicht, kann eine Multikerngruppe 240A einen Satz von Grafikkernen 243, einen Satz von Tensorkernen 244 und einen Satz von Raytracing-Kernen 245 aufweisen. Ein Einplaner/Dispatcher 241 plant und lastet Grafikthreads zur Ausführung auf den unterschiedlichen Kernen 243, 244, 245 ein. Ein Satz von Registerdateien 242 speichert Operandenwerte, die von den Kernen 243, 244, 245 verwendet werden, wenn die Grafikthreads ausgeführt werden. Diese können zum Beispiel Ganzzahlregister zum Speichern von Ganzzahlwerten, Gleitkommaregister zum Speichern von Gleitkommawerten, Vektorregister zum Speichern gepackter Datenelemente (Ganzzahl und/oder Gleitkommadatenelemente) und Kachelregister zum Speichern von Tensor-/Matrixwerten aufweisen. In einer Ausführungsform sind die Kachelregister als kombinierte Sätze von Vektorregistern implementiert.
Ein oder mehrere kombinierte Level-1- (L1) Caches und geteilte Speichereinheiten 247 speichern Grafikdaten, wie Texturdaten, Scheitelpunktdaten, Pixeldaten, Strahldaten, Volumenbegrenzungsdaten usw. lokal innerhalb jeder Multikerngruppe 240A. Eine oder mehrere Textureinheiten 247 können auch verwendet werden, um Texturierungsbetriebe durchzuführen, wie Texturabbildung und -abtastung. Ein Level-2- (L2) Cache 253, den sich alle oder eine Teilmenge der Multikerngruppen 240A-240N teilen, speichert Grafikdaten und/oder Anweisungen für mehrere gleichzeitige Grafikthreads. Wie veranschaulicht, kann der L2-Cache 253 über mehrere Multikerngruppen 240A-240N gespeichert werden. Wie veranschaulicht, kann der L2-Cache 253 über mehrere Multikerngruppen 240A-240N geteilt werden. Eine oder mehrere Speichersteuerungen 248 koppeln die GPU 239 mit einem Speicher 249, der ein Systemspeicher (z.B. DRAM) und/oder ein dedizierter Grafikspeicher (z.B. GDDR6-Speicher) sein kann.
Eingabe/Ausgabe- (I/O) Schaltkreis 250 koppelt die GPU 239 mit einer oder mehreren I/O-Vorrichtungen 252, wie Digitalsignalprozessoren (DSPs), Netzwerksteuerungen oder Anwendereingabevorrichtungen. Eine Zwischenverbindung auf dem Chip kann verwendet werden, um die I/O-Vorrichtungen 252 mit der GPU 239 und Speicher 249 zu koppeln. Eine oder mehrere I/O-Speicherverwaltungseinheiten (IOMMUs, I/O Memory Management Units) 251 des I/O-Schaltkreises 250 koppeln die I/O-Vorrichtungen 252 direkt mit dem Systemspeicher 249. In einer Ausführungsform verwaltet die IOMMU 251 mehrere Sätze von Seitentabellen, um virtuelle Adressen auf physische Adressen in Systemspeicher 249 abzubilden. In dieser Ausführungsform können die I/O-Vorrichtungen 252, CPU(s) 246 und GPU(s) 239 sich denselben virtuellen Adressraum teilen.
In einer Implementierung unterstützt die IOMMU 251 Virtualisierung. In diesem Fall kann sie einen ersten Satz von Seitentabellen verwalten, um virtuelle Gast-/Grafikadressen auf physische Gast-/Grafikadressen abzubilden, und einen zweiten Satz von Seitentabellen verwalten, um die physischen Gast-/Grafikadressen auf physische System-/Hostadressen (z.B. innerhalb von Systemspeicher 249) abzubilden. Die Basisadressen sowohl des ersten und zweiten Satzes von Seitentabellen können in Steuerungsregistern gespeichert und bei einem Kontextwechsel ausgetauscht werden (z.B. derart, dass der neue Kontext mit Zugriff auf den relevanten Satz von Seitentabellen bereitgestellt ist). Während es nicht in 2C veranschaulicht ist, kann jeder der Kerne 243, 244, 245 und/oder Multikerngruppen 240A-240N Übersetzungsnachschlagepuffer (TLBs, Translation Lookaside Buffers) aufweisen, um virtueller Gast zu physischem Gast Übersetzungen, physischer Gast zu physischem Host Übersetzungen und virtueller Gast zu physischem Host Übersetzungen zwischenzuspeichern.
In einer Ausführungsform sind die CPUs 246, GPUs 239 und I/O-Vorrichtungen 252 auf einem einzelnen Halbleiterchip und/oder Chip-Package integriert. Der veranschaulichte Speicher 249 kann auf demselben Chip integriert sein oder kann mit den Speichersteuerungen 248 über eine Schnittstelle extern vom Chip gekoppelt sein. In einer Implementierung umfasst der Speicher 249 GDDR6-Speicher, der sich denselben virtuellen Adressraum wie andere physische Systemlevelspeicher teilt, obwohl die zugrundeliegenden Prinzipien der Erfindung nicht auf diese bestimmte Implementierung begrenzt sind.
In einer Ausführungsform weisen die Tensorkerne 244 mehrere Ausführungseinheiten auf, die spezifisch gestaltet sind, Matrixbetriebe durchzuführen, die der fundamentale Rechenbetrieb sind, der verwendet wird, um Tiefenlernbetriebe durchzuführen. Zum Beispiel können gleichzeitige Matrixmultiplikationsbetriebe für neurales Netzwerktraining und Schlussfolgerung verwendet werden. Die Tensorkerne 244 können Matrixverarbeitung unter Verwendung einer Vielfalt von Operandenpräzisionen durchführen, aufweisend Einzelpräzisionsgleitkomma (z.B. 32 Bits), Halbpräzisionsgleitkomma (z.B. 16 Bits), Ganzzahlworte (16 Bits), Bytes (8 Bits) und Halbbytes (4 Bits). In einer Ausführungsform extrahiert eine neurale Netzwerkimplementierung Merkmale jeder gerenderten Szene, die potenziell Details mehrerer Frames kombiniert, um ein hochqualitatives finales Bild zu erstellen.
Bei Tiefenlernimplementierungen kann parallele Matrixmultiplikationsarbeit zur Ausführung auf den Tensorkernen 244 eingeplant werden. Das Training von neuralen Netzwerken benötigt insbesondere eine signifikante Zahl von Zahlenmatrixskalarproduktbetrieben. Um eine Innenproduktformulierung einer N × N × N Matrixmultiplikation zu verarbeiten, können die Tensorkerne 244 mindestens N Skalarproduktverarbeitungselemente aufweisen. Bevor die Matrixmultiplikation beginnt, wird eine gesamte Matrix in Kachelregister geladen und mindestens eine Spalte einer zweiten Matrix wird bei jedem Zyklus für N Zyklen geladen. Bei jedem Zyklus werden N Skalarprodukte verarbeitet.
Matrixelemente können bei verschiedenen Präzisionen gespeichert werden, abhängig von der bestimmten Implementierung, aufweisend 16-Bit-Worte, 8-Bit-Bytes (z.B. INT8) und 4-Bit-Halbbytes (z.B. INT4). Verschiedene Präzisionsmodi können für die Tensorkerne 244 bestimmt werden, um sicherzustellen, dass die effizienteste Präzision für verschiedene Arbeitslasten verwendet wird (z.B. wie Schlussfolgerungsarbeitslasten, die Quantisierung auf Bytes und Halbbytes tolerieren können).
In einer Ausführungsform beschleunigen die Raytracing-Kerne 245 Raytracing-Betriebe für sowohl Echtzeit-Raytracing und Nichtechtzeit-Raytracingimplementierungen. Insbesondere weisen die Raytracing-Kerne 245 Strahlquerungs-/-kreuzungsschaltkreise auf, um Strahlquerung unter Verwendung von Begrenzungsvolumenhierarchien (BVHs, Bounding Volume Hierarchies) durchzuführen und Kreuzungen zwischen Strahlen und Primitiven zu identifizieren, die innerhalb der BVH-Volumen umschlossen sind. Die Raytracing-Kerne 245 können auch Schaltkreise zum Durchführen von Tiefentestung und Auslese (z.B. unter Verwendung eines Z-Puffers oder einer ähnlichen Anordnung) aufweisen. In einer Implementierung führen die Raytracing-Kerne 245 Querungs- und Kreuzungsbetriebe in Einklang mit den hierin beschriebenen Bildentrauschtechniken durch, von denen mindestens ein Abschnitt auf den Tensorkernen 244 ausgeführt werden kann. Zum Beispiel implementieren in einer Ausführungsform die Tensorkerne 244 ein neurales Tiefenlernnetzwerk, um Entrauschen von Frames durchzuführen, das von den Raytracing-Kernen 245 erzeugt wird. Jedoch können die CPU(s) 246, Grafikkerne 243 und/oder Raytracingkerne 245 auch alle oder einen Abschnitt der Entrausch- und/oder Tiefenlernalgorithmen implementieren.
Zusätzlich kann, wie zuvor beschrieben, ein verteilter Ansatz von Entrauschen eingesetzt werden, bei dem die GPU 239 in einer Rechenvorrichtung ist, die mit anderen Rechenvorrichtungen über ein Netzwerk oder eine Hochgeschwindigkeitszwischenverbindung gekoppelt ist. In dieser Ausführungsform teilen sich die zwischenverbundenen Rechenvorrichtungen neurale Netzwerklern-/-trainingsdaten, um die Geschwindigkeit zu verbessern, mit der das gesamte System lernt, Entrauschen für verschiedene Typen von Bildframes und/oder verschiedene Grafikanwendungen durchzuführen.
In einer Ausführungsform verarbeiten die Raytracing-Kerne 245 alle BVH-Querungs- und Strahlprimitivkreuzungen, was die Grafikkerne 243 davor bewahrt, mit tausenden Anweisungen pro Strahl überladen zu werden. In einer Ausführungsform weist jeder Raytracing-Kern 245 einen ersten Satz spezialisierter Schaltkreise zum Durchführen von Begrenzungsboxtests (z.B. für Querungsbetriebe) und einen zweiten Satz spezialisierter Schaltkreise zum Durchführen der Strahl-Dreieck-Kreuzungstests (z.B. kreuzende Strahlen, die gequert wurden) auf. Daher kann in einer Ausführungsform die Multikerngruppe 240A einfach eine Strahlsonde starten und die Raytracing-Kerne 245 können unabhängig Strahlquerung und - kreuzung durchführen und Trefferdaten (z.B. ein Treffer, kein Treffer, viele Treffer usw.) an den Threadkontext zurückgeben. Die anderen Kerne 243, 244 sind frei, um andere Grafik- oder Rechenarbeit durchführen, während die Raytracing-Kerne 245 die Querungs- und Kreuzungsbetriebe durchführen.
In einer Ausführungsform weist jeder Raytracing-Kern 245 eine Querungseinheit auf, um BVH-Testbetriebe durchzuführen und eine Kreuzungseinheit, die Strahl-Primitiv-Kreuzungstests durchführt. Die Kreuzungseinheit erzeugt einen „Treffer“, „Nichttreffer“ oder „mehrere Treffer“ Antwort, die sie dem geeigneten Thread bereitstellt. Während der Querungs- und Kreuzungsbetriebe sind die Ausführungsressourcen der anderen Kerne (z.B. Grafikkerne 243 und Tensorkerne 244) frei, andere Formen von Grafikarbeit durchzuführen.
In einer unten beschriebenen bestimmten Ausführungsform wird ein Hybrid-Rasterisierungs-/Raytracing-Ansatz verwendet, in dem Arbeit zwischen den Grafikkernen 243 und Raytracing-Kernen 245 aufgeteilt wird.
In einer Ausführungsform weisen die Raytracing-Kerne 245 (und/oder andere Kerne 243, 244) Hardwareunterstützung für einen Raytracing-Anweisungssatz wie Microsofts DirectX Ray Tracing (DXR) auf, der einen DispatchRays-Befehl aufweist, wie auch Strahlerzeugungs-, nächster-Hit-, beliebiger-Treffer- und Verfehlungsshader, die die Zuweisung eindeutiger Sätze von Shadern und Texturen für jedes Objekt ermöglichen. Eine andere Raytracing-Plattform, die von den Raytracing-Kernen 245, Grafikkernen 243 und Tensorkernen 244 unterstütz werden kann, ist Vulkan 1.1.85. Man beachte jedoch, dass die zugrundeliegenden Prinzipien der Erfindung nicht auf irgendeine bestimmte Raytracing-ISA begrenzt ist.
Im Allgemeinen können die unterschiedlichen Kerne 245, 244, 243 einen Raytracing-Anweisungssatz unterstützen, der Anweisungen/Funktionen für Strahlerzeugung, nächster Treffer, beliebiger Treffer, Strahl-Primitiv-Kreuzung, pro-Primitiv und hierarchische Begrenzungsboxerrichtung, Verfehlung, Aufsuchen und Ausnahmen aufweist. Genauer weist eine Ausführungsform Raytracing-Anweisungen auf, um die folgenden Funktionen durchzuführen:
Ray Generation - Strahlerzeugungsanweisungen können für jedes Pixel, jede Probe oder andere anwenderdefinierte Arbeitszuweisung ausgeführt werden.
Closest Hit - Eine nächster-Treffer-Anweisung kann ausgeführt werden, um den nächsten Kreuzungspunkt eines Strahls mit Primitiven innerhalb einer Szene zu lokalisieren.
Any Hit - Eine beliebiger-Treffer-Anweisung identifiziert mehrere Kreuzungen zwischen einem Strahl und Primitiven innerhalb einer Szene, potenziell, um einen neuen nächsten Kreuzungspunkt zu identifizieren.
Intersection - Eine Kreuzungsanweisung führt einen Strahl-Primitiv-Kreuzungstest durch und gibt ein Ergebnis aus.
Per-primitive Bounding box Construction - Diese Anweisung bildet eine Begrenzungsbox um ein gegebenes Primitiv oder Gruppen von Primitiven (z.B. wenn eine neue BVH oder andere Beschleunigungsdatenstruktur gebildet wird).
Miss - gibt an, dass ein Strahl die gesamte Geometrie innerhalb einer Szene oder ein bestimmtes Gebiet einer Szene verfehlt.
Visit - gibt die Untervolumina an, die ein Strahl queren wird.
Exceptions - weist unterschiedliche Typen von Ausnahmehandlern auf (z.B. für unterschiedliche Fehlerbedingungen aufgerufen).
2D ist ein Blockdiagramm einer Allzweckgrafikverarbeitungseinheit (GPGPU, General Purpose Graphics Processing Unit) 270, die gemäß hierin beschriebenen Ausführungsformen als ein Grafikprozessor und/oder Rechenbeschleuniger konfiguriert sein kann. Die GPGPU 270 kann sich mit Prozessoren (z.B. eine oder mehrere CPU(s) 246) und Speicher 271, 272 über einen oder mehrere System- und/oder Speicherbusse zwischenverbinden. In einer Ausführungsform ist der Speicher 271 Systemspeicher, der mit der einen oder den mehreren CPU(s) 246 geteilt werden kann, während Speicher 272 Vorrichtungsspeicher ist, der dediziert für die GPGPU 270 ist. In einer Ausführungsforme können Komponenten innerhalb der GPGPU 270 und Vorrichtungsspeicher 272 in Speicheradressen abgebildet werden, die für die eine oder mehreren CPU(s) 246 zugänglich sind. Zugriff auf Speicher 271 und 272 können über eine Speichersteuerung 268 erleichtert werden. In einer Ausführungsform weist die Speichersteuerung 268 eine interne Direktspeicherzugriff- (DMA, Direct Memory Access) -steuerung 269 auf oder kann Logik aufweisen, um Betriebe durchzuführen, die ansonsten von einer DMA-Steuerung durchgeführt werden würden.
Die GPGPU 270 weist mehrere Cachespeicher auf, aufweisend einen L2-Cache 253, L1-Cache 254, einen Anweisungscache 255 und geteilten Speicher 256, von dem mindestens ein Abschnitt auch als ein Cachespeicher partitioniert sein kann. Die GPGPU 270 weist auch mehrere Recheneinheiten 260A-260N auf. Jede Recheneinheit 260A-260N weist einen Satz von Vektorregistern 261, Skalarregistern 262, Vektorlogikeinheiten 263 und Skalarlogikeinheiten 264 auf. Die Recheneinheiten 260A-260N können auch lokal geteilten Speicher 265 und einen Programmzähler 266 aufweisen. Die Recheneinheiten 260A-260N können sich mit einem konstanten Cache 267 koppeln, der verwendet werden kann, um konstante Daten zu speichern, die Daten sind, die sich während des Ablaufs von Kernel oder Shader-Programm nicht ändern, das auf der GPGPU 270 ausführt. In einer Ausführungsform ist das konstante Cache 267 ein Skalardatencache und zwischengespeicherte Daten können direkt in die Skalarregister 262 abgerufen werden.
Während Betrieb können die eine oder mehreren CPU(s) 246 Befehle in Register oder Speicher in der GPGPU 270 schreiben, die in einen zugänglichen Adressraum abgebildet wurde. Die Befehlsprozessoren 257 können die Befehle von Registern oder Speicher lesen und ermitteln, wie diese Befehle innerhalb der GPGPU 270 verarbeitet werden. Ein Thread-Dispatcher 258 kann dann verwendet werden, um Threads zu den Recheneinheiten 260A-260N einzulasten, um diese Befehle durchzuführen. Jede Recheneinheit 260A-260N kann Threads unabhängig von den anderen Recheneinheiten ausführen. Zusätzlich kann jede Recheneinheit 260A-260N unabhängig für konditionale Berechnung konfiguriert sein und kann konditional die Berechnungsergebnisse zu Speicher ausgeben. Die Befehlsprozessoren 257 können die eine oder mehreren CPU(s) 246 unterbrechen, wenn die vorgelegten Befehle abgeschlossen sind.
3A-3C veranschaulichen Blockdiagramme zusätzlicher Grafikprozessor- und Rechenbeschleunigerarchitekturen, die von hierin beschriebenen Ausführungsformen bereitgestellt sind. Die Elemente von 3A-3C, die dieselben Referenznummern (oder Namen) wie die Elemente einer beliebigen anderen FIGUR hierin aufweisen, können auf eine ähnliche Weise wie hier an anderer Stelle beschrieben arbeiten oder funktionieren, sind aber nicht darauf begrenzt.
3A ist ein Blockdiagramm eines Grafikprozessors 300, der eine diskrete Grafikverarbeitungseinheit sein kann, oder ein Grafikprozessor sein kann, in dem mehrere Verarbeitungskerne integriert sind, oder andere Halbleitervorrichtungen, wie, aber nicht begrenzt auf, Speichervorrichtungen oder Netzwerkschnittstellen. In manchen Ausführungsformen kommuniziert der Grafikprozessor über eine speicherabgebildete I/O-Schnittstelle mit Registern auf dem Grafikprozessor und mit Befehlen, die in den Prozessorspeicher platziert sind. In manchen Ausführungsformen weist Grafikprozessor 300 eine Speicherschnittstelle 314 zu Zugriffsspeicher auf. Speicherschnittstelle 314 kann eine Schnittstelle zu lokalem Speicher, einem oder mehreren internen Caches, einem oder mehreren geteilten externen Caches und/oder zu Systemspeicher sein.
In manchen Ausführungsformen weist Grafikprozessor 300 auch eine Anzeigesteuerung 302 auf, um Anzeigeausgabedaten zu einer Anzeigevorrichtung 318 zu treiben. Anzeigesteuerung 302 weist Hardware für eine oder mehrere Überlagerungsebenen für die Anzeige und Zusammenstellung von mehreren Schichten von Video oder Anwenderschnittstellenelementen auf. Die Anzeigevorrichtung 318 kann eine interne oder externe Anzeigevorrichtung sein. In einer Ausführungsform ist die Anzeigevorrichtung 318 eine am Kopf befestigte Anzeigevorrichtung, wie eine Anzeigevorrichtung für virtuelle Realität (VR, Virtual Reality) oder eine Anzeigevorrichtung für erweiterte Realität (AR, Augmented Reality). In manchen Ausführungsformen weist Grafikprozessor 300 eine Videocodec-Engine 306 auf, um Medien zu, von oder zwischen einem oder mehreren Mediencodierungsformaten zu codieren, decodieren oder transcodieren, aufweisend, aber nicht begrenzt auf, Moving Picture Experts Group (MPEG) Formate, wie MPEG-2, Advanced Video Coding (AVC) Formate, wie H.264/MPEG-4 AVC, H.265/HEVC, Alliance for Open Media (AOMedia) VP8, VP9, wie auch die Society of Motion Picture & Television Engineers (SMPTE) 421M/VC-1 und Joint Photographic Experts Group (JPEG) Formate, wie JPEG, und Motion JPEG (MJPEG) Formate.
In manchen Ausführungsformen weist Grafikprozessor 300 eine Blockbildtransfer- (BLIT, Block Image Transfer) Engine 304 auf, um zweidimensionale (2D) Rasterisierungsbetriebe durchzuführen, aufweisend zum Beispiel Bitbegrenzungsblocktransfers. Jedoch sind in einer Ausführungsform 2D-Grafikbetriebe unter Verwendung einer oder mehrerer Komponenten von Grafikverarbeitungs-Engine (GPE, Graphics Processing Engine) 310 durchgeführt. In manchen Ausführungsformen ist GPE 310 eine Rechen-Engine zum Durchführen von Grafikbetrieben, aufweisend dreidimensionale (3D) Grafikbetriebe und Medienbetriebe.
In manchen Ausführungsformen weist GPE 310 eine 3D-Pipeline 312 zum Durchführen von 3D-Betrieben auf, wie Rendern von dreidimensionalen Bildern und Szenen unter Verwendung von Verarbeitungsfunktionen, die auf 3D-Primitivformen (z.B. Rechteck, Dreieck usw.) wirken. Die 3D-Pipeline 312 weist programmierbare und fixierte Funktionselemente auf, die unterschiedliche Aufgaben innerhalb des Elements durchführen und/oder Ausführungsthreads zu einem 3D/Medienteilsystem 315 starten. Während 3D-Pipeline 312 verwendet werden kann, um Medienbetriebe durchzuführen, weist eine Ausführungsform von GPE 310 auch eine Medienpipeline 316 auf, die insbesondere verwendet wird, um Medienbetriebe durchzuführen, wie Videonachbearbeitung und Bildverbesserung.
In manchen Ausführungsformen weist Medienpipeline 316 fixierte Funktions- oder programmierbare Logikeinheiten auf, um einen oder mehrere spezialisierte Medienbetriebe durchzuführen, wie Videodecodierungsbeschleunigung, Videoentflechtung und Videocodierungsbeschleunigung anstelle von oder seitens der Videocodec-Engine 306. In manchen Ausführungsformen weist Medienpipeline 316 zusätzlich eine Thread-Starteinheit auf, um Threads zur Ausführung auf 3D-/Medienteilsystem 315 zu starten. Die gestarteten Threads führen Berechnungen für die Medienbetriebe auf einer oder mehreren Grafikausführungseinheiten durch, die in 3D-/Medienteilsystem 315 aufgewiesen sind.
In manchen Ausführungsformen weist 3D-/Medienteilsystem 315 Logik zum Ausführen von Threads auf, die von 3D-Pipeline 312 und Medienpipeline 316 gestartet wurden. In einer Ausführungsform senden die Pipelines Thread-Ausführungsanfragen an 3D-/Medienteilsystem 315, das Thread-Einlastungslogik zum Vermitteln und Einlasten der unterschiedlichen Anfragen an verfügbare Thread-Ausführungsressourcen aufweist. Die Ausführungsressourcen weisen ein Array von Grafikausführungseinheiten auf, um die 3D- und Medienthreads zu verarbeiten. In manchen Ausführungsformen weist 3D-/Medienteilsystem 315 einen oder mehrere interne Caches für Threadanweisungen und Daten auf. In manchen Ausführungsformen weist das Teilsystem auch geteilten Speicher auf, aufweisend Register und adressierbaren Speicher, um Daten zwischen Threads zu teilen und Ausgabedaten zu speichern.
3B veranschaulicht einen Grafikprozessor 320, der eine gekachelte Architektur aufweist, gemäß hierin beschriebenen Ausführungsformen. In einer Ausführungsform weist der Grafikprozessor 320 einen Grafikverarbeitungs-Engine-Cluster 322 auf, der mehrere Instanzen der Grafikverarbeitungs-Engine 310 von 3A innerhalb einer Grafik-Engine-Kachel 310A-310D aufweist. Jede Grafik-Engine-Kachel 310A-310D kann über einen Satz von Kachelzwischenverbindungen 323A-323F zwischenverbunden sein. Jede Grafik-Engine-Kachel 310A-310D kann auch mit einem Speichermodul oder einer Speichervorrichtung 326A-326D über Speicherzwischenverbindungen 325A-325D verbunden sein. Die Speichervorrichtungen 326A-326D können beliebige Grafikspeichertechnologie verwenden. Zum Beispiel können die Speichervorrichtungen 326A-326D Grafikdoppeldatenraten- (GDDR, Graphics Double Data Rate) Speicher sein. Die Speichervorrichtungen 326A-326D sind in einer Ausführungsform Hochbandbreitenspeicher- (HBM, High Bandwidth Memory) Module, die mit deren jeweiliger Grafik-Engine-Kachel 310A-310D auf dem Die sein können. In einer Ausführungsform sind die Speichervorrichtungen 326A-326D gestapelte Speichervorrichtungen, die auf deren jeweilige Grafik-Engine-Kachel 310A-310D gestapelt sein können. In einer Ausführungsform liegen jede Grafik-Engine-Kachel 310A-310D und damit verknüpfter Speicher 326A-326D auf separaten Chiplets, die an einen Basis-Die oder ein Basissubstrat gebondet sind, wie ferner in 11B-11D im Detail beschrieben wird.
Der Grafikverarbeitungs-Engine-Cluster 322 kann sich mit einer Fabric-Zwischenverbindung 324 auf dem Chip oder auf dem Package verbinden. Die Fabric-Zwischenverbindung 324 kann Kommunikation zwischen Grafik-Engine-Kacheln 310A-310D und Komponenten wie dem Videocodec 306 und einer oder mehreren Koper-Engines 304 ermöglichen. Die Kopier-Engines 304 können verwendet werden, um Daten aus den, in die und zwischen den Speichervorrichtungen 326A-326D und Speicher zu bewegen, der außerhalb des Grafikprozessors 320 (z.B. Systemspeicher) ist. Die Fabric-Zwischenverbindung 324 kann verwendet werden, um die Grafik-Engine-Kacheln 310A-310D zwischenzu-verbinden. Der Grafikprozessor 320 kann optional eine Anzeigesteuerung 302 aufweisen, um eine Verbindung mit einer externen Anzeigevorrichtung 318 zu ermöglichen. Der Grafikprozessor kann auch als ein Grafik- oder Rechenbeschleuniger konfiguriert sein. In der Beschleunigerkonfiguration können die Anzeigesteuerung 302 und Anzeigevorrichtung 318 ausgelassen werden.
Der Grafikprozessor 320 kann sich über eine Hostschnittstelle 328 mit einem Hostsystem verbinden. Die Hostschnittstelle 328 kann Kommunikation zwischen dem Grafikprozessor 320, Systemspeicher und/oder anderen Systemkomponenten ermöglichen. Die Hostschnittstelle 328 kann zum Beispiel ein PCI Express Bus oder ein anderer Typ von Hostsystemschnittstelle sein.
3C veranschaulicht einen Rechenbeschleuniger 330 gemäß hierin beschriebenen Ausführungsformen. Der Rechenbeschleuniger 330 kann architektonische Ähnlichkeiten mit dem Grafikprozessor 320 von 3B aufweisen und ist zur Rechenbeschleunigung optimiert. Ein Rechen-Engine-Cluster 332 kann einen Satz von Rechen-Engine-Kacheln 340A-340D aufweisen, die Ausführungslogik aufweisen, die für parallele oder vektorbasierte Allzweckrechenbetriebe optimiert ist. In manchen Ausführungsformen weisen die Rechen-Engine-Kacheln 340A-340D keine Grafikverarbeitungslogik mit fixierter Funktion auf, obwohl in einer Ausführungsform eine oder mehrere der Rechen-Engine-Kacheln 340A-340D Logik aufweisen können, um Medienbeschleunigung durchzuführen. Die Rechen-Engine-Kacheln 340A-340D können mit Speicher 326A-326D über Speicherzwischenverbindungen 325A-325D verbunden sein. Der Speicher 326A-326D und Speicherzwischenverbindungen 325A-325D können ähnliche Technologie wie in Grafikprozessor 320 aufweisen oder davon verschieden sein. Die Grafikrechen-Engine-Kacheln 340A-340D können auch über einen Satz von Kachelzwischenverbindungen 323A-323F zwischenverbunden sein und können mit einer Fabric-Zwischenverbindung 324 verbunden sein und/oder durch diese zwischenverbunden sein. In einer Ausführungsform weist der Rechenbeschleuniger 330 einen großen L3-Cache 336 auf, der als ein vorrichtungsweiter Cache konfiguriert sein kann. Der Rechenbeschleuniger 330 kann auch mit einem Hostprozessor und Speicher über eine Hostschnittstelle 328 auf eine ähnliche Weise wie der Grafikprozessor 320 von 3B verbunden sein.
Grafikverarbeitungs-Engine
4 ist ein Blockdiagramm einer Grafikverarbeitungs-Engine 410 eines Grafikprozessors in Übereinstimmung mit manchen Ausführungsformen. In einer Ausführungsform ist die Grafikverarbeitungs-Engine (GPE) 410 eine Version der in 3A gezeigten GPE 310 und kann auch eine Grafik-Engine-Kachel 310A-310D von 3B darstellen. Elemente von 4, die dieselben Referenznummern (oder Namen) wie die Elemente einer beliebigen anderen FIGUR hierin aufweisen, können auf eine ähnliche Weise wie hier an anderer Stelle beschrieben arbeiten oder funktionieren, sind aber nicht darauf begrenzt. Zum Beispiel sind die 3D-Pipeline 312 und Medienpipeline 316 von 3A veranschaulicht. Die Medienpipeline 316 ist optional in manchen Ausführungsformen der GPE 410 und kann ausdrücklich innerhalb der GPE 410 aufgewiesen sein. Zum Beispiel und in mindestens einer Ausführungsform ist ein separater Medien- und/oder Bildprozessor mit der GPE 410 gekoppelt.
In manchen Ausführungsformen koppelt sich GPE 410 mit einem Befehlsstreamer 403 oder weist diesen auf, der einen Befehlsstream zu der 3D-Pipeline 312 und/oder den Medienpipelines 316 bereitstellt. In manchen Ausführungsformen ist Befehlsstreamer 403 mit Speicher, der Systemspeicher sein kann, oder einem oder mehreren von internem Cachespeicher und geteiltem Cachespeicher gekoppelt. In manchen Ausführungsformen empfängt Befehlsstreamer 403 Befehle von dem Speicher und sendet die Befehle an 3D-Pipeline 312 und/oder Medienpipeline 316. Die Befehle sind von einem Ringpuffer, der Befehle für die 3D-Pipeline 312 und Medienpipeline 316 speichert, abgerufene Richtlinien. In einer Ausführungsform kann der Ringpuffer zusätzlich Sammelbefehlspuffer aufweisen, die Sammlungen mehrerer Befehle speichern. Die Befehle für die 3D-Pipeline 312 können auch Referenzen auf Daten aufweisen, die in Speicher gespeichert sind, wie, aber nicht begrenzt auf, Scheitelpunkt- und Geometriedaten für die 3D-Pipeline 312 und/oder Bilddaten und Speicherobjekte für die Medienpipeline 316. Die 3D-Pipeline 312 und Medienpipeline 316 verarbeiten die Befehle und Daten, indem Betriebe über Logik innerhalb der jeweiligen Pipelines durchgeführt werden oder indem ein oder mehrere Ausführungsthreads in ein Grafikkernarray 414 eingelastet werden. In einer Ausführungsform weist das Grafikkernarray 414 einen oder mehrere Blöcke von Grafikkernen (z.B. Grafikkern(e) 415A, Grafikkern(e) 415B) auf, wobei jeder Block einen oder mehrere Grafikkerne aufweist. Jeder Grafikkern weist einen Satz von Grafikausführungsressourcen auf, der Allzweck- und grafikspezifische Ausführungslogik aufweist, um Grafik- und Rechenbetriebe durchzuführen, wie auch Texturverarbeitung mit fixierter Funktion und/oder Maschinenlern- und Beschleunigungslogik mit künstlicher Intelligenz.
In unterschiedlichen Ausführungsformen kann die 3D-Pipeline 312 fixierte Funktion und programmierbare Logik aufweisen, um ein oder mehrere Shader-Programme zu verarbeiten, wie Scheitelpunktshader, Geometrieshader, Pixelshader, Fragmentshader, Rechenshader oder andere Shaderprogramme, indem die Anweisungen verarbeitet werden und Ausführungsthreads in das Grafikkernarray 414 eingelastet werden. Das Grafikkernarray 414 stellt einen vereinheitlichten Block von Ausführungsressourcen zur Verwendung bei Verarbeitung dieser Shader-Programme bereit. Mehrzweckausführungslogik (z.B. Ausführungseinheiten) innerhalb des/der Grafikkerns (Grafikkerne) 415A-414B des Grafikkernarrays 414 weist Unterstützung für unterschiedliche 3D-API-Shader-Sprachen auf und kann mehrere gleichzeitige Ausführungsthreads ausführen, die mit mehreren Shadern verknüpft sind.
In manchen Ausführungsformen weist das Grafikkernarray 414 Ausführungslogik auf, um Medienfunktionen durchzuführen, wie Video- und/oder Bildverarbeitung. In einer Ausführungsform weisen die Ausführungseinheiten Allzwecklogik auf, die programmierbar ist, parallele Allzweckrechenbetriebe zusätzlich zu Grafikverarbeitungsbetrieben durchzuführen. Die Allzwecklogik kann Verarbeitungsbetriebe parallel oder in Verbindung mit Allzwecklogik innerhalb des/der Prozessorkerns (Prozessorkerne) 107 von 1 oder Kern 202A-202N, wie in 2A, durchführen.
Ausgabedaten, die von Threads erzeugt werden, die auf dem Grafikkernarray 414 ausführen, können Daten an Speicher in einem vereinheitlichen Rückführungspuffer (URB, Unified Return Buffer) 418 ausgeben. Der URB 418 kann Daten für mehrere Threads speichern. In manchen Ausführungsformen kann der URB 418 verwendet werden, um Daten zwischen verschiedenen Threads zu senden, die auf dem Grafikkernarray 414 ausführen. In manchen Ausführungsformen kann der URB 418 zusätzlich zur Synchronisation zwischen Threads auf dem Grafikkernarray und fixierter Funktionslogik innerhalb der geteilten Funktionslogik 420 verwendet werden.
In manchen Ausführungsformen ist Grafikkernarray 414 derart skalierbar, dass das Array eine variable Zahl von Grafikkernen aufweist, wobei jeder eine variable Zahl von Ausführungseinheiten aufweist, basierend auf der Zielleistung und dem Arbeitsleistungslevel von GPE 410. In einer Ausführungsform sind die Ausführungsressourcen derart dynamisch skalierbar, dass Ausführungsressourcen nach Bedarf aktiviert oder deaktiviert werden können.
Das Grafikkernarray 414 koppelt sich mit geteilter Funktionslogik 420, die mehrere Ressourcen aufweist, die zwischen den Grafikkernen in dem Grafikkernarray geteilt werden. Die geteilten Funktionen innerhalb der geteilten Funktionslogik 420 sind Hardwarelogikeinheiten, die spezialisierte ergänzende Funktionalität zu dem Grafikkernarray 414 bereitstellen. In unterschiedlichen Ausführungsformen weist geteilte Funktionslogik 420 auf, ist aber nicht begrenzt auf, Abtaster- 421, Mathematik- 422 und Zwischen-Thread-Kommunikations- (ITC) 423 Logik. Zusätzlich implementieren manche Ausführungsformen einen oder mehrere Cache(s) 425 innerhalb der geteilten Funktionslogik 420.
Eine geteilte Funktion ist mindestens in einem Fall implementiert, wo der Bedarf an einer gegebenen spezialisierten Funktion zum Einschluss innerhalb des Grafikkernarrays 414 unzureichend ist. Stattdessen ist eine einzelne Instanziierung dieser spezialisierten Funktion als eine eigenständige Entität in der geteilten Funktionslogik 420 implementiert und wird unter den Ausführungsressourcen innerhalb des Grafikkernarrays 414 geteilt. Der präzise Satz von Funktionen, die zwischen dem Grafikkernarray 414 geteilt werden und innerhalb des Grafikkernarrays 414 aufgewiesen sind, variiert über die Ausführungsformen hinweg. In manchen Ausführungsformen können bestimmte geteilte Funktionen innerhalb der geteilten Funktionslogik 420, die umfangreich von dem Grafikkernarray 414 verwendet werden, innerhalb geteilter Funktionslogik 426 innerhalb des Grafikkernarrays 414 aufgewiesen sein. In unterschiedlichen Ausführungsformen kann die geteilte Funktionslogik 416 innerhalb des Grafikkernarrays 414 manche oder alle Logik innerhalb der geteilten Funktionslogik 420 aufweisen. In einer Ausführungsform können alle Logikelemente innerhalb der geteilten Funktionslogik 420 innerhalb der geteilten Funktionslogik 416 des Grafikkernarrays 414 dupliziert sein. In einer Ausführungsform ist die geteilte Funktionslogik 420 zugunsten der geteilten Funktionslogik 416 innerhalb des Grafikkernarrays 414 ausgeschlossen.
Ausführungseinheiten
5A-5B veranschaulichen Thread-Ausführungslogik 500, die ein Array von Verarbeitungselementen aufweist, die in einem Grafikprozessorkern aufgewiesen sind, gemäß hierin beschriebenen Ausführungsformen. Elemente von 5A-5B, die dieselben Referenznummern (oder Namen) wie die Elemente einer beliebigen anderen FIGUR hierin aufweisen, können auf eine ähnliche Weise wie hier an anderer Stelle beschrieben arbeiten oder funktionieren, sind aber nicht darauf begrenzt. 5A-5B veranschaulichen eine Übersicht von Thread-Ausführungslogik 500, die für Hardwarelogik repräsentativ sein kann, die mit jedem Teilkern 221A-221F von 2B veranschaulicht ist. 5A stellt eine Ausführungseinheit innerhalb eines Allzweckgrafikprozessors dar, während 5B eine Ausführungseinheit darstellt, die innerhalb eines Rechenbeschleunigers verwendet werden kann.
Wie in 5A veranschaulicht, weist in manchen Ausführungsformen Thread-Ausführungslogik 500 einen Shader-Prozessor 502, einen Thread-Dispatcher 504, Anweisungscache 506, ein skalierbares Ausführungseinheitsarray, das mehrere Ausführungseinheiten 508A-508N aufweist, einen Abtaster 510, geteilten lokalen Speicher 511, einen Datencache 512 und einen Datenanschluss 514 auf. In einer Ausführungsform kann das skalierbare Ausführungseinheitsarray dynamisch skalieren, indem eine oder mehrere Ausführungseinheiten (z.B. beliebige der Ausführungseinheiten 508A, 508B, 508C, 508D bis 508N-1 und 508N) basierend auf den Rechenanforderungen einer Arbeitslast aktiviert oder deaktiviert werden. In einer Ausführungsform sind die aufgewiesenen Komponenten über ein Zwischenverbindungsfabric zwischenverbunden, das jede der Komponenten verlinkt. In manchen Ausführungsformen weist Thread-Ausführungslogik 500 eine oder mehrere Verbindungen mit Speicher, wie Systemspeicher oder Cachespeicher, durch einen oder mehrere von Anweisungscache 506, Datenanschluss 514, Abtaster 510 und Ausführungseinheiten 508A-508N auf. In manchen Ausführungsformen ist jede Ausführungseinheit (z.B. 508A) eine eigenständige programmierbare Allzweckrecheneinheit, die im Stande ist, mehrere gleichzeitige Hardwarethreads auszuführen, während mehrere Datenelemente parallel für jeden Thread verarbeitet werden. In unterschiedlichen Ausführungsformen ist das Array von Ausführungseinheiten 508A-508N skalierbar, eine beliebige Zahl individueller Ausführungseinheiten aufzuweisen.
In manchen Ausführungsformen sind die Ausführungseinheiten 508A-508N vorrangig verwendet, um Shader-Programme auszuführen. Ein Shader-Prozessor 502 kann die unterschiedlichen Shader-Programme und Einlastungsausführungsthreads, die mit den Shader-Programmen über einen Thread-Dispatcher 504 verknüpft sind, verarbeiten. In einer Ausführungsform weist der Thread-Dispatcher Logik auf, um Thread-Initialisierungsanfragen von den Grafik- und Medienpipelines zu vermitteln und die angefragten Threads auf einer oder mehreren Ausführungseinheiten in den Ausführungseinheiten 508A-508N zu instanziieren. Zum Beispiel kann eine Geometriepipeline Scheiteilpunkt-, Tessellations- oder Geometrieshader zur Verarbeitung zu der Thread-Ausführungslogik einlasten. In manchen Ausführungsformen kann Thread-Dispatcher 504 auch Laufzeit-Thread-Startanfragen von den ausgeführten Shader-Programmen verarbeiten.
In manchen Ausführungsformen unterstützen die Ausführungseinheiten 508A-508N einen Anweisungssatz, der native Unterstützung für viele Standard-3D-Grafikshader-Anweisungen derart aufweist, dass Shaderprogramme von Grafikbibliotheken (z.B. Direct 3D und OpenGL) mit einer minimalen Übersetzung ausgeführt werden. Die Ausführungseinheiten unterstützen Scheitelpunkt- und Geometrieverarbeitung (z.B. Scheitelpunktprogramme, Geometrieprogramme, Scheitelpunktshader), Pixelverarbeitung (z.B. Pixelshader, Fragmentshader) und Allzweckverarbeitung (z.B. Rechen- und Medienshader). Jede der Ausführungseinheiten 508A-508N ist zur Mehrfachausgabe-Einzelanweisung-Mehrfach-Daten- (SIMD, Single Instruction Multiple Data) Ausführung im Stande und multigethreadeter Betrieb ermöglicht eine effiziente Ausführungsumgebung angesichts Speicherzugriffen mit höherer Latenz. Jeder Hardwarethread innerhalb jeder Ausführungseinheit weist eine dedizierte Hochbandbreitenregisterdatei auf und ist mit einem unabhängigen Thread-Zustand verknüpft. Ausführung wird Pro Takt mehrfach an Pipelines ausgestellt, die zu Ganzzahl-, Einzel- und Doppelpräzisionsgleitkommabetrieben, SIMD-Zweigkapazität, logischen Betrieben, transzendentalen Betrieben und anderen diversen Betrieben im Stande sind. Während auf Daten von Speicher oder einer der geteilten Funktionen gewartet wird, veranlasst Abhängigkeitslogik innerhalb der Ausführungseinheiten 508A-508N einen wartenden Thread zu ruhen, bis die angefragten Daten zurückgeleitet wurden. Während der wartende Thread ruht, können Hardwareressourcen Verarbeitung anderer Threads gewidmet werden. Zum Beispiel kann während einer Verzögerung, die mit einem Scheitelpunktshader-Betrieb verknüpft ist, eine Ausführungseinheit Betriebe für einen Pixelshader, Fragmentshader oder einen anderen Typ von Shaderprogramm, das einen verschiedenen Scheitelpunktshader aufweist, durchführen. Unterschiedliche Ausführungsformen können darauf zutreffen, Ausführung unter Verwendung von Einzelanweisung-Mehrfach-Thread (SIMT, Single Instruction Multiple Thread) als eine Alternative zur Verwendung von SIMD oder zusätzlich zur Verwendung von SIMD zu verwenden. Bezug auf einen SIMD-Kern oder Betrieb kann auch auf SIMT zutreffen oder auf SIMD in Kombination mit SIMT zutreffen.
Jede Ausführungseinheit in Ausführungseinheiten 508A-508N arbeitet auf Arrays von Datenelementen. Die Zahl von Datenelementen ist die „Ausführungsgröße“ oder die Zahl von Kanälen für die Anweisung. Ein Ausführungskanal ist eine logische Einheit von Ausführung für Datenelementzugriff, Maskierung und Ablaufsteuerung innerhalb von Anweisungen. Die Zahl von Kanälen kann unabhängig von der Zahl von physischen arithmetischen Logikeinheiten (ALUs, Arithmetic Logic Units) oder Gleitkommaeinheiten (FPUs, Floating Point Units) für einen bestimmten Grafikprozessor sein. In manchen Ausführungsformen unterstützen Ausführungseinheiten 508A-508N Ganzzahl- und Gl ei tkommada tentypen.
Der Ausführungseinheitsanweisungssatz weist SIMD-Anweisungen auf. Die unterschiedlichen Datenelemente können als ein verpackter Datentyp in einem Register gespeichert sein und die Ausführungseinheit wird die unterschiedlichen Elemente basierend auf der Datengröße der Elemente verarbeiten. Zum Beispiel, wenn auf einem 256-Bit breiten Vektor gearbeitet wird, sind die 256 Bits des Vektors in einem Register gespeichert und die Ausführungseinheit arbeitet auf dem Vektor als vier separate 54-Bit verpackte Datenelemente (Quad-Wort (QW) große Datenelemente), acht separaten 32-Bit verpackten Datenelementen (Doppelwort (DW) große Datenelemente), sechzehn separate 16-Bit verpackte Datenelemente (Wort (W) große Datenelemente) oder zweiunddreißig separate 8-Bit Datenelemente (Byte (B) große Datenelemente). Jedoch sind verschiedene Vektorbreiten und Registergrößen möglich.
In einer Ausführungsform können eine oder mehr Ausführungseinheiten in eine zusammengefügte Ausführungseinheit 509A-509N kombiniert werden, die Thread-Steuerungslogik (507A-507N) aufweist, die die vereinigten EUs gemeinsam haben. Mehrere EUs können in eine EU-Gruppe vereinigt werden. Jede EU in der vereinigten EU-Gruppe kann konfiguriert sein, einen separaten SIMD-Hardwarethread auszuführen. Die Zahl von EUs in einer vereinigten EU-Gruppe kann gemäß Ausführungsformen variieren. Zusätzlich können unterschiedliche SIMD-Breiten pro-EU durchgeführt werden, aufweisend, aber nicht begrenzt auf, SIMD8, SIMD16 und SIMD32. Jede vereinigte Grafikausführungseinheit 509A-509N weist mindestens zwei Ausführungseinheiten auf. Zum Beispiel weist vereinigte Ausführungseinheit 509A eine erste EU 508A, zweite EU 508B und Thread-Steuerungslogik 507A auf, die die erste EU 508A und die zweite EU 508B gemeinsam haben. Die Thread-Steuerungslogik 507A steuert Threads, die auf der vereinigten Grafikausführungseinheit 509A ausgeführt werden, was jeder EU innerhalb der vereinigten Ausführungseinheiten 509A-509N erlaubt, unter Verwendung eines gemeinsamen Anweisungszeigerregisters ausgeführt zu werden.
Ein oder mehrere interne Anweisungscaches (z.B. 506) sind in der Thread-Ausführungslogik 500 aufgewiesen, um Thread-Anweisungen für die Ausführungseinheiten zwischenzuspeichern. In manchen Ausführungsformen sind ein oder mehrere Datencaches (z.B. 512) aufgewiesen, um Threaddaten während Thread-Ausführung zwischenzuspeichern. Threads, die auf der Ausführungslogik 500 ausführen, können auch ausdrücklich verwaltete Daten in dem geteilten lokalen Speicher 511 speichern. In manchen Ausführungsformen ist ein Abtaster 510 aufgewiesen, um Texturabtastung für 3D-Betriebe und Medienabtastung für Medienbetriebe bereitzustellen. In manchen Ausführungsformen weist Abtaster 510 spezialisierte Textur- und Medienabtastungsfunktionalität auf, um Textur- oder Mediendaten während des Abtastungsprozesses zu verarbeiten, bevor die abgetasteten Daten an eine Ausführungseinheit bereitgestellt werden.
Während Ausführung senden die Grafik- und Medienpipelines Thread-Einleitungsanfragen an Thread-Ausführungslogik 500 über Thread-Start- und Einlastungslogik. Sobald eine Gruppe von geometrischen Objekten verarbeitet und in Pixeldaten gerastert wurde, wird Pixelprozessorlogik (z.B. Pixelshader-Logik, Fragmentshader-Logik usw.) innerhalb des Shader-Prozessors 502 aufgerufen, um ferner Ausgabeinformationen zu berechnen und Ergebnisse zu veranlassen, zu Ausgabeoberflächen geschrieben zu werden (z.B. Farbpuffer, Tiefenpuffer, Schablonenpuffer usw.). In manchen Ausführungsformen berechnet ein Pixelshader oder Fragmentshader die Werte der unterschiedlichen Scheitelpunktattribute, die über das gerasterte Objekt zu interpolieren sind. In manchen Ausführungsformen führt Pixelprozessorlogik innerhalb des Shaderprozessors 502 dann ein Anwendungsprogrammierschnittstellen- (API, Application Programming Interface) - geliefertes Pixel- oder Fragmentshader-Programm aus. Um das Shader-Programm auszuführen, lastet der Shader-Prozessor 502 Threads zu einer Ausführungseinheit (z.B. 508A) über Thread-Dispatcher 504 ein. In manchen Ausführungsformen verwendet Shader-Prozessor 502 Texturabtastungslogik in dem Abtaster 510, um auf Texturdaten in Texturabbildungen zuzugreifen, die in Speicher gespeichert sind. Arithmetische Betriebe an den Texturdaten und den Eingabegeometriedaten errechnen Pixelfarbdaten für jedes geometrische Fragment oder verwerfen ein oder mehrere Pixel von weiterer Verarbeitung.
In manchen Ausführungsformen stellt der Datenanschluss 514 einen Speicherzugriffmechanismus für die Thread-Ausführungslogik 500 bereit, um verarbeitete Daten an Speicher für weitere Verarbeitung auf einer Grafikprozessorausgabepipeline auszugeben. In manchen Ausführungsformen weist der Datenanschluss 514 einen oder mehrere Cachespeicher (z.B. Datencache 512) auf oder koppelt sich damit, um Daten für Speicherzugriff über den Datenanschluss zwischenzuspeichern.
In einer Ausführungsform kann die Ausführungslogik 500 auch einen Raytracer 505 aufweisen, der Raytracing-Beschleunigungsfunktionalität bereitstellen kann. Der Raytracer 505 kann einen Raytracing-Anweisungssatz unterstützen, der Anweisungen/Funktionen für Strahlerzeugung aufweist. Der Raytracing-Anweisungssatz kann ähnlich dem Raytracing-Anweisungssatz sein, der von den Raytracing-Kernen 245 in 2C unterstützt wird, oder sich davon unterscheiden.
5B veranschaulicht beispielhafte interne Details einer Ausführungseinheit 508 gemäß manchen Ausführungsformen. Eine Grafikausführungseinheit 508 kann eine Anweisungsabrufeinheit 537, ein allgemeines Registerdateiarray (GRF, General Register File array) 524, ein architektonisches Registerdateiarray (ARF, Architectural Register File array) 526, einen Thread-Vermittler 522, eine Sendeeinheit 530, eine Verzweigungseinheit 532, einen Satz von SIMD-Gleitkommaeinheiten (FPUs) 534 und in einer Ausführungsform einen Satz von dedizierten Ganzzahl-SIMD-ALUs 535 aufweisen. Das GRF 524 und ARF 526 weisen den Satz von allgemeinen Registerdateien und Architekturregisterdateien auf, die mit jedem gleichzeitigen Hardwarethread verknüpft sind, der in der Grafikausführungseinheit 508 aktiv sein kann. In einer Ausführungsform wird ein architektonischer Zustand pro Thread in dem ARF 526 beibehalten, während Daten, die während Thread-Ausführung verwendet werden, in dem GRF 524 gespeichert werden. Der Ausführungszustand jedes Threads, aufweisend die Anweisungszeiger für jeden Thread, kann in Thread-spezifischen Registern in dem ARF 526 gehalten werden.
In einer Ausführungsform weist die Grafikausführungseinheit 508 eine Architektur auf, die eine Kombination von gleichzeitigem Multithreading (SMT, Simultaneous Multi-Threading) und feinabgestuftem vernetzten Multithreading (IMT, Interleaved Multi-Threading) ist. Die Architektur weist eine modulare Konfiguration auf, die zum Zeitpunkt von Design basierend auf einer Zielzahl gleichzeitiger Threads und einer Zahl von Registern pro Ausführungseinheit feinabgestuft werden kann, wo Ausführungseinheitsressourcen über Logik geteilt sin, die verwendet wird, mehrere gleichzeitige Threads auszuführen. Die Zahl von logischen Threads, die von der Grafikausführungseinheit 508 ausgeführt werden können, ist nicht auf die Zahl von Hardwarethreads begrenzt und mehrere logische Threads können jedem Hardwarethread zugewiesen werden.
In einer Ausführungsform kann die Grafikausführungseinheit 508 mehrere Anweisungen gemeinsam ausstellen, die jeweils verschiedene Anweisungen sein können. Der Thread-Vermittler 522 des Grafikausführungseinheitsthreads 508 kann die Anweisungen zu einer der Sendeeinheit 530, Verzweigungseinheit 532 oder SIMD-FPU(s) 524 zur Ausführung einlasten. Jeder Ausführungsthread kann auf Allzweckregister innerhalb des GRF 524 zugreifen 128, wo jedes Register 32 Bytes speichern kann, die als ein SIMD 8-Elementvektor von 32-Bit Datenelementen zugänglich sind. In einer Ausführungsform weist jeder Ausführungseinheitsthread Zugriff auf 4 Kbytes innerhalb des GRF 524 auf, obwohl Ausführungsformen dahin nicht begrenzt sind und mehr oder weniger Registerressourcen in anderen Ausführungsformen bereitgestellt sein können. In einer Ausführungsform ist die Grafikausführungseinheit 508 in sieben Hardwarethreads partitioniert, die unabhängig Rechenbetriebe durchführen können, obwohl die Zahl von Threads pro Ausführungseinheit auch gemäß Ausführungsformen variieren kann. Zum Beispiel sind in einer Ausführungsform bis zu 16 Hardwarethreads unterstützt. In einer Ausführungsform, in der sieben Threads auf 4 Kbytes zugreifen können, kann das GRF 524 insgesamt 28 Kbytes speichern. Wo 16 Threads auf 4 Kbytes zugreifen können, kann das GRF 524 insgesamt 64 Kbytes speichern. Flexible Adressmodi können Registern gestatten, gemeinsam adressiert zu werden, um effektiv breitere Register zu bilden oder überstiegene Blockdatenstrukturen darzustellen.
In einer Ausführungsform sind Speicherbetriebe, Abtasterbetriebe und andere Systemkommunikationen mit längerer Latenz über „Send“-Anweisungen eingelastet, die von der Nachrichtenweitergabesendeeinheit 530 ausgeführt werden. In einer Ausführungsform sind Verzweigungsanweisungen zu einer dedizierten Verzweigungseinheit 532 eingelastet, um SIMD-Divergenz und eventuelle Konvergenz zu erleichtern.
In einer Ausführungsform weist die Grafikausführungseinheit 508 eine oder mehrere SIMD-Gleitkommaeinheiten (FPU(s)) 534 auf, um Gleitkommabetriebe durchzuführen. In einer Ausführungsform unterstützt (unterstützen) die FPU(s) 534 auch Ganzzahlberechnung. In einer Ausführungsform kann (können) die FPU(s) 534 bis zu einer Zahl vonM32-Bit Gleitkomma- (oder Ganzzahl-) -betrieben SIMD ausführen oder bis zu 2M 16-Bit Ganzzahl- oder 16-Bit Gleitkommabetrieben SIMD ausführen. In einer Ausführungsform stellt mindestens eine der FPU(s) erweiterte mathematische Kapazität bereit, um transzendentale mathematische Funktionen mit Hochdurchsatz und 54-Bit Gleitkomma mit Doppelpräzision zu unterstützen. In manchen Ausführungsformen ist auch ein Satz von 8-Bit Ganzzahl-SIMD-ALUs 535 vorhanden und kann spezifisch optimiert werden, um Betriebe durchzuführen, die mit Maschinenlernberechnungen verknüpft sind.
In einer Ausführungsform können Arrays mehrerer Instanzen der Grafikausführungseinheit 508 in einer Grafikteilkerngruppierung (z.B. ein Teilprozessorelement) instanziiert sein. Zur Skalierbarkeit können Produktarchitekten die exakte Zahl von Ausführungseinheiten pro Teilkerngruppierung auswählen. In einer Ausführungsform kann die Ausführungseinheit 508 Anweisungen über mehrere Ausführungskanäle ausführen. In einer weiteren Ausführungsform ist jeder Thread, der auf der Grafikausführungseinheit 508 ausgeführt wird, auf einem verschiedenen Kanal ausgeführt.
6 veranschaulicht eine zusätzliche Ausführungseinheit 600 gemäß einer Ausführungsform. Die Ausführungseinheit 600 kann eine rechenoptimierte Ausführungseinheit zur Verwendung in, zum Beispiel, einer Rechenengine-Kachel 340A-340D wie in 3C sein, ist aber nicht dahin begrenzt. Varianten der Ausführungseinheit 600 können auch in einer Grafikengine-Kachel 310A-310D wie in 3B verwendet werden. In einer Ausführungsform weist die Ausführungseinheit 600 eine Thread-Steuerungseinheit 601, eine Thread-Zustandseinheit 602, eine Anweisungsabruf-/-vorababrufeinheit 603 und eine Anweisungsdecodierungseinheit 604 auf. Die Ausführungseinheit 600 weist zusätzlich eine Registerdatei 606 auf, die Register speichert, die Hardwarethreads innerhalb der Ausführungseinheit zugewiesen werden können. Die Ausführungseinheit 600 weist zusätzlich eine Sendeeinheit 607 und eine Verzweigungseinheit 608 auf. In einer Ausführungsform können die Sendeeinheit 607 und Verzweigungseinheit 608 ähnlich der Sendeeinheit 530 und einer Verzweigungseinheit 532 der Grafikausführungseinheit 508 von 5B arbeiten.
Die Ausführungseinheit 600 weist auch eine Recheneinheit 610 auf, die mehrere verschiedene Typen von funktionalen Einheiten aufweist. In einer Ausführungsform weist die Recheneinheit 610 eine ALU-Einheit 611 auf, die ein Array arithmetischer Logikeinheiten aufweist. Die ALU-Einheit 611 kann konfiguriert sein, 64-Bit, 32-Bit und 16-Bit Ganzzahl- und Gleitkommabetriebe durchzuführen. Ganzzahl- und Gleitkommabetriebe können gleichzeitig durchgeführt werden. Die Recheneinheit 610 kann auch ein systolisches Array 612 und eine Mathematikeinheit 613 aufweisen. Das systolische Array 612 weist ein W breites und D tiefes Netzwerk von Datenverarbeitungseinheiten auf, die verwendet werden können, um Vektor- oder andere datenparallele Betriebe auf eine systolische Weise durchzuführen. In einer Ausführungsform kann das systolische Array 612 konfiguriert sein, Matrixbetriebe durchzuführen, wie Matrixskalarproduktbetriebe. In einer Ausführungsform unterstützt das systolische Array 612 16-Bit Gleitkommabetriebe, wie auch 8-Bit und 4-Bit Ganzzahlbetriebe. In einer Ausführungsform kann das systolische Array 612 konfiguriert sein, Maschinenlernbetriebe zu beschleunigen. In solchen Ausführungsformen kann das systolische Array 612 mit Unterstützung für das bfloat 16-Bit Gleitkommaformat konfiguriert sein. In einer Ausführungsform kann eine Mathematikeinheit 613 aufgewiesen sein, um einen bestimmten Teilsatz mathematischer Betriebe auf eine effiziente und leistungssparsamere Weise als die ALU-Einheit 611 durchzuführen. Die Mathematikeinheit 613 kann eine Variante von Mathematiklogik aufweisen, die in geteilter Funktionslogik einer Grafikverarbeitungsengine gefunden werden kann, die von anderen Ausführungsformen bereitgestellt ist (z.B. Mathematiklogik 422 der geteilten Funktionslogik 420 von 4). In einer Ausführungsform kann die Mathematikeinheit 613 konfiguriert sein, 32-Bit und 64-Bit Gleitkommabetriebe durchzuführen.
Die Thread-Steuerungseinheit 601 weist Logik auf, um die Ausführung von Threads innerhalb der Ausführungseinheit zu steuern. Die Thread-Steuerungseinheit 601 kann Threadvermittlungslogik aufweisen, um Ausführung von Threads innerhalb der Ausführungseinheit 600 zu beginnen, zu stoppen und zu umgehen. Die Thread-Zustandseinheit 602 kann verwendet werden, um Thread-Zustand für Threads zu speichern, die zugewiesen sind, auf der Ausführungseinheit 600 ausgeführt zu werden. Den Thread-Zustand innerhalb der Ausführungseinheit 600 zu speichern, ermöglicht die rasche Umgehung von Threads, wenn diese Threads blockiert oder inaktiv werden. Die Anweisungsabruf-/-vorababrufeinheit 603 kann Anweisungen von einem Anweisungscache von Ausführungslogik eines höheren Levels (z.B. Anweisungscache 506 wie in 5A) abrufen. Die Anweisungsabruf-/-vorababrufeinheit 603 kann auch Vorababrufanfragen für Anweisungen, die in den Anweisungscache zu laden sind, basierend auf einer Analyse aktuell ausgeführter Threads ausstellen. Die Anweisungsdecodierungseinheit 604 kann verwendet werden, um Anweisungen zu decodieren, die von den Recheneinheiten auszuführen sind. In einer ausführungsform kann die Anweisungsdecodierungseinheit 604 als ein sekundärer Decoder verwendet werden, um komplexe Anweisungen in einzelne Mikrobetriebe zu decodieren.
Die Ausführungseinheit 600 weist zusätzlich eine Registerdatei 606 auf, die von Hardwarethreads verwendet werden kann, die auf der Ausführungseinheit 600 ausgeführt werden. Register in der Registerdatei 606 können über die Logik geteilt werden, die verwendet wird, um mehrere gleichzeitige Threads innerhalb der Recheneinheit 610 der Ausführungseinheit 600 auszuführen. Die Zahl logischer Threads, die von der Grafikausführungseinheit 600 ausgeführt werden können, ist nicht auf die Zahl von Hardwarethreads begrenzt, und mehrere logische Threads können jedem Hardwarethread zu gewiesen werden. Die Größe der Registerdatei 606 kann über Ausführungsformen basierend auf der Zahl von unterstützen Hardwarethreads variieren. In einer Ausführungsform kann Registerumbenennung verwendet werden, um Register dynamisch zu Hardwarethreads zuzuweisen.
7 ist ein Blockdiagramm, das ein Grafikprozessoranweisungsformat 700 gemäß manchen Ausführungsformen veranschaulicht. In einer oder mehreren Ausführungsformen unterstützen die Grafikprozessorausführungseinheiten einen Anweisungssatz, der Anweisungen in mehreren Formaten aufweist. Die durchgängig linierten Boxen veranschaulichen die Komponenten, die im Allgemeinen in einer Ausführungseinheitsanweisung aufgewiesen sind, während die strichlierten Linien Komponenten aufweisen, die optional sind oder die nur in einem Teilsatz der Anweisungen aufgewiesen sind. In manchen Ausführungsformen ist beschriebenes und veranschaulichtes Anweisungsformat 700 Makroanweisungen, indem sie Anweisungen sind, die von der Ausführungseinheit geliefert werden, entgegen Mikrobetrieben, die von Anweisungsdecodierung resultieren, sobald die Anweisung verarbeitet ist.
In manchen Ausführungsformen unterstützen die Grafikprozessorausführungseinheiten nativ Anweisungen in einem 128-Bit Anweisungsformat 710. Ein 64-Bit komprimiertes Anweisungsformat 730 ist für manche Anweisungen basierend auf der ausgewählten Anweisung, den Anweisungsoptionen und der Zahl von Operanden verfügbar. Das native 128-Bit Anweisungsformat 710 stellt Zugriff auf alle Anweisungsoptionen bereit, während manche Optionen und Betriebe in dem 64-Bit Format 730 eingeschränkt sind. Die nativen Anweisungen, die in dem 64-Bit Format 730 verfügbar sind, variieren je Ausführungsform. In manchen Ausführungsformen ist die Anweisung zum Teil unter Verwendung eines Satzes von Indexwerten in einem Indexfeld 713 komprimiert. Die Ausführungseinheitshardware bezieht sich auf einen Satz von Komprimierungstabellen, basierend auf den Indexwerten, und verwendet die Komprimierungstabellenausgaben, um eine native Anweisung in dem 128-Bit Anweisungsformat 710 zu rekonstruieren. Andere Größen und Formate von Anweisung können verwendet werden.
Für jedes Format definiert Anweisungs-Opcode 712 den Betrieb, den die Ausführungseinheit durchführen wird. Die Ausführungseinheiten führen jede Anweisung parallel über mehrere Datenelemente jedes Operanden aus. Zum Beispiel führt die Ausführungseinheit in Antwort auf eine Zugabeanweisung einen gleichzeitigen Zugabebetrieb über jeden Farbkanal durch, der ein Texturelement oder Bildelement darstellt. Standardmäßig führt die Ausführungseinheit jede Anweisung über alle Datenkanäle der Operanden durch. In manchen Ausführungsformen ermöglicht Anweisungssteuerungsfeld 714 Steuerung über gewisse Ausführungsoptionen, wie Kanalauswahl (z.B. Vorhersage) und Datenkanalreihenfolge (z.B. Durchmischung). Für Anweisungen in dem 128-Bit Anweisungsformat 710 begrenzt ein Exec-Größenfeld 716 die Zahl von Datenkanälen, die parallel ausgeführt werden In manchen Ausführungsformen ist Exec-Größenfeld 716 nicht zur Verwendung in dem 64-Bit kompakten Anweisungsformat 730 verfügbar.
Manche Ausführungseinheitsanweisungen weisen bis zu drei Operanden auf, aufweisend zwei Quelloperanden, src0 720, src1 722 und ein Ziel 718. In manchen Ausführungsformen unterstützen die Ausführungseinheiten Doppelzielanweisungen, wo eines der Ziele inbegriffen ist. Datenmanipulationsanweisungen können einen dritten Quelloperanden (z.B. SRC2 724) aufweisen, wo der Anweisungs-Opcode 712 die Zahl von Quelloperanden ermittelt. Ein letzter Quelloperand einer Anweisung kann ein Zwischenwert (z.B. hartcodiert) sein, der mit der Anweisung weitergegeben wird.
In manchen Ausführungsformen weist das 128-Bit Anweisungsformat 710 ein Zugriffs-/Adressmodusfeld 726 auf, das zum Beispiel bestimmt, ob direkter Registeradressierungsmodus oder indirekter Registeradressierungsmodus verwendet wird. Wenn direkter Registeradressierungsmodus verwendet wird, wird die Registeradresse eines oder mehrerer Operanden direkt durch Bits in der Anweisung bereitgestellt.
In manchen Ausführungsformen weist das 128-Bit Anweisungsformat 710 ein Zugriffs-/Adressmodusfeld 726 auf, das einen Adressmodus und/oder einen Zugriffsmodus für die Anweisung bestimmt. In einer Ausführungsform wird der Zugriffsmodus verwendet, um eine Datenzugriffsausrichtung für die Anweisung zu definieren. Manche Ausführungsformen unterstützen Zugriffsmodi, die einen 16-Byte ausgerichteten Zugriffsmodus und einen 1-Byte ausgerichteten Zugriffsmodus aufweisen, wo die Byte-Ausrichtung des Zugriffsmodus die Zugriffsausrichtung der Anweisungsoperanden ermittelt. Zum Beispiel, wenn in einem ersten Modus, kann die Anweisung Byte-ausgerichtete Adressierung für Quell- und Zieloperanden verwenden, und wenn in einem zweiten Modus, kann die Anweisung 16-Byte-ausgerichtete Adressierung für alle Quell- und Zieloperanden verwenden.
In einer Ausführungsform ermittelt der Adressmodusabschnitt des Zugriffs-/Adressmodusfelds 726, ob die Anweisung direkte oder indirekte Adressierung verwenden wird. Wenn direkter Registeradressmodus verwendet wird, stellen Bits in der Anweisung direkt die Registeradresse eines oder mehrerer Operanden bereit. Wenn indirekter Registeradressiermodus verwendet wird, kann die Registeradresse eines oder mehrerer Operanden basierend auf dem Adressregisterwert und einem Adresszwischenfeld in der Anweisung berechnet werden.
In manchen Ausführungsformen sind Anweisungen basierend auf Opcode 712 Bitfeldern gruppiert, um Opcode-Decodierung 740 zu vereinfachen. Für einen 8-Bit Opcode erlauben Bits 4, 5 und 6 der Ausführungseinheit, den Typ von Opcode zu ermitteln. Die präzise gezeigte Opcode-Gruppierung ist bloß ein Beispiel. In manchen Ausführungsformen weist eine Bewegungs- und Logik-Opcode-Gruppe 742 Datenbewegungs- und Logikanweisungen auf (z.B. move (mov), compare (cmp)). In manchen Ausführungsformen teilt sich Bewegungs- und Logikgruppe 742 die fünf signifikantesten Bits (MSB, Most Significant Bits), wo move (mov) Anweisungen in der Form von 0000xxxxb sind und Logikanweisungen in der Form von 0001xxxxb sind. Eine Ablaufsteuerungsanweisungsgruppe 744 (z.B. call, jump (jmp)) weist Anweisungen in der Form von 0010xxxxb (z.B. 0x20) auf. Eine diverse Anweisungsgruppe 746 weist einen Mix von Anweisungen auf, aufweisend Synchronisationsanweisungen (z.B. wait, send) in der Form von OOllxxxxb (z.B. 0x30). Eine parallele Mathematikanweisungsgruppe 748 weist komponentenweise arithmetische Anweisungen (z.B. add, multiply (mul)) in der Form von 0100xxxxb (z.B. 0x40) auf. Die parallele Mathematikgruppe 748 führt die arithmetischen betriebe parallel über Datenkanäle durch. Die Vektormathematikgruppe 750 weist Arithmetikanweisungen (z.B. dp4) in der Form von 0101xxxxb (z.B. 0x50) auf. Die Vektormathematikgruppe führt Arithmetik, wie Skalarproduktberechnungen, an Vektoroperanden durch. Der veranschaulichte Opcode-Decodierung 740 kann in einer Ausführungsform verwendet werden, um zu ermitteln, welcher abschnitt einer Ausführungseinheit gesendet wird, um eine decodierte Anweisung auszuführen. Zum Beispiel können manche Anweisungen als systolische Anweisungen gestaltet sein, die von einem systolischen Array durchgeführt werden. Andere Anweisungen, wie Raytracing-Anweisungen (nicht gezeigt) können zu einem Raytracing-Kern oder einer Raytracing-Logik innerhalb eines Prozessorelements oder einer Partition von Ausführungslogik geleitet werden.
Grafikpipeline
8 ist ein Blockdiagramm einer anderen Ausführungsform eines Grafikprozessors 800. Elemente von 8, die dieselben Referenznummern (oder Namen) wie die Elemente einer beliebigen anderen Figur hierin aufweisen, können auf eine ähnliche Weise wie hier an anderer Stelle beschrieben arbeiten oder funktionieren, sind aber nicht darauf begrenzt.
In manchen Ausführungsformen weist Grafikprozessor 800 eine Geometriepipeline 820, eine Medienpipeline 830, eine Anzeige-Engine 840, Thread-Ausführungslogik 850 und eine Renderausgabepipeline 870 auf. In manchen Ausführungsformen ist Grafikprozessor 800 ein Grafikprozessor innerhalb eines Multikernverarbeitungssystems, das einen oder mehrere Allzweckverarbeitungskerne aufweist. Der Grafikprozessor wird von Registerschrieben zu einem oder mehreren Steuerungsregistern (nicht gezeigt) oder über Befehle, die an Grafikprozessor 800 über eine Ringzwischenverbindung 802 ausgestellt werden, gesteuert. In manchen Ausführungsformen koppelt Ringzwischenverbindung 802 Grafikprozessor 800 mit anderen Verarbeitungskomponenten, wie anderen Grafikprozessoren oder Allzweckprozessoren. Befehle von Ringzwischenverbindung 802 sind durch einen Befehlsstreamer 803 interpretiert, der Anweisungen an individuelle Komponenten der Geometriepipeline 820 oder die Medienpipeline 830 liefert.
In manchen Ausführungsformen lenkt Befehlsstreamer 803 den Betrieb eines Scheitelpunktabrufers 805, der Scheitelpunktdaten von Speicher liest und führt Scheitelpunktverarbeitungsbefehle aus, die von Befehlsstreamer 803 bereitgestellt sind. In manchen Ausführungsformen stellt Scheitelpunktabrufer 805 Scheitelpunktdaten an einen Scheitelpunktshader 807 bereit, der Koordinatenraumtransformation und Belichtungsbetriebe an jedem Scheitelpunkt durchführt. In manchen Ausführungsformen führen Scheitelpunktabrufer 805 und Scheitelpunktshader 807 Scheitelpunktverarbeitungsanweisungen aus, indem Ausführungsthreads zu Ausführungseinheiten 852A-852B über einen Thread-Dispatcher 831 eingelastet werden.
In manchen Ausführungsformen sind Ausführungseinheiten 852A-852B ein Array von Vektorprozessoren, die einen Anweisungssatz zum Durchführen von Grafik- und Medienbetrieben aufweisen. In manchen Ausführungsformen weisen Ausführungseinheiten 852A-852B einen angebrachten L1-Cache 851 auf, der für jede Array spezifisch ist oder zwischen den Arrays geteilt wird. Der Cache kann als ein Datencache, ein Anweisungscache oder ein einzelner Cache konfiguriert sein, der partitioniert ist, Daten und Anweisungen in verschiedenen Partitionen zu enthalten.
In manchen Ausführungsformen weist Geometriepipeline 820 Tessellationskomponenten auf, um hardwarebeschleunigte Tessellation von 3D-Objekten durchzuführen. In manchen Ausführungsformen konfiguriert ein programmierbarer Hull-Shader 811 die Tessellationsbetriebe. Ein programmierbarer Domänenshader 817 stellt Backend-Evaluierung von Tessellationsausgabe bereit. Ein Tessellator 813 arbeitet bei der Richtung von Hull-Shader 811 und enthält Sonderzwecklogik, um einen Satz von detaillierten geometrischen Objekten basierend auf einem groben geometrischen Modell bereitzustellen, das als Eingabe zu Geometriepipeline 820 bereitgestellt ist. In manchen Ausführungsformen, falls Tessellation nicht verwendet wird, können Tessellationskomponenten (z.B. Hull-Shader 811, Tessellator 813 und Domänenshader 817) umgangen werden.
In manchen Ausführungsformen können vollständige geometrische Objekte von einem Geometrieshader 819 über einen oder mehrere Threads verarbeitet werden, die zu Ausführungseinheiten 852A-852B eingelastet sind, oder können direkt zu dem Begrenzer 829 fortfahren. In manchen Ausführungsformen arbeitet der Geometrieshader auf gesamten geometrischen Objekten als auf Scheitelpunkten oder vereinzelten Scheitelpunkten, wie in vorherigen Stufen der Grafikpipeline. Falls die Tessellation deaktiviert ist, empfängt der Geometrieshader 819 Eingabe von dem Scheitelpunktshader 807. In manchen Ausführungsformen ist Geometrieshader 819 durch ein Geometrieshader-Programm programmierbar, um Geometrietessellation durchzuführen, falls die Tessellationseinheiten deaktiviert sind.
Vor Rasterisierung verarbeitet ein Begrenzer 829 Scheitelpunktdaten. Der Begrenzer 829 kann ein fixierter Funktionsbegrenzer oder ein programmierbarer Begrenzer sein, der Begrenzungs- und Geometrieshader-Funktionen aufweist. In manchen Ausführungsformen lastet eine Rasterisierer- und Tiefentestkomponente 873 in der Renderausgabepipeline 870 Pixelshader ein, um die geometrischen Objekte in Pro-Pixel-Darstellungen umzuwandeln. In manchen Ausführungsformen ist Pixelshader-Logik in Thread-Ausführungslogik 850 aufgewiesen. In manchen Ausführungsformen kann eine Anwendung die Rasterisierer- und Tiefentestkomponente 873 umgehen und auf ungerasterte Scheitelpunktdaten über eine Stream-Ausgangseinheit 823 zugreifen.
Der Grafikprozessor 800 weist einen Zwischenverbindungsbus, ein Zwischenverbindungsfabric oder einen anderen Zwischenverbindungsmechanismus auf, der Daten- und Nachrichtendurchleitung unter den Hauptkomponenten des Prozessors erlaubt. In manchen Ausführungsformen sind Ausführungseinheiten 852A-852B und verknüpfte Logikeinheiten (z.B. L1-Cache 851, Abtaster 854, Texturcache 858 usw.) über einen Datenanschluss 856 zwischenverbunden, um Speicherzugriff durchzuführen und mit Renderausgabepipeline-Komponenten des Prozessors zu kommunizieren. In manchen Ausführungsformen weisen Abtaster 854, Caches 851, 858 und Ausführungseinheiten 852A-852B jeweils separate Speicherzugriffspfade auf. In einer Ausführungsform kann der Texturcache 858 auch als ein Abtastercache konfiguriert sein.
In manchen Ausführungsformen enthält Renderausgabepipeline 870 eine Rasterisierer- und Tiefentestkomponente 873, die scheitelpunktbasierte Objekte in eine verknüpfte pixelbasierte Darstellung umwandelt. In manchen Ausführungsformen weist die Rasterisiererlogik eine Fensterungs-/Maskierungseinheit auf, um fixierte Funktionsdreieck- und Linienrasterisierung durchzuführen. Ein verknüpfter Rendercache 878 und Tiefencache 879 sind in manchen Ausführungsformen auch verfügbar. Eine Pixelbetriebskomponente 877 führt pixelbasierte Betriebe an den Daten aus, obwohl in manchen Instanzen Pixelbetriebe, die mit 2D-Betrieben (z.B. Bildblockierungsbildtransfers mit Vermischung) verknüpft sind, von der 2D-Engine 841 durchgeführt werden oder zum Anzeigezeitpunkt von der Anzeigesteuerung 843 unter Verwendung von Überlagerungsanzeigeebenen ersetzt werden. In manchen Ausführungsformen ist ein geteilter L3-Cache 875 für alle Grafikkomponenten verfügbar, was das Teilen von Daten ohne die Verwendung von Hauptsystemspeicher erlaubt.
In manchen Ausführungsformen weist Grafikprozessormedienpipeline 830 eine Medienengine 837 und ein Video-Frontend 834 auf. In manchen Ausführungsformen empfängt Video-Frontend 834 Pipelinebefehle von dem Befehlsstreamer 803. In manchen Ausführungsformen weist Medienpipeline 830 einen separaten Befehlsstreamer auf. In manchen Ausführungsformen verarbeitet Video-Frontend 834 Medienbefehle vor Senden des Befehls an die Medienengine 837. In manchen Ausführungsformen weist Medienengine 837 Thread-Startfunktionalität, um Threads zu starten, um sie zu Thread-Ausführungslogik 850 über Thread-Dispatcher 831 einzulasten.
In manchen Ausführungsformen weist Grafikprozessor 800 eine Anzeige-Engine 840 auf. In manchen Ausführungsformen ist Anzeige-Engine 840 außerhalb von Prozessor 800 und koppelt sich mit dem Grafikprozessor über die Ringzwischenverbindung 802 oder einen anderen Zwischenverbindungsbus oder ein Fabric. In manchen Ausführungsformen weist Anzeige-Engine 840 eine 2D-Engine 841 und eine Anzeigesteuerung 843 auf. In manchen Ausführungsformen enthält Anzeige-Engine 840 Sonderzwecklogik, die im Stande ist, unabhängig von der 3D-Pipeline zu arbeiten. In manchen Ausführungsformen koppelt sich Anzeigesteuerung 843 mit einer Anzeigevorrichtung (nicht gezeigt), die eine systemintegrierte Anzeigevorrichtung sein kann, wie in einem Laptopcomputer oder einer externen Anzeigevorrichtung, die über einen Anzeigevorrichtungsstecker angebracht ist.
In manchen Ausführungsformen sind die Geometriepipeline 820 und Medienpipeline 830 konfigurierbar, Betriebe basierend auf mehreren Grafik- und Medienprogrammierschnittstellen durchzuführen und sind für keine Anwendungsprogrammierschnittstelle (API) spezifisch. In manchen Ausführungsformen übersetzt Treibersoftware für den Grafikprozessor API-Anrufe, die spezifisch für eine bestimmte Grafik- oder Medienbibliothek sind, in Befehle, die von dem Grafikprozessor verarbeitet werden können. In manchen Ausführungsformen ist Unterstützung für die Open Graphics Library (OpenGL), Open Computing Language (OpenCL) und/oder Vulkan Grafik- und Rechen-API, alle von der Khronos Group, bereitgestellt. In manchen Ausführungsformen kann auch Unterstützung für die Direct3D Bibliothek von der Microsoft Corporation bereitgestellt sein. In manchen Ausführungsformen kann eine Kombination dieser Bibliotheken unterstützt werden. Unterstützung kann auch für die Open Source Computer Vision Bibliothek (OpenCV) bereitgestellt sein. Eine zukünftige API mit einer kompatiblen 3D-Pipeline würde auch unterstützt werden, falls eine Abbildung von der Pipeline der zukünftigen API zu der Pipeline des Grafikprozessors gemacht werden kann.
Grafikpipelineprogrammierung
9A ist ein Blockdiagramm, das ein Grafikprozessorbefehlsformat 900 gemäß manchen Ausführungsformen veranschaulicht. 9B ist ein Blockdiagramm, das eine Grafikprozessorbefehlssequenz 910 gemäß einer Ausführungsform veranschaulicht. Die durchgängig linierten Boxen in 9A veranschaulichen die Komponenten, die im Allgemeinen in einem Grafikbefehl aufgewiesen sind, während die strichlierten Linien Komponenten aufweisen, die optional sind oder die nur in einem Teilsatz der Grafikbefehle aufgewiesen sind. Das beispielhafte Grafikprozessorbefehlsformat 900 von 9A weist Datenfelder auf, um einen Client 902, einen Befehlsbetriebscode (Opcode) 904 und Daten 906 für den Befehl zu identifizieren. Ein Teil-Opcode 905 und eine Befehlsgröße 908 sind auch in manchen Befehlen aufgewiesen.
In manchen Ausführungsformen bestimmt Client 902 die Client-Einheit der Grafikvorrichtung, die die Befehlsdaten verarbeitet. In manchen Ausführungsformen untersucht ein Grafikprozessorbefehlszerteiler das Client-Feld jedes Befehls, um die weitere Verarbeitung des Befehls zu bedingen und die Befehlsdaten an die geeignete Client-Einheit zu leiten. In manchen Ausführungsformen weisen die Grafikprozessor-Client-Einheiten eine Speicherschnittstelleneinheit, eine Render-Einheit, eine 2D-Einheit, eine 3D-Einheit und eine Medieneinheit auf. Jede Client-Einheit weist eine entsprechende Verarbeitungspipeline auf, die die Befehle verarbeitet. Sobald der Befehl von der Client-Einheit empfangen ist, liest die Client-Einheit den Opcode 904 und, falls vorhanden, Teil-Opcode 905, um den durchzuführenden Betrieb zu ermitteln. Die Client-Einheit führt den Befehl unter Verwendung von Informationen in Datenfeld 906 durch. Für manche Befehle wird erwartet, dass eine ausdrückliche Befehlsgröße 908 die Größe des Befehls bestimmt. In manchen Ausführungsformen ermittelt der Befehlszerteiler automatisch die Größe von mindestens manchen der Befehle, basierend auf dem Befehls-Opcode. In manchen Ausführungsformen sind Befehle über Vielfache eines Doppelworts ausgerichtet. Andere Befehlsformate können verwendet werden.
Das Ablaufdiagramm in 9B veranschaulicht eine beispielhafte Grafikprozessorbefehlssequenz 910. In manchen Ausführungsformen verwendet Software oder Firmware eines Datenverarbeitungssystems, das eine Ausführungsform eines Grafikprozessors bietet, eine Version der gezeigten Befehlssequenz, um einen Satz von Grafikbetrieben einzurichten, auszuführen und zu beenden. Eine Probenbefehlssequenz ist zu Zwecken eines Beispiels gezeigt und beschrieben, aber Ausführungsformen sind nicht auf diese bestimmten Befehle oder auf diese Befehlssequenz begrenzt. Außerdem können die Befehle als Bündel von Befehlen in einer Befehlssequenz derart ausgestellt werden, dass der Grafikprozessor die Sequenz von Befehlen in mindestens teilweiser Gleichzeitigkeit verarbeiten wird.
In manchen Ausführungsformen kann die Grafikprozessorbefehlssequenz 910 mit einem Pipeline-Leerungsbefehl 912 beginnen, um eine beliebige aktive Grafikpipeline zu veranlassen, die aktuell ausständigen Befehle für die Pipeline abzuschließen. In manchen Ausführungsformen arbeiten die 3D-Pipeline 922 und die Medienpipeline 924 nicht zugleich. Die Pipelineleerung wird durchgeführt, um die aktive Grafikpipeline zu aktivieren, um beliebige ausstehende Befehle abzuschließen. In Antwort auf eine Pipeline-Leerung wird der Befehlszerteiler für den Grafikprozessor Befehlsverarbeitung pausieren, bis die aktiven Zeichen-Engines ausstehende Betriebe abschließen und die relevanten Lesecaches für ungültig erklärt sind. Optional können alle Daten in dem Rendercache, die als „schmutzig“ markiert sind, zu Speicher geleert werden. In manchen Ausführungsformen kann Pipeline-Leerungsbefehl 912 für Pipeline-Synchronisation oder vor Platzieren des Grafikprozessors in einen Niederleistungszustand verwendet werden.
In manchen Ausführungsformen wird ein Pipeline-Auswahlbefehl 913 verwendet, wenn eine Befehlssequenz erfordert, dass der Grafikprozessor ausdrücklich zwischen Pipelines wechselt. In manchen Ausführungsformen wird ein Pipeline-Auswahlbefehl 913 nur einmal innerhalb eines Ausführungskontextes benötigt, bevor Pipelinebefehle ausgestellt werden, außer der Kontext ist, Befehle für beide Pipelines auszustellen. In manchen Ausführungsformen wird ein Pipeline-Leerungsbefehl 912 unmittelbar vor einem Pipelinewechsel über den Pipelineauswahlbefehl 913 benötigt.
In manchen Ausführungsformen konfiguriert ein Pipelinesteuerungsbefehl 914 eine Grafikpipeline für Betrieb und wird verwendet, um die 3D-Pipeline 922 und die Medienpipeline 924 zu programmieren. In manchen Ausführungsformen konfiguriert Pipelinesteuerungsbefehl 914 den Pipelinezustand für die aktive Pipeline. In einer Ausführungsform wird der Pipelinesteuerungsbefehl 914 für Pipelinesynchronisation und zum Löschen von Daten aus einem oder mehreren Cachespeichern innerhalb der aktiven Pipeline verwendet, bevor ein Befehlsbündel verarbeitet wird.
In manchen Ausführungsformen werden Rückführungspufferzustandsbefehle 916 verwendet, um einen Satz von Rückführungspuffern für die jeweiligen Pipelines zu konfigurieren, um Daten zu schreiben. Manche Pipelinebetriebe benötigen die Zuweisung, Auswahl oder Konfiguration eines oder mehrerer Rückführungspuffer, in die die Betriebe Zwischendaten während Verarbeitung schreiben. In manchen Ausführungsformen verwendet der Grafikprozessor auch einen oder mehrere Rückführungspuffer, um Ausgabedaten zu speichern und Quer-Threadkommunikation durchzuführen. In manchen Ausführungsformen weist der Rückführungspufferzustand 916 auf, die Größe und Zahl von Rückführungspuffern auszuwählen, die für einen Satz von Pipelinebetrieben zu verwenden sind.
Die restlichen Befehle in der Befehlssequenz weichen basierend auf der aktiven Pipeline für Betriebe ab. Basierend auf einer Pipelineermittlung 920 ist die Befehlssequenz für die 3D-Pipeline 922, beginnend mit dem 3D-Pipelinezustand 930, oder die Medienpipeline 924, beginnend bei dem Medienpipelinezustand 940, maßgeschneidert.
Die Befehle, um den 3D-Pipelinezustand 930 zu konfigurieren, weisen 3D-Zustandsbefehle für Scheitelpunktpufferzustand, Scheitelpunktelementzustand, konstanten Farbzustand, Tiefenpufferzustand und andere Zustandsvariablen auf, die zu konfigurieren sind, bevor 3D-Primitivbefehle verarbeitet werden. Die Werte dieser Befehle sind mindestens zum Teil basierend auf der bestimmten 3D API in Verwendung ermittelt. In manchen Ausführungsformen sind 3D-Pipelinezustands-930 Befehle auch im Stande, selektiv gewisse Pipelineelemente zu deaktivieren oder zu umgehen, falls diese Elemente nicht verwendet werden.
In manchen Ausführungsformen wird 3D-Primitiv- 932 Befehl verwendet, um von der 3D-Pipeline zu verarbeitende 3D-Primitive vorzulegen. Befehle und verknüpfte Parameter, die zu dem Grafikprozessor über den 3D-Primitiv- 932 Befehl weitergegeben werden, werden zu der Scheitelpunktfunktion in der Grafikpipeline weitergeleitet. Die Scheitelpunktabruffunktion verwendet die 3D-Primitiv- 932 Befehlsdaten, um Scheitelpunktdatenstrukturen zu erzeugen. Die Scheitelpunktdatenstrukturen sind in einem oder mehreren Rückführungspuffern gespeichert. In manchen Ausführungsformen wird 3D-Primitiv- 932 Befehl verwendet, um Scheitelpunktbetriebe auf 3D-Primitiven über Scheitelpunkt-Shader durchzuführen. Um Scheitelpunkt-Shader zu verarbeiten, lastet 3D-Pipeline 922 Shader-Ausführungs-Threads zu Grafikprozessorausführungseinheiten ein.
In manchen Ausführungsformen ist 3D-Pipeline 922 über einen Ausführungs-934 Befehl oder ein Ereignis ausgelöst. In manchen Ausführungsformen löst ein Registerschrieb Befehlsausführung aus. In manchen Ausführungsformen ist Ausführung über einen „go“ oder „kick“ Befehl in der Befehlssequenz ausgelöst. In einer Ausführungsform ist Befehlsausführung unter Verwendung eines Pipelinesynchronisationsbefehls ausgelöst, um die Befehlssequenz durch die Grafikpipeline zu leeren. Die 3D-Pipeline wird Geometrieverarbeitung für die 3D-Primitive durchführen. Sobald Betriebe abgeschlossen sind, werden die resultierenden geometrischen Objekte rasterisiert und die Pixel-Engie färbt die resultierenden Pixel. Zusätzliche Befehle, um Pixel-Shading und Pixel-Backend-Betriebe zu steuern, können auch für diese Betriebe aufgewiesen sein.
In manchen Ausführungsformen folgt die Grafikprozessorbefehlssequenz 910 dem Medienpipeline- 924 -pfad, wenn Medienbetriebe durchgeführt werden. Im Allgemeinen hängt die bestimmte Verwendung und Weise von Programmierung für die Medienpipeline 924 von den durchzuführenden Medien- oder Rechenbetrieben ab. Bestimmte Mediendecodierungsbetriebe können während Mediendecodierung zu der Medienpipeline abgeladen werden. In manchen Ausführungsformen kann die Medienpipeline auch umgangen werden und Mediendecodierung kann zur Gänze oder zum Teil unter Verwendung von Ressourcen durchgeführt werden, die von einem oder mehreren Allzweckverarbeitungskernen bereitgestellt sind. In einer Ausführungsform weist die Medienpipeline auch Elemente für Allzweckgrafikprozessoreinheit- (GPGPU) Betriebe auf, wo der Grafikprozessor verwendet wird, um SIMD-Vektorbetriebe unter Verwendung von Rechen-Shader-Programmen durchzuführen, die nicht ausdrücklich auf das Rendering von Grafikprimitiven bezogen sind.
In manchen Ausführungsformen ist Medienpipeline 924 auf eine ähnliche Weise wie die 3D-Pipeline 922 konfiguriert. Ein Satz von Befehlen, um den Medienpipelinezustand 940 zu konfigurieren, wird vor den Medienobjektbefehlen 942 in eine Befehlswarteschlange eingelastet oder platziert. In manchen Ausführungsformen weisen Befehle für den Medienpipelinezustand 940 Daten auf, um die Medienpipelineelemente zu konfigurieren, die verwendet werden, um die Medienobjekte zu verarbeiten. Dies weist Daten auf, um die Videodecodierungs- und Videocodierungslogik innerhalb der Medienpipeline zu konfigurieren, wie Codierungs- und Decodierungsformat. In manchen Ausführungsformen unterstützen Befehle für den Medienpipelinezustand 940 auch die Verwendung eines oder mehrerer Zeiger zu „indirekten“ Zustandselementen, die ein Bündel von Zustandseinstellungen enthalten.
In manchen Ausführungsformen liefern Medienobjektbefehle 942 Zeiger zu Medienobjekten zur Verarbeitung durch die Medienpipeline. Die Medienobjekte weisen Speicherpuffer auf, die zu verarbeitende Videodaten enthalten. In manchen Ausführungsformen müssen alle Medienpipelinezustände gültig sein, bevor ein Medienobjektbefehl 942 ausgestellt wird. Sobald der Pipelinezustand konfiguriert ist und Medienobjektbefehle 942 eingereiht sind, wird die Medienpipeline 924 über einen Ausführungsbefehl 944 oder ein gleichwertiges Ausführungsereignis (z.B. Registerschrieb) ausgelöst. Ausgabe von der Medienpipeline 924 kann dann von Betrieben nachbearbeitet werden, die von der 3D-Pipeline 922 oder der Medienpipeline 924 bereitgestellt sind. In manchen Ausführungsformen sind GPGPU-Betriebe auf eine ähnliche Weise wie Medienbetriebe konfiguriert und ausgeführt.
Grafiksoftwarearchitektur
10 veranschaulicht eine beispielhafte Grafiksoftwarearchitektur für ein Datenverarbeitungssystem 1000 gemäß manchen Ausführungsformen. In manchen Ausführungsformen weist Softwarearchitektur eine 3D-Grafikanwendung 1010, ein Betriebssystem 1020 und mindestens einen Prozessor 1030 auf. In manchen Ausführungsformen weist Prozessor 1030 einen Grafikprozessor 1032 und einen oder mehrere Allzweckprozessorkern(e) 1034 auf. Die Grafikanwendung 1010 und das Betriebssystem 1020 sind jeweils in dem Systemspeicher 1050 des Datenverarbeitungssystems ausgeführt.
In manchen Ausführungsformen enthält 3D-Grafikanwendung 1010 ein oder mehrere Shader-Programme, die Shader-Anweisungen 1012 aufweisen. Die Shader-Sprachanweisungen können in einer Shader-Hochsprache sein, wie der High-Level Shader Language (HLSL) von Direct3D, der OpenGL Shader Language (GLSL) und so weiter. Die Anwendung weist auch ausführbare Anweisungen 1014 in einer Maschinensprache auf, die zur Ausführung durch den Allzweckprozessorkern 1034 geeignet ist. Die Anwendung weist auch Grafikobjekte 1016 auf, die von Scheitelpunktdaten definiert sind.
In manchen Ausführungsformen ist 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-Kernel verwendet. Das Betriebssystem 1020 kann eine Grafik-API 1022 unterstützen, wie die Direct3D API, die OpenGL API oder die Vulkan API. Wenn die Direct3D API verwendet wird, verwendet das Betriebssystem 1020 einen Frontend-Shader-Kompilierer 1024, um beliebige Shader-Anweisungen 1012 in HLSL in eine Shader-Niedersprache zu kompilieren. Die Kompilierung kann eine Just-in-Time (JIT) Kompilation verwenden oder die Anwendung kann Shader-Vorabkompilation durchführen. In manchen Ausführungsformen sind Hoch-Shader während der Kompilation der 3D-Grafikanwendung 1010 in Nieder-Shader kompiliert. In manchen Ausführungsformen sind die Shader-Anweisungen 1012 in einer Zwischenform bereitgestellt, wie einer Version der Standard Portable Intermediate Representation (SPIR), die von der Vulkan API verwendet wird.
In manchen Ausführungsformen enthält Anwendermodusgrafiktreiber 1026 einen Backend-Shader-Kompilierer 1027, um die Shader-Anweisungen 1012 in eine hardwarespezifische Darstellung umzuwandeln. Wenn die OpenGL API in Verwendung ist, werden Shader-Anweisungen 1012 in der GLSL-Hochsprache zu einem Anwendermodusgrafiktreiber 1026 zur Kompilation weitergegeben. In manchen Ausführungsformen verwendet Anwendermodusgrafiktreiber 1026 Betriebssystem-Kernelmodusfunktionen 1028, um mit einem Kernelmodusgrafiktreiber 1029 zu kommunizieren. In manchen Ausführungsformen kommuniziert Kernelmodusgrafiktreiber 1029 mit dem Grafikprozessor 1032, um Befehle und Anweisungen einzulasten.
IP-Kern-Implementierungen
Ein oder mehrere Aspekte mindestens einer Ausführungsform können durch stellvertretenden Code implementiert sein, der auf einem maschinenlesbaren Medium gespeichert ist, das Logik innerhalb einer integrierten Schaltung, wie einen Prozessor, darstellt und/oder definiert. Zum Beispiel kann das maschinenlesbare Medium Anweisungen aufweisen, die unterschiedliche Logik innerhalb des Prozessors darstellen. Wenn von einer Maschine gelesen, können die Anweisungen die Maschine veranlassen, die Logik zu fertigen, um die hierin beschriebenen Techniken durchzuführen. Solche Darstellungen, als „IP-Kerne“ bekannt, sind wiederverwendbare Einheiten von Logik für eine integrierte Schaltung, die auf einem greifbaren, maschinenlesbaren Medium gespeichert sein können, wie ein Hardwaremodell, das die Struktur der integrierten Schaltung beschreibt. Das Hardwaremodell kann an unterschiedliche Kunden oder Herstellungseinrichtungen geliefert werden, die das Hardwaremodell auf Fertigungsmaschinen laden, die die integrierte Schaltung herstellen. Die integrierte Schaltung kann derart gefertigt sein, dass die Schaltung in Verbindung mit einer beliebigen der hierin beschriebenen Ausführungsformen beschriebene Betriebe durchführt.
11A ist ein Blockdiagramm, das ein IP-Kern-Entwicklungssystem 1100 veranschaulicht, das verwendet werden kann, um eine integrierte Schaltung herzustellen, um Betriebe gemäß einer Ausführungsform durchzuführen. Das IP-Kern-Entwicklungssystem 1100 kann verwendet werden, um modulare, wiederverwendbare Designs zu erzeugen, die in ein größeres Design eingegliedert werden können oder verwendet werden können, um eine gesamte integrierte Schaltung (z.B. eine SOC-integrierte Schaltung) zu errichten. Eine Designstätte 1130 kann eine Softwaresimulation 1110 eines IP-Kerndesigns in einer Programmierhochsprache (z.B. C/C++) erzeugen. Die Softwaresimulation 1110 kann verwendet werden, um das Verhalten des IP-Kerns unter Verwendung eines Simulationsmodells 1112 zu designen, zu testen und zu verifizieren. Das Simulationsmodell 1112 kann funktionelle, verhaltensbezogene und/oder Taktungssimulationen aufweisen. Ein Registertransferlevel- (RTL) Design 1115 kann dann aus dem Simulationsmodell 1112 erstellt oder synthetisiert werden. Das RTL-Design 1115 ist eine Abstraktion des Verfahrens der integrierten Schaltung, die den Ablauf digitaler Signale zwischen Hardwareregistern modelliert, aufweisend die verknüpfte Logik, die unter Verwendung der modellierten Digitalsignale durchgeführt wird. Zusätzlich zu einem RTL-Design 1115 können auch Niederleveldesigns bei dem Logiklevel oder Transistorlevel erzeugt, designt oder synthetisiert werden. Daher können die bestimmten Details des Anfangsdesigns und der Simulation variieren.
Das RTL-Design 1115 oder ein Äquivalent kann weiter von der Designeinrichtung in ein Hardwaremodell 1120 synthetisiert werden, das in einer Hardwarebeschreibungssprache (HDL, Hardware Description Language) oder einer anderen Darstellung von physischen Designdaten sein kann. Die HDL kann weiter simuliert oder getestet werden, um das IP-Kern-Design zu verifizieren. Das IP-Kern-Design kann zur Zustellung an eine Drittfertigungsstätte 1165 unter Verwendung von nichtflüchtigem Speicher 1140 (z.B. Festplatte, Flashspeicher oder ein beliebiges nichtflüchtiges Datenspeichermedium) gespeichert sein. Alternativ kann das IP-Kern-Design mittels einer kabelgebundenen Verbindung 1150 oder drahtlosen Verbindung 1160 übertragen werden (z.B. über das Internet). Die Fertigungsstätte 1165 kann dann eine integrierte Schaltung fertigen, die mindestens zum Teil auf dem IP-Kern-Design basiert. Die gefertigte integrierte Schaltung kann konfiguriert sein, Betriebe in Übereinstimmung mit mindestens einer hierin beschriebenen Ausführungsform durchzuführen.
11B veranschaulicht eine Querschnittseitenansicht einer integrierten Schaltungs-Package-Anordnung 1170 gemäß manchen hierin beschriebenen Ausführungsformen. Die integrierte Schaltungs-Package-Anordnung 1170 veranschaulicht eine Implementierung einer oder mehrerer Prozessor- oder Beschleunigervorrichtungen, wie hierin beschrieben. Die Package-Anordnung 1170 weist mehrere Einheiten von Hardware-Logik 1172, 1174 auf, die mit einem Substrat 1180 verbunden sind. Die Logik 1172, 1174 kann mindestens teilweise in konfigurierbarer Logik oder fixierter Funktionalitätslogikhardware implementiert sein und kann einen oder mehrere Abschnitte beliebiger des/der Prozessorkern(e), Grafikprozessor(en) oder anderer hierin beschriebener Beschleunigervorrichtungen aufweisen. Jede Einheit von Logik 1172, 1174 kann innerhalb eines Halbleiter-Dies implementiert sein oder mit dem Substrat 1180 über eine Zwischenverbindungsstruktur 1173 gekoppelt sein. Die Zwischenverbindungsstruktur 1173 kann konfiguriert sein, elektrische Signale zwischen der Logik 1172, 1174 und dem Substrat 1180 zu leiten und kann Zwischenverbindungen aufweisen, wie, aber nicht begrenzt auf, Bumps oder Säulen. In manchen Ausführungsformen kann die Zwischenverbindungsstruktur 1173 konfiguriert sein, elektrische Signale zu leiten, wie zum Beispiel Eingabe/Ausgabe-(I/O, Input/Output) Signale und/oder Leistungs- oder Massesignale, die mit dem Betrieb der Logik 1172, 1174 verknüpft sind. In manchen Ausführungsformen ist das Substrat 1180 ein Epoxy-basiertes Laminatsubstrat. Das Substrat 1180 kann andere geeignete Typen von Substraten in anderen Ausführungsformen aufweisen. Die Package-Anordnung 1170 kann mit anderen elektrischen Vorrichtungen über eine Package-Zwischenverbindung 1183 verbunden sein. Die Package-Zwischenverbindung 1183 kann mit einer Oberfläche des Substrats 1180 gekoppelt sein, um elektrische Signale mit anderen elektrischen Vorrichtungen zu leiten, wie einer Hauptplatine, einem anderen Chipsatz oder Multichipmodul.
In manchen Ausführungsformen sind die Einheiten von Logik 1172, 1174 elektrisch mit einer 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 Leitung für elektrische Signale bereitstellt. Die Brücke 1182 kann ein Brückensubstrat aufweisen, das aus Glas oder einem geeigneten Halbleitermaterial besteht. Elektrische Leitungsmerkmale können auf dem Brückensubstrat gebildet sein, um eine Chip-zu-Chip-Verbindung zwischen der Logik 1172, 1174 bereitzustellen.
Obwohl zwei Einheiten von Logik 1172, 1174 und einer Brücke 1182 veranschaulicht sind, können hierin beschriebene Ausführungsformen mehr oder weniger Logikeinheiten auf einem oder mehreren Dies aufweisen. Der eine oder die mehreren Dies können durch null oder mehr Brücken verbunden sein, da die Brücke 1182 ausgeschlossen sein kann, wenn die Logik auf einem einzelnen Die aufgewiesen ist. Alternativ können mehrere Dies oder Einheiten von Logik durch eine oder mehrere Brücken verbunden sein. Zusätzlich können mehrere Logikeinheiten, Dies und Brücken miteinander in anderen möglichen Konfigurationen verbunden sein, aufweisend dreidimensionale Konfigurationen.
11C veranschaulicht eine Package-Anordnung 1190, die mehrere Einheiten von Hardwarelogikchiplets aufweist, die mit einem Substrat 1180 (z.B. Basis-Die) verbunden sind. Eine Grafikverarbeitungseinheit, ein paralleler Prozessor und/oder Rechenbeschleuniger wie hierin beschrieben, können aus vielfältigen Siliziumchiplets zusammengesetzt sein, die separat hergestellt wurden. In diesem Kontext ist ein Chiplet eine mindestens teilweise gepackte integrierte Schaltung, die individuelle Einheiten von Logik aufweist, die mit anderen Chiplets in ein größeres Package zusammengefügt werden können. Ein vielfältiger Satz von Chiplets mit verschiedener IP-Kern-Logik kann in eine einzelne Vorrichtung zusammengesetzt werden. Zusätzlich können die Chiplets in ein Basis-Die oder Basischiplet unter Verwendung aktiver Interposer-Technologie integriert sein. Die hierin beschriebenen Konzepte ermöglichen die Zwischenverbindung und Kommunikation zwischen den verschiedenen Formen von IP innerhalb der GPU. IP-Kerne können unter Verwendung verschiedener Prozesstechnologien hergestellt und während Herstellung zusammengefügt werden, was die Komplexität vermeidet, mehrere IPs, insbesondere auf einem großen SoC mit einigen Arten von IPs, zu demselben Herstellungsprozess zusammenlaufen zu lassen. Die Verwendung mehrerer Prozesstechnologien zu ermöglichen, verbessert die Zeit bis zur Vermarktung und stellt eine kosteneffektive Weise bereit, mehrere Produkt-SKUs zu erstellen. Zusätzlich sind die verteilten IPs zugänglicher dafür, unabhängig leistungsgeschaltet zu werden, wobei Komponenten, die auf einer gegebenen Nutzlast nicht in Verwendung sind, ausgeschaltet werden können, was einen Gesamtleistungsverbrauch verringert.
Die Hardwarelogikchiplets können Sonderzweckhardwarelogikchiplets 1172, Logik- oder I/O-Chiplets 1174 und/oder Speicherchiplets 1175 aufweisen. Die Hardwarelogikchiplets 1172 und Logik- oder I/O-Chiplets 1174 können mindestens teilweise in konfigurierbarer Logik oder fixierter Funktionalitätslogikhardware implementiert sein und können einen oder mehrere Abschnitte beliebiger des/der Prozessorkern(e), Grafikprozessor(en), parallelen Prozessoren oder anderen hierin beschriebenen Beschleunigervorrichtungen aufweisen. Die Speicherchiplets 1175 können DRAM- (z.B. GDDR, HBM) Speicher oder Cache- (SRAM) Speicher sein.
Jedes Chiplet kann als separates Halbleiter-Die gefertigt sein und mit dem Substrat 1180 über eine Zwischenverbindungsstruktur 1173 gekoppelt sein. Die Zwischenverbindungsstruktur 1173 kann konfiguriert sein, elektrische Signale zwischen den unterschiedlichen Chiplets und Logik innerhalb des Substrats 1180 zu leiten. Die Zwischenverbindungsstruktur 1173 kann Zwischenverbindungen aufweisen, wie, aber nicht begrenzt auf, Bumps oder Säulen. In manchen Ausführungsformen kann die Zwischenverbindungsstruktur 1173 konfiguriert sein, elektrische Signale, wie zum Beispiel Eingang/Ausgang- (I/O) Signale und/oder Leistungs- oder Massesignale, die mit dem Betrieb der Logik-, I/O- und Speicherchiplets verknüpft sind, zu leiten.
In manchen Ausführungsformen ist das Substrat 1180 ein Epoxy-basiertes Laminatsubstrat. Das Substrat 1180 kann in anderen Ausführungsformen andere geeignete Typen von Substraten aufweisen. Die Package-Anordnung 1190 kann mit anderen elektrischen Vorrichtungen über eine Package-Zwischenverbindung 1183 verbunden sein. Die Package-Zwischenverbindung 1183 kann an eine Fläche des Substrats 1180 gekoppelt sein, um elektrische Signale zu anderen elektrischen Vorrichtungen zu leiten, wie einer Hauptplatine, einem anderen Chipsatz oder ein Multichipmodul.
In manchen Ausführungsformen kann ein Logik- oder I/O-Chiplet 1174 und ein Speicherchiplet 1175 elektrisch über eine Brücke 1187 gekoppelt sein, die konfiguriert ist, elektrische Signale zwischen dem Logik- oder I/O-Chiplet 1174 und einem Speicherchiplet 1175 zu leiten. Die Brücke 1187 kann eine dichte Zwischenverbindungsstruktur sein, die eine Leitung für elektrische Signale bereitstellt. Die Brücke 1187 kann ein Brückensubstrat aufweisen, das aus Glas oder einem geeigneten Halbleitermaterial besteht. Elektrische Leitungsmerkmale können auf dem Brückensubstrat gebildet sein, um eine Chip-zu-Chip-Verbindung zwischen dem Logik- oder I/O-Chiplet 1174 und einem Speicherchiplet 1175 bereitzustellen. Die Brücke 1187 kann auch als eine Siliziumbrücke oder eine Zwischenverbindungsbrücke bezeichnet werden. Zum Beispiel ist die Brücke 1187 in manchen Ausführungsformen eine eingebettete Multi-Die-Zwischenverbindungsbrücke (EMIB, Embedded Multi-die Interconnect Bridge). In manchen Ausführungsformen kann die Brücke 1187 einfach eine direkte Verbindung von einem Chiplet zu einem anderen Chiplet sein.
Das Substrat 1180 kann Hardwarekomponenten für I/O 1191, Cachespeicher 1192 und andere Hardwarelogik 1193 aufweisen. Ein Fabric 1185 kann in das Substrat 1180 eingebettet sein, um Kommunikation zwischen den unterschiedlichen Logikchiplets und der Logik 1191, 1193 innerhalb des Substrats 1180 zu ermöglichen. In einer Ausführungsform können der I/O 1191, das Fabric 1185, der Cache, die Brücke und andere Hardwarelogik 1193 in ein Basis-Die integriert sein, das auf das Substrat 1180 geschichtet ist.
In unterschiedlichen Ausführungsformen kann eine Package-Anordnung 1190 weniger oder mehr Komponenten und Chiplets aufweisen, die durch ein Fabric 1185 oder eine oder mehrere Brücken 1187 zwischenverbunden sind. Die Chiplets innerhalb der Package-Anordnung 1190 können in einer 3D- oder 2,5D-Anordnung angeordnet sein. Im Allgemeinen können Brückenstrukturen 1187 verwendet werden, um eine Punkt-zu-Punkt-Zwischenverbindung zwischen zum Beispiel Logik- oder I/O-Chiplets und Speicherchiplets zu ermöglichen. Das Fabric 1185 kann verwendet werden, um die unterschiedlichen Logik- und/oder I/O-Chiplets (z.B. Chiplets 1172, 1174, 1191, 1193) mit anderer Logik und/oder I/O-Chiplets zwischenzuverbinden In einer Ausführungsform kann der Cachespeicher 1192 innerhalb des Substrats als ein globaler Cache für die Package-Anordnung 1190, Teil eines verteilten globalen Caches, oder als ein dedizierter Cache für das Fabric 1185 agieren.
11D veranschaulicht eine Package-Anordnung 1194, die austauschbare Chiplets 1195 aufweist, gemäß einer Ausführungsform. Die austauschbaren Chiplets 1195 können in standardisierten Schlitzen auf einem oder mehreren Basischiplets 1196, 1198 angeordnet sein. Die Basischiplets 1196, 1198 können über eine Brückenzwischenverbindung 1197 gekoppelt sein, die ähnlich den anderen Brückenverbindungen sein kann, die hierin beschrieben sind, und kann zum Beispiel ein EMIB sein. Speicherchiplets können auch mit Logik- oder I/O-Chiplets über eine Brückenzwischenverbindung verbunden sein. I/O- und Logikchiplets können über ein Zwischenverbindungsfabric kommunizieren. Die Basischiplets können jeweils einen oder mehrere Schlitze in einem standardisierten Format für eines von Logik oder I/O oder Speicher/Cache unterstützen.
In einer Ausführungsform können SRAM- und Leistungslieferungsschaltungen in ein oder mehrere der Basischiplets 1196, 1198 gefertigt sein, die unter Verwendung einer verschiedenen Prozesstechnologie relativ zu den austauschbaren Chiplets 1195 gefertigt sein können, die auf die Basischiplets gestapelt sind. Zum Beispiel können die Basischiplets 1196, 1198 unter Verwendung einer größeren Prozesstechnologie gefertigt werden, während die austauschbaren Chiplets unter Verwendung einer kleineren Prozesstechnologie hergestellt sein können. Ein oder mehrere der austauschbaren Chiplets 1195 können Speicher- (z.B. DRAM) Chiplets sein. Verschiedene Speicherdichten können für die Package-Anordnung 1194 basierend auf der Leistung und/oder Arbeitsleistung ausgewählt sein, die für das Produkt angezielt wird, das die Package-Anordnung 1194 verwendet. Zusätzlich können Logikchiplets mit einer verschiedenen Zahl von Typen von funktionalen Einheiten zum Zeitpunkt der Anordnung basierend auf der Leistung und/oder Arbeitsleistung, die für das Produkt angezielt werden, ausgewählt werden. Zusätzlich können Chiplets, die IP-Logikkerne verschiedener Typen enthalten, in die austauschbaren Chipletschlitze eingesetzt werden, was Hybridprozessordesigns ermöglicht, die verschiedene Technologie-IP-Blöcke frei kombinieren können.
Beispielhafte System-auf-einem-Chip-integrierte Schaltung
12-13 veranschaulichen beispielhafte integrierte Schaltungen und verknüpfte Grafikprozessoren, die unter Verwendung eines oder mehrerer IP-Kerne gefertigt sein können, gemäß unterschiedlichen hierin beschriebenen Ausführungsformen. Zusätzlich zu dem Veranschaulichten können andere Logik und Schaltungen aufgewiesen sein, die zusätzliche Grafikprozessoren/-kerne, periphere Schnittstellensteuerungen oder Allzweckprozessorkerne aufweisen.
12 ist ein Blockdiagramm, das eine beispielhafte System-auf-einem-Chip-integrierte Schaltung 1200 veranschaulicht, die unter Verwendung eines oder mehrerer IP-Kerne gefertigt werden kann, gemäß einer Ausführungsform. Beispielhafte integrierte Schaltung 1200 weist einen oder mehrere Anwendungsprozessor(en) 1205 (z.B. CPUs), mindestens einen Grafikprozessor 1210 auf und kann zusätzlich einen Bildprozessor 1215 und/oder einen Videoprozessor 1220 aufweisen, von denen beliebige ein modularer IP-Kern von derselben oder vielen verschiedenen Designeinrichtungen sein können. Integrierte Schaltung 1200 weist Peripherie- oder Buslogik auf, aufweisend eine USB-Steuerung 1225, UART-Steuerung 1230, eine SPI/SDIO-Steuerung 1235 und eine I²S/I²C-Steuerung 1240. Zusätzlich kann die integrierte Schaltung eine Anzeigevorrichtung 1245 aufweisen, die mit einer oder mehreren einer High-Definition Multimedia Interface (HDMI) Steuerung 1250 und einer Mobile Industry Processor Interface (MIPI) Anzeigeschnittstelle 1255 gekoppelt ist. Datenspeicher kann durch ein Flashspeicherteilsystem 1260 bereitgestellt sein, das Flashspeicher und eine Flashspeichersteuerung aufweist. Speicherschnittstelle kann über eine Speichersteuerung 1265 für Zugriff auf SDRAM- oder SRAM-Speichervorrichtungen bereitgestellt sein. Manche integrierten Schaltungen weisen zusätzlich eine eingebettete Sicherheits-Engine 1270 auf.
13A-13B sind Blockdiagramme, die beispielhafte Grafikprozessoren zur Verwendung innerhalb eines SoC veranschaulichen, gemäß hierin beschriebenen Ausführungsformen. 13A veranschaulicht einen beispielhaften Grafikprozessor 1310 einer System-auf-einem-Chip-integrierten Schaltung, die unter Verwendung eines oder mehrerer IP-Kerne gefertigt sein kann, gemäß einer Ausführungsform. 13B veranschaulicht einen zusätzlichen beispielhaften Grafikprozessor 1340 einer System-auf-einem-Chip-integrierten Schaltung, die unter Verwendung eines oder mehrerer IP-Kerne gefertigt sein kann, gemäß einer Ausführungsform. Grafikprozessor 1310 von 13A ist ein Beispiel eines Niederleistungsgrafikprozessorkerns. Grafikprozessor 1340 von 13B ist ein Beispiel eines Hocharbeitsleistungsgrafikprozessorkerns. Jeder der Grafikprozessoren 1310, 1340 kann eine Variante des Grafikprozessors 1210 von 12 sein.
Wie in 13A gezeigt, weist Grafikprozessor 1310 einen Scheitelpunktprozessor 1305 und einen oder mehrere Fragmentprozessor(en) 1315A-1315N (z.B. 1315A, 1315B, 1315C, 1315D bis 1315N-1 und 1315N) auf. Grafikprozessor 1310 kann verschiedene Shader-Programme über separate Logik derart ausführen, dass der Scheitelpunktprozessor 1305 optimiert ist, Betriebe für Scheitelpunkt-Shader-Programme auszuführen, während der eine oder die mehreren Fragment-Shaderprozessor(en) 1315A-1315N Fragment- (z.B. Pixel) Shading-Betriebe für Fragment- oder Pixel-Shader-Programme ausführen. Der Scheitelpunktprozessor 1305 führt die Scheitelpunktverarbeitungsstufe der 3D-Grafikpipeline aus und erzeugt Primitive und Scheitelpunktdaten. Der/die Fragmentprozessor(en) 1315A-1315N verwenden die Primitiv- und Scheitelpunktdaten, die von dem Scheitelpunktprozessor 1305 erzeugt sind, um einen Framepuffer zu erstellen, der auf einer Anzeigevorrichtung angezeigt wird. In einer Ausführungsform sind die Fragmentprozessor(en) 1315A-1315N optimiert, Fragment-Shader-Programme auszuführen, wie sie in der OpenGL API bereitgestellt sind, die verwendet werden können, ähnliche Betriebe wie ein Pixel-Shader-Programm durchzuführen, wie es in der der Direct 3D API bereitgestellt ist.
Grafikprozessor 1310 weist zusätzlich eine oder mehrere Speicherverwaltungseinheiten (MMUs, Memory Management Units) 1320A-1320B, Cache(s) 1325A-1325B und Schaltungszwischenverbindung(en) 1330A-1330B auf. Die eine oder mehreren MMU(s) 1320A-1320B stellen virtuelle zu physischer Adressabbildung für den Grafikprozessor 1310 bereit, aufweisend den Scheitelpunktprozessor 1305 und/oder Fragmentprozessor(en) 1315A-1315N, die sich auf Scheitelpunkt- oder Bild-/Texturdaten beziehen können, die in Speicher gespeichert sind, zusätzlich zu Scheitelpunkt- oder Bild-/Texturdaten, die in dem einen oder den mehreren Cache(s) 1325A-1325B gespeichert sind. In einer Ausführungsform können die eine oder mehreren MMU(s) 1320A-1320B mit anderen MMUs innerhalb des Systems synchronisiert werden, aufweisend eine oder mehrere MMUs, die mit dem einen oder den mehreren Anwendungsprozessor(en) 1205, Bildprozessor 1215 und/oder Videoprozessor 1220 von 12 derart verknüpft sind, dass jeder Prozessor 1205-1220 in einem geteilten oder vereinheitlichten virtuellen Speichersystem teilnehmen kann. Die eine oder mehreren Schaltungszwischenverbindung(en) 1330A-1330B ermöglichen Grafikprozessor 1310, sich mit anderen IP-Kernen innerhalb des SOC entweder über einen internen Bus des SOC oder über eine direkte Verbindung zu verschalten, gemäß Ausführungsformen.
Wie in 13B gezeigt, weist Grafikprozessor 1340 die eine oder mehreren MMU(s) 1320A-1320B, Cache(s) 1325A-1325B und Schaltungszwischenverbindung(en) 1330A-1330B des Grafikprozessors 1310 von 13A auf. Grafikprozessor 1340 weist einen oder mehrere Shader-Kern(e) 1355A-1355N (z.B. 1455A, 1355B, 1355C, 1355D, 1355E, 1355F über 1355N-1 und 1355N) auf, der eine vereinheitlichte Shader-Kernarchitektur bereitstellt, in der ein einzelner Kern oder Typ oder Kern alle Typen programmierbaren Shader-Codes ausführen kann, aufweisend Shader-Programmcode, um Scheitelpunkt-Shader, Fragment-Shader und/oder Rechen-Shader zu implementieren. Die exakte Zahl von vorhandenen Shader-Kernen kann unter Ausführungsformen und Implementierungen variieren. Zusätzlich weist Grafikprozessor 1340 einen Zwischenkernaufgabenverwalter 1345 auf, der als ein Thread-Dispatcher dient, um Ausführungs-Threads zu einem oder mehreren Shader-Kernen 1355A-1355N einzulasten, und eine Kachelungseinheit 1358, um Kachelungsbetriebe für kachelbasiertes Rendering zu beschleunigen, in dem Rendering-Betriebe für eine Szene in Bildraum unterteilt sind, zum Beispiel um lokale räumliche Kohärenz mit einer Szene auszunutzen oder Verwendung interner Caches zu optimieren.
Multikachelarchitekturen bringen einige Herausforderungen mit sich, da außer Bereitstellung einer vereinheitlichten Ansicht von physischem Speicher sonst nicht viel über die Kacheln geteilt wird. Zum Beispiel weist jede Kachel ihre eigene separate Seitentabelle auf und die Treiber müssen ausdrücklich Arbeit für jede Kachel unabhängig einplanen. In einem Beispiel entspricht jede Kachel einer verschiedenen GPU.
Mehrkachelspeicherhierarchien bevorzugen stark Daten, die mit Aufgaben verknüpft sind, die diese Daten bearbeiten. Mit anderen Worten, Aufgaben, die auf jeder Kachel laufen, sollten im Allgemeinen auf Daten zugreifen, die lokal bei dieser Kachel liegen. Jedoch ist das nicht immer möglich, weil Speicherverwaltungsstrategien erzeugt sind, um geteilte Speicherzugriffe zu optimieren und besseren Arbeitslastausgleich zu gestatten.
Eine modulare Skalierungsstrategie weist auf, große diskrete GPUs aufzubauen, wie eine Konfiguration mehrerer Kacheln, die mit Hochgeschwindigkeits-Fabric-Zwischenverbindungen aneinandergeschlossen sind. Jede Kachel (z.B. diskrete GPU) kann ihren eigenen lokalen Speicher mit anderen Kacheln teilen, um einen vereinheitlichten kachelübergreifenden physischen Adressraum zu erzeugen. Diese Speicherteilung wird durch bidirektionale Hochgeschwindigkeitszwischenverbindungen ermöglicht und Fernzugriffe durch diese werden zusätzliche Latenzen mit sich bringen. Das vorliegende Design weist neue Speicherverwaltungsmerkmale auf, um Fernzugriffe zu minimieren und beide Richtungen der bidirektionalen Zwischenverbindungen besser zu nutzen.
Die Speicherverwaltungsmerkmale des vorliegenden Designs stellen bessere Nutzung der maximal angesammelten Bandbreite von Multikachelarchitekturen (z.B. 2 Kacheln, 4 Kacheln) und deren Zwischenverbindungen für Prozesse bereit, die über mehrere Kacheln ausgeführt werden. Zusätzlich erlaubt eine Kombination von Pro-Kachel-Seitentabellen mit einem vereinheitlichten Adressraum Verwaltungsmerkmale, die dabei helfen, Anwendermodustreiberprogrammierung zu vereinfachen, während bessere Arbeitsleistung bereitgestellt wird.
Ressourcenspiegelung ist ein Zuweisungsverfahren, dass sicherstellt, dass alle Zugriffe auf gewisse Nur-Lese-Ressourcen, wie konstante Puffer, lokal sind, indem die Daten über alle teilnehmenden Kacheln repliziert werden. 14A und 14B veranschaulichen einen Ansatz für einen Anwendermodustreiber (UMD) (z.B. UMF 1026), um ausdrücklich eine Ressource zu spiegeln, indem separate gespiegelte Zuweisungen virtueller Adressen erzeugt und entsprechende Kopierbefehle eingesetzt werden, um sicherzustellen, dass die Daten ordentlich repliziert werden. 14A veranschaulicht eine Konfiguration eines Grafikprozessors 1400 an einem Package, das Grafikvorrichtungen 1410, 1420, 1430 und 1440 (z.B. GPU 239, GPU 270, GPU 1980, Grafikengine-Kachel 310A-310D, Rechenengine-Kachel 340A-340D, Grafikverarbeitungsengine 410) und jeweiligen lokalen Speicher 1411, 1421, 1431 und 1441 für jede Grafikvorrichtung aufweist. Der Grafikprozessor 1400 weist Kommunikationslinks 1445-1449 auf (z.B. bidirektionale Hochgeschwindigkeitszwischenverbindungen, PCIe x 16).
14B veranschaulicht eine separate Vorrichtungskonfiguration eines Grafikprozessors 1450 an einem Package, das Grafikvorrichtungen 1460, 1470, 1480 und 1490 (z.B. GPU 239, GPU 270, GPU 1980, Grafikengine-Kachel 310A-310D, Rechenengine-Kachel 340A-340D, Grafikverarbeitungsengine 410) und jeweiligen lokalen Speicher 1461, 1471, 1481, 1491 für jede GPU aufweist. Der Grafikprozessor 1450 weist Kommunikationslinks 1495-1498 auf (z.B. bidirektionale Hochgeschwindigkeitszwischenverbindungen, PCIe x 16).
Wenn der Anwendermodustreiber (UMD) ausdrücklich eine Ressource spiegelt, indem separate gespiegelte Zuweisungen virtueller Adressen erzeugt werden (z.B. 4 separate virtuelle Zuweisungen für 14B), bedeutet das, dass der UMD sicherstellen muss, dass alle Referenzen auf diese Ressource die korrekte virtuelle Adresse verwenden, um lokalen Zugriff sicherzustellen. Dies fügt zusätzliche Komplexität zu den UMDs hinzu, da erwartet wird, dass der UMD einen Einzelbündelpuffer vorlegen wird, den der Kernelmodustreiber (KMD, Kernel Mode Driver) (z.B. KMD 1029) allen Kacheln neuvorlegen wird. Zum Beispiel, wenn eine gespiegelte Ressource aktualisiert wird, wird der UMD mehrere Kopierbefehle für jede gespiegelte virtuelle Zuweisung einsetzen und Vorhersage oder andere Verfahren verwenden, wie eindeutige Befehlsstreams an jede GPU-Kachel zu senden, um sicherzustellen, dass die korrekten Kopierbefehle pro Kachel ausgeführt werden.
Jedoch gestatten separate Pro-Kachel-Seitentabellen dem Kernelmodustreiber, die physischen Seiten zu spiegeln, während ein gemeinsamer virtueller Adressbereich für diese Kacheln derart bereitgestellt wird, dass er aus der Perspektive des Anwendermodustreibers als eine einzelne virtuelle Zuweisung erscheint. Dies wird angestellt, indem Seitentabellenabbildungen für jede Kachel derart eingestellt werden, dass die virtuellen Adressen für eine gespiegelte Zuweisung nur zu physischem Speicher abbilden werden, der lokal von einer jeweiligen Kachel ist.
15A und 15B veranschaulichen UMD-verwaltete gespiegelte Zuweisungen in Übereinstimmung mit einer Ausführungsform. 15A veranschaulicht eine einzelne virtuelle Zuweisung 1560-1, 1560-2, 1560-3 und 1560-4. 15B zeigt eine physische Zuweisung in Speicher 1570-1, 1570-2, 1570-3 und 1570-4 der einzelnen virtuellen Zuweisung. Der Grafikprozessor 1500 weist Grafikvorrichtungen 1510, 1520, 1530 und 1540 (z.B. GPU 239, GPU 270, GPU 1980; Grafikengine-Kachel 310A-310D, Rechenengine-Kachel 340A-340D, Grafikverarbeitungsengine 410) und jeweiligen lokalen Speicher 1570-1, 1570-2, 1570-3 und 1570-4 (z.B. Hochbandbreitenspeicher, DRAM) für jede Grafikvorrichtung auf. Der Grafikprozessor 1500 weist Kommunikationslinks 1590-1594 (z.B. bidirektionale Hochgeschwindigkeitszwischenverbindungen, PCIe x 16) auf.
Unterstützung für diesen Typ von gespiegelten Zuweisungen hinzuzufügen, wird dabei helfen, Arbeitsleistung zu verbessern, ohne Komplexität zu den UMDs hinzuzufügen. Es werden keine wesentlichen UMD-Programmierungsänderungen nebst Einstellen einer Speicherzuweisungskennzeichnung benötigt. Zum Beispiel muss der UMD keine zusätzlichen Kopierbetriebe hinzufügen, während eine gespiegelte Ressource aktualisiert wird, da jede Kachel den Kopierbetrieb unabhängig ausführen und ihren lokalen physischen Speicher ordentlich besetzen wird.
16A und 16B veranschaulichen KMD-Speicherverwalterunterstützung zum Spiegeln physischer Seiten von einem gemeinsamen virtuellen Adressbereich in Übereinstimmung mit einer Ausführungsform. 16A veranschaulicht eine einzelne oder gemeinsame virtuelle Zuweisung 1600, die Seiten (z.B. A1, B1, C1, D1, A2, B2, C2, D2, A3, B3, C3, D3) zum Speichern von Daten aufweisen. 16B zeigt eine physische Zuweisung in Speicher 1670-1, 1670-2, 1670-3 und 1670-4 der einzelnen oder gemeinsamen virtuellen Zuweisung. Der Grafikprozessor 1650 weist Grafikvorrichtungen 1610, 1620, 1630 und 1640 (z.B. GPU 239, GPU 270, GPU 1980, Grafikengine-Kachel 310A-310D, Rechenengine-Kachel 340A-340D, Grafikverarbeitungsengine 410) und jeweiligen lokalen Speicher 1670-1, 1670-2, 1670-3 und 1670-4 (z.B. Hochbandbreitenspeicher, DRAM) für jede Grafikvorrichtung auf. Der Grafikprozessor 1650 weist Kommunikationslinks 1690-1694 (z.B. bidirektionale Hochgeschwindigkeitszwischenverbindungen, PCIe x 16) auf.
In einem Beispiel kann für ein Anzeigetreibermodell der UMD zusätzliche private Daten mit der Zuweisungserzeugungsanfrage bereitstellen, um dem KMD anzuzeigen, ob die Ressource gemeinsam mit einer Knotenmaske gespiegelt werden muss oder nicht, um anzuzeigen, welche Kacheln auf die Ressource zugreifen werden. Jedoch ändert dieser Typ von Zuweisung die Weise, wie der KMD physische Seitenanfragen von dem OS handhabt und muss wahrscheinlich private physische Speicherheaps für jede Kachel reservieren. Andere Optionen können aufweisen, hohe Bits der virtuellen Adresse zu verwenden, um pro-Kachel-Zuweisungen anzuzeigen, die der Speicherverwalter verwenden kann.
Für geteilte Lese-/Schreibressourcen, wie Lese-/Schreibpuffer, ist es wünschenswert, die physischen Seiten für die virtuelle Zuweisung über alle teilnehmenden Kacheln zu verschachteln, wie es in 17A und 17B veranschaulicht ist. Eine virtuelle Zuweisung 1700 weist verschiedene Typen von Schattierung auf, um verschiedene Farbzuweisungen über verschiedene Kacheln darzustellen. Die virtuelle Zuweisung 1700 weist verschiedene Seiten A1, B1, C1, D1, A2, B2, C2, D2, A3, B3, C3, D3 auf. In einem Beispiel speichern A1, B1, C1 und D1 Bilddaten für eine Bergszene. A1 entspricht einem ersten Gebiet einer Anzeige, B1 entspricht einem zweiten Gebiet der Anzeige, C1 entspricht einem dritten Gebiet der Anzeige und D1 entspricht einem vierten Gebiet der Anzeige.
Der Grafikprozessor 1750 weist Grafikvorrichtungen 1710, 1720, 1730 und 1740 (z.B. GPU 239, GPU 270, GPU 1980, Grafikengine-Kachel 310A-310D, Rechenengine-Kachel 340A-340D, Grafikverarbeitungsengine 410) und jeweiligen lokalen Speicher 1770, 1771, 1772 und 1773 (z.B. Hochbandbreitenspeicher, DRAM) für jede Grafikvorrichtung auf. Der Grafikprozessor 1750 weist Kommunikationslinks 1790-1794 (z.B. bidirektionale Hochgeschwindigkeitszwischenverbindungen, PCIe x 16) auf.
Diese Verschachtelung der virtuellen zu physischen Zuweisung gestattet vollständige Verwendung beider Richtungen der bidirektionalen Kommunikationslinks 1790-1794 (z.B. 500GB/s MDFI-Links) und stellt bessere Arbeitslastverteilung bereit, um zu vermeiden, dass ferne Kacheln erhöhte Speicherlatenzen aufweisen. Falls eine Zuweisung einer einzelnen Kachel zugewiesen werden würde, werden die zusätzlichen Speicherlatenzen allen fernen Kacheln auferlegt und Flaschenhalse können aufgrund dessen auftreten, dass ferne Kacheln um Bandbreite konkurrieren.
Idealerweise findet diese Verschachtelung bei einer Granularität statt, die viel kleiner als eine 4 KB-Seite ist. Es gibt jedoch eine Tendenz, sich zu 64 KB-Zuweisungsgrößen zu bewegen, die Färbung nicht so effektiv machen, da kleinere Ressourcen keine Farbzuweisung aufweisen können. Dieser Verschachtelungsmechanismus gestattet Lastenausgleich von Speicherzugriffen, um Flaschenhälse und Hotspots von regelmäßigem Zugriff zu verhindern.
Eine Knotenmaske stellt einen Mechanismus mit Software bereit, die anzeigt, wo eine Stelle einer eingeschränkten Ressource in physischem Speicher einer Kachel zu platzieren ist. Die Knotenmaske zeigt an, welche Gruppe von Kacheln eine bestimmte Seitenfärbung einer virtuellen Zuweisung handhaben wird. In einem Beispiel erzeugt das vorliegende Design zwei abwechselnde Framerendering- (AFR; Alternate Frame Rendering) Gruppen von jeweils zwei Kacheln, wo eine Gruppe Betriebe zum Rendering von Frame N durchführt und die andere Gruppe Betriebe zum Rendering von Frame N+1 durchführt. Innerhalb einer AFR-Gruppe kann das vorliegende Design geteiltes Framerendering- (SFR, Split Frame Rendering) verwenden, um 3D-Skalierung für ein Frame zu erzielen und dies würde Färbung von Zuweisungen zu Kacheln innerhalb der Gruppe begrenzen.
18A und 18B veranschaulichen färbige Zuweisung (verschiedene Schattierung), die mit einer Knotenmaske begrenzt ist, in Übereinstimmung mit einer Ausführungsform. Eine virtuelle Zuweisung 1800 für AFR-Gruppe A weist verschiedene Typen von Schattierung für verschiedene Farbzuweisungen über verschiedene Kacheln auf. Die virtuelle Zuweisung 1800 weist verschiedene Seiten A1, B1, A2, B2, A3, B3, A4, B4, A5, B5, A6 und B6 für AFR-Gruppe A auf.
Der Grafikprozessor 1850 weist Grafikvorrichtungen 1810, 1820, 1830 und 1840 (z.B. GPU 239, GPU 270, GPU 1980, Grafikengine-Kachel 310A-310D, Rechenengine-Kachel 340A-340D, Grafikverarbeitungsengine 410) und jeweiligen lokalen Speicher 1870, 1871, 1872 und 1873 (z.B. Hochbandbreitenspeicher, DRAM) für jede Grafikvorrichtung auf. Der Grafikprozessor 1850 weist Kommunikationslinks 1890-1894 (z.B. bidirektionale Hochgeschwindigkeitszwischenverbindungen, PCIe x 16) auf. Die AFR-Gruppe A weist Grafikvorrichtungen 1910 und 1930 auf. Die AFR-Gruppe B weist Grafikvorrichtung 1920 und 1940 auf.
Neuere Grafik-APIs stellen eine Heapkonstruktion bereit, die Anwendungen erlaubt, mehrere Ressourcen innerhalb eines Heaps zu platzieren. 19A veranschaulicht Platzierung von Ressourcen in einen Heap 1922, in Übereinstimmung mit einer Ausführungsform. Die Ressourcen 1920 weisen Textur 1920-1 und Puffer 1920-2 auf. Der Heap stellt eine Abstraktion an physischen Speicher zur Abbildung der Ressourcen in physischen Speicher bereit. Ressourcenplatzierung in Heaps kann andere Ressourcen überlappen, um Speicherwiederverwendung mit einem Streaming-Modell (transiente Daten) zu fördern. 19B veranschaulicht Abbildung eines Heaps, um Ressourcen farbige (schattierte) Zuweisungen von Grafikvorrichtungen (z.B. GPU 239, GPU 270, GPU 1980, Grafikengine-Kachel 310A-310D, Rechenengine-Kachel 340A-340D, Grafikverarbeitungsengine 410) eines Grafikprozessors zu platzieren, in Übereinstimmung mit einer Ausführungsform. Der Grafikprozessor 1900 weist Grafikvorrichtungen 1901-1904 und jeweiligen lokalen Speicher 1905-1908 (z.B. Hochbandbreitenspeicher, DRAM) auf. Der Grafikprozessor 1900 weist Kommunikationslinks 1910-1914 (z.B. bidirektionale Hochgeschwindigkeitszwischenverbindungen, PCIe x 16) auf.
Renderzielzuweisung
Während Renderingbetrieben wird es gewünscht, dass alle Renderzielschriebe zu lokalem Speicher einer GPU gehen, um beste Arbeitsleistung zu erzielen. Dafür ist das Renderziel in Gebiete partitioniert, die jede Kachel besitzt, oder ist mit dem Gebiet verknüpft. Zukünftige Hardware wird feinkörnigere Partitionierung unterstützen, wie Schachbrettrendering (CBR, Checkerboard Rendering), wo das Renderziel in kleine Kachelformen unterteilt ist, die beste Arbeitslastverteilungseigenschaften bereitstellen. In einem Beispiel für 4 Kacheln, macht sich das vorliegende Design geteilte Framerendering- (SFR) Techniken, wobei eine pro-Kachel-Schere genutzt wird, um ein Renderziel zu partitionieren, zu Nutze, wie in 20A und 20B veranschaulicht ist. Virtuelle Zuweisung 2000 weist 4 farbige (schattierte) Gebiete auf, die jeweils Seiten aufweisen. Jeder Satz von farbigen Seiten ist auf eine verschiedene Grafikvorrichtung abgebildet. In diesem Fall muss die Schere mit physischen Seitengrenzen über das Renderziel ausgerichtet werden, und Tiefenmatrizenpuffer und alle physischen Seiten für jedes Scherengebiet sollten der Grafikvorrichtung zugewiesen werden, die sie besitzt.
Der Grafikprozessor 2050 weist Grafikvorrichtungen 2051-2054 (z.B. GPU 239, GPU 270, GPU 1980, Grafikengine-Kachel 310A-310D, Rechenengine-Kachel 340A-340D, Grafikverarbeitungsengine 410) und jeweiligen lokalen Speicher 2070-2073 (z.B. Hochbandbreitenspeicher, DRAM) für jede Grafikvorrichtung auf. Der Grafikprozessor 2050 weist Kommunikationslinks 2090-2094 (z.B. bidirektionale Hochgeschwindigkeitszwischenverbindungen, PCIe x 16) auf.
Eine andere Strategie für geteilte Ressourcen, insbesondere wenn es viele geteilte Ressourcen gibt, auf die sich durch ausgeführte Aufgaben bezogen wird, ist, Ressourcenzuweisungen über den lokalen Speicher aller der teilnehmenden Kacheln zu verteilen. Diese Strategie ist ähnlich Seitenfärbung aber auf dem Ressourcenlevel und dieses Design gleicht die Arbeitslast durch gleichmäßige Streuung der Zahl von Fernzugriffen über alle der Kacheln aus.
Das vorliegende Design kann Software oder Hardware aufweisen, um Kommunikationslinknutzung zu überwachen und dann Ressourcen basierend auf der Kommunikationsnutzung dynamisch umzulegen. Die Ressourcen können zu lokalem Speicher einer Grafikvorrichtung umgelegt werden, die regelmäßig auf die Ressourcen zugreift.
Seitenmigration ist eine Technik, um Seiten zu Kacheln zu bewegen, die auf diese Seiten am regelmäßigsten zugreifen. In einem Beispiel weist Seitenmigration auf, dass die Software (z.B. KMD-Speicherverwalter, UMD, eine Anwendung) sich Speicherzugriffszähler ansieht und basierend auf diesen Speicherzugriffszählern die Seitentabellen dementsprechend aktualisiert und die Daten von einer physischen Seite zu einer anderen bewegt.
In einem anderen Beispiel wird Seitenmigration mit Seitenmigrationshardware 290 von 2C durchgeführt, die konfiguriert ist, Speicherzugriffsstatistiken für individuelle Ressourcen, Grafikvorrichtungen (z. B. GPUs, Grafikengine-Kacheln, Rechenkacheln) oder für Fabric-Nutzung zu überwachen. Die Hardware 290 migriert Daten oder Seiten zu lokalem Speicher einer Grafikvorrichtung, wenn angemessen (z.B. Grafik greift regelmäßig auf die Daten oder Seiten zu, Grafik greift regelmäßig greift gelegentlich auf die Daten oder Seiten zu). Die Seitenmigrationshardware 290 kann eine separate Hardwarekomponente oder in eine Speicherverwaltungseinheit (z.B. 251, 1320A, 1320B, 1942) integriert oder in GPU-Hardware 291, die eine Schnittstelle zwischen Multikerngruppen (z.B. 240A, 240B, 1965A, 1965B usw.) und der Speichersteuerung 248 ist, integriert sein. Die GPU-Hardware 291 handhabt Speicherbetriebe.
Der Speicherverwaltungsmechanismus des vorliegenden Designs ist in 4-Kachel-Architekturen für 15B, 16B, 17B, 18B, 19B und 20B veranschaulicht. Dieser Speicherverwaltungsmechanismus kann in einer beliebigen Multikachelarchitektur implementiert werden, die mindestens zwei Kacheln aufweist.
21A-21C veranschaulichen zusätzliche Grafikmultiprozessoren gemäß Ausführungsformen. 21A-21B veranschaulichen Grafikmultiprozessoren 1925, 1950. 21C veranschaulicht eine Grafikverarbeitungseinheit (GPU) 1980, die dedizierte Sätze von Grafikverarbeitungsressourcen in Multikerngruppen 1965A-1965N eingerichtet aufweist. Die veranschaulichten Grafikmultiprozessoren 1925, 1950 und die Multikerngruppen 1965A-1965N können Streamingmultiprozessor (SM) sein, der zur gleichzeitigen Ausführung einer großen Zahl von Ausführungsthreads im Stande ist.
21A zeigt einen Grafikmultiprozessor 1925 gemäß einer zusätzlichen Ausführungsform. Der Grafikmultiprozessor 1925 weist mehrere zusätzliche Instanzen von Ausführungsressourceneinheiten auf. Zum Beispiel kann der Grafikmultiprozessor 1925 mehrere Instanzen der Anweisungseinheit 1932A-1932B, Registerdatei 1934A-1934B und Textureinheit(en) 1944A-1944B aufweisen. Der Grafikmultiprozessor 1925 weist auch mehrere Sätze von Grafik- oder Rechenausführungseinheiten (z.B. GPGPU-Kern 1936A-1936B, Tensorkern 1937A-1937B, Raytracing-Kern 1938A-1938B) und mehrere Sätze von Lade-/Speichereinheiten 1940A-1940B auf. In einer Ausführungsform weisen die Ausführungsressourceneinheiten einen gemeinsamen Anweisungscache 1930, Textur- und/oder Datencachespeicher 1942 und geteilten Speicher 1946 auf.
Die unterschiedlichen Komponenten können über ein Zwischenverbindungsfabric 1927 kommunizieren. In einer Ausführungsform weist das Zwischenverbindungsfabric 1927 einen oder mehrere Kreuzschienenschalter auf, um Kommunikation zwischen den unterschiedlichen Komponenten des Grafikmultiprozessors 1925 zu ermöglichen. In einer Ausführungsform ist das Zwischenverbindungsfabric 1927 eine separate Hochgeschwindigkeitsnetzwerkfabric-Schicht, auf der jede Komponente des Grafikmultiprozessors 1925 gestapelt ist. Die Komponenten des Grafikmultiprozessors 1925 kommunizieren mit fernen Komponenten über das Zwischenverbindungsfabric 1927. Zum Beispiel können die GPGPU-Kerne 1936A-1936B, 1937A-1937B und 1938A-1938B jeweils mit geteiltem Speicher 1946 über das Zwischenverbindungsfabric 1927 kommunizieren. Das Zwischenverbindungsfabric 1927 kann Kommunikation innerhalb des Grafikmultiprozessors 1925 vermitteln, um eine gerechte Bandbreitenzuweisung zwischen Komponenten sicherzustellen.
21B zeigt einen Grafikmultiprozessor 1950 gemäß einer zusätzlichen Ausführungsform. Der Grafikprozessor weist mehrere Sätze von Ausführungsressourcen 1956A-1956D auf, wo jeder Satz von Ausführungsressource mehrere Anweisungseinheiten, Registerdateien, GPGPU-Kerne und Ladespeichereinheiten aufweist. Die Ausführungsressourcen 1956A-1956D können in Einklang mit Textureinheit(en) 1960A-1960D für Texturbetriebe arbeiten, während sie sich einen Anweisungscache 1954 und geteilten Speicher 1953 teilen. In einer Ausführungsform können sich die Ausführungsressourcen 1956A-1956D einen Anweisungscache 1954 und geteilten Speicher 1953, wie auch mehrere Instanzen eines Textur- und/oder Datencachespeichers 1958A-1958B teilen. Die unterschiedlichen Komponenten können über ein Zwischenverbindungsfabric 1952 ähnlich dem Zwischenverbindungsfabric 1927 von 21A kommunizieren.
Fachkundige werden verstehen, dass die Beschreibungen der Architektur in 21A-21C beschreibend und nicht den Umfang der vorliegenden Ausführungsformen begrenzend sind. Daher können die hierin beschriebenen Techniken auf einer beliebigen, geeignet konfigurierten Verarbeitungseinheit implementiert werden, aufweisend, ohne Begrenzung, einen oder mehrere mobile Anwendungsprozessoren, eine oder mehrere zentrale Verarbeitungseinheiten (CPUs) für Desktop- oder Server, aufweisend Multikern-CPUs, eine oder mehrere parallele Verarbeitungseinheiten, wie auch einen oder mehrere Grafikprozessoren oder Sonderzweckverarbeitungseinheiten, ohne von dem Umfang der hierin beschriebenen Ausführungsformen abzuweichen.
In manchen Ausführungsformen ist ein paralleler Prozessor oder eine GPGPU wie hierin beschrieben, kommunikativ mit Host-/Prozessorkernen gekoppelt, um Grafikbetriebe, Maschinenlernbetriebe, Strukturanalysebetriebe und unterschiedliche Allzweck-GPU- (GPGPU) Funktionen gekoppelt. Die GPU kann kommunikativ mit dem Host-Prozessor/den Host-Kernen über einen Bus oder eine andere Zwischenverbindung (z.B. eine Hochgeschwindigkeitszwischenverbindung, wie PCIe oder NVLink) gekoppelt sein. In anderen Ausführungsformen kann die GPU auf demselben Package oder Chip integriert sein wie die Kerne und kommunikativ mit den Kernen über einen internen Prozessorbus/eine Prozessorzwischenverbindung (z.B. intern vom Package oder Chip) gekoppelt sein. Ungeachtet der Weise, auf die die GPU verbunden ist, können die Prozessorkerne Arbeit zu der GPU in der Form von Abfolgen von Befehlen/Anweisungen zuweisen, die in einem Arbeitsbeschreiber enthalten sind. Die GPU verwendet dann dedizierte Schaltkreise/Logik zur effizienten Verarbeitung dieser Befehle/Anweisungen.
21C veranschaulicht eine Grafikverarbeitungseinheit (GPU) 1980, die dedizierte Sätze von Grafikverarbeitungsressourcen in Multikerngruppen 1965A-N eingerichtet aufweist. Während die Details von nur einer einzelnen Multikerngruppe 1965A bereitgestellt sind, wird begrüßt, dass die anderen Multikerngruppen 1965B-1965N mit denselben oder ähnlichen Sätzen von Grafikverarbeitungsressourcen ausgestattet sein können.
Wie veranschaulicht, kann eine Multikerngruppe 1965A einen Satz von Grafikkernen 1970, einen Satz von Tensorkernen 1971 und einen Satz von Raytracing-Kernen 1972 aufweisen. Jeder Kern kann Ausführungsschaltkreise aufweisen, die eine Gruppierung von Verarbeitungsressourcen aufweisen. Ein Einplaner/Dispatcher 1968 plant und lastet die Grafikthreads zur Ausführung auf den unterschiedlichen Kernen 1970, 1971, 1972 ein. Der Einplaner/Dispatcher 1968 kann Ausführungsschaltkreise aufweisen. Ein Satz von Registerdateien 1969 speichert Operandenwerte, die von den Kernen 1970, 1971, 1972 verwendet werden, wenn die Grafikthreads ausgeführt werden. Diese können zum Beispiel Ganzzahlregister zum Speichern von Ganzzahlwerten, Gleitkommaregister zum Speichern von Gleitkommawerten, Vektorregister zum Speichern von gepackten Datenelementen (Ganzzahl- und/oder Gleitkommadatenelemente) und Kachelregister zum Speichern von Tensor-/Matrixwerten aufweisen. In einer Ausführungsform sind die Kachelregister als kombinierte Sätze von Vektorregistern implementiert.
Ein oder mehrere kombinierte Level-1- (L1) Caches und geteilte Speichereinheiten 1973 speichern Grafikdaten, wie Texturdaten, Scheitelpunktdaten, Pixeldaten, Strahldaten, Begrenzungsvolumendaten usw., lokal innerhalb jeder Multikerngruppe 1965A. Eine oder mehrere Textureinheiten 1974 können auch verwendet werden, um Texturierungsbetriebe durchzuführen, wie Texturabbildung und -abtastung. Ein Level-2- (L2) Cache 1975, der von allen oder einem Teilsatz der Multikerngruppen 1965A-1965N geteilt wird, speichert Grafikdaten und/oder Anweisungen für mehrere gleichzeitige Grafikthreads. Wie veranschaulicht, kann der L2-Cache 1975 über mehrere Multikerngruppen 1965A-1965N geteilt werden. Eine oder mehrere Speichersteuerungen 1967 koppeln die GPU 1980 mit einem Speicher 1966, der ein Systemspeicher (z.B. DRAM) und/oder ein dedizierter Grafikspeicher (z.B. GDDR6-Speicher) sein kann.
Eingabe/Ausgabe- (I/O) Schaltkreise 1963 koppeln die GPU 1980 mit einer oder mehreren I/O-Vorrichtungen 1962, wie Digitalsignalprozessoren (DSPs), Netzwerksteuerungen oder Anwendereingabevorrichtungen. Eine Auf-dem-Chip-Zwischenverbindung kann verwendet werden, um die I/O-Vorrichtungen 1962 mit der GPU 1980 und Speicher 1966 zu koppeln. Eine oder mehrere I/O-Speicherverwaltungseinheiten (IOMMUs) 1964 der I/O-Schaltkreise 3195 koppeln die I/O-Vorrichtungen 1962 direkt mit dem Systemspeicher 1966. In einer Ausführungsform verwaltet die IOMMU 1964 mehrere Sätze von Seitentabellen, um virtuelle Adressen auf physische Adressen in Systemspeicher 1966 abzubilden. In dieser Ausführungsform können sich die I/O-Vorrichtungen 1962, CPU(s) 1961 und GPU(s) 1980 denselben virtuellen Adressraum teilen.
In einer Implementierung unterstützt die IOMMU 1964 Virtualisierung. In diesem Fall kann sie einen ersten Satz von Seitentabellen verwalten, um virtuelle Gast-/Grafikadressen auf physische Gast-/Grafikadressen abzubilden, und einen zweiten Satz von Seitentabellen, um die physischen Gast-/Grafikadressen auf physische System-/Host-Adressen (z.B. innerhalb von Systemspeicher 1966) abzubilden. Die Basisadressen sowohl des ersten als auch zweiten Satzes von Seitentabellen können in Steuerungsregistern gespeichert und bei einem Kontextwechsel ausgetauscht werden (z.B. derart, dass der neue Kontext mit Zugriff auf den relevanten Satz von Seitentabellen bereitgestellt ist). Während nicht in 21C veranschaulicht, können jeder der Kerne 1970, 1971, 1972 und/oder jede der Multikerngruppen 1965A-1965N Übersetzungsnachschlagepuffer (TLBs) aufweisen, um Gast-virtuell zu Gast-physisch Übersetzungen, Gast-physisch zu Host-physisch Übersetzungen und Gast-virtuell zu Host-physisch Übersetzungen zwischenzuspeichern.
In einer Ausführungsform sind die CPUs 1961, GPUs 1980 und I/O-Vorrichtungen 1962 auf einem einzelnen Halbleiterchip und/oder Chippackage integriert. Der veranschaulichte Speicher 1966 kann auf demselben Chip integriert sein oder kann mit den Speichersteuerungen 1967 über eine Schnittstelle außerhalb vom Chip gekoppelt sein. In einer Implementierung weist der Speicher 1966 GDDR6-Speicher auf, der sich denselben virtuellen Adressraum wie andere physische Systemlevelspeicher teilt, obwohl die zugrundeliegenden Prinzipien der Erfindung nicht auf diese bestimmte Implementierung begrenzt sind.
In einer Ausführungsform weisen die Tensorkerne 1971 mehrere Ausführungseinheiten auf, die insbesondere designt sind, um Matrixbetriebe durchzuführen, die der fundamentale Rechenbetrieb sind, der verwendet wird, um tiefe Lernbetriebe durchzuführen. Zum Beispiel können gleichzeitige Matrixmultiplikationsbetriebe für neurales Netzwerktraining und Schlussfolgerung verwendet werden. Die Tensorkerne 1971 können Matrixverarbeitung unter Verwendung einer Vielfalt von Operandenpräzisionen verwenden, aufweisend Einzelpräzisionsgleitkomma (z.B. 32 Bits), Halbpräzisionsgleitkomma (z.B. 16 Bits) Ganzzahlwort (16 Bits), Bytes (8 Bits) und Halbbytes (4 Bits). In einer Ausführungsform extrahiert eine neurale Netzwerkimplementierung Merkmale jeder gerenderten Szene, potenziell Details mehrerer Frames kombinierend, um ein hochqualitatives finales Bild zu erstellen.
In tiefen Lernimplementierungen kann parallele Multiplikationsarbeit zur Ausführung auf den Tensorkernen 1971 eingeplant werden. Das Training von neuralen Netzwerken benötigt insbesondere eine signifikante Zahl von Matrixskalarproduktbetrieben. Um eine Innenproduktformulierung einer N × N × N Matrixmultiplikation zu verarbeiten, können die Tensorkerne 1971 mindestens N Skalarproduktverarbeitungselemente aufweisen. Bevor die Matrixmultiplikation beginnt, wird eine gesamte Matrix in Kachelregister geladen und mindestens eine Spalte einer zweiten Matrix wird bei jedem Zyklus für N Zyklen geladen. Jeden Zyklus gibt es N Skalarprodukte, die verarbeitet werden.
Matrixelemente können bei unterschiedlichen Präzisionen gespeichert werden, abhängig von der bestimmten Implementierung, aufweisend 16-Bit Worte, 8-Bit Bytes (z.B. INT8) und 4-Bit Halbbytes (z.B. INT4). Verschiedene Präzisionsmodi können für die Tensorkerne 1971 bestimmt werden, um sicherzustellen, dass die effizienteste Präzision für verschiedene Arbeitslasten verwendet wird (z.B. wie schlussfolgern von Arbeitslasten, die Quantisierung zu Bytes und Halbbytes vertragen).
In einer Ausführungsform beschleunigen die Raytracingkerne 1972 Raytracingbetriebe für sowohl Echtzeitraytracing als auch Nicht-Echtzeitraytracing-Implementierungen. Insbesondere weisen die Raytracingkerne 1972 Strahlquerungs-/schnittschaltkreise zum Durchführen von Strahlquerung unter Verwendung von Begrenzungsvolumenhierarchien (BVHs) und Identifizieren von Schnittpunkten zwischen Strahlen und Primitiven, die innerhalb des BVH-Volumens umfasst sind, auf. Die Raytracingkerne 1972 können auch Schaltkreise zum Durchführen von Tiefentestung und Auslese aufweisen (z.B. unter Verwendung eines Z-Puffers oder einer ähnlichen Anordnung). In einer Implementierung führen die Raytracingkerne 1972 Querungs- und Schnittbetriebe im Einklang mit den hierin beschriebenen Bildentrauschtechniken aus, von welchen mindestens ein Abschnitt auf den Tensorkernen 1971 ausgeführt werden kann. Zum Beispiel implementieren in einer Ausführungsform die Tensorkerne 1971 ein neurales Netzwerk zum tiefen Lernen, um Entrauschen von Frames durchzuführen, die von den Raytracingkernen 1972 erzeugt werden. Jedoch können die CPU(s) 1961, Grafikkerne 1970 und/oder Raytracingkerne 1972 auch alles oder einen Abschnitt der Entrausch- und/oder tiefen Lernalgorithmen implementieren.
Zusätzlich kann, wie zuvor beschrieben, ein verteilter Ansatz zum Entrauschen eingesetzt werden, bei dem die GPU 1980 in einer Rechenvorrichtung ist, die mit anderen Rechenvorrichtungen über ein Netzwerk oder eine Hochgeschwindigkeitszwischenverbindung gekoppelt ist. In dieser Ausführungsform teilen sich die zwischenverbundenen Rechenvorrichtungen neurale Netzwerklern-/-trainingsdaten, um die Geschwindigkeit zu verbessern, mit der das gesamte System lernt, Entrauschen verschiedener Typen von Bildframes und/oder verschiedener Grafikanwendungen durchzuführen.
In einer Ausführungsform verarbeiten die Raytracingkerne 1972 alle BVH-Querungs- und Strahl-Primitiv-Schnitte, was die Grafikkerne 1970 davor schützt, mit tausenden von Anweisungen pro Strahl überladen zu werden. In einer Ausführungsform weist jeder Raytracingkern 1972 einen ersten Satz von spezialisierten Schaltkreisen zum Durchführen von Begrenzungsboxtests (z.B. für Querungsbetriebe) und einen zweiten Satz von spezialisierten Schaltkreisen zum Durchführen der Strahldreieckschnitttests (z.B. schneidende Strahlen, die gequert wurden) auf. Daher kann in einer Ausführungsform die Multikerngruppe 1965A einfach eine Strahlsonde starten und die Raytracingkerne 1972 unabhängig Strahlquerung und -schnitt durchführen und Trefferdaten (z.B. einen Treffer, keinen Treffer, mehrere Treffer usw.) zu dem Threadkontext durchführen. Die anderen Kerne 1970, 1971 werden freigemacht, um andere Grafik- oder Rechenarbeit durchzuführen, während die Raytracingkerne 1972 die Querungs- und Schnittbetriebe durchführen.
In einer Ausführungsform weist jeder Raytracingkern 1972 eine Querungseinheit, um BVH-Testbetriebe durchzuführen, und eine Schnitteinheit auf, die Strahl-Primitiv-Schnitttests durchführt. Die Schnitteinheit erzeugt eine „Treffer“, „kein Treffer“ oder „mehrere Treffer“-Antwort, die sie an den angemessenen Thread bereitstellt. Während der Querungs- und Schnittbetriebe werden die Ausführungsressourcen der anderen Kerne (z.B. Grafikkerne 1970 und Tensorkerne 1971) freigemacht, um andere Formen von Grafikarbeit durchzuführen.
In einer bestimmten, unten beschriebenen Ausführungsform wird ein Hybrid-Rasterisierungs-/Raytracing-Ansatz verwendet, in dem Arbeit zwischen den Grafikkernen 1970 und Raytracing-Kernen 1972 verteilt wird.
In einer Ausführungsform weisen die Raytracingkerne 1972 (und/oder andere Kerne 1970, 1971) Hardwareunterstützung für einen Raytracinganweisungssatz, wie Microsofts DirectX Ray Tracing (DXR) auf, der einen DispatchRays-Befehl aufweist, wie auch Strahlerzeugungs-, nächster-Hit-, beliebiger-Treffer- und Verfehlungsshader, die die Zuweisung eindeutiger Sätze von Shadern und Texturen für jedes Objekt ermöglichen. Eine andere Raytracingplattform, die von den Raytracingkernen 1972, Grafikkernen 1970 und Tensorkernen 1971 unterstützt wird, ist Vulkan 1.1.85. Man beachte jedoch, dass die zugrundeliegenden Prinzipien der Erfindung nicht auf irgendeine bestimmte Raytracing-ISA begrenzt sind.
Im Allgemeinen können die unterschiedlichen Kerne 1972, 1971, 1970 einen Raytracing-Anweisungssatz unterstützen, der Anweisungen/Funktionen für Strahlerzeugung, nächster Treffer, beliebiger Treffer, Strahl-Primitiv-Kreuzung, pro-Primitiv und hierarchische Begrenzungsboxerrichtung, Verfehlung, Aufsuchen und Ausnahmen aufweist. Genauer weist eine Ausführungsform Raytracing-Anweisungen auf, um die folgenden Funktionen durchzuführen:
Ray Generation - Strahlerzeugungsanweisungen können für jedes Pixel, jede Probe oder andere anwenderdefinierte Arbeitszuweisung ausgeführt werden.
Closest Hit - Eine nächster-Treffer-Anweisung kann ausgeführt werden, um den nächsten Kreuzungspunkt eines Strahls mit Primitiven innerhalb einer Szene zu lokalisieren.
Any Hit - Eine beliebiger-Treffer-Anweisung identifiziert mehrere Kreuzungen zwischen einem Strahl und Primitiven innerhalb einer Szene, potenziell, um einen neuen nächsten Kreuzungspunkt zu identifizieren.
Intersection - Eine Kreuzungsanweisung führt einen Strahl-Primitiv-Kreuzungstest durch und gibt ein Ergebnis aus.
Per-primitive Bounding box Construction - Diese Anweisung bildet eine Begrenzungsbox um ein gegebenes Primitiv oder Gruppen von Primitiven (z.B., wenn eine neue BVH oder andere Beschleunigungsdatenstruktur gebildet wird).
Miss - gibt an, dass ein Strahl die gesamte Geometrie innerhalb einer Szene oder ein bestimmtes Gebiet einer Szene verfehlt.
Visit - gibt die Untervolumina an, die ein Strahl queren wird.
Exceptions - weist unterschiedliche Typen von Ausnahmehandlern auf (z.B. für unterschiedliche Fehlerbedingungen aufgerufen).
Manche Ausführungsformen beziehen sich auf Beispiel 1, das einen Grafikprozessor aufweist, aufweisend eine erste Grafikvorrichtung, die einen lokalen Speicher aufweist, eine zweite Grafikvorrichtung, die einen lokalen Speicher aufweist, und einen Grafiktreiber, um eine einzelne virtuelle Anweisung mit einem gemeinsamen virtuellen Adressbereich bereitzustellen, um eine Ressource zu jedem lokalen Speicher der ersten und zweiten Grafikvorrichtungen zu spiegeln.
Beispiel 2 weist den Gegenstand von Beispiel 1 auf, wobei die einzelne virtuelle Zuweisung eine erste Seitentabelle für die erste Grafikvorrichtung und eine zweite Seitentabelle für die zweite Grafikvorrichtung aufweist, wobei die erste und zweite Seitentabelle einen vereinheitlichten physischen Adressraum bereitstellen.
Beispiel 3 weist den Gegenstand von einem beliebigen von Beispielen 1-2 auf, wobei die erste Grafikvorrichtung kommunikativ mit der zweiten Grafikvorrichtung gekoppelt ist und jede Grafikvorrichtung eine Grafikkachel der Multikachelarchitektur für einen Prozess aufweist.
Beispiel 4 weist den Gegenstand von einem der Beispiele 1-3 auf, wobei die einzelne virtuelle Zuweisung, um die Ressource zu spiegeln, physische Seiten für jeden lokalen Speicher der ersten und zweiten Grafikvorrichtung aufweist.
Beispiel 5 weist den Gegenstand von einem der Beispiele 1-4 auf, wobei die gespiegelte Ressource eine Nur-Lese-Ressource aufweist.
Beispiel 6 weist den Gegenstand von einem der Beispiele 1-5, auf, wobei die erste Grafikvorrichtung eine Grafikverarbeitungseinheit aufweist.
Beispiel 7 weist den Gegenstand von einem der Beispiele 1-6 auf, wobei der Grafiktreiber einen Kernelmodusgrafiktreiber aufweist.
Beispiel 8 weist den Gegenstand von einem der Beispiele 1-7 auf, weiter aufweisend einen Anwendermodusgrafiktreiber, um private Daten mit einer Zuweisungserzeugungsanfrage an den Kernelmodusgrafiktreiber bereitzustellen, um anzuzeigen, ob die Ressourcen zu spiegeln sind oder nicht, gemeinsam mit einer Knotenmaske, um anzuzeigen, welche Grafikvorrichtungen auf die Ressource zugreifen werden.
Manche Ausführungsformen beziehen sich auf Beispiel 9, das eine Grafikverarbeitungseinheit für eine Multikachelarchitektur aufweist, aufweisend eine erste Grafikvorrichtung, die einen lokalen Speicher aufweist, eine zweite Grafikvorrichtung, die einen lokalen Speicher aufweist, und einen Grafiktreiber, um eine einzelne virtuelle Zuweisung mit einem gemeinsamen virtuellen Adressbereich bereitzustellen, um physische Seiten einer geteilten Ressource mit lokalem Speicher der ersten und zweiten Grafikvorrichtung zu verschachteln.
Beispiel 10 weist den Gegenstand von Beispiel 9 auf, wobei die einzelne virtuelle Zuweisung eine erste physische Seite mit dem lokalen Speicher der ersten Grafikvorrichtung und eine zweite physische Seite mit dem lokalen Speicher der zweiten Grafikvorrichtung verschachtelt.
Beispiel 11 weist den Gegenstand von einem der Beispiele 9-10 auf, wobei die einzelne virtuelle Zuweisung einen ersten Teilsatz einer physischen Seite mit dem lokalen Speicher der ersten Grafikvorrichtung einen zweiten Teilsatz der physischen Seite mit dem lokalen Speicher der zweiten Grafikvorrichtung verschachtelt.
Beispiel 12 weist den Gegenstand von einem der Beispiele 9-11 auf, wobei die erste Grafikvorrichtung kommunikativ mit der zweiten Grafikvorrichtung gekoppelt ist.
Beispiel 13 weist den Gegenstand von einem der Beispiele 9-11 auf, wobei die geteilte Ressource einen geteilten Lese-/Schreibpuffer aufweist.
Beispiel 14 weist den Gegenstand von einem der Beispiele 9-13 auf, ferner eine dritte Grafikvorrichtung aufweisend, die einen lokalen Speicher aufweist, und eine vierte Grafikvorrichtung, die einen lokalen Speicher aufweist. Der Grafiktreiber weist einen Kernelmodusgrafiktreiber auf, um eine erste Gruppe, die die erste und dritte Grafikvorrichtung aufweist, zum Rendern von Frame N einer Anzeigevorrichtung, basierend auf einer Knotenmaske, zu bilden.
Beispiel 15 weist den Gegenstand von einem der Beispiele 9-14 auf, wobei der Kernelmodusgrafiktreiber dazu dient, eine zweite Gruppe, die die zweite und die vierte Grafiktreibervorrichtung aufweist, zum Rendern von Frame N+1 der Anzeigevorrichtung, basierend auf der Knotenmaske, zu bilden.
Beispiel 16 weist den Gegenstand von einem der Beispiele 9-15 auf, wobei die erste Grafikvorrichtung eine Grafikkachel der Multikachelhierarchie aufweist.
Beispiel 17 weist den Gegenstand von einem der Beispiele 9-16 auf, wobei die einzelne virtuelle Zuweisung mit einem gemeinsamen virtuellen Adressbereich dazu dient, ein Renderziel auf einer Pro-Grafikvorrichtung-Basis zu partitionieren.
Beispiel 18 weist den Gegenstand von einem der Beispiele 9-17 auf, wobei die einzelne virtuelle Zuweisung dazu dient, eine erste Seite des Renderziels zu dem lokalen Speicher der ersten Grafikvorrichtung zuzuweisen und eine zweite Seite des Renderziels zu dem lokalen Speicher der zweiten Grafikvorrichtung zuzuweisen.
Manche Ausführungsformen beziehen sich auf Beispiel 19, das einen Grafikprozessor für eine Multikachelarchitektur aufweist, aufweisend eine erste Grafikvorrichtung, die einen lokalen Speicher aufweist, eine zweite Grafikvorrichtung, die einen lokalen Speicher aufweist, und einen Grafiktreiber, um einen Heap mit einem gemeinsamen virtuellen Adressbereich zur Abbildung virtueller Adressen von mindestens einer Ressource in den Heap bereitzustellen und die mindestens eine Ressource in lokalen Speicher der ersten und zweiten Grafikvorrichtung zu verschachteln.
Beispiel 20 weist den Gegenstand von Beispiel 19 auf, wobei der Heap eine erste physische Seite mit dem lokalen Speicher der ersten Grafikvorrichtung und eine zweite physische Seite mit dem lokalen Speicher der zweiten Grafikvorrichtung verschachtelt.
Beispiel 21 weist den Gegenstand von einem der Beispiele 19-20 auf, wobei der Heap einen ersten Teilsatz einer physischen Seite mit dem lokalen Speicher der ersten Grafikvorrichtung und einen zweiten Teilsatz der physischen Seite mit dem lokalen Speicher der zweiten Grafikvorrichtung verschachtelt.
Beispiel 22 weist den Gegenstand von einem der Beispiele 19-21 auf, wobei die mindestens eine Ressource eine erste Ressource, die eine Textur aufweist, und eine zweite Ressource, die einen Puffer aufweist, aufweist.
Manche Ausführungsform bezieht sich auf Beispiel 23, das einen Grafikprozessor aufweist, aufweisend eine erste Grafikvorrichtung, die einen lokalen Speicher aufweist, eine zweite Grafikvorrichtung, die einen lokalen Speicher aufweist, einen Kommunikationslink, um die erste und zweite Grafikvorrichtung zu koppeln, und eine Speicherverwaltungseinheit, die konfiguriert ist, eine einzelne virtuelle Zuweisung mit einem gemeinsamen virtuellen Adressbereich zu nutzen, um eine Ressource zu spiegeln oder physische Seiten der Ressource mit dem lokalen Speicher der ersten und zweiten Grafikvorrichtung zu verschachteln.
Beispiel 24 weist den Gegenstand von Beispiel 23 auf, wobei die Speicherverwaltungseinheit ferner mit einem Überwachungsmerkmal konfiguriert ist, um Zugriffe auf den Kommunikationslink, den lokalen Speicher der ersten Grafikvorrichtung, den lokalen Speicher der zweiten Grafikvorrichtung zu überwachen, um Daten von Ressourcen zu der ersten und zweiten Grafikvorrichtung zuzuweisen und Zuweisung der Daten zu der ersten und zweiten Grafikvorrichtung basierend auf dem Überwachungsmerkmal zu ändern.
Beispiel 25 weist den Gegenstand von einem der Beispiele 23-24 auf, wobei die einzelne virtuelle Zuweisung eine erste physische Seite mit dem lokalen Speicher der ersten Grafikvorrichtung und eine zweite physische Seite mit dem lokalen Speicher der zweiten Grafikvorrichtung verschachtelt.
Die vorangehende Beschreibung und die Zeichnungen sind eher veranschaulichend als in einem eingrenzenden Sinn anzusehen. Fachkundige werden verstehen, dass unterschiedliche Modifikationen und Änderungen an den hierin beschriebenen Ausführungsformen vorgenommen werden können, ohne von dem weiteren Wesen und Umfang der Erfindung abzuweichen, wie sie in den angehängten Ansprüchen vorgelegt wird.

Claims

Grafikprozessor für eine Multikachelarchitektur, aufweisend: eine erste Grafikvorrichtung, die einen lokalen Speicher aufweist; eine zweite Grafikvorrichtung, die einen lokalen Speicher aufweist; und einen Grafiktreiber, um eine einzelne virtuelle Zuweisung mit einem gemeinsamen virtuellen Adressbereich bereitzustellen, um eine Ressource zu jedem lokalen Speicher der ersten und zweiten Grafikvorrichtung zu spiegeln.
Grafikprozessor nach Anspruch 1, wobei die einzelne virtuelle Zuweisung eine erste Seitentabelle für die erste Grafikvorrichtung und eine zweite Seitentabelle für die zweite Grafikvorrichtung aufweist, wobei die erste und zweite Seitentabelle einen vereinheitlichten physischen Adressraum bereitstellen.
Grafikprozessor nach Anspruch 1 oder 2, wobei die erste Grafikvorrichtung kommunikativ mit der zweiten Grafikvorrichtung gekoppelt ist und jede Grafikvorrichtung eine Grafikkachel der Multikachelarchitektur für einen Prozess aufweist.
Grafikprozessor nach einem der vorstehenden Ansprüche, wobei die einzelne virtuelle Zuweisung dazu dient, die Ressource zu spiegeln, aufweisend physische Seiten für jeden lokalen Speicher der ersten und zweiten Grafikvorrichtung.
Grafikprozessor nach einem der vorstehenden Ansprüche, wobei die gespiegelte Ressource eine Nur-Lese-Ressource aufweist.
Grafikprozessor nach einem der vorstehenden Ansprüche, wobei die erste Grafikvorrichtung eine Grafikverarbeitungseinheit aufweist.
Grafikprozessor nach Anspruch 1, wobei der Grafiktreiber einen Kernelmodusgrafiktreiber aufweist.
Grafikprozessor nach Anspruch 7, weiter aufweisend: einen Anwendermodusgrafiktreiber, um private Daten mit einer Anweisungserzeugungsanfrage an den Kernelmodusgrafiktreiber bereitzustellen, um anzuzeigen, ob die Ressourcen zu spiegeln sind oder nicht, gemeinsam mit einer Knotenmaske, um anzuzeigen, welche Grafikvorrichtungen auf die Ressource zugreifen werden.
Grafikprozessor für eine Multikachelarchitektur, aufweisend: eine erste Grafikvorrichtung, die einen lokalen Speicher aufweist; eine zweite Grafikvorrichtung, die einen lokalen Speicher aufweist; und einen Grafiktreiber, um eine einzelne virtuelle Zuweisung mit einem gemeinsamen virtuellen Adressbereich bereitzustellen, um physische Seiten einer geteilten Ressource mit lokalem Speicher der ersten und zweiten Grafikvorrichtung zu verschachteln.
Grafikprozessor nach Anspruch 9, wobei die einzelne virtuelle Zuweisung eine erste physische Seite mit dem lokalen Speicher der ersten Grafikvorrichtung und eine zweite physische Seite mit dem lokalen Speicher der zweiten Grafikvorrichtung verschachtelt.
Grafikprozessor nach Anspruch 9, wobei die einzelne virtuelle Zuweisung einen ersten Teilsatz einer physischen Seite mit dem lokalen Speicher der ersten Grafikvorrichtung und einen zweiten Teilsatz der physischen Seite mit dem lokalen Speicher der zweiten Grafikvorrichtung verschachtelt.
Grafikprozessor nach einem der vorstehenden Ansprüche, wobei die erste Grafikvorrichtung kommunikativ mit der zweiten Grafikvorrichtung gekoppelt ist.
Grafikprozessor nach einem der vorstehenden Ansprüche, wobei die geteilte Ressource einen geteilten Lese-/Schreibpuffer aufweist.
Grafikprozessor nach einem der vorstehenden Ansprüche, ferner aufweisend: eine dritte Grafikvorrichtung, die einen lokalen Speicher aufweist; und eine vierte Grafikvorrichtung, die einen lokalen Speicher aufweist, wobei der Grafiktreiber einen Kernelmodusgrafiktreiber aufweist, um eine erste Gruppe, die die erste und dritte Grafikvorrichtung aufweist, zum Rendern von Frame N einer Anzeigevorrichtung, basierend auf einer Knotenmaske, zu bilden.
Grafikprozessor nach Anspruch 14, wobei der Kernelmodusgrafiktreiber dazu dient, eine zweite Gruppe, die die zweite und die vierte Grafikvorrichtung aufweist, zum Rendern von Frame N+1 der Anzeigevorrichtung, basierend auf der Knotenmaske, zu bilden.
Grafikprozessor nach einem der vorstehenden Ansprüche, wobei die erste Grafikvorrichtung eine Grafikkachel der Multikachelhierarchie aufweist.
Grafikprozessor nach Anspruch 9, wobei die einzelne virtuelle Zuweisung mit einem gemeinsamen virtuellen Adressbereich dazu dient, ein Renderziel auf einer Pro-Grafikvorrichtung-Basis zu partitionieren.
Grafikprozessor nach Anspruch 17, wobei die einzelne virtuelle Zuweisung dazu dient, eine erste Seite des Renderziels zu dem lokalen Speicher der ersten Grafikvorrichtung zuzuweisen und eine zweite Seite des Renderziels zu dem lokalen Speicher der zweiten Grafikvorrichtung zuzuweisen.
Grafikprozessor für eine Multikachelarchitektur, aufweisend: eine erste Grafikvorrichtung, die einen lokalen Speicher aufweist; eine zweite Grafikvorrichtung, die einen lokalen Speicher aufweist; und einen Grafiktreiber, um einen Heap mit einem gemeinsamen virtuellen Adressbereich zur Abbildung virtueller Adressen von mindestens einer Ressource in den Heap bereitzustellen und die mindestens eine Ressource in lokalen Speicher der ersten und zweiten Grafikvorrichtung zu verschachteln.
Grafikprozessor nach Anspruch 19, wobei der Heap eine erste physische Seite mit dem lokalen Speicher der ersten Grafikvorrichtung und eine zweite physische Seite mit dem lokalen Speicher der zweiten Grafikvorrichtung verschachtelt.
Grafikprozessor nach Anspruch 19, wobei der Heap einen ersten Teilsatz einer physischen Seite mit dem lokalen Speicher der ersten Grafikvorrichtung und einen zweiten Teilsatz der physischen Seite mit dem lokalen Speicher der zweiten Grafikvorrichtung verschachtelt.
Grafikprozessor nach einem der vorstehenden Ansprüche, wobei die mindestens eine Ressource eine erste Ressource, die eine Textur aufweist, und eine zweite Ressource, die einen Puffer aufweist, aufweist.
Grafikprozessor, aufweisend: eine erste Grafikvorrichtung, die einen lokalen Speicher aufweist; eine zweite Grafikvorrichtung, die einen lokalen Speicher aufweist; einen Kommunikationslink, um die erste und zweite Grafikvorrichtung zu koppeln; und eine Speicherverwaltungseinheit, die konfiguriert ist, eine einzelne virtuelle Zuweisung mit einem gemeinsamen virtuellen Adressbereich zu nutzen, um eine Ressource zu spiegeln oder physische Seiten der Ressource mit dem lokalen Speicher der ersten und zweiten Grafikvorrichtung zu verschachteln.
Grafikprozessor nach Anspruch 23, wobei die Speicherverwaltungseinheit ferner mit einem Überwachungsmerkmal konfiguriert ist, um Zugriffe auf den Kommunikationslink, den lokalen Speicher der ersten Grafikvorrichtung, den lokalen Speicher der zweiten Grafikvorrichtung zu überwachen, um Daten von Ressourcen zu der ersten und zweiten Grafikvorrichtung zuzuweisen und Zuweisung der Daten zu der ersten und zweiten Grafikvorrichtung basierend auf dem Überwachungsmerkmal zu ändern.
Grafikprozessor nach Anspruch 23, wobei die einzelne virtuelle Zuweisung eine erste physische Seite mit dem lokalen Speicher der ersten Grafikvorrichtung und eine zweite physische Seite mit dem lokalen Speicher der zweiten Grafikvorrichtung verschachtelt.