DE102019120922A1

DE102019120922A1 - Vorrichtung und verfahren für multifrequenz-vertex-shadinghintergrund

Info

Publication number: DE102019120922A1
Application number: DE102019120922.6A
Authority: DE
Inventors: John Gierach; Daniel Walsh; John Feit; Devan Burke
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2018-08-28
Filing date: 2019-08-02
Publication date: 2020-03-05
Also published as: US10839597B2; US20200074726A1

Abstract

Vorrichtung und Verfahren für einen Multifrequenz-Vertex-Shader. Zum Beispiel umfasst eine Ausführungsform einer Grafikverarbeitungsvorrichtung eine Vielzahl von Vertex-Caches, um mit Grafik-Grundkörpern verbundene Vertexdaten zu speichern; und Grafikausführungsschaltungen, um Vertex-Shader auszuführen, die bei unterschiedlichen Verarbeitungsraten für unterschiedliche Sätze der Vertexdaten betriebsfähig sind, wobei jeder der unterschiedlichen Sätze von Vertexdaten einen damit verbundenen unterschiedlichen Typ von Identifikator aufweist, um die Vertexdaten zu identifizieren.

Description

Gebiet der Erfindung
Diese Erfindung bezieht sich allgemein auf das Gebiet von Grafikprozessoren. Insbesondere bezieht sich die Erfindung auf eine Vorrichtung und ein Verfahren für Multifrequenz-Vertex-Shading.
Beschreibung des Stands der Technik
Ein Shader ist eine Art von Programmcode, der eine Vielfalt an spezialisierten Funktionen in einem Grafikprozessor durchführt. Zum Beispiel berechnen Shader Renderingeffekte auf Grafik-Hardware mit einem hohen Grad an Flexibilität.
Shading-Sprachen werden zum Programmieren der programmierbaren GPU-Rendering-Pipeline verwendet, die weitgehend überholte Festfunktions-Pipelines aufweist, die nur allgemeine Geometrie-Transformations- und Pixel-Shading-Funktionen erlaubten. Mit Shadern können angepasste Effekte verwendet werden.
Vertex-Shader sind eine Art von 3D-Shader, die für jeden an den Grafikprozessor abgegebenen Vertex einmal ausgeführt werden. Der Vertex-Shader hat die Aufgabe, die 3D-Position jedes Vertex im virtuellen Raum auf die 2D-Koordinate zu transformieren, an welcher er auf dem Bildschirm erscheint (sowie einen Tiefenwert für den Z-Puffer). Die Ausgabe des Vertex-Shaders geht zu der nächsten Stufe in der Pipeline, die ein Geometrie-Shader, eine Tessellations-Pipeline, falls vorhanden, oder ein Rasterer ist.
Figurenliste
Ein besseres Verständnis der vorliegenden Erfindung kann von der folgenden detaillierten Beschreibung in Verbindung mit den folgenden Zeichnungen erhalten werden, wobei:

1 ist ein Blockdiagramm einer Ausführungsform eines Computersystems mit einem Prozessor, der ein oder mehrere Prozessorkerne und Grafikprozessoren aufweist;
2 ist ein Blockdiagramm einer Ausführungsform eines Prozessors, der ein oder mehrere Prozessorkerne, einen integrierten Speichercontroller und einen integrierten Grafikprozessor aufweist;
3 ist ein Blockdiagramm einer Ausführungsform eines Grafikprozessors, der eine diskrete Grafikverarbeitungseinheit oder ein mit einer Vielzahl von Prozessorkernen integrierter Grafikprozessor sein kann;
4 ist ein Blockdiagramm einer Ausführungsform einer Grafikverarbeitungs-Engine für einen Grafikprozessor;
5 ist ein Blockdiagramm einer weiteren Ausführungsform eines Grafikprozessors;
6 ist ein Blockdiagramm von Thread-Ausführungslogik, die ein Array von Verarbeitungselementen aufweist;
7 stellt ein Befehlsformat einer Grafikprozessor-Ausführungseinheit gemäß einer Ausführungsform dar;
8 ist ein Blockdiagramm einer weiteren Ausführungsform eines Grafikprozessors, der eine Grafik-Pipeline, eine Medien-Pipeline, eine Display-Engine, eine Thread-Ausführungslogik und eine Render-Ausgabe-Pipeline aufweist;
9A ist ein Blockdiagramm, das ein Grafikprozessor-Befehlsformat gemäß einer Ausführungsform darstellt;
9B ist ein Blockdiagramm, das eine Grafikprozessor-Befehlssequenz gemäß einer Ausführungsform darstellt;
10 stellt eine beispielhafte Grafik-Softwarearchitektur für ein Datenverarbeitungssystem gemäß einiger Ausführungsformen dar;
11 stellt ein beispielhaftes IP-Kernentwicklungssystem dar, das gemäß einer Ausführungsform zur Herstellung einer integrierten Schaltung verwendet werden kann, um Operationen durchzuführen;
12 stellt eine beispielhafte integrierte Ein-Chip-System-Schaltung dar, die gemäß einer Ausführungsform unter Verwendung von ein oder mehreren IP-Kernen hergestellt werden kann;
13 stellt einen beispielhaften Grafikprozessor einer integrierten Ein-Chip-System-Schaltung dar, der gemäß einer Ausführungsform unter Verwendung von ein oder mehreren IP-Cores hergestellt werden kann;
14 stellt einen zusätzlichen beispielhaften Grafikprozessor einer integrierten Ein-Chip-System-Schaltung dar, der unter Verwendung von ein oder mehreren IP-Cores hergestellt werden kann;
15 stellt eine Ausführungsform einer Architektur dar, die einen Multifrequenz-Vertex-Shader aufweist;
16 stellt eine Ausführungsform eines Verfahrens für Vertex-Shading dar;
17 stellt ein Verfahren im Einklang mit einer Ausführungsform der Erfindung dar;
18A-H stellen Pseudo-Code zum Implementieren einer Ausführungsform der Erfindung dar;
19 stellt eine Ausführungsform einer Architektur dar, die unterschiedliche Arten von Vertex-Shadern aufweist;
20 stellt eine Ausführungsform der Erfindung mit einem spezifischen Satz von Verbindungen zwischen unterschiedlichen Vertex-Shadern dar; und
21 stellt Pseudo-Code dar, der die Operation einer Ausführungsform der Erfindung repräsentiert.

AUSFÜHRLICHE BESCHREIBUNG
In der folgenden Beschreibung werden zu Erläuterungszwecken zahlreiche spezifische Details dargelegt, um ein fundiertes Verständnis der Ausführungsformen der nachstehend beschriebenen Erfindung zu bieten. Für eine fachkundige Person ist es jedoch offensichtlich, dass die Ausführungsformen der Erfindung ohne einige dieser spezifischen Details praktiziert werden können. In anderen Fällen werden bekannte Strukturen und Vorrichtungen in Blockdiagrammform gezeigt, um eine Verschleierung der Grundprinzipien der Erfindung zu vermeiden.
BEISPIELHAFTE GRAFIKPROZESSOR-ARCHITEKTUREN UND DATENTYPEN
Systemübersicht
1 ist ein Blockdiagramm eines Verarbeitungssystems 100 gemäß einer Ausführungsform. In verschiedenen Ausführungsformen umfasst das System 100 ein oder mehrere Prozessoren 102 und ein oder mehrere Grafikprozessoren 108 und kann ein Einzelprozessor-Desktopsystem, ein Multiprozessor-Arbeitsplatzsystem oder ein Serversystem sein, das eine große Anzahl von Prozessoren 102 oder Prozessorkernen 107 aufweist. In einer Ausführungsform ist das System 100 eine Verarbeitungsplattform, die in einer integrierten Schaltung als Ein-Chip-System (SoC) für den Einsatz in mobilen, handgehaltenen oder integrierten Vorrichtungen einbezogen sein kann.
In einer Ausführungsform kann das System 100 eine serverbasierte Spielplattform, eine Spielkonsole, einschließlich einer Spiel- und Medienkonsole, eine mobile Spielkonsole, eine handgehaltene Spielkonsole oder eine Online-Spielkonsole enthalten oder darin integriert sein. In einigen Ausführungsformen ist das System 100 ein Mobiltelefon, ein Smartphone, eine Tablet-Rechenvorrichtung oder eine mobile Internet-Vorrichtung. Das Verarbeitungssystem 100 kann auch eine tragbare Vorrichtung, wie etwa eine tragbare Smart Watch-Vorrichtung, eine Smart Eyewear-Vorrichtung, eine Vorrichtung für erweiterte Realität oder eine Vorrichtung für virtuelle Realität enthalten, damit gekoppelt oder darin integriert sein. In einigen Ausführungsformen ist das Verarbeitungssystem 100 ein Fernsehgerät oder eine Set-Top-Box, die ein oder mehrere Prozessoren 102 und eine grafische Benutzeroberfläche aufweist, die von ein oder mehreren Grafikprozessoren 108 erzeugt wird.
In einigen Ausführungsformen enthalten die ein oder mehreren Prozessoren 102 jeweils ein oder mehrere Prozessorkerne 107, um Befehle zu verarbeiten, die, wenn sie ausgeführt werden, Operationen für System- und Benutzersoftware durchführen. In einigen Ausführungsformen ist jeder der ein oder mehreren Prozessorkerne 107 dazu ausgebildet, einen bestimmten Befehlssatz 109 zu verarbeiten. In einigen Ausführungsformen kann der Befehlssatz 109 Complex Instruction Set Computing (CISC), Reduced Instruction Set Computing (RISC) oder Datenverarbeitung über ein Very Long Instruction Word (VLIW) unterstützen. Mehrere Prozessorkerne 107 können jeweils einen unterschiedlichen Befehlssatz 109 verarbeiten, der Befehle enthalten kann, um die Emulation anderer Befehlssätze zu unterstützen. Der Prozessorkern 107 kann auch andere Verarbeitungsvorrichtungen, wie etwa einen Digitalsignalprozessor (DSP), enthalten.
In einigen Ausführungsformen enthält der Prozessor 102 einen Cache-Speicher 104. Abhängig von der Architektur kann der Prozessor 102 einen einzigen internen Cache oder mehrere Ebenen von internem Cache aufweisen. In einigen Ausführungsformen wird der Cache-Speicher von verschiedenen Komponenten des Prozessors 102 gemeinsam genutzt. In einigen Ausführungsformen nutzt der Prozessor 102 auch einen externen Cache (z. B. einen Level-3 (L3)-Cache oder Last Level Cache (LLC)) (nicht gezeigt), der von Prozessorkernen 107 unter Verwendung von bekannten Cache-Kohärenztechniken gemeinsam genutzt werden kann. Zusätzlich in dem Prozessor 102 enthalten ist eine Registerdatei 106, die unterschiedliche Arten von Registern zum Speichern unterschiedlicher Arten von Daten (z. B. Ganzzahlenregister, Gleitkommaregister, Statusregister und ein Befehlszeigerregister) enthalten kann. Einige Register können Allzweckregister sein, während andere Register für das Design des Prozessors 102 spezifisch sein können.
In einigen Ausführungsformen ist (sind) ein oder mehrere Prozessor(en) 102 mit einem oder mehreren Schnittstellenbus(sen) 110 gekoppelt, um Kommunikationssignale, wie etwa Adressen, Daten oder Steuersignale zwischen dem Prozessor 102 und anderen Komponenten in dem System 100 zu übertragen. Der Schnittstellenbus 110 kann in einer Ausführungsform ein Prozessorbus sein, wie z. B. eine Version des Direct Media Interface (DMI)-Busses. 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), Speicherbusse oder andere Arten von Schnittstellenbussen einschließen. In einer Ausführungsform enthält (enthalten) der Prozessor (die Prozessoren) 102 einen integrierten Speichercontroller 116 und einen Plattform-Controllerhub 130. Der Speichercontroller 116 unterstützt Kommunikation zwischen einer Speichervorrichtung und anderen Komponenten des Systems 100, während der Plattform-Controllerhub (PCH) 130 Verbindungen zu E/A-Vorrichtungen über einen lokalen E/A-Bus bereitstellt.
Die Speichervorrichtung 120 kann eine dynamische Direktzugriffsspeicher (DRAM)-Vorrichtung, eine statische Direktzugriffsspeicher (SRAM)-Vorrichtung, eine Flash-Speichervorrichtung, eine Phasenwechsel-Speichervorrichtung oder eine andere Speichervorrichtung sein, die eine geeignete Leistung aufweist, um als Prozessspeicher zu dienen. In einer Ausführungsform kann die Speichervorrichtung 120 als Systemspeicher für das System 100 arbeiten, um Daten 122 und Befehle 121 zum Gebrauch zu speichern, wenn die ein oder mehreren Prozessoren 102 eine Anwendung oder einen Prozess ausführen. Der Speichercontroller 116 wird auch mit einem optionalen externen Grafikprozessor 112 gekoppelt, der mit den ein oder mehreren Grafikprozessoren 108 in den Prozessoren 102 kommuniziert, um Grafik- und Medienoperationen durchzuführen. In einigen Ausführungsformen kann eine Anzeigevorrichtung 111 mit dem (den) Prozessor(en) 102 verbunden werden. Die Anzeigevorrichtung 111 kann eine oder mehrere einer internen Anzeigevorrichtung, wie etwa in einer mobilen elektronischen Vorrichtung, oder einer Laptop-Vorrichtung oder einer externen Anzeigevorrichtung sein, die über eine Anzeigeschnittstelle (z. B. DisplayPort usw.) angebracht sein kann. In einer Ausführungsform kann die Anzeigevorrichtung 111 ein Head-Mounted Display (HMD), wie etwa eine stereoskopische Anzeigevorrichtung, für den Einsatz in Virtual Reality (VR)-Anwendungen oder Augmented Reality (AR)-Anwendungen sein.
In einigen Ausführungsformen versetzt der Plattform-Controllerhub 130 Peripheriegeräte in die Lage, eine Verbindung mit der Speichervorrichtung 120 und dem Prozessor 102 über einen Hochgeschwindigkeits-E/A-Bus herzustellen. Die E/A-Peripheriegeräte umfassen, sind aber nicht beschränkt auf, einen Audiocontroller 146, einen Netzwerkcontroller 134, eine Firmware-Schnittstelle 128, einen Funk-Transceiver 126, Berührungssensoren 125, eine Datenspeichervorrichtung 124 (z. B. Festplattenlaufwerk, Flash-Speicher usw.). Die Datenspeichervorrichtung 124 kann über eine Speicherschnittstelle (z. B. SATA) oder über einen Peripheriebus, wie z. B. einen Peripheral Component Interconnect-Bus (z. B. PCI, PCI Express) verbunden werden. Die Berührungssensoren 125 können Touchscreensensoren, Drucksensoren oder Fingerabdrucksensoren einschließen. Der Funk-Transceiver 126 kann ein Wi-Fi-Transceiver, ein Bluetooth-Transceiver oder ein Mobilnetzwerk-Transceiver, wie z. B. ein 3G-, 4G- oder Long-Term Evolution (LTE)-Transceiver, sein. Die Firmware-Schnittstelle 128 ermöglicht Kommunikation mit System-Firmware und kann zum Beispiel eine Unified Extensible Firmware Interface (UEFI) sein. Der Netzwerkcontroller 134 kann eine Netzwerkverbindung mit einem Kabelnetzwerk ermöglichen. In einigen Ausführungsformen wird ein Hochleistungs-Netzwerkcontroller (nicht gezeigt) mit dem Schnittstellenbus 110 gekoppelt. Der Audiocontroller 146 ist in einer Ausführungsform ein Multi-Channel-High-Definition-Audiocontroller. In einer Ausführungsform enthält das System 100 einen optionalen Legacy-E/A-Controller 140, um Legacy-Vorrichtungen (z. B. Personal System 2 (PS/2)) mit dem System zu koppeln. Der Plattform-Controllerhub 130 kann auch mit einem oder mehreren Universal Serial Bus (USB)-Controllern 142 zum Anschließen von Eingabevorrichtungen, wie z. B. Kombinationen von Tastatur und Maus 143, einer Kamera 144 oder anderen USB-Eingabevorrichtungen, verbunden werden.
Es versteht sich, dass das gezeigte System 100 beispielhaft und nicht einschränkend ist, da andere Arten von Datenverarbeitungssystemen, die anders konfiguriert sind, ebenfalls verwendet werden können. Zum Beispiel kann eine Instanz des Speichercontrollers 116 und des Plattform-Controllerhubs 130 in einen diskreten externen Grafikprozessor, wie z. B. den externen Grafikprozessor 112, integriert sein. In einer Ausführungsform können der Plattform-Controllerhub 130 und/oder der Speichercontroller 1160 extern zu dem einen oder den mehreren Prozessor(en) 102 sein. Zum Beispiel kann das System 100 einen externen Speichercontroller 116 und einen Plattform-Controllerhub 130 enthalten, die innerhalb eines System-Chipsatzes, der mit dem (den) Prozessor(en) 102 in Kommunikation steht, als Speicher-Controllerhub und Peripheriegeräte-Controllerhub konfiguriert sein kann.
2 ist ein Blockdiagramm einer Ausführungsform eines Prozessors 200, der ein oder mehrere Prozessorkerne 202A-202N aufweist, eines integrierten Speichercontrollers 214 und eines integrierten Grafikprozessors 208. Jene Elemente von 2, welche die gleichen Bezugsnummern (oder Namen) wie die Elemente einer anderen hierin enthaltenen Figur haben, können in jeder Weise ähnlich den woanders hierin beschriebenen Elementen arbeiten oder funktionieren, sind aber nicht auf solche beschränkt. Der Prozessor 200 kann zusätzliche Kerne bis zu und einschließlich dem zusätzlichen Kern 202N, die durch die gestrichelten Kästen repräsentiert sind, enthalten. Jeder der Prozessorkerne 202A-202N enthält ein oder mehrere interne Cache-Einheiten 204A-204N. In einigen Ausführungsformen hat jeder Prozessorkern auch Zugriff auf ein oder mehrere gemeinsam genutzte Cache-Einheiten 206.
Die internen Cache-Einheiten 204A-204N und die gemeinsam genutzten Cache-Einheiten 206 repräsentieren eine Cache-Speicherhierarchie innerhalb des Prozessors 200. Die Cache-Speicherhierarchie kann mindestens eine Ebene von Befehls- und Datencache innerhalb jedes Prozessorkerns und ein oder mehrere Ebenen von gemeinsam genutztem Mid-Level-Cache, wie z. B. Level 2 (L2), Level 3 (L3), Level 4 (L4), oder andere Ebenen von Cache aufweisen, wobei die höchste Cache-Ebene vor dem externen Speicher als LLC klassifiziert ist. In einigen Ausführungsformen erhält eine Cache-Kohärenzlogik die Kohärenz zwischen den verschiedenen Cache-Einheiten 206 und 204A-204N aufrecht.
In einigen Ausführungsformen kann der Prozessor 200 auch einen Satz von ein oder mehreren Buscontrollereinheiten 216 und einen Systemdienstkern 210 enthalten. Die ein oder mehreren Buscontrollereinheiten 216 verwalten einen Satz von Peripheriebussen, wie z. B. ein oder mehrere PCI- oder PCI Express-Busse. Der Systemdienstkern 210 bietet eine Verwaltungsfunktion für die verschiedenen Prozessorkomponenten. In einigen Ausführungsformen enthält der Systemdienstkern 210 ein oder mehrere integrierte Speichercontroller 214, die den Zugriff auf verschiedene externe Speichervorrichtungen (nicht gezeigt) verwalten.
In einigen Ausführungsformen schließen die ein oder mehreren Prozessorkerne 202A-202N Unterstützung für gleichzeitiges Multi-Threading ein. In einer solchen Ausführungsform schließt der Systemdienstkern 210 Komponenten zum Koordinieren und Betreiben von Kernen 202A-202N während der Multi-Threading-Verarbeitung ein. Der Systemdienstkern 210 kann zusätzlich eine Leistungssteuereinheit (PCU) aufweisen, die Logik und Komponenten zum Regulieren des Leistungszustands der Prozessorkerne 202A-202N und des Grafikprozessors 208 enthält.
In einigen Ausführungsformen enthält der Prozessor 200 zusätzlich einen Grafikprozessor 208, um Grafikverarbeitungsoperationen auszuführen. In einigen Ausführungsformen ist der Grafikprozessor 208 mit dem Satz von gemeinsam genutzten Cache-Einheiten 206 und dem Systemdienstkern 210 gekoppelt, der die ein oder mehreren integrierten Speichercontroller 214 einschließt. In einigen Ausführungsformen enthält der Systemdienstkern 210 auch einen Anzeige-Controller 211, um die Grafikprozessorausgabe zu ein oder mehreren gekoppelten Displays anzutreiben. In einigen Ausführungsformen kann der Anzeige-Controller 211 auch ein getrenntes Modul sein, das über mindestens einen Interconnect mit dem Grafikprozessor gekoppelt ist, oder er kann in dem Grafikprozessor 208 integriert sein.
In einigen Ausführungsformen wird eine ringbasierte Interconnect-Einheit 212 verwendet, um die internen Komponenten des Prozessors 200 zu koppeln. Es kann jedoch auch eine alternative Interconnect-Einheit, wie z. B. ein Punkt-zu-Punkt-Interconnect, ein geschalteter Interconnect, oder andere Techniken, einschließlich im Stand der Technik wohlbekannte Techniken, verwendet werden. In einigen Ausführungsformen ist der Grafikprozessor 208 über eine E/A-Verbindung 213 mit dem Ring-Interconnect 212 gekoppelt.
Die beispielhafte E/A-Verbindung 213 repräsentiert mindestens eine von mehreren Varianten von E/A-Interconnects, einschließlich eines On-Package-E/A-Interconnects, der Kommunikation zwischen verschiedenen Prozessorkomponenten und einem integrierten Hochleistungs-Speichermodul 218, wie z. B. einem eDRAM-Modul, unterstützt. In einigen Ausführungsformen verwendet jeder der Prozessorkerne 202A-202N und der Grafikprozessor 208 integrierte Speichermodule 218 als einen gemeinsam genutzten Last Level Cache.
In einigen Ausführungsformen sind die Prozessorkerne 202A-202N homogene Kerne, welche die gleiche Befehlssatzarchitektur ausführen. In einer anderen Ausführungsform sind die Prozessorkerne 202A-202N heterogen in Bezug auf die Befehlssatzarchitektur (ISA), wobei ein oder mehrere Prozessorkerne 202A-202N einen ersten Befehlssatz ausführen, während mindestens einer der anderen Kerne einen Teilsatz des ersten Befehlssatzes oder einen unterschiedlichen Befehlssatz ausführt. In einer Ausführungsform sind die Prozessorkerne 202A-202N heterogen in Bezug auf die Mikroarchitektur, wobei ein oder mehrere Kerne, die einen relativ hohen Stromverbrauch haben, mit ein oder mehreren Energiekernen gekoppelt sind, die einen geringeren Stromverbrauch haben. Außerdem kann der Prozessor 200 auf ein oder mehreren Chips oder als integrierte SoC-Schaltung implementiert werden, welche die dargestellten Komponenten zusätzlich zu anderen Komponenten aufweist.
3 ist ein Blockdiagramm eines Grafikprozessors 300, der eine diskrete Grafikverarbeitungseinheit oder ein mit einer Vielzahl von Prozessorkernen integrierter Grafikprozessor sein kann. In einigen Ausführungsformen kommuniziert der Grafikprozessor über eine im Speicher abgebildete E/A-Schnittstelle mit Registern auf dem Grafikprozessor und mit Befehlen, die in den Prozessorspeicher platziert werden. In einigen Ausführungsformen enthält der Grafikprozessor 300 eine Speicherschnittstelle 314 für den Zugriff auf den Speicher. Die Speicherschnittstelle 314 kann eine Schnittstelle zu einem lokalen Speicher, ein oder mehreren internen Caches, ein oder mehreren gemeinsam genutzten externen Caches und/oder zum Systemspeicher sein.
In einigen Ausführungsformen enthält der Grafikprozessor 300 auch einen Anzeige-Controller 302, um die Anzeige-Ausgangsdaten zu einer Anzeigevorrichtung 320 anzusteuern. Der Anzeige-Controller 302 enthält Hardware für ein oder mehrere Overlay-Ebenen für das Display und die Komposition von mehreren Schichten von Video- oder Benutzerschnittstellenelementen. Die Anzeigevorrichtung 320 kann eine interne oder externe Anzeigevorrichtung sein. In einer Ausführungsform ist die Anzeigevorrichtung 320 eine am Kopf montierte Anzeigevorrichtung, wie z. B. eine Virtual Reality (VR)-Anzeigevorrichtung oder eine Augmented Reality (AR)-Anzeigevorrichtung. In einigen Ausführungsformen enthält der Grafikprozessor 300 eine Videocodec-Engine 306, um Medien zu, von oder zwischen ein oder mehreren Mediencodierungsformaten zu codieren, decodieren oder transcodieren, einschließlich, aber nicht beschränkt auf Moving Picture Experts Group (MPEG)-Formate, wie z. B. MPEG-2, Advanced Video Coding (AVC)-Formate, wie z. B. H.264/MPEG-4 AVC, sowie Formate der Society of Motion Picture & Television Engineers (SMPTE) 421M/VC-1 und der Joint Photographic Experts Group (JPEG), wie z. B. JPEG, und Motion JPEG (MJPEG)-Formate.
In einigen Ausführungsformen enthält der Grafikprozessor 300 eine Block Image Transfer (BLIT)-Engine 304, um zweidimensionale (2D) Rasterizer-Operationen, einschließlich z. B. Bit-Boundary Block-Transfers, durchzuführen. In einer Ausführungsform werden jedoch 2D-Grafikoperationen unter Verwendung von ein oder mehreren Komponenten der Grafikverarbeitungs-Engine (GPE) 310 durchgeführt. In einigen Ausführungsformen ist GPE 310 eine Compute-Engine zur Durchführung von Grafikoperationen, einschließlich dreidimensionaler (3D) Grafikoperationen und Medienoperationen.
In einigen Ausführungsformen enthält die GPE 310 eine 3D-Pipeline 312 zur Durchführung von 3D-Operationen, wie z. B. Rendering von dreidimensionalen Bildern und Szenen unter Verwendung von Verarbeitungsfunktionen, die auf 3D-Grundkörperformen (z. B. Rechteck, Dreieck usw.) reagieren. Die 3D-Pipeline 312 enthält programmierbare und Festfunktionselemente, die verschiedene Aufgaben innerhalb des Elements durchführen und/oder Ausführungsthreads zu einem 3D/Medien-Untersystem 315 hervorbringen. Während die 3D-Pipeline 312 zur Durchführung von Medienoperationen verwendet werden kann, enthält eine Ausführungsform der GPE 310 auch eine Medien-Pipeline 316, die speziell verwendet wird, um Medienoperationen, wie z. B. Video-Nachverarbeitung und Bildverbesserung, durchzuführen.
In einigen Ausführungsformen enthält die Medien-Pipeline 316 Festfunktions- oder programmierbare Logikeinheiten, um ein oder mehrere spezialisierte Medienoperationen, wie z. B. Videodecodierungsbeschleunigung, Video-De-Interlacing und Videocodierungsbeschleunigung, anstelle der oder zugunsten der Videocodec-Engine 306 durchzuführen. In einigen Ausführungsformen enthält die Medien-Pipeline 316 zusätzlich eine Thread-Hervorbringungseinheit, um Threads zur Ausführung auf dem 3D/Medien-Untersystem 315 hervorzubringen. Die hervorgebrachten Threads führen Berechnungen für die Medienoperationen auf ein oder mehreren Grafikausführungseinheiten durch, die in dem 3D/Medien-Untersystem 315 enthalten sind.
In einigen Ausführungsformen enthält das 3D/Medien-Untersystem 315 Logik zum Ausführen von Threads, die durch die 3D-Pipeline 312 und die Medien-Pipeline 316 hervorgebracht wurden. In einer Ausführungsform senden die Pipelines Thread-Ausführungsanforderungen an das 3D/Medien-Untersystem 315, das Thread-Versendungslogik zum Arbitrieren und Entsenden der verschiedenen Anforderungen an verfügbare Thread-Ausführungsressourcen enthält. Die Ausführungsressourcen schließen ein Array von Grafikausführungseinheiten zum Verarbeiten der 3D- und Medienthreads ein. In einigen Ausführungsformen enthält das 3D/Medien-Untersystem 315 ein oder mehrere interne Caches für Threadbefehle und Daten. In einigen Ausführungsformen enthält das Untersystem auch gemeinsam genutzten Speicher, einschließlich Registern und adressierbarem Speicher, um Daten zwischen Threads zu teilen und Ausgabedaten zu speichern.
Grafikverarbeitungs-Engine
4 ist ein Blockdiagramm einer Grafikverarbeitungs-Engine 410 eines Grafikprozessors im Einklang mit einigen Ausführungsformen. In einer Ausführungsform ist die Grafikverarbeitungs-Engine (GPE) 410 eine Version der in 3 gezeigten GPE 310. Elemente von 4, welche die gleichen Bezugsnummern (oder Namen) wie die Elemente einer anderen hierin enthaltenen Figur haben, können in jeder Weise ähnlich den woanders hierin beschriebenen Elementen arbeiten oder funktionieren, sind aber nicht auf solche beschränkt. Zum Beispiel werden die 3D-Pipeline 312 und die Medien-Pipeline 316 von 3 dargestellt. Die Medien-Pipeline 316 ist in einigen Ausführungsformen der GPE 410 optional und ist möglicherweise nicht unbedingt in der GPE 410 enthalten. Zum Beispiel, und in mindestens einer Ausführungsform, ist ein getrenntes Medium und/oder ein Bildprozessor mit der GPE 410 gekoppelt.
In einigen Ausführungsformen koppelt die GPE 410 mit oder enthält einen Befehlsstreamer 403, der einen Befehlsstrom zu der 3D-Pipeline 312 und/oder den Medien-Pipelines 316 bereitstellt. In einigen Ausführungsformen ist der Befehlsstreamer 403 mit dem Speicher gekoppelt, der Systemspeicher oder einen oder mehrere des internen Cache-Speichers und gemeinsam genutzten Cache-Speichers sein kann. In einigen Ausführungsformen empfängt der Befehlsstreamer 403 Befehle von dem Speicher und sendet die Befehle an die 3D-Pipeline 312 und/oder die Medien-Pipeline 316. Die Befehle sind von einem Ringpuffer abgerufene Richtlinien, der Befehle für die 3D-Pipeline 312 und die Medien-Pipeline 316 speichert. In einer Ausführungsform kann der Ringpuffer zusätzlich Stapelbefehlspuffer enthalten, die Stapel von mehreren Befehlen speichern. Die Befehle für die 3D-Pipeline 312 können auch Referenzen zu im Speicher abgelegten Daten enthalten, wie z. B., aber nicht beschränkt auf, Scheitelpunkt- und Geometriedaten für die 3D-Pipeline 312 und/oder Bilddaten und Speicherobjekte für die Medien-Pipeline 316. Die 3D-Pipeline 312 und Medien-Pipeline 316 verarbeiten die Befehle und Daten, indem sie Operationen über Logik innerhalb der jeweiligen Pipelines durchführen oder ein oder mehrere Ausführungsthreads zu einem Grafikkernarray 414 entsenden. In einer Ausführungsform enthält das Grafikkernarray 414 ein oder mehrere Blöcke von Grafikkernen (z. B. Grafikkern(e) 415A, Grafikkern(e) 415B), wobei jeder Block ein oder mehrere Grafikkerne enthält. Jeder Grafikkern enthält einen Satz von Grafikausführungsressourcen, der Allzweck- und grafikspezifische Ausführungslogik enthält, um Grafik- und Rechenoperationen durchzuführen, sowie Festfunktions-Texturverarbeitung und/oder Maschinenlern- und Beschleunigungslogik von künstlicher Intelligenz.
In verschiedenen Ausführungsformen enthält die 3D-Pipeline 312 Festfunktions- und programmierbare Logik, um ein oder mehrere Shaderprogramme, wie z. B. Vertex-Shader, Geometrie-Shader, Pixel-Shader, Fragment-Shader, Compute-Shader oder andere Shaderprogramme zu verarbeiten, und zwar durch Verarbeiten der Befehle und Entsenden von Ausführungsthreads zu dem Grafikkernarray 414. Das Grafikkernarray 414 liefert einen vereinheitlichten Block von Ausführungsressourcen zum Gebrauch bei der Verarbeitung dieser Shaderprogramme. Mehrzweck-Ausführungslogik (z. B. Ausführungseinheiten) innerhalb des (der) Grafikkern(e) 415A-414B des Grafikkernarrays 414 schließt Unterstützung für verschiedene 3D API-Shadersprachen ein und kann mit mehreren Shadern verbundene mehrfache gleichzeitige Ausführungsthreads ausführen.
In einigen Ausführungsformen enthält das Grafikkernarray 414 auch Ausführungslogik, um Medienfunktionen, wie z. B. Video- und/oder Bildverarbeitung durchzuführen. In einer Ausführungsform enthalten die Ausführungseinheiten zusätzlich Allzwecklogik, die programmierbar ist, um parallele Allzweck-Rechenoperationen zusätzlich zu Grafikverarbeitungsoperationen durchzuführen. Die Allzwecklogik kann Verarbeitungsoperationen parallel oder in Verbindung mit Allzwecklogik innerhalb des (der) Prozessorkern(e) 107 von 1 oder der Kerne 202A-202N wie in 2 durchführen.
Ausgabedaten, die von auf dem Grafikkernarray 414 ausgeführte Threads erzeugt werden, können Daten an den Speicher in einem Unified Return Buffer (URB) 418 ausgeben. Der URB 418 kann Daten für mehrere Threads speichern. In einigen Ausführungsformen kann der URB 418 auch verwendet werden, um Daten zwischen unterschiedlichen Threads zu senden, die auf dem Grafikkernarray 414 ausgeführt werden. In einigen Ausführungsformen kann der URB 418 zusätzlich für Synchronisierung zwischen Threads auf dem Grafikkernarray und Festfunktionslogik innerhalb der gemeinsamen Funktionslogik 420 verwendet werden.
In einigen Ausführungsformen ist das Grafikkernarray 414 skalierbar, so dass das Array eine veränderliche Anzahl von Grafikkernen aufweist, die jeweils eine veränderliche Anzahl von Ausführungseinheiten auf der Basis der Soll-Leistung und des Leistungsniveaus der GPE 410 aufweisen. In einer Ausführungsform sind die Ausführungsressourcen dynamisch skalierbar, so dass Ausführungsressourcen nach Bedarf aktiviert oder deaktiviert werden können.
Das Grafikkernarray 414 koppelt mit der gemeinsamen Funktionslogik 420, die mehrere Ressourcen umfasst, die zwischen den Grafikkernen in dem Grafikkernarray geteilt werden. Die gemeinsamen Funktionen innerhalb der gemeinsamen Funktionslogik 420 sind Hardware-Logikeinheiten, die spezialisierte ergänzende Funktionalität für das Grafikkernarray 414 bereitstellen. In verschiedenen Ausführungsformen schließt die gemeinsame Funktionslogik 420 Logik für Sampler 421, Math 422 und Inter-Thread-Kommunikation (ITC) 423 ein, ist aber nicht darauf beschränkt. Außerdem implementieren einige Ausführungsformen einen oder mehrere Cache(s) 425 innerhalb der gemeinsamen Funktionslogik 420.
Eine gemeinsame Funktion wird implementiert, wenn der Bedarf an einer gegebenen spezialisierten Funktion unzureichend für Einbeziehung in das Grafikkernarray 414 ist. Statt dessen wird eine einzige Instanziierung dieser spezialisierten Funktion als unabhängige Einheit in der gemeinsamen Funktionslogik 420 implementiert und unter den Ausführungsressourcen innerhalb des Grafikkernarrays 414 geteilt. Der genaue Satz von Funktionen, die zwischen dem Grafikkernarray 414 geteilt werden und in dem Grafikkernarray 414 enthalten sind, ist je nach Ausführungsform unterschiedlich. In einigen Ausführungsformen können spezifische gemeinsame Funktionen innerhalb der gemeinsamen Funktionslogik 420, die von dem Grafikkernarray 414 häufig verwendet werden, in der gemeinsamen Funktionslogik 416 innerhalb des Grafikkernarrays 414 enthalten sein. In verschiedenen Ausführungsformen kann die gemeinsame Funktionslogik 416 innerhalb des Grafikkernarrays 414 einige oder alle Logik innerhalb der gemeinsamen Funktionslogik 420 enthalten. In einer Ausführungsform können alle Logikelemente innerhalb der gemeinsamen Funktionslogik 420 innerhalb der gemeinsamen Funktionslogik 416 des Grafikkernarrays 414 dupliziert werden. In einer Ausführungsform wird die gemeinsame Funktionslogik 420 zugunsten der gemeinsamen Funktionslogik 416 innerhalb des Grafikkernarrays 414 ausgeschlossen.
5 ist ein Blockdiagramm einer Hardwarelogik eines Grafikprozessorkerns 500 gemäß einigen hierin beschriebenen Ausführungsformen. Elemente von 5, welche die gleichen Bezugsnummern (oder Namen) wie die Elemente einer anderen hierin enthaltenen Figur haben, können in jeder Weise ähnlich den woanders hierin beschriebenen Elementen arbeiten oder funktionieren, sind aber nicht auf solche beschränkt. Der dargestellte Grafikprozessorkern 500 ist in einigen Ausführungsformen innerhalb des Grafikkernarrays 414 von 4 enthalten. Der Grafikprozessorkern 500, der manchmal auch als Kernscheibe bezeichnet wird, kann ein oder mehrere Grafikkerne innerhalb eines modularen Grafikprozessors sein. Der Grafikprozessorkern 500 ist beispielhaft für eine Grafikkernscheibe, und ein Grafikprozessor, wie hierin beschrieben, kann mehrere Grafikkernscheiben auf der Basis von Soll-Leistung und Leistungshüllen enthalten. Jeder Grafikprozessorkern 500 kann einen Festfunktionsblock 530 enthalten, der mit mehreren Teilkernen 501A-501F, auch als Teilscheiben bezeichnet, gekoppelt ist, die modulare Blöcke von Allzweck- und Festfunktionslogik enthalten.
In einigen Ausführungsformen schließt der Festfunktionsblock 530 eine Geometrie/Festfunktions-Pipeline 536 ein, die von allen Teilkernen in dem Grafikprozessorkern 500 gemeinsam genutzt werden können, zum Beispiel in Implementierungen von geringerer Leistung und/oder niedrigerer Grafikprozessorleistung. In verschiedenen Ausführungsformen schließt die Geometrie/Festfunktions-Pipeline 536 eine 3D-Festfunktions-Pipeline (z. B. 3D-Pipeline 312, wie in 3 und 4), eine Video-Front-End-Einheit, einen Thread-Spawner und Thread-Dispatcher sowie einen vereinheitlichten Rückgabepuffermanager ein, der vereinheitlichte Rückgabepuffer verwaltet, wie z. B. den vereinheitlichten Rückgabepuffer 418 von 4.
In einer Ausführungsform schließt der Festfunktionsblock 530 auch eine Grafik-SoC-Schnittstelle 537, einen Grafik-Mikrocontroller 538 und eine Medien-Pipeline 539 ein. Die Grafik-SoC-Schnittstelle 537 stellt eine Schnittstelle zwischen dem Grafikprozessorkern 500 und anderen Prozessorkernen innerhalb einer integrierten Ein-Chip-System-Schaltung bereit. Der Grafik-Mikrocontroller 538 ist ein programmierbarer Subprozessor, der konfigurierbar ist, um verschiedene Funktionen des Grafikprozessorkerns 500, einschließlich Thread-Dispatch, Planung und Vorwegnahme, zu verwalten.
Die Medien-Pipeline 539 (z. B. Medien-Pipeline 316 von 3 und 4) weist Logik auf, um Decodierung, Codierung, Vorverarbeitung und/oder Nachverarbeitung von Multimediadaten, einschließlich Bild- und Videodaten, zu unterstützen. Die Medien-Pipeline 539 implementiert Medienoperationen über Anforderungen an die Rechen- oder Sampling-Logik innerhalb der Teilkerne 501-501F.
In einer Ausführungsform ermöglicht die SoC-Schnittstelle 537 dem Grafikprozessorkern 500, mit den Allzweck-Anwendungsprozessorkernen (z. B. CPUs) und/oder anderen Komponenten innerhalb eines SoC, einschließlich Speicherhierarchieelementen, wie z. B. einem gemeinsamen Last-Level-Cache-Speicher, dem System-RAM und/oder integriertem On-Chip- oder On-Package-DRAM, zu kommunizieren. Die SoC-Schnittstelle 537 kann auch Kommunikation mit Festfunktionsvorrichtungen innerhalb des SoC, wie z. B. Kamerabild-Pipelines, ermöglichen, und ermöglicht den Einsatz von und/oder implementiert Global Memory Atomics, die zwischen dem Grafikprozessorkern 500 und CPUs innerhalb des SoC geteilt werden können. Die SoC-Schnittstelle 537 kann auch Energieverwaltungskontrollen für den Grafikprozessorkern 500 implementieren und eine Schnittstelle zwischen einer Taktdomäne des Grafikkerns 500 und anderen Taktdomänen innerhalb des SoC ermöglichen. In einer Ausführungsform ermöglicht die SoC-Schnittstelle 537 den Empfang von Befehlspuffern von einem Befehlsstreamer und einem globalen Thread-Dispatcher, die dazu ausgebildet sind, Befehle und Anweisungen zu jedem der ein oder mehreren Grafikkerne innerhalb eines Grafikprozessors zu liefern. Die Befehle und Anweisungen können zu der Medien-Pipeline 539 entsendet werden, wenn Medienoperationen durchzuführen sind, oder zu einer Geometrie- und Festfunktions-Pipeline (z. B. der Geometrie- und Festfunktions-Pipeline 536, der Geometrie- und Festfunktions-Pipeline 514), wenn Grafikverarbeitungsoperationen durchzuführen sind.
Der Grafik-Mikrocontroller 538 kann dazu ausgebildet sein, verschiedene Planungs- und Verwaltungsaufgaben für den Grafikprozessorkern 500 durchzuführen. In einer Ausführungsform kann der Grafik-Mikrocontroller 538 Grafik- und/oder Rechenarbeitslastplanung an den verschiedenen parallelen Grafik-Engines innerhalb der Ausführungseinheit (AE)-Arrays 502A-502F, 504A-504F innerhalb der Teilkerne 501A-501F durchführen. In diesem Planungsmodell kann Hostsoftware, die auf einem CPU-Kern eines den Grafikprozessorkern 500 aufweisenden SoC ausgeführt wird, Arbeitslasten von einer von mehreren Grafikprozessor-Türklingeln übermitteln, wodurch eine Planungsoperation an der entsprechenden Grafik-Engine aufgerufen wird. Planungsoperationen umfassen das Bestimmen, welche Arbeitslast als Nächstes auszuführen ist, Übermitteln einer Arbeitslast zu einem Befehlsstreamer, Vorwegnehmen existierender Arbeitslasten, die auf einer Engine ausgeführt werden, Überwachen des Fortschritts einer Arbeitslast, und Benachrichtigen der Hostsoftware, wenn eine Arbeitslast abgeschlossen ist. In einer Ausführungsform kann der Grafik-Mikrocontroller 538 auch Energiespar- oder Ruhezustände für den Grafikprozessorkern 500 unterstützen, indem er dem Grafikprozessorkern 500 die Fähigkeit verleiht, Register innerhalb des Grafikprozessorkerns 500 über Energiesparzustandsübergänge unabhängig von dem Betriebssystem und/oder der Grafiktreibersoftware auf dem System zu speichern und wiederherzustellen.
Der Grafikprozessorkern 500 kann mehr oder weniger als die dargestellten Teilkerne 501A-501F, bis zu N modularen Teilkernen, aufweisen. Für jeden Satz von N Teilkernen kann der Grafikprozessorkern 500 auch eine gemeinsame Funktionslogik 510, einen gemeinsam genutzten und/oder Cache-Speicher 512, eine Geometrie/Festfunktions-Pipeline 514 sowie zusätzliche Festfunktionslogik 516 aufweisen, um verschiedene Grafik- und Datenverarbeitungsoperationen zu beschleunigen. Die gemeinsame Funktionslogik 510 kann mit der gemeinsamen Funktionslogik 420 von 4 verbundene Logikeinheiten (z. B. Sampler-, Math- und/oder Inter-Thread-Kommunikationslogik) enthalten, die von allen N Teilkernen innerhalb des Grafikprozessorkerns 500 gemeinsam genutzt werden können. Der gemeinsam genutzte und/oder Cache-Speicher 512 kann ein Last-Level-Cache für den Satz von N Teilkernen 501A-501F innerhalb des Grafikprozessorkerns 500 sein, und kann auch als gemeinsam genutzter Speicher dienen, der von mehreren Teilkernen zugänglich ist. Die Geometrie/Festfunktions-Pipeline 514 kann anstelle der Geometrie/Festfunktions-Pipeline 536 innerhalb des Festfunktionsblocks 530 enthalten sein, und kann die gleichen oder ähnliche Logikeinheiten aufweisen.
In einer Ausführungsform enthält der Grafikprozessorkern 500 zusätzliche Festfunktionslogik 516, die verschiedene Festfunktions-Beschleunigungslogiken zur Verwendung durch den Grafikprozessorkern 500 aufweisen kann. In einer Ausführungsform weist die zusätzliche Festfunktionslogik 516 eine zusätzliche Geometrie-Pipeline für Position-only-Shading auf. In Position-only-Shading existieren zwei Geometrie-Pipelines, die volle Geometrie-Pipeline innerhalb der Geometrie/Festfunktions-Pipeline 516, 536, und eine Cull-Pipeline, die eine zusätzliche Geometrie-Pipeline ist, die in der zusätzlichen Festfunktionslogik 516 eingeschlossen sein kann. In einer Ausführungsform ist die Cull-Pipeline eine abgespeckte Version der vollen Geometrie-Pipeline. Die volle Pipeline und die Cull-Pipeline können unterschiedliche Instanzen derselben Anwendung ausführen, wobei jede Instanz einen getrennten Kontext hat. Position-only-Shading kann lange Cull-Läufe von verworfenen Dreiecken verbergen, wodurch es in manchen Fällen möglich ist, Shading früher zu vollenden. Zum Beispiel und in einer Ausführungsform kann die Cull-Pipeline-Logik innerhalb der zusätzlichen Festfunktionslogik 516 Position-Shader parallel zu der Hauptanwendung ausführen und erzeugt im Allgemeinen kritische Resultate schneller als die volle Pipeline, da die volle Pipeline nur das Positionsattribut der Vertices abruft und schattiert, ohne Rasterisierung und Rendering der Pixel am Bildspeicher durchzuführen. Die Cull-Pipeline kann die erzeugten kritischen Resultate verwenden, um Sichtbarkeitsinformationen für alle Dreiecke zu berechnen, ohne Rücksicht darauf, ob diese Dreiecke ausgesondert werden. Die volle Pipeline (die in diesem Fall als Replay-Pipeline bezeichnet werden kann) kann die Sichtbarkeitsinformationen konsumieren, um die ausgesonderten Dreiecke zu überspringen und nur die sichtbaren Dreiecke zu schattieren, die letztendlich zu der Rasterisierungsphase geleitet werden.
In einer Ausführungsform kann die zusätzliche Festfunktionslogik 516 auch Maschinenlern-Beschleunigungslogik, wie z. B. Festfunktions-Matrixmultiplikationslogik, für Implementierungen einschließlich Optimierungen für Maschinenlerntraining oder Ableiten aufweisen.
In jedem Grafik-Teilkern 501A-501F ist ein Satz von Ausführungsressourcen enthalten, der verwendet werden kann, um Grafik-, Medien- und Rechenoperationen als Reaktion auf Anforderungen von der Grafik-Pipeline, der Medien-Pipeline oder von Shaderprogrammen durchzuführen. Die Grafik-Teilkerne 501A-501F schließen mehrere AE-Arrays 502A-502F, 504A-504F, Thread-Dispatch- und Inter-Thread-Kommunikationslogik (TD/IC) 503A-503F, einen 3D-Sampler (z. B. Textur) 505A-505F, einen Mediensampler 506A-506F, einen Shaderprozessor 507A-507F und Shared Local Memory (SLM) 508A-508F ein. Die AE-Arrays 502A-502F, 504A-504F enthalten jeweils mehrere Ausführungseinheiten, bei denen es sich um Allzweck-Grafikverarbeitungseinheiten handelt, die in der Lage sind, Gleitkomma- und Ganzzahl/Festpunkt-Logikoperationen im Dienste einer Grafik-, Medien- oder Rechenoperation, einschließlich Grafik-, Medien- oder Compute-Shaderprogrammen, durchzuführen. Die TD/IC-Logik 503A-503F führt lokale Thread-Dispatch- und Thread-Control-Operationen für die Ausführungseinheiten innerhalb eines Teilkerns durch und unterstützt Kommunikation zwischen Threads, die auf den Ausführungseinheiten des Teilkerns ausgeführt werden. Der 3D-Sampler 505A-505F kann auf Textur oder andere 3D-Grafik bezogene Daten in den Speicher einlesen. Der 3D-Sampler kann Texturdaten auf der Basis eines konfigurierten Abtastzustands und des mit einer gegebenen Textur verbundenen Texturformats unterschiedlich lesen. Der Mediensampler 506A-506F kann ähnliche Lesevorgänge auf der Basis des mit den Mediendaten verbundenen Typs und Formats durchführen. In einer Ausführungsform kann jeder Grafik-Teilkern 501A-501F abwechselnd einen vereinheitlichten 3D-Sampler und einen Mediensampler enthalten. Threads, die auf den Ausführungseinheiten innerhalb jedes der Teilkerne 501A-501F ausgeführt werden, können den gemeinsamen lokalen Speicher 508A-508F innerhalb jedes Teilkerns nutzen, um zu ermöglichen, dass Threads, die innerhalb einer Threadgruppe ausgeführt werden, unter Verwendung eines gemeinsamen Pools von On-Chip-Speicher ausgeführt werden.
Ausführungseinheiten
6A-6B stellen eine Thread-Ausführungslogik 600 dar, die ein Array von Verarbeitungselementen einschließt, die gemäß hierin beschriebenen Ausführungsformen in einem Grafikprozessorkern eingesetzt werden. Elemente der 6A-6B, welche die gleichen Bezugsnummern (oder Namen) wie die Elemente einer anderen hierin enthaltenen Figur haben, können in jeder Weise ähnlich den woanders hierin beschriebenen Elementen arbeiten oder funktionieren, sind aber nicht auf solche beschränkt. 6A stellt eine Übersicht der Thread-Ausführungslogik 600 dar, die eine Variante der Hardwarelogik enthalten kann, die mit jedem Teilkern 501A-501F von 5 dargestellt ist. 6B stellt beispielhafte interne Details einer Ausführungseinheit dar.
Wie in 6A dargestellt, enthält die Thread-Ausführungslogik 600 in einigen Ausführungsformen einen Shaderprozessor 602, einen Thread-Dispatcher 604, Befehlscache 606 und ein skalierbares Ausführungseinheitsarray, das eine Vielzahl von Ausführungseinheiten 608A-608N, einen Sampler 610, einen Datencache 612 und einen Datenport 614 enthält. In einer Ausführungsform kann das skalierbare Ausführungseinheitsarray dynamisch skalieren, indem es ein oder mehrere Ausführungseinheiten (z. B. eine der Ausführungseinheiten 608A, 608B, 608C, 608D bis 608N-1 und 608N) auf der Basis der Rechenanforderungen einer Arbeitslast aktiviert oder deaktiviert. In einer Ausführungsform sind die enthaltenen Komponenten über ein Interconnect-Netzwerk verbunden, das alle Komponenten miteinander verbindet. In einigen Ausführungsformen weist die Thread-Ausführungslogik 600 ein oder mehrere Verbindungen mit dem Speicher auf, wie z. B. einem Systemspeicher oder Cache-Speicher, durch ein oder mehrere von Befehlscache 606, Datenport 614, Sampler 610 und Ausführungseinheiten 608A-608N. In einigen Ausführungsformen ist jede Ausführungseinheit (z. B. 608A) eine unabhängige programmierbare Allzweck-Recheneinheit, die in der Lage ist, mehrere simultane Hardware-Threads auszuführen, während sie parallel mehrere Datenelemente für jeden Thread verarbeitet. In verschiedenen Ausführungsformen ist das Array von Ausführungseinheiten 608A-608N skalierbar, um eine beliebige Anzahl von individuellen Ausführungseinheiten einzuschließen.
In einigen Ausführungsformen werden die Ausführungseinheiten 608A-608N hauptsächlich verwendet, um Shaderprogramme auszuführen. Ein Shaderprozessor 602 kann die verschiedenen Shaderprogramme verarbeiten und mit den Shaderprogrammen verbundenen Ausführungsthreads über einen Thread-Dispatcher 604 versenden. In einer Ausführungsform enthält der Thread-Dispatcher Logik, um Thread-Initiierungsanforderungen von den Grafik- und Medien-Pipelines zu vermitteln und die angeforderten Threads auf ein oder mehreren Ausführungseinheiten der Ausführungseinheiten 608A-608N zu instanziieren. Zum Beispiel kann eine Geometrie-Pipeline Vertex-, Tessellations- oder Geometrie-Shader zur Verarbeitung an die Thread-Ausführungslogik entsenden. In einigen Ausführungsformen kann der Thread-Dispatcher 604 auch Runtime-Thread-Hervorbringungsanforderungen von den laufenden Shaderprogrammen verarbeiten.
In einigen Ausführungsformen unterstützen die Ausführungseinheiten 608A-608N einen Befehlssatz, der native Unterstützung für viele standardmäßige 3D-Grafik-Shaderbefehle einschließt, so dass Shaderprogramme von Grafikbibliotheken (z. B. Direct 3D und OpenGL) mit minimaler Übersetzung ausgeführt werden. Die Ausführungseinheiten unterstützen Vertex- und Geometrieverarbeitung (z. B. Vertex-Programme, Geometrieprogramme, Vertex-Shader), Pixelverarbeitung (z. B. Pixel-Shader, Fragment-Shader) und Allzweckverarbeitung (z. B. Rechen- und Medien-Shader). Jede der Ausführungseinheiten 608A-608N ist zur Ausführung von mehrteiligen Single Instruction Multiple Data (SIMD) fähig, und Multithread-Betrieb ermöglicht eine effiziente Ausführungsumgebung angesichts Speicherzugriffen von höherer Latenz. Jeder Hardware-Thread innerhalb jeder Ausführungseinheit hat eine dedizierte Registerdatei von hoher Bandbreite und einen zugehörigen unabhängigen Thread-Zustand. Die Ausführung erfolgt mehrteilig per Taktgeber an Pipelines, die zu Ganzzahl-, Gleitkommaoperationen von einfacher und doppelter Präzision, SIMD-Verzweigungsfähigkeit, logischen Operationen, transzendentalen Operationen und anderen verschiedenen Operationen fähig sind. Während auf Daten vom Speicher oder eine der gemeinsamen Funktionen gewartet wird, veranlasst Abhängigkeitslogik innerhalb der Ausführungseinheiten 608A-608N einen wartenden Thread zu schlafen, bis die angeforderten Daten zurückgegeben worden sind. Während der wartende Thread schläft, können Hardware-Ressourcen zum Verarbeiten anderer Threads eingesetzt werden. Zum Beispiel kann eine Ausführungseinheit während einer durch eine Vertex-Shaderoperation bedingte Verzögerung Operationen für einen Pixel-Shader, Fragment-Shader oder eine andere Art von Shaderprogramm, das einen anderen Vertex-Shader enthält, durchführen.
Jede Ausführungseinheit in den Ausführungseinheiten 608A-608N arbeitet an Arrays von Datenelementen. Die Anzahl der Datenelemente ist die „Ausführungsgröße“ bzw. die Anzahl von Kanälen für den Befehl. Ein Ausführungskanal ist eine logische Einheit der Ausführung für Datenelementzugriff, Maskierung und Ablaufsteuerung innerhalb von Befehlen. Die Anzahl von Kanälen kann unabhängig von der Anzahl von physischen Arithmetic Logic Units (ALUs) oder Floating Point Units (FPUs) für einen bestimmten Grafikprozessor sein. In einigen Ausführungsformen unterstützen Ausführungseinheiten 608A-608N Ganzzahl- und Gleitkomma -Datentypen.
Der Ausführungseinheits-Befehlssatz enthält SIMD-Befehle. Die verschiedenen Datenelemente können als gepackter Datentyp in einem Register gespeichert werden, und die Ausführungseinheit verarbeitet die verschiedenen Elemente auf der Basis der Datengröße der Elemente. Zum Beispiel, wenn an einem 256 Bit breiten Vektor gearbeitet wird, werden die 256 Bits des Vektors in einem Register gespeichert, und die Ausführungseinheit arbeitet an dem Vektor als vier getrennte 64-Bit-gepackte Datenelemente (Datenelemente von Quad-Word (QW)-Größe), acht getrennte 32-Bit-gepackte Datenelemente (Datenelemente von Double Word (DW)-Größe), sechzehn getrennte 16-Bit-gepackte Datenelemente (Datenelemente von Word (W)-Größe) oder zweiunddreißig getrennte 8-Bit-Datenelemente (Datenelemente von Byte (B)-Größe). Es sind jedoch unterschiedliche Vektorbreiten und Registergrößen möglich.
In einer Ausführungsform können ein oder mehrere Ausführungseinheiten zu einer verschmolzenen Ausführungseinheit 609A-609N kombiniert werden, die eine Thread-Steuerlogik (607A-607N) aufweist, die den verschmolzenen AEs gemeinsam ist. Mehrere AEs können zu einer AE-Gruppe verschmolzen werden. Jede AE in der verschmolzenen AE-Gruppe kann dazu ausgebildet sein, einen getrennten SIMD-Hardware-Thread auszuführen. Die Anzahl von AEs in einer verschmolzenen AE-Gruppe kann gemäß den Ausführungsformen variieren. Außerdem können verschiedene SIMD-Breiten pro AE durchgeführt werden, einschließlich, aber nicht beschränkt auf, SIMD8, SIMD16 und SIMD32. Jede verschmolzene Grafikausführungseinheit 609A-609N enthält mindestens zwei Ausführungseinheiten. Zum Beispiel enthält die verschmolzene Ausführungseinheit 609A eine erste AE 608A, eine zweite AE 608B und eine Thread-Steuerlogik 607A, die der ersten AE 608A und der zweiten AE 608B gemeinsam ist. Die Thread-Steuerlogik 607A steuert die auf der verschmolzenen Grafikausführungseinheit 609A ausgeführten Threads, so dass jede AE in den verschmolzenen Ausführungseinheiten 609A-609N in der Lage ist, unter Verwendung eines gemeinsamen Befehlszeigerregisters auszuführen.
Ein oder mehrere interne Befehlscaches (z. B. 606) sind in der Thread-Ausführungslogik 600 enthalten, um Threadbefehle für die Ausführungseinheiten zu cachen. In einigen Ausführungsformen sind ein oder mehrere Datencaches (z. B. 612) enthalten, um Threaddaten während der Threadausführung zu cachen. In einigen Ausführungsformen ist ein Sampler 610 enthalten, um Textursampling für 3D-Operationen und Mediensampling für Medienoperationen bereitzustellen. In einigen Ausführungsformen enthält der Sampler 610 spezialisierte Textur- oder Mediensamplingfunktionen, um Textur- oder Mediendaten während des Samplingprozesses zu verarbeiten, bevor die gesampelten Daten einer Ausführungseinheit bereitgestellt werden.
Während der Ausführung senden die Grafik- und Medien-Pipelines Thread-Initiierungsanforderungen an die Thread-Ausführungslogik 600 über Thread-Hervorbringungs- und Versendungslogik. Nachdem eine Gruppe von geometrischen Objekten zu Pixeldaten verarbeitet und rasterisiert worden ist, wird die Pixelprozessorlogik (z. B. Pixel-Shaderlogik, Fragment-Shaderlogik usw.) innerhalb des Shaderprozessors 602 aufgerufen, um Ausgabeinformationen weiter zu berechnen und zu veranlassen, dass Resultate auf Ausgabeflächen (z. B. Farbpuffer, Tiefenpuffer, Stencilpuffer usw.) geschrieben werden. In einigen Ausführungsformen berechnet ein Pixel-Shader oder Fragment-Shader die Werte der verschiedenen Vertexattribute, die zu interpolieren sind, über das rasterisierte Objekt. In einigen Ausführungsformen führt die Pixelprozessorlogik innerhalb des Shaderprozessors 602 dann ein von einer Anwendungsprogrammierschnittstelle (API) geliefertes Pixel- oder Fragment-Shaderprogramm aus. Um das Shaderprogramm auszuführen, versendet der Shaderprozessor 602 Threads über den Thread-Dispatcher 604 zu einer Ausführungseinheit (z. B. 608A). In einigen Ausführungsformen verwendet der Shaderprozessor 602 Texturabtastlogik in dem Sampler 610, um auf Texturdaten zuzugreifen, die in gespeicherten Texturabbildungen vorliegen. In Rechenoperationen an den Texturdaten und den eingegebenen Geometriedaten werden Pixelfarbdaten für jedes geometrische Fragment berechnet, oder es werden ein oder mehrere Pixel von weiterer Verarbeitung ausgeschlossen.
In einigen Ausführungsformen stellt der Datenport 614 einen Speicherzugriffsmechanismus für die Thread-Ausführungslogik 600 bereit, um verarbeitete Daten für weitere Verarbeitung auf einer Grafikprozessor-Ausgabe-Pipeline auszugeben. In einigen Ausführungsformen enthält der Datenport 614 ein oder mehrere Cache-Speicher (z. B. Datencache 612), oder wird damit gekoppelt, um Daten für Speicherzugriff über den Datenport zu cachen.
Wie in 6B dargestellt, kann eine Grafikausführungseinheit 608 eine Befehlsabrufeinheit 637, ein allgemeines Registerdateiarray (GRF) 624, ein architektonisches Registerdateiarray (ARF) 626, einen Thread-Vermittler 622, eine Sendeeinheit 630, eine Verzweigungseinheit 632, einen Satz von SIMD-Gleitkommaeinheiten (FPUs) 634 und in einer Ausführungsform einen Satz von dedizierten Ganzzahl-SIMD ALUs 635 umfassen. Das GRF 624 und das ARF 626 enthalten den Satz von allgemeinen Registerdateien und architektonischen Registerdateien, die mit jedem simultanen Hardware-Thread verbunden sind, der in der Grafikausführungseinheit 608 aktiv sein kann. In einer Ausführungsform wird pro Thread der architektonische Zustand in dem ARF 626 aufrechterhalten, während Daten, die während der Threadausführung verwendet werden, in dem GRF 624 gespeichert werden. Der Ausführungszustand jedes Threads, einschließlich der Befehlszeiger für jeden Thread, kann in Thread-spezifischen Registern in dem ARF 626 gehalten werden.
In einer Ausführungsform weist die Grafikausführungseinheit 608 eine Architektur auf, die eine Kombination von Simultaneous Multi-Threading (SMT) und feinkörnigem Interleaved Multi-Threading (IMT) ist. Die Architektur weist eine modulare Konfiguration auf, die zur Designzeit auf der Basis einer Sollzahl von simultanen Threads und der Anzahl von Registern pro Ausführungseinheit fein abgestimmt werden kann, wobei Ausführungseinheitsressourcen über die Logik aufgeteilt werden, die verwendet wird, um mehrere simultane Threads auszuführen.
In einer Ausführungsform kann die Grafikausführungseinheit 608 mehrere Befehle zusammen ausgeben, die jeweils unterschiedliche Befehle sein können. Der Thread-Vermittler 622 des Threads der Grafikausführungseinheit 608 kann die Befehle zur Ausführung an eine Einheit der Sendeeinheit 630, der Verzweigungseinheit 6342 oder der SIMD FPU(s) 634 entsenden. Jeder Ausführungsthread kann auf 128 Allzweckregister innerhalb des GRF 624 zugreifen, wobei jedes Register 32 Bytes speichern kann, die als SIMD 8-Element-Vektor von 32-Bit-Datenelementen zugänglich sind. In einer Ausführungsform hat jeder Ausführungseinheitsthread Zugriff auf 4 Kilobyte innerhalb des GRF 624, obwohl Ausführungsformen nicht derartig eingeschränkt sind, und mehr oder weniger Registerressourcen können in anderen Ausführungsformen bereitgestellt werden. In einer Ausführungsform können bis zu sieben Threads gleichzeitig ausgeführt werden, obwohl die Anzahl von Threads pro Ausführungseinheit gemäß den Ausführungsformen auch variieren kann. In einer Ausführungsform, in der sieben Threads auf 4 Kilobyte zugreifen können, kann das GRF 624 insgesamt 28 Kilobyte speichern. Flexible Adressiermodi können es gestatten, dass Register zusammen adressiert werden, um effektiv breitere Register aufzubauen, oder um streifenförmige rechteckige Blockdatenstrukturen zu repräsentieren.
In einer Ausführungsform werden Speicheroperationen, Sampleroperationen und andere Systemkommunikationsvorgänge von längerer Latenz über „Senden“-Befehle versendet, die durch die Nachrichtenübertragungs-Sendeeinheit 630 ausgeführt werden. In einer Ausführungsform werden Verzweigungsbefehle zu einer dedizierten Verzweigungseinheit 632 versendet, um SIMD-Divergenz und eventuelle Konvergenz zu unterstützen.
In einer Ausführungsform enthält die Grafikausführungseinheit 608 ein oder mehrere SIMD-Gleitkommaeinheiten (FPU(s)) 634 zur Durchführung von Gleitkommaoperationen. In einer Ausführungsform unterstützen die FPU(s) 634 auch Ganzzahlberechnung. In einer Ausführungsform können die FPU(s) 634 bis zu M Zahlen von 32-Bit-Gleitkomma- (oder Ganzzahl-) Operationen SIMD-ausführen, oder bis zu 2M von 16-Bit-Ganzzahl- oder 16-Bit-Gleitkommaoperationen SIMD-ausführen. In einer Ausführungsform bietet mindestens eine der FPU(s) erweiterte Rechenfähigkeit, um transzendentale Rechenfunktionen von hohem Durchsatz und 64-Bit-Gleitkommafunktionen von doppelter Präzision zu unterstützen. In einigen Ausführungsformen ist ein Satz von 8-Bit-Ganzzahl-SIMD ALUs 635 ebenfalls vorhanden und kann speziell optimiert werden, um mit Maschinenlemberechnungen verbundene Operationen durchzuführen.
In einer Ausführungsform können Arrays von mehreren Instanzen der Grafikausführungseinheit 608 in einer Grafik-Teilkern-Gruppierung (z. B. einer Teilscheibe) instanziiert werden. Für Skalierbarkeit können Produktarchitekten die genaue Anzahl von Ausführungseinheiten pro Teilkerngruppierung wählen. In einer Ausführungsform kann die Ausführungseinheit 608 Befehle über eine Vielzahl von Ausführungskanälen ausführen. In einer weiteren Ausführungsform wird jeder auf der Grafikausführungseinheit 608 ausgeführte Thread auf einem anderen Kanal ausgeführt.
7 ist ein Blockdiagramm, das Grafikprozessor-Befehlsformate 700 gemäß einigen Ausführungsformen darstellt. In ein oder mehreren Ausführungsformen unterstützen die Grafikprozessor-Ausführungseinheiten einen Befehlssatz, der Befehle in mehreren Formaten aufweist. Die Kästen mit durchgezogener Linie stellen die Komponenten dar, die im Allgemeinen in einem Ausführungseinheitsbefehl enthalten sind, während die Kästen mit gestrichelter Linie Komponenten enthalten, die optional oder nur in einem Teilsatz der Befehle enthalten sind. In einigen Ausführungsformen stellt das beschriebene und dargestellte Befehlsformat 700 Makrobefehle dar, insofern als sie Befehle sind, die der Ausführungseinheit zugeführt werden, im Gegensatz zu Mikrooperationen, die aus Befehlsdecodierung resultieren, nachdem der Befehl verarbeitet worden ist.
In einigen Ausführungsformen unterstützen die Grafikprozessor-Ausführungseinheiten nativ Befehle in einem 128-Bit-Befehlsformat 710. Ein komprimiertes 64-Bit-Befehlsformat 730 ist für einige Befehle auf der Basis des ausgewählten Befehls, der Befehlsoptionen und der Anzahl von Operanden verfügbar. Das native 128-Bit-Befehlsformat 710 bietet Zugriff auf alle Befehlsoptionen, während einige Optionen und Operationen in dem 64-Bit-Format 730 eingeschränkt sind. Die in dem 64-Bit-Format 730 verfügbaren nativen Befehle variieren nach Ausführungsform. In einigen Ausführungsformen wird der Befehl unter Verwendung eines Satzes von Indexwerten in einem Indexfeld 713 teilweise komprimiert. Die Ausführungseinheit-Hardware referenziert einen Satz von Komprimierungstabellen auf der Basis der Indexwerte und verwendet die Komprimierungstabellenausgaben, um einen nativen Befehl in dem 128-Bit-Befehlsformat 710 zu rekonstruieren.
Für jedes Format definiert der Befehls-Opcode 712 die Operation, die von der Ausführungseinheit auszuführen ist. Die Ausführungseinheiten führen jeden Befehl parallel über die mehreren Datenelemente jedes Operanden aus. Zum Beispiel führt die Ausführungseinheit als Reaktion auf einen Hinzufügungsbefehl eine simultane Hinzufügungsoperation über jeden Farbkanal, der ein Texturelement oder Bildelement repräsentiert, durch. Standardmäßig führt die Ausführungseinheit jeden Befehl über alle Datenkanäle der Operanden durch. In einigen Ausführungsformen ermöglicht das Befehlssteuerfeld 714 eine Kontrolle über bestimmte Ausführungsoptionen, wie z. B. Kanalwahl (z. B. Prädikation) und Datenkanalreihenfolge (z. B. Umstellmechanismus). Für Befehle in dem 128-Bit-Befehlsformat 710 begrenzt ein Exec-Größenfeld 716 die Anzahl von Datenkanälen, die parallel ausgeführt werden. In einigen Ausführungsformen ist das Exec-Größenfeld 716 nicht für die Verwendung in dem kompakten 64-Bit-Befehlsformat 730 verfügbar.
Einige Ausführungseinheitsbefehle haben bis zu drei Operanden, die zwei Quellenoperanden, src0 720, src1 722 und ein Ziel 718 enthalten. In einigen Ausführungsformen unterstützen die Ausführungseinheiten doppelte Zielbefehle, wobei eines der Ziele impliziert wird. Datenmanipulationsbefehle können einen dritten Quellenoperanden (z. B. SRC2 724) aufweisen, wobei der Befehls-Opcode 712 die Anzahl von Quellenoperanden bestimmt. Der letzte Quellenoperand eines Befehls kann ein unmittelbarer (z. B. hartcodierter) Wert sein, der mit dem Befehl weitergeleitet wird.
In einigen Ausführungsformen enthält das 128-Bit-Befehlsformat 710 ein Zugriffs-/Adressmodusfeld 726 das zum Beispiel angibt, ob der direkte Registeradressiermodus oder der indirekte Registeradressiermodus verwendet wird. Wenn der direkte Registeradressiermodus verwendet wird, wird die Registeradresse von ein oder mehreren Operanden direkt durch Bits in dem Befehl bereitgestellt.
In einigen Ausführungsformen enthält das 128-Bit-Befehlsformat 710 ein Zugriffs-/Adressmodusfeld 726, das einen Adressmodus und/oder einen Zugriffsmodus für den Befehl angibt. In einer Ausführungsform wird der Zugriffsmodus verwendet, um eine Datenzugriffsausrichtung für den Befehl zu definieren. Einige Ausführungsformen unterstützen Zugriffsmodi, die einen 16-Byte-Ausrichtungs-Zugriffsmodus und einen 1-Byte-Ausrichtungs-Zugriffsmodus enthalten, wobei die Byteausrichtung des Zugriffsmodus die Zugriffsausrichtung der Befehlsoperanden bestimmt. Zum Beispiel kann der Befehl in einem ersten Modus Byte-ausgerichtete Adressierung für Quellen- und Zieloperanden verwenden, während der Befehl in einem zweiten Modus 16-Byte-ausgerichtete Adressierung für alle Quellen- und Zieloperanden verwenden kann.
In einer Ausführungsform bestimmt der Adressmodusteil des Zugriffs-/Adressmodusfelds 726, ob der Befehl direkte oder indirekte Adressierung verwenden soll. Wenn der direkte Registeradressiermodus verwendet wird, liefern Bits in dem Befehl direkt die Registeradresse von ein oder mehreren Operanden. Wenn der indirekte Registeradressiermodus verwendet wird, kann die Registeradresse von ein oder mehreren Operanden auf der Basis eines Adressenregisterwertes und eines unmittelbaren Adressenfelds in dem Befehl berechnet werden.
In einigen Ausführungsformen werden Befehle auf der Basis von Bitfeldern des Opcodes 712 gruppiert, um die Opcode-Decodierung 740 zu vereinfachen. Für einen 8-Bit-Opcode gestatten die Bits 4, 5 und 6 der Ausführungseinheit, die Art des Opcodes zu bestimmen. Die gezeigte präzise Opcodegruppierung ist lediglich ein Beispiel. In einigen Ausführungsformen enthält eine Bewegungs- und Logik-Opcodegruppe 742 Datenbewegungs- und Logikbefehle (z. B. Bewegen (mov), Vergleichen (cmp)). In einigen Ausführungsformen teilt die Bewegungs- und Logikgruppe 742 die fünf höchstwertigen Bits (MSB), wobei Bewegungs-(mov)-Befehle in der Form von 0000xxxxb vorliegen, und Logikbefehle in der Form von 0001xxxxb vorliegen. Eine Ablaufsteuerungs-Befehlsgruppe 744 (z. B. Aufruf, Sprung (jmp)) enthält Befehle in der Form von 0010xxxxb (z. B. 0x20). Eine Gruppe für verschiedene Befehle 746 enthält eine Mischung aus Befehlen, die Synchronisierungsbefehle (z. B. Warten, Senden) in der Form von 0011xxxxb (z. B. 0x30) enthalten. Eine parallele Rechenbefehlsgruppe 748 enthält komponentenweise Rechenbefehle (z. B. Addieren, Multiplizieren (mul)) in der Form von 0100xxxxb (z. B. 0x40). Die parallele Rechengruppe 748 führt die Rechenoperationen parallel über Datenkanäle durch. Die Vector Math-Gruppe 750 enthält Rechenbefehle (z. B. dp4) in der Form von 0101xxxxb (z. B. 0x50). Die Vector Math-Gruppe führt Arithmetik, wie z. B. Skalarproduktberechnungen, an Vektoroperanden durch.
Grafik-Pipeline
8 ist ein Blockdiagramm einer weiteren Ausführungsform eines Grafikprozessors 800. Elemente von 8, welche die gleichen Bezugsnummern (oder Namen) wie die Elemente einer anderen hierin enthaltenen Figur haben, können in jeder Weise ähnlich den woanders hierin beschriebenen Elementen arbeiten oder funktionieren, sind aber nicht auf solche beschränkt.
In einigen Ausführungsformen enthält der Grafikprozessor 800 eine Geometrie-Pipeline 820, eine Medien-Pipeline 830, eine Display-Engine 840, Thread-Ausführungslogik 850 und eine Renderausgabe-Pipeline 870. In einigen Ausführungsformen ist der Grafikprozessor 800 ein Grafikprozessor innerhalb eines Mehrkern-Verarbeitungssystems, das ein oder mehrere Allzweck-Verarbeitungskerne enthält. Der Grafikprozessor wird durch Registerschreibvorgänge zu ein oder mehreren Steuerregistern (nicht gezeigt) oder über Befehle, die über einen Ring-Interconnect 802 an den Grafikprozessor 800 ausgegeben werden, gesteuert. In einigen Ausführungsformen koppelt der Ring-Interconnect 802 den Grafikprozessor 800 mit anderen Verarbeitungskomponenten, z. B. mit anderen Grafikprozessoren oder Allzweckprozessoren. Befehle vom Ring-Interconnect 802 werden durch einen Befehlsstreamer 803 interpretiert, der Anweisungen zu individuellen Komponenten der Geometrie-Pipeline 820 oder der Medien-Pipeline 830 liefert.
In einigen Ausführungsformen leitet der Befehlsstreamer 803 die Operation eines Vertex-Fetchers 805, der Vertexdaten aus dem Speicher ausliest und von dem Befehlsstreamer 803 gelieferte Vertex-Verarbeitungsbefehle ausführt. In einigen Ausführungsformen liefert der Vertex-Fetcher 805 Vertexdaten zu einem Vertex-Shader 807, der Koordinaten-Raumtransformations- und Beleuchtungsoperationen für jeden Vertex durchführt. In einigen Ausführungsformen führen Vertex-Fetcher 805 und Vertex-Shader 807 Vertex-Verarbeitungsbefehle aus, indem sie Ausführungsthreads über einen Thread-Dispatcher 831 zu den Ausführungseinheiten 852A-852B versenden.
In einigen Ausführungsformen sind die Ausführungseinheiten 852A-852B ein Array von Vektorprozessoren, die einen Befehlssatz zur Durchführung von Grafik- und Medienoperationen aufweisen. In einigen Ausführungsformen haben die Ausführungseinheiten 852A-852B einen angeschlossenen L1-Cache 851, der für jedes Array spezifisch ist oder zwischen den Arrays geteilt wird. Der Cache kann als Datencache, Befehlscache oder Einzelcache konfiguriert werden, der partitioniert ist, um Daten und Befehle in unterschiedlichen Partitionen zu enthalten.
In einigen Ausführungsformen enthält die Geometrie-Pipeline 820 Tessellationskomponenten, um hardwarebeschleunigte Tessellation von 3D-Objekten durchzuführen. In einigen Ausführungsformen konfiguriert ein programmierbarer Hull-Shader 811 die Tessellationsoperationen. Ein programmierbarer Domain-Shader 817 liefert Back-End-Bewertung der Tessellationsausgabe. Ein Tessellator 813 arbeitet auf Anweisung des Hull-Shaders 811 und enthält Sonderzwecklogik, um einen Satz von detaillierten geometrischen Objekten auf der Basis eines groben geometrischen Modells zu erzeugen, das als Eingabe in die Geometrie-Pipeline 820 bereitgestellt wird. Falls Tessellation in einigen Ausführungsformen nicht verwendet wird, können die Tessellationskomponenten (z. B. Hull-Shader 811, Tessellator 813 und Domain-Shader 817) umgangen werden.
In einigen Ausführungsformen können komplette geometrische Objekte durch einen Geometrie-Shader 819 über ein oder mehrere Threads verarbeitet werden, die an die Ausführungseinheiten 852A-852B versendet werden, oder sie können direkt zu dem Clipper 829 vorrücken. In einigen Ausführungsformen arbeitet der Geometrie-Shader an gesamten geometrischen Objekten anstatt an Vertices oder Stücken von Vertices, wie in vorhergehenden Phasen der Grafik-Pipeline. Falls die Tessellation deaktiviert ist, empfängt der Geometrie-Shader 819 Eingabe von dem Vertex-Shader 807. In einigen Ausführungsformen ist der Geometrie-Shader 819 durch ein Geometrie-Shaderprogramm programmierbar, um Geometrie-Tessellation durchzuführen, falls die Tessellationseinheiten deaktiviert sind.
Vor der Rasterisierung verarbeitet ein Clipper 829 Vertexdaten. Der Clipper 829 kann ein Festfunktionsclipper oder ein programmierbarer Clipper sein, der Clipping- und Geometrie-Shaderfunktionen aufweist. In einigen Ausführungsformen versendet eine Rasterisierungs- und Tiefentestkomponente 873 in der Render-Ausgabepipeline 870 Pixel-Shader, um die geometrischen Objekte in Pro-Pixel-Repräsentationen umzuwandeln. In einigen Ausführungsformen ist eine Pixel-Shaderlogik in der Thread-Ausführungslogik 850 enthalten. In einigen Ausführungsformen kann eine Anwendung die Rasterisierungs- und Tiefentestkomponente 873 umgehen und über eine Streamausgabeeinheit 823 auf nicht rasterisierte Vertexdaten zugreifen.
Der Grafikprozessor 800 hat einen Interconnect-Bus, ein Interconnect-Netzwerk oder einen anderen Interconnect-Mechanismus, der Daten- und Nachrichtendurchgang zwischen den Hauptkomponenten des Prozessors gestattet. In einigen Ausführungsformen sind die Ausführungseinheiten 852A-852B und die zugehörigen Logikeinheiten (z. B. L1-Cache 851, Sampler 854, Texturcache 858 usw.) über einen Datenport 856 verbunden, um Speicherzugriff durchzuführen und mit Renderausgabe-Pipelinekomponenten des Prozessors zu kommunizieren. In einigen Ausführungsformen verwenden Sampler 854, Caches 851, 858 und Ausführungseinheiten 852A-852B jeweils getrennte Speicherzugriffspfade. In einer Ausführungsform kann der Texturcache 858 auch als Samplercache konfiguriert sein.
In einigen Ausführungsformen enthält die Renderausgabe-Pipeline 870 eine Rasterisierungs- und Tiefentestkomponente 873, die vertexbasierte Objekte in eine zugehörige pixelbasierte Repräsentation umwandelt. In einigen Ausführungsformen enthält die Rastererlogik eine Windower/Masker-Einheit, um Festfunktions-Dreieck- und Linienrasterisierung durchzuführen. Ein verbundener Rendercache 878 und Tiefencache 879 sind in einigen Ausführungsformen ebenfalls verfügbar. Eine Pixeloperationskomponente 877 führt pixelbasierte Operationen an den Daten durch, obwohl in manchen Fällen mit 2D-Operationen (z. B. Bitblock-Bildübertragungen mit Mischung) verbundene Pixeloperationen durch die 2D-Engine 841 durchgeführt oder zur Anzeigezeit durch den Anzeige-Controller 843 unter Verwendung von Überlagerungs-Anzeigeebenen ersetzt werden. In einigen Ausführungsformen ist ein gemeinsamer L3-Cache 875 für alle Grafikkomponenten verfügbar, so dass die gemeinsame Nutzung von Daten ohne Verwendung des Hauptsystemspeichers möglich ist.
In einigen Ausführungsformen enthält die Grafikprozessor-Medien-Pipeline 830 eine Medien-Engine 837 und ein Video-Front-End 834. In einigen Ausführungsformen empfängt das Video-Front-End 834 Pipelinebefehle von dem Befehlsstreamer 803. In einigen Ausführungsformen enthält die Medien-Pipeline 830 einen getrennten Befehlsstreamer. In einigen Ausführungsformen verarbeitet das Video-Front-End 834 Medienbefehle, bevor der Befehl zu der Medien-Engine 837 gesendet wird. In einigen Ausführungsformen enthält die Medien-Engine 837 Thread-Hervorbringungsfunktionalität, um Threads zum Versenden zu der Thread-Ausführungslogik 850 über den Thread-Dispatcher 831 hervorzubringen.
In einigen Ausführungsformen enthält der Grafikprozessor 800 eine Display-Engine 840. In einigen Ausführungsformen ist die Display-Engine 840 extern zu dem Prozessor 800 und koppelt mit dem Grafikprozessor über den Ring-Interconnect 802 oder einen anderen Interconnect-Bus oder ein Netzwerk. In einigen Ausführungsformen enthält die Display-Engine 840 eine 2D-Engine 841 und einen Anzeige-Controller 843. In einigen Ausführungsformen enthält die Display-Engine 840 Sonderzwecklogik, die in der Lage ist, unabhängig von der 3D-Pipeline zu arbeiten. In einigen Ausführungsformen koppelt der Anzeige-Controller 843 mit einer Anzeigevorrichtung (nicht gezeigt), die eine systemintegrierte Anzeigevorrichtung, wie in einem Laptop-Computer, oder eine externe Anzeigevorrichtung sein kann, die über einen Anzeigevorrichtungsanschluss angeschlossen wird.
In einigen Ausführungsformen sind die Geometrie-Pipeline 820 und die Medien-Pipeline 830 konfigurierbar, um auf mehreren Grafik- und Medien-Programmierschnittstellen basierende Operationen durchzuführen, und sind nicht spezifisch für eine beliebige Anwendungsprogrammierschnittstelle (API). In einigen Ausführungsformen übersetzt Treibersoftware für den Grafikprozessor API-Aufrufe, die spezifisch für eine bestimmte Grafik- oder Medienbibliothek sind, in Befehle, die von dem 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 Berechnungs-API, alle von der Khronos Group, bereitgestellt. In einigen Ausführungsformen kann auch Unterstützung 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 ein Mapping von der Pipeline der zukünftigen API zu der Pipeline des Grafikprozessors gemacht werden kann.
Grafik-Pipeline-Programmierung
9A ist ein Blockdiagramm, das ein Grafikprozessor-Befehlsformat 900 gemäß einigen Ausführungsformen darstellt. 9B ist ein Blockdiagramm, das eine Grafikprozessor-Befehlssequenz 910 gemäß einer Ausführungsform darstellt. Die Kästen mit durchgezogener Linie in 9A stellen die Komponenten dar, die im Allgemeinen in einem Grafikbefehl enthalten sind, während die Kästen mit gestrichelter Linie Komponenten enthalten, die optional oder nur in einem Teilsatz der Grafikbefehle enthalten sind. Das beispielhafte Grafikprozessor-Befehlsformat 900 von 9A enthält Datenfelder, um einen Client 902, einen Befehlsoperationscode (Opcode) 904 und Daten 906 für den Befehl zu identifizieren. Ein Sub-Opcode 905 und eine Befehlsgröße 908 sind ebenfalls in einigen Befehlen enthalten.
In einigen Ausführungsformen gibt der Client 902 die Client-Einheit des Grafikgerätes an, das die Befehlsdaten verarbeitet. In einigen Ausführungsformen untersucht ein Grafikprozessor-Befehlsparser das Client-Feld jedes Befehls, um die weitere Verarbeitung des Befehls zu konditionieren und die Befehlsdaten zu der entsprechenden Client-Einheit zu leiten. In einigen Ausführungsformen enthalten die Grafikprozessor-Client-Einheiten eine Speicherschnittstelleneinheit, eine Rendereinheit, eine 2D-Einheit, eine 3D-Einheit und eine Medieneinheit. Jede Client-Einheit hat eine entsprechende Verarbeitungs-Pipeline, welche die Befehle verarbeitet. Sobald der Befehl von der Client-Einheit empfangen wird, liest die Client-Einheit den Opcode 904 und, falls vorhanden, den Sub-Opcode 905, um die durchzuführende Operation zu bestimmen. Die Client-Einheit führt den Befehl unter Verwendung der Informationen im Datenfeld 906 durch. Für einige Befehle wird eine explizite Befehlsgröße 908 erwartet, um die Größe des Befehls anzugeben. In einigen Ausführungsformen bestimmt der Befehlsparser automatisch die Größe von mindestens einigen der Befehle auf der Basis des Befehls-Opcodes. In einigen Ausführungsformen werden Befehle über Vielfache eines Doppelworts ausgerichtet.
Das Flussdiagramm in 9B stellt eine beispielhafte Grafikprozessor-Befehlssequenz 910 dar. In einigen Ausführungsformen verwendet Software oder Firmware eines Datenverarbeitungssystems, das eine Ausführungsform eines Grafikprozessors aufweist, eine Version der gezeigten Befehlssequenz, um einen Satz von Grafikoperationen einzurichten, auszuführen und zu beenden. Eine beispielhafte Befehlssequenz wird lediglich zum Zwecke eines Beispiels gezeigt und beschrieben, da Ausführungsformen nicht auf diese spezifischen Befehle oder diese Befehlssequenz beschränkt sind. Darüber hinaus können die Befehle als Stapel von Befehlen in einer Befehlssequenz ausgegeben werden, so dass der Grafikprozessor die Sequenz von Befehlen in zumindest teilweiser Übereinstimmung verarbeitet.
In einigen Ausführungsformen kann die Grafikprozessor-Befehlssequenz 910 mit einem Pipeline-Spülbefehl 912 beginnen, um eine aktive Grafik-Pipeline zu veranlassen, die gegenwärtig ausstehenden Befehle für die Pipeline zu vollenden. In einigen Ausführungsformen arbeiten die 3D-Pipeline 922 und die Medien-Pipeline 924 nicht gleichzeitig. Die Pipeline-Spülung wird durchgeführt, um die aktive Grafik-Pipeline zu veranlassen, etwaige ausstehende Befehle zu vollenden. Als Reaktion auf eine Pipeline-Spülung unterbricht der Befehlsparser für den Grafikprozessor die Befehlsverarbeitung, bis die aktiven Zeichnungs-Engines ausstehende Operationen vollenden und die relevanten Lese-Caches invalidiert werden. Optional können etwaige Daten im Rendercache, die als ,schmutzig‘ markiert sind, in den Speicher gespült werden. In einigen Ausführungsformen kann der Pipeline-Spülbefehl 912 für Pipeline-Synchronisierung oder vor der Versetzung des Grafikprozessors in einen Energiesparzustand verwendet werden.
In einigen Ausführungsformen wird ein Pipeline-Auswahlbefehl 913 verwendet, wenn eine Befehlssequenz ausdrücklich vom Grafikprozessor verlangt, zwischen Pipelines umzuschalten. In einigen Ausführungsformen ist ein Pipeline-Auswahlbefehl 913 nur einmal innerhalb eines Ausführungskontextes vor der Ausgabe von Pipeline-Befehlen erforderlich, es sei denn der Kontext besteht darin, Befehle für beide Pipelines auszugeben. In einigen Ausführungsformen ist ein Pipeline-Spülbefehl 912 unmittelbar vor einer Pipeline-Umschaltung über den Pipeline-Auswahlbefehl 913 erforderlich.
In einigen Ausführungsformen konfiguriert ein Pipeline-Steuerbefehl 914 eine Grafik-Pipeline für eine Operation und wird verwendet, die 3D-Pipeline 922 und die Medien-Pipeline 924 zu programmieren. In einigen Ausführungsformen konfiguriert der Pipeline-Steuerbefehl 914 den Pipeline-Zustand für die aktive Pipeline. In einer Ausführungsform wird der Pipeline-Steuerbefehl 914 für Pipeline-Synchronisierung und zum Löschen von Daten von einem oder mehreren Cache-Speichern innerhalb der aktiven Pipeline vor der Verarbeitung eines Stapels von Befehlen verwendet.
In einigen Ausführungsformen werden Rückgabepuffer-Zustandsbefehle 916 verwendet, um einen Satz von Rückgabepuffern für die entsprechenden Pipelines zum Schreiben von Daten zu konfigurieren. Einige Pipeline-Operationen erfordern die Zuweisung, Auswahl oder Konfiguration von ein oder mehreren Rückgabepuffern, in welche die Operationen Zwischendaten während der Verarbeitung schreiben. In einigen Ausführungsformen verwendet der Grafikprozessor auch ein oder mehrere Rückgabepuffer, um Ausgabedaten zu speichern und Cross-Thread-Kommunikation durchzuführen. In einigen Ausführungsformen beinhaltet der Rückgabepufferzustand 916 das Auswählen der Größe und Anzahl von Rückgabepuffern zur Verwendung für einen Satz von Pipeline-Operationen.
Die verbleibenden Befehle in der Befehlssequenz sind je nach der aktiven Pipeline für Operationen unterschiedlich. Basierend auf einer Pipeline-Bestimmung 920, ist die Befehlssequenz auf die 3D-Pipeline 922 beginnend mit dem 3D-Pipeline-Zustand 930 oder die Medien-Pipeline 924 beginnend bei dem Medien-Pipeline-Zustand 940 abgestimmt.
Die Befehle zum Konfigurieren des 3D-Pipeline-Zustands 930 enthalten 3D-Zustand-Einstellungsbefehle für Vertex-Pufferzustand, Vertex-Elementzustand, Konstantfarbenzustand, Tiefenpufferzustand und andere Zustandsvariablen, die zu konfigurieren sind, bevor 3D-Grundkörperbefehle verarbeitet werden. Die Werte dieser Befehle werden zumindest teilweise auf der Basis der verwendeten bestimmten 3D-API bestimmt. In einigen Ausführungsformen sind Befehle des 3D-Pipeline-Zustands 930 auch in der Lage, bestimmte Pipeline-Elemente gezielt zu deaktivieren oder zu umgehen, falls diese Elemente nicht verwendet werden.
In einigen Ausführungsformen wird ein 3D-Grundkörperbefehl 932 verwendet, um durch die 3D-Pipeline zu verarbeitende 3D-Grundkörper zu übermitteln. Befehle und zugehörige Parameter, die über den Befehl des 3D-Grundkörpers 932 zu dem Grafikprozessor geleitet werden, werden zu der Vertex-Abruffunktion in der Grafik-Pipeline weitergeleitet. Die Vertex-Abruffunktion verwendet die Befehlsdaten des 3D-Grundkörpers 932, um Vertex-Datenstrukturen zu erzeugen. Die Vertex-Datenstrukturen werden in ein oder mehreren Rückgabepuffern gespeichert. In einigen Ausführungsformen wird der Befehl des 3D-Grundkörpers 932 verwendet, um Vertex-Operationen an 3D-Grundkörpern über Vertex-Shader durchzuführen. Um Vertex-Shader zu verarbeiten, versendet die 3D-Pipeline 922 Shader-Ausführungsthreads zu Grafikprozessor-Ausführungseinheiten.
In einigen Ausführungsformen wird die 3D-Pipeline 922 über einen Ausführungsbefehl 934 oder ein Ausführungsereignis ausgelöst. In einigen Ausführungsformen löst ein Registerschreibvorgang eine Befehlsausführung aus. In einigen Ausführungsformen wird die Ausführung über den Befehl ,go‘ oder ,kick‘ in der Befehlssequenz ausgelöst. In einer Ausführungsform wird die Befehlsausführung unter Verwendung eines Pipeline-Synchronisierungsbefehls ausgelöst, um die Befehlssequenz durch die Grafik-Pipeline zu spülen. Die 3D-Pipeline führt Geometrieverarbeitung für die 3D-Grundkörper durch. Sobald die Operationen abgeschlossen sind, werden die resultierenden geometrischen Objekte rasterisiert, und die Pixel-Engine färbt die resultierenden Pixel. Zusätzliche Befehle zum Steuern von Pixel-Shading und Pixel-Back-End-Operationen können ebenfalls für diese Operationen enthalten sein.
In einigen Ausführungsformen folgt die Grafikprozessor-Befehlssequenz 910 dem Pfad der Medien-Pipeline 924 bei der Durchführung von Medienoperationen. Im Allgemeinen hängt die spezifische Nutzung und Art der Programmierung für die Medien-Pipeline 924 von den durchzuführenden Medien- oder Berechnungsoperationen ab. Spezifische Mediendecodierungsoperationen können während der Mediendecodierung auf die Medien-Pipeline abgeladen werden. In einigen Ausführungsformen kann die Medien-Pipeline auch umgangen werden, und die Mediendecodierung kann ganz oder teilweise unter Verwendung von Ressourcen durchgeführt werden, die von ein oder mehreren Allzweck-Verarbeitungskernen bereitgestellt werden. In einer Ausführungsform enthält die Medien-Pipeline auch Elemente für Operationen der Allzweck-Grafikprozessoreinheit (GPGPU), wobei der Grafikprozessor verwendet wird, um SIMD-Vektoroperationen unter Verwendung von rechnerischen Shaderprogrammen durchzuführen, die nicht ausdrücklich auf das Rendern von Grafik-Grundkörpern bezogen sind.
In einigen Ausführungsformen ist die Medien-Pipeline 924 in einer ähnlichen Weise wie die 3D-Pipeline 922 ausgelegt. Ein Satz von Befehlen zum Konfigurieren des Medien-Pipelinezustands 940 wird versendet oder in eine Befehlswarteschlange vor den Medienobjektbefehlen 942 gesetzt. In einigen Ausführungsformen enthalten Befehle für den Medien-Pipelinezustand 940 Daten zum Konfigurieren der Medien-Pipeline-Elemente, die zum Verarbeiten der Medienobjekte verwendet werden. Dies schließt Daten zum Konfigurieren der Videodecodier- und Videocodierlogik innerhalb der Medien-Pipeline ein, wie z. B. das Codier- oder Decodierformat. In einigen Ausführungsformen unterstützen Befehle für den Medien-Pipelinezustand 940 auch die Verwendung von ein oder mehreren Zeigern zu Elementen des Zustands „indirekt“, die einen Stapel von Zustandseinstellungen enthalten.
In einigen Ausführungsformen liefern Medienobjektbefehle 942 Zeiger zu Medienobjekten zum Verarbeiten durch die Medien-Pipeline. Die Medienobjekte schließen Speicherpuffer ein, die zu verarbeitende Videodaten enthalten. In einigen Ausführungsformen müssen alle Medien-Pipelinezustände gültig sein, bevor ein Medienobjektbefehl 942 ausgegeben wird. Nachdem der Pipelinezustand konfiguriert worden ist und die Medienobjektbefehle 942 aufgereiht worden sind, wird die Medien-Pipeline 924 über einen Ausführbefehl 944 oder ein gleichwertiges Ausführereignis (z. B. Registerschreibvorgang) ausgelöst. Die Ausgabe von der Medien-Pipeline 924 kann dann durch Operationen, die von der 3D-Pipeline 922 oder der Medien-Pipeline 924 bereitgestellt werden, nachverarbeitet werden. In einigen Ausführungsformen werden die GPGPU-Operationen in einer ähnlichen Weise wie Medienoperationen konfiguriert und ausgeführt.
Grafiksoftwarearchitektur
10 stellt eine beispielhafte Grafiksoftwarearchitektur für ein Datenverarbeitungssystem 1000 gemäß einiger Ausführungsformen dar. 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 Allzweck-Prozessorkern(e) 1034. Die Grafikanwendung 1010 und das Betriebssystem 1020 werden jeweils im Systemspeicher 1050 des Datenverarbeitungssystems ausgeführt.
In einigen Ausführungsformen enthält die 3D-Grafikanwendung 1010 ein oder mehrere Shaderprogramme, die Shaderbefehle 1012 aufweisen. Die Shader-Sprachbefehle können in einer Shader-Hochsprache vorliegen, wie z. B. der High Level Shader Language (HLSL) oder der OpenGL Shader Language (GLSL). Die Anwendung enthält auch ausführbare Befehle 1014 in einer Maschinensprache, die für Ausführung durch den Allzweck-Prozessorkern 1034 geeignet ist. Die Anwendung enthält auch durch Vertexdaten definierte Grafikobjekte 1016.
In einigen Ausführungsformen ist das Betriebssystem 1020 ein Microsoft® Windows® Betriebssystem von der Microsoft Corporation, ein proprietäres UNIX-artiges Betriebssystem oder ein UNIX-artiges Open-Source-Betriebssystem, das eine Variante des Linux-Kerns verwendet. Das Betriebssystem 1020 kann eine Grafik-API 1022, wie etwa die Direct3D-API, die OpenGL-API oder die Vulkan-API, unterstützen. Wenn die Direct3D-API in Gebrauch ist, verwendet das Betriebssystem 1020 einen Front-End-Shader-Compiler 1024, um in HLSL vorliegende Shaderbefehle 1012 zu einer Shadersprache einer niedrigeren Ebene zu kompilieren. Die Kompilierung kann eine Just-in-Time (JIT)-Kompilierung sein, oder die Anwendung kann eine Shader-Vorkompilierung durchführen. In einigen Ausführungsformen werden Shader einer hohen Ebene während der Kompilierung der 3D-Grafikanwendung 1010 zu Shadern einer niedrigen Ebene kompiliert. In einigen Ausführungsformen werden die Shaderbefehle 1012 in einer Zwischenform bereitgestellt, wie z. B. einer Version der von der Vulkan-API verwendeten Standard Portable Intermediate Representation (SPIR).
In einigen Ausführungsformen enthält der Benutzermodus-Grafiktreiber 1026 einen Back-End-Shader-Compiler 1027, um die Shaderbefehle 1012 in eine hardwarespezifische Repräsentation umzuwandeln. Wenn die OpenGL-API in Gebrauch ist, werden Shaderbefehle 1012 in der GLSL-Hochsprache zur Kompilierung zu einem Benutzermodus-Grafiktreiber 1026 geleitet. In einigen Ausführungsformen verwendet der Benutzermodus-Grafiktreiber 1026 Betriebssystem-Kernmodusfunktionen 1028, um mit einem Kernmodus-Grafiktreiber 1029 zu kommunizieren. In einigen Ausführungsformen kommuniziert der Kernmodus-Grafiktreiber 1029 mit dem Grafikprozessor 1032, um Befehle und Anweisungen zu versenden.
IP-Kern-Implementierungen
Ein oder mehrere Aspekte von mindestens einer Ausführungsform können durch repräsentativen Code implementiert werden, der auf einem maschinenlesbaren Medium gespeichert ist, und der Logik innerhalb einer integrierten Schaltung, wie z. B. einem Prozessor, repräsentiert und/oder definiert. Beispielsweise kann das maschinenlesbare Medium Befehle enthalten, die verschiedene Logik innerhalb des Prozessors repräsentieren. Wenn von einer Maschine gelesen, können die Befehle die Maschine veranlassen, die Logik zu fabrizieren, um die hierin beschriebenen Techniken durchzuführen. Solche Repräsentationen, auch als „IP-Kerne“ bekannt, sind wiederverwendbare Einheiten von Logik für eine integrierte Schaltung, die auf einem materiellen, maschinenlesbaren Medium als ein Hardwaremodell gespeichert werden können, das die Struktur der integrierten Schaltung beschreibt. Das Hardwaremodell kann zu verschiedenen Kunden oder Herstellungseinrichtungen geliefert werden, die das Hardwaremodell auf Fertigungsmaschinen laden, welche die integrierte Schaltung herstellen. Die integrierte Schaltung kann so gefertigt werden, dass die Schaltung Operationen durchführt, die in Verbindung mit beliebigen der hierin beschriebenen Ausführungsformen beschrieben werden.
11A ist ein Blockdiagramm, das ein IP-Kernentwicklungssystem 1100 darstellt, das zur Herstellung einer integrierten Schaltung verwendet werden kann, um Operationen gemäß einer Ausführungsform durchzuführen. Das IP-Kernentwicklungssystem 1100 kann verwendet werden, um modulare, wiederverwendbare Designs zu erzeugen, die in ein größeres Design integriert oder verwendet werden können, um eine gesamte integrierte Schaltung (z. B. eine integrierte SOC-Schaltung) zu konstruieren. Eine Designeinrichtung 1130 kann eine Softwaresimulation 1110 eines IP-Core-Designs in einer Programmier-Hochsprache (z. B. C/C++) erzeugen. Die Softwaresimulation 1110 kann verwendet werden, um das Verhalten des IP-Kerns unter Verwendung eines Simulationsmodells 1112 zu entwerfen, zu testen und zu überprüfen. Das Simulationsmodell 1112 kann funktionale, verhaltensbasierte und/oder Timingsimulationen enthalten. Ein Register-Transfer-Level (RTL)-Design 1115 kann dann von dem Simulationsmodell 1112 erzeugt oder synthetisiert werden. Das RTL-Design 1115 ist eine Abstraktion des Verhaltens der integrierten Schaltung, das den Fluss von Digitalsignalen zwischen Hardwareregistern, einschließlich der zugehörigen Logik, die unter Verwendung der modellierten Digitalsignale durchgeführt wird, modelliert. Zusätzlich zu einem RTL-Design 1115 können auch Designs einer niedrigeren Ebene auf dem Logikniveau oder Transistorniveau erzeugt, entworfen oder synthetisiert werden. Somit können die konkreten Details des anfänglichen Designs und der Simulation variieren.
Das RTL-Design 1115 oder eine Entsprechung kann durch die Designeinrichtung zu einem Hardwaremodell 1120, das in einer Hardwarebeschreibungssprache (HDL) vorliegen kann, oder zu einer anderen Repräsentation der physischen Designdaten weiter synthetisiert werden. Die HDL kann ferner simuliert oder getestet werden, um das IP-Core-Design zu überprüfen. Das IP-Core-Design kann zur Lieferung an eine Fertigungseinrichtung 1165 eines anderen Herstellers unter Verwendung von nichtflüchtigem Speicher 1140 (z. B. Festplatte, Flash-Speicher oder einem beliebigen nichtflüchtigen Speichermedium) gespeichert werden. Alternativ dazu kann das IP-Core-Design über eine Kabelverbindung 1150 oder eine Funkverbindung 1160 übertragen werden (z. B. über das Internet). Die Fertigungseinrichtung 1165 kann dann eine integrierte Schaltung fertigen, die zumindest teilweise auf dem IP-Core-Design basiert. Die gefertigte integrierte Schaltung kann dazu ausgelegt sein, Operationen im Einklang mit mindestens einer hierin beschriebenen Ausführungsform durchzuführen.
11B stellt eine Querschnitts-Seitenansicht einer IC-Gehäuseanordnung 1170 gemäß einigen hierin beschriebenen Ausführungsformen dar. Die IC-Gehäuseanordnung 1170 stellt eine Implementierung von ein oder mehreren Prozessor- oder Beschleunigereinrichtungen dar, wie hierin beschrieben. 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 Festfunktions-Logikhardware implementiert sein, und kann ein oder mehrere Teile eines der Prozessorkerne, der Grafikprozessoren oder der anderen hierin beschriebenen Beschleunigereinrichtungen enthalten. Jede Einheit der Logik 1172, 1174 kann innerhalb eines Halbleiterchips implementiert und über eine Interconnect-Struktur 1173 mit dem Substrat 1180 gekoppelt werden. Die Interconnect-Struktur 1173 kann dazu ausgebildet sein, elektrische Signale zwischen der Logik 1172, 1174 und dem Substrat 1180 zu leiten, und kann solche Interconnects wie etwa Höcker oder Säulen enthalten, ohne jedoch darauf beschränkt zu sein. In einigen Ausführungsformen kann die Interconnect-Struktur 1173 dazu ausgebildet sein, elektrische Signale, wie z. B. Eingabe/Ausgabe (E/A)-Signale und/oder Strom- oder Massesignale, die mit dem Betrieb der Logik 1172, 1174 verbunden sind, zu leiten. In einigen Ausführungsformen ist das Substrat 1180 ein Laminatsubstrat auf Epoxidbasis. In anderen Ausführungsformen kann das Gehäusesubstrat 1180 andere geeignete Arten von Substraten enthalten. Die Gehäuseanordnung 1170 kann über ein Gehäuse-Interconnect 1183 mit anderen elektrischen Vorrichtungen verbunden sein. Das Gehäuse-Interconnect 1183 kann mit einer Oberfläche des Substrats 1180 gekoppelt sein, um elektrische Signale zu anderen elektrischen Vorrichtungen, wie z. B. einer Systemplatine, einem anderen Chipsatz oder einem Multi-Chip-Modul, zu leiten.
In einigen Ausführungsformen sind die Einheiten der Logik 1172, 1174 mit einer Brücke 1182 elektrisch gekoppelt, die dazu ausgelegt ist, elektrische Signale zwischen der Logik 1172, 1174 zu leiten. Die Brücke 1182 kann eine dichte Interconnect-Struktur sein, die eine Route für elektrische Signale bereitstellt. Die Brücke 1182 kann ein Brückensubstrat einschließen, das aus Glas oder einem geeigneten Halbleitermaterial gebildet ist. Elektrische Leitungselemente können auf dem Brückensubstrat gebildet sein, um eine Chip-zu-Chip-Verbindung zwischen der Logik 1172, 1174 bereitzustellen.
Obwohl zwei Einheiten von Logik 1172, 1174 und eine Brücke 1182 dargestellt sind, können die hierin beschriebenen Ausführungsformen mehr oder weniger Logikeinheiten auf ein oder mehreren Chips enthalten. Die ein oder 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 dazu können mehrere Chips oder Logikeinheiten durch ein oder mehrere Brücken verbunden sein. Außerdem können in anderen möglichen Konfigurationen, einschließlich dreidimensionaler Konfigurationen, mehrere Logikeinheiten, Chips und Brücken miteinander verbunden sein.
Beispielhafte integrierte Ein-Chip-System-Schaltung
12-14 stellen beispielhafte integrierte Schaltungen und zugehörige Grafikprozessoren dar, die gemäß verschiedenen hierin beschriebenen Ausführungsformen unter Verwendung von ein oder mehreren IP-Cores gefertigt sein können. Zusätzlich zu den dargestellten Elementen können andere Logikeinheiten und Schaltungen enthalten sein, darunter auch zusätzliche Grafikprozessoren/-kerne, Peripherie-Schnittstellencontroller oder Allzweck-Prozessorkerne.
12 ist ein Blockdiagramm, das eine beispielhafte integrierte Ein-Chip-System-Schaltung 1200 darstellt, die gemäß einer Ausführungsform unter Verwendung von ein oder mehreren IP-Kernen gefertigt werden kann. Die beispielhafte integrierte Schaltung 1200 enthält ein oder mehrere Anwendungsprozessoren 1205 (z. B. CPUs), mindestens einen Grafikprozessor 1210, und kann zusätzlich einen Bildprozessor 1215 und/oder einen Videoprozessor 1220 enthalten, von denen jeder ein modularer IP-Core von derselben oder von mehreren unterschiedlichen Designeinrichtungen sein kann. Die integrierte Schaltung 1200 enthält Peripheriegeräte- oder Bus-Logik, darunter einen USB-Controller 1225, UART-Controller 1230, einen SPI/SDIO-Controller 1235 und einen I2S/I2C-Controller 1240. Außerdem kann die integrierte Schaltung eine Anzeigevorrichtung 1245 enthalten, die mit ein oder mehreren eines High-Definition-Multimedia-Interface (HDMI)-Controllers 1250 und einer Mobile Industry Processor Interface (MIPI)-Anzeigeschnittstelle 1255 gekoppelt ist. Speicherung kann von einem Flash-Speicher-Untersystem 1260 bereitgestellt werden, das einen Flash-Speicher und einen Flash-Speichercontroller enthält. Eine Speicherschnittstelle kann über einen Speichercontroller 1265 für Zugriff auf SDRAM- oder SRAM-Speichervorrichtungen bereitgestellt werden. Einige integrierte Schaltungen enthalten zusätzlich eine integrierte Sicherheits-Engine 1270.
13A-13B sind Blockdiagramme, die beispielhafte Grafikprozessoren für den Einsatz innerhalb eines SoC gemäß den hierin beschriebenen Ausführungsformen darstellen. 13A stellt einen beispielhaften Grafikprozessor 1310 einer integrierten Ein-Chip-System-Schaltung dar, der gemäß einer Ausführungsform unter Verwendung von ein oder mehreren IP-Cores gefertigt werden kann. 13B stellt einen zusätzlichen beispielhaften Grafikprozessor 1340 einer integrierten Ein-Chip-System-Schaltung dar, der gemäß einer Ausführungsform unter Verwendung von ein oder mehreren IP-Cores gefertigt werden kann. Der Grafikprozessor 1310 von 13A ist ein Beispiel eines energiesparenden 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 Vertex-Prozessor 1305 und einen oder mehrere Fragment-Prozessor(en) 1315A-1315N (z. B. 1315A, 1315B, 1315C, 1315D bis 1315N-1 und 1315N). Der Grafikprozessor 1310 kann unterschiedliche Shaderprogramme über eine getrennte Logik ausführen, so dass der Vertex-Prozessor 1305 optimiert wird, um Operationen für Vertex-Shaderprogramme auszuführen, während der eine oder die mehreren Fragment-Prozessor(en) 1315A-1315N Fragment- (z. B. Pixel)-Shading-Operationen für Fragment- oder Pixel-Shaderprogramme ausführen. Der Vertex-Prozessor 1305 führt die Vertex-Verarbeitungsstufe der 3D-Grafik-Pipeline durch und erzeugt Grundkörper und Vertexdaten. Der (Die) Fragment-Prozessor(en) 1315A-1315N verwendet (verwenden) die von dem Vertex-Prozessor 1305 erzeugten Grundkörper und Vertexdaten, um einen Framebuffer zu produzieren, der auf einer Anzeigevorrichtung angezeigt wird. In einer Ausführungsform wird der (werden die) Fragment-Prozessor(en) 1315A-1315N optimiert, um Fragment-Shaderprogramme gemäß der OpenGL-API auszuführen, die verwendet werden können, um ähnliche Operationen wie ein Pixel-Shaderprogramm gemäß der Direct 3D-API durchzuführen.
Der Grafikprozessor 1310 enthält zusätzlich ein oder mehrere Speicherverwaltungseinheiten (MMUs) 1320A-1320B, Caches 1325A-1325B und Schaltungs-Interconnects 1330A-1330B. Die eine oder mehreren MMU(s) 1320A-1320B sorgen für virtuelle auf physische Adresszuordnung für den Grafikprozessor 1310, einschließlich für den Vertex-Prozessor 1305 und/oder den (die) Fragment-Prozessor(en) 1315A-1315N, die im Speicher abgelegte Vertex- oder Bild-/Texturdaten referenzieren können, zusätzlich zu in den ein oder mehreren Caches 1325A-1325B gespeicherten Vertex- oder Bild-/Texturdaten. In einer Ausführungsform kann (können) die eine oder mehreren MMU(s) 1320A-1320B mit anderen MMUs innerhalb des Systems synchronisiert werden, einschließlich den ein oder mehreren MMUs, die mit dem einen oder mehreren Anwendungsprozessor(en) 1205, dem Bildprozessor 1215 und/oder dem Videoprozessor 1220 von 12, verbunden sind, so dass jeder Prozessor 1205-1220 an einem gemeinsamen oder vereinheitlichten virtuellen Speichersystem teilhaben kann. Der (Die) eine oder mehreren Schaltungs-Interconnect(s) 1330A-1330B ermöglicht (ermöglichen) es dem Grafikprozessor 1310, Schnittstellen mit anderen IP-Cores innerhalb des SoC, entweder über einen internen Bus des SoC oder über eine Direktverbindung gemäß den Ausführungsformen, zu bilden.
Wie in 13B gezeigt, enthält der Grafikprozessor 1340 die eine oder mehreren MMU(s) 1320A-1320B, Caches 1325A-1325B und Schaltungs-Interconnects 1330A-1330B des Grafikprozessors 1310 von 13A. Der Grafikprozessor 1340 enthält ein oder mehrere Shaderkerne 1355A-1355N (z. B. 1455A, 1355B, 1355C, 1355D, 1355E, 1355F bis 1355N-1 und 1355N), wodurch eine vereinheitlichte Shaderkern-Architektur gebildet wird, in der ein einzelner Core oder Typ oder Core alle Arten von programmierbarem Shadercode, einschließlich Shader-Programmcode, ausführen kann, um Vertex-Shader, Fragment-Shader und/oder Compute-Shader zu implementieren. Die genaue Anzahl von vorhandenen Shaderkernen kann je nach Ausführungsformen und Implementierungen variieren. Außerdem enthält der Grafikprozessor 1340 einen Inter-Core-Taskmanager 1345, der als Thread-Dispatcher agiert, um Ausführungsthreads zu ein oder mehreren Shaderkernen 1355A-1355N und einer Kachelungseinheit 1358 zu versenden, um Kachelungsoperationen für kachelbasiertes Rendering zu beschleunigen, wobei Rendering-Operationen für eine Szene in Bildraum unterteilt werden, um beispielsweise lokale räumliche Kohärenz innerhalb einer Szene auszunutzen, oder um den Gebrauch von internen Caches zu optimieren.
14A-14B stellen eine zusätzliche beispielhafte Grafikprozessorlogik gemäß den hierin beschriebenen Ausführungsformen dar. 14A stellt einen Grafikkern 1400 dar, der in dem Grafikprozessor 1210 von 12 enthalten sein kann, und der ein vereinheitlichter Shaderkern 1355A-1355N sein kann, wie in 13B gezeigt. 14B stellt eine zusätzliche äußerst parallele Allzweck-Grafikverarbeitungseinheit 1430 dar, die eine für den Einsatz auf einem Multi-Chip-Modul geeignete äußerst parallele Allzweck-Grafikverarbeitungseinheit ist.
Wie in 14A gezeigt, enthält der Grafikkern 1400 einen gemeinsamen Befehlscache 1402, eine Textureinheit 1418 und einen Cache-/Freigabespeicher 1420, die den Ausführungsressourcen innerhalb des Grafikkerns 1400 gemeinsam sind. Der Grafikkern 1400 kann mehrere Scheiben 1401A-1401N oder Partitionen für jeden Kern enthalten, und ein Grafikprozessor kann mehrere Instanzen des Grafikkerns 1400 enthalten. Die Scheiben 1401A-1401N können Supportlogik enthalten, die einen lokalen Befehlscache 1404A-1404N, einen Thread-Scheduler 1406A-1406N, einen Thread-Dispatcher 1408A-1408N und einen Satz von Registern 1410A-1440N einschließt.
Um Logikoperationen durchzuführen, können die Scheiben 1401A-1401N einen Satz von Zusatzfunktionseinheiten (AFUs 1412A-1412N), Gleitkommaeinheiten (FPU 1414A-1414N), Ganzzahl-Arithmetik-Logik-Einheiten (ALUs 1416-1416N), Adressberechnungseinheiten (ACU 1413A-1413N), Doppelpräzisions-Gleitkommaeinheiten (DPFPU 1415A-1415N) und Matrix-Verarbeitungseinheiten (MPU 1417A-1417N) enthalten.
Einige der Berechnungseinheiten arbeiten mit einer spezifischen Präzision. Beispielsweise können die FPUs 1414A-1414N Single-Precision (32-Bit) und Half-Precision (16-Bit)-Gleitkommaoperationen durchführen, während die DPFPUs 1415A-1415N Double-Precision (64-Bit)-Gleitkommaoperationen durchführen können. Die ALUs 1416A-1416N können Ganzzahloperationen mit variabler Präzision mit einer Präzision von 8-Bit, 16-Bit und 32-Bit durchführen und können für Operationen mit gemischter Präzision konfiguriert werden. Die MPUs 1417A-1417N können ebenfalls für Matrixoperationen mit gemischter Präzision, einschließlich Half-Precision-Gleitkomma- und 8-Bit-Ganzzahloperationen, konfiguriert werden. Die MPUs 1417-1417N können eine Vielfalt von Matrixoperationen durchführen, um Maschinenlernanwendungs-Frameworks zu beschleunigen und Unterstützung für beschleunigte allgemeine Matrix-Matrix-Multiplikation (GEMM) zu ermöglichen. Die AFUs 1412A-1412N können zusätzliche Logikoperationen durchführen, die nicht von den Gleitkomma- oder Ganzzahleinheiten unterstützt werden, u. a. trigonometrische Operationen (z. B. Sinus, Kosinus usw.).
Wie in 14B gezeigt, kann eine Allzweck-Verarbeitungseinheit (GPGPU) 1430 dazu ausgebildet sein, äußerst parallele Berechnungsoperationen zu ermöglichen, die von einem Array von Grafikprozessoren durchzuführen sind. Außerdem kann die GPGPU 1430 direkt mit anderen Instanzen der GPGPU verbunden werden, um einen Multi-GPU-Cluster zu erzeugen, der die Trainingsgeschwindigkeit für besonders tiefe neuronale Netzwerke verbessert. Die GPGPU 1430 enthält eine Hostschnittstelle 1432, um eine Verbindung mit einem Hostprozessor zu ermöglichen. In einer Ausführungsform ist die Hostschnittstelle 1432 eine PCI Express-Schnittstelle. Die Hostschnittstelle kann jedoch auch eine herstellerspezifische Kommunikationsschnittstelle oder ein Kommunikationsnetzwerk sein. Die GPGPU 1430 empfängt Befehle von dem Hostprozessor und verwendet einen globalen Scheduler 1434, um mit diesen Befehlen verbundene Ausführungsthreads zu einem Satz von Berechnungsclustern 1436A-1436H zu verteilen. Die Berechnungscluster 1436A-1436H teilen sich einen Cache-Speicher 1438. Der Cache-Speicher 1438 kann als ein übergeordneter Cache für Cache-Speicher innerhalb der Berechnungscluster 1436A-1436H dienen.
Die GPGPU 1430 enthält Speicher 14434A-14434B, der mit den Berechnungsclustern 1436A-1436H über einen Satz von Speichercontrollern 1442A-1442B gekoppelt ist. In verschiedenen Ausführungsformen kann der Speicher 1434A-1434B verschiedene Arten von Speichervorrichtungen enthalten, darunter auch dynamischen Direktzugriffsspeicher (DRAM) oder Grafik-Direktzugriffsspeicher, wie z. B. synchroner Grafik-Direktzugriffsspeicher (SGRAM), einschließlich Grafik-Doppeldatenraten-(GDDR)-Speicher.
In einer Ausführungsform enthalten die Berechnungscluster 1436A-1436H jeweils einen Satz von Grafikkernen, wie z. B. den Grafikkern 1400 von 14A, der mehrere Arten von Ganzzahl- und Gleitkomma-Logikeinheiten enthalten kann, die Berechnungsoperationen mit einer Reihe von Präzisionen durchführen können, die auch für Maschinenlernberechnungen geeignet sind. Beispielsweise und in einer Ausführungsform kann zumindest ein Teilsatz der Gleitkommaeinheiten in jedem der Berechnungscluster 1436A-1436H dazu ausgebildet sein, 16-Bit- oder 32-Bit-Gleitkommaoperationen durchzuführen, während ein anderer Teilsatz der Gleitkommaeinheiten dazu ausgebildet sein kann, 64-Bit-Gleitkommaoperationen durchzuführen.
Mehrere Instanzen der GPGPU 1430 können dazu ausgebildet sein, als ein Berechnungscluster zu arbeiten. Der von dem Berechnungscluster für Synchronisierung und Datenaustausch verwendete Kommunikationsmechanismus variiert je nach Ausführungsform. In einer Ausführungsform kommunizieren die mehreren Instanzen der GPGPU 1430 über die Hostschnittstelle 1432. In einer Ausführungsform enthält die GPGPU 1430 einen E/A-Hub 1439, der die GPGPU 1430 mit einer GPU-Verbindung 1440 koppelt, die eine Direktverbindung mit anderen Instanzen der GPGPU ermöglicht. In einer Ausführungsform ist die GPU-Verbindung 1440 mit einer dedizierten GPU-GPU-Brücke gekoppelt, die Kommunikation und Synchronisierung zwischen mehreren Instanzen der GPGPU 1430 ermöglicht. In einer Ausführungsform ist die GPU-Verbindung 1440 mit einem Hochgeschwindigkeits-Interconnect gekoppelt, um Daten von und zu anderen GPGPUs oder parallelen Prozessoren zu empfangen und zu senden. In einer Ausführungsform befinden sich die mehreren Instanzen der GPGPU 1430 in getrennten Datenverarbeitungssystemen und kommunizieren über eine Netzwerkvorrichtung, die über die Hostschnittstelle 1432 zugänglich ist. In einer Ausführungsform kann die GPU-Verbindung 1440 dazu ausgebildet sein, eine Verbindung zu einem Hostprozessor zusätzlich zu oder als Alternative der Hostschnittstelle 1432 zu ermöglichen.
Während die dargestellte Konfiguration der GPGPU 1430 dazu ausgebildet sein kann, neuronale Netzwerke zu trainieren, stellt eine Ausführungsform eine alternative Konfiguration der GPGPU 1430 bereit, die zum Einsatz innerhalb einer Inferenzplattform von hoher Leistung oder geringer Energie konfiguriert werden kann. In einer Inferenzkonfiguration enthält die GPGPU 1430 weniger der Berechnungscluster 1436A-1436H relativ zu der Trainingskonfiguration. Außerdem kann die mit dem Speicher 1434A-1434B verbundene Speichertechnologie zwischen den Inferenz- und Trainingskonfigurationen abweichen, wobei Speichertechnologien mit höherer Bandbreite den Trainingskonfigurationen gewidmet sind. In einer Ausführungsform kann die Inferenzkonfiguration der GPGPU 1430 Inferenz-spezifische Befehle unterstützen. Beispielsweise kann eine Inferenzkonfiguration Unterstützung für ein oder mehrere 8-Bit-Ganzzahl-Skalarproduktbefehle bereitstellen, die allgemein während Inferenzoperationen für eingesetzte neuronale Netzwerke verwendet werden.
MULTIFREQUENZ-VERTEX-SHADER-VORRICHTUNG UND VERFAHREN
Eine Ausführungsform der Erfindung implementiert Vertex-Shading-Operationen bei unterschiedlichen Frequenzen. Vertex-Elemente, die für jede Instanz eindeutig sind, werden für jede Instanz durch ein getrenntes Shader-Programm schattiert, für jede Vertex-ID eindeutige Daten (im Falle von Ansichtsinstanziierung) werden für jede Ansicht einmal schattiert, und der Rest der Daten wird einmal pro Vertex pro Grundkörper schattiert. Die nachschattierten Vertexdaten werden in lokaler Speicherung gespeichert. Vor der Rasterisierung werden Daten pro Vertex, pro Instanz und/oder pro Ansicht zusammengesetzt, um einen vollständigen Vertex zu bilden.
Die Ausführungsformen der Erfindung gestatten die Durchführung der Vertex-Verarbeitung bei unterschiedlichen Frequenzen basierend auf der Frequenz, mit der die Attribute dem Vertex-Shader bereitgestellt werden. Insbesondere eine Ausführungsform verarbeitet Vertexdaten unter Verwendung einer Instanz-ID, einer Vertex-ID und möglicherweise einer Ansichts-ID für Multi-View-Rendering in einem Durchgang.
15 stellt eine Grafikverarbeitungseinheit 1520 dar, auf der Ausführungsformen der Erfindung eingesetzt werden können. Die GPU 1520 weist eine Grafikverarbeitungs-Engine 1510 zum Implementieren einer Grafikverarbeitungs-Pipeline sowie einen Scheduler 1560 zum Planen der Ausführung von verschiedenen Shadern auf einem Satz von Ausführungseinheiten 1550-1555 auf, die mit SIMD-Funktionseinheiten (Single Instruction, Multiple Data) und Vektorregistern zum Speichern von gepackten SIMD-Datenelementen ausgestattet sind. Ein Speicher-Teilsystem 1520 koppelt die Grafikverarbeitungs-Engine 1510 und die Ausführungseinheiten 1550-1555 mit einem Systemspeicher 1530 und kann einen lokalen Speicher und/oder Caches 1525 aufweisen.
Innerhalb der Grafikverarbeitungs-Engine verarbeitet ein Befehlsstreamer 1500 einen Befehlspuffer, der durch eine CPU im Speicher 1520 eingerichtet werden kann. Ein Input-Assembler 1501 setzt die Vertexdaten zu einer Vielzahl von unterschiedlichen Vertex-Caches zusammen, die einen Instanz-ID-Vertex-Cache 1502A, einen Vertex-ID-Vertex-Cache 1502B und einen Ansichts-ID-Vertex-Cache 1502C (nachstehend ausführlicher beschrieben) aufweisen. Der Input-Assembler (IA) 2001 liest Grundkörperdaten (z. B. Vertices, Linien und/oder Dreiecke) aus dem Speicher-Teilsystem 1520 aus und setzt die Daten zu Grundkörpern zusammen. In einer Ausführungsform werden die Grundkörper durch Multifrequenz-Vertex-Shader (MFVSs) 1502 verarbeitet, die Shading-Operationen unter Verwendung der hierin beschriebenen Multifrequenz-Techniken an jedem Vertex durchführen (z. B. Umwandeln der 3D-Position jedes Vertex im virtuellen Raum in die 2D-Koordinate, an welcher er auf dem Bildschirm erscheint). In einer Ausführungsform weisen die MFVSs einen Instanz-ID-Rate-Shader zum Verarbeiten von Vertexdaten von dem Instanz-ID-Vertex-Cache 1502A, einen Vertex-ID-Rate-Shader zum Verarbeiten von Vertexdaten von dem Vertex-ID-Vertex-Cache 1502B, und einen Ansichts-ID-Rate-Shader zum Verarbeiten von Vertexdaten von dem Ansichts-ID-Vertex-Cache 1502C auf. Die Grundkörperdaten werden durch einen Rasterer 1504 rasterisiert, und Pixel-Shading-Operationen werden durch einen Pixel-Shader 1505 an den resultierenden Pixeln durchgeführt. Die schattierten Pixel werden Bild für Bild innerhalb eines Bildspeichers 1506 gespeichert, bevor sie auf ein oder mehreren Displays 1507 angezeigt werden.
Das Folgende ist ein beispielhafter Anwendungsfall, der von den Ausführungsformen der Erfindung profitiert. DirectX High Level Shading Language (HLSL)-Code wird verwendet, um den Vertex-Shader zum Rendern eines GPU-erzeugten Partikelsystems zu implementieren. Relevante Teile des Shaderkerns sind in den 18A-H dargestellt. Dieser Shader wird mit einem API-Ruf aufgerufen: $\begin{array}{l} pDx11Context - > DrawInstanced (4, / * Vertices pro Partikel zum Zeichnen von quadbasiertem \\ Partikel* / ParticleCnt, / * z .B . große Anzahl 0,0) \end{array}$
Beginnend mit den 18A-B, hat der beispielhafte Shadercode die folgenden Eigenschaften:

1. „output.Albedo_Opacity“ ist der teuerste Teil des Shaders. Die produzierten Daten sind nur von der Instanz-ID abhängig.
2. „output.Position“ ist ansichtsabhängig.
3. „output.TexCoord“ ist nur von vertexID abhängig, und die Ausführung von VertexFrequenz wird vorausgesetzt.

Eine Ausführungsform der Erfindung führt diesen Shadercode in 3 Phasen aus. Die Ergebnisse jeder Phase werden in einem Zwischenspeicher oder einem Vertex-Cache gespeichert.
Die Komponenten, die ausschließlich von einer Instanz-ID abhängen, werden getrennt ausgeführt und in einem intermediären Instanzdaten-Cache gespeichert, wie in 18C angegeben. Diese Caches können innerhalb des Speicher-Teilsystems 1520 oder als getrennte Caching-Strukturen innerhalb der Ausführungseinheiten 1550-1555 implementiert werden. Ebenso werden Daten, die bei Vertexfrequenz berechnet werden können, getrennt ausgeführt und in einem Vertexdaten-Cache gespeichert, wie in 18D dargestellt.
Schließlich kann Code, der von der Ansichts-ID abhängt, innerhalb seines eigenen Caches ausgeführt und gespeichert werden, wie in 18E dargestellt.
Bei dieser Ausführungsform werden die Vertexdaten vor der Rasterisierung gesammelt. Der Input-Assembler 1501 der Pipeline führt Funktionalität aus, die in dem in 18F gezeigten Pseudo-Code demonstriert wird.
Die Semantik zum Verarbeiten in drei Phasen, wie hierin beschrieben, kann in einer ShaderSprache, wie z. B. HLSL, implementiert werden, wie in 18G gezeigt.
Die zusätzliche Annotation „SV“, die den Funktionsaufrufen folgt (z. B. „SV_InstanceRate“), kann als Leitlinie für die Hardware verwendet werden, in welcher Frequenz der Shadercode ausgeführt und gespeichert werden sollte. Hardware-Unterstützung zum Aufspalten von Code in getrennte Stufen ermöglicht es dem Code, in unterschiedlichen Kernen bei unterschiedlichen Frequenzen ausgeführt zu werden. Der Input-Assembler 1501 führt die richtigen Vertexdaten vor der Rasterisierung zusammen. Falls die Hardware in einer Ausführungsform eine solche Funktionalität nicht unterstützt, könnte die Hardware darauf zurückfallen, einen Shaderkern zu erzeugen, der alle Phasen in einem Shader zusammenführt und seriell ausführt.
Ein alternatives Schema zum Leiten des Grafiktreiber/Shader-Compilers auf Vertexfrequenz besteht darin, die Ausgabeattribute zu annotieren, wie in 18H gezeigt.
Alternativ dazu kann der IHV-Shader-Compiler in dem Softwarestapel Code, basierend auf dem Gebrauch von SV _ViewID, SV_VertexID und SV_InstanceID, auf intelligente Weise isolieren und in getrennte Kerne aufteilen. Nachdem die aufgeteilten Shaderkerne erzeugt worden sind, kann die Hardware die Ausführungsformen der Erfindung nutzen, ohne von Änderungen an der Grafik-API abhängig zu sein.
Grundkörpermontage kann auf mindestens zwei Weisen implementiert werden:
Erzeugen von Vertexattributen nach Bedarf.
Hier kann der Input-Assembler 1501 Vertexattribute in dem damit verknüpften Vertex-Cache nachschlagen. Falls ein Cache-Fehltreffer auftritt, wird der verknüpfte Kern aufgerufen, um diese Vertexattribute zu produzieren. Sobald die Daten bereit sind, wird der Vertex zusammengesetzt. Nachdem alle Vertices in dem Grundkörper zusammengesetzt sind, wird der Grundkörper zur Rasterisierung durch die Pipeline geleitet.
Um die Vorbereitung der verschiedenen Vertex-Caches zu unterstützen, ruft eine Ausführungsform der Hardware eine Version des seriellen Vertex-Shaders auf (z. B. MultiPhasePartcleVS). Durch vollständiges Ausführen der ersten „N“ Instanzen in einem Durchgang sind die Instanz- und Vertexdaten in den verschiedenen Caches verfügbar, damit der Rest der Multi-Frequenz-Shader-Ausführung und Grundkörpermontage dies ausnutzen kann. Der Treiber oder die Hardware kann den geeigneten Wert für „N“ abstimmen und auswählen.
Vorbelegen von Instanzraten- und/oder Vertex-Ratendaten.
In einer Ausführungsform führt ein getrennter Befehlslisten-Vorprozessor die folgenden Operationen durch:

(i) Der Befehlslisten-Vorprozessor geht voraus, um ausschließlich Instanzdaten zu füllen und den Instanz-Vertex-Cache für Ziehungen zu füllen, die von Vertex-Ratendaten und/oder Ansichts-ID-Ratendaten abhängen.
(ii) Vorausgehen und Vertex-Ratendaten für Ziehungen füllen, die von der Ansichts-ID abhängen. Beide davon könnten potenzielle Rasterisierungsstopps beim Zusammensetzen von Vertexdaten entschärfen.
(iii) „Stream out“-Daten zum Vorbelegen von Vertex-Cachedaten verwenden. Siehe den nachstehenden Abschnitt „Stream Out“.

16 stellt ein Beispiel eines Verfahrens dar, das auf der aktuellen Hardware implementiert wird. Bei 1601 werden Instanz-IDs und Vertex-IDs für alle Vertices in dem Grundkörper gesammelt. Falls nicht alle schattierten Vertices in dem Vertex-Cache vorhanden sind, wie bei 1602 bestimmt, dann werden für alle Vertices, die bei 1605 nicht in dem Cache enthalten sind, die Vertexdaten bei 1606 abgerufen. Bei 1607 werden die abgerufenen Vertexdaten und Thread-ID-Daten zu dem Thread-Scheduler gesendet, und der Vertex-Shader wird bei 1608 ausgeführt. Die schattierten Vertexdaten werden bei 1609 in dem Cache gespeichert. Der Grundkörper wird bei 1603 zusammengesetzt, und der Grundkörper wird bei 1604 zum Rasterer gesendet.
17 stellt ein Verfahren im Einklang mit einer Ausführungsform der Erfindung dar. Bei 1701 werden Instanz-IDs und Vertex-IDs für alle Vertices in dem Grundkörper gesammelt. Falls nicht alle Vertex-Instanz-ID-Attribute mit schattierten Vertices in dem Vertex-Cache vorhanden sind, wie bei 1702 bestimmt, dann werden bei 1716 für jeden Instanz-ID-Vertex, der bei 1716 nicht in dem Cache enthalten ist, die Vertexdaten bei 1717 abgerufen. Bei 1718 werden die Vertex-Abrufdaten und die Thread-ID-Daten zu dem Thread-Scheduler gesendet. Bei 1719 wird der Vertex-Instanzraten-Shader-Thread ausgeführt, und bei 1720 werden die schattierten Vertex-Instanzdaten in dem Cache gespeichert.
Falls nicht alle schattierten Vertices mit Vertex-ID-Attributen in dem Vertex-Cache gespeichert sind, wie bei 1703 bestimmt, dann werden für alle Vertexattribute, die bei 1711 nicht in dem Cache enthalten sind, die Vertexdaten bei 1712 abgerufen. Bei 1713 werden die Vertex-Abrufdaten und Thread-ID-Daten zu dem Thread-Scheduler gesendet, und der Vertex-Shader-Thread wird bei 1714 ausgeführt. Die schattierten Vertexdaten werden bei 1715 in dem Cache gespeichert.
Falls nicht alle Vertex-Ansichtsattribute mit schattierten Vertices in dem Vertex-Cache gespeichert sind, wie bei 1704 bestimmt, dann werden für alle Vertexattribut-Ansichts-ID-Daten, die bei 1707 nicht in dem Cache enthalten sind, die Vertexdaten bei 1708 abgerufen. Bei 1709 werden die Vertex-Abrufdaten und die Thread-ID-Daten zu dem Thread-Scheduler gesendet, und bei 1710 wird der Vertex-Ansichts-ID-Ratenshader ausgeführt. Bei 1711 werden die schattierten Ansichts-ID-Vertexdaten in dem Cache gespeichert.
19 stellt zusätzliche Details einer Ausführungsform der Erfindung dar. Insbesondere stellt 19 ein oder mehrere CPUs 1900 dar, die einen Grafikgerätetreiber 1901 ausführen, der einen Shader-Compiler 1902 aufweist, um einen Vertex-Shader zu erzeugen und in unterschiedliche Phasen aufzuteilen, wie hierin beschrieben. Ein Speicher 1930 speichert den (die) Vertex-Shader 1925, Eingabe-Oberflächen 1923 und Ausgabe-Oberflächen 1923. Die CPUs 1900 und der Speicher 1930 sind mit ein oder mehreren Grafikprozessoren 1910 gekoppelt, welche die Grafikverarbeitungs-Pipeline implementieren.
In Reaktion auf einen Ziehungsaufruf 1903 erstellt der Benutzermodustreiber 1905 den Befehlspuffer, der durch einen Befehlsstreamer 1911 der GPUs verarbeitet wird. Ein Input-Assembler 1912 montiert die Vertexdaten zu einem Instanz-ID-Vertex-Cache 1913, einem Vertex-ID-Vertex-Cache 1914 und einem Ansichts-ID-Vertex-Cache 1915. Ein Instanz-ID-Ratenshader 1918 führt Vertex-Shading-Operationen an Vertexdaten von dem Instanz-ID-Vertex-Cache 1913 durch, ein Vertex-ID-Ratenshader 1919 führt Vertex-Shading-Operationen an Vertexdaten von dem Vertex-ID-Vertex-Cache 1914 durch, und ein Ansichts-ID-Ratenshader 1920 führt Vertex-Operationen an Vertexdaten von dem Ansichts-ID-Vertex-Cache 1915 durch. Eine Vertex-Abrufeinheit 1916 ruft zusätzliche Vertexdaten ab, die von den Shadern 1918-1920 benötigt werden. Die Vertex-Shader-Ergebnisse werden durch den Rasterer 1917 rasterisiert, der Pixel erzeugt, die wiederum durch einen Pixel-Shader 1921 schattiert werden. Ein Satz von Ausführungseinheiten und Zwischenspeicher 1922 werden verwendet, um die Vertex-Shader 1918-1920 und den Pixel-Shader 1921 auszuführen.
Die Verarbeitung von Vertexattributen kann mit der Nutzung von Tessellations- und Geometrie-Shader-Pipelinestufen abgeändert werden. Wenn Applikationen Tessellations- oder Geometrie-Shader-Stufen verwenden, werden Applikationen in den meisten Fällen gezwungen, Hull-, Domänen- und Geometrie-Shader zu schreiben, um alle Vertexattribute durch alle Shader zu verbreiten, die zu dem Rasterer 1917 gesendet werden müssen. Die Ausführungsformen der Erfindung können erweitert werden, um Vertexattribute, die sich nicht ändern, zwischen den Vertex-Shadern 1918-1920 und dem Pixel-Shader 1921 zu isolieren.
Der Shader-Compiler 1902 kann mit Hilfe von Verbindungszeitoptimierungen die redundanten Speicherbewegungen und Speicherung zwischen Shaderstufen vermeiden. Die endgültigen Vertexattributdaten können vor der Rasterisierung aus dem korrekten Vertexattribut-Cache gezogen werden.
Die Ausführungsformen der Erfindung können auch das Vertex-Shading auf unterschiedlichen Stufen implementieren, um die Ausgabe einer Shaderstufe als Eingabe in eine andere Vertex-Shaderstufe in der Multifrequenz-Vertex-Pipeline zu akzeptieren. Wie in 20 dargestellt, können zum Beispiel die durch den Instanzraten-Vertex-Shader 1918 erzeugten Instanzratendaten 2018 zur weiteren Verarbeitung in den Vertex-ID-Raten-Vertex-Shader 1919 eingespeist werden. Dies kann geschehen, wenn der Vertex-ID-Ratenshader 1919 Berechnungen an nach der Instanzrate schattierten Vertexdaten 2018 durchführen muss.
Ebenso können die durch den Vertex-ID-Ratenshader 1919 erzeugten Vertex-Ratendaten 2019 in den Ansichtsraten-ID-Shader 1920 eingespeist werden, der die Vertex-Ratendaten 2019 potenziell mit den Instanzratendaten 2018 verarbeiten kann, um Ansichtsratendaten 2020 zu erzeugen. In dieser Hierarchie werden nachschattierte Instanzratendaten durch den Vertex-ID-Ratenshader oder den Ansichts-ID-Ratenshader referenziert. Ebenso können die Vertex-ID-Ratendaten durch den Ansichts-ID-Ratenshader referenziert werden. Dies macht die Ausführung der Vertex-ID- oder Ansichts-ID-Ratenshader abhängig von den Eingabedaten, was bedeutet, dass die Eingabedaten durch die entsprechende Shaderstufe schattiert werden müssen, bevor die Ausführung der Ansichts-ID-Rate oder Vertex-ID-Rate beginnen kann.
Der in 21 dargestellte Pseudo-Code implementiert eine Vertexmontage, wobei die Instanzdaten für den Vertexratenshader und den Ansichtsratenshader verwendet werden.
„Stream out“-Funktionalität funktioniert auch mit den Ausführungsformen der Erfindung, in der schattierte Vertexdaten gespeichert werden. Um „Stream out“ korrekt zu benutzen, muss die Schnittstelle ausdrücklich das Ausschreiben von Vertexdaten zu getrennten Puffern pro Vertex-Shaderrate unterstützen. Beispielsweise wird ein Puffer für Instanzratendaten, ein Puffer für Vertex-ID-Ratendaten und ein Puffer für den Ansichts-ID-Ratenshader verwendet. Diese Puffer können wieder gebunden und wieder benutzt werden, um die Vertexdaten optimal zu montieren. Dies erfordert eine neue explizite Grafik-API.
Die Vertex-Caches müssen eventuell Daten räumen, wenn der Cache voll ist und neue Daten gespeichert werden müssen. Der Treiber kann geräumte Vertexdaten optional in den „Stream Out“-Speicher schreiben. Anstatt die Vertexdaten neu zu schattieren, wenn die Daten als verfügbar markiert sind, können sie aus dem „Stream Out“-Speicher in den Cache zurückgezogen werden. In einer Ausführungsform ist der Gerätetreiber für das Einrichten und Verwalten der Stream-Out-Speicherung unter der Haube verantwortlich.
Ausführungsformen der Erfindung können verschiedene Schritte enthalten, die oben beschrieben worden sind. Die Schritte können in maschinenausführbaren Anweisungen integriert sein, die verwendet werden können, um einen Allzweckprozessor oder einen Sonderzweckprozessor zu veranlassen, die Schritte auszuführen. Alternativ dazu können diese Schritte durch spezifische Hardwarekomponenten, die festverdrahtete Logik zum Durchführen der Schritte enthalten, oder durch eine beliebige Kombination von programmierten Computerkomponenten und angepassten Hardwarekomponenten durchgeführt werden.
Wie hierin beschrieben, können Anweisungen sich auf spezifische Konfigurationen von Hardware beziehen, wie z. B. anwendungsspezifische integrierte Schaltungen (ASICs), die dazu ausgelegt sind, bestimmte Operationen durchzuführen, oder die eine vorbestimmte Funktionalität oder Softwareanweisungen haben, die in einem Speicher gespeichert sind, der in einem nichtflüchtigen computerlesbaren Medium integriert ist. Somit können die in den Figuren gezeigten Techniken unter Verwendung von Code und Daten implementiert werden, die auf einem oder mehreren elektronischen Geräten (z. B. einer Endstation, einem Netzwerkelement usw.) gespeichert und ausgeführt werden. Solche elektronischen Geräte speichern und übermitteln (intern und/oder mit anderen elektronischen Geräten über ein Netzwerk) Code und Daten unter Verwendung von computer-maschinenlesbaren Medien, wie z. B. nichtflüchtigen computer-maschinenlesbaren Speichermedien (z. B. magnetische Disks; optische Discs; Direktzugriffsspeicher; Nur-Lese-Speicher; Flash-Speichervorrichtungen; Phasenwechselspeicher) und flüchtigen computer-maschinenlesbaren Kommunikationsmedien (z. B. elektrische, optische, akustische oder andere Formen von ausgebreiteten Signalen - wie etwa Trägerwellen, Infrarotsignale, Digitalsignale usw.).
Außerdem weisen solche elektronischen Geräte in der Regel einen Satz von ein oder mehreren Prozessoren auf, die mit ein oder mehreren anderen Komponenten, wie z. B. ein oder mehreren Speichergeräten (nichtflüchtigen maschinenlesbaren Speichermedien), Benutzer-Eingabe/Ausgabe-Geräten (z. B. einer Tastatur, einem Touchscreen und/oder einem Display) gekoppelt sind, sowie Netzwerkverbindungen. Die Kopplung des Satzes von Prozessoren und anderen Komponenten erfolgt in der Regel durch ein oder mehrere Busse und Brücken (auch als Buscontroller bezeichnet). Die Speichervorrichtung und die Signale, die den Netzwerkverkehr transportieren, repräsentieren jeweils ein oder mehrere maschinenlesbare Speichermedien und maschinenlesbare Kommunikationsmedien. Somit speichert die Speichervorrichtung einer gegebenen elektronischen Vorrichtung in der Regel Code und/oder Daten zur Ausführung auf dem Satz von ein oder mehreren Prozessoren der betreffenden elektronischen Vorrichtung. Natürlich können ein oder mehrere Teile einer Ausführungsform der Erfindung unter Verwendung unterschiedlicher Kombinationen von Software, Firmware und/oder Hardware implementiert werden. Überall in dieser ausführlichen Beschreibung wurden zu Erläuterungszwecken zahlreiche spezifische Details dargelegt, um ein fundiertes Verständnis der vorliegenden Erfindung bereitzustellen. Für eine fachkundige Person ist es jedoch offensichtlich, dass die Erfindung ohne einige dieser spezifischen Details in die Praxis umgesetzt werden kann. In bestimmten Fällen wurden bekannte Strukturen und Funktionen nicht in aufwendigen Details beschrieben, um eine Verschleierung des Gegenstands der vorliegenden Erfindung zu vermeiden. Dementsprechend sollte der Umfang und Sinn der Erfindung in Bezug auf die folgenden Ansprüche beurteilt werden.

Claims

Grafikverarbeitungsvorrichtung, die Folgendes umfasst: eine Vielzahl von Vertex-Caches, um mit Grafik-Grundkörpern verbundene Vertexdaten zu speichern; und Grafikausführungsschaltungen, um Vertex-Shader auszuführen, die bei unterschiedlichen Verarbeitungsraten für unterschiedliche Sätze der Vertexdaten betriebsfähig sind, wobei jeder der unterschiedlichen Sätze von Vertexdaten einen damit verbundenen unterschiedlichen Typ von Identifikator aufweist, um die Vertexdaten zu identifizieren.
Grafikverarbeitungsvorrichtung nach Anspruch 1, wobei die Vertex-Shader unterschiedliche Vertex-Shader-Typen umfassen, die Folgende einschließen: einen ersten Vertex-Shader-Typ zum Verarbeiten von ersten Vertexdaten, die spezifisch für einen Instanzidentifikator (ID) sind; einen zweiten Vertex-Shader-Typ zum Verarbeiten von zweiten Vertexdaten, die spezifisch für eine Ansichts-ID sind, und einen dritten Vertex-Shader-Typ zum Verarbeiten von dritten Vertexdaten, die spezifisch für eine Vertex-ID sind.
Grafikverarbeitungsvorrichtung nach Anspruch 2, wobei die ersten, zweiten und dritten Vertexdaten jeweils in einem getrennten Vertex-Cache zu speichern sind.
Grafikverarbeitungsvorrichtung nach Anspruch 2 oder 3, die ferner Folgendes umfasst: einen Instanz-ID-Vertex-Cache zum Speichern der Vertexdaten, die spezifisch für eine Instanz-ID sind; einen Ansichts-ID-Vertex-Cache zum Speichern der Vertexdaten, die spezifisch für eine Ansichts-ID sind, und einen Vertex-ID-Cache zum Speichern der Vertexdaten, die spezifisch für eine Vertex-ID sind.
Grafikverarbeitungsvorrichtung nach Anspruch 4, die ferner Folgendes umfasst: einen Eingangsassembler, der veranlasst, dass die Vertexdaten aus dem Speicher und/oder dem Instanz-ID-Vertex-Cache, dem Ansichts-ID-Vertex-Cache oder dem Vertex-ID-Vertex-Cache ausgelesen werden.
Grafikverarbeitungsvorrichtung nach Anspruch 5, die ferner Folgendes umfasst: einen Befehlsstreamer zum Binden der durch die Grafikausführungsschaltungen auszuführenden Vertex-Shader, um den ID-Vertex-Cache, den Ansichts-ID-Vertex-Cache und/oder den Vertex-ID-Vertex-Cache mit ihren entsprechenden Vertexdaten zu füllen.
Grafikverarbeitungsvorrichtung nach Anspruch 2 oder 6, die ferner Folgendes umfasst: einen Rasterer, um schattierte Vertices von den ersten, zweiten und dritten Vertex-Shader-Typen zu empfangen, und um mit den schattierten Vertices verbundene Bildpixel darauf reagierend zu erzeugen; und einen Pixel-Shader, um die Bildpixel zu schattieren.
Grafikverarbeitungsvorrichtung nach Anspruch 7, die ferner Folgendes umfasst: eine Zentraleinheit (CPU) zum Ausführen eines Grafikgerätetreibers einschließlich einer ersten Treiberkomponente, um einen Befehlspuffer zu erstellen, der die ersten, zweiten und dritten Vertexdaten identifiziert.
Grafikverarbeitungsvorrichtung nach Anspruch 2 oder 8, wobei die Grafikausführungsschaltungen eine Vielzahl von Ausführungseinheiten (AEs) umfassen, und wobei unterschiedliche Instanzen der ersten, zweiten und dritten Vertex-Shader-Typen an jedem Satz von verfügbaren AEs zu planen und auszuführen sind.
Maschinenlesbares Medium, auf dem Programmcode gespeichert ist, der, wenn er von einer Maschine ausgeführt wird, die Maschine veranlasst, die folgenden Operationen durchzuführen: Speichern von Vertexdaten, die mit Grafik-Grundkörpern verbunden sind, in einer Vielzahl von Vertex-Caches; Abrufen der Vertexdaten in Reaktion auf die Ausführung von Grafikbefehlen; und die mit Grafik-Grundkörpern verbunden sind, in einer Vielzahl von Vertex-Caches; und Ausführen von Vertex-Shadern bei unterschiedlichen Verarbeitungsraten für unterschiedliche Sätze der Vertexdaten, wobei jeder der unterschiedlichen Sätze von Vertexdaten einen damit verbundenen unterschiedlichen Typ von Identifikator aufweist, um die Vertexdaten zu identifizieren.
Maschinenlesbares Medium nach Anspruch 10, wobei die Vertex-Shader unterschiedliche Vertex-Shader-Typen umfassen, die Folgende einschließen: einen ersten Vertex-Shader-Typ zum Verarbeiten von ersten Vertexdaten, die spezifisch für einen Instanzidentifikator (ID) sind; einen zweiten Vertex-Shader-Typ zum Verarbeiten von zweiten Vertexdaten, die spezifisch für eine Ansichts-ID sind, und einen dritten Vertex-Shader-Typ zum Verarbeiten von dritten Vertexdaten, die spezifisch für eine Vertex-ID sind.
Maschinenlesbares Medium nach Anspruch 11, wobei die ersten, zweiten und dritten Vertexdaten jeweils in einem getrennten Vertex-Cache zu speichern sind.
Maschinenlesbares Medium nach Anspruch 11 oder 12, das ferner Programmcode umfasst, um die Maschine zu veranlassen, die folgenden Operationen durchzuführen: Abrufen der Vertexdaten, die spezifisch für eine Instanz-ID sind, zu einem Instanz-ID-Vertex-Cache; Abrufen der Vertexdaten, die spezifisch für eine Ansichts-ID sind, zu einem Ansichts-ID-Vertex-Cache; und Abrufen der Vertexdaten, die spezifisch für eine Vertex-ID sind, zu einem Vertex-ID-Vertex-Cache.
Maschinenlesbares Medium nach Anspruch 13, wobei das Abrufen ferner Folgendes umfasst: Bestimmen, ob der Instanz-ID-Vertex-Cache mindestens einige der Vertexdaten enthält, die spezifisch für die Instanz-ID sind, und Abrufen eines Teils der Vertexdaten, die sich nicht in dem Instanz-ID-Vertex-Cache befinden, von einem Speicher-Teilsystem; Bestimmen, ob der Ansichts-ID-Vertex-Cache mindestens einige der Vertexdaten enthält, die spezifisch für die Ansichts-ID sind, und Abrufen eines Teils der Vertexdaten, die sich nicht in dem Ansichts-ID-Vertex-Cache befinden, von dem Speicher-Teilsystem; und Bestimmen, ob der Vertex-ID-Vertex-Cache mindestens einige der Vertexdaten enthält, die spezifisch für die Vertex-ID sind, und Abrufen eines Teils der Vertexdaten, die sich nicht in dem Vertex-ID-Vertex-Cache befinden, von dem Speicher-Teilsystem.
Maschinenlesbares Medium nach Anspruch 14, das ferner Programmcode umfasst, um die Maschine zu veranlassen, die folgenden Operationen durchzuführen: Auslesen von Befehlen, die zum Identifizieren der ersten, zweiten und dritten Vertexdaten nutzbar sind, aus einem Befehlspuffer; und darauf reagierend, Speichern der Vertexdaten jeweils in dem Instanz-ID-Vertex-Cache, dem Ansichts-ID-Vertex-Cache oder dem Vertex-ID-Vertex-Cache.
Maschinenlesbares Medium nach Anspruch 11, das ferner Programmcode umfasst, um die Maschine zu veranlassen, die folgenden Operationen durchzuführen: Durchführen von Rasterisierung an schattierten Vertices von den ersten, zweiten und dritten Vertex-Shader-Typen, und darauf reagierend, Erzeugen von mit den schattierten Vertices verbundenen Bildpixeln; und Schattieren der Bildpixel.
Maschinenlesbares Medium nach Anspruch 16, das ferner Programmcode umfasst, um die Maschine zu veranlassen, die folgenden Operationen durchzuführen: Ausführen eines Grafikgerätetreibers einschließlich einer ersten Treiberkomponente, um einen Befehlspuffer zu erstellen, der die ersten, zweiten und dritten Vertexdaten identifiziert.
Maschinenlesbares Medium nach Anspruch 11, wobei unterschiedliche Instanzen der ersten, zweiten und dritten Vertex-Shader-Typen an jedem Satz von verfügbaren Ausführungseinheiten (AEs) der Grafikverarbeitungsvorrichtung zu planen und auszuführen sind.
Vorrichtung, die Folgendes umfasst: Mittel zum Speichern von Vertexdaten, die mit Grafik-Grundkörpern verbunden sind, in einer Vielzahl von Vertex-Caches; Mittel zum Abrufen der Vertexdaten in Reaktion auf die Ausführung von Grafikbefehlen; und Vertex-Shader-Mittel, die unterschiedliche Vertex-Shader umfassen, die bei unterschiedlichen Verarbeitungsraten für unterschiedliche Sätze der Vertexdaten ausgeführt werden, wobei jeder der unterschiedlichen Sätze von Vertexdaten einen damit verbundenen unterschiedlichen Typ von Identifikator aufweist, um die Vertexdaten zu identifizieren.
Vorrichtung nach Anspruch 19, wobei die Vertex-Shader unterschiedliche Vertex-Shader-Typen umfassen, die Folgende einschließen: einen ersten Vertex-Shader-Typ zum Verarbeiten von ersten Vertexdaten, die spezifisch für einen Instanzidentifikator (ID) sind; einen zweiten Vertex-Shader-Typ zum Verarbeiten von zweiten Vertexdaten, die spezifisch für eine Ansichts-ID sind, und einen dritten Vertex-Shader-Typ zum Verarbeiten von dritten Vertexdaten, die spezifisch für eine Vertex-ID sind.
Vorrichtung nach Anspruch 20, wobei die ersten, zweiten und dritten Vertexdaten jeweils in einem getrennten Vertex-Cache zu speichern sind.
Vorrichtung nach Anspruch 20 oder 21, die ferner Folgendes umfasst: Mittel zum Abrufen der Vertexdaten, die spezifisch für eine Instanz-ID sind, zu einem Instanz-ID-Vertex-Cache, der Vertexdaten, die spezifisch für eine Ansichts-ID sind, zu einem Ansichts-ID-Vertex-Cache, und der Vertexdaten, die spezifisch für eine Vertex-ID sind, zu einem Vertex-ID-Vertex-Cache.
Vorrichtung nach Anspruch 22, wobei das Abrufen ferner Folgendes umfasst: Mittel zum Bestimmen, ob der Instanz-ID-Vertex-Cache mindestens einige der Vertexdaten enthält, die spezifisch für die Instanz-ID sind, und Abrufen eines Teils der Vertexdaten, die sich nicht in dem Instanz-ID-Vertex-Cache befinden, von einem Speicher-Teilsystem; Mittel zum Bestimmen, ob der Ansichts-ID-Vertex-Cache mindestens einige der Vertexdaten enthält, die spezifisch für die Ansichts-ID sind, und Abrufen eines Teils der Vertexdaten, die sich nicht in dem Ansichts-ID-Vertex-Cache befinden, von dem Speicher-Teilsystem; und Mittel zum Bestimmen, ob der Vertex-ID-Vertex-Cache mindestens einige der Vertexdaten enthält, die spezifisch für die Vertex-ID sind, und Abrufen eines Teils der Vertexdaten, die sich nicht in dem Vertex-ID-Vertex-Cache befinden, von dem Speicher-Teilsystem.
Vorrichtung nach Anspruch 23, die ferner Folgendes umfasst: Mittel zum Auslesen von Befehlen, die zum Identifizieren der ersten, zweiten und dritten Vertexdaten nutzbar sind, aus einem Befehlspuffer; und Mittel zum darauf reagierenden Speichern der Vertexdaten jeweils in dem Instanz-ID-Vertex-Cache, dem Ansichts-ID-Vertex-Cache oder dem Vertex-ID-Vertex-Cache.
Vorrichtung nach Anspruch 20, die ferner Folgendes umfasst: Mittel zum Durchführen von Rasterisierung an schattierten Vertices von den ersten, zweiten und dritten Vertex-Shader-Typen, und darauf reagierend, Erzeugen von mit den schattierten Vertices verbundenen Bildpixeln; und Mittel zum Schattieren der Bildpixel.