DE112020000846T5 - Architektur für Block-Sparse-Operationen an einem systolischen Array - Google Patents

Architektur für Block-Sparse-Operationen an einem systolischen Array Download PDF

Info

Publication number
DE112020000846T5
DE112020000846T5 DE112020000846.0T DE112020000846T DE112020000846T5 DE 112020000846 T5 DE112020000846 T5 DE 112020000846T5 DE 112020000846 T DE112020000846 T DE 112020000846T DE 112020000846 T5 DE112020000846 T5 DE 112020000846T5
Authority
DE
Germany
Prior art keywords
graphics
hardware
instruction
processor
instructions
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
DE112020000846.0T
Other languages
English (en)
Inventor
Abhishek Appu
Subramaniam Maiyuran
Mike MacPherson
Fangwen Fu
Jiasheng Chen
Varghese George
Vasanth Ranganathan
Ashutosh Garg
Joydeep Ray
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 DE112020000846T5 publication Critical patent/DE112020000846T5/de
Pending legal-status Critical Current

Links

Images

Classifications

    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/76—Architectures of general purpose stored program computers
    • G06F15/80—Architectures of general purpose stored program computers comprising an array of processing units with common control, e.g. single instruction multiple data processors
    • G06F15/8007—Architectures of general purpose stored program computers comprising an array of processing units with common control, e.g. single instruction multiple data processors single instruction multiple data [SIMD] multiprocessors
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/76—Architectures of general purpose stored program computers
    • G06F15/80—Architectures of general purpose stored program computers comprising an array of processing units with common control, e.g. single instruction multiple data processors
    • G06F15/8046—Systolic arrays
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F17/00—Digital computing or data processing equipment or methods, specially adapted for specific functions
    • G06F17/10—Complex mathematical operations
    • G06F17/16—Matrix or vector computation, e.g. matrix-matrix or matrix-vector multiplication, matrix factorization
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F7/00—Methods or arrangements for processing data by operating upon the order or content of the data handled
    • G06F7/38—Methods or arrangements for performing computations using exclusively denominational number representation, e.g. using binary, ternary, decimal representation
    • G06F7/48—Methods or arrangements for performing computations using exclusively denominational number representation, e.g. using binary, ternary, decimal representation using non-contact-making devices, e.g. tube, solid state device; using unspecified devices
    • G06F7/544—Methods or arrangements for performing computations using exclusively denominational number representation, e.g. using binary, ternary, decimal representation using non-contact-making devices, e.g. tube, solid state device; using unspecified devices for evaluating functions by calculation
    • G06F7/5443—Sum of products
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003—Arrangements for executing specific machine instructions
    • G06F9/30007—Arrangements for executing specific machine instructions to perform operations on data operands
    • G06F9/3001—Arithmetic instructions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003—Arrangements for executing specific machine instructions
    • G06F9/30007—Arrangements for executing specific machine instructions to perform operations on data operands
    • G06F9/30036—Instructions to perform operations on packed data, e.g. vector, tile or matrix operations
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30145—Instruction analysis, e.g. decoding, instruction word fields
    • G06F9/3016—Decoding the operand specifier, e.g. specifier format
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3836—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3885—Concurrent instruction execution, e.g. pipeline or look ahead using a plurality of independent parallel functional units
    • G06F9/3887—Concurrent instruction execution, e.g. pipeline or look ahead using a plurality of independent parallel functional units controlled by a single instruction for multiple data lanes [SIMD]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • 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/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • 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/04—Architecture, e.g. interconnection topology
    • G06N3/048—Activation functions
    • 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
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/02—Neural networks
    • G06N3/08—Learning methods
    • 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
    • G06T1/00—General purpose image data processing
    • G06T1/20—Processor architectures; Processor configuration, e.g. pipelining

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • Data Mining & Analysis (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • Biophysics (AREA)
  • Computer Hardware Design (AREA)
  • Computational Linguistics (AREA)
  • Molecular Biology (AREA)
  • General Health & Medical Sciences (AREA)
  • Evolutionary Computation (AREA)
  • Artificial Intelligence (AREA)
  • Computational Mathematics (AREA)
  • Mathematical Analysis (AREA)
  • Mathematical Optimization (AREA)
  • Pure & Applied Mathematics (AREA)
  • Algebra (AREA)
  • Databases & Information Systems (AREA)
  • Neurology (AREA)
  • Image Generation (AREA)
  • Image Processing (AREA)
  • Complex Calculations (AREA)
  • Advance Control (AREA)
  • Compression, Expansion, Code Conversion, And Decoders (AREA)

Abstract

Hierin beschriebene Ausführungsformen beinhalten Software-, Firmware- und Hardwarelogik, die Techniken zum Durchführen von Arithmetik an Sparse-Daten über eine systolische Verarbeitungseinheit bereitstellt. Eine Ausführungsform stellt datenbewusste Sparsity über komprimierte Bitströme bereit. Eine Ausführungsform stellt Block-Sparse-Skalarprodukt-Anweisungen bereit. Eine Ausführungsform stellt einen tiefenweisen Adapter für ein systolisches Array bereit.

Description

  • QUERVERWEIS AUF VERWANDTE ANWENDUNGEN
  • Die vorliegende Anmeldung bezieht sich auf und beansprucht, gemäß 35 U.S.C. 119(e), den Vorteil und die Priorität der vorläufigen US-Anmeldungen 62/819,337 mit dem Titel „GRAPHICS PROCESSING“ von Abhishek Appu et al., eingereicht am 15. März 2019 (Anwaltsaktenzeichen Nr. AC0271-Z), 62/819,435 mit dem Titel „GRAPHICS DATA PROCESSING“ von Lakshminarayanan Striramassarma, et al., eingereicht am 15. März 2019 (Anwaltsaktenzeichen Nr. AC0285-Z), 62/819,361 mit dem Titel „SYSTEMS AND METHODS FOR PARTITIONING CACHE TO REDUCE CACHE ACCESS LATENCY“ von Subramaniam Maiyuran et al., eingereicht am 15. März 2019 (Anwaltsaktenzeichen Nr. AC0286-Z) und 62/935,670 mit dem Titel „SYSTOLIC ARITHMETIC ON SPARSE DATA“ von Abhishek Appu et al., eingereicht am 15. November 2019 (Anwaltsaktenzeichen Nr. AC5197-Z), deren jeweilige Inhalte hiermit durch Bezugnahme aufgenommen werden.
  • GEBIET
  • Diese Offenbarung bezieht sich allgemein auf Datenverarbeitung und insbesondere auf Verarbeitung von Sparse-Daten über einen Matrixbeschleuniger einer Allzweck-Grafikverarbeitungseinheit.
  • HINTERGRUND DER OFFENBARUNG
  • Die aktuelle parallele Grafikdatenverarbeitung beinhaltet Systeme und Verfahren, die entwickelt wurden, um spezifische Operationen an Grafikdaten auszuführen, wie beispielsweise lineare Interpolation, Tessellation, Rasterisierung, Texturabbildung, Tiefentestung usw. Traditionell haben Grafikprozessoren Festfunktions-Recheneinheiten verwendet, um Grafikdaten zu verarbeiten; in jüngster Zeit wurden Teile von Grafikprozessoren jedoch programmierbar gemacht, wodurch ermöglicht wurde, dass solche Prozessoren eine größere Vielfalt an Operationen zur Verarbeitung von Vertex- und Fragmentdaten unterstützen.
  • Um die Leistungsfähigkeit weiter zu verbessern, implementieren Grafikprozessoren typischerweise Verarbeitungstechniken wie Pipelining, bei denen versucht wird, so viele Grafikdaten wie möglich in den verschiedenen Teilen der Grafik-Pipeline parallel zu verarbeiten. Parallele Grafikprozessoren mit SIMT(Single Instruction, Multiple Thread)-Architekturen sollen den Umfang der parallelen Verarbeitung in der Grafik-Pipeline maximieren. In einer SIMT-Architektur versuchen Gruppen von parallelen Threads, Programmanweisungen so oft wie möglich synchron gemeinsam auszuführen, um die Verarbeitungseffizienz zu erhöhen. Eine allgemeine Übersicht über Software und Hardware für SIMT-Architekturen findet sich in Shane Cook, CUDA Programming Kapitel 3, Seiten 37-51 (2013).
  • Figurenliste
  • Damit die Art und Weise, auf die oben angeführten Merkmale der vorliegenden Ausführungsformen ausführlich verstanden werden können, kann eine speziellere Beschreibung der oben kurz zusammengefassten Ausführungsformen unter Bezugnahme auf Ausführungsformen vorgenommen werden, von denen manche in den beigefügten Zeichnungen veranschaulicht sind. Es ist jedoch anzumerken, dass die beigefügten Zeichnungen nur typische Ausführungsformen veranschaulichen und daher nicht als ihren Schutzumfang beschränkend anzusehen sind.
    • 1 ist ein Blockdiagramm, das ein Computersystem veranschaulicht, das zum Implementieren eines oder mehrerer Aspekte der hierin beschriebenen Ausführungsformen konfiguriert ist;
    • 2A-2D veranschaulichen parallele Prozessorkomponenten;
    • 3A-3C sind Blockdiagramme von Grafikmultiprozessoren und Multiprozessorbasierten GPUs;
    • 4A-4F veranschaulichen eine beispielhafte Architektur, in der mehrere GPUs kommunikativ mit mehreren Mehrkernprozessoren gekoppelt sind;
    • 5 veranschaulicht eine Grafikverarbeitungs-Pipeline;
    • 6 veranschaulicht einen Software-Stack für maschinelles Lernen;
    • 7 veranschaulicht eine Allzweck-Grafikverarbeitungseinheit;
    • 8 veranschaulicht ein Mehrfach-GPU-Rechensystem;
    • 9A-9B veranschaulichen Schichten beispielhafter tiefer neuronaler Netzwerke;
    • 10 veranschaulicht ein beispielhaftes rekurrentes neuronales Netzwerk;
    • 11 veranschaulicht Training und Einsatz eines tiefen neuronalen Netzwerks;
    • 12 ist ein Blockdiagramm, das verteiltes Lernen veranschaulicht;
    • 13 veranschaulicht ein beispielhaftes Inferenz-System-on-Chip (SOC), das zum Durchführen einer Inferenz unter Verwendung eines trainierten Modells geeignet ist;
    • 14 ist ein Blockdiagramm eines Verarbeitungssystems;
    • 15A-15C veranschaulichen Rechensysteme und Grafikprozessoren;
    • 16A-16C veranschaulichen Blockdiagramme zusätzlicher Grafikprozessor- und Berechnungsbeschleunigerarchitekturen;
    • 17 ist ein Blockdiagramm einer Grafikverarbeitungs-Engine eines Grafikprozessors;
    • 18A-18B veranschaulichen eine Thread-Ausführungslogik, die ein Array von Verarbeitungselementen beinhaltet, die in einem Grafikprozessorkern eingesetzt werden;
    • 19 veranschaulicht eine zusätzliche Ausführungseinheit;
    • 20 ist ein Blockdiagramm, das die Anweisungsformate eines Grafikprozessors veranschaulicht;
    • 21 ist ein Blockdiagramm einer zusätzlichen Grafikprozessorarchitektur;
    • 22A-22B veranschaulichen ein Grafikprozessor-Befehlsformat und eine Grafikprozessor-Befehlssequenz;
    • 23 veranschaulicht eine beispielhafte Grafiksoftwarearchitektur für ein Datenverarbeitungssystem;
    • 24A ist ein Blockdiagramm, das ein IP-Kern-Entwicklungssystem veranschaulicht;
    • 24B veranschaulicht eine Querschnittsseitenansicht einer Integrierte-Schaltung-Package-Baugruppe;
    • 24C veranschaulicht eine Package-Baugruppe, die mehrere Einheiten von Hardware-Logik-Chiplets beinhaltet, die mit einem Substrat (z. B. Basis-Die) verbunden sind;
    • 24D veranschaulicht eine Package-Baugruppe, die austauschbare Chiplets enthält;
    • 25 ist ein Blockdiagramm, das eine beispielhafte integrierte Schaltung eines System-on-Chip veranschaulicht;
    • 26A-26B sind Blockdiagramme, die beispielhafte Grafikprozessoren zur Verwendung in einem SoC veranschaulichen;
    • 27 veranschaulicht eine zusätzliche Ausführungseinheit gemäß einer Ausführungsform;
    • 28 veranschaulicht eine Matrixoperation, die durch eine Anweisungs-Pipeline durchgeführt wird, gemäß einer Ausführungsform;
    • 29A-29B veranschaulichen Einzelheiten eines hardwarebasierten systolischen Arrays gemäß einigen Ausführungsformen;
    • 30 veranschaulicht ein systolisches Array, das ein Teilsummen-Loopback und eine Schaltungsanordnung zum Beschleunigen der Sparse-Matrix-Multiplikation enthält;
    • 31A-31B veranschaulichen eine Matrixbeschleunigungslogik einschließlich Codecs, um das Lesen von Sparse-Daten in einem komprimierten Format zu ermöglichen;
    • 32A-32B veranschaulichen eine Null-basierte SM-Codierung für Sparse-Daten eines neuronalen Netzwerks gemäß Ausführungsformen;
    • 33A-33B veranschaulichen eine SM-Codierung mit spezifiziertem Wert für Sparse-Daten eines neuronalen Netzwerks gemäß Ausführungsformen;
    • 34A-34B veranschaulichen Vergleiche zwischen unstrukturierter Sparsity (Spärlichkeit) und Block-Sparsity innerhalb von Trainingsdaten für ein neuronales Netzwerk;
    • 35A-35B veranschaulichen eine Vier-Elemente-Skalarprodukt-Anweisung, die durch die Skalarprodukt-Logik ausführbar ist;
    • 36A-36B veranschaulichen eine Zwei-Elemente-Skalarprodukt-Anweisung, die durch die Skalarprodukt-Logik ausführbar ist;
    • 37A-37C veranschaulichen eine Anweisung und eine assoziierte Hardwarelogik, um eine Multiplizieren-Addieren-Vektoroperation mit Nullüberspringen für eine Sparse-Eingabe zu ermöglichen;
    • 38A-38B vergleichen 3D-Faltung mit tiefenweiser Faltung;
    • 39A-39C veranschaulichen ein System, das ein systolisches Tensorarray und einen Bild-zu-Spalten-Adapter zur Verwendung während der tiefenweisen Faltung enthält;
    • 40 veranschaulicht ein Verfahren zum Durchführen einer tiefenweisen Faltung an einem systolischen Array; und
    • 41 ist ein Blockdiagramm einer Rechenvorrichtung, die einen Grafikprozessor beinhaltet, gemäß einer Ausführungsform.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Eine Grafikverarbeitungseinheit (GPU) ist kommunikativ mit Host-/Prozessorkernen gekoppelt, um beispielsweise Grafikoperationen, Maschinenlernoperationen, Musteranalyseoperationen und/oder verschiedene Allzweck-GPU(GPGPU)-Funktionen zu beschleunigen. Die GPU kann über einen Bus oder einen anderen Interconnect (z. B. einen Hochgeschwindigkeits-Interconnect wie PCIe oder NVLink) kommunikativ mit dem Hostprozessor/Kernen verbunden sein. Alternativ kann die GPU auf demselben Package oder Chip wie die Kerne integriert sein und über einen internen Prozessorbus/ein Interconnect (d. h. innerhalb des Package oder Chips) kommunikativ mit den Kernen gekoppelt sein. Unabhängig von der Art und Weise, auf welche die GPU verbunden ist, können die Prozessorkerne der GPU Arbeit in Form von in einem Arbeitsdeskriptor enthaltenen Sequenzen von Befehlen/Anweisungen zuweisen. Die GPU verwendet dann eine dedizierte Schaltungsanordnung/Logik zum effizienten Verarbeiten dieser Befehle/Anweisungen.
  • Hierin beschriebene Ausführungsformen beinhalten Software-, Firmware- und Hardwarelogik, die Techniken zum Durchführen von Arithmetik an Sparse-Daten über eine systolische Verarbeitungseinheit bereitstellt. Eine Ausführungsform stellt datenbewusste Sparsity über komprimierte Bitströme bereit. Eine Ausführungsform stellt Block-Sparse-Skalarprodukt-Anweisungen bereit (z. B. dp4a, dp2a). Eine Ausführungsform stellt einen Tiefenadapter für ein systolisches Array bereit.
  • In der folgenden Beschreibung werden zahlreiche spezifische Einzelheiten dargelegt, um ein umfassenderes Verständnis bereitzustellen. Fachleute werden jedoch erkennen, dass die hierin beschriebenen Ausführungsformen ohne eine oder mehrere dieser spezifischen Einzelheiten in die Praxis umgesetzt werden können. In anderen Fällen wurden wohlbekannte Merkmale nicht beschrieben, um die Einzelheiten der vorliegenden Ausführungsformen nicht unklar zu machen.
  • Systemübersicht
  • 1 ist ein Blockdiagramm, das ein Rechensystem 100 veranschaulicht, das dazu ausgelegt ist, einen oder mehrere Aspekte der hierin beschriebenen Ausführungsformen zu implementieren. Das Rechensystem 100 beinhaltet ein Verarbeitungssubsystem 101 mit einem oder mehreren Prozessoren 102 und einem Systemspeicher 104, die über einen Verbindungspfad, der einen Speicherhub 105 aufweisen kann, kommunizieren. Der Speicherhub 105 kann eine separate Komponente innerhalb einer Chipsatzkomponente sein oder kann in dem einen oder den mehreren Prozessoren 102 integriert sein. Der Speicherhub 105 ist über eine Kommunikationslink 106 mit einem E/A-Subsystem 111 gekoppelt. Das E/A-Subsystem 111 beinhaltet einen E/A-Hub 107, der ermöglichen kann, dass das Rechensystem 100 eine Eingabe von einer oder mehreren Eingabevorrichtungen 108 empfängt. Außerdem kann der E/A-Hub 107 ermöglichen, dass eine Anzeigesteuerung, die in dem einen oder den mehreren Prozessoren 102 enthalten sein kann, einer oder mehreren Anzeigevorrichtungen 110A Ausgaben bereitstellt. In einer Ausführungsform können die eine oder die mehreren Anzeigevorrichtungen 110A, die mit dem E/A-Hub 107 gekoppelt sind, eine lokale, interne oder eingebettete Anzeigevorrichtung beinhalten.
  • Das Verarbeitungssubsystem 101 beinhaltet zum Beispiel einen oder mehrere Parallelprozessoren 112, die über einen Bus oder einen anderen Kommunikationslink 113 an den Speicherhub 105 gekoppelt sind. Der Kommunikationslink 113 kann eine von einer beliebigen Anzahl von auf Standards basierenden Kommunikationslinktechnologien oder -protokollen sein, wie etwa, jedoch nicht darauf beschränkt, PCI Express, oder kann eine anbieterspezifische Kommunikationsschnittstelle oder ein Kommunikations-Fabric sein. Der eine oder die mehreren Parallelprozessoren 112 können ein rechnerisch fokussiertes Parallel- oder Vektorverarbeitungssystem bilden, das eine große Anzahl von Verarbeitungskernen und/oder Verarbeitungsclustern beinhalten kann, wie etwa einen MIC-Prozessor (MIC: Many Integrated Core). Zum Beispiel bilden der eine oder die mehreren Parallelprozessoren 112 ein Grafikverarbeitungssubsystem, das Pixel an eine der einen oder mehreren Anzeigevorrichtungen 110A, die über den E/A-Hub 107 gekoppelt sind, ausgeben kann. Der eine oder die mehreren Parallelprozessoren 112 können auch eine Anzeigesteuerung und eine Anzeigeschnittstelle (nicht dargestellt) aufweisen, um eine direkte Verbindung mit einer oder mehreren Anzeigevorrichtungen 110B zu ermöglichen.
  • Innerhalb des E/A-Subsystems 111 kann eine Systemspeicherungseinheit 114 eine Verbindung mit dem E/A-Hub 107 herstellen, um einen Speicherungsmechanismus für das Rechensystem 100 bereitzustellen. Ein E/A-Schalter 116 kann verwendet werden, um einen Schnittstellenmechanismus bereitzustellen, um Verbindungen zwischen dem E/A-Hub 107 und anderen Komponenten, wie etwa einem Netzwerkadapter 118 und/oder einem drahtlosen Netzwerkadapter 119, die in der Plattform integriert sein können, und verschiedenen anderen Vorrichtungen, die über eine oder mehrere Add-In-Vorrichtungen 120 hinzugefügt werden können, zu ermöglichen. Die eine oder die mehreren Add-In-Vorrichtungen 120 können beispielsweise auch eine oder mehrere externe Grafikprozessorvorrichtungen und/oder Berechnungsbeschleuniger beinhalten. Der Netzwerkadapter 118 kann ein Ethernet-Adapter oder ein anderer drahtgebundener Netzwerkadapter sein. Der drahtlose Netzwerkadapter 119 kann eine oder mehrere einer Wi-Fi-, Bluetooth-, Nahfeldkommunikations(NFC)- oder einer anderen Netzwerkvorrichtung beinhalten, die eine oder mehrere drahtlose Funkgeräte aufweist.
  • Das Rechensystem 100 kann andere Komponenten beinhalten, die nicht explizit gezeigt sind, darunter USB- oder andere Port-Verbindungen, optische Speicherungslaufwerke, Videoaufnahmevorrichtungen und dergleichen, die auch mit dem E/A-Hub 107 verbunden sein können. Kommunikationspfade, die die verschiedenen Komponenten in 1 miteinander verbinden, können unter Verwendung beliebiger geeigneter Protokolle implementiert werden, wie etwa PCI(Peripheral Component Interconnect)-basierte Protokolle (zum Beispiel PCI-Express) oder beliebige andere Bus- oder Punkt-zu-Punkt-Kommunikationsschnittstellen und/oder -Protokoll(e), wie etwa der NV-Link-Hochgeschwindigkeits-Interconnect oder im Stand der Technik bekannte Interconnect-Protokolle.
  • Der eine oder die mehreren Parallelprozessoren 112 können eine Schaltungsanordnung umfassen, die für Grafik- und Videoverarbeitung optimiert ist, darunter beispielsweise eine Videoausgabeschaltungsanordnung, und eine Grafikverarbeitungseinheit (GPU) bildet. Alternativ oder zusätzlich können der eine oder die mehreren Parallelprozessoren 112 eine Schaltungsanordnung umfassen, die zur Allzweckverarbeitung optimiert ist, während die zugrundeliegende Rechenarchitektur erhalten bleibt, die hierin ausführlicher beschrieben wird. Komponenten des Rechensystems 100 können mit einem oder mehreren anderen Systemelementen auf einer einzigen integrierten Schaltung integriert sein. Zum Beispiel können der eine oder die mehreren Parallelprozessoren 112, der Speicherhub 105, der eine oder die mehreren Prozessoren 102 und der E/A-Hub 107 in einer integrierten System-on-Chip (SoC)-Schaltung integriert sein. Alternativ können die Komponenten des Rechensystems 100 in einem einzigen Package integriert sein, um eine System-in-Package(SIP)-Konfiguration zu bilden. Bei einer Ausführungsform kann mindestens ein Teil der Komponenten des Rechensystems 100 in einem Multi-Chip-Modul (MCM) integriert sein, das mit anderen Multi-Chip-Modulen zu einem modularen Rechensystem verschaltet sein kann.
  • Es versteht sich, dass das hier gezeigte Rechensystem 100 veranschaulichend ist und dass Variationen und Modifikationen möglich sind. Die Verbindungstopologie, einschließlich der Anzahl und Anordnung von Brücken, der Anzahl von Prozessoren 102 und der Anzahl von Parallelprozessoren 112, kann wie gewünscht modifiziert werden. Zum Beispiel kann der Systemspeicher direkt mit dem einen oder den mehreren Prozessoren 102 statt über eine Brücke verbunden sein, während andere Vorrichtungen über den Speicherhub 105 und den einen oder die mehreren Prozessoren 102 mit dem Systemspeicher 104 kommunizieren. In anderen alternativen Topologien sind der eine oder die mehreren Parallelprozessoren 112 mit dem E/A-Hub 107 oder direkt mit einem des einen oder der mehreren Prozessoren 102 anstatt mit dem Speicherhub 105 verbunden. In anderen Ausführungsformen können der E/A-Hub 107 und der Speicherhub 105 in einem einzigen Chip integriert sein. Es ist auch möglich, dass zwei oder mehr Sätze von Prozessor(en) 102 über mehrere Sockets angeschlossen sind, die mit zwei oder mehr Instanzen des einen der mehreren Parallelprozessoren 112 koppeln können.
  • Einige der hierin gezeigten speziellen Komponenten sind optional und müssen nicht in allen Implementierungen des Rechensystems 100 enthalten sein. Zum Beispiel kann eine beliebige Anzahl von Add-in-Karten oder Peripheriegeräten unterstützt werden, oder einige Komponenten können entfernt werden. Darüber hinaus können einige Architekturen eine andere Terminologie für Komponenten verwenden, die denen ähnlich sind, die in 1 dargestellt sind. Zum Beispiel kann der Speicherhub 105 in einigen Architekturen als eine Northbridge bezeichnet werden, während der E/A-Hub 107 als eine Southbridge bezeichnet werden kann.
  • 2A veranschaulicht einen Parallelprozessor 200. Der Parallelprozessor 200 kann eine GPU, GPGPU oder dergleichen sein, wie hierin beschrieben. Die verschiedenen Komponenten des Parallelprozessors 200 können unter Verwendung einer oder mehrerer integrierter Schaltungsvorrichtungen implementiert sein, wie etwa programmierbarer Prozessoren, anwendungsspezifischer integrierter Schaltungen (ASICs) oder feldprogrammierbarer Gate-Arrays (FPGA). Der veranschaulichte Parallelprozessor 200 kann der oder einer der in 1 gezeigten Parallelprozessor(en) 112 sein.
  • Der Parallelprozessor 200 beinhaltet eine Parallelverarbeitungseinheit 202. Die Parallelverarbeitungseinheit beinhaltet eine E/A-Einheit 204, die eine Kommunikation mit anderen Vorrichtungen, darunter andere Instanzen der Parallelverarbeitungseinheit 202, ermöglicht. Die E/A-Einheit 204 kann direkt mit anderen Vorrichtungen verbunden sein. Zum Beispiel stellt die E/A-Einheit 204 über die Verwendung einer Hub- oder Switch-Schnittstelle, wie etwa des Speicherhubs 105, eine Verbindung mit anderen Vorrichtungen her. Die Verbindungen zwischen dem Speicherhub 105 und der E/A-Einheit 204 bilden einen Kommunikationslink 113. Innerhalb der Parallelverarbeitungseinheit 202 ist die E/A-Einheit 204 mit einer Host-Schnittstelle 206 und einer Speicher-Crossbar 216 verbunden, wobei die Host-Schnittstelle 206 Befehle zum Durchführen von Verarbeitungsoperationen empfängt und die Speicher-Crossbar 216 Befehle zum Durchführen 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 zum Durchführen dieser Befehle an ein Frontend 208 leiten. In einer Ausführungsform ist das Frontend 208 mit einem Scheduler 210 gekoppelt, der dazu konfiguriert ist, Befehle oder andere Arbeitselemente an ein Verarbeitungscluster-Array 212 zu verteilen. Der Scheduler 210 stellt sicher, dass das Verarbeitungscluster-Array 212 richtig 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 implementiert werden, die auf einem Mikrocontroller ausgeführt wird. Der Mikrocontroller-implementierte Scheduler 210 ist dazu konfigurierbar, komplexe Scheduling- und Arbeitsverteilungsoperationen mit Grob- und Feingranularität auszuführen, was eine schnelle Präemption und einen schnellen Kontextwechsel von Threads ermöglicht, die auf dem Verarbeitungsarray 212 ausgeführt werden. Vorzugsweise kann die Host-Software Arbeitslasten zum Planen auf dem Verarbeitungsarray 212 über eine von mehreren Grafikverarbeitungs-Doorbells nachweisen. Die Arbeitslasten können dann automatisch durch die Logik des Schedulers 210 innerhalb des Scheduler-Mikrocontrollers über das Verarbeitungsarray 212 hinweg verteilt werden.
  • Das Verarbeitungscluster-Array 212 kann bis zu „N“ Verarbeitungscluster (z. B. Cluster 214A, Cluster 214B bis Cluster 214N) beinhalten. Jeder Cluster 214A-214N des Verarbeitungscluster-Arrays 212 kann eine große Anzahl gleichzeitiger Threads ausführen. Der Scheduler 210 kann den Clustern 214A-214N des Verarbeitungscluster-Arrays 212 unter Verwendung verschiedener Scheduling- und/oder Arbeitsverteilungsalgorithmen, die je nach der Arbeitslast variieren können, die für jede Art von Programm oder Berechnung auftritt, Arbeit zuweisen. Das Scheduling kann dynamisch durch den Scheduler 210 gehandhabt werden oder kann teilweise durch eine Compiler-Logik während eines Kompilierens einer Programmlogik, die zur Ausführung durch das Verarbeitungscluster-Array 212 konfiguriert ist, unterstützt werden. Optional können verschiedene Cluster 214A-214N des Verarbeitungscluster-Arrays 212 zum Verarbeiten verschiedener Arten von Programmen oder zum Durchführen verschiedener Arten von Berechnungen zugewiesen werden.
  • Das Verarbeitungscluster-Array 212 kann dazu konfiguriert sein, verschiedene Arten von parallelen Verarbeitungsoperationen durchzuführen. Zum Beispiel ist das Cluster-Array 212 dazu konfiguriert, parallele Allzweck-Rechenoperationen durchzuführen. Zum Beispiel kann das Verarbeitungscluster-Array 212 eine Logik zum Durchführen von Verarbeitungsaufgaben, darunter Filtern von Video- und/oder Audiodaten, Durchführen von Modellierungsoperationen einschließlich physischer Operationen und Durchführen von Datentransformationen, beinhalten.
  • Das Verarbeitungscluster-Array 212 ist dazu konfiguriert, parallele Grafikverarbeitungsoperationen durchzuführen. In solchen Ausführungsformen, in denen der Parallelprozessor 200 zum Ausführen von Grafikverarbeitungsoperationen konfiguriert ist, kann das Verarbeitungscluster-Array 212 zusätzliche Logik aufweisen, um die Ausführung solcher Grafikverarbeitungsoperationen zu unterstützen, darunter unter anderem eine Texturabtastlogik zum Durchführen von Texturoperationen sowie eine Tessellationslogik und andere Vertex-Verarbeitungslogik. Zusätzlich kann das Verarbeitungscluster-Array 212 dazu konfiguriert sein, mit der Grafikverarbeitung in Zusammenhang stehende Shader-Programme auszuführen, wie etwa unter anderem Vertex-Shader, Tessellations-Shader, Geometrie-Shader 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 während der Verarbeitung in einem On-Chip-Speicher (z. B. Parallelprozessorspeicher 222) gespeichert und dann in den Systemspeicher zurückgeschrieben werden.
  • In Ausführungsformen, bei denen die Parallelverarbeitungseinheit 202 zum Durchführen einer Grafikverarbeitung verwendet wird, kann der Scheduler 210 dazu konfiguriert sein, die Verarbeitungsarbeitslast in ungefähr gleich große Aufgaben aufzuteilen, um eine Verteilung der Grafikverarbeitungsoperationen auf mehrere Cluster 214A-214N des Verarbeitungscluster-Arrays 212 besser zu ermöglichen. In einigen dieser Ausführungsformen können Teile des Verarbeitungscluster-Arrays 212 dazu konfiguriert sein, unterschiedliche Arten von Verarbeitung durchzuführen. Ein erster Abschnitt kann zum Beispiel dazu konfiguriert sein, Vertex-Shading und Topologieerzeugung durchzuführen, ein zweiter Abschnitt kann dazu konfiguriert sein, Tessellations- und Geometrie-Shading durchzuführen, und ein dritter Abschnitt kann dazu konfiguriert sein, Pixel-Shading oder andere Bildschirmraumoperationen durchzuführen, um ein gerendertes Bild zur Anzeige zu erzeugen. Zwischendaten, die von einem oder mehreren der Cluster 214A bis 214N erzeugt werden, können in Puffern gespeichert werden, um zu ermöglichen, dass die Zwischendaten zwischen Clustern 214A bis 214N zur weiteren Verarbeitung übertragen werden.
  • Während des Betriebs kann das Verarbeitungscluster-Array 212 Verarbeitungsaufgaben empfangen, die über den Scheduler 210 auszuführen sind, der Befehle empfängt, die Verarbeitungsaufgaben vom Frontend 208 definieren. Für Grafikverarbeitungsoperationen können Verarbeitungsaufgaben Indizes von zu verarbeitenden Daten beinhalten, z. B. Oberflächen(Patch)-Daten, Primitivdaten, Vertexdaten und/oder Pixeldaten sowie Zustandsparameter und Befehle, die definieren, wie die Daten verarbeitet werden sollen (z. B. welches Programm ausgeführt werden soll). Der Scheduler 210 kann konfiguriert sein, die den Aufgaben entsprechenden Indizes abzurufen oder die Indizes von dem Frontend 208 zu empfangen. Das Frontend 208 kann konfiguriert sein, sicherzustellen, dass das Verarbeitungscluster-Array 212 in einen gültigen Zustand konfiguriert ist, bevor die durch ankommende Befehlspuffer (z. B. Stapel-Puffer, Push-Puffer usw.) spezifizierte Arbeitslast initiiert wird.
  • Jede der einen oder mehreren Instanzen der Parallelverarbeitungseinheit 202 kann mit dem Parallelprozessorspeicher 222 gekoppelt sein. Auf den Parallelprozessorspeicher 222 kann über die Speicher-Crossbar 216 zugegriffen werden, die Speicheranfragen von dem Verarbeitungscluster-Array 212 sowie der I/O-Einheit 204 empfangen kann. Die Speicher-Crossbar 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) aufweisen, die jeweils mit einem Abschnitt (z. B. Speichereinheit) des Parallelprozessorspeichers 222 gekoppelt sein können. Die Anzahl von Partitionseinheiten 220A - 220N kann so konfiguriert sein, dass sie gleich der Anzahl von Speichereinheiten ist, sodass eine erste Partitionseinheit 220A eine entsprechende erste Speichereinheit 224A aufweist, eine zweite Partitionseinheit 220B eine entsprechende Speichereinheit 224B aufweist und eine N-te Partitionseinheit 220N eine entsprechende N-te Speichereinheit 224N aufweist. In anderen Ausführungsformen ist die Anzahl der Partitionseinheiten 220A bis 220N möglicherweise nicht gleich der Anzahl der Speichervorrichtungen.
  • Die Speichereinheiten 224A - 224N können verschiedene Arten von Speichervorrichtungen beinhalten, einschließlich eines dynamischen Direktzugriffsspeichers (DRAM) oder eines Grafik-Direktzugriffsspeichers, wie beispielsweise eines synchronen Grafik-Direktzugriffsspeichers (SGRAM), einschließlich eines Grafikspeichers mit doppelter Datenrate (GDDR). Optional können die Speichereinheiten 224A - 224N auch 3D-Stapelspeicher beinhalten, einschließlich unter anderem Speicher mit hoher Bandbreite (High Bandwidth Memory - HBM). Fachleute werden zu schätzen wissen, dass die spezifische Implementierung der Speichereinheiten 224A bis 224N variieren kann und aus einer von verschiedenen herkömmlichen Designs ausgewählt werden kann. Rendering-Ziele wie Rahmenpuffer oder Texturabbildungen können über die Speichereinheiten 224A bis 224N gespeichert werden, wodurch die Partitionseinheiten 220A bis 220N Abschnitte jedes Rendering-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 vereinheitlichen Speicherdesigns ausgeschlossen werden, der einen Systemspeicher in Verbindung mit einem lokalen Cachespeicher verwendet.
  • Optional hat jeder beliebige der Cluster 214A - 214N des Verarbeitungscluster-Arrays 212 die Fähigkeit, Daten zu verarbeiten, die in eine der Speichereinheiten 224A - 224N innerhalb des Parallelprozessorspeichers 222 geschrieben werden. Die Speicher-Crossbar 216 kann konfiguriert sein, die Ausgabe jedes Clusters 214A-214N an eine beliebige Partitionseinheit 220A-220N oder an einen anderen Cluster 214A - 214N zu übertragen, die zusätzliche Verarbeitungsoperationen an der Ausgabe ausführen können. Jeder Cluster 214A bis 214N kann mit der Speicherschnittstelle 218 über die Speicher-Crossbar 216 kommunizieren, um aus verschiedenen externen Speichervorrichtungen zu lesen oder in diese zu schreiben. In einer der Ausführungsformen mit der Speicher-Crossbar 216 weist die Speicher-Crossbar 216 eine Verbindung mit der Speicherschnittstelle 218 auf, um mit der E/A-Einheit 204 zu kommunizieren, sowie eine Verbindung mit einer lokalen Instanz des Parallelprozessorspeichers 222, wodurch den Verarbeitungseinheiten innerhalb der verschiedenen Verarbeitungscluster 214A-214N ermöglicht wird, mit dem Systemspeicher oder einem anderen Speicher zu kommunizieren, der nicht lokal für die Parallelverarbeitungseinheit 202 ist. Im Allgemeinen kann die Speicher-Crossbar 216 beispielsweise in der Lage sein, virtuelle Kanäle zu verwenden, um Verkehrsströme zwischen den Clustern 214A - 214N und den Partitionseinheiten 220A - 220N zu trennen.
  • Wenngleich eine einzelne Instanz der Parallelverarbeitungseinheit 202 innerhalb des Parallelprozessors 200 dargestellt ist, kann eine beliebige Anzahl von Instanzen der Parallelverarbeitungseinheit 202 enthalten sein. Zum Beispiel können mehrere Instanzen der Parallelverarbeitungseinheit 202 auf einer einzelnen Add-In-Karte bereitgestellt sein, oder mehrere Add-In-Karten können miteinander verbunden sein. Die verschiedenen Instanzen der Parallelverarbeitungseinheit 202 können konfiguriert sein, miteinander zu arbeiten, selbst wenn die verschiedenen Instanzen unterschiedliche Anzahlen von Verarbeitungskernen, unterschiedliche Mengen von lokalem Parallelprozessorspeicher und/oder andere Konfigurationsunterschiede aufweisen. Optional können einige Instanzen der Parallelverarbeitungseinheit 202 Gleitkommaeinheiten mit höherer Präzision relativ zu anderen Instanzen beinhalten. Systeme, die eine oder mehrere Instanzen der Parallelverarbeitungseinheit 202 oder des Parallelprozessors 200 umfassen, können in einer Vielzahl von Konfigurationen und Formfaktoren implementiert werden, darunter unter anderem Desktop-, Laptop- oder Handheld-Personal-Computer, Server, Workstations, Spielkonsolen und/oder eingebettete Systeme.
  • 2B ist ein Blockdiagramm einer Partitionseinheit 220. Die Partitionseinheit 220 kann eine Instanz einer der Partitionseinheiten 220A - 220N von 2A sein. Wie veranschaulicht, weist die Partitionseinheit 220 einen L2-Cache 221, eine Rahmenpufferschnittstelle 225 und eine ROP 226 (Raster Operations Unit - Rasteroperationseinheit) auf. Der L2-Cachespeicher 221 ist ein Lese-/Schreib-Cachespeicher, der zum Ausführen von Lade- und Speicheroperationen konfiguriert ist, die von der Speicher-Crossbar 216 und der ROP 226 empfangen werden. Lesefehler und dringende Rückschreibanfragen von dem L2-Cache 221 an die Rahmenpuffer-Schnittstelle 225 zur Verarbeitung ausgegeben. Aktualisierungen können auch über die Rahmenpuffer-Schnittstelle 225 zur opportunistischen Verarbeitung an den Rahmenpuffer gesendet werden. Bei einer Ausführungsform ist die Rahmenpufferschnittstelle 225 über eine Schnittstelle mit einer der Speichereinheiten im Parallelprozessorspeicher verbunden, wie etwa den Speichereinheiten 224A-224N aus 2A (z. B. innerhalb des Parallelprozessorspeichers 222). Die Partitionseinheit 220 kann zusätzlich oder alternativ auch eine Schnittstelle mit einer der Speichereinheiten im Parallelprozessorspeicher über eine Speichersteuerung (nicht gezeigt) aufweisen.
  • In Grafikanwendungen ist die ROP 226 eine Verarbeitungseinheit, die Rasteroperationen wie Schablonen-, z-Test-, Mischoperationen und dergleichen ausführt. Die ROP 226 gibt dann verarbeitete Grafikdaten aus, die im Grafikspeicher gespeichert werden. In einigen Ausführungsformen beinhaltet die ROP 226 Kompressionslogik zum Komprimieren von Tiefen- oder Farbdaten, die in den Speicher geschrieben werden, und zum Dekomprimieren von Tiefen- oder Farbdaten, die aus dem Speicher gelesen werden. Die Komprimierungslogik kann eine verlustfreie Komprimierungslogik sein, die einen oder mehrere Komprimierungsalgorithmen verwendet. Die Art der Komprimierung, die von der ROP 226 ausgeführt wird, kann basierend auf den statistischen Eigenschaften der zu komprimierenden Daten variieren. Zum Beispiel wird in einer Ausführungsform eine Delta-Farbkomprimierung an Tiefen- und Farbdaten auf einer Pro-Kachel-Basis ausgeführt.
  • Die ROP 226 kann in jedem Verarbeitungscluster (z. B. Cluster 214A-214N von 2A) anstatt in der Partitionseinheit 220 enthalten sein. In einer solchen Ausführungsform werden Lese- und Schreibanfragen für Pixeldaten über die Speicher-Crossbar 216 anstelle von Pixelfragmentdaten übertragen. Die verarbeiteten Grafikdaten können auf einer Anzeigevorrichtung wie einer der einen oder mehreren Anzeigevorrichtungen 110 aus 1 angezeigt werden, zur weiteren Verarbeitung durch den einen oder die mehreren Prozessoren 102 geroutet werden oder für die weitere Verarbeitung durch eine der Verarbeitungseinheiten innerhalb des Parallelprozessors 200 aus 2A geroutet werden.
  • 2C ist ein Blockdiagramm eines Verarbeitungsclusters 214 in einer Parallelverarbeitungseinheit. Der Verarbeitungscluster ist zum Beispiel eine Instanz eines der Verarbeitungscluster 214A-214N von 2A. Der Verarbeitungscluster 214 kann dazu konfiguriert sein, viele Threads parallel auszuführen, wobei sich der Begriff „Thread“ auf eine Instanz eines bestimmten Programms bezieht, das auf einem bestimmten Satz von Eingabedaten ausgeführt wird. Optional können SIMD-Anweisungsausgabetechniken (SIMD: Single Instruction, Multiple Data) angewendet werden, um eine parallele Ausführung einer großen Anzahl von Threads zu unterstützen, ohne mehrere unabhängige Anweisungseinheiten bereitzustellen. Alternativ werden SIMT-Techniken (SIMT: Single Instruction, Multiple Thread) angewendet, um eine parallele Ausführung einer großen Anzahl von allgemein synchronisierten Threads zu unterstützen, wobei eine gemeinsame Anweisungseinheit verwendet wird, die dazu konfiguriert ist, Anweisungen an einen Satz von Verarbeitungs-Engines innerhalb jedes der Verarbeitungscluster auszugeben. Im Gegensatz zu einer SIMD-Ausführungsregelung, bei der alle Verarbeitungs-Engines typischerweise identische Anweisungen ausführen, ermöglicht die SIMT-Ausführung, dass verschiedene Threads divergenten Ausführungspfaden durch ein gegebenes Thread-Programm leichter folgen. Fachleute werden verstehen, dass eine SIMD-Verarbeitungsregelung eine funktionelle Teilmenge einer SIMT-Verarbeitungsregelung darstellt.
  • Der Betrieb des Verarbeitungsclusters 214 kann über einen Pipeline-Manager 232 gesteuert werden, der Verarbeitungsaufgaben an parallele SIMT-Prozessoren verteilt. Der Pipeline-Manager 232 empfängt Anweisungen von dem Scheduler 210 von 2A und verwaltet eine Ausführung dieser Anweisungen über einen Grafikmultiprozessor 234 und/oder eine Textureinheit 236. Der veranschaulichte Grafikmultiprozessor 234 ist eine beispielhafte Instanz eines SIMT-Parallelprozessors. Es können jedoch verschiedene Arten von SIMT-Parallelprozessoren unterschiedlicher Architekturen in dem Verarbeitungscluster 214 enthalten sein. Eine oder mehrere Instanzen des Grafikmultiprozessors 234 können in einem Verarbeitungscluster 214 enthalten sein. Der Grafikmultiprozessor 234 kann Daten verarbeiten und eine Daten-Crossbar 240 kann verwendet werden, um die verarbeiteten Daten an eines von mehreren möglichen Zielen zu verteilen, einschließlich anderer Shader-Einheiten. Der Pipeline-Manager 232 kann die Verteilung verarbeiteter Daten erleichtern, indem er Ziele für verarbeitete Daten spezifiziert, die über die Daten-Crossbar 240 verteilt werden sollen.
  • Jeder Grafikmultiprozessor 234 innerhalb des Verarbeitungsclusters 214 kann einen identischen Satz funktionaler Ausführungslogik (z. B. arithmetischen Logikeinheiten, Lade-Speicher-Einheiten usw.) aufweisen. Die Ausführungsfunktionslogik kann in einer Pipeline-Art konfiguriert sein, in der neue Anweisungen erteilt werden können, bevor vorherige Anweisungen abgeschlossen sind. Die Ausführungsfunktionslogik unterstützt verschiedene Operationen, einschließlich arithmetischer Ganzzahl- und Gleitkomma-Vergleichsoperationen, Boolescher Operationen, Bitverschiebung und Berechnung verschiedener algebraischer Funktionen. Dieselbe Funktionseinheit-Hardware könnte genutzt werden, um unterschiedliche Operationen durchzuführen, und es kann eine beliebige Kombination von Funktionseinheiten vorhanden sein.
  • Die an den Verarbeitungscluster 214 übertragenen Anweisungen bilden einen Thread. Eine Gruppe von Threads, die über den Satz paralleler Verarbeitungs-Engines ausgeführt werden, ist eine Thread-Gruppe. Eine Thread-Gruppe führt dasselbe Programm für verschiedene Eingabedaten aus. Jeder Thread innerhalb einer Thread-Gruppe kann einer anderen Verarbeitungs-Engine innerhalb eines Grafikmultiprozessors 234 zugewiesen sein. Eine Thread-Gruppe kann weniger Threads als die Anzahl von Verarbeitungs-Engines innerhalb des Grafikmultiprozessors 234 aufweisen. Wenn eine Thread-Gruppe weniger Threads als die Anzahl der Verarbeitungs-Engines aufweist, können eine oder mehrere der Verarbeitungs-Engines während Zyklen, in denen diese Thread-Gruppe verarbeitet wird, inaktiv sein. Eine Thread-Gruppe kann auch mehr Threads als die Anzahl von Verarbeitungs-Engines innerhalb des Grafikmultiprozessors 234 aufweisen. Wenn die Thread-Gruppe mehr Threads beinhaltet als die Anzahl der Verarbeitungs-Engines innerhalb des Grafikmultiprozessors 234, kann die Verarbeitung über aufeinanderfolgende Taktzyklen durchgeführt werden. Optional können mehrere Thread-Gruppen gleichzeitig auf dem Grafikmultiprozessor 234 ausgeführt werden.
  • Der Grafikmultiprozessor 234 kann einen internen Cachespeicher beinhalten, um Lade- und Speicheroperationen durchzuführen. Optional kann der Grafikmultiprozessor 234 auf einen internen Cache verzichten und einen Cachespeicher (z. B. L1-Cache 248) innerhalb des Verarbeitungsclusters 214 verwenden. Jeder Grafikmultiprozessor 234 hat auch Zugriff auf L2-Caches innerhalb der Partitionseinheiten (z. B. Partitionseinheiten 220A-220N von 2A), die durch alle Verarbeitungscluster 214 gemeinsam genutzt werden und zum Übertragen von Daten zwischen Threads verwendet werden können. Der Grafikmultiprozessor 234 kann auch auf einen chipexternen globalen Speicher zugreifen, der einen oder mehrere eines lokalen Parallelprozessorspeichers und/oder Systemspeichers aufweisen kann. Jeder beliebige Speicher außerhalb der Parallelverarbeitungseinheit 202 kann als globaler Speicher verwendet werden. Ausführungsformen, in denen der Verarbeitungscluster 214 mehrere Instanzen des Grafikmultiprozessors 234 aufweist, können gemeinsame Anweisungen und Daten, die in dem L1-Cache 248 gespeichert sein können, gemeinsam nutzen.
  • Jeder Verarbeitungscluster 214 kann eine MMU 245 (Memory Management Unit - Speicherverwaltungseinheit) aufweisen, die konfiguriert ist, virtuelle Adressen auf physische Adressen abzubilden. In anderen Ausführungsformen können sich eine oder mehrere Instanzen der MMU 245 in der Speicherschnittstelle 218 von 2A befinden. Die MMU 245 enthält einen Satz von Seitentabelleneinträgen (PTEs), die verwendet werden, um eine virtuelle Adresse auf eine physische Adresse einer Kachel und optional einen Cachezeilenindex abzubilden. Die MMU 245 kann Adressübersetzungs-Nachschlagepuffer (TLB) oder Caches aufweisen, die sich innerhalb des Grafikmultiprozessors 234 oder des L1-Cachespeichers oder VerarbeitungsClusters 214 befinden können. Die physische Adresse wird verarbeitet, um die Oberflächendaten-Zugriffslokalität zu verteilen, um eine effiziente Anfragenverschachtelung zwischen Partitionseinheiten zu ermöglichen. Der Cachezeilenindex kann verwendet werden, um zu bestimmen, ob eine Anfrage für eine Cachezeile ein Treffer oder ein Fehltreffer ist.
  • In Grafik- und Rechenanwendungen kann ein Verarbeitungscluster 214 derart konfiguriert sein, dass jeder Grafikmultiprozessor 234 mit einer Textureinheit 236 zur Durchführung von Texturabbildungsoperationen gekoppelt ist, z. B. zum Bestimmen von Texturabtastpositionen, zum Lesen von Texturdaten und zum Filtern der Texturdaten. Texturdaten werden von einem internen Textur-L1-Cache (nicht dargestellt) oder in einigen Ausführungsformen aus dem L1-Cache innerhalb des Grafikmultiprozessors 234 gelesen und werden je nach Bedarf von einem L2-Cache, einem lokalen Parallelprozessorspeicher oder Systemspeicher abgerufen. Jeder Grafikmultiprozessor 234 gibt verarbeitete Aufgaben an die Daten-Crossbar 240 aus, um die verarbeitete Aufgabe einem weiteren Verarbeitungs-Cluster 214 zur weiteren Verarbeitung bereitzustellen oder die verarbeitete Aufgabe über die Speicher-Crossbar 216 in einem L2-Cache, lokalen Parallelprozessorspeicher oder Systemspeicher zu speichern. Ein preROP 242 (Pre-Raster-Operationseinheit) ist dazu konfiguriert, Daten von dem Grafikmultiprozessor 234 zu empfangen und Daten zu ROP-Einheiten zu leiten, die sich bei Partitionseinheiten befinden können, wie hierin beschrieben (z. B. Partitionseinheiten 220A-220 N von 2A). Die preROP 242-Einheit kann Optimierungen für die Farbmischung ausführen, Pixelfarbdaten organisieren und Adressübersetzungen ausführen.
  • Es versteht sich, dass die hier beschriebene Kernarchitektur veranschaulichend ist und dass Variationen und Modifikationen möglich sind. Eine beliebige Anzahl von Verarbeitungseinheiten, z. B. Grafikmultiprozessor 234, Textureinheiten 236, pre-ROPs 242 usw., kann in einem Verarbeitungscluster 214 enthalten sein. Wenngleich nur ein Verarbeitungscluster 214 dargestellt ist, kann ferner eine Parallelverarbeitungseinheit, wie hierin beschrieben, eine beliebige Anzahl von Instanzen des Verarbeitungsclusters 214 aufweisen. Optional kann jeder Verarbeitungscluster 214 dazu konfiguriert sein, unabhängig von anderen Verarbeitungsclustern 214 unter Verwendung separater und unterschiedlicher Verarbeitungseinheiten, L1-Caches usw. zu arbeiten.
  • 2D zeigt ein Beispiel des Grafikmultiprozessors 234, bei dem der Grafikmultiprozessor 234 mit dem Pipeline-Manager 232 des Verarbeitungsclusters 214 gekoppelt ist. Der Grafikmultiprozessor 234 weist eine Ausführungs-Pipeline auf, die einen Anweisungscache 252, eine Anweisungseinheit 254, eine Adressabbildungseinheit 256, eine Registerdatei 258, einen oder mehrere GPGPU(Allzweck-Grafikverarbeitungseinheit)-Kerne 262 und einen oder mehr Lade/Speicher-Einheiten 266 aufweist. Die GPGPU-Kerne 262 und Lade/Speicher-Einheiten 266 sind über eine Speicher- und Cache-Interconnect 268 mit dem Cachespeicher 272 und dem gemeinsam genutzten Speicher 270 gekoppelt. Der Grafikmultiprozessor 234 kann zusätzlich Tensor- und/oder Strahlverfolgungskerne 263 beinhalten, die Hardwarelogik beinhalten, um Matrix- und/oder Strahlverfolgungsoperationen zu beschleunigen.
  • Der Anweisungscache 252 kann einen Strom von Anweisungen zur Ausführung von dem Pipeline-Manager 232 empfangen. Die Anweisungen werden im Anweisungscache 252 gecacht und zur Ausführung durch die Anweisungseinheit 254 ausgegeben. Die Anweisungseinheit 254 kann Anweisungen als Thread-Gruppen (z. B. Warps) versenden, wobei jeder Thread der Thread-Gruppe einer anderen Ausführungseinheit innerhalb des GPGPU-Kerns 262 zugewiesen ist. Eine Anweisung kann auf einen beliebigen lokalen, gemeinsam genutzten oder globalen Adressraum zugreifen, indem sie eine Adresse in einem vereinheitlichten Adressraum spezifiziert. Die Adressenabbildungseinheit 256 kann verwendet werden, um Adressen in dem vereinheitlichten Adressraum in eine unterschiedliche Speicheradresse zu übersetzen, auf die von den Lade/Speicher-Einheiten 266 zugegriffen werden kann.
  • Die Registerdatei 258 stellt einen Satz von Registern für die Funktionseinheiten des Grafikmultiprozessors 234 bereit. Die Registerdatei 258 stellt einen temporären Speicher für Operanden bereit, die mit den Datenpfaden der Funktionseinheiten (z. B. GPGPU-Kerne 262, Lade/Speicher-Einheiten 266) des Grafikmultiprozessors 234 verbunden sind. Die Registerdatei 258 kann zwischen jeder der Funktionseinheiten aufgeteilt werden, sodass jeder Funktionseinheit ein dedizierter Abschnitt der Registerdatei 258 zugewiesen wird. Zum Beispiel kann die Registerdatei 258 zwischen den verschiedenen Warps aufgeteilt werden, die durch den Grafikmultiprozessor 234 ausgeführt werden.
  • Die GPGPU-Kerne 262 können jeweils Gleitkommaeinheiten (FPUs) und/oder arithmetische Ganzzahl-Logikeinheiten (ALUs) aufweisen, die zum Ausführen von Anweisungen des Grafikmultiprozessors 234 verwendet werden. In einigen Implementierungen können die GPGPU-Kerne 262 Hardwarelogik beinhalten, die sich ansonsten in den Tensor- und/oder Strahlverfolgungskernen 263 befinden kann. Die GPGPU-Kerne 262 können eine ähnliche Architektur aufweisen oder sich in der Architektur unterscheiden. Zum Beispiel und in einer Ausführungsform beinhaltet ein erster Teil der GPGPU-Kerne 262 eine Einzelpräzisions-FPU und eine Ganzzahl-ALU, während ein zweiter Teil der GPGPU-Kerne eine Doppelpräzisions-FPU beinhaltet. Optional können die FPUs den IEEE 754-2008-Standard für Gleitkomma-Arithmetik implementieren oder Gleitkomma-Arithmetik mit variabler Präzision ermöglichen. Der Grafikmultiprozessor 234 kann außerdem eine oder mehrere Festfunktions- oder Spezialfunktionseinheiten beinhalten, um spezifische Funktionen wie Rechteckkopier- oder Pixelblendingoperationen durchzuführen. Einer oder mehrere der GPGPU-Kerne können auch Fest- oder Spezialfunktionslogik enthalten.
  • Die GPGPU-Kerne 262 können eine SIMD-Logik beinhalten, die in der Lage ist, eine einzelne Anweisung an mehreren Datensätzen auszuführen. Optional können die GPGPU-Kerne 262 SIMD4-, SIMD8- und SIMD16-Anweisungen physisch ausführen und SIMD1-, SIMD2- und SIMD32-Anweisungen logisch ausführen. Die SIMD-Anweisungen für die GPGPU-Kerne können zur Kompilierungszeit von einem Shader-Compiler erzeugt oder automatisch erzeugt werden, wenn Programme ausgeführt werden, die für SPMD(Single Program Multiple Data)- oder SIMT-Architekturen geschrieben und kompiliert sind. Mehrere Threads eines für das SIMT-Ausführungsmodell konfigurierten Programms können über eine einzige SIMD-Anweisung ausgeführt werden. Zum Beispiel können in einer Ausführungsform acht SIMT-Threads, die die gleichen oder ähnliche Operationen ausführen, parallel über eine einzige SIMD8-Logikeinheit ausgeführt werden.
  • Das Speicher- und Cache-Interconnect 268 ist ein Interconnect-Netzwerk, das jede der Funktionseinheiten des Grafikmultiprozessors 234 mit der Registerdatei 258 und mit dem gemeinsam genutzten Speicher 270 verbindet. Zum Beispiel ist das Speicher- und Cache-Interconnect 268 ein Crossbar-Interconnect, das es der Lade/Speicher-Einheit 266 ermöglicht, Lade- und Speicheroperationen zwischen dem gemeinsam genutzten Speicher 270 und der Registerdatei 258 zu implementieren. Die Registerdatei 258 kann mit der gleichen Frequenz wie die GPGPU-Kerne 262 arbeiten, sodass die Datenübertragung zwischen den GPGPU-Kernen 262 und der Registerdatei 258 eine sehr niedrige Latenz hat. Der gemeinsam genutzte Speicher 270 kann verwendet werden, um eine Kommunikation zwischen Threads zu ermöglichen, die auf den Funktionseinheiten innerhalb des Grafikmultiprozessors 234 ausgeführt werden. Der Cachespeicher 272 kann beispielsweise als ein Datencache verwendet werden, um Texturdaten zwischen den Funktionseinheiten und der Textureinheit 236 zu cachen. Der gemeinsam genutzte Speicher 270 kann auch als ein gecachtes Programm verwendet werden. Threads, die auf den GPGPU-Kernen 262 ausgeführt werden, können programmatisch Daten in dem gemeinsam genutzten Speicher zusätzlich zu den automatisch gecachten Daten speichern, die in dem Cachespeicher 272 gespeichert sind.
  • 3A-3C veranschaulichen zusätzliche Grafikmultiprozessoren gemäß Ausführungsformen. 3A- 3B veranschaulichen Grafikmultiprozessoren 325, 350, die mit den Grafikmultiprozessor 234 von 2C in Zusammenhang stehen und anstelle von einem von diesen verwendet werden können. Daher offenbart die Offenbarung jeglicher Merkmale in Kombination mit dem Grafikmultiprozessor 234 hierin auch eine entsprechende Kombination mit dem einen oder den mehreren Grafikmultiprozessoren 325, 350, ist aber nicht darauf beschränkt. 3C veranschaulicht eine Grafikverarbeitungseinheit (GPU) 380, die dedizierte Sätze von Grafikverarbeitungsressourcen beinhaltet, die in Mehrkerngruppen 365A - 365N angeordnet sind, die den Grafikmultiprozessoren 325, 350 entsprechen. Die veranschaulichten Grafikmultiprozessoren 325, 350 und die Mehrkerngruppen 365A-365N können Streaming-Multiprozessoren (SM) sein, die in der Lage sind, gleichzeitig eine große Anzahl von Ausführungs-Threads auszuführen.
  • Der Grafikmultiprozessor 325 von 3A beinhaltet mehrere zusätzliche Instanzen von Ausführungsressourceneinheiten relativ zu dem Grafikmultiprozessor 234 von 2D. Zum Beispiel kann der Grafikmultiprozessor 325 mehrere Instanzen der Anweisungseinheit 332A-332B, der Registerdatei 334A-334B und der einen oder der mehreren Textureinheiten 344A-344B aufweisen. Der Grafikmultiprozessor 325 beinhaltet auch mehrere Sätze von Grafik- oder Rechenausführungseinheiten (z. B. GPGPU-Kern 336A-336B, Tensorkern 337A-337B, Strahlenverfolgungskern 338A-338B) und mehrere Sätze von Lade/Speicher-Einheiten 340A-340B. Die Ausführungsressourceneinheiten weisen einen gemeinsamen Anweisungscache 330, einen Textur- und/oder Datencachespeicher 342 und einen gemeinsam genutzten Speicher 346 auf.
  • Die verschiedenen Komponenten können über ein Interconnect-Fabric 327 kommunizieren. Das Interconnect-Fabric 327 kann einen oder mehrere Crossbar-Schalter beinhalten, um eine Kommunikation zwischen den verschiedenen Komponenten des Grafikmultiprozessors 325 zu ermöglichen. Das Interconnect-Fabric 327 kann eine separate Hochgeschwindigkeits-Netzwerk-Fabric-Schicht sein, auf der jede Komponente des Grafikmultiprozessors 325 gestapelt ist. Die Komponenten des Grafikmultiprozessors 325 kommunizieren mit entfernten Komponenten über das Interconnect-Fabric 327. Zum Beispiel können die GPGPU-Kerne 336A-336B, 337A-337B und 3378A-338B jeweils mit dem gemeinsam genutzten Speicher 346 über das Interconnect-Fabric 327 kommunizieren. Das Interconnect-Fabric 327 kann die Kommunikation innerhalb des Grafikmultiprozessors 325 vermitteln, um eine faire Bandbreitenzuordnung zwischen den Komponenten sicherzustellen.
  • Der Grafikmultiprozessor 350 von 3B beinhaltet mehrere Sätze von Ausführungsressourcen 356A-356D, wobei jeder Satz von Ausführungsressourcen mehrere Anweisungseinheiten, Registerdateien, GPGPU-Kerne und Lade/Speicher-Einheiten beinhaltet, wie in 2D und 3A veranschaulicht. Die Ausführungsressourcen 356A-356D können mit einer oder mehreren Textureinheiten 360A-360D für Texturoperationen zusammenarbeiten, während sie sich einen Anweisungscache 354 und einen gemeinsam genutzten Speicher 353 teilen. Zum Beispiel können sich die Ausführungsressourcen 356A- 356D einen Anweisungscache 354 und einen gemeinsam genutzten Speicher 353 sowie mehrere Instanzen eines Textur- und/oder Datencachespeichers 358A- 358B teilen. Die verschiedenen Komponenten können über ein Interconnect-Fabric 352 ähnlich dem Interconnect-Fabric 327 von 3A kommunizieren.
  • Fachleute werden verstehen, dass die in 1, 2A-2D und 3A-3B beschriebenen Architekturen beschreibend sind und den Schutzumfang der vorliegenden Ausführungsformen nicht einschränken. Somit können die hierin beschriebenen Techniken auf jeder ordnungsgemäß konfigurierten Verarbeitungseinheit implementiert werden, darunter, ohne Einschränkung, ein oder mehrere Mobilanwendungsprozessoren, eine oder mehrere Desktop- oder Server-Zentralverarbeitungseinheiten (CPUs), einschließlich Mehrkern-CPUs, eine oder mehrere Parallelverarbeitungseinheiten, wie etwa die Parallelverarbeitungseinheit 202 von 2A, sowie ein oder mehrere Grafikprozessoren oder Spezialverarbeitungseinheiten, ohne vom Schutzumfang der hierin beschriebenen Ausführungsformen abzuweichen.
  • Der Parallelprozessor oder die GPGPU, wie hierin beschrieben, können kommunikativ mit Host-/Prozessorkernen gekoppelt sein, um Grafikoperationen, Maschinenlernoperationen, Musteranalyseoperationen und verschiedene Allzweck-GPU(GPGPU)-Funktionen zu beschleunigen. Die GPU kann über einen Bus oder ein anderes Interconnect (z. B. ein Hochgeschwindigkeits-Interconnect wie etwa PCIe oder NVLink) kommunikativ mit dem Hostprozessor/den Kernen verbunden sein. In anderen Ausführungsformen kann die GPU auf demselben Package oder Chip wie die Kerne integriert sein und über einen internen Prozessorbus/ein Interconnect (d. h. innerhalb des Package oder Chips) kommunikativ mit den Kernen gekoppelt sein. Unabhängig von der Art und Weise, auf welche die GPU verbunden ist, können die Prozessorkerne der GPU Arbeit in Form von in einem Arbeitsdeskriptor enthaltenen Sequenzen von Befehlen/Anweisungen zuweisen. Die GPU verwendet dann eine dedizierte Schaltungsanordnung/Logik zum effizienten Verarbeiten dieser Befehle/Anweisungen.
  • 3C veranschaulicht eine Grafikverarbeitungseinheit (GPU) 380, die dedizierte Sätze von Grafikverarbeitungsressourcen beinhaltet, die in Mehrkerngruppen 365A - 365N angeordnet sind. Während die Einzelheiten lediglich einer einzigen Mehrkerngruppe 365A bereitgestellt sind, versteht es sich, dass die anderen Mehrkerngruppen 365B-365N mit den gleichen oder ähnlichen Sätzen von Grafikverarbeitungsressourcen ausgestattet sein können. Einzelheiten, die in Bezug auf die Mehrkerngruppen 365A-365N beschrieben sind, können auch für jeden beliebigen hierin beschriebenen Grafikmultiprozessor 234, 325, 350 gelten.
  • Wie veranschaulicht, kann eine Mehrkerngruppe 365A einen Satz von Grafikkernen 370, einen Satz von Tensorkernen 371 und einen Satz von Strahlverfolgungskernen 372 beinhalten. Ein Scheduler/Dispatcher 368 plant und sendet die Grafik-Threads zur Ausführung auf den verschiedenen Kernen 370, 371, 372 aus. Ein Satz von Registerdateien 369 speichert Operandenwerte, die von den Kernen 370, 371, 372 verwendet werden, wenn die Grafik-Threads ausgeführt werden. Diese können zum Beispiel Ganzzahlregister zum Speichern von Ganzzahlwerten, Gleitkommaregister zum Speichern von Gleitkommawerten, Vektorregister zum Speichern von gepackten Datenelementen (Ganzzahl- und/oder Gleitkommadatenelementen) und Kachelregister zum Speichern von Tensor-/Matrixwerten beinhalten. Die Kachelregister können als kombinierte Sätze von Vektorregistern implementiert werden.
  • Ein oder mehrere kombinierte Level-1(L1)-Caches und gemeinsam genutzte Speichereinheiten 373 speichern Grafikdaten, wie Texturdaten, Vertexdaten, Pixeldaten, Strahlendaten, Begrenzungsvolumendaten usw., lokal innerhalb jeder Mehrkerngruppe 365A. Eine oder mehrere Textureinheiten 374 können auch verwendet werden, um Texturierungsoperationen, wie etwa Texturabbildung und Abtastung, durchzuführen. Ein Level-2(L2)-Cache 375, der durch alle oder eine Teilmenge der Mehrkerngruppen 365A-365N gemeinsam genutzt wird, speichert Grafikdaten und/oder Anweisungen für mehrere gleichzeitige Grafik-Threads. Wie veranschaulicht, kann der L2-Cache 375 über mehrere Mehrkerngruppen 365A-365N gemeinsam genutzt werden. Eine oder mehrere Speichersteuerungen 367 koppeln die GPU 380 mit einem Speicher 366, der ein Systemspeicher (z. B. DRAM) und/oder ein dedizierter Grafikspeicher (z. B. GDDR6-Speicher) sein kann.
  • Eine Eingabe/Ausgabe(E/A)-Schaltungsanordnung 363 koppelt die GPU 380 mit einer oder mehreren E/A-Vorrichtungen 362, wie etwa Digitalsignalprozessoren (DSPs), Netzwerksteuerungen oder Benutzereingabevorrichtungen. Ein On-Chip-Interconnect kann verwendet werden, um die E/A-Vorrichtungen 362 mit der GPU 380 und dem Speicher 366 zu koppeln. Eine oder mehrere E/A-Speicherverwaltungseinheiten (IOMMUs) 364 der E/A-Schaltungsanordnung 363 koppeln die E/A-Vorrichtungen 362 direkt mit dem Systemspeicher 366. Optional verwaltet die IOMMU 364 mehrere Sätze von Seitentabellen, um virtuelle Adressen auf physische Adressen im Systemspeicher 366 abzubilden. Die E/A-Vorrichtungen 362, die CPU(s) 361 und die GPU(s) 380 können sich dann denselben virtuellen Adressraum teilen.
  • In einer Implementierung der IOMMU 364 unterstützt die IOMMU 364 die Virtualisierung. In diesem Fall kann sie einen ersten Satz von Seitentabellen dahingehend verwalten, virtuelle Gast-/Grafikadressen auf physische Gast-/Grafikadressen abzubilden, und einen zweiten Satz von Seitentabellen dahingehend verwalten, die physischen Gast-/Grafikadressen auf physische System-/Hostadressen (z. B. innerhalb des Systemspeichers 366) abzubilden. Die Basisadressen sowohl des ersten als auch des zweiten Satzes von Seitentabellen können in Steuerregistern gespeichert werden und bei einem Kontextwechsel ausgelagert werden (z. B. sodass der neue Kontext Zugriff auf den relevanten Satz von Seitentabellen erhält). Obgleich dies in 3C nicht veranschaulicht ist, kann jeder der Kerne 370, 371, 372 und/oder die Mehrkerngruppen 365A-365N Übersetzungspuffer (TLBs: Translation Lookaside Buffers) beinhalten, um Virtuell-Gast-zu-Physisch-Gast-Übersetzungen, Physisch-Gast-zu-Physisch-Host-Übersetzungen und Virtuell-Gast-zu-Physisch-Host-Übersetzungen zu cachen.
  • Die CPUs 361, die GPUs 380 und die I/O-Vorrichtungen 362 können auf einem einzelnen Halbleiterchip und/oder Chip-Package integriert sein. Der veranschaulichte Speicher 366 kann auf demselben Chip integriert sein oder kann über eine chip externe Schnittstelle mit den Speichersteuerungen 367 gekoppelt sein. In einer Implementierung umfasst der Speicher 366 einen GDDR6-Speicher, der denselben virtuellen Adressraum wie andere physische Speicher auf Systemebene teilt, obwohl die hierin beschriebenen zugrundeliegenden Prinzipien nicht auf diese spezielle Implementierung beschränkt sind.
  • Die Tensorkerne 371 können eine Vielzahl von Ausführungseinheiten beinhalten, die speziell dafür ausgelegt sind, Matrixoperationen durchzuführen, die die grundlegende Rechenoperation sind, die verwendet wird, um Deep-Learning-Operationen durchzuführen. Zum Beispiel können simultane Matrixmultiplikationsoperationen für neuronales Netzwerktraining und Inferenz verwendet werden. Die Tensorkerne 371 können eine Matrixverarbeitung unter Verwendung einer Vielzahl von Operandenpräzisionen durchführen, darunter Gleitkomma mit einfacher Präzision (z. B. 32 Bit), Gleitkomma mit halber Präzision (z. B. 16 Bit), Ganzzahlwörter (16 Bit), Bytes (8 Bit) und Halbbytes (4 Bits). Beispielsweise extrahiert eine Neuronalnetzwerkimplementierung Merkmale jeder gerenderten Szene, wobei möglicherweise Details aus mehreren Frames kombiniert werden, um ein hochwertiges Endbild zu konstruieren.
  • Bei Deep-Learning-Implementierungen kann Parallelmatrix-Multiplikationsarbeit zur Ausführung auf den Tensorkernen 371 geplant werden. Insbesondere das Training neuronaler Netzwerke erfordert eine signifikante Anzahl von Matrix-Skalarprodukt-Operationen. Um eine Innenproduktformulierung einer N × N × N Matrixmultiplikation zu verarbeiten, können die Tensorkerne 371 mindestens N Skalarprodukt-Verarbeitungselemente beinhalten. Bevor die Matrixmultiplikation beginnt, wird eine ganze Matrix in Kachelregister geladen und wird pro Zyklus für N Zyklen mindestens eine Spalte einer zweiten Matrix geladen. In jedem Zyklus gibt es N Skalarprodukte, die verarbeitet werden.
  • Matrixelemente können in Abhängigkeit von der speziellen Implementierung mit unterschiedlichen Präzisionen gespeichert werden, darunter 16-Bit-Wörter, 8-Bit-Bytes (z. B. INT8) und 4-Bit-Halbbytes (z. B. INT4). Modi mit unterschiedlichen Präzisionen können für die Tensorkerne 371 spezifiziert werden, um sicherzustellen, dass die effizienteste Präzision für unterschiedliche Arbeitslasten verwendet wird (z. B. wie etwa Inferenzieren von Arbeitslasten, die Quantisierung zu Bytes und Halbbytes tolerieren können).
  • Die Strahlverfolgungskerne 372 können Strahlverfolgungsoperationen sowohl für Echtzeit-Strahlverfolgungs- als auch für Nicht-Echtzeit-Strahlverfolgungsimplementierungen beschleunigen. Insbesondere können die Strahlverfolgungskerne 372 eine Strahldurchquerungs-/-schnittpunktschaltungsanordnung zum Durchführen einer Strahldurchquerung unter Verwendung von Hüllkörperhierarchien (BVHs: Bounding Volume Hierarchies) und Identifizieren von Schnittpunkten zwischen Strahlen und Primitiven, die in den BVH-Volumina enthalten sind, beinhalten. Die Strahlverfolgungskerne 372 können auch Schaltungsanordnungen zum Durchführen von Tiefenprüfung und -Culling (z. B. unter Verwendung eines Z-Puffers oder einer ähnlichen Anordnung) beinhalten. Bei einer Implementierung führen die Strahlverfolgungskerne 372 Durchquerungs- und Schnittoperationen in Übereinstimmung mit den hierin beschriebenen Bildentrauschungstechniken durch, von denen zumindest ein Teil auf den Tensorkernen 371 ausgeführt werden kann. Zum Beispiel können die Tensorkerne 371 ein neuronales Deep-Learning-Netzwerk implementieren, um eine Entrauschung von Frames durchzuführen, die durch die Strahlenverfolgungskerne 372 erzeugt werden. Die CPU(s) 361, Grafikkerne 370 und/oder Strahlenverfolgungskerne 372 können jedoch auch alle oder einen Teil der Entrauschungs- und/oder Deep-Learning-Algorithmen implementieren.
  • Zudem kann, wie oben beschrieben, ein verteilter Ansatz zum Entrauschen eingesetzt werden, bei dem sich die GPU 380 in einer Rechenvorrichtung befindet, die über ein Netzwerk oder ein Hochgeschwindigkeits-Interconnect mit anderen Rechenvorrichtungen gekoppelt ist. Bei diesem verteilten Ansatz können sich die miteinander verbundenen Rechenvorrichtungen Neuronalnetzwerk-Lern-/-Trainingsdaten teilen, um die Geschwindigkeit zu verbessern, mit der das Gesamtsystem lernt, eine Entrauschung für unterschiedliche Arten von Bildframes und/oder unterschiedliche Grafikanwendungen durchzuführen.
  • Die Strahlverfolgungskerne 372 können alle BVH-Durchquerungen und/oder Strahl-Primitiv-Schnittpunkte verarbeiten, wodurch verhindert wird, dass die Grafikkerne 370 mit tausenden Anweisungen pro Strahl überlastet werden. Zum Beispiel beinhaltet jeder Strahlverfolgungskern 372 einen ersten Satz spezialisierter Schaltungsanordnungen zum Durchführen von Hüllquaderprüfungen (z. B. für Durchquerungsoperationen) und/oder einen zweiten Satz spezialisierter Schaltungsanordnungen zum Durchführen der Strahl-Dreieck-Schnittpunktprüfungen (z. B. schneidende Strahlen, die durchlaufen wurden). Somit kann zum Beispiel die Mehrkerngruppe 365A einfach eine Strahlsonde starten, und die Strahlverfolgungskerne 372 führen unabhängig Strahldurchquerung und -schneidung durch und geben Trefferdaten (z. B. ein Treffer, kein Treffer, mehrere Treffer usw.) an den Thread-Kontext zurück. Die anderen Kerne 370, 371 werden freigegeben, um andere Grafik- oder Rechenarbeit durchzuführen, während die Strahlverfolgungskerne 372 die Durchquerungs- und Schnittoperationen durchführen.
  • Optional kann jeder Strahlverfolgungskern 372 eine Durchquerungseinheit zum Durchführen von BVH-Prüfungsoperationen und/oder eine Schnittpunkteinheit, die Strahl-Primitiv-Schnittpunktprüfungen durchführt, beinhalten. Die Schnittpunkteinheit erzeugt eine „Treffer“, „kein Treffer“ oder „Mehrfachtreffer“ Antwort, die sie dem geeigneten Thread bereitstellt. Während der Durchquerungs- und Schnittpunktoperationen werden die Ausführungsressourcen der anderen Kerne (z. B. Grafikkerne 370 und Tensorkerne 371) freigegeben, um andere Arten von Grafikarbeit durchzuführen.
  • In einer unten beschriebenen optionalen Ausführungsform wird ein hybrider Rasterisierung/Strahlverfolgung-Ansatz verwendet, bei dem Arbeit zwischen den Grafikkernen 370 und den Strahlverfolgungskernen 372 verteilt wird.
  • Die Strahlverfolgungskerne 372 (und/oder andere Kerne 370, 371) können Hardwareunterstützung für einen Strahlverfolgungsanweisungssatz, wie etwa DirectX Ray Tracing (DXR) von Microsoft, der einen DispatchRays-Befehl beinhaltet, sowie Strahlerzeugung, Closest-Hit-, Any-Hit- und Fehltreffer-Shader, die die Zuweisung eindeutiger Sätze von Shadern und Texturen für jedes Objekt ermöglichen, beinhalten. Eine andere Strahlverfolgungsplattform, die durch die Strahlverfolgungskerne 372, Grafikkerne 370 und Tensorkerne 371 unterstützt werden kann, ist Vulkan 1.1.85. Es ist jedoch zu beachten, dass die hierin beschriebenen zugrundeliegenden Prinzipien nicht auf irgendeine spezielle Strahlverfolgungs-ISA beschränkt sind.
  • Im Allgemeinen können die verschiedenen Kerne 372, 371, 370 einen Strahlverfolgungsanweisungssatz unterstützen, der Anweisungen/Funktionen für Strahlerzeugung und/oder Closest-Hit und/oder Any-Hit und/oder Strahl-Primitiv-Schnittpunkt und/oder Primitiv-weise und hierarchische Hüllquaderkonstruktion und/oder Fehltreffer und/oder Visit und/oder Ausnahmen enthält. Genauer gesagt beinhaltet eine bevorzugte Ausführungsform Strahlverfolgungsanweisungen zum Durchführen einer oder mehrerer der folgenden Funktionen:
  • Strahlenerzeugung - Strahlenerzeugungsanweisungen können für jedes Pixel, jedes Abtastung oder jede andere benutzerdefinierte Arbeitszuweisung ausgeführt werden.
  • Closest-Hit - Eine Closest-Hit-Anweisung kann ausgeführt werden, um den nächstgelegenen Schnittpunkt eines Strahls mit Primitiven innerhalb einer Szene zu lokalisieren.
  • Any-Hit - Eine Any-Hit-Anweisung identifiziert mehrere Schnittpunkte zwischen einem Strahl und Primitiven innerhalb einer Szene, um potenziell einen neuen nächstgelegenen Schnittpunkt zu identifizieren.
  • Schnittpunkt - Eine Schnittpunktanweisung führt eine Strahl-Primitiv-Schnittpunktprüfung durch und gibt ein Ergebnis aus.
  • Primitiv-weise Hüllquaderkonstruktion - Diese Anweisung erstellt einen Hüllquader um ein gegebenes Primitiv oder eine gegebene Gruppe von Primitiven herum (z. B. wenn eine neue BVH- oder andere Beschleunigungsdatenstruktur erstellt wird).
  • Fehltreffer - gibt an, dass ein Strahl alle Geometrie innerhalb einer Szene oder ein spezifiziertes Gebiet einer Szene verfehlt.
  • Visit - gibt die Nachfolgevolumina an, die ein Strahl durchlaufen wird.
  • Ausnahmen - beinhalten verschiedene Typen von Ausnahme-Handler (z. B. für verschiedene Fehlerbedingungen aufgerufen).
  • Techniken zur Verbindung zwischen GPU und Hostprozessor
  • 4A veranschaulicht eine beispielhafte Architektur, in der mehrere GPUs 410-413, z. B. wie etwa die in 2A gezeigten Parallelprozessoren 200, kommunikativ mit mehreren Mehrkernprozessoren 405-406 über Hochgeschwindigkeitslinks 440A-440D (z. B. Busse, Punkt-zu-Punkt-Interconnects usw.) gekoppelt sind. Die Hochgeschwindigkeitslinks 440A - 440D können je nach Implementierung einen Kommunikationsdurchsatz von 4 GB/s, 30 GB/s, 80 GB/s oder höher unterstützen. Verschiedene Interconnect-Protokolle können verwendet werden, einschließlich, jedoch nicht beschränkt auf PCIe 4.0 oder 5.0 und NVLink 2.0. Die hierin beschriebenen zugrundeliegenden Prinzipien sind jedoch nicht auf ein bestimmtes Kommunikationsprotokoll oder einen bestimmten Durchsatz beschränkt.
  • Zwei oder mehr der GPUs 410 - 413 können über Hochgeschwindigkeitslinks 442A - 442B miteinander verbunden sein, die unter Verwendung der gleichen oder anderer Protokolle/Links als denen, die für die Hochgeschwindigkeitslinks 440A - 440D verwendet werden, implementiert werden können. In ähnlicher Weise können zwei oder mehrere der Mehrkernprozessoren 405-406 über einen Hochgeschwindigkeitslink 443 verbunden sein, der SMP(symmetrischer Multiprozessor)-Busse sein kann, die mit 20 GB/s, 30 GB/s, 120 GB/s oder höher arbeiten. Alternativ kann die gesamte Kommunikation zwischen den in 4A gezeigten verschiedenen Systemkomponenten unter Verwendung der gleichen Protokolle/Links (z. B. über eine gemeinsame Verbindungs-Fabric) erreicht werden. Wie erwähnt, sind die hierin beschriebenen zugrundeliegenden Prinzipien jedoch nicht auf eine bestimmte Art von Interconnect-Technologie beschränkt.
  • Jeder Mehrkernprozessor 405 - 406 kann über Speicher-Interconnects 430A - 430B jeweils kommunikativ mit einem Prozessorspeicher 401 - 402 gekoppelt sein, und jede GPU 410 - 413 ist über GPU-Speicher-Interconnects 450A - 450D jeweils kommunikativ mit dem GPU-Speicher 420 - 423 gekoppelt. Die Speicher-Interconnects 430A-430B und 450A-450D können die gleichen oder unterschiedliche Speicherzugriffstechnologien nutzen. Beispielhaft und nicht einschränkend können die Prozessorspeicher 401-402 und die GPU-Speicher 420-423 flüchtige Speicher wie dynamische Direktzugriffsspeicher (DRAMs) (einschließlich gestapelter DRAMs), Grafik-DDR-SDRAM (GDDR) (z. B. GDDR5, GDDR6) oder Hochbandbreitenspeicher (HBM: High-Bandwidth-Memory) sein und/oder können nichtflüchtige Speicher wie 3D XPoint/Optane oder Nano-Ram sein. Beispielsweise kann ein Teil der Speicher ein flüchtiger Speicher sein und ein anderer Teil kann ein nichtflüchtiger Speicher sein (z. B. unter Verwendung einer 2LM-Hierarchie (2LM: Two-Level Memory - Zwei-Ebenen-Speicher)).
  • Wie nachstehend beschrieben, kann, wenngleich die verschiedenen Prozessoren 405-406 und GPUs 410-413 physisch jeweils mit einem bestimmten Speicher 401-402, 420-423 gekoppelt sein können, eine vereinheitlichte Speicherarchitektur implementiert sein, in der derselbe virtuelle Systemadressraum (auch als der „effektive Adressraum“ bezeichnet) unter allen verschiedenen physischen Speichern verteilt ist. Zum Beispiel können die Prozessorspeicher 401-402 jeweils 64 GB des Systemspeicheradressraums umfassen, und die GPU-Speicher 420-423 können jeweils 32 GB des Systemspeicheradressraums umfassen (was in diesem Beispiel zu insgesamt 256 GB adressierbarem Speicher führt).
  • 4B veranschaulicht zusätzliche optionale Einzelheiten für eine Verbindung zwischen einem Mehrkernprozessor 407 und einem Grafikbeschleunigungsmodul 446. Das Grafikbeschleunigungsmodul 446 kann einen oder mehrere GPU-Chips aufweisen, die auf einer Leitungskarte integriert sind, die über die Hochgeschwindigkeitslink 440 mit dem Prozessor 407 gekoppelt ist. Alternativ kann das Grafikbeschleunigungsmodul 446 auf dem gleichen Package oder Chip wie der Prozessor 407 integriert sein.
  • Der veranschaulichte Prozessor 407 weist mehrere Kerne 460A-460D mit jeweils einem Übersetzungspuffer 461A-461D und einem oder mehreren Caches 462A-462D auf. Die Kerne können verschiedene andere Komponenten zum Ausführen von Anweisungen und zum Verarbeiten von Daten beinhalten, die nicht veranschaulicht sind, um zu vermeiden, dass die zugrundeliegenden Prinzipien der hierin beschriebenen Komponenten (z. B. Anweisungsabrufeinheiten, Verzweigungsvorhersageeinheiten, Decodierer, Ausführungseinheiten, Neuordnungspuffer usw.) unklar werden. Die Caches 462A-462D können Level-1(L1)- und Level-2(L2)-Caches umfassen. Außerdem können ein oder mehrere gemeinsam genutzte Caches 456 in der Caching-Hierarchie enthalten sein und durch Sätze der Kerne 460A-460D gemeinsam genutzt werden. Zum Beispiel weist eine Ausführungsform des Prozessors 407 24 Kerne auf, jeder mit seinem 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 Prozessorspeicher 401-402 beinhalten kann.
  • Die Kohärenz wird für Daten und Anweisungen, die in den verschiedenen Caches 462A-462D, 456 und dem Systemspeicher 441 gespeichert sind, über eine Inter-Kern-Kommunikation über einen Kohärenzbus 464 aufrechterhalten. Zum Beispiel kann jeder Cache eine mit diesem assoziierte Cachekohärenzlogik/-schaltungsanordnung aufweisen, um als Reaktion auf detektierte Lese- oder Schreibvorgänge auf bestimmte Cachezeilen über den Kohärenzbus 464 zu kommunizieren. In einer Implementierung wird ein Cache-Snooping-Protokoll über den Kohärenzbus 464 implementiert, um Cachezugriffe zu snoopen. Cache-Snooping-/Kohärenztechniken sind Fachleuten gut bekannt und werden hier nicht detailliert beschrieben, um zu vermeiden, dass die hierin beschriebenen zugrundeliegenden Prinzipien unklar werden.
  • Eine Proxyschaltung 425 kann bereitgestellt sein, die das Grafikbeschleunigungsmodul 446 kommunikativ mit dem Kohärenzbus 464 koppelt, wodurch ermöglicht wird, dass das Grafikbeschleunigungsmodul 446 als ein Peer der Kerne am Cache-Kohärenzprotokoll teilnimmt. Insbesondere stellt eine Schnittstelle 435 eine Konnektivität zu der Proxyschaltung 425 über einen Hochgeschwindigkeitslink 440 (z. B. einen PCIe-Bus, NVLink usw.) bereit und eine Schnittstelle 437 verbindet das Grafikbeschleunigungsmodul 446 mit dem Hochgeschwindigkeitslink 440.
  • Bei einer Implementierung stellt eine Beschleunigerintegrationsschaltung 436 Cache-Verwaltungs-, Speicherzugriffs-, Kontextverwaltungs- und Interrupt-Verwaltungsdienste für mehrere Grafikverarbeitungs-Engines 431, 432, N des Grafikbeschleunigungsmoduls 446 bereit. Die Grafikverarbeitungs-Engines 431, 432, N können jeweils eine separate Grafikverarbeitungseinheit (GPU) umfassen. Alternativ können die Grafikverarbeitungs-Engines 431, 432, N verschiedene Arten von Grafikverarbeitungs-Engines in einer GPU umfassen, wie etwa Grafikausführungseinheiten, Medienverarbeitungs-Engines (z. B. Videocodierer/-decodierer), Sampler und Blit-Engines. Mit anderen Worten kann das Grafikbeschleunigungsmodul eine GPU mit mehreren Grafikverarbeitungs-Engines 431-432, N sein oder die Grafikverarbeitungs-Engines 431-432, N können einzelne GPUs sein, die auf einem gemeinsamen Package, einer Leitungskarte oder einem Chip integriert sind.
  • Die Beschleunigerintegrationsschaltung 436 kann eine Speicherverwaltungseinheit (MMU: Memory Management Unit) 439 zum Durchführen verschiedener Speicherverwaltungsfunktionen wie etwa Übersetzungen von virtuellem in physischen Speicher (auch als Übersetzungen von effektivem in realen Speicher bezeichnet) und Speicherzugriffsprotokolle zum Zugriff auf den Systemspeicher 441 beinhalten. Die MMU 439 kann auch einen Übersetzungspuffer (TLB) (nicht gezeigt) zum Cachen der Übersetzungen von virtuellen/effektiven in physische/reale Adressen aufweisen. In einer Implementierung speichert ein Cache 438 Befehle und Daten für einen effizienten Zugriff durch die Grafikverarbeitungs-Engines 431 - 432, N. Die im Cache 438 und den Grafikspeichern 433 - 434, M gespeicherten Daten können mit den Kern-Caches 462A - 462D, 456 und dem Systemspeicher 411 kohärent gehalten werden. Wie erwähnt, kann dies über die Proxyschaltung 425 erreicht werden, die am Cache-Kohärenzmechanismus für den Cache 438 und die Speicher 433-434, M teilnimmt (z. B. Senden von Aktualisierungen an den Cache 438 in Bezug auf Modifikationen/Zugriffe auf Cache-Zeilen auf den Prozessor-Caches 462A-462D, 456 und Empfangen von Aktualisierungen vom Cache 438).
  • Ein Satz von Registern 445 speichert Kontextdaten für Threads, die durch die Grafikprozessor-Engines 431-432, N ausgeführt werden, und eine Kontextverwaltungsschaltung 448 verwaltet die Thread-Kontexte. Zum Beispiel kann die Kontextverwaltungsschaltung 448 Speicher- und Wiederherstellungsoperationen zum Speichern und Wiederherstellen von Kontexten der verschiedenen Threads während Kontextwechseln durchführen (z. B. wenn ein erster Thread gespeichert wird und ein zweiter Thread gespeichert wird, sodass der zweite Thread durch eine Grafikverarbeitungs-Engine ausgeführt werden kann). Zum Beispiel kann die Kontextverwaltungsschaltung 448 bei einem Kontextwechsel aktuelle Registerwerte in einem designierten Bereich im Speicher (z. B. durch einen Kontextzeiger identifiziert) speichern. Sie kann dann die Registerwerte wiederherstellen, wenn sie zum Kontext zurückkehrt. Eine Interrupt-Verwaltungsschaltung 447 kann beispielsweise Interrupts empfangen und verarbeiten, die von Systemvorrichtungen empfangen werden.
  • In einer Implementierung werden virtuelle/effektive Adressen von einer Grafikverarbeitungs-Engine 431 durch die MMU 439 in reale/physische Adressen im Systemspeicher 411 übersetzt. Optional unterstützt die Beschleunigerintegrationsschaltung 436 mehrere (z. B. 4, 8, 16) Grafikbeschleunigermodule 446 und/oder andere Beschleunigervorrichtungen. Das Grafikbeschleunigermodul 446 kann für eine einzelne Anwendung dediziert sein, die auf dem Prozessor 407 ausgeführt wird, oder kann von mehreren Anwendungen gemeinsam genutzt werden. Optional wird eine virtualisierte Grafikausführungsumgebung bereitgestellt, in der die Ressourcen der Grafikverarbeitungs-Engines 431 - 432, N mit mehreren Anwendungen oder virtuellen Maschinen (VMs) geteilt werden. Die Ressourcen können in „Slices“ unterteilt sein, die verschiedenen VMs und/oder Anwendungen auf der Grundlage der Verarbeitungsanforderungen und -prioritäten zugewiesen sind, die den VMs und/oder Anwendungen zugeordnet sind.
  • Somit wirkt die Beschleunigerintegrationsschaltung 436 als Brücke zum System für das Grafikbeschleunigungsmodul 446 und stellt Adressübersetzungs- und Systemspeichercachedienste bereit. In einer Ausführungsform kann die Beschleunigerintegrationsschaltung 436 zur Erleichterung der Überbrückungsfunktionalität auch gemeinsam genutzte E/A 497 (z. B. PCIe, USB) und Hardware beinhalten, um eine Systemsteuerung von Spannung, Taktung, Leistungsfähigkeit, Temperatur und Sicherheit zu ermöglichen. Die gemeinsam genutzte E/A 497 kann separate physische Verbindungen verwenden oder kann den Hochgeschwindigkeitslink 440 durchlaufen. Außerdem kann die Beschleunigerintegrationsschaltung 436 Virtualisierungseinrichtungen für den Host-Prozessor bereitstellen, um die Virtualisierung der Grafikverarbeitungs-Engines, Interrupts und Speicherverwaltung zu verwalten.
  • Da Hardwareressourcen der Grafikverarbeitungs-Engines 431-432, N explizit auf den realen Adressraum abgebildet werden, den der Hostprozessor 407 sieht, kann jeder Hostprozessor diese Ressourcen direkt unter Verwendung eines effektiven Adresswerts adressieren. Eine optionale Funktion der Beschleunigerintegrationsschaltung 436 ist die physische Trennung der Grafikverarbeitungs-Engines 431 - 432, N, sodass sie dem System als unabhängige Einheiten erscheinen.
  • Ein oder mehrere Grafikspeicher 433 - 434, M können jeweils mit jeder der Grafikverarbeitungs-Engines 431 - 432, N gekoppelt sein. Die Grafikspeicher 433 - 434, M speichern Anweisungen und Daten, die durch jede der Grafikverarbeitungs-Engines 431 - 432, N verarbeitet werden. Die Grafikspeicher 433 - 434, M können flüchtige Speicher sein, wie DRAMs (einschließlich gestapelter DRAMs), GDDR-Speicher (z. B. GDDR5, GDDR6) oder HBM, und/oder können nichtflüchtige Speicher sein, wie etwa 3D XPoint/Optane oder Nano-Ram.
  • Um den Datenverkehr über den Hochgeschwindigkeitslink 440 zu reduzieren, können Biasing-Techniken verwendet werden, um sicherzustellen, dass die in den Grafikspeichern 433 - 434, M gespeicherten Daten Daten sind, die am häufigsten von den Grafikverarbeitungs-Engines 431-432, N verwendet werden und vorzugsweise nicht von den Kernen 460A-460D verwendet werden (zumindest nicht häufig). Gleichermaßen versucht der Biasing-Mechanismus, Daten, die von den Kernen (und vorzugsweise nicht den Grafikverarbeitungs-Engines 431-432, N) benötigt werden, in den Caches 462A-462D, 456 der Kerne und des Systemspeichers 411 zu halten.
  • Gemäß einer in 4C gezeigten Variante ist die Beschleunigerintegrationsschaltung 436 in dem Prozessor 407 integriert. Die Grafikverarbeitungs-Engines 431 - 432, N kommunizieren direkt über den Hochgeschwindigkeitslink 440 mit der Beschleunigerintegrationsschaltung 436 über die Schnittstelle 437 und die Schnittstelle 435 (die wiederum eine beliebige Form von Bus- oder Schnittstellenprotokoll verwenden können). Die Beschleunigerintegrationsschaltung 436 kann die gleichen Operationen wie die unter Bezugnahme auf 4B beschriebenen ausführen, jedoch möglicherweise mit einem höheren Durchsatz aufgrund ihrer unmittelbaren Nähe zu dem Kohärenzbus 464 und den Caches 462A-462D, 456.
  • Die beschriebenen Ausführungsformen können verschiedene Programmiermodelle unterstützen, einschließlich eines Programmiermodells mit dedizierten Prozessen (keine Virtualisierung des Grafikbeschleunigungsmoduls) und gemeinsam genutzten Programmiermodellen (mit Virtualisierung). Letzteres kann Programmiermodelle beinhalten, die von der Beschleunigerintegrationsschaltung 436 gesteuert werden, und Programmiermodelle, die von dem Grafikbeschleunigungsmodul 446 gesteuert werden.
  • In den Ausführungsformen des dedizierten Prozessmodells können die Grafikverarbeitungs-Engines 431 - 432, N einer einzelnen Anwendung oder einem einzelnen Prozess unter einem einzigen Betriebssystem dediziert sein. Die einzelne Anwendung kann andere Anwendungsanfragen an die Grafik-Engines 431-432, N leiten und eine Virtualisierung innerhalb einer VM/Partition bereitstellen.
  • In den Programmiermodellen mit dedizierten Prozessen können die Grafikverarbeitungs-Engines 431, 432, N, durch mehrere VM/Anwendungspartitionen gemeinsam genutzt werden. Die gemeinsam genutzten Modelle erfordern einen Systemhypervisor zur Virtualisierung der Grafikverarbeitungs-Engines 431-432, N, um einen Zugriff durch jedes Betriebssystem zu ermöglichen. Für Einzelpartitionssysteme ohne Hypervisor gehören die Grafikverarbeitungs-Engines 431-432, N dem Betriebssystem. In beiden Fällen kann das Betriebssystem die Grafikverarbeitungs-Engines 431-432, N virtualisieren, um Zugriff auf jeden Prozess oder jede Anwendung bereitzustellen.
  • Für das gemeinsam genutzte Programmiermodell wählt das Grafikbeschleunigungsmodul 446 oder eine einzelne Grafikverarbeitungs-Engine 431-432, N ein Prozesselement unter Verwendung eines Prozess-Handles aus. Die Prozesselemente können in dem Systemspeicher 411 gespeichert werden und unter Verwendung der hierin beschriebenen Techniken zur Übersetzung von effektiven Adressen in reale Adressen adressierbar sein. Der Prozess-Handle kann ein implementierungsspezifischer Wert sein, der dem Hostprozess bereitgestellt wird, wenn sein Kontext bei der Grafikverarbeitungs-Engine 431-432, N registriert wird (das heißt, Systemsoftware aufgerufen wird, um das Prozesselement zu der verknüpften Prozesselement-Liste hinzuzufügen). Die unteren 16 Bit des Prozess-Handles können der Offset des Prozesselements innerhalb der verknüpften Prozesselement-Liste sein.
  • 4D veranschaulicht ein beispielhaftes Beschleunigerintegrations-Slice 490. Wie hierin verwendet, umfasst ein „Slice“ einen spezifizierten Abschnitt der Verarbeitungsressourcen der Beschleunigerintegrationsschaltung 436. Der anwendungseffektive Adressraum 482 im Systemspeicher 411 speichert Prozesselemente 483. Die Prozesselemente 483 können als Reaktion auf GPU-Aufrufe 481 von Anwendungen 480 gespeichert werden, die auf dem Prozessor 407 ausgeführt werden. Ein Prozesselement 483 enthält den Prozesszustand für die entsprechende Anwendung 480. Ein Arbeitsdeskriptor (WD: Work Descriptor) 484, der in dem Prozesselement 483 enthalten ist, kann ein einziger Arbeitsauftrag sein, der durch eine Anwendung angefordert wird, oder er kann einen Zeiger auf eine Warteschlange von Arbeitsaufträgen enthalten. Im letzteren Fall ist der WD 484 ein Zeiger auf die Arbeitsauftragsanforderungswarteschlange in dem Adressraum 482 der Anwendung.
  • Das Grafikbeschleunigungsmodul 446 und/oder die einzelnen Grafikverarbeitungs-Engines 431-432, N können durch alle oder eine Teilmenge der Prozesse in dem System gemeinsam genutzt werden. Die hierin beschriebenen Technologien können beispielsweise eine Infrastruktur zum Einrichten des Prozesszustands und zum Senden eines WD 484 an ein Grafikbeschleunigungsmodul 446 zum Starten eines Arbeitsauftrags in einer virtualisierten Umgebung beinhalten.
  • In einer Implementierung ist das Programmiermodell mit dedizierten Prozessen implementierungsspezifisch. In diesem Modell gehört das Grafikbeschleunigungsmodul 446 oder eine individuelle Grafikverarbeitungs-Engine 431 einem einzelnen Prozess. Da das Grafikbeschleunigungsmodul 446 einem einzelnen Prozess gehört, initialisiert der Hypervisor die Beschleunigerintegrationsschaltung 436 für die besitzende Partition und das Betriebssystem initialisiert die Beschleunigerintegrationsschaltung 436 für den besitzenden Prozess zu dem Zeitpunkt, an dem das Grafikbeschleunigungsmodul 446 zugewiesen wird.
  • Während des Betriebs ruft eine WD-Abrufeinheit 491 im Beschleunigerintegrations-Slice 490 den nächsten WD 484 ab, der eine Indikation der von einer der Grafikverarbeitungs-Engines des Grafikbeschleunigungsmoduls 446 auszuführenden Arbeit beinhaltet. Daten von dem WD 484 können in Registern 445 gespeichert werden und durch die MMU 439, die Interrupt-Verwaltungsschaltung 447 und/oder die Kontextverwaltungsschaltung 448 wie veranschaulicht verwendet werden. Zum Beispiel kann die MMU 439 eine Segment-/Seitenlauf-Schaltungsanordnung zum Zugreifen auf Segment-/Seitentabellen 486 innerhalb des virtuellen Adressraums 485 des Betriebssystems beinhalten. Die Interrupt-Verwaltungsschaltung 447 kann Interrupt-Ereignisse 492 verarbeiten, die von dem Grafikbeschleunigungsmodul 446 empfangen werden. Wenn Grafikoperationen ausgeführt werden, wird eine effektive Adresse 493, die von einer Grafikverarbeitungs-Engine 431-432 erzeugt wird, von der MMU 439 in eine reale Adresse übersetzt.
  • Der gleiche Satz von Registern 445 kann für jede Grafikverarbeitungs-Engine 431 - 432, N und/oder das Grafikbeschleunigungsmodul 446 dupliziert und kann durch den Hypervisor oder das Betriebssystem initialisiert werden. Jedes dieser duplizierten Register kann in einem Beschleunigerintegrations-Slice 490 enthalten sein. Beispielhafte Register, die von dem Hypervisor initialisiert werden können, sind in Tabelle 1 dargestellt. Tabelle 1 - Vom Hypervisor initialisierte Register
    1 Slice-Steuerregister
    2 Realadressen(RA)-Geplante-Prozesse-Bereichszeiger
    3 Autoritätsmasken-Überschreibungsregister
    4 Interrupt-Vektor-Tabelleneintrag-Offset
    5 Interrupt-Vektor-Tabelleneintrag-Limit
    6 Zustandsregister
    7 Logikpartitions-ID
    8 Realadressen(RA)-Hypervisorbeschleunigernutzungseintragszeiger
    9 Speicherungsbeschreibungsregister
  • Beispielhafte Register, die vom Betriebssystem initialisiert werden können, sind in Tabelle 2 dargestellt. Tabelle 2 - Vom Betriebssystem initialisierte Register
    1 Prozess- und Thread-Identifizierung
    2 Effektivadressen(EA)-Kontextspeicherungs-/-wiederherstellungszeiger
    3 Virtuelladressen(VA)-Beschleunigernutzungseintragszeiger
    4 Virtuelladressen(VA)-Speicherungssegmenttabellenzeiger
    5 Autoritätsmaske
    6 Arbeitsdeskriptor
  • Jeder WD 484 kann spezifisch für ein bestimmtes Grafikbeschleunigungsmodul 446 und/oder eine Grafikverarbeitungs-Engine 431-432, N sein. Er enthält alle Informationen, die eine Grafikverarbeitungs-Engine 431-432 benötigt, um ihre Arbeit zu tun, oder er kann ein Zeiger auf einen Speicherort sein, an dem die Anwendung eine Befehlswarteschlange mit auszuführenden Arbeiten eingerichtet hat.
  • 4E veranschaulicht zusätzliche optionale Einzelheiten eines gemeinsam genutzten Modells. Es enthält einen Hypervisor-Realadressraum 498, in dem eine Prozesselementliste 499 gespeichert ist. Der Hypervisor-Realadressraum 498 ist über einen Hypervisor 496 zugänglich, der die Grafikbeschleunigungsmodul-Engines für das Betriebssystem 495 virtualisiert.
  • Die gemeinsam genutzten Programmiermodelle ermöglichen, dass alle oder eine Teilmenge von Prozessen von allen oder einer Teilmenge von Partitionen in dem System ein Grafikbeschleunigungsmodul 446 verwenden. Es gibt zwei Programmiermodelle, bei denen das Grafikbeschleunigungsmodul 446 durch mehrere Prozesse und Partitionen gemeinsam genutzt wird: eine gemeinsame Nutzung nach Zeit-Slices und eine grafikgerichtete gemeinsame Nutzung.
  • In diesem Modell hat der Systemhypervisor 496 das Grafikbeschleunigungsmodul 446 inne und stellt dessen Funktion allen Betriebssystemen 495 zur Verfügung. Damit ein Grafikbeschleunigungsmodul 446 eine Virtualisierung durch den System-Hypervisor 496 unterstützt, kann das Grafikbeschleunigungsmodul 446 die folgenden Anforderungen erfüllen: 1) Eine Arbeitsauftragsanforderung einer Anwendung muss autonom sein (das heißt, der Zustand muss nicht zwischen Arbeitsaufträgen aufrechterhalten werden), oder das Grafikbeschleunigungsmodul 446 muss einen
    Kontextsicherungs- und -wiederherstellungsmechanismus bereitstellen. 2) Das Grafikbeschleunigungsmodul 446 garantiert, dass eine Arbeitsauftragsanforderung einer Anwendung innerhalb einer spezifizierten Zeitdauer abgeschlossen wird, einschließlich etwaiger Übersetzungsfehler, oder das Grafikbeschleunigungsmodul 446 stellt die Fähigkeit bereit, die Verarbeitung des Arbeitsauftrags zurückzustellen. 3) Dem Grafikbeschleunigungsmodul 446 muss Fairness zwischen Prozessen garantiert werden, wenn es in dem gerichteten gemeinsam genutzten Programmiermodell arbeitet.
  • Für das gemeinsam genutzte Modell muss die Anwendung 480 möglicherweise einen Systemsystemaufruf des Betriebssystems 495 mit einem Typ des Grafikbeschleunigungsmoduls 446, einem Arbeitsdeskriptor (WD), einem AMR-Wert (AMR: Authority Mask Register) und einem Kontextspeicherungs-/-wiederherstellungsbereichszeiger (Context Save/Restore Area Pointer - CSRP) durchführen. Der Typ des Grafikbeschleunigungsmoduls 446 beschreibt die Zielbeschleunigungsfunktion für den Systemaufruf. Der Typ des Grafikbeschleunigungsmoduls 446 kann ein systemspezifischer Wert sein. Der WD ist speziell für das Grafikbeschleunigungsmodul 446 formatiert und kann in Form eines Befehls für das Grafikbeschleunigungsmodul 446, eines effektiven Adresszeigers für eine benutzerdefinierte Struktur, eines effektiven Adresszeigers für eine Warteschlange von Befehlen oder einer beliebigen anderen Datenstruktur vorliegen, um die von dem Grafikbeschleunigungsmodul 446 auszuführende 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 ähnelt einer Anwendung, die den AMR einstellt. Falls die Implementierungen der Beschleunigerintegrationsschaltung 436 und des Grafikbeschleunigungsmoduls 446 kein Benutzerautoritätsmasken-Überschreibungsregister (User Authority Mask Override Register - UAMOR) unterstützen, kann das Betriebssystem den aktuellen UAMOR-Wert auf den AMR-Wert anwenden, bevor es das AMR in dem Hypervisor-Aufruf übergibt. Der Hypervisor 496 kann den aktuellen Autoritätsmasken-Überschreibungsregister(AMOR)-Wert anwenden, bevor das AMR in das Prozesselement 483 platziert wird. Der CSRP kann eines der Register 445 sein, das die effektive Adresse eines Bereichs im Adressraum 482 der Anwendung für das Grafikbeschleunigungsmodul 446 zum Speichern und Wiederherstellen des Kontextzustands enthält. Dieser Zeiger ist optional, falls kein Status zwischen Arbeitsaufträgen gespeichert werden muss oder wenn ein Arbeitsauftrag zurückgestellt wird. Der Kontextspeicherungs-/- wiederherstellungsbereich kann festgelegter Systemspeicher sein.
  • Bei Empfang des Systemaufrufs kann das Betriebssystem 495 verifizieren, dass die Anwendung 480 registriert wurde und die Berechtigung zur Verwendung des Grafikbeschleunigungsmoduls 446 erhalten hat. Das Betriebssystem 495 ruft dann den Hypervisor 496 mit den in Tabelle 3 gezeigten Informationen auf. Tabelle 3 - OS-zu-Hypervisor-Aufrufparameter
    1 Ein Arbeitsdeskriptor
    2 Ein Autoritätsmaskenregister- (AMR) Wert (möglicherweise maskiert).
    3 Ein Effektivadressen(EA)-Kontextspeicher-/-wiederherstellungsbereichszeiger (CSRP)
    4 Eine Prozess-ID (PID) und optionale Thread-ID (TID)
    5 Virtuelladressen(VA)-Beschleunigernutzungseintragszeiger (AURP)
    6 Die virtuelle Adresse des Speichersegmenttabellenzeigers (SSTP)
    7 Eine logische Interrupt-Dienstnummer (LISN)
  • Nach Empfang des Hypervisor-Aufrufs verifiziert der Hypervisor 496, dass das Betriebssystem 495 registriert wurde und ihm die Berechtigung zur Verwendung des Grafikbeschleunigungsmoduls 446 gegeben wurde. Der Hypervisor 496 setzt dann das Prozesselement 483 in die mit Prozesselement verknüpfte Liste für den entsprechenden Typ des Grafikbeschleunigungsmoduls 446 ein. Das Prozesselement kann die in Tabelle 4 dargestellten Informationen enthalten. Tabelle 4 - Informationen zum Prozesselement
    1 Ein Arbeitsdeskriptor (WD)
    2 Ein Autoritätsmaskenregister(AMR)-Wert (möglicherweise maskiert).
    3 Ein Effektivadressen(EA)-Kontextspeicherungs-/- wiederherstellungsbereichszeiger (CSRP)
    4 Eine Prozess-ID (PID) und optionale Thread-ID (TID)
    5 Ein Virtuelladressen(VA)-Beschleunigernutzungseintragszeiger (AURP)
    6 Die virtuelle Adresse des Speichersegmenttabellenzeigers (SSTP)
    7 Eine logische Interrupt-Dienstnummer (LISN)
    8 Interrupt-Vektortabelle, abgeleitet von den Hypervisor-Aufrufparametern.
    9 Einen Zustandsregister(SR)-Wert
    10 Eine Logikpartitions-ID (LPID)
    11 Einen Realadressen(RA)-Hypervisorbeschleunigernutzungseintragszeiger
    12 Das Speicherdeskriptorregister (SDR)
  • Der Hypervisor kann mehrere Registern 445 des Beschleunigerintegrations-Slice 490 initialisieren.
  • Wie in 4F veranschaulicht, wird in einer optionalen Implementierung ein vereinheitlichter Speicher, der über einen gemeinsamen virtuellen Speicheradressraum adressierbar ist, der zum Zugriff auf die physischen Prozessorspeicher 401-402 und GPU-Speicher 420-423 verwendet wird, eingesetzt. Bei dieser Implementierung verwenden auf den GPUs 410-413 ausgeführte Operationen den gleichen virtuellen/effektiven Speicheradressraum, um auf die Prozessorspeicher 401-402 zuzugreifen und umgekehrt, wodurch die Programmierbarkeit vereinfacht wird. Ein erster Abschnitt des virtuellen/effektiven Speicheradressraums kann dem Prozessorspeicher 401, ein zweiter Abschnitt dem zweiten Prozessorspeicher 402, ein dritter Abschnitt dem GPU-Speicher 420 usw. zugewiesen sein. Der gesamte virtuelle/effektive Speicherraum (manchmal als effektiver Adressraum bezeichnet) kann dadurch auf jeden der Prozessorspeicher 401 - 402 und GPU-Speicher 420 - 423 verteilt werden, wodurch ermöglicht wird, dass jeder Prozessor oder jede GPU auf einen beliebigen physischen Speicher mit einer auf diesen Speicher abgebildeten virtuellen Adresse zugreifen kann.
  • Eine Bias-/Kohärenz-Verwaltungsschaltungsanordnung 494A - 494E innerhalb einer oder mehrerer der MMUs 439A - 439E kann bereitgestellt werden, die die Cache-Kohärenz zwischen den Caches der Hostprozessoren (z. B. 405) und den GPUs 410 - 413 sicherstellt und Biasing-Techniken implementiert, die die physischen Speicher angeben, in denen bestimmte Arten von Daten gespeichert werden sollten. Obgleich mehrere Instanzen der Bias-/Kohärenz-Verwaltungsschaltungsanordnung 494A-494E in 4F veranschaulicht sind, kann die Bias-/Kohärenz-Schaltungsanordnung innerhalb der MMU eines oder mehrerer Hostprozessoren 405 und/oder innerhalb der Beschleunigerintegrationsschaltung 436 implementiert sein.
  • Der an die GPU angeschlossene Speicher 420-423 kann als Teil des Systemspeichers abgebildet werden und es kann auf ihn unter Verwendung einer SVM-Technologie (SVM Shared Virtual Memory - gemeinsam genutzter virtueller Speicher) zugegriffen werden, ohne jedoch die typischen Leistungsnachteile zu erleiden, die mit vollständiger System-Cache-Kohärenz verbunden sind. Die Möglichkeit, auf den an die GPU angeschlossenen Speicher 420-423 als Systemspeicher ohne lästigen Cache-Kohärenz-Overhead zuzugreifen, bietet eine vorteilhafte Betriebsumgebung für GPU-Offload. Diese Anordnung ermöglicht es der Software des Hostprozessors 405, Operanden einzurichten und auf Berechnungsergebnisse zuzugreifen, ohne den Overhead herkömmlicher E/A-DMA-Datenkopien. Solche herkömmlichen Kopien beinhalten Treiberaufrufe, Interrupts und speicherabgebildete E/A-Zugriffe (MMIO-Zugriffe - Memory Mapped I/O), die alle in Bezug auf einfache Speicherzugriffe ineffizient sind. Gleichzeitig kann die Fähigkeit, ohne Cache-Kohärenz-Overhead auf den an die GPU angeschlossenen Speicher 420-423 zuzugreifen, 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-413 sieht, erheblich reduzieren. Die Effizienz der Operandeneinrichtung, die Effizienz des Ergebniszugriffs und die Effizienz der GPU-Berechnung spielen alle eine Rolle bei der Bestimmung der Effektivität des GPU-Offloads.
  • Eine Auswahl zwischen GPU-Bias und Hostprozessor-Bias kann durch eine Bias-Tracker-Datenstruktur gesteuert werden. Beispielsweise kann eine Bias-Tabelle verwendet werden, die eine seitengranulare Struktur sein kann (d. h. bei der Granularität einer Speicherseite gesteuert werden kann), die 1 oder 2 Bits pro GPU-angeschlossener Speicherseite aufweist. Die Bias-Tabelle kann in einem gestohlenen Speicherbereich eines oder mehrerer GPU-angeschlossener Speicher 420-423 mit oder ohne Bias-Cache in der GPU 410-413 implementiert sein (z. B. um häufig/kürzlich verwendete Einträge der Bias-Tabelle zu cachen). Alternativ kann die gesamte Bias-Tabelle in der GPU gehalten werden.
  • In einer Implementierung wird auf den Bias-Tabelleneintrag, der mit jedem Zugriff auf den an die GPU angeschlossenen Speicher 420-423 assoziiert ist, vor dem eigentlichen Zugriff auf den GPU-Speicher zugegriffen, was die folgenden Operationen bewirkt. Zunächst werden lokale Anforderungen von der GPU 410-413, die ihre Seite in GPU-Bias finden, direkt an einen entsprechenden GPU-Speicher 420-423 weitergeleitet. Lokale Anforderungen von der GPU, die ihre Seite in Host-Bias finden, werden an den Prozessor 405 weitergeleitet (z. B. über einen Hochgeschwindigkeitslink, wie oben erläutert). Optional schließen Anforderungen von dem Prozessor 405, die die angeforderte Seite in Hostprozessor-Bias finden, die Anforderung wie einen normalen Speicherlesevorgang ab. Alternativ können Anforderungen, die an eine Seite mit GPU-Bias gerichtet sind, an die GPU 410-413 weitergeleitet werden. Die GPU kann dann die Seite zu einem Hostprozessor-Bias überführen, wenn sie die Seite derzeit nicht verwendet.
  • Der Bias-Zustand einer Seite kann entweder durch einen softwarebasierten Mechanismus, einen hardwaregestützten softwarebasierten Mechanismus oder für einen begrenzten Satz von Fällen einen rein hardwarebasierten Mechanismus geändert werden.
  • Ein Mechanismus zum Ändern des Bias-Zustands verwendet einen API-Aufruf (z. B. OpenCL), der wiederum den Vorrichtungstreiber der GPU aufruft, der wiederum eine Nachricht an die GPU sendet (oder einen Befehlsdeskriptor in eine Warteschlange einreiht), die sie anweist, den Bias-Zustand zu ändern und für einige Übergänge eine Cache-Flushing-Operation im Host durchzuführen. Die Cache-Flushing-Operation ist für einen Übergang vom Bias des Hostprozessors 405 zu GPU-Bias erforderlich, ist jedoch für den umgekehrten Übergang nicht erforderlich.
  • Die Cache-Kohärenz kann dadurch aufrechterhalten werden, dass bewirkt wird, dass Seiten mit GPU-Bias durch den Hostprozessor 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 der Implementierung sofortigen Zugriff gewähren kann oder nicht. Somit ist es zur Reduzierung einer Kommunikation zwischen dem Hostprozessor 405 und der GPU 410 vorteilhaft, sicherzustellen, dass Seiten mit GPU-Bias jene sind, die durch die GPU, jedoch nicht den Hostprozessor 405 benötigt werden, und umgekehrt.
  • Grafikverarbeitungs-Pipeline
  • 5 veranschaulicht eine Grafikverarbeitungs-Pipeline 500. Ein Grafikmultiprozessor, wie etwa der Grafikmultiprozessor 234 von 2D, der Grafikmultiprozessor 325 von 3A, der Grafikmultiprozessor 350 von 3B, kann die veranschaulichte Grafikverarbeitungs-Pipeline 500 implementieren. Der Grafikmultiprozessor kann in den hierin beschriebenen Parallelverarbeitungssubsystemen enthalten sein, wie etwa dem Parallelprozessor 200 von 2A, der mit dem Parallelprozessor bzw. den Parallelprozessoren 112 von 1 in Beziehung steht und anstelle dieser verwendet werden kann. Die verschiedenen Parallelverarbeitungssysteme können die Grafikverarbeitungs-Pipeline 500 über eine oder mehrere Instanzen der Parallelverarbeitungseinheit (z. B. Parallelverarbeitungseinheit 202 von 2A) implementieren, wie hierin beschrieben. Zum Beispiel kann eine Shader-Einheit (z. B. Grafikmultiprozessor 234 von 2C) dazu konfiguriert sein, die Funktionen einer oder mehrerer einer Vertexverarbeitungseinheit 504, einer Tessellationssteuerverarbeitungseinheit 508, einer Tessellationsauswertungsverarbeitungseinheit 512, einer Geometrieverarbeitungseinheit 516 und einer Fragment-/Pixelverarbeitungseinheit 524 auszuführen. Die Funktionen des Daten-Assemblers 502, der Primitiv-Assembler 506, 514, 518, der Tessellationseinheit 510, des Rasterisierers 522 und der Rasteroperationseinheit 526 können auch durch andere Verarbeitungs-Engines innerhalb eines Verarbeitungsclusters (z. B. Verarbeitungsclusters 214 von 2A) und einer entsprechenden Partitionseinheit (z. B. Partitionseinheit 220A-220N von 2A) durchgeführt werden. Die Grafikverarbeitungs-Pipeline 500 kann auch unter Verwendung dedizierter Verarbeitungseinheiten für eine oder mehrere Funktionen implementiert werden. Es ist auch möglich, dass ein oder mehrere Abschnitte der Grafikverarbeitungs-Pipeline 500 von einer Parallelverarbeitungslogik in einem Allzweckprozessor (z. B. CPU) ausgeführt werden. Optional können ein oder mehrere Abschnitte der Grafikverarbeitungs-Pipeline 500 über eine Speicherschnittstelle 528, die eine Instanz der Speicherschnittstelle 218 von 2A sein kann, auf einen chipinternen Speicher (z. B. den Parallelprozessorspeicher 222 wie in 2A) zugreifen. Die Grafikprozessor-Pipeline 500 kann auch über eine Mehrkerngruppe 365A wie in 3C implementiert werden.
  • Der Daten-Assembler 502 ist eine Verarbeitungseinheit, die Vertexdaten für Oberflächen und Primitive sammelt. Der Daten-Assembler 502 gibt dann die Vertexdaten einschließlich der Vertexattribute an die Vertexverarbeitungseinheit 504 aus. Die Vertexverarbeitungseinheit 504 ist eine programmierbare Ausführungseinheit, die Vertex-Shader-Programme ausführt und Vertexdaten wie durch die Vertex-Shader-Programme spezifiziert beleuchtet und transformiert. Die 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 Weltkoordinatenraum oder einen normalisierten Vorrichtungskoordinatenraum transformiert.
  • Eine erste Instanz eines Primitiv-Assemblers 506 empfängt Vertexattribute von der Vertexverarbeitungseinheit 504. Der Primitiv-Assembler 506 liest nach Bedarf gespeicherte Vertexattribute aus und konstruiert Grafikprimitive zur Verarbeitung durch die Tessellationssteuerverarbeitungseinheit 508. Die Grafikprimitive beinhalten Dreiecke, Liniensegmente, Punkte, Felder (Patches) und so weiter, wie durch verschiedene Grafikverarbeitungs-Anwendungsprogrammierschnittstellen (APIs) unterstützt.
  • Die Tessellationssteuerverarbeitungseinheit 508 behandelt die Eingabevertices als Steuerpunkte für ein geometrisches Feld. Die Steuerpunkte werden von einer Eingabedarstellung von dem Feld (z. B. den Basen des Felds) in eine Repräsentation transformiert, die zur Verwendung bei der Oberflächenauswertung durch die Tessellationsauswertungsverarbeitungseinheit 512 geeignet ist. Die Tessellationssteuerverarbeitungseinheit 508 kann auch Tessellationsfaktoren für Kanten geometrischer Felder berechnen. Ein Tessellationsfaktor gilt für eine einzige Kante und quantifiziert einen mit der Kante assoziierten ansichtsabhängigen Detailgrad. Eine Tessellationseinheit 510 ist dazu konfiguriert, die Tessellationsfaktoren für Kanten eines Feldes zu empfangen und das Feld in mehrere geometrische Primitive wie Linien-, Dreieck- oder Viereck-Primitive zu tessellieren, die an eine Tessellationsauswertungsverarbeitungseinheit 512 übertragen werden. Die Tessellationsauswertungsverarbeitungseinheit 512 arbeitet mit parametrisierten Koordinaten des unterteilten Felds, um eine Oberflächenrepräsentation und Vertexattribute für jeden mit den geometrischen Primitiven assoziierten Vertex zu erzeugen.
  • Eine zweite Instanz eines Primitiv-Assemblers 514 empfängt Vertexattribute von der Tessellationsauswertungsverarbeitungseinheit 512, liest gespeicherte Vertexattribute nach Bedarf und konstruiert Grafikprimitive zur Verarbeitung durch die Geometrieverarbeitungseinheit 516. Die Geometrieverarbeitungseinheit 516 ist eine programmierbare Ausführungseinheit, die Geometrie-Shader-Programme ausführt, um Grafikprimitive, die von dem Primitiv-Assembler 514 empfangen werden, wie durch die Geometrie-Shader-Programme spezifiziert, zu transformieren. Die Geometrieverarbeitungseinheit 516 kann dazu programmiert sein, die Grafikprimitive in ein oder mehrere neue Grafikprimitive zu unterteilen und Parameter zu berechnen, die zum Rasterisieren der neuen Grafikprimitive verwendet werden.
  • Die Geometrieverarbeitungseinheit 516 kann in der Lage sein, Elemente im Geometriestrom hinzuzufügen oder zu löschen. Die Geometrieverarbeitungseinheit 516 gibt die Parameter und Vertices, die neue Grafik-Primitive spezifizieren, an den Primitive-Assembler 518 aus. Der Primitiv-Assembler 518 empfängt die Parameter und Vertices von der Geometrieverarbeitungseinheit 516 und konstruiert Grafikprimitive zur Verarbeitung durch eine Viewport-Skalierungs-, Cull- und Clip-Einheit 520. Die Geometrieverarbeitungseinheit 516 liest Daten, die im Parallelprozessorspeicher oder Systemspeicher zur Verwendung bei der Verarbeitung der Geometriedaten gespeichert sind. Die Viewport-Skalierungs-, Cull- und Clip-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 durchführen. Der Rasterisierer 522 führt auch eine Scan-Konvertierung an den neuen Grafikprimitiven durch, um Fragmente zu generieren und diese Fragmente und zugehörige Abdeckungsdaten an die Fragment-/Pixelverarbeitungseinheit 524 auszugeben. Die Fragment-/Pixelverarbeitungseinheit 524 ist eine programmierbare Ausführungseinheit, die dazu konfiguriert ist, Fragment-Shader-Programme oder Pixel-Shader-Programme auszuführen. Die Fragment-/Pixelverarbeitungseinheit 524 transformiert Fragmente oder Pixel, die von dem Rasterisierer 522 empfangen werden, wie durch die Fragment- oder Pixel-Shader-Programme spezifiziert. Zum Beispiel kann die Fragment-/Pixelverarbeitungseinheit 524 dazu programmiert sein, Operationen durchzuführen, darunter unter anderem Texturabbildung, Shading, Blending, Texturkorrektur und Perspektivenkorrektur, um schattierte Fragmente oder Pixel zu erzeugen, die an eine Rasteroperationseinheit 526 ausgegeben werden. Die Fragment-/Pixelverarbeitungseinheit 524 kann entweder in dem Parallelprozessorspeicher oder in dem Systemspeicher gespeicherte Daten zur Verwendung bei einer Verarbeitung der Fragmentdaten lesen. Fragment- oder Pixel-Shader-Programme können so konfiguriert sein, dass sie abhängig von der für die Verarbeitungseinheiten konfigurierten Abtastrate mit Sample-, Pixel-, Kachel- oder anderen Granularitäten schattieren.
  • Die Rasteroperationseinheit 526 ist eine Verarbeitungseinheit, die Rasteroperationen durchführt, darunter unter anderem Stencil, z-Test, Blending und dergleichen, und Pixeldaten als verarbeitete Grafikdaten ausgibt, die im Grafikspeicher (z. B. Parallelprozessorspeicher 222 wie in 2A und/oder Systemspeicher 104 wie in 1) gespeichert werden sollen, um auf der einen oder den mehreren Anzeigevorrichtungen 110 angezeigt zu werden, oder zur weiteren Verarbeitung durch einen des einen oder der mehreren Prozessoren 102 oder Parallelprozessoren 112. Die Rasteroperationseinheit 526 kann dazu konfiguriert sein, z- oder Farbdaten, die in Speicher geschrieben werden, zu komprimieren und z- oder Farbdaten, die aus dem Speicher gelesen werden, zu dekomprimieren.
  • Überblick über das maschinelle Lernen
  • Die oben beschriebene Architektur kann angewendet werden, um Trainings- und Inferenzoperationen unter Verwendung von Maschinenlernmodellen durchzuführen. Maschinelles Lernen hat sich bei der Lösung vieler Arten von Aufgaben bewährt. Die Berechnungen, die beim Training und bei der Verwendung von Maschinenlernalgorithmen (z. B. neuronalen Netzwerken) anfallen, eignen sich in ihrer Natur für effiziente Parallelimplementierungen. Dementsprechend haben Parallelprozessoren wie Allzweck-Grafikverarbeitungseinheiten (GPGPUs) eine bedeutende Rolle bei der praktischen Implementierung von tiefen neuronalen Netzwerken gespielt. Parallele Grafikprozessoren mit SIMT-Architekturen (SIMT: Single Instruction, Multiple Thread) sind darauf ausgelegt, das Ausmaß der Parallelverarbeitung in der Grafik-Pipeline zu maximieren. In einer SIMT-Architektur versuchen Gruppen von parallelen Threads, Programmanweisungen so oft wie möglich synchron gemeinsam auszuführen, um die Verarbeitungseffizienz zu erhöhen. Die Effizienz, die durch parallele Maschinenlernalgorithmus-Implementierungen bereitgestellt wird, ermöglicht die Verwendung von Netzwerken mit hoher Kapazität und erlaubt es, diese Netzwerke an größeren Datensätzen zu trainieren.
  • Ein Maschinenlernalgorithmus ist ein Algorithmus, der basierend auf einem Datensatz lernen kann. Beispielsweise können Maschinenlernalgorithmen darauf ausgelegt sein, hochgradige Abstraktionen innerhalb eines Datensatzes zu modellieren. Zum Beispiel können Bilderkennungsalgorithmen verwendet werden, um zu bestimmen, welche von mehreren Kategorien zu welcher gegebenen Eingabe gehören; Regressionsalgorithmen können bei einer Eingabe einen numerischen Wert ausgeben; und Mustererkennungsalgorithmen können verwendet werden, um übersetzten Text zu generieren oder eine Text-zu-Sprache- und/oder Spracherkennung durchzuführen.
  • Ein beispielhafter Typ eines Maschinenlernalgorithmus ist ein neuronales Netzwerk. Es gibt viele Arten von neuronalen Netzwerken; ein einfacher Typ eines neuronalen Netzwerks ist ein vorwärtsgekoppeltes Netzwerk. Ein vorwärtsgekoppeltes Netzwerk kann als ein azyklischer Graph implementiert sein, in dem die Knoten in Schichten angeordnet sind. Typischerweise weist eine vorwärtsgekoppelte Netzwerktopologie eine Eingabeschicht und eine Ausgabeschicht auf, die durch mindestens eine verborgene Schicht getrennt sind. Die verborgene Schicht wandelt durch die Eingabeschicht empfangene Eingaben in eine Repräsentation um, die zum Erzeugen von Ausgaben in der Ausgabeschicht nützlich ist. Die Netzwerkknoten 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 vorwärtsgekoppelten Netzwerks empfangen werden, werden über eine Aktivierungsfunktion, die die Zustände der Knoten jeder aufeinanderfolgenden Schicht in dem Netzwerk auf der Grundlage von Koeffizienten („Gewichtungen“) berechnet, die jeweils mit jeder der die Schichten verbindenden Kanten assoziiert sind, an die Knoten der Ausgabeschicht propagiert (d. h. „vorwärts gekoppelt“). Abhängig von dem durch den ausgeführten Algorithmus repräsentierten spezifischen Modell kann die Ausgabe von dem Neuronalnetzwerkalgorithmus verschiedene Formen annehmen.
  • Bevor ein Maschinenlernalgorithmus verwendet werden kann, um ein bestimmtes Problem zu modellieren, wird der Algorithmus unter Verwendung eines Trainingsdatensatzes trainiert. Das Trainieren eines neuronalen Netzwerks beinhaltet das Auswählen einer Netzwerktopologie, das Verwendung eines Satzes von Trainingsdaten, die ein durch das Netzwerk modelliertes Problem repräsentieren, und das Anpassen der Gewichtungen, bis das Netzwerkmodell für alle Instanzen des Trainingsdatensatzes mit einem minimalen Fehler arbeitet. Zum Beispiel wird während eines Trainingsprozesses mit überwachtem Lernen für ein neuronales Netzwerk die Ausgabe, die durch das Netzwerk als Reaktion auf die eine Instanz in einem Trainingsdatensatz repräsentierende Eingabe erzeugt wird, mit der als „korrekt“ gelabelten Ausgabe für diese Instanz verglichen, ein Fehlersignal, das die Differenz zwischen der Ausgabe und der gelabelten Ausgabe repräsentiert, wird berechnet, und die Gewichtungen, die mit den Verbindungen assoziiert sind, werden angepasst, um diesen Fehler zu minimieren, während das Fehlersignal rückwärts durch die Schichten des Netzwerks propagiert wird. Das Netzwerk wird als „trainiert“ betrachtet, wenn die Fehler für jede der aus den Instanzen des Trainingsdatensatzes erzeugten Ausgaben minimiert sind.
  • Die Genauigkeit eines Maschinenlernalgorithmus kann durch die Qualität des zum Trainieren des Algorithmus verwendeten Datensatzes erheblich beeinflusst werden. Der Trainingsprozess kann rechenintensiv sein und kann einen erheblichen Zeitaufwand auf einem herkömmlichen Allzweckprozessor erfordern. Dementsprechend wird eine Parallelverarbeitungshardware verwendet, um viele Arten von Maschinenlernalgorithmen zu trainieren. Dies ist besonders nützlich zum Optimieren des Trainings von neuronalen Netzwerken, da die Berechnungen, die beim Anpassen der Koeffizienten in neuronalen Netzwerken durchgeführt werden, sich auf natürliche Weise für parallele Implementierungen eignen. Insbesondere wurden viele Maschinenlernalgorithmen und Softwareanwendungen dahingehend angepasst, die Parallelverarbeitungshardware in Allzweck-Grafikverarbeitungsvorrichtungen zu verwenden.
  • 6 ist ein verallgemeinertes Diagramm eines Softwarestapels 600 für maschinelles Lernen. Eine Maschinenlernanwendung 602 kann dazu konfiguriert sein, ein neuronales Netzwerk unter Verwendung eines Trainingsdatensatzes zu trainieren oder ein trainiertes tiefes neuronales Netzwerk zu verwenden, um Maschinenintelligenz zu implementieren. Die Maschinenlernanwendung 602 kann eine Trainings- und Inferenzfunktionalität für ein neuronales Netzwerk und/oder spezialisierte Software beinhalten, die verwendet werden kann, um ein neuronales Netzwerk vor dem Einsatz zu trainieren. Die Maschinenlernanwendung 602 kann eine beliebige Art von Maschinenintelligenz implementieren, darunter unter anderem Bilderkennung, Kartierung und Lokalisierung, autonome Navigation, Sprachsynthese, medizinische Bildgebung oder Sprachübersetzung.
  • Die Hardwarebeschleunigung für die Maschinenlernanwendung 602 kann über ein Maschinenlern-Framework 604 aktiviert werden. Das Maschinenlern-Framework 604 kann eine Bibliothek von Maschinenlernprimitiven bereitstellen. Maschinenlernprimitive sind grundlegende Operationen, die üblicherweise durch Maschinenlernalgorithmen durchgeführt werden. Ohne das Maschinenlern-Framework 604 müssten Entwickler von Maschinenlernalgorithmen die mit dem Maschinenlernalgorithmus assoziierte Hauptrechenlogik erstellen und optimieren und dann bei Entwicklung neuer Parallelprozessoren die Rechenlogik erneut optimieren. Stattdessen kann die Maschinenlernanwendung dazu konfiguriert sein, die notwendigen Berechnungen unter Verwendung der Primitive durchzuführen, die von dem Maschinenlern-Framework 604 bereitgestellt werden. Zu beispielhaften Primitiven gehören Tensorfaltungen, Aktivierungsfunktionen und Pooling, bei denen es sich um Rechenoperationen handelt, die während des Trainierens eines faltenden neuronalen Netzwerks (CNN Convolutional Neural Network) durchgeführt werden. Das Maschinenlern-Framework 604 kann auch Primitive bereitstellen, um grundlegende Unterprogramme für lineare Algebra, die durch viele Maschinenlernalgorithmen durchgeführt werden, wie etwa Matrix- und Vektoroperationen, zu implementieren.
  • Das Maschinenlern-Framework 604 kann Eingabedaten, die von der Maschinenlernanwendung 602 empfangen werden, verarbeiten und die geeignete Eingabe in ein Rechen-Framework 606 erzeugen. Das Rechen-Framework 606 kann die dem GPGPU-Treiber 608 bereitgestellten zugrundeliegenden Anweisungen abstrahieren, um zu ermöglichen, dass das Maschinenlern-Framework 604 eine Hardwarebeschleunigung über die GPGPU-Hardware 610 nutzt, ohne dass das Maschinenlern-Framework 604 genaue Kenntnisse über die Architektur der GPGPU-Hardware 610 haben muss. Außerdem kann das Rechen-Framework 606 eine Hardwarebeschleunigung für das Maschinenlern-Framework 604 über viele verschiedene Arten und Generationen der GPGPU-Hardware 610 ermöglichen.
  • GPGPU-Beschleunigung für maschinelles Lernen
  • 7 veranschaulicht eine Allzweck-Grafikverarbeitungseinheit 700, die der Parallelprozessor 200 von 2A oder der eine oder die mehreren Parallelprozessoren 112 von 1 sein kann. Die Allzweck-Verarbeitungseinheit (GPGPU) 700 kann derart konfiguriert sein, dass sie besonders effizient beim Verarbeiten der Art von Berechnungsarbeitslasten ist, die mit dem Trainieren von tiefen neuronalen Netzwerken assoziiert ist. Darüber hinaus kann die GPGPU 700 direkt mit anderen Instanzen der GPGPU verbunden sein, um einen Multi-GPU-Cluster zu erstellen, um die Trainingsgeschwindigkeit für besonders tiefe neuronale Netzwerke zu verbessern.
  • Die GPGPU 700 weist eine Hostschnittstelle 702 zum Ermöglichen einer Verbindung mit einem Hostprozessor auf. Die Hostschnittstelle 702 kann eine PCI-Express-Schnittstelle sein. Die Hostschnittstelle kann jedoch auch eine anbieterspezifische Kommunikationsschnittstelle oder ein anbieterspezifisches Kommunikations-Fabric sein. Die GPGPU 700 empfängt Befehle von dem Hostprozessor und verwendet einen globalen Scheduler 704 zum Verteilen von Ausführungs-Threads, die mit diesen Befehlen assoziiert sind, an einen Satz von Verarbeitungsclustern 706A-706H. Die Verarbeitungscluster 706A-706H nutzen einen Cachespeicher 708 gemeinsam. Der Cachespeicher 708 kann als Cache höherer Ebene für Cachespeicher innerhalb der Verarbeitungscluster 706A-706H dienen. Die veranschaulichten Verarbeitungscluster 706A - 706H können den Verarbeitungsclustern 214A - 214N wie in 2A entsprechen.
  • Die GPGPU 700 beinhaltet Speicher 714A-714B, der über einen Satz von Speichersteuerungen 712A-712B mit den Verarbeitungsclustern 706A-H gekoppelt ist. Der Speicher 714A - 714N kann verschiedene Arten von Speichervorrichtungen beinhalten, einschließlich eines dynamischen Direktzugriffsspeichers (DRAM) oder eines Grafik-Direktzugriffsspeichers, wie etwa eines synchronen Grafik-Direktzugriffsspeichers (SGRAM), einschließlich eines Grafikspeichers mit doppelter Datenrate (GDDR). Der Speicher 714A - 714B kann auch 3D-Stapelspeicher beinhalten, einschließlich unter anderem Speicher mit hoher Bandbreite (High Bandwidth Memory - HBM).
  • Jeder der Verarbeitungscluster 706A-706H kann einen Satz von Grafikmultiprozessoren beinhalten, wie etwa den Grafikmultiprozessor 234 von 2D, den Grafikmultiprozessor 325 von 3A, den Grafikmultiprozessor 350 von 3B, oder kann eine Mehrkerngruppe 365A-365N wie in 3C beinhalten. Die Grafikmultiprozessoren des Rechenclusters beinhalten mehrere Arten von Ganzzahl- und Gleitkommalogikeinheiten, die Rechenoperationen mit einer Reihe von Präzisionen durchführen können, darunter auch solche, die sich für Berechnungen für maschinelles Lernen eignen. Zum Beispiel kann zumindest eine Teilmenge der Gleitkommaeinheiten in jedem der Verarbeitungscluster 706A-706H dazu konfiguriert sein, 16-Bit- oder 32-Bit-Gleitkommaoperationen durchzuführen, während eine andere Teilmenge der Gleitkommaeinheiten dazu konfiguriert sein kann, 64-Bit-Gleitkommaoperationen durchzuführen.
  • Mehrere Instanzen der GPGPU 700 können derart konfiguriert sein, dass sie als ein Rechencluster arbeiten. Der Kommunikationsmechanismus, der durch den Rechen-Cluster für die Synchronisation und den Datenaustausch verwendet wird, variiert je nach Ausführungsform. Zum Beispiel kommunizieren die mehreren Instanzen der GPGPU 700 über die Hostschnittstelle 702. In einer Ausführungsform beinhaltet die GPGPU 700 einen E/A-Hub 709, der die GPGPU 700 mit einem GPU-Link 710 koppelt, der eine direkte Verbindung mit anderen Instanzen der GPGPU ermöglicht. Der GPU-Link 710 kann mit einer dedizierten GPU-zu-GPU-Brücke gekoppelt sein, die eine Kommunikation und Synchronisation zwischen mehreren Instanzen der GPGPU 700 ermöglicht. Optional ist der GPU-Link 710 mit einem Hochgeschwindigkeits-Interconnect gekoppelt, um Daten an andere GPGPUs oder Parallelprozessoren zu übertragen und von diesen zu empfangen. Die mehreren Instanzen der GPGPU 700 können sich in separaten Datenverarbeitungssystemen befinden und über eine Netzwerkvorrichtung kommunizieren, auf die über die Hostschnittstelle 702 zugegriffen werden kann. Der GPU-Link 710 kann dazu konfiguriert sein, eine Verbindung zu einem Hostprozessor zusätzlich oder als Alternative zur Hostschnittstelle 702 zu ermöglichen.
  • Obgleich die veranschaulichte Konfiguration der GPGPU 700 zum Trainieren von neuronalen Netzwerken konfiguriert sein kann, kann eine alternative Konfiguration der GPGPU 700 zum Einsatz in einer Inferenzplattform mit hoher Leistungsfähigkeit oder einer Niederleistungsinferenzplattform konfiguriert sein. In einer Inferenzkonfiguration beinhaltet die GPGPU 700 im Vergleich zu der Trainingskonfiguration weniger der Verarbeitungscluster 706A-706H. Zusätzlich dazu kann sich die Speichertechnologie, die mit dem Speicher 714A-714B assoziiert ist, zwischen Inferenz- und Trainingskonfigurationen unterscheiden. In einer Ausführungsform kann die Inferenzkonfiguration der GPGPU 700 das Inferenzieren spezifischer Anweisungen unterstützen. Zum Beispiel kann eine Inferenzkonfiguration Unterstützung für einen oder mehrere 8-Bit-Ganzzahl-Skalarprodukt-Anweisungen bereitstellen, die üblicherweise während Inferenzoperationen für eingesetzte neuronale Netzwerke verwendet werden.
  • 8 veranschaulicht ein Multi-GPU-Rechensystem 800. Das Multi-GPU-Rechensystem 800 kann einen Prozessor 802 beinhalten, der über einen Hostschnittstellen-Switch 804 mit mehreren GPGPUs 806A-806D gekoppelt ist. Der Hostschnittstellen-Switch 804 kann eine PCI-Express-Switch-Vorrichtung sein, die den Prozessor 802 mit einem PCI-Express-Bus koppelt, über den der Prozessor 802 mit dem Satz von GPGPUs 806A-806D kommunizieren kann. Jede der mehreren GPGPUs 806A-806D kann eine Instanz der GPGPU 700 von 7 sein. Die GPGPUs 806A-806D können über einen Satz von Hochgeschwindigkeits-Punkt-zu-Punkt-GPU-zu-GPU-Links 816 verbunden sein. Die Hochgeschwindigkeits-GPU-zu-GPU-Links können mit jeder der GPGPUs 806A-806D über einen dedizierten GPU-Link, wie etwa den GPU-Link 710 wie in 7, verbunden sein. Die P2P-GPU-Links 816 ermöglichen eine direkte Kommunikation zwischen jeder der GPGPUs 806A-806D, ohne dass eine Kommunikation über den Hostschnittstellenbus erforderlich ist, mit dem der Prozessor 802 verbunden ist. Wenn der GPU-zu-GPU-Verkehr auf die P2P-GPU-Links geleitet wird, bleibt der Hostschnittstellenbus für einen Systemspeicherzugriff oder zur Kommunikation mit anderen Instanzen des Multi-GPU-Rechensystems 800 verfügbar, beispielsweise über eine oder mehrere Netzwerkvorrichtungen. Während in 8 die GPGPUs 806A-806D über den Hostschnittstellen-Switch 804 mit dem Prozessor 802 verbunden sind, kann alternativ der Prozessor 802 eine direkte Unterstützung für die P2P-GPU-Links 816 beinhalten und direkt mit den GPGPUs 806A-806D verbunden sein.
  • Implementierungen neuronaler Netzwerke für maschinelles Lernen
  • Die hierin beschriebene Rechenarchitektur kann dazu konfiguriert sein, die Arten der parallelen Verarbeitung durchzuführen, die insbesondere zum Trainieren und Einsetzen von neuronalen Netzwerken für maschinelles Lernen geeignet sind. Ein neuronales Netzwerk kann als ein Netzwerk von Funktionen, die in einer Graphenbeziehung stehen, verallgemeinert werden. Wie im Stand der Technik bekannt, gibt es viele verschiedene Arten von Implementierungen neuronaler Netzwerke, die beim maschinellen Lernen verwendet werden. Ein beispielhafter Typ eines neuronalen Netzwerks ist das vorwärtsgekoppeltes Netzwerk, wie zuvor beschrieben.
  • Ein zweiter beispielhafter Typ eines neuronalen Netzwerks ist das faltende neuronale Netzwerk (CNN: Convolutional Neural Network). Ein CNN ist ein spezialisiertes neuronales vorwärtsgekoppeltes Netzwerk zum Verarbeiten von Daten mit einer bekannten gitterartigen Topologie, wie etwa Bilddaten. Dementsprechend werden CNNs üblicherweise für Computer-Vision- und Bilderkennungsanwendungen verwendet, sie können aber auch für andere Arten der Mustererkennung, wie etwa die Verarbeitung gesprochener und geschriebener Sprache, verwendet werden. Die Knoten in der CNN-Eingabeschicht sind in einem Satz von „Filtern“ organisiert (Merkmalsdetektoren, die von den rezeptiven Feldern in der Netzhaut inspiriert sind), und die Ausgabe jedes Filtersatzes wird an Knoten in aufeinanderfolgenden Schichten des Netzwerks propagiert. Die Berechnungen für ein CNN beinhalten das Anwenden der mathematischen Faltungsoperation auf jedes Filter, um die Ausgabe dieses Filters zu erzeugen. Die Faltung 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 eines faltenden Netzwerks kann die erste Funktion der Faltung als Eingabe bezeichnet werden, während die zweite Funktion als Faltungskernel bezeichnet werden kann. Die Ausgabe kann als Feature-Map bezeichnet werden. Die Eingabe in eine Faltungsschicht kann beispielsweise ein mehrdimensionales Array von Daten sein, das die verschiedenen Farbkomponenten eines Eingabebilds definiert. Der Faltungskernel kann ein mehrdimensionales Array von Parametern sein, wobei die Parameter durch den Trainingsprozess für das neuronale Netzwerk angepasst werden.
  • Rekurrente neuronale Netzwerke (RNNs) sind eine Familie von neuronalen vorwärtsgekoppelten Netzwerken, die Rückkopplungsverbindungen zwischen Schichten enthalten. RNNs ermöglichen eine Modellierung sequenzieller Daten durch den Austausch von Parameterdaten über verschiedene Teile des neuronalen Netzwerks hinweg. Die Architektur für ein RNN beinhaltet Zyklen. Die Zyklen stellen den Einfluss eines gegenwärtigen Wertes einer Variablen auf ihren eigenen Wert zu einem zukünftigen Zeitpunkt dar, da zumindest ein Teil der Ausgangsdaten von dem RNN als eine Rückkopplung zum Verarbeiten einer nachfolgenden Eingabe in einer Sequenz verwendet wird. Diese Eigenschaft macht RNNs besonders nützlich für die Sprachverarbeitung, da Sprachdaten sehr variabel zusammengesetzt sein können.
  • Die nachstehend beschriebenen Figuren zeigen beispielhafte vorwärtsgekoppelte, CNN- und RNN-Netzwerke und beschreiben einen allgemeinen Prozess zum jeweiligen Trainieren und Einsetzen jedes dieser Typen von Netzwerken. Es versteht sich, dass diese Beschreibungen beispielhaft und nicht einschränkend für beliebige spezifische hierin beschriebene Ausführungsform sind und die veranschaulichten Konzepte allgemein auf tiefe neuronale Netzwerke und Maschinenlerntechniken im Allgemeinen angewendet werden können.
  • Die oben beschriebenen beispielhaften neuronalen Netzwerke können zum Durchführen von Deep Learning (Tiefes Lernen) verwendet werden. Deep Learning ist maschinelles Lernen unter Verwendung von tiefen neuronalen Netzwerken. Die tiefen neuronalen Netzwerke, die beim Deep Learning verwendet werden, sind künstliche neuronale Netzwerke, die aus mehreren verborgenen Schichten bestehen, im Gegensatz zu flachen neuronalen Netzwerken, die nur eine einzige verborgene Schicht aufweisen. Tiefere neuronale Netzwerke sind im Allgemeinen rechenintensiver zu trainieren. Die zusätzlichen verborgenen Schichten des Netzwerks ermöglichen jedoch eine mehrstufige Mustererkennung, die verglichen mit flachen Maschinenlerntechniken zu verringerten Ausgabefehlern führt.
  • Tiefe neuronale Netzwerke, die beim Deep Learning verwendet werden, beinhalten in der Regel ein Frontend-Netzwerk zur Durchführung einer Merkmalserkennung, das mit einem Backend-Netzwerk gekoppelt ist, das ein mathematisches Modell repräsentiert, das Operationen (z. B. Objektklassifizierung, Spracherkennung usw.) basierend auf der dem Modell bereitgestellten Merkmalsrepräsentation durchführen kann. Deep Learning ermöglicht ein Durchführen von maschinellem Lernen, ohne dass für das Modell eine manuelle Merkmalskonstruktion durchgeführt werden muss. Stattdessen können tiefe neuronale Netzwerke Merkmale basierend auf einer statistischen Struktur oder Korrelation innerhalb der Eingabedaten lernen. Die gelernten Merkmale können einem mathematischen Modell bereitgestellt werden, das detektierte Merkmale auf eine Ausgabe abbilden kann. Das durch das Netzwerk verwendete mathematische Modell ist im Allgemeinen für die spezifische durchzuführende Aufgabe spezialisiert, und andere Modelle werden verwendet, um andere Aufgaben durchzuführen.
  • Sobald das neuronale Netzwerk strukturiert ist, kann ein Lernmodell auf das Netzwerk angewendet werden, um das Netzwerk dahingehend zu trainieren, spezifische Aufgaben durchzuführen. Das Lernmodell beschreibt, wie die Gewichtungen innerhalb des Modells anzupassen sind, um den Ausgabefehler des Netzwerks zu reduzieren. Fehlerrückpropagation ist ein übliches Verfahren zum Trainieren neuronaler Netzwerke. Ein Eingabevektor wird dem Netzwerk zur Verarbeitung bereitgestellt. Die Ausgabe des Netzwerks wird unter Verwendung einer Verlustfunktion mit der gewünschten Ausgabe verglichen, und für jedes der Neuronen in der Ausgabeschicht wird ein Fehlerwert berechnet. Die Fehlerwerte werden dann rückwärts propagiert, bis jedes Neuron einen zugehörigen Fehlerwert hat, der in etwa seinen Beitrag zur ursprünglichen Ausgabe repräsentiert. Das Netzwerk kann dann aus diesen Fehlern lernen, indem es einen Algorithmus, wie etwa den stochastischen Gradientenabstiegsalgorithmus, verwendet, um die Gewichtungen des neuronalen Netzwerks zu aktualisieren.
  • 9A-9B veranschaulichen ein beispielhaftes faltendes neuronales Netzwerk. 9A veranschaulicht verschiedene Schichten innerhalb eines CNN. Wie in 9A gezeigt, kann ein beispielhaftes CNN, das zum Modellieren einer Bildverarbeitung verwendet wird, eine Eingabe 902 empfangen, die die Rot-, Grün- und Blau(RGB)-Komponenten eines Eingabebilds beschreibt. Die Eingabe 902 kann durch mehrere Faltungsschichten (z. B. Faltungsschicht 904, Faltungsschicht 906) verarbeitet werden. Die Ausgabe von den mehreren Faltungsschichten kann gegebenenfalls durch einen Satz vollständig verbundener Schichten 908 verarbeitet werden. Neuronen in einer vollständig verbundenen Schicht weisen vollständige Verbindungen mit allen Aktivierungen in der vorherigen Schicht auf, wie zuvor für ein vorwärtsgekoppeltes Netzwerk beschrieben. Die Ausgabe von den vollständig verbundenen Schichten 908 kann dazu verwendet werden, ein Ausgabeergebnis von dem Netzwerk zu erzeugen. Die Aktivierungen innerhalb der vollständig verbundenen Schichten 908 können unter Verwendung einer Matrixmultiplikation anstelle einer Faltung berechnet werden. Nicht alle CNN-Implementierungen verwenden vollständig verbundene Schichten 908. Zum Beispiel kann in einigen Implementierungen die Faltungsschicht 906 eine Ausgabe für das CNN erzeugen.
  • Die Faltungsschichten sind spärlich verbunden, was sich von der herkömmlichen Neuronalnetzwerkkonfiguration unterscheidet, die in den vollständig verbundenen Schichten 908 zu finden ist. Herkömmliche Neuronalnetzwerkschichten sind vollständig verbunden, sodass jede Ausgabeeinheit mit jeder Eingabeeinheit interagiert. Die Faltungsschichten sind jedoch spärlich verbunden, da die Ausgabe der Faltung eines Feldes (anstatt des jeweiligen Zustandswertes jedes der Knoten in dem Feld) in die Knoten der nachfolgenden Schicht eingegeben wird, wie veranschaulicht. Die mit den Faltungsschichten assoziierten Kernel führen Faltungsoperationen durch, deren Ausgabe an die nächste Schicht gesendet wird. Die Dimensionalitätsreduzierung, die in den Faltungsschichten durchgeführt wird, ist ein Aspekt, der ermöglicht, dass das CNN zur Verarbeitung großer Bilder skaliert.
  • 9B veranschaulicht beispielhafte Berechnungsstufen innerhalb einer Faltungsschicht eines CNN. Eine Eingabe in eine Faltungsschicht 912 eines CNN kann in drei Stufen einer Faltungsschicht 914 verarbeitet werden. Zu den drei Stufen können eine Faltungsstufe 916, eine Detektorstufe 918 und eine Pooling-Stufe 920 gehören. Die Faltungsschicht 914 kann dann Daten an eine nachfolgende Faltungsschicht ausgeben. Die letzte Faltungsschicht des Netzwerks kann Ausgabe-Feature-Map-Daten erzeugen oder eine Eingabe in eine vollständig verbundene Schicht bereitstellen, um beispielsweise einen Klassifizierungswert für die Eingabe in das CNN zu erzeugen.
  • In der Faltungsstufe 916 werden mehrere Faltungen parallel durchgeführt, um einen Satz linearer Aktivierungen zu erzeugen. Die Faltungsstufe 916 kann eine affine Transformation enthalten, bei der es sich um eine beliebige Transformation handelt, die als lineare Transformation plus eine Translation angegeben werden kann. Affine Transformationen beinhalten Rotationen, Translationen, Skalierungen und Kombinationen dieser Transformationen. Die Faltungsstufe berechnet die Ausgabe von Funktionen (z. B. Neuronen), die mit spezifischen Regionen in der Eingabe verbunden sind, die als die mit dem Neuron assoziierte lokale Region bestimmt werden können. Die Neuronen berechnen ein Skalarprodukt zwischen den Gewichtungen der Neuronen und der Region in der lokalen Eingabe, mit der die Neuronen verbunden sind. Die Ausgabe von der Faltungsstufe 916 definiert einen Satz linearer Aktivierungen, die durch aufeinanderfolgende Stufen der Faltungsschicht 914 verarbeitet werden.
  • Die linearen Aktivierungen können durch eine Detektorstufe 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 Gesamtnetzwerks, ohne die rezeptiven Felder der Faltungsschicht zu beeinflussen. Verschiedene Arten von nichtlinearen Aktivierungsfunktionen können verwendet werden. Eine spezielle Art ist die rektifizierte lineare Einheit (ReLU: Rectified Linear Unit), die eine Aktivierungsfunktion verwendet, die als f(x) = max(0, x) definiert ist, sodass die Aktivierung bei null begrenzt wird.
  • Die Pooling-Stufe 920 verwendet eine Pooling-Funktion, die die Ausgabe der Faltungsschicht 906 durch eine Zusammenfassungsstatistik der nahegelegenen Ausgaben ersetzt. Die Pooling-Funktion kann dazu verwendet werden, eine Translationsinvarianz in das neuronale Netzwerk einzuführen, sodass kleine Translationen der Eingabe die gepoolten Ausgaben nicht verändern. Die Invarianz gegenüber lokaler Translation 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, darunter Max-Pooling, Average-Pooling (Durchschnitts-Pooling) und L2-Norm-Pooling. Darüber hinaus beinhalten einige CNN-Implementierungen keine Pooling-Stufe. Stattdessen ersetzen solche Implementierungen eine zusätzliche Faltungsstufe, die eine erhöhte Schrittweite relativ zu vorherigen Faltungsstufen hat.
  • Die Ausgabe aus der Faltungsschicht 914 kann dann durch die nächste Schicht 922 verarbeitet werden. Die nächste Schicht 922 kann eine zusätzliche Faltungsschicht oder eine der vollständig verbundenen Schichten 908 sein. Zum Beispiel kann die erste Faltungsschicht 904 von 9A zu der zweiten Faltungsschicht 906 ausgeben, während die zweite Faltungsschicht zu einer ersten Schicht der vollständig verbundenen Schichten 908 ausgeben kann.
  • 10 veranschaulicht ein beispielhaftes rekurrentes neuronales Netzwerk 1000. In einem rekurrenten neuronalen Netzwerk (RNN) beeinflusst der vorherige Zustand des Netzwerks die Ausgabe des aktuellen Zustands des Netzwerks. RNNs können auf vielfältige Weise unter Verwendung einer Vielzahl von Funktionen konstruiert werden. Bei der Verwendung von RNNs geht es im Allgemeinen um die Verwendung mathematischer Modelle zur Vorhersage der Zukunft auf Grundlage einer vorherigen Sequenz von Eingaben. Ein RNN kann beispielsweise zum Durchführen einer statistischen Sprachmodellierung verwendet werden, um ein kommendes Wort anhand einer vorherigen Wortfolge vorherzusagen. Das veranschaulichte RNN 1000 kann so beschrieben werden, dass es eine Eingabeschicht 1002, die einen Eingabevektor empfängt, verborgene Schichten 1004 zum Implementieren einer rekurrenten Funktion, einen Rückkopplungsmechanismus 1005 zum Ermöglichen eines „Memory“ von vorherigen Zuständen und eine Ausgabeschicht 1006 zum Ausgeben eines Ergebnisses aufweist. Das RNN 1000 arbeitet auf Grundlage von Zeitschritten. Der Zustand des RNN zu einem gegebenen Zeitschritt wird basierend auf dem vorherigen Zeitschritt über den Rückkopplungsmechanismus 1005 beeinflusst. Für einen gegebenen Zeitschritt wird der Zustand der verborgenen Schichten 1004 durch den vorherigen Zustand und die Eingabe in dem aktuellen Zeitschritt definiert. Eine initiale Eingabe (x1) in einem ersten Zeitschritt kann durch die verborgene Schicht 1004 verarbeitet werden. Eine zweite Eingabe (x2) kann durch die verborgene Schicht 1004 unter Verwendung von Zustandsinformationen, die während der Verarbeitung der initialen Eingabe (x1) bestimmt werden, verarbeitet werden. Ein gegebener Zustand kann als st = f(Uxt + Wst-1) berechnet werden, wobei U und W Parametermatrizen sind. Die Funktion ƒ ist im Allgemeinen eine Nichtlinearität, wie etwa die hyperbolische Tangensfunktion (Tanh) oder eine Variante der Gleichrichterfunktion f(x) = max(0, x). Die spezifische mathematische Funktion, die in den verborgenen Schichten 1004 verwendet wird, kann jedoch abhängig von den spezifischen Implementierungsdetails des RNN 1000 variieren.
  • Zusätzlich zu den beschriebenen grundlegenden CNN- und RNN-Netzwerken können Variationen dieser Netzwerke ermöglicht werden. Eine beispielhafte RNN-Variante ist das LSTM-RNN (LSTM: Long Short Term Memory - langer Kurzzeitspeicher). 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 faltendes Deep-Belief-Netzwerk, das eine ähnliche Struktur wie ein CNN aufweist und ähnlich wie ein Deep-Belief-Netzwerk trainiert wird. Ein Deep-Belief-Netzwerk (DBN) ist ein generatives neuronales Netzwerk, das aus mehreren Schichten stochastischer (zufälliger) Variablen besteht. DBNs können Schicht für Schicht mittels unüberwachtem Lernen mit Greedy-Ansatz trainiert werden. Die gelernten Gewichtungen des DBN können dann verwendet werden, um neuronale Vortrainings-Netzwerke bereitzustellen, indem ein optimaler initialer Satz von Gewichtungen für das neuronale Netzwerk bestimmt wird.
  • 11 veranschaulicht Training und Einsatz eines tiefen neuronalen Netzwerks. Sobald ein gegebenes Netzwerk für eine Aufgabe strukturiert wurde, wird das neuronale Netzwerk unter Verwendung eines Trainingsdatensatzes 1102 trainiert. Verschiedene Trainings-Frameworks 1104 wurden entwickelt, um eine Hardwarebeschleunigung des Trainingsprozesses zu ermöglichen. Zum Beispiel kann das Maschinenlern-Framework 604 von 6 als ein Trainings-Framework 604 konfiguriert sein. Das Trainings-Framework 604 kann sich in ein untrainiertes neuronales Netzwerk 1106 einklinken und ermöglichen, dass das untrainierte neuronale Netzwerk unter Verwendung der hierin beschriebenen Parallelverarbeitungsressourcen trainiert wird, um ein trainiertes neuronales Netzwerk 1108 zu erzeugen.
  • Um den Trainingsprozess zu beginnen, können die initialen Gewichtungen zufällig oder durch Vortraining unter Verwendung eines Deep-Belief-Netzwerks gewählt werden. Der Trainingszyklus kann dann entweder auf überwachte oder auf unüberwachte Weise durchgeführt werden.
  • Überwachtes Lernen ist eine Lernmethode, bei der das Training als vermittelte Operation durchgeführt wird, z. B. wenn der Trainingsdatensatz 1102 Eingaben enthält, die mit der gewünschten Ausgabe für die Eingabe gepaart sind, oder wenn der Trainingsdatensatz Eingaben mit bekannter Ausgabe enthält und die Ausgabe des neuronalen Netzwerks manuell bewertet wird. Das Netzwerk verarbeitet die Eingaben und vergleicht die resultierenden Ausgaben mit einem Satz von erwarteten oder gewünschten Ausgaben. Fehler werden dann zurück durch das System propagiert. Das Trainings-Framework 1104 kann die Gewichtungen anpassen, die das untrainierte neuronale Netzwerk 1106 steuern. Das Trainings-Framework 1104 kann Werkzeuge bereitstellen, um zu überwachen, wie gut das untrainierte neuronale Netzwerk 1106 zu einem Modell hin konvergiert, das zum Erzeugen korrekter Antworten auf der Grundlage bekannter Eingabedaten geeignet ist. Der Trainingsprozess findet wiederholt statt, während die Gewichtungen des Netzwerks angepasst werden, um die durch das neuronale Netzwerk erzeugte Ausgabe zu verfeinern. Der Trainingsprozess kann fortgesetzt werden, bis das neuronale Netzwerk eine mit einem trainierten neuronalen Netzwerk 1108 assoziierte statistisch gewünschte Genauigkeit erreicht. Das trainierte neuronale Netzwerk 1108 kann dann eingesetzt werden, um eine beliebige Anzahl von Maschinenlernoperationen zu implementieren, um ein Inferenzergebnis 1114 basierend auf einer Eingabe neuer Daten 1112 zu erzeugen.
  • Unüberwachtes Lernen ist eine Lernmethode, bei der das Netzwerk versucht, sich selbst unter Verwendung nicht gelabelter Daten zu trainieren. Somit wird der Trainingsdatensatz 1102 für unüberwachtes Lernen Eingabedaten ohne zugehörige Ausgabedaten enthalten. Das untrainierte neuronale Netzwerk 1106 kann Gruppierungen innerhalb der nicht gelabelten Eingabe lernen und kann bestimmen, wie einzelne Eingaben mit dem gesamten Datensatz in Zusammenhang stehen. Unüberwachtes Training kann verwendet werden, um eine selbstorganisierende Map zu generieren, die eine Art trainiertes neuronales Netzwerk 1108 ist, das in der Lage ist, Operationen durchzuführen, die nützlich sind, um die Dimensionalität von Daten zu reduzieren. Unüberwachtes Training kann auch verwendet werden, um eine Anomalieerkennung auszuführen, die die Identifizierung von Datenpunkten in einem Eingabedatensatz ermöglicht, die von den normalen Mustern der Daten abweichen.
  • Es können auch Variationen von überwachtem und unüberwachtem Training eingesetzt werden. Semi-überwachtes Lernen ist eine Technik, bei der der Trainingsdatensatz 1102 eine Mischung aus gelabelten und nicht gelabelten Daten mit gleicher Verteilung beinhaltet. 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, dass das trainierte neuronale Netzwerk 1108 sich an die neuen Daten 1112 anpasst, ohne das Wissen zu vergessen, das dem Netzwerk bei einem initialen Training vermittelt wurde.
  • Ob überwacht oder unüberwacht, der Trainingsprozess für besonders tiefe neuronale Netzwerke kann für einen einzelnen Rechenknoten zu rechenintensiv sein. Anstatt einen einzelnen Rechenknoten zu verwenden, kann ein verteiltes Netzwerk von Rechenknoten verwendet werden, um den Trainingsprozess zu beschleunigen.
  • 12 ist ein Blockdiagramm, das verteiltes Lernen veranschaulicht. Verteiltes Lernen ist ein Trainingsmodell, das mehrere verteilte Rechenknoten verwendet, um ein überwachtes oder unüberwachtes Training eines neuronalen Netzwerks auszuführen. Die verteilten Rechenknoten können jeweils einen oder mehrere Hostprozessoren und einen oder mehrere der Allzweck-Verarbeitungsknoten beinhalten, wie etwa die hochparallele Allzweck-Grafikverarbeitungseinheit 700 wie in 7. Wie veranschaulicht, kann verteiltes Lernen mit Modellparallelität 1202, Datenparallelität 1204 oder einer Kombination aus Modell- und Datenparallelität 1204 durchgeführt werden.
  • Bei der Modellparallelität 1202 können verschiedene Rechenknoten in einem verteilten System Trainingsberechnungen für verschiedene Teile eines einzelnen Netzwerks durchführen. Zum Beispiel kann jede Schicht eines neuronalen Netzwerks durch einen anderen Verarbeitungsknoten des verteilten Systems trainiert werden. Zu den Vorteilen der Modellparallelität gehört die Möglichkeit, auf besonders große Modelle zu skalieren. Die Aufteilung der Berechnungen, die mit verschiedenen Schichten des neuronalen Netzwerks assoziiert sind, ermöglicht das Trainieren von sehr großen neuronalen Netzwerken, bei denen die Gewichtungen aller Schichten nicht in den Speicher eines einzelnen Rechenknotens passen würden. In einigen Fällen kann die Modellparallelität besonders nützlich sein, um ein unüberwachtes Training großer neuronaler Netzwerke durchzuführen.
  • Bei der Datenparallelität 1204 weisen die verschiedenen Knoten des verteilten Netzwerks eine vollständige Instanz des Modells auf, und jeder Knoten erhält einen anderen Teil der Daten. Die Ergebnisse aus den verschiedenen Knoten werden dann kombiniert. Obgleich verschiedene Ansätze zur Datenparallelität möglich sind, erfordern alle datenparallele Trainingsansätze eine Technik zur Kombination von Ergebnissen und zur Synchronisierung der Modellparameter zwischen den einzelnen Knoten. Zu beispielhaften Ansätzen zum Kombinieren von Daten gehören Parametermittelwertbildung und aktualisierungsbasierte Datenparallelität. Die Parametermittelwertbildung trainiert jeden Knoten an einem Teilsatz der Trainingsdaten und setzt die globalen Parameter (z. B. Gewichtungen, Biases) auf den Mittelwert der Parameter von jedem Knoten. Die Parametermittelwertbildung verwendet einen zentralen Parameterserver, der die Parameterdaten verwaltet. Die aktualisierungsbasierte Datenparallelität ist der Parametermittelwertbildung ähnlich, außer dass die Aktualisierungen an die Modelle übertragen werden und nicht Parameter von den Knoten an den Parameterserver übertragen werden. Zudem kann die aktualisierungsbasierte Datenparallelität dezentral durchgeführt werden, wobei die Aktualisierungen komprimiert und zwischen Knoten übertragen werden.
  • Die kombinierte Modell- und Datenparallelität 1206 kann beispielsweise in einem verteilten System implementiert werden, in dem jeder Rechenknoten mehrere GPUs beinhaltet. Jeder Knoten kann eine vollständige Instanz des Modells aufweisen, wobei separate GPUs innerhalb jedes Knotens dazu verwendet werden, verschiedene Teile des Modells zu trainieren.
  • Verteiltes Training hat einen erhöhten Overhead im Vergleich zum Training auf einer einzelnen Maschine. Die hier beschriebenen Parallelprozessoren und GPGPUs können jedoch jeweils verschiedene Techniken implementieren, um den Overhead des verteilten Trainings zu reduzieren, darunter Techniken zum Ermöglichen einer GPU-zu-GPU-Datenübertragung mit hoher Bandbreite und einer beschleunigten Ferndatensynchronisation.
  • Beispielhafte Maschinenlernanwendungen
  • Maschinelles Lernen kann zur Lösung einer Vielzahl von technologischen Problemen eingesetzt werden, darunter unter anderem Computer Vision, autonomes Fahren und Navigation, Erkennung gesprochener Sprache und Sprachverarbeitung. Computer Vision ist traditionell eines der aktivsten Forschungsgebiete für Maschinenlernanwendungen. Anwendungen von Computer Vision reichen von der Reproduktion menschlicher visueller Fähigkeiten, wie etwa dem Erkennen von Gesichtern, bis hin zur Schaffung neuer Kategorien visueller Fähigkeiten. Zum Beispiel können Computer-Vision-Anwendungen dazu konfiguriert sein, Schallwellen aus den Vibrationen, die in den in einem Video sichtbaren Objekten induziert werden, erkennen.
  • Parallelprozessor-beschleunigtes maschinelles Lernen ermöglicht es, Computer-Vision-Anwendungen unter Verwendung wesentlich größerer Trainingsdatensätze zu trainieren, als dies bisher möglich war, und ermöglicht es, Inferenzsysteme unter Verwendung von Niederleistungs-Parallelprozessoren einzusetzen.
  • Parallelprozessor-beschleunigtes maschinelles Lernen hat Anwendungen für autonomes Fahren, einschließlich Fahrspur- und Verkehrszeichenerkennung, Hindernisvermeidung, Navigation und Fahrkontrolle. Beschleunigte Maschinenlerntechniken können zum Trainieren von Fahrmodellen auf der Grundlage von Datensätzen verwendet werden, die die entsprechenden Reaktionen auf bestimmte Trainingseingaben definieren. Die vorliegend beschriebenen Parallelprozessoren können ein schnelles Training der zunehmend komplexen neuronalen Netzwerke ermöglichen, die für Lösungen zum autonomen Fahren verwendet werden, und ermöglichen den Einsatz von Niederleistungs-Inferenzprozessoren in einer mobilen Plattform, die zur Integration in autonome Fahrzeuge geeignet ist.
  • Parallelprozessor-beschleunigte tiefe neuronale Netzwerke haben Maschinenlernansätze für die automatische Spracherkennung (Automatic Speech Recognition, ASR) ermöglicht. ASR beinhaltet die Erstellung einer Funktion, die die wahrscheinlichste sprachliche Sequenz angesichts einer akustischen Eingabesequenz berechnet. Beschleunigtes maschinelles Lernen unter Verwendung tiefer neuronaler Netzwerke hat es ermöglicht, die bisher für ASR verwendeten Hidden-Markov-Modelle (HMMs) und Gaußschen Mischmodelle (GMMs) zu ersetzen.
  • Parallelprozessor-beschleunigtes maschinelles Lernen kann auch zur Beschleunigung der Verarbeitung natürlicher Sprache verwendet werden. Automatische Lernverfahren können statistische Inferenzalgorithmen nutzen, um Modelle zu erzeugen, die robust gegenüber fehlerhaften oder ungewohnten Eingaben sind. Zu beispielhaften Anwendungen für natürliche Sprachprozessoren gehört die automatische maschinelle Übersetzung zwischen menschlichen Sprachen.
  • Die für maschinelles Lernen verwendeten Parallelverarbeitungsplattformen können in Trainingsplattformen und Einsatzplattformen unterteilt werden. Trainingsplattformen sind im Allgemeinen hochparallel und beinhalten Optimierungen zur Beschleunigung von Multi-GPU-Einzelknoten-Training und Multi-Knoten-Multi-GPU-Training. Zu beispielhaften Parallelprozessoren, die sich für das Training eignen, gehören die Allzweck-Grafikverarbeitungseinheit 700 von 7 und das Multi-GPU-Rechensystem 800 von 8. Eingesetzte Maschinenlernpattformen beinhalten dagegen im Allgemeinen Niederleistungs-Parallelprozessoren, die zur Verwendung in Produkten wie Kameras, autonomen Robotern und autonomen Fahrzeugen geeignet sind.
  • 13 veranschaulicht ein beispielhaftes Inferenz-System-on-Chip (SOC) 1300, das zum Durchführen von Inferenzieren unter Verwendung eines trainierten Modells 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 etwa die GPGPU 700, und der Mehrkernprozessor 1308 kann ein hierin beschriebener Mehrkernprozessor sein, wie etwa die Mehrkernprozessoren 405 - 406. Das SOC 1300 kann zusätzlich einen On-Chip-Speicher 1305 beinhalten, der einen gemeinsam genutzten On-Chip-Datenpool ermöglichen kann, auf den jede der Verarbeitungskomponenten zugreifen kann. Die Verarbeitungskomponenten können für einen Niederleistungsbetrieb optimiert werden, um den Einsatz in einer Vielzahl von Maschinenlernplattformen zu ermöglichen, einschließlich autonomer Fahrzeuge und autonomer Roboter. Eine Implementierung des SOC 1300 kann zum Beispiel als Teil des Hauptsteuersystems für ein autonomes Fahrzeug verwendet werden. Wenn das SOC 1300 zur Verwendung in autonomen Fahrzeugen konfiguriert ist, ist das SOC dahingehend ausgelegt und konfiguriert, die relevanten funktionalen Sicherheitsstandards des Einsatzlandes zu erfüllen.
  • Während des Betriebs können der Medienprozessor 1302 und der Bildverarbeitungsprozessor 1304 zusammenarbeiten, um Computer-Vision-Operationen zu beschleunigen. Der Medienprozessor 1302 kann eine latenzarme Decodierung mehrerer hochauflösender Videoströme (z. B. 4K, 8K) ermöglichen. Die decodierten Videoströme können in einen Puffer in dem On-Chip-Speicher 1305 geschrieben werden. Der Vision-Prozessor 1304 kann dann das decodierte Video parsen und vorläufige Verarbeitungsoperationen an den Frames des decodierten Videos als Vorbereitung der Verarbeitung der Frames unter Verwendung eines trainierten Bilderkennungsmodells durchführen. Beispielsweise kann der Bildverarbeitungsprozessor 1304 die Faltungsoperationen für ein CNN beschleunigen, das zur Durchführung von Bilderkennung an den hochauflösenden Videodaten verwendet wird, während die Backend-Modellberechnungen durch die GPGPU 1306 durchgeführt werden.
  • Der Mehrkernprozessor 1308 kann Steuerlogik beinhalten, die bei der Sequenzierung und Synchronisierung von Datenübertragungen und gemeinsamen Speicheroperationen hilft, die durch den Medienprozessor 1302 und den Vision-Prozessor 1304 durchgeführt werden. Der Mehrkernprozessor 1308 kann zudem als Anwendungsprozessor fungieren, um Softwareanwendungen auszuführen, die die Inferenzrechenfähigkeit der GPGPU 1306 nutzen können. Zum Beispiel kann zumindest ein Teil der Navigations- und Fahrlogik in Software implementiert sein, die auf dem Mehrkernprozessor 1308 ausgeführt wird. Derartige Software kann direkt Rechenlasten an die GPGPU 1306 ausgeben oder die Rechenlasten können an den Mehrkernprozessor 1308 ausgegeben werden, der zumindest einen Teil dieser Operationen an die GPGPU 1306 auslagern kann.
  • Die GPGPU 1306 kann Rechencluster beinhalten, wie etwa eine Niederleistungskonfiguration der Verarbeitungscluster 706A-706H innerhalb der Allzweck-Grafikverarbeitungseinheit 700. Die Rechencluster innerhalb der GPGPU 1306 können Anweisungen unterstützen, die spezifisch zur Durchführung von Inferenzberechnungen in einem trainierten neuronalen Netzwerk optimiert sind. Die GPGPU 1306 kann beispielsweise Anweisungen zur Durchführung von Berechnungen mit geringer Präzision wie 8-Bit- und 4-Bit-Ganzzahl-Vektoroperationen unterstützen.
  • Zusätzliche Systemübersicht
  • 14 ist ein Blockdiagramm eines Verarbeitungssystems 1400. Die Elemente von 14 mit den gleichen oder ähnlichen Namen wie die Elemente einer beliebigen anderen Figur hierin beschreiben die gleichen Elemente wie in den anderen Figuren, können auf ähnliche Weise arbeiten oder fungieren, können die gleichen Komponenten umfassen und können mit anderen Entitäten wie jene, die an anderer Stelle hierin beschrieben sind, verknüpft sein, sind jedoch nicht darauf beschränkt. Das System 1400 kann in einem Einzelprozessor-Desktop-System, einem Multiprozessor-Workstation-System oder einem Serversystem mit einer großen Anzahl von Prozessoren 1402 oder Prozessorkernen 1407 verwendet werden. Das System 1400 kann eine Verarbeitungsplattform sein, die innerhalb einer integrierten Schaltung eines System-on-Chip (SoC) zur Verwendung in mobilen, handgehaltenen oder eingebetteten Vorrichtungen, wie etwa innerhalb von Internet-der-Dinge(IoT)-Vorrichtungen mit drahtgebundener oder drahtloser Konnektivität zu einem Lokal- oder Weitbereichsnetzwerk, integriert ist.
  • Das System 1400 kann ein Verarbeitungssystem mit Komponenten sein, die denen von 1 entsprechen. Beispielsweise können in unterschiedlichen Konfigurationen Prozessor(en) 1402 oder Prozessorkern(e) 1407 dem einen bzw. den mehreren Prozessoren 102 von 1 entsprechen. Der eine bzw. die mehreren Grafikprozessoren 1408 können dem einen bzw. den mehreren Parallelprozessoren 112 von 1 entsprechen. Der externe Grafikprozessor 1418 kann eine der Add-In-Vorrichtungen 120 von 1 sein.
  • Das System 1400 kann eine serverbasierte Gaming-Plattform; eine Spielkonsole, einschließlich einer Spiel- und Medienkonsole; eine Mobile-Gaming-Konsole, eine handgehaltene Spielkonsole oder eine Onlinespielkonsole beinhalten, mit dieser gekoppelt oder darin integriert sein. Das System 1400 kann Teil eines Mobiltelefons, Smartphones, einer Tablet-Rechenvorrichtung oder einer mobilen internetverbundenen Vorrichtung sein, wie etwa eines Laptops mit geringer interner Speicherkapazität. Das Verarbeitungssystem 1400 kann auch Folgendes beinhalten, damit gekoppelt oder darin integriert sein: eine Wearable-Vorrichtung, wie etwa eine Smartwatch-Wearable-Vorrichtung; eine Smart-Brille oder Smart-Kleidung, erweitert mit Augmented-Reality(AR)- oder Virtual-Reality(VR)-Merkmalen, um visuelle, auditive oder taktile Ausgaben bereitzustellen, um visuelle, auditive oder taktile reelle Erfahrungen zu ergänzen oder anderweitig Text, Audio, Grafiken, Video, holografische Bilder oder Video oder taktiles Feedback bereitzustellen; eine andere Augmented-Reality(AR)-Vorrichtung; oder eine andere Virtual-Reality(VR)-Vorrichtung. Das Verarbeitungssystem 1400 kann ein Fernsehgerät oder eine Set-Top-Box-Vorrichtung beinhalten oder ein Teil davon sein. Das System 1400 kann ein selbstfahrendes Fahrzeug, wie etwa einen Bus, einen Traktoranhänger, ein Auto, ein Motorrad oder E-Bike, ein Flugzeug oder Segelflugzeug (oder eine beliebige Kombination davon) beinhalten, damit gekoppelt oder darin integriert sein. Das selbstfahrende Fahrzeug kann das System 1400 verwenden, um die Umgebung zu verarbeiten, die um das Fahrzeug herum erfasst wird.
  • Der eine oder die mehreren Prozessoren 1402 können einen oder mehrere Prozessorkerne 1407 beinhalten, um Anweisungen zu verarbeiten, die dann, wenn sie ausgeführt werden, Operationen für System- und Anwender-Software durchführen. Der mindestens eine des einen oder der mehreren Prozessorkerne 1407 kann dazu konfiguriert sein, einen spezifischen Anweisungssatz 1409 zu verarbeiten. Der Anweisungssatz 1409 kann Berechnungen mit komplexem Anweisungssatz (CISC), Berechnungen mit reduziertem Anweisungssatz (RISC) oder Berechnungen über ein sehr langes Befehlswort (VLIW) unterstützen. Ein oder mehrere Prozessorkerne 1407 können einen unterschiedlichen Anweisungssatz 1409 verarbeiten, der Anweisungen enthalten kann, um die Emulation anderer Anweisungssätze zu unterstützen. Der Prozessorkern 1407 kann auch andere Verarbeitungsvorrichtungen beinhalten, wie etwa einen Digitalsignalprozessor (DSP).
  • Der Prozessor 1402 kann Cachespeicher 1404 beinhalten. In Abhängigkeit von der Architektur kann der Prozessor 1402 einen einzigen internen Cache oder mehrere Ebenen von internem Cache aufweisen. In manchen Ausführungsformen wird der Cachespeicher durch verschiedene Komponenten des Prozessors 1402 gemeinsam genutzt. In einigen Ausführungsformen verwendet der Prozessor 1402 auch einen externen Cache (z. B. einen Level-3(L3)-Cache oder einen Cache der letzten Ebene (LLC)) (nicht gezeigt), der durch Prozessorkerne 1407 unter Verwendung bekannter Cachekohärenztechniken gemeinsam genutzt wird. Eine Registerdatei 1406 kann zusätzlich in dem Prozessor 1402 enthalten sein und kann verschiedene Arten von Registern zum Speichern verschiedener Arten von Daten (z. B. Ganzzahlregister, Gleitkommaregister, Statusregister und ein Anweisungszeigerregister) beinhalten. Manche Register können Allzweckregister sein, während andere Register für die Gestaltung des Prozessors 1402 spezifisch sein können.
  • Der eine oder die mehreren Prozessoren 1402 können mit einem oder mehreren Schnittstellenbussen 1410 zum Übertragen von Kommunikationssignalen, wie etwa Adress-, Daten- oder Steuersignalen, zwischen dem Prozessor 1402 und anderen Komponenten in dem System 1400 gekoppelt sein. Der Schnittstellenbus 1410 kann bei einer dieser Ausführungsformen ein Prozessorbus sein, wie etwa eine Version des DMI-Busses (DMI: Direct Media Interface - direkte Medienschnittstelle). Prozessorbusse sind jedoch nicht auf den DMI-Bus beschränkt und können einen oder mehrere Peripheral-Component-Interconnect-Busse (z. B. PCI, PCI Express), Speicherbusse oder andere Arten von Schnittstellenbussen beinhalten. Beispielsweise können der eine oder die mehreren Prozessoren 1402 eine integrierte Speichersteuerung 1416 und einen Plattformsteuerungshub 1430 beinhalten. Die Speichersteuerung 1416 ermöglicht eine Kommunikation zwischen einer Speichervorrichtung und anderen Komponenten des Systems 1400, während der Plattformsteuerungshub (PCH: Plattform Controller Hub) 1430 Verbindungen zu E/A-Vorrichtungen über einen lokalen E/A-Bus bereitstellt.
  • Die Speichervorrichtung 1420 kann eine Dynamischer-Direktzugriffsspeicher(DRAM)-Vorrichtung, eine Statischer-Direktzugriffsspeicher(SRAM)-Vorrichtung, eine Flash-Speichervorrichtung, eine Phasenwechselspeichervorrichtung oder eine andere Speichervorrichtung sein, die eine geeignete Leistungsfähigkeit aufweist, um als ein Prozessspeicher zu dienen. Die Speichervorrichtung 1420 kann beispielsweise als Systemspeicher für das System 1400 arbeiten, um Daten 1422 und Anweisungen 1421 zu speichern, die verwendet werden, wenn der eine oder die mehreren Prozessoren 1402 eine Anwendung oder einen Prozess ausführen. Die Speichersteuerung 1416 ist auch mit einem optionalen externen Grafikprozessor 1418 gekoppelt, der mit dem einen oder den mehreren Grafikprozessoren 1408 in den Prozessoren 1402 kommunizieren kann, um Grafik- und Medienoperationen durchzuführen. In einigen Ausführungsformen können Grafik-, Medien- und/oder Rechenoperationen durch einen Beschleuniger 1412 unterstützt werden, der ein Coprozessor ist, der dazu konfiguriert sein kann, einen spezialisierten Satz von Grafik-, Medien- oder Rechenoperationen durchzuführen. Beispielsweise kann der Beschleuniger 1412 ein Matrixmultiplikationsbeschleuniger sein, der verwendet wird, um Maschinenlern- oder Rechenoperationen zu optimieren. Der Beschleuniger 1412 kann ein Strahlverfolgungsbeschleuniger sein, der verwendet werden kann, um Strahlverfolgungsoperationen zusammen mit dem Grafikprozessor 1408 durchzuführen. In einer Ausführungsform kann ein externer Beschleuniger 1419 anstelle des Beschleunigers 1412 oder zusammen mit diesem verwendet werden.
  • Eine Anzeigevorrichtung 1411 kann bereitgestellt sein, die mit dem einen oder den mehreren Prozessoren 1402 verbunden werden kann. Die Anzeigevorrichtung 1411 kann eine interne Anzeigevorrichtung, wie in einer mobilen elektronischen Vorrichtung oder einer Laptopvorrichtung, und/oder eine externe Anzeigevorrichtung sein, die über eine Anzeigeschnittstelle (z. B. DisplayPort usw.) angeschlossen ist. Die Anzeigevorrichtung 1411 kann eine am Kopf angebrachte Anzeige (HMD: Head Mounted Display) sein, wie etwa eine stereoskopische Anzeigevorrichtung zur Verwendung bei Virtual-Reality(VR)-Anwendungen oder Augmented-Reality(AR)-Anwendungen.
  • Der Plattformsteuerungshub 1430 kann ermöglichen, dass Peripheriegeräte über einen Hochgeschwindigkeits-E/A-Bus mit der Speichervorrichtung 1420 und dem Prozessor 1402 verbunden sind. Die E/A-Peripheriegeräte schließen unter anderem eine Audiosteuerung 1446, eine Netzwerksteuerung 1434, eine Firmware-Schnittstelle 1428, einen drahtlosen Sendeempfänger 1426, Berührungssensoren 1425, eine Datenspeicherungsvorrichtung 1424 (z. B. nichtflüchtigen Speicher, flüchtigen Speicher, Festplattenlaufwerk, Flash-Speicher, NAND, 3D-NAND, 3D-XPoint/Optane usw.) ein. Die Datenspeicherungsvorrichtung 1424 kann über eine Speicherungsschnittstelle (z. B. SATA) oder über einen Peripheriebus, wie etwa einen Peripheral-Component-Interconnect-Bus (z. B. PCI, PCI Express), verbunden sein. Die Berührungssensoren 1425 können Touchscreen-Sensoren, Drucksensoren oder Fingerabdrucksensoren einschließen. Der drahtlose Sendeempfänger 1426 kann ein WiFi-Sendeempfänger, ein Bluetooth-Sendeempfänger oder ein Mobilnetz-Sendeempfänger sein, wie etwa ein 3G-, 4G-, 5G- oder Long-Term-Evolution(LTE)-Sendeempfänger. Die Firmware-Schnittstelle 1428 ermöglicht die Kommunikation mit System-Firmware und kann beispielsweise eine vereinheitlichte erweiterbare Firmware-Schnittstelle (UEFI: Unified Extensible Firmware Interface) sein. Die Netzwerksteuerung 1434 kann eine Netzwerkverbindung zu einem drahtgebundenen Netzwerk ermöglichen. In einigen Ausführungsformen ist eine Hochleistungsnetzwerksteuerung (nicht gezeigt) mit dem Schnittstellenbus 1410 gekoppelt. Die Audiosteuerung 1446 kann eine Mehrkanal-High-Definition- Audio Steuerung sein. In einigen dieser Ausführungsformen beinhaltet das System 1400 eine optionale Legacy-E/A-Steuerung 1440 zum Koppeln von Legacy(z. B. Personal System 2 (PS/2))-Vorrichtungen mit dem System. Der Plattformsteuerungshub 1430 kann auch mit einem oder mehreren USB(Universal Serial Bus)-Steuerungen 1442 verbunden sein, welche Eingabevorrichtungen, wie etwa Kombinationen aus Tastatur und Maus 1443, eine Kamera 1444 oder andere USB-Eingabevorrichtungen, verbinden.
  • Es versteht sich, dass das gezeigte System 1400 beispielhaft und nicht beschränkend ist, da andere Arten von Datenverarbeitungssystemen, die anders konfiguriert sind, ebenfalls verwendet werden können. Zum Beispiel kann eine Instanz der Speichersteuerung 1416 und des Plattformsteuerungshubs 1430 in einen diskreten externen Grafikprozessor, wie etwa den externen Grafikprozessor 1418, integriert sein. Der Plattformsteuerungshub 1430 und/oder die Speichersteuerung 1416 können extern zu dem einen oder den mehreren Prozessoren 1402 liegen. Zum Beispiel kann das System 1400 eine externe Speichersteuerung 1416 und einen Plattformsteuerungshub 1430 beinhalten, die als ein Speichersteuerungshub und ein Peripheriesteuerungshub innerhalb eines Systemchipsatzes konfiguriert sein können, der mit dem einen oder den mehreren Prozessoren 1402 in Kommunikation steht.
  • Zum Beispiel können Leiterplatten („Schlitten“) verwendet werden, auf denen Komponenten, wie etwa CPUs, Speicher und andere Komponenten, platziert sind, die für eine erhöhte thermische Leistungsfähigkeit gestaltet sind. Verarbeitungskomponenten, wie etwa die Prozessoren, können sich auf einer Oberseite eines Schlittens befinden, während sich Nahspeicher, wie etwa DIMMs, auf einer Unterseite des Schlittens befinden. Infolge des verbesserten Luftstroms, der durch diese Gestaltung bereitgestellt wird, können die Komponenten bei höheren Frequenzen und Leistungspegeln als in typischen Systemen arbeiten, wodurch die Leistungsfähigkeit erhöht wird. Des Weiteren sind die Schlitten dazu konfiguriert, blind mit Strom- und Datenkommunikationskabeln in einem Rack zusammenzupassen, wodurch ihre Fähigkeit verbessert wird, schnell entfernt, aufgerüstet, wieder installiert und/oder ersetzt zu werden. Gleichermaßen sind individuelle auf den Schlitten befindliche Komponenten wie Prozessoren, Beschleuniger, Speicher und Datenspeicherungslaufwerke so konfiguriert, dass sie sich dank ihrer größeren Beabstandung zueinander leicht aufrüsten lassen. In der veranschaulichenden Ausführungsform beinhalten die Komponenten zusätzlich Hardwareattestierungsmerkmale, um ihre Authentizität nachzuweisen.
  • Ein Datenzentrum kann eine einzelne Netzwerkarchitektur („Fabric“) nutzen, die mehrere andere Netzwerkarchitekturen unterstützt, darunter Ethernet und Omni-Path. Die Schlitten können über optische Fasern mit Switches gekoppelt sein, die eine höhere Bandbreite und eine niedrigere Latenz als eine typische Twisted-Pair-Verkabelung (z. B. Kategorie 5, Kategorie 5e, Kategorie 6 usw.) bereitstellen. Aufgrund der hochbandbreitigen, latenzarmen Verbindungen und Netzwerkarchitektur kann das Datenzentrum im Gebrauch Ressourcen, wie etwa Speicher, Beschleuniger (z. B. GPUs, Grafikbeschleuniger, FPGAs, ASICs, Neuronalnetzwerk- und/oder Künstliche-Intelligenz-Beschleuniger usw.) und Datenspeicherungslaufwerke, die physisch getrennt sind, zusammenschließen und sie Rechenressourcen (z. B. Prozessoren) nach Bedarf bereitstellen, wodurch ermöglicht wird, dass die Rechenressourcen auf die gepoolten Ressourcen zugreifen, als wären sie lokal.
  • Eine Leistungsversorgung oder -quelle kann Spannung und/oder Strom an das System 1400 oder eine beliebige Komponente oder ein beliebiges System, die/das hierin beschrieben wird, liefern. In einem Beispiel beinhaltet die Leistungsversorgung einen AC/DC(Wechselstrom-zu-Gleichstrom)-Adapter zum Einstecken in eine Wandsteckdose. Eine solche AC-Leistungsquelle kann eine erneuerbare Energiequelle (z. B. Solarstrom) sein. In einem Beispiel beinhaltet die Leistungsquelle eine DC-Leistungsquelle, wie etwa einen externen AC-DC-Wandler. Eine Leistungsquelle oder Leistungsversorgung kann auch Drahtlosladehardware zum Laden über die Nähe zu einem Ladefeld beinhalten. Die Leistungsquelle kann eine interne Batterie, eine Wechselstromversorgung, eine bewegungsbasierte Leistungsversorgung, eine Solarenergieversorgung oder eine Brennstoffzellenquelle beinhalten.
  • 15A-15C veranschaulichen Rechensysteme und Grafikprozessoren. Die Elemente von 15A-15C mit den gleichen oder ähnlichen Namen wie die Elemente einer beliebigen anderen Figur hierin beschreiben die gleichen Elemente wie in den anderen Figuren, können auf ähnliche Weise arbeiten oder fungieren, können die gleichen Komponenten umfassen und können mit anderen Entitäten wie jene, die an anderer Stelle hierin beschrieben sind, verknüpft sein, sind jedoch nicht darauf beschränkt.
  • 15A ist ein Blockdiagramm eines Prozessors 1500, der eine Variante eines der Prozessoren 1402 sein kann und anstelle eines dieser verwendet werden kann. Daher offenbart die Offenbarung jeglicher Merkmale in Kombination mit dem Prozessor 1500 hierin auch eine entsprechende Kombination mit dem einen oder den mehreren Prozessoren 1402, ist aber nicht darauf beschränkt. Der Prozessor 1500 kann einen oder mehrere Prozessorkerne 1502A-1502N, eine integrierte Speichersteuerung 1514 und einen integrierten Grafikprozessor 1508 aufweisen. Wenn ein integrierter Grafikprozessor 1508 ausgeschlossen ist, enthält das System, das den Prozessor enthält, eine Grafikprozessorvorrichtung innerhalb eines Systemchipsatzes oder ist über einen Systembus gekoppelt. Der Prozessor 1500 kann zusätzliche Kerne bis zu und einschließlich des zusätzlichen Kerns 1502N enthalten, der durch die gestrichelten Kästen repräsentiert ist. Jeder der Prozessorkerne 1502A-1502N beinhaltet eine oder mehrere interne Cacheeinheiten 1504A-1504N. In einigen Ausführungsformen weist jeder Prozessorkern 1502A - 1502N auch Zugriff auf eine oder mehrere gemeinsam genutzte Cacheeinheiten 1506 auf. Die internen Cacheeinheiten 1504A-1504N und die gemeinsam genutzten Cacheeinheiten 1506 repräsentieren eine Cachespeicherhierarchie innerhalb des Prozessors 1500. Die Cachespeicherhierarchie kann mindestens eine Ebene („Level“) von Anweisungs- und Datencache innerhalb jedes Prozessorkerns und eine oder mehrere Ebenen von gemeinsam genutztem Mid-Level-Cache, wie etwa Level 2 (L2), Level 3 (L3), Level 4 (L4) oder andere Cacheebenen beinhalten, wobei die höchste Cacheebene vor dem externen Speicher als LLC klassifiziert wird. In einigen Ausführungsformen bewahrt eine Cachekohärenzlogik die Kohärenz zwischen den verschiedenen Cacheeinheiten 1506 und 1504A-1504N.
  • Der Prozessor 1500 kann zudem einen Satz aus einer oder mehreren Bussteuerungseinheiten 1516 und einen Systemagentenkern 1510 beinhalten. Die eine oder die mehreren Bussteuerungseinheiten 1516 verwalten einen Satz von Peripheriebussen, wie etwa einen oder mehrere PCI- oder PCI-Express-Busse. Der Systemagentenkern 1510 stellt eine Verwaltungsfunktionalität für die verschiedenen Prozessorkomponenten bereit. Der Systemagentenkern 1510 kann eine oder mehrere integrierte Speichersteuerungen 1514 beinhalten, um den Zugriff auf verschiedene externe Speichervorrichtungen (nicht gezeigt) zu verwalten.
  • Beispielsweise beinhalten einer oder mehrere der Prozessorkerne 1502A-1502N eine Unterstützung für simultanes Multithreading. Der Systemagentenkern 1510 beinhaltet Komponenten zum Koordinieren und Betreiben der Kerne 1502A-1502N während der Multithreading-Verarbeitung. Der Systemagentenkern 1510 kann zusätzlich eine Leistungssteuereinheit (PCU) beinhalten, die Logik und Komponenten beinhaltet, um den Leistungszustand der Prozessorkerne 1502A - 1502N und des Grafikprozessors 1508 zu regulieren.
  • Der Prozessor 1500 kann zusätzlich einen Grafikprozessor 1508 zum Ausführen von Grafikverarbeitungsoperationen beinhalten. In einigen dieser Ausführungsformen ist der Grafikprozessor 1508 mit dem Satz von gemeinsam genutzten Cacheeinheiten 1506 und dem Systemagentenkern 1510 gekoppelt, einschließlich der einen oder der mehreren integrierten Speichersteuerungen 1514. Der Systemagentenkern 1510 kann auch eine Anzeigesteuerung 1511 zum Steuern die Grafikprozessorausgabe an eine oder mehrere gekoppelte Anzeigen beinhalten. Bei der Anzeigesteuerung 1511 kann es sich auch um ein separates Modul handeln, das über mindestens ein Interconnect mit dem Grafikprozessor gekoppelt ist, oder sie kann in den Grafikprozessor 1508 integriert sein.
  • Eine ringbasierte Interconnect-Einheit 1512 kann verwendet werden, um die internen Komponenten des Prozessors 1500 zu koppeln. Es kann jedoch auch eine alternative Interconnect-Einheit verwendet werden, wie etwa ein Punkt-zu-Punkt-Interconnect, ein geschaltetes Interconnect oder andere Techniken, einschließlich im Stand der Technik bekannter Techniken. In einigen dieser Ausführungsformen mit einem ringbasierten Interconnect 1512 ist der Grafikprozessor 1508 mit dem ringbasierten Interconnect 1512 über einen E/A-Link 1513 gekoppelt.
  • Der beispielhafte E/A-Link 1513 repräsentiert mindestens einen von mehreren Arten von E/A-Interconnects, einschließlich eines On-Package-E/A-Interconnect, das die Kommunikation zwischen verschiedenen Prozessorkomponenten und einem eingebetteten Hochleistungsspeichermodul 1518 wie etwa einem eDRAM-Modul ermöglicht. Optional können jeder der Prozessorkerne 1502A- 1502N und der Grafikprozessor 1508 eingebettete Speichermodule 1518 als gemeinsam genutzten Last-Level-Cache verwenden.
  • Die Prozessorkerne 1502A - 1502N können beispielsweise homogene Kerne sein, die dieselbe Anweisungssatzarchitektur ausführen. Alternativ sind die Prozessorkerne 1502A-1502N hinsichtlich der Anweisungssatzarchitektur (ISA: Instruction Set Architecture) heterogen, wobei einer oder mehrere der Prozessorkerne 1502A-1502N einen ersten Anweisungssatz ausführen, während mindestens einer der anderen Kerne einen Teilsatz des ersten Anweisungssatzes oder einen anderen Anweisungssatz ausführt. Die Prozessorkerne 1502A-1502N können in Bezug auf die Mikroarchitektur heterogen sein, wobei ein oder mehrere Kerne mit einem relativ höheren Leistungsverbrauch mit einem oder mehreren Leistungskernen mit einem niedrigeren Leistungsverbrauch gekoppelt sind. Als weiteres Beispiel sind die Prozessorkerne 1502A-1502N hinsichtlich der Rechenfähigkeit heterogen. Außerdem kann der Prozessor 1500 auf einem oder mehreren Chips oder als eine integrierte SoC-Schaltung mit den veranschaulichten Komponenten zusätzlich zu anderen Komponenten implementiert sein.
  • 15B ist ein Blockdiagramm einer Hardwarelogik eines Grafikprozessorkerns 1519 gemäß einigen hierin beschriebenen Ausführungsformen. Der Grafikprozessorkern 1519, der manchmal als ein Kern-Slice bezeichnet wird, kann ein oder mehrere Grafikkerne innerhalb eines modularen Grafikprozessors sein. Der Grafikprozessorkern 1519 ist beispielhaft für ein Grafikkern-Slice, und ein Grafikprozessor, wie hierin beschrieben, kann mehrere Grafikkern-Slices auf der Grundlage von Zielleistungs- und Leistungsverhaltenshüllkurven beinhalten. Jeder Grafikprozessorkern 1519 kann einen Festfunktionsblock 1530 beinhalten, der mit mehreren Unterkernen 1521A-1521F, auch als Unter-Slices bezeichnet, die modulare Blöcke von Allzweck- und Festfunktionslogik beinhalten, gekoppelt ist.
  • Der Festfunktionsblock 1530 kann eine Geometrie-/Festfunktions-Pipeline 1531 beinhalten, die durch alle Unterkerne in dem Grafikprozessorkern 1519 gemeinsam genutzt werden kann, zum Beispiel bei Grafikprozessorimplementierungen mit geringerer Leistungsfähigkeit und/oder geringerer Leistung. Die Geometrie-/Festfunktions-Pipeline 1531 kann eine 3D-Festfunktions-Pipeline (z. B. 3D-Pipeline 1612 wie in der nachstehend beschriebenen 16A), eine Video-Frontend-Einheit, einen Thread-Spawner und Thread-Dispatcher und einen Vereinheitlichter-Rückgabepuffer-Manager, der vereinheitlichte Rückgabepuffer verwaltet (z. B. den vereinheitlichten Rückgabepuffer 1718 von 17, wie nachstehend beschrieben) beinhalten.
  • Der Festfunktionsblock 1530 kann auch eine Grafik-SoC-Schnittstelle 1532, einen Grafik-Mikrocontroller 1533 und eine Medien-Pipeline 1534 beinhalten. Die Grafik-SoC-Schnittstelle 1532 stellt eine Schnittstelle zwischen dem Grafikprozessorkern 1519 und anderen Prozessorkernen innerhalb einer integrierten Schaltung eines System-on-Chip bereit. Der Grafik-Mikrocontroller 1533 ist ein programmierbarer Subprozessor, der dazu konfigurierbar ist, verschiedene Funktionen des Grafikprozessorkerns 1519 zu verwalten, einschließlich Thread-Dispatch, Scheduling und Präemption. Die Medien-Pipeline 1534 (z. B. die Medien-Pipeline 1616 von 16A und 17) beinhaltet Logik, um das Decodieren, Codieren, Vorverarbeiten und/oder Nachverarbeiten von Multimediadaten, einschließlich Bild- und Videodaten, zu ermöglichen. Die Medien-Pipeline 1534 implementiert Medienoperationen über Anfragen zum Berechnen oder Sampeln einer Logik innerhalb der Unterkerne 1521-1521F.
  • Die SoC-Schnittstelle 1532 kann dem Grafikprozessorkern 1519 die Kommunikation mit Prozessorkernen für Allzweckanwendungen (z. B. CPUs) und/oder anderen Komponenten innerhalb eines SoC ermöglichen, darunter Speicherhierarchieelemente wie etwa ein gemeinsam genutzter Last-Level-Cachespeicher, der System-RAM und/oder eingebetteter On-Chip- oder On-Package-DRAM. Die SoC-Schnittstelle 1532 kann auch die Kommunikation mit Festfunktionseinrichtungen innerhalb des SoC ermöglichen, wie etwa Kamerabildgebungs-Pipelines, und ermöglicht die Verwendung von und/oder implementiert globale Speicher-Atome, die zwischen dem Grafikprozessorkern 1519 und CPUs innerhalb des SoC gemeinsam genutzt werden können. Die SoC-Schnittstelle 1532 kann auch Leistungsverwaltungssteuerungen für den Grafikprozessorkern 1519 implementieren und eine Schnittstelle zwischen einer Taktdomäne des Grafikkerns 1519 und anderen Taktdomänen innerhalb des SoC ermöglichen. Optional ermöglicht die SoC-Schnittstelle 1532 den Empfang von Befehlspuffern von einem Befehls-Streamer und globalen Thread-Dispatcher, die dafür konfiguriert sind, Befehle und Anweisungen an jeden von einem oder mehreren Grafikkernen innerhalb eines Grafikprozessors bereitzustellen. Die Befehle und Anweisungen können an die Medien-Pipeline 1534 versendet werden, wenn Medienoperationen durchgeführt werden sollen, oder an eine Geometrie- und Festfunktions-Pipeline (z. B. Geometrie- und Festfunktions-Pipeline 1531, Geometrie- und Festfunktions-Pipeline 1537), wenn Grafikverarbeitungsoperationen durchgeführt werden sollen.
  • Der Grafik-Mikrocontroller 1533 kann dafür konfiguriert sein, verschiedene Scheduling- und Verwaltungsaufgaben für den Grafikprozessorkern 1519 durchzuführen. In einer Konfiguration kann der Grafik-Mikrocontroller 1533 beispielsweise Grafik- und/oder Rechenlast-Scheduling auf den verschiedenen parallelen Grafik-Engines innerhalb der Arrays 1522A-1522F, 1524A-1524F der Ausführungseinheiten (AE) innerhalb der Unterkerne 1521A-1521F durchführen. Bei diesem Arbeitslast-Scheduling kann Host-Software, die auf einem CPU-Kern eines den Grafikprozessorkern 1519 beinhaltenden SoC ausgeführt wird, Arbeitslasten einer von mehreren Grafikprozessor-Doorbells liefern, was eine Scheduling-Operation auf der entsprechenden Grafik-Engine aktiviert. Zu Scheduling-Operationen zählen Bestimmen, welche Arbeitslast als nächstes ausgeführt werden soll, Liefern einer Arbeitslast an einen Befehls-Streamer, Präemptieren bestehender Arbeitslasten, die auf einer Engine ausgeführt werden, Überwachen des Fortschritts einer Arbeitslast und Benachrichtigen einer Host-Software, wenn eine Arbeitslast abgeschlossen ist. Optional kann der Grafik-Mikrocontroller 1533 auch Niederleistungs- 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 Niederleistungszustandsübergänge hinweg unabhängig von dem Betriebssystem und/oder der Grafiktreibersoftware auf dem System zu speichern und wiederherzustellen.
  • Der Grafikprozessorkern 1519 kann mehr als oder weniger als die veranschaulichten Unterkerne 1521A-1521F aufweisen, bis zu N modulare Unterkerne. Für jeden Satz aus N Unterkernen kann der Grafikprozessorkern 1519 auch eine Logik 1535 mit gemeinsam genutzter Funktion, einen gemeinsam genutzten Speicher und/oder Cachespeicher 1536, eine Geometrie-/Festfunktions-Pipeline 1537 sowie eine zusätzliche Festfunktionslogik 1538 zur Beschleunigung verschiedener Grafik- und Rechenverarbeitungsoperationen beinhalten. Die Logik 1535 mit gemeinsam genutzter Funktion kann Logikeinheiten beinhalten, die mit der Logik 1720 mit gemeinsam genutzter Funktion von 17 assoziiert sind (z. B. Sampler-, Mathe- und/oder Inter-Thread-Kommunikationslogik), die durch jeden der N Unterkerne innerhalb des Grafikprozessorkerns 1519 gemeinsam genutzt werden können. Der gemeinsam genutzte Speicher und/oder Cachespeicher 1536 kann ein Last-Level-Cache für den Satz von N Unterkernen 1521A-1521F innerhalb des Grafikprozessorkerns 1519 sein und kann auch als gemeinsam genutzter Speicher dienen, auf den mehrere Unterkerne zugreifen können. Die Geometrie-/Festfunktions-Pipeline 1537 kann anstelle der Geometrie-/Festfunktions-Pipeline 1531 innerhalb des Festfunktionsblocks 1530 enthalten sein und dieselben oder ähnliche Logikeinheiten aufweisen.
  • Der Grafikprozessorkern 1519 kann zusätzliche Festfunktionslogik 1538 beinhalten, die verschiedene Festfunktionsbeschleunigungslogik zur Verwendung durch den Grafikprozessorkern 1519 beinhalten kann. Optional beinhaltet die zusätzliche Festfunktionslogik 1538 eine zusätzliche Geometrie-Pipeline zur Verwendung beim Nur-Positions-Shading. Beim Nur-Positions-Shading existieren zwei Geometrie-Pipelines, die vollständige Geometrie-Pipeline innerhalb der Geometrie-/Festfunktions-Pipeline 1538, 1531 und eine Cull-Pipeline, die eine zusätzliche Geometrie-Pipeline ist, die in der zusätzlichen Festfunktionslogik 1538 enthalten sein kann. Zum Beispiel kann die Cull-Pipeline eine abgespeckte Version der vollständigen Geometrie-Pipeline sein. Die vollständige Pipeline und die Cull-Pipeline können verschiedene Instanzen derselben Anwendung ausführen, wobei jede Instanz einen separaten Kontext aufweist. Das Nur-Positions-Shading kann lange Aussortierdurchläufe von verworfenen Dreiecken verbergen, wodurch das Shading in manchen Fällen früher abgeschlossen werden kann. Zum Beispiel kann die Cull-Pipeline-Logik innerhalb der zusätzlichen Festfunktionslogik 1538 Positions-Shader parallel zur Hauptanwendung ausführen und erzeugt allgemein kritische Ergebnisse schneller als die vollständige Pipeline, da die Cull-Pipeline nur das Positionsattribut der Vertices abruft und diese schattiert, ohne Rasterisierung und Rendering der Pixel zum Rahmenpuffer durchzuführen. Die Cull-Pipeline kann die erzeugten kritischen Ergebnisse verwenden, um Sichtbarkeitsinformationen für alle Dreiecke zu berechnen, ohne Rücksicht darauf, ob diese Dreiecke aussortiert werden. Die vollständige Pipeline (die in diesem Fall als Wiedergabe-Pipeline bezeichnet werden kann) kann die Sichtbarkeitsinformationen verbrauchen, um die aussortierten Dreiecke zu überspringen, um nur an den sichtbaren Dreiecken Shading durchzuführen, die schließlich an die Rasterisierungsphase übergeben werden.
  • Optional kann die zusätzliche Festfunktionslogik 1538 auch eine Maschinenlernbeschleunigungslogik, wie etwa eine Festfunktions-Matrixmultiplikationslogik, für Implementierungen einschließlich Optimierungen für Maschinenlerntraining oder Inferenzieren, beinhalten.
  • Innerhalb jedes Grafikunterkerns 1521A-1521F ist ein Satz von Ausführungsressourcen enthalten, die verwendet werden können, um Grafik-, Medien- und Rechenoperationen als Reaktion auf Anforderungen durch eine Grafik-Pipeline, Medien-Pipeline oder Shader-Programme durchzuführen. Die Grafikunterkerne 1521A-1521F beinhalten mehrere AE-Arrays 1522A-1522F, 1524A-1524F, Thread-Dispatch- und Inter-Thread-Kommunikations(TD/IC)-Logik 1523A-1523F, einen 3D-Sampler (z. B. Textur-Sampler) 1525A-1525F, einen Medien-Sampler 1506A-1506F, einen Shader-Prozessor 1527A-1527F und einen gemeinsam genutzten lokalen Speicher (SLM: Shared Local Memory) 1528A-1528F. Die AE-Arrays 1522A-1522F, 1524A-1524F beinhalten jeweils mehrere Ausführungseinheiten, die Allzweck-Grafikverarbeitungseinheiten sind, die Gleitkomma- und Ganzzahl-/Festkommalogikoperationen im Dienst einer Grafik-, Medien- oder Rechenoperation durchführen können, einschließlich Grafik-, Medien- oder Rechen-Shader-Programmen. Die TD/IC-Logik 1523A-1523F führt lokale Thread-Dispatch- und Thread-Steueroperationen für die Ausführungseinheiten innerhalb eines Unterkerns aus und ermöglicht die Kommunikation zwischen Threads, die auf den Ausführungseinheiten des Unterkerns ausgeführt werden. Der 3D-Sampler 1525A-1525F kann Textur oder andere 3D-Grafik-bezogene Daten in den Speicher lesen. Der 3D-Sampler kann Texturdaten basierend auf einem konfigurierten Sample-Status und dem Texturformat, das mit einer gegebenen Textur assoziiert ist, unterschiedlich lesen. Der Medien-Sampler 1506A-1506F kann ähnliche Leseoperationen basierend auf der Art und dem Format durchführen, die mit den Mediendaten assoziiert sind. Zum Beispiel kann jeder Grafikunterkern 1521A-1521F abwechselnd einen vereinheitlichten 3D- und Medien-Sampler beinhalten. Threads, die auf den Ausführungseinheiten in jedem der Unterkerne 1521A-1521F ausgeführt werden, können den gemeinsam genutzten lokalen Speicher 1528A-1528F in jedem Unterkern verwenden, um zu ermöglichen, dass Threads, die innerhalb einer Thread-Gruppe ausgeführt werden, unter Verwendung eines gemeinsamen On-Chip-Speicher-Pools ausgeführt werden.
  • 15C ist ein Blockdiagramm einer Allzweck-Grafikverarbeitungseinheit (GPGPU) 1570, die gemäß hierin beschriebenen Ausführungsformen als ein Grafikprozessor, z. B. der Grafikprozessor 1508, und/oder ein Berechnungsbeschleuniger konfiguriert werden kann. Die GPGPU 1570 kann über einen oder mehrere System- und/oder Speicherbusse mit Hostprozessoren (z. B. einer oder mehreren CPUs 1546) und Speicher 1571, 1572 verbunden sein. Der Speicher 1571 kann Systemspeicher sein, der mit der einen oder mehreren CPUs 1546 gemeinsam genutzt werden kann, während der Speicher 1572 ein Vorrichtungsspeicher ist, der der GPGPU 1570 dediziert ist. Zum Beispiel können Komponenten innerhalb der GPGPU 1570 und des Vorrichtungsspeichers 1572 auf Speicheradressen abgebildet werden, auf die die eine oder die mehreren CPUs 1546 zugreifen können. Der Zugriff auf die Speicher 1571 und 1572 kann über eine Speichersteuerung 1568 ermöglicht werden. Die Speichersteuerung 1568 kann eine interne Direktspeicherzugriff(DMA)-Steuerung 1569 beinhalten oder kann Logik enthalten, um Operationen durchzuführen, die ansonsten durch eine DMA-Steuerung ausgeführt werden würden.
  • Die GPGPU 1570 enthält mehrere Cachespeicher, einschließlich eines L2-Cache 1553, L1-Cache 1554, eines Anweisungscache 1555 und eines gemeinsam genutzten Speichers 1556, von dem zumindest ein Teil auch als Cachespeicher partitioniert werden kann. Die GPGPU 1570 enthält außerdem mehrere Berechnungseinheiten 1560A-1560N. Jede Berechnungseinheit 1560A-1560N beinhaltet einen Satz von Vektorregistern 1561, Skalarregister 1562, Vektorlogikeinheiten 1563 und Skalarlogikeinheiten 1564. Die Berechnungseinheiten 1560A-1560N können auch einen lokalen gemeinsam genutzten Speicher 1565 und einen Programmzähler 1566 beinhalten. Die Berechnungseinheiten 1560A-1560N können mit einem konstanten Cache 1567 gekoppelt werden, der zum Speichern von konstanten Daten verwendet werden kann, die Daten sind, die sich während der Ausführung eines Kernel- oder Shader-Programms, das auf der GPGPU 1570 ausgeführt wird, nicht ändern. Der konstante Cache 1567 kann ein Skalardaten-Cache sein und gecachte Daten können direkt in die Skalarregister 1562 abgerufen werden.
  • Während des Betriebs können die eine oder die mehreren CPUs 1546 Befehle in Register oder Speicher in der GPGPU 1570 schreiben, die in einen zugänglichen Adressraum abgebildet wurde. Die Befehlsprozessoren 1557 können die Befehle aus Registern oder dem Speicher lesen und bestimmen, wie diese Befehle innerhalb der GPGPU 1570 verarbeitet werden. Ein Thread-Dispatcher 1558 kann dann verwendet werden, um Threads an die Berechnungseinheiten 1560A-1560N zu senden, um diese Befehle auszuführen. Jede Berechnungseinheit 1560A-1560N kann Threads unabhängig von den anderen Berechnungseinheiten ausführen. Außerdem kann jede Berechnungseinheit 1560A-1560N unabhängig für eine bedingte Berechnung konfiguriert werden und die Ergebnisse der Berechnung bedingt an den Speicher ausgeben. Die Befehlsprozessoren 1557 können die eine oder die mehreren CPUs 1546 unterbrechen, wenn die übermittelten Befehle abgeschlossen sind.
  • 16A-16C veranschaulichen Blockdiagramme zusätzlicher Grafikprozessor- und Berechnungsbeschleunigerarchitekturen, die durch hierin beschriebene Ausführungsformen bereitgestellt werden, z. B. gemäß 15A-15C. Die Elemente von 16A-16C mit den gleichen oder ähnlichen Namen wie die Elemente einer beliebigen anderen Figur hierin beschreiben die gleichen Elemente wie in den anderen Figuren, können auf ähnliche Weise arbeiten oder fungieren, können die gleichen Komponenten umfassen und können mit anderen Entitäten wie jene, die an anderer Stelle hierin beschrieben sind, verknüpft sein, sind jedoch nicht darauf beschränkt.
  • 16A ist ein Blockdiagramm eines Grafikprozessors 1600, der eine diskrete Grafikverarbeitungseinheit sein kann oder ein Grafikprozessor sein kann, der mit mehreren Verarbeitungskernen integriert ist, oder andere Halbleitervorrichtungen, wie etwa unter anderem Speichervorrichtungen oder Netzwerkschnittstellen. Der Grafikprozessor 1600 kann eine Variante des Grafikprozessors 1508 sein und kann anstelle des Grafikprozessors 1508 verwendet werden. Daher offenbart die Offenbarung jeglicher Merkmale in Kombination mit dem Grafikprozessor 1508 hierin auch eine entsprechende Kombination mit dem Grafikprozessor 1600, ist aber nicht darauf beschränkt. Der Grafikprozessor kann über eine speicherabgebildete E/A-Schnittstelle mit Registern auf dem Grafikprozessor und mit in den Prozessorspeicher platzierten Befehlen kommunizieren. Der Grafikprozessor 1600 kann eine Speicherschnittstelle 1614 enthalten, um auf Speicher zuzugreifen. Die Speicherschnittstelle 1614 kann eine Schnittstelle zu einem lokalem Speicher, einem oder mehreren internen Caches, einem oder mehreren gemeinsam genutzten externen Caches und/oder einem Systemspeicher sein.
  • Optional beinhaltet der Grafikprozessor 1600 zudem eine Anzeigesteuerung 1602, um Anzeigeausgabedaten zu einer Anzeigevorrichtung 1618 zu steuern. Die Anzeigesteuerung 1602 beinhaltet Hardware für eine oder mehrere Überlagerungsebenen für die Anzeige und Zusammensetzung mehrerer Schichten von Video- oder Benutzeroberflächenelementen. Die Anzeigevorrichtung 1618 kann eine interne oder externe Anzeigevorrichtung sein. Bei einer Ausführungsform ist die Anzeigevorrichtung 1618 eine am Kopf angebrachte Anzeigevorrichtung, wie etwa eine VR(Virtual Reality)-Anzeigevorrichtung oder eine AR(Augmented Reality)-Anzeigevorrichtung. Der Grafikprozessor 1600 kann eine Video-Codec-Engine 1606 zum Codieren, Decodieren oder Transcodieren von Medien zu, von oder zwischen einem oder mehreren Mediencodierformaten beinhalten, darunter unter anderem MPEG-Formate (MPEG: Moving Picture Experts Group) wie MPEG-2, AVC-Formate (AVC: Advanced Video Coding) wie H.264/MPEG-4 AVC, H.265/HEVC, Alliance for Open Media (AOMedia) VP8, VP9 sowie die SNIPTE-421M/VC-1- (SMPTE: Society of Motion Picture & Television Engineers) und JPEG- (JPEG: Joint Photographic Experts Group) Formate wie JPEG- und Motion-JPEG(MJPEG)-Formate.
  • Der Grafikprozessor 1600 kann eine Blockbildtransfer(BLIT)-Engine 1604 beinhalten, um zweidimensionale (2D) Rasterisiereroperationen durchzuführen, einschließlich zum Beispiel Bitgrenzblocktransfers. Alternativ können jedoch 2D-Grafikoperationen unter Verwendung einer oder mehrerer Komponenten der Grafikverarbeitungs-Engine (GPE) 1610 durchgeführt werden. In manchen Ausführungsformen ist die GPE 1610 eine Berechnungs-Engine zum Durchführen von Grafikoperationen, einschließlich dreidimensionaler (3D) Grafikoperationen und Medienoperationen.
  • Die GPE 1910 kann eine 3D-Pipeline 1612 zum Durchführen von 3D-Operationen beinhalten, wie etwa Rendering von dreidimensionalen Bildern und Szenen unter Verwendung von Verarbeitungsfunktionen, die auf 3D-Primitivformen (z. B. Rechteck, Dreieck usw.) wirken. Die 3D-Pipeline 1612 beinhaltet programmierbare und feste Funktionselemente, die verschiedene Aufgaben innerhalb des Elements durchführen und/oder Ausführungs-Threads zu einem 3D/Medien-Subsystem 1615 erzeugen. Während die 3D-Pipeline 1612 zum Durchführen von Medienoperationen verwendet werden kann, beinhaltet eine Ausführungsform der GPE 1610 auch eine Medien-Pipeline 1616, die speziell zum Durchführen von Medienoperationen, wie etwa Videonachbearbeitung und Bildverbesserung, verwendet wird.
  • Die Medien-Pipeline 1616 kann Festfunktions- oder programmierbare Logikeinheiten beinhalten, um eine oder mehrere spezialisierte Medienoperationen, wie etwa Videodecodierungsbeschleunigung, Videoentschachtelung und Videocodierungsbeschleunigung, anstelle von oder im Auftrag der Video-Codec-Engine 1606 durchzuführen. Die Medien-Pipeline 1616 kann außerdem eine Thread-Spawning-Einheit beinhalten, um Threads zur Ausführung auf dem 3D/Medien-Subsystem 1615 zu spawnen. Die gespawnten Threads führen Berechnungen für die Medienoperationen auf einer oder mehreren Grafikausführungseinheiten durch, die in dem 3D/Medien-Subsystem 1615 enthalten sind.
  • Das 3D/Medien-Subsystem 1615 kann Logik zum Ausführen von durch die 3D-Pipeline 1612 und die Medien-Pipeline 1616 gespawnten Threads beinhalten. Die Pipelines können Thread-Ausführungsanforderungen an das 3D/Medien-Subsystem 1615 senden, das eine Thread-Dispatch-Logik für die Vermittlung und Verteilung der verschiedenen Anforderungen an verfügbare Thread-Ausführungsressourcen beinhaltet. Die Ausführungsressourcen beinhalten ein Array von Grafikausführungseinheiten zum Verarbeiten der 3D- und Medien-Threads. Das 3D/Medien-Subsystem 1615 kann einen oder mehrere interne Caches für Thread-Anweisungen und Daten beinhalten. Zusätzlich kann das 3D/Medien-Subsystem auch gemeinsam genutzten Speicher beinhalten, einschließlich Registern und adressierbarem Speicher, um Daten zwischen Threads gemeinsam zu nutzen und Ausgabedaten zu speichern.
  • 16B veranschaulicht einen Grafikprozessor 1620, der eine Variante des Grafikprozessors 1600 ist und anstelle des Grafikprozessors 1600 verwendet werden kann und umgekehrt. Daher offenbart die Offenbarung jeglicher Merkmale in Kombination mit dem Grafikprozessor 1600 hierin auch eine entsprechende Kombination mit dem Grafikprozessor 1620, ist aber nicht darauf beschränkt. Der Grafikprozessor 1620 weist gemäß hierin beschriebenen Ausführungsformen eine gekachelte Architektur auf. Der Grafikprozessor 1620 kann einen Grafikverarbeitungs-Engine-Cluster 1622 mit mehreren Instanzen der Grafikverarbeitungs-Engine 1610 von 16A innerhalb einer Grafik-Engine-Kachel 1610A-1610D beinhalten. Jede Grafik-Engine-Kachel 1610A-1610D kann über einen Satz von Kachel-Interconnects 1623A-1623F miteinander verbunden sein. Jede Grafik-Engine-Kachel 1610A-1610D kann auch über Speicher-Interconnects 1625A-1625D mit einem Speichermodul oder einer Speichervorrichtung 1626A-1626D verbunden sein. Die Speichervorrichtungen 1626A-1626D können eine beliebige Grafikspeichertechnologie verwenden. Zum Beispiel können die Speichervorrichtungen 1626A - 1626D ein Grafikspeicher mit doppelter Datenrate (GDDR) sein. Die Speichervorrichtungen 1626A - 1626D können Hochbandbreitenspeicher(HBM)-Module sein, die sich On-Die mit ihrer jeweiligen Grafik-Engine-Kachel 1610A- 1610D befinden können. Die Speichervorrichtungen 1626A - 1626D können gestapelte Speichervorrichtungen sein, die auf ihre jeweiligen Grafik-Engine-Kacheln 1610A- 1610D gestapelt werden können. Jede Grafik-Engine-Kachel 1610A-1610D und die assoziierten Speichervorrichtungen 1626A - 1626D können sich auf separaten Chiplets befinden, die an einen Basis-Die oder ein Basis-Substrat gebondet sind, wie in 24B-24D ausführlicher beschrieben.
  • Der Grafikprozessor 1620 kann mit einem Non-Uniform-Memory-Access(NUMA; ungleichförmiger Speicherzugriff)-System konfiguriert sein, bei dem die Speichervorrichtungen 1626A-1626D mit assoziierten Grafik-Engine-Kacheln 1610A-1610D gekoppelt sind. Auf eine gegebene Speichervorrichtung kann durch andere Grafik-Engine-Kacheln als die Kachel zugegriffen werden, mit der sie direkt verbunden ist. Jedoch kann die Zugriffslatenz auf die Speichervorrichtungen 1626A - 1626D am niedrigsten sein, wenn auf eine lokale Kachel zugegriffen wird. In einer Ausführungsform ist ein cachekohärentes NUMA(ccNUMA)-System aktiviert, das die Kachel-Interconnects 1623A-1623F verwendet, um die Kommunikation zwischen Cachesteuerungen innerhalb der Grafik-Engine-Kacheln 1610A-1610D zu ermöglichen, damit ein konsistentes Speicherabbild beibehalten wird, wenn mehr als ein Cache denselben Speicherort speichert.
  • Der Grafikverarbeitungs-Engine-Cluster 1622 kann mit einem On-Chip- oder On-Package-Fabric-Interconnect 1624 verbunden sein. Das Fabric-Interconnect 1624 kann die Kommunikation zwischen den Grafik-Engine-Kacheln 1610A-1610D und Komponenten wie dem Video-Codec 1606 und einer oder mehreren Kopier-Engines 1604 ermöglichen. Die Kopier-Engines 1604 können verwendet werden, um Daten aus den, in die und zwischen den Speichervorrichtungen 1626A - 1626D und einem Speicher extern zu dem Grafikprozessor 1620 (z. B. Systemspeicher) zu verschieben. Das Fabric-Interconnect 1624 kann auch verwendet werden, um die Grafik-Engine-Kacheln 1610A-1610D miteinander zu verbinden. Der Grafikprozessor 1620 kann optional eine Anzeigesteuerung 1602 beinhalten, um eine Verbindung mit einer externen Anzeigevorrichtung 1618 zu ermöglichen. Der Grafikprozessor kann auch als Grafik- oder Berechnungsbeschleuniger konfiguriert sein. In der Beschleunigerkonfiguration können die Anzeigesteuerung 1602 und die Anzeigevorrichtung 1618 weggelassen werden.
  • Der Grafikprozessor 1620 kann über eine Hostschnittstelle 1628 mit einem Hostsystem verbunden sein. Die Hostschnittstelle 1628 kann eine Kommunikation zwischen dem Grafikprozessor 1620, dem Systemspeicher und/oder anderen Systemkomponenten ermöglichen. Die Hostschnittstelle 1628 kann beispielsweise ein PCI-Express-Bus oder eine andere Art von Hostsystemschnittstelle sein.
  • 16C veranschaulicht einen Berechnungsbeschleuniger 1630 gemäß hierin beschriebenen Ausführungsformen. Der Berechnungsbeschleuniger 1630 kann architektonische Ähnlichkeiten mit dem Grafikprozessor 1620 von 16B aufweisen und ist für die Berechnungsbeschleunigung optimiert. Ein Berechnungs-Engine-Cluster 1632 kann einen Satz von Berechnungs-Engine-Kacheln 1640A - 1640D beinhalten, die eine Ausführungslogik beinhalten, die für parallele oder vektorbasierte Allzweck-Rechenoperationen optimiert ist. Die Berechnungs-Engine-Kacheln 1640A - 1640D beinhalten möglicherweise keine Festfunktions-Grafikverarbeitungslogik, obwohl in einigen Ausführungsformen eine oder mehrere der Berechnungs-Engine-Kacheln 1640A - 1640D Logik zum Durchführen einer Medienbeschleunigung beinhalten können. Die Berechnungs-Engine-Kacheln 1640A-1640D können über Speicher-Interconnects 1625A-1625D mit Speichervorrichtungen 1626A-1626D verbunden werden. Die Speichervorrichtungen 1626A - 1626D und die Speicher-Interconnects 1625A - 1625D können eine ähnliche Technologie wie im Grafikprozessor 1620 sein oder können anders sein. Die Grafikberechnungs-Engine-Kacheln 1640A- 1640D können auch über einen Satz von Kachel-Interconnects 1623A - 1623F miteinander verbunden sein und können mit einem Fabric-Interconnect 1624 verbunden und/oder durch dieses miteinander verbunden sein. In einer Ausführungsform beinhaltet der Berechnungsbeschleuniger 1630 einen großen L3-Cache 1636, der als ein vorrichtungsumfassender Cache konfiguriert werden kann. Der Berechnungsbeschleuniger 1630 kann auch über eine Hostschnittstelle 1628 in ähnlicher Weise wie der Grafikprozessor 1620 von 16B mit einem Hostprozessor und Speicher verbunden sein.
  • Grafikverarbeitungs-Engine
  • 17 ist ein Blockdiagramm einer Grafikverarbeitungs-Engine 1710 eines Grafikprozessors gemäß einigen Ausführungsformen. Die Grafikverarbeitungs-Engine (GPE) 1710 kann eine Version der in 16A gezeigten GPE 1610 sein und kann auch eine Grafik-Engine-Kachel 1610A-1610D von 16B repräsentieren. Die Elemente von 17 mit den gleichen oder ähnlichen Namen wie die Elemente einer beliebigen anderen Figur hierin beschreiben die gleichen Elemente wie in den anderen Figuren, können auf ähnliche Weise arbeiten oder fungieren, können die gleichen Komponenten umfassen und können mit anderen Entitäten wie jene, die an anderer Stelle hierin beschrieben sind, verknüpft sein, sind jedoch nicht darauf beschränkt. Zum Beispiel sind die 3D-Pipeline 1612 und die Medien-Pipeline 1616 16A auch in 17 veranschaulicht. Die Medien-Pipeline 1616 ist in einigen Ausführungsformen der GPE 1710 optional und ist möglicherweise nicht explizit in der GPE 1710 enthalten. Zum Beispiel und in mindestens einer Ausführungsform ist ein separater Medien- und/oder Bildprozessor mit der GPE 1710 gekoppelt.
  • Die GPE 1710 kann mit einem Befehls-Streamer 1703 gekoppelt sein oder diesen beinhalten, der einen Befehlsstrom an die 3D-Pipeline 1612 und/oder die Medien-Pipelines 1616 bereitstellt. Alternativ oder zusätzlich kann der Befehls-Streamer 1703 direkt mit einem vereinheitlichten Rückgabepuffer 1718 gekoppelt sein. Der vereinheitlichte Rückgabepuffer 1718 kann kommunikativ an ein Grafikkernarray 1714 gekoppelt sein. Optional ist der Befehls-Streamer 1703 mit einem Speicher, der ein Systemspeicher sein kann, oder einem internen Cachespeicher und/oder einem gemeinsam genutzten Cachespeicher gekoppelt. Der Befehls-Streamer 1703 kann Befehle vom Speicher empfangen und sendet die Befehle an die 3D-Pipeline 1612 und/oder die Medien-Pipeline 1616. Die Befehle sind Direktiven, die aus einem Ringpuffer abgerufen werden, der Befehle für die 3D-Pipeline 1612 und die Medien-Pipeline 1616 speichert. Der Ringpuffer kann zusätzlich Batch-Befehlspuffer aufweisen, die Batches aus mehreren Befehlen speichern. Die Befehle für die 3D-Pipeline 1612 können auch Verweise auf Daten beinhalten, die im Speicher gespeichert sind, wie etwa unter anderem Vertex- und Geometriedaten für die 3D-Pipeline 1612 und/oder Bilddaten und Speicherobjekte für die Medien-Pipeline 316. Die 3D-Pipeline 1612 und die Medien-Pipeline 1616 verarbeiten die Befehle und Daten, indem sie Operationen über eine Logik innerhalb der jeweiligen Pipelines durchführen oder indem sie einen oder mehrere Ausführungs-Threads an das Grafikkernarray 1714 versenden. Das Grafikkernarray 1714 kann einen oder mehrere Blöcke aus Grafikkernen (z. B. Grafikkern(e) 1715A, Grafikkern(e) 1715B) beinhalten, wobei jeder Block einen oder mehrere Grafikkerne beinhaltet. Jeder Grafikkern beinhaltet einen Satz von Grafikausführungsressourcen, der eine Allzweck- und grafikspezifische Ausführungslogik zum Ausführen von Grafik- und Rechenoperationen sowie Festfunktionstexturverarbeitung und/oder Maschinenlernen und eine Künstliche-Intelligenz-Beschleunigungslogik beinhaltet.
  • In verschiedenen Ausführungsformen kann die 3D-Pipeline 1612 Festfunktions- und programmierbare Logik beinhalten, um ein oder mehrere Shader-Programme, wie etwa Vertex-Shader, Geometrie-Shader, Pixel-Shader, Fragment-Shader, Berechnungs-Shader oder andere Shader-Programme zu verarbeiten, indem die Anweisungen verarbeitet und Ausführungs-Threads an das Grafikkern-Array 1714 versendet werden. Das Grafikkernarray 1714 stellt einen vereinheitlichten Block von Ausführungsressourcen zur Verwendung bei der Verarbeitung dieser Shader-Programme bereit. Eine Allzweckausführungslogik (z. B. Ausführungseinheiten) innerhalb des einen bzw. der mehreren Grafikkerne 1715A-1714B des Grafikkernarrays 1714 unterstützt verschiedene 3D-API-Shader-Sprachen und kann mehrere simultane Ausführungs-Threads ausführen, die mit mehreren Shadern assoziiert sind.
  • Das Grafikkernarray 1714 kann Ausführungslogik zum Durchführen von Medienfunktionen wie etwa Video- und/oder Bildverarbeitung beinhalten. Die Ausführungseinheiten können zusätzlich Allzwecklogik beinhalten, die dazu programmierbar ist, parallele Allzweck-Rechenoperationen zusätzlich zu Grafikverarbeitungsoperationen durchzuführen. Die Allzwecklogik kann Verarbeitungsoperationen parallel oder in Verbindung mit der Allzwecklogik innerhalb des einen bzw. der mehreren Prozessorkerne 1407 von 14 oder des Kerns 1502A-1502N wie in 15A durchführen.
  • Ausgabedaten, die durch Threads erzeugt werden, die auf dem Grafikkernarray 1714 ausgeführt werden, können Daten an einen Speicher in einem vereinheitlichten Rückgabepuffer (URB) 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 Grafikkernarray 1714 ausgeführt werden. Der URB 1718 kann zusätzlich zur Synchronisation zwischen Threads auf dem Grafikkernarray 1714 und einer Festfunktionslogik innerhalb der Logik 1720 mit gemeinsam genutzter Funktion verwendet werden.
  • Optional kann das Grafikkernarray 1714 skalierbar sein, sodass das Array eine variable Anzahl von Grafikkernen mit jeweils einer variablen Anzahl an Ausführungseinheiten, die auf der Zielleistung und der Leistungsverhaltensstufe der GPE 1710 basiert, beinhaltet. Die Ausführungsressourcen können dynamisch skalierbar sein, sodass Ausführungsressourcen je nach Bedarf aktiviert oder deaktiviert werden können.
  • Das Grafikkernarray 1714 ist mit Logik 1720 mit gemeinsam genutzter Funktion gekoppelt, die mehrere Ressourcen beinhaltet, die unter den Grafikkernen in dem Grafikkernarray gemeinsam genutzt werden. Die gemeinsam genutzten Funktionen innerhalb der Logik 1720 mit gemeinsam genutzter Funktion sind Hardware-Logikeinheiten, die dem Grafikkernarray 1714 eine spezialisierte Zusatzfunktionalität bereitstellen. In verschiedenen Ausführungsformen beinhaltet die Logik 1720 mit gemeinsam genutzter Funktion, ohne darauf beschränkt zu sein, eine Sampler- 1721, eine Mathe- 1722 und eine Inter-Thread-Kommunikations(ITC: Inter-Thread Communication)-Logik 1723. Außerdem können ein oder mehrere Caches 1725 innerhalb der Logik 1720 mit gemeinsam genutzter Funktion implementiert werden.
  • Eine gemeinsam genutzte Funktion wird zumindest in einem Fall implementiert, in dem die Anforderung für eine gegebene spezialisierte Funktion für die Aufnahme in das Grafikkernarray 1714 unzureichend ist. Stattdessen wird eine einzelne Instanziierung dieser spezialisierten Funktion als eine eigenständige Entität in der Logik 1720 mit gemeinsam genutzter Funktion implementiert und unter den Ausführungsressourcen innerhalb des Grafikkernarrays 1714 gemeinsam genutzt. Der genaue Satz von Funktionen, die von dem Grafikkernarray 1714 gemeinsam genutzt werden und im Grafikkernarray 1714 enthalten sind, variiert zwischen den Ausführungsformen. Spezifische gemeinsam genutzte Funktionen innerhalb der Logik 1720 mit gemeinsam genutzter Funktion, die ausgiebig von dem Grafikkernarray 1714 verwendet werden, können in der Logik 1716 mit gemeinsam genutzter Funktion innerhalb des Grafikkernarrays 1714 enthalten sein. Optional kann die Logik 1716 mit gemeinsam genutzter Funktion innerhalb des Grafikkernarrays 1714 einen Teil der oder die gesamte Logik innerhalb der Logik 1720 mit gemeinsam genutzter Funktion beinhalten. Alle Logikelemente innerhalb der Logik 1720 mit gemeinsam genutzter Funktion können innerhalb der Logik 1716 mit gemeinsam genutzter Funktion des Grafikkernarrays 1714 dupliziert werden. Alternativ wird die Logik 1720 mit gemeinsam genutzter Funktion zugunsten der Logik 1716 mit gemeinsam genutzter Funktion innerhalb des Grafikkernarrays 1714 ausgeschlossen.
  • Ausführungseinheiten
  • 18A-18B veranschaulichen Thread-Ausführungslogik 1800 einschließlich eines Arrays von Verarbeitungselementen, die in einem Grafikprozessorkern eingesetzt werden, gemäß hierin beschriebenen Ausführungsformen. Die Elemente von 18A-18B mit den gleichen oder ähnlichen Namen wie die Elemente einer beliebigen anderen Figur hierin beschreiben die gleichen Elemente wie in den anderen Figuren, können auf ähnliche Weise arbeiten oder fungieren, können die gleichen Komponenten umfassen und können mit anderen Entitäten wie jene, die an anderer Stelle hierin beschrieben sind, verknüpft sein, sind jedoch nicht darauf beschränkt. 18A-18B veranschaulichen eine Übersicht über die Thread-Ausführungslogik 1800, die für eine Hardwarelogik repräsentativ ist, die mit jedem Unterkern 1521A-1521F von 15B veranschaulicht ist. 18A ist repräsentativ für eine Ausführungseinheit innerhalb eines Allzweck-Grafikprozessors, während 18B für eine Ausführungseinheit repräsentativ ist, die in einem Berechnungsbeschleuniger verwendet werden kann.
  • Wie in 18A veranschaulicht, kann die Thread-Ausführungslogik 1800 einen Shader-Prozessor 1802, einen Thread-Dispatcher 1804, einen Anweisungscache 1806, ein skalierbares Ausführungseinheitenarray einschließlich mehrerer Ausführungseinheiten 1808A - 1808N, einen Sampler 1810, einen gemeinsam genutzten lokalen Speicher 1811, einen Datencache 1812 und einen Datenport 1814 beinhalten. Optional kann das skalierbare Ausführungseinheitenarray dynamisch skalieren, indem eine oder mehrere Ausführungseinheiten (z. B. eine beliebige der Ausführungseinheiten 1808A, 1808B, 1808C, 1808D bis 1808N-1 und 1808N) basierend auf den Rechenanforderungen einer Arbeitslast aktiviert oder deaktiviert werden. Die enthaltenen Komponenten können über ein Interconnect-Fabric, das mit jeder der Komponenten verknüpft ist, miteinander verbunden sein. Die Thread-Ausführungslogik 1800 kann eine oder mehrere Verbindungen zum Speicher, wie zum Beispiel dem Systemspeicher oder Cachespeicher, über einen oder mehrere von Anweisungscache 1806, Datenport 1814, Sampler 1810 und Ausführungseinheiten 1808A - 1808N beinhalten. Jede Ausführungseinheit (z. B. 1808A) kann eine selbständige programmierbare Allzweckrecheneinheit sein, die dazu in der Lage ist, mehrere simultane Hardware-Threads auszuführen, während sie mehrere Datenelemente parallel für jeden Thread verarbeitet. Bei verschiedenen Ausführungsformen kann das Array aus Ausführungseinheiten 1808A-1808N skalierbar sein, sodass es eine beliebige Anzahl einzelner Ausführungseinheiten enthält.
  • Die Ausführungseinheiten 1808A-1808N können hauptsächlich zum Ausführen von Shader-Programmen verwendet werden. Ein Shader-Prozessor 1802 kann die verschiedenen Shader-Programme verarbeiten und Ausführungs-Threads, die mit den Shader-Programmen assoziiert sind, über einen Thread-Dispatcher 1804 versenden. Der Thread-Dispatcher kann Logik beinhalten, um Thread-Initiierungsanforderungen von den Grafik- und Medien-Pipelines zu vermitteln und die angeforderten Threads auf einer oder mehreren Ausführungseinheiten 1808A-1808N zu instanziieren. Zum Beispiel kann eine Geometrie-Pipeline Vertex-, Tessellations- oder Geometrie-Shaders an die Thread-Ausführungslogik zur Verarbeitung versenden. Optional kann der Thread-Dispatcher 1804 auch Laufzeit-Thread-Spawning-Anforderungen von den ausführenden Shader-Programmen verarbeiten.
  • Die Ausführungseinheiten 1808A-1808N können einen Anweisungssatz unterstützen, der native Unterstützung für viele Standard-3D-Grafik-Shader-Anweisungen beinhaltet, sodass Shader-Programme aus Grafikbibliotheken (z. B. Direct 3D und OpenGL) mit einer minimalen Übersetzung ausgeführt werden. Die Ausführungseinheiten unterstützen Vertex- und Geometrieverarbeitung (z. B. Vertex-Programme, Geometrieprogramme, Vertex-Shader), Pixelverarbeitung (z. B. Pixel-Shader, Fragment-Shader) und Allzweckverarbeitung (z. B. Berechnungs- und Medien-Shader). Jede der Ausführungseinheiten 1808A-1808N ist zu einer SIMD-Ausführung (SIMD: Single Instruction Multiple Data - einzelne Anweisung, mehrere Daten) fähig und eine Multithread-Operation ermöglicht eine effiziente Ausführungsumgebung angesichts von Speicherzugriffen mit höherer Latenz. Jeder Hardware-Thread innerhalb jeder Ausführungseinheit weist eine dedizierte Registerdatei mit hoher Bandbreite und einen assoziierten unabhängigen Thread-Zustand auf. Die Ausführung ist eine Mehrfach-Erteilung pro Takt an Pipelines mit Gleitkomma-Operationen mit ganzzahliger, einfacher und doppelter Genauigkeit, SIMD-Verzweigungskapazität, logischen Operationen, transzendenten Operationen und anderen sonstigen Operationen. Während auf Daten aus dem Speicher oder einer der gemeinsam genutzten Funktionen gewartet wird, bewirkt die Abhängigkeitslogik innerhalb der Ausführungseinheiten 1808A-1808N, dass ein wartender Thread in den Ruhezustand geht, bis die angeforderten Daten zurückgegeben worden sind. Während der wartende Thread im Ruhezustand ist, können sich Hardwareressourcen der Verarbeitung der anderen Threads widmen. Zum Beispiel kann während einer Verzögerung, die mit einer Vertex-Shader-Operation assoziiert ist, eine Ausführungseinheit Operationen für einen Pixel-Shader, Fragment-Shader oder eine andere Art von Shader-Programm durchführen, einschließlich eines anderen Vertex-Shaders, wie etwa des in 21 veranschaulichten Vertex-Shaders 2107. Verschiedene Ausführungsformen können für die Verwendung einer Ausführung unter Verwendung von SIMT (Single Instruction Multiple Thread) als Alternative zur Verwendung von SIMD oder zusätzlich zur Verwendung von SIMD gelten. Eine Bezugnahme auf einen SIMD-Kern oder eine SIMD-Operation kann auch für SIMT gelten oder für SIMD in Kombination mit SIMT gelten.
  • Jede Ausführungseinheit in den Ausführungseinheiten 1808A - 1808N arbeitet an Arrays von Datenelementen. Die Anzahl der Datenelemente ist die „Ausführungsgröße“ oder die Anzahl der Kanäle für die Anweisung. Ein Ausführungskanal ist eine logische Ausführungseinheit für den Datenelementzugriff, die Maskierung und die Ablaufsteuerung innerhalb von Anweisungen. Die Anzahl der Kanäle kann unabhängig von der Anzahl der physischen arithmetischen Logikeinheiten (ALUs), Gleitkommaeinheiten (FPUs) oder anderen Logikeinheiten (z. B. Tensorkerne, Strahlverfolgungskerne usw.) für einen bestimmten Grafikprozessor sein. Außerdem können die Ausführungseinheiten 1808A - 1808N Ganzzahl- und Gleitkomma-Datentypen unterstützen.
  • Der Ausführungseinheit-Anweisungssatz beinhaltet SIMD-Anweisungen. Die verschiedenen Datenelemente können als ein gepackter Datentyp in einem Register gespeichert werden und die Ausführungseinheit wird die verschiedenen Elemente basierend auf der Datengröße der Elemente verarbeiten. Wenn zum Beispiel mit einem 256 Bit breiten Vektor gearbeitet wird, werden die 256 Bits des Vektors in einem Register gespeichert, wobei die Ausführungseinheit am Vektor als vier separate gepackte 184-Bit-Datenelemente (Datenelemente in Vierfachwort(QW)-Größe), acht separate gepackte 32-Bit-Datenelemente (Datenelemente in Doppelwort(DW)-Größe), sechzehn separate gepackte 16-Bit-Datenelemente (Datenelemente in Wort(W)-Größe) oder zweiunddreißig separate gepackte 8-Bit-Datenelemente (Datenelemente in Byte(B)-Größe) arbeitet. Es sind jedoch unterschiedliche Vektorbreiten und Registergrößen möglich.
  • Optional können eine oder mehrere Ausführungseinheiten zu einer vereinigten Ausführungseinheit 1809A-1809N mit einer Thread-Steuerlogik (1807A-1807N) kombiniert werden, die den vereinigten AEs gemein ist. Mehrere AEs können zu einer AE-Gruppe vereinigt werden. Jede AE in der vereinigten AE-Gruppe kann derart konfiguriert sein, dass sie einen separaten SIMD-Hardware-Thread ausführt. Die Anzahl der AEs in einer vereinigten AE-Gruppe kann je nach Ausführungsformen variieren. Außerdem können verschiedene SIMD-Breiten pro AE durchgeführt werden, einschließlich, jedoch nicht beschränkt auf, SIMD8, SIMD16 und SIMD32. Jede vereinigte Grafikausführungseinheit 1809A-1809N beinhaltet mindestens zwei Ausführungseinheiten. Zum Beispiel beinhaltet die vereinigte Ausführungseinheit 1809A eine erste AE 1808A, eine zweite AE 1808B und eine Thread-Steuerlogik 1807A, die der ersten AE 1808A und der zweiten AE 1808B gemein ist. Die Thread-Steuerlogik 1807A steuert Threads, die auf der vereinigten Grafikausführungseinheit 1809A ausgeführt werden, wodurch jeder AE innerhalb der vereinigten Ausführungseinheiten 1809A-1809N ermöglicht wird, unter Verwendung eines gemeinsamen Anweisungszeigerregisters ausgeführt zu werden.
  • Ein oder mehrere interne Anweisungscaches (z. B. 1806) sind in der Thread-Ausführungslogik 1800 enthalten, um Thread-Anweisungen für die Ausführungseinheiten zu cachen. Ein oder mehrere Datencaches (z. B. 1812) können in der Thread-Ausführungslogik 1800 enthalten 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 gemeinsam genutzten lokalen Speicher 1811 speichern. Ein Sampler 1810 kann enthalten sein, um ein Textur-Sampling für 3D-Operationen und ein Medien-Sampling für Medienoperationen bereitzustellen. Der Sampler 2210 kann eine spezielle Textur- oder Medien-Sampling-Funktionalität beinhalten, um Textur- oder Mediendaten während des Sampling-Prozesses zu verarbeiten, bevor die gesampelten Daten einer Ausführungseinheit bereitgestellt werden.
  • Während der Ausführung senden die Grafik- und Medien-Pipelines Thread-Initiierungsanforderungen an die Thread-Ausführungslogik 1800 über die Thread-Spawning- und -Dispatch-Logik. Sobald eine Gruppe geometrischer Objekte verarbeitet und zu Pixeldaten rasterisiert wurde, wird Pixelprozessorlogik (z. B. Pixel-Shader-Logik, Fragment-Shader-Logik usw.) innerhalb des Shader-Prozessors 1802 aufgerufen, um Ausgabeinformationen weiter zu berechnen und zu bewirken, dass Ergebnisse auf Ausgabeoberflächen (z. B. Farbpuffer, Tiefenpuffer, Schablonenpuffer usw.) geschrieben werden. Ein Pixel-Shader oder Fragment-Shader kann die Werte der verschiedenen Vertex-Attribute berechnen, die über das rasterisierte Objekt hinweg interpoliert werden sollen. Die Pixelprozessorlogik innerhalb des Shader-Prozessors 1802 kann dann ein von einer Anwendungsprogrammierschnittstelle (API) geliefertes Pixel- oder Fragment-Shader-Programm ausführen. Um das Shader-Programm auszuführen, versendet der Shader-Prozessor 1802 Threads über den Thread-Dispatcher 1804 an eine Ausführungseinheit (z. B. 1808A). Der Shader-Prozessor 1802 kann eine Textur-Sampling-Logik in dem Sampler 1810 verwenden, um auf Texturdaten in im Speicher gespeicherten Texturabbildungen zuzugreifen. Arithmetische Operationen an den Texturdaten und den Eingabegeometriedaten berechnen Pixelfarbdaten für jedes geometrische Fragment oder verwerfen ein oder mehrere Pixel von der weiteren Verarbeitung.
  • Außerdem kann der Datenport 1814 einen Speicherzugriffsmechanismus für die Thread-Ausführungslogik 1800 bereitstellen, um verarbeitete Daten an den Speicher zur weiteren Verarbeitung auf einer Grafikprozessorausgabe-Pipeline auszugeben. Der Datenport 1814 kann einen oder mehrere Cachespeicher (z. B. den Datencache 1812) beinhalten oder damit gekoppelt sein, um Daten für den Speicherzugriff über den Datenport 1814 zu cachen.
  • Optional kann die Ausführungslogik 1800 auch einen Strahlverfolger 1805 beinhalten, der eine Strahlverfolgungsbeschleunigungsfunktionalität bereitstellen kann. Der Strahlverfolger 1805 kann einen Strahlverfolgungs-Anweisungssatz unterstützen, der Anweisungen/Funktionen für die Strahlerzeugung enthält. Der Strahlverfolgungs-Anweisungssatz kann dem Strahlverfolgungs-Anweisungssatz, der von den Strahlverfolgungskernen 372 in 3C unterstützt wird, ähneln oder von diesem verschieden sein.
  • 18B veranschaulicht beispielhafte interne Einzelheiten einer Ausführungseinheit 1808. Eine Grafikausführungseinheit 1808 kann eine Anweisungsabrufeinheit 1837, ein Allgemeinregisterdatei-Array (GRF) 1824, ein Architekturregisterdatei-Array (ARF) 1826, einen Thread-Arbiter 1822, eine Sendeeinheit 1830, eine Verzweigungseinheit 1832, einen Satz von SIMD-Gleitkommaeinheiten (FPUs) 1834 und optional einen Satz von dedizierten ganzzahligen SIMD-ALUs 1835 beinhalten. Das GRF 1824 und das ARF 1826 beinhalten den Satz von Allgemeinregisterdateien und Architekturregisterdateien, die mit jedem simultanen Hardware-Thread assoziiert sind, der in der Grafikausführungseinheit 1808 aktiv sein kann. Der Architekturzustand pro Thread kann in dem ARF 1826 beibehalten werden, während Daten, die während der Thread-Ausführung verwendet werden, in dem GRF 1824 gespeichert werden. Der Ausführungszustand jedes Threads, einschließlich der Anweisungszeiger für jeden Thread, kann in Thread-spezifischen Registern im ARF 1826 gehalten werden.
  • Die Grafikausführungseinheit 1808 kann eine Architektur aufweisen, die eine Kombination von simultanem Multi-Threading (SMT) und feinkörnigem verschachteltem Multi-Threading (IMT) ist. Die Architektur kann eine modulare Konfiguration aufweisen, die zur Gestaltungszeit basierend auf einer Zielanzahl von simultanen Threads und einer Anzahl von Registern pro Ausführungseinheit fein abgestimmt werden kann, wobei Ressourcen der Ausführungseinheit über die Logik aufgeteilt werden, die zum Ausführen mehrerer simultaner Threads verwendet wird. Die Anzahl von logischen Threads, die durch die Grafikausführungseinheit 1808 ausgeführt werden können, ist nicht auf die Anzahl von Hardware-Threads beschränkt, und jedem Hardware-Thread können mehrere logische Threads zugewiesen werden.
  • Optional kann die Grafikausführungseinheit 1808 mehrere Anweisungen gemeinsam ausgeben, die jeweils unterschiedliche Anweisungen sein können. Der Thread-Arbiter 1822 des Grafikausführungseinheit-Threads 1808 kann die Anweisungen an entweder die Sendeeinheit 1830, die Verzweigungseinheit 1832 oder die SIMD-FPU(s) 1834 zur Ausführung versenden. Jeder Ausführungs-Thread kann auf 128 Allzweckregister innerhalb des GRF 1824 zugreifen, wobei jedes Register 32 Byte speichern kann, die als ein SIMD-8-Element-Vektor von 32-Bit-Datenelementen zugänglich sind. Jeder Ausführungseinheit-Thread kann Zugriff auf 4 kByte innerhalb des GRF 1824 haben, obwohl die Ausführungsformen nicht darauf beschränkt sind und mehr oder weniger Registerressourcen in anderen Ausführungsformen bereitgestellt werden können. Die Grafikausführungseinheit 1808 kann in sieben Hardware-Threads partitioniert sein, die unabhängig Rechenoperationen ausführen können, obwohl die Anzahl von Threads pro Ausführungseinheit auch gemäß Ausführungsformen variieren kann, zum Beispiel können bis zu 16 Hardware-Threads unterstützt werden. In einer beispielhaften Ausführungsform, in der sieben Threads auf 4 kByte zugreifen können, kann das GRF 1824 insgesamt 28 kByte speichern. In einer anderen beispielhaften Ausführungsform, bei der 16 Threads auf 4 kByte zugreifen können, kann das GRF 1824 insgesamt 64 kByte speichern. Die Anzahl der Threads pro Ausführungseinheit ist jedoch nicht auf diese Beispiele beschränkt und kann größer oder kleiner als die angegebenen Zahlen sein. Flexible Adressierungsmodi können ermöglichen, dass Register zusammen adressiert werden, um effektiv breitere Register zu bilden oder um streifenförmige rechteckige Blockdatenstrukturen zu repräsentieren.
  • Zusätzlich oder alternativ dazu können Speicheroperationen, Sampler-Operationen und andere Systemkommunikationen mit längerer Latenz über „send“ (Senden)-Anweisungen versendet werden, die durch die Nachrichtenweiterleitungssendeeinheit 1830 ausgeführt werden. Verzweigungsanweisungen können an eine dedizierte Verzweigungseinheit 1832 versendet werden, um eine SIMD-Divergenz und letztliche Konvergenz zu ermöglichen.
  • Die Grafikausführungseinheit 1808 kann eine oder mehrere SIMD-Gleitkommaeinheiten (FPU(s)) 1834 zum Durchführen von Gleitkommaoperationen beinhalten. Die FPU(s) 1834 können auch Ganzzahlberechnungen unterstützen. In einigen Fällen können die FPU(s) 1834 bis zu M Anzahl von 32-Bit Gleitkomma- (oder Ganzzahl-) Operationen SIMDausführen, oder bis zu 2 M 16-Bit Ganzzahl- oder 16-Bit-Gleitkommaoperationen SIMDausführen. Optional stellt mindestens eine der FPUs erweiterte mathematische Fähigkeiten bereit, um transzendentale mathematische Funktionen mit hohem Durchsatz und 184-Bit-Gleitkommazahl mit doppelter Präzision zu unterstützen. Ein Satz von 8-Bit-Ganzzahl-SIMD-ALUs 1835 kann auch vorhanden sein und kann speziell optimiert werden, um Operationen durchzuführen, die mit Maschinenlernberechnungen assoziiert sind.
  • Optional können Arrays von mehreren Instanzen der Grafikausführungseinheit 1808 in einer Grafikunterkerngruppierung (z. B. einem Sub-Slice) instanziiert werden. Für die Skalierbarkeit können Produktarchitekten die exakte Anzahl an Ausführungseinheiten pro Unterkerngruppierung auswählen. Die Ausführungseinheit 1808 kann Anweisungen über eine Vielzahl von Ausführungskanälen ausführen. Außerdem kann jeder auf der Grafikausführungseinheit 1808 ausgeführte Thread auf einem anderen Kanal ausgeführt werden.
  • 19 veranschaulicht eine weitere beispielhafte Ausführungseinheit 1900. Die Elemente von 19 mit den gleichen oder ähnlichen Namen wie die Elemente einer beliebigen anderen Figur hierin beschreiben die gleichen Elemente wie in den anderen Figuren, können auf ähnliche Weise arbeiten oder fungieren, können die gleichen Komponenten umfassen und können mit anderen Entitäten wie jene, die an anderer Stelle hierin beschrieben sind, verknüpft sein, sind jedoch nicht darauf beschränkt. Die Ausführungseinheit 1900 kann eine rechenoptimierte Ausführungseinheit zur Verwendung beispielsweise in einer Berechnungs-Engine-Kachel 1640A - 1640D wie in 16C sein, ist jedoch nicht darauf beschränkt. Die Ausführungseinheit 1900 kann auch in einer Grafik-Engine-Kachel 1610A-1610D wie in 16B verwendet werden. Die Ausführungseinheit 1900 kann eine Thread-Steuereinheit 1901, eine Thread-Zustandseinheit 1902, eine Anweisungsabruf-/-vorabrufeinheit 1903 und eine Anweisungsdecodiereinheit 1904 beinhalten. Die Ausführungseinheit 1900 kann zusätzlich eine Registerdatei 1906 beinhalten, die Register speichert, die Hardware-Threads innerhalb der Ausführungseinheit zugewiesen werden können. Die Ausführungseinheit 1900 kann zusätzlich eine Sendeeinheit 1907 und eine Verzweigungseinheit 1908 beinhalten. Die Sendeeinheit 1907 und die Verzweigungseinheit 1908 können ähnlich wie die Sendeeinheit 1830 und eine Verzweigungseinheit 1832 der Grafikausführungseinheit 1808 von 18B arbeiten.
  • Die Ausführungseinheit 1900 kann auch eine Berechnungseinheit 1910 beinhalten, die mehrere unterschiedliche Arten von Funktionseinheiten enthält. Die Berechnungseinheit 1910 kann auch eine ALU-Einheit 1911 beinhalten, die ein Array von arithmetischen Logikeinheiten enthält. Die ALU-Einheit 1911 kann dazu konfiguriert sein, 64-Bit-, 32-Bit- und 16-Bit-Ganzzahl- und Gleitkomma-Operationen durchzuführen. Ganzzahl- und Gleitkomma-Operationen können gleichzeitig durchgeführt werden. Die Berechnungseinheit 1910 kann auch ein systolisches Array 1912 und eine Mathe-Einheit 1913 beinhalten. Das systolische Array 1912 enthält ein Wbreites und D tiefes Netzwerk von Datenverarbeitungseinheiten, die verwendet werden können, um Vektor- oder andere datenparallele Operationen auf systolische Weise durchzuführen. Das systolische Array 1912 kann dazu konfiguriert sein, Matrixoperationen durchzuführen, wie etwa Matrixskalarproduktoperationen. Das systolische Array 1912 kann 16-Bit-Gleitkommaoperationen sowie 8-Bit- und 4-Bit-Ganzzahloperationen unterstützen. Das systolische Array 1912 kann dazu konfiguriert sein, Maschinenlernoperationen zu beschleunigen. Das systolische Array 1912 kann mit Unterstützung für bfloat16, einem 16-Bit-Gleitkommaformat, konfiguriert werden. Eine Mathe-Einheit 1913 kann enthalten sein, um eine bestimmte Teilmenge mathematischer Operationen auf effiziente Weise und mit geringerer Leistung als die ALU-Einheit 1911 durchzuführen. Die Mathe-Einheit 1913 kann eine Mathe-Logik beinhalten, die in einer Logik mit gemeinsam genutzter Funktion einer Grafikverarbeitungs-Engine gefunden wird, die von anderen beschriebenen Ausführungsformen bereitgestellt wird, z. B. die Mathe-Logik 1722 der Logik 1720 mit gemeinsam genutzter Funktion von 17. Die Mathe-Einheit 1913 kann dazu konfiguriert sein, 32-Bit- und 64-Bit-Gleitkommaoperationen durchzuführen.
  • Die Thread-Steuereinheit 1901 enthält Logik zum Steuern der Ausführung von Threads innerhalb der Ausführungseinheit. Die Thread-Steuereinheit 1901 kann Thread-Arbitrierungslogik beinhalten, um die Ausführung von Threads innerhalb der Ausführungseinheit 1900 zu starten, zu stoppen und zu präemptieren. Die Thread-Zustandseinheit 1902 kann verwendet werden, um den Thread-Zustand für Threads zu speichern, die zur Ausführung auf der Ausführungseinheit 1900 zugewiesen sind. Das Speichern des Thread-Zustands in der Ausführungseinheit 1900 ermöglicht die schnelle Präemption von Threads, wenn diese Threads blockiert oder inaktiv werden. Die Anweisungsabruf-/-vorabrufeinheit 1903 kann Anweisungen aus einem Anweisungscache einer Ausführungslogik höherer Ebene (z. B. Anweisungscache 1806 wie in 18A) abrufen. Die Anweisungssabruf-/-vorabrufeinheit 1903 kann auch Vorabruf-Anforderungen für in den Anweisungscache zu ladende Anweisungen basierend auf einer Analyse aktuell ausgeführter Threads ausgeben. Die Anweisungsdecodiereinheit 1904 kann verwendet werden, um von den Berechnungseinheiten auszuführende Anweisungen zu decodieren. Die Anweisungsdecodiereinheit 1904 kann als ein sekundärer Decodierer verwendet werden, um komplexe Anweisungen in konstituierende Mikrooperationen zu decodieren.
  • Die Ausführungseinheit 1900 beinhaltet zusätzlich eine Registerdatei 1906, die durch Hardware-Threads verwendet werden kann, die auf der Ausführungseinheit 1900 ausgeführt werden. Register in der Registerdatei 1906 können über die Logik aufgeteilt werden, die verwendet wird, um mehrere simultane Threads innerhalb der Berechnungseinheit 1910 der Ausführungseinheit 1900 auszuführen. Die Anzahl von logischen Threads, die durch die Grafikausführungseinheit 1900 ausgeführt werden können, ist nicht auf die Anzahl von Hardware-Threads beschränkt, und jedem Hardware-Thread können mehrere logische Threads zugewiesen werden. Die Größe der Registerdatei 1906 kann zwischen Ausführungsformen basierend auf der Anzahl unterstützter Hardware-Threads variieren. Eine Registerumbenennung kann verwendet werden, um Registern Hardware-Threads dynamisch zuzuordnen.
  • 20 ist ein Blockdiagramm, das ein Grafikprozessor-Anweisungsformat 2000 veranschaulicht. Die Grafikprozessorausführungseinheiten unterstützen einen Anweisungssatz mit Anweisungen in mehreren Formaten. Die Kästchen mit durchgezogenen Linien veranschaulichen die Komponenten, die allgemein in einer Ausführungseinheitenanweisung enthalten sind, während die gestrichelten Linien Komponenten enthalten, die optional sind oder die nur in einer Teilmenge der Anweisungen enthalten sind. Die beschriebenen und veranschaulichten Anweisungsformate 2000 sind Makroanweisungen, da sie Anweisungen sind, die der Ausführungseinheit zugeführt werden, im Gegensatz zu Mikrooperationen, die sich aus der Anweisungsdecodierung ergeben, sobald die Anweisung verarbeitet ist.
  • Die hierin beschriebenen Grafikprozessorausführungseinheiten können Anweisungen in einem 128-Bit-Anweisungsformat 2010 nativ unterstützen. Ein verdichtetes 64-Bit-Anweisungsformat 2030 ist für manche Anweisungen basierend auf der ausgewählten Anweisung, den Anweisungsoptionen und der Anzahl der Operanden verfügbar. Das native 128-Bit-Anweisungsformat 2010 bietet Zugriff auf alle Anweisungsoptionen, während manche Optionen und Operationen im 64-Bit-Format 2030 beschränkt sind. Die nativen Anweisungen, die im 64-Bit-Format 2030 verfügbar sind, variieren je nach Ausführungsform. Die Anweisung wird teilweise unter Verwendung eines Satzes von Indexwerten in einem Indexfeld 2013 verdichtet. Die Ausführungseinheit-Hardware referenziert einen Satz von Verdichtungstabellen basierend auf den Indexwerten und verwendet die Verdichtungstabellenausgaben, um eine native Anweisung im 128-Bit-Anweisungsformat 2010 zu rekonstruieren. Andere Anweisungsgrößen und -formate können verwendet werden.
  • Für jedes Format definiert der Anweisungs-Opcode 2012 die Operation, die die Ausführungseinheit durchführen soll. Die Ausführungseinheiten führen jede Anweisung parallel über die mehreren Datenelemente jedes Operanden aus. Zum Beispiel führt die Ausführungseinheit als Reaktion auf eine Addieranweisung eine simultane Addieroperation über jeden Farbkanal aus, der ein Texturelement oder Bildelement repräsentiert. Standardmäßig führt die Ausführungseinheit jede Anweisung über alle Datenkanäle der Operanden aus. Das Anweisungsteuerungsfeld 2014 kann die Steuerung bestimmter Ausführungsoptionen ermöglichen, wie die Kanalauswahl (z. B. Prädikation) und Datenkanalreihenfolge (z. B. Swizzle). Für Anweisungen im 128-Bit-Anweisungsformat 2010 begrenzt ein Ausführungsgröße-Feld 2016 die Anzahl an Datenkanälen, die parallel ausgeführt werden. Ein Ausführungsgröße-Feld 2016 ist möglicherweise nicht zur Verwendung in dem kompakten 64-Bit-Anweisungsformat 2030 verfügbar.
  • Einige Ausführungseinheitsanweisungen haben bis zu drei Operanden einschließlich zwei Quelloperanden, src0 2020, src1 2022, und ein Ziel 2018. Die Ausführungseinheiten können duale Zielanweisungen unterstützen, wobei eines der Ziele impliziert ist. Datenmanipulationsanweisungen können einen dritten Quelloperanden aufweisen (z. B. SRC2 2024), wobei der Anweisungs-Opcode 2012 die Anzahl der Quelloperanden bestimmt. Der letzte Quelloperand einer Anweisung kann ein Immediate-Wert (z. B. fest codierter Wert) sein, der mit der Anweisung übergeben wird.
  • Das 128-Bit-Anweisungsformat 2010 kann ein Zugriffs-/Adressmodus-Feld 2026 beinhalten, das zum Beispiel angibt, ob der direkte Registeradressierungsmodus oder der indirekte Registeradressierungsmodus verwendet wird. Wenn der direkte Registeradressierungsmodus verwendet wird, wird die Registeradresse eines oder mehrerer Operanden direkt durch Bits in der Anweisung bereitgestellt.
  • Das 128-Bit-Anweisungsformat 2010 kann auch ein Zugriffs-/Adressmodus-Feld 2026 beinhalten, das einen Adressmodus und/oder einen Zugriffsmodus für die Anweisung spezifiziert. Der Zugriffsmodus kann verwendet werden, um eine Datenzugriffsausrichtung für die Anweisung zu definieren. Zugriffsmodi einschließlich eines 16-Byte-ausgerichteten Zugriffsmodus und eines 1-Byte-ausgerichteten Zugriffsmodus können unterstützen werden, wobei die Byteausrichtung des Zugriffsmodus die Zugriffsausrichtung der Anweisungsoperanden bestimmt. Zum Beispiel kann die Anweisung, wenn sie sich in einem ersten Modus befindet, eine Byte-ausgerichtete Adressierung für Quell- und Zieloperanden verwenden, und, wenn sie sich in einem zweiten Modus befindet, kann die Anweisung eine 16-Byte-ausgerichtete Adressierung für alle Quell- und Zieloperanden verwenden.
  • Der Adressmodusabschnitt des Zugriffs-/Adressmodus-Feldes 2026 kann bestimmen, ob die Anweisung eine direkte oder eine indirekte Adressierung verwenden soll. Wenn der direkte Registeradressierungsmodus verwendet wird, stellen die Bits in der Anweisung direkt die Registeradresse eines oder mehrerer Operanden bereit. Wenn der indirekte Registeradressierungsmodus verwendet wird, kann die Registeradresse eines oder mehrerer Operanden basierend auf einem Adressregisterwert und einem unmittelbaren Adressfeld in der Anweisung berechnet werden.
  • Anweisungen können basierend auf Bitfeldern des Opcodes 2012 gruppiert werden, um die Opcode-Decodierung 2040 zu vereinfachen. Bei einem 8-Bit-Opcode ermöglichen die Bits 4, 5 und 6 der Ausführungseinheit, den Opcode-Typ zu bestimmen. Die gezeigte präzise Opcode-Gruppierung ist lediglich ein Beispiel. Eine Bewegung-und-Logik-Opcode-Gruppe 2042 kann Datenbewegungs- und Logikanweisungen (z. B. move (mov) (Bewegen), compare (cmp) (Vergleichen)) beinhalten. Die Bewegung-und-Logik-Gruppe 2042 kann die fünf höchstwertigen Bits (MSB) gemeinsam nutzen, wobei move(mov)-Anweisungen die Form 0000xxxxb haben und Logikanweisungen die Form 0001xxxxb haben. Eine Ablaufsteuerungsanweisungsgruppe 2044 (z. B. call (Aufrufen), jump (jmp) (Springen)) beinhaltet Anweisungen in Form von 0010xxxxb (z. B. 0x20). Eine gemischte Anweisungsgruppe 2046 beinhaltet eine Mischung von Anweisungen einschließlich Synchronisationsanweisungen (z. B. wait (Warten), send (Senden)) in der Form 001 Ixxxxb (z. B. 0x30). Eine Parallel-Mathe-Anweisungsgruppe 2048 beinhaltet komponentenweise arithmetische Anweisungen (z. B. add (Addieren), multiply (mul) (Multiplizieren)) in der Form 0100xxxxb (z. B. 0x40). Die Parallel-Mathe-Gruppe 2048 führt die arithmetischen Operationen parallel über Datenkanäle aus. Die Vektor-Mathe-Gruppe 2050 beinhaltet arithmetische Befehle (z. B. dp4) in Form von 0101xxxxb (z. B. 0x50). Die Vektor-Mathe-Gruppe führt Arithmetik wie z. B. Skalarproduktberechnungen an Vektoroperanden aus. Die veranschaulichte Opcode-Decodierung 2040 kann in einer Ausführungsform verwendet werden, um zu bestimmen, welcher Abschnitt einer Ausführungseinheit verwendet wird, um eine decodierte Anweisung auszuführen. Zum Beispiel können einige Anweisungen als systolische Anweisungen bezeichnet werden, die durch ein systolisches Array ausgeführt werden. Andere Anweisungen, wie etwa Strahlverfolgungsanweisungen (nicht gezeigt) können zu einem Strahlverfolgungskern oder einer Strahlverfolgungslogik innerhalb eines Slice oder einer Partition der Ausführungslogik geleitet werden.
  • Grafik-Pipeline
  • 21 ist ein Blockdiagramm eines Grafikprozessors 2100 gemäß einer anderen Ausführungsform. Die Elemente von 21 mit den gleichen oder ähnlichen Namen wie die Elemente einer beliebigen anderen Figur hierin beschreiben die gleichen Elemente wie in den anderen Figuren, können auf ähnliche Weise arbeiten oder fungieren, können die gleichen Komponenten umfassen und können mit anderen Entitäten wie jene, die an anderer Stelle hierin beschrieben sind, verknüpft sein, sind jedoch nicht darauf beschränkt.
  • Der Grafikprozessor 2100 kann verschiedene Arten von Grafikverarbeitungs-Pipelines beinhalten, wie etwa eine Geometrie-Pipeline 2120, eine Medien-Pipeline 2130, eine Anzeige-Engine 2140, eine Thread-Ausführungslogik 2150 und eine Rendering-Ausgabe-Pipeline 2170. Der Grafikprozessor 2100 kann ein Grafikprozessor in einem Mehrkern-Verarbeitungssystem sein, das einen oder mehrere Allzweck-Verarbeitungskerne beinhaltet. Der Grafikprozessor kann durch Registerschreibvorgänge in ein oder mehrere Steuerregister (nicht gezeigt) oder über Befehle gesteuert werden, die über ein Ring-Interconnect 2102 an den Grafikprozessor 2100 ausgegeben werden. Das Ring-Interconnect 2102 kann den Grafikprozessor 2100 mit anderen Verarbeitungskomponenten koppeln, wie etwa anderen Grafikprozessoren oder Allzweckprozessoren. Befehle vom Ring-Interconnect 2102 werden von einem Befehls-Streamer 2103 interpretiert, der Anweisungen an einzelne Komponenten der Geometrie-Pipeline 2120 oder der Medien-Pipeline 2130 liefert.
  • Der Befehls-Streamer 2103 kann die Operation eines Vertex-Abrufers 2105 leiten, der Vertex-Daten aus einem Speicher liest und Vertex-Verarbeitungsbefehle ausführt, die durch den Befehls-Streamer 2403 bereitgestellt werden. Der Vertex-Abrufer 2105 kann Vertex-Daten an einen Vertex-Shader 2107 liefern, der eine Koordinatenraumtransformation und Beleuchtungsoperationen für jeden Vertex durchführt. Der Vertex-Abrufer 2105 und der Vertex-Shader 2107 können Vertex-Verarbeitungsanweisungen ausführen, indem sie Ausführungs-Threads über einen Thread-Dispatcher 2131 an die Ausführungseinheiten 2152A-2152B versenden.
  • Die Ausführungseinheiten 2152A - 2152B können ein Array von Vektorprozessoren mit einem Anweisungssatz zum Durchführen von Grafik- und Medienoperationen sein. Die Ausführungseinheiten 2152A - 2152B können einen angeschlossenen L1-Cache 2151 aufweisen, der für jedes Array spezifisch ist oder von den Arrays gemeinsam genutzt wird. Der Cache kann als Datencache, als Anweisungscache oder als Einzelcache konfiguriert sein, der derart partitioniert ist, dass er Daten und Anweisungen in verschiedenen Partitionen enthält.
  • Eine Geometrie-Pipeline 2120 kann Tessellationskomponenten beinhalten, um eine hardwarebeschleunigte Tessellation von 3D-Objekten durchzuführen. Ein programmierbarer Hüllen-Shader 2111 kann die Tessellationsoperationen konfigurieren. Ein programmierbarer Domänen-Shader 2117 kann eine Backend-Auswertung der Tessellationsausgabe bereitstellen. Ein Tessellator 2113 kann unter Anleitung des Hüllen-Shaders 2111 arbeiten und eine Spezialzwecklogik zum Erzeugen eines Satzes detaillierter geometrischer Objekte basierend auf einem groben geometrischen Modell enthalten, das als Eingabe in die Geometrie-Pipeline 2120 bereitgestellt wird. Falls keine Tessellation verwendet wird, können zusätzlich Tessellationskomponenten (z. B. Hüllen-Shader 2111, Tessellator 2113 und Domänen-Shader 2117) umgangen werden.
  • Vollständige geometrische Objekte können durch einen Geometrie-Shader 2119 über einen oder mehrere Threads verarbeitet werden, die an die Ausführungseinheiten 2152A-2152B versendet werden, oder sie können direkt zu dem Clipper 2129 weitergehen. Der Geometrie-Shader kann mit ganzen geometrischen Objekten arbeiten, anstatt mit Vertices oder Feldern von Vertices wie in vorherigen Stufen der Grafik-Pipeline. Falls die Tessellation deaktiviert ist, empfängt der Geometrie-Shader 2119 eine Eingabe vom Vertex-Shader 2107. Der Geometrie-Shader 2119 kann durch ein Geometrie-Shader-Programm programmierbar sein, um eine Geometrie-Tessellation durchzuführen, falls die Tessellationseinheiten deaktiviert sind.
  • Vor der Rasterisierung verarbeitet ein Clipper 2129 Vertex-Daten. Der Clipper 2129 kann ein Clipper mit fester Funktion oder ein programmierbarer Clipper mit Clipping- und Geometrie-Shader-Funktionen sein. Eine Rasterisierer-und-Tiefenprüfung-Komponente 2173 in der Rendering-Ausgabe-Pipeline 2170 kann Pixel-Shader versenden, um die geometrischen Objekte in Pro-Pixel-Repräsentationen umzuwandeln. Die Pixel-Shader-Logik kann in der Thread-Ausführungslogik 2150 enthalten sein. Optional kann eine Anwendung die Rasterisierer-und-Tiefenprüfung-Komponente 2173 umgehen und über eine Stream-Out-Einheit 2123 auf nicht rasterisierte Vertex-Daten zugreifen.
  • Der Grafikprozessor 2100 weist einen Interconnect-Bus, ein Interconnect-Fabric oder einen anderen Interconnect-Mechanismus auf, der ein Weitergeben von Daten und Nachrichten zwischen den Hauptkomponenten des Prozessors ermöglicht. Bei manchen Ausführungsformen sind die Ausführungseinheiten 2152A-2152B und die assoziierten Logikeinheiten (z. B. L1-Cache 2151, Sampler 2154, Textur-Cache 2158 usw.) über einen Datenport 2156 miteinander verbunden, um einen Speicherzugriff durchzuführen und mit Rendering-Ausgabe-Pipeline-Komponenten des Prozessors zu kommunizieren. Ein Sampler 2154, die Caches 2151, 2158 und die Ausführungseinheiten 2152A-2152B können jeweils getrennte Speicherzugriffspfade aufweisen. Optional kann der Textur-Cache 2158 auch als ein Sampler-Cache konfiguriert sein.
  • Die Rendering-Ausgabe-Pipeline 2170 kann eine Rasterisierer-und-Tiefenprüfung-Komponente 2173 enthalten, die Vertex-basierte Objekte in eine assoziierte pixelbasierte Repräsentation umwandelt. Die Rasterisierer-Logik kann eine Windower/Maskierer-Einheit aufweisen, um eine Dreiecks- und Linienrasterisierung mit fester Funktion durchzuführen. Ein assoziierter Rendering-Cache 2178 und Tiefencache 2179 sind bei manchen Ausführungsformen ebenfalls verfügbar. Eine Pixeloperationskomponente 2177 führt pixelbasierte Operationen an den Daten aus, wenngleich in einigen Fällen Pixeloperationen, die mit 2D-Operationen assoziiert sind (z. B. Bitblockbildtransfers mit Blending), von der 2D-Engine 2141 ausgeführt oder zur Anzeigezeit von der Anzeigesteuerung 2143 unter Verwendung von Overlay-Anzeigeebenen ersetzt werden. Ein gemeinsam genutzter L3-Cache 2175 kann für alle Grafikkomponenten verfügbar sein, was die gemeinsame Nutzung von Daten ohne die Verwendung von Hauptsystemspeicher ermöglicht.
  • Die Grafikprozessor-Medien-Pipeline 2130 kann eine Medien-Engine 2137 und ein Video-Frontend 2134 beinhalten. Das Video-Frontend 2134 kann Pipeline-Befehle vom Befehls-Streamer 2103 empfangen. Die Medien-Pipeline 2130 kann einen separaten Befehls-Streamer beinhalten. Das Video-Frontend 2134 kann Medienbefehle verarbeiten, bevor der Befehl an die Medien-Engine 2137 gesendet wird. Die Medien-Engine 2137 kann eine Thread-Spawning-Funktionalität beinhalten, um Threads zum Versand an die Thread-Ausführungslogik 2150 über den Thread-Dispatcher 2131 zu spawnen.
  • Der Grafikprozessor 2100 kann eine Anzeige-Engine 2140 beinhalten. Diese Anzeige-Engine 2140 kann sich außerhalb des Prozessors 2100 befinden und kann mit dem Grafikprozessor über das Ring-Interconnect 2102 oder einen anderen Interconnect-Bus oder ein anderes Interconnect-Fabric gekoppelt sein. Die Anzeige-Engine 2140 kann eine 2D-Engine 2141 und eine Anzeigesteuerung 2143 beinhalten. Die Anzeige-Engine 2140 kann eine Speziallogik enthalten, die in der Lage ist, unabhängig von der 3D-Pipeline zu arbeiten. Die Anzeigesteuerung 2143 kann mit einer Anzeigevorrichtung (nicht gezeigt) gekoppelt sein, die eine systemintegrierte Anzeigevorrichtung, wie in einem Laptop-Computer, oder eine externe Anzeigevorrichtung sein kann, die über einen Anzeigevorrichtungsverbindungselement angeschlossen ist.
  • Die Geometrie-Pipeline 2120 und die Medien-Pipeline 2130 können dazu konfigurierbar sein, Operationen basierend auf mehreren Grafik- und Medienprogrammierschnittstellen durchzuführen, und sind für keine Anwendungsprogrammierschnittstelle (API) spezifisch. Eine Treibersoftware für den Grafikprozessor kann API-Aufrufe, die für eine bestimmte Grafik- oder Medienbibliothek spezifisch sind, in Befehle übersetzen, die durch den Grafikprozessor verarbeitet werden können. Unterstützung kann für Open Graphics Library (OpenGL), Open Computing Language (OpenCL) und/oder Vulkan Graphics und Rechen-API bereitgestellt werden, die alle von der Khronos Group sind. Unterstützung kann auch für die Direct3D-Bibliothek von der Microsoft Corporation bereitgestellt werden. Eine Kombination dieser Bibliotheken kann unterstützt werden. Unterstützung kann auch für die Open Source Computer Vision Library (OpenCV) bereitgestellt werden. Eine zukünftige API mit einer kompatiblen 3D-Pipeline wird ebenfalls unterstützt, falls eine Abbildung von der Pipeline der zukünftigen API auf die Pipeline des Grafikprozessors vorgenommen werden kann.
  • Grafik-Pipeline-Programmierung
  • 22A ist ein Blockdiagramm, das ein Grafikprozessor-Befehlsformat 2200 veranschaulicht, das zum Programmieren von Grafikverarbeitungs-Pipelines verwendet wird, wie beispielsweise die hierin in Verbindung mit 16A, 17, 21 beschriebenen Pipelines. 22B ist ein Blockdiagramm, das eine Grafikprozessor-Befehlssequenz 2210 gemäß einer Ausführungsform veranschaulicht. Die durchgezogenen Kästen in 22A veranschaulichen die Komponenten, die im Allgemeinen in einem Grafikbefehl enthalten sind, während die gestrichelten Linien Komponenten enthalten, die optional sind oder die nur in einer Teilmenge der Grafikbefehle enthalten sind. Das beispielhafte Grafikprozessor-Befehlsformat 2200 von 22A enthält Datenfelder, um einen Client 2202, einen Befehlsoperationscode (Opcode) 2204 und Daten 2206 für den Befehl zu identifizieren. Ein Sub-Opcode 2205 und eine Befehlsgröße 2208 sind auch in einigen Befehlen enthalten.
  • Der Client 2202 kann die Client-Einheit der Grafikvorrichtung spezifizieren, die die Befehlsdaten verarbeitet. Ein Grafikprozessor-Befehls-Parser kann das Client-Feld jedes Befehls untersuchen, um die weitere Verarbeitung des Befehls zu konditionieren und die Befehlsdaten an die geeignete Client-Einheit zu leiten. Die Grafikprozessor-Client-Einheiten können eine Speicherschnittstelleneinheit, eine Rendering-Einheit, eine 2D-Einheit, eine 3D-Einheit und eine Medieneinheit beinhalten. Jede Client-Einheit kann eine entsprechende Verarbeitungs-Pipeline aufweisen, die die Befehle verarbeitet. Sobald der Befehl durch die Client-Einheit empfangen wird, liest die Client-Einheit den Opcode 2204 und, falls vorhanden, den Sub-Opcode 2205, um die durchzuführende Operation zu bestimmen. Die Client-Einheit führt den Befehl unter Verwendung von Informationen in dem Datenfeld 2206 aus. Für einige Befehle wird eine explizite Befehlsgröße 2208 erwartet, um die Größe des Befehls anzugeben. Der Befehls-Parser kann die Größe von zumindest einigen der Befehle basierend auf dem Befehls-Opcode automatisch bestimmen. Befehle können über Vielfache eines Doppelwortes ausgerichtet werden. Andere Befehlsformate können ebenfalls verwendet werden.
  • Das Flussdiagramm in 22B veranschaulicht eine beispielhafte Grafikprozessor-Befehlssequenz 2210. Software oder Firmware eines Datenverarbeitungssystems, das einen beispielhaften Grafikprozessor aufweist, kann eine Version der gezeigten Befehlssequenz verwenden, um einen Satz von Grafikoperationen einzurichten, auszuführen und zu beenden. Eine beispielhafte Befehlssequenz ist nur zu beispielhaften Zwecken gezeigt und beschrieben und ist nicht auf diese spezifischen Befehle oder auf diese Befehlssequenz beschränkt. Darüber hinaus können die Befehle als Batch von Befehlen in einer Befehlssequenz ausgegeben werden, sodass der Grafikprozessor die Befehlssequenz zumindest teilweise gleichzeitig verarbeiten wird.
  • Die Grafikprozessor-Befehlssequenz 2210 kann mit einem Pipeline-Flush-Befehl 2212 beginnen, um zu bewirken, dass jede aktive Grafik-Pipeline die aktuell anstehenden Befehle für die Pipeline abschließt. Optional arbeiten die 3D-Pipeline 2222 und die Medien-Pipeline 2224 möglicherweise nicht gleichzeitig. Der Pipeline-Flush wird durchgeführt, um die aktive Grafik-Pipeline zu veranlassen, alle ausstehenden Befehle abzuschließen. Als Reaktion auf einen Pipeline-Flush pausiert der Befehls-Parser für den Grafikprozessor die Befehlsverarbeitung, bis die aktiven Zeichnung-Engines ausstehende Operationen abschließen und die relevanten Lese-Caches ungültig gemacht werden. Optional können beliebige Daten in dem Rendering-Cache, die als „verschmutzt“ markiert sind, in den Speicher geflusht werden.
  • Der Pipeline-Flushing-Befehl 2212 kann zur Pipeline-Synchronisation oder vor dem Versetzen des Grafikprozessors in einen Niederleistungszustand verwendet werden.
  • Ein Pipeline-Auswahlbefehl 2213 kann verwendet werden, wenn eine Befehlssequenz erfordert, dass der Grafikprozessor explizit zwischen Pipelines umschaltet. Ein Pipeline-Auswahlbefehl 2213 wird möglicherweise nur einmal in einem Ausführungskontext vor dem Ausgeben von Pipeline-Befehlen benötigt, es sei denn, der Kontext gibt Befehle für beide Pipelines aus. Ein Pipeline-Flushing-Befehl 2212 kann unmittelbar vor einem Pipeline-Umschalten über den Pipeline-Auswahlbefehl 2213 erforderlich sein.
  • Ein Pipeline-Steuerbefehl 2214 kann eine Grafik-Pipeline für den Betrieb konfigurieren und kann verwendet werden, um die 3D-Pipeline 2222 und die Medien-Pipeline 2224 zu programmieren. Der Pipeline-Steuerbefehl 2214 kann den Pipeline-Zustand für die aktive Pipeline konfigurieren. Der Pipeline-Steuerbefehl 2214 kann für die Pipeline-Synchronisation und zum Löschen von Daten aus einem oder mehreren Cachespeichern innerhalb der aktiven Pipeline verwendet werden, bevor ein Batch von Befehlen verarbeitet wird.
  • Rückgabepufferzustandsbefehle 2216 können verwendet werden, um einen Satz von Rückgabepuffern für die jeweiligen Pipelines zum Schreiben von Daten zu konfigurieren. Manche Pipeline-Operationen erfordern die Zuweisung, Auswahl oder Konfiguration eines oder mehrerer Rückgabepuffer, in die die Operationen Zwischendaten während der Verarbeitung schreiben. Der Grafikprozessor kann auch einen oder mehrere Rückgabepuffer verwenden, um Ausgabedaten zu speichern und eine Cross-Thread-Kommunikation auszuführen. Der Rückgabepufferzustand 2216 kann das Auswählen der Größe und Anzahl von Rückgabepuffern beinhalten, die für einen Satz von Pipeline-Operationen zu verwenden sind.
  • Die übrigen Befehle in der Befehlssequenz unterscheiden sich basierend auf der aktiven Pipeline für Operationen. Basierend auf einer Pipeline-Bestimmung 2220 wird die Befehlssequenz auf die 3D-Pipeline 2222, beginnend mit dem 3D-Pipeline-Zustand 2230, oder auf die Medien-Pipeline 2224, beginnend mit dem Medien-Pipeline-Zustand 2240, zugeschnitten.
  • Die Befehle zum Konfigurieren des 3D-Pipeline-Zustands 2230 beinhalten 3D-Zustandseinstellbefehle für den Vertex-Pufferzustand, den Vertex-Elementzustand, den konstanten Farbzustand, den Tiefenpufferzustand und andere Zustandsvariablen, die zu konfigurieren sind, bevor 3D-Primitivenbefehle verarbeitet werden. Die Werte dieser Befehle werden zumindest teilweise basierend auf der jeweiligen verwendeten 3D-API bestimmt. Die Befehle des 3D-Pipeline-Zustands 2230 können auch in der Lage sein, bestimmte Pipeline-Elemente gezielt zu deaktivieren oder zu umgehen, falls diese Elemente nicht verwendet werden.
  • Ein 3D-Primitivenbefehl 2232 kann verwendet werden, um 3D-Primitive, die von der 3D-Pipeline verarbeitet werden sollen, zu versenden. Befehle und assoziierte Parameter, die über den 3D-Primitivenbefehl 2232 an den Grafikprozessor geleitet werden, werden an die Vertex-Abruffunktion in der Grafik-Pipeline weitergeleitet. Die Vertex-Abruffunktion verwendet die Daten des 3D-Primitivenbefehls 2232, um Vertex-Datenstrukturen zu erzeugen. Die Vertex-Datenstrukturen werden in einem oder mehreren Rückgabepuffern gespeichert. Der 3D-Primitivenbefehl 2232 kann verwendet werden, um Vertex-Operationen an 3D-Primitiven über Vertex-Shader durchzuführen. Um Vertex-Shader zu verarbeiten, versendet die 3D-Pipeline 2222 Shader-Ausführungs-Threads an Grafikprozessorausführungseinheiten.
  • Die 3D-Pipeline 2222 kann über einen Ausführungsbefehl 2234 oder ein Ausführungsereignis ausgelöst werden. Ein Register kann Auslösebefehlsausführungen schreiben. Eine Ausführung kann über einen „go‟- oder „kick‟-Befehl in der Befehlssequenz ausgelöst werden. Die Befehlsausführung kann unter Verwendung eines Pipeline-Synchronisationsbefehls ausgelöst werden, um die Befehlssequenz durch die Grafik-Pipeline zu flushen. Die 3D-Pipeline führt eine Geometrieverarbeitung für die 3D-Primitiven aus. Sobald die Operationen abgeschlossen sind, werden die resultierenden geometrischen Objekte rasterisiert und färbt die Pixel-Engine die resultierenden Pixel. Weitere Befehle zum Steuern des Pixel-Shadings und der Pixel-Backend-Operationen können ebenfalls für diese Operationen enthalten sein.
  • Die Grafikprozessor-Befehlssequenz 2210 kann dem Pfad der Medien-Pipeline 2224 folgen, wenn Medienoperationen durchgeführt werden. Im Allgemeinen hängt die spezielle Verwendung und Art der Programmierung für die Medien-Pipeline 2224 von den durchzuführenden Medien- oder Rechenoperationen ab. Spezifische Mediendecodieroperationen können während der Mediendecodierung auf die Medien-Pipeline ausgelagert werden. Die Medien-Pipeline kann auch umgangen werden und die Mediendecodierung kann vollständig oder teilweise unter Verwendung von Ressourcen durchgeführt werden, die von einem oder mehreren Allzweckverarbeitungskernen bereitgestellt werden. Die Medien-Pipeline kann auch Elemente für Operationen einer Allzweck-Grafikprozessoreinheit (GPGPU: General-Purpose Graphics Processor Unit) beinhalten, wobei der Grafikprozessor verwendet wird, um SIMD-Vektoroperationen unter Verwendung von Rechen-Shader-Programmen, die nicht explizit mit dem Rendering von Grafikprimitiven in Zusammenhang stehen, durchzuführen.
  • Die Medien-Pipeline 2224 kann auf ähnliche Weise wie die 3D-Pipeline 2222 konfiguriert sein. Ein Satz von Befehlen zum Konfigurieren des Medien-Pipeline-Zustands 2240 wird vor den Medienobjektbefehlen 2242 versendet oder in eine Befehlswarteschlange eingereiht. Befehle für den Medien-Pipeline-Zustand 2240 können Daten zum Konfigurieren der Medien-Pipeline-Elemente beinhalten, die zum Verarbeiten der Medienobjekte verwendet werden. Dies schließt Daten zum Konfigurieren der Videodecodierungs- und Videocodierungslogik in der Medien-Pipeline wie etwa ein Codierungs- oder Decodierungsformat ein. Befehle für den Medien-Pipeline-Zustand 2240 können auch die Verwendung eines oder mehrerer Zeiger auf „indirekte“ Zustandselemente unterstützen, die ein Batch von Zustandseinstellungen enthalten.
  • Medienobjektbefehle 2242 können Zeiger auf Medienobjekte zur Verarbeitung durch die Medien-Pipeline liefern. Die Medienobjekte beinhalten Speicherpuffer, die zu verarbeitende Videodaten enthalten. Optional müssen alle Medien-Pipeline-Zustände gültig sein, bevor sie einen Medienobjektbefehl 2242 ausgeben. Sobald der Pipeline-Zustand konfiguriert ist und die Medienobjektbefehle 2242 in die Warteschlange eingereiht sind, wird die Medien-Pipeline 2224 über einen Ausführungsbefehl 2244 oder ein äquivalentes Ausführungsereignis (z. B. Registerschreibvorgang) ausgelöst. Die Ausgabe von der Medien-Pipeline 2224 kann dann durch Operationen nachverarbeitet werden, die durch die 3D-Pipeline 2222 oder die Medien-Pipeline 2224 bereitgestellt werden. GPGPU-Operationen können auf ähnliche Weise wie Medienoperationen konfiguriert und ausgeführt werden.
  • Grafiksoftwarearchitektur
  • 23 veranschaulicht eine beispielhafte Grafiksoftwarearchitektur für ein Datenverarbeitungssystem 2300. Eine solche Softwarearchitektur kann eine 3D-Grafikanwendung 2310, ein Betriebssystem 2320 und mindestens einen Prozessor 2330 beinhalten. Der Prozessor 2330 kann einen Grafikprozessor 2332 und einen oder mehrere Allzweck-Prozessorkerne 2334 beinhalten. Der Prozessor 2330 kann eine Variante des Prozessors 1402 oder ein beliebiger anderer der hierin beschriebenen Prozessoren sein. Der Prozessor 2330 kann anstelle des Prozessors 1402 oder eines beliebigen anderen der hierin beschriebenen Prozessoren verwendet werden. Daher offenbart die Offenbarung jeglicher Merkmale in Kombination mit dem Prozessor 1402 oder einem beliebigen anderen der hierin beschriebenen Prozessoren auch eine entsprechende Kombination mit dem Grafikprozessor 2330, ist aber nicht darauf beschränkt. Zudem beschreiben die Elemente von 23 mit den gleichen oder ähnlichen Namen wie die Elemente einer beliebigen anderen Figur hierin die gleichen Elemente wie in den anderen Figuren, können auf ähnliche Weise arbeiten oder fungieren, können die gleichen Komponenten umfassen und können mit anderen Entitäten wie jene, die an anderer Stelle hierin beschrieben sind, verknüpft sein, sind jedoch nicht darauf beschränkt. Die Grafikanwendung 2310 und das Betriebssystem 2320 werden jeweils in dem Systemspeicher 2350 des Datenverarbeitungssystems ausgeführt.
  • Die 3D-Grafikanwendung 2310 kann ein oder mehrere Shader-Programme, die Shader-Anweisungen 2312 beinhalten, enthalten. Die Shader-Sprache-Anweisungen können in einer High-Level-Shader-Sprache sein, wie etwa der High-Level-Shader-Sprache (HLSL) von Direc3D, der OpenGL Shader-Sprache (GLSL) und so weiter. Die Anwendung kann auch ausführbare Anweisungen 2314 in einer Maschinensprache aufweisen, die zur Ausführung durch den Allzweckprozessorkern 2334 geeignet sind. Die Anwendung kann auch Grafikobjekte 2316 beinhalten, die durch Vertex-Daten definiert sind.
  • Bei dem Betriebssystem 2320 kann es sich um ein Microsoft® Windows® Betriebssystem der Microsoft Corporation, ein proprietäres UNIX-ähnliches Betriebssystem oder ein UNIX-ähnliches Open-Source-Betriebssystem, das eine Variante des Linux-Kernels verwendet, handeln. Das Betriebssystem 2320 kann eine Grafik-API 2322 unterstützen, wie etwa die Direct3D-API, die OpenGL-API oder die Vulkan-API. Wenn die Direct3D-API verwendet wird, verwendet das Betriebssystem 2320 einen Frontend-Shader-Compiler 2324, um alle Shader-Anweisungen 2312 in HLSL in eine Shader-Sprache niedrigerer Ebene zu kompilieren. Die Kompilierung kann eine Just-in-Time(JIT)-Kompilierung sein, oder die Anwendung kann eine Shader-Vorkompilierung durchführen. Shader hoher Ebene können während der Kompilierung der 3D-Grafikanwendung 2310 zu Shadern niedrigerer Ebene kompiliert werden. Die Shader-Anweisungen 2312 können in einer Zwischenform bereitgestellt werden, wie etwa als eine Version der SPIR (Standard Portable Intermediate Representation), die durch die Vulkan-API verwendet wird.
  • Ein Benutzermodus-Grafiktreiber 2326 kann einen Backend-Shader-Compiler 2327 enthalten, um die Shader-Anweisungen 2312 in eine hardwarespezifische Repräsentation umzuwandeln. Wenn die OpenGL-API verwendet wird, werden Shader-Anweisungen 2312 in der GLSL-Hochsprache zum Kompilieren an einen Benutzermodus-Grafiktreiber 2326 weitergegeben. Der Benutzermodus-Grafiktreiber 2326 kann Betriebssystemkernelmodus-Funktionen 2328 verwenden, um mit einem Kernelmodus-Grafiktreiber 2329 zu kommunizieren. Der Kernelmodus-Grafiktreiber 2329 kann mit dem Grafikprozessor 2332 kommunizieren, um Befehle und Anweisungen zu versenden.
  • IP-Kern-Implementierungen
  • Ein oder mehrere Aspekte können durch einen repräsentativen Code implementiert werden, der auf einem maschinenlesbaren Medium gespeichert ist, das Logik innerhalb einer integrierten Schaltung, wie zum Beispiel einem Prozessor, repräsentiert und/oder definiert. Zum Beispiel kann das maschinenlesbare Medium Anweisungen beinhalten, die verschiedene Logik innerhalb des Prozessors repräsentieren. Wenn sie durch eine Maschine gelesen werden, können die Anweisungen bewirken, dass die Maschine die Logik herstellt, um die hierin beschriebenen Techniken durchzuführen. Derartige Repräsentationen, die als „IP-Kerne“ bekannt sind, sind wiederverwendbare Logikeinheiten für eine integrierte Schaltung, die auf einem greifbaren, maschinenlesbaren Medium als ein Hardwaremodell gespeichert werden können, das die Struktur der integrierten Schaltung beschreibt. Das Hardwaremodell kann an verschiedene Kunden oder Herstellungseinrichtungen geliefert werden, die das Hardwaremodell auf Herstellungsmaschinen laden, die die integrierte Schaltung herstellen. Die integrierte Schaltung kann derart hergestellt sein, dass die Schaltung Operationen durchführt, die in Verbindung mit irgendeiner der hierin beschriebenen Ausführungsformen beschrieben sind.
  • 24A ist ein Blockdiagramm, das ein IP-Kern-Entwicklungssystem 2400 veranschaulicht, das verwendet werden kann, um eine integrierte Schaltung herzustellen, um Operationen gemäß einer Ausführungsform durchzuführen. Das IP-Kern-Entwicklungssystem 2400 kann verwendet werden, um modulare, wiederverwendbare Designs zu erzeugen, die in ein größeres Design integriert oder verwendet werden können, um eine gesamte integrierte Schaltung (z. B. eine integrierte SOC-Schaltung) zu konstruieren. Eine Designanlage 2430 kann eine Softwaresimulation 2410 eines IP-Kern-Designs in einer höheren Programmiersprache (z. B. C/C++) erzeugen. Die Softwaresimulation 2410 kann dazu verwendet werden, das Verhalten des IP-Kerns unter Verwendung eines Simulationsmodells 2412 zu entwerfen, zu testen und zu verifizieren. Das Simulationsmodell 2412 kann Funktions-, Verhaltens- und/oder Timing-Simulationen beinhalten. Ein Registertransferebene(RTL)-Design 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 Hardware-Registern modelliert, einschließlich der zugehörigen Logik, die unter Verwendung der modellierten digitalen Signale ausgeführt wird. Neben einem RTL-Design 2415 können auch Designs auf niedrigerer Ebene auf der Logikebene oder der Transistorebene erzeugt, entworfen oder synthetisiert werden. Daher können die besonderen Details des anfänglichen Designs und der Simulation variieren.
  • Das RTL-Design 2415 oder ein Äquivalent kann ferner durch die Designanlage in ein Hardwaremodell 2420 synthetisiert werden, das in einer Hardwarebeschreibungssprache (HDL) oder einer anderen Repräsentation von physischen Designdaten vorliegen kann. Die HDL kann weiter simuliert oder getestet werden, um das IP-Kern-Design zu verifizieren. Das IP-Kern-Design kann zur Lieferung an eine Drittherstelleranlage 2465 unter Verwendung eines nichtflüchtigen Speichers 2440 (z. B. Festplatte, Flash-Speicher oder ein beliebiges nichtflüchtiges Speichermedium) gespeichert werden. Alternativ dazu kann das IP-Kern-Design über eine drahtgebundene Verbindung 2450 oder eine drahtlose Verbindung 2460 übertragen werden (z. B. über das Internet). Die Fertigungsanlage 2465 kann dann eine integrierte Schaltung fertigen, die zumindest teilweise auf dem IP-Kern-Design basiert. Die gefertigte integrierte Schaltung kann dazu konfiguriert sein, Operationen gemäß mindestens einer hierin beschriebenen Ausführungsform durchzuführen.
  • 24B veranschaulicht eine Querschnittsseitenansicht einer Integrierte-Schaltung-Package-Baugruppe 2470. Die Integrierte-Schaltung-Package-Baugruppe 2470 veranschaulicht eine Implementierung eines oder mehrerer Prozessoren oder einer oder mehrerer Beschleunigervorrichtungen, wie hierin beschrieben. Die Package-Baugruppe 2470 beinhaltet mehrere Hardwarelogikeinheiten 2472, 2474, die mit einem Substrat 2480 verbunden sind. Die Logik 2472, 2474 kann zumindest teilweise in konfigurierbarer Logik- oder Festfunktionalitätslogikhardware implementiert werden und kann einen oder mehrere Teile beliebiger des einen oder der mehreren Prozessorkerne, des einen oder der mehreren Grafikprozessoren oder anderer hierin beschriebener Beschleunigervorrichtungen beinhalten. Jede Logikeinheit 2472, 2474 kann in einem Halbleiter-Die implementiert und über eine Interconnect-Struktur 2473 mit dem Substrat 2480 gekoppelt werden. Die Interconnect-Struktur 2473 kann dazu konfiguriert sein, elektrische Signale zwischen der Logik 2472, 2474 und dem Substrat 2480 zu routen, und kann Interconnects, wie etwa unter anderem Kontakthügel oder Säulen, beinhalten. Die Interconnect-Struktur 2473 kann dazu konfiguriert sein, elektrische Signale, wie etwa zum Beispiel Eingabe/Ausgabe(E/A)-Signale und/oder Leistungs- oder Massesignale, zu routen, die mit dem Betrieb der Logik 2472, 2474 assoziiert sind. Optional kann das Substrat 2480 ein epoxidbasiertes Laminatsubstrat sein. Das Substrat 2480 kann auch andere geeignete Arten von Substraten beinhalten. Die Package-Baugruppe 2470 kann über ein Package-Interconnect 2483 mit anderen elektrischen Vorrichtungen verbunden sein. Das Package-Interconnect 2483 kann mit einer Oberfläche des Substrats 2480 gekoppelt sein, um elektrische Signale zu anderen elektrischen Vorrichtungen, wie etwa einer Hauptplatine, einem anderen Chipsatz oder einem Mehrchipmodul zu routen.
  • Die Logikeinheiten 2472, 2474 können elektrisch mit einer Brücke 2482 gekoppelt sein, die dazu konfiguriert ist, elektrische Signale zwischen der Logik 2472, 2474 zu routen. Die Brücke 2482 kann eine dichte Interconnect-Struktur sein, die eine Route für elektrische Signale bereitstellt. Die Brücke 2482 kann ein Brückensubstrat beinhalten, das aus Glas oder einem geeigneten Halbleitermaterial gebildet ist. Elektrische Routing-Merkmale können auf dem Brückensubstrat ausgebildet sein, um eine Chip-zu-Chip-Verbindung zwischen der Logik 2472, 2474 bereitzustellen.
  • Obwohl zwei Logikeinheiten 2472, 2474 und eine Brücke 2482 veranschaulicht sind, können hierin beschriebene Ausführungsformen mehr oder weniger Logikeinheiten auf einem oder mehreren Dies beinhalten. Der eine oder die mehreren Dies können durch keine oder mehr Brücken verbunden sein, da die Brücke 2482 ausgelassen werden kann, wenn die Logik auf einem einzelnen Die enthalten ist. Alternativ dazu können mehrere Dies oder Logikeinheiten durch eine oder mehrere Brücken verbunden sein. Zusätzlich dazu können mehrere Logikeinheiten, Dies und Brücken in anderen möglichen Konfigurationen, einschließlich dreidimensionaler Konfigurationen, miteinander verbunden sein.
  • 24C veranschaulicht eine Package-Baugruppe 2490, die mehrere Einheiten von Hardware-Logik-Chiplets beinhaltet, die mit einem Substrat 2480 (z. B. Basis-Die) verbunden sind. Eine Grafikverarbeitungseinheit, ein Parallelprozessor und/oder ein Berechnungsbeschleuniger, wie hierin beschrieben, können aus verschiedenen Silizium-Chiplets bestehen, die separat hergestellt werden. In diesem Zusammenhang ist ein Chiplet eine zumindest teilweise integrierte Schaltung in einem Package, die verschiedene Logikeinheiten beinhaltet, die mit anderen Chiplets zu einem größeren Package zusammengebaut werden können. Ein diverser Satz von Chiplets mit unterschiedlicher IP-Kern-Logik kann zu einer einzigen Vorrichtung zusammengebaut werden. Darüber hinaus können die Chiplets mittels aktiver Interposer-Technologie in einen Basis-Die oder ein Basis-Chiplet integriert werden. Die hierin beschriebenen Konzepte ermöglichen die Verbindung und Kommunikation zwischen den verschiedenen Formen von IP innerhalb der GPU. IP-Kerne können unter Verwendung unterschiedlicher Prozesstechnologien hergestellt und während der Herstellung zusammengestellt werden, wodurch die Komplexität zum Konvergieren mehrerer IPs, insbesondere auf einem großen SoC mit mehreren IP-Varianten, für denselben Herstellungsprozess vermieden wird. Die Nutzung mehrerer Prozesstechnologien verkürzt die Markteinführungszeit und bietet eine kostengünstige Möglichkeit, mehrere Produkt-SKUs zu erstellen. Darüber hinaus sind die disaggregierten IPs für ein unabhängiges Ansteuern mit Leistung besser geeignet, Komponenten, die bei einer bestimmten Arbeitslast nicht verwendet werden, können ausgeschaltet werden, wodurch der Gesamtleistungsverbrauch reduziert wird.
  • Die Hardware-Logik-Chiplets können Spezialhardware-Logik-Chiplets 2472, Logik- oder E/A-Chiplets 2474 und/oder Speicher-Chiplets 2475 beinhalten. Die Hardware-Logik-Chiplets 2472 und die Logik- oder E/A-Chiplets 2474 können zumindest teilweise in konfigurierbarer Logik- oder Festfunktionalitätslogikhardware implementiert werden und können einen oder mehrere Teile beliebiger des einen oder der mehreren Prozessorkerne, des einen oder der mehreren Grafikprozessoren, der Parallelprozessoren oder anderer hierin beschriebener Beschleunigervorrichtungen beinhalten. Die Speicher-Chiplets 2475 können DRAM(z. B. GDDR, HBM)-Speicher oder Cache(SRAM)-Speicher sein.
  • Jedes Chiplet kann als separater Halbleiter-Die gefertigt und über eine Interconnect-Struktur 2473 mit dem Substrat 2480 gekoppelt werden. Die Interconnect-Struktur 2473 kann dazu konfiguriert sein, elektrische Signale zwischen den verschiedenen Chiplets und der Logik innerhalb des Substrats 2480 zu routen. Die Interconnect-Struktur 2473 kann Interconnects wie etwa unter anderem Kontakthügel oder Säulen beinhalten. Bei manchen Ausführungsformen kann die Interconnect-Struktur 2473 dazu konfiguriert sein, elektrische Signale, wie etwa zum Beispiel Eingabe/Ausgabe(E/A)-Signale und/oder Leistungs- oder Massesignale, zu routen, die mit dem Betrieb der Logik, E/A und Speicher-Chiplets assoziiert sind.
  • Das Substrat 2480 kann ein epoxidbasiertes Laminatsubstrat sein, ist jedoch nicht darauf beschränkt, und das Substrat 2480 kann auch andere geeignete Arten von Substraten beinhalten. Die Package-Baugruppe 2490 kann über ein Package-Interconnect 2483 mit anderen elektrischen Vorrichtungen verbunden sein. Das Package-Interconnect 2483 kann mit einer Oberfläche des Substrats 2480 gekoppelt sein, um elektrische Signale zu anderen elektrischen Vorrichtungen, wie etwa einer Hauptplatine, einem anderen Chipsatz oder einem Mehrchipmodul zu routen.
  • Ein Logik- oder E/A-Chiplet 2474 und ein Speicher-Chiplet 2475 können über eine Brücke 2487 elektrisch gekoppelt sein, die dazu konfiguriert ist, elektrische Signale zwischen dem Logik- oder E/A-Chiplet 2474 und einem Speicher-Chiplet 2475 zu routen. Die Brücke 2487 kann eine dichte Interconnect-Struktur sein, die eine Route für elektrische Signale bereitstellt. Die Brücke 2487 kann ein Brückensubstrat beinhalten, das aus Glas oder einem geeigneten Halbleitermaterial gebildet ist. Elektrische Routing-Merkmale können auf dem Brückensubstrat ausgebildet sein, um eine Chip-zu-Chip-Verbindung zwischen dem Logik- oder E/A-Chiplet 2474 und einem Speicher-Chiplet 2475 bereitzustellen. Die Brücke 2487 kann auch als Siliziumbrücke oder Interconnect-Brücke bezeichnet werden. Die Brücke 2487 ist beispielsweise eine eingebettete Mehrfach-Die-Interconnect-Brücke (EMIB: Embedded Multidie Interconnect Bridge). Alternativ kann die Brücke 2487 einfach eine direkte Verbindung von einem Chiplet zu einem anderen Chiplet sein.
  • Das Substrat 2480 kann Hardwarekomponenten für die E/A 2491, den Cachespeicher 2492 und andere Hardwarelogik 2493 beinhalten. Ein Fabric 2485 kann in das Substrat 2480 eingebettet sein, um eine Kommunikation zwischen den verschiedenen Logik-Chiplets und der Logik 2491, 2493 innerhalb des Substrats 2480 zu ermöglichen. Optional können die E/A 2491, das Fabric 2485, der Cache, die Brücke und andere Hardwarelogik 2493 in einen Basis-Die integriert werden, der auf das Substrat 2480 geschichtet ist.
  • Darüber hinaus kann eine Package-Baugruppe 2490 auch eine kleinere oder größere Anzahl von Komponenten und Chiplets beinhalten, die durch ein Fabric 2485 oder eine oder mehrere Brücken 2487 miteinander verbunden sind. Die Chiplets innerhalb der Package-Baugruppe 2490 können in einer 3D- oder 2,5D-Anordnung angeordnet sein. Im Allgemeinen können Brückenstrukturen 2487 verwendet werden, um ein Punkt-zu-Punkt-Interconnect zwischen beispielsweise Logik- oder E/A-Chiplets und Speicher-Chiplets zu ermöglichen. Das Fabric 2485 kann verwendet werden, um die verschiedenen Logik- und/oder E/A-Chiplets (z. B. Chiplets 2472, 2474, 2491, 2493) miteinander, mit anderen Logik- und/oder E/A-Chiplets zu verbinden. Der Cachespeicher 2492 innerhalb des Substrats kann als globaler Cache für die Package-Baugruppe 2490, als Teil eines verteilten globalen Caches oder als dedizierter Cache für das Fabric 2485 fungieren.
  • 24D veranschaulicht eine Package-Baugruppe 2494 einschließlich austauschbarer Chiplets 2495 gemäß einer Ausführungsform. Die austauschbaren Chiplets 2495 können in standardisierte Steckplätze auf einem oder mehreren Basis-Chiplets 2496, 2498 montiert werden. Die Basis-Chiplets 2496, 2498 können über ein Brücken-Interconnect 2497 gekoppelt sein, das den anderen hierin beschriebenen Brücken-Interconnects ähnlich sein kann und beispielsweise eine EMIB sein kann. Speicher-Chiplets können auch über ein Brücken-Interconnect mit Logik- oder E/A-Chiplets verbunden sein. E/A- und Logik-Chiplets können über ein Interconnect-Fabric kommunizieren. Die Basis-Chiplets können jeweils einen oder mehrere Steckplätze in einem standardisierten Format für Logik oder E/A oder Speicher/Cache unterstützen.
  • SRAM- und Leistungsabgabeschaltungen können in einem oder mehreren der Basis-Chiplets 2496, 2498 hergestellt werden, die unter Verwendung einer anderen Prozesstechnologie im Vergleich zu den austauschbaren Chiplets 2495 hergestellt werden können, die auf die Basis-Chiplets gestapelt sind. Beispielsweise können die Basis-Chiplets 2496, 2498 unter Verwendung einer größeren Prozesstechnologie hergestellt werden, während die austauschbaren Chiplets unter Verwendung einer kleineren Prozesstechnologie hergestellt werden können. Einer oder mehrere der austauschbaren Chiplets 2495 können Speicher(z. B. DRAM)-Chiplets sein. Für die Package-Baugruppe 2494 können unterschiedliche Speicherdichten basierend auf der Leistung und/oder Leistungsfähigkeit ausgewählt werden, die für das Produkt, das die Package-Baugruppe 2494 verwendet, angestrebt wird. Außerdem können Logik-Chiplets mit einer anderen Anzahl von Typen von Funktionseinheiten zum Zeitpunkt des Zusammenbaus basierend auf der Leistung und/oder Leistungsfähigkeit ausgewählt werden, die für das Produkt angestrebt wird. Darüber hinaus können Chiplets, die IP-Logikkerne unterschiedlicher Typen enthalten, in die austauschbaren Chiplet-Steckplätze eingefügt werden, wodurch Hybridprozessordesigns ermöglicht werden, die IP-Blöcke unterschiedlicher Technologie Mix-and-Match-artig frei kombinieren können.
  • Beispielhafte integrierte Schaltung eines System-on-Chip
  • 25-26 veranschaulichen beispielhafte integrierte Schaltungen und assoziierte Grafikprozessoren, die unter Verwendung eines oder mehrerer IP-Kerne hergestellt werden können. Zusätzlich zu den Veranschaulichungen können andere Logik und Schaltungen enthalten sein, einschließlich zusätzlicher Grafikprozessoren/-kerne, Peripherieschnittstellensteuerungen oder Allzweckprozessorkerne. Die Elemente von 25-26 mit den gleichen oder ähnlichen Namen wie die Elemente einer beliebigen anderen Figur hierin beschreiben die gleichen Elemente wie in den anderen Figuren, können auf ähnliche Weise arbeiten oder fungieren, können die gleichen Komponenten umfassen und können mit anderen Entitäten wie jene, die an anderer Stelle hierin beschrieben sind, verknüpft sein, sind jedoch nicht darauf beschränkt.
  • 25 ist ein Blockdiagramm, das eine beispielhafte integrierte Schaltung 2500 eines System-on-Chip veranschaulicht, die unter Verwendung eines oder mehrerer IP-Kerne hergestellt werden kann. Die beispielhafte integrierte Schaltung 2500 beinhaltet einen oder mehrere Anwendungsprozessoren 2505 (z. B. CPUs), mindestens einen Grafikprozessor 2510, der eine Variante des Grafikprozessors 1408, 1508, 2510 oder eines beliebigen hierin beschriebenen Grafikprozessors sein kann, und kann anstelle jeglicher beschriebenen Grafikprozessoren verwendet werden. Daher offenbart die Offenbarung jeglicher Merkmale in Kombination mit einem Grafikprozessor hierin auch eine entsprechende Kombination mit dem Grafikprozessor 2510, ist aber nicht darauf beschränkt. Die integrierte Schaltung kann zusätzlich einen Bildprozessor 2515 und/oder einen Videoprozessor 2520 aufweisen, von denen jeder ein modularer IP-Kern aus derselben oder mehreren verschiedenen Entwurfseinrichtungen sein kann. Die integrierte Schaltung 2500 kann eine Peripherie- oder Buslogik beinhalten, einschließlich einer USB-Steuerung 2525, einer UART-Steuerung 2530, einer SPI/SDIO-Steuerung 2535 und einer I2S/I2C-Steuerung 2540. Außerdem kann die integrierte Schaltung eine Anzeigevorrichtung 2545 beinhalten, die mit einer HDMI(High Definition Multimedia Interface)-Steuerung 2550 und/oder einer MIPI(Mobile Industry Processor Interface)-Anzeigeschnittstelle 2555 gekoppelt ist. Die Speicherung kann durch ein Flash-Speichersubsystem 2560 bereitgestellt werden, das Flash-Speicher und eine Flash-Speichersteuerung beinhaltet. Eine Speicherschnittstelle kann über eine Speichersteuerung 2565 zum Zugriff auf SDRAM- oder SRAM-Speichervorrichtungen bereitgestellt werden. Einige integrierte Schaltungen weisen zusätzlich eine eingebettete Sicherheits-Engine 2570 auf.
  • 26A-26B sind Blockdiagramme, die beispielhafte Grafikprozessoren zur Verwendung in einem SoC gemäß hierin beschriebenen Ausführungsformen veranschaulichen. Die Grafikprozessoren können Varianten des Grafikprozessors 1408, 1508, 2510 oder eines beliebigen anderen hierin beschriebenen Grafikprozessors sein. Der Grafikprozessor kann anstelle des Grafikprozessors 1408, 1508, 2510 oder eines beliebigen anderen der hierin beschriebenen Grafikprozessoren verwendet werden. Daher offenbart die Offenbarung jeglicher Merkmale in Kombination mit dem Grafikprozessor 1408, 1508, 2510, oder einem beliebigen anderen der hierin beschriebenen Grafikprozessoren auch eine entsprechende Kombination mit den Grafikprozessoren von 26A-26B, ist aber nicht darauf beschränkt. 26A veranschaulicht einen beispielhaften Grafikprozessor 2610 einer integrierten Schaltung eines System-on-Chip, der gemäß einer Ausführungsform unter Verwendung eines oder mehrerer IP-Kerne hergestellt werden kann. 26B veranschaulicht einen zusätzlichen beispielhaften Grafikprozessor 2640 einer integrierten Schaltung eines System-on-Chip, der gemäß einer Ausführungsform unter Verwendung eines oder mehrerer IP-Kerne hergestellt werden kann. Der Grafikprozessor 2610 von 26A ist ein Beispiel für einen Niederleistungs-Grafikprozessorkern. Der Grafikprozessor 2640 von 26B ist ein Beispiel für einen Grafikprozessorkern mit höherer Leistungsfähigkeit. Beispielsweise kann jeder der Grafikprozessoren 2610, 2640 eine Variante des Grafikprozessors 2510 von 25 sein, wie zu Beginn dieses Absatzes erwähnt.
  • Wie in 26A gezeigt, beinhaltet der Grafikprozessor 2610 einen Vertex-Prozessor 2605 und einen oder mehrere Fragmentprozessoren 2615A-2615N (z. B. 2615A, 2615B, 2615C, 2615D bis 2615N-1 und 2615N). Der Grafikprozessor 2610 kann verschiedene Shader-Programme über separate Logik ausführen, sodass der Vertex-Prozessor 2605 zum Ausführen von Operationen für Vertex-Shader-Programme optimiert ist, während der eine oder die mehreren Fragment-Prozessoren 2615A-2615N Fragment(z. B. Pixel)-Shading-Operationen für Fragment- oder Pixel-Shader-Programme ausführen. Der Vertex-Prozessor 2605 führt die Vertex-Verarbeitungsstufe der 3D-Grafik-Pipeline aus und erzeugt Primitive und Vertexdaten. Der eine oder die mehreren Fragment-Prozessoren 2615A-2615N verwenden die durch den Vertex-Prozessor 2605 erzeugten Primitiven und Vertex-Daten, um einen Frame-Puffer zu erzeugen, der auf einer Anzeigevorrichtung angezeigt wird. Der eine oder die mehreren Fragment-Prozessoren 2615A-2615N können dazu optimiert sein, Fragment-Shader-Programme, wie sie in der OpenGL-API bereitgestellt werden, auszuführen, die verwendet werden können, um ähnliche Operationen wie ein Pixel-Shader-Programm durchzuführen, wie es in der Direct-3D-API bereitgestellt wird.
  • Der Grafikprozessor 2610 enthält zusätzlich eine oder mehrere Speicherverwaltungseinheiten (MMUs: Memory Management Units) 2620A-2620B, den einen oder die mehreren Caches 2625A-2625B und das eine oder die mehreren Schaltung-Interconnects 2630A-2630B. Die eine oder die mehreren MMUs 2620A-2620B stellen eine Abbildung von virtuellen auf physische Adressen für den Grafikprozessor 2610 bereit, einschließlich für den Vertex-Prozessor 2605 und/oder den einen oder die mehreren Fragment-Prozessoren 2615A-2615N, die zusätzlich zu Vertex- oder Bild-/Texturdaten, die in dem einen oder den mehreren Caches 2625A-2625B gespeichert sind, Vertex- oder Bild-/Texturdaten referenzieren können, die im Speicher gespeichert sind. Die eine oder die mehreren MMUs 2620A-2620B können mit anderen MMUs innerhalb des Systems synchronisiert werden, einschließlich einer oder mehrerer MMUs, die mit dem einen oder den mehreren Anwendungsprozessoren 2505, dem Bildprozessor 2515 und/oder dem Videoprozessor 2520 25 assoziiert sind, sodass jeder Prozessor 2505-2520 an einem gemeinsam genutzten oder vereinheitlichten virtuellen Speichersystem teilnehmen kann. Komponenten des Grafikprozessors 2610 können Komponenten anderer hierin beschriebener Grafikprozessoren entsprechen. Die eine oder die mehreren MMUs 2620A - 2620B können der MMU 245 von 2C entsprechen. Der Vertex-Prozessor 2605 und der eine oder die mehreren Fragment-Prozessoren 2615A-2615N können dem Grafikmultiprozessor 234 entsprechen. Das eine oder die mehreren Schaltung-Interconnects 2630A-2630B ermöglichen gemäß Ausführungsformen, dass der Grafikprozessor 2610 mit anderen IP-Kernen innerhalb des SoC eine Schnittstelle bildet, entweder über einen internen Bus des SoC oder über eine direkte Verbindung. Das eine oder die mehreren Interconnects 2630A - 2630B können der Daten-Crossbar 240 von 2C entsprechen. Eine weitere Korrespondenz kann zwischen analogen Komponenten des Grafikprozessors 2610 und den verschiedenen hierin beschriebenen Grafikprozessorarchitekturen gefunden werden.
  • Wie in 26B gezeigt, enthält der Grafikprozessor 2640 die eine oder die mehreren MMUs 2620A-2620B, den einen oder die mehreren Caches 2625A-2625B und das eine oder die mehreren Schaltung-Interconnects 2630A-2630B des Grafikprozessors 2610 von 26A. Der Grafikprozessor 2640 beinhaltet einen oder mehrere Shader-Kerne 2655A-2655N (z. B. 2655A, 2655B, 2655C, 2655D, 2655E, 2655F, bis 2655N-1 und 2655N), was für eine vereinheitlichte Shader-Kernarchitektur sorgt, in der ein einzelner Kern oder Kerntyp alle Arten von programmierbarem Shader-Code ausführen kann, einschließlich Shader-Programmcode zur Implementierung von Vertex-Shadern, Fragment-Shadern und/oder Berechnungs-Shadem. Die genaue Anzahl der vorhandenen Shader-Kerne kann zwischen Ausführungsformen und Implementierungen variieren. Außerdem beinhaltet der Grafikprozessor 2640 einen Inter-Kern-Aufgabenmanager 2645, der als ein Thread-Dispatcher zum Versenden von Ausführungs-Threads an einen oder mehrere Shader-Kerne 2655A-2655N fungiert, und eine Kachelungseinheit 2658 zum Beschleunigen von Kacheloperationen für kachelbasiertes Rendering, wobei die Rendering-Operationen für eine Szene in einen Bildraum unterteilt sind, um zum Beispiel lokale räumliche Kohärenz innerhalb einer Szene auszunutzen oder um die Verwendung von internen Caches zu optimieren. Die Shader-Kerne 2655A- 2655N können beispielsweise dem Grafikmultiprozessor 234 wie in 2D oder den Grafikmultiprozessoren 325, 350 von 3A bzw. 3B oder der Mehrkerngruppe 365A von 3C entsprechen.
  • Hierin beschriebene Ausführungsformen beinhalten Software-, Firmware- und Hardwarelogik, die Techniken zum Durchführen von Arithmetik an Sparse-Daten über eine systolische Verarbeitungseinheit bereitstellt. Die hierin beschriebene Ausführungsform stellte Techniken bereit, um Rechenoperationen für mit Nullen gefüllte Matrizen und Untermatrizen zu überspringen. Ausführungsformen stellen zusätzlich Techniken bereit, um die Datenkomprimierung bis hin zu einer Verarbeitungseinheit aufrechtzuerhalten. Ausführungsformen stellen zusätzlich eine Architektur für eine sparse-bewusste Logikeinheit bereit.
  • GPGPU mit Tensorbeschleunigungslogik und vereinheitlichtem Speicher
  • 27 ist ein Blockdiagramm eines Datenverarbeitungssystems 2700 gemäß einer Ausführungsform. Das Datenverarbeitungssystem 2700 ist ein heterogenes Verarbeitungssystem mit einem Prozessor 2702, einem vereinheitlichten Speicher 2710 und einer GPGPU 2720 mit Maschinenlernbeschleunigungslogik. Der Prozessor 2702 und die GPGPU 2720 können beliebige der hier beschriebenen Prozessoren und GPGPU/Parallelprozessoren sein. Der Prozessor 2702 kann Anweisungen für einen Compiler 2715 ausführen, die im Systemspeicher 2712 gespeichert sind. Der Compiler 2715 wird auf dem Prozessor 2702 ausgeführt, um den Quellcode 2714A in den kompilierten Code 2714B zu kompilieren. Der kompilierte Code 2714B kann Anweisungen aufweisen, die durch den Prozessor 2702 ausgeführt werden können, und/oder einen Anweisungen, die durch die GPGPU 2720 ausgeführt werden können. Während des Kompilierens kann der Compiler 2715 Operationen zum Einfügen von Metadaten durchführen, einschließlich Hinweisen bezüglich des Grads an Datenparallelität, der in dem kompilierten Code 2714B vorhanden ist, und/oder Hinweise bezüglich der Datenlokalität, die mit zu versendenden Threads assoziiert ist, basierend auf dem kompilierten Code 2714B. Der Compiler 2715 kann die Informationen beinhalten, die zum Ausführen solcher Operationen erforderlich sind, oder die Operationen können mithilfe einer Laufzeitbibliothek 2716 durchgeführt werden. Die Laufzeitbibliothek 2716 kann den Compiler 2715 auch bei der Kompilierung des Quellcodes 2714A unterstützen und kann auch Anweisungen beinhalten, die zur Laufzeit mit dem kompilierten Code 2714B verknüpft sind, um die Ausführung der kompilierten Anweisungen auf der GPGPU 2720 zu ermöglichen.
  • Der vereinheitlichte Speicher 2710 repräsentiert einen vereinheitlichten Adressraum, auf den der Prozessor 2702 und die GPGPU 2720 zugreifen können. Der vereinheitlichte Speicher kann einen Systemspeicher 2712 sowie einen GPGPU-Speicher 2718 beinhalten. Der GPGPU-Speicher 2718 ist ein Speicher innerhalb eines Adressbereichs der GPGPU 2720 und kann einen Teil oder den gesamten Systemspeicher 2712 beinhalten. In einer Ausführungsform kann der GPGPU-Speicher 2718 auch zumindest einen Teil eines beliebigen Speichers beinhalten, der ausschließlich für die Verwendung durch die GPGPU 2720 dediziert ist. In einer Ausführungsform kann der im Systemspeicher 2712 gespeicherte kompilierte Code 2714B für den Zugriff durch die GPGPU 2720 in den GPGPU-Speicher 2718 abgebildet werden.
  • Die GPGPU 2720 beinhaltet mehrere Berechnungsblöcke 2724A - 2724N, die eine oder mehrere einer Vielzahl von hierin beschriebenen Verarbeitungsressourcen beinhalten können. Die Verarbeitungsressourcen können eine Vielzahl unterschiedlicher Rechenressourcen sein oder beinhalten, wie etwa beispielsweise Ausführungseinheiten, Berechnungseinheiten, Streaming-Multiprozessoren, Grafikmultiprozessoren oder Mehrkerngruppen. In einer Ausführungsform beinhaltet die GPGPU 2720 zusätzlich einen Tensor(z. B. Matrix)-Beschleuniger 2723, der eine oder mehrere Spezialfunktions-Berechnungseinheiten beinhalten kann, die dafür ausgelegt sind, eine Teilmenge von Matrixoperationen (z. B. Skalarprodukt usw.) zu beschleunigen. Der Tensorbeschleuniger 2723 kann auch als Tensorbeschleuniger oder Tensorkern bezeichnet werden. In einer Ausführungsform können Logikkomponenten innerhalb des Tensorbeschleunigers 2723 über die Verarbeitungsressourcen der mehreren Berechnungsblöcke 2724A - 2724N verteilt werden.
  • Die GPGPU 2720 kann auch einen Satz von Ressourcen beinhalten, der von den Berechnungsblöcken 2724A-2724N und dem Tensorbeschleuniger 2723 gemeinsam genutzt werden kann, einschließlich unter anderem eines Satzes von Registern 2725, eines Leistungs- und Leistungsfähigkeitsmoduls 2726 und eines Caches 2727. In einer Ausführungsform beinhalten die Register 2725 direkt und indirekt zugängliche Register, wobei die indirekt zugänglichen Register für die Verwendung durch den Tensorbeschleuniger 2723 optimiert sind. Das Leistungs- und Leistungsfähigkeitsmodul 2726 kann dazu konfiguriert sein, Leistungsabgabe und Taktfrequenzen für die Berechnungsblöcke 2724A - 2724N anzupassen, um Gate-Leerlaufkomponenten innerhalb der Berechnungsblöcke 2724A - 2724N mit Leistung zu versorgen. In verschiedenen Ausführungsformen kann der Cache 2727 einen Anweisungscache und/oder einen Datencache niedrigerer Ebene beinhalten.
  • Die GPGPU 2720 kann zusätzlich einen L3-Datencache 2730 beinhalten, der verwendet werden kann, um Daten zu cachen, auf die vom vereinigten Speicher 2710 durch den Tensorbeschleuniger 2723 und/oder die Berechnungselemente innerhalb der Berechnungsblöcke 2724A - 2724N zugegriffen wird. In einer Ausführungsform beinhaltet der L3-Datencache 2730 einen gemeinsam genutzten lokalen Speicher 2732, der von den Berechnungselementen innerhalb der Berechnungsblöcke 2724A-2724N und dem Tensorbeschleuniger 2723 gemeinsam genutzt werden kann.
  • In einer Ausführungsform beinhaltet die GPGPU 2720 eine Anweisungshandhabungslogik, wie etwa eine Abruf-und-Decodier-Einheit 2721 und eine Scheduler-Steuerung 2722. Die Abruf-und-Decodier-Einheit 2721 beinhaltet eine Abrufeinheit und eine Decodiereinheit zum Abrufen und Decodieren von Anweisungen zur Ausführung durch einen oder mehrere der Berechnungsblöcke 2724A-2724N oder den Tensorbeschleuniger 2723. Die Anweisungen können über die Scheduler-Steuerung 2722 für die entsprechende Funktionseinheit innerhalb des Berechnungsblocks 2724A-2724N oder des Tensorbeschleunigers geplant werden. In einer Ausführungsform ist die Scheduler-Steuerung 2722 eine ASIC, die konfiguriert werden kann, um erweiterte Scheduling-Operationen durchzuführen. In einer Ausführungsform ist die Scheduler-Steuerung 2722 ein Mikrocontroller oder ein Verarbeitungskern mit niedriger Energie pro Anweisung, der in der Lage ist, von einem Firmware-Modul geladene Scheduler-Anweisungen auszuführen.
  • In einer Ausführungsform können einige von den Berechnungsblöcken 2724A-2724N durchzuführende Funktionen direkt für den Tensorbeschleuniger 2723 geplant oder zu diesem ausgelagert werden. In verschiedenen Ausführungsformen beinhaltet der Tensorbeschleuniger 2723 eine Verarbeitungselementlogik, die dazu konfiguriert ist, Matrixberechnungsoperationen effizient durchzuführen, wie etwa Multiplikations- und Addieroperationen und Skalarproduktoperationen, die von 3D-Grafik- oder Berechnungs-Shader-Programmen verwendet werden. In einer Ausführungsform kann der Tensorbeschleuniger 2723 dazu konfiguriert sein, Operationen zu beschleunigen, die von Maschinenlern-Frameworks verwendet werden. In einer Ausführungsform ist der Tensorbeschleuniger 2723 eine anwendungsspezifische integrierte Schaltung, die explizit dazu konfiguriert ist, einen spezifischen Satz von parallelen Matrixmultiplikations- und/oder -additionsoperationen durchzuführen. In einer Ausführungsform ist der Tensorbeschleuniger 2723 ein feldprogrammierbares Gate-Array (FPGA), das eine Festfunktionslogik bereitstellt, die zwischen Arbeitslasten aktualisiert werden kann. Der Satz von Matrixoperationen, die durch den Tensorbeschleuniger 2723 ausgeführt werden können, kann im Vergleich zu den Operationen beschränkt sein, die durch die Berechnungsblöcke 2724A - 2724N ausgeführt werden können. Jedoch kann der Tensorbeschleuniger 2723 diese Operationen mit einem signifikant höheren Durchsatz im Vergleich zu den Berechnungsblöcken 2724A-2724N ausführen.
  • 28 veranschaulicht eine Matrixoperation 2805, die von einer Anweisung-Pipeline 2800 ausgeführt wird, gemäß einer Ausführungsform. Die Anweisung-Pipeline 2800 kann dazu konfiguriert sein, eine Matrixoperation 2805 durchzuführen, wie etwa unter anderem eine Skalarproduktoperation. Das Skalarprodukt zweier Vektoren ist ein Skalarwert, der gleich der Summe der Produkte entsprechender Komponenten der Vektoren ist. Das Skalarprodukt kann wie in Gleichung (1) unten gezeigt berechnet werden. a → ⋅ b → = ∑ i = 1 n a i b i = a 1 b 1 + … + a n b n
    Figure DE112020000846T5_0001
  • Das Skalarprodukt kann in einer Faltungsoperation für ein faltendes neuronales Netzwerk (CNN) verwendet werden. 28 veranschaulicht eine zweidimensionale (2D) Faltung unter Verwendung einer Matrixoperation 2805 einschließlich einer Skalarproduktoperation. Während eine 2D-Faltung veranschaulicht ist, kann eine N-dimensionale Faltung an einem N-dimensionalen Volumen unter Verwendung von N-dimensionalen Filtern durchgeführt werden. Eine rezeptive Feldkachel 2802 hebt einen Teil eines Eingabevolumens in einem Eingabevolumenpuffer 2804 hervor. Der Eingabevolumenpuffer kann im Speicher 2830 gespeichert werden. Eine Skalarproduktmatrixoperation 2805 kann zwischen den Daten innerhalb der rezeptiven Feldkachel 2802 und einem Faltungsfilter ausgeführt werden, um einen Datenpunkt innerhalb des Ausgabepuffers 2806 zu erzeugen, der auch im Speicher 2830 gespeichert werden kann. Der Speicher 2830 kann ein beliebiger der hierin beschriebenen Speicher sein, einschließlich Systemspeicher 2712, GPGPU-Speicher 2718 oder ein oder mehrere Cachespeicher 2727, 2730 wie in 27.
  • Die Kombination der Datenpunkte innerhalb des Ausgabepuffers 2806 stellt eine Aktivierungskarte dar, die durch die Faltungsoperation erzeugt wird. Jeder Punkt innerhalb der Aktivierungskarte wird erzeugt, indem die rezeptive Feldkachel über den Eingabevolumenpuffer 2804 geschoben wird. Die Aktivierungskartendaten können in eine Aktivierungsfunktion eingegeben werden, um einen Ausgabeaktivierungswert zu bestimmen. In einer Ausführungsform kann die Faltung des Eingabevolumenpuffers 2804 innerhalb eines Framework als Matrixoperation 2905 hoher Ebene definiert werden. Die Matrixoperationen hoher Ebene können über Primitiv-Operationen durchgeführt werden, wie beispielsweise eine BLAS-Operation (BLAS: Basic Linear Algebra Subprogram - grundlegendes lineares Algebra-Unterprogramm). Die Primitiv-Operationen können über Hardware-Anweisungen beschleunigt werden, die durch die Anweisung-Pipeline 2800 ausgeführt werden.
  • Die Anweisung-Pipeline 2800, die zum Beschleunigen von Hardware-Anweisungen verwendet wird, kann die Anweisungsabruf- und -decodiereinheit 2721, die Hardware-Anweisungen abrufen und decodieren kann, und die Scheduler-Steuerung 2722, die decodierte Anweisungen für eine oder mehrere Verarbeitungsressourcen innerhalb der Berechnungsblöcke 2724A-2724N und/oder des Tensorbeschleunigers 2723 planen kann, beinhalten. In einer Ausführungsform kann eine Hardware-Anweisung für die Berechnungsblöcke 2724A-2724N geplant und an den Tensorbeschleuniger 2723 ausgelagert werden. Die eine oder die mehreren Hardware-Anweisungen und assoziierten Daten zum Durchführen der Matrixoperation 2805 können im Speicher 2830 gespeichert werden. Die Ausgabe der Hardware-Anweisung kann auch im Speicher 2830 gespeichert werden.
  • In einer Ausführungsform kann der Tensorbeschleuniger 2723 eine oder mehrere Hardware-Anweisungen ausführen, um die Matrixoperation 2805 unter Verwendung eines integrierten systolischen Arrays 2808 (DP-Logik) durchzuführen. Das systolische Array 2808 kann eine Kombination aus programmierbarer und Festfunktionshardware beinhalten, die konfigurierbar ist, um Skalarproduktoperationen durchzuführen. Während Funktionseinheiten innerhalb der Berechnungsblöcke 2724A-2724N auch dazu konfiguriert sein können, Skalarproduktoperationen durchzuführen, kann das systolische Array 2808 dazu konfiguriert sein, eine begrenzte Teilmenge von Skalarproduktoperationen mit einem signifikant höheren Durchsatz im Vergleich zu dem Berechnungsblock 2724A-2724N durchzuführen.
  • 29A-29B veranschaulichen Einzelheiten eines hardwarebasierten systolischen Arrays 2808 gemäß einigen Ausführungsformen. 29A veranschaulicht ein Gitter von mehreren Funktionseinheiten, die dazu konfigurierbar sind, mehrere Skalarproduktoperationen innerhalb eines einzelnen Taktzyklus durchzuführen. 29B veranschaulicht eine einzelne beispielhafte Funktionseinheit. Während einer Berechnung der systolischen Matrix,
  • Wie in 29A gezeigt, ist das systolische Array 2808 in einer Ausführungsform dazu konfigurierbar, einen Satz paralleler Skalarproduktoperationen unter Verwendung einer Vielzahl von Funktionseinheiten durchzuführen. Die Skalarprodukte können auf „systolische“ Weise durchgeführt werden, bei der SIMD-Daten über mehrere Schichten von Funktionseinheiten gepumpt werden. Wie in 29A gezeigt, ist das systolische Array 2808 in einer Ausführungsform dazu konfigurierbar, einen Satz paralleler Skalarproduktoperationen unter Verwendung einer Vielzahl von Funktionseinheiten durchzuführen. Die Skalarprodukte können auf „systolische“ Weise durchgeführt werden, bei der SIMD-Daten über mehrere Schichten von Funktionseinheiten gepumpt werden. Das systolische Array 2808 ist eine Sammlung von Funktionseinheiten, die in einem Gitter angeordnet sind. Das Gitter der Funktionseinheiten arbeitet im Gleichschritt und ist für die Durchführung von Multiplizieren-Akkumulieren-Operationen optimiert. Durch das systolische Array 2808 zu bearbeitende Matrizen werden in Untermatrizen unterteilt, die über das Gitter von Funktionseinheiten gepumpt werden.
  • In einer Ausführungsform kann das systolische Array 2808 eine konfigurierbare Anzahl von SIMD-Datenkanälen unter Verwendung einer konfigurierbaren systolischen Tiefe verarbeiten. Für eine gegebene Anweisung können eine SIMD-Breite und eine systolische Tiefe ausgewählt werden, um einen Satz von Quelldaten zu verarbeiten. Die systolische Tiefe definiert die Anzahl der systolischen Schichten der Hardwarelogik, die zum Verarbeiten einer Anweisung verwendet werden. Eine systolische Schicht ist eine Gruppe von Multiplizier- und Addiererlogikeinheiten mit einer variablen SIMD-Breite, wobei die systolische Schicht als Eingabe einen initialen Akkumulatorwert empfangen kann und einen Skalarproduktwert zur Ausgabe an eine nachfolgende systolische Schicht oder an ein Ausgaberegister erzeugt.
  • In einigen Ausführungsformen können drei Quellen verarbeitet werden, wobei jede Quelle ein Vektorregister oder ein Immediate sein kann. In einer Ausführungsform kann die Quelle 2900 (SRC0) ein oder mehrere initiale Akkumulatorwerte sein, die ein einzelner Wert oder ein Vektor von Akkumulatorwerten sein können. Der initiale Akkumulatorwert wird zu dem ersten Satz von Skalarprodukten addiert, die von jeder Funktionseinheit innerhalb der ersten systolischen Schicht berechnet werden. Das von einer Funktionseinheit berechnete Skalarprodukt kann der nächsten systolischen Schicht für den gegebenen SIMD-Kanal bereitgestellt werden. Die Skalarprodukte können basierend auf Quelle 2901 (SRC1) und Quelle 2902 (SRC2) berechnet werden, die Vektorregister sind, die einen oder mehrere Kanäle gepackter Daten enthalten können, wobei jeder Kanal einen Vier-Elemente-Vektor enthält. In einer Ausführungsform ist jeder Kanal 32 Bit breit und stellt vier 8-Bit-Vektorelemente bereit. Einige Ausführungsformen sind dazu konfigurierbar, Skalarprodukte aus Eingabevektoren mit 8-Bit-Elementen, 4-Bit-Elementen und/oder 2-Bit-Elementen zu berechnen. In einer Ausführungsform können Operationen mit gemischter Präzision unter Verwendung einer beliebigen Kombination von unterstützten Elementgrößen (z. B. 8-Bit × 2-Bit, 8-Bit × 4-Bit, 4-Bit × 4-Bit usw.) durchgeführt werden. In einer Ausführungsform ist das systolische Array 2808 für eine ganzzahlige Berechnung konfiguriert, obwohl in einigen Ausführungsformen eine automatische Festkommaoperation konfigurierbar ist. Obwohl die hierin beschriebene Anweisung ein Vier-Elemente-Skalarprodukt ist, kann das systolische Array 2808 in einigen Ausführungsformen auch so konfiguriert sein, dass es Gleitkomma-Skalarproduktberechnungen an einer unterschiedlichen Anzahl von Elementen pro Vektor unterstützt.
  • In einer Ausführungsform können mehrere Kanäle von Vier-Elemente-Vektoren in ein einzelnes Vektorregister verschiedener Breiten (z. B. 64-Bit, 128-Bit, 256-Bit, 512-Bit usw.) gepackt werden. Simultane Skalarprodukte können über das systolische Array 2808 für mehrere Kanäle von Vektorelementen, die über die Quelle 2901 und die Quelle 2902 bereitgestellt werden, berechnet werden. Die Anzahl der zu verarbeitenden Kanäle von Vektorelementen kann basierend auf einer gewählten Ausführungsgröße und systolischen Tiefe für die Skalarproduktberechnung konfiguriert werden. In einer Ausführungsform können Quellvektoren, die breiter als die angegebene Ausführungsgröße und/oder systolische Tiefe sind, unter Verwendung mehrerer Zyklen des systolischen Arrays 2808 berechnet werden.
  • Die Anzahl der Berechnungen, die innerhalb eines gegebenen Taktzyklus durchgeführt werden können, kann basierend auf der Anzahl der SIMD-Spuren und systolischen Schichten variieren. Das systolische Array 2808 kann, wie veranschaulicht, sechzehn Skalarprodukte pro SIMD-Durchsatzspur unter Verwendung einer systolischen Tiefe von vier ausführen. Bei einer Konfiguration für acht SIMD-Spuren kann die Logik 128 Acht-Bit-Ganzzahl(INT8)-Skalarprodukte innerhalb eines gegebenen Zyklus ausführen. Bei einer Konfiguration für acht SIMD-Spuren und einer systolischen Tiefe von acht kann jede Spur 32 Acht-Bit-Ganzzahl(INT8)-Skalarprodukte und insgesamt 256 Skalarprodukte ausführen. Diese spezifische Anzahl von Operationen ist für eine Ausführungsform beispielhaft, und andere Ausführungsformen variieren im Durchsatz. Falls die Datentypen unterschiedlich sind, wird ferner die Anzahl der Operationen basierend auf den unterschiedlichen Datentypen skaliert.
  • Bei jeder Funktionseinheit wird über Multiplizierer- und Addiererlogik ein Skalarprodukt berechnet und das Skalarprodukt zu einem Akkumulatorwert addiert. Die resultierenden Daten können an ein Zielregister ausgegeben oder an den Akkumulator der nächsten systolischen Schicht bereitgestellt werden. Einzelheiten einer Funktionseinheit 2912 sind in 29B gezeigt.
  • Wie in 29B gezeigt, kann eine Funktionseinheit 2912 einen Satz von Eingabedatenpuffern 2904, 2906 und einen Akkumulator 2922 beinhalten, die jeweils Eingabedaten annehmen können. In einer Ausführungsform kann der Eingabedatenpuffer 2906 die Quelle 2902 (SRC2) annehmen, die ein gepackter Vektor mit Eingabedaten sein kann. Der Eingabedatenpuffer 2904 kann eine Quelle 2901 (SRC1) annehmen, die auch ein gepackter Vektor mit Eingabedaten sein kann. Der Akkumulator 2922 kann eine Quelle 2900 (SRC0) annehmen, die einen initialen Akkumulatorwert für die Funktionseinheit 2912 bereitstellt. Der initiale Akkumulatorwert wird zu dem Skalarprodukt addiert, das aus den Elementen der Quelle 2901 und der Quelle 2902 berechnet wird. Das Skalarprodukt wird über eine elementweise Multiplikation der Quellvektoren unter Verwendung eines Satzes von Multiplizierern 2923A-2923D und eines Addierers 2924 berechnet. Die Multiplizierer 2923A-2923D werden verwendet, um einen Satz von Produkten zu berechnen. Eine Summe des Satzes von Produkten wird vom Addierer 2924 berechnet. Die Summe kann mit einem beliebigen über die Quelle 2900 bereitgestellten initialen Wert akkumuliert (z. B. addiert) werden. In einer Ausführungsform kann dieser akkumulierte Wert als ein Eingabewert 2926 für den nächsten Akkumulator bereitgestellt werden, der sich in einer nachfolgenden systolischen Schicht befinden kann. In einer Ausführungsform kann die Quelle 2901 mehrere Kanäle von Eingabedaten beinhalten. Zusätzliche Kanäle der Quelle 2901 können als SRC1-Eingabe an zusätzliche SIMD-Spuren 2928 weitergeleitet werden. sIn einer Ausführungsform kann die Quelle 2902 mehrere Kanäle von Eingabedaten beinhalten. Zusätzliche Kanäle der Quelle 2902 können als SRC2-Eingabedaten in Logikeinheiten innerhalb zusätzlicher systolischer Tiefen verwendet werden. In einer Ausführungsform kann die Quelle 2900 optional mehrere Kanäle beinhalten, wobei zusätzliche Kanäle als Eingabe in den Akkumulator innerhalb zusätzlicher Funktionseinheiten bereitgestellt werden. In einer Ausführungsform kann die Quelle 2900 ein einzelner Wert sein, der zu jedem Akkumulator in jeder Funktionseinheit der initialen systolischen Schicht addiert wird.
  • 30 veranschaulicht ein systolisches Array 3000, das ein Teilsummen-Loopback und eine Schaltungsanordnung zum Beschleunigen der Sparse-Matrix-Multiplikation enthält; In dem oben beschriebenen systolischen Array 2808 können Operanden, die Gewichtungsdaten enthalten, innerhalb des Arrays stationär sein, und eine Teilsumme wird durch die Array-Struktur propagiert. Während andere Einzelheiten in Bezug auf das systolische Array 2808 anwendbar sein können, wird im systolischen Array 3000 eine Teilsumme rezirkuliert, anstatt an eine nächste systolische Schicht propagiert zu werden. In einer Ausführungsform kann ein systolisches Array 3000 mit M Zeilen und N Spalten von Verarbeitungselementen (PE 3012AA - PE 3012MN) konfiguriert sein. Die Verarbeitungselemente können auf Register zugreifen, die Eingabedaten in Form von Zeilen- und Spaltendaten für Eingabematrizen speichern. Die Register können in einer Registerdatei, die lokal für das systolische Array 3000 ist, oder in einer Registerdatei einer Verarbeitungsressource, die mit dem systolischen Array 3000 gekoppelt ist oder dieses beinhaltet, gespeichert sein. Die Register können Zeilenelemente der Matrix A 3002A-3002M speichern, die mit Spaltenelementen der Matrix B 3001A-3002N zu multiplizieren sind.
  • In einer Ausführungsform kann bei jedem Verarbeitungselement PE 3012AA - PE 3012MN in jedem Taktzyklus ein fusioniertes Multiplizieren-Addieren (FMA) durchgeführt werden. Ein Element der Matrix A wird mit einem entsprechenden Element der Matrix B multipliziert und dann zu einem Akkumulatorwert oder für den ersten Zyklus einem optionalen initialen Eingabewert (z. B. SRC0) addiert. Bei jedem Verarbeitungselement kann ein Teilsummen-Loopback konfiguriert werden. Nach jedem Zyklus kann der Akkumulatorwert innerhalb des Verarbeitungselements zurückgeführt und als Eingabe für den nächsten Zyklus verwendet werden. Sobald Operationen für eine ganze Zeile durchgeführt wurden, kann das Ergebnis in einer Registerdatei gespeichert werden. Die Datenbewegung zwischen den Verarbeitungselementen PE 3012AA - PE 3012MN nach einem Satz von Rechenzyklen kann je nach ausgeführter Anweisung oder Makrooperation variieren.
  • Datenbewusste Sparsity (Spärlichkeit) mit Komprimierung
  • Hierin beschriebene Ausführungsformen stellen ein Codierungslayout bereit, das es ermöglicht, Abtastblöcke von Sparse-Daten eines neuronalen Netzwerks in einem reduzierten Bit-Format zu codieren, das die Datenmenge reduziert, die beim Verarbeiten von neuronalen Netzwerken, die mit den Daten assoziiert sind, übertragen oder gespeichert werden muss. Die Anzahl von Werten ungleich Null in einem Abtastblock wird in einem Header angegeben, gefolgt von einer Signifikanzkarte, die eine Karte der Werte ungleich Null innerhalb des Blocks angibt. Die Werte ungleich Null der Abtastung werden in der Reihenfolge ihres Auftretens innerhalb des Stroms codiert. In einer Ausführungsform kann die Komprimierung auf anderen Werten neben Nullwerten basieren. Beispielsweise kann ein spezifizierter Wert innerhalb eines Datensatzes codiert und aus einem komprimierten Datenstrom ausgeschlossen werden, wodurch eine Komprimierung basierend auf Einsen, Zweien oder anderen spezifizierten Werten ermöglicht wird. In einer Ausführungsform wird die Komprimierung basierend auf Nahe-Werten aktiviert. Werte innerhalb eines Datensatzes, die innerhalb einer Schwelle von null oder innerhalb einer Schwelle eines spezifizierten Werts liegen, können komprimiert werden, als ob diese Werte null oder innerhalb einer Schwelle des spezifizierten Werts wären. Datenbewusste Sparsity mit Komprimierung kann über Codec-Logik aktiviert werden, die mit oder innerhalb der Matrixbeschleunigerlogik gekoppelt ist.
  • 31A-31B veranschaulichen eine Matrixbeschleunigungslogik einschließlich Codecs, um das Lesen von Sparse-Daten in einem komprimierten Format zu ermöglichen. 31A veranschaulicht einen Berechnungsblock 3100 einschließlich Codec-aktivierter disaggregierter systolischer Logik. 31B veranschaulicht Verarbeitungselemente innerhalb eines systolischen Arrays, die mit Codecs gekoppelt sind, um Eingabedaten zu dekomprimieren.
  • Wie in 31A gezeigt, kann, anstatt ein systolisches Array 2808 in einem separaten Tensorbeschleuniger 2723 einzuschließen, wie in 28, oder ein systolisches Array 1912 in jeder Ausführungseinheit 1900 einzuschließen, wie in 19, ein disaggregierter Satz von systolischen Arrays 3112A - 3112B in einem Berechnungsblock 3100 enthalten sein, der analog zu einem der Berechnungsblöcke 2724A - 2724N von 27 ist. Der Berechnungsblock 3100 kann auch Komponenten der Ausführungslogik 1800 von 18A enthalten, einschließlich mehrerer miteinander verbundener Verarbeitungsressourcen (PR 3108A-3108O), die der AE 1808A-1808N oder einer beliebigen anderen hierin beschriebenen Verarbeitungsressource ähneln können. In einer Ausführungsform beinhalten die systolischen Arrays 3112A - 3112B Codecs 3124A - 3124B, die das Codieren und Decodieren von Eingabe- und Ausgabedaten ermöglichen, die zur Verarbeitung empfangen werden.
  • Die systolischen Arrays 3112A-3112B beinhalten ein Wbreites und D tiefes Netzwerk von Datenverarbeitungseinheiten, die verwendet werden können, um Vektor- oder andere datenparallele Operationen auf systolische Weise durchzuführen, ähnlich zu anderen hierin beschriebenen systolischen Arrays. In einer Ausführungsform können die systolischen Arrays 3112A - 3112B dazu konfiguriert sein, Matrixoperationen durchzuführen, wie etwa Matrixskalarproduktoperationen. In einer Ausführungsform unterstützen die systolischen Arrays 3112A-3112B 16-Bit-Gleitkommaoperationen sowie 8-Bit- und 4-Bit-Ganzzahloperationen. In einer Ausführungsform kann das systolische Array 3112 dazu konfiguriert sein, Maschinenlernoperationen zu beschleunigen. In solchen Ausführungsformen kann das systolische Array 3112 mit Unterstützung für das bfloat 16-Bit-Gleitkommaformat konfiguriert werden. Durch das Einschließen der systolischen Arrays 3112A - 3112B innerhalb des Berechnungsblocks 3100, aber außerhalb der PRs 3108A - 31080 können die Größe und Anzahl der systolischen Arrays 3112A - 3112B unabhängig von der Anzahl der PRs 3108A - 31080 skaliert werden. Außerdem kann Kommunikationsbandbreite innerhalb einer PR, die ansonsten durch die Aktivität des systolischen Arrays verbraucht würde, bewahrt werden. Darüber hinaus können die systolischen Arrays 3112A - 3112B takt-/leistungsgesteuert sein, wenn keine Matrixarbeitslasten ausgeführt werden.
  • Die Kommunikation zwischen den systolischen Arrays 3112A-3112 und den PRs 3108A-3108O kann über einen Cache oder gemeinsam genutzten lokalen Speicher (Cache/SLM 3110) und/oder eine gemeinsam genutzte Registerdatei 3114 durchgeführt werden. In einer Ausführungsform kann der Cache/SLM 3110 anstelle einer unterschiedlichen gemeinsam genutzten Registerdatei 3114 zur Verwendung als gemeinsam genutzte Registerdatei partitioniert werden. Die gemeinsam genutzte Registerdatei 3114 kann ähnlich wie andere GPGPU-Registerdateien, wie etwa die Registerdatei 1906 wie in 19, strukturiert sein. Die gemeinsam genutzte Registerdatei kann auch einen Satz von Spezialregistern enthalten, die verwendet werden, um die Interaktion zwischen den systolischen Arrays 3112A - 3112B und den PRs 3108A - 31080 zu konfigurieren. Der Cache/SLM 3110 kann ein L 1-Cache, ein L2-Cache und/oder ein Block von explizit adressierbarem On-Die-Speicher sein.
  • Matrixdaten zur Verarbeitung durch die systolischen Arrays 3112A - 3112B können im Cache/SLM 3110 gespeichert werden. Verarbeitungsbefehle oder -anweisungen können den systolischen Arrays 3112A - 3112B über die gemeinsam genutzte Registerdatei 3114 bereitgestellt werden. Verarbeitungsergebnisse können aus dem Cache/SLM 3110 durch die PRs 3108A-3108O oder aus Ziel-/Ausgaberegistern innerhalb der gemeinsam genutzten Registerdatei gelesen werden. Während des Betriebs kann der Kommunikationsverkehr auf die systolischen Arrays 3112A-3112B, den Cache/SLM 3110 und/oder die gemeinsam genutzte Registerdatei 3114 lokalisiert werden, anstatt Bus-/Fabric-Bandbreite innerhalb der PRs 3108A-3108O zu verbrauchen. Jede der PRs 3108A - 31080 innerhalb des Berechnungsblocks 3100 kann eine Matrixarbeitslast auf ein oder beide der systolischen Arrays 3112A - 3112B auslagern. Eine Nachricht kann von einer PR an ein systolisches Array mit einem Befehl gesendet werden, der eine auszuführende Operation und Operanden für die Operation spezifiziert. Die systolischen Arrays 3112A - 3112B können die angeforderten Operationen (Multiplizieren/Addieren, fusioniertes Multiplizieren/Addieren, Multiplizieren/Akkumulieren, Skalarprodukt usw.) ausführen und die Ergebnisse an die gemeinsam genutzte Registerdatei 3114 ausgeben. Eingabe-, Zwischen- und/oder Ausgabedaten für angeforderte Operationen können im Cache/SLM 3110 gespeichert werden und mehrere abhängige Operationen können verkettet werden. In einer Ausführungsform können die systolischen Arrays 3128A - 3128B, wenn Verarbeitungsoperationen für Training oder Inferenz für ein neuronales Netzwerk durchgeführt werden, auch Aktivierungsfunktionen ausführen, einschließlich unter anderem Sigmoid-, ReLU- und Hyperbolische-Tangensfunktion-(TanH)-Aktivierungen. In einer solchen Ausführungsform können Operationen für neuronale Netzwerke bei grober Granularität auf die systolischen Arrays 3112A - 3112B ausgelagert werden.
  • Die PRs 3108A-3108O können den systolischen Arrays 3112A-3112B Eingabedaten in einem komprimierten Format bereitstellen, und die Codecs 3124A-3124B können zum Dekomprimieren der Daten verwendet werden. Wenn Ausgabedaten bereit sind, den PRs 3108A-31080 zur Verfügung gestellt zu werden, können die Daten dekomprimiert bleiben, falls die PRs Operationen an den Daten durchführen und das direkte Lesen komprimierter Daten nicht unterstützen. Falls die PRs 3108A-3108O das Lesen komprimierter Daten unterstützen oder keine zusätzlichen Operationen an den Daten durchführen, können die Ausgabedaten neu codiert werden. Es kann eine Null-basierte Codierung verwendet werden und die Komprimierung kann basierend auf dem Grad der Daten-Sparsity aktiviert oder deaktiviert werden. Alternativ können andere Formen von Codierung basierend auf der Verteilung des zu verarbeitenden oder auszugebenden Datensatzes verwendet werden. Beispielsweise können die Codecs 3124A-3124B dazu konfiguriert sein, Sparse-Daten zu decodieren, die basierend auf einer Null-basierten Komprimierung oder unter Verwendung einer anderen hierin beschriebenen Form von Komprimierung (z. B. Eins-basiert, Zwei-basiert, Nahe-Null, Nahe-Eins, Nahe-Zwei usw.) codiert sind.
  • Wie in 31B gezeigt, veranschaulicht das System 3150 Verarbeitungselemente des systolischen Arrays 3000, wobei das systolische Array dazu konfiguriert ist, komprimierte Sparse-Daten zu decodieren. Wie mit Bezug auf 30 beschrieben, enthält jedes PE 3012AA-3013MN Hardwarelogik, um Berechnungen für Matrixoperationen durchzuführen. A (A0, A1 bis AM) und B (B0, B1 bis BN) sind Elemente von Eingabematrizen, die mit Skalarprodukt-, Matrixmultiplikations-, Multiplikation/Addition- oder Multiplikation-Akkumulation-Operationen assoziiert sind. In einer Ausführungsform ist jedes PE 3012AA-3013MN mit Codecs (3151a, 3151b, ...,3151m; 3152a, 3152b, ...,3152n) assoziiert, um komprimierte Eingabeoperanden zu decodieren, die mit durchzuführenden Operationen assoziiert sind. Die Codecs können dazu konfiguriert sein, Sparse-Daten zu decodieren, die basierend auf einer Null-basierten Komprimierung oder unter Verwendung einer anderen hierin beschriebenen Form von Komprimierung codiert sind.
  • Sparse-Daten eines neuronalen Netzwerks können unter Verwendung einer Vielzahl von Codiertechniken codiert (z. B. komprimiert) werden, wie etwa unter anderem UAV-Tabellencodierung (UAV: Unique Absolute Value - eindeutiger Absolutwert), SM-Codierung (SM: Significance Map - Signifikanzkarte), Tabellencodierung (TE: Table Encoding), UVC-Codierung (UVC: Unique Value Coordinate - eindeutige Wertkoordinate) und Mittelwertcodierung (ME: Mean Encoding). Metadaten für die codierten Daten geben den Typ des für die Daten verwendeten Codierungsformats an. In einer Ausführungsform können spezifische Codierungsformate für spezifische Datentypen, wie etwa Kerneldaten oder Merkmalsdaten, ausgewählt werden. In einer Ausführungsform wird eine statistische Analyse der Daten vor der Codierung durchgeführt, um die Auswahl eines geeigneten Codierers für jeden Datenblock zu ermöglichen. Die Codierung kann eine Null-basierte Codierung, eine Nahe-Null-Codierung oder basierend auf anderen Werten (Einsen, Zweien usw.) sein.
  • In einer Ausführungsform können während der SM-Codierung erzeugte Daten verwendet werden, um die Bereitstellung komprimierter Daten an ein systolisches Tensor-Array zu ermöglichen. Im Null-basierten SM-Codierungsmodus werden nur Werte ungleich null in einem Block codiert. Die Anzahl von Werten ungleich Null in einem Abtastblock wird in dem Header angegeben, gefolgt von einer Signifikanzkarte, die eine Karte der Werte ungleich Null innerhalb des Blocks angibt. Die Werte ungleich Null der Abtastung werden dann in der Reihenfolge ihres Auftretens innerhalb des Stroms codiert.
  • 32A-32B veranschaulichen eine Null-basierte SM-Codierung für Sparse-Daten eines neuronalen Netzwerks gemäß Ausführungsformen. 32A veranschaulicht ein Codierungslayout 3220 für eine Null-basierte SM-Codierung. 32B veranschaulicht die Decodierung eines beispielhaften SM-codierten Bitstroms.
  • Wie in 32A gezeigt, ermöglicht ein Codierungslayout 3220, dass Abtastblöcke von Sparse-Daten eines neuronalen Netzwerks in einem reduzierten Bit-Format codiert werden, das die Datenmenge reduziert, die beim Verarbeiten von neuronalen Netzwerken, die mit den Daten assoziiert sind, übertragen oder gespeichert werden muss. In dem veranschaulichten Codierungslayout 3220 wird die Anzahl von Werten ungleich Null in einem Abtastblock in einem Header 3222 angegeben, gefolgt von einer Signifikanzkarte 3224, die eine Karte der Werte ungleich Null innerhalb des 3224 Blocks angibt. Die Werte 3226 ungleich Null der Abtastung werden in der Reihenfolge ihres Auftretens innerhalb des Stroms codiert.
  • Wie in 32B gezeigt, können codierte Bitstromdaten basierend auf Signifikanzkartendaten decodiert werden. In einer Ausführungsform werden SM-Codierungsmodusdaten beginnend mit dem dritten Byte nach einem Zwei-Byte-Header präsentiert, wobei das Vorhandensein von SM-Codierung durch das erste Bit eines Bitstrom-Headers (nicht gezeigt) am Anfang eines codierten Datenstroms angegeben wird. Die Anzahl der Werte ungleich Null in einem Abtastblock ist im Header 3222 angegeben. In einer Ausführungsform kann sich das Codierungsformat auf einer Pro-Abtastblock-Basis ändern, sodass der Header 3222 auch Metadaten enthalten kann, die angeben, dass die SM-Codierung für den kommenden Block von Abtastungen aktiviert ist. Eine Signifikanzkarte 3224 gibt eine Karte der Werte ungleich Null innerhalb des Abtastblocks an, wobei jedem Wert ein Ein-Bit-Eintrag zugeordnet ist. Die Werte 3226 ungleich Null der Abtastung werden dann in der Reihenfolge ihres Auftretens innerhalb des Stroms codiert. Um Signifikanzkartendaten in den beispielhaften decodierten Bitstrom 3230 zu decodieren, kann die Decodiererlogik zumindest einen Teil eines Ausgabedatenpuffers 3210 auf Null initialisieren. Die Decodiererlogik kann dann die Signifikanzkarte 3224 referenzieren, um zu bestimmen, welche Werte in dem Bitstrom ungleich Null sind. Die Werte ungleich Null können sequentiell entpackt und an Orte im Ausgabedatenpuffer 3210 geschrieben werden, die durch die Signifikanzkarte angegeben werden. Zum Beispiel gibt ein Wert von Null (0b0) in der Signifikanzkarte 3224 an, dass der entsprechende decodierte Wert Null ist. Ein Wert von Eins (0b1) in der Signifikanzkarte 3224 gibt an, dass der entsprechende decodierte Wert dem nächsten nachfolgenden Eintrag in den Werten 3226 ungleich Null in dem codierten Bitstrom entspricht.
  • In einer Ausführungsform kann eine verlustbehaftete Nahe-Null-Codierung aktiviert werden, die Werte, die nahe Null liegen, so codiert, als ob diese Werte Null wären. Während eine gewisse Präzision verloren geht, kann dieser Präzisionsverlust unter bestimmten Umständen für Inferenzdaten akzeptabel sein. Eine verlustbehaftete Nahe-Null-Codierung kann als eine Alternative zu expliziten Gewichtungsabschneideoperationen verwendet werden, die verwendet werden können, um Sparsity in Post-Training-Daten zu induzieren.
  • 33A-33B veranschaulichen eine Spezifizierter-Wert-SM-Codierung für Sparse-Daten eines neuronalen Netzwerks gemäß Ausführungsformen. 33A veranschaulicht ein Codierungslayout 3320 für eine Spezifizierter-Wert-SM-Codierung. 33B veranschaulicht die Decodierung eines beispielhaften Spezifizierter-Wert-SM-codierten Bitstrom.
  • Wie in 33A gezeigt, kann ein Codierlayout 3320 ähnlich dem Codierlayout 3220 verwendet werden, mit einem anderen Header 3322, der angibt, dass die Spezifizierter-Wert-Signifikanzkartencodierung aktiviert ist, und einem spezifizierten Wert 3323, der den Wert spezifiziert, der beim Codieren des Bitstroms übersprungen wird. Die Signifikanzkarte 3324 identifiziert die Orte innerhalb eines Ausgabepuffers, in die die Daten innerhalb der Restwerte 3326 entpackt werden sollten.
  • Wie in 33B gezeigt, können codierte Bitstromdaten basierend auf Signifikanzkartendaten auf eine ähnliche Weise wie in 32B decodiert werden. Der Header 3322 enthält ein Bitfeld, das spezifiziert, dass eine Spezifizierter-Wert-Signifikanzkarte aktiviert ist. Der spezifizierte Wert 3323 identifiziert den Wert, der von der Signifikanzkarte 3324 übersprungen wird. Die Anzahl der Restwerte 3326 in einem Abtastblock ist im Header 3322 angegeben. In einer Ausführungsform kann sich das Codierungsformat auf einer Pro-Abtastblock-Basis ändern, sodass der Header 3322 auch Metadaten enthalten kann, die angeben, dass die Spezifizierter-Wert-SM-Codierung für den kommenden Block von Abtastungen aktiviert ist, und den verwendeten spezifizierten Wert 3323 angeben. Die Signifikanzkarte 3324 gibt die Karte der Restwerte innerhalb des Abtastblocks an, wobei jedem Restwert ein Ein-Bit-Eintrag zugeordnet ist. Die Restwerte 3326 der Abtastung werden dann in der Reihenfolge ihres Auftretens innerhalb des Stroms codiert. Um Spezifizierter-Wert-Signifikanzkartendaten in den beispielhaften decodierten Bitstrom 3330 zu decodieren, kann die Decodiererlogik zumindest einen Teil eines Ausgabedatenpuffers 3310 auf den spezifizierten Wert 3323 initialisieren. Die Decodiererlogik kann dann die Signifikanzkarte 3324 referenzieren, um zu bestimmen, welche Werte in dem Bitstrom Restwerte sind. Die Restwerte können sequentiell entpackt und an Orte im Ausgabedatenpuffer 3310 geschrieben werden, die durch die Signifikanzkarte angegeben werden. Zum Beispiel gibt ein Wert von Null (0b0) in der Signifikanzkarte 3324 an, dass der entsprechende decodierte Wert der spezifizierte Wert 3323 ist. Ein Wert von Eins (0b1) in der Signifikanzkarte 3324 gibt an, dass der entsprechende decodierte Wert dem nächsten nachfolgenden Eintrag in den Restwerten 3326 in dem codierten Bitstrom entspricht.
  • In einer Ausführungsform kann eine verlustbehaftete Codierung mit spezifiziertem Wert aktiviert werden, die Werte, die nahe dem spezifizierten Wert liegen, so codiert, als ob diese Werte gleich dem spezifizierten Wert wären. Während eine gewisse Präzision verloren geht, kann dieser Präzisionsverlust unter bestimmten Umständen für Inferenzdaten akzeptabel sein.
  • Unter Verwendung der obigen Techniken kann ein Fachmann beispielsweise eine Allzweck-Grafikverarbeitungseinheit implementieren, die einen Matrixbeschleuniger umfasst, der dazu konfiguriert ist, Sparse-Matrixoperationen zu beschleunigen. Der Matrixbeschleuniger kann einen Hardware-Decodierer beinhalten, um Eingabedaten einschließlich mehrerer Matrixelemente zu decodieren. Die Eingabedaten können in einem komprimierten Format empfangen und durch den Hardware-Decodierer decodiert werden, bevor sie durch den Matrixbeschleuniger verarbeitet werden. In einer Ausführungsform beinhaltet der Matrixbeschleuniger mehrere Verarbeitungselemente, die in einer Ausführungsform als ein systolisches Array konfiguriert sind. Die mehreren Verarbeitungselemente des systolischen Arrays können Decodierer beinhalten, um Eingabedaten auf einer Pro-Verarbeitungselement-Basis zu decodieren, oder für eine Gruppe von Verarbeitungselementen, die kleiner ist als das gesamte systolische Array.
  • In einer Ausführungsform werden die Daten in einem komprimierten Format empfangen, das basierend auf einer Null-basierten Komprimierung codiert ist. In einer Ausführungsform werden die komprimierten Daten in einem Nahe-Null-Format codiert, in dem Werte innerhalb einer Schwelle von Null auf einen Null-Wert gesetzt werden. In einer Ausführungsform werden die Daten in einem komprimierten Format empfangen, das basierend auf einer Spezifizierter-Wert-Komprimierung codiert ist. In einer Ausführungsform werden die komprimierten Daten in einem Nahe-Spezifizierter-Wert-Format codiert, in dem Werte innerhalb einer Schwelle des spezifizierten Werts auf den spezifizierten Wert gesetzt werden.
  • Block-Sparse-Skalarproduktoperationen
  • Auf dem Gebiet der tiefen neuronalen Netzwerke (DNNs) werden verschiedene Techniken angewendet, um die Rechengeschwindigkeit und/oder -effizienz zu verbessern, während eine akzeptable Genauigkeit der Ergebnisse beibehalten wird. Es wurde festgestellt, dass für einige Typen von DNN-Modellen die Rechenpräzision der Operationen reduziert werden kann, ohne die Genauigkeit des Modells signifikant zu reduzieren. Zusätzlich zur Reduzierung der Rechenpräzision, zum Beispiel durch Trainieren mit 16-Bit-Gleitkommawerten anstelle von 36-Bit-Gleitkommawerten oder Durchführen von Inferenzoperationen unter Verwendung ganzzahliger Werte, können Trainingstechniken angepasst werden, um Sparsity in die Gewichtungswerte einzuführen, die mit einem DNN-Modell assoziiert sind. Sparsity bezieht sich auf den Anteil der Gewichtungen eines DNN, die Nullwerte aufweisen. Eine höhere Sparsity entspricht weniger Gewichtungen, was zu geringeren Rechen- und Speicheranforderungen führt. Bei nullwertigen Gewichtungen können alle unter Verwendung dieser Gewichtungen durchgeführten Multiplikationen umgangen werden und Modelle können unter Verwendung von Sparse-Matrix-Formaten kompakt gespeichert und übertragen werden. Empirische Ergebnisse zeigen, dass DNNs ein hohes Maß an Sparsity mit minimaler oder akzeptabler Genauigkeitsreduzierung tolerieren können. Angesichts dieses Trends wäre es von Vorteil, GPGPU- und Parallelprozessor-Hardware anzupassen, die verwendet wird, um Trainings- und Inferenzoperationen für DNN-Modelle durchzuführen.
  • 34A-34B veranschaulichen Vergleiche zwischen unstrukturierter Sparsity und Block-Sparsity innerhalb von Trainingsdaten für ein neuronales Netzwerk. 34A veranschaulicht einen Vergleich zwischen unstrukturierter Sparsity und Block-Sparsity. 34B veranschaulicht die Blockabschneidung von Gewichtungen für ein neuronales Netzwerk.
  • Wie in 34A gezeigt, kann Sparsity in DNN-Modellen die Form unregelmäßiger Sparsity, wie in Matrix 3402, oder Block-Sparsity, wie in Matrix 3404, annehmen. Unregelmäßige Sparsity wie in der Matrix 3402 kann während des Trainings natürlich auftreten, oder Abschneidetechniken können angewendet werden, um Gewichtungswerte zu nullen, die unter einer minimalen Schwelle liegen. Block-Sparsity wie in Matrix 3404 kann durch Abschneiden auf blockweiser Basis induziert werden. Eine Blockgröße kann definiert werden und Blöcke unterhalb einer minimalen absoluten Größe können abgeschnitten werden.
  • Wie in 34B gezeigt, kann die Gewichtungsabschneidung durchgeführt werden, nachdem ein DNN-Modell trainiert wurde, indem die Gewichtungswerte innerhalb eines Blocks summiert werden und alle Gewichtungen in dem Block auf Null gesetzt werden, falls die absolute Größe der Gewichtungen unter einer Schwelle liegt. Die Matrix 3412 kann in eine Block-Sparse-Matrix 3414 abgeschnitten werden, indem beispielsweise eine Gewichtungsschwelle von 0,4 und ein 4x4-Block verwendet werden. Für jeden 4x4-Block können die Gewichtungen in dem Block summiert werden, und für jeden Block mit einer absoluten Größe, die unter der Schwelle liegt, können seine Gewichtungen auf Null gesetzt werden. Matrixmultiplikationsoperationen, die diese Blöcke beinhalten, können während der Inferenz umgangen werden.
  • In einer Ausführungsform können Block-Sparse-Operationen an einem systolischen Array optimiert werden, indem einer Block-Sparse-Makroanweisung ermöglicht wird, Skalarproduktoperationen an Block-Sparse-Daten auszuführen. Eine Sequenz von Skalarprodukt-Anweisungen (dp4a, dp2a) kann intern innerhalb einer GPGPU als Reaktion auf den Empfang einer Block-Sparse-Makroanweisung (dpXaV) erzeugt werden. In einer Ausführungsform wird ein Bitfeld erzeugt, das den Sparsity-Grad für Zeilen einer Matrix A angibt, die als Eingabe für die Block-Sparse-Makroanweisung bereitzustellen sind. Die Makroanweisung kann das Bitfeld verwenden, um automatisch einen Satz von Anweisungen und Operanden zu erzeugen, um aufeinanderfolgende Skalarproduktoperationen für Elemente der Matrix durchzuführen. Die Skalarprodukt-Anweisung kann verwendet werden, um ein Skalarprodukt aus Zeilenelementen der Matrix A und Spaltenelementen von Matrix B zu erzeugen. Wenn alle Eingabewerte der Matrix A für eine Anweisung Null sind, kann die Skalarprodukt-Anweisung für diese Zeile übersprungen werden. Da das Ergebnis Null sein wird. Wenn ein oder mehrere zu verarbeitende Elemente, aber nicht alle Elemente, der Matrix A Null sind, kann eine Prädikationsmaske verwendet werden, um die Multiplikation für die spezifischen Nullwert-Elemente zu deaktivieren.
  • 35A-35B veranschaulichen eine Skalarprodukt-Anweisung 3500, die durch Skalarprodukt-Logik ausführbar ist. 35A veranschaulicht Felder eines Vier-Elemente-Skalarprodukts mit Akkumulationsanweisung, die durch eine systolische Matrixlogik ausführbar ist, die von einer Ausführungsform bereitgestellt wird. 35B veranschaulicht elementweise Berechnungen, die während der Berechnung des Vier-Elemente-Skalarprodukts mit Akkumulation unter Verwendung der systolischen Matrixlogik durchgeführt werden.
  • Wie in 35A gezeigt, kann ein Vier-Elemente-Skalarprodukt mit Akkumulationsanweisung 3500 verwendet werden, um zu bewirken, dass ein systolischer Matrixbeschleuniger ein Vier-Elemente-Skalarprodukt mit Akkumulation ausführt. In einer Ausführungsform enthält die Anweisung 3500 ein Prädikat-Feld 3502, ein Opcode-Feld 3504, ein Bedingungsmodifikator-Feld 3506, ein Ausführungsgröße-Feld 3508 und Operand-Felder zum Spezifizieren eines Ziels 3510, einer nullten Quelle 3512 (src0), einer ersten Quelle 3514 (src1), einer zweiten Quelle 3516 (src2) und einer systolischen Tiefe 3518 (sTiefe). Das Prädikat-Feld 3502 kann eine Prädikatsmaske 3562 spezifizieren, wie in 35B. Jetzt mit Bezug auf 35B kann die Prädikatsmaske verwendet werden, um einen Ausführungskanal der Anweisung zu aktivieren oder zu deaktivieren, sodass eine Ausgabeerzeugung für ein spezifisches Element deaktiviert wird. In verschiedenen Ausführungsformen kann ein deaktivierter Kanal die Ausführung umgehen oder kann ausgeführt werden, während die Ausführungslogik daran gehindert wird, den mit dem deaktivierten Kanal assoziierten Architekturzustand zu modifizieren. In einer Ausführungsform kann die Ausgabe der Ausführung verworfen werden, ohne festgeschrieben zu werden. Wenn alle Elemente der Prädikatsmaske 3562 null sind, können alle Operationen für die Anweisung umgangen werden. Wenn eine dp4aV-Vektoranweisung verwendet wird, um mehrere dp4as-Anweisungen zu erzeugen, kann die Erzeugung einer dp4as-Anweisung umgangen werden, wenn die Prädikatsmaske 3562 null ist.
  • Erneut mit Bezug auf 35A kann das Opcode-Feld 3504 einen Opcode spezifizieren, der die Anweisung 3500 für die Ausführungslogik identifiziert. In einer Ausführungsform enthält das Opcode-Feld 3504 ein oder mehrere Bits, die, wenn sie aktiviert sind, angeben, dass die Anweisung durch einen Matrixbeschleuniger wie hierin beschrieben (z. B. Tensorbeschleuniger 2723) ausgeführt werden soll. In einer Ausführungsform kann das Opcode-Feld 3504 auch ein oder mehrere Bits enthalten, die spezifizieren, dass die Anweisung 3500 durch eine Spezial-Skalarprodukt-Logik, wie etwa eine Skalarprodukt-Logik (z. B. Skalarprodukt-Logik 1608) innerhalb eines Matrixbeschleunigers, ausgeführt werden soll.
  • Das Bedingungsmodifikator-Feld 3506 kann verwendet werden, um ein Flag-Register basierend auf den internen bedingten Signalen zu setzen, die von der Ausführungs-Pipeline ausgegeben werden, wie etwa Vorzeichen, Null, Überlauf, keine Zahl (NaN) usw. Falls dieses Feld auf 0000 gesetzt ist, werden keine Flag-Register aktualisiert. In einer Ausführungsform beinhalten die unterstützten Bedingungen unter anderem Null oder Gleich, Nicht Null oder Nicht gleich, Größer als, Größer als oder gleich, Kleiner als, Kleiner als oder gleich, Überlauf, und Ungeordnet mit berechnetem NaN. Darüber hinaus kann in einigen Konfigurationen ein Quellmodifikator-Feld aktiviert werden.
  • Die Ausführungsgröße 3508 (Ausf_Größe) spezifiziert die Anzahl der Ausführungskanäle für die Anweisung 3500. Im Fall einer für ein Vier-Elemente-Skalarprodukt-Anweisung kann in einer Ausführungsform die Anzahl der Ausführungskanäle verwendet werden, um eine Anzahl von Paaren von Vektoren mit vier Elementen zu spezifizieren, über die die Berechnung durchgeführt wird.
  • Das Ziel 3510, die nullte Quelle 3512 (src0), die erste Quelle 3514 (src1) und die zweite Quelle 3516 (src2) können verwendet werden, um ein Ziel zu spezifizieren, in das eine Berechnung geschrieben wird, und einen Ort, aus dem Quelldaten abgerufen werden können. In einer Ausführungsform kann das Ziel 3510 ein Register spezifizieren, in das Daten geschrieben werden sollen. In einer Ausführungsform kann das Ziel 3510 ein Skalarregister sein, obwohl das Ziel in einigen Ausführungsformen auch ein Vektorregister sein kann, das die Ausgabe von mehreren Kanälen speichert. Wenn beispielsweise ein einzelner Vier-Elemente-Kanal spezifiziert ist, kann ein einzelnes Skalarprodukt in einen einzelnen Ausgabekanal am Ziel geschrieben werden. Wenn mehrere Vier-Elemente-Kanäle spezifiziert sind, können mehrere Skalarprodukte in ein Vektorzielregister geschrieben werden. Die nullte Quelle 3512, die erste Quelle 3514 und die zweite Quelle 3516 können Register- oder Immediate-Werte sein, die einen oder mehrere Kanäle von Quelldaten enthalten, wobei jeder Kanal vier Elemente aufweist, die durch die Skalarprodukt-Logik zu verarbeiten sind, wie etwa mit Quelle 2900, Quelle 2901 und Quelle 2902 wie in 29A-29B. In einer Ausführungsform können die vier Elemente für jede Quelle einem Verarbeitungselement des systolischen Arrays 3000 wie in 30 bereitgestellt werden. Die systolische Tiefe 3518 (sTiefe) kann verwendet werden, um die Anzahl systolischer Schichten zu spezifizieren, die zum Verarbeiten der Eingabedaten verwendet werden sollen. In einer Ausführungsform kann die systolische Tiefe 3518 als Immediate-Wert bereitgestellt werden.
  • In einigen Ausführungsformen können zusätzlichen Felder vorhanden sein, die sich von den veranschaulichten unterscheiden. Beispielsweise ist in einer Ausführungsform ein Quellenmodifikator-Feld vorhanden, das die numerische Modifikation eines Quelloperanden spezifiziert. Der Wert jedes Datenelements eines Quelloperanden kann vor der Lieferung an die Ausführungs-Pipeline optional seinen Absolutwert annehmen und/oder sein Vorzeichen invertiert haben. Der Absolutwertmodifikator kann vor dem Negativ-Modifikator angewendet werden, sodass ein garantiert negativer Wert erzeugt werden kann. In einer Ausführungsform ist ein Sättigung-Feld vorhanden, das verwendet werden kann, um die Zielsättigung zu steuern. Wenn die Sättigung aktiviert ist, werden die Ausgabedaten an das Zielregister gesättigt. Die spezifische Sättigungsoperation hängt vom Zieldatentyp ab. Sättigung ist eine Operation, die jegliche Daten, die außerhalb des Sättigungszielbereichs für den Datentyp liegen, in den nächstliegenden repräsentierten Wert im Zielbereich umwandelt.
  • Elementweise Operationen der Anweisung 3500 sind in 35B gezeigt. In einer Ausführungsform kann ein Hardwarepuffer, ein temporäres Register oder ein internes Register einer Funktionseinheit innerhalb der Skalarprodukt-Logik des systolischen Matrixbeschleunigers Elemente A3-A0 eines Kanals 3524 der ersten Quelle 3514 speichern. Ein zusätzlicher Hardwarepuffer oder zusätzliches temporäres Register kann Elemente B3-B0 eines Kanals 3526 der zweiten Quelle 3516 speichern. Die Elemente können in eine Funktionseinheit (z. B. Funktionseinheit 2912 von 29A) der Skalarprodukt-Logik innerhalb eines hierin beschriebenen systolischen Tensorarrays geladen werden. Ein Satz von Multiplikatoren (z. B. Multiplikatoren 2923A-2923D von 29B) kann einen Satz von Produkten 3534 erzeugen. Der Satz von Produkten kann in einen Addierer (z. B. Addierer 2924 von 29B) geladen werden.
  • Der Addierer kann eine Summe des Satzes von Produkten 3535 erzeugen, die mit einem vorhandenen Akkumulatorwert 3522 (z. B. C0) akkumuliert werden kann. Der vorhandene Akkumulatorwert 3522 kann ein initialer Akkumulatorwert sein, der über die Anweisung 3500 bereitgestellt wird, oder kann ein Akkumulatorwert sein, der von einer vorherigen systolischen Schicht bereitgestellt wird. Die akkumulierte Summe des Satzes von Produkten 3535 kann dann an ein Ziel 3538 ausgegeben werden, das das durch die Anweisung 3500 spezifizierte Ziel 3510 sein kann, oder kann als der initiale Akkumulatorwert 3536 der nächsten systolischen Schicht geladen werden. Das Ziel für die akkumulierte Summe, die durch eine systolische Schicht ausgegeben wird, kann basierend darauf bestimmt werden, ob die gegebene systolische Schicht die letzte Schicht in der Kette ist, wobei die Anzahl von Schichten durch die systolische Tiefe spezifiziert wird.
  • 36A-36B veranschaulichen eine durch Skalarprodukt-Logik ausführbare Anweisung 3600 gemäß hierin beschriebenen Ausführungsformen. 36A veranschaulicht Felder eines Zwei-Elemente-Skalarprodukts mit Akkumulationsanweisung, die durch eine systolische Matrixlogik ausführbar ist, die von einer Ausführungsform bereitgestellt wird. 36B veranschaulicht elementweise Berechnungen, die während der Berechnung des Zwei-Elemente-Skalarprodukts mit Akkumulation unter Verwendung der systolischen Matrixlogik durchgeführt werden.
  • 36A veranschaulicht Felder eines Zwei-Elemente-Skalarprodukts mit Akkumulationsanweisung 3600, die, wenn sie ausgeführt wird, einen systolischen Matrixbeschleuniger veranlasst, ein Zwei-Elemente-Skalarprodukt mit Akkumulierung auszuführen. In einer Ausführungsform enthält die Anweisung 3600 ein Prädikat-Feld 3602, ein Opcode-Feld 3604, ein Bedingungsmodifikator-Feld 3606, ein Ausführungsgröße-Feld 3608 und Operand-Felder zum Spezifizieren eines Ziels 3610, einer nullten Quelle 3612 (src0), einer ersten Quelle 3614 (src1), einer zweiten Quelle 3616 (src2) und einer systolischen Tiefe 3618 (sTiefe). Jedes der veranschaulichten Felder kann denen der Anweisung 3500 ähnlich sein, außer dass das Opcode-Feld 3604 ein Zwei-Elemente-Skalarprodukt spezifiziert und jeder Operand einen Vektor mit zwei gepackten Elementen anstelle von vier spezifiziert.
  • Das Prädikat-Feld 3602 kann eine Prädikatsmaske 3662 von 36B spezifizieren. Jetzt mit Bezug auf 36B kann die Prädikatsmaske 3662 verwendet werden, um einen Ausführungskanal der Anweisung zu aktivieren oder zu deaktivieren, sodass eine Ausgabeerzeugung für ein spezifisches Element deaktiviert wird, wie mit dem Prädikat-Feld 3502 und der Prädikatsmaske 3562. Die veranschaulichte Prädikatsmaske 3662 gibt an, dass das Element A0 ungleich null ist, während das Element A1 null ist. Für diesen Satz von Eingaben der Matrix A kann eine Anweisung erzeugt werden, um die Skalarproduktoperation durchzuführen und A0 des Eingabekanals 3624 mit B0 des Kanals 3626 zu multiplizieren. Es kann ein Satz von Produkten 3634 erzeugt werden, der nur A0*B0 enthält, der dann mit einem vorhandenen Akkumulatorwert 3622 (z. B. C0) multipliziert werden kann. Die akkumulierte Summe des Satzes von Produkten 3635 kann dann an ein Ziel 3638 ausgegeben werden, das das durch die Anweisung 3600 spezifizierte Ziel 3610 sein kann, oder kann als der initiale Akkumulatorwert 3636 der nächsten systolischen Schicht geladen werden. Das Ziel für die akkumulierte Summe, die durch eine systolische Schicht ausgegeben wird, kann basierend darauf bestimmt werden, ob die gegebene systolische Schicht die letzte Schicht in der Kette ist, wobei die Anzahl von Schichten durch die systolische Tiefe spezifiziert wird.
  • 37A-37D veranschaulichen eine Anweisung und eine assoziierte Hardwarelogik, um eine Sparse-Skalarproduktoperation mit Nullüberspringen für eine Sparse-Eingabe zu ermöglichen. 37A veranschaulicht ein Format für eine Sparse-Skalarprodukt-Anweisung 3700. 37B veranschaulicht die Hardwaredecodierlogik 3710, um die Decodierung der Sparse-Skalarprodukt-Anweisung 3700 zu ermöglichen. 37C veranschaulicht die Ausführungslogik 3720, die dazu konfiguriert ist, die Decodierung und Ausführung der hierin beschriebenen Sparse-Skalarprodukt-Anweisung 3700 zu ermöglichen. 37D veranschaulicht ein Verfahren 3750, das durch Hardware ausgeführt wird, die dazu konfiguriert ist, eine Sparse-Skalarprodukt-Anweisung auszuführen.
  • Wie in 37A gezeigt, stellt eine Ausführungsform Hardwareunterstützung für eine Sparse-Skalarprodukt-Anweisung (dpXaV-Anweisung 3700) bereit und führt eine Sequenz von Skalarprodukt-Anweisungen mit automatischem Nullüberspringen für einen oder mehrere Eingabevektoren durch. Die dpXaV-Anweisung ist repräsentativ für eine Vier-Elemente-Sparse-Skalarprodukt-Anweisung (dp4aV) und eine Zwei-Elemente-Sparse-Skalarprodukt-Anweisung (dp2aV). Das Format für die dpXaV-Anweisung 3700 beinhaltet ein Prädikat (Präd 3702), den Anweisungs-Opcode mit einer angehängten Wiederholungszählung 3704 (dpXaV.rcount), einen Zieloperanden (Ziel 3706) und mehrere Quelloperanden (src0 3707, src1 3708, src2 3709). In einer Ausführungsform wird der Prädikatwert basierend auf dem Flag-Register bestimmt, wobei die Bits der Prädikatsmaske eine Prädikation über ein Array von einzelnen Skalarprodukt-Anweisungen und nicht ein Array von Kanälen anwenden. Dementsprechend kann die Prädikatsmaske verwendet werden, um die Erzeugung spezifischer Anweisungen in dem Satz von Anweisungen, der durch die dpXaV-Anweisung 3700 repräsentiert wird, zu aktivieren oder zu deaktivieren. Für eine gegebene erzeugte Anweisung kann die elementweise Prädikation verwendet werden, um Operationen für ein spezifisches Element der Matrix A zu deaktivieren.
  • In einer Ausführungsform wird die dpXaV-Anweisung 3700 als eine Hardware-Makroanweisung implementiert, die während der Decodierung in mehrere zusätzliche Anweisungen erweitert wird. In einer solchen Ausführungsform gibt der Wert der Wiederholungszählung 3704 die Anzahl von Anweisungen an, auf die innerhalb der Ausführungsressource erweitert werden soll. Zum Beispiel kann die in Tabelle 5 unten gezeigte dp4aV.8-Anweisung innerhalb einer Ausführungsressource in mehrere Skalarproduktoperationen erweitert werden. Tabelle 5 - Beispielhafte Sparse-Skalarprodukt-Anweisung
    dp4aV.8 r34.0<1>:f r34.0<1,0>:f r10.0<1,0>:f r76.0<1>:f
  • Für die Anweisung in Tabelle 5 oben beträgt die Wiederholungszählung 3704 acht. Die gelieferten Operanden repräsentieren die initialen Operanden für die erste Anweisung in dem Satz von erweiterten Anweisungen. Die Operanden für die nachfolgenden Anweisungen werden während der Erweiterung erzeugt. Die Operandenerweiterung nutzt einen Block aufeinanderfolgender Register für das <Ziel> 3706 und die <src0> 3707 und aufeinanderfolgende Unterregister für src2 3709, wobei die Anzahl aufeinanderfolgender Register/Unterregister basierend auf dem Wert der Wiederholungszählung 3704 bestimmt wird. Basierend auf dem Wert des Flag-Registers kann die Erweiterung für spezifische Anweisungen in dem Satz von Anweisungen umgangen werden, zum Beispiel in dem Fall, dass NullÜberspringen für Sparse-Eingaben durchgeführt wird.
  • Wie in 37B gezeigt, wird die Anweisungserweiterung während der Decodierung der dpXaV-Anweisung in einer Ausführungsform durchgeführt, obwohl andere Implementierungstechniken in anderen Ausführungsformen verwendet werden können, wie etwa über eine direkte Ausführung der Anweisung durch die Ausführungsstufe der Anweisungsausführungs-Pipeline. In einer Ausführungsform kann die Anweisungsdecodierungslogik 3710 innerhalb einer Verarbeitungsressource zusätzlich zu der herkömmlichen Anweisungsdecodierungslogik einen Zähler/eine Zustandsmaschine 3711, einen Prioritätscodierer 3712, einen Anweisungsgenerator 3713 und einen Operandengenerator 3714 beinhalten. Der Zähler/die Zustandsmaschine 3711 speichert Zählerwerte und den Decodierungszustand zur Verwendung während der Erweiterung einer dpXaV-Anweisung. Der Prioritätscodierer 3712 wird verwendet, um das Prädikat zu scannen, um das erste aktivierte Bit zu bestimmen, das die erste zu erzeugende Skalarprodukt-Anweisung angibt.
  • Die vorgeschlagene dpXaV-Anweisung kann in der Ausführungseinheit implementiert werden, indem ein Zähler/eine Zustandsmaschine in der Decodierungsstufe der ALU-Pipeline hinzugefügt wird und eine Sequenz von Skalarprodukt-Anweisungen erzeugt wird. Ein Prioritätscodierer 3712 scannt die Prädikatsmaske, um das erste gesetzte Bit zu finden. Anweisungen werden durch den Anweisungsgenerator 3713 erzeugt, falls das entsprechende Bit für diese Anweisung im Prädikatsbitfeld gesetzt ist. Der Operandengenerator 3714 erzeugt dann die entsprechenden Operandenwerte basierend auf den initialen Operandenregister- und Unterregisterwerten und auf den Bitpositionen, die innerhalb der Prädikatsmaske gesetzt sind.
  • Wie in 37C gezeigt, kann die Ausführungslogik 3720 innerhalb einer Multithread-Verarbeitungsressource dazu konfiguriert sein, eine dpXaV-Anweisung wie hierin beschrieben zu erweitern und auszuführen. Die Ausführungslogik 3720 kann in einer Multithread-Verarbeitungsressource gefunden werden, wie etwa einer Ausführungseinheit, einer Berechnungseinheit oder einem Streaming-Multiprozessor, wie hierin beschrieben. In einer Ausführungsform kann ein Satz von Anweisungswarteschlangen 3722A - 3722N N Sätze von Anweisungen speichern, die zur Ausführung durch N Threads der Ausführungslogik 3720 anstehen. Jeder Thread weist eine assoziierte Vordecodierungsstufe 3724A-3724N auf, die die Ausführung für den Thread anhält, bis Abhängigkeiten für die aktuelle Anweisung gelöscht sind. Ein Thread wird als bereit markiert, wenn keine Abhängigkeiten für die aktuelle Anweisung bestehen. Nach der Freigabe kann ein Thread an dem Arbitrierungsprozess teilnehmen, der einen Thread zur Versendung in die Ausführungs-Pipeline einer der ALUs auswählt.
  • Die jeweiligen Arbiter 3726A-3726M für jede ALU können einen oder mehrere bereite Threads basierend auf der Verfügbarkeit von Ausführungsressourcen innerhalb einer ALU auswählen. Die Anweisungen für die ausgewählten Threads werden dann an die Ausführungs-Pipeline der ausgewählten ALU versendet. Die Ausführungs-Pipeline-Stufen für die veranschaulichten ALUs beinhalten Decodierstufen 3728A-3728M, Registerlesestufen 3730A-3730M, Ausführungsstufen 3732A-3732M und Rückschreibstufen (WB-Stufen) 3734A-3734M. In einer Ausführungsform kann eine einzelne dpXaV-Anweisung in mehrere Skalarprodukt-Anweisungen innerhalb einer Decodierstufe 3728A-3728M der ALU, die die Anweisung empfängt, erweitert werden.
  • In einer Ausführungsform ist die Anzahl von ALUs innerhalb der Ausführungslogik 3720 kleiner als die Anzahl von Threads, die durch die Ausführungslogik 3720 ausgeführt werden können. In einer Ausführungsform können mehrere Anweisungen an eine einzelne ALU ausgegeben werden. In einer Ausführungsform kann nur ein Teilsatz verfügbarer ALUs für die dpXaV-Anweisungserweiterung konfiguriert werden, und solche Anweisungen werden durch diese spezifischen ALUs ausgeführt. Die Gesamtanzahl von Takten, die die Ausführungslogik 3720 verbraucht, um eine dpXaV-Anweisung auszuführen, hängt von der Anzahl von Takten pro Skalarprodukt-Anweisung, der Wiederholungszählung und der Anzahl übersprungener Anweisungen ab.
  • 37D zeigt ein Verfahren 3750 zum Ermöglichen der Ausführung einer Sparse-Skalarprodukt-Anweisung. Das Verfahren 3750 kann durch die Logik einer Berechnungs- oder Grafikprozessor-Pipeline eines hierin beschriebenen Grafikprozessors oder Parallelprozessors durchgeführt werden. Zum Beispiel kann das Verfahren 3750 durch die Ausführungslogik 3720 von 37C unter Verwendung der Anweisungsdecodierlogik 3710 von 37B ausgeführt werden. Das Verfahren 3750 kann verwendet werden, um die Ausführung einer Hardware-Makroanweisung zu ermöglichen, wie etwa der dpXaV-Anweisung 3700 von 37A und/oder wie hierin beschrieben.
  • In einer Ausführungsform beinhaltet das Verfahren 3750 das Durchführen einer Operation zum Abrufen einer Hardware-Makroanweisung über die Hardwarelogik des Grafik- oder Parallelprozessors (3751). Die Hardware-Makroanweisung weist eine Prädikatsmaske, eine Wiederholungszählung und einen Satz von initialen Operanden (<Ziel>, <src0>, <src1>, <src2>) auf. Die Hardware-Makroanweisung ist dazu konfiguriert, eine oder mehrere Skalarproduktoperationen an Eingabedaten durchzuführen, die mit einem Satz von Matrizen assoziiert sind. Das Verfahren 3750 beinhaltet zusätzlich das Durchführen von Operationen zum Decodieren der Hardware-Makroanweisung (3752). In einer Ausführungsform kann die abgerufene Hardware-Makroanweisung in einer Anweisungswarteschlange gespeichert werden, bis die Logik einer Vordecodierungsstufe der Anweisungsausführungs-Pipeline (z. B. Vordecodierung 3724A-3724N) bestimmt, dass Abhängigkeiten, wie etwa assoziierte Lade- oder Vergleichsanweisungen, erfüllt sind. Sobald die Abhängigkeiten erfüllt sind, kann die Anweisung automatisch zur Decodierung durch die Decodierlogik einer hierin beschriebenen Verarbeitungsressource übergeben werden.
  • Die Decodierungsoperationen können einen Satz von Hardware-Anweisungen, die zur Ausführung zu erzeugen sind, beinhalten oder zumindest teilweise zu deren Bestimmung durchgeführt werden. Beispielsweise kann für jedes aktivierte Bit in der Prädikatsmaske eine Skalarprodukt-Anweisung erzeugt werden. Die Prädikatsmaske kann basierend auf Eingaben generiert werden, die in Unterregistern gespeichert sind, die dem Eingabeoperanden der Matrix A entsprechen, der zum Beispiel die <src1>-Eingabe sein kann. Die spezifischen Eingaben, die spezifischen Matrizen entsprechen können, können je nach Implementierung variieren. Zum Beispiel kann eine Vergleichsanweisung verwendet werden, um Bits in einem Flag-Register zu setzen, indem die Daten, die als die <src1>-Eingabe zu verwenden sind, mit Null verglichen werden. Das Flag-Register kann dann als die Prädikatsmaske verwendet werden. Die Prädikatsmaske und die Wiederholungszählung können dann verwendet werden, um den Satz von Hardware-Anweisungen zur Ausführung zu erzeugen (3753). Die Anweisungen können durch einen Anweisungsgenerator 3713 wie in 37B erzeugt werden. Die maximale Anzahl von zu erzeugenden Anweisungen kann basierend auf der Wiederholungszählung bestimmt werden. Die Erzeugung spezifischer Hardware-Anweisungen wird basierend auf der Deaktivierung durch ein assoziiertes Bit innerhalb der Prädikatsmaske umgangen.
  • Die durch die erzeugten Anweisungen im Anweisungssatz zu verwendenden spezifischen Operanden können basierend auf der Prädikatsmaske und dem Satz von initialen Operanden bestimmt werden (3754). Operanden für die Anweisungen können durch einen Operandengenerator 3714 wie in 37B erzeugt werden. Aufeinanderfolgende zusammenhängende Register werden für <Ziel>- und<src0>-Operanden verwendet und aufeinanderfolgende Unterregister werden für <src1>-Operanden verwendet. Für umgangene Anweisungen werden keine Operanden erzeugt. Die Anweisungsausführungs-Pipeline des Grafik- oder Parallelprozessors kann dann den Satz von Hardware-Anweisungen atomar ausführen (3755). Atomare Ausführung gibt an, dass eine oder mehrere Operationen, die während der Ausführung des Anweisungssatzes ausgeführt werden, atomar ausgeführt werden, sodass die Anweisungen in dem Anweisungssatz als eine einzelne Anweisung betrachtet werden. Die spezifische Anzahl von Taktzyklen, die durch die Ausführung der Hardware-Makroanweisung verbraucht werden, kann basierend auf der Zykluszahl zum Ausführen einer einzelnen Multiplikation-Addition-Operation, der mit der Anweisung assoziierten Wiederholungszählung und der Anzahl von Anweisungen oder Operationen, die aufgrund von Sparse-Eingabedaten umgangen werden, variieren. Die Anweisungsausführungs-Pipeline des Grafik- oder Parallelprozessors kann dann die Hardware-Makroanweisung nach Beendigung jeder Anweisung in den Satz von Hardware-Anweisungen zurückziehen (3756).
  • Es ist zu beachten, dass die Anzahl von Ausführungszyklen abhängig von der Sparseness (Spärlichkeit) der Eingabe in eine Skalarprodukt-Anweisung variieren kann. Somit kann die Latenzzeit für die Anweisung möglicherweise nicht zur Kompilierzeit bestimmt werden, um die Planung der nächsten abhängigen Anweisung zu ermöglichen. Dementsprechend werden die mehreren Anweisungen oder Operationen, die durch eine Skalarprodukt-Anweisung ausgeführt werden, vom Compiler und der Scheduling-Hardware als eine einzelne atomare Anweisung angesehen. Somit werden für einen Satz aufeinanderfolgender abhängiger Skalarprodukt-Anweisungen die Anweisungen der Reihe nach ausgeführt, sodass eine erste Skalarprodukt-Anweisung abgeschlossen ist, bevor eine nachfolgende abhängige Anweisung in die Ausführungs-Pipeline eintritt.
  • Unter Verwendung der obigen Techniken kann ein Fachmann beispielsweise eine Allzweck-Grafikverarbeitungseinheit implementieren, die Folgendes umfasst: einen Grafikprozessor, der einen Anweisungsabrufer zum Abrufen einer Hardware-Makroanweisung mit einer Prädikatsmaske, einer Wiederholungszählung und einem Satz von initialen Operanden umfasst, wobei die Hardware-Makroanweisung eine oder mehrere Skalarproduktoperationen an einer Eingabe durchführen soll, die mit einem Satz von Matrizen assoziiert ist. Die Skalarproduktoperationen können Zwei-Elemente-Skalarproduktoperationen oder Vier-Elemente-Skalarproduktoperationen sein. Die Allzweck-Grafikverarbeitungseinheit enthält zusätzlich einen Anweisungsdecodierer, um die Hardware-Makroanweisung zu decodieren und einen Satz von Hardware-Anweisungen zu erzeugen, um eine oder mehrere Multiplikations- und Addieroperationen durchzuführen, wobei der Satz von Hardware-Anweisungen basierend auf der Prädikatsmaske und der Wiederholungszählung erzeugt wird. Die Allzweck-Grafikverarbeitungseinheit enthält zusätzlich eine Verarbeitungsressource zum Ausführen des Satzes von Hardware-Anweisungen. Die Hardware-Makroanweisung kann nach Beendigung des Satzes von Hardware-Anweisungen zurückgezogen werden.
  • Unter Verwendung der obigen Techniken kann ein Fachmann beispielsweise eine Allzweck-Grafikverarbeitungseinheit implementieren, die dazu konfiguriert ist, ein Verfahren durchzuführen, das Folgendes umfasst: Abrufen einer Hardware-Makroanweisung mit einer Prädikatsmaske, einer Wiederholungszählung und einem Satz von initialen Operanden, wobei die initialen Operanden einen Zieloperanden und mehrere Quelloperanden beinhalten. Die Wiederholungszählung soll eine maximale Anzahl von Hardware-Anweisungen angeben, die für den Satz von Hardware-Anweisungen zu erzeugen sind. Die Prädikatsmaske gibt an, welche Anweisungen im Satz von Anweisungen erzeugt oder umgangen werden sollen. Die Prädikatsmaske kann über einen Vergleich zwischen Null und jedem Element erzeugt werden, das mit einem Quelleingabeoperanden assoziiert ist. Die Hardware-Makroanweisung ist dazu konfiguriert, eine oder mehrere Skalarproduktoperationen an Eingabedaten durchzuführen, die mit einem Satz von Matrizen assoziiert sind.
  • Unter Verwendung der obigen Techniken kann ein Fachmann beispielsweise ein Grafikverarbeitungssystem einschließlich Verarbeitungslogik zum Durchführen des oben angegebenen Verfahrens implementieren. Es kann auch ein Grafikverarbeitungssystem implementiert werden, das eine Speichervorrichtung beinhaltet, die mit einer Allzweck-Grafikverarbeitungseinheit wie oben beschrieben gekoppelt ist.
  • Tiefenweiser Adapter für ein systolisches Array
  • Die hierin beschriebenen systolischen Arrays leiden an einer verringerten Effizienz bei der tiefenweisen Faltung. Eine Ausführungsform stellt eine Adapterschaltung bereit, um eine Bild-zu-Spalten-Transformation an Aktivierungsdaten durchzuführen, bevor die Aktivierungsdaten an das systolische Array bereitgestellt werden.
  • 38A-38B vergleichen 3D-Faltung mit tiefenweiser Faltung. 38A veranschaulicht eine 3D-Faltung. 38B veranschaulicht die tiefenweise Faltung. Die tiefenweise 3D-Faltung kann auf ähnliche Weise wie die 2D-Faltung durchgeführt werden, die in 28 gezeigt ist, mit der Ausnahme, dass die Eingabeaktivierungen und Gewichtungen/Faltungskernel 3D-Matrizen sind. Eine 3D-Faltung kann beispielsweise für RGB-Bilder mit roten, grünen und blauen Farbkanälen durchgeführt werden.
  • Wie in 38A gezeigt, kann bei einem gegebenen Eingabebild 3802 mit 12x12 Pixeln und drei Farbkanälen eine 5x5x3-Faltungsoperation 3803 an dem Eingabebild 3802 unter Verwendung eines 5x5-Pixel-Dreikanal-Faltungskernel 3804 durchgeführt werden. Die Ausgabe 3805 der 5×5×3-Faltungsoperation 3803 an dem 12×12×3-Eingabebild 3802 ist ein 8×8×1-Bild. Falls gewünscht, können zusätzliche Faltungsoperationen mit verschiedenen Kerneln durchgeführt werden, um ein Ausgabebild mit einer größeren Anzahl von Kanälen zu erzeugen. Um beispielsweise die Anzahl der Ausgabekanäle auf 256 zu erweitern, können 256 separate 5×5×3-Kernel verwendet werden, um 256 8×8×1-Ausgabebilder zu erzeugen, die zu einem 8×8×256-Ausgabebild kombiniert werden können. Für jeden Schritt der 5×5×3-Faltungsoperation 3803 werden mindestens 5×5×4 = 75 Multiplikationsoperationen durchgeführt. Um die 8×8×1-Ausgabe 3805 zu erzeugen, werden 8×8 = 64 Schritte für mindestens 64×75 = 4.800 Multiplikationen durchgeführt. Um die Ausgabe auf ein 256-Kanal-Ausgabebild zu erweitern, werden 256×4800 = 1.228.800 Multiplikationen durchgeführt.
  • Wie in 38B gezeigt, kann eine tiefenweise Faltung durchgeführt werden, um das gleiche Ausgabebild mit einer reduzierten Anzahl von Berechnungen zu erhalten, insbesondere wenn eine Ausgabekanalerweiterung durchgeführt werden soll. Um eine tiefenweise Faltung bei gegebenem Eingabebild 3802 mit 12×12 Pixeln und drei Farbkanälen durchzuführen, kann das Eingabebild 3802 in drei 12×12×1 Eingabebilder 3812a-3812c unterteilt werden. Der 5×5×5-Kernel 3804 kann in drei 5×5×1-Kernel 3814a-3814c unterteilt werden. Dann kann eine tiefenweise Faltungsoperation 3813 durchgeführt werden, bei der jeder 5×5×1-Kernel einen Kanal der Eingabebilder iteriert, um drei 8×8×1-Ausgabebilder 3815a - 3815c zu erzeugen. Die Ausgabebilder 3815a-3815c können dann als Eingabe in eine punktweise Faltungsoperation 3823 unter Verwendung eines 1×1×3-Kernels 3824 verwendet werden, um dieselbe 8×8×1-Ausgabe 3805 als Standardfaltung zu erzeugen. Die Ausgabekanalerweiterung kann während der punktweisen Faltungsstufe durchgeführt werden, in der ein 8×8×256-Ausgabebild unter Verwendung von 256 1×1×3-Kerneln erzeugt werden kann, um ein 8×8×256-Ausgabebild zu erzeugen. Um das 8×8×1-Ausgabebild 3805 unter Verwendung der tiefenweisen Faltung zu erzeugen, werden mindestens 4.800 Multiplikationen in der tiefenweisen Faltungsstufe plus zusätzlich 192 Multiplikationen in der punktweisen Faltungsstufe verwendet. Um jedoch eine Ausgabeerweiterung auf 256 Kanäle durchzuführen, werden insgesamt 53.952 Multiplikationen durchgeführt, im Gegensatz zu 1.228.800 Multiplikationen für die Standardfaltung. Somit wäre es von Vorteil, wenn eine Matrixeinheit oder ein Tensorarray, die/das verwendet wird, um CNN-Operationen zu beschleunigen, eine effiziente Unterstützung für die tiefenweise Faltung bietet.
  • 39A-39C veranschaulichen ein System 3900 einschließlich eines systolischen Tensorarrays 2808 und eines Bild-zu-Spalten-Adapters 3910 zur Verwendung während der tiefenweisen Faltung. Wie in 39A gezeigt, beinhaltet das System 3900 in einer Ausführungsform ein systolisches Array 2808 wie in 28 und eine allgemeine Registerdatei 3924 wie beispielsweise in der allgemeinen Registerdatei 1824 wie in 18B, der Registerdatei 1906 wie in 19 oder einem Teil der gemeinsam genutzten Registerdatei 3114 wie in 31. Das systolische Tensorarray 2808 kann auch Aspekte des systolischen Arrays 1912 wie in 19, des systolischen Arrays 3000 wie in 30A-30B und/oder des systolischen Arrays 3112A-3112B beinhalten. Das System 3900 beinhaltet auch einen Bild-zu-Spalten-Adapter 3910, der eine Schaltungsanordnung zum Umwandeln der Daten für ein Eingabebild für eine Faltungsoperation, die als ein Dreikanal-RGB-Bild konfiguriert sein kann, in spaltenformatierte Daten enthält. In den spaltenformatierten Daten werden die Daten für die mehreren Eingabekanäle getrennt und in eine transformierte Eingabe 3932 neu formatiert. Die Verwendung der transformierten Eingabe 3932 verbessert die Recheneffizienz von tiefenweisen Faltungsoperationen, wenn sie über das systolische Array 2808 durchgeführt werden. Der Bild-zu-Spalten-Adapter 3910 kann als ein Satz von Eingangsports implementiert sein, die dazu konfiguriert sind, Vektor- und/oder gepackte Daten aus der allgemeinen Registerdatei 3924 zu lesen, die auf einen Satz von Ausgangsports abgebildet sind, die mit dem systolischen Tensorarray 2808 gekoppelt sind. Die Abbildung der Eingangsports auf die Ausgangsports kann basierend auf den Besonderheiten der zu transformierenden Eingabeaktivierungsmatrix angepasst werden.
  • Beim Durchführen einer tiefenweisen Faltung werden Gewichtungen 3925 als SRC2-Eingabe 3926 bereitgestellt und Eingabeaktivierungsdaten 3930 werden durch den Bild-zu-Spalten-Adapter 3910 geleitet, bevor sie als SRC1-Eingabe 3931 als transformierte Eingabe 3932 bereitgestellt werden. Es wird eine inkrementelle dpas-Anweisung (dpas: Skalarprodukt, Akkumulieren, systolisch) verwendet, die ein einzelnes Eingaberegister der transformierten Eingabe 3932 in SRC1 3931 pro Anweisung lädt. Abhängig von der Größe der Eingabedaten können mehrere Iterationen der dpas-Anweisung verwendet werden, um einen gesamten Eingabesatz zu verarbeiten. Es wird auch ein Initialisierungsmodus verwendet, in dem ein ganzer initialer Satz von Registern einer transformierten Eingabe 3932 als SRC1-Eingabe 3931 geladen wird. Aufeinanderfolgende Iterationen der inkrementellen dpas-Anweisung können durchgeführt werden, bis die Faltung für den gesamten Satz von Eingabeaktivierungen durchgeführt ist.
  • Wie in 39B gezeigt, ist keine signifikante Transformation für Gewichtungseingaben erforderlich. Die Gewichtungseingabe kann während der inkrementellen dpas-Initialisierungsoperation aus der allgemeinen Registerdatei 3924 gelesen werden. Aufeinanderfolgende Lesevorgänge von Gewichtungsdaten können umgangen werden und eine tiefenweise Gewichtungsmatrix 3928 kann für jede Iteration innerhalb des systolischen Tensorarrays 2808 erzeugt werden. Um die tiefenweise Gewichtungsmatrix 3928 zu konstruieren, werden die SRC2-Gewichtungen mit Nullen an den entsprechenden Stellen konstruiert, sodass nur die richtigen Zeilen von Gewichtungen pro Zyklus verwendet werden. Die richtigen Zeilen von Gewichtungen, die für die tiefenweise Faltungsoperation zu verwenden sind, werden in der tiefenweisen Gewichtungsmatrix 3928 in jedem Zyklus entlang eines Gleitfensters 3927 nach unten bewegt. Die richtigen Zeilen können schließlich die Oberseite der tiefenweisen Gewichtungsmatrix 3928 umschließen.
  • Wie in 39C gezeigt, werden die Werte der Eingabeaktivierung 3930 gemäß einer Bild-zu-Spalten-Transformation 3940 umgestellt, wenn die Daten aus der allgemeinen Registerdatei 3924 gelesen werden. Die Bild-zu-Spalten-Transformation 3940 positioniert Matrixelemente der Eingabeaktivierung 3930 neu, um die Daten der Eingabeaktivierung 3930, die ein Mehrkanalbild sein kann, in eine transformierte Eingabe 3932 in Form einer 2D-Matrix zu trennen, in der jeder der Kanäle getrennt und nebeneinander angeordnet werden. Die spezifische Art der Bild-zu-Spalten-Transformation 3940 kann basierend auf der Anzahl von Eingabedatenkanälen, der Größe des Faltungskernels und der Ziel-Ausgabetiefe variieren.
  • 40 veranschaulicht ein Verfahren 4000 zum Durchführen einer tiefenweisen Faltung an einem systolischen Array. Das Verfahren 4000 kann durch Hardware- oder Firmware-Logik eines systolischen Arrays in Verbindung mit einer allgemeinen Registerdatei und einem Bild-zu-Spalten-Adapter, wie zum Beispiel in 39A veranschaulicht, unter Verwendung von Datentransformationen, die in 39B und 39C veranschaulicht sind, durchgeführt werden.
  • Das Verfahren 4000 beinhaltet Logik, die mit einem systolischen Array assoziiert ist, um eine initiale Eingabe zu laden, die einen ersten Satz von mehreren Zeilen einer transformierten Matrix von Eingabeaktivierungen und einen entsprechenden Satz von Zeilen einer transformierten Gewichtungsmatrix beinhaltet (4002). Die transformierte Matrix von Eingabeaktivierungen kann aus einer allgemeinen Registerdatei gelesen und während des Lesevorgangs automatisch durch einen Bild-zu-Spalten-Adapter transformiert werden. Die Anzahl der Zeilen der initialen Eingabe kann der Größe der durchzuführenden Faltungsoperation entsprechen. Die Logik kann dann eine tiefenweise Faltungsberechnung über das systolische Array unter Verwendung der initialen Eingabe durchführen (4004). Die Logik kann dann eine nächste Zeile der transformierten Matrix von Eingabeaktivierungen in das systolische Array laden (4006). Die geladene nächste Zeile kann durch den Bild-zu-Spalten-Adapter nach dem Lesen aus der allgemeinen Registerdatei automatisch transformiert werden. Die Logik kann dann die Gewichtungswerte der transformierten Gewichtungsmatrix innerhalb des systolischen Arrays anpassen (4008). Die Logik kann dann eine nächste tiefenweise Faltungsberechnung über das systolische Array unter Verwendung der nächsten Zeile der transformierten Matrix und der angepassten Gewichtungswerte durchführen (4010). Die Operationen können mit einem Ein-Zeilen-Quantum fortgesetzt werden, bis alle transformierten Eingabeaktivierungsdaten mit den transformierten Gewichtungen gefaltet sind. Falls erforderlich, kann eine punktweise Faltung an der Ausgabe der tiefenweisen Faltung durchgeführt werden, um die Anzahl der Kanäle der Ausgabe entweder zu verringern oder zu erweitern.
  • In einer Ausführungsform kann die Reihe von Skalarprodukt-Anweisungen, die verwendet werden, um die hierin beschriebenen tiefenweisen Faltungsoperationen durchzuführen, unter Verwendung der hierin beschriebenen Block-Sparse-Makroanweisung (dpXasV) implementiert werden, wenn Operationen an Sparse-Matrizen durchgeführt werden.
  • Unter Verwendung der obigen Techniken kann ein Fachmann beispielsweise eine Allzweck-Grafikverarbeitungseinheit implementieren, die Folgendes umfasst: eine Registerdatei zum Speichern von Matrixelementen, einen Tensorbeschleuniger zum Durchführen einer tiefenweisen Faltungsoperation an aus der Registerdatei gelesenen Matrixelementen und eine Adapterschaltung zum Transformieren einer Datenkonfiguration der Matrixelemente eines Eingabeaktivierungstensors, wobei die Adapterschaltung die Datenkonfiguration während eines Lesevorgangs der Matrixelemente durch den Tensorbeschleuniger aus der Registerdatei transformieren soll. Die Adapterschaltung soll eine Bild-zu-Spalten-Transformation an der Datenkonfiguration der Matrixelemente eines Eingabeaktivierungstensors durchführen.
  • Unter Verwendung der obigen Techniken kann ein Fachmann beispielsweise eine Allzweck-Grafikverarbeitungseinheit implementieren, die dazu konfiguriert ist, ein Verfahren durchzuführen, das Folgendes umfasst: Laden einer initialen Eingabe, die einen ersten Satz von mehreren Zeilen einer transformierten Matrix von Eingabeaktivierungen und einen entsprechenden Satz von Zeilen einer transformierten Gewichtungsmatrix enthält, und Durchführen einer tiefenweisen Faltungsberechnung über das systolische Array unter Verwendung der initialen Eingabe. Die an der Matrix von Eingabeaktivierungen durchgeführte Transformation kann eine Bild-zu-Spalten-Transformation sein, die automatisch durchgeführt wird, wenn die Matrix von Eingabeaktivierungen aus einer allgemeinen Registerdatei der Allzweck-Grafikverarbeitungseinheit gelesen wird. Das Verfahren beinhaltet zusätzlich Laden der nächsten Zeile der transformierten Matrix von Eingabeaktivierungen in das systolische Array, wobei die nächste Zeile automatisch durch den Bild-zu-Spalten-Adapter transformiert wird. Das Verfahren beinhaltet zusätzlich Anpassen von Gewichtungswerten der transformierten Gewichtungsmatrix. Die Anpassung der Gewichtungswerte kann innerhalb des systolischen Arrays durchgeführt werden. Das Verfahren beinhaltet außerdem Durchführen einer nächsten tiefenweisen Faltungsberechnung über das systolische Array unter Verwendung der nächsten Zeile der transformierten Matrix und der angepassten Gewichtungswerte. Die tiefenweise Faltungsoperationen können Skalarproduktoperationen sein. Die Skalarproduktoperationen können durch Skalarprodukt-Anweisungen durchgeführt werden, die durch eine Block-Sparse-Skalarprodukt-Makroanweisung erzeugt werden.
  • Zusätzliche beispielhafte Rechenvorrichtung
  • 41 ist ein Blockdiagramm einer Rechenvorrichtung 4100 einschließlich eines Grafikprozessors 4104 gemäß einer Ausführungsform. Die Rechenvorrichtung 4100 kann eine Rechenvorrichtung sein, die die Funktionalität von jeder der oben beschriebenen Ausführungsformen beinhaltet. Die Rechenvorrichtung 4100 kann eine Kommunikationsvorrichtung wie etwa eine Set-Top-Box (z. B. internetbasierte Kabelfernseh-Set-Top-Boxen usw.), GPS(Global Positioning System - globales Positionierungssystem)-basierte Vorrichtungen usw. sein oder darin enthalten sein. Die Rechenvorrichtung 4100 kann auch mobile Rechenvorrichtungen wie etwa zellulare Telefone, Smartphones, Personal Digital Assistants (PDAs), Tablet-Computer, Laptop-Computer, E-Reader, Smart-Fernseher, Fernsehplattformen, Wearable-Vorrichtungen (z. B. Brillen, Armbanduhren, Armbänder, Smartcards, Schmuck, Kleidungsstücke usw.), Mediaplayer usw. sein oder darin enthalten sein. Zum Beispiel umfasst die Rechenvorrichtung 4100 in einer Ausführungsform eine mobile Rechenvorrichtung, die eine integrierte Schaltung („IC“) verwendet, wie etwa ein System-on-Chip („SoC“ oder „SOC“), die verschiedene Hardware- und/oder Softwarekomponenten der Rechenvorrichtung 4100 auf einem einzigen Chip integriert.
  • Die Rechenvorrichtung 4100 beinhaltet einen Grafikprozessor 4104. Der Grafikprozessor 4104 repräsentiert einen beliebigen hier beschriebenen Grafikprozessor. Der Grafikprozessor beinhaltet eine oder mehrere Grafik-Engines, Grafikprozessorkerne und andere Grafikausführungsressourcen, wie hier beschrieben. Solche Grafikausführungsressourcen können in den Formen präsentiert werden, einschließlich, aber nicht beschränkt auf Ausführungseinheiten, Shader-Engines, Fragmentprozessoren, Vertex-Prozessoren, Streaming-Multiprozessoren, Grafikprozessorcluster oder eine beliebige Sammlung von Rechenressourcen, die für die Verarbeitung von Grafikressourcen oder Bildressourcen geeignet sind oder Allzweck-Rechenoperationen in einem heterogenen Prozessor durchführen.
  • In einer Ausführungsform beinhaltet der Grafikprozessor 4104 einen Cache 4114, der ein einzelner Cache sein kann oder in mehrere Segmente von Cachespeicher unterteilt sein kann, einschließlich, aber nicht beschränkt auf eine beliebige Anzahl von L1-, L2-, L3- oder L4-Caches, Rendering-Caches, Tiefencaches, Sampler-Caches und/oder Shader-Einheit-Caches. Der Cache 4114 kann ein Nah- und Ferngebiet aufweisen, wie hierin beschrieben. Der Cache 4114 kann auch eine dynamische Hash-Logik beinhalten, die eine dynamische Rekonfiguration eines Speicherbank-Hash-Algorithmus unterstützt. In einigen Ausführungsformen beinhaltet der Grafikprozessor 4104 eine GPGPU-Engine 4144, die gemeinsam genutzten lokalen Speicher (SLM 4134) beinhaltet, sowie eine Registerdatei 4124, die Register zur Verwendung durch die GPGPU-Engine 4144 beinhaltet. Die Registerdatei 4124 kann Allzweckregister, Architekturregister, Konfigurationsregister und andere Arten von Registern beinhalten. Eine Allzweckregisterdatei (GRF) und/oder Architekturregisterdatei (ARF) können sich auch innerhalb von Verarbeitungsressourcen innerhalb eines oder mehrerer Blöcke von Berechnungseinheiten (z. B. Berechnung 4150, Berechnung 4155) innerhalb der GPGPU-Engine 4144 befinden. Es kann auch eine gemeinsam genutzte Fabric 4142 vorhanden sein, die eine schnelle Kommunikation zwischen den verschiedenen Komponenten der GPGPU-Engine 4144 ermöglicht.
  • Wie veranschaulicht, kann die Rechenvorrichtung 4100 bei einer Ausführungsform und zusätzlich zu dem Grafikprozessor 4104 ferner eine beliebige Anzahl und einen beliebigen Typ von Hardwarekomponenten und/oder Softwarekomponenten beinhalten, einschließlich unter anderem eines Anwendungsprozessors 4106, eines Speichers 4108 und Eingabe/Ausgabe(E/A)-Quellen 4110. Der Anwendungsprozessor 4106 kann mit einer Hardware-Grafik-Pipeline interagieren, um die Grafik-Pipeline-Funktionalität gemeinsam zu nutzen. Verarbeitete Daten werden in einem Puffer in der Hardware-Grafik-Pipeline gespeichert und Zustandsinformationen werden in dem Speicher 4108 gespeichert. Die resultierenden Daten können zur Ausgabe über eine Anzeigevorrichtung, wie hierin beschrieben, an eine Anzeigesteuerung transferiert werden. Die Anzeigevorrichtung kann von verschiedenen Typen sein, wie etwa eine Kathodenstrahlröhre (CRT: Cathode Ray Tube), ein Dünnschichttransistor(TFT: Thin Film Transistor)-, Flüssigkristallanzeigen(LCD: Liquid Crystal Display)-, Organische-Leuchtdioden(OLED: Organic Light Emitting Diode)-Array usw., und kann dazu konfiguriert sein, einem Benutzer über eine grafische Benutzeroberfläche Informationen anzuzeigen.
  • Der Anwendungsprozessor 4106 kann einen oder mehrere Prozessoren beinhalten und kann die Zentralverarbeitungseinheit (CPU) sein, die zumindest teilweise verwendet wird, um ein Betriebssystem (OS) 4102 für die Rechenvorrichtung 4100 auszuführen. Das OS 4102 kann als eine Schnittstelle zwischen Hardware und/oder physischen Ressourcen der Rechenvorrichtung 4100 und einem oder mehreren Benutzern dienen. Das OS 4102 kann Treiberlogik für verschiedene Hardwarevorrichtungen in der Rechenvorrichtung 4100 beinhalten, einschließlich Grafiktreiberlogik 4122, wie etwa den Benutzermodus-Grafiktreiber 2326 und/oder den Kernelmodus-Grafiktreiber 2329 von 23.
  • Es wird in Betracht gezogen, dass der Grafikprozessor 4104 bei manchen Ausführungsformen als Teil des Anwendungsprozessors 4106 (wie etwa als Teil eines physischen CPU-Packages) existieren kann, wobei in diesem Fall zumindest ein Teil des Speichers 4108 gemeinsam durch den Anwendungsprozessor 4106 und den Grafikprozessor 4104 genutzt werden kann, obwohl zumindest ein Teil des Speichers 4108 ausschließlich für den Grafikprozessor 4104 sein kann oder der Grafikprozessor 4104 einen getrennten Speicher aufweisen kann. Der Speicher 4108 kann ein vorab zugewiesenes Gebiet eines Puffers (z. B. Rahmenpuffers) umfassen; jedoch versteht es sich für einen Durchschnittsfachmann, dass die Ausführungsformen nicht darauf beschränkt sind und dass ein beliebiger Speicher, auf den die niedrigere Grafik-Pipeline zugreifen kann, verwendet werden kann. Der Speicher 4108 kann verschiedene Formen von Direktzugriffsspeicher (RAM) (z. B. SDRAM, SRAM usw.) beinhalten, die eine Anwendung umfassen, die den Grafikprozessor 4104 verwendet, um eine Desktop- oder 3D-Grafikszene zu rendern. Ein Speichersteuerungshub kann auf Daten im Speicher 4108 zugreifen und sie an den Grafikprozessor 4104 zur Grafik-Pipeline-Verarbeitung weiterleiten. Der Speicher 4108 kann für andere Komponenten innerhalb der Rechenvorrichtung 4100 verfügbar gemacht werden. Zum Beispiel können beliebige Daten (z. B. Eingabegrafikdaten), die von verschiedenen E/A-Quellen 4110 der Rechenvorrichtung 4100 empfangen werden, vorübergehend in eine Warteschlange des Speichers 4108 eingereiht werden, bevor sie durch einen oder mehrere Prozessoren (z. B. den Anwendungsprozessor 4106) bei der Implementierung eines Softwareprogrammes oder einer Anwendung bearbeitet werden. Gleichermaßen werden Daten, für die ein Softwareprogramm bestimmt, dass sie von der Rechenvorrichtung 4100 an eine äußere Entität über eine der Rechensystemschnittstellen gesendet oder in einem internen Speicherungselement gespeichert werden sollen, oft vorübergehend in eine Warteschlange des Speichers 4108 eingereiht, bevor sie übertragen oder gespeichert werden.
  • Die E/A-Quellen können Vorrichtungen wie etwa Touchscreens, Touchpanels, Touchpads, virtuelle oder reguläre Tastaturen, virtuelle oder reguläre Mäuse, Ports, Anschlusselemente, Netzwerkvorrichtungen oder dergleichen beinhalten und können über einen E/A-Hub 107 wie in 1, eine Eingabe/Ausgabe-(E/A)-Schaltungsanordnung 363 wie in 3, einen Plattformsteuerungshub 1430 wie in 14 oder dergleichen angeschlossen werden. Zusätzlich können die E/A-Quellen 4110 eine oder mehrere E/A-Vorrichtungen beinhalten, die für ein Übermitteln von Daten zu und/oder von der Rechenvorrichtung 4100
    (z. B. einem Netzwerkadapter); oder für eine großskalige nichtflüchtige Speicherung innerhalb der Rechenvorrichtung 4100 (z. B. Festplattenlaufwerk) implementiert sind. Benutzereingabevorrichtungen, einschließlich alphanumerischer und anderer Tasten, können verwendet werden, um Informationen und Befehlsauswahlen an den Grafikprozessor 4104 zu kommunizieren. Ein anderer Typ von Benutzereingabevorrichtung ist eine Cursor-Steuerung, wie etwa eine Maus, ein Trackball, ein Touchscreen, ein Touchpad oder Cursor-Richtungstasten, um Richtungsinformationen und Befehlsauswahlen an die GPU zu kommunizieren und eine Cursor-Bewegung auf der Anzeigevorrichtung zu steuern. Kamera- und Mikrofonarrays der Rechenvorrichtung 4100 können eingesetzt werden, um Gesten zu beobachten, Audio und Video aufzuzeichnen und visuelle und auditive Befehle zu empfangen und zu übertragen.
  • Als Netzwerkschnittstellen konfigurierte E/A-Quellen 4110 können Zugriff auf ein Netzwerk bereitstellen, wie etwa ein LAN, ein Weitbereichsnetzwerk (WAN), ein städtisches Netzwerk (MAN), ein persönliches Netzwerk (PAN), Bluetooth, ein Cloud-Netzwerk, ein zellulares oder mobiles Netz (z. B. Drittgeneration (3G), Viertgeneration (4G), Fünftgeneration (5G) usw.), ein Satellitennetzwerk, ein Intranet, das Internet usw. Netzwerkschnittstelle(n) können beispielsweise eine drahtlose Netzwerkschnittstelle mit einer oder mehreren Antennen beinhalten. Netzwerkschnittstelle(n) können beispielsweise auch eine drahtgebundene Netzwerkschnittstelle beinhalten, um mit entfernten Vorrichtungen über ein Netzwerkkabel zu kommunizieren, das beispielsweise ein Ethernet-Kabel, ein Koaxialkabel, ein Glasfaserkabel, ein serielles Kabel oder ein Parallelkabel sein kann.
  • Die Netzwerkschnittstelle(n) können Zugriff auf ein LAN bereitstellen, zum Beispiel durch Erfüllen der IEEE 802.11 Standards, und/oder die Drahtlosnetzwerkschnittstelle kann Zugriff auf ein persönliches Netzwerk bereitstellen, zum Beispiel durch Erfüllen von Bluetooth-Standards. Andere Drahtlosnetzwerkschnittstellen und/oder -protokolle, einschließlich vorhergehender und nachfolgender Versionen der Standards, können ebenfalls unterstützt werden. Zusätzlich zu oder anstatt einer Kommunikation über die Wireless-LAN-Standards können die Netzwerkschnittstelle(n) eine Drahtloskommunikation unter Verwendung von zum Beispiel TDMA(Time-Division-Multiple-Access - Zeitmultiplex-Mehrfachzugriff)-Protokollen, GSM(Global Systems for Mobile Communications - globale Systeme für Mobilkommunikationen)-Protokollen, CDMA(Code Division Multiple Access - Codemultiplex-Mehrfachzugriff)-Protokollen und/oder einem beliebigen anderen Typ von Drahtloskommunikationsprotokollen bereitstellen.
  • Es versteht sich, dass für bestimmte Implementierungen ein weniger oder besser ausgestattetes System als das oben beschriebene Beispiel bevorzugt werden kann. Daher kann die Konfiguration der Rechenvorrichtung 4100 von Implementierung zu Implementierung in Abhängigkeit von zahlreichen Faktoren variieren, wie etwa Preisbeschränkungen, Leistungsfähigkeitsanforderungen, technologischen Verbesserungen oder anderen Umständen. Beispiele beinhalten (ohne Beschränkung) eine Mobilvorrichtung, ein Personal Digital Assistant, eine mobile Rechenvorrichtung, ein Smartphone, ein zellulares Telefon, ein Handset, einen Ein-Wege-Pager, einen Zwei-Wege-Pager, eine Messaging-Vorrichtung, einen Computer, einen Personal Computer (PC), einen Desktop-Computer, einen Laptop-Computer, einen Notebook-Computer, einen tragbaren Computer, einen Tablet-Computer, einen Server, ein Server-Array oder eine Serverfarm, einen Webserver, einen Netzwerkserver, einen Internetserver, eine Workstation, einen Minicomputer, einen Main-Frame-Computer, einen Supercomputer, ein Netzwerkgerät, ein Web-Gerät, ein verteiltes Rechensystem, Multiprozessorsysteme, prozessorbasierte Systeme, Verbraucherelektronik, programmierbare Verbraucherelektronik, einen Fernseher, einen Digitalfernseher, eine Set-Top-Box, einen Drahtloszugangspunkt, eine Basisstation, eine Teilnehmerstation, ein Mobilteilnehmercenter, eine Funknetzwerksteuerung, einen Router, ein Hub, ein Gateway, eine Brücke, einen Switch, eine Maschine oder Kombinationen davon.
  • Ausführungsformen können als ein(e) beliebige(r) oder eine Kombination aus einem oder mehreren Mikrochips oder integrierten Schaltungen, die unter Verwendung einer Parent-Board miteinander verbunden sind, eine festverdrahtete Logik, von einer Speichervorrichtung gespeicherte und durch einen Mikroprozessor ausgeführte Software, eine Firmware, eine anwendungsspezifische integrierte Schaltung (ASIC) und/oder ein feldprogrammierbares Gate-Array (FPGA) implementiert werden. Der Begriff „Logik“ kann beispielsweise Software oder Hardware und/oder Kombinationen von Software und Hardware einschließen.
  • Ausführungsformen können beispielsweise als ein Computerprogrammprodukt bereitgestellt werden, das ein oder mehrere maschinenlesbare Medien mit darauf gespeicherten maschinenausführbaren Anweisungen beinhalten kann, die, wenn sie durch eine oder mehrere Maschinen wie etwa einen Computer, ein Computernetzwerk oder anderen elektronischen Vorrichtungen ausgeführt werden, dazu führen können, dass die eine oder die mehreren Maschinen Operationen gemäß hierin beschriebenen Ausführungsformen ausführen. Ein maschinenlesbares Medium kann Disketten, optische Platten, CD-ROMs (Compact Disc-Read Only Memories) und magnetooptische Platten, 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 nichttransitorischen maschinenlesbaren Medien, die zum Speichern von maschinenausführbaren Anweisungen geeignet sind, aufweisen, ist jedoch nicht darauf beschränkt.
  • Darüber hinaus können Ausführungsformen als ein Computerprogrammprodukt heruntergeladen werden, wobei das Programm von einem entfernten Computer (z. B. einem Server) an einen anfordernden Computer (z. B. einen Client) über einen Kommunikationslink (z. B. ein Modem und/oder eine Netzwerkverbindung) mittels eines oder mehrerer Datensignale, die in einer Trägerwelle oder einem anderen Ausbreitungsmedium umgesetzt sind und/oder durch diese moduliert werden, übermittelt werden kann.
  • Eine Bezugnahme hierin auf „eine Ausführungsform“ bedeutet, dass ein spezielles Merkmal, eine spezielle Struktur oder eine spezielle Charakteristik, das/die in Verbindung mit der Ausführungsform beschrieben wurde, in mindestens einer Ausführungsform der Erfindung enthalten sein kann. Verwendungen des Ausdrucks „in einer Ausführungsform“ an verschiedenen Stellen in der Beschreibung beziehen sich nicht zwangsweise immer auf die gleiche Ausführungsform. Die in den folgenden Figuren dargestellten Prozesse können durch Verarbeitungslogik durchgeführt werden, die Hardware (z. B. Schaltungsanordnung, dedizierte Logik usw.), Software (als Anweisungen auf einem nichttransitorischen maschinenlesbaren Speicherungsmedium) oder eine Kombination von sowohl Hardware als auch Software umfasst. Es wird ausführlich auf verschiedene Ausführungsformen Bezug genommen, von denen Beispiele in den begleitenden Zeichnungen veranschaulicht sind. In der folgenden ausführlichen Beschreibung werden zahlreiche spezifische Einzelheiten dargelegt, um ein gründliches Verständnis der vorliegenden Erfindung zu ermöglichen. Ein Durchschnittsfachmann wird jedoch erkennen, dass die vorliegende Erfindung ohne diese spezifischen Einzelheiten in die Praxis umgesetzt werden können. In anderen Fällen wurden wohlbekannte Verfahren, Prozeduren, Komponenten, Schaltungen und Netzwerke nicht im Detail beschrieben, um Aspekte der Ausführungsformen nicht unnötig zu verschleiern.
  • Es versteht sich auch, dass, obwohl die Begriffe erster, zweiter usw. hierin verwendet werden können, um verschiedene Elemente zu beschreiben, diese Elemente nicht durch diese Begriffe eingeschränkt werden sollten. Diese Begriffe werden nur verwendet, um ein Element von einem anderen zu unterscheiden. Beispielsweise könnte ein erster Kontakt als ein zweiter Kontakt bezeichnet werden, und in ähnlicher Weise könnte ein zweiter Kontakt als ein erster Kontakt bezeichnet werden, ohne vom Schutzumfang der vorliegenden Erfindung abzuweichen. Der erste Kontakt und der zweite Kontakt sind beide Kontakte, aber sie sind nicht derselbe Kontakt.
  • Die hierin verwendete Terminologie dient nur dem Zweck, spezielle Ausführungsformen zu beschreiben und soll nicht alle Ausführungsformen einschränken. Wie in der Beschreibung der Erfindung und den angehängten Ansprüchen verwendet, sollen die Singularformen „ein“, „eine“ und „der/die/das“ auch die Pluralformen einschließen, sofern der Kontext nicht eindeutig etwas anderes angibt. Es versteht sich auch, dass sich der wie hierin verwendete Ausdruck „und/oder“ auf beliebige und alle möglichen Kombinationen von einem oder mehreren der assoziierten aufgelisteten Elemente bezieht und diese einschließt. Es versteht sich ferner, dass die Begriffe „umfasst“ und/oder „umfassend“, wenn in dieser Beschreibung verwendet, das Vorhandensein aufgeführter Merkmale, ganzer Zahlen, Schritte, Operationen, Elemente und/oder Komponenten spezifiziert, aber nicht das Vorhandensein oder das Hinzufügen eines oder mehrerer anderer Merkmale, ganzer Zahlen, Schritte, Operationen, Elemente, Komponenten und/oder Gruppen davon ausschließt.
  • Wie hierin verwendet, kann der Begriff „falls“ in Abhängigkeit vom Kontext so ausgelegt werden, dass er „wenn“ oder „bei“ oder „als Reaktion auf das Bestimmen“ oder „als Reaktion auf das Detektieren“ bedeutet. In ähnlicher Weise kann der Ausdruck „falls bestimmt wird“ oder „falls [eine angegebene Bedingung oder ein angegebenes Ereignis] detektiert wird“ in Abhängigkeit vom Kontext so ausgelegt werden, dass es „bei Bestimmung“ oder „als Reaktion auf eine Bestimmung“ oder „bei Detektion [der angegebenen Bedingung oder des angegebenen Ereignisses]“ oder „als Reaktion auf das Detektieren [der angegebenen Bedingung oder des angegebenen Ereignisses]‟.
  • Hierin beschriebene Ausführungsformen beinhalten Software-, Firmware- und Hardwarelogik, die Techniken zum Durchführen von Arithmetik an Sparse-Daten über eine systolische Verarbeitungseinheit bereitstellt. Eine Ausführungsform stellt datenbewusste Sparsity über komprimierte Bitströme bereit. Eine Ausführungsform stellt Block-Sparse-Skalarprodukt-Anweisungen bereit (z. B. dp4a, dp2a). Eine Ausführungsform stellt einen tiefenweisen Adapter für ein systolisches Array bereit.
  • Eine Ausführungsform stellt einen Grafikprozessor bereit, der eine Abruf- und Decodiereinheit umfasst, die einen Anweisungsabrufer zum Abrufen einer Hardware-Makroanweisung und einen Anweisungsdecodierer zum Decodieren der Hardware-Makroanweisung beinhaltet, wobei die Hardware-Makroanweisung einen Satz initialer Operanden beinhaltet und das Decodieren der Hardware-Makroanweisung Erzeugen eines Satzes von Hardware-Anweisungen, einschließlich mehrerer Skalarprodukt-Anweisungen beinhaltet, wobei die mehreren Skalarprodukt-Anweisungen bei einer Eingabe auszuführen sind, die mit einer ersten Matrix und einer zweiten Matrix assoziiert ist. Die Eingabe wird zumindest teilweise basierend auf dem initialen Satz von Operanden identifiziert. Der Grafikprozessor enthält zusätzlich einen Matrixbeschleuniger einschließlich einer Verarbeitungsressource zum Ausführen des Satzes von Hardware-Anweisungen.
  • Eine Ausführungsform stellt ein Verfahren bereit, das auf einer Grafikverarbeitungseinheit, die einen Matrixbeschleuniger enthält, Abrufen einer Hardware-Makroanweisung mit einer Prädikatsmaske, einer Wiederholungszählung und einem Satz von initialen Operanden beinhaltet. Die Hardware-Makroanweisung kann die Erzeugung eines Satzes von Skalarproduktoperationen bei einer Eingabe ermöglichen, die mit einem Satz von Matrizen assoziiert ist. In einer Ausführungsform beinhaltet das Verfahren zusätzlich Decodieren der Hardware-Makroanweisung in eine decodierte Hardware-Makroanweisung und Erzeugen eines Satzes von Hardware-Anweisungen basierend auf der decodierten Hardware-Makroanweisung, wobei der Satz von Hardware-Anweisungen einen Satz mehrerer Skalarproduktoperationen beinhaltet, wobei der Satz von Hardware-Anweisungen basierend auf der Prädikatsmaske und der Wiederholungszählung erzeugt werden. Das Verfahren beinhaltet ferner Ausführen des Satzes von Hardware-Anweisungen über eine Verarbeitungsressource eines Grafikprozessors.
  • Eine Ausführungsform stellt ein Grafikverarbeitungssystem bereit, das eine Speichervorrichtung und einen mit der Speichervorrichtung gekoppelten Grafikprozessor umfasst, wobei der Grafikprozessor eine Abruf- und Decodiereinheit enthält, die einen Anweisungsabrufer zum Abrufen einer Hardware-Makroanweisung und einen Anweisungsdecodierer zum Decodieren der Hardware-Makroanweisung enthält, wobei die Hardware-Makroanweisung einen Satz initialer Operanden enthält und das Decodieren der Hardware-Makroanweisung Erzeugen eines Satzes von Hardware-Anweisungen, einschließlich mehrerer Skalarprodukt-Anweisungen, beinhaltet. Die mehreren Skalarprodukt-Anweisungen können bei einer Eingabe ausgeführt werden, die mit einer ersten Matrix und einer zweiten Matrix assoziiert ist. Die Eingabe kann zumindest teilweise basierend auf dem initialen Satz von Operanden identifiziert werden. In einer Ausführungsform beinhaltet der Matrixbeschleuniger eine Verarbeitungsressource zum Ausführen des Satzes von Hardware-Anweisungen.
  • Die vorstehende Beschreibung und Zeichnungen sind in einem veranschaulichenden und nicht einschränkenden Sinne zu betrachten. Fachleute werden verstehen, dass verschiedene Modifikationen und Veränderungen an den hierin beschriebenen Ausführungsformen vorgenommen werden können, ohne von der weiteren Idee und dem Schutzumfang der Merkmale gemäß Darlegung in den angehängten Ansprüchen 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/819337 [0001]
    • US 62/819435 [0001]
    • US 62/819361 [0001]
    • US 62/935670 [0001]
  • Zitierte Nicht-Patentliteratur
    • Shane Cook, CUDA Programming Kapitel 3, Seiten 37-51 (2013) [0004]

Claims (25)

  1. Grafikprozessor, der Folgendes umfasst: eine Abruf- und Decodiereinheit, die einen Anweisungsabrufer zum Abrufen einer Hardware-Makroanweisung und einen Anweisungsdecodierer zum Decodieren der Hardware-Makroanweisung beinhaltet, wobei die Hardware-Makroanweisung einen Satz initialer Operanden beinhaltet und das Decodieren der Hardware-Makroanweisung Erzeugen eines Satzes von Hardware-Anweisungen, einschließlich mehrerer Skalarprodukt-Anweisungen beinhaltet, wobei die mehreren Skalarprodukt-Anweisungen bei einer Eingabe auszuführen sind, die mit einer ersten Matrix und einer zweiten Matrix assoziiert ist, wobei die Eingabe zumindest teilweise basierend auf dem initialen Satz von Operanden identifiziert wird; und einen Matrixbeschleuniger, der eine Verarbeitungsressource zum Ausführen des Satzes von Hardware-Anweisungen beinhaltet.
  2. Grafikprozessor nach Anspruch 1, wobei die Hardware-Makroanweisung nach Beendigung des Satzes von Hardware-Anweisungen zurückgezogen wird.
  3. Grafikprozessor nach Anspruch 1, wobei der Satz von initialen Operanden einen Zieloperanden und mehrere Quelloperanden enthält.
  4. Grafikprozessor nach Anspruch 3, wobei die Hardware-Makroanweisung zusätzlich eine Prädikatsmaske und eine Wiederholungszählung enthält, wobei der Satz von Hardware-Anweisungen basierend auf der Prädikatsmaske und der Wiederholungszählung erzeugt wird.
  5. Grafikprozessor nach Anspruch 4, wobei die Wiederholungszählung eine maximale Anzahl von Hardware-Anweisungen angeben soll, die für den Satz von Hardware-Anweisungen zu erzeugen sind.
  6. Grafikprozessor nach Anspruch 5, wobei jede der mehreren Skalarprodukt-Anweisungen die Verarbeitungsressource veranlassen soll, eine Skalarproduktoperation an mehreren Datenelementen durchzuführen.
  7. Grafikprozessor nach Anspruch 6, wobei der Anweisungsdecodierer zum Erzeugen des Satzes von Hardware-Anweisungen ausgelegt ist zum: Erzeugen einer ersten Hardware-Anweisung für ein aktives Bit innerhalb der Prädikatsmaske; und Umgehen der Erzeugung einer zweiten Hardware-Anweisung für ein inaktives Bit innerhalb der Prädikatsmaske.
  8. Grafikprozessor nach Anspruch 7, wobei der Anweisungsdecodierer zum Erzeugen des Satzes von Hardware-Anweisungen zusätzlich ausgelegt ist zum: Erzeugen eines ersten Satzes von Operanden für die erste Hardware-Anweisung, wobei der erste Satz von Operanden ein Zielregister und mehrere Quellregister zur Verwendung durch die erste Hardware-Anweisung angeben soll, wobei der erste Satz von Operanden basierend auf dem Satz von initialen Operanden und einem Operanden-Offset erzeugt wird.
  9. Grafikprozessor nach Anspruch 8, wobei die Prädikatsmaske eine erste Prädikatsmaske ist, das Erzeugen der ersten Hardware-Anweisung für ein aktives Bit Erzeugen einer zweiten Prädikatsmaske für die erste Hardware-Anweisung beinhaltet und die zweite Prädikatsmaske einen oder mehrere aktive Kanäle zum Berechnen für die erste Hardware-Anweisung angeben soll.
  10. Grafikprozessor nach Anspruch 1, wobei die Verarbeitungsressource eine Verarbeitungsressource innerhalb eines systolischen Arrays von Verarbeitungsressourcen ist.
  11. Grafikprozessor nach Anspruch 1, wobei die mehreren Skalarprodukt-Anweisungen eine Vier-Elemente-Skalarprodukt-Anweisung beinhalten.
  12. Grafikprozessor nach Anspruch 1, wobei die mehreren Skalarprodukt-Anweisungen eine Zwei-Elemente-Skalarprodukt-Anweisung beinhalten.
  13. Verfahren, das Folgendes umfasst: auf einer Grafikprozessoreinheit, die einen Matrixbeschleuniger beinhaltet: Abrufen einer Hardware-Makroanweisung mit einer Prädikatsmaske, einer Wiederholungszählung und einem Satz initialer Operanden, wobei die Hardware-Makroanweisung die Erzeugung eines Satzes von Skalarproduktoperationen an einer Eingabe ermöglichen soll, die mit einem Satz von Matrizen assoziiert ist; Decodieren der Hardware-Makroanweisung in eine decodierte Hardware-Makroanwei sung; Erzeugen eines Satzes von Hardware-Anweisungen basierend auf der decodierten Hardware-Makroanweisung, wobei der Satz von Hardware-Anweisungen einen Satz mehrerer Skalarproduktoperationen beinhaltet, wobei der Satz von Hardware-Anweisungen basierend auf der Prädikatsmaske und der Wiederholungszählung erzeugt; und Ausführen des Satzes von Hardware-Anweisungen über eine Verarbeitungsressource eines Grafikprozessors.
  14. Verfahren nach Anspruch 13, wobei die Verarbeitungsressource des Grafikprozessors eine Verarbeitungsressource innerhalb eines Matrixbeschleunigers innerhalb des Grafikprozessors ist.
  15. Verfahren nach Anspruch 14, zusätzlich umfassend Zurückziehen der Hardware-Makroanweisung nach Beendigung des Satzes von Hardware-Anweisungen.
  16. Verfahren nach Anspruch 13, wobei der Satz von initialen Operanden einen Zieloperanden und mehrere Quelloperanden beinhaltet.
  17. Verfahren nach Anspruch 13, wobei das Erzeugen des Satzes von Hardware-Anweisungen Folgendes beinhaltet: Erzeugen einer ersten Hardware-Anweisung für ein aktives Bit innerhalb der Prädikatsmaske; und Umgehen der Erzeugung einer zweiten Hardware-Anweisung für ein inaktives Bit innerhalb der Prädikatsmaske.
  18. Verfahren nach Anspruch 17, das zusätzlich Folgendes umfasst: Erzeugen eines ersten Satzes von Operanden für die erste Hardware-Anweisung, wobei der erste Satz von Operanden ein Zielregister und mehrere Quellregister zur Verwendung durch die erste Hardware-Anweisung angeben soll, wobei der erste Satz von Operanden basierend auf dem Satz von initialen Operanden und einem Operanden-Offset erzeugt wird.
  19. Verfahren nach Anspruch 18, wobei die Prädikatsmaske eine erste Prädikatsmaske ist und das Erzeugen der ersten Hardware-Anweisung für ein aktives Bit Erzeugen einer zweiten Prädikatsmaske für die erste Hardware-Anweisung beinhaltet und die zweite Prädikatsmaske mehrere aktive Kanäle zum Berechnen für die erste Hardware-Anweisung angeben soll.
  20. Grafikverarbeitungssystem, das Folgendes umfasst: eine Speichervorrichtung; und einen Grafikprozessor, der mit der Speichervorrichtung gekoppelt ist, wobei der Grafikprozessor Folgendes beinhaltet: eine Abruf- und Decodiereinheit, die einen Anweisungsabrufer zum Abrufen einer Hardware-Makroanweisung und einen Anweisungsdecodierer zum Decodieren der Hardware-Makroanweisung beinhaltet, wobei die Hardware-Makroanweisung einen Satz initialer Operanden beinhaltet und das Decodieren der Hardware-Makroanweisung Erzeugen eines Satzes von Hardware-Anweisungen, einschließlich mehrerer Skalarprodukt-Anweisungen beinhaltet, wobei die mehreren Skalarprodukt-Anweisungen bei einer Eingabe auszuführen sind, die mit einer ersten Matrix und einer zweiten Matrix assoziiert ist, wobei die Eingabe zumindest teilweise basierend auf dem initialen Satz von Operanden identifiziert wird; und einen Matrixbeschleuniger, der eine Verarbeitungsressource zum Ausführen des Satzes von Hardware-Anweisungen beinhaltet.
  21. Grafikverarbeitungssystem nach Anspruch 20, wobei die Hardware-Makroanweisung nach Beendigung des Satzes von Hardware-Anweisungen zurückgezogen wird.
  22. Grafikverarbeitungssystem nach Anspruch 20, wobei der Satz von initialen Operanden einen Zieloperanden und mehrere Quelloperanden enthält, die Hardware-Makroanweisung zusätzlich eine Prädikatsmaske und eine Wiederholungszählung enthält, der Satz von Hardware-Anweisungen basierend auf der Prädikatsmaske und der Wiederholungszählung erzeugt wird und die Wiederholungszählung eine maximale Anzahl von Hardware-Anweisungen angeben soll, die für den Satz von Hardware-Anweisungen zu erzeugen sind.
  23. Grafikverarbeitungssystem nach 22, wobei jede der mehreren Skalarprodukt-Anweisungen die Verarbeitungsressource veranlassen soll, eine Skalarproduktoperation an mehreren Datenelementen durchzuführen.
  24. Grafikverarbeitungssystem nach Anspruch 23, wobei der Anweisungsdecodierer zum Erzeugen des Satzes von Hardware-Anweisungen ausgelegt ist zum: Erzeugen einer ersten Hardware-Anweisung für ein aktives Bit innerhalb der Prädikatsmaske; und Umgehen der Erzeugung einer zweiten Hardware-Anweisung für ein inaktives Bit innerhalb der Prädikatsmaske.
  25. Grafikverarbeitungssystem nach Anspruch 24, wobei die Prädikatsmaske eine erste Prädikatsmaske ist, das Erzeugen der ersten Hardware-Anweisung für ein aktives Bit Erzeugen einer zweiten Prädikatsmaske für die erste Hardware-Anweisung beinhaltet und die zweite Prädikatsmaske einen oder mehrere aktive Kanäle zum Berechnen für die erste Hardware-Anweisung angeben soll.
DE112020000846.0T 2019-03-15 2020-03-14 Architektur für Block-Sparse-Operationen an einem systolischen Array Pending DE112020000846T5 (de)

Applications Claiming Priority (9)

Application Number Priority Date Filing Date Title
US201962819337P 2019-03-15 2019-03-15
US201962819435P 2019-03-15 2019-03-15
US201962819361P 2019-03-15 2019-03-15
US62/819,361 2019-03-15
US62/819,435 2019-03-15
US62/819,337 2019-03-15
US201962935670P 2019-11-15 2019-11-15
US62/935,670 2019-11-15
PCT/US2020/022847 WO2020190809A1 (en) 2019-03-15 2020-03-14 Architecture for block sparse operations on a systolic array

Publications (1)

Publication Number Publication Date
DE112020000846T5 true DE112020000846T5 (de) 2021-11-18

Family

ID=70285850

Family Applications (2)

Application Number Title Priority Date Filing Date
DE112020001249.2T Pending DE112020001249T5 (de) 2019-03-15 2020-03-14 Dünnbesetzt-Optimierungen für eine Matrixbeschleunigerarchitektur
DE112020000846.0T Pending DE112020000846T5 (de) 2019-03-15 2020-03-14 Architektur für Block-Sparse-Operationen an einem systolischen Array

Family Applications Before (1)

Application Number Title Priority Date Filing Date
DE112020001249.2T Pending DE112020001249T5 (de) 2019-03-15 2020-03-14 Dünnbesetzt-Optimierungen für eine Matrixbeschleunigerarchitektur

Country Status (10)

Country Link
US (5) US11113784B2 (de)
EP (3) EP3938889A1 (de)
JP (4) JP2022523760A (de)
KR (3) KR20210135998A (de)
CN (5) CN112534404A (de)
AU (1) AU2020241262A1 (de)
BR (2) BR112021016106A2 (de)
DE (2) DE112020001249T5 (de)
SG (1) SG11202107290QA (de)
WO (3) WO2020190809A1 (de)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11361496B2 (en) 2019-03-15 2022-06-14 Intel Corporation Graphics processors and graphics processing units having dot product accumulate instruction for hybrid floating point format
US11676239B2 (en) 2019-03-15 2023-06-13 Intel Corporation Sparse optimizations for a matrix accelerator architecture

Families Citing this family (45)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10474458B2 (en) 2017-04-28 2019-11-12 Intel Corporation Instructions and logic to perform floating-point and integer operations for machine learning
KR102559581B1 (ko) * 2018-05-23 2023-07-25 삼성전자주식회사 재구성 가능 로직을 포함하는 스토리지 장치 및 상기 스토리지 장치의 동작 방법
US20200210517A1 (en) 2018-12-27 2020-07-02 Intel Corporation Systems and methods to accelerate multiplication of sparse matrices
US11934342B2 (en) 2019-03-15 2024-03-19 Intel Corporation Assistance for hardware prefetch in cache access
US11392376B2 (en) * 2019-04-11 2022-07-19 Arm Limited Processor for sparse matrix computation
US11222092B2 (en) * 2019-07-16 2022-01-11 Facebook Technologies, Llc Optimization for deconvolution
KR102213258B1 (ko) * 2019-07-29 2021-02-08 한국전자기술연구원 효율적인 명령어 처리를 위한 프로세싱-인-메모리 제어 방법 및 이를 적용한 연산장치
CN112899740B (zh) * 2019-11-15 2022-04-19 源秩科技（上海）有限公司 基于电化学的加工装置和方法
CN111176582A (zh) * 2019-12-31 2020-05-19 北京百度网讯科技有限公司 矩阵存储方法、矩阵访问方法、装置和电子设备
US11586601B2 (en) * 2020-02-05 2023-02-21 Alibaba Group Holding Limited Apparatus and method for representation of a sparse matrix in a neural network
US11687831B1 (en) 2020-06-30 2023-06-27 Cadence Design Systems, Inc. Method, product, and apparatus for a multidimensional processing array for hardware acceleration of convolutional neural network inference
US11823018B1 (en) 2020-06-30 2023-11-21 Cadence Design Systems, Inc. Method, product, and apparatus for a machine learning process using weight sharing within a systolic array having reduced memory bandwidth
US11676068B1 (en) 2020-06-30 2023-06-13 Cadence Design Systems, Inc. Method, product, and apparatus for a machine learning process leveraging input sparsity on a pixel by pixel basis
US11615320B1 (en) 2020-06-30 2023-03-28 Cadence Design Systems, Inc. Method, product, and apparatus for variable precision weight management for neural networks
US11651283B1 (en) * 2020-06-30 2023-05-16 Cadence Design Systems, Inc. Method, product, and apparatus for a machine learning process using dynamic rearrangement of sparse data and corresponding weights
US11848980B2 (en) * 2020-07-09 2023-12-19 Boray Data Technology Co. Ltd. Distributed pipeline configuration in a distributed computing system
US20220164663A1 (en) * 2020-11-24 2022-05-26 Arm Limited Activation Compression Method for Deep Learning Acceleration
US11977885B2 (en) * 2020-11-30 2024-05-07 Intel Corporation Utilizing structured sparsity in systolic arrays
US20220197642A1 (en) * 2020-12-23 2022-06-23 Intel Corporation Processor instructions for data compression and decompression
US20220197799A1 (en) * 2020-12-23 2022-06-23 Intel Corporation Instruction and Micro-Architecture Support for Decompression on Core
US20220222319A1 (en) * 2021-01-14 2022-07-14 Microsoft Technology Licensing, Llc Compressed matrix with sparsity metadata
US20230161479A1 (en) * 2021-02-25 2023-05-25 Alibab Group Holding Limited Zero skipping techniques for reducing data movement
US20220293170A1 (en) * 2021-03-10 2022-09-15 Invention And Collaboration Laboratory Pte. Ltd. Integrated scaling and stretching platform for optimizing monolithic integration and/or heterogeneous integration in a single semiconductor die
US20220300816A1 (en) * 2021-03-19 2022-09-22 Rebellions Inc. Neural processing device and method for pruning thereof
CN113516172B (zh) * 2021-05-19 2023-05-12 电子科技大学 基于随机计算贝叶斯神经网络误差注入的图像分类方法
CN113076521B (zh) * 2021-06-03 2021-09-21 沐曦集成电路(上海)有限公司 一种基于gpgpu可重构架构的方法及计算系统
CN113268270B (zh) * 2021-06-07 2022-10-21 中科计算技术西部研究院 一种针对成对隐马尔可夫模型的加速方法、系统及装置
US11669331B2 (en) * 2021-06-17 2023-06-06 International Business Machines Corporation Neural network processing assist instruction
US20220414053A1 (en) * 2021-06-24 2022-12-29 Intel Corporation Systolic array of arbitrary physical and logical depth
US20220414054A1 (en) * 2021-06-25 2022-12-29 Intel Corporation Dual pipeline parallel systolic array
US20220413803A1 (en) * 2021-06-25 2022-12-29 Intel Corporation Systolic array having support for output sparsity
US20220413924A1 (en) * 2021-06-25 2022-12-29 Intel Corporation Using sparsity metadata to reduce systolic array power consumption
US20220413851A1 (en) * 2021-06-25 2022-12-29 Intel Corporation Register file for systolic array
US11941111B2 (en) 2021-07-31 2024-03-26 International Business Machines Corporation Exploiting fine-grained structured weight sparsity in systolic arrays
US20230079975A1 (en) * 2021-09-10 2023-03-16 Arm Limited Power management for system-on-chip
US20230102279A1 (en) * 2021-09-25 2023-03-30 Intel Corporation Apparatuses, methods, and systems for instructions for structured-sparse tile matrix fma
US11657260B2 (en) * 2021-10-26 2023-05-23 Edgecortix Pte. Ltd. Neural network hardware accelerator data parallelism
CN114218152B (zh) * 2021-12-06 2023-08-15 海飞科(南京)信息技术有限公司 流处理方法、处理电路和电子设备
TWI824392B (zh) * 2022-01-21 2023-12-01 財團法人國家實驗研究院 適用於分散式深度學習計算的隨需即組共用資料快取方法、電腦程式、電腦可讀取媒體
CN115034198B (zh) * 2022-05-16 2023-05-12 北京百度网讯科技有限公司 语言模型中嵌入模块计算优化的方法
KR102548582B1 (ko) * 2022-12-26 2023-06-29 리벨리온 주식회사 뉴럴 프로세서 및 이의 명령어 페치 방법
US11915001B1 (en) 2022-12-26 2024-02-27 Rebellions Inc. Neural processor and method for fetching instructions thereof
TWI831588B (zh) * 2023-01-30 2024-02-01 創鑫智慧股份有限公司 神經網路演算裝置以及在神經網路演算中的數值轉換方法
TWI830669B (zh) * 2023-02-22 2024-01-21 旺宏電子股份有限公司 編碼方法及編碼電路
CN117093816B (zh) * 2023-10-19 2024-01-19 上海登临科技有限公司 矩阵乘运算方法、装置和电子设备

Family Cites Families (325)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2581236B2 (ja) 1989-11-16 1997-02-12 三菱電機株式会社 データ処理装置
JP2682232B2 (ja) 1990-11-21 1997-11-26 松下電器産業株式会社 浮動小数点演算処理装置
US5381539A (en) 1992-06-04 1995-01-10 Emc Corporation System and method for dynamically controlling cache management
GB9307359D0 (en) 1993-04-08 1993-06-02 Int Computers Ltd Cache replacement mechanism
US5450607A (en) 1993-05-17 1995-09-12 Mips Technologies Inc. Unified floating point and integer datapath for a RISC processor
US5574928A (en) 1993-10-29 1996-11-12 Advanced Micro Devices, Inc. Mixed integer/floating point processor core for a superscalar microprocessor with a plurality of operand buses for transferring operand segments
US5623636A (en) 1993-11-09 1997-04-22 Motorola Inc. Data processing system and method for providing memory access protection using transparent translation registers and default attribute bits
US5627985A (en) 1994-01-04 1997-05-06 Intel Corporation Speculative and committed resource files in an out-of-order processor
GB2296155B (en) 1994-06-22 1997-04-23 Microsoft Corp Data decompression circuit
US5805475A (en) 1995-02-10 1998-09-08 International Business Machines Corporation Load-store unit and method of loading and storing single-precision floating-point registers in a double-precision architecture
US5651137A (en) 1995-04-12 1997-07-22 Intel Corporation Scalable cache attributes for an input/output bus
US5940311A (en) 1996-04-30 1999-08-17 Texas Instruments Incorporated Immediate floating-point operand reformatting in a microprocessor
US5917741A (en) 1996-08-29 1999-06-29 Intel Corporation Method and apparatus for performing floating-point rounding operations for multiple precisions using incrementers
US6078940A (en) 1997-01-24 2000-06-20 Texas Instruments Incorporated Microprocessor with an instruction for multiply and left shift with saturate
US5943687A (en) 1997-03-14 1999-08-24 Telefonakiebolaget Lm Ericsson Penalty-based cache storage and replacement techniques
US5926406A (en) 1997-04-30 1999-07-20 Hewlett-Packard, Co. System and method for calculating floating point exponential values in a geometry accelerator
AUPO793897A0 (en) * 1997-07-15 1997-08-07 Silverbrook Research Pty Ltd Image processing method and apparatus (ART25)
SG120064A1 (en) * 1997-07-15 2006-03-28 Silverbrook Res Pty Ltd Thermal actuator
US6856320B1 (en) 1997-11-25 2005-02-15 Nvidia U.S. Investment Company Demand-based memory system for graphics applications
US7102646B1 (en) 1997-11-25 2006-09-05 Nvidia U.S. Investment Company Demand-based memory system for graphics applications
US6253311B1 (en) 1997-11-29 2001-06-26 Jp First Llc Instruction set for bi-directional conversion and transfer of integer and floating point data
US6049865A (en) 1997-12-18 2000-04-11 Motorola, Inc. Method and apparatus for implementing floating point projection instructions
US6260008B1 (en) 1998-01-08 2001-07-10 Sharp Kabushiki Kaisha Method of and system for disambiguating syntactic word multiples
US6480872B1 (en) 1999-01-21 2002-11-12 Sandcraft, Inc. Floating-point and integer multiply-add and multiply-accumulate
US6529928B1 (en) 1999-03-23 2003-03-04 Silicon Graphics, Inc. Floating-point adder performing floating-point and integer operations
US6788738B1 (en) 1999-05-07 2004-09-07 Xilinx, Inc. Filter accelerator for a digital signal processor
US6631437B1 (en) 2000-04-06 2003-10-07 Hewlett-Packard Development Company, L.P. Method and apparatus for promoting memory read commands
US6578102B1 (en) 2000-04-18 2003-06-10 International Business Machines Corporation Tracking and control of prefetch data in a PCI bus system
US6412046B1 (en) 2000-05-01 2002-06-25 Hewlett Packard Company Verification of cache prefetch mechanism
US7499053B2 (en) 2000-06-19 2009-03-03 Mental Images Gmbh Real-time precision ray tracing
US8188997B2 (en) 2000-06-19 2012-05-29 Mental Images Gmbh Accelerated ray tracing using shallow bounding volume hierarchies
US6678806B1 (en) 2000-08-23 2004-01-13 Chipwrights Design, Inc. Apparatus and method for using tagged pointers for extract, insert and format operations
US6792509B2 (en) 2001-04-19 2004-09-14 International Business Machines Corporation Partitioned cache of multiple logical levels with adaptive reconfiguration based on multiple criteria
US6748495B2 (en) 2001-05-15 2004-06-08 Broadcom Corporation Random generator
US6947049B2 (en) 2001-06-01 2005-09-20 Nvidia Corporation Method and system for synchronizing updates of vertex data with a graphics processor that is fetching vertex data
US7127482B2 (en) 2001-11-19 2006-10-24 Intel Corporation Performance optimized approach for efficient downsampling operations
US7197605B2 (en) 2002-12-30 2007-03-27 Intel Corporation Allocating cache lines
US7483031B2 (en) 2003-04-17 2009-01-27 Nvidia Corporation Method for synchronizing graphics processing units
US7373369B2 (en) 2003-06-05 2008-05-13 International Business Machines Corporation Advanced execution of extended floating-point add operations in a narrow dataflow
US7272624B2 (en) 2003-09-30 2007-09-18 International Business Machines Corporation Fused booth encoder multiplexer
JP3807400B2 (ja) 2003-10-30 2006-08-09 ソニー株式会社 記録制御装置および記録制御方法
GB2409068A (en) 2003-12-09 2005-06-15 Advanced Risc Mach Ltd Data element size control within parallel lanes of processing
KR100800468B1 (ko) 2004-01-29 2008-02-01 삼성전자주식회사 저전력 고속 동작을 위한 하드웨어 암호화/복호화 장치 및그 방법
US8253750B1 (en) 2004-02-14 2012-08-28 Nvidia Corporation Digital media processor
US7873812B1 (en) 2004-04-05 2011-01-18 Tibet MIMAR Method and system for efficient matrix multiplication in a SIMD processor architecture
US7548892B2 (en) * 2004-04-30 2009-06-16 Microsoft Corporation Processing machine learning techniques using a graphics processing unit
US7428566B2 (en) 2004-11-10 2008-09-23 Nvidia Corporation Multipurpose functional unit with multiply-add and format conversion pipeline
US20060101244A1 (en) 2004-11-10 2006-05-11 Nvidia Corporation Multipurpose functional unit with combined integer and floating-point multiply-add pipeline
US20060179092A1 (en) 2005-02-10 2006-08-10 Schmookler Martin S System and method for executing fixed point divide operations using a floating point multiply-add pipeline
US20060248279A1 (en) 2005-05-02 2006-11-02 Al-Sukhni Hassan F Prefetching across a page boundary
US7346741B1 (en) 2005-05-10 2008-03-18 Sun Microsystems, Inc. Memory latency of processors with configurable stride based pre-fetching technique
US20090030960A1 (en) 2005-05-13 2009-01-29 Dermot Geraghty Data processing system and method
US8250348B2 (en) 2005-05-19 2012-08-21 International Business Machines Corporation Methods and apparatus for dynamically switching processor mode
US7659899B2 (en) 2005-08-08 2010-02-09 Via Technologies, Inc. System and method to manage data processing stages of a logical graphics pipeline
US20070030277A1 (en) 2005-08-08 2007-02-08 Via Technologies, Inc. Method for processing vertex, triangle, and pixel graphics data packets
US20070074008A1 (en) 2005-09-28 2007-03-29 Donofrio David D Mixed mode floating-point pipeline with extended functions
CN1952979B (zh) 2005-10-14 2012-06-27 威盛电子股份有限公司 多重图形处理器系统及方法
US7616206B1 (en) 2006-06-16 2009-11-10 Nvidia Corporation Efficient multi-chip GPU
US7467280B2 (en) 2006-07-05 2008-12-16 International Business Machines Corporation Method for reconfiguring cache memory based on at least analysis of heat generated during runtime, at least by associating an access bit with a cache line and associating a granularity bit with a cache line in level-2 cache
US20080030510A1 (en) 2006-08-02 2008-02-07 Xgi Technology Inc. Multi-GPU rendering system
US7620793B1 (en) 2006-08-28 2009-11-17 Nvidia Corporation Mapping memory partitions to virtual memory pages
US20080071851A1 (en) * 2006-09-20 2008-03-20 Ronen Zohar Instruction and logic for performing a dot-product operation
US7327289B1 (en) 2006-09-20 2008-02-05 Intel Corporation Data-modifying run length encoder to avoid data expansion
US8122078B2 (en) 2006-10-06 2012-02-21 Calos Fund, LLC Processor with enhanced combined-arithmetic capability
US20080086598A1 (en) 2006-10-10 2008-04-10 Maron William A System and method for establishing cache priority for critical data structures of an application
US20080189487A1 (en) 2007-02-06 2008-08-07 Arm Limited Control of cache transactions
US8781110B2 (en) 2007-06-30 2014-07-15 Intel Corporation Unified system architecture for elliptic-curve cryptography
US7783859B2 (en) 2007-07-12 2010-08-24 Qnx Software Systems Gmbh & Co. Kg Processing system implementing variable page size memory organization
US8990505B1 (en) 2007-09-21 2015-03-24 Marvell International Ltd. Cache memory bank selection
EP2220554A1 (de) 2007-11-17 2010-08-25 Krass, Maren Rekonfiguri erbare fliesskomma- und bit- ebenen datenverarbeitungseinheit
US8106914B2 (en) 2007-12-07 2012-01-31 Nvidia Corporation Fused multiply-add functional unit
US7941633B2 (en) 2007-12-18 2011-05-10 International Business Machines Corporation Hash optimization system and method
US7870339B2 (en) 2008-01-11 2011-01-11 International Business Machines Corporation Extract cache attribute facility and instruction therefore
US20090190432A1 (en) 2008-01-28 2009-07-30 Christoph Bilger DRAM with Page Access
US8429351B1 (en) 2008-03-28 2013-04-23 Emc Corporation Techniques for determining an amount of data to prefetch
US8146064B2 (en) 2008-04-04 2012-03-27 International Business Machines Corporation Dynamically controlling a prefetching range of a software controlled cache
US8078833B2 (en) 2008-05-29 2011-12-13 Axis Semiconductor, Inc. Microprocessor with highly configurable pipeline and executional unit internal hierarchal structures, optimizable for different types of computational functions
US7945768B2 (en) 2008-06-05 2011-05-17 Motorola Mobility, Inc. Method and apparatus for nested instruction looping using implicit predicates
US8340280B2 (en) 2008-06-13 2012-12-25 Intel Corporation Using a single instruction multiple data (SIMD) instruction to speed up galois counter mode (GCM) computations
US8041856B2 (en) * 2008-09-30 2011-10-18 Lsi Corporation Skip based control logic for first in first out buffer
US8219757B2 (en) 2008-09-30 2012-07-10 Intel Corporation Apparatus and method for low touch cache management
US20100162247A1 (en) 2008-12-19 2010-06-24 Adam Welc Methods and systems for transactional nested parallelism
US20100185816A1 (en) 2009-01-21 2010-07-22 Sauber William F Multiple Cache Line Size
US8266409B2 (en) 2009-03-03 2012-09-11 Qualcomm Incorporated Configurable cache and method to configure same
US8108612B2 (en) 2009-05-15 2012-01-31 Microsoft Corporation Location updates for a distributed data store
US8566801B2 (en) 2009-05-22 2013-10-22 International Business Machines Corporation Concurrent static single assignment for general barrier synchronized parallel programs
US8819359B2 (en) 2009-06-29 2014-08-26 Oracle America, Inc. Hybrid interleaving in memory modules by interleaving physical addresses for a page across ranks in a memory module
US8352945B2 (en) 2009-08-11 2013-01-08 International Business Machines Corporation System, method, and apparatus for scan-sharing for business intelligence queries in an in-memory database
US8615637B2 (en) 2009-09-10 2013-12-24 Advanced Micro Devices, Inc. Systems and methods for processing memory requests in a multi-processor system using a probe engine
US8364739B2 (en) 2009-09-30 2013-01-29 International Business Machines Corporation Sparse matrix-vector multiplication on graphics processor units
US8103910B2 (en) 2009-11-13 2012-01-24 International Business Machines Corporation Local rollback for fault-tolerance in parallel computing systems
US8669990B2 (en) 2009-12-31 2014-03-11 Intel Corporation Sharing resources between a CPU and GPU
US8677613B2 (en) 2010-05-20 2014-03-25 International Business Machines Corporation Enhanced modularity in heterogeneous 3D stacks
US8812575B2 (en) 2010-07-06 2014-08-19 Silminds, Llc, Egypt Decimal floating-point square-root unit using Newton-Raphson iterations
US8982140B2 (en) 2010-09-24 2015-03-17 Nvidia Corporation Hierarchical memory addressing
US9965395B2 (en) 2010-09-28 2018-05-08 Texas Instruments Incorporated Memory attribute sharing between differing cache levels of multilevel cache
US8488055B2 (en) 2010-09-30 2013-07-16 Apple Inc. Flash synchronization using image sensor interface timing signal
US8745111B2 (en) 2010-11-16 2014-06-03 Apple Inc. Methods and apparatuses for converting floating point representations
CN102033985A (zh) * 2010-11-24 2011-04-27 南京理工大学 基于*-矩阵算法的高效时域电磁仿真方法
US8847965B2 (en) 2010-12-03 2014-09-30 The University Of North Carolina At Chapel Hill Methods, systems, and computer readable media for fast geometric sound propagation using visibility computations
CN102141976B (zh) * 2011-01-10 2013-08-14 中国科学院软件研究所 稀疏矩阵的对角线数据存储方法及基于该方法的SpMV实现方法
GB2488985A (en) 2011-03-08 2012-09-19 Advanced Risc Mach Ltd Mixed size data processing operation with integrated operand conversion instructions
US8862653B2 (en) * 2011-04-26 2014-10-14 University Of South Carolina System and method for sparse matrix vector multiplication processing
FR2974645A1 (fr) 2011-04-28 2012-11-02 Kalray Operateur de multiplication et addition fusionnees a precision mixte
US9501392B1 (en) 2011-05-12 2016-11-22 Avago Technologies General Ip (Singapore) Pte. Ltd. Management of a non-volatile memory module
JP5813380B2 (ja) 2011-06-03 2015-11-17 株式会社東芝 半導体記憶装置
US9529712B2 (en) 2011-07-26 2016-12-27 Nvidia Corporation Techniques for balancing accesses to memory having different memory types
US9727336B2 (en) 2011-09-16 2017-08-08 International Business Machines Corporation Fine-grained instruction enablement at sub-function granularity based on an indicated subrange of registers
US20130099946A1 (en) 2011-10-21 2013-04-25 International Business Machines Corporation Data Compression Utilizing Variable and Limited Length Codes
US8935478B2 (en) 2011-11-01 2015-01-13 International Business Machines Corporation Variable cache line size management
US20130141442A1 (en) 2011-12-06 2013-06-06 John W. Brothers Method and apparatus for multi-chip processing
US20130148947A1 (en) 2011-12-13 2013-06-13 Ati Technologies Ulc Video player with multiple grpahics processors
WO2013095504A1 (en) 2011-12-22 2013-06-27 Intel Corporation Matrix multiply accumulate instruction
CN104137055B (zh) * 2011-12-29 2018-06-05 英特尔公司 点积处理器、方法、系统和指令
US20130185515A1 (en) 2012-01-16 2013-07-18 Qualcomm Incorporated Utilizing Negative Feedback from Unexpected Miss Addresses in a Hardware Prefetcher
US20140052965A1 (en) 2012-02-08 2014-02-20 Uzi Sarel Dynamic cpu gpu load balancing using power
US20130218938A1 (en) 2012-02-17 2013-08-22 Qualcomm Incorporated Floating-point adder with operand shifting based on a predicted exponent difference
US9036710B2 (en) * 2012-03-08 2015-05-19 Blackberry Limited Unified transform coefficient encoding and decoding
US8775762B2 (en) 2012-05-07 2014-07-08 Advanced Micro Devices, Inc. Method and apparatus for batching memory requests
US8892619B2 (en) 2012-07-24 2014-11-18 The Board Of Trustees Of The Leland Stanford Junior University Floating-point multiply-add unit using cascade design
US9128845B2 (en) 2012-07-30 2015-09-08 Hewlett-Packard Development Company, L.P. Dynamically partition a volatile memory for a cache and a memory partition
CN103581052B (zh) 2012-08-02 2017-07-21 华为技术有限公司 一种数据处理方法、路由器及ndn系统
US9298456B2 (en) 2012-08-21 2016-03-29 Apple Inc. Mechanism for performing speculative predicated instructions
US20140075163A1 (en) 2012-09-07 2014-03-13 Paul N. Loewenstein Load-monitor mwait
US9134954B2 (en) 2012-09-10 2015-09-15 Qualcomm Incorporated GPU memory buffer pre-fetch and pre-back signaling to avoid page-fault
US10742475B2 (en) 2012-12-05 2020-08-11 Origin Wireless, Inc. Method, apparatus, and system for object tracking sensing using broadcasting
US9317482B2 (en) * 2012-10-14 2016-04-19 Microsoft Technology Licensing, Llc Universal FPGA/ASIC matrix-vector multiplication architecture
US9152382B2 (en) 2012-10-31 2015-10-06 Intel Corporation Reducing power consumption in a fused multiply-add (FMA) unit responsive to input data values
US11150721B2 (en) 2012-11-07 2021-10-19 Nvidia Corporation Providing hints to an execution unit to prepare for predicted subsequent arithmetic operations
US9183144B2 (en) 2012-12-14 2015-11-10 Intel Corporation Power gating a portion of a cache memory
US20140173203A1 (en) 2012-12-18 2014-06-19 Andrew T. Forsyth Block Memory Engine
US9317251B2 (en) 2012-12-31 2016-04-19 Nvidia Corporation Efficient correction of normalizer shift amount errors in fused multiply add operations
US9971710B2 (en) 2013-02-07 2018-05-15 Microsoft Technology Licensing, Llc Optimizing data transfers between heterogeneous memory arenas
US9478066B2 (en) 2013-03-14 2016-10-25 Nvidia Corporation Consistent vertex snapping for variable resolution rendering
US10133677B2 (en) 2013-03-14 2018-11-20 Nvidia Corporation Opportunistic migration of memory pages in a unified virtual memory system
US9940286B2 (en) 2013-03-14 2018-04-10 Nvidia Corporation PCIE traffic tracking hardware in a unified virtual memory system
US9525586B2 (en) 2013-03-15 2016-12-20 Intel Corporation QoS based binary translation and application streaming
GB2551291B (en) 2013-05-23 2018-02-14 Linear Algebra Tech Limited Corner detection
US9378127B2 (en) 2013-06-21 2016-06-28 Intel Corporation Dynamic memory page policy
US9264066B2 (en) 2013-07-30 2016-02-16 Apple Inc. Type conversion using floating-point unit
US9946666B2 (en) 2013-08-06 2018-04-17 Nvidia Corporation Coalescing texture access and load/store operations
US9092345B2 (en) 2013-08-08 2015-07-28 Arm Limited Data processing systems
US9710380B2 (en) 2013-08-29 2017-07-18 Intel Corporation Managing shared cache by multi-core processor
TWI676898B (zh) 2013-12-09 2019-11-11 安然國際科技有限公司 分散式記憶體磁碟群集儲存系統運作方法
US9461667B2 (en) 2013-12-30 2016-10-04 Samsung Electronics Co., Ltd. Rounding injection scheme for floating-point to integer conversion
US20150193358A1 (en) 2014-01-06 2015-07-09 Nvidia Corporation Prioritized Memory Reads
US10528357B2 (en) 2014-01-17 2020-01-07 L3 Technologies, Inc. Web-based recorder configuration utility
US20150205724A1 (en) 2014-01-20 2015-07-23 Honeywell International Inc. System and method of cache partitioning for processors with limited cached memory pools
KR102100161B1 (ko) 2014-02-04 2020-04-14 삼성전자주식회사 Gpu 데이터 캐싱 방법 및 그에 따른 데이터 프로세싱 시스템
WO2015119610A1 (en) 2014-02-06 2015-08-13 Empire Technology Development, Llc Server-client secret generation with cached data
US9275429B2 (en) 2014-02-17 2016-03-01 Qualcomm Incorporated Device hang detection and recovery
KR20150106132A (ko) 2014-03-11 2015-09-21 삼성전자주식회사 전자 장치의 캐시 메모리 제어 방법 및 장치
US20150268963A1 (en) 2014-03-23 2015-09-24 Technion Research & Development Foundation Ltd. Execution of data-parallel programs on coarse-grained reconfigurable architecture hardware
US9436972B2 (en) 2014-03-27 2016-09-06 Intel Corporation System coherency in a distributed graphics processor hierarchy
EP2937794B1 (de) 2014-04-22 2016-08-17 DataVard GmbH Verfahren und System zum Archivieren von digitalen Daten
US9673998B2 (en) 2014-05-15 2017-06-06 Futurewei Technologies, Inc. Differential cache for representational state transfer (REST) API
JP6248808B2 (ja) 2014-05-22 2017-12-20 富士通株式会社 情報処理装置、情報処理システム、情報処理装置の制御方法、及び、情報処理装置の制御プログラム
KR102192956B1 (ko) 2014-06-23 2020-12-18 삼성전자주식회사 디스플레이 장치 및 그 제어 방법
US10061592B2 (en) 2014-06-27 2018-08-28 Samsung Electronics Co., Ltd. Architecture and execution for efficient mixed precision computations in single instruction multiple data/thread (SIMD/T) devices
US9520192B2 (en) 2014-06-30 2016-12-13 Intel Corporation Resistive memory write operation with merged reset
US20150378920A1 (en) 2014-06-30 2015-12-31 John G. Gierach Graphics data pre-fetcher for last level caches
US10223333B2 (en) 2014-08-29 2019-03-05 Nvidia Corporation Performing multi-convolution operations in a parallel processing system
KR102263326B1 (ko) 2014-09-18 2021-06-09 삼성전자주식회사 그래픽 프로세싱 유닛 및 이를 이용한 그래픽 데이터 처리 방법
US9928076B2 (en) 2014-09-26 2018-03-27 Intel Corporation Method and apparatus for unstructured control flow for SIMD execution engine
US20160092118A1 (en) 2014-09-26 2016-03-31 Intel Corporation Memory write management in a computer system
JP2016091242A (ja) 2014-10-31 2016-05-23 富士通株式会社 キャッシュメモリ、キャッシュメモリへのアクセス方法及び制御プログラム
US20160124709A1 (en) 2014-11-04 2016-05-05 International Business Machines Corporation Fast, energy-efficient exponential computations in simd architectures
US10282227B2 (en) 2014-11-18 2019-05-07 Intel Corporation Efficient preemption for graphics processors
US9910785B2 (en) 2014-12-14 2018-03-06 Via Alliance Semiconductor Co., Ltd Cache memory budgeted by ways based on memory access type
US9898411B2 (en) 2014-12-14 2018-02-20 Via Alliance Semiconductor Co., Ltd. Cache memory budgeted by chunks based on memory access type
JP6207766B2 (ja) 2014-12-14 2017-10-04 ヴィア アライアンス セミコンダクター カンパニー リミテッド ヘテロジニアス置換ポリシーを用いるセット・アソシエイティブ・キャッシュ・メモリ
FR3030846B1 (fr) * 2014-12-23 2017-12-29 Commissariat Energie Atomique Representation semantique du contenu d'une image
US9304835B1 (en) * 2014-12-31 2016-04-05 International Business Machines Corporation Optimized system for analytics (graphs and sparse matrices) operations
US20160255169A1 (en) 2015-02-27 2016-09-01 Futurewei Technologies, Inc. Method and system for smart object eviction for proxy cache
US10002455B2 (en) 2015-04-20 2018-06-19 Intel Corporation Optimized depth buffer cache apparatus and method
US9626299B2 (en) 2015-05-01 2017-04-18 Intel Corporation Changing a hash function based on a conflict ratio associated with cache sets
US9804666B2 (en) 2015-05-26 2017-10-31 Samsung Electronics Co., Ltd. Warp clustering
US20160378465A1 (en) * 2015-06-23 2016-12-29 Intel Corporation Efficient sparse array handling in a processor
GB2540761B (en) 2015-07-23 2017-12-06 Advanced Risc Mach Ltd Cache usage estimation
US20170039144A1 (en) 2015-08-07 2017-02-09 Intel Corporation Loading data using sub-thread information in a processor
CN105068787A (zh) * 2015-08-28 2015-11-18 华南理工大学 一种稀疏矩阵向量乘法的异构并行计算方法
US10423354B2 (en) 2015-09-23 2019-09-24 Advanced Micro Devices, Inc. Selective data copying between memory modules
US10423411B2 (en) * 2015-09-26 2019-09-24 Intel Corporation Data element comparison processors, methods, systems, and instructions
US10042749B2 (en) 2015-11-10 2018-08-07 International Business Machines Corporation Prefetch insensitive transactional memory
US10387309B2 (en) 2015-10-14 2019-08-20 Elastifile Ltd. High-performance distributed caching
KR101843243B1 (ko) * 2015-10-30 2018-03-29 세종대학교산학협력단 제로값을 피연산자로 갖는 연산자에 대한 연산을 스킵하는 연산 방법 및 연산 장치
US9558156B1 (en) * 2015-11-24 2017-01-31 International Business Machines Corporation Sparse matrix multiplication using a single field programmable gate array module
CN106886429B (zh) 2015-12-16 2020-11-06 华为技术有限公司 一种加载驱动程序的方法和服务器
US20170177336A1 (en) 2015-12-22 2017-06-22 Intel Corporation Hardware cancellation monitor for floating point operations
US9996320B2 (en) 2015-12-23 2018-06-12 Intel Corporation Fused multiply-add (FMA) low functional unit
KR102604737B1 (ko) 2016-01-11 2023-11-22 삼성전자주식회사 가속 구조를 생성하는 방법 및 장치
US10762164B2 (en) * 2016-01-20 2020-09-01 Cambricon Technologies Corporation Limited Vector and matrix computing device
US20170214930A1 (en) 2016-01-26 2017-07-27 Sandia Corporation Gpu-assisted lossless data compression
US9778871B1 (en) 2016-03-27 2017-10-03 Qualcomm Incorporated Power-reducing memory subsystem having a system cache and local resource management
CN107315718B (zh) * 2016-04-26 2020-08-21 中科寒武纪科技股份有限公司 一种用于执行向量内积运算的装置和方法
US20170308800A1 (en) 2016-04-26 2017-10-26 Smokescreen Intelligence, LLC Interchangeable Artificial Intelligence Perception Systems and Methods
US10509732B2 (en) 2016-04-27 2019-12-17 Advanced Micro Devices, Inc. Selecting cache aging policy for prefetches based on cache test regions
CN107346148A (zh) 2016-05-04 2017-11-14 杭州海存信息技术有限公司 基于背面查找表的仿真处理器
US9846579B1 (en) 2016-06-13 2017-12-19 Apple Inc. Unified integer and floating-point compare circuitry
US10176099B2 (en) 2016-07-11 2019-01-08 Intel Corporation Using data pattern to mark cache lines as invalid
JP6665720B2 (ja) 2016-07-14 2020-03-13 富士通株式会社 情報処理装置、コンパイルプログラム、コンパイル方法、およびキャッシュ制御方法
US20180018266A1 (en) 2016-07-18 2018-01-18 Advanced Micro Devices, Inc. Stride prefetcher for inconsistent strides
US10034407B2 (en) 2016-07-22 2018-07-24 Intel Corporation Storage sled for a data center
US10242311B2 (en) * 2016-08-11 2019-03-26 Vivante Corporation Zero coefficient skipping convolution neural network engine
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
US10467195B2 (en) 2016-09-06 2019-11-05 Samsung Electronics Co., Ltd. Adaptive caching replacement manager with dynamic updating granulates and partitions for shared flash-based storage system
US20180107602A1 (en) 2016-10-13 2018-04-19 Intel Corporation Latency and Bandwidth Efficiency Improvement for Read Modify Write When a Read Operation is Requested to a Partially Modified Write Only Cacheline
US11315018B2 (en) 2016-10-21 2022-04-26 Nvidia Corporation Systems and methods for pruning neural networks for resource efficient inference
US10216479B2 (en) 2016-12-06 2019-02-26 Arm Limited Apparatus and method for performing arithmetic operations to accumulate floating-point numbers
CN106683036A (zh) 2016-12-12 2017-05-17 中国航空工业集团公司西安航空计算技术研究所 一种面向gpu高效绘制的帧缓冲区存储编码方法
US10452551B2 (en) 2016-12-12 2019-10-22 Intel Corporation Programmable memory prefetcher for prefetching multiple cache lines based on data in a prefetch engine control register
KR20180069461A (ko) 2016-12-15 2018-06-25 삼성전자주식회사 가속 구조를 생성하는 방법 및 장치
US20180173623A1 (en) 2016-12-21 2018-06-21 Qualcomm Incorporated Reducing or avoiding buffering of evicted cache data from an uncompressed cache memory in a compressed memory system to avoid stalling write operations
US20180183577A1 (en) 2016-12-28 2018-06-28 Intel Corporation Techniques for secure message authentication with unified hardware acceleration
US10558575B2 (en) 2016-12-30 2020-02-11 Intel Corporation Processors, methods, and systems with a configurable spatial accelerator
US10146738B2 (en) * 2016-12-31 2018-12-04 Intel Corporation Hardware accelerator architecture for processing very-sparse and hyper-sparse matrix data
DK3812900T3 (da) 2016-12-31 2024-02-12 Intel Corp Systemer, fremgangsmåder og apparater til heterogen beregning
US20180210836A1 (en) 2017-01-24 2018-07-26 Microsoft Technology Licensing, Llc Thermal and reliability based cache slice migration
US10430912B2 (en) 2017-02-14 2019-10-01 Qualcomm Incorporated Dynamic shader instruction nullification for graphics processing
GB2560159B (en) 2017-02-23 2019-12-25 Advanced Risc Mach Ltd Widening arithmetic in a data processing apparatus
US10409887B1 (en) * 2017-02-28 2019-09-10 Ambarella, Inc. Generalized dot product for computer vision applications
KR102499396B1 (ko) * 2017-03-03 2023-02-13 삼성전자 주식회사 뉴럴 네트워크 장치 및 뉴럴 네트워크 장치의 동작 방법
US10229059B2 (en) 2017-03-31 2019-03-12 Intel Corporation Dynamic fill policy for a shared cache
US10303602B2 (en) 2017-03-31 2019-05-28 Advanced Micro Devices, Inc. Preemptive cache management policies for processing units
US10423415B2 (en) 2017-04-01 2019-09-24 Intel Corporation Hierarchical general register file (GRF) for execution block
US10503652B2 (en) 2017-04-01 2019-12-10 Intel Corporation Sector cache for compression
US10304421B2 (en) 2017-04-07 2019-05-28 Intel Corporation Apparatus and method for remote display and content protection in a virtualized graphics processing environment
US10861216B2 (en) 2017-04-07 2020-12-08 Intel Corporation Ray tracing apparatus and method for memory access and register operations
US10346944B2 (en) * 2017-04-09 2019-07-09 Intel Corporation Machine learning sparse computation mechanism
US10824938B2 (en) * 2017-04-24 2020-11-03 Intel Corporation Specialized fixed function hardware for efficient convolution
US10409614B2 (en) 2017-04-24 2019-09-10 Intel Corporation Instructions having support for floating point and integer data types in the same register
US10403003B2 (en) * 2017-04-24 2019-09-03 Intel Corporation Compression mechanism
US10186011B2 (en) * 2017-04-28 2019-01-22 Intel Corporation Programmable coarse grained and sparse matrix compute hardware with advanced scheduling
US10474458B2 (en) 2017-04-28 2019-11-12 Intel Corporation Instructions and logic to perform floating-point and integer operations for machine learning
US10726514B2 (en) 2017-04-28 2020-07-28 Intel Corporation Compute optimizations for low precision machine learning operations
US11488008B2 (en) 2017-05-05 2022-11-01 Intel Corporation Hardware implemented point to point communication primitives for machine learning
US10776699B2 (en) * 2017-05-05 2020-09-15 Intel Corporation Optimized compute hardware for machine learning operations
US10338919B2 (en) 2017-05-08 2019-07-02 Nvidia Corporation Generalized acceleration of matrix multiply accumulate operations
CN117273096A (zh) 2017-05-17 2023-12-22 谷歌有限责任公司 在硬件中执行矩阵乘法
US20180336136A1 (en) 2017-05-17 2018-11-22 Qualcomm Incorporated Input/output-coherent Look-ahead Cache Access
US10102015B1 (en) 2017-06-22 2018-10-16 Microsoft Technology Licensing, Llc Just in time GPU executed program cross compilation
US10282299B2 (en) 2017-06-23 2019-05-07 Cavium, Llc Managing cache partitions based on cache usage information
US10984049B2 (en) 2017-06-27 2021-04-20 Nvidia Corporation Performing traversal stack compression
US10969740B2 (en) 2017-06-27 2021-04-06 Nvidia Corporation System and method for near-eye light field rendering for wide field of view interactive three-dimensional computer graphics
US10990648B2 (en) 2017-08-07 2021-04-27 Intel Corporation System and method for an optimized winograd convolution accelerator
US10394456B2 (en) 2017-08-23 2019-08-27 Micron Technology, Inc. On demand memory page size
US11232531B2 (en) 2017-08-29 2022-01-25 Intel Corporation Method and apparatus for efficient loop processing in a graphics hardware front end
US10691572B2 (en) 2017-08-30 2020-06-23 Nvidia Corporation Liveness as a factor to evaluate memory vulnerability to soft errors
US10725740B2 (en) * 2017-08-31 2020-07-28 Qualcomm Incorporated Providing efficient multiplication of sparse matrices in matrix-processor-based devices
US10503507B2 (en) * 2017-08-31 2019-12-10 Nvidia Corporation Inline data inspection for workload simplification
US10943171B2 (en) 2017-09-01 2021-03-09 Facebook, Inc. Sparse neural network training optimization
US10503520B2 (en) 2017-09-26 2019-12-10 Intel Corporation Automatic waking of power domains for graphics configuration requests
US10782904B2 (en) 2017-09-28 2020-09-22 Intel Corporation Host computing arrangement, remote server arrangement, storage system and methods thereof
US10692244B2 (en) 2017-10-06 2020-06-23 Nvidia Corporation Learning based camera pose estimation from images of an environment
US11222256B2 (en) * 2017-10-17 2022-01-11 Xilinx, Inc. Neural network processing system having multiple processors and a neural network accelerator
GB2569274B (en) 2017-10-20 2020-07-15 Graphcore Ltd Synchronization amongst processor tiles
GB2569271B (en) 2017-10-20 2020-05-13 Graphcore Ltd Synchronization with a host processor
GB2569844B (en) 2017-10-20 2021-01-06 Graphcore Ltd Sending data off-chip
GB2569098B (en) 2017-10-20 2020-01-08 Graphcore Ltd Combining states of multiple threads in a multi-threaded processor
US11651223B2 (en) * 2017-10-27 2023-05-16 Baidu Usa Llc Systems and methods for block-sparse recurrent neural networks
KR102414047B1 (ko) 2017-10-30 2022-06-29 에스케이하이닉스 주식회사 통합 메모리 디바이스 및 그의 동작 방법
US10762137B1 (en) 2017-11-15 2020-09-01 Amazon Technologies, Inc. Page table search engine
US10762620B2 (en) 2017-11-27 2020-09-01 Nvidia Corporation Deep-learning method for separating reflection and transmission images visible at a semi-reflective surface in a computer image of a real-world scene
US11977974B2 (en) 2017-11-30 2024-05-07 International Business Machines Corporation Compression of fully connected / recurrent layers of deep network(s) through enforcing spatial locality to weight matrices and effecting frequency compression
US10579535B2 (en) 2017-12-15 2020-03-03 Intel Corporation Defragmented and efficient micro-operation cache
EP3783477B1 (de) * 2017-12-27 2021-11-17 Cambricon Technologies Corporation Limited Integrierte schaltungschipvorrichtung
US10482156B2 (en) * 2017-12-29 2019-11-19 Facebook, Inc. Sparsity-aware hardware accelerators
KR102533241B1 (ko) 2018-01-25 2023-05-16 삼성전자주식회사 적응적으로 캐시 일관성을 제어하도록 구성된 이종 컴퓨팅 시스템
US10970080B2 (en) * 2018-02-08 2021-04-06 Marvell Asia Pte, Ltd. Systems and methods for programmable hardware architecture for machine learning
US11693627B2 (en) * 2018-02-09 2023-07-04 Deepmind Technologies Limited Contiguous sparsity pattern neural networks
US10755201B2 (en) 2018-02-14 2020-08-25 Lucid Circuit, Inc. Systems and methods for data collection and analysis at the edge
JP2019148969A (ja) * 2018-02-27 2019-09-05 富士通株式会社 行列演算装置、行列演算方法および行列演算プログラム
US20190278593A1 (en) 2018-03-09 2019-09-12 Nvidia Corporation Accelerating linear algebra kernels for any processor architecture
US20190278600A1 (en) 2018-03-09 2019-09-12 Nvidia Corporation Tiled compressed sparse matrix format
US10678508B2 (en) 2018-03-23 2020-06-09 Amazon Technologies, Inc. Accelerated quantized multiply-and-add operations
US10572568B2 (en) 2018-03-28 2020-02-25 Intel Corporation Accelerator for sparse-dense matrix multiplication
EP3777166A1 (de) 2018-04-13 2021-02-17 Koninklijke KPN N.V. Auf superauflösung basierende videocodierung auf frame-ebene
US11010092B2 (en) 2018-05-09 2021-05-18 Micron Technology, Inc. Prefetch signaling in memory system or sub-system
US10572409B1 (en) * 2018-05-10 2020-02-25 Xilinx, Inc. Sparse matrix processing circuitry
US11269805B2 (en) 2018-05-15 2022-03-08 Intel Corporation Signal pathways in multi-tile processors
GB2574060B (en) * 2018-05-25 2022-11-23 Myrtle Software Ltd Processing matrix vector multiplication
US10838864B2 (en) 2018-05-30 2020-11-17 Advanced Micro Devices, Inc. Prioritizing local and remote memory access in a non-uniform memory access architecture
US10699468B2 (en) 2018-06-09 2020-06-30 Adshir Ltd. Method for non-planar specular reflections in hybrid ray tracing
US10620951B2 (en) 2018-06-22 2020-04-14 Intel Corporation Matrix multiplication acceleration of sparse matrices using column folding and squeezing
US20190392287A1 (en) * 2018-06-22 2019-12-26 Samsung Electronics Co., Ltd. Neural processor
CN113190791A (zh) 2018-08-06 2021-07-30 华为技术有限公司 矩阵的处理方法、装置及逻辑电路
EP3608828A1 (de) * 2018-08-09 2020-02-12 Olympus Soft Imaging Solutions GmbH Verfahren zur bereitstellung eines auswertungsmittels für wenigstens ein optisches anwendungssystem einer mikroskopischen anwendungstechnologie
KR20200022118A (ko) 2018-08-22 2020-03-03 에스케이하이닉스 주식회사 데이터 저장 장치 및 그 동작 방법
US20190042457A1 (en) 2018-08-22 2019-02-07 Intel Corporation Cache (partition) size determination method and apparatus
US11833681B2 (en) * 2018-08-24 2023-12-05 Nvidia Corporation Robotic control system
US10846241B2 (en) 2018-08-29 2020-11-24 Vmware, Inc. Score-based cache admission and eviction
US11093248B2 (en) 2018-09-10 2021-08-17 International Business Machines Corporation Prefetch queue allocation protection bubble in a processor
US10817426B2 (en) 2018-09-24 2020-10-27 Arm Limited Prefetching techniques
US10853067B2 (en) 2018-09-27 2020-12-01 Intel Corporation Computer processor for higher precision computations using a mixed-precision decomposition of operations
US11294626B2 (en) 2018-09-27 2022-04-05 Intel Corporation Floating-point dynamic range expansion
CN112384900A (zh) 2018-09-28 2021-02-19 英特尔公司 用于实现自适应页面大小的转换后备缓冲器
GB2578097B (en) 2018-10-15 2021-02-17 Advanced Risc Mach Ltd Cache control circuitry and methods
US10768895B2 (en) * 2018-11-08 2020-09-08 Movidius Limited Dot product calculators and methods of operating the same
US11366663B2 (en) 2018-11-09 2022-06-21 Intel Corporation Systems and methods for performing 16-bit floating-point vector dot product instructions
US10963246B2 (en) 2018-11-09 2021-03-30 Intel Corporation Systems and methods for performing 16-bit floating-point matrix dot product instructions
US20200175074A1 (en) 2018-12-04 2020-06-04 Vmware, Inc. Tree structure aware cache eviction policy
US20200202195A1 (en) 2018-12-06 2020-06-25 MIPS Tech, LLC Neural network processing using mixed-precision data representation
US11893470B2 (en) 2018-12-06 2024-02-06 MIPS Tech, LLC Neural network processing using specialized data representation
US11615307B2 (en) 2018-12-06 2023-03-28 MIPS Tech, LLC Neural network data computation using mixed-precision
GB2580151B (en) 2018-12-21 2021-02-24 Graphcore Ltd Identifying processing units in a processor
US10909741B2 (en) 2018-12-28 2021-02-02 Intel Corporation Speculative execution of hit and intersection shaders on programmable ray tracing architectures
US10832371B2 (en) 2018-12-28 2020-11-10 Intel Corporation Unified architecture for BVH construction based on hardware pre-sorting and a parallel, reconfigurable clustering array
KR20200091623A (ko) * 2019-01-23 2020-07-31 삼성전자주식회사 위노그라드 변환에 기반한 뉴럴 네트워크의 컨볼루션 연산을 수행하는 방법 및 장치
US11106600B2 (en) 2019-01-24 2021-08-31 Advanced Micro Devices, Inc. Cache replacement based on translation lookaside buffer evictions
US10725923B1 (en) 2019-02-05 2020-07-28 Arm Limited Cache access detection and prediction
US10915461B2 (en) 2019-03-05 2021-02-09 International Business Machines Corporation Multilevel cache eviction management
US11934342B2 (en) 2019-03-15 2024-03-19 Intel Corporation Assistance for hardware prefetch in cache access
US20220121421A1 (en) 2019-03-15 2022-04-21 Intel Corporation Multi-tile memory management
DE112020001249T5 (de) 2019-03-15 2021-12-23 Intel Corporation Dünnbesetzt-Optimierungen für eine Matrixbeschleunigerarchitektur
WO2020190796A1 (en) 2019-03-15 2020-09-24 Intel Corporation Systems and methods for cache optimization
US11036642B2 (en) 2019-04-26 2021-06-15 Intel Corporation Architectural enhancements for computing systems having artificial intelligence logic disposed locally to memory
US11675998B2 (en) 2019-07-15 2023-06-13 Meta Platforms Technologies, Llc System and method for performing small channel count convolutions in energy-efficient input operand stationary accelerator
US11861761B2 (en) 2019-11-15 2024-01-02 Intel Corporation Graphics processing unit processing and caching improvements
US11663746B2 (en) 2019-11-15 2023-05-30 Intel Corporation Systolic arithmetic on sparse data
US11275561B2 (en) 2019-12-12 2022-03-15 International Business Machines Corporation Mixed precision floating-point multiply-add operation
US11645145B2 (en) 2019-12-16 2023-05-09 Qualcomm Incorporated Methods and apparatus to facilitate speculative page fault handling in a graphics processing unit
US20220100518A1 (en) 2020-09-25 2022-03-31 Advanced Micro Devices, Inc. Compression metadata assisted computation
US20220197975A1 (en) 2020-12-23 2022-06-23 Intel Corporation Apparatus and method for conjugate transpose and multiply
US20220335563A1 (en) 2021-07-06 2022-10-20 Intel Corporation Graphics processing unit with network interfaces

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
Shane Cook, CUDA Programming Kapitel 3, Seiten 37-51 (2013)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11361496B2 (en) 2019-03-15 2022-06-14 Intel Corporation Graphics processors and graphics processing units having dot product accumulate instruction for hybrid floating point format
US11676239B2 (en) 2019-03-15 2023-06-13 Intel Corporation Sparse optimizations for a matrix accelerator architecture
US11709793B2 (en) 2019-03-15 2023-07-25 Intel Corporation Graphics processors and graphics processing units having dot product accumulate instruction for hybrid floating point format
US11842423B2 (en) 2019-03-15 2023-12-12 Intel Corporation Dot product operations on sparse matrix elements
US11954063B2 (en) 2019-03-15 2024-04-09 Intel Corporation Graphics processors and graphics processing units having dot product accumulate instruction for hybrid floating point format

Also Published As

Publication number Publication date
US20210374897A1 (en) 2021-12-02
JP2022523761A (ja) 2022-04-26
JP7423644B2 (ja) 2024-01-29
US20230351543A1 (en) 2023-11-02
JP2024036383A (ja) 2024-03-15
US11676239B2 (en) 2023-06-13
BR112021016106A2 (pt) 2021-11-09
DE112020001249T5 (de) 2021-12-23
CN112534404A (zh) 2021-03-19
WO2020190808A1 (en) 2020-09-24
EP3938889A1 (de) 2022-01-19
US20240161227A1 (en) 2024-05-16
AU2020241262A1 (en) 2021-11-04
WO2020190809A1 (en) 2020-09-24
KR20210135998A (ko) 2021-11-16
CN113383310A (zh) 2021-09-10
JP2022523762A (ja) 2022-04-26
EP3938890A1 (de) 2022-01-19
SG11202107290QA (en) 2021-09-29
JP7408671B2 (ja) 2024-01-05
US20210035258A1 (en) 2021-02-04
JP2022523760A (ja) 2022-04-26
CN112905241A (zh) 2021-06-04
KR20210135999A (ko) 2021-11-16
CN112905241B (zh) 2024-03-29
EP3938888A1 (de) 2022-01-19
CN112534405A (zh) 2021-03-19
BR112021016138A2 (pt) 2022-01-04
US11842423B2 (en) 2023-12-12
KR20210136994A (ko) 2021-11-17
US11113784B2 (en) 2021-09-07
WO2020190807A1 (en) 2020-09-24
US20210103550A1 (en) 2021-04-08
CN112905240A (zh) 2021-06-04

Similar Documents

Publication Publication Date Title
DE112020000846T5 (de) Architektur für Block-Sparse-Operationen an einem systolischen Array
US20220129521A1 (en) Systolic disaggregation within a matrix accelerator architecture
DE102020130078A1 (de) Systolische arithmetik an spärlichen daten
DE102018133555A1 (de) Berechnungsoptimierungsmechanismus für tiefe neuronale Netze
DE102020120372A1 (de) Programmierbare wandlungshardware
DE102018110380A1 (de) Tool zum Ermöglichen der Effizienz beim Maschinenlernen
DE102018110687A1 (de) Dynamisches Genauigkeitsmanagement für Deep-Learning-Ganzzahlprimitive
DE102020129251A1 (de) Adaptives verformbares kernvorhersagenetzwerk zum bildentrauschen
DE102020129970A1 (de) Systeme und verfahren zur fehlererkennung und steuerung für eingebettete arbeitsspeicher- und rechenelemente
DE102020130073A1 (de) Verbesserung der datenlokalität für grafikprozessoreinheiten
DE112020000464T5 (de) Mehrfachkachel-grafikprozessor-rendering
DE102020129969A1 (de) Verbesserungen der verarbeitung und des caching von graphikverarbeitungseinheiten
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
DE102020130865A1 (de) Anweisungen und logik für vektor-multiplikation-addition mit zero-skipping
DE102020129432A1 (de) System und Verfahren zum Anpassen eines ausführbaren Objekts an eine Verarbeitungseinheit
DE102020130995A1 (de) Verfahren und vorrichtung zur codierung basierend auf wichtigkeitswerten
DE102022125600A1 (de) Eingabefilterung und abtaster-beschleunigung für supersampling
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
DE102022130862A1 (de) Niederleistungs-inferenz-engine-pipeline in einer grafikverarbeitungseinheit

Legal Events

Date Code Title Description
R082 Change of representative

Representative=s name: SAMSON & PARTNER PATENTANWAELTE MBB, DE

R130 Divisional application to

Ref document number: 112020003570

Country of ref document: DE