DE102020130078A1 - Systolische arithmetik an spärlichen daten - Google Patents

Systolische arithmetik an spärlichen daten Download PDF

Info

Publication number
DE102020130078A1
DE102020130078A1 DE102020130078.6A DE102020130078A DE102020130078A1 DE 102020130078 A1 DE102020130078 A1 DE 102020130078A1 DE 102020130078 A DE102020130078 A DE 102020130078A DE 102020130078 A1 DE102020130078 A1 DE 102020130078A1
Authority
DE
Germany
Prior art keywords
graphics
data
memory
processor
processing
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
DE102020130078.6A
Other languages
English (en)
Inventor
Abhishek R. Appu
Prasoonkumar Surti
Jill Boyce
Subramaniam Maiyuran
Michael Apodaca
Adam T. Lake
James Holland
Vasanth Ranganathan
Altug Koker
Lidong Xu
Nikos Kaburlasos
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 DE102020130078A1 publication Critical patent/DE102020130078A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T9/00—Image coding
    • G06T9/002—Image coding using neural networks
    • 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/3877—Concurrent instruction execution, e.g. pipeline or look ahead using a slave processor, e.g. coprocessor
    • 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
    • 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/22—Microcontrol or microprogram arrangements
    • G06F9/28—Enhancement of operational speed, e.g. by using several microcontrol devices operating in parallel
    • 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/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • 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/044—Recurrent networks, e.g. Hopfield networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/02—Neural networks
    • G06N3/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/08—Learning methods
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T1/00—General purpose image data processing
    • G06T1/20—Processor architectures; Processor configuration, e.g. pipelining
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T15/00—3D [Three Dimensional] image rendering
    • G06T15/005—General purpose rendering architectures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T9/00—Image coding
    • G06T9/007—Transform coding, e.g. discrete cosine transform
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T9/00—Image coding
    • G06T9/008—Vector quantisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/42—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation
    • 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/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45579—I/O management, e.g. providing access to device drivers or storage
    • 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/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45583—Memory management, e.g. access or allocation
    • 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/08—Learning methods
    • G06N3/084—Backpropagation, e.g. using gradient descent

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mathematical Physics (AREA)
  • Data Mining & Analysis (AREA)
  • Computing Systems (AREA)
  • Evolutionary Computation (AREA)
  • Artificial Intelligence (AREA)
  • Multimedia (AREA)
  • Mathematical Analysis (AREA)
  • Mathematical Optimization (AREA)
  • Biomedical Technology (AREA)
  • Molecular Biology (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Computational Mathematics (AREA)
  • Computational Linguistics (AREA)
  • Biophysics (AREA)
  • Pure & Applied Mathematics (AREA)
  • Algebra (AREA)
  • Databases & Information Systems (AREA)
  • Computer Hardware Design (AREA)
  • Computer Graphics (AREA)
  • Discrete Mathematics (AREA)
  • Signal Processing (AREA)
  • Image Generation (AREA)
  • Complex Calculations (AREA)
  • Image Processing (AREA)

Abstract

Hier beschriebene Ausführungsformen stellen einen Befehl und zugehörige Logik bereit, um einer Verarbeitungsressource, die einen Tensor-Beschleuniger aufweist, zu ermöglichen, optimierte Berechnung von Sparse-Teilmatrixoperationen durchzuführen. Eine Ausführungsform stellt Hardwarelogik bereit, um eine numerische Transformation an Matrixdaten anzuwenden, um die Spärlichkeit der Daten zu erhöhen. Erhöhen der Spärlichkeit kann zu einem höheren Kompressionsverhältnis führen, wenn die Matrixdaten komprimiert werden.

Description

  • QUERVERWEIS
  • Diese Anmeldung beansprucht Priorität der vorläufigen US-Patentanmeldung Nr. 62/935,670 , eingereicht am 15. November 2019, die hiermit zur Bezugnahme aufgenommen wird.
  • GEBIET
  • Diese Offenbarung betrifft im Allgemeinen Datenverarbeitung und insbesondere Datenverarbeitung über eine Allzweckgrafikverarbeitungseinheit.
  • HINTERGRUND DER OFFENBARUNG
  • Derzeitige parallele Grafikdatenverarbeitung weist Systeme und Verfahren auf, die entwickelt sind, um bestimmte Operationen an Grafikdaten durchzuführen wie zum Beispiel lineare Interpolation, Tessellation, Rasterung, Texturabbildung, Tiefentestung usw. Üblicherweise verwendeten Grafikprozessoren Festfunktion-Recheneinheiten zur Verarbeitung von Grafikdaten. Kürzlich jedoch wurden Teile von Grafikprozessoren programmierbar gemacht, um solchen Prozessoren zu ermöglichen, eine größere Vielzahl von Operationen zur Verarbeitung von Vertex- und Fragmentdaten zu unterstützen.
  • Zur weiteren Erhöhung von Arbeitsleistung implementieren Grafikprozessoren typischerweise Verarbeitungstechniken wie Pipelining, die versuchen, soviel Grafikdaten wie möglich in allen verschiedenen Teilen der Grafik-Pipeline parallel zu verarbeiten. Parallele Grafikprozessoren mit Einzelbefehl, Mehrfach-Thread (SIMT, Single Instruction, Multiple Thread) Architekturen sind gestaltet, die Menge an paralleler Verarbeitung in der Grafik-Pipeline zu maximieren. In einer SIMT-Architektur versuchen Gruppen paralleler Threads, Programmbefehle gemeinsam synchron so häufig wie möglich auszuführen, um Verarbeitungseffizienz zu erhöhen. Ein allgemeiner Überblick von Software und Hardware für SIMT-Architekturen findet sich in Shane Cook, CUDA Programming Kapitel 3, Seiten 37-51 (2013).
  • Figurenliste
  • Für ein besseres Verständnis der Einzelheiten der oben angeführten Merkmale der vorliegenden Ausführungsformen folgt eine genauere Beschreibung der Ausführungsformen, die oben kurz zusammengefasst sind, unter Bezugnahme auf Ausführungsformen, von welchen manche in den beiliegenden Zeichnungen veranschaulicht sind. Es wird jedoch festgehalten, dass die beiliegenden Zeichnungen nur typische Ausführungsformen veranschaulichen und daher nicht als Einschränkung des Umfangs auszulegen sind.
    • 1 ist ein Blockdiagramm, das ein Computersystem veranschaulicht, das konfiguriert ist, einen oder mehrere Aspekte der hier beschriebenen Ausführungsformen zu implementieren;
    • 2A-2D veranschaulichen parallele Prozessorkomponenten;
    • 3A-3C sind Blockdiagramme von Grafikmultiprozessoren und Multiprozessor-basierten GPUs;
    • 4A-4F veranschaulichen eine beispielhafte Architektur, in der mehrere GPUs kommunikativ an mehrere Mehrfachkernprozessoren gekoppelt sind;
    • 5 veranschaulicht eine Grafikverarbeitungs-Pipeline;
    • 6 veranschaulicht einen Maschinenlern-Softwarestapel;
    • 7 veranschaulicht eine Allzweckgrafikverarbeitungseinheit;
    • 8 veranschaulicht ein Multi-GPU-Rechensystem;
    • 9A-9B veranschaulichen Schichten beispielhafter tiefer neuraler Netzwerke;
    • 10 veranschaulicht ein beispielhaftes rekurrentes neurales Netzwerk;
    • 11 veranschaulicht Training und Nutzung eines tiefen neuralen Netzwerks;
    • 12A ist ein Blockdiagramm, das verteiltes Lernen veranschaulicht;
    • 12B ist ein Blockdiagramm, das eine programmierbare Netzwerkschnittstelle zum Beschleunigen von verteiltem Lernen veranschaulicht;
    • 13 veranschaulicht ein beispielhaftes Schlussfolgerungssystem auf einem Chip (SOC, System on a Chip), das zum Durchführen von Schlussfolgerungen unter Verwendung eines Trainingsmodells imstande ist;
    • 14 ist ein Blockdiagramm eines Verarbeitungssystems;
    • 15A-15C veranschaulichen Rechensysteme und Grafikprozessoren;
    • 16A-16C veranschaulichen Blockdiagramme zusätzlicher Grafikprozessor- und Rechenbeschleunigerarchitekturen;
    • 17 ist ein Blockdiagramm einer Grafikverarbeitungs-Engine eines Grafikprozessors ;
    • 18A-18B veranschaulichen Thread-Ausfiihrungslogik, die ein Array von Verarbeitungselementen aufweist, die in einem Grafikprozessorkern eingesetzt werden;
    • 19 veranschaulicht eine zusätzliche Ausführungseinheit;
    • 20 ist ein Blockdiagramm, das ein Grafikprozessorbefehlsformat veranschaulicht;
    • 21 ist ein Blockdiagramm einer zusätzlichen Grafikprozessorarchitektur;
    • 22A-22B veranschaulichen ein Grafikprozessorsteuerbefehlsformat und eine Steuerbefehlsabfolge;
    • 23 veranschaulicht beispielhafte Grafik-Softwarearchitektur für ein Datenverarbeitungssystem;
    • 24A ist ein Blockdiagramm, das ein IP-Kernentwicklungssystem veranschaulicht;
    • 24B veranschaulicht eine Seitenquerschnittsansicht einer integrierten Schaltungs-Package-Anordnung;
    • 24C veranschaulicht eine Package-Anordnung, die mehrere Einheiten von Hardwarelogik-Chiplets aufweist, die mit einem Substrat (z.B. Basis-Die) verbunden sind;
    • 24D veranschaulicht eine Package-Anordnung, die austauschbare Chiplets aufweist;
    • 25 ist ein Blockdiagramm, das eine beispielhafte integrierte System-aufeinem-Chip-Schaltung 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 Befehls-Pipeline durchgeführt wird, gemäß einer Ausführungsform;
    • 29A-29B veranschaulichen Einzelheiten von Hardware-basiertem systolischen Tensor-Array gemäß manchen Ausführungsformen;
    • 30 veranschaulicht eine Verarbeitungsressource gemäß einer Ausführungsform, die ein systolisches Tensor-Array mit Sparse-Optimierungen aufweist;
    • 31A-31B veranschaulicht ein System zum Umgehen von Nullwert-Teilmatrizen gemäß Ausführungsformen;
    • 32 veranschaulicht eine Rechenressource, die Logik aufweist, um das systolische Tensor-Array für Operationen auf einer Teilmatrix zu umgehen, die einen einzelnen Nicht-Null-Wert aufweisen;
    • 33 veranschaulicht eine Rechenarchitektur gemäß einer Ausführungsform, die konfiguriert ist, komprimierte Übertragung neuraler Netzwerkdaten zu ermöglichen;
    • 34A-34B veranschaulicht Signifikanzkartencodierung für spärliche neurale Netzwerkdaten gemäß Ausführungsformen;
    • 35 veranschaulicht die Verwendung von Signifikanzkartendaten, um das Umgehen oder Takt/Leistung-Gating von Elementen eines systolischen Tensor-Arrays zu erleichtern;
    • 36 veranschaulicht ein System zum Transformieren spärlicher neuraler Netzwerkdaten, um Nicht-Null-Koeffizienten zu verdichten, gemäß einer Ausführungsform;
    • 37A-37B veranschaulicht Logikeinheiten zur Durchführung von Transformationen und inverser Transformationen an spärlichen neuralen Netzwerkdaten;
    • 38A-38B veranschaulichen Verfahren zum Erzeugen und Verwenden transformierter Matrizen auf einem Grafikprozessor;
    • 39 veranschaulicht eine Version des systolischen Tensor-Arrays, das konfiguriert ist, komprimierte oder codierte Daten zu bearbeiten; und
    • 40 veranschaulicht ein Verfahren zum Durchführen systolischer Arithmetik an komprimierten oder codierten Daten; und
    • 41 ist ein Blockdiagramm einer Rechenvorrichtung gemäß einer Ausführungsform, die einen Grafikprozessor aufweist.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Eine Grafikverarbeitungseinheit (GPU) ist kommunikativ an Host/Prozessorkerne gekoppelt, um zum Beispiel Grafikoperationen, Maschinenlemoperationen, Strukturanalyseoperationen und/oder verschiedene Allzweck-GPU (GPGPU) Funktionen zu beschleunigen. Die GPU kann über einen Bus oder ein anderes Interconnect (z.B. ein Hochgeschwindigkeit-Interconnect wie PCIe oder NVLink) kommunikativ an den Host-Prozessor/Kerne gebunden sein. Alternativ kann die GPU auf demselben Package oder Chip wie die Kerne integriert und über einen internen Prozessorbus/Interconnect (d.h. intern des Packages oder Chips) kommunikativ an die Kerne gekoppelt sein. Unabhängig von der Art, in der die GPU verbunden ist, können die Prozessorkerne der GPU Arbeit in der Form von Abfolgen von Steuerbefehlen/Befehlen zuordnen, die in einer Arbeitsbeschreibung enthalten sind. Die GPU verwendet dann dedizierten Schaltkreis/Logik zur effizienten Verarbeitung dieser Steuerbefehle/Befehle.
  • In der folgenden Beschreibung sind zahlreiche bestimmte Einzelheiten angeführt, um ein umfassenderes Verständnis zu ermöglichen. Einem Fachmann auf dem Gebiet ist jedoch klar, dass die hier beschriebenen Ausführungsformen ohne eine oder mehrere dieser bestimmten Einzelheiten in die Praxis umgesetzt werden können. In anderen Fällen sind allgemein bekannte Merkmale nicht beschrieben, um eine Verschleierung der Einzelheiten der vorliegenden Ausführungsformen zu vermeiden.
  • Systemüberblick
  • 1 ist ein Blockdiagramm, das ein Rechensystem 100 veranschaulicht, das konfiguriert ist, einen oder mehrere Aspekte der hier beschriebenen Ausführungsformen zu implementieren. Das Rechensystem 100 weist ein Verarbeitungsteilsystem 101 mit einem oder mehreren Prozessor(en) 102 und einem Systemspeicher 104 auf, die über einen Zwischenverbindungspfad kommunizieren, der einen Speicher-Hub 105 aufweisen kann. Der Speicher-Hub 105 kann eine separate Komponente in einer Chipset-Komponente sein oder kann in dem einen oder den mehreren Prozessor(en) 102 integriert sein. Der Speicher-Hub 105 ist mit einem I/O-Teilsystem 111 über einen Kommunikationslink 106 gekoppelt. Das I/O-Teilsystem 111 weist einen I/O-Hub 107 auf, der dem Rechensystem 100 ermöglichen kann, Eingang von einer oder mehreren Eingabevorrichtung(en) 108 zu empfangen. Zusätzlich kann der I/O-Hub 107 einer Anzeigesteuerung, die in dem einen oder den mehreren Prozessor(en) 102 enthalten sein kann, ermöglichen, Ausgänge an eine oder mehrere Anzeigevorrichtung(en) 110A bereitzustellen. In einer Ausführungsform können die eine oder mehreren Anzeigevorrichtung(en) 110A, die mit dem I/O-Hub 107 gekoppelt sind, eine lokale, interne oder eingebettete Anzeigevorrichtung aufweisen.
  • Das Verarbeitungsteilsystem 101 weist zum Beispiel einen oder mehrere parallele Prozessor(en) 112 auf, die an Speicher-Hub 105 über einen Bus oder einen anderen Kommunikationslink 113 gekoppelt sind. Der Kommunikationslink 113 kann eine(s) von einer beliebigen Anzahl auf Standards basierender Kommunikationslinktechnologien oder Protokolle sein, wie, ohne aber darauf beschränkt zu sein, PCI Express, oder kann eine verkäuferbestimmte Kommunikationsschnittstelle oder ein Kommunikations-Fabric sein. Der eine oder die mehreren parallelen Prozessor(en) 112 können ein rechnerisch fokussiertes paralleles oder Vektorverarbeitungssystem sein, das eine große Anzahl von Verarbeitungskernen und/oder Verarbeitungsclustern aufweist, wie ein Prozessor mit vielen integrierten Kernen (MIC, Multi Integrated Cores). Zum Beispiel bilden der eine oder die mehreren parallelen Prozessor(en) 112 ein Grafikverarbeitungsteilsystem, das Pixel an eine der einen oder mehreren Anzeigevorrichtung(en) 110A ausgeben kann, die über den I/O-Hub 107 gekoppelt sind. Der eine oder die mehreren parallelen Prozessor(en) 112 können auch eine Anzeigesteuerung und Anzeigeschnittstelle (nicht dargestellt) aufweisen, um eine direkte Verbindung mit einer oder mehreren Anzeigevorrichtung(en) 110B zu ermöglichen.
  • In dem I/O-Teilsystem 111 kann eine Systemdatenspeichereinheit 114 mit dem I/O-Hub 107 verbunden sein, um einen Datenspeichermechanismus für das Rechensystem 100 bereitzustellen. Ein I/O-Schalter 116 kann verwendet werden, um einen Schnittstellenmechanismus bereitzustellen, der Verbindungen zwischen dem I/O-Hub 107 und anderen Komponenten ermöglicht, wie einen Netzwerkadapter 118 und/oder drahtlosen Netzwerkadapter 119, der in die Plattform integriert sein kann, und verschiedene andere Vorrichtungen können dann über eine oder mehrere Zusatzvorrichtung(en) 120 hinzugefügt werden. Die Zusatzvorrichtung(en) 120 können zum Beispiel auch eine oder mehrere externe Grafikprozessorvorrichtungen, Grafikkarten und/oder Rechenbeschleuniger aufweisen. Der Netzwerkadapter 118 kann ein Ethernet-Adapter oder ein anderer kabelgebundener Netzwerkadapter sein. Der drahtlose Netzwerkadapter 119 kann eine oder mehrere von einer Wi-Fi-, Bluetooth-, Nahfeldkommunikations- (NFC, Near Field Communication) oder anderen Netzwerkvorrichtung aufweisen, die eine oder mehrere drahtlose Funkeinrichtungen aufweist.
  • Das Rechensystem 100 kann andere Komponenten aufweisen, die nicht ausdrücklich dargestellt sind, enthaltend USB- oder andere Anschlussverbindungen, optische Datenspeicherlaufwerke, Videoaufnahmevorrichtungen und dergleichen, die auch mit dem I/O-Hub 107 verbunden sein können. Kommunikationspfade, die die verschiedenen Komponenten in 1 verbinden, können unter Verwendung geeigneter Protokolle implementiert werden, wie PCI (Peripheral Component Interconnect) basierte Protokolle (z.B. PCI-Express) oder sämtliche andere Bus- oder Punkt-zu-Punkt-Kommunikationsschnittstellen und/oder Protokoll(e), wie NVLink Hochgeschwindigkeit-Interconnect, Compute Express Link™ (CXL™) (z.B. CXL.mem), Infinity Fabric (IF), Ethernet (IEEE 802.3), ferner direkter Speicherzugriff (RDMA, Remote Direct Memory Access), InfiniBand, Internet Wide Area RDMA Protocol (iWARP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Quick UDP Internet Connections (QUIC), RDMA über Converged Ethernet (RoCE), Intel QuickPath Interconnect (QPI), Intel Ultra Path Interconnect (UPI), Intel On-Chip System Fabric (IOSF), Omnipath, HyperTransport, Advanced Microcontroller Bus Architecture (AMBA) Interconnect, OpenCAPI, Gen-Z, Cache Coherent Interconnect for Accelerators (CCIX), 3GPP Long Term Evolution (LTE) (4G), 3GPP 5G und Variationen davon, oder kabelgebundene oder drahtlose Interconnect-Protokolle, die am Stand der Technik bekannt sind. In manchen Beispielen können Daten kopiert und bei virtualisierten Datenspeicherknoten unter Verwendung eines Protokolls wie Non Volatile Memory Express (NVMe) Over Fabrics (NVMe-oF) oder NVMe gespeichert werden.
  • Der eine oder die mehreren parallelen Prozessor(en) 112 können einen Schaltkreis beinhalten, der für Grafik- und Videoverarbeitung optimiert ist, aufweisend zum Beispiel Videoausgangsschaltkreis, und eine Grafikverarbeitungseinheit (GPU) darstellt. Alternativ oder zusätzlich können der eine oder die mehreren parallelen Prozessor(en) 112 einen Schaltkreis beinhalten, der für Allzweckverarbeitung optimiert ist, während die darunterliegende Rechenarchitektur beibehalten wird, die hier in näheren Einzelheiten beschrieben ist. Komponenten des Rechensystems 100 können mit einem oder mehreren anderen Systemelementen auf einer einzelnen integrierten Schaltung integriert sein. Zum Beispiel können der eine oder die mehreren parallelen Prozessor(en) 112, Speicher-Hub 105, Prozessor(en) 102 und I/O-Hub 107 in einer integrierten Systemauf-Chip- (SoC) Schaltung integriert sein. Alternativ können die Komponenten des Rechensystems 100 in ein einzelnes Package integriert sein, um eine System-in-Package (SIP) Konfiguration zu bilden. In einer Ausführungsform kann mindestens ein Teil der Komponenten des Rechensystems 100 in ein Multi-Chip-Modul (MCM) integriert sein, das mit anderen Multi-Chip-Modulen zu einem modularen Rechensystem verbunden sein kann.
  • Es ist klar, dass das hier dargestellte Rechensystem 100 veranschaulichend ist und dass Variationen und Modifizierungen möglich sind. Die Verbindungstopologie, aufweisend die Anzahl und Anordnung von Brücken, die Anzahl von Prozessor(en) 102 und die Anzahl von parallelen Prozessor(en) 112, kann nach Wunsch modifiziert werden. Beispielsweise kann Systemspeicher 104 mit dem (den) Prozessor(en) 102 direkt und nicht durch eine Brücke verbunden sein, während andere Vorrichtungen mit Systemspeicher 104 über den Speicher-Hub 105 und die Prozessor(en) 102 kommunizieren. In anderen alternativen Topologien sind die parallelen Prozessor(en) 112 mit dem I/O-Hub 107 oder direkt mit einem des einen oder der mehreren Prozessor(en) 102 und nicht mit dem Speicher-Hub 105 verbunden. In anderen Ausführungsformen können der I/O-Hub 107 und Speicher-Hub 105 in einen einzigen Chip integriert sein. Es ist auch möglich, dass zwei oder mehr Sätze von Prozessor(en) 102 über mehrere Buchsen, die mit zwei oder mehr Exemplaren der parallelen Prozessor(en) 112 koppeln können, befestigt sind.
  • Manche der bestimmten, hier dargestellten Komponenten sind optional und können nicht in allen Implementierungen des Rechensystems 100 enthalten sein. Zum Beispiel kann eine beliebige Anzahl von Zusatzkarten oder peripheren Geräten unterstützt werden oder manche Komponenten können eliminiert werden. Überdies können manche Architekturen andere Terminologie für Komponenten verwenden, die jenen ähnlich sind, die in 1 veranschaulicht sind. Zum Beispiel kann der Speicher-Hub 105 in manchen Architekturen als Northbridge bezeichnet werden, während der I/O-Hub 107 als eine Southbridge bezeichnet werden kann.
  • 2A veranschaulicht einen parallelen Prozessor 200. Der parallele Prozessor 200 kann eine GPU, GPGPU oder dergleichen sein, wie hier beschrieben. Die verschiedenen Komponenten des parallelen Prozessors 200 können unter Verwendung einer oder mehrerer integrierter Schaltungsvorrichtungen implementiert sein, wie programmierbare Prozessoren, anwendungsspezifische integrierte Schaltungen (ASICs, Application Specific Integrated Circuits) oder feldprogrammierbare Gate-Arrays (FPGA). Der veranschaulichte parallele Prozessor 200 kann einer oder mehrerer der in 1 dargestellten parallelen Prozessor(en) 112 sein.
  • Der parallele Prozessor 200 weist eine Parallelverarbeitungseinheit 202 auf. Die Parallelverarbeitungseinheit weist eine I/O Einheit 204 auf, die Kommunikation mit anderen Vorrichtungen ermöglicht, aufweisend andere Exemplare der Parallelverarbeitungseinheit 202. Die I/O Einheit 204 kann direkt mit anderen Vorrichtungen verbunden sein. Beispielsweise ist die I/O Einheit 204 mit anderen Vorrichtungen durch Verwendung eines Hub oder einer Umschaltschnittstelle, wie Speicher-Hub 105 verbunden. Die Verbindungen zwischen dem Speicher-Hub 105 und der I/O Einheit 204 bilden einen Kommunikationslink 113. Innerhalb der Parallelverarbeitungseinheit 202 ist die I/O Einheit 204 mit einer Host Schnittstelle 206 und einer Speicher-Crossbar 216 verbunden, wo die Host-Schnittstelle 206 Steuerbefehle empfängt, die auf Durchführung von Verarbeitungsoperationen gerichtet sind, und die Speicher-Crossbar 216 Steuerbefehle empfängt, die auf Durchführung von Speicheroperationen gerichtet sind.
  • Wenn die Host-Schnittstelle 206 einen Steuerbefehlspuffer über die I/O Einheit 204 empfängt, kann die Host-Schnittstelle 206 Arbeitsoperationen lenken, um diese Steuerbefehle an einem Frontend 208 durchzuführen. In einer Ausführungsform ist das Frontend 208 mit einem Scheduler 210 gekoppelt, der konfiguriert ist, Steuerbefehle oder andere Arbeitspunkte zu einem Verarbeitungsclusterarray 212 zu verteilen. Der Scheduler 210 stellt sicher, dass das Verarbeitungsclusterarray 212 richtig konfiguriert und in einem gültigen Zustand ist, bevor Aufgaben an die Verarbeitungscluster des Verarbeitungsclusterarrays 212 verteilt werden. Der Scheduler 210 kann über Firmwarelogik implementiert werden, die auf einer Mikrosteuerung ausgeführt wird. Der Mikrosteuerung-implementierte Scheduler 210 ist konfigurierbar, um komplexe Planungs- und Arbeitsverteilungsoperationen bei grober und feiner Granularität durchzuführen, wodurch rasche Präemption und Kontextumschaltung von Threads möglich ist, die auf dem Verarbeitungsclusterarray 212 laufen. Vorzugsweise kann die Host Software Arbeitslasten zur Planung auf dem Verarbeitungsclusterarray 212 über eine von mehreren Grafikverarbeitungs-Doorbells belegen. In anderen Beispielen kann eine Abfrage nach neuen Arbeitslasten oder Unterbrechungen verwendet werden, Verfügbarkeit von durchzuführender Arbeit zu identifizieren oder anzugeben. Die Arbeitslasten können dann von der Scheduler- 210 Logik innerhalb der Scheduler-Mikrosteuerung automatisch über das Verarbeitungsclusterarray 212 verteilt werden.
  • Das Verarbeitungsclusterarray 212 kann bis zu „N“ Verarbeitungscluster (z.B. Cluster 214A, Cluster 214B bis Cluster 214N) aufweisen. Jeder Cluster 214A-214N des Verarbeitungsclusterarrays 212 kann eine große Anzahl von gleichzeitigen Threads ausführen. Der Scheduler 210 kann den Clustern 214A-214N des Verarbeitungsclusterarrays 212 Arbeit unter Verwendung verschiedener Planung- und/oder Arbeitsverteilungsalgorithmen zuordnen, die abhängig von der Arbeitslast variieren können, die für jede Art von Programm oder Berechnung auftritt. Die Planung kann von dem Scheduler 210 dynamisch erledigt werden oder kann teilweise von Kompiliererlogik während Kompilierens von Programmlogik unterstützt werden, die zur Ausführung durch das Verarbeitungsclusterarray 212 konfiguriert ist. Optional können verschiedene Cluster 214A-214N des Verarbeitungsclusterarrays 212 zur Verarbeitung verschiedener Arten von Programmen oder zur Durchführung verschiedener Arten von Berechnungen zugeordnet sein.
  • Das Verarbeitungsclusterarray 212 kann konfiguriert sein, verschiedene Arten von parallelen Verarbeitungsoperationen durchzuführen. Zum Beispiel ist das Verarbeitungsclusterarray 212 konfiguriert, parallele Allzweckrechenoperationen durchzuführen. Zum Beispiel kann das Verarbeitungsclusterarray 212 Logik zum Ausführen von Verarbeitungsaufgaben aufweisen, aufweisend Filtern von Video- und/oder Audiodaten, Durchführen von Modellierungsoperationen, aufweisend Physikoperationen, und Durchführen von Datentransformationen.
  • Das Verarbeitungsclusterarray 212 ist konfiguriert, parallele Grafikverarbeitungsoperationen durchzuführen. In solchen Ausführungsformen, in welchen der parallele Prozessor 200 konfiguriert ist, Grafikverarbeitungsoperationen durchzuführen, kann das Verarbeitungsclusterarray 212 zusätzliche Logik aufweisen, um die Ausführung solcher Grafikverarbeitungsoperationen zu unterstützen, aufweisend, aber nicht beschränkt auf, Texturabtastlogik, um Texturoperationen durchzuführen, wie auch Tessellationslogik und andere Vertexverarbeitungslogik. Zusätzlich kann das Verarbeitungsclusterarray 212 konfiguriert sein, auf Grafikverarbeitung bezogene Shader-Programme auszuführen, wie, ohne aber darauf beschränkt zu sein, Vertex-Shader, Tessellations-Shader, Geometrie-Shader und Pixel-Shader. Die Parallelverarbeitungseinheit 202 kann Daten vom Systemspeicher über die I/O Einheit 204 zur Verarbeitung überführen. Während der Verarbeitung können die überführten Daten beim On-Chip-Speicher (z.B. paralleler Prozessorspeicher 222) während der Verarbeitung gespeichert, dann wieder zurück in den Systemspeicher geschrieben werden.
  • In Ausführungsformen, in welchen die Parallelverarbeitungseinheit 202 verwendet wird, um Grafikverarbeitung durchzuführen, kann der Scheduler 210 konfiguriert sein, die Verarbeitungsarbeitslast in annähernd gleich große Aufgaben zu teilen, um eine Verteilung der Grafikverarbeitungsoperationen auf mehrere Cluster 214A-214N des Verarbeitungsclusterarrays 212 besser zu ermöglichen. In manchen dieser Ausführungsformen können Teile des Verarbeitungsclusterarrays 212 konfiguriert sein, verschiedene Arten von Verarbeitung durchzuführen. Zum Beispiel kann ein erster Teil konfiguriert sein, Vertex-Shading und Topologieerzeugung durchzuführen, ein zweiter Teil kann konfiguriert sein, Tessellations- und Geometrie-Shading durchzuführen, und ein dritter Teil kann konfiguriert sein, Pixel-Shading oder andere Bildschirmraumoperationen durchzuführen, um ein gerendertes Bild zur Anzeige zu erzeugen. Zwischendaten, die durch einen oder mehrere der Cluster 214A-214N erzeugt werden, können in Puffern gespeichert werden, um ein Übertragen der Zwischendaten zwischen Clustern 214A-214N zur Weiterverarbeitung zu ermöglichen.
  • Während des Betriebs kann das Verarbeitungsclusterarray 212 auszuführende Verarbeitungsaufgaben über den Scheduler 210 empfangen, der Steuerbefehle, die Verarbeitungsaufgaben definieren, vom Frontend 208 empfängt. Für Grafikverarbeitungsoperationen können Verarbeitungsaufgaben Indizes von Zu verarbeitenden Daten empfangen, z.B. Oberflächen- (Patch-) Daten, Primitive-Daten, Vertexdaten und/oder Pixeldaten, wie auch Zustandsparameter und Steuerbefehle, die definieren, wie die Daten zu verarbeiten sind (z.B. welches Programm auszuführen ist). Der Scheduler 210 kann konfiguriert sein, die den Aufgaben entsprechenden Indizes abzurufen oder kann die Indizes vom Frontend 208 empfangen. Das Frontend 208 kann konfiguriert sein sicherzustellen, dass das Verarbeitungsclusterarray 212 zu einem gültigen Zustand konfiguriert ist, bevor die Arbeitslast, die durch eingehende Steuerbefehlspuffer (z.B. Batch-Puffer, Schiebe-Puffer usw.) definiert ist, eingeleitet wird.
  • Jedes des einen oder der mehreren Exemplare der Parallelverarbeitungseinheit 202 kann mit parallelem Prozessorspeicher 222 gekoppelt sein. Der Zugriff auf den parallelen Prozessorspeicher 222 kann über die Speicher-Crossbar 216 erfolgen, die Speicheranfragen von dem Verarbeitungsclusterarray 212 wie auch der I/O Einheit 204 empfangen kann. Die Speicher-Crossbar 216 kann auf den parallelen Prozessorspeicher 222 über eine Speicherschnittstelle 218 zugreifen. Die Speicherschnittstelle 218 kann mehrere Trennungseinheiten (z.B. Trennungseinheit 220A, Trennungseinheit 220B bis Trennungseinheit 220N) aufweisen, die an einen Teil (z.B. Speichereinheit) von paralleler Prozessorspeicher 222 koppeln können. Die Anzahl von Trennungseinheiten 220A-220N kann konfiguriert sein, gleich der Anzahl von Speichereinheiten zu sein, sodass eine erste Trennungseinheit 220A eine entsprechende erste Speichereinheit 224A hat, eine zweite Trennungseinheit 220B eine entsprechende zweite Speichereinheit 224B hat und eine N-te Trennungseinheit 220N eine entsprechende N-te Speichereinheit 224N hat. In anderen Ausführungsformen kann die Anzahl von Trennungseinheiten 220A-220N nicht gleich der Anzahl von Speichervorrichtungen sein.
  • Die Speichereinheiten 224A-224N können verschiedene Arten von Speicher Vorrichtungen aufweisen, aufweisend dynamischen Direktzugriffsspeicher (DRAM, Dynamic Random Access Memory) oder Grafikdirektzugriffsspeicher, wie synchronen Grafikdirektzugriffsspeicher(SGRAM), aufweisend Grafikdoppeldatenraten- (GDDR) Speicher. Optional können die Speichereinheiten 224A-224N auch 3D-gestapelten Speicher aufweisen, aufweisend ohne aber darauf beschränkt zu sein, Speicher hoher Bandbreite (HBM, High Bandwidth Memory). Fachleute werden erkennen, dass die bestimmte Implementierung der Speichereinheiten 224A-224N variieren kann und aus einem von verschiedenen herkömmlichen Designs ausgewählt sein kann. Render-Ziele wie Frame-Puffer oder Texturkarten können über die Speichereinheiten 224A-224N gespeichert werden, was Trennungseinheiten 220A-220N erlaubt, Teile jedes Renderziels parallel zu speichern, um die verfügbare Bandbreite paralleler Prozessorspeicher 222 effizient zu nutzen. In manchen Ausführungsformen kann ein lokales Exemplar des parallelen Prozessorspeichers 222 zugunsten eines vereinheitlichten Speicherdesigns ausgeschlossen sein, das Systemspeicher in Verbindung mit lokalem Cache-Speicher benutzt.
  • Optional hat einer der Cluster 214A-214N des Verarbeitungsclusterarrays 212 die Fähigkeit, Daten zu verarbeiten, die in eine der Speichereinheiten 224A-224N im parallelen Prozessorspeicher 222 geschrieben werden. Die Speicher-Crossbar 216 kann konfiguriert sein, den Ausgang jedes Clusters 214A-214N zu jeder Trennungseinheit 220A-220N oder zu einem anderen Cluster 214A-214N zu überführen, der zusätzliche Verarbeitungsoperationen an dem Ausgang durchführen kann. Jeder Cluster 214A-214N kann mit der Speicherschnittstelle 218 durch die Speicher-Crossbar 216 kommunizieren, um aus verschiedenen externen Speichervorrichtungen zu lesen und in diese zu schreiben. In einer der Ausführungsformen mit der Speicher-Crossbar 216 hat die Speicher-Crossbar 216 eine Verbindung zu der Speicherschnittstelle 218, um mit der I/O-Einheit 204 zu kommunizieren, wie auch eine Verbindung zu einem lokalen Exemplar des parallelen Prozessorspeichers 222, die den Verarbeitungseinheiten innerhalb der verschiedenen Verarbeitungscluster 214A-214N ermöglicht, mit Systemspeicher oder anderen Speichern zu kommunizieren, die nicht lokal bei der Parallelverarbeitungseinheit 202 sind. Im Allgemeinen kann die Speicher-Crossbar 216 zum Beispiel imstande sein, virtuelle Kanäle zu verwenden, um Verkehrsströme zwischen den Clustern 214A-214N und den Trennungseinheiten 220A-220N zu trennen.
  • Während ein einziges Exemplar der Parallelverarbeitungseinheit 202 in dem parallelen Prozessor 200 veranschaulicht ist, kann eine beliebige Anzahl von Exemplaren der Parallelverarbeitungseinheit 202 enthalten sein. Zum Beispiel können mehrere Exemplare der Parallelverarbeitungseinheit 202 auf einer einzigen Zusatzkarte bereitgestellt sein oder mehrere Zusatzkarten können miteinander verbunden sein. Zum Beispiel kann der parallele Prozessor 200 eine Zusatzvorrichtung, wie Zusatzvorrichtung 120 von 1 sein, die eine Grafikkarte wie eine separate Grafikkarte, die eine oder mehrere GPUs aufweist, eine oder mehrere Speichervorrichtungen und Vorrichtung-zu-Vorrichtung- oder Netzwerk- oder Fabric-Schnittstellen sein kann. Die verschiedenen Exemplare der Parallelverarbeitungseinheit 202 können konfiguriert sein, miteinander zu arbeiten, selbst wenn die verschiedenen Exemplare verschiedene Anzahlen von Verarbeitungskernen, verschiedene Mengen von lokalen parallelen Prozessorspeichern und/oder andere Konfigurationsunterschiede aufweisen. Optional können manche Exemplare der Parallelverarbeitungseinheit 202 Gleitkommaeinheiten höherer Präzision relativ zu anderen Exemplaren haben. Systeme, die ein oder mehrere Exemplare der Parallelverarbeitungseinheit 202 oder des parallelen Prozessors 200 aufweisen, können in einer Vielzahl von Konfigurationen und Formfaktoren implementiert werden, aufweisend, ohne aber darauf beschränkt zu sein, Desktop, Laptop oder handgehaltene Personal Computer, Server, Workstations, Spielekonsolen und/oder eingebettete Systeme. Ein Orchestrator kann zusammengestellte Knoten für Arbeitslastleistung unter Verwendung eines oder mehrerer der Folgenden bilden: disaggregierte Prozessorressourcen, Cache-Ressourcen, Speicherressourcen, Datenspeicherressourcen und Vernetzungsressourcen.
  • 2B ist ein Blockdiagramm einer Trennungseinheit 220. Die Trennungseinheit 220 kann ein Exemplar einer der Trennungseinheiten 220A-220N von 2A sein. Wie veranschaulicht, weist die Trennungseinheit 220 einen L2 Cache 221, eine Frame-Pufferschnittstelle 225 und eine ROP 226 (Rasteroperationseinheit) auf. Der L2 Cache 221 ist ein Lese/Schreib-Cache, der konfiguriert ist, Lade- und Speicheroperationen durchzuführen, die von der Speicher-Crossbar 216 und ROP 226 empfangen werden. Lesefehlschläge und dringende Rückschreibanfragen werden vom L2 Cache 221 an Frame-Pufferschnittstelle 225 zur Verarbeitung ausgegeben. Aktualisierungen können auch an den Frame-Puffer über die Frame-Pufferschnittstelle 225 zur Verarbeitung gesendet werden. In einer Ausführungsform ist die Frame-Pufferschnittstelle 225 mit einer der Speichereinheiten im parallelen Prozessorspeicher verbunden, wie den Speichereinheiten 224A-224N von 2A (z.B. im parallelen Prozessorspeicher 222). Die Trennungseinheit 220 kann zusätzlich oder alternativ auch mit einer der Speichereinheiten im parallelen Prozessorspeicher über eine Speichersteuerung (nicht dargestellt) verbunden sein.
  • In Grafikanwendungen ist die ROP 226 eine Verarbeitungseinheit, die Rasteroperationen wie Stencil, z-Test, Überblenden und dergleichen, durchführt. Die ROP 226 gibt dann verarbeitete Grafikdaten aus, die im Grafikspeicher gespeichert sind. In manchen Ausführungsformen weist die ROP 226 einen CODEC 227 auf oder ist an diesen gekoppelt, der Kompressionslogik zum Komprimieren von Tiefen- oder Farbdaten, die in Speicher oder den L2 Cache 221 geschrieben sind, und zum Dekomprimieren von Tiefen- oder Farbdaten, die aus dem Speicher oder dem L2 Cache 221 gelesen werden, aufweist. Die Kompressionslogik kann verlustlose Kompressionslogik sein, die einen oder mehrere von mehreren Kompressionsalgorithmen nutzt. Die Art von Kompression, die durch den CODEC 227 durchgeführt wird, kann basierend auf den statistischen Eigenschaften der zu komprimierenden Daten variieren. Zum Beispiel wird in einer Ausführungsform Delta-Farbkompression an Tiefen- und Farbdaten auf einer Basis pro Kachel durchgeführt. In einer Ausführungsform weist der CODEC 227 Kompressions- und Dekompressionslogik auf, die Rechendaten komprimieren und dekomprimieren kann, die mit Maschinenlernoperationen verknüpft sind. Der CODEC 227 kann zum Beispiel Sparse-Matrixdaten für Sparse-Maschinenlernoperationen komprimieren. Der CODEC 227 kann auch Sparse-Matrixdaten komprimieren, die in einem Sparse-Matrixformat codiert sind (z.B. Koordinatenlistencodierung (COO, Coordinate List Encoding), komprimierte Sparse-Reihe (CSR, Compressed Sparse Row), komprimierte Sparse-Spalte (CSC, Compressed Sparse Column) usw.), um komprimierte und codierte Sparse-Matrixdaten zu generieren. Die komprimierten und codierten Sparse-Matrixdaten können dekomprimiert und/oder decodiert werden, bevor sie durch Verarbeitungselemente verarbeitet werden, oder die Verarbeitungselemente können konfiguriert sein, komprimierte, codierte oder komprimierte und codierte Daten zur Verarbeitung zu benutzen.
  • Die ROP 226 kann in jedem Verarbeitungscluster (z.B. Cluster 214A-214N von 2A) anstatt in der Trennungseinheit 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 angezeigt werden, wie einer der einen oder mehreren Anzeigevorrichtung(en) 110 von 1, die zur Weiterverarbeitung durch den (die) Prozessor(en) 102 geroutet werden oder zur Weiterverarbeitung durch eine der Verarbeitungseinheiten in dem parallelen Prozessor 200 von 2A geroutet werden.
  • 2C ist ein Blockdiagramm eines Verarbeitungsclusters 214 in einer Parallelverarbeitungseinheit. Zum Beispiel ist der Verarbeitungscluster ein Exemplar eines der Verarbeitungscluster 214A-214N von 2A. Der Verarbeitungscluster 214 kann konfiguriert sein, viele Threads parallel auszuführen, wo der Begriff „Thread“ sich auf ein Exemplar eines bestimmten Programms bezieht, das auf einem bestimmten Satz von Eingangsdaten ausgeführt wird. Optional können Einzelbefehl, Mehrfachdaten-(SIMD, Single-Instruction, Multiple-Data) Befehlsausgabetechniken verwendet werden, um parallele Ausführung einer großen Anzahl von Threads zu unterstützen, ohne mehrere unabhängige Befehlseinheiten bereitzustellen. Alternativ können Einzelbefehl, Mehrfach-Thread (SIMT, Single-Instruction, Multiple-Thread) Techniken verwendet werden, um parallele Ausführung einer großen Anzahl von im Allgemeinen synchronisierten Threads unter Verwendung einer gemeinsamen Befehlseinheit zu unterstützen, die konfiguriert ist, Befehle an einen Satz von Verarbeitungs-Engines innerhalb jedes der Verarbeitungscluster auszugeben. Anders als ein SIMD-Ausführungsschema, wo alle Verarbeitungs-Engines typischerweise identische Befehle ausführen, erlaubt SIMT-Ausführung verschiedenen Threads, leichter divergierenden Ausführungspfaden durch ein bestimmtes Thread-Programm zu folgen. Fachleute werden verstehen, dass ein SIMD-Verarbeitungsschema einen funktionellen Teilsatz eines SIMT-Verarbeitungsschemas darstellt.
  • Betrieb des Verarbeitungsclusters 214 kann über einen Pipeline-Verwalter 232 gesteuert werden, der Verarbeitungsaufgaben zu SIMT-parallelen Prozessoren verteilt. Der Pipeline-Verwalter 232 empfängt Befehle vom Scheduler 210 von 2A und verwaltet Ausführung dieser Befehle über einen Grafikmultiprozessor 234 und/oder eine Textureinheit 236. Der veranschaulichte Grafikmultiprozessor 234 ist ein beispielhaftes Exemplar eines SIMT-parallelen Prozessors. Es können jedoch verschiedene Arten von SIMT-parallelen Prozessoren unterschiedlicher Architekturen in dem Verarbeitungscluster 214 enthalten sein. Eines oder mehrere Exemplare des Grafikmultiprozessors 234 können in einem Verarbeitungscluster 214 enthalten sein. Der Grafikmultiprozessor 234 kann Daten verarbeiten und eine Daten-Crossbar 240 kann zum Verteilen der verarbeiteten Daten an einen von mehreren möglichen Zielorte verwendet werden, die andere Shader-Einheiten aufweisen. Der Pipeline-Verwalter 232 kann die Verteilung verarbeiteter Daten durch Spezifizieren von Zielorten für verarbeitete Daten erleichtern, die über die Daten-Crossbar 240 verteilt werden sollen.
  • Jeder Grafikmultiprozessor 234 in dem Verarbeitungscluster 214 kann einen identischen Satz von funktioneller Ausführungslogik (z.B. Arithmetiklogikeinheiten, Lade-Speicher- Einheiten usw.) aufweisen. Die funktionelle Ausführungslogik kann in der Art einer Pipeline konfiguriert sein, in der neue Befehle ausgegeben werden können, bevor vorherige Befehle abgeschlossen sind. Die funktionelle Ausführungslogik unterstützt eine Reihe von Operationen, die Ganzzahl- und Gleitkommaarithmetik, Vergleichsoperationen, Boolesche Operationen, Bit-Verschiebung und Berechnung verschiedener algebraischer Funktionen aufweisen. Dieselbe Funktionseinheit-Hardware könnte benutzt werden, um verschiedene Operationen durchzuführen, und es kann jede beliebige Kombination von Funktionseinheiten vorhanden sein.
  • Die Befehle, die an den Verarbeitungscluster 214 übertragen werden, stellen einen Thread dar. Ein Satz von Threads, der über den Satz von Parallelverarbeitungs-Engines ausgeführt wird, ist eine Thread-Gruppe. Eine Thread-Gruppe führt dasselbe Programm an verschiedenen Eingangsdaten aus. Jeder Thread in einer Thread-Gruppe kann einer anderen Verarbeitungs-Engine in einem Grafikmultiprozessor 234 zugewiesen sein. Eine Thread-Gruppe kann weniger Threads als die Anzahl von Verarbeitungs-Engines in dem Grafikmultiprozessor 234 aufweisen. Wenn eine Thread-Gruppe weniger Threads als die Anzahl von Verarbeitungs-Engines aufweist, können eine oder mehrere der Verarbeitungs-Engines während Zyklen leerlaufen, in welchen diese Thread-Gruppe verarbeitet wird. Eine Thread-Gruppe kann auch mehr Threads als die Anzahl von Verarbeitungs-Engines in dem Grafikmultiprozessor 234 aufweisen. Wenn die Thread-Gruppe mehr Threads als die Anzahl von Verarbeitungs-Engines in dem Grafikmultiprozessor 234 aufweist, kann 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 Cache-Speicher aufweisen, um Lade- und Speicheroperationen durchzuführen. Optional kann der Grafikmultiprozessor 234 auf einen internen Cache verzichten und einen Cache-Speicher (z.B. Ebene 1 (L1) Cache 248) in dem Verarbeitungscluster 214 verwenden. Jeder Grafikmultiprozessor 234 hat auch Zugriff auf Ebene 2 (L2) Caches in den Trennungseinheiten (z.B. Trennungseinheiten 220A-220N von 2A), die sich alle Verarbeitungscluster 214 teilen, und kann zum Überführen von Daten zwischen Threads verwendet werden. Der Grafikmultiprozessor 234 kann auch auf globalen Off-Chip-Speicher zugreifen, der einen oder mehrere von lokalem parallelen Prozessorspeicher und/oder Systemspeicher aufweisen kann. Jeder Speicher extern der Parallelverarbeitungseinheit 202 kann als globaler Speicher verwendet werden. Ausführungsformen, in welchen der Verarbeitungscluster 214 mehrere Exemplare des Grafikmultiprozessors 234 aufweist, können gemeinsame Befehle und Daten teilen, die in dem L1 Cache 248 gespeichert sein können.
  • Jeder Verarbeitungscluster 214 kann eine MMU 245 (Speicherverwaltungseinheit, Memory Management Unit) aufweisen, die konfiguriert ist, virtuelle Adressen in physische Adressen abzubilden. In anderen Ausführungsformen können sich ein oder mehrere Exemplare der MMU 245 in der Speicherschnittstelle 218 von 2A befinden. Die MMU 245 weist einen Satz von Seitentabelleneinträgen (PTEs, Page Table Entries), die zum Abbilden einer virtuellen Adresse auf eine physische Adresse einer Kachel verwendet werden, und optional einen Cache-Zeilenindex auf. Die MMU 245 kann Adressenübersetzungspuffer (TLB, Translation Lookaside Buffer) oder Caches aufweisen, die sich in dem Grafikmultiprozessor 234 oder dem L1 Cache oder Verarbeitungscluster 214 befinden können. Die physische Adresse wird verarbeitet, um Oberflächendatenzugriffslokalität zu verteilen, um effiziente Anfrageverschachtelung unter Trennungseinheiten zu erlauben. Der Cache-Zeilenindex kann zum Bestimmen verwendet werden, ob eine Anfrage für eine Cache-Zeile ein Treffer oder ein Fehlschlag ist.
  • In Grafik- und Rechenanwendungen kann ein Verarbeitungscluster 214 so konfiguriert sein, dass jeder Grafikmultiprozessor 234 an eine Textureinheit 236 zum Durchführen von Texturabbildungsoperationen gekoppelt ist, z.B. Bestimmen von Texturabtastpositionen, Lesen von Texturdaten und Filtern der Texturdaten. Texturdaten werden aus einem internen Textur L1 Cache (nicht dargestellt) oder in manchen Ausführungsformen aus dem L1 Cache im Grafikmultiprozessor 234 gelesen und aus einem L2 Cache, lokalen parallelen Prozessorspeicher oder Systemspeicher nach Bedarf abgerufen. Jeder Grafikmultiprozessor 234 gibt verarbeitete Aufgaben an die Daten-Crossbar 240 aus, um die verarbeitete Aufgabe einem anderen Verarbeitungscluster 214 zur Weiterverarbeitung bereitzustellen oder die verarbeitete Aufgabe in einem L2 Cache, lokalen parallelen Prozessorspeicher oder Systemspeicher über die Speicher-Crossbar 216 zu speichern. Eine preROP 242 (Prä-Rasteroperationseinheit) ist konfiguriert, Daten vom Grafikmultiprozessor 234 zu empfangen, Daten zu ROP-Einheiten zu lenken, die mit Trennungseinheiten wie hier beschrieben (z.B. Trennungseinheiten 220A-220N von 2A) liegen können. Die preROP 242 Einheit kann Optimierungen für Farbüberblendung durchführen, Pixelfarbdaten organisieren und Adressenübersetzungen durchführen.
  • Es ist klar, dass die hier beschriebene Kernarchitektur veranschaulichend ist und dass Variationen und Modifizierungen möglich sind. Es kann eine beliebige Anzahl von Verarbeitungseinheiten, z.B. Grafikmultiprozessor 234, Textureinheiten 236, preROPs 242 usw., in einem Verarbeitungscluster 214 enthalten sein. Ferner, während nur ein Verarbeitungscluster 214 dargestellt ist, kann eine Parallelverarbeitungseinheit wie hier beschrieben eine beliebige Anzahl von Exemplaren der Verarbeitungscluster 214 aufweisen. Optional kann jeder Verarbeitungscluster 214 konfiguriert sein, unter Verwendung separater und einzelner Verarbeitungseinheiten, L1 Caches, L2 Caches usw. unabhängig von anderen Verarbeitungsclustern 214 zu arbeiten.
  • 2D zeigt ein Beispiel des Grafikmultiprozessors 234, in dem der Grafikmultiprozessor 234 mit dem Pipeline-Verwalter 232 des Verarbeitungsclusters 214 gekoppelt ist. Der Grafikmultiprozessor 234 hat eine Ausführungs-Pipeline, die einen Befehls-Cache 252, eine Befehlseinheit 254, eine Adressabbildungseinheit 256, eine Registerdatei 258, einen oder mehrere Allzweckgrafikverarbeitungseinheits- (GPGPU) Kerne 262 und eine oder mehrere Lade/Speichereinheiten 266 aufweist, ohne aber darauf beschränkt zu sein. Die GPGPU-Kerne 262 und Lade/Speichereinheiten 266 sind mit Cache-Speicher 272 und geteiltem Speicher 270 über ein Speicher- und Cache-Interconnect 268 gekoppelt. Der Grafikmultiprozessor 234 kann zusätzlich Tensor- und/oder Strahlverfolgungskerne 263 aufweisen, die Hardwarelogik aufweisen, um Matrix- und/oder Strahlverfolgungsoperationen zu beschleunigen.
  • Der Befehls-Cache 252 kann einen Strom von auszuführenden Befehlen vom Pipeline-Verwalter 232 empfangen. Die Befehle sind im Befehls-Cache 252 zwischengespeichert und werden zur Ausführung durch die Befehlseinheit 254 weitergeleitet. Die Befehlseinheit 254 kann Befehle als Thread-Gruppen (z.B. Warps) weiterleiten, wobei jeder Thread der Thread-Gruppe einer anderen Ausführungseinheit im GPGPU-Kern 262 zugewiesen ist. Ein Befehl kann auf einen lokalen, geteilten oder globalen Adressenraum durch Spezifizieren einer Adresse in einem vereinheitlichten Adressenraum zugreifen. Die Adressenabbildungseinheit 256 kann zum Übersetzen von Adressen in dem vereinheitlichten Adressenraum in eine einzelne Speicheradresse verwendet werden, auf die die Lade/Speichereinheiten 266 zugreifen können.
  • Die Registerdatei 258 stellt einen Satz von Registern für die Funktionseinheiten des Grafikmultiprozessors 234 bereit. Die Registerdatei 258 stellt vorübergehenden Datenspeicher für Operanden bereit, die mit den Datenpfaden der Funktionseinheiten (z.B. GPGPU-Kerne 262, Lade/Speichereinheiten 266) des Grafikmultiprozessors 234 verbunden sind. Die Registerdatei 258 kann zwischen jeder der Funktionseinheiten verbunden sein, sodass jeder Funktionseinheit ein dedizierter Teil der Registerdatei 258 zugeordnet ist. Zum Beispiel kann die Registerdatei 258 zwischen den verschiedenen Warps aufgeteilt sein, die von dem Grafikmultiprozessor 234 ausgeführt werden.
  • Die GPGPU-Kerne 262 können jeweils Gleitkommaeinheiten (FPUs, Floating Point Units) und/oder Ganzzahl-Arithmetiklogikeinheiten (ALUs, Arithmetic Logic Units) aufweisen, die verwendet werden, um Befehle des Grafikmultiprozessors 234 auszuführen. In manchen Implementierungen können die GPGPU-Kerne 262 Hardwarelogik aufweisen, die sich sonst in den Tensor- und/oder Strahlverfolgungskernen 263 befinden kann. Die GPGPU-Kerne 262 können in Architektur ähnlich sein oder können sich in Architektur unterscheiden. Zum Beispiel und in einer Ausführungsform weist ein erster Teil der GPGPU-Kerne 262 eine FPU einfacher Präzision und eine Ganzzahl-ALU auf, während ein zweiter Teil der GPGPU-Kerne eine FPU doppelter Präzision aufweist. Optional können die FPUs den IEEE 754-2008 Standard für Gleitkommaarithmetik implementieren oder Gleitkommaarithmetik variabler Präzision ermöglichen. Der Grafikmultiprozessor 234 kann zusätzlich eine oder mehrere Festfunktions- oder Spezialfunktionseinheiten aufweisen, um bestimmte Funktionen wie Kopierrechteck- Pixelüberblendungsoperationen durchzuführen. Einer oder mehrere der GPGPU-Kerne können auch Fest- oder Spezialfunktionslogik aufweisen.
  • Die GPGPU-Kerne 262 können SIMD-Logik aufweisen, die zum Durchführen eines einzelnen Befehls an mehreren Sätzen von Daten imstande ist. Optional können GPGPU-Kerne 262 physisch SIMD4, SIMD8 und SIMD16 Befehle ausführen und logisch SIMD1, SIMD2 und SIMD32 Befehle ausführen. Die SIMD-Befehle für die GPGPU-Kerne können zur Kompilierungszeit von einem Shader-Kompilierer erzeugt oder automatisch erzeugt werden, wenn Programme ausgeführt werden, die für Einzelprogramm-Mehrfachdaten- (SPMD, Single Program Multiple Data) oder SIMT-Architekturen geschrieben sind. Mehrere Threads eines Programms, das für das SIMT-Ausführungsmodell konfiguriert ist, können über einen einzelnen SIMD-Befehl ausgeführt werden. Zum Beispiel und in einer Ausführungsform können acht SIMT-Threads, die dieselben oder ähnliche Operationen durchführen, parallel über einen 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 geteilten Speicher 270 verbindet. Zum Beispiel ist das Speicher- und Cache-Interconnect 268 ein Crossbar-Interconnect, das der Lade/Speichereinheit 266 erlaubt, Lade- und Speicheroperationen zwischen dem geteilten Speicher 270 und der Registerdatei 258 zu implementieren. Die Registerdatei 258 kann bei derselben Frequenz wie die GPGPU-Kerne 262 arbeiten, wodurch Datentransfer zwischen den GPGPU-Kernen 262 und der Registerdatei 258 bei sehr geringer Latenz ist. Der geteilte Speicher 270 kann verwendet werden, um Kommunikation zwischen Threads zu ermöglichen, die auf den Funktionseinheiten in dem Grafikmultiprozessor 234 laufen. Der Cache-Speicher 272 kann als ein Datencache verwendet werden, um zum Beispiel Texturdaten zwischenzuspeichern, die zwischen den Funktionseinheiten und der Textureinheit 236 kommuniziert werden. Der geteilte Speicher 270 kann auch als ein programmverwalteter Cache verwendet werden. Der geteilte Speicher 270 und der Cache-Speicher 272 können mit der Daten-Crossbar 240 gekoppelt sein, um Kommunikation mit anderen Komponenten des Verarbeitungsclusters zu ermöglichen. Threads, die auf den GPGPU-Kernen 262 laufen, können programmatisch Daten in dem geteilten Speicher zusätzlich zu den automatisch zwischengespeicherten Daten speichern, die in dem Cache-Speicher 272 gespeichert sind.
  • 3A-3C veranschaulichen zusätzlicher Grafikmultiprozessoren gemäß Ausführungsformen. 3A-3B veranschaulichen Grafikmultiprozessoren 325, 350, die mit dem Grafikmultiprozessor 234 von 2C in Zusammenhang stehen und anstatt einem von diesen verwendet werden können. Daher offenbart die Offenbarung beliebiger Merkmale in Kombination mit dem Grafikmultiprozessor 234 hierin auch eine entsprechende Kombination mit dem (den) Grafikmultiprozessor(en) 325, 350, ist aber nicht darauf beschränkt. 3C veranschaulicht eine Grafikverarbeitungseinheit (GPU) 380, die dedizierte Sätze von Grafikverarbeitungsressourcen aufweist, die in Mehrfachkerngruppen 365A-365N angeordnet sind, die den Grafikmultiprozessoren 325, 350 entsprechen. Die veranschaulichten Grafikmultiprozessoren 325, 350 und die Mehrfachkerngruppen 365A-365N können Streaming-Multiprozessoren (SM) sein, die zur Ausführung einer großen Anzahl von Ausführung Threads imstande sind.
  • Der Grafikmultiprozessor 325 von 3A weist mehrere zusätzliche Exemplare von Ausführungsressourceneinheiten relativ zu dem Grafikmultiprozessor 234 von 2D auf. Zum Beispiel kann der Grafikmultiprozessor 325 mehrere Exemplare der Befehlseinheit 332A-332B, Registerdatei 334A-334B und Textureinheit(en) 344A-344B aufweisen. Der Grafikmultiprozessor 325 weist auch mehrere Sätze von Grafik- oder Rechenausführungseinheiten (z.B. GPGPU-Kern 336A-336B, Tensor Kern 337A-337B, Strahlverfolgungskern 338A-338B) und mehrere Sätze von Lade/Speichereinheiten 340A-340B auf. Die Ausführungsressourceneinheiten haben einen gemeinsamen Befehls-Cache 330, Textur und/oder Daten-Cache-Speicher 342 und geteilten Speicher 346.
  • Die verschiedenen Komponenten können über ein Interconnect-Fabric 327 kommunizieren. Das Interconnect-Fabric 327 kann eine oder mehrere Crossbar-Schalter aufweisen, um Kommunikation zwischen den verschiedenen Komponenten des Grafikmultiprozessors 325 zu ermöglichen. Das Interconnect-Fabric 327 kann eine separate Hochgeschwindigkeitsnetzwerk-Fabric-Schicht sein, auf der jede Komponente des Grafikmultiprozessors 325 gestapelt ist. Die Komponenten des Grafikmultiprozessors 325 kommunizieren mit fernen Komponenten über das Interconnect-Fabric 327. Zum Beispiel können die Kerne 336A-336B, 337A-337B und 338A-338B jeweils mit geteiltem Speicher 346 über das Interconnect-Fabric 327 kommunizieren. Das Interconnect-Fabric 327 kann Kommunikation in dem Grafikmultiprozessor 325 schlichten, um eine faire Bandbreitenzuordnung zwischen Komponenten sicherzustellen.
  • Der Grafikmultiprozessor 350 von 3B weist mehrere Sätze von Ausführungsressourcen 356A-356D auf, wo jeder Satz von Ausführungsressourcen mehrere Befehlseinheiten, Registerdateien, GPGPU-Kerne und Ladespeichereinheiten aufweist, wie in 2D und 3A veranschaulicht. Die Ausführungsressourcen 356A-356D können gemeinsam mit Textureinheit(en) 360A-360D für Texturoperationen arbeiten, während sie sich einen Befehls-Cache 354 und geteilten Speicher 353 teilen. Zum Beispiel können sich die Ausführungsressourcen 356A-356D einen Befehls-Cache 354 und geteilten Speicher 353, wie auch mehrere Exemplare eines Textur- und/oder Daten-Cache-Speichers 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 beschriebene Architektur beschreibend ist und nicht für den Umfang der vorliegenden Ausführungsformen einschränkend ist. Somit können die hier beschriebenen Techniken auf einer richtig konfigurierten Verarbeitungseinheit implementiert werden, aufweisend, ohne Einschränkung, einen oder mehrere mobile Anwendungsprozessoren, eine oder mehrere zentrale Desktop- oder Server-Verarbeitungseinheiten (CPUs), aufweisend mehr Mehrfachkern-CPUs, einen oder mehrere Parallelverarbeitungseinheiten, wie die Parallelverarbeitungseinheit 202 von 2A, wie auch einen oder mehrere Grafikprozessoren oder Spezialzweckverarbeitungseinheiten, ohne vom Umfang der hier beschriebenen Ausführungsformen abzuweichen.
  • Der parallele Prozessor oder die GPGPU, wie hier beschrieben, kann kommunikativ an Host/Prozessorkerne gekoppelt sein, um Grafikoperationen, Maschinenlemoperationen, Strukturanalyseoperationen und verschiedene Allzweck-GPU- (GPGPU) Funktionen zu beschleunigen. Die GPU kann kommunikativ an die Host-Prozessor/Kerne über einen Bus oder ein anderes Interconnect (z.B. ein Hochgeschwindigkeit-Interconnect wie PCIe, NVLink oder andere bekannte Protokolle, standardisierte Protokolle oder firmeneigene Protokolle) gekoppelt sein. In anderen Ausführungsformen kann die GPU auf demselben Package oder Chip wie die Kerne integriert sein und über einen internen Prozessorbus/Interconnect (d.h. intern zu dem Package oder Chip) kommunikativ an die Kerne gekoppelt sein. Unabhängig von der Art, in der die GPU verbunden ist, können die Prozessorkerne der GPU Arbeit in der Form von Abfolgen von Steuerbefehlen/Befehlen zuordnen, die in einer Arbeitsbeschreibung enthalten sind. Die GPU verwendet dann dedizierte Schaltkreis/Logik für effiziente Verarbeitung dieser Steuerbefehle/Befehle.
  • 3C veranschaulicht eine Grafikverarbeitungseinheit (GPU) 380, die dedizierte Sätze von Grafikverarbeitungsressourcen aufweist, die in Mehrfachkerngruppen 365A-365N angeordnet sind. Während die Einzelheiten einer einzigen Mehrfachkerngruppe 365A bereitgestellt sind, ist klar, dass die anderen Mehrfachkerngruppen 365B-365N mit denselben oder ähnlichen Sätzen von Grafikverarbeitungsressourcen ausgestattet sein können. Einzelheiten, die in Bezug auf die Mehrfachkerngruppen 365A-365N beschrieben sind, können auch für jeden hier beschriebenen Grafikmultiprozessor 234, 325, 350 gelten.
  • Wie veranschaulicht, kann eine Mehrfachkerngruppe 365A einen Satz von Grafikkernen 370, einen Satz von Tensor-Kernen 371 und einen Satz von Strahlverfolgungskerne 372 aufweisen. Ein Scheduler/Dispatcher 368 plant die Grafik-Threads und leitete sie zur Ausführung auf den verschiedenen Kernen 370, 371, 372 weiter. Ein Satz von Registerdateien 369 speichert Operandenwerte, die von den Kernen 370, 371, 372 beim Ausführen der Grafik-Threads verwendet werden. Diese können zum Beispiel Ganzzahlregister zum Speichern von Ganzzahlwerten, Gleitkommaregister zum Speichern von Gleitkommawerten, Vektorregister zum Speichern gepackter Datenelemente (Ganzzahl- und/oder Gleitkommadatenelemente) und Kachelregister zum Speichern von Tensor/Matrixwerten aufweisen. Die Kachelregister können als kombinierte Sätze von Vektorregistern implementiert sein.
  • Ein oder mehrere kombinierte Ebene 1 (L1) Caches und geteilte Speichereinheiten 373 speichern Grafikdaten wie Texturdaten, Vertexdaten, Pixeldaten, Strahlendaten, Begrenzungsvolumendaten usw. lokal in jeder Mehrfachkerngruppe 365A. Eine oder mehrere Textureinheiten 374 können auch zum Durchführen von Texturierungsoperationen, wie Texturabbildung und -abtastung, verwendet werden. Ein Ebene 2 (L2) Cache 375, den sich alle oder ein Teilsatz der Mehrfachkerngruppen 365A-365N teilen, speichert Grafikdaten und/oder Befehle für mehrere gleichzeitige Grafik-Threads. Wie veranschaulicht, kann der L2 Cache 375 über mehrere Mehrfachkerngruppen 365A-365N geteilt werden. Eine oder mehrere Speichersteuerungen 367 koppeln die GPU 380 an einen Speicher 366, der ein Systemspeicher (z.B. DRAM) und/oder ein dedizierter Grafikspeicher (z.B. GDDR6-Speicher) sein kann.
  • Eingangs-/Ausgangs- (I/O) Schaltkreis 363 koppelt die GPU 380 an eine oder mehrere I/O-Vorrichtungen 362 wie Digitalsignalprozessoren (DSPs), Netzwerksteuerungen oder Anwendereingabevorrichtungen. Ein On-Chip-Interconnect kann verwendet werden, um die I/O-Vorrichtungen 362 an die GPU 380 und den Speicher 366 zu koppeln. Eine oder mehrere I/O Speicherverwaltungseinheiten (IOMMUs) 364 des I/O-Schaltkreises 363 koppeln die I/O-Vorrichtungen 362 direkt an den Systemspeicher 366. Optional verwaltet die IOMMU 364 mehrere Sätze von Seitentabellen, um virtuelle Adressen auf physische Adressen im Systemspeicher 366 abzubilden. Die I/O-Vorrichtungen 362, CPU(s) 361 und GPU(s) 380 können sich dann denselben virtuellen Adressenraum teilen.
  • In einer Implementierung der IOMMU 364 unterstützt die IOMMU 364 Virtualisierung. In diesem Fall kann sie einen ersten Satz von Seitentabellen verwalten, um virtuelle Gast/Grafikadressen auf physische Gast/Grafikadressen abzubilden, und einen zweiten Satz von Seitentabellen, um die physischen Gast/Grafikadressen auf physische System/Hostadressen abzubilden (z.B. im Systemspeicher 366). Die Basisadressen jedes der ersten und zweiten Sätze von Seitentabellen können in Steuerregistern gespeichert und auf einen Kontextschalter ausgelagert werden (z.B. so dass der neue Kontext mit Zugriff auf den relevanten Satz von Seitentabellen bereitgestellt ist). Obwohl in 3C nicht veranschaulicht, kann jeder der Kerne 370, 371, 372 und/oder jede der Mehrfachkerngruppen 365A-365N Übersetzungspuffer (TLBs) aufweisen, um virtuelle Gast- zu physischen Gastübersetzungen, physische Gastzu physischen Host-Übersetzungen und virtuelle Gast- zu physischen Host-Übersetzungen zwischenzuspeichern.
  • Die CPUs 361, GPUs 380 und I/O-Vorrichtungen 362 können auf einem einzigen Halbleiter-Chip und/oder Chip-Package integriert sein. Der veranschaulichte Speicher 366 kann auf demselben Chip integriert sein oder kann an die Speichersteuerungen 367 über eine Off-Chip-Schnittstelle gekoppelt sein. In einer Implementierung weist der Speicher 366 GDDR6-Speicher auf der sich denselben virtuellen Adressenraum mit anderen Speichern auf physischer Systemebene teilt, obwohl die hier beschriebenen, darunterliegenden Prinzipien nicht auf diese bestimmte Implementierung begrenzt sind.
  • Die Tensor-Kerne 371 können eine mehrere von Ausführungseinheiten aufweisen, die speziell gestaltet sind, Matrixoperationen durchzuführen, die die grundlegende Rechenoperation sind, die zum Durchführen von tiefen Lemoperationen verwendet werden. Zum Beispiel können simultane Matrixmultiplikationsoperationen für neurales Netzwerktraining und Schlussfolgerung verwendet werden. Die Tensor-Kerne 371 können Matrixverarbeitung unter Verwendung einer Reihen von Operandenpräzisionen durchführen, aufweisend Gleitkomma einfacher Präzision (z.B. 32 Bits), Gleitkomma halber Präzision (z.B. 16 Bits), Ganzzahlwörter (16 Bits), Bytes (8 Bits) und Halb-Bytes (4 Bits). Zum Beispiel extrahiert eine neurale Netzwerkimplementierung Merkmale jeder gerenderten Szene, wobei möglicherweise Details aus mehreren Frames kombiniert werden, um ein fertiges Hochqualitätsbild zu erstellen.
  • In tiefen Lernimplementierungen kann parallele Matrixmultiplikationsarbeit zur Ausführung auf den Tensor-Kernen 371 geplant werden. Das Training neuraler Netzwerke erfordert insbesondere eine signifikante Anzahl von Matrixskalarproduktoperationen. Zur Verarbeitung einer Innenproduktformulierung einer N × N × N Matrixmultiplikation können die Tensor-Kerne 371 mindestens N Skalarproduktverarbeitungselemente aufweisen. Bevor die Matrixmultiplikation beginnt, wird eine gesamte Matrix in Kachelregister geladen und mindestens eine Spalte einer zweiten Matrix wird jeden Zyklus für N Zyklen geladen. In jedem Zyklus sind N Skalarprodukte, die verarbeitet werden.
  • Matrixelemente können bei verschiedenen Präzisionen verarbeitet werden, abhängig von der bestimmten Implementierung, aufweisend 16-Bit Wörter, 8-Bit Bytes (z.B. INT8) und 4-Bit Halb-Bytes (z.B. INT4). Es können verschiedene Präzisionsmodi für die Tensor-Kerne 371 spezifiziert werden um sicherzustellen, dass die effizienteste Präzision für verschiedene Arbeitslasten verwendet wird (z.B. wie Schlussfolgerungsarbeitslasten, die Quantisierung in Bytes und Halb-Bytes tolerieren können). Unterstützte Formate weisen zusätzlich 64-Bit Gleitkomma- (FP64) und Nicht-IEEE Gleitkommaformate wie das bfloat16 Format (z.B. Brain-Gleitkomma), ein 16-Bit Gleitkommaformat mit einem Zeichen-Bit, acht Exponenten-Bits und acht Mantissen-Bits auf, von welchen sieben explizit gespeichert sind. Eine Ausführungsform weist Unterstützung für Tensor-Gleitformat reduzierter Präzision (TF32) auf, das den Bereich von FP32 (8-Bit) mit der Präzision von FP16 (10-Bit) hat. TF32 Operationen reduzierter Präzision können an FP32-Eingängen durchgeführt werden und erzeugen FP32-Ausgänge bei höherer Arbeitsleistung relativ zu FP32 und erhöhter Präzision relativ zu FP16.
  • In einer Ausführungsform unterstützen die Tensor-Kerne 371 einen Sparse-Betriebsmodus für Matrizen, in welchen der Großteil von Werten null ist. Die Tensor-Kerne 371 weisen Unterstützung für Sparse-Eingangsmatrizen auf, die in einer Sparse-Matrix-Darstellung codiert sind (z.B. Koordinatenlistencodierung (COO), komprimierte Sparse-Reihe (CSR), komprimierte Sparse-Spalte (CSC) usw.). Die Tensor-Kerne 371 weisen auch Unterstützung für komprimierte Sparse-Matrixdarstellungen auf, falls diese Sparse-Matrixdarstellung weiter komprimiert werden kann. Komprimierte, codierte und/oder komprimierte und codierte Matrixdaten, gemeinsam mit zugehörigen Kompressions- und/oder Codierungsmetadaten, können durch die Tensor-Kerne 371 bereit sein und die Nicht-Null-Werte können extrahiert werden. Zum Beispiel kann für eine bestimmte Eingangsmatrix A ein Nicht-Null-Wert aus der komprimierten und/oder codierten Darstellung mindestens eines Teils von Matrix A geladen werden. Basierend auf der Stelle in Matrix A für den Nicht-Null-Wert, die aus Index- oder Koordinatenmetadaten bestimmt werden kann, die mit dem Nicht-Null-Wert verknüpft sind, kann ein entsprechender Wert in Eingangsmatrix B geladen werden. Abhängig von der durchzuführenden Operation (z.B. Multiplikation) kann das Laden des Werts aus Eingangsmatrix B umgangen werden, wenn der entsprechende Wert ein Nullwert ist. In einer Ausführungsform können die Paarungen von Werten für gewisse Operationen, wie Multiplikationsoperationen durch Scheduler-Logik, vorabgetastet werden und nur Operationen zwischen Nicht-Null-Eingängen geplant werden. Abhängig von den Dimensionen von Matrix A und Matrix B und der durchzuführenden Operation, kann Ausgangsmatrix C dicht oder dünnbesetzt sein. Wo Ausgangsmatrix C dünnbesetzt ist und abhängig von der Konfiguration der Tensor-Kerne 371, kann Ausgangsmatrix C in einem komprimierten Format, einer Sparse-Codierung oder einer komprimierten Sparse-Codierung ausgegeben werden.
  • Die Strahlverfolgungskerne 372 können Strahlverfolgungsoperationen für sowohl Echtzeit-Strahlverfolgungs- als auch Nicht-Echtzeit Strahlverfolgungsimplementierungen beschleunigen. Insbesondere können die Strahlverfolgungskerne 372 Strahldurchquerungs-/Schnittpunktschaltkreis zum Durchführen von Strahldurchquerung unter Verwendung von Begrenzungsvolumenhierarchien (BVHs, Bounding Volume Hierarchies) durchführen und Schnittpunkte zwischen Strahlen und Primitiven definieren, die in den BVH-Volumina eingeschlossen sind. Die Strahlverfolgungskerne 372 können auch Schaltkreis zum Durchführen von Tiefentestung und Culling aufweisen (z.B. unter Verwendung eines Z-Puffers oder einer ähnlichen Anordnung). In einer Implementierung führen die Strahlverfolgungskerne 372 Querungs- und Schnittpunktoperationen in Übereinstimmung mit den hier beschriebenen Bildrauschunterdrückungstechniken durch, von welchen mindestens ein Teil an den Tensor-Kernen 371 ausgeführt werden kann. Zum Beispiel können die Tensor-Kerne 371 ein neurales, tiefes Lernnetzwerk implementieren, um Rauschunterdrückung von Frames durchzuführen, die durch die Strahlverfolgungskerne 372 erzeugt werden. Die CPU(s) 361, Grafikkerne 370 und/oder Strahlverfolgungskerne 372 können jedoch auch die gesamte oder einen Teil der Rauschunterdrückungs- und/oder tiefen Lernalgorithmen implementieren.
  • Zusätzlich, wie oben beschrieben, kann ein verteilter Ansatz zur Rauschunterdrückung benutzt werden, in dem die GPU 380 in einer Rechenvorrichtung ist, die an andere Rechenvorrichtungen über ein Netzwerk oder Hochgeschwindigkeit-Interconnect gekoppelt ist. In diesem verteilten Ansatz können sich die miteinander verbundenen Rechenvorrichtungen neurale Netzwerk-Lern-/Trainingsdaten teilen, um die Geschwindigkeit zu verbessern, mit der das gesamte System lernt, Rauschunterdrückung für verschiedene Arten von Bildframes und/oder verschiedene Grafikanwendungen durchzuführen.
  • Die Strahlverfolgungskerne 372 können alle BVH Querungen und/oder Strahl-Primitive-Schnittpunkte verarbeiten, wobei die Grafikkerne 370 vor einer Überladung mit tausenden Befehlen pro Strahl verschont bleiben. Zum Beispiel weist jeder Strahlverfolgungskern 372 einen ersten Satz von spezialisierten Schaltkreisen zum Durchführen von Begrenzungskastentests (z.B. für querende Operationen) und/oder einen zweiten Satz von spezialisierten Schaltkreisen zum Durchführen der Strahl-Dreieck-Schnittpunkttests auf (z.B. schneidende Strahlen, die gequert wurden). So kann zum Beispiel die Mehrfachkerngruppe 365A einfach eine Strahlsonde starten und die Strahlverfolgungskerne 372 führen unabhängig Strahlquerung und Schnittpunkt durch und geben Trefferdaten (z.B. ein Treffer, kein Treffer, mehrere Treffer usw.) an den Thread-Kontext zurück. Die anderen Kerne 370, 371 sind frei, andere Grafik- oder Rechenarbeit durchzuführen, während die Strahlverfolgungskerne 372 die Querungs- und Schnittpunktoperationen durchführen.
  • Optional kann jeder Strahlverfolgungskern 372 eine Querungseinheit, um BVH-Testoperationen durchzuführen, und/oder eine Schnittpunkteinheit, die Strahl-Primitive-Schnittpunkttests durchführt, aufweisen. Die Schnittpunkteinheit erzeugt eine „Treffer“, „keine Treffer“ oder „mehrere Treffer“ Antwort, die sie dem richtigen Thread bereitstellt. Während der Querung- und Schnittpunktoperationen sind die Ausführungsressourcen der anderen Kerne (z.B. Grafikkerne 370 und Tensor-Kerne 371) frei, andere Formen von Grafikarbeit durchzuführen.
  • In einer optionalen, unten beschriebenen Ausführungsform wird ein hybrider Rasterungs-/Strahlverfolgungsansatz verwendet, in dem Arbeit zwischen den Grafikkernen 370 und Strahlverfolgungskernen 372 verteilt ist.
  • Die Strahlverfolgungskerne 372 (und/oder anderen Kerne 370, 371) können Hardwareunterstützung für einen Strahlverfolgungsbefehlssatz wie Microsofts DirectX Ray Tracing (DXR) aufweisen, der einen DispatchRays-Steuerbefehl, wie auch Strahlerzeugung, ähnlichster Treffer, irgendeinen Treffer und Verfehlungs-Shader aufweist, die die Zuweisung einzigartiger Sätze von Shadern und Texturen für jedes Objekt ermöglichen. Eine andere Strahlverfolgungsplattform, die von den Strahlverfolgungskernen 372, Grafikkernen 370 und Tensor-Kernen 371 unterstützt werden kann, ist Vulkan 1.1.85. Es ist jedoch zu beachten, dass die hier beschriebenen darunterliegenden Prinzipien nicht auf eine bestimmte Strahlverfolgungs-ISA begrenzt sind.
  • Im Allgemeinen können die verschiedenen Kerne 372, 371, 370 einen Strahlverfolgungsbefehlssatz unterstützen, der Befehle/Funktionen für eines oder mehrere von Strahlerzeugung, ähnlichster Treffer, beliebiger Treffer, Strahl-Primitive-Schnittpunkt, Pro-Primitive und hierarchische Begrenzungskastenkonstruktion, Verfehlung, Aufsuchen und Ausnahmen aufweist. Insbesondere weist eine bevorzugte Ausführungsform Strahlverfolgungsbefehle zum Durchführen einer oder mehrerer der folgenden Funktionen auf:
  • Strahlerzeugung - Strahlerzeugungsbefehle können für jedes Pixel, jede Abtastung oder andere vom Anwender definierte Arbeitszuweisung ausgeführt werden.
  • Ähnlichster Treffer - Ein ähnlichster Treffer-Befehl kann ausgeführt werden, um den ähnlichsten Schnittpunkt eines Strahls mit Primitiven in einer Szene zu lokalisieren.
  • Beliebiger Hit - Ein beliebiger Treffer-Befehl identifiziert mehrere Schnittpunkte zwischen einem Strahl und Primitiven in einer Szene, möglicherweise um einen neuen ähnlichsten Schnittpunkt zu identifizieren.
  • Schnittpunkt - Ein Schnittpunktbefehl führt einen Strahl-Primitive-Schnittpunkttest durch und gibt ein Ergebnis aus.
  • Pro-Primitive-Begrenzungskastenerstellung - Dieser Befehl erstellt einen Begrenzungskasten um eine bestimmte Primitive oder Gruppe von Primitiven (z.B., wenn eine neue BVH oder andere Beschleunigungsdatenstruktur errichtet wird).
  • Verfehlung - Gibt an, dass ein Strahl die gesamte Geometrie in einer Szene oder einem spezifizierten Gebiet einer Szene verfehlt.
  • Aufsuchen - Gibt die Kindervolumina an, die ein Strahl queren wird.
  • Ausnahmen - Enthält verschiedene Arten von Ausnahme-Handlern (z.B. aufgerufen für verschiedene Fehlerbedingungen).
  • In einer Ausführungsform können die Strahlverfolgungskerne 372 ausgebildet sein, Allzweckrechenoperationen zu beschleunigen, die unter Verwendung von Berechnungstechniken beschleunigt werden können, die zu Strahlschnittpunkttests analog sind. Ein Rechen-Framework kann bereitgestellt sein, das ermöglicht, Shader-Programme in Befehle tieferer Ebene und/oder Primitive zu kompilieren, die Allzweckrechenoperationen über die Strahlverfolgungskerne durchführen. Beispielhafte Berechnungsprobleme, die von Rechenoperationen profitieren können, die an den Strahlverfolgungskernen 372 durchgeführt werden, enthalten Berechnungen, die Strahlbündel-, Wellen- oder Partikelausbreitung in einem Koordinatenraum involvieren. Interaktionen, die mit dieser Ausbreitung verknüpft sind, können relativ zu einer Geometrie oder einem Netz in dem Koordinatenraum berechnet werden. Zum Beispiel können Berechnungen, die mit elektromagnetischer Signalausbreitung durch eine Umgebung verknüpft sind, durch Verwendung von Befehlen oder Primitiven beschleunigt werden, die über die Strahlverfolgungskerne ausgeführt werden. Beugung und Reflexion der Signale durch Objekte in der Umgebung können als direkte Strahlverfolgungsanalogien berechnet werden.
  • Strahlverfolgungskerne 372 können auch verwendet werden, um Berechnungen durchzuführen, die nicht direkt analog zu Strahlverfolgung sind. Zum Beispiel können Netzprojektions-, Netzverfeinerungs- und Volumenabtastberechnungen unter Verwendung der Strahlverfolgungskerne 372 beschleunigt werden. Generische Koordinatenraumberechnungen, wie Berechnungen des nächsten Nachbarn, können ebenso durchgeführt werden. Zum Beispiel kann der Satz von Punkten nahe einem bestimmten Punkt durch Definieren eines Begrenzungskastens in dem Koordinatenraum um den Punkt entdeckt werden. BVH und Strahlsondenlogik innerhalb der Strahlverfolgungskerne 372 können dann verwendet werden, um den Satz von Punktschnittpunkten innerhalb des Begrenzungskastens zu bestimmen. Die Schnittpunkte stellen den Ursprungspunkt und die nächsten Nachbarn zu diesem Ursprungspunkt dar. Berechnungen, die unter Verwendung der Strahlverfolgungskerne 372 durchgeführt werden, können parallel mit Berechnungen durchgeführt werden, die an den Grafikkernen 372 und Tensor-Kernen 371 durchgeführt werden. Ein Shader-Kompilierer kann konfiguriert sein, einen Rechen-Shader oder ein anderes Allzweckgrafikverarbeitungsprogramm in Primitive tieferer Ebene zu kompilieren, die über die Grafikkerne 370, Tensor-Kerne 371 und Strahlverfolgungskerne 372 parallelisiert werden können.
  • Techniken für Zwischenverbindungen von GPU und Host-Prozessor
  • 4A veranschaulicht eine beispielhafte Architektur, in der mehrere GPUs 410-413, wie z.B. die parallelen Prozessoren 200, dargestellt in 2A, kommunikativ an mehrere Mehrfachkernprozessoren 405-406 über Hochgeschwindigkeitslinks 440A-440D (z.B. Busse, Punkt-zu-Punkt-Zwischenverbindungen usw.) gekoppelt sind. Die Hochgeschwindigkeitslinks 440A-440D können einen Kommunikationsdurchsatz von 4GB/s, 30GB/s, 80GB/s oder höher unterstützen, abhängig von der Implementierung. Verschiedene Interconnect-Protokolle können verwendet werden, aufweisend, aber nicht beschränkt auf, PCIe 4.0 oder 5.0 und NVLink 2.0. Die hier beschriebenen zugrundeliegenden Prinzipien sind jedoch nicht auf ein bestimmtes Kommunikationsprotokoll oder einen bestimmten Durchsatz begrenzt.
  • Zwei oder mehr der GPUs 410-413 können über Hochgeschwindigkeitslinks 442A-442B verbunden sein, die unter Verwendung derselben oder verschiedenen Protokolle/Links implementiert sein können, wie jenen, die für Hochgeschwindigkeitslinks 440A-440D verwendet werden. Ebenso können zwei oder mehr der Mehrfachkernprozessoren 405-406 über Hochgeschwindigkeitslink 443 verbunden sein, die symmetrische Multi-Prozessor- (SMP) Busse sein können, die bei 20GB/s, 30GB/s, 120GB/s oder niedrigeren oder höheren Geschwindigkeiten arbeiten können. Alternativ kann die gesamte Kommunikation zwischen den verschiedenen Systemkomponenten, die in 4A dargestellt sind, unter Verwendung derselben Protokolle/Links (z.B. über ein gemeinsames Zwischenverbindungs-Fabric) bewerkstelligt werden. Wie erwähnt, sind jedoch die hier beschriebenen zugrundeliegenden Prinzipien nicht auf eine bestimmte Art von Interconnect-Technologie begrenzt.
  • Jeder Mehrfachkem Prozessor 405-406 kann kommunikativ an einen Prozessorspeicher 401-402 über Speicher-Interconnects 430A-430B gekoppelt sein und jede GPU 410-413 ist kommunikativ an GPU-Speicher 420-423 über GPU-Speicher-Interconnects 450A-450D gekoppelt. Die Speicher-Interconnects 430A-430B und 450A-450D können dieselben oder verschiedene Speicherzugriffstechnologien verwenden. Als Beispiel und nicht zur Einschränkung können die Prozessorspeicher 401-402 und GPU-Speicher 420-423 flüchtige Speicher wie dynamische Direktzugriffsspeicher (DRAMs) (aufweisend gestapelte DRAMs), Grafik DDR SDRAM (GDDR) (z.B. GDDR5, GDDR6) oder Speicher hoher Bandbreite (HBM) sein und/oder können nicht flüchtige Speicher wie 3D XPoint/Optane oder Nano-Ram sein. Zum Beispiel kann ein Teil der Speicher flüchtiger Speicher sein und ein anderer Teil kann nicht flüchtiger Speicher sein (z.B. unter Verwendung einer Zwei-Ebenen Speicher- (2LM) Hierarchie). Ein Speicherteilsystem, wie hier beschrieben, kann mit einer Anzahl von Speichertechnologien kompatibel sein, wie Doppeldatenratenversionen, die von JEDEC (Joint Electronic Device Engineering Council) veröffentlicht werden.
  • Wie unten beschrieben, obwohl die verschiedenen Prozessoren 405-406 und GPUs 410-413 physisch an einen bestimmten Speicher 401-402, 420-423 gekoppelt sein können, kann eine vereinheitlichte Speicherarchitektur implementiert werden, in welcher derselbe virtuelle Systemadressenraum (auch als der „effektive Adressenraum“ bezeichnet) unter all den verschiedenen physischen Speichern verteilt ist. Zum Beispiel können Prozessorspeicher 401-402 jeweils 64GB des Systemspeicheradressenraums aufweisen und GPU-Speicher 420-423 können jeweils 32GB des Systemspeicheradressenraums aufweisen (was zu insgesamt 256GB adressierbarem Speicher in diesem Beispiel führt).
  • 4B veranschaulicht zusätzliche optionale Einzelheiten für eine Zwischenverbindung zwischen einem Mehrfachkernprozessor 407 und einem Grafikbeschleunigungsmodul 446. Das Grafikbeschleunigungsmodul 446 kann einen oder mehrere GPU-Chips aufweisen, die auf einer Leitungskarte integriert sind, die über den Hochgeschwindigkeitslink 440 an den Prozessor 407 gekoppelt ist. Alternativ kann das Grafikbeschleunigungsmodul 446 auf demselben Package oder Chip wie der Prozessor 407 integriert sein.
  • Der veranschaulichte Prozessor 407 weist mehrere Kerne 460A-460D auf, jeder mit einem Übersetzungspuffer 461A-461D und einem oder mehreren Caches 462A-462D. Die Kerne können verschiedene andere Komponenten zur Ausführung von Befehlen und Verarbeitung von Daten aufweisen, die nicht veranschaulicht sind, um ein Verschleiern der zugrundeliegenden Prinzipien der hier beschriebenen Komponenten (z.B. Befehlsabrufeinheiten, Verzweigungsvorhersageeinheiten, Decodierer, Ausführungseinheiten, Neuordnungspuffer usw.) zu vermeiden. Die Caches 462A-462D können Ebene 1 (L1) und Ebene 2 (L2) Caches aufweisen. Zusätzlich können einer oder mehrere geteilte Caches 456 in der Zwischenspeicherungshierarchie enthalten und von Sätzen der Kerne 460A-460D gemeinsam benutzt werden. Zum Beispiel weist eine Ausführungsform des Prozessors 407 24 Kerne, jeder mit seinem eigenen L1 Cache, zwölf geteilte L2 Caches und zwölf geteilte L3 Caches auf. In dieser Ausführungsform ist einer der L2 und L3 Caches durch zwei benachbarte Kerne geteilt. Der Prozessor 407 und das Grafikbeschleunigerintegrationsmodul 446 sind mit Systemspeicher 441 verbunden, der Prozessorspeicher 401-402 aufweisen kann.
  • Kohärenz wird für Daten und Befehle, die in den verschiedenen Caches 462A-462D, 456 und Systemspeichern 441 gespeichert sind, über Inter-Kernkommunikation über einen Kohärenzbus 464 aufrechterhalten. Zum Beispiel können mit jedem Cache Zwischenspeicherungskohärenzlogik/Schaltkreise verknüpft sein, um mit diesem über den Kohärenzbus 464 in Antwort auf erfasste Lese- oder Schreibvorgänge zu bestimmten Cache-Zeilen zu kommunizieren. In einer Implementierung ist ein Cache-Snooping-Protokoll über den Kohärenzbus 464 implementiert, um Cache-Zugriffe zu entdecken. Cache-Snooping/Kohärenztechniken sind einem Fachmann allgemein bekannt und werden hier nicht ausführlich beschrieben, um Verschleierung der hier beschriebenen zugrundeliegenden Prinzipien zu vermeiden.
  • Eine Proxy-Schaltung 425 kann bereitgestellt sein, die das Grafikbeschleunigungsmodul 446 kommunikativ an den Kohärenzbus 464 koppelt, wodurch dem Grafikbeschleunigungsmodul 446 ermöglicht wird, an dem Zwischenspeicherungskohärenzprotokoll als ein Peer der Kerne teilzuhaben. Insbesondere stellt eine Schnittstelle 435 Konnektivität zu der Proxy-Schaltung 425 über Hochgeschwindigkeitslink 440 (z.B. einen PCIe Bus, NVLink usw.) bereit und eine Schnittstelle 437 verbindet das Grafikbeschleunigungsmodul 446 mit dem Hochgeschwindigkeitslink 440.
  • In einer Implementierung stellt eine Beschleunigerintegrationsschaltung 436 Cache-Verwaltungs-, Speicherzugriffs-, Kontextverwaltungs- und Unterbrechungsverwaltungsdienste seitens mehrerer Grafikverarbeitungs-Engines 431, 432, N des Grafikbeschleunigungsmoduls 446 bereit. Die Grafikverarbeitungs-Engines 431, 432, N können jeweils eine separate Grafikverarbeitungseinheit (GPU) aufweisen. Alternativ können die Grafikverarbeitungs-Engines 431, 432, N verschiedene Arten von Grafikverarbeitungs-Engines in einer GPU aufweisen, wie Grafikausführungseinheiten, Medien Verarbeitungs-Engines (z.B. Videocodierer/-decodierer), Sampler und Blit-Engines. Mit anderen Worten, das Grafikbeschleunigungsmodul kann 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) 439 zum Durchführen verschiedener Speicherverwaltungsfunktionen wie virtuelle-zu-physische Speicherübersetzungen (auch als effektive-zu-reale-Speicherübersetzungen bezeichnet) und Speicherzugriffsprotokolle zum Zugreifen auf Systemspeicher 441 aufweisen. Die MMU 439 kann auch einen Übersetzungspuffer (TLB) (nicht dargestellt) zum Zwischenspeichern der virtuellen/effektiven zu physischen/realen Adressenübersetzungen aufweisen. In einer Implementierung speichert ein Cache 438 Steuerbefehle und Daten für effizienten Zugriff durch die Grafikverarbeitungs-Engines 431, 432, N. Die Daten, die in Cache 438 und Grafikspeicher 433-434, M gespeichert sind, können mit den Kern-Caches 462A-462D, 456 und Systemspeicher 441 kohärent gehalten werden. Wie erwähnt kann dies über Proxy-Schaltung 425 bewerkstelligt werden, die an Zwischenspeicherungskohärenzmechanismus seitens Cache 438 und Speicher 433-434, M teilnimmt (z.B. Aktualisierungen an den Cache 438 sendet, die sich auf Modifizierungen/Zugriffe von Cache-Zeilen auf Prozessor-Caches 462A-462D, 456 beziehen, und Aktualisierungen von dem Cache 438 empfängt).
  • Ein Satz von Registern 445 speichert Kontextdaten für Threads, die von Grafikverarbeitungs-Engines 431-432, N ausgeführt werden, und eine Kontextverwaltungsschaltung 448 verwaltet die Thread-Kontexte. Zum Beispiel kann die Kontextverwaltungsschaltung 448 Speicher- und Wiederherstellungsoperationen durchführen, um Kontexte der verschiedenen Threads während Kontextwechseln zu speichern und wiederherzustellen (z.B., wenn ein erster Thread gespeichert und ein zweiter Thread wiederhergestellt wird, sodass der zweite Thread von einer Grafikverarbeitungs-Engine ausgeführt werden kann). Zum Beispiel kann die Kontextverwaltungsschaltung 448 auf einem Kontextschalter aktuelle Registerwerte in einem angegebenen Gebiet im Speicher speichern (z.B. identifiziert durch einen Kontextzeiger). Sie kann dann die Registerwerte wiederherstellen, wenn sie zu dem Kontext zurückkehrt. Eine Verwaltungsschaltung 447 kann zum Beispiel Unterbrechungen empfangen und verarbeiten, die von Systemvorrichtungen empfangen werden.
  • In einer Implementierung werden virtuelle/effektive Adressen von einer Grafikverarbeitungs-Engine 431 in reale/physische Adressen im Systemspeicher 441 durch die MMU 439 ü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 zwischen mehreren Anwendungen geteilt sein. Optional ist eine virtualisierte Grafikausführungsumgebung bereitgestellt, in der die Ressourcen der Grafikverarbeitungs-Engines 431-432, N mit mehreren Anwendungen, virtuellen Maschinen (VMs) oder Containern geteilt sind. Die Ressourcen können in „Slices“ geteilt werden, die verschiedenen VMs und/oder Anwendungen basierend auf den Verarbeitungsanforderungen und Prioritäten zugeordnet werden, die mit den VMs und/oder Anwendungen verknüpft sind. VMs und Container können hier austauschbar verwendet werden.
  • Eine virtuelle Maschine (VM) kann Software sein, die ein Betriebssystem und eine oder mehrere Anwendungen betreibt. Eine VM kann durch Spezifikation, Konfigurationsdateien, virtuelle Plattendatei, Einstellungsdatei eines nicht flüchtigen Direktzugriffsspeichers (NVRAM) und die Protokolldatei definiert sein und wird von den physischen Ressourcen einer Host-Rechenplattform unterstützt. Eine VM kann ein Betriebssystem (OS) oder Anwendungsumgebung aufweisen, die auf Software installiert ist, die dedizierte Hardware nachahmt. Der Endanwender hat dieselbe Erfahrung auf einer virtuellen Maschine die er auf dedizierter Hardware hätte. Spezialisiertes Software, als Hypervisor bezeichnet, emuliert die CPU des PC-Clients oder Servers, Speicher, Festplatte, das Netzwerk und andere Hardwareressourcen vollständig, wodurch es virtuellen Maschinen möglich wird, die Ressourcen gemeinsam zu benutzen. Der Hypervisor kann mehrere virtuelle Hardwareplattformen emulieren, die voneinander isoliert sind, was virtuellen Maschinen erlaubt, Linux®, Windows® Server, VMware ESXi und andere Betriebssysteme auf demselben darunterliegenden Host laufen zu lassen.
  • Ein Container kann ein Software-Package von Anwendungen, Konfigurationen und Abhängigkeiten sein, sodass die Anwendungen zuverlässig auf einer Rechenumgebung zu einer anderen laufen. Container können sich ein Betriebssystem teilen, das auf der Serverplattform isoliert ist, und als isolierte Prozesse laufen. Ein Container kann ein Software-Package sein, dass alles enthält, was die Software zum Laufen benötigt, wie System-Tools, Bibliotheken und Einstellungen. Container sind nicht wie herkömmliche Softwareprogramme installiert, was ihnen ermöglicht, von der anderen Software und dem Betriebssystem selbst isoliert zu sein. Die isolierte Eigenschaft von Containern bietet mehrere Vorteile. Erstens läuft die Software in einem Container in verschiedenen Umgebungen gleich. Zum Beispiel kann ein Container, der PHP und MySQL aufweist, sowohl auf einem Linux® Computer als auch einer Windows® Maschine identisch laufen. Zweitens stellen Container zusätzliche Sicherheit bereit, da die Software das Host-Betriebssystem nicht beeinflusst. Während eine installierte Anwendung Systemeinstellungen verändern und Ressourcen modifizieren kann, wie die Windows Registrierungsdatenbank, kann ein Container nur Einstellungen innerhalb des Containers modifizieren.
  • Somit dient die Beschleunigerintegrationsschaltung 436 als eine Brücke zu dem System für das Grafikbeschleunigungsmodul 446 und stellt Adressenübersetzungs- und Systemspeicherzwischenspeicherdienste bereit. In einer Ausführungsform kann, zur Erleichterung der Überbrückungsfunktionalität, die Beschleunigerintegrationsschaltung 436 auch geteilten I/O 497 (z.B. PCIe, USB oder andere) und Hardware aufweisen, um Systemsteuerung von Spannung, Taktung, Arbeitsleistung, Thermiken und Sicherheit zu ermöglichen. Der geteilte I/O 497 kann separate physische Verbindungen nutzen oder kann den Hochgeschwindigkeitslink 440 durchqueren. Zusätzlich kann die Beschleunigerintegrationsschaltung 436 Virtualisierungsanlagen für den Host-Prozessor bereitstellen, um Virtualisierung der Grafikverarbeitungs-Engines, Unterbrechungen und Speicherverwaltung zu verwalten.
  • Da Hardwareressourcen der Grafikverarbeitungs-Engines 431-432, N explizit auf den realen Adressenraum abgebildet werden, den der Host-Prozessor 407 sieht, kann jeder Host-Prozessor diese Ressourcen direkt unter Verwendung eines effektiven Adressenwerts 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 an jede der Grafikverarbeitungs-Engines 431-432, N gekoppelt sein. Die Grafikspeicher 433-434, M speichern Befehle und Daten, die von jeder der Grafikverarbeitungs-Engines 431-432, N verarbeitet werden. Die Grafikspeicher 433-434, M können flüchtige Speicher sein wie DRAMs (aufweisend gestapelte DRAMs), GDDR Speicher (z.B. GDDR5, GDDR6) oder HBM und/oder können nicht flüchtige Speicher wie 3D XPoint/Optane, Samsung Z-NAND oder Nano-Ram sein.
  • Zur Verringerung des Datenverkehrs über den Hochgeschwindigkeitslink 440 können Biasing-Techniken verwendet werden um sicherzustellen, dass die im Grafikspeicher 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 (zumindest nicht häufig) verwendet werden. Ebenso 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 dem Systemspeicher 441 zu halten.
  • Daher ist eine Variante, dargestellt in 4C, der Beschleunigerintegrationsschaltung 436 in den Prozessor 407 integriert. Die Grafikverarbeitungs-Engines 431-432, N kommunizieren direkt über den Hochgeschwindigkeitslink 440 zu der Beschleunigerintegrationsschaltung 436 über Schnittstelle 437 und Schnittstelle 435 (die wiederum jede Form von Bus- oder Schnittstellenprotokoll verwenden können). Die Beschleunigerintegrationsschaltung 436 kann dieselben Operationen wie jene durchführen, die in Bezug auf 4B beschrieben sind, aber möglicherweise bei einem höheren Durchsatz angesichts ihrer unmittelbaren Nähe zu dem Kohärenzbus 464 und den Caches 462A-462D, 456.
  • Die hier beschriebenen Ausführungsformen können verschiedene Programmierungsmodelle unterstützen, aufweisend eine Dedizierter-Prozess-Programmierungsmodell (keine Grafikbeschleunigungsmodulvirtualisierung) und geteilte Programmierungsmodelle (mit Virtualisierung). Das letztgenannte kann Programmierungsmodelle aufweisen, die durch die Beschleunigerintegrationsschaltung 436 gesteuert werden, und Programmierungsmodelle, die durch das Grafikbeschleunigungsmodul 446 gesteuert werden.
  • In den Ausführungsformen des Dedizierter-Prozess-Modells können Grafikverarbeitungs-Engines 431, 432, ... N für eine einzelne Anwendung oder einen einzigen Prozess unter einem einzelnen Betriebssystem dediziert sein. Die einzelne Anwendung kann andere Anwendungsanfragen an die Grafik-Engines 431, 432, ... N trichtern, die Virtualisierung innerhalb einer VM/Abtrennung bereitstellen.
  • In den Dedizierter-Prozess-Programmierungsmodellen können die Grafikverarbeitungs-Engines 431,432, N von mehreren VM/Anwendungsabtrennungen gemeinsam benutzt werden. Die geteilten Modelle erfordern einen System-Hypervisor, um die Grafikverarbeitungs-Engines 431-432, N zu virtualisieren, um Zugriff durch jedes Betriebssystem zu erlauben. Für Einzeltrennungssysteme ohne einen Hypervisor sind die Grafikverarbeitungs-Engines 431-432, N in Besitz des Betriebssystem. In beiden Fällen kann das Betriebssystem die Grafikverarbeitungs-Engines 431-432, N virtualisieren, um Zugriff für jeden Prozess oder jede Anwendung bereitzustellen.
  • Für das geteilte Programmierungsmodell wählt das Grafikbeschleunigungsmodul 446 oder eine individuelle Grafikverarbeitungs-Engine 431-432, N ein Prozesselement unter Verwendung eines Prozesshandlers. Die Prozesselemente können im Systemspeicher 441 gespeichert sein und unter Verwendung der hier beschriebenen Übersetzungstechniken von effektiver Adresse zu realer Adresse adressierbar sein. Der Prozesshandler kann ein implementierungsspezifischer Wert sein, der dem Host-Prozess bereitgestellt wird, wenn er seinen Kontext bei der Grafikverarbeitungs-Engine 431-432, N registriert (das heißt, Systemsoftware anruft, um das Prozesselement zu der Liste angebundener Prozesselemente hinzuzufügen). Die niedrigeren 16-Bit des Prozesshandlers können von dem Prozesselement in der Liste angebundener Prozesselemente versetzt sein.
  • 4D veranschaulicht ein beispielhaftes Beschleunigerintegrations-Slice 490. Wie hier verwendet, weist ein „Slice“ einen spezifizierten Teil der Verarbeitungsressourcen der Beschleunigerintegrationsschaltung 436 auf. Anwendungseffektiver Adressenraum 482 im Systemspeicher 441 speichert Prozesselemente 483. Die Prozesselemente 483 können in Antwort 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. Eine Arbeitsbeschreibung (WD) 484, die in dem Prozesselement 483 enthalten ist, kann ein einzelner Job sein, der von einer Anwendung angefragt wird, oder kann einen Zeiger zu einer Warteschlange von Jobs enthalten. Im letztgenannten Fall ist die WD 484 ein Zeiger zu der Jobanfrage im Adressenraum 482 der Anwendung.
  • Das Grafikbeschleunigungsmodul 446 und/oder die einzelnen Grafikverarbeitungs-Engines 431-432, N können von allen oder einem Teilsatz der Prozesse in dem System gemeinsam benutzt werden. Zum Beispiel können die hier beschriebenen Technologien eine Infrastruktur zum Einrichten des Prozesszustands und Senden einer WD 484 an ein Grafikbeschleunigungsmodul 446 aufweisen, um einen Job in einer virtualisierten Umgebung zu starten.
  • In einer Implementierung ist das Dedizierter-Prozess-Programmierungsmodell implementierungsspezifisch. In diesem Modell besitzt ein einziger Prozess das Grafikbeschleunigungsmodul 446 oder eine einzelne Grafikverarbeitungs-Engine 431. Da das Grafikbeschleunigungsmodul 446 von einem einzigen Prozess besessen wird, initialisiert der Hypervisor die Beschleunigerintegrationsschaltung 436 für die besitzende Abtrennung und das Betriebssystem initialisiert die Beschleunigerintegrationsschaltung 436 für den besitzenden Prozess zu dem Zeitpunkt, zu dem das Grafikbeschleunigungsmodul 446 zugewiesen wird.
  • In Betrieb ruft eine WD-Abrufungseinheit 491 in der Beschleunigerintegrations-Slice 490 die nächste WD 484 ab, die eine Angabe der Arbeit aufweist, die von einer der Grafikverarbeitungs-Engines des Grafikbeschleunigungsmoduls 446 zu erledigen ist. Daten aus der WD 484 können in Registern 445 gespeichert und von der MMU 439, Unterbrechungsverwaltungsschaltung 447 und/oder Kontextverwaltungsschaltung 448, wie veranschaulicht, verwendet werden. Zum Beispiel kann die MMU 439 Segment/Seitendurchlaufschaltkreis zum Zugreifen auf Segment/Seitentabellen 486 im virtuellen OS-Adressenraum 485 aufweisen. Die Unterbrechungsverwaltungsschaltung 447 kann Unterbrechungsereignisse 492 verarbeiten, die von dem Grafikbeschleunigungsmodul 446 empfangen werden. Wenn Grafikoperationen durchgeführt werden, wird eine effektive Adresse 493, die von einer Grafikverarbeitungs-Engine 431-432, N erzeugt wird, zu einer realen Adresse durch die MMU 439 erzeugt.
  • Derselbe Satz von Registern 445 kann für jede Grafikverarbeitungs-Engine 431-432, N und/oder jedes Grafikbeschleunigungsmoduls 446 dupliziert werden und kann durch den Hypervisor oder das Betriebssystem initialisiert werden. Jedes dieser duplizierten Register kann in einem Beschleunigerintegrations-Slice 490 enthalten sein. In einer Ausführungsform kann jede Grafikverarbeitungs-Engine 431-432, N dem Hypervisor 496 als eine einzelne Grafikprozessorvorrichtung präsentiert werden. QoS-Einstellungen können für Clients einer bestimmten Grafikverarbeitungs-Engine 431-432, N konfiguriert sein und Datenisolation zwischen den Clients jeder Engine kann möglich sein. Beispielhafte Register, die durch den Hypervisor initialisiert werden, sind in Tabelle 1 dargestellt. Tabelle 1 - Hypervisor-initialisierte Register
    1 Slice-Steuerregister
    2 Gebietszeiger für geplante reale Adressen- (RA) Prozesse
    3 Autoritätsmaskenübersteuerungsregister
    4 Unterbrechungsvektortabelleneintragsverschiebung
    5 Unterbrechungsvektortabelleneintragsgrenze
    6 Zustandsregister
    7 Logische Trennungs-ID
    8 Hypervisorbeschleunigerbenutzungsaufzeichnungszeiger für reale Adressen (RA)
    9 Datenspeicherbeschreibungregister
  • Beispielhafte Register, die durch das Betriebssystem initialisiert werden können, sind in Tabelle 2 dargestellt. Tabelle 2 - Betriebssystem-initialisierte Register
    1 Prozess- und Thread-Identifizierung
    2 Kontextspeicher-/-wiederherstellungszeiger für effektive Adressen- (EA)
    3 Beschleunigerbenutzungsaufzeichnungszeiger für virtuelle Adressen- (VA)
    4 Datenspeichersegmenttabellenzeiger für virtuelle Adressen- (VA)
    5 Autoritätsmaske
    6 Arbeitsbeschreiber
  • Jede WD 484 kann für ein bestimmtes Grafikbeschleunigungsmodul 446 und/oder eine Grafikverarbeitungs-Engine 431-432, N spezifisch sein. Sie enthält alle Informationen, die eine Grafikverarbeitungs-Engine 431-432, N benötigt, um ihre Arbeit zu erledigen, oder kann ein Zeiger zu einer Speicherstelle sein, wo die Anwendung eine Steuerbefehlswarteschlange von zu erledigender Arbeit eingerichtet hat.
  • 4E veranschaulicht zusätzliche optionale Einzelheiten eines geteilten Modells. Es weist einen realen Hypervisoradressenraum 498 auf, in dem eine Prozesselementliste 499 gespeichert ist. Der reale Hypervisoradressenraum 498 ist über einen Hypervisor 496 zugänglich, der die Grafikbeschleunigungsmodul-Engines für das Betriebssystem 495 visualisiert.
  • Die geteilten Programmierungsmodelle erlauben, dass alle oder ein Teilsatz von Prozessen von allen oder einem Teilsatz von Abtrennungen in dem System ein Grafikbeschleunigungsmodul 446 verwenden. Es gibt zwei Programmierungsmodelle, wo das Grafikbeschleunigungsmodul 446 durch mehrere Prozesse und Abtrennungen geteilt ist: zeitlich geteilte und grafikgelenkte geteilte.
  • In diesem Modell besitzt der Systemhypervisor 496 das Grafikbeschleunigungsmodul 446 und macht seine Funktion allen Betriebssystemen 495 verfügbar. Damit ein Grafikbeschleunigungsmodul 446 Virtualisierung durch den Systemhypervisor 496 unterstützt, kann das Grafikbeschleunigungsmodul 446 die folgenden Anforderungen einhalten: 1) Eine Jobanfrage einer Anwendung muss autonom sein (das heißt, der Zustand muss nicht zwischen Jobs aufrechterhalten werden) oder das Grafikbeschleunigungsmodul 446 muss einen Kontextspeicher- und -wiederherstellungsmechanismus bereitstellen. 2) Eine Jobanfrage einer Anwendung wird garantiert von dem Grafikbeschleunigungsmodul 446 in einer bestimmten Zeitdauer fertiggestellt, aufweisend Übersetzungsfehler, oder das Grafikbeschleunigungsmodul 446 stellt die Fähigkeit bereit, die Verarbeitung des Jobs vorwegzunehmen. 3) Das Grafikbeschleunigungsmodul 446 muss Fairness zwischen Prozessen garantieren, wenn es in dem gelenkten geteilten Programmierungsmodell arbeitet.
  • Für das geteilte Modell kann notwendig sein, dass die Anwendung 480 einen Systemanruf für ein Betriebssystem 495 mit einer Art von Grafikbeschleunigungsmodul 446, einer Arbeitsbeschreibung (WD), einem Autoritätsmaskenregister- (AMR) Wert und einem Kontextspeicher-/-wiederherstellungsgebietzeiger (CSRP, Context Save Recovery Area Pointer) vornimmt. Die Art von Grafikbeschleunigungsmodul 446 beschreibt die angezielte Beschleunigungsfunktion für den Systemanruf. Die Art von Grafikbeschleunigungsmodul 446 kann ein systemspezifischer Wert sein. Die WD ist spezielle für das Grafikbeschleunigungsmodul 446 formatiert und kann in der Form eines Grafikbeschleunigungsmodul- 446 Steuerbefehls, eines effektiven Adressenzeigers zu einer anwenderdefinierten Struktur, eines effektiven Adressenzeigers zu einer Warteschlange von Steuerbefehlen oder einer beliebigen anderen Datenstruktur sein, um die Arbeit zu beschreiben, die von dem Grafikbeschleunigungsmodul 446 zu erledigen ist. In einer Ausführungsform ist der AMR-Wert der AMR-Zustand, der für den aktuellen Prozess zu verwenden ist. Der Wert, der zu dem Betriebssystem geleitet wird, ist einer Anwendungseinstellung des AMR ähnlich. Wenn die Beschleunigerintegrationsschaltungs- 436 und Grafikbeschleunigungsmodul- 446 Implementierungen ein User Authority Mask Override Register (UAMOR) nicht unterstützen, kann das Betriebssystem den aktuellen UAMOR-Wert bei dem AMR-Wert anwenden, bevor das AMR in dem Hypervisoranruf weitergeleitet wird. Der Hypervisor 496 kann optional den aktuellen Authority Mask Override Register (AMOR) Wert anwenden, bevor der AMR in das Prozesselement 483 platziert wird. Der CSRP kann eines der Register 445 sein, die die effektive Adresse eines Bereichs in dem Adressenraum 482 der Anwendung für das Grafikbeschleunigungsmodul 446 enthalten, um den Kontextzustand zu speichern und wiederherzustellen. Dieser Zeiger ist optional, wenn kein Zustand zwischen Jobs gespeichert oder wiederhergestellt werden muss, oder wenn ein Job vorweggenommen wird. Der Kontextspeicher-/-wiederherstellungsbereich kann gepinnter Systemspeicher sein.
  • Beim Empfang des Systemanrufs kann das Betriebssystem 495 verifizieren, dass die Anwendung 480 sich registriert hat und ihr Autorität verliehen wurde, das Grafikbeschleunigungsmodul 446 zu verwenden. Das Betriebssystem 495 ruft dann den Hypervisor 496 mit den Informationen auf, die in Tabelle 3 dargestellt sind. Tabelle 3 - OS zu Hypervisor-Anrufparameter
    1 Eine Arbeitsbeschreibung (WD)
    2 Ein Autoritätsmaskenregister- (AMR) Wert (möglicherweise maskiert).
    3 Ein effektive Adresse- (EA) Kontextspeicher-/-wiederherstellungsbereichszeiger (CSRP)
    4 Eine Prozess-ID (PID) und optionale Thread-ID (TID)
    5 Ein Beschleunigerbenutzungsaufzeichnungszeiger (AURP) für eine virtuelle Adresse (VA)
    6 Der Datenspeichersegmenttabellenzeiger (SSTP) für die virtuelle Adresse
    7 Eine logische Unterbrechungsdienstnummer (LISN)
  • Nach Empfang des Hypervisoranrufs verifiziert der Hypervisor 496, dass sich das Betriebssystem 495 registriert hat und ihm Autorität verliehen wurde, das Grafikbeschleunigungsmodul 446 zu verwenden. Der Hypervisor 496 stellt dann das Prozesselement 483 in die Liste angebundener Prozesselemente für die entsprechende Art von Grafikbeschleunigungsmodul 446. Das Prozesselement kann die Informationen aufweisen, die in Tabelle 4 dargestellt sind. Tabelle 4 - Prozesselementinformation
    1 Eine Arbeitsbeschreibung (WD)
    2 Ein Autoritätsmaskenregister- (AMR) Wert (möglicherweise maskiert)
    3 Eine effektive Adresse (EA) Kontextspeicher-/-wiederherstellungsbereichszeiger (CSRP)
    4 Eine Prozess-ID (PID) und optionale Thread-ID (TID)
    5 Ein Beschleunigerbenutzungsaufzeichnungszeiger (AURP) für eine virtuelle Adresse (VA)
    6 Der Datenspeichersegmenttabellenzeiger (SSTP) für die virtuelle Adresse
    7 Eine logische Unterbrechungsdienstnummer (LISN)
    8 Unterbrechungsvektortabelle, abgeleitet aus den Hypervisoranrufparametern
    9 Einen Zustandsregister- (SR) Wert
    10 Eine logische Abtrennung ID (LPID)
    11 Einen Hypervisor-Beschleunigerbenutzungsaufzeichnungszeiger für eine reale Adresse (RA)
    12 Das Datenspeicherbeschreiberregister (SDR)
  • Der Hypervisor kann mehrere Beschleunigerintegrations-Slice- 490 Register 445 initialisieren.
  • Wie in 4F veranschaulicht, wird in einer optionalen Implementierung ein vereinheitlichter Speicher, der über einen gemeinsamen virtuellen Speicheradressenraum adressierbar ist, verwendet, um auf die physischen Prozessorspeicher 401-402 und GPU-Speicher 420-423 zuzugreifen. In dieser Implementierung benutzen Operationen, die auf den GPUs 410-413 ausgeführt werden, denselben virtuellen/effektiven Speicheradressenraum, um auf die Prozessorspeicher 401-402 zuzugreifen und umgekehrt, wodurch Programmierbarkeit vereinfacht wird. Ein erster Teil des virtuellen/effektiven Adressenraums kann dem Prozessorspeicher 401, ein zweiter Teil dem zweiten Prozessorspeicher 402, ein dritter Teil dem GPU-Speicher 420 zugeordnet werden und so weiter. Der gesamte virtuelle/effektive Speicherraum (manchmal als der effektive Adressenraum bezeichnet) kann dadurch über jeden der Prozessorspeicher 401-402 und GPU-Speicher 420-423 verteilt werden, was einem Prozessor oder GPU erlaubt, auf einen physischen Speicher mit einer virtuellen Adresse zuzugreifen, die auf diesen Speicher abgebildet ist.
  • Bias/Kohärenzverwaltungsschaltkreise 494A-494E in einer oder mehreren der MMUs 439A-439E können bereitgestellt sein, der Zwischenspeicherungskohärenz zwischen den Caches der Host-Prozessoren (z.B. 405) und den GPUs 410-413 sicherstellt und Biasing-Techniken implementiert, die den physischen Speicher angeben, in dem gewisse Arten von Daten gespeichert werden sollten. Während mehrere Exemplare von Bias/Kohärenzverwaltungsschaltkreisen 494A-494E in 4F veranschaulicht sind, kann der Bias/Kohärenzschaltkreis in der MMU eines oder mehrerer Host-Prozessoren 405 und/oder in der Beschleunigerintegrationsschaltung 436 implementiert sein.
  • Der GPU-angehängte Speicher 420-423 kann als Teil von Systemspeicher abgebildet werden und auf ihn kann unter Verwendung geteilter virtueller Speicher-(SVM, Shared Virtual Memory) Technologie zugegriffen werden, ohne aber unter den typischen Arbeitsleistungsnachteilen zu leiden, die mit voller Systemzwischenspeicherungskohärenz verbunden sind. Die Fähigkeit des GPU-angehängten Speichers 420-423, dass auf ihn als Systemspeicher zugegriffen werden kann, ohne beschwerlichen Zwischenspeicherungskohärenzmehraufwand, stellt eine günstige Betriebsumgebung für GPU-Entladung bereit. Diese Anordnung erlaubt der Host-Prozessor- 405 Software, Operanden einzurichten und auf Berechnungsergebnisse zuzugreifen, ohne den Mehraufwand herkömmlicher I/O DMA Datenkopien. Solche herkömmlichen Kopien beinhalten Treiberanrufe, Unterbrechungen und Speicherabgebildete I/O (MMIO) Zugriffe, die alle relativ zu einfachen Speicherzugriffen ineffizient sind. Gleichzeitig kann die Fähigkeit, auf den GPU-angehängten Speicher 420-423 ohne Zwischenspeicherungskohärenzmehraufwand zuzugreifen, für die Ausführungszeit einer entladenen Berechnung kritisch sein. In Fällen mit wesentlichem Streaming-Schreibspeicherverkehr zum Beispiel kann Zwischenspeicherungskohärenzmehraufwand die effektive Schreibbandbreite signifikant verringern, die von einer GPU 410-413 gesehen wird. Die Effizienz einer Operandeneinrichtung, die Effizienz von Zugriff auf Ergebnisse und die Effizienz von GPU-Berechnung spielen alle eine Rolle in der Bestimmung der Wirksamkeit einer GPU-Entladung.
  • Eine Auswahl zwischen GPU-Bias und Host-Prozessor-Bias kann durch eine Bias-Verfolgerdatenstruktur angetrieben werden. Es kann zum Beispiel eine Bias-Tabelle verwendet werden, die eine seitengranulare Struktur sein kann (d.h. bei der Granularität einer Speicherseite gesteuert wird), die 1 oder 2 Bits pro GPU-angehängter Speicherseite aufweist. Die Bias-Tabelle kann in einem gestohlenen Speicherbereich eines oder mehrerer GPU-angehängter Speicher 420-423, mit oder ohne einen Bias-Cache in der GPU 410-413 implementiert sein (z.B. um häufig/zuletzt verwendete Einträger der Bias-Tabelle zwischenzuspeichern). Alternativ kann die gesamte Bias-Tabelle in der GPU geführt werden.
  • In einer Implementierung wird auf den Bias-Tabelleneintrag, der mit jedem Zugriff auf den GPU-angehängten Speicher 420-423 verknüpft ist, vor dem tatsächlichen Zugriff auf den GPU-Speicher zugegriffen, was die folgenden Operationen veranlasst. Erstens werden lokale Anfragen von der GPU 410-413, die ihre Seite in GPU-Bias finden direkt zu einem entsprechenden GPU-Speicher 420-423 weitergeleitet. Lokale Anfragen von der GPU, die ihre Seite im Host-Bias finden, werden zu dem Prozessor 405 weitergeleitet (z.B. über einen Hochgeschwindigkeitslink wie oben besprochen). Optional vollenden Anfragen von dem Prozessor 405, die die angefragte Seite im Host-Prozessor-Bias finden, die Anfrage wie eine normale Speicherauslesung. Alternativ können Anfragen, die an eine Seite mit GPU-Bias gerichtet sind, zu der GPU 410-413 weitergeleitet werden. Die GPU kann dann die Seite zu einem Host-Prozessor-Bias überführen, wenn sie derzeit die Seite nicht verwendet.
  • Der Bias-Zustand einer Seite kann entweder durch einen Software-basierten Mechanismus, einen Hardware-unterstützten Software-basierten Mechanismus oder, für einen begrenzten Satz von Fällen, einen rein Hardware-basierten Mechanismus geändert werden.
  • Ein Mechanismus zum Ändern des Bias-Zustands benutzt einen API-Anruf (z.B. OpenCL), der wiederum den Vorrichtungstreiber der GPU anruft, der wiederum eine Nachricht (an die GPU sendet oder einen Steuerbefehlbeschreiber einreiht), die diese veranlasst, den Bias-Zustand zu ändern und für manche Übergänge einen Cache-Spülbetrieb im Host auszuführen. Der Cache-Spülbetrieb ist für einen Übergang vom Host-Prozessor- 405 Bias zum GPU-Bias erforderlich, ist aber nicht für den entgegengesetzten Übergang erforderlich.
  • Zwischenspeicherungskohärenz kann durch vorübergehendes Rendern von Seiten mit GPU-Bias aufrechterhalten werden, die von dem Host-Prozessor 405 nicht zwischengespeichert werden können. Für einen Zugriff auf diese Seiten kann der Prozessor 405 Zugriff von der GPU 410 anfragen, die Zugriff unmittelbar gewähren kann oder nicht, abhängig von der Implementierung. Somit ist es, um Kommunikation zwischen dem Host-Prozessor 405 und der GPU 410 zu verringern, günstig sicherzustellen, dass Seiten mit GPU-Bias jene sind, die von der GPU benötigt sind, aber nicht vom Host-Prozessor 405, und umgekehrt.
  • Grafikverarbeitungs-Pipeline
  • 5 veranschaulicht eine Grafikverarbeitungs-Pipeline 500. Ein Grafikmultiprozessor, wie Grafikmultiprozessor 234, wie in 2D, Grafikmultiprozessor 325 von 3A, Grafikmultiprozessor 350 von 3B können die veranschaulichte Grafikverarbeitungs-Pipeline 500 implementieren. Der Grafikmultiprozessor kann in den Parallelverarbeitungsteilsystemen wie hier beschrieben enthalten sein, wie der parallele Prozessor 200 von 2A, der mit den parallelen Prozessor(en) 112 von 1 verwandt sein kann und anstelle eines von diesen verwendet werden kann. Die verschiedenen Parallelverarbeitungssysteme können die Grafikverarbeitungs-Pipeline 500 über ein oder mehrere Exemplare der Parallelverarbeitungseinheit (z.B. Parallelverarbeitungseinheit 202 von 2A) implementieren, wie hier beschrieben. Zum Beispiel kann eine Shader-Einheit (z.B. Grafikmultiprozessor 234 von 2C) konfiguriert sein, die Funktionen einer oder mehrerer einer Vertexverarbeitungseinheit 504, einer Tessellationsteuerungsverarbeitungseinheit 508, einer Tessellationsauswertungsverarbeitungseinheit 512, einer Geometrieverarbeitungseinheit 516 und eine Fragment/Pixel-Verarbeitungseinheit 524 auszuführen. Die Funktionen von Datenassemblierer 502, Primitive-Assemblierer 506, 514, 518, Tessellationseinheit 510, Rasterisierer 522 und Rasteroperationseinheit 526 können auch von anderen Verarbeitungs-Engines in einem Verarbeitungscluster (z.B. Verarbeitungscluster 214 von 2A) und einer entsprechenden Trennungseinheit (z.B. Trennungseinheit 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 Teile der Grafikverarbeitungs-Pipeline 500 durch Parallelverarbeitungslogik in einem Allzweckprozessor (z.B. CPU) durchgeführt werden. Optional können ein oder mehrere Teile der Grafikverarbeitungs-Pipeline 500 auf On-Chip Speicher (z.B. paralleler Prozessorspeicher 222 wie in 2A) über eine Speicherschnittstelle 528 zugreifen, der ein Exemplar der Speicherschnittstelle 218 von 2A sein kann. Die Grafikprozessor-Pipeline 500 kann auch über eine Mehrfachkerngruppe 365A implementiert sein, wie in 3C.
  • Der Datenassemblierer 502 ist eine Verarbeitungseinheit, die Vertexdaten für Oberflächen und Primitive sammeln kann. Der Datenassemblierer 502 gibt dann die Vertexdaten, aufweisend die Vertexattribute, an die Vertexverarbeitungseinheit 504 aus. Die Vertexverarbeitungseinheit 504 ist eine programmierbare Ausführungseinheit, die Vertex-Shader-Programme ausführt, wobei Vertex-Daten wie durch die Vertex-Shader-Programme beleuchtet und transformiert werden. Die Vertexverarbeitungseinheit 504 liest Daten, die im Cache, lokalen oder Systemspeicher gespeichert sind, zur Verwendung in der Verarbeitung der Vertex-Daten und kann programmiert sein, die Vertex-Daten von einer Objekt-basierten Koordinatendarstellung zu einem weltweiten Koordinatenraum oder einen normalisierten Vorrichtungskoordinatenraum zu transformieren.
  • Ein erstes Exemplar eines Primitive-Assemblierers 506 empfängt Vertexattribute von der Vertexverarbeitungseinheit 504. Der Primitive-Assemblierer 506 liest gespeicherte Vertexattribute nach Bedarf und konstruiert Grafikprimitive zur Verarbeitung durch Tessellationssteuerungsverarbeitungseinheit 508. Die Grafikprimitive weisen Dreiecke, Liniensegmente, Punkte, Felder und so weiter auf, wie von verschiedenen Grafikverarbeitung-Anwendungsprogrammierungsschnittstellen (APIs) unterstützt.
  • Die Tessellationssteuerungsverarbeitungseinheit 508 behandelt die eingegebenen Vertices als Kontrollpunkte für ein geometrisches Feld. Die Kontrollpunkte werden von einer Eingangsdarstellung von dem Feld (z.B. den Basen des Felds) zu einer Darstellung umgeformt, die zur Verwendung in Oberflächenauswertung durch die Tessellationsauswertungsverarbeitungseinheit 512 geeignet sind. Die Tessellationssteuerungsverarbeitungseinheit 508 kann auch Tessellationsfaktoren für Ränder der geometrischen Felder berechnen. Ein Tessellationsfaktor wendet einen einzigen Rand an und quantifiziert eine ansichtsabhängige Ebene eines Details, das mit dem Rand verknüpft ist. Eine Tessellationseinheit 510 ist konfiguriert, die Tessellationsfaktoren für Ränder eines Feldes zu empfangen und das Feld in mehrere geometrische Primitive wie Linie, Dreieck oder vierseitige Primitive zu tessellieren, die zu einer Tessellationsauswertungsverarbeitungseinheit 512 übertragen werden. Die Tessellationsauswertungsverarbeitungseinheit 512 bearbeitet parametrisierte Koordinaten des unterteilten Felds, um eine Oberflächendarstellung und Vertexattribute für jeden Vertex, der mit den geometrischen Primitiven verknüpft ist, zu erzeugen.
  • Ein zweites Exemplar eines Primitive-Assemblierers 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 zum Transformieren von Grafikprimitiven durchführt, die vom Primitive-Assemblierer 514 empfangen werden, wie durch die Geometrie-Shader-Programme spezifiziert. Die Geometrieverarbeitungseinheit 516 kann programmiert sein, die Grafikprimitive in eine oder mehrere neue Grafikprimitive zu unterteilen und Parameter zu berechnen, die zum Rastern der neuen Grafikprimitive verwendet werden.
  • Die Geometrieverarbeitungseinheit 516 kann imstande sein, Elemente in den Geometriestrom hinzuzufügen oder aus diesem zu löschen. Die Geometrieverarbeitungseinheit 516 gibt die Parameter und Vertices, die neue Grafikprimitive spezifizieren, an Primitive-Assemblierer 518 aus. Der Primitive-Assemblierer 518 empfängt die Parameter und Vertices von der Geometrieverarbeitungseinheit 516 und konstruiert Grafikprimitive zur Verarbeitung durch eine Darstellungsfeldskala-, Cull- und Zuschneideeinheit 520. Die Geometrieverarbeitungseinheit 516 liest Daten, die im parallelen Prozessorspeicher oder Systemspeicher gespeichert sind, zur Verwendung in Verarbeitung der Geometriedaten aus. Die Darstellungsfeldskala-, Cull- und Zuschneideeinheit 520 führt Zuschneiden, Culling und Darstellungsfeldskalierung aus und gibt verarbeitete Grafikprimitive an einen Rasterisierer 522 aus.
  • Der Rasterisierer 522 kann tiefes Culling und andere tiefenbasierte Optimierungen durchführen. Der Rasterisierer 522 führt auch Abtastumwandlung an den neuen Grafikprimitiven aus, um Fragmente zu erzeugen und diese Fragmente und zugehörige Abdeckungsdaten an die Fragment-/Pixelverarbeitungseinheit 524 auszugeben. Die Fragment-/Pixelverarbeitungseinheit 524 ist eine programmierbare Ausführungseinheit, die konfiguriert ist, Fragment-Shader-Programme oder Pixel-Shader-Programme auszuführen. Die Fragment-/Pixelverarbeitungseinheit 524 transformiert Fragmente oder Pixel, die vom Rasterisierer 522 empfangen werden, wie durch die Fragment- oder Pixel-Shader-Programme spezifiziert. Zum Beispiel kann die Fragment-/Pixelverarbeitungseinheit 524 programmiert sein, Operationen durchzuführen, aufweisend, ohne aber darauf beschränkt zu sein, Texturabbildung, Shading, Überblendung, Texturkorrektur und Perspektivenkorrektur, um schattierte Fragmente oder Pixel zu erzeugen, die an eine Rasteroperationseinheit 526 ausgegeben werden. Die Fragment-/Pixelverarbeitungseinheit 524 kann Daten, die entweder in dem parallelen Prozessorspeicher oder dem Systemspeicher zur Verwendung gespeichert sind, lesen, wenn die Fragmentdaten verarbeitet werden. Fragment- oder Pixel-Shader-Programme können konfiguriert sein, bei Probe-, Pixel-, Kachel- oder anderen Granularitäten zu schattieren, abhängig von der Abtastrate, die für die Verarbeitungseinheiten konfiguriert ist.
  • Die Rasteroperationseinheit 526 ist eine Verarbeitungseinheit, die Rasteroperationen durchführt, aufweisend, aber nicht beschränkt auf, Stencil, z-Test, Überblendung und dergleichen, und gibt Pixeldaten als verarbeitete Grafikdaten, die im Grafikspeicher (z.B. paralleler Prozessorspeicher 222 wie in 2A und/oder Systemspeicher 104 wie in 1) gespeichert werden sollen, die auf der einen oder den mehreren Anzeigevorrichtung(en) 110 angezeigt werden sollen, oder zur Weiterverarbeitung durch den einen oder die mehreren Prozessor(en) 102 oder parallelen Prozessor(en) 112 aus. Die Rasteroperationseinheit 526 kann konfiguriert sein, z- oder Farbdaten zu komprimieren, die in den Speicher geschrieben werden, und z- oder Farbdaten zu dekomprimieren, die aus dem Speicher gelesen werden.
  • Überblick über Maschinenlernen
  • Die oben beschriebene Architektur kann angewendet werden, um Trainings- und Schlussfolgerungsoperationen unter Verwendung von Maschinenlernmodellen durchzuführen. Maschinenlernen ist bei der Lösung vieler Arten von Aufgaben erfolgreich. Die Berechnungen, die beim Training und unter Verwendung von Maschinenlernalgorithmen (z.B. neurale Netzwerke) entstehen, eignen sich natürlich für effiziente parallele Implementierungen. Daher haben parallele Prozessoren wie Allzweckgrafikverarbeitungseinheiten (GPGPUs) eine signifikante Rolle in der praktischen Implementierung tiefer neuraler Netzwerke gespielt. Parallele Grafikprozessoren mit Einzelbefehl, Mehrfach-Thread- (SIMT) Architekturen sind gestaltet, die Menge an Parallelverarbeitung in der Grafik-Pipeline zu maximieren. In einer SIMT-Architektur versuchen Gruppen paralleler Threads, Programmbefehle gemeinsam so oft wie möglich synchron auszuführen, um Verarbeitungseffizienz zu erhöhen. Die Effizienz, die durch parallele Maschinenlernalgorithmusimplementierungen bereitgestellt wird, erlaubt die Verwendung von Netzwerken hoher Kapazität und ermöglicht diesen Netzwerken, auf größere Datensätze trainiert zu werden.
  • Ein Maschinenlernalgorithmus ist ein Algorithmus, der auf der Basis eines Satzes von Daten lernen kann. Zum Beispiel können Maschinenlernalgorithmen gestaltet sein, Abstraktionen hoher Ebene in einem Datensatz als Modell darzustellen. Zum Beispiel können Bilderkennungsalgorithmen verwendet werden um zu bestimmen, zu welcher von mehreren Kategorien ein bestimmter Eingang gehört; Regressionsalgorithmen können einen als Eingang gegebenen numerischen Wert ausgeben; und Mustererkennungsalgorithmen können verwendet werden, um übersetzten Text zu erzeugen oder Text-zu-Sprache- und/oder Spracherkennung durchzuführen.
  • Eine beispielhafte Art von Maschinenlernalgorithmus ist ein neurales Netzwerk. Es gibt viele Arten von neuralen Netzwerken; eine einfache Art von neuralem Netzwerk 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 Eingangsschicht und eine Ausgangsschicht auf, die durch mindestens eine verborgene Schicht getrennt sind. Die verborgene Schicht transformiert Eingang, der durch die Eingangsschicht empfangen wird, in eine Darstellung, die zum Erzeugen von Ausgang in der Ausgangsschicht nützlich ist. Die Netzwerkknoten sind über Ränder vollständig mit den Knoten in angrenzenden Schichten verbunden, aber es gibt keine Ränder zwischen Knoten in jeder Schicht. Daten, die bei den Knoten einer Eingangsschicht eines vorwärtsgekoppelten Netzwerks empfangen werden, werden zu den Knoten der Ausgangsschicht über eine Aktivierungsfunktion übertragen (d.h. „vorwärtsgekoppelt“), die die Zustände der Knoten jeder folgenden Schicht in dem Netzwerk auf Basis von Koeffizienten („Gewichte“) berechnet, die jeweils jedem der Ränder zugeordnet sind, die die Schichten verbinden. Abhängig von dem bestimmten Modell, das durch den ausgeführten Algorithmus dargestellt ist, kann der Ausgang von dem neuralen Netzwerkalgorithmus verschiedene Formen annehmen.
  • Bevor ein Maschinenlernalgorithmus verwendet werden kann, um ein bestimmtes Problem als Modell darzustellen, wird der Algorithmus unter Verwendung eines Trainingsdatensatzes trainiert. Training eines neuralen Netzwerk beinhaltet Auswählen einer Netzwerktopologie unter Verwendung eines Satzes von Trainingsdaten, der ein Problem präsentiert, das von dem Netzwerk als Modell darzustellen ist, und Einstellen der Gewichte, bis das Netzwerkmodell mit einem minimalen Fehler für alle Exemplare des Trainingsdatensatzes arbeitet. Zum Beispiel wird während eines überwachten Lerntrainingsprozesses für ein neurales Netzwerk der Ausgang, der von dem Netzwerk in Antwort auf den Eingang erzeugt wird, der ein Exemplar in einem Trainingsdatensatz darstellt, mit dem als „korrekt“ markierten Ausgang für dieses Exemplar erzeugt, ein Fehlersignal, das die Differenz zwischen dem Ausgang und dem markierten Ausgang darstellt, wird berechnet und die Gewichte, die mit den Verbindungen verknüpft sind, werden eingestellt, um diesen Fehler zu minimieren, wenn das Fehlersignal durch die Schichten des Netzwerks zurück übertragen wird. Das Netzwerk wird als „trainiert“ angesehen, wenn die Fehler für jeden der Ausgänge, die aus den Exemplaren des Trainingsdatensatzes erzeugt werden, minimiert sind.
  • Die Genauigkeit eines Maschinenlernalgorithmus kann signifikant durch die Qualität des Datensatzes beeinflusst werden, der zum Trainieren des Algorithmus verwendet wird. Der Trainingsprozess kann rechenintensiv sein und kann eine signifikante Zeit auf einem herkömmlichen Allzweckprozessor brauchen. Daher wird Parallelverarbeitungshardware verwendet, um viele Arten von Maschinenlernalgorithmen zu trainieren. Dies ist besonders zum Optimieren des Trainings neuraler Netzwerke nützlich, da die Berechnungen, die beim Einstellen der Koeffizienten in neuralen Netzwerken verwendet werden, sich natürlich für parallele Implementierungen eignen. Insbesondere wurden viele Maschinenlernalgorithmen und Softwareanwendungen angepasst, um die Parallelverarbeitungshardware in Allzweckgrafikverarbeitungsvorrichtungen zu nutzen.
  • 6 ist ein verallgemeinertes Diagramm eines Maschinenlern-Softwarestapels 600. Eine Maschinenlernanwendung 602 ist jede Logik, die konfiguriert sein kann, ein neurales Netzwerk unter Verwendung eines Trainingsdatensatzes zu trainieren, oder ein trainiertes tiefes neurales Netzwerk zu verwenden, um Maschinenintelligenz zu implementieren. Die Maschinenlernanwendung 602 kann Trainings- und Schlussfolgerungsfunktionalität für ein neurales Netzwerk und/oder spezialisierte Software aufweisen, die verwendet werden können, um ein neurales Netzwerk vor Nutzung zu trainieren. Die Maschinenlernanwendung 602 kann jede Art von Maschinenintelligenz implementieren, aufweisend, ohne aber darauf beschränkt zu sein, Bilderkennung, Abbildung und Lokalisierung, autonome Navigation, Sprachsynthese, medizinische Bildgebung oder Sprachübersetzung. Beispielhafte Maschinenlernanwendungen 602 weisen sprachbasierte virtuelle Assistenten, Bild- oder Gesichtserkennungsalgorithmen, autonome Navigation und die Software-Tools auf, ohne aber darauf beschränkt zu sein, die zum Trainieren der Maschinenlernmodelle verwendet werden, die von den Maschinenlernanwendungen 602 verwendet werden.
  • Hardwarebeschleunigung für die Maschinenlernanwendung 602 kann über ein Maschinenlern-Framework 604 ermöglicht werden. Das Maschinenlern-Framework 604 kann eine Bibliothek von Maschinenlernprimitiven bereitstellen. Maschinenlernprimitive sind grundlegende Operationen, die gemeinsam durch Maschinenlernalgorithmen durchgeführt werden. Ohne das Maschinenlern-Framework 604 müssen Entwickler von Maschinenlernalgorithmen die Hauptberechnungslogik, die mit dem Maschinenlernalgorithmus verknüpft ist, erstellen und optimieren, dann die Berechnungslogik erneut optimieren, wenn neue parallele Prozessoren entwickelt werden. Stattdessen kann die Maschinenlernanwendung konfiguriert sein, die notwendigen Berechnungen unter Verwendung der Primitive durchzuführen, die durch das Maschinenlern-Framework 604 bereitgestellt werden. Beispielhafte Primitive weisen Tensorkonvolutionen, Aktivierungsfunktionen und Pooling auf, die Berechnungsoperationen sind, die durchgeführt werden, während ein Convolutional Neural Network (CNN) trainiert wird. Das Maschinenlern-Framework 604 kann auch Primitive bereitstellen, um grundlegende, lineare, algebraische Teilprogramme zu implementieren, die von vielen Maschinenlernalgorithmen durchgeführt werden, wie Matrix- und Vektoroperationen. Beispiele für ein Maschinenlern-Framework 604 weisen TensorFlow, TensorRT, PyTorch, MXNet, Caffee und andere Maschinenlern-Frameworks hoher Ebene auf, sind aber nicht darauf beschränkt.
  • Das Maschinenlern-Framework 604 kann Eingangsdaten verarbeiten, die von der Maschinenlernanwendung 602 empfangen werden, und den richtigen Eingang zu einem Rechen-Framework 606 erzeugen. Das Rechen-Framework 606 kann die zugrundeliegenden Befehle, die dem GPGPU-Treiber 608 bereitgestellt werden, abstrahieren, um dem Maschinenlern-Framework 604 zu ermöglichen, Hardwarebeschleunigung über die GPGPU-Hardware 610 zu nutzen, ohne zu erfordern, dass das Maschinenlern-Framework 604 genaue Kenntnis der Architektur der GPGPU-Hardware 610 hat. Zusätzlich kann das Rechen-Framework 606 Hardwarebeschleunigung für das Maschinenlern-Framework 604 über eine Vielzahl von Arten und Generationen der GPGPU-Hardware 610 ermöglichen. Beispielhafte Rechen-Frameworks 606 weisen das CUDA Rechen-Framework und zugehörige Maschinenlernbibliotheken auf, wie die CUDA tiefe neurale Netzwerk- (cuDNN) Bibliothek. Der Maschinenlern-Softwarestapel 600 kann auch Kommunikationsbibliotheken oder Frameworks aufweisen, um Multi-GPU- und Mehrfachknotenberechnungen zu erleichtern.
  • GPGPU-Maschinenlernbeschleunigung
  • 7 veranschaulicht eine Allzweckgrafikverarbeitungseinheit 700, die der parallele Prozessor 200 von 2A oder der (die) parallelen Prozessor(en) 112 von 1 sein kann. Die Allzweckverarbeitungseinheit (GPGPU) 700 kann konfiguriert sein, Unterstützung für Hardwarebeschleunigung von Primitiven bereitzustellen, die durch ein Maschinenlern-Framework zum Beschleunigen der Verarbeitung der Art von Berechnungsarbeitslasten bereitgestellt werden, die mit Training tiefer neuraler Netzwerke verknüpft sind. Zusätzlich kann die GPGPU 700 direkt mit anderen Exemplaren der GPGPU verbunden sein, um einen Multi-GPU-Cluster zu erzeugen, um Trainingsgeschwindigkeit für besonders tiefe neurale Netzwerke zu verbessern. Primitive werden auch unterstützt, um Schlussfolgerungsoperationen für eingesetzte neurale Netzwerke zu beschleunigen.
  • Die GPGPU 700 weist eine Host-Schnittstelle 702 auf, um eine Verbindung mit einem Host-Prozessor zu ermöglichen. Die Host-Schnittstelle 702 kann eine PCI Express Schnittstelle sein. Die Host-Schnittstelle kann jedoch auch eine verkäuferbestimmte Kommunikationsschnittstelle oder ein Kommunikations-Fabric sein. Die GPGPU 700 empfängt Steuerbefehle von dem Host-Prozessor und verwendet einen globalen Scheduler 704 zum Verteilen von Ausführungs-Threads, die mit diesen Steuerbefehlen verknüpft sind, zu einem Satz von Verarbeitungsclustern 706A-706H. Die Verarbeitungscluster 706A-706H teilen sich einen Cache-Speicher 708. Der Cache-Speicher 708 kann als ein Cache höherer Ebene für Cache-Speicher in den Verarbeitungsclustern 706A-706H dienen. Die veranschaulichten Verarbeitungscluster 706A-706H können Verarbeitungsclustern 214A-214N wie in 2A entsprechen.
  • Die GPGPU 700 weist Speicher 714A-714B auf, die mit den Verarbeitungsclustern 706A-706H über einen Satz von Speichersteuerungen 712A-712B gekoppelt sind. Die Speicher 714A-714B können verschiedene Arten von Speichervorrichtungen aufweisen, aufweisend dynamischen Direktzugriffsspeicher (DRAM) oder Grafikdirektzugriffsspeicher, wie synchronen Grafikdirektzugriffsspeicher (SGRAM), aufweisend Grafikdoppeldatenraten- (GDDR) Speicher. Die Speicher 714A-714B können auch 3D-gestapelte Speicher aufweisen, aufweisend, ohne aber darauf beschränkt zu sein, Speicher hoher Bandbreite (HBM).
  • Jeder der Verarbeitungscluster 706A-706H kann einen Satz von Grafikmultiprozessoren aufweisen, wie den Grafikmultiprozessor 234 von 2D, Grafikmultiprozessor 325 von 3A, Grafikmultiprozessor 350 von 3B, oder kann eine Mehrfachkerngruppe 365A-365N aufweisen, wie in 3C. Die Grafikmultiprozessoren des Rechen-Clusters weisen mehrere Arten von Ganzzahl- und Gleitkommalogikeinheiten auf, die Berechnungsoperationen bei einem Präzisionsbereich durchführen können, aufweisend jene, die für Maschinenlernberechnungen geeignet sind. Zum Beispiel kann mindestens ein Teilsatz der Gleitkommaeinheiten in jedem der Verarbeitungsclusters 706A-706H konfiguriert sein, 16-Bit oder 32-Bit Gleitkommaoperationen durchzuführen, während ein anderer Teilsatz der Gleitkommaeinheiten konfiguriert sein kann, 64-Bit Gleitkommaoperationen durchzuführen.
  • Mehrere Exemplare der GPGPU 700 können konfiguriert sein, als ein Rechen-Cluster zu arbeiten. Der Kommunikationsmechanismus, der von dem Rechen-Cluster zur Synchronisation und für Datenaustausch verwendet wird, variiert über Ausführungsformen. Zum Beispiel kommunizieren die mehreren Exemplare der GPGPU 700 über die Host-Schnittstelle 702. In einer Ausführungsform weist die GPGPU 700 einen I/O-Hub 709 auf, der die GPGPU 700 mit einem GPU-Link 710 koppelt, der eine direkte Verbindung mit anderen Exemplaren der GPGPU ermöglicht. Der GPU-Link 710 kann an eine dedizierte GPU-zu-GPU-Brücke gekoppelt sein, die Kommunikation und Synchronisation zwischen mehreren Exemplaren der GPGPU 700 ermöglicht. Optional ist der GPU-Link 710 mit einem Hochgeschwindigkeit-Interconnect gekoppelt, um Daten zu empfangen und zu anderen GPGPUs oder parallelen Prozessoren zu übertragen. Die mehreren Exemplare der GPGPU 700 können in separaten Datenverarbeitungssystemen liegen und über eine Netzwerkvorrichtung kommunizieren, auf die über die Host-Schnittstelle 702 zugegriffen werden kann. Der GPU-Link 710 kann konfiguriert sein, eine Verbindung zu einem Host-Prozessor zusätzlich oder als Alternative zu der Host-Schnittstelle 702 zu ermöglichen.
  • Während die veranschaulichte Konfiguration der GPGPU 700 konfiguriert sein kann, neurale Netzwerke zu trainieren, kann eine andere Konfiguration der GPGPU 700 zur Nutzung in einer Schlussfolgerungsplattform hoher Arbeitsleistung oder niederer Leistung konfiguriert sein. In einer Schlussfolgerungskonfiguration weist die GPGPU 700 weniger der Verarbeitungscluster 706A-706H relativ zu der Trainingskonfiguration auf. Zusätzlich kann sich die Speichertechnologie, die mit den Speichern 714A-714B verknüpft ist, zwischen Schlussfolgerungs- und Trainingskonfiguration unterscheiden. In einer Ausführungsform kann die Schlussfolgerungskonfiguration der GPGPU 700 schlussfolgerungsspezifische Befehle unterstützen. Zum Beispiel kann eine Schlussfolgerungskonfiguration Unterstützung für einen oder mehrere 8-Bit ganzzahlige Skalarproduktbefehle bereitstellen, die gemeinsam während Schlussfolgerungsoperationen für eingesetzte neurale Netzwerke verwendet werden.
  • 8 veranschaulicht ein Multi-GPU-Rechensystem 800. Das Multi-GPU-Rechensystem 800 kann einen Prozessor 802 aufweisen, der über einen Host-Schnittstellenschalter 804 an mehrere GPGPUs 806A-806D gekoppelt ist. Der Host-Schnittstellenschalter 804 kann eine PCI Express-Schaltvorrichtung sein, die den Prozessor 802 an einen 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 ein Exemplar 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 zwischenverbunden sein. Die Hochgeschwindigkeits-, GPU-zu-GPU-Links können mit jeder der GPGPUs 806A-806D über einen dedizierten GPU-Link verbunden sein, wie den GPU-Link 710, wie in 7. Die P2P GPU-Links 816 ermöglichen direkte Kommunikation zwischen jeder der GPGPUs 806A-806D, ohne Kommunikation über den Host-Schnittstellenbus zu erfordern, mit dem der Prozessor 802 verbunden ist. Mit GPU-zu-GPU-Verkehr, der zu den P2P GPU-Links gelenkt wird, bleibt der Host-Schnittstellenbus für Systemspeicherzugriff oder für Kommunikation mit anderen Exemplaren des Multi-GPU-Rechensystems 800 verfügbar, zum Beispiel über eine oder mehrere Netzwerkvorrichtungen. Während in 8 die GPGPUs 806A-806D mit dem Prozessor 802 über den Host-Schnittstellenschalter 804 verbunden sind, kann der Prozessor 802 alternativ direkte Unterstützung für die P2P GPU-Links 816 aufweisen und direkt mit den GPGPUs 806A-806D verbunden sein. In einer Ausführungsform ermöglicht der P2P GPU-Link 816 dem Multi-GPU-Rechensystem 800, als eine einzelne logische GPU zu arbeiten.
  • Neurale Netzwerkimplementierungen für Maschinenlernen
  • Die hier beschriebene Berechnungsarchitektur kann konfiguriert sein, die Arten von Parallelverarbeitung durchzuführen, die besonders für Training und Einsatz neuraler Netzwerke für Maschinenlernen geeignet sind. Ein neurales Netzwerk kann als ein Netzwerk von Funktionen mit einer Graphenbeziehung verallgemeinert werden. Wie in der Technik allgemein bekannt ist, gibt es eine Reihe von Arten von neuralen Netzwerkimplementierungen, die beim Maschinenlernen verwendet werden. Eine beispielhafte Art von neuralem Netzwerk ist das vorwärtsgekoppelte Netzwerk wie zuvor beschrieben.
  • Eine zweite beispielhafte Art von neuralem Netzwerk ist das Convolutional Neural Network (CNN). Ein CNN ist ein spezielles vorwärtsgekoppeltes neurales Netzwerk zur Verarbeitung von Daten mit einer bekannten gitterartigen Topologie, wie Bilddaten. Daher werden CNNs allgemein zum Berechnen von Bildverarbeitungs- und Bilderkennungsanwendungen verwendet, aber sie können auch für andere Arten von Mustererkennung, wie Sprech- und Sprachverarbeitung, verwendet werden. Die Knoten in der CNN-Eingangsschicht sind zu einem Satz von „Filtern“ (Merkmaldetektoren, die durch die rezeptiven Felder inspiriert sind, die in der Retina vorgefunden werden) organisiert und der Ausgang jedes Satzes von Filtern wird zu Knoten in aufeinanderfolgenden Schichten des Netzwerks geleitet. Die Berechnungen für ein CNN weisen Anwenden der mathematischen Kovolutionsoperation an jedem Filter auf, um den Ausgang für diesen Filter zu erzeugen. Konvolution ist eine spezielle Art von mathematischer Operation, die von zwei Funktionen durchgeführt wird, um eine dritte Funktion zu erzeugen, die eine modifizierte Version einer der zwei ursprünglichen Funktionen ist. In der Terminologie des Konvolutionsnetzwerks kann die erste Funktion für die Konvolution als der Eingang bezeichnet werden, während die zweite Funktion als der Konvolutionskernel bezeichnet werden kann. Der Ausgang kann als die Merkmalskarte bezeichnet werden. Zum Beispiel kann der Eingang zu einer Konvolutionsschicht eine mehrdimensionale Gruppe von Daten sein, die die verschiedenen Farbkomponenten eines Eingangsbilds definiert. Der Konvolutionskernel kann eine mehrdimensionale Gruppe von Parametern sein, wobei die Parameter durch den Trainingsprozess für das neurale Netzwerk angepasst werden.
  • Rekurrente neurale Netzwerke (RNNs) sind eine Familie von vorwärtsgekoppelten neuralen Netzwerken, die Feedback-Verbindungen zwischen Schichten aufweisen. RNNs ermöglichen Modellierung von aufeinanderfolgenden Daten durch Teilen von Parameterdaten über verschiedene Teile des neuralen Netzwerks. Die Architektur für ein RNN weist Zyklen auf. Die Zyklen stellen den Einfluss eines gegenwärtigen Werts einer Variable auf ihren eigenen Wert zu einem zukünftigen Zeitpunkt dar, da mindestens ein Teil der Ausgangsdaten von dem RNN als Feedback für Verarbeitung nach Eingabe in eine Abfolge verwendet wird. Dieses Merkmal macht RNNs für Sprachverarbeitung aufgrund seiner variablen Eigenschaft, in der Sprachdaten zusammengesetzt sein können, besonders nützlich.
  • Die unten beschriebenen Figuren stellen beispielhafte vorwärtsgekoppelte CNN und RNN Netzwerke dar, beschreiben auch einen allgemeinen Prozess für Training beziehungsweise Einsatz dieser Arten von Netzwerken. Es ist klar, dass diese Beschreibungen beispielhaft und nicht auf eine bestimmte, hier beschriebene Ausführungsform einschränkend sind und die veranschaulichten Konzepte im Allgemeinen bei tiefen neuralen Netzwerken und Maschinenlerntechniken im Allgemeinen angewendet werden können.
  • Die oben beschriebenen, beispielhaften, neuralen Netzwerke können verwendet werden, um tiefes Lernen durchzuführen. Tiefes Lernen ist Maschinenlernen unter Verwendung tiefer neuraler Netzwerke. Die tiefen neuralen Netzwerke, die beim tiefen Lernen verwendet werden, sind künstliche neurale Netzwerke, die aus mehreren verborgenen Schichten zusammengesetzt sind, im Gegensatz zu flachen neuralen Netzwerken, die nur eine einzige verborgene Schicht aufweisen. Tiefere neurale Netzwerke sind im Allgemeinen rechenintensiver zu trainieren. Die zusätzlichen verborgenen Schichten des Netzwerks ermöglichen jedoch mehrstufige Mustererkennung, die zu verringertem Ausgangsfehler relativ zu flachen Maschinenlerntechniken führt.
  • Tiefe neurale Netzwerke, die beim tiefen Lernen verwendet werden, weisen typischerweise ein Frontend Netzwerk zum Durchführen von Merkmalserkennung auf, das an ein Backend-Netzwerk gekoppelt ist, das ein mathematisches Modell darstellt, das Operationen (z.B. Objektklassifizierung, Spracherkennung usw.) basierend auf der Merkmalsdarstellung durchführen kann, die dem Modell bereitgestellt wird. Tiefes Lernen ermöglicht eine Durchführung von Maschinenlernen, ohne von Hand gestaltete Merkmalsbildung zu erfordern, die für das Modell durchgeführt wird. Stattdessen können tiefe neurale Netzwerke Merkmale basierend auf statistischer Struktur oder Korrelation in den Eingangsdaten lernen. Die gelernten Merkmale können einem mathematischen Modell bereitgestellt werden, das erfasste Merkmale auf einen Ausgang abbilden kann. Das mathematische Modell, das von dem Netzwerk verwendet wird, ist im Allgemeinen für die bestimmte durchzuführende Aufgabe spezialisiert und verschiedene Modelle werden zur Durchführung verschiedener Aufgaben verwendet.
  • Sobald das neurale Netzwerk strukturiert ist, kann ein Lernmodell an dem Netzwerk angewendet werden, um das Netzwerk zu trainieren, bestimmte Aufgaben durchzuführen. Das Lernmodell beschreibt, wie die Gewichte in dem Modell einzustellen sind, um den Ausgangsfehler des Netzwerks zu verringern. Rückübertragung von Fehlern ist ein allgemeines Verfahren, das zum Trainieren neuraler Netzwerke verwendet wird. Ein Eingangsvektor wird dem Netzwerk zur Verarbeitung präsentiert. Der Ausgang des Netzwerks wird mit dem gewünschten Ausgang unter Verwendung einer Verlustfunktion verglichen und ein Fehlerwert wird für jedes der Neuronen in der Ausgangsschicht berechnet. Die Fehlerwerte werden dann zurückübertragen, bis jedes Neuron einen zugehörigen Fehlerwert hat, der annähernd seinen Beitrag zu dem ursprünglichen Ausgang darstellt. Das Netzwerk kann dann aus diesen Fehlern unter Verwendung eines Algorithmus lernen, wie des stochastischen Gradientenabstiegsalgorithmus, um die Gewichte des neuralen Netzwerks zu aktualisieren.
  • 9A-9B veranschaulichen ein beispielhaftes Convolutional Neural Network. 9A veranschaulicht verschiedene Schichten in einem CNN. Wie in 9A dargestellt, kann ein beispielhaftes CNN, das zur Modelldarstellung von Bildverarbeitung verwendet wird, Eingang 902 empfangen, der die roten, grünen und blauen (RGB) Komponenten eines Eingangsbilds beschreibt. Der Eingang 902 kann durch mehrere Faltungsschichten verarbeitet werden (z.B. Faltungsschicht 904, Faltungsschicht 906). Der Ausgang von den mehreren Faltungsschichten kann optional durch einen Satz vollständig verbundener Schichten 908 verarbeitet werden. Neuronen in einer vollständig verbundenen Schicht haben vollständige Verbindungen zu allen Aktivierungen in der vorherigen Schicht, wie zuvor für ein vorwärtsgekoppeltes Netzwerk beschrieben. Der Ausgang von den vollständig verbundenen Schichten 908 kann verwendet werden, um ein Ausgangsergebnis von dem Netzwerk zu erzeugen. Die Aktivierungen in den vollständig verbundenen Schichten 908 können unter Verwendung von Matrixmultiplikation anstelle von Konvolution berechnet werden. Nicht alle CNN-Implementierungen verwenden vollständig verbundene Schichten 908. Zum Beispiel kann in manchen Implementierungen die Faltungsschicht 906 Ausgang für das CNN erzeugen.
  • Die Faltungsschichten sind spärlich verbunden, was sich von herkömmlicher neuraler Netzwerkkonfiguration unterscheidet, die in den vollständig verbundenen Schichten 908 vorgefunden wird. Herkömmliche neurale Netzwerkschichten sind vollständig verbunden, sodass jede Ausgangseinheit mit jeder Eingangseinheit interagiert. Die Faltungsschichten sind jedoch spärlich verbunden, da der Ausgang der Konvolution eines Feldes (anstelle des jeweiligen Zustandswerts jedes der Knoten in dem Feld) in die Knoten der folgenden Schicht eingegeben wird, wie veranschaulicht. Die Kernels, die mit den Faltungsschichten verknüpft sind, führen Konvolutionsoperationen durch, deren Ausgang zu der nächsten Schicht gesendet wird. Die Dimensionalitätsreduktion, die in den Faltungsschichten durchgeführt wird, ist ein Aspekt, der dem CNN ermöglicht, auf eine Verarbeitung großer Bilder skaliert zu werden.
  • 9B veranschaulicht beispielhafte Berechnungsstufen in einer Faltungsschicht eines CNN. Eingang zu einer Faltungsschicht 912 eines CNN kann in drei Stufen einer Faltungsschicht 914 verarbeitet werden. Die drei Stufen können eine Konvolutionsstufe 916, eine Detektorstufe 918 und eine Pooling-Stufe 920 aufweisen. Die Konvolutionsschicht 914 kann dann Daten an eine folgende Faltungsschicht ausgeben. Die letzte Faltungsschicht des Netzwerks kann Ausgangsmerkmalsabbildungsdaten ausgeben oder Eingang zu einer vollständig verbundenen Schicht bereitstellen, um zum Beispiel einen Klassifizierungswert für den Eingang zu dem CNN zu erzeugen.
  • In der Konvolutionsstufe 916 werden mehrere Konvolutionen parallel durchgeführt, um einen Satz linearer Aktivierungen zu erzeugen. Die Konvolutionsstufe 916 kann eine affine Transformation aufweisen, die jede Transformation ist, die als eine lineare Transformation plus eine Übersetzung spezifiziert werden kann. Affine Transformationen weisen Rotationen, Übersetzungen, Skalieren und Kombinationen dieser Transformationen auf. Die Konvolutionsstufe berechnet den Ausgang von Funktionen (z.B. Neuronen), die mit bestimmten Regionen in dem Eingang verbunden sind, die als die lokale Region bestimmt werden kann, die mit dem Neuron verknüpft ist. Die Neuronen berechnen ein Skalarprodukt zwischen den Gewichten der Neuronen und der Region in dem lokalen Eingang, mit dem die Neuronen verbunden sind. Der Ausgang von der Konvolutionsstufe 916 definiert einen Satz linearer Aktivierungen, die durch folgende 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 nicht lineare Aktivierungsfunktion verarbeitet. Die nicht lineare Aktivierungsfunktion erhöht die nicht linearen Eigenschaften des gesamten Netzwerks, ohne die rezeptiven Felder der Faltungsschicht zu beeinflussen. Es können mehrere Arten der nicht linearen Aktivierungsfunktionen verwendet werden. Eine bestimmte Art ist die gleichgerichtete lineare Einheit (ReLU, Rectified Linear Unit), die eine Aktivierungsfunktion verwendet, definiert als f(x) = max(0, x), sodass die Aktivierung einen Schwellenwert bei null hat.
  • Die Pooling-Stufe 920 verwendet eine Pooling-Funktion, die den Ausgang der Faltungsschicht 906 mit einer Zusammenfassungsstatistik der nahen Ausgänge ersetzt. Die Pooling-Funktion kann verwendet werden, um Übersetzungsinvarianz in das neurale Netzwerk einzuführen, sodass kleine Übersetzungen zu dem Eingang die gepoolten Ausgänge nicht verändern. Invarianz bei lokaler Übersetzung kann in Szenarien nützlich sein, in welchen die Gegenwart eines Merkmals in den Eingangsdaten wichtiger ist als die präzise Stelle des Merkmals. Verschiedene Arten von Pooling-Funktionen können während der Pooling-Stufe 920 verwendet werden, aufweisend Maximum-Pooling, Durchschnitts-Pooling und 12-Norm Pooling. Zusätzlich weisen manche CNN Implementierungen keine Pooling-Stufe auf. Stattdessen haben solche Implementierungen eine ergänzende und zusätzliche Konvolutionsstufe mit einer erhöhten Länge relativ zu den vorherigen Konvolutionsstufen.
  • Der Ausgang von 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 an die zweite Faltungsschicht 906 ausgeben, während die zweite Faltungsschicht an ein erste Schicht der vollständig verbundenen Schichten 908 ausgeben kann.
  • 10 veranschaulicht ein beispielhaftes rekurrentes neurales Netzwerk 1000. In einem rekurrenten neuralen Netzwerk (RNN) beeinflusst der vorherige Zustand des Netzwerks den Ausgang des aktuellen Zustands des Netzwerks. RNNs können auf verschiedene Weisen unter Verwendung einer Vielzahl von Funktionen errichtet werden. Die Verwendung von RNNs dreht sich im Allgemeinen um die Verwendung mathematischer Modelle, um die Zukunft basierend auf einer früheren Abfolge von Eingängen vorherzusagen. Zum Beispiel kann ein RNN verwendet werden, um statistische Sprachmodellierung durchzuführen, um ein anstehendes Wort aufgrund einer vorherigen Abfolge von Wörtern vorherzusagen. Das veranschaulichte RNN 1000 kann so beschrieben werden, dass es eine Eingangsschicht 1002, die einen Eingangsvektor empfängt, verborgene Schichten 1004 zum Implementieren einer rekurrenten Funktion, einen Feedback-Mechanismus 1005, um einen ‚Speicher‘ vorheriger Zustände zu ermöglichen, und eine Ausgangsschicht 1006 zum Ausgeben eines Ergebnisses hat. Das RNN 1000 arbeitet auf der Basis von Zeitschritten. Der Zustand des RNN zu einem bestimmten Zeitschritt wird auf der Basis des vorherigen Zeitschritts über den Feedback-Mechanismus 1005 beeinflusst. Für einen bestimmten Zeitschritt ist der Zustand der verborgenen Schichten 1004 durch den vorherigen Zustand und den Eingang zum aktuellen Zeitschritt definiert. Ein anfänglicher Eingang (x1) bei einem ersten Zeitschritt kann durch die verborgene Schicht 1004 verarbeitet werden. Ein zweiter Eingang (x2) kann durch die verborgene Schicht 1004 unter Verwendung von Zustandsinformationen verarbeitet werden, die während der Verarbeitung des anfänglichen Eingangs (x1) bestimmt werden. Ein bestimmter Zustand kann als st = f(Uxt + Wst-1) berechnet werden, wo U und W Parametermatrizen sind. Die Funktion / ist im Allgemeinen eine Nichtlinearität, wie die hyperbolische Tangentenfunktion (Tanh) oder eine Variante der Gleichrichterfunktion f(x) = max(0, x). Die bestimmte mathematische Funktion, die in den verborgenen Schichten 1004 verwendet wird, kann jedoch abhängig von den bestimmten Implementierungsdetails des RNN 1000 variieren.
  • Zusätzlich zu den beschriebenen CNN und RNN Basisnetzwerken kann Beschleunigung für Variationen an diesen Netzwerken möglich sein. Eine beispielhafte RNN Variante ist das lange kurzfristige Speicher- (LSTM, Long Short Term Memory) RNN. LSTM RNNs sind imstande, langfristige Abhängigkeiten zu lernen, die für Verarbeitung langer Sprachabfolgen notwendig sind. Eine Variante an dem CNN ist ein Convolutional Deep Belief Network, das eine ähnliche Struktur wie ein CNN hat und auf ähnliche Weise wie ein Deep Belief Network trainiert wird. Ein Deep Belief Network (DBN) ist ein generatives neurales Netzwerk, das aus mehreren Schichten stochastischer (zufälliger) Variabler besteht. DBNs können Schicht für Schicht unter Verwendung von begierigem unüberwachten Lernen trainiert werden. Die gelernten Gewichte des DBN können dann verwendet werden, um neurale Prä-Trainingsnetzwerke bereitzustellen, indem ein optimaler anfänglicher Satz von Gewichten für das neurale Netzwerk bestimmt wird. In weiteren Ausführungsformen ist Beschleunigung für verstärktes Lernen möglich. Beim verstärkten Lernen lernt ein künstlicher Agent durch Interaktion mit seiner Umgebung. Der Agent ist konfiguriert, gewisse Zielsetzungen zu optimieren, um kumulative Rewards zu maximieren.
  • 11 veranschaulicht Training und Nutzung eines tiefen neuralen Netzwerks. Sobald ein bestimmtes Netzwerk für eine Aufgabe strukturiert ist, wird das neurale Netzwerk unter Verwendung eines Trainingsdatensatzes 1102 trainiert. Verschiedene Training-Frameworks 1104 wurden entwickelt, um Hardwarebeschleunigung des Trainingsprozesses zu ermöglichen. Zum Beispiel kann das Maschinenlern-Framework 604 von 6 als ein Training-Framework 604 konfiguriert sein. Das Training-Framework 604 kann an einem untrainierten neuralen Netzwerk 1106 festhaken und dem untrainierten neuralen Netz ermöglichen, unter Verwendung der hier beschriebenen Parallelverarbeitungsressourcen trainiert zu werden, um ein trainiertes neurales Netz 1108 zu erzeugen.
  • Zum Starten des Trainingsprozesses können die anfänglichen Gewichte zufällig oder durch Prä-Training unter Verwendung eines Deep Belief Network gewählt werden. Der Trainingszyklus kann dann entweder auf überwachte oder unüberwachte Weise durchgeführt werden.
  • Überwachtes Lernen ist ein Lernverfahren, in dem Training als eine vermittelte Operation durchgeführt wird, wie wenn der Trainingsdatensatz 1102 Eingang gepaart mit dem gewünschten Ausgang für den Eingang aufweist oder wo der Trainingsdatensatz Eingang mit bekanntem Ausgang aufweist und der Ausgang des neuralen Netzwerks manuell abgestuft ist. Das Netzwerk verarbeitet die Eingänge und vergleicht die resultierenden Ausgänge mit einem Satz erwarteter oder gewünschter Ausgänge. Fehler werden dann durch das System zurück übertragen. Das Training-Framework 1104 kann einstellen, um die Gewichte einzustellen, die das untrainierte neurale Netzwerk 1106 steuern. Das Training-Framework 1104 kann Werkzeuge zum Überwachen bereitstellen, wie gut das untrainierte neurale Netzwerk 1106 zu einem Modell konvergiert, das zum Erzeugen korrekter Reaktionen basierend auf bekannten Eingangsdaten geeignet ist. Der Trainingsprozess erfolgt wiederholt, während die Gewichte des Netzwerks eingestellt werden, um den Ausgang zu verfeinern, der von dem neuralen Netzwerk erzeugt wird. Der Trainingsprozess kann fortfahren, bis das neurale Netzwerk eine statistisch gewünschte Genauigkeit erreicht, die mit einem trainierten neuralen Netz 1108 verknüpft ist. Das trainierte neurale Netzwerk 1108 kann dann eingesetzt werden, um eine beliebige Anzahl von Maschinenlernoperationen zu implementieren, um ein Schlussfolgerungsergebnis 1114 basierend auf Eingabe neuer Daten 1112 zu erzeugen.
  • Unüberwachtes Lernen ist ein Lernverfahren, in dem das Netzwerk versucht, sich selbst unter Verwendung unmarkierter Daten zu trainieren. Daher weist für unüberwachtes Lernen der Trainingsdatensatz 1102 Eingangsdaten ohne zugehörige Ausgangsdaten auf. Das untrainierte neurale Netzwerk 1106 kann Gruppierungen in dem unmarkierten Eingang lernen und kann bestimmen, wie einzelne Eingänge mit dem gesamten Datensatz zusammenhängen. Unüberwachtes Training kann verwendet werden, um eine Selbstorganisierungskarte zu erstellen, die eine Art von trainiertem neuralen Netzwerk 1108 ist, das imstande ist, Operationen durchzuführen, die beim Verringern der Dimensionalität von Daten nützlich sind. Unüberwachtes Training kann auch zum Durchführen einer Anomaliedetektion verwendet werden, die die Identifizierung von Datenpunkten in einem Eingangsdatensatz ermöglicht, die von den normalen Mustern der Daten abweichen.
  • Variationen beim überwachten und unüberwachten Training können auch benutzt werden. Semi-überwachtes Lernen ist eine Technik, in der der Trainingsdatensatz 1102 eine Mischung aus markierten und unmarkierten Daten derselben Verteilung aufweist. Inkrementelles Lernen ist eine Variante von überwachtem Lernen, bei der Eingangsdaten kontinuierlich verwendet werden, um das Modell weiter zu trainieren. Inkrementelles Lernen ermöglicht dem trainierten neuralen Netzwerk 1108, sich an die neuen Daten 1112 anzupassen, ohne das Wissen zu vergessen, das in das Netzwerk während des anfänglichen Trainings eingebracht wird.
  • Ob überwacht oder unüberwacht, der Trainingsprozess für besonders tiefe neurale Netzwerke kann zu rechenintensiv für einen einzelnen Rechenknoten sein. Stattdessen kann bei Verwendung eines einzelnen Rechenknotens ein verteiltes Netzwerk von Berechnungsknoten verwendet werden, um den Trainingsprozess zu beschleunigen.
  • 12A ist ein Blockdiagramm, das verteiltes Lernen zeigt. Verteiltes Lernen ist ein Trainingsmodell, das mehrere verteilte Berechnungsknoten aufweist, um überwachtes oder unüberwachtes Training eines neuralen Netzwerks durchzuführen. Die verteilten Berechnungsknoten können jeweils einen oder mehrere Host-Prozessoren und einen oder mehrere der Allzweckverarbeitungsknoten, wie die hoch parallele Allzweckgrafikverarbeitungseinheit 700 wie in 7, aufweisen. Wie veranschaulicht, kann verteiltes Lernen mit Modellparallelismus 1202, Datenparallelismus 1204 oder einer Kombination von Modell- und Datenparallelismus 1206 durchgeführt werden.
  • Im Modellparallelismus 1202 können verschiedenen Berechnungsknoten in einem verteilten System Trainingsberechnungen für verschiedenen Teile eines einzelnen Netzwerks durchführen. Zum Beispiel kann jede Schicht eines neuralen Netzwerks durch einen anderen Verarbeitungsknoten des verteilten Systems trainiert werden. Die Vorteile von Modellparallelismus weisen die Fähigkeit auf, auf besonders große Modelle zu skalieren. Teilen der Berechnungen, die mit verschiedenen Schichten des neuralen Netzwerks verknüpft sind, ermöglicht das Training sehr großer neuraler Netzwerke, in welchen die Gewichte aller Schichten nicht in den Speicher eines einzelnen Berechnungsknotens passen würden. In manchen Fällen kann Modellparallelismus beim Durchführen eines unüberwachten Trainings großer neuraler Netzwerke besonders nützlich sein.
  • Im Datenparallelismus 1204 haben die verschiedenen Knoten des verteilten Netzwerks ein vollständiges Exemplar des Modells und jeder Knoten empfängt einen anderen Teil der Daten. Die Ergebnisse aus den verschiedenen Knoten werden dann kombiniert. Während verschiedene Ansätze für Datenparallelismus möglich sind, erfordern datenparallele Trainingsansätze alle eine Technik zum Kombinieren von Ergebnissen und Synchronisieren der Modellparameter zwischen jedem Knoten. Beispielhafte Ansätze zum Kombinieren von Daten weisen Parameterdurchschnittsbildung und Datenparallelismus basierend auf Aktualisierung auf. Parameterdurchschnittsbildung trainiert jeden Knoten an einem Teilsatz der Trainingsdaten und Sätzen der globalen Parameter (z.B. Gewichte, Biases) auf den Durchschnitt der Parameter von jedem Knoten. Parameterdurchschnittsbildung verwendet einen zentralen Parameterserver, der die Parameterdaten hält. Auf Aktualisierung basierter Datenparallelismus ist Parameterdurchschnittsbildung ähnlich, außer, dass anstelle einer Übertragung von Parametern von dem Knoten zu dem Parameterserver die Aktualisierungen zu dem Modell übertragen werden. Zusätzlich kann auf Aktualisierung basierter Datenparallelismus auf dezentralisierte Weise durchgeführt werden, wo die Aktualisierungen komprimiert sind und zwischen Knoten übertragen werden.
  • Kombinierter Modell- und Datenparallelismus 1206 kann zum Beispiel in einem verteilten System implementiert werden, in dem jeder Berechnungsknoten mehrere GPUs aufweist. Jeder Knoten kann ein vollständiges Exemplar des Modells haben, wobei separate GPUs in jedem Knoten zum Trainieren verschiedener Teile des Modells verwendet werden.
  • Verteiltes Training hat erhöhten Mehraufwand relativ zu Training an einer einzelnen Maschine. Die hier beschriebenen parallelen Prozessoren und GPGPUs können jedoch verschiedene Techniken implementieren, um den Mehraufwand eines verteilten Trainings zu verringern, aufweisend Techniken, die GPU-zu-GPU Datentransfer hoher Bandbreite und beschleunigte ferne Datensynchronisation ermöglichen.
  • 12B ist ein Blockdiagramm, das eine programmierbare Netzwerkschnittstelle 1210 und Datenverarbeitungseinheit veranschaulicht. Die programmierbare Netzwerkschnittstelle 1210 ist eine programmierbare Netzwerk-Engine, die verwendet werden kann, um Netzwerk-basierte Rechenaufgaben in einer verteilten Umgebung zu beschleunigen. Die programmierbar Netzwerkschnittstelle 1210 kann mit einem Host-System über Host-Schnittstelle 1270 gekoppelt sein. Die programmierbare Netzwerkschnittstelle 1210 kann verwendet werden, um Netzwerk- oder Datenspeicheroperationen für CPUs oder GPUs des Host-Systems zu beschleunigen. Das Host-System kann zum Beispiel ein Knoten eines verteilten Lernsystems sein, das zum Durchführen eines verteilten Trainings verwendet wird, wie zum Beispiel in 12A dargestellt. Das Host-System kann auch ein Datenzentrumsknoten in einem Datenzentrum sein.
  • In einer Ausführungsform kann Zugriff auf einen fernen Datenspeicher, der Modelldaten beinhaltet, durch die programmierbare Netzwerkschnittstelle 1210 beschleunigt werden. Zum Beispiel kann die programmierbare Netzwerkschnittstelle 1210 konfiguriert sein, ferne Datenspeichervorrichtungen dem Host-System als lokale Datenspeichervorrichtungen zu präsentieren. Die programmierbare Netzwerkschnittstelle 1210 kann auch ferne direkte Speicherzugriffs- (RDMA) Operationen beschleunigen, die zwischen GPUs des Host-Systems mit GPUs von fernen Systemen durchgeführt werden. In einer Ausführungsform kann die programmierbare Netzwerkschnittstelle 1210 Datenspeicherfunktionalität ermöglichen wie, ohne aber darauf beschränkt zu sein, NVME-oF. Die programmierbare Netzwerkschnittstelle 1210 kann auch Verschlüsselung, Datenintegrität, Kompression und andere Operationen für ferne Datenspeicher seitens des Host-Systems beschleunigen, wodurch es fernem Datenspeicher möglich ist, sich den Latenzen von Datenspeichervorrichtungen zu nähern, die direkt an dem Host-System angehängt sind.
  • Die programmierbare Netzwerkschnittstelle 1210 kann auch Ressourcenzuordnung und Verwaltung seitens des Host-Systems durchführen. Datenspeichersicherheitsoperationen können auf die programmierbare Netzwerkschnittstelle 1210 abgeladen und in Übereinstimmung mit der Zuordnung und Verwaltung ferner Datenspeicherressourcen durchgeführt werden. Netzwerk-basierte Operationen zum Verwalten von Zugriff auf den fernen Datenspeicher, die sonst von einem Prozessor des Host-Systems durchgeführt werden, können stattdessen von der programmierbaren Netzwerkschnittstelle 1210 durchgeführt werden.
  • In einer Ausführungsform können Netzwerk- und/oder Datensicherheitsoperationen von dem Host-System zu der programmierbaren Netzwerkschnittstelle 1210 abgeladen werden. Datenzentrumsicherheitsrichtlinien für einen Datenzentrumsknoten können durch die programmierbare Netzwerkschnittstelle 1210 anstelle der Prozessoren des Host-Systems gehandhabt werden. Zum Beispiel kann die programmierbare Netzwerkschnittstelle 1210 einen versuchten Netzwerk-basierten Angriff (z.B. DDoS) auf dem Host-System erfassen und dagegen vorgehen, wodurch verhindert wird, dass der Angriff die Verfügbarkeit des Host-Systems beeinträchtigt.
  • Die programmierbare Netzwerkschnittstelle 1210 kann ein System auf einem Chip (SoC 1220) aufweisen, das ein Betriebssystem über mehrere Prozessorkerne 1222 ausführt. Die Prozessorkerne 1222 können Allzweckprozessor- (z.B. CPU) Kerne aufweisen. In einer Ausführungsform können die Prozessorkerne 1222 auch einen oder mehrere GPU Kerne aufweisen. Das SoC 1220 kann Befehle ausführen, die in einer Speichervorrichtung 1240 gespeichert sind. Eine Datenspeichervorrichtung 1250 kann lokale Betriebssystemdaten speichern. Die Datenspeichervorrichtung 1250 und Speichervorrichtung 1240 können auch zum Zwischenspeichern ferner Daten für das Host-System verwendet werden. Netzwerkanschlüsse 1260A-1260B ermöglichen eine Verbindung zu einem Netzwerk oder Fabric und erleichtern Netzwerkzugriff für das SoC 1220 und, über die Host-Schnittstelle 1270, für das Host-System. Die programmierbare Netzwerkschnittstelle 1210 kann auch eine I/O Schnittstelle 1275, wie eine USB-Schnittstelle, aufweisen. Die I/O Schnittstelle 1275 kann verwendet werden, um externe Vorrichtungen an die programmierbare Netzwerkschnittstelle 1210 zu koppeln, oder als Störungsbehebungsschnittstelle. Die programmierbare Netzwerkschnittstelle 1210 weist auch eine Verwaltungsschnittstelle 1230 auf, die ermöglicht, dass Software auf der Host Vorrichtung die programmierbare Netzwerkschnittstelle 1210 und/oder das SoC 1220 verwaltet und konfiguriert. In einer Ausführungsform kann die programmierbare Netzwerkschnittstelle 1210 auch eine(n) oder mehrere Beschleuniger oder GPUs 1245 aufweisen, um Abladen paralleler Rechenaufgaben von dem SoC 1220, Host-System oder fernen Systemen, die über die Netzwerkanschlüsse 1260A-1260B gekoppelt sind, zu akzeptieren.
  • Beispielhafte Maschinenlernanwendungen
  • Maschinenlernen kann angewendet werden, um eine Reihe von technologischen Problemen zu lösen, aufweisend, ohne aber darauf beschränkt zu sein, Computer Vision, autonomes Lenken und Navigation, Spracherkennung und Sprachenverarbeitung. Computer Vision ist traditionell eines der aktivsten Forschungsgebiete für Maschinenlernanwendungen. Anwendungen von Computer Vision reichen von Reproduzieren von Sehfähigkeiten eines Menschen, wie Erkennen von Gesichtern, bis zum Erstellen neuer Kategorien von Sehfähigkeiten. Zum Beispiel können Computer Visionsanwendungen konfiguriert sein, Schallwellen aus den Vibrationen zu erkennen, die von Objekten herbeigeführt werden, die in einem Video sichtbar sind. Durch parallele Prozessoren beschleunigtes Maschinenlernen ermöglicht, dass Computer Visionsanwendungen unter Verwendung eines signifikant größeren Trainingsdatensatzes trainiert werden als zuvor machbar war, und ermöglicht den Einsatz von Schlussfolgerungssystemen unter Verwendung von leistungsarmen parallelen Prozessoren.
  • Durch parallele Prozessoren beschleunigtes Maschinenlernen hat autonome Fahranwendungen, aufweisend Spur- und Verkehrszeichenerkennung, Hindernisvermeidung, Navigation und Fahrsteuerung. Beschleunigte Maschinenlerntechniken können verwendet werden, um Fahrmodelle basierend auf Datensätzen zu trainieren, die die richtigen Reaktionen auf einen bestimmten Trainingseingang definieren. Die hier beschriebenen parallelen Prozessoren können rasches Training der zunehmend komplexen neuralen Netzwerke ermöglichen, die für autonome Fahrlösungen verwendet werden, und ermöglichen die Nutzung von Schlussfolgerungsprozessoren geringer Leistung in einer mobilen Plattform, die zur Integration in autonome Fahrzeuge geeignet sind.
  • Durch parallele Prozessoren beschleunigte tiefe neurale Netzwerke haben Maschinenlernansätze zur automatischen Spracherkennung (ASR) ermöglicht. ASR weist die Erstellung einer Funktion auf, die die wahrscheinlichste linguistische Abfolge aufgrund einer eingegebenen akustischen Abfolge berechnet. Beschleunigtes Maschinenlernen unter Verwendung tiefer neuraler Netzwerke hat den Ersatz der verborgenen Markov Modelle (HMMs) und Gaußschen Mischungsmodelle (GMMs) ermöglicht, die zuvor für ASR verwendet wurden.
  • Durch parallele Prozessoren beschleunigtes Maschinenlernen kann auch zum Beschleunigen von Verarbeitung natürlicher Sprache verwendet werden. Automatische Lernprozeduren können statistische Schlussfolgerungsalgorithmen nutzen, um Modelle zu erzeugen, die gegenüber fehlerhaftem oder unvertrautem Eingang robust sind. Beispielhafte Prozessoranwendungen bei natürlicher Sprache weisen automatische Maschinenübersetzung zwischen menschlichen Sprachen auf.
  • Die Parallelverarbeitungsplattformen, die zum Maschinenlernen verwendet werden, können in Trainingsplattformen und Nutzungsplattformen unterteilt werden. Trainingsplattformen sind im Allgemeinen hoch parallel und weisen Optimierungen auf, um Multi-GPU-Einzelknoten-Training und Multi-Knoten, Multi-GPU-Training zu beschleunigen. Beispielhafte parallele Prozessoren, die für Training geeignet sind, weisen die Allzweckgrafikverarbeitungseinheit 700 von 7 und das Multi-GPU-Rechensystem 800 von 8 auf. Im Gegensatz dazu weisen eingesetzte Maschinenlernplattformen im Allgemeinen leistungsärmere parallele Prozessoren auf, die zur Verwendung in Produkten wie Kameras, autonomen Robotern und autonomen Fahrzeugen geeignet sind.
  • Zusätzlich können Maschinenlerntechniken angewendet werden, um Grafikverarbeitungsaktivitäten zu beschleunigen oder zu verstärken. Zum Beispiel kann ein Maschinenlernmodell trainiert werden, um Ausgang zu erkennen, der durch eine GPU-beschleunigte Anwendung erzeugt wird, und eine aufwärtsskalierte Version dieses Ausgangs erzeugen. Solche Techniken können angewendet werden, um die Erzeugung von Hochauflösungsbildern für eine Spieleanwendung zu beschleunigen. Verschiedene andere Grafik-Pipeline-Aktivitäten können von der Verwendung von Maschinenlernen profitieren. Zum Beispiel können Maschinenlernmodelle trainiert werden, Tessellationsoperationen an Geometriedaten durchzuführen, um die Komplexität geometrischer Modelle zu erhöhen, zu ermöglichen, dass fein detaillierte Geometrie automatisch aus Geometrie relativ weniger Details erzeugt wird.
  • 13 veranschaulicht ein beispielhaftes Schlussfolgerungssystem auf einem Chip (SOC) 1300, das zum Durchführen von Schlussfolgerung unter Verwendung eines trainierten Modells geeignet ist. Das SOC 1300 kann Verarbeitungskomponenten integrieren, aufweisend einen Medienprozessor 1302, einen Vision-Prozessor 1304, eine GPGPU 1306 und einen Mehrfachkernprozessor 1308. Die GPGPU 1306 kann eine GPGPU wie hier beschrieben sein, wie die GPGPU 700, und der Mehrfachkernprozessor 1308 kann ein hier beschriebener Mehrfachkernprozessor sein, wie die Mehrfachkernprozessoren 405-406. Das SOC 1300 kann zusätzlich On-Chip-Speicher 1305 enthalten, der einen geteilten On-Chip-Datenpool ermöglichen kann, der für jede der Verarbeitungskomponenten zugänglich ist. Die Verarbeitungskomponenten können für leistungsarmen Betrieb optimiert sein, um Nutzung für eine Reihe von Maschinenlernplattformen zu ermöglichen, aufweisend autonome Fahrzeuge und autonome Roboter. Zum Beispiel kann eine Implementierung des SOC 1300 als ein Teil des Hauptsteuersystems für ein autonomes Fahrzeug verwendet werden. Wenn das SOC 1300 zur Verwendung in autonomen Fahrzeugen konfiguriert ist, ist das SOC so gestaltet und konfiguriert, dass es den relevanten Funktionssicherheitsstandards der Nutzungsrechtsprechung entspricht.
  • Während des Betriebs können der Medienprozessor 1302 und Vision-Prozessor 1304 zusammenarbeiten, um Computer Vision-Operationen zu beschleunigen. Der Medienprozessor 1302 kann Decodieren mit niedriger Latenz von mehreren hochauflösenden (z.B. 4K, 8K) Videostreams ermöglichen. Die decodierten Videostreams können in einen Puffer in dem On-Chip-Speicher 1305 geschrieben werden. Der Vision-Prozessor 1304 kann dann das decodierte Video analysieren und vorläufige Verarbeitungsoperationen an den Frames des decodierten Videos in Vorbereitung einer Verarbeitung der Frames unter Verwendung eines trainierten Bilderkennungsmodells durchführen. Zum Beispiel kann der Vision-Prozessor 1304 Konvolutionsoperationen für ein CNN beschleunigen, das verwendet wird, um Bilderkennung an den hochauflösenden Videodaten durchzuführen, während Backend-Modellberechnungen durch die GPGPU 1306 durchgeführt werden.
  • Der Mehrfachkernprozessor 1308 kann Steuerlogik aufweisen, die Sequenzierung und Synchronisation von Datentransfers und geteilte Speicheroperationen unterstützt, die durch den Medienprozessor 1302 und den Vision-Prozessor 1304 durchgeführt werden. Der Mehrfachkernprozessor 1308 kann auch als ein Anwendungsprozessor dienen, um Softwareanwendungen auszuführen, die die Schlussfolgerungsrechenkapazität der GPGPU 1306 nutzen können. Zum Beispiel kann mindestens ein Teil der Navigations- und Fahrlogik in Software implementiert sein, die auf dem Mehrfachkernprozessor 1308 läuft. Solche Software kann direkt Berechnungsarbeitslasten an die GPGPU 1306 ausgeben oder die Berechnungsarbeitslasten können an den Mehrfachkernprozessor 1308 ausgegeben werden, der mindestens einen Teil dieser Operationen an die GPGPU 1306 abladen kann.
  • Die GPGPU 1306 kann Rechen-Cluster wie eine leistungsarme Konfiguration der Verarbeitungsclusters 706A-706H in der Allzweckgrafikverarbeitungseinheit 700 aufweisen. Die Rechen-Cluster in der GPGPU 1306 können Befehle unterstützen, die besonders optimiert sind, um Schlussfolgerungsberechnungen an einem trainierten neuralen Netzwerk durchzuführen. Zum Beispiel kann die GPGPU 1306 Befehle unterstützen, um Berechnungen geringer Präzision, wie 8-Bit und 4-Bit ganzzahlige Vektoroperationen durchzuführen.
  • Zusätzlicher Systemüberblick
  • 14 ist ein Blockdiagramm eines Verarbeitungssystems 1400. Die Elemente von 14 mit denselben oder ähnlichen Bezeichnungen wie die Elemente einer beliebigen anderen Figur hierin, beschreiben dieselben Elemente wie in den anderen Figuren, können auf ähnliche Weise wie diese arbeiten oder funktionieren, können dieselben Komponenten aufweisen und können mit anderen Einheiten, wie jenen, die hier an anderer Stelle beschrieben sind, verbunden sein, sind aber als solche nicht eingeschränkt. System 1400 kann in einem einzelnen Prozessor-Desktopsystem, einem Multi-Prozessor-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 in einer integrierten Schaltung eines Systemauf-einem-Chip (SoC) eingegliedert ist, zur Verwendung in mobilen, handgehaltenen oder eingebetteten Vorrichtungen wie in Internet der Dinge- (IoT) Vorrichtungen mit kabelgebundener oder drahtloser Konnektivität zu einem lokalen oder Weitverkehrsnetzwerk.
  • Das System 1400 kann ein Verarbeitungssystem mit Komponenten sein, die jenen von 1 entsprechen. Zum Beispiel können in verschiedenen Konfigurationen Prozessor(en) 1402 oder Prozessorkern(e) 1407 Prozessor(en) 102 von 1 entsprechen. Grafik Prozessor(en) 1408 können parallelen Prozessor(en) 112 von 1 entsprechen. Externer Grafikprozessor 1418 kann einer der Zusatzvorrichtung(en) 120 von 1 sein.
  • Das System 1400 kann aufweisen: eine Server-basierte Spieleplattform; eine Spielekonsole, aufweisend eine Spiel- und Medienkonsole; eine mobile Spielkonsole, eine handgehaltene Spielkonsole oder eine Online-Spielkonsole, mit diesen gekoppelt oder integriert sein. Das System 1400 kann Teil eines Mobiltelefons, Smartphones, einer Tablet-Rechenvorrichtung oder mobilen Internet-angeschlossenen Vorrichtung wie eines Laptops mit niedriger interner Datenspeicherkapazität sein. Verarbeitungssystem 1400 kann auch aufweisen: eine am Körper tragbare Vorrichtung, wie eine am Körper tragbare Smartwatch-Vorrichtung; smarte Brillen oder smarte Kleidung, verstärkt mit erweiterten Realitäts- (AR) oder virtuellen Realitäts- (VR) Merkmalen, um visuelle, auditive oder taktile Ausgänge bereitzustellen, um visuelle, auditive oder taktile Erfahrungen in der realen Welt zu ergänzen, oder auf andere Weise Text, Audio, Grafik, Video, holographische Bilder oder Video oder taktiles Feedback bereitzustellen; eine andere erweiterte Realitäts- (AR) Vorrichtung; oder eine andere virtuelle Realitäts- (VR) Vorrichtung, mit diesen gekoppelt oder integriert sein. Das Verarbeitungssystem 1400 kann ein Fernsehgerät oder eine Set Top Box-Vorrichtung aufweisen oder Teil derselben sein. Das System 1400 kann ein selbstfahrendes Fahrzeug wie einen Bus, einen Traktoranhänger, ein Auto, Motorrad oder Elektrofahrrad, einen Flugzeug oder Gleiter (oder einer Kombination davon) aufweisen, mit diesem gekoppelt oder integriert sein. Das selbstfahrende Fahrzeug kann System 1400 verwenden, um die Umgebung zu verarbeiten, die rund um das Fahrzeug erfasst wird.
  • Der eine oder die mehreren Prozessoren 1402 können einen oder mehrere Prozessorkerne 1407 aufweisen, um Befehle zu verarbeiten, die, wenn ausgeführt, Operationen für System- oder Anwendersoftware durchführen. Der mindestens eine des einen oder der mehreren Prozessorkerne 1407 kann konfiguriert sein, einen bestimmten Befehlssatz 1409 zu verarbeiten. Der Befehlssatz 1409 kann Berechnung mit komplexem Befehlssatz (CISC, Complex Instruction Set Computing), Berechnung mit reduziertem Befehlssatz (RISC, Reduced Instruction Set Computing) oder Berechnung über ein sehr langes Befehlswort (VLIW, Very Long Instruction Word) erleichtern. Ein oder mehrere Prozessorkerne 1407 können einen unterschiedlichen Befehlssatz 1409 verarbeiten, der Befehle aufweisen kann, um Emulation anderer Befehlssätze zu erleichtern. Prozessorkern 1407 kann auch andere Verarbeitungsvorrichtungen aufweisen, wie einen Digitalsignalprozessor (DSP).
  • Der Prozessor 1402 kann Cache-Speicher 1404 aufweisen. Abhängig von der Architektur kann der Prozessor 1402 einen einzelnen internen Cache oder mehrere Ebenen eines internen Cache aufweisen. In manchen Ausführungsformen ist der Cache-Speicher unter verschiedenen Komponenten des Prozessors 1402 geteilt. In manchen Ausführungsformen verwendet der Prozessor 1402 auch einen externen Cache (z.B. einen Ebene-3 (L3) Cache oder Cache letzter Ebene (LLC)) (nicht dargestellt), den sich Prozessorkerne 1407 unter Verwendung bekannter Zwischenspeicherungskohärenztechniken teilen können. Eine Registerdatei 1406 kann zusätzlich in Prozessor 1402 enthalten sein und kann verschiedene Arten von Registern zum Speichern verschiedener Arten von Daten (z.B. Ganzzahlregister, Gleitkommaregister, Statusregister und ein Befehlszeigerregister) aufweisen. Manche Register können Allzweckregister sein, während andere Register für das Design des Prozessors 1402 spezifisch sein können.
  • Der eine oder die mehreren Prozessor(en) 1402 können mit einem oder mehreren Schnittstellenbus(sen) 1410 gekoppelt sein, um Kommunikationssignale wie Adressen-, Daten- oder Steuersignale zwischen Prozessor 1402 und anderen Komponenten in dem System 1400 zu übertragen. Der Schnittstellenbus 1410 kann in einer dieser Ausführungsformen ein Prozessorbus, wie eine Version des Direct Media Interface (DMI) Busses sein. 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 anderen Arten von Schnittstellenbussen aufweisen. Zum Beispiel kann (können) der (die) Prozessor(en) 1402 eine integrierte Speichersteuerung 1416 und einen Plattformsteuerungs-Hub 1430 aufweisen. Die Speichersteuerung 1416 erleichtert Kommunikation zwischen einer Speichervorrichtung und anderen Komponenten des Systems 1400, während der Plattformsteuerungs-Hub (PCH) 1430 Verbindungen zu I/O-Vorrichtungen über einen lokalen I/O-Bus bereitstellt.
  • Die Speichervorrichtung 1420 kann eine dynamische Direktzugriffsspeicher-(DRAM) Vorrichtung, eine statische Direktzugriffsspeicher- (SRAM) Vorrichtung, Flash-Speichervorrichtung, Phasenänderungsspeichervorrichtung oder manche andere Speichervorrichtung mit geeigneter Arbeitsleistung sein, um als Prozessspeicher zu dienen. Die Speichervorrichtung 1420 kann zum Beispiel als Systemspeicher für das System 1400 arbeiten, um Daten 1422 und Befehle 1421 zur Verwendung zu speichern, wenn der eine oder die mehreren Prozessoren 1402 eine Anwendung oder einen Prozess ausführen. Speichersteuerung 1416 ist auch mit einem optionalen externen Grafikprozessor 1418 gekoppelt, der mit dem einen oder den mehreren Grafikprozessoren 1408 in Prozessoren 1402 kommunizieren kann, um Grafik- und Medienoperationen durchzuführen. In manchen Ausführungsformen können Grafik-, Medien- und oder Rechenoperationen durch einen Beschleuniger 1412 unterstützt werden, der ein Co-Prozessor ist, der konfiguriert sein kann, einen spezialisierten Satz von Grafik-, Medien- oder Rechenoperationen durchzuführen. Zum Beispiel kann der Beschleuniger 1412 ein Matrixmultiplikationsbeschleuniger sein, der verwendet wird, um Maschinenlern- oder Rechenoperationen durchzuführen. Der Beschleuniger 1412 kann ein Strahlverfolgungsbeschleuniger sein, der verwendet werden kann, um Strahlverfolgungsoperationen gemeinsam mit dem Grafikprozessor 1408 durchzuführen. In einer Ausführungsform kann ein externer Beschleuniger 1419 anstelle von oder gemeinsam mit dem Beschleuniger 1412 verwendet werden.
  • Eine Anzeigevorrichtung 1411 kann bereitgestellt sein, die mit dem (den) Prozessor(en) 1402 verbunden werden kann. Die Anzeigevorrichtung 1411 kann eine oder mehrere von einer internen Anzeigevorrichtung, wie in einer mobilen elektronischen Vorrichtung oder einer Laptop-Vorrichtung, oder einer externen Anzeigevorrichtung, die über eine Anzeigeschnittstelle (z.B. DisplayPort usw.) angehängt ist, sein. Die Anzeigevorrichtung 1411 kann eine am Kopf befestigte Anzeige (HMD, Head Mounted Display) sein, wie eine stereoskopische Anzeigevorrichtung zur Verwendung in virtuellen Realitäts- (VR) Anwendungen oder erweiterten Realitäts- (AR) Anwendungen.
  • Der Plattformsteuerungs-Hub 1430 kann peripheren Geräten ermöglichen, sich mit Speichervorrichtung 1420 und Prozessor 1402 über einen Hochgeschwindigkeits-I/O-Bus zu verbinden. Die peripheren I/O-Geräte weisen eine Audiosteuerung 1446, eine Netzwerksteuerung 1434, eine Firmware-Schnittstelle 1428, einen drahtlosen Sendeempfänger 1426, Berührungssensoren 1425, eine Datenspeichervorrichtung 1424 (z.B. nicht flüchtiger Speicher, flüchtiger Speicher, Festplattenlaufwerk, Flash-Speicher, NAND, 3D NAND, 3D XPoint/Optane usw.) auf, ohne aber darauf beschränkt zu sein. Die Datenspeichervorrichtung 1424 kann über eine Datenspeicherschnittstelle (z.B. SATA) oder über einen peripheren Bus, wie einen Peripheral Component Interconnect-Bus (z.B. PCI, PCI Express) verbunden sein. Die Berührungssensoren 1425 können Berührungsbildschirmsensoren, Drucksensoren oder Fingerabdrucksensoren aufweisen. Der drahtlose Sendeempfänger 1426 kann ein Wi-Fi-Sendeempfänger, ein Bluetooth-Sendeempfänger oder ein Mobilnetzwerk-Sendeempfänger wie ein 3G, 4G, 5G oder Long-Term Evolution (LTE) Sendeempfänger sein. Die Firmwareschnittstelle 1428 ermöglicht Kommunikation mit Systemfirmware und kann zum Beispiel eine vereinheitlichte erweiterbare Firmwareschnittstelle (UEFI, Unified Extensible Firmware Interface) sein. Die Netzwerksteuerung 1434 kann eine Netzwerkverbindung zu einem kabelgebundenen Netzwerk ermöglichen. In manchen Ausführungsformen ist eine Netzwerksteuerung hoher Arbeitsleistung (nicht dargestellt) mit dem Schnittstellenbus 1410 gekoppelt. Die Audiosteuerung 1446 kann eine Mehrfachkanal- Hochdefinitions-Audiosteuerung sein. In manchen dieser Ausführungsformen weist das System 1400 eine optionale alte I/O-Steuerung 1440 zur Kopplung alter (z.B. Personal System 2 (PS/2)) Vorrichtungen an das System auf. Der Plattformsteuerungs-Hub 1430 kann auch mit einer oder mehreren Universal Serial Bus (USB) Steuerungen 1442 verbundenen Eingabevorrichtungen verbunden sein, wie Tastatur- und Maus- 1443 Kombinationen, eine Kamera 1444 oder andere USB-Eingabevorrichtungen.
  • Es ist klar, dass das dargestellte System 1400 beispielhaft und nicht einschränkend ist, da andere Arten von Datenverarbeitungssystemen, die anders konfiguriert sind, auch verwendet werden können. Zum Beispiel können ein Exemplar der Speichersteuerung 1416 und der Plattformsteuerung-Hub 1430 in einen einzelnen externen Grafikprozessor, wie den externen Grafikprozessor 1418 integriert sein. Der Plattformsteuerungs-Hub 1430 und/oder die Speichersteuerung 1416 können extern zu dem einen oder den mehreren Prozessor(en) 1402 sein. Zum Beispiel kann das System 1400 eine externe Speichersteuerung 1416 und einen Plattformsteuerungs-Hub 1430 aufweisen, die als ein Speichersteuerungs-Hub und peripherer Steuerungs-Hub in einem System-Chipset konfiguriert sein können, das mit dem (den) Prozessor(en) 1402 in Kommunikation ist.
  • Zum Beispiel können Leiterplatten („Sleds“) verwendet werden, auf welchen Komponenten wie CPUs, Speicher und andere Komponenten platziert sind, die für eine erhöhte thermische Leistung entworfen sind. Verarbeitungskomponenten wie die Prozessoren können sich an einer oberen Seite eines Sleds befinden, während nahe Speicher, wie DIMMs, sich an einer unteren Seite des Sleds befinden. Infolge des verstärkten Luftstroms, der durch dieses Design bereitgestellt ist, können die Komponenten bei höheren Frequenzen und Leistungspegeln arbeiten als in typischen Systemen, wodurch Arbeitsleistung erhöht wird. Ferner sind die Sleds konfiguriert, blind mit Leistungs- und Datenkommunikationskabeln in einem Rack zusammenzupassen, wodurch ihre Fähigkeit verbessert wird, rasch entfernt, aktualisiert und wieder eingebaut und/oder ersetzt zu werden. Ähnlich sind einzelne Komponenten, die sich auf den Sleds befinden, wie Prozessoren, Beschleuniger, Speicher und Datenspeicherlaufwerke, konfiguriert, leicht aufgrund ihres erhöhten Abstands zueinander aktualisiert zu werden. In der veranschaulichenden Ausführungsform weisen die Komponenten zusätzlich Hardware-Bestätigungsmerkmale auf, um ihre Authentizität zu beweisen.
  • Ein Datenzentrum kann eine einzelne Netzwerkarchitektur („Fabric“) benutzen, die mehrere andere Netzwerkarchitekturen unterstützt, enthaltend Ethernet und Omni-Path. Die Sleds können über optische Fasern, die höhere Bandbreite und niedrigere Latenz als typische paarweise verdrillte Kabel bereitstellen (z.B. Kategorie 5, Kategorie 5e, Kategorie 6 usw.) an Schalter gekoppelt sein. Aufgrund der Zwischenverbindungen und Netzwerkarchitektur hoher Bandbreite, niedriger Latenz kann das Datenzentrum in Verwendung Ressourcen poolen, wie Speicher, Beschleuniger (z.B. GPUs, Grafikbeschleuniger, FPGAs, ASICs, neurale Netzwerk- und/oder künstliche Intelligenzbeschleuniger usw.) und Datenspeicherlaufwerke, die physisch getrennt sind, und ihnen Rechenressourcen (z.B. Prozessoren) auf einer Bedarfsbasis bereitstellen, wobei es den Rechenressourcen möglich ist, auf gepoolte Ressourcen zuzugreifen als wären sie lokal.
  • Eine Leistungsversorgung oder -quelle kann dem System 1400 oder einer beliebigen Komponente oder einen beliebigen System, wie hier beschrieben, Spannung und/oder Strom bereitstellen. In einem Beispiel weist die Leistungsversorgung einen AC/DC- (Wechselstrom/Gleichstrom) Adapter auf, der in eine Wandsteckdose gesteckt wird. Solche AC-Leistung kann eine Leistungsquelle emeuerbarer Energie (z.B. Sonnenenergie) sein. In einem Beispiel weist die Leistungsquelle eine DC Leistungsquelle wie einen externen AC/DC-Wandler auf. Eine Leistungsquelle oder Leistungsversorgung kann auch drahtlose Lade-Hardware aufweisen, um über Nähe zu einem Ladungsfeld zu laden. Die Leistungsquelle kann eine interne Batterie, Wechselstromversorgung, bewegungsbasierte Leistungsversorgung, Sonnenenergieversorgung oder eine Brennstoffzellenquelle aufweisen.
  • 15A-15C veranschaulichen Rechensysteme und Grafikprozessoren. Die Elemente von 15A-15C mit denselben oder ähnlichen Bezeichnungen wie die Elemente einer beliebigen anderen Figur hierin, beschreiben dieselben Elemente wie in den anderen Figuren, können auf ähnliche Weise wie diese arbeiten oder funktionieren, können dieselben Komponenten aufweisen und können mit anderen Einheiten, wie jenen, die hier an anderer Stelle beschrieben sind, verbunden sein, sind aber als solche nicht eingeschränkt.
  • 15A ist ein Blockdiagramm eines Prozessors 1500, der eine Variante eines der Prozessoren 1402 sein kann und anstatt einem von diesen verwendet werden kann. Daher offenbart die Offenbarung beliebiger Merkmale in Kombination mit dem Prozessor 1500 hierin auch eine entsprechende Kombination mit dem (den) Prozessor(en) 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 haben. Wo ein integrierter Grafikprozessor 1508 ausgeschlossen ist, weist das System, das den Prozessor aufweist, eine Grafikprozessorvorrichtung in einem System-Chipset oder gekoppelt über einen Systembus auf Prozessor 1500 kann zusätzliche Kerne bis zu und enthaltend zusätzlichen Kern 1502N aufweisen, dargestellt durch die gestrichelten Kästen. Jeder von Prozessorkernen 1502A-1502N weist eine oder mehrere interne Cache-Einheiten 1504A-1504N auf. In manchen Ausführungsformen hat jeder Prozessorkern 1502A-1502N auch Zugriff auf eine oder mehrere geteilte Cache-Einheiten 1506. Die internen Cache-Einheiten 1504A-1504N und geteilten Cache-Einheiten 1506 stellen eine Cache-Speicherhierarchie im Prozessor 1500 dar. Die Cache-Speicherhierarchie kann mindestens eine Ebene von Befehls- und Daten-Cache in jedem Prozessorkern und eine oder mehrere Ebenen von geteilten Cache mittlerer Ebene, wie Ebene 2 (L2), Ebene 3 (L3), Ebene 4 (L4) oder andere Ebenen von Cache aufweisen, wo die höchste Ebene von Cache vor externem Speicher als der LLC klassifiziert ist. In manchen Ausführungsformen hält Zwischenspeicherungskohärenzlogik Kohärenz zwischen den verschiedenen Cache-Einheiten 1506 und 1504A-1504N aufrecht.
  • Der Prozessor 1500 kann auch einen Satz von einer oder mehreren Bussteuerungseinheiten 1516 und einen Systemagentkern 1510 aufweisen. Die eine oder mehreren Bussteuerungseinheiten 1516 verwalten einen Satz von peripheren Bussen, wie einen oder mehrere PCI oder PCI Express Busse. Systemagentkern 1510 stellt Verwaltungsfunktionalität für die verschiedenen Prozessorkomponenten bereit. Der Systemagentkern 1510 kann eine oder mehrere integrierte Speichersteuerungen 1514 aufweisen, um Zugriff auf verschiedene externe Speichervorrichtungen (nicht dargestellt) zu verwalten.
  • Zum Beispiel können einer oder mehrere der Prozessorkerne 1502A-1502N Unterstützung für simultanes Multi-Threading aufweisen. Der Systemagentkern 1510 weist Komponenten zum Koordinieren und Betreiben von Kernen 1502A-1502N während Multi-Threading-Verarbeitung auf. Systemagentkern 1510 kann zusätzlich eine Leistungssteuerungseinheit (PCU, Power Control Unit) aufweisen, die Logik und Komponenten zum Regulieren des Leistungszustands von Prozessorkernen 1502A-1502N und Grafikprozessor 1508 aufweist.
  • Der Prozessor 1500 kann zusätzlich Grafikprozessor 1508 zur Ausführung von Grafikverarbeitungsoperationen aufweisen. In manchen dieser Ausführungsformen ist der Grafikprozessor 1508 mit dem Satz von geteilten Cache-Einheiten 1506 und dem Systemagentkern 1510 gekoppelt, aufweisend die eine oder mehreren integrierten Speichersteuerungen 1514. Der Systemagentkern 1510 kann auch eine Anzeigesteuerung 1511 zum Antreiben von Grafikprozessorausgang zu einer oder mehreren gekoppelten Anzeigen aufweisen. Die Anzeigesteuerung 1511 kann auch ein separates Modul sein, das mit dem Grafikprozessor über mindestens ein Interconnect gekoppelt ist, oder kann im Grafikprozessor 1508 integriert sein.
  • Eine Ring-basierte Interconnect Einheit 1512 kann verwendet werden, um die internen Komponenten des Prozessors 1500 zu koppeln. Es kann jedoch eine alternative Interconnect-Einheit verwendet werden, wie ein Punkt-zu-Punkt-Interconnect, ein geschaltetes Interconnect oder andere Techniken, aufweisend Techniken, die am Stand der Technik allgemein bekannt sind. In manchen dieser Ausführungsformen mit einem Ring-basierten Interconnect 1512 ist der Grafikprozessor 1508 mit dem Ring-basierten Interconnect 1512 über einen I/O-Link 1513 gekoppelt.
  • Der beispielhafte I/O-Link 1513 stellt mindestens eine von mehreren Variationen von I/O-Interconnects dar, aufweisend ein On-Package I/O-Interconnect, das Kommunikation zwischen verschiedenen Prozessorkomponenten und einem eingebetteten Speichermodul hoher Arbeitsleistung 1518, wie ein eDRAM-Modul, erleichtert. Optional können jeder der Prozessorkerne 1502A-1502N und der Grafikprozessor 1508 eingebettete Speichermodule 1518 als einen geteilten Cache letzter Ebene verwenden.
  • Die Prozessorkerne 1502A-1502N können zum Beispiel homogene Kerne sein, die dieselbe Befehlssatzarchitektur ausführen. Alternativ sind die Prozessorkerne 1502A-1502N heterogen im Sinne von Befehlssatzarchitektur (ISA), wo einer oder mehrere von Prozessorkernen 1502A-1502N einen ersten Befehlssatz ausführen, während mindestens einer der anderen Kerne einen Teilsatz des ersten Befehlssatzes oder einen anderen Befehlssatz ausführt. Die Prozessorkerne 1502A-1502N können im Sinne von Mikroarchitektur heterogen sein, wo einer oder mehrere Kerne mit einem relativ hohen Leistungsverbrauch mit einem oder mehreren Leistungskemen gekoppelt sind, die einen niedrigeren Leistungsverbrauch haben. Als ein anderes Beispiel sind die Prozessorkerne 1502A-1502N im Sinne von Berechnungskapazität heterogen. Zusätzlich kann Prozessor 1500 auf einem oder mehreren Chips oder als eine SoC-integrierte Schaltung mit den veranschaulichten Komponenten zusätzlich zu anderen Komponenten implementiert sein.
  • 15B ist ein Blockdiagramm von Hardwarelogik eines Grafikprozessorkerns 1519 gemäß manchen hier beschriebenen Ausführungsformen. Der Grafikprozessorkern 1519, manchmal als ein Kern-Slice bezeichnet, kann einer oder mehrere Grafikkerne in einem modularen Grafikprozessor sein. Der Grafikprozessorkern 1519 ist für einen Grafikkern-Slice beispielhaft und ein Grafikprozessor wie hier beschrieben kann mehrere Grafikkern-Slices aufweisen, basierend auf Zielleistung und Arbeitsleistungshüllen. Jeder Grafikprozessorkern 1519 kann einen Block fester Funktion 1530 aufweisen, gekoppelt mit mehreren Teilkernen 1521A-1521F, auch als Sub-Slices bezeichnet, die modulare Blöcke von Allzwecklogik und Logik fester Funktion aufweisen.
  • Der Block fester Funktion 1530 kann eine Geometrie/Festfunktion-Pipeline 1531 aufweisen, die sich alle Teilkerne in dem Grafikprozessorkern 1519 teilen können, zum Beispiel Grafikprozessorimplementierungen geringerer Arbeitsleistung und/oder geringerer Leistung. Die Geometrie/Festfunktion-Pipeline 1531 kann eine 3D-Festfunktion-Pipeline (z.B. 3D-Pipeline 1612, wie unten in 16A beschrieben) eine Video-Frontend-Einheit, einen Thread Spawner und Thread Dispatcher und einen vereinheitlichten Rückgabepufferverwalter aufweisen, der vereinheitlichte Rückgabepuffer (z.B. vereinheitlichten Rückgabepuffer 1718 in 17, wie unten beschrieben) verwaltet.
  • Der Block fester Funktion 1530 kann auch eine Grafik-SoC-Schnittstelle 1532, eine Grafikmikrosteuerung 1533 und eine Medien-Pipeline 1534 aufweisen. Die Grafik-SoC-Schnittstelle 1532 stellt eine Schnittstelle zwischen dem Grafikprozessorkern 1519 und anderen Prozessorkernen in einer integrierten System-auf-einem-Chip-Schaltung bereit. Die Grafik Mikrosteuerung 1533 ist ein programmierbarer Teilprozessor, der konfigurierbar ist, um verschiedene Funktionen des Grafikprozessorkerns 1519 zu verwalten, aufweisend Thread Dispatch, Planung und Präemption. Die Medien-Pipeline 1534 (z.B. Medien-Pipeline 1616 von 16A und 17) weist Logik auf, um das Decodieren, Codieren, Vorverarbeiten und/oder Nachverarbeiten von Multmediendaten zu erleichtern, aufweisend Bild- und Videodaten. Die Medien-Pipeline 1534 implementiert Medienoperationen über Anfragen an Rechen- oder Abtastlogik in den Teilkernen 1521-1521F.
  • Die SoC-Schnittstelle 1532 kann dem Grafikprozessorkem 1519 ermöglichen, mit Allzweckanwendungsprozessorkernen (z.B. CPUs) und/oder anderen Komponenten in einem SoC zu kommunizieren, das Speicherhierarchieelemente wie einen geteilten Cache-Speicher letzter Ebene, den System RAM und/oder eingebetteten On-Chip oder On-Package DRAM aufweist. Die SoC-Schnittstelle 1532 kann auch Kommunikation mit Vorrichtungen fester Funktion im SoC ermöglichen, wie Kamerabildgebungs-Pipelines, und ermöglicht die Verwendung von und/oder implementiert globale Speicher-Atomics, die sich Grafikprozessorkern 1519 und CPUs innerhalb des SoC teilen 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 Empfang von Steuerbefehlspuffern von einem Steuerbefehl-Streamer und globalen Thread Dispatcher, die konfiguriert sind, Steuerbefehle und Befehle für jeden von einem oder mehreren Grafikkernen in einem Grafikprozessor bereitzustellen. Die Steuerbefehle und Befehle können an die Medien-Pipeline 1534 geleitet werden, wenn Medienoperationen durchzuführen sind, oder eine Geometrie- und Festfunktion-Pipeline (z.B. Geometrie- und Festfunktion-Pipeline 1531, Geometrie- und Festfunktion-Pipeline 1537), wenn Grafikverarbeitungsoperationen durchzuführen sind.
  • Die Grafikmikrosteuerung 1533 kann konfiguriert sein, verschiedene Planungs- und Verwaltungsaufgaben für den Grafikprozessorkern 1519 durchzuführen. In einer Konfiguration kann die Grafikmikrosteuerung 1533 zum Beispiel Grafik- und/oder Rechenarbeitslastplanung an den verschiedenen parallelen Grafik-Engines innerhalb Ausführungseinheits- (EU, Execution Unit) Gruppen 1522A-1522F, 1524A-1524F innerhalb der Teilkerne 1521A-1521F durchführen. In dieser Arbeitslastplanung kann Host-Software, die auf einem CPU-Kern eines SoC ausgeführt wird, das den Grafikprozessorkern 1519 aufweist, Arbeitslasten einer oder mehrerer Grafikprozessor-Doorbells unterbreiten, wodurch eine Planungsoperation auf der geeigneten Grafik-Engine aufgerufen wird. Planungsoperationen weisen Bestimmen auf, welche Arbeitslast als nächste läuft, Unterbreiten einer Arbeitslast einem Steuerbefehl-Streamer, Vorwegnehmen bestehender Arbeitslasten, die auf einer Engine laufen, Überwachen eines Verlaufs einer Arbeitslast und Benachrichtigen von Host-Software, wenn eine Arbeitslast abgeschlossen ist. Optional kann die Grafikmikrosteuerung 1533 auch leistungsarme oder Leerlaufzustände für den Grafikprozessorkern 1519 erleichtern, dem Grafikprozessorkern 1519 die Fähigkeit bereitstellen, Register in dem Grafikprozessorkern 1519 über Niederleistungszustandsübergänge unabhängig von dem Betriebssystem und/oder der Grafiktreibersoftware auf dem System zu speichern oder wiederherzustellen.
  • Der Grafikprozessorkern 1519 kann mehr oder weniger als die veranschaulichten Teilkerne 1521A-1521F haben, bis zu N modulare Teilkerne. Für jeden Satz von N Teilkernen kann der Grafikprozessorkern 1519 auch geteilte Funktionslogik 1535, geteilten und/oder Cache-Speicher 1536, eine Geometrie-/Festfunktion-Pipeline 1537, wie auch zusätzliche Logik fester Funktion 1538 haben, um verschiedene Grafik- und Rechenverarbeitungsoperationen zu beschleunigen. Die geteilte Funktionslogik 1535 kann Logikeinheiten aufweisen, die mit der geteilten Funktionslogik 1720 von 17 verknüpft sind (z.B. Sampler, mathematische und/oder Inter-Thread Kommunikationslogik), die sich N Teilkerne in dem Grafikprozessorkem 1519 teilen können. Der geteilte und/oder Cache-Speicher 1536 kann ein Cache letzter Ebene für den Satz von N Teilkernen 1521A-1521F in dem Grafikprozessorkern 1519 sein und kann auch als geteilter Speicher dienen, auf den mehrere Teilkerne zugreifen können. Die Geometrie-/Festfunktion-Pipeline 1537 kann anstelle der Geometrie-/Festfunktion-Pipeline 1531 in dem Block fester Funktion 1530 enthalten sein und kann dieselben oder ähnliche Logikeinheiten aufweisen.
  • Der Grafikprozessorkern 1519 kann zusätzliche Logik fester Funktion 1538 aufweisen, die verschiedene Beschleunigungslogik fester Funktion zur Verwendung durch den Grafikprozessorkern 1519 aufweisen kann. Optional weist die zusätzliche Logik fester Funktion 1538 eine zusätzliche Geometrie-Pipeline zur Verwendung in Schattieren nur der Position auf. In Schattieren nur der Position gibt es zwei Geometrie-Pipelines, die vollständige Geometrie-Pipeline in der Geometrie-/Festfunktion-Pipeline 1538, 1531 und eine Cull-Pipeline, die eine zusätzliche Geometrie-Pipeline ist, die in der zusätzlichen Logik fester Funktion 1538 enthalten sein kann. Zum Beispiel kann die Cull-Pipeline eine gekürzte Version der vollständigen Geometrie-Pipeline sein. Die vollständige Pipeline und die Cull-Pipeline können verschiedene Fälle derselben Anwendung ausführen, wobei jeder Fall einen eigenen Kontext hat. Schattieren nur der Position kann lange Cull-Verläufe verworfener Dreiecke verbergen, wodurch Schattieren in manchen Fällen früher abgeschlossen werden kann. Zum Beispiel kann die Cull-Pipeline-Logik in der zusätzlichen Logik fester Funktion 1538 Position-Shader parallel mit der Hauptanwendung ausführen und erzeugt im Allgemeinen kritische Ergebnisse schneller als die vollständige Pipeline, da die Cull-Pipeline nur das Positionsattribut von Scheitelpunkten abruft und zeichnet, ohne Rastern und Rendern der Pixel zu dem Frame-Puffer durchzuführen. Die Cull-Pipeline kann die erzeugten kritischen Ergebnisse zur Berechnung von Sichtbarkeitsinformationen für alle Dreiecke verwenden, ohne zu berücksichtigen ob diese Dreiecke verworfen sind. Die vollständige Pipeline (die in diesem Fall als eine Wiedergabe-Pipeline bezeichnet werden kann) kann die Sichtbarkeitsinformationen verwenden, um die verworfenen Dreiecke zu überspringen, um nur die sichtbaren Dreiecke zu zeichnen, die schließlich zu der Rasterungsphase geleitet werden.
  • Optional kann die zusätzliche Logik fester Funktion 1538 auch Maschinenlernbeschleunigungslogik, wie Matrixmultiplikationslogik fester Funktion, für Implementierungen aufweisen, die Optimierungen für Maschinenlerntraining oder Schlussfolgerung aufweisen.
  • Jeder Grafikteilkern 1521A-1521F weist einen Satz von Ausführungsressourcen auf, die zum Durchführen von Grafik-, Medien- und Rechenoperationen in Antwort auf Anfragen von Grafik-Pipeline, Medien-Pipeline oder Shader-Programmen verwendet werden können. Die Grafikteilkerne 1521A-1521F weisen mehrere EU-Arrays 1522A-1522F, 1524A-1524F, Thread Dispatch und Inter-Thread-Kommunikations- (TD/IC) Logik 1523A-1523F, einen 3D (z.B. Textur) Sampler 1525A-1525F, einen Medien-Sampler 1526A-1526F, einen Shader-Prozessor 1527A-1527F und geteilten lokalen Speicher (SLM) 1528A-1528F auf. Die EU-Arrays 1522A-1522F, 1524A-1524F weisen jeweils mehrere Ausführungseinheiten auf, die AllzweckGrafikverarbeitungseinheiten sind, die zum Durchführen von Gleitkomma- und Ganzzahl/Festkomma-Logikoperationen beim Ausführen einer Grafik-, Medien- oder Rechenoperation imstande sind, enthaltend Grafik-, Medien- oder Rechen-Shader-Programme. Die TD/IC-Logik 1523A-1523F führt lokale Thread Dispatch- und Thread-Steueroperationen für die Ausführungseinheiten innerhalb eines Teilkerns durch und erleichtert Kommunikation zwischen Threads, die auf den Ausführungseinheiten des Teilkerns laufen. Der 3D-Sampler 1525A-1525F kann Textur oder andere auf 3D-Grafik bezogene Daten in Speicher lesen. Der 3D-Sampler kann Texturdaten basierend auf einem konfigurierten Abtastzustand und dem Texturformat, das mit einer bestimmten Textur verknüpft ist, anders lesen. Der Medien-Sampler 1526A-1526F kann ähnliche Leseoperationen basierend auf dem Typ und Format durchführen, die mit Mediendaten verknüpft sind. Zum Beispiel kann jeder Grafikteilkern 1521A-1521F abwechselnd einen vereinheitlichten 3D- und Medien-Sampler aufweisen. Threads, die auf den Ausführungseinheiten in jedem der Teilkerne 1521A-1521F laufen, können den geteilten lokalen Speicher 1528A-1528F in jedem Teilkern nutzen, um Threads zu ermöglichen, in einer Thread-Gruppe ausgeführt zu werden, um unter Verwendung eines gemeinsamen Pools von On-Chip-Speicher ausgeführt zu werden.
  • 15C ist ein Blockdiagramm einer Allzweckgrafikverarbeitungseinheit (GPGPU) 1570, die als ein Grafikprozessor, z.B. der Grafikprozessor 1508, und/oder Rechenbeschleuniger, gemäß hier beschriebenen Ausführungsformen konfiguriert sein kann. Die GPGPU 1570 kann mit Host-Prozessoren (z.B. einer oder mehreren CPU(s) 1546) und Speicher 1571, 1572 über einen oder mehrere System- und/oder Speicherbusse zwischenverbunden sein. Speicher 1571 kann Systemspeicher sein, den sich die eine oder mehreren CPU(s) 1546 teilen können, während Speicher 1572 ein Vorrichtungsspeicher ist, der für die GPGPU 1570 dediziert ist. Zum Beispiel können Komponenten in der GPGPU 1570 und dem Vorrichtungsspeicher 1572 in Speicheradressen abgebildet werden, auf die eine oder mehrere CPU(s) 1546 zugreifen können. Zugriff auf Speicher 1571 und 1572 kann über eine Speichersteuerung 1568 erleichtert werden. Die Speichersteuerung 1568 kann eine interne direkte Speicherzugriffs- (DMA) Steuerung 1569 aufweisen oder kann Logik aufweisen, um Operationen durchzuführen, die sonst von einer DMA-Steuerung durchgeführt werden.
  • Die GPGPU 1570 weist mehrere Cache-Speicher auf, aufweisend einen L2 Cache 1553, L1 Cache 1554, einen Befehls-Cache 1555 und geteilten Speicher 1556, von dem mindestens ein Teil auch als ein Cache-Speicher abgetrennt sein kann. Die GPGPU 1570 weist auch mehrere Recheneinheiten 1560A-1560N auf Jede Recheneinheit 1560A-1560N weist einen Satz von Vektorregistern 1561, Skalarregistern 1562, Vektorlogikeinheiten 1563 und Skalarlogikeinheiten 1564 auf. Die Recheneinheiten 1560A-1560N können auch lokalen geteilten Speicher 1565 und einen Programmzähler 1566 aufweisen. Die Recheneinheiten 1560A-1560N können mit einem konstanten Cache 1567 gekoppelt sein, der verwendet werden kann, um konstante Daten zu speichern, die Daten sind, die sich während des Laufs des Kernel- oder Shader-Programms nicht ändern, das auf der GPGPU 1570 läuft. Der konstante Cache 1567 kann ein Skalardaten-Cache sein und zwischengespeicherte Daten können direkt in das Skalarregister 1562 abgerufen werden.
  • Während des Betriebs können die eine oder mehreren CPU(s) 1546 Steuerbefehle in Register oder Speicher in der GPGPU 1570 schreiben, die in einen zugänglichen Adressenraum abgebildet wurden. Die Steuerbefehlsprozessoren 1557 können die Steuerbefehle aus Registern oder Speicher lesen und bestimmen, wie diese Steuerbefehle in der GPGPU 1570 verarbeitet werden. Ein Thread Dispatcher 1558 kann dann verwendet werden, um Threads zu den Recheneinheiten 1560A-1560N zu leiten, um diese Steuerbefehle durchzuführen. Jede Recheneinheit 1560A-1560N kann Threads unabhängig von den anderen Recheneinheiten ausführen. Zusätzlich kann jede Recheneinheit 1560A-1560N unabhängig für konditionelle Berechnung konfiguriert sein und kann die Ergebnisse einer Berechnung konditionell an Speicher ausgeben. Die Steuerbefehlsprozessoren 1557 können die eine oder mehreren CPU(s) 1546 unterbrechen, wenn die unterbreiteten Steuerbefehle abgeschlossen sind.
  • 16A-16C veranschaulichen Blockdiagramme zusätzlicher Grafikprozessor- und Rechenbeschleunigerarchitekturen, die durch hier beschriebene Ausführungsformen bereitgestellt werden, z.B. gemäß 15A-15C. Die Elemente von 16A-16C mit denselben oder ähnlichen Bezeichnungen wie die Elemente einer beliebigen anderen Figur hierin, beschreiben dieselben Elemente wie in den anderen Figuren, können auf ähnliche Weise wie diese arbeiten oder funktionieren, können dieselben Komponenten aufweisen und können mit anderen Einheiten, wie jenen, die hier an anderer Stelle beschrieben sind, verbunden sein, sind aber als solche nicht eingeschränkt.
  • 16A ist ein Blockdiagramm eines Grafikprozessors 1600, der eine separate Grafikverarbeitungseinheit sein kann oder ein Grafikprozessor sein kann, der mit mehreren Verarbeitungskernen oder anderen Halbleitervorrichtungen integriert sein kann, wie, ohne aber darauf beschränkt zu sein, 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 beliebiger Merkmale in Kombination mit dem Grafikprozessor 1508 hier auch eine entsprechende Kombination mit dem Grafikprozessor 1600, ist aber nicht darauf beschränkt. Der Grafikprozessor kann über eine speicherabgebildete I/O-Schnittstelle zum Register auf dem Grafikprozessor und mit Steuerbefehlen, die im Prozessorspeicher platziert sind, kommunizieren. Grafikprozessor 1600 kann eine Speicherschnittstelle 1614 für einen Zugriff auf Speicher aufweisen. Speicherschnittstelle 1614 kann eine Schnittstelle zu einem lokalen Speicher, einem oder mehreren internen Caches, einem oder mehreren geteilten externen Caches und/oder zu Systemspeicher sein.
  • Optional weist Grafikprozessor 1600 auch eine Anzeigesteuerung 1602 auf, um Anzeige von Ausgangsdaten zu einer Anzeigevorrichtung 1618 anzutreiben. Anzeigesteuerung 1602 weist Hardware für eine oder mehrere Überlagerungsebenen für die Anzeige und Zusammenstellung mehrerer Schichten von Video- oder Anwenderschnittstellenelementen auf. Die Anzeigevorrichtung 1618 kann eine interne oder externe Anzeigevorrichtung sein. In einer Ausführungsform ist die Anzeigevorrichtung 1618 eine am Kopf montierte Anzeigevorrichtung, wie eine virtuelle Realitäts- (VR) Anzeigevorrichtung oder eine erweiterte Realitäts- (AR) Anzeigevorrichtung. Grafikprozessor 1600 kann eine Video-Codec-Engine 1606 zum Codieren, Decodieren oder Transcodieren von Medien zu, von oder zwischen einem oder mehreren Mediencodierformaten aufweisen, aufweisend, aber nicht beschränkt auf, Moving Picture Experts Group (MPEG) Formate, wie MPEG-2, Advanced Video Coding (AVC) Formate, wie H.264/MPEG-4 AVC, H.265/HEVC, Alliance for Open Media (AOMedia) VP8, VP9, wie auch die Society of Motion Picture & Television Engineers (SMPTE) 421M/VC-1 und Joint Photographic Experts Group (JPEG) Formate, wie JPEG und Motion JPEG (MJPEG) Formate.
  • Grafikprozessor 1600 kann eine Blockbildüberführungs- (BLIT) Engine 1603 aufweisen, um zweidimensionale (2D) Rasterisiereroperationen durchzuführen, aufweisend zum Beispiel Bit-Grenzen-Blocktransfers. Alternativ jedoch können 2D-Grafikoperationen unter Verwendung einer oder mehrerer Komponenten von Grafikverarbeitungs-Engine (GPE) 1610 durchgeführt werden. In manchen Ausführungsformen ist GPE 1610 eine Rechen-Engine zum Durchführen von Grafikoperationen, aufweisend dreidimensionale (3D) Grafikoperationen und Medienoperationen.
  • GPE 1610 kann eine 3D-Pipeline 1612 zum Durchführen von 3D-Operationen aufweisen, wie Rendern von dreidimensionalen Bildern und Szenen unter Verwendung von Verarbeitungsfunktionen, die auf 3D-Primitive-Formen (z.B. Rechteck, Dreieck usw.) wirken. Die 3D-Pipeline 1612 weist programmierbare und Festfunktion-Elemente auf, die verschiedene Aufgaben in dem Element durchführen und/oder Ausführungs-Threads auf ein 3D/Medienteilsystem 1615 auslagern. Während 3D-Pipeline 1612 verwendet werden kann, um Medienoperationen durchzuführen, weist eine Ausführungsform von GPE 1610 auch eine Medien-Pipeline 1616 auf, die im Speziellen zum Durchführen von Medienoperationen, wie Video-Nachbearbeitung und Bildverstärkung, verwendet wird.
  • Medien-Pipeline 1616 kann Festfunktion- oder programmierbare Logikeinheiten aufweisen, um eine oder mehrere spezialisierte Medienoperationen durchzuführen, wie Videodecodierbeschleunigung, Videoentschachtelung und Videocodierbeschleunigung anstelle oder seitens der Video-Codec-Engine 1606. Medien-Pipeline 1616 kann zusätzlich eine Thread-Spawning-Einheit aufweisen, um Threads zur Ausführung auf 3D/Medienteilsystem 1615 auszulagern. Die ausgelagerten Threads führen Berechnungen für die Medienoperationen auf einer oder mehreren Grafikausführungseinheiten durch, die im 3D/Medienteilsystem 1615 enthalten sind.
  • Das 3D/Medienteilsystem 1615 kann Logik zur Ausführung von Threads aufweisen, die durch 3D-Pipeline 1612 und Medien-Pipeline 1616 ausgelagert werden. Die Pipelines können Thread-Ausführungsanfragen an 3D/Medienteilsystem 1615 senden, das Thread Dispatch-Logik zum Schlichten und Weiterleiten der verschiedenen Anfragen an verfügbare Thread-Ausführungsressourcen aufweist. Die Ausführungsressourcen weisen ein Array von Grafikausführungseinheiten auf, um die 3D- und Medien-Threads zu verarbeiten. Das 3D/Medienteilsystem 1615 kann einen oder mehrere interne Caches für Thread-Befehle und -Daten aufweisen. Zusätzlich kann das 3D/Medienteilsystem 1615 auch geteilten Speicher aufweisen, aufweisend Register und adressierbaren Speicher, um Daten zwischen Threads zu teilen und Ausgangsdaten 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 beliebiger Merkmale in Kombination mit dem Grafikprozessor 1600 hier auch eine entsprechende Kombination mit dem (den) Grafikprozessor 1620, ist aber nicht darauf beschränkt. Der Grafikprozessor 1620 hat eine gekachelte Architektur gemäß hier beschriebenen Ausführungsformen. Der Grafikprozessor 1620 kann einen Grafikverarbeitungs-Engine-Cluster 1622 mit mehreren Exemplaren der Grafikverarbeitungs-Engine 1610 von 16A in einer Grafik-Engine-Kachel 1610A-1610D aufweisen. Jede Grafik-Engine-Kachel 1610A-1610D kann über einen Satz von Kachel-Interconnects 1623A-1623F zwischenverbunden sein. Jede Grafik-Engine-Kachel 1610A-1610D kann auch mit einem Speichermodul oder einer Speichervorrichtung 1626A-1626D über Speicher-Interconnects 1625A-1625D verbunden sein. Die Speichervorrichtungen 1626A-1626D kann eine beliebige Grafikspeichertechnologie verwenden. Zum Beispiel können die Speichervorrichtungen 1626A-1626D Grafikdoppeldatenraten- (GDDR) Speicher sein. Die Speichervorrichtungen 1626A-1626D können Speichermodule hoher Bandbreite (HBM) sein, die On-Die mit ihrer entsprechenden Grafik-Engine-Kachel 1610A-1610D sein können. Die Speichervorrichtungen 1626A-1626D können gestapelte Speichervorrichtungen sein, die auf ihrer jeweiligen Grafik-Engine-Kachel 1610A-1610D gestapelt sein können. Jede Grafik-Engine-Kachel 1610A-1610D und zugehöriger Speicher 1626A-1626D können sich auf separaten Chiplets befinden, die an einen Basis-Die oder ein Basissubstrat gebondet sind, wie in näherer Einzelheit in 24B-24D beschrieben.
  • Der Grafikprozessor 1620 kann mit einem nicht gleichförmigen Speicherzugriffs- (NUMA, Non-Uniform Memory Access) System konfiguriert sein, in dem Speichervorrichtungen 1626A-1626D mit zugehörigen Grafik-Engine-Kacheln 1610A-1610D gekoppelt sind. Auf eine bestimmte Speichervorrichtung kann durch Grafik-Engine-Kacheln zugegriffen werden, die nicht die Kachel sind, mit der sie direkt verbunden ist. Zugriffslatenz zu den Speichervorrichtungen 1626A-1626D kann jedoch am niedrigsten sein, wenn auf eine lokale Kachel zugegriffen wird. In einer Ausführungsform wird ein Cache-kohärentes NUMA (ccNUMA) System freigegeben, das die Kachel-Interconnects 1623A-1623F verwendet, um Kommunikation zwischen Cache-Steuerungen in den Grafik-Engine-Kacheln 1610A-1610D zu ermöglichen, um ein konsistentes Speicherbild beizubehalten, wenn mehr als ein Cache dieselbe Speicherstelle speichert.
  • Der Grafikverarbeitungs-Engine-Cluster 1622 kann mit einem On-Chip oder On-Package Fabric-Interconnect 1624 verbunden sein. In einer Ausführungsform weist das Fabric Interconnect 1624 einen Netzwerkprozessor, ein Netzwerk auf einem Chip (NoC) oder einen anderen Schaltprozessor auf, um dem Fabric-Interconnect 1624 zu ermöglichen, als ein paketvermitteltes Fabric-Interconnect zu agieren, das Datenpakete zwischen Komponenten des Grafikprozessors 1620 vermittelt. Das Fabric-Interconnect 1624 kann Kommunikation zwischen Grafik-Engine-Kacheln 1610A-1610D und Komponenten wie der Video-Codec-Engine 1606 und einer oder mehreren Kopier-Engines 1604 ermöglichen. Die Kopier-Engines 1604 können verwendet werden, um Daten aus, in und zwischen Speichervorrichtungen 1626A-1626D und Speicher zu bewegen, der extern zu dem Grafikprozessor 1620 (z.B. Systemspeicher) ist. Das Fabric-Interconnect 1624 kann auch zum Zwischenverbinden der Grafik-Engine-Kacheln
    1610A-1610D verwendet werden. Der Grafikprozessor 1620 kann optional eine Anzeigesteuerung 1602 aufweisen, um eine Verbindung mit einer externen Anzeigevorrichtung 1618 zu ermöglichen. Der Grafikprozessor kann auch als ein Grafik- oder Rechenbeschleuniger konfiguriert sein. In der Beschleunigerkonfiguration können die Anzeigesteuerung 1602 und Anzeigevorrichtung 1618 weggelassen werden.
  • Der Grafikprozessor 1620 kann mit einem Host-System über eine Host-Schnittstelle 1628 verbunden sein. Die Host-Schnittstelle 1628 kann Kommunikation zwischen dem Grafikprozessor 1620, Systemspeicher und/oder anderen Systemkomponenten ermöglichen. Die Host-Schnittstelle 1628 kann zum Beispiel ein PCI Express Bus oder eine andere Art von Host-Systemschnittstelle sein. Zum Beispiel kann die Host-Schnittstelle 1628 eine NVLink- oder NVSwitch-Schnittstelle sein. Die Host-Schnittstelle 1628 und das Fabric-Interconnect 1624 können zusammenarbeiten, um mehreren Exemplaren des Grafikprozessors 1620 zu ermöglichen, als eine einzelne logische Vorrichtung zu dienen. Zusammenarbeit zwischen der Host-Schnittstelle 1628 und dem Fabric-Interconnect 1624 kann auch den einzelnen Grafik-Engine-Kacheln 1610A-1610D ermöglichen, dem Host-System als separate logische Grafikvorrichtungen präsentiert zu werden.
  • 16C veranschaulicht einen Rechenbeschleuniger 1630 gemäß hier beschriebenen Ausführungsformen. Der Rechenbeschleuniger 1630 kann architektonische Ähnlichkeiten mit dem Grafikprozessor 1620 von 16B aufweisen und ist für Rechenbeschleunigung optimiert. Ein Rechen-Engine-Cluster 1632 kann einen Satz von Rechen-Engine-Kacheln 1640A-1640D aufweisen, die Ausführungslogik aufweisen, die für parallele oder Vektor-basierte Allzweckrechenoperationen optimiert ist. Die Rechen-Engine-Kacheln 1640A-1640D können keine Grafikverarbeitungslogik fester Funktion aufweisen, obwohl in manchen Ausführungsformen eine oder mehrere der Rechen-Engine-Kacheln 1640A-1640D Logik aufweisen können, um Medienbeschleunigung durchzuführen. Die Rechen-Engine-Kacheln 1640A-1640D können mit Speichern 1626A-1626D über Speicher-Interconnects 1625A-1625D verbunden sein. Die Speicher 1626A-1626D und Speicher-Interconnects 1625A-1625D können eine ähnliche Technologie wie in Grafikprozessor 1620 sein oder können sich davon unterscheiden. Die Grafik Rechen-Engine-Kacheln 1640A-1640D können auch über einen Satz von Kachel-Interconnects 1623A-1623F zwischenverbunden sein und können mit einem Fabric-Interconnect 1624 verbunden und/oder durch dieses zwischenverbunden sein. In einer Ausführungsform weist der Rechenbeschleuniger 1630 einen großen L3 Cache 1636 auf, der als ein vorrichtungsweiter Cache konfiguriert sein kann. Der Rechenbeschleuniger 1630 kann auch mit einem Host-Prozessor und Speicher über eine Host-Schnittstelle 1628 auf ähnliche Weise wie der Grafikprozessor 1620 von 16B verbunden sein.
  • Der Rechenbeschleuniger 1630 kann auch eine integrierte Netzwerkschnittstelle 1642 aufweisen. In einer Ausführungsform weist die Netzwerkschnittstelle 1642 einen Netzwerkprozessor und eine Steuerungslogik auf, die dem Rechen-Engine-Cluster 1632 ermöglicht, über ein physisches Schicht-Interconnect 1644 zu kommunizieren, ohne Daten zu Durchqueren eines Speichers eines Host-Systems zu benötigen. In einer Ausführungsform ist eine der Rechen-Engine-Kacheln 1640A-1640D durch Netzwerkprozessorlogik ersetzt und Daten, die über das physische Schicht-Interconnect 1644 übertragen oder empfangen werden sollen, können direkt zu oder von Speicher 1626A-1626D übertragen werden. Mehrere Exemplare des Rechenbeschleunigers 1630 können über das physische Schicht-Interconnect 1644 zu einer einzigen logischen Vorrichtung verbunden sein. Alternativ können die verschiedenen Rechen-Engine-Kacheln 1640A-1640D als einzelne netzwerkzugängliche Rechenbeschleunigervorrichtungen präsentiert werden.
  • Grafikverarbeitungs-Engine
  • 17 ist ein Blockdiagramm einer Grafikverarbeitungs-Engine 1710 eines Grafikprozessors gemäß manchen Ausführungsformen. Die Grafikverarbeitungs-Engine (GPE) 1710 kann eine Version der GPE 1610. dargestellt in 16A, sein und kann auch eine Grafik-Engine-Kachel 1610A-1610D von 16B darstellen. Die Elemente von 17 mit denselben oder ähnlichen Bezeichnungen wie die Elemente einer beliebigen anderen Figur hierin, beschreiben dieselben Elemente wie in den anderen Figuren, können auf ähnliche Weise wie diese arbeiten oder funktionieren, können dieselben Komponenten aufweisen und können mit anderen Einheiten, wie jenen, die hier an anderer Stelle beschrieben sind, verbunden sein, sind aber als solche nicht eingeschränkt. Zum Beispiel sind die 3D-Pipeline 1612 und Medien-Pipeline 1616 von 16A auch in 17 veranschaulicht. Die Medien-Pipeline 1616 ist in manchen Ausführungsformen der GPE 1710 optional und kann nicht ausdrücklich in der GPE 1710 enthalten sein. Zum Beispiel und in mindestens eine Ausführungsform ist ein separater Medien- und/oder Bildprozessor an die GPE 1710 gekoppelt.
  • GPE 1710 kann mit einem Steuerbefehl-Streamer 1703 koppeln oder diesen aufweisen, der der 3D-Pipeline 1612 und/oder den Medien-Pipelines 1616 einen Steuerbefehlsstrom bereitstellt. Alternativ oder zusätzlich, kann der Steuerbefehl-Streamer 1703 direkt an einen vereinheitlichten Rückgabepuffer 1718 gekoppelt sein. Der vereinheitlichte Rückgabepuffer 1718 kann kommunikativ an ein Grafikkernarray 1714 gekoppelt sein. Optional ist der Steuerbefehl-Streamer 1703 mit Speicher gekoppelt, der Systemspeicher oder einer oder mehrere von internem Cache-Speicher und geteiltem Cache-Speicher sein kann. Der Steuerbefehl-Streamer 1703 kann Steuerbefehle von dem Speicher empfangen und sendet die Steuerbefehle an 3D-Pipeline 1612 und/oder Medien-Pipeline 1616. Die Steuerbefehle sind Richtlinien, die von einem Ringpuffer abgerufen werden, der Steuerbefehle für die 3D-Pipeline 1612 und Medien-Pipeline 1616 speichert. Der Ringpuffer kann zusätzlich Stapelsteuerbefehlspuffer aufweisen, die Stapel von mehreren Steuerbefehlen speichern. Die Steuerbefehle für die 3D-Pipeline 1612 können auch Referenzen auf Daten aufweisen, die im Speicher gespeichert sind, wie, ohne aber darauf beschränkt zu sein, Vertex- und Geometriedaten für die 3D-Pipeline 1612 und/oder Bilddaten und Speicherobjekte für die Medien-Pipeline 1616. Die 3D-Pipeline 1612 und Medien-Pipeline 1616 verarbeiten die Steuerbefehle und Daten durch Durchführen von Operationen über Logik in den jeweiligen Pipelines oder durch Weiterleiten eines oder mehrerer Ausführungs-Threads an das Grafikkernarray 1714. Das Grafikkernarray 1714 kann einen oder mehrere Blöcke von Grafikkernen (z.B. Grafikkern(e) 1715A, Grafikkern(e) 1715B) aufweisen, wobei jeder Block einen oder mehrere Grafikkerne aufweist. Jeder Grafikkern weist einen Satz von Grafikausführungsressourcen auf, die Allzweck- und grafikspezifische Ausführungslogik aufweisen, um Grafik- und Rechenoperationen wie auch Festfunktion-Texturverarbeitung und/oder Maschinenlernen durchzuführen, und künstliche Intelligenz-Beschleunigungslogik.
  • In verschiedenen Ausführungsformen kann die 3D-Pipeline 1612 Festfunktion- und programmierbare Logik aufweisen, um ein oder mehrere Shader-Programme, wie Vertex-Shader-, Geometrie-Shader-, Pixel-Shader-, Fragment-Shader-, Rechen-Shader- oder andere Shader-Programme, durch Verarbeitung der Befehle und Weiterleiten von Ausführungs-Threads zu dem Grafikkernarray 1714 zu verarbeiten. Das Grafikkernarray 1714 stellt einen vereinheitlichten Block von Ausführungsressourcen zur Verwendung in Verarbeitung dieser Shader-Programme bereit. Mehrzweckausführungslogik (z.B. Ausführungseinheiten) in dem (den) Grafikkern(en) 1715A-1715B des Grafikkernarrays 1714 weist Unterstützung für verschiedene 3D API-Shader-Sprachen auf und kann mehrere simultane Ausführungs-Threads ausführen, die mit mehreren Shadern verknüpft sind.
  • Das Grafikkernarray 1714 kann Ausführungslogik aufweisen, um Medienfunktionen, wie Video- und/oder Bildverarbeitung durchzuführen. Die Ausführungseinheiten können Allzwecklogik aufweisen, die programmierbar ist, um Allzweckberechnungsoperationen zusätzlich zu Grafikverarbeitungsoperationen durchzuführen. Die Allzwecklogik kann Verarbeitungsoperationen parallel oder in Verbindung mit Allzwecklogik in dem (den) Prozessorkern(en) 1407 von 14 oder Kern 1502A-1502N, wie in 15A, durchführen.
  • Ausgangsdaten, die von Threads erzeugt werden, die auf dem Grafikkernarray 1714 laufen, können Ausgangsdaten zu Speicher in einem vereinheitlichten Rückgabepuffer (URB) 1718 sein. Der URB 1718 kann Daten für mehrere Threads speichern. Der URB 1718 kann zum Senden von Daten zwischen verschiedenen Threads verwendet werden, die auf dem Grafikkernarray 1714 laufen. Der URB 1718 kann zusätzlich zur Synchronisation zwischen Threads auf dem Grafikkernarray 1714 und Festfunktionslogik in der geteilten Funktionslogik 1720 verwendet werden.
  • Optional kann das Grafikkernarray 1714 skalierbar sein, sodass das Array eine variable Anzahl von Grafikkernen aufweist, die jeweils eine variable Anzahl von Ausführungseinheiten haben, basierend auf der Zielleistung und dem Arbeitsleistungsniveau von GPE 1710. Die Ausführungsressourcen können dynamisch skalierbar sein, sodass Ausführungsressourcen nach Bedarf freigegeben oder gesperrt werden können.
  • Das Grafikkernarray 1714 koppelt mit geteilter Funktionslogik 1720, die mehrere Ressourcen aufweist, die zwischen den Grafikkernen in dem Grafikkernarray geteilt werden. Die geteilten Funktionen in der geteilten Funktionslogik 1720 sind Hardwarelogikeinheiten, die dem Grafikkernarray 1714 spezialisierte ergänzende Funktionalität bereitstellen. In verschiedenen Ausführungsformen weist geteilte Funktionslogik 1720, ohne aber darauf beschränkt zu sein, Sampler 1721, Math 1722 und Inter-Thread-Kommunikations- (ITC) 1723 Logik auf. Zusätzlich können ein oder mehrere Cache(s) 1725 in der geteilten Funktionslogik 1720 implementiert sein.
  • Eine geteilte Funktion wird mindestens in einem Fall implementiert, wo der Bedarf an einer gegebenen spezialisierten Funktion für einen Einschluss in das Grafikkernarray 1714 unzureichend ist. Stattdessen wird eine einzige Instanziierung dieser spezialisierten Funktion als eine eigenständige Einheit in der geteilten Funktionslogik 1720 implementiert und unter den Ausführungsressourcen in dem Grafikkernarray 1714 geteilt. Der präzise Satz von Funktionen, der zwischen dem Grafikkernarray 1714 geteilt und in dem Grafikkernarray 1714 enthalten ist, variiert über Ausführungsformen. Bestimmte geteilte Funktionen in der geteilten Funktionslogik 1720, die umfassend von dem Grafikkernarray 1714 verwendet werden, können in der geteilten Funktionslogik 1716 in dem Grafikkernarray 1714 enthalten sein. Optional kann die geteilte Funktionslogik 1716 in dem Grafikkernarray 1714 etwas oder die gesamte Logik in der geteilten Funktionslogik 1720 aufweisen. Alle Logikelemente in der geteilten Funktionslogik 1720 können in der geteilten Funktionslogik 1716 des Grafikkernarrays 1714 dupliziert sein. Alternativ ist die geteilte Funktionslogik 1720 zugunsten der geteilten Funktionslogik 1716 in dem Grafikkernarray 1714 ausgeschlossen.
  • Ausführungseinheiten
  • 18A-18B veranschaulichen Thread-Ausführungslogik 1800, aufweisend ein Array von Verarbeitungselementen, die in einem Grafikprozessorkem gemäß hier beschriebenen Ausführungsformen verwendet werden. Die Elemente von 18A-18B mit denselben oder ähnlichen Bezeichnungen wie die Elemente einer beliebigen anderen Figur hierin, beschreiben dieselben Elemente wie in den anderen Figuren, können auf ähnliche Weise wie diese arbeiten oder funktionieren, können dieselben Komponenten aufweisen und können mit anderen Einheiten, wie jenen, die hier an anderer Stelle beschrieben sind, verbunden sein, sind aber als solche nicht eingeschränkt. 18A-18B veranschaulichen einen Überblick einer Thread-Ausführungslogik 1800, die für Hardwarelogik repräsentativ sein kann, die bei jedem Teilkern 1521A-1521F von 15B veranschaulicht ist. 18A ist für eine Ausführungseinheit in einem Allzweckgrafikprozessor repräsentativ, während 18B für eine Ausführungseinheit repräsentativ ist, die in einem Rechenbeschleuniger verwendet werden kann.
  • Wie in 18A veranschaulicht, kann Thread-Ausführungslogik 1800 einen Shader-Prozessor 1802, einen Thread Dispatcher 1804, Befehls-Cache 1806, ein skalierbares Ausführungseinheitsarray, aufweisend mehrere Grafikausführungseinheiten 1808A-1808N, einen Sampler 1810, geteilten lokalen Speicher 1811, einen Daten-Cache 1812 und einen Datenanschluss 1814 aufweisen. Optional kann das skalierbare Ausführungseinheitsarray dynamisch skalieren, indem eine oder mehrere Ausführungseinheiten (z.B. eine von Grafikausführungseinheiten 1808A, 1808B, 1808C, 1808D bis 1808N-1 und 1808N) basierend auf den Berechnungsanforderungen einer Arbeitslast freigegeben oder gesperrt wird. Die enthaltenen Komponenten können über ein Interconnect-Fabric, das mit jeder der Komponenten verbunden ist, zwischenverbunden werden. Thread-Ausführungslogik 1800 kann eine oder mehrere Verbindungen zu Speicher, wie Systemspeicher oder Cache-Speicher, durch einen oder mehrere von Befehls-Cache 1806, Datenanschluss 1814, Sampler 1810 und Grafikausführungseinheiten 1808A-1808N aufweisen. Jede Ausführungseinheit (z.B. 1808A) kann eine eigenständige programmierbare Allzweckberechnungseinheit sein, die imstande ist, mehrere simultane Hardware-Threads während paralleler Verarbeitung mehrerer Datenelemente für jeden Thread auszuführen. In verschiedenen Ausführungsformen ist das Array von Ausführungseinheiten 1808A-1808N skalierbar, um eine beliebige Anzahl einzelner Ausführungseinheiten aufzuweisen.
  • In manchen Ausführungsformen können die Grafikausführungseinheiten 1808A-1808N vorwiegend zur Ausführung von Shader-Programmen verwendet werden. Ein Shader-Prozessor 1802 kann die verschiedenen Shader-Programme verarbeiten und Ausführungs-Threads, die mit den Shader-Programmen verknüpft sind, über einen Thread Dispatcher 1804 weiterleiten. Der Thread Dispatcher kann Logik aufweisen, um Thread-Einleitungsanfragen von den Grafik- und Medien-Pipelines zu schlichten und die angeforderten Threads auf einer oder mehreren Ausführungseinheiten in den Grafikausführungseinheiten 1808A-1808N zu instanziieren. Zum Beispiel kann eine Geometrie-Pipeline Vertex-, Tessellation- oder Geometrie-Shader zu der Thread-Ausführungslogik zur Verarbeitung weiterleiten. Optional kann der Thread Dispatcher 1804 auch Laufzeit-Thread-Auslagerungsanfragen von den ausführenden Shader-Programmen verarbeiten.
  • In manchen Ausführungsformen können die Grafikausführungseinheiten 1808A-1808N einen Befehlssatz unterstützen, der native Unterstützung für viele Standard-3D Grafik-Shader-Befehle aufweist, sodass Shader-Programme von Grafikbibliotheken (z.B. Direct 3D und OpenGL) mit minimaler Übersetzung ausgeführt werden. Die Ausführungseinheiten unterstützen Vertex- und Geometrieverarbeitung (z.B. Vertexprogramme, Geometrieprogramme, Vertex-Shader), Pixelverarbeitung (z.B. Pixel-Shader, Fragment-Shader) und Allzweckverarbeitung (z.B. Rechen- und Medien-Shader). Jede der Grafikausführungseinheiten 1808A-1808N ist zur Mehrfachausgabe einer Einzelbefehl, Mehrfachdaten- (SIMD) Ausführung imstande und Multi-Threading-Betriebe ermöglicht eine effiziente Ausführungsumgebung angesichts der Speicherzugriffe hoher Latenz. Jeder Hardware-Thread in jeder Ausführungseinheit hat eine dedizierte Registerdatei hoher Bandbreite und einen zugehörigen unabhängigen Thread-Zustand. Ausführung ist Mehrfachausgabe pro Takt an Pipelines, die zu Ganzzahl-, Einfach- und Doppelpräzisions-Gleitkommaoperationen, SIMD-Verzweigungskapazität, logischen Operationen, transzendentalen Operationen und anderen diversen Operationen imstande sind. Während auf Daten von Speicher oder einer der geteilten Funktionen gewartet wird, veranlasst Logik in den Ausführungseinheiten 1808A-1808N, das ein Warte-Thread schläft, bis die angeforderten Daten zurückgegeben wurden. Während der Warte-Thread schläft, können Hardwareressourcen der Verarbeitung anderer Threads gewidmet werden. Zum Beispiel kann während einer Verzögerung, die mit einer Vertex-Shader-Operation verknüpft ist, eine Ausführungseinheit Operationen für ein Pixel-Shader-, Fragment-Shader- oder eine andere Art von Shader-Programm durchführen, aufweisend einen anderen Vertex-Shader, wie Vertex-Shader 2107 veranschaulicht in 21. Verschiedene Ausführungsformen können anwendbar sein, um Ausführung durch Verwendung von Einzelbefehl, Mehrfach-Thread (SIMT) als eine Alternative zur Verwendung von SIMD oder zusätzlich zur Verwendung von SIMD zu verwenden. Ein Verweis 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 Grafikausführungseinheiten 1808A-1808N bearbeitet Arrays von Datenelementen. Die Anzahl von Datenelementen ist die „Ausführungsgröße“ oder die Anzahl von Kanälen für den Befehl. Ein Ausführungskanal ist eine logische Einheit einer Ausführung für Datenelementzugriff, Maskierung und Flusssteuerung in den Befehlen. Die Anzahl von Kanälen kann von der Anzahl von physischen Logischen Arithmetikeinheiten (ALUs), Gleitkommaeinheiten (FPUs) oder anderen Logikeinheiten (z.B. Tensor-Kerne, Strahlverfolgungskerne usw.) für einen bestimmten Grafikprozessor unabhängig sein. Zusätzlich können die Grafikausführungseinheiten 1808A-1808N Ganzzahl- und Gleitkommadatenarten unterstützen.
  • Der Ausführungseinheitsbefehlssatz weist SIMD-Befehle auf. Die verschiedenen Datenelemente können als eine gepackte Datenart in einem Register gespeichert sein und die Ausführungseinheit verarbeitet die verschiedenen Elemente basierend auf der Datengröße der Elemente. Wenn zum Beispiel ein 256-Bit breiter Vektor bearbeitet wird, werden die 256 Bits des Vektors in einem Register gespeichert und die Ausführungseinheit bearbeitet den Vektor wie vier separate 184-Bit gepackte Datenelemente (Quadwort (QW) große Datenelemente), acht separate 32-Bit gepackte Datenelemente (Doppelwort (DW) große Datenelemente), sechzehn separate 16-Bit gepackte Datenelemente (Wort (W) große Datenelemente) oder zweiunddreißig separate 8-Bit Datenelemente (Byte (B) große Datenelemente). Es sind jedoch verschiedene Vektorbreiten und Registergrößen möglich.
  • Optional können eine oder mehrere Ausführungseinheiten zu einer fusionierten Grafikausführungseinheit 1809A-1809N mit Thread-Steuerlogik (1807A-1807N) kombiniert werden, die den fusionierten EUs gemein sind. Mehrere EUs können zu einer EU-Gruppe fusioniert werden. Jede EU in der fusionierten EU-Gruppe kann konfiguriert sein, einen separaten SIMD-Hardware-Thread auszuführen. Die Anzahl von EUs in einer fusionierten EU-Gruppe kann gemäß Ausführungsformen variieren. Zusätzlich können verschiedene SIMD-Breiten pro EU durchgeführt werden, aufweisend, ohne aber darauf beschränkt zu sein, SIMD8, SIMD16 und SIMD32. Jede fusionierte Grafikausführungseinheit 1809A-1809N weist mindestens zwei Ausführungseinheiten auf. Zum Beispiel weist fusionierte Ausführungseinheit 1809A eine erste EU 1808A, zweite EU 1808B und Thread-Steuerlogik 1807A auf, die der ersten EU 1808A und der zweiten EU 1808B gemein ist. Die Thread-Steuerlogik 1807A steuert Threads, die auf der fusionierten Grafikausführungseinheit 1809A ausgeführt werden, wodurch jeder EU in den fusionierten Ausführungseinheiten 1809A-1809N möglich ist, unter Verwendung eines gemeinsamen Befehlszeigerregisters auszuführen.
  • Ein oder mehrerer interne Befehls-Caches (z.B. 1806) sind in der Thread-Ausführungslogik 1800 enthalten, um Thread-Befehle für die Ausführungseinheiten zwischenzuspeichern. Einer oder mehrere Daten-Caches (z.B. 1812) können in der Thread-Ausführungslogik 1800 enthalten sein, um Thread-Daten während Thread-Ausführung zwischenzuspeichern. Threads, die auf der Ausführungslogik 1800 laufen, können auch explizit verwaltete Daten in dem geteilten lokalen Speicher 1811 speichern. Ein Sampler 1810 kann enthalten sein, um Texturabtastung für 3 D-Operationen und Medienabtastung für Medienoperationen bereitzustellen. Sampler 1810 kann spezialisierte Textur- oder Medienabtastungsfunktionalität bereitstellen, um Textur- oder Mediendaten während des Abtastungsprozesses zu verarbeiten, bevor die abgetasteten Daten einer Ausführungseinheit bereitgestellt werden.
  • Während Ausführung senden die Grafik- und Medien-Pipelines Thread-Einleitungsanfragen an Thread-Ausführungslogik 1800 über Thread-Spawning und Dispatch-Logik. Sobald eine Gruppe geometrischer Objekte verarbeitet und in Pixeldaten gerastert ist, wird Pixelprozessorlogik (z.B. Pixel-Shader-Logik, Fragment-Shader-Logik usw.) im Shader-Prozessor 1802 aufgerufen, um weiter Ausgangsinformationen zu berechnen und zu veranlassen, dass Ergebnisse an Ausgangsflächen (z.B. Farbpuffer, Tiefenpuffer, Stencil-Puffer usw.) geschrieben werden. Ein Pixel-Shader oder Fragment-Shader kann die Werte der verschiedenen Vertexattribute berechnen, die über das gerasterte Objekt zu interpolieren sind. Die Pixelprozessorlogik im Shader-Prozessor 1802 kann dann ein Anwendungsprogrammierschnittstelle (API)-zugeleitetes Pixel- oder Fragment-Shader-Programm ausführen. Zur Ausführung des Shader-Programms leitet der Shader-Prozessor 1802 Threads über Thread Dispatcher 1804 zu einer Ausführungseinheit (z.B. 1808A) weiter. Shader-Prozessor 1802 kann Texturabtastlogik in dem Sampler 1810 verwenden, um auf Texturdaten in Texturkarten zuzugreifen, die im Speicher gespeichert sind. Arithmetische Operationen an den Texturdaten und den Geometrieeingangsdaten berechnen Pixelfarbdaten für jedes geometrische Fragment oder verwerfen ein oder mehrere Pixel aus der Weiterverarbeitung.
  • Zusätzlich kann der Datenanschluss 1814 einen Speicherzugriffsmechanismus für die Thread-Ausführungslogik 1800 bereitstellen, um verarbeitete Daten an den Speicher zur Weiterverarbeitung auf einer Grafikprozessorausgangs-Pipeline auszugeben. Der Datenanschluss 1814 kann einen oder mehrere Cache-Speicher (z.B. Daten-Cache 1812) aufweisen oder daran gekoppelt sein, um Daten für Speicherzugriff über den Datenanschluss 1814 zwischenzuspeichern.
  • Optional kann die Ausführungslogik 1800 auch einen Strahlverfolger 1805 aufweisen, der Strahlverfolgungsbeschleunigungsfunktionalität bereitstellen kann. Der Strahlverfolger 1805 kann einen Strahlverfolgungsbefehlssatz unterstützen, der Befehle/Funktionen für Strahlerzeugung aufweist. Der Strahlverfolgungsbefehlssatz kann dem Strahlverfolgungsbefehlssatz, der von den Strahlverfolgungskernen 372 in 3C unterstützt wird, ähnlich sein oder sich von diesem unterscheiden.
  • 18B veranschaulicht beispielhafte interne Einzelheiten einer Ausführungseinheit 1808. Eine Grafikausführungseinheit 1808 kann eine Befehlsabrufeinheit 1837, ein allgemeines Registerdatei-Array (GRF) 1824, ein architektonisches Registerdatei-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 Ganzzahl-SIMD ALUs 1835 aufweisen. Das GRF 1824 und ARF 1826 weisen den Satz von allgemeinen Registerdateien und architektonischen Registerdateien verknüpft mit jedem simultanen Hardware-Thread auf, der in der Grafikausführungseinheit 1808 aktiv sein kann. Pro Thread-architektonischer Zustand kann in dem ARF 1826 aufrechterhalten werden, während Daten, die während Thread-Ausführung verwendet werden, in dem GRF 1824 gespeichert sind. Der Ausführungszustand jedes Threads, aufweisend die Befehlszeiger für jeden Thread, kann in Thread-spezifischen Registern im ARF 1826 gehalten werden.
  • Die Grafikausführungseinheit 1808 kann eine Architektur haben, die eine Kombination von simultanem Multi-Threading (SMT) und fein körnigem verschachteltem Multi-Threading (IMT, Interleaved Multi-Threading) ist. Die Architektur kann eine modulare Konfiguration haben, die zum Zeitpunkt des Designs feinabgestimmt werden kann, basierend auf einer Zielanzahl simultaner Threads und Anzahl von Registern pro Ausführungseinheit, wo Ausführungseinheitsressourcen über Logik verteilt sind, die zum Ausführen mehrerer simultaner Threads verwendet werden. Die Anzahl von logischen Threads, die von der Grafikausführungseinheit 1808 ausgeführt werden kann, ist nicht auf die Anzahl von Hardware-Threads beschränkt und mehrere logische Threads können jedem Hardware-Thread zugewiesen sein.
  • Optional kann die Grafikausführungseinheit 1808 mehrere Befehle gemeinsam ausgeben, die jeweils verschiedene Befehle sein können. Der Thread-Arbiter 1822 des Grafikausführungseinheits-Threads 1808 kann die Befehle an eine der Sendeeinheit 1830, Verzweigungseinheit 1832 oder SIMD FPU(s) 1834 zur Ausführung weiterleiten. Jeder Ausführungs-Thread 128 kann auf Allzweckregister im GRF 1824 zugreifen, wo jedes Register 32 Bytes speichern kann, die als ein SIMD 8-Element Vektor von 32-Bit Datenelementen zugänglich sind. Jeder Ausführungseinheit Thread kann Zugriff auf 4 Kbytes im GRF 1824 haben, obwohl Ausführungsformen dahingehend nicht eingeschränkt sind und mehr oder weniger Registerressourcen in anderen Ausführungsformen bereitgestellt werden können. Die Grafikausführungseinheit 1808 kann in sieben Hardware-Threads getrennt sein, die unabhängig Berechnungsoperationen durchfü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 Kbytes zugreifen können, kann das GRF 1824 insgesamt 28 Kbytes speichern. In einer anderen beispielhaften Ausführungsform, wo 16 Threads auf 4Kbytes zugreifen können, kann das GRF 1824 insgesamt 64Kbytes speichern. Die Anzahl von Threads pro Ausführungseinheit ist jedoch nicht auf diese Beispiele beschränkt und kann mehr oder weniger als die angegebenen Anzahlen sein. Flexible Adressierungsmodi können erlauben, dass die Register gemeinsam adressiert werden, um effektiv breitere Register zu errichten oder weite rechteckige Blockdatenstrukturen bereitzustellen.
  • Zusätzlich oder alternativ können Speicheroperationen, Sampleroperationen und andere Systemkommunikationen längerer Latenz „Senden“-Befehle weitergeleitet werden, die durch die Nachrichtenweiterleitungssendeeinheit 1830 ausgeführt werden. Verzweigungsbefehle können an eine dedizierte Verzweigungseinheit 1832 weitergeleitet werden, um SIMD-Divergenz und schließlich Konvergenz zu erleichtern.
  • Die Grafikausführungseinheit 1808 kann eine oder mehrere SIMD-Gleitkommaeinheiten (FPU(s)) 1834 aufweisen, um Gleitkommaoperationen durchzuführen. Die FPU(s) 1834 können auch Ganzzahlberechnung unterstützen. In manchen Fällen können die FPU(s) 1834 bis zu einer M Anzahl von 32-Bit Gleitkomma-(oder Ganzzahl) Operationen SIMD-ausführen oder bis zu 2M 16-Bit Ganzzahl- oder 16-Bit Gleitkommaoperationen SIMD-ausführen. Optional stellt mindestens eine der FPU(s) erweiterte mathematische Kapazität bereit, um transzendentale mathematische Funktionen mit hohem Durchsatz und Doppelpräzisions-184-Bit Gleitkomma zu unterstützen. Ein Satz von 8-Bit Ganzzahl-SIMD ALUs 1835 kann auch vorhanden sein und kann im Speziellen optimiert sein, um Operationen durchzuführen, die mit Maschinenlernberechnungen verknüpft sind.
  • Optional können Arrays mehrerer Exemplare der Grafikausführungseinheit 1808 in einer Grafikteilkerngruppierung (z.B. einem Teil-Slice) instanziiert sein. Für Skalierbarkeit können Produktarchitekten die exakte Anzahl von Ausführungseinheiten pro Teilkerngruppierung auswählen. Die Ausführungseinheit 1808 kann Befehle über mehrere Ausführungskanäle ausführen. Zusätzlich kann jeder Thread, der auf der Grafikausführungseinheit 1808 ausgeführt wird, auf einem anderen Kanal ausgeführt werden.
  • 19 veranschaulicht eine weitere beispielhafte Ausführungseinheit 1900. Die Elemente von 19 mit denselben oder ähnlichen Bezeichnungen wie die Elemente einer beliebigen anderen Figur hierin, beschreiben dieselben Elemente wie in den anderen Figuren, können auf ähnliche Weise wie diese arbeiten oder funktionieren, können dieselben Komponenten aufweisen und können mit anderen Einheiten, wie jenen, die hier an anderer Stelle beschrieben sind, verbunden sein, sind aber als solche nicht eingeschränkt. Die Ausführungseinheit 1900 kann eine rechenoptimierte Ausführungseinheit zur Verwendung in, zum Beispiel einer Rechen-Engine-Kachel 1640A-1640D wie in 16C, sein, ist aber als solche nicht eingeschrä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 Befehlsabruf/- vorabrufeinheit 1903 und eine Befehlsdecodiereinheit 1904 aufweisen. Die Ausführungseinheit 1900 kann zusätzlich eine Registerdatei 1906 aufweisen, die Register speichert, die Hardware-Threads in der Ausführungseinheit zugewiesen werden können. Die Ausführungseinheit 1900 kann zusätzlich eine Sendeeinheit 1907 und eine Verzweigungseinheit 1908 aufweisen. Die Sendeeinheit 1907 und Verzweigungseinheit 1908 können ähnlich wie die Sendeeinheit 1830 und eine Verzweigungseinheit 1832 der Grafikausführungseinheit 1808 von 18B arbeiten.
  • Die Ausführungseinheit 1900 kann auch eine Recheneinheit 1910 aufweisen, die mehrere verschiedene Arten von Funktionseinheiten aufweist. Die Recheneinheit 1910 kann auch eine ALU 1911, ein systolisches Array 1912 und eine Math-Einheit 1913 aufweisen. Die ALU 1911 weist ein Array von Arithmetiklogikeinheiten auf. Die ALU 1911 kann konfiguriert sein, 64-Bit, 32-Bit und 16-Bit Ganzzahl- und Gleitkommaoperationen über mehrere Verarbeitungsbahnen und Datenkanäle und für mehrere Hardware- und/oder Software-Threads durchzuführen. Die ALU 1911 kann Ganzzahl- und Gleitkommaoperationen simultan (z.B. in demselben Taktzyklus) durchführen.
  • Das systolische Array 1912 weist ein W breites und D tiefes Netzwerk von Datenverarbeitungseinheiten auf, die verwendet werden können, um Vektor- oder andere Daten-parallele Operationen in systolischer Weise durchzuführen. Das systolische Array 1912 kann konfiguriert sein, verschiedene Matrixoperationen durchzuführen, aufweisend Skalarprodukt-, Außenprodukt- und allgemeine Matrix-Matrixmultiplikations- (GEMM) Operationen. Das systolische Array 1912 kann 16-Bit Gleitkommaoperationen, wie auch 8-Bit, 4-Bit, 2-Bit und binäre Ganzzahloperationen unterstützen. Das systolische Array 1912 kann konfiguriert sein, Maschinenlernoperationen zu beschleunigen. Das systolische Array 1912 kann mit Unterstützung für bfloat16, (Brain-Gleitkomma) 16-Bit Gleitkommaformat oder ein Tensor-Gleit-32-Bit Gleitkommaformat (TF32) konfiguriert sein, die verschiedene Anzahlen von Mantissen- und Exponenten-Bits relativ zu Institute of Electrical and Electronics Engineers (IEEE) 754 Formaten haben. FP64 Formate können auch unterstützt werden.
  • In einer Ausführungsform weist das systolische Array 1912 Hardware zum Beschleunigen von Sparse-Matrixoperationen auf. Multiplikationsoperationen für Sparse-Gebiete von Eingangsdaten können umgangen werden, ohne Durchsatz zu opfern. BlockDünnbesetztheit in Eingangsmatrizen kann erfasst werden und Operationen mit bekannten Ausgangswerten können umgangen werden. In einer Ausführungsform weist das systolische Array 1912 Hardware auf, um Operationen an spärlichen Daten mit einer komprimierten Darstellung zu ermöglichen. Eine komprimierte Darstellung einer Sparse-Matrix speichert Nicht-Null-Werte und Metadaten, die die Position der Nicht-Null-Werte in der Matrix definieren. Beispielhafte komprimierte Darstellungen weisen, ohne aber darauf beschränkt zu sein, komprimierte Tensordarstellungen wie komprimierte Sparse-Reihe- (CSR), komprimierte Sparse-Spalte- (CSC), komprimierte Sparse-Faser- (CSF) Darstellungen auf. Unterstützung für komprimierte Darstellungen ermöglicht, dass Operationen an Eingang in einem komprimierten Tensorformat durchgeführt werden, ohne die komprimierte Darstellung dekomprimieren oder decodieren zu müssen. In einer solchen Ausführungsform können Operationen nur an Nicht-Null-Eingangswerten durchgeführt werden und die resultierenden Nicht-Null-Ausgangswerte können in eine Ausgangsmatrix abgebildet werden. In manchen Ausführungsformen ist Hardwareunterstützung auch für maschinenspezifische verlustlose Datenkompressionsformate bereitgestellt, die verwendet werden, wenn Daten in Hardware oder über Systembusse übertragen werden. Solche Daten können in einem komprimierten Format für Sparse-Eingangsdaten gehalten werden und das systolische Array 1912 kann die Kompressionsmetadaten für die komprimierten Daten verwenden, um zu ermöglichen, dass Operationen an nur Nicht-Null-Werten durchgeführt werden, oder um zu ermöglichen, dass Blöcke von Null-Dateneingang für Multiplikationsoperationen umgangen werden.
  • Die Math-Einheit 1913 kann konfiguriert sein, einen bestimmten Teilsatz mathematischer Operationen auf effiziente und leistungsärmere Weise durchzuführen als die ALU Einheit 1911. Die Math-Einheit 1913 kann Math-Logik aufweisen, die in geteilter Funktionslogik einer Grafikverarbeitungs-Engine vorgefunden wird, die von anderen beschriebenen Ausführungsformen bereitgestellt wird, wie z.B. die Math-Logik 1722 der geteilten Funktionslogik 1720 von 17. Die Math-Einheit 1913 kann konfiguriert sein, 32-Bit und 64-Bit Gleitkommaoperationen durchzuführen.
  • Die Thread-Steuereinheit 1901 weist Logik zum Steuern der Ausführung von Threads in der Ausführungseinheit auf. Die Thread-Steuereinheit 1901 kann Thread-Schlichtungslogik aufweisen, um Ausführung von Threads in der Ausführungseinheit 1900 zu starten, zu stoppen und vorwegzunehmen. Die Thread-Zustandseinheit 1902 kann verwendet werden, um Thread-Zustand für Threads zu speichern, die zur Ausführung an der Ausführungseinheit 1900 zugewiesen sind. Speichern des Thread-Zustands in der Ausführungseinheit 1900 ermöglicht die rasche Vorwegnahme von Threads, wenn diese Threads blockiert werden oder leerlaufen. Die Befehlsabruf/- vorabrufeinheit 1903 kann Befehle aus einem Befehls-Cache einer Ausführungslogik höherer Ebene abrufen (z.B. Befehls-Cache 1806 wie in 18A). Die Befehlsabruf/- vorabrufeinheit 1903 kann auch Vorabrufanfragen für Befehle ausgeben, die in den Befehls-Cache zu laden sind, basierend auf einer Analyse derzeit laufender Threads. Die Befehlsdecodiereinheit 1904 kann verwendet werden, Befehle zu decodieren, die von den Recheneinheiten auszuführen sind. Die Befehlsdecodiereinheit 1904 kann als ein sekundärer Decodierer verwendet werden, um komplexe Befehle in konstituierende Mikrooperationen zu decodieren.
  • Die Ausführungseinheit 1900 weist zusätzlich eine Registerdatei 1906 auf, die von Hardware-Threads verwendet werden kann, die auf der Ausführungseinheit 1900 laufen. Register in der Registerdatei 1906 können über die Logik verteilt werden, die verwendet wird, um mehrere simultane Threads in der Recheneinheit 1910 der Ausführungseinheit 1900 auszuführen. Die Anzahl von logischen Threads, die von der Grafikausführungseinheit 1900 ausgeführt werden kann, ist nicht auf die Anzahl von Hardware-Threads beschränkt und es können mehrere logische Threads jedem Hardware-Thread zugewiesen sein. Die Größe der Registerdatei 1906 kann über Ausführungsformen basierend auf der Anzahl unterstützter Hardware-Threads variieren. Registerumbenennung kann verwendet werden, um Register dynamisch zu Hardware-Threads zuzuordnen.
  • 20 ist ein Blockdiagramm, das Grafikprozessorbefehlsformat 2000 veranschaulicht. Die Grafikprozessorausführungseinheiten unterstützen einen Befehlssatz mit Befehlen in mehreren Formaten, die Volllinienkästen veranschaulichen die Komponenten, die im Allgemeinen in einem Ausführungseinheitsbefehl enthalten sind, während die gestrichelten Linien Komponenten aufweisen, die optional sind oder die nur in einem Teilsatz der Befehle enthalten sind. In manchen Ausführungsformen ist das beschriebene und veranschaulichte Grafikprozessorbefehlsformat 2000 Makrobefehle, da es Befehle sind, die der Ausführungseinheit zugeleitet werden, im Gegensatz zu Mikrooperationen, die aus Befehlsdecodierung resultieren, sobald der Befehl verarbeitet ist. Somit kann ein einzelner Befehle Hardware veranlassen, mehrere Mikrooperationen durchzuführen.
  • Die Grafikprozessorausführungseinheiten, wie hier beschrieben, können nativ Befehle in einem 128-Bit Befehlsformat 2010 unterstützen. Ein 64-Bit verdichtetes Befehlsformat 2030 ist für manche Befehle basierend auf dem gewählten Befehl, Befehlsoptionen und Anzahl von Operanden verfügbar. Das native 128-Bit Befehlsformat 2010 stellt Zugriff zu allen Befehlsoptionen bereit, während manche Optionen und Operationen im 64-Bit Format 2030 beschränkt sind. Die nativen Befehle, die im 64-Bit Format 2030 verfügbar sind, variieren nach Ausführungsform. Der Befehl wird teilweise unter Verwendung eines Satzes von Indexwerten in einem Indexfeld 2013 verdichtet. Die Ausführungseinheitshardware nimmt basierend auf den Indexwerten auf einen Satz von Verdichtungstabellen Bezug, und verwendet die Verdichtungstabellenausgänge zum Rekonstruieren eines nativen Befehls im 128-Bit Befehlsformat 2010. Es können andere Größen und Formate eines Befehls verwendet werden.
  • Für jedes Format, definiert Befehls-Opcode 2012 die Operation, die die Ausführungseinheit durchführen soll. Die Ausführungseinheiten führen jeden Befehl parallel über die mehreren Datenelemente jedes Operanden aus. Zum Beispiel führt die Ausführungseinheit in Antwort auf einen Additionsbefehl eine simultane Additionsoperation über jeden Farbkanal aus, der ein Texturelement oder Bildelement darstellt. Laut Vorgabe führt die Ausführungseinheit jeden Befehl über alle Datenkanäle der Operanden aus. Befehlssteuerfeld 2014 kann Steuerung über gewisse Ausführungsoptionen ermöglichen, wie Kanalauswahl (z.B. Aussage) und Datenkanalreihenfolge (z.B. Swizzle). Für Befehle im 128-Bit Befehlsformat 2010 begrenzt ein Ausführungsgrößenfeld 2016 die Anzahl an Datenkanälen, die parallel ausgeführt werden. Ein Ausführungsgrößenfeld 2016 könnte nicht zur Verwendung im 64-Bit Kompaktbefehlsformat 2030 zur Verfügung stehen.
  • Manche Befehle der Ausführungseinheit haben bis zu drei Operanden, enthaltend zwei Quellenoperanden, src0 2020, src1 2022 und einen Zielort 2018. die Ausführungseinheiten können duale Zielortbefehle unterstützen, wo einer der Zielorte impliziert ist. Datenmanipulationsbefehle können einen dritten Quellenoperanden (z.B. SRC2 2024) haben, wo der Befehls-Opcode 2012 die Anzahl an Quellenoperanden bestimmt. Ein letzter Quellenoperand eines Befehls kann ein unmittelbarer (z.B. hartcodierter) Wert sein, der mit dem Befehl weitergeleitet wird.
  • Das 128-Bit Befehlsformat 2010 kann ein Zugriffs-/Adressenmodusfeld 2026 aufweisen, das zum Beispiel spezifiziert, ob direkter Registeradressierungsmodus oder indirekter Registeradressierungsmodus verwendet wird. Wenn direkter Registeradressierungsmodus verwendet wird, werden die Registeradressen eines oder mehrerer Operanden direkt durch Bits in dem Befehl bereitgestellt.
  • Das 128-Bit Befehlsformat 2010 kann auch ein Zugriffs-/Adressenmodusfeld 2026 aufweisen, das einen Adressenmodus und/oder einen Zugriffsmodus für den Befehl spezifiziert. Der Zugriffsmodus kann verwendet werden, um eine Datenzugriffsausrichtung für den Befehl zu definieren. Zugriffsmodi, die einen 16-Byte ausgerichteten Zugriffsmodus und einen 1-Byte ausgerichteten Zugriffsmodus aufweisen, können unterstützt werden, wo die Byte-Ausrichtung des Zugriffsmodus die Zugriffsausrichtung der Befehlsoperanden unterstützt. Wenn zum Beispiel in einem ersten Modus der Befehl Byte-ausgerichtete Adressierung für Quellen- und Zielortoperanden verwenden kann und wenn in einem zweiten Modus der Befehl 16-Byte-ausgerichtete Adressierung für alle Quellen- und Zielortoperanden verwenden kann.
  • Der Adressenmodusabschnitt des Zugriffs-/Adressenmodusfelds 2026 kann bestimmen, ob der Befehl direkte oder indirekte Adressierung verwenden soll. Wenn direkter Registeradressierungsmodus verwendet wird, stellen Bits in dem Befehl direkt die Registeradressen eines oder mehrerer Operanden bereit. Wenn indirekter Registeradressierungsmodus verwendet wird, kann die Registeradresse eines oder mehrerer Operanden basierend auf einem Adressenregisterwert und einem unmittelbaren Adressenfeld in dem Befehl berechnet werden.
  • Befehle können basierend auf Opcode 2012 Bit-Feldern gruppiert sein, um Opcode-Decodierung 2040 zu erleichtern. Für einen 8-Bit Opcode, erlauben Bits 4, 5 und 6 der Ausführungseinheit, die Art von Opcode zu bestimmen. Die genaue dargestellte Opcode-Gruppierung ist nur ein Beispiel. Eine Bewegungs- und Logik-Opcode Gruppe 2042 kann Datenbewegungs- und Logikbefehle (z.B. Bewegen (mov), Vergleichen (cmp)) aufweisen. Die Bewegungs- und Logikgruppe 2042 kann die fünf niedrigstwertigen Bits (LSB) teilen, wo Bewegungsbefehle (mov) die Form von 0000xxxxb aufweisen und Logikbefehle die Form von 0001xxxxb aufweisen. Eine Durchflusssteuerbefehlsgruppe 2044 (z.B. Sprung (jmp)) weist Befehle in der Form von 0010xxxxb (z.B. 0x20) auf. Eine Diverse-Befehlsgruppe 2046 weist eine Mischung von Befehlen auf, enthaltend Synchronisierungsbefehle (z.B. Warten, Senden) in der Form von 0011xxxxb (z.B. 0x30). Eine parallele Math-Befehlsgruppe 2048 weist komponentenweise arithmetische Befehle (z.B. Addieren, Multiplizieren (mul)) in der Form von 0100xxxxb (z.B. 0x40) auf. Die parallele Math-Gruppe 2048 führt die arithmetischen Operationen parallel über Datenkanäle aus. Die Vektormathematikgruppe 2050 weist arithmetische Befehle (z.B. dp4) in der Form von 0101xxxxb (z.B. 0x50) auf. Die Vektor-Math-Gruppe führt Arithmetik wie Skalarproduktberechnungen an Vektoroperanden durch. Die veranschaulichte Opcode-Decodierung 2040 kann in einer Ausführungsform zum Bestimmen verwendet werden, welcher Abschnitt einer Ausführungseinheit zum Ausführen eines decodierten Befehls verwendet wird. Zum Beispiel können manche Befehle als systolische Befehle bezeichnet werden, die durch ein systolisches Array durchgeführt werden. Andere Befehle, wie Strahlverfolgungsbefehle (nicht dargestellt) können zu einem Strahlverfolgungskern oder einer Strahlverfolgungslogik in einem Slice oder einer Abtrennung von Ausführungslogik geleitet werden.
  • Grafik-Pipeline
  • 21 ist ein Blockdiagramm von Grafikprozessor 2100, gemäß einer anderen Ausführungsform. Die Elemente von 21 mit denselben oder ähnlichen Bezeichnungen wie die Elemente einer beliebigen anderen Figur hierin, beschreiben dieselben Elemente wie in den anderen Figuren, können auf ähnliche Weise wie diese arbeiten oder funktionieren, können dieselben Komponenten aufweisen und können mit anderen Einheiten, wie jenen, die hier an anderer Stelle beschrieben sind, verbunden sein, sind aber als solche nicht eingeschränkt.
  • Der Grafikprozessor 2100 kann verschiedene Arten von Grafikverarbeitungs-Pipelines, wie eine Geometrie-Pipeline 2120, eine Medien-Pipeline 2130, eine Anzeige-Engine 2140, Thread-Ausführungslogik 2150 und eine Render-Ausgang-Pipeline 2170 aufweisen. Grafikprozessor 2100 kann ein Grafikprozessor in einem Mehrfachkernverarbeitungssystem sein, das einen oder mehrere Allzweckverarbeitungskerne aufweist. Der Grafikprozessor kann durch Registerschriebe zu einem oder mehreren Steuerregistern (nicht dargestellt) oder über Steuerbefehle gesteuert werden, die an Grafikprozessor 2100 über ein Ring-Interconnect 2102 ausgegeben werden. Ring-Interconnect 2102 kann Grafikprozessor 2100 an andere Verarbeitungskomponenten, wie andere Grafikprozessoren oder Allzweckprozessoren, koppeln. Steuerbefehle vom Ring-Interconnect 2102 werden durch einen Steuerbefehl-Streamer 2103 interpretiert, der Befehle zu einzelnen Komponenten der Geometrie-Pipeline 2120 oder der Medien-Pipeline 2130 leitet.
  • Steuerbefehl-Streamer 2103 kann den Betrieb eines Vertex-Fetchers 2105 lenken, der Vertexdaten aus Speicher liest und Vertex-Verarbeitungssteuerbefehle liest, die durch den Steuerbefehl-Streamer 2103 bereitgestellt werden. Der Vertex-Fetcher 2105 kann einem Vertex-Shader 2107 Vertexdaten bereitstellen, der Koordinatenraumtransformation und Beleuchtungsoperationen an jedem Vertex durchführt. Vertex-Fetcher 2105 und Vertex-Shader 2107 können Vertex-Verarbeitungsbefehle durch Weiterleiten von Ausführungs-Threads zu Ausführungseinheiten 2152A-2152B über einen Thread Dispatcher 2131 ausführen.
  • Die Ausführungseinheiten 2152A-2152B können ein Array von Vektorprozessoren mit einem Befehlssatz zum Durchführen von Grafik- und Medienoperationen sein. Die Ausführungseinheiten 2152A-2152B können einen angehängten L1 Cache 2151 haben, der für jedes Array bestimmt oder zwischen den Arrays geteilt ist. Der Cache kann als ein Daten-Cache, ein Befehls-Cache oder ein einzelner Cache konfiguriert sein, der abgetrennt ist, um Daten und Befehle in verschiedenen Abtrennungen zu enthalten.
  • Eine Geometrie-Pipeline 2120 kann Tessellationskomponenten aufweisen, um Hardware-beschleunigte Tessellation von 3D-Objekten durchzuführen. Ein programmierbarer Hull-Shader 2111 kann die Tessellationsoperationen konfigurieren. Ein programmierbarer Domänen-Shader 2117 kann Backendauswertung von Tessellationsausgang bereitstellen. Ein Tessellator 2113 kann auf Anweisung von Hull-Shader 2111 arbeiten und Spezialzwecklogik aufweisen, um einen Satz detaillierter geometrischer Objekte basierend auf einem groben geometrischen Modell zu erzeugen, das als Eingang zu Geometrie-Pipeline 2120 bereitgestellt ist. Zusätzlich, wenn keine Tessellation verwendet wird, können Tessellationskomponenten (z.B. Hull-Shader 2111, Tessellator 2113 und Domänen-Shader 2117) umgangen werden. Die Tessellationskomponenten können basierend auf Daten arbeiten, die vom Vertex-Shader 2107 empfangen werden.
  • Vollständige geometrische Objekte können durch einen Geometrie-Shader 2119 über einen oder mehrere Threads verarbeitet werden, die den Ausführungseinheiten 2152A-2152B zugeleitet werden, oder können direkt mit dem Clipper 2129 fortfahren. Der Geometrie-Shader kann an vollständigen geometrischen Objekten und nicht an Vertizes oder Teilen von Vertizes arbeiten, wie in früheren Stufen der Grafik-Pipeline. Wenn die Tessellation gesperrt ist, empfängt der Geometrie-Shader 2119 Eingang vom Vertex-Shader 2107. Der Geometrie-Shader 2119 kann durch ein Geometrie-Shader-Programm programmierbar sein, um Geometrietessellation durchzuführen, wenn die Tessellationseinheiten gesperrt sind
  • Vor Rasterung verarbeitet ein Clipper 2129 Vertexdaten. Der Clipper 2129 kann ein Clipper fester Funktion oder ein programmierbarer Clipper mit Zuschneide- und Geometrie-Shader-Funktionen sein. Eine Rasterungs- und Tiefentestkomponente 2173 in der Renderausgang-Pipeline 2170 kann Pixel-Shader weiterleiten, um die geometrischen Objekte in Pro-Pixel-Darstellungen umzuwandeln. Die Pixel-Shader-Logik kann in Thread-Ausführungslogik 2150 enthalten sein. Optional kann eine Anwendung die Rasterungs- und Tiefentestkomponente 2173 umgehen und auf ungerasterte Vertexdaten über eine Ausströmungseinheit 2123 zugreifen
  • Der Grafikprozessor 2100 hat einen Interconnect-Bus, ein Interconnect-Fabric oder einen anderen Interconnect-Mechanismus, der erlaubt, dass Daten und Nachricht unter den Hauptkomponenten des Prozessors weitergeleitet werden. In manchen Ausführungsformen sind Ausführungseinheiten 2152A-2152B und zugehörige Logikeinheiten (z.B.L1 Cache 2151, Sampler 2154, Textur Cache 2158 usw.) über einen Datenanschluss 2156 miteinander verbunden, um Speicherzugriff durchzuführen und mit Renderausgang-Pipeline-Komponenten des Prozessors zu kommunizieren. Ein Sampler 2154, Caches 2151, 2158 und Ausführungseinheiten 2152A-2152B können jeweils separate Speicherzugriffspfade haben. Der Textur-Cache 2158 kann optional auch als ein Sampler- Cache konfiguriert sein.
  • Die Renderausgang-Pipeline 2170 kann eine Rasterungs- und Tiefentestkomponente 2173 aufweisen, die vertexbasierte Objekte in eine zugeordnete pixelbasierte Darstellung umwandelt. Die Rasterungslogik kann eine Fensterungs-/Maskierungseinheit aufweisen, um Festfunktions-Dreieck- und Linienrasterung durchzuführen. Ein zugehöriger Render-Cache 2178 und Tiefen-Cache 2179 stehen auch in manchen Ausführungsformen zur Verfügung. Eine Pixeloperationskomponente 2177 führt pixelbasierte Operationen an den Daten durch, obwohl in manchen Fällen Pixeloperationen, die mit 2D-Operationen verknüpft sind (z.B. Bit-Blockbildtransfers mit Überblenden) durch die 2D-Einheit 2141 durchgeführt oder zur Anzeigezeit durch die Anzeigesteuerung 2143 unter Verwendung von Überlagerungsanzeigeebenen ersetzt werden. Ein geteilter L3 Cache 2175 kann für alle Grafikkomponenten verfügbar sein, der die geteilte Nutzung von Daten ohne Verwendung von Hauptsystemspeicher erlaubt.
  • Die Medien-Pipeline 2130 kann eine Medien-Engine 2137 und ein Video-Frontend 2134 aufweisen. Video-Frontend 2134 kann Pipeline-Steuerbefehle von dem Steuerbefehl-Streamer 2103 empfangen. Medien-Pipeline 2130 kann einen separaten Steuerbefehl-Streamer aufweisen. Video-Frontend 2134 kann Mediensteuerbefehle vor Senden des Steuerbefehls an die Medien-Engine 2137 verarbeiten. Medien-Engine 2137 kann Thread-Auslagerungsfunktionalität aufweisen, um Threads zur Weiterleitung an Thread-Ausführungslogik 2150 über Thread Dispatcher 2131 auszulagern
  • Grafikprozessor 2100 kann eine Anzeige-Engine 2140 aufweisen. Diese Anzeige-Engine 2140 kann extern von Prozessor 2100 und mit dem Grafikprozessor über das Ring-Interconnect 2102 oder einen anderen Interconnect-Bus oder ein anderes Fabric gekoppelt sein. Anzeige-Engine 2140 kann eine 2D-Engine 2141 und eine Anzeigesteuerung 2143 aufweisen. Anzeige-Engine 2140 kann Spezialzwecklogik aufweisen, die imstande ist, unabhängig von der 3D-Pipeline zu arbeiten. Anzeigesteuerung 2143 kann mit einer Anzeigevorrichtung (nicht dargestellt) gekoppelt sein, die eine systemintegrierte Anzeigevorrichtung wie in einem Laptop Computer oder eine externe Anzeigevorrichtung, die über einen Anzeigevorrichtungsstecker verbunden ist, sein kann.
  • Die Geometrie-Pipeline 2120 und Medien-Pipeline 2130 können konfigurierbar sein, um Operationen basierend auf mehreren Grafik- und Medienprogrammierungsschnittstellen durchzuführen, und sind nicht für eine einzige Anwendungsprogrammierungsschnittstelle (API) spezifisch. Eine Treibersoftware für den Grafikprozessor kann API-Anrufe, die für eine bestimmte Grafik- oder Medienbibliothek spezifisch sind, in Steuerbefehle übersetzen, die von dem Grafikprozessor verarbeitet werden können. Unterstützung kann für die Open Graphics Library (OpenGL), Open Computing Language (OpenCL) und/oder Vulkan Grafik und Berechnungs-API, alle von der Khronos Group, bereitgestellt sein. Unterstützung kann auch für die Direct3D Bibliothek von der Firma Microsoft bereitgestellt sein. Eine Kombination dieser Bibliotheken kann unterstützt werden. Unterstützung kann auch für die Open Source Computer Vision Library (OpenCV) bereitgestellt sein. Eine zukünftige API mit einer kompatiblen 3D-Pipeline würde auch unterstützt werden, wenn eine Abbildung aus der Pipeline der zukünftigen API auf die Pipeline des Grafikprozessors vorgenommen werden kann
  • Grafik-Pipeline-Programmierung
  • 22A ist ein Blockdiagramm, das ein Grafikprozessorsteuerbefehlsformat 2200 veranschaulicht, das zum Programmmieren von Grafikverarbeitungs-Pipelines verwendet wird, wie zum Beispiel die hier in Verbindung mit 16A, 17, 21 beschriebenen Pipelines. 22B ist ein Blockdiagramm, das eine Grafikprozessorsteuerbefehlsabfolge 2210 gemäß einer Ausführungsform veranschaulicht. Die Volllinienkästen in 22A veranschaulichen die Komponenten, die im Allgemeinen in einem Grafiksteuerbefehl enthalten sind, während die gestrichelten Linien Komponenten aufweisen, die optional sind oder die nur in einem Teilsatz der Grafiksteuerbefehle enthalten sind. Das beispielhafte Grafikprozessorsteuerbefehlsformat 2200 von 22A weist Datenfelder zum Identifizieren eines Clients 2202, eines Steuerbefehls Operationscodes (opcode) 2204 und Daten 2206 für den Steuerbefehl auf. Ein Teil-Opcode 2205 und eine Steuerbefehlsgröße 2208 sind auch in manchen Steuerbefehlen enthalten.
  • Client 2202 kann die Clienteinheit der Grafikvorrichtung spezifizieren, die die Steuerbefehlsdaten verarbeitet. Ein Grafikprozessor-Steuerbefehlsparser kann das Client-Feld jedes Steuerbefehls untersuchen, um die Weiterverarbeitung des Steuerbefehls festzulegen und die Steuerbefehlsdaten zu der passenden Client-Einheit zu leiten. Die Grafikprozessor Client-Einheiten können eine Speicherschnittstelleneinheit, eine Render-Einheit, eine 2D-Einheit, eine 3D-Einheit und eine Medieneinheit aufweisen. Jede Client-Einheit kann eine entsprechende Verarbeitungs-Pipeline haben, die die Steuerbefehle verarbeitet. Sobald der Steuerbefehl von der Client-Einheit empfangen wird, liest die Client-Einheit den Opcode 2204 und, falls vorhanden, den Teil-Opcode 2205, um die durchzuführende Operation zu bestimmen. Die Client-Einheit führt den Steuerbefehl unter Verwendung von Informationen im Datenfeld 2206 aus. Für manche Steuerbefehle wird erwartet, dass eine explizite Steuerbefehlsgröße 2208 die Größe des Steuerbefehls spezifiziert. Der Steuerbefehlsparser kann automatisch die Größe mindestens mancher der Steuerbefehle basierend auf dem Steuerbefehl-Opcode bestimmen. Steuerbefehle können über Vielfache eines Doppelworts ausgerichtet werden. Andere Steuerbefehlsformate können auch verwendet werden.
  • Das Ablaufdiagramm in 22B veranschaulicht eine beispielhafte Grafikprozessorsteuerbefehlsabfolge 2210. Software oder Firmware eines Datenverarbeitungssystems, das einen beispielhaften Grafikprozessor aufweist, kann eine Version der Steuerbefehlsabfolge verwenden, die dargestellt ist, um einen Satz von Grafikoperationen einzurichten, auszuführen und abzuschließen. Eine beispielhafte Steuerbefehlsabfolge ist nur als Beispiel dargestellt und beschrieben, da Ausführungsformen nicht auf diese spezifischen Steuerbefehle oder auf diese Steuerbefehlsabfolge beschränkt sind. Überdies können die Steuerbefehle als Stapel von Steuerbefehlen in einer Steuerbefehlsabfolge ausgegeben werden, sodass der Grafikprozessor die Abfolge von Steuerbefehlen in mindestens teilweiser Gleichzeitigkeit ausführt.
  • Die Grafikprozessorsteuerbefehlsabfolge 2210 kann mit einem Pipeline-Spülungssteuerbefehl 2212 beginnen, um zu veranlassen, dass jede aktive Grafik-Pipeline die derzeit anstehenden Steuerbefehle für die Pipeline abschließt. Optional können die 3D-Pipeline 2222 und die Medien-Pipeline 2224 nicht gleichzeitig arbeiten. Die Pipeline-Spülung wird durchgeführt, um die aktive Grafik-Pipeline zu veranlassen, sämtliche anstehenden Steuerbefehle abzuschließen. In Antwort auf eine Pipeline-Spülung pausiert der Steuerbefehlsparser für den Grafikprozessor Steuerbefehlsverarbeitung, bis die aktiven Zeichnungseinheiten anstehende Operationen abschließen und die relevanten Lese-Caches auf ungültig gesetzt werden. Optional können sämtliche Daten im Render-Cache, die als ‚schmutzig‘ markiert sind, zum Speicher gespült werden. Optional kann Pipeline-Spülungssteuerbefehl 2212 zur Pipeline-Synchronisierung oder vor Platzieren des Grafikprozessors in einen Niederleistungszustand verwendet werden.
  • Ein Pipeline-Auswahlsteuerbefehl 2213 kann verwendet werden, wenn eine Steuerbefehlsabfolge erfordert, dass der Grafikprozessor explizit zwischen Pipelines umschaltet. Ein Pipeline Auswahlsteuerbefehl 2213 kann nur einmal in einem Ausführungskontext erforderlich sein, bevor Pipelinesteuerbefehle ausgegeben werden, wenn der Kontext nicht ist, Steuerbefehle für beide Pipelines auszugeben. Ein Pipeline-Spülungssteuerbefehl 2212 kann unmittelbar vor einem Umschalten der Pipeline über den Pipeline-Auswahlsteuerbefehl 2213 erforderlich sein.
  • Ein Pipeline-Steuerbefehl 2214 kann eine Grafik-Pipeline für einen Betrieb konfigurieren und kann zum Programmieren der 3D-Pipeline 2222 und der Medien-Pipeline 2224 verwendet werden. Der Pipeline-Steuerbefehl 2214 kann den Pipeline-Zustand für die aktive Pipeline konfigurieren. Der Pipeline-Steuerbefehl 2214 kann zur Pipeline-Synchronisierung und zum Löschen von Daten aus einem oder mehreren Cache-Speichern in der aktiven Pipeline vor Verarbeitung eines Stapels von Steuerbefehlen verwendet werden.
  • Steuerbefehle, die sich auf den Rückgabepufferzustand 2216 beziehen, können zum Konfigurieren eines Satzes von Rückgabepuffern für die jeweiligen Pipelines verwendet werden, um Daten zu schreiben. Manche Pipeline-Operationen erfordern die Zuordnung, Auswahl oder Konfiguration eines oder mehrerer Rückgabepuffer, in die die Operationen Zwischendaten während Verarbeitung schreiben. Der Grafikprozessor kann auch einen oder mehrere Rückgabepuffer verwenden, um Ausgangsdaten zu speichern und Kreuz-Thread-Kommunikation durchzuführen. Der Rückgabepufferzustand 2216 kann Auswählen der Größe und Anzahl von Rückgabepuffern aufweisen, die für einen Satz von Pipeline-Operationen zu verwenden sind.
  • Die verbleibenden Steuerbefehle in der Steuerbefehlsabfolge unterscheiden sich basierend auf der aktiven Pipeline für Operationen. Basierend auf einer Pipeline-Bestimmung 2220 wird die Steuerbefehlsabfolge auf die 3D-Pipeline 2222, beginnend mit dem 3D-Pipeline-Zustand 2230 oder die Medien-Pipeline 2224. beginnend mit dem Medien-Pipeline-Zustand 2240 abgestimmt.
  • Die Steuerbefehle zum Konfigurieren des 3D-Pipeline-Zustands 2230 weisen 3D-Zustandseinstellungsteuerbefehle für Vertexpufferzustand, Vertexelementzustand, konstanten Farbzustand, Tiefenpufferzustand und andere Zustandsvariable auf, die zu konfigurieren sind, bevor 3D-Primitive-Steuerbefehle verarbeitet werden. Die Werte dieser Steuerbefehle werden mindestens teilweise basierend auf der besonderen 3D API in Verwendung bestimmt. Die 3D-Pipeline-Zustands- 2230 Steuerbefehle können auch imstande sein, selektiv gewisse Pipeline-Elemente zu sperren oder zu umgehen, wenn diese Elemente nicht verwendet werden.
  • Ein 3D-Primitive 2232 Steuerbefehl kann verwendet werden, um 3D-Primitive zu unterbreiten, die von der 3D-Pipeline verarbeitet werden sollen. Steuerbefehle und verknüpfte Parameter, die zu dem Grafikprozessor über den 3D-Primitive 2232 Steuerbefehl geleitet werden, werden zu der Vertex-Abruffunktion in der Grafik-Pipeline weitergeleitet. Die Vertex-Abruffunktion verwendet die 3D-Primitive 2232 Steuerbefehlsdaten zum Erzeugen von Vertexdatenstrukturen. Die Vertexdatenstrukturen werden in einem oder mehreren Rückgabepuffern gespeichert. Der 3D-Primitive 2232 Steuerbefehl kann verwendet werden, um Vertexoperationen an 3D-Primitiven über Vertex-Shader durchzuführen. Zur Verarbeitung von Vertex-Shader leitet 3D-Pipeline 2222 Shader-Ausführungs-Threads zu Grafikprozessorausführungseinheiten.
  • Die 3D-Pipeline 2222 kann über einen Ausführungs- 2234 Steuerbefehl oder ein Ereignis ausgelöst werden. Ein Registerschrieb kann eine Steuerbefehlsausführung auslösen. Ausführung kann über einen ‚go‘ oder ‚kick‘ Steuerbefehl in der Steuerbefehlsabfolge ausgelöst werden. Steuerbefehlsausführung kann unter Verwendung eines Pipeline-Synchronisierungssteuerbefehls ausgelöst werden, um die Steuerbefehlsabfolge durch die Grafik-Pipeline zu spülen. Die 3D-Pipeline führt Geometrieverarbeitung für die 3D-Primitiven durch. Sobald Operationen abgeschlossen sind, werden die erhaltenen geometrischen Objekte gerastert und die Pixeleinheit färbt die resultierenden Pixel. Zusätzliche Steuerbefehle zum Steuern von Pixelschattierungs- und Pixel-Backend-Operationen können auch für diese Operationen enthalten sein.
  • Die Grafikprozessorsteuerbefehlsabfolge 2210 kann dem Medien-Pipeline-2224 Pfad folgen, wenn Medienoperationen durchgeführt werden. Im Allgemeinen hängen die spezifische Verwendung und Art von Programmierung für die Medien-Pipeline 2224 von den Medien- oder Rechenoperationen ab, die durchzuführen sind. Spezifische Mediendecodierungsoperationen können auf die Medien-Pipeline während Mediendecodierung abgeladen werden. Die Medien-Pipeline kann auch umgangen werden und Mediendecodierung kann zur Gänze 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 Allzweckgrafikprozessoreinheits- (GPGPU) Operationen aufweisen, wo der Grafikprozessor verwendet wird, um SIMD-Vektoroperationen unter Verwendung von Berechnungs-Shader-Programmen durchzuführen, die nicht explizit mit dem Rendering von Grafikprimitiven zusammenhängen.
  • Medien-Pipeline 2224 kann in einer ähnlichen Weise konfiguriert sein wie die 3D-Pipeline 2222. Ein Satz von Steuerbefehlen zum Konfigurieren des Medien-Pipeline-Zustands 2240 wird zu einer Steuerbefehlswarteschlange geleitet oder in dieser vor Medienobjektsteuerbefehlen 2242 platziert werden. Steuerbefehle für den Medien-Pipeline-Zustand 2240 können Daten zur Konfiguration der Medien-Pipeline-Elemente aufweisen, die zum Verarbeiten der Medienobjekte verwendet werden. Diese weisen Daten zum Konfigurieren der Videodecodier- und Videocodierlogik in der Medien-Pipeline auf, wie Codier- oder Decodierformat. Steuerbefehle für den Medien-Pipeline-Zustand 2240 können auch die Verwendung eines oder mehrerer Zeiger zu „indirekten“ Zustandselementen unterstützen, die einen Stapel von Zustandseinstellungen enthalten.
  • Medienobjektsteuerbefehle 2242 können Zeiger zu Medienobjekten zur Verarbeitung durch die Medien-Pipeline zuleiten. Die Medienobjekte weisen Speicherpuffer auf, die zu verarbeitende Videodaten enthalten. Optional müssen alle Medien-Pipeline-Zustände gültig sein, bevor ein Medienobjektsteuerbefehl 2242 ausgegeben wird. Sobald der Pipeline-Zustand konfiguriert ist und Medienobjektsteuerbefehle 2242 in der Schlange sind, wird die Medien-Pipeline 2224 über einen Ausführungssteuerbefehl 2244 oder ein äquivalentes Ausführungsereignis (z.B. Registerschrieb) ausgelöst. Ausgang 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 in einer ähnlichen Weise wie Medienoperationen konfiguriert sein und ausgeführt werden.
  • Grafik-Softwarearchitektur
  • 23 veranschaulicht eine beispielhafte Grafik-Softwarearchitektur für ein Datenverarbeitungssystem 2300. Eine solche Softwarearchitektur kann eine 3D-Grafikanwendung 2310, ein Betriebssystem 2320 und mindestens einen Prozessor 2330 aufweisen. Prozessor 2330 kann einen Grafikprozessor 2332 und einen oder mehrere Allzweckprozessorkern(e) 2334 aufweisen. Der Prozessor 2330 kann eine Variante des Prozessors 1402 oder eines anderen der hier beschriebenen Prozessoren sein. Der Prozessor 2330 kann anstelle des Prozessors 1402 oder eines anderen der hier beschriebenen Prozessoren verwendet werden. Daher offenbart die Offenbarung beliebiger Merkmale in Kombination mit dem Prozessor 1402 oder einem anderen der hier beschriebenen Prozessoren auch eine entsprechende Kombination mit dem Grafikprozessor 2330, ist aber nicht darauf beschränkt. Ferner beschreiben die Elemente von 23 mit denselben oder ähnlichen Bezeichnungen wie die Elemente einer beliebigen anderen Figur hierin, dieselben Elemente wie in den anderen Figuren, können auf ähnliche Weise wie diese arbeiten oder funktionieren, können dieselben Komponenten aufweisen und können mit anderen Einheiten, wie jenen, die hier an anderer Stelle beschrieben sind, verbunden sein, sind aber als solche nicht eingeschränkt.
  • Die Grafikanwendung 2310 und das Betriebssystem 2320 werden jeweils in dem Systemspeicher 2350 des Datenverarbeitungssystems ausgeführt.
  • 3D-Grafikanwendung 2310 kann ein oder mehrere Shader-Programme enthalten, die Shader-Befehle 2312 aufweisen. Die Shader-Sprachbefehle können in einer Shader-Sprache hoher Ebene sein, wie die High-Level Shader Language (HLSL) von Direct3D, die OpenGL Shader Language (GLSL) und so weiter. Die Anwendung kann auch ausführbare Befehle 2314 in einer Maschinensprache aufweisen, die zur Ausführung durch den Allzweckprozessorkern 2334 geeignet ist. Die Anwendung weist auch Grafikobjekte 2316 auf, die durch Vertexdaten definiert sind.
  • Das Betriebssystem 2320 kann ein Microsoft® Windows® Betriebssystem von der Firma Microsoft, ein firmeneigenes UNIX-artiges Betriebssystem oder ein Betriebssystem ähnlich Open Source UNIX, unter Verwendung einer Variante des Linux Kernels sein. Das Betriebssystem 2320 kann eine Grafik API 2322 wie die Direct3D API, die OpenGL API oder die Vulkan API unterstützen. Wenn die Direct3D API in Verwendung ist, verwendet das Betriebssystem 2320 einen Frontend-Shader-Kompilierer 2324 zum Kompilieren von Shader-Befehlen 2312 in HLSL in eine Shader-Sprache tieferer Ebene. Die Kompilierung kann eine zeitgerechte (JIT, just-in-time) Kompilierung sein oder die Anwendung kann Shader-Vorkompilierung durchführen. Shader hoher Ebene können während der Kompilierung der 3D-Grafikanwendung 2310 zu Shadern tiefer Ebene kompiliert werden. Die Shader Befehle 2312 können in einer Zwischenform bereitgestellt werden, wie einer Version der Standard Portable Intermediate Representation (SPIR), die von der Vulkan API verwendet wird.
  • Ein Anwendermodusgrafiktreiber 2326 kann einen Backend-Shader-Kompilierer 2327 zum Umwandeln der Shader-Befehle 2312 in eine hardwarespezifische Darstellung enthalten. Wenn die OpenGL API in Verwendung ist, werden Shader-Befehle 2312 in der GLSL Sprache hoher Ebene zu einem Anwendermodusgrafiktreiber 2326 zur Kompilierung geleitet. Der Anwendermodusgrafiktreiber 2326 kann Betriebssystem-Kernelmodusfunktionen 2328 verwenden, um mit einem Kernelmodusgrafiktreiber 2329 zu kommunizieren. Der Kernelmodusgrafiktreiber 2329 kann mit Grafikprozessor 2332 kommunizieren, um Steuerbefehle und Befehle weiterzuleiten.
  • IP-Kernimplementierungen
  • Ein oder mehrere Aspekte können durch repräsentativen Code implementiert sein, der auf einem maschinenlesbaren Medium gespeichert ist, das Logik in einer integrierten Schaltung wie einem Prozessor darstellt und/oder definiert. Zum Beispiel kann das maschinenlesbare Medium Befehle aufweisen, die verschiedene Logik in dem Prozessor darstellen. Wenn von einer Maschine gelesen, können die Befehle die Maschine veranlassen, die Logik zu fertigen, um die hier beschriebenen Techniken durchzuführen. Solche Darstellungen, bekannt als „IP-Kerne“, sind wiederverwendbare Einheiten von Logik für eine integrierte Schaltung, die auf einem greifbaren, maschinenlesbaren Medium als ein Hardwaremodell gespeichert sein können, das die Struktur der integrierten Schaltung beschreibt. Das Hardwaremodell kann verschiedenen Kunden oder Herstellungsanlagen geliefert werden, die das Hardwaremodell auf Fertigungsmaschinen laden, die die integrierte Schaltung herstellen. Die integrierte Schaltung kann so gefertigt werden, dass die Schaltung Operationen durchführt, die in Verbindung mit einer der hier beschriebenen Ausführungsformen beschrieben sind.
  • 24A ist ein Blockdiagramm, das ein IP-Kernentwicklungssystem 2400 zeigt, das zur Herstellung einer integrierten Schaltung verwendet werden kann, um Operationen gemäß einer Ausführungsform durchzuführen. Das IP-Kernentwicklungssystem 2400 kann zum Erzeugen modularer, wiederverwendbarer Designs verwendet werden, die in ein größeres Design eingefügt oder zum Bilden einer vollständigen integrierten Schaltung (z.B. einer integrierten SOC-Schaltung) verwendet werden können. Eine Designanlage 2430 kann eine Softwaresimulation 2410 eines IP-Kemdesigns in einer Programmiersprache hoher Ebene (z.B. C/C++) erzeugen. Die Softwaresimulation 2410 kann zum Gestalten, Testen und Verifizieren des Verhaltens des IP-Kerns unter Verwendung eines Simulationsmodells 2412 verwendet werden. Das Simulationsmodell 2412 kann Funktions-, Verhaltens- und/oder Zeitsteuerungssimulationen aufweisen. Ein Registertransferebenen- (RTL, Register Transfer Level) Design 2415 kann dann aus dem Simulationsmodell 2412 erzeugt oder synthetisiert werden. Das RTL-Design 2415 ist eine Abstraktion des Verhaltens der integrierten Schaltung, das den Fluss von Digitalsignalen zwischen Hardwareregistern als Modell darstellt, enthaltend die zugehörige Logik, die unter Verwendung der modellierten digitalen Signale durchgeführt wird. Zusätzlich zu einem RTL-Design 2415 können auch Designs unterer Ebene auf der Logikebene oder Transistorebene erzeugt, gestaltet oder synthetisiert werden. Daher können die besonderen Einzelheiten des anfänglichen Designs und der Simulation variieren.
  • Das RTL-Design 2415 oder Äquivalent kann ferner von der Designanlage zu einem Hardwaremodell 2420 synthetisiert werden, das eine Hardware-Beschreibungssprache (HDL, Hardware Description Language) oder eine andere Darstellung physischer Designdaten sein kann. Die HDL kann ferner simuliert oder getestet werden, um das IP-Kerndesign zu verifizieren. Das IP-Kerndesign kann zur Weiterleitung an eine Fertigungsanlage 2465 einer Drittpartei unter Verwendung nicht flüchtiger Speicher 2440 (z.B. Festplatte, Flash-Speicher oder ein nicht flüchtiges Datenspeichermedium) gespeichert werden. Alternativ kann das IP-Kerndesign (z.B. über das Internet) über eine drahtgebundene Verbindung 2450 oder drahtlose Verbindung 2460 übertragen werden. Die Fertigungsanlage 2465 kann dann eine integrierte Schaltung fertigen, die mindestens teilweise auf dem IP-Kemdesign basiert. Die gefertigte integrierte Schaltung kann konfiguriert sein, Operationen gemäß mindestens einer hier beschriebenen Ausführungsform durchzuführen.
  • 24B veranschaulicht eine Seitenansicht im Querschnitt einer Package-Anordnung integrierter Schaltungen 2470. Die Package-Anordnung integrierter Schaltungen 2470 veranschaulicht eine Implementierung einer oder mehrerer Prozessor- oder Beschleunigervorrichtungen wie hier beschrieben. Die Package-Anordnung 2470 weist mehrere Einheiten von Hardwarelogik 2472, 2474 auf, die mit einem Substrat 2480 verbunden sind. Die Logik 2472, 2474 kann mindestens teilweise in Hardware konfigurierbarer Logik oder Logik fester Funktionalität implementiert sein und kann einen oder mehrere Abschnitte eines der Prozessorkern(e), Grafikprozessor(en) oder anderen hier beschriebenen Beschleunigervorrichtungen aufweisen. Jede Logikeinheit 2472, 2474 kann in einem Halbleiter-Die implementiert und mit dem Substrat 2480 über eine Interconnect-Struktur 2473 gekoppelt sein. Die Interconnect-Struktur 2473 kann konfiguriert sein, elektrische Signale zwischen der Logik 2472, 2474 und dem Substrat 2480 zu leiten, und kann Interconnects aufweisen, wie, aber nicht beschränkt auf, Höcker oder Säulen. Die Interconnect-Struktur 2473 kann konfiguriert sein, elektrische Signale wie zum Beispiel Eingangs-/Ausgangs-(I/O) Signale und/oder Leistungs- oder Massesignale, die mit dem Betrieb der Logik 2472, 2474 verknüpft sind, zu leiten. Optional kann das Substrat 2480 ein epoxidbasiertes Laminatsubstrat sein. Das Substrat 2480 kann auch andere geeignete Arten von Substraten aufweisen. Die Package-Anordnung 2470 kann mit anderen elektrischen Vorrichtungen über ein Package-Interconnect 2483 verbunden sein. Das Package-Interconnect 2483 kann an eine Oberfläche des Substrats 2480 gekoppelt sein, um elektrische Signale zu anderen elektrischen Vorrichtungen, wie eine Hauptplatine, ein anderes Chipset oder Multi-Chip-Modul, zu leiten.
  • Die Logikeinheiten 2472, 2474 können elektrisch mit einer Brücke 2482 gekoppelt sein, die konfiguriert ist, elektrische Signale zwischen der Logik 2472, 2474 zu leiten. Die Brücke 2482 kann eine dichte Interconnect-Struktur sein, die einen Weg für elektrische Signale bereitstellt. Die Brücke 2482 kann ein Brückensubstrat aufweisen, das aus Glas oder einem geeigneten Halbleitermaterial besteht. Elektrische Leitermerkmale können auf dem Brückensubstrat gebildet sein, um eine Chip-zu-Chip Verbindung zwischen der Logik 2472, 2474 bereitzustellen.
  • Obwohl zwei Logikeinheiten 2472, 2474 und eine Brücke 2482 veranschaulicht sind, können hier beschriebene Ausführungsformen mehr oder weniger Logikeinheiten auf einem oder mehreren Dies aufweisen. Der eine oder die mehreren Dies können durch null oder mehr Brücken verbunden sein, da die Brücke 2482 ausgeschlossen sein kann, wenn die Logik auf einem einzelnen Die enthalten ist. Alternativ können mehrere Dies oder Logikeinheiten durch eine oder mehrere Brücken verbunden sein. Zusätzlich können mehrere Logikeinheiten, Dies und Brücken in anderen möglichen Konfigurationen, enthaltend dreidimensionale Konfigurationen, miteinander verbunden sein.
  • 24C veranschaulicht eine Package-Anordnung 2490, die mehrere Einheiten von Hardwarelogik-Chiplets aufweist, die mit einem Substrat 2480 (z.B. Basis-Die) verbunden sind. Eine Grafikverarbeitungseinheit, paralleler Prozessor und/oder Rechenbeschleuniger, wie hier beschrieben, können aus verschiedenen Silizium-Chiplets bestehen, die separat hergestellt werden. In diesem Zusammenhang ist ein Chiplet eine mindestens teilweise gepackte integrierte Schaltung, die einzelne Logikeinheiten aufweist, die mit anderen Chiplets zu einem größeren Package zusammengefügt werden können. Ein diverser Satz von Chiplets mit verschiedener IP-Kernlogik kann zu einer einzigen Vorrichtung zusammengefügt werden. Zusätzlich können die Chiplets zu einem Basis-Die oder Basis-Chiplet unter Verwendung aktiver Interposer-Technologie integriert werden. Die hier beschriebenen Konzepte ermöglichen die Zwischenverbindung und Kommunikation zwischen den verschiedenen Formen von IP in der GPU. IP-Kerne können unter Verwendung verschiedener Prozesstechnologien hergestellt und während Herstellung zusammengestellt werden, was die Komplexität konvergierender mehrerer IPs, insbesondere auf einem großen SoC mit mehreren Arten von IPs in demselben Herstellungsprozess vermeidet. Die Verwendung mehrerer Prozesstechnologien zu ermöglichen, verbessert die Zeit bis zur Vermarktung und stellt eine kosteneffektive Möglichkeit bereit, mehrere Produkt-SKUs zu erzeugen. Zusätzlich sind die zerlegten IPs für leistungsgeregelte unabhängige Komponenten besser geeignet, die bei einer bestimmten Arbeitslast nicht in Verwendung sind und ausgeschaltet werden können, wodurch der gesamte Leistungsverbrauch verringert wird.
  • In verschiedenen Ausführungsformen kann eine Package-Anordnung 2490 einer geringere oder größere Anzahl von Komponenten und Chiplets aufweisen, die durch ein Fabric 2485 oder eine oder mehrere Brücken 2487 zwischenverbunden sind. Die Chiplets in der Package-Anordnung 2490 können eine 2,5D Anordnung unter Verwendung von Chip-auf-Wafer-auf-Substrat-Stapelung aufweisen, wobei mehrere Dies Seite an Seite auf einem Silizium-Interposer gestapelt sind, der Siliziumdurchkontaktierungen (TSVs, Through-Silicon Vias) verwendet, um die Chiplets mit dem Substrat 2480 zu koppeln, das elektrische Verbindungen zu dem Package-Interconnect 2483 aufweist.
  • In einer Ausführungsform ist der Silizium-Interposer ein aktiver Interposer 2489, der eingebettete Logik zusätzlich zu TSVs aufweist. In einer solchen Ausführungsform sind die Chiplets in der Package-Anordnung 2490 unter Verwendung einer 3D Flache-an-Fläche-Die-Stapelung auf der Oberseite des aktiven Interposers 2489 angeordnet. Der aktive Interposer 2489 kann Hardwarelogik für I/O 2491, Cache-Speicher 2492 und andere Hardwarelogik 2493 zusätzlich zu Interconnect-Fabric 2485 und einer Siliziumbrücke 2487 aufweisen. Das Fabric 2485 ermöglicht Kommunikation zwischen den verschiedenen Logik-Chiplets 2472, 2474 und der Logik 2491, 2493 in dem aktiven Interposer 2489. Das Fabric 2485 kann ein NoC Interconnect oder eine andere Art von paketvermitteltem Fabric sein, das Datenpakete zwischen Komponenten der Package-Anordnung vermittelt. Für komplexe Zusammenstellungen kann das Fabric 2485 ein dediziertes Chiplet sein, das Kommunikation zwischen der unterschiedlichen Hardwarelogik der Package-Anordnung 2490 ermöglicht.
  • Brückenstrukturen 2487 in dem aktiven Interposer 2489 können verwendet werden, um ein Punkt-zu-Punkt Interconnect zwischen zum Beispiel Logik oder I/O-Chiplets 2474 und Speicher-Chiplets 2475 zu erleichtern. In manchen Implementierungen können Brückenstrukturen 2487 auch in das Substrat 2480 eingebettet sein.
  • Die Hardwarelogik-Chiplets können Spezialzweck-Hardwarelogik-Chiplets 2472, Logik- oder I/O-Chiplets 2474 und/oder Speicher Chiplets 2475 aufweisen. Die Hardwarelogik-Chiplets 2472 und Logik- oder I/O-Chiplets 2474 können mindestens teilweise in konfigurierbarer Logik- oder Festfunktionalitätslogik-Hardware implementiert sein und können einen oder mehrere Teile eines der Prozessorkern(e), Grafikprozessor(en), parallelen Prozessoren oder anderen hier beschriebenen Beschleunigervorrichtungen aufweisen. Die Speicher Chiplets 2475 können DRAM-(z.B. GDDR, HBM) Speicher oder Cache- (SRAM) Speicher sein. Cache-Speicher 2492 in dem aktiven Interposer 2489 (oder Substrat 2480) können als ein globaler Cache für die Package-Anordnung 2490, Teil eines verteilten globalen Cache oder als ein dedizierter Cache für das Fabric 2485 dienen.
  • Jedes Chiplet kann als separater Halbleiter-Die gefertigt und mit einem Basis-Die gekoppelt sein, das in dem Substrat 2480 eingebettet oder mit diesem gekoppelt ist. Die Kopplung mit dem Substrat 2480 kann über eine Interconnect-Struktur 2473 durchgeführt werden. Die Interconnect-Struktur 2473 kann konfiguriert sein, elektrische Signale zwischen den verschiedenen Chiplets und Logik im Substrat 2480 zu leiten. Die Interconnect-Struktur 2473 kann Interconnects aufweisen, wie, ohne aber darauf beschränkt zu sein, Höcker oder Säulen. In manchen Ausführungsformen kann die Interconnect-Struktur 2473 konfiguriert sein, elektrische Signale zu leiten, wie zum Beispiel Eingangs-/Ausgangs-(I/O) Signale und/oder Leistungs- oder Massesignale, die mit dem Betrieb der Logik-, I/O- und Speicher-Chiplets verknüpft sind. In einer Ausführungsform koppelt eine zusätzliche Interconnect-Struktur den aktiven Interposer 2489 mit dem Substrat 2480.
  • Das Substrat 2480 kann ein epoxidbasiertes Laminatsubstrat sein, ist jedoch nicht darauf beschränkt und das Substrat 2480 kann auch andere geeignete Arten von Substraten aufweisen. Die Package-Anordnung 2490 kann mit anderen elektrischen Vorrichtungen über ein Package-Interconnect 2483 verbunden sein. Das Package-Interconnect 2483 kann an eine Oberfläche des Substrats 2480 gekoppelt sein, um elektrische Signale zu anderen elektrischen Vorrichtungen, wie eine Hauptplatine, einen anderen Chipset oder ein Multi-Chip-Modul, zu leiten.
  • Ein Logik- oder I/O-Chiplet 2474 und ein Speicher-Chiplet 2475 können elektrisch über eine Brücke 2487 gekoppelt sein, die konfiguriert ist, elektrische Signale zwischen dem Logik- oder I/O-Chiplet 2474 und einem Speicher-Chiplet 2475 zu leiten. Die Brücke 2487 kann eine dichte Interconnect-Struktur sein, die einen Weg für elektrische Signale bereitstellt. Die Brücke 2487 kann ein Brückensubstrat aufweisen, das aus Glas oder einem geeigneten Halbleitermaterial besteht. Elektrische Leitermerkmale können auf dem Brückensubstrat gebildet sein, um eine Chip-zu-Chip Verbindung zwischen dem Logik- oder I/O-Chiplet 2474 und einem Speicher-Chiplet 2475 bereitzustellen. Die Brücke 2487 kann auch als eine Siliziumbrücke oder eine Interconnect-Brücke bezeichnet werden. Zum Beispiel ist die Brücke 2487 eine Embedded Multi-Die Interconnect Bridge (EMIB). Alternativ kann die Brücke 2487 einfach eine direkte Verbindung von einem Chiplet zu einem anderen Chiplet sein.
  • 24D veranschaulicht eine Package-Anordnung 2494, die austauschbare Chiplets 2495 aufweist, gemäß einer Ausführungsform. Die austauschbaren Chiplets 2495 können in standardisierten Schlitzen auf einem oder mehreren Basis-Chiplets 2496, 2498 zusammengefügt werden. Die Basis-Chiplets 2496, 2498 können über ein Brücken-Interconnect 2497 gekoppelt sein, das den anderen hier beschriebenen Brücken-Interconnects ähnlich sein kann und zum Beispiel ein EMIB sein kann. Speicher-Chiplets können auch mit Logik- oder I/O-Chiplets über ein Brücken-Interconnect verbunden sein. I/O- und Logik-Chiplets können über ein Interconnect-Fabric kommunizieren. Die Basis-Chiplets können jeweils einen oder mehrere Schlitze in einem standardisierten Format für einen von Logik- oder I/O- oder Speicher/Cache unterstützen.
  • SRAM und Leistungsabgabeschaltungen können zu einem oder mehreren der Basis-Chiplets 2496, 2498 gefertigt werden, die unter Verwendung einer anderen Prozesstechnologie relativ zu den austauschbaren Chiplets 2495 gefertigt werden können, die auf die Oberseite der Basis-Chiplets gestapelt sind. Zum Beispiel können die Basis-Chiplets 2496, 2498 unter Verwendung einer größeren Prozesstechnologie gefertigt werden, während die austauschbaren Chiplets unter Verwendung einer kleineren Prozesstechnologie hergestellt werden können. Eines oder mehrere der austauschbaren Chiplets 2495 können Speicher- (z.B. DRAM) Chiplets sein. Für die Package-Anordnung 2494 können basierend auf der Leistung und/oder Arbeitsleistung, die für das Produkt geplant ist, das die Package-Anordnung 2494 verwendet, verschiedene Speicherdichten gewählt werden. Zusätzlich können Logik-Chiplets mit einer anderen Anzahl einer Art von Funktionseinheiten zum Zeitpunkt des Zusammenbaus basierend auf der Leistung und/oder Arbeitsleistung, die für das Produkt geplant ist, gewählt werden. Zusätzlich können Chiplets, die IP-Logikkerne unterschiedlicher Arten enthalten, in die austauschbaren Chiplet-Schlitze eingesetzt werden, wodurch hybride Prozessordesigns möglich sind, die IP-Blöcke verschiedener Technologie mischen und zusammenpassen können.
  • Beispielhafte integrierte System-auf-einem-Chip Schaltung
  • 25-26B veranschaulichen beispielhafte integrierte Schaltungen und zugehörige Grafikprozessoren, die unter Verwendung eines oder mehrerer IP-Kerne gefertigt werden können. Zusätzlich zu dem, was veranschaulicht ist, können andere Logik und Schaltungen enthalten sein, die zusätzliche Grafikprozessoren/Kerne, periphere Schnittstellensteuerungen oder Allzweckprozessorkerne aufweisen. Die Elemente von 25-26B mit denselben oder ähnlichen Bezeichnungen wie die Elemente einer beliebigen anderen Figur hierin, beschreiben dieselben Elemente wie in den anderen Figuren, können auf ähnliche Weise wie diese arbeiten oder funktionieren, können dieselben Komponenten aufweisen und können mit anderen Einheiten, wie jenen, die hier an anderer Stelle beschrieben sind, verbunden sein, sind aber als solche nicht eingeschränkt.
  • 25 ist ein Blockdiagramm, das eine beispielhafte integrierte System-auf-einem-Chip Schaltung 2500 veranschaulicht, die unter Verwendung eines oder mehrerer IP-Kerne gefertigt werden kann. Beispielhafte integrierte Schaltung 2500 weist einen oder mehrere Anwendungsprozessor(en) 2505 (z.B. CPUs), mindestens einen Grafikprozessor 2510 auf, der eine Variante des Grafikprozessors 1408, 1508, 2510 oder eines hier beschriebenen Grafikprozessors sein kann und anstelle eines beschriebenen Grafikprozessors verwendet werden kann. Daher offenbart die Offenbarung beliebiger Merkmale in Kombination mit einem Grafikprozessor hier auch eine entsprechende Kombination mit dem Grafikprozessor 2510, ist aber nicht darauf beschränkt. Die integrierte Schaltung 2500 kann zusätzlich einen Bildprozessor 2515 und/oder einen Videoprozessor 2520 aufweisen, von welchen jeder ein modularer IP-Kern von derselben oder mehreren verschiedenen Designanlagen sein kann. Integrierte Schaltung 2500 kann periphere oder Bus-Logik aufweisen, die eine USB-Steuerung 2525, UART-Steuerung 2530, eine SPI/SDIO-Steuerung 2535 und eine I2S/I2C-Steuerung 2540 aufweisen kann. Zusätzlich kann die integrierte Schaltung eine Anzeigevorrichtung 2545 aufweisen, die an eine oder mehrere einer Hochdefinitions-Multimediaschnittstellen- (HDMI, High Definition Multimedia Interface) Steuerung 2550 und einer mobilen Industrieprozessorschnittstellen- (MIPI, Mobile Industry Processor Interface) Anzeigeschnittstelle 2555 gekoppelt ist. Datenspeicher kann durch ein Flash-Speicherteilsystem 2560 bereitgestellt sein, das einen Flash-Speicher und eine Flash-Speichersteuerung aufweist. Speicherschnittstelle kann über eine Speichersteuerung 2565 für Zugriff auf SDRAM- oder SRAM-Speichervorrichtungen bereitgestellt sein. Manche integrierte Schaltungen weisen zusätzlich eine eingebettete Sicherheits-Engine 2570 auf.
  • 26A-26B sind Blockdiagramme, die beispielhafte Grafikprozessoren zur Verwendung in einem SoC gemäß hier beschriebenen Ausführungsformen veranschaulichen. Die Grafikprozessoren können Varianten des Grafikprozessors 1408, 1508, 2510 oder eines anderen hier beschriebenen Grafikprozessors sein. Die Grafikprozessoren können anstelle des Grafikprozessors 1408, 1508, 2510 oder eines anderen der hier beschriebenen Grafikprozessoren verwendet werden. Daher offenbart die Offenbarung beliebiger Merkmale in Kombination mit dem Grafikprozessor 1408, 1508, 2510 oder eines anderen der hier beschriebenen Grafikprozessoren auch eine entsprechende Kombination mit dem (den) Grafikprozessoren von 26A-26B, ist aber nicht darauf beschränkt. 26A veranschaulicht einen beispielhaften Grafikprozessor 2610 einer integrierten System-auf-einem-Chip-Schaltung, die unter Verwendung eines oder mehrere IP-Kerne gefertigt werden kann, gemäß einer Ausführungsform. 26B veranschaulicht einen zusätzlichen beispielhaften Grafikprozessor 2640 einer integrierten System-auf-einem-Chip-Schaltung, die unter Verwendung eines oder mehrerer IP-Kerne gefertigt werden kann, gemäß einer Ausführungsform. Grafikprozessor 2610 von 26A ist ein Beispiel eines leistungsarmen Grafikprozessorkerns. Grafikprozessor 2640 von 26B ist ein Beispiel eines Grafikprozessorkerns höherer Arbeitsleistung. Zum Beispiel kann jeder von Grafikprozessor 2610 und Grafikprozessor 2640 eine Variante des Grafikprozessors 2510 von 25 sein, wie zu Beginn dieses Absatzes erwähnt.
  • Wie in 26A dargestellt, weist Grafikprozessor 2610 einen Vertexprozessor 2605 und einen oder mehrere Fragmentprozessor(en) 2615A-2615N (z.B. 2615A, 2615B, 2615C, 2615D bis 2615N-1 und 2615N) auf. Grafikprozessor 2610 kann verschiedene Shader-Programme über separate Logik ausführen, sodass der Vertexprozessor 2605 optimiert ist, um Operationen für Vertex-Shader-Programme auszuführen, während der eine oder die mehreren Fragmentprozessor(en) 2615A-2615N Fragment- (z.B. Pixel-) Shading-Operationen für Fragment- oder Pixel-Shader-Programme ausführen. Der Vertexprozessor 2605 führt die Vertexverarbeitungsstufe der 3D-Grafik-Pipeline durch und erzeugt Primitive und Vertexdaten. Der (die) Fragmentprozessor(en) 2615A-2615N verwendet (verwenden) die Primitive und Vertexdaten, die von dem Vertexprozessor 2605 erzeugt wurden, um einen Framepuffer zu erzeugen, der auf einer Anzeigevorrichtung angezeigt wird. Der (die) Fragmentprozessor(en) 2615A-2615N kann (können) optimiert sein, um Fragment-Shader-Programme auszuführen, wie in der OpenGL API bereitgestellt, die verwendet werden können, um ähnliche Operationen wie ein Pixel-Shader-Programm durchzuführen, wie in der Direct 3D API bereitgestellt.
  • Grafikprozessor 2610 weist zusätzlich eine oder mehrere Speicherverwaltungseinheiten (MMUs) 2620A-2620B, Cache(s) 2625A-2625B und Schaltungs-Interconnect(s) 2630A-2630B auf. Die eine oder mehreren MMU(s) 2620A-2620B stellen virtuelle zu physische Adressenabbildung für den Grafikprozessor 2610 bereit, aufweisend für den Vertexprozessor 2605 und/oder den (die) Fragmentprozessor(en) 2615A-2615N, die auf Vertex- oder Bild/Texturdaten Bezug nehmen können, die im Speicher gespeichert sind, zusätzlich zu Vertex- oder Bild/Texturdaten, die in dem einen oder den mehreren Cache(s) 2625A-2625B gespeichert sind. Die eine oder mehreren MMU(s) 2620A-2620B können mit anderen MMUs in dem System synchronisiert sein, aufweisend eine oder mehrere MMUs, die mit dem einen oder den mehreren Anwendungsprozessor(en) 2505, Bildprozessor 2515 und/oder Videoprozessor 2520 von 25 verknüpft sind, sodass jeder Prozessor 2505-2520 an einem geteilten oder vereinheitlichten virtuellen Speichersystem teilnehmen kann. Komponenten von Grafikprozessor 2610 können Komponenten von anderen hier beschriebenen Grafikprozessoren entsprechen. Die eine oder mehreren MMU(s) 2620A-2620B können MMU 245 von 2C entsprechen. Vertexprozessor 2605 und Fragmentprozessor 2615A-2615N können Grafikmultiprozessor 234 entsprechen. Das eine oder die mehreren Schaltungs-Interconnect(s) 2630A-2630B ermöglichen dem Grafikprozessor 2610 eine Verbindung mit anderen IP-Kernen in der SoC, entweder über einen internen Bus der SoC oder über eine direkte Verbindung, gemäß Ausführungsformen. Das eine oder die mehreren Schaltungs-Interconnect(s) 2630A-2630B können der Daten-Crossbar 240 von 2C entsprechen. Weitere Entsprechung kann zwischen analogen Komponenten des Grafikprozessoren 2610 und den verschiedenen hier beschriebenen Grafikprozessorarchitekturen gefunden werden.
  • Wie in 26B dargestellt, weist Grafikprozessor 2640 die eine oder mehreren MMU(s) 2620A-2620B, Cache(s) 2625A-2625B und Schaltungs-Interconnect(s) 2630A-2630B des Grafikprozessors 2610 von 26A auf. Grafikprozessor 2640 weist einen oder mehrere Shader-Kerne 2655A-2655N (z.B. 2655A, 2655B, 2655C, 2655D, 2655E, 2655F bis 2655N-1 und 2655N) auf, was eine vereinheitlichte Shader-Kernarchitektur bereitstellt, in der ein einzelner Kern oder eine Art von Kern alle Arten von programmierbarem Shader-Code ausführen kann, aufweisend Shader-Programmcode, um Vertex-Shader, Fragment-Shader und/oder Rechen-Shader zu implementieren. Die exakte Anzahl von vorhandenen Shader-Kernen kann unter Ausführungsformen und Implementierungen variieren. Zusätzlich weist Grafikprozessor 2640 einen Inter-Kernaufgabenverwalter 2645 auf, der als ein Thread Dispatcher dient, um Ausführungs-Threads zu einem oder mehreren Shader Kernen 2655A-2655N zu leiten, und eine Kachelungseinheit 2658, um Kachelungsoperationen für Kachel-basiertes Rendering zu beschleunigen, in welchen Renderingoperationen für eine Szene im Bildraum unterteilt sind, um zum Beispiel lokale räumliche Kohärenz in einer Szene zu nutzen oder Verwendung interner Caches zu optimieren. Shader-Kerne 2655A-2655N können zum Beispiel Grafikmultiprozessor 234 wie in 2D oder Grafikmultiprozessoren 325, 350 von 3A bzw. 3B oder Mehrfachkerngruppe 365A von 3C entsprechen.
  • Systolische Arithmetik an spärlichen Daten
  • Eine Sparse-Matrix ist eine Matrix, die wenige Nicht-Null-Elemente relativ zu der Gesamtzahl von Elementen in der Matrix enthält. Die dünne Besetzung einer Matrix kann durch die Anzahl von Null-Wert-Elementen dividiert durch die Gesamtzahl von Elementen bestimmt werden. Die Menge an Datenspeicher, die von Sparse-Matrizen eingenommen wird, kann durch Komprimieren der Daten und/oder Codieren der Daten in ein Sparse-Codierungsformat verringert werden. Verarbeitungsoperationen, die unter Verwendung von Sparse-Matrizen durchgeführt werden, können durch Umgehen von Multiplikationsoperationen an Null-Wert-Matrixelementen beschleunigt werden. Optimierungen können auch für Matrixdaten durchgeführt werden, die vorwiegend jeder einzelne Wert sind oder die sonst leicht komprimiert werden können.
  • Hier beschriebene Ausführungsformen weisen Software, Firmware und Hardwarelogik auf, die Techniken zum Durchführen von Arithmetik an spärlichen Daten über eine systolische Verarbeitungseinheit oder andere Matrix und/oder Tensor-Beschleunigereinheiten bereitstellt. Eine Ausführungsform stellt Techniken zum Optimieren von Trainings- und Schlussfolgerungen an einem systolischen Array bereit, wenn spärliche Daten verwendet werden. Eine Ausführungsform stellt Techniken zur Verwendung von Dekompressionsinformationen bereit, wenn Sparse-Rechenoperationen durchgeführt werden. Eine Ausführungsform stellt eine numerische Transformation bereit, um spärliche Daten umzuwandeln und Durchführung eines Trainings basierend auf den transformierten Daten zu ermöglichen. Eine Ausführungsform stellt Techniken zum Durchführen systolischer Arithmetik direkt an komprimierten Daten bereit.
  • GPGPU mit Tensor-Beschleunigungslogik
  • 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, aufweisend Maschinenlernbeschleunigungslogik. Der Prozessor 2702 und die GPGPU 2720 kann jede(r) der Prozessoren und GPGPU/parallelen Prozessoren wie hier beschrieben sein. Der Prozessor 2702 kann Befehle für einen Kompilierer 2715 ausführen, der im Systemspeicher 2712 gespeichert ist. Der Kompilierer 2715 läuft auf dem Prozessor 2702, um Quellencode 2714A in kompilierten Code 2714B zu kompilieren. Der kompilierte Code 2714B kann Befehle aufweisen, die von dem Prozessor 2702 ausgeführt werden können, und/oder Befehle, die von der GPGPU 2720 ausgeführt werden können. Während des Kompilierens kann der Kompilierer 2715 Operationen zum Einsetzen von Metadaten durchführen, aufweisend Hinweise auf das Niveau von Datenparallelismus, das in dem kompilierten Code 2714B vorhanden ist, und/oder Hinweise bezüglich der Datenlokalität, die mit Threads verknüpft ist, die basierend auf den kompilierten Code 2714B weiterzuleiten sind. Der Kompilierer 2715 kann die Informationen aufweisen, die notwendig sind, um solche Operationen durchzuführen, oder die Operationen können mit Hilfe einer Laufzeitbibliothek 2716 durchgeführt werden. Die Laufzeitbibliothek 2716 kann dem Kompilierer 2715 auch bei der Kompilierung des Quellencodes 2714A helfen und kann auch Befehle aufweisen, die bei Laufzeit mit dem kompilierten Code 2714B verbunden sind, um Ausführung der kompilierten Befehle auf der GPGPU 2720 zu erleichtern.
  • Der vereinheitlichte Speicher 2710 stellt einen vereinheitlichten Adressenraum dar, auf den der Prozessor 2702 und die GPGPU 2720 zugreifen können. Der vereinheitlichte Speicher kann Systemspeicher 2712, wie auch GPGPU-Speicher 2718 aufweisen. Der GPGPU-Speicher 2718 ist Speicher in einem Adressenraum der GPGPU 2720 und kann einen Teil oder die Gesamtheit von Systemspeicher 2712 aufweisen. In einer Ausführungsform kann der GPGPU-Speicher 2718 auch mindestens einen Teil von einem Speicher aufweisen, der zur ausschließlichen Verwendung durch die GPGPU 2720 bestimmt ist. In einer Ausführungsform kann der kompilierte Code 2714B, der im Systemspeicher 2712 gespeichert ist, in GPGPU-Speicher 2718 für Zugriff durch die GPGPU 2720 abgebildet sein.
  • Die GPGPU 2720 weist mehrere Rechenblöcke 2724A-2724N auf, die eine oder mehrere einer Vielzahl von hier beschriebenen Verarbeitungsressourcen aufweisen können. Die Verarbeitungsressourcen können eine Vielzahl verschiedener Berechnungsressourcen aufweisen oder nicht, wie zum Beispiel Ausführungseinheiten, Recheneinheiten, Streaming-Multiprozessoren, Grafikmultiprozessoren oder Mehrfachkerngruppen. In einer Ausführungsform weist die GPGPU 2720 zusätzlich einen Tensor-Beschleuniger 2723 auf, der eine oder mehrere Spezialfunktionsrecheneinheiten aufweisen kann, die zum Beschleunigen eines Teilsatzes von Matrixoperationen (z.B. Skalarprodukt usw.) bestimmt sind. Der Tensor-Beschleuniger 2723 kann auch als ein Tensor-Beschleuniger oder Tensor-Kern bezeichnet werden. In einer Ausführungsform können Logikkomponenten in dem Tensor-Beschleuniger 2723 über die Verarbeitungsressourcen der mehreren Rechenblöcke 2724A-2724N verteilt sein.
  • Die GPGPU 2720 kann auch einen Satz von Ressourcen aufweisen, die von den Rechenblöcken 2724A-2724N und dem Tensor-Beschleuniger 2723 gemeinsam benutzt werden können, aufweisend, ohne aber darauf beschränkt zu sein, einen Satz von Registern 2725, ein Leistungs- und Arbeitsleistungsmodul 2726 und einen Cache 2727. In einer Ausführungsform weisen die Register 2725 direkt und indirekt zugängliche Register auf, wo die indirekt zugänglichen Register zur Verwendung durch den Tensor-Beschleuniger 2723 optimiert sind. Das Leistungs- und Arbeitsleistungsmodul 2726 kann konfiguriert sein, Leistungsabgabe und Taktfrequenzen für die Rechenblöcke 2724A-2724N einzustellen, um leerlaufende Komponenten in den Rechenblöcken 2724A-2724N in der Leistung zu regulieren. In verschiedenen Ausführungsformen kann der Cache 2727 einen Befehls-Cache und/oder einen Daten-Cache tieferer Ebene aufweisen.
  • Die GPGPU 2720 kann zusätzlich einen L3 Daten-Cache 2730 aufweisen, der verwendet werden kann, um Daten zwischenzuspeichern, auf die von dem vereinheitlichten Speicher 2710 durch den Tensor-Beschleuniger 2723 und/oder die Rechenelemente in den Rechenblöcken 2724A-2724N zugegriffen werden kann. In einer Ausführungsform weist der L3 Daten-Cache 2730 einen geteilten lokalen Speicher 2732 auf, der von den Rechenelementen in den Rechenblöcken 2724A-2724N und dem Tensor-Beschleuniger 2723 gemeinsam benutzt werden kann.
  • In einer Ausführungsform weist die GPGPU 2720 Befehlshandhabungslogik, wie eine Abruf- und Decodiereinheit 2721 und eine Scheduler-Steuerung 2722, auf. Die Abruf- und Decodiereinheit 2721 weist eine Abruf- und Decodiereinheit auf, um Befehle zur Ausführung durch einen oder mehrere der Rechenblöcke 2724A-2724N oder den Tensor-Beschleuniger 2723 abzurufen und zu decodieren. Die Befehle können für die passende Funktionseinheit im Rechenblock 2724A-2724N oder Tensor-Beschleuniger über die Scheduler-Steuerung 2722 geplant werden. In einer Ausführungsform ist die Scheduler-Steuerung 2722 eine ASIC, die konfigurierbar ist, um hochentwickelte Planungsoperationen durchzuführen. In einer Ausführungsform ist die Scheduler-Steuerung 2722 eine Mikrosteuerung oder ein Niederenergie-pro-Befehl-Verarbeitungskern, der imstande ist, Scheduler-Befehle auszuführen, die von einem Firmwaremodul geladen werden.
  • In einer Ausführungsform können manche Funktionen, die von den Rechenblöcken 2724A-2724N durchzuführen sind, direkt für den Tensor-Beschleuniger 2723 geplant oder auf diesen abgeladen werden. In verschiedenen Ausführungsformen weist der Tensor-Beschleuniger 2723 Verarbeitungselementlogik auf, die konfiguriert ist, effizient Matrixrechenoperationen, wie Multiplikations- und Additionsoperationen und Skalarproduktoperationen durchzuführen, die von 3D-Grafik- oder Rechen-Shader-Programmen durchgeführt werden. In einer Ausführungsform kann der Tensor-Beschleuniger 2723 konfiguriert sein, Operationen zu beschleunigen, die von Maschinenlern-Frameworks verwendet werden. In einer Ausführungsform ist der Tensor-Beschleuniger 2723 eine anwendungsspezifische integrierte Schaltung, die explizit konfiguriert ist, einen bestimmten Satz von parallelen Matrixmultiplikations- und/oder Additionsoperationen durchzuführen. In einer Ausführungsform ist der Tensor-Beschleuniger 2723 ein feldprogrammierbares Gate Array (FPGA), das feste Funktionslogik bereitstellt, die zwischen Arbeitslasten aktualisiert werden kann. Der Satz von Matrixoperationen, der durch den Tensor-Beschleuniger 2723 durchgeführt werden kann, kann relativ zu den Operationen begrenzt sein, die durch den Rechenblock 2724A-2724N durchgeführt werden können. Der Tensor-Beschleuniger 2723 kann jedoch diese Operationen bei einem signifikant höheren Durchsatz relativ zu dem Rechenblock 2724A-2724N durchführen.
  • 28 veranschaulicht eine Matrixoperation 2805, die von einer Befehls-Pipeline 2800 gemäß einer Ausführungsform durchgeführt wird. Die Befehls-Pipeline 2800 kann konfiguriert sein, eine Matrixoperation 2805 durchzuführen, wie, ohne aber darauf beschränkt zu sein, eine Skalarproduktoperation. Das Skalarprodukt von zwei Vektoren ist ein Skalarwert der gleich einer Summe von Produkten entsprechender Komponenten der Vektoren ist. Das Skalarprodukt kann wie unten in Gleichung (1) dargestellt berechnet werden. a → ⋅ b → = ∑ i = 1 n a i b i = a 1 b 1 + ... + a n b n
    Figure DE102020130078A1_0001
  • Das Skalarprodukt kann in einer Konvolutionsoperation für ein Convolutional Neural Network (CNN) verwendet werden. 28 veranschaulicht eine zweidimensionale (2D) Konvolution unter Verwendung einer Matrixoperation 2805, aufweisend eine Skalarproduktoperation. Während 2D-Konvolution veranschaulicht ist, kann N-dimensionale Konvolution an einem N-dimensionalen Volumen unter Verwendung N-dimensionaler Filter durchgeführt werden. Eine rezeptive Feldkachel 2802 hebt einen Teil eines Eingangsvolumens in einem Eingangsvolumenpuffer 2804 hervor. Der Eingangsvolumenpuffer kann in Speicher 2830 gespeichert werden. Eine Punkt-Matrixoperation 2805 kann zwischen den Daten in der rezeptiven Feldkachel 2802 und einem konvolutionalen Filter durchgeführt werden, um einen Datenpunkt im Ausgangspuffer 2806 zu erzeugen, der auch in Speicher 2830 gespeichert werden kann. Der Speicher 2830 kann jeder der hier beschriebenen Speicher sein, aufweisend Systemspeicher 2712, GPGPU-Speicher 2718 oder einen oder mehrere Cache-Speicher 2727, 2730 wie in 27.
  • Die Kombination der Datenpunkte im Ausgangspuffer 2806 stellt eine Aktivierungskarte dar, die durch die Konvolutionsoperation erzeugt wird. Jeder Punkt in der Aktivierungskarte wird erzeugt, indem die rezeptive Feldkachel über den Eingangsvolumenpuffer 2804 geschoben wird. Die Aktivierungskartendaten können in eine Aktivierungsfunktion eingegeben werden, um einen Ausgangsaktivierungswert zu bestimmen. In einer Ausführungsform kann Konvolution des Eingangsvolumenpuffers 2804 in einem Framework als Matrixoperation hoher Ebene 2905 definiert sein. Die Matrixoperationen hoher Ebene können über Primitive-Operationen, wie eine grundlegende lineare algebraische Subprogramm- (BLAS) Operation durchgeführt werden. Die Primitive-Operationen können über Hardwarebefehle beschleunigt werden, die durch die Befehls-Pipeline 2800 ausgeführt werden.
  • Die Befehls-Pipeline 2800, die zum Beschleunigen von Hardwarebefehlen verwendet wird, kann die Befehlsabruf- und Decodiereinheit 2721, die Hardwarebefehle abrufen und decodieren kann, und die Scheduler-Steuerung 2722, die decodierte Befehle für eine oder mehrere Verarbeitungsressourcen in den Rechenblöcken 2724A-2724N planen kann, und/oder den Tensor-Beschleuniger 2723 aufweisen. In einer Ausführungsform kann ein Hardwarebefehl für die Rechenblöcke 2724A-2724N geplant und auf den Tensor-Beschleuniger 2723 abgeladen werden. Der eine oder die mehreren Hardwarebefehle und zugehörige Daten zum Durchführen der Matrixoperation 2805 können im Speicher 2830 gespeichert werden. Ausgang des Hardwarebefehls kann auch im Speicher 2830 gespeichert werden.
  • In einer Ausführungsform kann der Tensor-Beschleuniger 2723 einen oder mehrere Hardwarebefehle ausführen, um die Matrixoperation 2805 unter Verwendung eines integrierten systolischen Tensor-Arrays 2808 (DP-Logik) durchzuführen. Das systolische Tensor-Array 2808 kann eine Kombination von programmierbarer und Festfunktionshardware aufweisen, die konfigurierbar ist, um Skalarproduktoperationen durchzuführen. Während Funktionseinheiten in den Rechenblöcken 2724A-2724N auch konfiguriert sein können, Skalarproduktoperationen durchzuführen, kann das systolische Tensor-Array 2808 konfiguriert sein, einen begrenzten Teilsatz von Skalarproduktoperationen bei einem signifikant höheren Durchsatz relativ zu dem Rechenblock 2724A-2724N durchzuführen.
  • 29A-29B veranschaulichen Details von Hardware-basiertem systolischen Tensor-Array 2808 gemäß manchen Ausführungsformen. 29A veranschaulicht ein Gitter von mehreren Funktionseinheiten, die konfigurierbar sind, mehrere Skalarproduktoperationen im einem einzigen Taktzyklus durchzuführen. 29B veranschaulicht eine einzelne beispielhafte Funktionseinheit.
  • Wie in 29A dargestellt, ist in einer Ausführungsform das systolische Tensor-Array 2808 konfigurierbar, um einen Satz von parallelen Skalarproduktoperationen unter Verwendung einer Vielfalt von Funktionseinheiten durchzuführen. Die Skalarprodukte können auf ‚systolische‘ Weise durchgeführt werden, wobei SIMD-Daten über mehrere Schichten von Funktionseinheiten gepumpt werden. Das systolische Tensor-Array 2808 ist eine Sammlung von Funktionseinheiten, die in einem Gitter angeordnet sind. Das Gitter von Funktionseinheiten arbeitet im Gleichschritt und ist optimiert, Multiplikations-Akkumulationsoperationen durchzuführen. Matrizen, die von dem systolischen Tensor-Array 2808 bearbeitet werden sollen, werden in Teilmatrizen unterteilt, die über das Gitter von Funktionseinheiten gepumpt werden.
  • In einer Ausführungsform kann das systolische Tensor-Array 2808 eine konfigurierbare Anzahl von SIMD-Kanälen von Daten unter Verwendung einer konfigurierbaren systolischen Tiefe verarbeiten. Für einen bestimmten Befehl können eine SIMD-Breite und eine systolische Tiefe gewählt werden, um einen Satz von Quellendaten zu verarbeiten. Die systolische Tiefe definiert die Anzahl von systolischen Schichten von Hardwarelogik, die zum Verarbeiten eines Befehls verwendet werden. Eine systolische Schicht ist eine Gruppe von Multiplikator- und Addiererlogikeinheiten mit einer variablen SIMD-Breite, wo die systolische Schicht einen anfänglichen Akkumulatorwert als Eingang empfangen kann und einen Skalarproduktwert zur Ausgabe an eine folgende systolische Schicht oder an ein Ausgaberegister erzeugt.
  • In manchen Ausführungsformen können drei Quellen verarbeitet werden, wo jede Quelle ein Vektorregister oder eine Zwischeneinheit sein kann. In einer Ausführungsform kann Quelle 2900 (SRC0) ein oder mehrere anfängliche Akkumulatorwerte sein, der ein einzelner Wert oder ein Vektor von Akkumulatorwerten sein kann. Der anfängliche Akkumulatorwert wird zu dem ersten Satz von Skalarprodukten addiert, die von jeder Funktionseinheit in der ersten systolischen Schicht berechnet werden. Das Skalarprodukt, das von einer Funktionseinheit berechnet wird, 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 aufweisen können, wobei jeder Kanal einen Vier-Element-Vektor aufweist. In einer Ausführungsform ist jeder 32-Bit breit und stellt vier 8-Bit Vektorelemente bereit. Manche Ausführungsformen sind konfigurierbar, um Skalarprodukte aus Eingangsvektoren mit 8-Bit Elementen, 4-Bit Elementen und/oder 2-Bit Elementen zu berechnen. In einer Ausführungsform können gemischte Präzisionsoperationen unter Verwendung einer Kombination von unterstützten Elementgrößen (z.B. 8-Bit x 2-Bit, 8-Bit x 4-Bit, 4-Bit x 4-Bit usw.) durchgeführt werden. In einer Ausführungsform ist das systolische Tensor-Array 2808 zur Ganzzahlberechnung konfiguriert, obwohl in manchen Ausführungsformen automatische Festkommaoperation konfigurierbar ist. Obwohl der hier beschriebene Befehl ein Vier-Element-Skalarprodukt ist, kann in manchen Ausführungsformen das systolische Tensor-Array 2808 auch konfiguriert sein, Gleitkommaskalarproduktberechnungen an einer unterschiedlichen Anzahl von Elementen pro Vektor zu unterstützen.
  • In einer Ausführungsform können mehrere Kanälen von Vier-Element-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 Tensor-Array 2808 für mehrere Kanäle von Vektorelementen berechnet werden, die über Quelle 2901 und Quelle 2902 bereitgestellt werden. Die Anzahl von Kanälen von Vektorelementen, die zu verarbeiten sind, kann basierend auf einer gewählten Ausführungsgröße und systolischen Tiefe für die Skalarproduktberechnung konfiguriert werden. In einer Ausführungsform können Quellenvektoren, die breiter als die spezifizierte Ausführungsgröße und/oder systolische Tiefe sind, unter Verwendung mehrerer Zyklen des systolischen Tensor-Arrays 2808 berechnet werden.
  • Die Anzahl von Berechnungen, die in einem bestimmten Taktzyklus durchgeführt werden kann, kann basierend auf der Anzahl von SIMD-Bahnen und systolischen Schichten variieren. Das systolische Tensor-Array 2808, wie veranschaulicht, kann bei einem Durchsatz von sechzehn Skalarprodukte pro SIMD-Bahn unter Verwendung einer systolischen Tiefe von vier arbeiten. Falls für acht SIMD-Bahnen konfiguriert, kann die Logik 128 Acht-Bit Ganzzahl- (INT8) Skalarprodukte in einem bestimmten Zyklus durchführen. Falls für acht SIMD-Bahnen und eine systolische Tiefe von acht konfiguriert, kann jede Bahn 32 Acht-Bit Ganzzahl- (INT8) Skalarprodukte und insgesamt 256 Skalarprodukte durchführen. Diese bestimmte Anzahl von Operationen ist für eine Ausführungsform beispielhaft und andere Ausführungsformen variieren im Durchsatz. Überdies, wenn die Datenarten anders sind, wird die Anzahl von Operationen basierend auf den anderen Datenarten skaliert.
  • Bei jeder Funktionseinheit wird ein Skalarprodukt über Multiplikator- und Addiererlogik berechnet und das Skalarprodukt wird zu einem Akkumulatorwert addiert. Die resultierenden Daten können an ein Zielortregister ausgegeben oder dem Akkumulator der nächsten systolischen Schicht bereitgestellt werden. Details einer Funktionseinheit 2912 sind in 29B dargestellt.
  • Wie in 29B dargestellt, kann eine Funktionseinheit 2912 einen Satz von Eingangsdatenpuffer 2904, 2906 und einen Akkumulator 2922 aufweisen, die jeweils Eingangsdaten annehmen können. In einer Ausführungsform kann Datenpuffer 2906 Quelle 2902, (SRC2), annehmen, die ein gepackter Vektor von Eingangsdaten sein kann. Eingangsdatenpuffer 2904 kann eine Quelle 2901 (SRC1), annehmen, die auch ein gepackter Vektor von Eingangsdaten sein kann. Der Akkumulator 2922 kann Quelle 2900 (SRC0) annehmen, die einen anfänglichen Akkumulatorwert für die Funktionseinheit 2912 bereitstellt. Der anfängliche Akkumulatorwert wird zu dem Skalarprodukt addiert, das aus den Elementen von Quelle 2901 und Quelle 2902 berechnet wird. Das Skalarprodukt wird über eine elementweise Multiplikation des Quellenvektors unter Verwendung eines Satzes von Multiplikatoren 2923A-2923D und eines Addierers 2924 berechnet. Die Multiplikatoren 2923A-2923D werden verwendet, um einen Satz von Produkten zu berechnen. Eine Summe des Satzes von Produkten wird von dem Addierer 2924 berechnet. Die Summe kann mit jedem anfänglichen Wert akkumuliert (z.B. zu diesem addiert) werden, der über Quelle 2900 bereitgestellt wird. In einer Ausführungsform kann dieser akkumulierte Wert dem nächsten Akkumulator, der sich in einer folgenden systolischen Schicht befinden kann, als ein Eingangswert 2926 bereitgestellt werden. In einer Ausführungsform kann Quelle 2901 mehrere Kanäle von Eingangsdaten aufweisen. Zusätzliche Kanäle von Quelle 2901 können als SRC1-Eingang zu zusätzlichen SIMD-Bahnen 2928 weitergeleitet werden. In einer Ausführungsform kann Quelle 2902 mehrere Kanäle von Eingangsdaten aufweisen. Zusätzliche Kanäle von Quelle 2902 können als SRC2-Eingangsdaten zu Logikeinheiten im zusätzlichen systolischen Tiefen verwendet werden. In einer Ausführungsform kann Quelle 2900 optional mehrere Kanäle aufweisen, wobei zusätzliche Kanäle als Eingang zu dem Akkumulator in zusätzlichen Funktionseinheiten bereitgestellt sind. In einer Ausführungsform kann Quelle 2900 ein einzelner Wert sein, der zu jedem Akkumulator in jeder Funktionseinheit der anfänglichen systolischen Schicht addiert wird.
  • 30 veranschaulicht eine Verarbeitungsressource 3000, aufweisend ein systolisches Tensor-Array mit Sparse-Optimierungen gemäß einer Ausführungsform. Die Verarbeitungsressource 3000 weist ähnliche Komponenten wie die Ausführungseinheit 1900 auf, gemeinsam mit einem Tensor-Beschleuniger 3012 mit Sparse-Optimierungen. Varianten der Verarbeitungsressource 3000 können in einem parallelen Rechenbeschleuniger, einer Grafikverarbeitungs-Engine und/oder einem neuralen Netzwerkbeschleuniger verwendet werden. Der Tensor-Beschleuniger 3012 kann ein systolisches Tensor-Array 2808 wie in 28 oder ein systolisches Array 1912 wie in 19 aufweisen und ähnliche Funktionalität haben. Andere Matrixbeschleunigungsarchitekturen können auch verwendet werden. Die Sparse-Optimierungen des Tensor-Beschleunigers 3012 sind unten ausführlicher erklärt.
  • Optimierte Trainings- und Schlussfolgerungen an einem systolischen Array, wenn spärliche Daten verwendet werden
  • Eine Ausführungsform stellt Techniken zum Optimieren von Trainings- und Schlussfolgerungen auf einem systolischen Array bereit, wenn spärliche Daten verwendet werden. Wenn eine Teilmatrix, die durch das systolische Tensor-Array 2808 zu verarbeiten ist, zur Gänze null ist, kann ein Dimensionswert für die Teilmatrix auf null gestellt werden und das systolische Tensor-Array 2808 kann eine oder mehrere Berechnungsphasen umgehen, die mit der Teilmatrix verknüpft sind, abhängig von der durchzuführenden Operation. Während Vorverarbeitung von Matrixdaten können Null-Teilmatrizen identifiziert werden und eine Teilmatrixkarte für die Matrix kann erzeugt werden um anzugeben, welche Teilmatrizen nur Nullwerte aufweisen. In einer Ausführungsform können auch Teilmatrizen umgangen werden, die nur einen Nicht-Null-Wert aufweisen.
  • 31A-31B veranschaulicht ein System zum Umgehen von Nullwert-Teilmatrizen gemäß Ausführungsformen. Wie in 31A dargestellt, sind Matrix 3102 und Matrix 3104 Matrizen, in welchen ein oder mehrere Teilmatrizen nur Nullwerte aufweisen. Verarbeitungslogik kann eine Teilmatrixkarte 3112 für Matrix 3102 und eine Teilmatrixkarte 3114 für Matrix 3104 erzeugen um anzugeben, ob eine Teilmatrix nur Nullwerte enthält. Die Teilkarte kann unter Verwendung einer Reihe von Techniken erzeugt werden, aufweisend Durchführen eines bitweisen Vergleichs mit null für jede Teilmatrix. Die Teilmatrixkarten können durch Framework- oder Treiberlogik erzeugt werden, die auf Allzweckverarbeitungslogik (z.B. CPUs) laufen, oder können durch dedizierte Hardwarelogik in den Verarbeitungsressourcen erzeugt werden.
  • In einer Ausführungsform kann auch eine Nicht-Null-Einzelwert-Teilmatrix 3105, die einen einzigen Nicht-Null-Wert aufweist, umgangen werden, wodurch die Matrixoperation unter Verwendung einer ALU anstatt des systolischen Tensor-Arrays berechnet werden kann.
  • Wie in 31B dargestellt, kann ein Speicher 3120 Matrix 3102 und Matrix 3104 speichern. Das systolische Tensor-Array 2808 kann eine Matrix A-Ladeeinheit 3126, Matrix B-Ladeeinheit 3122, eine Matrix A-Zufuhreinheit 3128 und Matrix B-Zufuhreinheit 3124 aufweisen. Matrix 3102 kann als Matrix B geladen und zugeführt werden, während Matrix 3104 als Matrix A geladen und zugeführt werden kann. Teilmatrizen von Matrix A und Matrix B können durch die Funktionseinheiten 3130 geladen und zugeführt werden, die als die Verarbeitungselemente des systolischen Tensor-Arrays 2808 arbeiten.
  • In einer Ausführungsform kann eine Lade-B-Filter 3127 und Lade-A-Filter 2127 einen Puffer zum Speichern der Teilmatrixkarte 3112 für Matrix 3102 und Teilmatrixkarte 3114 für Matrix 3104 aufweisen. Der Lade-B-Filter 3121 kann das Laden von Nullwert-Teilmatrizen durch die Matrix B-Ladeeinheit 3122 umgehen. Der Lade-A-Filter 3127 das Laden von Nullwert-Teilmatrizen durch die Matrix A-Ladeeinheit 3126 umgehen. Teilmatrizen, die nicht umgangen werden, können von den Funktionseinheiten 3130 verarbeitet werden. Abhängig von der Operation, die durch das systolische Tensor-Array 2808 durchzuführen ist, kann die gesamte Operation umgangen werden, wo eine der Teilmatrizen null ist. Wenn die Teilmatrix eine Nicht-Null-Einzelwert-Teilmatrix aufweist, können die Teilmatrizen, die mit der durchzuführenden Operation verknüpft sind, das systolische Tensor-Array 2808 umgehen und die Operation kann durch eine ALU durchgeführt werden.
  • 32 veranschaulicht eine Rechenressource 3010, aufweisend Logik, um das systolische Tensor-Array 2808 für Operationen an einer Teilmatrix zu umgehen, die einen Nicht-Null-Einzelwert aufweisen. Elemente von Matrix 3102 und Matrix 3104, die im Speicher 3120 gespeichert sind, können in die Registerdatei 3006 der Rechenressource 3010 geladen werden. Der Tensor-Beschleuniger 3012 kann Logik aufweisen, um eine Teilmatrixumgehungsnachricht 3202 an die ALU 3011 zu senden, die die Register, die umgangene Teilmatrixdaten 3204 speichern, und die umgangene durchzuführende Operation angibt. Die ALU 3011 kann dann die umgangene Operation unter Verwendung von Vektorverarbeitungslogik durchführen. Die Verarbeitung der umgangenen Operation kann parallel mit den nicht umgangenen Operationen durchgeführt werden, die von dem Tensor-Beschleuniger 3012 durchgeführt werden.
  • Verwendung von Dekompressionsinformationen bei Durchführung von Sparse-Rechenoperationen
  • 33 veranschaulicht eine Rechenarchitektur 3300, die konfiguriert ist, komprimierte Übertragung neuraler Netzwerkdaten zu Verarbeitungsressourcen auf einem parallelen Rechenprozessor oder einer Allzweckgrafikverarbeitungseinheit gemäß einer Ausführungsform durchzuführen. Die Rechenarchitektur 3300 weist in einer Ausführungsform einen Rechenblock 3302 und Hardware-Scratch-Puffer 3304 auf, der über eine DMA-Steuerung 3306 an Speicher 3308 gekoppelt ist. Der Speicher 3308 kann Hauptspeicher oder Systemspeicher eines Datenverarbeitungssystems sein. Der Rechenblock 3302 weist einen Satz von Verarbeitungsressourcen wie hier beschrieben auf und kann einem der Rechenblöcke 2724A-2724N wie in 27 ähnlich sein. Der Scratch-Puffer 3304 kann ein Hochgeschwindigkeit-On-Chip-Speicher, wie statischer On-Chip-Direktzugriffsspeicher (SRAM) sein. In einer Ausführungsform ist der Scratch-Puffer 3304 optimiert, um Merkmalblockeinheiten oder Kernelblockeinheiten für neurale Netzwerkoperationen zu speichern, die durch den Rechenblock 3302 durchgeführt werden.
  • In einer Ausführungsform kann der Decodierer 3312 Hardware-Decodierlogik sein, die in den Rechenblock 3302 integriert ist, um komprimierte Übertragung neuraler Netzwerkdaten über die Rechenarchitektur zu ermöglichen. Wenn zum Beispiel ein CNN verarbeitet wird, kann der Rechenblock 3302 Ausgangsmerkmalkarten- (OFM, Output Feature Map) Daten im-Scratch-Puffer 3304 in einem unkomprimierten Format erzeugen. Ein Codierer 3316, der in die DMA-Steuerung 3306 integriert ist, um Schreiben der Ausgangsmerkmalkartendaten in dem Speicher 3308 in einem komprimierten Format zu ermöglichen. Wenn die OFM einer Schicht die Eingangsmerkmalkarte (IFM, Input Feature Map) der nächsten Schicht wird, werden diese IFMs aus Speicher 3308 als komprimierte Daten 3314 gelesen und im Scratch-Puffer 3304 gespeichert. Der Decodierer 3312 kann dem Rechenblock 3302 ermöglichen, die komprimierten Daten 3314 einzulesen, ohne dass die Daten decodiert werden müssen. Alternativ kann eine Codec-Einheit mit sowohl Codier- als auch Decodierlogik in die DMA-Steuerung 3306 integriert sein, die komprimierte Daten freigibt, die zu übertragen und von der DMA-Steuerung 3306 zu lesen sind. Die Merkmalskartendaten können dann durch die DMA-Steuerung 3306 dekomprimiert und in einem unkomprimierten Format in den Scratch-Puffer 3304 geschrieben werden, um von dem Rechenblock 3302 gelesen zu werden.
  • In den hier beschriebenen Ausführungsformen kann das Codierformat für Kernel- und Merkmalsdaten basierend auf der Statistik der zu codierenden Daten variiert werden. Analyse von neuralen Netzwerk-Merkmalskartendaten gibt an, dass viele Merkmalskarten äußert dünn besetzt sein können. Analyse von neuralen Netzwerk-Kerneldaten gibt an, dass während die Kerneldaten nicht so spärlich sind, wie die Merkmalskartendaten, viele Werte in den Kerneldaten wiederholt werden. Der dynamische Bereich von Kerneldaten ist relativ niedrig, was angibt, dass Rohdaten mehr Bits zuordnen als zum Speichern der Koeffizienten notwendig sind. Bei Verwendung variierter Codierungstechniken können Merkmalskarte und Kerneldaten um bis zu 80% verlustlos unter Verwendung einer Auswahl verschiedener Codierungstechniken komprimiert werden.
  • Daten, die sich auf das neurale Netzwerk beziehen, können unter Verwendung einer Vielfalt von Codierungstechniken codiert (z.B. komprimiert) werden, wie, ohne aber darauf beschränkt zu sein, Einzigartiger Absolutwert- (UAV, Unique Absolute Value) Tabellencodierung, Signifikanzkarten- (SM, Significance Map) Codierung, Tabellencodierung (TE, Table Encoding), Einzigartige Wertkoordinaten- (UVC, Unique Value Coordinate) Codierung und Mittelwertcodierung (ME, Mean Encoding). Metadaten für die codierten Daten geben die Art von Codierungsformat an, das für die Daten verwendet wird. In einer Ausführungsform können bestimmte Codierungsformate für bestimmte Arten von Daten, wie Kemeldaten oder Merkmalsdaten, ausgewählt werden. In einer Ausführungsform wird statistische Analyse an den Daten vor Codierung durchgeführt um zu ermöglichen, dass ein richtiger Codierer für jeden Block von Daten gewählt wird.
  • In einer Ausführungsform können Daten, die während SM-Codierung erzeugt werden, verwendet werden, um Umgehen einer Teilmatrix in einem systolischen Tensor-Array zu erleichtern. Im SM-Codierungsmodus werden nur Nicht-Null-Werte in einem Block codiert. Die Anzahl von Nicht-Null-Werten in einem Abtastungsblock wird im Header angegeben, gefolgt von einer Signifikanzkarte, die eine Karte der Nicht-Null-Werte in dem Block angibt. Die Nicht-Null-Werte der Abtastung werden dann in der Reihenfolge ihres Erscheinens in dem Strom codiert.
  • 34A-34B veranschaulicht Signifikanzkartencodierung für spärliche neurale Netzwerkdaten gemäß Ausführungsformen. 34A veranschaulicht ein Codierungslayout 3420 für SM-Codierung. 34B veranschaulicht Decodieren eines beispielhaften Bit-Strom-Signifikanzkarte-codierten Bit-Stroms.
  • Wie in 34A dargestellt, ermöglicht ein Codierungslayout 3420, dass Abtastungsblöcke spärlicher neuraler Netzwerkdaten in einem reduzierten Bit-Format codiert werden, das die Menge an Daten reduziert, die übertragen und gespeichert werden muss, wenn neurale Netzwerke verarbeitet werden, die mit den Daten verknüpft sind. In dem veranschaulichten Codierungslayout 3420 ist die Anzahl von Nicht-Null-Werten in einem Abtastungsblock in einem Header 3422 angegeben, gefolgt von einer Signifikanzkarte 3424. die eine Karte der Nicht-Null-Werte in dem Block angibt. Die Nicht-Null-Werte 3426 der Abtastung werden in der Reihenfolge ihres Erscheinens in dem Strom codiert.
  • Wie in 34B dargestellt, können codierte Bitstromdaten basierend auf Signifikanzkartendaten decodiert werden. In einer Ausführungsform werden SM-Codierungsmodusdaten präsentiert, beginnend mit dem dritten Byte nach einem Zwei-Byte-Header, wo das Vorhandensein von SM-Codierung durch das ersten Bit eines Bit-Strom-Headers (nicht dargestellt) am Beginn eines codierten Datenstroms angegeben ist. Die Anzahl von Nicht-Null-Werte in einem Abtastblock ist in dem Header 3422 angegeben. In einer Ausführungsform kann sich das Codierungsformat auf einer Basis pro Abtastblock ändern, so dass Header 3422 auch Metadaten aufweisen kann, die angeben, dass SM-Codierung für den anstehenden Block von Abtastungen freigegeben ist. Eine Signifikanzkarte 3424 gibt eine Karte der Nicht-Null-Werte in dem Abtastblock an, mit einem Eins-Bit-Eintrag, der jedem Wert zugeordnet ist. Die Nicht-Null-Werte 3426 der Abtastung werden dann in der Reihenfolge ihres Erscheinens in dem Strom codiert. Zum Decodieren von Signifikanzkartendaten in den beispielhaften decodierten Bit-Strom 3430 kann Decodierlogik mindestens einen Teil eines Ausgangsdatenpuffers 3410 auf null initialisieren. Die Decodierlogik kann dann auf die Signifikanzkarte 3424 Bezug nehmen um zu bestimmen, welche Werte in dem Bit-Strom nicht null sind. Die Nicht-Null-Werte können der Reihe nach entpackt und zu Stellen in dem Ausgangsdatenpuffer 3410 geschrieben werden, die durch die Signifikanzkarte angegeben sind. Zum Beispiel gibt ein Wert von null (0b0) in der Signifikanzkarte 3424 an, dass der entsprechende decodierte Wert null ist. Ein Wert von eins (0b1) in der Signifikanzkarte 3424 gibt an, dass der entsprechende decodierte Wert dem nächstfolgenden Eintrag in den Nicht-Null-Werten 3426 im codierten Bit-Strom entspricht.
  • 35 veranschaulicht die Verwendung von Signifikanzkartendaten, um das Umgehen oder Takt/Leistung-Gating von Elementen eines systolischen Tensor-Arrays zu erleichtern. In einer Ausführungsform kann ein Decodierer 3312 in einem Rechenblock 3302 die Signifikanzkarte 3506 für dekomprimierte Daten 3508 bereitstellen, die unter Verwendung von Signifikanzkartencodierung codiert wurde. In einer Ausführungsform kann der Decodierer die Signifikanzkarte 3506 für Daten erzeugen, die unter Verwendung einer anderen (Nicht-Signifikanzkarten-) Codierung codiert wurden. Die Signifikanzkarte 3506 und dekomprimierten Daten 3508 können vom Decodierer 3312 einer Verarbeitungsressource 3000 in dem Rechenblock 3404 bereitgestellt werden. Umgehungs-/Gate-Logik 3510 in dem systolischen Tensor-Array 2808 kann bestimmen, Teilmatrizen in den dekomprimierten Daten 3508 zu umgehen und/oder gewisse Verarbeitungselemente in dem systolischen Tensor-Array basierend auf dem Grad an Dünnbesetztheit einem Clock-Gating zu unterziehen, das durch die Signifikanzkarte 3506 und/oder die bestimmten Null- und Nicht-Null-Elemente angegeben ist, die durch die Signifikanzkarte 3506 spezifiziert sind.
  • Umwandeln spärlicher Daten unter Verwendung numerischer Transformationen
  • In einer Ausführungsform wird Training erweitert, um Transformation von Gewichten aufzuweisen, um Nicht-Null-Koeffizienten in derselben Region zu verdichten, um Verbrauch an Speicherbandbreite zu verringern. Das Trainingssystem kann mehrere verschiedene Transformationen testen, wie eine diskrete Kosinustransformation (DCT), diskrete Sinustransformation (DST), Bit-Flip-Transformationen, Bit-Rotations-Transformationen oder andere Arten von Transformationen (z.B. diskrete Fourier-Transformationen (DFT) usw.). Das Trainingssystem kann die Transformation wählen, die zu dem engsten Clustering von Nicht-Null-Koeffizienten und/oder dem höchsten Kompressionsverhältnis führt, wenn die Trainingsdaten komprimiert werden. In einer Ausführungsform kann das Trainingssystem die Transformation wählen, die unregelmäßige Dünnbesetztheit in strukturierte oder Blockdünnbesetztheit transformiert. Der ausgewählte Transformationsmodus wird im trainierten Modell signalisiert. Das transformierte trainierte Modell wird Schlussfolgerungsanwendungen bereitgestellt. Die richtige Umkehrtransformation wird von dem Schlussfolgerungssystem angewendet.
  • 36 veranschaulicht ein System 3600 zum Transformieren neuraler Netzwerkdaten zu kompakten Nicht-Null-Koeffizienten gemäß einer Ausführungsform. System 3600 weist ein Trainingssystem 3602, ein Transformationssystem 3604, Umkehrtransformationssystem 3608 und ein Schlussfolgerungssystem 3610 auf. Das Trainingssystem 3602 und Transformationssystem 3604 können auf einer Rechenvorrichtung oder einem Cluster mehrerer Rechenvorrichtungen liegen. Das Umkehrtransformationssystem 3608 und Schlussfolgerungssystem 3610 können auf einer separaten Rechenvorrichtung oder einem Cluster von Rechenvorrichtungen liegen. Die Komponenten des Systems 3600 können auch auf einem einzelnen Rechensystem oder Rechencluster liegen, der sowohl Trainings- als auch Schlussfolgerungsoperationen durchführt wie ein Rechensystem auf Basis eines Datenzentrums, das Cloud-basiertes Training und Schlussfolgerung durchführt.
  • Ein einzelnes Rechensystem oder ein Rechencluster können auch verwendet werden, wo Modell-Neutraining oder Aktualisierung durchzuführen ist. Gewichte für ein trainiertes Modell können in einem transformierten und komprimierten Zustand gespeichert werden. Wenn ein Modell neu trainiert oder aktualisiert werden soll, können die Gewichte dekomprimiert werden, eine Umkehrtransformation kann an diesen Gewichten angewendet werden und Neutraining oder Aktualisierung können durchgeführt werden, um einen aktualisierten Satz von Gewichten zu erzeugen. Dieser aktualisierte Satz von Gewichten kann dann für Datenspeicher oder Nutzung in einem Schlussfolgerungssystem retransformiert und rekomprimiert werden.
  • In einer Ausführungsform kann das Trainingssystem 3602, das einen Tensor-Beschleuniger (z.B. Tensor-Beschleuniger 2723 wie in 27) wie hier beschrieben aufweisen kann, eine Matrix von Gewichten 3603 infolge von Trainingsoperationen erzeugen, die an einem neuralen Netzwerk durchgeführt werden. Die Matrix von Gewichten kann durch das Transformationssystem 3604 verarbeitet werden. Das Transformationssystem 3604 kann eine Transformationsart bestimmen, die an der Matrix von Gewichten 3603 anzuwenden ist. Das Transformationssystem kann dann einen Satz von transformierten Gewichte 3607 und die Transformationsart 3605 ausgeben, die bei diesen transformierten Gewichten angewendet wird. Der Satz von transformierten Gewichten 3607 kann dann zur Datenspeicherung oder zur Übertragung komprimiert oder codiert werden. Die Transformation wird so durchgeführt, dass der Satz von transformierten Gewichten 3607 auf ein höheres Kompressionsverhältnis komprimiert wird als die ursprüngliche Matrix von Gewichten 3603. Das höhere Kompressionsverhältnis, zu dem der Satz von transformierten Gewichten 3607 komprimiert werden kann, kann auf einen höheren Grad an Dünnbesetztheit zurückzuführen sein, der in dem Satz von transformierten Gewichten 3607 vorhanden ist, oder auf eine Transformation von unregelmäßiger Dünnbesetztheit zu strukturierter oder Blockdünnbesetztheit. Strukturierte oder Blockdünnbesetztheit und/oder ein höherer Grad an Dünnbesetztheit können auch die Effizienz verbessern, mit der eine dünnbesetzte transformierte Matrix in einem Sparse-Codierungsformat codiert werden kann (z.B. Koordinatenlistencodierung (COO), komprimierte Sparse-Reihe (CSR), komprimierte Sparse-Spalte (CSC) usw.). In einer Ausführungsform kann eine Sparse-Matrix transformierter Gewichte sowohl in einem Sparse-Codierung Format komprimiert werden als auch zu einem komprimierten codierten Format komprimiert werden.
  • Die transformierten Gewichte 3607 und Transformationsart 3605 können zur Verwendung von einem Rechensystem gespeichert werden, das konfiguriert ist, Schlussfolgerungsoperationen durchzuführen. Wo die transformierten Gewichte 3607 komprimiert sind, können die transformierten Gewichte dekomprimiert werden, bevor die Umkehrtransformation von dem Umkehrtransformationssystem 3608 angewendet wird. Das Umkehrtransformationssystem 3608 kann eine Umkehrtransformationsoperation an den transformierten Gewichten 3607 basierend auf der angegebenen Transformationsart 3605 durchführen. Das Umkehrtransformationssystem 3608 kann eine Matrix von Gewichten 3609 an das Schlussfolgerungssystem 3610 ausgeben, um Schlussfolgerungsoperationen basierend auf Eingangsdaten auszuführen.
  • 37A-37B veranschaulicht Logikeinheiten, um Transformationen und Umkehrtransformationen an spärlichen neuralen Netzwerkdaten durchzuführen. 37A veranschaulicht Logikeinheiten des Transformationssystems 3604. 37B veranschaulicht Logikeinheiten des Umkehrtransformationssystems 3608. Das Transformationssystem 3604 und Umkehrtransformationssystem 3608 können jeweils internen Speicher aufweisen und/oder mit Speicher einer Rechenvorrichtung oder eines Rechensystems gekoppelt sein, in dem das Transformationssystem 3604 und Umkehrtransformationssystem 3608 enthalten sind
  • Wie in 37A dargestellt, kann das Transformationssystem 3604 einen Speicher 3701, einen Transformationsselektor 3702 und einen Satz von Transformationslogikeinheiten 3704A-3704N aufweisen. Der Satz von Transformationslogikeinheiten 3704A-3704N kann Hardware- oder Firmwarelogik aufweisen, um zum Beispiel DCT, DST, Bit-Flip, Bit-Rotation oder andere Transformationen (z.B. DFT usw.) durchzuführen. Für die DCT-Transformation wird eine verlustlose Transformation verwendet. In manchen Konfigurationen jedoch kann eine verlustbehaftete DCT angewendet werden, wenn die Genauigkeit des Modells nicht signifikant beeinträchtigt wird. In einer Ausführungsform wird der Satz von Transformationslogikeinheiten 3704A-3704N als GPGPU-ausführbarer Programmcode der Form von Rechen-Shader oder CUDA-Kernels implementiert, die durch eine hier beschriebene GPGPU ausgeführt werden können.
  • Die Transformationstestlogik 3703 kann repräsentative Abtastungen der Matrix von Gewichten 3603 in Speicher 3701 laden und die Abtastungen testen, um eine Transformation zu bestimmen, die zu dem höchsten Grad an Dünnbesetztheit, dem engsten Clustering von Nicht-Null-Koeffizienten und/oder dem höchsten Kompressionsverhältnis führt, wenn die Trainingsdaten komprimiert werden. In einer Ausführungsform kann die Transformationstestlogik 3703 Transformationstestdaten analysieren und Metrik entwickeln, die mit dem Abstand zwischen Nicht-Null-Werten in den Testtransformationsdaten zusammenhängt. In einer Ausführungsform kann die Transformationstestlogik 3703 auch Testtransformationsdaten analysieren, um Metrik zu den möglichen Kompressionsverhältnissen, Dünnbesetztheitsebene oder Dünnbesetztheitsmuster der transformierten Daten zu bestimmen. In Ausführungsformen, in welchen Kompressionsverhältnis als eine Qualitätsmetrik verwendet wird, wenn Transformationen verglichen werden, kann die Transformationstestlogik 3703 Logik aufweisen, um einen Kompressionstest an den transformierten Daten durchzuführen. Die Transformationstestlogik kann auch bestimmen, ob keine Transformation vorhanden ist, die das geplante Ergebnis erzeugt. In einem solchen Szenario kann Transformation abhängig von der Systemkonfiguration umgangen werden.
  • Sobald eine optimale Transformation bestimmt ist, kann die Transformationstestlogik 3703 dann eine Empfehlung an den Transformationsselektor 3702 senden, welche Einheit in dem Satz von Transformationslogikeinheiten 3704A-3704N für Transformation der Matrix von Gewichten in transformierte Gewichte 3607 zu verwenden ist. In einer Ausführungsform kann die Transformationstestlogik 3703 konfiguriert sein, eine Transformationsempfehlung zu erzeugen, ohne die Transformation an den Matrixdaten anzuwenden. In solchen Ausführungsform kann die Transformationstestlogik 3703 Metrik, die mit den numerischen Transformationstests verbunden ist, gemeinsam mit einer Transformationsempfehlung bereitstellen. Ferner, wenn in einer solchen Ausführungsform Transformation möglich ist, kann der Transformationsselektor 3702 auch Testmetrik berücksichtigen, die von der Transformationstestlogik 3703 erzeugt wird. Der Transformationsselektor 3702 kann dann unter gewissen Umständen eine andere Transformation als die empfohlene Transformation wählen. Wenn zum Beispiel die Metrik angibt, dass zum Beispiel die Verbesserung im Kompressionsverhältnis unter einem Schwellenwert liegt, kann die Transformation umgangen werden. Der Schwellenwert kann auf der Basis eines aktuellen Prozessorstatus variieren (z.B. thermische Last, verfügbare Bandbreite usw.). In einer Ausführungsform wird die Transformationstestlogik 3703 umgangen, wenn das Transformationssystem 3604 angewiesen wird, eine bestimmte Transformation anzuwenden.
  • In einer Ausführungsform können verschiedene Transformationen für Teilmatrizen einer Gewichtsmatrix verwendet werden. Wenn zum Beispiel die Transformationstestlogik bestimmt, dass ein erster Teil einer Gewichtsmatrix das höchste Kompressionsverhältnis hätte, wenn unter Verwendung einer ersten Transformation transformiert, während ein zweiter Teil der Gewichtsmatrix das höchste Kompressionsverhältnis hätte, wenn unter Verwendung einer zweiten Transformation transformiert, kann die erste Transformation an dem ersten Teil angewendet werden, während die zweite Transformation an dem zweiten Teil angewendet werden kann. Wenn mehrere verschiedene Transformationen für eine Gewichtsmatrix verwendet werden, kann die Transformationsart 3605 eine Matrix oder ein Bitfeld sein, die bzw. das angibt, welche Transformationsart für eine entsprechende Gewichtsteilmatrix verwendet wird. In manchen Ausführungsformen können auch mehrere Transformationen an derselben Teilmatrix oder der gesamten Gewichtsmatrix angewendet werden.
  • Wie in 37B dargestellt, weist das Umkehrtransformationssystem 3608 einen Umkehrtransformationsselektor 3712 und einen Satz von Umkehrtransformationslogikeinheiten 3714A-3714N auf. Der Satz von Umkehrtransformationslogikeinheiten 3714A-3714N kann Hardware- oder Firmwarelogik aufweisen, um Umkehrtransformationen der Transformationen durchzuführen, die durch den Satz von Transformationslogikeinheiten 3704A-3704N des Transformationssystems 3604 durchgeführt werden. In einer Ausführungsform ist der Satz von Umkehrtransformationslogikeinheiten 3714A-3714N als GPGPU-ausführbarer Programmcode in der Form von Rechen-Shader oder CUDA-Kernels implementiert, die durch eine hier beschriebene GPGPU ausgeführt werden können.
  • Der Umkehrtransformationsselektor 3712 kann die Transformationsart 3605 lesen, die an den transformierten Gewichten 3607 angewendet wird, und eine Umkehrtransformation unter Verwendung der richtigen Umkehrtransformationseinheit in dem Satz von Umkehrtransformationslogikeinheiten 3714A-3714N durchführen, um eine Matrix von Gewichten 3609 zu erzeugen. Umkehrtransformation wird gemäß der Transformationsart 3605 durchgeführt, die mit den transformierten Gewichten 3607 verknüpft ist. Wenn die Transformationsart 3605 angibt, dass verschiedene Transformationen bei verschiedenen Teilmatrizen der transformierten Gewichte 3607 angewendet wurden, werden verschiedene Umkehrtransformationen an dem verschiedenen Teil angewendet. Wenn mehrere Transformationen an einer Teilmatrix oder der gesamten Gewichtsmatrix angewendet werden, werden mehrere Umkehrtransformationen angewendet.
  • 38A-38B veranschaulichen Verfahren 3800, 3820 zum Erzeugen und Verwenden transformierter Matrizen auf einem Grafikprozessor. 38A veranschaulicht ein Verfahren 3800 zum Durchführen einer Matrixtransformation. 38B veranschaulicht ein Verfahren 3820 zum Verarbeiten einer transformierten Matrix. Die transformierten Matrixdaten können zum Beispiel die transformierten Gewichtsdaten sein, die von dem Transformationssystem 3604 ausgegeben werden, das in 36 und 37A dargestellt ist. Die transformierten Matrixdaten können in ein Sparse-Codierungsformat codiert werden. In einer Ausführungsform kann das Sparse-Codierungsformat zusätzlich unter Verwendung von Datenkompressionslogik komprimiert werden. Ein Umkehrtransformationssystem 3608, dargestellt in 36 und 37B, kann verwendet werden, um einen Umkehrtransformation an den Matrixdaten anzuwenden, bevor Verarbeitungsoperationen unter Verwendung der Daten durchgeführt werden.
  • Wie in 38A dargestellt, weist Verfahren 3800 für eine Rechenvorrichtung auf, Matrixdaten in einen Speicher in einem Grafikprozessor (3802) zu laden. Die Matrixdaten können in Hauptgrafikspeicher geladen werden und ein Teil der Matrixdaten kann in einen On-Die-Speicher des Grafikprozessors geladen werden. Der On-Die-Speicher kann lokal zu Transformationslogik in dem Grafikprozessor sein, wie Logik, die mit dem Transformationssystem 3604 verknüpft ist.
  • In einer Ausführungsform kann eine bestimmte Transformation für die Matrixdaten spezifiziert sein. Zum Beispiel ist eine bestimmte Transformation als optimal für die Matrixdaten bekannt, dass Transformation unter Umgehung der Transformationstestlogik angewendet werden kann. Wenn eine bestimmte Transformation für die Matrixdaten spezifiziert ist (3803, JA), kann die Rechenvorrichtung die spezifizierte Transformation anwenden (3806). Eine oder mehrere Transformationen können spezifiziert sein. Wenn keine Transformation spezifiziert ist (3803, NEIN), dann kann Transformationstestlogik 3703 zum Bestimmen einer optimalen Transformation verwendet werden (3804). In einer Ausführungsform ist die optimale Transformation für die Matrixdaten die Transformation, die bestimmt ist, zu dem höchsten Grad an Spärlichkeit für die Matrixdaten zu führen. In einer Ausführungsform ist die optimale Transformation die Transformation, die zu dem engsten Clustering von Nicht-Null-Koeffizienten führt. In einer Ausführungsform ist die optimale Transformation die Transformation, die zu dem höchsten Kompressionsverhältnis führt, wenn die Trainingsdaten komprimiert werden. Die bestimmte Transformation kann dann bei den Matrixdaten über numerische Transformationslogik angewendet werden (3806). Die transformierten Matrixdaten können dann codiert und/oder komprimiert werden (3808). Codierung und Kompression können durch die Rechenvorrichtung unter Verwendung des Grafikprozessors oder über Software, die auf der Host-Rechenvorrichtung läuft, durchgeführt werden. Wenn Codierung und Kompression unter Verwendung des Grafikprozessors durchgeführt werden, können die Codierung und Kompression unter Verwendung von Hardwarecodierern oder Codecs des Grafikprozessors oder über ein Shader- oder Rechenprogramm, das auf dem Grafikprozessor ausgeführt wird, durchgeführt werden.
  • Wie in 38B dargestellt, weist Verfahren 3820 für eine Rechenvorrichtung auf, komprimierte und/oder codierte und transformierte Matrixdaten aus Speicher zu lesen (3822). Der Speicher kann ein Speicher eines Grafikprozessors, ein nicht flüchtiger Systemdatenspeicher oder nicht flüchtiger Datenspeicher eines Grafikprozessors sein. Metadaten, die mit den Matrixdaten verknüpft sind, können gelesen werden, um die Kompression und/oder Codierung, die an den transformierten Matrixdaten angewendet wurde, und die Transformation, die an den Matrixdaten vor Kompression angewendet wurde, anzugeben. Unter Verwendung der Kompression und/oder Codierung von Metadaten kann die Rechenvorrichtung die transformierten Matrixdaten dekomprimieren und/oder decodieren (3824). Die Rechenvorrichtung kann dann, über einen Grafikprozessor, eine oder mehrere Umkehrtransformationen an den transformierten Matrixdaten basierend auf den Transformationsmetadaten anwenden (3826).
  • Die Rechenvorrichtung kann Spezialzwecklogik in dem Grafikprozessor verwenden, um die transformierten Matrixdaten zu dekomprimieren oder zu decodieren. Die Rechenvorrichtung kann auch ein Programm verwenden, das auf dem Host-Prozessor oder dem Grafikprozessor ausgeführt wird, um die transformierten Matrixdaten zu dekomprimieren oder zu decodieren. In einer Ausführungsform kann Programmcode, der auf dem Grafikprozessor läuft, komprimierte und/oder codierte und transformierte Daten lesen, die im Speicher gespeichert sind, und der Grafikprozessor kann automatisch die Daten dekomprimieren und/oder decodieren und eine Umkehrtransformation an den Daten anwenden, bevor die Daten Verarbeitungseinheiten in dem Grafikprozessor bereitgestellt werden. Die Verarbeitungseinheiten in dem Grafikprozessor können dann Rechenoperationen an den Matrixdaten durchführen, um Ausgangsdaten zu erzeugen (3828). Die Ausgangsdaten, die von den Verarbeitungseinheiten erzeugt werden, können dann in Speicher in dem Grafikprozessor oder in Systemspeicher geschrieben werden. In einer Ausführungsform kann das System konfiguriert sein, automatisch eine Transformation an den Ausgangsdaten anzuwenden, wenn eine gewünschte Eigenschaft der Ausgangsdaten (z.B. Kompressionsverhältnis, Spärlichkeitseigenschaft) zunimmt (3830).
  • Durchführen systolischer Arithmetik an komprimierten Daten.
  • In einer Ausführungsform empfängt in einer Ausführungsform das systolische Pipe, anstelle von unkomprimierten Daten vor Verarbeitung der Daten unter Verwendung des systolischen Tensor-Arrays 2808, Eingang in einem komprimierten oder codierten Format gemeinsam mit Metadaten, die beschreiben, wie die Daten komprimiert oder codiert sind. Der Ausgang von dem systolischen Tensor-Array 2808 kann auch komprimiert sein und in einem komprimierten Format in Speicher geschrieben werden. In einer Ausführungsform kann Kompression und Dekompression auch Anwenden von hier beschriebenen Transformations- und Umkehrtransformationstechniken aufweisen, um das Kompressionsverhältnis zu erhöhen, zu dem Daten komprimiert werden können.
  • 39 veranschaulicht eine Version des systolischen Tensor-Arrays 2808 das konfiguriert ist, komprimierte oder codierte Daten zu bearbeiten. In einer Ausführungsform weist das systolische Tensor-Array 2808 einen Decodierer 3312 auf, der komprimierte oder codierte Daten und zugehörige Metadaten 3902 empfängt. Der Decodierer 3312 kann die komprimierten oder codierten Daten basierend auf den Metadaten decodieren, um dekomprimierte Daten 3508 und eine Signifikanzkarte 3506 zu erzeugen. Umgehungs-/Gate-Logik 3510 kann bestimmen, Teilmatrizen in den dekomprimierten Daten 3508 zu umgehen und/oder gewisse Verarbeitungselemente der Verarbeitungseinheiten 3910 in dem systolische Tensor-Array 2808 einem Clock-Gating zu unterziehen, basierend auf dem Grad an Dünnbesetztheit, der durch die Signifikanzkarte 3506 angegeben ist und/oder den bestimmten Null- und Nicht-Null-Elementen, die durch die Signifikanzkarte 3506 spezifiziert sind. Daten, die von den Verarbeitungseinheiten 3910 ausgegeben werden können, können durch einen Codierer 3920 komprimiert oder codiert werden und als komprimierte oder codierte Daten mit zugehörigen Metadaten 3928 ausgegeben werden. In einer Ausführungsform kann der Codierer 3920 numerische Transformationslogik des Transformationssystems 3604 von 37A aufweisen und der Decodierer 3312 kann Umkehrtransformationslogik des Umkehrtransformationssystems 3608 von 37B aufweisen. In einer solchen Ausführungsform geben die Metadaten auch eine Transformationsart für die codierten Daten an.
  • 40 veranschaulicht ein Verfahren 4000 zum Durchführen systolischer Arithmetik an komprimierten oder codierten Daten. Das Verfahren 4000 kann durch hier beschriebene Hardware- oder Firmwarelogik durchgeführt werden. In einer Ausführungsform können die Hardware- oder Firmwarelogik durch Softwarelogik, wie Treiberlogik, durchgeführt werden, die auf einem Allzweckprozessor läuft.
  • Verfahren 4000 weist für ein Rechensystem Durchführung von Operationen auf, die Lesen komprimierter und/oder codierter Daten aus Speicher (Block 4002) umfassen. Das Rechensystem kann dann die komprimierten und/oder codierten Daten in eine Tensor-Beschleuniger-Pipeline laden (Block 4004). Die Tensor-Beschleuniger-Pipeline kann eine hier beschriebene systolische Pipeline, wie das systolische Tensor-Array 2808, oder eine andere Matrixbeschleunigerarchitektur sein.
  • Das Rechensystem kann dann Rechenoperationen an den komprimierten und/oder codierten Daten durchführen (Block 4006). Die Rechenoperationen können basierend auf Programmcodebefehlen durchgeführt werden, die von dem Rechensystem ausgeführt werden, wie einem Pixel-Shader, Vertex-Shader, Rechen-Shader oder CUDA-Programm. Decodierlogik, die mit Verarbeitungseinheiten eines Grafikprozessors in dem Rechensystem verknüpft ist, kann automatisch die komprimierten und/oder codierten Daten dekomprimieren und/oder decodieren. Zum Beispiel kann Dekompression und/oder Decodieren in Übereinstimmung mit einer Ladeoperation durchgeführt werden, die von den Verarbeitungseinheiten durchgeführt wird. In einer Ausführungsform kann die Kompression oder Codierung der komprimierten und/oder codierten Daten eine oder mehrere numerische Transformationen aufweisen, die angewendet werden, um das Kompressionsverhältnis zu erhöhen, zu dem die Daten komprimiert werden können. In einer solchen Ausführungsform weist Dekompression und/oder Decodierung Anwenden einer numerischen Umkehrtransformation an den Daten auf. Die numerische Transformation und numerischen Umkehrtransformationen sind zusätzlich zu beliebigen Transformationen oder Umkehrtransformationen, die durch den Codierungsalgorithmus spezifiziert sind, der an den Daten angewendet wird.
  • Das Rechensystem kann dann Ausgang der Tensor-Beschleuniger-Pipeline komprimieren und/oder codieren (Block 4008). Kompression und/oder Codierung können automatisch durchgeführt werden, zum Beispiel in Übereinstimmung mit einer Speicheroperation, die durch Verarbeitungseinheiten eines Grafikprozessors in dem Rechensystem durchgeführt wird. In einer Ausführungsform können numerische Transformationen vor Komprimieren und/oder Codieren der Daten gemäß Techniken angewendet werden, die in 36-38B beschrieben sind. Das Rechensystem kann dann den komprimierten und/oder codierten Ausgang in Speicher schreiben (Block 4010). Operationen des Verfahrens können über Befehle, die in einem nicht transitorischen maschinenlesbaren Medium gespeichert sind, basierend auf Firmware in einer Mikrosteuerung des Rechensystems oder basierend auf Hardwarelogik in dem Rechensystem implementiert werden.
  • Zusätzliche beispielhafte Rechenvorrichtung, die einen Grafikprozessor aufweist
  • 41 ist ein Blockdiagramm einer Rechenvorrichtung 4100, die einen Grafikprozessor 4104 aufweist, gemäß einer Ausführungsform. Die Rechenvorrichtung 4100 kann eine Rechenvorrichtung sein, die ein beliebiges, hier beschriebenes Datenverarbeitungssystem oder Teilsystem aufweist. Die Rechenvorrichtung 4100 kann auch eine Kommunikationsvorrichtung sein oder darin enthalten sein, wie eine Set-Top Box (z.B. Internet-basierte Set-Top Boxes für Kabelfernsehen usw.), Vorrichtungen, die auf globalem Positionierungssystem (GPS) basieren usw. Die Rechenvorrichtung 4100 kann auch mobile Rechenvorrichtungen sein oder darin enthalten sein, wie Mobiltelefone, Smartphones, Personal Digital Assistants (PDAs), Tablet Computer, Laptop Computer, E-Reader, smarte Fernsehgeräte, Fernsehplattformen, am Körper tragbare Vorrichtungen (z.B. Brillen, Uhren, Halsketten, Smartcards, Schmuck, Bekleidungsstücke usw.), Medienabspielgeräte usw. Zum Beispiel weist in einer Ausführungsform die Rechenvorrichtung 4100 eine mobile Rechenvorrichtung auf, die eine integrierte Schaltung („IC“), wie System auf einem Chip („SoC“ oder „SOC“), verwendet, die verschiedene Hardware- und/oder Softwarekomponenten von Rechenvorrichtung 4100 auf einem einzigen Chip integriert.
  • Die Rechenvorrichtung 4100 weist einen Grafikprozessor 4104 auf. Der Grafikprozessor 4104 stellt jeden hier beschriebenen Grafikprozessor dar. Der Grafikprozessor weist eine(n) oder mehrere Grafik-Engine(s), Grafikprozessorkerne und andere Grafikausführungsressourcen wie hier beschrieben auf. Solche Grafikausführungsressourcen können in den Formen präsentiert werden, aufweisend, ohne aber darauf beschränkt zu sein, Ausführungseinheiten, Shader Engines, Fragmentprozessoren, Vertexprozessoren, Streaming-Multiprozessoren, Grafikprozessorcluster oder jede Zusammenstellung von Rechenressourcen, die für die Verarbeitung von Grafikressourcen oder Bildressourcen oder Durchführen von Allzweckberechnungsoperationen in einem heterogenen Prozessor geeignet ist.
  • In einer Ausführungsform weist der Grafikprozessor 4104 einen Cache 4114 auf, der ein einzelner Cache sein kann oder in mehrere Segmente von Cache-Speicher unterteilt sein kann, aufweisend, ohne aber darauf beschränkt zu sein, eine beliebige Anzahl von L1, L2, L3 oder L4 Caches, Render-Caches, Tiefen-Caches, Sampler-Caches und/oder Shader-Einheit-Caches. In manchen Ausführungsformen weist der Grafikprozessor 4104 eine GPGPU-Engine 4144 auf, die einen Arbeitslasthandler 4140, einen Tensor-Beschleuniger 4134 und Transformations-/Umkehrtransformationslogik 4124 aufweist. Der Arbeitslasthandler 4140 kann Arbeitslastoperationen zur Ausführung auf dem Tensor-Beschleuniger 4134 und der GPGPU Engine 4144 planen. Die Arbeitslasteinheit 4124 kann Hardwarelogikeinheiten haben, aufweisend, aber nicht beschränkt auf, die Scheduler-Steuerung 2722 von 27. Der Tensor-Beschleuniger 4134 weist in einer Ausführungsform den Tensor-Beschleuniger 2723 wie in 27 auf oder ist eine Version desselben. In einer Ausführungsform kann der Tensor-Beschleuniger 4134 ein systolisches Tensor-Array (z.B. systolisches Tensor-Array 2808) wie hier beschrieben aufweisen.
  • Wie veranschaulicht kann in einer Ausführungsform und zusätzlich zu dem Grafikprozessor 4104 die Rechenvorrichtung 4100 ferner eine beliebige Anzahl und Art von Hardwarekomponenten und/oder Softwarekomponenten aufweisen, aufweisend, aber nicht beschränkt auf, einen Anwendungsprozessor 4106, Speicher 4108 und Eingangs-/Ausgangs-(I/O) Quellen 4110. Der Anwendungsprozessor 4106 kann mit einer Hardwaregrafik-Pipeline interagieren, um Grafik-Pipeline-Funktionalität zu teilen.
  • Verarbeitete Daten werden in einem Puffer in der Hardwaregrafik-Pipeline gespeichert und Zustandsinformationen werden im Speicher 4108 gespeichert. Die resultierenden Daten können zu einer Anzeigesteuerung zur Ausgabe über eine Anzeigevorrichtung, wie die Anzeigevorrichtung 1618 von 16B, überführt werden. Die Anzeigevorrichtung kann von verschiedenen Arten sein, wie Kathodenstrahlröhre (CRT, Cathode Ray Tube), Dünnfilmtransistor (TFT, Thin Film Transistor), Flüssigkristallanzeige (LCD, Liquid Crystal Display), organisches Leuchtdioden- (OLED, Organic Light Emitting Diode)) Array usw. und kann konfiguriert sein, einem, Benutzer Informationen über eine grafische Anwenderschnittstelle anzuzeigen.
  • Der Anwendungsprozessor 4106 kann einen oder mehrere Prozessoren aufweisen, wie Prozessor(en) 102 von 1, und kann die zentrale Verarbeitungseinheit (CPU) sein, die mindestens 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 Anwendern dienen. Das OS 4102 kann Treiberlogik für verschiedene Hardwarevorrichtungen in der Rechenvorrichtung 4100 aufweisen, aufweisend Grafiktreiberlogik 4122, wie der Anwendermodus-Grafiktreiber 2326 und/oder Kernelmodus-Grafiktreiber 2329 von 23.
  • Es wird in Betracht gezogen, dass in manchen Ausführungsformen der Grafikprozessor 4104 als Teil des Anwendungsprozessors 4106 vorliegen kann (wie Teil eines physischen CPU-Packages), wobei in diesem Fall mindestens ein Teil des Speichers 4108 von dem Anwendungsprozessor 4106 und Grafikprozessor 4104 gemeinsam benutzt werden kann, obwohl mindestens ein Teil des Speichers 4108 ausschließlich für den Grafikprozessor 4104 sein kann oder der Grafikprozessor 4104 einen separaten Speicherplatz haben kann. Der Speicher 4108 kann eine vorab zugeordnete Region eines Puffers (z.B. Framepuffer) aufweisen; einem Durchschnittsfachmann sollte jedoch klar sein, dass die Ausführungsformen dahingehend nicht eingeschränkt sind und jeder beliebige Speicher, der für die tiefere Grafik-Pipeline zugänglich ist, verwendet werden kann. Der Speicher 4108 kann verschiedene Formen von Direktzugriffsspeicher (RAM) (z.B. SDRAM, SRAM usw.) aufweisen, aufweisend eine Anwendung, die den Grafikprozessor 4104 benutzt, um eine Desktop- oder 3D Grafik-Szene wiederzugeben.
  • Ein Speichersteuerungs-Hub, wie Speichersteuerung 1416 von 14, kann auf Daten in dem Speicher 4108 zugreifen und diese zum Grafikprozessor 4104 zur Grafik-Pipeline-Verarbeitung leiten. Der Speicher 4108 kann für andere Komponenten in der Rechenvorrichtung 4100 verfügbar gemacht werden. Zum Beispiel können beliebige Daten (z.B. Eingangsgrafikdaten), die von verschiedenen I/O-Quellen 4110 der Rechenvorrichtung 4100 empfangen werden, vorübergehend im Speicher 4108 in eine Warteschlange gestellt werden, bevor sie von einem oder mehreren Prozessor(en) (z.B. Anwendungsprozessor 4106) in der Implementierung eines Softwareprogramms oder einer Anwendung bearbeitet werden. Ebenso werden Daten, für die ein Softwareprogramm bestimmt, dass sie von der Rechenvorrichtung 4100 durch eine der Rechensystemschnittstellen zu einer Entität außerhalb gesendet oder in einem internen Datenspeicherelement gespeichert werden sollen, häufig im Speicher 4108 in eine Warteschlange gestellt, bevor sie übertragen oder gespeichert werden.
  • Die I/O-Quellen können Vorrichtungen wie Berührungsbildschirme, Berührungsfelder, virtuelle oder reguläre Tastaturen, virtuelle oder reguläre Mäuse, Anschlüsse, Verbinder, Netzwerkvorrichtungen oder dergleichen aufweisen und können über einen Plattformsteuerungs-Hub 1430 angehängt sein, wie in 14 referenziert. Zusätzlich können die I/O-Quellen 4110 eine oder mehrere I/O-Vorrichtungen aufweisen, die zum Überführen von Daten zu und/oder von der Rechenvorrichtung 4100 implementiert sind (z.B. ein Netzwerkadapter); oder für einen nicht flüchtigen Datenspeicher in großem Maßstab in der Rechenvorrichtung 4100 (z.B. Festplattenlaufwerk). Anwendereingabevorrichtungen, aufweisend alphanumerische und andere Tasten, können zum Kommunizieren von Informationen und Steuerbefehlsauswahlen an Grafikprozessor 4104 verwendet werden. Eine andere Art von Anwendereingabevorrichtung ist Cursorsteuerung, wie eine Maus, ein Trackball, ein Berührungsbildschirm, ein Touchpad oder Cursor-Richtungstasten, um Richtungsinformationen und Steuerbefehlsauswahlen an die GPU zu kommunizieren und Cursor-Bewegung auf der Anzeigevorrichtung zu steuern. Kamera- und Mikrofon-Arrays der Rechenvorrichtung 4100 können verwendet werden, um Gesten zu beobachten, Audio und Video aufzuzeichnen und visuelle und Audiosteuerbefehle zu empfangen und zu senden.
  • I/O-Quellen 4110, die als Netzwerkschnittstellen konfiguriert sind, können Zugriff auf ein Netzwerk, wie ein LAN, ein Weitverkehrsnetzwerk (WAN, Wide Area Network), ein städtisches Netzwerk (MAN, Metropolitan Area Network), ein persönliches Netzwerk (PAN, Personal Area Network), Bluetooth, ein Cloud-Netzwerk, ein zelluläres oder mobiles Netzwerk (z.B. 3. Generation (3G), 4. Generation (4G) usw.), ein Intranet, das Internet usw. bereitstellen. Netzwerkschnittstelle(n) kann (können) zum Beispiel eine drahtlose Netzwerkschnittstelle mit einer oder mehreren Antenne(n) aufweisen. Netzwerkschnittstelle(n) kann (können) auch zum Beispiel eine kabelgebundene Netzwerkschnittstelle aufweisen, um mit fernen Vorrichtungen über Netzwerkkabel zu kommunizieren, das zum Beispiel ein Ethernetkabel, ein Koaxialkabel, ein Glasfaserkabel, ein serielles Kabel oder ein paralleles Kabel sein kann.
  • Netzwerkschnittstelle(n) kann (können) Zugriff auf ein LAN bereitstellen, zum Beispiel unter Einhaltung von IEEE 802.11 Standards, und/oder die drahtlose Netzwerkschnittstelle kann Zugriff auf ein persönliches Netzwerk bereitstellen, zum Beispiel unter Einhaltung von Bluetooth-Standards. Andere drahtlose Netzwerkschnittstellen und/oder Protokolle, aufweisend frühere und folgende Versionen der Standards, können auch unterstützt werden. Zusätzlich zu oder anstelle von Kommunikation über die drahtlosen LAN-Standards kann (können) Netzwerkschnittstelle(n) drahtlose Kommunikation unter Verwendung von zum Beispiel Time Division, Multiple Access (TDMA) Protokollen, Global Systems for Mobile Communications (GSM) Protokollen, Code Division, Multiple Access (CDMA) Protokollen und/oder einer anderen Art von drahtlosen Kommunikationsprotokollen bereitstellen.
  • Es ist klar, dass ein mehr oder weniger ausgestattetes System als das oben beschriebene Beispiel für gewisse Implementierungen bevorzugt sein kann. Daher kann die Konfiguration der Rechenvorrichtung 4100 von Implementierung zu Implementierung abhängig von zahlreichen Faktoren variieren, wie Preiseinschränkungen, Arbeitsleistungsanforderungen, technologischen Verbesserungen oder anderen Umständen. Beispiele weisen (ohne Einschränkung) eine mobile Vorrichtung, einen Personal Digital Assistant, eine mobile Rechenvorrichtung, ein Smartphone, eine zelluläres Telefon, ein Handset, einen Einweg-Pager, einen Zweiweg-Pager, eine Benachrichtigungsvorrichtung, einen Computer, einen Personal Computer (PC), einen Desktop Computer, einen Laptop Computer, einen Notebook Computer, einen handgehaltenen Computer, einen Tablet Computer, einen Server, ein Server-Array oder eine Serverfarm, einen Web-Server, einen Netzwerkserver, einen Internet-Server, eine Workstation, einen Mini-Computer, einen Mainframe Computer, einen Supercomputer, eine Netzwerkanwendung, eine Web-Anwendung, ein verteiltes Rechensystem, Multiprozessorsystem, Prozessor-basierte Systeme, Verbraucherelektronik, programmierbare Verbraucherelektronik, Fernsehgerät, digitales Fernsehgerät, Set Top Box, drahtlosen Zugangspunkt, Basisstation, Teilnehmerstation, Mobilteilnehmerzentrale, Funknetzwerksteuerung, Router, Hub, Gateway, Brücke, Schalter, Maschine oder Kombinationen davon auf.
  • Ausführungsformen können als eine beliebige oder eine Kombination der Folgenden implementiert sein: ein oder mehrere Mikrochips oder integrierte Schaltungen, die unter Verwendung einer Parent-Platine verbunden sind, hartverdrahtete Logik, Software, die von einer Speichervorrichtung gespeichert und von einem Mikroprozessor ausgeführt ist, Firmware, eine anwendungsspezifische integrierte Schaltung (ASIC) und/oder ein feldprogrammierbares Gate Array (FPGA). Der Begriff „Logik“ kann beispielsweise Software oder Hardware und/oder Kombinationen von Software und Hardware aufweisen.
  • Ausführungsformen können zum Beispiel als ein Computerprogrammprodukt bereitgestellt sein, das ein oder mehrere maschinenlesbare Medien aufweisen kann, auf welchen maschinenausführbare Befehle gespeichert sind, die, wenn sie von einer oder mehreren Maschinen, wie einem Computer, Netzwerk von Computern oder anderen elektronischen Vorrichtungen, ausgeführt werden, dazu führen können, dass die eine oder mehreren Maschinen Operationen gemäß hier beschriebenen Ausführungsformen ausführen. Ein maschinenlesbares Medium kann Disketten, optische Platten, CD-ROMs (Compact Disc-Read Only Memories) und magneto-optische Platten, ROMs, RAMs, EPROMs (Erasable Programmable Read Only Memories), EEPROMs (Electrically Erasable Programmable Read Only Memories), magnetische oder optische Karten, Flash-Speicher oder andere Art von nicht transitorischen maschinenlesbaren Medien, die zum Speichern maschinenausführbarer Befehle geeignet sind, aufweisen, ohne aber darauf beschränkt zu sein.
  • Ferner können Ausführungsformen als ein Computerprogrammprodukt heruntergeladen werden, wobei das Programm von einem fernen Computer (z.B. einem Server) zu einem anfragenden Computer (z.B. einen Client) durch ein oder mehrere Datensignale, die in einer Trägerwelle oder einem anderen Ausbreitungsmedium eingebettet sind und/oder durch dieses moduliert werden, über einen Kommunikationslink (z.B. ein Modem und/oder Netzwerkverbindung) übertragen werden kann.
  • Hier beschriebene Ausführungsformen stellen einen Befehl und zugehörige Logik bereit, um einem GPGPU-Programmcode zu ermöglichen, auf Spezialzweck-Hardwarelogik zuzugreifen, um Skalarproduktoperationen zu beschleunigen. Die folgenden Sätze und/oder Beispiele beziehen sich auf bestimmte Ausführungsformen oder Beispiele davon. Einzelheiten in den Beispielen können überall in einer oder mehreren Ausführungsformen verwendet werden. Die verschiedenen Merkmale der verschiedenen Ausführungsformen oder Beispiele können unterschiedlich kombiniert werden, wobei manche Merkmale enthalten und andere ausgeschlossen sind, um einer Vielfalt von verschiedenen Anwendungen zu entsprechen. Beispiele können einen Gegenstand aufweisen, wie ein Verfahren, Mittel zum Durchführen von Handlungen des Verfahrens, mindestens ein maschinenlesbares Medium, das Befehle aufweist, die, wenn von einer Maschine durchgeführt, die Maschine veranlassen, Handlungen des Verfahrens oder einer Vorrichtung oder eines Systems gemäß hier beschriebenen Ausführungsformen und Beispielen durchzuführen. Verschiedene Komponenten können ein Mittel zum Durchführen der beschriebenen Operationen oder Funktionen sein.
  • Eine Ausführungsform stellt eine Rechenvorrichtung bereit, aufweisend einen oder mehrere Prozessoren, die einen Grafikprozessor aufweisen. Der Grafikprozessor weist eine Verarbeitungsressource auf, die einen Tensor-Beschleuniger aufweist. Der Tensor-Beschleuniger ist konfigurierbar, numerische Operationen durchzuführen, um ein neurales Netzwerkmodell zu trainieren und eine erste Matrix von Gewichten zu erzeugen, die mit dem neuralen Netzwerkmodell verknüpft ist. Der Grafikprozessor weist zusätzlich einen Gewichtstransformator auf, um eine numerische Transformation an der ersten Matrix von Gewichten anzuwenden, um einen Satz von transformierten Gewichten und eine Transformationsart zu erzeugen. Die Transformationsart identifiziert die numerische Transformation, die bei der ersten Matrix von Gewichten angewendet wird. Die erste Matrix von Gewichten ist eine dünnbesetzte Matrix und die transformierten Gewichte komprimieren zu einem höheren Kompressionsverhältnis als die erste Matrix von Gewichten.
  • In verschiedenen Ausführungsformen ist der Gewichtstransformator eine Festfunktionshardwareeinheit des Grafikprozessors oder ist über programmierbare Hardware des Grafikprozessors implementiert. Der Gewichtstransformator weist einen Transformationsselektor und einen Transformationstester auf. Der Transformationstester ist konfigurierbar, eine erste numerische Transformation an mindestens einem Teil der ersten Matrix von Gewichten anzuwenden, um erste Testtransformationsdaten zu erzeugen, eine zweite numerische Transformation an mindestens einem Teil der ersten Matrix von Gewichten anzuwenden, um zweite Testtransformationsdaten zu erzeugen, Komprimierbarkeitsmetrik basierend auf Analysis der ersten Testtransformationsdaten und der zweiten Testtransformationsdaten zu bestimmen und eine empfohlene Transformation zu dem Transformationsselektor zu senden. Die bestimmte Anzahl von numerischen Transformationen, die getestet werden kann, ist nicht eingeschränkt. Testtransformationen können parallel durchgeführt werden. Der Transformationsselektor kann dann eine numerische Transformation, die an der ersten Matrix von Gewichten anzuwenden ist, basierend auf der empfohlenen Transformation auswählen. Eine numerische Transformation, die nicht die empfohlene Transformation ist, kann auch gewählt werden. Die numerische Transformation kann aus einem Satz von numerischen Transformationen gewählt werden, aufweisend eine diskrete Kosinustransformation, eine diskrete Sinustransformation, eine Bit-Flip-Transformation und eine Bit-Rotations-Transformation. In einer weiteren Ausführungsform weist der Grafikprozessor ferner einen Umkehr-Gewichtstransformator auf, um eine numerische Umkehrtransformation an den transformierten Gewichten anzuwenden, um eine zweite Matrix von Gewichten zu erzeugen. Die durchzuführende numerische Umkehrtransformation ist durch einen Umkehrtransformationsselektor des transformierten Umkehrgewichts über die Transformationsart identifiziert, die mit dem Satz transformierter Gewichte verknüpft ist.
  • Eine Ausführungsform stellt ein Verfahren bereit, aufweisend, auf einem Grafikprozessor, der einen Tensor-Beschleuniger aufweist, Laden von Matrixdaten und Metadaten, die mit den Matrixdaten verknüpft sind, in den Tensor-Beschleuniger, wobei die Metadaten eine numerische Transformation angeben, die bei den Matrixdaten angewendet wird, Durchführen, durch den Tensor-Beschleuniger, einer numerischen Umkehrtransformation an den Matrixdaten, wobei die numerische Umkehrtransformation durch die Metadaten angegeben ist, die mit den Matrixdaten verknüpft sind, Durchführen einer oder mehrerer Rechenoperationen in dem Tensor-Beschleuniger nach Durchführen der numerischen Umkehrtransformation und Schreiben eines Ausgangs der einen oder mehreren Rechenoperationen in einen Speicher des Grafikprozessors.
  • In einer weiteren Ausführungsform weist das Verfahren ferner Dekomprimieren oder Decodieren der Matrixdaten in dem Tensor-Beschleuniger vor Durchführen der numerischen Umkehrtransformation an den Matrixdaten und Komprimieren oder Codieren des Ausgangs in dem Tensor-Beschleuniger nach Durchführen der numerischen Transformation an den Matrixdaten auf In einer Ausführungsform weist Schreiben eines Ausgangs der einen oder mehreren Rechenoperationen in den Speicher des Grafikprozessors Schreiben des Ausgangs in einen Cache-Speicher des Grafikprozessors und/oder Schreiben des Ausgangs in einen Hauptspeicher des Grafikprozessors auf.
  • Eine numerische Transformation kann auch bei dem Ausgang der einen oder mehreren Rechenoperationen vor Schreiben des Ausgangs in den Speicher des Grafikprozessors angewendet werden. Die numerische Transformation kann eine spezifizierte numerische Transformation sein. Anwenden der numerischen Transformation kann auch Erzeugen, durch den Tensor-Beschleuniger, von Transformationstestmetrik für mehrere numerischen Transformationen, Auswählen einer numerischen Transformation basierend auf der Transformationstestmetrik und Anwenden der ausgewählten numerischen Transformation an dem Ausgang aufweisen. Die ausgewählte numerische Transformation kann aus einem Satz von numerischen Transformationen ausgewählt sein, aufweisend eine diskrete Kosinustransformation, eine diskrete Sinustransformation, eine Bit-Flip-Transformation und eine Bit-Rotations-Transformation.
  • Eine Ausführungsform stellt einen Grafikprozessor bereit, aufweisend eine Verarbeitungsressource, die einen Tensor-Beschleuniger aufweist, wobei der Tensor-Beschleuniger numerische Operationen durchführen soll, um ein neurales Netzwerkmodell zu trainieren und eine erste Matrix von Gewichten zu erzeugen, die mit dem neuralen Netzwerkmodell verknüpft ist, einen Gewichtstransformator, um eine numerische Transformation an der ersten Matrix von Gewichten anzuwenden, um einen Satz von transformierten Gewichten und eine Transformationsart zu erzeugen, wobei die Transformationsart die numerische Transformation identifiziert, die bei der ersten Matrix von Gewichten angewendet wird, wobei die erste Matrix von Gewichten eine dünnbesetzte Matrix ist und die transformierten Gewichte zu einem höheren Kompressionsverhältnis als die erste Matrix von Gewichten komprimieren, und einen Umkehr-Gewichtstransformator, um eine numerische Umkehrtransformation an den transformierten Gewichten anzuwenden, um eine zweite Matrix von Gewichten zu erzeugen, wobei die durchzuführende numerische Umkehrtransformation über die Transformationsart identifiziert wird, die mit dem Satz transformierter Gewichte verknüpft ist.
  • In einer weiteren Ausführungsform, weist der Gewichtstransformator einen Transformationsselektor und einen Transformationstester auf, wobei der Transformationstester eine erste numerische Transformation an mindestens einem Teil der ersten Matrix von Gewichten anwendet, um erste Testtransformationsdaten zu erzeugen, eine zweite numerische Transformation an mindestens einem Teil der ersten Matrix von Gewichten anwendet, um zweite Testtransformationsdaten zu erzeugen, Komprimierbarkeitsmetrik basierend auf Analysis der ersten Testtransformationsdaten und der zweiten Testtransformationsdaten bestimmt und eine empfohlene Transformation zu dem Transformationsselektor sendet, wobei der Transformationsselektor eine numerische Transformation, die an der ersten Matrix von Gewichten anzuwenden ist, basierend auf der empfohlenen Transformation auswählt. Die numerische Transformation wird aus einem Satz von numerischen Transformationen ausgewählt, die eine diskrete Kosinustransformation, eine diskrete Sinustransformation, eine Bit-Flip-Transformation und eine Bit-Rotations-Transformation aufweisen.
  • Die vorangehende Beschreibung und die Zeichnungen sind in einem veranschaulichenden und nicht in einem restriktiven Sinn zu betrachten. Fachleute werden verstehen, dass verschiedene Modifizierungen und Änderungen an den hier beschriebenen Ausführungsformen vorgenommen werden können, ohne von dem weiteren Wesen und Umfang der Merkmale abzuweichen, die in den beiliegenden Ansprüchen dargelegt sind.
  • 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/935670 [0001]

Claims (16)

  1. Rechenvorrichtung, aufweisend: einen oder mehrere Prozessoren, die einen Grafikprozessor aufweisen, wobei der Grafikprozessor aufweist: eine Verarbeitungsressource, die einen Tensor-Beschleuniger aufweist, wobei der Tensor-Beschleuniger numerische Operationen durchführt, um ein neurales Netzwerkmodell zu trainieren und eine erste Matrix von Gewichten zu erzeugen, die mit dem neuralen Netzwerkmodell verknüpft ist; und einen Gewichtstransformator, um eine numerische Transformation an der ersten Matrix von Gewichten anzuwenden, um einen Satz von transformierten Gewichten und eine Transformationsart zu erzeugen, wobei die Transformationsart die numerische Transformation identifiziert, die bei der ersten Matrix von Gewichten angewendet wird, wobei die erste Matrix von Gewichten eine dünnbesetzte Matrix ist und die transformierten Gewichte zu einem höheren Kompressionsverhältnis komprimieren als die erste Matrix von Gewichten.
  2. Rechenvorrichtung nach Anspruch 1, wobei der Gewichtstransformator eine Festfunktionshardwareeinheit des Grafikprozessors ist.
  3. Rechenvorrichtung nach Anspruch 1, wobei der Gewichtstransformator über programmierbare Hardware des Grafikprozessors implementiert ist.
  4. Rechenvorrichtung nach einem der Ansprüche 1-3, wobei der Gewichtstransformator einen Transformationsselektor und einen Transformationstester aufweist, wobei der Transformationstester dient zum: Anwenden einer ersten numerischen Transformation an mindestens einem Teil der ersten Matrix von Gewichten, um erste Testtransformationsdaten zu erzeugen; Anwenden einer zweiten numerischen Transformation an mindestens einem Teil der ersten Matrix von Gewichten, um zweite Testtransformationsdaten zu erzeugen; Bestimmen einer Komprimierbarkeitsmetrik basierend auf Analyse der ersten Testtransformationsdaten und der zweiten Testtransformationsdaten; und Senden einer empfohlenen Transformation zu dem Transformationsselektor.
  5. Rechenvorrichtung nach Anspruch 4, wobei der Transformationsselektor ferner eine numerische Transformation, die an der ersten Matrix von Gewichten anzuwenden ist, basierend auf der empfohlenen Transformation auswählt, wobei die numerische Transformation aus einem Satz von numerischen Transformationen ausgewählt ist, aufweisend eine diskrete Kosinustransformation, eine diskrete Sinustransformation, eine Bit-Flip-Transformation und eine Bit-Rotations-Transformation.
  6. Rechenvorrichtung nach einem der Ansprüche 1-5, wobei der Grafikprozessor ferner aufweist: einen Umkehr-Gewichtstransformator, um eine numerische Umkehrtransformation an dem Satz von transformierten Gewichten anzuwenden, um eine zweite Matrix von Gewichten zu erzeugen, wobei die durchzuführende numerische Umkehrtransformation über die Transformationsart identifiziert wird, die mit dem Satz transformierter Gewichte verknüpft ist.
  7. Rechenvorrichtung nach einem der Ansprüche 1-6, wobei der Tensor-Beschleuniger ein systolisches Array von Verarbeitungselementen aufweist.
  8. Verfahren, aufweisend: auf einem Grafikprozessor, der einen Tensor-Beschleuniger aufweist: Laden von Matrixdaten und Metadaten, die mit den Matrixdaten verknüpft sind, in den Tensor-Beschleuniger, wobei die Metadaten eine numerische Transformation angeben, die bei den Matrixdaten angewendet wird; Durchführen, durch den Tensor-Beschleuniger, einer numerischen Umkehrtransformation an den Matrixdaten, wobei die numerische Umkehrtransformation durch die Metadaten angegeben ist, die mit den Matrixdaten verknüpft sind; Durchführen einer oder mehrerer Rechenoperationen in dem Tensor-Beschleuniger nach Durchführen der numerischen Umkehrtransformation; und Schreiben eines Ausgangs der einen oder mehreren Rechenoperationen in einen Speicher des Grafikprozessors.
  9. Verfahren nach Anspruch 8, zusätzlich aufweisend Dekomprimieren oder Decodieren der Matrixdaten in dem Tensor-Beschleuniger vor Durchführen der numerischen Umkehrtransformation an den Matrixdaten.
  10. Verfahren nach Anspruch 9, zusätzlich aufweisend Komprimieren oder Codieren des Ausgangs in dem Tensor-Beschleuniger nach Durchführen der numerischen Transformation an den Matrixdaten.
  11. Verfahren nach einem der Ansprüche 8-10, wobei Schreiben eines Ausgangs der einen oder mehreren Rechenoperationen in den Speicher des Grafikprozessors Schreiben des Ausgangs in einen Cache-Speicher des Grafikprozessors aufweist.
  12. Verfahren nach einem der Ansprüche 8-10, wobei Schreiben eines Ausgangs der einen oder mehreren Rechenoperationen in den Speicher des Grafikprozessors Schreiben des Ausgangs in einen Hauptspeicher des Grafikprozessors aufweist.
  13. Verfahren nach Anspruch 11 oder 12, ferner aufweisend Anwenden einer numerischen Transformation an dem Ausgang der einen oder mehreren Rechenoperationen vor Schreiben des Ausgangs in den Speicher des Grafikprozessors.
  14. Verfahren nach Anspruch 13, wobei Anwenden der numerischen Transformation an dem Ausgang der einen oder mehreren Rechenoperationen Anwenden einer spezifizierten numerischen Transformation an dem Ausgang aufweist.
  15. Verfahren nach Anspruch 14, wobei Anwenden der numerischen Transformation an dem Ausgang der einen oder mehreren Rechenoperationen Erzeugen, durch den Tensor-Beschleuniger, einer Transformationstestmetrik für mehrere numerische Transformationen, Auswählen einer numerischen Transformation basierend auf der Transformationstestmetrik und Anwenden der ausgewählten numerischen Transformation an dem Ausgang aufweist, wobei die ausgewählte numerische Transformation aus einem Satz von numerischen Transformationen ausgewählt ist, aufweisend eine diskrete Kosinustransformation, eine diskrete Sinustransformation, eine Bit-Flip-Transformation und eine Bit-Rotations-Transformation.
  16. Grafikverarbeitungssystem aufweisend Mittel zum Durchführen eines Verfahrens nach einem der Ansprüche 8-15.
DE102020130078.6A 2019-11-15 2020-11-13 Systolische arithmetik an spärlichen daten Pending DE102020130078A1 (de)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201962935670P 2019-11-15 2019-11-15
US62/935,670 2019-11-15
US17/095,544 2020-11-11
US17/095,544 US11663746B2 (en) 2019-11-15 2020-11-11 Systolic arithmetic on sparse data

Publications (1)

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

Family

ID=75683481

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102020130078.6A Pending DE102020130078A1 (de) 2019-11-15 2020-11-13 Systolische arithmetik an spärlichen daten

Country Status (6)

Country Link
US (2) US11663746B2 (de)
JP (1) JP2021082289A (de)
KR (1) KR20210059647A (de)
CN (1) CN112819682A (de)
DE (1) DE102020130078A1 (de)
TW (1) TW202139136A (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11663746B2 (en) 2019-11-15 2023-05-30 Intel Corporation Systolic arithmetic on sparse data

Families Citing this family (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3671660A1 (de) * 2018-12-20 2020-06-24 Dassault Systèmes Entwurf eines 3d-modellierten objekts über eine benutzerinteraktion
WO2020190800A1 (en) 2019-03-15 2020-09-24 Intel Corporation Dynamic memory reconfiguration
WO2020190807A1 (en) 2019-03-15 2020-09-24 Intel Corporation Systolic disaggregation within a matrix accelerator architecture
US11934342B2 (en) 2019-03-15 2024-03-19 Intel Corporation Assistance for hardware prefetch in cache access
US11861761B2 (en) 2019-11-15 2024-01-02 Intel Corporation Graphics processing unit processing and caching improvements
US11467806B2 (en) * 2019-11-27 2022-10-11 Amazon Technologies, Inc. Systolic array including fused multiply accumulate with efficient prenormalization and extended dynamic range
US11521062B2 (en) * 2019-12-05 2022-12-06 International Business Machines Corporation Neural network training using a data flow graph and dynamic memory management
US11284071B2 (en) * 2019-12-12 2022-03-22 Google Llc Combination of mode-dependent and fixed transform types in video coding
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
US11599376B1 (en) * 2020-02-20 2023-03-07 Amazon Technologies, Inc. Deep learning architecture for edge computing system
US11347652B2 (en) * 2020-08-31 2022-05-31 Microsoft Technology Licensing, Llc Banked memory architecture for multiple parallel datapath channels in an accelerator
CN113392280B (zh) * 2021-06-10 2023-08-04 东北大学 一种面向跨区域的多主模型分布式图计算方法
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
WO2023281371A1 (en) * 2021-07-04 2023-01-12 Numenta, Inc. Hardware architecture for processing tensors with complementary sparsity
CN113590193B (zh) * 2021-07-12 2024-03-22 苏州仰思坪半导体有限公司 一种运算装置、方法、介质及计算设备
US11966343B2 (en) 2021-07-19 2024-04-23 Samsung Electronics Co., Ltd. Universal mechanism to access and control a computational device
KR102538980B1 (ko) * 2021-07-27 2023-06-01 이화여자대학교 산학협력단 연산 가속 방법, 연산 가속 장치 및 상기 방법을 실행시키기 위하여 기록매체에 저장된 컴퓨터 프로그램
KR102597079B1 (ko) * 2021-09-03 2023-10-31 연세대학교 산학협력단 n차원 텐서 곱 연산을 이용한 합성곱 신경망 압축 방법 및 장치
US20230076138A1 (en) * 2021-09-09 2023-03-09 Arm Limited Nibble Block Format
CN113946292B (zh) * 2021-10-29 2023-10-24 南京审计大学 一种基于强化学习的频繁写缓存数据压缩方法
US20230229353A1 (en) * 2022-01-14 2023-07-20 Samsung Electronics Co., Ltd. Interactive mechanism to communicate with tools inside computational devices
TWI824392B (zh) * 2022-01-21 2023-12-01 財團法人國家實驗研究院 適用於分散式深度學習計算的隨需即組共用資料快取方法、電腦程式、電腦可讀取媒體
CN114491404B (zh) * 2022-01-28 2022-12-06 北京理工大学 应用于计算设备的混合精度SpMV优化系统及方法
CN114331806A (zh) * 2022-03-17 2022-04-12 南京砺算科技有限公司 图形处理器及图形处理方法
KR20230138777A (ko) * 2022-03-24 2023-10-05 삼성전자주식회사 데이터 재구성가능한 스토리지 장치, 전자 시스템 및 그 동작방법
CN116718979B (zh) * 2023-08-08 2023-10-24 北京京仪北方仪器仪表有限公司 一种智能电表运行误差测量方法和系统

Family Cites Families (56)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2306271B (en) 1994-06-22 1997-07-16 Microsoft Corp Data analyser
US8188997B2 (en) 2000-06-19 2012-05-29 Mental Images Gmbh Accelerated ray tracing using shallow bounding volume hierarchies
US7499053B2 (en) 2000-06-19 2009-03-03 Mental Images Gmbh Real-time precision ray tracing
US7873812B1 (en) 2004-04-05 2011-01-18 Tibet MIMAR Method and system for efficient matrix multiplication in a SIMD processor architecture
US20060101244A1 (en) 2004-11-10 2006-05-11 Nvidia Corporation Multipurpose functional unit with combined integer and floating-point multiply-add pipeline
US7327289B1 (en) 2006-09-20 2008-02-05 Intel Corporation Data-modifying run length encoder to avoid data expansion
US7783859B2 (en) 2007-07-12 2010-08-24 Qnx Software Systems Gmbh & Co. Kg Processing system implementing variable page size memory organization
US20100185816A1 (en) 2009-01-21 2010-07-22 Sauber William F Multiple Cache Line Size
US8566801B2 (en) 2009-05-22 2013-10-22 International Business Machines Corporation Concurrent static single assignment for general barrier synchronized parallel programs
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
US8713294B2 (en) 2009-11-13 2014-04-29 International Business Machines Corporation Heap/stack guard pages using a wakeup unit
US8677613B2 (en) 2010-05-20 2014-03-25 International Business Machines Corporation Enhanced modularity in heterogeneous 3D stacks
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
US9529712B2 (en) 2011-07-26 2016-12-27 Nvidia Corporation Techniques for balancing accesses to memory having different memory types
US20130099946A1 (en) 2011-10-21 2013-04-25 International Business Machines Corporation Data Compression Utilizing Variable and Limited Length Codes
US9478066B2 (en) 2013-03-14 2016-10-25 Nvidia Corporation Consistent vertex snapping for variable resolution rendering
US9946666B2 (en) 2013-08-06 2018-04-17 Nvidia Corporation Coalescing texture access and load/store operations
US10528357B2 (en) 2014-01-17 2020-01-07 L3 Technologies, Inc. Web-based recorder configuration utility
EP2937794B1 (de) 2014-04-22 2016-08-17 DataVard GmbH Verfahren und System zum Archivieren von digitalen Daten
KR102192956B1 (ko) 2014-06-23 2020-12-18 삼성전자주식회사 디스플레이 장치 및 그 제어 방법
US10223333B2 (en) 2014-08-29 2019-03-05 Nvidia Corporation Performing multi-convolution operations in a parallel processing system
US9804666B2 (en) 2015-05-26 2017-10-31 Samsung Electronics Co., Ltd. Warp clustering
KR102604737B1 (ko) 2016-01-11 2023-11-22 삼성전자주식회사 가속 구조를 생성하는 방법 및 장치
US20170214930A1 (en) 2016-01-26 2017-07-27 Sandia Corporation Gpu-assisted lossless data compression
US10390114B2 (en) 2016-07-22 2019-08-20 Intel Corporation Memory sharing for physical accelerator resources in a data center
US10528864B2 (en) 2016-08-11 2020-01-07 Nvidia Corporation Sparse convolutional neural network accelerator
US10891538B2 (en) 2016-08-11 2021-01-12 Nvidia Corporation Sparse convolutional neural network accelerator
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
KR20180069461A (ko) 2016-12-15 2018-06-25 삼성전자주식회사 가속 구조를 생성하는 방법 및 장치
US10423415B2 (en) 2017-04-01 2019-09-24 Intel Corporation Hierarchical general register file (GRF) for execution block
US10186011B2 (en) 2017-04-28 2019-01-22 Intel Corporation Programmable coarse grained and sparse matrix compute hardware with advanced scheduling
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
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
US10503507B2 (en) 2017-08-31 2019-12-10 Nvidia Corporation Inline data inspection for workload simplification
US11222256B2 (en) * 2017-10-17 2022-01-11 Xilinx, Inc. Neural network processing system having multiple processors and a neural network accelerator
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
CN111788583A (zh) 2018-02-09 2020-10-16 渊慧科技有限公司 连续稀疏性模式神经网络
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
CN111937385B (zh) * 2018-04-13 2024-04-16 皇家Kpn公司 基于帧级超分辨率的视频编码
GB2574060B (en) * 2018-05-25 2022-11-23 Myrtle Software Ltd Processing matrix vector multiplication
US10699468B2 (en) 2018-06-09 2020-06-30 Adshir Ltd. Method for non-planar specular reflections in hybrid ray tracing
WO2020029018A1 (zh) * 2018-08-06 2020-02-13 华为技术有限公司 矩阵的处理方法、装置及逻辑电路
US11833681B2 (en) * 2018-08-24 2023-12-05 Nvidia Corporation Robotic control system
US11294626B2 (en) 2018-09-27 2022-04-05 Intel Corporation Floating-point dynamic range expansion
US10853067B2 (en) 2018-09-27 2020-12-01 Intel Corporation Computer processor for higher precision computations using a mixed-precision decomposition of operations
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
US20200202195A1 (en) 2018-12-06 2020-06-25 MIPS Tech, LLC Neural network processing using mixed-precision data representation
WO2020190800A1 (en) 2019-03-15 2020-09-24 Intel Corporation Dynamic memory reconfiguration
US11663746B2 (en) 2019-11-15 2023-05-30 Intel Corporation Systolic arithmetic on sparse data

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11663746B2 (en) 2019-11-15 2023-05-30 Intel Corporation Systolic arithmetic on sparse data

Also Published As

Publication number Publication date
US11663746B2 (en) 2023-05-30
JP2021082289A (ja) 2021-05-27
CN112819682A (zh) 2021-05-18
US20230377209A1 (en) 2023-11-23
US20210150770A1 (en) 2021-05-20
TW202139136A (zh) 2021-10-16
KR20210059647A (ko) 2021-05-25

Similar Documents

Publication Publication Date Title
DE102020130078A1 (de) Systolische arithmetik an spärlichen daten
DE112020000846T5 (de) Architektur für Block-Sparse-Operationen an einem systolischen Array
DE112020001258T5 (de) Grafikprozessoren und Grafikverarbeitungseinheiten mit Skalarproduktakkumulationsanweisungen für ein Hybrid-Gleitkommaformat
DE102018133555A1 (de) Berechnungsoptimierungsmechanismus für tiefe neuronale Netze
DE102020129251A1 (de) Adaptives verformbares kernvorhersagenetzwerk zum bildentrauschen
DE102018110380A1 (de) Tool zum Ermöglichen der Effizienz beim Maschinenlernen
DE102020129969A1 (de) Verbesserungen der verarbeitung und des caching von graphikverarbeitungseinheiten
DE102020129970A1 (de) Systeme und verfahren zur fehlererkennung und steuerung für eingebettete arbeitsspeicher- und rechenelemente
DE102020120372A1 (de) Programmierbare wandlungshardware
DE102018110687A1 (de) Dynamisches Genauigkeitsmanagement für Deep-Learning-Ganzzahlprimitive
DE102020130073A1 (de) Verbesserung der datenlokalität für grafikprozessoreinheiten
DE112020000464T5 (de) Mehrfachkachel-grafikprozessor-rendering
DE102018110371A1 (de) Intelligente speicherhandhabung und datenmanagement für maschinenlernnetzwerke
DE102020131896A1 (de) Deep learning-basierte auswahl von abtastwerten für adaptives supersampling
DE102020107080A1 (de) Grafiksysteme und Verfahren zum Beschleunigen von Synchronisation mittels feinkörniger Abhängigkeitsprüfung und Planungsoptimierungen basierend auf verfügbarem gemeinsam genutztem Speicherplatz
DE112020000854T5 (de) Thread-gruppen-planung für die grafikverarbeitung
DE102020132272A1 (de) Verfahren und vorrichtung zum codieren basierend auf schattierungsraten
DE102020132557A1 (de) Vorrichtung und verfahren für asynchrones raytracing
DE102020132544A1 (de) Vorrichtung und verfahren für doppelpräzisionsstrahlquerung in einer raytracing-pipeline
DE102020131901A1 (de) Vorrichtung und verfahren zum durchführen nicht lokaler mittelwertfilterung unter verwendung eines bewegungsschätzschaltkreises eines grafikprozessors
DE112020000848T5 (de) Skalarkernintegration
DE102020108476A1 (de) Mechanismus zum Ausführen nichtlinearer Funktionen in einem Beschleuniger des maschinellen Lernens
DE102018110346A1 (de) Speichersystem für dnn-ausgaben für die black box
DE102018110719A1 (de) Hardwareimplementierte Punkt-zu-Punkt-Kommunikationsprimitive zum Maschinenlernen
DE102020129409A1 (de) Dynamisches unterteilen von aktivierungen und kernels zum verbessern von speichereffizienz