DE102020130073A1 - Verbesserung der datenlokalität für grafikprozessoreinheiten - Google Patents

Verbesserung der datenlokalität für grafikprozessoreinheiten Download PDF

Info

Publication number
DE102020130073A1
DE102020130073A1 DE102020130073.5A DE102020130073A DE102020130073A1 DE 102020130073 A1 DE102020130073 A1 DE 102020130073A1 DE 102020130073 A DE102020130073 A DE 102020130073A DE 102020130073 A1 DE102020130073 A1 DE 102020130073A1
Authority
DE
Germany
Prior art keywords
graphics
processor
processing
data
memory
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
DE102020130073.5A
Other languages
English (en)
Inventor
Prasoonkumar Surti
Adam Lake
Christopher Hughes
Guei-Yuan Lueh
Subramaniam Maiyuran
Altug Koker
Vasanth Ranganathan
Nikos Kaburlasos
Lidong Xu
Abhishek Appu
James Holland
Jill Boyce
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 DE102020130073A1 publication Critical patent/DE102020130073A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • 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
    • 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/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0806—Multiuser, multiprocessor or multiprocessing cache systems
    • G06F12/0811—Multiuser, multiprocessor or multiprocessing cache systems with multilevel cache hierarchies
    • 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/3889—Concurrent instruction execution, e.g. pipeline or look ahead using a plurality of independent parallel functional units controlled by multiple instructions, e.g. MIMD, decoupled access or execute
    • G06F9/3891—Concurrent instruction execution, e.g. pipeline or look ahead using a plurality of independent parallel functional units controlled by multiple instructions, e.g. MIMD, decoupled access or execute organised in groups of units sharing resources, e.g. clusters
    • 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/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • 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/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0804—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches with main memory updating
    • 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/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0806—Multiuser, multiprocessor or multiprocessing cache systems
    • G06F12/084—Multiuser, multiprocessor or multiprocessing cache systems with a shared cache
    • 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/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0806—Multiuser, multiprocessor or multiprocessing cache systems
    • G06F12/0842—Multiuser, multiprocessor or multiprocessing cache systems for multiprocessing or multitasking
    • 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
    • G06F9/30138—Extension of register space, e.g. register cache
    • 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/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • 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/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5066—Algorithms for mapping a plurality of inter-dependent sub-tasks onto a plurality of physical CPUs
    • 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/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/544—Buffers; Shared memory; Pipes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/02—Neural networks
    • G06N3/04—Architecture, e.g. interconnection topology
    • G06N3/045—Combinations of networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/02—Neural networks
    • G06N3/06—Physical realisation, i.e. hardware implementation of neural networks, neurons or parts of neurons
    • G06N3/063—Physical realisation, i.e. hardware implementation of neural networks, neurons or parts of neurons using electronic means
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T1/00—General purpose image data processing
    • G06T1/60—Memory management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/10—Providing a specific technical effect
    • G06F2212/1016—Performance improvement
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/45—Caching of specific data in cache memory
    • G06F2212/454—Vector or matrix data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/45—Caching of specific data in cache memory
    • G06F2212/455—Image or video data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/02—Neural networks
    • G06N3/04—Architecture, e.g. interconnection topology
    • G06N3/044—Recurrent networks, e.g. Hopfield networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/02—Neural networks
    • G06N3/08—Learning methods
    • G06N3/084—Backpropagation, e.g. using gradient descent
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T2200/00—Indexing scheme for image data processing or generation, in general
    • G06T2200/28—Indexing scheme for image data processing or generation, in general involving image processing hardware

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Biomedical Technology (AREA)
  • Biophysics (AREA)
  • General Health & Medical Sciences (AREA)
  • Artificial Intelligence (AREA)
  • Computational Linguistics (AREA)
  • Data Mining & Analysis (AREA)
  • Evolutionary Computation (AREA)
  • Molecular Biology (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • Neurology (AREA)
  • Image Generation (AREA)
  • Image Processing (AREA)
  • Advance Control (AREA)
  • Memory System Of A Hierarchy Structure (AREA)

Abstract

Ausführungsformen, die hierin beschrieben sind, umfassen eine Vorrichtung, die mehrere Verarbeitungsressourcen, die eine erste Verarbeitungsressource und eine zweite Verarbeitungsressource umfassen, einen Speicher, der kommunikativ mit der ersten Verarbeitungsressource und der zweiten Verarbeitungsressource gekoppelt ist; und einen Prozessor zum Empfangen von Datenabhängigkeiten für eine oder mehrere Aufgaben, die eine oder mehrere Erzeugeraufgaben, die auf der ersten Verarbeitungsressource ausgeführt werden, und eine oder mehrere Verbraucheraufgaben, die auf der zweiten Verarbeitungsressource ausgeführt werden, umfassen, und eine Datenausgabe von einer oder mehreren Erzeugeraufgaben, die auf der ersten Verarbeitungsressource ausgeführt werden, zu einem kommunikativ mit der zweiten Verarbeitungsressource gekoppelten Cache-Speicher zu bewegen, umfasst. Andere Ausführungsformen können beschrieben und beansprucht sein.

Description

  • VERBUNDENE ANWENDUNGEN
  • Diese Anmeldung beansprucht unter 35 U.S.C. §119(e) die Priorität der provisorischen US-Patentanmeldung mit Seriennr. 62/935,716 von Christopher J. Hughes, et al, eingereicht am 15. November 2019, mit dem Titel DATA LOCALITY ENHANCEMENT FOR GRAPHICS PROCESSING UNITS, die durch Bezugnahme vollumfänglich aufgenommen wird.
  • FACHGEBIET
  • Diese Offenbarung bezieht sich allgemein auf Datenverarbeitung und speziell auf Datenverarbeitung über eine Allzweck-Grafikprozessoreinheit.
  • HINTERGRUND DER OFFENBARUNG
  • Aktuell umfasst parallele Grafikdatenverarbeitung Systeme und Verfahren, die entwickelt wurden, um bestimmte Operationen auf Grafikdaten auszuführen, wie z. B. lineare Interpolation, Tessellierung, Rasterisierung, Texturabbildung, Tiefenprüfung usw. Traditionell verwendeten Grafikprozessoren Rechnereinheiten mit fester Funktion zur Verarbeitung von Grafikdaten. Kürzlich wurden jedoch Abschnitte von Grafikprozessoren programmierbar gemacht, sodass solche Prozessoren eine größere Vielfalt von Operationen zur Verarbeitung von Vertex- und Fragmentdaten unterstützen.
  • Um die Leistung weiter zu steigern, setzen Grafikprozessoren typischerweise Verarbeitungstechniken wie Pipelining um, die versuchen, so viele Grafikdaten wie möglich in den verschiedenen Abschnitten der Grafikpipeline parallel zu verarbeiten. Parallelgrafikprozessoren mit Single-Instruction-Multi-Thread-Architekturen (SIMT-Architekturen) sind dafür ausgelegt, die Menge der parallelen Verarbeitung in der Grafikpipeline zu maximieren. In einer SIMT-Architektur versuchen Gruppen von parallelen Threads, Programmanweisungen so oft wie möglich gemeinsam synchron auszuführen, um die Verarbeitungseffizienz zu erhöhen. Eine allgemeine Übersicht der Software und Hardware für SIMT-Architekturen finden Sie in Shane Cook, CUDA Programming, Kapitel 3, Seite 37-51 (2013).
  • Figurenliste
  • Um die Art und Weise der obigen Merkmale dieser Ausführungsformen im Detail zu verstehen, kann eine genauere Beschreibung der Ausführungsformen, die oben kurz zusammengefasst wurden, durch Bezugnahme auf Ausführungsformen erfolgen, von denen einige in den beigefügten Zeichnungen illustriert sind. Es ist jedoch zu beachten, dass die beiliegenden Zeichnungen nur typische Ausführungsformen zeigen und daher nicht als einschränkend für den Anwendungsbereich zu betrachten sind.
    • 1 ist ein Blockdiagramm, das ein Rechnersystem illustriert, das so konfiguriert ist, dass es einen oder mehrere Aspekte der hierin beschriebenen Ausführungsformen umsetzt;
    • 2A bis 2D illustrieren die Komponenten des Parallelprozessors;
    • 3A bis 3C sind Blockdiagramme von Grafikmultiprozessoren und multiprozessorbasierten GPUs;
    • 4A bis 4F illustrieren eine beispielhafte Architektur, in der mehrere GPUs kommunikativ mit mehreren Mehrkernprozessoren gekoppelt sind;
    • 5 illustriert eine Grafikverarbeitungspipeline;
    • 6 illustriert einen Softwarestapel für Maschinenlernen;
    • 7 illustriert eine Allzweck-Grafikprozessoreinheit;
    • 8 illustriert ein Multi-GPU-Rechnersystem;
    • 9A bis 9B illustrieren Schichten von beispielhaften tiefen neuronalen Netzen;
    • 10 illustriert ein beispielhaftes rekurrentes neuronales Netz;
    • 11 illustriert das Training und den Einsatz eines tiefen neuronalen Netzwerks;
    • 12A ist ein Blockdiagramm, das verteiltes Lernen illustriert;
    • 12B ist ein Blockdiagramm, das eine programmierbare Netzwerkschnittstelle zur Beschleunigung des verteilten Lernens illustriert;
    • 13 illustriert ein beispielhaftes Inferencing-System auf einem Chip (Inferencing-SOC), das für die Ausführung von Inferencing mit einem trainierten Modell geeignet ist;
    • 14 ist ein Blockdiagramm eines Verarbeitungssystems;
    • 15A bis 15C illustrieren Rechnersysteme und Grafikprozessoren;
    • 16A bis 16C illustrieren Blockdiagramme weiterer Grafikprozessor- und Rechenbeschleunigerarchitekturen;
    • 17 ist ein Blockdiagramm einer Grafikverarbeitungsengine eines Grafikprozessors;
    • 18A bis 18B illustrieren eine Thread-Ausführungslogik mit einem Array von Verarbeitungselementen, die in einem Grafikprozessorkern eingesetzt werden;
    • 19 illustriert eine zusätzliche Ausführungseinheit;
    • 20 ist ein Blockdiagramm, das die Anweisungsformate eines Grafikprozessors illustriert;
    • 21 ist ein Blockdiagramm einer zusätzlichen Grafikprozessorarchitektur;
    • 22A bis 22B illustrieren ein Grafikprozessor-Befehlsformat und eine Befehlssequenz;
    • 23 illustriert eine beispielhafte Grafiksoftware-Architektur für ein Datenverarbeitungssystem;
    • 24A ist ein Blockdiagramm, das ein IP-Kernentwicklungssystem illustriert;
    • 24B illustriert eine Querschnitts-Seitenansicht einer integrierten Schaltungs- Packagebaugruppe;
    • 24C illustriert eine Packagebaugruppe, die mehrere Einheiten von Hardware-Logik-Chipletts umfasst, die mit einem Substrat (z. B. Basis-Die) verbunden sind,
    • 24D illustriert eine Packagebaugruppe, die austauschbare Chipletts umfasst;
    • 25 ist ein Blockdiagramm, das ein beispielhaftes System auf einer integrierten Chip-Schaltung illustriert;
    • 26A bis 26B sind Blockdiagramme, die beispielhafte Grafikprozessoren zur Verwendung in einem SoC illustrieren;
    • 27 ist eine schematische Illustration des Freilegens einer Taskkurve für eine Speicherhierarchie, nach den hierin beschriebenen Ausführungsformen;
    • 28 ist eine schematische Illustration eines kontextabhängigen Prädiktors nach den hierin beschriebenen Ausführungsformen; und
    • 29 ist ein Ablaufdiagramm zur Illustration von Operationen in einem Verfahren zur Umsetzung eines hardwarebasierten Vorabrufs, nach den hierin beschriebenen Ausführungsformen.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Eine Grafikprozessoreinheit (GPU) ist kommunikativ mit Host-/Prozessorkernen gekoppelt, um z. B. Grafikoperationen, Operationen für Maschinenlernen, Musteranalyseoperationen und/oder verschiedene Allzweck-GPU-Funktionen (GPGPU) zu beschleunigen. Die GPU kann kommunikativ über einen Bus oder eine andere Zwischenverbindung (z. B. eine Hochgeschwindigkeitszwischenverbindung wie PCIe oder NVLink) mit dem Host-Prozessor/den Kernen gekoppelt sein. Alternativ kann der Grafikprozessor an demselben Package oder Chip wie die Kerne integriert und mit den Kernen über einen internen Prozessorbus/Interconnect (d. h. innerhalb des Packages oder Chips) kommunikativ verbunden sein. Unabhängig von der Art, auf die die GPU verbunden ist, können die Prozessorkerne Arbeit in der Form von Sequenzen von Befehlen/Anweisungen, die in einem Arbeitsdeskriptor umfasst sind, der GPU zuordnen. Die GPU verwendet dann eigene Schaltungsanordnungen/Logik zur effizienten Verarbeitung dieser Befehle/Anweisungen.
  • In der folgenden Beschreibung werden zahlreiche spezifische Details dargelegt, um ein genaueres Verständnis bereitzustellen. Es ist jedoch für Fachleute auf dem Gebiet offensichtlich, dass die hierin beschriebenen Ausführungsformen ohne eine oder mehrere dieser spezifischen Details ausgeführt werden können. In anderen Fällen wurden bekannte Merkmale nicht beschrieben, um ein Verschleiern dieser Ausführungsformen zu vermieden.
  • Systemüberblick
  • 1 ist ein Blockdiagramm, das ein Rechnersystem 100 zeigt, das so konfiguriert ist, dass es einen oder mehrere Aspekte der hierin beschriebenen Ausführungsformen umsetzt. Das Rechnersystem 100 umfasst ein Verarbeitungs-Teilsystem 101 mit einem oder mehreren Prozessor(en) 102 und einem Systemspeicher 104 die über einen Verbindungspfad kommunizieren, der einen Speicherhub 105 umfassen kann. Der Speicherhub 105 kann eine separate Komponente innerhalb einer Chipsatzkomponente sein oder kann in den einem oder mehreren Prozessor(en) 102 integriert sein. Der Speicherhub 105 ist über eine Kommunikationsverbindung 106 mit einem E/A-Subsystem 111 gekoppelt. Das E/A-Subsystem 111 umfasst einen E/A-Hub 107, der es dem Rechnersystem 100 ermöglichen kann, Eingaben von einer oder mehreren Eingabevorrichtung(en) 108 zu empfangen. Zusätzlich kann der E/A-Hub 107 einen Anzeige-Controller, der in dem einen oder mehreren Prozessor(en) 102 umfasst sein kann, in die Lage versetzen, Ausgänge an eine oder mehrere Anzeigevorrichtung(en) 110A zu liefern. In einer Ausführungsform können die eine oder die mehreren Anzeigevorrichtung(en) 110A, die mit dem E/A-Hub 107 gekoppelt sind, eine lokale, interne oder eingebettete Anzeigevorrichtung umfassen.
  • Das verarbeitende Subsystem 101 umfasst beispielsweise einen oder mehrere Parallelprozessor(en) 112, die über einen Bus oder eine andere Kommunikationsverbindung 113 mit dem Speicherhub 105 gekoppelt sind. Bei der Kommunikationsverbindung 113 kann es sich um eine beliebige Anzahl von standardbasierten Kommunikationsverbindungstechnologien oder -protokollen handeln, wie z. B., aber nicht beschränkt auf PCI Express, oder um eine herstellerspezifische Kommunikationsschnittstelle oder Kommunikationsstruktur. Dier eine oder die mehreren Parallelprozessor(en) 112 kann (können) ein rechnerisch fokussiertes Parallel- oder Vektorverarbeitungssystem bilden, das eine große Anzahl von Verarbeitungskernen und/oder Verarbeitungsclustern umfassen kann, wie z. B. einen Many-Integrated-Core-Prozessor (MIC-Prozessor). Beispielsweise bilden der eine oder die mehreren Parallelprozessor(en) 112 ein Grafikverarbeitungs-Subsystem, das Pixel an eine der über den E/A-Hub 107 gekoppelten Anzeigevorrichtung(en) 110A ausgeben kann. Der eine oder die mehreren Parallelprozessor(en) 112 kann (können) auch einen Anzeige-Controller und eine Anzeige-Schnittstelle (nicht dargestellt) umfassen, um eine direkte Verbindung zu einem oder mehreren Anzeigevorrichtung(en) 11 0B zu ermöglichen.
  • Innerhalb des E/A-Subsystems 111 kann eine Systemspeichereinheit 114 mit dem E/A-Hub 107 verbunden werden, um einen Speichermechanismus für das Rechnersystem 100 bereitzustellen. Ein E/A-Switch 116 kann verwendet werden, um einen Schnittstellenmechanismus bereitzustellen, der Verbindungen zwischen dem E/A-Hub 107 und anderen Komponenten ermöglicht, wie z. B. einem Netzwerkadapter 118 und/oder einem drahtlosen Netzwerkadapter 119, die in die Plattform integriert werden können, und verschiedenen anderen Vorrichtungen, die über eine oder mehrere Add-In-Vorrichtungen 120 hinzugefügt werden können. Die Add-In-Vorrichtung(en) 120 kann/können auch z. B. ein oder mehrere externe Grafikprozessorvorrichtungen und/oder Rechenbeschleuniger umfassen. Der Netzwerkadapter 118 kann ein Ethernet-Adapter oder ein anderer kabelgebundener Netzwerkadapter sein. Der drahtlose Netzwerkadapter 119 kann eine oder mehrere der folgenden Vorrichtungen umfassen: Wi-Fi, Bluetooth, Near Field Communication (NFC) oder ein anderes Netzwerkgerät, das ein oder mehrere drahtlose Funkvorrichtungen umfasst.
  • Das Rechnersystem 100 kann weitere, nicht explizit dargestellte Komponenten umfassen, z. B. USB- oder andere Anschlussverbindungen, optische Speicherlaufwerke, Videoaufnahmevorrichtungen usw., die ebenfalls an den E/A-Hub 107 angeschlossen werden können. Kommunikationswege, die die verschiedenen Komponenten in 1 verbinden, können unter Verwendung beliebiger geeigneter Protokolle umgesetzt werden, wie z. B. auf PCI-basierte (Peripheral-Component-Interconnect-basierte) Bus- oder Punkt-zu-Punkt-Kommunikationsschnittstellen und/oder Protokolle, wie z. B. der Hochgeschwindigkeits-Interconnect NVLink, 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-Verbindung (AMBA-Verbindung), OpenCAPI, Gen-Z, Cache Coherent Interconnect for Accelerators (CCIX), 3GPP Long Term Evolution (LTE) (4G), 3GPP 5G und Variationen davon oder auf dem Stand der Technik bekannte verkabelte oder drahtlose Verbindungsprotokolle. In einigen Beispielen können Daten mit einem Protokoll wie Non-Volatile Memory Express (NVMe) over Fabrics (NVMe-oF) oder NVMe auf virtualisierte Speicherknoten kopiert oder gespeichert werden.
  • Der eine oder die mehreren Parallelprozessor(en) 112 kann (können) Schaltungsanordnungen umfassen, die für die Grafik- und Videoverarbeitung optimiert sind, wie etwa Videoausgangsschaltungsanordnungen, und stellt (stellen) eine Grafikprozessoreinheit (GPU) dar. Alternativ oder zusätzlich kann/können der eine oder mehrere Parallelprozessor(en) 112 Schaltungsanordnungen umfassen, die für die allgemeine Verarbeitung optimiert sind, wobei die zugrunde liegende Rechenarchitektur, die hier ausführlicher beschrieben wird, erhalten bleibt. Komponenten des Rechnersystems 100 können mit einem oder mehreren anderen Systemelementen auf einer einzigen integrierten Schaltung integriert sein. Beispielsweise können der eine oder die mehreren Parallelprozessor(en) 112, der Speicherhub 105, der/die Prozessor(en) 102 und der E/A-Hub 107 in einer integrierten System-on-Chip-Schaltung (integrierten SoC-Schaltung) integriert werden. Alternativ können die Komponenten des Rechnersystems 100 in ein einziges Package integriert werden, um eine System-in-Package-Konfiguration (SIP-Konfiguration) zu bilden. In einer Ausführungsform kann zumindest ein Abschnitt der Komponenten des Rechnersystems 100 in ein Multi-Chip-Modul (MCM) integriert sein, das mit anderen Multi-Chip-Modulen zu einem modularen Rechnersystem zusammengeschaltet werden kann.
  • Es ist zu erkennen, dass das hierin dargestellte Rechnersystem 100 illustrativ ist und dass Variationen und Änderungen möglich sind. Die Verbindungstopologie, unter anderem die Anzahl und Anordnung der Brücken, der Anzahl der Prozessoren 102 und der Anzahl der Parallelprozessoren 112, kann beliebig geändert werden. Beispielsweise kann der Systemspeicher 104 direkt statt über eine Brücke mit dem/den Prozessor(en) 102 verbunden werden, während andere Vorrichtungen über den Speicherhub 105 und den/die Prozessor(en) 102 mit dem Systemspeicher 104 kommunizieren. In anderen alternativen Topologien sind die Parallelprozessoren 112 mit dem E/A-Hub 107 oder direkt mit einem der ein oder mehreren Prozessoren 102 verbunden, anstatt mit dem Speicherhub 105. 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 Prozessoren 102 über Mehrfachsteckdosen angeschlossen sind, die mit zwei oder mehr Instanzen des/der Parallelprozessors/en 112 gekoppelt werden können.
  • Einige der hier dargestellten besonderen Komponenten sind optional und möglicherweise nicht in allen Umsetzungen des Rechnersystems 100 umfassen. So können z. B. eine beliebige Anzahl von Zusatzkarten oder Peripherievorrichtungen unterstützt werden, oder einige Komponenten können entfallen. Außerdem können einige Architekturen eine andere Terminologie für Komponenten verwenden, die den in 1 illustrierten ähneln. Beispielsweise kann der Speicherhub 105 in einigen Architekturen als Northbridge bezeichnet werden, während der E/A-Hub 107 als Southbridge bezeichnet werden kann.
  • 2A illustriert einen Parallelprozessor 200. Der Parallelprozessor 200 kann eine GPU, GPGPU oder ähnliches sein, wie hierin beschrieben. Die verschiedenen Komponenten des Parallelprozessors 200 können mit einem oder mehreren integrierten Schaltungsvorrichtungen umgesetzt sein, wie z. B. programmierbaren Prozessoren, anwendungsspezifischen integrierten Schaltungen (ASICs) oder feldprogrammierbaren Gate-Arrays (FPGAs). Der illustrierte Parallelprozessor 200 kann der oder einer der in 1 dargestellten Parallelprozessoren 112 sein.
  • Der Parallelprozessor 200 umfasst eine Parallelverarbeitungseinheit 202. Die Parallelverarbeitungseinheit umfasst eine E/A-Einheit 204, die die Kommunikation mit anderen Vorrichtungen, unter anderem anderer Instanzen der Parallelverarbeitungseinheit 202, erlaubt. Die E/A-Einheit 204 kann direkt mit anderen Vorrichtungen verbunden werden. Die E/A-Einheit 204 wird z. B. über eine Hub- oder Switch-Schnittstelle mit anderen Vorrichtungen verbunden, z. B. mit dem Speicherhub 105. 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 Host-Schnittstelle 206 und einer Speicherkreuzschiene 216 verbunden, wobei die Host-Schnittstelle 206 Befehle zur Ausführung von Verarbeitungsoperationen und die Speicherkreuzschiene 216 Befehle zur Ausführung von Speicheroperationen empfängt.
  • Wenn die Host-Schnittstelle 206 einen Befehlspuffer über die E/A-Einheit 204 empfängt, kann die Host-Schnittstelle 206 Arbeitsoperationen zur Ausführung dieser Befehle an ein Frontend 208 leiten. In einer Ausführungsform ist das Frontend 208 mit einem Scheduler 210 gekoppelt, der so konfiguriert ist, dass er Befehle oder andere Arbeitselemente an ein Verarbeitungscluster-Array 212 verteilt. Der Scheduler 210 stellt sicher, dass das Verarbeitungscluster-Array 212 ordnungsgemäß konfiguriert ist und sich in einem gültigen Zustand befindet, bevor Aufgaben an die Verarbeitungscluster des Verarbeitungscluster-Arrays 212 verteilt werden. Der Scheduler 210 kann über Firmware-Logik umgesetzt werden, die auf einem Mikrocontroller ausgeführt wird. Der von einem Mikrocontroller umgesetzte Scheduler 210 ist so konfigurierbar, dass er komplexe Planungs- und Arbeitsverteilungsoperationen mit grober und feiner Granularität ausführen kann, was eine schnelle Vorausführung und Kontextumschaltung von Threads ermöglicht, die auf dem Verarbeitungscluster-Array 212 ausgeführt werden. Vorzugsweise kann die Host-Software über eine von mehreren Grafikverarbeitungs-Türglocken Arbeitslasten für die Planung auf dem Verarbeitungscluster-Array 212 nachweisen. In anderen Beispielen kann die Abfrage nach neuen Workloads oder Interrupts verwendet werden, um die Verfügbarkeit von auszuführender Arbeit zu identifizieren oder anzuzeigen. Die Arbeitslasten können dann von der Logik des Schedulers 210 innerhalb des Scheduler-Mikrocontrollers automatisch auf das Verarbeitungscluster-Array 212 verteilt werden.
  • Das Verarbeitungscluster-Array 212 kann bis zu „N“ Verarbeitungscluster umfassen (z. B. Cluster 214A, Cluster 214B bis Cluster 214N). Jeder Cluster 214A bis 214N des Verarbeitungscluster-Arrays 212 kann eine hohe Anzahl von gleichzeitigen Threads ausführen. Der Scheduler 210 kann den Clustern 214A bis 214N des Verarbeitungscluster-Arrays 212 Arbeit zuweisen, indem er verschiedene Planungs- und/oder Arbeitsverteilungsalgorithmen verwendet, die in Abhängigkeit von der Arbeitslast variieren können, die für jeden Programm- oder Berechnungstyp entsteht. Die Planung kann dynamisch durch den Scheduler 210 erfolgen oder teilweise durch Compiler-Logik während der Kompilierung von Programmlogik unterstützt werden, die für die Ausführung durch das Verarbeitungscluster-Array 212 konfiguriert ist. Optional können verschiedene Cluster 214A bis 214N des Verarbeitungscluster-Arrays 212 für die Verarbeitung verschiedener Programmtypen oder für die Ausführung verschiedener Arten von Berechnungen zugewiesen werden.
  • Das Verarbeitungscluster-Array 212 kann so konfiguriert sein, dass es verschiedene Arten von parallelen Verarbeitungsoperationen ausführt. Beispielsweise ist das Verarbeitungscluster-Array 212 so konfiguriert, dass es parallele Allzweck-Rechenoperationen ausführt. Beispielsweise kann das Verarbeitungscluster-Array 212 Logik zur Ausführung von Verarbeitungsaufgaben umfassen, unter anderem die Filterung von Video- und/oder Audiodaten, der Ausführung von Modellierungsoperationen, unter anderem Physikoperationen, und der Ausführung von Datentransformationen.
  • Das Verarbeitungscluster-Array 212 ist so konfiguriert, dass es parallele Grafikverarbeitungsoperationen ausführt. In solchen Ausführungsformen, in denen der Parallelprozessor 200 so konfiguriert ist, dass er Grafikverarbeitungsoperationen ausführt, kann das Verarbeitungscluster-Array 212 zusätzliche Logik umfassen, um die Ausführung solcher Grafikverarbeitungsoperationen zu unterstützen, unter anderem, aber nicht beschränkt auf Texturabtastlogik, um Texturoperationen auszuführen, sowie Tessellierungslogik und andere Vertex-Verarbeitungslogik. Zusätzlich kann das Verarbeitungscluster-Array 212 so konfiguriert sein, dass es grafikverarbeitungsbezogene Shader-Programme ausführt, wie z. B. Vertex-Shader, Tessellierungs-Shader, Geometrieshader und Pixel-Shader. Die Parallelverarbeitungseinheit 202 kann Daten aus dem Systemspeicher über die E/A-Einheit 204 zur Verarbeitung übertragen. Während der Verarbeitung können die übertragenen Daten im On-Chip-Speicher (z. B. im Parallelprozessorspeicher 222) gespeichert und anschließend in den Systemspeicher zurückgeschrieben werden.
  • In Ausführungsformen, in denen die Parallelverarbeitungseinheit 202 zur Ausführung der Grafikverarbeitung verwendet wird, kann der Scheduler 210 so konfiguriert sein, dass er die Verarbeitungslast in ungefähr gleich große Aufgaben aufteilt, um eine bessere Verteilung der Grafikverarbeitungsoperationen auf mehrere Cluster 214A bis 214N des Verarbeitungscluster-Arrays 212 zu ermöglichen. In einigen dieser Ausführungsformen können Abschnitte des Verarbeitungscluster-Arrays 212 so konfiguriert sein, dass sie verschiedene Arten der Verarbeitung ausführen. Beispielsweise kann ein erster Abschnitt so konfiguriert sein, dass er Vertex-Shading und Topologieerzeugung ausführt, ein zweiter Abschnitt kann so konfiguriert sein, dass er Tessellierung und Geometrie-Shading ausführt, und ein dritter Abschnitt kann so konfiguriert sein, dass er Pixel-Shading oder andere Operationen im Bildschirmraum ausführt, um ein gerendertes Bild für die Anzeige zu erzeugen. Von einem oder mehreren der Cluster 214A bis 214N erzeugte Zwischendaten können in Puffern gespeichert werden, damit die Zwischendaten zur weiteren Verarbeitung zwischen den Clustern 214A bis 214N übertragen werden können.
  • Im Betrieb kann das Verarbeitungscluster-Array 212 auszuführende Verarbeitungsaufgaben über den Scheduler 210 empfangen, der Befehle zur Definition von Verarbeitungsaufgaben vom Frontend 208 empfängt. Bei Grafikverarbeitungsoperationen können die Verarbeitungsaufgaben Indizes der zu verarbeitenden Daten umfassen, z. B. Flächendaten (Patchdaten), Primitivdaten, Vertexdaten und/oder Pixeldaten, sowie Zustandsparameter und Befehle, die festlegen, wie die Daten verarbeitet werden sollen (z. B. welches Programm ausgeführt werden soll). Der Scheduler 210 kann so konfiguriert sein, dass er die den Aufgaben entsprechenden Indizes abruft, oder er kann die Indizes vom Frontend 208 empfangen. Das Frontend 208 kann so konfiguriert sein, dass sichergestellt wird, dass das Verarbeitungscluster-Array 212 in einen gültigen Zustand versetzt wird, bevor die durch eingehende Befehlspuffer (z. B. Batch-Puffer, Push-Puffer usw.) spezifizierte Arbeitslast eingeleitet wird.
  • Jede der einen oder mehreren Instanzen der Parallelverarbeitungseinheit 202 kann mit dem Parallelprozessorspeicher 222 gekoppelt sein. Auf den Parallelprozessorspeicher 222 kann über die Speicherkreuzschiene 216 zugegriffen werden, die sowohl vom Verarbeitungscluster-Array 212 als auch von der E/A-Einheit 204 Speicheranforderungen erhalten kann. Die Speicherkreuzschiene 216 kann über eine Speicherschnittstelle 218 auf den Parallelprozessorspeicher 222 zugreifen. Die Speicherschnittstelle 218 kann mehrere Partitionseinheiten (z. B. Partitionseinheit 220A, Partitionseinheit 220B bis Partitionseinheit 220N) umfassen, die jeweils mit einem Abschnitt (z. B. Speichereinheit) des Parallelprozessorspeichers 222 gekoppelt werden können. Die Anzahl der Partitionseinheiten 220A bis 220N kann so konfiguriert sein, dass sie gleich der Anzahl der Speichereinheiten ist, sodass eine erste Partitionseinheit 220A eine entsprechende erste Speichereinheit 224A hat, eine zweite Partitionseinheit 220B eine entsprechende zweite Speichereinheit 224B hat und eine N-te Partitionseinheit 220N eine entsprechende N-te Speichereinheit 224N hat. In anderen Ausführungsformen ist die Anzahl der Partitionseinheiten 220A bis 220N möglicherweise nicht gleich der Anzahl der Speichervorrichtungen.
  • Die Speichereinheiten 224A bis 224N können verschiedene Arten von Speichervorrichtungen umfassen, unter anderem dynamischer Direktzugriffsspeicher (DRAM) oder Grafik-Direktzugriffsspeicher, wie synchroner Grafik-Direktzugriffsspeicher (SGRAM), unter anderem Grafik-Doppeldatenraten-Speicher (GDDR-Speicher). Optional können die Speichereinheiten 224A bis 224N auch 3D-Stapelspeicher umfassen, unter anderem, aber nicht beschränkt auf High Bandwidth Memory (HBM-Speicher). Fachleute auf dem Gebiet verstehen, dass die spezifische Umsetzung der Speichereinheiten 224A bis 224N variieren kann und aus einer von verschiedenen konventionellen Designs gewählt werden kann. Render-Ziele, wie z. B. Framepuffer oder Textur-Maps, können über die Speichereinheiten 224A bis 224N hinweg gespeichert werden, sodass die Partitionseinheiten 220A bis 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 einheitlichen Speicherdesigns ausgeschlossen werden, das den Systemspeicher in Verbindung mit dem lokalen Cache-Speicher nutzt.
  • Optional kann jeder der Cluster 214A bis 214N des Verarbeitungscluster-Arrays 212 Daten verarbeiten, die in eine der Speichereinheiten 224A bis 224N im Parallelprozessorspeicher 222 geschrieben werden. Die Speicherkreuzschiene 216 kann so konfiguriert sein, dass die Ausgabe jedes Clusters 214A bis 214N an eine beliebige Partitionseinheit 220A bis 220N oder an einen anderen Cluster 214A bis 214N übertragen wird, der weitere Verarbeitungsvorgänge an der Ausgabe ausführen kann. Jeder Cluster 214A bis 214N kann mit der Speicherschnittstelle 218 über die Speicherkreuzschiene 216 kommunizieren, um von verschiedenen externen Speichervorrichtungen zu lesen oder in diese zu schreiben. In einer der Ausführungsformen mit der Speicherkreuzschiene 216 weist die Speicherkreuzschiene 216 eine Verbindung zur Speicherschnittstelle 218 auf, um mit der E/A-Einheit 204 zu kommunizieren, sowie eine Verbindung zu einer lokalen Instanz des Parallelprozessorspeichers 222, die es den Verarbeitungseinheiten innerhalb der verschiedenen Verarbeitungscluster 214A bis 214N ermöglicht, mit dem Systemspeicher oder einem anderen Speicher zu kommunizieren, der sich nicht lokal in der Parallelverarbeitungseinheit 202 befindet. Allgemein kann die Speicherkreuzschiene 216 z. B. virtuelle Kanäle verwenden, um Verkehrsströme zwischen den Clustern 214A bis 214N und den Partitionseinheiten 220A bis 220N zu trennen.
  • Während eine einzelne Instanz der Parallelverarbeitungseinheit 202 innerhalb des Parallelprozessors 200 illustriert ist, kann eine beliebige Anzahl von Instanzen der Parallelverarbeitungseinheit 202 umfasst sein. So können z. B. mehrere Instanzen der Parallelverarbeitungseinheit 202 auf einer einzigen Einsteckkarte bereitgestellt werden, oder es können mehrere Einsteckkarten miteinander verbunden werden. Der Parallelprozessor 200 kann z. B. eine Add-in-Vorrichtung sein, wie die Add-In-Vorrichtung 120 aus 1, die eine Grafikkarte sein kann, wie z. B. eine diskrete Grafikkarte, die eine oder mehrere GPUs, eine oder mehrere Speichervorrichtungen und Device-to-Device- oder Netzwerk- oder Strukturschnittstellen umfasst. Die verschiedenen Instanzen der Parallelverarbeitungseinheit 202 können so konfiguriert sein, dass sie auch dann zusammenarbeiten, wenn die verschiedenen Instanzen eine unterschiedliche Anzahl von Prozessorkernen, unterschiedliche Mengen an lokalem Parallelprozessorspeicher und/oder andere Konfigurationsunterschiede aufweisen. Optional können einige Instanzen der Parallelverarbeitungseinheit 202 im Vergleich zu anderen Instanzen Gleitkommaeinheiten mit höherer Genauigkeit umfassen. Systeme, die eine oder mehrere Instanzen der Parallelverarbeitungseinheit 202 oder des Parallelprozessors 200 umfassen, können in einer Vielzahl von Konfigurationen und Formfaktoren umgesetzt werden, unter anderem, aber nicht beschränkt auf Desktop-, Laptop- oder Handheld-Personalcomputer, Server, Workstations, Spielekonsolen und/oder eingebettete Systeme. Ein Orchestrator kann zusammengesetzte Knoten für die Workload-Leistung bilden, indem er eine oder mehrere der folgenden Ressourcen verwendet: disaggregierte Prozessorressourcen, Cache-Ressourcen, Speicherressourcen, Speicherplatzressourcen und Netzwerkressourcen.
  • 2B ist ein Blockdiagramm einer Partitionseinheit 220. Die Partitionseinheit 220 kann eine Instanz einer der Partitionseinheiten 220A bis 220N aus 2A sein. Wie illustriertt, umfasst die Partitionseinheit 220 einen L2-Cache 221, eine Framepuffer-Schnittstelle 225 und eine ROP 226 (Rasterbetriebseinheit). Der L2-Cache 221 ist ein Lese-/Schreib-Cache, der für die Ausführung von Lade- und Speicheroperationen konfiguriert ist, die von der Speicherkreuzschiene 216 und dem ROP 226 empfangen werden. Read-Misses und dringende Write-Back-Anforderungen werden vom L2-Cache 221 an die Framepuffer-Schnittstelle 225 zur Verarbeitung ausgegeben. Updates können auch über die Framepuffer-Schnittstelle 225 zur Verarbeitung an den Framepuffer gesendet werden. In einer Ausführungsform ist die Framepuffer-Schnittstelle 225 mit einer der Speichereinheiten im Parallelprozessorspeicher verbunden, z. B. mit den Speichereinheiten 224A bis 224N aus 2A (z. B. innerhalb des Parallelprozessorspeichers 222). Die Partitionseinheit 220 kann zusätzlich oder alternativ dazu auch mit einer der Speichereinheiten im Parallelprozessorspeicher über einen Speicher-Controller (nicht dargestellt) verbunden sein.
  • In Grafikanwendungen ist die ROP 226 eine Verarbeitungseinheit, die Rasteroperationen wie Stencil, z-Test, Blending und ähnliches ausführt. Das ROP 226 gibt dann verarbeitete Grafikdaten aus, die im Grafikspeicher abgelegt werden. In einigen Ausführungsformen umfasst das ROP 226 einen CODEC 227 oder ist mit diesem gekoppelt, der eine Kompressionslogik umfasst, um Tiefen- oder Farbdaten zu komprimieren, die in den Speicher oder den L2-Cache 221 geschrieben werden, und Tiefen- oder Farbdaten zu dekomprimieren, die aus dem Speicher oder dem L2-Cache 221 gelesen werden. Die Kompressionslogik kann eine verlustfreie Kompressionslogik sein, die einen oder mehrere der mehreren Kompressionsalgorithmen verwendet. Die Art der Komprimierung, die vom ROP 226CODEC 227 ausgeführt wird, kann je nach den statistischen Eigenschaften der zu komprimierenden Daten variieren. In einer Ausführungsform wird beispielsweise eine Delta-Farbkomprimierung auf Tiefen- und Farbdaten auf einer Pro-Tile-Basis ausgeführt. In einer Ausführungsform umfasst der CODEC 227 eine Komprimierungs- und Dekomprimierungslogik, die mit Maschinenlernoperationen verbundene Rechendaten komprimieren und dekomprimieren kann. Der CODEC 227 kann z. B. Sparse-Matrix-Daten für spärliche Maschinenlernoperationen komprimieren. Der CODEC 227 kann auch Sparse-Matrix-Daten komprimieren, die in einem Sparse-Matrix-Format kodiert sind (z. B. Koordinatenlistenkodierung (COO), Compressed Sparse Row (CSR), Compress Sparse Column (CSC) usw.), um komprimierte und kodierte Sparse-Matrix-Daten zu erzeugen. Die komprimierten und kodierten Sparse-Matrix-Daten können dekomprimiert und/oder decodiert werden, bevor sie von den Verarbeitungselementen verarbeitet werden, oder die Verarbeitungselemente können so konfiguriert sein, dass sie komprimierte, kodierte oder komprimierte und kodierte Daten für die Verarbeitung verbrauchen.
  • Der ROP 226 kann in jedem Verarbeitungscluster umfasst sein (z. B. Cluster 214A bis 214N aus 2A) statt innerhalb der Partitionseinheit 220. In einer solchen Ausführungsform werden Lese- und Schreibanforderungen für Pixeldaten über die Speicherkreuzschiene 216 anstelle von Pixelfragmentdaten übertragen. Die verarbeiteten Grafikdaten können auf einer Anzeigevorrichtung, z. B. auf einem der ein oder mehreren Anzeigevorrichtungen 110 aus 1 angezeigt werden, zur weiteren Verarbeitung durch den/die Prozessor(en) 102 weitergeleitet werden, oder zur weiteren Verarbeitung durch eine der Verarbeitungseinheiten innerhalb des Parallelprozessors 200 aus 2A weitergeleitet werden.
  • 2C ist ein Blockdiagramm eines Verarbeitungsclusters 214 innerhalb einer Parallelverarbeitungseinheit. Der Verarbeitungscluster ist zum Beispiel eine Instanz eines der Verarbeitungscluster 214A bis 214N aus 2A. Der Verarbeitungscluster 214 kann so konfiguriert sein, dass viele Threads parallel ausgeführt werden, wobei sich der Begriff „Thread“ auf eine Instanz eines bestimmten Programms bezieht, das auf einem bestimmten Satz von Eingangsdaten ausgeführt wird. Optional können SIMD-Befehlsausgabetechniken (Single-Instruction, Multiple-Data) verwendet werden, um die parallele Ausführung einer großen Anzahl von Threads zu unterstützen, ohne mehrere unabhängige Befehlseinheiten bereitzustellen. Alternativ können Single-Instruction-Multiple-Thread-Techniken (SIMT-Techniken) verwendet werden, um die parallele Ausführung einer großen Anzahl von im Allgemeinen synchronisierten Threads zu unterstützen, wobei eine gemeinsame Befehlseinheit verwendet wird, die so konfiguriert ist, dass sie Befehle an eine Reihe von Verarbeitungsmaschinen innerhalb jedes der Verarbeitungscluster ausgibt. Im Gegensatz zu einem SIMD-Ausführungsregime, bei dem alle Verarbeitungsengines typischerweise identische Anweisungen ausführen, ermöglicht die SIMT-Ausführung, dass verschiedene Threads leichter unterschiedlichen Ausführungspfaden durch ein bestimmtes Thread-Programm folgen können. Fachleute auf dem Gebiet verstehen, dass ein SIMD-Verarbeitungsregime eine funktionale Teilmenge eines SIMT-Verarbeitungsregimes darstellt.
  • Der Betrieb des Verarbeitungsclusters 214 kann über einen Pipeline-Manager 232 gesteuert werden, der die Verarbeitungsaufgaben auf die parallelen SIMT-Prozessoren verteilt. Der Pipeline-Manager 232 erhält Anweisungen vom Scheduler 210 aus 2A und verwaltet die Ausführung dieser Anweisungen über einen Grafikmultiprozessor 234 und/oder eine Textureinheit 236. Der illustrierte Grafikmultiprozessor 234 ist eine beispielhafte Instanz eines SIMT-Parallelprozessors. Es können jedoch verschiedene Typen von SIMT-Parallelprozessoren mit unterschiedlichen Architekturen in den Verarbeitungscluster 214 aufgenommen werden. Eine oder mehrere Instanzen des Grafikmultiprozessors 234 können in einem Verarbeitungscluster 214 umfasst sein. Der Grafikmultiprozessor 234 kann Daten verarbeiten und eine Datenkreuzschiene 240 kann verwendet werden, um die verarbeiteten Daten an eines von mehreren möglichen Zielen, unter anderem anderer Shader-Einheiten, zu verteilen. Der Pipeline-Manager 232 kann die Verteilung der verarbeiteten Daten erleichtern, indem er Ziele für die zu verteilenden verarbeiteten Daten über die Datenkreuzschiene 240 angibt.
  • Jeder Grafikmultiprozessor 234 innerhalb des Verarbeitungsclusters 214 kann einen identischen Satz an funktionaler Ausführungslogik umfassen (z. B. arithmetische Logikeinheiten, Ladespeichereinheiten usw.). Die funktionale Ausführungslogik kann in einer Pipeline konfiguriert sein, in der neue Anweisungen ausgegeben werden können, bevor vorherige Anweisungen abgeschlossen sind. Die funktionale Ausführungslogik unterstützt unterschiedliche Operationen, darunter Ganzzahl- und Gleitkommaarithmetik, Vergleichsoperationen, boolesche Operationen, Bitverschiebung und die Berechnung verschiedener algebraischer Funktionen. Dieselbe Hardware mit Funktionseinheiten kann zur Ausführung verschiedener Operationen verwendet werden, und es kann eine beliebige Kombination von Funktionseinheiten vorhanden sein.
  • Die an den Verarbeitungscluster 214 übertragenen Anweisungen bilden einen Thread. Ein Satz von Threads, die über den Satz von Parallelverarbeitungsmodulen ausgeführt werden, ist eine Thread-Gruppe. Eine Thread-Gruppe führt das gleiche Programm auf unterschiedlichen Eingangsdaten aus. Jeder Thread innerhalb einer Thread-Gruppe kann einer anderen Verarbeitungsengine innerhalb eines Grafikmultiprozessors 234 zugewiesen werden. Eine Thread-Gruppe kann weniger Threads umfassen als die Anzahl der Verarbeitungsengines innerhalb des Grafikmultiprozessors 234. Wenn eine Thread-Gruppe weniger Threads umfasst als die Anzahl der Verarbeitungsengines, können eine oder mehrere der Verarbeitungsengines während der Zyklen, in denen diese Thread-Gruppe verarbeitet wird, im Leerlauf sein. Eine Thread-Gruppe kann auch mehr Threads umfassen als die Anzahl der Verarbeitungsengines innerhalb des Grafikmultiprozessors 234. Wenn die Thread-Gruppe mehr Threads umfasst als die Anzahl der Verarbeitungsengines innerhalb des Grafikmultiprozessors 234, kann die Verarbeitung über aufeinanderfolgende Taktzyklen erfolgen. Optional können mehrere Thread-Gruppen gleichzeitig auf dem Grafikmultiprozessor 234 ausgeführt werden.
  • Der Grafikmultiprozessor 234 kann einen internen Cache-Speicher umfassen, um Lade- und Speicheroperationen auszufü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-Caches (L2-Caches) innerhalb der Partitionseinheiten (z. B. die Partitionseinheiten 220A bis 220N aus 2A), die von allen Verarbeitungsclustern 214 gemeinsam genutzt werden und zur Datenübertragung zwischen Threads verwendet werden können. Der Grafikmultiprozessor 234 kann auch auf den globalen Off-Chip-Speicher zugreifen, der einen oder mehrere lokale parallele Prozessorspeicher und/oder Systemspeicher umfassen kann. Als globaler Speicher kann ein beliebiger Speicher außerhalb der Parallelverarbeitungseinheit 202 verwendet werden. Ausführungsformen, in denen der Verarbeitungscluster 214 mehrere Instanzen des Grafikmultiprozessors 234 umfasst, können gemeinsame Anweisungen und Daten nutzen, die im L1-Cache 2488 gespeichert werden können.
  • Jeder Verarbeitungscluster 214 kann eine MMU 245 (Memory Management Unit) umfassen, die so konfiguriert ist, dass sie virtuelle Adressen auf physikalische Adressen abbildet. In anderen Ausführungsformen können sich eine oder mehrere Instanzen der MMU 245 innerhalb der Speicherschnittstelle 218 aus 2A befinden. Die MMU 245 umfasst einen Satz von Seitentabelleneinträgen (PTEs), die verwendet werden, um eine virtuelle Adresse auf eine physikalische Adresse einer Kachel abzubilden, und optional einen Cache-Zeilenindex. Die MMU 245 kann Adressübersetzungs-Lookaside-Puffer (TLB) oder Caches umfassen, die sich im Grafikmultiprozessor 234 oder im L1-Cache oder Verarbeitungscluster 214 befinden können. Die physikalische Adresse wird verarbeitet, um die Zugriffslokalität der Oberflächendaten zu verteilen, um ein effizientes Request Interleaving zwischen den Partitionseinheiten zu ermöglichen. Der Cache-Zeilen-Index kann verwendet werden, um festzustellen, ob eine Anforderung für eine Cache-Zeile ein Hit oder Miss ist.
  • In Grafik- und Computeranwendungen kann ein Verarbeitungscluster 214 so konfiguriert sein, dass jeder Grafikmultiprozessor 234 mit einer Textureinheit 236 gekoppelt ist, um Texturabbildungsoperationen auszuführen, z. B. die Bestimmung von Texturabtastpositionen, das Lesen von Texturdaten und das Filtern der Texturdaten. Texturdaten werden aus einem internen Textur-L1-Cache (nicht dargestellt) oder in einigen Ausführungsformen aus dem L1-Cache innerhalb des Grafikmultiprozessors 234 gelesen und nach Bedarf aus einem L2-Cache, dem lokalen Parallelprozessorspeicher oder dem Systemspeicher abgerufen. Jeder Grafikmultiprozessor 234 gibt verarbeitete Aufgaben an die Datenkreuzschiene 240 aus, um die verarbeitete Aufgabe einem anderen Verarbeitungscluster 214 zur weiteren Verarbeitung zur Verfügung zu stellen oder um die verarbeitete Aufgabe über die Speicherkreuzschiene 216 in einem L2-Cache, einem lokalen Parallelprozessorspeicher oder im Systemspeicher zu speichern. Eine preROP 242 (Vor-Rasterbetriebseinheit) ist so konfiguriert, dass sie Daten vom Grafikmultiprozessor 234 empfängt und Daten an ROP-Einheiten weiterleitet, die sich bei den hierin beschriebenen Partitionseinheiten befinden können (z. B. die Partitionseinheiten 220A bis 220N aus 2A). Die Einheit preROP 242 kann Optimierungen für die Farbüberblendung ausführen, Pixelfarbdaten organisieren und Adressübersetzungen vornehmen.
  • Es ist zu erkennen, dass die hier beschriebene Kernarchitektur illustrativ ist und dass Variationen und Änderungen möglich sind. Eine beliebige Anzahl von Verarbeitungseinheiten, z. B. Grafikmultiprozessor 234, Textureinheiten 236, PreROPs 242 usw., kann in einem Verarbeitungscluster 214 umfasst sein. Auch wenn nur ein Verarbeitungscluster 214 dargestellt ist, kann eine hier beschriebene Parallelverarbeitungseinheit eine beliebige Anzahl von Instanzen des Verarbeitungsclusters 214 umfassen. Optional kann jeder Verarbeitungscluster 214 so konfiguriert sein, dass er unabhängig von anderen Verarbeitungsclustern 214 arbeitet und separate und unterschiedliche Verarbeitungseinheiten, LI-Caches, L2-Caches usw. verwendet.
  • 2D zeigt ein Beispiel für den Grafikmultiprozessor 234, bei dem der Grafikmultiprozessor 234 mit dem Pipeline-Manager 232 des Verarbeitungsclusters 214 gekoppelt ist. Der Grafikmultiprozessor 234 verfügt über eine Ausführungspipeline, die unter anderem einen Befehlscache 252, eine Befehlseinheit 254, eine Adressabbildungseinheit 256, eine Registerdatei 258, einen oder mehrere Allzweckgrafikprozessoreinheitenkerne (GPGPU-Kerne) 262 und eine oder mehrere Lade-/Speichereinheiten 266 umfasst. Die GPGPU-Kerne 262 und Lade-/Speichereinheiten 266 sind über eine Speicher- und Cache-Verbindung 268 mit dem Cache-Speicher 272 und dem gemeinsamen Speicher 270 gekoppelt. Der Grafikmultiprozessor 234 kann zusätzlich Tensor- und/oder Raytracing-Kerne 263 umfassen, die Hardware-Logik zur Beschleunigung von Matrix- und/oder Raytracing-Operationen beinhalten.
  • Der Befehls-Cache 252 kann einen Strom von auszuführenden Befehlen vom Pipeline-Manager 232 empfangen. Die Befehle werden im Befehls-Cache 252 zwischengespeichert und von der Befehlseinheit 254 zur Ausführung bereitgestellt. Die Befehlseinheit 254 kann Befehle als Thread-Gruppen (z. B. Warps) versenden, wobei jeder Thread der Thread-Gruppe einer anderen Ausführungseinheit innerhalb des GPGPU-Kerns 262 zugewiesen ist. Eine Anweisung kann auf einen beliebigen lokalen, gemeinsamen oder globalen Adressraum zugreifen, indem sie eine Adresse innerhalb eines einheitlichen Adressraums angibt. Die Adressabbildungseinheit 256 kann verwendet werden, um Adressen im einheitlichen Adressraum in eine eindeutige Speicheradresse zu übersetzen, auf die von den Lade-/Speichereinheiten 266 zugegriffen werden kann.
  • Die Registerdatei 258 umfasst einen Satz von Registern für die Funktionseinheiten des Grafikmultiprozessors 234. Die Registerdatei 258 dient der temporären Speicherung von Operanden, die mit den Datenpfaden der Funktionseinheiten (z. B. GPGPU-Kerne 262, Lade-/Speichereinheiten 266) des Grafikmultiprozessors 234 verbunden sind. Die Registerdatei 258 kann zwischen den einzelnen Funktionseinheiten aufgeteilt werden, sodass jeder Funktionseinheit ein eigener Abschnitt der Registerdatei 258 zugewiesen wird. Beispielsweise kann die Registerdatei 258 auf die verschiedenen Warps aufgeteilt werden, die vom Grafikmultiprozessor 234 ausgeführt werden.
  • Die GPGPU-Kerne 262 können jeweils Gleitkommaeinheiten (FPUs) und/oder ganzzahlige arithmetische Logikeinheiten (ALUs) umfassen, die zur Ausführung von Befehlen des Grafikmultiprozessors 234 verwendet werden. In einigen Umsetzungen können die GPGPU-Kerne 262 Hardware-Logik umfassen, die sich ansonsten in den Tensor- und/oder Raytracing-Kernen 263 befinden könnte. Die GPGPU-Kerne 262 können in ihrer Architektur ähnlich sein oder sich unterscheiden. Beispielsweise und in einer Ausführungsform umfasst ein erster Abschnitt der GPGPU-Kerne 262 eine FPU mit einfacher Genauigkeit und eine Integer-ALU, während ein zweiter Abschnitt der GPGPU-Kerne eine FPU mit doppelter Genauigkeit umfasst. Optional können die FPUs den IEEE 754-2008-Standard für Gleitkommaarithmetik umsetzen oder Gleitkommaarithmetik mit variabler Genauigkeit ermöglichen. Der Grafikmultiprozessor 234 kann zusätzlich eine oder mehrere feste Funktions- oder Sonderfunktionseinheiten umfassen, um bestimmte Funktionen wie z. B. Kopierrechteck- oder Pixel-Blending-Operationen auszuführen. Einer oder mehrere der GPGPU-Kerne können auch feste oder spezielle Funktionslogik umfassen.
  • Die GPGPU-Kerne 262 können SIMD-Logik umfassen, die in der Lage ist, einen einzigen Befehl auf mehreren Datensätzen auszuführen. Optional können die GPGPU-Kerne 262 physikalisch SIMD4-, SIMD8- und SIMD16-Befehle und logisch SIMD1-, SIMD2- und SIMD32-Befehle ausführen. Die SIMD-Befehle für die GPGPU-Kerne können zur Kompilierzeit von einem Shader-Compiler oder automatisch bei der Ausführung von Programmen, die für Single Program Multiple Data (SPMD) oder SIMT-Architekturen geschrieben und kompiliert wurden, erzeugt werden. Mehrere Threads eines für das SIMT-Ausführungsmodell konfigurierten Programms können über eine einzige SIMD-Anweisung ausgeführt werden. In einer Ausführungsform können z. B. acht SIMT-Threads, die gleiche oder ähnliche Operationen ausführen, parallel über eine einzige SIMD8-Logikeinheit ausgeführt werden.
  • Die Speicher- und Cache-Verbindung 268 ist ein Verbindungsnetzwerk, das jede der Funktionseinheiten des Grafikmultiprozessors 234 mit der Registerdatei 258 und mit dem gemeinsamen Speicher 270 verbindet. Beispielsweise ist die Speicher- und Cache-Verbindung 268 eine Kreuzschienenverbindung, die es der Lade-/Speichereinheit 266 ermöglicht, Lade- und Speicheroperationen zwischen dem gemeinsamen Speicher 270 und der Registerdatei 258 zu umsetzen. 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 sehr geringe Latenz aufweist. Der gemeinsame Speicher 270 kann verwendet werden, um die Kommunikation zwischen Threads zu ermöglichen, die auf den Funktionseinheiten innerhalb des Grafikmultiprozessors 234 ausgeführt werden. Der Cache-Speicher 272 kann z. B. als Daten-Cache verwendet werden, um Texturdaten zwischenzuspeichern, die zwischen den Funktionseinheiten und der Textureinheit 236 kommuniziert werden. Der gemeinsame Speicher 270 kann auch als programmverwalteter Cache verwendet werden. Der gemeinsame Speicher 270 und der Cache-Speicher 272 können mit der Datenkreuzschiene 240 gekoppelt werden, um die Kommunikation mit anderen Komponenten des Verarbeitungsclusters zu ermöglichen. Threads, die auf den GPGPU-Kernen 262 ausgeführt werden, können zusätzlich zu den automatisch zwischengespeicherten Daten, die im Cache-Speicher 272 gespeichert sind, programmatisch Daten im gemeinsamen Speicher speichern.
  • 3A bis 3C illustrieren weitere Grafikmultiprozessoren den Ausführungsformen entsprechend. 3A bis 3B illustrieren die Grafikmultiprozessoren 325, 350, die mit dem Grafikmultiprozessor 234 aus 2C und kann anstelle eines dieser Vorrichtungenverwendet werden. Daher offenbart die Offenbarung beliebiger Merkmale in Kombination mit dem Grafikmultiprozessor 234 hierin auch eine entsprechende Kombination mit dem/den Grafikmultiprozessor(en) 325, 350, ist aber nicht auf diese beschränkt. 3C illustriert eine Grafikprozessoreinheit (GPU) 380, die dedizierte Sätze von Grafikverarbeitungsressourcen umfasst, die in Multi-Core-Gruppen 365A bis 365N angeordnet sind, die den Grafikmultiprozessoren 325, 350 entsprechen. Die illustrierten Grafikmultiprozessoren 325, 350 und die Multi-Core-Gruppen 365A bis 365N können Streaming-Multiprozessoren (SM) sein, die eine große Anzahl von Ausführungs-Threads gleichzeitig ausführen können.
  • Der Grafikmultiprozessor 325 aus 3A umfasst mehrere zusätzliche Instanzen von Ausführungsressourceneinheiten relativ zum Grafikmultiprozessor 234 aus 2D. Der Grafikmultiprozessor 325 kann z. B. mehrere Instanzen der Befehlseinheit 332A bis 332B, der Registerdatei 334A bis 334B und der Textureinheit(en) 344A bis 344B umfassen. Der Grafikmultiprozessor 325 umfasst auch mehrere Sätze von Grafik- oder Rechenausführungseinheiten (z. B. GPGPU-Kern 336A bis 336B, Tensorkern 337A bis 337B, Raytracing-Kern 338A bis 338B) und mehrere Sätze von Lade-/Speichereinheiten 340A bis 340B. Die Ausführungsressourceneinheiten verfügen über einen gemeinsamen Befehls-Cache 330, einen Textur- und/oder Daten-Cache-Speicher 342 und einen gemeinsamen Speicher 346.
  • Die verschiedenen Komponenten können über eine Verbindungsstruktur 327 kommunizieren. Die Verbindungsstruktur 327 kann einen oder mehrere Kreuzschienenschalter umfassen, um die Kommunikation zwischen den verschiedenen Komponenten des Grafikmultiprozessors 325 zu ermöglichen. Die Verbindungsstruktur 327 kann eine separate Hochgeschwindigkeits-Netzwerkstrukturschicht sein, auf die jede Komponente des Grafikmultiprozessors 325 gestapelt ist. Die Komponenten des Grafikmultiprozessors 325 kommunizieren mit entfernten Komponenten über die Verbindungsstruktur 327. Beispielsweise können die Kerne 336A bis 336B, 337A bis 337B und 3378A bis 338B jeweils mit dem gemeinsamen Speicher 346 über die Verbindungsstruktur 327 kommunizieren. Die Vebrindungsstruktur 327 kann die Kommunikation innerhalb des Grafikmultiprozessors 325 vermitteln, um eine faire Bandbreitenzuordnung zwischen den Komponenten zu gewährleisten.
  • Der Grafikmultiprozessor 350 aus 3B umfasst mehrere Sätze von Ausführungsressourcen 356A bis 356D, wobei jeder Satz von Ausführungsressourcen mehrere Befehlseinheiten, Registerdateien, GPGPU-Kerne und Ladespeichereinheiten umfasst, wie in 2D und 3A illustriert its. Die Ausführungsressourcen 356A bis 356D können mit der/den Textureinheit(en) 360A bis 360D für Texturoperationen zusammenarbeiten, während sie sich einen Befehlscache 354 und einen gemeinsamen Speicher 353 teilen. Beispielsweise können sich die Ausführungsressourcen 356A bis 356D einen Befehls-Cache 354 und einen gemeinsamen Speicher 353 sowie mehrere Instanzen eines Textur- und/oder Daten-Cache-Speichers 358A bis 358B teilen. Die verschiedenen Komponenten können über eine Verbindungsstruktur 352 kommunizieren, die der Verbindungsstruktur 327 aus 3A ähnlich sind.
  • Fachleute auf dem Gebiet verstehen, dass die in 1, 2A bis 2D und 3A bis 3B beschriebene Architektur beschreibend und den Umfang dieser Ausführungsformen betreffend nicht einschränkend ist. Daher können die hierin beschriebenen Techniken auf jeder ordnungsgemäß konfigurierten Verarbeitungseinheit umgesetzt werden, unter anderem, ohne Einschränkung, einem oder mehreren mobilen Anwendungsprozessoren, einer oder mehreren zentralen Prozessoreinheiten (CPUs) für Desktop oder Server, unter anderem Multi-Core-CPUs, einer oder mehreren Parallelverarbeitungseinheiten, wie der Parallelverarbeitungseinheit 202 aus 2A, sowie einen oder mehrere Grafikprozessoren oder spezielle Verarbeitungseinheiten, ohne vom Umfang der hierin beschriebenen Ausführungsformen abzuweichen.
  • Der hier beschriebene Parallelprozessor oder die GPGPU kann kommunikativ mit Host-/Prozessorkernen gekoppelt werden, um Grafikoperationen, Operationen des Maschinenlernens, Musteranalyseoperationen und verschiedene Allzweck-GPU-Funktionen (GPGPU) zu beschleunigen. Die GPU kann über einen Bus oder eine andere Verbindung (z. B. eine Hochgeschwindigkeitsverbindung wie PCIe oder NVLink) mit dem/den Host-Prozessor(en) kommunikativ verbunden sein., NVLink oder andere bekannte Protokolle, standardisierte Protokolle oder proprietäre Protokolle). In anderen Ausführungsformen kann die GPU auf demselben Package oder Chip integriert sein wie die Kerne, und kommunikativ über einen internen Prozessorbus/ein Interconnect (d. h. intern in dem Package oder Chip) mit den Kernen gekoppelt sein. Unabhängig von der Art, auf die die GPU verbunden ist, können die Prozessorkerne Arbeit in der Form von Sequenzen von Befehlen/Anweisungen, die in einem Arbeitsdeskriptor umfasst sind, der GPU zuordnen. Die GPU verwendet dann eigene Schaltungsanordnungen/Logik zur effizienten Verarbeitung dieser Befehle/Anweisungen.
  • 3C illustriert eine Grafikprozessoreinheit (GPU) 380, die dedizierte Sätze von Grafikverarbeitungsressourcen umfasst, die in Multi-Core-Gruppen 365A bis 365N angeordnet sind. Während die Details nur einer einzigen Multi-Core-Gruppe 365A bereitgestellt werden, wird es geschätzt, dass die anderen Multi-Core-Gruppen 365B bis 365N mit den gleichen oder ähnlichen Sätzen von Grafikverarbeitungsressourcen ausgestattet sein können. Details, die in Bezug auf die Multi-Core-Gruppen 365A bis 365N beschrieben sind, können auch für jeden hierin beschriebenen Grafikmultiprozessor 234, 325, 350 gelten.
  • Wie illustriert, kann eine Multi-Core-Gruppe 365A einen Satz von Grafikkernen 370, einen Satz von Tensorkernen 371 und einen Satz von Ray-Tracing-Kernen 372 umfassen. Ein Scheduler/Dispatcher 368 plant und disponiert 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 beim Ausführen der Grafik-Threads verwendet werden. Dies können z. B. Integer-Register zur Speicherung von Integer-Werten, Fließkomma-Register zur Speicherung von Fließkomma-Werten, Vektor-Register zur Speicherung von gepackten Datenelementen (Integer- und/oder Fließkomma-Datenelemente) und Kachelregister zur Speicherung von Tensor/Matrix-Werten sein. Die Kachelregister können als kombinierte Sätze von Vektorregistern umgesetzt werden.
  • Ein oder mehrere kombinierte Level-1-Caches (L1) und gemeinsam genutzte Speichereinheiten 373 speichern Grafikdaten wie Texturdaten, Vertexdaten, Pixeldaten, Strahldaten, Bounding-Volume-Daten usw. lokal innerhalb jeder Multi-Core-Gruppe 365A. Eine oder mehrere Textureinheiten 374 können auch verwendet werden, um Texturierungsoperationen auszuführen, wie z. B. Texturabbildung und Sampling. Ein Level 2-Cache (L2-Cache) 375, der von allen oder einer Teilmenge der Multi-Core-Gruppen 365A bis 365N gemeinsam genutzt wird, speichert Grafikdaten und/oder Anweisungen für mehrere gleichzeitige Grafik-Threads. Wie illustriert, kann der L2-Cache 375 von mehreren Multi-Core-Gruppen 365A bis 365N gemeinsam genutzt werden. Ein oder mehrere Speichercontroller 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.
  • Die Eingangs-/Ausgangsschaltungsanordnung (E/A-Schaltungsanordnung) 363 koppelt die GPU 380 mit einem oder mehreren E/A-Vorrichtungen 362, wie z. B. digitalen Signalprozessoren (DSPs), Netzwerk-Controllern oder Benutzereingabevorrichtungen. Ein On-Chip-Interconnect kann verwendet werden, um die E/A-Vorrichtungen 362 mit der GPU 380 und dem Speicher 366 zu verbinden. Eine oder mehrere E/A-Speicherverwaltungseinheiten (IOMMUs) 364 der E/A-Schaltungsanordnung 363 koppeln die E/A-Vorrichtungen 362 direkt an den Systemspeicher 366. Optional verwaltet die IOMMU 364 mehrere Sätze von Seitentabellen, um virtuelle Adressen auf physikalische Adressen im Systemspeicher 366 abzubilden. Die E/A-Vorrichtungen 362, die CPU(s) 361 und die GPU(s) 380 können sich dann denselben virtuellen Adressraum teilen.
  • In einer Umsetzung des IOMMU 364 unterstützt das IOMMU 364 die Virtualisierung. In diesem Fall kann es einen ersten Satz von Seitentabellen verwalten, um virtuelle Gast-/Grafikadressen auf physikalische Gast-/Grafikadressen abzubilden, und einen zweiten Satz von Seitentabellen, um die physikalischen Gast-/Grafikadressen auf physikalische System-/Hostadressen abzubilden (z. B. im Systemspeicher 366). Die Basisadressen des ersten und zweiten Satzes von Seitentabellen können in Steuerregistern gespeichert und bei einem Kontextwechsel ausgelagert werden (z. B. damit der neue Kontext Zugriff auf den entsprechenden Satz von Seitentabellen erhält). Obwohl dies in 3C nicht illustriert ist, kann jeder der Kerne 370, 371, 372 und/oder Multi-Core-Gruppen 365A bis 365N Übersetzungs-Lookaside-Buffer (TLBs) umfassen, um virtuelle Gast-zu-Gast-physikalische Übersetzungen, physische Gast-zu-Host-physikalische Übersetzungen und virtuelle Gast-zu-Host-physikalische Übersetzungen zu cachen.
  • Die CPUs 361, GPUs 380 und E/A-Vorrichtungen 362 können auf einem einzigen Halbleiterchip und/oder Chip-Package integriert sein. Der illustrierte Speicher 366 kann auf demselben Chip integriert sein oder über eine Off-Chip-Schnittstelle mit den Speicher-Controllern 367 gekoppelt sein. In einer Umsetzung besteht der Speicher 366 aus GDDR6-Speicher, der sich denselben virtuellen Adressraum wie andere physische Speicher auf Systemebene teilt, obwohl die hierin beschriebenen Grundsätze nicht auf diese spezielle Umsetzung beschränkt sind.
  • Die Tensorkerne 371 können mehrere Ausführungseinheiten umfassen, die speziell für die Ausführung von Matrixoperationen ausgelegt sind, die die grundlegende Rechenoperation für die Ausführung von Deep-Learning-Operationen sind. Beispielsweise können gleichzeitige Matrixmultiplikationsoperationen für das Training und die Inferenz eines neuronalen Netzes verwendet werden. Die Tensorkerne 371 können die Matrixverarbeitung unter Verwendung einer Vielzahl von Operandenpräzisionen ausführen, unter anderem Gleitkomma mit einfacher Genauigkeit (z. B. 32 Bit), Gleitkomma mit halber Genauigkeit (z. B. 16 Bit), Ganzzahlwörter (16 Bit), Bytes (8 Bit) und Halbbytes (4 Bit). Beispielsweise extrahiert eine neuronale Netzwerkumsetzung Merkmale jeder gerenderten Szene, wobei möglicherweise Details aus mehreren Frames kombiniert werden, um ein qualitativ hochwertiges Endbild zu konstruieren.
  • In Deep-Learning-Umsetzungen kann die parallele Matrixmultiplikation für die Ausführung auf den Tensorkernen 371 geplant werden. Insbesondere die Schulung von neuronalen Netzen erfordert eine erhebliche Anzahl von Matrixpunktprodukt-Operationen. Um eine Innenprodukt-Formulierung einer N × N × N-MatrixMultiplikation zu verarbeiten, können die Tensorkerne 371 mindestens N Punktprodukt-Verarbeitungselemente umfassen. Bevor die Matrixmultiplikation beginnt, wird eine gesamte Matrix in Kachelregister geladen und mindestens eine Spalte einer zweiten Matrix wird jeden Zyklus für N Zyklen geladen. In jedem Zyklus gibt es N Punktprodukte, die verarbeitet werden.
  • Matrixelemente können je nach Umsetzung mit unterschiedlichen Genauigkeiten gespeichert werden, z. B. 16-Bit-Worte, 8-Bit-Bytes (z. B. INT8) und 4-Bit-Halbbytes (z. B. INT4). Für die Tensorkerne 371 können verschiedene Präzisionsmodi festgelegt werden, um sicherzustellen, dass die effizienteste Präzision für verschiedene Arbeitslasten verwendet wird (z. B. wie Inferenz-Arbeitslasten, die eine Quantisierung auf Bytes und Halbbytes tolerieren können). Unterstützt werden außerdem 64-Bit-Gleitkommaformate (FP64) und Nicht-IEEE-Gleitkommaformate wie das bfloat16-Format (z. B. Brain-Gleitkomma), ein 16-Bit-Gleitkommaformat mit einem Vorzeichenbit, acht Exponentenbits und acht Signifikantenbits, von denen sieben explizit gespeichert werden. Eine Ausführungsform umfasst die Unterstützung eines Tensor-Float-Formats mit verringerter Genauigkeit (TF32), das den Bereich von FP32 (8-Bits) mit der Genauigkeit von FP16 (10-Bits) hat. TF32-Operationen mit verringerter Genauigkeit können auf FP32-Eingängen ausgeführt werden und erzeugen FP32-Ausgänge bei höherer Leistung im Vergleich zu FP32 und erhöhter Genauigkeit im Vergleich zu FP16.
  • In einer Ausführungsform unterstützen die Tensorkerne 371 einen Sparse-Betriebsmodus für Matrizen, in denen die überwiegende Mehrheit der Werte Null ist. Die Tensorkerne 371 unterstützen Sparse-Input-Matrizen, die in einer Sparse-Matrix-Darstellung kodiert sind (z. B. Koordinatenlistenkodierung (COO), Compressed Sparse Row (CSR), Compress Sparse Column (CSC) usw.). Die Tensorkerne 371 umfassen auch Unterstützung für komprimierte Sparse-Matrix-Darstellungen für den Fall, dass die Sparse-Matrix-Darstellung weiter komprimiert werden kann. Komprimierte, kodierte und/oder komprimierte und kodierte Matrixdaten, zusammen mit zugehörigen Komprimierungs- und/oder Kodierungsmetadaten, können von den Tensorkernen 371 bereitgestellt und die Nicht-Nullwerte extrahiert werden. Beispielsweise kann für eine gegebene Eingabematrix A ein Nicht-Null-Wert aus der komprimierten und/oder kodierten Darstellung von mindestens einem Abschnitt der Matrix A geladen werden. Basierend auf der Position in der Matrix A für den Nicht-Null-Wert, die aus Index- oder Koordinaten-Metadaten bestimmt werden kann, die mit dem Nicht-Null-Wert verbunden sind, kann ein entsprechender Wert in die Eingabematrix B geladen werden. Abhängig von der auszuführenden Operation (z. B. Multiplizieren) kann das Laden des Wertes aus der Eingabematrix B übersprungen werden, wenn der entsprechende Wert ein Nullwert ist. In einer Ausführungsform können die Wertepaare für bestimmte Operationen, wie z. B. Multiplikationsoperationen, von der Scheduler-Logik vorab gescannt werden, und nur Operationen zwischen Eingängen, die nicht Null sind, werden eingeplant. Abhängig von den Dimensionen der Matrix A und der Matrix B und der auszuführenden Operation kann die Ausgabematrix C dicht oder spärlich sein. Wenn die Ausgabematrix C spärlich ist, kann die Ausgabematrix C je nach Konfiguration der Tensorkerne 371 in einem komprimierten Format, einer Sparse-Kodierung oder einer komprimierten spärlichen Kodierung ausgegeben werden.
  • Die Raytracing-Kerne 372 können Raytracing-Operationen sowohl für Echtzeit- als auch für Nicht-Echtzeit-Umsetzungen beschleunigen. Insbesondere können die Raytracing-Kerne 372 Schaltungsanordnungen für die Strahlendurchquerung/den Schnittpunkt umfassen, um eine Strahlendurchquerung unter Verwendung von Bounding-Volume-Hierarchien (BVHs) auszuführen und Schnittpunkten zwischen Strahlen und in den BVH-Volumen eingeschlossenen Primitiven zu identifizieren. Die Raytracing-Kerne 372 können auch Schaltungsanordnungen zur Ausführung von Tiefenprüfung und Culling umfassen (z. B. unter Verwendung eines Z-Puffers oder einer ähnlichen Anordnung). In einer Umsetzung führen die Raytracing-Kerne 372 Quer- und Schnittoperationen zusammen mit den hierin beschriebenen Bildentrauschungstechniken durch, von denen zumindest ein Abschnitt auf den Tensorkerne 371 ausgeführt werden kann. Beispielsweise können die Tensorkerne 371 ein neuronales Netzwerk mit tiefem Lernen umsetzen, um eine Rauschunterdrückung von Bildern auszuführen, die von den Raytracing-Kernen 372 erzeugt wurden. Die CPU(s) 361, Grafikkerne 370 und/oder Raytracing-Kerne 372 können jedoch auch alle oder einen Abschnitt der Rauschunterdrückungs- und/oder Deep-Learning-Algorithmen umsetzen.
  • Außerdem kann, wie oben beschrieben, ein verteilter Ansatz zur Rauschunterdrückung verwendet werden, bei dem sich die GPU 380 in einer Rechnervorrichtung befindet, das über ein Netzwerk oder eine Hochgeschwindigkeitsverbindung mit anderen Rechenvorrichtungen verbunden ist. Bei diesem verteilten Ansatz können die miteinander verbundenen Computervorrichtungen die Lern-/Trainingsdaten des neuronalen Netzwerks gemeinsam nutzen, um die Geschwindigkeit zu verbessern, mit der das Gesamtsystem lernt, die Rauschunterdrückung für verschiedene Arten von Bildrahmen und/oder verschiedene Grafikanwendungen auszuführen.
  • Die Raytracing-Kerne 372 können alle BVH-Queren und/oder strahlenprimitive Schnittpunkte verarbeiten, wodurch die Grafik-Kerne 370 nicht mit Tausenden von Anweisungen pro Strahl überlastet werden. Beispielsweise umfasst jeder Raytracing-Kern 372 einen ersten Satz spezialisierter Schaltungsanordnungen zur Ausführung von Bounding-Box-Tests (z. B. für Quer-Operationen) und/oder einen zweiten Satz spezialisierter Schaltungsanordnungen zur Ausführung der Strahl-Dreieck-Schnittpunkttests (z. B. zum Schneiden von Strahlen, die traversiert wurden). So kann z. B. die Multi-Core-Gruppe 365A einfach eine Ray-Probe starten, und die Raytracing-Kerne 372 führen unabhängig voneinander Strahlquerbewegung und Schneiden durch und geben Trefferdaten (z. B. einen Treffer, keinen Treffer, mehrere Treffer usw.) an den Thread-Kontext zurück. Die anderen Kerne 370, 371 sind frei für andere Grafik- oder Rechenaufgaben, während die Raytracing-Kerne 372 die Quer- und Schnittoperationen ausführen.
  • Optional kann jeder Raytracing-Kern 372 eine Quereinheit zur Ausführung von BVH-Prüfoperationen und/oder eine Schnittpunkteinheit umfassen, die strahlenprimitive Schnittpunkttests ausführt. Die Schnittpunkteinheit erzeugt eine „Treffer“-, „kein Treffer“- oder „mehrere Treffer“-Antwort, die sie an den entsprechenden Thread weitergibt. Während der Quer- und Schnittoperationen werden die Ausführungsressourcen der anderen Kerne (z. B. Grafikkerne 370 und Tensorkerne 371) freigegeben, um andere Formen der Grafikarbeit auszuführen.
  • In einer optionalen Ausführungsform, die nachfolgend beschrieben ist, wird ein hybrider Rasterisierungs-/Raytracing-Ansatz verwendet, bei dem die Arbeit zwischen den Grafikkernen 370 und den Raytracing-Kernen 372 verteilt wird.
  • Die Raytracing-Kerne 372 (und/oder andere Kerne 370, 371) können Hardwareunterstützung für einen Raytracing-Anweisungssatz wie DirectX Ray Tracing (DXR) von Microsoft umfassen, der einen DispatchRays-Befehl sowie Ray-Generierung, Closest-Hit-, Any-Hit- und Miss-Shader umfasst, die die Zuweisung eindeutiger Sätze von Shadern und Texturen für jedes Objekt ermöglichen. Eine weitere Raytracing-Plattform, die von den Raytracing-Kerne 372, Grafik-Kerne 370 und Tensorkerne 371 unterstützt werden kann, ist Vulkan 1.1.85. Beachten Sie jedoch, dass die hierin beschriebenen Grundsätze nicht auf ein bestimmtes Raytracing ISA beschränkt sind.
  • Allgemein können die verschiedenen Kerne 372, 371, 370 einen Raytracing-Anweisungssatz unterstützen, der Befehle/Funktionen für eine oder mehrere der folgenden Funktionen umfasst: Strahlenerzeugung, nächstgelegener Treffer, beliebiger Treffer, Strahlen-Primitivschnittpunkt, Konstruktion von vorprimitiven und hierarchischen Begrenzungsrahmen, Fehlschuss, Besuch und Ausnahmen. Genauer gesagt umfasst eine bevorzugte Ausführungsform Anweisungen zur Strahlenverfolgung, um eine oder mehrere der folgenden Funktionen auszuführen:
  • Strahlenerzeugung - Anweisungen zur Strahlenerzeugung können für jedes Pixel, jede Probe oder eine andere benutzerdefinierte Arbeitszuweisung ausgeführt werden.
  • Nächster Treffer - Eine Anweisung für den nächsten Treffer kann ausgeführt werden, um den nächstgelegenen Schnittpunkt eines Strahls mit Primitiven innerhalb einer Szene zu finden.
  • Jeder Treffer - Eine Anweisung für jeden Treffer identifiziert mehrere Schnittpunkte zwischen einem Strahl und Primitiven innerhalb einer Szene, um möglicherweise einen neuen nächstgelegenen Schnittpunkt zu identifizieren.
  • Schnittpunkt - Eine Schnittpunktanweisung führt eine strahlenprimitive Schnittpunktprüfung durch und gibt ein Ergebnis aus.
  • Konstruktion eines Begrenzungsrahmens pro Primitiv - Dieser Befehl erstellt einen Begrenzungsrahmen um ein bestimmtes Primitiv oder eine Gruppe von Primitiven (z. B. beim Erstellen einer neuen BVH- oder einer anderen Beschleunigungsdatenstruktur).
  • Verfehlung - Gibt an, dass ein Strahl die gesamte Geometrie innerhalb einer Szene oder einer bestimmten Region einer Szene verfehlt.
  • Besuch - Gibt an, welche untergeordneten Volumen ein Strahl durchlaufen wird.
  • Ausnahmen - Umfasst verschiedene Arten von Ausnahme-Handlern (z. B., die für verschiedene Fehlerbedingungen aufgerufen werden).
  • In einer Ausführungsform können die Raytracing-Kerne 245 so angepasst werden, dass sie Allzweck-Rechenoperationen beschleunigen, die mit Rechentechniken beschleunigt werden können, die analog zu Strahlenschnittpunkttests sind. Es kann ein Rechner-Framework bereitgestellt werden, das es ermöglicht, Shader-Programme in Low-Level-Anweisungen und/oder Primitive zu kompilieren, die Allzweck-Rechenoperationen über die Raytracing-Kerne ausführen. Zu den beispielhaften Berechnungsproblemen, die von den auf den Strahlverfolgungskernen 245 ausgeführten Rechenoperationen profitieren können, gehören Berechnungen, die die Ausbreitung von Strahlen, Wellen, Strahlen oder Teilchen in einem Koordinatenraum betreffen. Die mit dieser Ausbreitung verbundenen Wechselwirkungen können relativ zu einer Geometrie oder einem Netz im Koordinatenraum berechnet werden. So können z. B. Berechnungen im Zusammenhang mit der Ausbreitung elektromagnetischer Signale durch eine Umgebung durch die Verwendung von Anweisungen oder Primitiven beschleunigt werden, die über die Raytracing-Kerne ausgeführt werden. Beugung und Reflexion der Signale an Objekten in der Umgebung können als direkte Raytracing-Analogien berechnet werden.
  • Die Raytracing-Kerne 245 können auch für Berechnungen verwendet werden, die nicht direkt mit dem Raytracing vergleichbar sind. Beispielsweise können Netzprojektion, Netzverfeinerung und Volumensampling-Berechnungen mit den Raytracing-Kernen 245 beschleunigt werden. Allgemeine Koordinatenraumberechnungen, wie z. B. die Berechnung der nächsten Nachbarn, können ebenfalls ausgeführt werden. So kann z. B. die Menge der Punkte in der Nähe eines bestimmten Punktes ermittelt werden, indem ein Begrenzungsrahmen im Koordinatenraum um den Punkt definiert wird. Die BVH- und Strahlensondenlogik innerhalb der Raytracing-Kerne 245 kann dann verwendet werden, um die Menge der Punktschnittpunkte innerhalb der Bounding Box zu bestimmen. Die Schnittpunkte bilden den Ursprungspunkt und die nächstgelegenen Nachbarn zu diesem Ursprungspunkt. Berechnungen, die mit den Raytracing-Kernen 245 ausgeführt werden, können parallel zu Berechnungen auf den Grafikkernen 243 und Tensorkernen 244 ausgeführt werden. Ein Shader-Compiler kann so konfiguriert sein, dass er einen Rechner-Shader oder ein anderes Allzweck-Grafikverarbeitungsprogramm in Low-Level-Primitive kompiliert, die über die Grafikkerne 243, die Tensorkerne 244 und die Raytracing-Kerne 245 parallelisiert werden können.
  • Techniken für die Verbindung zwischen GPU und Host-Prozessor
  • 4A illustriert eine beispielhafte Architektur, in der mehrere GPUs 410 bis 413, z. B. wie die Parallelprozessoren 200 in 2A, sind über Hochgeschwindigkeitsverbindungen 440A bis 440D (z. B. Busse, Punkt-zu-Punkt-Verbindungen usw.) kommunikativ mit mehreren Mehrkernprozessoren 405 bis 406 gekoppelt. Die Hochgeschwindigkeitsverbindungen 440A bis 440D können je nach Umsetzung einen Kommunikationsdurchsatz von 4GB/s, 30GB/s, 80GB/s oder höher unterstützen. Es können verschiedene Interconnect-Protokolle verwendet werden, unter anderem, aber nicht beschränkt auf PCIe 4.0 oder 5.0 und NVLink 2.0. Die hierin beschriebenen Grundsätze sind jedoch nicht auf ein bestimmtes Kommunikationsprotokoll oder einen bestimmten Durchsatz beschränkt.
  • Zwei oder mehr der GPUs 410 bis 413 können über Hochgeschwindigkeitsverbindungen 442A bis 442B miteinander verbunden werden, die mit denselben oder anderen Protokollen/Verbindungen umgesetzt werden können als die für die Hochgeschwindigkeitsverbindungen 440A bis 440D verwendeten. Ähnlich Weise können zwei oder mehr der Mehrkernprozessoren 405 bis 406 über eine Hochgeschwindigkeitsverbindung 443 verbunden sein, bei der es sich um einen symmetrischen Multiprozessor-Bus (SMP-Bus) handeln kann, der mit 20GB/s, 30GB/s, 120GB/s oder niedrigeren oder höheren Geschwindigkeiten arbeitet. Alternativ kann die gesamte Kommunikation zwischen den verschiedenen Systemkomponenten in 4A mit den gleichen Protokollen/Links (z. B. über eine gemeinsame Verbindungsstruktur) erfolgen. Wie erwähnt, sind die hierin beschriebenen Grundsätze jedoch nicht auf einen bestimmten Typ von Verbindungstechnologie beschränkt.
  • Jeder Mehrkernprozessor 405 bis 406 kann kommunikativ mit einem Prozessorspeicher 401 bis 402 über Speicherverbindungen 430A bis 430B verbunden sein, und jeder Grafikprozessor 410 bis 413 ist kommunikativ mit dem Grafikprozessorspeicher 420 bis 423 über Grafikprozessorspeicherverbindungen 450A bis 450D verbunden. Die Speicherverbindungen 430A bis 430B und 450A bis 450D können dieselben oder unterschiedliche Speicherzugriffstechnologien verwenden. Die Prozessorspeicher 401 bis 402 und die GPU-Speicher 420 bis 423 können beispielsweise flüchtige Speicher wie dynamische Direktzugriffsspeicher (DRAMs) (unter anderem gestapelte 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 flüchtig und ein anderer Abschnitt nicht flüchtig sein (z. B. unter Verwendung einer zweistufigen Speicherhierarchie (2LM)). Ein Speichersubsystem, wie hierin beschrieben, kann mit einer Reihe von Speichertechnologien kompatibel sein, z. B. mit Double Data Rate-Versionen, die von JEDEC (Joint Electronic Device Engineering Council) freigegeben wurden.
  • Wie nachfolgend beschrieben, können die verschiedenen Prozessoren 405 bis 406 und GPUs 410 bis 413 zwar physisch mit einem bestimmten Speicher 401 bis 402 bzw. 420 bis 423 verbunden sein, es kann jedoch eine einheitliche Speicherarchitektur umgesetzt werden, bei der derselbe virtuelle Systemadressraum (auch als „effektiver Adressraum“ bezeichnet) auf alle verschiedenen physischen Speicher verteilt ist. Beispielsweise können die Prozessorspeicher 401 bis 402 jeweils 64 GB des Adressraums des Systemspeichers und die GPU-Speicher 420 bis 423 jeweils 32 GB des Adressraums des Systemspeichers umfassen (was in diesem Beispiel zu einem adressierbaren Gesamtspeicher von 256 GB führt).
  • 4B illustriert zusätzliche optionale Details für eine Verbindung zwischen einem Mehrkernprozessor 407 und einem Grafikbeschleunigungsmodul 446. Das Grafikbeschleunigungsmodul 446 kann einen oder mehrere GPU-Chips umfassen, die auf einer Linecard integriert sind, die über die Hochgeschwindigkeitsverbindung 440 mit dem Prozessor 407 gekoppelt ist. Alternativ kann das Grafikbeschleunigungsmodul 446 auch auf demselben Package oder Chip wie der Prozessor 407 integriert sein.
  • Der illustrierte Prozessor 407 umfasst mehrere Kernen 460A bis 460D, jeder mit einem Übersetzungs-Lookaside-Puffer 461A bis 461D und einem oder mehreren Caches 462A bis 462D. Die Kerne können verschiedene andere Komponenten für die Ausführung von Befehlen und die Verarbeitung von Daten umfassen, die nicht illustriert sind, um die Grundsätze der hierin beschriebenen Komponenten nicht zu verdecken (z. B. Befehlsabrufeinheiten, Verzweigungsvorhersageeinheiten, Decoder, Ausführungseinheiten, Reorder-Puffer usw.). Die Caches 462A bis 462D können Caches auf Level 1 (L1) und Level 2 (L2) umfassen. Zusätzlich können ein oder mehrere gemeinsam genutzte Caches 456 in der Caching-Hierarchie umfasst sein und von Gruppen der Kerne 460A bis 460D gemeinsam genutzt werden. Eine Ausführungsform des Prozessors 407 umfasst beispielsweise 24 Kerne, jeder mit einem eigenen L1 -Cache, zwölf gemeinsam genutzten L2-Caches und zwölf gemeinsam genutzten L3-Caches. In dieser Ausführungsform wird einer der L2 und L3 Caches von zwei benachbarten Kernen gemeinsam genutzt. Der Prozessor 407 und das Grafikbeschleuniger-Integrationsmodul 446 sind mit dem Systemspeicher 441 verbunden, der die Prozessorspeicher 401 bis 402 umfassen kann.
  • Die Kohärenz wird für Daten und Anweisungen, die in den verschiedenen Caches 462A bis 462D, 456 und im Systemspeicher 441 gespeichert sind, über eine Inter-Core-Kommunikation über einen Kohärenzbus 464 aufrechterhalten. Beispielsweise kann jeder Cache über eine Cache-Kohärenzlogik/-schaltungsanordnung verfügen, die mit ihm verbunden ist, um über den Kohärenzbus 464 als Reaktion auf erkannte Lese- oder Schreibvorgänge auf bestimmte Cache-Zeilen zu kommunizieren. In einer Umsetzung wird ein Cache-Snooping-Protokoll über den Kohärenzbus 464 umgesetzt, um Cache-Zugriffe auszuspähen. Cache-Snooping/Kohärenz-Techniken sind Fachleuten auf dem Gebiet bekannt und werden hier nicht im Detail beschrieben, um die hierin beschriebenen Grundsätze nicht zu verschleiern.
  • Es kann eine Proxy-Schaltung 425 vorgesehen werden, die das Grafikbeschleunigungsmodul 446 kommunikativ mit dem Kohärenzbus 464 koppelt, sodass das Grafikbeschleunigungsmodul 446 als Peer der Kerne am Cache-Kohärenzprotokoll teilnehmen kann. Insbesondere bietet eine Schnittstelle 435 Konnektivität zum Proxy-Schaltung 425 über die Hochgeschwindigkeitsverbindung 440 (z. B. ein PCIe-Bus, NVLink usw.) und eine Schnittstelle 437 verbindet das Grafikbeschleunigungsmodul 446 mit der Hochgeschwindigkeitsverbindung 440.
  • In einer Umsetzung bietet eine Beschleuniger-Integrationsschaltung 436 Cache-Verwaltung, Speicherzugriff, Kontextverwaltung und Interrupt-Verwaltungsdienste für mehrere Grafikverarbeitungsengines 431, 432, N des Grafikbeschleunigungsmoduls 446. Die Grafikprozessoren 431, 432, N können jeweils eine separate Grafikprozessoreinheit (GPU) umfassen. Alternativ können die Grafikverarbeitungsengines 431, 432, N verschiedene Arten von Grafikverarbeitungsengines innerhalb einer GPU umfassen, wie z. B. Grafikausführungseinheiten, Medienverarbeitungsengines (z. B. Video-Encoder/Decoder), Sampler und Blit-Engines. Mit anderen Worten, das Grafikbeschleunigungsmodul kann ein Grafikprozessor mit mehreren Grafikverarbeitungsengines 431 bis 432, N sein oder die Grafikverarbeitungsengines 431 bis 432, N können einzelne Grafikprozessoren sein, die auf einem gemeinsamen Package, einer Linecard oder einem Chip integriert sind.
  • Die Beschleuniger-Integrationsschaltung 436 kann eine Speicherverwaltungseinheit (MMU) 439 umfassen, um verschiedene Speicherverwaltungsfunktionen auszuführen, wie z. B. Übersetzungen von virtuellem in physischen Speicher (auch als Übersetzungen von effektivem in realen Speicher bezeichnet) und Speicherzugriffsprotokolle für den Zugriff auf den Systemspeicher 441. Die MMU 439 kann auch einen Übersetzungs-Lookaside-Buffer (TLB) (nicht dargestellt) für die Zwischenspeicherung der Übersetzungen von virtuellen/effektiven zu physischen/realen Adressen umfassen. In einer Umsetzung speichert ein Cache 438 Befehle und Daten für den effizienten Zugriff durch die Grafikverarbeitungsengines 431, 432, N. Die im Cache 438 und in den Grafikspeichern 433 bis 434, M gespeicherten Daten können mit den Kern-Caches 462A bis 462D, 456 und dem Systemspeicher 441 kohärent gehalten werden. Wie bereits erwähnt, kann dies über die Proxy-Schaltung 425 erfolgen, die im Namen des Cache 438 und der Speicher 433 bis 434, M am Cache-Kohärenzmechanismus teilnimmt (z. B. Senden von Aktualisierungen an den Cache 438 in Bezug auf Änderungen/Zugriffe auf Cache-Zeilen in den Prozessor-Caches 462A bis 462D, 456 und Empfangen von Aktualisierungen vom Cache 438).
  • Ein Satz von Registern 445 speichert Kontextdaten für Threads, die von den Grafikverarbeitungsmodulen 431 bis 432, N ausgeführt werden, und eine Kontextmanagementschaltung 448 verwaltet die Thread-Kontexte. Beispielsweise kann die Kontextmanagementschaltung 448 Speicher- und Wiederherstellungsoperationen ausführen, um Kontexte der verschiedenen Threads während Kontextumschaltungen zu speichern und wiederherzustellen (z. B. wenn ein erster Thread gespeichert und ein zweiter Thread wiederhergestellt wird, damit der zweite Thread von einer Grafikverarbeitungsmaschine ausgeführt werden kann). Beispielsweise kann die Kontextmanagementschaltung 448 bei einem Kontextwechsel aktuelle Registerwerte in einer bestimmten Region im Speicher speichern (z. B. identifiziert durch einen Kontextzeiger). Sie kann dann bei der Rückkehr zum Kontext die Registerwerte wiederherstellen. Eine Interrupt-Managementschaltung 447 kann z. B. von Systemvorrichtungen empfangene Interrupts empfangen und verarbeiten.
  • In einer Umsetzung werden virtuelle/effektive Adressen von einer Grafikverarbeitungsengine 431 durch die MMU 439 in reale/physikalische 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 bestimmt sein, die auf dem Prozessor 407 ausgeführt wird, oder es kann von mehreren Anwendungen gemeinsam genutzt werden. Optional wird eine virtualisierte Grafikausführungsumgebung bereitgestellt, in der die Ressourcen der Grafikverarbeitungsengines 431 bis 432, N mit mehreren Anwendungen, virtuellen Maschinen (VMs) oder Containern gemeinsam genutzt werden. Die Ressourcen können in „Slices“ unterteilt werden, die verschiedenen VMs und/oder Anwendungen basierend auf den mit den VMs und/oder Anwendungen verbundenen Verarbeitungsanforderungen und Prioritäten zugewiesen werden. VMs und Container können hier austauschbar verwendet werden.
  • Eine virtuelle Maschine (VM) kann eine Software sein, die ein Betriebssystem und eine oder mehrere Anwendungen ausführt. Eine VM kann durch eine Spezifikation, Konfigurationsdateien, eine virtuelle Festplattendatei, eine Einstellungsdatei für den nichtflüchtigen Direktzugriffsspeicher (NVRAM) und die Protokolldatei definiert werden und wird durch die physischen Ressourcen einer Host-Computerplattform unterstützt. Eine VM kann ein Betriebssystem (OS) oder eine Anwendungsumgebung umfassen, die auf einer Software installiert ist, die eine dedizierte Hardware imitiert. Der Endanwender hat auf einer virtuellen Maschine die gleiche Erfahrung wie auf dedizierter Hardware. Eine spezielle Software, die als Hypervisor bezeichnet wird, emuliert die CPU, den Arbeitsspeicher, die Festplatte, das Netzwerk und andere Hardwareressourcen des PC-Clients oder Servers vollständig, sodass virtuelle Maschinen die Ressourcen gemeinsam nutzen können. Der Hypervisor kann mehrere virtuelle Hardware-Plattformen emulieren, die voneinander isoliert sind, sodass virtuelle Maschinen Linux®, Windows® Server, VMware ESXi und andere Betriebssysteme auf demselben zugrunde liegenden physischen Host ausführen können.
  • Ein Container kann ein Softwarepaket von Anwendungen, Konfigurationen und Abhängigkeiten sein, sodass die Anwendungen zuverlässig auf einer Computerumgebung zu einer anderen laufen. Container können sich ein auf der Serverplattform installiertes Betriebssystem teilen und als isolierte Prozesse laufen. Ein Container kann ein Softwarepaket sein, das alles umfasst, was die Software zum Ausführen benötigt, z. B. 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 Art von Containern bietet mehrere Vorteile. Erstens läuft die Software in einem Container in verschiedenen Umgebungen gleich. So kann beispielsweise ein Container, der PHP und MySQL umfasst, sowohl auf einem Linux®-Rechner als auch auf einem Windows®-Rechner identisch laufen. Zweitens geben Container zusätzliche Sicherheit, da die Software das Host-Betriebssystem nicht beeinflusst. Während eine installierte Anwendung Systemeinstellungen ändern und Ressourcen, wie z. B. die Windows-Registrierung, modifizieren kann, kann ein Container nur Einstellungen innerhalb des Containers ändern.
  • Somit wirkt die Beschleuniger-Integrationsschaltung 436 als Brücke zum System für das Grafikbeschleunigungsmodul 446 und bietet Adressübersetzung und Systemspeicher-Cache-Dienste. In einer Ausführungsform kann die Beschleuniger-Integrationsschaltung 436 zur Erleichterung der Überbrückungsfunktionalität auch gemeinsam genutzte E/A 497 (z. B. PCIe, USB oder andere) und Hardware umfassen, um die Systemsteuerung von Spannung, Taktung, Leistung, Thermik und Sicherheit zu ermöglichen. Der gemeinsam genutzte E/A 497 kann separate physikalische Verbindungen nutzen oder die Hochgeschwindigkeitsverbindung 440 durchlaufen. Außerdem kann die Beschleuniger-Integrationsschaltung 436 Virtualisierungsfunktionen für den Host-Prozessor bereitstellen, um die Virtualisierung der Grafikverarbeitungsengines, Interrupts und die Speicherverwaltung zu verwalten.
  • Da die Hardware-Ressourcen der Grafikverarbeitungsengines 431 bis 432, N explizit auf den realen Adressraum abgebildet werden, den der Host-Prozessor 407 sieht, kann jeder Host-Prozessor diese Ressourcen direkt über einen effektiven Adresswert ansprechen. Eine optionale Funktion der Beschleuniger-Integrationsschaltung 436 ist die physikalische Trennung der Grafikverarbeitungsengines 431 bis 432, N, sodass sie dem System als unabhängige Einheiten erscheinen.
  • Ein oder mehrere Grafikspeicher 433 bis 434, M können jeweils mit jeder der Grafikverarbeitungsmaschinen 431 bis 432, N gekoppelt sein. Die Grafikspeicher 433 bis 434, M speichern Anweisungen und Daten, die von jeder der Grafikverarbeitungsengines 431 bis 432, N verarbeitet werden. Bei den Grafikspeichern 433 bis 434, M kann es sich um flüchtige Speicher wie DRAMs (unter anderem gestapelter DRAMs), GDDR-Speicher (z. B. GDDR5, GDDR6) oder HBM und/oder um nichtflüchtige Speicher wie 3D XPoint/Optane, Samsung Z-NAND oder Nano-RAM handeln.
  • Um den Datenverkehr über die Hochgeschwindigkeitsverbindung 440 zu verringern, können Vorbeaufschlagungstechniken verwendet werden, um sicherzustellen, dass die in den Grafikspeichern 433 bis 434, M gespeicherten Daten Daten sind, die am häufigsten von den Grafikverarbeitungsengines 431 bis 432, N und vorzugsweise nicht von den Kernen 460A bis 460D (zumindest nicht häufig) verwendet werden. Ähnlich versucht der Vorbeaufschlagungsmechanismus, Daten, die von den Kernen (und vorzugsweise nicht von den Grafikverarbeitungsengines 431 bis 432, N) benötigt werden, in den Caches 462A bis 462D, 456 der Kerne und im Systemspeicher 441 zu halten.
  • Nach einer in 4C gezeigten Variante ist die Beschleuniger-Integrationsschaltung 436 in den Prozessor 407 integriert. Die Grafikverarbeitungsengines 431 bis 432, N kommunizieren direkt über die Hochgeschwindigkeitsverbindung 440 mit der Beschleuniger-Integrationsschaltung 436 über die Schnittstelle 437 und die Schnittstelle 435 (die wiederum jede Form von Bus oder Schnittstellenprotokoll verwenden kann). Die Beschleuniger-Integrationsschaltung 436 kann die gleichen Operationen ausführen, die in 4B beschrieben sind, erfolgt jedoch potenziell mit einem höheren Durchsatz aufgrund der unmittelbaren Nähe zum Kohärenzbus 464 und den Caches 462A bis 462D, 456.
  • Die beschriebenen Ausführungsformen können verschiedene Programmiermodelle unterstützen, darunter ein Programmiermodell mit dediziertem Prozess (ohne Virtualisierung des Grafikbeschleunigungsmoduls) und gemeinsam genutzte Programmiermodelle (mit Virtualisierung). Letztere können Programmiermodelle umfassen, die von der Beschleuniger-Integrationsschaltung 436 gesteuert werden, und Programmiermodelle, die vom Grafikbeschleunigungsmodul 446 gesteuert werden.
  • In den Ausführungsformen des dedizierten Prozessmodells können die Grafikverarbeitungsmaschinen 431, 432, ... N für eine einzelne Anwendung oder einen einzelnen Prozess unter einem einzelnen Betriebssystem bestimmt sein. Die einzelne Anwendung kann andere Anwendungsanforderungen an die Grafik-Engines 431, 432, ... N weiterleiten und bietet Virtualisierung innerhalb einer VM/Partition.
  • In den Programmiermodellen mit dedizierten Prozessen können die Grafikverarbeitungsengines 431,432, N, von mehreren VM-/Anwendungspartitionen gemeinsam genutzt werden. Die gemeinsam genutzten Modelle erfordern einen System-Hypervisor zur Virtualisierung der Grafikverarbeitungsengines 431 bis 432, N, um den Zugriff durch jedes Betriebssystem zu ermöglichen. Bei Single-Partition-Systemen ohne Hypervisor unterliegen die Grafikverarbeitungsengines 431 bis 432, N der Kontrolle des Betriebssystems. In beiden Fällen kann das Betriebssystem die Grafikverarbeitungsengines 431 bis 432, N virtualisieren, um jedem Prozess oder jeder Anwendung Zugriff zu gewähren.
  • Für das gemeinsame Programmiermodell wählt das Grafikbeschleunigungsmodul 446 oder eine einzelne Grafikverarbeitungsengine 431 bis 432, N ein Prozesselement mit einem Prozesshandle aus. Die Prozesselemente können im Systemspeicher 441 gespeichert und mit den hierin beschriebenen Techniken zur Übersetzung von effektiven Adressen in reale Adressen adressierbar sein. Das Prozesshandle kann ein umsetzungsspezifischer Wert sein, der dem Host-Prozess zur Verfügung gestellt wird, wenn er seinen Kontext bei der Grafikverarbeitungsengine 431 bis 432, N registriert (d. h. die Systemsoftware aufruft, um das Prozesselement zur verknüpften Prozesselementliste hinzuzufügen). Die unteren 16 Bits des Prozesshandles können der Offset des Prozesselements innerhalb der Prozesselement-Verknüpfungsliste sein.
  • 4D illustriert eine beispielhafte Beschleuniger-Integrationsscheibe 490. Wie hier verwendet, umfasst ein „Slice“ einen bestimmten Abschnitt der Verarbeitungsressourcen der Beschleuniger-Integrationsschaltung 436. Der anwendungseffektive Adressraum 482 innerhalb des Systemspeichers 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 umfasst den Prozesszustand für die entsprechende Applikation 480. Ein im Prozesselement 483 umfassener Workdeskriptor (WD) 484 kann ein einzelner, von einer Anwendung angeforderter Job sein oder einen Zeiger auf eine Warteschlange von Aufträgen umfassen. Im letzteren Fall ist der WD 484 ein Zeiger auf die Job-Request-Queue im Adressraum 482 der Anwendung.
  • Das Grafikbeschleunigungsmodul 446 und/oder die einzelnen Grafikverarbeitungsengines 431 bis 432, N können von allen oder einer Teilmenge der Prozesse im System gemeinsam genutzt werden. Die hierin beschriebenen Technologien können beispielsweise eine Infrastruktur zum Einrichten des Prozessstatus und zum Senden eines WD 484 an ein Grafikbeschleunigungsmodul 446 umfassen, um einen Auftrag in einer virtualisierten Umgebung zu starten.
  • In einer Umsetzung ist das Dedicated-Process-Programmiermodell umsetzungsspezifisch. In diesem Modell besitzt ein einzelner Prozess das Grafikbeschleunigungsmodul 446 oder eine einzelne Grafikverarbeitungsengine 431. Da das Grafikbeschleunigungsmodul 446 von einem einzelnen Prozesses kontrolliert wird, initialisiert der Hypervisor die Beschleuniger-Integrationsschaltung 436 für die besitzende Partition und das Betriebssystem initialisiert die Beschleuniger-Integrationsschaltung 436 für den besitzenden Prozess zu dem Zeitpunkt, zu dem das Grafikbeschleunigungsmodul 446 zugewiesen wird.
  • Im Betrieb holt eine WD-Abrufeinheit 491 in der Beschleuniger-Integrationsscheibe 490 die nächste WD 484, die eine Angabe der Arbeit umfasst, die von einer der Grafikverarbeitungsmaschinen des Grafikbeschleunigungsmoduls 446 zu erledigen ist. Daten vom WD 484 können in Registern 445 gespeichert und von der MMU 439, der Interrupt-Managementschaltung 447 und/oder der Kontextmanagementschaltung 448 verwendet werden, wie illustriert. Beispielsweise kann die MMU 439 eine Segment-/Seitenlaufschaltungsanordnung für den Zugriff auf Segment-/Seitentabellen 486 innerhalb des virtuellen Adressraums 485 des Betriebssystems umfassen. Die Interrupt-Managementschaltung 447 kann vom Grafikbeschleunigungsmodul 446 empfangene Interrupt-Ereignisse 492 verarbeiten. Bei der Ausführung von Grafikoperationen wird eine von einer Grafikverarbeitungsengine 431 bis 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 Grafikverarbeitungsengine 431 bis 432, N und/oder jedes Grafikbeschleunigungsmodul 446 dupliziert werden und kann vom Hypervisor oder Betriebssystem initialisiert werden. Jedes dieser duplizierten Register kann in einer Beschleuniger-Integrationsscheibe 490 umfasst sein. In einer Ausführungsform kann jede Grafikverarbeitungsengine 431 bis 432, N dem Hypervisor 496 als ein eigene Grafikprozessorvorrichtung präsentiert werden. QoS-Einstellungen können für Clients einer bestimmten Grafikverarbeitungsengine 431 bis 432 konfiguriert sein, N und Datenisolierung zwischen den Clients jeder Engine können aktiviert werden. Beispielhafte Register, die vom Hypervisor initialisiert werden können, sind in Tabelle 1 dargestellt. Tabelle 1 - Vom Hypervisor initialisierte Register
    1 Slice-Control-Register
    2 Reale Adresse (RA) Bereichszeiger für geplante Prozesse
    3 Autoritätsmasken-Überschreibungsregister
    4 Interrupt-Vektor-Tabelleneintragsabstand
    5 Interrupt-Vektor-Tabelleneintragsgrenze
    6 Zustandsregister
    7 Logische Partitions-ID
    8 Reale Adresse (RA) Satzzeiger für Verwendung des Hypervisor-Beschleunigers
    9 Speicherbeschreibungsregister
  • Beispielhafte Register, die vom Betriebssystem initialisiert werden können, sind in Tabelle 2 dargestellt. Tabelle 2 - Vom Betriebssystem initialisierte Register
    1 Prozess- und Thread-Identifikation
    2 Zeiger für Speichern/Wiederherstellen im Kontext mit effektiver Adresse (EA)
    3 Satzzeiger für Verwendung des-Beschleunigers mit virtueller Adresse (VA)
    4 Speichersegmenttabellenzeiger mit virtueller Adresse (VA)
    5 Autoritätenmaske
    6 Arbeitsbeschreibung
  • Jedes WD 484 kann spezifisch für ein bestimmtes Grafikbeschleunigungsmodul 446 und/oder eine Grafikverarbeitungsengine 431 bis 432, N sein. Es umfasst alle Informationen, die eine Grafikverarbeitungsengine 431 bis 432, N benötigt, um ihre Arbeit zu verrichten, oder es kann ein Zeiger auf einen Speicherplatz sein, an dem die Anwendung eine Befehlswarteschlange von zu verrichtender Arbeit eingerichtet hat.
  • 4E illustriert zusätzliche optionale Details eines gemeinsamen Modells. Dies umfasst einen realen Hypervisor-Adressraum 498, in dem eine Prozesselementliste 499 gespeichert ist. Der Zugriff auf den realen Adressraum 498 erfolgt über einen Hypervisor 496, der die Engines der Grafikbeschleunigungsmodule für das Betriebssystem 495 virtualisiert.
  • Die gemeinsam genutzten Programmiermodelle ermöglichen es, dass alle oder eine Teilmenge von Prozessen aus allen oder einer Teilmenge von Partitionen im System ein Grafikbeschleunigungsmodul 446 verwenden. Es gibt zwei Programmiermodelle, bei denen das Grafikbeschleunigungsmodul 446 von mehreren Prozessen und Partitionen gemeinsam genutzt wird: geteilte Zeitscheiben und Teilung nach Grafikvorgabe.
  • In diesem Modell besitzt der System-Hypervisor 496 das Grafikbeschleunigungsmodul 446 und stellt dessen Funktion allen Betriebssystemen 495 zur Verfügung. Damit ein Grafikbeschleunigungsmodul 446 die Virtualisierung durch den Systemhypervisor 496 unterstützt, kann das Grafikbeschleunigungsmodul 446 die folgenden Anforderungen einhalten: 1) Die Auftragsanforderung einer Anwendung muss autonom sein (d. h. der Zustand muss zwischen den Aufträgen nicht beibehalten werden), oder das Grafikbeschleunigungsmodul 446 muss einen Mechanismus zum Speichern und Wiederherstellen des Kontexts bereitstellen. 2) Das Grafikbeschleunigungsmodul 446 garantiert, dass die Auftragsanforderung einer Anwendung in einer bestimmten Zeitspanne abgeschlossen wird, unter anderem etwaiger Übersetzungsfehler, oder das Grafikbeschleunigungsmodul 446 bietet die Möglichkeit, die Bearbeitung des Auftrags vorzuziehen. 3) Für das Grafikbeschleunigungsmodul 446 muss Fairness zwischen den Prozessen garantiert werden, wenn es im gerichteten gemeinsamen Programmiermodell arbeitet.
  • Für das gemeinsam genutzte Modell muss die Anwendung 480 möglicherweise einen Systemaufruf des Betriebssystems 495 mit einem Grafikbeschleunigungsmodultyp 446, einem Arbeitsdeskriptor (WD), einem Authority-Mask-Register-Wert (AMR-Wert) und einem Zeiger für Speichern/Wiederherstellen im Kontext (CSRP) ausführen. Der Typ Grafikbeschleunigungsmodul 446 beschreibt die angestrebte Beschleunigungsfunktion für den Systemaufruf. Der Typ des Grafikbeschleunigungsmoduls 446 kann ein systemspezifischer Wert sein. Die WD ist speziell für das Grafikbeschleunigungsmodul 446 formatiert und kann in Form eines Grafikbeschleunigungsmodul 446-Befehls, eines effektiven Adresszeigers auf eine benutzerdefinierte Struktur, eines effektiven Adresszeigers auf eine Befehlswarteschlange oder einer anderen Datenstruktur vorliegen, um die vom Grafikbeschleunigungsmodul 446 zu verrichtende Arbeit zu beschreiben. 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 ist vergleichbar mit einer Anwendung, die den AMR einstellt. Wenn die Umsetzungen der Beschleuniger-Integrationsschaltung 436 und des Grafikbeschleunigungsmoduls 446 kein User Authority Mask Override Register (UAMOR) unterstützen, kann das Betriebssystem den aktuellen UAMOR-Wert auf den AMR-Wert anwenden, bevor das AMR im Hypervisor-Aufruf übergeben wird. Der Hypervisor 496 kann optional den aktuellen Authority-Mask-Override-Register-Wert (AMOR-Wert) anwenden, bevor er das AMR in das Prozesselement 483 platziert. Das 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 umfasst. Dieser Zeiger ist optional, wenn zwischen den Aufträgen oder beim Preempted eines Auftrags kein Zustand gespeichert werden muss. Der Kontextspeicher-/Wiederherstellungsbereich kann in den Systemspeicher gepinnt werden.
  • Beim Empfang des Systemaufrufs kann das Betriebssystem 495 überprüfen, ob die Anwendung 480 registriert ist 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 - Parameter für den Aufruf vom Betriebssystem an den Hypervisor
    1 Ein Arbeitsdeskriptor (WD)
    2 Ein Authority-Mask-Register-Wert (AMR-Wert) (potenziell maskiert).
    3 Ein Zeiger für Speichern/Wiederherstellen im Kontext (CSRP) mit effektiver Adresse (EA)
    4 Eine Prozess-ID (PID) und optional eine Thread-ID (TID)
    5 Ein Zeiger des Beschleunigungssatzes (AURP) mit virtueller Adresse (VA)
    6 Ein Speichersegmenttabellenzeiger (SSTP) mit virtueller Adresse
    7 Eine logische Interrupt-Service-Nummer (LISN)
  • Beim Empfang des Hypervisor-Aufrufs prüft der Hypervisor 496, ob das Betriebssystem 495 registriert ist und die Berechtigung zur Verwendung des Grafikbeschleunigungsmoduls 446 erhalten hat. Der Hypervisor 496 setzt dann das Prozesselement 483 in die Prozesselementeverknüpfungsliste für den entsprechenden Grafikbeschleunigungsmodultyp 446. Das Prozesselement kann die in Tabelle 4 dargestellten Informationen umfassen. Tabelle 4 - Informationen zum Prozesselement
    1 Ein Arbeitsdeskriptor (WD)
    2 Ein Authority-Mask-Register-Wert (AMR-Wert) (potenziell maskiert).
    3 Ein Zeiger für Speichern/Wiederherstellen im Kontext (CSRP) mit effektiver Adresse (EA)
    4 Eine Prozess-ID (PID) und optional eine Thread-ID (TID)
    5 Ein Zeiger des Beschleunigungssatzes (AURP) mit virtueller Adresse (VA)
    6 Ein Speichersegmenttabellenzeiger (SSTP) mit virtueller Adresse
    7 Eine logische Interrupt-Service-Nummer (LISN)
    8 Interrupt-Vektortabelle, abgeleitet aus den Hypervisor-Aufrufparametern.
    9 Ein Statusregisterwert (SR-Wert)
    10 Eine logische Partitions-ID (LPID)
    11 Ein Hypervisor-Beschleunigerauslastungs-Datensatzzeiger mit realer Adresse (RA)
    12 Das Speicher-Deskriptor-Register (SDR)
  • Der Hypervisor kann mehrere Registern 445 der Beschleuniger-Integrationsscheibe 490 initialisieren.
  • Wie in 4F illustriert ist, wird in einer optionalen Umsetzung ein einheitlicher Speicher verwendet, der über einen gemeinsamen virtuellen Speicheradressraum adressierbar ist, der für den Zugriff auf die physischen Prozessorspeicher 401 bis 402 und die GPU-Speicher 420 bis 423 verwendet wird. In dieser Umsetzung verwenden Operationen, die auf den GPUs 410 bis 413 ausgeführt werden, denselben virtuellen/effektiven Speicheradressraum, um auf die Prozessorspeicher 401 bis 402 zuzugreifen und umgekehrt, was die Programmierbarkeit vereinfacht. Ein erster Abschnitt des virtuellen/effektiven Adressraums kann dem Prozessorspeicher 401 zugewiesen werden, ein zweiter Abschnitt dem zweiten Prozessorspeicher 402, ein dritter Abschnitt dem GPU-Speicher 420 usw. Der gesamte virtuelle/effektive Speicherraum (manchmal auch als effektiver Adressraum bezeichnet) kann dadurch über jeden der Prozessorspeicher 401 bis 402 und GPU-Speicher 420 bis 423 verteilt werden, sodass jeder Prozessor oder jede GPU auf jeden physischen Speicher mit einer virtuellen Adresse zugreifen kann, die diesem Speicher zugeordnet ist.
  • Tendenz/Kohärenz-Managementschaltungsanordnungen 494A bis 494E in einer oder mehreren der MMUs 439A bis 439E können vorgesehen sein, die die Cache-Kohärenz zwischen den Caches der Host-Prozessoren (z. B. 405) und den GPUs 410 bis 413 sicherstellen und Tendenztechniken umsetzen, die die physischen Speicher angeben, in denen bestimmte Datentypen gespeichert werden sollten. Während mehrere Instanzen der Tendenz/Kohärenz-Managementschaltungsanordnung 494A bis 494E in 4F illustriert sind, kann die Bias/Kohärenz-Schaltung innerhalb der MMU eines oder mehrerer Host-Prozessoren 405 und/oder innerhalb der Beschleuniger-Integrationsschaltung 436 umgesetzt sein.
  • Der mit der GPU verbundene Speicher 420 bis 423 kann als Abschnitt des Systemspeichers abgebildet werden und der Zugriff erfolgt über die Shared-Virtual-Memory-Technologie (SVM-Technologie), ohne jedoch die typischen Leistungsnachteile zu erleiden, die mit vollständiger System-Cache-Kohärenz verbunden sind. Die Möglichkeit, auf den mit der GPU verbundenen Speicher 420 bis 423 als Systemspeicher ohne lästigen Cache-Kohärenz-Overhead zuzugreifen, bietet eine vorteilhafte Betriebsumgebung für GPU-Offload. Diese Anordnung ermöglicht es der Software des Host-Prozessors 405, Operanden einzurichten und auf Berechnungsergebnisse zuzugreifen, ohne den Overhead der traditionellen E/A-DMA-Datenkopien. Solche traditionellen Kopien beinhalten Treiberaufrufe, Interrupts und Memory-Mapped-E/A-Zugriffe (MMIO), die alle im Vergleich zu einfachen Speicherzugriffen ineffizient sind. Gleichzeitig kann die Fähigkeit, ohne Cache-Kohärenz-Overhead auf den an die GPU angeschlossenen Speicher 420 bis 423 zuzugreifen, entscheidend für die Ausführungszeit einer ausgelagerten Berechnung sein. In Fällen mit erheblichem Streaming-Schreibspeicherverkehr kann beispielsweise der Cache-Kohärenz-Overhead die effektive Schreibbandbreite, die eine GPU 410 bis 413 sieht, erheblich verringern. Die Effizienz des Operandenaufbaus, 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-Tendenz und Host-Prozessor-Tendenz kann durch eine Tendenztracker-Datenstruktur gesteuert werden. Es kann z. B. eine Tendenztabelle verwendet werden, die eine seitengranulare Struktur sein kann (d. h., die auf der Granularität einer Speicherseite gesteuert wird), die 1 oder 2 Bits pro GPUangeschlossene Speicherseite umfasst. Die Tendenztabelle kann in einem gestohlenen Speicherbereich eines oder mehrerer GPU-angeschlossener Speicher 420 bis 423 umgesetzt sein, mit oder ohne Tendenz-Cache in der GPU 410 bis 413 (z. B. um häufig/kurzzeitig verwendete Einträge der Tendenztabelle zu cachen). Alternativ kann auch die gesamte Tendenztabelle innerhalb der GPU gepflegt werden.
  • In einer Umsetzung wird auf den Tendenztabelleneintrag, der mit jedem Zugriff auf den GPU-angeschlossenen Speicher 420 bis 423 verbunden ist, vor dem eigentlichen Zugriff auf den GPU-Speicher zugegriffen, was die folgenden Operationen auslöst. Zunächst werden lokale Anfragen von der GPU 410 bis 413, die ihre Seite in GPU-Tendenz finden, direkt an einen entsprechenden GPU-Speicher 420 bis 423 weitergeleitet. Lokale Anfragen von der GPU, die ihre Seite in Host-Tendenz finden, werden an den Prozessor 405 weitergeleitet (z. B. über eine Hochgeschwindigkeitsverbindung wie oben beschrieben). Optional schließen Anfragen des Prozessors 405, die die angeforderte Seite in Host-Prozessor-Tendenz finden, die Anfrage wie ein normales Speicherlesen ab. Alternativ können Anfragen, die an eine GPU-Tendenz Seite gerichtet sind, an die GPU 410 bis 413 weitergeleitet werden. Der Grafikprozessor kann dann die Seite an einen Host-Prozessor-Tendenz übergeben, wenn er die Seite gerade nicht verwendet.
  • Der Tendenz-Zustand einer Seite kann entweder durch einen softwarebasierten Mechanismus, einen hardwareunterstützten softwarebasierten Mechanismus oder, für eine begrenzte Anzahl von Fällen, einen rein hardwarebasierten Mechanismus geändert werden.
  • Ein Mechanismus zum Ändern des Tendenz-Zustands verwendet einen API-Aufruf (z. B. OpenCL), der wiederum den Gerätetreiber der GPU aufruft, der wiederum eine Nachricht an die GPU sendet (oder einen Befehlsdeskriptor in die Warteschlange stellt) und sie anweist, den Tendenz-Zustand zu ändern und bei einigen Übergängen einen Cache-Flushing-Vorgang im Host auszuführen. Der Cache-Flushing-Vorgang ist für einen Übergang der Tendenz des Host-Prozessors 405 der Tendenz der GPU erforderlich, aber nicht für den umgekehrten Übergang.
  • Die Cache-Kohärenz kann aufrechterhalten werden, indem GPU-basierte Seiten vom Host-Prozessor 405 vorübergehend nicht gecacht werden können. Um auf diese Seiten zuzugreifen, kann der Prozessor 405 Zugriff von der GPU 410 anfordern, die je nach Umsetzung den Zugriff sofort gewähren kann oder nicht. Um die Kommunikation zwischen dem Host-Prozessor 405 und der GPU 410 zu verringern, ist es daher vorteilhaft, dafür zu sorgen, dass es sich bei den GPU-basierten Seiten um solche handelt, die von der GPU, aber nicht vom Host-Prozessor 405 benötigt werden und umgekehrt.
  • Grafikverarbeitungs- Pipeline
  • 5 illustriert eine Grafikverarbeitungspipeline 500. Ein Grafikmultiprozessor, wie z. B. der Grafikmultiprozessor 234 aus 2D, der Grafikmultiprozessor 325 aus 3A, der Grafikmultiprozessor 350 aus 3B kann die illustrierte Grafikverarbeitungspipeline 500 umsetzen. Der Grafikmultiprozessor kann in den hierin beschriebenen Parallelverarbeitungs-Subsystemen umfasst sein, wie z. B. im Parallelprozessor 200 aus 2A, der mit dem/den Parallelprozessor(en) 112 aus 1 zusammenhängen und statt einem von diesen verwendet werden kann. Die verschiedenen Parallelverarbeitungssysteme können die Grafikverarbeitungspipeline 500 über eine oder mehrere Instanzen der Parallelverarbeitungseinheit (z. B. die Parallelverarbeitungseinheit 202 aus 2A) wie hierin beschrieben umsetzen. Beispielsweise kann eine Shader-Einheit (z. B. der Grafikmultiprozessor 234 aus 2C) so konfiguriert sein, dass sie die Funktionen einer oder mehrerer Vertex-Verarbeitungseinheiten 504, einer Tessellierungssteuerungs-Verarbeitungseinheit 508, einer Tessellierungsauswertungs-Verarbeitungseinheit 512, einer Geometrieverarbeitungseinheit 516 und einer Fragment/Pixel-Verarbeitungseinheit 524 ausführt. Die Funktionen von Data Assembler 502, Primitiv-Assembler 506, 514, 518, Tessellierungseinheit 510, Rasterisierer 522 und Rasterbetriebseinheit 526 können auch von anderen Verarbeitungsengines innerhalb eines Verarbeitungsclusters (z. B. Verarbeitungscluster 214 aus 2A) und einer entsprechenden Partitionseinheit (z. B. Partitionseinheit 220A bis 220N aus 2A) ausgeführt werden. Die Grafikverarbeitungspipeline 500 kann auch mit dedizierten Verarbeitungseinheiten für eine oder mehrere Funktionen umgesetzt werden. Es ist auch möglich, dass ein oder mehrere Abschnitte der Grafikverarbeitungspipeline 500 von einer parallelen Verarbeitungslogik innerhalb eines Allzweckprozessors (z. B. CPU) ausgeführt werden. Optional können ein oder mehrere Abschnitte der Grafikverarbeitungspipeline 500 auf den On-Chip-Speicher zugreifen (z. B. auf den Parallelprozessorspeicher 222 wie in 2A) über eine Speicherschnittstelle 528, die eine Instanz der Speicherschnittstelle 218 aus 2A sein kann. Die Grafikprozessor-Pipeline 500 kann auch über eine Multi-Core-Gruppe 365A wie in 3C umgesetzt sein.
  • Der Datenassembler 502 ist eine Verarbeitungseinheit, die Vertexdaten für Flächen und Primitive erfassen kann. Der Datenassembler 502 gibt dann die Vertexdaten, unter anderem die Vertexattribute, an die Vertexverarbeitungseinheit 504 aus. Die Vertexverarbeitungseinheit 504 ist eine programmierbare Ausführungseinheit, die Vertex-Shader-Programme ausführt und Vertexdaten entsprechend den Vorgaben der Vertex-Shader-Programme beleuchtet und umwandelt. Die Vertexverarbeitungseinheit 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 Weltraumkoordinatenraum oder einen normalisierten Vorrichtungskoordinatenraum umwandelt.
  • Eine erste Instanz eines Primitiv-Assemblers 506 empfängt Vertexattribute von der Vertexverarbeitungseinheit 504. Der Primitiv-Assembler 506 liest gespeicherte Vertexattribute nach Bedarf aus und konstruiert Grafikprimitive für die Verarbeitung durch die Tessellierungssteuerungs-Verarbeitungseinheit 508. Zu den Grafikprimitiven gehören Dreiecke, Liniensegmente, Punkte, Patches usw., die von verschiedenen Programmierschnittstellen (APIs) für die Grafikverarbeitung unterstützt werden.
  • Die Tessellierungssteuerungs-Verarbeitungseinheit 508 behandelt die Eingangsvertizes als Kontrollpunkte für einen geometrischen Patch. Die Kontrollpunkte werden von einer Eingabedarstellung aus dem Patch (z. B. die Basen des Patches) in eine Darstellung transformiert, die für die Verwendung in der Flächenauswertung durch die Tessellierungsauswertungs-Verarbeitungseinheit 512 geeignet ist. Die Tessellierungssteuerungs-Verarbeitungseinheit 508 kann auch Tessellierungsfaktoren für Kanten von geometrischen Patches berechnen. Ein Tessellierungsfaktor gilt für eine einzelne Kante und quantifiziert einen ansichtsabhängigen Detailgrad, der mit der Kante verbunden ist. Eine Tessellierungseinheit 510 ist so konfiguriert, dass sie die Tessellierungsfaktoren für die Kanten eines Patches empfängt und den Patch in mehrere geometrische Primitive wie Linien-, Dreieck- oder Viereckprimitive tesselliert, die an eine Tessellierungsauswertungs-Verarbeitungseinheit 512 übertragen werden. Die Tessellierungsauswertungsverarbeitungseinheit 512 arbeitet mit parametrisierten Koordinaten des unterteilten Patch, um eine Flächendarstellung und Vertexattribute für jeden Vertex zu erzeugen, der mit den geometrischen Primitiven verbunden ist.
  • Eine zweite Instanz eines Primitiv-Assemblers 514 empfängt Vertexattribute von der Tessellierungsauswertungs-Verarbeitungseinheit 512, liest bei Bedarf gespeicherte Vertexattribute ein und konstruiert Grafik-Primitive zur Verarbeitung durch die Geometrieverarbeitungseinheit 516. Die Geometrieverarbeitungseinheit 516 ist eine programmierbare Ausführungseinheit, die Geometrieshader-Programme ausführt, um vom Primitiv-Assembler 514 empfangene Grafikprimitive nach den Vorgaben der Geometrieshader-Programme zu transformieren. Die Geometrieverarbeitungseinheit 516 kann so programmiert sein, dass sie die Grafikprimitive in ein oder mehrere neue Grafikprimitive unterteilt und Parameter berechnet, die zur Rasterisierung 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 Vertizes, die neue Grafikprimitive spezifizieren, an den Primitiv-Assembler 518 aus. Der Primitiv-Assembler 518 empfängt die Parameter und Vertizes von der Geometrieverarbeitungseinheit 516 und konstruiert Grafikprimitive zur Verarbeitung durch eine Ansichtsfenster-Skalierungs-, Culling- und Clipping-Einheit 520. Die Geometrieverarbeitungseinheit 516 liest Daten, die im Parallelprozessorspeicher oder im Systemspeicher gespeichert sind, um sie für die Verarbeitung der Geometriedaten zu verwenden. Die Viewport-Skalierungs-, Culling- und Clipping-Einheit 520 führt Clipping, Culling und Viewport-Skalierung durch und gibt verarbeitete Grafikprimitive an einen Rasterisierer 522 aus.
  • Der Rasterisierer 522 kann Tiefen-Culling und andere tiefenbasierte Optimierungen ausführen. Der Rasterisierer 522 führt auch eine Scan-Konvertierung an den neuen Grafik-Primitiven durch, um Fragmente zu erzeugen und diese Fragmente und die zugehörigen Abdeckungsdaten an die Fragment/Pixel-Verarbeitungseinheit 524 auszugeben. Die Fragment-/Pixelverarbeitungseinheit 524 ist eine programmierbare Ausführungseinheit, die für die Ausführung von Fragment-Shader-Programmen oder Pixel-Shader-Programmen konfiguriert ist. Die Fragment-/Pixelverarbeitungseinheit 524 transformiert vom Rasterisierer 522 empfangene Fragmente oder Pixel, wie von den Fragment- oder Pixel-Shader-Programmen vorgegeben. Beispielsweise kann die Fragment-/Pixelverarbeitungseinheit 524 so programmiert sein, dass sie Operationen wie Texturabbildung, Schattierung, Überblendung, Texturkorrektur und perspektivische Korrektur ausführt, um schattierte Fragmente oder Pixel zu erzeugen, die an eine Rasterbetriebseinheit 526 ausgegeben werden. Die Fragment-/Pixelverarbeitungseinheit 524 kann Daten lesen, die entweder im Parallelprozessorspeicher oder im Systemspeicher gespeichert sind, um sie bei der Verarbeitung der Fragmentdaten zu verwenden. Fragment- oder Pixel-Shader-Programme können so konfiguriert sein, dass sie auf Sample-, Pixel-, Kachel- oder anderen Granularitäten schattieren, abhängig von der für die Verarbeitungseinheiten konfigurierten Abtastrate.
  • Die Rasterbetriebseinheit 526 ist eine Verarbeitungseinheit, die Rasteroperationen ausführt, unter anderem, aber nicht beschränkt auf Schablone, Z-Test, Überblendung und dergleichen, und Pixeldaten als verarbeitete Grafikdaten ausgibt, die im Grafikspeicher (z. B. im Parallelprozessorspeicher 222 wie in 2A, und/oder Systemspeicher 104 wie in 1) gespeichert auf der/den einen oder mehreren Anzeigevorrichtung(en) 110 angezeigt oder durch einen der einen oder mehreren Prozessor(en) 102 oder Parallelprozessor(en) 112 weiter verarbeitet werden. Die Rasterbetriebseinheit 526 kann so konfiguriert sein, dass sie z- oder Farbdaten, die in den Speicher geschrieben werden, komprimiert und z- oder Farbdaten, die aus dem Speicher gelesen werden, dekomprimiert.
  • Überblick über Maschinenlernen
  • Die oben beschriebene Architektur kann verwendet werden, um Trainings- und Inferenzoperationen mit Modellen für Maschinenlernen auszuführen. Maschinenlernen hat sich bei der Lösung vieler Arten von Aufgaben bewährt. Die Berechnungen, die beim Training und der Verwendung von Algorithmen zum Maschinenlernen (z. B. neuronale Netze) anfallen, eignen sich natürlich für effiziente parallele Umsetzungen. Dementsprechend spielen Parallelprozessoren wie Allzweck-Grafikprozessoreinheiten (GPGPUs) eine wichtige Rolle bei der praktischen Umsetzung von tiefen neuronalen Netzen gespielt. Parallele Grafikprozessoren mit Single-Instruction-Multi-Thread-Architekturen (SIMT-Architekturen) sind dafür ausgelegt, die Menge der parallelen Verarbeitung in der Grafikpipeline zu maximieren. In einer SIMT-Architektur versuchen Gruppen von parallelen Threads, Programmanweisungen so oft wie möglich gemeinsam synchron auszuführen, um die Verarbeitungseffizienz zu erhöhen. Die Effizienz, die durch parallele Umsetzungen von Algorithmen des Maschinenlernens erreicht wird, ermöglicht den Einsatz von Netzwerken mit hoher Kapazität und erlaubt es, diese Netzwerke auf größeren Datensätzen zu schulen.
  • Ein Algorithmus für Maschinenlernen ist ein Algorithmus, der auf der Grundlage eines Datensatzes lernen kann. Beispielsweise können Algorithmen für Maschinenlernen so entworfen werden, dass sie High-Level-Abstraktionen innerhalb eines Datensatzes modellieren. Beispielsweise können Bilderkennungsalgorithmen verwendet werden, um zu bestimmen, zu welcher von mehreren Kategorien eine gegebene Eingabe gehört; Regressionsalgorithmen können einen numerischen Wert angesichts einer Eingabe ausgeben; und Mustererkennungsalgorithmen können verwendet werden, um übersetzten Text zu generieren oder Text-zu-Sprache und/oder Spracherkennung auszuführen.
  • Ein beispielhafter Typ eines Maschinenlernalgorithmus ist ein neuronales Netz. Es gibt viele Arten von neuronalen Netzen; ein einfacher Typ von neuronalen Netzen ist ein Feedforward-Netz. Ein Feedforward-Netzwerk kann als azyklische Kurve umgesetzt werden, in dem die Knoten in Schichten angeordnet sind. Typischerweise umfasst eine Feedforward-Netzwerktopologie eine Eingabeschicht und eine Ausgabeschicht, die durch mindestens eine versteckte Schicht getrennt sind. Die versteckte Schicht transformiert die von der Eingabeschicht empfangene Eingabe in eine Darstellung, die für die Erzeugung der Ausgabe in der Ausgabeschicht nützlich ist. Die Netzknoten sind vollständig über Kanten mit den Knoten in benachbarten Schichten verbunden, aber es gibt keine Kanten zwischen Knoten innerhalb jeder Schicht. Daten, die an den Knoten einer Eingabeschicht eines Feedforward-Netzwerks empfangen werden, werden über eine Aktivierungsfunktion, die die Zustände der Knoten jeder aufeinanderfolgenden Schicht im Netzwerk auf der Grundlage von Koeffizienten („Gewichtungen“) berechnet, die jeweils mit jeder der Kanten verbunden sind, die die Schichten verbinden, an die Knoten der Ausgabeschicht propagiert (d. h. „vorwärtsgeleitet“). Je nach dem spezifischen Modell, das durch den ausgeführten Algorithmus illustriert wird, kann die Ausgabe des neuronalen Netzwerkalgorithmus verschiedene Formen annehmen.
  • Bevor ein Algorithmus für Maschinenlernen zur Modellierung eines bestimmten Problems verwendet werden kann, wird der Algorithmus anhand eines Trainingsdatensatzes trainiert. Das Training eines neuronalen Netzwerks umfasst das Auswählen einer Netzwerktopologie, die Verwendung eines Satzes von Trainingsdaten, die ein Problem darstellen, das durch das Netzwerk modelliert wird, und das Anpassen der Gewichtungen, bis das Netzwerkmodell mit einem minimalen Fehler für alle Instanzen des Trainingsdatensatzes arbeitet. Beispielsweise wird während eines Trainingsablaufes mit überwachtem Lernen für ein neuronales Netzwerk die Ausgabe, die durch das Netzwerk als Reaktion auf die Eingabe, die eine Instanz in einem Trainingsdatensatz darstellt, erzeugt wird, mit der „korrekten“ beschrifteten Ausgabe für diese Instanz verglichen, ein Fehlersignal, das die Differenz zwischen der Ausgabe und der beschrifteten Ausgabe darstellt, wird berechnet, und die mit den Verbindungen verbundenen Gewichtungen werden angepasst, um diesen Fehler zu minimieren, während das Fehlersignal rückwärts durch die Schichten des Netzwerks propagiert wird. Das Netz gilt als „trainiert“, wenn die Fehler für jede der aus den Instanzen des Trainingsdatensatzes erzeugten Ausgaben minimiert sind.
  • Die Genauigkeit eines Algorithmus für Maschinenlernen kann erheblich von der Qualität des zum Trainieren des Algorithmus verwendeten Datensatzes beeinflusst werden. Der Trainingsablauf kann rechenintensiv sein und auf einem herkömmlichen Allzweckprozessor eine erhebliche Zeitspanne in Anspruch nehmen. Dementsprechend wird Parallelverarbeitungs-Hardware zum Trainieren vieler Arten von Maschinenlernalgorithmen verwendet. Dies ist besonders nützlich für die Optimierung des Trainings von neuronalen Netzen, da sich die Berechnungen, die bei der Anpassung der Koeffizienten in neuronalen Netzen ausgeführt werden, natürlich für parallele Umsetzungen eignen. Insbesondere wurden viele Algorithmen und Softwareanwendungen für Maschinenlernen so angepasst, dass sie die Parallelverarbeitungshardware in Allzweck-Grafikverarbeitungsvorrichtungen nutzen können.
  • 6 ist ein verallgemeinertes Diagramm eines Softwarestapels zum Maschinenlernen 600. Eine Anwendung zum Maschinenlernen 602 ist eine beliebige Logik, die so konfiguriert sein kann, dass sie ein neuronales Netzwerk anhand eines Trainingsdatensatzes trainiert oder ein trainiertes tiefes neuronales Netzwerk verwendet, um Maschinenintelligenz zu umsetzen. Die Anwendung zum Maschinenlernen 602 kann Trainings- und Inferenzfunktionalität für ein neuronales Netzwerk und/oder spezialisierte Software umfassen, die zum Trainieren eines neuronalen Netzwerks vor dem Einsatz verwendet werden kann. Die Maschinenlernanwendung 602 kann jede Art von Maschinenintelligenz umsetzen, unter anderem aber nicht beschränkt auf Bilderkennung, Abbildung und Lokalisierung, autonome Navigation, Sprachsynthese, medizinische Bildgebung oder Sprachübersetzung. Beispiele für Maschinenlernanwendungen 602 sind unter anderem sprachbasierte virtuelle Assistenten, Bild- oder Gesichtserkennungsalgorithmen, autonome Navigation und die Softwaretools, die zum Trainieren der von den Maschinenlernanwendungen 602 verwendeten Maschinenlernmodelle verwendet werden.
  • Die Hardwarebeschleunigung für die Maschinenlernanwendung 602 kann über ein Maschinenlern-Framework 604 aktiviert werden. Das Maschinenlern-Framework 604 kann eine Bibliothek mit Primitiven für Maschinenlernen bereitstellen. Primitive für Maschinenlernen sind grundlegende Operationen, die häufig von Algorithmen für Maschinenlernen ausgeführt werden. Ohne das Maschinenlern-Framework 604 müssten Entwickler von Algorithmen für Maschinenlernen die mit dem Algorithmus für Maschinenlernen verbundene Hauptrechenlogik erstellen und optimieren und dann die Rechenlogik erneut optimieren, wenn neue Parallelprozessoren entwickelt werden. Stattdessen kann die Anwendung für Maschinenlernen so konfiguriert sein, dass sie die erforderlichen Berechnungen mit den vom Maschinenlern-Framework 604 bereitgestellten Primitiven ausführt. Zu den beispielhaften Primitiven gehören Tensorfaltungen, Aktivierungsfunktionen und Pooling, d. h. Rechenoperationen, die beim Training eines konvolutionalen neuronalen Netzwerks (CNN) ausgeführt werden. Das Maschinenlern-Framework 604 kann auch Primitive bereitstellen, um grundlegende lineare Algebra-Unterprogramme zu umsetzen, die von vielen Algorithmen für Maschinenlernen ausgeführt werden, wie z. B. Matrix- und Vektoroperationen. Beispiele für ein Maschinenlern-Framework 604 sind unter anderem TensorFlow, TensorRT, PyTorch, MXNet, Caffee und andere High-Level-Frameworks für Maschinenlernen.
  • Das Maschinenlern-Framework 604 kann von der Anwendung für Maschinenlernen 602 empfangene Eingabedaten verarbeiten und die entsprechende Eingabe für ein Rechner-Framework 606 erzeugen. Das Rechner-Framework 606 kann die zugrundeliegenden Anweisungen abstrahieren, die dem GPGPU-Treiber 608 zur Verfügung gestellt werden, um es dem Maschinenlern-Framework 604 zu ermöglichen, die Vorteile der Hardwarebeschleunigung über die GPGPU-Hardware 610 zu nutzen, ohne dass das Maschinenlern-Framework 604 intime Kenntnisse über die Architektur der GPGPU-Hardware 610 haben muss. Zusätzlich kann das Rechner-Framework 606 die Hardwarebeschleunigung für das Maschinenlern-Framework 604 über mehrere Typen und Generationen der GPGPU-Hardware 610 ermöglichen. Beispielhafte Rechner-Frameworks 606 umfassen das CUDA-Rechner-Framework und zugehörige Bibliotheken für Maschinenlernen, wie die CUDA-Deep-Neural-Network-Bibliothek (cuDNN-Bibliothek). Der Softwarestapel 600 für Maschinenlernen kann auch Kommunikationsbibliotheken oder Frameworks umfassen, um Multi-GPU- und Multi-Knoten-Berechnungen zu ermöglichen.
  • GPGPU-Beschleunigung für Maschinenlernen
  • 7 illustriert eine Allzweck-Grafikprozessoreinheit 700, bei der es sich um den Parallelprozessor 200 aus 2A oder der/die Parallelprozessor(en) 112 aus 1 handeln kann. Die Allzweck-Prozessoreinheit (GPGPU) 700 kann so konfiguriert sein, dass sie Unterstützung für die Hardwarebeschleunigung von Primitiven bietet, die von einem Maschinenlern-Framework bereitgestellt werden, um die Verarbeitung der Art von Rechenlasten zu beschleunigen, die mit dem Training tiefer neuronaler Netze verbunden sind. Weiterhin kann die GPGPU 700 direkt mit anderen Instanzen der GPGPU verknüpft werden, um einen Multi-GPU-Cluster zu erschaffen, um die Schulungsgeschwindigkeit für besonders tiefe neutrale Netze zu verbessern. Es werden auch Primitive unterstützt, um Inferenzoperationen für eingesetzte neuronale Netze zu beschleunigen.
  • Die GPGPU 700 umfasst eine Host-Schnittstelle 702, um eine Verbindung mit einem Host-Prozessor zu ermöglichen. Die Host-Schnittstelle 702 kann eine PCI-Express-Schnittstelle sein. Die Host-Schnittstelle kann jedoch auch eine händlerspezifische Kommunikationsschnittstelle oder ein Kommunikationsgewebe sein. Die GPGPU 700 empfängt Befehle vom Host-Prozessor und verwendet einen globalen Scheduler 704, um die mit diesen Befehlen verknüpften Ausführungsthreads auf eine Reihe von Verarbeitungsclustern 706A bis 706H zu verteilen. Die Verarbeitungscluster 706A bis 706H teilen sich einen Cache-Speicher 708. Der Cache-Speicher 708 kann als übergeordneter Cache für Cache-Speicher innerhalb der Verarbeitungscluster 706A bis 706H dienen. Die illustrierten Verarbeitungscluster 706A bis 706H können mit den Verarbeitungsclustern 214A bis 214N wie in 2A entsprechen.
  • Die GPGPU 700 umfasst Speicher 714A bis 714B, die über eine Reihe von Speichercontrollern 712A bis 712B mit den Verarbeitungsclustern 706A bis 706H verbunden sind. Die Speichereinheiten 714A bis 714B können verschiedene Arten von Speichervorrichtungen umfassen, unter anderem dynamischer Direktzugriffsspeicher (DRAM) oder Grafik-Direktzugriffsspeicher, wie synchroner Grafik-Direktzugriffsspeicher (SGRAM), unter anderem Grafik-Doppeldatenraten-Speicher (GDDR-Speicher). Der Speicher 714A bis 714B kann auch 3D-Stapelspeicher umfassen, unter anderem, aber nicht beschränkt auf High Bandwidth Memory (HBM-Speicher).
  • Jeder der Verarbeitungscluster 706A bis 706H kann einen Satz von Grafikmultiprozessoren umfassen, z. B. den Grafikmultiprozessor 234 aus 2D, Grafikmultiprozessor 325 aus 3A, Grafikmultiprozessor 350 aus 3B, oder kann eine Multi-Core-Gruppe 365A bis 365N wie in 3C umfassen. Die Grafikmultiprozessoren des Rechner-Clusters umfassen mehrere Typen von Ganzzahl- und Fließkomma-Logikeinheiten, die Rechenoperationen mit einer Reihe von Genauigkeiten ausführen können, die sich auch für Maschinenlernberechnungen eignen. Beispielsweise kann zumindest eine Teilmenge der Gleitkommaeinheiten in jedem der Verarbeitungscluster 706A bis 706H so konfiguriert sein, dass sie 16-Bit- oder 32-Bit-Gleitkommaoperationen ausführen, während eine andere Teilmenge der Gleitkommaeinheiten so konfiguriert sein kann, dass sie 64-Bit-Gleitkommaoperationen ausführen.
  • Mehrere Instanzen der GPGPU 700 können konfiguriert sein, als ein Rechencluster zu wirken. Der Kommunikationsmechanismus, der durch den Rechencluster für Synchronisierung und Datenaustausch verwendet wird, variiert in verschiedenen Ausführungsformen. Beispielsweise kommunizieren die mehreren Instanzen der GPGPU 700 über die Host-Schnittstelle 702. In einer Ausführungsform umfasst die GPGPU 700 einen E/A-Hub 709, der die GPGPU 700 mit einer GPU-Verbindung 710 koppelt, die eine direkte Verbindung mit anderen Instanzen der GPGPU ermöglicht. Die GPU-Verbindung 710 kann mit einer dedizierten GPU-zu-GPU-Brücke gekoppelt sein, die die Kommunikation und Synchronisation zwischen mehreren Instanzen der GPGPU 700 ermöglicht. Optional kann die GPU-Verbindung 710 mit einem Hochgeschwindigkeits-Interconnect gekoppelt sein, um Daten an andere GPGPUs oder Parallelprozessoren zu senden und zu empfangen. Die mehreren Instanzen der GPGPU 700 können sich in separaten Datenverarbeitungssystemen befinden und über eine Netzwerkvorrichtung kommunizieren, das über die Host-Schnittstelle 702 zugänglich ist. Die GPU-Verbindung 710 kann so konfiguriert sein, dass er zusätzlich oder alternativ dazu zur Host-Schnittstelle 702 eine Verbindung zu einem Host-Prozessor ermöglicht.
  • Während die illustrierte Konfiguration der GPGPU 700 für das Training von neuronalen Netzen konfiguriert sein kann, kann eine alternative Konfiguration der GPGPU 700 für den Einsatz innerhalb einer Hochleistungs- oder Niederleistungs-Inferencing-Plattform konfiguriert sein. In einer Inferencing-Konfiguration umfasst die GPGPU 700 im Vergleich zur Trainingskonfiguration weniger der Verarbeitungscluster 706A bis 706H. Zusätzlich kann sich die Speichertechnologie, die mit dem Speicher 714A bis 714B verbunden ist, zwischen Inferenz- und Trainingskonfigurationen unterscheiden. In einer Ausführungsform kann die Inferencing-Konfiguration der GPGPU 700 Inferencing-spezifische Anweisungen unterstützen. Beispielsweise kann eine Schlussfolgerungskonfiguration eine Unterstützung für eine oder mehr 8-Bit-Integer-Punktproduktanweisungen bereitstellen, die üblicherweise bei Schlussfolgerungsoperationen für eingesetzte neurale Netze verwendet werden.
  • 8 illustriert ein Multi-GPU-Rechnersystem 800. Das Multi-GPU-Rechnersystem 800 kann einen Prozessor 802 umfassen, der über einen Host-Schnittstellenschalter 804 mit mehreren GPGPUs 806A bis 806D verbunden ist. Der Host-Schnittstellen-Switch 804 kann eine PCI-Express-Switch-Vorrichtung sein, die den Prozessor 802 an einen PCI-Express-Bus koppelt, über den der Prozessor 802 mit dem Satz von GPGPUs 806A bis 806D kommunizieren kann. Jede der mehreren GPGPUs 806A bis 806D kann eine Instanz der GPGPU 700 aus 7 sein. Die GPGPUs 806A bis 806D können über eine Reihe von Hochgeschwindigkeits-Punkt-zu-Punkt-GPU-zu-GPU-Verbindungen 816 miteinander verbunden werden. Die Hochgeschwindigkeits-GPU-zu-GPU-Verbindungen können mit jeder der GPGPUs 806A bis 806D über eine dedizierte GPU-Verbindung verbunden werden, wie etwa die GPU-Verbindung 710 aus 7. Die P2P-GPU-Verbindungen 816 ermöglichen eine direkte Kommunikation zwischen den einzelnen GPGPUs 806A bis 806D, ohne dass eine Kommunikation über den Host-Schnittstellenbus erforderlich ist, mit dem der Prozessor 802 verbunden ist. Wenn der GPU-zu-GPU-Verkehr auf die P2P-GPU-Verbindungen geleitet wird, bleibt der Host-Schnittstellenbus für den Systemspeicherzugriff oder für die Kommunikation mit anderen Instanzen des Multi-GPU-Rechnersystems 800 verfügbar, beispielsweise über ein oder mehrere Netzwerkvorrichtungen. Während in 8 die GPGPUs 806A bis 806D über den Host-Schnittstellenschalter 804 mit dem Prozessor 802 verbunden sind, kann der Prozessor 802 alternativ eine direkte Unterstützung für die P2P-GPU-Verbindungen 816 umfassen und direkt mit den GPGPUs 806A bis 806D verbunden sein. In einer Ausführungsform ermöglicht die P2P-GPU-Verbindung 816, dass das Multi-GPU-Rechnersystem 800 als eine einzige logische GPU arbeitet.
  • Umsetzungen eines neuronalen Netzwerks zum Maschinenlernen
  • Die hier beschriebene Rechnerarchitektur kann so konfiguriert sein, dass sie die Arten der parallelen Verarbeitung ausführt, die sich besonders für das Training und den Einsatz von neuronalen Netzen für Maschinenlernen eignen. Ein neuronales Netzwerk kann als ein Netzwerk von Funktionen verallgemeinert werden, die in einer Kurvenbeziehung stehen. Wie in der Fachwelt bekannt ist, gibt es mehrere Typen von neuronalen Netzwerkumsetzungen, die beim Maschinenlernen verwendet werden. Ein beispielhafter Typ eines neuronalen Netzes ist das Feedforward-Netz, wie zuvor beschrieben.
  • Ein zweiter beispielhafter Typ eines neuronalen Netzes ist das konvolutionale neuronale Netz (CNN). Ein CNN ist ein spezialisiertes neuronales Feedforward-Netzwerk zur Verarbeitung von Daten mit einer bekannten, gitterartigen Topologie, wie z. B. Bilddaten. Dementsprechend werden CNNs üblicherweise für die Berechnung von Bildverarbeitungs- und Bilderkennungsanwendungen eingesetzt, sie können aber auch für andere Arten der Mustererkennung wie z. B. Sprach- 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 Satzes von Filtern wird an Knoten in aufeinanderfolgenden Schichten des Netzwerks propagiert. Die Berechnungen für ein CNN beinhalten die Anwendung der mathematischen Konvolutionsoperation auf jeden Filter, um die Ausgabe des jeweiligen Filters zu erzeugen. Die Konvolution ist eine spezielle Art von mathematischer Operation, bei der zwei Funktionen eine dritte Funktion erzeugen, die eine modifizierte Version einer der beiden ursprünglichen Funktionen ist. In der Terminologie von konvolutionalen Netzen kann die erste Funktion der Konvolution als Eingang bezeichnet werden, während die zweite Funktion als Konvolutions-Kernel bezeichnet wird. Die Ausgabe kann als Kennfeld bezeichnet werden. Die Eingabe für eine Konvolutionsschicht kann z. B. ein mehrdimensionales Array von Daten sein, das die verschiedenen Farbkomponenten eines Eingangsbildes definiert. Der Konvolutions-Kernel kann ein mehrdimensionales Array von Parametern sein, wobei die Parameter durch den Trainingsablauf für das neuronale Netz angepasst werden.
  • Rekurrente neuronale Netze (RNNs) sind eine Familie von neuronalen Feedforward-Netzen, die Rückkopplungsverbindungen zwischen den Schichten umfassen. RNNs ermöglichen die Modellierung sequenzieller Daten, indem sie Parameterdaten auf verschiedene Abschnitte des neuronalen Netzwerks verteilen. Die Architektur für ein RNN umfasst Zyklen. Die Zyklen stellen den Einfluss eines gegenwärtigen Wertes einer Variablen auf ihren eigenen Wert zu einem zukünftigen Zeitpunkt dar, da zumindest ein Abschnitt der Ausgangsdaten des RNN als Rückkopplung für die Verarbeitung nachfolgender Eingaben in einer Sequenz verwendet wird. Diese Eigenschaft macht RNNs besonders nützlich für die Sprachverarbeitung, da Sprachdaten sehr variabel zusammengesetzt sein können.
  • Die folgenden Abbildungen zeigen beispielhafte Feedforward-, CNN- und RNN-Netzwerke und beschreiben einen allgemeinen Prozess für das jeweilige Training und den Einsatz jedes dieser Netzwerktypen. Es versteht sich, dass diese Beschreibungen beispielhaft und nicht einschränkend für jede hier beschriebene spezifische Ausführungsform sind und die illustrierten Konzepte allgemein auf tiefe neuronale Netzwerke und Maschinenlerntechniken im Allgemeinen angewendet werden können.
  • Die oben beschriebenen beispielhaften neuronalen Netze können verwendet werden, um Deep Learning auszuführen. Deep Learning ist Maschinenlernen mit tiefen neuronalen Netzwerken. Die beim Deep Learning verwendeten tiefen neuronalen Netze sind künstliche neuronale Netze, die aus mehreren versteckten Schichten bestehen, im Gegensatz zu flachen neuronalen Netzen, die nur eine einzige versteckte Schicht umfassen. Tiefere neuronale Netze sind im Allgemeinen rechenintensiver zu trainieren. Die zusätzlichen versteckten Schichten des Netzes ermöglichen jedoch eine mehrstufige Mustererkennung, die im Vergleich zu flachen Maschinenlernverfahren zu einem geringeren Ausgabefehler führt.
  • Tiefe neuronale Netze, die beim Deep Learning verwendet werden, umfassen typischerweise ein Frontend-Netz zur Ausführung der Merkmalserkennung, das mit einem Backend-Netz gekoppelt ist, das ein mathematisches Modell darstellt, das Operationen (z. B. Objektklassifizierung, Spracherkennung usw.) basierend auf der dem Modell bereitgestellten Merkmalsdarstellung ausführen kann. Deep Learning ermöglicht Maschinenlernen, ohne dass für das Modell ein handwerkliches Feature Engineering ausgeführt werden muss. Stattdessen können tiefe neuronale Netze Features basierend auf statistischen Strukturen oder Korrelationen innerhalb der Eingabedaten lernen. Die gelernten Merkmale können einem mathematischen Modell zur Verfügung gestellt werden, das die erkannten Merkmale auf einen Ausgang abbilden kann. Das mathematische Modell, das vom Netzwerk verwendet wird, ist in der Regel auf die jeweilige Aufgabe spezialisiert, und es werden unterschiedliche Modelle für unterschiedliche Aufgaben verwendet.
  • Sobald das neuronale Netz strukturiert ist, kann ein Lernmodell auf das Netz angewendet werden, um das Netz für die Ausführung bestimmter Aufgaben zu trainieren. Das Lernmodell beschreibt, wie die Gewichtungen innerhalb des Modells angepasst werden, um den Ausgangsfehler des Netzwerks zu verringern. Rückpropagation von Fehlern ist ein gängiges Verfahren zum Trainieren neuronaler Netze. Ein Eingangsvektor wird dem Netzwerk zur Verarbeitung vorgelegt. Die Ausgabe des Netzes wird mit Hilfe 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 zurückpropagiert, bis jedes Neuron einen zugehörigen Fehlerwert hat, der in etwa seinen Beitrag zur ursprünglichen Ausgabe darstellt. Das Netzwerk kann dann aus diesen Fehlern lernen, indem es einen Algorithmus, wie z. B. den stochastischen Gradientenabstiegsalgorithmus, verwendet, um die Gewichtungen des neuronalen Netzwerks zu aktualisieren.
  • 9A bis 9B illustriert ein beispielhaftes rekurrentes neuronales Netz. 9A illustriert verschiedene Schichten innerhalb eines CNN. Wie in 9A dargestellt, kann ein beispielhaftes CNN, das zur Modellierung der Bildverarbeitung verwendet wird, eine Eingabe 902 empfangen, die die Rot-, Grün- und Blau-Komponenten (RGB) eines Eingabebildes beschreibt. Die Eingabe 902 kann von mehreren Konvolutionsschichten verarbeitet werden (z. B. Konvolutionsschicht 904, Konvolutionsschicht 906). Die Ausgabe der mehrfachen Konvolutionsschichten kann optional von einem Satz vollständig verbundener Schichten 908 verarbeitet werden. Neuronen in einer vollständig verbundenen Schicht haben vollständige Verbindungen zu allen Aktivierungen in der vorherigen Schicht, wie zuvor für ein Feedforward-Netzwerk beschrieben. Die Ausgabe der vollständig verbundenen Schichten 908 kann verwendet werden, um ein Ausgabeergebnis des Netzes zu erzeugen. Die Aktivierungen innerhalb der vollverknüpften Schichten 908 können durch Matrixmultiplikation statt durch Konvolution berechnet werden. Nicht alle CNN-Umsetzungen verwenden vollständig verbundene Schichten 908. In einigen Umsetzungen kann zum Beispiel die Konvolutionsschicht 906 die Ausgabe für das CNN erzeugen.
  • Die Konvolutionsschichten weisen spärliche Verbindungen auf, was sich von der traditionellen Konfiguration neuronaler Netze unterscheidet, die in den voll verbundenen Schichten 908 zu finden ist. Traditionelle neuronale Netzwerkschichten sind vollständig verbunden, sodass jede Ausgabeeinheit mit jeder Eingabeeinheit interagiert. Die Konvolutionsschichten sind jedoch spärlich verschaltet, da die Ausgabe der Konvolution eines Feldes (anstelle des jeweiligen Zustandswertes jedes der Knoten im Feld) in die Knoten der nachfolgenden Schicht eingegeben wird, wie illustriert. Die zu den Konvolutionsschichten gehörenden Kernel führen Konvolutionsoperationen durch, deren Ausgabe an die nächste Schicht gesendet wird. Die Dimensionalitätsreduktion, die innerhalb der Konvolutionsschichten ausgeführt wird, ist ein Aspekt, der es dem CNN ermöglicht, zur Verarbeitung großer Bilder zu skalieren.
  • 9B illustriert beispielhafte Berechnungsschritte innerhalb einer Konvolutionsschicht eines CNN. Die Eingabe in eine Konvolutionsschicht 912 eines CNN kann in drei Stufen in einer Konvolutionsschicht 914 verarbeitet werden. Die drei Stufen können eine Konvolutionsstufe 916, eine Detektorstufe 918 und eine Pooling-Stufe 920 umfassen. Die Konvolutionsschicht 914 kann dann Daten an eine nachfolgende Konvolutionsschicht ausgeben. Die letzte Konvolutionsschicht des Netzwerks kann Ausgabe-Merkmalskartendaten generieren oder Eingaben für eine vollständig verbundene Schicht bereitstellen, z. B. um einen Klassifizierungswert für die Eingabe in das CNN zu erzeugen.
  • In der Konvolutionsstufe 916 werden mehrere Konvolutionen parallel ausgeführt, um einen Satz von linearen Aktivierungen zu erzeugen. Die Konvolutionsstufe 916 kann eine affine Transformation umfassen, d. h. eine beliebige Transformation, die als lineare Transformation plus eine Übersetzung angegeben werden kann. Affine Transformationen umfassen Rotationen, Übersetzungen, Skalierungen und Kombinationen dieser Transformationen. Die Konvolutionsstufe berechnet die Ausgabe von Funktionen (z. B. Neuronen), die mit bestimmten Regionen in der Eingabe verbunden sind, die als die dem Neuron zugeordnete lokale Region bestimmt werden kann. Die Neuronen berechnen ein Punktprodukt zwischen den Gewichtungenn der Neuronen und der Region im lokalen Eingang, mit dem die Neuronen verbunden sind. Die Ausgabe der Konvolutionsstufe 916 definiert einen Satz von linearen Aktivierungen, die von aufeinanderfolgenden Stufen der Konvolutionsschicht 914 verarbeitet werden.
  • Die linearen Aktivierungen können von einer Detektorstufe 918 verarbeitet werden. In der Detektorstufe 918 wird jede lineare Aktivierung durch eine nichtlineare Aktivierungsfunktion verarbeitet. Die nichtlineare Aktivierungsfunktion erhöht die nichtlinearen Eigenschaften des Gesamtnetzes, ohne die rezeptiven Felder der Konvolutionsschicht zu beeinflussen. Es können verschiedene Arten von nichtlinearen Aktivierungsfunktionen verwendet werden. Ein spezieller Typ ist die gleichgerichtete lineare Einheit (ReLU), die eine Aktivierungsfunktion verwendet, die als f(x)=max(0,x) definiert ist, sodass die Aktivierung bei Null abgeschwächt wird.
  • Die Pooling-Stufe 920 verwendet eine Pooling-Funktion, die die Ausgabe der Konvolutionsschicht 906 durch eine zusammenfassende Statistik der nahe gelegenen Ausgaben ersetzt. Die Pooling-Funktion kann verwendet werden, um Übersetzungsinvarianz in das neuronale Netzwerk einzuführen, sodass kleine Übersetzungen der Eingabe die gepoolten Ausgaben nicht verändern. Die Invarianz gegenüber lokaler Übersetzung kann in Szenarien nützlich sein, in denen das Vorhandensein eines Merkmals in den Eingabedaten wichtiger ist als die genaue Position des Merkmals. Während der Pooling-Stufe 920 können verschiedene Arten von Pooling-Funktionen verwendet werden, z. B. Max-Pooling, Durchschnitts-Pooling und L2-Norm-Pooling. Außerdem umfassen einige CNN-Umsetzungen keine Pooling-Stufe. Stattdessen ersetzen solche Umsetzungen eine zusätzliche Konvolutionsstufe, die eine erhöhte Schrittweite relativ zu den vorherigen Konvolutionsstufen hat.
  • Die Ausgabe der Konvolutionsschicht 914 kann dann von der nächsten Schicht 922 verarbeitet werden. Die nächste Schicht 922 kann eine zusätzliche Konvolutionsschicht oder eine der vollverknüpften Schichten 908 sein. Beispielsweise kann die erste Konvolutionsschicht 904 aus 9A an die zweite Konvolutionsschicht 906 ausgeben kann, während die zweite Konvolutionsschicht an eine erste Schicht der vollständig verbundenen Schichten 908 ausgeben kann.
  • 10 illustriert ein beispielhaftes rekurrentes neuronales Netz 1000. In einem rekurrenten neuronalen Netz (RNN) beeinflusst der vorherige Zustand des Netzes die Ausgabe des aktuellen Zustands des Netzes. RNNs können auf verschiedene Weise mit verschiedenen Funktionen aufgebaut werden. Bei der Nutzung von RNNs geht es im Allgemeinen um die Verwendung mathematischer Modelle zur Vorhersage der Zukunft auf der Grundlage einer vorherigen Sequenz von Eingaben. Ein RNN kann z. B. zur statistischen Sprachmodellierung verwendet werden, um ein kommendes Wort anhand einer vorherigen Wortfolge vorherzusagen. Das illustrierte RNN 1000 kann beschrieben werden mit einer Eingangsschicht 1002, die einen Eingangsvektor empfängt, versteckten Schichten 1004 zur Umsetzung einer rekurrenten Funktion, einem Rückkopplungsmechanismus 1005, um einen „Speicher“ vorheriger Zustände zu ermöglichen, und einer Ausgangsschicht 1006 zur Ausgabe eines Ergebnisses. Der RNN 1000 arbeitet auf der Basis von Zeitschritten. Der Zustand des RNN zu einem bestimmten Zeitschritt wird basierend auf dem vorherigen Zeitschritt über den Rückkopplungsmechanismus 1005 beeinflusst. Für einen bestimmten Zeitschritt wird der Zustand der ausgeblendeten Schichten 1004 durch den vorherigen Zustand und die Eingabe im aktuellen Zeitschritt definiert. Eine anfängliche Eingabe (x1) zu einem ersten Zeitschritt kann von der verborgenen Schicht 1004 verarbeitet werden. Eine zweite Eingabe (x2) kann von der versteckten Schicht 1004 unter Verwendung von Zustandsinformationen verarbeitet werden, die bei der Verarbeitung der ersten Eingabe (x1) ermittelt wurden. Ein gegebener Zustand kann als s_t=f(Uxt+ Wst-1) berechnet werden, wobei U und W Parametermatrizen sind. Die Funktion f ist allgemein eine Nichtlinearität, wie z. B. die hyperbolische Tangensfunktion (Tanh) oder eine Variante der Gleichrichterfunktion f(x)=max(0,x). Die spezifische mathematische Funktion, die in den versteckten Schichten 1004 verwendet wird, kann jedoch abhängig von den spezifischen Umsetzungsdetails des RNN 1000 variieren.
  • Zusätzlich zu den beschriebenen grundlegenden CNN- und RNN-Netzwerken kann die Beschleunigung für Variationen dieser Netzwerke aktiviert werden. Ein Beispiel für eine RNN-Variante ist das Long Short Term Memory (LSTM) RNN. LSTM RNNs sind in der Lage, langfristige Abhängigkeiten zu lernen, die für die Verarbeitung längerer Sprachsequenzen notwendig sein können. Eine Variante des CNN ist ein Convolutional Deep Belief Network, das eine ähnliche Struktur wie ein CNN hat und auf ähnliche Weise wie ein Deep Belief Network trainiert wird. Ein Deep Belief Network (DBN) ist ein generatives neuronales Netzwerk, das aus mehreren Schichten stochastischer (zufälliger) Variablen zusammengesetzt ist. DBNs können schichtweise mit greedy unsupervised learning trainiert werden. Die gelernten Gewichtungen des DBN können dann zum Vortraining von neuronalen Netzen verwendet werden, indem ein optimaler Anfangssatz von Gewichtungenn für das neuronale Netz bestimmt wird. In weiteren Ausführungsformen ist die Beschleunigung für das Reinforcement Learning aktiviert. Beim Reinforcement Learning lernt ein künstlicher Agent durch Interaktion mit seiner Umgebung. Der Agent ist so konfiguriert, dass er bestimmte Ziele optimiert, um die kumulativen Belohnungen zu maximieren.
  • 11 illustriert das Training und den Einsatz eines tiefen neuronalen Netzes. Nachdem ein gegebenes Netz für eine Aufgabe strukturiert wurde, wird das neuronale Netz anhand eines Trainingsdatensatzes 1102 trainiert. Es wurden verschiedene Trainings-Frameworks 1104 entwickelt, die eine Hardwarebeschleunigung des Trainingsablaufes ermöglichen. Beispielsweise kann das Maschinenlern-Framework 604 aus 6 als Trainings-Framework 604 konfiguriert sein. Das Trainings-Framework 604 kann sich in ein untrainiertes neuronales Netz 1106 einklinken und ermöglichen, dass das untrainierte neuronale Netz mit den hierin beschriebenen parallelen Verarbeitungsressourcen trainiert wird, um ein trainiertes neuronales Netz 1108 zu erzeugen.
  • Um den Trainingsablauf zu starten, können die Anfangsgewichte zufällig oder durch Vortraining mit einem Deep Belief Network gewählt werden. Der Trainingszyklus kann dann entweder überwacht oder nicht überwacht ausgeführt werden.
  • Überwachtes Lernen ist ein Lernverfahren, bei dem das Training als vermittelte Operation ausgeführt wird, z. B. wenn der Trainingsdatensatz 1102 Eingaben umfasst, die mit der gewünschten Ausgabe für die Eingabe gepaart sind, oder wenn der Trainingsdatensatz Eingaben mit bekannter Ausgabe umfasst 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 durch das System zurück propagiert. Das Trainings-Framework 1104 kann die Gewichtungen anpassen, die das untrainierte neuronale Netz 1106 steuern. Das Trainings-Framework 1104 kann Werkzeuge bereitstellen, um zu überwachen, wie gut das untrainierte neuronale Netzwerk 1106 zu einem Modell konvergiert, das geeignet ist, korrekte Antworten basierend auf bekannten Eingabedaten zu erzeugen. Der Trainingsablauf findet wiederholt statt, da die Gewichtungen des Netzwerks angepasst werden, um die vom neuronalen Netzwerk erzeugte Ausgabe zu verfeinern. Der Trainingsablauf kann fortgesetzt werden, bis das neuronale Netz eine statistisch gewünschte Genauigkeit erreicht, die mit einem trainierten neuronalen Netz 1108 verbunden ist. Das trainierte neuronale Netzwerk 1108 kann dann eingesetzt werden, um eine beliebige Anzahl von Maschinenlernoperationen zu umsetzen, um ein Inferenzergebnis 1114 basierend auf der Eingabe neuer Daten 1112 zu erzeugen.
  • Nicht überwachtes Lernen ist ein Lernverfahren, bei dem das Netzwerk versucht, sich selbst anhand von nicht beschrifteten Daten zu trainieren. Beim nicht überwachten Lernen umfasst der Trainingsdatensatz 1102 also Eingabedaten ohne zugehörige Ausgabedaten. Das nicht trainierte neuronale Netzwerk 1106 kann Gruppierungen innerhalb der unbeschrifteten Eingaben lernen und bestimmen, wie einzelne Eingaben mit dem Gesamtdatensatz zusammenhängen. Nicht überwachtes Training kann verwendet werden, um eine selbstorganisierende Karte zu erzeugen, die eine Art von trainiertem neuronalen Netzwerk 1108 ist, das in der Lage ist, nützliche Operationen zur Reduzierung der Dimensionalität von Daten auszuführen. Nicht überwachtes Training kann auch zur Erkennung von Anomalien verwendet werden, was 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 nicht überwachtem Training eingesetzt werden. Teilüberwachtes Lernen ist eine Technik, bei der der Trainingsdatensatz 1102 eine Mischung aus gelabelten und nicht gelabelten Daten mit gleicher Verteilung umfasst. Inkrementelles Lernen ist eine Variante des überwachten Lernens, bei der die Eingabedaten kontinuierlich verwendet werden, um das Modell weiter zu trainieren. Inkrementelles Lernen ermöglicht es dem trainierten neuronalen Netzwerk 1108, sich an die neuen Daten 1112 anzupassen, ohne das Wissen zu vergessen, das dem Netzwerk beim anfänglichen Training eingeflößt wurde.
  • Egal, ob er überwacht oder nicht überwacht stattfindet, kann der Trainingsablauf für besonders tiefe neuronale Netze für einen einzelnen Rechenknoten zu rechenintensiv sein. Anstatt einen einzelnen Rechenknoten zu verwenden, kann ein verteiltes Netzwerk von Rechenknoten verwendet werden, um den Trainingsablauf zu beschleunigen.
  • 12A ist ein Blockdiagramm, das verteiltes Lernen illustriert. Verteiltes Lernen ist ein Trainingsmodell, das mehrere verteilte Rechenknoten verwendet, um ein überwachtes oder nicht überwachtes Training eines neuronalen Netzwerks auszuführen. Die verteilten Rechenknoten können jeweils einen oder mehrere Host-Prozessoren und einen oder mehrere der Allzweck-Verarbeitungsknoten umfassen, wie z. B. die hochparallele Allzweck-Grafikprozessoreinheit 700 aus 7. Wie illustriert, kann das verteilte Lernen mit Modellparallelität 1202, Datenparallelität 1204 oder einer Kombination aus Modell- und Datenparallelität 1206 ausgeführt werden.
  • Bei der Modellparallelität 1202 können verschiedene Rechenknoten in einem verteilten System Trainingsberechnungen für verschiedene Abschnitte eines einzelnen Netzes ausführen. Beispielsweise kann jede Schicht eines neuronalen Netzes von einem anderen Verarbeitungsknoten des verteilten Systems trainiert werden. Die Vorteile der Modellparallelität umfassen die Möglichkeit, auf besonders große Modelle zu skalieren. Die Aufteilung der Berechnungen, die mit verschiedenen Schichten des neuronalen Netzes verbunden sind, ermöglicht das Training von sehr großen neuronalen Netzen, 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 nicht überwachtes Training großer neuronaler Netze auszuführen.
  • Bei der Datenparallelität 1204 verfügen die verschiedenen Knoten des verteilten Netzwerks über eine vollständige Instanz des Modells und jeder Knoten erhält einen anderen Abschnitt der Daten. Die Ergebnisse aus den verschiedenen Knoten werden dann kombiniert. Obwohl verschiedene Ansätze zur Datenparallelität möglich sind, erfordern alle datenparallelen Trainingsansätze eine Technik zur Kombination der Ergebnisse und zur Synchronisierung der Modellparameter zwischen den einzelnen Knoten. Beispielhafte Ansätze zum Kombinieren von Daten sind Parameter-Durchschnittsbildung und aktualisierungsbasierte Datenparallelität. Die Parameter-Durchschnittsbildung trainiert jeden Knoten auf einer Teilmenge der Trainingsdaten und setzt die globalen Parameter (z. B. Gewichtungen, Verzerrungen) auf den Durchschnitt der Parameter von jedem Knoten. Die Parameter-Durchschnittsbildung verwendet einen zentralen Parameterserver, der die Parameterdaten pflegt. Die aktualisierungsbasierte Datenparallelität ist ähnlich wie die Parameter-Durchschnittsbildung, außer, dass anstelle der Übertragung von Parametern von den Knoten zum Parameterserver die Aktualisierungen des Modells übertragen werden. Zusätzlich kann die aktualisierungsbasierte Datenparallelität dezentral ausgeführt werden, wobei die Aktualisierungen komprimiert und zwischen den Knoten übertragen werden.
  • Die kombinierte Modell- und Datenparallelität 1206 kann z. B. in einem verteilten System umgesetzt werden, in dem jeder Rechenknoten mehrere GPUs umfasst. Jeder Knoten kann eine vollständige Instanz des Modells haben, wobei separate GPUs innerhalb jedes Knotens verwendet werden, um verschiedene Abschnitte des Modells zu trainieren.
  • Verteiltes Training hat einen erhöhten Overhead im Vergleich zum Training auf einem einzelnen Rechner. Die hierin beschriebenen Parallelprozessoren und GPGPUs können jedoch jeweils verschiedene Techniken umsetzen, um den Overhead des verteilten Trainings zu verringern, unter anderem Techniken, die eine Datenübertragung von GPU zu GPU mit hoher Bandbreite und eine beschleunigte Remote-Datensynchronisation ermöglichen.
  • 12B ist ein Blockdiagramm, das eine programmierbare Netzwerkschnittstelle 1210 und eine Datenverarbeitungseinheit illustriert. Die programmierbare Netzwerkschnittstelle 1210 ist eine programmierbare Netzwerk-Engine, die zur Beschleunigung von netzwerkbasierten Rechenaufgaben innerhalb einer verteilten Umgebung verwendet werden kann. Die programmierbare Netzwerkschnittstelle 1210 kann über die Host-Schnittstelle 1270 mit einem Host-System gekoppelt werden. Die programmierbare Netzwerkschnittstelle 1210 kann verwendet werden, um Netzwerk- oder Speicheroperationen für CPUs oder GPUs des Host-Systems zu beschleunigen. Das Host-System kann z. B. ein Knoten eines verteilten Lernsystems sein, mit dem ein verteiltes Training ausgeführt wird, z. B. wie in 12A dargestellt. Das Host-System kann auch ein Rechenzentrumsknoten innerhalb eines Rechenzentrums sein.
  • In einer Ausführungsform kann der Zugriff auf einen entfernten Speicher mit Modelldaten durch die programmierbare Netzwerkschnittstelle 1210 beschleunigt werden. Beispielsweise kann die programmierbare Netzwerkschnittstelle 1210 so konfiguriert sein, dass sie entfernte Speichervorrichtungen als lokale Speichervorrichtungen für das Host-System darstellt. Die programmierbare Netzwerkschnittstelle 1210 kann auch RDMA-Operationen (Remote Direct Memory Access) beschleunigen, die zwischen GPUs des Host-Systems mit GPUs entfernter Systeme ausgeführt werden. In einer Ausführungsform kann die programmierbare Netzwerkschnittstelle 1210 Speicherfunktionalität wie z. B., aber nicht beschränkt auf NVME-oF ermöglichen. Die programmierbare Netzwerkschnittstelle 1210 kann auch die Verschlüsselung, Datenintegrität, Komprimierung und andere Operationen für die Fernspeicherung im Auftrag des Host-Systems beschleunigen, sodass die Fernspeicherung sich den Latenzen von Speichervorrichtungen nähert, die direkt an das Host-System angeschlossen sind.
  • Die programmierbare Netzwerkschnittstelle 1210 kann auch die Ressourcenzuweisung und -verwaltung im Auftrag des Host-Systems ausführen. Speichersicherheitsoperationen können an die programmierbare Netzwerkschnittstelle 1210 ausgelagert und zusammen mit der Zuweisung und Verwaltung von entfernten Speicherressourcen ausgeführt werden. Netzwerkbasierte Operationen zur Verwaltung des Zugriffs auf den entfernten Speicher, die sonst von einem Prozessor des Host-Systems ausgeführt würden, können stattdessen von der programmierbaren Netzwerkschnittstelle 1210 ausgeführt werden.
  • In einer Ausführungsform können Netzwerk- und/oder Datensicherheitsoperationen vom Host-System auf die programmierbare Netzwerkschnittstelle 1210 ausgelagert werden. Die Sicherheitsrichtlinien für einen Rechenzentrumsknoten können von der programmierbaren Netzwerkschnittstelle 1210 statt von den Prozessoren des Hostsystems gehandhabt werden. Beispielsweise kann die programmierbare Netzwerkschnittstelle 1210 einen versuchten netzwerkbasierten Angriff (z. B. DDoS) auf das Host-System erkennen und abwehren und so verhindern, dass der Angriff die Verfügbarkeit des Host-Systems beeinträchtigt.
  • Die programmierbare Netzwerkschnittstelle 1210 kann ein System auf einem Chip (SoC 1220) umfassen, das ein Betriebssystem über mehrere Prozessorkerne 1222 ausführt. Die Prozessorkerne 1222 können Allzweckprozessorkerne (z. B. CPU) umfassen. In einer Ausführungsform können die Prozessorkerne 1222 auch einen oder mehrere GPU-Kerne umfassen. Der SoC 1220 kann Anweisungen ausführen, die in einer Speichervorrichtung 1240 gespeichert sind. Eine Speichervorrichtung 1250 kann lokale Betriebssystemdaten speichern. Die Speichervorrichtung 1250 und die Speichervorrichtung 1240 können auch zum Zwischenspeichern entfernter Daten für das Host-System verwendet werden. Die Netzwerkports 1260A bis 1260B erlauben eine Verbindung zu einem Netzwerk oder einer Struktur und erleichtern den Netzwerkzugriff für den SoC 1220 und, über die Host-Schnittstelle 1270, für das Host-System. Die programmierbare Netzwerkschnittstelle 1210 kann auch eine E/A-Schnittstelle 1275 umfassen, wie z. B. eine USB-Schnittstelle. Die E/A-Schnittstelle 1275 kann zum Koppeln externer Vorrichtungenmit der programmierbaren Netzwerkschnittstelle 1210 oder als Debug-Schnittstelle verwendet werden. Die programmierbare Netzwerkschnittstelle 1210 umfasst auch eine Verwaltungsschnittstelle 1230, die es der Software auf der Host-Vorrichtung ermöglicht, die programmierbare Netzwerkschnittstelle 1210 und/oder den SoC 1220 zu verwalten und zu konfigurieren. In einer Ausführungsform kann die programmierbare Netzwerkschnittstelle 1210 auch einen oder mehrere Beschleuniger oder GPUs 1245 umfassen, um die Auslagerung von parallelen Rechenaufgaben vom SoC 1220, vom Hostsystem oder von entfernten Systemen zu akzeptieren, die über die Netzwerkports 1260A bis 1260B gekoppelt sind.
  • Beispielhafte Maschinenlem-Anwendungen
  • Maschinenlernen kann zur Lösung mehreren technologischen Problemen eingesetzt werden, unter anderem, aber nicht beschränkt auf Computer Vision, autonomes Fahren und Navigation, Spracherkennung und Sprachverarbeitung. Computer Vision ist traditionell eines der aktivsten Forschungsgebiete für Anwendungen des Maschinenlernens. Die Anwendungen von Computer Vision reichen von der Reproduktion menschlicher visueller Fähigkeiten, wie z. B. dem Erkennen von Gesichtern, bis hin zur Schaffung neuer Kategorien visueller Fähigkeiten. Beispielsweise können Computer-Vision-Anwendungen so konfiguriert sein, dass sie Schallwellen aus den Vibrationen erkennen, die in den in einem Video sichtbaren Objekten induziert werden. Parallelprozessor-beschleunigtes Maschinenlernen ermöglicht es, Computer-Vision-Anwendungen mit wesentlich größeren Trainingsdatensätzen zu trainieren, als dies bisher möglich war, und Inferencing-Systeme mit Parallelprozessoren mit geringem Stromverbrauch zu betreiben.
  • Parallelprozessor-beschleunigtes Maschinenlernen hat Anwendungen für autonomes Fahren, unter anderem Fahrspur- und Verkehrszeichenerkennung, Hindernisvermeidung, Navigation und Fahrkontrolle. Beschleunigte Maschinenlernverfahren können zum Trainieren von Fahrmodellen auf der Grundlage von Datensätzen verwendet werden, die die entsprechenden Reaktionen auf bestimmte Trainingseingaben definieren. Die hierin beschriebenen Parallelprozessoren können ein schnelles Training der immer komplexeren neuronalen Netze ermöglichen, die für Lösungen zum autonomen Fahren verwendet werden, und ermöglichen den Einsatz von Inferencing-Prozessoren mit geringem Stromverbrauch in einer mobilen Plattform, die für die Integration in autonome Fahrzeuge geeignet ist.
  • Parallelprozessor-beschleunigte tiefe neuronale Netze haben Maschinenlernansätze für die automatische Spracherkennung (ASR) ermöglicht. ASR umfasst die Erstellung einer Funktion, die die wahrscheinlichste sprachliche Sequenz angesichts einer akustischen Eingangssequenz berechnet. Beschleunigtes Maschinenlernen mit tiefen neuronalen Netzen hat es ermöglicht, die bisher für ASR verwendeten Hidden-Markov-Modelle (HMMs) und Gaussian-Mixture-Modelle (GMMs) zu ersetzen.
  • Parallelprozessor-beschleunigtes 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. Beispielhafte Anwendungen für natürliche Sprachprozessoren sind die automatische Maschinenübersetzung zwischen menschlichen Sprachen.
  • Die zum Maschinenlernen verwendeten Parallelverarbeitungsplattformen können in Trainingsplattformen und Einsatzplattformen unterteilt werden. Trainingsplattformen sind in der Regel hochparallel und beinhalten Optimierungen zur Beschleunigung von Multi-GPU-Einzelknoten-Training und Multi-Node-Multi-GPU-Training. Zu den beispielhaften Parallelprozessoren, die sich für das Training eignen, gehört die Allzweck-Grafikprozessoreinheit 700 aus 7 und das Multi-GPU-Rechnersystem 800 aus 8. Im Gegenteil dazu umfassen eingesetzte Plattformen für Maschinenlernen in der Regel parallele Prozessoren mit geringerer Leistung, die für den Einsatz in Produkten wie Kameras, autonomen Robotern und autonomen Fahrzeugen geeignet sind.
  • Zusätzlich können Techniken des Maschinenlernens zur Beschleunigung oder Verbesserung von Grafikverarbeitungsaktivitäten eingesetzt werden. Beispielsweise kann ein Modell für Maschinenlernen darauf trainiert werden, die von einer GPUbeschleunigten Anwendung erzeugte Ausgabe zu erkennen und eine hochskalierte Version dieser Ausgabe zu erzeugen. Solche Techniken können angewendet werden, um die Erzeugung von hochauflösenden Bildern für eine Spieleanwendung zu beschleunigen. Verschiedene andere Aktivitäten in der Grafikpipeline können von der Verwendung von Maschinenlernen profitieren. Beispielsweise können Modelle für Maschinenlernen darauf trainiert werden, Tessellierungsoperationen auf Geometriedaten auszuführen, um die Komplexität von Geometriemodellen zu erhöhen, sodass aus Geometrien mit relativ geringer Detailtiefe automatisch eine feindetailierte Geometrie erzeugt werden kann.
  • 13 illustriert ein beispielhaftes Inferencing-System auf einem Chip (Inferencing-SOC) 1300, das für die Ausführung von Inferencing mit einem trainierten Modell geeignet ist. Das SOC 1300 kann Verarbeitungskomponenten integrieren, darunter einen Medienprozessor 1302, einen Bildverarbeitungsprozessor 1304, eine GPGPU 1306 und einen Mehrkernprozessor 1308. Die GPGPU 1306 kann eine hierin beschriebene GPGPU sein, wie z. B. die GPGPU 700, und der Mehrkernprozessor 1308 kann ein hierin beschriebener Mehrkernprozessor sein, wie z. B. die Mehrkernprozessoren 405 bis 406. Der SOC 1300 kann zusätzlich einen On-Chip-Speicher 1305 umfassen, der einen gemeinsamen On-Chip-Datenpool ermöglichen kann, auf den jede der Verarbeitungskomponenten zugreifen kann. Die Verarbeitungskomponenten können für einen stromsparenden Betrieb optimiert werden, um den Einsatz in einer Vielzahl von Plattformen für Maschinenlernen zu ermöglichen, unter anderem autonomer Fahrzeuge und autonomer Roboter. Eine Umsetzung des SOC 1300 kann zum Beispiel als Abschnitt des Hauptsteuerungssystems für ein autonomes Fahrzeug verwendet werden. Wenn der SOC 1300 für den Einsatz in autonomen Fahrzeugen konfiguriert ist, ist der SOC so ausgelegt und konfiguriert, dass er die relevanten funktionalen Sicherheitsstandards des Einsatzlandes erfüllt.
  • Im Betrieb können der Medienprozessor 1302 und der Bildverarbeitungsprozessor 1304 zusammenarbeiten, um Computer-Vision-Operationen zu beschleunigen. Der Medienprozessor 1302 kann die decodierung mehrerer hochauflösender Videoströme (z. B. 4K, 8K) mit geringer Latenz ermöglichen. Die decodierten Videoströme können in einen Puffer im On-Chip-Speicher 1305 geschrieben werden. Der Bildverarbeitungsprozessor 1304 kann dann das decodierte Video analysieren und vorläufige Verarbeitungsvorgänge an den Einzelbildern des decodierten Videos als Vorbereitung für die Verarbeitung der Einzelbilder mit einem trainierten Bilderkennungsmodell ausführen. Beispielsweise kann der Bildverarbeitungsprozessor 1304 die Konvolutionsoperationen für ein CNN beschleunigen, das zur Bilderkennung auf den hochauflösenden Videodaten verwendet wird, während die Backend-Modellberechnungen von der GPGPU 1306 ausgeführt werden.
  • Der Mehrkernprozessor 1308 kann eine Steuerlogik umfassen, die bei der Sequenzierung und Synchronisierung von Datenübertragungen und gemeinsamen Speicheroperationen hilft, die vom Medienprozessor 1302 und dem Vision-Prozessor 1304 ausgeführt werden. Der Mehrkernprozessor 1308 kann auch als Anwendungsprozessor wirken, um Softwareanwendungen auszuführen, die die Inferenzberechnungsfähigkeit der GPGPU 1306 nutzen können. Beispielsweise kann zumindest ein Abschnitt der Navigations- und Fahrlogik in Software umgesetzt werden, die auf dem Mehrkernprozessor 1308 ausgeführt wird. Solche Software kann direkt Rechenlasten an die GPGPU 1306 ausgeben oder die Rechenlasten können an den Mehrkernprozessor 1308 ausgegeben werden, der zumindest einen Abschnitt dieser Operationen an die GPGPU 1306 auslagern kann.
  • Die GPGPU 1306 kann Rechencluster umfassen, wie z. B. eine stromsparende Konfiguration der Verarbeitungscluster 706A bis 706H innerhalb der Allzweck-Grafikprozessoreinheit 700. Die Rechencluster innerhalb der GPGPU 1306 können Befehle unterstützen, die speziell für die Ausführung von Inferenzberechnungen auf einem trainierten neuronalen Netzwerk optimiert sind. Die GPGPU 1306 kann beispielsweise Befehle zur Ausführung von Berechnungen mit geringer Genauigkeit wie 8-Bit- und 4-Bit-Integer-Vektoroperationen unterstützen.
  • Zusätzliche Systemübersicht
  • 14 ist ein Blockdiagramm eines Verarbeitungssystems 1400. Die Elemente aus 14 mit gleichen oder ähnlichen Namen wie die Elemente einer anderen Figur hierin beschreiben die gleichen Elemente wie in den anderen Figuren, können in ähnlicher Weise arbeiten oder funktionieren, können die gleichen Komponenten umfassen und können mit anderen Einheiten verbunden sein, wie die, die an anderer Stelle hierin beschrieben sind, sind aber nicht auf solche beschränkt. Das System 1400 kann in einem Einprozessor-Desktop-System, einem Multiprozessor-Workstation-System oder einem Server-System mit einer großen Anzahl von Prozessoren 1402 oder Prozessorkernen 1407 eingesetzt werden. Das System 1400 kann eine Verarbeitungsplattform sein, die in eine integrierte System-on-a-Chip-Schaltung (SoC-Schaltung) für den Einsatz in mobilen, tragbaren oder eingebetteten Vorrichtungen, wie z. B. in Internet-of-Things-Vorrichtungen (IoT-Vorrichtungen) mit drahtgebundener oder drahtloser Konnektivität zu einem lokalen oder Wide Area Network, integriert ist.
  • Das System 1400 kann ein Verarbeitungssystem mit Komponenten sein, die denen aus 1 entsprechen. In verschiedenen Konfigurationen können z. B. der/die Prozessor(en) 1402 oder der/die Prozessorkern(e) 1407 dem/den Prozessor(en) 102 aus 1 entsprechen. Der/die Grafikprozessor(en) 1408 kann/können dem/den Parallelprozessor(en) 112 aus 1 entsprechen. Der externe Grafikprozessor 1418 kann eines der Add-In-Vorrichtungen 120 aus 1 sein.
  • Das System 1400 kann Folgendes umfassen, damit gekoppelt oder darin integriert sein: eine serverbasierte Spielplattform; eine Spielkonsole, unter anderem einer Spiel- und Medienkonsole; eine mobile Spielkonsole, eine Handheld-Spielkonsole oder eine Online-Spielkonsole. Das System 1400 kann ein Abschnitt eines Mobiltelefons, eines Smartphones, eines Tablet-Computers oder einer mobilen, mit dem Internet verbundenen Vorrichtung wie z. B. eines Laptops mit geringer interner Speicherkapazität sein. Das Verarbeitungssystem 1400 kann auch eine tragbare Vorrichtung, wie z. B. eine intelligente Uhr, eine intelligente Brille oder Kleidung, die mit Augmented-Reality-Funktionen (AR-Funktionen) oder Virtual-Reality-Funktionen (VR-Funktionen) erweitert ist, um visuelle, akustische oder taktile Ausgaben zu liefern, um visuelle, akustische oder taktile Erfahrungen der realen Welt zu ergänzen oder anderweitig Text, Audio, Grafiken, Video, holografische Bilder oder Video oder taktiles Feedback zu liefern, eine andere Augmented-Reality-Vorrichtung (AR-Vorrichtung) oder eine andere Virtual-Reality-Vorrichtung (VR-Vorrichtung) umfassen, mit diesem gekoppelt oder in dieses integriert sein. Das Verarbeitungssystem 1400 kann ein Fernsehgerät oder ein Set-Top-Box-Gerät umfassen oder ein Abschnitt davon sein. Das System 1400 kann ein selbstfahrendes Fahrzeug, wie z. B. einen Bus, einen Traktoranhänger, ein Auto, ein Motor- oder Elektrofahrrad, ein Flugzeug oder ein Segelflugzeug (oder eine beliebige Kombination davon) umfassen, mit diesem gekoppelt oder in dieses integriert sein. Das selbstfahrende Fahrzeug kann das System 1400 verwenden, um die um das Fahrzeug herum erfasste Umgebung zu verarbeiten.
  • Der eine oder die mehreren Prozessoren 1402 können einen oder mehrere Prozessorkerne 1407 umfassen, um Anweisungen zu verarbeiten, die bei ihrer Ausführung Operationen für die System- oder Anwendersoftware ausführen. Der mindestens eine der ein oder mehreren Prozessorkerne 1407 kann so konfiguriert sein, dass er einen bestimmten Anweisungssatz 1409 verarbeitet. Der Anweisungssatz 1409 kann Complex Instruction Set Computing (CISC), Reduced Instruction Set Computing (RISC) oder das Rechnen über ein Very Long Instruction Word (VLIW) ermöglichen. Ein oder mehrere Prozessorkerne 1407 können einen anderen Anweisungssatz 1409 verarbeiten, der Anweisungen umfassen kann, um die Emulation anderer Befehlssätze zu erleichtern. Der Prozessorkern 1407 kann auch andere Verarbeitungsvorrichtungen umfassen, wie z. B. einen digitalen Signalprozessor (DSP).
  • Der Prozessor 1402 kann einen Cache-Speicher 1404 umfassen. Abhängig von der Architektur kann der Prozessor 1402 einen einzelnen internen Cache oder mehrere Levels eines internen Cache aufweisen. In einigen Ausführungsformen wird der Cachespeicher von verschiedenen Bauteilen des Prozessors 1402 geteilt. In einigen Ausführungsformen verwendet der Prozessor 1402 außerdem einen externen Cache (z. B. einen Level-3-Cache (L3-Cache) oder Last-Level-Cache (LLC)) (nicht dargestellt), der von den Prozessorkernen 1407 unter Verwendung bekannter Cache-Kohärenztechniken geteilt werden kann. Eine Registerdatei 1406 kann zusätzlich im Prozessor 1402 umfasst sein und kann verschiedene Arten von Registern zum Speichern verschiedener Datentypen umfassen (z. B. Ganzzahlregister, Gleitkommaregister, Statusregister und ein Befehlszeigerregister). Einige Register können Allzweckregister sein, während sich andere Register speziell auf das Design des Prozessors 1402 beziehen.
  • Der eine oder die mehreren Prozessor(en) 1402 kann (können) mit einem oder mehreren Schnittstellenbus(en) 1410 gekoppelt sein, um Kommunikationssignale wie Adress-, Daten- oder Steuersignale zwischen dem Prozessor 1402 und anderen Komponenten im System 1400 zu übertragen. Der Schnittstellenbus 1410 kann in einer dieser Ausführungsformen ein Prozessorbus sein, wie z. B. eine Version des Direct-Media-Interface-Busses (DMI-Busses. Prozessorbusse sind jedoch nicht auf den DMI-Bus beschränkt und können einen oder mehrere Peripheral Component Interconnect-Busse (z. B. PCI, PCI express), Speicherbusse oder andere Arten von Schnittstellenbussen umfassen. Der/die Prozessor(en) 1402 kann/können zum Beispiel einen integrierten Speicher-Controller 1416 und einen Plattform-Controller-Hub 1430 umfassen. Der Speichercontroller 1416 ermöglicht die Kommunikation zwischen einer Speichervorrichtung und anderen Komponenten des Systems 1400, während der Plattformcontrollerhub (PCH) 1430 Verbindungen mit E/A-Vorrichtungen über einen örtlichen E/A-Bus bereitstellt.
  • Die Speichervorrichtung 1420 kann ein dynamischer Direktzugriffsspeicher (DRAM), ein statischer Direktzugriffsspeicher (SRAM), ein Flash-Speicher, ein Phasenwechselspeicher oder eine andere Speichervorrichtung mit geeigneter Leistung sein, um als Prozessspeicher zu dienen. Die Speichervorrichtung 1420 kann zum Beispiel als Systemspeicher für das System 1400 arbeiten, um Daten 1422 und Anweisungen 1421 zur Verwendung zu speichern, wenn der eine oder mehrere Prozessoren 1402 eine Anwendung oder einen Prozess ausführt. Der Speichercontroller 1416 koppelt sich auch mit einem optionalen externen Grafikprozessor 1418, der mit einem oder mehreren Grafikprozessoren 1408 in den Prozessoren 1402 kommunizieren kann, um Grafik- und Medienoperationen auszuführen. In einigen Ausführungsformen können Grafik-, Medien- oder Rechenoperationen durch einen Beschleuniger 1412 unterstützt werden, der ein Coprozessor ist, der so konfiguriert sein kann, dass er einen speziellen Satz von Grafik-, Medien- oder Rechenoperationen ausführt. Der Beschleuniger 1412 kann zum Beispiel ein Matrixmultiplikationsbeschleuniger sein, der zur Optimierung von Maschinenlernen oder Rechenoperationen verwendet wird. Der Beschleuniger 1412 kann ein Raytracing-Beschleuniger sein, der zur Ausführung von Raytracing-Operationen in Zusammenarbeit mit dem Grafikprozessor 1408 verwendet werden kann. In einer Ausführungsform kann ein externer Beschleuniger 1419 anstelle des Beschleunigers 1412 oder zusammen mit diesem verwendet werden.
  • Es kann eine Anzeigevorrichtung 1411 vorgesehen sein, die an den/die Prozessor(en) 1402 angeschlossen werden kann. Die Anzeigevorrichtung 1411 kann eines oder mehrere aus einer internen Anzeigevorrichtung, wie bei einer mobilen elektronischen Vorrichtung oder einer Laptopvorrichtung, oder einer externen Anzeigevorrichtung, die über eine Anzeigeschnittstelle (z. B. DisplayPort usw.) verbunden ist, sein. Die Anzeigevorrichtung 1411 kann ein kopfmontiertes Anzeige (HMD) sein, wie z. B. eine stereoskope Anzeigevorrichtung zur Verwendung in Virtual-Reality-Anwendungen (VR) oder Augmented-Reality-Anwendungen (AR).
  • Der Plattform-Controller-Hub 1430 kann es Peripherievorrichtungen ermöglichen, sich über einen Hochgeschwindigkeitse/A-Bus mit der Speichervorrichtung 1420 und dem Prozessor 1402 zu verbinden. Zu den E/A-Peripherievorrichtungen gehören u. a. ein Audio-Controller 1446, ein Netzwerk-Controller 1434, eine FirmwareSchnittstelle 1428, ein drahtloser Transceiver 1426, Berührungssensoren 1425, eine Datenspeichervorrichtung 1424 (z. B. nichtflüchtiger Speicher, flüchtiger Speicher, Festplattenlaufwerk, Flash-Speicher, NAND, 3D-NAND, 3D-XPoint/Optane usw.). Die Datenspeichervorrichtung 1424 kann über eine Speicherschnittstelle (z. B. SATA) oder über einen Peripheriebus, wie z. B. einen Peripheral Component Interconnect Bus (z. B. PCI, PCI express), angeschlossen werden. Die Touchsensoren 1425 können Touchscreensensoren, Drucksensoren oder Fingerabdrucksensoren umfassen. Der drahtlose Transceiver 1426 kann ein Wi-Fi-Transceiver, ein Bluetooth-Transceiver oder ein Mobilfunk-Transceiver wie ein 3G-, 4G-, 5G- oder Long-Term Evolution-Transceiver (LTE-Transceiver) sein. Die Firmwareschnittstelle 1428 ermöglicht die Kommunikation mit Systemfirmware, und kann beispielsweise eine Unified Extensible Firmware Interface (UEFI) sein. Der Netzwerkcontroller 1434 kann eine Netzwerkverbindung mit einem verkabelten Netzwerk ermöglichen. In einigen Ausführungsformen koppelt sich ein Hochleistungsnetzwerkcontroller (nicht dargestellt) mit dem Schnittstellenbus 1410. Der Audio-Controller 1446 kann ein mehrkanaliger High-Definition-Audio-Controller sein. In einigen dieser Ausführungsformen umfasst das System 1400 einen optionalen Legacy-E/A-Controller 1440 zur Kopplung von Legacy-Vorrichtungen (z. B. Personal System 2 (PS/2)) mit dem System. Der Plattformcontrollerhub 1430 kann sich auch mit einer oder mehreren Universal-Serial-Bus-Controller (USB-Controller) 1442 Verbindungseingabevorrichtungen verbinden, wie etwa mit Kombinationen aus Tastatur und Maus 1443, einer Kamera 1444 oder anderen USB -Eingabevorrichtungen.
  • Es ist zu erkennen, dass das dargestellte System 1400 beispielhaft und nicht einschränkend ist, da auch andere Arten von Datenverarbeitungssystemen, die unterschiedlich konfiguriert sind, verwendet werden können. Beispielsweise kann eine Instanz des Speichercontrollers 1416 und Plattformcontrollerhubs 1430 in einen diskreten externen Grafikprozessor integriert sein, wie etwa in den externen Grafikprozessor 1418. Der Plattform-Controller-Hub 1430 und/oder der Speicher-Controller 1416 können extern zu dem (den) einen oder mehreren Prozessor(en) 1402 sein. Beispielsweise kann das System 1400 einen externen Speichercontroller 1416 und Plattformcontrollerhub 1430 umfassen, der als ein Speichercontrollerhub und peripherer Controllerhub in einem Systemchipset konfiguriert sein kann, das mit dem/den Prozessor(en) 1402 in Kommunikation steht.
  • So können z. B. Leiterplatten („Schlitten“) verwendet werden, auf denen Komponenten wie CPUs, Speicher und andere Bauteile platziert werden, die für eine erhöhte thermische Leistung ausgelegt sind. Verarbeitungskomponenten wie die Prozessoren können sich auf der Oberseite eines Schlittens befinden, während sich speichernahe Komponenten, wie DIMMs, auf der Unterseite des Schlittens befinden. Infolge des verbesserten Luftstroms, der durch dieses Design bereitgestellt wird, können die Komponenten mit höheren Frequenzen und Leistungspegeln als in typischen Systemen betrieben werden, wodurch die Leistung erhöht wird. Außerdem sind die Schlitten so konfiguriert, dass sie blind mit Strom- und Datenkommunikationskabeln in einem Rack verbunden werden können, was ihre Fähigkeit verbessert, schnell entfernt, aufgerüstet, neu installiert und/oder ersetzt zu werden. Ebenso sind einzelne Komponenten, die sich auf den Schlitten befinden, wie z. B. Prozessoren, Beschleuniger, Speicher und Datenspeicherlaufwerke, so konfiguriert, dass sie aufgrund ihres größeren Abstands zueinander leicht aufgerüstet werden können. In der illustrativen Ausführungsform umfassen die Komponenten zusätzlich Hardware-Attestierungsmerkmale, um ihre Authentizität zu beweisen.
  • Ein Rechenzentrum kann eine einzelne Netzwerkarchitektur („Struktur“) verwenden, die mehrere andere Netzwerkarchitekturen wie Ethernet und Omni-Path unterstützt. Die Schlitten können über optische Fasern an Switches gekoppelt werden, die eine höhere Bandbreite und geringere Latenz als typische Twisted-Pair-Verkabelungen (z. B. Kategorie 5, Kategorie 5e, Kategorie 6 usw.) bieten. Aufgrund der Verbindungen mit hoher Bandbreite und geringer Latenz sowie der Netzwerkarchitektur kann das Rechenzentrum bei der Nutzung Ressourcen wie Speicher, Beschleuniger (z. B. GPUs, Grafikbeschleuniger, FPGAs, ASICs, Beschleuniger für neuronale Netzwerke und/oder künstliche Intelligenz usw.) und Datenspeicherlaufwerke, die physisch disaggregiert sind, bündeln und sie den Rechenressourcen (z. B. Prozessoren) nach Bedarf zur Verfügung stellen, sodass die Rechenressourcen auf die gebündelten Ressourcen zugreifen können, als wären sie lokal.
  • Eine Stromversorgung oder Quelle kann das System 1400 oder jede hierin beschriebene Komponente oder jedes System mit Spannung und/oder Strom versorgen. In einem Beispiel umfasst die Stromversorgung einen AC-zu-DC-Adapter (Wechselstrom-Gleichstrom-Adapter) zum Anschluss an eine Wandsteckdose. Eine solche AC-Stromquelle kann eine erneuerbare Energiequelle (z. B. Solarstrom) sein. In einem Beispiel umfasst die Stromquelle eine Gleichstromquelle, wie z. B. einen externen Wechselstrom-Gleichstrom-Wandler. Eine Stromquelle oder Stromversorgung kann auch drahtlose Ladehardware umfassen, um über die Nähe zu einem Ladefeld zu laden. Die Stromquelle kann eine interne Batterie, eine Wechselstromversorgung, eine bewegungsbasierte Stromversorgung, eine Solarstromversorgung oder eine Brennstoffzellenquelle umfassen.
  • 15A bis 15C illustrieren Rechnersysteme und Grafikprozessoren. Die Elemente aus 15A bis 15C mit gleichen oder ähnlichen Namen wie die Elemente einer anderen Figur hierin beschreiben die gleichen Elemente wie in den anderen Figuren, können in ähnlicher Weise arbeiten oder funktionieren, können die gleichen Komponenten umfassen und können mit anderen Einheiten verbunden sein, wie die, die an anderer Stelle hierin beschrieben sind, sind aber nicht auf solche beschränkt.
  • 15A ist ein Blockdiagramm eines Prozessors 1500, der eine Variante eines der Prozessoren 1402 sein kann und anstelle eines dieser Prozessoren verwendet werden kann. Daher offenbart die Offenbarung beliebiger Merkmale in Kombination mit dem Prozessor 1500 hier auch eine entsprechende Kombination mit dem/den Prozessor(en) 1402, ist aber nicht auf diese beschränkt. Der Prozessor 1500 kann einen oder mehrere Prozessorkerne 1502A bis 1502N, einen integrierten Speichercontroller 1514 und einen integrierten Grafikprozessor 1508 aufweisen. Wenn ein integrierter Grafikprozessor 1508 ausgeschlossen ist, umfasst das System, das den Prozessor umfasst, eine Grafikprozessorvorrichtung innerhalb eines Systemchipsets oder gekoppelt über einen Systembus. Der Prozessor 1500 kann zusätzliche Kerne umfassen, bis hin zu und unter anderem des zusätzlichen Kerns 1502N, der durch die gestrichelt umrandeten Kästchen illustriert wird. Jeder der Prozessorkerne 1502A bis 1502N umfasst eine oder mehrere interne Cache-Einheiten 1504A bis 1504N. In einigen Ausführungsformen hat jeder Prozessorkern 1502A bis 1502N auch Zugriff auf eine oder mehrere gemeinsam genutzte Cache-Einheiten 1506. Die internen Cache-Einheiten 1504A bis 1504N und die gemeinsam genutzten Cache-Einheiten 1506 stellen eine Cache-Speicherhierarchie innerhalb des Prozessors 1500 dar. Die Cachespeicherhierarchie kann mindestens ein Level eines Anweisungs- und Datencaches innerhalb jedes Prozessorkerns und ein oder mehrere Levels eines geteilten Mid-Level-Caches, wie etwa ein Level 2 (L2), Level 3 (L3), Level 4 (L4) oder andere Levels des Caches umfassen, wobei der höchste Level des Caches vor dem externen Speicher als LLC klassifiziert ist. In einigen Ausführungsformen hält die Cache-Kohärenzlogik die Kohärenz zwischen den verschiedenen Cache-Einheiten 1506 und 1504A bis 1504N aufrecht.
  • Der Prozessor 1500 kann auch einen Satz von einer oder mehreren Bus-Controller-Einheiten 1516 und einen Systemagentenkern 1510 umfassen. Die eine oder die mehreren Buscontrollereinheiten 1516 verwalten einen Satz peripherer Busse, wie etwa einen oder mehrere PCI- oder PCI-Expressbusse. Der Systemagentenkern 1510 stellt Managementfunktionen für die verschiedenen Prozessorkomponenten bereit. Der Systemagentenkern 1510 kann einen oder mehrere integrierte Speicher-Controller 1514 umfassen, um den Zugriff auf verschiedene externe Speichervorrichtungen (nicht dargestellt) zu verwalten.
  • Beispielsweise können einer oder mehrere der Prozessorkerne 1502A bis 1502N Unterstützung für gleichzeitiges Multi-Threading bieten. Der Systemagentenkern 1510 umfasst Komponenten zur Koordination und zum Betrieb der Kerne 1502A bis 1502N während der Multithreading-Verarbeitung. Der Systemagentenkern 1510 kann zusätzlich eine Leistungssteuerungseinheit (PCU) umfassen, die Logik und Komponenten zur Regelung des Leistungszustands der Prozessorkerne 1502A bis 1502N und des Grafikprozessors 1508 umfasst.
  • Der Prozessor 1500 kann zusätzlich einen Grafikprozessor 1508 zur Ausführung von Grafikverarbeitungsoperationen umfassen. In einigen dieser Ausführungsformen koppelt der Grafikprozessor 1508 mit dem Satz gemeinsam genutzter Cache-Einheiten 1506 und dem Systemagentenkern 1510, unter anderem des einen oder mehrerer integrierter Speicher-Controller 1514. Der Systemagentenkern 1510 kann auch einen Anzeige-Controller 1511 umfassen, um die Ausgabe des Grafikprozessors an ein oder mehrere gekoppelte Anzeigen zu steuern. Der Anzeige-Controller 1511 kann auch ein separates Modul sein, das über mindestens ein Interconnect mit dem Grafikprozessor gekoppelt ist, oder er kann in den Grafikprozessor 1508 integriert sein.
  • Zur Kopplung der internen Komponenten des Prozessors 1500 kann eine ringbasierte Verbindungseinheit 1512 verwendet werden. Eine alternative Verbindungseinheit kann jedoch verwendet werden, wie etwa eine Punkt-zu-Punkt-Verbindung, eine geschaltete Verbindung oder andere Techniken, unter anderem Techniken, die auf dem Stand der Technik bekannt sind. In einigen dieser Ausführungsformen mit einem ringbasierten Interconnect 1512 koppelt der Grafikprozessor 1508 über eine E/A-Verbindung 1513 mit dem ringbasierten Interconnect 1512.
  • Die beispielhafte E/A-Verbindung 1513 stellt mindestens eine der mehreren Variationen der E/A-Verbindungen dar, unter anderem einer E/A-Verbindung auf dem Package, die die Kommunikation zwischen verschiedenen Prozessorbestandteilen und einem eingebetteten Hochleistungsspeichermodul 1518, wie etwa einem eDRAM-Modul, ermöglicht. Optional kann jeder der Prozessorkerne 1502A bis 1502N und der Grafikprozessor 1508 eingebettete Speichermodule 1518 als gemeinsamen Last-Level-Cache verwenden.
  • Die Prozessorkerne 1502A bis 1502N können z. B. homogene Kerne sein, die dieselbe Anweisungssatzarchitektur ausführen. Alternativ sind die Prozessorkerne 1502A bis 1502N heterogen in Bezug auf die Anweisungssatzarchitektur (ISA), wobei einer oder mehrere der Prozessorkerne 1502A bis 1502N einen ersten Anweisungssatz ausführen, während mindestens einer der anderen Kerne eine Teilmenge des ersten Anweisungssatzes oder einen anderen Anweisungssatz ausführt. Die Prozessorkerne 1502A bis 1502N können in Bezug auf die Mikroarchitektur heterogen sein, wobei ein oder mehrere Kerne mit einer relativ höheren Leistungsaufnahme mit einem oder mehreren Kernen mit einer geringeren Leistungsaufnahme gekoppelt sind. Als weiteres Beispiel sind die Prozessorkerne 1502A bis 1502N in Bezug auf die Rechenleistung heterogen. Weiterhin kann der Prozessor 1500 auf einem oder mehreren Chips oder als SoC-integrierte Schaltung umgesetzt werden, der neben anderen Bestandteilen die illustrierten Bestandteile aufweist.
  • 15B ist ein Blockdiagramm der Hardware-Logik eines Grafikprozessorkerns 1519, nach einigen hierin beschriebenen Ausführungsformen. Der Grafikprozessorkern 1519, manchmal bezeichnet als eine Kernscheibe, kann ein oder mehrere Grafikkerne innerhalb eines modularen Grafikprozessors sein. Der Grafikprozessorkern 1519 ist ein Beispiel für eine Grafikkernscheibe, und ein hierin beschriebener Grafikprozessor kann mehrere Grafikkernscheiben basierend auf Zielenergie- und Leistungshüllen umfassen. Jeder Grafikprozessorkern 1519 kann einen festen Funktionsblock 1530 umfassen, der mit mehreren Subkernen 1521A bis 1521F gekoppelt ist, die auch als Sub-Slices bezeichnet werden und modulare Blöcke aus Allzweck- und fester Funktionslogik umfassen.
  • Der Festfunktionsblock 1530 kann eine Geometrie-/Festfunktionspipeline 1531 umfassen, die von allen Subkernen im Grafikprozessorkern 1519 gemeinsam genutzt werden kann, z. B. in Grafikprozessorumsetzungen mit geringerer Leistung und/oder geringerem Stromverbrauch. Die Geometrie-/Festfunktionspipeline 1531 kann eine 3D-Festfunktionspipeline (z. B. 3D-Pipeline 1612 wie in 16A nachfolgend beschrieben), eine Video-Frontend-Einheit, einen Thread-Spawner und Thread-Dispatcher sowie einen Manager für den einheitlichen Rückgabepuffer, der einheitliche Rückgabepuffer verwaltet (z. B. einheitlicher Rückgabepuffer 1718 in 17, wie nachfolgend beschrieben), umfassen.
  • Der feste Funktionsblock 1530 kann auch eine Grafik-SoC-Schnittstelle 1532, einen Grafikmikrocontroller 1533 und eine Medienpipeline 1534 umfassen. Die Grafik-SoC-Schnittstelle 1532 bietet eine Schnittstelle zwischen dem Grafikprozessorkern 1519 und anderen Prozessorkernen innerhalb einer integrierten System-on-Chip-Schaltung. Der Grafikmikrocontroller 1533 ist ein programmierbarer Subprozessor, der so konfiguriert sein kann, dass er verschiedene Funktionen des Grafikprozessorkerns 1519 verwaltet, unter anderem Thread-Dispatching, Planung und Vorhersage. Die Medienpipeline 1534 (z. B. die Medienpipeline 1616 aus 16A und 17) umfasst eine Logik zur Erleichterung der decodierung, Kodierung, Vorverarbeitung und/oder Nachbearbeitung von Multimediadaten, unter anderem Bild- und Videodaten. Die Medienpipeline 1534 umgesetzt Medienoperationen über Anforderungen an die Rechen- oder Abtastlogik innerhalb der Subkerne 1521 bis 1521F.
  • Die SoC-Schnittstelle 1532 kann es dem Grafikprozessorkern 1519 ermöglichen, mit Allzweck-Anwendungsprozessorkernen (z. B. CPUs) und/oder anderen Komponenten innerhalb eines SoCs zu kommunizieren, unter anderem Speicherhierarchieelementen wie einem gemeinsamen Cache-Speicher der letzten Ebene, dem System-RAM und/oder eingebettetem On-Chip- oder On-Package-DRAM. Die SoC-Schnittstelle 1532 kann auch die Kommunikation mit Vorrichtungen mit fester Funktion innerhalb des SoCs ermöglichen, wie z. B. Kamera-Bildgebungspipelines, und ermöglicht die Verwendung von und/oder umgesetzt globale Speicher-Atome, die zwischen dem Grafikprozessorkern 1519 und CPUs innerhalb des SoCs gemeinsam genutzt werden können. Die SoC-Schnittstelle 1532 kann auch Energieverwaltungssteuerungen für den Grafikprozessorkern 1519 umsetzen und eine Schnittstelle zwischen einer Taktdomäne des Grafikkerns 1519 und anderen Taktdomänen innerhalb des SoCs ermöglichen. Optional ermöglicht die SoC-Schnittstelle 1532 den Empfang von Befehlspuffern von einem Befehlsstreamer und einem globalen Thread-Dispatcher, die so konfiguriert sind, dass sie Befehle und Anweisungen für jeden von einem oder mehreren Grafikkernen innerhalb eines Grafikprozessors bereitstellen. Die Befehle und Anweisungen können an die Medienpipeline 1534 gesendet werden, wenn Medienoperationen ausgeführt werden sollen, oder an eine Geometrie- und Festfunktionspipeline (z. B. Geometrie- und Festfunktionspipeline 1531, Geometrie- und Festfunktionspipeline 1537), wenn Grafikverarbeitungsoperationen ausgeführt werden sollen.
  • Der Grafikmikrocontroller 1533 kann so konfiguriert sein, dass er verschiedene Planungs- und Verwaltungsaufgaben für den Grafikprozessorkern 1519 ausführt. In einer Konfiguration kann der Grafikmikrocontroller 1533 z. B. die Grafik- und/oder Rechenlastplanung auf den verschiedenen parallelen Grafik-Engines innerhalb der Arrays 1522A bis 1522F, 1524A bis 1524F der Ausführungseinheiten (EU) innerhalb der Subkerne 1521A bis 1521F ausführen. Bei dieser Workloadplanung kann HostSoftware, die auf einem CPU-Kern eines SoCs mit dem Grafikprozessorkern 1519 ausgeführt wird, Workloads an eine von mehreren Grafikprozessor-Türglocken übermitteln, die einen Planungsvorgang auf der entsprechenden Grafik-Engine aufruft. Planungsoperationen umfassen das Bestimmen, welche Workload als nächstes laufen soll, das Übermitteln einer Workload an einen Befehls-Streamer, das Vorhersagen bestehender Workloads, die auf einem Engine laufen, das Überwachen des Fortschritts einer Workload und das Informieren der Hostsoftware, wenn eine Workload abgeschlossen ist. Optional kann der Grafikmikrocontroller 1533 auch stromsparende oder Leerlaufzustände für den Grafikprozessorkern 1519 ermöglichen, indem er dem Grafikprozessorkern 1519 die Möglichkeit gibt, Register innerhalb des Grafikprozessorkerns 1519 über stromsparende Zustandsübergänge unabhängig vom Betriebssystem und/oder der Grafiktreibersoftware auf dem System zu speichern und wiederherzustellen.
  • Der Grafikprozessorkern 1519 kann mehr oder weniger als die illustrierten Subkerne 1521A bis 1521F haben, bis zu N modulare Subkerne. Für jeden Satz von N Subkerne kann der Grafikprozessorkern 1519 auch eine gemeinsam genutzte Funktionslogik 1535, einen gemeinsam genutzten und/oder Cache-Speicher 1536, eine Geometrie-/Festfunktions-Pipeline 1537 sowie eine zusätzliche Festfunktionslogik 1538 zur Beschleunigung verschiedener Grafik- und Rechenverarbeitungsvorgänge umfassen. Die gemeinsam genutzte Funktionslogik 1535 kann Logikeinheiten umfassen, die mit der gemeinsam genutzten Funktionslogik 1720 aus 17 (z. B. Sampler, Mathematik und/oder Inter-Thread-Kommunikationslogik), die von allen N Subkerne innerhalb des Grafikprozessorkerns 1519 gemeinsam genutzt werden können. Der gemeinsame und/oder Cache-Speicher 1536 kann ein Cache der letzten Ebene für den Satz von N Subkerne 1521A bis 1521F innerhalb des Grafikprozessorkerns 1519 sein und kann auch als gemeinsam genutzter Speicher dienen, auf den mehrere Subkerne zugreifen können. Die Geometrie-/Festfunktionspipeline 1537 kann statt der Geometrie-/Festfunktionspipeline 1531 in dem Festfunktionsblock 1530 umfasst sein und dieselben oder ähnliche Logikeinheiten umfassen.
  • Der Grafikprozessorkern 1519 kann zusätzliche feste Funktionslogik 1538 umfassen, die verschiedene feste Funktionsbeschleunigungslogik zur Verwendung durch den Grafikprozessorkern 1519 umfassen kann. Optional umfasst die zusätzliche feste Funktionslogik 1538 eine zusätzliche Geometrie-Pipeline zur Verwendung in der positionsabhängigen Schattierung. Im reinen Positions-Shading gibt es zwei Geometriepipelines, die volle Geometriepipeline innerhalb der Geometrie-/Festfunktionspipeline 1538, 1531, und eine Cull-Pipeline, die eine weitere Geometriepipeline ist, die in der weiteren Festfunktionslogik 1538 umfasst sein kann. Die Cull-Pipeline kann zum Beispiel eine abgespeckte Version der vollständigen Geometrie-Pipeline sein. Die volle Pipeline und die Cull-Pipeline können verschiedene Instanzen derselben Anwendung ausführen, wobei jede Instanz einen anderen Kontext aufweist. Reines Positions-Shading kann lange Cull-Läufe verworfener Dreiecke verbergen, sodass das Shading in einigen Fällen schneller abgeschlossen werden kann. Beispielsweise kann die Cull-Pipeline-Logik innerhalb der zusätzlichen festen Funktionslogik 1538 Positions-Shader parallel zur Hauptanwendung ausführen und erzeugt im Allgemeinen kritische Ergebnisse schneller als die vollständige Pipeline, da die Cull-Pipeline nur das Positionsattribut der Vertizes abruft und schattiert, ohne eine Rasterung und ein Rendering der Pixel in den Framepuffer auszuführen. Die Cull-Pipeline kann die erzeugten kritischen Ergebnisse verwenden, um Sichtbarkeitsinformationen für alle Dreiecke ohne Beachtung davon, ob die Dreiecke entfernt werden, zu berechnen. Die volle Pipeline (die in diesem Fall als Replay-Pipeline bezeichnet werden kann) kann die Sichtbarkeitsinformationen verwenden, um die entfernten Dreiecke zu überspringen und nur die sichtbaren Dreiecke zu schattieren, die schließlich an die Rasterisierungsphase übergeben werden.
  • Optional kann die zusätzliche feste Funktionslogik 1538 auch eine Logik zur Beschleunigung des Maschinenlernens umfassen, wie z. B. eine Logik zur Matrixmultiplikation mit fester Funktion, für Umsetzungen, die Optimierungen für das Training oder die Inferenzierung des Maschinenlernens beinhalten.
  • In jedem Grafik-Subkern 1521A bis 1521F ist ein Satz von Ausführungsressourcen umfassen, die zur Ausführung von Grafik-, Medien- und Rechenoperationen als Reaktion auf Anforderungen von Grafik-Pipeline-, Medienpipeline- oder Shader-Programmen verwendet werden können. Die Grafiksubkerne 1521A bis 1521F umfassen mehrere EU-Arrays 1522A bis 1522F, 1524A bis 1524F, Thread-Dispatch- und Inter-Thread-Kommunikationslogik (TD/IC) 1523A bis 1523F, einen 3D-Sampler (z. B. Textur) 1525A bis 1525F, einen Media-Sampler 1526A bis 1526F, einen Shader-Prozessor 1527A bis 1527F und einen gemeinsamen lokalen Speicher (SLM) 1528A bis 1528F. Die EU-Arrays 1522A bis 1522F, 1524A bis 1524F umfassen jeweils mehrere Ausführungseinheiten, bei denen es sich um Allzweck-Grafikprozessoreinheiten handelt, die in der Lage sind, Gleitkomma- und Ganzzahl-/Festkomma-Logikoperationen im Dienste einer Grafik-, Medien- oder Rechenoperation auszuführen, unter anderem Grafik-, Medien- oder Rechenshaderprogrammen. Die TD/IC-Logik 1523A bis 1523F führt lokale Thread-Versand- und Thread-Steuerungsoperationen für die Ausführungseinheiten innerhalb eines Subkerns durch und erleichtert die Kommunikation zwischen Threads, die auf den Ausführungseinheiten des Subkerns ausgeführt werden. Der 3D-Sampler 1525A bis 1525F kann Texturen oder andere 3D-Grafikdaten in den Speicher einlesen. Der 3D-Sampler kann Texturdaten auf Grundlage eines konfigurierten Samplingzustands und des Texturformats lesen, das mit einer bestimmten Textur assoziiert ist. Der Medienabtaster 1506A bis 1506F kann ähnliche Lesevorgänge basierend auf dem Typ und dem Format der Mediendaten ausführen. Beispielsweise kann jeder Grafik-Subkern 1521A bis 1521F abwechselnd einen einheitlichen 3D- und Medien-Sampler umfassen. Threads, die auf den Ausführungseinheiten in jedem der Subkerne 1521A bis 1521F ausgeführt werden, können den gemeinsamen lokalen Speicher 1528A bis 1528F in jedem Subkern nutzen, damit Threads, die innerhalb einer Thread-Gruppe ausgeführt werden, einen gemeinsamen Pool von On-Chip-Speicher nutzen können.
  • 15C ist ein Blockdiagramm der Allzweck-Grafikprozessoreinheit (GPGPU) 1570, die als Grafikprozessor, z. B. der Grafikprozessor 1508, und/oder als Rechenbeschleuniger den hierin beschriebenen Ausführungsformen entsprechend konfiguriert sein kann. Die GPGPU 1570 kann über einen oder mehrere System- und/oder Speicherbusse mit den Host-Prozessoren (z. B. einer oder mehreren CPU(s) 1546) und dem Speicher 1571, 1572 verbunden sein. Der Speicher 1571 kann ein Systemspeicher sein, der gemeinsam mit der/den CPU(s) 1546 genutzt werden kann, während der Speicher 1572 ein Gerätespeicher ist, der für die GPGPU 1570 bestimmt ist. Beispielsweise können Komponenten innerhalb der GPGPU 1570 und des Gerätespeichers 1572 in Speicheradressen abgebildet werden, die für die eine oder mehrere CPU(s) 1546 zugänglich sind. Der Zugriff auf die Speicher 1571 und 1572 kann über einen Speicher-Controller 1568 erfolgen. Der Speicher-Controller 1568 kann einen internen Direktspeicherzugriffs-Controller (DMA) 1569 umfassen oder eine Logik zur Ausführung von Operationen, die sonst von einem DMA-Controller ausgeführt werden würden.
  • Die GPGPU 1570 umfasst mehrere Cache-Speicher, darunter einen L2-Cache 1553, einen LI-Cache 1554, einen Befehls-Cache 1555 und einen gemeinsam genutzten Speicher 1556, von dem zumindest ein Abschnitt auch als Cache-Speicher partitioniert sein kann. Die GPGPU 1570 umfasst auch mehrere Rechnereinheiten 1560A bis 1560N. Jede Rechnereinheit 1560A bis 1560N umfasst einen Satz von Vektorregistern 1561, Skalarregistern 1562, Vektorlogikeinheiten 1563 und Skalarlogikeinheiten 1564. Die Rechnereinheiten 1560A bis 1560N können auch einen lokalen gemeinsamen Speicher 1565 und einen Programmzähler 1566 umfassen. Die Rechnereinheiten 1560A bis 1560N können mit einem Konstant-Cache 1567 gekoppelt werden, der zum Speichern von konstanten Daten verwendet werden kann, d. h. von Daten, die sich während der Ausführung des Kernel- oder Shader-Programms, das auf der GPGPU 1570 ausgeführt wird, nicht ändern. Der Konstant-Cache 1567 kann ein skalarer Daten-Cache sein und zwischengespeicherte Daten können direkt in die skalaren Register 1562 geholt werden.
  • Im Betrieb können die eine oder mehrere CPU(s) 1546 Befehle in Register oder Speicher in der GPGPU 1570 schreiben, die in einen zugänglichen Adressraum eingeblendet wurden. Die Befehlsprozessoren 1557 können die Befehle aus Registern oder dem Speicher lesen und bestimmen, wie diese Befehle innerhalb der GPGPU 1570 verarbeitet werden. Ein Thread-Dispatcher 1558 kann dann verwendet werden, um Threads an die Rechnereinheiten 1560A bis 1560N zur Ausführung dieser Befehle zu senden. Jede Rechnereinheit 1560A bis 1560N kann unabhängig von den anderen Rechnereinheiten Threads ausführen. Zusätzlich kann jede Rechnereinheit 1560A bis 1560N unabhängig für bedingte Berechnungen konfiguriert sein und die Ergebnisse der Berechnung bedingt an den Speicher ausgeben. Die Befehlsprozessoren 1557 können die eine oder mehrere CPU(s) 1546 unterbrechen, wenn die übermittelten Befehle abgeschlossen sind.
  • 16A bis 16C illustrieren Blockdiagramme von zusätzlichen Grafikprozessor- und Rechenbeschleuniger-Architekturen, die durch hier beschriebene Ausführungsformen bereitgestellt werden, z. B. nach 15A bis 15C. Die Elemente aus 16A bis 16C mit gleichen oder ähnlichen Namen wie die Elemente einer anderen Figur hierin beschreiben die gleichen Elemente wie in den anderen Figuren, können in ähnlicher Weise arbeiten oder funktionieren, können die gleichen Komponenten umfassen und können mit anderen Einheiten verbunden sein, wie die, die an anderer Stelle hierin beschrieben sind, sind aber nicht auf solche beschränkt.
  • 16A ist ein Blockdiagramm eines Grafikprozessors 1600, bei dem es sich um eine diskrete Grafikprozessoreinheit oder um einen Grafikprozessor handeln kann, der in mehrere Verarbeitungskernen oder andere Halbleitervorrichtungen integriert ist, wie z. B. Speichervorrichtungen oder Netzwerkschnittstellen, aber nicht darauf beschränkt. Der Grafikprozessor 1600 kann eine Variante des Grafikprozessors 1508 sein und kann anstelle des Grafikprozessors 1508 verwendet werden. Daher offenbart die Offenbarung beliebiger Merkmale in Kombination mit dem Grafikprozessor 1508 hier auch eine entsprechende Kombination mit dem/den Grafikprozessor 1600, ist aber nicht auf diese beschränkt. Der Grafikprozessor kann über eine speicherabgebildete E/A-Schnittstelle mit Registern auf dem Grafikprozessor und mit im Prozessorspeicher abgelegten Befehlen kommunizieren. Der Grafikprozessor 1600 kann eine Speicherschnittstelle 1614 für den Zugriff auf den Speicher umfassen. Die Speicherschnittstelle 1614 kann eine Schnittstelle mit einem örtlichen Speicher, einem oder mehreren internen Caches, einem oder mehreren geteilten externen Caches und/oder dem Systemspeicher sein.
  • Optional umfasst der Grafikprozessor 1600 auch einen Anzeige-Controller 1602 zur Ansteuerung von Anzeige-Ausgabedaten an eine Anzeigevorrichtung 1618. Der Anzeige-Controller 1602 umfasst Hardware für eine oder mehrere Überlagerungsebenen zur Anzeige und Zusammensetzung mehrerer Ebenen 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 montierte Anzeigevorrichtung, wie etwa eine Virtual-Reality-Anzeigevorrichtung (VR-Anzeigevorrichtung) oder eine Augmented-Reality-Anzeigevorrichtung (AR-Anzeigevorrichtung). Der Grafikprozessor 1600 kann eine Videocodec-Engine 1606 zum Codieren, Decodieren oder Transcodieren von Medien in, aus oder zwischen einem oder mehreren Mediencodierformaten umfassen, unter anderem, aber nicht beschränkt auf Moving Picture Experts Group-Formate (MPEG-Formate) wie MPEG-2, Advanced Video Coding-Formate (AVC-Formate) wie H.264/MPEG-4 AVC, H.265/HEVC, Alliance for Open Media (AOMedia) VP8, VP9, sowie Society of Motion Picture & Television Engineers (SMPTE) 421M/VC-1 und Joint Photographic Experts Group-Formate (JPEG-Formate) wie JPEG- und Motion-JPEG-Formate (MJPEG-Formate).
  • Der Grafikprozessor 1600 kann eine Block-Image-Transfer-Engine (BLIT-Engine) 1603 umfassen, um zweidimensionale (2D) Rasterisierungsoperationen auszuführen, wie etwa Bit-Boundary Block Transfers. Alternativ können 2D-Grafikoperationen jedoch auch mit einer oder mehreren Komponenten der Grafikverarbeitungsengine (GPE) 1610 ausgeführt werden. In einigen Ausführungsformen ist die GPE 1610 eine Berechnungsengine zur Ausführung von Grafikoperationen, die dreidimensionale Grafikoperationen (3D-Grafikoperationen) und Medienoperationen umfassen.
  • GPE 1610 kann eine 3D-Pipeline 1612 zur Ausführung von 3D-Operationen umfassen, wie z. B. das Rendern dreidimensionaler Bilder und Szenen unter Verwendung von Verarbeitungsfunktionen, die auf 3D-Primitivformen (z. B. Rechteck, Dreieck usw.) wirken. Die 3D-Pipeline 1612 umfasst programmierbare und feste Funktionselemente, die verschiedene Aufgaben innerhalb des Elements ausführen und/oder AusführungsThreads an ein 3D/Media-Subsystem 1615 weiterleiten. Während die 3D-Pipeline 1612 zur Ausführung von Medienoperationen verwendet werden kann, umfasst eine Ausführungsform von GPE 1610 auch eine Medienpipeline 1616, die speziell zur Ausführung von Medienoperationen, wie z. B. Videonachbearbeitung und Bildverbesserung, verwendet wird.
  • Die Medienpipeline 1616 kann feste Funktions- oder programmierbare Logikeinheiten umfassen, um eine oder mehrere spezialisierte Medienoperationen auszuführen, wie z. B. Videodecodierbeschleunigung, Videoentflechtung und Videocodierbeschleunigung anstelle von oder im Auftrag der Videocodec-Engine 1606. Die Medienpipeline 1616 kann zusätzlich eine Thread-Spawning-Einheit umfassen, um Threads zur Ausführung im 3D/Media-Subsystem 1615 zu erzeugen. Die gespawnten Threads führen Berechnungen für die Medienoperationen auf einer oder mehreren Grafikausführungseinheiten durch, die im 3D/Media-Subsystem 1615 umfasst sind.
  • Das 3D/Media-Subsystem 1615 kann Logik zur Ausführung von Threads umfassen, die von der 3D-Pipeline 1612 und der Media-Pipeline 1616 erzeugt werden. Die Pipelines können Thread-Ausführungsanforderungen an das 3D/Media-Subsystem 1615 senden, das eine Thread-Dispatch-Logik für die Arbitrierung und Zuteilung der verschiedenen Anforderungen an verfügbare Thread-Ausführungsressourcen umfasst. Die Ausführungsressourcen umfassen ein Array von Grafikausführungseinheiten zur Verarbeitung der 3D- und Medien-Threads. Das 3D/Media-Subsystem 1615 kann einen oder mehrere interne Caches für Thread-Anweisungen und Daten umfassen. Zusätzlich kann das 3D/Media-Subsystem 1615 auch einen gemeinsam genutzten Speicher umfassen, unter anderem Registern und adressierbarem Speicher, um Daten zwischen Threads gemeinsam zu nutzen und um Ausgabedaten zu speichern.
  • 16B illustriert einen Grafikprozessor 1620, der eine Variante des Grafikprozessors 1600 ist und anstelle des Grafikprozessors 1600 verwendet werden kann und umgekehrt. Daher offenbart die Offenbarung beliebiger Merkmale in Kombination mit dem Grafikprozessor 1600 hier auch eine entsprechende Kombination mit dem/den Grafikprozessor 1620, ist aber nicht auf diese beschränkt. Der Grafikprozessor 1620 verfügt über eine Kachelarchitektur, entsprechend den hierin beschriebenen Ausführungsformen. Der Grafikprozessor 1620 kann einen Grafikverarbeitungsengine-Cluster 1622 mit mehreren Instanzen der Grafikverarbeitungsengine 1610 aus 16A innerhalb einer Grafik-Engine-Kachel 1610A bis 1610D umfassen. Jede Grafik-Engine-Kachel 1610A bis 1610D kann über einen Satz von Kachel-Verbindungen 1623A bis 1623F miteinander verbunden werden. Jede Grafik-Engine-Kachel 1610A bis 1610D kann auch mit einem Speichermodul oder einer Speichervorrichtung 1626A bis 1626D über Speicherverbindungen 1625A bis 1625D verbunden werden. Die Speichervorrichtungen 1626A bis 1626D können eine beliebige Grafikspeichertechnologie verwenden. Bei den Speichervorrichtungen 1626A bis 1626D kann es sich zum Beispiel um Grafikspeicher mit doppelter Datenrate (GDDR) handeln. Bei den Speichervorrichtungen 1626A bis 1626D kann es sich um HBM-Module (High-Bandwidth Memory) handeln, die mit der jeweiligen Grafik-Engine-Kachel 1610A bis 1610D auf dem Chip liegen können. Bei den Speichervorrichtungen 1626A bis 1626D kann es sich um Stapelspeichervorrichtungen handeln, die auf ihre jeweilige Grafik-Engine-Kachel 1610A bis 1610D gestapelt werden können. Jede Grafik-Engine-Kachel 1610A bis 1610D und der zugehörige Speicher 1626A bis 1626D können sich auf separaten Chipletts befinden, die mit einem Basis-Die oder Basissubstrat verbunden sind, wie in 24B bis 24D genauer beschrieben.
  • Der Grafikprozessor 1620 kann mit einem Non-Uniform-Memory-Access-System (NUMA-System) konfiguriert sein, bei dem die Speichervorrichtungen 1626A bis 1626D mit den zugehörigen Grafik-Engine-Kacheln 1610A bis 1610D gekoppelt sind. Auf eine bestimmte Speichervorrichtung kann von anderen Kacheln der Grafik-Engine zugegriffen werden als von der Kachel, mit der es direkt verbunden ist. Die Zugriffslatenz auf die Speichervorrichtungen 1626A bis 1626D kann jedoch beim Zugriff auf eine lokale Kachel am geringsten sein. In einer Ausführungsform wird ein cachekohärentes NUMA-System (ccNUMA) aktiviert, das die Kachelverbindungen 1623A bis 1623F verwendet, um die Kommunikation zwischen Cache-Controllern innerhalb der Grafik-Engine-Kacheln 1610A bis 1610D zu ermöglichen, um ein konsistentes Speicherabbild zu erhalten, wenn mehr als ein Cache dieselbe Speicherstelle speichert.
  • Der Grafikverarbeitungsengine-Cluster 1622 kann mit einem On-Chip- oder On-Package-Struktur-Interconnect 1624 verbunden werden. In einer Ausführungsform umfasst der Struktur-Interconnect 1624 einen Netzwerkprozessor, ein Network on a Chip (NoC) oder einen anderen Vermittlungsprozessor, damit der Struktur-Interconnect 1624 als paketvermittelter Struktur-Interconnect wirken kann, die Datenpakete zwischen Komponenten des Grafikprozessors 1620 vermittelt. Der Struktur-Interconnect 1624 kann die Kommunikation zwischen den Grafik-Engine-Kacheln 1610A bis 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, in und zwischen den Speichervorrichtungen 1626A bis 1626D und dem Speicher, der sich außerhalb des Grafikprozessors 1620 befindet (z. B. Systemspeicher), zu verschieben. Der Struktur-Interconnect 1624 kann auch zur Verbindung der Grafik-Engine-Kacheln 1610A bis 1610D verwendet werden. Der Grafikprozessor 1620 kann optional einen Anzeige-Controller 1602 umfassen, 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 der Anzeige-Controller 1602 und die Anzeigevorrichtung 1618 weggelassen werden.
  • Der Grafikprozessor 1620 kann über eine Host-Schnittstelle 1628 mit einem Host-System verbunden werden. Die Host-Schnittstelle 1628 kann die Kommunikation zwischen dem Grafikprozessor 1620, dem Systemspeicher und/oder anderen Systemkomponenten ermöglichen. Die Host-Schnittstelle 1628 kann z. B. ein PCI-Express-Bus oder eine andere Art von Host-System-Schnittstelle sein. Die Host-Schnittstelle 1628 kann zum Beispiel eine NVLink- oder NVSwitch-Schnittstelle sein. Die Host-Schnittstelle 1628 und der Struktur-Interconnect 1624 können zusammenarbeiten, damit mehrere Instanzen des Grafikprozessors 1620 als einzelne logische Vorrichtung agieren können. Die Zusammenarbeit zwischen der Host-Schnittstelle 1628 und dem Struktur-Interconnect 1624 kann auch dazu führen, dass die einzelnen Grafik-Engine-Kacheln 1610A bis 1610D dem Host-System als unterschiedliche logische Grafikvorrichtungen präsentiert werden.
  • 16C illustriert einen Rechenbeschleuniger 1630 den hierin beschriebenen Ausführungsformen entsprechend. Der Rechenbeschleuniger 1630 kann architektonische Ähnlichkeiten mit dem Grafikprozessor 1620 aus 16B und ist für die Rechenbeschleunigung optimiert. Ein Rechner-Engine-Cluster 1632 kann einen Satz von Rechner-Engine-Kacheln 1640A bis 1640D umfassen, die eine Ausführungslogik umfassen, die für parallele oder vektorbasierte Allzweck-Rechenoperationen optimiert ist. Die Rechner-Engine-Kacheln 1640A bis 1640D umfassen möglicherweise keine Grafikverarbeitungslogik mit fester Funktion, obwohl in einigen Ausführungsformen eine oder mehrere der Rechner-Engine-Kacheln 1640A bis 1640D Logik zur Ausführung der Medienbeschleunigung umfassen können. Die Rechner-Engine-Kacheln 1640A bis 1640D können über Speicherverbindungen 1625A bis 1625D mit dem Speicher 1626A bis 1626D verbunden werden. Der Speicher 1626A bis 1626D und die Speicherverbindungen 1625A bis 1625D können in ähnlicher Technologie wie im Grafikprozessor 1620 ausgeführt sein, können aber auch anders sein. Die Kacheln 1640A bis 1640D der Grafikberechnungsengine können auch über einen Satz von KachelVerbindungen 1623A bis 1623F miteinander verbunden sein und können mit einer Strukturverbindung 1624 verbunden und/oder durch diese miteinander verbunden werden. In einer Ausführungsform umfasst der Rechenbeschleuniger 1630 einen großen L3-Cache 1636, der als vorrichtungenweiter Cache konfiguriert sein kann. Der Rechenbeschleuniger 1630 kann auch über eine Host-Schnittstelle 1628 mit einem Host-Prozessor und -Speicher in ähnlicher Weise verbunden werden wie der Grafikprozessor 1620 aus 16B.
  • Der Rechenbeschleuniger 1630 kann auch eine integrierte Netzwerkschnittstelle 1642 umfassen. In einer Ausführungsform umfasst die Netzwerkschnittstelle 1642 einen Netzwerkprozessor und eine Steuerungslogik, die es dem Rechner-Engine-Cluster 1632 ermöglicht, über eine physikalische Verbindungsschicht 1644 zu kommunizieren, ohne dass Daten den Speicher eines Host-Systems durchlaufen müssen. In einer Ausführungsform wird eine der Rechner-Engine-Kacheln 1640A bis 1640D durch Netzwerkprozessorlogik ersetzt und Daten, die über die Physical-Layer-Verbindung 1644 übertragen oder empfangen werden sollen, können direkt zum oder vom Speicher 1626A bis 1626D übertragen werden. Mehrere Instanzen des Rechenbeschleunigers 1630 können über die Verbindung der physikalischen Schicht 1644 zu einer einzigen logischen Vorrichtung verbunden werden. Alternativ können die verschiedenen Rechner-Engine-Kacheln 1640A bis 1640D als unterschiedliche, über das Netzwerk zugängliche Rechenbeschleunigervorrichtungen illustriert werden.
  • Grafikverarbeitungsengine
  • 17 ist ein Blockdiagramm einer Grafikverarbeitungsengine 1710 eines Grafikprozessors nach einigen Ausführungsformen. Die Grafikverarbeitungsengine (GPE) 1710 kann eine Version der in 16A dargestellten GPE 1610 sein, und sie kann auch eine Grafik-Engine-Kachel 1610A bis 1610D aus 16B darstellen. Die Elemente aus 17 mit gleichen oder ähnlichen Namen wie die Elemente einer anderen Figur hierin beschreiben die gleichen Elemente wie in den anderen Figuren, können in ähnlicher Weise arbeiten oder funktionieren, können die gleichen Komponenten umfassen und können mit anderen Einheiten verbunden sein, wie die, die an anderer Stelle hierin beschrieben sind, sind aber nicht auf solche beschränkt. Beispielsweise sind die 3D-Pipeline 1612 und die Medienpipeline 1616 aus 16A auch in 17 illustriert. Die Medienpipeline 1616 ist in einigen Ausführungsformen der GPE 1710 optional und ist möglicherweise nicht ausdrücklich in der GPE 1710 umfassen. Beispielsweise und in mindestens einer Ausführungsform ist ein separater Medien- und/oder Bildprozessor mit der GPE 1710 verbunden.
  • GPE 1710 kann mit einem Befehlsstreamer 1703 gekoppelt sein oder einen solchen umfassen, der einen Befehlsstrom an die 3D-Pipeline 1612 und/oder die Medienpipelines 1616 liefert. Alternativ oder zusätzlich kann der Befehlsstreamer 1703 direkt mit einem einheitlichen Rückgabepuffer 1718 gekoppelt sein. Der einheitliche Rückgabepuffer 1718 kann kommunikativ mit einem Grafikkern-Array 1714 gekoppelt sein. Optional ist der Befehlsstreamer 1703 mit einem Speicher gekoppelt, bei dem es sich um Systemspeicher oder einen oder mehrere interne Cache-Speicher und gemeinsam genutzte Cache-Speicher handeln kann. Der Befehlsstreamer 1703 kann Befehle aus dem Speicher empfangen und sendet die Befehle an die 3D-Pipeline 1612 und/oder die Medienpipeline 1616. Die Befehle sind Anweisungen, die von einem Ringpuffer abgerufen werden, der Befehle für die 3D-Pipeline 1612 und Medienpipelines 1616 speichert. Der Ringpuffer kann zusätzlich Batch-Befehlspuffer umfassen, die Stapel von mehreren Befehlen speichern. Die Befehle für die 3D-Pipeline 1612 können auch Referenzen auf Daten umfassen, die im Speicher gespeichert sind, unter anderem, aber nicht beschränkt auf Vertex- und Geometriedaten für die 3D-Pipeline 1612 und/oder Bilddaten und Speicherobjekte für die Medienpipeline 1616. Die 3D-Pipeline 1612 und die Medienpipeline 1616 verarbeiten die Befehle und Daten, indem sie Operationen über die Logik innerhalb der jeweiligen Pipelines ausführen oder einen oder mehrere Ausführungsthreads an das Grafikkern-Array 1714 senden. Das Grafikkern-Array 1714 kann einen oder mehrere Blöcke von Grafikkernen umfassen (z. B. Grafikkern(e) 1715A, Grafikkern(e) 1715B), wobei jeder Block einen oder mehrere Grafikkerne umfasst. Jeder Grafikkern umfasst einen Satz von Grafikausführungsressourcen, der Allzweck- und grafikspezifische Ausführungslogik zum Ausführen von Grafik- und Rechenoperationen, sowie feste Funktionstexturverarbeitung und/oder Maschinenlern- und Künstliche-Intelligenz-Beschleunigungslogik umfasst.
  • In verschiedenen Ausführungsformen kann die 3D-Pipeline 1612 feste Funktionen und programmierbare Logik umfassen, um ein oder mehrere Shader-Programme zu verarbeiten, wie z. B. Vertex-Shader, Geometrieshader, Pixel-Shader, Fragment-Shader, Rechner-Shader oder andere Shader-Programme, indem die Anweisungen verarbeitet und Ausführungs-Threads an das Grafikkern-Array 1714 gesendet werden. Das Grafikkernarray 1714 stellt einen einheitlichen Block von Ausführungsressourcen zur Verwendung bei der Verarbeitung dieser Shaderprogramme bereit. Die Mehrzweck-Ausführungslogik (z. B. Ausführungseinheiten) innerhalb des/der Grafikkerns/Grafikkerne 1714A bis 1714B des Grafikkern-Arrays 1714 umfasst Unterstützung für verschiedene 3D-API-Shader-Sprachen und kann mehrere gleichzeitige Ausführungs-Threads ausführen, die mit mehreren Shadern verbunden sind.
  • Das Grafikkern-Array 1714 kann Ausführungslogik zur Ausführung von Medienfunktionen, wie Video- und/oder Bildverarbeitung, umfassen. Die Ausführungseinheiten können eine Allzwecklogik umfassen, die so programmiert werden kann, dass sie zusätzlich zu den Grafikverarbeitungsoperationen parallele Allzweckrechenoperationen ausführt. Die Allzwecklogik kann Verarbeitungsoperationen parallel oder in Verbindung mit der Allzwecklogik innerhalb des/der Prozessorkerns/Prozessorkerne 1407 aus 14 oder Kern 1502A bis 1502N wie in 15A ausführen.
  • Ausgabedaten, die durch Threads erzeugt werden, die auf dem Grafikkernarray 1714 ausgeführt werden, können Daten an den Speicher in einem einheitlichen Rückgabepuffer (URB) 1718 ausgeben. 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 Grafikkern-Array 1714 ausgeführt werden. Der URB 1718 kann zusätzlich für die Synchronisation zwischen Threads auf dem Grafikkern-Array 1714 und der festen Funktionslogik innerhalb der gemeinsamen Funktionslogik 1720 verwendet werden.
  • Optional kann das Grafikkern-Array 1714 skalierbar sein, sodass das Array eine variable Anzahl von Grafikkernen umfasst, die jeweils eine variable Anzahl von Ausführungseinheiten haben, die auf der Zielleistung und dem Leistungsniveau des GPE 1710 basieren. Die Ausführungsressourcen können dynamisch skalierbar sein, sodass Ausführungsressourcen nach Bedarf aktiviert oder deaktiviert werden können.
  • Das Grafikkernarray 1714 koppelt sich mit der geteilten Funktionslogik 1720, die mehrere Ressourcen umfasst, die zwischen den Grafikkernen in dem Grafikkernarray geteilt werden. Die geteilten Funktionen innerhalb der geteilten Funktionslogik 1720 sind Hardwarelogikeinheiten, die spezialisierte ergänzende Funktionen für das Grafikkernarray 1714 bereitstellen. In verschiedenen Ausführungsformen umfasst die geteilte Funktionslogik 1720 eine Sampler- 1721, Mathematik- 1722 und Interthread-Kommunikations-Logik (ITC-Logik) 1723, ist jedoch nicht darauf beschränkt. Zusätzlich können ein oder mehrere Cache(s) 1725 innerhalb der gemeinsamen Funktionslogik 1720 umgesetzt werden.
  • Eine gemeinsam genutzte Funktion wird zumindest in dem Fall umgesetzt, in dem die Nachfrage nach einer bestimmten spezialisierten Funktion nicht ausreicht, um sie in das Grafikkern-Array 1714 aufzunehmen. Stattdessen wird eine einzelne Instanziierung dieser spezialisierten Funktion als eigenständige Entität in der geteilten Funktionslogik 1720 umgesetzt und unter den Ausführungsressourcen innerhalb des Grafikkernarrays 1714 geteilt. Der genaue Satz der Funktionen, die zwischen dem Grafikkernarray 1714 geteilt und in dem Grafikkernarray 1714 eingeschlossen sind, variiert über Ausführungsformen hinweg. Bestimmte gemeinsam genutzte Funktionen innerhalb der gemeinsam genutzten Funktionslogik 1720, die vom Grafikkern-Array 1714 intensiv genutzt werden, können in der gemeinsam genutzten Funktionslogik 1716 innerhalb des Grafikkern-Arrays 1714 umfasst sein. Optional kann die gemeinsam genutzte Funktionslogik 1716 innerhalb des Grafikkern-Arrays 1714 einige oder alle Logiken innerhalb der gemeinsam genutzten Funktionslogik 1720 umfassen. Alle Logikelemente innerhalb der gemeinsamen Funktionslogik 1720 können innerhalb der gemeinsamen Funktionslogik 1716 des Grafikkern-Arrays 1714 dupliziert werden. Alternativ wird die gemeinsam genutzte Funktionslogik 1720 zu Gunsten der gemeinsam genutzten Funktionslogik 1716 innerhalb des Grafikkern-Arrays 1714 ausgeschlossen.
  • Ausführungseinheiten
  • 18A bis 18B illustrieren eine Thread-Ausführungslogik 1800 mit einem Array von Verarbeitungselementen, die in einem Grafikprozessorkern nach hierin beschriebenen Ausführungsformen eingesetzt werden. Die Elemente aus 18A bis 18B mit gleichen oder ähnlichen Namen wie die Elemente einer anderen Figur hierin beschreiben die gleichen Elemente wie in den anderen Figuren, können in ähnlicher Weise arbeiten oder funktionieren, können die gleichen Komponenten umfassen und können mit anderen Einheiten verbunden sein, wie die, die an anderer Stelle hierin beschrieben sind, sind aber nicht auf solche beschränkt. 18A bis 18B zeigt eine Übersicht über die Thread-Ausführungslogik 1800, die repräsentativ für die Hardware-Logik sein kann, die mit jedem Subkern 1521A bis 1521F aus 15B illustriert ist. 18A ist repräsentativ für eine Ausführungseinheit innerhalb eines Allzweck-Grafikprozessors, während 18B ist repräsentativ für eine Ausführungseinheit, die innerhalb eines Rechenbeschleunigers verwendet werden kann.
  • Wie in 18A illustriert ist, kann die Thread-Ausführungslogik 1800 einen Shader-Prozessor 1802, einen Thread-Dispatcher 1804, einen Befehls-Cache 1806, ein skalierbares Ausführungseinheiten-Array mit mehreren Grafikausführungseinheiten 1808A bis 1808N, einen Sampler 1810, einen gemeinsam genutzten lokalen Speicher 1811, einen Daten-Cache 1812 und einen Datenport 1814 umfassen. Optional kann das skalierbare Ausführungseinheiten-Array dynamisch skaliert werden, indem eine oder mehrere Ausführungseinheiten (z. B. eine der Grafikausführungseinheiten 1808A, 1808B, 1808C, 1808D bis 1808N-1 und 1808N) basierend auf den Rechenanforderungen einer Arbeitslast aktiviert oder deaktiviert werden. Die umfassten Komponenten können über eine Verbindungsstruktur miteinander verbunden sein, die mit jeder der Komponenten eine Verbindung herstellt. Die Thread-Ausführungslogik 1800 kann eine oder mehrere Verbindungen zum Speicher, z. B. zum Systemspeicher oder zum Cache-Speicher, über einen oder mehrere der Befehls-Cachespeicher 1806, den Datenport 1814, den Sampler 1810 und die Grafikausführungseinheiten 1808A bis 1808N umfassen. Jede Ausführungseinheit (z. B. 1808A) kann eine eigenständige programmierbare Allzweck-Rechnereinheit sein, die in der Lage ist, mehrere gleichzeitige Hardware-Threads auszuführen und dabei mehrere Datenelemente parallel für jeden Thread zu verarbeiten. In verschiedenen Ausführungsformen ist die Anordnung der Ausführungseinheiten 1808A bis 1808N skalierbar und kann eine beliebige Anzahl einzelner Ausführungseinheiten umfassen.
  • In einigen Ausführungsformen können die Grafikausführungseinheiten 1808A bis 1808N hauptsächlich zur Ausführung von Shader-Programmen verwendet werden. Ein Shaderprozessor 1802 kann die verschiedenen Shaderprogramme verarbeiten und Ausführungsthreads absenden, die mit Shaderprogrammen über einen Threadsender 1804 assoziiert sind. Der Thread-Dispatcher kann Logik umfassen, um Thread-Initiierungsanforderungen von den Grafik- und Medienpipelines zu vermitteln und die angeforderten Threads auf einer oder mehreren Ausführungseinheiten in den Grafikausführungseinheiten 1808A bis 1808N zu instanziieren. Beispielsweise kann eine Geometriepipeline Vertex-, Tessellierungs- oder Geometrieshader zur Verarbeitung an die Threadausführungslogik senden. Optional kann der Thread-Dispatcher 1804 auch Runtime-Thread-Spawning-Anforderungen von den ausführenden Shader-Programmen verarbeiten.
  • In einigen Ausführungsformen können die Grafikausführungseinheiten 1808A bis 1808N einen Anweisungssatz unterstützen, der native Unterstützung für viele Standard-3D-Grafik-Shader-Befehle umfasst, sodass Shader-Programme aus Grafikbibliotheken (z. B. Direct 3D und OpenGL) mit einer minimalen Übersetzung ausgeführt werden. Die Ausführungseinheiten unterstützen Vertex- und Geometrieverarbeitung (z. B. Vertexprogramme, Geometrieprogramme, Vertexshader), Pixelverarbeitung (z. B. Pixelshader, Fragmentshader) und Verarbeitung zu allgemeinen Zwecken (z. B. Berechnungs- und Medienshader). Jede der Grafikausführungseinheiten 1808A bis 1808N ist in der Lage, SIMD (Single Instruction Multiple Data) auszuführen, und der Multi-Thread-Betrieb ermöglicht eine effiziente Ausführungsumgebung angesichts von Speicherzugriffen mit höherer Latenz. Jeder Hardwarethread innerhalb jeder Ausführungseinheit weist eine spezielle Registerdatei mit hoher Bandbreite und assoziiertem unabhängigem Threadzustand auf. Die Ausführung erfolgt durch mehrere Ausgaben pro Takt an Pipelines, die in der Lage sind, Integer-, Einzel- und Doppelpräzisions-Fließkommaoperationen, SIMD-Zweigfähigkeit, logische Operationen, transzendente Operationen und andere verschiedene Operationen auszuführen. Während des Wartens auf Daten aus dem Speicher oder einer der gemeinsam genutzten Funktionen veranlasst die Abhängigkeitslogik innerhalb der Ausführungseinheiten 1808A bis 1808N einen wartenden Thread, zu Schlafen, bis die angeforderten Daten zurückgegeben wurden. Während der wartende Thread schläft, können Hardwareressourcen für die Verarbeitung anderer Threads reserviert werden. Beispielsweise kann eine Ausführungseinheit während einer Verzögerung, die mit einer Vertex-Shader-Operation verbunden ist, Operationen für einen Pixel-Shader, Fragment-Shader oder eine andere Art von Shader-Programm ausführen, unter anderem eines anderen Vertex-Shaders, wie z. B. dem in 21 illustrierten Vertex-Shader 2107. Verschiedene Ausführungsformen können die Ausführung unter Verwendung von Single Instruction Multiple Thread (SIMT) als Alternative zur Verwendung von SIMD oder zusätzlich zur Verwendung von SIMD anwenden. Der Verweis auf einen SIMD-Kern oder eine SIMD-Operation kann auch für SIMT gelten oder für SIMD in Kombination mit SIMT.
  • Jede Ausführungseinheit in den Grafikausführungseinheiten 1808A bis 1808N arbeitet auf Arrays von Datenelementen. Die Anzahl der Datenelemente ist die „Ausführungsgröße“, d. h. die Anzahl der Kanäle für die Anweisung. Ein Ausführungskanal ist eine logische Ausführungseinheit für den Datenelementzugriff, die Maskierung und die Flusssteuerung innerhalb von Anweisungen. Die Anzahl der Kanäle kann unabhängig von der Anzahl der physischen Arithmetic Logic Units (ALUs), Floating-Point Units (FPUs) oder anderer Logikeinheiten (z. B. Tensorkerne, Raytracing-Kerne usw.) eines bestimmten Grafikprozessors sein. Zusätzlich können die Grafikausführungseinheiten 1808A bis 1808N Ganzzahl- und Gleitkommadatentypen unterstützen.
  • Der Ausführungseinheitenanweisungssatz umfasst SIMD-Anweisungen. Die verschiedenen Datenelemente können als gepackter Datentyp in einem Register gespeichert werden und die Ausführungseinheit verarbeitet die verschiedenen Elemente basierend auf der Datengröße der Elemente. Beispielsweise werden bei der Verwendung auf einem 256 Bit breiten Vektor die 256 Bits des Vektors in einem Register gespeichert und die Ausführungseinheit arbeitet auf dem Vektor in Form von vier separaten 184-Bit-gepackten Datenelementen (Quad-Word-Größendatenelementen (QW-Größendatenelementen)), acht separaten 32-Bit-gepackten Datenelementen (Double-Word-Größendatenelementen (DW-Größendatenelementen)), sechzehn separaten 16-Bit-gepackten Datenelementen (Word-Größendatenelementen (W-Größendatenelementen)) oder zweiunddreißig separaten 8-Bit Datenelementen (Byte-Größendatenelementen (B-Größendatenelementen)). Verschiedene Vektorbereiten und Registergrößen sind jedoch möglich.
  • Optional können eine oder mehrere Ausführungseinheiten zu einer verschmolzenen Grafikausführungseinheit 1809A bis 1809N kombiniert werden, die über eine gemeinsame Thread-Steuerlogik (1807A bis 1807N) für die verschmolzenen EUs verfügt. Mehrere EUs können in eine EU-Gruppe verschmolzen werden. Jede EU in der verschmolzenen EU-Gruppe kann konfiguriert sein, einen eigenen SIMD-Hardwarethread auszuführen. Die Anzahl der EUs in einer verschmolzenen EU-Gruppe kann Ausführungsformen entsprechend variieren. Weiterhin können verschiedene SIMD-Breiten pro EU ausgeführt werden, unter anderem unter anderem SIMD8, SIMD 16 und SIMD32. Jede verschmolzene Grafikausführungseinheit 1809A bis 1809N umfasst mindestens zwei Ausführungseinheiten. Beispielsweise umfasst die verschmolzene Ausführungseinheit 1809A eine erste EU 1808A, eine zweite EU 1808B und eine Threadsteuerlogik 1807A, die der ersten EU 1808A und der zweiten EU 1808B gemeinsam ist. Die Thread-Steuerlogik 1807A steuert Threads, die auf der verschmolzenen Grafikausführungseinheit 1809A ausgeführt werden, sodass jede EU innerhalb der verschmolzenen Ausführungseinheiten 1809A bis 1809N unter Verwendung eines gemeinsamen Befehlszeigerregisters ausgeführt werden kann.
  • Ein oder mehrere interne Anweisungscaches (z. B. 1806) sind in der Threadausführungslogik 1800 umfassen, um Threadanweisungen für die Ausführungseinheiten zu cachen. Ein oder mehrere Daten-Caches (z. B. 1812) können in der Thread-Ausführungslogik 1800 umfasst sein, um Thread-Daten während der Thread-Ausführung zu cachen. Threads, die auf der Ausführungslogik 1800 ausgeführt werden, können auch explizit verwaltete Daten im gemeinsamen lokalen Speicher 1811 speichern. Ein Sampler 1810 kann umfasst sein, um Textur-Sampling für 3D-Operationen und Medien-Sampling für Medien-Operationen bereitzustellen. Der Sampler 1810 kann eine spezielle Textur- oder Mediensampling-Funktionalität umfassen, um Textur- oder Mediendaten während des Sampling-Prozesses zu verarbeiten, bevor die gesampelten Daten an eine Ausführungseinheit weitergegeben werden.
  • Während der Ausführung senden die Grafik- und Medienpipelines Threadeinleitungsanfragen an die Threadausführungslogik 1800 über die Thread-Spawning- und Dispatch-Logik. Wenn eine Gruppe geometrischer Objekte verarbeitet und in Pixeldaten rasterisiert wurde, wird die Pixelprozessorlogik (z. B. Pixelshaderlogik, Fragmentshaderlogik usw.) innerhalb des Pixelshaderprozessors 1802 aufgerufen, um ferner Ausgabeinformationen zu berechnen und Ergebnisse auf Ausgabeflächen schreiben zu lassen (z. B. Farbpuffer, Tiefenpuffer, Schablonenpuffer usw.). Ein Pixel-Shader oder Fragment-Shader kann die Werte der verschiedenen Vertexattribute berechnen, die über das rasterisierte Objekt interpoliert werden sollen. Die Pixelprozessorlogik innerhalb des Shader-Prozessors 1802 kann dann ein von der Anwendungsprogrammierschnittstelle (API) bereitgestelltes Pixel- oder Fragment-Shader-Programm ausführen. Zur Ausführung des Shaderprogramme sendet der Shaderprozessor 1802 Threads über den Thread-Dispatcher 1804 an eine Ausführungseinheit (z. B. 1808A). Der Shader-Prozessor 1802 kann die Textur-Sampling-Logik in dem Sampler 1810 verwenden, um auf Texturdaten in den im Speicher abgelegten Textur-Maps zuzugreifen. Arithmetische Operationen auf den Texturdaten und den Eingangsgeometriedaten 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 zur weiteren Verarbeitung auf einer Grafikprozessor-Ausgabepipeline in den Speicher auszugeben. Der Datenport 1814 kann einen oder mehrere Cache-Speicher (z. B. Daten-Cache 1812) umfassen oder mit diesen gekoppelt sein, um Daten für den Speicherzugriff über den Datenport 1814 zu cachen.
  • Optional kann die Ausführungslogik 1800 auch einen Raytracer 1805 umfassen, der eine Raytracing-Beschleunigungsfunktionalität bereitstellen kann. Der Raytracer 1805 kann einen Raytracing-Anweisungssatz unterstützen, der Befehle/Funktionen zur Erzeugung von Strahlen umfasst. Der Anweisungssatz für die Strahlenverfolgung kann dem Anweisungssatz für die Strahlenverfolgung, der von den Strahlenverfolgungskernen 372 in 3C unterstützt wird, ähnlich sein oder sich von ihm unterscheiden.
  • 18B illustriert beispielhaft interne Details einer Ausführungseinheit 1808. Eine Grafikausführungseinheit 1808 kann eine Befehlsabrufeinheit 1837, ein allgemeines Registerdateiarray (GRF) 1824, ein architektonisches Registerdateiarray (ARF) 1826, einen Thread-Arbiter 1822, eine Sendeeinheit 1830, eine Verzweigungseinheit 1832, einen Satz SIMD-Gleitkommaeinheiten (FPUs) 1834 und optional einen Satz dedizierter Ganzzahl-SIMD-ALUs 1835 umfassen. Das GRF 1824 und ARF 1826 umfassen den Satz der allgemeinen Registerdateien und Architekturregisterdateien mit jedem simultanem Hardwarethread, der möglicherweise in der Grafikausführungseinheit 1808 aktiv ist. Der Architekturzustand pro Thread kann im ARF 1826 aufbewahrt werden, während die während der Thread-Ausführung verwendeten Daten im GRF 1824 gespeichert werden. Der Ausführungszustand jedes Threads, unter anderem die Anweisungsanzeiger für jeden Thread, kann in threadspezifischen Registern im ARF 1826 erhalten 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 haben, die zur Designzeit auf der Grundlage einer Zielanzahl von gleichzeitigen Threads und der Anzahl von Registern pro Ausführungseinheit fein abgestimmt werden kann, wobei die Ressourcen der Ausführungseinheit auf die Logik aufgeteilt werden, die zur Ausführung mehrerer gleichzeitiger Threads verwendet wird. Die Anzahl der logischen Threads, die von der Grafikausführungseinheit 1808 ausgeführt werden können, ist nicht auf die Anzahl der Hardware-Threads beschränkt, und jedem Hardware-Thread können mehrere logische Threads zugewiesen werden.
  • Optional kann die Grafikausführungseinheit 1808 mehrere Befehle mitausgeben, die jeweils unterschiedliche Befehle sein können. Der Thread-Arbiter 1822 des Grafikausführungseinheitenthreads 1808 kann die Anweisungen zur Ausführung an eines aus Sendeeinheit 1830, Verzweigungseinheit 1832 oder SIMD-FPU(s) 1834 senden. Jeder Ausführungsthread kann auf 128 Allzweckregister innerhalb des GRF 1824 zugreifen, wobei jedes Register 32 Bytes speichern kann, auf die als ein SIMD 8-Elementvektor von 32-Bitdatenelementen zugegriffen wird. Jeder Thread der Ausführungseinheit kann auf 4 KByte innerhalb des GRF 1824 zugreifen, obwohl Ausführungsformen nicht so beschränkt sind und in anderen Ausführungsformen mehr oder weniger Registerressourcen bereitgestellt werden können. Die Grafikausführungseinheit 1808 kann in sieben Hardware-Threads unterteilt sein, die unabhängig voneinander Rechenoperationen ausführen können, wobei die Anzahl der Threads pro Ausführungseinheit je nach Ausführungsform auch variieren kann, z. B. 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 der GRF 1824 insgesamt 28 KByte speichern. In einer anderen beispielhaften Ausführungsform, in der 16 Threads auf 4 KByte zugreifen können, kann der GRF 1824 insgesamt 64 KByte speichern. Die Anzahl der Threads pro Ausführungseinheit ist jedoch nicht auf diese Beispiele beschränkt und kann mehr oder weniger als die angegebenen Zahlen betragen. Flexible Adressierungsmodi können es erlauben, Register gemeinsam zu adressieren, um effektiv weitere Register aufzubauen oder ausgreifende rechteckige Blockdatenstrukturen darzustellen.
  • Zusätzlich oder alternativ dazu können Speicheroperationen, Sampleroperationen und andere Systemkommunikationen mit längerer Latenzzeit über „Sende“-Befehle abgewickelt werden, die von der Message-Passing-Sendeeinheit 1830 ausgeführt werden. Verzweigungsbefehle können an eine dedizierte Verzweigungseinheit 1832 weitergeleitet werden, um SIMD-Divergenz und eventuelle Konvergenz zu erleichtern.
  • Die Grafikausführungseinheit 1808 kann eine oder mehrere SIMD-Gleitkommaeinheiten (FPU(s)) 1834 umfassen, um Gleitkommaoperationen auszuführen. Die FPU(s) 1834 können auch Ganzzahlberechnungen unterstützen. In einigen Fällen können die FPU(s) 1834 bis zu M Anzahl von 32-Bit-Gleitkommaoperationen (oder Ganzzahloperationen) SIMD ausführen oder bis zu 2M 16-Bit-Ganzzahl- oder 16-Bit-Gleitkomma-Operationen SIMD ausführen. Optional bietet mindestens eine der FPU(s) erweiterte mathematische Fähigkeiten, um transzendentale mathematische Funktionen mit hohem Durchsatz und 184-Bit-Gleitkomma mit doppelter Präzision zu unterstützen. Ein Satz von 8-Bit-Integer-SIMD-ALUs 1835 kann ebenfalls vorhanden sein und kann speziell für die Ausführung von Operationen im Zusammenhang mit Maschinenlernberechnungen optimiert sein.
  • Optional können Arrays aus mehreren Instanzen der Grafikausführungseinheit 1808 in einer Grafik-Subkern-Gruppierung (z. B. einem Sub-Slice) instanziiert werden. Für die Skalierbarkeit können die Produktarchitekten die genaue Anzahl der Ausführungseinheiten pro Subkern-Gruppierung wählen. Die Ausführungseinheit 1808 kann Anweisungen über mehrere Ausführungskanälen ausführen. Außerdem kann jeder Thread, der auf der Grafikausführungseinheit 1808 ausgeführt wird, auf einem anderen Kanal ausgeführt werden.
  • 19 illustriert eine weitere beispielhafte Ausführungseinheit 1900. Die Elemente aus 19 mit gleichen oder ähnlichen Namen wie die Elemente einer anderen Figur hierin beschreiben die gleichen Elemente wie in den anderen Figuren, können in ähnlicher Weise arbeiten oder funktionieren, können die gleichen Komponenten umfassen und können mit anderen Einheiten verbunden sein, wie die, die an anderer Stelle hierin beschrieben sind, sind aber nicht auf solche beschränkt. Die Ausführungseinheit 1900 kann eine rechenoptimierte Ausführungseinheit sein, die z. B. in einer Rechenkachel 1640A bis 1640D wie in 16C, ist aber für sich nicht beschränkt. Die Ausführungseinheit 1900 kann auch in einer Grafik-Engine-Kachel 1610A bis 1610D wie in 16B verwendet werden. Die Ausführungseinheit 1900 kann eine Thread-Steuereinheit 1901, eine Thread-Zustandseinheit 1902, eine Befehlsabruf-/Vorabrufeinheit 1903 und eine Befehlsdecodiereinheit 1904 umfassen. Die Ausführungseinheit 1900 kann zusätzlich eine Registerdatei 1906 umfassen, 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 umfassen. Die Sendeeinheit 1907 und die Verzweigungseinheit 1908 können ähnlich arbeiten wie die Sendeeinheit 1830 und eine Verzweigungseinheit 1832 der Grafikausführungseinheit 1808 aus 18B.
  • Die Ausführungseinheit 1900 kann auch eine Rechnereinheit 1910 umfassen, die mehrere verschiedene Typen von Funktionseinheiten umfasst. Die Rechnereinheit 1910 kann auch eine ALU 1911, ein systolisches Array 1912 und eine Mathematikeinheit 1913 umfassen. Die ALU 1911 umfasst eine Reihe von arithmetischen Logikeinheiten. Die ALU 1911 kann so konfiguriert sein, dass sie 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 ausführt. Die ALU 1911 kann Ganzzahl- und Gleitkomma-Operationen gleichzeitig (z. B. innerhalb desselben Taktzyklus) ausführen.
  • Das systolische Array 1912 umfasst ein W breites und D tiefes Netzwerk von Datenverarbeitungseinheiten, die zur Ausführung von Vektor- oder anderen datenparallelen Operationen in systolischer Weise verwendet werden können. Das systolische Array 1912 kann so konfiguriert sein, dass es verschiedene Matrixoperationen ausführt, wie z. B. Punktprodukt, äußeres Produkt und allgemeine Matrix-Matrix-Multiplikation (GEMM). Das systolische Array 1912 kann sowohl 16-Bit-Gleitkommaoperationen als auch 8-Bit-, 4-Bit-, 2-Bit- und binäre Ganzzahloperationen unterstützen. Das systolische Array 1912 kann so konfiguriert sein, dass es Maschinenlernvorgänge beschleunigt. Das systolische Array 1912 kann mit Unterstützung für bfloat16, (brain floating point) 16-Bit-Gleitkommaformat oder ein Tensor-Float 32-Bit-Gleitkommaformat (TF32) konfiguriert sein, die eine unterschiedliche Anzahl von Mantissen- und Exponentenbits in Bezug auf Institute of Electrical and Electronics Engineers (IEEE) 754-Formate haben. Es können auch FP64-Formate unterstützt werden.
  • In einer Ausführungsform umfasst das systolische Array 1912 Hardware zur Beschleunigung von Operationen mit spärlichen Matrizen. Multiplikationsoperationen für spärliche Regionen der Eingabedaten können ohne Einbußen beim Durchsatz umgangen werden. Die Blocksparsamkeit innerhalb von Eingangsmatrizen kann erkannt werden und Operationen mit bekannten Ausgangswerten können umgangen werden. In einer Ausführungsform umfasst das systolische Array 1912 Hardware, um Operationen auf spärlichen Daten mit einer komprimierten Darstellung zu ermöglichen. Eine komprimierte Darstellung einer Sparse-Matrix speichert Nicht-Null-Werte und Metadaten, die die Position der Nicht-Null-Werte innerhalb der Matrix definieren. Beispielhafte komprimierte Darstellungen umfassen, sind aber nicht beschränkt auf komprimierte Tensordarstellungen wie Compressed Sparse Row (CSR), Compressed Sparse Column (CSC), Compressed Sparse Fiber (CSF) Darstellungen. Die Unterstützung von komprimierten Darstellungen ermöglicht es, Operationen an Eingaben in einem komprimierten Tensorformat auszuführen, ohne dass die komprimierte Darstellung dekomprimiert oder decodiert werden muss. In einer solchen Ausführungsform können Operationen nur an Nicht-Null-Eingangswerten ausgeführt werden und die resultierenden Nicht-Null-Ausgangswerte können in eine Ausgabematrix abgebildet werden. In einigen Ausführungsformen wird auch Hardware-Unterstützung für maschinenspezifische verlustfreie Datenkompressionsformate bereitgestellt, die bei der Übertragung von Daten innerhalb der Hardware oder über Systembusse verwendet werden. Solche Daten können in einem komprimierten Format für spärliche Eingabedaten beibehalten werden, und das systolische Array 1912 kann die Komprimierungs-Metadaten für die komprimierten Daten verwenden, um die Ausführung von Operationen nur auf Nicht-Null-Werten zu ermöglichen, oder um Blöcke mit Null-Dateneingabe für Multiplikationsoperationen zu umgehen.
  • Die Mathematikeinheit 1913 kann so konfiguriert sein, dass sie eine bestimmte Teilmenge von mathematischen Operationen effizienter und stromsparender als die ALU-Einheit 1911 ausführt. Die Mathematikeinheit 1913 kann die mathematische Logik umfassen, die sich in der gemeinsam genutzten Funktionslogik einer Grafikverarbeitungsmaschine befindet, die von anderen beschriebenen Ausführungsformen bereitgestellt wird, wie z. B. die mathematische Logik 1722 der gemeinsam genutzten Funktionslogik 1720 aus 17. Die Mathematikeinheit 1913 kann so konfiguriert sein, dass sie 32-Bit- und 64-Bit-Gleitkommaoperationen ausführt.
  • Die Thread-Steuereinheit 1901 umfasst Logik zur Steuerung der Ausführung von Threads innerhalb der Ausführungseinheit. Die Thread-Steuereinheit 1901 kann eine Thread-Arbitrierungslogik umfassen, um die Ausführung von Threads innerhalb der Ausführungseinheit 1900 zu starten, zu stoppen und vorzeitig zu beenden. Die Thread-Zustandseinheit 1902 kann verwendet werden, um den Thread-Zustand für Threads zu speichern, die zur Ausführung auf der Ausführungseinheit 1900 zugewiesen sind. Die Speicherung des Thread-Zustandes innerhalb der Ausführungseinheit 1900 ermöglicht die schnelle Vorbelegung von Threads, wenn diese blockiert oder untätig werden. Die Befehlsabruf-/Vorabrufeinheit 1903 kann Befehle aus einem Befehlscache der übergeordneten Ausführungslogik abrufen (z. B. Befehlscache 1806 wie in 18A). Die Befehlsabruf-/Vorabruf-Einheit 1903 kann auch Vorabruf-Anforderungen für Befehle ausgeben, die in den Befehls-Cache geladen werden sollen, basierend auf einer Analyse der aktuell ausgeführten Threads. Die Befehlsdecodiereinheit 1904 kann zum decodieren von Befehlen verwendet werden, die von den Rechnereinheiten ausgeführt werden sollen. Die Befehlsdecodiereinheit 1904 kann als Sekundärdecoder verwendet werden, um komplexe Befehle in einzelne Mikrooperationen zu decodieren.
  • Die Ausführungseinheit 1900 umfasst zusätzlich eine Registerdatei 1906, die von Hardware-Threads verwendet werden kann, die auf der Ausführungseinheit 1900 ausgeführt werden. Die Register in der Registerdatei 1906 können auf die Logik verteilt werden, die zur Ausführung mehrerer gleichzeitiger Threads innerhalb der Rechnereinheit 1910 der Ausführungseinheit 1900 verwendet wird. Die Anzahl der logischen Threads, die von der Grafikausführungseinheit 1900 ausgeführt werden können, ist nicht auf die Anzahl der Hardware-Threads beschränkt, und jedem Hardware-Thread können mehrere logische Threads zugewiesen werden. Die Größe der Registerdatei 1906 kann in verschiedenen Ausführungsformen je nach Anzahl der unterstützten Hardware-Threads variieren. Die Registerumbenennung kann verwendet werden, um Hardware-Threads dynamisch Register zuzuweisen.
  • 20 ist ein Blockdiagramm, das die Anweisungsformate 2000 eines Grafikprozessors illustriert. Die Ausführungseinheiten des Grafikprozessors unterstützen einen Anweisungssatz mit Befehlen in mehreren Formaten. Die Kästen mit durchgezogenen Linien illustrieren die Bestandteile, die allgemein in einer Ausführungseinheitenanweisung umfasst sind, während die gestrichelten Linien Bestandteile umfassen, die optional sind oder die nur in einem Untersatz von Anweisungen umfasst sind. In einigen Ausführungsformen handelt es sich bei den beschriebenen und illustrierten Grafikprozessor-Befehlsformaten 2000 um Makrobefehle, d. h. um Befehle, die der Ausführungseinheit zugeführt werden, im Gegensatz zu Mikrooperationen, die sich aus der Befehlsdecodierung ergeben, sobald der Befehl verarbeitet wurde. So kann eine einzelne Anweisung die Hardware veranlassen, mehrere Mikrooperationen auszuführen
  • Die hierin beschriebenen Grafikprozessor-Ausführungseinheiten können nativ Befehle in einem 128-Bit-Befehlsformat 2010 unterstützen. Ein verdichtetes 64-Bit-Anweisungsformat 2030 ist für einige Anweisungen auf Grundlage der gewählten Anweisung, Anweisungsoptionen und Anzahl Operanden verfügbar. Das native 128-Bit-Anweisungsformat 2010 stellt Zugriff auf alle Anweisungsoptionen bereit, während einige Optionen und Operationen auf das 64-Bit-Format 2030 beschränkt sind. Die nativen Anweisungen, die im 64-Bitformat 2030 verfügbar sind, variieren nach Ausführungsform. Die Anweisung wird zum Teil über einen Satz von Indexwerten in einem Indexfeld 2013 verdichtet. Die Ausführungseinheitenhardware verweist auf einen Satz Verdichtungstabellen auf Grundlage der Indexwerte und verwendet die Verdichtungstabellenausgaben zum Rekonstruieren einer nativen Anweisung in dem 128-Bit-Anweisungsformat 2010. Andere Größen und Formate der Anweisung können verwendet werden.
  • Für jedes Format definiert der Anweisungs-Opcode 2012 die Funktion, die die Ausführungseinheit ausführen soll. Die Ausführungseinheiten führen jede Anweisung parallel über die mehreren Datenelemente jedes Operanden hinweg aus. Beispielsweise führt die Ausführungseinheit in Reaktion auf eine Addierungsanweisung eine simultane Addierungsoperation über jeden Farbkanal hinweg aus, der ein Texturelement oder Bildelement darstellt. Standardmäßig führt die Ausführungseinheit jede Anweisung über alle Datenkanäle der Operanden hinweg aus. Das Befehlssteuerungsfeld 2014 kann die Kontrolle über bestimmte Ausführungsoptionen erlauben, wie z. B. die Auswahl der Kanäle (z. B. Prädikation) und die Reihenfolge der Datenkanäle (z. B. Swizzle). Für die Anweisungen im 128-Bit-Anweisungsformat 2010 begrenzt ein Exec-Größenfeld 2016 die Anzahl Datenkanäle, die parallel ausgeführt werden. Ein exec-size-Feld 2016 ist möglicherweise nicht für die Verwendung im 64-Bit-Kompaktbefehlsformat 2030 verfügbar.
  • Einige Ausführungseinheitenanweisungen haben bis zu drei Operanden, unter anderem zwei Source-Operanden, src0 2020, srcl 2022, und ein Ziel 2018. Die Ausführungseinheiten können Befehle mit zwei Zielen unterstützen, wobei eines der Ziele implizit ist. Datenmanipulierungsanweisungen können einen dritten Quelloperanden (z. B. SRC2 2024) aufweisen, wo der Anweisungs-Opcode 2012 die Anzahl der Quelloperanden bestimmt. Der letzte Quelloperand einer Anweisung kann ein direkter (z. B. hartcodierter) Wert sein, der mit den Anweisungen weitergegeben wird.
  • Das 128-Bit-Befehlsformat 2010 kann ein Zugriffs-/Adressiermodusfeld 2026 umfassen, das z. B. angibt, ob der direkte Registeradressiermodus oder der indirekte Registeradressiermodus verwendet wird. Wenn der direkte Adressierungsmodus verwendet wird, wird die Registeradresse eines oder mehrerer Operanden direkt durch die Bits in der Anweisung bereitgestellt.
  • Das 128-Bit-Befehlsformat 2010 kann auch ein Zugriffs-/Adressmodusfeld 2026 umfassen, das einen Adressmodus und/oder einen Zugriffsmodus für den Befehl angibt. Der Zugriffsmodus kann verwendet werden, um eine Datenzugriffsausrichtung für die Anweisung zu definieren. Es können Zugriffsmodi unter anderem eines 16-Byte-ausgerichteten Zugriffsmodus und eines 1 -Byte-ausgerichteten Zugriffsmodus unterstützt werden, wobei die Byte-Ausrichtung des Zugriffsmodus die Zugriffsausrichtung der Befehlsoperanden bestimmt. Beispielsweise kann die Anweisung in einem ersten Modus byteausgerichtete Adressierung für Quell- und Zieloperanden verwenden und die Anweisung kann in einem zweiten Modus 16-Byte-ausgerichtete Adressierung für alle Source- und Zieloperanden verwenden.
  • Der Adressmodusabschnitt des Zugriffs-/Adressmodus-Feldes 2026 kann bestimmen, ob der Befehl direkte oder indirekte Adressierung verwenden soll. Wenn der direkte Registeradressierungsmodus verwendet wird, stellen Bits in der Anweisung die Registeradresse eines oder mehrerer Operanden direkt zur Verfügung. Wenn der indirekte Registeradressierungsmodus verwendet wird, kann die Registeradresse eines oder mehrerer Operanden basierend auf einem Adressregisterwert und einem direkten Adressfeld in der Anweisung berechnet werden.
  • Befehle können basierend auf Opcode 2012-Bitfeldern gruppiert werden, um die Opcode-Decodierung 2040 zu vereinfachen. Für einen 8-Bit-Opcode erlauben die Bits 4, 5 und 6 der Ausführungseinheit die Bestimmung der Art des Opcodes. Die spezielle dargestellte Opcode-Gruppierung ist nur ein Beispiel. Eine Bewegungs- und Logik-Opcode-Gruppe 2042 kann Datenbewegungs- und Logikbefehle umfassen (z. B. move (mov), compare (cmp)). Die Verschiebe- und die Logikgruppe 2042 können sich die fünf niedrigstwertigen Bits (LSB) teilen, wobei die Verschiebebefehle (mov) in der Form 0000xxxxb und die Logikbefehle in der Form 0001xxxxb vorliegen. Eine Flusssteuerungsanweisungsgruppe 2044 (z. B. Aufruf, Sprung (jmp)) umfasst Anweisungen in der Form 0010xxxxb (z. B. 0x20). Eine Gruppe 2046 verschiedener Anweisungen umfasst eine Mischung aus Anweisungen, unter anderem Synchronisierungsanweisungen (z. B. Warten, Senden) in Form von 001Ixxxxb (z. B. 0x30). Eine Gruppe 2048 paralleler Rechenanweisungen umfasst bauteilspezifische arithmetische Anweisungen (z. B. Addieren, Multiplizieren (mul)) in Form von 0100xxxxb (z. B. 0x40). Die parallele Mathematik-Befehlsgruppe 2048 führt die arithmetischen Operationen datenkanalübergreifend parallel aus. Die Vektor-Mathematikgruppe 2050 umfasst arithmetische Anweisungen (z. B. dp4) in Form von 0101xxxxb (z. B. 0x50). Die Vektorrechnungsgruppe führt arithmetische Anweisungen wie Punktproduktrechnungen auf Vektoroperanden aus. Der illustrierte Opcode-Decoder 2040 kann in einer Ausführungsform dazu verwendet werden, zu bestimmen, welcher Abschnitt einer Ausführungseinheit zur Ausführung eines decodierten Befehls verwendet wird. Beispielsweise können einige Befehle als systolische Befehle bezeichnet werden, die von einem systolischen Array ausgeführt werden. Andere Befehle, wie z. B. Raytracing-Befehle (nicht dargestellt), können an einen Raytracing-Kern oder eine Raytracing-Logik innerhalb eines Slice oder einer Partition der Ausführungslogik weitergeleitet werden.
  • Grafikpi peline
  • 21 ist ein Blockdiagramm eines Grafikprozessors 2100 nach einer anderen Ausführungsform. Die Elemente aus 21 mit gleichen oder ähnlichen Namen wie die Elemente einer anderen Figur hierin beschreiben die gleichen Elemente wie in den anderen Figuren, können in ähnlicher Weise arbeiten oder funktionieren, können die gleichen Komponenten umfassen und können mit anderen Einheiten verbunden sein, wie die, die an anderer Stelle hierin beschrieben sind, sind aber nicht auf solche beschränkt.
  • Der Grafikprozessor 2100 kann verschiedene Arten von GrafikverarbeitungsPipelines umfassen, z. B. eine Geometrie-Pipeline 2120, eine Medienpipeline 2130, eine Anzeige-Engine 2140, eine Thread-Ausführungslogik 2150 und eine Render-AusgabePipeline 2170. Der Grafikprozessor 2100 kann ein Grafikprozessor innerhalb eines Mehrkernverarbeitungssystems sein, das einen oder mehrere Allzweckverarbeitungskerne umfasst. Der Grafikprozessor kann durch Registerschreibvorgänge in einem oder mehreren Steuerregistern (nicht dargestellt) oder über Befehle gesteuert werden, die über eine Ringverbindung 2102 an den Grafikprozessor 2100 ausgegeben werden. Die Ringverbindung 2102 kann den Grafikprozessor 2100 mit anderen Verarbeitungskomponenten koppeln, z. B. mit anderen Grafikprozessoren oder Allzweckprozessoren. Befehle von der Ringverbindung 2102 werden durch einen Befehls-Streamer 2103 interpretiert, der Anweisungen an einzelne Komponenten der Geometriepipeline 2120 oder der Medienpipeline 2130 bereitstellt.
  • Der Befehlsstreamer 2103 kann den Betrieb eines Vertex-Fetcher 2105 steuern, der Vertexdaten aus dem Speicher liest und Vertex-Verarbeitungsbefehle ausführt, die vom Befehlsstreamer 2103 bereitgestellt werden. Der Vertex-Fetcher 2105 kann Vertexdaten an einen Vertex-Shader 2107 liefern, der Koordinatenraumtransformationen und Beleuchtungsoperationen für jeden Vertex ausführt. Vertex-Fetcher 2105 und Vertex-Shader 2107 können Vertex-Verarbeitungsanweisungen ausführen, indem sie Ausführungs-Threads über einen Thread-Dispatcher 2131 an die Ausführungseinheiten 2152A bis 2152B verteilen.
  • Die Ausführungseinheiten 2152A bis 2152B können ein Array von Vektorprozessoren mit einem Anweisungssatz zur Ausführung von Grafik- und Medienoperationen sein. Die Ausführungseinheiten 2152A bis 2152B können einen angeschlossenen L1-Cache 2151 haben, der für jedes Array spezifisch ist oder von den Arrays gemeinsam genutzt wird. Der Cache kann als Datencache, Anweisungscache oder einzelner Cache konfiguriert sein, der partitioniert ist, um Daten und Anweisungen in unterschiedlichen Partitionen zu umfassen.
  • Eine Geometrie-Pipeline 2120 kann Tessellierungskomponenten umfassen, um eine hardwarebeschleunigte Tessellierung von 3D-Objekten auszuführen. Ein programmierbarer Hull-Shader 2111 kann die Tessellierungsoperationen konfigurieren. Ein programmierbarer Domänen-Shader 2117 kann die Backend-Auswertung der Tessellierungsausgabe bereitstellen. Ein Tessellator 2113 kann auf Anweisung des Hull-Shaders 2111 arbeiten und eine spezielle Logik umfassen, um einen Satz detaillierter geometrischer Objekte auf der Grundlage eines groben geometrischen Modells zu erzeugen, das als Eingabe für die Geometrie-Pipeline 2120 bereitgestellt wird. Wenn keine Tessellierung verwendet wird, können außerdem Tessellierungskomponenten (z. B. Hull-Shader 2111, Tesselator 2113 und Domain-Shader 2117) umgangen werden. Die Tessellierung-Komponenten können auf der Grundlage der vom Vertex-Shader 2107 empfangenen Daten arbeiten.
  • Vollständige geometrische Objekte können von einem Geometrieshader 2119 über einen oder mehrere Threads verarbeitet werden, die an die Ausführungseinheiten 2152A bis 2152B weitergeleitet werden, oder sie können direkt an den Clipper 2129 weitergeleitet werden. Der Geometrieshader kann auf ganzen geometrischen Objekten arbeiten und nicht auf Vertizes oder Vertex-Patches wie in früheren Phasen der Grafikpipeline. Wenn die Tessellierung deaktiviert ist, empfängt der Geometrieshader 2119 Eingaben von dem Vertex-Shader 2107. Der Geometrieshader 2119 kann von einem Geometrieshader-Programm so programmiert werden, dass er eine Geometrietessellierung ausführt, wenn die Tessellierungseinheiten deaktiviert sind.
  • Vor der Rasterisierung verarbeitet ein Clipper 2129 die Vertexdaten. Der Clipper 2129 kann ein Clipper mit einer festen Funktion oder ein programmierbarer Clipper mit Clipping- und Geometrieshaderfunktionen sein. Eine Rasterisierungs- und Tiefenprüfungskomponente 2173 in der Rendering-Ausgabepipeline 2170 kann Pixel-Shader versenden, um die geometrischen Objekte in Darstellungen pro Pixel zu konvertieren. Die Pixel-Shader-Logik kann in der Thread-Ausführungslogik 2150 umfasst sein. Optional kann eine Anwendung den Rasterisierer und die Tiefenprüfungskomponente 2173 umgehen und über eine Stream-Out-Einheit 2123 auf nicht gerasterte Vertexdaten zugreifen.
  • Der Grafikprozessor 2100 hat einen Verbindungsbus, eine Verbindungsstruktur oder einen anderen Verbindungsmechanismus, der die Übermittlung von Daten und Meldungen unter den wichtigen Bestandteilen des Prozessors zu ermöglicht. In einigen Ausführungsformen sind die Ausführungseinheiten 2152A bis 2152B und die zugehörigen Logikeinheiten (z. B. L1-Cache 2151, Sampler 2154, Textur-Cache 2158 usw.) über einen Datenport 2156 miteinander verbunden, um Speicherzugriffe auszuführen und mit den Rendering-Output-Pipeline-Komponenten des Prozessors zu kommunizieren. Ein Sampler 2154, die Caches 2151, 2158 und die Ausführungseinheiten 2152A bis 2152B können jeweils separate Speicherzugriffspfade haben. Optional kann der Textur-Cache 2158 auch als Sampler-Cache konfiguriert sein.
  • Die Render-Output-Pipeline 2170 kann eine Rasterisierer- und Tiefenprüfkomponente 2173 umfassen, die vertexbasierte Objekte in eine zugehörige pixelbasierte Darstellung umwandelt. Die Rasterisierungslogik kann eine Windower/Masker-Einheit umfassen, um eine Dreiecks- und Linienrasterisierung mit festen Funktionen auszuführen. Ein entsprechender Rendercache 2178 und Tiefencache 2179 sind in einigen Ausführungsformen ebenfalls verfügbar. Eine Pixeloperationskomponente 2177 führt pixelbasierte Operationen auf die Daten aus, wobei in einigen Fällen jedoch Pixeloperationen, die mit 2D-Operationen assoziiert sind (z. B. Bitblockbildtransfers mit Blending) durch die 2D-Engine 2141 ausgeführt oder zum Zeitpunkt der Anzeige durch den Anzeige-Controller 2143 unter Verwendung von Overlay-Anzeigeebenen ersetzt werden. Ein gemeinsam genutzter L3-Cache 2175 kann allen Grafikkomponenten zur Verfügung stehen und ermöglicht die gemeinsame Nutzung von Daten ohne die Verwendung des Hauptspeichers des Systems.
  • Die Medienpipeline 2130 kann eine Medien-Engine 2137 und ein Video-Frontend 2134 umfassen. Das Video-Frontend 2134 kann Pipeline-Befehle vom Befehlsstreamer 2103 empfangen. Die Medienpipeline 2130 kann einen separaten Befehlsstreamer umfassen. Das Video-Frontend 2134 kann Medienbefehle verarbeiten, bevor der Befehl an die Media Engine 2137 gesendet wird. Die Medien-Engine 2137 kann eine Thread-Spawning-Funktionalität umfassen, um Threads zur Weiterleitung an die Thread-Ausführungslogik 2150 über den Thread-Dispatcher 2131 zu erzeugen.
  • Der Grafikprozessor 2100 kann eine Anzeige-Engine 2140 umfassen. Diese Anzeige-Engine 2140 kann extern zum Prozessor 2100 sein und mit dem Grafikprozessor über die Ringverbindung 2102 oder einen anderen Verbindungsbus oder eine andere Struktur verbunden sein. Die Anzeige-Engine 2140 kann eine 2D-Engine 2141 und einen Anzeige-Controller 2143 umfassen. Die Anzeige-Engine 2140 kann eine spezielle Logik umfassen, die unabhängig von der 3D-Pipeline arbeiten kann. Der Anzeige-Controller 2143 kann mit einer Anzeigevorrichtung (nicht dargestellt) gekoppelt werden, das ein systemintegriertes Anzeigevorrichtung sein kann, wie in einem Laptop-Computer, oder eine externe Anzeigevorrichtung, die über einen Anzeigevorrichtungsanschluss angeschlossen ist.
  • Die Geometrie-Pipeline 2120 und die Medienpipeline 2130 können so konfiguriert sein, dass sie Operationen auf der Grundlage mehrerer Grafik- und Medien-Programmierschnittstellen ausführen und sind nicht spezifisch für eine bestimmte Anwendungsprogrammierschnittstelle (API). Eine Treibersoftware für den Grafikprozessor kann API-Aufrufe, die für eine bestimmte Grafik- oder Medienbibliothek spezifisch sind, in Befehle übersetzen, die vom Grafikprozessor verarbeitet werden können. Die Open Graphics Library (OpenGL), die Open Computing Language (OpenCL) und/oder die Vulkan-Grafik- und Rechner-API, die alle von der Khronos Group stammen, können unterstützt werden. Es kann auch Unterstützung für die Direct3D-Bibliothek der Microsoft Corporation bereitgestellt werden. Eine Kombination dieser Bibliotheken kann unterstützt werden. Außerdem kann eine Unterstützung für die Open Source Computer Vision Library (OpenCV) bereitgestellt werden. Eine künftige API mit einer kompatiblen 3D-Pipeline wäre ebenfalls unterstützt, wenn eine Abbildung von der Pipeline einer künftigen API zur Pipeline des Grafikprozessor möglich ist.
  • Grafikpipelineprogrammierung
  • 22A ist ein Blockdiagramm, das ein Grafikprozessor-Befehlsformat 2200 illustriert, das zum Programmieren von Grafikverarbeitungspipelines verwendet wird, wie z. B. die hier in Verbindung mit 16A, 17, 21 beschriebenen. 22B ist ein Blockdiagramm, das eine Grafikprozessorbefehlssequenz 2210 nach einer Ausführungsform illustriert. Die Kästen mit durchgezogenen Linien aus 22A illustrieren die Bestandteile, die allgemein in einem Graphikbefehl umfasst sind, während die gestrichelten Linien Bestandteile umfassen, die optional sind oder die nur in einem Untersatz von Graphikbefehlen umfasst sind. Das beispielhafte Grafikprozessor-Befehlsformat 2200 aus 22A umfasst Datenfelder zur Identifizierung eines Clients 2202, einen Befehlsoperationscode (Opcode) 2204 und Daten 2206 für den Befehl. Ein Unter-Opcode 2205 und eine Befehlsgröße 2208 sind in einigen Befehlen ebenfalls umfassen.
  • Der Client 2202 kann die Client-Einheit der Grafikvorrichtung angeben, die die Befehlsdaten verarbeitet. Ein Befehls-Parser des Grafikprozessors kann das Client-Feld jedes Befehls untersuchen, um die weitere Verarbeitung des Befehls zu bestimmen und die Befehlsdaten an die entsprechende Client-Einheit weiterzuleiten. Die Grafikprozessor-Clienteinheiten können eine Speicherschnittstelleneinheit, eine Rendereinheit, eine 2D-Einheit, eine 3D-Einheit und eine Medieneinheit umfassen. Jede Client-Einheit kann eine entsprechende Verarbeitungspipeline haben, die die Befehle verarbeitet. Wenn der Befehl durch die Clienteinheit empfangen wird, liest die Clienteinheit den Opcode 2204 und, wenn vorhanden, den Unter-Opcode 2205 aus, um die auszuführende Operation zu bestimmen. Die Clienteinheit führt den Befehl unter Verwendung von Informationen im Datenfeld 2206 aus. Für einige Befehle wird eine ausdrückliche Befehlsgröße 2208 erwartet, um die Größe des Befehls anzugeben. Der Befehls-Parser kann die Größe zumindest einiger der Befehle automatisch anhand des Befehls-Opcodes bestimmen. Befehle können über Vielfache eines Doppelwortes ausgerichtet werden. Es können auch andere Befehlsformate verwendet werden.
  • Das Ablaufdiagramm in 22B illustriert eine beispielhafte Grafikprozessor-Befehlssequenz 2210. Software oder Firmware eines Datenverarbeitungssystems, das einen beispielhaften Grafikprozessor umfasst, kann eine Version der dargestellten Befehlssequenz verwenden, um einen Satz von Grafikoperationen einzurichten, auszuführen und zu beenden. Eine Beispiel-Befehlssequenz wird nur zu Beispielzwecken dargestellt und beschrieben und ist nicht auf diese spezifischen Befehle oder auf diese Befehlssequenz beschränkt. Weiterhin können die Befehle als Befehlsbatch in einem Befehlsablauf ausgegeben werden, sodass der Grafikprozessor die Befehlssequenz in mindestens teilweiser Übereinstimmung ausführen kann.
  • Die Grafikprozessor-Befehlssequenz 2210 kann mit einem Pipeline-Flush-Befehl 2212 beginnen, um jede aktive Grafikpipeline zu veranlassen, die aktuell anstehenden Befehle für die Pipeline abzuschließen. Optional können die 3D-Pipeline 2222 und die Medienpipeline 2224 nicht gleichzeitig arbeiten. Die Pipelineleerung erfolgt, um die aktiven Grafikpipeline zu veranlassen, ausstehende Befehle abzuschließen. In Reaktion auf eine Pipelineleerung pausiert der Befehlsparser für den Grafikprozessor die Befehlsverarbeitung, bis die aktiven Zeichnungsengines die ausstehenden Operationen abschließen und die jeweiligen Lesecaches invalidiert werden. Optional können Daten in dem Rendercache, der als „unsauber“ markiert ist, in den Speicher geleert werden. Der Pipeline-Flush-Befehl 2212 kann zur Pipeline-Synchronisation oder vor dem Versetzen des Grafikprozessors in einen Zustand mit geringer Leistungsaufnahme verwendet werden.
  • Ein Pipeline-Auswahlbefehl 2213 kann verwendet werden, wenn eine Befehlssequenz erfordert, dass der Grafikprozessor explizit zwischen den Pipelines umschaltet. Ein Pipeline-Auswahlbefehl 2213 kann nur einmal innerhalb eines Ausführungskontexts erforderlich sein, bevor Pipeline-Befehle ausgegeben werden, es sei denn, der Kontext soll Befehle für beide Pipelines ausgeben. Ein Pipeline-Flush-Befehl 2212 kann unmittelbar vor einem Pipeline-Wechsel über den Pipeline-Auswahlbefehl 2213 erforderlich sein.
  • Ein Pipeline-Steuerungsbefehl 2214 kann eine Grafik-Pipeline für den Betrieb konfigurieren und kann zur Programmierung der 3D-Pipeline 2222 und der Medienpipeline 2224 verwendet werden. Der Pipeline-Steuerbefehl 2214 kann den Pipelinezustand für die aktive Pipeline konfigurieren. Der Pipeline-Steuerbefehl 2214 kann zur Pipeline-Synchronisation und zum Löschen von Daten aus einem oder mehreren Cache-Speichern innerhalb der aktiven Pipeline vor der Verarbeitung eines Befehlsstapels verwendet werden.
  • Befehle, die sich auf den Zustand des Rückgabepuffers 2216 beziehen, können zur Konfiguration eines Satzes von Rückgabepuffern für die jeweiligen Pipelines zum Schreiben von Daten verwendet werden. Einige Pipeline-Operationen erfordern die Zuweisung, Auswahl oder Konfiguration von einem oder mehreren Rückgabepuffern, in die die Operationen während der Verarbeitung Zwischendaten schreiben. Der Grafikprozessor kann auch einen oder mehrere Rückgabepuffer verwenden, um Ausgabedaten zu speichern und eine threadübergreifende Kommunikation auszuführen. Der Rückpufferstatus 2216 kann die Auswahl der Größe und Anzahl der Rückpuffer beinhalten, die für einen Satz von Pipeline-Operationen verwendet werden sollen.
  • Die verbleibenden Befehle in dem Befehlsablauf unterscheiden sich je nach der aktiven Pipeline für Operationen. Basierend auf der Pipelinebestimmung 2220 wird die Befehlssequenz beginnend mit dem 3D-Pipelinezustand 2230 auf die 3D-Pipeline 2222 oder beginnend mit dem Medienpipelinezustand 2240 auf die Medienpipeline 2224 zugeschnitten.
  • Die Befehle zum Konfigurieren des 3D-Pipelinezustands 2230 umfassen 3D-Zustandseinstellbefehle für den Vertex-Pufferzustand, Vertex-Elementzustand, konstanten Farbzustand, Tiefenpufferzustand und andere Zustandsvariablen, die konfiguriert sein sollen, bevor 3D-primitive Befehle #verarbeitet werden. Die Werte dieser Befehle werden mindestens teilweise basierend auf der jeweils verwendeten 3D-API berechnet. Die Befehle für den 3D-Pipeline-Status 2230 können auch bestimmte Pipeline-Elemente selektiv deaktivieren oder umgehen, wenn diese Elemente nicht verwendet werden sollen.
  • Ein 3D-Primitiv 2232-Befehl kann verwendet werden, um 3D-Primitive zur Verarbeitung durch die 3D-Pipeline zu übermitteln. Befehle und entsprechende Parameter, die über den Befehl für 3D-Primitive 2232 an den Grafikprozessor weitergegeben werden, werden an die Vertex-Fetcher-Funktion in der Grafikpipeline weitergeleitet. Die Vertex-Fetcher-Funktion verwendet die Befehlsdaten für die 3D-Primitive 2232 zur Erzeugung von Vertexdatenstrukturen. Die Vertexdatenstrukturen werden in einem oder mehreren Rücklaufpuffern gespeichert. Der Befehl 3D-Primitiv 2232 kann verwendet werden, um Vertex-Operationen auf 3D-Primitiven über Vertex-Shader auszuführen. Um den Vertexshader zu verarbeiten, versendet die 3D-Pipeline 2222 Shaderausführungsthreads an die Grafikprozessorausführungseinheiten.
  • Die 3D-Pipeline 2222 kann über einen Ausführungsbefehl 2234 oder ein Ereignis ausgelöst werden. Ein Register kann Ausführungsbefehlsausführungen schrieben. Eine Ausführung kann über einen ‚go‘- oder ‚kick‘-Befehl in der Befehlssequenz ausgelöst werden. Die Befehlsausführung kann mit einem Pipeline-Synchronisationsbefehl ausgelöst werden, um die Befehlssequenz durch die Grafikpipeline zu leeren. Die 3D-Pipeline führt eine Geometrieverarbeitung für 3D-Primitive aus. Wenn die Operationen abgeschlossen sind, werden die entstehenden geometrischen Objekte rasterisiert und die Pixelengine färbt die entstehenden Pixel ein. Weitere Befehle zum Steuern von Pixelshading und Pixel-Backend-Operationen können für diese Operationen ebenfalls umfasst sein.
  • Die Grafikprozessor-Befehlssequenz 2210 kann bei der Ausführung von Medienoperationen dem Pfad der Medienpipeline 2224 folgen. Allgemein hängt die spezifische Verwendung und Art der Programmierung für die Medienpipeline 2224 von den auszuführenden Medien- oder Rechenoperationen ab. Bestimmte Mediendecodiervorgänge können während der Medien-decodierung an die Medienpipeline ausgelagert werden. Die Medienpipeline kann auch umgangen werden und die Mediendecodierung kann ganz oder teilweise unter Verwendung von Ressourcen ausgeführt werden, die von einem oder mehreren Allzweck-Verarbeitungskernen bereitgestellt werden. Die Medienpipeline kann auch Elemente für Allzweck-Grafikprozessoreinheit (GPGPU-Operationen) umfassen, bei denen der Grafikprozessor verwendet wird, um SIMD-Vektoroperationen unter Verwendung von Rechen-Shader-Programmen auszuführen, die nicht explizit mit dem Rendern von Grafik-Primitiven verbunden sind.
  • Die Medienpipeline 2224 kann in ähnlicher Weise wie die 3D-Pipeline 2222 konfiguriert sein. Ein Satz Befehle zum Konfigurieren des Medienpipelinezustands 2240 wird versendet oder in eine Befehlswarteschlange vor den Medienobjektbefehlen 2242 eingestellt. Befehle für den Medienpipeline-Zustand 2240 können Daten zur Konfiguration der Medienpipeline-Elemente umfassen, die zur Verarbeitung der Medienobjekte verwendet werden. Dies umfasst Daten zur Konfiguration der Videodecodierung und Videocodierungslogik innerhalb der Medienpipeline, wie etwa dem Codierungs- oder Decodierungsformat. Befehle für den Medienpipeline-Zustand 2240 können auch die Verwendung von einem oder mehreren Zeigern auf „indirekte“ Zustandselemente unterstützen, die einen Stapel von Zustandseinstellungen umfassen.
  • Medienobjektbefehle 2242 können Zeiger auf Medienobjekte zur Verarbeitung durch die Medienpipeline liefern. Die Medienobjekte umfassen Speicherpuffer, die zu verarbeitende Videodaten umfassen. Optional müssen alle Medienpipeline-Zustände gültig sein, bevor ein Medienobjekt-Befehl 2242 ausgegeben wird. Wenn der Pipelinezustand konfiguriert ist und die Medienobjektbefehle 2242 in die Warteschlange eingereiht sind, wird die Medienpipeline 2224 über einen Ausführungsbefehl 2244 oder ein entsprechendes Ausführungsereignis ausgeführt (z. B. Registerschreibvorgang). Die Ausgabe von der Medienpipeline 2224 kann dann durch die Operationen, die durch die 3D-Pipeline 2222 oder die Medienpipeline 2224 bereitgestellt werden, nachverarbeitet werden. GPGPU-Operationen können in ähnlicher Weise konfiguriert und ausgeführt werden wie Medienoperationen.
  • Grafiksoftwarearchitektur
  • 23 illustriert eine beispielhafte Grafiksoftware-Architektur für ein Datenverarbeitungssystem 2300. Eine solche Software-Architektur kann eine 3D-Grafikanwendung 2310, ein Betriebssystem 2320 und mindestens einen Prozessor 2330 umfassen. Der Prozessor 2330 kann einen Grafikprozessor 2332 und einen oder mehrere Allzweckprozessorkerne 2334 umfassen. Der Prozessor 2330 kann eine Variante des Prozessors 1402 oder ein anderer der hierin beschriebenen Prozessoren sein. Der Prozessor 2330 kann anstelle des Prozessors 1402 oder eines anderen der hierin beschriebenen Prozessoren verwendet werden. Daher offenbart die Offenbarung beliebiger Merkmale in Kombination mit dem Prozessor 1402 oder einem anderen der Prozessoren, die hierin beschrieben sind, auch eine entsprechende Kombination mit dem/den Grafikprozessor 2330, ist aber nicht auf diese beschränkt. Außerdem können die Elemente aus 23 mit gleichen oder ähnlichen Namen wie die Elemente einer anderen Figur hierin beschreiben die gleichen Elemente wie in den anderen Figuren, in ähnlicher Weise arbeiten oder funktionieren, können die gleichen Komponenten umfassen und können mit anderen Einheiten verbunden sein, wie die, die an anderer Stelle hierin beschrieben sind, sind aber nicht auf solche beschränkt. Die Grafikanwendung 2310 und das Betriebssystem 2320 werden jeweils im Systemspeicher 2350 des Datenverarbeitungssystems ausgeführt.
  • Die 3D-Grafikanwendung 2310 kann ein oder mehrere Shader-Programme unter anderem Shader-Anweisungen 2312 umfassen. Die Shader-Sprachbefehle können in einer High-Level-Shader-Sprache vorliegen, wie z. B. die High-Level-Shader-Sprache (HLSL) von Direct3D, die OpenGL-Shader-Sprache (GLSL) usw. Die Anwendung kann auch ausführbare Anweisungen 2314 in einer Maschinensprache umfassen, die für die Ausführung durch den Allzweckprozessorkern 2334 geeignet ist. Die Anwendung kann auch Grafikobjekte 2316 umfassen, die durch Vertexdaten definiert sind.
  • Das Betriebssystem 2320 kann ein Microsoft® Windows®-Betriebssystem der Microsoft Corporation, ein proprietäres UNIX-ähnliches Betriebssystem oder ein Open-Source-UNIX-ähnliches Betriebssystem sein, das eine Variante des Linux-Kernels verwendet. Das Betriebssystem 2320 kann eine Grafik-API 2322 wie die Direct3D API, die OpenGL API oder die Vulkan API unterstützen. Wenn die Direct3D API verwendet wird, verwendet das Betriebssystem 2320 einen Frontend-Shadercompiler 2324 zum Kompilieren aller Shaderanweisungen 2312 in HLSL in eine Shadersprache eines tieferen Levels. Die Kompilation kann eine Just-in-Time-Kompilation (JIT-Kompilation) sein, oder die Anwendung kann eine Shader-Vorkompilation ausführen. High-Level-Shader können während der Kompilierung der 3D-Grafikanwendung 2310 in Low-Level-Shader kompiliert werden. Die Shader-Anweisungen 2312 können in einer Zwischenform bereitgestellt werden, z. B. in einer Version der von der Vulkan-API verwendeten Standard Portable Intermediate Representation (SPIR).
  • Der Benutzermodus-Grafiktreiber 2326 kann einen Back-End-ShaderCompiler 2327 umfassen, um die Shader-Anweisungen 2312 in eine hardwarespezifische Darstellung zu konvertieren. Wenn die OpenGL API verwendet wird, werden Shaderanweisungen 2312 in der GLSL-High-Level-Sprache zur Kompilierung an einen Benutzermodusgrafiktreiber 2326 übergeben. Der Benutzermodus-Grafiktreiber 2326 kann Betriebssystem-Kernelmodusfunktionen 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-Umsetzungen
  • Ein oder mehrere Aspekte können durch repräsentativen Code umgesetzt werden, der auf einem maschinenlesbaren Medium gespeichert ist und die Logik innerhalb einer integrierten Schaltung, wie z. B. eines Prozessors, darstellt und/oder definiert. Das maschinenlesbare Medium kann z. B. Befehle umfassen, die verschiedene Logiken innerhalb des Prozessors darstellen. Beim Auslesen durch eine Maschine können die Anweisungen dazu führen, dass die Maschine die Logik so herstellt, dass die darin beschriebenen Techniken ausgeführt werden. Solche Darstellungen, die als „IP-Kerne“ bekannt sind, sind wiederverwendbare Logikeinheiten der Logik für eine integrierte Schaltung, die auf einem greifbaren maschinenlesbaren Medium als Hardwaremodell gespeichert werden kann, das die Struktur der integrierten Schaltung beschreibt. Das Hardwaremodell kann an die verschiedenen Kunden oder Herstellungseinrichtungen geliefert werden, die das Hardwaremodell auf Herstellungsmaschinen laden, die die integrierte Schaltung herstellen. Die integrierte Schaltung kann so hergestellt sein, dass die Schaltung Operationen ausführt, die in Assoziation mit einer der hierin beschriebenen Ausführungsformen beschrieben sind.
  • 24A ist ein Blockdiagramm, das ein IP-Kern-Entwicklungssystem 2400 illustriert, das zur Herstellung einer integrierten Schaltung verwendet werden kann, um Operationen nach einer Ausführungsform auszuführen. Das IP-Kernentwicklungssystem 2400 kann verwendet werden, um modulare wiederverwendbare Designs zu erzeugen, die in ein größeres Design eingebaut oder verwendet werden können, um eine gesamte integrierte Schaltung (z. B. eine SOC-integrierte Schaltung) zu erzeugen. Eine Designeinrichtung 2430 kann eine Softwaresimulation 2410 eines IP-Kerndesigns in einer Programmiersprache auf 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 designen, zu prüfen und zu verifizieren. Das Simulationsmodell 2412 kann Funktions-, Verhaltens- und/oder Timingsimulationen umfassen. Ein Design für einen Registertransferlevel (RTL) 2415 kann dann aus dem Simulationsmodell 2412 erzeugt oder synthetisiert werden. Das RTL-Design 2415 ist eine Abstraktion des Verhaltens der integrierten Schaltung, die den Fluss digitaler Signale zwischen Hardwareregistern modelliert, unter anderem die entsprechenden Logik, die unter Verwendung der modellierten digitalen Signale ausgeführt wird. Neben einem RTL-Design 2415 können auch Lower-Level-Designs auf Logik-Ebene oder Transistor-Ebene erzeugt, entworfen oder synthetisiert werden. So können die genauen Details des anfänglichen Designs und der Simulation variieren.
  • Das RTL-Design 2415 oder etwas Entsprechendes können weiter durch die Designeinrichtung in ein Hardwaremodell 2420 synthetisiert werden, das in einer Hardwarebeschreibungssprache (HDL) oder einer anderen Darstellung physischer Designdaten erstellt sein kann. Die HDL kann ferner simuliert oder geprüft werden, um das IP-Kerndesign zu verifizieren. Das IP-Kerndesign kann zur Lieferung an eine Drittherstellungseinrichtung 2465 unter Verwendung eines nichtflüchtigen Speichers 2440 (z. B. Festplatte, Flash-Speicher oder ein anderes nichtflüchtiges Speichermedium) gespeichert sein. Alternativ kann das IP-Kerndesign (z. B. über das Internet) über eine verkabelte Verbindung 2450 oder eine drahtlose Verbindung 2460 übermittelt werden. Die Herstellungseinrichtung 2465 kann dann eine integrierte Schaltung herstellen, der mindestens teilweise auf dem IP-Kerndesign basiert. Die hergestellte integrierte Schaltung kann konfiguriert sein, Operationen nach mindestens einer hierin beschriebenen Ausführungsform bereitzustellen.
  • 24B illustriert eine Querschnitts-Seitenansicht einer integrierten Schaltungs-Packagebaugruppe 2470. Die integrierte Schaltungs-Packagebaugruppe 2470 illustriert eine Umsetzung eines oder mehrerer Prozessoren oder Beschleunigervorrichtungen wie hierin beschrieben. Die Packagebaugruppe 2470 umfasst mehrere Einheiten von Hardwarelogik 2472, 2474, die mit einem Substrat 2480 verbunden sind. Die Logik 2472, 2474 kann mindestens teilweise in konfigurierbarer Logik oder Festfunktionslogikhardware umgesetzt sein und kann einen oder mehrere Abschnitte eines der Prozessorkern(e), Grafikprozessor(en) oder anderen Beschleunigervorrichtungen umfassen, die hierin beschrieben sind. Jede Einheit der Logik 2472, 2474 kann innerhalb eines Halbleiterdies umgesetzt und mit dem Substrat 2480 über eine Interconnect-Struktur 2473 gekoppelt sein. Die Interconnect-Struktur 2473 kann konfiguriert sein, elektrische Signale zwischen der Logik 2472, 2474 und dem Substrat 2480 zu leiten und kann Verbindungen, wie unter anderem Bumps oder Pillars, umfassen. Die Interconnect-Struktur 2473 kann so konfiguriert sein, dass sie elektrische Signale, wie z. B. Eingangs-/Ausgangssignale (E/A) und/oder Stromversorgungs- oder Erdungssignale, die mit dem Betrieb der Logik 2472, 2474 verbunden sind, leitet. Optional kann das Substrat 2480 ein Laminatsubstrat auf Epoxidbasis sein. Das Substrat 2480 kann auch andere geeignete Arten von Substraten umfassen. Die Packagebaugruppe 2470 kann mit anderen elektrischen Vorrichtungen über eine Packageverbindung 2483 verbunden werden. Die Packageverbindung 2483 kann mit einer Fläche des Substrats 2480 gekoppelt sein, um elektrische Signale an andere elektrische Vorrichtungen, wie etwa an ein Motherboard, ein anderer Chipset oder ein Multichipmodul, zu routen.
  • Die Einheiten der Logik 2472, 2474 können elektrisch mit einer Brücke 2482 gekoppelt sein, die so konfiguriert ist, dass sie elektrische Signale zwischen den Logiken 2472, 2474 weiterleitet. 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 umfassen, das aus Glas oder einem geeigneten Halbleitermaterial besteht. Elektrische Routingmerkmale können auf dem Brückensubstrat gebildet werden, um eine Chip-Chip-Verbindung zwischen der Logik 2472, 2474 herzustellen.
  • Wenn auch zwei Einheiten der Logik 2472, 2474 und eine Brücke 2482 illustriert sind, können hierin beschriebene Ausführungsformen mehr oder weniger Logikeinheiten an einem oder mehr Dies umfassen. Der eine oder die mehreren Dies können durch Null oder mehr Brücken verbunden sein, da die Brücke 2482 ausgeschlossen werden kann, wenn die Logik auf einem einzigen Die umfassen ist. Alternativ dazu können mehrere Dies oder Einheiten der Logik durch eine oder mehrere Brücken verbunden sein. Weiterhin können mehrere Logikeinheiten, Dies und Brücken miteinander in anderen möglichen Konfigurationen, unter anderem dreidimensionaler Konfigurationen, verbunden sein.
  • 24C illustriert eine Packagebaugruppe 2490, die mehrere Einheiten von Hardware-Logik-Chipletts umfasst, die mit einem Substrat 2480 (z. B. Basis-Die) verbunden sind. Eine Grafikprozessoreinheit, ein Parallelprozessor und/oder ein Rechenbeschleuniger, wie hierin beschrieben, kann aus verschiedenen Silizium-Chiplets zusammengesetzt sein, die separat hergestellt werden. In diesem Zusammenhang ist ein Chiplet eine zumindest teilweise verpackte integrierte Schaltung, die einzelne Logikeinheiten umfasst, die mit anderen Chipletts zu einem größeren Package zusammengesetzt werden können. Ein vielfältiger Satz von Chipletts mit unterschiedlicher IP-Kernlogik kann in einer einzigen Vorrichtung montiert werden. Zusätzlich können die Chipletts mittels aktiver Interposer-Technologie in ein Basis-Die oder Basis-Chiplet integriert werden. Die hierin beschriebenen Konzepte ermöglichen die Zusammenschaltung und Kommunikation zwischen den verschiedenen Formen von IP innerhalb der GPU. IP-Kerne können mit unterschiedlichen Prozesstechnologien hergestellt und während der Fertigung zusammengesetzt werden, wodurch die Komplexität der Konvergenz mehrerer IPs, insbesondere bei einem großen SoC mit mehreren Arten von IPs, auf denselben Fertigungsprozess vermieden wird. Die Verwendung mehrerer Prozesstechnologien verbessert die Markteinführungszeit und bietet eine kostengünstige Möglichkeit, mehrere Produkt-SKUs zu erstellen. Außerdem lassen sich die disaggregierten IPs besser unabhängig voneinander mit Strom versorgen. Komponenten, die bei einem bestimmten Workload nicht verwendet werden, können abgeschaltet werden, was den Gesamtstromverbrauch verringert.
  • In verschiedenen Ausführungsformen kann eine Packagebaugruppe 2490 eine geringere oder größere Anzahl von Komponenten und Chipletts umfassen, die durch ein Gewebe 2485 oder eine oder mehrere Brücken 2487 miteinander verbunden sind. Die Chipletts in der Packagebaugruppe 2490 können eine 2,5D-Anordnung aufweisen, bei der mehrere Chips nebeneinander auf einem Silizium-Interposer gestapelt sind, der Durchkontaktierungen (TSVs) umfasst, um die Chipletts mit dem Substrat 2480 zu verbinden, das elektrische Verbindungen zur Packageverbindung 2483 umfasst.
  • In einer Ausführungsform ist der Silizium-Interposer ein aktiver Interposer 2489, der zusätzlich zu den TSVs eingebettete Logik umfasst. In einer solchen Ausführungsform werden die Chipletts innerhalb der Packagebaugruppe 2490 unter Verwendung von 3D-Face-to-Face-Diestapeling auf dem aktiven Interposer 2489 angeordnet. Der aktive Interposer 2489 kann neben der Verbindungsstruktur 2485 und einer Siliziumbrücke 2487 auch Hardware-Logik für E/A 2491, Cache-Speicher 2492 und andere Hardware-Logik 2493 umfassen. Die Struktur 2485 ermöglicht die Kommunikation zwischen den verschiedenen Logik-Chipletts 2472, 2474 und der Logik 2491, 2493 innerhalb des aktiven Interposers 2489. Die Struktur 2485 kann ein NoC-Interconnect oder eine andere Form von packetgeschalteter Struktur sein, die Datenpakete zwischen den Komponenten der Baugruppe vermittelt. Bei komplexen Baugruppen kann die Struktur 2485 ein dedizierter Chiplet sein, der die Kommunikation zwischen den verschiedenen Hardware-Logiken der Packagebaugruppe 2490 ermöglicht.
  • Brückenstrukturen 2487 innerhalb des aktiven Interposers 2489 können verwendet werden, um eine Punkt-zu-Punkt-Verbindung zwischen z. B. Logik- oder E/A-Chipletts 2474 und SpeicherChipletts 2475 zu ermöglichen. In einigen Umsetzungen können die Brückenstrukturen 2487 auch in das Substrat 2480 eingebettet sein.
  • Die Hardware-Logik-Chipletts können spezielle Hardware-Logik-Chipletts 2472, Logik- oder E/A-Chipletts 2474 und/oder Speicher-Chipletts 2475 umfassen. Die Hardware-Logik-Chipletts 2472 und die Logik- oder E/A-Chiplets 2474 können zumindest teilweise in konfigurierbarer Logik oder Logik-Hardware mit fester Funktionalität umgesetzt sein und können einen oder mehrere Abschnitte eines oder mehrerer der hierin beschriebenen Prozessorkerne, Grafikprozessoren, Parallelprozessoren oder anderer Beschleunigungsvorrichtungen umfassen. Die Speicher-Chipletts 2475 können DRAM-Speicher (z. B. GDDR, HBM) oder Cache-Speicher (SRAM) sein. Der Cache-Speicher 2492 innerhalb des aktiven Interposers 2489 (oder Substrats 2480) kann als globaler Cache für die Packagebaugruppe 2490, als Abschnitt eines verteilten globalen Caches oder als dedizierter Cache für die Struktur 2485 dienen
  • Jedes Chiplet kann als separates Halbleiterchip hergestellt und mit einem Basischip gekoppelt werden, der in das Substrat 2480 eingebettet oder mit diesem gekoppelt ist. Die Kopplung mit dem Substrat 2480 kann über eine Interconnect-Struktur 2473 erfolgen. Die Interconnect-Struktur 2473 kann so konfiguriert sein, dass sie elektrische Signale zwischen den verschiedenen Chipletts und der Logik innerhalb des Substrats 2480 leitet. Die Interconnect-Struktur 2473 kann Verbindungen wie z. B. Bumps oder Säulen umfassen, ist aber nicht darauf beschränkt. In einigen Ausführungsformen kann die Interconnect-Struktur 2473 so konfiguriert sein, dass sie elektrische Signale wie z. B. Eingangs-/Ausgangssignale (E/A) und/oder Stromversorgungs- oder Massesignale, die mit dem Betrieb der Logik-, E/A- und Speicher-Chipletts verbunden sind, leitet. In einer Ausführungsform koppelt eine zusätzliche Interconnect-Struktur den aktiven Interposer 2489 mit dem Substrat 2480.
  • Das Substrat 2480 kann ein Laminatsubstrat auf Epoxidbasis sein, ist jedoch nicht darauf beschränkt und das Substrat 2480 kann auch andere geeignete Arten von Substraten umfassen. Die Packagebaugruppe 2490 kann mit anderen elektrischen Vorrichtungen über eine Packageverbindung 2483 verbunden werden. Die Packageverbindung 2483 kann mit einer Fläche des Substrats 2480 gekoppelt sein, um elektrische Signale an andere elektrische Vorrichtungen, wie etwa an ein Motherboard, ein anderer Chipset oder ein Multichipmodul, zu routen.
  • Ein Logik- oder E/A-Chiplet 2474 und ein Speicher-Chiplet 2475 können elektrisch über eine Brücke 2487 gekoppelt sein, die so konfiguriert ist, dass sie elektrische Signale zwischen dem Logik- oder E/A-Chiplet 2474 und einem Speicher-Chiplet 2475 leitet. 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 umfassen, das aus Glas oder einem geeigneten Halbleitermaterial besteht. Elektrische Routing-Merkmale können auf dem Brückensubstrat ausgebildet werden, um eine Chipzu-Chip-Verbindung zwischen dem Logik- oder E/A-Chiplet 2474 und einem Speicher-Chiplet 2475 herzustellen. Die Brücke 2487 kann auch als Siliziumbrücke oder als Verbindungsbrücke bezeichnet werden. Die Brücke 2487 ist z. B. eine Embedded Multi-Die-Interconnect-Brücke (EMIB). Alternativ kann die Brücke 2487 auch einfach eine direkte Verbindung von einem Chiplet zu einem anderen Chiplet sein.
  • 24D illustriert eine Packagebaugruppe 2494 mit austauschbaren Chipletts 2495 nach einer Ausführungsform. Die austauschbaren Chipletts 2495 können in standardisierte Steckplätze auf einem oder mehreren Basis-Chipletts 2496, 2498 montiert werden. Die Basis-Chipletts 2496, 2498 können über eine Brückenverbindung 2497 gekoppelt werden, die den anderen hierin beschriebenen Brückenverbindungen ähnlich sein kann und z. B. ein EMIB sein kann. Speicher-Chipletts können auch über eine Brückenverbindung mit Logik- oder E/A-Chipletts verbunden werden. E/A- und Logik-Chipletts können über eine Verbindungsstruktur kommunizieren. Die Basis-Chipletts können jeweils einen oder mehrere Steckplätze in einem standardisierten Format für eine von Logik oder E/A oder Speicher/Cache unterstützen.
  • SRAM- und Stromversorgungsschaltungen können in einem oder mehreren der Basis-Chipletts 2496, 2498 hergestellt werden, die mit einer anderen Prozesstechnologie als die austauschbaren Chipletts 2495 hergestellt werden können, die auf den Basis-Chipletts gestapelt sind. Beispielsweise können die Basis-Chipletts 2496, 2498 mit einer größeren Prozesstechnologie hergestellt werden, während die austauschbaren Chipletts mit einer kleineren Prozesstechnologie gefertigt werden können. Einer oder mehrere der austauschbaren Chipletts 2495 können Speicher-Chipletts (z. B. DRAM-Chipletts) sein. Für die Packagebaugruppe 2494 können unterschiedliche Speicherdichten gewählt werden, je nach der angestrebten Leistung und/oder Performance für das Produkt, das die Packagebaugruppe 2494 verwendet. Zusätzlich können bei der Montage Logik-Chipletts mit einer unterschiedlichen Anzahl von Typen von Funktionseinheiten ausgewählt werden, basierend auf der für das Produkt angestrebten Leistung und/oder Performance. Zusätzlich können Chipletts, die IP-Logik-Kerne unterschiedlicher Typen umfassen, in die austauschbaren Chiplet-Slots eingesetzt werden, was hybride Prozessor-Designs ermöglicht, die verschiedene Technologie-IP-Blöcke mischen und anpassen können.
  • Beispielhafte in einem System auf einem Chip integrierte Schaltung
  • 25 bis 26B illustrieren beispielhafte integrierte Schaltungen und zugehörige Grafikprozessoren, die mit einem oder mehreren IP-Kerne hergestellt werden können. Neben dem Illustrierten können andere Logik und Schaltungen umfasst sein, unter anderem weiterer Grafikprozessors/-kerne, Peripherieschnittstellencontroller oder Allzweckprozessorkernen. Die Elemente aus 25 bis 26B mit gleichen oder ähnlichen Namen wie die Elemente einer anderen Figur hierin beschreiben die gleichen Elemente wie in den anderen Figuren, können in ähnlicher Weise arbeiten oder funktionieren, können die gleichen Komponenten umfassen und können mit anderen Einheiten verbunden sein, wie die, die an anderer Stelle hierin beschrieben sind, sind aber nicht auf solche beschränkt.
  • 25 ist ein Blockdiagramm, das eine beispielhafte integrierte System-aufeinem-Chip-Schaltung 2500 zeigt, die unter Verwendung eines oder mehrerer IP-Kerne hergestellt werden kann. Die beispielhafte integrierte Schaltung 2500 umfasst einen oder mehrere Anwendungsprozessor(en) 2505 (z. B. CPUs), mindestens einen 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 Offenbarung beliebiger Merkmale in Kombination mit einem Grafikprozessor hier auch eine entsprechende Kombination mit dem/den Grafikprozessor 2510, ist aber nicht auf diese beschränkt. Die integrierte Schaltung 2500 kann zusätzlich einen Bildprozessor 2515 und/oder einen Videoprozessor 2520 umfassen, wobei jeder dieser Prozessoren ein modularer IP-Kern aus der gleichen oder aus mehreren verschiedenen Designeinrichtungen sein kann. Die integrierte Schaltung 2500 kann Peripherie- oder Buslogik umfassen, unter anderem einen USB-Controller 2525, einen UART-Controller 2530, einen SPI/SDIO-Controller 2535 und einen I2S/I2C-Controller 2540. Zusätzlich kann die integrierte Schaltung eine Anzeigevorrichtung 2545 umfassen, die mit einem oder mehreren von einem HDMI-Controller (High-Definition Multimedia Interface) 2550 und einer MIPI-Anzeigeschnittstelle (Mobile Industry Processor Interface) 2555 verbunden ist. Der Speicher kann durch ein Flashspeicheruntersystem 2560 bereitgestellt werden, das einen Flashspeicher und einen Flashspeichercontroller umfasst. Die Speicherschnittstelle kann über einen Speichercontroller 2565 bereitgestellt werden, um auf SDRAM oder SRAM-Speichervorrichtungen zuzugreifen. Einige integrierte Schaltungen umfassen weiterhin eine eingebettete Sicherheitsengine 2570.
  • 26A bis 26B sind Blockdiagramme, die beispielhafte Grafikprozessoren zur Verwendung in einem SoC nach hierin beschriebenen Ausführungsformen illustrieren. Die Grafikprozessoren können Varianten des Grafikprozessors 1408, 1508, 2510 oder um ein anderer hierin beschriebener Grafikprozessor sein. Die Grafikprozessoren können anstelle des Grafikprozessors 1408, 1508, 2510 oder eines anderen der hierin beschriebenen Grafikprozessoren verwendet werden. Daher offenbart die Offenbarung beliebiger Merkmale in Kombination mit dem Grafikprozessor 1408, 1508, 2510 oder einem anderen der hierin beschriebenen Grafikprozessoren auch eine entsprechende Kombination mit den Grafikprozessoren aus 26A bis 26B, ist jedoch nicht darauf beschränkt. 26A illustriert einen beispielhaften Grafikprozessor 2610 einer integrierten System-on-Chip-Schaltung, die nach einer Ausführungsform unter Verwendung eines oder mehrerer IP-Kerne hergestellt werden kann. 26B illustriert einen weiteren beispielhaften Grafikprozessor 2640 einer integrierten System-on-Chip-Schaltung, die nach einer Ausführungsform unter Verwendung eines oder mehrerer IP-Kerne hergestellt werden kann. Der Grafikprozessor 2610 aus 26A ist ein Beispiel für einen Grafikprozessorkern mit geringem Stromverbrauch. Der Grafikprozessor 2640 aus 26B ist ein Beispiel für einen Grafikprozessorkern mit höhrerer Leistung. Beispielsweise können der Grafikprozessor 2610 und der Grafikprozessor 2640 jeweils eine Variante des Grafikprozessors 2510 aus 25, wie zu Beginn dieses Absatzes erwähnt.
  • Wie in 26A dargestellt ist, umfasst der Grafikprozessor 2610 einen Vertex-Prozessor 2605 und einen oder mehrere Fragment-Prozessor(en) 2615A bis 2615N (z. B. 2615A, 2615B, 2615C, 2615D, bis 2615N-1 und 2615N). Der Grafikprozessor 2610 kann verschiedene Shader-Programme über eine separate Logik ausführen, sodass der Vertex-Prozessor 2605 für die Ausführung von Operationen für Vertex-Shader-Programme optimiert ist, während der eine oder die mehreren Fragment-Prozessor(en) 2615A bis 2615N Fragment-Shading-Operationen (z. B. Pixel-Shading-Operationen) für Fragment- oder Pixel-Shader-Programme ausführen. Der Vertexprozessor 2605 führt die Vertexverarbeitungsstufe der 3D-Grafikpipeline durch und erzeugt die Primitiven- und Vertexdaten. Der/die Fragment-Prozessor(en) 2615A bis 2615N verwenden die vom Vertex-Prozessor 2605 erzeugten Primitiv- und Vertexdaten, um einen Framepuffer zu erzeugen, der auf einer Anzeigevorrichtung angezeigt wird. Der/die Fragment-Prozessor(en) 2615A bis 2615N kann/können für die Ausführung von Fragment-Shader-Programmen, wie sie in der OpenGL-API vorgesehen sind, optimiert werden, die zur Ausführung ähnlicher Operationen wie ein Pixel-Shader-Programm, wie es in der Direct 3D-API vorgesehen ist, verwendet werden können.
  • Der Grafikprozessor 2610 umfasst zusätzlich eine oder mehrere Speicherverwaltungseinheiten (MMUs) 2620A bis 2620B, Cache(s) 2625A bis 2625B und Schaltungsverbindung(en) 2630A bis 2630B. Die eine oder die mehreren MMU(s) 2620A bis 2620B stellen die Abbildung von virtuellen zu physikalischen Adressen für den Grafikprozessor 2610 bereit, unter anderem für den Vertex-Prozessor 2605 und/oder den/die Fragment-Prozessor(en) 2615A bis 2615N, der/die auf im Speicher gespeicherte Vertex- oder Bild-/Texturdaten verweisen kann/können, zusätzlich zu den Vertex- oder Bild-/Texturdaten, die in dem einen oder mehreren Cache(s) 2625A bis 2625B gespeichert sind. Die eine oder die mehreren MMU(s) 2620A bis 2620B können mit anderen MMUs innerhalb des Systems synchronisiert werden, unter anderem einer oder mehrerer MMUs, die mit dem einen oder mehreren Anwendungsprozessor(en) 2505, dem Bildprozessor 2515 und/oder dem Videoprozessor 2520 aus 25 assoziiert sind, sodass jeder Prozessor 2505 bis 2520 in einem gemeinsamen oder einheitlichen virutellen Speichersystem beteiligt sein kann. Die Komponenten des Grafikprozessors 2610 können den Komponenten anderer hier beschriebener Grafikprozessoren entsprechen. Die eine oder mehrere MMU(s) 2620A bis 2620B können der MMU 245 aus 2C. Der Vertex-Prozessor 2605 und der Fragment-Prozessor 2615A bis 2615N können mit dem Grafikmultiprozessor 234 korrespondieren. Die eine oder mehrere Schaltungsverbindung(en) 2630A bis 2630B ermöglichen es dem Grafikprozessor 2610, sich mit anderen IP-Kerne innerhalb des SoCs zu verbinden, entweder über einen internen Bus des SoCs oder über eine direkte Verbindung, je nach Ausführungsform. Die eine oder die mehreren Schaltung(s) 2630A bis 2630B können der Datenkreuzschiene 240 aus 2C entsprechen. Weitere Entsprechungen können zwischen analogen Komponenten des Grafikprozessors 2610 und den verschiedenen hierin beschriebenen Grafikprozessorarchitekturen gefunden werden.
  • Wie in 26B dargestellt ist, umfasst der Grafikprozessor 2640 die eine oder mehrere MMU(s) 2620A bis 2620B, den/die Cache(s) 2625A bis 2625B und der/die Schaltungsinterconnect(s) 2630A bis 2630B des Grafikprozessors 2610 aus 26A. Der Grafikprozessor 2640 umfasst einen oder mehrere Shader-Kerne 2655A bis 2655N (z. B. 2655A, 2655B, 2655C, 2655D, 2655E, 2655F bis 2655N-1 und 2655N), die eine einheitliche Shader-Kern-Architektur bereitstellen, bei der ein einziger Kern oder Typ oder Kern alle Arten von programmierbarem Shader-Code ausführen kann, unter anderem Shader-Programmcode zur Umsetzung von Vertex-Shadern, Fragment-Shadern und/oder Rechner-Shadern. Die genaue Anzahl von vorhandenen Shaderkernen kann zwischen verschiedenen Ausführungsformen und Umsetzungen variieren. Zusätzlich umfasst der Grafikprozessor 2640 einen Inter-Core-Task-Manager 2645, der als Thread-Dispatcher wirkt, um Ausführungs-Threads an einen oder mehrere Shader-Kerne 2655A bis 2655N zu verteilen, sowie eine Tiling-Einheit 2658 zur Beschleunigung von Tiling-Operationen für das kachelbasierte Rendering, bei dem Rendering-Operationen für eine Szene im Bildraum unterteilt werden, um beispielsweise die lokale räumliche Kohärenz innerhalb einer Szene auszunutzen oder die Nutzung interner Caches zu optimieren. Die Shader-Kerne 2655A bis 2655N können z. B. mit dem Grafikmultiprozessor 234 wie in 2D- oder Grafikmultiprozessoren 325, 350 aus 3A bzw. 3B, oder die Multi-Core-Gruppe 365A aus 3C.
  • Freigabe der Taskkurve an die Speicherhierarchie
  • Eine Taskkurve ist eine Menge von Vertizes und gerichteten Kanten. Jeder Knoten entspricht einer Berechnung, und jede Kante stellt eine Abhängigkeit dar; Abhängigkeiten sind meist Datenabhängigkeiten (z. B. ist die Ausgabe einer Berechnung die Eingabe einer anderen). In einigen Beispielen werden einige keine
  • Neuronale Netze können als Taskkurve illustriert werden, und dies wird in einigen populären Deep-Learning-Frameworks, z. B. TensorFlow, getan. Jeder Vertex kann eine Berechnung mit vielen möglichen Berechnungsgranularitäten darstellen. Ein Vertex könnte beispielsweise etwas Grobkörniges darstellen, wie die Vorwärtspropagierung einer ganzen Schicht in einem neuronalen Netzwerk, oder er könnte etwas Feinkörnigeres darstellen, wie eine Datentypkonvertierung eines einzelnen Datenpunkts. Grobkörnigere Vertizes sind einfacher, stellen aber potenziell weniger Parallelität für die Hardware zur Verfügung.
  • Eine Taskkurve hat viele mögliche Darstellungen, und in einigen Beispielen kann die Software eine ganze Kurve auf einmal oder nur ein Stück auf einmal bereitstellen. Unabhängig davon besteht eine Kurve (oder Teilkurve) aus einer Menge von Vertizes und einer Menge von Kanten. Jeder Vertex ist eine Berechnung (z. B. eine Funktion oder ein Kernel) und die Parameter/Eingaben für diese Berechnung. Dies kann durch ein Tupel illustriert werden, z. B. (Funktionszeiger „x“, Integerwert 0, Datenzeiger „y“). Dies ist ein recht gängiges Konstrukt, z. B. in Task-Stealing-Systemen, wie Intels TBB. Jede Kante besteht aus einem Quell- und einem Zielvertex und kann daher durch ein (Quell-, Ziel-) Paar von Indizes, Zeigern usw. illustriert werden.
  • Software kann einen Bibliotheksaufruf tätigen, um eine Taskkurve (oder Teilkurve) an die Hardware zu übermitteln. Je nachdem, was die Hardware mit der Kurve macht, kann der Gerätetreiber oder die Laufzeitumgebung dei gesamte Kurve an die Hardware übermitteln (z. B. die Informationen an einen bestimmten, vorher festgelegten Ort kopieren oder die Adresse bereitstellen, an der die Kurve im Grafikspeicher gespeichert ist), oder er kann die Kurve in Untergraphen aufteilen und jeweils nur einen Abschnitt übermitteln. Beispielsweise könnte für jeden Vertex in der Kurve ein Kernel für die GPU in die Warteschlange gestellt werden, der ausgeführt werden soll, und es könnte auch ein Satz von Zielvertex-IDs für diese Aufgabe übergeben werden, was eine Erweiterung des bereits vorhandenen Kernel-Deskriptors wäre.
  • Eine Taskkurve legt Parallelität/Abhängigkeiten und Kommunikation offen. In unserem einfachsten Fall, in dem die Software die Ziel-IDs für jeden Task übermittelt, könnte die Hardware verfolgen, welcher Abschnitt einer GPU (z. B. welche Ausführungseinheit oder SM) für die Ausführung des Ziels/der Ziele zugewiesen ist, und die Ausgabedaten unseres Aufgaben vorbeugend in die Nähe des Ziels kopieren. Dies könnte ein LI-Cache für eine bestimmte SM sein oder ein gemeinsam genutzter Cache in der Nähe des Ziels.
  • In einigen Ausführungsformen könnte die Hardware mehr mit den Informationen machen. Beispielsweise könnte es eine Ziel-Task der gleichen Hardware-Einheit zuweisen wie die Quelle, sodass das Kopieren von Daten entfällt (oder zumindest verringert wird, wenn wir mehrere Ziele haben).
  • 27 ist eine schematische Illustration einer Matrixmultiplikationsoperation, nach einigen Ausführungsformen. Mit Verweis auf 27 kann in einigen Beispielen eine Softwareschnittstelle erweitert werden, um es einer Anwendung zu ermöglichen, Datenabhängigkeiten über verschiedene Aufgaben hinweg auszudrücken. Die Systemhardware weiß, wo Aufgaben eingeplant sind und verschiebt die Ausgabe von „Producer“-Aufgaben (z. B. 2710, 2715) in den Cache von „Consumer“-Aufgaben (z. B. 2720). In einigen Beispielen können Daten von Erzeugeraufgaben 2710, 2715 in einen Cache 2725 eingegeben werden, der kommunikativ mit Verbraucheraufgabe 2720 gekoppelt ist.
  • KontextabhängigerPrädiktor zur Steuerung von Vorabrufen und Cacheability
  • 28 ist eine schematische Illustration eines kontextabhängigen Prädiktors 2800 nach den hierin beschriebenen Ausführungsformen. Mit Verweis auf 28 zeigen einige Anwendungen ein pseudozufälliges Muster bei der Ausführung von Speicherzugriffen, was es schwierig machen kann, Heuristiken zur Steuerung der Hardware im Speichersystem effektiv zu umsetzen. Um beispielsweise sinnvolle Entscheidungen darüber zu treffen, ob eine bestimmte Zeile in den Cache gelegt oder die Seite, auf der sie sich befindet, migriert werden soll, muss man genau vorhersagen können, ob auf diese Cache-Zeile in naher Zukunft wieder zugegriffen werden wird. Die meisten Heuristiken stützen sich auf eine historische Abfolge von Adressen (z. B. Cache-Zeilenadressen oder Seitenadressen), um die Zukunft vorherzusagen. Diese Heuristiken umsetzen typischerweise einen sehr einfachen Satz von Regeln für die Entscheidungsfindung. So können z. B. die N zuletzt aufgerufenen Seiten verfolgt werden, wobei davon ausgegangen wird, dass diese Seiten wahrscheinlich in naher Zukunft erneut aufgerufen werden.
  • Wenn keine genauen Vorhersagen gemacht werden können, kann die Effizienz innerhalb des Speichersystems verringert werden. So kann zum Beispiel unnötigerweise eine Kopie von Daten, die nie wieder angefasst werden, in kostbarem Hochgeschwindigkeitsspeicher in der Nähe einer Rechner Engine gespeichert werden. Außerdem muss der für diese Kopie benötigte Platz durch das Verdrängen von etwas anderem, das vielleicht nützlich ist, geschaffen werden.
  • Während sich einige Algorithmen von Natur aus für sehr „regelmäßige“ Zugriffsmuster eignen (z. B. ein Strom aufeinanderfolgender Adressen), die sich mit einfachen Heuristiken leicht vorhersagen lassen, erzeugen einige von Natur aus „unregelmäßige“ Zugriffsmuster.
  • Eine Klasse von Deep-Learning-Algorithmen, die zu unregelmäßigen Zugriffen führt, ist als Embeddings 2812 bekannt. Diese sind eine Möglichkeit, sehr spärliche Daten auf dichte Vektoren abzubilden, die dann typischerweise in ein neuronales Netzwerk 2820 wie z. B. ein mehrschichtiges Perceptron (MLP) eingespeist werden.
  • Einbettungen werden häufig in der Sprachverarbeitung und in Empfehlungssystemen verwendet, z. B. um einzelne Wörter auf kurze Vektoren von Fließkommawerten abzubilden, sodass verwandte Wörter (z. B. „Mutter“ und „Vater“) einen geringen Abstand zueinander haben. Während eines Vorwärtsdurchlaufs durch die Einbettungen kann ein gegebener Eingabewert in einer oder mehreren Tabellen nachgeschlagen werden, und die entsprechenden Tabelleneinträge können abgerufen werden. Dies ist einem Satz von Hash-Tabellen-Lookups sehr ähnlich. Ähnlich wie bei Hash-Tabellen-Lookups kann eine Steuerung für einen gegebenen Strom von Eingaben einen Strom von (absichtlich) nicht zusammenhängenden Tabelleneinträgen abrufen; das Zugriffsmuster ist von vornherein pseudozufällig.
  • Während bestehende Heuristiken nicht erfolgreich sind, um gute Entscheidungen über unregelmäßige Zugriffsmuster zu treffen, sind neuronale Netzwerke ein alternatives Verfahren, das eingesetzt werden kann. Sie sind oft erfolgreich beim Erkennen von Mustern, selbst in scheinbar zufälligen Eingabeströmen.
  • Außerdem gibt es eine Klasse von neuronalen Netzen, die manchmal besonders schwierige Fälle bewältigen können: kontextbewusste Netze. Kontextabhängige Netzwerke nehmen entweder als Eingabe oder finden selbst in einem separaten Abschnitt des Netzwerks einige kontextabhängige Informationen über die Eingabe heraus. Diese Kontextinformationen sind dann ein zusätzlicher Input für das Netzwerk, der die Ausgabe unterstützen kann. Wenn wir z. B. ein Spracherkennungsnetzwerk haben, das mehrere Sprachen verarbeiten kann, kann es ein bestimmtes Sprachsegment viel besser erkennen, wenn es zuerst bestimmen kann, welche Sprache die Sprache ist (oder gesagt wird).
  • In einigen Beispielen kann ein neuronales Netzwerk (das ein kontextabhängiges neuronales Netzwerk sein kann, aber nicht unbedingt sein muss) zu einem System hinzugefügt werden, das eine Arbeitslast ausführt, die Einbettungen umfasst. Die Einbettungsausgabe wird in dieses Vorhersagenetzwerk eingespeist, um Empfehlungen für die Hardware auszusprechen.
  • Einbettungen werden oft in Systemen verwendet, in denen wir einige kontextbezogene Informationen haben. Beispielsweise nehmen Empfehlungssysteme klassischerweise Benutzerinformationen und einen gewissen Kontext auf (z. B. „der Benutzer besucht die Webseite X“) und geben auf der Grundlage dieser Informationen Empfehlungen ab, z. B. welche Werbung dem Benutzer angezeigt werden soll, um die Wahrscheinlichkeit zu maximieren, dass er darauf klickt. Daher kann es einige oder alle dieser Kontextinformationen als einen seiner Eingänge an ein kontextabhängiges Netzwerk weitergeben.
  • Ein neues neuronales Netz kann rein in Hardware umgesetzt sein oder eine Mischung aus Hardware und Software darstellen. Beispielsweise kann ein programmierbarer Beschleuniger für neuronale Netze in einen Prozessor eingebaut werden, und der Gerätetreiber oder eine andere Systemsoftware kann ein Programm mit einem vortrainierten Netz umfassen, das auf diesem Beschleuniger läuft. Benutzeranwendungen können Aufrufe an eine API umfassen, um dem Gerätetreiber oder der Systemsoftware anzuzeigen, dass sie Einbettungs-Lookups ausführen, sodass einige/alle der Ein- und Ausgänge an den Beschleuniger übergeben werden können. Alternativ könnte die Hardware versuchen zu erkennen, dass eine Anwendung Einbettungs-Lookups ausführt und die erkannten Ein-/Ausgänge völlig automatisch an den Beschleuniger weitergeben.
  • In einigen Ausführungsformen können die Vorhersagen des neuronalen Netzes verwendet werden, um Aspekte des Speicher-Subsystems zu steuern. Zwei konkrete Beispiele sind Richtlinien für das Kopieren von Seiten und die Cache-Verwaltung.
  • Wenn ein Beschleuniger wie ein Grafikprozessor eine Seite im Systemspeicher (und nicht im GPU-Speicher) berührt, muss die Hardware und/oder Systemsoftware entscheiden, ob diese Seite in den GPU-Speicher kopiert werden soll. Wenn eine Seite in naher Zukunft erneut bearbeitet wird, führt dies zu schnelleren zukünftigen Zugriffen. Wenn die Seite in naher Zukunft oft genug angefasst wird, kann dies auch Bandbreite zwischen Systemspeicher und GPU einsparen, da sonst alle diese Zugriffe zu Datenverkehr zwischen Systemspeicher und GPU führen würden. Wenn die Seite jedoch in naher Zukunft nicht oft genug angefasst wird, kann durch das Kopieren der Seite in den GPU-Speicher mehr Bandbreite verbraucht werden (da wir die gesamte Seite lesen müssen, um sie zu kopieren), als dies bei einem kleinen (z. B. 64 B) Zugriff der Fall wäre. Außerdem hängt die optimale Entscheidung davon ab, welche Daten aus dem GPU-Speicher verdrängt werden, um Platz für die neue Seite zu schaffen.
  • Ähnlich verhält es sich, wenn ein Prozessor (oder Beschleuniger) eine Cache-Hierarchie hat. Wenn er auf Daten zugreift, die sich nicht in einer bestimmten Ebene dieser Hierarchie befinden, kann er die Wahl haben, ob er die Daten in den Cache einfügt oder nicht. Die Kompromisse sind ähnlich wie die Frage der Seitenplatzierung. In Caches kann ein Controller jedoch manchmal auch die Möglichkeit haben, zukünftige Entscheidungen darüber zu beeinflussen, welche Daten zu evakuieren sind (d. h. die Ersetzungsrichtlinie). Wenn eine Steuerung also entscheidet, ob die Daten in einen bestimmten Cache eingefügt werden sollen, kann sie auch entscheiden, wie einige Metadaten, die mit dieser Zeile verknüpft sind und sich auf die Ersetzungsrichtlinie beziehen, gesetzt werden sollen. Es kann z. B. beschließen, eine Cache-Zeile einzufügen, sie aber (fälschlicherweise) als „am wenigsten verwendete“ Zeile markieren, sodass sie als nächstes aus diesem Satz im Cache verdrängt wird.
  • Hardwarebasierter Daten-Vorabruf
  • Die derzeitige GPU-Vorabruf-Technologie basiert auf Software (d. h. Load-Hailing). Es gibt Fälle, in denen die Software die Adresse nicht im Voraus berechnen kann, um den WOD zu heben (d. h. Vorabruf), um die Latenz zu verbergen. In diesen Fällen wird ein Hardware-Prefetcher benötigt, um den Vorabruf einzuleiten. Diese Einheit kann sich entweder in der EU (Ausführungseinheit) oder LSC (Load Store Cache) oder in der nächsten Hierarchieebene befinden.
  • 29 ist ein Ablaufdiagramm zur Illustration von Operationen, die durch einen hardwarebasierten Prefetcher 2900 nach hierin beschriebenen Ausführungsformen umgesetzt sind. Mit Verweis auf 29 umgesetzt der Prefetcher 2900 in einigen Beispielen Anweisungen 2910 zum Überwachen von Lade-/Speicheroperationen, Anweisungen 2915 zum Erlernen von Vorabrufschritten, Anweisungen 2920 zum Festlegen eines Konfidenzniveaus und Anweisungen 2925 zum Einleiten von Vorabrufsoperationen.
  • Im Folgenden finden Sie illustrative Beispiele für die hier offengelegten Technologien. Eine Ausführungsform der Technologien kann eines oder mehrere und eine beliebige Kombination der nachfolgend beschriebenen Beispiele umfassen.
  • Beispiel 1 umfasst eine Vorrichtung, die mehrere Verarbeitungsressourcen, die eine erste Verarbeitungsressource und eine zweite Verarbeitungsressource umfassen,
    einen Speicher, der kommunikativ mit der ersten Verarbeitungsressource und der zweiten Verarbeitungsressource gekoppelt ist; und einen Prozessor zum Empfangen von Datenabhängigkeiten für eine oder mehrere Aufgaben, die eine oder mehrere Erzeugeraufgaben, die auf der ersten Verarbeitungsressource ausgeführt werden, und eine oder mehrere Verbraucheraufgaben, die auf der zweiten Verarbeitungsressource ausgeführt werden, umfassen, und eine Datenausgabe von einer oder mehreren Erzeugeraufgaben, die auf der ersten Verarbeitungsressource ausgeführt werden, zu einem kommunikativ mit der zweiten Verarbeitungsressource gekoppelten Cache-Speicher zu bewegen, umfasst.
  • Beispiel 2 umfasst den Inhalt von Beispiel 1, wobei die eine oder die mehreren Aufgaben in einer Taskkurve als Aufgaben illustriert werden, die durch eine Kante verbunden sind.
  • Beispiel 3 umfasst den Inhalt aus einem der Beispiele 1 bis 2, wobei der Prozessor die eine oder mehrere Aufgaben auf die mehreren Verarbeitungsressourcen abbildet.
  • Beispiel 4 umfasst den Inhalt aus einem der Beispiele 1 bis 3, wobei der Prozessor einen Kernel zur Ausführung durch eine der mehreren Verarbeitungsressourcen in die Warteschlange stellt.
  • Beispiel 5 umfasst den Inhalt eines der Beispiele 1 bis 4, wobei der Prozessor eine oder mehrere Zielkennungen für die eine oder die mehreren Aufgaben an die mehreren Verarbeitungsressourcen weitergibt.
  • Beispiel 6 umfasst den Inhalt aus einem der Beispiele 1 bis 5, wobei der Cache-Speicher einen L1-Cache umfasst.
  • Beispiel 7 umfasst den Inhalt aus einem der Beispiele 1 bis 6, wobei der L1-Cache von mehreren Verarbeitungsressourcen gemeinsam genutzt wird.
  • Beispiel 8 umfasst ein prozessorumgesetztes Verfahren, das das Empfangen von Datenabhängigkeiten für eine oder mehrere Aufgaben, die eine oder mehrere Erzeugeraufgaben, die auf einer ersten Verarbeitungsressource ausgeführt werden, und eine oder mehrere Verbraucheraufgaben, die auf einer zweiten Verarbeitungsressource ausgeführt werden, umfassen, und eine Datenausgabe von einer oder mehreren Erzeugeraufgaben, die auf der ersten Verarbeitungsressource ausgeführt werden, zu einem kommunikativ mit der zweiten Verarbeitungsressource gekoppelten Cache-Speicher zu bewegen, umfasst.
  • Beispiel 9 umfasst den Inhalt von Beispiel 8, wobei die eine oder die mehreren Aufgaben in einer Taskkurve als Aufgaben illustriert werden, die durch eine Kante verbunden sind.
  • Beispiel 10 umfasst den Inhalt aus einem der Beispiele 8 bis 9, fener umfassend das Zuordnen der einen oder mehreren Aufgaben auf die mehreren Verarbeitungsressourcen abbildet.
  • Beispiel 11 umfasst den Inhalt aus einem der Beispiele 8 bis 10, fenrer umfassend das Einstellen eines Kernels in eine Warteschlange zur Ausführung durch eine der mehreren Verarbeitungsressourcen.
  • Beispiel 12 umfasst den Inhalt eines der Beispiele 8 bis 11, ferner umfassend das Weitergeben einer oder mehrerer Zielkennungen für die eine oder mehrere Aufgaben an die mehreren Verarbeitungsressourcen.
  • Beispiel 13 umfasst den Inhalt aus einem der Beispiele 8 bis 12, wobei der Cache-Speicher einen L1-Cache umfasst.
  • Beispiel 14 umfasst den Inhalt aus einem der Beispiele 8 bis 13, wobei der L1-Cache von mehreren Verarbeitungsressourcen gemeinsam genutzt wird.
  • Beispiel 15 umfasst ein nicht-transitorisches computerlesbares Medium, das eine oder mehrere Anweisungen umfasst, die, wenn sie auf mindestens einem Prozessor ausgeführt werden, den mindestens einen Prozessor so konfigurieren, Datenabhängigkeiten für eine oder mehrere Aufgaben, die eine oder mehrere Erzeugeraufgaben, die auf einer ersten Verarbeitungsressource ausgeführt werden, und eine oder mehrere Verbraucheraufgaben, die auf einer zweiten Verarbeitungsressource ausgeführt werden, in einem Prozessor zu empfangen und eine Datenausgabe von einer oder mehreren Erzeugeraufgaben, die auf der ersten Verarbeitungsressource ausgeführt werden, zu einem kommunikativ mit der zweiten Verarbeitungsressource gekoppelten Cache-Speicher zu bewegen.
  • Beispiel 16 umfasst den Inhalt von Beispiel 15, wobei die eine oder die mehreren Aufgaben in einer Taskkurve als Aufgaben illustriert werden, die durch eine Kante verbunden sind.
  • Beispiel 17 umfasst den Inhalt eines der Beispiele 15 bis 16, wobei Befehle gespeichert werden, die bei Ausführung durch einen oder mehrere Prozessoren den einen oder die mehreren Prozessoren veranlassen, die eine oder die mehreren Aufgaben mehreren Verarbeitungsressourcen zuzuordnen.
  • Beispiel 18 umfasst den Inhalt eines der Beispiele 15 bis 17, der Anweisungen speichert, die, wenn sie von einem oder mehreren Prozessoren ausgeführt werden, den einen oder die mehreren Prozessoren veranlassen, einen Kernel zur Ausführung durch eine der mehreren Verarbeitungsressourcen in die Warteschlange zu stellen.
  • Beispiel 19 umfasst den Inhalt aus einem der Beispiele 15 bis 18, umfassend das Speichern von Anweisungen, die, wenn sie von einem oder mehreren Prozessoren ausgeführt werden, den einen oder die mehreren Prozessoren veranlassen, einen oder mehrere Zielidentifikatoren für die eine oder die mehreren Aufgaben an die mehreren Verarbeitungsressourcen weiterzuleiten.
  • Beispiel 20 umfasst den Inhalt aus einem der Beispiele 15 bis 19, wobei der Cache-Speicher einen L1 -Cache umfasst.
  • Beispiel 21 umfasst den Inhalt aus einem der Beispiele 15 bis 20, wobei der L1-Cache von mehreren Verarbeitungsressourcen gemeinsam genutzt wird.
  • Beispiel 22 ist eine Vorrichtung, die mehrere Verarbeitungsressourcen umfasst, unter anderem eine erste Verarbeitungsressource und eine zweite Verarbeitungsressource; einen Speicher, der kommunikativ mit der ersten Verarbeitungsressource und der zweiten Verarbeitungsressource gekoppelt ist; und einen Prozessor, um eine oder mehrere Einbettungen in ein kontextbewusstes neuronales Netzwerk zu empfangen; und eine Hardware-Vorhersage unter Verwendung der einen oder mehreren Einbettungen zu erzeugen
  • Beispiel 23 umfasst den Inhalt von Beispiel 22, wobei die Einbettung dem kontextbewussten neuronalen Netzwerk kontextbezogene Informationen zur Verfügung stellt.
  • Beispiel 24 umfasst den Inhalt eines der Beispiele 21 bis 22, wobei der Prozessor eine Cache-Operation in Reaktion auf eine oder mehrere Einbettungen umgeht.
  • Beispiel 25 ist eine Vorrichtung mit mehreren Verarbeitungsressourcen, unter anderem eine erste Verarbeitungsressource und eine zweite Verarbeitungsressource; einem Speicher, der kommunikativ mit der ersten Verarbeitungsressource und der zweiten Verarbeitungsressource gekoppelt ist; und einem Prozessor zum Überwachen von Lade-/Speicheroperationen; Lernen eines oder mehrerer Vorabruf-Strides; Festlegen eines Vertrauensniveaus; und Einleiten von Vorabrufsoperationen.
  • Die obige detaillierte Beschreibung umfasst Verweise auf die begleitenden Zeichnungen, die einen Abschnitt der detaillierten Beschreibung bilden. Die Zeichnungen zeigen illustrative bestimmte Ausführungsformen, die ausgeführt werden können. Diese Ausführungsformen werden hier auch als „Beispiele“ bezeichnet Solche Beispiele können zusätzlich zu den dargestellten oder beschriebenen Elementen weitere Elemente umfassen. Es sind jedoch auch Beispiele vorstellbar, die die dargestellten oder beschriebenen Elemente umfassen. Außerdem sind auch Beispiele vorstellbar, bei denen eine beliebige Kombination oder Permutation der dargestellten oder beschriebenen Elemente (oder eines oder mehrerer Aspekte davon) verwendet wird, entweder in Bezug auf ein bestimmtes Beispiel (oder einen oder mehrere Aspekte davon) oder in Bezug auf andere hier dargestellte oder beschriebene Beispiele (oder einen oder mehrere Aspekte davon).
  • Veröffentlichungen, Patente und Patentdokumente, auf die in diesem Dokument Bezug genommen wird, sind in ihrer Gesamtheit in dieses Dokument aufgenommen, als ob sie einzeln durch Bezugnahme aufgenommen würden. Bei widersprüchlichen Verwendungen zwischen diesem Dokument und den durch Verweis einbezogenen Dokumenten gilt die Verwendung in den einbezogenen Verweisen ergänzend zu derjenigen in diesem Dokument; bei nicht zu beseitigenden Widersprüchen gilt die Verwendung in diesem Dokument.
  • In diesem Dokument werden die Begriffe „ein“ oder „eine“, wie in Patentdokumenten üblich, verwendet, um einen oder mehr als einen einzuschließen, unabhängig von allen anderen Instanzen oder Verwendungen von „mindestens ein/e“ oder „ein/e oder mehrere“ Außerdem umfasst „eine Menge von“ ein oder mehrere Elemente. In diesem Dokument wird der Begriff „oder“ als nicht ausschließendes oder verwendet, sodass „A oder B“ „A aber nicht B“, „B aber nicht A“ und „A und B“ umfasst, sofern nicht anders angegeben. In den beiligenden Ansprüchen werden die Ausdrücke „unter anderem“ und „in denen“ als einfache englische Entsprechungen der jeweiligen Begriffe „umfassend“ und „wobei“ verwendet Außerdem sind die Begriffe „unter anderem“ und „umfassend“ in den folgenden Ansprüchen offen formuliert, d. h. ein System, eine Vorrichtung, ein Artikel oder ein Verfahren, der/die/das Elemente zusätzlich zu den nach einem solchen Begriff in einem Anspruch aufgeführten Elementen umfasst, fällt dennoch in den Anwendungsbereich dieses Anspruchs. Außerdem werden in den folgenden Ansprüchen die Begriffe „erster“, „zweiter“, „dritter“ usw. lediglich als Bezeichnungen verwendet und sollen keine numerische Reihenfolge der Objekte suggerieren.
  • Der Begriff „Logikbefehle“ bezieht sich wie hierin verwendet auf Ausdrücke, die von einer oder mehreren Maschinen zur Ausführung einer oder mehrerer logischer Operationen verstanden werden können. Logikbefehle können z. B. Befehle umfassen, die von einem Prozessor-Compiler interpretierbar sind, um eine oder mehrere Operationen auf einem oder mehreren Datenobjekten auszuführen. Dies ist jedoch nur ein Beispiel für maschinenlesbare Anweisungen und die Beispiele sind in dieser Hinsicht nicht beschränkt.
  • Der Begriff „computerlesbares Medium“, auf den hier Bezug genommen wird, bezieht sich auf Medien, die in der Lage sind, Ausdrücke zu speichern, die von einer oder mehreren Maschinen wahrnehmbar sind. Ein computerlesbares Medium kann z. B. ein oder mehrere Speichervorrichtungen zum Speichern von computerlesbaren Anweisungen oder Daten umfassen. Solche Speichervorrichtungen können Speichermedien wie z. B. optische, magnetische oder Halbleiter-Speichermedien umfassen. Dies ist jedoch nur ein Beispiel für ein computerlesbares Medium und die Beispiele sind in dieser Hinsicht nicht beschränkt.
  • Der hier verwendete Begriff „Logik“ bezieht sich auf eine Struktur zur Ausführung einer oder mehrerer logischer Operationen. Die Logik kann z. B. eine Schaltungsanordnung umfassen, die ein oder mehrere Ausgangssignale auf der Grundlage eines oder mehrerer Eingangssignale liefert. Eine solche Schaltungsanordnung kann eine Finite-State-Maschine umfassen, die einen digitalen Eingang empfängt und einen digitalen Ausgang bereitstellt, oder eine Schaltungsanordnung, die ein oder mehrere analoge Ausgangssignale in Reaktion auf ein oder mehrere analoge Eingangssignale bereitstellt. Eine solche Schaltungsanordnung kann in einer anwendungsspezifisch integrierten Schaltung (ASIC) oder einem feldprogrammierbaren Gate-Array (FPGA) bereitgestellt sein. Die Logik kann auch maschinenlesbare Befehle umfassen, die in einem Speicher gespeichert sind, in Kombination mit einer Verarbeitungsschaltungsanordnung zur Ausführung dieser maschinenlesbaren Befehle. Dies sind jedoch nur Beispiele für Strukturen, die eine Logik liefern können, und die Beispiele sind in dieser Hinsicht nicht beschränkt.
  • Einige der hierin beschriebenen Verfahren können als logische Anweisungen auf einem computerlesbaren Medium verkörpert sein. Bei der Ausführung auf einem Prozessor bewirken die Logikbefehle, dass ein Prozessor als Spezialmaschine programmiert wird, die die beschriebenen Verfahren umgesetzt. Der Prozessor stellt, wenn er durch die Logikbefehle zur Ausführung der hierin beschriebenen Verfahren konfiguriert ist, eine Struktur zur Ausführung der beschriebenen Verfahren dar. Alternativ können die hierin beschriebenen Verfahren auf die Logik verringert werden, z. B. auf ein Field Programmable Gate Array (FPGA), eine anwendungsspezifische integrierte Schaltung (ASIC) oder ähnliches.
  • In der Beschreibung und den Ansprüchen können die Begriffe gekoppelt und verbunden sowie deren Ableitungen verwendet werden. In besonderen Beispielen kann der Begriff verbunden verwendet werden, um anzuzeigen, dass zwei oder mehr Elemente in direktem physischen oder elektrischen Kontakt miteinander stehen. Gekoppelt kann bedeuten, dass zwei oder mehr Elemente in direktem physikalischen oder elektrischen Kontakt stehen. Gekoppelt kann aber auch bedeuten, dass zwei oder mehr Elemente nicht direkt in Kontakt miteinander stehen, aber dennoch zusammenarbeiten oder miteinander interagieren können.
  • Ein Verweis in der Spezifikation auf „ein Beispiel“ oder „einige Beispiele“ bedeutet, dass ein bestimmtes Merkmal, eine bestimmte Struktur oder eine bestimmte Eigenschaft, die im Zusammenhang mit dem Beispiel beschrieben wird, in mindestens einer Umsetzung umfassen ist. Das Auftreten des Ausdrucks „in einem Beispiel“ an verschiedenen Stellen in der Spezifikation kann sich auf dasselbe Beispiel beziehen, muss es aber nicht.
  • Die obige Beschreibung soll illustrativ und nicht einschränkend sein. Beispielsweise können die oben beschriebenen Beispiele (oder ein oder mehrere Aspekte davon) in Kombination mit anderen verwendet werden. Andere Ausführungsformen können verwendet werden, wie von einem Fachmann auf dem Gebiet nach Durchsicht der obigen Beschreibung festgestellt werden kann. Die Zusammenfassung soll es dem Leser ermöglichen, die Art der technischen Offenbarung schnell zu erfassen. Sie wird mit dem Verständnis vorgelegt, dass sie nicht verwendet wird, um den Umfang oder die Bedeutung der Ansprüche auszulegen oder einzuschränken. Außerdem können in der obigen detaillierten Beschreibung verschiedene Merkmale gruppiert sein, um die Offenbarung zu verschlanken. Die Ansprüche sind jedoch möglicherweise nicht für jedes hierin offenbarte Merkmal dargelegt, da Ausführungsformen einen Untersatz der Merkmale aufweisen können. Ferner können Ausführungsformen weniger Merkmale umfassen als in einem bestimmten Beispiel offenbart sind. Daher werden die folgenden Ansprüche hiermit in die ausführliche Beschreibung aufgenommen, wobei jeder Anspruch für sich allein als separate Ausführungsform steht. Der Umfang der hier offengelegten Ausführungsformen ist mit Verweis auf die beigefügten Ansprüche zu bestimmen, zusammen mit dem vollen Umfang der Äquivalente, auf die diese Ansprüche Anspruch haben.
  • Obwohl die Beispiele in mit Bezeichnungen beschrieben wurden, die spezifisch für strukturelle Merkmale und/oder methodische Handlungen sind, ist zu verstehen, dass der beanspruchte Gegenstand nicht auf die beschriebenen spezifischen Merkmale oder Handlungen beschränkt sein kann. Stattdessen sind die spezifischen offenbarten Merkmale und Handlungen als Beispielformen der Umsetzung des beanspruchten Inhalts offenbart.
  • Die vorstehende Beschreibung und die Zeichnungen sind eher illustrativ als einschränkend zu verstehen. Fachleute auf dem Gebiet verstehen, dass verscheiden Modifikationen und Änderungen an den hierin beschriebenen Ausführungsformen ohne Abweichung von dem breiteren Geist und Umfang dieser Erfindung, wie in den beiliegenden Ansprüchen festgelegt, vorgenommen werden.
  • Ausführungsformen können z. B. als Computerprogrammprodukt bereitgestellt werden, das ein oder mehrere maschinenlesbare Medien mit darauf gespeicherten maschinenausführbaren Befehlen umfassen kann, die bei Ausführung durch eine oder mehrere Maschinen, wie z. B. einen Computer, ein Computernetzwerk oder andere elektronische Vorrichtungen, dazu führen können, dass die eine oder die mehreren Maschinen Vorgänge in Übereinstimmung mit den hierin beschriebenen Ausführungsformen ausführen. Ein maschinenlesbares Medium kann Floppy-Disketten, optische Disketten, CD-ROMs (Compact Disc-Read Only Memories) und magnetooptische Disketten, ROMs, RAMs, EPROMs (Erasable Programmable Read Only Memories), EEPROMs (Electrically Erasable Programmable Read Only Memories), magnetische oder optische Karten, Flash-Speicher oder andere Arten von Medien/maschinenlesbaren Medien umfassen, die zum Speichern von maschinenausführbaren Befehlen geeignet sind, ist aber nicht darauf beschränkt.
  • Außerdem können Ausführungsformen als Computerprogrammprodukt heruntergeladen werden, wobei das Programm von einem entfernten Computer (z. B. einem Server) zu einem anfordernden Computer (z. B. einem Client) mittels eines oder mehrerer Datensignale, die in einer Trägerwelle oder einem anderen Ausbreitungsmedium verkörpert und/oder durch diese moduliert sind, über eine Kommunikationsverbindung (z. B. ein Modem und/oder eine Netzwerkverbindung) übertragen werden kann.
  • Fachleute auf dem Gebiet erkennen, aus der vorhergehenden Beschreibung, dass die breiten Techniken der Ausführungsformen in einer Vielzahl von Formen umgesetzt werden können. Daher wurden zwar die Ausführungsformen mit bestimmten Beispielen davon beschrieben, der wahre Umfang der Ausführungsformen sollte jedoch nicht so eingeschränkt sein, da andere Modifikationen dem Fachmann bei Betrachtung der Zeichnungen, Spezifikation und nachfolgenden Ansprüche offensichtlich werden.
  • Die vorstehende Beschreibung und die Zeichnungen sind eher illustrativ als einschränkend zu verstehen. Fachleute auf dem Gebiet verstehen, dass verschiedene Modifikationen und Änderungen an den hierin beschriebenen Ausführungsformen vorgenommen werden können, ohne von dem breiteren Geist und Umfang der in den beigefügten Ansprüchen dargelegten Merkmale abzuweichen.
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Patentliteratur
    • US 62/935716 [0001]

Claims (21)

  1. Vorrichtung, aufweisend: mehrere Verarbeitungsressourcen, aufweisend eine erste Verarbeitungsressource und eine zweite Verarbeitungsressource; einen Speicher, der kommunikativ mit der ersten Verarbeitungsressource und der zweiten Verarbeitungsressource gekoppelt ist; und einen Prozessor zum: Empfangen von Datenabhängigkeiten für eine oder mehrere Aufgaben, die eine oder mehrere Erzeugeraufgaben, die auf der ersten Verarbeitungsressource ausgeführt werden, und eine oder mehrere Verbraucheraufgaben, die auf der zweiten Verarbeitungsressource ausgeführt werden, umfassen; und Verschieben einer Datenausgabe von einer oder mehreren Erzeugeraufgaben, die auf der ersten Verarbeitungsressource ausgeführt werden, in einen Cache-Speicher, der kommunikativ mit der zweiten Verarbeitungsressource verbunden ist.
  2. Vorrichtung aus Anspruch 1, wobei die eine oder die mehreren Aufgaben in einer Taskkurve als Aufgaben illustriert werden, die durch eine Kante verbunden sind.
  3. Vorrichtung aus Anspruch 2, wobei der Prozessor dazu dient: die eine oder die mehreren Aufgaben auf mehrere Verarbeitungsressourcen abzubilden.
  4. Vorrichtung aus Anspruch 3, wobei der Prozessor dazu dient: einen Kernel zur Ausführung durch eine der mehreren Verarbeitungsressourcen in die Warteschlange zu stellen.
  5. Vorrichtung aus Anspruch 4, wobei der Prozessor dazu dient: eine oder mehrere Zielkennungen für die eine oder die mehreren Aufgaben an die mehreren Verarbeitungsressourcen weiterzugeben.
  6. Vorrichtung aus Anspruch 1, wobei der Cache-Speicher einen LI-Cache umfasst.
  7. Vorrichtung aus Anspruch 6, wobei der LI-Cache von mehreren Verarbeitungsressourcen gemeinsam genutzt wird.
  8. Computerumgesetztes Verfahren, umfassend: Empfangen von Datenabhängigkeiten für eine oder mehrere Aufgaben in einem Prozessor, die eine oder mehrere Erzeugeraufgaben, die auf einer ersten Verarbeitungsressource ausgeführt werden, und eine oder mehrere Verbraucheraufgaben, die auf einer zweiten Verarbeitungsressource ausgeführt werden, umfassen; und Verschieben einer Datenausgabe von einer oder mehreren Erzeugeraufgaben, die auf der ersten Verarbeitungsressource ausgeführt werden, in einen Cache-Speicher, der kommunikativ mit der zweiten Verarbeitungsressource verbunden ist.
  9. Verfahren aus Anspruch 8, wobei die eine oder die mehreren Aufgaben in einer Taskkurve als Aufgaben illustriert werden, die durch eine Kante verbunden sind.
  10. Verfahren aus Anspruch 9, umfassend: Abbilden der einen oder der mehreren Aufgaben auf die mehreren Verarbeitungsressourcen.
  11. Verfahren aus Anspruch 10, umfassend: Einstellen eines Kerns in die Warteschlange zur Ausführung durch eine der mehreren Verarbeitungsressourcen.
  12. Verfahren aus Anspruch 11, umfassend: Weitergeben von einer oder mehreren Zielkennungen für die eine oder die mehreren Aufgaben an die mehreren Verarbeitungsressourcen.
  13. Verfahren aus Anspruch 8, wobei der Cache-Speicher einen LI-Cache umfasst.
  14. Verfahren aus Anspruch 13, wobei der L1-Cache von mehreren Verarbeitungsressourcen gemeinsam genutzt wird.
  15. Nichttransitorisches, maschinenlesbares Medium, das Befehle speichert, die, wenn sie von einem oder mehreren Prozessoren ausgeführt werden, den einen oder die mehreren Prozessoren veranlassen: Datenabhängigkeiten für eine oder mehrere Aufgaben, die eine oder mehrere Erzeugeraufgaben, die auf einer ersten Verarbeitungsressource ausgeführt werden, und eine oder mehrere Verbraucheraufgaben, die auf einer zweiten Verarbeitungsressource ausgeführt werden, umfassen, in einem Prozessor zu empfangen; und eine Datenausgabe von einer oder mehreren Erzeugeraufgaben, die auf der ersten Verarbeitungsressource ausgeführt werden, in einen Cache-Speicher zu verschieben, der kommunikativ mit der zweiten Verarbeitungsressource verbunden ist.
  16. Nichttransitorisches maschinenlesbares Medium aus Anspruch 1, wobei die eine oder die mehreren Aufgaben in einer Taskkurve als Aufgaben illustriert werden, die durch eine Kante verbunden sind.
  17. Nichttransitorisches maschinenlesbares Medium aus Anspruch 16, das Befehle speichert, die, wenn sie von einem oder mehreren Prozessoren ausgeführt werden, den einen oder die mehreren Prozessoren veranlassen: die eine oder die mehreren Aufgaben auf mehrere Verarbeitungsressourcen abzubilden.
  18. Nichttransitorisches maschinenlesbares Medium aus Anspruch 17, das Befehle speichert, die, wenn sie von einem oder mehreren Prozessoren ausgeführt werden, den einen oder die mehreren Prozessoren veranlassen: einen Kernel zur Ausführung durch eine der mehreren Verarbeitungsressourcen in die Warteschlange zu stellen.
  19. Nichttransitorisches maschinenlesbares Medium aus Anspruch 18, das Befehle speichert, die, wenn sie von einem oder mehreren Prozessoren ausgeführt werden, den einen oder die mehreren Prozessoren veranlassen: eine oder mehrere Zielkennungen für die eine oder die mehreren Aufgaben an die mehreren Verarbeitungsressourcen weiterzugeben.
  20. Nichttransitorisches maschinenlesbares Medium aus Anspruch 15, wobei der Cache-Speicher einen L1 -Cache umfasst.
  21. Nichttransitorisches maschinenlesbares Medium aus Anspruch 20, wobei der L1-Cache von mehreren Verarbeitungsressourcen gemeinsam genutzt wird.
DE102020130073.5A 2019-11-15 2020-11-13 Verbesserung der datenlokalität für grafikprozessoreinheiten Pending DE102020130073A1 (de)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201962935716P 2019-11-15 2019-11-15
US62/935,716 2019-11-15
US17/095,585 2020-11-11
US17/095,585 US11726793B2 (en) 2019-11-15 2020-11-11 Data locality enhancement for graphics processing units

Publications (1)

Publication Number Publication Date
DE102020130073A1 true DE102020130073A1 (de) 2021-05-20

Family

ID=75683475

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102020130073.5A Pending DE102020130073A1 (de) 2019-11-15 2020-11-13 Verbesserung der datenlokalität für grafikprozessoreinheiten

Country Status (5)

Country Link
US (2) US11726793B2 (de)
JP (1) JP2021082285A (de)
KR (1) KR20210059649A (de)
CN (1) CN112819678A (de)
DE (1) DE102020130073A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11726793B2 (en) 2019-11-15 2023-08-15 Intel Corporation Data locality enhancement for graphics processing units

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11544113B2 (en) * 2019-11-20 2023-01-03 Google Llc Task scheduling for machine-learning workloads
US20220197651A1 (en) * 2020-12-22 2022-06-23 Intel Corporation Processing of data by multiple graphic processing devices
WO2022261652A1 (en) * 2021-06-10 2022-12-15 Sailion Inc. Method and system for distributed workload processing
WO2023285865A1 (en) * 2021-07-15 2023-01-19 Telefonaktiebolaget Lm Ericsson (Publ) Execution of a machine learning model by a system of resource nodes
US11947459B2 (en) * 2021-09-30 2024-04-02 Xilinx, Inc. Multipath memory with static or dynamic mapping to coherent or MMIO space
TWI786992B (zh) 2021-12-14 2022-12-11 國立清華大學 整合卷積神經網路運算電路的影像感測器
US11966590B2 (en) 2022-02-25 2024-04-23 Samsung Electronics Co., Ltd. Persistent memory with cache coherent interconnect interface
CN114756369B (zh) * 2022-04-19 2022-12-09 北京领为军融科技有限公司 利用c++编译器的cpu-gpu数据同步方法和装置
CN117193951A (zh) * 2022-05-30 2023-12-08 华为技术有限公司 调度装置、方法及相关设备
CN115840654B (zh) * 2023-01-30 2023-05-12 北京万里红科技有限公司 消息的处理方法、系统、计算设备及可读存储介质

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7873812B1 (en) 2004-04-05 2011-01-18 Tibet MIMAR Method and system for efficient matrix multiplication in a SIMD processor architecture
US10223333B2 (en) 2014-08-29 2019-03-05 Nvidia Corporation Performing multi-convolution operations in a parallel processing system
US9471501B2 (en) * 2014-09-26 2016-10-18 Intel Corporation Hardware apparatuses and methods to control access to a multiple bank data cache
US9733978B2 (en) * 2015-08-27 2017-08-15 Qualcomm Incorporated Data management for multiple processing units using data transfer costs
US10891538B2 (en) 2016-08-11 2021-01-12 Nvidia Corporation Sparse convolutional neural network accelerator
US10528864B2 (en) 2016-08-11 2020-01-07 Nvidia Corporation Sparse convolutional neural network accelerator
US11726793B2 (en) 2019-11-15 2023-08-15 Intel Corporation Data locality enhancement for graphics processing units

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11726793B2 (en) 2019-11-15 2023-08-15 Intel Corporation Data locality enhancement for graphics processing units

Also Published As

Publication number Publication date
US20230418617A1 (en) 2023-12-28
KR20210059649A (ko) 2021-05-25
CN112819678A (zh) 2021-05-18
US11726793B2 (en) 2023-08-15
JP2021082285A (ja) 2021-05-27
US20210149680A1 (en) 2021-05-20

Similar Documents

Publication Publication Date Title
CN110543332B (zh) 使用低精度和高精度的混合推理
DE112020000874T5 (de) Systeme und Methoden zum Aktualisieren von speicherseitigen Caches in einer Multi-GPU-Konfiguration
DE112020001249T5 (de) Dünnbesetzt-Optimierungen für eine Matrixbeschleunigerarchitektur
DE102020130078A1 (de) Systolische arithmetik an spärlichen daten
DE102020130073A1 (de) Verbesserung der datenlokalität für grafikprozessoreinheiten
KR20240017972A (ko) SoC 아키텍처의 분할
DE102020129970A1 (de) Systeme und verfahren zur fehlererkennung und steuerung für eingebettete arbeitsspeicher- und rechenelemente
DE102020129251A1 (de) Adaptives verformbares kernvorhersagenetzwerk zum bildentrauschen
CN116894762A (zh) 计算优化机制
DE102020129969A1 (de) Verbesserungen der verarbeitung und des caching von graphikverarbeitungseinheiten
DE112020000464T5 (de) Mehrfachkachel-grafikprozessor-rendering
DE102020107080A1 (de) Grafiksysteme und Verfahren zum Beschleunigen von Synchronisation mittels feinkörniger Abhängigkeitsprüfung und Planungsoptimierungen basierend auf verfügbarem gemeinsam genutztem Speicherplatz
DE112020000854T5 (de) Thread-gruppen-planung für die grafikverarbeitung
DE102020132272A1 (de) Verfahren und vorrichtung zum codieren basierend auf schattierungsraten
DE112020000848T5 (de) Skalarkernintegration
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
CN113495793A (zh) 用于缓冲器共享的方法和装置
DE102020130995A1 (de) Verfahren und vorrichtung zur codierung basierend auf wichtigkeitswerten
DE102022130536A1 (de) Sich selbst abstimmende thread-verteilungsrichtlinie
DE102022119733A1 (de) Sammeln von nutzdaten aus beliebigen registern für sende-nachrichten in einer grafikumgebung
DE102020130081A1 (de) Erweiterte prozessorfunktionen für berechnungen
DE112020000902T5 (de) Datenvorabruf für die grafikdatenverarbeitung
CN113424156A (zh) 用于利用队列和过渡存储以实现改善的低等待时间高带宽管芯上数据检取的系统和方法
CN115700722A (zh) 高效的压缩逐字复制