DE102020130847A1

DE102020130847A1 - Dynamischer aktualisierungsmechanismus für konstanten

Info

Publication number: DE102020130847A1
Application number: DE102020130847.7A
Authority: DE
Inventors: Michael Apodaca; John Feit; David Cimini; Thomas Raoux; Konstantin Levit-Gurevich
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2019-12-23
Filing date: 2020-11-23
Publication date: 2021-06-24
Also published as: US20210225062A1; US11461954B2; US10997772B1; CN113095996A

Abstract

Eine Einrichtung zum Ermöglichen einer Aktualisierung von Shader-Datenkonstanten. Die Einrichtung enthält einen oder mehrere Prozessoren, um eine Änderung an einer oder mehreren Datenkonstanten in einem Shaderprogramm zu erkennen, einen Mikrocodeblock, der aktualisierte Konstantendaten enthält, während einer Ausführung des Shaderprogramms zu generieren und den Mikrocodeblock an das Shaderprogramm zu senden.

Description

HINTERGRUND DER BESCHREIBUNG
Grafikverarbeitungseinheiten (GPUs) werden oft verwendet, um Grafikanwendungen auszuführen, die programmierbare Shader enthalten, um verschiedene Shadingalgorithmen zu implementieren. Diese Shader werden von Treibern in Maschinencode compiliert, um einen Rechenkernel (oder Kernel) zu generieren, der auf eine bestimmte Plattform abzielt. Diese Compilierung ist jedoch rechnerisch aufwendig und findet üblicherweise während einer Szeneninitialisierung statt. Wenn der compilierte Kernel später ausgeführt wird, kann es aktualisierte Daten geben, die der Treiber oder die Anwendung möglicherweise an den Kernel weiterleiten muss, um ein Verhalten zu ändern (z. B. um dem Shader eine dynamische Eingabe bereitzustellen). Herkömmliche Mechanismen stellen eine dynamische Eingabe durch Neucompilieren des Kernels mit den Daten bereit. Derartige Lösungen sind jedoch mit Nachteilen in der Zentralverarbeitungseinheit (CPU) (z. B. Nachverfolgung, Neucompilierung) und GPU (z. B. Anweisungszwischenspeicher-Fehlzugriffe) verbunden.
Figurenliste
Damit die Art und Weise, in der die oben genannten Merkmale der vorliegenden Erfindung im Detail verstanden werden können, kann eine detailliertere Beschreibung der Erfindung, die oben kurz zusammengefasst wurde, durch Bezugnahme auf Ausführungsformen erhalten werden, von denen einige in den beigefügten Zeichnungen veranschaulicht sind. Es ist jedoch anzumerken, dass die beigefügten Zeichnungen nur typische Ausführungsformen dieser Erfindung veranschaulichen und deshalb den Geltungsbereich nicht einschränken sollen, da die Erfindung andere gleichermaßen wirksame Ausführungsformen erlauben kann.

1 ist ein Blockdiagramm eines Verarbeitungssystems nach einer Ausführungsform;
2A-2D veranschaulichen Rechensysteme und Grafikprozessoren, die von hierin beschriebenen Ausführungsformen bereitgestellt werden;
3A-3C veranschaulichen Blockdiagramme von zusätzlichen Grafikprozessor- und Rechenbeschleunigerarchitekturen, die von Ausführungsformen bereitgestellt werden;
4 ist ein Blockdiagramm einer Grafikverarbeitungsengine eines Grafikprozessors in Übereinstimmung mit einigen Ausführungsformen;
5A-5B veranschaulichen eine Threadausführungslogik 500, die eine Anordnung von Verarbeitungselementen enthält, die in einem Grafikprozessorkern nach Ausführungsformen eingesetzt wird;
6 veranschaulicht eine zusätzliche Ausführungseinheit 600 nach einer Ausführungsform;
7 ist ein Blockdiagramm, das ein Grafikprozessoranweisungsformat nach einigen Ausführungsformen veranschaulicht;
8 ist ein Blockdiagramm eines Grafikprozessors nach einer anderen Ausführungsform;
9A und 9B veranschaulichen ein Grafikprozessor-Befehlsformat und eine Befehlsfolge nach einigen Ausführungsformen;
10 veranschaulicht eine beispielhafte Grafiksoftwarearchitektur für ein Datenverarbeitungssystem nach einigen Ausführungsformen;
11A-11D veranschaulichen eine integrierte Schaltkreispaketanordnung nach einer Ausführungsform;
12 ist ein Blockdiagramm, das einen beispielhaften integrierten Ein-Chip-System-Schaltkreis nach einer Ausführungsform veranschaulicht;
13A und 13B sind ein Blockdiagramm, das einen zusätzlichen beispielhaften Grafikprozessor veranschaulicht;
14 veranschaulicht eine Ausführungsform einer Rechenvorrichtung, die einen dynamischen Aktualisierungsmechanismus einsetzt;
15 veranschaulicht eine Ausführungsform eines Kernelheaps;
16 veranschaulicht eine Ausführungsform einer Konstantenänderung; und
17 ist ein Ablaufdiagramm, das eine Ausführungsform eines Prozesses zum Durchführen einer dynamischen Aktualisierung veranschaulicht.

AUSFÜHRLICHE BESCHREIBUNG
In der folgenden detaillierten Beschreibung werden zahlreiche spezifische Details dargelegt, um ein gründlicheres Verständnis der vorliegenden Erfindung zu vermitteln. Es wird jedoch Fachleuten klar sein, dass die vorliegende Erfindung ohne eines oder mehrere dieser spezifischen Details ausgebildet werden kann. In anderen Fällen wurden wohlbekannte Merkmale nicht beschrieben, um zu vermeiden, dass die vorliegende Erfindung verschleiert wird.
In Ausführungsformen werden aktualisierte Konstanten in einem Mikrocodeblock während einer Ausführung eines Shaderprogramms nach einer Ermittlung eingebettet, dass es aktualisierte Daten gibt. In einer weiteren Ausführungsform wird der Mikrocodeblock an das Shaderprogramm mit einer Sprunganweisung gestreamt und ausgeführt, um die aktualisierten Konstanten im Shaderprogramm zu implementieren.
Systemüberblick
1 ist ein Blockdiagramm eines Verarbeitungssystems 100 nach einer Ausführungsform. Das System 100 kann in einem Einzelprozessor-Desktopsystem, einem Mehrprozessor-Arbeitsplatzsystem oder einem Serversystem mit einer großen Anzahl von Prozessoren 102 oder Prozessorkernen 107 verwendet werden. In einer Ausführungsform ist das System 100 eine Verarbeitungsplattform, die in einen integrierten Ein-Chip-System-Schaltkreis (SoC-Schaltkreis) zur Verwendung in mobilen, tragbaren oder eingebetteten Vorrichtungen, wie zum Beispiel in Internet-der-Dinge(IdD)-Vorrichtungen mit verkabelter oder kabelloser Konnektivität mit einem lokalen oder Weitverkehrsnetz, eingebunden ist.
In einer Ausführungsform kann das System 100 enthalten, koppeln mit oder integriert sein in: einer serverbasierten Gamingplattform; einer Spielekonsole, einschließlich einer Spiele- und Medienkonsole; einer mobilen Gamingkonsole, einer tragbaren Spielekonsole oder einer Online-Spielekonsole. In einigen Ausführungsformen ist das System 100 ein Teil eines Mobiltelefons, Smartphones, einer Tablet-Rechenvorrichtung oder mobilen, mit dem Internet verbundenen Vorrichtung, wie eines Laptops mit geringer interner Speicherkapazität. Das Verarbeitungssystem 100 kann auch eine tragbare Vorrichtung enthalten, an eine solche koppeln oder in eine solche integriert sein, wie eine tragbare Smartwatch-Vorrichtung; Smart-Brillen oder Kleidung, die mit Funktionen erweiterter Realität (AR) oder virtueller Realität (VR) erweitert ist bzw. sind, um visuelle, Audio- oder taktile Ausgaben bereitzustellen, um reale visuelle, Audio- oder taktile Erfahrungen zu ergänzen oder anderweitig Text, Audio, Grafik, Video, holografische Bilder oder holografisches Video oder eine taktile Rückmeldung bereitzustellen; eine andere Vorrichtung für erweiterte Realität (AR); oder eine andere Vorrichtung für virtuelle Realität (VR). In einigen Ausführungsformen enthält das Verarbeitungssystem 100 einen Fernseher oder eine Set-Top-Box-Vorrichtung oder ist Teil dieses bzw. dieser. In einer Ausführungsform kann das System 100 enthalten, koppeln mit oder integriert sein in ein selbstfahrendes Fahrzeug, wie einem Bus, Traktoranhänger, Auto, Motorrad oder elektrisch angetriebenen Fahrrad, einem Flugzeug oder Gleitflieger (oder einer beliebigen Kombination daraus). Das selbstfahrende Fahrzeug kann das System 100 verwenden, um die um das Fahrzeug herum erfasste Umgebung zu verarbeiten.
In einigen Ausführungsformen enthalten der eine oder die mehreren Prozessoren 102 jeweils einen oder mehrere Prozessorkerne 107, um Anweisungen zu verarbeiten, die bei Ausführung Operationen für System- oder Benutzersoftware durchführen. In einigen Ausführungsformen ist mindestens einer des einen oder der mehreren Prozessorkerne 107 ausgelegt, einen bestimmten Anweisungssatz 109 zu verarbeiten. In einigen Ausführungsformen kann der Anweisungssatz 109 ein Rechnen mit komplexem Anweisungssatz (CISC), ein Rechnen mit reduziertem Anweisungssatz (RISC) oder ein Rechnen über ein Very Long Instruction Word (VLIW) ermöglichen. Ein oder mehrere Prozessorkerne 107 können einen anderen Anweisungssatz 109 verarbeiten, der Anweisungen enthalten kann, um die Emulation anderer Anweisungssätze zu ermöglichen. Der Prozessorkern 107 kann auch andere Verarbeitungsvorrichtungen wie einen digitalen Signalprozessor (DSP) enthalten.
In einigen Ausführungsformen enthält der Prozessor 102 einen Zwischenspeicher 104. Abhängig von der Architektur kann der Prozessor 102 einen einzelnen internen Zwischenspeicher oder mehrere Ebenen von internen Zwischenspeichern aufweisen. In einigen Ausführungsformen wird der Zwischenspeicher unter verschiedenen Komponenten des Prozessors 102 gemeinsam genutzt. In einigen Ausführungsformen verwendet der Prozessor 102 auch einen externen Zwischenspeicher (z. B. einen Level-3(L3)-Zwischenspeicher oder einen Last-Level-Zwischenspeicher (LLC)) (nicht gezeigt), der von den Prozessorkernen 107 unter Verwendung bekannter Zwischenspeicherkohärenztechniken gemeinsam genutzt werden kann. Eine Registerdatei 106 kann zusätzlich im Prozessor 102 enthalten sein und kann unterschiedliche Arten von Registern zum Speichern unterschiedlicher Datentypen enthalten (z. B. Ganzzahlregister, Gleitkommaregister, Statusregister und ein Anweisungszeigerregister). Einige Register können Universalregister sein, während andere Register für das Design des Prozessors 102 spezifisch sein können.
In einigen Ausführungsformen ist bzw. sind ein oder mehrere Prozessor(en) 102 an einen oder mehrere Schnittstellenbusse 110 gekoppelt, um Kommunikationssignale wie Adressen, Daten oder Steuersignale zwischen dem Prozessor 102 und anderen Komponenten im System 100 zu übertragen. Der Schnittstellenbus 110 kann in einer Ausführungsform ein Prozessorbus, zum Beispiel eine Version des Direct-Media-Interface(DMI)-Busses sein. Prozessorbusse sind jedoch nicht auf den DMI-Bus beschränkt und können einen oder mehrere Peripheral-Component-Interconnect-Busse (z. B. PCI, PCI Express), Arbeitsspeicherbusse oder andere Arten von Schnittstellenbussen enthalten. In einer Ausführungsform enthält bzw. enthalten der Prozessor bzw. die Prozessoren 102 eine integrierte Arbeitsspeichersteuerung 116 und einen Plattformsteuerungshub 130. Die Arbeitsspeichersteuerung 116 ermöglicht eine Kommunikation zwischen einer Arbeitsspeichervorrichtung und anderen Komponenten des Systems 100, während der Plattformsteuerungshub (PCH) 130 Verbindungen mit E/A-Vorrichtungen über einen lokalen E/A-Bus bereitstellt.
Die Arbeitsspeichervorrichtung 120 kann eine dynamische Arbeitsspeichervorrichtung mit wahlfreiem Zugriff (DRAM-Vorrichtung), eine statische Arbeitsspeichervorrichtung mit wahlfreiem Zugriff (SRAM-Vorrichtung), eine Flashspeichervorrichtung, eine Phasenwechselspeichervorrichtung oder eine andere Arbeitsspeichervorrichtung mit geeigneter Leistung sein, um als Prozessarbeitsspeicher zu dienen. In einer Ausführungsform kann die Arbeitsspeichervorrichtung 120 als Systemarbeitsspeicher für das System 100 arbeiten, um Daten 122 und Anweisungen 121 zur Verwendung speichern, wenn der eine oder die mehreren Prozessoren 102 eine Anwendung oder einen Prozess ausführen. Die Arbeitsspeichersteuerung 116 koppelt auch an einen optionalen externen Grafikprozessor 118, der mit dem einen oder den mehreren Grafikprozessoren 108 in den Prozessoren 102 kommunizieren kann, um Grafik- und Medienoperationen durchzuführen. In einigen Ausführungsformen können Grafik-, Medien- oder Rechenoperationen durch einen Beschleuniger 112 unterstützt werden, der ein Coprozessor ist, der ausgelegt sein kann, um einen Sondersatz von Grafik-, Medien- oder Rechenoperationen durchzuführen. In einer Ausführungsform ist der Beschleuniger 112 zum Beispiel ein Matrixmultiplikations-Beschleuniger, der verwendet wird, um maschinelles Lernen oder Rechenoperationen zu optimieren. In einer Ausführungsform ist der Beschleuniger 112 ein Raytracing-Beschleuniger, der verwendet werden kann, um zusammen mit dem Grafikprozessor 108 Raytracing-Operationen durchzuführen. In einer Ausführungsform kann ein externer Beschleuniger 119 anstelle des Beschleunigers 112 oder zusammen mit diesem verwendet werden.
In einigen Ausführungsformen kann eine Anzeigevorrichtung 111 an den bzw. die Prozessor(en) 102 anbinden. Die Anzeigevorrichtung 111 kann eine oder mehrere von einer internen Anzeigevorrichtung, wie zum Beispiel in einer mobilen elektronischen Vorrichtung oder einer Laptopvorrichtung, oder eine externe Anzeigevorrichtung sein, die über eine Anzeigeschnittstelle (z. B. DisplayPort usw.) angebunden ist. In einer Ausführungsform kann die Anzeigevorrichtung 111 eine am Kopf montierte Anzeige (HMD) wie eine stereoskopische Anzeigevorrichtung zur Verwendung in Anwendungen mit virtueller Realität (VR) oder Anwendungen mit erweiterter Realität (AR) sein.
In einigen Ausführungsformen ermöglicht der Plattformsteuerungshub 130, dass Peripherieeinrichtungen über einen Hochgeschwindigkeits-E/A-Bus an die Arbeitsspeichervorrichtung 120 und den Prozessor 102 anbinden. Die E/A-Peripherieeinrichtungen enthalten unter anderem eine Audiosteuerung 146, eine Netzwerksteuerung 134, eine Firmwareschnittstelle 128, einen drahtlosen Sende-Empfänger 126, Berührungssensoren 125, eine Datenspeichervorrichtung 124 (z. B. nichtflüchtigen Arbeitsspeicher, flüchtigen Arbeitsspeicher, ein Festplattenlaufwerk, Flashspeicher, 3D NAND, 3D XPoint usw.). Die Datenspeichervorrichtung 124 kann über eine Speicherschnittstelle (z. B. SATA) oder über einen peripheren Bus, wie einen Peripheral-Component-Interconnect-Bus (z. B. PCI, PCI Express) verbunden sein. Die Berührungssensoren 125 können Berührungsbildschirmsensoren, Drucksensoren oder Fingerabdrucksensoren enthalten. Der drahtlose Sende-Empfänger 126 kann ein WiFi-Sende-Empfänger, ein Bluetooth-Sende-Empfänger oder ein Sende-Empfänger für mobile Netzwerke sein, wie ein 3G-, 4G-, 5G- oder Long-Term-Evolution(LTE)-Sende-Empfänger. Die Firmwareschnittstelle 128 ermöglicht eine Kommunikation mit Systemfirmware und kann beispielsweise eine vereinheitlichte erweiterbare Firmwareschnittstelle (UEFI) sein. Die Netzwerksteuerung 134 kann eine Netzwerkverbindung mit einem verdrahteten Netzwerk ermöglichen. In einigen Ausführungsformen koppelt eine Hochleistungsnetzwerksteuerung (nicht gezeigt) an den Schnittstellenbus 110. Die Audiosteuerung 146 ist in einer Ausführungsform eine hochauflösende Mehrkanal-Audiosteuerung. In einer Ausführungsform enthält das System 100 eine optionale Vorgänger-E/A-Steuerung 140, um Vorgänger-Vorrichtungen (z. B. Personal System 2 (PS/2) an das System zu koppeln. Der Plattformsteuerungshub 130 kann auch an eine oder mehrere Universal-Serial-Bus(USB)-Steuerungen 142 anbinden, um Eingabevorrichtungen wie Tastatur- und Mauskombinationen 143, eine Kamera 144 oder andere USB-Eingabevorrichtungen anzubinden.
Es ist klar, dass das gezeigte System 100 beispielhaft und nicht einschränkend ist, da andere Arten von Datenverarbeitungssystemen, die unterschiedlich konfiguriert sind, ebenfalls verwendet werden können. Eine Instanz der Arbeitsspeichersteuerung 116 und des Plattformsteuerungshubs 130 kann zum Beispiel in einen diskreten externen Grafikprozessor, wie den externen Grafikprozessor 118 integriert sein. In einer Ausführungsform können der Plattformsteuerungshub 130 und/oder die Arbeitsspeichersteuerung 116 zum einen oder zu den mehreren Prozessoren 102 extern sein. Das System 100 kann zum Beispiel eine externe Arbeitsspeichersteuerung 116 und einen externen Plattformsteuerungshub 130 enthalten, die als ein Arbeitsspeichersteuerungshub und ein peripherer Steuerungshub innerhalb eines Systemchipsatzes konfiguriert sein können, der in Kommunikation mit den Prozessoren 102 steht.
Beispielsweise können Leiterplatten („Schlitten“) verwendet werden, auf denen Komponenten wie CPUs, Arbeitsspeicher und andere Komponenten platziert sind und die für erhöhte Wärmeleistung konstruiert sind. In einigen Beispielen befinden sich Verarbeitungskomponenten wie die Prozessoren auf einer Oberseite eines Schlittens, wohingegen naher Arbeitsspeicher, wie DIMMs, auf einer Unterseite des Schlittens angeordnet ist. Als Ergebnis des verbesserten Luftstroms, der von diesem Design geboten wird, können die Komponenten mit höheren Frequenzen und Energiepegeln als in typischen Systemen arbeiten, wodurch die Leistung verbessert wird. Darüber hinaus sind die Einschübe ausgelegt, blind mit Energie- und Datenkommunikationskabeln in einem Rack zusammenzupassen, wodurch ihre Fähigkeit verbessert wird, schnell entfernt, nachgerüstet, neu installiert und/oder ausgetauscht zu werden. Gleichermaßen sind individuelle Komponenten, die sich auf den Schlitten befinden, wie Prozessoren, Beschleuniger, Arbeitsspeicher und Datenspeicherlaufwerke, ausgelegt, aufgrund ihrer erhöhten Beabstandung voneinander leicht hochgerüstet zu werden. In der veranschaulichenden Ausführungsform enthalten die Komponenten zusätzlich Hardwarebestätigungsmerkmale, um ihre Echtheit zu beweisen.
Ein Rechenzentrum kann eine einzelne Netzwerkarchitektur („Fabric“) einsetzen, die mehrere andere Netzwerkarchitekturen einschließlich Ethernet und Omni-Path unterstützt. Die Schlitten können über Lichtwellenleiter, die eine höhere Bandbreite und geringere Latenz als übliche verdrillte Leitungskabel (z. B. Kategorie 5, Kategorie 5e, Kategorie 6 usw.) bieten, an Switches gekoppelt sein. Aufgrund der hohen Bandbreite, Zwischenverbindungen mit geringer Latenz und Netzwerkarchitektur kann das Rechenzentrum in Verwendung Ressourcen wie Arbeitsspeicher, Beschleuniger (z. B. GPUs, Grafikbeschleuniger, FPGAs, ASICs, neuronale Netze und/oder Beschleuniger mit künstlicher Intelligenz usw.) und Datenspeicherlaufwerke, die physisch getrennt sind, zusammenlegen und diese Rechenressourcen (z. B. Prozessoren) bei Bedarf bereitstellen, was den Rechenressourcen ermöglicht, auf die zusammengelegten Ressourcen zuzugreifen, als ob sie lokal wären.
Eine Energieversorgung oder -quelle kann das System 100 oder eine beliebige Komponente oder ein beliebiges System, die bzw. das hierin beschrieben ist, mit Spannung und/oder Strom versorgen. In einem Beispiel enthält die Energieversorgung einen Wechselstrom-auf-Gleichstrom(AC-DC)-Adapter, der in eine Wandsteckdose zu stecken ist. Eine derartige Wechselstromversorgung kann eine Energiequelle erneuerbarer Energie (z. B. Sonnenenergie) sein. In einem Beispiel enthält die Energiequelle eine Gleichstromquelle, wie einen externen AC-DC-Wandler. In einem Beispiel enthält die Energieversorgung oder die Energiequelle drahtlose Ladehardware, um über eine Nähe zu einem Ladefeld aufzuladen. In einem Beispiel kann die Energiequelle eine interne Batterie, eine Wechselstromversorgung, eine bewegungsbasierte Energieversorgung, eine Solar-Energieversorgung oder eine Brennstoffzellenquelle enthalten.
2A-2D veranschaulichen Rechensysteme und Grafikprozessoren, die von hierin beschriebenen Ausführungsformen bereitgestellt werden. Die Elemente von 2A-2D, die die gleichen Bezugsziffern (oder Namen) wie die Elemente einer beliebigen anderen Figur hierin aufweisen, können auf eine Weise arbeiten oder funktionieren, die der hierin anderswo beschriebenen ähnlich ist, aber nicht darauf beschränkt ist.
2A ist ein Blockdiagramm einer Ausführungsform eines Prozessors 200 mit einem oder mehreren Prozessorkernen 202A-202N, einer integrierten Arbeitsspeichersteuerung 214 und einem integrierten Grafikprozessor 208. Der Prozessor 200 kann zusätzliche Kerne bis zu und enthaltend einen zusätzlichen Kern 202N enthalten, die durch die gestrichelt umrandeten Kästchen dargestellt sind. Jeder der Prozessorkerne 202A-202N enthält eine oder mehrere interne Zwischenspeichereinheiten 204A-204N. In einigen Ausführungsformen weist jeder Prozessorkern auch Zugriff auf eine oder mehrere gemeinsam genutzte Zwischenspeichereinheiten 206 auf. Die internen Zwischenspeichereinheiten 204A-204N und die gemeinsam genutzten Zwischenspeichereinheiten 206 stellen innerhalb des Prozessors 200 eine Zwischenspeicherhierarchie dar. Die Zwischenspeicherhierarchie kann mindestens eine Ebene von Anweisungs- und Datenzwischenspeicher innerhalb jedes Prozessorkerns und eine oder mehrere Ebenen von gemeinsam genutztem Zwischenspeicher einer mittleren Ebene, wie einen Level-2(L2)-, Level-3(L3)-, Level-4(L4)-Zwischenspeicher oder einen Zwischenspeicher anderer Ebenen, wobei die höchste Zwischenspeicherebene vor dem externen Arbeitsspeicher als LLC klassifiziert ist. In einigen Ausführungsformen hält Zwischenspeicherkohärenzlogik eine Kohärenz zwischen den verschiedenen Zwischenspeichereinheiten 206 und 204A-204N aufrecht.
In einigen Ausführungsformen kann der Prozessor 200 auch einen Satz von einem oder mehreren Bussteuereinheiten 216 und einen Systemagentenkern 210 enthalten. Die eine oder die mehreren Bussteuereinheiten 216 verwalten einen Satz von peripheren Bussen, wie einen oder mehrere PCI- oder PCI-Express-Busse. Der Systemagentenkern 210 bietet Verwaltungsfunktionalität für die verschiedenen Prozessorkomponenten. In einigen Ausführungsformen enthält der Systemagentenkern 210 einen oder mehrere integrierte Arbeitsspeichersteuerungen 214, um den Zugriff auf verschiedene externe Arbeitsspeichervorrichtungen (nicht gezeigt) zu verwalten.
In einigen Ausführungsformen enthalten einer oder mehrere der Kerne 202A-202N Unterstützung für gleichzeitiges Multithreading. In einer derartigen Ausführungsform enthält der Systemagentenkern 210 Komponenten zum Koordinieren und Betreiben der Kerne 202A-202N während einer Multithreadingverarbeitung. Der Systemagentenkern 210 kann zusätzlich eine Leistungssteuereinheit (PCU) enthalten, die Logik und Komponenten enthält, um den Leistungszustand der Prozessorkerne 202A-202N und des Grafikprozessors 208 zu regeln.
In einigen Ausführungsformen enthält der Prozessor 200 zusätzlich einen Grafikprozessor 208, um Grafikverarbeitungsoperationen auszuführen. In einigen Ausführungsformen koppelt der Grafikprozessor 208 an den Satz von gemeinsam genutzten Zwischenspeichereinheiten 206 und den Systemagentenkern 210, einschließlich des einen oder der mehreren integrierten Arbeitsspeichersteuerungen 214. In einigen Ausführungsformen enthält der Systemagentenkern 210 auch eine Anzeigesteuerung 211, um eine Grafikprozessorausgabe zu einer oder mehreren gekoppelten Anzeigen zu lenken. In einigen Ausführungsformen kann die Anzeigesteuerung 211 auch ein separates Modul sein, das über mindestens eine Zwischenverbindung an den Grafikprozessor gekoppelt ist, oder kann innerhalb des Grafikprozessors 208 integriert sein.
In einigen Ausführungsformen wird eine Zwischenverbindungseinheit auf Ringbasis 212 verwendet, um die internen Komponenten des Prozessors 200 zu koppeln. Es kann jedoch eine alternative Zwischenverbindungseinheit verwendet werden, wie zum Beispiel eine Punkt-zu-Punkt-Zwischenverbindung, eine geschaltete Zwischenverbindung oder andere Techniken, einschließlich von Techniken, wie sie auf dem Fachgebiet wohlbekannt sind. In einigen Ausführungsformen koppelt der Grafikprozessor 208 über eine E/A-Verknüpfung 213 an die Ringzwischenverbindung 212.
Die beispielhafte E/A-Verknüpfung 213 stellt mindestens eine von mehreren Varianten von E/A-Zwischenverbindungen dar, einschließlich einer gehäuseinternen E/A-Zwischenverbindung, die eine Kommunikation zwischen verschiedenen Prozessorkomponenten und einem eingebetteten Hochleistungsarbeitsspeichermodul 218 ermöglicht, wie einem eDRAM-Modul. In einigen Ausführungsformen kann jeder der Prozessorkerne 202A-202N und der Grafikprozessor 208 eingebettete Arbeitsspeichermodule 218 als einen gemeinsam genutzten Last-Level-Zwischenspeicher verwenden.
In einigen Ausführungsformen sind die Prozessorkerne 202A-202N homogene Kerne, die die gleiche Anweisungssatzarchitektur ausführen. In einer anderen Ausführungsform sind die Prozessorkerne 202A-202N in Bezug auf die Anweisungssatzarchitektur (ISA) heterogen, wobei einer oder mehrere der Prozessorkerne 202A-202N einen ersten Anweisungssatz ausführen, während mindestens einer der anderen Kerne eine Teilmenge des ersten Anweisungssatzes oder einen anderen Anweisungssatz ausführt. In einer Ausführungsform sind die Prozessorkerne 202A-202N in Bezug auf die Mikroarchitektur heterogen, wobei ein oder mehrere Kerne mit einem relativ hohen Energieverbrauch an einen oder mehrere Energiekerne mit einem niedrigeren Energieverbrauch koppeln. In einer Ausführungsform sind die Prozessorkerne 202A-202N in Bezug auf die Rechenfähigkeit heterogen. Zusätzlich kann der Prozessor 200 auf einem oder mehreren Chips oder als ein integrierter SoC-Schaltkreis implementiert werden, der zusätzlich zu anderen Komponenten die illustrierten Komponenten aufweist.
2B ist ein Blockdiagramm von Hardwarelogik eines Grafikprozessorkerns 219 nach einigen hierin beschriebenen Ausführungsformen. Elemente von 2B, die die gleichen Bezugsziffern (oder Namen) wie die Elemente einer beliebigen anderen Figur hierin aufweisen, können auf eine Weise arbeiten oder funktionieren, die der hierin anderswo beschriebenen ähnlich ist, aber nicht darauf beschränkt ist. Der Grafikprozessorkern 219, manchmal als ein Kernsegment bezeichnet, kann ein oder mehrere Grafikkerne in einem modularen Grafikprozessor sein. Der Grafikprozessorkern 219 ist beispielhaft für ein Grafikkernsegment, und ein Grafikprozessor wie hierin beschrieben kann mehrere Grafikkernsegmente auf Grundlage von Zielleistung und Leistungsprofil enthalten. Jeder Grafikprozessorkern 219 kann einen festen Funktionsblock 230 enthalten, der an mehrere Subkerne 221A-221F gekoppelt ist, auch als Teilsegmente bezeichnet, die modulare Blöcke von Universal- und fester Funktionslogik enthalten.
In einigen Ausführungsformen enthält der feste Funktionsblock 230 eine Geometrie-/feste Funktionspipeline 231, die von allen Subkernen im Grafikprozessorkern 219 gemeinsam genutzt werden kann, zum Beispiel in Grafikprozessorimplementierungen mit niedrigerer Leistung und/oder niedrigerer Energie. In verschiedenen Ausführungsformen enthält die Geometrie-/feste Funktionspipeline 231 eine feste 3D-Funktionspipeline (z. B. die 3D-Pipeline 312 wie in 3 und 4), eine Video-Front-End-Einheit, einen Threaderzeuger und einen Thread-Dispatcher und eine vereinheitlichte Rückgabepufferverwaltung, die vereinheitlichte Rückgabepuffer verwaltet (z. B. den vereinheitlichten Rückgabepuffer 418 in 4, wie unten beschrieben).
In einer Ausführungsform enthält der feste Funktionsblock 230 auch eine Grafik-SoC-Schnittstelle 232, einen Grafikmikrocontroller 233 und eine Medienpipeline 234. Die Grafik-SoC-Schnittstelle 232 bietet eine Schnittstelle zwischen dem Grafikprozessorkern 219 und anderen Prozessorkernen innerhalb eines integrierten Ein-Chip-System-Schaltkreises. Der Grafikmikrocontroller 233 ist ein programmierbarer Subprozessor, der konfigurierbar ist, um verschiedene Funktionen des Grafikprozessorkerns 219, einschließlich von Threadversand, Planung und Vorwegnahme zu verwalten. Die Medienpipeline 234 (z. B. die Medienpipeline 316 von 3 und 4) enthält Logik, um das Decodieren, Codieren, Vorverarbeiten und/oder Nachbearbeiten von Multimediadaten, einschließlich Bild- und Videodaten zu ermöglichen. Die Medienpipeline 234 implementiert Medienoperationen über Anforderungen an Rechen- oder Abtastlogik in den Subkernen 221A-221F.
In einer Ausführungsform ermöglicht die SoC-Schnittstelle 232 dem Grafikprozessorkern 219, mit Universalanwendungsprozessorkernen (z. B. CPUs) und/oder anderen Komponenten innerhalb eines SoC, einschließlich Arbeitsspeicherhierarchieelementen wie eines gemeinsam genutzten Last-Level-Zwischenspeichers, des System-RAM und/oder eingebettetem chipinternem oder paketinternem DRAM, zu kommunizieren. Die SoC-Schnittstelle 232 kann auch eine Kommunikation mit festen Funktionsvorrichtungen im SoC, wie Kameraabbildungspipelines ermöglichen und ermöglicht die Verwendung von und/oder implementiert globale Arbeitsspeicheratomik, die unter dem Grafikprozessorkern 219 und CPUs innerhalb des SoC gemeinsam genutzt werden kann. Die SoC-Schnittstelle 232 kann auch Energieverwaltungssteuerungen 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 einen Empfang von Befehlspuffern von einer Befehlsstreamingeinheit und einem globalen Thread-Dispatcher, die ausgelegt sind, jedem von einem oder mehreren Grafikkernen innerhalb eines Grafikprozessors Befehle und Anweisungen bereitzustellen. Die Befehle und Anweisungen können an die Medienpipeline 234 vergeben werden, wenn Medienoperationen durchzuführen sind, oder an eine Geometrie- und feste Funktionspipeline (z. B. die Geometrie- und feste Funktionspipeline 231, die Geometrie- und feste Funktionspipeline 237), wenn Grafikverarbeitungsoperationen durchzuführen sind.
Der Grafikmikrocontroller 233 kann ausgelegt sein, verschiedene Planungs- und Verwaltungsaufgaben für den Grafikprozessorkern 219 durchzuführen. In einer Ausführungsform kann der Grafikmikrocontroller 233 eine Grafik- und/oder Rechenarbeitslastplanung an den verschiedenen parallelen Grafikengines innerhalb der Ausführungseinheitsanordnungen (EU-Anordnungen) 222A-222F, 224A-224F innerhalb der Subkerne 221A-221F durchführen. In diesem Planungsmodell kann Hostsoftware, die auf einem CPU-Kern eines SoC ausgeführt wird, das den Grafikprozessorkern 219 enthält, Arbeitslasten an eine von mehreren Grafikprozessortürklingeln schicken, die eine Planungsoperation auf der jeweiligen Grafikengine aufruft. Planungsoperationen enthalten ein Ermitteln, welche Arbeitslast als Nächstes auszuführen ist, Übermitteln einer Arbeitslast an eine Befehlsstreamingeinheit, Vorbelegen von bestehenden Arbeitslasten, die auf einer Engine laufen, Überwachen eines Fortschritts einer Arbeitslast und Benachrichtigen einer Hostsoftware, wenn eine Arbeitslast abgeschlossen ist. In einer Ausführungsform kann der Grafikmikrocontroller 233 auch Niedrigenergie- oder Leerlaufzustände für den Grafikprozessorkern 219 ermöglichen, was dem Grafikprozessorkern 219 die Fähigkeit gibt, Register innerhalb des Grafikprozessorkerns 219 über Niedrigenergie-Übergänge hinweg unabhängig vom Betriebssystem und/oder der Grafiktreibersoftware auf dem System Register zu speichern und wiederherzustellen.
Der Grafikprozessorkern 219 kann mehr oder weniger als die veranschaulichten Subkerne 221A-221F aufweisen, bis zu N modulare Subkerne. Für jeden Satz von N Subkernen kann der Grafikprozessorkern 219 auch gemeinsam genutzte Funktionslogik 235, gemeinsam genutzten Arbeitsspeicher und/oder Zwischenspeicher 236, eine Geometrie-/feste Funktionspipeline 237 sowie zusätzliche feste Funktionslogik 238 enthalten, um verschiedene Grafik- und Rechenverarbeitungsoperationen zu beschleunigen. Die gemeinsam genutzte Funktionslogik 235 kann mit der gemeinsam genutzten Funktionslogik 420 von 4 assoziierte Logikeinheiten enthalten (z. B. Abtast-, Mathematik- und/oder Kommunikationslogik zwischen Threads), die von jedem der N Subkerne innerhalb des Grafikprozessorkerns 219 gemeinsam genutzt werden können. Der gemeinsam genutzte Arbeitsspeicher und/oder Zwischenspeicher 236 kann ein Last-Level-Zwischenspeicher für den Satz der N Subkerne 221A-221F innerhalb des Grafikprozessorkerns 219 sein und kann auch als gemeinsam genutzter Arbeitsspeicher dienen, auf den von mehreren Subkernen zugegriffen werden kann. Die Geometrie-/feste Funktionspipeline 237 kann anstatt der Geometrie-/festen Funktionspipeline 231 innerhalb des festen Funktionsblocks 230 enthalten sein und kann die gleichen oder ähnliche Logikeinheiten enthalten.
In einer Ausführungsform enthält der Grafikprozessorkern 219 eine zusätzliche feste Funktionslogik 238, die verschiedene feste Funktionsbeschleunigungslogik zur Verwendung durch den Grafikprozessorkern 219 enthalten kann. In einer Ausführungsform enthält die zusätzliche feste Funktionslogik 238 eine zusätzliche Geometriepipeline zur Verwendung bei Schattierung nur nach Position. Bei Schattierung nur nach Position gibt es zwei Geometriepipelines, die vollständige Geometriepipeline innerhalb der Geometrie-/festen Funktionspipeline 238, 231 und eine Auswahlpipeline, die eine zusätzliche Geometriepipeline ist, die in der zusätzlichen festen Funktionslogik 238 enthalten sein kann. In einer Ausführungsform ist die Auswahlpipeline eine verkürzte Version der vollständigen Geometriepipeline. Die vollständige Pipeline und die Auswahlpipeline können unterschiedliche Instanzen der gleichen Anwendung ausführen, wobei jede Instanz einen separaten Kontext aufweist. Schattierung nur nach Position kann lange Auswahlläufe verworfener Dreiecke verbergen, was in einigen Fällen ermöglicht, dass die Schattierung früher abgeschlossen wird. Beispielsweise und in einer Ausführungsform kann die Auswahlpipeline innerhalb der zusätzlichen festen Funktionslogik 238 Positionsshader parallel zur Hauptanwendung ausführen und erzeugt allgemein wichtige Ergebnisse schneller als die vollständige Pipeline, da die Auswahlpipeline nur das Positionsattribut der Vertices abruft und schattiert, ohne eine Rasterung und ein Rendern der Pixel im Framepuffer durchzuführen. Die Auswahlpipeline kann die erzeugten kritischen Ergebnisse verwenden, um Sichtbarkeitsinformationen für alle Dreiecke unabhängig davon zu berechnen, ob diese Dreiecke ausgewählt sind. Die vollständige Pipeline (die in diesem Fall als eine Wiederholungspipeline bezeichnet werden kann) kann die Sichtbarkeitsinformationen verwenden, um die ausgewählten Dreiecke zu überspringen und nur die sichtbaren Dreiecke zu schattieren, die schließlich an die Rasterungsphase weitergegeben werden.
In einer Ausführungsform kann die zusätzliche feste Funktionslogik 238 auch Beschleunigungslogik für maschinelles Lernen enthalten, wie eine feste Funktionsmatrixmultiplikationslogik, für Implementierungen, die Optimierungen zum Training bei maschinellem Lernen oder Schlussfolgerungen enthalten.
Innerhalb jedes Grafik-Subkerns 221A-221F ist ein Satz von Ausführungsressourcen enthalten, die verwendet werden können, um Grafik-, Medien- und Rechenoperationen als Reaktion auf Anforderungen von einer Grafikpipeline, einer Medienpipeline oder Shaderprogrammen durchzuführen. Die Grafik-Subkerne 221A-221F enthalten mehrere EU-Anordnungen 222A-222F, 224A-224F, Thread-Dispatch- und Logik zur Kommunikation zwischen Threads (TD/IC) 223A-223F, einen 3D-Abtaster (z. B. Texturabtaster) 225A-225F, einen Medienabtaster 206A-206F, einen Shader-Prozessor 227A-227F und gemeinsam genutzten lokalen Arbeitsspeicher (SLM) 228A-228F. Die EU-Anordnungen 222A-222F, 224A-224F enthalten jeweils mehrere Ausführungseinheiten, die Universalgrafikverarbeitungseinheiten sind, die fähig sind, Gleitkomma- und Ganzzahl-/Fixpunktlogikoperationen im Dienst einer Grafik-, Medien- oder Rechenoperation durchzuführen, einschließlich Grafik-, Medien- oder Rechenshaderprogramme. Die TD/IC-Logik 223A-223F führt lokale Thread-Dispatch- und Threadsteueroperationen für die Ausführungseinheiten innerhalb eines Subkerns durch und ermöglichen eine Kommunikation zwischen Threads, die auf den Ausführungseinheiten des Subkerns ausgeführt werden. Der 3D-Abtaster 225A-225F kann eine Textur oder andere 3D-Grafik-bezogene Daten in einen Arbeitsspeicher lesen. Der 3D-Abtaster kann Texturdaten auf Grundlage eines konfigurierten Abtastzustands und dem mit einer bestimmten Textur assoziierten Texturformat unterschiedlich lesen. Der Medienabtaster 206A-206F kann ähnliche Leseoperationen auf Grundlage des mit Mediendaten assoziierten Typs und Formats durchführen. In einer Ausführungsform kann jeder Grafik-Subkern 221A-221F alternativ einen vereinheitlichten 3D- und Medienabtaster enthalten. Threads, die auf den Ausführungseinheiten in jedem der Subkerne 221A-221F ausgeführt werden, können den gemeinsam genutzten Arbeitsspeicher 228A-228F in jedem Subkern verwenden, um zu ermöglichen, dass Threads, die in einer Threadgruppe ausgeführt werden, unter Verwendung eines gemeinsamen chipinternen Arbeitsspeicherbestands ausgeführt werden.
2C veranschaulicht eine Grafikverarbeitungseinheit (GPU) 239, die dedizierte Sätze von Grafikverarbeitungsressourcen enthält, die in Mehrkerngruppen 240A-240N angeordnet sind. Während nur die Details von einer einzigen Mehrkerngruppe 240A bereitgestellt werden, ist klar, dass die anderen Mehrkerngruppen 240B-240N mit den gleichen oder ähnlichen Sätzen von Grafikverarbeitungsressourcen ausgestattet sein können.
Wie veranschaulicht, kann eine Mehrkerngruppe 240A einen Satz von Grafikkernen 243, einen Satz von Tensorkernen 244 und einen Satz von Raytracingkernen 245 enthalten. Ein Planer/Dispatcher 241 plant und verteilt die Grafikthreads zur Ausführung auf den verschiedenen Kernen 243, 244, 245. Ein Satz von Registerdateien 242 speichert Operandenwerte, die von den Kernen 243, 244, 245 beim Ausführen der Grafikthreads verwendet werden. Diese können zum Beispiel Ganzzahlregister zum Speichern von ganzzahligen Werten, Gleitkommaregister zum Speichern von Gleitkommawerten, Vektorregister zum Speichern von gepackten Datenelementen (ganzzahligen und/oder Gleitkomma-Datenelementen) und Kachelregister zum Speichern von Tensor-/Matrixwerten enthalten. In einer Ausführungsform sind die Kachelregister als kombinierte Sätze von Vektorregistern implementiert.
Ein oder mehrere kombinierte Level-1 (L1)-Zwischenspeicher und gemeinsam genutzte Arbeitsspeichereinheiten 247 speichern Grafikdaten wie Texturdaten, Vertexdaten, Pixeldaten, Strahldaten, Hüllkörperdaten usw. lokal innerhalb jeder Mehrkerngruppe 240A. Eine oder mehrere Textureinheiten 247 können auch verwendet werden, um Texturoperationen durchzuführen, wie Texturabbildung und Abtastung. Ein von allen oder einer Teilmenge der Mehrkerngruppen 240A-240N gemeinsam genutzter Level-2(L2)-Zwischenspeicher 253 speichert Grafikdaten und/oder Anweisungen für mehrere gleichzeitige Grafikthreads. Wie veranschaulicht kann der L2-Zwischenspeicher 253 über eine Vielzahl von Mehrkerngruppen 240A-240N hinweg gemeinsam genutzt werden. Eine oder mehrere Arbeitsspeichersteuerungen 248 koppeln die GPU 239 an einen Arbeitsspeicher 249, der ein Systemarbeitsspeicher (z. B. DRAM) und/oder ein dedizierter Grafikspeicher (z. B. GDDR6-Arbeitsspeicher) sein kann.
Eingabe-/Ausgabe(E/A)-Verschaltung 250 koppelt die GPU 239 an eine oder mehrere E/A-Vorrichtungen 252, wie digitale Signalprozessoren (DSPs), Netzwerksteuerungen oder Benutzereingabevorrichtungen. Eine chipinterne Zwischenverbindung kann verwendet werden, um die E/A-Vorrichtungen 252 an die GPU 239 und den Arbeitsspeicher 249 zu koppeln. Eine oder mehrere E/A-Arbeitsspeicherverwaltungseinheiten (IOMMUs) 251 der E/A-Verschaltung 250 koppeln die E/A-Vorrichtungen 252 direkt an den Systemarbeitsspeicher 249. In einer Ausführungsform verwaltet die IOMMU 251 mehrere Sätze von Seitentabellen, um virtuelle Adressen auf physische Adressen im Systemarbeitsspeicher 249 abzubilden. In dieser Ausführungsform können die E/A-Vorrichtungen 252, CPU(s) 246 und GPU(s) 239 den gleichen virtuellen Adressraum gemeinsam nutzen.
In einer Implementierung unterstützt die IOMMU 251 Virtualisierung. In diesem Fall kann sie einen ersten Satz von Seitentabellen, 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 des Systemarbeitsspeichers 249) abzubilden. Die Basisadressen jedes des ersten und des zweiten Satzes von Seitentabellen können in Steuerregistern gespeichert sein und bei einem Kontextwechsel ausgetauscht werden (sodass z. B. dem neuen Kontext Zugriff auf den relevanten Satz von Seitentabellen bereitgestellt wird). Obwohl in 2C nicht veranschaulicht, kann jeder der Kerne 243, 244, 245 und/oder der Mehrkerngruppen 240A-240N Übersetzungspuffer (TLBs) enthalten, um Übersetzungen von virtuellen Gast- auf physische Gastadressen, Übersetzungen von physischen Gast- auf physische Hostadressen und Übersetzungen von virtuellen Gast- auf physische Hostadressen zwischenzuspeichern.
In einer Ausführungsform sind die CPUs 246, GPUs 239 und E/A-Vorrichtungen 252 auf einem einzigen Halbleiterchip und/oder Chipgehäuse integriert. Der veranschaulichte Arbeitsspeicher 249 kann auf demselben Chip integriert sein oder kann über eine chipexterne Schnittstelle an die Arbeitsspeichersteuerungen 248 gekoppelt sein. In einer Implementierung umfasst der Arbeitsspeicher 249 GDDR6-Arbeitsspeicher, der den gleichen virtuellen Adressraum wie andere physische Arbeitsspeicher auf Systemebene nutzt, obwohl die zugrunde liegenden Prinzipien der Erfindung nicht auf diese spezifische Implementierung beschränkt sind.
In einer Ausführungsform enthalten die Tensorkerne 244 eine Vielzahl von Ausführungseinheiten, die spezifisch konstruiert sind, um Matrixoperationen durchzuführen, die die grundlegenden Rechenoperationen sind, die verwendet werden, um Operationen für tiefgehendes Lernen durchzuführen. Beispielsweise können gleichzeitige Matrixmultiplikationsoperationen für Training von neuronalen Netzen und Schlussfolgerungen verwendet werden. Die Tensorkerne 244 können eine Matrixverarbeitung unter Verwendung einer Vielfalt von Operandengenauigkeiten durchführen, einschließlich Gleitkomma mit einfacher Genauigkeit (z. B. 32 Bits), Gleitkomma mit halber Genauigkeit (z. B. 16 Bits), ganzzahliger Wörter (16 Bits), Bytes (8 Bits) und Halbbytes (4 Bits). In einer Ausführungsform extrahiert eine Implementierung eines neuronalen Netzes Merkmale jeder gerenderten Szene, wobei sie möglicherweise Details aus mehreren Rahmen kombiniert, um ein hochwertiges endgültiges Bild zu konstruieren.
In Implementierungen von tiefgehendem Lernen kann parallele Matrixmultiplikationsarbeit zur Ausführung auf den Tensorkernen 244 eingeplant werden. Insbesondere erfordert das Training von neuronalen Netzen eine wesentliche Anzahl von Matrix-Skalarproduktoperationen. Um eine Formulierung eines inneren Produktes einer N-mal-N-mal-N-Matrixmultiplikation zu verarbeiten, können die Tensorkerne 244 mindestens N Skalarprodukt-Verarbeitungselemente enthalten. Bevor die Matrixmultiplikation beginnt, wird eine gesamte Matrix in Kachelregister geladen und mindestens eine Spalte einer zweiten Matrix wird in jedem Zyklus für N Zyklen geladen. In jedem Zyklus gibt es N Skalarprodukte, die verarbeitet werden.
Matrixelemente können abhängig von der bestimmten Implementierung mit unterschiedlichen Präzisionen gespeichert werden, einschließlich von 16-Bit-Wörtern, 8-Bit-Bytes (z. B. INT8) und 4-Bit-Halbbytes (z. B. INT4). Unterschiedliche Präzisionsmodi können für die Tensorkerne 244 angegeben werden, um sicherzustellen, dass die effizienteste Präzision für unterschiedliche Arbeitslasten verwendet wird (wie z. B. Schlussfolgerungsarbeitslasten, die eine Quantisierung in Bytes und Halbbytes tolerieren können).
In einer Ausführungsform beschleunigen die Raytracingkerne 245 Raytracing-Operationen sowohl für Echzeit-Raytracing- als auch Nicht-Echtzeit-Raytracing-Implementierungen. Insbesondere enthalten die Raytracingkerne 245 Strahltraversierungs-/Schnittverschaltung zum Durchführen einer Strahltraversierung unter Verwendung von Hüllkörperhierarchien (BVHs) und zum Identifizieren von Schnittpunkten zwischen Strahlen und Primitiven, die innerhalb der BVH-Volumina eingeschlossen sind. Die Raytracingkerne 245 können auch Verschaltung zum Durchführen einer Tiefenprüfung und Aussonderung (z. B. unter Verwendung eines Z-Puffers oder einer ähnlichen Anordnung) enthalten. In einer Implementierung führen die Raytracingkerne 245 Traversierungs- und Schnittoperationen zusammen mit den hierin beschriebenen Bildrauschunterdrückungstechniken durch, von denen zumindest ein Teil auf den Tensorkernen 244 ausgeführt werden kann. In einer Ausführungsform implementieren die Tensorkerne 244 zum Beispiel ein neuronales Netz für tiefgehendes Lernen, um eine Rauschunterdrückung von Frames durchzuführen, die von den Raytracingkernen 245 generiert wurden. Die CPU(s) 246, die Grafikkerne 243 und/oder die Raytracingkerne 245 können jedoch auch die Gesamtheit oder einen Teil der Rauschunterdrückung und/oder Algorithmen für tiefgehendes Lernen implementieren.
Darüber hinaus, wie oben beschrieben, kann ein verteilter Ansatz für Rauschunterdrückung eingesetzt werden, bei dem sich die GPU 239 in einer Rechenvorrichtung befindet, die über ein Netzwerk oder eine Hochgeschwindigkeits-Zwischenverbindung an andere Rechenvorrichtungen gekoppelt ist. In dieser Ausführungsform nutzen die miteinander verbundenen Rechenvorrichtungen neuronale Netz-Lern-/Trainingsdaten gemeinsam, um die Geschwindigkeit zu verbessern, mit der das Gesamtsystem lernt, um eine Rauschunterdrückung für unterschiedliche Arten von Bildrahmen und/oder unterschiedliche Grafikanwendungen durchzuführen.
In einer Ausführungsform verarbeiten die Raytracingkerne 245 alle BVH-Traversierungs- und Strahl-Primitiven-Schnittpunkte, was die Grafikkerne 243 vor einem Überlasten mit Tausenden von Anweisungen pro Strahl schützt. In einer Ausführungsform enthält jeder Raytracingkern 245 einen ersten Satz von Sonderverschaltung zum Durchführen von Begrenzungsrahmenprüfungen (z. B. für Traversierungsoperationen) und einen zweiten Satz von Sonderverschaltung zum Durchführen der Strahl-Dreieck-Schnittprüfungen (z. B. sich schneidende Strahlen, die durchlaufen wurden). Deshalb kann die Mehrkerngruppe 240A in einer Ausführungsform einfach eine Strahlabtastung starten und die Raytracingkerne 245 unabhängig eine Strahltraversierung und Schnittpunktbestimmung durchführen und Trefferdaten (z. B. ein Treffer, keine Treffer, mehrere Treffer usw.) an den Threadkontext zurückgeben. Die anderen Kerne 243, 244 sind freigegeben, um eine andere Grafik- oder Rechenarbeit durchzuführen, während die Raytracingkerne 245 die Traversierungs- und Schnittoperationen durchführen.
In einer Ausführungsform enthält jeder Raytracingkern 245 eine Traversierungseinheit, um BVH-Testoperationen durchzuführen, und eine Schnitteinheit, die Strahl-Primitiven-Schnittpunkttests durchführt. Die Schnitteinheit generiert eine Antwort mit „Treffer“, „kein Treffer“ oder „mehrere Treffer“, die sie dem passenden Thread bereitstellt. Während der Traversierungs- und Schnittoperationen sind die Ausführungsressourcen der anderen Kerne (z. B. der Grafikkerne 243 und der Tensorkerne 244) freigegeben, um andere Formen von Grafikarbeit durchzuführen.
In einer bestimmten Ausführungsform, die unten beschrieben ist, wird ein hybrider Rasterungs-/Raytracing-Ansatz verwendet, bei dem Arbeit auf die Grafikkerne 243 und die Raytracingkerne 245 verteilt ist.
In einer Ausführungsform enthalten die Raytracingkerne 245 (und/oder andere Kerne 243, 244) Hardwareunterstüzung für einen Raytracing-Anweisungssatz, wie DirectX Ray Tracing (DXR) von Microsoft, der einen DispatchRays-Befehl sowie Strahlengenerierungs-, Nächstliegender-Treffer-, Beliebiger-Treffer- und Verfehlungs-Shader enthält, was die Zuweisung eindeutiger Sätze von Shadern und Texturen für jedes Objekt ermöglicht. Eine weitere Raytracing-Plattform, die von den Raytracingkernen 245, Grafikkernen 243 und Tensorkernen 244 unterstützt werden kann, ist Vulkan 1.1.85. Es ist jedoch anzumerken, dass die zugrunde liegenden Prinzipien der Erfindung nicht auf eine bestimmte Raytracing-ISA beschränkt ist.
Im Allgemeinen können verschiedene Kerne 245, 244, 243 einen Raytracing-Anweisungssatz unterstützen, der Anweisungen/Funktionen zur Strahlengenerierung, für den nächstgelegenen Treffer, einen beliebigen Treffer, einen Strahl-Primitiven-Schnitt, eine Konstruktion von Begrenzungsrahmen pro Primitiv und eine hierarchische Konstruktion von Begrenzungsrahmen, Verfehlung, Besuch und Ausnahmen enthält. Genauer enthält eine Ausführungsform Raytracing-Anweisungen, um die folgenden Funktionen durchzuführen:
Strahlgenerierung - Strahlgenerierungsanweisungen können für jedes Pixel, jede Probe oder eine andere benutzerdefinierte Arbeitszuweisung ausgeführt werden.
Nächstgelegener Treffer - Eine Anweisung für den nächstgelegenen Treffer kann ausgeführt werden, um den nächstgelegenen Schnittpunkt eines Strahls mit Primitiven innerhalb einer Szene aufzufinden.
Beliebiger Treffer - Eine Anweisung für einen beliebigen Treffer identifiziert mehrere Schnitte zwischen einem Strahl und Primitiven innerhalb einer Szene, um möglicherweise einen neuen nächstgelegenen Schnittpunkt zu identifizieren.
Schnitt - Eine Schnittanweisung führt einen Schnitttest zwischen Strahl und Primitivem durch und gibt ein Ergebnis aus.
Begrenzungsrahmenkonstruktion pro Primitivem - Diese Anweisung baut einen Begrenzungsrahmen um einen bestimmten Primitiven oder eine Gruppe von Primitiven auf (z. B. beim Aufbauen einer neuen BVH oder anderen Beschleunigungsdatenstruktur).
Verfehlung - Zeigt an, dass ein Strahl die gesamte Geometrie innerhalb einer Szene oder einem angegebenen Bereich einer Szene verfehlt.
Besuch - Zeigt die untergeordneten Volumina an, die ein Strahl durchläuft.
Ausnahmen - Enthält verschiedene Arten von Ausnahmehandlern (die z. B. für verschiedene Fehlerbedingungen aufgerufen werden).
2D ist ein Blockdiagramm einer Universal-Grafikprozessoreinheit (GPGPU) 270, die als ein Grafikprozessor und/oder Rechenbeschleuniger konfiguriert werden kann, nach hierin beschriebenen Ausführungsformen. Die GPGPU 270 kann über einen oder mehrere System- und/oder Arbeitsspeicherbusse mit Hostprozessoren (z. B. einer oder mehreren CPU(s) 246) und Arbeitsspeicher 271, 272 verbunden sein. In einer Ausführungsform ist der Arbeitsspeicher 271 Systemarbeitsspeicher, der mit der einen oder den mehreren CPU(s) 246 gemeinsam genutzt werden kann, während der Arbeitsspeicher 272 Vorrichtungsarbeitsspeicher ist, der für die GPGPU 270 dediziert ist. In einer Ausführungsform können Komponenten innerhalb der GPGPU 270 und des Vorrichtungsarbeitsspeichers 272 in Arbeitsspeicheradressen abgebildet werden, die für die eine oder die mehreren CPU(s) 246 zugänglich sind. Ein Zugriff auf die Arbeitsspeicher 271 und 272 kann über eine Arbeitsspeichersteuerung 268 ermöglicht werden. In einer Ausführungsform enthält die Arbeitsspeichersteuerung 268 eine interne Steuerung für direkten Speicherzugriff (DMA) 269 oder kann Logik enthalten, um Operationen durchzuführen, die andernfalls von einer DMA-Steuerung durchgeführt würden.
Die GPGPU 270 enthält mehrere Zwischenspeicher, einschließlich eines L2-Zwischenspeichers 253, eines L1-Zwischenspeichers 254, eines Anweisungszwischenspeichers 255 und eines gemeinsam genutzten Arbeitsspeichers 256, von dem zumindest ein Abschnitt auch als ein Zwischenspeicher partitioniert sein kann. Die GPGPU 270 enthält auch mehrere Recheneinheiten 260A-260N. Jede Recheneinheit 260A-260N enthält einen Satz von Vektorregistern 261, Skalarregistern 262, Vektorlogikeinheiten 263 und Skalarlogikeinheiten 264. Die Recheneinheiten 260A-260N können auch lokalen gemeinsam genutzten Arbeitsspeicher 265 und einen Programmzähler 266 enthalten. Die Recheneinheiten 260A-260N können an einen Konstantzwischenspeicher 267 koppeln, der verwendet werden kann, um konstante Daten zu speichern, die Daten sind, die sich während des Ablaufs des Kernel- oder Shaderprogramms nicht ändern, das auf der GPGPU 270 ausgeführt wird. In einer Ausführungsform ist der Konstantzwischenspeicher 267 ein skalarer Datenzwischenspeicher und zwischengespeicherte Daten können direkt in die Skalarregister 262 abgerufen werden.
Während des Betriebs können die eine oder die mehreren CPU(s) 246 Befehle in Register oder Arbeitsspeicher in der GPGPU 270 schreiben, die bzw. der auf einen zugänglichen Adressraum abgebildet wurden bzw. wurde. Die Befehlsprozessoren 257 können die Befehle aus Registern oder Arbeitsspeicher lesen und ermitteln, wie diese Befehle innerhalb der GPGPU 270 verarbeitet werden. Ein Thread-Dispatcher 258 kann dann verwendet werden, um Threads an die Recheneinheiten 260A-260N zu verteilen, um diese Befehle durchzuführen. Jede Recheneinheit 260A-260N kann Threads unabhängig von anderen Recheneinheiten ausführen. Zusätzlich kann jede Recheneinheit 260A-260N unabhängig für eine bedingte Berechnung konfiguriert sein und kann bedingt die Ergebnisse der Berechnung an einen Arbeitsspeicher ausgeben. Die Befehlsprozessoren 257 können die eine oder die mehreren CPU(s) 246 unterbrechen, wenn die vorgelegten Befehle abgeschlossen sind.
3A-3C veranschaulichen Blockdiagramme von zusätzlichen Grafikprozessor- und Rechenbeschleunigerarchitekturen, die von hierin beschriebenen Ausführungsformen bereitgestellt werden. Die Elemente von 3A-3C, die die gleichen Bezugsziffern (oder Namen) wie die Elemente einer beliebigen anderen Figur hierin aufweisen, können auf eine Weise arbeiten oder funktionieren, die der hierin anderswo beschriebenen ähnlich ist, aber nicht darauf beschränkt ist.
3A ist ein Blockdiagramm eines Grafikprozessors 300, der eine diskrete Grafikverarbeitungseinheit sein kann oder ein Grafikprozessor sein kann, der in eine Vielzahl von Verarbeitungskernen oder anderen Halbleitervorrichtungen, wie unter anderem Arbeitsspeichervorrichtungen oder Netzwerkschnittstellen, integriert ist. In einigen Ausführungsformen kommuniziert der Grafikprozessor über eine in den Arbeitsspeicher abgebildete E/A-Schnittstelle mit Registern auf dem Grafikprozessor und mit in den Prozessorarbeitsspeicher platzierten Befehlen. In einigen Ausführungsformen enthält der Grafikprozessor 300 eine Arbeitsspeicherschnittstelle 314, um auf den Arbeitsspeicher zuzugreifen. Die Arbeitsspeicherschnittstelle 314 kann eine Schnittstelle zu einem lokalen Arbeitsspeicher, einem oder mehreren internen Zwischenspeichern, einem oder mehreren gemeinsam genutzten externen Zwischenspeichern und/oder Systemarbeitsspeicher sein.
In einigen Ausführungsformen enthält der Grafikprozessor 300 auch eine Anzeigesteuerung 302, um eine Anzeigevorrichtung 318 mit Anzeigedaten anzusteuern. Die Anzeigesteuerung 302 enthält Hardware für eine oder mehrere Überlagerungsebenen für die Anzeige und für eine Zusammensetzung mehrerer Schichten von Video oder Benutzerschnittstellenelementen. Die Anzeigevorrichtung 318 kann eine interne oder externe Anzeigevorrichtung sein. In einer Ausführungsform kann die Anzeigevorrichtung 318 eine am Kopf montierte Anzeigevorrichtung wie eine Anzeigevorrichtung mit virtueller Realität (VR) oder eine Anzeigevorrichtung mit erweiterter Realität (AR) sein. In einigen Ausführungsformen enthält der Grafikprozessor 300 eine Videocodecengine 306, um Medien in ein oder mehrere Mediencodierformate zu codieren, aus diesen zu decodieren oder zwischen diesen transcodieren, einschließlich unter anderem Formaten der Moving Picture Experts Group (MPEG) wie MGEG-2, Advanced-Video-Coding(AVC)-Formaten wie H.264/MPEG-4 AVC, H.265/HEVC, VP8, VP9 der Alliance for Open Media (AOMedia) sowie 421M/VC-1 der Society of Motion Picture & Television Engineers (SMPTE) und Formaten der Joint Photographic Experts Group (JPEG) wie JPEG- und Motion-JPEG(MJPEG)-Formate.
In einigen Ausführungsformen enthält der Grafikprozessor 300 eine Blockbildtransfer(BLIT)-Engine 304, um zweidimensionale (2D) Rasteroperationen einschließlich beispielsweise Bitgrenzen-Blocktransfers. In einer Ausführungsform werden 2D-Grafikoperationen jedoch unter Verwendung einer oder mehrerer Komponenten der Grafikverarbeitungsengine (GPE) 310 durchgeführt. In einigen Ausführungsformen ist GPE 310 eine Rechenengine zum Durchführen von Grafikoperationen, einschließlich von dreidimensionalen (3D) Grafikoperationen und Medienoperationen.
In einigen Ausführungsformen enthält die GPE 310 eine 3D-Pipeline 312 zum Durchführen von 3D-Operationen, wie Rendern von dreidimensionalen Bildern und Szenen unter Verwendung von Verarbeitungsfunktionen, die primitive 3D-Formen (z. B. Rechteck, Dreieck usw.) bearbeiten. Die 3D-Pipeline 312 enthält programmierbare und feste Funktionselemente, die verschiedene Aufgaben innerhalb des Elements durchführen und/oder Ausführungsthreads in einem 3D/Medien-Subsystem 315 zu erzeugen. Während die 3D-Pipeline 312 verwendet werden kann, um Medienoperationen durchzuführen, enthält eine Ausführungsform der GPE 310 auch eine Medienpipeline 316, die spezifisch verwendet wird, um Medienoperationen wie eine Video-Nachbearbeitung und Bildverbesserung durchzuführen.
In einigen Ausführungsformen enthält die Medienpipeline 316 feste Funktions- oder programmierbare Logikeinheiten, um statt der oder im Auftrag der Videocodecengine 306 eine oder mehrere spezialisierte Medienoperationen durchzuführen, wie eine Videocodecbeschleunigung, Videozeilenentflechtung und Videocodierbeschleunigung. In einigen Ausführungsformen enthält die Medienpipeline 316 zusätzlich eine Threaderzeugungseinheit, um Threads zur Ausführung im 3D-Medien-Subsystem 315 zu erzeugen. Die erzeugten Threads führen Berechnungen für die Medienoperationen auf einer oder mehreren Grafikausführungseinheiten durch, die im 3D/Medien-Subsystem 315 enthalten sind.
In einigen Ausführungsformen enthält das 3D/Medien-Subsystem 315 Logik zum Ausführen von Threads, die von der 3D-Pipeline 312 und der Medienpipeline 316 erzeugt wurden. In einer Ausführungsform senden die Pipelines Threadausführungsanforderungen an das 3D/Medien-Subsystem 315, das Threadversandlogik zum Vermitteln und Versenden der verschiedenen Anforderungen an verfügbare Threadausführungsressourcen enthält. Die Ausführungsressourcen enthalten eine Anordnung von Grafikausführungseinheiten, um die 3D- und Medienthreads zu verarbeiten. In einigen Ausführungsformen enthält das 3D/Medien-Subsystem 315 einen oder mehrere interne Zwischenspeicher für Threadanweisungen und Daten. In einigen Ausführungsformen enthält das Subsystem auch gemeinsam genutzten Arbeitsspeicher, einschließlich von Registern und adressierbarem Arbeitsspeicher, um Daten zwischen Threads zu übermitteln und Ausgabedaten zu speichern.
3B veranschaulicht einen Grafikprozessor 320 mit einer gekachelten Architektur nach hierin beschriebenen Ausführungsformen. In einer Ausführungsform enthält der Grafikprozessor 320 ein Grafikverarbeitungsengine-Cluster 322 mit mehreren Instanzen der Grafikverarbeitungsengine 310 von 3A innerhalb einer Grafikenginekachel 310A-310D. Jede Grafikenginekachel 310A-310D kann über einen Satz von Kachelzwischenverbindungen 323A-323F miteinander verbunden werden. Jede Grafikenginekachel 310A-310D kann auch über Arbeitsspeicherzwischenverbindungen 325A-325D mit einem Arbeitsspeichermodul oder einer Arbeitsspeichervorrichtung 326A-326D verbunden sein. Die Arbeitsspeichervorrichtungen 326A-326D können eine beliebige Grafikspeichertechnologie verwenden. Die Arbeitsspeichervorrichtungen 326A-326D können beispielsweise Grafikspeicher mit doppelter Datenrate (GDDR) sein. Die Arbeitsspeichervorrichtungen 326A-326D sind in einer Ausführungsform Arbeitsspeichermodule mit hoher Bandbreite (HBM-Module), die mit ihrer jeweiligen Grafikenginekachel 310A-310D chipintern sein können. In einer Ausführungsform sind die Arbeitsspeichervorrichtungen 326A-326D gestapelte Arbeitsspeichervorrichtungen, die oben auf ihrer jeweiligen Grafikenginekachel 310A-310D gestapelt sein können. In einer Ausführungsform residiert jede Grafikenginekachel 31A-310D und zugehöriger Arbeitsspeicher 326A-326D auf separaten Einzelchips, die auf einen Basischip oder ein Basissubstrat gebondet sind, wie ausführlicher in 11B-11D beschrieben wird.
Das Grafikverarbeitungsengine-Cluster 322 kann mit einer chipinternen oder gehäuseinternen Fabric-Zwischenverbindung 324 verbunden sein. Die Fabric-Zwischenverbindung 324 kann eine Kommunikation zwischen Grafikenginekacheln 310A-310D und Komponenten wie dem Videocodec 306 und einer oder mehreren Kopierengines 304 ermöglichen. Die Kopierengines 304 können verwendet werden, um Daten aus den, in die und zwischen den Arbeitsspeichervorrichtungen 326A-326D und Arbeitsspeicher zu bewegen, der zum Grafikprozessor 320 extern ist (z. B. Systemarbeitsspeicher). Die Fabric-Zwischenverbindung 324 kann auch verwendet werden, um die Grafikenginekacheln 310A-310D miteinander zu verbinden. Der Grafikprozessor 320 kann optional eine Anzeigesteuerung 302 enthalten, 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 die Anzeigevorrichtung 318 weggelassen sein.
Der Grafikprozessor 320 kann über eine Hostschnittstelle 328 an ein Hostsystem anbinden. Die Hostschnittstelle 328 kann eine Kommunikation zwischen dem Grafikprozessor 320, Systemarbeitsspeicher und/oder anderen Systemkomponenten ermöglichen. Die Hostschnittstelle 328 kann beispielsweise ein PCI-Express-Bus oder ein anderer Typ von Hostsystemschnittstelle sein.
3C veranschaulicht einen Rechenbeschleuniger 330 nach hierin beschriebenen Ausführungsformen. Der Rechenbeschleuniger 330 kann architekturelle Ähnlichkeiten mit dem Grafikprozessor 320 von 3B enthalten und ist für eine Rechenbeschleunigung optimiert. Ein Rechenenginecluster 332 kann einen Satz von Rechenenginekacheln 340A-340D enthalten, die Ausführungslogik enthalten, die für parallele oder vektorbasierte Universal-Rechenoperationen optimiert ist. In einigen Ausführungsformen enthalten die Rechenenginekacheln 340A-340D keine feste Funktionsgrafikverarbeitungslogik, obwohl eine oder mehrere der Rechenenginekacheln 340A-340D in einer Ausführungsform Logik enthalten kann, um eine Medienbeschleunigung durchzuführen. Die Rechenenginekacheln 340A-340D können über Arbeitsspeicherzwischenverbindungen 325A-325D an Arbeitsspeicher 326A-326D anbinden. Der Arbeitsspeicher 326A-326D und Arbeitsspeicherzwischenverbindungen 325A-325D können eine ähnliche Technologie wie im Grafikprozessor 320 sein oder können unterschiedlich sein. Die Grafikrechenenginekacheln 340A-340D können auch über einen Satz von Kachelzwischenverbindungen 323A-323F miteinander verbunden sein und können mit und/oder miteinander durch eine Fabric-Zwischenverbindung 324 verbunden sein. In einer Ausführungsform enthält der Rechenbeschleuniger 330 enthält einen großen L3-Zwischenspeicher 336, der als ein vorrichtungsweiter Zwischenspeicher konfiguriert sein kann. Der Rechenbeschleuniger 330 kann auch über eine Hostschnittstelle 328 auf eine ähnliche Weise wie der Grafikprozessor 320 von 3B an einen Hostprozessor und einem Arbeitsspeicher anbinden.
Grafikverarbeitungsengine
4 ist ein Blockdiagramm einer Grafikverarbeitungsengine 410 eines Grafikprozessors in Übereinstimmung mit einigen Ausführungsformen. Die Grafikverarbeitungsengine (GPE) 410 ist in einer Ausführungsform eine Version der in 3A gezeigten GPE 310 und kann auch eine Grafikenginekachel 310A-310D von 3B repräsentieren. Elemente von 4, die die gleichen Bezugsziffern (oder Namen) wie die Elemente einer beliebigen anderen Figur hierin aufweisen, können auf eine Weise arbeiten oder funktionieren, die der hierin anderswo beschriebenen ähnlich ist, aber nicht darauf beschränkt ist. Beispielsweise sind die 3D-Pipeline 312 und die Medienpipeline 316 von 3A veranschaulicht. Die Medienpipeline 316 ist in einigen Ausführungsformen der GPE 410 optional und ist möglicherweise nicht explizit in der GPE 410 enthalten. In mindestens einer Ausführungsform ist ein separater Medien- und/oder Bildprozessor an die GPE 410 gekoppelt.
In einigen Ausführungsformen koppelt die GPE 410 an eine Befehlsstreamingeinheit 403, die der 3D-Pipeline 312 und/oder den Medienpipelines 316 einen Befehlsstrom bereitstellt, oder enthält eine solche. In einigen Ausführungsformen ist die Befehlsstreamingeinheit 403 an Arbeitsspeicher gekoppelt, der Systemarbeitsspeicher oder einer oder mehrerer von einem internen Zwischenspeicher und einem gemeinsam genutzten Zwischenspeicher sein kann. In einigen Ausführungsformen empfängt die Befehlsstreamingeinheit 403 Befehle vom Arbeitsspeicher und sendet die Befehle an die 3D-Pipeline 312 und/oder die Medienpipeline 316. Die Befehle sind Direktiven, die von einem Ringpuffer abgerufen wurden, der Befehle für die 3D-Pipeline 312 und die Medienpipeline 316 speichert. In einer Ausführungsform kann der Ringpuffer zusätzlich Batchbefehlspuffer enthalten, die Batches mehrerer Befehle speichern. Die Befehle für die 3D-Pipeline 312 können auch Bezüge auf im Arbeitsspeicher gespeicherte Daten enthalten, wie zum Beispiel unter anderem Vertex- und Geometriedaten für die 3D-Pipeline 312 und/oder Bilddaten und Arbeitsspeicherobjekte für die Medienpipeline 316. Die 3D-Pipeline 312 und die Medienpipeline 316 verarbeiten die Befehle und Daten durch Durchführen von Operationen durch Logik in den jeweiligen Pipelines oder durch Vergeben eines oder mehrerer Ausführungsthreads an eine Grafikkernanordnung 414. In einer Ausführungsform enthält die Grafikkernanordnung 414 einen oder mehrere Blöcke von Grafikkernen (z. B. Grafikkern(e) 415A, Grafikkern(e) 415B), wobei jeder Block einen oder mehrere Grafikkerne enthält. Jeder Grafikkern enthält einen Satz von Grafikausführungsressourcen, die Universal- und grafikspezifische Ausführungslogik enthalten, um Grafik- und Rechenoperationen durchzuführen, sowie feste Funktionslogik zur Texturverarbeitung und/oder für maschinelles Lernen und Beschleunigung künstlicher Intelligenz.
In verschiedenen Ausführungsformen kann die 3D-Pipeline 312 feste Funktions- und programmierbare Logik enthalten, um ein oder mehrere Shaderprogramme zu verarbeiten, wie Vertexshadern, Geometrieshadern, Pixelshadern, Fragmentshadern, Rechenshadern oder andere Shaderprogramme, durch Verarbeiten der Anweisungen und Vergeben von Ausführungsthreads an die Grafikkernanordnung 414. Die Grafikkernanordnung 414 stellt einen einheitlichen Block mit Ausführungsressourcen zur Verwendung bei der Verarbeitung dieser Shaderprogramme bereit. Mehrzweckausführungslogik (z. B. Ausführungseinheiten) innerhalb des Grafikkerns bzw. der Grafikkerne 415A-414B der Grafikkernanordnung 414 enthält Unterstützung für verschiedene 3D-API-Shadersprachen und kann mehrere gleichzeitige Ausführungsthreads ausführen, die mit mehreren Shadern assoziiert sind.
In einigen Ausführungsformen enthält die Grafikkernanordnung 414 Ausführungslogik, um Medienfunktionen durchzuführen, wie Video- und/oder Bildverarbeitung. In einer Ausführungsform enthalten die Ausführungseinheiten Universallogik, die programmierbar ist, um zusätzlich zu Grafikverarbeitungsoperationen parallele Universalrechenoperationen durchzuführen. Die Universallogik kann Verarbeitungsoperationen parallel oder zusammen mit Universallogik im Prozessorkern bzw. in den Prozessorkernen 107 von 1 oder im Kern 202A-202N wie in 2A durchführen.
Ausgabedaten, die von Threads generiert werden, die auf der Grafikkernanordnung 414 ausgeführt werden, können Daten in den Arbeitsspeicher in einen vereinheitlichten Rückgabepuffer (URB) 418 ausgeben. Der URB 418 kann Daten für mehrere Threads speichern. In einigen Ausführungsformen kann der URB 418 verwendet werden, um Daten zwischen unterschiedlichen Threads zu senden, die auf der Grafikkernanordnung 414 ausgeführt werden. In einigen Ausführungsformen kann der URB 418 zusätzlich zur Synchronisierung zwischen Threads auf der Grafikkernanordnung und fester Funktionslogik in der gemeinsam genutzten Funktionslogik 420 verwendet werden.
In einigen Ausführungsformen ist die Grafikkernanordnung 414 skalierbar, sodass die Anordnung eine variable Anzahl von Grafikkernen enthält, die jeweils eine variable Anzahl von Ausführungseinheiten auf Grundlage der Zielleistung und des Leistungspegels der GPE 410 aufweisen. In einer Ausführungsform sind die Ausführungsressourcen dynamisch skalierbar, sodass die Ausführungsressourcen je nach Bedarf aktiviert oder deaktiviert werden können.
Die Grafikkernanordnung 414 koppelt an die gemeinsam genutzte Funktionslogik 420, die mehrere Ressourcen enthält, die unter den Grafikkernen in der Grafikkernanordnung gemeinsam genutzt werden. Die gemeinsam genutzten Funktionen in der gemeinsam genutzten Funktionslogik 420 sind Hardwarelogikeinheiten, die der Grafikkernanordnung 414 spezialisierte ergänzende Funktionalität bereitstellen. In verschiedenen Ausführungsformen enthält die gemeinsam genutzte Funktionslogik 420 unter anderem Abtaster 421, Mathematik- 422 und Zwischenthreadkommunikationslogik (ITC-Logik) 423. Zusätzlich implementieren einige Ausführungsformen einen oder mehrere Zwischenspeicher 425 in der gemeinsam genutzten Funktionslogik 420.
Eine gemeinsam genutzte Funktion ist zumindest in einem Fall implementiert, in dem der Bedarf an einer bestimmten spezialisierten Funktion zur Aufnahme in die Grafikkernanordnung 414 unzureichend ist. Stattdessen ist eine einzelne Instantiierung dieser spezialisierten Funktion als eine eigenständige Entität in der gemeinsam genutzten Funktionslogik 420 implementiert und wird von den Ausführungsressourcen in der Grafikkernanordnung 414 gemeinsam genutzt. Die genaue Funktionsgruppe, die in der Grafikkernanordnung 414 gemeinsam genutzt ist und in der Grafikkernanordnung 414 enthalten ist, variiert über Ausführungsformen. In einigen Ausführungsformen können bestimmte gemeinsam genutzte Funktionen in der gemeinsam genutzten Funktionslogik 420, die von der Grafikkernanordnung 414 umfangreich genutzt werden, in der gemeinsam genutzten Funktionslogik 416 in der Grafikkernanordnung 414 enthalten sein. In verschiedenen Ausführungsformen kann die gemeinsam genutzte Funktionslogik 416 in der Grafikkernanordnung 414 einige der oder die gesamte Logik in der gemeinsam genutzten Funktionslogik 420 enthalten. In einer Ausführungsform können alle Logikelemente in der gemeinsam genutzten Funktionslogik 420 in der gemeinsam genutzten Funktionslogik 416 der Grafikkernanordnung 414 dupliziert werden. In einer Ausführungsform ist die gemeinsam genutzte Funktionslogik 420 zugunsten der gemeinsam genutzten Funktionslogik 416 in der Grafikkernanordnung 414 ausgeschlossen.
Ausführungseinheiten
5A-5B veranschaulichen eine Threadausführungslogik 500, die eine Anordnung von Verarbeitungselementen enthält, die in einem Grafikprozessorkern nach hierin beschriebenen Ausführungsformen eingesetzt wird. Elemente von 5A-5B, die die gleichen Bezugsziffern (oder Namen) wie die Elemente einer beliebigen anderen Figur hierin aufweisen, können auf eine Weise arbeiten oder funktionieren, die der hierin anderswo beschriebenen ähnlich ist, aber nicht darauf beschränkt ist. 5A-5B veranschaulichen eine Übersicht von Threadausführungslogik 500, die für Hardwarelogik repräsentativ sein kann, die mit jedem Subkern 221A-221F von 2B veranschaulicht ist. 5A ist für eine Ausführungseinheit innerhalb eines Universal-Grafikprozessors repräsentativ, während 5B für eine Ausführungseinheit repräsentativ ist, die innerhalb einer Rechenarchitektur verwendet werden kann.
Wie in 5A veranschaulicht, enthält die Threadausführungslogik 500 einen Shaderprozessor 502, einen Thread-Dispatcher 504, einen Anweisungszwischenspeicher 506, eine skalierbare Ausführungseinheitsanordnung, die eine Vielzahl von Ausführungseinheiten 508A-508N enthält, eine Abtasteinheit 510, einen gemeinsam genutzten Arbeitsspeicher 511, einen Datenzwischenspeicher 512 und einen Datenanschluss 514. In einer Ausführungsform kann die skalierbare Ausführungseinheitsanordnung dynamisch durch Aktivieren oder Deaktivieren einer oder mehrerer Ausführungseinheiten (z. B. beliebige der Ausführungseinheiten 508A, 508B, 508C, 508D bis 508N-1 und 508N) auf Grundlage der rechnerischen Anforderungen einer Arbeitslast skaliert werden. In einer Ausführungsform sind die enthaltenen Komponenten über eine Zwischenverbindungsfabric verbunden, die mit jeder der Komponenten verknüpft ist. In einigen Ausführungsformen enthält die Threadausführungslogik 500 eine oder mehrere Verbindungen mit einem Arbeitsspeicher, wie einem Systemarbeitsspeicher oder einem Zwischenspeicher, über eines oder mehrere vom Anweisungszwischenspeicher 506, dem Datenanschluss 514, der Abtasteinheit 510 und den Ausführungseinheiten 508A-508N. In einigen Ausführungsformen ist jede Ausführungseinheit (z. B. 508A) eine eigenständige programmierbare Universalrecheneinheit, die fähig ist, mehrere gleichzeitige Hardwarethreads auszuführen, während mehrere Datenelemente parallel für jeden Thread verarbeitet werden. In verschiedenen Ausführungsformen ist die Anordnung von Ausführungseinheiten 508A-508N skalierbar, um eine beliebige Anzahl individueller Ausführungseinheiten aufzunehmen.
In einigen Ausführungsformen werden die Ausführungseinheiten 508A-508N hauptsächlich verwendet, um Shaderprogramme auszuführen. Ein Shaderprozessor 502 kann die verschiedenen Shaderprogramme verarbeiten und Ausführungsthreads, die mit den Shaderprogrammen assoziiert sind, über einen Thread-Dispatcher 504 versenden. In einer Ausführungsform enthält der Thread-Dispatcher Logik, um Threadinitiierungsanforderungen von den Grafik- und Medienpipelines zu vermitteln und die angeforderten Threads auf einer oder mehreren Ausführungseinheiten in den Ausführungseinheiten 508A-508N zu instanziieren. Eine Geometriepipeline kann zum Beispiel Vertex-, Tessellations- oder Geometrieshader an die Threadausführungslogik zur Verarbeitung vergeben. In einigen Ausführungsformen kann der Thread-Dispatcher 504 auch Laufzeit-Threaderzeugungsanforderungen von den ausgeführten Shaderprogrammen verarbeiten.
In einigen Ausführungsformen unterstützen die Ausführungseinheiten 508A-508N einen Anweisungssatz, der native Unterstützung für viele Standard-3D-Grafikshaderanweisungen enthält, sodass Shaderprogamme von Grafikbibliotheken (z. B. Direct 3D und OpenGL) mit einer minimalen Übersetzung ausgeführt werden. Die Ausführungseinheiten unterstützen eine Vertex- und Geometrieverarbeitung (z. B. Vertexprogramme, Geometrieprogramme, Vertexshader), eine Pixelverarbeitung (z. B. Pixelshader, Fragmentshader) und eine Universalverarbeitung (z. B. Rechen- und Medienshader). Jede der Ausführungseinheiten 508A-508N ist zu einer mehrfach erteilten Einzelanweisungs-Mehrfachdaten(SIMD)-Ausführung fähig, und eine Operation mit mehreren Threads ermöglicht eine effiziente Ausführungsumgebung angesichts Arbeitsspeicherzugriffe mit höherer Latenz. Jeder Hardwarethread in jeder Ausführungseinheit weist eine dedizierte Registerdatei mit hoher Bandbreite und einen zugehörigen unabhängigen Threadzustand auf. Die Ausführung erfolgt in mehrfacher Erteilung pro Takt an Pipelines, die zu Ganzzahl- und Gleitkomma-Operationen mit einfacher und doppelter Genauigkeit, SIMD-Verzweigungsfähigkeit, logischen Operationen, transzendenten Operationen und anderen sonstigen Operationen fähig sind. Während des Wartens auf Daten aus dem Arbeitsspeicher oder von einer der gemeinsam genutzten Funktionen verursacht Abhängigkeitslogik in den Ausführungseinheiten 508A-508N, dass ein wartender Thread im Ruhezustand ist, bis die angeforderten Daten zurückgegeben wurden. Während sich der wartende Thread im Ruhezustand befindet, können Hardwareressourcen dem Verarbeiten anderer Threads gewidmet werden. Während einer mit einer Vertexshaderoperation assoziierten Verzögerung kann eine Ausführungseinheit beispielsweise Operationen für einen Pixelshader, Fragmentshader oder einen anderen Typ von Shaderprogramm durchführen, einschließlich eines anderen Vertexshaders. Verschiedene Ausführungsformen können anwenden, eine Ausführung durch Verwendung von Einzelanweisung-Mehrfachthreads (SIMT) als eine Alternative zur Verwendung von SIMD oder zusätzlich zur Verwendung von SIMD zu verwenden. Eine Bezugnahme auf einen SIMD-Kern oder eine SIMD-Operation kann auch für SIMT gelten oder für SIMD in Kombination mit SIMT gelten.
Jede Ausführungseinheit in den Ausführungseinheiten 508A-508N arbeitet an Arrays von Datenelementen. Die Anzahl der Datenelemente ist die „Ausführungsgröße“ oder die Anzahl der Kanäle für die Anweisung. Ein Ausführungskanal ist eine logische Einheit der Ausführung zum Zugriff auf Datenelemente, zur Maskierung und Ablaufsteuerung innerhalb von Anweisungen. Die Anzahl der Kanäle kann von der Anzahl der physischen arithmetisch-logischen Einheiten (ALUs) oder Gleitkommaeinheiten (FPUs) für einen bestimmten Grafikprozessor unabhängig sein. In einigen Ausführungsformen unterstützen die Ausführungseinheiten 508A-508N Ganzzahl- und Gleitkomma-Datentypen.
Der Anweisungssatz der Ausführungseinheiten enthält SIMD-Anweisungen. Die verschiedenen Datenelemente können als ein gepackter Datentyp in einem Register gespeichert sein und die Ausführungseinheit verarbeitet die verschiedenen Elemente auf Grundlage der Datengröße der Elemente. Beim Arbeiten an einem 256-Bit breiten Vektor werden die 256 Bits des Vektors zum Beispiel in einem Register gespeichert und die Ausführungseinheit bearbeitet den Vektor als vier separate gepackte 54-Bit-Datenelemente (Datenelemente von Quadwort(QW)-Größe), acht separate gepackte 32-Bit-Datenelemente (Datenelemente von Doppelwort(DW)-Datengröße), sechzehn separate gepackte 16-Bit-Datenelemente (Datenelemente von Wort(W)-Größe) oder zweiunddreißig separate 8-Bit-Datenelemente (Datenelemente von Byte(B)-Größe). Unterschiedliche Vektorbreiten und Registergrößen sind jedoch möglich.
In einer Ausführungsform können eine oder mehrere Ausführungseinheiten in eine verschmolzene Ausführungseinheit 509A-509N mit Threadsteuerlogik (507A-507N) kombiniert werden, die den verschmolzenen EUs gemeinsam ist. Mehrere EUs können in eine EU-Gruppe verschmolzen werden. Jede EU in der verschmolzenen EU-Gruppe kann ausgelegt sein, einen separaten SIMD-Hardwarethread auszuführen. Die Anzahl der EUs in einer verschmolzenen EU-Gruppe kann je nach Ausführungsformen variieren. Darüber hinaus können verschiedene SIMD-Breiten pro EU durchgeführt werden, einschließlich unter anderem SIMD8, SIMD16 und SIMD32. Jede verschmolzene Grafikausführungseinheit 509A-509N enthält mindestens zwei Ausführungseinheiten. Die verschmolzene Ausführungseinheit 509A enthält zum Beispiel eine erste EU 508A, eine zweite EU 508B und Threadsteuerlogik 507A, die der ersten EU 508A und der zweiten EU 508B gemeinsam ist. Die Threadsteuerlogik 507A steuert Threads, die auf der verschmolzenen Grafikausführungseinheit 509A ausgeführt werden, was jeder EU innerhalb der verschmolzenen Ausführungseinheiten 509A-509N ermöglicht, unter Verwendung eines gemeinsamen Anweisungszeigerregisters ausgeführt zu werden.
Ein oder mehrere interne Anweisungszwischenspeicher (z. B. 506) sind in der Threadausführungslogik 500 enthalten, um Threadanweisungen für die Ausführungseinheiten zwischenzuspeichern. In einigen Ausführungsformen sind ein oder mehrere Datenzwischenspeicher (z. B. 512) enthalten, um Threaddaten während der Threadausführung zwischenzuspeichern. Threads, die auf der Ausführungslogik 500 ausgeführt werden, können auch explizit verwaltete Daten im gemeinsam genutzten Arbeitsspeicher 511 speichern. In einigen Ausführungsformen ist ein Abtaster 510 enthalten, um eine Texturabtastung für 3D-Operationen und Medienabtastung für Medienoperationen bereitzustellen. In einigen Ausführungsformen enthält der Abtaster 510 spezialisierte Textur- oder Medienabtastfunktionalität, um Textur- oder Mediendaten während des Abtastprozesses vor dem Bereitstellen der abgetasteten Daten an eine Ausführungseinheit zu verarbeiten.
Während der Ausführung senden die Grafik- und Medienpipelines Threadinitiierungsanforderungen über Threaderzeugungs- und Dispatch-Logik an die Threadausführungslogik 500. Sobald eine Gruppe geometrischer Objekte verarbeitet und in Pixeldaten rasterisiert worden ist, wird Pixelprozessorlogik (z. B. Pixelshaderlogik, Fragmentshaderlogik usw.) im Shaderprozessor 502 aufgerufen, um Ausgabeinformationen weiter zu berechnen und zu bewirken, dass Ergebnisse in Ausgabeflächen (z. B. Farbpuffer, Tiefenpuffer, Schablonenpuffer usw.) geschrieben werden. In einigen Ausführungsformen berechnet ein Pixelshader oder Fragmentshader die Werte der verschiedenen Vertexattribute, die über das rasterisierte Objekt zu interpolieren sind. In einigen Ausführungsformen führt dann Pixelprozessorlogik im Shaderprozessor 502 ein von einer Anwendungsprogrammierschnittstelle (API) geliefertes Pixel- oder Fragmentshaderprogramm durch. Um das Shaderprogramm auszuführen, vergibt der Shaderprozessor 502 Threads über den Thread-Dispatcher 504 an eine Ausführungseinheit (z. B. 508A). In einigen Ausführungsformen verwendet der Shaderprozessor 502 Texturabtastlogik im Abtaster 510, um auf Texturdaten in im Arbeitsspeicher gespeicherten Texturabbildungen zuzugreifen. Arithmetische Operationen an den Texturdaten und den Eingabegeometriedaten berechnen Pixelfarbdaten für jedes geometrische Fragment oder verwerfen ein oder mehrere Pixel von einer weiteren Verarbeitung.
In einigen Ausführungsformen bietet der Datenanschluss 514 einen Arbeitsspeicherzugriffsmechanismus für die Threadausführungslogik 500, um verarbeitete Daten in den Arbeitsspeicher zur weiteren Verarbeitung in einer Grafikprozessorausgabepipeline auszugeben. In einigen Ausführungsformen enthält der Datenanschluss 514 einen oder mehrere Zwischenspeicher (z. B. den Datenzwischenspeicher 512) oder koppelt an diese, um Daten für einen Arbeitsspeicherzugriff über den Datenanschluss zwischenzuspeichern.
In einer Ausführungsform kann die Ausführungslogik 500 auch eine Raytracing-Einheit 505 enthalten, die Raytracing-Beschleunigungsfunktionalität bereitstellen kann. Die Raytracing-Einheit 505 kann einen Raytracing-Anweisungssatz unterstützen, der Anweisungen/Funktionen zur Strahlengenerierung enthält. Der Raytracing-Anweisungssatz kann dem Raytracing-Anweisungssatz ähnlich sein, der von den Raytracingkernen 245 in 2C unterstützt wird, oder von diesem verschieden sein.
5B veranschaulicht beispielhafte interne Details einer Ausführungseinheit 508 nach Ausführungsformen. Eine Grafikausführungseinheit 508 kann eine Anweisungsabrufeinheit 537, eine allgemeine Registerdateianordnung (GRF-Anordnung) 524, eine Architekturregisterdateianordnung (ARF-Anordnung) 526, einen Threadarbiter 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 enthalten. Die GRF 524 und ARF 526 enthalten den Satz von allgemeinen Registerdateien und Architekturregisterdateien, die mit jedem gleichzeitigen Hardwarethread assoziiert sind, die in der Grafikausführungseinheit 508 aktiv sein können. In einer Ausführungsform wird ein architektonischer Zustand pro Thread in der ARF 526 gepflegt, während Daten, die während der Threadausführung verwendet werden, in der GRF 524 gespeichert sind. Der Ausführungszustand jedes Threads, einschließlich der Anweisungszeiger für jeden Thread, kann in threadspezifischen Registern in der ARF 526 gehalten werden.
In einer Ausführungsform weist die Grafikausführungseinheit 508 eine Architektur auf, die eine Kombination von simultanem Multithreading (SMT) und feinkörnigem verschachteltem Multithreading (IMT) ist. Die Architektur weist eine modulare Konfiguration auf, die zum Zeitpunkt des Designs auf Grundlage einer Zielanzahl gleichzeitiger Threads und einer Anzahl von Registern pro Ausführungseinheit feinabgestimmt werden kann, wobei Ausführungseinheitsressourcen über Logik aufgeteilt werden, die verwendet wird, um mehrere gleichzeitige Threads auszuführen. Die Anzahl von logischen Threads, die von der Grafikausführungseinheit 508 ausgeführt werden kann, ist nicht auf die Anzahl von Hardwarethreads beschränkt, und mehrere logische Threads können jedem Hardwarethread zugewiesen werden.
In einer Ausführungsform kann die Grafikausführungseinheit 508 gemeinsam mehrere Anweisungen erteilen, die jeweils unterschiedliche Anweisungen sein können. Der Threadarbiter 522 des Grafikausführungsthreads 508 kann die Anweisungen an eine der Sendeinheit 530, Verzweigungseinheit 532 oder SIMD-FPU(s) 534 zur Ausführung vergeben. Jeder Ausführungsthread kann auf 128 Universalregister in der GRF 524 zugreifen, wobei jedes Register 32 Bytes speichern kann, auf die als ein SIMD-8-Element-Vektor aus 32-Bit-Datenelementen zugegriffen werden kann. In einer Ausführungsform weist jeder Ausführungseinheitsthread Zugriff auf 4 kBytes innerhalb der GRF 524 auf, obwohl Ausführungsformen derart nicht eingeschränkt sind und in anderen Ausführungsformen mehr oder weniger Registerressourcen bereitgestellt werden können. In einer Ausführungsform ist die Grafikausführungseinheit 508 in sieben Hardwarethreads partitioniert, die unabhängig rechnerische Operationen durchführen können, obwohl die Anzahl von Threads pro Ausführungseinheit auch nach Ausführungsformen variieren kann. In einer Ausführungsform werden zum Beispiel bis zu 16 Hardwarethreads unterstützt. In einer Ausführungsform, in der sieben Threads auf 4 kBytes zugreifen können, kann die GRF 524 insgesamt 28 kBytes speichern. Wo 16 Threads auf 4 kBytes zugreifen können, kann die GRF 524 insgesamt 64 kBytes speichern. Flexible Adressierungsmodi können ermöglichen, dass Register gemeinsam adressiert werden, um effektiv breitere Register zu bilden oder schrittweise rechteckige Blockdatenstrukturen zu repräsentieren.
In einer Ausführungsform werden Arbeitsspeicheroperationen, Abtastoperationen und andere Systemkommunikationen mit längerer Latenz über „Sende“-Anweisungen versandt, die von der Nachrichten übermittelnden Sendeeinheit 530 ausgeführt werden. In einer Ausführungsform werden Verzweigungsanweisungen an eine dedizierte Verzweigungseinheit 532 versandt, um eine SIMD-Divergenz und letztendliche Konvergenz zu ermöglichen.
In einer Ausführungsform enthält die Grafikausführungseinheit 508 eine oder mehrere SIMD-Gleitkommaeinheiten (FPU(s)) 534, um Gleitkomma-Operationen durchzuführen. In einer Ausführungsform unterstützen die FPU(s) 534 auch eine ganzzahlige Berechnung. In einer Ausführungsform kann bzw. können die FPU(s) 534 bis zu M32-Bit-Gleitkomma- (oder Ganzzahl-)Operationen via SIMD ausführen oder bis zu 2M 16-Bit-Ganzzahl- oder 16-Bit-Gleitkomma-Operationen via SIMD ausführen. In einer Ausführungsform bietet mindestens eine der FPU(s) erweiterte Mathematikfähigkeiten, um transzendente Mathematikfunktionen mit hohem Durchsatz und 54-Bit-Gleitkomma mit doppelter Genauigkeit zu unterstützen. In einigen Ausführungsformen ist auch eine Gruppe von 8-Bit-Ganzzahl-SIMD-ALUs 535 vorhanden und diese kann spezifisch optimiert sein, um Operationen durchzuführen, die mit Berechnungen für maschinelles Lernen assoziiert sind.
In einer Ausführungsform können Anordnungen mehrerer Instanzen der Grafikausführungseinheit 508 in einer Grafik-Subkerngruppierung (z. B. eines Teilsegments) instanziiert sein. Zur Skalierbarkeit können Produktarchitekten die genaue Anzahl der Ausführungseinheiten pro Subkerngruppierung wählen. In einer Ausführungsform kann die Ausführungseinheit 508 Anweisungen über eine Vielzahl von Ausführungskanälen ausführen. In einer weiteren Ausführungsform wird jeder Thread, der auf der Grafikausführungseinheit 508 ausgeführt wird, in einem anderen Kanal ausgeführt.
6 veranschaulicht eine zusätzliche Ausführungseinheit 600 nach einer Ausführungsform. Die Ausführungseinheit 600 kann eine rechenoptimierte Ausführungseinheit beispielsweise zur Verwendung in einer Rechenenginekachel 340A-340D wie in 3C sein, aber ist derartig nicht eingeschränkt. Varianten der Ausführungseinheit 600 können auch in einer Grafikenginekachel 31 0A-31 0D wie in 3B verwendet werden. In einer Ausführungsform enthält die Ausführungseinheit 600 eine Threadsteuereinheit 601, eine Threadzustandseinheit 602, eine Anweisungsabruf-/vorabrufeinheit 603 und eine Anweisungsdecodiereinheit 604. Die Ausführungseinheit 600 enthält zusätzlich eine Registerdatei 606, die Register speichert, die Hardwarethreads innerhalb der Ausführungseinheit zugewiesen werden können. Die Ausführungseinheit 600 enthält zusätzlich eine Sendeeinheit 607 und eine Verzweigungseinheit 608. In einer Ausführungsform können die Sendeeinheit 607 und die Verzweigungseinheit 608 ähnlich wie die Sendeeinheit 530 und eine Verzweigungseinheit 532 der Grafikausführungseinheit 508 von 5B arbeiten.
Die Ausführungseinheit 600 enthält auch eine Recheneinheit 610, die mehrere verschiedene Arten von funktionalen Einheiten enthält. In einer Ausführungsform enthält die Recheneinheit 610 eine ALU-Einheit 611, die eine Anordnung von arithmetisch-logischen Einheiten enthält. Die ALU-Einheit 611 kann ausgelegt sein, 64-Bit-, 32-Bit- und 16-Bit-Ganzzahl- und Gleitkomma-Operationen durchzuführen. Ganzzahlige und Gleitkomma-Operationen können gleichzeitig durchgeführt werden. Die Recheneinheit 610 kann auch eine systolische Anordnung 612 und eine Mathematikeinheit 613 enthalten. Die systolische Anordnung 612 enthält ein Netzwerk von Datenverarbeitungseinheiten der Breite W und Tiefe D, die verwendet werden können, um Vektor- oder andere datenparallele Operationen auf systolische Weise durchzuführen. In einer Ausführungsform kann die systolische Anordnung 612 ausgelegt sein, Matrixoperationen durchzuführen, wie Matrix-SkalarproduktOperationen. In einer Ausführungsform unterstützt die systolische Anordnung 612 16-Bit-Gleitkomma-Operationen sowie 8-Bit- und 4-Bit-Ganzzahl-Operationen. In einer Ausführungsform kann die systolische Anordnung 612 ausgelegt sein, Operationen für maschinelles Lernen zu beschleunigen. In derartigen Ausführungsformen kann die systolische Anordnung 612 mit Unterstützung für das bfloat-16-Bit-Gleitkomma-Format konfiguriert sein. In einer Ausführungsform kann eine Mathematikeinheit 613 enthalten sein, um eine bestimmte Teilmenge von mathematischen Operationen auf effiziente Weise und mit niedriger Energie als die ALU-Einheit 611 durchzuführen. Die Mathematikeinheit 613 kann eine Variante mathematischer Logik enthalten, die in gemeinsam genutzter Funktionslogik einer Grafikverarbeitungsengine gefunden werden kann, die von anderen Ausführungsformen (z. B. die Mathematiklogik 422 der gemeinsam genutzten Funktionslogik 420 von 4) bereitgestellt wird. In einer Ausführungsform kann die Mathematikeinheit 613 ausgelegt sein, 32-Bit- und 64-Bit-Gleitkomma-Operationen durchzuführen.
Die Threadsteuereinheit 601 enthält Logik, um die Ausführung von Threads innerhalb der Ausführungseinheit zu steuern. Die Threadsteuereinheit 601 kann Threadvermittlungslogik enthalten, um eine Ausführung von Threads innerhalb der Ausführungseinheit 600 zu starten, zu stoppen und vorwegzunehmen. Die Threadzustandseinheit 602 kann verwendet werden, um einen Threadzustand für Threads zu speichern, die zur Ausführung auf der Ausführungseinheit 600 zugewiesen wurden. Das Speichern des Threadzustands innerhalb der Ausführungseinheit 600 ermöglicht die rasche Vorwegnahme von Threads, wenn diese Threads blockiert werden oder im Leerlauf sind. Die Anweisungsabruf-/-vorabrufeinheit 603 kann Anweisungen aus einem Anweisungszwischenspeicher einer Ausführungslogik auf höherer Ebene (z. B. dem Anweisungszwischenspeicher 506 wie in 5A) abrufen. Die Anweisungsabruf-/-vorabrufeinheit 603 kann auch Vorabrufanforderungen für Anweisungen erteilen, die auf Grundlage einer Analyse von Threads, die derzeit ausgeführt werden, in den Anweisungszwischenspeicher zu laden sind. Die Anweisungsdecodiereinheit 604 kann verwendet werden, um Anweisungen zu decodieren, die von den Recheneinheiten auszuführen sind. In einer Ausführungsform kann die Anweisungsdecodiereinheit 604 als ein sekundärer Decoder verwendet werden, um komplexe Anweisungen in Mikrooperationsbestandteile zu decodieren.
Die Ausführungseinheit 600 enthält zusätzlich eine Registerdatei 606, 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 verteilt werden, die verwendet wird, um mehrere simultane Threads innerhalb der Recheneinheit 610 der Ausführungseinheit 600 auszuführen. Die Anzahl von logischen Threads, die von der Grafikausführungseinheit 600 ausgeführt werden kann, ist nicht auf die Anzahl von Hardwarethreads beschränkt, und mehrere logische Threads können jedem Hardwarethread zugewiesen werden. Die Größe der Registerdatei 606 kann über Ausführungsformen auf Grundlage der Anzahl von unterstützten Hardwarethreads variieren. In einer Ausführungsform kann eine Registerumbenennung verwendet werden, um dynamisch Register zu Hardwarethreads zuzuteilen.
7 ist ein Blockdiagramm, das ein Grafikprozessoranweisungsformat 700 nach einigen Ausführungsformen veranschaulicht. In einer oder mehreren Ausführungsformen unterstützen die Grafikprozessor-Ausführungseinheiten einen Anweisungssatz mit Anweisungen in mehreren Formaten. Die durchgezogen umrandeten Kästchen veranschaulichen die Komponenten, die allgemein in einer Ausführungseinheitsanweisung enthalten sind, während die gestrichelten Linien Komponenten enthalten, die optional sind oder die nur in einer Teilmenge der Anweisungen enthalten sind. In einigen Ausführungsformen des Anweisungsformats 700 sind Makroanweisungen beschrieben und veranschaulicht, dahingehend, dass sie Anweisungen sind, die der Ausführungseinheit geliefert werden, im Gegensatz zu Mikrooperationen, die sich aus einer Decodierung der Anweisung ergeben, sobald die Anweisung verarbeitet wurde.
In einigen Ausführungsformen unterstützen die Grafikprozessor-Ausführungseinheiten nativ Anweisungen in einem 128-Bit-Anweisungsformat 710. Ein kompaktes 64-Bit-Anweisungsformat 730 ist für einige Anweisungen verfügbar, auf Grundlage der ausgewählten Anweisung, der Anweisungsoptionen und der Anzahl der Operanden. Das native 128-Bit-Anweisungsformat 710 bietet Zugriff auf alle Anweisungsoptionen, während einige Optionen und Operationen im 64-Bit-Format 730 eingeschränkt sind. Die nativen Anweisungen, die im 64-Bit-Format 730 verfügbar sind, variieren nach Ausführungsform. In einigen Ausführungsformen wird die Anweisung teilweise unter Verwendung eines Satzes von Indexwerten in einem Indexfeld 713 komprimiert. Die Hardware der Ausführungseinheit nimmt auf Grundlage der Indexwerte auf einen Satz von Komprimierungstabellen Bezug und verwendet die Ausgaben der Komprimierungstabelle, um eine native Anweisung im 128-Bit-Anweisungsformat 710 zu rekonstruieren. Andere Größen und Formate von Anweisungen können verwendet werden.
Für jedes Format definiert der Anweisungsopcode 712 die Operation, die die Ausführungseinheit durchzuführen hat. Die Ausführungseinheiten führen jede Anweisung parallel über die mehreren Datenelemente jedes Operanden aus. Beispielsweise führt die Ausführungseinheit als Reaktion auf eine Additionsanweisung eine gleichzeitige Additionsoperation über jeden Farbkanal durch, der ein Texturelement oder Bildelement repräsentiert. Standardmäßig führt die Ausführungseinheit jede Anweisung über alle Datenkanäle der Operanden durch. In einigen Ausführungsformen ermöglicht das Anweisungssteuerfeld 714 eine Steuerung bestimmter Ausführungsoptionen, wie eine Kanalauswahl (z. B. Prädikation) und Datenkanalreihenfolge (z. B. Swizzeln). Für Anweisungen im 128-Bit-Anweisungsformat 710 schränkt ein Ausführungsgrößenfeld 716 die Anzahl der Datenkanäle ein, die parallel ausgeführt werden. In einigen Ausführungsformen steht das Ausführungsgrößenfeld 716 nicht zur Verwendung im kompakten 64-Bit-Anweisungsformat 730 zur Verfügung.
Einige Ausführungseinheitsanweisungen weisen bis zu drei Operanden einschließlich zweier Quelloperanden src0 720, src1 722 und eines Ziels 718 auf. In einigen Ausführungsformen unterstützen die Ausführungseinheiten Anweisungen mit zwei Zielen, wobei eines der Ziele implizit ist. Datenmanipulationsanweisungen können einen dritten Quelloperanden aufweisen (z. B. SRC2 724), wobei der Anweisungsopcode 712 die Anzahl der Quelloperanden bestimmt. Ein letzter Quelloperand einer Anweisung kann ein unmittelbarer (z. B. fest codierter) Wert sein, der mit der Anweisung übergeben wird.
In einigen Ausführungsformen enthält das 128-Bit-Anweisungsformat 710 ein Zugriffs-/Adressmodusfeld 726, das beispielsweise angibt, ob ein direkter Registeradressierungsmodus oder ein indirekter Registeradressierungsmodus verwendet wird. Wenn ein direkter Registeradressierungsmodus verwendet wird, wird die Registeradresse eines oder mehrerer Operanden direkt durch Bits in der Anweisung bereitgestellt.
In einigen Ausführungsformen enthält das 128-Bit-Anweisungsformat 710 ein Zugriffs-/Adressmodusfeld 726, das einen Adressmodus und/oder einen Zugriffsmodus für die Anweisung spezifiziert. In einer Ausführungsform wird der Zugriffsmodus verwendet, um eine Datenzugriffsausrichtung für die Anweisung zu definieren. Einige Ausführungsformen unterstützen Zugriffsmodi, die einen ausgerichteten 16-Byte-Zugriffsmodus und einen ausgerichteten 1-Byte-Zugriffsmodus enthalten, wobei die Byteausrichtung des Zugriffsmodus die Zugriffsausrichtung der Anweisungsoperanden bestimmt. In einem ersten Modus kann die Anweisung zum Beispiel Byte-ausgerichtete Adressierung für Quell- und Zieloperanden verwenden und in einem zweiten Modus kann die Anweisung eine 16-Byte-ausgerichtete Adressierung für alle Quell- und Zieloperanden verwenden.
In einer Ausführungsform bestimmt der Adressmodusabschnitt des Zugriffs-/Adressmodusfelds 726, ob die Anweisung eine direkte oder eine indirekte Adressierung zu verwenden hat. Wenn ein direkter Registeradressierungsmodus verwendet wird, stellen Bits in der Anweisung direkt die Registeradresse eines oder mehrerer Operanden bereit. Wenn ein indirekter Registeradressierungsmodus verwendet wird, kann die Registeradresse eines oder mehrerer Operanden auf Grundlage eines Adressregisterwerts und eines Adressen-Direktfelds in der Anweisung berechnet werden.
In einigen Ausführungsformen werden Anweisungen auf Grundlage von Opcode-Bitfeldern 712 gruppiert, um eine Opcode-Decodierung 740 zu vereinfachen. Für einen 8-Bit-Opcode ermöglichen Bits 4, 5 und 6 der Ausführungseinheit, den Typ von Opcode zu ermitteln. Die präzise gezeigte Opcodegruppierung ist nur ein Beispiel. In einigen Ausführungsformen enthält eine Bewegungs- und Logik-Opcodegruppe 742 Anweisungen zur Datenbewegung und Logikanweisungen (z. B. Bewegen (mov), Vergleichen (cmp)). In einigen Ausführungsformen nutzt die Bewegungs- und Logikgruppe 742 die fünf höchstwertigen Bits (MSB) gemeinsam, wobei Bewegungsanweisungen (mov) die Form von 0000xxxxb haben und Logikanweisungen die Form von 0001xxxxb haben. Eine Ablaufsteuerungsanweisungsgruppe 744 (z. B. Aufruf, Springen (jmp)) enthält Anweisungen in der Form von 0010xxxxb (z. B. 0x20). Eine Gruppe für sonstige Anweisungen 746 enthält eine Mischung von Anweisungen, einschließlich Synchronisierungsanweisungen (z. B. Warten, Senden) in Form von OOllxxxxb (z. B. 0x30). Eine parallele Mathematikanweisungsgruppe 748 enthält komponentenweise arithmetische Anweisungen (z. B. Addieren, Multiplizieren (mul)) in Form von 0100xxxxb (z. B. 0x40). Die Parallelmathematikgruppe 748 führt die arithmetischen Operationen parallel über Datenkanäle hinweg durch. Die Vektormathematikgruppe 750 enthält arithmetische Anweisungen (z. B. dp4) in Form von 0101xxxxb (z. B. 0x50). Die Vektormathematikgruppe führt Arithmetik wie Skalarproduktberechnungen an Vektoroperanden durch. Die veranschaulichte Opcode-Decodierung 740 kann in einer Ausführungsform verwendet werden, um zu ermitteln, welcher Abschnitt einer Ausführungseinheit verwendet werden wird, um eine decodierte Anweisung auszuführen. Einige Anweisungen können zum Beispiel als systolische Anweisungen designiert sein, die von einer systolischen Anordnung durchgeführt werden. Andere Anweisungen, wie Raytracing-Anweisungen (nicht gezeigt), können zu einem Raytracingkern oder Raytracinglogik innerhalb einer Scheibe oder einer Partition von Ausführungslogik geleitet werden.
Grafikpipeline
8 ist ein Blockdiagramm einer anderen Ausführungsform eines Grafikprozessors 800. Elemente von 8, die die gleichen Bezugsziffern (oder Namen) wie die Elemente einer beliebigen anderen Figur hierin aufweisen, können auf eine Weise arbeiten oder funktionieren, die der hierin anderswo beschriebenen ähnlich ist, aber nicht darauf beschränkt ist.
In einigen Ausführungsformen enthält ein Grafikprozessor 800 eine Geometriepipeline 820, eine Medienpipeline 830, eine Anzeigeengine 840, Threadausführungslogik 850 und eine Ausgaberenderpipeline 870. In einigen Ausführungsformen ist der Grafikprozessor 800 ein Grafikprozessor in einem Mehrkernverarbeitungssystem, das einen oder mehrere Universalverarbeitungskerne enthält. Der Grafikprozessor wird durch Registerschreibvorgänge in ein oder mehrere Steuerregister (nicht gezeigt) oder durch Befehle gesteuert, die über eine Ringverbindung 802 an den Grafikprozessor 800 ausgegeben werden. In einigen Ausführungsformen koppelt die Ringverbindung 802 den Grafikprozessor 800 an andere Verarbeitungskomponenten, wie andere Grafikprozessoren oder Universalprozessoren. Befehle von der Ringverbindung 802 werden durch eine Befehlsstreamingeinheit 803 interpretiert, die Anweisungen an individuelle Komponenten der Geometriepipeline 820 oder der Medienpipeline 830 liefert.
In einigen Ausführungsformen leitet die Befehlsstreamingeinheit 803 die Operation einer Vertexabrufeinheit 805, die Vertexdaten aus dem Arbeitsspeicher liest und Vertexverarbeitungsbefehle ausführt, die von der Befehlsstreamingeinheit 803 bereitgestellt werden. In einigen Ausführungsformen stellt die Vertexabrufeinheit 805 einem Vertexshader 807 Vertexdaten bereit, der an jedem Vertex eine Koordinatenraumtransformation und Beleuchtungsoperationen durchführt. In einigen Ausführungsformen führen die Vertexabrufeinheit 805 und der Vertexshader 807 Vertexverarbeitungsanweisungen durch Vergeben von Ausführungsthreads über einen Thread-Dispatcher 831 an die Ausführungseinheiten 852A-852B aus.
In einigen Ausführungsformen sind die Ausführungseinheiten 852A-852B eine Anordnung von Vektorprozessoren mit einem Anweisungssatz zum Durchführen von Grafik- und Medienoperationen. In einigen Ausführungsformen weisen die Ausführungseinheiten 852A-852B einen zugehörigen L1-Zwischenspeicher 851 auf, der für jede Anordnung spezifisch ist oder unter den Anordnungen gemeinsam genutzt wird. Der Zwischenspeicher kann als ein Datenzwischenspeicher, ein Anweisungszwischenspeicher oder ein einzelner Zwischenspeicher konfiguriert sein, der partitioniert ist, um Daten und Anweisungen in unterschiedlichen Partitionen zu enthalten.
In einigen Ausführungsformen enthält die Geometriepipeline 820 Tessellationskomponenten, um eine hardwarebeschleunigte Tessellation von 3D-Objekten durchzuführen. In einigen Ausführungsformen konfiguriert ein programmierbarer Hüllenshader 811 die Tessellationsoperationen. Ein programmierbarer Domänenshader 817 stellt eine Back-End-Auswertung der Tessellationsausgabe bereit. Eine Tessellationseinheit 813 arbeitet auf Anweisung des Hüllenshaders 811 und enthält Sonderlogik, um auf Grundlage eines groben geometrischen Modells, das als Eingabe in die Geometriepipeline 820 bereitgestellt wurde, einen Satz von detaillierten geometrischen Objekten zu erzeugen. In einigen Ausführungsformen, falls keine Tessellation verwendet wird, können Tessellationskomponenten (z. B. der Hüllenshader 811, die Tessellationseinheit 813 und der Domänenshader 817) umgangen werden.
In einigen Ausführungsformen können vollständige geometrische Objekte durch einen Geometrieshader 819 über einen oder mehrere Threads verarbeitet werden, die an die Ausführungseinheiten 852A-852B vergeben werden, oder können direkt zum Clipper 829 weitergehen. In einigen Ausführungsformen arbeitet der Geometrieshader an geometrischen Gesamtobjekten anstatt an Vertices oder Gruppen von Vertices, wie in vorangehenden Phasen der Grafikpipeline. Falls die Parkettierung deaktiviert ist, empfängt der Geometrieshader 819 eine Eingabe vom Vertexshader 807. In einigen Ausführungsformen ist der Geometrieshader 819 durch ein Geometrieshaderprogramm programmierbar, um Geometrietessellationen durchzuführen, falls die Tessellationseinheiten deaktiviert sind.
Vor einer Rasterung verarbeitet ein Clipper 829 Vertexdaten. Der Clipper 829 kann ein fester Funktionsclipper oder ein programmierbarer Clipper mit Clipping- und Geometrieshaderfunktionen sein. In einigen Ausführungsformen verteilt eine Rasterungs- und Tiefentestkomponente 873 in der Ausgaberenderpipeline 870 Pixelshader, um die geometrischen Objekte in Darstellungen pro Pixel umzuwandeln. In einigen Ausführungsformen ist Pixelshaderlogik in der Threadausführungslogik 850 enthalten. In einigen Ausführungsformen kann eine Anwendung die Rasterungs- und Tiefentestkomponente 873 umgehen und über eine Ausgabestreamingeinheit 823 auf nicht gerasterte Vertexdaten zugreifen.
Der Grafikprozessor 800 weist einen Zwischenverbindungsbus, ein Zwischenverbindungsfabric oder einen anderen Zwischenverbindungsmechanismus auf, der ermöglicht, dass Daten und Nachrichten zwischen den Hauptkomponenten des Prozessors übermittelt werden. In einigen Ausführungsformen sind die Ausführungseinheiten 852A-852B und zugehörige Logikeinheiten (z. B. der L1-Zwischenspeicher 851, der Abtaster 854, der Texturzwischenspeicher 858 usw.) über einen Datenanschluss 856 verbunden, um auf Arbeitsspeicher zuzugreifen und mit Ausgaberenderpipelinekomponenten des Prozessors zu kommunizieren. In einigen Ausführungsformen weisen der Abtaster 854, die Zwischenspeicher 851, 858 und die Ausführungseinheiten 852A-852B jeweils separate Arbeitsspeicherzugriffspfade auf. In einer Ausführungsform kann der Texturzwischenspeicher 858 auch als ein Abtastzwischenspeicher konfiguriert sein.
In einigen Ausführungsformen enthält die Ausgaberenderpipeline 870 eine Rasterungs- und Tiefentestkomponente 873, die vertexbasierte Objekte in eine assoziierte pixelbasierte Darstellung umwandelt. In einigen Ausführungsformen enthält die Rasterungslogik eine Fenster-/Maskierungseinheit, um eine feste Funktions-Dreieck- und Linien-Rasterung durchzuführen. Ein assoziierter Renderzwischenspeicher 878 und Tiefenzwischenspeicher 879 sind ebenfalls in einigen Ausführungsformen verfügbar. Eine Pixeloperationskomponente 877 führt pixelbasierte Operationen an den Daten durch, obwohl mit 2D-Operationen assoziierte Pixeloperationen (z. B. Bitblockbildtransfers mit Mischen) in einigen Fällen von der 2D-Engine 841 durchgeführt werden oder zum Zeitpunkt der Anzeige von der Anzeigesteuerung 843 unter Verwendung von Überlagerungsanzeigeebenen substituiert werden. In einigen Ausführungsformen steht ein gemeinsam genutzter L3-Zwischenspeicher 875 allen Grafikkomponenten zur Verfügung, was das gemeinsame Nutzen von Daten ohne die Verwendung von Hauptsystemarbeitsspeicher ermöglicht.
In einigen Ausführungsformen enthält die Grafikprozessor-Medienpipeline 830 eine Medienengine 837 und ein Video-Front-End 834. In einigen Ausführungsformen empfängt das Video-Front-End 834 Pipelinebefehle von der Befehlsstreamingeinheit 803. In einigen Ausführungsformen enthält die Medienpipeline 830 eine separate Befehlsstreamingeinheit. In einigen Ausführungsformen verarbeitet das Video-Front-End 834 Medienbefehle, bevor es den Befehl an die Medienengine 837 sendet. In einigen Ausführungsformen enthält die Medienengine 837 Threaderzeugungsfunktionalität, um Threads zum Versand über den Thread-Dispatcher 831 an die Threadausführungslogik 850 zu erzeugen.
In einigen Ausführungsformen enthält der Grafikprozessor 800 eine Anzeigeengine 840. In einigen Ausführungsformen ist die Anzeigeengine 840 zum Prozessor 800 extern und koppelt über die Ringzwischenverbindung 802 oder einen anderen Zwischenverbindungsbus oder eine andere Zwischenverbindungsfabric an den Grafikprozessor. In einigen Ausführungsformen enthält die Anzeigeengine 840 eine 2D-Engine 841 und eine Anzeigesteuerung 843. In einigen Ausführungsformen enthält die Anzeigeengine 840 Sonderlogik, die fähig ist, unabhängig von der 3D-Pipeline zu arbeiten. In einigen Ausführungsformen koppelt die Anzeigesteuerung 843 an eine Anzeigevorrichtung (nicht gezeigt), die eine in das System integrierte Anzeigevorrichtung sein kann, wie in einem Laptopcomputer, oder eine externe Anzeigevorrichtung sein kann, die über einen Anzeigevorrichtungsanschluss angebunden ist.
In einigen Ausführungsformen sind die Geometriepipeline 820 und die Medienpipeline 830 konfigurierbar, um Operationen auf Grundlage mehrerer Grafik- und Medienprogrammierschnittstellen durchzuführen, und sind nicht für eine bestimmte Anwendungsprogrammierschnittstelle (API) spezifisch. In einigen Ausführungsformen übersetzt Treibersoftware für den Grafikprozessor API-Aufrufe, die für eine bestimmte Grafik- oder Medienbibliothek spezifisch sind, in Befehle, die vom Grafikprozessor verarbeitet werden können. In einigen Ausführungsformen wird Unterstützung für die Open Graphics Library (OpenGL), Open Computing Language (OpenCL) und/oder Vulkan-Grafik- und Rechen-API, alle von der Khronos-Gruppe, bereitgestellt. In einigen Ausführungsformen kann Unterstützung auch für die Direct3D-Bibliothek von der Microsoft Corporation bereitgestellt werden. In einigen Ausführungsformen kann eine Kombination dieser Bibliotheken unterstützt werden. Unterstützung kann auch für die Open Source Computer Vision Library (OpenCV) bereitgestellt werden. Eine zukünftige API mit einer kompatiblen 3D-Pipeline würde ebenfalls unterstützt werden, falls eine Abbildung von der Pipeline der zukünftigen API auf die Pipeline des Grafikprozessors erstellt werden kann.
Programmierung der Grafikpipeline
9A ist ein Blockdiagramm, das ein Grafikprozessor-Befehlsformat 900 nach einigen Ausführungsformen veranschaulicht. 9B ist ein Blockdiagramm, das eine Grafikprozessor-Befehlsfolge 910 nach einer Ausführungsform veranschaulicht. Die durchgezogen umrandeten Kästchen in 9A veranschaulichen die Komponenten, die allgemein in einem Grafikbefehl enthalten sind, während die gestrichelten Linien Komponenten enthalten, die optional sind oder die nur in einer Teilmenge der Grafikbefehle enthalten sind. Das beispielhafte Grafikprozessor-Befehlsformat 900 von 9A enthält Datenfelder, um einen Client 902 zu identifizieren, einen Befehlsoperationscode (Opcode) 904 und Daten 906 für den Befehl. Ein Sub-Opcode 905 und eine Befehlsgröße 908 sind in einigen Befehlen ebenfalls enthalten.
In einigen Ausführungsformen gibt der Client 902 die Clienteinheit der Grafikvorrichtung an, die die Befehlsdaten verarbeitet. In einigen Ausführungsformen untersucht ein Grafikprozessor-Befehlsparser das Clientfeld jedes Befehls, um die weitere Verarbeitung des Befehls aufzubereiten und die Befehlsdaten an die passende Clienteinheit zu leiten. In einigen Ausführungsformen enthalten die Grafikprozessor-Clienteinheiten eine Arbeitsspeicherschnittstelleneinheit, eine Rendereinheit, eine 2D-Einheit, eine 3D-Einheit und eine Medieneinheit. Jede Clienteinheit weist eine entsprechende Verarbeitungspipeline auf, die die Befehle verarbeitet. Sobald der Befehl von der Clienteinheit empfangen wurde, liest die Clienteinheit den Opcode 904 und den Sub-Opcode 905, falls vorhanden, um die durchzuführende Operation zu ermitteln. Die Clienteinheit führt den Befehl unter Verwendung von Informationen im Datenfeld 906 durch. Für einige Befehle wird erwartet, dass eine explizite Befehlsgröße 908 die Größe des Befehls angibt. In einigen Ausführungsformen ermittelt der Befehlsparser die Größe von mindestens einigen der Befehle auf Grundlage des Befehlsopcodes. In einigen Ausführungsformen sind die Befehle über Mehrfache eines Doppelworts ausgerichtet. Andere Befehlsformate können verwendet werden.
Das Ablaufdiagramm in 9B veranschaulicht eine beispielhafte Grafikprozessor-Befehlsfolge 910. In einigen Ausführungsformen verwendet Software oder Firmware eines Datenverarbeitungssystems, das eine Ausführungsform eines Grafikprozessors umfasst, eine Version der gezeigten Befehlsfolge, um einen Satz von Grafikoperationen einzurichten, auszuführen und abzuschließen. Eine beispielhafte Befehlsfolge wird nur zu Beispielzwecken gezeigt, da Ausführungsformen nicht auf diese spezifischen Befehle oder auf diese Befehlsfolge beschränkt sind. Darüber hinaus können die Befehle als ein Batch von Befehlen in einer Befehlsfolge erteilt werden, sodass der Grafikprozessor die Befehlsfolge zumindest teilweise gleichzeitig verarbeitet.
In einigen Ausführungsformen kann die Grafikprozessor-Befehlsfolge 910 mit einem Pipelineleerungsbefehl 912 beginnen, um zu bewirken, dass alle aktiven Grafikpipelines die aktuell anstehenden Befehle für die Pipeline abschließen. In einigen Ausführungsformen können die 3D-Pipeline 922 und die Medienpipeline 924 nicht gleichzeitig arbeiten. Die Pipelineleerung wird durchgeführt, um zu veranlassen, dass die aktive Grafikpipeline alle anstehenden Befehle abschließt. Als Reaktion auf eine Pipelineleerung hält der Befehlsparser für den Grafikprozessor eine Befehlsverarbeitung an, bis die aktiven Zeichenengines anstehende Operationen abschließen und die relevanten Lesezwischenspeicher ungültig gemacht sind. Optional können alle Daten im Renderzwischenspeicher, die als ,verändert' markiert sind, in den Arbeitsspeicher geleert werden. In einigen Ausführungsformen kann der Pipelineleerungsbefehl 912 zur Pipelinesynchronisierung oder vor dem Platzieren des Grafikprozessors in einen Ruhezustand verwendet werden.
In einigen Ausführungsformen wird ein Pipelineauswahlbefehl 913 verwendet, wenn eine Befehlsfolge erfordert, dass der Grafikprozessor explizit zwischen Pipelines wechselt. In einigen Ausführungsformen ist ein Pipelineauswahlbefehl 913 nur einmal innerhalb eines Ausführungskontexts erforderlich, bevor Pipelinebefehle erteilt werden, es sei denn, der Kontext hat Befehle für beide Pipelines auszugeben. In einigen Ausführungsformen ist ein Pipelineleerungsbefehl 912 unmittelbar vor einem Pipelinewechsel über den Pipelineauswahlbefehl 913 erforderlich.
In einigen Ausführungsformen konfiguriert ein Pipelinesteuerbefehl 914 eine Grafikpipeline zum Betrieb und wird verwendet, um die 3D-Pipeline 922 und die Medienpipeline 924 zu programmieren. In einigen Ausführungsformen konfiguriert der Pipelinesteuerbefehl 914 den Pipelinezustand für die aktive Pipeline. In einer Ausführungsform wird der Pipelinesteuerbefehl 914 zur Pipelinesynchronisierung und dazu verwendet, vor dem Verarbeiten eines Batchs von Befehlen Daten aus einem oder mehreren Zwischenspeichern in der aktiven Pipeline zu löschen.
In einigen Ausführungsformen werden Rückgabepufferzustandsbefehle 916 verwendet, um einen Satz von Rückgabepuffern für die jeweiligen Pipelines zum Schreiben von Daten zu konfigurieren. Einige Pipelineoperationen erfordern die Zuordnung, Auswahl oder Konfiguration eines oder mehrerer Rückgabepuffer, in die die Operationen während der Verarbeitung Zwischendaten schreiben. In einigen Ausführungsformen verwendet der Grafikprozessor auch einen oder mehrere Rückgabepuffer, um Ausgabedaten zu speichern und eine threadübergreifende Kommunikation durchzuführen. In einigen Ausführungsformen enthält der Rückgabepufferzustand 916 ein Auswählen der Größe und Anzahl der Rückgabepuffer, die für einen Satz von Pipelineoperationen zu verwenden sind.
Die verbleibenden Befehle in der Befehlsfolge unterscheiden sich auf Grundlage der aktiven Pipeline für Operationen. Auf Grundlage einer Pipelineermittlung 920 ist die Befehlsfolge auf die 3D-Pipeline 922, beginnend mit dem 3D-Pipelinezustand 930, oder die Medienpipeline 924, beginnend mit dem Medienpipelinezustand 940, zugeschnitten.
Die Befehle, um den 3D-Pipelinezustand 930 zu konfigurieren, enthalten Festlegungsbefehle für den 3D-Zustand für den Vertexpufferzustand, Vertexelementzustand, konstanten Farbzustand, Tiefenpufferzustand und andere Zustandsvariablen, die zu konfigurieren sind, bevor 3D-Primitiven-Befehle verarbeitet werden. Die Werte dieser Befehle werden zumindest teilweise auf Basis der bestimmten 3D-API in Verwendung ermittelt. In einigen Ausführungsformen sind 3D-Pipelinezustandsbefehle 930 auch fähig, bestimmte Pipelineelemente selektiv zu deaktivieren oder zu umgehen, falls diese Elemente nicht verwendet werden.
In einigen Ausführungsformen wird ein 3D-Primitiven-Befehl 932 verwendet, um 3D-Primitiven zu übermitteln, die von der 3D-Pipeline zu verarbeiten sind. Befehle und zugehörige Parameter, die an den Grafikprozessor über den 3D-Primitiven-Befehl 932 übermittelt werden, werden an die Vertexabruffunktion in der Grafikpipeline weitergeleitet. Die Vertexabruffunktion verwendet die Daten des 3D-Primitiven-Befehls 932, um Vertexdatenstrukturen zu generieren. Die Vertexdatenstrukturen werden in einem oder mehreren Rückgabepuffern gespeichert. In einigen Ausführungsformen wird der 3D-Primitiven-Befehl 932 verwendet, um über Vertexshader Vertexoperationen an 3D-Primitiven durchzuführen. Um Vertexshader zu verarbeiten, verteilt die 3D-Pipeline 922 Shaderausführungsthreads an Grafikprozessor-Ausführungseinheiten.
In einigen Ausführungsformen wird die 3D-Pipeline 922 über einen Ausführungsbefehl 934 oder ein Ereignis ausgelöst. In einigen Ausführungsformen löst ein Registerschreibvorgang eine Befehlsausführung aus. In einigen Ausführungsformen wird die Ausführung über einen ,Los‘- oder ,Anstoß‘-Befehl in der Befehlsfolge ausgelöst. In einer Ausführungsform wird die Befehlsausführung unter Verwendung eines Pipelinesynchronisationsbefehls ausgelöst, um die Befehlsfolge durch die Grafikpipeline zu spülen. Die 3D-Pipeline führt eine Geometrieverarbeitung für die 3D-Primitiven aus. Sobald die Vorgänge abgeschlossen sind, werden die resultierenden geometrischen Objekte gerastert und die Pixelengine färbt die resultierenden Pixel ein. Zusätzliche Befehle, um eine Pixelschattierung und Pixel-Hintergrundoperationen zu steuern, können für diese Operationen auch enthalten sein.
In einigen Ausführungsformen folgt die Grafikprozessor-Befehlsfolge 910 beim Durchführen von Medienoperationen dem Pfad der Medienpipeline 924. Im Allgemeinen hängen die bestimmte Verwendung und die Art der Programmierung für die Medienpipeline 924 von den durchzuführenden Medien- oder Rechenoperationen ab. Spezifische Mediendecodieroperationen können während der Mediendecodierung an die Medienpipeline ausgelagert werden. In einigen Ausführungsformen kann die Medienpipeline auch umgangen werden und eine Mediendecodierung kann gänzlich oder teilweise unter Verwendung von Ressourcen durchgeführt werden, die von einem oder mehreren Universalverarbeitungskernen bereitgestellt werden. In einer Ausführungsform enthält die Medienpipeline auch Elemente für Operationen einer Universalgrafikprozessoreinheit (GPGPU), wobei der Grafikprozessor verwendet wird, um SIMD-Vektoroperationen unter Verwendung von rechnerischen Shaderprogrammen durchzuführen, die nicht explizit mit dem Rendern von Grafikgrundtypen verbunden sind.
In einigen Ausführungsformen ist die Medienpipeline 924 auf eine ähnliche Weise wie die 3D-Pipeline 922 konfiguriert. Ein Befehlssatz, um den Zustand der Medienpipeline 940 zu konfigurieren, wird vor den Medienobjektbefehlen 942 in eine Befehlswarteschlange verteilt oder platziert. In einigen Ausführungsformen enthalten die Befehle für den Medienpipelinezustand 940 Daten, um die Medienpipelineelemente zu konfigurieren, die verwendet werden, um die Medienobjekte zu verarbeiten. Dies enthält Daten, um die Videodecodier- und Videocodierlogik in der Medienpipeline zu konfigurieren, wie ein Codier- oder Decodierformat. In einigen Ausführungsformen unterstützen Befehle für den Medienpipelinezustand 940 auch die Verwendung von einem oder mehreren Zeigern auf „indirekte“ Zustandselemente, die eine Gruppe von Zustandseinstellungen enthalten.
In einigen Ausführungsformen liefern Medienobjektbefehle 942 Zeiger auf Medienobjekte zur Verarbeitung durch die Medienpipeline. Die Medienobjekte enthalten Speicherpuffer, die zu verarbeitende Videodaten enthalten. In einigen Ausführungsformen müssen alle Medienpipelinezustände gültig sein, bevor ein Medienobjektbefehl 942 erteilt wird. Sobald der Pipelinezustand konfiguriert ist und die Medienobjektbefehle 942 in die Warteschlange gereiht sind, wird die Medienpipeline 924 über einen Ausführungsbefehl 944 oder ein äquivalentes Ausführungsereignis (z. B. einen Registerschreibvorgang) ausgelöst. Eine Ausgabe von der Medienpipeline 924 kann dann durch von der 3D-Pipeline 922 oder der Medienpipeline 924 bereitgestellte Operationen nachbearbeitet werden. In einigen Ausführungsformen werden GPGPU-Operationen auf eine ähnliche Weise wie Medienoperationen konfiguriert und ausgeführt.
Grafiksoftwarearchitektur
10 veranschaulicht eine beispielhafte Grafiksoftwarearchitektur für ein Datenverarbeitungssystem 1000 nach einigen Ausführungsformen. In einigen Ausführungsformen enthält die Softwarearchitektur eine 3D-Grafikanwendung 1010, ein Betriebssystem 1020 und mindestens einen Prozessor 1030. In einigen Ausführungsformen enthält der Prozessor 1030 einen Grafikprozessor 1032 und einen oder mehrere Universalprozessorkerne 1034. Die Grafikanwendung 1010 und das Betriebssystem 1020 werden jeweils im Systemarbeitsspeicher 1050 des Datenverarbeitungssystems ausgeführt.
In einigen Ausführungsformen enthält die 3D-Grafikanwendung 1010 ein oder mehrere Shaderprogramme, die Shaderanweisungen 1012 enthalten. Die Shader-Sprachanweisungen können in einer höheren Shadersprache, wie der High Level Shader Language (HLSL) von Direct3D oder der OpenGL Shader Language (GLSL) und so weiter sein. Die Anwendung enthält auch ausführbare Anweisungen 1014 in einer zur Ausführung durch den Universalprozessorkern 1034 geeigneten Maschinensprache. Die Anwendung enthält auch Grafikobjekte 1016, die durch Vertexdaten definiert sind.
In einigen Ausführungsformen ist das Betriebssystem 1020 ein Microsoft® Windows®-Betriebssystem von der Microsoft Corporation, ein proprietäres UNIX-ähnliches Betriebssystem oder ein quelloffenes UNIX-ähnliches Betriebssystem, das eine Variante des Linux-Kernels verwendet. Das Betriebssystem 1020 kann eine Grafik-API 1022 wie die Direct3D-API, die OpenGL-API oder die Vulkan-API unterstützen. Wenn die Direct3D-API in Verwendung ist, verwendet das Betriebssystem 1020 einen Front-End-Shader-Compiler 1024, um eine Shader-Anweisung 1012 in HLSL in eine niedrigere Shadersprache zu compilieren. Die Compilierung kann eine einsatzsynchrone (JIT) Compilierung sein oder die Anwendung kann eine Shader-Vorcompilierung durchführen. In einigen Ausführungsformen werden Shader auf hoher Ebene während der Compilierung der 3D-Grafikanwendung 1010 in Shader auf niedriger Ebene compiliert. In einigen Ausführungsformen werden die Shaderanweisungen 1012 in einer Zwischenform bereitgestellt, wie einer Version der von der Vulkan-API verwendeten Standard Portable Intermediate Representation (SPIR).
In einigen Ausführungsformen enthält ein Benutzermodus-Grafiktreiber 1026 einen Back-End-Shader-Compiler 1027, um die Shaderanweisungen 1012 in eine hardwarespezifische Darstellung umzuwandeln. Wenn die OpenGL-API in Verwendung ist, werden Shaderanweisungen 1012 in der GLSL-Sprache auf hoher Ebene an einen Benutzermodus-Grafiktreiber 1026 zur Compilierung weitergeleitet. In einigen Ausführungsformen verwendet der Benutzermodus-Grafiktreiber 1026 Betriebssystemkernelmodusfunktionen 1028, um mit einem Kernelmodus-Grafiktreiber 1029 zu kommunizieren. In einigen Ausführungsformen kommuniziert der Kernelmodus-Grafiktreiber 1029 mit dem Grafikprozessor 1032, um Befehle und Anweisungen zu versenden.
IP-Kern-Implementierungen
Ein oder mehrere Gesichtspunkte mindestens einer Ausführungsform können durch repräsentativen Code implementiert sein, der auf einem maschinenlesbaren Medium gespeichert ist, das Logik in einem integrierten Schaltkreis wie einem Prozessor repräsentiert und/oder definiert. Das maschinenlesbare Medium kann zum Beispiel Anweisungen enthalten, die verschiedene Logik im Prozessor repräsentiert. Wenn sie von einer Maschine gelesen werden, können die Anweisungen die Maschine veranlassen, die Logik zu erzeugen, um die hierin beschriebenen Techniken durchzuführen. Derartige Darstellungen, als „IP-Kerne“ bekannt, sind wiederverwendbare Logikeinheiten für einen integrierten Schaltkreis, die auf einem greifbaren, maschinenlesbaren Medium als ein Hardwaremodell gespeichert sein können, das die Struktur des integrierten Schaltkreises beschreibt. Das Hardwaremodell kann an verschiedene Kunden oder Fertigungsanlagen geliefert werden, die das Hardwaremodell in Fertigungsmaschinen laden, die den integrierten Schaltkreis herstellen. Der integrierte Schaltkreis kann so gefertigt werden, dass der Schaltkreis Operationen durchführt, die im Zusammenhang mit beliebigen der hierin beschriebenen Ausführungsformen beschrieben wurden.
11A ist ein Blockdiagramm, das ein IP-Kern-Entwicklungssystem 1100 veranschaulicht, das verwendet werden kann, um einen integrierten Schaltkreis herzustellen, um Operationen nach einer Ausführungsform durchzuführen. Das IP-Kern-Entwicklungssystem 1100 kann verwendet werden, um modulare, wiederverwendbare Designs zu erstellen, die in ein größeres Design eingebunden werden können oder verwendet werden können, um einen gesamten integrierten Schaltkreis (z. B. einen integrierten SoC-Schaltkreis) zu konstruieren. Eine Designanlage 1130 kann eine Softwaresimulation 1110 eines IP-Kern-Designs in einer höheren Programmiersprache (z. B. C/C++) generieren. Die Softwaresimulation 1110 kann verwendet werden, um das Verhalten des IP-Kerns unter Verwendung eines Simulationsmodells 1112 zu konstruieren, testen und zu verifizieren. Das Simulationsmodell 1112 kann funktionale, Verhaltens- und/oder Zeitgebungssimulationen enthalten. Ein Design auf Registertransferebene (RTL) 1115 kann dann erstellt oder aus dem Simulationsmodell 1112 zusammengesetzt werden. Das RTL-Design 1115 ist eine Abstraktion des Verhaltens des integrierten Schaltkreises, das den Fluss digitaler Signale zwischen Hardwareregistern modelliert, einschließlich der assoziierten Logik, die unter Verwendung der modellierten digitalen Signale durchgeführt wird. Zusätzlich zu einem RTL-Design 1115 können auch Designs niedrigerer Ebenen auf Logikebene oder Transistorebene erstellt, konstruiert oder zusammengesetzt werden. Deshalb können die bestimmten Details des anfänglichen Designs und der Simulation variieren.
Das RTL-Design 1115 oder ein äquivalentes können weiter von der Designanlage in ein Hardwaremodell 1120 zusammengesetzt werden, das in einer Hardwarebeschreibungssprache (HDL) oder einer anderen Darstellung von physikalischen Designdaten sein kann. Die HDL kann weiter simuliert oder getestet werden, um das IP-Kern-Design zu verifizieren. Das IP-Kern-Design kann zur Lieferung an eine Fertigungsanlage von Dritten 1165 unter Verwendung von nichtflüchtigem Speicher 1140 (z. B. einer Festplatte, Flashspeicher oder einem beliebigen nichtflüchtigen Speichermedium) gespeichert werden. Alternativ kann das IP-Kern-Design über eine verdrahtete Verbindung 1150 oder drahtlose Verbindung 1160 (z. B. über das Internet) gesendet werden. Die Fertigungsanlage 1165 kann dann einen integrierten Schaltkreis fertigen, der zumindest teilweise auf dem IP-Kern-Design basiert. Der gefertigte integrierte Schaltkreis kann konfiguriert sein, Operationen nach mindestens einer hierin beschriebenen Ausführungsform durchzuführen.
11B veranschaulicht eine seitliche Querschnittsansicht einer integrierten Schaltkreisgehäuseanordnung 1170 nach einigen hierin beschriebenen Ausführungsformen. Die integrierte Schaltkreisgehäuseanordnung 1170 veranschaulicht eine Implementierung eines oder mehrerer Prozessor- oder Beschleunigervorrichtungen, wie sie hierin beschrieben sind. Die Gehäuseanordnung 1170 enthält mehrere Einheiten von Hardwarelogik 1172, 1174, die mit einem Substrat 1180 verbunden sind. Die Logik 1172, 1174 kann zumindest teilweise in konfigurierbarer Logik oder Logikhardware mit fester Funktionalität implementiert sein und kann einen oder mehrere Abschnitte eines der Prozessoren(e), Grafikprozessor(en) oder anderer hierin beschriebenen Beschleunigervorrichtungen enthalten. Jede Logikeinheit 1172, 1174 kann in einem Halbleiterchip implementiert sein und über eine Zwischenverbindungsstruktur 1173 an das Substrat 1180 gekoppelt sein. Die Zwischenverbindungsstruktur 1173 kann konfiguriert sein, elektrische Signale zwischen der Logik 1172, 1174 und dem Substrat 1180 zu leiten und kann Zwischenverbindungen wie unter anderem Lötperlen oder Säulen enthalten. In einigen Ausführungsformen kann die Zwischenverbindungsstruktur 1173 konfiguriert sein, elektrische Signale wie beispielsweise Eingabe/Ausgabe(E/A)-Signale und/oder Energie- oder Erdungssignale zu leiten, die mit dem Betrieb der Logik 1172, 1174 assoziiert sind. In einigen Ausführungsformen ist das Substrat 1180 ein Laminatsubstrat auf Epoxidbasis. Das Substrat 1180 kann in anderen Ausführungsformen andere geeignete Typen von Substraten enthalten. Die Gehäuseanordnung 1170 kann über eine Gehäusezwischenverbindung 1183 mit anderen elektrischen Vorrichtungen verbunden sein. Die Gehäusezwischenverbindung 1183 kann an eine Oberfläche des Substrats 1180 gekoppelt sein, um elektrische Signale an andere elektrische Vorrichtungen zu leiten, wie eine Hauptplatine, einen anderen Chipsatz oder ein Mehrchipmodul.
In einigen Ausführungsformen sind die Logikeinheiten 1172, 1174 elektrisch an eine Brücke 1182 gekoppelt, die konfiguriert ist, elektrische Signale zwischen der Logik 1172, 1174 zu leiten. Die Brücke 1182 kann eine dichte Zwischenverbindungsstruktur sein, die eine Route für elektrische Signale bietet. Die Brücke 1182 kann ein Brückensubstrat enthalten, das aus Glas oder einem geeigneten Halbleitermaterial besteht. Elektrische Leitungselemente können auf dem Brückensubstrat gebildet werden, um eine Chip-zu-Chip-Verbindung zwischen der Logik 1172, 1174 bereitzustellen.
Obwohl zwei Logikeinheiten 1172, 1174 und eine Brücke 1182 veranschaulicht sind, können hierin beschriebene Ausführungsformen mehr oder weniger Logikeinheiten auf einem oder mehreren Chips enthalten. Der eine oder die mehreren Chips können durch null oder mehr Brücken verbunden sein, da die Brücke 1182 ausgeschlossen sein kann, wenn die Logik auf einem einzelnen Chip enthalten ist. Alternativ können mehrere Chips oder Logikeinheiten durch eine oder mehrere Brücken verbunden sein. Zusätzlich können mehrere Logikeinheiten und Brücken zusammen in anderen möglichen Konfigurationen verbunden sein, einschließlich dreidimensionaler Konfigurationen.
11C veranschaulicht eine Gehäuseanordnung 1190, die mehrere Einheiten von Hardwarelogik-Einzelchips enthält, die mit einem Substrat 1180 (z. B. einem Basischip) verbunden sind. Eine Grafikverarbeitungseinheit, Parallelprozessor und/oder Rechenbeschleuniger wie hierin beschrieben kann bzw. können aus verschiedenen Silizium-Einzelchips bestehen, die getrennt hergestellt werden. In diesem Kontext ist ein Einzelchip ein zumindest teilweise eingehauster integrierter Schaltkreis, der individuelle Logikeinheiten enthält, die mit anderen Einzelchips in ein größeres Gehäusepaket zusammengesetzt werden können. Ein verschiedenartiger Satz von Einzelchips mit unterschiedlicher IP-Kernlogik kann in eine einzige Vorrichtung zusammengesetzt werden. Zusätzlich können die Einzelchips unter Verwendung von aktiver Zwischenschaltungstechnologie in einen Basischip oder Basis-Einzelchip integriert werden. 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 sein und während der Herstellung zusammengesetzt werden, was die Komplexität eines Zusammenlegens mehrerer IPs, insbesondere auf einem großen SoC mit mehreren Arten von IPs, auf den gleichen Herstellungsprozess vermeidet. Eine Ermöglichung der Verwendung mehrerer Prozesstechnologien verbessert die Produkteinführungszeit und bietet einen kostengünstigen Weg, mehrere Produkt-SKUs zu erzeugen. Darüber hinaus sind die getrennten IPs besser geeignet, unabhängig mit Energie angesteuert zu werden, Komponenten, die bei einer bestimmten Arbeitslast nicht in Verwendung sind, können ausgeschaltet werden, was den Gesamtenergieverbrauch reduziert.
Die Hardwarelogik-Einzelchips können Sonder-Hardwarelogik-Einzelchips 1172, Logik- oder E/A-Einzelchips 1174 und/oder Arbeitsspeicher-Einzelchips 1175 enthalten. Die Hardwarelogik-Einzelchips 1172 und Logik- oder E/A-Einzelchips 1174 können zumindest teilweise in konfigurierbarer Logik oder Logikhardware mit fester Funktionalität implementiert sein und können einen oder mehrere Abschnitte eines der Prozessoren(e), Grafikprozessor(en), Parallelprozessoren oder anderer hierin beschriebenen Beschleunigervorrichtungen enthalten. Die Arbeitsspeicher-Einzelchips 1175 können DRAM-Arbeitsspeicher (z. B. GDDR, HBM) oder Zwischenspeicher (SRAM) sein.
Jeder Einzelchip kann als ein getrennter Halbleiterchip gefertigt sein und über eine Zwischenverbindungsstruktur 1173 an das Substrat 1180 gekoppelt sein. Die Zwischenverbindungsstruktur 1173 kann ausgelegt sein, um elektrische Signale zwischen den verschiedenen Einzelchips und Logik innerhalb des Substrats 1180 zu leiten. Die Zwischenverbindungsstruktur 1173 kann Zwischenverbindungen wie unter anderem Lötperlen oder Säulen enthalten. In einigen Ausführungsformen kann die Zwischenverbindungsstruktur 1173 konfiguriert sein, elektrische Signale wie beispielsweise Eingabe/Ausgabe(E/A)-Signale und/oder Energie- oder Erdungssignale zu leiten, die mit dem Betrieb der Logik-, E/A- und Arbeitsspeicher-Einzelchips assoziiert sind.
In einigen Ausführungsformen ist das Substrat 1180 ein Laminatsubstrat auf Epoxidbasis. Das Substrat 1180 kann in anderen Ausführungsformen andere geeignete Typen von Substraten enthalten. Die Gehäuseanordnung 1190 kann über eine Gehäusezwischenverbindung 1183 mit anderen elektrischen Vorrichtungen verbunden sein. Die Gehäusezwischenverbindung 1183 kann an eine Oberfläche des Substrats 1180 gekoppelt sein, um elektrische Signale an andere elektrische Vorrichtungen zu leiten, wie eine Hauptplatine, einen anderen Chipsatz oder ein Mehrchipmodul.
In einigen Ausführungsformen können ein Logik- oder E/A-Einzelchip 1174 und ein Arbeitsspeicher-Einzelchip 1175 elektrisch über eine Brücke 1187 gekoppelt sein, die ausgelegt ist, elektrische Signale zwischen dem Logik- oder E/A-Einzelchip 1174 und einem Arbeitsspeicher-Einzelchip 1175 zu lenken. Die Brücke 1187 kann eine dichte Zwischenverbindungsstruktur sein, die eine Route für elektrische Signale bietet. Die Brücke 1187 kann ein Brückensubstrat enthalten, das aus Glas oder einem geeigneten Halbleitermaterial besteht. Elektrische Leitungselemente können auf dem Brückensubstrat gebildet werden, um eine Chip-zu-Chip-Verbindung zwischen der Logik oder dem E/A-Einzelchip 1174 und einem Arbeitsspeicher-Einzelchip 1175 bereitzustellen. Die Brücke 1187 kann auch als eine Siliziumbrücke oder eine Zwischenverbindungsbrücke bezeichnet werden. Die Brücke 1187 ist in einigen Ausführungsformen zum Beispiel eine Embedded Multi-Die Interconnect Bridge (EMIB). In einigen Ausführungsformen kann die Brücke 1187 einfach eine direkte Verbindung von einem Einzelchip zu einem anderen Einzelchip sein.
Das Substrat 1180 kann Hardwarekomponenten für E/A 1191, Zwischenspeicher 1192 und andere Hardwarelogik 1193 enthalten. Eine Fabric 1185 kann in das Substrat 1180 eingebettet sein, um eine Kommunikation zwischen den verschiedenen Logik-Einzelchips und der Logik 1191, 1193 innerhalb des Substrats 1180 zu ermöglichen. In einer Ausführungsform können die E/A 1191, Fabric 1185, der Zwischenspeicher, die Brücke und andere Hardwarelogik 1193 in einen Basischip integriert sein, der auf das Substrat 1180 geschichtet ist.
In verschiedenen Ausführungsformen kann eine Gehäuseanordnung 1190 weniger oder mehr Komponenten und Einzelkomponenten enthalten, die durch eine Fabric 1185 oder eine oder mehrere Brücken 1187 miteinander verbunden sind. Die Einzelchips innerhalb der Gehäuseanordnung 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 beispielsweise zwischen Logik- oder E/A-Einzelchips und Arbeitsspeicher-Einzelchips zu ermöglichen. Die Fabric 1185 kann verwendet werden, um die verschiedenen Logik- und/oder E/A-Einzelchips (z. B. die Einzelchips 1172, 1174, 1191, 1193) mit anderen Logik- und/oder E/A-Einzelchips zu verbinden. In einer Ausführungsform kann der Zwischenspeicher 1192 innerhalb des Substrats als ein globaler Zwischenspeicher für die Gehäuseanordnung 1190, als Teil eins verteilten globalen Zwischenspeichers oder als ein dedizierter Zwischenspeicher für die Fabric 1185 fungieren.
11D veranschaulicht eine Gehäuseanordnung 1194, die austauschbare Einzelchips 1195 enthält, nach einer Ausführungsform. Die austauschbaren Einzelchips 1195 können in standardisierte Schlitze auf einem oder mehreren Basis-Einzelchips 1196, 1198 zusammengesetzt werden. Die Basis-Einzelchips 1196, 1198 können über eine Brücken-Zwischenverbindung 1197 gekoppelt sein, die den anderen hierin beschriebenen Brücken-Zwischenverbindungen ähnlich sein kann und beispielsweise eine EMIB sein kann. Arbeitsspeicher-Einzelchips können auch über eine Brücken-Zwischenverbindung mit Logik- oder E/A-Einzelchips verbunden sein. E/A- und Logik-Einzelchips können über eine Zwischenverbindungsfabric kommunizieren. Die Basis-Einzelchips können jeweils einen oder mehrere Schlitze in einem standardisierten Format für entweder Logik oder E/A oder Arbeitsspeicher/Zwischenspeicher unterstützen.
In einer Ausführungsform können SRAM- und Energieversorgungsschaltkreise in einen oder mehrere der Basis-Einzelchips 1196, 1198 gefertigt sein, die unter Verwendung einer relativ zu den austauschbaren Einzelchips 1195, die auf den Basis-Einzelchips gestapelt sind, verschiedenen Prozesstechnologie gefertigt sein können. Beispielsweise können die Basis-Einzelchips 1196, 1198 unter Verwendung einer größeren Prozesstechnologie gefertigt sein, während die austauschbaren Einzelchips unter Verwendung einer kleineren Prozesstechnologie hergestellt sein können. Einer oder mehrere der austauschbaren Einzelchips 1195 können Arbeitsspeicher-Einzelchips (z. B. DRAM-Einzelchips) sein. Unterschiedliche Arbeitsspeicherdichten können für die Gehäuseanordnung 1194 auf Grundlage der Energie und/oder Leistung ausgewählt werden, auf die für das Produkt abgezielt wird, das die Gehäuseanordnung 1194 verwendet. Darüber hinaus können Logik-Einzelchips mit einer unterschiedlichen Anzahl von Typen von funktionalen Einheiten zum Zeitpunkt des Zusammenbaus auf Grundlage der Energie und/oder Leistung ausgewählt werden, auf die für das Produkt abgezielt wird. Darüber hinaus können Einzelchips, die IP-Logikkerne verschiedener Typen beinhalten, in die austauschbaren Einzelchipschlitze eingesetzt werden, was Hybrid-Prozessordesigns ermöglicht, die IP-Blöcke unterschiedlicher Technologien frei kombinieren können.
Beispielhafter integrierter Ein-Chip)-System-Schaltkreis
12-13 veranschaulichen beispielhafte integrierte Schaltkreise und zugehörige Grafikprozessoren, die unter Verwendung eines oder mehrerer IP-Kerne nach verschiedenen hierin beschriebenen Ausführungsformen gefertigt werden können. Zusätzlich zu den veranschaulichten können andere Logik und Schaltkreise enthalten sein, einschließlich zusätzlicher Grafikprozessoren/Kerne, peripherer Schnittstellensteuerungen oder Universalprozessorkerne.
12 ist ein Blockdiagramm, das einen beispielhaften integrierten Ein-Chip-System-Schaltkreis 1200 nach einer Ausführungsform veranschaulicht, der unter Verwendung eines oder mehrerer IP-Kerne gefertigt werden kann. Der beispielhafte integrierte Schaltkreis 1200 enthält einen oder mehrere Anwendungsprozessor(en) 1205 (z. B. CPUs), mindestens einen Grafikprozessor 1210 und kann zusätzlich einen Bildprozessor 1215 und/oder einen Videoprozessor 1220 enthalten, von denen beliebige ein modularer IP-Kern von der gleichen oder mehreren verschiedenen Designanlagen sein können. Der integrierte Schaltkreis 1200 enthält periphere oder Buslogik, die eine USB-Steuerung 1225, eine UART-Steuerung 1230, eine SPI/SDIO-Steuerung 1235 und eine I²S/I²C-Steuerung 1240 enthält. Zusätzlich kann der integrierte Schaltkreis eine Anzeigevorrichtung 1245 enthalten, die entweder an eine High-Definition-Multimedia-Interface(HDMI)-Steuerung 1250 und/oder eine Mobile-Industry-Processor-Interface(MIPI)-Anzeigeschnittstelle 1255 gekoppelt ist. Speicher kann durch ein Flashspeicher-Subsystem 1260 bereitgestellt werden, das Flasharbeitsspeicher und eine Flashspeichersteuerung enthält. Eine Arbeitsspeicherschnittstelle kann über eine Arbeitsspeichersteuerung 1265 zum Zugriff auf SDRAM- oder SRAM-Arbeitsspeichervorrichtungen bereitgestellt werden. Einige integrierte Schaltkreise enthalten zusätzlich eine eingebettete Sicherheitsengine 1270.
13A-13B sind Blockdiagramme, die beispielhafte Grafikprozessoren zur Verwendung innerhalb eines SoC nach hierin beschriebenen Ausführungsformen veranschaulichen. 13A veranschaulicht einen beispielhaften Grafikprozessor 1310 eines integrierten Ein-Chip-System-Schaltkreises nach einer Ausführungsform, der unter Verwendung eines oder mehrerer IP-Kerne gefertigt werden kann. 13B veranschaulicht einen weiteren beispielhaften Grafikprozessor 1340 eines integrierten Ein-Chip-System-Schaltkreises nach einer Ausführungsform, der unter Verwendung eines oder mehrerer IP-Kerne gefertigt werden kann. Der Grafikprozessor 1310 von 13A ist ein Beispiel eines Niedrigenergie-Grafikprozessorkerns. Der Grafikprozessor 1340 von 13B ist ein Beispiel eines Grafikprozessorkerns mit höherer Leistung. Jeder der Grafikprozessoren 1310, 1340 kann eine Variante des Grafikprozessors 1210 von 12 sein.
Wie in 13A gezeigt, enthält der Grafikprozessor 1310 einen Vertexprozessor 1305 und einen oder mehrere Fragmentprozessor(en) 1315A-1315N (z.B. 1315A, 1315B, 1315C, 1315D bis 1315N-1, und 1315N). Der Grafikprozessor 1310 kann über separate Logik unterschiedliche Shaderprogramme ausführen, sodass der Vertexprozessor 1305 optimiert ist, um Operationen für Vertexshaderprogramme auszuführen, während der eine oder die mehreren Fragmentprozessor(en) 1315A-1315N Fragmentschattierungsoperationen (z. B. Pixelschattierungsoperationen) für Fragment- oder Pixelshaderprogramme ausführen. Der Vertexprozessor 1305 führt die Vertexverarbeitungsphase der 3D-Grafikpipeline durch und erzeugt Primitive und Vertexdaten. Der bzw. die Fragmentprozessor(en) 1315A-1315N verwendet bzw. verwenden die vom Vertexprozessor 1305 generierten Primitiven- und Vertexdaten, um einen Rahmenpuffer zu erzeugen, der auf einer Anzeigevorrichtung angezeigt wird. In einer Ausführungsform ist bzw. sind der bzw. die Fragmentprozessor(en) 1315A-1315N optimiert, um Fragmentshaderprogramme auszuführen, wie sie in der OpenGL-API vorgesehen sind, die verwendet werden können, um ähnliche Operationen wie ein Pixelshaderprogramm durchzuführen, wie es in der Direct3D-API vorgesehen ist.
Der Grafikprozessor 1310 enthält zusätzlich eine oder mehrere Arbeitsspeicherverwaltungseinheiten (MMUs) 1320A-1320B, Zwischenspeicher 1325A-1325B und Schaltkreiszwischenverbindung(en) 1330A-1330B. Die eine oder die mehreren MMU(s) 1320A-1320B stellen eine virtuelle auf physische Adressenabbildung für den Grafikprozessor 1310 bereit, einschließlich für den Vertexprozessor 1305 und/oder den bzw. die Fragmentprozessor(en) 1315A-1315N, die auf im Arbeitsspeicher gespeicherte Vertex- oder Bild-/Texturdaten Bezug nehmen können, zusätzlich zu in dem einen oder den mehreren Zwischenspeichern 1325A-1325B gespeicherten Vertex- oder Bild-/Texturdaten. In einer Ausführungsform können die eine oder die mehreren MMU(s) 1320A-1320B mit anderen MMUs im System synchronisiert sein, einschließlich einer oder mehreren MMUs, die mit dem einen oder den mehreren Anwendungsprozessor(en) 1205, dem Bildprozessor 1215 und/oder dem Videoprozessor 1220 von 12 assoziiert sind, sodass jeder Prozessor 1205-1220 an einem gemeinsam genutzten oder vereinheitlichten virtuellen Arbeitsspeichersystem teilnehmen kann. Der eine oder die mehreren Schaltkreiszwischenverbindung(en) 1330A-1330B ermöglichen dem Grafikprozessor 1310, an andere IP-Kerne im SoC anzubinden, entweder über einen internen Bus des SoC oder über eine direkte Verbindung, nach Ausführungsformen.
Wie in 13B gezeigt, enthält der Grafikprozessor 1340 eine oder mehrere MMU(s) 1320A-1320B, Zwischenspeicher 1325A-1325B und Schaltkreiszwischenverbindung(en) 1330A-1330B des Grafikprozessors 1310 von 13A. Der Grafikprozessor 1340 enthält einen oder mehrere Shaderkern(e) 1355A-1355N (z. B. 1455A, 1355B, 1355C, 1355D, 1355E, 1355F bis 1355N-1 und 1355N), was eine einheitliche Shaderkernarchitektur bereitstellt, in der ein einzelner Kern oder Typ oder Kern alle Arten von programmierbarem Shadercode ausführen kann, einschließlich Shaderprogrammcode, um Vertexshader, Fragmentshader und/oder Rechenshader zu implementieren. Die genaue Anzahl der vorhandenen Shaderkerne kann zwischen Ausführungsformen und Implementierungen variieren. Zusätzlich enthält der Grafikprozessor 1340 eine Zwischenkern-Aufgabenverwaltung 1345, die als ein Thread-Dispatcher fungiert, um Ausführungsthreads an einen oder mehrere Shaderkerne 1355A-1355N und eine Kacheleinheit 1358 zur Beschleunigung von Kacheloperationen für kachelbasiertes Rendering zu verteilen, wobei Renderoperationen für eine Szene im Bildraum aufgeteilt werden, zum Beispiel, um eine lokale räumliche Kohärenz innerhalb einer Szene auszunutzen oder eine Verwendung von internen Zwischenspeichern zu optimieren.
14 veranschaulicht eine Ausführungsform einer Ausführungsform einer Rechenvorrichtung, die einen dynamischen Aktualisierungsmechanismus 1410 einsetzt. Beispielsweise kann der dynamische Aktualisierungsmechanismus 1410 von 14 von einer Rechenvorrichtung 1400 eingesetzt oder gehostet werden. Wie veranschaulicht kann ein dynamischer Aktualisierungsmechanismus 1410 nach einer Ausführungsform von einem Grafiktreiber 1416 gehostet werden oder Teil dieses sein.
In anderen Ausführungsformen kann der dynamische Aktualisierungsmechanismus 1410 von einer Grafikverarbeitungseinheit („GPU“ oder „Grafikprozessor“) 1414 gehostet werden oder Teil dieser sein. In noch anderen Ausführungsformen kann der dynamische Aktualisierungsmechanismus 1410 von einer Firmware einer Zentralverarbeitungseinheit („CPU“ oder „Anwendungsprozessor“) 1412 gehostet werden oder Teil dieser sein. Der Kürze und Klarheit halber und zum leichteren Verständnis kann der dynamische Aktualisierungsmechanismus 1410 im Rest dieses Dokuments als Teil der GPU 1414 besprochen werden; Ausführungsformen sind jedoch derart nicht eingeschränkt.
In noch einer anderen Ausführungsform kann der dynamische Aktualisierungsmechanismus 1410 als Software oder Firmwarelogik vom Betriebssystem 1406 gehostet werden. In noch einer weiteren Ausführungsform kann der dynamische Aktualisierungsmechanismus 1410 teilweise und gleichzeitig von mehreren Komponenten der Rechenvorrichtung 1400 gehostet werden, wie zum Beispiel einem oder mehreren vom Grafiktreiber 1416, der GPU 1414, GPU-Firmware, CPU 1412, CPU-Firmware, des Betriebssystems 1406 und/oder dergleichen. Es wird erwogen, dass der dynamische Aktualisierungsmechanismus 1410 oder eine oder mehrere seiner Komponenten als Hardware, Software und/oder Firmware implementiert sein können.
Die Rechenvorrichtung 1400 repräsentiert eine Kommunikations- und Datenverarbeitungsvorrichtung, die eine beliebige Anzahl und einen beliebigen Typ von intelligenten Vorrichtungen enthält oder repräsentiert, wie zum Beispiel (ohne Einschränkung) von intelligenten Befehlsvorrichtungen oder intelligenten Organizern, einem Heim-/Büroautomatisierungssystem, Haushaltsgeräten (z. B. Waschmaschinen, Fernsehern usw.), mobilen Vorrichtungen (z. B. Smartphones, Tablet-Computer usw.), Gamingvorrichtungen, in der Hand gehaltene Vorrichtungen, tragbare Vorrichtungen (z. B. Smartwatches, intelligente Armbänder usw.), Vorrichtungen für virtuelle Realität (VR), einer kopfmontierte Anzeige (HMDs), Vorrichtungen des Internets der Dinge (IdD), Laptopcomputer, Desktopcomputer, Servercomputer, Set-Top-Boxen (z. B. internetbasierte Kabelfernseh-Set-Top-Boxen usw.), Vorrichtungen auf Grundlage des globalen Positionierungssystems (GPS) usw.
In einigen Ausführungsformen kann die Rechenvorrichtung 1400 (ohne Einschränkung) autonome Maschinen oder Agenten mit künstlicher Intelligenz enthalten, wie mechanische Agenten oder Maschinen, Elektronikagenten oder Maschinen, virtuelle Agenten oder Maschinen, elektromechanische Agenten oder Maschinen usw. Beispiele autonomer Maschinen oder Agenten mit künstlicher Intelligenz können (ohne Einschränkung) Roboter, autonome Fahrzeuge (z. B. selbstfahrende Autos, selbstfliegende Flugzeuge, selbstfahrende Boote usw.), autonome Geräte (selbsttätig funktionierende Baumaschinen, selbsttätig funktionierende medizinische Geräte usw.) und/oder dergleichen enthalten. Ferner sind „autonome Fahrzeuge“ nicht auf Automobile beschränkt, sondern sie können eine beliebige Anzahl und einen beliebigen Typ von autonomen Maschinen enthalten, wie Roboter, autonome Geräte, autonome Haushaltsvorrichtungen und/oder dergleichen, und eine beliebige oder mehrere Aufgaben oder Operationen in Verbindung mit derartigen autonomen Maschinen können austauschbar mit autonomem Fahren referenziert werden.
Ferner kann die Rechenvorrichtung 1400 zum Beispiel eine Cloudrechenplattform enthalten, die aus einer Vielzahl von Servercomputern besteht, wobei jeder Servercomputer einen Mehrfunktions-Perzeptron-Mechanismus einsetzt oder hostet. Beispielsweise kann eine automatische ISP-Anpassung unter Verwendung einer früher in diesem Dokument beschriebenen Komponente, einem früher in diesem Dokument beschriebenen System und früher in diesem Dokument beschriebenen architektonischen Konfigurationen durchgeführt werden. Beispielsweise können einige der vorgenannten Typen von Vorrichtungen verwendet werden, um eine benutzerdefinierte erlernte Prozedur zu implementieren, wie unter Verwendung von feldprogrammierbaren Gatearrays (FPGAs) usw.
Ferner kann die Rechenvorrichtung 1400 zum Beispiel eine Computerplattform enthalten, die einen integrierten Schaltkreis („IC“), wie ein Ein-Chip-System („SoC‟ oder „SOC“) hostet, das verschiedene Hardware- und/oder SoftwareKomponenten der Rechenvorrichtung 1400 auf einem einzigen Chip integriert.
Wie veranschaulicht kann die Rechenvorrichtung 1400 in einer Ausführungsform eine beliebige Anzahl und einen beliebigen Typ von Hardware- und/oder Softwarekomponenten enthalten, wie zum Beispiel (ohne Einschränkung) eine Grafikverarbeitungseinheit 1414 („GPU“ oder einfach „Grafikprozessor“), einen Grafiktreiber 1416 (auch als „GPU-Treiber“, „Grafiktreiberlogik“, „Treiberlogik“, Benutzermodustreiber (UMD), UMD, Benutzermodus-Treiberframework (UMDF), UMDF oder einfach „Treiber“ bezeichnet), eine Zentralverarbeitungseinheit 1412 („CPU“ oder einfach „Anwendungsprozessor“), einen Arbeitsspeicher 1404, Netzwerkvorrichtungen, Treiber oder dergleichen sowie Eingabe/Ausgabe(E/A)-Quellen 1408, wie Berührungsbildschirme, Berührungstafeln, Berührungsfelder, virtuelle oder normale Tastaturen, virtuelle oder normale Mäuse, Anschlüsse, Verbindungsstücke usw. Die Rechenvorrichtung 1400 kann ein Betriebssystem (OS) enthalten, das als eine Schnittstelle zwischen Hardware- und/oder physischen Ressourcen der Rechenvorrichtung 1400 und einem Benutzer dient.
Es muss klar sein, dass ein weniger oder mehr ausgestattetes System als das oben beschriebene Beispiel für bestimmte Implementierungen bevorzugt werden kann. Deshalb kann die Konfiguration der Rechenvorrichtung 1400 von Implementierung zu Implementierung abhängig von zahlreichen Faktoren variieren, wie preisbedingte Einschränkungen, Leistungsanforderungen, technologischen Verbesserungen oder von anderen Umständen.
Ausführungsformen können als ein beliebiges von oder eine Kombination von Folgendem implementiert sein: einem oder mehreren Mikrochips oder integrierten Schaltkreisen, die unter Verwendung einer übergeordneten Leiterplatte verbunden sind, festverdrahteter Logik, von einer Arbeitsspeichervorrichtung gespeicherter und von einem Mikroprozessor ausgeführter Software, Firmware, einem anwendungsspezifischen integrierten Schaltkreis (ASIC) und/oder einem feldprogrammierbaren Gatearray (FPGA). Die Begriffe „Logik“, „Modul“, „Komponente“, „Engine“ und „Mechanismus“ können beispielsweise Software oder Hardware und/oder eine Kombination daraus enthalten, wie Firmware.
Nach einer Ausführungsform ist die Rechenvorrichtung 1400 über ein oder mehrere Netzwerke 1445 an eine oder mehrere Client-Rechenvorrichtungen (oder Clients) 1440 gekoppelt. Dementsprechend können der Server 1400 und der Client 1440 ferner eine Netzwerkschnittstelle bzw. Netzwerkschnittstellen enthalten, um Zugang zu einem Netzwerk bereitzustellen, wie einem LAN, einem Weitverkehrsnetz (WAN), einem innerstädtischen Netzwerk (MAN), einem persönlichen Netzwerk (PAN), Bluetooth, einem Cloudnetzwerk, einem mobilen Netzwerk (z. B. der 3. Generation (3G), der 4. Generation (4G) usw.), einem Intranetz, dem Internet usw. Die Netzwerkschnittstelle(n) kann bzw. können zum Beispiel eine drahtlose Netzwerkschnittstelle mit einer Antenne enthalten, die eine oder mehrere Antennen repräsentieren kann. Die Netzwerkschnittstelle(n) kann bzw. können beispielsweise auch eine verdrahtete Netzwerkschnittstelle enthalten, um mit entfernten Vorrichtungen über ein Netzwerkkabel zu kommunizieren, das zum Beispiel ein Ethernetkabel, ein Koaxialkabel, ein Lichtwellenleiterkabel, ein serielles Kabel oder ein paralleles Kabel sein kann.
Ausführungsformen können zum Beispiel als ein Computerprogrammprodukt bereitgestellt werden, das ein oder mehrere maschinenlesbare Medien mit darauf gespeicherten maschinenausführbaren Anweisungen enthalten kann, die bei Ausführung durch eine oder mehrere Maschinen wie einem Computer, einem Netzwerk von Computern oder anderen elektronischen Vorrichtungen dazu führen können, dass die eine oder die mehreren Maschinen Operationen in Übereinstimmung mit hierin beschriebenen Ausführungsformen ausführen. Ein maschinenlesbares Medium kann unter anderem Disketten, optische Platten, CD-ROMs (schreibgeschützte Compact-Disc-Arbeitsspeicher) und magnetooptische Platten, ROMs, RAMs, EPROMs (löschbare programmierbare schreibgeschützte Arbeitsspeicher), EEPROMs (elektrisch löschbare programmierbare schreibgeschützte Arbeitsspeicher), magnetische oder optische Karten, Flashspeicher oder einen anderen Typ von Medien/eines maschinenlesbaren Mediums enthalten, die bzw. das zum Speichern von maschinenausführbaren Anweisungen geeignet sind bzw. ist.
Darüber hinaus können Ausführungsformen als ein Computerprogrammprodukt heruntergeladen werden, wobei das Programm von einem entfernten Computer (z. B. einem Server) an einen anfordernden Computer (z. B. einem Client) über ein oder mehrere Datensignale übertragen werden kann, die in einer Trägerwelle oder einem anderen Ausbreitungsmedium über eine Kommunikationsverknüpfung (z. B. ein Modem und/oder eine Netzwerkverbindung) ausgebildet sind und/oder durch diese moduliert sind.
Im gesamten Dokument kann der Ausdruck „Benutzer“ austauschbar als „Betrachter“, „Beobachter“, „Sprecher“, „Person“, „Individuum“, „Endanwender“ und/oder dergleichen bezeichnet werden. Es ist anzumerken, dass in diesem gesamten Dokument Begriffe wie „Grafikdomäne“ austauschbar mit „Grafikverarbeitungseinheit“, „Grafikprozessor“ oder einfach „GPU“ referenziert werden können, und gleichermaßen kann „CPU-Domäne“ oder „Hostdomäne“ austauschbar mit „Computerverarbeitungseinheit“, „Anwendungsprozessor“ oder einfach „CPU“ referenziert werden.
Es ist anzumerken, dass Begriffe wie „Knoten“, „Rechenknoten“, „Server“, „Servervorrichtung“, „Cloud-Computer“, „Cloud-Server“, „Cloud-Servercomputer“, „Maschine“, „Hostmaschine“, „Vorrichtung“, „Rechenvorrichtung“, „Computer“, „Rechensystem“ und dergleichen in diesem gesamten Dokument austauschbar verwendet werden können. Es ist ferner anzumerken, dass Begriffe wie „Anwendung“, „Softwareanwendung“, „Programm“, „Softwareprogramm“, „Paket“, „Softwarepaket“ und dergleichen in diesem gesamten Dokument austauschbar verwendet werden können. Begriffe wie „Einzelvorgang“, „Eingabe“, „Anforderung“, „Nachricht“ und dergleichen können ebenfalls in diesem gesamten Dokument austauschbar verwendet werden.
Wie oben besprochen kann ein Bereitstellen einer dynamischen Eingabe in einen Shader aufgrund der Notwendigkeit, den Kernel vollständig neu compilieren zu müssen, mit Nachteilen verbunden sein. Ferner kann GPU-Hardware Push-Konstanten (z. B. einheitliche Werte, die in einem Befehlspuffer gespeichert sind und auf die von einem Shaderprogramm zugegriffen wird) implementieren, um dynamische Informationen von einem sekundären Puffer in den Kernel vor einer Ausführung per Push (oder Pull) zu übermitteln. Es gibt derzeit jedoch keine Option, die Daten nicht konstant zu machen, aufgrund der Art und Weise, wie diese konstanten Daten definiert sind. Ein Verhalten, das einem nicht konstanten Verhalten am nächsten ist, das erreicht werden könnte, ist durch Übertragen der Daten per Pull von einem sekundären Puffer in den Kernel. Nichtsdestotrotz sind die Daten im Puffer weiterhin konstant, obwohl die Kernel-ISA sie als nicht konstant erscheinen lässt. Dies ist einer Algebragleichung sehr ähnlich, in der:

F(x) = Cx, wobei x die Vertex-/Pixeldaten sind und C die ISA-/konstanten Daten sind.

Nach einer Ausführungsform stellt der dynamische Aktualisierungsmechanismus 1410 effiziente Datenkonstanten (C) durch Liefern von Informationen an einen Kernel ohne Neucompilierung eines Shaderprogramms bereit. In einer derartigen Ausführungsform bettet der dynamische Aktualisierungsmechanismus 1410 die aktualisierten Konstanten in einen Mikrocodeblock (oder ein Trampolin) ein und leitet den Block an ein Shaderprogramm weiter, wo der Block als eine Präambel zum ursprünglichen Shaderprogramm ausgeführt wird, um die aktualisierten Konstanten zur Ausführung des Shaderprogramms einzubinden. In einer weiteren Ausführungsform umfasst der Mikrocodeblock einen ISA-Block, der jedes Mal mit einer Sprunganweisung zu einem ursprünglichen Shaderprogramm gestreamt wird, wenn sich die Konstanten ändern.
Nach einer Ausführungsform ist ein Compiler 1415 enthalten, um ein Trampolin nach einer Erkennung bei einem dynamischen Aktualisierungsmechanismus 1410 zu generieren, dass sich eine oder mehrere Konstanten geändert haben. In einer Ausführungsform wird eine Aktualisierung an den Konstantendaten bei Empfangen von aktualisierten Daten von einem Treiber oder einer Anwendung erkannt. 15 veranschaulicht eine Ausführungsform eines Kernelheaps 1500. Wie in 15 gezeigt, enthält der Kernelheap 1500 ein Trampolin 1510 und einen ursprünglichen Kernel 1520. Das Trampolin 1510 codiert die aktualisierten Konstantendaten (oder Konstanten) in einer Gruppe von Bewegungsanweisungen mit einer Sprunganweisung am Ende, um zum ursprünglichen Shaderprogramm zurück zu navigieren. Beispielsweise enthält das Trampolin einen Vektor <1,0,0,1>, der zum ursprünglichen Kernel 1520 zu bewegen ist, der sich an einem Offset 0x1000 im Kernelheap 1500 befindet.
Nach einer Ausführungsform berechnet der Treiber 1416 den Offset auf Grundlage der Basisgrafikadresse des Kernelheaps 1500 und wobei der ursprüngliche Kernel 1520 in den Kernelheap 1500 abgebildet ist. In einer weiteren Ausführungsform arbeitet die Sprunganweisung (jmp) an einem 32-Bit-Offset, der in einem festen 4-GB-Heap 1500 implementiert ist. In einer anderen Ausführungsform kann ein Anweisungszeigerregister (z. B. innerhalb der GPU 1414) implementiert sein, um 64-Bit-Verzweigungen zu unterstützen.
In einer Ausführungsform kann eine Vielzahl von Trampolinen 1510 generiert werden und in den Kernelheap 1500 übertragen (oder gestreamt) werden, jedes Mal, wenn sich die Konstanten ändern. In einer derartigen Ausführungsform wird die GPU 1414 angewiesen, einen neuen Alias durch Ändern der Kerneladresse für die entsprechende Shaderstufe zu verwenden. 16 veranschaulicht eine Ausführungsform einer Konstantenänderung für eine Vertexshaderstufe. Wie in 16 gezeigt enthält ein Befehlspuffer 1600 Vertexshaderbefehle (VS-Befehle), die zur Generierung von Trampolinen 1510 (z. B. der Trampoline O-N und Trampoline M-Z) bei Erkennung von geänderten Konstanten führen. Nachfolgend werden die Trampoline 1510 an die jeweiligen Kernel 1520 (z. B. Kernel A und Kernel B) gestreamt.
Das Ändern der Vertexshader-Kerneladresse ist eine Operation in einer Pipeline, die kein Anhalten einführt. Falls sich jedoch der ursprüngliche Shader ändert, aber die Konstanten gleich bleiben, erzeugt das aktuelle Trampolin 1510 einen Alias, da sich der jmp-Offset ändert. Dementsprechend implementieren mehrere Shaderstufen eindeutige Alias abhängig von den Konstanten und den compilierten Kemels.
17 ist ein Ablaufdiagramm, das eine Ausführungsform eines Prozesses zum Durchführen einer dynamischen Aktualisierung veranschaulicht. Bei Verarbeitungsblock 1710 wird eine Aktualisierung an einer oder mehreren Konstanten während einer Ausführung eines ursprünglichen Shaderprogramms erkannt. Bei Verarbeitungsblock 1720 wird ein Trampolin generiert, das die aktualisierten Konstanten enthält. Bei Verarbeitungsblock 1730 wird das Trampolin an das ursprüngliche Shaderprogramm übertragen. Bei Verarbeitungsblock 1740 nimmt das ursprüngliche Shaderprogramm eine Ausführung mit den aktualisierten Konstanten wieder auf.
Der oben beschriebene Mechanismus ermöglicht, dass Shaderkonstanten aktualisiert werden, ohne eine Hardwareunterstützung zu erfordern. Darüber hinaus vermeidet der Mechanismus die Arbeitsspeicherabruflatenz von sowohl dem Push- als auch dem Pull-Modell, da die Konstanten von einer CPU vorbereitet (z. B. compiliert) werden.
Die folgenden Paragrafen und/oder Beispiele betreffen weitere Ausführungsformen oder Beispiele. Spezifisches in den Beispielen kann überall in einer oder mehreren Ausführungsformen verwendet werden. Die verschiedenen Merkmale der verschiedenen Ausführungsformen oder Beispiele können auf verschiedene Weise kombiniert werden, wobei einige Merkmale enthalten sind und andere ausgeschlossen sind, um einer Vielzahl unterschiedlicher Anwendungen zu genügen. Beispiele können einen Gegenstand umfassen, wie ein Verfahren, Mittel zum Durchführen von Handlungen des Verfahrens, mindestens ein maschinenlesbares Medium mit Anweisungen, die, wenn sie von einer Maschine ausgeführt werden, die Maschine dazu veranlassen, Handlungen des Verfahrens oder einer Einrichtung oder eines Systems zum Ermöglichen einer Hybridkommunikation nach hierin beschriebenen Ausführungsformen und Beispielen durchzuführen.
Einige Ausführungsformen betreffen Beispiel 1, das eine Einrichtung zum Ermöglichen einer Aktualisierung von Shader-Datenkonstanten enthält, umfassend einen oder mehrere Prozessoren, um eine Änderung an einer oder mehreren Datenkonstanten in einem Shaderprogramm zu erkennen, einen Mikrocodeblock, der aktualisierte Konstantendaten enthält, während einer Ausführung des Shaderprogramms zu generieren und den Mikrocodeblock an das Shaderprogramm zu senden.
Beispiel 2 enthält den Gegenstand von Beispiel 1, wobei der Mikrocodeblock als eine Präambel zum Shaderprogramm ausgeführt wird, um die aktualisierten Konstanten zur Ausführung des Shaderprogramms einzubinden.
Beispiel 3 enthält den Gegenstand von Beispiel 1 und 2, wobei das Shaderprogramm einen Kernelheap umfasst, der den Mikrocodeblock und einen Shaderprogrammkernel enthält.
Beispiel 4 enthält den Gegenstand der Beispiele 1-3, wobei der Mikrocodeblock die aktualisierten Konstantendaten umfasst, die in einer oder mehreren Bewegungsanweisungen codiert sind.
Beispiel 5 enthält den Gegenstand der Beispiele 1-4, wobei der Mikrocodeblock ferner eine Sprunganweisung zum Shaderprogrammkernel umfasst.
Beispiel 6 enthält den Gegenstand der Beispiele 1-5, wobei die Sprunganweisung auf einem Offset des Shaderprogrammkernels im Kernelheap beruht.
Beispiel 7 enthält den Gegenstand der Beispiele 1-6, wobei der Offset auf Grundlage einer Basisadresse des Kernelheaps berechnet wird.
Beispiel 8 enthält den Gegenstand der Beispiele 1-7, wobei der Mikrocodeblock einen Block einer Anweisungssatzarchitektur (ISA) umfasst.
Einige Ausführungsformen betreffen Beispiel 9, das ein Verfahren zum Ermöglichen einer Aktualisierung von Shader-Datenkonstanten enthält, umfassend Erkennen einer Änderung an einer oder mehreren Datenkonstanten in einem Shaderprogramm, Generieren eines Mikrocodeblocks, der aktualisierte Konstantendaten enthält, während einer Ausführung des Shaderprogramms und Senden des Mikrocodeblocks an das Shaderprogramm.
Beispiel 10 enthält den Gegenstand von Beispiel 9, wobei der Mikrocodeblock als eine Präambel zum Shaderprogramm ausgeführt wird, um die aktualisierten Konstanten zur Ausführung des Shaderprogramms einzubinden.
Beispiel 11 enthält den Gegenstand von Beispiel 9 und 10, wobei das Shaderprogramm einen Kernelheap umfasst, der den Mikrocodeblock und einen Shaderprogrammkernel enthält.
Beispiel 12 enthält den Gegenstand der Beispiele 9-11, wobei der Mikrocodeblock die aktualisierten Konstantendaten, die in einer oder mehreren Bewegungsanweisungen codiert sind, und eine Sprunganweisung zum Shaderprogrammkernel umfasst.
Beispiel 13 enthält den Gegenstand der Beispiele 9-11, wobei die Sprunganweisung auf einem Offset des Shaderprogrammkernels im Kernelheap beruht.
Beispiel 14 enthält den Gegenstand der Beispiele 9-11, wobei der Offset auf Grundlage einer Basisadresse des Kernelheaps berechnet wird.
Einige Ausführungsformen betreffen Beispiel 15, das mindestens ein computerlesbares Medium mit darauf gespeicherten Anweisungen enthält, die bei Ausführung durch einen oder mehrere Prozessoren die Prozessoren veranlassen, eine Änderung an einer oder mehreren Datenkonstanten in einem Shaderprogramm zu erkennen, einen Mikrocodeblock, der aktualisierte Konstantendaten enthält, während einer Ausführung des Shaderprogramms zu generieren und den Mikrocodeblock an das Shaderprogramm zu senden.
Beispiel 16 enthält den Gegenstand von Beispiel 15, wobei der Mikrocodeblock als eine Präambel zum Shaderprogramm ausgeführt wird, um die aktualisierten Konstanten zur Ausführung des Shaderprogramms einzubinden.
Beispiel 17 enthält den Gegenstand von Beispiel 15 und 16, wobei das Shaderprogramm einen Kernelheap umfasst, der den Mikrocodeblock und einen Shaderprogrammkernel enthält.
Beispiel 18 enthält den Gegenstand der Beispiele 9-17, wobei der Mikrocodeblock die aktualisierten Konstantendaten, die in einer oder mehreren Bewegungsanweisungen codiert sind, und eine Sprunganweisung zum Shaderprogrammkernel umfasst.
Beispiel 19 enthält den Gegenstand der Beispiele 9-18, wobei die Sprunganweisung auf einem Offset des Shaderprogrammkernels im Kernelheap beruht.
Beispiel 20 enthält den Gegenstand der Beispiele 9-19, wobei der Offset auf Grundlage einer Basisadresse des Kernelheaps berechnet wird.
Die Erfindung wurde oben unter Bezugnahme auf bestimmte Ausführungsformen beschrieben. Fachleute verstehen jedoch, dass verschiedene Modifikationen und Änderungen daran vorgenommen werden können, ohne vom allgemeinen Gedanken und Umfang der Erfindung abzuweichen, wie in den beigefügten Ansprüchen dargelegt. Die vorstehende Beschreibung und die vorstehenden Zeichnungen sollen dementsprechend in einem veranschaulichenden Sinn statt in einem einschränkenden Sinn betrachtet werden.

Claims

Einrichtung zum Ermöglichen einer Aktualisierung von Shader-Datenkonstanten, umfassend: einen oder mehrere Prozessoren, um eine Änderung an einer oder mehreren Datenkonstanten in einem Shaderprogramm zu erkennen, einen Mikrocodeblock, der aktualisierte Konstantendaten enthält, während einer Ausführung des Shaderprogramms zu generieren und den Mikrocodeblock an das Shaderprogramm zu senden.
Einrichtung nach Anspruch 1, wobei der Mikrocodeblock als eine Präambel zum Shaderprogramm ausgeführt wird, um die aktualisierten Konstanten zur Ausführung des Shaderprogramms einzubinden.
Einrichtung nach Anspruch 1 oder 2, wobei das Shaderprogramm einen Kernelheap umfasst, der den Mikrocodeblock und einen Shaderprogrammkernel enthält.
Einrichtung nach den Ansprüchen 1-3, wobei der Mikrocodeblock die aktualisierten Konstantendaten umfasst, die in einer oder mehreren Bewegungsanweisungen codiert sind.
Einrichtung nach den Ansprüchen 1-4, wobei der Mikrocodeblock ferner eine Sprunganweisung zum Shaderprogrammkernel umfasst.
Einrichtung nach den Ansprüchen 1-5, wobei die Sprunganweisung auf einem Offset des Shaderprogrammkernels im Kernelheap beruht.
Einrichtung nach den Ansprüchen 1-6, wobei der Offset auf Grundlage einer Basisadresse des Kernelheaps berechnet wird.
Einrichtung nach den Ansprüchen 1-7, wobei der Mikrocodeblock einen Block einer Anweisungssatzarchitektur (ISA) umfasst.
Verfahren zum Ermöglichen einer Aktualisierung von Shader-Datenkonstanten, umfassend: Erkennen einer Änderung an einer oder mehreren Datenkonstanten in einem Shaderprogramm; Generieren eines Mikrocodeblocks, der aktualisierte Konstantendaten enthält, während einer Ausführung des Shaderprogramms; und Senden des Mikrocodeblocks an das Shaderprogramm.
Verfahren nach Anspruch 9, wobei der Mikrocodeblock als eine Präambel zum Shaderprogramm ausgeführt wird, um die aktualisierten Konstanten zur Ausführung des Shaderprogramms einzubinden.
Verfahren nach Anspruch 9 oder 10, wobei das Shaderprogramm einen Kernelheap umfasst, der den Mikrocodeblock und einen Shaderprogrammkernel enthält.
Verfahren nach den Ansprüchen 9-11, wobei der Mikrocodeblock die aktualisierten Konstantendaten, die in einer oder mehreren Bewegungsanweisungen codiert sind, und eine Sprunganweisung zum Shaderprogrammkernel umfasst.
Verfahren nach den Ansprüchen 9-12, wobei die Sprunganweisung auf einem Offset des Shaderprogrammkernels im Kernelheap beruht.
Verfahren nach den Ansprüchen 9-13, wobei der Offset auf Grundlage einer Basisadresse des Kernelheaps berechnet wird.
Mindestens ein computerlesbares Medium mit darauf gespeicherten Anweisungen, die bei Ausführung durch einen oder mehrere Prozessoren die Prozessoren veranlassen: eine Änderung an einer oder mehreren Datenkonstanten in einem Shaderprogramm zu erkennen; einen Mikrocodeblock, der aktualisierte Konstantendaten enthält, während einer Ausführung des Shaderprogramms zu generieren; und den Mikrocodeblock an das Shaderprogramm zu senden.
Computerlesbares Medium nach Anspruch 15, wobei der Mikrocodeblock als eine Präambel zum Shaderprogramm ausgeführt wird, um die aktualisierten Konstanten zur Ausführung des Shaderprogramms einzubinden.
Computerlesbares Medium nach Anspruch 15 oder 16, wobei das Shaderprogramm einen Kernelheap umfasst, der den Mikrocodeblock und einen Shaderprogrammkernel enthält.
Computerlesbares Medium nach den Ansprüchen 15-17, wobei der Mikrocodeblock die aktualisierten Konstantendaten, die in einer oder mehreren Bewegungsanweisungen codiert sind, und eine Sprunganweisung zum Shaderprogrammkernel umfasst.
Computerlesbares Medium nach den Ansprüchen 15-18, wobei die Sprunganweisung auf einem Offset des Shaderprogrammkernels im Kernelheap beruht.
Computerlesbares Medium nach den Ansprüchen 15-19, wobei der Offset auf Grundlage einer Basisadresse des Kernelheaps berechnet wird.