DE102022119733A1 - Sammeln von nutzdaten aus beliebigen registern für sende-nachrichten in einer grafikumgebung - Google Patents

Sammeln von nutzdaten aus beliebigen registern für sende-nachrichten in einer grafikumgebung Download PDF

Info

Publication number
DE102022119733A1
DE102022119733A1 DE102022119733.6A DE102022119733A DE102022119733A1 DE 102022119733 A1 DE102022119733 A1 DE 102022119733A1 DE 102022119733 A DE102022119733 A DE 102022119733A DE 102022119733 A1 DE102022119733 A1 DE 102022119733A1
Authority
DE
Germany
Prior art keywords
graphics
send
processor
memory
instruction
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102022119733.6A
Other languages
English (en)
Inventor
Supratim Pal
Chandra Gurram
Fan-Yin Tzeng
Subramaniam Maiyuran
Guei-Yuan Lueh
Timothy R. Bauer
Vikranth Vemulapalli
Wei-Yu Chen
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intel Corp
Original Assignee
Intel Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel Corp filed Critical Intel Corp
Publication of DE102022119733A1 publication Critical patent/DE102022119733A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30098—Register arrangements
    • G06F9/3012—Organisation of register space, e.g. banked or distributed register file
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3836—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution
    • G06F9/3851—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution from multiple instruction streams, e.g. multistreaming
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003—Arrangements for executing specific machine instructions
    • G06F9/30007—Arrangements for executing specific machine instructions to perform operations on data operands
    • G06F9/30032—Movement instructions, e.g. MOVE, SHIFT, ROTATE, SHUFFLE
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003—Arrangements for executing specific machine instructions
    • G06F9/30007—Arrangements for executing specific machine instructions to perform operations on data operands
    • G06F9/30036—Instructions to perform operations on packed data, e.g. vector, tile or matrix operations
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30098—Register arrangements
    • G06F9/30105—Register structure
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30145—Instruction analysis, e.g. decoding, instruction word fields
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3824—Operand accessing
    • G06F9/3826—Bypassing or forwarding of data results, e.g. locally between pipeline stages or within a pipeline stage
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3854—Instruction completion, e.g. retiring, committing or graduating
    • G06F9/3858—Result writeback, i.e. updating the architectural state or memory
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3885—Concurrent instruction execution, e.g. pipeline or look ahead using a plurality of independent parallel functional units
    • G06F9/3887—Concurrent instruction execution, e.g. pipeline or look ahead using a plurality of independent parallel functional units controlled by a single instruction for multiple data lanes [SIMD]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T1/00—General purpose image data processing
    • G06T1/20—Processor architectures; Processor configuration, e.g. pipelining

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Mathematical Physics (AREA)
  • Multimedia (AREA)
  • Image Processing (AREA)
  • Image Generation (AREA)

Abstract

Offenbart wird eine Einrichtung zum Ermöglichen des Sammelns von Nutzdaten aus beliebigen Registern für Sende-Nachrichten in einer Grafikumgebung. Die Einrichtung schließt Verarbeitungsressourcen ein, die eine Ausführungsschaltlogik zum Empfangen einer Sende-Sammel-Nachrichten-Anweisung umfassen, die eine Anzahl von Registern zum Zugreifen auf eine Sende-Nachricht identifiziert und IDs mehrerer einzelner Register entsprechend der Anzahl von Registern identifiziert; Decodieren einer ersten Phase der Sende-Sammel-Nachrichten-Anweisung; basierend auf dem Decodieren der ersten Phase, Veranlassen, dass eine zweite Phase der Sende-Sammel-Nachrichten-Anweisung eine Anweisungsdecodierungsstufe umgeht; und Versenden der ersten Phase, gefolgt vom Versenden der zweiten Phase an eine Sende-Pipeline. Die Einrichtung kann auch ein sofortiges Verschieben der IDs der mehreren einzelnen Register in ein Architekturregister der Ausführungsschaltlogik durchführen und einen Zeiger auf das Architekturregister in der Sende-Sammel-Nachrichten-Anweisung einschließen.

Description

  • GEBIET
  • Dieses Dokument bezieht sich allgemein auf Datenverarbeitung und insbesondere auf Datenverarbeitung über eine Universal-Grafikverarbeitungseinheit.
  • HINTERGRUND
  • Die aktuelle parallele Grafikdatenverarbeitung beinhaltet Systeme und Verfahren, die entwickelt wurden, um spezifische Operationen an Grafikdaten auszuführen, wie beispielsweise lineare Interpolation, Tessellation, Rasterisierung, Texturabbildung, Tiefentest usw. Herkömmlicherweise verwenden Grafikprozessoren Festfunktions-Recheneinheiten, um Grafikdaten zu verarbeiten. In jüngster Zeit wurden Teile von Grafikprozessoren jedoch programmierbar gemacht, wodurch ermöglicht wurde, dass solche Prozessoren eine größere Vielfalt an Operationen zur Verarbeitung von Vertex- und Fragmentdaten unterstützen.
  • Um die Leistungsfähigkeit weiter zu verbessern, implementieren Grafikprozessoren typischerweise Verarbeitungstechniken wie Pipelining, bei denen versucht wird, parallel so viele Grafikdaten wie möglich über die verschiedenen Teile der Grafik-Pipeline hinweg zu verarbeiten. Parallelgrafikprozessoren mit SIMT-Architekturen (SIMT: Single Instruction, Multiple Thread) sind dafür ausgelegt, das Ausmaß der Parallelverarbeitung in der Grafik-Pipeline zu maximieren. In einer SIMT-Architektur versuchen Gruppen paralleler Threads, Programmanweisungen so oft wie möglich synchron zusammen auszuführen, um eine Verarbeitungseffizienz zu erhöhen. Ein allgemeiner Überblick über Soft- und Hardware für SIMT-Architekturen findet sich bei Shane Cook, CUDA-Programming Kapitel 3, Seiten 37-51 (2013).
  • Parallele Rendering-Grafikarchitekturen nutzen Kommunikationen zwischen den Ausführungsressourcen (z. B. EUs) und den gemeinsam genutzten Funktionen und/oder Festfunktions-Pipelines, um effiziente parallele Renderberechnungen zu ermöglichen. Solche Kommunikationen zwischen den Ausführungsressourcen und den gemeinsam genutzten Funktionen und/oder festen Funktionen können über Pakete von Informationen erreicht werden, die Nachrichten genannt werden. Eine Nachrichtenübertragung wird unter Verwendung von Sende-Nachrichten-Anweisungen angefordert. Die aktuellen Sende-Nachrichten-Anweisungen erfordern, dass sich die Nutzdaten der Anweisung in zusammenhängenden Registern befindet. Bei herkömmlichen Ansätzen nutzt die Ausführungsressource (z. B. EU) zum Beispiel eine Sende-Nachrichten-Anweisung (z. B. send- oder sendc-Anweisung (wobei sich sende auf eine bedingte Sende-Nachricht bezieht), und diese Sende-Nachrichten-Anweisungen nehmen einen Satz von GRF-Registern und senden diesen Satz von GRF-Registern an eine gemeinsam genutzte Funktion (oder feste Funktion).
  • Figurenliste
  • Für ein ausführliches Verständnis der Art und Weise der Merkmale der Ausführungsformen kann eine genauere Beschreibung der oben kurz zusammengefassten Ausführungsformen unter Bezugnahme auf Ausführungsformen erhalten werden, von denen manche in den beigefügten Zeichnungen veranschaulicht sind. Es sei jedoch angemerkt, dass die beigefügten Zeichnungen nur typische Ausführungsformen veranschaulichen und daher nicht als ihren Schutzumfang einschränkend anzusehen sind.
    • 1 ist ein Blockdiagramm, das ein Computersystem veranschaulicht, das zum Implementieren eines oder mehrerer Aspekte der hierin beschriebenen Ausführungsformen konfiguriert ist;
    • 2A-2D veranschaulichen Parallelprozessorkomponenten;
    • 3A-3C sind Blockdiagramme von Grafikmultiprozessoren und multiprozessorbasierten GPUs;
    • 4A-4F veranschaulichen eine beispielhafte Architektur, in der mehrere GPUs kommunikativ mit mehreren Mehrkernprozessoren gekoppelt sind;
    • 5 veranschaulicht eine Grafikverarbeitungs-Pipeline;
    • 6 veranschaulicht einen Maschinenlernsoftwarestapel;
    • 7 veranschaulicht eine Universal-Grafikverarbeitungseinheit;
    • 8 veranschaulicht ein Multi-GPU-Rechensystem;
    • 9A-9B veranschaulichen Schichten beispielhafter tiefer neuronaler Netzwerke;
    • 10 veranschaulicht ein beispielhaftes rekurrentes neuronales Netzwerk;
    • 11 veranschaulicht Training und Einsatz eines tiefen neuronalen Netzwerks;
    • 12A ist ein Blockdiagramm, das verteiltes Lernen veranschaulicht;
    • 12B ist ein Blockdiagramm, das eine programmierbare Netzwerkschnittstelle und eine Datenverarbeitungseinheit veranschaulicht;
    • 13 veranschaulicht ein beispielhaftes Inferenzierungssystem auf einem Chip (SOC), das zum Durchführen einer Inferenzierung unter Verwendung eines trainierten Modells geeignet ist;
    • 14 ist ein Blockdiagramm eines Verarbeitungssystems;
    • 15A-15C veranschaulichen Rechensysteme und Grafikprozessoren;
    • 16A-16C veranschaulichen Blockdiagramme zusätzlicher Grafikprozessor- und Rechenbeschleunigerarchitekturen;
    • 17 ist ein Blockdiagramm einer Grafikverarbeitungs-Engine eines Grafikprozessors;
    • 18A-18B veranschaulichen eine Thread-Ausführungslogik, die ein Array von Verarbeitungselementen beinhaltet, die in einem Grafikprozessorkern eingesetzt werden;
    • 19 veranschaulicht eine zusätzliche Ausführungseinheit;
    • 20 ist ein Blockdiagramm, das die Anweisungsformate eines Grafikprozessors veranschaulicht;
    • 21 ist ein Blockdiagramm einer zusätzlichen Grafikprozessorarchitektur;
    • 22A-22B veranschaulichen ein Befehlsformat und eine Befehlssequenz eines Grafikprozessors;
    • 23 veranschaulicht eine beispielhafte Grafiksoftwarearchitektur für ein Datenverarbeitungssystem;
    • 24A ist ein Blockdiagramm, das ein IP-Kern-Entwicklungssystem veranschaulicht;
    • 24B veranschaulicht eine Querschnittsseitenansicht einer integrierte-Schaltungs-Package-Anordnung;
    • 24C veranschaulicht eine Package-Anordnung, die mehrere Einheiten von Hardware-Logik-Chiplets beinhaltet, die mit einem Substrat (z. B. Basis-Die) verbunden sind;
    • 24D veranschaulicht eine Package-Anordnung, die austauschbare Chiplets beinhaltet;
    • 25 ist ein Blockdiagramm, das eine beispielhafte integrierte System-on-Chip-Schaltung veranschaulicht;
    • 26a-26B sind Blockdiagramme, die beispielhafte Grafikprozessoren zur Verwendung in einem SoC veranschaulichen;
    • 27 ist ein Blockdiagramm, das einen beispielhaften Integrierte-Schaltung-Grafikprozessor mit einer Ausführungsressource zum Bereitstellen einer Sende-Sammel-Nachrichten-Anweisung zum Sammeln von Nutzdaten aus beliebigen Registern für eine Sende-Nachricht in einer Grafikumgebung gemäß Ausführungsformen veranschaulicht.
    • 28A veranschaulicht einen Satz von Anweisungen, der von einer Verarbeitungseinheit ausführbar ist, gemäß hierin beschriebenen Ausführungsformen
    • 28B veranschaulicht einen Programmcode-Kompilierungsprozess gemäß einer Ausführungsform.
    • 29 ist ein Flussdiagramm, das eine Ausführungsform eines Verfahrens zum Ausführen einer Anweisung zum Durchführen des Sammelns von Nutzdaten aus beliebigen Registern für Senden-Nachrichten in einer Grafikumgebungveranschaulicht.
    • 30 ist ein Flussdiagramm, das eine Ausführungsform eines Verfahrens zum Planen einer Sende-Sammel-Nachricht veranschaulicht, die Nutzdaten aus beliebigen Registern in einer Grafikumgebung sammelt.
    • 31 ist ein Flussdiagramm, das eine Ausführungsform eines Verfahrens zum Planen einer Sende-Sammel-Nachricht unter Verwendung eines Architekturregisters veranschaulicht, um Nutzdaten aus beliebigen Registern in einer Grafikumgebung zu sammeln.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Implementierungen betreffen das Sammeln von Nutzdaten aus beliebigen Registern für Sende-Nachrichten in einer Grafikumgebung, wie in einer Grafikverarbeitungseinheit (GPU).
  • Eine Grafikverarbeitungseinheit (GPU) ist kommunikativ mit Host-/Prozessorkernen gekoppelt, um beispielsweise Grafikoperationen, Maschinenlernoperationen, Musteranalyseoperationen und/oder verschiedene Universal-GPU(GPGPU)-Funktionen zu beschleunigen. Die GPU kann über einen Bus oder ein anderes Interconnect (z. B. ein Hochgeschwindigkeits-Interconnect wie PCIe oder NVLink) kommunikativ mit dem Hostprozessor/den Kernen verbunden sein. Alternativ kann die GPU auf demselben Package oder Chip wie die Kerne integriert sein und über einen internen Prozessorbus bzw. ein internes Interconnect (d. h. innerhalb des Package oder Chips) kommunikativ mit den Kernen gekoppelt sein. Unabhängig von der Art und Weise, auf welche die GPU verbunden ist, können die Prozessorkerne der GPU Arbeit in Form von Sequenzen von Befehlen/Anweisungen zuweisen, die in einem Arbeitsdeskriptor enthalten sind. Die GPU verwendet dann eine dedizierte Schaltlogik/Logik zum effizienten Verarbeiten dieser Befehle/Anweisungen.
  • In der folgenden Beschreibung werden zahlreiche spezifische Details dargelegt, um ein gründlicheres Verständnis bereitzustellen. Fachleute können jedoch erkennen, dass die hierin beschriebenen Ausführungsformen ohne eine oder mehrere dieser spezifischen Einzelheiten in die Praxis umgesetzt werden können. In anderen Fällen wurden wohl bekannte Merkmale nicht beschrieben, um das Verschleiern von Details der vorliegenden Ausführungsformen zu vermeiden.
  • Systemübersicht
  • 1 ist ein Blockdiagramm, das ein Rechensystem 100 veranschaulicht, das konfiguriert ist, um einen oder mehrere Aspekte der hierin beschriebenen Ausführungsformen zu implementieren. Das Rechensystem 100 weist ein Verarbeitungssubsystem 101 mit einem oder mehreren Prozessor(en) 102 und einem Systemspeicher 104 auf, die über einen Verbindungspfad kommunizieren, der einen Speicherhub 105aufweisen kann. Der Speicherhub 105 kann eine separate Komponente innerhalb einer Chipsatzkomponente sein oder kann in dem einen oder den mehreren Prozessor(en) 102integriert sein. Der Speicherhub 105 ist über eine Kommunikationsverbindung 106mit einem E/A-Subsystem 111 gekoppelt. Das E/A-Subsystem 111 beinhaltet einen E/A-Hub 107 , der ermöglichen kann, dass das Rechensystem 100 eine Eingabe von einer oder mehreren Eingabevorrichtungen 108empfängt. Außerdem kann der E/A-Hub 107 ermöglichen, dass eine Anzeigesteuerung, die in dem einen oder den mehreren Prozessor(en) 102enthalten sein kann, einer oder mehreren Anzeigevorrichtung(en) 110A Ausgabenbereitstellt. In einer Ausführungsform können die eine oder die mehreren Anzeigevorrichtungen 110A, die mit dem E/A-Hub 107 gekoppelt sind, eine lokale, interne oder eingebettete Anzeigevorrichtung beinhalten.
  • Das Verarbeitungssubsystem 101 beinhaltet zum Beispieleinen oder mehrere Parallelprozessoren 112 , die über einen Bus oder eine andere Kommunikationsverbinddung 113 an den Speicherhub 105 gekoppelt sind. Die Kommunikationsverbindung 113 kann eine von einer beliebigen Anzahl von auf standardbasierten Kommunikationsverbindungstechnologien oder -Protokollen sein, wie, jedoch ohne Einschränkung, PCI Express, oder kann eine anbieterspezifische Kommunikationsschnittstelle oder ein Kommunikations-Fabric sein. Der eine oder die mehreren Parallelprozessoren 112 können ein rechnerisch fokussiertes Parallel- oder Vektorverarbeitungssystem bilden, das eine große Anzahl von Verarbeitungskernen und/oder Verarbeitungsclustern beinhalten kann, wie einen MIC-Prozessor (MIC: Many Integrated Core). Zum Beispiel bilden der eine oder die mehreren Parallelprozessoren 112 ein Grafikverarbeitungssubsystem, das Pixel an eine der einen oder mehreren Anzeigevorrichtungen 110A ausgeben kann, die über den E/A-Hub 107 gekoppelt sind. Der eine oder die mehreren Parallelprozessoren 112 können auch eine Anzeigesteuerung und eine Anzeigeschnittstelle (nicht dargestellt) aufweisen, um eine direkte Verbindung mit einer oder mehreren Anzeigevorrichtungen 110B zu ermöglichen.
  • Innerhalb des E/A-Subsystems 111 kann eine Systemspeicherungseinheit 114 eine Verbindung mit dem E/A-Hub 107 herstellen, um einen Speicherungsmechanismus für das Rechensystem 100bereitzustellen. Ein E/A-Schalter 116 kann verwendet werden, um einen Schnittstellenmechanismus bereitzustellen, um Verbindungen zwischen dem E/A-Hub 107 und anderen Komponenten wie einem Netzwerkadapter 118 und/oder einem drahtlosen Netzwerkadapter 119, die in die Plattform integriert sein können, und verschiedenen anderen Vorrichtungen zu ermöglichen, die über eine oder mehrere Add-in-Vorrichtung(en) 120hinzugefügt werden können. Die eine oder die mehreren Add-in-Vorrichtungen 120 können beispielsweise auch eine oder mehrere externe Grafikprozessorvorrichtungen, Grafikkarten und/oder Rechenbeschleuniger beinhalten. Der Netzwerkadapter 118 kann ein Ethernet-Adapter oder ein anderer drahtgebundener Netzwerkadapter sein. Der Drahtlosnetzwerkadapter 119 kann eine oder mehrere einer Wi-Fi-, Bluetooth-, Nahfeldkommunikation (NFC) oder eine andere Netzwerkvorrichtung beinhalten, die eine oder mehrere drahtlose Funkvorrichtungen aufweist.
  • Das Rechensystem 100 kann andere Komponenten beinhalten, die nicht explizit gezeigt sind, darunter USB- oder andere Port-Verbindungen, optische Speicherungslaufwerke, Videoaufnahmevorrichtungen und dergleichen, die auch mit dem E/A-Hub 107verbunden sein können. Kommunikationswege, die die verschiedenen Komponenten in 1 miteinander verbinden, können unter Verwendung beliebiger geeigneter Protokolle implementiert werden, wie PCI (Peripheral Component Interconnect)-basierte Protokolle (z. B. PCI-Express) oder beliebige andere Bus- oder Punkt-zu-Punkt-Kommunikationsschnittstellen und/oder Protokolle, wie das NVLink-Hochgeschwindigkeits-Interconnect, Compute Express Link™ (CXL™) (z. B. CXL.mem), Infinity Fabric (IF), Ethernet (IEEE 802,3), Remote Direct Memory Access (RDMA), InfiniBand, Internet Wide Area RDMA Protocol (iWARP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Quick UDP Internet Connections (QUIC), RDMA over Converged Ethernet (RoCE), Intel QuickPath Interconnect (QPI), Intel Ultra Path Interconnect (UPI), Intel On-Chip System Fabric (IOSF), OmniPath, HyperTransport, Advanced Microcontroller Bus Architecture (AMBA) Interconnect, OpenCAPI, Gen-Z, Cache Coherent Interconnect for Accelerators (CCIX), 3GPP Long Term Evolution (LTE) (4G), 3GPP 5G und Variationen davon, oder in der in der Technik bekannte drahtgebundene oder drahtlose Verbindungsprotokolle. In manchen Beispielen können Daten unter Verwendung eines Protokolls, wie Non-Volatile-Memory-Express(NVMe)-over-Fabrics (NVMe-oF) oder NVMe, in virtualisierte Speicherungsknoten kopiert oder gespeichert werden.
  • Der eine oder die mehreren Parallelprozessoren 112 können eine Schaltlogik integrieren, die für Grafik- und Videoverarbeitung optimiert ist, einschließlich beispielsweise einer Videoausgabeschaltlogik, und eine Grafikverarbeitungseinheit (GPU) bildet. Alternativ oder zusätzlich können der eine oder die mehreren Parallelprozessor(en) 112 eine Schaltlogik umfassen, die zur Universalverarbeitung optimiert ist, während die zugrundeliegende Rechenarchitektur erhalten bleibt, die hier ausführlicher beschrieben wird. Komponenten des Rechensystems 100 können mit einem oder mehreren anderen Systemelementen auf einer einzigen integrierten Schaltung integriert sein. Zum Beispiel können der eine oder die mehreren Parallelprozessor(en) 112, Speicher-Hub 105, Prozessor(en) 102 und E/A-Hub 107 in einer integrierten System-on-Chip(SoC)-Schaltung integriert sein. Alternativ können die Komponenten des Rechensystems 100 in einem einzigen Package integriert sein, um eine System-in-Package-(SIP)-Konfiguration zu bilden. In einer Ausführungsform kann zumindest ein Teil der Komponenten des Rechensystems 100 in einem Multi-Chip-Modul (MCM) integriert sein, das mit anderen Multi-Chip-Modulen zu einem modularen Rechensystem verschaltet sein kann.
  • Es versteht sich, dass das hier gezeigte Rechensystem 100 veranschaulichend ist und dass Variationen und Modifikationen möglich sind. Die Verbindungstopologie, einschließlich der Anzahl und Anordnung von Brücken, der Anzahl von Prozessor(en) 102und der Anzahl von Parallelprozessor(en) 112, kann wie gewünscht modifiziert werden. Zum Beispiel kann der Systemspeicher 104 direkt mit dem einen oder den mehreren Prozessoren 102 statt über eine Brücke verbunden sein, während andere Vorrichtungen über den Speicherhub 105 und den einen oder die mehreren Prozessoren 102 mit dem Systemspeicher 104kommunizieren. In anderen alternativen Topologien ist bzw. sind der bzw. die Parallelprozessor(en) 112mit dem E/A-Hub 107 oder direkt mit einem des einen bzw. der mehreren Prozessor(en) 102und nicht mit dem Speicherhub 105verbunden. In anderen Ausführungsformen können der E/A-Hub 107 und der Speicherhub 105 in einem einzigen Chip integriert sein. Es ist auch möglich, dass zwei oder mehr Sätze von Prozessor(en) 102 über mehrere Sockets angeschlossen sind, die mit zwei oder mehr Instanzen des /der Parallelprozessors(en) 112 koppeln können.
  • Manche der hierin gezeigten speziellen Komponenten sind optional und müssen nicht in allen Implementierungen des Rechensystems 100enthalten sein. Zum Beispiel kann eine beliebige Anzahl von Add-in-Karten oder Peripheriegeräten unterstützt werden, oder einige Komponenten können entfernt sein. Darüber hinaus können einige Architekturen eine andere Terminologie für Komponenten verwenden, die denen ähnlich sind, die in 1 veranschaulicht sind. Zum Beispiel kann der Speicher-Hub 105 in manchen Architekturen als eine Northbridge bezeichnet werden, während der E/A-Hub 107 als eine Southbridge bezeichnet werden kann.
  • 2A veranschaulicht einen Parallelprozessor 200. Der Parallelprozessor 200 kann eine GPU, GPGPU oder dergleichen sein, wie hierin beschrieben. Die verschiedenen Komponenten des Parallelprozessors 200 können unter Verwendung einer oder mehrerer Integrierter-Schaltungs-Vorrichtungen implementiert werden, wie programmierbarer Prozessoren, anwendungsspezifischer integrierter Schaltungen (ASICs) oder feldprogrammierbarer Gate-Arrays (FPGA). Der veranschaulichte Parallelprozessor 200 kann einer oder mehrere der Parallelprozessor(en) 112 sein, die in 1 gezeigt sind.
  • Der Parallelprozessor 200 weist eine Parallelverarbeitungseinheit 202auf. Die Parallelverarbeitungseinheit weist eine E/A-Einheit 204 auf, die die Kommunikation mit anderen Vorrichtungen, darunter andere Instanzen der Parallelverarbeitungseinheit 202, ermöglicht. Die E/A-Einheit 204 kann direkt mit anderen Vorrichtungen verbunden sein. Zum Beispiel stellt die E/A-Einheit 204 über die Verwendung einer Hub- oder Switch-Schnittstelle, wie des Speicherhubs 105, eine Verbindung mit anderen Vorrichtungen her. Die Verbindungen zwischen dem Speicherhub 105 und der E/A-Einheit 204 bilden eine Kommunikationsverbindung 113. Innerhalb der Parallelverarbeitungseinheit 202 ist die E/A-Einheit 204 mit einer Hostschnittstelle 206 und einer Speicher-Crossbar 216verbunden, wobei die Hostschnittstelle 206 Befehle zum Durchführen von Verarbeitungsoperationen empfängt und die Speicher-Crossbar 216 Befehle zum Durchführen von Speicheroperationen empfängt.
  • Wenn die Hostschnittstelle 206 einen Befehlspuffer über die E/A-Einheit 204 empfängt, kann die Hostschnittstelle 206 Arbeitsoperationen anweisen, diese Befehle an ein Frontend 208durchzuführen. In einer Ausführungsform ist das Frontend 208 mit einem Scheduler 210gekoppelt, der konfiguriert ist, um Befehle oder andere Arbeitselemente an ein Verarbeitungsclusterarray 212zu verteilen. Der Scheduler 210 stellt sicher, dass das Verarbeitungsclusterarray 212 richtig konfiguriert ist und sich in einem gültigen Zustand befindet, bevor Aufgaben an die Verarbeitungscluster des Verarbeitungsclusterarrays 212 verteilt werden. Der Scheduler 210 kann über Firmware-Logik implementiert sein, die auf einem Mikrocontroller ausgeführt wird. Der mikrocontrollerimplementierte Scheduler 210 ist dazu konfigurierbar, komplexe Planungs- und Arbeitsverteilungsoperationen mit Grob- und Feingranularität auszuführen, was eine schnelle Präemption und einen schnellen Kontextwechsel von Threads ermöglicht, die auf dem Verarbeitungsclusterarray 212 ausgeführt werden. Vorzugsweise kann die Hostsoftware Arbeitslasten zum Planen auf dem Verarbeitungsclusterarray 212 über eine von mehreren Grafikverarbeitungs-Doorbells nachweisen. In anderen Beispielen kann das Abfragen nach neuen Arbeitslasten oder Interrupts verwendet werden, um die Verfügbarkeit von durchzuführender Arbeit zu identifizieren oder anzugeben. Die Arbeitslasten können dann automatisch durch die Logik des Schedulers 210 innerhalb des Scheduler-Mikrocontrollers über das Verarbeitungsclusterarray 212 hinweg verteilt werden.
  • Das Verarbeitungsclusterarray 212 kann bis zu „N“ Verarbeitungsclustern (z. B. Cluster 214A, Cluster 214Bbis Cluster 214N) aufweisen. Jeder Cluster 214A-214N des Verarbeitungsclusterarrays 212 kann eine große Anzahl gleichzeitiger Threads ausführen. Der Scheduler 210 kann den Clustern 214A-214N des Verarbeitungsclusterarrays 212 unter Verwendung verschiedener Planungs- und/oder Arbeitsverteilungsalgorithmen, die je nach der Arbeitslast variieren können, die für jede Art von Programm oder Berechnung auftritt, Arbeit zuweisen. Das Planen kann dynamisch vom Scheduler 210 gehandhabt werden oder kann teilweise durch eine Compiler-Logik während des Kompilierens einer Programmlogik, die zur Ausführung durch das Verarbeitungsclusterarray 212konfiguriert ist, unterstützt werden. Optional können verschiedene Cluster 214A-214N des Verarbeitungscluster-Arrays 212 zum Verarbeiten verschiedener Arten von Programmen oder zum Durchführen verschiedener Arten von Berechnungen zugewiesen werden.
  • Das Verarbeitungsclusterarray 212 kann dazu konfiguriert sein, verschiedene Arten von parallelen Verarbeitungsoperationen durchzuführen. Zum Beispiel ist das Verarbeitungsclusterarray 212 dazu konfiguriert, parallele Universalrechenoperationen durchzuführen. Zum Beispiel kann das Verarbeitungsclusterarray 212 Logik zum Ausführen von Verarbeitungsaufgaben, darunter Filtern von Video- und/oder Audiodaten, Durchführen von Modellierungsoperationen einschließlich physischer Operationen und Durchführen von Datentransformationen, beinhalten.
  • Das Verarbeitungsclusterarray 212 ist dazu konfiguriert, parallele Grafikverarbeitungsoperationen durchzuführen. In solchen Ausführungsformen, in denen der Parallelprozessor 200 zum Durchführen von Grafikverarbeitungsoperationen konfiguriert ist, kann das Verarbeitungsclusterarray 212 zusätzliche Logik aufweisen, um die Ausführung solcher Grafikverarbeitungsoperationen zu unterstützen, einschließlich, jedoch ohne Einschränkung, einer Texturabtastlogik zum Durchführen von Texturoperationen sowie einer Tessellationslogik und anderer Vertex-Verarbeitungslogik. Zusätzlich kann das Verarbeitungsclusterarray 212 dazu konfiguriert sein, mit der Grafikverarbeitung in Zusammenhang stehende Shader-Programme auszuführen, wie, jedoch ohne Einschränkung, Vertex-Shader, Tessellations-Shader, Geometrie-Shader und Pixel-Shader. Die Parallelverarbeitungseinheit 202 kann Daten von dem Systemspeicher über die E/A-Einheit 204 zur Verarbeitung übertragen. Während der Verarbeitung können die übertragenen Daten in einem On-Chip-Speicher (z. B. Parallelprozessorspeicher 222) während der Verarbeitung gespeichert werden, dann in den Systemspeicher zurückgeschrieben werden.
  • In Ausführungsformen, in denen die Parallelverarbeitungseinheit 202 zum Durchführen einer Grafikverarbeitung verwendet wird, kann der Scheduler 210 dazu konfiguriert sein, die Verarbeitungsarbeitslast in ungefähr gleich große Aufgaben aufzuteilen, um eine Verteilung der Grafikverarbeitungsoperationen auf mehrere Cluster 214A-214N des Verarbeitungsclusterarrays 212 besser zu ermöglichen. In manchen dieser Ausführungsformen können Teile des Verarbeitungsclusterarrays 212 dazu konfiguriert sein, unterschiedliche Arten von Verarbeitung durchzuführen. Ein erster Abschnitt kann zum Beispiel dazu konfiguriert sein, Vertex-Shading und Topologiegenerierung durchzuführen, ein zweiter Abschnitt kann dazu konfiguriert sein, Tessellations- und Geometrie-Shading durchzuführen, und ein dritter Abschnitt kann dazu konfiguriert sein, Pixel-Shading oder andere Screen-Space-Operationen durchzuführen, um ein gerendertes Bild zur Anzeige zu erzeugen. Zwischendaten, die von einem oder mehreren Clustern 214A bis 214N erzeugt werden, können in Puffern gespeichert werden, um zu ermöglichen, dass die Zwischendaten zwischen Clustern 214A bis 214N zur weiteren Verarbeitung übertragen werden.
  • Während des Betriebs kann das Verarbeitungsclusterarray 212 auszuführende Verarbeitungsaufgaben über den Scheduler 210empfangen, der Befehle, die Verarbeitungsaufgaben definieren, vom Frontend 208empfängt. Für Grafikverarbeitungsoperationen können Verarbeitungsaufgaben Indizes von zu verarbeitenden Daten beinhalten, z. B. Oberflächen-(Patch)-Daten, Primitivdaten, Vertex-Daten und/oder Pixeldaten sowie Zustandsparameter und Befehle, die definieren, wie die Daten verarbeitet werden sollen (z. B. welches Programm ausgeführt werden soll). Der Scheduler 210 kann konfiguriert sein, die den Aufgaben entsprechenden Indizes abzurufen oder die Indizes von dem Frontend 208zu empfangen. Das Frontend 208 kann dazu konfiguriert sein, sicherzustellen, dass das Verarbeitungsclusterarray 212 in einen gültigen Zustand konfiguriert ist, bevor die durch Eingangsbefehlspuffer (z. B. Stapel-Puffer, Push-Puffer usw.) spezifizierte Arbeitslast initiiert wird.
  • Jede der einen oder der mehreren Instanzen der Parallelverarbeitungseinheit 202 kann mit dem Parallelprozessorspeicher 222gekoppelt sein. Auf den Parallelprozessorspeicher 222 kann über die Speicher-Crossbar 216zugegriffen werden, die Speicheranfragen von dem Verarbeitungsclusterarray 212 sowie der E/A-Einheit 204empfangen kann. Die Speicher-Crossbar 216 kann über eine Speicherschnittstelle 218 auf den Parallelprozessorspeicher 222zugreifen. Die Speicherschnittstelle 218 kann mehrere Partitionseinheiten (z. B. Partitionseinheit 220A, Partitionseinheit 220Bbis Partitionseinheit 220N), die jeweils mit einem Teil (z. B. Speichereinheit) des Parallelprozessorspeichers 222gekoppelt sein können, aufwiesen. Die Anzahl von Partitionseinheiten 220A-220N kann so konfiguriert sein, dass sie gleich der Anzahl von Speichereinheiten ist, sodass eine erste Partitionseinheit 220A eine entsprechende erste Speichereinheit 224Aaufweist, eine zweite Partitionseinheit 220B eine entsprechende zweite Speichereinheit 224Baufweist und eine N-te Partitionseinheit 220N eine entsprechende N-te Speichereinheit 224Naufweist. In anderen Ausführungsformen ist die Anzahl von Partitionseinheiten 220A-220N möglicherweise nicht gleich der Anzahl von Speichervorrichtungen.
  • Die Speichereinheiten 224A-224N können verschiedene Arten von Speichervorrichtungen beinhalten, einschließlich eines dynamischen Direktzugriffsspeichers (DRAM) oder eines Grafik-Direktzugriffspeichers, wie eines synchronen Grafik-Direktzugriffspeichers (SGRAM), einschließlich eines Grafikspeichers mit doppelter Datenrate (GDDR). Optional können die Speichereinheiten 224A-224N auch 3D-gestapelten Speicher beinhalten, einschließlich, jedoch ohne Einschränkung, Speicher mit hoher Bandbreite (HBM: High Bandwidth Memory). Fachleute können verstehen, dass die spezielle Implementierung der Speichereinheiten 224A-224N variieren kann und aus einer von verschiedenen herkömmlichen Designs ausgewählt werden kann. Render-Ziele wie Framepuffer oder Texturabbildungen können über die Speichereinheiten 224A-224Ngespeichert werden, wodurch die Partitionseinheiten 220A-220N Abschnitte jedes Render-Ziels parallel schreiben können, um die verfügbare Bandbreite des Parallelprozessorspeichers 222 effizient zu nutzen. In einigen Ausführungsformen kann eine lokale Instanz des Parallelprozessorspeichers 222 zugunsten eines vereinheitlichten Speicherdesigns, das Systemspeicher in Verbindung mit lokalem Cache-Speicher nutzt, ausgeschlossen werden.
  • Optional weist jeder beliebige der Cluster 214A-214N des Verarbeitungsclusterarrays 212 die Fähigkeit auf, Daten zu verarbeiten, die in eine der Speichereinheiten 224A-224N innerhalb des Parallelprozessorspeichers 222 geschrieben werden können. Die Speicher-Crossbar 216 kann konfiguriert sein, um die Ausgabe jedes Clusters 214A-214N an eine beliebige Partitionseinheit 220A-220N oder an einen anderen Cluster 214A-214N zu übertragen, der zusätzliche Verarbeitungsoperationen an der Ausgabe ausführen kann. Jeder Cluster 214A-214N kann mit der Speicherschnittstelle 218 über die Speicher-Crossbar 216 kommunizieren, um aus verschiedenen externen Speichervorrichtungen zu lesen oder in diese zu schreiben. In einer der Ausführungsformen mit der Speicher-Crossbar 216 weist die Speicher-Crossbar 216 eine Verbindung mit der Speicherschnittstelle 218 auf, um mit der E/A-Einheit 204 zu kommunizieren, sowie eine Verbindung mit einer lokalen Instanz des Parallelprozessorspeichers 222, wodurch den Verarbeitungseinheiten innerhalb der verschiedenen Verarbeitungscluster 214A-214N ermöglicht wird, mit dem Systemspeicher oder einem anderen Speicher, der nicht lokal für die Parallelverarbeitungseinheit 202ist, zu kommunizieren. Im Allgemeinen kann die Speicher-Crossbar 216 beispielsweise dazu in der Lage sein, virtuelle Kanäle zu verwenden, um Verkehrsströme zwischen den Clustern 214A-214N und den Partitionseinheiten 220A-220Nzu trennen.
  • Obgleich eine einzige Instanz der Parallelverarbeitungseinheit 202 innerhalb des Parallelprozessors 200 veranschaulicht ist, kann eine beliebige Anzahl von Instanzen der Parallelverarbeitungseinheit 202 eingeschlossen sein. Zum Beispiel können mehrere Instanzen der Parallelverarbeitungseinheit 202 auf einer einzelnen Add-in-Karte bereitgestellt sein, oder mehrere Add-in-Karten können miteinander verbunden sein. Zum Beispiel kann der Parallelprozessor 200 eine Add-in-Vorrichtung sein, wie die Add-in-Vorrichtung 120 von 1, die eine Grafikkarte sein kann, wie eine diskrete Grafikkarte, die eine oder mehrere GPUs, eine oder mehrere Speichervorrichtungen und Vorrichtung-zu-Vorrichtung- oder Netzwerk- oder Fabric-Schnittstellen beinhaltet. Die verschiedenen Instanzen der Parallelverarbeitungseinheit 202 können dazu konfiguriert sein, miteinander zu arbeiten, selbst wenn die verschiedenen Instanzen unterschiedliche Anzahlen von Verarbeitungskernen, unterschiedliche Mengen von lokalem Parallelprozessorspeicher und/oder andere Konfigurationsunterschiede aufweisen. Optional können einige Instanzen der Parallelverarbeitungseinheit 202 Gleitkommaeinheiten mit höherer Genauigkeit relativ zu anderen Instanzen beinhalten. Systeme, die eine oder mehrere Instanzen der Parallelverarbeitungseinheit 202 oder des Parallelprozessors 200 aufweisen, können in einer mehreren Konfigurationen und Formfaktoren implementiert werden, einschließlich, jedoch nicht beschränkt auf Desktop-, Laptop- oder Handheld-Personalcomputer, Server, Workstations, Spielkonsolen und/oder eingebettete Systeme. Ein Orchestrator kann Verbundknoten für Arbeitslastleistungsfähigkeit unter Verwendung eines oder mehrerer von Folgendem bilden: disaggregierter Prozessorressourcen, Cacheressourcen, Speicherressourcen, Speicherungsressourcen und Vernetzungsressourcen.
  • 2B ist ein Blockdiagramm einer Partitionseinheit 220. Die Partitionseinheit 220 kann eine Instanz einer der Partitionseinheiten 220A-220N von 2A sein. Wie veranschaulicht, beinhaltet die Partitionseinheit 220 einenL2-Cache 221, eine Framepufferschnittstelle 225und eine ROP 226 (Rasteroperationseinheit). Der L2-Cache-Speicher 221 ist ein Lese/Schreib-Cache-Speicher, der zum Durchführen von Lade- und Speicheroperationen konfiguriert ist, die von der Speicher-Crossbar 216 und der ROP 226 empfangen werden. Lesefehltreffer und dringende Rückschreibanforderungen werden vom L2-Cache 221 an die Framepufferschnittstelle 225 zur Verarbeitung ausgegeben. Aktualisierungen können auch über die Framepufferschnittstelle 225 zur Verarbeitung an den Framepuffer gesendet werden. In einer Ausführungsform ist die Framepufferschnittstelle 225 mit einer der Speichereinheiten im Parallelprozessorspeicher, wie den Speichereinheiten 224A-224N von 2A (z. B. innerhalb des Parallelprozessorspeichers 222) verbunden. Die Partitionseinheit 220 kann zusätzlich oder alternativ auch über eine Speichersteuerung (nicht gezeigt) mit einer der Speichereinheiten im Parallelprozessorspeicher verbunden sein.
  • In Grafikanwendungen ist die ROP 226 eine Verarbeitungseinheit, die Rasteroperationen wie Schablonen-, z-Test-, Mischoperationen und dergleichen ausführt. Die ROP 226 gibt dann verarbeitete Grafikdaten aus, die im Grafikspeicher gespeichert werden. In einigen Ausführungsformen beinhaltet die ROP 226 einen CODEC 227 oder ist mit diesem gekoppelt, der eine Komprimierungslogik zum Komprimieren von Tiefen- oder Farbdaten, die in den Speicher oder denL2-Cache 221 geschrieben werden, und zum Dekomprimieren von Tiefen- oder Farbdaten, die aus dem Speicher oder dem L2-Cache 221 gelesen werden, beinhaltet. Die Komprimierungslogik kann eine verlustfreie Komprimierungslogik sein, die einen oder mehrere Komprimierungsalgorithmen verwendet. Die Art der Komprimierung, die vom CODEC 227 durchgeführt wird, kann basierend auf den statistischen Eigenschaften der zu komprimierenden Daten variieren. Zum Beispiel wird in einer Ausführungsform eine Delta-Farbkomprimierung an Tiefen- und Farbdaten auf einer Pro-Kachel-Basis durchgeführt. In einer Ausführungsform beinhaltet der CODEC 227 eine Komprimierungs- und Dekomprimierungslogik, die Rechendaten, die Maschinenlernoperationen zugeordnet sind, komprimieren und dekomprimieren kann. Der CODEC 227 kann zum Beispiel dünn besetzte Matrixdaten für dünn besetzte Maschinenlernoperationen komprimieren. Der CODEC 227 kann auch dünn besetzte Matrixdaten komprimieren, die in einem dünn besetzten Matrixformat codiert sind (z. B. Koordinatenlistencodierung (COO), komprimierte dünn besetzte Zeile (CSR), komprimierte dünn besetzte Spalte (CSC) usw.), um komprimierte und codierte dünn besetzte Matrixdaten zu erzeugen. Die komprimierten und codierten dünn besetzten Matrixdaten können dekomprimiert und/oder decodiert werden, bevor sie von Verarbeitungselementen verarbeitet werden, oder die Verarbeitungselemente können dazu konfiguriert sein, komprimierte, codierte oder komprimierte und codierte Daten zur Verarbeitung zu verbrauchen.
  • Die ROP 226 kann in jedem Verarbeitungscluster (z. B. Cluster 214A-214N aus 2A) anstelle innerhalb der Partitionseinheit 220 enthalten sein. In einer solchen Ausführungsform werden Lese- und Schreibanfragen für Pixeldaten über die Speicher-Crossbar 216 anstelle von Pixelfragmentdaten übertragen. Die verarbeiteten Grafikdaten können auf einer Anzeigevorrichtung wie einer der einen oder mehreren Anzeigevorrichtung(en) 110 von 1 angezeigt werden, die zur weiteren Verarbeitung von dem/den Prozessor(en) 102 geroutet werden, oder zur weiteren Verarbeitung durch eine der Verarbeitungseinheiten innerhalb des Parallelprozessors 200 von 2A geroutet werden.
  • 2C ist ein Blockdiagramm eines Verarbeitungsclusters 214 innerhalb einer Parallelverarbeitungseinheit. Der Verarbeitungscluster ist zum Beispiel eine Instanz einer der Verarbeitungscluster 214A-214N von 2A. Der Verarbeitungscluster 214 kann dazu konfiguriert sein, viele Threads parallel auszuführen, wobei sich der Begriff „Thread“ auf eine Instanz eines speziellen Programms bezieht, das auf einem speziellen Satz von Eingabedaten ausgeführt wird. Optional können SIMD-Anweisungsausgabetechniken (SIMD: Single Instruction, Multiple Data) angewendet werden, um eine parallele Ausführung einer großen Anzahl von Threads zu unterstützen, ohne mehrere unabhängige Anweisungseinheiten bereitzustellen. Alternativ werden SIMT-Techniken (SIMT: Single Instruction, Multiple Thread) angewendet, um eine parallele Ausführung einer großen Anzahl von allgemein synchronisierten Threads zu unterstützen, wobei eine gemeinsame Anweisungseinheit verwendet wird, die dazu konfiguriert ist, Anweisungen an einen Satz von Verarbeitungs-Engines innerhalb jedes der Verarbeitungscluster auszugeben. Im Gegensatz zu einer SIMD-Ausführungsregelung, bei der alle Verarbeitungs-Engines typischerweise identische Anweisungen ausführen, ermöglicht die SIMT-Ausführung, dass verschiedene Threads divergenten Ausführungspfaden durch ein gegebenes Thread-Programm leichter folgen. Fachleute können verstehen, dass ein SIMD-Verarbeitungsregime eine funktionelle Teilmenge eines SIMT-Verarbeitungsregimes darstellt.
  • Der Betrieb des Verarbeitungsclusters 214 kann über einen Pipeline-Manager 232 gesteuert werden, der Verarbeitungsaufgaben an SIMT-Parallelprozessoren verteilt. Der Pipeline-Manager 232 empfängt Anweisungen vom Scheduler 210 von 2A und verwaltet die Ausführung dieser Anweisungen über einen Grafikmultiprozessor 234 und/oder eine Textureinheit 236. Der dargestellte Grafikmultiprozessor 234 ist eine beispielhafte Instanz eines SIMT-Parallelprozessors. Es können jedoch verschiedene Arten von SIMT-Parallelprozessoren unterschiedlicher Architekturen in dem Verarbeitungscluster 214enthalten sein. Eine oder mehrere Instanzen des Grafikmultiprozessors 234 können in einem Verarbeitungscluster 214enthalten sein. Der Grafikmultiprozessor 234 kann Daten verarbeiten und eine Daten-Crossbar 240 kann verwendet werden, um die verarbeiteten Daten an eines von mehreren möglichen Zielen, darunter andere Shader-Einheiten, zu verteilen. Der Pipeline-Manager 232 kann die Verteilung verarbeiteter Daten erleichtern, indem er Ziele für verarbeitete Daten spezifiziert, die über die Daten-Crossbar 240 verteilt werden sollen.
  • Jeder Grafikmultiprozessor 234 innerhalb des Verarbeitungsclusters 214 kann einen identischen Satz von funktionaler Ausführungslogik (z. B. arithmetische Logikeinheiten, Lade-Speicher-Einheiten usw.) aufweisen. Die funktionale Ausführungslogik kann auf eine Pipeline-Art konfiguriert sein, in der neue Anweisungen ausgegeben werden können, bevor vorherige Anweisungen abgeschlossen sind. Die funktionale Ausführungsfunktionslogik unterstützt verschiedene Operationen, einschließlich arithmetischer Ganzzahl- und Gleitkomma-Vergleichsoperationen, Boolescher Operationen, Bitverschiebung und Berechnung verschiedener algebraischer Funktionen. Dieselbe Funktionseinheits-Hardware könnte genutzt werden, um unterschiedliche Operationen durchzuführen, und es kann eine beliebige Kombination von Funktionseinheiten vorhanden sein.
  • Die an den Verarbeitungscluster 214 übertragenen Anweisungen bilden einen Thread. Ein Satz von Threads, der über den Satz Parallelverarbeitungs-Engines ausgeführt wird, ist eine Thread-Gruppe. Eine Thread-Gruppe führt dasselbe Programm an unterschiedlichen Eingabedaten aus. Jeder Thread innerhalb einer Thread-Gruppe kann einer anderen Verarbeitungs-Engine innerhalb eines Grafikmultiprozessors 234zugewiesen werden. Eine Thread-Gruppe kann weniger Threads als die Anzahl von Verarbeitungs-Engines innerhalb des Grafikmultiprozessors 234aufweisen. Wenn eine Thread-Gruppe weniger Threads als die Anzahl der Verarbeitungs-Engines aufweist, können eine oder mehrere der Verarbeitungs-Engines während Zyklen, in denen diese Thread-Gruppe verarbeitet wird, inaktiv sein. Eine Thread-Gruppe kann auch mehr Threads als die Anzahl von Verarbeitungs-Engines innerhalb des Grafikmultiprozessors 234beinhalten. Wenn die Thread-Gruppe mehr Threads beinhaltet als die Anzahl der Verarbeitungs-Engines innerhalb des Grafikmultiprozessors 234, kann die Verarbeitung über aufeinanderfolgende Taktzyklen durchgeführt werden. Optional können mehrere Thread-Gruppen gleichzeitig auf dem Grafikmultiprozessor 234ausgeführt werden.
  • Der Grafikmultiprozessor 234 kann einen internen Cache-Speicher beinhalten, um Lade- und Speicheroperationen durchzuführen. Optional kann der Grafikmultiprozessor 234 auf einen internen Cache verzichten und einen Cache-Speicher (z. B. Level-1-(L1)-Cache 248) innerhalb des Verarbeitungsclusters 214 verwenden. Jeder Grafikmultiprozessor 234 hat auch Zugriff auf Level-2-(L2)-Caches innerhalb der Partitionseinheiten (z. B. Partitionseinheiten 220A-220N von 2A), die von allen Verarbeitungsclustern 214 gemeinsam genutzt werden und zum Übertragen von Daten zwischen Threads verwendet werden können. Der Grafikmultiprozessor 234 kann auch auf einen chipexternen globalen Speicher zugreifen, der einen oder mehrere eines lokalen Parallelprozessorspeichers und/oder eines Systemspeichers beinhalten kann. Jeder beliebige Speicher außerhalb der Parallelverarbeitungseinheit 202 kann als globaler Speicher verwendet werden. Ausführungsformen, in denen der Verarbeitungscluster 214 mehrere Instanzen des Grafikmultiprozessors 234 aufweist, können gemeinsame Anweisungen und Daten, die in dem L1-Cache 248gespeichert sein können, gemeinsam nutzen.
  • Jeder Verarbeitungscluster 214 kann eine MMU 245 (Memory Management Unit - Speicherverwaltungseinheit) aufweisen, die dazu konfiguriert ist, virtuelle Adressen in physische Adressen abzubilden. In anderen Ausführungsformen können sich eine oder mehrere Instanzen der MMU 245 in der Speicherschnittstelle 218 von 2A befinden. Die MMU 245 beinhaltet einen Satz von Seitentabelleneinträgen (PTEs), die zum Abbilden einer virtuellen Adresse auf eine physische Adresse einer Kachel verwendet werden, und optional einen Cachezeilenindex. Die MMU 245 kann Adressübersetzungs-Nachschlagepuffer (TLB) oder Caches aufweisen, die sich innerhalb des Grafikmultiprozessors 234 oder des L1-Caches oder Verarbeitungsclusters 214 befinden können. Die physische Adresse wird verarbeitet, um die Oberflächendaten-Zugriffslokalität zu verteilen, um eine effiziente Anforderungsverschachtelung zwischen Partitionseinheiten zu ermöglichen. Der Cachezeilenindex kann verwendet werden, um zu bestimmen, ob eine Anforderung für eine Cachezeile ein Treffer oder ein Fehltreffer ist.
  • In Grafik- und Rechenanwendungen kann ein Verarbeitungscluster 214 derart konfiguriert sein, dass jeder Grafikmultiprozessor 234 mit einer Textureinheit 236 zur Durchführung von Texturabbildungsoperationen, z. B. Bestimmen von Texturabtastpositionen, Lesen von Texturdaten und Filtern der Texturdaten, gekoppelt ist. Texturdaten werden aus einem internen Textur-L1-Cache (nicht gezeigt) oder in einigen Ausführungsformen aus dem L1-Cache innerhalb des Grafikmultiprozessors 234 gelesen und werden je nach Bedarf aus einem L2-Cache, einem lokalen Parallelprozessorspeicher oder einem Systemspeicher abgerufen. Jeder Grafikmultiprozessor 234 gibt verarbeitete Aufgaben an die Daten-Crossbar 240 aus, um die verarbeitete Aufgabe einem weiteren Verarbeitungscluster 214 zur weiteren Verarbeitung bereitzustellen oder die verarbeitete Aufgabe über die Speicher-Crossbar 216 in einem L2-Cache, einem lokalen Parallelprozessorspeicher oder einem Systemspeicher zu speichern. Ein preROP 242 (Vor-Rasteroperationseinheit) ist dazu konfiguriert, Daten von dem Grafikmultiprozessor 234zu empfangen, Daten zu ROP-Einheiten zu leiten, die sich bei Partitionseinheiten befinden können, wie hier beschrieben (z. B. Partitionseinheiten 220A-220N von 2A). Die preROP 242 - Einheit kann Optimierungen für die Farbmischung ausführen, Pixelfarbdaten organisieren und Adressübersetzungen ausführen.
  • Es versteht sich, dass die hier beschriebene Kernarchitektur veranschaulichend ist und dass Variationen und Modifikationen möglich sind. Eine beliebige Anzahl von Verarbeitungseinheiten, z. B. der Grafikmultiprozessor 234, Textureinheiten 236, preROPs 242usw. können innerhalb eines Verarbeitungsclusters 214enthalten sein. Wenngleich nur ein Verarbeitungscluster 214 dargestellt ist, kann ferner eine Parallelverarbeitungseinheit, wie hierin beschrieben, eine beliebige Anzahl von Instanzen des Verarbeitungs-Clusters 214aufweisen. Optional kann jeder Verarbeitungscluster 214 dazu konfiguriert sein, unabhängig von anderen Verarbeitungsclustern 214 unter Verwendung separater und unterschiedlicher Verarbeitungseinheiten, mit L1-Caches, L2-Caches usw. zu arbeiten.
  • 2D zeigt ein Beispiel für den Grafikmultiprozessor 234, in dem der Grafikmultiprozessor 234 mit dem Pipeline-Manager 232 des Verarbeitungsclusters 214gekoppelt ist. Der Grafikmultiprozessor 234 weist eine Ausführungs-Pipeline auf, einschließlich, jedoch ohne Einschränkung, eines Anweisungscaches 252, einer Anweisungseinheit 254, einer Adressenabbildungseinheit 256, einer Registerdatei 258, eines oder mehrerer GPGPU-(Universalgrafikverarbeitungseinheits)-Kerne 262und einer oder mehrerer Lade/Speicher-Einheiten 266. Die GPGPU-Kerne 262 und Lade/Speicher-Einheiten 266 sind über eine Speicher- und Cache-Verbindung 268mit dem Cache-Speicher 272 und dem gemeinsam genutzten Speicher 270 gekoppelt. Der Grafikmultiprozessor 234 kann zusätzlich Tensor- und/oder Strahlverfolgungskerne 263 beinhalten, die Hardwarelogik beinhalten, um Matrix- und/oder Strahlverfolgungsoperationen zu beschleunigen.
  • Der Anweisungscache 252 kann einen Strom auszuführender Anweisungen von dem Pipeline-Manager 232empfangen. Die Anweisungen werden in dem Anweisungscache 252 zwischengespeichert und zur Ausführung durch die Anweisungseinheit 254versendet. Die Anweisungseinheit 254 kann Anweisungen als Thread-Gruppen (z. B. Warps) versenden, wobei jeder Thread der Thread-Gruppe einer anderen Ausführungseinheit innerhalb des GPGPU-Kerns 262zugewiesen ist. Eine Anweisung kann auf einen beliebigen lokalen, gemeinsam genutzten oder globalen Adressraum zugreifen, indem sie eine Adresse in einem vereinheitlichten Adressraum spezifiziert. Die Adressenabbildungseinheit 256 kann verwendet werden, um Adressen in dem vereinheitlichten Adressraum in eine unterschiedliche Speicheradresse zu übersetzen, auf die von den Lade/Speicher-Einheiten 266 zugegriffen werden kann.
  • Die Registerdatei 258 stellt einen Satz von Registern für die Funktionseinheiten des Grafikmultiprozessors 234bereit. Die Registerdatei 258 stellt einen temporären Speicher für Operanden bereit, die mit den Datenpfaden der Funktionseinheiten (z. B. GPGPU-Kerne 262, Lade/Speicher-Einheiten 266) des Grafikmultiprozessors 234 verbunden sind. Die Registerdatei 258 kann zwischen jeder der Funktionseinheiten aufgeteilt werden, sodass jeder Funktionseinheit ein dedizierter Abschnitt der Registerdatei 258zugewiesen wird. Zum Beispiel kann die Registerdatei 258 zwischen den verschiedenen Warps aufgeteilt werden, die vom Grafikmultiprozessor 234 ausgeführt werden.
  • Die GPGPU-Kerne 262 können jeweils Gleitkommaeinheiten (FPUs) und/oder arithmetische Ganzzahl-Logikeinheiten (ALUs) aufweisen, die zum Ausführen von Anweisungen des Grafikmultiprozessors 234verwendet werden. In einigen Implementierungen können die GPGPU-Kerne 262 Hardwarelogik beinhalten, die sich ansonsten in den Tensor- und/oder Strahlverfolgungskernen 263befinden kann. Die GPGPU-Kerne 262 können eine ähnliche Architektur aufweisen oder sich in der Architektur unterscheiden. Zum Beispiel und in einer Ausführungsform beinhaltet ein erster Abschnitt der GPGPU-Kerne 262 eine FPU mit einfacher Genauigkeit und eine Ganzzahl-ALU, während ein zweiter Abschnitt der GPGPU-Kerne eine FPU mit doppelter Genauigkeit beinhaltet. Optional können die FPUs den IEEE 754-2008-Standard für Gleitkomma-Arithmetik implementieren oder Gleitkomma-Arithmetik mit variabler Genauigkeit ermöglichen. Der Grafikmultiprozessor 234 kann außerdem eine oder mehrere Festfunktions- oder Spezialfunktionseinheiten beinhalten, um spezielle Funktionen wie Rechteckkopier- oder Pixelmischoperationen durchzuführen. Einer oder mehrere der GPGPU-Kerne können auch Logik mit Fest- oder Spezialfunktion beinhalten.
  • Die GPGPU-Kerne 262 können eine SIMD-Logik beinhalten, die in der Lage ist, eine einzelne Anweisung an mehreren Datensätzen durchzuführen. Optional können die GPGPU-Kerne 262 physisch SIMD4-, SIMD8- und SIMD16-Anweisungen ausführen und logisch SIMD1-, SIMD2- und SIMD32-Anweisungen ausführen. Die SIMD-Anweisungen für die GPGPU-Kerne können zur Kompilierungszeit von einem Shader-Compiler erzeugt oder automatisch erzeugt werden, wenn Programme ausgeführt werden, die für Single-Program-Multiple-Data(SPMD)- oder SIMT-Architekturen geschrieben und kompiliert werden. Mehrere Threads eines für das SIMT-Ausführungsmodell konfigurierten Programms können über eine einzige SIMD-Anweisung ausgeführt werden. Zum Beispiel können in einer Ausführungsform acht SIMT-Threads, die die gleichen oder ähnliche Operationen ausführen, parallel über eine einzige SIMD8-Logikeinheit ausgeführt werden.
  • Das Speicher- und Cache-Interconnect 268 ist ein Interconnect-Netzwerk, das jede der Funktionseinheiten des Grafikmultiprozessors 234 mit der Registerdatei 258 und mit dem gemeinsam genutzten Speicher 270 verbindet. Zum Beispiel ist das Speicher- und Cache-Interconnect 268 ein Crossbar-Interconnect, das es der Lade/Speicher-Einheit 266 ermöglicht, Lade- und Speicheroperationen zwischen dem gemeinsam genutzten Speicher 270 und der Registerdatei 258 zu implementieren. Die Registerdatei 258 kann mit der gleichen Frequenz wie die GPGPU-Kerne 262 arbeiten, sodass die Datenübertragung zwischen den GPGPU-Kernen 262 und der Registerdatei 258 eine niedrige Latenz hat. Der gemeinsam genutzte Speicher 270 kann verwendet werden, um eine Kommunikation zwischen Threads zu ermöglichen, die auf den Funktionseinheiten innerhalb des Grafikmultiprozessors 234 ausgeführt werden. Der Cache-Speicher 272 kann beispielsweise als ein Datencache verwendet werden, um Texturdaten, die zwischen den Funktionseinheiten und der Textureinheit 236 übermittelt werden, zwischenzuspeichern. Der gemeinsam genutzte Speicher 270 kann auch als ein Programm mit Cacheverwaltung verwendet werden. Der gemeinsam genutzte Speicher 270 und der Cache-Speicher 272 können mit der Daten-Crossbar 240 gekoppelt sein, um eine Kommunikation mit anderen Komponenten des Verarbeitungsclusters zu ermöglichen. Threads, die auf den GPGPU-Kernen 262 ausgeführt werden, können programmatisch Daten in dem gemeinsam genutzten Speicher zusätzlich zu den automatisch zwischengespeicherten Daten speichern, die in dem Cache-Speicher 272 gespeichert sind.
  • 3A-3C veranschaulichen zusätzliche Grafikmultiprozessoren gemäß Ausführungsformen. 3A-3B veranschaulichen Grafikmultiprozessoren 325, 350, die mit den Grafikmultiprozessor 234 von 2C in Beziehung stehen, und können anstelle von einem von diesen verwendet werden. Daher offenbart die Erläuterung jeglicher Merkmale in Kombination mit dem Grafikmultiprozessor 234 hierin auch eine entsprechende Kombination mit dem/den Grafikmultiprozessor(en) 325, 350, ist aber nicht darauf beschränkt. 3C veranschaulicht eine Grafikverarbeitungseinheit (GPU) 380 , die dedizierte Sätze von Grafikverarbeitungsressourcen beinhaltet, die in Mehrkerngruppen 365A-365Nangeordnet sind, die den Grafikmultiprozessoren 325, 350entsprechen. Die veranschaulichten Grafikmultiprozessoren 325, 350 und die Mehrkerngruppen 365A-365N können Streaming-Multiprozessoren (SM) sein, die in der Lage sind, gleichzeitig eine große Anzahl von Ausführungs-Threads auszuführen.
  • Der Grafikmultiprozessor 325 aus 3A beinhaltet mehrere zusätzliche Instanzen von Ausführungsressourceneinheiten relativ zu dem Grafikmultiprozessor 234 von 2D. Zum Beispiel kann der Grafikmultiprozessor 325 mehrere Instanzen der Anweisungseinheit 332A-332B, der Registerdatei 334A-334B und der Textureinheit(en) 344A-344Bbeinhalten. Der Grafikmultiprozessor 325 beinhaltet auch mehrere Sätze von Grafik- oder Rechenausführungseinheiten (z. B. GPGPU-Kern 336A-336B, Tensorkern 337A-337B, Strahlverfolgungskern 338A-338B) und mehrere Sätze von Lade-/Speichereinheiten 340A-340B. Die Ausführungsressourceneinheiten weisen einen gemeinsamen Anweisungscache 330, einen Textur- und/oder Daten-Cache-Speicher 342und einen gemeinsam genutzten Speicher 346auf.
  • Die verschiedenen Komponenten können über eine Interconnect-Fabric 327kommunizieren. Die Interconnect-Fabric 327 kann einen oder mehrere Crossbar-Schalter beinhalten, um eine Kommunikation zwischen den verschiedenen Komponenten des Grafikmultiprozessors 325 zu ermöglichen. Die Interconnect-Fabric 327 kann eine separate Hochgeschwindigkeits-Netzwerk-Fabric-Schicht sein, auf der jede Komponente des Grafikmultiprozessors 325 gestapelt ist. Die Komponenten des Grafikmultiprozessors 325 kommunizieren mit entfernten Komponenten über die Interconnect-Fabric 327. Zum Beispiel können die Kerne 336A-336B, 337A-337B und 338A-338B jeweils mit einem gemeinsam genutzten Speicher 346 über die Interconnect-Fabric 327 kommunizieren. Die Interconnect-Fabric 327 kann die Kommunikation innerhalb des Grafikmultiprozessors 325 vermitteln, um eine faire Bandbreitenzuordnung zwischen Komponenten sicherzustellen.
  • Der Grafikmultiprozessor 350 aus 3B beinhaltet mehrere Sätze von Ausführungsressourcen 356A-356D, wobei jeder Satz von Ausführungsressourcen mehrere Anweisungseinheiten, Registerdateien, GPGPU-Kerne und Lade/Speicher-Einheiten beinhaltet, wie in 2D und 3A veranschaulicht. Die Ausführungsressourcen 356A-356D können für Texturoperationen mit Textureinheit(en) 360A-360D zusammenarbeiten, während sie einen Anweisungs-Cache 354und einen gemeinsam genutzten Speicher 353gemeinsam nutzen. Zum Beispiel können die Ausführungsressourcen 356A-356D einen Anweisungs-Cache 354 und einen gemeinsam genutzten Speicher 353sowie mehrere Instanzen eines Textur- und/oder Daten-Cache-Speichers 358A-358b gemeinsam nutzen. Die verschiedenen Komponenten können über eine Interconnect-Fabric 352 ähnlich der Interconnect-Fabric 327 von 3A kommunizieren.
  • Fachleute können verstehen, dass die in 1, 2A-2D und 3A-3B beschriebene Architektur beschreibend ist und den Umfang der vorliegenden Ausführungsformen nicht einschränkend. Somit können die hier beschriebenen Techniken auf jeder ordnungsgemäß konfigurierten Verarbeitungseinheit implementiert werden, einschließlich, ohne Einschränkung, einem oder mehreren mobilen Anwendungsprozessoren, einer oder mehreren Desktop- oder Server-Zentralverarbeitungseinheiten (CPUs), einschließlich Mehrkern-CPUs, einer oder mehreren parallelen Verarbeitungseinheiten, wie der Parallelverarbeitungseinheit 202 von 2A, sowie einen oder mehrere Grafikprozessoren oder Spezialverarbeitungseinheiten, ohne vom Umfang der hierin beschriebenen Ausführungsformen abzuweichen.
  • Der Parallelprozessor oder die GPGPU, wie hierin beschrieben, können kommunikativ mit Host-/Prozessorkernen gekoppelt sein, um Grafikoperationen, Maschinenlernoperationen, Musteranalyseoperationen und verschiedene Universal-GPU-(GPGPU)-Funktionen zu beschleunigen. Die GPU kann über einen Bus oder ein anderes Interconnect (z. B. ein Hochgeschwindigkeits-Interconnect, wie PCIe oder NVLink, oder andere bekannte Protokolle, standardisierte Protokolle oder proprietäre Protokolle) kommunikativ mit dem Hostprozessor/den Kernen gekoppelt sein. In anderen Ausführungsformen kann die GPU auf demselben Package oder Chip wie die Kerne integriert sein und über einen internen Prozessorbus/ein Interconnect (d. h. innerhalb des Package oder Chips) kommunikativ mit den Kernen gekoppelt sein. Unabhängig von der Art und Weise, auf welche die GPU verbunden ist, können die Prozessorkerne der GPU Arbeit in Form von Sequenzen von Befehlen/Anweisungen zuweisen, die in einem Arbeitsdeskriptor enthalten sind. Die GPU verwendet dann eine dedizierte Schaltlogik/Logik zum effizienten Verarbeiten dieser Befehle/Anweisungen.
  • 3C veranschaulicht eine Grafikverarbeitungseinheit (GPU) 380 , die dedizierte Sätze von Grafikverarbeitungsressourcen beinhaltet, die in Mehrkerngruppen 365A-365Nangeordnet sind. Während die Details nur einer einzigen Mehrkerngruppe 365A bereitgestellt sind, versteht es sich, dass die anderen Mehrkerngruppen 365B-365N mit den gleichen oder ähnlichen Sätzen von Grafikverarbeitungsressourcen ausgestattet sein können. Details, die in Bezug auf die Mehrkerngruppen 365A-365N beschrieben sind, können auch für jeden beliebigen hierin beschriebenen Grafikmultiprozessor 234, 325, 350 gelten.
  • Wie veranschaulicht, kann eine Mehrkerngruppe 365A einen Satz von Grafikkernen 370, einen Satz von Tensorkernen 371 und einen Satz von Strahlverfolgungskernen 372beinhalten. Ein Scheduler/Dispatcher 368 plant und versendet die Grafik-Threads zur Ausführung auf den verschiedenen Kernen 370, 371, 372. Ein Satz von Registerdateien 369 speichert Operandenwerte, die von den Kernen 370, 371, 372 verwendet werden, wenn die Grafik-Threads ausgeführt werden. Diese können zum Beispiel Ganzzahlregister zum Speichern von Ganzzahlwerten, Gleitkommaregister zum Speichern von Gleitkommawerten, Vektorregister zum Speichern von gepackten Datenelementen (Ganzzahl- und/oder Gleitkomma-Datenelementen) und Kachelregister zum Speichern von Tensor-/Matrixwerten einschließen. Die Kachelregister können als kombinierte Sätze von Vektorregistern implementiert werden.
  • Ein oder mehrere kombinierte Level-1-(L1)-Caches und gemeinsam genutzte Speichereinheiten 373 speichern Grafikdaten, wie Texturdaten, Vertex-Daten, Pixeldaten, Strahlendaten, Begrenzungsvolumendaten usw. lokal innerhalb jeder Mehrkerngruppe 365A. Eine oder mehrere Textureinheiten 374 können auch verwendet werden, um Texturierungsoperationen wie Texturabbildung und Sampling durchzuführen. Ein Level-2-(L2)-Cache 375 , der von allen oder einer Teilmenge der Mehrkerngruppen 365A-365N gemeinsam genutzt wird, speichert Grafikdaten und/oder Anweisungen für mehrere gleichzeitige Grafik-Threads. Wie veranschaulicht, kann der L2-Cache 375 über mehrere Mehrkerngruppen 365A-365N hinweg gemeinsam genutzt werden. Eine oder mehrere Speichersteuerungen 367 koppeln die GPU 380 mit einem Speicher 366 , der ein Systemspeicher (z. B. DRAM) und/oder ein dedizierter Grafikspeicher (z. B. GDDR6 Speicher) sein kann.
  • Eine Eingabe/Ausgabe(E/A)-Schaltlogik 363 koppelt die GPU 380 mit einer oder mehreren E/A-Vorrichtungen 362, wie Digitalsignalprozessoren (DSPs), Netzwerksteuerungen oder Benutzereingabevorrichtungen. Ein On-Chip-Interconnect kann dazu verwendet werden, die E/A-Vorrichtungen 362 mit der GPU 380 und dem Speicher 366zu koppeln. Eine oder mehrere E/A-Speicherverwaltungseinheiten (IOMMUs) 364 der E/A-Schaltlogik 363 koppeln die E/A-Vorrichtungen 362 direkt mit dem Systemspeicher 366. Optional verwaltet die IOMMU 364 mehrere Sätze von Seitentabellen, um virtuelle Adressen auf physische Adressen im Systemspeicher 366 abzubilden. Die E/A-Vorrichtungen 362, die CPU(s) 361und die GPU(s) 380 können dann denselben virtuellen Adressraum gemeinsam nutzen.
  • Bei einer Implementierung der IOMMU 364unterstützt die IOMMU 364 die Virtualisierung. In diesem Fall kann sie einen ersten Satz von Seitentabellen dahingehend verwalten, virtuelle Gast-/Grafikadressen auf physische Gast-/Grafikadressen abzubilden, und einen zweiten Satz von Seitentabellen dahingehend verwalten, die physischen Gast-/Grafikadressen auf physische System-/Hostadressen (z. B. innerhalb des Systemspeichers 366) abzubilden. Die Basisadressen sowohl des ersten als auch des zweiten Satzes von Seitentabellen können in Steuerregistern gespeichert werden und bei einem Kontextwechsel ausgelagert werden (z. B. sodass dem neuen Kontext Zugriff auf den relevanten Satz von Seitentabellen bereitgestellt wird). Obwohl dies in 3C nicht veranschaulicht ist, kann jeder der Kerne 370, 371, 372 und/oder die Mehrkerngruppen 365A-365N Übersetzungsnachschlagpuffer (TLBs: Translation Lookaside Buffers) beinhalten, um virtuelle-Gast-in-physische-Gast-Übersetzungen, physische-Gast-in-physische-Host-Übersetzungen und virtuelle-Gast-in-physische-Host-Übersetzungen zwischenzuspeichern.
  • Die CPU(s) 361, GPUs 380und die E/A-Vorrichtungen 362 können auf einem einzigen Halbleiterchip und/oder Chip-Package integriert sein. Der veranschaulichte Speicher 366 kann auf demselben Chip integriert sein oder kann über eine chipexterne Schnittstelle mit den Speichersteuerungen 367 gekoppelt sein. In einer Implementierung umfasst der Speicher 366 GDDR6 Speicher, der denselben virtuellen Adressraum wie andere physische Systemebenenspeicher nutzt, obwohl die hierin beschriebenen zugrundeliegenden Prinzipien nicht auf diese spezifische Implementierung beschränkt sind.
  • Die Tensorkerne 371 können mehrere Ausführungseinheiten beinhalten, die speziell dafür ausgelegt sind, Matrixoperationen durchzuführen, die die Kernrechenoperation sind, die verwendet wird, um Deep-Learning-Operationen durchzuführen. Zum Beispiel können simultane Matrixmultiplikationsoperationen für neuronales Netzwerktraining und -inferenzieren verwendet werden. Die Tensorkerne 371 können eine Matrixverarbeitung unter Verwendung einer mehreren Operandengenauigkeiten durchführen, einschließlich Gleitkomma mit einfacher Genauigkeit (z. B. 32 Bits), Gleitkomma mit halber Genauigkeit (z. B. 16 Bits), ganzzahligen Wörtern (16 Bits), Bytes (8 Bits) und Halbbytes (4 Bits). Zum Beispiel extrahiert eine Implementierung eines neuronalen Netzwerks Merkmale jeder gerenderten Szene, wobei potenziell Details aus mehreren Frames kombiniert werden, um ein qualitativ hochwertiges Endbild zu konstruieren.
  • Bei Deep-Learning-Implementierungen kann eine Parallelmatrixmultiplikationsarbeit zur Ausführung auf den Tensorkernen 371 geplant werden. Insbesondere nutzt das Training neuronaler Netzwerke eine signifikante Anzahl von Matrixskalarproduktoperationen. Um eine Innenproduktformulierung einer N x N x N Matrixmultiplikation zu verarbeiten, können die Tensorkerne 371 mindestens N Skalarproduktverarbeitungselemente beinhalten. Bevor die Matrixmultiplikation beginnt, wird pro Zyklus für N Zyklen eine ganze Matrix in Kachelregister geladen und mindestens eine Spalte einer zweiten Matrix geladen. In jedem Zyklus gibt es N Skalarprodukte, die verarbeitet werden.
  • Matrixelemente können in Abhängigkeit von der speziellen Implementierung mit unterschiedlichen Genauigkeiten gespeichert werden, einschließlich 16-Bit-Wörtern, 8-Bit-Bytes (z. B. INT8) und 4-Bit-Halbbytes (z. B. INT4). Unterschiedlichen Präzisionsmodi können für die Tensorkerne 371 spezifiziert werden, um sicherzustellen, dass eine effiziente Genauigkeit für unterschiedliche Arbeitslasten verwendet wird (z. B. wie Inferenzieren von Arbeitslasten, die eine Quantisierung auf Bytes und Halbbytes tolerieren können). Unterstützte Formate beinhalten zusätzlich 64-Bit-Gleitkomma (FP64) und nicht-IEEE-Gleitkommaformate, wie das bfloat16-Format (z. B. Brain-Gleitkomma), ein 16-Bit-Gleitkommaformat mit einem Vorzeichenbit, acht Exponentenbits und acht signifikante Bits, von denen sieben explizit gespeichert sind. Eine Ausführungsform beinhaltet Unterstützung für ein Tensor-Float-Format (TF32) mit reduzierter Präzision, das den Bereich von FP32 (8 Bit) mit der Präzision von FP16 (10 Bit) aufweist. TF32-Operationen mit reduzierter Präzision können an FP32-Eingaben durchgeführt werden und FP32-Ausgaben mit höherer Leistungsfähigkeit relativ zu FP32 und erhöhter Präzision relativ zu FP16 erzeugen.
  • In einer Ausführungsform unterstützen die Tensorkerne 371 einen dünn besetzten Betriebsmodus für Matrizen, in denen die überwiegende Mehrzahl von Werten null ist. Die Tensorkerne 371 weisen Unterstützung für dünn besetzte Eingabematrizen auf, die in einer dünn besetzten Matrixrepräsentation codiert sind (z. B. Koordinatenlistencodierung (COO), komprimierte dünn besetzte Zeile (CSR), kompimierte dünn besetzte Spalte (CSC) usw.). Die Tensorkerne 371 weisen auch Unterstützung für komprimierte dünn besetzte Matrixdarstellungen in dem Fall auf, dass die dünn besetzte Matrixrepräsentation weiter komprimiert werden kann. Komprimierte, codierte und/oder komprimierte und codierte Matrixdaten zusammen mit zugehörigen Komprimierungs- und/oder Codierungsmetadaten können von den Tensorkernen 371 gelesen werden und die Werte ungleich Null können extrahiert werden. Zum Beispiel kann für eine gegebene Eingabematrix A ein Wert ungleich null aus der komprimierten und/oder codierten Repräsentation von mindestens einem Abschnitt der Matrix A geladen werden. Basierend auf der Position in der Matrix A für den Wert ungleich Null, der aus Index- oder Koordinatenmetadaten bestimmt werden kann, die dem Wert ungleich Null zugeordnet sind, kann ein entsprechender Wert in der Eingangsmatrix B geladen werden. In Abhängigkeit von der durchzuführenden Operation (z. B. Multiplizieren) kann das Laden des Werts aus der Eingabematrix B umgangen werden, falls der entsprechende Wert ein Nullwert ist. In einer Ausführungsform können die Paarungen von Werten für gewisse Operationen, wie Multiplikationsoperationen, von der Scheduler-Logik vorgescannt werden und nur Operationen zwischen Eingaben ungleich Null werden geplant. In Abhängigkeit von den Dimensionen der Matrix A und der Matrix B und der durchzuführenden Operation kann die Ausgabematrix C dicht oder dünn besetzt sein. Wenn die Ausgabematrix C dünn besetzt ist und in Abhängigkeit von der Konfiguration der Tensorkerne 371, kann die Ausgabematrix C in einem komprimierten Format, einer dünn besetzten Codierung oder einer komprimierten dünn besetzten Codierung ausgegeben werden.
  • Die Strahlverfolgungskerne 372 können Strahlverfolgungsoperationen sowohl für Echtzeit-Strahlverfolgungs- als auch für Nicht-Echtzeit-Strahlverfolgungsimplementierungen beschleunigen. Insbesondere können die Strahlverfolgungskerne 372 eine Strahltraversierungs-/-schnittschaltlogik zum Durchführen einer Strahltraversierung unter Verwendung von Begrenzungsvolumenhierarchien (BVHs) und Identifizieren von Schnittpunkten zwischen Strahlen und Primitiven, die in den BVH-Volumina enthalten sind, aufweisen. Die Strahlverfolgungskerne 372 können auch eine Schaltlogik zum Durchführen von Tiefenprüfung und Culling (z. B. unter Verwendung eines Z-Puffers oder einer ähnlichen Anordnung) beinhalten. Bei einer Implementierung führen die Strahlverfolgungskerne 372 Traversierungs- und Schnittoperationen in Übereinstimmung mit den hierin beschriebenen Bildentrauschungstechniken durch, von denen mindestens ein Teil an den Tensorkernen 371 ausgeführt werden kann. Zum Beispiel können die Tensorkerne 371 ein neuronales Deep-Learning-Netzwerk implementieren, um eine Entrauschung von Frames durchzuführen, die durch die Strahlverfolgungskerne 372erzeugt werden. Die CPU(s) 361, Grafikkerne 370und/oder Strahlverfolgungskerne 372 können jedoch auch alle oder einen Teil der Entrauschungs- und/oder Deep-Learning-Algorithmen implementieren.
  • Außerdem kann, wie oben beschrieben, ein verteilter Ansatz zur Rauschentfernung eingesetzt werden, bei dem sich die GPU 380 in einer Rechenvorrichtung befindet, die über ein Netzwerk oder eine Hochgeschwindigkeitsverbindung mit anderen Rechenvorrichtungen gekoppelt ist. Bei diesem verteilten Ansatz können die miteinander verbundenen Rechenvorrichtungen Lern-/Trainingsdaten von neuronalen Netzwerken gemeinsam nutzen, um die Geschwindigkeit zu verbessern, mit der das Gesamtsystem lernt, eine Entrauschung für unterschiedliche Arten von Bildframes und/oder unterschiedliche Grafikanwendungen durchzuführen.
  • Die Strahlverfolgungskerne 372 können alle BVH-Traversierung und/oder Strahl-Primitiv-Schnitte verarbeiten, was verhindert, dass die Grafikkerne 370 mit tausenden Anweisungen pro Strahl überlastet werden. Zum Beispiel beinhaltet jeder Strahlverfolgungskern 372 einen ersten Satz spezialisierter Schaltlogik zum Durchführen von Begrenzungsquaderprüfungen (z. B. für Traversierungsoperationen) und/oder einen zweiten Satz spezialisierter Schaltlogik zum Durchführen der Strahl-Dreieck-Schnittprüfungen (z. B. sich schneidende Strahlen, die durchquert wurden). Somit kann zum Beispiel die Mehrkerngruppe 365A einfach eine Strahlsonde starten und die Strahlverfolgungskerne 372 führen unabhängig Strahltraversierung und -schnitt durch und geben Trefferdaten (z. B. ein Treffer, kein Treffer, mehrere Treffer usw.) an den Thread-Kontext zurück. Die anderen Kerne 370, 371 werden freigegeben, um andere Grafik- oder Rechenarbeit durchzuführen, während die Strahlverfolgungskerne 372 die Traversier- und Schnittoperationen durchführen.
  • Optional kann jeder Strahlverfolgungskern 372 eine Traversierungseinheit zum Durchführen von BVH-Prüfungsoperationen und/oder eine Schnitteinheit, die Strahl-Primitiv-Schnittprüfungen durchführt, beinhalten. Die Schnitteinheit generiert eine „Treffer“-, „kein Treffer“- oder „mehrere Treffer“-Antwort, die sie dem jeweiligen Thread bereitstellt. Während der Traversierungs- und Schnittoperationen werden die Ausführungsressourcen der anderen Kerne (z.B. die Grafikkerne 370 und die Tensorkerne 371) freigegeben, um andere Formen von Grafikarbeit durchzuführen.
  • In einer unten beschriebenen optionalen Ausführungsform wird ein hybrider Rasterisierungs-/Strahlverfolgungsansatz verwendet, bei dem Arbeit zwischen den Grafikkernen 370 und den Strahlverfolgungskernen 372verteilt wird.
  • Die Strahlverfolgungskerne 372 (und/oder andere Kerne 370, 371) können Hardwareunterstützung für einen Strahlverfolgungsanweisungssatz, wie DirectX Ray Tracing (DXR) von Microsoft, der einen DispatchRays-Befehl beinhaltet, sowie Strahlerzeugung, Nächster-Treffer-, Beliebiger-Treffer- und Fehltreffer-Shader, die die Zuweisung eindeutiger Sätze von Shadern und Texturen für jedes Objekt ermöglichen, beinhalten. Eine andere Strahlverfolgungsplattform, die von den Strahlverfolgungskernen 372, Grafikkernen 370 und Tensorkernen 371 unterstützt werden kann, ist Vulkan 1.1.85. Es sei jedoch angemerkt, dass die hier beschriebenen zugrundeliegenden Prinzipien nicht auf irgendeine spezielle Strahlverfolgungs-ISA beschränkt sind.
  • Im Allgemeinen können die verschiedenen Kerne 372, 371, 370 einen Strahlverfolgungsanweisungssatz unterstützen, der Anweisungen/Funktionen für einen oder mehrere von einer Strahlerzeugung, einem Nächsten-Treffer, Beliebigem-Treffer, Strahl-Primitiv-Schnittpunkt und hierarchische Primitiv-weise Begrenzungsquaderkonstruktion , Fehltreffer, Visit und Ausnahmen beinhaltet. Genauer gesagt beinhaltet eine Ausführungsform Strahlverfolgungsanweisungen zum Durchführen einer oder mehrerer der folgenden Funktionen:
    • Strahlerzeugung - Strahlerzeugungsanweisungen können für jedes Pixel, jede Abtastung oder jede andere benutzerdefinierte Arbeitszuweisung ausgeführt werden.
    • Nächster-Treffer - Eine Nächster-Treffer-Anweisung kann ausgeführt werden, um den nächstgelegenen Schnittpunkt eines Strahls mit Primitiven innerhalb einer Szene zu lokalisieren.
    • Beliebiger-Treffer - Eine Beliebiger-Treffer-Anweisung identifiziert mehrere Schnitte zwischen einem Strahl und Primitiven innerhalb einer Szene, um potenziell einen neuen nächstgelegenen Schnittpunkt zu identifizieren.
    • Schnitt - Eine Schnittanweisung führt eine Strahl-Primitiv-Schnittprüfung durch und gibt ein Ergebnis aus.
    • Primitiv-weise Beszrenzunszsquaderkonstruktion - Diese Anweisung erstellt einen Begrenzungsquader um ein gegebenes Primitiv oder eine gegebene Gruppe von Primitiven herum (z. B., wenn eine neue BVH- oder andere Beschleunigungsdatenstruktur erstellt wird).
    • Fehltreffer - gibt an, dass ein Strahl die gesamte Geometrie innerhalb einer Szene oder einem spezifizierten Gebiet einer Szene verfehlt.
    • Visit - gibt die Nachfolgevolumina an, die ein Strahl traversieren kann.
    • Ausnahmen - beinhaltet verschiedene Typen von Ausnahme-Handlern (z. B. für verschiedene Fehlerbedingungen aufgerufen).
  • In einer Ausführungsform können die Strahlverfolgungskerne 372 ausgelegt sein, um Universalrechenoperationen zu beschleunigen, die unter Verwendung von Rechentechniken beschleunigt werden können, die analog zu Strahlschnittprüfungen sind. Ein Rechen-Framework kann bereitgestellt werden, das ermöglicht, dass Shader-Programme in Anweisungen auf niedriger Ebene und/oder Primitive kompiliert werden, die Universalrechenoperationen über die Strahlverfolgungskerne durchführen. Beispielhafte Rechenprobleme, die von Rechenoperationen profitieren können, die auf den Strahlverfolgungskernen 372 ausgeführt werden, beinhalten Berechnungen, die eine Lichtstrahl-, Wellen-, Strahl- oder Partikelausbreitung innerhalb eines Koordinatenraums involvieren. Mit dieser Ausbreitung in Zusammenhang stehende Interaktionen können relativ zu einer Geometrie oder einem Netz innerhalb des Koordinatenraums berechnet werden. Zum Beispiel können Berechnungen, die mit elektromagnetischer Signalpropagation durch eine Umgebung assoziiert sind, über die Verwendung von Anweisungen oder Primitiven beschleunigt werden, die über die Strahlverfolgungskerne ausgeführt werden. Beugung und Spiegelung der Signale durch Objekte in der Umgebung können als direkte Strahlverfolgungsanalogien berechnet werden.
  • Strahlverfolgungskerne 372 können auch verwendet werden, um Berechnungen durchzuführen, die nicht direkt zur Strahlverfolgung analog sind. Zum Beispiel können Netzprojektions-, Netzverfeinerung- und Volumenabtastberechnungen unter Verwendung der Strahlverfolgungskerne 372beschleunigt werden. Generische Koordinatenraumberechnungen, wie Nächste-Nachbarn-Berechnungen, können ebenfalls durchgeführt werden. Zum Beispiel kann der Satz von Punkten nahe einem gegebenen Punkt entdeckt werden, indem ein Begrenzungsrahmen im Koordinatenraum um den Punkt herum definiert wird. BVH- und Strahlsondenlogik innerhalb der Strahlverfolgungskerne 372 können dann verwendet werden, um den Satz von Punktschnittpunkten innerhalb des Begrenzungsrahmens zu bestimmen. Die Schnitte stellen den Ursprungspunkt und die nächsten Nachbarn zu diesem Ursprungspunkt dar. Berechnungen, die unter Verwendung der Strahlverfolgungskerne 372 durchgeführt werden, können parallel mit Berechnungen durchgeführt werden, die auf den Grafikkernen 372 und den Tensorkernen 371 durchgeführt werden. Ein Shader-Compiler kann konfiguriert sein, einen Rechen-Shader oder ein anderes Universal-Grafikverarbeitungsprogramm in Primitive auf niedriger Ebene zu kompilieren, die über die Grafikkerne 370, Tensorkerne 371 und Strahlverfolgungskerne 372 parallelisiert werden können.
  • Techniken zur Verbindung zwischen GPU und Hostprozessor
  • 4A veranschaulicht eine beispielhafte Architektur, in der mehrere GPUs 410-413, z. B. wie die Parallelprozessoren 200, die in 2A gezeigt sind, über Hochgeschwindigkeits-Links 440A-440D (z. B. Busse, Punkt-zu-Punkt-Verbindungen usw.) kommunikativ mit mehreren Multi-Kern-Prozessoren 405-406 gekoppelt sind. Die Hochgeschwindigkeits-Links 440A-440D können je nach Implementierung einen Kommunikationsdurchsatz von 4GB/s, 30GB/s, 80GB/s oder mehr unterstützen. Verschiedene Interconnect-Protokolle können verwendet werden, einschließlich, jedoch nicht beschränkt auf PCIe 4.0 oder 5.0 und NVLink 2.0. Die hierin beschriebenen zugrundeliegenden Prinzipien sind jedoch nicht auf ein bestimmtes Kommunikationsprotokoll oder einen bestimmten Durchsatz beschränkt.
  • Zwei oder mehr der GPUs 410-413 können über Hochgeschwindigkeits-Links 442A-442B miteinander verbunden sein, die unter Verwendung der gleichen oder anderer Protokolle/Links als denen, die für die Hochgeschwindigkeits-Links 440A-440Dverwendet werden, implementiert werden können. In ähnlicher Weise können zwei oder mehrere der Mehrkernprozessoren 405-406 über einen Hochgeschwindigkeits-Link 443 verbunden sein, der symmetrische Multiprozessor-(SMP)-Busse sein kann, die mit 20GB/s, 30GB/s, 120GB/s oder niedrigeren oder höheren Geschwindigkeiten arbeiten. Alternativ kann die gesamte Kommunikation zwischen den verschiedenen Systemkomponenten in 4A unter Verwendung der gleichen Protokolle/Links (z. B. über eine gemeinsame Interconnect-Fabric) erreicht werden. Wie erwähnt, sind die hierin beschriebenen zugrundeliegenden Prinzipien jedoch nicht auf eine bestimmte Art von Interconnect-Technologie beschränkt.
  • Jeder Mehrkernprozessor 405-406 kann jeweils über Speicher-Interconnects 430A-430B kommunikativ mit einem Prozessorspeicher 401-402 gekoppelt sein, und jede GPU 410-413 ist jeweils über GPU-Speicher-Interconnects 450A-450D kommunikativ mit dem GPU-Speicher 420-423 gekoppelt. Die Speicher-Interconnects 430A-430B und 450A-450D können die gleiche oder unterschiedliche Speicherzugriffstechnologien nutzen. Zum Beispiel und ohne Einschränkung können die Prozessorspeicher 401-402 und die GPU-Speicher 420-423 flüchtige Speicher wie dynamische Direktzugriffsspeicher (DRAMs) (einschließlich gestapelter DRAMs), Grafik-DDR-SDRAM (GDDR) (z. B. GDDR5, GDDR6) oder High-Bandwidth-Memory (HBM) sein und/oder können nichtflüchtige Speicher wie 3D XPoint/Optane oder Nano-RAM sein. Beispielsweise kann ein Abschnitt der Speicher ein flüchtiger Speicher sein, und ein anderer Abschnitt kann ein nichtflüchtiger Speicher sein (z. B. unter Verwendung einer Hierarchie eines Two-Level-Speichers (2LM)). Ein Speichersubsystem, wie hierin beschrieben, kann mit einer Anzahl von Speichertechnologien kompatibel sein, wie mit Double-Data-Rate-Versionen, die von JEDEC (Joint Electronic Device Engineering Council) veröffentlicht wurden.
  • Wie nachstehend beschrieben, kann, wenngleich die verschiedenen Prozessoren 405-406 und GPUs 410-413 physisch j eweils mit einem bestimmten Speicher 401-402, 420-423 gekoppelt sein können, eine vereinheitlichte Speicherarchitektur implementiert sein, in der derselbe virtuelle Systemadressraum (auch als der „effektive Adressraum“ bezeichnet) unter allen verschiedenen physischen Speichern verteilt ist. Beispielsweise können die Prozessorspeicher 401-402 jeweils 64GB des Systemspeicheradressraums umfassen, und die GPU-Speicher 420-423 können jeweils 32GB des Systemspeicheradressraums umfassen (was in diesem Beispiel zu insgesamt 256GB adressierbaren Speichers führt).
  • 4B veranschaulicht zusätzliche optionale Einzelheiten für eine Zwischenverbindung zwischen einem Mehrkernprozessor 407 und einem Grafikbeschleunigungsmodul 446. Das Grafikbeschleunigungsmodul 446 kann einen oder mehrere GPU-Chips aufweisen, die auf einer Leitungskarte integriert sind, die über den Hochgeschwindigkeits-Link 440 mit dem Prozessor 407gekoppelt ist. Alternativ kann das Grafikbeschleunigungsmodul 446 auf dem gleichen Package oder Chip wie der Prozessor 407integriert sein.
  • Der veranschaulichte Prozessor 407 weist mehrere Kerne 460A-460Dauf, die jeweils einen Übersetzungspuffer 461A-461D und einen oder mehrere Caches 462A-462Daufweisen. Die Kerne können verschiedene andere Komponenten zum Ausführen von Anweisungen und zum Verarbeiten von Daten beinhalten, die nicht veranschaulicht sind, um zu vermeiden, dass die zugrundeliegenden Prinzipien der hierin beschriebenen Komponenten (z. B. Anweisungsabrufeinheiten, Verzweigungsvorhersageeinheiten, Decodierer, Ausführungseinheiten, Neuordnungspuffer usw.) verschleiert werden. Die Caches 462A-462D können Caches der Ebene 1 (L1) und der Ebene 2 (L2) umfassen. Außerdem können ein oder mehrere gemeinsam genutzte Caches 456 in der Caching-Hierarchie enthalten sein und von Sätzen der Kerne 460A bis 460Dgemeinsam genutzt werden. Zum Beispiel weist eine Ausführungsform des Prozessors 407 24 Kerne, jeweils mit ihrem eigenen L1-Cache, zwölf gemeinsam genutzten L2-Caches und zwölf gemeinsam genutzten L3-Caches auf. In dieser Ausführungsform wird einer der L2- und L3-Caches von zwei benachbarten Kernen gemeinsam genutzt. Der Prozessor 407 und das Grafikbeschleunigerintegrationsmodul 446 sind mit dem Systemspeicher 441 verbunden, der die Prozessorspeicher 401-402beinhalten kann.
  • Die Kohärenz wird für Daten und Anweisungen, die in den verschiedenen Caches 462A-462D, 456 und dem Systemspeicher 441 gespeichert sind, über eine Inter-Kern-Kommunikation über einen Kohärenzbus 464 aufrechterhalten. Zum Beispiel kann jeder Cache eine mit diesem assoziierte Cachekohärenzlogik/-schaltlogik aufweisen, um als Reaktion auf detektierte Lese- oder Schreibvorgänge in bestimmte Cachezeilen über den Kohärenzbus 464 zu kommunizieren. In einer Implementierung wird ein Cache-Snooping-Protokoll über den Kohärenzbus 464 implementiert, um Cachezugriffe zu snoopen. Cache-Snooping-/Kohärenztechniken sind für den Fachmann gut verständlich und können hier nicht ausführlich beschrieben werden, um zu vermeiden, die hierin beschriebenen zugrundeliegenden Prinzipien zu verschleiern.
  • Eine Proxyschaltung 425 kann bereitgestellt sein, die das Grafikbeschleunigungsmodul 446 kommunikativmit dem Kohärenzbus 464 koppelt, wodurch ermöglicht wird, dass das Grafikbeschleunigungsmodul 446 als ein Peer der Kerne am Cache-Kohärenzprotokoll teilnimmt. Insbesondere stellt eine Schnittstelle 435 eine Konnektivität zu der Proxyschaltung 425 über einen Hochgeschwindigkeits-Link 440 (z. B. einen PCIe-Bus, NVLink usw.) bereit und eine Schnittstelle 437 verbindet das Grafikbeschleunigungsmodul 446 mit dem Hochgeschwindigkeits-Link 440.
  • Bei einer Implementierung stellt eine Beschleunigerintegrationsschaltung 436 Cacheverwaltungs-, Speicherzugriffs-, Kontextverwaltungs- und Interrupt-Verwaltungsdienste für mehrere Grafikverarbeitungs-Engines 431, 432, N des Grafikbeschleunigungsmoduls 446bereit. Die Grafikverarbeitungs-Engines 431, 432, N können jeweils eine separate Grafikverarbeitungseinheit (GPU) umfassen. Alternativ dazu können die Grafikverarbeitungs-Engines 431, 432, N verschiedene Arten von Grafikverarbeitungs-Engines in einer GPU umfassen, wie Grafikausführungseinheiten, Medienverarbeitungs-Engines (z. B. Videocodierer/-Decodierer), Sampler und Blit-Engines. Mit anderen Worten kann das Grafikbeschleunigungsmodul eine GPU mit mehreren Grafikverarbeitungs-Engines 431-432, N sein oder können die Grafikverarbeitungs-Engines 431-432, N einzelne GPUs sein, die auf einem gemeinsamen Package, einer Leitungskarte oder einem Chip integriert sind.
  • Die Beschleunigerintegrationsschaltung 436 kann eine Speicherverwaltungseinheit (MMU: Memory Management Unit) 439 zum Durchführen verschiedener Speicherverwaltungsfunktionen wie Übersetzungen von virtuellem-inphysischen Speicher (auch als Übersetzungen von effektivem-in-realen Speicher bezeichnet) und Speicherzugriffsprotokolle zum Zugriff auf den Systemspeicher 441 beinhalten. Die MMU 439 kann auch einen Übersetzungspuffer (TLB: Translations-Lookaside-Puffer) (nicht gezeigt) zum Zwischenspeichern der Übersetzungen von virtuellen/effektiven-in-physische/reale Adressen aufweisen. In einer Implementierung speichert ein Cache 438 Befehle und Daten für einen effizienten Zugriff durch die Grafikverarbeitungs-Engines 431, 432, N. Die im Cache 438 und den Grafikspeichern 433-434, M gespeicherten Daten können mit den Kern-Caches 462A-462D, 456 und dem Systemspeicher 441 kohärent gehalten werden. Wie erwähnt, kann dies über die Proxyschaltung 425 erreicht werden, die am Cachekohärenzmechanismus für den Cache 438 und die Speicher 433-434, M teilnimmt (z. B. Senden von Aktualisierungen an den Cache 438 in Bezug auf Modifikationen/Zugriffe auf Cachezeilen auf den Prozessor-Caches 462A-462D, 456 und Empfangen von Aktualisierungen von dem Cache 438).
  • Ein Satz von Registern 445 speichert Kontextdaten für Threads, die durch die Grafikprozessor-Engines 431-432, N ausgeführt werden, und eine Kontextverwaltungsschaltung 448 verwaltet die Thread-Kontexte. Zum Beispiel kann die Kontextverwaltungsschaltung 448 Speicher- und Wiederherstellungsoperationen zum Speichern und Wiederherstellen von Kontexten der verschiedenen Threads während Kontextwechseln durchführen (z. B., wenn ein erster Thread gespeichert wird und ein zweiter Thread erneut gespeichert wird, sodass der zweite Thread durch eine Grafikverarbeitungs-Engine ausgeführt werden kann). Zum Beispiel kann die Kontextverwaltungsschaltung 448 bei einem Kontextwechsel aktuelle Registerwerte in einem designierten Bereich im Speicher (z. B. durch einen Kontextzeiger identifiziert) speichern. Sie kann dann die Registerwerte bei Rückkehr zu dem Kontext wiederherstellen. Eine Interrupt -Verwaltungsschaltung 447 kann zum Beispiel Interrupts empfangen und verarbeiten, die von Systemvorrichtungen empfangen werden.
  • In einer Implementierung werden virtuelle/effektive Adressen von einer Grafikverarbeitungs-Engine 431 durch die MMU 439 in reale/physische Adressen im Systemspeicher 441 übersetzt. Optional unterstützt die Beschleunigerintegrationsschaltung 436 mehrere (z. B. 4, 8, 16)Grafikbeschleunigermodule 446 und/oder andere Beschleunigervorrichtungen. Das Grafikbeschleunigermodul 446 kann für eine einzelne Anwendung dediziert sein, die auf dem Prozessor 407 ausgeführt wird, oder kann von mehreren Anwendungen gemeinsam genutzt werden. Optional wird eine virtualisierte Grafikausführungsumgebung bereitgestellt, in der die Ressourcen der Grafikverarbeitungs-Engines 431-432, N mit mehreren Anwendungen, virtuellen Maschinen (VMs) oder Containern gemeinsam genutzt werden. Die Ressourcen können in „Slices“ unterteilt sein, die verschiedenen VMs und/oder Anwendungen auf der Grundlage der den VMs und/oder den Anwendungen zugeordneten Verarbeitungsanforderungen und -prioritäten zugewiesen sind. VMs und Container können hierin austauschbar verwendet werden.
  • Eine virtuelle Maschine (VM) kann Software sein, die ein Betriebssystem und eine oder mehrere Anwendungen ausführt. Eine VM kann durch Spezifikation, Konfigurationsdateien, virtuelle Plattendatei, NVRAM-Einstelldatei (NVRAM: Volatile Random Access Memory - flüchtiger Direktzugriffsspeicher) und die Protokolldatei definiert werden und wird durch die physischen Ressourcen einer Host-Rechenplattform gesichert. Eine VM kann ein Betriebssystem (OS) oder eine Anwendungsumgebung beinhalten, die auf Software installiert ist, die dedizierte Hardware imitiert. Der Endbenutzer hat die gleiche Erfahrung auf einer virtuellen Maschine, wie er auf dedizierter Hardware haben würde. Spezialisierte Software, Hypervisor genannt, emuliert die CPU, den Speicher, die Festplatte, das Netzwerk und andere HardwareRessourcen des PC-Clients oder -Servers vollständig, wodurch es virtuellen Maschinen ermöglicht wird, die Ressourcen gemeinsam zu nutzen. Der Hypervisor kann mehrere virtuelle Hardwareplattformen emulieren, die voneinander isoliert sind, wodurch ermöglicht wird, dass virtuelle Maschinen Linux®, Windows® Server, VMware ESXi und andere Betriebssysteme auf demselben zugrundeliegenden physischen Host ausführen.
  • Ein Container kann ein Softwarepaket von Anwendungen, Konfigurationen und Abhängigkeiten sein, sodass die Anwendungen zuverlässig auf einer Rechenumgebung zu einer anderen laufen. Container können ein auf der Serverplattform installiertes Betriebssystem gemeinsam nutzen und als isolierte Prozesse ablaufen. Ein Container kann ein Softwarepaket sein, das Komponenten enthält, die die Software zum Ausführen verwendet, wie Systemwerkzeuge, Bibliotheken und Einstellungen. Container werden nicht wie herkömmliche Softwareprogramme installiert, wodurch sie von der anderen Software und dem Betriebssystem selbst isoliert werden können. Die isolierte Natur von Containern bietet mehrere Vorteile. Zuerst kann die Software in einem Container in unterschiedlichen Umgebungen gleich ausgeführt werden. Zum Beispiel kann ein Container, der PHP und MySQL beinhaltet, sowohl auf einem Linux®-Computer als auch auf einer Windows®-Maschine identisch laufen. Zweitens stellen Container zusätzliche Sicherheit bereit, da die Software das Host-Betriebssystem nicht beeinflussen kann. Obwohl eine installierte Anwendung Systemeinstellungen ändern und Ressourcen modifizieren kann, wie die Windows-Registry, kann ein Container nur Einstellungen innerhalb des Containers modifizieren.
  • Somit fungiert die Beschleunigerintegrationsschaltung 436 als eine Brücke zu dem System für das Grafikbeschleunigungsmodul 446 und stellt Adressübersetzungs- und Systemspeicher-Cachedienste bereit. In einer Ausführungsform kann die Beschleunigerintegrationsschaltung 436 zur Erleichterung der Überbrückungsfunktionalität auch gemeinsam genutzte E/A 497 (z. B. PCIe, USB oder andere) und Hardware beinhalten, um eine Systemsteuerung von Spannung, Taktung, Leistungsfähigkeit, Temperatur und Sicherheit zu ermöglichen. Die gemeinsam genutzte E/A 497 kann separate physische Verbindungen verwenden oder kann den Hochgeschwindigkeits-Link 440durchlaufen. Außerdem kann die Beschleunigerintegrationsschaltung 436 Virtualisierungseinrichtungen für den Hostprozessor bereitstellen, um die Virtualisierung der Grafikverarbeitungs-Engines, Interrupts und Speicherverwaltung zu verwalten.
  • Da Hardwareressourcen der Grafikverarbeitungs-Engines 431-432, N explizit auf den realen Adressraum abgebildet werden, den der Hostprozessor 407 sieht, kann jeder Hostprozessor diese Ressourcen direkt unter Verwendung eines effektiven Adresswerts adressieren. Eine optionale Funktion der Beschleunigerintegrationsschaltung 436 ist die physische Trennung der Grafikverarbeitungs-Engines 431-432, N, sodass sie dem System als unabhängige Einheiten erscheinen.
  • Ein oder mehrere Grafikspeicher 433-434, M können jeweils mit jeder der Grafikverarbeitungs-Engines 431-432, N gekoppelt sein. Die Grafikspeicher 433-434, M speichern Anweisungen und Daten, die von jeder der Grafikverarbeitungs-Engines 431-432, N verarbeitet werden. Die Grafikspeicher 433-434, M können flüchtige Speicher wie DRAMs (einschließlich gestapelter DRAMs), GDDR-Speicher (z. B. GDDR5, GDDR6) oder HBM sein, und/oder können nichtflüchtige Speicher wie 3D XPoint/Optane, Samsung Z-NAND oder Nano-RAM sein.
  • Um den Datenverkehr über den Hochgeschwindigkeits-Link 440zu reduzieren, können Biasing-Techniken verwendet werden, um sicherzustellen, dass die in den Grafikspeichern 433-434, M gespeicherten Daten Daten sind, die häufig von den Grafikverarbeitungs-Engines 431-432, N verwendet werden können und vorzugsweise nicht durch von den Kernen 460A-460D (zumindest nicht häufig) verwendet werden können. Gleichermaßen versucht der Biasing-Mechanismus, Daten, die von den Kernen (und vorzugsweise nicht von den Grafikverarbeitungs-Engines 431-432, N) genutzt werden, in den Caches 462A-462D, 456 der Kerne und des Systemspeichers 441 zu halten.
  • Gemäß einer in 4C gezeigten Variante ist die Beschleunigerintegrationsschaltung 436 innerhalb des Prozessors 407 integriert. Die Grafikverarbeitungs-Engines 431-432, N kommunizieren direkt über den Hochgeschwindigkeits-Link 440 mit der Beschleunigerintegrationsschaltung 436 über die Schnittstelle 437 und die Schnittstelle 435 (die wiederum eine beliebige Form von Bus- oder Schnittstellenprotokoll verwenden können). Die Beschleunigerintegrationsschaltung 436 kann die gleichen Operationen wie jene durchführen, die mit Bezug auf 4B beschrieben sind, jedoch möglicherweise bei einem höheren Durchsatz aufgrund ihrer unmittelbaren Nähe zum Kohärenzbus 464 und den Caches 462A-462D, 456.
  • Die beschriebenen Ausführungsformen können verschiedene Programmiermodelle unterstützen, einschließlich eines Programmiermodells mit dedizierten Prozessen (keine Virtualisierung des Grafikbeschleunigungsmoduls) und gemeinsam genutzten Programmiermodellen (mit Virtualisierung). Letztere können Programmiermodelle, die von der Beschleunigerintegrationsschaltung 436 gesteuert werden, und Programmiermodelle, die von dem Grafikbeschleunigungsmodul 446 gesteuert werden, beinhalten.
  • In den Ausführungsformen des dedizierten Prozessmodells können die Grafikverarbeitungs-Engines 431, 432, ... N für eine einzelne Anwendung oder einen einzelnen Prozess unter einem einzigen Betriebssystem dediziert sein. Die einzelne Anwendung kann andere Anwendungsanfragen an die Grafik-Engines 431, 432, ... N leiten und eine Virtualisierung innerhalb einer VM/Partition bereitstellen.
  • In den Programmiermodellen mit dedizierten Prozessen können die Grafikverarbeitungs-Engines 431, 432, N von mehreren VM/Anwendungspartitionen gemeinsam genutzt werden. Die gemeinsam genutzten Modelle nutzen einen Systemhypervisor zur Virtualisierung der Grafikverarbeitungs-Engines 431-432, N, um einen Zugriff durch jedes Betriebssystem zu ermöglichen. Für Einzelpartitionssysteme ohne Hypervisor gehören die Grafikverarbeitungs-Engines 431-432, N dem Betriebssystem. In beiden Fällen kann das Betriebssystem die Grafikverarbeitungs-Engines 431-432, N virtualisieren, um Zugriff auf jeden Prozess oder jede Anwendung bereitzustellen.
  • Für das gemeinsam genutzte Programmiermodell wählt das Grafikbeschleunigungsmodul 446 oder eine einzelne Grafikverarbeitungs-Engine 431-432, N ein Prozesselement unter Verwendung eines Prozess-Handles aus. Die Prozesselemente können in dem Systemspeicher 441 gespeichert werden und unter Verwendung der hierin beschriebenen Techniken zur Übersetzung von effektiven Adressen in reale Adressen adressierbar sein. Die Prozesskennung kann ein implementierungsspezifischer Wert sein, der dem Hostprozess bereitgestellt wird, wenn sein Kontext bei der Grafikverarbeitungs-Engine 431-432, N registriert wird (das heißt, Systemsoftware aufgerufen wird, um das Prozesselement zu der mit dem Prozesselement verknüpften Liste hinzuzufügen). Die unteren 16 Bits der Prozesskennung können der Versatz des Prozesselements innerhalb der mit dem Prozesselement verknüpften Liste sein.
  • 4D veranschaulicht einen beispielhaften Beschleunigerintegrations-Slice 490. Wie hierin verwendet, umfasst ein „Slice“ einen spezifizierten Abschnitt der Verarbeitungsressourcen der Beschleunigerintegrationsschaltung 436. Der effektive Anwendungsadressraum 482 im Systemspeicher 441 speichert Prozesselemente 483. Die Prozesselemente 483 können als Reaktion auf GPU-Aufrufe 481 von Anwendungen 480 , die auf dem Prozessor 407 ausgeführt werden, gespeichert werden. Ein Prozesselement 483 enthält den Prozesszustand für die entsprechende Anwendung 480. Ein Arbeitsdeskriptor (WD: Work Descriptor) 484 , der in dem Prozesselement 483 enthalten ist, kann ein einziger Arbeitsauftrag sein, der von einer Anwendung angefordert wird, oder er kann einen Zeiger auf eine Warteschlange von Arbeitsaufträgen enthalten. Im letzteren Fall ist der WD 484 ein Zeiger auf die Arbeitsauftragsanforderungswarteschlange im Adressraum 482 der Anwendung.
  • Das Grafikbeschleunigungsmodul 446 und/oder die einzelnen Grafikverarbeitungs-Engines 431-432, N können von allen oder einer Teilmenge der Prozesse in dem System gemeinsam genutzt werden. Beispielsweise können die hierin beschriebenen Technologien eine Infrastruktur zum Einrichten des Prozesszustands und zum Senden eines WD 484 an ein Grafikbeschleunigungsmodul 446 zum Starten eines Arbeitsauftrags in einer virtualisierten Umgebung beinhalten.
  • In einer Implementierung ist das Programmiermodell mit dedizierten Prozessen implementierungsspezifisch. In diesem Modell gehört das Grafikbeschleunigungsmodul 446 oder eine einzelne Grafikverarbeitungs-Engine 431 einem einzelnen Prozess. Da das Grafikbeschleunigungsmodul 446 einem einzelnen Prozess gehört, initialisiert der Hypervisor die Beschleunigerintegrationsschaltung 436 für die besitzende Partition und das Betriebssystem initialisiert die Beschleunigerintegrationsschaltung 436 für den besitzenden Prozess zu dem Zeitpunkt, zu dem das Grafikbeschleunigungsmodul 446 zugewiesen wird.
  • Während des Betriebs ruft eine WD-Abrufeinheit 491 in der Beschleunigerintegrations-Slice 490 den nächsten WD 484 ab, der eine Angabe der von einer der Grafikverarbeitungs-Engines des Grafikbeschleunigungsmoduls 446 vorzunehmenden Arbeit beinhaltet. Daten von dem WD 484 können in Registern 445 gespeichert und von der MMU 439, der Interrupt-Verwaltungsschaltung 447 und/oder der Kontext-Verwaltungsschaltung 448 verwendet werden, wie veranschaulicht. Zum Beispiel kann die MMU 439 eine Segment-/Seitentabellen-Schaltlogik zum Zugreifen auf Segment-/Seitentabellen 486 innerhalb des virtuellen OS-Adressraums 485beinhalten. Die Interrupt-Verwaltungsschaltung 447 kann Interrupt -Ereignisse 492 verarbeiten, die von dem Grafikbeschleunigungsmodul 446 empfangen werden. Beim Durchführen von Grafikoperationen wird eine von einer Grafikverarbeitungs-Engine 431-432, N erzeugte effektive Adresse 493 von der MMU 439 in eine reale Adresse übersetzt.
  • Der gleiche Satz von Registern 445 kann für jede Grafikverarbeitungs-Engine 431-432, N und/oder das Grafikbeschleunigungsmodul 446 dupliziert werden und kann vom Hypervisor oder dem Betriebssystem initialisiert werden. Jedes dieser duplizierten Register kann in einem Beschleunigerintegrations-Slice 490enthalten sein. In einer Ausführungsform kann jede Grafikverarbeitungs-Engine 431-432, N dem Hypervisor 496 als eine getrennte Grafikprozessorvorrichtung präsentiert werden. QoS-Einstellungen können für Clients einer spezifischen Grafikverarbeitungs-Engine 431-432konfiguriert sein, N und eine Datenisolation zwischen den Clients jeder Engine kann aktiviert werden. Beispielhafte Register, die vom Hypervisor initialisiert werden können, sind in Tabelle 1gezeigt. Tabelle 1 - Von Hypervisor initialisierte Register
    1 Slice-Steuerregister
    2 Bereichszeiger für geplante Prozesse für reale Adresse (RA)
    3 Autoritätsmasken-Überschreibungsregister
    4 Interrupt-Vektor-Tabelleneintragsversatz
    5 Interrupt-Vektor-Tabelleneintragsgrenze
    6 Zustandsregister
    7 Logikpartitions-ID
    8 Aufzeichnungszeiger zur Hypervisorbeschleunigernutzung für reale Adresse (RA)
    9 Speicherungsbeschreibungsregister
  • Beispielhafte Register, die vom Betriebssystem initialisiert werden können, sind in Tabelle 2gezeigt. Tabelle 2 - Vom Betriebssystem initialisierte Register
    1 Prozess- und Thread-Identifizierung
    2 Zeiger für Kontext-Speichern/Wiederherstellen für effektive Adresse (EA)
    3 Aufzeichnungszeiger zur Beschleunigernutzung für virtuelle Adresse (VA)
    4 Zeiger für Speichersegmenttabelle für virtuelle Adresse (VA)
    5 Autoritätsmaske
    6 Arbeitsdeskriptor
  • Jeder WD 484 kann für ein bestimmtes Grafikbeschleunigungsmodul 446 und/oder eine Grafikverarbeitungs-Engine 431-432, N spezifisch sein. Er enthält alle Informationen, die eine Grafikverarbeitungs-Engine 431-432verwendet, um ihre Arbeit zu tun, oder er kann ein Zeiger auf einen Speicherort sein, an dem die Anwendung eine Befehlswarteschlange mit auszuführenden Arbeiten eingerichtet hat.
  • 4E veranschaulicht zusätzliche optionale Details eines gemeinsam genutzten Modells. Es beinhaltet einen realen Hypervisor-Adressraum 498 , in dem eine Prozesselementliste 499 gespeichert ist. Der reale Hypervisor-Adressraum 498 ist über einen Hypervisor 496 zugänglich, der die Grafikbeschleunigungsmodul-Engines für das Betriebssystem 495 virtualisiert.
  • Die gemeinsam genutzten Programmiermodelle ermöglichen, dass alle oder eine Teilmenge von Prozessen von allen oder einer Teilmenge von Partitionen in dem System ein Grafikbeschleunigungsmodul 446verwenden. Es gibt zwei Programmiermodelle, bei denen das Grafikbeschleunigungsmodul 446 von mehreren Prozessen und Partitionen gemeinsam genutzt wird: Eine gemeinsame Nutzung nach Zeit-Slices und eine grafikgerichtete gemeinsame Nutzung.
  • In diesem Modell besitzt der Systemhypervisor 496 das Grafikbeschleunigungsmodul 446 und stellt dessen Funktion allen Betriebssystemen 495 zur Verfügung. Damit ein Grafikbeschleunigungsmodul 446 eine Virtualisierung durch den Systemhypervisor 496unterstützt, kann das Grafikbeschleunigungsmodul 446 die folgenden Anforderungen erfüllen: 1) Die Arbeitsauftragsanfrage einer Anwendung sollte autonom sein (das heißt, der Zustand muss nicht zwischen Arbeitsaufträgen aufrechterhalten werden), oder das Grafikbeschleunigungsmodul 446 sollte einen Kontextspeicher- und -wiederherstellungsmechanismus bereitstellen. 2) Das Grafikbeschleunigungsmodul 446 garantiert, dass eine Arbeitsauftragsanforderung einer Anwendung innerhalb einer spezifizierten Zeitdauer abgeschlossen wird, einschließlich etwaiger Übersetzungsfehler, oder das Grafikbeschleunigungsmodul 446 stellt die Fähigkeit bereit, die Verarbeitung des Arbeitsauftrags zurückzustellen. 3) Dem Grafikbeschleunigungsmodul 446 sollte Fairness zwischen Prozessen garantiert werden, wenn es in dem gerichteten gemeinsam genutzten Programmiermodell arbeitet.
  • Für das gemeinsam genutzte Modell kann die Anwendung 480 genutzt werden, um einen Systemsystemaufruf des Betriebssystems 495 mit einem Typ des Grafikbeschleunigungsmoduls 446, einem Arbeitsdeskriptor (WD), einem AMR-Wert (AMR: Authority Mask Register) und einem Kontextspeicherungs-/- wiederherstellungsbereichszeiger (Context Save/Restore Area Pointer - CSRP) durchzuführen. Der Typ des Grafikbeschleunigungsmoduls 446 beschreibt die Zielbeschleunigungsfunktion für den Systemaufruf. Der Typ des Grafikbeschleunigungsmoduls 446 kann ein systemspezifischer Wert sein. Der WD ist speziell für das Grafikbeschleunigungsmodul 446 formatiert und kann in Form eines Befehls des Grafikbeschleunigungsmoduls 446, eines Effektivadresszeigers auf eine benutzerdefinierte Struktur, eines Effektivadresszeigers auf eine Warteschlange von Befehlen oder einer beliebigen anderen Datenstruktur zum Beschreiben der vom Grafikbeschleunigungsmodul 446 zu verrichtenden Arbeit vorliegen. In einer Ausführungsform ist der AMR-Wert der AMR-Zustand, der für den aktuellen Prozess zu verwenden ist. Der an das Betriebssystem übergebene Wert ähnelt einer Anwendung, die den AMR einstellt. Falls die Implementierungen der Beschleunigerintegrationsschaltung 436 und des Grafikbeschleunigungsmoduls 446 kein Benutzerautoritätsmasken-Überschreibungsregister (UAMOR: User Authority Mask Override Register) unterstützen, kann das Betriebssystem den aktuellen UAMOR-Wert auf den AMR-Wert anwenden, bevor der AMR in dem Hypervisor-Aufruf übergeben wird. Der Hypervisor 496 kann den aktuellen Autoritätsmasken-Überschreibungsregister-(AMOR: Authority Mask Override Register)-Wert anwenden, bevor das AMR in das Prozesselement 483 platziert wird. Der CSRP kann eines der Register 445 sein, das die effektive Adresse eines Bereichs im Adressraum 482 der Anwendung für das Grafikbeschleunigungsmodul 446 zum Speichern und Wiederherstellen des Kontextstatus enthält. Dieser Zeiger ist optional, falls kein Status verwendet wird, um zwischen Arbeitsaufträgen gespeichert zu werden oder wenn ein Arbeitsauftrag vorzeitig beendet wird. Der Kontextspeicherungs-/-wiederherstellungsbereich kann ein festgelegter Systemspeicher sein.
  • Beim Empfang des Systemaufrufs kann das Betriebssystem 495 verifizieren, dass die Anwendung 480 registriert wurde und die Berechtigung zur Verwendung des Grafikbeschleunigungsmoduls 446 erhalten hat. Das Betriebssystem 495 ruft dann den Hypervisor 496 mit den in Tabelle 3 dargestellten Informationen auf. Tabelle 3 - OS-zu-Hypervisor-Aufrufparameter
    1 Ein Arbeitsdeskriptor (WD)
    2 Ein Autoritätsmaskenregister-(AMR)-Wert (möglicherweise maskiert).
    3 Ein Bereichszeiger für Kontext-Speichern/-Wiederherstellen (CSRP) für effektive Adresse (EA)
    4 Eine Prozess-ID (PID) und optionale Thread-ID (TID)
    5 Ein Aufzeichnungszeiger zur Beschleunigernutzung für virtuelle Adresse (VA)
    6 Die virtuelle Adresse des Speichersegmenttabellenzeigers (SSTP)
    7 Eine logische Interrupt-Dienstnummer (LISN)
  • Nach Empfang des Hypervisor-Aufrufs verifiziert der Hypervisor 496, dass das Betriebssystem 495 registriert wurde und die Berechtigung zur Verwendung des Grafikbeschleunigungsmoduls 446erhalten hat. Der Hypervisor 496 fügt dann das Prozesselement 483 in die verknüpfte Prozesselementliste für den entsprechenden Typ des Grafikbeschleunigungsmoduls 446 ein. Das Prozesselement kann die in Tabelle 4 dargestellten Informationenbeinhalten. Tabelle 4 - Prozesselementinformationen
    1 Ein Arbeitsdeskriptor (WD)
    2 Ein Autoritätsmaskenregister-(AMR)-Wert (möglicherweise maskiert).
    3 Ein Bereichszeiger für Kontext-Speichern/-Wiederherstellen (CSRP) für effektive Adresse (EA)
    4 Eine Prozess-ID (PID) und optionale Thread-ID (TID)
    5 Ein Aufzeichnungszeiger zur Beschleunigernutzung für virtuelle Adresse (VA)
    6 Die virtuelle Adresse des Speichersegmenttabellenzeigers (SSTP)
    7 Eine logische Interrupt-Dienstnummer (LISN)
    8 Interrupt-Vektortabelle, abgeleitet von den Hypervisor-Aufrufparametern.
    9 Ein Zustandsregister-(SR)-Wert
    10 Eine Logikpartitions-ID (LPID)
    11 Ein Aufzeichnungszeiger zur Beschleunigernutzung für reale Adresse (RA)
    12 Das Speicherungsdeskriptorregister (SDR)
  • Der Hypervisor kann mehrere Registern 445 des Beschleunigerintegrations-Slice 490 initialisieren.
  • Wie in 4F veranschaulicht, wird in einer optionalen Implementierung ein vereinheitlichter Speicher, der über einen gemeinsamen virtuellen Speicheradressraum adressierbar ist, der zum Zugriff auf die physischen Prozessorspeicher 401-402 und GPU-Speicher 420-423 verwendet wird, eingesetzt. Bei dieser Implementierung verwenden auf den GPUs 410-413 ausgeführte Operationen den gleichen virtuellen/effektiven Speicheradressraum, um auf die Prozessorspeicher 401-402 zuzugreifen und umgekehrt, wodurch die Programmierbarkeit vereinfacht wird. Ein erster Abschnitt des virtuellen/effektiven Speicheradressraums kann dem Prozessorspeicher 401, ein zweiter Abschnitt dem zweiten Prozessorspeicher 402, ein dritter Abschnitt dem GPU-Speicher 420usw. zugewiesen sein. Der gesamte virtuelle/effektive Speicherraum (manchmal als effektiver Adressraum bezeichnet) kann dadurch auf jeden der Prozessorspeicher 401-402 und GPU-Speicher 420-423 verteilt werden, wodurch ermöglicht wird, dass jeder Prozessor oder jede GPU auf einen beliebigen physischen Speicher mit einer auf diesen Speicher abgebildeten virtuellen Adresse zugreifen kann.
  • Eine Bias-/Kohärenz-Verwaltungsschaltlogik 494A-494E innerhalb einer oder mehrerer der MMUs 439A-439E kann bereitgestellt sein, die die Cache-Kohärenz zwischen den Caches der Hostprozessoren (z. B. 405) und den GPUs 410-413 sicherstellt und Biasing-Techniken implementiert, die die physischen Speicher anzeigen, in denen bestimmte Arten von Daten gespeichert werden sollten. Während mehrere Instanzen der Bias-/Kohärenz-Verwaltungsschaltlogik 494A-494E in 4F veranschaulicht sind, kann die Bias-/Kohärenz-Schaltung innerhalb der MMU eines oder mehrerer HostProzessoren 405 und/oder innerhalb der Beschleuniger-Integrationsschaltung 436implementiert sein.
  • Der an die GPU angeschlossene Speicher 420-423 kann als Teil des Systemspeichers abgebildet werden und auf ihn kann unter Verwendung einer SVM-Technologie (SVM: Shared Virtual Memory - gemeinsam genutzter Speicher) zugegriffen werden, ohne jedoch unter den typischen Leistungsnachteilen zu leiden, die mit vollständiger System-Cache-Kohärenz in Zusammenhang gebracht werden. Die Möglichkeit, auf den an die GPU angeschlossenen Speicher 420-423 als Systemspeicher ohne lästigen Cache-Kohärenz-Overhead zuzugreifen, bietet eine vorteilhafte Betriebsumgebung für GPU-Offload. Diese Anordnung ermöglicht der Software des Hostprozessors 405, ohne den Overhead herkömmlicher E/A-DMA-Datenkopien Operanden einzurichten und auf Berechnungsergebnisse zuzugreifen. Solche herkömmlichen Kopien beinhalten Treiberaufrufe, Interrupts und speicherabgebildete E/A-Zugriffe (MMIO-Zugriffe - Memory Mapped Input/Output), die alle in Bezug auf einfache Speicherzugriffe ineffizient sind. Gleichzeitig kann die Fähigkeit, ohne Cache-Kohärenz-Overhead auf den an die GPU angeschlossenen Speicher 420-423 zuzugreifen, zur Ausführungszeit einer ausgelagerten Berechnung beitragen. In Fällen mit erheblichem Streaming-Schreibspeicherverkehr kann beispielsweise der Cache-Kohärenz-Overhead die effektive Schreibbandbreite, die eine GPU 410-413erfährt, erheblich reduzieren. Die Effizienz der Operandeneinrichtung, die Effizienz des Ergebniszugriffs und die Effizienz der GPU-Berechnung spielen alle eine Rolle bei der Bestimmung der Effektivität des GPU-Offloads.
  • Eine Auswahl zwischen GPU-Bias und Hostprozessor-Bias kann durch eine Bias-Tracker-Datenstruktur gesteuert werden. Beispielsweise kann eine Bias-Tabelle verwendet werden, die eine seitengranulare Struktur sein kann (d. h. mit der Granularität einer Speicherseite gesteuert werden kann), die 1 oder 2 Bits pro GPU-angeschlossener Speicherseite aufweist. Die Bias-Tabelle kann in einem gestohlenen Speicherbereich eines oder mehrerer an die GPU angeschlossener Speicher 420-423mit oder ohne Bias-Cache in der GPU 410-413 implementiert sein (z. B. um häufig/kürzlich verwendete Einträge der Bias-Tabelle zwischenzuspeichern). Alternativ kann die gesamte Bias-Tabelle in der GPU gehalten werden.
  • In einer Implementierung wird auf den Bias-Tabelleneintrag, der jedem Zugriff auf den an die GPU angeschlossenen Speicher 420-423 zugeordnet ist, vor dem eigentlichen Zugriff auf den GPU-Speicher zugegriffen, was die folgenden Operationen bewirkt. Zunächst werden lokale Anforderungen von der GPU 410-413, die ihre Seite in GPU-Bias finden, direkt an einen entsprechenden GPU-Speicher 420-423 weitergeleitet. Lokale Anforderungen von der GPU, die ihre Seite in Host-Bias finden, werden an den Prozessor 405 weitergeleitet (z. B. über einen Hochgeschwindigkeits-Link, wie oben erläutert). Optional schließen Anforderungen von dem Prozessor 405, die die angeforderte Seite in Hostprozessor-Bias finden, die Anforderung wie einen normalen Speicherlesevorgang ab. Alternativ dazu können Anforderungen, die an eine Seite mit GPU-Bias gerichtet sind, an die GPU 410-413 weitergeleitet werden. Die GPU kann dann die Seite zu einem Hostprozessor-Bias überführen, wenn sie die Seite derzeit nicht verwendet.
  • Der Bias-Zustand einer Seite kann entweder durch einen softwarebasierten Mechanismus, einen hardwaregestützten softwarebasierten Mechanismus oder für einen begrenzten Satz von Fällen einen rein hardwarebasierten Mechanismus geändert werden.
  • Ein Mechanismus zum Ändern des Bias-Zustands verwendet einen API-Aufruf (z. B. OpenCL), der wiederum den Vorrichtungstreiber der GPU aufruft, der wiederum eine Nachricht an die GPU sendet (oder einen Befehlsdeskriptor in eine Warteschlange einreiht), die sie anweist, den Bias-Zustand zu ändern und für manche Übergänge eine Cache-Entleerungsoperation im Host durchzuführen. Die Cache-Entleerungsoperation wird für einen Übergang vom Bias des Hostprozessors 405 zum GPU-Bias verwendet, wird jedoch für den umgekehrten Übergang nicht genutzt.
  • Die Cache-Kohärenz kann dadurch aufrechterhalten werden, dass bewirkt wird, dass Seiten mit GPU-Bias vom Hostprozessor 405 vorübergehend nicht zwischengespeichert werden können. Um auf diese Seiten zuzugreifen, kann der Prozessor 405 Zugriff von der GPU 410 anfordern, die je nach der Implementierung einen sofortigen Zugriff gewähren kann oder nicht. Somit ist es zur Reduzierung von Kommunikation zwischen dem Hostprozessor 405 und der GPU 410 vorteilhaft, sicherzustellen, dass Seiten mit GPU-Bias jene sind, die von der GPU, jedoch nicht dem Hostprozessor 405 genutzt werden, und umgekehrt.
  • Grafikverarbeitungs-Pipeline
  • 5 veranschaulicht eine Grafikverarbeitungs-Pipeline 500. Ein Grafikmultiprozessor, wie der Grafikmultiprozessor 234, wie in 2D, Grafikmultiprozessor 325 von 3A, Grafikmultiprozessor 350 von 3B, kann die veranschaulichte Grafikverarbeitungs-Pipeline 500implementieren. Der Grafikmultiprozessor kann in den hier beschriebenen Parallelverarbeitungssubsystemen enthalten sein, wie dem Parallelprozessor 200 von 2A, der sich auf den bzw. die Parallelprozessor(en) 112 von 1 beziehen kann und anstelle von einem von diesen verwendet werden kann. Die verschiedenen Parallelverarbeitungssysteme können die Grafikverarbeitungs-Pipeline 500 über eine oder mehrere Instanzen der Parallelverarbeitungseinheit (z. B. Parallelverarbeitungseinheit 202 von 2A) implementieren, wie hierin beschrieben. Zum Beispiel kann eine Shader-Einheit (z.B. Grafikmultiprozessor 234 von 2C) dazu konfiguriert sein, die Funktionen einer oder mehrerer von einer Vertex-Verarbeitungseinheit 504, einer Tessellationssteuerverarbeitungseinheit 508, einer Tessellationsauswertungsverarbeitungseinheit 512, einer Geometrieverarbeitungseinheit 516 und einer Fragment-/Pixelverarbeitungseinheit 524auszuführen. Die Funktionen des Datenassemblers 502, der Primitiv-Assembler 506, 514, 518, der Tessellationseinheit 510, des Rasterisierers 522 und der Rasteroperationseinheit 526 können auch von anderen Verarbeitungs-Engines innerhalb eines Verarbeitungs-Clusters (z. B. Verarbeitungscluster 214 von 2A) und einer entsprechenden Partitionseinheit (z. B. Partitionseinheit 220A-220N von 2A) durchgeführt werden. Die Grafikverarbeitungs-Pipeline 500 kann auch unter Verwendung dedizierter Verarbeitungseinheiten für eine oder mehrere Funktionen implementiert werden. Es ist auch möglich, dass ein oder mehrere Abschnitte der Grafikverarbeitungs-Pipeline 500 von einer Parallelverarbeitungslogik in einem Universalprozessor (z. B. CPU) ausgeführt werden. Optional können ein oder mehrere Abschnitte der Grafikverarbeitungs-Pipeline 500 auf einen On-Chip-Speicher (z. B. den Parallelprozessorspeicher 222 wie in 2A) über eine Speicherschnittstelle 528 zugreifen, die eine Instanz der Speicherschnittstelle 218 von 2A sein kann. Die Grafikprozessor-Pipeline 500 kann auch über eine Mehrkerngruppe 365A wie in 3C implementiert sein.
  • Der Daten-Assembler 502 ist eine Verarbeitungseinheit, die Vertexdaten für Oberflächen und Primitive sammelt. Der Daten-Assembler 502 gibt dann die Vertex-Daten einschließlich der Vertex-Attribute an die Vertex-Verarbeitungseinheit 504 aus. Die Vertex-Verarbeitungseinheit 504 ist eine programmierbare Ausführungseinheit, die Vertex-Shader-Programme ausführt und Vertexdaten wie durch die Vertex-Shader-Programme spezifiziert beleuchtet und transformiert. Die Vertex-Verarbeitungseinheit 504 liest Daten, die im Cache-, Lokal- oder Systemspeicher gespeichert sind, zur Verwendung bei der Verarbeitung der Vertexdaten und kann so programmiert sein, dass sie die Vertexdaten von einer objektbasierten Koordinatendarstellung in einen Weltkoordinatenraum oder einen normalisierten Vorrichtungskoordinatenraum transformiert.
  • Eine erste Instanz eines Primitiv-Assemblers 506 empfängt Vertex-Attribute von der Vertex-Verarbeitungseinheit 504. Der Primitiv-Assembler 506 liest nach Bedarf gespeicherte Vertex-Attribute aus und konstruiert Grafikprimitive zur Verarbeitung von der Tessellationssteuerverarbeitungseinheit 508. Die Grafikprimitive beinhalten Dreiecke, Liniensegmente, Punkte, Felder und so weiter, wie durch verschiedene Grafikverarbeitungs-Anwendungsprogrammierschnittstellen (APIs) unterstützt.
  • Die Tessellationssteuerverarbeitungseinheit 508 behandelt die Eingabe-Vertices als Steuerpunkte für ein geometrisches Feld. Die Steuerpunkte werden von einer Eingabedarstellung von dem Feld (z. B. den Basen des Felds) in eine Darstellung transformiert, die zur Verwendung bei der Oberflächenauswertung durch die Tessellationsauswertungsverarbeitungseinheit 512geeignet ist. Die Tessellationssteuerverarbeitungseinheit 508 kann auch Tessellationsfaktoren für Kanten geometrischer Felder berechnen. Ein Tessellationsfaktor gilt für eine einzelne Kante und quantifiziert einen mit der Kante assoziierten ansichtsabhängigen Detailgrad. Eine Tessellationseinheit 510 ist konfiguriert, die Tessellationsfaktoren für Kanten eines Patches zu empfangen und das Patch in mehrere geometrische Primitive wie Linien-, Dreieck- oder Viereck-Primitive zu tessellieren, die an eine Tessellationsauswertungsverarbeitungseinheit 512übertragen werden. Die Tessellationsauswertungsverarbeitungseinheit 512 arbeitet mit parametrisierten Koordinaten des unterteilten Felds, um eine Oberflächendarstellung und Vertexattribute für jeden mit den geometrischen Primitiven zugehörigen Vertex zu erzeugen.
  • Eine zweite Instanz eines Primitiv-Assemblers 514 empfängt Vertex-Attribute von der Tessellationsauswertungsverarbeitungseinheit 512, liest gespeicherte Vertex-Attribute nach Bedarf und konstruiert Grafikprimitive zur Verarbeitung durch die Geometrieverarbeitungseinheit 516. Die Geometrieverarbeitungseinheit 516 ist eine programmierbare Ausführungseinheit, die Geometrie-Shader-Programme ausführt, um Grafikprimitive, die von dem primitiv-Assembler 514 empfangen werden, wie durch die Geometrie-Shader-Programme spezifiziert zu transformieren. Die Geometrieverarbeitungseinheit 516 kann dazu programmiert sein, die Grafikprimitive in ein oder mehrere neue Grafikprimitive zu unterteilen und Parameter zu berechnen, die zum Rasterisieren der neuen Grafikprimitive verwendet werden.
  • Die Geometrieverarbeitungseinheit 516 kann in der Lage sein, Elemente im Geometriestrom hinzuzufügen oder zu löschen. Die Geometrieverarbeitungseinheit 516 gibt die Parameter und Vertices, die neue Grafik-Primitive spezifizieren, an den Primitiv-Assembler 518aus. Der Primitiv-Assembler 518 empfängt die Parameter und Vertices von der Geometrie-Verarbeitungseinheit 516 und konstruiert Grafik-Primitive zur Verarbeitung durch eine Ansichtsfeldskalierungs-, Cull- und Clip-Einheit 520. Die Geometrieverarbeitungseinheit 516 liest Daten, die im Parallelprozessorspeicher oder Systemspeicher gespeichert sind, zur Verwendung bei der Verarbeitung der Geometriedaten. Die Ansichtsfeldskalierungs-, Cull- und Clip-Einheit 520 führt ein Clipping, Culling und eine Ansichtsfeldskalierung aus und gibt verarbeitete Grafik-Primitive an einen Rasterisierer 522aus.
  • Der Rasterisierer 522 kann Tiefen-Culling und andere tiefenbasierte Optimierungen durchführen. Der Rasterisierer 522 führt auch eine Scan-Umwandlung an den neuen Grafik-Primitiven aus, um Fragmente zu generieren, und gibt diese Fragmente und die zugehörigen Abdeckungsdaten an die Fragment/Pixel-Verarbeitungseinheit 524aus. Die Fragment/Pixel-Verarbeitungseinheit 524 ist eine programmierbare Ausführungseinheit, die konfiguriert ist, um Fragment-Shader-Programme oder Pixel-Shader-Programme auszuführen. Die Fragment/Pixel-Verarbeitungseinheit 524 transformiert Fragmente oder Pixel, die von dem Rasterisierer 522empfangen werden, wie durch die Fragment- oder Pixel-Shader-Programme spezifiziert. Zum Beispiel kann die Fragment/Pixel-Verarbeitungseinheit 524 programmiert sein, Operationen auszuführen, die einschließen, jedoch nicht beschränkt sind auf Texturabbildung, Shading, Mischen, Texturkorrektur und Perspektivenkorrektur, um schattierte Fragmente oder Pixel zu erzeugen, die an eine Rasteroperationseinheit 526 ausgegeben werden. Die Fragment/Pixel-Verarbeitungseinheit 524 kann Daten lesen, die entweder im Parallelprozessorspeicher oder im Systemspeicher zur Verwendung bei der Verarbeitung der Fragmentdaten gespeichert sind. Fragment- oder Pixel-Shader-Programme können derart konfiguriert sein, dass sie je nach der Abtastrate, die für die Verarbeitungseinheiten konfiguriert ist, bei Abtastung, Pixel, Kachel oder anderen Granularitäten schattieren.
  • Die Rasteroperationseinheit 526 ist eine Verarbeitungseinheit, die Rasteroperationen durchführt, einschließlich, jedoch nicht beschränkt auf Schablone, z-Test, Mischen und dergleichen, und Pixeldaten als verarbeitete Grafikdaten ausgibt, die im Grafikspeicher (z. B. Parallelprozessorspeicher 222 wie in 2A und/oder Systemspeicher 104 wie in 1) gespeichert sind, um auf der einen oder den mehreren Anzeigevorrichtungen 110 oder zur weiteren Verarbeitung durch einen des einen oder der mehreren Prozessor(en) 102 oder Parallelprozessor(en) 112 angezeigt werden sollen. Die Rasteroperationseinheit 526 kann dazu konfiguriert sein, z- oder Farbdaten, die in den Speicher geschrieben werden, zu komprimieren und z- oder Farbdaten, die aus dem Speicher gelesen werden, zu dekomprimieren.
  • Überblick über Maschinenlernen
  • Die oben beschriebene Architektur kann angewendet werden, um Trainings- und Inferenzierungsoperationen unter Verwendung von Maschinenlernmodellen durchzuführen. Maschinenlernen hat sich bei der Lösung vieler Arten von Aufgaben bewährt. Die Berechnungen, die beim Trainieren und Verwenden von Maschinenlernalgorithmen (z. B. neuronalen Netzwerken) entstehen, eignen sich natürlich für effiziente parallele Implementierungen. Dementsprechend haben Parallelprozessoren wie Grafikprozessoren für allgemeine Zwecke (GPGPUs) eine bedeutende Rolle bei der praktischen Implementierung von tiefen neuronalen Netzen gespielt. Parallelgrafikprozessoren mit SIMT-Architekturen (SIMT: Single Instruction, Multiple Thread) sind dafür ausgelegt, das Ausmaß der Parallelverarbeitung in der Grafik-Pipeline zu maximieren. In einer SIMT-Architektur versuchen Gruppen von parallelen Threads, Programmanweisungen so oft wie möglich synchron gemeinsam auszuführen, um die Verarbeitungseffizienz zu erhöhen. Die Effizienz, die durch parallele Maschinenlernalgorithmus-Implementierungen bereitgestellt wird, ermöglicht die Verwendung von Netzwerken mit hoher Kapazität und ermöglicht diesen Netzwerken, an größeren Datensätzen trainiert zu werden.
  • Ein Maschinenlernalgorithmus ist ein Algorithmus, der basierend auf einem Datensatz lernen kann. Beispielsweise können Maschinenlernalgorithmen dafür ausgelegt sein, hochgradige Abstraktionen innerhalb eines Datensatzes zu modellieren. Zum Beispiel können Bilderkennungsalgorithmen verwendet werden, um zu bestimmen, welche von mehreren Kategorien zu welcher gegebenen Eingabe gehören; Regressionsalgorithmen können bei einer Eingabe einen numerischen Wert ausgeben werden; und Mustererkennungsalgorithmen können verwendet werden, um übersetzten Text zu erzeugen oder eine Text-zu-Sprache- und/oder Spracherkennung durchzuführen.
  • Ein beispielhafter Typ eines Maschinenlernalgorithmus ist ein neuronales Netzwerk. Es gibt viele Arten von neuronalen Netzwerken; ein einfacher Typ eines neuronalen Netzwerks ist ein vorwärtsgekoppeltes Netzwerk. Ein vorwärtsgekoppeltes Netzwerk kann als ein azyklischer Graph implementiert sein, in dem die Knoten in Schichten angeordnet sind. Typischerweise weist eine vorwärtsgekoppelte Netzwerktopologie eine Eingabeschicht und eine Ausgabeschicht auf, die durch mindestens eine verborgene Schicht getrennt sind. Die verborgene Schicht transformiert eine durch die Eingabeschicht empfangene Eingabe in eine Repräsentation, die zum Erzeugen einer Ausgabe in der Ausgabeschicht nützlich ist. Die Netzwerkknoten sind vollständig über Kanten mit den Knoten in angrenzenden Schichten verbunden, es gibt aber keine Kanten zwischen Knoten innerhalb jeder Schicht. Daten, die an den Knoten einer Eingabeschicht eines Vorwärtskopplungsnetzwerks empfangen werden, werden zu den Knoten der Ausgabeschicht über eine Aktivierungsfunktion, die die Zustände der Knoten jeder nachfolgenden Schicht in dem Netzwerk basierend auf Koeffizienten („Gewichtungen“) berechnet, die jeweils jeder der Kanten zugeordnet sind, die die Schichten verbinden, propagiert (d. h. „vorwärts gekoppelt“). Abhängig von dem durch den ausgeführten Algorithmus repräsentierten spezifischen Modell kann die Ausgabe von dem Neuronalnetzwerkalgorithmus verschiedene Formen annehmen.
  • Bevor ein Maschinenlernalgorithmus verwendet werden kann, um ein bestimmtes Problem zu modellieren, wird der Algorithmus unter Verwendung eines Trainingsdatensatzes trainiert. Das Trainieren eines neuronalen Netzwerks beinhaltet das Auswählen einer Netzwerktopologie, das Verwenden eines Satzes von Trainingsdaten, die ein durch das Netzwerk modelliertes Problem repräsentieren, und das Anpassen der Gewichtungen, bis das Netzwerkmodell für alle Instanzen des Trainingsdatensatzes mit einem minimalen Fehler arbeitet. Zum Beispiel wird während eines Trainingsprozesses mit überwachtem Lernen für ein neuronales Netzwerk die Ausgabe, die durch das Netzwerk als Reaktion auf die eine Instanz in einem Trainingsdatensatz repräsentierende Eingabe erzeugt wird, mit der als „korrekt“ gelabelten Ausgabe für diese Instanz verglichen, ein Fehlersignal, das die Differenz zwischen der Ausgabe und der gelabelten Ausgabe repräsentiert, wird berechnet, und die Gewichtungen, die den Verbindungen zugeordnet sind, werden angepasst, um diesen Fehler zu minimieren, während das Fehlersignal rückwärts durch die Schichten des Netzwerks propagiert wird. Das Netzwerk wird als „trainiert“ betrachtet, wenn die Fehler für jede der aus den Instanzen des Trainingsdatensatzes erzeugten Ausgaben minimiert sind.
  • Die Genauigkeit eines Maschinenlernalgorithmus kann durch die Qualität des zum Trainieren des Algorithmus verwendeten Datensatzes erheblich beeinflusst werden. Der Trainingsprozess kann rechenintensiv sein und kann einen erheblichen Zeitaufwand auf einem herkömmlichen Universalprozessor nutzen. Dementsprechend wird eine Parallelverarbeitungshardware verwendet, um viele Arten von Maschinenlernalgorithmen zu trainieren. Dies ist besonders zum Optimieren des Trainings neuronaler Netzwerke nützlich, da sich die Berechnungen, die beim Anpassen der Koeffizienten in neuronalen Netzwerken durchgeführt werden, auf natürliche Weise für parallele Implementierungen eignen. Insbesondere wurden viele Maschinenlernalgorithmen und Softwareanwendungen dahingehend angepasst, die Parallelverarbeitungshardware in Universal-Grafikverarbeitungsvorrichtungen zu verwenden.
  • 6 ist ein verallgemeinertes Diagramm eines Softwarestapels 600 für Maschinenlernen. Eine Maschinenlernanwendung 602 ist eine beliebige Logik, die dazu konfiguriert sein kann, ein neuronales Netzwerk unter Verwendung eines Trainingsdatensatzes zu trainieren oder ein trainiertes tiefes neuronales Netzwerk zu verwenden, um Maschinenintelligenz zu implementieren. Die Maschinenlernanwendung 602 kann eine Trainings- und Inferenzfunktionalität für ein neuronales Netzwerk und/oder spezialisierte Software beinhalten, die verwendet werden kann, um ein neuronales Netzwerk vor dem Einsatz zu trainieren. Die Maschinenlernanwendung 602 kann eine beliebige Art von Maschinenintelligenz implementieren, einschließlich , jedoch ohne Einschränkung, Bilderkennung, Kartierung und Lokalisierung, autonome Navigation, Sprachsynthese, medizinische Bildgebung oder Sprachübersetzung. Beispielhafte Maschinenlernanwendungen 602 beinhalten, jedoch ohne Einschränkung, sprachbasierte virtuelle Assistenten, Bild- oder Gesichtserkennungsalgorithmen, autonome Navigation und die Softwarewerkzeuge, die verwendet werden, um die durch die Maschinenlernanwendungen 602 verwendeten Maschinenlernmodelle zu trainieren.
  • Die Hardwarebeschleunigung für die Maschinenlernanwendung 602 kann über ein Maschinenlern-Framework 604 aktiviert werden. Das Maschinenlern-Framework 604 kann eine Bibliothek von Maschinenlernprimitiven bereitstellen. Maschinenlernprimitive sind Basisoperationen, die üblicherweise von Maschinenlernalgorithmen durchgeführt werden. Ohne das Maschinenlern-Framework 604würden Entwickler von Maschinenlernalgorithmen genutzt werden, um die dem Maschinenlernalgorithmus zugeordnete Hauptrechenlogik zu erzeugen und zu optimieren und dann die Rechenlogik erneut zu optimieren, wenn neue Parallelprozessoren entwickelt werden. Stattdessen kann die Maschinenlernanwendung dazu konfiguriert sein, die Berechnungen unter Verwendung der Primitive durchzuführen, die von dem Maschinenlern-Framework 604 bereitgestellt werden. Beispielhafte Primitive beinhalten Tensorfaltungen, Aktivierungsfunktionen und Pooling, die Rechenoperationen sind, die während des Trainierens eines neuronalen Faltungsnetzwerks (CNN) durchgeführt werden. Das Maschinenlern-Framework 604 kann auch Primitive bereitstellen, um grundlegende Unterprogramme für lineare Algebra, die von vielen Maschinenlernalgorithmen durchgeführt werden, wie Matrix- und Vektoroperationen, zu implementieren. Beispiele für ein Maschinenlern-Framework 604 beinhalten , jedoch ohne Einschränkung, TensorFlow, TensorRT, PyTorch, MXNet, Caffee und andere Maschinenlern-Frameworks hoher Ebene.
  • Das Maschinenlern-Framework 604 kann Eingabedaten verarbeiten, die von der Maschinenlernanwendung 602 empfangen werden, und die die geeignete Eingabe in ein Rechen-Framework 606 erzeugen. Das Rechen-Framework 606 kann die dem GPGPU-Treiber 608 bereitgestellten zugrundeliegenden Anweisungen abstrahieren, um zu ermöglichen, dass das Maschinenlern-Framework 604 eine Hardwarebeschleunigung über die GPGPU-Hardware 610 nutzt, ohne dass das Maschinenlern-Framework 604 genaue Kenntnisse über die Architektur der GPGPU-Hardware 610 haben muss. Außerdem kann das Rechen-Framework 606 eine Hardwarebeschleunigung für das Maschinenlern-Framework 604 über viele verschiedene Arten und Generationen der GPGPU-Hardware 610ermöglichen. Beispielhafte Rechen-Frameworks 606 beinhalten das CUDA-Rechen-Framework und zugehörige Maschinenlernbibliotheken, wie die CUDA Deep Neural Network (cuDNN)-Bibliothek. Der Softwarestapel 600 für Maschinenlernen kann auch Kommunikationsbibliotheken oder Frameworks beinhalten, um Multi-GPU- und Multiknotenberechnung zu ermöglichen.
  • GPGPU-Maschinenlernbeschleunigung
  • 7 veranschaulicht eine Universal-Grafikverarbeitungseinheit 700, die der Parallelprozessor 200 von 2A oder der bzw. die Parallelprozessor(en) 112 von 1 sein kann. Die Universalverarbeitungseinheit (GPGPU) 700 kann dazu konfiguriert sein, Unterstützung für eine Hardwarebeschleunigung von Primitiven bereitzustellen, die von einem Maschinenlern-Framework bereitgestellt werden, um die Verarbeitung der Art von Berechnungsarbeitslasten zu beschleunigen, die dem Trainieren von tiefen neuronalen Netzwerken zugeordnet ist. Darüber hinaus kann die GPGPU 700 direkt mit anderen Instanzen der GPGPU verknüpft sein, um einen Multi-GPU-Cluster zu erstellen, um die Trainingsgeschwindigkeit für besonders tiefe neuronale Netzwerke zu verbessern. Primitive werden auch unterstützt, um Inferenzoperationen für eingesetzte neuronale Netzwerke zu beschleunigen.
  • Die GPGPU 700 weist eine Hostschnittstelle 702 zum Ermöglichen einer Verbindung mit einem Hostprozessor auf. Die Hostschnittstelle 702 kann eine PCI-Express-Schnittstelle sein. Die Hostschnittstelle kann jedoch auch eine anbieterspezifische Kommunikationsschnittstelle oder eine anbieterspezifische Kommunikations-Fabric sein. Die GPGPU 700 empfängt Befehle von dem Hostprozessor und verwendet einen globalen Scheduler 704 zum Verteilen von Ausführungs-Threads, die diesen Befehlen zugeordnet sind, an einen Satz von Verarbeitungsclustern 706A-706H. Die Verarbeitungscluster 706A-706H nutzen einen Cache-Speicher 708 gemeinsam. Der Cache-Speicher 708 kann als Cache höherer Ebene für Cache-Speicher innerhalb der Verarbeitungscluster 706A-706Hdienen. Die veranschaulichten Verarbeitungscluster 706A-706H können den Verarbeitungsclustern 214A-214N wie in 2A entsprechen.
  • Die GPGPU 700 weist einen Speicher 714A-714B auf, der über einen Satz von Speichersteuerungen 712A-712B mit den Verarbeitungsclustern 706A-706H gekoppelt ist. Der Speicher 714A-714B kann verschiedene Arten von Speichervorrichtungen beinhalten, einschließlich eines dynamischen Direktzugriffsspeichers (DRAM) oder eines Grafik-Direktzugriffspeichers, wie eines synchronen Grafik-Direktzugriffspeichers (SGRAM), einschließlich eines Grafikspeichers mit doppelter Datenrate (GDDR). Der Speicher 714A-714B kann auch 3D-gestapelten Speicher beinhalten, einschließlich, jedoch ohne Einschränkung, Speicher mit hoher Bandbreite (HBM: High Bandwidth Memory).
  • Jeder der Verarbeitungscluster 706A-706H kann einen Satz von Grafikmultiprozessoren beinhalten, wie den Grafikmultiprozessor 234 von 2D, Grafikmultiprozessor 325 von 3A, Grafikmultiprozessor 350 von 3B oder kann eine Mehrkerngruppe 365A-365N wie in 3C beinhalten. Die Grafikmultiprozessoren des Rechenclusters beinhalten mehrere Arten von Ganzzahl- und Gleitkommalogikeinheiten, die Rechenoperationen mit einer Reihe von Präzisionen durchführen können, darunter auch solche, die sich für Maschinenlernberechnungen eignen. Zum Beispiel kann zumindest eine Teilmenge der Gleitkommaeinheiten in jedem der Verarbeitungscluster 706A-706H dazu konfiguriert sein, 16-Bit- oder 32-Bit-Gleitkommaoperationen durchzuführen, während eine andere Teilmenge der Gleitkommaeinheiten dazu konfiguriert sein kann, 64-Bit-Gleitkommaoperationen durchzuführen.
  • Mehrere Instanzen der GPGPU 700 können derart konfiguriert sein, dass sie als ein Rechencluster arbeiten. Der Kommunikationsmechanismus, der vom Rechencluster zur Synchronisation und zum Datenaustausch verwendet wird, variiert je nach Ausführungsform. Zum Beispiel kommunizieren die mehreren Instanzen der GPGPU 700 über die Hostschnittstelle 702. In einer Ausführungsform beinhaltet die GPGPU 700 einen E/A-Hub 709, der die GPGPU 700 mit einem GPU-Link 710 koppelt, der eine direkte Verbindung mit anderen Instanzen der GPGPU ermöglicht. Der GPU-Link 710 kann mit einer dedizierten GPU-zu-GPU-Brücke gekoppelt sein, die eine Kommunikation und Synchronisation zwischen mehreren Instanzen der GPGPU 700 ermöglicht. Optional ist der GPU-Link 710 mit einem Hochgeschwindigkeits-Interconnect gekoppelt, um Daten an andere GPGPUs oder Parallelprozessoren zu übertragen und von diesen zu empfangen. Die mehreren Instanzen der GPGPU 700 können sich in separaten Datenverarbeitungssystemen befinden und über eine Netzwerkvorrichtung kommunizieren, auf die über die Hostschnittstelle 702 zugegriffen werden kann. Der GPU-Link 710 kann dazu konfiguriert sein, eine Verbindung zu einem Hostprozessor zusätzlich oder als Alternative zur Hostschnittstelle 702 zu ermöglichen.
  • Obgleich die veranschaulichte Konfiguration der GPGPU 700 zum Trainieren von neuronalen Netzen konfiguriert sein kann, kann eine alternative Konfiguration der GPGPU 700 zum Einsatz in einer Inferenzplattform mit hoher Leistungsfähigkeit oder einer Niederleistungsinferenzplattform konfiguriert sein. In einer Inferenzierungskonfiguration beinhaltet die GPGPU 700 im Vergleich zu der Trainingskonfiguration weniger Verarbeitungscluster 706A-706H. Zusätzlich dazu kann sich die Speichertechnologie, die dem Speicher 714A-714B zugeordnet ist, zwischen Inferenz- und Trainingskonfigurationen unterscheiden. In einer Ausführungsform kann die Inferenzierungskonfiguration der GPGPU 700 inferenzierungsspezifische Anweisungen unterstützen. Zum Beispiel kann eine Inferenzkonfiguration Unterstützung für eine oder mehrere 8-Bit-Ganzzahl-Skalarproduktanweisungen bereitstellen, die üblicherweise während Inferenzoperationen für implementierte neuronale Netzwerke verwendet werden.
  • 8 veranschaulicht ein Multi-GPU-Rechensystem 800. Das Multi-GPU-Rechensystem 800 kann einen Prozessor 802 beinhalten, der über einen Hostschnittstellen-Switch 804 mit mehreren GPGPUs 806A-806D gekoppelt ist. Der Hostschnittstellen-Switch 804 kann eine PCI-Express-Switch-Vorrichtung sein, die den Prozessor 802 mit einem PCI-Express-Bus koppelt, über den der Prozessor 802 mit dem Satz von GPGPUs 806A-806D kommunizieren kann. Jede der mehreren GPGPUs 806A-806D kann eine Instanz der GPGPU 700 von 7 sein. Die GPGPUs 806A-806D können über einen Satz von Hochgeschwindigkeits-Punkt-zu-Punkt-GPU mit GPU-Links 816 miteinander verbunden sein. Die Hochgeschwindigkeits-GPU-zu-GPU-Verbindungen können mit jeder der GPGPUs 806A-806D über eine dedizierte GPU-Verbindung wie die GPU-Verbindung 710 wie in 7 verbunden sein. Die P2P-GPU-Links 816 ermöglichen eine direkte Kommunikation zwischen jeder der GPGPUs 806A-806D , ohne dass eine Kommunikation über den Hostschnittstellenbus erforderlich ist, mit dem der Prozessor 802 verbunden ist. Mit GPU-zu-GPU-Verkehr, der zu den P2P GPU-Links geleitet wird, bleibt der Hostschnittstellenbus für den Systemspeicherzugriff verfügbar oder kommuniziert mit anderen Instanzen des Multi-GPU-Rechensystems 800, beispielsweise über eine oder mehrere Netzwerkvorrichtungen. Während in 8 die GPGPUs 806A-806D über den Hostschnittstellen-Switch 804 mit dem Prozessor 802verbunden sind, kann der Prozessor 802 alternativ dazu eine direkte Unterstützung für die P2P-GPU-Links 816 beinhalten und direkt mit den GPGPUs 806A-806D verbunden sein. In einer Ausführungsform ermöglicht der P2P-GPU-Link 816 dem Multi-GPU-Rechensystem 800 , als eine einzige logische GPU zu arbeiten.
  • Implementierungen Neuronaler Netzwerke Für Maschinenlernen
  • Die hierin beschriebene Rechenarchitektur kann dazu konfiguriert sein, die Arten der parallelen Verarbeitung durchzuführen, die insbesondere zum Trainieren und Einsetzen von neuronalen Netzwerken für maschinelles Lernen geeignet sind. Ein neuronales Netzwerk kann als ein Netzwerk von Funktionen, die in einer Graphenbeziehung stehen, verallgemeinert werden. Wie im Stand der Technik bekannt, gibt es viele verschiedene Arten von Implementierungen neuronaler Netzwerke, die beim Maschinenlernen verwendet werden. Ein beispielhafter Typ eines neuronalen Netzwerks ist das vorwärtsgekoppelte Netzwerk, wie zuvor beschrieben.
  • Ein zweiter beispielhafter Typ eines neuronalen Netzwerks ist das neuronale Faltungsnetzwerk (CNN). Ein CNN ist ein spezialisiertes neuronales vorwärtsgekoppeltes Netzwerk zum Verarbeiten von Daten mit einer bekannten gitterartigen Topologie, wie Bilddaten. Dementsprechend werden CNNs üblicherweise für Computer-Vision- und Bilderkennungsanwendungen verwendet, können aber auch für andere Arten von Mustererkennung, wie Sprache und Sprachverarbeitung, verwendet werden. Die Knoten in der CNN-Eingabeschicht sind in einem Satz von „Filtern“ organisiert (Merkmalsdetektoren, die von den rezeptiven Feldern in der Netzhaut inspiriert sind), und die Ausgabe jedes Filtersatzes wird an Knoten in aufeinanderfolgenden Schichten des Netzwerks propagiert. Die Berechnungen für ein CNN beinhalten das Anwenden der mathematischen Faltungsoperation auf jedes Filter, um die Ausgabe dieses Filters zu erzeugen. Faltung ist eine spezielle Art von mathematischer Operation, die von zwei Funktionen ausgeführt wird, um eine dritte Funktion zu erzeugen, die eine modifizierte Version einer der beiden ursprünglichen Funktionen ist. In der Terminologie eines Faltungsnetzwerks kann die erste Funktion der Faltung als Eingabe bezeichnet werden, während die zweite Funktion als Faltungskern bezeichnet werden kann. Die Ausgabe kann als Merkmalsabbildung bezeichnet werden. Zum Beispiel kann die Eingabe in eine Faltungsschicht ein mehrdimensionales Array von Daten sein, das die verschiedenen Farbkomponenten eines Eingabebildes definiert. Der Faltungskern kann ein mehrdimensionales Array von Parametern sein, wobei die Parameter durch den Trainingsprozess für das neuronale Netzwerk angepasst werden.
  • Rekurrente neuronale Netze (RNNs) sind eine Familie von vorwärtsgekoppelten neuronalen Netzen, die Rückkopplungsverbindungen zwischen Schichten enthalten. RNNs ermöglichen eine Modellierung sequenzieller Daten durch den Austausch von Parameterdaten über verschiedene Teile des neuronalen Netzwerks hinweg. Die Architektur für ein RNN beinhaltet Zyklen. Die Zyklen stellen den Einfluss eines gegenwärtigen Werts einer Variablen auf ihren eigenen Wert zu einem zukünftigen Zeitpunkt dar, da zumindest ein Teil der Ausgangsdaten von dem RNN als eine Rückkopplung zum Verarbeiten einer nachfolgenden Eingabe in einer Sequenz verwendet wird. Diese Eigenschaft macht RNNs aufgrund der variablen Natur, in der Sprachdaten zusammengesetzt sein können, besonders nützlich für die Sprachverarbeitung.
  • Die unten beschriebenen Figuren zeigen beispielhafte vorwärtsgekoppelte, CNN- und RNN-Netzwerke und beschreiben einen allgemeinen Prozess zum jeweiligen Trainieren und Einsetzen j eder dieser Arten von Netzwerken. Es versteht sich, dass diese Beschreibungen beispielhaft und nicht einschränkend für eine beliebige spezifische hierin beschriebene Ausführungsform sind und die veranschaulichten Konzepte allgemein auf tiefe neuronale Netzwerke und Maschinenlerntechniken im Allgemeinen angewendet werden können.
  • Die oben beschriebenen beispielhaften neuronalen Netzwerke können verwendet werden, um Deep Learning durchzuführen. Tiefes Lernen ist maschinelles Lernen unter Verwendung von tiefen neuronalen Netzen. Die tiefen neuronalen Netzwerke, die beim Deep Learning verwendet werden, sind künstliche neuronale Netzwerke, die aus mehreren verborgenen Schichten bestehen, im Gegensatz zu flachen neuronalen Netzwerken, die nur eine einzige verborgene Schicht aufweisen. Tiefere neuronale Netzwerke sind im Allgemeinen rechenintensiver zu trainieren. Die zusätzlichen verborgenen Schichten des Netzwerks ermöglichen jedoch eine mehrstufige Mustererkennung, die verglichen mit flachen Maschinenlerntechniken zu verringerten Ausgabefehlern führt.
  • Tiefe neuronale Netzwerke, die beim Deep Learning verwendet werden, beinhalten in der Regel ein Frontend-Netzwerk zur Durchführung einer Merkmalserkennung, das mit einem Backend-Netzwerk gekoppelt ist, das ein mathematisches Modell repräsentiert, das Operationen (z. B. Objektklassifizierung, Spracherkennung usw.) basierend auf der dem Modell bereitgestellten Merkmalsrepräsentation durchführen kann. Deep Learning ermöglicht ein Durchführen von maschinellem Lernen, ohne dass für das Modell eine manuelle Merkmalskonstruktion durchgeführt werden muss. Stattdessen können tiefe neuronale Netzwerke Merkmale basierend auf statistischer Struktur oder Korrelation innerhalb der Eingabedaten lernen. Die erlernten Merkmale können einem mathematischen Modell bereitgestellt werden, das detektierte Merkmale auf eine Ausgabe abbilden kann. Das mathematische Modell, das durch das Netzwerk verwendet wird, ist allgemein für die spezifische durchzuführende Aufgabe spezialisiert, und unterschiedliche Modelle können verwendet werden, um unterschiedliche Aufgaben durchzuführen.
  • Sobald das neuronale Netzwerk strukturiert ist, kann ein Lernmodell auf das Netzwerk angewendet werden, um das Netzwerk dahingehend zu trainieren, spezifische Aufgaben durchzuführen. Das Lernmodell beschreibt, wie die Gewichtungen innerhalb des Modells anzupassen sind, um den Ausgabefehler des Netzwerks zu reduzieren. Die Fehlerrückpropagation ist ein übliches Verfahren zum Trainieren neuronaler Netzwerke. Ein Eingabevektor wird dem Netzwerk zur Verarbeitung bereitgestellt. Die Ausgabe des Netzwerks wird unter Verwendung einer Verlustfunktion mit der gewünschten Ausgabe verglichen, und für jedes der Neuronen in der Ausgabeschicht wird ein Fehlerwert berechnet. Die Fehlerwerte werden dann rückwärts propagiert, bis jedem Neuron ein Fehlerwert zugeordnet ist, der seinen Beitrag zur ursprünglichen Ausgabe grob repräsentiert. Das Netzwerk kann dann von diesen Fehlern unter Verwenden eines Algorithmus, wie des stochastischen Gradientenabstiegsalgorithmus, lernen, um die Gewichtungen des neuronalen Netzwerks zu aktualisieren.
  • 9A-9B veranschaulichen ein beispielhaftes neuronales Faltungsnetzwerk. 9A veranschaulicht verschiedene Schichten innerhalb eines CNN. Wie in 9A gezeigt, kann ein beispielhaftes CNN, das zum Modellieren einer Bildverarbeitung verwendet wird, eine Eingabe 902 empfangen, die die Rot-, Grün- und Blau(RGB)-Komponenten eines Eingabebildes beschreibt. Die Eingabe 902 kann durch mehrere Faltungsschichten (z. B. Faltungsschicht 904, Faltungsschicht 906) verarbeitet werden. Die Ausgabe von den mehreren Faltungsschichten kann optional durch einen Satz vollständig verbundener Schichten 908verarbeitet werden. Neuronen in einer vollständig verbundenen Schicht weisen vollständige Verbindungen mit allen Aktivierungen in der vorherigen Schicht auf, wie zuvor für ein vorwärtsgekoppeltes Netzwerk beschrieben wurde. Die Ausgabe von den vollständig verbundenen Schichten 908 kann dazu verwendet werden, ein Ausgabeergebnis von dem Netzwerk zu erzeugen. Die Aktivierungen innerhalb der vollständig verbundenen Schichten 908 können unter Verwendung einer Matrixmultiplikation anstelle einer Faltung berechnet werden. Nicht alle CNN-Implementierungen verwenden vollständig verbundene Schichten 908. In einigen Implementierungen kann die Faltungsschicht 906 zum Beispiel eine Ausgabe für das CNN erzeugen.
  • Die Faltungsschichten sind dünn besetzt verbunden, was sich von der herkömmlichen Konfiguration von neuronalen Netzwerken unterscheidet, die in den vollständig verbundenen Schichten 908 zu finden ist. Herkömmliche Schichten von neuronalen Netzwerken sind vollständig verbunden, sodass jede Ausgabeeinheit mit jeder Eingabeeinheit interagiert. Die Faltungsschichten sind jedoch dünn besetzt verbunden, da die Ausgabe der Faltung eines Feldes (anstelle des jeweiligen Zustandswertes jedes der Knoten in dem Feld) in die Knoten der nachfolgenden Schicht eingegeben wird, wie veranschaulicht. Die den Faltungsschichten zugeordneten Kerne führen Faltungsoperationen durch, deren Ausgabe an die nächste Schicht gesendet wird. Die Dimensionalitätsreduzierung, die in den Faltungsschichten durchgeführt wird, ist ein Aspekt, der dem CNN ermöglicht, skaliert zu werden, um große Bilder zu verarbeiten.
  • 9B veranschaulicht beispielhafte Berechnungsstufen innerhalb einer Faltungsschicht eines CNN. Eine Eingabe in eine Faltungsschicht 912 eines CNN kann in drei Stufen einer Faltungsschicht 914 verarbeitet werden. Zu den drei Stufen können eine Faltungsstufe 916, eine Detektorstufe 918 und eine Pooling-Stufe 920gehören. Die Faltungsschicht 914 kann dann Daten an eine nachfolgende Faltungsschicht ausgeben. Die letzte Faltungsschicht des Netzwerks kann Ausgabemerkmalsabbildungsdaten erzeugen oder eine Eingabe in eine vollständig verbundene Schicht bereitstellen, um beispielsweise einen Klassifizierungswert für die Eingabe in das CNN zu erzeugen.
  • In der Faltungsstufe 916 werden mehrere Faltungen parallel durchgeführt, um einen Satz linearer Aktivierungen zu erzeugen. Die Faltungsstufe 916 kann eine affine Transformation aufweisen, bei der es sich um eine beliebige Transformation handelt, die als lineare Transformation plus eine Translation angegeben werden kann. Affine Transformationen schließen Rotationen, Translationen, Skalierungen und Kombinationen dieser Transformationen ein. Die Faltungsstufe berechnet die Ausgabe von Funktionen (z. B. Neuronen), die mit bestimmten Regionen in der Eingabe verbunden sind, die als die lokale Region bestimmt werden kann, die dem Neuron zugeordnet ist. Die Neuronen berechnen ein Skalarprodukt zwischen den Gewichtungen der Neuronen und der Region in der lokalen Eingabe, mit der die Neuronen verbunden sind. Die Ausgabe aus der Faltungsstufe 916 definiert einen Satz linearer Aktivierungen, die durch aufeinanderfolgende Stufen der Faltungsschicht 914 verarbeitet werden.
  • Die linearen Aktivierungen können durch eine Detektorstufe 918verarbeitet werden. In der Detektorstufe 918wird jede lineare Aktivierung durch eine nichtlineare Aktivierungsfunktion verarbeitet. Die nichtlineare Aktivierungsfunktion erhöht die nichtlinearen Eigenschaften des Gesamtnetzwerks, ohne die rezeptiven Felder der Faltungsschicht zu beeinflussen. Es können verschiedene Arten von nichtlinearen Aktivierungsfunktionen verwendet werden. Eine spezielle Art ist die gleichgerichtete lineare Einheit (ReLU: Rectified Linear Unit), die eine Aktivierungsfunktion verwendet, die als f(x) = max (0, x) definiert ist, sodass die Aktivierung bei Null als Schwellenwert verwendet wird.
  • Die Pooling-Stufe 920 verwendet eine Pooling-Funktion, die die Ausgabe der Faltungsschicht 906 durch eine Zusammenfassungsstatistik der nahegelegenen Ausgaben ersetzt. Die Pooling-Funktion kann verwendet werden, um eine Translationsinvarianz in das neuronale Netzwerk einzuführen, sodass kleine Translationen der Eingabe die gepoolten Ausgaben nicht ändern. Invarianz gegenüber lokaler Translation kann in Szenarien nützlich sein, in denen das Vorhandensein eines Merkmals in den Eingabedaten wichtiger als die genaue Position des Merkmals ist. Während der Pooling-Stufe 920können verschiedene Arten von Pooling-Funktionen verwendet werden, darunter Max-Pooling, Average-Pooling und L2-Norm-Pooling. Darüber hinaus weisen einige CNN-Implementierungen keine Pooling-Stufe auf. Stattdessen ersetzen solche Implementierungen eine zusätzliche Faltungsstufe, die im Vergleich zu früheren Faltungsstufen einen erhöhten Fortschritt aufweist.
  • Die Ausgabe aus der Faltungsschicht 914 kann dann von der nächsten Schicht 922 verarbeitet werden. Die nächste Schicht 922 kann eine zusätzliche Faltungsschicht oder eine der vollständig verbundenen Schichten 908 sein. Zum Beispiel kann die erste Faltungsschicht 904 von 9A an die zweite Faltungsschicht 906 ausgeben, während die zweite Faltungsschicht an eine erste Schicht der vollständig verbundenen Schichten 908 ausgeben kann.
  • 10 veranschaulicht ein beispielhaftes rekurrentes neuronales Netzwerk 1000. In einem rekurrenten neuronalen Netzwerk (RNN) beeinflusst der vorherige Zustand des Netzwerks die Ausgabe des aktuellen Zustands des Netzwerks. RNNs können auf vielfältige Weise unter Verwendung einer mehreren Funktionen konstruiert werden. Bei der Verwendung von RNNs geht es im Allgemeinen darum, mathematische Modelle zu verwenden, um die Zukunft basierend auf einer vorherigen Sequenz von Eingaben vorherzusagen. Ein RNN kann beispielsweise zum Durchführen einer statistischen Sprachmodellierung verwendet werden, um ein aufkommendes Wort anhand einer vorherigen Wortfolge vorherzusagen. Das veranschaulichte RNN 1000 kann so beschrieben werden, dass es eine Eingabeschicht 1002, die einen Eingabevektor empfängt, verborgene Schichten 1004 zum Implementieren einer rekurrenten Funktion, einen Rückkopplungsmechanismus 1005 zum Ermöglichen eines ‚Speichers‘ von vorherigen Zuständen und eine Ausgabeschicht 1006 zum Ausgeben eines Ergebnisses aufweist. Das RNN 1000 arbeitet auf Grundlage von Zeitschritten. Der Zustand des RNN zu einem gegebenen Zeitschritt wird basierend auf dem vorherigen Zeitschritt über den Rückkopplungsmechanismus 1005 beeinflusst. Für einen gegebenen Zeitschritt wird der Zustand der verborgenen Schichten 1004 durch den vorherigen Zustand und die Eingabe bei dem aktuellen Zeitschritt definiert. Eine anfängliche Eingabe (x1) in einem ersten Zeitschritt kann durch die verborgene Schicht 1004 verarbeitet werden. Eine zweite Eingabe (x2) kann durch die verborgene Schicht 1004 unter Verwendung von Zustandsinformationen verarbeitet werden, die während der Verarbeitung der anfänglichen Eingabe (x1) bestimmt werden. Ein gegebener Zustand kann als st = f (Uxt + Wst-1) berechnet werden, wobei U und W Paramtermatrizen sind. Die Funktion f ist im Allgemeinen eine Nichtlinearität, wie die hyperbolische Tangensfunktion (Tanh) oder eine Variante der Gleichrichterfunktion f (x) = max(0, x). Die spezifische mathematische Funktion, die in den verborgenen Schichten 1004 verwendet wird, kann jedoch in Abhängigkeit von den spezifischen Implementierungsdetails des RNN 1000 variieren.
  • Zusätzlich zu den beschriebenen grundlegenden CNN- und RNN-Netzwerken kann eine Beschleunigung für Variationen dieser Netzwerke ermöglicht werden. Eine beispielhafte RNN-Variante ist das Long-Short-Term-Memory (LSTM) -RNN. LSTM-RNNs sind in der Lage, Langzeitabhängigkeiten zu lernen, die zur Verarbeitung längerer Sprachsequenzen genutzt werden können. Eine Variante des CNN ist ein Deep-Belief-Faltungsnetzwerk, das eine ähnliche Struktur wie ein CNN aufweist und ähnlich wie ein Deep-Belief-Netzwerk trainiert wird. Ein Deep-Belief-Netzwerk (DBN) ist ein generatives neuronales Netzwerk, das aus mehreren Schichten stochastischer (zufälliger) Variablen besteht. DBNs können Schicht für Schicht mittels unüberwachtem Lernen mit Greedy-Ansatz trainiert werden. Die gelernten Gewichtungen des DBN können dann verwendet werden, um neuronale Vortrainingsnetzwerke bereitzustellen, indem ein anfänglicher Satz von Gewichtungen für das neuronale Netzwerk bestimmt wird. In weiteren Ausführungsformen wird eine Beschleunigung zum bestärkenden Lernen ermöglicht. Beim bestärkenden Lernen lernt ein künstlicher Agent, indem er mit seiner Umgebung interagiert. Der Agent ist dazu konfiguriert, gewisse Ziele zu optimieren, um kumulative Belohnungen zu maximieren.
  • 11 veranschaulicht Training und Einsatz eines tiefen neuronalen Netzwerks. Sobald ein gegebenes Netzwerk für eine Aufgabe strukturiert wurde, wird das neuronale Netzwerk unter Verwendung eines Trainingsdatensatzes 1102trainiert. Verschiedene Trainings-Frameworks 1104 wurden entwickelt, um eine Hardwarebeschleunigung des Trainingsprozesses zu ermöglichen. Zum Beispiel kann das Maschinenlern-Framework 604 aus 6 als Trainings-Framework 1104 konfiguriert sein. Das Trainings-Framework 1104 kann sich in ein untrainiertes neuronales Netzwerk 1106 einklinken und ermöglichen, dass das untrainierte neuronale Netzwerk unter Verwendung der hierin beschriebenen Parallelverarbeitungsressourcen trainiert wird, um ein trainiertes neuronales Netzwerk 1108 zu erzeugen.
  • Um den Trainingsprozess zu beginnen, können die Anfangsgewichtungen zufällig oder durch Vortraining unter Verwendung eines Deep-Belief-Netzwerks gewählt werden. Der Trainingszyklus kann dann entweder auf überwachte oder auf unüberwachte Weise durchgeführt werden.
  • Überwachtes Lernen ist ein Lernverfahren, bei dem das Training als vermittelte Operation durchgeführt wird, z. B., wenn der Trainingsdatensatz 1102 Eingaben enthält, die mit der gewünschten Ausgabe für die Eingabe gepaart sind, oder wenn der Trainingsdatensatz Eingaben mit bekannter Ausgabe enthält und die Ausgabe des neuronalen Netzwerks manuell bewertet wird. Das Netzwerk verarbeitet die Eingaben und vergleicht die resultierenden Ausgaben mit einem Satz von erwarteten oder gewünschten Ausgaben. Fehler werden dann zurück durch das System propagiert. Das Trainings-Framework 1104 kann die Gewichtungen anpassen, die das untrainierte neuronale Netzwerk 1106 steuern. Das Trainings-Framework 1104 kann Werkzeuge bereitstellen, um zu überwachen, wie gut das untrainierte neuronale Netzwerk 1106 zu einem Modell konvergiert, das zum Erzeugen korrekter Antworten auf der Grundlage bekannter Eingabedaten geeignet ist. Der Trainingsprozess findet wiederholt statt, während die Gewichtungen des Netzwerks angepasst werden, um die durch das neuronale Netzwerk erzeugte Ausgabe zu verfeinern. Der Trainingsprozess kann fortgesetzt werden, bis das neuronale Netzwerk eine einem trainierten neuronalen Netzwerk 1108 zugeordnete statistisch gewünschte Genauigkeit erreicht. Das trainierte neuronale Netzwerk 1108 kann dann eingesetzt werden, um eine beliebige Anzahl von Maschinenlernoperationen zu implementieren, um ein Inferenzergebnis 1114 basierend auf einer Eingabe neuer Daten 1112 zu erzeugen.
  • Unüberwachtes Lernen ist ein Lernverfahren, bei dem das Netzwerk versucht, sich mit unmarkierten Daten zu trainieren. Somit kann der Trainingsdatensatz 1102 für unüberwachtes Lernen Eingabedaten ohne zugehörige Ausgabedaten enthalten. Das untrainierte neuronale Netzwerk 1106 kann Gruppierungen innerhalb der unmarkierten Eingabe lernen und kann bestimmen, wie einzelne Eingaben mit dem Gesamtdatensatz in Beziehung stehen. Unüberwachtes Training kann verwendet werden, um eine selbstorganisierende Abbildung zu erzeugen, die eine Art trainiertes neuronales Netzwerk 1108 ist, das in der Lage ist, Operationen durchzuführen, die nützlich sind, um die Dimensionalität von Daten zu reduzieren. Unüberwachtes Training kann auch verwendet werden, um eine Anomalieerkennung auszuführen, die die Identifizierung von Datenpunkten in einem Eingabedatensatz ermöglicht, die von den normalen Mustern der Daten abweichen.
  • Es können auch Variationen von überwachtem und unüberwachtem Training eingesetzt werden. Semi-überwachtes Lernen ist eine Technik, bei der der Trainingsdatensatz 1102 eine Mischung aus markierten und unmarkierten Daten mit gleicher Verteilung beinhaltet. Inkrementelles Lernen ist eine Variante des überwachten Lernens, bei der Eingabedaten kontinuierlich verwendet werden, um das Modell weiter zu trainieren. Inkrementelles Lernen ermöglicht, dass sich das trainierte neuronale Netzwerk 1108 an die neuen Daten 1112 anpasst, ohne das Wissen zu vergessen, das dem Netzwerk bei einem anfänglichen Training vermittelt wurde.
  • Unabhängig davon, ob er überwacht oder unüberwacht ist, kann der Trainingsprozess für besonders tiefe neuronale Netzwerke für einen einzelnen Rechenknoten zu rechenintensiv sein. Anstatt einen einzelnen Rechenknoten zu verwenden, kann ein verteiltes Netzwerk von Rechenknoten verwendet werden, um den Trainingsprozess zu beschleunigen.
  • 12A ist ein Blockdiagramm, das verteiltes Lernen veranschaulicht. Verteiltes Lernen ist ein Trainingsmodell, das mehrere verteilte Rechenknoten verwendet, um überwachtes oder unüberwachtes Training eines neuronalen Netzwerks durchzuführen. Die verteilten Rechenknoten können jeweils einen oder mehrere Hostprozessoren und einen oder mehrere der Universalverarbeitungsknoten beinhalten, wie die hochparallele Universalgrafikverarbeitungseinheit 700 wie in 7. Wie veranschaulicht, kann verteiltes Lernen mit Modellparallelität 1202, Datenparallelität 1204oder einer Kombination von Modell- und Datenparallelität 1206 durchgeführt werden.
  • Bei der Modellparallelität 1202können verschiedene Rechenknoten in einem verteilten System Trainingsberechnungen für verschiedene Teile eines einzelnen Netzwerks durchführen. Zum Beispiel kann jede Schicht eines neuronalen Netzwerks durch einen anderen Verarbeitungsknoten des verteilten Systems trainiert werden. Zu den Vorteilen der Modellparallelität gehört die Möglichkeit, auf besonders große Modelle zu skalieren. Das Aufteilen der Berechnungen, die verschiedenen Schichten des neuronalen Netzwerks zugeordnet sind, ermöglicht das Trainieren sehr großer neuronaler Netzwerke, bei denen die Gewichtungen aller Schichten nicht in den Speicher eines einzelnen Rechenknotens passen würden. In einigen Fällen kann die Modellparallelität besonders nützlich sein, um ein unüberwachtes Training großer neuronaler Netzwerke durchzuführen.
  • Beider Datenparallelität 1204weisen die verschiedenen Knoten des verteilten Netzwerks eine vollständige Instanz des Modells auf, und jeder Knoten empfängt einen anderen Teil der Daten. Die Ergebnisse aus den verschiedenen Knoten werden dann kombiniert. Obgleich verschiedene Ansätze zur Datenparallelität möglich sind, nutzen alle datenparallele Trainingsansätze eine Technik zur Kombination von Ergebnissen und zur Synchronisierung der Modellparameter zwischen den einzelnen Knoten. Beispielhafte Ansätze zum Kombinieren von Daten schließen eine Parametermittelwertbildung und eine aktualisierungsbasierte Datenparallelität ein. Die Parametermittelwertbildung trainiert jeden Knoten in einer Teilmenge der Trainingsdaten und setzt die globalen Parameter (z. B. Gewichtungen, Bias) auf den Mittelwert der Parameter von jedem Knoten. Die Parametermittelwertbildung verwendet einen zentralen Parameterserver, der die Parameterdaten verwaltet. Die aktualisierungsbasierte Datenparallelität ist der Parametermittelwertbildung ähnlich, außer
    dass, statt Parameter von den Knoten an den Parameterserver zu übertragen, die Aktualisierungen an die Modelle übertragen werden,. Zusätzlich dazu kann die aktualisierungsbasierte Datenparallelität dezentral durchgeführt werden, wobei die Aktualisierungen komprimiert und zwischen Knoten übertragen werden.
  • Kombinierte Modell- und Datenparallelität 1206 kann zum Beispiel in einem verteilten System implementiert werden, in dem jeder Rechenknoten mehrere GPUs aufweist. Jeder Knoten kann eine vollständige Instanz des Modells aufweisen, wobei separate GPUs innerhalb jedes Knotens dazu verwendet werden, verschiedene Teile des Modells zu trainieren.
  • Verteiltes Training hat einen erhöhten Overhead im Vergleich zum Training auf einer einzelnen Maschine. Die hier beschriebenen Parallelprozessoren und GPGPUs können jedoch jeweils verschiedene Techniken implementieren, um den Overhead des verteilten Trainings zu reduzieren, einschließlich Techniken zum Ermöglichen einer GPU-zu-GPU-Datenübertragung mit hoher Bandbreite und einer beschleunigten Ferndatensynchronisation.
  • 12B ist ein Blockdiagramm, das eine programmierbare Netzwerkschnittstelle 1210 und eine Datenverarbeitungseinheit veranschaulicht. Die programmierbare Netzwerkschnittstelle 1210 ist eine programmierbare Netzwerk-Engine, die verwendet werden kann, um netzwerkbasierte Rechenaufgaben innerhalb einer verteilten Umgebung zu beschleunigen. Die programmierbare Netzwerkschnittstelle 1210 kann über die Hostschnittstelle 1270 mit einem Hostsystemgekoppelt sein. Die programmierbare Netzwerkschnittstelle 1210 kann verwendet werden, um Netzwerk- oder Speicheroperationen für CPUs oder GPUs des Hostsystems zu beschleunigen. Das Hostsystem kann zum Beispiel ein Knoten eines verteilten Lernsystems sein, das zum Durchführen von verteiltem Trainings verwendet wird, wie zum Beispiel in 12A gezeigt. Das Hostsystem kann auch ein Datenzentrumsknoten innerhalb eines Datenzentrums sein.
  • In einer Ausführungsform kann der Zugriff auf eine Fernspeicherung, die Modelldaten enthält, durch die programmierbare Netzwerkschnittstelle 1210 beschleunigt werden. Zum Beispiel kann die programmierbare Netzwerkschnittstelle 1210 dazu konfiguriert sein, entfernten Speichervorrichtungen als lokale Speichervorrichtungen für das Hostsystem zu präsentieren. Die programmierbare Netzwerkschnittstelle 1210 kann auch RDMA-Operationen (RDMA: Remote Direct Memory Access - Fernspeicherzugriff) beschleunigen, die zwischen GPUs des Hostsystems mit GPUs von Fernsystemen durchgeführt werden. In einer Ausführungsform kann die programmierbare Netzwerkschnittstelle 1210 eine Speicherungsfunktionalität wie, jedoch ohne Einschränkung, NVMF-oF ermöglichen. Die programmierbare Netzwerkschnittstelle 1210 kann auch Verschlüsselung, Datenintegrität, Komprimierung und andere Operationen zur Fernspeicherung für das Hostsystem beschleunigen, wodurch ermöglicht wird, dass sich die Fernspeicherung den Latenzen von Speicherungsvorrichtungen annähert, die direkt an das Hostsystem angeschlossen sind.
  • Die programmierbare Netzwerkschnittstelle 1210 kann auch Ressourcenzuweisung und -verwaltung im Auftrag des Hostsystems durchführen. Speicherungssicherheitsoperationen können an die programmierbaren Netzwerkschnittstelle 1210 abgegeben und in Übereinstimmung mit der Zuweisung und Verwaltung von Fernspeicherungsressourcen durchgeführt werden. Netzwerkbasierte Operationen zum Verwalten des Zugriffs auf die Fernspeicherung, die ansonsten durch einen Prozessor des Hostsystems durchgeführt würde, können stattdessen von der programmierbaren Netzwerkschnittstelle 1210durchgeführt werden.
  • In einer Ausführungsform können Netzwerk- und/oder Datensicherheitsoperationen von dem Hostsystem an die programmierbare Netzwerkschnittstelle 1210 ausgelagert werden. Datenzentrumssicherheitsrichtlinien für einen Datenzentrumsknoten können durch die programmierbare Netzwerkschnittstelle 1210 anstelle der Prozessoren des Hostsystems gehandhabt werden. Zum Beispiel kann die programmierbare Netzwerkschnittstelle 1210 einen versuchten netzwerkbasierten Angriff (z. B. DDoS) auf das Hostsystem detektieren und diesen eindämmen, wodurch verhindert wird, dass der Angriff die Verfügbarkeit des Hostsystems beeinträchtigt.
  • Die programmierbare Netzwerkschnittstelle 1210 kann ein System-on-Chip (SoC 1220) beinhalten, das ein Betriebssystem über mehrere Prozessorkerne 1222 ausführt. Die Prozessorkerne 1222 können Universalprozessorkerne (z. B. CPU-Kerne) beinhalten. In einer Ausführungsform können die Prozessorkerne 1222 auch einen oder mehrere GPU-Kerne beinhalten. Das SoC 1220 kann in einer Speichereinrichtung 1240 gespeicherte Anweisungen ausführen. Eine Speicherungsvorrichtung 1250 kann lokale Betriebssystemdaten speichern. Die Speicherungsvorrichtung 1250 und die Speichervorrichtung 1240 können auch verwendet werden, um Ferndaten für das Hostsystem zwischenzuspeichern. Die Netzwerkports 1260A-1260B ermöglichen eine Verbindung zu einem Netzwerk oder einer Fabric und ermöglichen einen Netzwerkzugriff für das SoC 1220 , und über die Hostschnittstelle 1270für das Hostsystem. Die programmierbare Netzwerkschnittstelle 1210 kann auch eine E/A-Schnittstelle 1275beinhalten, wie eine USB-Schnittstelle. Die E/A-Schnittstelle 1275 kann verwendet werden, um externe Vorrichtungen mit der programmierbaren Netzwerkschnittstelle 1210 oder als eine Debug-Schnittstelle zu koppeln. Die programmierbare Netzwerkschnittstelle 1210 beinhaltet außerdem eine Verwaltungsschnittstelle 1230 , die es Software auf der Hostvorrichtung ermöglicht, die programmierbare Netzwerkschnittstelle 1210 und/oder das SoC 1220 zu verwalten und zu konfigurieren. In einer Ausführungsform kann die programmierbare Netzwerkschnittstelle 1210 auch einen oder mehrere Beschleuniger oder GPUs 1245 beinhalten, um einen Offload paralleler Rechenaufgaben vom SoC 1220, ein Hostsystem oder Fernsystemen zu akzeptieren, die über die Netzwerkports 1260A-1260B gekoppelt sind.
  • Beispielhafte Maschinenlernanwendungen
  • Maschinenlernen kann zur Lösung verschiedener technologischer Probleme eingesetzt werden, einschließlich, jedoch ohne Einschränkung, Computer Vision, autonomes Fahren und Navigation, Erkennung gesprochener Sprache und Sprachverarbeitung. Computer Vision ist traditionell ein aktives Forschungsgebiet für Maschinenlernanwendungen. Anwendungen von Computer-Vision reichen von der Reproduktion menschlicher visueller Fähigkeiten, wie dem Erkennen von Gesichtern, bis hin zur Schaffung neuer Kategorien visueller Fähigkeiten. Zum Beispiel können Computer-Vision-Anwendungen dazu konfiguriert sein, Schallwellen aus den Vibrationen, die in den in einem Video sichtbaren Objekten induziert werden, zu erkennen. Parallelprozessorbeschleunigtes Maschinenlernen ermöglicht, Computer-Vision-Anwendungen unter Verwendung wesentlich größerer Trainingsdatensätze zu trainieren, als dies bisher möglich war, und ermöglicht, Inferenzsysteme unter Verwendung von Niederleistungs-Parallelprozessoren einzusetzen.
  • Parallelprozessorbeschleunigtes Maschinenlernen weist autonome Fahranwendungen auf, einschließlich Spur- und Verkehrszeichenerkennung, Hindernisvermeidung, Navigation und Fahrsteuerung. Beschleunigte Maschinenlerntechniken können verwendet werden, um Fahrmodelle basierend auf Datensätzen zu trainieren, die die geeigneten Antworten auf spezifische Trainingseingaben definieren. Die vorliegend beschriebenen Parallelprozessoren können ein schnelles Training der zunehmend komplexen neuronalen Netze ermöglichen, die für Lösungen zum autonomen Fahren verwendet werden, und ermöglichen den Einsatz von Niederleistungs-Inferenzprozessoren in einer mobilen Plattform, die zur Integration in autonome Fahrzeuge geeignet ist.
  • Parallelprozessorbeschleunigte tiefe neuronale Netzwerke haben Maschinenlernansätze zur automatischen Spracherkennung (ASR) ermöglicht. ASR beinhaltet die Erzeugung einer Funktion, die bei einer eingegebenen Akustiksequenz eine wahrscheinliche linguistische Sequenz berechnet. Beschleunigtes Maschinenlernen unter Verwendung tiefer neuronaler Netzwerke hat es ermöglicht, die bisher für ASR verwendeten Hidden-Markov-Modelle (HMMs) und Gaußschen Mischmodelle (GMMs) zu ersetzen.
  • Parallelprozessorbeschleunigtes Maschinenlernen kann auch zur Beschleunigung der Verarbeitung natürlicher Sprache verwendet werden. Automatische Lernverfahren können statistische Inferenzalgorithmen nutzen, um Modelle zu erzeugen, die robust gegenüber fehlerhaften oder ungewohnten Eingaben sind. Zu beispielhaften Anwendungen für natürliche Sprachprozessoren gehört die automatische Maschinenübersetzung zwischen menschlichen Sprachen.
  • Die zum Maschinenlernen verwendeten parallelen Verarbeitungsplattformen können in Trainingsplattformen und Einsatzplattformen unterteilt werden. Trainingsplattformen sind im Allgemeinen stark parallel und beinhalten Optimierungen zum Beschleunigen von Multi-GPU-Einzelknoten-Training und Multi-Knoten-Multi-GPU-Training. Zu beispielhaften Parallelprozessoren, die sich für das Training eignen, gehören die Universal-Grafikverarbeitungseinheit 700 von 7 und das Multi-GPU-Rechensystem 800 von 8. Eingesetzte Maschinenlernpattformen beinhalten dagegen im Allgemeinen Niederleistungsparallelprozessoren, die zur Verwendung in Produkten wie Kameras, autonomen Robotern und autonomen Fahrzeugen geeignet sind.
  • Außerdem können Maschinenlerntechniken angewendet werden, um Grafikverarbeitungsaktivitäten zu beschleunigen oder zu verbessern. Zum Beispiel kann ein Maschinenlernmodell dazu trainiert werden, eine Ausgabe zu erkennen, die durch eine GPU-beschleunigte Anwendung erzeugt wird, und eine hochskalierte Version dieser Ausgabe zu erzeugen. Solche Techniken können angewendet werden, um die Erzeugung hochauflösender Bilder für eine Gaming-Anwendung zu beschleunigen. Verschiedene andere Grafik-Pipeline-Aktivitäten können von der Verwendung von maschinellem Lernen profitieren. Zum Beispiel können Maschinenlernmodelle trainiert werden, Tessellationsoperationen an Geometriedaten durchzuführen, um die Komplexität geometrischer Modelle zu erhöhen, wodurch ermöglicht wird, dass eine detaillierte Geometrie automatisch aus einer Geometrie mit relativ niedrigerer Details erzeugt wird.
  • 13 veranschaulicht ein beispielhaftes Inferenzsystem auf einem Chip (SOC) 1300 , das zum Durchführen einer Inferenzierung unter Verwendung eines trainierten Modells geeignet ist. Das SOC 1300 kann Verarbeitungskomponenten integrieren, einschließlich eines Medienprozessors 1302, eines Bildverarbeitungsprozessors 1304, einer GPGPU 1306 und eines Mehrkernprozessors 1308. Die GPGPU 1306 kann eine hierin beschriebene GPGPU sein, wie die GPGPU 700, und der Mehrkernprozessor 1308 kann ein hier beschriebener Mehrkernprozessor sein, wie die Mehrkernprozessoren 405-406. Das SOC 1300 kann zusätzlich einen On-Chip-Speicher 1305 beinhalten, der einen gemeinsam genutzten On-Chip-Datenpool ermöglichen kann, auf den jede der Verarbeitungskomponenten zugreifen kann. Die Verarbeitungskomponenten können für einen Niedrigleistungsbetrieb optimiert werden, um den Einsatz auf eine mehreren Maschinenlernplattformen zu ermöglichen, einschließlich autonomer Fahrzeuge und autonomer Roboter. Eine Implementierung des SOC 1300 kann zum Beispiel als Teil des Hauptsteuersystems für ein autonomes Fahrzeug verwendet werden. Wenn das SOC 1300 zur Verwendung in autonomen Fahrzeugen konfiguriert ist, ist das SOC dahingehend ausgelegt und konfiguriert, die relevanten Standards funktionaler Sicherheit des Einsatzlandes zu erfüllen.
  • Während des Betriebs können der Medienprozessor 1302 und der Vision-Prozessor 1304 zusammenarbeiten, um Computer-Vision-Operationen zu beschleunigen. Der Medienprozessor 1302 kann eine latenzarme Decodierung mehrerer hochauflösender Videoströme (z. B. 4K, 8K) ermöglichen. Die decodierten Videoströme können in einen Puffer in dem On-Chip -Speicher 1305 geschrieben werden. Der Vision-Prozessor 1304 kann dann das decodierte Video parsen und vorläufige Verarbeitungsoperationen an den Frames des decodierten Videos als Vorbereitung der Verarbeitung der Frames unter Verwendung eines trainierten Bilderkennungsmodells durchführen. Beispielsweise kann der Bildverarbeitungsprozessor 1304 die Faltungsoperationen für ein CNN beschleunigen, das zur Durchführung von Bilderkennung an den hochauflösenden Videodaten verwendet wird, während die Backend-Modellberechnungen durch die GPGPU 1306durchgeführt werden.
  • Der Mehrkernprozessor 1308 kann eine Steuerlogik beinhalten, die bei der Sequenzierung und Synchronisierung von Datenübertragungen und gemeinsamen Speicheroperationen hilft, die durch den Medienprozessor 1302 und den Vision-Prozessor 1304 durchgeführt werden. Der Mehrkernprozessor 1308 kann zudem als Anwendungsprozessor fungieren, um Softwareanwendungen auszuführen, die die Inferenzrechenfähigkeit der GPGPU 1306nutzen können. Zum Beispiel kann zumindest ein Teil der Navigations- und Fahrlogik in Software implementiert sein, die auf dem Mehrkernprozessor 1308ausgeführt wird. Eine solche Software kann Rechenarbeitslasten direkt an die GPGPU 1306 ausgeben oder die Rechenarbeitslasten können an den Mehrkernprozessor 1308 ausgegeben werden, der zumindest einen Teil dieser Operationen an die GPGPU 1306 auslagern kann.
  • Die GPGPU 1306 kann Rechencluster beinhalten, wie eine Niederleistungskonfiguration der Verarbeitungscluster 706A-706H innerhalb der Universal-Grafikverarbeitungseinheit 700. Die Rechencluster innerhalb der GPGPU 1306 können Anweisungen unterstützen, die spezifisch zur Durchführung von Inferenzberechnungen in einem trainierten neuronalen Netzwerk optimiert sind. Zum Beispiel kann die GPGPU 1306 Anweisungen zum Durchführen von Berechnungen mit niedriger Genauigkeit unterstützen, wie 8-Bit- und 4-Bit-Ganzzahlvektoroperationen.
  • Zusätzliche Systemübersicht
  • 14 ist ein Blockdiagramm eines Verarbeitungssystems 1400. Die Elemente von 14 mit den gleichen oder ähnlichen Namen wie die Elemente einer beliebigen anderen Figur hierin beschreiben die gleichen Elemente wie in den anderen Figuren, können auf eine ähnliche Weise wie jene arbeiten oder funktionieren, können die gleichen Komponenten umfassen und können mit anderen Entitäten, wie jenen, die an anderer Stelle hierin beschrieben sind, verknüpft sein, sind aber nicht darauf beschränkt. Das System 1400 kann in einem Einzelprozessor-Desktop-System, einem Multiprozessor-Workstation-System oder einem Serversystem mit einer großen Anzahl von Prozessoren 1402 oder Prozessorkernen 1407 verwendet werden. Das System 1400 kann eine Verarbeitungsplattform sein, die innerhalb einer integrierten System-on-Chip(SoC)-Schaltung zur Verwendung in mobilen, handgehaltenen oder eingebetteten Vorrichtungen, wie innerhalb von Internet-of-Things-(IoT)-Vorrichtungen mit drahtgebundener oder drahtloser Konnektivität zu einem lokalen oder Weitverkehrsnetzwerk, integriert ist.
  • Das System 1400 kann ein Verarbeitungssystem mit Komponenten sein, die denen von 1 entsprechen. Beispielsweise können in unterschiedlichen Konfigurationen Prozessor(en) 1402 oder Prozessorkern(e) 1407 dem einen bzw. den mehreren Prozessoren 102 von 1 entsprechen. Der/die Grafikprozessor(en) 1408 kann/können dem/den Parallelprozessor(en) 112 von 1 entsprechen. Der externe Grafikprozessor 1418 kann eine der Add-in-Vorrichtungen 120 von 1 sein.
  • Das System 1400 kann eine serverbasierte Spielplattform; eine Spielkonsole, einschließlich einer Spiel- und Medienkonsole, einer mobilen Spielkonsole, einer handgehaltenen Spielkonsole oder einer Online-Spielkonsole, beinhalten, mit dieser gekoppelt oder darin integriert sein. Das System 1400 kann Teil eines Mobiltelefons, Smartphones, einer Tablet-Rechenvorrichtung oder einer mobilen internetverbundenen Vorrichtung, wie eines Laptops mit geringer interner Speicherkapazität sein. Das Verarbeitungssystem 1400 kann auch eine Wearable-Vorrichtung, wie eine Smartwatch-Wearable-Vorrichtung; eine intelligente Brille oder Bekleidung, die mit Augmented Reality-(AR)- oder Virtual Reality-(VR)-Merkmalen erweitert ist, um visuelle, auditive Ausgaben bereitzustellen, um visuelle, auditive Erfahrungen der realen Welt zu ergänzen oder anderweitig Text-, Audio-, Grafik-, Video-, holografische Bilder oder Video oder taktile Rückmeldung bereitzustellen; eine andere Augmented Reality-(AR)-Vorrichtung; oder eine andere Virtual Reality-(VR)-Vorrichtung beinhalten, damit gekoppelt sein oder darin integriert sein. Das Verarbeitungssystem 1400 kann ein Fernsehgerät oder eine Set-Top-Box-Vorrichtung beinhalten oder Teil davon sein. Das System 1400 kann ein selbstfahrendes Fahrzeug wie einen Bus, einen Traktoranhänger, ein Auto, ein Motorrad oder E-Bike, ein Flugzeug oder Segelflugzeug (oder eine beliebige Kombination davon) beinhalten, damit gekoppelt oder darin integriert sein. Das selbstfahrende Fahrzeug kann das System 1400 zur Verarbeitung der um das Fahrzeug herum erfassten Umgebung verwenden.
  • Der eine oder die mehreren Prozessoren 1402 können einen oder mehrere Prozessorkerne 1407 beinhalten, um Anweisungen zu verarbeiten, die, wenn sie ausgeführt werden, Operationen für System- oder Benutzersoftware durchführen. Der mindestens eine des einen oder der mehreren Prozessorkerne 1407 kann dazu konfiguriert sein, einen spezifischen Anweisungssatz 1409 zu verarbeiten. Der Anweisungssatz 1409 kann Berechnungen mit komplexem Anweisungssatz (CISC: Complex Instruction Set Computing), Berechnungen mit reduziertem Anweisungssatz (RISC: Reduced Instruction Set Computing) oder Berechnungen über ein sehr langes Befehlswort (VLIW: Very Long Instruction Word) unterstützen. Ein oder mehrere Prozessorkerne 1407 können einen anderen Anweisungssatz 1409verarbeiten, der Anweisungen zum Ermöglichen der Emulation anderer Anweisungssätze beinhalten kann. Der Prozessorkern 1407 kann auch andere Verarbeitungsvorrichtungen beinhalten, wie einen Digitalsignalprozessor (DSP).
  • Der Prozessor 1402 kann einen Cache-Speicher 1404beinhalten. In Abhängigkeit von der Architektur kann der Prozessor 1402 einen einzigen internen Cache oder mehrere Ebenen von internem Cache aufweisen. In einigen Ausführungsformen wird der Cache-Speicher von verschiedenen Komponenten des Prozessors 1402 gemeinsam genutzt. In einigen Ausführungsformen verwendet der Prozessor 1402 auch einen externen Cache (z. B. einen Level-3-(L3)-Cache oder einen Last Level Cache (LLC)) (nicht gezeigt), der von Prozessorkernen 1407 , die bekannte Cache-Kohärenztechniken verwenden, gemeinsam genutzt wird. Eine Registerdatei 1406 kann zusätzlich in dem Prozessor 1402 enthalten sein und kann verschiedene Arten von Registern zum Speichern verschiedener Arten von Daten (z. B. Ganzzahlregister, Gleitkommaregister, Statusregister und ein Anweisungszeigerregister) beinhalten. Manche Register können Universalregister sein, während andere Register für das Design des Prozessors 1402 spezifisch sein können.
  • Der eine oder die mehreren Prozessoren 1402 können mit einem oder mehreren Schnittstellenbussen 1410 zum Übertragen von Kommunikationssignalen, wie Adress-, Daten- oder Steuersignalen, zwischen dem Prozessor 1402 und anderen Komponenten in dem System 1400 gekoppelt sein. Der Schnittstellenbus 1410 kann bei einer dieser Ausführungsformen ein Prozessorbus sein, wie eine Version des DMI-Busses (DMI: Direct Media Interface). Prozessorbusse sind jedoch nicht auf den DMI-Bus beschränkt und können einen oder mehrere Peripheral-Component-Interconnect-Busse (z. B. PCI, PCI Express), Speicherbusse oder andere Arten von Schnittstellenbussen beinhalten. Beispielsweise können der eine oder die mehreren Prozessoren 1402 eine integrierte Speichersteuerung 1416 und einen Plattformsteuerungshub 1430beinhalten. Die Speichersteuerung 1416 ermöglicht eine Kommunikation zwischen einer Speichervorrichtung und anderen Komponenten des Systems 1400, während der Plattformsteuerungshub (PCH: Plattform Controller Hub) 1430 Verbindungen zu E/A-Vorrichtungen über einen lokalen E/A-Bus bereitstellt.
  • Die Speichervorrichtung 1420 kann eine dynamischer-Direktzugriffsspeicher-(DRAM)-Vorrichtung, eine statischer-Direktzugriffsspeicher-(SRAM)-Vorrichtung, eine Flash-Speichervorrichtung, eine Phasenwechselspeichervorrichtung oder eine andere Speichervorrichtung sein, die eine geeignete Leistungsfähigkeit aufweist, um als ein Prozessspeicher zu dienen. Die Speichervorrichtung 1420 kann beispielsweise als Systemspeicher für das System 1400arbeiten, um Daten 1422 und Anweisungen 1421 zu speichern, die verwendet werden, wenn der eine oder die mehreren Prozessoren 1402 eine Anwendung oder einen Prozess ausführen. Die Speichersteuerung 1416 ist auch mit einem optionalen externen Grafikprozessor 1418 gekoppelt, der mit dem einen oder den mehreren Grafikprozessoren 1408 in den Prozessoren 1402 kommunizieren kann, um Grafik- und Medienoperationen durchzuführen. In einigen Ausführungsformen können Grafik-, Medien- und/oder Rechenoperationen durch einen Beschleuniger 1412 unterstützt werden, der ein Coprozessor ist, der dazu konfiguriert sein kann, einen spezialisierten Satz von Grafik-, Medien- oder Rechenoperationen durchzuführen. Der Beschleuniger 1412 kann zum Beispiel ein Matrixmultiplikationsbeschleuniger sein, der verwendet wird, um Maschinenlern- oder Rechenoperationen zu optimieren. Der Beschleuniger 1412 kann ein Strahlverfolgungsbeschleuniger sein, der verwendet werden kann, um Strahlverfolgungsoperationen in Übereinstimmung mit dem Grafikprozessor 1408durchzuführen. In einer Ausführungsform kann ein externer Beschleuniger 1419 anstelle des Beschleunigers 1412 oder zusammen mit diesem verwendet werden.
  • Eine Anzeigevorrichtung 1411 kann bereitgestellt sein, die mit dem einen oder den mehreren Prozessoren 1402 verbunden werden kann. Die Anzeigevorrichtung 1411 kann eine interne Anzeigevorrichtung, wie in einer mobilen elektronischen Vorrichtung oder einer Laptopvorrichtung, und/oder eine externe Anzeigevorrichtung sein, die über eine Anzeigeschnittstelle (z. B. DisplayPort usw.) angeschlossen ist. Die Anzeigevorrichtung 1411 kann eine am Kopf befestigte Anzeige (HMD: Head Mounted Display) sein, wie eine stereoskopische Anzeigevorrichtung zur Verwendung bei Virtual-Reality-(VR)-Anwendungen oder Augmented-Reality-(AR)-Anwendungen.
  • Der Plattformsteuerungshub 1430 kann es Peripheriegeräten ermöglichen, sich über einen Hochgeschwindigkeits-E/A-Bus mit der Speichervorrichtung 1420 und dem Prozessor 1402 zu verbinden. Die E/A-Peripheriegeräte beinhalten, jedoch ohne Einschränkung, eine Audiosteuerung 1446, eine Netzwerksteuerung 1434, eine Firmware-Schnittstelle 1428, einen drahtlosen Sendeempfänger 1426, Berührungssensoren 1425, eine Datenspeicherungsvorrichtung 1424 (z. B. nichtflüchtigen Speicher, flüchtigen Speicher, Festplattenlaufwerk, Flash-Speicher, NAND, 3D NAND, 3D XPoint/Optane usw.). Die Datenspeicherungsvorrichtung 1424 kann über eine Speicherungsschnittstelle (z. B. SATA) oder über einen Peripheriebus, wie einen Peripheral-Component-Interconnect-Bus (z. B. PCI, PCI Express), verbunden sein. Die Berührungssensoren 1425 können Touchscreen-Sensoren, Drucksensoren oder Fingerabdrucksensoren beinhalten. Der drahtlose Sendeempfänger 1426 kann ein WiFi-Sendeempfänger, ein Bluetooth-Sendeempfänger oder ein Mobilnetz-Sendeempfänger sein, wie ein 3G-, 4G-, 5G- oder Long-Term-Evolution-(LTE)-Sendeempfänger. Die Firmware-Schnittstelle 1428 ermöglicht die Kommunikation mit System-Firmware und kann zum Beispiel eine vereinheitlichte erweiterbare Firmware-Schnittstelle (UEFI: Unified Extensible Firmware Interface) sein. Die Netzwerksteuerung 1434 kann eine Netzwerkverbindung zu einem drahtgebundenen Netzwerk ermöglichen. In einigen Ausführungsformen ist eine Hochleistungsnetzwerksteuerung (nicht gezeigt) mit dem Schnittstellenbus 1410 gekoppelt. Die Audiosteuerung 1446 kann eine Mehrkanal-High-Definition-Audiosteuerung sein. In manchen dieser Ausführungsformen beinhaltet das System 1400 eine optionale Legacy-E/A-Steuerung 1440 zum Koppeln von Legacy(z. B. Personal System 2-(PS/2)-Vorrichtungen an das System. Der Plattformsteuerungshub 1430 kann auch mit einer oder mehreren USB-(Universal Serial Bus)-Steuerungen 1442 verbunden sein, welche Eingabevorrichtungen, wie Kombinationen aus Tastatur und Maus 1443 , eine Kamera 1444oder andere USB-Eingabevorrichtungen, verbinden.
  • Es versteht sich, dass das gezeigte System 1400 beispielhaft und nicht beschränkend ist, da andere Arten von Datenverarbeitungssystemen, die anders konfiguriert sind, ebenfalls verwendet werden können. Zum Beispiel kann eine Instanz der Speichersteuerung 1416 und des Plattformsteuerungs-Hubs 1430 in einen diskreten externen Grafikprozessor, wie den externen Grafikprozessor 1418, integriert sein. Der Plattformsteuerungshub 1430 und/oder die Speichersteuerung 1416 können extern zu dem einen oder den mehreren Prozessoren 1402 liegen. Zum Beispiel kann das System 1400 eine externe Speichersteuerung 1416 und einen Plattformsteuerungs-Hub 1430beinhalten, die als ein Speichersteuerungs-Hub und ein Peripheriesteuerungs-Hub innerhalb eines System-Chipsatzes konfiguriert sein können, der mit dem einen oder den mehreren Prozessoren 1402 in Kommunikation steht.
  • Zum Beispiel können Leiterplatten („Sleds“) verwendet werden, auf denen Komponenten wie CPUs, Speicher und andere Komponenten platziert sind, die für eine erhöhte Wärmeleistung ausgelegt sind. Verarbeitungskomponenten, wie die Prozessoren, können sich auf einer Oberseite eines Sleds befinden, während sich Nahspeicher, wie DIMMs, auf einer Unterseite des Sleds befinden. Infolge des verbesserten Luftstroms, der durch diese Gestaltung bereitgestellt wird, können die Komponenten bei höheren Frequenzen und Leistungspegeln als in typischen Systemen arbeiten, wodurch die Leistungsfähigkeit erhöht wird. Des Weiteren sind die Schlitten dazu konfiguriert, blind mit Strom- und Datenkommunikationskabeln in einem Rack zusammenzupassen, wodurch ihre Fähigkeit verbessert wird, schnell entfernt, aufgerüstet, wieder installiert und/oder ersetzt zu werden. Gleichermaßen sind einzelne auf den Sleds befindliche Komponenten wie Prozessoren, Beschleuniger, Speicher und Datenspeicherungslaufwerke so konfiguriert, dass sie sich dank ihrer größeren Beabstandung zueinander leicht aufrüsten lassen. In der veranschaulichenden Ausführungsform beinhalten die Komponenten zusätzlich Hardwareattestierungsmerkmale, um ihre Authentizität nachzuweisen.
  • Ein Datenzentrum kann eine einzelne Netzwerkarchitektur („Fabric“) nutzen, die mehrere andere Netzwerkarchitekturen unterstützt, darunter Ethernet und Omni-Path. Die Sleds können über optische Fasern mit Schaltern gekoppelt sein, die eine höhere Bandbreite und eine niedrigere Latenz als eine typische Twisted-Pair-Verkabelung (z. B. Kategorie 5, Kategorie 5e, Kategorie 6usw.) bereitstellen. Aufgrund der Zwischenverbindungen mit hoher Bandbreite und niedriger Latenz und der Netzwerkarchitektur kann das Datenzentrum im Gebrauch Ressourcen, wie Speicher, Beschleuniger (z. B. GPUs, Grafikbeschleuniger, FPGAs, ASICs, Neuronale-Netzwerk- und/oder Künstliche-Intelligenz-Beschleuniger usw.) und Datenspeicherungslaufwerke, die physisch getrennt sind, zusammenschließen und sie Rechenressourcen (z. B. Prozessoren) nach Bedarf bereitstellen, wodurch ermöglicht wird, dass die Rechenressourcen auf die zusammengeschlossenen Ressourcen zugreifen, als wären sie lokal.
  • Eine Leistungsversorgung oder -Quelle kann Spannung und/oder Strom an das System 1400 oder eine beliebige Komponente oder ein beliebiges System, die/das hierin beschrieben wird, bereitstellen. Bei einem Beispiel beinhaltet die Leistungsversorgung einen AC/DC-(Wechselstrom zu Gleichstrom)-Adapter zum Einstecken in eine Wandsteckdose. Eine derartige Wechselstromversorgung kann eine Energiequelle erneuerbarer Energie (z. B. Solarenergie) sein. In einem Beispiel beinhaltet die Leistungsquelle eine DC-Leistungsquelle, wie einen externen AC-DC-Wandler. Eine Leistungsquelle oder Leistungsversorgung kann auch Drahtlosladehardware zum Laden über die Nähe zu einem Ladefeld beinhalten. Die Leistungsquelle kann eine interne Batterie, eine Wechselstromversorgung, eine bewegungsbasierte Leistungsversorgung, eine Solarenergieversorgung oder eine Brennstoffzellenquelle beinhalten.
  • 15A-15C veranschaulichen Rechensysteme und Grafikprozessoren. Die Elemente von 15A-15C mit den gleichen oder ähnlichen Namen wie die Elemente einer beliebigen anderen Figur hierin beschreiben die gleichen Elemente wie in den anderen Figuren, können auf eine ähnliche Weise wie jene arbeiten oder funktionieren, können die gleichen Komponenten umfassen und können mit anderen Entitäten, wie jenen, die an anderer Stelle hierin beschrieben sind, verknüpft sein, sind aber nicht darauf beschränkt.
  • 15A ist ein Blockdiagramm eines Prozessors 1500, der eine Variante eines der Prozessoren 1402 sein kann und anstelle eines dieser verwendet werden kann. Daher offenbart die Erörterung beliebiger Merkmale in Kombination mit dem Prozessor 1500 hierin auch eine entsprechende Kombination mit dem einen oder den mehreren Prozessoren 1402, ist aber nicht darauf beschränkt. Der Prozessor 1500 kann einen oder mehrere Prozessorkerne 1502A-1502N, eine integrierte Speichersteuerung 1514 und einen integrierten Grafikprozessor 1508aufweisen. Wenn ein integrierter Grafikprozessor 1508 ausgeschlossen ist, kann das System, das den Prozessor beinhaltet, eine Grafikprozessorvorrichtung innerhalb eines Systemchipsatzes beinhalten oder über einen Systembus gekoppelt sein. Der Prozessor 1500 kann zusätzliche Kerne bis zu und einschließlich des zusätzlichen Kerns 1502N beinhalten, der durch die gestrichelten Kästchen dargestellt ist. Jeder der Prozessorkerne 1502A-1502N beinhaltet eine oder mehrere interne Cache-Einheiten 1504A-1504N. In einigen Ausführungsformen hat jeder Prozessorkern 1502A-1502N auch Zugriff auf eine oder mehrere gemeinsam genutzte Cache-Einheiten 1506. Die internen Cache-Einheiten 1504A-1504N und die gemeinsam genutzten Cache-Einheiten 1506 stellen eine Cache-Speicherhierarchie innerhalb des Prozessors 1500dar. Die Cache-Speicherhierarchie kann mindestens einen Level von Anweisungs- und Daten-Cache innerhalb jedes Prozessorkerns und einen oder mehrere Levels von gemeinsam genutztem Mittel-Level-Cache, wie einen Level 2 (L2), Level 3 (L3), Level 4 (L4) oder andere Cache-Levels beinhalten, wobei die höchste Cache-Ebene vor dem externen Speicher als der LLC klassifiziert wird. In einigen Ausführungsformen hält die Cache-Kohärenzlogik die Kohärenz zwischen den verschiedenen Cache-Einheiten 1506 und 1504A-1504N aufrecht.
  • Der Prozessor 1500 kann auch einen Satz von einer oder mehreren Bussteuerungseinheiten 1516 und einen Systemagentenkern 1510 beinhalten. Die eine oder die mehreren Bussteuerungseinheiten 1516 verwalten einen Satz von Peripheriebussen, wie einen oder mehrere PCI- oder PCI-Express-Busse. Der Systemagentenkern 1510 stellt eine Verwaltungsfunktionalität für die verschiedenen Prozessorkomponenten bereit. Der Systemagentenkern 1510 kann eine oder mehrere integrierte Speichersteuerungen 1514 beinhalten, um den Zugriff auf verschiedene externe Speichervorrichtungen (nicht gezeigt) zu verwalten.
  • Beispielsweise können einer oder mehrere der Prozessorkerne 1502A-1502N Unterstützung für simultanes Multithreading beinhalten. Der Systemagentenkern 1510 beinhaltet Komponenten zum Koordinieren und Betreiben der Kerne 1502A-1502N während der Multithread-Verarbeitung. Der Systemagentenkern 1510 kann zusätzlich eine Leistungssteuereinheit (PCU) beinhalten, die Logik und Komponenten zum Regeln des Leistungszustands der Prozessorkerne 1502A-1502N und des Grafikprozessors 1508 beinhaltet.
  • Der Prozessor 1500 kann zusätzlich einen Grafikprozessor 1508 zum Ausführen von Grafikverarbeitungsoperationen beinhalten. In einigen dieser Ausführungsformen ist der Grafikprozessor 1508 mit dem Satz von gemeinsam genutzten Cacheeinheiten 1506und dem Systemagentenkern 1510gekoppelt, einschließlich der einen oder der mehreren integrierten Speichersteuerungen 1514. Der Systemagentenkern 1510 kann auch eine Anzeigesteuerung 1511 zum Steuern die Grafikprozessorausgabe an eine oder mehrere gekoppelte Anzeigen beinhalten. Die Anzeigesteuerung 1511 kann auch ein separates Modul sein, das über mindestens ein Interconnect mit dem Grafikprozessor gekoppelt ist, oder kann in den Grafikprozessor 1508integriert sein.
  • Eine ringbasierte Interconnect-Einheit 1512 kann verwendet werden, um die internen Komponenten des Prozessors 1500zu koppeln. Es kann jedoch auch eine alternative Interconnect-Einheit verwendet werden, wie ein Punkt-zu-Punkt-Interconnect, ein vermitteltes Interconnect oder andere Techniken, einschließlich im Stand der Technik bestens bekannter Techniken. In einigen dieser Ausführungsformen mit einem ringbasierten Interconnect 1512 ist der Grafikprozessor 1508 mit dem ringbasierten Interconnect 1512 über einen E/A-Link 1513gekoppelt.
  • Der beispielhafte E/A-Link 1513 repräsentiert mindestens eine von mehreren Varianten von E/A-Interconnects, einschließlich eines On-Package-E/A-Interconnects, das die Kommunikation zwischen verschiedenen Prozessorkomponenten und einem eingebetteten Hochleistungsspeichermodul 1518 wie einem eDRAM-Modul ermöglicht. Optional können jeder der Prozessorkerne 1502A-1502N und der Grafikprozessor 1508 eingebettete Speichermodule 1518 als einen gemeinsam genutzten Last-Level-Cache verwenden.
  • Die Prozessorkerne 1502A-1502N können beispielsweise homogene Kerne sein, die dieselbe Anweisungssatzarchitektur ausführen. Alternativ sind die Prozessorkerne 1502A-1502N hinsichtlich der Anweisungssatzarchitektur (ISA: Instruction Set Architecture) heterogen, wobei einer oder mehrere der Prozessorkerne 1502A-1502N einen ersten Anweisungssatz ausführen, während mindestens einer der anderen Kerne einen Teilsatz des ersten Anweisungssatzes oder einen anderen Anweisungssatz ausführt. Die Prozessorkerne 1502A-1502N können in Bezug auf die Mikroarchitektur heterogen sein, wobei ein oder mehrere Kerne mit einem relativ höheren Leistungsverbrauch mit einem oder mehreren Leistungskernen mit einem niedrigeren Leistungsverbrauch gekoppelt sind. Als weiteres Beispiel sind die Prozessorkerne 1502A-1502N hinsichtlich der Rechenfähigkeit heterogen. Außerdem kann der Prozessor 1500 auf einem oder mehreren Chips oder als eine integrierte SoC-Schaltung mit den veranschaulichten Komponenten zusätzlich zu anderen Komponenten implementiert sein.
  • 15B ist ein Blockdiagramm einer Hardwarelogik eines Grafikprozessorkerns 1519 gemäß einigen hierin beschriebenen Ausführungsformen. Der Grafikprozessorkern 1519, der manchmal als Kern-Slice bezeichnet wird, kann ein oder mehrere Grafikkerne innerhalb eines modularen Grafikprozessors sein. Der Grafikprozessorkern 1519 ist ein Beispiel für ein Grafikkern-Slice, und ein Grafikprozessor, wie hierin beschrieben, kann mehrere Grafikkern-Slices basierend auf Zielleistungs- und Leistungsfähigkeitsumfang beinhalten. Jeder Grafikprozessorkern 1519 kann einen Festfunktionsblock 1530 beinhalten, der mit mehreren Unterkernen 1521A-1521F gekoppelt ist, die auch als Unter-Slices bezeichnet werden, die modulare Blöcke von Universal- und Festfunktionslogik beinhalten. In einer Konfiguration ist ein Unter-Kern (Unter-Slice) der mehreren Unterkerne 1521A bis 1521F ein architekturales Äquivalent zu einem Grafikmultiprozessor 234 von 2D, Grafikmultiprozessor 325 von 3A und/oder eine Mehrkerngruppe der Mehrkerngruppen 365A-365N von 3C.
  • Der Festfunktionsblock 1530 kann eine Geometrie/Festfunktions-Pipeline 1531 beinhalten, die durch alle Unterkerne in dem Grafikprozessorkern 1519gemeinsam genutzt werden kann, zum Beispiel bei Grafikprozessorimplementierungen mit geringerer Leistungsfähigkeit und/oder geringerer Leistung. Die Geometrie-/Festfunktions-Pipeline 1531 kann eine 3D-Festfunktions-Pipeline (z. B. die 3D-Pipeline 1612 wie in 16A unten beschrieben), eine Video-Frontend-Einheit, einen Thread-Spawner und Thread-Dispatcher und einen vereinheitlichten Rückgabepuffermanager, der vereinheitlichte Rückgabepuffer (z. B. den vereinheitlichten Rückgabepuffer 1718 in 17, wie unten beschrieben) verwaltet, beinhalten.
  • Der Festfunktionsblock 1530 kann auch eine Grafik-SoC-Schnittstelle 1532, einen Grafik-Mikrocontroller 1533und eine Medien-Pipeline 1534beinhalten. Die Grafik-SoC-Schnittstelle 1532 stellt eine Schnittstelle zwischen dem Grafikprozessorkern 1519 und anderen Prozessorkernen innerhalb einer integrierten System-on-Chip-Schaltung bereit. Der Grafikmikrocontroller 1533 ist ein programmierbarer Subprozessor, der dazu konfigurierbar ist, verschiedene Funktionen des Grafikprozessorkerns 1519 zu verwalten, einschließlich Thread-Dispatch, Scheduling und Präemption. Die Medien-Pipeline 1534 (z. B. Medien-Pipeline 1616 von 16A und 17) beinhaltet eine Logik, um das Decodieren, Codieren, Vorverarbeiten und/oder Nachverarbeiten von Multimediadaten, einschließlich Bild- und Videodaten, zu erleichtern. Die Medien-Pipeline 1534 implementiert Medienoperationen über Anforderungen zum Berechnen oder Sampeln einer Logik innerhalb der Unterkerne 1521-1521F.
  • Die SoC-Schnittstelle 1532 kann dem Grafikprozessorkern 1519 die Kommunikation mit Prozessorkernen für Universalanwendungen (z. B. CPUs) und/oder anderen Komponenten innerhalb eines SoC ermöglichen, einschließlich Speicherhierarchieelementen wie ein gemeinsam genutzter Last-Level-Cache-Speicher, der System-RAM und/oder eingebetteter On-Chip- oder On-Package-DRAM. Die SoC-Schnittstelle 1532 kann auch eine Kommunikation mit Festfunktionsvorrichtungen innerhalb des SoC ermöglichen, wie Kamerabildgebungs-Pipelines, und ermöglicht die Verwendung von und/oder implementiert globale Speicheratomik, die zwischen dem Grafikprozessorkern 1519 und CPUs innerhalb des SoC gemeinsam genutzt werden kann. Die SoC-Schnittstelle 1532 kann auch Leistungsverwaltungssteuerungen für den Grafikprozessorkern 1519 implementieren und eine Schnittstelle zwischen einer Taktdomäne des Grafikprozessorkerns 1519 und anderen Taktdomänen innerhalb des SoC ermöglichen. Optional ermöglicht die SoC-Schnittstelle 1532 den Empfang von Befehlspuffern von einem Befehls-Streamer und globalen Thread-Dispatcher, die dazu konfiguriert sind, Befehle und Anweisungen an jeden von einem oder mehreren Grafikkernen innerhalb eines Grafikprozessors bereitzustellen. Die Befehle und Anweisungen können an die Medien-Pipeline 1534 gesendet werden, wenn Medienoperationen durchzuführen sind, oder an eine Geometrie- und Festfunktions-Pipeline (z. B. die Geometrie- und Festfunktions-Pipeline 1531, die Geometrie- und Festfunktions-Pipeline 1537), wenn Grafikverarbeitungsoperationen durchzuführen sind.
  • Der Grafikmikrocontroller 1533 kann dazu konfiguriert sein, verschiedene Planungs- und Verwaltungsaufgaben für den Grafikprozessorkern 1519durchzuführen. In einer Konfiguration kann der Grafik-Mikrocontroller 1533 beispielsweise Grafik- und/oder Rechenlast-Scheduling auf den verschiedenen parallelen Grafik-Engines innerhalb der Arrays 1522A-1522F, 1524A-1524F der Ausführungseinheiten (EU) innerhalb der Unterkerne 1521A-1521F durchführen. Bei diesem Arbeitslast-Scheduling kann Hostsoftware, die auf einem CPU-Kern eines den Grafikprozessorkern 1519 beinhaltenden SoC ausgeführt wird, Arbeitslasten einer von mehreren Grafikprozessor-Doorbells liefern, was eine Scheduling-Operation auf der entsprechenden Grafik-Engine aktiviert. Zu Scheduling-Operationen zählen Bestimmen, welche Arbeitslast als nächstes ausgeführt werden soll, liefern einer Arbeitslast an einen Befehls-Streamer, Präemptieren bestehender Arbeitslasten, die auf einer Engine ausgeführt werden, Überwachen des Fortschritts einer Arbeitslast und Benachrichtigen einer Hostsoftware, wenn eine Arbeitslast abgeschlossen ist. Optional kann der Grafik-Mikrocontroller 1533 auch Niederleistungs- oder Leerlaufzustände für den Grafikprozessorkern 1519ermöglichen, indem er dem Grafikprozessorkern 1519 die Möglichkeit gibt, Register innerhalb des Grafikprozessorkerns 1519 über Niederleistungszustandsübergänge hinweg unabhängig von dem Betriebssystem und/oder der Grafiktreibersoftware auf dem System zu speichern und wiederherzustellen.
  • Der Grafikprozessorkern 1519 kann mehr als oder weniger als die veranschaulichten Unterkerne 1521A-1521F, bis zu N modulare Unterkerne, aufweisen. Für jeden Satz von NUnterkernen kann der Grafikprozessorkern 1519 auch Logik 1535 mit gemeinsam genutzter Funktion, gemeinsam genutzten und/oder Cache-Speicher 1536, eine Geometrie-/Festfunktions-Pipeline 1537sowie zusätzliche Festfunktions-Logik 1538zum Beschleunigen verschiedener Grafik- und Rechenverarbeitungsoperationen beinhalten. Die Logik 1535 mit gemeinsam genutzter Funktion kann Logikeinheiten beinhalten, die der Logik 1720 mit gemeinsam genutzter Funktion von 17 (z. B. Sampler, Mathematik und/oder Inter-Thread-Kommunikationslogik) zugeordnet sind, die von jedem N Unterkern innerhalb des Grafikprozessorkerns 1519 gemeinsam genutzt werden können. Der gemeinsam genutzte und/oder Cache-Speicher 1536 kann ein Last-Level-Cache für den Satz von NUnterkernen 1521A-1521F innerhalb des Grafikprozessorkerns 1519 sein und kann auch als gemeinsam genutzter Speicher dienen, auf den mehrere Unterkerne zugreifen können. Die Geometrie-/Festfunktions-Pipeline 1537 kann anstelle der Geometrie-/Festfunktions-Pipeline 1531 innerhalb des Festfunktionsblocks 1530 enthalten sein und die gleichen oder ähnliche Logikeinheiten beinhalten.
  • Der Grafikprozessorkern 1519 kann zusätzliche Festfunktionslogik 1538 beinhalten, die verschiedene Festfunktionsbeschleunigungslogik zur Verwendung durch den Grafikprozessorkern 1519 beinhalten kann. Optional beinhaltet die zusätzliche Festfunktionslogik 1538 eine zusätzliche Geometrie-Pipeline zur Verwendung beim Nur-Positions-Shading. Beim Nur-Positions-Shading existieren zwei Geometrie-Pipelines, die vollständige Geometrie-Pipeline innerhalb der Geometrie-/Festfunktions-Pipeline 1538, 1531und eine Cull-Pipeline, die eine zusätzliche Geometrie-Pipeline ist, die in der zusätzlichen Festfunktionslogik 1538 enthalten sein kann. Zum Beispiel kann die Cull-Pipeline eine abgespeckte Version der vollständigen Geometrie-Pipeline sein. Die vollständige Pipeline und die Cull-Pipeline können verschiedene Instanzen derselben Anwendung ausführen, wobei jede Instanz einen separaten Kontext aufweist. Das Nur-Positions-Shading kann lange Cull-Durchläufe von verworfenen Dreiecken verbergen, wodurch das Shading in manchen Fällen früher abgeschlossen werden kann. Zum Beispiel kann die Cull-Pipeline-Logik innerhalb der zusätzlichen Festfunktionslogik 1538 Positions-Shader parallel zur Hauptanwendung ausführen und erzeugt allgemein kritische Ergebnisse schneller als die vollständige Pipeline, da die Cull-Pipeline nur das Positionsattribut der Vertices abruft und diese schattiert, ohne Rasterisierung und Rendering der Pixel zum Framepuffer durchzuführen. Die Cull-Pipeline kann die erzeugten kritischen Ergebnisse verwenden, um Sichtbarkeitsinformationen für alle Dreiecke zu berechnen, ohne Rücksicht darauf, ob diese Dreiecke ausgesondert werden. Die vollständige Pipeline (die in diesem Fall als Wiedergabe-Pipeline bezeichnet werden kann) kann die Sichtbarkeitsinformationen verbrauchen, um die aussortierten Dreiecke zu überspringen, um nur an den sichtbaren Dreiecken Shading durchzuführen, die schließlich an die Rasterisierungsphase übergeben werden.
  • Optional kann die zusätzliche Festfunktionslogik 1538 auch Maschinenlernbeschleunigungslogik, wie Festfunktionsmatrix-Multiplikationslogik, für Implementierungen einschließlich Optimierungen für Maschinenlerntraining oder Inferenz beinhalten.
  • Innerhalb jedes Grafikunterkerns 1521A-1521F ist ein Satz von Ausführungsressourcen enthalten, die verwendet werden können, um Grafik-, Medien- und Rechenoperationen als Reaktion auf Anforderungen durch eine Grafik-Pipeline, Medien-Pipeline oder Shader-Programme durchzuführen. Die Grafikunterkerne 1521A-1521F beinhalten mehrere EU-Arrays 1522A-1522F, 1524A-1524F, Thread-Dispatch- und Inter-Thread-Kommunikations-(TD/IC)-Logik 1523A-1523F, einen 3D-(z. B. Textur)-Sampler 1525A-1525F, einen Medien-Sampler 1526A-1526F, einen Shader-Prozessor 1527A-1527F und gemeinsam genutzten lokalen Speicher (SLM) 1528A-1528F. Die EU-Arrays 1522A-1522F, 1524A-1524F beinhalten jeweils mehrere Ausführungseinheiten, die Universal-Grafikverarbeitungseinheiten sind, die in der Lage sind, Gleitkomma- und Ganzzahl-/Festkomma-Logikoperationen beim Dienst einer Grafik-, Medien- oder Rechenoperation durchzuführen, einschließlich Grafik-, Medien- oder Rechen-Shader-Programmen. Die TD/IC-Logik 1523A-1523F führt lokale Thread-Dispatch- und Thread-Steueroperationen für die Ausführungseinheiten innerhalb eines Unterkerns aus und ermöglicht die Kommunikation zwischen Threads, die auf den Ausführungseinheiten des Unterkerns ausgeführt werden. Der 3D-Sampler 1525A-1525F kann Textur- oder andere 3D-Grafik-bezogene Daten in den Speicher lesen. Der 3D-Sampler kann Texturdaten unterschiedlich basierend auf einem konfigurierten Sample-Zustand und dem mit einer bestimmten Textur assoziierten Texturformat lesen. Der Medien-Sampler 1526A-1526F kann ähnliche Leseoperationen basierend auf der Art und dem Format durchführen, die mit den Mediendaten assoziiert sind. Zum Beispiel kann jeder Grafikunterkern 1521A-1521F abwechselnd einen vereinheitlichten 3D- und Medien-Sampler beinhalten. Threads, die auf den Ausführungseinheiten innerhalb jedes der Unterkerne 1521A-1521F ausgeführt werden, können gemeinsam genutzten lokalen Speicher 1528A-1528F innerhalb jedes Unterkerns ausnutzen, um Threads, die innerhalb einer Thread-Gruppe ausgeführt werden, zu ermöglichen, unter Verwendung eines gemeinsamen Pools von On-Chip-Speicher ausgeführt zu werden.
  • 15C ist ein Blockdiagramm einer Universal-Grafikverarbeitungseinheit (GPGPU) 1570, die als ein Grafikprozessor, z. B. der Grafikprozessor 1508, und/oder ein Berechnungsbeschleuniger konfiguriert sein kann, gemäß hierin beschriebenen Ausführungsformen. Die GPGPU 1570 kann mit Host-Prozessoren (z. B. eine oder mehrere CPU(s) 1546) und Speicher 1571, 1572 über einen oder mehrere System- und/oder Speicherbusse verbunden sein. Der Speicher 1571 kann Systemspeicher sein, der mit der einen oder den mehreren CPUs 1546 gemeinsam genutzt werden kann, während der Speicher 1572 ein Vorrichtungsspeicher ist, der der GPGPU 1570 dediziert ist. Zum Beispiel können Komponenten innerhalb der GPGPU 1570 und des Speichers 1572 in Speicheradressen abgebildet werden, auf die die eine oder die mehreren CPU(s) 1546 zugreifenkönnen. Der Zugriff auf die Speicher 1571 und 1572 kann über eine Speichersteuerung 1568ermöglicht werden. Die Speichersteuerung 1568 kann eine interne Direktspeicherzugriff-s(DMA)-Steuerung 1569 beinhalten oder kann Logik zum Durchführen von Operationen beinhalten, die ansonsten durch eine DMA-Steuerung durchgeführt würden.
  • Die GPGPU 1570 weist mehrere Cache-Speicher auf, einschließlich eines L2-Caches 1553, L1-Caches 1554, eines Anweisungscaches 1555und eines gemeinsam genutzten Speichers 1556, von dem zumindest ein Teil auch als Cache-Speicher partitioniert werden kann. Die GPGPU 1570 weist auch mehrere Recheneinheiten 1560A-1560N auf. Jede Recheneinheit 1560A-1560N beinhaltet einen Satz von Vektorregistern 1561, Skalarregistern 1562, Vektorlogikeinheiten 1563und Skalarlogikeinheiten 1564. Die Recheneinheiten 1560A-1560N können auch einen lokalen gemeinsam genutzten Speicher 1565 und einen Programmzähler 1566 beinhalten. Die Recheneinheiten 1560A-1560N können mit einem konstanten Cache 1567gekoppelt sein, der zum Speichern von konstanten Daten verwendet werden kann, die Daten sind, die sich während der Ausführung eines Kernel- oder Shader-Programms, das auf der GPGPU 1570 ausgeführt wird, nicht ändern können. Der konstante Cache 1567 kann ein Skalardaten-Cache sein und zwischengespeicherte Daten können direkt in die Skalarregister 1562abgerufen werden.
  • Während des Betriebs können die eine oder die mehreren CPU(s) 1546 Befehle in Register oder Speicher in der GPGPU 1570 schreiben, die in einen zugänglichen Adressraum abgebildet wurde. Die Befehlsprozessoren 1557 können die Befehle aus Registern oder dem Speicher lesen und bestimmen, wie diese Befehle innerhalb der GPGPU 1570 verarbeitet werden können. Ein Thread-Dispatcher 1558 kann dann verwendet werden, um Threads an die Recheneinheiten 1560A-1560N zu senden, um diese Befehle durchzuführen. Jede Recheneinheit 1560A-1560N kann Threads unabhängig von den anderen Recheneinheiten ausführen. Zusätzlich dazu kann jede Recheneinheit 1560A-1560N unabhängig für eine bedingte Berechnung konfiguriert sein und kann die Ergebnisse der Berechnung bedingt an den Speicher ausgeben. Die Befehlsprozessoren 1557 können die eine oder die mehreren CPU(s) 1546 unterbrechen, wenn die übermittelten Befehle abgeschlossen sind.
  • 16A bis 16C veranschaulichen Blockdiagramme zusätzlicher Grafikprozessor- und Rechenbeschleunigerarchitekturen, die durch hier beschriebene Ausführungsformen bereitgestellt werden, z. B. gemäß 15A-15C. Die Elemente von 16A-16C mit den gleichen oder ähnlichen Namen wie die Elemente einer beliebigen anderen Figur hierin beschreiben die gleichen Elemente wie in den anderen Figuren, können auf eine ähnliche Weise wie jene arbeiten oder funktionieren, können die gleichen Komponenten umfassen und können mit anderen Entitäten, wie jenen, die an anderer Stelle hierin beschrieben sind, verknüpft sein, sind aber nicht darauf beschränkt.
  • 16A ist ein Blockdiagramm eines Grafikprozessors 1600, der eine diskrete Grafikverarbeitungseinheit sein kann oder ein Grafikprozessor sein kann, der mit mehreren Verarbeitungskernen integriert ist, oder andere Halbleitervorrichtungen, wie, jedoch ohne Einschränkung, Speichervorrichtungen oder Netzwerkschnittstellen. Der Grafikprozessor 1600 kann eine Variante des Grafikprozessors 1508 sein und kann anstelle des Grafikprozessors 1508 verwendet werden. Daher offenbart die Erörterung jeglicher Merkmale in Kombination mit dem Grafikprozessor 1508 hierin auch eine entsprechende Kombination mit dem Grafikprozessor 1600, ist aber nicht darauf beschränkt. Der Grafikprozessor kann über eine speicherabgebildete E/A-Schnittstelle mit Registern auf dem Grafikprozessor und mit in den Prozessorspeicher platzierten Befehlen kommunizieren. Der Grafikprozessor 1600 kann eine Speicherschnittstelle 1614 zum Zugreifen auf Speicher beinhalten. Die Speicherschnittstelle 1614 kann eine Schnittstelle zu lokalem Speicher, einem oder mehreren internen Caches, einem oder mehreren gemeinsam genutzten externen Caches und/oder zu Systemspeicher sein.
  • Optional beinhaltet der Grafikprozessor 1600 zudem eine Anzeigesteuerung 1602, um Anzeigeausgabedaten zu einer Anzeigevorrichtung 1618 zu steuern. Die Anzeigesteuerung 1602 beinhaltet Hardware für eine oder mehrere Überlagerungsebenen für die Anzeige und Zusammensetzung mehrerer Schichten von Video- oder Benutzeroberflächenelementen. Die Anzeigevorrichtung 1618 kann eine interne oder externe Anzeigevorrichtung sein. In einer Ausführungsform ist die Anzeigevorrichtung 1618 eine am Kopf befestigte Anzeigevorrichtung, wie eine Virtual-Reality-(VR)-Anzeigevorrichtung oder eine Augmented-Reality-(AR)-Anzeigevorrichtung. Der Grafikprozessor 1600 kann eine Video-Codec-Engine 1606 zum Codieren, Decodieren oder Transcodieren von Medien zu, von oder zwischen einem oder mehreren Mediencodierungsformaten beinhalten, einschließlich, ohne Einschränkung auf Moving Picture Experts Group-(MPEG)-Formate, wie MPEG-2, Advanced Video Coding-(AVC)-Formate, wie H.264/MPEG-4 AVC, H.265/HEVC, Alliance for Open Media (AMMedia) VP8, VP9, sowie die Formate der Society of Motion Picture & Television Engineers (SMPTE) 421M/VC-1 und der Joint Photographic Experts Group (JPEG), wie JPEG- und MJPEG-Formate (MJPEG: Motion JPEG).
  • Der Grafikprozessor 1600 kann eine Blockbildtransfer-(BLIT)-Engine 1603 beinhalten, um zweidimensionale (2D) Rasterisiereroperationen durchzuführen, einschließlich zum Beispiel Bitgrenzblocktransfers. Alternativ dazu können jedoch 2D Grafikoperationen unter Verwendung einer oder mehrerer Komponenten der Grafikverarbeitungs-Engine (GPE) 1610durchgeführt werden. In einigen Ausführungsformen ist die GPE 1610 eine Rechen-Engine zum Durchführen von Grafikoperationen, einschließlich dreidimensionaler (3D) Grafikoperationen und Medienoperationen.
  • Die GPE 1610 kann eine 3D-Pipeline 1612 zum Durchführen von 3D-Operationen beinhalten, wie Rendering von dreidimensionalen Bildern und Szenen unter Verwendung von Verarbeitungsfunktionen, die auf 3D-Primitivformen (z. B. Rechteck, Dreieck usw.) wirken. Die 3D-Pipeline 1612 beinhaltet programmierbare und Festfunktionselemente, die verschiedene Aufgaben innerhalb des Elements durchführen und/oder Ausführungs-Threads zu einem 3D-/Medien-Subsystem 1615 spawnen. Obwohl die 3D-Pipeline 1612 zum Durchführen von Medienoperationen verwendet werden kann, beinhaltet eine Ausführungsform der GPE 1610 auch eine Medien-Pipeline 1616 , die speziell zum Durchführen von Medienoperationen, wie Videonachbearbeitung und Bildverbesserung, verwendet wird.
  • Die Medien-Pipeline 1616 kann Festfunktions- oder programmierbare Logikeinheiten beinhalten, um eine oder mehrere spezialisierte Medienoperationen, wie Videodecodierungsbeschleunigung, Videoentschachtelung und Videocodierungsbeschleunigung, anstelle von oder im Auftrag der Video-Codec-Engine 1606 durchzuführen. Die Medien-Pipeline 1616 kann außerdem eine Thread-Spawning-Einheit beinhalten, um Threads zur Ausführung auf 3D/Medien-Subsystem 1615zu spawnen. Die erzeugten Threads führen Berechnungen für die Medienoperationen auf einer oder mehreren Grafikausführungseinheiten durch, die in 3D/Medien-Subsystem 1615 enthalten sind.
  • Das 3D-/Medien-Subsystem 1615 kann Logik zum Ausführen von durch die 3D-Pipeline 1612und die Medien-Pipeline 1616 gespawnten Threads beinhalten. Die Pipelines können Thread-Ausführungsanforderungen an das 3D-/Medien-Subsystem 1615 senden, das eine Thread-Dispatch-Logik zum arbitrieren und Dispatchen der verschiedenen Anforderungen an verfügbare Thread-Ausführungsressourcen beinhaltet. Die Ausführungsressourcen beinhalten ein Array von Grafikausführungseinheiten zum Verarbeiten der 3D- und Medien-Threads. Das 3D-/Medien-Subsystem 1615 kann einen oder mehrere interne Caches für Thread-Anweisungen und Daten beinhalten. Zusätzlich kann das 3D-/Medien-Subsystem 1615 auch gemeinsam genutzten Speicher beinhalten, einschließlich Registern und adressierbarem Speicher, um Daten zwischen Threads gemeinsam zu nutzen und Ausgabedaten zu speichern.
  • 16B veranschaulicht einen Grafikprozessor 1620, der eine Variante des Grafikprozessors 1600 ist und anstelle des Grafikprozessors 1600 verwendet werden kann und umgekehrt. Daher offenbart die Erörterung jeglicher Merkmale in Kombination mit dem Grafikprozessor 1600 hierin auch eine entsprechende Kombination mit dem Grafikprozessor 1620, ist aber nicht darauf beschränkt. Der Grafikprozessor 1620 weist gemäß hierin beschriebenen Ausführungsformen eine gekachelte Architektur auf. Der Grafikprozessor 1620 kann einen Grafikverarbeitungs-Engine-Cluster 1622 mit mehreren Instanzen der Grafikverarbeitungs-Engine 1610 von 16A innerhalb einer Grafik-Engine-Kachel 1610A-1610D beinhalten. Jede Grafik-Engine-Kachel 1610A-1610D kann über einen Satz von Kachel-Interconnects 1623A-1623F miteinander verbunden sein. Jede Grafik-Engine-Kachel 1610A-1610D kann auch über Speicherverbindungen 1625A-1625Dmit einem Speichermodul oder einer Speichervorrichtung 1626A-1626D verbunden sein. Die Speichervorrichtungen 1626A-1626D können eine beliebige Grafikspeichertechnologie verwenden. Zum Beispiel können die Speichervorrichtungen 1626A-1626D ein Grafikspeicher mit doppelter Datenrate (GDDR) sein. Die Speichervorrichtungen 1626A-1626D können Hochbandbreitenspeicher(HBM)-Module sein, die sich mit ihrer jeweiligen Grafik-Engine-Kachel 1610A-1610D auf dem Die befinden können. Die Speichervorrichtungen 1626A-1626D können gestapelte Speichervorrichtungen sein, die auf ihrer jeweiligen Grafik-Engine-Kachel 1610A-1610D gestapelt sein können. Jede Grafik-Engine-Kachel 1610A-1610D und ein zugehöriger Speicher 1626A-1626D können sich auf separaten Chiplets befinden, die an einen Basis-Die oder ein Basissubstrat gebondet sind, wie in 24B-24D ausführlicher beschrieben.
  • Der Grafikprozessor 1620 kann mit einem Non-Uniform-Memory-Access-(NUMA; ungleichförmiger Speicherzugriff)-System konfiguriert sein, in dem die Speichervorrichtungen 1626A-1626D mit zugehörigen Grafik-Engine-Kacheln 1610A-1610Dgekoppelt sind. Auf eine gegebene Speichervorrichtung kann durch andere Grafik-Engine-Kacheln als die Kachel zugegriffen werden, mit der sie direkt verbunden ist. Jedoch kann die Zugriffslatenz auf die Speichervorrichtungen 1626A-1626D am niedrigsten sein, wenn auf eine lokale Kachel zugegriffen wird. Bei einer Ausführungsform ist ein cachekohärentes NUMA-(ccNUMA)-System aktiviert, das die Kachel-Interconnects 1623A-1623F verwendet, um eine Kommunikation zwischen Cache-Steuerungen innerhalb der Grafik-Engine-Kacheln 1610A-1610D zu ermöglichen, um ein konsistentes Speicherabbild beizubehalten, wenn mehr als ein Cache denselben Speicherort speichert.
  • Der Grafikverarbeitungs-Engine-Cluster 1622 kann mit einem On-Chip- oder On-Package-Fabric-Interconnect 1624 verbunden sein. In einer Ausführungsform beinhaltet das Fabric-Interconnect 1624 einen Netzwerkprozessor, Network on a Chip (NoC), oder einen anderen Vermittlungsprozessor, um dem Fabric-Interconnect 1624 zu ermöglichen, als ein paketvermitteltes Fabric-Interconnect zu fungieren, das Datenpakete zwischen Komponenten des Grafikprozessors 1620 vermittelt. Das Fabric-Interconnect 1624 kann die Kommunikation zwischen den Grafik-Engine-Kacheln 1610A-1610D und Komponenten wie der Video-Codec-Engine 1606 und einer oder mehreren Kopier-Engines 1604 ermöglichen. Die Kopier-Engines 1604 können verwendet werden, um Daten aus den, in die und zwischen den Speichervorrichtungen 1626A-1626D und dem Speicher, der sich außerhalb des Grafikprozessors 1620 befindet (z. B. Systemspeicher), zu verschieben. Das Fabric-Interconnect 1624 kann auch verwendet werden, um die Grafik-Engine-Kacheln 1610A-1610D miteinander zu verbinden. Der Grafikprozessor 1620 kann optional eine Anzeigesteuerung 1602 beinhalten, um eine Verbindung mit einer externen Anzeigevorrichtung 1618 zu ermöglichen. Der Grafikprozessor kann auch als Grafik- oder Rechenbeschleuniger konfiguriert sein. In der Beschleunigerkonfiguration können die Anzeigesteuerung 1602 und die Anzeigevorrichtung 1618 weggelassen werden.
  • Der Grafikprozessor 1620 kann über eine Hostschnittstelle 1628 mit einem Hostsystem verbunden sein. Die Hostschnittstelle 1628 kann eine Kommunikation zwischen dem Grafikprozessor 1620, dem Systemspeicher und/oder anderen Systemkomponenten ermöglichen. Die Hostschnittstelle 1628 kann zum Beispiel ein PCI-Express-Bus oder eine andere Art von Hostsystemschnittstelle sein. Zum Beispiel kann die Hostschnittstelle 1628 eine NVLink- oder NVSwitch-Schnittstelle sein. Die Hostschnittstelle 1628 und die Fabric-Verbindung 1624 können zusammenwirken, um zu ermöglichen, dass mehrere Instanzen des Grafikprozessors 1620 als eine einzelne logische Vorrichtung fungieren. Die Zusammenarbeit zwischen der Hostschnittstelle 1628 und dem Fabric-Interconnect 1624 kann auch ermöglichen, dass die einzelnen Grafik-Engine-Kacheln 1610A-1610D dem Host-System als distinkte logische Grafikvorrichtungen präsentiert werden.
  • 16C veranschaulicht einen Rechenbeschleuniger 1630gemäß hierin beschriebenen Ausführungsformen. Der Berechnungsbeschleuniger 1630 kann architektonische Ähnlichkeiten mit dem Grafikprozessor 1620 von 16B beinhalten und ist für die Rechenbeschleunigung optimiert. Ein Berechnungs-Engine -Cluster 1632 kann einen Satz von Berechnungs-Engine-Kacheln 1640A-1640D beinhalten, die eine Ausführungslogik beinhalten, die für parallele oder vektorbasierte Universalrechenoperationen optimiert ist. Die Berechnungs-Engine-Kacheln 1640A-1640D beinhalten möglicherweise keine Festfunktions-Grafikverarbeitungslogik, obwohl in manchen Ausführungsformen eine oder mehrere der Berechnungs-Engine-Kacheln 1640A-1640D Logik zum Durchführen einer Medienbeschleunigung beinhalten können. Die Berechnungs-Engine-Kacheln 1640A-1640D können mit dem Speicher 1626D-1640Düber Speicher-Interconnects 1625A-1625D verbunden sein. Der Speicher 1626A-1626D und die Speicher-Interconnects 1625A-1625D können eine ähnliche Technologie wie im Grafikprozessor 1620aufweisen oder können unterschiedlich sein. Die Grafikberechnungs-Engine-Kacheln 1640A-1640D können auch über einen Satz von Kachel-Interconnects 1623A-1623F miteinander verbunden sein und können mit einem Fabric-Interconnect 1624verbunden und/oder durch dieses miteinander verbunden sein. In einer Ausführungsform weist der Rechenbeschleuniger 1630 einen großen L3-Cache 1636 auf, der als ein vorrichtungsumfassender Cache konfiguriert sein kann. Der Berechnungsbeschleuniger 1630 kann mit einem Hostprozessor und Speicher auch über eine Hostschnittstelle 1628 in ähnlicher Weise wie der Grafikprozessor 1620 von 16B verbunden sein.
  • Der Rechenbeschleuniger 1630 kann auch eine integrierte Netzwerkschnittstelle 1642 beinhalten. In einer Ausführungsform weist die integrierte Netzwerkschnittstelle 1642 einen Netzwerkprozessor und eine Steuerlogik auf, die dem Rechen-Engine-Cluster 1632 ermöglicht, über ein Bitübertragungsschicht-Interconnect 1644 zu kommunizieren, ohne dass Daten zum Traversieren des Speichers eines Hostsystems erforderlich sind. In einer Ausführungsform ist eine der Rechen-Engine-Kacheln 1640A-1640D durch Netzwerkprozessorlogik ersetzt und Daten, die über das Bitübertragungsschicht-Interconnect 1644 übertragen oder empfangen werden sollen, können direkt an oder aus dem Speicher 1626A-1626D übertragen werden. Mehrere Instanzen des Rechenbeschleunigers 1630 können über das Bitübertragungsschicht-Interconnect 1644 zu einer einzigen logischen Vorrichtung zusammengefügt sein. Alternativ dazu können die verschiedenen Rechen-Engine-Kacheln 1640A-1640D als getrennte netzwerkzugängliche Rechenbeschleunigervorrichtungen präsentiert werden.
  • Grafikverarbeitungs-Engine
  • 17 ist ein Blockdiagramm einer Grafikverarbeitungs-Engine 1710 eines Grafikprozessors gemäß einigen Ausführungsformen. Die Grafikverarbeitungs-Engine (GPE) 1710 kann eine Version der GPE 1610 sein, die in 16A gezeigt ist, und kann auch eine Grafik-Engine-Kachel 1610A-1610D von 16B repräsentieren. Die Elemente von 17 mit den gleichen oder ähnlichen Namen wie die Elemente einer beliebigen anderen Figur hierin beschreiben die gleichen Elemente wie in den anderen Figuren, können auf eine ähnliche Weise wie jene arbeiten oder funktionieren, können die gleichen Komponenten umfassen und können mit anderen Entitäten, wie jenen, die an anderer Stelle hierin beschrieben sind, verknüpft sein, sind aber nicht darauf beschränkt. Zum Beispiel sind die 3D-Pipeline 1612 und die Medien-Pipeline 1616 von 16A ebenfalls in 17 veranschaulicht. Die Medien-Pipeline 1616 ist bei manchen Ausführungsformen der GPE 1710 optional und möglicherweise nicht explizit in der GPE 1710enthalten. Zum Beispiel und in mindestens einer Ausführungsform ist ein separater Medien- und/oder Bildprozessor mit der GPE 1710 gekoppelt.
  • Die GPE 1710 kann mit einem Befehls-Streamer 1703 gekoppelt sein oder diesen beinhalten, der der3D-Pipeline 1612 und/oder den Medien-Pipelines 1616 einen Befehlsstrombereitstellt. Alternativ oder zusätzlich kann der Befehls-Streamer 1703 direkt mit einem vereinheitlichten Rückgabepuffer 1718 gekoppelt sein. Der vereinheitlichte Rückgabepuffer 1718 kann kommunikativ mit einem Grafikkernarray 1714gekoppelt sein. Optional ist der Befehls-Streamer 1703 mit einem Speicher, der ein Systemspeicher sein kann, oder einem internen Cache-Speicher und/oder einem gemeinsam genutzten Cache-Speicher gekoppelt. Der Befehls-Streamer 1703 kann Befehle vom Speicher empfangen und sendet die Befehle an die 3D-Pipeline 1612 und/oder die Medien-Pipeline 1616. Die Befehle sind Direktiven, die aus einem Ringpuffer abgerufen werden, der Befehle für die 3D-Pipeline 1612 und die Medien-Pipeline 1616 speichert. Der Ringpuffer kann zusätzlich Stapelbefehlspuffer beinhalten, die Stapel mehrerer Befehle speichern. Die Befehle für die 3D-Pipeline 1612 können auch Verweise auf im Speicher gespeicherte Daten beinhalten, wie, jedoch ohne Einschränkung, Vertex- und Geometriedaten für die 3D-Pipeline 1612 und/oder Bilddaten und Speicherobjekte für die Medien-Pipeline 1616. Die 3D-Pipeline 1612 und die Medien-Pipeline 1616 verarbeiten die Befehle und Daten, indem sie Operationen über eine Logik innerhalb der jeweiligen Pipelines durchführen oder indem sie einen oder mehrere Ausführungs-Threads an das Grafikkernarray 1714versenden. Das Grafikkernarray 1714 kann einen oder mehrere Blöcke von Grafikkernen (z. B. Grafikkern(e) 1715A, Grafikkern(e) 1715B) beinhalten, wobei jeder Block einen oder mehrere Grafikkerne beinhaltet. Jeder Grafikkern beinhaltet einen Satz von Grafikausführungsressourcen, der Universal- und grafikspezifische Ausführungslogik zum Durchführen von Grafik- und Rechenoperationen sowie Texturverarbeitung mit fester Funktion und/oder Maschinenlernen und Beschleunigungslogik mit künstlicher Intelligenz beinhaltet.
  • In verschiedenen Ausführungsformen kann die 3D-Pipeline 1612 Festfunktions- und programmierbare Logik beinhalten, um ein oder mehrere Shader-Programme, wie Vertex-Shader, Geometrie-Shader, Pixel-Shader, Fragment-Shader, Rechen-Shader oder andere Shader-Programme, durch Verarbeiten der Anweisungen und Senden von Ausführungs-Threads an das Grafikkernarray 1714 zu verarbeiten. Das Grafikkernarray 1714 stellt einen vereinheitlichten Block von Ausführungsressourcen zur Verwendung bei der Verarbeitung dieser Shader-Programme bereit. Eine Universalausführungslogik (z. B. Ausführungseinheiten) innerhalb des /der Grafikkern(e) 1715A-1715B des Grafikkernarrays 1714 unterstützt verschiedene 3D-API-Shader-Sprachen und kann mehrere gleichzeitige Ausführungs-Threads ausführen, die mehreren Shadern zugeordnet sind.
  • Das Grafikkernarray 1714 kann Ausführungslogik zum Durchführen von Medienfunktionen wie Video- und/oder Bildverarbeitung beinhalten. Die Ausführungseinheiten können zusätzlich Universallogik beinhalten, die dazu programmierbar ist, parallele Universalrechenoperationen zusätzlich zu Grafikverarbeitungsoperationen durchzuführen. Die Universallogik kann Verarbeitungsoperationen parallel oder in Verbindung mit Universallogik innerhalb des/der Prozessorkern(e) 1407 von 14 oder des Kerns 1502A-1502N wie in 15A durchführen.
  • Ausgabedaten, die durch Threads erzeugt werden, die auf dem Grafikkernarray 1714 ausgeführt werden, können Daten an einen Speicher in einem vereinheitlichten Rückgabepuffer (URB: Unified Return Buffer) 1718ausgeben. Der URB 1718 kann Daten für mehrere Threads speichern. Der URB 1718 kann verwendet werden, um Daten zwischen verschiedenen Threads zu senden, die auf dem Grafikkernarray 1714 ausgeführt werden. Der URB 1718 kann zusätzlich zur Synchronisation zwischen Threads auf dem Grafikkernarray 1714 und Festfunktionslogik innerhalb der Logik 1720 mit gemeinsam genutzter Funktion verwendet werden.
  • Optional kann das Grafikkernarray 1714 skalierbar sein, sodass das Array eine variable Anzahl von Grafikkernen mit jeweils einer variablen Anzahl an Ausführungseinheiten, die auf der Zielleistung und dem Leistungsfähigkeitspegel der GPE 1710basiert, beinhaltet. Die Ausführungsressourcen können dynamisch skalierbar sein, sodass Ausführungsressourcen je nach Bedarf aktiviert oder deaktiviert werden können.
  • Das Grafikkernarray 1714 ist mit Logik 1720 mit gemeinsam genutzter Funktion gekoppelt, die mehrere Ressourcen beinhaltet, die zwischen den Grafikkernen in dem Grafikkernarray gemeinsam genutzt werden. Die gemeinsam genutzten Funktionen innerhalb der Logik 1720 mit gemeinsam genutzter Funktion sind Hardware-Logikeinheiten, die dem Grafikkernarray 1714 eine spezialisierte Zusatzfunktionalität bereitstellen. In verschiedenen Ausführungsformen weist die Logik 1720 mit gemeinsam genutzter Funktion, ohne darauf beschränkt zu sein, eine Sampler- 1721, eine Mathe-1722und eine Inter-Thread-Kommunikations-(ITC: Inter-Thread Communication)-Logik 1723 auf. Zusätzlich können ein oder mehrere Cache(s) 1725 innerhalb der Logik 1720 mit gemeinsam genutzter Funktion implementiert sein.
  • Eine gemeinsam genutzte Funktion wird zumindest in dem Fall implementiert, in dem die Nachfrage nach einer gegebenen spezialisierten Funktion nicht ausreicht, um sie in das Grafikkernarray 1714 aufzunehmen. Stattdessen wird eine einzelne Instanziierung dieser spezialisierten Funktion als eine eigenständige Entität in der Logik 1720 mit gemeinsam genutzter Funktion implementiert und von den Ausführungsressourcen innerhalb des Grafikkernarrays 1714 gemeinsam genutzt. Der genaue Satz von Funktionen, die von dem Grafikkernarray 1714 gemeinsam genutzt werden und in dem Grafikkernarray 1714 enthalten sind, variiert zwischen den Ausführungsformen. Spezielle gemeinsam genutzte Funktionen innerhalb der Logik 1720 mit gemeinsam genutzter Funktion, die umfangreich von dem Grafikkernarray 1714 verwendet werden, können in der Logik 1716 mit gemeinsam genutzter Funktion innerhalb des Grafikkernarrays 1714enthalten sein. Optional kann die Logik 1716 mit gemeinsam genutzter Funktion innerhalb des Grafikkernarrays 1714 einen Teil der oder die gesamte Logik innerhalb der Logik 1720 mit gemeinsam genutzter Funktion beinhalten. Alle Logikelemente innerhalb der Logik 1720 mit gemeinsam genutzter Funktion können innerhalb der Logik 1716 mit gemeinsam genutzter Funktion des Grafikkernarrays 1714 dupliziert werden. Alternativ wird die Logik 1720 mit gemeinsam genutzter Funktion zugunsten der Logik 1716 mit gemeinsam genutzter Funktion innerhalb des Grafikkernarrays 1714 ausgeschlossen.
  • Ausführungseinheiten
  • 18A-18B veranschaulichen eine Thread-Ausführungslogik 1800 einschließlich eines Arrays von Verarbeitungselementen, die in einem Grafikprozessorkern eingesetzt werden, gemäß hierin beschriebenen Ausführungsformen. Die Elemente von 18A-18B mit den gleichen oder ähnlichen Namen wie die Elemente einer beliebigen anderen Figur hierin beschreiben die gleichen Elemente wie in den anderen Figuren, können auf eine ähnliche Weise wie jene arbeiten oder funktionieren, können die gleichen Komponenten umfassen und können mit anderen Entitäten, wie jenen, die an anderer Stelle hierin beschrieben sind, verknüpft sein, sind aber nicht darauf beschränkt. 18A-18B veranschaulicht eine Übersicht über die Thread-Ausführungslogik 1800, die eine Hardwarelogik repräsentieren kann, die mit jedem Unterkern 1521A-1521F von 15B veranschaulicht ist. 18A repräsentiert eine Ausführungseinheit innerhalb eines Universalgrafikprozessors, während 18B eine Ausführungseinheit repräsentiert, die innerhalb eines Rechenbeschleunigers verwendet werden kann.
  • Wie in 18A veranschaulicht, kann die Thread-Ausführungslogik 1800 einen Shader-Prozessor 1802, einen Thread-Dispatcher 1804, einen Anweisungscache 1806, ein skalierbares Ausführungseinheitenarray einschließlich mehrerer Grafikausführungseinheiten 1808A-1808N, einen Sampler 1810, einen gemeinsam genutzten lokalen Speicher 1811, einen Datencache 1812und einen Datenport 1814beinhalten. Optional kann das skalierbare Ausführungseinheitenarray dynamisch skalieren, indem eine oder mehrere Ausführungseinheiten (z. B. eine beliebige der Grafikausführungseinheiten 1808A, 1808B, 1808C, 1808Dbis 1808N-1 und 1808N) basierend auf den Rechenanforderungen einer Arbeitslast aktiviert oder deaktiviert werden. Die enthaltenen Komponenten können über eine Interconnect-Fabric, die mit jeder der Komponenten verknüpft ist, miteinander verbunden sein. Die Thread-Ausführungslogik 1800 kann eine oder mehrere Verbindungen zum Speicher, wie dem Systemspeicher oder Cache-Speicher, über einen oder mehrere von Anweisungscache 1806, Datenport 1814, Sampler 1810und Grafikausführungseinheiten 1808A-1808N beinhalten. Jede Ausführungseinheit (z. B. 1808A) kann eine selbständige programmierbare Universalrecheneinheit sein, die dazu in der Lage ist, mehrere simultane Hardware-Threads auszuführen, während sie mehrere Datenelemente parallel für jeden Thread verarbeitet. In verschiedenen Ausführungsformen ist das Array von Ausführungseinheiten 1808A-1808N skalierbar, um eine beliebige Anzahl einzelner Ausführungseinheiten aufzuweisen.
  • In einigen Ausführungsformen können die Grafikausführungseinheiten 1808A-1808N hauptsächlich zum Ausführen von Shader-Programmen verwendet werden. Ein Shader-Prozessor 1802 kann die verschiedenen Shader-Programme verarbeiten und Ausführungs-Threads versenden, die den Shader-Programmen über einen Thread-Dispatcher 1804 zugeordnet sind. Der Thread-Dispatcher kann Logik zum Arbitrieren von Thread-Initiierungsanfragen von den Grafik- und Medien-Pipelines und Instanziieren der angeforderten Threads auf einer oder mehreren Ausführungseinheiten in den Grafikausführungseinheiten 1808A-1808Nbeinhalten. Eine Geometrie-Pipeline kann zum Beispiel Vertex, Tessellation oder Geometrie-Shader an die Thread-Ausführungslogik zur Verarbeitung versenden. Optional kann der Thread-Dispatcher 1804 auch Laufzeit-Thread-Spawning-Anforderungen von den ausführenden Shader-Programmen verarbeiten.
  • In einigen Ausführungsformen können die Grafikausführungseinheiten 1808A-1808N einen Anweisungssatz unterstützen, der native Unterstützung für viele Standard-3D -Grafik-Shader-Anweisungen beinhaltet, sodass Shader-Programme aus Grafikbibliotheken (z. B. Direct 3D und OpenGL) mit einer minimalen Translation ausgeführt werden. Die Ausführungseinheiten unterstützen Vertex- und Geometrieverarbeitung (z. B. Vertex-Programme, Geometrieprogramme, Vertex-Shader), Pixelverarbeitung (z. B. Pixel-Shader, Fragment-Shader) und Universalverarbeitung (z. B. Rechen- und Medien-Shader). Jede der Grafikausführungseinheiten 1808A-1808N ist zu einer Single Instruction Multiple Data-(SIMD)-Ausführung fähig, und eine Multithread-Operation ermöglicht eine effiziente Ausführungsumgebung angesichts von Speicherzugriffen mit höherer Latenz. Jeder Hardware-Thread innerhalb jeder Ausführungseinheit weist eine dedizierte Registerdatei mit hoher Bandbreite und einen zugehörigen unabhängigen Thread-Zustand auf. Die Ausführung ist eine Mehrfach-Erteilung pro Takt an Pipelines mit Gleitkomma-Operationen mit ganzzahliger, einfacher und doppelter Genauigkeit, SIMD-Verzweigungskapazität, logischen Operationen, transzendenten Operationen und anderen sonstigen Operationen. Während auf Daten aus dem Speicher oder einer der gemeinsam genutzten Funktionen gewartet wird, bewirkt die Abhängigkeitslogik innerhalb der Ausführungseinheiten 1808A-1808N, dass ein wartender Thread in den Ruhezustand geht, bis die angeforderten Daten zurückgegeben wurden. Während der wartende Thread schläft, können Hardware-Ressourcen der Verarbeitung anderer Threads zugeteilt werden. Zum Beispiel 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 eine andere Art von Shader-Programm, einschließlich eines anderen Vertex-Shaders, wie des Vertex-Shaders 2107 durchführen, der in 21 veranschaulicht ist. Verschiedene Ausführungsformen können für die Verwendung einer Ausführung unter Verwendung von Single Instruction Multiple Thread (SIMT) als Alternative zur Verwendung von SIMD oder zusätzlich zur Verwendung von SIMD gelten. Eine Bezugnahme auf einen SIMD-Kern oder eine SIMD-Operation kann auch für SIMT gelten oder für SIMD in Kombination mit SIMT gelten.
  • Jede Ausführungseinheit in den Grafikausführungseinheiten 1808A-1808N arbeitet auf Arrays von Datenelementen. Die Anzahl von Datenelementen ist die „Ausführungsgröße“ oder die Anzahl von Kanälen für die Anweisung. Ein Ausführungskanal ist eine logische Ausführungseinheit für Datenelementzugriff, Maskierung und Ablaufsteuerung innerhalb von Anweisungen. Die Anzahl der Kanäle kann unabhängig von der Anzahl der physischen arithmetischen Logikeinheiten (ALUs), Gleitkommaeinheiten (FPUs) oder anderen Logikeinheiten (z. B. Tensorkerne, Strahlverfolgungskerne usw.) für einen bestimmten Grafikprozessor sein. Zusätzlich dazu können die Grafikausführungseinheiten 1808A-1808N Ganzzahl- und Gleitkomma-Datentypen unterstützen.
  • Der Ausführungseinheitsanweisungssatz beinhaltet SIMD-Anweisungen. Die verschiedenen Datenelemente können als ein gepackter Datentyp in einem Register gespeichert werden und die Ausführungseinheit kann die verschiedenen Elemente basierend auf der Datengröße der Elemente verarbeiten. Wenn zum Beispiel an einem 25 6-Bit-breiten Vektor gearbeitet wird, werden die 256 Bits des Vektors in einem Register gespeichert und die Ausführungseinheit arbeitet an dem Vektor als vier separate gepackte 64-Bit -Datenelemente (Datenelemente mit Quad-Word-(QW)-Größe), acht separate gepackte 32-Bit -Datenelemente (Datenelemente mit Double-Word-(DW)-Größe), sechzehn separate gepackte 16-Bit -Datenelemente (Datenelemente mit Word-(W)-Größe) oder zweiunddreißig separate 8-Datenelemente (Datenelemente mit Byte-(B)-Größe). Es sind jedoch unterschiedliche Vektorbreiten und Registergrößen möglich.
  • Optional können eine oder mehrere Ausführungseinheiten zu einer vereinigten Grafikausführungseinheit 1809A-1809N mit einer Thread-Steuerlogik (1807A-1807N) kombiniert werden, die den vereinigten EUs gemein ist. Mehrere EUs können zu einer EU-Gruppe fusioniert werden. Jede EU in der fusionierten EU-Gruppe kann derart konfiguriert sein, dass sie einen separaten SIMD-Hardware-Thread ausführt. Die Anzahl der EUs in einer fusionierten EU-Gruppe kann je nach Ausführungsformen variieren. Außerdem können verschiedene SIMD-Breiten pro EU durchgeführt werden, einschließlich, jedoch nicht beschränkt auf, SIMD8, SIMD16 und SIMD32. Jede vereinigte Grafikausführungseinheit 1809A-1809N weist mindestens zwei Ausführungseinheiten auf. Zum Beispiel beinhaltet die fusionierte Ausführungseinheit 1809A eine erste EU 1808A, eine zweite EU 1808Bund eine Thread-Steuerlogik 1807A , die der ersten EU 1808A und der zweiten EU 1808B gemein ist. Die Thread-Steuerlogik 1807A steuert Threads, die auf der vereinigten Grafikausführungseinheit 1809A ausgeführt werden, wodurch jeder EU innerhalb der vereinigten Ausführungseinheiten 1809A-1809N ermöglicht wird, unter Verwendung eines gemeinsamen Anweisungszeigerregisters ausgeführt zu werden.
  • Ein oder mehrere interne Anweisungscaches (z. B. 1806) sind in der Thread-Ausführungslogik 1800 enthalten, um Thread-Anweisungen für die Ausführungseinheiten zwischenzuspeichern. Ein oder mehrere Daten-Caches (z. B. 1812) können in der Thread-Ausführungslogik 1800 enthalten sein, um Thread-Daten während der Thread-Ausführung zwischenzuspeichern. Threads, die auf der Ausführungslogik 1800 ausgeführt werden, können auch explizit verwaltete Daten in dem gemeinsam genutzten lokalen Speicher 1811 speichern. Ein Sampler 1810 kann enthalten sein, um ein Textur-Sampling für 3D-Operationen und ein Medien-Sampling für Medienoperationen bereitzustellen. Der Sampler 1810 kann spezialisierte Textur- oder Medienabtastfunktionalität beinhalten, um Textur- oder Mediendaten während des Abtastprozesses zu verarbeiten, bevor die abgetasteten Daten einer Ausführungseinheit bereitgestellt werden.
  • Während der Ausführung senden die Grafik- und Medien-Pipelines Thread-Initiierungsanforderungen an die Thread-Ausführungslogik 1800 über die Thread-Spawning- und Dispatch-Logik. Sobald eine Gruppe geometrischer Objekte verarbeitet und zu Pixeldaten rasterisiert wurde, wird eine Pixelprozessorlogik (z. B. Pixel-Shader-Logik, Fragment-Shader-Logik usw.) innerhalb des Shader-Prozessors 1802 aufgerufen, um Ausgabeinformationen weiter zu berechnen und zu veranlassen, dass Ergebnisse auf Ausgabeoberflächen (z. B. Farbpuffer, Tiefenpuffer, Schablonenpuffer usw.) geschrieben werden. Ein Pixel-Shader oder Fragment-Shader kann die Werte der verschiedenen Vertex-Attribute berechnen, die über das rasterisierte Objekt hinweg interpoliert werden sollen. Die Pixelprozessorlogik innerhalb des Shader-Prozessors 1802 kann dann ein von einer Anwendungsprogrammierschnittstelle (API) geliefertes Pixel- oder Fragment-Shader-Programm ausführen. Um das Shader-Programm auszuführen, versendet der Shader-Prozessor 1802 Threads über den Thread-Dispatcher 1804 an eine Ausführungseinheit (z. B. 1808A). Der Shader-Prozessor 1802 kann eine Textur-Sampling-Logik im Sampler 1810 verwenden, um auf Texturdaten in im Speicher gespeicherten Texturabbildungen zuzugreifen. Arithmetische Operationen an den Texturdaten und den Eingabegeometriedaten berechnen Pixelfarbdaten für jedes geometrische Fragment oder verwerfen ein oder mehrere Pixel von der weiteren Verarbeitung.
  • Außerdem kann der Datenport 1814 einen Speicherzugriffsmechanismus für die Thread-Ausführungslogik 1800 bereitstellen, um verarbeitete Daten an den Speicher zur weiteren Verarbeitung auf einer Grafikprozessorausgabe-Pipeline auszugeben. Der Datenport 1814 kann einen oder mehrere Cache-Speicher (z. B. Datencache 1812) zum Zwischenspeichern von Daten für einen Speicherzugriff über den Datenport 1814 beinhalten oder mit diesen gekoppelt sein.
  • Optional kann die Ausführungslogik 1800 auch einen Strahlverfolger 1805 beinhalten, der eine Strahlverfolgungs-Beschleunigungsfunktionalität bereitstellen kann. Der Strahlverfolger 1805 kann einen Strahlverfolgungs-Anweisungssatz unterstützen, der Anweisungen/Funktionen für die Strahlerzeugung beinhaltet. Der Strahlverfolgungs-Anweisungssatz kann dem Strahlverfolgungs-Anweisungssatz, der von den Strahlverfolgungskernen 372 in 3C unterstützt wird, ähnlich oder von diesem verschieden sein.
  • 18B veranschaulicht beispielhafte interne Details einer Ausführungseinheit 1808. Eine Grafikausführungseinheit 1808 kann eine Anweisungsabrufeinheit 1837, ein Allgemeinregisterbank(GRF)-Array 1824, ein Architekturregisterbank-Array (ARF) 1826, einen Thread-Arbiter 1822, eine Sendeeinheit 1830, eine Verzweigungseinheit 1832, einen Satz von SIMD-Gleitkommaeinheiten (FPUs) 1834und optional einen Satz von dedizierten ganzzahligen SIMD-ALUs 1835 beinhalten. Die GRF 1824 und die ARF 1826 beinhalten den Satz von Allgemeinregisterdateien und Architekturregisterdateien, die jedem simultanen Hardware-Thread zugeordnet sind, der in der Grafikausführungseinheit 1808 aktiv sein kann. Der Architekturzustand pro Thread kann in der ARF 1826 beibehalten werden, während Daten, die während der Thread-Ausführung verwendet werden, in der GRF 1824 gespeichert werden. Der Ausführungszustand jedes Threads, einschließlich der Anweisungszeiger für jeden Thread, kann in Thread-spezifischen Registern in der ARF 1826gehalten werden.
  • Die Grafikausführungseinheit 1808 kann eine Architektur aufweisen, die eine Kombination aus Simultaneous Multi-Threading (SMT) und feinkörnigem Interleaved Multi-Threading (IMT) ist. Die Architektur kann eine modulare Konfiguration aufweisen, die zur Gestaltungszeit basierend auf einer Zielanzahl von gleichzeitigen Threads und einer Anzahl von Registern pro Ausführungseinheit fein abgestimmt werden kann, wobei Ressourcen der Ausführungseinheit über die Logik aufgeteilt werden, die zum Ausführen mehrerer gleichzeitiger Threads verwendet wird. Die Anzahl von logischen Threads, die durch die Grafikausführungseinheit 1808 ausgeführt werden können, ist nicht auf die Anzahl von Hardware-Threads beschränkt, und jedem Hardware-Thread können mehrere logische Threads zugewiesen werden.
  • Optional kann die Grafikausführungseinheit 1808 mehrere Anweisungen gemeinsam ausgeben, die jeweils unterschiedliche Anweisungen sein können. Der Thread-Arbiter 1822 der Grafikausführungseinheit 1808 kann die Anweisungen an entweder die Sendeeinheit 1830, die Verzweigungseinheit 1832oder die SIMD-FPU(s) 1834 zur Ausführung versenden. Jeder Ausführungs-Thread kann auf 128 Universalregister innerhalb des GRF 1824zugreifen, wobei jedes Register 32 Byte speichern kann, die als ein SIMD-8-Element-Vektor von 32-Bit-Datenelementen zugänglich sind. Jeder Ausführungseinheit-Thread kann Zugriff auf 4 Kbyte innerhalb der GRF 1824haben, obwohl Ausführungsformen nicht darauf beschränkt sind und größere oder weniger Registerressourcen in anderen Ausführungsformen bereitgestellt werden können. Die Grafikausführungseinheit 1808 kann in sieben Hardware-Threads partitioniert sein, die unabhängig Rechenoperationen ausführen können, obwohl die Anzahl von Threads pro Ausführungseinheit auch gemäß Ausführungsformen variieren kann, zum Beispiel können bis zu 16 Hardware-Threads unterstützt werden. In einer beispielhaften Ausführungsform, in der sieben Threads auf 4 Kbyte zugreifen können, kann die GRF 1824 insgesamt 28 Kbyte speichern. Bei einem anderen Ausführungsbeispiel, bei dem 16 Threads auf 4Kbyteszugreifen können, kann das GRF 1824 insgesamt 64Kbytes speichern. Die Anzahl von Threads pro Ausführungseinheit ist jedoch nicht auf diese Beispiele beschränkt und kann größer oder kleiner als die angegebenen Zahlen sein. Flexible Adressierungsmodi können ermöglichen, dass Register zusammen adressiert werden, um effektiv breitere Register zu bilden oder um streifenförmige rechteckige Blockdatenstrukturen zu repräsentieren.
  • Zusätzlich oder alternativ dazu können Speicheroperationen, Sampler-Operationen und andere Systemkommunikationen mit längerer Latenz über „Sende“-Anweisungen versendet werden, die durch die Nachrichtenweiterleitungssendeeinheit 1830ausgeführt werden. Verzweigungsanweisungen können an eine dedizierte Verzweigungseinheit 1832 versendet werden, um eine SIMD-Divergenz und letztliche Konvergenz zu ermöglichen.
  • Die Grafikausführungseinheit 1808 kann eine oder mehrere SIMD-Gleitkommaeinheiten (FPU(s)) 1834 zum Durchführen von Gleitkommaoperationen beinhalten. Die FPU(s) 1834 können auch Ganzzahlberechnungen unterstützen. In einigen Fällen können die FPU(s) 1834 SIMD bis zu einer Anzahl vonM 32-Bit-Gleitkomma- (oder Ganzzahl-) Operationen ausführen oder SIMD bis zu 2M 16-Bit-Ganzzahl- oder 16-Bit-Gleitkommaoperationen ausführen. Optional stellt mindestens eine der FPUs erweiterte mathematische Fähigkeiten bereit, um transzendentale mathematische Funktionen mit hohem Durchsatz und 64-Bit--Gleitkommazahl mit doppelter Präzision zu unterstützen. Ein Satz von 8-Bit-Ganzzahl-SIMD-ALUs 1835 kann auch vorhanden sein und kann speziell optimiert werden, um Operationen durchzuführen, die Maschinenlernberechnungen zugeordnet sind.
  • Optional können Arrays von mehreren Instanzen der Grafikausführungseinheit 1808 in einer Grafikunterkerngruppierung (z. B. einem Sub-Slice) instanziiert werden. Für die Skalierbarkeit können Produktarchitekten die exakte Anzahl an Ausführungseinheiten pro Unterkerngruppierung auswählen. Die Ausführungseinheit 1808 kann Anweisungen über mehrere Ausführungskanäle ausführen. Außerdem kann jeder Thread, der auf der Grafikausführungseinheit 1808 ausgeführt wird, auf einem anderen Kanal ausgeführt werden.
  • 19 veranschaulicht eine weitere beispielhafte Ausführungseinheit 1900. Die Elemente von 19 mit den gleichen oder ähnlichen Namen wie die Elemente einer beliebigen anderen Figur hierin beschreiben die gleichen Elemente wie in den anderen Figuren, können auf eine ähnliche Weise wie jene arbeiten oder funktionieren, können die gleichen Komponenten umfassen und können mit anderen Entitäten, wie jenen, die an anderer Stelle hierin beschrieben sind, verknüpft sein, sind aber nicht darauf beschränkt. Die Ausführungseinheit 1900 kann eine rechenoptimierte Ausführungseinheit zur Verwendung beispielsweise in einer Rechen--Engine-Kachel 1640A-1640D wie in 16C gezeigt sein, ist aber nicht darauf beschränkt. Die Ausführungseinheit 1900 kann auch in einer Grafik-Engine-Kachel 1610A-1610D wie in 16B verwendet werden. Die Ausführungseinheit 1900 kann eine Thread-Steuereinheit 1901, eine Thread-Zustandseinheit 1902, eine Anweisungsabruf-/- vorabrufeinheit 1903 und eine Anweisungsdecodiereinheit 1904beinhalten. Die Ausführungseinheit 1900 kann zusätzlich eine Registerdatei 1906 beinhalten, die Register speichert, die Hardware-Threads innerhalb der Ausführungseinheit zugewiesen werden können. Die Ausführungseinheit 1900 kann zusätzlich eine Sendeeinheit 1907 und eine Verzweigungseinheit 1908 beinhalten. Die Sendeeinheit 1907 und die Verzweigungseinheit 1908 können ähnlich wie die Sendeeinheit 1830 und eine Verzweigungseinheit 1832 der Grafikausführungseinheit 1808 von 18B arbeiten.
  • Die Ausführungseinheit 1900 kann auch eine Recheneinheit 1910 beinhalten, die mehrere unterschiedliche Typen von Funktionseinheiten beinhaltet. Die Recheneinheit 1910 kann auch eine Alu 1911, ein systolisches Array 1912und eine Math-Einheit 1913 beinhalten. Die ALU 1911 beinhaltet ein Array von arithmetischen Logikeinheiten. Die ALU 1911 kann dazu konfiguriert sein, 64-Bit-, 32-Bit- und 16-Bit-Ganzzahl- und Gleitkommaoperationen über mehrere Verarbeitungsspuren und Datenkanäle und für mehrere Hardware- und/oder Software-Threads durchzuführen. Die ALU 1911 kann Ganzzahl- und Gleitkommaoperationen gleichzeitig durchführen (z. B. innerhalb desselben Taktzyklus).
  • Das systolische Array 1912 beinhaltet ein W breites und D tiefes Netzwerk von Datenverarbeitungseinheiten, die verwendet werden können, um Vektor- oder andere datenparallele Operationen auf eine systolische Weise durchzuführen. Das systolische Array 1912 kann dazu konfiguriert sein, verschiedene Matrixoperationen durchzuführen, einschließlich als Skalarprodukt-, Außenprodukt- und allgemeine Matrix-Matrix-Multiplikations-(GEMM)-Operationen. Das systolische Array 1912 kann 16-Bit - Gleitkommaoperationen sowie 8-Bit-, 4-Bit-, 2-Bit- und binäre Ganzzahloperationen unterstützen. Das systolische Array 1912 kann dazu konfiguriert sein, Maschinenlernoperationen zu beschleunigen. Das systolische Array 1912 kann mit Unterstützung für ein bfloat16-(Brain Floating Point)-16-Bit-Gleitkommaformat oder ein Tensor-Float-32-Bit-Gleitkommaformat 32 (TF32) konfiguriert sein, das unterschiedliche Anzahlen von Mantissen- und Exponentenbits relativ zu den Formaten des Institute of Electrical and Electronics Engineers (IEEE) 754 aufweist. FP64-Formate können ebenfalls unterstützt werden.
  • In einer Ausführungsform beinhaltet das systolische Array 1912 Hardware zum Beschleunigen von Dünnbesetzte-Matrix-Operationen. Multiplikationsoperationen für dünn besetzte Gebiete von Eingabedaten können übersprungen werden, ohne den Durchsatz zu opfern. Eine Block-Dünnbesetztheit innerhalb von Eingabematrizen kann detektiert werden und Operationen mit bekannten Ausgabewerten können übersprungen werden. In einer Ausführungsform beinhaltet das systolische Array 1912 Hardware, um Operationen an dünn besetzten Daten mit einer komprimierten Repräsentation zu ermöglichen. Eine komprimierte Repräsentation einer dünn besetzten Matrix speichert Werte ungleich null und Metadaten, die die Position der Werte ungleich null innerhalb der Matrix definieren. Beispielhafte komprimierte Repräsentationen beinhalten, jedoch ohne Einschränkung, komprimierte Tensordarstellungen, wie Repräsentationen für komprimierte dünn besetzte Zeile (CSR), komprimierte dünn besetzte Spalte (CSC), komprimierte dünn besetzte Faser (CSF). Die Unterstützung komprimierter Repräsentationen ermöglicht es, Operationen an einer Eingabe in einem komprimierten Tensorformat durchzuführen, ohne dass die komprimierte Darstellung dekomprimiert oder decodiert werden muss. In einer solchen Ausführungsform können Operationen nur an Eingabewerten ungleich null durchgeführt werden und die resultierenden Ausgabewerte ungleich null können in eine Ausgangsmatrix abgebildet werden. In manchen Ausführungsformen wird eine Hardwareunterstützung auch für maschinenspezifische verlustfreie Datenkomprimierungsformate bereitgestellt, die verwendet werden, wenn Daten innerhalb von Hardware oder über Systembusse hinweg übertragen werden. Derartige Daten können in einem komprimierten Format für dünn besetzte Eingabedaten beibehalten werden, und das systolische Array 1912 kann die Komprimierungsmetadaten für die komprimierten Daten verwenden, um zu ermöglichen, dass Operationen nur an Werten ungleich null durchgeführt werden, oder um zu ermöglichen, dass Blöcke einer Nulldateneingabe für Multiplikationsoperationen übersprungen werden.
  • Die Mathe-Einheit 1913 kann dazu konfiguriert sein, eine spezifische Teilmenge mathematischer Operationen auf effiziente Weise und mit geringerer Leistung als die ALU-Einheit 1911 durchzuführen. Die Mathe-Einheit 1913 kann eine Mathe-Logik beinhalten, die in einer Logik mit gemeinsam genutzter Funktion einer Grafikverarbeitungs-Engine zu finden ist, die von anderen beschriebenen Ausführungsformen bereitgestellt wird, z. B. die Mathe-Logik 1722 der Logik 1720 mit gemeinsam genutzter Funktion von 17. Die Mathe-Einheit 1913 kann dazu konfiguriert sein, 32-Bit- und 64-Bit-Gleitkommaoperationen durchzuführen.
  • Die Thread-Steuereinheit 1901 beinhaltet Logik zum Steuern der Ausführung von Threads innerhalb der Ausführungseinheit. Die Thread-Steuereinheit 1901 kann Thread-Arbitrierungslogik beinhalten, um die Ausführung von Threads innerhalb der Ausführungseinheit 1900 zu starten, zu stoppen und zu präemptieren. Die Thread-Zustandseinheit 1902 kann verwendet werden, um den Thread-Zustand für Threads zu speichern, die zur Ausführung auf der Ausführungseinheit 1900zugewiesen sind. Das Speichern des Thread-Zustands in der Ausführungseinheit 1900 ermöglicht die schnelle Präemption von Threads, wenn diese Threads blockiert oder inaktiv werden. Die Anweisungsabruf-/-vorabrufeinheit 1903 kann Anweisungen aus einem Anweisungscache einer Ausführungslogik höherer Ebene (z. B. Anweisungscache 1806 wie in 18A) abrufen. Die Anweisungsabruf-/-vorabrufeinheit 1903 kann auch Vorabrufanforderungen für in den Anweisungscache zu ladende Anweisungen basierend auf einer Analyse aktuell ausgeführter Threads ausgeben. Die Anweisungsdecodiereinheit 1904 kann verwendet werden, um von den Recheneinheiten auszuführende Anweisungen zu decodieren. Die Anweisungsdecodiereinheit 1904 kann als ein sekundärer Decodierer verwendet werden, um komplexe Anweisungen in konstituierende Mikrooperationen zu decodieren.
  • Die Ausführungseinheit 1900 beinhaltet zusätzlich eine Registerdatei 1906 , die durch Hardware-Threads verwendet werden kann, die auf der Ausführungseinheit 1900 ausgeführt werden. Register in der Registerdatei 1906 können über die Logik aufgeteilt werden, die verwendet wird, um mehrere simultane Threads innerhalb der Recheneinheit 1910 der Ausführungseinheit 1900 auszuführen. Die Anzahl von logischen Threads, die durch die Grafikausführungseinheit 1900is ausgeführt werden können, ist nicht auf die Anzahl von Hardware-Threads beschränkt, und jedem Hardware-Thread können mehrere logische Threads zugewiesen werden. Die Größe der Registerdatei 1906 kann zwischen Ausführungsformen basierend auf der Anzahl unterstützter Hardware-Threads variieren. Eine Registerumbenennung kann verwendet werden, um Register dynamisch Hardware-Threads zuzuordnen.
  • 20 ist ein Blockdiagramm, das die Grafikprozessoranweisungsformate 2000 veranschaulicht. Die Grafikprozessorausführungseinheiten unterstützen einen Anweisungssatz mit Anweisungen in mehreren Formaten. Die Kästchen mit durchgezogenen Linien veranschaulichen die Komponenten, die allgemein in einer Ausführungseinheitsanweisung enthalten sind, während die gestrichelten Linien Komponenten enthalten, die optional sind oder die nur in einer Teilmenge der Anweisungen enthalten sind. In einigen Ausführungsformen sind die beschriebenen und veranschaulichten Grafikprozessoranweisungsformate 2000 Makroanweisungen, da sie Anweisungen sind, die der Ausführungseinheit zugeführt werden, im Gegensatz zu Mikrooperationen, die sich aus der Anweisungsdecodierung ergeben, sobald die Anweisung verarbeitet ist. Somit kann eine einzige Anweisung veranlassen, dass Hardware mehrere Mikrooperationen durchführt.
  • Die hierin beschriebenen Grafikprozessorausführungseinheiten können Anweisungen in einem 128-Bit-Anweisungsformat 2010 nativ unterstützen. Ein kompaktiertes 64-Bit -Anweisungsformat 2030 steht für manche Anweisungen basierend auf der ausgewählten Anweisung, den Anweisungsoptionen und der Anzahl von Operanden zur Verfügung. Das native 128-Bit-Anweisungsformat 2010 stellt Zugriff auf alle Anweisungsoptionen bereit, während manche Optionen und Operationen in dem 64-Bit-Format 2030 beschränkt sind. Die nativen Anweisungen, die im 64-Bit-Format 2030 verfügbarsind, variieren je nach Ausführungsform. Die Anweisung wird teilweise unter Verwendung eines Satzes von Indexwerten in einem Indexfeld 2013 kompaktiert. Die Hardware der Ausführungseinheit referenziert einen Satz von Kompaktierungstabellen basierend auf den Indexwerten und verwendet die Kompaktierungstabellenausgaben, um eine native Anweisung im 128-Bit-Anweisungsformat 2010 zu rekonstruieren. Andere Anweisungsgrößen und Anweisungsformate können verwendet werden.
  • Für jedes Format definiert der Anweisungs-Opcode 2012 die Operation, die die Ausführungseinheit durchführen soll. Die Ausführungseinheiten führen jede Anweisung parallel über die mehreren Datenelemente jedes Operanden aus. Zum Beispiel führt die Ausführungseinheit als Reaktion auf einen Addierbefehl eine gleichzeitige Addieroperation über jeden Farbkanal durch, der ein Texturelement oder Bildelement repräsentiert. Standardmäßig führt die Ausführungseinheit jeden Befehl über alle Datenkanäle der Operanden durch. Das Anweisungssteuerfeld 2014 kann die Steuerung bestimmter Ausführungsoptionen ermöglichen, wie die Kanalauswahl (z. B. Prädikation) und Datenkanalreihenfolge (z. B. Swizzle). Für Anweisungen im 128-Bit-Anweisungsformat 2010 begrenzt ein Ausführungsgrößenfeld 2016 die Anzahl von Datenkanälen, die parallel ausgeführt werden können. Ein Ausführungsgrößenfeld 2016 ist möglicherweise nicht zur Verwendung in dem kompakten 64-Bit-Anweisungsformat 2030 verfügbar.
  • Einige Ausführungseinheitsanweisungen haben bis zu drei Operanden einschließlich zwei Quelloperanden, src0 2020, src1 2022, und einen Zieloperanden (Ziel 2018). Andere Anweisungen, wie beispielsweise Datenmanipulationsanweisungen, Skalarproduktanweisungen, Multiplikations-Additionsbefehle oder Multiplikations-Akkumulationsbefehle können einen dritten Quelloperanden (z. B. SRC2 2024) aufweisen. Der Anweisungs-Opcode 2012 bestimmt die Anzahl von Quelloperanden. Der letzte Quelloperand einer Anweisung kann ein unmittelbarer Wert (z. B. fest codierter Wert) sein, der mit der Anweisung übergeben wird. Die Ausführungseinheiten können auch mehrere Zielanweisungen unterstützen, wobei eines oder mehrere der Ziele basierend auf der Anweisung und/oder dem spezifizierten Ziel impliziert oder implizit sind.
  • Das 128-Bit-Anweisungsformat 2010 kann ein Zugriffs-/Adressmodusfeld 2026 aufweisen, das zum Beispiel spezifiziert, ob ein direkter Registeradressierungsmodus oder ein indirekter Registeradressierungsmodus verwendet wird. Wenn der direkte Registeradressierungsmodus verwendet wird, wird die Registeradresse eines oder mehrerer Operanden direkt durch Bits in der Anweisung bereitgestellt.
  • Das 128-Bit-Anweisungsformat 2010 kann auch ein Zugriffs-/Adressmodusfeld 2026aufweisen, das einen Adressmodus und/oder einen Zugriffsmodus für die Anweisung spezifiziert. Der Zugriffsmodus kann verwendet werden, um eine Datenzugriffsausrichtung für die Anweisung zu definieren. Zugriffsmodi einschließlich eines 16-Byte-ausgerichteten Zugriffsmodus und eines 1-Byte-ausgerichteten Zugriffsmodus können unterstützt werden, wobei die Byteausrichtung des Zugriffsmodus die Zugriffsausrichtung der Anweisungsoperanden bestimmt. Beispielsweise kann die Anweisung, wenn sie sich in einem ersten Modus befindet, eine byteausgerichtete Adressierung für Quell- und Zieloperanden verwenden, und wenn sie sich in einem zweiten Modus befindet, kann die Anweisung eine 16-Byte-ausgerichtete Adressierung für alle Quell- und Zieloperanden verwenden.
  • Der Adressmodusabschnitt des Zugriffs-/Adressmodusfeldes 2026 kann bestimmen, ob die Anweisung direktes oder indirektes Adressieren verwenden soll. Wenn der direkte Registeradressierungsmodus verwendet wird, liefern Bits in der Anweisung direkt die Registeradresse eines oder mehrerer Operanden. Wenn der indirekte Registeradressierungsmodus verwendet wird, kann die Registeradresse eines oder mehrerer Operanden basierend auf einem Adressregisterwert und einem Adress-Immediate-Feld in der Anweisung berechnet werden.
  • Anweisungen können basierend auf Bitfeldern des Opcodes 2012 gruppiert werden, um die Opcode-Decodierung 2040 zu vereinfachen. Für einen 8-Bit-Opcode ermöglichen die Bits 4, 5 und 6 der Ausführungseinheit, den Opcode-Typ zu bestimmen. Die gezeigte genaue Opcode-Gruppierung ist lediglich ein Beispiel. Eine Verschiebungs- und Logik-Opcode-Gruppe 2042 kann Datenverschiebungs- und Logikanweisungen (z. B. move (mov), compare (cmp)) beinhalten. Die Verschiebungs- und Logik-Gruppe 2042 kann die fünf niedrigstwertigen Bits (LSB) gemeinsam nutzen, wobei move-(mov)-Anweisungen die Form 0000xxxxb haben und Logikanweisungen die Form 0001xxxxb haben. Eine Ablaufsteueranweisungsgruppe 2044 (z. B. call, jump (jmp)) beinhaltet Anweisungen in Form von 0010xxxxb (z. B. 0x20). Eine gemischte Anweisungsgruppe 2046 beinhaltet eine Mischung von Anweisungen einschließlich Synchronisationsanweisungen (z. B. wait, send) in der Form von 001 1xxxxb (z. B. 0x30). Eine Parallel-Mathe-Anweisungsgruppe 2048 beinhaltet komponentenweise arithmetische Anweisungen (z. B. add, multiply (mul)) in der Form von 0100xxxxb (z. B. 0x40). Die Parallel-Mathe-Anweisungsgruppe 2048 führt die arithmetischen Operationen parallel über Datenkanäle aus. Die Vektor-Mathe-Gruppe 2050 beinhaltet arithmetische Anweisungen (z. B. dp4) in Form von 0101xxxxb (z. B. 0x50). Die Vektor-Mathe-Gruppe führt Arithmetik wie Skalarproduktberechnungen an Vektoroperanden durch. Die veranschaulichte Opcode-Decodierung 2040kann bei einer Ausführungsform verwendet werden, um zu bestimmen, welcher Abschnitt einer Ausführungseinheit verwendet werden kann, um eine decodierte Anweisung auszuführen. Zum Beispiel können einige Anweisungen als systolische Anweisungen bezeichnet werden, die durch ein systolisches Array durchgeführt werden können. Andere Anweisungen, wie Strahlverfolgungsanweisungen (nicht gezeigt), können zu einem Strahlverfolgungskern oder einer Strahlverfolgungslogik innerhalb eines Slices oder einer Partition der Ausführungslogik geleitet werden.
  • Grafik-Pipeline
  • 21 ist ein Blockdiagramm eines Grafikprozessors 2100 gemäß einer anderen Ausführungsform. Die Elemente von 21 mit den gleichen oder ähnlichen Namen wie die Elemente einer beliebigen anderen Figur hierin beschreiben die gleichen Elemente wie in den anderen Figuren, können auf eine ähnliche Weise wie jene arbeiten oder funktionieren, können die gleichen Komponenten umfassen und können mit anderen Entitäten, wie jenen, die an anderer Stelle hierin beschrieben sind, verknüpft sein, sind aber nicht darauf beschränkt.
  • Der Grafikprozessor 2100 kann verschiedene Arten von Grafikverarbeitungs-Pipelines beinhalten, wie eine Geometrie-Pipeline 2120, eine Medien-Pipeline 2130, eine Anzeige-Engine 2140, eine Thread-Ausführungslogik 2150und eine Rendering-Ausgabe-Pipeline 2170. Der Grafikprozessor 2100 kann ein Grafikprozessor in einem Mehrkernverarbeitungssystem sein, das einen oder mehrere Universalverarbeitungskerne beinhaltet. Der Grafikprozessor kann durch Registerschreibvorgänge in ein oder mehrere Steuerregister (nicht gezeigt) oder über Befehle gesteuert werden, die über ein Ring-Interconnect 2102 an den Grafikprozessor 2100 ausgegeben werden. Das Ring-Interconnect 2102 kann den Grafikprozessor 2100 mit anderen Verarbeitungskomponenten koppeln, wie anderen Grafikprozessoren oder Universalprozessoren. Befehle von dem Ring-Interconnect 2102 werden von einem Befehls-Streamer 2103 interpretiert, der Anweisungen an einzelne Komponenten der Geometrie-Pipeline 2120 oder der Medien-Pipeline 2130 liefert.
  • Der Befehls-Streamer 2103 kann die Operation eines Vertex-Abrufers 2105 leiten, der Vertex-Daten aus einem Speicher liest und Vertex-Verarbeitungsbefehle ausführt, die durch den Befehls-Streamer 2103 bereitgestellt werden. Der Vertex-Abrufer 2105 kann Vertex-Daten an einen Vertex-Shader 2107bereitstellen, der Koordinatenraumtransformationen und Beleuchtungsoperationen für jeden Vertex durchführt. Der Vertex-Abrufer 2105 und der Vertex-Shader 2107 können Vertex-Verarbeitungsanweisungen ausführen, indem sie Ausführungs-Threads über einen Thread-Dispatcher 2131 an die Ausführungseinheiten 2152A-2152B versenden.
  • Die Ausführungseinheiten 2152A-2152B können ein Array von Vektorprozessoren sein, die einen Anweisungssatz zum Durchführen von Grafik- und Medienoperationen aufweisen. Die Ausführungseinheiten 2152A-2152B können einen angehängten L1-Cache 2151 aufweisen, der für jedes Array spezifisch ist oder von den Arrays gemeinsam genutzt wird. Der Cache kann als ein Daten-Cache, ein AnweisungsCache oder ein einzelner Cache konfiguriert sein, der partitioniert ist, um Daten und Anweisungen in verschiedenen Partitionen aufzunehmen.
  • Eine Geometrie-Pipeline 2120 kann Tessellationskomponenten beinhalten, um eine hardwarebeschleunigte Tessellation von 3D-Objekten durchzuführen. Ein programmierbarer Hull-Shader 2111 kann die Tessellationsoperationen konfigurieren. Ein programmierbarer Domänen-Shader 2117 kann eine Backend-Auswertung der Tessellationsausgabe bereitstellen. Ein Tessellator 2113 kann unter Anleitung des Hull-Shaders 2111 arbeiten und eine Speziallogik zum Erzeugen eines Satzes detaillierter geometrischer Objekte basierend auf einem groben geometrischen Modell enthalten, das als Eingabe in die Geometrie-Pipeline 2120 bereitgestellt wird. Falls keine Tessellation verwendet wird, können zusätzlich Tessellationskomponenten (z. B. der Hull-Shader 2111, der Tesselator 2113und der Domänen-Shader 2117) umgangen werden. Die Tessellationskomponenten können basierend auf Daten arbeiten, die von dem Vertex-Shader 2107 empfangen werden.
  • Vollständige geometrische Objekte können durch einen Geometrie-Shader 2119 über einen oder mehrere Threads verarbeitet werden, die an die Ausführungseinheiten 2152A-2152Bversendet werden, oder sie können direkt zu dem Clipper 2129 weitergehen. Der Geometrie-Shader kann an ganzen geometrischen Objekten arbeiten, anstatt an Vertices oder Patches von Vertices wie in vorherigen Stufen der Grafik-Pipeline. Wenn die Tessellation deaktiviert ist, empfängt der Geometrie-Shader 2119 eine Eingabe von dem Vertex-Shader 2107. Der Geometrie-Shader 2119 kann durch ein Geometrie-Shader-Programm programmierbar sein, um eine Geometrie-Tessellation durchzuführen, falls die Tessellationseinheiten deaktiviert sind.
  • Vor der Rasterisierung verarbeitet ein Clipper 2129 Vertex-Daten. Der Clipper 2129 kann ein Festfunktions-Clipper oder ein programmierbarer Clipper mit Clipping- und Geometrie-Shader-Funktionen sein. Eine Rasterisierer- und - Tiefenprüfungskomponente 2173 in der Rendering-Ausgabe-Pipeline 2170 kann Pixel-Shader versenden, um die geometrischen Objekte in Pro-Pixel-Repräsentationen umzuwandeln. Die Pixel-Shader-Logik kann in der Thread-Ausführungslogik 2150enthalten sein. Optional kann eine Anwendung die Rasterisierer- und - Tiefenprüfungskomponente 2173 umgehen und über eine Stream-Out-Einheit 2123 auf nicht rasterisierte Vertex-Datenzugreifen.
  • Der Grafikprozessor 2100 weist einen Interconnect-Bus, eine Interconnect-Fabric oder einen anderen Interconnect-Mechanismus auf, der eine Daten- und Nachrichtenweiterleitung zwischen den Komponenten des Prozessors ermöglicht. In einigen Ausführungsformen sind die Ausführungseinheiten 2152A-2152B und die zugehörigen Logikeinheiten (z. B. L1-Cache 2151, Sampler 2154, Texturcache 2158usw.) über einen Datenport 2156 miteinander verbunden, um einen Speicherzugriff durchzuführen und mit Rendering-Ausgabe-Pipeline-Komponenten des Prozessors zu kommunizieren. Ein Sampler 2154, die Caches 2151, 2158 und die Ausführungseinheiten 2152A-2152B können jeweils separate Speicherzugriffspfade aufweisen. Optional kann der Textur-Cache 2158 auch als ein Sampler-Cache konfiguriert sein.
  • Die Rendering-Ausgabe-Pipeline 2170 kann eine Rasterisierer- und - Tiefenprüfungskomponente 2173 enthalten, die vertex-basierte Objekte in eine zugehörige pixelbasierte Repräsentation umwandelt. Die Rasterisierlogik kann eine Fenster-/Maskiereinheit zum Durchführen einer Dreiecks- und Linienrasterisierung mit fester Funktion beinhalten. Ein zugehöriger Rendering-Cache 2178 und Tiefen-Cache 2179 sind in einigen Ausführungsformen ebenfalls verfügbar. Eine Pixeloperationskomponente 2177 führt pixelbasierte Operationen an den Daten aus, wenngleich in manchen Fällen Pixeloperationen, die 2D-Operationen zugeordnet sind (z. B. Bitblockbildtransfers mit Mischen), von der 2D-Engine 2141 ausgeführt oder zur Anzeigezeit von der Anzeigesteuerung 2143 unter Verwendung von Overlay-Anzeigeebenen ersetzt werden. Ein gemeinsam genutzter L3-Cache 2175 kann für alle Grafikkomponenten verfügbar sein, was die gemeinsame Nutzung von Daten ohne die Verwendung von Hauptsystemspeicher ermöglicht.
  • Die Medien-Pipeline 2130 kann eine Medien-Engine 2137 und ein Video-Frontend 2134beinhalten. Das Video-Frontend 2134 kann Pipeline-Befehle von dem Befehls-Streamer 2103empfangen. Die Medien-Pipeline 2130 kann einen separaten Befehls-Streamer beinhalten. Das Video-Frontend 2134 kann Medienbefehle verarbeiten, bevor der Befehl an die Medien-Engine 2137 gesendet wird. Die Medien-Engine 2137 kann eine Thread-Spawning-Funktionalität beinhalten, um Threads zum Versenden an die Thread-Ausführungslogik 2150 über den Thread-Dispatcher 2131zu spawnen.
  • Der Grafikprozessor 2100 kann eine Anzeige-Engine 2140beinhalten. Diese Anzeige-Engine 2140 kann sich außerhalb des Prozessors 2100 befinden und kann mit dem Grafikprozessor über das Ring-Interconnect 2102oder einen anderen Interconnect-Bus oder eine andere Interconnect-Fabric gekoppelt sein. Die Anzeige-Engine 2140 kann eine 2D-Engine 2141 und eine Anzeigesteuerung 2143 beinhalten. Die Anzeige-Engine 2140 kann eine Speziallogik enthalten, die dazu in der Lage ist, unabhängig von der 3D-Pipeline zu arbeiten. Die Anzeigesteuerung 2143 kann mit einer Anzeigevorrichtung (nicht gezeigt) gekoppelt sein, die eine systemintegrierte Anzeigevorrichtung, wie in einem Laptop-Computer, oder eine externe Anzeigevorrichtung, die über einen Anzeigevorrichtungsverbinder angebracht ist, sein kann.
  • Die Geometrie-Pipeline 2120 und die Medien-Pipeline 2130 können dazu konfigurierbar sein, Operationen basierend auf mehreren Grafik- und Medienprogrammierschnittstellen durchzuführen, und sind für keine Anwendungsprogrammierschnittstelle (API) spezifisch. Eine Treibersoftware für den Grafikprozessor kann API-Aufrufe, die für eine bestimmte Grafik- oder Medienbibliothek spezifisch sind, in Befehle übersetzen, die von dem Grafikprozessor verarbeitet werden können. Eine Unterstützung kann für Open Graphics Library (OpenGL), Open Computing Language (OpenCL) und/oder Vulkan Graphics und Rechen-API bereitgestellt werden, die alle von der Khronos Group sind. Eine Unterstützung kann auch für die Direct3D-Bibliothek von der Microsoft Corporation bereitgestellt werden. Eine Kombination dieser Bibliotheken kann unterstützt werden. Unterstützung kann auch für die Open Source Computer Vision Library (OpenCV) bereitgestellt werden. Eine zukünftige API mit einer kompatiblen 3D-Pipeline wird ebenfalls unterstützt, falls eine Abbildung von der Pipeline der zukünftigen API auf die Pipeline des Grafikprozessors vorgenommen werden kann.
  • Grafik-Pipeline-Programmierung
  • 22A ist ein Blockdiagramm, das ein Grafikprozessor-Befehlsformat 2200 veranschaulicht, das zum Programmieren von Grafikverarbeitungs-Pipelines verwendet wird, wie beispielsweise die hierin in Verbindung mit 16A, 17, 21 beschriebenen Pipelines. 22B ist ein Blockdiagramm, das eine Grafikprozessorbefehlssequenz 2210 gemäß einer Ausführungsform veranschaulicht. Die Kästchen mit durchgezogenen Linien in 22A veranschaulichen die Komponenten, die im Allgemeinen 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 Grafikprozessorbefehlsformat 2200 aus 22A beinhaltet Datenfelder, um einen Client 2202, einen Befehlsoperationscode (Opcode) 2204 und Daten 2206 für den Befehl zu identifizieren. Ein Sub-Opcode 2205 und eine Befehlsgröße 2208 sind ebenfalls in einigen Befehlen enthalten.
  • Der Client 2202 kann die Client-Einheit der Grafikvorrichtung spezifizieren, die die Befehlsdaten verarbeitet. Ein Grafikprozessor-Befehls-Parser kann das Client-Feld jedes Befehls untersuchen, um die weitere Verarbeitung des Befehls zu konditionieren und die Befehlsdaten an die geeignete Client-Einheit zu routen. Die Grafikprozessor-Client-Einheiten können eine Speicherschnittstelleneinheit, eine Rendering-Einheit, eine 2D-Einheit, eine 3D-Einheit und eine Medieneinheit beinhalten. Jede Client-Einheit kann eine entsprechende Verarbeitungs-Pipeline aufweisen, die die Befehle verarbeitet. Sobald der Befehl von der Client-Einheit empfangen wird, liest die Client-Einheit den Opcode 2204 und, falls vorhanden, den Sub-Opcode 2205, um die durchzuführende Operation zu bestimmen. Die Client-Einheit führt den Befehl unter Verwendung von Informationen in dem Datenfeld 2206aus. Für einige Befehle wird erwartet, dass eine explizite Befehlsgröße 2208 die Größe des Befehls angibt. Der Befehls-Parser kann die Größe von mindestens einigen der Befehle basierend auf dem Befehls-Opcode automatisch bestimmen. Befehle können über Vielfache eines Doppelwortes ausgerichtet werden. Andere Befehlsformate können ebenfalls verwendet werden.
  • Das Flussdiagramm in 22b veranschaulicht eine beispielhafte Grafikprozessorbefehlssequenz 2210. Software oder Firmware eines Datenverarbeitungssystems, das einen beispielhaften Grafikprozessor aufweist, kann eine Version der gezeigten Befehlssequenz verwenden, um einen Satz von Grafikoperationen einzurichten, auszuführen und zu beenden. Eine beispielhafte Befehlssequenz ist nur zu beispielhaften Zwecken gezeigt und beschrieben und ist nicht auf diese spezifischen Befehle oder auf diese Befehlssequenz beschränkt. Darüber hinaus können die Befehle als Stapel von Befehlen in einer Befehlssequenz ausgegeben werden, sodass der Grafikprozessor die Befehlssequenz zumindest teilweise gleichzeitig verarbeiten kann.
  • Die Grafikprozessor-Befehlssequenz 2210 kann mit einem Pipeline-Entleerungsbefehl 2212 beginnen, um zu veranlassen, dass jede aktive Grafik-Pipeline die aktuell anstehenden Befehle für die Pipeline abschließt. Optional arbeiten die 3D-Pipeline 2222 und die Medien-Pipeline 2224 möglicherweise nicht gleichzeitig. Die Pipeline-Leerung wird durchgeführt, um zu veranlassen, dass die aktive Grafik-Pipeline alle ausstehenden Befehle abschließt. Als Reaktion auf eine Pipeline-Leerung kann der Befehls-Parser für den Grafikprozessor die Befehlsverarbeitung pausieren, bis die aktiven Zeichnungs-Engines ausstehende Operationen abschließen und die relevanten Lese-Caches ungültig gemacht sind. Optional können beliebige Daten im Render-Cache, die als ‚verschmutzt‘ markiert sind, in den Speicher geleert werden. Der Pipeline-Entleerungsbefehl 2212 kann zur Pipeline-Synchronisation oder vor dem Versetzen des Grafikprozessors in einen Niederleistungszustand verwendet werden.
  • Ein Pipeline-Auswahlbefehl 2213 kann verwendet werden, wenn eine Befehlssequenz anfordert, dass der Grafikprozessor explizit zwischen Pipelines umschaltet. Ein Pipeline-Auswahlbefehl 2213 kann nur einmal in einem Ausführungskontext verwendet werden, bevor Pipeline-Befehle ausgegeben werden, es sei denn, der Kontext gibt Befehle für beide Pipelines aus. Ein Pipeline-Leerungsbefehl 2212 kann unmittelbar vor einem Pipeline-Umschalten über den Pipeline-Auswahlbefehl 2213 genutzt werden.
  • Ein Pipeline-Steuerbefehl 2214 kann eine Grafik-Pipeline für den Betrieb konfigurieren und kann verwendet werden, um die 3D-Pipeline 2222 und die Medien-Pipeline 2224zu programmieren. Der Pipeline-Steuerbefehl 2214 kann den Pipeline-Zustand für die aktive Pipeline konfigurieren. Der Pipeline-Steuerbefehl 2214 kann für die Pipeline-Synchronisation und zum Löschen von Daten aus einem oder mehreren Cache-Speichern innerhalb der aktiven Pipeline verwendet werden, bevor ein Stapel von Befehlen verarbeitet wird.
  • Befehle, die sich auf den Rückgabepufferzustand 2216 beziehen, können verwendet werden, um einen Satz von Rückgabepuffern für die jeweiligen Pipelines zum Schreiben von Daten zu konfigurieren. Manche Pipeline-Operationen nutzen die Zuweisung, Auswahl oder Konfiguration eines oder mehrerer Rückgabepuffer, in die die Operationen Zwischendaten während der Verarbeitung schreiben. Der Grafikprozessor kann auch einen oder mehrere Rückgabepuffer verwenden, um Ausgabedaten zu speichern und eine Cross-Thread-Kommunikation durchzuführen. Der Rückgabepufferzustand 2216 kann das Auswählen der Größe und Anzahl von Rückgabepuffern beinhalten, die für einen Satz 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 2220wird die Befehlssequenz auf die 3D-Pipeline 2222 beginnend mit dem 3D-Pipeline-Zustand 2230 oder die Medien-Pipeline 2224 beginnend mit dem Medien-Pipeline-Zustand 2240 zugeschnitten.
  • Die Befehle zum Konfigurieren des 3D-Pipeline-Zustands 2230 beinhalten 3D-Zustandseinstellbefehle für den Vertex-Pufferzustand, den Vertex-Elementzustand, den konstanten Farbzustand, den Tiefenpufferzustand und andere Zustandsvariablen, die zu konfigurieren sind, bevor 3D-Primitiv-Befehle verarbeitet werden. Die Werte dieser Befehle werden mindestens teilweise basierend auf der jeweiligen verwendeten 3D-API bestimmt. Die Befehle des 3D-Pipeline-Zustands 2230 können auch in der Lage sein, bestimmte Pipeline-Elemente gezielt zu deaktivieren oder zu umgehen, falls diese Elemente nicht verwendet werden können.
  • Ein 3D-Primitiv-Befehl 2232 kann verwendet werden, um 3D-Primitive, die von der 3D-Pipeline verarbeitet werden sollen, zu versenden. Befehle und zugehörige Parameter, die über den 3D-Primitiv-Befehl 2232 an den Grafikprozessorgeleitet werden, werden an die Vertex-Abruffunktion in der Grafik-Pipeline weitergeleitet. Die Vertex-Abruffunktion verwendet die Daten des 3D-Primitiv-Befehls 2232, um Vertex-Datenstrukturen zu erzeugen. Die Vertex-Datenstrukturen werden in einem oder mehreren Rückgabepuffern gespeichert. Der 3D-Primitiv-Befehl 2232 kann verwendet werden, um Vertex-Operationen an 3D Primitiven über Vertex-Shader durchzuführen. Um Vertex-Shader zu verarbeiten, versendet die 3D-Pipeline 2222 Shader-Ausführungs-Threads an Grafikprozessorausführungseinheiten.
  • Die 3D-Pipeline 2222 kann über einen Ausführungsbefehl 2234 oder ein Ausführungsereignis ausgelöst werden. Ein Register kann Auslösebefehlsausführungen schreiben. Eine Ausführung kann über einen „Go“- oder „Kick“-Befehl in der Befehlssequenz ausgelöst werden. Die Befehlsausführung kann unter Verwendung eines Pipeline-Synchronisationsbefehls ausgelöst werden, um die Befehlssequenz durch die Grafik-Pipeline zu entleeren. Die 3D-Pipeline kann Geometrieverarbeitung für die 3D-Primitive durchführen. Sobald die Operationen abgeschlossen sind, werden die resultierenden geometrischen Objekte rasterisiert und färbt die Pixel-Engine die resultierenden Pixel. Weitere Befehle zum Steuern des Pixel-Shadings und der Pixel-Backend-Operationen können ebenfalls für diese Operationen enthalten sein.
  • Die Grafikprozessorbefehlssequenz 2210 kann dem Pfad der Medien-Pipeline 2224 folgen, wenn Medienoperationen durchgeführt werden. Im Allgemeinen hängen die spezielle Verwendung und Art der Programmierung für die Medien-Pipeline 2224 von den durchzuführenden Medien oder Rechenoperationen ab. Spezifische Mediendecodierungsoperationen können während der Mediendecodierung an die Medien-Pipeline abgeladen werden. Die Medien-Pipeline kann auch umgangen werden und die Mediendecodierung kann vollständig oder teilweise unter Verwendung von Ressourcen durchgeführt werden, die von einem oder mehreren Universalverarbeitungskernen bereitgestellt werden. Die Medien-Pipeline kann auch Elemente für Operationen einer Universalgrafikprozessoreinheit (GPGPU: General-Purpose Graphics Processor Unit) beinhalten, wobei der Grafikprozessor verwendet wird, um SIMD-Vektoroperationen unter Verwendung von Rechen-Shader-Programmen, die nicht explizit mit dem Rendering von Grafikprimitiven in Zusammenhang stehen, durchzuführen.
  • Die Medien-Pipeline 2224 kann auf ähnliche Weise wie die 3D-Pipeline 2222 konfiguriert sein. Ein Satz von Befehlen zum Konfigurieren des Medien-Pipeline-Zustands 2240 wird vor den Medienobjektbefehlen 2242 versendet oder in eine Befehlswarteschlange platziert. Befehle für den Medien-Pipeline-Zustand 2240 können Daten zum Konfigurieren der Medien-Pipeline-Elemente beinhalten, die zum Verarbeiten der Medienobjekte verwendet werden können. Dies beinhaltet Daten zum Konfigurieren der Videodecodier- und Videocodierlogik innerhalb der Medien-Pipeline, wie Codieren oder Decodieren des Formats. Befehle für den Medien-Pipeline-Zustand 2240 können auch die Verwendung von einem oder mehreren Zeigern auf „indirekte“ Zustandselemente unterstützen, die einen Stapel von Zustandseinstellungen enthalten.
  • Medienobjektbefehle 2242 können Zeiger auf Medienobjekte zur Verarbeitung durch die Medien-Pipeline liefern. Die Medienobjekte weisen Speicherpuffer auf, die zu verarbeitende Videodaten beinhalten. Optional sollten alle Medien-Pipeline-Zustände gültig sein, bevor sie einen Medienobjektbefehl 2242 ausgeben. Sobald der Pipeline-Zustand konfiguriert ist und Medienobjektbefehle 2242 in die Warteschlange eingereiht sind, wird die Medien-Pipeline 2224 über einen Ausführungsbefeh12244 oder ein äquivalentes Ausführungsereignis (z. B. Registerschreibvorgang) ausgelöst. Die Ausgabe von der Medien-Pipeline 2224 kann dann durch Operationen nachverarbeitet werden, die durch die 3D-Pipeline 2222 oder die Medien-Pipeline 2224bereitgestellt werden. GPGPU-Operationen können auf ähnliche Weise wie Medienoperationen konfiguriert und ausgeführt werden.
  • Grafiksoftwarearchitektur
  • 23 veranschaulicht eine beispielhafte Grafiksoftwarearchitektur für ein Datenverarbeitungssystem 2300. Eine solche Softwarearchitektur kann eine 3D-Grafikanwendung 2310, ein Betriebssystem 2320 und mindestens einen Prozessor 2330 beinhalten. Der Prozessor 2330 kann einen Grafikprozessor 2332 und einen oder mehrere Universalprozessorkerne 2334 beinhalten. Der Prozessor 2330 kann eine Variante des Prozessors 1402 oder ein beliebiger anderer der hier beschriebenen Prozessoren sein. Der Prozessor 2330 kann anstelle des Prozessors 1402 oder eines beliebigen anderen der hier beschriebenen Prozessoren verwendet werden. Daher offenbart die Erläuterung jeglicher Merkmale in Kombination mit dem Prozessor 1402 oder einem beliebigen anderen der hierin beschriebenen Prozessoren auch eine entsprechende Kombination mit dem Grafikprozessor 2332, ist aber nicht darauf beschränkt. Darüber hinaus sind die Elemente von 23 mit den gleichen oder ähnlichen Namen wie die Elemente einer beliebigen anderen Figur hierin beschreiben die gleichen Elemente wie in den anderen Figuren, können auf eine ähnliche Weise wie jene arbeiten oder funktionieren, können die gleichen Komponenten umfassen und können mit anderen Entitäten, wie jenen, die an anderer Stelle hierin beschrieben sind, verknüpft sein, sind aber nicht darauf beschränkt. Die Grafikanwendung 2310 und das Betriebssystem 2320 werden jeweils in dem Systemspeicher 2350 des Datenverarbeitungssystems ausgeführt.
  • Die 3D-Grafikanwendung 2310 kann ein oder mehrere Shader-Programme, einschließlich Shader-Anweisungen 2312, enthalten. Die Shader-Sprachanweisungen können in einer Shader-Sprache hoher Ebene vorliegen, wie der High Level Shader Language (HLSL) von Direct3D, der OpenGL Shader Language (GLSL) und so weiter. Die Anwendung kann auch ausführbare Anweisungen 2314 in einer Maschinensprache aufweisen, die zur Ausführung durch den Universalprozessorkern 2334 geeignet sind. Die Anwendung kann auch Grafikobjekte 2316 beinhalten, die durch Vertex-Daten definiert sind.
  • Das Betriebssystem 2320 kann ein Microsoft® Windows®-Betriebssystem der Microsoft Corporation, ein proprietäres UNIX-ähnliches Betriebssystem oder ein UNIX-ähnliches Open-Source-Betriebssystem, das eine Variante des Linux-Kernels verwendet, sein. Das Betriebssystem 2320 kann eine Grafik-API 2322 unterstützen, wie die API Direct3D, die OpenGL-API oder die Vulkan-API. Wenn die API Direct3D verwendet wird, verwendet das Betriebssystem 2320 einen Frontend-Shader-Compiler 2324 , um jegliche Shader-Anweisungen 2312 in HLSL in eine Shader-Sprache niedrigerer Ebene zu kompilieren. Die Kompilierung kann eine Just-in-Time-(JIT)-Kompilierung sein, oder die Anwendung kann eine Shader-Vorkompilierung durchführen. Shader hoher Ebene können während der Kompilierung der 3D-Grafikanwendung 2310 zu Shadern niedrigerer Ebene kompiliert werden. Die Shader-Anweisungen 2312 können in einer Zwischenform bereitgestellt werden, wie als eine Version der SPIR (Standard Portable Intermediate Representation), die durch die Vulkan-API verwendet wird.
  • Der Benutzermodus-Grafiktreiber 2326 kann einen Backend-Shader-Compiler 2327 enthalten, um die Shader-Anweisungen 2312 in eine hardwarespezifische Repräsentation umzuwandeln. Wenn die OpenGL-API verwendet wird, werden Shader-Anweisungen 2312 in der GLSL-Sprache hoher Ebene an einen Benutzermodus-Grafiktreiber 2326 zur Kompilierung weitergeleitet. Der Benutzermodus-Grafiktreiber 2326 kann Betriebssystem-Kernelmodus-Funktionen 2328 verwenden, um mit einem Kernelmodus-Grafiktreiber 2329 zu kommunizieren. Der Kernelmodus-Grafiktreiber 2329 kann mit dem Grafikprozessor 2332 kommunizieren, um Befehle und Anweisungen zu versenden.
  • IP-Kern-Implementierungen
  • Ein oder mehrere Aspekte können durch einen repräsentativen Code implementiert werden, der auf einem maschinenlesbaren Medium (z. B. einem nichtflüchtigen computerlesbaren (oder maschinenlesbaren) Speichermedium) gespeichert ist, der Logik innerhalb einer integrierten Schaltung, wie einem Prozessor, repräsentiert und/oder definiert. Zum Beispiel kann das maschinenlesbare Medium Anweisungen aufweisen, die verschiedene Logik innerhalb des Prozessors repräsentieren. Wenn sie durch eine Maschine gelesen werden, können die Anweisungen veranlassen, dass die Maschine die Logik herstellt, um die hierin beschriebenen Techniken durchzuführen. Derartige Repräsentationen, die als „IP-Kerne“ bekannt sind, sind wiederverwendbare Logikeinheiten für eine integrierte Schaltung, die auf einem greifbaren, maschinenlesbaren Medium als ein Hardwaremodell gespeichert werden können, das die Struktur der integrierten Schaltung beschreibt. Das Hardwaremodell kann an verschiedene Kunden oder Herstellungseinrichtungen geliefert werden, die das Hardwaremodell auf Herstellungsmaschinen laden, die die integrierte Schaltung herstellen. Die integrierte Schaltung kann derart hergestellt sein, dass die Schaltung Operationen durchführt, die in Verbindung mit irgendeiner der hierin beschriebenen Ausführungsformen beschrieben sind.
  • 24A ist ein Blockdiagramm, das ein IP-Kern-Entwicklungssystem 2400 veranschaulicht, das zur Herstellung einer integrierten Schaltung zur Durchführung von Operationen verwendet werden kann. Das IP-Kernentwicklungssystem 2400 kann verwendet werden, um modulare, wiederverwendbare Designs zu erzeugen, die in ein größeres Design integriert werden können oder verwendet werden können, um eine gesamte integrierte Schaltung (z. B. eine integrierte SOC-Schaltung) zu konstruieren. Eine Designeinrichtung 2430 kann eine Softwaresimulation 2410 eines IP-Kern-Designs in einer Programmiersprache hoher Ebene (z. B. C/C++) erzeugen. Die Softwaresimulation 2410 kann verwendet werden, um das Verhalten des IP-Kerns unter Verwendung eines Simulationsmodells 2412 zu entwerfen, zu testen und zu verifizieren. Das Simulationsmodell 2412 kann Funktions-, Verhaltens- und/oder Zeitsteuerungssimulationen beinhalten. Aus dem Simulationsmodell 2412kann dann ein Register Transfer Level-(RTL)-Design 2415 erstellt oder synthetisiert werden. Das RTL-Design 2415 ist eine Abstraktion des Verhaltens der integrierten Schaltung, die den Fluss digitaler Signale zwischen Hardwareregistern modelliert, einschließlich der zugehörigen Logik, die unter Verwendung der modellierten digitalen Signale durchgeführt wird. Zusätzlich zu einem RTL-Design 2415können auch Designs niedrigerer Ebene auf der Logikebene oder der Transistorebene erzeugt, gestaltet oder synthetisiert werden. Daher können die speziellen Einzelheiten des anfänglichen Designs und der Simulation variieren.
  • Das RTL-Design 2415 oder Äquivalent kann ferner durch die Designeinrichtung in ein Hardwaremodell 2420 synthetisiert werden, das in einer Hardwarebeschreibungssprache (HDL) oder einer anderen Repräsentation physischer Designdaten vorliegen kann. Die HDL kann weiter simuliert oder getestet werden, um das IP-Kern-Design zu verifizieren. Das IP-Kern-Design kann zur Lieferung an eine Fertigungseinrichtung 2465 Dritter unter Verwendung eines nichtflüchtigen Speichers 2440 (z. B. Festplatte, Flash-Speicher oder ein beliebiges nichtflüchtiges Speichermedium) gespeichert werden. Alternativ dazu kann das IP-Kern-Design über eine drahtgebundene Verbindung 2450 oder eine drahtlose Verbindung 2460übertragen werden (z. B. über das Internet). Die Fertigungseinrichtung 2465 kann dann eine integrierte Schaltung fertigen, die mindestens teilweise auf dem IP-Kern-Design basiert. Die gefertigte integrierte Schaltung kann dazu konfiguriert sein, Operationen gemäß mindestens einer hier beschriebenen Ausführungsform durchzuführen.
  • 24B veranschaulicht eine Querschnittsseitenansicht einer Package-Baugruppe 2470 mit integrierter Schaltung. Die Package-Baugruppe 2470 mit integrierter Schaltung veranschaulicht eine Implementierung eines oder mehrerer Prozessoren oder einer oder mehrerer Beschleunigervorrichtungen, wie hier beschrieben. Die Package-Baugruppe 2470 beinhaltet mehrere Hardwarelogikeinheiten 2472, 2474, die mit einem Substrat 2480 verbunden sind. Die Logik 2472, 2474 kann mindestens teilweise in konfigurierbarer Logik oder Logikhardware mit fester Funktionalität implementiert sein und kann einen oder mehrere Abschnitte von beliebigen des einen oder der mehreren Prozessorkerne, des einen oder der mehreren Grafikprozessoren oder anderer hier beschriebener Beschleunigervorrichtungen beinhalten. Jede Logikeinheit 2472, 2474 kann in einem Halbleiter-Die implementiert und über eine Interconnect-Struktur 2473 mit dem Substrat 2480 gekoppelt sein. Die Interconnect-Struktur 2473 kann dazu konfiguriert sein, elektrische Signale zwischen der Logik 2472, 2474 und dem Substrat 2480 zu routen, und kann Interconnects wie, jedoch ohne Einschränkung, Kontakthügel oder Säulen beinhalten. Die Interconnect-Struktur 2473 kann dazu konfiguriert sein, elektrische Signale, wie zum Beispiel Eingabe/Ausgabe-(E/A)-Signale und/oder Leistungs- oder Massesignale, die dem Betrieb der Logik 2472, 2474 zugeordnet sind, zu routen. Optional kann das Substrat 2480 ein epoxidbasiertes Laminatsubstrat sein. Das Substrat 2480 kann auch andere geeignete Arten von Substraten beinhalten. Die Package-Baugruppe 2470 kann über ein Package-Interconnect 2483 mit anderen elektrischen Vorrichtungen verbunden sein. Das Package-Interconnect 2483 kann mit einer Oberfläche des Substrats 2480 gekoppelt sein, um elektrische Signale zu anderen elektrischen Vorrichtungen, wie einer Hauptplatine, einem anderen Chipsatz oder einem Mehrchipmodul, zu routen.
  • Die Logikeinheiten 2472, 2474 können elektrisch mit einer Brücke 2482 gekoppelt sein, die dazu konfiguriert ist, elektrische Signale zwischen der Logik 2472, 2474zu routen. Die Brücke 2482 kann eine dichte Interconnect-Struktur sein, die eine Route für elektrische Signale bereitstellt. Die Brücke 2482 kann ein Brückensubstrat beinhalten, das aus Glas oder einem geeigneten Halbleitermaterial zusammengesetzt ist. Elektrische Routing-Merkmale können auf dem Brückensubstrat gebildet sein, um eine Chip-zu-Chip-Verbindung zwischen der Logik 2472, 2474 bereitzustellen.
  • Obwohl zwei Logikeinheiten 2472, 2474 und eine Brücke 2482 veranschaulicht sind, können hier beschriebene Ausführungsformen mehr oder weniger Logikeinheiten auf einem oder mehreren Dies beinhalten. Der eine oder die mehreren Dies können durch keine oder mehr Brücken verbunden sein, da die Brücke 2482 ausgelassen werden kann, wenn die Logik auf einem einzelnen Die enthalten ist. Alternativ dazu können mehrere Dies oder Logikeinheiten durch eine oder mehrere Brücken verbunden sein. Zusätzlich dazu können mehrere Logikeinheiten, Dies und Brücken in anderen möglichen Konfigurationen, einschließlich dreidimensionaler Konfigurationen, miteinander verbunden sein.
  • 24C veranschaulicht eine Package-Baugruppe 2490, die mehrere Einheiten von Hardware-Logik-Chiplets beinhaltet, die mit einem Substrat 2480 (z. B. Basis-Die) verbunden sind. Eine Grafikverarbeitungseinheit, ein Parallelprozessor und/oder ein Berechnungsbeschleuniger, wie hierin beschrieben, können aus verschiedenen Silizium-Chiplets bestehen, die separat hergestellt werden. In diesem Zusammenhang ist ein Chiplet eine zumindest teilweise integrierte Schaltung in einem Package, die verschiedene Logikeinheiten beinhaltet, die mit anderen Chiplets zu einem größeren Package zusammengebaut werden können. Ein diverser Satz von Chiplets mit unterschiedlicher IP-Kern-Logik kann zu einer einzigen Vorrichtung zusammengebaut werden. Darüber hinaus können die Chiplets mittels aktiver Interposer-Technologie in einen Basis-Die oder ein Basis-Chiplet integriert werden. Die hierin beschriebenen Konzepte ermöglichen die Verbindung und Kommunikation zwischen den verschiedenen Formen von IP innerhalb der GPU. IP-Kerne können unter Verwendung unterschiedlicher Prozesstechnologien hergestellt und während der Herstellung zusammengestellt werden, wodurch die Komplexität zum Konvergieren mehrerer IPs, insbesondere auf einem großen SoC mit mehreren IP-Varianten, für denselben Herstellungsprozess vermieden wird. Die Nutzung mehrerer Prozesstechnologien verkürzt die Markteinführungszeit und bietet eine kostengünstige Möglichkeit, mehrere Produkt-SKUs zu erstellen. Darüber hinaus sind die disaggregierten IPs für ein unabhängiges Ansteuern mit Leistung besser geeignet, Komponenten, die bei einer bestimmten Arbeitslast nicht verwendet werden, können ausgeschaltet werden, wodurch der Gesamtleistungsverbrauch reduziert wird.
  • In verschiedenen Ausführungsformen kann eine Package-Baugruppe 2490 weniger oder mehr Komponenten und Chiplets beinhalten, die durch eine Fabric 2485 oder eine oder mehrere Brücken 2487 miteinander verbunden sind. Die Chiplets innerhalb der Package-Baugruppe 2490 können eine 2,5D-Anordnung unter Verwendung eines Chip-auf-Wafer-auf-Substrat-Stapels aufweisen, bei dem mehrere Dies nebeneinander auf einem Silicium-Interposer gestapelt sind, der Silicium-Durchkontaktierungen (TSVs) beinhaltet, um die Chiplets mit dem Substrat 2480zu koppeln, das elektrische Verbindungen mit dem Package-Interconnect 2483beinhaltet.
  • Bei einer Ausführungsform ist der Silicium-Interposer ein aktiver Interposer 2489 , der eingebettete Logik zusätzlich zu TSVs beinhaltet. Bei einer solchen Ausführungsform sind die Chiplets innerhalb der Package-Baugruppe 2490 unter Verwendung von 3D-Fläche-zu-Fläche-Die-Stapeln auf dem aktiven Interposer 2489 angeordnet. Der aktive Interposer 2489 kann Hardwarelogik für die E/A 2491, den Cache-Speicher 2492 und andere Hardwarelogik 2493 zusätzlich zu der Interconnect-Fabric 2485 und einer Siliciumbrücke 2487 beinhalten. Die Fabric 2485 ermöglicht eine Kommunikation zwischen den verschiedenen Logik-Chiplets 2472, 2474 und der Logik 2491, 2493 innerhalb des aktiven Interposers 2489. Die Fabric 2485 kann ein NoC-Interconnect oder eine andere Form eines paketvermittelten Fabric sein, das Datenpakete zwischen Komponenten der Package-Baugruppe vermittelt. Für komplexe Baugruppen kann die Fabric 2485 ein dediziertes Chiplet sein, das eine Kommunikation zwischen den verschiedenen Hardwarelogiken der Package-Baugruppe 2490ermöglicht.
  • Brückenstrukturen 2487 innerhalb des aktiven Interposers 2489 können verwendet werden, um ein Punkt-zu-Punkt-Interconnect zwischen zum Beispiel Logik- oder E/A-Chiplets 2474 und Speicher-Chiplets 2475 zu ermöglichen. In einigen Implementierungen können die Brückenstrukturen 2487 auch innerhalb des Substrats 2480 eingebettet sein.
  • Die Hardware-Logik-Chiplets können Spezialhardware-Logik-Chiplets 2472, Logik- oder E/A-Chiplets 2474 und/oder Speicher-Chiplets 2475beinhalten. Die Hardwarelogik-Chiplets 2472 und die Logik- oder E/A-Chiplets 2474 können zumindest teilweise in konfigurierbarer Logik- oder Festfunktionalitätslogikhardware implementiert werden und können einen oder mehrere Teile beliebiger des einen oder der mehreren Prozessorkerne, des einen oder der mehreren Grafikprozessoren, der Parallelprozessoren oder anderer hierin beschriebener Beschleunigervorrichtungen beinhalten. Die Speicher-Chiplets 2475 können DRAM-(z. B. GDDR, HBM)-Speicher oder Cache-(SRAM)-Speicher sein. Cache-Speicher 2492 innerhalb des aktiven Interposers 2489 (oder des Substrats 2480) kann als globaler Cache für die Package-Baugruppe 2490, als Teil eines verteilten globalen Caches oder als dedizierter Cache für die Fabric 2485 fungieren.
  • Jedes Chiplet kann als separater Halbleiter-Die gefertigt und mit einem Basis-Die gekoppelt werden, der innerhalb des Substrats 2480 eingebettet oder mit diesem gekoppelt ist. Die Kopplung mit dem Substrat 2480 kann über eine Interconnect-Struktur 2473 durchgeführt werden. Die Interconnect-Struktur 2473 kann dazu konfiguriert sein, elektrische Signale zwischen den verschiedenen Chiplets und der Logik innerhalb des Substrats 2480 zu routen. Die Interconnect-Struktur 2473 kann Interconnects wie, jedoch ohne Einschränkung, Kontakthügel oder Säulen beinhalten. In einigen Ausführungsformen kann die Interconnect-Struktur 2473 dazu konfiguriert sein, elektrische Signale, wie zum Beispiel Eingabe/Ausgabe-(E/A)-Signale und/oder Leistungs- oder Massesignale, zu routen, die dem Betrieb der Logik, E/A- und Speicher-Chiplets zugeordnet sind. Bei einer Ausführungsform koppelt eine zusätzliche Interconnect-Struktur den aktiven Interposer 2489 mit dem Substrat 2480.
  • Das Substrat 2480 kann ein epoxidbasiertes Laminatsubstrat sein, ist jedoch nicht darauf beschränkt und das Substrat 2480 kann auch andere geeignete Arten von Substraten beinhalten. Die Package-Baugruppe 2490 kann über ein Package-Interconnect 2483 mit anderen elektrischen Vorrichtungen verbunden sein. Das Package-Interconnect 2483 kann mit einer Oberfläche des Substrats 2480 gekoppelt sein, um elektrische Signale zu anderen elektrischen Vorrichtungen, wie einer Hauptplatine, einem anderen Chipsatz oder einem Mehrchipmodul, zu routen.
  • Eine Logik oder ein E/A-Chiplet 2474 und ein Speicher-Chiplet 2475 können elektrisch über eine Brücke 2487 gekoppelt sein, die dazu konfiguriert ist, elektrische Signale zwischen der Logik oder dem E/A-Chiplet 2474 und einem Speicher-Chiplet 2475zu routen. Die Brücke 2487 kann eine dichte Interconnect-Struktur sein, die eine Route für elektrische Signale bereitstellt. Die Brücke 2487 kann ein Brückensubstrat beinhalten, das aus Glas oder einem geeigneten Halbleitermaterial zusammengesetzt ist. Elektrische Routing-Merkmale können auf dem Brückensubstrat ausgebildet sein, um eine Chip-zu-Chip-Verbindung zwischen dem Logik- oder E/A-Chiplet 2474 und einem Speicher-Chiplet 2475bereitzustellen. Die Brücke 2487 kann auch als Siliciumbrücke oder Interconnect-Brücke bezeichnet werden. Die Brücke 2487 ist zum Beispiel eine eingebettete Multi-Die-Interconnect-Brücke (EMIB: Embedded Multi-die Interconnect Bridge). Alternativ dazu kann die Brücke 2487 einfach eine direkte Verbindung von einem Chiplet zu einem anderen Chiplet sein.
  • 24D veranschaulicht eine Package-Baugruppe 2494 einschließlich austauschbarer Chiplets 2495 gemäß einer Ausführungsform. Die austauschbaren Chiplets 2495 können in standardisierte Steckplätze auf einem oder mehreren Basis-Chiplets 2496, 2498 montiert sein. Die Basis-Chiplets 2496, 2498 können über ein Brücken-Interconnect 2497gekoppelt sein, das den anderen hierin beschriebenen Brücken-Interconnects ähnlich sein kann und beispielsweise eine EMIB sein kann. Speicher-Chiplets können auch über ein Brücken-Interconnect mit Logik- oder E/A-Chiplets verbunden sein. E/A- und Logik-Chiplets können über eine Interconnect-Fabric kommunizieren. Die Basis-Chiplets können jeweils einen oder mehrere Steckplätze in einem standardisierten Format für Logik oder E/A oder Speicher/Cache unterstützen.
  • SRAM- und Leistungslieferschaltungen können in einem oder mehreren der Basis-Chiplets 2496, 2498 gefertigt sein, die unter Verwendung einer anderen Prozesstechnologie relativ zu den austauschbaren Chiplets 2495, die auf den Basis-Chiplets gestapelt sind, gefertigt werden können. Zum Beispiel können die Basis-Chiplets 2496, 2498 unter Verwendung einer größeren Prozesstechnologie hergestellt werden, während die austauschbaren Chiplets unter Verwendung einer kleineren Prozesstechnologie hergestellt werden können. Einer oder mehrere der austauschbaren Chiplets 2495 können Speicher-(z. B. DRAM)-Chiplets sein. Für die Package-Baugruppe 2494 können unterschiedliche Speicherdichten basierend auf der Leistung und/oder Leistungsfähigkeit ausgewählt werden, die für das Produkt, das die Package-Baugruppe 2494 verwendet, angestrebt wird. Zusätzlich dazu können Logik-Chiplets mit einer anderen Anzahl von Arten von Funktionseinheiten zum Zeitpunkt des Zusammenbaus basierend auf der Leistung und/oder Leistungsfähigkeit, die für das Produkt angestrebt wird, ausgewählt werden. Darüber hinaus können Chiplets, die IP-Logik-Kerne unterschiedlicher Typen enthalten, in die austauschbaren Chiplet-Steckplätze eingefügt werden, wodurch Hybridprozessordesigns ermöglicht werden, die IP-Blöcke unterschiedlicher Technologie mischen und abgleichen können.
  • Beispielhafte integrierte Schaltung in einem System-on-a-Chip
  • 25-26B veranschaulichen beispielhafte integrierte Schaltungen und zugehörige Grafikprozessoren, die unter Verwendung eines oder mehrerer IP-Kerne hergestellt werden können. Zusätzlich zu den Veranschaulichungen, können andere Logik und Schaltungen enthalten sein, einschließlich zusätzlicher Grafikprozessoren/- kerne, Peripherieschnittstellensteuerungen oder Universalprozessorkerne. Die Elemente von 25-26B mit den gleichen oder ähnlichen Namen wie die Elemente einer beliebigen anderen Figur hierin beschreiben die gleichen Elemente wie in den anderen Figuren, können auf eine ähnliche Weise wie jene arbeiten oder funktionieren, können die gleichen Komponenten umfassen und können mit anderen Entitäten, wie jenen, die an anderer Stelle hierin beschrieben sind, verknüpft sein, sind aber nicht darauf beschränkt.
  • 25 ist ein Blockdiagramm, das eine beispielhafte integrierte System-on-Chip-Schaltung 2500 veranschaulicht, die unter Verwendung eines oder mehrerer IP-Kerne hergestellt werden kann. Die beispielhafte integrierte Schaltung 2500 beinhaltet einen oder mehrere Anwendungsprozessoren 2505 (z. B. CPUs), mindestens ein Grafikprozessor 2510, der eine Variante des Grafikprozessors 1408, 1508, 2510 oder eines beliebigen hierin beschriebenen Grafikprozessors sein kann und anstelle eines beliebigen beschriebenen Grafikprozessors verwendet werden kann. Daher offenbart die Erörterung jeglicher Merkmale in Kombination mit einem Grafikprozessor hierin auch eine entsprechende Kombination mit dem Grafikprozessor 2510, ist aber nicht darauf beschränkt. Die integrierte Schaltung 2500 kann zusätzlich einen Bildprozessor 2515 und/oder einen Videoprozessor 2520 aufweisen, von denen jeder ein modularer IP-Kern aus derselben oder mehreren verschiedenen Designentwurfseinrichtungen sein kann. Die integrierte Schaltung 2500 kann eine Peripherie- oder Buslogik einschließlich einer USB-Steuerung 2525, einer UART-Steuerung 2530, einer SPI/SDIO-Steuerung 2535 und einer I2S/I2C-Steuerung 2540 aufweisen. Zusätzlich dazu kann die integrierte Schaltung eine Anzeigevorrichtung 2545 beinhalten, die mit einer HDMI-(High Definition Multimedia Interface)-Steuerung 2550 und /oder einer NHPI-(Mobile Industry Processor Interface)-Anzeigeschnittstelle 2555gekoppelt ist. Die Speicherung kann durch ein Flash-Speicher-Subsystem 2560 bereitgestellt werden, das einen Flash-Speicher und eine Flash-Speichersteuerung aufweist. Eine Speicherschnittstelle kann über eine Speichersteuerung 2565 zum Zugriff auf SDRAM- oder SRAM-Speichervorrichtungen bereitgestellt werden. Einige integrierte Schaltungen weisen zusätzlich eine eingebettete Sicherheits-Engine 2570auf.
  • 26A-26B sind Blockdiagramme, die beispielhafte Grafikprozessoren zur Verwendung innerhalb eines SoC gemäß hierin beschriebenen Ausführungsformen veranschaulichen. Die Grafikprozessoren können Varianten des Grafikprozessors 1408, 1508, 2510 oder eines beliebigen anderen hierin beschriebenen Grafikprozessors sein. Die Grafikprozessoren können anstelle des Grafikprozessors 1408, 1508, 2510 oder eines beliebigen anderen der hierin beschriebenen Grafikprozessoren verwendet werden. Daher offenbart die Erörterung jeglicher Merkmale in Kombination mit dem Grafikprozessor 1408, 1508, 2510 oder einem beliebigen anderen der hierin beschriebenen Grafikprozessoren auch eine entsprechende Kombination mit den Grafikprozessoren von 26A-26B, ist aber nicht darauf beschränkt. 26A veranschaulicht einen beispielhaften Grafikprozessor 2610 einer integrierten System-on-Chip-Schaltung, die unter Verwendung eines oder mehrerer IP-Kerne hergestellt werden kann, gemäß einer Ausführungsform. 26B veranschaulicht einen zusätzlichen beispielhaften Grafikprozessor 2640 einer integrierten System-on-Chip-Schaltung, die unter Verwendung eines oder mehrerer IP-Kerne hergestellt werden kann, gemäß einer Ausführungsform. Der Grafikprozessor 2610 aus 26A ist ein Beispiel für einen Niederleistungs-Grafikprozessorkern. Der Grafikprozessor 2640 aus 26B ist ein Beispiel für einen Grafikprozessorkern mit höherer Leistungsfähigkeit. Zum Beispiel können sowohl der Grafikprozessor 2610 als auch der Grafikprozessor 2640 eine Variante des Grafikprozessors 2510 von 25 sein, wie zu Beginn dieses Absatzes erwähnt.
  • Wie in 26A beinhaltet der Grafikprozessor 2610 einen Vertex-Prozessor 2605 und einen oder mehrere Fragment-Prozessoren 2615A-2615N (z. B. 2615A, 2615B, 2615C, 2615D bis 2615N-1 und 2615N). Der Grafikprozessor 2610 kann verschiedene Shader-Programme über separate Logik ausführen, so dass der Vertex-Prozessor 2605 zum Ausführen von Operationen für Vertex-Shader-Programme optimiert ist, während der eine oder die mehreren Fragment-Prozessor(en) 2615A-2615N Fragment- (z. B. Pixel-) Shading-Operationen für Fragment- oder Pixel-Shader-Programme ausführen. Der Vertex-Prozessor 2605 führt die Vertex-Verarbeitungsstufe der 3D Grafik-Pipeline durch und erzeugt Primitive und Vertex-Daten. Der eine oder die mehreren Fragmentprozessoren 2615A-2615N verwendet die Primitiv- und Vertex-Daten, die durch den Vertex-Prozessor 2605 erzeugt werden, um einen Framepuffer zu erzeugen, der auf einer Anzeigevorrichtung angezeigt wird. Der eine oder die mehreren Fragment-Prozessoren 2615A-2615N kann dazu optimiert sein, Fragment-Shader-Programme, wie sie in der OpenGL-API bereitgestellt werden, auszuführen, die verwendet werden können, um ähnliche Operationen wie ein Pixel-Shader-Programm durchzuführen, wie in der Direct 3D-API bereitgestellt.
  • Der Grafikprozessor 2610 weist zusätzlich eine oder mehrere Speicherverwaltungseinheiten (MMUs) 2620A-2620B, einen oder mehrere Cache(s) 2625A-2625Bund eine oder mehrere Schaltungszwischenverbindung(en) 2630A-2630B auf. Die eine oder die mehreren MMU(s) 2620A-2620B stellen eine Abbildung von virtueller auf physische Adresse für den Grafikprozessor 2610bereit, einschließlich für den Vertex-Prozessor 2605 und/oder Fragment-Prozessor(en) 2615A-2615N, die Vertex- oder Bild-/Texturdaten, die im Speicher gespeichert sind, zusätzlich zu Vertex- oder Bild-/Texturdaten, die in dem einen oder den mehreren Cache(s) 2625A-2625Bgespeichert sind. Die eine oder die mehreren MMUs 2620A-2620B können mit anderen MMUs innerhalb des Systems synchronisiert werden, einschließlich einer oder mehrerer MMUs, die dem einen oder den mehreren Anwendungsprozessoren 2505, dem Bildprozessor 2515und/oder dem Videoprozessor 2520 von 25 zugeordnet sind, so dass jeder Prozessor 2505-2520 an einem gemeinsam genutzten oder vereinheitlichten virtuellen Speichersystem teilnehmen kann. Komponenten des Grafikprozessors 2610 können Komponenten anderer hierin beschriebener Grafikprozessoren entsprechen. Die eine oder die mehreren MMU(s) 2620A-2620B können der MMU 245 von 2C entsprechen. Der Vertex-Prozessor 2605 und der Fragmentprozessor 2615A-2615N können dem Grafikmultiprozessor 234 entsprechen. Das eine oder die mehreren Schaltungs-Interconnect(s) 2630A-2630B ermöglichen gemäß Ausführungsformen, dass der Grafikprozessor 2610 mit anderen IP-Kernen innerhalb des SoC eine Schnittstelle bildet, und zwar entweder über einen internen Bus des SoC oder über eine direkte Verbindung. Das eine oder die mehreren Schaltungs-Interconnect(s) 2630A-2630B können der Daten-Crossbar 240 von 2C entsprechen. Eine weitere Entsprechung ist zwischen analogen Komponenten des Grafikprozessors 2610 und den verschiedenen hierin beschriebenen Grafikprozessorarchitekturen zu finden.
  • Wie 26B gezeigt, beinhaltet der Grafikprozessor 2640 die eine oder die mehreren MMU(s) 2620A-2620B, den/die Cache(s) 2625A-2625B und die Schaltungszwischenverbindung(en) 2630A-2630B des Grafikprozessors 2610 von 26A. Der Grafikprozessor 2640 beinhaltet einen oder mehrere Shader-Kerne 2655A-2655N (z. B. 2655A, 2655B, 2655C, 2655D, 2655E, 2655F bis 2655N-1 und 2655N), die eine vereinheitlichte Shader-Kern-Architektur bereitstellt, in der ein einziger Kern oder Typ von Kern alle Arten von programmierbarem Shader-Code ausführen kann, einschließlich Shader-Programmcode, um Vertex-Shader, Fragment-Shader und/oder Rechen-Shader zu implementieren. Die genaue Anzahl vorhandener Shader-Kerne kann zwischen Ausführungsformen und Implementierungen variieren. Außerdem beinhaltet der Grafikprozessor 2640 einen Inter-Kern-Aufgabenmanager 2645, der als ein Thread-Dispatcher zum Versenden von Ausführungs-Threads an einen oder mehrere Shader-Kerne 2655A-2655N und eine Kachelungseinheit 2658 zum Beschleunigen von Kacheloperationen für kachelbasiertes Rendering agiert, wobei die Rendering-Operationen für eine Szene in einen Bildraum unterteilt sind, um sich zum Beispiel lokale räumliche Kohärenz innerhalb einer Szene zunutze zu machen oder um die Verwendung von internen Caches zu optimieren. Die Shader-Kerne 2655A-2655N können beispielsweise dem Grafikmultiprozessor 234 wie in 2D oder Grafikmultiprozessoren 325, 350 von 3A bzw. 3B oder der Mehrkerngruppe 365A von 3C entsprechen.
  • In einigen Ausführungsformen repräsentiert eine Verarbeitungsressource ein Verarbeitungselement (z. B. GPGPU-Kern, Strahlverfolgungskern, Tensorkern, Ausführungsressource, Ausführungseinheit (EU), Stream-Prozessor, Streaming-Multiprozessor (SM), Grafikmultiprozesssor), die einem Grafikprozessor oder einer Grafikprozessor-Struktur (z. B. Parallelverarbeitungseinheit, Grafikverarbeitungs-Engine, Mehrkerngruppe, Recheneinheit, Recheneinheit des nächsten Grafikkerns) in einer GPU, wie hierin beschrieben, zugeordnet sind. Die Verarbeitungsressource kann zum Beispiel einer der GPGPU-Kerne oder Tensor-/Strahlverfolgungskerne eines Grafikmultiprozessors; ein Strahlverfolgungskern, Tensorkern oder GPGPU-Kern eines Grafikmultiprozessors; Ausführungsressourcen eines Grafikmultiprozessors; einer aus GFX-Kernen, Tensorkernen oder Strahlverfolgungskernen einer Mehrkerngruppe; eine aus Vektorlogikeinheiten oder Skalarlogikeinheiten einer Recheneinheit; Ausführungseinheit mit EU-Array oder EU-Array; eine Ausführungseinheit einer Ausführungslogik; und/oder eine Ausführungseinheit sein. Die Verarbeitungsressource kann auch eine Ausführungsressource innerhalb zum Beispiel einer Grafikverarbeitungs-Eengine, eines Verarbeitungs-Clusters, einer GPGPU, GPGPU, einer Grafikverarbeitungs-Engine, eines Grafikverarbeitungs-Engine-Clusters und/oder einer Grafikverarbeitungs-Engine sein. Die Verarbeitungsressource kann auch eine Verarbeitungsressource innerhalb eines Grafikprozessors, Grafikprozessors und/oder Grafikprozessors sein.
  • SAMMELN VON NUTZDATEN AUS BELIEBIGEN REGISTERN FÜR SENDE-Nachrichten IN EINER GRAFIKUMGEBUNG
  • Eine Parallelberechnung ist eine Art von Berechnung, bei der viele Berechnungen oder die Ausführung von Prozessen gleichzeitig ausgeführt werden. Die Parallelberechnung kann in einer mehreren Formen vorliegen, einschließlich, jedoch ohne Einschränkung, SIMD oder SIMT. SIMD beschreibt Computer mit mehreren Verarbeitungselementen, die dieselbe Operation auf mehreren Datenpunkten gleichzeitig durchführen. In einem Beispiel beziehen sich die oben erläuterten Figuren auf SIMD und seine Implementierung in einem allgemeinen Prozessor hinsichtlich EUs, FPUs und ALUs. In einer gewöhnlichen SIMD-Maschine werden Daten in Register gepackt, die jeweils ein Array von Kanälen enthalten. Anweisungen arbeiten auf den Daten, die in Kanal n eines Registers gefunden werden, mit den Daten, die in demselben Kanal eines anderen Registers gefunden werden. SIMD-Maschinen sind in Bereichen vorteilhaft, in denen eine einzige Sequenz von Anweisungen gleichzeitig auf hohe Datenmengen angewendet werden kann. In einer Ausführungsform kann zum Beispiel ein Grafikprozessor (z. B. GPGPU, GPU usw.) verwendet werden, um SIMD-Vektoroperationen unter Verwendung von Shader-Berechnungsprogrammen durchzuführen.
  • Verschiedene Ausführungsformen können sich auch dafür entscheiden, Ausführung unter Verwendung von Einzelanweisungs-Multithread (SIMT) als eine Alternative zur Verwendung von SIMD oder zusätzlich zur Verwendung von SIMD zu verwenden. Eine Bezugnahme auf einen SIMD-Kern oder eine SIMD-Operation kann auch für SIMT gelten oder für SIMD in Kombination mit SIMT gelten. Die folgende Beschreibung wird in Bezug auf SIMD-Maschinen erläutert. Ausführungsformen hierin sind jedoch nicht nur auf eine Anwendung im SIMD-Kontext beschränkt und können in anderen parallelen Datenverarbeitungsparadigmen, wie zum Beispiel SIMT, gelten. Zur einfachen Erörterung und Erklärung konzentriert sich die folgende Beschreibung allgemein auf eine SIMD-Implementierung. Ausführungsformen können jedoch gleichermaßen für SIMT-Maschinen ohne Modifikationen an den beschriebenen Techniken und Methodologien gelten. Im Hinblick auf SIMT-Maschinen können ähnliche Muster, wie unten erläutert, befolgt werden, um dem systolischen Array Anweisungen bereitzustellen und die Anweisungen auf der SIMT-Maschine auszuführen. Andere Arten von Parallelrechenmaschinen können auch Ausführungsformen hierin nutzen.
  • Parallele Rendering-Grafikarchitekturen nutzen Kommunikationen zwischen den Ausführungsressourcen (z. B. EUs) und den gemeinsam genutzten Funktionen und/oder Festfunktions-Pipelines, um effiziente parallele Renderberechnungen zu ermöglichen. Solche Kommunikationen zwischen den Ausführungsressourcen und den gemeinsam genutzten Funktionen und/oder festen Funktionen können über Pakete von Informationen erreicht werden, die Nachrichten genannt werden. Eine Nachrichtenübertragung wird unter Verwendung von Sende-Nachrichten-Anweisungen angefordert. Die aktuellen Sende-Nachrichten-Anweisungen erfordern, dass sich die Nutzdaten der Anweisung in zusammenhängenden Registern befindet. Bei herkömmlichen Ansätzen nutzt die Ausführungsressource (z. B. EU) zum Beispiel eine Sende-Nachrichten-Anweisung (z. B. send- oder sendc-Anweisung (wobei sich sende auf eine bedingte Sende-Nachricht bezieht), und diese Sende-Nachrichten-Anweisungen nehmen einen Satz von GRF-Registern und senden diesen Satz von GRF-Registern an eine gemeinsam genutzte Funktion (oder feste Funktion).
  • Um sicherzustellen, dass der Satz von GRF-Registern zusammenhängend ist, implementieren herkömmliche Ansätze zusätzliche Verschiebungsanweisungen (z. B. mov) im Prozessor (z. B. 3D-Shader), um zu veranlassen, dass sich die Nutzdaten in zusammenhängenden Registern (z. B. als Block) befinden. Die Daten, die in dem Block genutzt werden, stammen jedoch häufig aus unterschiedlichen Berechnungsausgaben, die in unterschiedlichen Berechnungsausgaberegistern gefunden werden, die nicht zusammenhängend sind. Zum Beispiel können unterschiedliche FPUs in unterschiedliche Register schreiben. Die Verschiebungsanweisungen der herkömmlichen Ansätze sind ineffizient, da die Verschiebungsanweisungen nichts anderes tun, außer Daten in einem zusammenhängenden Block von GRF-Registern zusammen zu setzen. Eine solche Ineffizienz verbraucht zusätzliche Energie im Prozessor und reduziert die Ausführungseffizienz.
  • Ausführungsformen nehmen die oben genannten Nachteile in Angriff, indem sie eine Sende-Sammel-Nachrichten-Anweisung bereitstellen, um Nutzdaten aus beliebigen Registern für eine Sende-Nachricht in einer Grafikumgebung zu sammeln. Bei Implementierungen hier können sich beliebige Register auf nicht zusammenhängende Register beziehen. Die Verschiebungsanweisungen des herkömmlichen Ansatzes können durch Implementierungen hierin vermieden werden, indem die zusammenhängende Registeranforderung entfernt wird. Implementierungen hierin stellen eine Sende-Sammel-Nachrichten-Anweisung (z. B. sendg/sendgc) bereit, die Nutzdaten aus einem beliebigen Register sammeln kann, das nicht zusammenhängend sein muss. Zum Beispiel kann die Sende-Sammel-Nachrichten-Anweisung von Implementierungen hierin bis zu 16 Register für Nutzdaten der Sende-Nachricht sammeln. Dieser Sende-Sammel-Nachrichten-Anweisung kann auch bis zu 16 Zeiger bereitstellen und kann 16 GRFs von verschiedenen frei wählbaren Positionen sammeln und diese aussenden.
  • Ausführungsformen stellen einen technischen Vorteil zur Verbesserung der Leistungsfähigkeit des Prozessors bereit. Die erörterten Ansätze, um eine Sende-Sammel-Nachrichten-Anweisung bereitzustellen, um Nutzdaten aus beliebigen Registern für eine Sende-Nachricht in einer Grafikumgebung zu sammeln, reduzieren die Menge an Anweisungen in den Ausführungsressourcen (z. B. EUs) der Grafikumgebung, was die Gesamtenergie, die verbraucht wird, indem externe Verschiebungsanweisungen vermieden werden, reduziert. In einigen Implementierungen können die Energieeinsparungen von einer dynamischen Zählung dieser Verschiebungsanweisungen abhängen.
  • 27 ist ein Blockdiagramm, das einen beispielhaften Integrierte-Schaltung-Grafikprozessor 2700 mit einer Ausführungsressource zum Bereitstellen einer Sende-Sammel-Nachrichten-Anweisung zum Sammeln von Nutzdaten aus beliebigen Registern für eine Sende-Nachricht in einer Grafikumgebung gemäß Ausführungsformen veranschaulicht. Bei einer Implementierung kann der Grafikprozessor 2700 eine GPGPU oder GPU beinhalten, wie die hierin mit Bezug auf 1-26 beschrieben beispielhaften GPGPUs und/oder GPUs. Die Elemente von 27 mit den gleichen oder ähnlichen Namen wie die Elemente einer beliebigen anderen Figur hierin beschreiben die gleichen Elemente wie in den anderen Figuren, können auf eine ähnliche Weise wie jene arbeiten oder funktionieren, können die gleichen Komponenten umfassen und können mit anderen Entitäten, wie jenen, die an anderer Stelle hierin beschrieben sind, verknüpft sein, sind aber nicht darauf beschränkt. Der beispielhafte Grafikprozessor 2700 kann eine Variante des Grafikprozessors 1408, 1508, 2510 oder eines beliebigen hierin beschriebenen Grafikprozessors sein und kann anstelle eines beliebigen beschriebenen Grafikprozessors verwendet werden. Die beispielhafte Ausführungsressource 2710 kann eine Variante der Ausführungseinheit 1900 oder einer beliebigen hier beschriebenen Ausführungseinheit oder Verarbeitungsressource sein und kann anstelle einer beliebigen beschriebenen Ausführungsressource verwendet werden. Daher offenbart die Erörterung jeglicher Merkmale in Kombination mit einem Grafikprozessor hierin auch eine entsprechende Kombination mit dem Grafikprozessor 2700, ist aber nicht darauf beschränkt.
  • Der Grafikprozessor 2700, der in 27 veranschaulicht ist, kann einen Shader-Prozessor 2702, einen Thread-Dispatcher 2704, eine Anweisungswarteschlange 2706, eine oder mehrere Ausführungsressourcen 2710, gemeinsam genutzte Funktionen 2760, feste Funktionen 2770, einen Datencache 2780 und einen Datenport 2790 beinhalten. Der Grafikprozessor 2700 kann ähnliche Komponenten beinhalten, wie oben mit Bezug auf die Ausführungslogik 1800 beschrieben, die in 18A beschrieben ist. Die Elemente von 27 mit den gleichen oder ähnlichen Namen wie die Elemente von 18A beschreiben hierin die gleichen Elemente wie in 18A, können auf eine ähnliche Weise wie jene arbeiten oder funktionieren, können die gleichen Komponenten umfassen und können mit anderen Entitäten wie jenen, die an anderer Stelle hierin beschrieben sind, verknüpft sein, sind aber nicht darauf beschränkt. Zur Vereinfachung der Beschreibung und Erklärung gilt die Beschreibung derselben oder ähnlicher Elemente, wie oben in 18A bereitgestellt, gleichermaßen für die Beschreibung derselben oder ähnlicher Elemente von 27 hierin und müssen nicht notwendigerweise wiederholt werden.
  • Der Grafikprozessor 2700, der in 27 veranschaulicht ist, kann eine oder mehrere Ausführungsressourcen 2710 beinhalten. Die Ausführungsressource 2710 kann rechenoptimierte Verarbeitungsressourcen, wie eine EU, zur Verwendung beispielsweise in einer Rechen-Engine-Kachel 1640A-1640D wie in 16C gezeigt sein, ist aber nicht darauf beschränkt. Die Ausführungsressource 2710 kann auch in einer Grafik-Engine-Kachel 1610A-1610D wie in 16B verwendet werden. Die Ausführungsressource 2710 kann einen Thread-Arbiter 2712, einen Thread-Zustand 2714, einen Anweisungsabruf 2716, eine Anweisungsdecodierung 2718, Registerdateien 2720, eine Rechenressource 2730 mit Funktionseinheiten 2735, eine Verzweigungseinheit 2740 und eine Sendeeinheit 2750 beinhalten. Die Ausführungsressourcen 2710 können eine Ausführungsschaltlogik zum Ausführen von Operationen des Grafikprozessors 2700 beinhalten. Die Ausführungsressource 2710 kann ähnliche Komponenten beinhalten, wie oben mit Bezug auf die Ausführungseinheit 1900 beschrieben, die in 19 beschrieben ist. Die Elemente von 27 mit den gleichen oder ähnlichen Namen wie die Elemente von 19 beschreiben hierin die gleichen Elemente wie in 19, können auf eine ähnliche Weise wie jene arbeiten oder funktionieren, können die gleichen Komponenten umfassen und können mit anderen Entitäten wie jenen, die an anderer Stelle hierin beschrieben sind, verknüpft sein, sind aber nicht darauf beschränkt. Zur Vereinfachung der Beschreibung und Erklärung gilt die Beschreibung derselben oder ähnlicher Elemente, wie oben in 19 bereitgestellt, gleichermaßen gilt für die Beschreibung derselben oder ähnlicher Elemente von 27 hierin und müssen nicht notwendigerweise wiederholt werden.
  • Die Ausführungsressource 2710 kann eine Registerdatei 2720 beinhalten, die Register speichert, die Hardware-Threads innerhalb der Ausführungsressource 2710 zugewiesen werden können. Register in der Registerdatei 2720 können über die Logik aufgeteilt werden, die verwendet wird, um mehrere simultane Threads innerhalb der Rechenressource 2730 der Ausführungsressource 2710 auszuführen. Die Anzahl von logischen Threads, die durch die Ausführungsressource 2710 ausgeführt werden können, ist nicht auf die Anzahl von Hardware-Threads beschränkt, und jedem Hardware-Thread können mehrere logische Threads zugewiesen werden. Die Größe der Registerdatei 2720 kann zwischen Ausführungsformen basierend auf der Anzahl unterstützter Hardware-Threads variieren. Eine Registerumbenennung kann verwendet werden, um Register dynamisch Hardware-Threads zuzuordnen.
  • Die Ausführungsressource 2710 kann auch eine Rechenressource 2730 beinhalten, die mehrere unterschiedliche Arten von Funktionseinheiten beinhaltet. Die Rechenressource 2730 kann eine oder mehrere Funktionseinheiten 2735 beinhalten, die zum Beispiel ein Array von arithmetischen Logikeinheiten (ALUs) beinhalten. Die Funktionseinheiten 2735 und/oder ALUs können dazu konfiguriert sein, 64-Bit-, 32-Bit- und 16-Bit-Ganzzahl- und -Gleitkommaoperationen über mehrere Verarbeitungsspuren und Datenkanäle und für mehrere Hardware- und/oder Software-Threads durchzuführen. Die Funktionseinheit 2735 kann Ganzzahl- und Gleitkommaoperationen gleichzeitig durchführen (z. B. innerhalb desselben Taktzyklus).
  • Bei Implementierungen hierin wird der Grafikprozessor 2700 verbessert, um eine Sende-Sammel-Nachrichten-Anweisung bereitzustellen, um Nutzdaten aus beliebigen Registern für eine Sende-Nachricht in einer Grafikumgebung, wie in der hierin erörterten GPU-Umgebung, zu sammeln. Implementierungen hierin stellen eine Sende-Sammel-Nachrichten-Anweisung bereit. Bei einigen Implementierungen werden zwei Sende-Sammel-Nachrichten-Anweisungen bereitgestellt, eine für eine reguläre Sende-Sammel-Nachricht (z. B. sendg) und eine für eine bedingte Sende-Sammel-Nachricht (z. B. sendgc). Eine Nachricht ist ein eigenständiges Paket von Informationen, das von einem Kernel erstellt und an eine spezifische gemeinsam genutzte Funktion, wie die gemeinsam genutzte Funktionen 2760, gerichtet wird. Die Nachricht kann durch einen Satz von GRF-Registern oder Nachrichtenregisterdateien-(MRF)-Registern (Teil der Registerdateien 2720), die Nachrichtenoperanden enthalten, eine Ziel-ID mit gemeinsam genutzter Funktion, eine funktionsspezifische Codierung einer Zieloperation und einen Satz von Ziel-GRF-Registern (Teil von als Registerdateien 2720) definiert werden, an die eine Rückschreibantwort gerichtet werden soll. Die GRF- oder MRF-Register können hier auch als „einzelne Register“ bezeichnet werden. Nachrichten werden unter Softwaresteuerung über eine Sende-Anweisung, wie die hier erörterte Sende-Sammel-Nachrichten-Anweisung, an die gemeinsam genutzte Funktion 2760 versendet. Die Sende-Anweisung identifiziert die Inhalte der Nachricht und die GRF-Registerorte zum Leiten einer beliebigen Antwort.
  • Die durch Implementierungen hierin bereitgestellte Sende-Sammel-Nachricht kann Nutzdaten aus beliebigen Registern der Registerdateien 2720 der Ausführungsressource 2710 sammeln. In einem Ausführungsbeispiel kann die Sende-Sammel-Nachrichten-Anweisung ein 128-Bit-Quellenvektor-(SrcVec)-Feld in der Anweisung verwenden, um bis zu 16 verschiedene Register (8bits pro Register) darzustellen. Die Größe der Sende-Sammel-Nachrichten-Anweisung wird 256 Bits mit dem SrcVec-Feld. Der Compiler sieht die Nachricht als eine 256-Bit-Anweisung. Bei einigen Implementierungen hierin können der Thread-Dispatcher 2704 und die Ausführungsressource 2710 jedoch verbessert werden, um die Sende-Sammel-Nachrichten-Anweisung in zwei Phasen in der Hardware zu lesen, anstatt eine Infrastruktur zum Lesen einer 256-Bit-Anweisung aus der Anweisungswarteschlange 2706 hinzuzufügen. Bei anderen Implementierungen werden der Thread-Dispatcher 2704 und die Ausführungsressource 2710 verbessert, um die Sende-Sammel-Nachrichten-Anweisung in einer einzigen Phase in der Hardware zu lesen, wobei die Anweisung und der Quellenvektor zur gleichen Zeit gelesen und verarbeitet werden.
  • Die Sende-Sammel-Nachrichten-Anweisung wird so formatiert, dass die Anforderungsnachricht keine zusammenhängenden Register 2720 nutzt. Die Nutzdaten der hierin bereitgestellten Sende-Sammel-Nachrichten-Anweisung können in einem beliebigen Satz von beliebigen GRF-Registern 2720 gespeichert werden. Ein Quellenvektorlängenfeld (z. B. SrcVec.Length-Feld) der Sende-Sammel-Nachrichten-Anweisung kann eine Anzahl von GRF-Registern angeben, und ein Quellenvektorfeld (z. B. SrcVec-Feld) kann den Satz einzelner GRF-Register für die Anforderungsnachricht angeben.
  • In einer Ausführungsform ist die Sende-Sammel-Nachrichten-Anweisung formatiert, um ein Architekturregister, wie ein Skalarregister von Registerdateien 2720 der Ausführungsressource 2710, zu nutzen, um die Liste von GRF-Registern 2720 zu speichern (z. B. IDs der GRF-Register in dem Skalarregister zu speichern). In einer Ausführungsform kann die Ausführungsressource 2710 eine oder mehrere Sofortverschiebungsanweisungen ausführen, um die IDs der beliebigen GRF-Register in das Skalarregister zu verschieben. Eine einzige Sofortverschiebungsanweisung kann in der Lage sein, 8 Bytes zu einem Zeitpunkt in das Skalarregister zu verschieben. Dies bedeutet, dass 8 IDs oder Zeiger zu den GRF-Registern 2720 unter Verwendung einer einzigen Sofortverschiebungsanweisung („immediate move“) in das Skalarregister verschoben werden können. Ein Zeiger zu diesem Architekturregister ist dann in der Sende-Sammel-Nachrichten-Anweisung enthalten. In einem Beispiel kann das Quellenvektorfeld (z. B. SrcVec-Feld) der Sende-Sammel-Nachrichten-Anweisung den Zeiger auf das Skalarregister aufweisen.
  • Bei Implementierungen hierin kann der Thread-Dispatcher 2704 die Sende-Sammel-Nachrichten-Anweisung von zum Beispiel einem Shader-Prozessor 2702 empfangen. Der Thread-Dispatcher 2704 kann veranlassen, dass diese Sende-Sammel-Nachrichten-Anweisung zur Verarbeitung an die Ausführungsressource 2710 versendet wird.
  • In einer Ausführungsform kann der Thread-Arbiter 2712 an der Ausführungsressource 2710 einen Sende-Nachrichten-Scheduler 2713 zum Lesen der Sende-Sammel-Nachrichten-Anweisung in zwei Phasen beinhalten. Die erste Phase kann, jedoch ohne Einschränkung, eine Identifikation des Satzes von GRF-Registern oder MRF-Registern, die Nachrichtenoperanden enthalten, die Ziel-ID mit gemeinsam genutzter Funktion, die funktionsspezifische Codierung einer Zieloperation und/oder die Quellenvektorlänge (z. B. SrcVec.Length-Feld) beinhalten. Die erste Phase kann unter Verwendung der Anweisungsdecodierung 2718 decodiert werden, ähnlich wie bei einer herkömmlichen Sende-Nachrichten-Anweisung. Bei Implementierungen hierin kann der Sende-Nachrichten-Scheduler 2713 jedoch veranlassen, dass eine zweite Phase der Sende-Sammel-Nachrichten-Anweisung die Anweisungsdecodierung 2718 hinter der ersten Phase der Sende-Sammel-Nachrichten-Anweisung umgeht. Die zweite Phase kann, jedoch ohne Einschränkung, das Quellenvektorfeld (z. B. SrcVec-Feld) beinhalten, das den Satz einzelner GRF-Register für die Anforderungsnachricht angibt.
  • Der Sende-Nachrichten-Scheduler 2713 des Thread-Arbiters 2712 kann die zwei Phasen der Sende-Sammel-Nachrichten-Anweisung als zwei atomare Anweisungen behandeln. Diese zwei atomaren Anweisungen der Sende-Sammel-Nachrichten-Anweisung können sequenziell, eine nach der anderen, ohne irgendwelche dazwischenliegenden Nachrichten zwischen den zwei Phasen der Anweisung gesendet werden. In einigen Implementierungen können die zwei Phasen der Anweisung in zwei unterschiedlichen Cache-Zeilen sein. Der Sende-Nachrichten-Scheduler 2713 des Thread-Arbiters 2712 sollte die Sende-Sammel-Nachrichten-Anweisung zur Sende-Pipe der Sendeeinheit 2750 planen, nachdem beide Phasen aus der Anweisungswarteschlange 2706 gelesen wurden.
  • In einer Ausführungsform ist ein Einphasenmechanismus implementiert, bei dem der Thread-Dispatcher 2704 und die Ausführungsressource 2710 verbessert sind, um die Sende-Sammel-Nachrichten-Anweisung in einer einzigen Phase in der Hardware zu lesen. Bei dem Einzelphasenansatz werden die Anweisung und der Quellenvektor gleichzeitig gelesen und verarbeitet.
  • Bei Ausführungsformen, die das Architekturregister (z. B. Skalarregister) verwenden, um die IDs (Zeiger) der beliebigen GRF-Register zu speichern, wird ein einzelner Phasenmechanismus implementiert, um die Sende-Sammel-Nachrichten-Anweisung in einer einzigen Phase in der Hardware zu lesen.
  • 28A veranschaulicht einen Satz von Anweisungen 2800, die durch eine Verarbeitungseinheit ausführbar sind, gemäß hierin beschriebenen Ausführungsformen. 28A veranschaulicht Felder der Anweisung 2800 zum Durchführen einer Sende-Sammel-Nachrichten-Operation. Die Anweisung 2800 beinhaltet, jedoch ohne Einschränkung, eine Senden-Sammel-Nachrichten-Anweisung. Andere Sende-Sammel-Nachrichten-Anweisungen können auch durch Ausführungsformen implementiert werden.
  • Die Sende-Sammel-Nachrichten-Anweisung 2800 ist durch eine Verarbeitungseinheit wie eine VPU oder FPU ausführbar, die durch eine Ausführungsform bereitgestellt wird. 28A veranschaulicht Felder der Senden-Sammel-Nachrichten-Anweisung 2800, die, wenn sie ausgeführt wird, eine Verarbeitungseinheit veranlasst, eine Anweisung auszuführen, um unter Verwendung spezifizierter Operanden Senden-Sammel-Nachrichten-Operationen durchzuführen. In einer Ausführungsform beinhaltet der Befehl 2800 ein Opcode-Feld 2802 und Operandenfelder zum Spezifizieren eines Ziels (dst) 2804, einer Quellenvektorlänge (SrcVec Length) 2806, einer Ziel-ID mit gemeinsam genutzter Funktion (ex_desc) 2808 und eines Quellenvektors (SrcVec) 2810.
  • Das Opcode-Feld 2802 kann einen Opcode spezifizieren, der die Anweisung 2800 für die Ausführungslogik identifiziert. In einer Ausführungsform weist das Opcode-Feld 2802 ein oder mehrere Bits auf, die, wenn sie aktiviert sind, angeben, dass die Anweisung von einer Verarbeitungseinheit eines Rechenblocks (z. B. Rechenblock 1424) ausgeführt werden soll. In einer Ausführungsform identifiziert das Opcode-Feld 2802 den Opcode für die Sende-Sammel-Nachrichten-(sendg)-Anweisung.
  • Das Ziel (dst) 2804 kann verwendet werden, um ein Ziel zu spezifizieren, um einen GRF-Registerort für eine Antwortnachricht bereitzustellen, falls vorhanden, und Parameter bereitzustellen, um Kanalfreigabe-Seitenbandsignale zu bilden. Die Quellenvektorlänge (SrcVec Length) 2806 kann verwendet werden, um eine Anzahl von GRF-Registern für die Nutzdaten anzugeben. Die Ziel-ID mit gemeinsam genutzter Funktion (ex_desc) 2808 kann verwendet werden, um eine Zielfunktions-ID (z. B. gemeinsam genutzte Funktion (SFID) für die Sende-Sammel-Nachricht zu spezifizieren. Der Quellenvektor (SrcVec) 2810 kann verwendet werden, um die tatsächlichen einzelnen GRF-Register für die Sende-Sammel-Nachricht anzugeben.
  • 28B veranschaulicht einen Programmcode-Kompilierungsprozess 2815 gemäß einer Ausführungsform. In einer Ausführungsform wird eine Quellcodeebenenbeschreibung 2820 eines Softwareprogramms an einem Compiler 2830 kompiliert, der mehrere Ebenen von Kompilierungen beinhalten kann, auf eine Ebene mit einer Operation 2840, die einen durch die Verarbeitungslogik auszuführenden Sende-Sammel-Nachrichtenbefehl beinhaltet oder spezifiziert. Die Sende-Sammel-Nachricht kann eine Sende-Nachricht aufweisen, die Nutzdaten aus beliebigen Registern sammelt, die nicht zusammenhängend sein müssen. Wie oben erörtert, identifiziert die Sende-Sammel-Nachricht selbst jedes beliebige Register, das zum Sammeln der Nutzdaten verwendet wird, sowie die Anzahl von Registern, die für das Sammeln von Nutzdaten verwendet werden.
  • Die Operation 2840 kann eine Operation sein, die in einer Zwischensprache spezifiziert ist, oder kann Programmcode sein, der auf ein Primitiv eines Rechen-Framework verweist, wie ein Primitiv, das von einem Maschinenlern-Framework bereitgestellt wird. Die Operation 2840, die eine Sende-Sammel-Nachrichten-Anweisung beinhaltet oder spezifiziert, kann dann ferner durch einen zusätzlichen Compiler 2850 kompiliert werden, der ein Shader-Compiler in den Objektcode 2860 auf Maschinenebene sein kann, der eine Sende-Sammel-Anweisung beinhaltet, der durch eine Verarbeitungseinheit (z. B. VPU, FPU) eines Rechenblocks durchzuführen ist, wie hier beschrieben.
  • 29 ist ein Flussdiagramm, das eine Ausführungsform eines Verfahrens 2900 zum Ausführen einer Anweisung zum Durchführen des Sammelns von Nutzdaten aus beliebigen Registern für Sende-Nachrichten in einer Grafikumgebungveranschaulicht. Das Verfahren 2900 kann von einer Verarbeitungslogik durchgeführt werden, die Hardware (z. B. eine Schaltung, dedizierte Logik, programmierbare Logik usw.), Software (wie auf einer Verarbeitungsvorrichtung ausgeführte Anweisungen) oder eine Kombination davon umfassen kann. Der Prozess des Verfahrens 2900 wird der Kürze und Klarheit der Darstellung halber in linearen Sequenzen dargestellt; es wird jedoch in Betracht gezogen, dass eine beliebige Anzahl von ihnen parallel, asynchron oder in verschiedenen Reihenfolgen ausgeführt werden kann. Ferner werden der Kürze, Klarheit und dem leichten Verständnis halber viele der mit Bezug auf 1-28 beschriebenen Komponenten und Prozesse möglicherweise nicht wiederholt oder im Folgenden erläutert. Bei einer Implementierung kann ein Prozessor, wie ein Prozessor 2700 von 27 das Verfahren 2900 durchführen.
  • Das Verfahren 2900 beginnt bei Verarbeitungsblock 2910, bei dem eine einzelne Anweisung abgerufen und decodiert wird, um innerhalb einer GPGPU ausgeführt zu werden. Bei einer Implementierung wird die einzelne Anweisung in eine decodierte Anweisung decodiert, um die GPGPU zu veranlassen, eine Sende-Sammel-Nachrichten-Operation durchzuführen. Bei Verarbeitungsblock 2920 wird ein Satz von Befehlen bestimmt, um die decodierte Vektoranweisung auf einem Rechenblock der GPGPU auszuführen.
  • Anschließend wird bei Verarbeitungsblock 2930 der Satz von Befehlen in einen Rechenblock der GPGPU geplant, um die decodierte Anweisung auszuführen, um die Sende-Sammel-Nachrichten-Operation durchzuführen. Schließlich wird bei Verarbeitungsblock 2940 der decodierte Befehl als Reaktion auf das Abschließen des Satzes von Befehlen zurückgezogen.
  • 30 ist ein Flussdiagramm, das eine Ausführungsform eines Verfahrens 3000 zum Planen einer Sende-Sammel-Nachricht veranschaulicht, die Nutzdaten aus beliebigen Registern in einer Grafikumgebung sammelt. Das Verfahren 3000 kann von einer Verarbeitungslogik durchgeführt werden, die Hardware (z. B. eine Schaltung, dedizierte Logik, programmierbare Logik usw.), Software (wie auf einer Verarbeitungsvorrichtung ausgeführte Anweisungen) oder eine Kombination davon umfassen kann. Der Prozess des Verfahrens 3000 wird der Kürze und Klarheit der Darstellung halber in linearen Sequenzen dargestellt; es wird jedoch in Betracht gezogen, dass eine beliebige Anzahl von ihnen parallel, asynchron oder in verschiedenen Reihenfolgen ausgeführt werden kann. Ferner werden der Kürze, Klarheit und dem leichten Verständnis halber viele der mit Bezug auf 1-29 beschriebenen Komponenten und Prozesse möglicherweise nicht wiederholt oder im Folgenden erläutert. Bei einer Implementierung kann ein Prozessor, wie ein Prozessor 2700 von 27 das Verfahren 3000 durchführen.
  • Das Verfahren 3000 beginnt bei Verarbeitungsblock 3010, bei dem der Prozessor an einer Ausführungsressource einer GPU eine Sende-Sammel-Nachrichten-Anweisung empfangen kann, die eine Anzahl von GRF-Registern identifiziert, um auf eine Sende-Nachricht zuzugreifen, und IDs mehrerer einzelner GRF-Register, die der Anzahl von GRF-Registern entsprechen, identifizieren kann. Dann kann der Prozessor bei Block 3020 eine erste Phase der Sende-Sammel-Nachrichten-Anweisung an der Ausführungsressource decodieren.
  • Anschließend kann der Prozessor bei Block 3030 basierend auf dem Decodieren der ersten Phase der Sende-Sammel-Nachricht veranlassen, dass eine zweite Phase der Sende-Sammel-Nachricht eine Anweisungsdecodierungsstufe der Ausführungsressource umgeht. Schließlich kann der Prozessor bei Block 3040 die erste Phase der Sende-Sammel-Nachricht, anschließend gefolgt vom Versenden der zweiten Phase der Sende-Sammel-Nachricht an eine Sende-Pipeline der Ausführungsressource versenden. Bei einer Ausführungsform wird das Versenden der ersten Phase und der zweiten Phase der Sende-Sammel-Nachricht an die Sende-Pipeline ohne irgendwelche dazwischenliegenden versandten Nachrichten zwischen der ersten Phase und der zweiten Phase in der Sende-Pipeline gesendet.
  • Wie zuvor angemerkt, können Implementierungen anstelle des oben erläuterten Zweiphasenansatzes einen Einzelphasenmechanismus implementieren. Bei dem Einzelphasenansatz werden der Thread-Dispatcher und die Ausführungsressource verbessert, um die Sende-Sammel-Nachrichten-Anweisung in einer einzigen Phase in der Hardware zu lesen. Bei dem Einzelphasenansatz werden der Befehl und der Quellenvektor gleichzeitig gelesen und verarbeitet.
  • 31 ist ein Flussdiagramm, das eine Ausführungsform eines Verfahrens 3000 zum Planen einer Sende-Sammel-Nachricht unter Verwendung eines Architekturregisters veranschaulicht, um Nutzdaten aus beliebigen Registern in einer Grafikumgebung zu sammeln. Das Verfahren 3100 kann von einer Verarbeitungslogik durchgeführt werden, die Hardware (z. B. Schaltlogik, dedizierte Logik, programmierbare Logik usw.), Software (wie Anweisungen, die auf einer Verarbeitungsvorrichtung ausgeführt werden) oder eine Kombination davon umfassen kann. Der Prozess des Verfahrens 3100 wird der Kürze und Klarheit der Darstellung halber in linearen Sequenzen dargestellt; es wird jedoch in Betracht gezogen, dass eine beliebige Anzahl von ihnen parallel, asynchron oder in verschiedenen Reihenfolgen ausgeführt werden kann. Ferner werden der Kürze, Klarheit und dem leichten Verständnis halber viele der mit Bezug auf 1-20 beschriebenen Komponenten und Prozesse möglicherweise nicht wiederholt oder im Folgenden erläutert. Bei einer Implementierung kann ein Prozessor, wie ein Prozessor 2700 aus 27 das Verfahren 3100 durchführen.
  • Das Verfahren 3100 beginnt bei Verarbeitungsblock 3110, bei dem der Prozessor an einer Ausführungsressource einer GPU eine Sende-Sammel-Nachrichten-Anweisung empfangen kann, die eine Anzahl von GRF-Registern zum Zugreifen auf eine Sende-Nachricht identifiziert und IDs mehrerer einzelner GRF-Register, die der Anzahl von GRF-Registern entsprechen, identifiziert. Bei Block 3120 kann die Verarbeitung ein sofortiges Verschieben der IDs der mehreren einzelnen GRF-Register zu einem Architekturregister der Ausführungsressource durchführen.
  • Anschließend kann der Prozessor bei Block 3130 einen Zeiger zu dem Architekturregister in der Sende-Sammel-Nachrichten-Anweisung aufweisen. Schließlich kann der Prozessor bei Block 3140 die Sende-Sammel-Nachrichten-Anweisung an eine Sende-Pipeline der Ausführungsressource versenden.
  • Die folgenden Beispiele betreffen weitere Ausführungsformen. Beispiel 1 ist eine Vorrichtung zum Ermöglichen des Sammelns von Nutzdaten aus beliebigen Registern für Sende-Nachrichten in einer Grafikumgebung. Die Einrichtung von Beispiel 1 beinhaltet einen Prozessor zum Bereitstellen von Verarbeitungsressourcen, die eine Ausführungsschaltlogik umfassen zum: Empfangen einer Sende-Sammel-Nachrichten-Anweisung, die eine Anzahl von Registern zum Zugreifen auf eine Sende-Nachricht identifiziert und IDs mehrerer einzelner Register, die der Anzahl von Registern entsprechen, identifiziert; Decodieren einer ersten Phase der Sende-Sammel-Nachrichten-Anweisung; basierend auf dem Decodieren der ersten Phase der Sende-Sammel-Nachrichtenanweisung, Veranlassen, dass eine zweite Phase der Sende-Sammel-Nachrichten-Anweisung eine Anweisungsdecodierungsstufe der Ausführungsschaltlogik umgeht; und Versenden der ersten Phase der Sende-Sammel-Nachrichten-Anweisung, anschließend gefolgt vom Versenden der zweiten Phase der Sende-Sammel-Nachrichten-Anweisung an eine Sende-Pipeline der Ausführungsschaltlogik.
  • In Beispiel 2 kann der Gegenstand von Beispiel 1 optional beinhalten, dass das Versenden der ersten Phase und der zweiten Phase der Sende-Sammel-Nachrichten-Anweisung ohne irgendwelche dazwischenliegenden versandten Nachrichten zwischen der ersten Phase und der zweiten Phase in der Sende-Pipeline versendet werden. Bei Beispiel 3 kann der Gegenstand eines der Beispiele 1-2 optional beinhalten, dass die mehreren einzelnen Register allgemeine Registerdateiregister (GRF-Register) umfassen. In Beispiel 4 kann der Gegenstand eines der Beispiele 1-3 optional Folgendes beinhalten: wobei die zweite Phase der Sende-Sammel-Nachrichten-Anweisung die IDs der mehreren einzelnen Register umfasst.
  • In Beispiel 5 kann der Gegenstand eines der Beispiele 1-4 optional beinhalten, dass die erste Phase der Sende-Sammel-Nachrichten-Anweisung die Anzahl der Register identifiziert, auf die für die Sende-Nachricht zuzugreifen ist. In Beispiel 6 kann der Gegenstand eines der Beispiele 1-5 optional beinhalten, dass die mehreren einzelnen Register nicht zusammenhängend sind. In Beispiel 7 kann der Gegenstand eines der Beispiele 1-6 optional beinhalten, dass die erste Phase der Sende-Sammel-Nachrichten-Anweisung eine Ziel-ID mit gemeinsam genutzter Funktion, eine funktionsspezifische Codierung einer Operation der Sende-Sammel-Nachrichten-Anweisung und ein Zielregister für eine Rückschreibantwort auf die Sende-Sammel-Nachrichten-Anweisung identifiziert.
  • In Beispiel 8 kann der Gegenstand eines der Beispiele 1-7 optional beinhalten, dass der Prozessor eine Grafikverarbeitungseinheit (GPU) umfasst. In Beispiel 9 kann der Gegenstand eines der Beispiele 1-8 optional beinhalten , dass der Prozessor mindestens eines von einer SIMD-(Single Instruction Multiple Data)-Maschine oder einer SIMT-(Single Instruction Multiple Thread)-Maschine ist.
  • Beispiel 10 ist ein Verfahren zum Ermöglichen des Sammelns von Nutzdaten aus beliebigen Registern für Sende-Nachrichten in einer Grafikumgebung. Das Verfahren von Beispiel 10 kann das Empfangen, durch die Ausführungsschaltlogik eines Grafikprozessors, einer Sende-Sammel-Nachrichten-Anweisung, die eine Anzahl von Registern zum Zugreifen auf eine Sende-Nachricht identifiziert und IDs mehrerer einzelner Register identifiziert, die der Anzahl von Registern entsprechen; Decodieren einer ersten Phase der Sende-Sammel-Nachrichten-Anweisung; basierend auf dem Decodieren der ersten Phase der Sende-Sammel-Nachrichten-Anweisung, Veranlassen, dass eine zweite Phase der Sende-Sammel-Nachrichten-Anweisung eine Anweisungsdecodierungsstufe der Ausführungsschaltung umgeht; und Senden der ersten Phase der Sende-Sammel-Nachrichten-Anweisung, anschließend gefolgt vom Versenden der zweiten Phase der Sende-Sammel-Nachrichten-Anweisung an eine Sende-Pipeline der Ausführungsschaltlogik beinhaltet.
  • In Beispiel 11 kann der Gegenstand von Beispiel 10 optional beinhalten, dass das Versenden der ersten Phase und der zweiten Phase der Sende-Sammel-Nachrichten-Anweisung ohne irgendwelche dazwischenliegenden versandten Nachrichten zwischen der ersten Phase und der zweiten Phase in der Sende-Pipeline versendet werden. In Beispiel 12 kann der Gegenstand der Beispiele 10-11 optional beinhalten , dass die mehreren einzelnen Registern allgemeine Registerdateiregister (GRF-Register) umfassen.
  • In Beispiel 13 kann der Gegenstand der Beispiele 10-12 optional beinhalten, dass die erste Phase der Sende-Sammel-Nachrichten-Anweisung die Anzahl der Register identifiziert, auf die für die Sende-Nachricht zuzugreifen ist, und wobei die zweite Phase der Sende-Sammel-Nachrichten-Anweisung die IDs der mehreren einzelnen Register umfasst. In Beispiel 14 kann der Gegenstand der Beispiele 10-13 optional beinhalten, dass die mehreren einzelnen Register nicht zusammenhängend sind. In Beispiel 15 kann der Gegenstand der Beispiele 10-14 optional beinhalten, dass die erste Phase der Sende-Sammel-Nachrichten-Anweisung eine Ziel-ID mit gemeinsam genutzter Funktion, eine funktionsspezifische Codierung einer Operation der Sende-Sammel-Nachrichten-Anweisung und ein Zielregister für eine Rückschreibantwort auf die Sende-Sammel-Nachrichtenanweisung identifiziert.
  • Beispiel 16 ist ein System zum Ermöglichen des Sammelns von Nutzdaten aus beliebigen Registern für Sende-Nachrichten in einer Grafikumgebung. Das System von Beispiel 21 kann optional einen Speicher zum Speichern eines Datenblocks; und einen Prozessor, der mit dem Speicher gekoppelt ist, beinhalten, wobei der Prozessor Verarbeitungsressourcen umfasst, wobei die Verarbeitungsressourcen eine Ausführungsschaltlogik umfassen zum: Empfangen einer Sende-Sammel-Nachrichten-Anweisung, die eine Anzahl von Registern zum Zugreifen auf eine Sende-Nachricht identifiziert und IDs mehrerer einzelner Register identifiziert, die der Anzahl von Registern entsprechen; Durchführen einer sofortigen Verschiebung der IDs der mehreren einzelnen Register in ein Architekturregister der Ausführungsschaltlogik; Einschließen eines Zeigers auf das Architekturregister in der Sende-Sammel-Nachrichten-Anweisung; und Versenden der Sende-Sammel-Nachrichten-Anweisung an eine Sende-Pipeline der Ausführungsschaltlogik.
  • In Beispiel 17 kann der Gegenstand von Beispiel 16 optional beinhalten , dass das Architekturregister ein Skalarregister ist. In Beispiel 18 kann der Gegenstand der Beispiele 16-17 optional beinhalten, dass die Sende-Sammel-Nachrichten-Anweisung die Anzahl der Register identifiziert, auf die für die Sende-Sammel-Nachrichten-Anweisung und das Architekturregister zuzugreifen ist.
  • In Beispiel 19 kann der Gegenstand von Beispiel 16-18 optional beinhalten, dass die mehreren einzelnen Register nicht zusammenhängend sind und die IDs Zeiger umfassen. In Beispiel 20 kann der Gegenstand der Beispiele 16-19 optional beinhalten, dass die Sende-Sammel-Nachrichten-Anweisung eine Ziel-ID mit gemeinsam genutzter Funktion, eine funktionsspezifische Codierung einer Operation der Sende-Sammel-Nachrichten-Anweisung und ein Zielregister für eine Rückschreibantwort auf die Sende-Sammel-Nachrichten-Anweisung identifiziert.
  • Beispiel 21 ist ein System zum Ermöglichen des Sammelns von Nutzdaten aus beliebigen Registern für Sende-Nachrichten in einer Grafikumgebung. Das System von Beispiel 21 kann optional einen Speicher zum Speichern eines Datenblocks und einen Prozessor beinhalten, der kommunikativ mit dem Speicher gekoppelt ist zum: Empfangen einer Sende-Sammel-Nachrichten-Anweisung, die eine Anzahl von Registern zum Zugreifen auf eine Sende-Nachricht identifiziert und IDs mehrerer einzelner Register, die der Anzahl von Registern entsprechen, identifiziert; Decodieren einer ersten Phase der Sende-Sammel-Nachrichten-Anweisung; basierend auf dem Decodieren der ersten Phase der Sende-Sammel-Nachrichten-Anweisung, Veranlassen, dass eine zweite Phase der Sende-Sammel-Nachrichten-Anweisung eine Anweisungsdecodierungsstufe der Ausführungsschaltlogik umgeht; und Versenden der ersten Phase der Sende-Sammel-Nachrichten-Anweisung, anschließend gefolgt vom Versenden der zweiten Phase der Sende-Sammel-Nachrichten-Anweisung an eine Sende-Pipeline der Ausführungsschaltlogik.
  • In Beispiel 22 kann der Gegenstand von Beispiel 21 optional beinhalten, dass das Versenden der ersten Phase und der zweiten Phase der Sende-Sammel-Nachrichten-Anweisung ohne irgendwelche dazwischenliegenden versandten Nachrichten zwischen der ersten Phase und der zweiten Phase in der Sende-Pipeline versendet werden. Bei Beispiel 23 kann der Gegenstand eines der Beispiele 21-22 optional beinhalten, dass die mehreren einzelnen Register allgemeine Registerdateiregister (GRF-Register) umfassen. In Beispiel 24 kann der Gegenstand eines der Beispiele 21-23 optional Folgendes beinhalten: wobei die zweite Phase der Sende-Sammel-Nachrichten-Anweisung die IDs der mehreren einzelnen Register umfasst.
  • In Beispiel 25 kann der Gegenstand eines der Beispiele 21-24 optional beinhalten, dass die erste Phase der Sende-Sammel-Nachrichten-Anweisung die Anzahl der Register identifiziert, auf die für die Sende-Nachricht zuzugreifen ist. In Beispiel 26 kann der Gegenstand eines der Beispiele 21-25 optional beinhalten, dass die mehreren einzelnen Register nicht zusammenhängend sind. In Beispiel 27 kann der Gegenstand eines der Beispiele 21-26 optional beinhalten, dass die erste Phase der Sende-Sammel-Nachrichten-Anweisung eine Ziel-ID mit gemeinsam genutzter Funktion, eine funktionsspezifische Codierung einer Operation der Sende-Sammel-Nachrichten-Anweisung und ein Zielregister für eine Rückschreibantwort auf die Sende-Sammel-Nachrichten-Anweisung identifiziert.
  • In Beispiel 28 kann der Gegenstand aus einem der Beispiele 21-27 optional beinhalten, dass der Prozessor eine Grafikverarbeitungseinheit (GPU) umfasst. In Beispiel 29 kann der Gegenstand eines der Beispiele 21-28 optional beinhalten , dass der Prozessor mindestens eine von einer SIMD-(Single Instruction Multiple Data)-Maschine oder einer SIMT-(Single Instruction Multiple Thread)-Maschine ist.
  • Beispiel 30 ist ein Verfahren zum Ermöglichen des Sammelns von Nutzdaten aus beliebigen Registern für Sende-Nachrichten in einer Grafikumgebung. Das Verfahren von Beispiel 30 kann das Empfangen einer Sende-Sammel-Nachrichten-Anweisung beinhalten, die eine Anzahl von Registern zum Zugreifen auf eine Sende-Nachricht identifiziert und IDs mehrerer einzelner Register entsprechend der Anzahl von Registern identifiziert; Durchführen einer sofortigen Verschiebung der IDs der mehreren einzelnen Register in ein Architekturregister der Ausführungsschaltlogik; Einschließen eines Zeigers auf das Architekturregister in der Sende-Sammel-Nachrichten-Anweisung; und Versenden der Sende-Sammel-Nachrichten-Anweisung an eine Sende-Pipeline der Ausführungsschaltung beinhalten.
  • In Beispiel 31 kann der Gegenstand von Beispiel 30 optional beinhalten , dass das Architekturregister ein Skalarregister ist. In Beispiel 32 kann der Gegenstand der Beispiele 30-31 optional beinhalten, dass die Sende-Sammel-Nachrichten-Anweisung die Anzahl der Register identifiziert, auf die für die Anweisung zum Senden von Sammelnachrichten und das Architekturregister zuzugreifen ist.
  • In Beispiel 33 kann der Gegenstand von Beispiel 30-32 optional beinhalten, dass die mehreren einzelnen Register nicht zusammenhängend sind und die IDs Zeiger umfassen. In Beispiel 34 kann der Gegenstand der Beispiele 30-33 optional beinhalten, dass die Sende-Sammel-Nachrichten-Anweisung eine Ziel-ID mit gemeinsam genutzter Funktion, eine funktionsspezifische Codierung einer Operation der Sende-Sammel-Nachrichten-Anweisung und ein Zielregister für eine Rückschreibantwort auf die Sende-Sammel-Nachrichten-Anweisung identifiziert.
  • Beispiel 35 ist eine Einrichtung zum Ermöglichen des Sammelns von Nutzdaten aus beliebigen Registern für Sende-Nachrichten in einer Grafikumgebung, umfassend Mittel zum Empfangen, über eine Ausführungsschaltlogik eines Grafikprozessors, einer Sende-Sammel-Nachrichten-Anweisung, die eine Anzahl von Registern zum Zugreifen auf eine Sende-Nachricht identifiziert und IDs mehrerer einzelner Register identifiziert, die der Anzahl von Registern entsprechen; Mittel zum Decodieren einer ersten Phase der Sende-Sammel-Nachrichten-Anweisung; basierend auf dem Decodieren der ersten Phase der Sende-Sammel-Nachrichten-Anweisung, Mittel zum Veranlassen, dass eine zweite Phase der Sende-Sammel-Nachrichten-Anweisung eine Anweisungsdecodierungsstufe der Ausführungsschaltlogik umgeht; und Mittel zum Versenden der ersten Phase der Sende-Sammel-Nachrichten-Anweisung, anschließend gefolgt vom Versenden der zweiten Phase der Sende-Sammel-Nachrichten-Anweisung an eine Sende-Pipeline der Ausführungsschaltlogik. In Beispiel 36 kann der Gegenstand des Beispiels 35 optional einschließen, dass die Einrichtung ferner konfiguriert ist, um das Verfahren nach einem der Beispiele 12 bis 16 durchzuführen.
  • Beispiel 37 ist mindestens ein maschinenlesbares Medium, umfassend mehrere Anweisungen, die als Reaktion auf das Ausführen auf einer Datenverarbeitungsvorrichtung die Datenverarbeitungsvorrichtung veranlassen, ein Verfahren nach einem der Beispiele 11-16 durchzuführen. Beispiel 38 ist eine Einrichtung zum Ermöglichen des Sammelns von Nutzdaten aus beliebigen Registern für Sende-Nachrichten in einer Grafikumgebung, die dazu konfiguriert ist, das Verfahren nach einem der Beispiele 11 bis 16 durchzuführen. Beispiel 39 ist eine Einrichtung zum Ermöglichen des Sammelns von Nutzdaten aus beliebigen Registern für Sende-Nachrichten in einer Grafikumgebung, umfassend Mittel zum Durchführen des Verfahrens nach einem der Ansprüche 11 bis 16. Einzelheiten in den Beispielen können überall in einer oder mehreren Ausführungsformen verwendet werden.
  • Beispiel 40 ist eine Einrichtung zum Ermöglichen des Sammelns von Nutzdaten aus beliebigen Registern für Sende-Nachrichten in einer Grafikumgebung, umfassend Mittel zum Empfangen einer Sende-Sammel-Nachrichten-Anweisung, die eine Anzahl von Registern zum Zugreifen auf eine Sende-Nachricht identifiziert und IDs mehrerer einzelner Register identifiziert, die der Anzahl von Registern entsprechen; Mittel zum Durchführen einer sofortigen Verschiebung der IDs der mehreren einzelnen Registern in ein Architekturregister der Ausführungsschaltlogik; Mittel zum Einschließen eines Zeigers auf das Architekturregister in der Sende-Sammel-Nachrichten-Anweisung; und Mittel zum Versenden der Sende-Sammel-Nachrichten-Anweisung an eine Sende-Pipeline der Ausführungsschaltlogik. In Beispiel 41 kann der Gegenstand des Beispiels 40 optional einschließen, dass die Einrichtung ferner konfiguriert ist, um das Verfahren nach einem der Beispiele 31 bis 34 durchzuführen.
  • Beispiel 42 ist mindestens ein maschinenlesbares Medium, umfassend mehrere Anweisungen, die als Reaktion auf das Ausführen auf einer Datenverarbeitungsvorrichtung die Datenverarbeitungsvorrichtung veranlassen, ein Verfahren nach einem der Beispiele 30-34 durchzuführen. Beispiel 43 ist eine Einrichtung zum Ermöglichen des Sammelns von Nutzdaten aus beliebigen Registern für Sende-Nachrichten in einer Grafikumgebung, die dazu konfiguriert ist, das Verfahren nach einem der Beispiele 30 bis 34 durchzuführen. Beispiel 44 ist eine Einrichtung zum Ermöglichen des Sammelns von Nutzdaten aus beliebigen Registern für Sende-Nachrichten in einer Grafikumgebung, umfassend Mittel zum Durchführen des Verfahrens nach einem der Ansprüche 30 bis 34. Spezifische Einzelheiten in den Beispielen können überall in einer oder mehreren Ausführungsformen verwendet werden.
  • Die vorstehende Beschreibung und Zeichnungen sind in einem veranschaulichenden und nicht einschränkenden Sinne zu betrachten. Fachleute können verstehen, dass verschiedene Modifikationen und Änderungen an den hierin beschriebenen Ausführungsformen vorgenommen werden können, ohne vom breiteren Gedanken und Schutzumfang der in den beigefügten Ansprüchen dargelegten Merkmale abzuweichen.

Claims (23)

  1. Prozessor, der Folgendes umfasst: Verarbeitungsressourcen, die eine Ausführungsschaltlogik umfassen, zum: Empfangen einer Sende-Sammel-Nachrichten-Anweisung, die eine Anzahl von Registern zum Zugreifen auf eine Sende-Nachricht identifiziert und IDs mehrerer einzelner Register, die der Anzahl von Registern entsprechen, identifiziert; Decodieren einer ersten Phase der Sende-Sammel-Nachrichten-Anweisung; Basierend auf dem Decodieren der ersten Phase der Sende-Sammel-Nachrichten-Anweisung, Veranlassen, dass eine zweite Phase der Sende-Sammel-Nachrichten-Anweisung eine Anweisungsdecodierungsstufe der Ausführungsschaltlogik umgeht; und Versenden der ersten Phase der Sende-Sammel-Nachrichten-Anweisung, anschließend gefolgt vom Versenden der zweiten Phase der Sende-Sammel-Nachrichten-Anweisung an eine Sende-Pipeline der Ausführungsschaltlogik.
  2. Prozessor nach Anspruch 1, wobei das Versenden der ersten Phase und der zweiten Phase der Sende-Sammel-Nachrichten-Anweisung ohne irgendwelche dazwischenliegenden versandten Nachrichten zwischen der ersten Phase und der zweiten Phase in der Sende-Pipeline an die Sende-Pipeline versendet werden.
  3. Prozessor nach Anspruch 1, wobei die mehreren einzelnen Register allgemeine Registerdateiregister (GRF-Register) umfassen.
  4. Prozessor nach Anspruch 1, wobei die zweite Phase der Sende-Sammel-Nachrichten-Anweisung die IDs der mehreren einzelnen Register umfasst.
  5. Prozessor nach Anspruch 1, wobei die erste Phase der Sende-Sammel-Nachrichten-Anweisung die Anzahl der Register identifiziert, auf die für die Sende-Nachricht zugegriffen werden soll.
  6. Prozessor nach Anspruch 1, wobei die mehreren einzelnen Register nicht zusammenhängend ist.
  7. Prozessor nach Anspruch 1, wobei die erste Phase der Sende-Sammel-Nachrichten-Anweisung eine Ziel-ID mit gemeinsam genutzter Funktion, eine funktionsspezifische Codierung einer Operation der Sende-Sammel-Nachrichten-Anweisung und ein Zielregister für eine Rückschreibantwort auf die Sende-Sammel-Nachrichten-Anweisung identifiziert.
  8. Prozessor nach Anspruch 1, wobei der Prozessor eine Grafikverarbeitungseinheit (GPU) umfasst.
  9. Prozessor nach Anspruch 1, wobei der Prozessor mindestens eine von einer SIMD-Maschine (Single Instruction Multiple Data-Maschine) oder einer SIMT-Maschine (Single Instruction Multiple Thread-Maschine) ist.
  10. Verfahren, das Folgendes umfasst: Empfangen, von der Ausführungsschaltlogik eines Grafikprozessors, einer Sende-Sammel-Nachrichten-Anweisung, die eine Anzahl von Registern identifiziert, auf die für eine Sende-Nachricht zuzugreifen ist, und IDs mehrerer einzelner Register identifiziert, die der Anzahl von Registern entsprechen; Decodieren einer ersten Phase der Sende-Sammel-Nachrichten-Anweisung; basierend auf dem Decodieren der ersten Phase der Sende-Sammel-Nachrichten-Anweisung, Veranlassen, dass eine zweite Phase der Sende-Sammel-Nachrichten-Anweisung eine Anweisungsdecodierungsstufe der Ausführungsschaltlogik umgeht; und Versenden der ersten Phase der Sende-Sammel-Nachrichten-Anweisung, anschließend gefolgt vom Versenden der zweiten Phase der Sende-Sammel-Nachrichten-Anweisung an eine Sende-Pipeline der Ausführungsschaltlogik.
  11. Verfahren nach Anspruch 10, wobei das Versenden der ersten Phase und der zweiten Phase der Sende-Sammel-Nachrichten-Anweisung ohne irgendwelche dazwischenliegenden versandten Nachrichten zwischen der ersten Phase und der zweiten Phase in der Sende-Pipeline an die Sende-Pipeline versendet werden.
  12. Verfahren nach Anspruch 10, wobei die mehreren einzelnen Register allgemeine Registerdateiregister (GRF-Register) umfassen.
  13. Verfahren nach Anspruch 10, wobei die erste Phase der Sende-Sammel-Nachrichten-Anweisung die Anzahl der Register identifiziert, auf die für die Sende-Nachricht zugegriffen werden soll, und wobei die zweite Phase der Sende-Sammel-Nachrichten-Anweisung die IDs der mehreren einzelnen Register umfasst.
  14. Verfahren nach Anspruch 10, wobei die mehreren einzelnen Register nicht zusammenhängend sind.
  15. Verfahren nach Anspruch 10, wobei die erste Phase der Sende-Sammel-Nachrichten-Anweisung eine Ziel-ID mit gemeinsam genutzter Funktion, eine funktionsspezifische Codierung einer Operation der Sende-Sammel-Nachrichten-Anweisung und ein Zielregister für eine Rückschreibantwort auf die Sende-Sammel-Nachrichten-Anweisung identifiziert.
  16. System, umfassend: einen Speicher zum Speichern eines Datenblocks; und einen Prozessor, der mit dem Speicher gekoppelt ist, wobei der Prozessor Verarbeitungsressourcen umfasst, wobei die Verarbeitungsressourcen eine Ausführungsschaltlogik umfassen zum: Empfangen einer Sende-Sammel-Nachrichten-Anweisung, die eine Anzahl von Registern zum Zugreifen auf eine Sende-Nachricht identifiziert und IDs mehrerer einzelner Register, die der Anzahl von Registern entsprechen, identifiziert; Durchführen eines sofortigen Verschiebens der IDs der mehreren einzelnen Register in ein Architekturregister der Ausführungsschaltlogik; Einschließen eines Zeigers auf das Architekturregister in der Sende-Sammel-Nachrichten-Anweisung; und Versenden der Sende-Sammel-Nachrichten-Anweisung an eine Sende-Pipeline der Ausführungsschaltlogik.
  17. System nach Anspruch 16, wobei das Architekturregister ein Skalarregister ist.
  18. System nach einem der Ansprüche 16-17, wobei die Sende-Sammel-Nachrichten-Anweisung die Anzahl der Register identifiziert, auf die für die Sende-Sammel-Nachrichten-Anweisung und das Architekturregister zuzugreifen ist.
  19. System nach einem der Ansprüche 16-18, wobei die mehreren einzelnen Register nicht zusammenhängend sind und wobei die IDs Zeiger umfassen.
  20. System nach einem der Ansprüche 16-19, wobei die Sende-Sammel-Nachrichten-Anweisung eine Ziel-ID mit gemeinsam genutzter Funktion, eine funktionsspezifische Codierung einer Operation der Sende-Sammel-Nachrichten-Anweisung und ein Zielregister für eine Rückschreibantwort auf die Sende-Sammel-Nachrichten-Anweisung identifiziert.
  21. Einrichtung zum Ermöglichen des Sammelns von Nutzdaten aus beliebigen Registern für Sende-Nachrichten in einer Grafikumgebung, wobei die Einrichtung Folgendes umfasst: Mittel zum Empfangen, über eine Ausführungsschaltlogik eines Grafikprozessors, einer Sende-Sammel-Nachrichten-Anweisung, die eine Anzahl von Registern zum Zugreifen auf eine Sende-Nachricht identifiziert und IDs mehrerer einzelner Register, die der Anzahl von Registern entsprechen, identifiziert; Mittel zum Decodieren einer ersten Phase der Sende-Sammel-Nachrichten-Anweisung; basierend auf dem Decodieren der ersten Phase der Sende-Sammel-Nachrichten-Anweisung; Mittel zum Veranlassen, dass eine zweite Phase der Sende-Sammel-Nachrichten-Anweisung eine Anweisungsdecodierungsstufe der Ausführungsschaltlogik umgeht; und Mittel zum Senden der ersten Phase der Sende-Sammel-Nachrichten-Anweisung, anschließend gefolgt vom Versenden der zweiten Phase der Sende-Sammel-Nachrichten-Anweisung an eine Sende-Pipeline der Ausführungsschaltlogik.
  22. Einrichtung nach Anspruch 21, die ferner konfiguriert ist, das Verfahren nach einem der Ansprüche 12-16 durchzuführen.
  23. Maschinenlesbares Medium bzw. maschinenlesbare Medien, die mehrere Anweisungen umfassen, die als Reaktion darauf, dass sie auf einer Rechenvorrichtung ausgeführt werden, die Rechenvorrichtung veranlassen, ein Verfahren nach einem der Ansprüche 11-16 auszuführen.
DE102022119733.6A 2021-09-22 2022-08-05 Sammeln von nutzdaten aus beliebigen registern für sende-nachrichten in einer grafikumgebung Pending DE102022119733A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US17/481,448 US20230088743A1 (en) 2021-09-22 2021-09-22 Gathering payload from arbitrary registers for send messages in a graphics environment
US17/481,448 2021-09-22

Publications (1)

Publication Number Publication Date
DE102022119733A1 true DE102022119733A1 (de) 2023-03-23

Family

ID=85383925

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102022119733.6A Pending DE102022119733A1 (de) 2021-09-22 2022-08-05 Sammeln von nutzdaten aus beliebigen registern für sende-nachrichten in einer grafikumgebung

Country Status (2)

Country Link
US (1) US20230088743A1 (de)
DE (1) DE102022119733A1 (de)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220019720A1 (en) * 2020-07-17 2022-01-20 University Of Florida Research Foundation, Incorporated Framework for automated synthesis of secure, optimized system-on-chip architectures
CN117573205A (zh) * 2023-11-17 2024-02-20 摩尔线程智能科技(北京)有限责任公司 基于simt的寄存器分配方法、装置、设备和存储介质

Also Published As

Publication number Publication date
US20230088743A1 (en) 2023-03-23

Similar Documents

Publication Publication Date Title
DE112020001258T5 (de) Grafikprozessoren und Grafikverarbeitungseinheiten mit Skalarproduktakkumulationsanweisungen für ein Hybrid-Gleitkommaformat
DE102020130078A1 (de) Systolische arithmetik an spärlichen daten
DE112020000846T5 (de) Architektur für Block-Sparse-Operationen an einem systolischen Array
US11755501B2 (en) Efficient data sharing for graphics data processing operations
DE102018133555A1 (de) Berechnungsoptimierungsmechanismus für tiefe neuronale Netze
DE102018110380A1 (de) Tool zum Ermöglichen der Effizienz beim Maschinenlernen
DE102018110687A1 (de) Dynamisches Genauigkeitsmanagement für Deep-Learning-Ganzzahlprimitive
DE102020129251A1 (de) Adaptives verformbares kernvorhersagenetzwerk zum bildentrauschen
DE102020129970A1 (de) Systeme und verfahren zur fehlererkennung und steuerung für eingebettete arbeitsspeicher- und rechenelemente
DE102020129969A1 (de) Verbesserungen der verarbeitung und des caching von graphikverarbeitungseinheiten
DE102020130073A1 (de) Verbesserung der datenlokalität für grafikprozessoreinheiten
DE112020000464T5 (de) Mehrfachkachel-grafikprozessor-rendering
DE102020132272A1 (de) Verfahren und vorrichtung zum codieren basierend auf schattierungsraten
DE112020000854T5 (de) Thread-gruppen-planung für die grafikverarbeitung
DE102020107080A1 (de) Grafiksysteme und Verfahren zum Beschleunigen von Synchronisation mittels feinkörniger Abhängigkeitsprüfung und Planungsoptimierungen basierend auf verfügbarem gemeinsam genutztem Speicherplatz
DE112020000848T5 (de) Skalarkernintegration
DE102018110346A1 (de) Speichersystem für dnn-ausgaben für die black box
DE102018110719A1 (de) Hardwareimplementierte Punkt-zu-Punkt-Kommunikationsprimitive zum Maschinenlernen
DE102020129409A1 (de) Dynamisches unterteilen von aktivierungen und kernels zum verbessern von speichereffizienz
DE102020129432A1 (de) System und Verfahren zum Anpassen eines ausführbaren Objekts an eine Verarbeitungseinheit
DE102022119733A1 (de) Sammeln von nutzdaten aus beliebigen registern für sende-nachrichten in einer grafikumgebung
CN113495793A (zh) 用于缓冲器共享的方法和装置
DE102020130995A1 (de) Verfahren und vorrichtung zur codierung basierend auf wichtigkeitswerten
DE102022130536A1 (de) Sich selbst abstimmende thread-verteilungsrichtlinie
DE102022125600A1 (de) Eingabefilterung und abtaster-beschleunigung für supersampling