DE102020106002A1

DE102020106002A1 - Dynamischer lastausgleich von rechenanlagen unter unterschiedlichen rechenkontexten

Info

Publication number: DE102020106002A1
Application number: DE102020106002.5A
Authority: DE
Inventors: James Valerio; Vasanth Ranganathan; Joydeep Ray; Rahul A. Kulkarni; Abhishek R. Appu; Jeffery S. Boles; Hema C. Nalluri
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2019-03-27
Filing date: 2020-03-05
Publication date: 2020-10-01
Also published as: US20220129323A1; US11726826B2; US11074109B2; US20200310883A1; US20230359499A1

Abstract

Es werden hier Beispiele beschrieben, die verwendet werden können, um Befehle aus mehreren Quellen zur Ausführung durch ein oder mehrere Segmente einer Verarbeitungsvorrichtung zuzuweisen. Beispielsweise kann eine Verarbeitungsvorrichtung in mehrere Abschnitte segmentiert sein, und jeder Abschnitt ist zugewiesen, um Befehle aus einer speziellen Quelle zu verarbeiten. In dem Fall, in dem eine einzige Quelle Befehle bereitstellt, kann die gesamte Verarbeitungsvorrichtung (alle Segmente) zugewiesen sein, um Befehle aus der einzigen Quelle zu verarbeiten. Wenn eine zweite Quelle Befehle bereitstellt, können einige Segmente zugewiesen sein, um Befehle aus der ersten Quelle zu verarbeiten, und andere Segmente können zugewiesen sein, um Befehle aus der zweiten Quelle zu verarbeiten. Dementsprechend können Befehle aus mehreren Anwendungen durch eine Verarbeitungseinheit zur gleichen Zeit ausgeführt werden.

Description

GEBIET
Ausführungsformen beziehen sich allgemein auf das Gebiet von Grafikprozessoren und die Ausführung von Arbeitslasten.
STAND DER TECHNIK
Die digitale Bilderzeugung, -verarbeitung und -anzeige werden weithin durch Berechnungssysteme und durch Computer ausgeführte Anwendungen ausgeführt und eingesetzt. Beispielsweise erzeugen Smartphones, intelligente Häuser, Sicherheitssysteme, selbstfahrende Fahrzeuge und Computerspielanwendungen digitale Bilder oder setzen Bildverarbeitung ein. In einigen Fällen werden zweidimensionale (2D) oder dreidimensionale (3D) Bilder durch ein Computersystem erzeugt und angezeigt.
Eine Verarbeitungsvorrichtung kann programmiert sein, um Arbeitslasten aus verschiedenen Quellen zu handhaben. In einigen Fällen der Zuweisung dieser Verarbeitungsvorrichtung zum Handhaben von Arbeitslasten aus verschiedenen Quellen kann jedoch die Verarbeitungsvorrichtung nicht ausgelastet sein. Beispielsweise in einer Zeitscheibenanwendung einer Grafikverarbeitungseinheit (GPU) kann eine GPU zugewiesen sein, um Kontexte aus einer einzigen Anwendung zu einer Zeit zu verarbeiten. Falls eine zweite Anwendung anfordert, Kontexte zur Verarbeitung zu der GPU zu übermitteln, muss die zweite Anwendung darauf warten, dass Threads von der ersten Anwendung, die gerade verarbeitet werden, fertiggestellt sind, selbst wenn die GPU noch freie Kapazität zum Handhaben von Threads von der zweiten Anwendung besitzt. Der Kontext und resultierende Daten aus der Verwendung der GPU durch die erste Anwendung werden aus dem Speicher gelöscht, bevor ein Kontext aus der zweiten Anwendung die GPU verwenden kann. Mit anderen Worten, zu einer Zeit können eine einzige Anwendung und ein einziger Kontext die GPU verwenden.
Figurenliste
Ein besseres Verständnis der vorliegenden Erfindung kann aus der folgenden genauen Beschreibung erhalten werden, zusammen mit den folgenden Zeichnungen; es zeigen:

1 ein Blockdiagramm einer Ausführungsform eines Computersystems mit einem Prozessor, der einen oder mehrere Prozessorkerne und Grafikprozessoren aufweist;
2 ein Blockdiagramm einer Ausführungsform eines Prozessors, der einen oder mehrere Prozessorkerne, eine integrierte Speichersteuereinheit und einen integrierten Grafikprozessor aufweist;
3 ein Blockdiagramm einer Ausführungsform eines Grafikprozessors, der eine diskrete Grafikverarbeitungseinheit sein kann oder ein Grafikprozessor sein kann, der mit mehreren Verarbeitungskernen integriert ist;
4 ein Blockdiagramm einer Ausführungsform einer Grafikverarbeitungs-Engine für einen Grafikprozessor,
5 ein Blockdiagramm einer weiteren Ausführungsform eines Grafikprozessors;
6A und 6B Blockdiagramme einer Thread-Ausführungslogik, die eine Anordnung von Verarbeitungselementen enthält;
7 ein Grafikprozessorausführungseinheit-Anweisungsformat gemäß einer Ausführungsform;
8 ein Blockdiagramm einer weiteren Ausführungsform eines Grafikprozessors, der einen Grafik-Pipeline, eine Medien-Pipeline, eine Anzeige-Engine, Thread-Ausführungslogik und eine Render-Ausgabe-Pipeline enthält;
9A ein Blockdiagramm, das ein Grafikprozessor-Befehlsformat gemäß einer Ausführungsform darstellt;
9B ein Blockdiagramm, das eine Grafikprozessor-Befehlsfolge gemäß einer Ausführungsform darstellt;
10 eine beispielhafte Grafik-Software-Architektur für ein Datenverarbeitungssystem gemäß einer Ausführungsform;
11A und 11B beispielhafte IP-Kernentwicklungssysteme, die zum Herstellen einer integrierten Schaltung zum Ausführung von Operation gemäß einer Ausführungsform verwendet werden können.
12 eine beispielhafte integrierte Schaltung eines Einchipsystems, die unter Verwendung eines oder mehrerer IP-Kerne produziert werden kann, gemäß einer Ausführungsform;
13A und 13B einen beispielhaften Grafikprozessor einer integrierten Schaltung eines Einchipsystems, der unter Verwendung eines oder mehrerer IP-Kerne produziert werden kann;
14A und 14B einen zusätzlichen beispielhaften Grafikprozessor einer integrierten Schaltung eines Einchipsystems, der unter Verwendung eines oder mehrerer IP-Kerne produziert werden kann;
15 eine Beispielumgebung;
16 einen Beispielprozess;
17A ein beispielhaftes Grafikverarbeitungseinheitssystem;
17B ein beispielhaftes globales Rechen-Frontend;
18 ein Beispiel einer Verteilung von Arbeit;
19 eine Beispielverwendung von Thread-Ausführung;
20 ein beispielhaftes Betriebsmittelzuweisungsschema;
21 ein Beispiel einer Bewegung zwischen Zuständen;
22 ein Beispiel der zum Verarbeiten von Kontexten benötigten Zeit; und
23 einen Beispielprozess.

AUSFÜHRLICHE BESCHREIBUNG
In der folgenden Beschreibung sind für die Zwecke der Erläuterung zahlreiche spezifische Einzelheiten dargelegt, um ein gründliches Verstehen der nachstehend beschriebenen Ausführungsformen der nachstehenden Erfindung bereitzustellen. Es wird jedoch für einen Fachmann offensichtlich, dass Ausführungsformen der Erfindung ohne einige dieser spezifischen Einzelheiten praktiziert werden können. In anderen Fällen sind bekannte Strukturen und Vorrichtungen in Blockdiagrammform gezeigt, um das Verdecken der zugrundeliegenden Prinzipien der Ausführungsformen der Erfindung zu vermeiden.
BEISPIELHAFTE GRAFIKPROZESSORARCHITEKTUREN UND DATENTYPEN
Systemüberblick
1 ist ein Blockdiagramm eines Verarbeitungssystems 100 gemäß einer Ausführungsform. Das System 100 kann in einem Einzelprozessor-Desktop-System, einem Mehrprozessor-Workstation-System oder einem Serversystem, das eine große Anzahl von Prozessoren 102 oder Prozessorkernen 107 aufweist, verwendet werden. In einer Ausführungsform ist das System 100 eine Verarbeitungsplattform, die in eine integrierte Schaltung eines Ein-Chip-Systems (SoC) zum Gebrauch in mobilen, tragbaren oder eingebetteten Vorrichtungen eingebunden ist, wie z. B. in Vorrichtungen des Internet der Dinge (IoT) mit drahtgebundener oder drahtloser Konnektivität zu einem lokalen oder Weitbereichsnetz.
In einer Ausführungsform kann das System 100 Folgendes enthalten, damit gekoppelt sein oder damit integriert sein: eine serverbasierte Spieleplattform; eine Spielekonsole, die eine Spiel- und Medienkonsole enthält; eine mobile Spielekonsole, eine tragbare Spielekonsole oder eine Online-Spielekonsole. In einigen Ausführungsformen ist das System 100 Teil eines Mobiltelefons, eines Smartphone, einer Tablet-Berechnungsvorrichtung oder einer mobilen mit dem Internet verbundenen Vorrichtung wie z. B. eines Laptops mit geringer interner Speicherkapazität. Das Verarbeitungssystem 100 kann außerdem Folgendes enthalten, damit gekoppelt sein oder damit integriert sein: eine am Körper getragene Vorrichtung, wie z. B. eine am Körper getragene Smartwatch-Vorrichtung; intelligente Brille oder Kleidung, die mit Merkmalen für erweiterte Realität (AR) oder virtuelle Realität (VR) erweitert sind, um visuelle, Audio- oder tastbare Ausgaben bereitzustellen, um visuelle, Audio- oder tastbare Wahrnehmungen der realen Welt zu ergänzen, oder anderweitig Text, Audio, Grafik, Video, holographische Bilder oder Video oder tastbare Rückmeldung bereitzustellen; eine andere Vorrichtung für erweiterte Realität (AR); oder eine andere Vorrichtung für virtuelle Realität (VR). In einigen Ausführungsformen enthält das Verarbeitungssystem 100 ein Fernsehgerät oder eine Set-Top-Box-Vorrichtung oder ist Teil davon.
In einer Ausführungsform kann das System 100 ein selbstfahrendes Fahrzeug wie z. B. einen Bus, einen Sattelschlepper, ein Kraftfahrzeug, ein Motorrad oder Elektrofahrrad, ein Flugzeug oder Segelflugzeug (oder irgendeine Kombination daraus) enthalten, damit gekoppelt sein oder darin integriert sein. Das selbstfahrende Fahrzeug kann das System 100 verwenden, um die um das Fahrzeug erfasste Umgebung zu verarbeiten.
In einigen Ausführungsformen enthalten der eine oder die mehreren Prozessoren 102 jeweils einen oder mehrere Prozessorkerne 107 zum Verarbeiten von Anweisungen, die dann, wenn sie ausgeführt werden, Operationen für das System oder Anwender-Software ausführen. In einigen Ausführungsformen ist wenigstens einer aus dem einen oder den mehreren Prozessorkernen 107 konfiguriert, einen spezifischen Befehlssatz 109 auszuführen. In einigen Ausführungsformen kann der Befehlssatz 109 „Complex Instruction Set Computing“ (CISC), „Reduced Instruction Set Computing“ (RISC) oder Berechnen über ein „Very Long Instruction Word“ (VLIW) unterstützen. Ein oder mehrere Prozessorkerne 107 können einen unterschiedlichen Befehlssatz 109 verarbeiten, der Anweisungen zum Unterstützen der Emulation anderer Befehlssätze enthalten kann. Der Prozessorkern 107 kann außerdem andere Verarbeitungsvorrichtungen enthalten, wie z. B. einen digitalen Signalprozessor (DSP).
In einigen Ausführungsformen enthält der Prozessor 102 eine Cache-Speicher 104. Abhängig von der Architektur kann der Prozessor 102 einen einzelnen internen Cache oder mehrere Ebenen von internem Cache aufweisen. In einigen Ausführungsformen wird der Cache-Speicher von verschiedenen Komponenten des Prozessors 102 gemeinsam verwendet. In einigen Ausführungsformen enthält der Prozessor 102 außerdem einen externen Cache (z. B. einen Ebene-3- (L3-) Cache oder Cache der letzten Ebene (LLC)) (nicht gezeigt), der von den Prozessorkernen 107 unter Verwendung bekannter Cache-Kohärenztechniken gemeinsam verwendet werden kann. Eine Registerdatei 106 kann zusätzlich in dem Prozessor 102 enthalten sein und kann unterschiedliche Typen von Registern zum Speichern unterschiedlicher Typen von Daten enthalten (z. B. Ganzzahlregister, Gleitkommaregister, Statusregister und ein Befehlszeigerregister). Einige Register können Allzweckregister sein, während andere Register für die Konstruktion des Prozessors 102 spezifisch sein können.
In einigen Ausführungsformen sind ein oder mehrere Prozessor(en) 102 mit einem oder mehreren Schnittstellenbus(sen) 110 gekoppelt, um Kommunikationssignale wie z. B. Adresse, 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 Typen von Schnittstellenbussen enthalten. In einer Ausführungsform enthält/enthalten der/die Prozessor(en) 102 eine integrierte Speichersteuereinheit 116 und einen Plattformsteuereinheit-Hub 130. Die Speichersteuereinheit 116 ermöglicht die Kommunikation zwischen einer Speichervorrichtung und anderen Komponenten des Systems 100, während der Plattformsteuereinheit-Hub (PCH) 130 Verbindungen zu I/O-Vorrichtungen über einen lokalen I/O-Bus bereitstellt.
Die Speichervorrichtung 120 kann eine Vorrichtung mit dynamischem Direktzugriffsspeicher (DRAM), eine Vorrichtung mit statischem Direktzugriffsspeicher (SRAM), eine Flash-Speichervorrichtung, eine Phasenwechselspeichervorrichtung oder eine andere Speichervorrichtung sein, die geeignete Leistungsfähigkeit 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 Anweisungen 121 zum Gebrauch, wenn der eine oder die mehreren Prozessoren 102 eine Anwendung oder einen Prozess ausführt, zu speichern. Die Speichersteuereinheit 116 ist außerdem mit einem optionalen externen Grafikprozessor 112 gekoppelt, der mit dem einen oder den mehreren Grafikprozessoren 108 in den Prozessoren 102 kommunizieren kann, um Grafik- und Medienoperationen auszuführen. In einigen Ausführungsformen kann eine Anzeigevorrichtung 111 mit dem/den Prozessor(en) 102 verbunden sein. Die Anzeigevorrichtung 111 kann eine oder mehrere aus einer internen Anzeigevorrichtung, wie in einer mobilen elektronischen Vorrichtung oder einer Laptop-Vorrichtung, oder einer externen Anzeigevorrichtung, die über eine Anzeigeschnittstelle (z. B. DisplayPort usw.) angeschlossen ist, sein. In einer Ausführungsform kann die Anzeigevorrichtung 111 eine am Kopf getragene Anzeigevorrichtung (HMD) wie z. B. eine stereoskopische Anzeigevorrichtung zum Gebrauch in Anwendungen für virtuelle Realität (VR) oder Anwendungen für erweiterte Realität (AR) sein.
In einigen Ausführungsformen ermöglicht der Plattformsteuereinheit-Hub 130, dass sich Peripheriegeräte mit der Speichervorrichtung 120 und dem Prozessor 102 über einen Hochgeschwindigkeits-I/O-Bus verbinden. Die I/O-Peripheriegeräte enthalten, ohne jedoch darauf beschränkt zu sein, eine Audiosteuereinheit 146, eine Netzsteuereinheit 134, eine Firmware-Schnittstelle 128, einen Drahtlos-Sender/Empfänger 126, Berührungssensoren 125, eine Datenspeichervorrichtung 124 (z. B. nichtflüchtigen Speicher, flüchtigen Speicher, Festplattenlaufwerk, Flash-Speicher NAND, 3D-NAND, 3D XPoint usw.). Die Datenspeichervorrichtung 124 kann über eine Speicherschnittstelle (z. B. SATA) oder über einen Peripherie-Bus wie z. B. einen „Peripheral Component Interconnect“-Bus (z. B. PCI, PCI Express) verbunden sein. Die Berührungssensoren 125 können Sensoren für berührungssensitiven Bildschirm, Drucksensoren oder Fingerabdrucksensoren enthalten. Der Drahtlos-Sender/Empfänger 126 kann ein Wi-Fi-Sender/Empfänger, ein Bluetooth-Sender/Empfänger oder ein Sender/Empfänger eines mobilen Netzes wie z. B. ein 3G-, 4G-, 5G- oder Langzeitentwicklungs- (LTE-) Sender/Empfänger sein. Die Firmware-Schnittstelle 128 ermöglicht Kommunikation mit System-Firmware und kann beispielsweise eine „Unified Extensible Firmware“-Schnittstelle (UEFI) sein. Die Netzsteuereinheit 134 kann eine Netzverbindung zu einem drahtgebundenen Netz ermöglichen. In einigen Ausführungsformen ist eine Hochleistungsnetzsteuereinheit (nicht gezeigt) mit dem Schnittstellenbus 110 gekoppelt. Die Audiosteuereinheit 146 ist in einer Ausführungsform eine hochauflösende Mehrkanal-Audiosteuereinheit. In einer Ausführungsform enthält das System 100 optional eine alte I/O-Steuereinheit 140 zum Koppeln alter (z. B. Personal System 2 (PS/2)) Vorrichtungen mit dem System. Der Plattformsteuereinheit-Hub 130 kann außerdem mit einer oder mehreren über Steuereinheiten 142 für den universellen seriellen Bus (USB) verbundene Eingabevorrichtungen verbinden, wie z. B. Kombinationen aus Tastatur und Maus 143, einer Kamera 144 oder anderen USB-Eingabevorrichtungen.
Es ist zu verstehen, dass das gezeigte System 100 beispielhaft und nicht einschränkend ist, da andere Typen von Datenverarbeitungssystemen, die anders konfiguriert sind, ebenfalls verwendet werden können. Beispielsweise können eine Instanz der Speichersteuereinheit 116 und der Plattformsteuereinheit-Hub 130 in einen diskreten externen Grafikprozessor wie z. B. den externen Grafikprozessor 112 integriert sein. In einer Ausführungsform können der Plattformsteuereinheit-Hub 10 und/oder die Speichersteuereinheit 116 außerhalb des einen oder der mehreren Prozessor(en) 102 sein. Beispielsweise kann das System 100 eine externe Speichersteuereinheit 116 und einen Plattformsteuereinheit-Hub 130 enthalten, die als ein Speichersteuereinheit-Hub und Peripheriesteuereinheit-Hub innerhalb eines System-Chipsatzes, der in Kommunikation mit dem/den Prozessor(en) 102 ist, konfiguriert sein können.
Beispielsweise können Platinen („Sleds“) verwendet werden, auf denen Komponenten wie z. B. CPUs, Speicher und andere Komponenten platziert sind, die für gesteigerte thermische Leistungsfähigkeit konstruiert sind. In einigen Beispielen befinden sich Verarbeitungskomponenten wie z. B. die Prozessoren auf einer Oberseite eines „Sied“, während sich naher Speicher, wie z. B. DIMMs, auf einer Unterseite des „Sled“ befindet. Als ein Ergebnis der verbesserten Luftströmung, die durch diese Konstruktion bereitgestellt ist, können die Komponenten mit höheren Frequenzen und Leistungspegeln arbeiten wie in typischen Systemen und erhöhen dadurch die Leistungsfähigkeit. Darüber hinaus sind die „Sleds“ so konfiguriert, dass sie mit Strom- und Datenkommunikationskabeln in einem Rack blind zusammenpassen, und dadurch ist ihre Fähigkeit verbessert, schnell entfernt, hochgerüstet, neu installiert und/oder ersetzt zu werden. Ähnlich sind individuelle Komponenten, die sich auf den „Sleds“ befinden, wie z. B. Prozessoren, Beschleuniger, Speicher und Datenspeicherlaufwerke, so konfiguriert, dass sie aufgrund ihres vergrößerten Abstands zueinander leicht aufgerüstet werden können. In der erläuternden Ausführungsform enthalten die Komponenten zusätzlich Hardware-Bestätigungs-Merkmale, um ihre Authentizität nachzuweisen.
Ein Datenzentrum kann eine einzige Netzarchitektur („Fabric“) nutzen, die mehrere andere Netzarchitekturen, die Ethernet und Omni-Path enthalten, unterstützt. Die „Sleds“ können mit Verteilern über Lichtleitfasern verbunden sein, die höhere Bandbreite und geringere Latenz als typische Zweidrahtleitungen (z. B. Kategorie 5, Kategorie 5e, Kategorie 6 usw.) bereitstellen. Aufgrund der hohen Bandbreite, Zusammenschaltungen mit geringer Latenz und der Netzarchitektur kann das Datenzentrum Pool-Betriebsmittel wie z. B. Speicher, Beschleuniger (z. B. GPUs, Grafikbeschleuniger, FPGAs, ASICs, Beschleuniger für neuronale Netze und/oder künstliche Intelligenz usw.) und Datenspeicherlaufwerke, die physikalisch getrennt sind, verwenden und sie für Rechenbetriebsmittel (z. B. Prozessoren) je nach Bedarf bereitstellen, was es den Rechenbetriebsmitteln ermöglicht, auf die Pool-Betriebsmittel so zuzugreifen, als ob sie lokal wären.
Eine Stromversorgung oder -quelle kann Spannung und/oder Strom für das System 100 oder irgendein/e hier beschriebene/s Komponente oder System bereitstellen. In einem Beispiel enthält die Stromquelle einen AD/DC- (Wechselstrom/Gleichstrom-) Adapter, der in eine Steckdose gesteckt werden kann. Ein solcher Wechselstrom kann eine Stromquelle aus erneuerbarer Energie (z. B. Solargenergie) sein. In einem Beispiel enthält die Stromquelle eine DC-Stromquelle, wie z. B. einen externen AC/DC-Umsetzer. In einem Beispiel enthält die Stromquelle oder Stromversorgung eine Hardware für drahtloses Laden, um über die Nähe zu einem Ladungsfeld zu laden. In einem Beispiel kann die Stromquelle eine interne Batterie, eine Wechselstromversorgung, eine bewegungsbasierte Stromversorgung, eine Solarstromversorgung oder eine Brennstoffzellenquelle enthalten.
2 ist ein Blockdiagramm einer Ausführungsform eines Prozessors 200, der einen oder mehrere Prozessorkerne 202A-202N, eine integrierte Speichersteuereinheit 214 und einen integrierten Grafikprozessor 208 aufweist. Diejenigen Elemente von 2, die die gleichen Bezugszeichen (oder Namen) wie die Elemente irgendeiner anderen Figur hier aufweisen, können auf eine Weise arbeiten oder funktionieren, die ähnlich derjenigen ist, die hier an anderer Stelle beschrieben ist, sind jedoch nicht darauf beschränkt. Der Prozessor 200 kann zusätzliche Kerne bis zu dem und einschließlich des zusätzlichen Kerns 202N enthalten, die durch die gestrichelten Kästen repräsentiert sind. Jeder der Prozessorkerne 202A-202N enthält eine oder mehrere interne Cache-Einheiten 204A-204N. In einigen Ausführungsformen besitzt jeder Prozessorkern außerdem Zugang zu einer oder mehreren gemeinsam verwendeten Cache-Einheiten 206.
Die internen Cache-Einheiten 204A-204N und gemeinsam verwendeten Cache-Einheiten 206 repräsentieren eine Cache-Speicherhierarchie innerhalb des Prozessors 200. Die Cache-Speicherhierarchie kann wenigstens eine Ebene von Befehls- und Daten-Cache innerhalb jedes Prozessorkerns und eine oder mehrere Ebenen von gemeinsam verwendetem Cache mittlerer Ebene, wie z. B. Ebene 2 (L2), Ebene 3 (L3), Ebene 4 (L4) oder andere Ebenen von Cache enthalten, wobei die höchste Ebene des Cache vor dem externen Speicher als der 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.
In einigen Ausführungsformen kann der Prozessor 200 außerdem eine Gruppe aus einer oder mehreren Bussteuereinheiten 216 und einen Systemagentenkern 210 enthalten. Die eine oder die mehreren Bussteuereinheiten 216 managen eine Gruppe peripherer Busse, wie z. B. einen oder mehrere PCI- oder PCI-Express-Busse. Der Systemagentenkern 210 stellt Managementfunktionalität für die verschiedenen Prozessorkomponenten bereit. In einigen Ausführungsformen enthält der Systemagentenkern 210 eine oder mehrere integrierte Speichersteuereinheiten 214 zum Managen des Zugriffs auf verschiedene externe Speichervorrichtungen (nicht gezeigt).
In einigen Ausführungsformen enthalten ein oder mehrere der Prozessorkerne 202A-202N Unterstützung für simultanes Multi-Threading. In einer solchen Ausführungsform enthält der Systemagentenkern 210 Komponenten zum Koordinieren und Betreiben der Kerne 202A-202N während der Verarbeitung mehrerer Threads. Der Systemagentenkern 210 kann zusätzlich eine Leistungssteuerungseinheit (PCU) enthalten, 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 zum Ausführen von Grafikverarbeitungsoperationen. In einigen Ausführungsformen ist der Grafikprozessor 208 mit der Gruppe gemeinsam verwendeter Cache-Einheiten 206 und dem Systemagentenkern 210, der die eine oder mehreren integrierten Speichersteuereinheiten 214 enthält, gekoppelt. In einigen Ausführungsformen enthält der Systemagentenkern 210 außerdem eine Anzeigesteuereinheit 211 zum Treiben der Grafikprozessorausgabe zu einer oder mehreren gekoppelten Anzeigevorrichtungen. In einigen Ausführungsformen kann die Anzeigesteuereinheit 211 außerdem ein separates Modul sein, das mit dem Grafikprozessor über wenigstens eine Zusammenschaltung gekoppelt ist, oder kann in den Grafikprozessor 208 integriert sein.
In einigen Ausführungsformen ist eine ringbasierte Zusammenschaltungseinheit 212 verwendet, um die internen Komponenten des Prozessors 200 zu koppeln. Es kann jedoch eine alternative Zusammenschaltung verwendet sein, wie z. B. eine Punkt-zu-Punkt-Zusammenschaltung, eine geschaltete Zusammenschaltung oder andere Techniken, die in der Technik gut bekannte Techniken enthalten. In einigen Ausführungsformen ist der Grafikprozessor 208 mit der Ringzusammenschaltung 212 über eine I/O-Verbindungsstrecke 213 gekoppelt.
Die beispielhafte I/O-Verbindungsstrecke 213 repräsentiert wenigstens eine aus mehreren Varianten von I/O-Zusammenschaltungen, die eine bausteininterne I/O-Zusammenschaltung enthalten, die die Kommunikation zwischen verschiedenen Prozessorkomponenten und einem eingebetteten Hochleistungs-Speichermodul 218, wie z. B. einem eDRAM-Modul, ermöglicht. In einigen Ausführungsformen verwendet jeder aus den Prozessorkernen 202A-202N und dem Grafikprozessor 208 eingebettete Speichermodule 218 als einen gemeinsam verwendeten Cache letzter Ebene.
In einigen Ausführungsformen sind die Prozessorkerne 202A-202N homogene Kerne, die die gleiche Befehlssatzarchitektur ausführen. In einer weiteren Ausführungsform sind die Prozessorkerne 202A-202N hinsichtlich der Befehlssatzarchitektur (ISA) heterogen, wobei einer oder mehrere der Prozessorkerne 202A-202N einen ersten Befehlssatz ausführen, während wenigstens einer der anderen Kerne eine Teilmenge des ersten Befehlssatzes oder einen anderen Befehlssatz ausführt. In einer Ausführungsform sind die Prozessorkerne 202A-202N hinsichtlich der Mikroarchitektur heterogen, wobei ein oder mehrere Kerne, die einen relativ hohen Energieverbrauch aufweisen, mit einem oder mehreren Leistungskernen, die einen niedrigeren Energieverbrauch aufweisen, gekoppelt sind. Zusätzlich kann der Prozessor 200 auf einem oder mehreren Chips oder als eine integrierte Schaltung eines SoC implementiert sein, die die dargestellten Komponenten aufweisen, zusätzlich zu anderen Komponenten.
Die internen Cache-Einheiten 204A-204N und gemeinsam verwendeten Cache-Einheiten 206 repräsentieren eine Cache-Speicherhierarchie innerhalb des Prozessors 200. Die Cache-Speicherhierarchie kann wenigstens eine Ebene von Befehls- und Daten-Cache innerhalb jedes Prozessorkerns und eine oder mehrere Ebenen von gemeinsam verwendeten Cache mittlerer Ebene, wie z. B. Ebene 2 (L2), Ebene 3 (L3), Ebene 4 (L4) oder andere Ebenen von Cache, enthalten, wobei die höchste Ebene des Cache vor dem externen Speicher als der 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.
In einigen Ausführungsformen kann der Prozessor 200 außerdem eine Gruppe aus einer oder mehreren Bussteuereinheiten 216 und einen Systemagentenkern 210 enthalten. Die eine oder mehreren Bussteuereinheiten 216 managen eine Gruppe peripherer Busse, wie z. B. einen oder mehrere PCI- oder PCI-Express-Busse. Der Systemagentenkern 210 stellt Managementfunktionalität für die verschiedenen Prozessorkomponenten bereit. In einigen Ausführungsformen enthält der Systemagentenkern 210 eine oder mehrere integrierte Speichersteuereinheiten 214 zum Managen des Zugriffs auf verschiedene externe Speichervorrichtungen (nicht gezeigt).
In einigen Ausführungsformen enthalten ein oder mehrere der Prozessorkerne 202A-202N Unterstützung für simultanes Multi-Threading. In einer solchen Ausführungsform enthält der Systemagentenkern 210 Komponenten zum Koordinieren und Betreiben der Kerne 202A-202N während der Verarbeitung mehrerer Threads. Der Systemagentenkern 210 kann zusätzlich eine Leistungssteuerungseinheit (PCU) enthalten, 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 zum Ausführen von Grafikverarbeitungsoperationen. In einigen Ausführungsformen ist der Grafikprozessor 208 mit der Gruppe gemeinsam verwendeter Cache-Einheiten 206 und dem Systemagentenkern 210, der die eine oder mehreren integrierten Speichersteuereinheiten 214 enthält, gekoppelt. In einigen Ausführungsformen enthält der Systemagentenkern 210 außerdem eine Anzeigesteuereinheit 211 zum Treiben der Grafikprozessorausgabe zu einer oder mehreren gekoppelten Anzeigevorrichtungen. In einigen Ausführungsformen kann die Anzeigesteuereinheit 211 außerdem ein separates Modul sein, das mit dem Grafikprozessor über wenigstens eine Zusammenschaltung gekoppelt ist, oder kann in den Grafikprozessor 208 integriert sein.
In einigen Ausführungsformen wird eine ringbasierte Zusammenschaltungseinheit 212 verwendet, um die internen Komponenten des Prozessors 200 zu koppeln. Es kann jedoch eine alternative Zusammenschaltung verwendet werden, wie z. B. eine Punkt-zu-Punkt-Zusammenschaltung, eine geschaltete Zusammenschaltung oder andere Techniken, die in der Technik bekannte Techniken einschließen. In einigen Ausführungsformen ist der Grafikprozessor 208 mit der Ringzusammenschaltung 212 über eine I/O-Verbindungsstrecke 213 gekoppelt.
Die beispielhafte I/O-Verbindungsstrecke 213 repräsentiert wenigstens eine aus mehreren Varianten von I/O-Zusammenschaltungen, die eine bausteininterne I/O-Zusammenschaltung enthalten, die die Kommunikation zwischen verschiedenen Prozessorkomponenten und einem eingebetteten Hochleistungs-Speichermodul 218, wie z. B. einem eDRAM-Modul, ermöglicht. In einigen Ausführungsformen kann jeder aus den Prozessorkernen 202A-202N und dem Grafikprozessor 208 eingebettete Speichermodule 218 als einen gemeinsam verwendeten Cache letzter Ebene verwenden.
In einigen Ausführungsformen sind die Prozessorkerne 202A-202N homogene Kerne, die die gleiche Befehlssatzarchitektur ausführen. In einer weiteren Ausführungsform sind die Prozessorkerne 202A-202N hinsichtlich der Befehlssatzarchitektur (ISA) heterogen, wobei einer oder mehrere der Prozessorkerne 202A-202N einen ersten Befehlssatz ausführen, während wenigstens einer der anderen Kerne eine Teilmenge des ersten Befehlssatzes oder einen anderen Befehlssatz ausführt. In einer Ausführungsform sind die Prozessorkerne 202A-202N hinsichtlich der Mikroarchitektur heterogen, wobei ein oder mehrere Kerne, die einen relativ hohen Energieverbrauch aufweisen, mit einem oder mehreren Leistungskernen, die einen niedrigeren Energieverbrauch aufweisen, gekoppelt sind. In einer Ausführungsform sind die Prozessorkerne 202A-202N hinsichtlich der Rechenfähigkeit heterogen. Zusätzlich kann der Prozessor 200 auf einem oder mehreren Chips oder als eine integrierte Schaltung eines SoC implementiert sein, die die dargestellten Komponenten aufweisen, zusätzlich zu anderen Komponenten.
3 ist ein Blockdiagramm eines Grafikprozessors 300, der eine diskrete Grafikverarbeitungseinheit sein kann oder ein Grafikprozessor sein kann, der mit mehreren Verarbeitungskernen oder anderen Halbleitervorrichtungen wie z. B., ohne jedoch darauf beschränkt zu sein, Speichervorrichtungen oder Netzschnittstellen integriert sein kann. In einigen Ausführungsformen kommuniziert der Grafikprozessor über eine speicherabgebildete I/O-Schnittstelle zu Registern auf dem Grafikprozessor und mit Befehlen, die in den Prozessorspeicher platziert sind. In einigen Ausführungsformen enthält der Grafikprozessor 300 eine Speicherschnittstelle 314, um auf den Speicher zuzugreifen. Die Speicherschnittstelle 314 kann eine Schnittstelle zu einem lokalen Speicher, einem oder mehreren internen Caches, einem oder mehreren gemeinsam verwendeten externen Caches und/oder zu dem Systemspeicher sein.
In einigen Ausführungsformen enthält der Grafikprozessor 300 außerdem eine Anzeigesteuereinheit 302 zum Treiben von Anzeigeausgabedaten zu einer Anzeigevorrichtung 320. Die Anzeigesteuereinheit 302 enthält Hardware für eine oder mehrere Überlagerungsebenen für die Anzeige und Zusammenstellung mehrerer Schichten von Video oder Anwenderschnittstellenelementen. Die Anzeigevorrichtung 320 kann eine interne oder eine externe Anzeigevorrichtung sein. In einer Ausführungsform ist die Anzeigevorrichtung 320 eine am Kopf getragene Anzeigevorrichtung, wie z. B. eine Anzeigevorrichtung für virtuelle Realität (VR) oder eine Anzeigevorrichtung für erweiterte Realität (AR). In einigen Ausführungsformen enthält der Grafikprozessor 300 eine Video-Codec-Engine 306 zum Codieren, Decodieren oder Transcodieren von Medien in ein oder mehrere, aus oder zwischen einem oder mehreren Mediencodierungsformate/n, die, ohne jedoch darauf beschränkt zu sein, sowohl Formate der „Moving Picture Experts Group“ (MPEG) wie z. B. MPEG-2, „Advanced Video Coding“- (AVC-) Formate wie z. B. H.264/MPEG-4 AVC, H.265/HEVC, „Alliance for Open Media“ (AOMedia) VP8, VP9 als auch Formate der „Society of Motion Picture & Television Engineers“ (SMPTE) 421M/VC-1 und „Joint Photographic Experts Group“ (JPEG) wie z. B. JPEG und Motion JPEG (MJPEG) enthalten.
In einigen Ausführungsformen enthält der Grafikprozessor 300 eine Blockbildübertragungs- (BLIT-) Engine 403 zum Ausführen zweidimensionaler (2D) Rasterisierer-Operationen, die beispielsweise Bitgrenzenblockübertragungen enthalten. In einer Ausführungsform werden 2D-Grafikoperationen jedoch unter Verwendung einer oder mehrerer Komponenten der Grafikverarbeitungs-Engine (GPE) 310 ausgeführt. In einigen Ausführungsformen ist die GPE 310 eine Rechen-Engine zum Ausführen von Grafikoperationen, die dreidimensionale (3D-) Grafikoperationen und Medienoperationen enthalten.
In einigen Ausführungsformen enthält die GPE 310 eine 3D-Pipeline 312 zum Ausführen von 3D-Operationen wie z. B. Rendern dreidimensionaler Bilder und Szenen unter Verwendung von Verarbeitungsfunktionen, die auf 3D-Grundformen (z. B. Rechteck, Dreieck usw.) arbeiten. Die 3D-Pipeline 312 enthält programmierbare Elemente und Elemente mit fester Funktion, die verschiedene Aufgaben innerhalb des Elements ausführen und/oder Ausführungs-Threads zu einem 3D/Medienteilsystem 315 erzeugen. Während die 3D-Pipeline 312 verwendet werden kann, um Medienoperationen auszuführen, enthält eine Ausführungsform der GPE 310 außerdem eine Medien-Pipeline 316, die spezifisch verwendet wird, um Medienoperationen auszuführen, wie z. B. Videonachverarbeitung und Bildverbesserung.
In einigen Ausführungsformen enthält die Medien-Pipeline 316 Logikeinheiten mit fester Funktion oder programmierbare Logikeinheiten zum Ausführen einer oder mehrerer spezialisierter Medienoperationen wie z. B. Video-Decodierungsbeschleunigung, Video-Entschachtelung und Video-Codierungsbeschleunigung anstelle der oder im Auftrag der Video-Codec-Engine 306. In einigen Ausführungsformen enthält die Medien-Pipeline 316 zusätzlich eine Thread-Erzeugungseinheit zum Erzeugen von Threads zur Ausführung auf dem 3D/Medienteilsystem 315. Die erzeugten Threads führen Berechnungen für die Medienoperationen auf einer oder mehreren Grafikausführungseinheiten, die in dem 3D/Medienteilsystem 315 enthalten sind, aus.
In einigen Ausführungsformen enthält das 3D/Medienteilsystem 315 Logik zum Ausführen von Threads, die durch die 3D-Pipeline 312 und die Medien-Pipeline 316 erzeugt werden. In einer Ausführungsform senden die Pipelines Thread-Ausführungsanforderungen an das 3D/Medienteilsystem 315, das Thread-Verteilungslogik zum Vermitteln und Verteilen der verschiedenen Anforderungen an verfügbare Thread-Ausführungsbetriebsmittel enthält. Die Ausführungsbetriebsmittel enthalten eine Anordnung von Grafikausführungseinheiten zum Verarbeiten der 3D- und Medien-Threads. In einigen Ausführungsformen enthält das 3D-Medienteilsystem einen oder mehrere interne Caches für Thread-Anweisungen und Daten. In einigen Ausführungsformen enthält das Teilsystem auch gemeinsam verwendeten Speicher, der Register und adressierbaren Speicher enthält, um Daten durch Threads gemeinsam zu verwenden und um Ausgabedaten zu speichern.
Grafikverarbeitungs-Engine
4 ist ein Blockdiagramm einer Grafikverarbeitungs-Engine 410 eines Grafikprozessors in Übereinstimmung mit einigen Ausführungsformen. In einer Ausführungsform ist die Grafikverarbeitungs-Engine 410 eine Version der in 3 gezeigten GPE 310. Elemente von 4, die die gleichen Bezugszeichen (oder Namen) wie die Elemente irgendeiner anderen Figur hier aufweisen, können auf eine Weise arbeiten oder funktionieren, die ähnlich derjenigen ist, die hier an anderer Stelle beschrieben ist, sind jedoch nicht darauf beschränkt. Beispielsweise sind 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 kann in der GPE 410 nicht ausdrücklich enthalten sein. Beispielsweise und in wenigstens einer Ausführungsform ist ein separater Medien- und/oder Bildprozessor mit der GPE 410 gekoppelt.
In einigen Ausführungsformen ist die GPE 410 mit einem Befehls-Streamer 403 gekoppelt oder enthält ihn, der einen Befehlsstrom zu der 3D-Pipeline 312 und/oder Medien-Pipelines 316 bereitstellt. In einigen Ausführungsformen ist der Befehls-Streamer 403 mit Speicher gekoppelt, der Systemspeicher oder einer oder mehrere aus internem Cache-Speicher und gemeinsam verwendetem Cache-Speicher sein kann. In einigen Ausführungsformen empfängt der Befehls-Streamer 403 Befehle von dem Speicher und sendet die Befehle zu der 3D-Pipeline 312 und/oder Medien-Pipeline 316. Die Befehle sind Weisungen, die aus einem Ringpuffer geholt werden, der Befehle für die 3D-Pipeline 312 und Medien-Pipeline 316 speichert. In einer Ausführungsform kann der Ringpuffer zusätzlich Stapelbefehlspuffer enthalten, die Stapel aus mehreren Befehlen speichern. Die Befehle für die 3D-Pipeline 312 können außerdem Referenzen auf im Speicher gespeicherte Daten enthalten, wie z. B., ohne jedoch darauf beschränkt zu sein, Vertex- und Geometriedaten für die 3D-Pipeline 312 und/oder Bilddaten und Speicherobjekte für die Medien-Pipeline 316. Die 3D-Pipeline 312 und die Medien-Pipeline 316 verarbeiten die Befehle und Daten durch Ausführen von Operationen über Logik innerhalb der entsprechenden Pipelines oder durch Verteilen eines oder mehrerer Ausführungs-Threads zu einer Grafikkernanordnung 414. In einer Ausführungsform enthält die Grafikkernanordnung 414 einen oder mehrere Blöcke von Grafikkernen (z. B. Grafikkern(e) 425A, Grafikkern(e) 415B), wobei jeder Block einen oder mehrere Grafikkerne enthält. Jeder Grafikkern enthält eine Gruppe von Grafikausführungsbetriebsmitteln, die sowohl Allzweck- und grafikspezifische Ausführungslogik zum Ausführen von Grafik- und Rechenoperationen als auch Beschleunigungslogik für Texturverarbeitung mit fester Funktion und/oder maschinelles Lernen und künstliche Intelligenz enthalten.
In verschiedenen Ausführungsformen kann die 3D-Pipeline 312 Logik mit fester Funktion und programmierbare Logik enthalten, um ein oder mehrere Shader-Programme zu verarbeiten, wie z. B. Vertex-Shader, Geometrie-Shader, Pixel-Shader, Fragment-Shader, Rechen-Shader oder andere Shader-Programme, durch Verarbeiten der Anweisungen und Verteilen von Ausführungs-Threads zu der Grafikkernanordnung 414. Die Grafikkernanordnung 414 stellt einen einheitlichen Block von Ausführungsbetriebsmitteln zum Gebrauch zum Verarbeiten dieser Shader-Programme bereit. Mehrzweck-Ausführungslogik (z. B. Ausführungseinheiten) innerhalb des/der Grafikkern(e) 415A-414B der Grafikkernanordnung 414 enthält Unterstützung für verschiedene 3D-API-Shader-Sprachen und kann mehrere gleichzeitige Ausführungs-Threads, die mehreren Shadern zugeordnet sind, ausführen.
In einigen Ausführungsformen enthält die Grafikkernanordnung 414 Ausführungslogik zum Ausführen von Medienfunktionen wie z. B. Video- und/oder Bildverarbeitung. In einer Ausführungsform enthalten die Ausführungseinheiten Allzwecklogik, die programmierbar ist, um parallele Allzweckberechnungsoperationen auszuführen, zusätzlich zu Grafikverarbeitungsoperationen. Die Allzwecklogik kann Verarbeitungsoperationen parallel oder zusammen mit Allzwecklogik innerhalb des/der Prozessorkern(e) 107 von 1 oder dem Kern 202A-202N wie in 2 ausführen.
Ausgabedaten, die durch Threads, die auf der Grafikkernanordnung 424 ablaufen, erzeugt werden, können Daten zum Speicher in einem einheitlichen Rückgabepuffer (URB) 418 ausgeben. Der URB 418 kann Daten für mehrere Threads speichern. In einigen Ausführungsformen kann der URB 428 verwendet werden, um Daten zwischen unterschiedlichen Threads, die auf der Grafikkernanordnung 414 ablaufen, zu senden. In einigen Ausführungsformen kann der URB 418 zusätzlich zur Synchronisation zwischen Threads auf der Grafikkernanordnung und der Logik mit fester Funktion innerhalb der Logik 420 mit gemeinsam verwendeter Funktion verwendet werden.
In einigen Ausführungsformen ist die Grafikkernanordnung 414 skalierbar, so dass die Anordnung eine variable Anzahl von Grafikkernen enthält, von denen jeder eine variable Anzahl von Ausführungseinheiten basierend auf der Zielleistung und dem Leistungsfähigkeitsniveau der GPE 410 aufweist. In einer Ausführungsform sind die Ausführungsbetriebsmittel dynamisch skalierbar, so dass Ausführungsbetriebsmittel je nach Bedarf aktiviert oder deaktiviert werden können.
Die Grafikkernanordnung 414 ist mit der Logik 420 mit gemeinsam verwendeter Funktion gekoppelt, die mehrere Betriebsmittel enthält, die von den Grafikkernen in der Grafikkernanordnung gemeinsam verwendet werden. Die gemeinsam verwendeten Funktionen innerhalb der Logik 420 mit gemeinsam verwendeter Funktion sind Hardware-Logikeinheiten, die spezialisierte ergänzende Funktionalität für die Grafikkernanordnung 414 bereitstellen. In verschiedenen Ausführungsformen enthält die Logik 420 mit gemeinsam verwendeter Funktion, ohne jedoch darauf beschränkt zu sein, Logik für Sampler 421, Math 422 und Thread-übergreifende Kommunikation (ITC) 423. Zusätzlich implementieren einige Ausführungsformen einen oder mehrere Cache(s) 425 innerhalb der Logik 420 mit gemeinsam verwendeter Funktion.
Eine gemeinsam verwendete Funktion ist wenigstens in einem Fall implementiert, in dem der Bedarf für eine gegebene spezialisierte Funktion zum Aufnehmen in die Grafikkernanordnung 414 nicht ausreichend ist. Stattdessen ist eine einzige Instanziierung dieser spezialisierten Funktion als eine eigenständige Instanziierung in der Logik 420 für gemeinsam verwendete Funktion implementiert und wird von den Ausführungsbetriebsmitteln innerhalb der Grafikkernanordnung 414 gemeinsam verwendet. Die genaue Gruppe von Funktionen, die von der Grafikkernanordnung 412 gemeinsam verwendet und in der Grafikkernanordnung 414 enthalten ist, variiert über die Ausführungsformen. In einigen Ausführungsformen können spezifische gemeinsam verwendete Funktionen innerhalb der Logik 420 mit gemeinsam verwendeter Funktion, die durch die Grafikkernanordnung 414 extensiv verwendet werden, in der Logik 416 mit gemeinsam verwendeter Funktion innerhalb der Grafikkernanordnung 414 enthalten sein. In verschiedenen Ausführungsformen kann die Logik 416 mit gemeinsam verwendeter Funktion in der Grafikkernanordnung 414 einen Teil der oder die gesamte Logik innerhalb der Logik 420 mit gemeinsam verwendeter Funktion enthalten. In einer Ausführungsform können alle Logikelemente innerhalb der Logik 420 mit gemeinsam verwendeter Funktion innerhalb der Logik 416 mit gemeinsam verwendeter Funktion der Grafikkernanordnung 414 dupliziert sein. In einer Ausführungsform ist die Logik 420 mit gemeinsam verwendeter Funktion zugunsten der Logik 416 mit gemeinsam verwendeter Funktion innerhalb der Grafikkernanordnung 414 ausgeschlossen.
5 ist ein Blockdiagramm von Hardware-Logik eines Grafikprozessorkerns 500 gemäß einigen hier beschriebenen Ausführungsformen. Elemente von 5, die die gleichen Bezugszeichen (oder Namen) wie die Elemente irgendeiner anderen Figur hier aufweisen, können auf eine Weise arbeiten oder funktionieren, die ähnlich derjenigen ist, die hier an anderer Stelle beschrieben ist, sind jedoch nicht darauf beschränkt. Der dargestellte Grafikprozessorkern 500 ist in einigen Ausführungsformen in der Grafikkernanordnung 414 von 4 enthalten. Der Grafikprozessorkern 500, der manchmal als eine Kernscheibe bezeichnet ist, kann ein oder mehrere Grafikkerne innerhalb eines modularen Grafikprozessors sein. Der Grafikprozessorkern 500 ist für eine Grafikkernscheibe beispielhaft, und ein Grafikprozessor, wie er hier beschrieben ist, kann basierend auf Zielleistung und Leistungsfähigkeitseinhüllenden mehrere Grafikkernscheiben enthalten. Jeder Grafikprozessorkern 500 kann einen Block 530 mit fester Funktion enthalten, der mit mehreren Teilkernen 501A-501F, auch als Teilscheiben bezeichnet, die modulare Blöcke von Allzwecklogik und Logik mit fester Funktion enthalten, gekoppelt ist.
In einigen Ausführungsformen enthält der Block 530 mit fester Funktion eine Pipeline 536 für Geometrie/feste Funktion, die von allen Teilkerne in dem Grafikprozessorkern 500 gemeinsam verwendet werden kann, beispielsweise in Implementierungen für Grafikprozessoren mit geringerer Leistungsfähigkeit und/oder geringerem Energieverbrauch. In verschiedenen Ausführungsformen enthält die Pipeline 536 für Geometrie/feste Funktion eine Pipeline mit fester 3D-Funktion (z. B. 3D-Pipeline 312 wie in 3 und 4), eine Video-Frontend-Einheit, eine Thread-Erzeugungseinheit und einen Thread-Verteiler und einen Manager des einheitlichen Rückgabepuffers, der einheitliche Rückgabepuffer wie z. B. den einheitlichen Rückgabepuffer 418 von 4 managt.
In einer Ausführungsform enthält der Block 530 mit fester Funktion außerdem eine Grafik-SoC-Schnittstelle 537, eine Grafikmikrosteuereinheit 538 und eine Medien-Pipeline 539. Die Grafik-SoC-Schnittstelle 537 stellt eine Schnittstelle zwischen dem Grafikprozessorkern 500 und anderen Prozessorkernen innerhalb einer integrierten Schaltung eines Einchipsystems bereit. Die Grafikmikrosteuereinheit 538 ist ein programmierbarer Teilprozessor, der konfigurierbar ist, verschiedene Funktionen des Grafikprozessorkerns 500, die Thread-Verteilung, Planung und Vorwegnahme enthalten, zu managen. Die Medien-Pipeline 539 (z. B. die Medien-Pipeline 316 von 3 und 4) enthält Logik zum Unterstützen der Decodierung, Codierung und Vorverarbeitung und/oder Nachverarbeitung von Multimediadaten, die Bild- und Videodaten enthalten. Die Medien-Pipeline 539 implementiert Medienoperationen über Anforderungen an die Rechen- und Sample-Logik innerhalb der Teilkerne 501-501F.
In einer Ausführungsform ermöglicht die SoC-Schnittstelle 537, dass der Grafikprozessorkern 500 mit Allzweck-Anwendungsprozessorkernen (z. B. CPUs) und/oder anderen Komponenten innerhalb eines SoC, die Speicherhierarchieelemente wie z. B. einen gemeinsam verwendeten Cache-Speicher der letzten Ebene, den System-RAM und/oder chipintern oder baugruppenintern eingebetteten DRAM enthalten, zu kommunizieren. Die SoC-Schnittstelle 537 kann außerdem die Kommunikation mit Vorrichtungen mit fester Funktion innerhalb des SoC, wie z. B. Kamerabildaufnahme-Pipelines, ermöglichen und ermöglicht die Verwendung und/oder implementiert globale Speicher-Grundbausteine, die von dem Grafikprozessorkern 500 und CPUs innerhalb des SoC gemeinsam verwendet werden können. Die SoC-Schnittstelle 537 kann außerdem Leistungsmanagementsteuerung 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 aus einem Befehls-Streamer und globalen Thread-Verteiler, die konfiguriert sind, die konfiguriert sind, Befehle und Anweisungen für jeden aus dem einen oder den mehreren Grafikkernen innerhalb eines Grafikprozessors bereitzustellen. Die Befehle und Anweisungen können zu der Medien-Pipeline 539, wenn Medienoperationen ausgeführt werden sollen, oder einer Pipeline für Geometrie und feste Funktionen (z. B. die Pipeline 536 für Geometrie und feste Funktionen und die Pipeline 514 für feste Funktionen), wenn Grafikverarbeitungsoperationen ausgeführt werden sollen, verteilt werden.
Die Grafikmikrosteuereinheit 538 kann konfiguriert sein, verschiedene Planungs- und Managementaufgaben für den Grafikprozessorkern 500 auszuführen. In einer Ausführungsform kann die Grafikmikrosteuereinheit 538 Grafik- und/oder Rechenarbeitslastplanung auf den verschiedenen parallelen Grafik-Engines innerhalb der Ausführungseinheits- (EU-) Anordnungen 502A-502F, 504A-504F innerhalb der Teilkerne 501A-501F ausführen. In diesem Planungsmodell kann Host-Software, die auf einem CPU-Kern eines SoC, das den Grafikprozessorkern 500 enthält, abläuft, Arbeitslast zu einer aus mehreren Grafikprozessor-Doorbells übermitteln, die eine Planungsoperation auf der geeigneten Grafik-Engine aufruft. Planungsoperationen enthalten das Bestimmen, welche Arbeitslast als nächstes laufen soll, Übermitteln einer Arbeitslast zu einem Befehls-Streamer, Vorwegnahme existierender Arbeitslasten, die auf einer Engine laufen, Überwachen des Fortschritts einer Arbeitslast und Benachrichtigen der Host-Software, wenn eine Arbeitslast fertiggestellt ist. In einer Ausführungsform kann die Grafikmikrosteuereinheit 538 außerdem Niederenergie- oder Leerlauf-Zustände für den Grafikprozessorkern 500 unterstützen, die den Grafikprozessorkern 500 mit der Fähigkeit ausstatten, Register innerhalb des Grafikprozessorkerns 500 über Niederenergiezustandsübergänge unabhängig von dem Betriebssystem und/oder der Grafiktreiber-Software auf dem System zu sichern und wiederherzustellen.
Der Grafikprozessorkern 500 kann mehr oder weniger als die dargestellten Teilkerne 501A-501F aufweisen, bis zu N modulare Teilkerne. Für jede Gruppe aus N Teilkernen kann der Grafikprozessorkern 500 außerdem eine Logik 510 mit gemeinsam verwendeter Funktion, einen gemeinsam verwendeten und/oder Cache-Speicher 512, eine Pipeline 514 für Geometrie/feste Funktion, und auch zusätzliche Logik 516 mit fester Funktion enthalten, um verschiedene Grafik- und Rechenverarbeitungsoperationen zu beschleunigen. Die Logik 510 mit gemeinsam verwendeter Funktion kann Logikeinheiten enthalten, die der Logik 420 mit gemeinsam verwendeter Funktion von 4 zugeordnet ist (z. B. Sampler-, Math- und/oder Inter-Thread-Kommunikation-Logik), die durch jeden der N Teilkerne innerhalb des Grafikprozessorkerns 500 gemeinsam verwendet werden können. Der gemeinsam verwendete und/oder Cache-Speicher 512 kann ein Cache der letzten Ebene für die Gruppe der N Teilkerne 501A-501F innerhalb des Grafikprozessorkerns 500 sein und kann außerdem als gemeinsam verwendeter Speicher dienen, der für mehrere Teilkerne zugreifbar ist. Die Pipeline 514 für Geometrie/feste Funktion kann anstelle der Pipeline 536 für Geometrie/feste Funktion innerhalb des Blocks 530 mit fester Funktion enthalten sein und kann die gleichen oder ähnliche Logikeinheiten enthalten.
In einer Ausführungsform enthält der Grafikprozessorkern 500 zusätzliche Logik 516 mit fester Funktion, die verschiedene Beschleunigungslogik mit fester Funktion zum Gebrauch durch den Grafikprozessorkern 500 enthalten kann. In einer Ausführungsform enthält die zusätzliche Logik 516 mit fester Funktion eine zusätzliche Geometrie-Pipeline zum Gebrauch für Nur-Positions-Shading. Bei Nur-Position-Shading existieren zwei Geometrie-Pipelines, eine vollständige Geometrie-Pipeline innerhalb der Pipeline 516, 526 für Geometrie/feste Funktion und eine Auswahl-Pipeline, die eine zusätzliche Geometrie-Pipeline ist, die innerhalb der zusätzlichen Logik 516 mit fester Funktion enthalten sein kann. In einer Ausführungsform ist die Auswahl-Pipeline eine verschlankte Version der vollständigen Geometrie-Pipeline. Die vollständige Pipeline und die Auswahl-Pipeline können unterschiedliche Instanzen derselben Anwendung ausführen, wobei jede Instanz einen separaten Kontext aufweist. Nur-Positions-Shading kann lange Auswahl-Abläufe verworfener Dreiecke verstecken, was ermöglicht, dass in einigen Fällen Shading früher fertiggestellt werden kann. Beispielsweise und in einer Ausführungsform kann die Auswahl-Pipeline-Logik innerhalb der zusätzlichen Logik 516 mit fester Funktion Positions-Shader parallel mit der Hauptanwendung ausführen und erzeugt im allgemeinen kritische Ergebnisse schneller als die vollständige Pipeline, da die Auswahl-Pipeline nur die Positionsattribute der Vertices abholt und schattiert, ohne Rasterung und Rendern der Pixel zu dem Rahmenpuffer auszuführen. Die Auswahl-Pipeline kann die erzeugten kritischen Ergebnisse verwenden, um Sichtbarkeitsinformationen für alle Dreiecke zu berechnen, ohne zu berücksichtigen, ob diese Dreiecke ausgewählt sind. Die vollständige Pipeline (die in diesem Fall als eine Wiedergabe-Pipeline bezeichnet sein kann) kann die Sichtbarkeitsinformationen verbrauchen, um die ausgewählten Dreiecke zu überspringen, um nur die sichtbaren Dreiecke zu schattieren, die schließlich zu der Rasterungsphase weitergegeben werden.
In einer Ausführungsform kann die zusätzliche Logik 516 mit fester Funktion außerdem Maschinenlernbeschleunigungslogik, wie z. B. Matrixmultiplikationslogik mit fester Funktion, für Implementierungen enthalten, die Optimierungen für Maschinenlerntraining oder Inferenzieren enthalten.
Innerhalb jeder Grafik enthält der Teilkern 501A-501F eine Gruppe von Ausführungsbetriebsmitteln, die verwendet werden können, um Grafik-, Medien- und Rechenoperationen in Reaktion auf Anforderungen durch die Grafik-Pipeline, die Medien-Pipeline oder Shader-Programme auszuführen. Die Grafikteilkerne 501A-501F enthalten mehrere EU-Anordnungen 502A-502F, 504A-504F, Logik zur Thread-Verteilung und thread-übergreifende Kommunikation (TD/IC-Logik) 503A-503F, einen 3D- (z. B. Textur-) Sampler 505A-505F, einen Medien-Sampler 506A-506F, einen Shader-Prozessor 507A-507F und einen gemeinsam verwendeten lokalen Speicher (SLM) 508A-508F. Die EU-Anordnungen 502A-502F, 504A-504F 502A-502F, 504A-504F enthalten jeweils mehrere Ausführungseinheiten, die Allzweckgrafikverarbeitungseinheiten sind, die zum Ausführen von Gleitkomma- und Ganzzahl/Festkomma-Logikoperationen zum Bedienen von Grafik-, Medien- oder Rechenoperationen, die Grafik-, Medien- oder Computer-Shader-Programme enthalten, fähig sind. Die TD/IC-Logik führt lokale Thread-Verteilung und Thread-Steueroperationen für die Ausführungseinheiten innerhalb eines Teilkerns aus und unterstützt Kommunikation zwischen Threads, die auf den Ausführungseinheiten des Teilkerns ablaufen. Der 3D-Sampler 505A-505F kann Textur oder andere 3D-Grafik-bezogene Daten in den Speicher lesen. Der 3D-Sampler kann Texturdaten basierend auf einem konfigurierten Sample-Zustand und dem Texturformat, das einer gegebenen Textur zugeordnet ist, unterschiedlich lesen. Der Medien-Sampler 506A-506F kann ähnliche Leseoperationen basierend auf dem Typ und dem Format, die Mediendaten zugeordnet sind, ausführen. In einer Ausführungsform kann jeder Grafikteilkern 501A-501F alternierend einen einheitlichen 3D- und Medien-Sampler enthalten. Threads, die auf dem Ausführungseinheiten innerhalb jedes der Teilkerne 501A-501F ablaufen, können den gemeinsam verwendeten lokalen Speicher 508A-508F innerhalb jedes Teilkerns nutzen, um zu ermöglichen, dass Threads, die innerhalb einer Thread-Gruppe ablaufen, unter Verwendung eines gemeinsamen Pools von chip-internem Speicher ablaufen.
Ausführungseinheiten
Die 6A-6B stellen Thread-Ausführungslogik 600, die eine Anordnung von Verarbeitungselementen enthält, die in einem Grafikprozessorkern eingesetzt sind, gemäß hier beschriebenen Ausführungsformen dar. Elemente der 6A-6B, die die gleichen Bezugszeichen (oder Namen) aufweisen wie die Elemente irgendeiner anderen Figur hier, können auf eine Weise arbeiten oder funktionieren, die ähnlich der an anderer Stelle hier beschriebenen ist, sind jedoch nicht darauf beschränkt. 6A stellt eine Übersicht der Thread-Ausführungslogik 600 dar, die eine Variante der Hardware-, die mit jedem Teilkern 501A-501F von 5 dargestellt ist, Logik enthalten kann. 6B stellt beispielhafte interne Einzelheiten einer Ausführungseinheit dar.
Wie in 6A dargestellt ist, enthält in einigen Ausführungsformen die Thread-Ausführungslogik 600 einen Shader-Prozessor 602, einen Thread-Verteiler 604, einen Befehls-Cache 606, eine skalierbare Anordnung von Ausführungseinheiten, die mehrere Ausführungseinheiten 608A-608N enthält, einen Sampler 610, einen Daten-Cache 612 und einen Daten-Port 614. In einer Ausführungsform kann die skalierbare Anordnung von Ausführungseinheiten durch Aktivieren oder Deaktivieren einer oder mehrerer Ausführungseinheiten (z. B. irgendeiner der Ausführungseinheit 608A, 608B, 608C, 608D bis 608N-1 und 608N) basierend auf den Rechenanforderungen einer Arbeitslast dynamisch skaliert werden. In einer Ausführungsform sind die enthaltenen Komponenten über ein Zusammenschaltungs-Fabric, das mit jeder der Komponenten gekoppelt ist, miteinander verbunden. In einigen Ausführungsformen enthält die Thread-Ausführungslogik 600 eine oder mehrere Verbindungen zum Speicher, wie z. B. dem Systemspeicher oder Cache-Speicher, über eine/n oder mehrere aus dem Befehls-Cache 606, dem Daten-Port 614, dem Sampler 610 und den Ausführungseinheiten 608A-608N. In einigen Ausführungsformen ist jede Ausführungseinheit (z. B. 608A) eine eigenständige programmierbare Allzweckberechnungseinheit, die zum Ausführen mehrerer gleichzeitiger Hardware-Threads fähig ist, während sie mehrere Datenelemente parallel für jeden Thread verarbeitet. In verschiedenen Ausführungsformen ist die Anordnung von Ausführungseinheiten 608A-608N skalierbar, so dass es irgendeine Anzahl individueller Ausführungseinheiten enthält.
In einigen Ausführungsformen werden die Ausführungseinheiten 608A-608N primär zum Ausführen von Shader-Programmen verwendet. Ein Shader-Prozessor 602 kann die verschiedenen Shader-Programme verarbeiten und Ausführungs-Threads, die den Shader-Programmen zugeordnet sind, über einen Thread-Verteiler 604 verteilen. In einer Ausführungsform enthält der Thread-Verteiler Logik, um Thread-Einleitungsanforderungen aus den Grafik- und Medien-Pipelines zu vermitteln und die angeforderten Threads auf einer oder mehreren Ausführungseinheiten in den Ausführungseinheiten 608A-608N zu instanziieren. Beispielsweise kann eine Geometrie-Pipeline Vertex-, Parkettierung- oder Geometrie-Shader zur Thread-Ausführungslogik zur Verarbeitung verteilen. In einigen Ausführungsformen kann der Thread-Verteiler 604 außerdem Laufzeit-Thread-Erzeugungsanforderungen aus den ablaufenden Shader-Programmen verarbeiten.
In einigen Ausführungsformen unterstützen die Ausführungseinheiten 608A-608N einen Befehlssatz, der native Unterstützung für viele Standard-3D-Grafik-Shader-Befehle enthält, so dass Shader-Programme aus Grafikbibliotheken (z. B. Direct 3D und OpenGL) mit einer minimalen Übersetzung ausgeführt werden. Die Ausführungseinheiten unterstützen Vertex- und Geometrieverarbeitung (z. B. Vertexprogramme, Geometrieprogramme, Vertex-Shader), Pixelverarbeitung (z. B. Pixel-Shader, Fragment-Shader) und Allzweckverarbeitung (z. B. Rechen- und Medien-Shader). Jede der Ausführungseinheiten 608A-608N ist zur Ausführung von Mehrfachausgabe von Einzelbefehl-Mehrfachdaten (SIMD) fähig, und Mehr-Thread-Betrieb ermöglicht eine effiziente Ausführungsumgebung angesichts von Speicherzugriffen mit größerer Latenz. Jeder Hardware-Thread innerhalb jeder Ausführungseinheit weist eine dedizierte Registerdatei mit großer Bandbreite und einen zugeordneten unabhängigen Thread-Zustand auf. Die Ausführung ist mit Mehrfachausgabe pro Takt zu Pipelines, die zu Ganzzahl-, einfach und doppelt genauer Gleitkommazahloperationen, SIMD-Verzweigungsfähigkeit, logischen Operationen, transzendenten Operationen und verschiedenen anderen Operationen fähig sind. Während auf Daten aus dem Speicher oder einer der gemeinsam verwendeten Funktionen gewartet wird, veranlasst eine Abhängigkeitslogik innerhalb der Ausführungseinheiten 608A-608N, dass ein wartender Thread schläft, bis die angeforderten Daten zurückgegeben worden sind. Während der wartende Thread schläft, können Hardware-Betriebsmittel zum Verarbeiten anderer Threads verwendet werden. Beispielsweise kann während einer Verzögerung, die einer Vertex-Shader-Operation zugeordnet ist, eine Ausführungseinheit Operationen für einen Pixel-Shader, Fragment-Shader oder einen andere Typ eines Shader-Programms, das einen anderen Vertex-Shader enthält, ausführen. Verschiedene Ausführungsformen können für die Ausführung durch Verwendung von Einzelbefehl-Mehrere-Threads (SIMT) als eine Alternative zur Verwendung von SIMD oder zusätzlich zur Verwendung von SIMD gelten. Bezugnahme auf eine/n SIMD-Kern oder -Operation kann auch für SIMT gelten oder für SIMD in Kombination mit SIMT gelten.
Jede Ausführungseinheit in den Ausführungseinheiten 608A-608N arbeitet auf Anordnungen von Datenelementen. Die Anzahl von Datenelementen ist die „Ausführungsgröße“ oder die Anzahl von Kanälen für den Befehl. Ein Ausführungskanal ist eine logische Einheit zum Ausführen für Datenelementzugriff, Maskierung und Ablaufsteuerung innerhalb von Befehlen. Die Anzahl von Kanälen kann von der Anzahl physikalischer Arithmetiklogikeinheiten (ALUs) oder Gleitkommaeinheiten (FPUs) für einen speziellen Grafikprozessor unabhängig sein. In einigen Ausführungsformen unterstützen die Ausführungseinheiten 608A-608N Ganzzahl- und Gleitkomma-Datentypen.
Der Ausführungseinheitenbefehlssatz enthält SIMD-Befehle. Die verschiedenen Datenelemente können als ein Paketdatentyp in einem Register gespeichert sein, und die Ausführungseinheit wird die verschiedenen Elemente basierend auf der Datengröße der Elemente verarbeiten. Beispielsweise werden, wenn sie auf einem 256-Bit breiten Vektor arbeitet, die 256 Bits des Vektors in einem Register gespeichert, und die Ausführungseinheit arbeitet auf dem Vektor als vier separate gepackte 64-Bit-Datenelemente (Datenelemente der Größe Quad-Wort (QW)), acht separate gepackte 32-Bit-Datenelemente (Datenelemente der Größe Double-Word (DW)), sechzehn separaten gepackten 16-Bit-Datenelemente (Datenelemente der Größe Wort (W)) oder zweiunddreißig separate 8-Bit-Datenelemente (Datenelemente der Größe Byte (B)). Es sind jedoch andere Vektorbreiten und Registergrößen möglich.
In einer Ausführungsform können eine oder mehrere Ausführungseinheiten in eine vereinigte Ausführungseinheit 609A-609N kombiniert sein, die eine Thread-Steuerlogik (607A-607N) aufweist, die den vereinigten EUs gemeinsam ist. Mehrere EUs können in eine EU-Gruppe vereinigt sein. Jede EU in der vereinigten EU-Gruppe kann konfiguriert sein, einen separaten SIMD-Hardware-Thread auszuführen. Die Anzahl von EUs in einer vereinigten EU-Gruppe kann gemäß Ausführungsformen variieren. Zusätzlich können verschiedene SIMD pro EU ausgeführt werden, die, ohne darauf beschränkt zu sein, SIMD8, SIMD16 und SIMD32 enthalten. Jede vereinigte Grafikausführungseinheit 609A-609N enthält wenigstens zwei Ausführungseinheiten. Beispielsweise enthält die vereinigte Ausführungseinheit 609A eine erste EU 608A, eine zweite EU 608B und die Thread-Steuerlogik 607A, die der ersten EU 608A und der zweite EU 608B gemeinsam ist. Die Thread-Steuerlogik 607A steuert Threads, die auf der vereinigten Grafikausführungseinheit 609A ausgeführt werden, was es jeder EU innerhalb der vereinigten Ausführungseinheiten 609A-609N ermöglicht, unter Verwendung eines gemeinsamen Befehlszeigerregisters abzulaufen.
Ein oder mehrere interne Befehls-Caches (z. B. 606) sind in der Thread-Ausführungslogik 600 enthalten, um Thread-Befehle für die Ausführungseinheiten zwischenzuspeichern. In einigen Ausführungsformen sind ein oder mehrere Daten-Caches (z. B. 612) enthalten, um Thread-Daten während der Thread-Ausführung zwischenzuspeichern. In einigen Ausführungsformen ist ein Sampler 610 enthalten, um Textur-Sampling für 3D-Operationen und Medien-Sampling für Medienoperationen auszuführen. In einigen Ausführungsformen enthält der Sampler 610 spezialisierte Textur- oder Medien-Sampling-Funktionalität, um Textur- oder Mediendaten während des Sampling-Prozesses zu verarbeiten, bevor die gesampelten Daten für eine Ausführungseinheit bereitgestellt werden.
Während der Ausführung senden die Grafik- und Medien-Pipelines Thread-Einleitungsanforderungen zu der Thread-Ausführungslogik 600 über die Thread-Erzeugungs- und Verteilungs-Logik. Sobald eine Gruppe geometrischer Objekte verarbeitet und in Pixeldaten gerastert worden ist, wird die Pixelprozessorlogik (z. B. Pixel-Shader-Logik, Fragment-Shader-Logik usw.) innerhalb des Shader-Prozessors 602 aufgerufen, um Ausgabeinformationen weiter zu berechnen und zu bewirken, dass Ergebnisse in Ausgabeoberflächen (z. B. Farbpuffer, Tiefenpuffer, Schablonenpuffer usw.) geschrieben werden. In einigen Ausführungsformen berechnet ein Pixel-Shader oder Fragment-Shader die Werte der verschiedenen Vertex-Attribute, die über das gerasterte Objekt interpoliert werden sollen. In einigen Ausführungsformen führt dann die Pixel-Prozessorlogik innerhalb des Shader-Prozessors 602 ein über die Anwendungsprogrammierschnittstelle (API) zugeführtes Pixel- oder Fragment-Shader-Programm aus. Um das Shader-Programm auszuführen, verteilt der Shader-Prozessor 602 Threads an eine Ausführungseinheit (z. B. 608A) über den Thread-Verteiler 604. In einigen Ausführungsformen verwendet der Shader-Prozessor 602 Textur-Sampling-Logik in dem Sampler 610, um auf Texturdaten in Textur-Karten, die in dem Speicher gespeichert sind, zuzugreifen. Arithmetikoperationen auf den Texturdaten und den eingegebenen Geometriedaten berechnen Pixel-Farbdaten für jedes geometrische Fragment oder verwerfen ein oder mehrere Pixel aus der weiteren Verarbeitung.
In einigen Ausführungsformen stellt der Daten-Port 614 einen Speicherzugriffsmechanismus für die Thread-Ausführungslogik 600 bereit, um verarbeitete Daten zum Speicher zur weiteren Verarbeitung auf einer Grafikprozessorausgabe-Pipeline auszugeben. In einigen Ausführungsformen enthält der Daten-Port 614 einen oder mehrere Cache-Speicher (z. B. Daten-Cache 612) oder ist mit ihnen gekoppelt, um Daten für Speicherzugriff über den Daten-Port zwischenzuspeichern.
Wie in 6B dargestellt ist, kann eine Grafikausführungseinheit 608 eine Befehlsabholeinheit 637, eine allgemeine Registerdatei-Anordnung (GRF) 624, eine architektonische Registerdatei-Anordnung (ARF) 626, einen Thread-Vermittler 622, eine Sendeeinheit 630, eine Verzweigungseinheit 632, eine Gruppe von SIMD-Gleitkommaeinheiten (FPUs) 634 und in einer Ausführungsform eine Gruppe dedizierter Ganzzahl-SIMD-ALUs 635 enthalten. Die GRF 624 und die ARF 626 enthalten die Gruppe allgemeiner Registerdateien und architektonischer Registerdateien, die jedem gleichzeitigen Hardware-Thread zugeordnet sind, der in der Grafikausführungseinheit 608 aktiv sein kann. In einer Ausführungsform wird ein architektonischer Zustand pro Thread in der ARF 626 gehalten, während Daten, die während der Thread-Ausführung verwendet werden, in der GRF 624 gespeichert sind. Der Ausführungszustand jedes Threads, der die Befehlszeiger für jeden Thread enthält, kann in thread-spezifischen Registern in der ARF 626 gehalten werden.
In einer Ausführungsform weist die Grafikausführungseinheit 608 eine Architektur auf, die eine Kombination aus gleichzeitigem Multi-Threading (SMT) und feingranularem verschachteltem Multi-Threading (IMT) ist. Die Architektur weist eine modulare Konfiguration auf, die zur Zeit der Konstruktion basierend auf einer Zielanzahl gleichzeitiger Threads und der Anzahl von Registern pro Ausführungseinheit feinabgestimmt werden kann, wobei die Ausführungseinheitsbetriebsmittel über Logik, die verwendet wird, um mehrere gleichzeitige Threads auszuführen, verteilt sind.
In einer Ausführungsform kann die Grafikausführungseinheit 608 mehrere Befehle, die jeweils ein unterschiedlicher Befehl sein können, zusammen ausgeben. Der Thread-Vermittler 622 des Grafikausführungseinheits-Threads 608 kann die Befehle zu einer aus der Sendeeinheit 630, der Verzweigungseinheit 632 oder der/den SIMD-FPU(s) 634 zur Ausführung verteilen. Jeder Ausführungs-Thread kann auf 128 Allzweckregister innerhalb der GRF 624 zugreifen, wobei jedes Register 32 Bytes speichern kann, die als ein SIMD-8-Elementevektor aus 32-Bit-Datenelementen zugreifbar sind. In einer Ausführungsform besitzt jeder Ausführungseinheit-Thread Zugriff auf 4 Kbytes innerhalb der GRF 624, obwohl Ausführungsformen nicht so eingeschränkt sind und in anderen Ausführungsformen mehr oder weniger Registerbetriebsmittel bereitgestellt sein können. In einer Ausführungsform können bis zu sieben Threads gleichzeitig ablaufen, obwohl die Anzahl von Threads pro Ausführungseinheit ebenfalls gemäß Ausführungsformen variieren kann. In einer Ausführungsform, in der sieben Threads auf 4 Kbytes zugreifen können, kann die GRF 624 insgesamt 28 Kbytes speichern. Flexible Adressierungsarten können erlauben, dass Register zusammen adressiert werden, um effektiv breitere Register aufzubauen oder um abgestufte rechteckige Blockdatenstrukturen zu repräsentieren.
In einer Ausführungsform werden Speicheroperationen, Sampler-Operationen und andere Systemkommunikation mit größerer Latenz über „Sende“-Befehle verteilt, die durch die Nachricht, die die Sendeeinheit 630 durchlaufen, ausgeführt werden. In einer Ausführungsform werden Verzweigungsbefehle zu einer dedizierten Verzweigungseinheit 632 verteilt, um SIMD-Divergenz und schließlich Konvergenz zu unterstützen.
In einer Ausführungsform enthält die Grafikausführungseinheit 608 eine oder mehrere SIMD-Gleitkommaeinheiten (FPU(s)) 634 zum Ausführen von Gleitkommaoperationen. In einer Ausführungsform können die FPU(s) 634 außerdem Ganzzahlberechnung unterstützen. In einer Ausführungsform können die FPU(s) 634 bis zur Anzahl von M 32-Bit-Gleitkomma-(oder Ganzzahl-) Operationen SIMD-ausführen oder bis zur 2M 16-Bit-Ganzzahl- oder 16-Bit-Gleitkommaoperationen SIMD-ausführen. In einer Ausführungsform stellt wenigstens eine der FPU(s) erweiterte Math-Fähigkeiten bereit, um transzendente Math-Operationen mit hohem Durchsatz und doppelt genaue 64-Bit-Gleitkommazahl zu unterstützen. In einigen Ausführungsformen ist außerdem eine Gruppe von 8-Bit-Ganzzahl-SIMD-ALUs 635 vorhanden und kann spezifisch optimiert sein, um Operationen auszuführen, die Berechnungen für maschinelles Lernen zugeordnet sind.
In einer Ausführungsform können Anordnungen aus mehreren Instanzen der Grafikausführungseinheit 608 in einer Grafikteilkern-Gruppierung (z. B. einer Teilscheibe) instanziiert werden. Zur 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 mehrere Ausführungskanäle ausführen. In einer weiteren Ausführungsform wird jeder Thread, der auf der Grafikausführungseinheit 608 ausgeführt wird, auf einem anderen Kanal ausgeführt.
7 ist ein Blockdiagramm, das ein Grafikprozessor-Befehlsformat 700 gemäß einigen Ausführungsformen darstellt. In einer oder mehreren Ausführungsformen unterstützen die Grafikprozessorausführungseinheiten einen Befehlssatz, der Befehle in mehreren Formaten aufweist. Die durchgezogen umrandeten Kästen stellen die Komponenten dar, die allgemein in einem Ausführungseinheitenbefehl enthalten sind, während die gestrichelten Linien Komponenten enthalten, die optional sind oder die nur in einer Teilmenge der Befehle enthalten sind. In einigen Ausführungsformen ist das beschriebene und dargestellte Befehlsformat 700 Makro-Befehle, insofern als es Befehle sind, die der Ausführungseinheit zugeführt werden, im Gegensatz zu Mikrooperationen, die aus dem Decodieren von Befehlen resultieren, sobald der Befehl verarbeitet wird.
In einigen Ausführungsformen unterstützen die Grafikprozessorausführungseinheiten nativ Befehle in einem 128-Bit-Befehlsformat 710. Ein kompaktes 64-Bit-Befehlsformat 730 ist für einige Befehle basierend auf dem ausgewählten Befehl, Befehlsoptionen und der Anzahl von Operanden verfügbar. Das native 128-Bit-Befehlsformat 710 stellt Zugriff auf alle Befehlsoptionen bereit, während in dem 64-Bit-Format 730 einige Optionen und Operationen eingeschränkt sind. Die nativen Befehle, die in dem 64-Bit-Format 730 verfügbar sind, variieren je nach Ausführungsform. In einigen Ausführungsformen ist der Befehl teilweise unter Verwendung einer Gruppe von Indexwerten in einem Indexfeld 713 kompaktiert. Die Ausführungseinheit-Hardware referenziert eine Gruppe von Kompaktierungstabellen basierend auf den Indexwerten und verwendet die Kompaktierungstabellenausgaben, um einen nativen Befehl in dem 128-Bit-Befehlsformat 710 zu rekonstruieren. Andere Größen und Formate von Befehlen können verwendet werden.
Für jedes Format definiert der Befehls-Opcode 712 die Operation, die die Ausführungseinheit ausführen soll. Die Ausführungseinheiten führen jeden Befehl parallel über die mehreren Datenelemente jedes Operanden aus. Beispielsweise führt die Ausführungseinheit in Reaktion auf einen Add-Befehl eine gleichzeitige Add-Operation über jeden Farbkanal, der ein Texturelement oder ein Bildelement repräsentiert, aus. Standardmäßig führt die Ausführungseinheit jeden Befehl über alle Datenkanäle der Operanden aus. In einigen Ausführungsformen ermöglicht das Befehlssteuerfeld 714 die Steuerung spezieller Ausführungsoptionen wie z. B. Kanalauswahl (z. B. Vorhersage) und Datenkanalreihenfolge (z. B. Swizzle). 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 zum Gebrauch in dem kompakten 64-Bit-Befehlsformat 730 nicht verfügbar.
Einige Anweisungseinheitenbefehle weisen bis zu drei Operanden auf, die zwei Quelloperanden, src0 720, src1 722, und ein Ziel 718 enthalten. In einigen Ausführungsformen unterstützen die Ausführungseinheiten Befehle mit zwei Zielen, wobei eines der Ziele impliziert ist. Datenmanipulationsbefehle können einen dritten Quelloperanden (z. B. SRC2 724) aufweisen, wobei der Befehls-Opcode 712 die Anzahl von Quelloperanden bestimmt. Ein letzter Quelloperand eines Befehls kann ein unmittelbarer (z. B. fest codierter) Wert sein, der mit dem Befehl übergeben wird.
In einigen Ausführungsformen enthält das 128-Bit-Befehlsformat 710 ein Zugriffs/Adressmodusfeld 726, das beispielsweise spezifiziert, ob ein direkter Registeradressierungsmodus oder ein indirekter Registeradressierungsmodus verwendet wird. Wenn der direkte Registeradressierungsmodus verwendet wird, wird die Registeradresse eines oder mehrerer Operanden durch Bits in dem Befehl direkt 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 spezifiziert. In einer Ausführungsform wird der Adressmodus verwendet, um eine Datenzugriffsausrichtung für den Befehl zu definieren. Einige Ausführungsformen unterstützen Zugriffsmodi, die einen an 16 Byte ausgerichteten Zugriffsmodus und einen an 1 Byte ausgerichteten Zugriffsmodus enthalten, wobei die Byte-Ausrichtung des Adressmodus die Zugriffsausrichtung der Befehlsoperanden bestimmt. Beispielsweise kann in einem ersten Modus der Befehl Byte-ausgerichtete Adressierung für Quell- und Zieloperanden verwenden, und in einem zweiten Modus kann der Befehl 16-Byte-ausgerichtete Adressierung für alle Quell- und Zieloperanden verwenden.
In einer Ausführungsform bestimmt der Adressmodusabschnitt des Zugriffs/Adressmodusfelds 726, ob der Befehl direkte oder indirekte Adressierung verwenden soll. Wenn der direkte Registeradressierungsmodus verwendet wird, stellen Bits in dem Befehl die Registeradresse eines oder mehrerer Operationen direkt bereit. Wenn der indirekte Registeradressierungsmodus verwendet wird, kann die Registeradresse eines oder mehrerer Operanden basierend auf einem Adressregisterwert und einem Adressen-Immediate-Feld in dem Befehl berechnet werden.
In einigen Ausführungsformen sind die Befehle basierend auf Opcode-Bit-Feldern 712 gruppiert, um das Opcode-Decodieren 740 zu vereinfachen. Für einen 8-Bit-Opcode ermöglichen die Bits 4, 5 und 6, dass die Ausführungseinheit den Typ des Opcode bestimmt. Die gezeigte genaue Opcode-Gruppierung ist lediglich ein Beispiel. In einigen Ausführungsformen enthält eine Verschiebungs- und Logik-Opcode-Gruppe 742 Datenverschiebungs- und Logik-Befehle (z. B. Verschieben (mov), Vergleichen (cmp)). In einigen Ausführungsformen verwendet die Verschiebungs- und Logik-Gruppe 742 die fünf höchstwertigen Bits (MSB) gemeinsam, wobei Verschiebungs- (mov) Befehle in der Form 0000xxxxb sind und Logik-Befehle in der Form 0001xxxxb sind. Eine Ablaufsteuerungsbefehlsgruppe 744 (z. B. Aufruf (call), Sprung (jmp)) enthält Befehle in der Form 0010xxxxb (z. B. 0x20). Eine Verschiedenes-Befehlsgruppe 746 enthält eine Mischung aus Befehlen, die Synchronisationsbefehle (z. B. Warten (wait), Senden (send)) in der Form 0011xxxxb (z. B. 0x30) enthält. Eine Parallel-Math-Befehlsgruppe 748 enthält komponentenweise Arithmetikbefehle (z. B. Addieren (add), Multiplizieren (mul)) in der Form 0100xxxxb (z. B. 0x40). Die Parallel-Math-Gruppe 748 führt Arithmetikoperationen parallel über Datenkanäle aus. Die Vektor-Math-Gruppe 750 enthält Arithmetikbefehle (z. B. dp4) in der Form 0101xxxxb (z. B. 0x50). Die Vektor-Math-Gruppe führt Arithmetik wie z. B. Skalarproduktberechnungen auf Vektoroperanden aus.
Grafik-Pipeline
8 ist ein Blockdiagramm einer weiteren Ausführungsform eines Grafikprozessors 800. Elemente von 8, die die gleichen Bezugszeichen (oder Namen) wie die Elemente irgendeiner anderen Figur hier aufweisen, können auf eine Weise arbeiten oder funktionieren, die ähnlich derjenigen ist, die hier an anderer Stelle beschrieben ist, sind jedoch nicht darauf beschränkt.
In einigen Ausführungsformen enthält der Grafikprozessor 800 eine Geometrie-Pipeline 820, eine Medien-Pipeline 830, eine Anzeige-Engine 840, Thread-Ausführungslogik 850 und eine Render-Ausgabe-Pipeline 870. In einigen Ausführungsformen ist der Grafikprozessor 800 ein Grafikprozessor innerhalb eines Mehrkern-Verarbeitungssystems, das einen oder mehrere Allzweckverarbeitungskerne enthält. Der Grafikprozessor wird durch Registerschreiben in ein oder mehrere Steuerregister (nicht gezeigt) oder über Befehle, die zu dem Grafikprozessor 800 über eine Ringzusammenschaltung 802 ausgegeben werden, gesteuert. In einigen Ausführungsformen koppelt die Ringzusammenschaltung 802 den Grafikprozessor 800 mit anderen Verarbeitungskomponenten wie z. B. anderen Grafikprozessoren oder Allzweckprozessoren. Befehle aus der Ringzusammenschaltung 802 werden durch einen Befehls-Streamer 803 interpretiert, der Anweisungen einzelnen Komponenten der Geometrie-Pipeline 802 oder der Medien-Pipeline 803 zuführt.
In einigen Ausführungsformen lenkt der Befehls-Streamer 803 den Betrieb einer Vertex-Abholeinheit 805, die Vertex-Daten aus dem Speicher liest und Vertex-Verarbeitungsbefehle, die durch den Befehls-Streamer 803 bereitgestellt werden, ausführt. In einigen Ausführungsformen stellt die Vertex-Abholeinheit 805 Vertex-Daten für einen Vertex-Shader 807 bereit, der Koordinatenraumtransformation und Ausleuchtungsoperationen für jeden Vertex ausführt. In einigen Ausführungsformen führen die Vertex-Abholeinheit 805 und der Vertex-Shader 807 Vertex-Verarbeitungsbefehle durch Verteilen von Ausführungs-Threads an die Ausführungseinheiten 852A-852B über einen Thread-Verteiler 831 aus.
In einigen Ausführungsformen sind die Ausführungseinheiten 852A-852B eine Anordnung von Vektorprozessoren, die einen Befehlssatz zum Ausführen von Grafik- und Medienoperationen aufweisen. In einigen Ausführungsformen weisen die Ausführungseinheiten 852A-852B einen zugeordneten L1-Cache 851 auf, der für jede Anordnung spezifisch ist oder von den Anordnungen gemeinsam verwendet wird. Der Cache kann als ein Daten-Cache, ein Befehls-Cache oder ein einziger Cache, der partitioniert ist, um Daten und Befehle in unterschiedlichen Partitionen zu beinhalten, konfiguriert sein.
In einigen Ausführungsformen enthält die Geometrie-Pipeline 820 Parkettierungskomponenten, um Hardware-beschleunigte Parkettierung von 3D-Objekten auszuführen. In einigen Ausführungsformen konfiguriert ein programmierbarer Hüll-Shader 811 die Parkettierungsoperationen. Ein programmierbarer Domänen-Shader 817 stellt Backend-Auswertung der Parkettierungsausgabe bereit. Ein Parkettierer 813 arbeitet unter der Leitung des Hüll-Shaders 811 und beinhaltet Speziallogik, um eine Gruppe detaillierter geometrischer Objekte basierend auf einem groben geometrischen Modell zu erzeugen, die als Eingabe in die Geometrie-Pipeline 820 bereitgestellt wird. In einigen Ausführungsformen können, falls keine Parkettierung verwendet wird, die Parkettierungskomponenten (z. B. der Hüll-Shader 811, der Parkettierer 813 und der Domänen-Shader 817) umgangen werden.
In einigen Ausführungsformen können vollständige geometrische Objekte durch einen Geometrie-Shader 819 über einen oder mehrere Threads, die an die Ausführungseinheiten 852A-852B verteilt sind, verarbeitet werden, oder können direkt zu dem Clipper 819 weitergehen. In einigen Ausführungsformen arbeitet der Geometrie-Shader auf vollständigen geometrischen Objekten anstatt auf Vertices oder Ausschnitten von Vertices wie in früheren Stufen der Grafik-Pipeline. Falls die Parkettierung deaktiviert ist, empfängt der Geometrie-Shader 819 Eingaben aus dem Vertex-Shader 807. In einigen Ausführungsformen ist der Geometrie-Shader 819 durch ein Geometrie-Shader-Programm programmierbar, um Geometrie-Parkettierung auszuführen, falls die Parkettierungseinheiten deaktiviert sind.
Vor der Rasterung verarbeitet ein Clipper 829 die Vertex-Daten. Der Clipper 829 kann ein Clipper mit fester Funktion oder ein programmierbarer Clipper, der Clipping- und Geometrie-Shader-Funktionen aufweist, sein. In einigen Ausführungsformen verteilt eine Rasterisierer- und Tiefenprüfungskomponente 873 in der Render-Ausgabe-Pipeline 870 Pixel-Shader, um die geometrischen Objekte in pixelweise Repräsentation umzusetzen. In einigen Ausführungsformen ist die Pixel-Shader-Logik in der Thread-Ausführungslogik 850 enthalten. In einigen Ausführungsformen kann eine Anwendung die Rasterisierer- und Tiefenprüfungskomponente 873 umgehen und auf nicht gerasterte Vertex-Daten über eine Stream-out-Einheit 823 zugreifen.
Der Grafikprozessor 800 weist einen Zusammenschaltungsbus, ein Zusammenschaltungs-Fabric oder einen anderen Zusammenschaltungsmechanismus auf, der es ermöglicht, dass Daten und Nachrichten zwischen den Hauptkomponenten des Prozessors übergehen. In einigen Ausführungsformen sind die Ausführungseinheiten 852A-852B und zugeordnete Logikeinheiten (z. B. L1-Cache 851, Sampler 854, Textur-Cache 858 usw.) über einen Daten-Port 856 zusammengeschaltet, um Speicherzugriff auszuführen und mit Render-Ausgabe-Pipeline-Komponenten des Prozessors zu kommunizieren. In einigen Ausführungsformen weisen der Sampler 854, die Caches 851, 858 und die Ausführungseinheiten 852A-852B jeweils separate Speicherzugriffspfade auf. In einer Ausführungsform kann der Textur-Cache 858 auch als ein Sampler-Cache konfiguriert sein.
In einigen Ausführungsformen enthält wie Render-Ausgabe-Pipeline 870 eine Rasterisierer- und Tiefenprüfungskomponente 873, die vertexbasierte Objekte in eine zugeordnete pixelbasierte Repräsentation umsetzt. In einigen Ausführungsformen enthält die Rasterungslogik eine Fensterbildungs/Maskierungs-Einheit, um die feste Funktion einer Dreieck- und Linienrasterung auszuführen. Ein zugeordneter Render-Cache 878 und Tiefen-Cache 879 sind in einigen Ausführungsformen ebenfalls verfügbar. Eine Pixeloperationskomponente 877 führt pixelbasierte Operationen auf den Daten aus, obwohl in einigen Fällen Pixel Operationen, die 2D-Operationen zugeordnet sind (z. B. Bit-Block-Bildübertragungen mit Einblendung) durch die 2D-Engine 841 ausgeführt werden oder zur Zeit der Anzeige durch die Anzeigesteuereinheit 843 unter Verwendung von Überlagerungsanzeigeebenen ersetzt werden. In einigen Ausführungsformen ist ein gemeinsam verwendeter L3-Cache für alle Grafikkomponenten verfügbar, was das gemeinsame Verwenden von Daten ohne die Verwendung des Systemhauptspeichers ermöglicht.
In einigen Ausführungsformen enthält die Grafikprozessor-Medien-Pipeline 830 eine Medien-Engine 837 und ein Video-Frontend 834. In einigen Ausführungsformen empfängt das Video-Frontend 834 Pipeline-Befehle von dem Befehls-Streamer 803. In einigen Ausführungsformen enthält die Medien-Pipeline 830 einen separaten Befehls-Streamer. In einigen Ausführungsformen verarbeitet das Video-Frontend 834 Medien-Befehle vor dem Senden des Befehls an die Medien-Engine 837. In einigen Ausführungsformen enthält die Medien-Engine 837 Thread-Erzeugungsfunktionalität, um Threads zum Verteilen an die Thread-Ausführungslogik 850 über den Thread-Verteiler 831 zu erzeugen.
In einigen Ausführungsformen enthält der Grafikprozessor 800 eine Anzeige-Engine 840. In einigen Ausführungsformen ist die Anzeige-Engine 840 außerhalb des Prozessors 800 und ist mit dem Grafikprozessor über die Ringzusammenschaltung 802 oder einen anderen Zusammenschaltungsbus oder Fabric gekoppelt. In einigen Ausführungsformen enthält die Anzeige-Engine 840 eine 2D-Engine 841 und eine Anzeigesteuereinheit 843. In einigen Ausführungsformen beinhaltet die Anzeige-Engine 840 Speziallogik, die zum unabhängigen Betreiben der 3D-Pipeline fähig ist. In einigen Ausführungsformen ist die Anzeigesteuereinheit 843 mit einer Anzeigevorrichtung (nicht gezeigt) gekoppelt, die eine in das System integrierte Anzeigevorrichtung, wie in einem Laptop-Computer, oder eine externe Anzeigevorrichtung, die über ein Verbindungselement für die Anzeigevorrichtung angeschlossen ist, sein kann.
In einigen Ausführungsformen sind die Geometrie-Pipeline 820 und die Medien-Pipeline 830 konfigurierbar, um Operationen basierend auf mehreren Grafik- und Medienprogrammierschnittstellen auszuführen, und sind nicht für irgendeine Anwendungsprogrammierschnittstelle (API) spezifisch. In einigen Ausführungsformen übersetzt Treiber-Software für den Grafikprozessor API-Aufrufe, die für eine spezielle Grafik- oder Medienbibliothek spezifisch sind, in Befehle, die durch den Grafikprozessor verarbeitet werden können. In einigen Ausführungsformen ist Unterstützung für die „Open Graphics Library“ (OpenGL), die „Open Computing Language“ (OpenCL) und Vulkan-Grafik und Rechen-API, alle von der Khronos-Gruppe, bereitgestellt. In einigen Ausführungsformen kann auch Unterstützung für die Direct3D-Bibliothek von der Microsoft Corporation bereitgestellt sein. In einigen Ausführungsformen kann eine Kombination dieser Bibliotheken bereitgestellt sein. Es kann auch Unterstützung für die „Open Source Computer Vision Library“ (OpenCV) bereitgestellt sein. Eine zukünftige API mit einer kompatiblen 3D-Pipeline würde ebenfalls unterstützt, falls eine Abbildung von der Pipeline der zukünftigen API auf die Pipeline des Grafikprozessors vorgenommen 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 durchgezogen umrandeten Kästen in 9A stellen die Komponenten dar, die allgemein in einem Grafikbefehl enthalten sind, während die gestrichelten Linien Komponenten enthalten, die optional sind oder die nur in einer Teilmenge der Grafikbefehle enthalten sind. Das beispielhafte Grafikprozessor-Befehlsformat 900 von 9A enthält Datenfelder, um einen Client 902, einen Befehlsoperationscode (Opcode) 904 und Daten 906 für den Befehl zu identifizieren. Ein Teil-Opcode 905 und eine Befehlsgröße 908 sind ebenfalls in einigen Befehlen enthalten.
In einigen Ausführungsformen spezifiziert der Client 902 die Client-Einheit der Grafikvorrichtung, die die Befehlsdaten verarbeitet. In einigen Ausführungsformen untersucht ein Grafikprozessor-Befehls-Parser das Client-Feld jedes Befehls, um die weitere Verarbeitung des Befehls festzusetzen und die Befehlsdaten zu der geeigneten Client-Einheit zu lenken. In einigen Ausführungsformen enthalten die Grafikprozessor-Client-Einheiten eine Speicherschnittstelleneinheit, eine Render-Einheit, eine 2D-Einheit, eine 3D-Einheit und eine Medieneinheit. Jede Client-Einheit weist eine entsprechende Verarbeitungs-Pipeline auf, die die Befehle verarbeitet. Sobald der Befehl durch die Client-Einheit empfangen worden ist, liest die Client-Einheit den Opcode 904 und, falls vorhanden, den Teil-Opcode 905, um die Operation zu bestimmen, die ausgeführt werden soll. Die Client-Einheit führt den Befehl unter Verwendung der Informationen in dem Datenfeld 906 aus. Für einige Befehle wird eine explizite Befehlsgröße 908 erwartet, um die Größe des Befehls zu spezifizieren. In einigen Ausführungsformen bestimmt der Befehls-Parser automatisch die Größe wenigstens einiger der Befehle basierend auf dem Befehls-Opcode. In einigen Ausführungsformen sind Befehle über Vielfache eines Doppelworts ausgerichtet. Andere Befehlsformate können verwendet werden.
Das Ablaufdiagramm in 9B stellt eine beispielhafte Grafikprozessor-Befehlssequenz 910 dar. In einigen Ausführungsformen verwendet Software oder Firmware eines Datenverarbeitungssystems, das mit einer Ausführungsform eines Grafikprozessors ausgestattet ist, eine Version der gezeigte Befehlssequenz, um eine Gruppe von Grafikoperationen aufzubauen, auszuführen und zu beenden. Eine Sample-Befehlssequenz ist nur zu Beispielzwecken gezeigt und beschrieben, da Ausführungsformen nicht auf diese spezifischen Befehle oder auf diese Befehlssequenz beschränkt sind. Außerdem können die Befehle als ein Stapel von Befehlen in einer Befehlssequenz ausgegeben werden, so dass der Grafikprozessor die Sequenz von Befehlen in wenigstens teilweiser Gleichzeitigkeit ausführen kann.
In einigen Ausführungsformen kann die Grafikprozessor-Befehlssequenz 901 mit einem Pipeline-Leerungsbefehl 912 beginnen, um zu bewirken, dass irgendeine aktive Grafik-Pipeline die derzeit anstehenden Befehle für die Pipeline fertigstellt. In einigen Ausführungsformen arbeiten die 3D-Pipeline 922 und die Medien-Pipeline 924 nicht gleichzeitig. Das Leeren der Pipeline wird ausgeführt, um zu bewirken, dass die aktive Grafik-Pipeline irgendwelche anstehenden Befehle fertigstellt. In Reaktion auf ein Leeren der Pipeline wird der Befehls-Parser für den Grafikprozessor die Befehlsverarbeitung pausieren, bis die aktiven Zeichnungs-Engines anstehende Operationen fertigstellen und die relevanten Lese-Caches ungültig gemacht sind. Optional können irgendwelche Daten in dem Render-Cache, die als „schmutzig“ markiert sind, in den Speicher entleert werden. In einigen Ausführungsformen kann der Pipeline-Leerungsbefehl 912 zur Pipeline-Synchronisation oder vor dem Versetzen des Grafikprozessors in einen Zustand mit geringem Energieverbrauch verwendet werden.
In einigen Ausführungsformen wird ein Pipeline-Auswahlbefehl 913 verwendet, wenn eine Befehlssequenz erfordert, dass der Grafikprozessor explizit zwischen Pipelines umschaltet. In einigen Ausführungsformen ist ein Pipeline-Auswahlbefehl 913 nur einmal in einem Ausführungskontext vor dem Ausgeben von Pipeline-Befehlen erforderlich, sofern der Kontext nicht Befehle für beide Pipelines ausgeben muss. In einigen Ausführungsformen ist ein Pipeline-Leerungsbefehl 912 unmittelbar vor dem Umschalten einer Pipeline über den Pipeline-Auswahlbefehl 913 erforderlich.
In einigen Ausführungsformen konfiguriert ein Pipeline-Steuerbefehl 914 eine Grafik-Pipeline für den Betrieb und wird verwendet, um 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 zur Pipeline-Synchronisation und um Daten aus einem oder mehreren Cache-Speichern innerhalb der aktiven Pipeline vor dem Verarbeiten eines Stapels von Befehlen zu entfernen, verwendet.
In einigen Ausführungsformen werden Rückgabepufferzustandsbefehle 916 verwendet, um eine Gruppe von Rückgabepuffern für die jeweiligen Daten zum Schreiben von Daten zu konfigurieren. Einige Pipeline-Operationen erfordern die Zuweisung, Auswahl oder Konfiguration eines oder mehrerer Rückgabepuffer, in die Operationen während der Verarbeitung Zwischendaten schreiben. In einigen Ausführungsformen verwendet der Grafikprozessor außerdem einen oder mehrere Rückgabepuffer, um Ausgabedaten zu speichern und thread-übergreifende Kommunikation auszuführen. In einigen Ausführungsformen enthält der Rückgabepufferzustand 916 Auswählen der Größe und Anzahl von Rückgabepuffern, die für eine Gruppe von Pipeline-Operationen verwendet werden sollen.
Die verbleibenden Befehle in der Befehlssequenz unterscheiden sich basierend auf der aktiven Pipeline für Operationen. 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 an dem Medien-Pipeline-Zustand 940 zugeschnitten.
Die Befehle, um den 3D-Pipeline-Zustand 930 zu konfigurieren, enthalten 3D-Zustandseinstellbefehle für den Vertexpufferzustand, de Vertexelementzustand, den konstanten Farbzustand, den Tiefenpufferzustand und andere Zustandsvariablen, die konfiguriert werden müssen, bevor 3D-Primitiv-Befehle verarbeitet werden. Die Werte dieser Befehle werden wenigstens teilweise basierend auf der speziellen verwendeten 3D-API bestimmt. In einigen Ausführungsformen sind Befehle für den 3D-Pipeline-Zustand 903 außerdem fähig, spezielle Pipeline-Elemente selektiv zu deaktivieren oder zu umgehen, falls diese Elemente nicht verwendet werden.
In einigen Ausführungsformen wird ein Befehl eines 3D-Grundelements verwendet, um 3D-Grundelemente, die durch die 3D-Pipeline verarbeitet werden sollen, zu übermitteln. Befehle und zugeordnete Parameter, die über den Befehl für 3D-Grundelemente 932 an den Grafikprozessor übergeben werden, werden zu der Vertexabholfunktion in der Grafik-Pipeline weitergeleitet. Die Vertexabholfunktion verwendet die Befehlsdaten des 3D-Grundelements, um Vertexdatenstrukturen zu erzeugen. Die Vertexdatenstrukturen werden in einem oder mehreren Rückgabepuffern gespeichert. In einigen Ausführungsformen wird ein Befehl für 3D-Grundelemente 932 verwendet, um Vertexoperationen auf 3D-Grundelementen über Vertex-Shader auszuführen. Um Vertex-Shader auszuführen, verteilt die 3D-Pipeline 922 Shader-Ausführungs-Threads an Grafikprozessorausführungseinheiten.
In einigen Ausführungsformen wird die 3D-Pipeline 922 über einen Ausführungs-924 Befehl oder ein Ereignis getriggert. In einigen Ausführungsformen triggert ein Registerschreiben die Befehlsausführung. In einigen Ausführungsformen wird die Ausführung über einen „Go“- oder „Kick“-Befehl in der Befehlssequenz getriggert. In einer Ausführungsform wird die Befehlsausführung unter Verwendung eines Pipeline-Synchronisationsbefehls getriggert, um die Befehlssequenz über die Grafik-Pipeline zu leeren. Die 3D-Pipeline wird Geometrieverarbeitung für die 3D-Grundelemente ausführen. Sobald die Operationen fertiggestellt sind, werden die resultierenden geometrischen Objekte gerastert, und die Pixel-Engine koloriert die resultierenden Pixel. Zusätzliche Befehle zum Steuern von Pixel-Shading- und Pixel-Backend-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, wenn Medien-Operationen ausgeführt werden. Allgemein hängen die spezifische Verwendung und Art der Programmierung für die Medien-Pipeline 914 von den Medien- oder Rechenoperationen ab, die ausgeführt werden sollen. Spezifische Mediendecodierungsoperationen können während der Mediendecodierung zu der Medien-Pipeline entladen werden. In einigen Ausführungsformen kann die Medien-Pipeline auch umgangen werden, und Mediendecodierung kann ganz oder teilweise unter Verwendung von Betriebsmitteln ausgeführt werden, die durch einen oder mehrere Allzweckverarbeitungskerne bereitgestellt werden. In einer Ausführungsform enthält die Medien-Pipeline außerdem Elemente für Operationen der Allzweckgrafikprozessoreinheit (GPGPU-Operationen), wobei der Grafikprozessor verwendet wird, um SIMD-Vektoroperationen unter Verwendung von Berechnungs-Shader-Programmen auszuführen, die nicht explizit zum Wiedergeben von Grafik-Grundelementen gehören.
In einigen Ausführungsformen ist die Medien-Pipeline 924 auf ähnliche Weise wie die 3D-Pipeline 922 konfiguriert. Eine Gruppe von Befehlen zum Konfigurieren des Medien-Pipeline-Zustands 940 wird verteilt oder in eine Befehlswarteschlange vor den Medienobjektbefehlen 942 platziert. In einigen Ausführungsformen enthalten Befehle für den Medien-Pipeline-Zustand 940 Daten zum Konfigurieren der Medien-Pipeline-Elemente, die verwendet werden, um die Medienobjekte zu verarbeiten. Das enthält Daten zum Konfigurieren der Video-Decodier- und Video-Codier-Logik innerhalb der Medien-Pipeline, wie z. B. das Codierungs- oder Decodierungsformat. In einigen Ausführungsformen unterstützen Befehle für den Medien-Pipeline-Zustand 940 außerdem das Verwenden eines oder mehrerer Zeiger auf „indirekte“ Zustandselemente, die einen Stapel von Zustandseinstellungen beinhalten.
In einigen Ausführungsformen führen Medienobjektbefehle 942 Zeiger zu Medienobjekten zum Verarbeiten durch die Medien-Pipeline zu. Die Medienobjekte enthalten Speicherpuffer, die Videodaten, die verarbeitet werden sollen, enthalten. In einigen Ausführungsformen müssen alle Medien-Pipeline-Zustände vor dem Ausgeben eines Medienobjektbefehls 942 gültig sein. Sobald der Pipeline-Zustand konfiguriert ist und Medienobjektbefehle 942 in eine Warteschlange eingereiht sind, wird die Medien-Pipeline 924 über einen Ausführungsbefehl 944 oder ein äquivalentes Ausführungsereignis (z. B. Registerschreiben) getriggert. Die Ausgabe aus der Medien-Pipeline 924 kann dann durch Operationen nachverarbeitet werden, die durch die 3D-Pipeline 922 oder die Medien-Pipeline 924 bereitgestellt werden. In einigen Ausführungsformen werden GPGPU-Operationen auf ähnliche Weise wie Medienoperationen konfiguriert und ausgeführt.
Grafik-Software-Architektur
10 stellt eine beispielhafte Grafik-Software-Architektur für ein Verarbeitungssystem 1000 gemäß einigen Ausführungsformen dar. In einigen Ausführungsformen enthält die Software-Architektur eine 3D-Grafikanwendung 1010, ein Betriebssystem 1020 und wenigstens einen Prozessor 1030. In einigen Ausführungsformen enthält der Prozessor 1030 einen Grafikprozessor 1032 und einen oder mehrere Allzweckprozessorprozessorkern(e) 1034. Die Grafikanwendung 1010 und das Betriebssystem 1020 laufen jeweils in dem Systemspeicher 1050 des Datenverarbeitungssystems ab.
In einigen Ausführungsformen beinhaltet die 3D-Grafikanwendung ein oder mehrere Shader-Programme, die Shader-Befehle 1012 enthalten. Die Shader-Sprachenbefehle können in einer Shader-Hochsprache wie z. B. der „High Level Shader Language“ (HLSL), Direct3D, der „OpenGL Shader Language“ (GLSL) und so weiter sein. Die Anwendung enthält außerdem ausführbare Befehle 1014 in einer Maschinensprache, die zur Ausführung durch den Allzweckprozessorprozessorkern 1034 geeignet ist. Die Anwendung enthält außerdem Grafikobjekte 1016, die durch Vertexdaten definiert sind.
In einigen Ausführungsformen ist das System ein Microsoft® Windows®-Betriebssystem von der Microsoft Corporation, ein proprietäres UNIX-ähnliches Betriebssystem oder ein Open-Source-UNIX-ähnliches Betriebssystem unter Verwendung einer Variante des Linux-Kernel. Das Betriebssystem 1020 kann eine Grafik-API 1022 wie z. B. die Direct3D-API, die OpenGL-API oder die Vulkan-API unterstützen. Wenn die Direct3D-API verwendet wird, verwendet das Betriebssystem 1020 einen Frontend-Shader-Compiler 1024, um irgendwelche Shader-Befehle 1012 in HLSL in eine Shader-Sprache niedrigerer Ebene zu kompilieren. Die Kompilierung kann eine „Just-in-time“- (JIT-) Kompilierung sein, oder die Anwendung kann Shader-Vorkompilierung ausführen. In einigen Ausführungsformen werden Shader hoher Ebene in Shader niedriger Ebene während der Kompilierung der 3D-Grafikanwendung 1010 kompiliert. In einigen Ausführungsformen werden die Shader-Befehle in einer Zwischenform bereitgestellt, wie z. B. in einer Version der „Standard Portable Intermediate Representation“ (SPIR), die durch die Vulkan-API verwendet wird.
In einigen Ausführungsformen beinhaltet ein Anwendermodus-Grafiktreiber 1026 einen Backend-Shader-Compiler 1027, um die Shader-Befehle 1012 in eine Hardwarespezifische Darstellung umzusetzen. Wenn die OpenGL-API verwendet wird, werden Shader-Befehle 1012 in der GLSL-Hochsprache zu einem Anwendermodus-Grafiktreiber 1026 zur Kompilierung weitergegeben. In einigen Ausführungsformen verwendet der Anwendermodus-Grafiktreiber 1026 Betriebssystemkernelmodusfunktionen 1028, um mit einem Kernelmodus-Grafiktreiber 1029 zu kommunizieren. In einigen Ausführungsformen kommuniziert der Kernelmodus-Grafiktreiber 1029 mit dem Grafikprozessor 1032, um Befehle und Anweisungen zu verteilen.
IP-Kern-Implementierungen
Ein oder mehrere Aspekte wenigstens einer Ausführungsform können durch repräsentativen Code implementiert sein, der auf einem maschinenlesbaren Medium gespeichert ist, das Logik innerhalb einer integrierten Schaltung wie z. B. eines Prozessors repräsentiert und/oder definiert. Beispielsweise kann das maschinenlesbare Medium Befehle enthalten, die verschiedene Logik innerhalb des Prozessors repräsentieren. Wenn sie durch eine Maschine gelesen werden, können die Befehle bewirken, dass die Maschine die Logik zum Ausführen der hier beschriebenen Techniken herstellt. Solche Repräsentationen, die als „IP-Kerne“ bezeichnet sind, sind wiederverwendbare Einheiten von Logik für eine integrierte Schaltung, die auf einem greifbaren, maschinenlesbaren Medium als ein Hardware-Modell, das die Struktur der integrierten Schaltung beschreibt, gespeichert sein können. Das Hardware-Modell kann an verschiedene Kunden oder Produktionsanlagen geliefert werden, die das Hardware-Modell auf Produktionsmaschinen laden, die die integrierte Schaltung herstellen. Die integrierte Schaltung kann so produziert werden, dass die Schaltung Operationen ausführt, die im Zusammenhang mit irgendeiner der hier beschriebenen Ausführungsformen beschrieben sind.
11A ist ein Blockdiagramm, das ein IP-Kern-Entwicklungssystem 1100, das verwendet werden kann, um eine integrierte Schaltung herzustellen, um Operationen auszuführen, gemäß einer Ausführungsform darstellt. Das IP-Kern-Entwicklungssystem 1100 kann verwendet werden, um modulare, wiederverwendbare Konstruktionen zu erzeugen, die in eine größere Konstruktion integriert werden können, oder kann verwendet werden, um eine vollständige integrierte Schaltung (z. B. eine integrierte SOC-Schaltung) zu konstruieren. Eine Konstruktionsanlage 1130 kann eine Software-Simulation 1110 einer IP-Kern-Konstruktion in einer Programmier-Hochsprache (z. B. C/C++) erzeugen. Die Software-Simulation 1110 kann verwendet werden, um das Verhalten des IP-Kerns unter Verwendung eines Simulationsmodells 1112 zu konstruieren, zu testen und zu verifizieren. Das Simulationsmodell 1112 kann Funktions-, Verhaltens- und/oder Zeit-Simulationen enthalten. Eine Konstruktion auf Registerübertragungsebene (RTL-Konstruktion) 1115 kann dann aus dem Simulationsmodell 1112 erzeugt oder synthetisiert werden. Die RTL-Konstruktion 1115 ist eine Abstraktion des Verhaltens der integrierten Schaltung, die den Fluss digitaler Signale zwischen Hardware-Registern modelliert, die die zugeordnete Logik enthält, die unter Verwendung der modellierten digitalen Signale ausgeführt wird. Zusätzlich zu einer RTL-Konstruktion 1115 können auch Konstruktionen niedrigerer Ebene auf Logikebene oder Transistorebene erzeugt, konstruiert oder synthetisiert werden. Somit können die speziellen Einzelheiten der anfänglichen Konstruktion und Simulation variieren.
Die RTL-Konstruktion 1115 oder ein Äquivalent kann ferner durch die Konstruktionsanlage in ein Hardware-Modell 1120, das in Hardware-Beschreibungssprache (HDL) sein kann, oder eine andere Repräsentation physikalischer Konstruktionsdaten synthetisiert werden. Die HDL kann ferner simuliert oder getestet werden, um die IP-Kern-Konstruktion zu verifizieren. Die IP-Kern-Konstruktion kann zur Lieferung an eine Produktionsanlage 1165 Dritter unter Verwendung eines nichtflüchtigen Speichers 1140 (z. B. Festplatte, Flash-Speicher oder irgendein nichtflüchtiges Speichermedium) gespeichert werden. Alternativ kann die IP-Kern-Konstruktion über eine drahtgebundene Verbindung 1150 oder eine drahtlose Verbindung 1160 gesendet werden (z. B. über das Internet). Die Produktionsanlage 1165 kann dann eine integrierte Schaltung herstellen, die wenigstens teilweise auf der IP-Kern-Konstruktion basiert. Die hergestellte integrierte Schaltung kann konfiguriert sein, Operationen in Übereinstimmung mit wenigstens einer hier beschriebenen Ausführungsform auszuführen.
11B stellt eine Querschnittsseitenansicht einer Baugruppe 1170 für eine integrierte Schaltung gemäß einigen hier beschriebenen Ausführungsformen dar. Die Baugruppe 1170 für eine integrierte Schaltung stellt eine Implementierung einer oder mehrerer Prozessor- oder Beschleunigervorrichtungen, wie sie hier beschrieben sind, dar. Die Baugruppe 1170 enthält mehrere Einheiten von Hardware-Logik 1172, 1174, die mit einem Substrat 1180 verbunden sind. Die Logik 1172, 1174 kann wenigstens teilweise in konfigurierbarer Logik oder Hardware-Logik mit fester Funktionalität implementiert sein und kann einen oder mehrere Abschnitte irgendeines aus dem/den Prozessorkern(en), Grafikprozessor(en) oder anderen Beschleunigervorrichtungen, die hier beschrieben sind, enthalten. Jede Einheit der Logik 1172, 1174 kann innerhalb eines Halbleiter-Bausteins implementiert sein und mit dem Substrat 1180 über eine Zusammenschaltungsstruktur 1173 gekoppelt sein. Die Zusammenschaltungsstruktur 1173 kann konfiguriert sein, elektrische Signale zwischen der Logik 1172, 1174 und dem Substrat 1180 zu lenken, und kann, ohne darauf beschränkt zu sein, Zusammenschaltungen wie z. B. Höcker oder Säulenenthalten. In einigen Ausführungsformen kann die Zusammenschaltungsstruktur 1173 konfiguriert sein, elektrische Signale wie beispielsweise Eingabe/Ausgabe- (I/O-) Signale und/oder Strom- oder Massesignale, die dem Betrieb der Logik 1172, 1174 zugeordnet sind, zu lenken. In einigen Ausführungsformen ist das Substrat 1180 ein Epoxid-basiertes Laminatsubstrat. Das Baugruppensubstrat 1180 kann andere geeignete Typen von Substraten in anderen Ausführungsformen enthalten. Die Baugruppe 1170 kann mit anderen elektrischen Vorrichtungen über eine Baugruppenzusammenschaltung 1183 verbunden sein. Die Baugruppenzusammenschaltung 1183 kann mit einer Oberfläche des Substrats 1180 gekoppelt sein, um elektrische Signale zu anderen elektrischen Vorrichtungen wie z. B. einer Hauptplatine, einem anderen Chipsatz oder einem Mehrchipmodul zu lenken.
In einigen Ausführungsformen sind die Einheiten der Logik 1172, 1174 elektrisch mit einer Brücke 1182 gekoppelt, die konfiguriert ist, elektrische Signale zwischen der Logik 1172, 1174 zu lenken. Die Brücke 1182 kann eine kompakte Zusammenschaltungsstruktur sein, die einen Weg für elektrische Signale bereitstellt. Die Brücke 1182 kann ein Brückensubstrat enthalten, das aus Glas oder einem geeigneten Halbleitermaterial zusammengesetzt ist. Merkmale zum elektrischen Lenken können auf dem Brückensubstrat gebildet sein, um eine Chip-zu-Chip-Verbindung zwischen der Logik 1172, 1174 bereitzustellen.
Obwohl zwei Einheiten der Logik 1172, 1174 und eine Brücke 1182 dargestellt sind, können hier beschriebene Ausführungsformen mehr oder weniger Logikeinheiten auf einem oder mehreren Bausteinen enthalten. Der eine oder die mehreren Bausteine können durch null oder mehr Brücken verbunden sein, da die Brücke 1182 ausgeschlossen sein kann, wenn die Logik auf einem einzelnen Baustein enthalten ist. Alternativ können mehrere Bausteine oder Einheiten der Logik durch eine oder mehrere Brücken verbunden sein. Zusätzlich können mehrere Logikeinheiten, Bausteine und Brücken in anderen möglichen Konfigurationen, die dreidimensionale Konfigurationen einschließen, miteinander verbunden sein.
Beispielhafte integrierte Schaltung eines Einchipsystems
Die 12-14 stellen beispielhafte integrierte Schaltungen und zugeordnete Grafikprozessoren, die unter Verwendung eines oder mehrerer IP-Kerne hergestellt sein können, gemäß verschiedenen hier beschriebenen Ausführungsformen dar. Zusätzlich zu dem Dargestellten können andere Logik und Schaltungen enthalten sein, die zusätzliche Grafikprozessoren/Kerne, Peripherie-Schnittstellensteuereinheiten oder Allzweckprozessorprozessorkerne enthalten.
12 ist ein Blockdiagramm, das eine beispielhafte integrierte Schaltung 1200 eines Einchipsystems, die unter Verwendung eines oder mehrerer IP-Kerne hergestellt sein kann, gemäß einer Ausführungsform darstellt. Die beispielhafte integrierte Schaltung 1200 enthält einen oder mehrere Anwendungsprozessor(en) 1205 (z. B. CPUs), wenigstens einen Grafikprozessor 1210 und kann zusätzlich einen Bildprozessor 1215 und/oder einen Videoprozessor 1220 enthalten, von denen jeder ein modularer IP-Kern aus derselben oder mehreren unterschiedlichen Konstruktionsanlagen sein kann. Die integrierte Schaltung 1200 enthält Peripherie- oder Buslogik, die eine USB-Steuereinheit 1225, eine UART-Steuereinheit 12130, eine SPI/SDIO-Steuereinheit 1235 und eine I²S/I²C-Steuereinheit 1240 enthält. Zusätzlich kann die integrierte Schaltung eine Anzeigevorrichtung 1245 enthalten, die mit einer oder mehreren aus einer hochauflösenden Multimediaschnittstellen- (HDMI-) Steuereinheit 1250 und einer „Mobile Industry Processor Interface“- (MIPI-) Anzeigeschnittstelle 1255 gekoppelt ist. Ein Speicher kann durch ein Flash-Speicher-Teilsystem 1260 bereitgestellt sein, das Flash-Speicher und eine Flash-Speicher-Steuereinheit enthält. Eine Speicherschnittstelle kann über eine Speichersteuereinheit 1265 zum Zugriff auf SDRAM- oder SRAM-Speichervorrichtungen bereitgestellt sein. Einige integrierte Schaltungen enthalten zusätzlich eine eingebettete Sicherheits-Engine 1270.
Die 13A-13B sind Blockdiagramme, die beispielhafte Grafikprozessoren zum Gebrauch in einem SoC gemäß hier beschriebenen Ausführungsformen darstellen. 13A stellt einen beispielhaften Grafikprozessor 1310 einer integrierten Schaltung eines Einchipsystems, das unter Verwendung eines oder mehrerer IP-Kerne hergestellt sein kann, gemäß einer Ausführungsform dar. 13B stellt einen zusätzlichen beispielhaften Grafikprozessor 1340 einer integrierten Schaltung eines Einchipsystems, das unter Verwendung eines oder mehrerer IP-Kerne hergestellt sein kann, gemäß einer Ausführungsform dar. Der Grafikprozessor 1310 von 13A ist ein Beispiel eines Grafikprozessorkerns mit geringem Energieverbrauch. Der Grafikprozessor 1340 von 13B ist ein Beispiel eines Grafikprozessorkerns mit höherer Leistung. Jeder der Grafikprozessoren 1310, 1340 kann Varianten des Grafikprozessors 1210 von 12 sein.
Wie in 13A gezeigt ist, enthält der Grafikprozessor 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 Shader-Programme über separate Logik ausführen, so dass der Vertex-Prozessor 1305 optimiert ist, um Operationen für Vertex-Shader-Programme 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-Shader-Programme ausführen. Der Vertex-Prozessor 1305 führt die Vertex-Verarbeitungsstufe der 3D-Grafik-Pipeline aus und erzeugt Grundelemente und Vertex-Daten. Der/die Fragment-Prozessor(en) 1315A-1315N verwenden die Grundelemente und Vertex-Daten, die durch den Vertex-Prozessor 1305 erzeugt werden, um einen Rahmenpuffer zu produzieren, der auf einer Anzeigevorrichtung angezeigt wird. In einer Ausführungsform ist/sind der/die Fragment-Prozessor(en) 1315A-1315N optimiert, um Fragment-Shader-Programme auszuführen, wie sie in der OpenGL-API vorgesehen sind, was verwendet werden kann, um ähnliche Operationen wie ein Pixel-Shader-Programm auszuführen, wie sie in der Direct-3D-API vorgesehen sind.
Der Grafikprozessor 1310 enthält zusätzlich eine oder mehrere Speichermanagementeinheiten (MMUs) 1320A-1320B, Cache(s) 1325A-1325B und Schaltungszusammenschaltungen 1330A-1330B. Die eine oder mehreren MMU(s) 1320A-1320B stellen die Abbildung virtueller auf physikalische Adressen für den Grafikprozessor 1310 bereit, der den Vertex-Prozessor 1305 und/oder die Fragment-Prozessor(en) 1315A-1315N enthält, die im Speicher gespeicherte Vertex- oder Bild/Texturdaten referenzieren können, zusätzlich zu Vertex- oder Bild/Texturdaten, die in dem einen oder den mehreren Cache(s) 1325A-1325B gespeichert sind. In einer Ausführungsform können die eine oder die mehreren MMU(s) 1320A-1320B mit anderen MMUs innerhalb des Systems synchronisiert sein, die eine oder mehrere MMUs enthalten, die dem einen oder den mehreren Anwendungsprozessor(en) 1205, dem Bildprozessor 1215 und/oder dem Videoprozessor 1220 von 12 zugeordnet sind, so dass jeder Prozessor 1205-1220 an einem gemeinsam verwendeten oder einheitlichen virtuellen Speichersystem teilhaben kann. Die eine oder die mehreren Schaltungszusammenschaltung(en) 1330A-1330B ermöglichen dem Grafikprozessor 1310 eine Schnittstelle mit anderen IP-Kernen innerhalb des SoC, entweder über einen internen Bus des SoC oder über eine direkte Verbindung gemäß Ausführungsformen.
Wie in 13B gezeigt ist, enthält der Grafikprozessor 1340 die eine oder die mehreren MMU(s) 1320A-1320B, Caches 1325A-1325B und Schaltungszusammenschaltungen 1330A-1330B des Grafikprozessors 1310 von 13A. Der Grafikprozessor 1340 enthält einen oder mehrere Shader-Kern(e) 1355A-1355N (z. B. 1455A, 1355B, 1355C, 1355D, 1355E, 1355F bis 1355N-1 und 1355N), die eine einheitliche Shader-Kernarchitektur bereitstellen, in der ein einzelner Kern oder Typ oder Kern alle Typen eines programmierbaren Shader-Codes ausführen kann, die Shader-Programmcode enthalten, um Vertex-Shader, Fragment-Shader und/oder Rechen-Shader zu implementieren. Die genaue Anzahl von vorhandenen Shader-Kernen kann unter Ausführungsformen und Implementierungen variieren. Zusätzlich enthält der Grafikprozessor 1340 einen kernübergreifenden Aufgabenmanager 1345, der als ein Thread-Verteiler arbeitet, um Ausführungs-Threads zu einem oder mehreren Shader-Kernen 1355A-1355N zu verteilen, und eine Kachelungseinheit 1358, um Kachelungsoperationen für kachelbasiertes Rendern zu beschleunigen, wobei Render-Operationen für eine Szene im Bildraum unterteilt sind, beispielsweise um lokale räumliche Kohärenz innerhalb einer Szene zu auszunutzen oder die Verwendung interner Caches zu optimieren.
Die 14A-14B stellen zusätzliche beispielhafte Grafikprozessorlogik gemäß hier beschriebenen Ausführungsformen dar. 14A stellt einen Grafikkern 1400 dar, der in dem Grafikprozessor 1210 von 12 enthalten sein kann und ein einheitlicher Shader-Kern 1355A-1355N wie in 13B sein kann. 14B stellt eine zusätzliche Allzweck-Grafikverarbeitungseinheit 1430 dar, die eine hochparallele Allzweck-Grafikverarbeitungseinheit ist, die zum Einsatz auf einem Mehrchipmodul geeignet ist.
Wie in 14A gezeigt ist, enthält der Grafikkern 1400 einen gemeinsam verwendeten Befehls-Cache 1402, eine Textureinheit 1418 und einen Cache/gemeinsam verwendeten Speicher 1420, die für die Ausführungsbetriebsmittel 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 Unterstützungslogik enthalten, die einen lokalen Befehls-Cache 1404A-1404N, einen Thread-Planer 1406A-1406N, einen Thread-Verteiler 1408A-1408N und eine Gruppe von Registern 1410A-1440N enthält. Um Logikoperationen auszuführen, können die Scheiben 1401A-1401N eine Gruppe zusätzlicher Funktionseinheiten (AFUs 1412A-1412N), Gleitkommaeinheiten (FPU 1414A-1414N), Ganzzahlarithmetiklogikeinheiten (ALUs 1416-1416N), Adressberechnungseinheiten (ACU 1413A-1413N), doppelt genaue Gleitkommaeinheiten (DPFPU 1415A-1415N) und Matrixverarbeitungseinheiten (MPU 1417A-1417N) enthalten.
Einige der Berechnungseinheiten arbeiten mit einer spezifischen Genauigkeit. Beispielsweise können die FPUs 1414A-1414N einfach genaue (32-Bit) und halb genaue (16-Bit) Gleitkommaoperationen ausführen, während die DPFPUs 1415A-1415N doppelt genaue (64-Bit) Gleitkommaoperationen ausführen. Die ALUs 1416A-1416N können Ganzzahloperationen mit variabler Genauigkeit mit 8-Bit-, 16-Bit- und 32-Bit-Genauigkeit ausführen und können für Operationen mit gemischter Genauigkeit konfiguriert sein. Die MPUs 1417A-1417N auch für Operationen mit gemischter Genauigkeit konfiguriert sein, die halb genaue Gleitkomma- und 8-Bit-Ganzzahloperationen enthalten. Die MPUs 1417-1417N können eine Vielzahl von Matrixoperationen ausführen, um Maschinenlernanwendungsrahmen zu beschleunigen, was das Ermöglichen von Unterstützung für beschleunigte allgemeine Matrix-auf-Matrix-Multiplikation (GEMM) enthält. Die AFUs 1412A-1412N können zusätzliche Logikoperationen ausführen, die durch die Gleitkomma- oder Ganzzahleinheiten nicht unterstützt werden, was trigonometrische Operationen (z. B. Sinus, Cosinus, usw.) enthält.
Wie in 14B gezeigt ist, kann eine Allzweckverarbeitungseinheit (GPGPU) 1430 konfiguriert sein., hochparallele Berechnungsoperationen zu ermöglichen, die durch eine Anordnung von Grafikverarbeitungseinheiten ausführt werden sollen. Zusätzlich kann die GPGPU 1430 direkt mit anderen Instanzen der GPGPU verknüpft sein, um ein Multi-GPU-Cluster zu erzeugen, um die Trainingsgeschwindigkeit für besonders tiefe neuronale Netze zu verbessern. Die GPGPU 1430 enthält eine Host-Schnittstelle 1432, um eine Verbindung mit einem Host-Prozessor zu ermöglichen. In einer Ausführungsform ist die Host-Schnittstelle 1432 eine PCI-Express-Schnittstelle. Die Host-Schnittstelle kann jedoch auch eine anbieterspezifische Kommunikationsschnittstelle oder ein Kommunikations-Fabric sein. Die GPGPU 1430 empfängt Befehle von dem Host-Prozessor und verwendet einen globalen Scheduler 1434, um Ausführungs-Threads, die diesen Befehlen zugeordnet sind, zu einer Gruppe von Berechnungs-Clustern 1436A-1436H zu verteilen. Die Berechnungs-Cluster 1436A-1436H verwenden einen Cache-Speicher 1438 gemeinsam. Der Cache-Speicher 1438 kann als ein Cache hoher Ebene für Cache-Speicher innerhalb der Berechnungs-Cluster 1436A-1436H sein.
Die GPGPU 1430 enthält den Speicher 1444A-1444B, der mit den Rechen-Clustern 1436A-1436H über eine Gruppe von Speichersteuereinheiten 1442A-1442B gekoppelt ist. In verschiedenen Ausführungsformen kann der Speicher 1434A-1434B verschiedene Typen von Speichervorrichtungen enthalten, die dynamischen Direktzugriffsspeicher (DRAM) oder Grafik-Direktzugriffsspeicher enthalten, wie z. B. synchronen Grafik-Direktzugriffsspeicher (SGRAM), der einen Grafikspeicher mit doppelter Datenrate (GDDR) enthält.
In einer Ausführungsform enthalten die Rechen-Cluster 1436A-1436H jeweils eine Gruppe von Grafikkernen, wie z. B. den Grafikkern 1400 von 14A, der mehrere Typen von Ganzzahl- und Gleitkomma-Logikeinheiten enthalten kann, die Berechnungsoperationen in einem Genauigkeitsbereich ausführen können, der einen für Maschinenlernberechnungen geeigneten enthält. Beispielsweise und in einer Ausführungsform kann wenigstens eine Teilmenge der Gleitkommaeinheiten in jedem der Rechen-Cluster 1436A-1436H konfiguriert sein, 16-Bit- oder 32-Bit-Gleitkommaoperationen auszuführen, während eine andere Teilmenge der Gleitkommaeinheiten konfiguriert sein kann, 64-Bit-Gleitkommaoperationen auszuführen.
Mehrere Instanzen der GPGPU 1430 können konfiguriert sein, als ein Rechen-Cluster zu arbeiten. Der Kommunikationsmechanismus, der durch das Rechen-Cluster zur Synchronisation und zum Datenaustausch verwendet wird, variiert über Ausführungsformen. In einer Ausführungsform kommunizieren die mehreren Instanzen der GPGPU 1430 über die Host-Schnittstelle 1432. In einer Ausführungsform enthält die GPGPU 1430 einen I/O-Hub 1439, der die GPGPU 1430 mit einer GPU-Verknüpfung 1440 koppelt, die eine direkte Verbindung mit anderen Instanzen der GPGPU ermöglicht. In einer Ausführungsform ist die GPU-Verknüpfung 1440 mit einer dedizierten GPU-zu-GPU-Brücke gekoppelt, die Kommunikation und Synchronisation zwischen mehreren Instanzen der GPGPU 1430 ermöglicht. In einer Ausführungsform koppelt die GPU-Verknüpfung 1440 mit einer Hochgeschwindigkeitszusammenschaltung, um Daten zu anderen GPGPUs oder Parallelprozessoren zu senden und von ihnen zu empfangen. In einer Ausführungsform befinden sich die mehreren Instanzen der GPGPU 1430 in separaten Datenverarbeitungssystemen und kommunizieren über eine Netzvorrichtung, die über die Host-Schnittstelle 1432 zugreifbar ist. In einer Ausführungsform kann die GPU-Verknüpfung konfiguriert sein, eine Verbindung zu einem Host-Prozessor zusätzlich zu der oder als eine Alternative zu der Host-Schnittstelle 1432 zu ermöglichen.
Obwohl die dargestellte Konfiguration der GPGPU 1430 konfiguriert sein kann, neuronale Netze zu trainieren, stellt eine Ausführungsform alternative Ausführungsformen der GPGPU 1430 bereit, die zum Einsatz in einer Inferenz-Plattform mit hoher Leistung oder geringem Energieverbrauch konfiguriert sein können. In einer Inferenz-Konfiguration enthält die GPGPU 1432 weniger Rechen-Cluster 1436A-1436H im Vergleich zu der Trainingskonfiguration. Zusätzlich kann die Speichertechnologie, die dem Speicher 1434A-1434B zugeordnet ist, zwischen Inferenz- und Trainingskonfigurationen verschieden sein, wobei Speichertechnologien mit höherer Bandbreite den Trainingstechnologien gewidmet sind. In einer Ausführungsform kann die Inferenz-Konfiguration der GPGPU 1430 inferenzspezifische Befehle unterstützen kann. Beispielsweise kann eine Inferenz-Konfiguration Unterstützung für einen oder mehrere Ganzzahl-Skalarprodukt-Befehle von 8 Bit (oder mit anderer Größe) bereitstellen, die üblicherweise während Inferenz-Operationen für eingesetzte neuronale Netze verwendet werden.
Beispiele für die Ausführung mehrerer Befehle
Eine herkömmliche Weise zum Abbilden von Rechenkontexten auf Rechenbetriebsmittel (z. B. Ausführungseinheiten (EUs)) beinhaltet statische Zuweisung unter Verwendung von Software. Um jedoch das Abbilden von Rechenkontexten auf Rechenbetriebsmittel auf größeren Grafikverarbeitungseinheiten (GPUs) hoch zu skalieren, kann statische Zuweisung oder das Einbeziehen von Software, um für Hochskalieren einzugreifen, für maschinelle Nutzung oder Ausführung nicht machbar sein. Zusätzlich ist in der Vergangenheit eine gesamte GPU bereitgestellt worden, um entweder 3D-Kontexte oder Rechenkontexte zu verarbeiten, jedoch nicht beides, und somit kann eine GPU nicht fähig sein, zum Verarbeiten unterschiedlicher Typen und Anzahlen von Kontexten zu skalieren.
Eine GPU führt eine Arbeit basierend auf übermittelten Kontexten aus. In einigen GPU-Systemen werden übermittelte Kontexte seriell ausgeführt. Beispielsweise liest eine GPU Daten, zu Kontexten zugeordnet sind, aus dem Speicher, führt Arbeit auf den Daten unter Verwendung zugeordneter Kernel oder Prozesse aus und schreibt Ergebnisse in den Speicher. Zur seriellen Ausführung von Kontexten können Probleme mit der Isolierung von Daten zwischen Schritten zum Lesen und Schreiben des Speichers auftreten. Gemäß einigen Ausführungsformen kann, um zur Isolierung von Daten beizutragen, der GPU-Zustand zwischen der Kontextübermittlung gelöscht werden.
Verschiedene Ausführungsformen ermöglichen, dass unabhängige Anwendungen Arbeitslasten unter Verwendung gemeinsam verwendeter Berechnungsbetriebsmittel wie z. B. einer Grafikverarbeitungseinheit (GPU) zur gleichen Zeit ausführen. Verschiedene Ausführungsformen können asynchrone gleichzeitige Ausführung von zwei oder mehr Kontexten des gleichen oder unterschiedlicher Typen aus unterschiedlichen Anwendungen unter Verwendung eines gemeinsam verwendeten Berechnungsbetriebsmittels unterstützen. Ein Berechnungsbetriebsmittel kann die Rechenanlagen basierend auf der Anzahl aktiver ablaufender Rechenkontexte aus einem oder mehreren Rechenkontext-Streamern automatisch dynamisch managen. Beispielsweise kann ein Rechenbetriebsmittel eine Arbeitslastabbildungstabelle verwenden, um einen Kontext auf ein oder mehrere Segmente des Rechenbetriebsmittels zur Ausführung abzubilden. Eine Anwendung oder ein Treiber kann nicht verwendet werden, um einzugreifen, um die Rechenbetriebsmittelaktivität jedes Mal zu managen, wenn ein Kontext endet oder aktiv wird. In einigen Ausführungsformen kann die Ausführung aktiver Kontexte fortgesetzt werden, während neue Kontexte empfangen werden.
Beispielsweise in einer Situation, in der ein erster (einzelner) Rechenkontext-Streamer Kontexte zur Ausführung bereitstellt und ein Rechenbetriebsmittel vier Quadranten von Ausführungseinheiten bereitstellt, können dann alle vier Quadranten der Ausführung der Rechenkontexte von dem ersten Rechenkontext-Streamer zugewiesen werden. Nach der Fertigstellung der Ausführung von Rechenkontexten von dem ersten Rechenkontext-Streamer in einem Quadranten kann der Quadrant in einen Zustand der Inaktivität zurückkehren und zur Ausführung einer Arbeitslast, die dem ersten Rechenkontext-Streamer zugeordnet ist, verfügbar sein.
In dem Fall, in dem ein Rechenkontext von einem zweiten Rechenkontext-Streamer empfangen wird, während irgendein Kontext, der dem ersten Rechenkontext-Streamer zugeordnet ist, auf einem Quadranten ausgeführt wird, wird der dem zweiten Rechenkontext-Streamer zugeordnete Kontext gemäß einem Arbeitslastverteilungsschema einem speziellen Quadranten zur Ausführung zugewiesen. Falls der zugewiesene Quadrant eine Arbeitslast ausführt, die einem Kontext von dem ersten Rechenkontext-Streamer zugeordnet ist, dann wird die dem zweiten Rechenkontext-Streamer zugeordnete Arbeitslast zur Ausführung durch den zugewiesenen Quadranten bereitgestellt, nachdem der zugewiesene Quadrant die Ausführung der dem ersten Rechenkontext-Streamer zugeordneten Arbeitslast fertiggestellt hat. Falls der zugewiesene Quadrant inaktiv oder im Leerlauf ist, dann wird die dem zweiten Rechenkontext-Streamer zugeordnete Arbeitslast (z. B. Threads, Befehle oder Kontexte) zur Ausführung durch den zugewiesenen Quadranten bereitgestellt. Gemäß dem Arbeitslastverteilungsschema für zwei aktive Rechenkontext-Streamer können Arbeitslasten, die dem ersten Rechenkontext-Streamer zugeordnet sind, für die Quadranten bereitgestellt werden, die durch das Arbeitslastverteilungsschema zugewiesen sind, jedoch nicht für die Quadranten, die zur Ausführung von Arbeitslasten von dem zweiten Rechenkontext-Streamer zugewiesen sind.
Der Empfang eines dritten Rechenkontexts während Arbeitslasten von ersten und zweiten Rechenkontext-Streamern aktiv ausgeführt werden, kann die Zuweisung von Rechenkontexten gemäß einem Arbeitslastverteilungsschema unter Quadranten für drei Rechenkontext-Streamer veranlassen. Ähnlich kann der Empfang eines vierten Rechenkontexts während Arbeitslasten von ersten, zweiten und dritten Rechenkontext-Streamern aktiv ausgeführt werden, die Zuweisung von Rechenkontexten gemäß einem Arbeitslastverteilungsschema unter Quadranten für vier Rechenkontext-Streamer veranlassen.
In dem Fall, in dem ein Quadrant die Ausführung einer Arbeitslast fertiggestellt hat und ein Rechenkontext-Streamer, der dem Quadranten zugewiesen ist, keine zusätzlichen Arbeitslasten bereitstellt, kann der Quadrant zur Zuweisung gemäß dem Arbeitslastverteilungsschema basierend auf der Anzahl aktiver Kontexte von (einem) Rechenkontext-Streamer(n) verfügbar sein. Beispielsweise weisen zwei Kontext-Streamer aktive Arbeitslasten auf, und ein erster Rechenkontext-Streamer ist ersten und zweiten Quadranten zugewiesen und ein zweiter Rechenkontext-Streamer ist dritten und vierten Quadranten zugewiesen. In dem Fall, in dem der erste Rechenkontext-Streamer keine zusätzlichen Arbeitslasten (z. B. Threads, Befehle oder Kontexte) aufweist, kann das Arbeitslastverteilungsschema veranlassen, dass Arbeitslasten, die dem zweiten Rechenkontext-Streamer zugeordnet sind, auf ersten, zweiten, dritten und vierten Quadranten ausgeführt werden, nachdem Arbeitslasten, die dem ersten Rechenkontext-Streamer zugeordnet sind, die Ausführung auf den ersten und zweiten Quadranten fertiggestellt haben.
15 bildet eine Beispielumgebung ab. Die Anwendung 1502 kann Befehle zur Verarbeitung zugeordneter Daten zum Speichern im Befehls- (Cmd-) Puffer 1504 und Datenpuffer 1506 erzeugen. Die Befehle können außerdem Referenzen auf im Speicher gespeicherte Daten enthalten, wie z. B., ohne jedoch darauf beschränkt zu sein, Vertex- und Geometriedaten und/oder Bilddaten und Speicherobjekte. Das Verarbeitungselement 1520 kann eines oder mehrere aus den Folgenden sein: eine Render-Engine, eine Ausführungseinheit, eine Grafikverarbeitungseinheit, eine zentrale Verarbeitungseinheit, ein Beschleuniger, eine im Feld programmierbare Gatter-Anordnung und so weiter. Der Befehls-Streamer 1522 kann einen Strom von Befehlen beispielsweise aus einer Anwendung bereitstellen. Der Thread-Verteiler 1524 kann die Threads auf Ausführungseinheiten (EUs) 1532 zur Ausführung verteilen. In diesem Beispiel kann das Verarbeitungselement 1520 eine oder mehrere Doppel-Teilscheiben (DSS) 1530 mit einer oder mehreren Ausführungseinheiten (EUs) 1532 enthalten. Eine EU 1532 kann einen Abschnitt eines Befehls über Ausführung eines Threads und seines zugeordneten Kernels ausführen. Das Verarbeitungselement kann einen Speicher 1536 und Cache 1538 zur Ausführung von Threads und Speichern von Ergebnissen verwenden. Daten und Ergebnisse können in den Systemspeicher 1540 oder den Cache 1542 der letzten Ebene, der einem oder mehreren Kernen oder CPUs zugeordnet ist, kopiert werden.
16 bildet einen Beispielprozess ab. Der Prozess kann unter Verwendung einer mit Bezug auf 15 beschriebenen Umgebung ausgeführt werden, obwohl andere Umgebungen verwendet werden können, wie z. B. diejenige, die mit Bezug auf 17A beschrieben ist, oder eine weitere ähnliche oder verschiedene Berechnungsumgebung. Bei 1602 bereitet eine Anwendung Daten vor und reiht Arbeit (z. B. Befehl, Kernel und Kontext) zur Ausführung durch ein Verarbeitungselement in eine Werteschlange ein. Bei 1604 kann ein Treiber für ein Verarbeitungselement die Arbeit an das Verarbeitungselement übermitteln. Bei 1606 führt das Verarbeitungselement einen nächsten Befehl aus. Bei 1608 werden ein Thread und zugeordneter Kernel verteilt. Beispielsweise kann eine Hardware-Verteilungs-Engine (z. B. Thread-Verteilungs-Engine) Threads verteilen. Bei 1610 lassen eine oder mehrere Ausführungseinheiten Threads ablaufen, die zum Ablaufen bereit sind. Beispielsweise kann ein zum Ablaufen bereiter Thread einen zugeordneten Kernel zum Rechnen und Laden/Speichern aufweisen. Eine EU schaltet zu einem nächsten Thread auf einem Speicherabruf oder Registerstillstand, unter anderem. Wenn ein Thread endet, speichert die EU Ergebnisse und Zustände in den Speicher und nimmt einen weiteren Thread zur Ausführung an. Bei 1612 wird eine Bestimmung dafür vorgenommen, ob ein letzter Befehl für die übermittelte Arbeit erreicht ist. Fall ein letzter Befehl für die übermittelte Arbeit nicht erreicht ist, dann folgt 1608. Fall ein letzter Befehl für die übermittelte Arbeit erreicht ist, dann folgt 1614. Bei 1614 wird die Anwendung benachrichtigt, dass die Arbeit in der Warteschlange fertiggestellt ist.
17A bildet ein beispielhaftes Grafikverarbeitungseinheitssystem ab. In einigen Beispielen kann ein globales Rechen-Frontend (CFEG) 1704 Befehle von einem Render-Befehls-Streamer (RCS) 1706 und asynchronen Rechenkontext-Streamern (CCS) 1702-0 bis 1702-3 empfangen, obwohl unterschiedliche Anzahlen von RCS und CCS unterstützt werden können. Das CFEG 1704 kann eine Befehls- oder Thread-Verteilungs-Engine verwenden, sie bereitstellen oder als sie agieren. Ein Rechenbefehl-Streamer (z. B. CCSO 1702-0 bis CCS3 1702-3) kann einen asynchronen Rechenkontext empfangen und interpretieren. Im Übrigen können Rechenkontexte beispielsweise über einen Verteilungs-Abschnitt unter Verwendung einer MMIO-Adresse durch eine Anwendung bereitgestellt werden. Eine MMIO-Adresse kann einem CCS zugeordnet sein, und ein Software-Treiber und eine Mikrosteuereinheit können Anforderungen zu einem spezifischen CCS oder irgendeinem CCS lenken. Die CCS 1702-0 bis 1702-3 können Rechenkontexte für das CFEG 1704 zum Verteilen zu einem oder mehreren CFE 1706-0 bis 1706-3 bereitstellen. Beispielsweise kann ein Rechenkontext Daten, Variablen, Bedingungen, Kernel, Befehle, Ursprungs- und Ziel-Speicherorte und andere Informationen oder Befehle, die verwendet werden, um Operationen auf Daten auszuführen, definieren. Ein CCS ermöglicht, dass ein Programmierer oder eine Anwendung den Typ der auszuführenden Berechnung auswählt, im Gegensatz zum Aufrufen einer mehrstufigen Verarbeitung. Beispiele von Anwendungen, die Rechenbefehl-Streamer verwenden, enthalten Matrix-Anwendungen (z. B. maschinelles Lernen), physikalisches Modellieren in Spielen, Hochleistungsrechen-Engines (z. B. chemische Reaktionen). Das CFE 1706-0 bis 1706-3 kann (einen) Thread(s) aus Rechenkontexten unter Verwendung einer einzigen Rechenstufe erzeugen.
Das CFEG 1704 kann eine Abbildungstabelle verwenden, um auszuwählen, welches aus den CFE 1706-0 bis 1706-3 Kontexte, Arbeitslasten, Threads oder Befehle von einem oder mehreren CCSO - CCS3 oder RCS 1706 empfangen soll. Ein Befehl, eine Arbeitslast oder ein Thread kann mehrere Befehle, Arbeitslasten oder Threads enthalten oder erzeugen. Beispielsweise kann die Abbildungstabelle als ein Zustandsautomat oder eine programmierbare Tabelle implementiert sein, die Arbeitszuweisung von einem oder mehreren der CCS0-CCS3 zu einem Rechen-Frontend (CFE) 1706-0 bis 1706-3 spezifiziert. Eine Beispiel-Abbildungstabelle ist mit Bezug auf 20 beschrieben, obwohl andere Schemas verwendet werden können. Basierend darauf, ob ein CFE 1706-0 bis 1706-3 eine Arbeitslast verarbeitet, die einem Kontext und einer Quelle einer Arbeitslast zugeordnet ist, kann das CFEG 1704 die Arbeitslast oder den Thread einem spezifischen CFE gemäß der Abbildungstabelle zuweisen. Das CFEG 1704 kann einen Thread-Scheduler bereitstellen, ihn verwenden oder als ein solcher agieren, um Threads zur Ausführung zuzuweisen. Falls das durch die Abbildungstabelle zur Handhabung einer Arbeitslast von dem CCS spezifizierte CFE verfügbar oder inaktiv ist, kann das CFEG 1704 Arbeit zu dem spezifizierten CFE senden. Falls das CFE, das durch die Abbildungstabelle spezifiziert ist, eine Arbeitslast von einem CCS zu handhaben, aktiv eine Arbeit für dasselbe CFE handhabt, kann das CFEG 1704 darauf warten, dass das CFE die Arbeit fertigstellt, oder auf ein anderes CFE (das abgebildet ist, um Befehle von dem CCS zu empfangen), das frei ist, warten und die Arbeit zu diesem CFE senden. Das CFEG 1704 kann Arbeit zu einem CFE, das zum Verarbeiten verfügbar ist, senden und muss keine aktiven Arbeitslasten auf einem speziellen CFE anhalten. Nachdem Zustand und Daten von EUs, die einem CFE zugeordnet sind, verfügbar sind, können diese Informationen kopiert werden, und die EUs, die einem CFE zugeordnet sind, können zum Ausführen einer Arbeit verfügbar sein. Dementsprechend kann das CFEG 1704 dynamisch eine oder mehrere DSSs zum Ausführen einer Arbeitslast von einem CCS oder RCS zuweisen und den Übergang von dem inaktiven Zustand zur Ausführung einer Arbeitslast, die durch die Abbildungstabelle zugewiesen ist, der Fertigstellung der Arbeitslast, zum Beginn einer Arbeitslast von demselben oder einem anderen CCS gemäß der Abbildungstabelle managen.
Das CFEG 1704 kann Arbeitslasten von dem RCS 1706 zu einer am wenigsten belasteten DSS verteilen, CCS-Arbeitslasten können jedoch unter Verwendung einer Abbildungstabelle zugewiesen werden und können nur zu einer erlaubten DSS (gemäß der Abbildungstabelle) gesendet werden. Beispielsweise kann das CFEG 1704 Eingaben von den CCSO 1702-0 bis CCS3 1702-3 und Eingaben von dem RCS 1706 empfangen und Arbeit von CCSO 1702-0 bis CCS3 1702-3 zu CFE 1706-0 bis 1706-3 basierend auf einer Arbeitslastabbildungstabelle verteilen. Das CFEG 1704 kann dynamischen Arbeitslastausgleich von Arbeitslasten, die von einem CCS zu einem CFE gesendet werden, ausführen. In einigen Ausführungsformen kann das CFEG 1704 Arbeit in kleinere Stücke aufbrechen. Beispielsweise können für eine Arbeitslast von 1000 Threads 10 Threads einem CFE in einem Stapel zugewiesen werden, bis alle Threads fertiggestellt sind.
Die CFE 1706-0 bis 1706-3 können Arbeitslasten zu jeweiligen Quadranten 0 bis 3 zuweisen (z. B. verteilen), und jeder Quadrant kann einer oder mehreren Doppel-Teilscheiben (DSSs), die zur Ausführung von Threads verfügbar sind, zugeordnet sein. Die CFE 1706-0 bis 1706-3 können Lastausgleich auf DSSs ausführen. Eine DSS kann Arbeitslasten oder Threads (z. B. Kernel und/oder Code), die von einem CCS0 1702-0 bis CCS3 1702-3 oder RCS 1706 bereitgestellt sind, ablaufen lassen. Eine DSS kann als eine Ausführungseinheit, ein Prozessor, ein Kern, eine Vorrichtung mit fester Funktion, eine im Feld programmierbare Gatter-Anordnung (FPGA), eine programmierbare Logiksteuerung (PLC), eine anwendungsspezifische integrierte Schaltung (ASIC) und so weiter implementiert sein. In einigen Ausführungsformen können DSSs homogene Rechenfähigkeiten bereitstellen. In einigen Beispielen können Arbeitslasten von dem RCS 1706 auf irgendwelchen Rechenanlagen (z. B. DSS) in dem System ablaufen, Arbeitslasten von einem CCS können andererseits jedoch zugewiesen werden, um auf spezifischen Quadranten abzulaufen, basierend auf der Aktivität der anderen CCS-Kontexte und der Abbildungstabelle. In einigen Beispielen kann eine DSS Arbeitslasten von 1 aus 4 CCS zu einer Zeit annehmen, aber irgendeine DSS kann Arbeitslasten von dem RCS 1706 empfangen. In einigen Beispielen weist jeder durch eine DSS ausgeführte Thread einen zugeordneten Bezeichner zu einem Kontext auf, so dass ein DSS-Thread einen zugeordneten Kontext für einen Thread verfolgen kann.
Das Einschränken des CCS auf Zuweisen von Arbeitslasten zu spezifischen Quadranten kann eine Größe des Zustands, der zum Gebrauch durch einen Quadranten der DSS begrenzen und die Größe des Speichers, der verwendet wird, um Kontext zu speichern, begrenzen, so dass Arbeitslasten, die durch den CCS zugewiesen sind, Zustand oder Kontext gemeinsam verwenden können. Der Zustand für Arbeitslasten von einem RCS kann von mehreren Quadranten gemeinsam verwendet werden.
Der RCS 1706 kann 3D-Grafikverarbeitungsbefehle oder Rechenbefehle ablaufen lassen und 3D-Render-Rechenkontexte zur Ausführung durch eine oder mehrere Doppel-Teilscheiben (DSS) über das CFEG 1704 oder die globale Vertex-Abholeinheit (VFG) 1720 verteilen. Die VFG kann Lastausgleich für Vertex-Verarbeitung ausführen. Der RCS 1706 kann Threads erzeugen und sie zu einer mehrstufigen festen 3D-Grafik-Pipeline verteilen, um die Berechnung durch die 3D-Pipeline der Reihe nach zu bewegen. Der RCS 1706 kann Zustände der Pipeline einstellen (z. B. 3D-Render-Kontext) basierend auf einem Zeichnen-Befehl, wobei eine Pipeline eines oder mehrere aus dem Folgenden enthalten kann: einen Vertex-Shader, einen Hüll-Shader, einen Geometrie-Shader, einen Pixel-Shader, einen Hash-Pixel-Shader, Parkettierung und so weiter. In einigen Beispielen kann die DSS Arbeitslasten unter anderem zum Gebrauch in OpenGL- oder DirectX-konformen Grafik-Pipelines annehmen.
Verschiedene Ausführungsformen können das CFEG 1704 verwenden, um Arbeitslastverteilungen zu DSSs ohne Software-Synchronisation wie z. B. Pipe-Steuerung und Leerungen, die die Leistungsfähigkeit begrenzen könnten, zu managen.
17B bildet ein beispielhaftes globales Rechen-Frontend ab. In diesem Beispiel kann die RCS-Warteschlange 1752 Befehle von einem RCS empfangen und sie in eine Warteschlange einreihen, obwohl andere Anzahlen von Warteschlangen verwendet werden kann. Die CCSO-Warteschlange 1754-0 bis CCS3-Warteschlange 1754-3 können Befehle von entsprechenden CCS0 bis CCS3 empfangen und in eine Warteschlange einreihen, obwohl andere Anzahlen von Warteschlangen verwendet werden kann. Die Zuweisungseinheit 1758 kann bestimmen, welcher Quadrant oder welches Berechnungsbetriebsmittel zuzuweisen ist, um einen Befehl auszuführen, basierend auf dem/den Rechenkontext-Streamer(n), die aktive Befehle zur Ausführung aufweisen. Die Abbildungstabelle 1756 kann angeben, welcher Quadrant oder welches Berechnungsbetriebsmittel zuzuweisen ist, um einen Befehl von einem Rechenkontext-Streamer auszuführen. Eine beispielhafte Abbildungstabelle ist beispielsweise mit Bezug auf 20 beschrieben. Eine Quadrantenbesitzübertragungsvorrichtung 1760 kann die Besitzänderung eines Quadranten oder eines Berechnungsbetriebsmittels managen, wenn ein Rechenkontext-Streamer einen Quadranten oder ein Berechnungsbetriebsmittel verwenden soll, nachdem ein anderer Rechenkontext-Streamer denselben Quadranten oder dasselbe Berechnungsbetriebsmittel verwendet. Beispielsweise kann die Quadrantenbesitzübertragungsvorrichtung 1760 den Schreibdatenpuffer des/der Quadranten in den Cache (z. B. Ebene-3-Cache) leeren, den Zustand und feste Caches ungültig machen und/oder die Zustandswerte zu den Einheiten mit gemeinsam verwendeter Funktion (z. B. DSS-Einheiten) verbreiten. Die Zustandswerte können Zeiger auf den Ort des surface_state, die Bindungstabelle und so weiter sein.
18 bildet ein Beispiel einer Verteilung von Arbeit ab. In diesem Beispiel verteilt das CFEG 1802 Rechenarbeit von dem CCS0 bis CCS3 und RCS 1804 zu einem oder mehreren aus den CFE 1806-0 bis 1806-3. Für einen CCS (CCS0 bis CCS3) verfolgt ein Allzweck-Befehls-Streamer (GPCMD) Befehle, die zur Ausführung angefordert sind. Der GPCMD führt einen Befehl COMPUTE_WALKER aus, um die Ausführung eines Kernel über eine oder mehrere Thread-Gruppenverteilungen zu veranlassen. Beispielsweise kann der GPCMD basierend auf einer Abbildungstabelle von CCS auf CFE (und dem zugeordneten Quadranten) Stapel von 1 bis 16 Thread-Gruppen zu einem CFE in jedem Zyklus verteilen. Das CFEG 1802 kann Priorisierung von Kontextweiterleitung unter Kontexten von CCSs und RCS bereitstellen. Ein CFE kann aktive Kontexte von einem RCS und einem CCS unterstützen. In einigen Beispielen kann ein Kontext mit höherer Priorität von einem RCS oder CCS zum Verteilen zu einem CFE und seinem zugeordneten Quadranten bereitgestellt sein.
Die Lastausgleichseinheit 1808 managt den Übergang des CFE-Besitzes von einem Kontext zu einem weiteren. Die Lastausgleichseinheit 1808 kann warten, bis die Thread-Verteilung eines Kontexts enden, und dann den Zustand für den neuen besitzenden Kontext einstellen.
In einigen Ausführungsformen wird ein Zustand von irgendeinem vorweggenommenen GPCMD im Kontextabbild in einer gemeinsamen Schnittstelle zu einer Speichereinheit gesichert, z. B. einer globalen Adressierungseinheit für Befehls-Streamer (GACS).
19 bildet ein Beispiel für Kontextausführungen ab. Threads, die RCS- und CSS-Kontextverteilungen zugeordnet sind, können unter Verwendung eines begrenzten Busbetriebsmittels für eine DSS bereitgestellt werden. RCS- und CCS-Thread-Verteilungen können an einer DSS parallel ankommen. Virtuelle Kanäle können für jede DSS bereitgestellt werden, wobei QID0 verwendet wird, um Threads von dem RCS zu identifizieren, und QID1 verwendet wird, um Threads von einem CCS zu identifizieren. Für eine DSS kann ein einzelner CCS einen Thread zu einer Zeit verteilen. Ablaufende Kontexte können zu einem Befehls-Streamer übermittelt werden, wobei einem Befehls-Streamer eine QID zugewiesen ist. Dem 3D-Befehlsstrom wird eine QID aus QID0 zugewiesen, während Rechenbefehl-Streamern eine QID aus QID1 zugewiesen wird. Die Thread-Verteilung 1902 kann einen Thread mit einer zugeordneten QID (z. B. QID0 oder QID1) verteilen. Eine Tabelle aktiver Seiten eines Befehls-Streamers, die einer eindeutigen EXID zugewiesen ist, und das EXID-Tag werden mit jeder Speicheradresse für Speicher-Caches und Seitentabellenübersetzungen verwendet. In einigen Ausführungsformen unterstützt eine GPU einen 3D-Befehls-Streamer gleichzeitig mit null bis vier aktiven Rechenbefehl-Streamern. Der verteilte Thread kann eine Anforderung zum Ausführen einer Arbeitslast, Thread-Ausführung oder Grafikverarbeitungsoperation sein.
Die Thread-Verteilung 1902 weist einen freien Thread, seine Schranke und gemeinsam verwendeten lokalen Speicher (SLM) zu. Bei der Thread-Zuweisung leert die Thread-Verteilung 1902 die Allzweck-Registerdatei (GRF), die Schranke des Thread und den SLM. In diesem Beispiel werden Caches, die Threads zugeordnet sind, die QID0 und QID1 aufweisen, geleert, wenn sich ein QID-Kontext ändert. Ein verteilter Thread kann auf einer Ausführungseinheit (EU) ablaufen.
Eine DSS-Partition einer GPU, die eine oder mehrere Ausführungseinheiten (EUs) enthält, kann gleichzeitig zwei Kontexte ablaufen lassen: eine QID0 und eine QID1. Jeder ausgeführte Thread wie seine eigene QID, Register (z. B. GRF), Basis/Grenze des gemeinsam verwendeten lokalen Speichers (SLM) (z. B. Speicherbetriebsmittel, die durch die DSS zum Lesen / Schreiben des Speichers verwendet werden) auf. Mehrere EUs können unterschiedliche Threads parallel ausführen. Caches mit gemeinsam verwendeter Funktion werden unter Verwendung einer QID markiert. Die Zugriffe auf den gemeinsam verwendeten lokalen Speicher werden basierend auf einer Grenze pro Thread durch Schranken überprüft.
Um zu versuchen, Datenisolation zwischen den Threads bereitzustellen, kann ein gemeinsam verwendetes DSS-Betriebsmittel das QID-Tag verwenden, um zwei unterschiedliche Rechenkontexte, beide QID1, die separat auf derselben DSS (oder eines Abschnitts davon) ablaufen, zu isolieren, nur nachdem die alten Daten einer früheren QID1 gelöscht worden sind. Globale Adressierung für DSS-Einheiten (GADSS) stellt eine Entscheidung unter Anforderern für Speicher innerhalb der DSS bereit, um Speicheranforderungen auszuwählen und Speicheranforderungen auszugeben und Inhalt zu einem Anforderer zu lenken. EXID[QID] kann einen Speicheradresseneintragungsort für einen Kontext angeben (z. B. innerhalb des Ebene-3-Cache und Seitentabellenübersetzung).
20 bildet ein beispielhaftes Betriebsmittelzuweisungsschema ab. Verschiedene Ausführungsformen können eine Arbeitslastabbildungstabelle verwenden, um ein aktuelles Tupel aktiver Zustände auf ein CFE-Cluster (z. B. C-Scheibe oder CScheibe) abzubilden, wie es einem speziellen Rechenkontext-Streamer (CCS) zugewiesen ist. Ein CCS kann als im Leerlauf (I) oder aktiv (A) betrachtet werden. Das Kennzeichen „A“ bedeutet, dass eine Arbeitslast von einem CCS auf einem Quadranten aktiv abläuft, und das Kennzeichen „I“ bedeutet, dass der CCS im Leerlauf ist (z. B. ein Quadrant führt keine Arbeitslast aus). Eine Abbildungstabelle definiert ein Tupel für einen „aktiven Zustand“ für CCSO, CCS1, CCS2 und CCS3 (jeweils gezeigt als C0, C1, C2 und C3) für 16 Fälle, obwohl andere Anzahlen von Fällen behandelt werden können. Wenn sich das Tupel des aktiven Zustands ändert, verschiebt eine Scheibenzuweisungsvorrichtung eines globalen Rechen-Frontend (CFEG) den Besitz der C-Scheibe (z. B. des Quadranten). Die Priorität eines CCS-Kontexts kann ignoriert werden, wenn der Besitz der Scheibe neu ausgeglichen wird.
Basierend auf dem Abbildungstabellensystem mit 4 C-Scheiben wird jede C-Scheibe abgebildet, um Threads von einem speziellen CCS auszuführen. Bevor irgendein Kontext zur Ausführung übermittelt wird, sind alle C-Scheiben-Quadranten in einem inaktiven Zustand. Für einen einzelnen CCS, der Kontexte zum Arbeiten bereitstellt, werden alle C-Scheiben zum Verarbeiten von Kontexten von dem einzelnen CCS zugewiesen. Die Zeile mit dem Titel „0 oder 1 aktiver CCS“ stellt ein Beispiel für die Zuweisung einer C-Scheibe zum Verarbeiten eines Kontexts von einem einzelnen CCS bereit. Eine C-Scheibe kann eine oder mehrere DSS enthalten. Beispielsweise können Kontexte von CCS0 allen C-Scheiben zugewiesen werden (gezeigt als C0), Kontexte von CCS1 können allen C-Scheiben zugewiesen werden (gezeigt als C1), und so weiter.
Die Zeile mit dem Titel „2 aktive CCS“ stellt ein Beispiel der Zuweisung von C-Scheiben zum Verarbeiten von Kontexten von zwei CCSs bereit. Beispielsweise werden Kontexte von CCS0 und CCS1 zum Verarbeiten durch C-Scheiben zugewiesen, wobei die Hälfte eines CFE-Clusters Kontexte von CCS0 ausführt (z. B. Cscheibe-0 und Cscheibe-2) und eine andere unterschiedliche Hälfte Kontexte von CCS1 ausführt (z. B. Cscheibe-1 und Cscheibe-3). Ein spezifischeres Beispiel ist, dass 8 DSSs einem CFE-Cluster zugewiesen sind und 4 DSSs zum Verarbeiten von Kontexten von CCS0 zugewiesen sind und 4 DSSs zum Verarbeiten von Kontexten von CCS1 zugewiesen sind.
Die Zeile mit dem Titel „3 oder 4 aktive CCS“ stellt ein Beispiel der Zuweisung von C-Scheiben zum Verarbeiten eines Kontexts von drei oder vier CCSs bereit. Beispielsweise werden Kontexte von CCS0, CCS1 und CCS2 zum Verarbeiten durch C-Scheiben zugewiesen, wobei ein Viertel eines CFE-Clusters Kontexte von CCS0 (z. B. Cscheibe-0) verarbeitet, ein Viertel eines CFE-Clusters Kontexte von CCS1 (z. B. Cscheibe-1) verarbeitet, und eine Hälfte eines CFE-Clusters Kontexte von CCS2 verarbeitet (z. B. Cscheibe-2 und Cscheibe-3). Ein spezifischeres Beispiel ist, dass 8 DSSs einem CFE-Cluster zugewiesen sind und 2 DSSs zum Verarbeiten von Kontexten von CCS0 zugewiesen sind, 2 DSSs zum Verarbeiten von Kontexten von CCS1 zugewiesen sind und 4 DSSs zum Verarbeiten von Kontexten von CCS2 zugewiesen sind.
Es wird darauf hingewiesen, dass die Besitzabbildungstabellen angepasst werden können, so dass irgendwelche DSSs zum Verarbeiten eines Kontexts von einem CCS ausgewählt werden können. Es wird außerdem darauf hingewiesen, dass für Zuweisungen von 3 aktiven CCSs irgendein CCS zur Zuweisung von 50 % der CFE-Cluster-Verarbeitungsbetriebsmittel gewählt werden kann. In einigen Fällen können, falls eine höhere Anzahl von Arbeitslasten von einem CCS ankommt, dann dem CCSs 50 % der Verarbeitungsbetriebsmittel zugewiesen werden, und den anderen beiden CCSs werden jeweils 25 % der Verarbeitungsbetriebsmittel zugewiesen.
Beispielsweise werden Kontexte von CCS0, CCS1, CCS2 und CCS3 zum Verarbeiten durch C-Scheiben zugewiesen, wobei ein Viertel eines CFE-Clusters Kontexte von CCS0 (z. B. Cscheibe-0) verarbeitet, ein Viertel eines CFE-Clusters Kontexte von CCS1 (z. B. Cscheibe-1) verarbeitet, ein Viertel eines CFE-Clusters Kontexte von CCS2 (z. B. Cscheibe-2) verarbeitet und ein Viertel eines CFE-Clusters Kontexte von CCS3 (z. B. Cscheibe-3) verarbeitet. Ein spezifischeres Beispiel ist, dass 8 DSSs einem CFE-Cluster zugewiesen sind und 2 DSSs zum Verarbeiten von Kontexten von CCS0 zugewiesen sind, 2 DSSs zum Verarbeiten von Kontexten von CCS1 zugewiesen sind, 2 DSSs zum Verarbeiten von Kontexten von CCS2 zugewiesen sind und 2 DSSs zum Verarbeiten von Kontexten von CCS3 zugewiesen sind. Es wird darauf hingewiesen, dass die Besitzabbildungstabellen angepasst werden können, so dass irgendwelche DSSs zum Verarbeiten eines Kontexts von einem CCS ausgewählt werden können.
Als Nächstes wird eine beispielhafte Beschreibung für eine Art und Weise zum Übertragen zwischen einem aktiven CCS-Zustand oder zu einem nicht aktiven CCS-Zustand bereitgestellt, wobei kein Kontext oder keine Arbeitslast von einem CCS unter Verwendung eines CFE-Clusters (z. B. eines Quadranten) abläuft. Wenn eine Grafikverarbeitungs-Engine von einem aktiven CCS (z. B. dem aktiven CCS0) zu zwei aktiven CCSs (z. B. CCS0 und CCS1) wechselt, werden einige der CScheiben, die Threads von CCS0 ausführten, zugewiesen, um Threads von CCS1 auszuführen. Beispielsweise wenn CCS0 der einzige aktive CCS ist, werden die C-Scheibe0 bis C-Scheibe3 zum Ausführen der Threads von CCS0 zugewiesen. Der Übergang zu ablaufenden Arbeitslasten von CCS0 könnte das Umtauschen von CScheibe-1 und CScheibe-3 von der Verwendung durch CCS0 zur Verwendung durch CCS1 beinhalten, nachdem die Arbeit, die durch CScheibe-1 und CScheibe-3 ausgeführt wird, fertiggestellt ist. Ähnlich werden, wenn von zwei aktiven CCS (CCS0 und CCS1) zu einem aktiven (CCS0) übergegangen wird, Arbeitslasten von dem CCS0 zu allen C-Scheiben verteilt.
CCS0 bis CCS3 (durch C0 - C3 repräsentiert) können unterschiedliche MMIO-Anschlüsse zur Kontextübermittlung (z. B. Arbeitsübermittlung) verwenden. In dem Beispiel, in dem C0 Kontexte von CCS0 ausführt und ein Kontext von CCS1 über einen MMIO-Anschluss übermittelt wird, kann das System darauf warten, dass die CScheiben-1 und 3 beendet sind, und dann die Verteilung eines Kontexts von CCS1 zu unteren Quadranten (CScheiben-1 und 3) erlauben. Zusätzlich kann Arbeit, die von CCS0 verteilt wird, für CScheibe-0 oder CScheibe-2 bereitgestellt werden. Nachdem die CScheibe-1 und 3 ihre Arbeitslast beenden und keine weiteren Kontexte von CCS1 verfügbar sind, können dann die vier Quadranten (z. B. CScheiben-0 bis 3) zugewiesen werden, um Arbeit von CCS9 zu behandeln. Nach dem Beenden der Arbeit von CCS0 können dann alle Quadranten inaktiv werden.
21 bildet ein Beispiel einer Verschiebung zwischen Zuständen ab. Beispielsweise sind in dem inaktiven Zustand 2102 alle CScheiben im Leerlauf. Nachdem ein CCS0 einen oder mehrere Threads verteilt, die so abgebildet werden, dass sie auf allen 4 Cscheiben (Cscheibel - Cscheibe3) ablaufen, ändert sich der Zustand auf den Zustand 2104. Eine Software-Anwendung übermittelt einen Rechen-Walker-Befehl unter Verwendung von CCS1. Basierend auf einer beispielhaften Abbildungstabelle kann der Befehl von CCS1 auf Cscheibel und Cscheibe3 ablaufen. Das CFEG hält das Verteilen von Threads von CCS0 zu Cscheibel und Cscheibe3 an. Das CFEG wartet, bis alle ablaufenden Threads von CCS0 auf Cscheibel und Cscheibe3 fertiggestellt sind, erlaubt jedoch, dass CCS0 weiterhin Threads auf Cscheibe0 und Cscheibe2 verteilt. Das CFEG leert den Schreibdatenpuffer der Cscheibel und Cscheibe 3 zu dem Cache (z. B. dem Ebene-3-Cache), um sicherzustellen, dass die Schreibdaten global zu beachten und zugänglich sind. Das CFEG macht den Zustand und die konstanten Caches von CCS0 ungültig. Bevor die Threads von CCS1 auf Cscheibel und Cscheibe3 ablaufen, werden die Zustandswerte zu den Einheiten mit gemeinsam verwendeter Funktion in Cscheibel und Cscheibe3 (z. B. DSS-Einheiten) verbreitet. Die Zustandswerte können Zeiger auf den Ort des surface_state, die Bindungstabelle und so weiter sein. Nach dem Verbreiten der Zustandswerte startet das CFEG das Verteilen von CCS1-Threads zu Cscheibel und Cscheibe3, und der Zustand ändert sich auf den Zustand 2106.
Das folgende Beispiel beschreibt einen Fall des Zustands 2110, wenn Befehle von CCS0 auf Cscheibe0 und Cscheibe2 ablaufen, während Befehle von CCS1 auf Cscheibel und Cscheibe3 ablaufen. Befehle von CCS1 sind fertiggestellt oder vorweggenommen, und Cscheibel und Cscheibe3 sind frei. Das CFEG bereitet die Cscheibel und Cscheibe3 vor, das Ablaufen von Threads für CCS0 zu starten, so dass Cscheibe0 - Cscheibe3 Threads für CCS0 im Zustand 2112 ausführen.
Es wird darauf hingewiesen, dass eine Scheibe durch einen weiteren CCS vorweggenommen ist, falls eine Anwendung angibt, dass Vorwegnahme angewandt werden soll. Beispielsweise kann Vorwegnahme enthalten zu erlauben, dass Threads auf einer Scheibe fertiggestellt werden, den Zustand und Daten zu sichern, und das Ablaufen von Threads, die dem Befehl zugeordnet sind, der Vorwegnahme aufruft. Ein CFEG kann Verteilungen zu der vorweggenommenen Scheibe anhalten und darauf warten, dass verteilte Threads fertiggestellt werden. Threads, die nicht verteilt worden sind, können auf derselben Scheibe (nachdem vorweggenommene Threads fertiggestellt sind) oder unter Verwendung einer anderen Scheibe wiederaufgenommen werden.
22 bildet ein Beispiel der zum Verarbeiten von Kontexten benötigten Zeit ab. Die vertikale Achse repräsentiert die EU-Nutzung, und der horizontale Zugang repräsentiert die Zeit. Die Beispiele zeigen die Zeit, die erforderlich ist, um die Verarbeitung eines zugeführten Kontexts fertigzustellen, für drei Szenarios: Kontextvorwegnahme, Doppel-Kontextübermittlung und Mehrfach-Kontextübermittlung. In dem Beispiel der Kontextvorwegnahme wird ein aktiv verarbeiteter Kontext ersetzt. Doppel-Kontextübermittlung ermöglicht, dass Kontexte zu Ausführungseinheiten übermittelt werden, ohne einen aktiven Kontext zu ersetzen. Mehrfach-Kontextübermittlung ermöglicht, dass ein aktiver Kontext fertiggestellt wird und die EU, die den aktiven Kontext verarbeitet hat, einen weiteren Kontext verarbeitet. Wie gezeigt ist, können die Doppel-Kontextübermittlung und Mehrfach-Kontextübermittlung ermöglichen, dass übermittelte Kontexte die Ausführung früher beginnen als in einem Fall von Kontextvorwegnahme.
23 bildet einen Beispielprozess ab. Bei 2302 wird ein Befehl von einem Streamer empfangen. Der Befehl kann von einem aus mehreren Rechenkontext-Streamern empfangen werden. Rechenkontext-Streamer können Kontexte von einer oder mehreren Anwendungen empfangen. Der Befehl kann auf einem Rechenkontext oder einem Render-Kontext basieren. Beispielsweise kann ein Rechenkontext Daten, Variablen, Bedingungen, Kernel, Befehle, Ursprungs- und Ziel-Speicherorte und andere Informationen oder Befehle, die verwendet werden, um Operationen auf Daten auszuführen, definieren. Bei 2304 kann eine Bestimmung dafür vorgenommen werden, welches Verarbeitungsbetriebsmittel zum Ausführen des Befehls zu verwenden ist. Beispielsweise kann eine Abbildungstabelle verwendet werden, um einen Befehl einem Verarbeitungsbetriebsmittel basierend auf einem Ursprung-Rechenkontext-Streamer und welcher Rechenkontext-Streamer einen aktiv ausgeführten Befehl aufweist zuzuweisen. Beispielsweise kann ein Berechnungsbetriebsmittel mehrere Verarbeitungsbetriebsmittel enthalten, und Befehle von einem speziellen Rechenkontext-Streamer können zur Ausführung durch ein spezielles Verarbeitungsbetriebsmittel zugewiesen werden. Ein Berechnungsbetriebsmittel kann eine GPU, CPU, GPGPU sein. Ein Verarbeitungsbetriebsmittel kann eines oder mehrere aus den Folgenden enthalten: eine DSS, eine Ausführungseinheit, einen Prozessor, einen Kern, eine Vorrichtung mit fester Funktion, eine im Feld programmierbare Gatter-Anordnung, eine programmierbare Logiksteuerung (PLC), eine anwendungsspezifische integrierte Schaltung (ASIC) und so weiter. Bei 2306 wird der Befehl einem bestimmten Verarbeitungsbetriebsmittel zur Ausführung zugewiesen.
Bei 2308 kann ein Bestimmen darüber vorgenommen werden, ob das zum Ausführen des Befehls bestimmte Verarbeitungsbetriebsmittel verfügbar ist, um den Befehl auszuführen. Beispielsweise ist das bestimmte Verarbeitungsbetriebsmittel verfügbar, um den Befehl auszuführen, falls das Verarbeitungsbetriebsmittel zum Ausführen des Befehls von demselben Rechenkontext-Streamer zugewiesen ist, und 2310 folgt. Beispielsweise ist das bestimmte Verarbeitungsbetriebsmittel nicht verfügbar, um den Befehl auszuführen, falls das bestimmte Verarbeitungsbetriebsmittel einen weiteren Befehl von einem anderen Rechenkontext-Streamer als demjenigen, der den Befehl bereitgestellt hat, ausführt, und 2320 folgt.
Bei 2310 wird der Befehl zum Verwenden dem bestimmten Verarbeitungsbetriebsmittel zugewiesen. Ein Befehl kann unter Verwendung eines oder mehrerer Threads repräsentiert sein. Falls beispielsweise eine Warteschlange für einen oder mehrere Threads, die einem Befehl zugeordnet sind, vorhanden ist, dann werden der eine oder die mehreren Threads der Warteschlange hinzugefügt und können der Reihe nach ausgeführt werden.
Bei 2320 ist das bestimmte Verarbeitungsbetriebsmittel so zugewiesen, dass es zugelassen ist, Befehle von einem zweiten Rechenkontext-Streamer auszuführen. Der zweite Rechenkontext-Streamer kann ein Rechenkontext-Streamer sein, der bei 2302 den Befehl bereitgestellt hat. Ein oder mehrere Threads können einen Befehl repräsentieren und zur Ausführung bereitgestellt sein. Bei 2322 wird der Schreibdatenpuffer des Verarbeitungsbetriebsmittels zu dem Cache (z. B. Ebene-3-Cache) geleert, um die Schreibdaten als zu beachten und zugänglich bereitzustellen, und der Zustand und die konstanten Caches des vorhergehenden Rechenkontext-Streamers werden ungültig gemacht. Zusätzlich werden bei 2324 die Zustandswerte des zweiten Rechenkontext-Streamers zu Einheiten für gemeinsam verwendete Funktionen des bestimmten Verarbeitungsbetriebsmittels verbreitet. Befehle in der Warteschlange können verlagert und zugewiesen werden, um durch ein weiteres Verarbeitungsbetriebsmittel ausgeführt zu werden.
Verschiedene Beispiele können unter Verwendung von Hardware-Elementen, Software-Elemente oder einer Kombination aus beiden implementiert sein. In einigen Beispielen können Hardware-Elemente Vorrichtungen, Komponenten, Prozessoren, Mikroprozessoren, Schaltungen, Schaltungselemente (z. B. Transistoren, Widerstände, Kondensatoren, Induktivitäten und so weiter), integrierte Schaltungen, ASICs, PLDs, DSPs, FPGAs, Datenspeichereinheiten, Logikgatter, Register, Halbleitervorrichtung, Chips, Mikrochips, Chipsätze und so weiter enthalten. In einigen Beispielen können Software-Elemente Software-Komponenten, Programme, Anwendungen, Computerprogramme, Anwendungsprogramme, Systemprogramme, Maschinenprogramme, Betriebssystem-Software, Middleware, Firmware, Software-Module, Routinen, Subroutinen, Funktionen, Methoden, Prozeduren, Software-Schnittstellen, APIs, Befehlssätze, Berechnungscode, Computercode, Codesegmente, Computercodesegmente, Wörter, Werte, Symbole oder irgendeine Kombination daraus enthalten. Das Bestimmen, ob ein Beispiel unter Verwendung von Hardware-Elementen und/oder Software-Elementen implementiert wird, kann in Übereinstimmung mit irgendeiner Anzahl von Faktoren variieren, wie z. B. gewünschter Berechnungsrate, Leistungspegel, Wärmetoleranzen, Verarbeitungszyklusbudget, Eingangsdatenraten, Ausgangsdatenraten, Speicherbetriebsmittel, Datenbusgeschwindigkeiten und anderen Konstruktions- oder Leistungseinschränkungen, wie es für eine gegebene Implementierung gewünscht ist. Es wird darauf hingewiesen, dass Hardware-, Firmware- und/oder Software-Elemente gemeinsam oder individuell hier als „Modul“, „Logik“, „Schaltung“ oder „Schaltungsanordnung“ bezeichnet sein können.
Einige Beispiele können unter Verwendung eines oder als ein Herstellungserzeugnis oder wenigstens ein computerlesbares Medium implementiert sein. Ein computerlesbares Medium kann ein nicht-transitorisches Speichermedium zum Speichern von Logik enthalten. In einigen Beispielen kann das nicht-transitorisch Speichermedium einen oder mehrere Typen von computerlesbaren Speichermedien enthalten, die zum Speichern elektronischer Daten fähig sind, die flüchtigen Speicher oder nichtflüchtigen Speicher, herausnehmbaren oder nicht herausnehmbaren Speicher, löschbaren oder nicht löschbaren Speicher, beschreibbaren oder wiederbeschreibbaren Speicher und so weiter enthalten. In einigen Beispielen kann die Logik verschiedene Software-Elemente enthalten, wie z. B. Software-Komponenten, Programme, Anwendungen, Computerprogramme, Anwendungsprogramme, Systemprogramme, Maschinenprogramme, Betriebssystem-Software, Middleware, Firmware, Software-Module, Routinen, Subroutinen, Funktionen, Methoden, Prozeduren, Software-Schnittstellen, API, Befehlssätze, Berechnungscode, Computercode, Codesegmente, Computercodesegmente, Wörter, Werte, Symbole oder irgendeine Kombination daraus.
Gemäß einigen Beispielen kann ein computerlesbares Medium ein nicht-transitorisches Speichermedium zum Speichern oder Halten von Anweisungen, die dann, wenn sie durch eine Maschine, eine Berechnungsvorrichtung oder ein System ausgeführt werden, die Maschine, die Berechnungsvorrichtung oder das System veranlassen, Verfahren und/oder Operationen in Übereinstimmung mit den beschriebenen Beispielen auszuführen, enthalten. Die Anweisungen können irgendeinen geeigneten Typ von Code enthalten, wie z. B. Quellcode, kompilierten Code, interpretierten Code, ausführbaren Code, statischen Code, dynamischen Code und dergleichen. Die Anweisungen können gemäß einem vordefinierten Computersprache, Art und Weise oder Syntax zum Anweisen einer Maschine, einer Berechnungsvorrichtung oder eines Systems, eine spezielle Funktion auszuführen, implementiert sein. Die Anweisungen können unter Verwendung irgendeiner geeigneten Hochsprache, Sprache niedriger Ebene, objektorientierten, visuellen, kompilierten und/oder interpretierten Programmiersprache implementiert sein.
Ein oder mehrere Aspekte wenigstens eines Beispiels können durch repräsentative Anweisungen implementiert sein, die auf wenigstens einem maschinenlesbaren Medium gespeichert sind, das verschiedene Logik innerhalb des Prozessors repräsentiert, die dann, wenn sie durch eine Maschine, eine Berechnungsvorrichtung oder ein System gelesen werden, die Maschine, die Berechnungsvorrichtung oder das System zum Herstellen von Logik zum Ausführen der hier beschriebenen Techniken veranlassen. Solche Repräsentationen, als „IP-Kerne“ bezeichnet, können auf einem greifbaren, maschinenlesbaren Medium gespeichert sein und verschiedenen Kunden oder Produktionsanlagen zum Laden in die Produktionsmaschinen, die die Logik oder den Prozessor tatsächlich herstellen, zugeführt werden.
Das Vorkommen des Ausdrucks „ein Beispiel“ bezieht sich nicht notwendigerweise immer auf dasselbe Beispiel oder dieselbe Ausführungsform. Irgendein hier beschriebener Aspekt kann mit irgendeinem anderen Aspekt oder ähnlichen Aspekt, der hier beschrieben ist, kombiniert sein, unabhängig davon, ob die Aspekte mit Bezug auf dieselbe Figur oder dasselbe Element beschrieben sind. Aus dem Aufteilen, Weglassen oder Aufnehmen von Blockfunktionen, die in den begleitenden Zeichnungen dargestellt sind, ist nicht zu schließen, dass die Hardware-Komponenten, Schaltungen, Software und/oder Elemente zum Implementieren dieser Funktionen in Ausführungsformen notwendigerweise aufgeteilt, weggelassen oder aufgenommen wären.
Einige Beispiele können unter Verwendung des Ausdrucks „gekoppelt“ oder „verbunden“ zusammen mit ihren Ableitungen beschrieben sein. Diese Begriffe sind nicht notwendigerweise als Synonyme füreinander vorgesehen. Beispielsweise können Beschreibungen unter Verwendung der Begriffe „verbunden“ und/oder „gekoppelt“ angeben, dass zwei oder mehr Elemente in direktem physikalischem oder elektrischem Kontakt miteinander sind. Der Begriff „gekoppelt“ kann jedoch auch bedeuten, dass zwei oder mehr Elemente nicht in direktem Kontakt miteinander sind, jedoch immer noch miteinander zusammenarbeiten oder zusammenwirken.
Die Begriffe „erster“, „zweiter“ und dergleichen, bezeichnen hier keine Reihenfolge, Menge oder Wichtigkeit, sondern sind vielmehr verwendet, um ein Element von einem weiteren zu unterscheiden. Der Begriff „ein“ bezeichnet hier nicht eine Einschränkung der Menge, sondern bezeichnet vielmehr das Vorhandensein wenigstens eines aus den bezeichneten Gegenständen. Der Begriff „festgestellt“, der hier mit Bezug auf ein Signal verwendet ist, bezeichnet einen Zustand des Signals, in dem das Signal aktiv ist und der durch Anlegen irgendeines Logikpegels, entweder logisch 0 oder logisch 1, an das Signal erreicht werden kann. Die Begriffe „folgen“ oder „nach“ können sich auf unmittelbar nachfolgend oder nachfolgend nach einem oder einigen anderen Ereignis oder Ereignissen beziehen. Andere Reihenfolgen von Schritten können gemäß alternativen Ausführungsformen ebenfalls ausgeführt werden. Darüber hinaus können zusätzliche Schritte hinzugefügt oder entfernt werden, abhängig von den speziellen Anwendungen. Irgendeine Kombination von Änderungen kann verwendet werden, und ein normaler Fachmann, der Nutzen aus dieser Offenbarung ziehen kann, würde die vielen Variationen, Modifikationen und alternativen Ausführungsformen davon verstehen.
Disjunktive Ausdrucksweise wie z. B. der Ausdruck „wenigstens eines aus X, Y oder Z“, sofern nicht spezifisch anderes festgestellt, ist anderweitig in dem Kontext so zu verstehen, wie sie im Allgemeinen verwendet ist, um zu präsentieren, dass irgendein Gegenstand, Begriffe usw. entweder X, Y oder Z oder irgendeine Kombination daraus (z. B. X, Y und/oder Z) sein kann. Somit ist eine solche disjunktive Ausdrucksweise nicht allgemein vorgesehen zu implizieren, und sollte nicht implizieren, dass spezielle Ausführungsformen erfordern, dass wenigstens eines aus X, wenigstens eines aus Y oder wenigstens eines aus Z jeweils vorhanden ist. Zusätzlich sollte konjunktive Ausdrucksweise, wie z. B. der Ausdruck „wenigstens eines aus X, Y und Z“, sofern nicht spezifisch anders festgestellt, ebenfalls so verstanden werden, dass sie X, Y, Z oder irgendeine Kombination daraus bedeuten, einschließlich „X, Y und/oder Z“.

Claims

Einrichtung, die Folgendes umfasst: eine Speichervorrichtung; eine Grafikverarbeitungseinheit (GPU), die mehrere Ausführungseinheiten enthält; und einen Thread-Scheduler zum Verteilen wenigstens eines Thread zur Ausführung durch wenigstens einen Abschnitt der GPU, wobei der Thread-Scheduler dient zum: in Reaktion auf den Empfang eines ersten Befehls aus einer ersten Quelle, Zuweisen von Ausführungseinheiten zum Ausführen eines oder mehrerer dem ersten Befehl zugeordneten Threads und in Reaktion auf den Empfang eines zweiten Befehls aus einer zweiten Quelle während ein dem ersten Befehl zugeordneter Thread ausgeführt wird, Zuweisen eines ersten Abschnitts der Ausführungseinheiten zum Ausführen von dem ersten Befehl zugeordneten Threads und Zuweisen eines zweiten Abschnitts der Ausführungseinheiten zum Ausführen von dem zweiten Befehl zugeordneten Threads.
Einrichtung nach Anspruch 1, wobei der Thread-Scheduler in Reaktion auf den Empfang eines zweiten Befehls aus einer zweiten Quelle während ein dem ersten Befehl zugeordneter Thread ausgeführt wird, dient zum: Erlauben, dass einer oder mehrere dem ersten Befehl zugeordnete Threads, die auf dem zweiten Abschnitt ausgeführt werden, fertiggestellt werden, und Zuweisen eines oder mehrerer dem zweiten Befehl zugeordneter Threads zur Ausführung auf dem zweiten Abschnitt der Ausführungseinheiten.
Einrichtung nach Anspruch 2, wobei der Thread-Scheduler dient zum: Leeren eines Schreibdatenpuffers, der dem zweiten Abschnitt der Ausführungseinheiten zugeordnet ist und der Daten speichert, von der fertiggestellten Ausführung des einen oder der mehreren dem ersten Befehl zugeordneten Threads zu einem Cache und Ungültigmachen von Zustand und konstanten Caches, die dem zweiten Abschnitt der Ausführungseinheiten zugeordnet sind, der die Ausführung des einen oder der mehreren dem ersten Befehl zugeordneten Threads fertiggestellt hat.
Einrichtung nach Anspruch 1, wobei der Thread-Scheduler dient zum: in Reaktion auf die Detektion der Fertigstellung eines oder mehrerer dem zweiten Befehl zugeordneten Threads unter Verwendung des zweiten Abschnitts der Ausführungseinheiten und eines oder mehrerer dem ersten Befehl zugeordneten nicht ausgeführten Threads, Zuweisen des zweiten Abschnitts der Ausführungseinheiten zum Ausführen eines oder mehrerer dem ersten Befehl zugeordneten nicht ausgeführten Threads.
Einrichtung nach Anspruch 1, wobei der Thread-Scheduler dient zum: in Reaktion auf die Detektion der Fertigstellung eines oder mehrerer dem ersten Befehl zugeordneten Threads unter Verwendung des ersten Abschnitts der Ausführungseinheiten und eines oder mehrerer dem zweiten Befehl zugeordneten nicht ausgeführten Threads, Zuweisen des ersten Abschnitts der Ausführungseinheiten zum Ausführen eines oder mehrerer dem zweiten Befehl zugeordneten nicht ausgeführten Threads.
Einrichtung nach Anspruch 1, wobei der Thread-Scheduler dient zum: in Reaktion auf den Empfang eines oder mehrerer einem dritten Befehl aus einer dritten Quelle zugeordneten Threads, Zuweisen eines Abschnitts der Ausführungseinheiten zum Ausführen eines oder mehrerer dem dritten Befehl zugeordneten Threads.
Einrichtung nach Anspruch 1, die eine Abbildungstabelle zum Identifizieren eines Abschnitts der GPU zum Ausführen einer Arbeitslast aus mehreren Quellen umfasst, wobei die mehreren Quellen wenigstens die erste Quelle, die zweite Quelle, eine dritte Quelle und eine vierte Quelle umfassen und wobei der Thread-Scheduler dazu dient, die Abbildungstabelle zu verwenden, um einen Abschnitt der GPU zum Ausführen eines einem Befehl aus der ersten Quelle, der zweiten Quelle, der dritten Quelle oder der vierten Quelle zugeordneten Threads zu identifizieren.
Einrichtung nach einem der Ansprüche 1-7, die eines oder mehrere aus dem Folgenden umfasst: eine Allzweck-Grafikverarbeitungseinheit oder eine zentrale Verarbeitungseinheit.
Verfahren, das Folgendes umfasst: Empfangen eines Befehls aus einer ersten Quelle zur Ausführung unter Verwendung einer Grafikverarbeitungseinheit; basierend darauf, dass die erste Quelle eine aktuell einzige Quelle für Befehle für die Grafikverarbeitungseinheit ist, Zuweisen der Grafikverarbeitungseinheit zum Ausführen eines oder mehrerer auf dem Befehl aus der ersten Quelle basierenden Threads; Empfangen eines ersten Befehls aus einer zweiten Quelle zur Ausführung unter Verwendung der Grafikverarbeitungseinheit; Zuweisen eines ersten Abschnitts der Grafikverarbeitungseinheit zur Ausführung eines oder mehrerer auf Befehlen aus der ersten Quelle basierenden Threads; Erlauben, dass ein zweiter Abschnitt der Grafikverarbeitungseinheit die Ausführung eines oder mehrerer zugewiesener Threads aus der ersten Quelle fertigstellt; und Zuweisen des zweiten Abschnitts der Grafikverarbeitungseinheit zur Ausführung eines oder mehrerer auf Befehlen aus der zweiten Quelle basierenden Threads.
Verfahren nach Anspruch 9, das Folgendes umfasst: basierend auf der Fertigstellung eines oder mehrerer dem ersten Befehl aus der zweiten Quelle zugeordneten Threads und wenigstens einem verfügbaren auf einem Befehl aus der ersten Quelle basierenden Thread, Zuweisen des zweiten Abschnitts zur Ausführung wenigstens eines auf einem Befehl aus der ersten Quelle basierenden Thread.
Verfahren nach Anspruch 9, das Folgendes umfasst: Empfangen eines ersten Befehls aus einer dritten Quelle zur Ausführung unter Verwendung der Grafikverarbeitungseinheit; Erlauben, dass ein dritter Abschnitt der Grafikverarbeitungseinheit die Ausführung eines auf einem Befehl aus der ersten Quelle basierenden verteilten Thread fertigstellt, wobei der dritte Abschnitt einen Teil des ersten Abschnitts und einen Teil des zweiten Abschnitts enthält; und Zuweisen des dritten Abschnitts der Grafikverarbeitungseinheit zur Ausführung eines oder mehrerer auf dem ersten Befehl aus der dritten Quelle basierenden Threads.
Verfahren nach einem der Ansprüche 9-11, das Folgendes umfasst: Verwenden einer Abbildungstabelle zum Zuweisen eines Abschnitts der Grafikverarbeitungseinheit zu einer Quelle.
System, das Folgendes umfasst: wenigstens einen Speicher; eine Befehlsverteilungs-Engine; und wenigstens eine Grafikverarbeitungseinheit, die mit dem wenigstens einen Speicher und der Befehlsverteilungs-Engine kommunikationstechnisch gekoppelt ist, wobei: die Befehlsverteilungs-Engine dient zum: Empfangen einer Anforderung zum Ausführen wenigstens eines Befehls aus einer ersten Quelle; Empfangen einer Anforderung zum Ausführen wenigstens eines Befehls aus einer zweiten Quelle; Zuweisen eines ersten Abschnitts der Grafikverarbeitungseinheit zur Ausführung wenigstens eines einem Befehl aus der ersten Quelle zugeordneten Thread; und Zuweisen eines zweiten Abschnitts der Grafikverarbeitungseinheit zur Ausführung wenigstens eines einem Befehl aus der zweiten Quelle zugeordneten Thread.
System nach Anspruch 13, wobei die Befehlsverteilungs-Engine dient zum: in Reaktion auf die Fertigstellung von auf Befehlen aus der ersten Quelle basierenden Threads und wenigstens einen verfügbaren auf einem Befehl aus der zweiten Quelle basierenden Thread, Zuweisen des ersten Abschnitts zur Ausführung des wenigstens einen verfügbaren auf einem Befehl aus der zweiten Quelle basierenden Thread.
System nach einem der Ansprüche 13 und 14, wobei die Befehlsverteilungs-Engine dient zum: in Reaktion auf den Empfang eines oder mehrerer einem dritten Befehl aus einer dritten Quelle zugeordneten Threads, Zuweisen eines Abschnitts der Ausführungseinheiten zum Ausführen eines oder mehrerer dem dritten Befehl zugeordneten Threads.