DE102020130081A1 - Erweiterte prozessorfunktionen für berechnungen - Google Patents

Erweiterte prozessorfunktionen für berechnungen Download PDF

Info

Publication number
DE102020130081A1
DE102020130081A1 DE102020130081.6A DE102020130081A DE102020130081A1 DE 102020130081 A1 DE102020130081 A1 DE 102020130081A1 DE 102020130081 A DE102020130081 A DE 102020130081A DE 102020130081 A1 DE102020130081 A1 DE 102020130081A1
Authority
DE
Germany
Prior art keywords
graphics
instruction
data
processing
processor
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
DE102020130081.6A
Other languages
English (en)
Inventor
Subramaniam Maiyuran
Lidong Xu
Abhishek R. Appu
James M. Holland
Vasanth Ranganathan
Nikos Kaburlasos
Altug Koker
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 DE102020130081A1 publication Critical patent/DE102020130081A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003—Arrangements for executing specific machine instructions
    • G06F9/30007—Arrangements for executing specific machine instructions to perform operations on data operands
    • G06F9/3001—Arithmetic instructions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T1/00—General purpose image data processing
    • G06T1/20—Processor architectures; Processor configuration, e.g. pipelining
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • 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
    • G06F18/00—Pattern recognition
    • G06F18/20—Analysing
    • G06F18/21—Design or setup of recognition systems or techniques; Extraction of features in feature space; Blind source separation
    • G06F18/214—Generating training patterns; Bootstrap methods, e.g. bagging or boosting
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F7/00—Methods or arrangements for processing data by operating upon the order or content of the data handled
    • G06F7/38—Methods or arrangements for performing computations using exclusively denominational number representation, e.g. using binary, ternary, decimal representation
    • G06F7/48—Methods or arrangements for performing computations using exclusively denominational number representation, e.g. using binary, ternary, decimal representation using non-contact-making devices, e.g. tube, solid state device; using unspecified devices
    • G06F7/483—Computations with numbers represented by a non-linear combination of denominational numbers, e.g. rational numbers, logarithmic number system or floating-point numbers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003—Arrangements for executing specific machine instructions
    • G06F9/30007—Arrangements for executing specific machine instructions to perform operations on data operands
    • G06F9/3001—Arithmetic instructions
    • G06F9/30014—Arithmetic instructions with variable precision
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003—Arrangements for executing specific machine instructions
    • G06F9/30007—Arrangements for executing specific machine instructions to perform operations on data operands
    • G06F9/30021—Compare instructions, e.g. Greater-Than, Equal-To, MINMAX
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003—Arrangements for executing specific machine instructions
    • G06F9/30007—Arrangements for executing specific machine instructions to perform operations on data operands
    • G06F9/30036—Instructions to perform operations on packed data, e.g. vector, tile or matrix operations
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003—Arrangements for executing specific machine instructions
    • G06F9/30007—Arrangements for executing specific machine instructions to perform operations on data operands
    • G06F9/30036—Instructions to perform operations on packed data, e.g. vector, tile or matrix operations
    • G06F9/30038—Instructions to perform operations on packed data, e.g. vector, tile or matrix operations using a mask
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30098—Register arrangements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30098—Register arrangements
    • G06F9/3012—Organisation of register space, e.g. banked or distributed register file
    • G06F9/3013—Organisation of register space, e.g. banked or distributed register file according to data content, e.g. floating-point registers, address registers
    • 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/3818—Decoding for concurrent execution
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3818—Decoding for concurrent execution
    • G06F9/382—Pipelined decoding, e.g. using predecoding
    • 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/3867—Concurrent instruction execution, e.g. pipeline or look ahead using instruction pipelines
    • 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/3867—Concurrent instruction execution, e.g. pipeline or look ahead using instruction pipelines
    • G06F9/3875—Pipelining a single stage, e.g. superpipelining
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3885—Concurrent instruction execution, e.g. pipeline or look ahead using a plurality of independent parallel functional units
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3885—Concurrent instruction execution, e.g. pipeline or look ahead using a plurality of independent parallel functional units
    • G06F9/3887—Concurrent instruction execution, e.g. pipeline or look ahead using a plurality of independent parallel functional units controlled by a single instruction for multiple data lanes [SIMD]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3885—Concurrent instruction execution, e.g. pipeline or look ahead using a plurality of independent parallel functional units
    • G06F9/3888—Concurrent instruction execution, e.g. pipeline or look ahead using a plurality of independent parallel functional units controlled by a single instruction for multiple threads [SIMT] 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/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3885—Concurrent instruction execution, e.g. pipeline or look ahead using a plurality of independent parallel functional units
    • G06F9/3888—Concurrent instruction execution, e.g. pipeline or look ahead using a plurality of independent parallel functional units controlled by a single instruction for multiple threads [SIMT] in parallel
    • G06F9/38885—Divergence aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N20/00—Machine learning
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/02—Neural networks
    • G06N3/04—Architecture, e.g. interconnection topology
    • G06N3/045—Combinations of networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/02—Neural networks
    • G06N3/06—Physical realisation, i.e. hardware implementation of neural networks, neurons or parts of neurons
    • G06N3/063—Physical realisation, i.e. hardware implementation of neural networks, neurons or parts of neurons using electronic means
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • 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)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Mathematical Physics (AREA)
  • Computing Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Pure & Applied Mathematics (AREA)
  • Computational Mathematics (AREA)
  • Mathematical Optimization (AREA)
  • Mathematical Analysis (AREA)
  • Artificial Intelligence (AREA)
  • Evolutionary Computation (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • Biophysics (AREA)
  • Molecular Biology (AREA)
  • General Health & Medical Sciences (AREA)
  • Computational Linguistics (AREA)
  • Computer Hardware Design (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Medical Informatics (AREA)
  • Bioinformatics & Cheminformatics (AREA)
  • Bioinformatics & Computational Biology (AREA)
  • Evolutionary Biology (AREA)
  • Neurology (AREA)
  • Nonlinear Science (AREA)
  • Image Generation (AREA)
  • Advance Control (AREA)

Abstract

Es werden erweiterte Prozessorfunktionen für Berechnungen beschrieben. Ein Beispiel für eine Vorrichtung umfasst einen oder mehrere Prozessoren mit einer oder mehreren Verarbeitungsressourcen und einen Speicher zum Speichern von Daten, wobei die Daten Daten für Rechenoperationen umfassen. Eine Verarbeitungsressource der einen oder der mehreren Verarbeitungsressourcen umfasst eine konfigurierbare Pipeline für Berechnungsoperationen, und wobei die konfigurierbare Pipeline verwendet werden kann, um sowohl eine normale Anweisung für eine Berechnung mit einer bestimmten Präzision als auch eine systolische Anweisung für eine Berechnung mit einer bestimmten Präzision durchzuführen.

Description

  • BEANSPRUCHTE PRIORITÄT/ QUERVERWEIS AUF VERWANDTE ANMELDUNGEN
  • Die vorliegende Anmeldung ist verwandt mit und beansprucht gemäß 35 U.S.C. 119(e) den Nutzen und die Priorität der US-Provisional-Anmeldung Nr. 62/935,758 mit dem Titel „Enhanced Processor Functions for Calculation“ von Subramaniam Maiyuran et al., eingereicht am 15. November 2019 (Aktenzeichen des Vertreters: AC5188-Z), deren Inhalt hierin durch Bezugnahme aufgenommen ist.
  • TECHNISCHES GEBIET
  • Diese Offenbarung betrifft allgemein Datenverarbeitung und insbesondere Datenverarbeitung über eine Allzweck-Grafikverarbeitungseinheit.
  • HINTERGRUND
  • Die aktuelle parallele Grafikdatenverarbeitung umfasst Systeme und Verfahren, die entwickelt wurden, um bestimmte Operationen an Grafikdaten durchzuführen, beispielsweise lineare Interpolation, Tesselation, Rasterung, Texturabbildung, Tiefenprüfung usw. Traditionell verwendeten Grafikprozessoren Recheneinheiten mit fester Funktion zur Verarbeitung von Grafikdaten. In jüngerer Zeit wurden jedoch Teile von Grafikprozessoren programmierbar gemacht, so dass solche Prozessoren eine größere Vielfalt von Operationen zur Verarbeitung von Vertex- und Fragmentdaten unterstützen.
  • Um die Leistung weiter zu steigern, implementieren Grafikprozessoren typischerweise Verarbeitungstechniken wie Pipelining, die versuchen, so viele Grafikdaten wie möglich in den verschiedenen Teilen der Grafikpipeline parallel zu verarbeiten. Parallele Grafikprozessoren mit Single-Instruction-Multi-Thread (SIMT)-Architekturen sind darauf ausgelegt, das Ausmaß der Parallelverarbeitung in der Grafikpipeline zu maximieren. In einer SIMT-Architektur versuchen Gruppen von parallelen Threads, Programmanweisungen so oft wie möglich gemeinsam synchron auszuführen, um die Verarbeitungseffizienz zu erhöhen. Ein allgemeiner Überblick über Software und Hardware für SIMT-Architekturen ist Shane Cook, CUDA Programming, Kapitel 3, Seiten 37-51 (2013) zu entnehmen.
  • Herkömmliche Systeme mit Grafikverarbeitung zum Rechnen weisen verschiedene Prozessorfunktionen für Berechnungen auf. Die Verarbeitung von Daten für maschinelles Lernen und verwandte Technologien haben jedoch spezifische Anforderungen an die Berechnung und erfordern im Allgemeinen die Verarbeitung sehr großer Datenmengen. Infolgedessen kann die Rechenleistung aktueller Prozessoren für bestimmte Anwendungen unzureichend sein.
  • Figurenliste
  • Zum besseren Verständnis der vorstehend genannten Merkmale der vorliegenden Ausführungsformen folgt eine eingehendere Beschreibung der vorstehend kurz zusammengefassten Ausführungsformen unter Bezugnahme auf Ausführungsformen, von denen einige in den beiliegenden Zeichnungen veranschaulicht sind. Es wird jedoch angemerkt, dass die beiliegenden Zeichnungen lediglich typische Ausführungsformen veranschaulichen und daher nicht als den Umfang einschränkend zu verstehen sind.
    • 1 ist ein Blockschaubild, das ein Computersystem veranschaulicht, das dafür konfiguriert ist, einen oder mehrere Aspekte der vorliegend beschriebenen Ausführungsformen zu implementieren;
    • 2A bis 2D veranschaulichen Parallelprozessor-Komponenten;
    • 3A bis 3C sind Blockschaubilder von Grafik-Multiprozessoren und Multiprozessor-basierten GPUs;
    • 4A-4F veranschaulichen eine beispielhafte Architektur, in der eine Vielzahl von GPUs kommunikativ mit einer Vielzahl von Mehrkernprozessoren gekoppelt ist;
    • 5 veranschaulicht eine Grafikverarbeitungspipeline;
    • 6 veranschaulicht einen Software-Stack für maschinelles Lernen;
    • 7 veranschaulicht eine Allzweck-Grafikverarbeitungseinheit;
    • 8 veranschaulicht ein Multi-GPU-Datenverarbeitungssystem;
    • 9A bis 9B veranschaulichen Schichten beispielhafter tiefer neuronaler Netze (deep neural networks);
    • 10 veranschaulicht ein beispielhaftes rekurrentes neuronales Netz;
    • 11 veranschaulicht Training und Einsatz eines tiefen neuronalen Netzes;
    • 12A ist ein Blockschaubild, das verteiltes Lernen (distributed learning) veranschaulicht;
    • 12B ist ein Blockschaubild, das eine programmierbare Netzwerkschnittstelle und Datenverarbeitungseinheit veranschaulicht;
    • 13 veranschaulicht ein beispielhaftes Inferenzfindungssystem auf einem Chip (SOC), das zur Durchführung von Inferenzfindung unter Verwendung eines trainierten Modells geeignet ist;
    • 14 ist ein Blockschaubild eines Verarbeitungssystems;
    • 15A bis 15C veranschaulichen Rechensysteme und Grafikprozessoren;
    • 16A bis 16C veranschaulichen Blockschaubilder zusätzlicher Grafikprozessor- und Rechenbeschleuniger-Architekturen;
    • 17 ist ein Blockschaubild einer Grafikverarbeitungs-Engine eines Grafikprozessors;
    • 18A bis 18B veranschaulichen Thread-Ausfiihrungslogik einschließlich eines Arrays in einem Grafikprozessorkern eingesetzter Verarbeitungselemente;
    • 19 veranschaulicht eine zusätzliche Ausführungseinheit;
    • 20 ist ein Blockschaubild, das Grafikprozessor-Anweisungsformate veranschaulicht;
    • 21 ist ein Blockschaubild einer zusätzlichen Grafikprozessorarchitektur;
    • 22A bis 22B veranschaulichen ein Grafikprozessor-Befehlsformat und eine Befehlssequenz;
    • 23 veranschaulicht eine beispielhafte Grafiksoftwarearchitektur für ein Datenverarbeitungssystem;
    • 24A ist ein Blockschaubild, das ein IP-Kern-Entwicklungssystem veranschaulicht;
    • 24B zeigt eine seitliche Querschnittsansicht einer Package-Baugruppe für eine integrierte Schaltung;
    • 24C veranschaulicht eine Package-Baugruppe, die mehrere Einheiten aus Hardwarelogik-Chiplets aufweist, die mit einem Substrat (z.B. Basis-Die) verbunden sind;
    • 24D veranschaulicht eine Package-Baugruppe mit austauschbaren Chiplets;
    • 25 ist ein Blockschaubild, das eine beispielhafte integrierte Ein-Chip-System-Schaltung veranschaulicht;
    • 26A bis 26B sind Blockschaubilder, die beispielhafte Grafikprozessoren zur Verwendung in einem SoC veranschaulichen;
    • 27 veranschaulicht Verarbeitung in einer konfigurierbaren Pipeline gemäß einigen Ausführungsformen;
    • 28 veranschaulicht eine Verarbeitungsressource mit einer konfigurierbaren Pipeline mit doppelter Präzision zur Bereitstellung einer systolischen Ausgabe gemäß einigen Ausführungsformen;
    • 29 ist ein Flussdiagramm zur Veranschaulichung eines Prozesses zur Bereitstellung einer systolischen Ausgabe unter Verwendung einer konfigurierbaren Pipeline gemäß einigen Ausführungsformen;
    • 30 veranschaulicht die Berechnung einer horizontalen Operation über SIMD-Anweisungskanäle hinweg gemäß einigen Ausführungsformen;
    • 31 ist eine Darstellung der Anwendung von systolischer Hardware zur Durchführung einer Operation zur Verarbeitung von Werten über horizontale Kanäle hinweg gemäß einigen Ausführungsformen;
    • 32 ist ein Flussdiagramm zur Veranschaulichung eines Prozesses für eine konfigurierbare Pipeline mit doppelter Präzision zur Bereitstellung einer systolischen Ausgabe gemäß einigen Ausführungsformen;
    • 33 ist eine Darstellung einer Operation zur Bereitstellung stochastischer Rundung in einer Anwendung gemäß einigen Ausführungsformen;
    • 34 ist eine Darstellung einer Verarbeitungsressource zur Bereitstellung stochastischer Rundung von Werten gemäß einigen Ausführungsformen; und
    • 35 ist ein Flussdiagramm zur Veranschaulichung eines Prozesses zur Bereitstellung stochastischer Rundung von Werten in Anwendung gemäß einigen Ausführungsformen.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Vorliegend beschriebene Ausführungsformen betreffen allgemein erweiterte Prozessorfunktionen für Berechnungen.
  • Eine Grafikverarbeitungseinheit (GPU) ist kommunikativ mit Host- /Prozessorkernen gekoppelt, um beispielsweise Grafikoperationen, Operationen des maschinellen Lernens, Musteranalyseoperationen und/oder verschiedene Allzweck-GPU-(General-Purpose Graphics Processing Unit, GPGPU) Funktionen zu beschleunigen. Die GPU kann über einen Bus oder eine andere Verbindung (z.B. eine Hochgeschwindigkeitsverbindung wie PCIe oder NVLink) mit dem oder den Hostprozessoren/Kernen kommunikativ verbunden sein. Alternativ kann die GPU auf demselben Package oder Chip wie die Kerne integriert und mit den Kernen über eine(n) interne(n) Prozessorbus/-verbindung (d.h. innerhalb des Packages oder Chips) kommunikativ verbunden sein. Unabhängig von der Art und Weise, in der die GPU angeschlossen ist, können die Prozessorkerne der GPU Arbeit in Form von Sequenzen aus Befehlen/Anweisungen zuteilen, die in einem Arbeitsdeskriptor enthalten sind. Die GPU verwendet dann dedizierte Schalttechnik/Logik zur effizienten Verarbeitung dieser Befehle/Anweisungen.
  • In einigen Ausführungsformen bietet eine Vorrichtung, ein System oder ein Prozess erweiterte Prozessorfunktionen für Berechnungen, darunter eines oder mehrere der Folgenden:
    1. (1) Konfigurierbare Pipeline zur Bereitstellung einer systolischen Ausgabe;
    2. (2) Min/Max-Operationen (Anweisungen) unter Verwendung einer systolischen Pipeline; oder
    3. (3) Pseudo-Zufallszahlengenerator in Verarbeitungsressourcen.
  • In der nachfolgenden Beschreibung werden zahlreiche konkrete Einzelheiten angegeben, um ein besseres Verständnis der Erfindung zu vermitteln. Ein Fachmann versteht jedoch, dass die vorliegend beschriebenen Ausführungsformen auch ohne eine oder mehrere dieser konkreten Einzelheiten umgesetzt werden können. In anderen Fällen wurden bekannte Merkmale nicht beschrieben, um nicht von den Einzelheiten der vorliegenden Ausführungsformen abzulenken.
  • Systemübersicht
  • 1 ist ein Blockschaubild, das ein Datenverarbeitungssystem 100 veranschaulicht, das dafür konfiguriert ist, einen oder mehrere Aspekte der vorliegend beschriebenen Ausführungsformen zu implementieren. Das Datenverarbeitungssystem 100 weist ein Verarbeitungsteilsystem 101 mit einem oder mehreren Prozessor(en) 102 und einem Systemspeicher 104 auf, die über einen Verbindungspfad kommunizieren, der einen Speicher-Hub 105 aufweisen kann. Der Speicher-Hub 105 kann eine separate Komponente innerhalb einer Chipsatzkomponente sein oder kann in den einen oder die mehreren Prozessoren 102 integriert sein. Der Speicher-Hub 105 ist über eine Kommunikationsverbindung 106 mit einem E/A-Teilsystem 111 gekoppelt. Das E/A-Teilsystem 111 weist einen E/A-Hub 107 auf, der es dem Datenverarbeitungssystem 100 ermöglichen kann, Eingaben von einer oder mehreren Eingabeeinrichtungen 108 zu empfangen. Zusätzlich kann der E/A-Hub 107 einen Anzeigecontroller, der in dem einen oder den mehreren Prozessoren 102 umfasst sein kann, in die Lage versetzen, Ausgaben an eine oder mehrere Anzeigeeinrichtungen 110A zu liefern. In einer Ausführungsform können die eine oder die mehreren Anzeigeeinrichtungen 110A, die mit dem E/A-Hub 107 gekoppelt sind, eine lokale, interne oder eingebettete Anzeigeeinrichtung aufweisen.
  • Das Verarbeitungsteilsystem 101 weist beispielsweise einen oder mehrere Parallelprozessoren 112 auf, die über einen Bus oder eine andere Kommunikationsverbindung 113 mit dem Speicher-Hub 105 gekoppelt sind. Bei der Kommunikationsverbindung 113 kann es sich um eine beliebige Anzahl von standardbasierten Kommunikationsverbindungstechnologien oder -protokollen handeln, wie beispielsweise, ohne jedoch hierauf eingeschränkt zu sein, PCI Express, oder um eine herstellerspezifische Kommunikationsschnittstelle oder Kommunikationsstruktur („-Fabric“). Der eine oder die mehreren Parallelprozessoren 112 können ein rechnerisch fokussiertes Parallel- oder Vektorverarbeitungssystem bilden, das eine große Anzahl an Verarbeitungskernen und/oder Verarbeitungsclustern umfassen kann, wie beispielsweise einen Prozessor mit vielen integrierten Kernen (Many-Integrated-Core-, MIC-, Prozessor). Beispielsweise bilden der eine oder die mehreren Parallelprozessoren 112 ein Grafikverarbeitungsteilsystem, das Pixel an eine der einen oder der mehreren über den E/A-Hub 107 gekoppelten Anzeigeeinrichtungen 110A ausgeben kann. Der eine oder die mehreren Parallelprozessoren 112 können auch einen Anzeigecontroller und eine Anzeigeschnittstelle (nicht gezeigt) aufweisen, um eine direkte Verbindung zu einer oder mehreren Anzeigeeinrichtungen 110B zu ermöglichen.
  • Innerhalb des E/A-Teilsystems 111 kann eine Systemspeichereinheit 114 mit dem E/A-Hub 107 verbunden sein, um einen Speichermechanismus für das Datenverarbeitungssystem 100 bereitzustellen. Ein E/A-Switch 116 kann verwendet werden, um einen Schnittstellenmechanismus bereitzustellen, um Verbindungen zwischen dem E/A-Hub 107 und anderen Komponenten zu ermöglichen, wie beispielsweise einem Netzwerkadapter 118 und/oder einem drahtlosen Netzwerkadapter 119, die in die Plattform integriert werden können, und verschiedenen anderen Einrichtungen, die über eine oder mehrere Add-In-Einrichtungen 120 hinzugefügt werden können. Die eine oder die mehreren Add-In-Einrichtungen 120 können zudem beispielsweise eine oder mehrere externe Grafikprozessoreinrichtungen, Grafikkarten und/oder Rechenbeschleuniger umfassen. Der Netzwerkadapter 118 kann ein Ethernet-Adapter oder ein anderer drahtgebundener Netzwerkadapter sein. Der drahtlose Netzwerkadapter 119 kann eines oder mehrere der Folgenden umfassen: eine Wi-Fi-, Bluetooth-, eine Nahfeldkommunikations- (Near Field Communication, NFC) oder eine andere Netzwerkeinrichtung, die ein oder mehrere drahtlose Funkgeräte aufweist.
  • Das Datenverarbeitungssystem 100 kann weitere, nicht explizit gezeigte Komponenten aufweisen, darunter USB- oder andere Anschlussverbindungen, optische Speicherlaufwerke, Videoaufnahmeeinrichtungen usw., die ebenfalls an den E/A-Hub 107 angeschlossen werden können. Kommunikationspfade, die die verschiedenen Komponenten in 1 miteinander verbinden, können unter Verwendung beliebiger geeigneter Protokolle implementiert werden, beispielsweise PCI- (Peripheral Component Interconnect) basierte Protokolle (z.B. PCI-Express) oder beliebige andere Bus- oder Punkt-zu-Punkt-Kommunikationsschnittstellen und/oder -protokolle, beispielsweise die NVLink-Hochgeschwindigkeitsverbindung, Compute Express Link™ (CXL™) (z.B. CXL.mem), Infinity Fabric (IF), Ethernet (IEEE 802.3), Remote Direct Memory Access (RDMA), InfiniBand, Internet Wide Area RDMA Protocol (iWARP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Quick UDP Internet Connections (QUIC), RDMA over Converged Ethernet (RoCE), Intel QuickPath Interconnect (QPI), Intel Ultra Path Interconnect (UPI), Intel On-Chip System Fabric (IOSF), Omnipath, HyperTransport, Advanced-Microcontroller-Bus-Architecture-(AMBA-) Verbindung, OpenCAPI, Gen-Z, Cache Coherent Interconnect for Accelerators (CCIX), 3GPP Long Term Evolution (LTE) (4G), 3GPP 5G und Variationen davon oder im Stand der Technik bekannte drahtgebundene oder drahtlose Verbindungsprotokolle. In einigen Beispielen können Daten mit einem Protokoll wie beispielsweise Non-Volatile Memory Express (NVMe) over Fabrics (NVMe-oF) oder NVMe auf virtualisierte Speicherknoten kopiert oder gespeichert werden.
  • Der eine oder die mehreren Parallelprozessoren 112 können Schalttechnik enthalten, die für Grafik- und Videoverarbeitung optimiert ist, einschließlich beispielsweise Videoausgabeschalttechnik, und stellt eine Grafikverarbeitungseinheit (GPU) dar. Alternativ oder ergänzend können der eine oder die mehreren Parallelprozessoren 112 Schalttechnik aufweisen, die für Allzweckverarbeitung optimiert ist, wobei die zugrunde liegende Rechenarchitektur, die vorliegend ausführlicher beschrieben wird, erhalten bleibt. Komponenten des Datenverarbeitungssystems 100 können mit einem oder mehreren anderen Systemelementen auf einer einzigen integrierten Schaltung integriert sein. Beispielsweise können der eine oder die mehreren Parallelprozessoren 112, der Speicher-Hub 105, der/die Prozessor(en) 102 und der E/A-Hub 107 in eine integrierte Ein-Chip-System-(SoC-) Schaltung integriert sein. Alternativ können die Komponenten des Datenverarbeitungssystems 100 in ein einziges Package integriert sein, um eine Systemin-Package- (SIP-) Konfiguration zu bilden. In einer Ausführungsform kann zumindest ein Teil der Komponenten des Datenverarbeitungssystems 100 in ein Mehrchipmodul (Multi-Chip Module, MCM) integriert werden, das mit anderen Mehrchipmodulen zu einem modularen Datenverarbeitungssystem verbunden werden kann.
  • Es versteht sich, dass das vorliegend gezeigte Datenverarbeitungssystem 100 veranschaulichend ist und dass Variationen und Änderungen möglich sind. Die Verbindungstopologie, einschließlich der Anzahl und Anordnung von Brücken, der Anzahl an Prozessoren 102 und der Anzahl der Parallelprozessoren 112, kann nach Belieben geändert werden. Beispielsweise kann der Systemspeicher 104 direkt und nicht über eine Brücke mit dem/den Prozessor(en) 102 verbunden werden, während andere Einrichtungen über den Speicher-Hub 105 und den/die Prozessor(en) 102 mit dem Systemspeicher 104 kommunizieren. In anderen alternativen Topologien sind der/die Parallelprozessor(en) 112 mit dem E/A-Hub 107 oder direkt mit einem des einen oder der mehreren Prozessoren 102 verbunden, anstatt mit dem Speicher-Hub 105. In anderen Ausführungsformen können der E/A-Hub 107 und der Speicher-Hub 105 in einem einzigen Chip integriert sein. Es ist auch möglich, dass zwei oder mehr Sätze von Prozessoren 102 über mehrere Sockel angeschlossen sind, die mit zwei oder mehr Instanzen des/der Parallelprozessors(en) 112 gekoppelt werden können.
  • Einige der vorliegend gezeigten besonderen Komponenten sind optional und möglicherweise nicht in allen Implementierungen des Datenverarbeitungssystems 100 umfasst. So kann beispielsweise eine beliebige Anzahl an Zusatzkarten oder Peripheriegeräten unterstützt werden, oder einige Komponenten können entfallen. Darüber hinaus können einige Architekturen andere Terminologie für Komponenten verwenden, die den in 1 dargestellten ähnlich sind. Zum Beispiel kann der Speicher-Hub 105 in einigen Architekturen als Northbridge bezeichnet werden, während der E/A-Hub 107 als Southbridge bezeichnet werden kann.
  • 2A veranschaulicht einen Parallelprozessor 200. Der Parallelprozessor 200 kann eine GPU, GPGPU oder ähnliches sein, wie vorliegend beschrieben. Die verschiedenen Komponenten des Parallelprozessors 200 können mit einer oder mehreren integrierten Schaltungseinrichtungen implementiert werden, beispielsweise programmierbaren Prozessoren, anwendungsspezifischen integrierten Schaltungen (ASICs) oder feldprogrammierbaren Gate-Arrays (FPGAs). Bei dem dargestellten Parallelprozessor 200 kann es sich um einen oder mehrere der in 1 gezeigten Parallelprozessor(en) 112 handeln.
  • Der Parallelprozessor 200 weist eine Parallelverarbeitungseinheit 202 auf. Die Parallelverarbeitungseinheit weist eine E/A-Einheit 204 auf, die Kommunikation mit anderen Einrichtungen, einschließlich anderer Instanzen der Parallelverarbeitungseinheit 202, ermöglicht. Die E/A-Einheit 204 kann direkt mit anderen Einrichtungen verbunden sein. Beispielsweise ist die E/A-Einheit 204 über eine Hub- oder Switch-Schnittstelle, beispielsweise den Speicher-Hub 105, mit anderen Einrichtungen verbunden. Die Verbindungen zwischen dem Speicher-Hub 105 und der E/A-Einheit 204 bilden eine Kommunikationsverbindung 113. Innerhalb der Parallelverarbeitungseinheit 202 ist die E/A-Einheit 204 mit einer Hostschnittstelle 206 und einer Speicherkreuzschiene 216 verbunden, wobei die Hostschnittstelle 206 Befehle zur Durchführung von Verarbeitungsoperationen und die Speicherkreuzschiene 216 Befehle zur Durchführung von Speicheroperationen empfängt.
  • Wenn die Hostschnittstelle 206 einen Befehlspuffer über die E/A-Einheit 204 empfängt, kann die Hostschnittstelle 206 Arbeitsoperationen zur Durchführung dieser Befehle an ein Front-End 208 leiten. In einer Ausführungsform ist das Front-End 208 mit einem Scheduler 210 gekoppelt, der dafür konfiguriert ist, Befehle oder andere Arbeitselemente an ein Verarbeitungscluster-Array 212 zu verteilen. Der Scheduler 210 stellt sicher, dass das Verarbeitungscluster-Array 212 ordnungsgemäß konfiguriert ist und sich in einem gültigen Zustand befindet, bevor Aufgaben an die Verarbeitungscluster des Verarbeitungscluster-Arrays 212 verteilt werden. Der Scheduler 210 kann über Firmwarelogik implementiert werden, die auf einem Mikrocontroller ausgeführt wird. Der von einem Mikrocontroller implementierte Scheduler 210 ist so konfigurierbar, dass er komplexe Planungs- und Arbeitsverteilungsoperationen mit grober und feiner Granularität durchführen kann, was eine schnelle Zurückstellung und Kontextumschaltung von Threads ermöglicht, die auf dem Verarbeitungscluster-Array 212 ausgeführt werden. Bevorzugt kann die Hostsoftware über eine von mehreren Grafikverarbeitungs-Doorbells Arbeitslasten für die Planung auf dem Verarbeitungscluster-Array 212 bestätigen. In anderen Beispielen kann die Abfrage nach neuen Arbeitslasten oder Interrupts verwendet werden, um die Verfügbarkeit von auszuführender Arbeit zu identifizieren oder anzuzeigen. Die Arbeitslasten können dann von der Logik des Schedulers 210 im Scheduler-Mikrocontroller automatisch auf das Verarbeitungscluster-Array 212 verteilt werden.
  • Das Verarbeitungscluster-Array 212 kann bis zu „N“ Verarbeitungscluster umfassen (z. B. Cluster 214A, Cluster 214B bis Cluster 214N). Jeder Cluster 214A bis 214N des Verarbeitungscluster-Arrays 212 kann eine große Anzahl von gleichzeitigen Threads ausführen. Der Scheduler 210 kann den Clustern 214A bis 214N des Verarbeitungscluster-Arrays 212 Arbeit zuteilen, indem er verschiedene Planungs- und/oder Arbeitsverteilungsalgorithmen verwendet, die in Abhängigkeit von der Arbeitslast variieren können, die für jede Art von Programm oder Berechnung anfällt. Die Planung kann dynamisch durch den Scheduler 210 erfolgen oder teilweise durch Compilerlogik während der Kompilierung von Programmlogik unterstützt werden, die für die Ausführung durch das Verarbeitungs-Cluster-Array 212 konfiguriert ist. Wahlweise können verschiedene Cluster 214A bis 214N des Verarbeitungscluster-Arrays 212 für die Verarbeitung verschiedener Programmtypen oder für die Durchführung verschiedener Arten von Berechnungen zugeteilt werden.
  • Das Verarbeitungscluster-Array 212 kann so konfiguriert sein, dass es verschiedene Arten von Parallelverarbeitungsoperationen durchführt. Beispielsweise ist das Verarbeitungscluster-Array 212 so konfiguriert, dass es Allzweck-Parallelrechenoperationen durchführt. Beispielsweise kann das Verarbeitungscluster-Array 212 Logik zur Ausführung von Verarbeitungsaufgaben aufweisen, einschließlich Filterung von Video- und/oder Audiodaten, Durchführung von Modellierungsoperationen, einschließlich physikalischer Operationen, und Durchführung von Datentransformationen.
  • Das Verarbeitungscluster-Array 212 ist so konfiguriert, dass es parallele Grafikverarbeitungsoperationen durchführt. In solchen Ausführungsformen, in denen der Parallelprozessor 200 so konfiguriert ist, dass er Grafikverarbeitungsoperationen durchführt, kann das Verarbeitungscluster-Array 212 zusätzliche Logik aufweisen, um die Ausführung solcher Grafikverarbeitungsoperationen zu unterstützen, darunter, ohne jedoch hierauf eingeschränkt zu sein, Textursamplinglogik, um Texturoperationen durchzuführen, sowie Tesselationslogik und andere Vertexverarbeitungslogik. Zusätzlich kann das Verarbeitungscluster-Array 212 so konfiguriert werden, dass es grafikverarbeitungsbezogene Schattierprogramme ausführt, beispielsweise, ohne jedoch hierauf eingeschränkt zu sein, Vertex-Shader, Tesselations-Shader, Geometrie-Shader und Pixel-Shader. Die Parallelverarbeitungseinheit 202 kann Daten aus dem Systemspeicher über die E/A-Einheit 204 zur Verarbeitung übertragen. Während der Verarbeitung können die übertragenen Daten in einem On-Chip-Speicher (z. B. Parallelprozessorspeicher 222) gespeichert und anschließend in den Systemspeicher zurückgeschrieben werden.
  • In Ausführungsformen, in denen die Parallelverarbeitungseinheit 202 zur Durchführung der Grafikverarbeitung verwendet wird, kann der Scheduler 210 so konfiguriert sein, dass er die Verarbeitungslast in ungefähr gleich große Aufgaben aufteilt, um eine bessere Verteilung der Grafikverarbeitungsoperationen auf mehrere Cluster 214A bis 214N des Verarbeitungscluster-Arrays 212 zu ermöglichen. In einigen dieser Ausführungsformen können Teile des Verarbeitungs-Cluster-Arrays 212 so konfiguriert werden, dass sie verschiedene Arten der Verarbeitung durchführen. Beispielsweise kann ein erster Teil so konfiguriert sein, dass er Vertexschattierung und Topologieerzeugung durchführt, ein zweiter Teil kann so konfiguriert sein, dass er Tesselation und Geometrieschattierung durchführt, und ein dritter Teil kann so konfiguriert sein, dass er Pixelschattierung oder andere Operationen im Bildschirmraum durchführt, um ein gerendertes Bild für die Anzeige zu erzeugen. Von einem oder mehreren der Cluster 214A bis 214N erzeugte Zwischendaten können in Puffern gespeichert werden, damit die Zwischendaten zur weiteren Verarbeitung zwischen den Clustern 214A bis 214N übertragen werden können.
  • Während des Betriebs kann das Verarbeitungscluster-Array 212 auszuführende Verarbeitungsaufgaben über den Scheduler 210 empfangen, der Befehle zur Definition von Verarbeitungsaufgaben vom Front-End 208 empfängt. Bei Grafikverarbeitungsvorgängen können die Verarbeitungsaufgaben Indizes der zu verarbeitenden Daten umfassen, z.B. Oberflächen- (Patch-) Daten, Primitivdaten, Vertexdaten und/oder Pixeldaten, sowie Statusparameter und Befehle, die definieren, wie die Daten verarbeitet werden sollen (z.B. welches Programm ausgeführt werden soll). Der Scheduler 210 kann so konfiguriert sein, dass er die den Aufgaben entsprechenden Indizes abruft, oder er kann die Indizes vom Front-End 208 empfangen. Das Front-End 208 kann so konfiguriert werden, dass sichergestellt wird, dass das Verarbeitungscluster-Array 212 in einen gültigen Zustand versetzt wird, bevor die durch eingehende Befehlspuffer (z.B. Batch-Puffer, Push-Puffer usw.) spezifizierte Arbeitslast initiiert wird.
  • Jede der einen oder der mehreren Instanzen der Parallelverarbeitungseinheit 202 kann mit dem Parallelprozessorspeicher 222 gekoppelt sein. Auf den Parallelprozessorspeicher 222 kann über die Speicherkreuzschiene 216 zugegriffen werden, die sowohl vom Verarbeitungscluster-Array 212 als auch von der E/A-Einheit 204 Speicheranfragen empfangen kann. Die Speicherkreuzschiene 216 kann über eine Speicherschnittstelle 218 auf den Parallelprozessorspeicher 222 zugreifen. Die Speicherschnittstelle 218 kann mehrere Partitionseinheiten (z.B. Partitionseinheit 220A, Partitionseinheit 220B bis Partitionseinheit 220N) aufweisen, die jeweils mit einem Teil (z.B. Speichereinheit) des Parallelprozessorspeichers 222 gekoppelt sein können. Die Anzahl der Partitionseinheiten 220A bis 220N kann so konfiguriert sein, dass sie gleich der Anzahl der Speichereinheiten ist, so dass eine erste Partitionseinheit 220A eine entsprechende erste Speichereinheit 224A hat, eine zweite Partitionseinheit 220B eine entsprechende zweite Speichereinheit 224B hat und eine N-te Partitionseinheit 220N eine entsprechende N-te Speichereinheit 224N hat. In anderen Ausführungsformen ist die Anzahl an Partitionseinheiten 220A bis 220N möglicherweise nicht gleich der Anzahl der Speichereinrichtungen.
  • Die Speichereinheiten 224A bis 224N können verschiedene Arten von Speichereinrichtungen aufweisen, einschließlich dynamischer Direktzugriffsspeicher (DRAM) oder Grafik-Direktzugriffsspeicher, wie synchroner Grafik-Direktzugriffsspeicher (SGRAM), einschließlich Grafik-Doppeldatenraten- (GDDR-) Speicher. Wahlweise können die Speichereinheiten 224A bis 224N zudem 3D-Stapelspeicher enthalten, darunter, ohne jedoch hierauf eingeschränkt zu sein, Speicher mit hoher Bandbreite (High Bandwidth Memory, HBM-, Speicher). Der Fachmann versteht, dass die konkrete Implementierung der Speichereinheiten 224A bis 224N variieren kann und aus einer von verschiedenen herkömmlichen Ausführungen gewählt werden kann. Render-Ziele wie beispielsweise Rahmenpuffer oder Texturkarten können über die Speichereinheiten 224A bis 224N hinweg gespeichert werden, so dass die Partitionseinheiten 220A bis 220N Teile jedes Render-Ziels parallel schreiben können, um die verfügbare Bandbreite des Parallelprozessorspeichers 222 effizient zu nutzen. In einigen Ausführungsformen kann eine lokale Instanz des Parallelprozessorspeichers 222 zugunsten eines vereinheitlichten Speicherdesigns ausgeschlossen werden, das den Systemspeicher in Verbindung mit lokalem Cachespeicher nutzt.
  • Wahlweise kann jeder der Cluster 214A bis 214N des Verarbeitungscluster-Arrays 212 Daten verarbeiten, die in eine der Speichereinheiten 224A bis 224N im Parallelprozessorspeicher 222 geschrieben werden. Die Speicherkreuzschiene 216 kann so konfiguriert werden, dass die Ausgabe jedes Clusters 214A bis 214N an eine beliebige Partitionseinheit 220A bis 220N oder an einen anderen Cluster 214A bis 214N übertragen wird, der weitere Verarbeitungsoperationen an der Ausgabe durchführen kann. Jeder Cluster 214A bis 214N kann mit der Speicherschnittstelle 218 über die Speicherkreuzschiene 216 kommunizieren, um aus verschiedenen externen Speichereinrichtungen zu lesen oder in diese zu schreiben. In einer der Ausführungsformen mit der Speicherkreuzschiene 216 hat die Speicherkreuzschiene 216 eine Verbindung zur Speicherschnittstelle 218, um mit der E/A-Einheit 204 zu kommunizieren, sowie eine Verbindung zu einer lokalen Instanz des Parallelprozessorspeichers 222, die es den Verarbeitungseinheiten innerhalb der verschiedenen Verarbeitungscluster 214A bis 214N ermöglicht, mit dem Systemspeicher oder einem anderen Speicher zu kommunizieren, der sich nicht lokal in der Parallelverarbeitungseinheit 202 befindet. Generell kann die Speicherkreuzschiene 216 beispielsweise virtuelle Kanäle verwenden, um Verkehrsströme zwischen den Clustern 214A bis 214N und den Partitionseinheiten 220A bis 220N zu trennen.
  • Zwar ist eine einzige Instanz der Parallelverarbeitungseinheit 202 innerhalb des Parallelprozessors 200 dargestellt, jedoch kann eine beliebige Anzahl an Instanzen der Parallelverarbeitungseinheit 202 umfasst sein. Beispielsweise können mehrere Instanzen der Parallelverarbeitungseinheit 202 auf einer einzigen Einsteckkarte bereitgestellt werden, oder es können mehrere Einsteckkarten miteinander verbunden werden. Beispielsweise kann der Parallelprozessor 200 eine Add-in-Einrichtung sein, wie die Add-in-Einrichtung 120 in 1, die eine Grafikkarte sein kann, wie eine diskrete Grafikkarte, die einen oder mehrere Grafikprozessoren, eine oder mehrere Speichereinrichtungen und Einrichtung-zu-Einrichtung- oder Netzwerk- oder Fabric-Schnittstellen umfasst. Die verschiedenen Instanzen der Parallelverarbeitungseinheit 202 können so konfiguriert werden, dass sie auch dann zusammenarbeiten, wenn die verschiedenen Instanzen eine unterschiedliche Anzahl an Prozessorkemen, unterschiedliche Mengen an lokalem Parallelprozessorspeicher und/oder andere Konfigurationsunterschiede aufweisen. Optional können einige Instanzen der Parallelverarbeitungseinheit 202 im Vergleich zu anderen Instanzen Gleitkommaeinheiten mit höherer Präzision aufweisen. Systeme, die eine oder mehrere Instanzen der Parallelverarbeitungseinheit 202 oder des Parallelprozessors 200 aufweisen, können in einer Vielzahl von Konfigurationen und Formfaktoren implementiert werden, darunter, ohne jedoch hierauf eingeschränkt zu sein, Desktop-, Laptop- oder Handheld-Personalcomputer, Server, Workstations, Spielkonsolen und/oder eingebettete Systeme. Ein Orchestrator kann Verbundknoten für Arbeitslastendurchfiihrung bilden, indem er eines oder mehrere der Folgenden verwendet: disaggregierte Prozessorressourcen, Cacheressourcen, (Arbeits- )Speicherressourcen, (Fest-)Speicherressourcen und Netzwerkressourcen.
  • 2B ist ein Blockschaubild einer Partitionseinheit 220. Die Partitionseinheit 220 kann eine Instanz einer der Partitionseinheiten 220A bis 220N aus 2A sein. Wie dargestellt, umfasst die Partitionseinheit 220 einen L2-Cache 221, eine Rahmenpufferschnittstelle 225 und eine ROP 226 (Raster Operations Unit, Rasteroperationseinheit). Der L2-Cache 221 ist ein Lese-/Schreibcache, der für die Durchführung von Lade- und Speicheroperationen konfiguriert ist, die von der Speicherkreuzschiene 216 und der ROP 226 empfangen werden. Lesefehler und dringende Rückschreibanfragen werden vom L2-Cache 221 an die Rahmenpufferschnittstelle 225 zur Verarbeitung ausgegeben. Aktualisierungen können zudem über die Rahmenpufferschnittstelle 225 zur Verarbeitung an den Rahmenpuffer gesendet werden. In einer Ausführungsform ist die Rahmenpufferschnittstelle 225 mit einer der Speichereinheiten im Parallelprozessorspeicher verbunden, beispielsweise mit den Speichereinheiten 224A bis 224N aus 2A (z.B. innerhalb des Parallelprozessorspeichers 222). Die Partitionseinheit 220 kann zusätzlich oder alternativ auch mit einer der Speichereinheiten im Parallelprozessorspeicher über einen Speichercontroller (nicht gezeigt) verbunden sein.
  • In Grafikanwendungen ist die ROP 226 eine Verarbeitungseinheit, die Rasteroperationen wie Schablonen, z-Test, Blending und ähnliches durchführt. Die ROP 226 gibt dann verarbeitete Grafikdaten aus, die im Grafikspeicher gespeichert werden. In einigen Ausführungsformen weist die ROP 226 einen CODEC 227 auf oder ist mit diesem gekoppelt, der eine Komprimierungslogik aufweist, um Tiefen- oder Farbdaten zu komprimieren, die in den Speicher oder den L2-Cache 221 geschrieben werden, und Tiefen- oder Farbdaten zu dekomprimieren, die aus dem Speicher oder dem L2-Cache 221 gelesen werden. Die Komprimierungslogik kann eine Logik für verlustfreie Komprimierung sein, die einen oder mehrere von mehreren Komprimierungsalgorithmen verwendet. Die Art der Komprimierung, die vom CODEC 227 durchgeführt wird, kann je nach den statistischen Eigenschaften der zu komprimierenden Daten variieren. In einer Ausführungsform wird beispielsweise eine Delta-Farbkomprimierung an Tiefen- und Farbdaten auf einer Pro-Kachel-Basis durchgeführt. In einer Ausführungsform weist der CODEC 227 eine Komprimierungs- und Dekomprimierungslogik auf, die mit maschinellen Lernoperationen verbundene Rechendaten komprimieren und dekomprimieren kann. Der CODEC 227 kann beispielsweise spärliche Matrixdaten für spärliche maschinelle Lernoperationen komprimieren. Der CODEC 227 kann auch spärliche Matrixdaten komprimieren, die in einem Sparse-Matrix-Format kodiert sind (z.B. Koordinatenlistencodierung (Coordinate List Encoding, COO), Compressed Sparse Row (CSR), Compress Sparse Column (CSC) usw.), um komprimierte und codierte spärliche Matrixdaten zu erzeugen. Die komprimierten und codierten spärlichen Matrixdaten können dekomprimiert und/oder decodiert werden, bevor sie von Verarbeitungselementen verarbeitet werden, oder die Verarbeitungselemente können so konfiguriert werden, dass sie komprimierte, codierte oder komprimierte und codierte Daten für die Verarbeitung aufnehmen.
  • Die ROP 226 kann in jedem Verarbeitungscluster (z.B. Cluster 214A bis 214N aus 2A) anstatt innerhalb der Partitionseinheit 220 umfasst sein. In einer solchen Ausführungsform werden Lese- und Schreibanfragen für Pixeldaten über die Speicherkreuzschiene 216 anstelle von Pixelfragmentdaten übertragen. Die verarbeiteten Grafikdaten können auf einer Anzeigeeinrichtung, beispielsweise der einen oder den mehreren Anzeigeeinrichtungen 110 aus 1, angezeigt, zur weiteren Verarbeitung durch den/die Prozessor(en) 102 weitergeleitet oder zur weiteren Verarbeitung durch eine der Verarbeitungseinheiten innerhalb des Parallelprozessors 200 aus 2A weitergeleitet werden.
  • 2C ist ein Blockschaubild eines Verarbeitungsclusters 214 innerhalb einer Parallelverarbeitungseinheit. Der Verarbeitungscluster ist beispielsweise eine Instanz eines der Verarbeitungscluster 214A bis 214N aus 2A. Der Verarbeitungscluster 214 kann so konfiguriert werden, dass viele Threads parallel ausgeführt werden, wobei sich der Begriff „Thread“ auf eine Instanz eines bestimmten Programms bezieht, das an einem bestimmten Satz von Eingabedaten ausgeführt wird. Wahlweise können SIMD- (Single-Instruction, Multiple-Data) Anweisungsausgabemethoden verwendet werden, um die parallele Ausführung einer großen Anzahl von Threads zu unterstützen, ohne mehrere unabhängige Anweisungseinheiten bereitzustellen. Alternativ können SIMT- (Single-Instruction, Multiple-Thread) Methoden verwendet werden, um die parallele Ausführung einer großen Anzahl allgemein synchronisierter Threads zu unterstützen, wobei eine gemeinsame Anweisungseinheit verwendet wird, die so konfiguriert ist, dass sie Anweisungen an eine Reihe von Verarbeitungs-Engines innerhalb jedes der Verarbeitungscluster ausgibt. Im Gegensatz zu einem SIMD-Ausführungsregime, bei dem alle Verarbeitungs-Engines typischerweise identische Anweisungen ausführen, ermöglicht die SIMT-Ausführung, dass verschiedene Threads leichter unterschiedlichen Ausführungspfaden durch ein bestimmtes Thread-Programm folgen können. Ein Fachmann versteht, dass ein SIMD-Verarbeitungsregime einen Funktionsteilsatz eines SIMT-Verarbeitungsregimes darstellt.
  • Der Betrieb des Verarbeitungsclusters 214 kann über einen Pipeline-Manager 232 gesteuert werden, der die Verarbeitungsaufgaben auf die SIMT-Parallelprozessoren verteilt. Der Pipeline-Manager 232 empfängt Anweisungen vom Scheduler 210 aus 2A und verwaltet die Ausführung dieser Anweisungen über einen Grafik-Multiprozessor 234 und/oder eine Textureinheit 236. Der abgebildete Grafik-Multiprozessor 234 ist eine beispielhafte Instanz eines SIMT-Parallelprozessors. Es können jedoch verschiedene Typen von SIMT-Parallelprozessoren mit unterschiedlichen Architekturen in den Verarbeitungscluster 214 umfasst sein. Eine oder mehrere Instanzen des Grafik-Multiprozessors 234 können in einem Verarbeitungscluster 214 umfasst sein. Der Grafik-Multiprozessor 234 kann Daten verarbeiten, und eine Datenkreuzschiene 240 kann verwendet werden, um die verarbeiteten Daten an eines von mehreren möglichen Zielen, einschließlich anderer Schattiereinheiten, zu verteilen. Der Pipeline-Manager 232 kann die Verteilung der verarbeiteten Daten erleichtern, indem er Ziele für die über die Datenkreuzschiene 240 zu verteilenden verarbeiteten Daten angibt.
  • Jeder Grafik-Multiprozessor 234 innerhalb des Verarbeitungsclusters 214 kann einen identischen Satz Funktionsausführungslogik aufweisen (z.B. arithmetisch-logische Einheiten, Lade-/Speichereinheiten usw.). Die Funktionsausführungslogik kann als Pipeline konfiguriert sein, in der neue Anweisungen ausgegeben werden können, bevor vorherige Anweisungen abgeschlossen sind. Die Funktionsausführungslogik unterstützt eine Vielzahl von Operationen, darunter Ganzzahl- und Gleitkommaarithmetik, Vergleichsoperationen, boolesche Operationen, Bitverschiebung und die Berechnung verschiedener algebraischer Funktionen. Hardware mit gleichen Funktionseinheiten kann zur Ausführung verschiedener Operationen verwendet werden, und es kann eine beliebige Kombination von Funktionseinheiten vorhanden sein.
  • Die an den Verarbeitungscluster 214 übertragenen Anweisungen bilden einen Thread. Ein Satz von Threads, die über den Satz paralleler Verarbeitungs-Engines hinweg ausgeführt werden, ist eine Thread-Gruppe. Eine Thread-Gruppe führt das gleiche Programm an unterschiedlichen Eingabedaten aus. Jeder Thread innerhalb einer Thread-Gruppe kann einer anderen Verarbeitungs-Engine innerhalb eines Grafik-Multiprozessors 234 zugewiesen werden. Eine Thread-Gruppe kann weniger Threads umfassen als die Anzahl der Verarbeitungs-Engines innerhalb des Grafik-Multiprozessors 234. Wenn eine Thread-Gruppe weniger Threads umfasst als die Anzahl der Verarbeitungs-Engines, können eine oder mehrere der Verarbeitungs-Engines während der Zyklen, in denen diese Thread-Gruppe verarbeitet wird, untätig sein. Eine Thread-Gruppe kann auch mehr Threads umfassen als die Anzahl der Verarbeitungs-Engines innerhalb des Grafik-Multiprozessors 234. Wenn die Thread-Gruppe mehr Threads umfasst als die Anzahl der Verarbeitungs-Engines innerhalb des Grafik-Multiprozessors 234, kann die Verarbeitung über aufeinanderfolgende Taktzyklen erfolgen. Wahlweise können mehrere Thread-Gruppen gleichzeitig auf dem Grafik-Multiprozessor 234 ausgeführt werden.
  • Der Grafik-Multiprozessor 234 kann einen internen Cachespeicher aufweisen, um Lade- und Speicheroperationen durchzuführen. Optional kann der Grafik-Multiprozessor 234 auf einen internen Cache verzichten und einen Cachespeicher (z.B. Level-1- (L1-) Cache 248) innerhalb des Verarbeitungsclusters 214 verwenden. Jeder Grafik-Multiprozessor 234 hat zudem Zugriff auf Level-2- (L2-) Caches innerhalb der Partitionseinheiten (z.B. Partitionseinheiten 220A bis 220N aus 2A), die von allen Verarbeitungsclustern 214 gemeinsam genutzt werden und zur Datenübertragung zwischen Threads verwendet werden können. Der Grafik-Multiprozessor 234 kann auch auf globalen Off-Chip-Speicher zugreifen, der einen oder mehrere lokale Parallelprozessorspeicher und/oder Systemspeicher umfassen kann. Als globaler Speicher kann ein beliebiger Speicher außerhalb der Parallelverarbeitungseinheit 202 verwendet werden. Ausführungsformen, in denen der Verarbeitungscluster 214 mehrere Instanzen des Grafik-Multiprozessors 234 aufweist, können gemeinsame Anweisungen und Daten nutzen, die im L1-Cache 248 gespeichert werden können.
  • Jeder Verarbeitungscluster 214 kann eine MMU 245 (Memory Management Unit) aufweisen, die so konfiguriert ist, dass sie virtuelle Adressen auf physische Adressen abbildet. In anderen Ausführungsformen können sich eine oder mehrere Instanzen der MMU 245 innerhalb der Speicherschnittstelle 218 aus 2A befinden. Die MMU 245 weist einen Satz von Seitentabelleneinträgen (Page Table Entries, PTEs), die verwendet werden, um eine virtuelle Adresse auf eine physische Adresse einer Kachel abzubilden, und wahlweise einen Cachezeilenindex auf. Die MMU 245 kann Adressübersetzungs-Lookaside-Puffer (Translation Lookaside Buffer, TLB) oder Caches aufweisen, die sich im Grafik-Multiprozessor 234 oder im L1-Cache oder Verarbeitungscluster 214 befinden können. Die physische Adresse wird verarbeitet, um die Zugriffslokalität der Oberflächendaten zu verteilen, um ein effizientes Request Interleaving unter Partitionseinheiten zu ermöglichen. Der Cachezeilenindex kann verwendet werden, um festzustellen, ob eine Anforderung für eine Cachezeile ein Hit oder Miss ist.
  • In Grafik- und Datenverarbeitungsanwendungen kann ein Verarbeitungscluster 214 so konfiguriert sein, dass jeder Grafik-Multiprozessor 234 mit einer Textureinheit 236 gekoppelt ist, um Texturabbildungsoperationen durchzuführen, z.B. Bestimmenvon Texturabtastpositionen, Lesen von Texturdaten und Filtern der Texturdaten. Texturdaten werden aus einem internen Textur-L1-Cache (nicht gezeigt) oder in einigen Ausführungsformen aus dem L1-Cache innerhalb des Grafik-Multiprozessors 234 gelesen und je nach Bedarf aus einem L2-Cache, dem lokalen Parallelprozessorspeicher oder dem Systemspeicher abgerufen. Jeder Grafik-Multiprozessor 234 gibt verarbeitete Aufgaben an die Datenkreuzschiene 240 aus, um die verarbeitete Aufgabe einem anderen Verarbeitungscluster 214 zur weiteren Verarbeitung zur Verfügung zu stellen oder um die verarbeitete Aufgabe über die Speicherkreuzschiene 216 in einem L2-Cache, einem lokalen Parallelprozessorspeicher oder im Systemspeicher zu speichern. Eine preROP 242 (pre-raster operations unit, Vor-Raster-Operationseinheit) ist so konfiguriert, dass sie Daten vom Grafik-Multiprozessor 234 empfängt und Daten an ROP-Einheiten weiterleitet, die sich bei vorliegend beschriebenen Partitionseinheiten befinden können (z.B. die Partitionseinheiten 220A bis 220N aus 2A). Die preROP- 242 Einheit kann Optimierungen für Farbmischung durchführen, Pixelfarbdaten organisieren und Adressübersetzungen vornehmen.
  • Es versteht sich, dass die vorliegend beschriebene Kernarchitektur veranschaulichend ist und dass Variationen und Änderungen möglich sind. Eine beliebige Anzahl von Verarbeitungseinheiten, z.B. Grafik-Multiprozessor 234, Textureinheiten 236, PreROPs 242 usw., kann in einem Verarbeitungscluster 214 umfasst sein. Ferner kann, auch wenn nur ein Verarbeitungscluster 214 gezeigt wird, eine vorliegend beschriebene Parallelverarbeitungseinheit eine beliebige Anzahl an Instanzen des Verarbeitungsclusters 214 umfassen. Wahlweise kann jeder Verarbeitungscluster 214 so konfiguriert werden, dass er unabhängig von anderen Verarbeitungsclustern 214 arbeitet und separate und unterschiedliche Verarbeitungseinheiten, L1-Caches, L2-Caches usw. verwendet.
  • 2D zeigt ein Beispiel des Grafik-Multiprozessors 234, bei dem der Grafik-Multiprozessor 234 mit dem Pipeline-Manager 232 des Verarbeitungsclusters 214 gekoppelt ist. Der Grafik-Multiprozessor 234 verfügt über eine Ausführungspipeline, die, ohne jedoch hierauf eingeschränkt zu sein, einen Anweisungscache 252, eine Anweisungseinheit 254, eine Adressabbildungseinheit 256, eine Registerdatei 258, einen oder mehrere GPGPU- (General Purpose Graphics Processing Unit) Kerne 262 und eine oder mehrere Lade-/Speichereinheiten 266 umfasst. Die GPGPU-Kerne 262 und Lade-/Speichereinheiten 266 sind über eine Speicher- und Cacheverbindung 268 mit dem Cachespeicher 272 und dem gemeinsamen Speicher 270 gekoppelt. Der Grafik-Multiprozessor 234 kann zusätzlich Tensor- und/oder Strahlverfolgungs- (Ray Tracing) Kerne 263 aufweisen, die Hardwarelogik zur Beschleunigung von Matrix- und/oder Strahlverfolgungsoperationen aufweisen.
  • Der Anweisungscache 252 kann einen Strom von auszuführenden Anweisungen vom Pipeline-Manager 232 empfangen. Die Anweisungen werden im Anweisungscache 252 zwischengespeichert und von der Anweisungseinheit 254 zur Ausführung verschickt. Die Anweisungseinheit 254 kann Anweisungen als Thread-Gruppen (z.B. Warps) versenden, wobei jeder Thread der Thread-Gruppe einer anderen Ausführungseinheit innerhalb des GPGPU-Kerns 262 zugewiesen ist. Eine Anweisung kann auf einen beliebigen lokalen, gemeinsamen oder globalen Adressraum zugreifen, indem sie eine Adresse innerhalb eines vereinheitlichten Adressraums angibt. Die Adressabbildungseinheit 256 kann verwendet werden, um Adressen im vereinheitlichten Adressraum in eine eindeutige Speicheradresse zu übersetzen, auf die von den Lade-/Speichereinheiten 266 zugegriffen werden kann.
  • Die Registerdatei 258 stellt einen Satz von Registern für die Funktionseinheiten des Grafik-Multiprozessors 234 bereit. Die Registerdatei 258 stellt temporäre Speicherung von Operanden bereit, die mit den Datenpfaden der Funktionseinheiten (z. B. GPGPU-Kerne 262, Lade-/Speichereinheiten 266) des Grafik-Multiprozessors 234 verbunden sind. Die Registerdatei 258 kann zwischen den einzelnen Funktionseinheiten so aufgeteilt werden, dass jeder Funktionseinheit ein eigener Teil der Registerdatei 258 zugeteilt wird. Zum Beispiel kann die Registerdatei 258 auf die verschiedenen Warps aufgeteilt werden, die vom Grafik-Multiprozessor 234 ausgeführt werden.
  • Die GPGPU-Kerne 262 können jeweils Gleitkommaeinheiten (Floating Point Units, FPUs) und/oder arithmetisch-logische Einheiten (ALUs) für Ganzzahlen enthalten, die zur Ausführung von Anweisungen des Grafik-Multiprozessors 234 verwendet werden. In einigen Implementierungen können die GPGPU-Kerne 262 Hardwarelogik enthalten, die sich ansonsten in den Tensor- und/oder Strahlverfolgungskernen 263 befinden könnte. Die GPGPU-Kerne 262 können in ihrer Architektur ähnlich sein oder sich unterscheiden. Zum Beispiel und in einer Ausführungsform weist ein erster Teil der GPGPU-Kerne 262 eine FPU mit einfacher Präzision und eine Ganzzahl-ALU auf, während ein zweiter Teil der GPGPU-Kerne eine FPU mit doppelter Präzision aufweist. Wahlweise können die FPUs den IEEE 754-2008-Standard für Gleitkommaarithmetik implementieren oder Gleitkommaarithmetik mit variabler Präzision ermöglichen. Der Grafik-Multiprozessor 234 kann zusätzlich eine oder mehrere Festfunktions- oder Spezialfunktionseinheiten aufweisen, um bestimmte Funktionen wie z.B. Kopierrechteck- oder Pixel-Blending-Operationen durchzuführen. Einer oder mehrere der GPGPU-Kerne können zudem Fest- oder Spezialfunktionslogik aufweisen.
  • Die GPGPU-Kerne 262 können SIMD-Logik aufweisen, die in der Lage ist, eine einzige Anweisung an mehreren Datensätzen auszuführen. Wahlweise können die GPGPU-Kerne 262 physikalisch SIMD4-, SIMD8- und SIMD16-Anweisungen und logisch SIMD1-, SIMD2- und SIMD32-Anweisungen ausführen. Die SIMD-Anweisungen für die GPGPU-Kerne können zur Kompilierzeit von einem Shader-Compiler oder automatisch bei der Ausführung von Programmen erzeugt werden, die für Single-Program-Multiple-Data- (SPMD-) oder SIMT-Architekturen geschrieben und kompiliert wurden. Mehrere Threads eines für das SIMT-Ausführungsmodell konfigurierten Programms können über eine einzige SIMD-Anweisung ausgeführt werden. Beispielsweise und in einer Ausführungsform können acht SIMT-Threads, die gleiche oder ähnliche Operationen durchführen, parallel über eine einzige SIMD8-Logikeinheit ausgeführt werden.
  • Die Speicher- und Cacheverbindung 268 ist ein Verbindungsnetzwerk, das jede der Funktionseinheiten des Grafik-Multiprozessors 234 mit der Registerdatei 258 und mit dem gemeinsamen Speicher 270 verbindet. Zum Beispiel ist die Speicher- und Cacheverbindung 268 eine Kreuzschienenverbindung, die es der Lade- /Speichereinheit 266 ermöglicht, Lade- und Speicheroperationen zwischen dem gemeinsamen Speicher 270 und der Registerdatei 258 zu implementieren. Die Registerdatei 258 kann mit der gleichen Frequenz wie die GPGPU-Kerne 262 arbeiten, so dass die Datenübertragung zwischen den GPGPU-Kernen 262 und der Registerdatei 258 eine sehr geringe Latenz aufweist. Der gemeinsame Speicher 270 kann verwendet werden, um Kommunikation zwischen Threads zu ermöglichen, die auf den Funktionseinheiten innerhalb des Grafik-Multiprozessors 234 ausgeführt werden. Der Cachespeicher 272 kann beispielsweise als Datencache verwendet werden, um Texturdaten zwischenzuspeichern, die zwischen den Funktionseinheiten und der Textureinheit 236 kommuniziert werden. Der gemeinsame Speicher 270 kann auch als programmverwalteter Cache verwendet werden. Der gemeinsame Speicher 270 und der Cachespeicher 272 können mit der Datenkreuzschiene 240 gekoppelt sein, um Kommunikation mit anderen Komponenten des Verarbeitungsclusters zu ermöglichen. Threads, die auf den GPGPU-Kernen 262 ausgeführt werden, können zusätzlich zu den automatisch zwischengespeicherten Daten, die im Cachespeicher 272 gespeichert werden, programmatisch Daten im gemeinsamen Speicher speichern.
  • 3A bis 3C veranschaulichen zusätzliche Grafik-Multiprozessoren gemäß Ausführungsformen. 3A-3B zeigen die Grafik-Multiprozessoren 325, 350, die mit dem Grafik-Multiprozessor 234 aus 2C verwandt sind und anstelle eines dieser Prozessoren verwendet werden können. Daher offenbart die Offenbarung jeglicher Merkmale in Kombination mit dem Grafik-Multiprozessor 234 vorliegend auch eine entsprechende Kombination mit dem/den Grafik-Multiprozessor(en) 325, 350, ohne jedoch hierauf eingeschränkt zu sein. 3C veranschaulicht eine Grafikverarbeitungseinheit (GPU) 380, die dedizierte Sätze von Grafikverarbeitungsressourcen aufweist, die in Mehrkerngruppen 365A bis 365N angeordnet sind, die den Grafik-Multiprozessoren 325, 350 entsprechen. Die veranschaulichten Grafik-Multiprozessoren 325, 350 und die Mehrkerngruppen 365A bis 365N können Streaming-Multiprozessoren (SM) sein, die eine große Anzahl von Ausführungs-Threads gleichzeitig ausführen können.
  • Der Grafik-Multiprozessor 325 aus 3A weist gegenüber dem Grafik-Multiprozessor 234 aus 2D mehrere zusätzliche Instanzen von Ausführungsressourceneinheiten auf. Beispielsweise kann der Grafik-Multiprozessor 325 mehrere Instanzen der Anweisungseinheit 332A bis 332B, der Registerdatei 334A bis 334B und der Textureinheit(en) 344A bis 344B aufweisen. Der Grafik-Multiprozessor 325 umfasst zudem mehrere Sätze von Grafik- oder Rechenausführungseinheiten (z.B. GPGPU-Kern 336A bis 336B, Tensorkern 337A bis 337B, Strahlverfolgungskern 338A bis 338B) und mehrere Sätze von Lade-/Speichereinheiten 340A bis 340B. Die Ausführungsressourceneinheiten verfügen über einen gemeinsamen Anweisungscache 330, Textur- und/oder Datencachespeicher 342 und einen gemeinsamen Speicher 346.
  • Die verschiedenen Komponenten können über ein Verbindungs-Fabric 327 kommunizieren. Das Verbindungs-Fabric 327 kann einen oder mehrere Kreuzschienen-Switches enthalten, um Kommunikation zwischen den verschiedenen Komponenten des Grafik-Multiprozessors 325 zu ermöglichen. Das Verbindungs-Fabric 327 kann eine separate Hochgeschwindigkeits-Netzwerkstrukturschicht sein, auf die jede Komponente des Grafik-Multiprozessors 325 aufgesetzt ist. Die Komponenten des Grafik-Multiprozessors 325 kommunizieren mit entfernten Komponenten über das Verbindungs-Fabric 327. Beispielsweise können die Kerne 336A bis 336B, 337A bis 337B und 338A bis 338B jeweils über das Verbindungs-Fabric 327 mit dem gemeinsamen Speicher 346 kommunizieren. Das Verbindungs-Fabric 327 kann Kommunikation innerhalb des Grafik-Multiprozessors 325 vermitteln, um eine faire Bandbreitenzuteilung zwischen Komponenten zu gewährleisten.
  • Der Grafik-Multiprozessor 350 aus 3B weist mehrere Sätze von Ausführungsressourcen 356A bis 356D auf, wobei jeder Satz von Ausführungsressourcen mehrere Anweisungseinheiten, Registerdateien, GPGPU-Kerne und Lade-/Speichereinheiten umfasst, wie in 2D und 3A veranschaulicht. Die Ausführungsressourcen 356A bis 356D können mit der/den Textureinheit(en) 360A bis 360D für Texturoperationen zusammenarbeiten, wobei sie sich einen Anweisungscache 354 und einen gemeinsamen Speicher 353 teilen. Beispielsweise können sich die Ausführungsressourcen 356A bis 356D einen Anweisungscache 354 und einen gemeinsamen Speicher 353 sowie mehrere Instanzen eines Textur- und/oder Datencachespeichers 358A bis 358B teilen. Die verschiedenen Komponenten können über ein Verbindungs-Fabric 352 ähnlich dem Verbindungs-Fabric 327 aus 3A kommunizieren.
  • Ein Fachmann versteht, dass die in 1, 2A bis 2D und 3A bis 3B beschriebene Architektur in Bezug auf den Umfang der vorliegenden Ausführungsformen beschreibend und nicht einschränkend ist. Somit können die vorliegend beschriebenen Methoden auf jeder ordnungsgemäß konfigurierten Verarbeitungseinheit implementiert werden, einschließlich, ohne Einschränkung, einem oder mehreren mobilen Anwendungsprozessoren, einer oder mehreren Desktop- oder Server-Zentralverarbeitungseinheiten (CPUs), einschließlich Mehrkern-CPUs, einer oder mehreren Parallelverarbeitungseinheiten, wie der Parallelverarbeitungseinheit 202 aus 2A, sowie einem oder mehreren Grafikprozessoren oder Spezialverarbeitungseinheiten, ohne vom Umfang der vorliegend beschriebenen Ausführungsformen abzuweichen.
  • Der Parallelprozessor oder die GPGPU wie vorliegend beschrieben kann kommunikativ mit Host-/Prozessorkernen gekoppelt sein, um Grafikoperationen, Operationen des maschinellen Lernens, Musteranalyseoperationen und verschiedene Allzweck-GPU- (GPGPU-) Funktionen zu beschleunigen. Die GPU kann über einen Bus oder eine andere Verbindung (z.B. eine Hochgeschwindigkeitsverbindung wie PCIe, NVLink oder andere bekannte Protokolle, standardisierte Protokolle oder proprietäre Protokolle) mit dem oder den Hostprozessoren/Kernen kommunikativ verbunden sein. In anderen Ausführungsformen kann die GPU auf demselben Package oder Chip wie die Kerne integriert und mit den Kernen über eine(n) interne(n) Prozessorbus/-verbindung (d.h. innerhalb des Packages oder Chips) kommunikativ verbunden sein. Unabhängig von der Art und Weise, in der die GPU angeschlossen ist, können die Prozessorkerne der GPU Arbeit in Form von Sequenzen aus Befehlen/Anweisungen zuteilen, die in einem Arbeitsdeskriptor enthalten sind. Die GPU verwendet dann dedizierte Schalttechnik/Logik zur effizienten Verarbeitung dieser Befehle/Anweisungen.
  • 3C veranschaulicht eine Grafikverarbeitungseinheit (GPU) 380, die dedizierte Sätze aus Grafikverarbeitungsressourcen aufweist, die in Mehrkerngruppen 365A bis 365N angeordnet sind. Zwar sind nur die Einzelheiten einer einzigen Mehrkerngruppe 365A angegeben, jedoch versteht es sich, dass die anderen Mehrkerngruppen 365B bis 365N mit den gleichen oder ähnlichen Sätzen aus Grafikverarbeitungsressourcen ausgestattet sein können. Einzelheiten, die in Bezug auf die Mehrkerngruppen 365A bis 365N beschrieben sind, können auch für jeden vorliegend beschriebenen Grafik-Multiprozessor 234, 325, 350 gelten.
  • Wie veranschaulicht, kann eine Mehrkerngruppe 365A einen Satz aus Grafikkernen 370, einen Satz aus Tensorkernen 371 und einen Satz aus Strahlverfolgungskernen 372 aufweisen. Ein Scheduler/Dispatcher 368 plant und verschickt die Grafik-Threads zur Ausführung auf den verschiedenen Kernen 370, 371, 372. Ein Satz Registerdateien 369 speichert während des Ausführens der Grafik-Threads von den Kernen 370, 371, 372 verwendete Operandenwerte. Hierzu können beispielsweise Ganzzahlenregister zum Speichern von Ganzzahlwerten, Gleitkommaregister zum Speichern von Gleitkommawerten, Vektorregister zum Speichern gepackter Datenelemente (Ganzzahl- und/oder Gleitkomma-Datenelemente) und Kachelregister zum Speichern von Tensor-/Matrixwerten zählen. Die Kachelregister können als kombinierte Sätze aus Vektorregistern implementiert werden.
  • Ein oder mehrere kombinierte Level-1 - (L1-) Caches und gemeinsam genutzte Speichereinheiten 373 speichern Grafikdaten wie Texturdaten, Vertexdaten, Pixeldaten, Strahldaten, Bounding-Volume- (Hüllkörper-) Daten usw. lokal innerhalb jeder Mehrkerngruppe 365A. Eine oder mehrere Textureinheiten 374 können zudem verwendet werden, um Texturieroperationen wie beispielsweise Texturabbildung und - abtastung (sampling) durchzuführen. Ein Level-2- (L2-) Cache 375, der von allen oder einem Teilsatz der Mehrkerngruppen 365A bis 365N verwendet wird, speichert Grafikdaten und/oder Anweisungen für mehrere gleichzeitige Grafik-Threads. Wie veranschaulicht, kann der L2-Cache 375 von einer Vielzahl von Mehrkerngruppen 365A bis 365N gemeinsam verwendet werden. Ein oder mehrere Speichercontroller 367 koppeln die GPU 380 an einen Speicher 366, bei dem es sich um einen Systemspeicher (z.B. DRAM) und/oder einen dedizierten Grafikspeicher (z.B. GDDR6-Speicher) handeln kann.
  • Eingabe/Ausgabe- (E/A-) Schalttechnik 363 koppelt die GPU 380 an eine oder mehrere E/A-Einrichtungen 362 wie beispielsweise digitale Signalprozessoren (DSPs), Netzwerkcontroller oder Nutzereingabeeinrichtungen. Eine On-Chip-Verbindung kann verwendet werden, um die E/A-Einrichtungen 362 an die GPU 380 und den Speicher 366 zu koppeln. Eine oder mehrere E/A-Speicherverwaltungseinheiten (I/O Memory Management Units, IOMMUs) 364 der E/A-Schalttechnik 363 koppeln die E/A-Einrichtungen 362 direkt an den Systemspeicher 366. Wahlweise verwaltet die IOMMU 364 mehrere Sätze von Seitentabellen, um virtuelle Adressen auf physische Adressen im Systemspeicher 366 abzubilden. Die E/A-Einrichtunen 362, CPU(s) 361 und GPU(s) 380 können sich dann denselben virtuellen Adressraum 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 des ersten und zweiten Satzes von Seitentabellen können jeweils in Steuerregistern gespeichert und bei einem Kontextwechsel ausgelagert werden (z.B. damit der neue Kontext Zugriff auf den entsprechenden Satz von Seitentabellen erhält). Auch wenn dies in 3C nicht veranschaulicht ist, kann jeder der Kerne 370, 371, 372 und/oder der Mehrkerngruppen 365A bis 365N Übersetzungs-Lookaside-Puffer (TLBs) aufweisen, um virtueller-Gast-zu-physischer-Gast-Übersetzungen, physischer-Gast-zu-physischer-Host-Übersetzungen und virtueller-Gast-zu-physischer-Host-Übersetzungen zwischenzuspeichern.
  • Die CPUs 361, GPUs 380 und E/A-Einrichtungen 362 können auf einem einzigen Halbleiterchip und/oder Chip-Package integriert sein. Der veranschaulichte Speicher 366 kann auf dem gleichen Chip integriert sein oder kann über eine Off-Chip-Schnittstelle an die Speichercontroller 367 gekoppelt sein. In einer Implementierung umfasst der Speicher 366 GDDR6-Speicher, der sich denselben virtuellen Adressraum wie andere physische Speicher auf Systemebene teilt, obwohl die vorliegend beschriebenen zugrunde liegenden Prinzipien nicht auf diese konkrete Implementierung eingeschränkt sind.
  • Die Tensorkerne 371 können eine Vielzahl von Ausführungseinheiten aufweisen, die speziell für die Durchführung von Matrixoperationen ausgelegt sind, welche die grundlegende Rechenoperation zur Durchführung von Deep-Learning-Operationen sind. Beispielsweise können gleichzeitige Matrixmultiplikationsoperationen für das Training neuronaler Netze und für Inferenzfindung verwendet werden. Die Tensorkerne 371 können die Matrixverarbeitung unter Verwendung einer Vielzahl von Operandenpräzisionen durchführen, einschließlich Gleitkomma mit einfacher Präzision (z.B. 32 Bit), Gleitkomma mit halber Präzision (z.B. 16 Bit), Ganzzahlwörter (16 Bit), Bytes (8 Bit) und Halbbytes (4 Bit). Beispielsweise extrahiert eine neuronale Netzimplementierung Merkmale jeder gerenderten Szene, wobei möglicherweise Details aus mehreren Frames kombiniert werden, um ein qualitativ hochwertiges Endbild zu konstruieren.
  • In Deep-Learning-Implementierungen kann parallele Matrixmultiplikationsarbeit für die Ausführung auf den Tensorkernen 371 geplant werden. Insbesondere das Training neuronaler Netze erfordert eine beträchtliche Anzahl an Matrix-Punktproduktoperationen. Um eine Innenprodukt-Formulierung einer N × N × N-Matrixmultiplikation zu verarbeiten, können die Tensorkerne 371 mindestens N Punktprodukt-Verarbeitungselemente aufweisen. Bevor die Matrixmultiplikation beginnt, wird eine vollständige Matrix in Kachelregister geladen und mindestens eine Spalte einer zweiten Matrix jeden Zyklus für N Zyklen geladen. Jeden Zyklus werden N Punktprodukte verarbeitet.
  • Je nach der jeweiligen Implementierung werden Matrixelemente mit verschiedenen Präzisionen gespeichert, darunter 16-Bit-Wörter, 8-Bit-Bytes (z.B. INT8) und 4-Bit-Halbbytes (z.B. INT4). Für die Tensorkerne 371 können unterschiedliche Präzisionsmodi festgelegt werden, um sicherzustellen, dass für unterschiedliche Arbeitslasten die effizienteste Präzision verwendet wird (wie beispielsweise Inferenzfindungsarbeitslasten, die eine Quantisierung in Bytes und Halbbytes tolerieren können). Unterstützt werden außerdem 64-Bit-Gleitkommaformate (FP64) und Nicht-IEEE-Gleitkommaformate wie das bfloat16-Format (z.B. Brain-Gleitkomma), ein 16-Bit-Gleitkommaformat mit einem Vorzeichenbit, acht Exponentenbits und acht Mantissenbits, von denen sieben explizit gespeichert werden. Eine Ausführungsform umfasst Unterstützung für ein Tensor-Float-Format mit reduzierter Präzision (TF32), das die Spanne von FP32 (8-Bits) mit der Präzision von FP16 (10-Bits) besitzt. TF32-Operationen mit reduzierter Präzision können an FP32-Eingaben ausgeführt werden und erzeugen FP32-Ausgaben bei höherer Leistung im Vergleich zu FP32 und erhöhter Präzision im Vergleich zu FP16.
  • In einer Ausführungsform unterstützen die Tensorkerne 371 einen Sparse-Betriebsmodus für Matrizen, in denen die überwiegende Mehrheit der Werte Null ist. Die Tensorkerne 371 unterstützen spärliche Eingabematrizen, die in einer Sparse-Matrix-Darstellung codiert sind (z.B. Koordinatenlistencodierung (COO), Compressed Sparse Row (CSR), Compress Sparse Column (CSC) usw.). Die Tensorkerne 371 umfassen zudem Unterstützung für komprimierte Sparse-Matrix-Darstellungen für den Fall, dass die Sparse-Matrix-Darstellung möglicherweise weiter komprimiert wird. Komprimierte, codierte und/oder komprimierte und codierte Matrixdaten können zusammen mit zugehörigen Komprimierungs- und/oder Codierungsmetadaten von den Tensorkernen 371 bereitgestellt und die Nicht-Nullwerte extrahiert werden. Beispielsweise kann für eine gegebene Eingabematrix A ein Nicht-Nullwert aus der komprimierten und/oder codierten Darstellung zumindest eines Teils der Matrix A geladen werden. Auf Grundlage der Position in der Matrix A für den Nicht-Null-Wert, die aus Index- oder Koordinatenmetadaten bestimmt werden kann, die mit dem Nicht-Nullwert verbunden sind, kann ein entsprechender Wert in der Eingabematrix B geladen werden. Abhängig von der durchzuführenden Operation (z.B. Multiplizieren) kann das Laden des Wertes aus der Eingabematrix B übersprungen werden, wenn der entsprechende Wert ein Nullwert ist. In einer Ausführungsform können die Wertepaare für bestimmte Operationen, wie beispielsweise Multiplikationsoperationen, von der Scheduler-Logik vorab gescannt werden, und es werden nur Operationen zwischen Eingaben geplant, die nicht Null sind. Abhängig von den Dimensionen der Matrix A und der Matrix B und der auszuführenden Operation kann die Ausgabematrix C dicht oder spärlich sein. Wenn die Ausgabematrix C spärlich ist, kann die Ausgabematrix C je nach Konfiguration der Tensorkerne 371 in einem komprimierten Format, einer spärlichen Codierung oder einer komprimierten spärlichen 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 Schalttechnik für Strahldurchquerung/-schneidung unter Verwendung von Hüllkörperhierarchien (Bounding Volume Hierarchies, BVHs) und die Identifizierung von Schneidungen zwischen Strahlen und Primitiven aufweisen, die in den BVH-Volumina enthalten sind. Die Strahlverfolgungskerne 372 können zudem Schalttechnik zum Durchführen von Tiefenprüfung und Sortierung (z.B mittels einer Z-Puffer- oder einer ähnlichen Anordnung) aufweisen. In einer Implementierung können die Strahlverfolgungskerne 372 Durchquerungs- und Schneidungsoperationen zusammen mit den vorliegend beschriebenen Bildrauschminderungsmethoden durchführen, von denen zumindest ein Teil auf den Tensorkernen 371 ausgeführt werden kann. Beispielsweise können die Tensorkerne 371 ein neuronales Deep-Learning-Netz implementieren, um Rauschminderung an durch die Strahlverfolgungskerne 372 erzeugten Frames durchzuführen. Jedoch können auch die CPU(s) 361, Grafikkerne 370 und/oder Strahlverfolgungskerne 372 die Rauschminderungs- und/oder Deep-Learning-Algorithmen ganz oder teilweise implementieren.
  • Zudem kann, wie vorstehend beschrieben, ein verteilter Ansatz für die Rauschminderung eingesetzt werden, bei dem sich die GPU 380 in einer Datenverarbeitungseinrichtung befindet, die über eine Netzwerk- oder Hochgeschwindigkeitsverbindung an andere Datenverarbeitungseinrichtungen gekoppelt ist. Bei diesem verteilten Ansatz können die untereinander verbundenen Datenverarbeitungseinrichtungen Lern-/Trainingsdaten des neuronalen Netzes gemeinsam verwenden, um die Geschwindigkeit zu verbessern, mit der das Gesamtsystem lernt, Rauschminderung für verschiedene Arten von Bildrahmen und/oder verschiedene Grafikanwendungen durchzuführen.
  • Die Strahlverfolgungskerne 372 können alle BVH-Durchquerungen und Strahl-Primitiv-Schneidungen verarbeiten, so dass die Grafikkerne 370 nicht mit tausenden von Anweisungen pro Strahl überlastet werden. Beispielsweise weist jeder Strahlverfolgungskern 372 einen ersten Satz spezialisierter Schalttechnik zur Durchführung von Hüllquaderprüfungen (Bounding Box Tests) (z.B. für Durchquerungsoperationen) und/oder einen zweiten Satz spezialisierter Schalttechnik zur Durchführung der Strahl-Dreieck-Schneidungsprüfungen (z.B. schneidende Strahlen, die durchquert wurden) auf. Somit kann beispielsweise die Mehrkerngruppe 365A einfach eine Strahlsonde aussenden, und die Strahlverfolgungskerne 372 führen unabhängig Strahldurchquerung und -schneidung durch und liefern Trefferdaten (z.B. Treffer, kein Treffer, mehrere Treffer usw.) an den Thread-Kontext zurück. Die anderen Kerne 370, 371 sind frei, um andere Grafik- oder Rechenarbeit durchzuführen, während die Strahlverfolgungskerne 372 die Durchquerungs- und Schneidungsoperationen durchführen.
  • Wahlweise kann jeder Strahlverfolgungskern 372 eine Durchquerungseinheit zum Durchführen von BVH-Prüfoperationen und eine Schneidungseinheit aufweisen, die Strahl-Primitiv-Schneidungsprüfungen durchführt. Die Schneidungseinheit erzeugt eine „Treffer“-, „kein Treffer“- oder „mehrere Treffer“-Antwort, die sie dem geeigneten Thread bereitstellt. Während der Durchquerungs- und Schneidungsoperationen sind die Ausführungsressourcen der anderen Kerne (z.B. Grafikkerne 370 und Tensorkerne 371) frei, um andere Formen von Grafikarbeit auszuführen.
  • In einer optionalen, nachstehend beschriebenen Ausführungsform wird ein hybrider Rasterung/Strahlverfolgung-Ansatz verwendet, bei dem Arbeit zwischen den Grafikkernen 370 und Strahlverfolgungskernen 372 aufgeteilt wird.
  • Die Strahlverfolgungskerne 372 (und/oder andere Kerne 370, 371) können Hardwareunterstützung für einen Strahlverfolgungs-Befehlssatz wie DirectX Ray Tracing (DXR) von Microsoft aufweisen, der einen DispatchRays-Befehl sowie Strahlerzeugung, Closest-Hit-, Any-Hit- und Miss-Shader enthält, die die Zuweisung eindeutiger Sätze von Shadern und Texturen für jedes Objekt ermöglichen. Eine weitere Strahlverfolgungsplattform, die von den Strahlverfolgungskernen 372, Grafikkernen 370 und Tensorkernen 371 unterstützt werden kann, ist Vulkan 1.1.85. Es ist jedoch zu beachten, dass die vorliegend beschriebenen zugrunde liegenden Prinzipien auf keine bestimmte Strahlverfolgungs-ISA eingeschränkt sind.
  • Im Allgemeinen können die verschiedenen Kerne 372, 371, 370 einen Strahlverfolgungsbefehlssatz unterstützen, der Befehle/Funktionen für Strahlerzeugung, Closest Hit, Any Hit, Strahl-Primitiv-Schneidung, pro Primitiv und hierarchisch erfolgende Konstruktion von Hüllquadern, Miss, Visit und/oder Ausnahmen umfasst. Konkret umfasst eine bevorzugte Ausführungsform Strahlverfolgungsanweisungen zum Durchführen einer oder mehrerer der folgenden Funktionen:
    • Strahlerzeugung - Strahlerzeugungsanweisungen können für jedes Pixel, jede Abtastung oder einen anderen nutzerdefinierten Arbeitsauftrag ausgeführt werden.
    • Closest Hit - Eine Closest-Hit-Anweisung kann ausgeführt werden, um den nächstliegenden Schnittpunkt eines Strahls mit Primitiven in einer Szene zu lokalisieren.
    • Any Hit - Eine Any-Hit-Anweisung identifiziert mehrere Schneidungen zwischen einem Strahl und Primitiven in einer Szene, potenziell zur Identifizierung eines neuen nächstliegenden Schnittpunkts.
    • Intersection - Eine Intersection-Anweisung führt eine Strahl-Primitiv-Schneidungsprüfung durch und gibt ein Ergebnis aus.
    • Pro Primitiv erfolgende Hüllquaderkonstruktion - Diese Anweisung erstellt einen Hüllquader um ein gegebenes Primitiv oder Gruppe von Primitiven (z.B. beim Erstellen einer neuen BVH- oder anderen Beschleunigungsdatenstruktur).
    • Miss - Zeigt an, dass ein Strahl die gesamte Geometrie innerhalb einer Szene oder eine festgelegte Region einer Szene verfehlt.
    • Visit - Zeigt an, welche Nachfolgevolumina ein Strahl durchqueren wird.
    • Ausnahmen - Umfasst mehrere Typen von Ausnahmebehandlungsroutinen (z.B. für verschiedene Fehlerbedingungen aufgerufen).
  • In einer Ausführungsform können die Strahlverfolgungskerne 372 so angepasst sein, dass sie Allzweck-Rechenoperationen beschleunigen, die mit Rechenmethoden beschleunigt werden können, die analog zu den Strahlschneidungsprüfungen sind. Es kann ein Rechen-Framework bereitgestellt werden, das es ermöglicht, Schattierprogramme in Anweisungen einer niedrigeren Ebene und/oder Primitive zu kompilieren, die Allzweck-Rechenoperationen über die Strahlverfolgungskerne durchführen. Zu beispielhaften Berechnungsproblemen, die von den auf den Strahlverfolgungskernen 372 ausgeführten Rechenoperationen profitieren können, gehören Berechnungen, die die Ausbreitung von Strahlen, Wellen oder Teilchen in einem Koordinatenraum betreffen. Mit dieser Ausbreitung verbundene Wechselwirkungen können relativ zu einer Geometrie oder einem Netz im Koordinatenraum berechnet werden. Beispielsweise können Berechnungen im Zusammenhang mit der Ausbreitung elektromagnetischer Signale durch eine Umgebung durch die Verwendung von Anweisungen oder Primitiven beschleunigt werden, die über die Strahlverfolgungskerne ausgeführt werden. Beugung und Reflexion der Signale an Objekten in der Umgebung können als direkte Strahlverfolgungsanalogien berechnet werden.
  • Die Strahlverfolgungskerne 372 können auch zur Durchführung von Berechnungen verwendet werden, die nicht direkt analog zur Strahlverfolgung sind. So können z. B. Netzprojektion, Netzverfeinerung und Volume-Sampling-Berechnungen mit Hilfe der Strahlverfolgungskerne 372 beschleunigt werden. Allgemeine Koordinatenraumberechnungen, wie beispielsweise Nearest-Neighbor- (Nächstgelegener-Nachbar-) Berechnungen, können ebenfalls durchgeführt werden. Beispielsweise kann die Menge der Punkte in der Nähe eines bestimmten Punktes ermittelt werden, indem ein Hüllquader im Koordinatenraum um den Punkt definiert wird. BVH- und Strahlsondenlogik innerhalb der Strahlverfolgungskerne 372 kann dann verwendet werden, um die Menge der Punktschneidungen innerhalb des Hüllquaders zu bestimmen. Die Schneidungen bilden den Ursprungspunkt und die nächstgelegenen Nachbarn zu diesem Ursprungspunkt. Berechnungen, die mit den Strahlverfolgungskernen 372 durchgeführt werden, können parallel zu Berechnungen auf den Grafikkernen 372 und Tensorkernen 371 durchgeführt werden. Ein Shader-Compiler kann so konfiguriert werden, dass er einen Rechen-Shader oder ein anderes Allzweck-Grafikverarbeitungsprogramm in Primitive einer niedrigeren Ebene kompiliert, die über die Grafikkerne 370, die Tensorkerne 371 und die Strahlverfolgungskerne 372 parallelisiert werden können.
  • Methoden der Verbindung zwischen GPU und Hostprozessor
  • 4A veranschaulicht eine beispielhafte Architektur, in der eine Vielzahl von GPUs 410-413, wie beispielsweise die in 2A gezeigten Parallelprozessoren 200, kommunikativ mit einer Vielzahl von Mehrkernprozessoren 405-406 über Hochgeschwindigkeitsverbindungen 440A-440D (z.B. Busse, Punkt-zu-Punkt-Verbindungen usw.) gekoppelt sind. Die Hochgeschwindigkeitsverbindungen 440A bis 440D können je nach Implementierung einen Kommunikationsdurchsatz von 4GB/s, 30GB/s, 80GB/s oder höher unterstützen. Es können verschiedene Verbindungsprotokolle verwendet werden, darunter, ohne jedoch hierauf eingeschränkt zu sein, PCIe 4.0 oder 5.0 und NVLink 2.0. Die vorliegend beschriebenen zugrunde liegenden Prinzipien sind jedoch auf kein bestimmtes Kommunikationsprotokoll und keinen bestimmten Durchsatz eingeschränkt.
  • Zwei oder mehr der GPUs 410 bis 413 können über Hochgeschwindigkeitsverbindungen 442A bis 442B untereinander verbunden sein, die mit denselben oder anderen Protokollen/Verbindungen implementiert werden können als die für die Hochgeschwindigkeitsverbindungen 440A bis 440D verwendeten. In ähnlicher Weise können zwei oder mehr der Mehrkernprozessoren 405 bis 406 über eine Hochgeschwindigkeitsverbindung 443 verbunden sein, bei der es sich um Busse für symmetrische Multiprozessoren (SMP) handeln kann, die mit 20GB/s, 30GB/s, 120GB/s oder niedrigeren oder höheren Geschwindigkeiten arbeiten. Alternativ kann die gesamte Kommunikation zwischen den verschiedenen in 4A gezeigten Systemkomponenten über die gleichen Protokolle/Verbindungen erfolgen (z.B. über ein gemeinsames Verbindungs-Fabric). Wie erwähnt, sind jedoch die vorliegend beschriebenen zugrunde liegenden Prinzipien nicht auf eine bestimmte Art von Verbindungstechnologie eingeschränkt.
  • Jeder Mehrkernprozessor 405 bis 406 kann kommunikativ mit einem Prozessorspeicher 401 bis 402 über Speicherverbindungen 430A bis 430B verbunden sein, und jede GPU 410-413 ist kommunikativ mit dem GPU-Speicher 420 bis 423 über GPU-Speicherverbindungen 450A bis 450D verbunden. Die Speicherverbindungen 430A bis 430B und 450A bis 450D können die gleichen oder unterschiedliche Speicherzugriffstechnologien verwenden. Die Prozessorspeicher 401 bis 402 und die GPU-Speicher 420 bis 423 können beispielsweise flüchtige Speicher wie dynamische Direktzugriffsspeicher (DRAMs) (einschließlich gestapelter DRAMs), Grafik-DDR-SDRAM (GDDR) (z.B. GDDR5, GDDR6) oder Speicher mit hoher Bandbreite (High Bandwidth Memory, HBM) sein und/oder können nichtflüchtige Speicher wie 3D XPoint/Optane oder Nano-Ram sein. Zum Beispiel kann ein Teil der Speicher flüchtig und ein anderer Teil nichtflüchtig sein (z.B. unter Verwendung einer zweistufigen Speicherhierarchie (Two-Level Memory, 2LM)). Ein Speicherteilsystem wie vorliegend beschrieben kann mit einer Reihe von Speichertechnologien kompatibel sein, beispielsweise mit Double-Data-Rate-Versionen, die von JEDEC (Joint Electronic Device Engineering Council) herausgegeben wurden.
  • Wie nachstehend beschrieben, können die verschiedenen Prozessoren 405 bis 406 und GPUs 410 bis 413 zwar physisch mit einem bestimmten Speicher 401 bis 402 bzw. 420 bis 423 verbunden sein, es kann jedoch eine vereinheitlichte Speicherarchitektur implementiert werden, bei der derselbe virtuelle Systemadressraum (auch als „effektiver Adressraum“ bezeichnet) auf alle verschiedenen physischen Speicher verteilt ist. Beispielsweise können die Prozessorspeicher 401 bis 402 jeweils 64 GB des Adressraums des Systemspeichers und die GPU-Speicher 420 bis 423 jeweils 32 GB des Adressraums des Systemspeichers umfassen (was in diesem Beispiel zu einem adressierbaren Gesamtspeicher von 256 GB führt).
  • 4B zeigt zusätzliche optionale Einzelheiten für eine Verbindung zwischen einem Mehrkernprozessor 407 und einem Grafikbeschleunigungsmodul 446. Das Grafikbeschleunigungsmodul 446 kann einen oder mehrere GPU-Chips enthalten, die auf einer Linecard integriert sind, die über die Hochgeschwindigkeitsverbindung 440 mit dem Prozessor 407 gekoppelt ist. Alternativ kann das Grafikbeschleunigungsmodul 446 auch auf demselben Package oder Chip wie der Prozessor 407 integriert sein.
  • Der dargestellte Prozessor 407 weist eine Vielzahl von Kernen 460A bis 460D auf, jeder mit einem Übersetzungs-Lookaside-Puffer 461A bis 461D und einem oder mehreren Caches 462A bis 462D. Die Kerne können verschiedene andere Komponenten für die Ausführung von Anweisungen und die Verarbeitung von Daten aufweisen, die nicht abgebildet sind, um nicht von den zugrunde liegenden Prinzipien der vorliegend beschriebenen Komponenten abzulenken (z.B. Anweisungsabrufeinheiten, Verzweigungsvorhersageeinheiten, Decoder, Ausführungseinheiten, Reorder-Puffer usw.). Die Caches 462A bis 462D können Level-1- (L1-) und Level-2- (L2-) Caches umfassen. Zusätzlich können ein oder mehrere gemeinsam genutzte Caches 456 in der Caching-Hierarchie enthalten sein und von Sätzen der Kerne 460A bis 460D gemeinsam genutzt werden. Eine Ausführungsform des Prozessors 407 umfasst beispielsweise 24 Kerne, jeder mit einem eigenen LI-Cache, zwölf gemeinsam genutzte L2-Caches und zwölf gemeinsam genutzte L3-Caches. In dieser Ausführungsform wird einer der L2- und L3-Caches von zwei benachbarten Kernen gemeinsam genutzt. Der Prozessor 407 und das Grafikbeschleuniger-Integrationsmodul 446 sind mit dem Systemspeicher 441 verbunden, der die Prozessorspeicher 401 bis 402 aufweisen kann.
  • Die Kohärenz wird für Daten und Anweisungen, die in den verschiedenen Caches 462A bis 462D, 456 und im Systemspeicher 441 gespeichert sind, über eine Inter-Kern-Kommunikation über einen Kohärenzbus 464 aufrechterhalten. Beispielsweise kann jeder Cache über eine Cache-Kohärenzlogik/-schalttechnik verfügen, die mit ihm verbunden ist, um über den Kohärenzbus 464 als Reaktion auf erkannte Lese- oder Schreibvorgänge auf bestimmte Cachezeilen zu kommunizieren. In einer Implementierung wird ein Cache-Snooping-Protokoll über den Kohärenzbus 464 implementiert, um Cachezugriffe zu erfassen. Cache-Snooping-/Kohärenz-Techniken sind dem Fachmann wohlbekannt und werden hier nicht im Einzelnen beschrieben, um nicht von den vorliegend beschriebenen zugrunde liegenden Prinzipien abzulenken.
  • Es kann eine Proxy-Schaltung 425 vorgesehen werden, die das Grafikbeschleunigungsmodul 446 kommunikativ mit dem Kohärenzbus 464 koppelt, so dass das Grafikbeschleunigungsmodul 446 als Peer der Kerne am Cache-Kohärenzprotokoll teilnehmen kann. Insbesondere bietet eine Schnittstelle 435 Konnektivität zur Proxy-Schaltung 425 über die Hochgeschwindigkeitsverbindung 440 (z.B. ein PCIe-Bus, NVLink usw.), und eine Schnittstelle 437 verbindet das Grafikbeschleunigungsmodul 446 mit der Hochgeschwindigkeitsverbindung 440.
  • In einer Implementierung bietet eine Beschleunigerintegrationsschaltung 436 Cacheverwaltung, Speicherzugriff, Kontextverwaltung und Interrupt-Verwaltungsdienste im Auftrag einer Vielzahl von Grafikverarbeitungs-Engines 431, 432, N des Grafikbeschleunigungsmoduls 446. Die Grafikverarbeitungs-Engines 431, 432, N können jeweils eine separate Grafikverarbeitungseinheit (GPU) umfassen. Alternativ können die Grafikverarbeitungs-Engines 431, 432, N verschiedene Arten von Grafikverarbeitungs-Engines innerhalb einer GPU umfassen, beispielsweise Grafikausführungseinheiten, Medienverarbeitungs-Engines (z.B. Videocodierer/-decodierer), Sampler und Blit-Engines. Mit anderen Worten, das Grafikbeschleunigungsmodul kann eine GPU mit einer Vielzahl von Grafikverarbeitungs-Engines 431 bis 432, N sein oder die Grafikverarbeitungs-Engines 431 bis 432, N können einzelne GPU sein, die auf einem gemeinsamen Package, einer Linecard oder einem Chip integriert sind.
  • Die Beschleuniger-Integrationsschaltung 436 kann eine Speicherverwaltungseinheit (Memory Management Unit, MMU) 439 zur Durchführung verschiedener Speicherverwaltungsfunktionen wie beispielsweise Übersetzungen von virtuellem in physischen Speicher (auch als Übersetzungen von effektivem in realen Speicher bezeichnet) und Speicherzugriffsprotokolle für den Zugriff auf den Systemspeicher 441 aufweisen. Die MMU 439 kann zudem einen Übersetzungs-Lookaside-Buffer (TLB) (nicht gezeigt) für die Zwischenspeicherung der Übersetzungen von virtuellen/effektiven in physische/reale Adressen aufweisen. In einer Implementierung speichert ein Cache 438 Befehle und Daten für den effizienten Zugriff durch die Grafikverarbeitungs-Engines 431, 432, N. Die im Cache 438 und in den Grafikspeichern 433 bis 434, M gespeicherten Daten können mit den Kerncaches 462A bis 462D, 456 und dem Systemspeicher 441 kohärent gehalten werden. Wie bereits erwähnt, kann dies über die Proxy-Schaltung 425 erfolgen, die für den Cache 438 und die Speicher 433 bis 434, M am Cache-Kohärenzmechanismus teilnimmt (z.B. Senden von Aktualisierungen an den Cache 438 in Bezug auf Änderungen/Zugriffe auf Cachezeilen in den Prozessorcaches 462A bis 462D, 456 und Empfangen von Aktualisierungen vom Cache 438).
  • Ein Satz von Registern 445 speichert Kontextdaten für Threads, die von den Grafikverarbeitungs-Engines 431 bis 432, N ausgeführt werden, und eine Kontextverwaltungsschaltung 448 verwaltet die Thread-Kontexte. Beispielsweise kann die Kontextverwaltungsschaltung 448 Speicher- und Wiederherstellungsoperationen durchführen, um Kontexte der verschiedenen Threads während Kontextumschaltungen zu speichern und wiederherzustellen (z.B. wenn ein erster Thread gespeichert und ein zweiter Thread wiederhergestellt wird, damit der zweite Thread von einer Grafikverarbeitungs-Engine ausgeführt werden kann). Zum Beispiel kann die Kontextverwaltungsschaltung 448 bei einem Kontextwechsel aktuelle Registerwerte in einem dafür vorgesehenen Bereich im Speicher speichern (z.B. identifiziert durch einen Kontextzeiger). Sie kann dann bei der Rückkehr zum Kontext die Registerwerte wiederherstellen. Eine Interrupt-Verwaltungsschaltung 447 kann beispielsweise von Systemeinrichtungen empfangene Interrupts empfangen und verarbeiten.
  • In einer Implementierung werden virtuelle/effektive Adressen aus einer Grafikverarbeitungs-Engine 431 durch die MMU 439 in reale/physische Adressen im Systemspeicher 441 übersetzt. Wahlweise unterstützt die Beschleunigerintegrationsschaltung 436 mehrere (z.B. 4, 8, 16) Grafikbeschleunigermodule 446 und/oder andere Beschleunigereinrichtungen. Das Grafikbeschleunigermodul 446 kann für eine einzelne Anwendung bestimmt sein, die auf dem Prozessor 407 ausgeführt wird, oder es kann von mehreren Anwendungen gemeinsam genutzt werden. Wahlweise wird eine virtualisierte Grafikausführungsumgebung bereitgestellt, in der die Ressourcen der Grafikverarbeitungs-Engines 431-432, N mit mehreren Anwendungen, virtuellen Maschinen (VMs) oder Containern gemeinsam genutzt werden. Die Ressourcen können in „Bausteine“ (slices) unterteilt werden, die auf Grundlage der mit den VMs und/oder Anwendungen verbundenen Verarbeitungsanforderungen und Prioritäten verschiedenen VMs und/oder Anwendungen zugeteilt werden. VMs und Container können vorliegend austauschbar verwendet werden.
  • Eine virtuelle Maschine (VM) kann eine Software sein, die ein Betriebssystem und eine oder mehrere Anwendungen ausführt. Eine VM kann durch eine Spezifikation, Konfigurationsdateien, eine virtuelle Festplattendatei, eine Einstellungsdatei für nichtflüchtigen Direktzugriffsspeicher (NVRAM) und die Protokolldatei definiert werden und wird durch die physischen Ressourcen einer Host-Datenverarbeitungsplattform unterstützt. Eine VM kann ein Betriebssystem (OS) oder eine Anwendungsumgebung aufweisen, die auf einer Software installiert ist, die eine dedizierte Hardware imitiert. Der Endanwender hat auf einer virtuellen Maschine das gleiche Bedienerlebnis wie auf einer dedizierten Hardware. Eine spezielle Software, Hypervisor genannt, emuliert die CPU, den Arbeitsspeicher, die Festplatte, das Netzwerk und andere Hardwareressourcen des PC-Clients oder Servers vollständig, so dass virtuelle Maschinen die Ressourcen gemeinsam nutzen können. Der Hypervisor kann mehrere virtuelle Hardwareplattformen emulieren, die voneinander isoliert sind, sodass virtuelle Maschinen Linux®, Windows® Server, VMware ESXi und andere Betriebssysteme auf demselben zugrunde liegenden physischen Host ausführen können.
  • Ein Container kann ein Softwarepaket aus Anwendungen, Konfigurationen und Abhängigkeiten sein, so dass die Anwendungen zuverlässig auf verschiedenen Datenverarbeitungsumgebungen laufen. Container können sich ein auf der Serverplattform installiertes Betriebssystem teilen und als isolierte Prozesse laufen. Ein Container kann ein Softwarepaket sein, das alles enthält, was die Software zum Ausführen benötigt, beispielsweise Systemwerkzeuge, Bibliotheken und Einstellungen. Container werden nicht wie herkömmliche Softwareprogramme installiert, wodurch sie von der anderen Software und dem Betriebssystem selbst isoliert werden können. Die Möglichkeit der Isolierung von Containern bietet mehrere Vorteile. Erstens wird die Software in einem Container in verschiedenen Umgebungen gleich ausgeführt. So kann beispielsweise ein Container, der PHP und MySQL enthält, sowohl auf einem Linux®-Rechner als auch auf einem Windows®-Rechner identisch laufen. Zweitens bieten Container zusätzliche Sicherheit, da die Software das Host-Betriebssystem nicht beeinträchtigt. Während eine installierte Anwendung Systemeinstellungen ändern und Ressourcen wie beispielsweise die Registrierung in Windows modifizieren kann, kann ein Container nur Einstellungen innerhalb des Containers ändern.
  • Somit fungiert die Beschleunigerintegrationsschaltung 436 als Brücke zum System für das Grafikbeschleunigungsmodul 446 und bietet Adressübersetzung und Systemspeicher-Cachedienste. In einer Ausführungsform kann die Beschleunigerintegrationsschaltung 436 zur Erleichterung der Überbrückungsfunktionalität auch gemeinsam genutzte E/A 497 (z.B. PCIe, USB oder andere) und Hardware aufweisen, um die Systemsteuerung von Spannung, Taktung, Leistung, Temperatur und Sicherheit zu ermöglichen. Die gemeinsam genutzte E/A 497 kann separate physische Verbindungen nutzen oder die Hochgeschwindigkeitsverbindung 440 durchlaufen. Darüber hinaus kann die Beschleunigerintegrationsschaltung 436 Virtualisierungseinrichtungen für den Hostprozessor bereitstellen, um die Virtualisierung der Grafikverarbeitungs-Engines, Interrupts und der Speicherverwaltung zu verwalten.
  • Da die Hardwareressourcen der Grafikverarbeitungs-Engines 431 bis 432, N explizit auf den realen Adressraum abgebildet werden, den der Hostprozessor 407 sieht, kann jeder Hostprozessor diese Ressourcen direkt über einen effektiven Adresswert adressieren. Eine optionale Funktion der Beschleunigerintegrationsschaltung 436 ist die physische Trennung der Grafikverarbeitungs-Engines 431 bis 432, N, so dass sie dem System als unabhängige Einheiten erscheinen.
  • Ein oder mehrere Grafikspeicher 433-434, M können jeweils mit jeder der Grafikverarbeitungs-Engines 431 bis 432, N gekoppelt sein. Die Grafikspeicher 433 bis 434, M speichern Anweisungen und Daten, die von jeder der Grafikverarbeitungs-Engines 431 bis 432, N verarbeitet werden. Bei den Grafikspeichern 433 bis 434, M kann es sich um flüchtige Speicher wie DRAMs (einschließlich gestapelter DRAMs), GDDR-Speicher (z.B. GDDR5, GDDR6) oder HBM und/oder um nichtflüchtige Speicher wie 3D XPoint/Optane, Samsung Z-NAND oder Nano-Ram handeln.
  • Um den Datenverkehr über die Hochgeschwindigkeitsverbindung 440 zu reduzieren, können Biasing-Methoden verwendet werden, um sicherzustellen, dass die in den Grafikspeichern 433 bis 434, M gespeicherten Daten die Daten sind, die am häufigsten von den Grafikverarbeitungs-Engines 431 bis 432, N verwendet werden und vorzugsweise nicht von den Kernen 460A bis 460D (zumindest nicht häufig) verwendet werden. In ähnlicher Weise versucht der Biasing-Mechanismus, Daten, die von den Kernen (und vorzugsweise nicht von den Grafikverarbeitungs-Engines 431 bis 432, N) benötigt werden, in den Caches 462A bis 462D, 456 der Kerne und im Systemspeicher 441 zu halten.
  • Gemäß einer in 4C dargestellten Variante ist die Beschleunigerintegrationsschaltung 436 in den Prozessor 407 integriert. Die Grafikverarbeitungs-Engines 431 bis 432, N kommunizieren direkt über die Hochgeschwindigkeitsverbindung 440 mit der Beschleunigerintegrationsschaltung 436 über die Schnittstelle 437 und die Schnittstelle 435 (die wiederum jede Form von Bus- oder Schnittstellenprotokoll verwenden können). Die Beschleunigerintegrationsschaltung 436 kann die gleichen Operationen durchführen, wie sie in 4B beschrieben sind, jedoch möglicherweise mit einem höheren Durchsatz, da sie sich in unmittelbarer Nähe zum Kohärenzbus 464 und den Caches 462A bis 462D, 456 befindet.
  • Die beschriebenen Ausführungsformen können verschiedene Programmiermodelle unterstützen, darunter ein Programmiermodell mit dedizierten Prozessen (ohne Virtualisierung des Grafikbeschleunigungsmoduls) und gemeinsam genutzte Programmiermodelle (mit Virtualisierung). Letztere können Programmiermodelle, die von der Beschleunigerintegrationsschaltung 436 gesteuert werden, und Programmiermodelle umfassen, die vom Grafikbeschleunigungsmodul 446 gesteuert werden.
  • In den Ausführungsformen des dedizierten Prozessmodells können die Grafikverarbeitungs-Engines 431, 432, ... N einer einzelnen Anwendung oder einem einzelnen Prozess unter einem einzelnen Betriebssystem zugeordnet sein. Die einzelne Anwendung kann andere Anwendungsanfragen an die Grafik-Engines 431, 432, ... N trichtern und so eine Virtualisierung innerhalb einer VM/Partition ermöglichen.
  • In den Programmiermodellen mit dedizierten Prozessen können die Grafikverarbeitungs-Engines 431,432, N, von mehreren VM-/Anwendungspartitionen gemeinsam genutzt werden. Die gemeinsam genutzten Modelle erfordern einen System-Hypervisor zur Virtualisierung der Grafikverarbeitungs-Engines 431-432, N, um den Zugriff durch jedes Betriebssystem zu ermöglichen. Bei Einzelpartitionssystemen ohne Hypervisor hat das Betriebssystem die Grafikverarbeitungs-Engines 431 bis 432, N inne. In beiden Fällen kann das Betriebssystem die Grafikverarbeitungs-Engines 431 bis 432, N virtualisieren, um für jeden Prozess oder jede Anwendung Zugriff zu gewährleisten.
  • Für das gemeinsame Programmiermodell wählt das Grafikbeschleunigungsmodul 446 oder eine einzelne Grafikverarbeitungs-Engine 431 bis 432, N ein Prozesselement mittels eines Prozess-Handles aus. Die Prozesselemente können im Systemspeicher 441 gespeichert werden und mit den vorliegend beschriebenen Methoden zur Übersetzung von effektiven Adressen in reale Adressen adressierbar sein. Das Prozess-Handle kann ein implementierungsspezifischer Wert sein, der dem Hostprozess zur Verfügung gestellt wird, wenn sein Kontext bei der Grafikverarbeitungs-Engine 431 bis 432, N registriert wird (d.h. Systemsoftware aufgerufen wird, um das Prozesselement zur Prozesselement-Verknüpfungsliste hinzuzufügen). Die unteren 16 Bit des Prozess-Handles können der Offset des Prozesselements innerhalb der Prozesselement-Verknüpfungsliste sein.
  • 4D veranschaulicht einen beispielhaften Beschleunigerintegrationsbaustein 490. Ein „Baustein“ umfasst vorliegend einen bestimmten Teil der Verarbeitungsressourcen der Beschleunigerintegrationsschaltung 436. Der effektive Adressraum 482 einer Anwendung innerhalb des Systemspeichers 441 speichert Prozesselemente 483. Die Prozesselemente 483 können als Reaktion auf GPU-Aufrufe 481 von Anwendungen 480, die auf dem Prozessor 407 ausgeführt werden, gespeichert werden. Ein Prozesselement 483 enthält den Prozessstatus für die entsprechende Anwendung 480. Ein im Prozesselement 483 enthaltener Arbeitsdeskriptor (Work Descriptor, WD) 484 kann ein einzelner, von einer Anwendung angefragter Arbeitsauftrag sein oder einen Zeiger auf eine Warteschlange von Arbeitsaufträgen enthalten. Im letzteren Fall ist der WD 484 ein Zeiger auf die Warteschlange aus Arbeitsaufträgen im Adressraum 482 der Anwendung.
  • Das Grafikbeschleunigungsmodul 446 und/oder die einzelnen Grafikverarbeitungs-Engines 431 bis 432, N können von allen oder einer Teilmenge der Prozesse im System gemeinsam genutzt werden. Beispielsweise können die vorliegend beschriebenen Technologien eine Infrastruktur zum Einrichten des Prozessstatus und zum Senden eines WD 484 an ein Grafikbeschleunigungsmodul 446 umfassen, um einen Arbeitsauftrag in einer virtualisierten Umgebung zu starten.
  • In einer Implementierung ist das Programmiermodell mit dedizierten Prozessen implementierungsspezifisch. In diesem Modell hat ein einzelner Prozess das Grafikbeschleunigungsmodul 446 oder eine einzelne Grafikverarbeitungs-Engine 431 inne. Da das Grafikbeschleunigungsmodul 446 im Besitz eines einzelnen Prozesses ist, initialisiert der Hypervisor die Beschleunigerintegrationsschaltung 436 für die innehabende Partition, und das Betriebssystem initialisiert die Beschleunigerintegrationsschaltung 436 für den innehabenden Prozess zu dem Zeitpunkt, zu dem das Grafikbeschleunigungsmodul 446 zugewiesen wird.
  • Im Betrieb ruft eine WD-Abrufeinheit 491 im Beschleunigerintegrationsbaustein 490 den nächsten WD 484 ab, der eine Angabe der Arbeit enthält, die von einer der Grafikverarbeitungs-Engines des Grafikbeschleunigungsmoduls 446 zu erledigen ist. Daten aus dem WD 484 können in Registern 445 gespeichert und von der MMU 439, der Interrupt-Verwaltungsschaltung 447 und/oder der Kontext-Verwaltungsschaltung 448 verwendet werden wie veranschaulicht. Zum Beispiel kann die MMU 439 eine Segment-/Seitenlaufschalttechnik für den Zugriff auf Segment-/Seitentabellen 486 innerhalb des virtuellen Adressraums 485 des Betriebssystems aufweisen. Die Interrupt-Verwaltungsschaltung 447 kann vom Grafikbeschleunigungsmodul 446 empfangene Interrupt-Ereignisse 492 verarbeiten. Bei der Durchführung von Grafikoperationen wird eine von einer Grafikverarbeitungs-Engine 431 bis 432, N erzeugte effektive Adresse 493 von der MMU 439 in eine reale Adresse übersetzt.
  • Der gleiche Satz von Registern 445 kann für jede Grafikverarbeitungs-Engine 431 bis 432, N und/oder jedes Grafikbeschleunigungsmodul 446 dupliziert werden und kann vom Hypervisor oder Betriebssystem initialisiert werden. Jedes dieser duplizierten Register kann in einem Beschleunigerintegrationsbaustein 490 enthalten sein. In einer Ausführungsform kann jede Grafikverarbeitungs-Engine 431 bis 432, N dem Hypervisor 496 als eine eigene Grafikprozessoreinrichtung angezeigt werden. QoS-Einstellungen können für Clients einer bestimmten Grafikverarbeitungs-Engine 431 bis 432, N konfiguriert werden, und es kann Datenisolierung zwischen den Clients jeder Engine ermöglicht werden. Beispielhafte Register, die vom Hypervisor initialisiert werden können, sind in Tabelle 1 gezeigt. Tabelle 1 - Vom Hypervisor initialisierte Register
    1 Baustein-Steuerregister
    2 Realadressen- (RA-) Bereichszeiger Geplante Prozesse
    3 Authority-Mask-Override-Register
    4 Offset Interrupt-Vektor-Tabelleneintrag
    5 Limit Interrupt-Vektor-Tabelleneintrag
    6 Statusregister
    7 ID Logische Partition
    8 Realadressen- (RA-) Eintragszeiger Hypervisor-Beschleuniger-Nutzung
    9 Speicherbeschreibungsregister
  • Beispielhafte Register, die vom Betriebssystem initialisiert werden können, sind in Tabelle 2 gezeigt. Tabelle 2 - Vom Betriebssystem initialisierte Register
    1 Prozess- und Thread-Identifizierung
    2 Effektivadressen- (EA-) Zeiger Kontextspeicherung/-wiederherstellung
    3 Virtuelladressen- (VA-) Eintragszeiger Beschleunigernutzung
    4 Virtuelladressen- (VA-) Zeiger Speichersegmenttabelle
    5 Authority Mask
    6 Arbeitsdeskriptor
  • Jeder WD 484 kann spezifisch für ein bestimmtes Grafikbeschleunigungsmodul 446 und/oder eine Grafikverarbeitungs-Engine 431 bis 432, N sein. Er enthält alle Informationen, die eine Grafikverarbeitungs-Engine 431 bis 432, N benötigt, um ihre Arbeit zu verrichten, oder er kann ein Zeiger auf einen Speicherplatz sein, an dem die Anwendung eine Befehlswarteschlange für zu verrichtende Arbeit eingerichtet hat.
  • 4E veranschaulicht zusätzliche optionale Einzelheiten eines gemeinsamen Modells. Es umfasst einen Hypervisor-Realadressraum 498, in dem eine Prozesselementliste 499 gespeichert ist. Der Zugriff auf den Hypervisor-Realadressraum 498 erfolgt über einen Hypervisor 496, der die Grafikbeschleunigungsmodul-Engines für das Betriebssystem 495 virtualisiert.
  • Die gemeinsamen Programmiermodelle ermöglichen es, dass alle oder ein Teilsatz von Prozessen aus allen oder einem Teilsatz von Partitionen im System ein Grafikbeschleunigungsmodul 446 verwenden. Es gibt zwei Programmiermodelle, bei denen das Grafikbeschleunigungsmodul 446 von mehreren Prozessen und Partitionen gemeinsam genutzt wird: nach Zeitbausteinen geteilt (time-sliced shared) und grafikgerichtet geteilt (graphics directed shared).
  • In diesem Modell hat der System-Hypervisor 496 das Grafikbeschleunigungsmodul 446 inne und stellt dessen Funktion allen Betriebssystemen 495 zur Verfügung. Damit ein Grafikbeschleunigungsmodul 446 die Virtualisierung durch den System-Hypervisor 496 unterstützt, kann das Grafikbeschleunigungsmodul 446 die folgenden Anforderungen einhalten: 1) Die Arbeitsauftragsanfrage einer Anwendung muss autonom sein (d.h. der Status muss zwischen den Arbeitsaufträgen nicht beibehalten werden), oder das Grafikbeschleunigungsmodul 446 muss einen Mechanismus für Kontextsicherung und -wiederherstellung bereitstellen. 2) Das Grafikbeschleunigungsmodul 446 garantiert, dass die Arbeitsauftragsanfrage einer Anwendung in einer bestimmten Zeitspanne abgeschlossen wird, einschließlich etwaiger Übersetzungsfehler, oder das Grafikbeschleunigungsmodul 446 bietet die Möglichkeit, die Bearbeitung des Auftrags zurückzustellen. 3) Dem Grafikbeschleunigungsmodul 446 muss Fairness zwischen den Prozessen garantiert werden, wenn es im gerichteten gemeinsamen Programmiermodell arbeitet.
  • Für das gemeinsame Modell muss die Anwendung 480 möglicherweise einen Systemaufruf des Betriebssystems 495 mit einem Grafikbeschleunigungsmodul- 446 Typ, einem Arbeitsdeskriptor (WD), einem AMR-(Authority Mask Register) Wert und einem Bereichszeiger für Kontextsicherung/- wiederherstellung (Context Save/Restore Area Pointer, CSRP) durchführen. Der Grafikbeschleunigungsmodul- 446 Typ beschreibt die angestrebte Beschleunigungsfunktion für den Systemaufruf. Der Grafikbeschleunigungsmodul- 446 Typ kann ein systemspezifischer Wert sein. Der WD ist speziell für das Grafikbeschleunigungsmodul 446 formatiert und kann in Form eines Grafikbeschleunigungsmodul- 446 Befehls, eines Effektivadresszeigers auf eine nutzerdefinierte Struktur, eines Effektivadresszeigers auf eine Befehlswarteschlange oder einer anderen Datenstruktur vorliegen, um die vom Grafikbeschleunigungsmodul 446 zu verrichtende Arbeit zu beschreiben. In einer Ausführungsform ist der AMR-Wert der AMR-Status, der für den aktuellen Prozess zu verwenden ist. Der an das Betriebssystem übergebene Wert ist vergleichbar mit einer Anwendung, die den AMR setzt. Wenn die Implementierungen der Beschleunigerintegrationsschaltung 436 und des Grafikbeschleunigungsmoduls 446 kein User-Authority-Mask-Override-Register (UAMOR) unterstützen, kann das Betriebssystem den aktuellen UAMOR-Wert auf den AMR-Wert anwenden, bevor der AMR im Hypervisor-Aufruf übergeben wird. Der Hypervisor 496 kann optional den aktuellen Authority-Mask-Override-Register-(AMOR-) Wert anwenden, bevor er den AMR in das Prozesselement 483 platziert. Der CSRP kann eines der Register 445 sein, die die effektive Adresse eines Bereichs im Adressraum 482 der Anwendung für das Grafikbeschleunigungsmodul 446 zum Speichern und Wiederherstellen des Kontextstatus enthält. Dieser Zeiger ist optional, wenn zwischen Arbeitsaufträgen oder beim Zurückstellen eines Auftrags kein Status gespeichert werden muss. Der Kontextspeicher-/Wiederherstellungsbereich kann festgelegter Systemspeicher sein.
  • Beim Empfang des Systemaufrufs kann das Betriebssystem 495 überprüfen, ob die Anwendung 480 registriert ist und die Berechtigung zur Verwendung des Grafikbeschleunigungsmoduls 446 erhalten hat. Anschließend ruft das Betriebssystem 495 den Hypervisor 496 mit den in Tabelle 3 gezeigten Informationen auf. Tabelle 3 - Parameter für den Aufruf des Betriebssystems an den Hypervisor
    1 Ein Arbeitsdeskriptor (WD)
    2 Ein Authority-Mask-Register- (AMR)-Wert (möglicherweise maskiert).
    3 Effektivadressen- (EA-) Bereichszeiger Kontextspeicherung/- wiederherstellung (CSRP)
    4 Eine Prozess-ID (PID) und wahlweise eine Thread-ID (TID)
    5 Virtuelladressen- (VA-) Eintragszeiger Beschleunigernutzung (Accelerator Utilization Record Pointer, AURP)
    6 Die virtuelle Adresse des Speichersegmenttabellenzeigers (Storage Segment Table Pointer, SSTP)
    7 Eine Logical-Interrupt-Service-Nummer (LISN)
  • Beim Empfang des Hypervisor-Aufrufs überprüft der Hypervisor 496, ob das Betriebssystem 495 registriert ist und die Berechtigung zur Verwendung des Grafikbeschleunigungsmoduls 446 erhalten hat. Der Hypervisor 496 setzt dann das Prozesselement 483 in die Prozesselement-Verknüpfungsliste für den entsprechenden Grafikbeschleunigungsmodul- 446 Typ. Das Prozesselement kann die in Tabelle 4 gezeigten Informationen aufweisen. Tabelle 4 - Prozesselementinformationen
    1 Einen Arbeitsdeskriptor (WD)
    2 Einen Authority-Mask-Register- (AMR)-Wert (möglicherweise maskiert).
    3 Effektivadressen- (EA-) Bereichszeiger Kontextspeicherung/- wiederherstellung (CSRP)
    4 Eine Prozess-ID (PID) und wahlweise eine Thread-ID (TID)
    5 Virtuelladressen- (VA-) Eintragszeiger Beschleunigernutzung (Accelerator Utilization Record Pointer, AURP)
    6 Die virtuelle Adresse des Speichersegmenttabellenzeigers (Storage Segment Table Pointer, SSTP)
    7 Eine Logical-Interrupt-Service-Nummer (LISN)
    8 Interrupt-Vektortabelle, abgeleitet aus den Hypervisor-Aufrufparametern.
    9 Einen Statusregister- (SR-) Wert
    10 Eine Logikpartitions-ID (LPID)
    11 Realadressen- (RA-) Eintragszeiger Hypervisor-Beschleuniger-Nutzung
    12 Das Storage-Descriptor-Register (SDR)
  • Der Hypervisor kann eine Vielzahl von Registern 445 des Beschleunigerintegrationsbausteins 490 initialisieren.
  • Wie in 4F veranschaulicht, wird in einer optionalen Implementierung ein vereinheitlichter Speicher verwendet, der über einen gemeinsamen virtuellen Speicheradressraum adressierbar ist, der für den Zugriff auf die physischen Prozessorspeicher 401 bis 402 und die GPU-Speicher 420 bis 423 verwendet wird. In dieser Implementierung verwenden Operationen, die auf den GPUs 410 bis 413 ausgeführt werden, denselben virtuellen/effektiven Speicheradressraum, um auf die Prozessorspeicher 401 bis 402 zuzugreifen und umgekehrt, was die Programmierbarkeit vereinfacht. Ein erster Teil des virtuellen/effektiven Adressraums kann dem Prozessorspeicher 401 zugeteilt werden, ein zweiter Teil dem zweiten Prozessorspeicher 402, ein dritter Teil dem GPU-Speicher 420 usw. Der gesamte virtuelle/effektive Speicherraum (manchmal auch als effektiver Adressraum bezeichnet) kann dadurch auf jeden der Prozessorspeicher 401 bis 402 und GPU-Speicher 420 bis 423 verteilt werden, so dass jeder Prozessor oder jede GPU auf jeden physischen Speicher mit einer virtuellen Adresse zugreifen kann, die auf diesen Speicher abgebildet ist.
  • Bias-/Kohärenz-Verwaltungsschalttechnik 494A bis 494E in einer oder mehreren der MMUs 439A bis 439E kann bereitgestellt sein, die die Cache-Kohärenz zwischen den Caches der Hostprozessoren (z.B. 405) und den GPUs 410 bis 413 sicherstellt und Biasing-Methoden implementiert, die die physischen Speicher angeben, in denen bestimmte Datentypen gespeichert werden sollten. Während in 4F mehrere Instanzen der Bias-/Kohärenz-Verwaltungsschalttechnik 494A bis 494E dargestellt sind, kann die Bias-/Kohärenz-Schalttechnik innerhalb der MMU eines oder mehrerer Hostprozessoren 405 und/oder innerhalb der Beschleunigerintegrationsschaltung 436 implementiert sein.
  • Der an die GPU angeschlossene Speicher 420 bis 423 kann als Teil des Systemspeichers abgebildet werden und der Zugriff erfolgt über die SVM-Technologie (Shared Virtual Memory), ohne jedoch die typischen Leistungsnachteile zu erleiden, die mit vollständiger System-Cache-Kohärenz verbunden sind. Die Möglichkeit, auf GPU-angeschlossenen Speicher 420 bis 423 als Systemspeicher ohne lästigen Cache-Kohärenz-Overhead zuzugreifen, bietet eine vorteilhafte Betriebsumgebung für GPU-Offload. Diese Anordnung ermöglicht es der Software des Hostprozessors 405, Operanden einzurichten und auf Berechnungsergebnisse zuzugreifen, ohne den Overhead der traditionellen E/A-DMA-Datenkopien. Solche traditionellen Kopien beinhalten Treiberaufrufe, Interrupts und speicherabgebildete E/A- (Memory-Mapped I/O, MMIO-) Zugriffe, die alle im Vergleich zu einfachen Speicherzugriffen ineffizient sind. Gleichzeitig kann die Fähigkeit, ohne Cache-Kohärenz-Overhead auf den an die GPU angeschlossenen Speicher 420 bis 423 zuzugreifen, entscheidend für die Ausführungszeit einer ausgelagerten Berechnung sein. In Fällen mit erheblichem Streaming-Schreibspeicherverkehr kann beispielsweise der Cache-Kohärenz-Overhead die effektive Schreibbandbreite, die eine GPU 410 bis 413 sieht, erheblich reduzieren. Die Effizienz der Operandeneinrichtung, die Effizienz des Ergebniszugriffs und die Effizienz der GPU-Berechnung spielen alle eine Rolle bei der Bestimmung der Effektivität des GPU-Offloads.
  • Eine Auswahl zwischen GPU-Bias und Hostprozessor-Bias kann durch eine Bias-Tracker-Datenstruktur gesteuert werden. Es kann z.B. eine Bias-Tabelle verwendet werden, die eine seitengranulare Struktur sein kann (d.h., die mit der Granularität einer Speicherseite gesteuert wird), die 1 oder 2 Bits pro Seite des GPU-angeschlossenen Speichers umfasst. Die Bias-Tabelle kann in einem gestohlenen Speicherbereich eines oder mehrerer GPU-angeschlossener Speicher 420 bis 423 implementiert sein, mit oder ohne Bias-Cache in der GPU 410 bis 413 (z.B. um häufig/kurzzeitig verwendete Einträge der Bias-Tabelle zwischenzuspeichern). Alternativ kann auch die gesamte Bias-Tabelle innerhalb der GPU gepflegt werden.
  • In einer Implementierung wird auf den Bias-Tabelleneintrag, der mit jedem Zugriff auf den GPU-angeschlossenen Speicher 420 bis 423 verbunden ist, vor dem eigentlichen Zugriff auf den GPU-Speicher zugegriffen, was die folgenden Operationen bewirkt. Zunächst werden lokale Anfragen von der GPU 410 bis 413, die ihre Seite in GPU-Bias finden, direkt an einen entsprechenden GPU-Speicher 420 bis 423 weitergeleitet. Lokale Anfragen von der GPU, die ihre Seite in Host-Bias finden, werden an den Prozessor 405 weitergeleitet (z.B. über eine Hochgeschwindigkeitsverbindung wie vorstehend beschrieben). Wahlweise schließen Anfragen des Prozessors 405, die die angefragte Seite in Hostprozessor-Bias finden, die Anfrage wie einen normalen Speicherlesevorgang ab. Alternativ können Anfragen, die an eine Seite mit GPU-Bias gerichtet sind, an die GPU 410 bis 413 weitergeleitet werden. Die GPU kann dann die Seite auf ein Hostprozessor-Bias überführen, wenn sie die Seite gerade nicht verwendet.
  • Der Bias-Status einer Seite kann entweder durch einen softwarebasierten Mechanismus, einen hardwareunterstützten softwarebasierten Mechanismus oder, für eine begrenzte Anzahl von Fällen, einen rein hardwarebasierten Mechanismus geändert werden.
  • Ein Mechanismus zum Ändern des Bias-Status verwendet einen API-Aufruf (z.B. OpenCL), der wiederum den Gerätetreiber der GPU aufruft, der wiederum eine Nachricht an die GPU sendet (oder einen Befehlsdeskriptor in die Warteschlange stellt) und sie anweist, den Bias-Status zu ändern und bei einigen Übergängen eine Cacheleerungsoperation im Host durchzuführen. Die Cacheleerungsoperation ist für einen Übergang von Hostprozessor- 405 Bias zu GPU-Bias erforderlich, nicht aber für den umgekehrten Übergang.
  • Die Cache-Kohärenz kann dadurch aufrechterhalten werden, dass Seiten mit GPU-Bias vom Hostprozessor 405 vorübergehend nicht zwischengespeichert werden können. Um auf diese Seiten zuzugreifen, kann der Prozessor 405 Zugriff bei der GPU 410 anfragen , die je nach Implementierung den Zugriff sofort gewähren kann oder nicht. Um die Kommunikation zwischen dem Hostprozessor 405 und der GPU 410 zu reduzieren, ist es daher vorteilhaft, dafür zu sorgen, dass es sich bei den Seiten mit GPU-Bias um solche handelt, die von der GPU, nicht aber vom Hostprozessor 405 benötigt werden und umgekehrt.
  • Grafikverarbeitungspipeline
  • 5 veranschaulicht eine Grafikverarbeitungspipeline 500. Ein Grafik-Multiprozessor wie beispielsweise der Grafik-Multiprozessor 234 wie in 2D, der Grafik-Multiprozessor 325 aus 3A, der Grafik-Multiprozessor 350 aus 3B kann die dargestellte Grafikverarbeitungspipeline 500 implementieren. Der Grafik-Multiprozessor kann in den vorliegend beschriebenen Parallelverarbeitungsteilsystemen umfasst sein, beispielsweise dem Parallelprozessor 200 aus 2A, die mit dem/den Parallelprozessor(en) 112 aus 1 verwandt sein können und anstelle eines dieser Systeme verwendet werden können. Die verschiedenen Parallelverarbeitungssysteme können die Grafikverarbeitungspipeline 500 über eine oder mehrere Instanzen der Parallelverarbeitungseinheit (z.B. die Parallelverarbeitungseinheit 202 aus 2A) wie vorliegend beschrieben implementieren. Beispielsweise kann eine Schattiereinheit (z.B. der Grafik-Multiprozessor 234 aus 2C) so konfiguriert sein, dass sie die Funktionen einer Vertexverarbeitungseinheit 504, einer Tesselationssteuerungs-Verarbeitungseinheit 508, einer Tesselationsauswertungs-Verarbeitungseinheit 512, einer Geometrieverarbeitungseinheit 516 und/oder einer Fragment-/Pixelverarbeitungseinheit 524 ausführt. Die Funktionen eines Daten-Assemblers 502, Primitiv-Assemblers 506, 514, 518, einer Tesselationseinheit 510, eines Rasterers 522 und einer Rasteroperationseinheit 526 können auch von anderen Verarbeitungs-Engines innerhalb eines Verarbeitungsclusters (z.B. Verarbeitungscluster 214 aus 2A) und einer entsprechenden Partitionseinheit (z.B. Partitionseinheit 220A bis 220N aus 2A) ausgeführt werden. Die Grafikverarbeitungspipeline 500 kann auch mit dedizierten Verarbeitungseinheiten für eine oder mehrere Funktionen implementiert werden. Es ist zudem möglich, dass ein oder mehrere Teile der Grafikverarbeitungspipeline 500 von Parallelverarbeitungslogik innerhalb eines Allzweckprozessors (z.B. CPU) ausgeführt werden. Optional können ein oder mehrere Teile der Grafikverarbeitungspipeline 500 über eine Speicherschnittstelle 528, bei der es sich um eine Instanz der Speicherschnittstelle 218 aus 2A handeln kann, auf On-Chip-Speicher (z.B. den Parallelprozessorspeicher 222 wie in 2A) zugreifen. Die Grafikprozessorpipeline 500 kann auch über eine Mehrkerngruppe 365A wie in 3C implementiert werden.
  • Der Daten-Assembler 502 ist eine Verarbeitungseinheit, die Vertexdaten für Flächen und Primitive erfassen kann. Der Daten-Assembler 502 gibt dann die Vertexdaten, einschließlich der Vertexattribute, an die Vertexverarbeitungseinheit 504 aus. Die Vertexverarbeitungseinheit 504 ist eine programmierbare Ausführungseinheit, die Vertexschattierprogramme ausführt und Vertexdaten entsprechend den Vorgaben der Vertexschattierprogramme beleuchtet und transformiert. Die Vertexverarbeitungseinheit 504 liest Daten, die im Cache-, Lokal- oder Systemspeicher gespeichert sind, zur Verwendung bei der Verarbeitung der Vertexdaten und kann so programmiert sein, dass sie die Vertexdaten von einer objektbasierten Koordinatendarstellung in einen Weltraumkoordinatenraum oder einen normalisierten Einrichtungskoordinatenraum transformiert.
  • Eine erste Instanz eines Primitiv-Assemblers 506 empfängt Vertexattribute von der Vertexverarbeitungseinheit 504. Der Primitiv-Assembler 506 liest gespeicherte Vertexattribute nach Bedarf aus und konstruiert Grafikprimitive für die Verarbeitung durch die Tesselationssteuerungs-Verarbeitungseinheit 508. Zu den Grafikprimitiven gehören Dreiecke, Liniensegmente, Punkte, Felder (patches) usw., die von verschiedenen Anwendungsprogrammierschnittstellen (APIs) für Grafikverarbeitung unterstützt werden.
  • Die Tesselationssteuerungs-Verarbeitungseinheit 508 behandelt die Eingangsvertices als Kontrollpunkte für ein geometrisches Feld. Die Kontrollpunkte werden aus einer Eingabedarstellung aus dem Feld (z.B. die Basen des Felds) in eine Darstellung transformiert, die für die Verwendung in der Oberflächenauswertung durch die Tesselationsauswertungs-Verarbeitungseinheit 512 geeignet ist. Die Tesselationssteuerungs-Verarbeitungseinheit 508 kann auch Tesselationsfaktoren für Kanten von geometrischen Feldern berechnen. Ein Tesselationsfaktor gilt für eine einzelne Kante und quantifiziert einen ansichtsabhängigen Detailgrad, der mit der Kante verbunden ist. Eine Tesselationseinheit 510 ist so konfiguriert, dass sie die Tesselationsfaktoren für die Kanten eines Flecks empfängt und das Feld in mehrere geometrische Primitive wie Linien-, Dreieck- oder Viereckprimitive tesseliert, die an eine Tesselationsauswertungs-Verarbeitungseinheit 512 übertragen werden. Die Tesselationsauswertungs-Verarbeitungseinheit 512 arbeitet mit parametrisierten Koordinaten des unterteilten Felds, um eine Oberflächendarstellung und Vertexattribute für jeden Vertex zu erzeugen, der mit den geometrischen Primitiven verbunden ist.
  • Eine zweite Instanz eines Primitiv-Assemblers 514 empfängt Vertexattribute von der Tesselationsauswertungs-Verarbeitungseinheit 512, liest gespeicherte Vertexattribute nach Bedarf aus und konstruiert Grafikprimitive zur Verarbeitung durch die Geometrieverarbeitungseinheit 516. Die Geometrieverarbeitungseinheit 516 ist eine programmierbare Ausführungseinheit, die Geometrieschattierprogramme ausführt, um vom Primitiv-Assembler 514 empfangene Grafikprimitive wie durch die Geometrieschattierprogramme vorgegeben zu transformieren. Die Geometrieverarbeitungseinheit 516 kann so programmiert sein, dass sie die Grafikprimitive in ein oder mehrere neue Grafikprimitive unterteilt und Parameter berechnet, die zur Rasterung der neuen Grafikprimitive verwendet werden.
  • Die Geometrieverarbeitungseinheit 516 kann in der Lage sein, Elemente im Geometriestrom hinzuzufügen oder zu löschen. Die Geometrieverarbeitungseinheit 516 gibt die Parameter und Vertices, die neue Grafikprimitive spezifizieren, an den Primitiv-Assembler 518 aus. Der Primitiv-Assembler 518 empfängt die Parameter und Vertices von der Geometrieverarbeitungseinheit 516 und konstruiert Grafikprimitive zur Verarbeitung durch eine Viewport-Skalierungs-, Sortier- und Clip-Einheit 520. Die Geometrieverarbeitungseinheit 516 liest Daten, die im Parallelprozessorspeicher oder im Systemspeicher gespeichert sind, um sie für die Verarbeitung der Geometriedaten zu verwenden. Die Viewport-Skalierungs-, Sortier- und Clip-Einheit 520 führt Clipping, Sortierung und Viewport-Skalierung durch und gibt verarbeitete Grafikprimitive an einen Rasterer 522 aus.
  • Der Rasterer 522 kann Tiefensortierung und andere tiefenbasierte Optimierungen durchführen. Der Rasterer 522 führt zudem eine Scan-Konvertierung an den neuen Grafikprimitiven durch, um Fragmente zu erzeugen und diese Fragmente und die zugehörigen Abdeckungsdaten an die Fragment-/Pixelverarbeitungseinheit 524 auszugeben. Die Fragment-/Pixelverarbeitungseinheit 524 ist eine programmierbare Ausführungseinheit, die für die Ausführung von Fragmentschattierprogrammen oder Pixelschattierprogrammen konfiguriert ist. Die Fragment-/Pixelverarbeitungseinheit 524 transformiert vom Rasterer 522 empfangene Fragmente oder Pixel wie von den Fragment- oder Pixelschattierprogrammen vorgegeben. Beispielsweise kann die Fragment-/Pixelverarbeitungseinheit 524 so programmiert sein, dass sie, ohne jedoch hierauf eingeschränkt zu sein, Operationen wie Texturabbildung, Schattierung, Mischung, Texturkorrektur und perspektivische Korrektur durchführt, um schattierte Fragmente oder Pixel zu erzeugen, die an eine Rasteroperationseinheit 526 ausgegeben werden. Die Fragment-/Pixelverarbeitungseinheit 524 kann Daten lesen, die im Parallelprozessorspeicher oder im Systemspeicher gespeichert sind, um sie für die Verarbeitung der Fragmentdaten zu verwenden. Fragment- oder Pixelschattierprogramme können so konfiguriert werden, dass sie mit Sample-, Pixel-, Kachel- oder anderen Granularitäten schattieren, abhängig von der für die Verarbeitungseinheiten konfigurierten Abtastrate.
  • Die Rasteroperationseinheit 526 ist eine Verarbeitungseinheit, die Rasteroperationen durchführt, darunter, ohne jedoch hierauf eingeschränkt zu sein, Schablone, Z-Test, Mischung und dergleichen, und Pixeldaten als verarbeitete Grafikdaten ausgibt, die im Grafikspeicher (z.B. im Parallelprozessorspeicher 222 wie in 2A und/oder im Systemspeicher 104 wie in 1) zur Anzeige auf der einen oder den mehreren Anzeigeeinrichtungen 110 oder zur weiteren Verarbeitung durch einen des einen oder der mehreren Prozessoren 102 oder Parallelprozessoren 112 gespeichert werden sollen. Die Rasteroperationseinheit 526 kann so konfiguriert sein, dass sie z- oder Farbdaten, die in den Speicher geschrieben werden, komprimiert und z- oder Farbdaten, die aus dem Speicher gelesen werden, dekomprimiert.
  • Übersicht maschinelles Lernen
  • Die vorstehend beschriebene Architektur kann verwendet werden, um Trainings- und Inferenzoperationen mit Modellen für maschinelles Lernen durchzuführen. Maschinelles Lernen hat sich bei der Lösung vieler Arten von Aufgaben bewährt. Die Berechnungen, die beim Training und der Verwendung von Algorithmen für maschinelles Lernen (z.B. neuronale Netze) anfallen, eignen sich in ihrer Natur für effiziente Parallelimplementierungen. Dementsprechend haben Parallelprozessoren wie Allzweck-Grafikverarbeitungseinheiten (GPGPUs) eine bedeutende Rolle bei der praktischen Implementierung von tiefen neuronalen Netzen gespielt. Parallele Grafikprozessoren mit Single-Instruction-Multi-Thread (SIMT)-Architekturen sind darauf ausgelegt, das Ausmaß der Parallelverarbeitung in der Grafikpipeline zu maximieren. In einer SIMT-Architektur versuchen Gruppen von parallelen Threads, Programmanweisungen so oft wie möglich gemeinsam synchron auszuführen, um die Verarbeitungseffizienz zu erhöhen. Die Effizienz, die durch parallele Implementierungen von Algorithmen des maschinellen Lernens erreicht wird, ermöglicht den Einsatz von Netzen mit hoher Kapazität und erlaubt es, diese Netze auf größere Datensätze zu trainieren.
  • Ein Algorithmus für maschinelles Lernen ist ein Algorithmus, der auf Grundlage eines Datensatzes lernen kann. Beispielsweise können Ausführungsformen von Algorithmen für maschinelles Lernen dafür konzipiert sein, hochgradige Abstraktionen innerhalb eines Datensatzes zu modellieren. Zum Beispiel können Bilderkennungsalgorithmen verwendet werden, um zu bestimmen, zu welcher von mehreren Kategorien eine gegebene Eingabe gehört, Regressionsalgorithmen können einen numerischen Wert angesichts einer Eingabe ausgeben, und Mustererkennungsalgorithmen können verwendet werden, um übersetzten Text zu generieren oder Text-zu-Sprache und/oder Spracherkennung durchzuführen.
  • Ein beispielhafter Typ eines Algorithmus für maschinelles Lernen ist ein neuronales Netz. Es gibt viele Arten von neuronalen Netzen; ein einfacher Typ von neuronalen Netzen ist ein Feedforward-Netz. Ein Feedforward-Netz kann als azyklischer Graph implementiert werden, in dem die Knoten in Schichten angeordnet sind. Typischerweise umfasst eine Feedforward-Netztopologie eine Eingabeschicht und eine Ausgabeschicht, die durch mindestens eine verborgene Schicht getrennt sind. Die verborgene Schicht wandelt durch die Eingabeschicht empfangene Eingaben in eine Repräsentation um, die zum Generieren von Ausgaben in der Ausgabeschicht von Nutzen ist. Die Netzknoten sind über Kanten zu den Knoten in angrenzenden Schichten vollständig verbunden, jedoch gibt es zwischen Knoten innerhalb jeder Schicht keine Kanten. Daten, die an den Knoten einer Eingabeschicht eines Feedforward-Netzes empfangen werden, werden über eine Aktivierungsfunktion, die die Zustände der Knoten jeder aufeinanderfolgenden Schicht im Netz auf der Grundlage von Koeffizienten („Gewichtungen“) berechnet, die jeweils mit jeder der die Schichten verbindenden Kanten verbunden sind, an die Knoten der Ausgabeschicht propagiert (d.h. „vorwärtsgeführt“). Je nach dem durch den ausgeführten Algorithmus repräsentierten konkreten Modell können die Ausgaben aus dem Algorithmus des neuronalen Netzes verschiedene Formen annehmen.
  • Bevor ein Algorithmus für maschinelles Lernen verwendet werden kann, um ein bestimmtes Problem zu modellieren, wird der Algorithmus mittels eines Trainingsdatensatzes trainiert. Das Training eines neuronalen Netzes beinhaltet die Auswahl einer Netztopologie, die Verwendung eines Satzes von Trainingsdaten, die ein Problem darstellen, das durch das Netz modelliert wird, und die Anpassung der Gewichtungen, bis das Netzmodell mit einem minimalen Fehler für alle Instanzen des Trainingsdatensatzes arbeitet. Zum Beispiel wird während eines Trainingsprozesses mit überwachtem Lernen für ein neuronales Netz die Ausgabe, die durch das Netz als Reaktion auf die eine Instanz in einem Trainingsdatensatz darstellende Eingabe erzeugt wird, mit der als „korrekt“ gekennzeichneten Ausgabe für diese Instanz verglichen, ein Fehlersignal, das die Differenz zwischen der Ausgabe und der gekennzeichneten Ausgabe darstellt, wird berechnet, und die Gewichtungen, die mit den Verbindungen verbunden sind, werden angepasst, um diesen Fehler zu minimieren, während das Fehlersignal rückwärts durch die Schichten des Netzes propagiert wird. Das Netz wird als „trainiert“ betrachtet, wenn die Fehler für jede der aus den Instanzen des Trainingsdatensatzes erzeugten Ausgaben minimiert sind.
  • Die Genauigkeit eines Algorithmus für maschinelles Lernen kann erheblich von der Qualität des zum Trainieren des Algorithmus verwendeten Datensatzes beeinflusst werden. Der Trainingsprozess kann rechenintensiv sein und auf einem herkömmlichen Allzweckprozessor eine erhebliche Zeitspanne in Anspruch nehmen. Dementsprechend wird Parallelverarbeitungshardware zum Trainieren vieler Arten von Algorithmen für maschinelles Lernen verwendet. Dies ist besonders nützlich für die Optimierung des Trainings von neuronalen Netzen, da sich die Berechnungen, die bei der Anpassung der Koeffizienten in neuronalen Netzen durchgeführt werden, natürlich für parallele Implementierungen eignen. Insbesondere wurden viele Algorithmen und Softwareanwendungen für maschinelles Lernen so angepasst, dass sie die Parallelverarbeitungshardware in Allzweck-Grafikverarbeitungseinrichtungen nutzen können.
  • 6 ist ein verallgemeinertes Schaubild eines Software-Stacks 600 für maschinelles Lernen. Eine Maschinenlernanwendung 602 ist eine beliebige Logik, die so konfiguriert werden kann, dass sie ein neuronales Netz anhand eines Trainingsdatensatzes trainiert oder ein trainiertes tiefes neuronales Netz verwendet, um maschinelle Intelligenz zu implementieren. Die Maschinenlernanwendung 602 kann Trainings- und Inferenzfunktionen für ein neuronales Netz und/oder spezialisierte Software enthalten, die zum Trainieren eines neuronalen Netzes vor dem Einsatz verwendet werden kann. Die Maschinelernanwendung 602 kann jede Art von maschineller Intelligenz implementieren, einschließlich, ohne jedoch hierauf eingeschränkt zu sein, Bilderkennung, Kartierung und Lokalisierung, autonome Navigation, Sprachsynthese, medizinische Bildgebung oder Sprachübersetzung. Beispiele für Maschinenlernanwendungen 602 sind, ohne jedoch hierauf eingeschränkt zu sein, sprachbasierte virtuelle Assistenten, Bild- oder Gesichtserkennungsalgorithmen, autonome Navigation und die Softwaretools, die zum Trainieren der von den Maschinenlernanwendungen 602 verwendeten Maschinenlernmodelle verwendet werden.
  • Die Hardwarebeschleunigung für die Maschinenlernanwendung 602 kann über ein Maschinenlern-Framework 604 aktiviert werden. Das Maschinenlern-Framework 604 kann eine Bibliothek mit Primitiven für maschinelles Lernen bereitstellen. Primitive für maschinelles Lernen sind grundlegende Operationen, die häufig von Algorithmen für maschinelles Lernen ausgeführt werden. Ohne das Framework 604 für maschinelles Lernen müssten Entwickler von Algorithmen für maschinelles Lernen die mit dem Algorithmus für maschinelles Lernen verbundene Hauptrechenlogik erstellen und optimieren und dann die Rechenlogik erneut optimieren, wenn neue Parallelprozessoren entwickelt werden. Stattdessen kann die Maschinenlernanwendung so konfiguriert werden, dass sie die erforderlichen Berechnungen unter Verwendung der vom Framework 604 für maschinelles Lernen bereitgestellten Primitive durchführt. Zu beispielhaften Primitiven gehören Tensorfaltungen, Aktivierungsfunktionen und Pooling, d.h. Rechenoperationen, die während des Trainings eines neuronalen Faltungsnetzes (Convolutional Neural Network, CNN) durchgeführt werden. Das Framework 604 für maschinelles Lernen kann auch Primitive bereitstellen, um grundlegende Teilprogramme für lineare Algebra zu implementieren, die von vielen Algorithmen für maschinelles Lernen ausgeführt werden, wie beispielsweise Matrix- und Vektoroperationen. Beispiele für ein Maschinenlern-Framework 604 sind, ohne jedoch hierauf eingeschränkt zu sein, TensorFlow, TensorRT, PyTorch, MXNet, Caffee und andere High-Level-Frameworks für maschinelles Lernen.
  • Das Maschinenlern-Framework 604 kann von der Maschinenlernanwendung 602 empfangene Eingabedaten verarbeiten und die entsprechende Eingabe für ein Rechen-Framework 606 erzeugen. Das Rechen-Framework 606 kann die zugrunde liegenden Anweisungen abstrahieren, die dem GPGPU-Treiber 608 zur Verfügung gestellt werden, um es dem Maschinenlern-Framework 604 zu ermöglichen, die Vorteile der Hardwarebeschleunigung über die GPGPU-Hardware 610 zu nutzen, ohne dass das Maschinenlern-Framework 604 genaue Kenntnisse über die Architektur der GPGPU-Hardware 610 haben muss. Zusätzlich kann das Rechen-Framework 606 die Hardwarebeschleunigung für das Maschinenlern-Framework 604 über eine Vielzahl von Typen und Generationen der GPGPU-Hardware 610 ermöglichen. Beispielhafte Rechen-Frameworks 606 umfassen das CUDA-Rechen-Framework und zugehörige Bibliotheken für maschinelles Lernen, wie die Bibliothek CUDA Deep Neural Network (cuDNN). Der Software-Stack 600 für maschinelles Lernen kann auch Kommunikationsbibliotheken oder Frameworks enthalten, um Multi-GPU- und Multi-Knoten-Berechnungen zu ermöglichen.
  • GPGPU-Beschleunigung für maschinelles Lernen
  • 7 veranschaulicht eine Allzweck-Grafikverarbeitungseinheit 700, bei der es sich um den Parallelprozessor 200 aus 2A oder den/die Parallelprozessor(en) 112 aus 1 handeln kann. Die Allzweck-Verarbeitungseinheit (GPGPU) 700 kann so konfiguriert sein, dass sie Unterstützung für die Hardwarebeschleunigung von Primitiven bietet, die von einem Maschinenlern-Framework bereitgestellt werden, um die Verarbeitung der Art von Rechenlasten zu beschleunigen, die mit dem Training tiefer neuronaler Netze verbunden sind. Zusätzlich kann die GPGPU 700 direkt mit anderen Instanzen der GPGPU verbunden werden, um einen Multi-GPU-Cluster zu erstellen, um die Trainingsgeschwindigkeit für besonders tiefe neuronale Netze zu verbessern. Es werden auch Primitive unterstützt, um Inferenzoperationen für eingesetzte neuronale Netze zu beschleunigen.
  • Die GPGPU 700 weist eine Hostschnittstelle 702 auf, um eine Verbindung mit einem Hostprozessor zu ermöglichen. Die Hostschnittstelle 702 kann eine PCI-Express-Schnittstelle sein. Die Hostschnittstelle kann jedoch auch eine herstellerspezifische Kommunikationsschnittstelle oder ein herstellerspezifisches Kommunikations-Fabric sein. Die GPGPU 700 empfängt Befehle vom Hostprozessor und verwendet einen globalen Scheduler 704, um die mit diesen Befehlen verbundenen Ausführungs-Threads auf einen Satz von Verarbeitungsclustern 706A bis 706H zu verteilen. Die Verarbeitungscluster 706A bis 706H teilen sich einen Cachespeicher 708. Der Cachespeicher 708 kann als übergeordneter Cache für Cachespeicher innerhalb der Verarbeitungscluster 706A bis 706H dienen. Die dargestellten Verarbeitungscluster 706A bis 706H können den Verarbeitungsclustern 214A bis 214N wie in 2A entsprechen.
  • Die GPGPU 700 weist Speicher 714A bis 714B auf, die über einen Satz von Speichercontrollern 712A bis 712B mit den Verarbeitungsclustern 706A bis 706H verbunden sind. Der Speicher 714A bis 714B kann verschiedene Arten von Speichereinrichtungen aufweisen, einschließlich dynamischer Direktzugriffsspeicher (DRAM) oder Grafik-Direktzugriffsspeicher, wie synchroner Grafik-Direktzugriffsspeicher (SGRAM), einschließlich Grafik-Doppeldatenraten- (GDDR-) Speicher. Der Speicher 714A bis 714B kann zudem 3D-Stapelspeicher enthalten, darunter, ohne jedoch hierauf eingeschränkt zu sein, Speicher mit hoher Bandbreite (High Bandwidth Memory, HBM-, Speicher).
  • Jeder der Verarbeitungscluster 706A bis 706H kann einen Satz von Grafik-Multiprozessoren aufweisen, beispielsweise den Grafik-Multiprozessor 234 aus 2D, den Grafik-Multiprozessor 325 aus 3A, den Grafik-Multiprozessor 350 aus 3B, oder kann eine Mehrkerngruppe 365A bis 365N wie in 3C aufweisen. Die Grafik-Multiprozessoren des Rechen-Clusters weisen mehrere Typen von Ganzzahl- und Fließkomma-Logikeinheiten auf, die Rechenoperationen mit einer Reihe von Präzisionen durchführen können, darunter auch solche, die sich für Berechnungen für maschinelles Lernen eignen. Zum Beispiel kann zumindest ein Teilsatz der Gleitkommaeinheiten in jedem der Verarbeitungscluster 706A bis 706H so konfiguriert sein, dass sie 16-Bit- oder 32-Bit-Gleitkommaoperationen durchführen, während ein anderer Teilsatz der Gleitkommaeinheiten so konfiguriert sein kann, dass sie 64-Bit-Gleitkommaoperationen durchführen.
  • Mehrere Instanzen der GPGPU 700 können für den Betrieb als Rechen-Cluster konfiguriert werden. Der vom Rechen-Cluster für die Synchronisierung und den Datenaustausch verwendete Kommunikationsmechanismus variiert je nach Ausführungsform. Zum Beispiel kommunizieren die mehreren Instanzen der GPGPU 700 über die Hostschnittstelle 702. In einer Ausführungsform weist die GPGPU 700 einen E/A-Hub 709 auf, der die GPGPU 700 mit einer GPU-Verbindung 710 koppelt, die eine direkte Verbindung zu anderen Instanzen der GPGPU ermöglicht. Die GPU-Verbindung 710 kann mit einer dedizierten GPU-zu-GPU-Brücke gekoppelt sein, die Kommunikation und Synchronisation zwischen mehreren Instanzen der GPGPU 700 ermöglicht. Optional kann die GPU-Verbindung 710 mit einer Hochgeschwindigkeitsverbindung gekoppelt sein, um Daten an andere GPGPUs oder Parallelprozessoren zu senden und zu empfangen. Die mehreren Instanzen der GPGPU 700 können sich in separaten Datenverarbeitungssystemen befinden und über eine Netzwerkeinrichtung kommunizieren, die über die Hostschnittstelle 702 zugänglich ist. Die GPU-Verbindung 710 kann so konfiguriert sein, dass sie zusätzlich oder alternativ zur Hostschnittstelle 702 eine Verbindung zu einem Hostprozessor ermöglicht.
  • Während die dargestellte Konfiguration der GPGPU 700 für das Training von neuronalen Netzen konfiguriert werden kann, kann eine alternative Konfiguration der GPGPU 700 für den Einsatz innerhalb einer Inferenzfindungsplattform mit hoher Leistung oder niedrigem Stromverbrauch konfiguriert werden. In einer Inferenzfindungskonfiguration weist die GPGPU 700 im Vergleich zur Trainingskonfiguration weniger der Verarbeitungscluster 706A bis 706H auf. Zusätzlich kann sich dem Speicher 714A bis 714B zugehörige Speichertechnologie zwischen Inferenzfindungs- und Trainingskonfigurationen unterscheiden. In einer Ausführungsform kann die Inferenzfindungskonfiguration der GPGPU 700 inferenzfindungsspezifische Anweisungen unterstützen. Beispielsweise kann eine Inferenzfindungskonfiguration Unterstützung für eine oder mehrere 8-Bit-Ganzzahl-Punktprodukt-Anweisungen bieten, die üblicherweise bei Inferenzfindungsoperationen für eingesetzte neuronale Netze verwendet werden.
  • 8 veranschaulicht ein Multi-GPU-Datenverarbeitungssystem 800. Das Multi-GPU-Datenverarbeitungssystem 800 kann einen Prozessor 802 aufweisen, der über einen Hostschnittstellen-Switch 804 mit mehreren GPGPUs 806A bis 806D verbunden ist. Der Hostschnittstellen-Switch 804 kann eine PCI-Express-Switch-Einrichtung sein, die den Prozessor 802 an einen PCI-Express-Bus koppelt, über den der Prozessor 802 mit dem Satz von GPGPUs 806A bis 806D kommunizieren kann. Jede der mehreren GPGPUs 806A bis 806D kann eine Instanz der GPGPU 700 aus 7 sein. Die GPGPUs 806A bis 806D können über einen Satz von Hochgeschwindigkeits-Punktzu-Punkt-GPU-zu-GPU-Verbindungen 816 miteinander verbunden sein. Die Hochgeschwindigkeits-GPU-zu-GPU-Verbindungen können mit jeder der GPGPUs 806A bis 806D über eine dedizierte GPU-Verbindung verbunden sein, z.B. die GPU-Verbindung 710 wie in 7. Die P2P-GPU-Verbindungen 816 ermöglichen eine direkte Kommunikation zwischen den einzelnen GPGPUs 806A bis 806D, ohne dass eine Kommunikation über den Hostschnittstellenbus erforderlich ist, an den der Prozessor 802 angeschlossen ist. Wenn der GPU-zu-GPU-Verkehr auf die P2P-GPU-Verbindungen geleitet wird, bleibt der Hostschnittstellenbus für den Systemspeicherzugriff oder für die Kommunikation mit anderen Instanzen des Multi-GPU-Datenverarbeitungssystems 800 verfügbar, beispielsweise über eine oder mehrere Netzwerkeinrichtungen. Während in 8 die GPGPUs 806A bis 806D über den Hostschnittstellen-Switch 804 mit dem Prozessor 802 verbunden sind, kann der Prozessor 802 alternativ eine direkte Unterstützung für die P2P-GPU-Verbindungen 816 aufweisen und direkt mit den GPGPUs 806A bis 806D verbunden sein. In einer Ausführungsform ermöglicht die P2P-GPU-Verbindung 816, dass das Multi-GPU-Datenverarbeitungssystem 800 als eine einzige logische GPU arbeitet.
  • Implementierungen Neuronaler Netze für Maschinelles Lernen
  • Die Computerarchitektur, die vorliegend bereitgestellt wird, kann dafür konfiguriert sein, die Arten von Parallelverarbeitung durchzuführen, die sich besonders für das Training und den Einsatz neuronaler Netze für maschinelles Lernen eignen. Ein neuronales Netz kann als ein Netz aus Funktionen verallgemeinert werden, die in einer Graphenbeziehung stehen. Wie im Fachgebiet bekannt ist, gibt es viele Arten der Implementierung neuronaler Netze, die beim maschinellen Lernen verwendet werden. Ein beispielhafter Typ eines neuronalen Netzes ist das Feedforward-Netz, wie zuvor beschrieben.
  • Ein zweiter beispielhafter Typ eines neuronalen Netzes ist das neuronale Faltungsnetz (CNN). Ein CNN ist ein spezialisiertes neuronales Feedforward-Netz zur Verarbeitung von Daten mit einer bekannten, gitterartigen Topologie, wie beispielsweise Bilddaten. Dementsprechend werden CNNs üblicherweise für die Berechnung von Bildverarbeitungs- und Bilderkennungsanwendungen eingesetzt, sie können aber auch für andere Arten der Mustererkennung wie beispielsweise die Verarbeitung gesprochener und geschriebener Sprache verwendet werden. Die Knoten in der CNN-Eingabeschicht sind in einem Satz von „Filtern“ organisiert (Merkmalsdetektoren, die von den rezeptiven Feldern in der Netzhaut inspiriert sind), und die Ausgabe jedes Satzes von Filtern wird an Knoten in aufeinanderfolgenden Schichten des Netzes propagiert. Die Berechnungen für ein CNN umfassen die Anwendung der mathematischen Operation „Faltung“ auf jedes Filter, um die Ausgabe dieses Filters zu erzeugen. Die Faltung ist eine spezielle Art der mathematischen Operation, bei der zwei Funktionen eine dritte Funktion erzeugen, die eine modifizierte Version einer der beiden ursprünglichen Funktionen ist. In der Terminologie von Faltungsnetzen kann die erste Funktion der Faltung als Eingabe bezeichnet werden, während die zweite Funktion als Faltungskernel bezeichnet werden kann. Die Ausgabe kann als Merkmalskarte bezeichnet werden. Die Eingabe für eine Faltungsschicht kann beispielsweise ein mehrdimensionales Array von Daten sein, das die verschiedenen Farbkomponenten eines Eingabebilds definiert. Der Faltungskernel kann ein mehrdimensionales Array von Parametern sein, wobei die Parameter durch den Trainingsprozess für das neuronale Netz angepasst werden.
  • Rekurrente neuronale Netze (RNNs) sind eine Familie von neuronalen Feedforward-Netzen, die Feedback-Verbindungen zwischen Schichten umfassen. RNNs ermöglichen die Modellierung sequenzieller Daten, indem sie Parameterdaten über verschiedene Teile des neuronalen Netzes hinweg teilen. Die Architektur für ein RNN weist Zyklen auf. Die Zyklen stellen den Einfluss eines gegenwärtigen Wertes einer Variablen auf ihren eigenen Wert zu einem zukünftigen Zeitpunkt dar, da zumindest ein Teil der Ausgabedaten des RNN als Feedback für die Verarbeitung nachfolgender Eingaben in einer Sequenz verwendet wird. Diese Eigenschaft macht RNNs besonders nützlich für die Sprachverarbeitung, da Sprachdaten sehr variabel zusammengesetzt sein können.
  • Die nachfolgenden Figuren zeigen beispielhafte Feedforward-, CNN- und RNN-Netze und beschreiben einen allgemeinen Prozess für das jeweilige Training und den Einsatz jedes dieser Netztypen. Es versteht sich, dass diese Beschreibungen beispielhaft und nicht einschränkend für jede vorliegend beschriebene konkrete Ausführungsform sind und die dargestellten Konzepte grundsätzlich auf tiefe neuronale Netze und Methoden des maschinellen Lernens im Allgemeinen angewendet werden können.
  • Die vorstehend beschriebenen beispielhaften neuronalen Netze können verwendet werden, um Deep Learning durchzuführen. Deep Learning ist maschinelles Lernen mit tiefen neuronalen Netzen. Die beim Deep Learning verwendeten tiefen neuronalen Netze sind künstliche neuronale Netze, die aus mehreren verborgenen Schichten bestehen, im Gegensatz zu flachen neuronalen Netzen, die nur eine einzige verborgene Schicht aufweisen. Tiefere neuronale Netze sind im Allgemeinen rechenintensiver zu trainieren. Die zusätzlichen verborgenen Schichten des Netzes ermöglichen jedoch eine mehrstufige Mustererkennung, die im Vergleich zu flachen maschinellen Lernverfahren zu einem geringeren Ausgabefehler führt.
  • Tiefe neuronale Netze, die beim Deep Learning verwendet werden, umfassen typischerweise ein Front-End-Netz zur Durchführung der Merkmalserkennung, das mit einem Back-End-Netz gekoppelt ist, das ein mathematisches Modell darstellt, das Operationen (z.B. Objektklassifizierung, Spracherkennung usw.) auf Grundlage der dem Modell bereitgestellten Merkmalsdarstellung durchführen kann. Deep Learning ermöglicht maschinelles Lernen, ohne dass für das Modell eine manuelle Merkmalskonstruktion durchgeführt werden muss. Stattdessen können tiefe neuronale Netze Merkmale basierend auf statistischen Strukturen oder Korrelationen innerhalb der Eingabedaten lernen. Die gelernten Merkmale können einem mathematischen Modell bereitgestellt werden, das die erkannten Merkmale auf eine Ausgabe abbilden kann. Das mathematische Modell, das vom Netzwerk verwendet wird, ist in der Regel auf die jeweilige Aufgabe spezialisiert, und es werden unterschiedliche Modelle für unterschiedliche Aufgaben verwendet.
  • Sobald das neuronale Netz strukturiert ist, kann ein Lernmodell auf das Netz angewendet werden, um das Netz für die Ausführung bestimmter Aufgaben zu trainieren. Das Lernmodell beschreibt, wie die Gewichtungen innerhalb des Modells angepasst werden, um den Ausgabefehler des Netzes zu verringern. Rückwärtspropagation von Fehlern ist ein gängiges Verfahren zum Trainieren neuronaler Netze. Ein Eingabevektor wird dem Netz zur Verarbeitung bereitgestellt. Die Ausgabe des Netzes wird mit Hilfe einer Verlustfunktion mit der gewünschten Ausgabe verglichen, und für jedes der Neuronen in der Ausgabeschicht wird ein Fehlerwert berechnet. Die Fehlerwerte werden dann rückwärts propagiert, bis jedes Neuron einen zugehörigen Fehlerwert hat, der in etwa seinen Beitrag zur ursprünglichen Ausgabe darstellt. Das Netz kann dann aus diesen Fehlern lernen, indem es einen Algorithmus wie beispielsweise den stochastischen Gradientenabstiegsalgorithmus verwendet, um die Gewichtungen des neuronalen Netzes zu aktualisieren.
  • 9A bis 9B veranschaulichen ein beispielhaftes neuronales Faltungsnetz. 9A veranschaulicht verschiedene Schichten innerhalb eines CNN. Wie in 9A gezeigt, kann ein beispielhaftes CNN, das zur Modellierung von Bildverarbeitung verwendet wird, eine Eingabe 902 empfangen, die die Rot-, Grün- und Blau- (RGB-) Komponenten eines Eingabebilds beschreibt. Die Eingabe 902 kann von mehreren Faltungsschichten (z.B. Faltungsschicht 904, Faltungsschicht 906) verarbeitet werden. Die Ausgabe der mehreren Faltungsschichten kann wahlweise von einem Satz vollständig verbundener Schichten 908 verarbeitet werden. Neuronen in einer vollständig verbundenen Schicht haben vollständige Verbindungen zu allen Aktivierungen in der vorherigen Schicht, wie vorstehend für ein Feedforward-Netz beschrieben. Die Ausgabe der vollständig verbundenen Schichten 908 kann verwendet werden, um ein Ausgabeergebnis des Netzes zu erzeugen. Die Aktivierungen innerhalb der vollständig verbundenen Schichten 908 können durch Matrixmultiplikation statt durch Faltung berechnet werden. Nicht alle CNN-Implementierungen verwenden vollständig verbundene Schichten 908. In einigen Implementierungen kann zum Beispiel die Faltungsschicht 906 die Ausgabe für das CNN erzeugen.
  • Die Faltungsschichten sind spärlich verbunden, was sich von der traditionellen Konfiguration neuronaler Netze unterscheidet, die in den voll verbundenen Schichten 908 zu finden ist. Traditionelle neuronale Netzschichten sind vollständig verbunden, so dass jede Ausgabeeinheit mit jeder Eingabeeinheit interagiert. Die Faltungsschichten sind jedoch spärlich verbunden, da die Ausgabe der Faltung eines Feldes (anstelle des jeweiligen Statuswertes jedes der Knoten im Feld) in die Knoten der nachfolgenden Schicht eingegeben wird, wie dargestellt. Die zu den Faltungsschichten gehörenden Kernel führen Faltungsoperationen durch, deren Ausgabe an die nächste Schicht gesendet wird. Die Dimensionalitätsreduktion, die innerhalb der Faltungsschichten durchgeführt wird, ist ein Aspekt, der es dem CNN ermöglicht, zur Verarbeitung großer Bilder zu skalieren.
  • 9B veranschaulicht beispielhafte Rechenstufen innerhalb einer Faltungsschicht eines CNN. Die Eingabe in eine Faltungsschicht 912 eines CNN kann in drei Stufen einer Faltungsschicht 914 verarbeitet werden. Die drei Stufen können eine Faltungsstufe 916, eine Detektorstufe 918 und eine Pooling-Stufe 920 umfassen. Die Faltungsschicht 914 kann dann Daten an eine nachfolgende Faltungsschicht ausgeben. Die letzte Faltungsschicht des Netzes kann Ausgabe-Merkmalskartendaten generieren oder Eingaben für eine vollständig verbundene Schicht bereitstellen, beispielsweise um einen Klassifizierungswert für die Eingabe in das CNN zu erzeugen.
  • In der Faltungsstufe 916 werden mehrere Faltungen parallel durchgeführt, um einen Satz linearer Aktivierungen zu erzeugen. Die Faltungsstufe 916 kann eine affine Transformation enthalten, d.h. eine beliebige Transformation, die als lineare Transformation plus eine Translation angegeben werden kann. Affine Transformationen umfassen Rotationen, Translationen, Skalierungen und Kombinationen dieser Transformationen. Die Faltungsstufe berechnet die Ausgabe von Funktionen (z.B. Neuronen), die mit bestimmten Regionen in der Eingabe verbunden sind, die als die dem Neuron zugeordnete lokale Region bestimmt werden können. Die Neuronen berechnen ein Punktprodukt zwischen den Gewichtungen der Neuronen und der Region in der lokalen Eingabe, mit der die Neuronen verbunden sind. Die Ausgabe der Faltungsstufe 916 definiert einen Satz linearer Aktivierungen, die von aufeinanderfolgenden Stufen der Faltungsschicht 914 verarbeitet werden.
  • Die linearen Aktivierungen können von einer Detektorstufe 918 verarbeitet werden. In der Detektorstufe 918 wird jede lineare Aktivierung durch eine nichtlineare Aktivierungsfunktion verarbeitet. Die nichtlineare Aktivierungsfunktion erhöht die nichtlinearen Eigenschaften des Gesamtnetzes, ohne die rezeptiven Felder der Faltungsschicht zu beeinflussen. Es können verschiedene Arten von nichtlinearen Aktivierungsfunktionen verwendet werden. Ein spezieller Typ ist die gleichgerichtete lineare Einheit (Rectified Linear Unit, ReLU), die eine Aktivierungsfunktion verwendet, die als f(x) = max(0, x) definiert ist, so dass die Aktivierung bei Null begrenzt wird.
  • Die Pooling-Stufe 920 verwendet eine Pooling-Funktion, die die Ausgabe der Faltungsschicht 906 durch eine zusammenfassende Statistik der nahegelegenen Ausgaben ersetzt. Die Pooling-Funktion kann verwendet werden, um Translationsinvarianz in das neuronale Netz einzuführen, so dass kleine Translationen der Eingabe die gepoolten Ausgaben nicht verändern. Die Invarianz gegenüber lokaler Translation kann in Szenarien nützlich sein, in denen das Vorhandensein eines Merkmals in den Eingabedaten wichtiger ist als die genaue Position des Merkmals. Während der Pooling-Stufe 920 können verschiedene Arten von Pooling-Funktionen verwendet werden, darunter Max-Pooling, Average-Pooling und L2-Norm-Pooling. Zudem weisen einige CNN-Implementierungen keine Pooling-Stufe auf. Stattdessen ersetzen solche Implementierungen eine zusätzliche Faltungsstufe, die eine erhöhte Schrittweite relativ zu den vorherigen Faltungsstufen hat.
  • Die Ausgabe der Faltungsschicht 914 kann dann von der nächsten Schicht 922 verarbeitet werden. Die nächste Schicht 922 kann eine zusätzliche Faltungsschicht oder eine der vollständig verbundenen Schichten 908 sein. Zum Beispiel kann die erste Faltungsschicht 904 aus 9A an die zweite Faltungsschicht 906 ausgegeben werden, während die zweite Faltungsschicht an eine erste Schicht der vollständig verbundenen Schichten 908 ausgegeben werden kann.
  • 10 veranschaulicht ein beispielhaftes rekurrentes neuronales Netz 1000. In einem rekurrenten neuronalen Netz (RNN) beeinflusst der vorherige Status des Netzes die Ausgabe des aktuellen Status des Netzes. RNNs können auf verschiedene Weise mit verschiedenen Funktionen aufgebaut werden. Bei der Verwendung von RNNs geht es im Allgemeinen um die Verwendung mathematischer Modelle zur Vorhersage der Zukunft auf Grundlage einer vorherigen Sequenz von Eingaben. Ein RNN kann beispielsweise zur statistischen Sprachmodellierung verwendet werden, um ein kommendes Wort anhand einer vorherigen Wortfolge vorherzusagen. Das dargestellte RNN 1000 kann beschrieben werden mit einer Eingangsschicht 1002, die einen Eingabevektor empfängt, verborgenen Schichten 1004 zur Implementierung einer rekurrenten Funktion, einem Feedback-Mechanismus 1005, um einen „Speicher“ vorheriger Status zu ermöglichen, und einer Ausgabeschicht 1006 zur Ausgabe eines Ergebnisses. Das RNN 1000 arbeitet auf Grundlage von Zeitschritten. Der Status des RNN zu einem bestimmten Zeitschritt wird auf Grundlage des vorherigen Zeitschritts über den Feedback-Mechanismus 1005 beeinflusst. Für einen bestimmten Zeitschritt wird der Status der verborgenen Schichten 1004 durch den vorherigen Status und die Eingabe im aktuellen Zeitschritt definiert. Eine anfängliche Eingabe (x1) in einem ersten Zeitschritt kann von der verborgenen Schicht 1004 verarbeitet werden. Eine zweite Eingabe (x2) kann von der verborgenen Schicht 1004 unter Verwendung von Zustandsinformationen verarbeitet werden, die bei der Verarbeitung der anfänglichen Eingabe (x1) bestimmt wurden. Ein gegebener Status kann berechnet werden als st = f(Uxt + Wst-1), wobei U und W Parametermatrizen sind. Die Funktion f ist in der Regel eine Nichtlinearität, wie beispielsweise die hyperbolische Tangensfunktion (Tanh) oder eine Variante der Gleichrichterfunktion f(x) = max(0, x). Die konkrete mathematische Funktion, die in den verborgenen Schichten 1004 verwendet wird, kann jedoch abhängig von den konkreten Implementierungsdetails des RNN 1000 variieren.
  • Zusätzlich zu den beschriebenen grundlegenden CNN- und RNN-Netzen kann auch Beschleunigung für Variationen dieser Netze möglich sein. Ein Beispiel für eine RNN-Variante ist das Long-Short-Term-Memory- (LSTM-) RNN. LSTM-RNNs sind in der Lage, langfristige Abhängigkeiten zu lernen, die für die Verarbeitung längerer Sprachsequenzen notwendig sein können. Eine Variante des CNN ist ein Convolutional Deep Belief Network, das eine ähnliche Struktur wie ein CNN hat und auf ähnliche Weise wie ein Deep Belief Network trainiert wird. Ein Deep Belief Network (DBN) ist ein generatives neuronales Netz, das aus mehreren Schichten von stochastischen (zufälligen) Variablen besteht. DBNs können schichtweise mit Greedy Unsupervised Learning trainiert werden. Die gelernten Gewichtungen des DBN können dann zum Vortraining von neuronalen Netzen verwendet werden, indem ein optimaler Anfangssatz von Gewichtungen für das neuronale Netz bestimmt wird. In weiteren Ausführungsformen ist die Beschleunigung für verstärkendes Lernen aktiviert. Beim verstärkenden Lernen lernt ein künstlicher Agent durch Interaktion mit seiner Umgebung. Der Agent ist so konfiguriert, dass er bestimmte Ziele optimiert, um kumulative Belohnungen zu maximieren.
  • 11 veranschaulicht Training und Einsatz eines tiefen neuronalen Netzes. Nachdem ein gegebenes Netz für eine Aufgabe strukturiert wurde, wird das neuronale Netz anhand eines Trainingsdatensatzes 1102 trainiert. Es wurden verschiedene Trainings-Frameworks 1104 entwickelt, die eine Hardwarebeschleunigung des Trainingsprozesses ermöglichen. Beispielsweise kann das Maschinenlern-Framework 604 aus 6 als Trainings-Framework 604 konfiguriert sein. Das Trainings-Framework 604 kann sich in ein untrainiertes neuronales Netz 1106 einklinken und ermöglichen, dass das untrainierte neuronale Netz mit den vorliegend beschriebenen Parallelverarbeitungsressourcen trainiert wird, um ein trainiertes neuronales Netz 1108 zu erzeugen.
  • Um den Trainingsprozess zu starten, können die Anfangsgewichtungen zufällig oder durch Vortraining mit einem Deep Belief Network gewählt werden. Der Trainingszyklus kann dann entweder überwacht oder unüberwacht durchgeführt werden.
  • Überwachtes Lernen ist eine Lernmethode, bei der das Training als vermittelte Operation durchgeführt wird, z.B. wenn der Trainingsdatensatz 1102 Eingaben enthält, die mit der gewünschten Ausgabe für die Eingabe gepaart sind, oder wenn der Trainingsdatensatz Eingaben mit bekannter Ausgabe enthält und die Ausgabe des neuronalen Netzes manuell bewertet wird. Das Netz verarbeitet die Eingaben und vergleicht die resultierenden Ausgaben mit einem Satz von erwarteten oder gewünschten Ausgaben. Fehler werden dann durch das System zurück propagiert. Das Trainings-Framework 1104 kann die Gewichtungen anpassen, die das untrainierte neuronale Netz 1106 steuern. Das Trainings-Framework 1104 kann Werkzeuge bereitstellen, um zu überwachen, wie gut das untrainierte neuronale Netz 1106 zu einem Modell hin konvergiert, das geeignet ist, korrekte Antworten basierend auf bekannten Eingabedaten zu erzeugen. Der Trainingsprozess findet wiederholt statt, da die Gewichtungen des Netzwerks angepasst werden, um die vom neuronalen Netz generierte Ausgabe zu verfeinern. Der Trainingsprozess kann fortgesetzt werden, bis das neuronale Netz eine statistisch gewünschte Genauigkeit erreicht, die mit einem trainierten neuronalen Netz 1108 verbunden ist. Das trainierte neuronale Netz 1108 kann dann eingesetzt werden, um eine beliebige Anzahl von Maschinenlernoperationen zu implementieren, um ein Inferenzergebnis 1114 auf Grundlage der Eingabe neuer Daten 1112 zu erzeugen.
  • Unüberwachtes Lernen ist eine Lernmethode, bei der das Netz versucht, sich selbst anhand von nicht gekennzeichneten Daten zu trainieren. Beim unüberwachten Lernen umfasst der Trainingsdatensatz 1102 also Eingabedaten ohne zugehörige Ausgabedaten. Das untrainierte neuronale Netz 1106 kann Gruppierungen innerhalb der ungekennzeichneten Eingaben lernen und bestimmen, wie einzelne Eingaben mit dem Gesamtdatensatz zusammenhängen. Unüberwachtes Training kann verwendet werden, um eine selbstorganisierende Karte zu erzeugen, die eine Art trainiertes neuronales Netz 1108 ist, das in der Lage ist, nützliche Operationen zur Reduzierung der Dimensionalität von Daten durchzuführen. Unüberwachtes Training kann auch zur Erkennung von Anomalien verwendet werden, was die Identifizierung von Datenpunkten in einem Eingabedatensatz ermöglicht, die von den normalen Mustern der Daten abweichen.
  • Es können auch Variationen von überwachtem und unüberwachtem Training eingesetzt werden. Semi-überwachtes Lernen ist eine Methode, bei der der Trainingsdatensatz 1102 eine Mischung aus gekennzeichneten und ungekennzeichneten Daten mit gleicher Verteilung umfasst. Inkrementelles Lernen ist eine Variante des überwachten Lernens, bei der die Eingabedaten kontinuierlich verwendet werden, um das Modell weiter zu trainieren. Inkrementelles Lernen ermöglicht es dem trainierten neuronalen Netz 1108, sich an die neuen Daten 1112 anzupassen, ohne das Wissen zu vergessen, das dem Netz beim anfänglichen Training vermittelt wurde.
  • Ob überwacht oder unüberwacht, der Trainingsprozess für besonders tiefe neuronale Netze kann für einen einzelnen Rechenknoten zu rechenintensiv sein. Anstatt einen einzelnen Rechenknoten zu verwenden, kann ein verteiltes Netz aus Rechenknoten verwendet werden, um den Trainingsprozess zu beschleunigen.
  • 12A ist ein Blockschaubild, das verteiltes Lernen (distributed learning) veranschaulicht. Verteiltes Lernen ist ein Trainingsmodell, das mehrere verteilte Rechenknoten verwendet, um ein überwachtes oder unüberwachtes Training eines neuronalen Netzes durchzuführen. Die verteilten Rechenknoten können jeweils einen oder mehrere Hostprozessoren und einen oder mehrere der Allzweck-Verarbeitungsknoten aufweisen, wie beispielsweise die hochparallele Allzweck-Grafikverarbeitungseinheit 700 wie in 7. Wie dargestellt, kann das verteilte Lernen mit Modellparallelität 1202, Datenparallelität 1204 oder einer Kombination aus Modell- und Datenparallelität 1206 durchgeführt werden.
  • Bei der Modellparallelität 1202 können verschiedene Rechenknoten in einem verteilten System Trainingsberechnungen für verschiedene Teile eines einzelnen Netzes durchführen. Zum Beispiel kann jede Schicht eines neuronalen Netzes von einem anderen Verarbeitungsknoten des verteilten Systems trainiert werden. Zu den Vorteilen der Modellparallelität gehört die Möglichkeit, auf besonders große Modelle zu skalieren. Die Aufteilung der Berechnungen, die mit verschiedenen Schichten des neuronalen Netzes verbunden sind, ermöglicht das Training von sehr großen neuronalen Netzen, bei denen die Gewichteungen aller Schichten nicht in den Speicher eines einzelnen Rechenknotens passen würden. In einigen Fällen kann die Modellparallelität besonders nützlich sein, um ein unüberwachtes Training großer neuronaler Netze durchzuführen.
  • Bei der Datenparallelität 1204 haben die verschiedenen Knoten des verteilten Netzes eine vollständige Instanz des Modells, und jeder Knoten erhält einen anderen Teil der Daten. Die Ergebnisse aus den verschiedenen Knoten werden dann kombiniert. Obwohl verschiedene Ansätze zur Datenparallelität möglich sind, erfordern alle datenparallelen Trainingsansätze eine Methode zur Kombination der Ergebnisse und zur Synchronisierung der Modellparameter zwischen den einzelnen Knoten. Beispielhafte Ansätze zum Kombinieren von Daten sind Parameter-Mittelwertbildung und aktualisierungsbasierte Datenparallelität. Die Parameter-Mittelwertbildung trainiert jeden Knoten auf einen Teilsatz der Trainingsdaten und setzt die globalen Parameter (z.B. Gewichtungen, Verzerrungen) auf den Mittelwert der Parameter von jedem Knoten. Die Parameter-Mittelwertbildung verwendet einen zentralen Parameterserver, der die Parameterdaten pflegt. Die aktualisierungsbasierte Datenparallelität ist ähnlich wie die Parameter-Mittelwertbildung, außer dass
    anstelle der Übertragung von Parametern von den Knoten zum Parameterserver die Aktualisierungen des Modells übertragen werden. Zusätzlich kann die aktualisierungsbasierte Datenparallelität dezentral durchgeführt werden, wobei die Aktualisierungen komprimiert und zwischen den Knoten übertragen werden.
  • Die kombinierte Modell- und Datenparallelität 1206 kann beispielsweise in einem verteilten System implementiert werden, in dem jeder Rechenknoten mehrere GPUs aufweist. Jeder Knoten kann eine vollständige Instanz des Modells haben, wobei separate GPUs innerhalb jedes Knotens verwendet werden, um verschiedene Teile des Modells zu trainieren.
  • Verteiltes Training hat einen erhöhten Overhead im Vergleich zum Training auf einem einzelnen Rechner. Die vorliegend beschriebenen Parallelprozessoren und GPGPUs können jedoch jeweils verschiedene Methoden implementieren, um den Overhead des verteilten Trainings zu reduzieren, einschließlich Methoden, die eine Datenübertragung von GPU zu GPU mit hoher Bandbreite und eine beschleunigte Remote-Datensynchronisierung ermöglichen.
  • 12B ist ein Blockschaubild, das eine programmierbare Netzwerkschnittstelle 1210 und Datenverarbeitungseinheit veranschaulicht. Die programmierbare Netzwerkschnittstelle 1210 ist eine programmierbare Netzwerk-Engine, die zur Beschleunigung von netzwerkbasierten Rechenaufgaben innerhalb einer verteilten Umgebung verwendet werden kann. Die programmierbare Netzwerkschnittstelle 1210 kann über die Hostschnittstelle 1270 mit einem Hostsystem gekoppelt werden. Die programmierbare Netzwerkschnittstelle 1210 kann verwendet werden, um Netzwerk- oder Speicheroperationen für CPUs oder GPUs des Hostsystems zu beschleunigen. Das Host-System kann z.B. ein Knoten eines verteilten Lernsystems sein, mit dem ein verteiltes Training durchgeführt wird, wie beispielsweise in 12A dargestellt. Das Hostsystem kann auch ein Rechenzentrenknoten innerhalb eines Rechenzentrums sein.
  • In einer Ausführungsform kann der Zugriff auf einen entfernten Speicher mit Modelldaten durch die programmierbare Netzwerkschnittstelle 1210 beschleunigt werden. Zum Beispiel kann die programmierbare Netzwerkschnittstelle 1210 so konfiguriert werden, dass sie entfernte Speichereinrichtungen als lokale Speichereinrichtungen für das Hostsystem darstellt. Die programmierbare Netzwerkschnittstelle 1210 kann auch RDMA- (Remote Direct Memory Access) Operationen beschleunigen, die zwischen GPUs des Hostsystems mit GPUs entfernter Systeme durchgeführt werden. In einer Ausführungsform kann die programmierbare Netzwerkschnittstelle 1210 Speicherfunktionalität wie beispielsweise, ohne jedoch hierauf eingeschränkt zu sein, NVME-oF ermöglichen. Die programmierbare Netzwerkschnittstelle 1210 kann zudem Verschlüsselung, Datenintegrität, Komprimierung und andere Operationen für Fernspeicherung im Auftrag des Hostsystems beschleunigen, so dass Fernspeicherung sich den Latenzen von Speichereinrichtungen annähert, die direkt an das Hostsystem angeschlossen sind.
  • Die programmierbare Netzwerkschnittstelle 1210 kann zudem Ressourcenzuweisung und -verwaltung im Auftrag des Hostsystems durchführen. Speichersicherheitsoperationen können an die programmierbare Netzwerkschnittstelle 1210 ausgelagert und zusammen mit der Zuteilung und Verwaltung entfernter Speicherressourcen durchgeführt werden. Netzwerkbasierte Operationen zur Verwaltung des Zugriffs auf den entfernten Speicher, die sonst von einem Prozessor des Hostsystems ausgeführt würden, können stattdessen von der programmierbaren Netzwerkschnittstelle 1210 ausgeführt werden.
  • In einer Ausführungsform können Netzwerk- und/oder Datensicherheitsoperationen vom Hostsystem auf die programmierbare Netzwerkschnittstelle 1210 ausgelagert werden. Die Sicherheitsrichtlinien für einen Rechenzentrenknoten können von der programmierbaren Netzwerkschnittstelle 1210 statt von den Prozessoren des Hostsystems gehandhabt werden. Beispielsweise kann die programmierbare Netzwerkschnittstelle 1210 einen versuchten netzwerkbasierten Angriff (z. B. DDoS) auf das Hostsystem erkennen und abwehren und so verhindern, dass der Angriff die Verfügbarkeit des Hostsystems beeinträchtigt.
  • Die programmierbare Netzwerkschnittstelle 1210 kann ein Ein-Chip-System (SoC 1220) aufweisen, das ein Betriebssystem über mehrere Prozessorkerne 1222 ausführt. Die Prozessorkerne 1222 können Allzweck-Prozessor- (z.B. CPU-) Kerne umfassen. In einer Ausführungsform können die Prozessorkerne 1222 auch einen oder mehrere GPU-Kerne umfassen. Das SoC 1220 kann Anweisungen ausführen, die in einer Speichereinrichtung 1240 gespeichert sind. Eine Speichereinrichtung 1250 kann lokale Betriebssystemdaten speichern. Die Speichereinrichtung 1250 und die Speichereinrichtung 1240 können auch zum Zwischenspeichern entfernter Daten für das Hostsystem verwendet werden. Die Netzwerk-Ports 1260A bis 1260B ermöglichen eine Verbindung zu einem Netzwerk oder einem Fabric und erleichtern den Netzwerkzugriff für das SoC 1220 und, über die Hostschnittstelle 1270, für das Hostsystem. Die programmierbare Netzwerkschnittstelle 1210 kann auch eine E/A-Schnittstelle 1275 aufweisen, beispielsweise eine USB-Schnittstelle. Die E/A-Schnittstelle 1275 kann zur Kopplung externer Einrichtungen mit der programmierbaren Netzwerkschnittstelle 1210 oder als Debug-Schnittstelle verwendet werden. Die programmierbare Netzwerkschnittstelle 1210 weist zudem eine Verwaltungsschnittstelle 1230 auf, die es der Software auf der Hosteinrichtung ermöglicht, die programmierbare Netzwerkschnittstelle 1210 und/oder das SoC 1220 zu verwalten und zu konfigurieren. In einer Ausführungsform kann die programmierbare Netzwerkschnittstelle 1210 auch einen oder mehrere Beschleuniger oder GPUs 1245 aufweisen, um die Auslagerung von parallelen Rechenaufgaben aus dem SoC 1220, dem Hostsystem oder entfernten Systemen zu akzeptieren, die über die Netzwerkports 1260A bis 1260B gekoppelt sind.
  • Beispielhafte Maschinenlernanwendungen
  • Maschinelles Lernen kann zur Lösung einer Vielzahl von technologischen Problemen eingesetzt werden, darunter, ohne jedoch hierauf eingeschränkt zu sein, auf Computer Vision, autonomes Fahren und Navigation, Erkennung gesprochener Sprache und Sprachverarbeitung. Computer Vision ist traditionell eines der aktivsten Forschungsgebiete für Maschinenlernanwendungen. Die Anwendungen von Computer Vision reichen von der Reproduktion menschlicher visueller Fähigkeiten, wie z.B. dem Erkennen von Gesichtern, bis hin zur Schaffung neuer Kategorien visueller Fähigkeiten. Zum Beispiel können Computer-Vision-Anwendungen so konfiguriert werden, dass sie Schallwellen aus den Vibrationen erkennen, die in den in einem Video sichtbaren Objekten induziert werden. Parallelprozessor-beschleunigtes maschinelles Lernen ermöglicht es, Computer-Vision-Anwendungen mit wesentlich größeren Trainingsdatensätzen zu trainieren, als dies bisher möglich war, und ermöglicht es, Inferenzfindungssysteme mit Parallelprozessoren mit geringem Stromverbrauch einzusetzen.
  • Parallelprozessor-beschleunigtes maschinelles Lernen hat Anwendungen für autonomes Fahren, einschließlich Fahrspur- und Verkehrszeichenerkennung, Hindernisvermeidung, Navigation und Fahrkontrolle. Beschleunigte maschinelle Lernverfahren können zum Trainieren von Fahrmodellen auf der Grundlage von Datensätzen verwendet werden, die die entsprechenden Reaktionen auf bestimmte Trainingseingaben definieren. Die vorliegend beschriebenen Parallelprozessoren können ein schnelles Training der immer komplexeren neuronalen Netze ermöglichen, die für Lösungen zum autonomen Fahren verwendet werden, und ermöglichen den Einsatz von Inferenzfindungsprozessoren mit geringem Stromverbrauch in einer mobilen Plattform, die für die Integration in autonome Fahrzeuge geeignet ist.
  • Parallelprozessor-beschleunigte tiefe neuronale Netze haben Maschinenlernansätze für die automatische Spracherkennung (Automatic Speech Recognition, ASR) ermöglicht. ASR umfasst die Erstellung einer Funktion, die die wahrscheinlichste sprachliche Sequenz angesichts einer akustischen Eingabesequenz berechnet. Beschleunigtes maschinelles Lernen mit tiefen neuronalen Netzen hat es ermöglicht, die bisher für ASR verwendeten Hidden-Markov-Modelle (HMMs) und Gaußschen Mischmodelle (GMMs) zu ersetzen.
  • Parallelprozessor-beschleunigtes maschinelles Lernen kann auch zur Beschleunigung der Verarbeitung natürlicher Sprache verwendet werden. Automatische Lernverfahren können statistische Inferenzalgorithmen nutzen, um Modelle zu erzeugen, die robust gegenüber fehlerhaften oder ungewohnten Eingaben sind. Beispielhafte Anwendungen für natürliche Sprachprozessoren sind die automatische maschinelle Übersetzung zwischen menschlichen Sprachen.
  • Die für maschinelles Lernen verwendeten Parallelverarbeitungsplattformen können in Trainingsplattformen und Einsatzplattformen unterteilt werden. Trainingsplattformen sind in der Regel hochparallel und umfassen Optimierungen zur Beschleunigung von Multi-GPU-Einzelknoten-Training und Multi-Knoten-Multi-GPU-Training. Zu den beispielhaften Parallelprozessoren, die sich für das Training eignen, gehören die Allzweck-Grafikverarbeitungseinheit 700 aus 7 und das Multi-GPU-Datenverarbeitungssystem 800 aus 8. Eingesetzte Plattformen für maschinelles Lernen umfassen dagegen in der Regel Parallelprozessoren mit geringerem Stromverbrauch, die für den Einsatz in Produkten wie Kameras, autonomen Robotern und autonomen Fahrzeugen geeignet sind.
  • Zudem können Methoden des maschinellen Lernens zur Beschleunigung oder Verbesserung von Grafikverarbeitungsaktivitäten eingesetzt werden. Beispielsweise kann ein Modell für maschinelles Lernen darauf trainiert werden, die von einer GPU-beschleunigten Anwendung erzeugte Ausgabe zu erkennen und eine hochskalierte Version dieser Ausgabe zu erzeugen. Solche Techniken können eingesetzt werden, um die Erzeugung von hochauflösenden Bildern für eine Spieleanwendung zu beschleunigen. Verschiedene andere Aktivitäten in der Grafikpipeline können von der Verwendung von maschinellem Lernen profitieren. Beispielsweise können Modelle für maschinelles Lernen darauf trainiert werden, Tesselationsoperationen an Geometriedaten durchzuführen, um die Komplexität von Geometriemodellen zu erhöhen, so dass aus Geometrien mit relativ geringer Detailtiefe automatisch eine feindetailierte Geometrie erzeugt werden kann.
  • 13 veranschaulicht ein beispielhaftes Inferenzfindungssystem auf einem Chip (SOC) 1300, das zur Durchführung von Inferenzfindung unter Verwendung eines trainierten Modells geeignet ist. Das SOC 1300 kann Verarbeitungskomponenten integrieren, darunter einen Medienprozessor 1302, einen Bildverarbeitungsprozessor 1304, eine GPGPU 1306 und einen Mehrkernprozessor 1308. Die GPGPU 1306 kann eine vorliegend beschriebene GPGPU sein, beispielsweise die GPGPU 700, und der Mehrkernprozessor 1308 kann ein vorliegend beschriebener Mehrkernprozessor sein, wie beispielsweise die Mehrkernprozessoren 405 bis 406. Das SOC 1300 kann zusätzlich einen On-Chip-Speicher 1305 aufweisen, der einen gemeinsamen On-Chip-Datenpool ermöglichen kann, auf den jede der Verarbeitungskomponenten zugreifen kann. Die Verarbeitungskomponenten können für einen stromsparenden Betrieb optimiert werden, um den Einsatz in einer Vielzahl von Plattformen für maschinelles Lernen zu ermöglichen, einschließlich autonomer Fahrzeuge und autonomer Roboter. Eine Implementierung des SOC 1300 kann zum Beispiel als Teil des Hauptsteuersystems für ein autonomes Fahrzeug verwendet werden. Wenn das SOC 1300 für den Einsatz in autonomen Fahrzeugen konfiguriert ist, ist das SOC so ausgelegt und konfiguriert, dass es die relevanten funktionalen Sicherheitsstandards des Einsatzlandes erfüllt.
  • Während des Betriebs können der Medienprozessor 1302 und der Bildverarbeitungsprozessor 1304 zusammenarbeiten, um Computer-Vision-Operationen zu beschleunigen. Der Medienprozessor 1302 kann die Decodierung mehrerer hochauflösender Videoströme (z.B. 4K, 8K) mit geringer Latenz ermöglichen. Die decodierten Videoströme können in einen Puffer im On-Chip-Speicher 1305 geschrieben werden. Der Bildverarbeitungsprozessor 1304 kann dann das decodierte Video analysieren und vorläufige Verarbeitungsoperationen an den Frames des decodierten Videos als Vorbereitung für die Verarbeitung der Frames mit einem trainierten Bilderkennungsmodell durchführen. Beispielsweise kann der Bildverarbeitungsprozessor 1304 die Faltungsoperationen für ein CNN beschleunigen, das zur Bilderkennung an den hochauflösenden Videodaten verwendet wird, während die Back-End-Modellberechnungen von der GPGPU 1306 durchgeführt werden.
  • Der Mehrkernprozessor 1308 kann Steuerlogik aufweisen, die bei der Sequenzierung und Synchronisierung von Datenübertragungen und gemeinsamen Speicheroperationen hilft, die vom Medienprozessor 1302 und dem Bildverarbeitungsprozessor 1304 durchgeführt werden. Der Mehrkernprozessor 1308 kann zudem als Anwendungsprozessor fungieren, um Softwareanwendungen auszuführen, die die Inferenzfindungs-Rechenfähigkeit der GPGPU 1306 nutzen können. Zum Beispiel kann zumindest ein Teil der Navigations- und Fahrlogik in Software implementiert werden, die auf dem Mehrkernprozessor 1308 ausgeführt wird. Solche Software kann direkt Rechenlasten an die GPGPU 1306 ausgeben oder die Rechenlasten können an den Mehrkernprozessor 1308 ausgegeben werden, der zumindest einen Teil dieser Operationen an die GPGPU 1306 auslagern kann.
  • Die GPGPU 1306 kann Rechencluster aufweisen, beispielsweise eine stromsparende Konfiguration der Verarbeitungscluster 706A bis 706H innerhalb der Allzweck-Grafikverarbeitungseinheit 700. Die Rechencluster innerhalb der GPGPU 1306 können Anweisungen unterstützen, die speziell für die Durchführung von Inferenzfindungsberechnungen in einem trainierten neuronalen Netz optimiert sind. Die GPGPU 1306 kann beispielsweise Anweisungen zur Durchführung von Berechnungen mit geringer Präzision wie 8-Bit- und 4-Bit-Ganzzahl-Vektoroperationen unterstützen.
  • Zusätzliche Systemübersicht
  • 14 ist ein Blockschaubild eines Verarbeitungssystems 1400. Die Elemente aus 14, die die gleichen oder ähnliche Namen wie die Elemente einer anderen vorliegend enthaltenen Figur haben, beschreiben die gleichen Elemente wie in den anderen Figuren, können in ähnlicher Weise arbeiten oder funktionieren, können die gleichen Komponenten umfassen und können mit anderen Einheiten verbunden sein, wie die, die vorliegend an anderer Stelle beschrieben sind, ohne jedoch hierauf eingeschränkt zu sein. Das System 1400 kann in einem Einzelprozessor-Desktop-System, einem Multiprozessor-Workstation-System oder einem Server-System mit einer großen Anzahl an Prozessoren 1402 oder Prozessorkernen 1407 verwendet werden. Das System 1400 kann eine Verarbeitungsplattform sein, die in einer integrierten Ein-Chip-System- (SoC-) Schaltung für den Einsatz in mobilen, tragbaren oder eingebetteten Einrichtungen wie beispielsweise in Internet-of-Things- (IoT-) Einrichtungen mit drahtgebundener oder drahtloser Konnektivität zu einem lokalen oder einem Weitverkehrsnetz integriert ist.
  • Das System 1400 kann ein Verarbeitungssystem mit Komponenten sein, die denen aus 1 entsprechen. In verschiedenen Konfigurationen können z.B. der/die Prozessor(en) 1402 oder der/die Prozessorkern(e) 1407 dem/den Prozessor(en) 102 aus 1 entsprechen. Der/die Grafikprozessor(en) 1408 kann/können dem/den Parallelprozessor(en) 112 aus 1 entsprechen. Der externe Grafikprozessor 1418 kann eine der Add-In-Einrichtungen 120 aus 1 sein.
  • Das System 1400 kann Folgendes aufweisen, damit gekoppelt oder darin integriert sein: eine Server-basierte Spielplattform; eine Spielkonsole, darunter eine Spiel- und Medienkonsole; eine mobile Spielkonsole, eine tragbare Spielkonsole oder eine Online-Spielkonsole. Das System 1400 kann Teil eines Mobiltelefons, eines Smartphones, einer Tablet-Datenverarbeitungseinrichtung oder einer mobilen Einrichtung mit Internet-Anbindung wie beispielsweise eines Laptops mit geringer interner Speicherkapazität sein. Das Verarbeitungssystem 1400 kann auch Folgendes aufweisen, damit gekoppelt oder darin integriert sein: eine tragbare Einrichtung wie beispielsweise eine Smartwatch; eine intelligente Brille oder Kleidung, die mit Augmented-Reality- (AR-) oder Virtual-Reality- (VR-) Funktionen erweitert ist, um visuelle, akustische oder taktile Ausgaben bereitzustellen, um visuelle, akustische oder taktile Erfahrung der realen Welt zu ergänzen oder anderweitig Text, Audio, Grafiken, Video, holografische Bilder oder Video- oder taktiles Feedback bereitzustellen; eine andere Augmented-Reality- (AR-) Einrichtung; oder eine andere Virtual-Reality- (VR-) Einrichtung. Das Verarbeitungssystem 1400 kann eine Fernseh- oder Set-Top-Box-Einrichtung aufweisen oder ein Teil davon sein. Das System 1400 kann ein selbstfahrendes Fahrzeug wie beispielsweise einen Bus, einen Sattelschlepper, ein Auto, ein Motor- oder Elektrorad, ein Flugzeug oder ein Gleitflugzeug (oder eine beliebige Kombination aus diesen) aufweisen, mit diesen gekoppelt oder in diese integriert sein. Das selbstfahrende Fahrzeug kann das System 1400 verwenden, um die um das Fahrzeug herum erfasste Umgebung zu verarbeiten.
  • Der eine oder die mehreren Prozessoren 1402 können jeweils einen oder mehrere Prozessorkerne 1407 zur Verarbeitung von Befehlen aufweisen, die bei ihrer Ausführung Operationen für System- oder Nutzersoftware durchführen. Der mindestens eine des einen oder der mehreren Prozessorkerne 1407 kann dafür konfiguriert sein, einen bestimmten Befehlssatz 1409 auszuführen. Der Befehlssatz 1409 kann Datenverarbeitung mit komplexem Befehlssatz (Complex Instruction Set Computing, CISC), Datenverarbeitung mit reduziertem Befehlssatz (Reduced Instruction Set Computing, RISC) oder Datenverarbeitung über ein überlanges Befehlswort (Very Long Instruction Word, VLIW) erleichtern. Ein oder mehrere Prozessorkerne 1407 können einen anderen Befehlssatz 1409 verarbeiten, der Anweisungen zum Erleichtern der Emulation anderer Befehlssätze aufweisen kann. Der Prozessorkern 1407 kann zudem andere Verarbeitungseinrichtungen aufweisen, beispielsweise einen digitalen Signalprozessor (DSP).
  • Der Prozessor 1402 kann einen Cachespeicher 1404 aufweisen. Je nach Architektur kann der Prozessor 1402 über einen einzigen internen Cache oder mehrere interne Cache-Level verfügen. In einigen Ausführungsformen wird der Cachespeicher von verschiedenen Komponenten des Prozessors 1402 gemeinsam genutzt. In einigen Ausführungsformen verwendet der Prozessor 1402 zudem einen externen Cache (z.B. einen Level-3- (L3-) Cache oder Last-Level-Cache (LLC)) (nicht gezeigt), der von Prozessorkernen 1407 mittels bekannter Cache-Kohärenz-Methoden gemeinsam verwendet werden kann. Zusätzlich kann in dem Prozessor 1402 eine Registerdatei 1406 umfasst sein, die verschiedene Registertypen zum Speichern verschiedener Datentypen (z.B. Ganzzahlenregister, Gleitkommaregister, Statusregister und ein Befehlszeigerregister) aufweist. Bei einigen Registern kann es sich um Allzweckregister handeln, während andere Register spezifisch für den Aufbau des Prozessors 1402 sein können.
  • Der eine oder die mehreren Prozessoren 1402 können mit einem oder mehreren Schnittstellenbussen 1410 gekoppelt sein, um Kommunikationssignale wie beispielsweise Adress-, Daten- oder Steuersignale zwischen dem Prozessor 1402 und anderen Komponenten im System 1400 zu übertragen. In einer dieser Ausführungsformen kann es sich bei dem Schnittstellenbus 1410 um einen Prozessorbus wie beispielsweise eine Version des Direct-Media-Interface- (DMI-) Busses handeln. Prozessorbusse sind jedoch nicht auf den DMI-Bus eingeschränkt und können einen oder mehrere Peripheral-Component-Interconnect-Busse (z.B. PCI, PCI Express), Speicherbusse oder andere Arten von Schnittstellenbussen umfassen. Beispielsweise können der oder die Prozessoren 1402 einen integrierten Speichercontroller 1416 und einen Platform Controller Hub 1430 aufweisen. Der Speichercontroller 1416 erleichtert Kommunikation zwischen einer Speichereinrichtung und anderen Komponenten des Systems 1400, während der Platform Controller Hub (PCH) 1430 Verbindungen mit E/A-Einrichtungen über einen lokalen E/A-Bus bereitstellt.
  • Die Speichereinrichtung 1420 kann eine dynamische Direktzugriffsspeicher- (DRAM-) Einrichtung, eine statische Direktzugriffsspeicher-(SRAM-) Einrichtung, eine Flashspeichereinrichtung, eine Phasenänderungsspeichereinrichtung oder eine andere Speichereinrichtung mit geeigneter Leistung sein, um als Prozessspeicher zu dienen. Beispielsweise kann die Speichereinrichtung 1420 als Systemspeicher für das System 1400 arbeiten, um Daten 1422 und Anweisungen 1421 zur Verwendung zu speichern, wenn der eine oder die mehreren Prozessoren 1402 eine Anwendung oder einen Prozess ausführen. Der Speichercontroller 1416 ist zudem mit einem optionalen externen Grafikprozessor 1418 gekoppelt, der mit dem einen oder den mehreren Grafikprozessoren 1408 in den Prozessoren 1402 kommunizieren kann, um Grafik- und Medienoperationen durchzuführen. In einigen Ausführungsformen können Grafik-, Medien- und/oder Rechenoperationen durch einen Beschleuniger 1412 unterstützt werden, bei dem es sich um einen Koprozessor handelt, der dafür konfiguriert sein kann, einen spezialisierten Satz von Grafik-, Medien- oder Rechenoperationen durchzuführen. Beispielsweise kann es sich bei dem Beschleuniger 1412 um einen Matrix-Multiplikationsbeschleuniger handeln, der verwendet wird, um Maschinenlern- oder Rechenoperationen zu optimieren. Bei dem Beschleuniger 1412 kann es sich um einen Strahlverfolgungs- (Ray-Tracing-) Beschleuniger handeln, der verwendet werden kann, um zusammen mit dem Grafikprozessor 1408 Strahlverfolgungsoperationen durchzuführen. In einer Ausführungsform kann anstelle des oder zusammen mit dem Beschleuniger 1412 ein externer Beschleuniger 1419 verwendet werden.
  • Es kann eine Anzeigeeinrichtung 1411 vorgesehen sein, die mit dem/den Prozessor(en) 1402 verbunden sein kann. Bei der Anzeigeeinrichtung 1411 kann es sich um eine interne Anzeigeeinrichtung wie in einer mobilen elektronischen Einrichtung oder einer Laptop-Einrichtung und/oder um eine über eine Anzeigenschnittstelle (z.B. DisplayPort usw.) angeschlossene externe Anzeigeeinrichtung handeln. Bei der Anzeigeeinrichtung 1411 kann es sich um eine am Kopf befestigbare Anzeige (head mounted display, HMD) wie beispielsweise eine stereoskopische Anzeigeeinrichtung zur Verwendung in Virtual-Reality- (VR-) Anwendungen oder Augmented-Reality- (AR-) Anwendungen handeln.
  • Der Platform-Controller-Hub 1430 kann es Peripheriegeräten ermöglichen, sich über einen Hochgeschwindigkeits-E/A-Bus mit der Speichereinrichtung 1420 und dem Prozessor 1402 zu verbinden. Zu den E/A-Peripheriegeräten gehören, ohne jedoch hierauf eingeschränkt zu sein, ein Audiocontroller 1446, ein Netzwerkcontroller 1434, eine Firmwareschnittstelle 1428, ein drahtloser Sendeempfänger 1426, Berührungssensoren 1425, eine Datenspeichereinrichtung 1424 (z.B. nichtflüchtiger Speicher, flüchtiger Speicher, Festplattenlaufwerk, Flashspeicher, NAND, 3D-NAND, 3D-XPoint/Optane usw.). Die Datenspeichereinrichtung 1424 kann über eine Speicherschnittstelle (z.B. SATA) oder über einen Peripheriebus wie beispielsweise einen Peripheral-Component-Interconnect-Bus (z.B. PCI, PCI express) verbunden sein. Zu den Berührungssensoren 1425 können Touchscreen-Sensoren, Drucksensoren oder Fingerabdrucksensoren zählen. Bei dem drahtlosen Sendeempfänger 1426 kann es sich um einen WiFi-Sendeempfänger, einen Bluetooth-Sendeempfänger oder einen Mobilnetzwerk-Sendeempfänger wie beispielsweise einen 3G-, 4G-, 5G- oder Long-Term-Evolution- (LTE-) Sendeempfänger handeln. Die Firmware-Schnittstelle 1428 ermöglicht Kommunikation mit System-Firmware und kann beispielsweise eine vereinheitlichte erweiterbare Firmware-Schnittstelle (Unified Extensible Firmware Interface, UEFI) sein. Der Netzwerkcontroller 1434 kann eine Netzwerkverbindung zu einem drahtgebundenen Netzwerk ermöglichen. In einigen Ausführungsformen ist mit dem Schnittstellenbus 1410 ein Hochleistungs-Netzwerkcontroller (nicht gezeigt) gekoppelt. Bei dem Audiocontroller 1446 kann es sich um einen Mehrkanal-High-Definition-Audiocontroller handeln. In einigen dieser Ausführungsformen weist das System 1400 einen optionalen Legacy-E/A-Controller 1440 zum Koppeln von Legacy- (z.B. Personal System 2 (PS/2)) Einrichtungen an das System auf. Der Platform Controller Hub 1430 kann zudem mit einem oder mehreren Universal-Serial-Bus- (USB-) Controllern 1442 verbunden sein, um Eingabeeinrichtungen wie beispielsweise Tastatur- und Maus- 1443 Kombinationen, eine Kamera 1444 oder andere USB-Eingabeeinrichtungen zu verbinden.
  • Es versteht sich, dass das gezeigte System 1400 beispielhaft und nicht einschränkend ist, da auch andere Arten von Datenverarbeitungssystemen mit anderer Konfiguration verwendet werden können. So können etwa in einem Beispiel der Speichercontroller 1416 und der Platform Controller Hub 1430 in einen diskreten externen Grafikprozessor wie beispielsweise den externen Grafikprozessor 1418 integriert sein. Der Platform Controller Hub 1430 und/oder der Speichercontroller 1416 können außerhalb des einen oder der mehreren Prozessoren 1402 liegen. Beispielsweise kann das System 1400 einen externen Speichercontroller 1416 und einen externen Platform Controller Hub 1430 aufweisen, die als Speichercontroller-Hub und Peripheriecontroller-Hub in einem System-Chipsatz konfiguriert sein können, der mit dem oder den Prozessoren 1402 in Kommunikation steht.
  • Beispielsweise können Platinen („Schlitten“) verwendet werden, auf denen Komponenten wie beispielsweise CPUs, Speicher und andere Komponenten platziert werden und die für erhöhte thermische Leistungsfähigkeit ausgelegt sind. Verarbeitende Komponenten wie beispielsweise die Prozessoren können sich auf einer Oberseite eines Schlittens befinden, während sich prozessornaher Speicher wie beispielsweise DIMMs auf einer Unterseite des Schlittens befindet. Aufgrund der durch diese Ausgestaltung bereitgestellten verbesserten Luftströmung können die Komponenten mit höheren Taktraten und Leistungspegeln als in typischen Systemen arbeiten, wodurch die Leistungsfähigkeit erhöht wird. Des Weiteren sind die Schlitten für Blindkopplung mit Leistungs- und Datenübertragungskabeln in einem Rack konfiguriert, was ihre Fähigkeit zur schnellen Entnahme, Aufrüstung, Neuinstallation und/oder Auswechslung steigert. Ebenso sind auf den Schlitten befindliche einzelne Komponenten wie beispielsweise Prozessoren, Beschleuniger, Kurzzeitspeicher und Datenspeicherlaufwerke aufgrund ihrer erhöhten Beabstandung zueinander für einfache Aufrüstung konfiguriert. In der veranschaulichenden Ausführungsform beinhalten die Komponenten zusätzlich Hardware-Attestiermerkmale, um deren Authentizität zu belegen.
  • Ein Datenzentrum kann eine einzige Netzarchitektur („Fabric“) verwenden, die mehrere andere Netzwerkarchitekturen einschließlich Ethernet und Omni-Path unterstützt. Die Schlitten können über Glasfaser, die höhere Bandbreiten und geringere Latenz bietet als typische Kabel mit verdrillten Aderpaaren (z.B. Kategorie 5, Kategorie 5e, Kategorie 6 usw.), mit Switches gekoppelt sein. Aufgrund der Verschaltungen und Netzarchitektur mit hoher Bandbreite und geringer Latenz kann das Datenzentrum im Betrieb Ressourcen wie beispielsweise Kurzzeitspeicher, Beschleuniger (z.B. GPUs, Grafikbeschleuniger, FPGAs, ASICs, mit neuronalen Netzen und/oder künstlicher Intelligenz arbeitende Beschleuniger usw.) und Datenspeicherlaufwerke, die physisch getrennt sind, zusammenschließen und diese nach Bedarf an Rechenressourcen (z.B. Prozessoren) bereitstellen, was den Rechenressourcen ermöglicht, auf die zusammengeschlossenen Ressourcen so zuzugreifen, als wären diese lokal.
  • Eine Leistungsversorgung oder -quelle kann dem System 1400 oder einer beliebigen Komponente oder einem beliebigen System, die vorliegend beschrieben werden, Spannung und/oder Strom bereitstellen. In einem Beispiel weist die Stromversorgung einen AC/DC- (Wechselstrom-zu-Gleichstrom-) Adapter zum Einstecken in eine Wandsteckdose auf. Eine solche AC-Leistungsquelle kann eine erneuerbare Energiequelle (z. B. Solarstrom) sein. In einem Beispiel weist die Leistungsquelle eine Gleichstromquelle wie beispielsweise einen externen Wechselstrom-Gleichstrom-Wandler auf. Eine Leistungsquelle oder Leistungsversorgung kann zudem Hardware für drahtloses Aufladen zum Aufladen über Nähe zu einem Ladefeld aufweisen. Die Leistungsquelle kann eine interne Batterie, eine Wechselstromversorgung, eine bewegungsbasierte Leistungsversorgung, eine Solarstromversorgung oder eine Brennstoffzellenquelle umfassen.
  • 15A bis 15C veranschaulichen Rechensysteme und Grafikprozessoren. Die Elemente aus 15A bis 15C, die die gleichen oder ähnliche Namen wie die Elemente einer anderen vorliegend enthaltenen Figur haben, beschreiben die gleichen Elemente wie in den anderen Figuren, können in ähnlicher Weise arbeiten oder funktionieren, können die gleichen Komponenten umfassen und können mit anderen Einheiten verbunden sein, wie die, die vorliegend an anderer Stelle beschrieben sind, ohne jedoch hierauf eingeschränkt zu sein.
  • 15A ist ein Blockschaubild eines Prozessors 1500, der eine Variante eines der Prozessoren 1402 sein kann und anstelle eines dieser Prozessoren verwendet werden kann. Daher offenbart die Offenbarung jeglicher Merkmale in Kombination mit dem Prozessor 1500 vorliegend auch eine entsprechende Kombination mit dem/den Prozessor(en) 1402, ohne jedoch hierauf eingeschränkt zu sein. Der Prozessor 1500 kann über einen oder mehrere Prozessorkerne 1502A bis 1502N, einen integrierten Speichercontroller 1514 und einen integrierten Grafikprozessor 1508 verfügen. Wenn ein integrierter Grafikprozessor 1508 ausgeschlossen ist, weist das System, das den Prozessor aufweist, eine Grafikprozessoreinrichtung innerhalb eines Systemchipsatzes oder gekoppelt über einen Systembus auf. Der Prozessor 1500 kann zusätzliche Kerne aufweisen, bis hin zu und einschließlich des zusätzlichen Kerns 1502N, die durch die gestrichelt umrandeten Kästchen dargestellt sind. Jeder der Prozessorkerne 1502A bis 1502N weist eine oder mehrere interne Cache-Einheiten 1504A bis 1504N auf. In einigen Ausführungsformen hat zudem jeder Prozessorkern 1502A bis 1502N Zugriff auf eine oder mehrere gemeinsam genutzte Cache-Einheiten 1506. Die internen Cache-Einheiten 1504A bis 1504N und die gemeinsam genutzten Cache-Einheiten 1506 repräsentieren eine Cachespeicher-Hierarchie innerhalb des Prozessors 1500. Die Cachespeicher-Hierarchie kann mindestens eine Ebene („Level“) von Anweisungs- und Datencache innerhalb jedes Prozessorkerns und eine oder mehrere Ebenen von gemeinsam genutztem Mid-Level-Cache wie beispielsweise eine Level-2-(L2-), Level-3- (L3-), Level-4- (L4-) oder andere Cache-Ebenen umfassen, wobei die höchste Cache-Ebene vor dem externen Speicher als LLC klassifiziert wird. In einigen Ausführungsformen bewahrt Cache-Kohärenzlogik die Kohärenz zwischen den verschiedenen Cache-Einheiten 1506 und 1504A bis 1504N.
  • Der Prozessor 1500 kann zudem einen Satz aus einer oder mehreren Buscontroller-Einheiten 1516 und einen Systemagenten-Kern 1510 aufweisen. Die eine oder die mehreren Buscontroller-Einheiten 1516 verwalten einen Satz von Peripheriebussen wie beispielsweise einen oder mehrere PCI- oder PCI-express-Busse. Der Systemagenten-Kern 1510 stellt Verwaltungsfunktionalität für die verschiedenen Prozessorkomponenten bereit. Der Systemagenten-Kern 1510 kann einen oder mehrere integrierte Speichercontroller 1514 aufweisen, um den Zugriff auf verschiedene externe Speichereinrichtungen (nicht gezeigt) zu verwalten.
  • Beispielsweise umfassen einer oder mehrere der Prozessorkerne 1502A bis 1502N Unterstützung für gleichzeitiges Multi-Threading. Der Systemagenten-Kern 1510 weist Komponenten zum Koordinieren und Betreiben der Kerne 1502A bis 1502N während der Multi-Threading-Verarbeitung auf. Der Systemagenten-Kern 1510 kann zusätzlich eine Leistungssteuereinheit (Power Control Unit, PCU) aufweisen, die Logik und Komponenten zum Regulieren des Leistungszustands der Prozessorkerne 1502A bis 1502N und des Grafikprozessors 1508 aufweist.
  • Der Prozessor 1500 kann zusätzlich einen Grafikprozessor 1508 zum Ausführen von Grafikverarbeitungsoperationen aufweisen. In einigen dieser Ausführungsformen ist der Grafikprozessor 1508 mit dem Satz gemeinsam genutzter Cache-Einheiten 1506 und dem Systemagenten-Kern 1510 einschließlich des einen oder der mehreren integrierten Speichercontroller 1514 gekoppelt. Der Systemagenten-Kern 1510 kann zudem einen Anzeigecontroller 1511 zum Steuern der Ausgabe des Grafikprozessors an eine oder mehrere gekoppelte Anzeigen aufweisen. Beim Anzeigecontroller 1511 kann es sich auch um ein separates Modul handeln, das über mindestens eine Verbindung mit dem Grafikprozessor gekoppelt ist, oder er kann in den Grafikprozessor 1508 integriert sein.
  • Eine Ring-basierte Verbindungseinheit 1512 kann verwendet werden, um die internen Komponenten des Prozessors 1500 zu koppeln. Es kann jedoch auch eine alternative Verbindungseinheit verwendet werden, beispielsweise eine Punkt-zu-Punkt-Verbindung, eine geschaltete Verbindung oder andere Methoden einschließlich im Fachgebiet bekannter Methoden. In einigen dieser Ausführungsformen mit einer Ring-basierten Verbindung 1512 ist der Grafikprozessor 1508 über eine E/A-Verbindung 1513 mit der Ring-basierten Verbindung 1512 gekoppelt.
  • Die beispielhafte E/A-Verbindung 1513 stellt wenigstens eine von mehreren Varianten von E/A-Verbindungen dar, darunter eine On-Package-E/A-Verbindung, welche die Kommunikation zwischen verschiedenen Prozessorkomponenten und einem eingebetteten Hochleistungs-Speichermodul 1518 wie beispielsweise einem eDRAM-Modul erleichtert. Wahlweise können die Prozessorkerne 1502A bis 1502N und der Grafikprozessor 1508 jeweils eingebettete Speichermodule 1518 als gemeinsamen Last-Level-Cache verwenden.
  • Die Prozessorkerne 1502A bis 1502N können beispielsweise homogene Kerne sein, die dieselbe Befehlssatzarchitektur ausführen. Alternativ sind die Prozessorkerne 1502A bis 1502N hinsichtlich der Befehlssatzarchitektur (Instruction Set Architecture, ISA) heterogen, wobei ein oder mehrere Prozessorkerne 1502A bis 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 bis 1502N können hinsichtlich der Mikroarchitektur heterogen sein, wobei ein oder mehrere Kerne mit einer relativ höheren Leistungsaufnahme mit einem oder mehreren Leistungskernen mit einer geringeren Leistungsaufnahme gekoppelt sind. Als weiteres Beispiel sind die Prozessorkerne 1502A bis 1502N hinsichtlich der Rechenleistung heterogen. Zudem kann der Prozessor 1500 auf einem oder mehreren Chips oder als integrierte SoC-Schaltung implementiert sein, die neben den veranschaulichten Komponenten auch über andere Komponenten verfügt.
  • 15B ist ein Blockschaubild von Hardware-Logik eines Grafikprozessorkerns 1519 gemäß einigen vorliegend beschriebenen Ausführungsformen. Bei dem Grafikprozessor 1519, welcher manchmal auch als Kernbaustein bezeichnet wird, kann es sich um einen oder mehrere Grafikkerne innerhalb eines modularen Grafikprozessors handeln. Der Grafikprozessorkern 1519 steht beispielhaft für einen Grafikkernbaustein, und ein Grafikprozessor wie vorliegend beschrieben kann je nach angestrebten Energie- und Leistungshüllkurven mehrere Grafikkernbausteine aufweisen. Jeder Grafikprozessorkern 1519 kann einen Festfunktionsblock 1530 aufweisen, der mit mehreren Teilkernen 1521A bis 1521F, auch bezeichnet als Teilbausteine, gekoppelt ist, die modulare Blöcke aus Allzwecklogik und Logik mit fester Funktion aufweisen.
  • Der Festfunktionsblock 1530 kann eine Geometrie- /Festfunktionspipeline 1531 aufweisen, die von allen Teilkernen im Grafikprozessorkern 1519 gemeinsam genutzt werden kann, beispielsweise in Grafikprozessor-Implementierungen mit geringerer Leistung und/oder geringerem Stromverbrauch. Die Geometrie-/Festfunktionspipeline 1531 kann eine 3D-Festfunktionspipeline (z.B. 3D-Pipeline 1612 wie in nachstehend beschriebener 16A), eine Video-Front-End-Einheit, einen Thread-Spawner und Thread-Dispatcher sowie einen Unified-Return-Buffer-Manager aufweisen, der vereinheitlichte Rücksprungpuffer (unified return buffers) verwaltet (z.B. den vereinheitlichten Rücksprungpuffer 1718 in nachstehend beschriebener 17).
  • Der Festfunktionsblock 1530 kann zudem eine Grafik-SoC-Schnittstelle 1532, einen Grafik-Mikrocontroller 1533 und eine Medienpipeline 1534 aufweisen. Die Grafik-SoC-Schnittstelle 1532 stellt eine Schnittstelle zwischen dem Grafikprozessorkern 1519 und anderen Prozessorkernen innerhalb einer integrierten Ein-Chip-System-Schaltung bereit. Bei dem Grafik-Mikrocontroller 1533 handelt es sich um einen programmierbaren Teilprozessor, der konfigurierbar ist, um verschiedene Funktionen des Grafikprozessorkerns 1519 zu verwalten, darunter Thread-Dispatch, Planung und Zurückstellung. Die Medienpipeline 1534 (z.B. die Medienpipeline 1616 aus 16A und 17) weist Logik auf, um die Decodierung, Codierung, Vorverarbeitung und/oder Nachbearbeitung von Multimedia-Daten, darunter Bild- und Videodaten, zu erleichtern. Die Medienpipeline 1534 implementiert Medienoperationen über Anfragen an Rechen- oder Abtastlogik innerhalb der Teilkerne 1521 bis 1521F.
  • Die SoC-Schnittstelle 1532 kann dem Grafikprozessorkern 1519 die Kommunikation mit Prozessorkernen für Allzweckanwendungen (z.B. CPUs) und/oder anderen Komponenten innerhalb eines SoC ermöglichen, darunter Speicherhierarchieelemente wie beispielsweise ein gemeinsamer Last-Level-Cachespeicher, der System-RAM und/oder eingebetteter On-Chip- oder On-Package-DRAM. Die SoC-Schnittstelle 1532 kann auch die Kommunikation mit Festfunktionseinrichtungen innerhalb des SoC ermöglichen, wie beispielsweise Kamera-Bildgebungspipelines, und ermöglicht die Verwendung von und/oder implementiert globale Speicher-Atome, die zwischen dem Grafikprozessorkern 1519 und CPUs innerhalb des SoC gemeinsam genutzt werden können. Die SoC-Schnittstelle 1532 kann zudem Energieverwaltungssteuerungen für den Grafikprozessorkern 1519 implementieren und eine Schnittstelle zwischen einem Taktbereich des Grafikkerns 1519 und anderen Taktbereichen innerhalb des SoC ermöglichen. Wahlweise ermöglicht die SoC-Schnittstelle 1532 den Empfang von Befehlspuffern von einem Befehls-Streamer und globalen Thread-Dispatcher, die dafür konfiguriert sind, Befehle und Anweisungen an jeden von einem oder mehreren Grafikkernen innerhalb eines Grafikprozessors bereitzustellen. Die Befehle und Anweisungen können an die Medienpipeline 1534 geschickt werden, wenn Medienoperationen durchgeführt werden sollen, oder an eine Geometrie- und Festfunktionspipeline (z.B. Geometrie- und Festfunktionspipeline 1531, Geometrie- und Festfunktionspipeline 1537), wenn Grafikverarbeitungsoperationen durchgeführt werden sollen.
  • Der Grafik-Mikrocontroller 1533 kann dafür konfiguriert sein, verschiedene Planungs- und Verwaltungsaufgaben für den Grafikprozessorkern 1519 durchzuführen. In einer Konfiguration kann der Grafik-Mikrocontroller 1533 beispielsweise die Grafik- und/oder Rechenlastplanung auf den verschiedenen parallelen Grafik-Engines innerhalb der Arrays 1522A bis 1522F, 1524A bis 1524F der Ausführungseinheiten (execution unit, EU) innerhalb der Teilkerne 1521A bis 1521F durchführen. Bei dieser Arbeitslastplanung kann Host-Software, die auf einem CPU-Kern eines den Grafikprozessorkern 1519 aufweisenden SoC ausgeführt wird, Arbeitslasten an eine von mehreren Grafikprozessor-Doorbells bereitstellen, was eine Planungsoperation auf der entsprechenden Grafik-Engine aktiviert. Zu Planungsoperationen zählen Bestimmen, welche Arbeitslast als nächstes ausgeführt werden soll, Liefern einer Arbeitslast an einen Befehls-Streamer, Zurückstellen bestehender Arbeitslasten, die auf einer Engine ausgeführt werden, Überwachen des Fortschritts einer Arbeitslast und Benachrichtigen einer Host-Software, wenn eine Arbeitslast abgeschlossen ist. Wahlweise kann der Grafik-Mikrocontroller 1533 auch stromsparende oder Leerlaufzustände für den Grafikprozessorkern 1519 erleichtern, indem er dem Grafikprozessorkern 1519 die Möglichkeit gibt, Register innerhalb des Grafikprozessorkerns 1519 über stromsparende Zustandsübergänge hinweg unabhängig vom Betriebssystem und/oder der Grafiktreibersoftware auf dem System zu speichern und wiederherzustellen.
  • Der Grafikprozessorkern 1519 kann mehr als oder weniger als die dargestellten Teilkerne 1521A bis 1521F aufweisen, bis zu N modulare Teilkerne. Für jeden Satz aus N Teilkernen kann der Grafikprozessorkern 1519 auch eine gemeinsam genutzte Funktionslogik 1535, einen gemeinsam genutzten und/oder Cache-Speicher 1536, eine Geometrie-/Festfunktionspipeline 1537 sowie zusätzliche Festfunktionslogik 1538 zur Beschleunigung verschiedener Grafik- und Rechenverarbeitungsoperationen aufweisen. Die gemeinsam genutzte Funktionslogik 1535 kann Logikeinheiten aufweisen, die mit der gemeinsam genutzten Funktionslogik 1720 aus 17 verbunden sind (z.B. Sampler-, Mathematik- und/oder Inter-Thread-Kommunikationslogik), die von allen N Teilkernen innerhalb des Grafikprozessorkerns 1519 gemeinsam genutzt werden können. Der gemeinsam genutzte und/oder Cache-Speicher 1536 kann ein Last-Level-Cache für den Satz aus N Teilkernen 1521A bis 1521F innerhalb des Grafikprozessorkerns 1519 sein und kann zudem als gemeinsam genutzter Speicher dienen, auf den mehrere Teilkerne zugreifen können. Die Geometrie- /Festfunktionspipeline 1537 kann anstelle der Geometrie-/Festfunktionspipeline 1531 innerhalb des Festfunktionsblocks 1530 umfasst sein und kann dieselben oder ähnliche Logikeinheiten aufweisen.
  • Der Grafikprozessorkern 1519 kann zusätzliche Festfunktionslogik 1538 aufweisen, die verschiedene Festfunktions-Beschleunigungslogik zur Verwendung durch den Grafikprozessorkern 1519 aufweisen kann. Wahlweise weist die zusätzliche Festfunktionslogik 1538 eine zusätzliche Geometriepipeline zur Verwendung für reine Positionsschattierung (position only shading) auf. Bei reiner Positionsschattierung existieren zwei Geometriepipelines, die vollständige Geometriepipeline innerhalb der Geometrie-/Festfunktionspipeline 1538, 1531 und eine Sortierpipeline (cull pipeline), bei der es sich um eine zusätzliche Geometriepipeline handelt, die in der zusätzlichen Festfunktionslogik 1538 umfasst sein kann. Beispielsweise kann es sich bei der Sortierpipeline um eine abgespeckte Version der vollständigen Geometriepipeline handeln. Die vollständige Pipeline und die Sortierpipeline können verschiedene Instanzen der gleichen Anwendung ausführen, wobei jede Instanz einen separaten Kontext hat. Reine Positionsschattierung kann lange Sortierdurchläufe verworfener Dreiecke verbergen, wodurch die Schattierung in einigen Instanzen früher abgeschlossen werden kann. Zum Beispiel kann die Sortierpipeline-Logik innerhalb der zusätzlichen Festfunktionslogik 1538 Positionsschattierer (position shaders) parallel zur Hauptanwendung ausführen und generiert im Allgemeinen kritische Ergebnisse schneller als die vollständige Pipeline, da die Sortierpipeline nur das Positionsattribut der Vertices abruft und schattiert, ohne Rasterung und Rendern der Pixel in den Rahmenpuffer (frame buffer) durchzuführen. Die Sortierpipeline kann die erzeugten kritischen Ergebnisse verwenden, um Sichtbarkeitsinformationen für alle Dreiecke zu berechnen, unabhängig davon, ob diese Dreiecke aussortiert werden. Die vollständige Pipeline (die in diesem Fall als Replay-Pipeline bezeichnet werden kann) kann die Sichtbarkeitsinformationen aufnehmen, um die aussortierten Dreiecke zu überspringen und nur die sichtbaren Dreiecke zu schattieren, die schließlich an die Rasterungsphase übergeben werden.
  • Wahlweise kann die zusätzliche Festfunktionslogik 1538 zudem Maschinenlern-Beschleunigungslogik umfassen, beispielsweise Festfunktions-Matrixmultiplikationslogik, für Implementierungen, die Optimierungen für Maschinenlemtraining oder Inferenzfindung umfassen.
  • Im Inneren jedes Grafik-Teilkerns 1521A bis 1521F ist ein Satz Ausführungsressourcen umfasst, die verwendet werden können, um in Reaktion auf Anfragen von Grafikpipeline-, Medienpipeline- oder Schattierprogrammen Grafik-, Medien- und Rechenoperationen durchzuführen. Die Grafik-Teilkerne 1521A bis 1521F weisen mehrere EU-Arrays 1522A bis 1522F, 1524A bis 1524F, Thread-Dispatch- und Inter-Thread-Kommunikations- (TD/IC-) Logik 1523A bis 1523F, einen 3D- (z.B. Textur-) Sampler 1525A bis 1525F, einen Mediensampler 1526A bis 1526F, einen Schattierprozessor 1527A bis 1527F und gemeinsam genutzten lokalen Speicher (shared local memory, SLM) 1528A bis 1528F auf Die EU-Arrays 1522A bis 1522F, 1524A bis 1524F weisen jeweils mehrere Ausführungseinheiten auf, bei denen es sich um Allzweck-Grafikverarbeitungseinheiten handelt, die in der Lage sind, Gleitkomma- und Ganzzahl-/Festkomma-Logikoperationen im Dienste einer Grafik-, Medien- oder Rechenoperation durchzuführen, einschließlich Grafik-, Medien- oder Schattierrechenprogrammen. Die TD/IC-Logik 1523A bis 1523F führt lokalen Thread-Dispatch und Thread-Steueroperatioinen für die Ausführungseinheiten innerhalb eines Teilkerns aus und erleichtert Kommunikation zwischen auf den Ausführungseinheiten des Teilkerns ausgeführten Threads. Der 3D-Sampler 1525A bis 1525F kann Textur- oder andere 3D-Grafik betreffende Daten in den Speicher lesen. Der 3D-Sampler kann Texturdaten auf Grundlage eines konfigurierten Abtaststatus und des Texturformats, das einer bestimmten Textur zugeordnet ist, unterschiedlich lesen. Der Mediensampler 1526A bis 1526F kann auf Grundlage des den Mediendaten zugehörigen Typs und Formats ähnliche Leseoperationen durchführen. Beispielsweise kann jeder Grafik-Teilkern 1521A bis 1521F alternativ einen kombinierten 3D- und Mediensampler aufweisen. Threads, die auf den Ausführungseinheiten in jedem der Teilkerne 1521A bis 1521F ausgeführt werden, können den gemeinsamen lokalen Speicher 1528A bis 1528F in jedem Teilkern nutzen, damit Threads, die innerhalb einer Thread-Gruppe ausgeführt werden, einen gemeinsamen Pool von On-Chip-Speicher nutzen können.
  • 15C ist ein Blockschaubild einer Allzweck-Grafikverarbeitungseinheit (General-Purpose Graphics Processing Unit, GPGPU) 1570, die als Grafikprozessor, z.B. der Grafikprozessor 1508, und/oder Rechenbeschleuniger konfiguriert sein kann, gemäß vorliegend beschriebenen Ausführungsformen. Die GPGPU 1570 kann über einen oder mehrere System- und/oder Speicherbusse mit Hostprozessoren (z.B. einer oder mehreren CPU(s) 1546) und einem Speicher 1571, 1572 verbunden sein. Bei dem Speicher 1571 kann es sich um Systemspeicher handeln, der mit der einen oder den mehreren CPU(s) 1546 gemeinsam verwendet werden kann, während es sich bei dem Speicher 1572 um Einrichtungsspeicher handelt, der speziell für die GPGPU 1570 bestimmt ist. Beispielsweise können Komponenten innerhalb der GPGPU 1570 und des Einrichtungsspeichers 1572 in Speicheradressen abgebildet werden, auf die die eine oder die mehreren CPU(s) 1546 zugreifen können. Der Zugriff auf die Speicher 1571 und 1572 kann über einen Speichercontroller 1568 erleichtert werden. Der Speichercontroller 1568 kann einen internen Speicherdirektzugriffscontroller 1569 (Direct Memory Access, DMA) aufweisen oder kann Logik zur Durchführung von Operationen aufweisen, die sonst von einem DMA-Controller durchgeführt würden.
  • Die GPGPU 1570 weist mehrere Cachespeicher auf, darunter einen L2-Cache 1553, einen L1-Cache 1554, einen Anweisungscache 1555 und gemeinsamen Speicher 1556, von dem zumindest ein Teil ebenfalls als Cachespeicher partitioniert sein kann. Die GPGPU 1570 weist zudem mehrere Recheneinheiten 1560A bis 1560N auf. Jede Recheneinheit 1560A bis 1560N weist einen Satz aus Vektorregistern 1561, Skalarregistern 1562, Vektorlogikeinheiten 1563 und Skalarlogikeinheiten 1564 auf. Die Recheneinheiten 1560A bis 1560N können zudem lokalen gemeinsamen Speicher 1565 und einen Programmzähler 1566 aufweisen. Die Recheneinheiten 1560A bis 1560N können an einen Konstant-Cache 1567 gekoppelt sein, der zum Speichern konstanter Daten verwendet werden kann, d.h. von Daten, die sich während der Ausführung des Kernel- oder Shader-Programms, das auf der GPGPU 1570 ausgeführt wird, nicht ändern. Der Konstant-Cache 1567 kann ein skalarer Datencache sein, und zwischengespeicherte Daten können direkt in die Skalarregister 1562 abgerufen werden.
  • Während des Betriebs können die eine oder die mehreren CPU(s) 1546 Befehle in Register oder Speicher in der GPGPU 1570 schreiben, die in einen zugänglichen Adressraum abgebildet wurden. Die Befehlsprozessoren 1557 können die Befehle aus Registern oder Speicher lesen und bestimmen, wie diese Befehle in der GPGPU 1570 verarbeitet werden. Ein Thread-Dispatcher 1558 kann dann verwendet werden, um Threads an die Recheneinheiten 1560A bis 1560N zu verschicken, um diese Befehle auszuführen. Jede Recheneinheit 1560A bis 1560N kann Threads unabhängig von den anderen Recheneinheiten ausführen. Zusätzlich kann jede Recheneinheit 1560A bis 1560N unabhängig für bedingte Berechnungen konfiguriert sein und kann die Ergebnisse der Berechnungen bedingt an den Speicher ausgeben. Die Befehlsprozessoren 1557 können die eine oder die mehreren CPU(s) 1546 unterbrechen, wenn die gegebenen Befehle abgeschlossen sind.
  • 16A bis 16C veranschaulichen Blockschaubilder weiterer Grafikprozessor- und Rechenbeschleuniger-Architekturen, die durch vorliegend beschriebene Ausführungsformen bereitgestellt werden, z.B. gemäß 15A bis 15C. Die Elemente aus 16A bis 16C, die die gleichen oder ähnliche Namen wie die Elemente einer anderen vorliegend enthaltenen Figur haben, beschreiben die gleichen Elemente wie in den anderen Figuren, können in ähnlicher Weise arbeiten oder funktionieren, können die gleichen Komponenten umfassen und können mit anderen Einheiten verbunden sein, wie die, die vorliegend an anderer Stelle beschrieben sind, ohne jedoch hierauf eingeschränkt zu sein.
  • 16A ist ein Blockschaubild eines Grafikprozessors 1600, bei dem es sich um eine diskrete Grafikverarbeitungseinheit oder um einen Grafikprozessor handeln kann, der mit einer Vielzahl von Verarbeitungskernen oder anderen Halbleitereinrichtungen wie beispielsweise, ohne jedoch hierauf eingeschränkt zu sein, Speichereinrichtungen oder Netzwerkschnittstellen integriert sein kann. Der Grafikprozessor 1600 kann eine Variante des Grafikprozessors 1508 sein und kann anstelle des Grafikprozessors 1508 verwendet werden. Daher offenbart die Offenbarung jeglicher Merkmale in Kombination mit dem Grafikprozessor 1508 vorliegend auch eine entsprechende Kombination mit dem Grafikprozessor 1600, ohne jedoch hierauf eingeschränkt zu sein. Der Grafikprozessor kann über eine speicherabgebildete E/A-Schnittstelle mit Registern auf dem Grafikprozessor und mit Befehlen kommunizieren, die im Prozessorspeicher abgelegt sind. Der Grafikprozessor 1600 kann eine Speicherschnittstelle 1614 aufweisen, um auf Speicher zuzugreifen. Bei der Speicherschnittstelle 1614 kann es sich um eine Schnittstelle mit lokalem Speicher, einem oder mehreren internen Caches, einem oder mehreren gemeinsamen externen Caches und/oder mit Systemspeicher handeln.
  • Wahlweise weist der Grafikprozessor 1600 zudem einen Anzeigecontroller 1602 auf, um Anzeigeausgabedaten an eine Anzeigeeinrichtung 1618 auszugeben. Der Anzeigecontroller 1602 weist Hardware für eine oder mehrere Überlagerungsebenen zur Anzeige und Zusammensetzung mehrerer Ebenen von Video- oder Nutzerschnittstellenelementen auf Bei der Anzeigeeinrichtung 1618 kann es sich um eine interne oder eine externe Anzeigeeinrichtung handeln. In einer Ausführungsform handelt es sich bei der Anzeigeeinrichtung 1618 um eine am Kopf befestigbare Anzeigeeinrichtung wie beispielsweise eine Virtual-Reality- (VR-) Anzeigeeinrichtung oder eine Augmented-Reality- (AR-) Anzeigeeinrichtung. Der Grafikprozessor 1600 kann eine Videocodec-Engine 1606 zum Codieren, Decodieren oder Transcodieren von Medien in, aus oder zwischen einem oder mehreren Mediencodierformaten aufweisen, darunter, ohne jedoch hierauf eingeschränkt zu sein, MPEG-Formate (Moving Picture Experts Group) wie MPEG-2, AVC-Formate (Advanced Video Coding) wie H.264 /MPEG-4 AVC, H.265/HEVC, Alliance for Open Media (AOMedia) VP8, VP9, sowie Society of Motion Picture & Television Engineers (SMPTE) 421M/VC-1 und JPEG-Formate (Joint Photographic Experts Group) wie JPEG und Motion-JPEG- (MJPEG-) Formate.
  • Der Grafikprozessor 1600 kann eine Block-Image-Transfer- (BLIT-) Engine 1603 aufweisen, um zweidimensionale (2D-) Rasteroperationen durchzuführen, darunter beispielsweise Bit-Boundary Block Transfers. Alternativ können jedoch 2D-Grafikoperationen mittels einer oder mehrerer Komponenten der Grafikverarbeitungs-Engine (GPE) 1610 durchgeführt werden. In einigen Ausführungsformen ist die GPE 1610 eine Rechen-Engine zum Durchführen von Grafikoperationen, darunter dreidimensionale (3D-) Grafikoperationen und Medienoperationen.
  • Die GPE 1610 kann eine 3D-Pipeline 1612 zur Durchführung von 3D-Operationen aufweisen, wie beispielsweise Rendern dreidimensionaler Bilder und Szenen unter Verwendung von Verarbeitungsfunktionen, die auf 3D-Primitivformen (z.B. Rechteck, Dreieck usw.) wirken. Die 3D-Pipeline 1612 weist programmierbare und Festfunktionselemente auf, die verschiedene Aufgaben innerhalb des Elements ausführen und/oder Ausführungs-Threads an ein 3D/Medienteilsystem 1615 weiterleiten. Während die 3D-Pipeline 1612 zur Durchführung von Medienoperationen verwendet werden kann, weist eine Ausführungsform der GPE 1610 auch eine Medienpipeline 1616 auf, die speziell zur Durchführung von Medienoperationen wie beispielsweise Videonachbearbeitung und Bildverbesserung verwendet wird.
  • Die Medienpipeline 1616 kann Festfunktions- oder programmierbare Logikeinheiten aufweisen, um anstelle oder im Auftrag der Videocodec-Engine 1606 eine oder mehrere spezialisierte Medienoperationen wie beispielsweise Videodecodierbeschleunigung, Video-De-Interlacing und Videocodierbeschleunigung durchzuführen. Die Medienpipeline 1616 kann zusätzlich eine Thread-Spawning-Einheit zum Erzeugen von Threads zur Ausführung auf dem 3D/Medienteilsystem 1615 aufweisen. Die erzeugten Threads führen Berechnungen für die Medienoperationen auf einer oder mehreren in dem 3D/Medienteilsystem 1615 umfassten Grafikausführungseinheiten durch.
  • Das 3D/Medienteilsystem 1615 kann Logik zum Ausführen von durch die 3D-Pipeline 1612 und die Medienpipeline 1616 erzeugten Threads aufweisen. Die Pipelines können Thread-Ausführungsanfragen an das 3D/Medienteilsystem 1615 senden, das eine Thread-Dispatch-Logik für die Vermittlung und Verteilung der verschiedenen Anfragen an verfügbare Thread-Ausführungsressourcen aufweist. Die Ausführungsressourcen umfassen ein Array aus Grafikausführungseinheiten zur Verarbeitung der 3D- und Medien-Threads. Das 3D/Medienteilsystem 1615 kann einen oder mehrere interne Caches für Thread-Anweisungen und -Daten aufweisen. Zusätzlich kann das 3D/Medienteilsystem 1615 zudem gemeinsamen Speicher aufweisen, darunter Register und adressierbaren Speicher, um Daten zwischen Threads zu teilen und Ausgabedaten zu speichern.
  • 16B veranschaulicht einen Grafikprozessor 1620, der eine Variante des Grafikprozessors 1600 ist und anstelle des Grafikprozessors 1600 verwendet werden kann und umgekehrt. Daher offenbart die Offenbarung jeglicher Merkmale in Kombination mit dem Grafikprozessor 1600 vorliegend auch eine entsprechende Kombination mit dem Grafikprozessor 1620, ohne jedoch hierauf eingeschränkt zu sein. Der Grafikprozessor 1620 verfügt gemäß vorliegend beschriebenen Ausführungsformen über eine gekachelte Architektur. Der Grafikprozessor 1620 kann einen Grafikverarbeitungs-Engine-Cluster 1622 mit mehreren Instanzen der Grafikverarbeitungs-Engine 1610 aus 16A innerhalb einer Grafik-Engine-Kachel 1610A bis 1610D aufweisen. Die Grafik-Engine-Kacheln 1610A bis 1610D können über einen Satz von Kachelverbindungen 1623A bis 1623F jeweils untereinander verbunden sein. Die Grafik-Engine-Kacheln 1610A bis 1610D können zudem über Speicherverbindungen 1625A bis 1625D jeweils mit einem Speichermodul oder einer Speichereinrichtung 1626A bis 1626D verbunden sein. Die Speichereinrichtungen 1626A bis 1626D können eine beliebige Grafikspeichertechnologie verwenden. Beispielsweise kann es sich bei den Speichereinrichtungen 1626A bis 1626D um GDDR- (Graphics Double Data Rate) Speicher handeln. Bei den Speichereinrichtungen 1626A bis 1626D kann es sich um HBM- (High-Bandwidth Memory) Module handeln, die sich mit ihrer jeweiligen Grafik-Engine-Kachel 1610A bis 1610D on-Die befinden können. Bei den Speichereinrichtungen 1626A bis 1626D kann es sich um gestapelte Speichereinrichtungen handeln, die auf ihre jeweilige Grafik-Engine-Kachel 1610A bis 1610D gestapelt sein können. Jede Grafik-Engine-Kachel 1610A bis 1610D und der zugehörige Speicher 1626A bis 1626D können sich auf separaten Chiplets befinden, die mit einem Basis-Die oder Basissubstrat verbunden sind, wie in 24B bis 24D näher beschrieben.
  • Der Grafikprozessor 1620 kann mit einem NUMA- (Non-Uniform Memory Access) System konfiguriert sein, bei dem die Speichereinrichtungen 1626A bis 1626D mit zugehörigen Grafik-Engine-Kacheln 1610A bis 1610D gekoppelt sind. Auf eine bestimmte Speichereinrichtung kann von anderen Kacheln der Grafik-Engine zugegriffen werden als von der Kachel, mit der sie direkt verbunden ist. Die Zugriffslatenz auf die Speichereinrichtungen 1626A bis 1626D kann jedoch beim Zugriff auf eine lokale Kachel am geringsten sein. In einer Ausführungsform ist ein cachekohärentes NUMA- (ccNUMA) System aktiviert, das die Kachelverbindungen 1623A bis 1623F verwendet, um die Kommunikation zwischen Cachecontrollern innerhalb der Grafik-Engine-Kacheln 1610A bis 1610D zu ermöglichen, um ein konsistentes Speicherabbild zu erhalten, wenn mehr als ein Cache dieselbe Speicherstelle speichert.
  • Der Grafikverarbeitungs-Engine-Cluster 1622 kann mit einer On-Chip- oder On-Package-Fabric-Verbindung 1624 verbunden sein. In einer Ausführungsform weist die Fabric-Verbindung 1624 einen Netzwerkprozessor, ein Network on a Chip (NoC) oder einen anderen Vermittlungsprozessor auf, damit die Fabric-Verbindung 1624 als paketvermittelte Fabric-Verbindung fungieren kann, die Datenpakete zwischen Komponenten des Grafikprozessors 1620 vermittelt. Die Fabric-Verbindung 1624 kann Kommunikation zwischen Grafik-Engine-Kacheln 1610A bis 1610D und Komponenten wie beispielsweise der Videocodec- 1606 und einer oder mehreren Kopier-Engines 1604 ermöglichen. Die Kopier-Engines 1604 können verwendet werden, um Daten aus, in und zwischen den Speichereinrichtungen 1626A bis 1626D und dem Speicher, der sich außerhalb des Grafikprozessors 1620 befindet (z.B. Systemspeicher), zu verschieben. Die Fabric-Verbindung 1624 kann zudem verwendet werden, um die Grafik-Engine-Kacheln 1610A bis 1610D untereinander zu verbinden. Der Grafikprozessor 1620 kann wahlweise einen Anzeigecontroller 1602 aufweisen, um eine Verbindung mit einer externen Anzeigeeinrichtung 1618 zu ermöglichen. Der Grafikprozessor kann zudem als Grafik- oder Rechenbeschleuniger konfiguriert sein. In der Beschleuniger-Konfiguration können der Anzeigecontroller 1602 und die Anzeigeeinrichtung 1618 wegfallen.
  • Der Grafikprozessor 1620 kann über eine Hostschnittstelle 1628 mit einem Hostsystem verbunden sein. Die Hostschnittstelle 1628 kann Kommunikation zwischen dem Grafikprozessor 1620, dem Systemspeicher und/oder anderen Systemkomponenten ermöglichen. Bei der Hostschnittstelle 1628 kann es sich beispielsweise um einen PCI-express-Bus oder eine andere Art von Hostsystem-Schnittstelle handeln. Die Hostschnittstelle 1628 kann zum Beispiel eine NVLink- oder NVSwitch-Schnittstelle sein. Die Hostschnittstelle 1628 und die Fabric-Verbindung 1624 können zusammenarbeiten, damit mehrere Instanzen des Grafikprozessors 1620 als einzelne logische Einrichtung agieren können. Die Zusammenarbeit zwischen der Hostschnittstelle 1628 und der Fabric-Verbindung 1624 kann auch dazu führen, dass die einzelnen Grafik-Engine-Kacheln 1610A bis 1610D dem Hostsystem als unterschiedliche logische Grafikeinrichtungen angezeigt werden.
  • 16C veranschaulicht einen Rechenbeschleuniger 1630 gemäß vorliegend beschriebenen Ausführungsformen. Der Rechenbeschleuniger 1630 kann architektonische Ähnlichkeiten mit dem Grafikprozessor 1620 aus 16B aufweisen und ist für Rechenbeschleunigung optimiert. Ein Rechen-Engine-Cluster 1632 kann einen Satz Rechen-Engine-Kacheln 1640A bis 1640D aufweisen, die Ausführungslogik aufweisen, die für parallele oder vektorbasierte Allzweck-Rechenoperationen optimiert ist. Die Rechen-Engine-Kacheln 1640A bis 1640D weisen möglicherweise keine Festfunktions-Grafikverarbeitungslogik auf, obwohl in einigen Ausführungsformen eine oder mehrere der Rechen-Engine-Kacheln 1640A bis 1640D Logik zum Durchführen von Medienbeschleunigung aufweisen können. Die Rechen-Engine-Kacheln 1640A bis 1640D können über Speicherverbindungen 1625A bis 1625D mit dem Speicher 1626A bis 1626D verbunden sein. Beim Speicher 1626A bis 1626D und den Speicherverbindungen 1625A bis 1625D kann es sich um ähnliche Technologie wie im Grafikprozessor 1620 oder um andere Technologie handeln. Die Grafik-Rechen-Engine-Kacheln 1640A bis 1640D können zudem über einen Satz Kachelverbindungen 1623A bis 1623F untereinander verbunden sein und können mit einer Fabric-Verbindung 1624 verbunden oder durch diese untereinander verbunden sein. In einer Ausführungsform weist der Rechenbeschleuniger 1630 einen großen L3-Cache 1636 auf, der als einrichtungsweiter Cache konfiguriert sein kann. Der Rechenbeschleuniger 1630 kann zudem in ähnlicher Weise wie der Grafikprozessor 1620 aus 16B über eine Hostschnittstelle 1628 mit einem Hostprozessor und Speicher verbunden sein.
  • Der Rechenbeschleuniger 1630 kann zudem eine integrierte Netzwerkschnittstelle 1642 aufweisen. In einer Ausführungsform weist die Netzwerkschnittstelle 1642 einen Netzwerkprozessor und eine Controllerlogik auf, die es dem Rechen-Engine-Cluster 1632 ermöglicht, über eine Bitübertragungsschichtverbindung 1644 zu kommunizieren, ohne dass Daten den Speicher eines Hostsystems durchlaufen müssen. In einer Ausführungsform ist eine der Rechen-Engine-Kacheln 1640A-1640D durch Netzwerkprozessorlogik ersetzt, und Daten, die über die Bitübertragungsschichtverbindung 1644 übertragen oder empfangen werden sollen, können direkt zum oder vom Speicher 1626A bis 1626D übertragen werden. Mehrere Instanzen des Rechenbeschleunigers 1630 können über die Bitübertragungsschichtverbindung 1644 zu einer einzigen logischen Einrichtung verbunden werden. Alternativ können die verschiedenen Rechen-Engine-Kacheln 1640A bis 1640D als unterschiedliche, über das Netzwerk zugängliche Rechenbeschleunigereinrichtungen dargestellt werden.
  • Grafikverarbeitungs-Engine
  • 17 ist ein Blockschaubild einer Grafikverarbeitungs-Engine 1710 eines Grafikprozessors gemäß einigen Ausführungsformen. Die Grafikverarbeitungs-Engine (GPE) 1710 kann eine Version der in 16A gezeigten GPE 1610 sein und kann zudem eine Grafik-Engine-Kachel 1610A bis 1610D aus 16B repräsentieren. Die Elemente aus 17, die die gleichen oder ähnliche Namen wie die Elemente einer anderen vorliegend enthaltenen Figur haben, beschreiben die gleichen Elemente wie in den anderen Figuren, können in ähnlicher Weise arbeiten oder funktionieren, können die gleichen Komponenten umfassen und können mit anderen Einheiten verbunden sein, wie die, die vorliegend an anderer Stelle beschrieben sind, ohne jedoch hierauf eingeschränkt zu sein. Beispielsweise sind die 3D-Pipeline 1612 und die Medienpipeline 1616 aus 16A auch in 17 veranschaulicht. Die Medienpipeline 1616 ist in einigen Ausführungsformen der GPE 1710 optional und ist gegebenenfalls nicht explizit in der GPE 1710 enthalten. Beispielsweise und in mindestens einer Ausführungsform ist ein separater Medien- und/oder Bildprozessor an die GPE 1710 gekoppelt.
  • Die GPE 1710 kann mit einem Befehlsstreamer 1703 gekoppelt sein oder diesen aufweisen, der der 3D-Pipeline 1612 und/oder den Medienpipelines 1616 einen Befehlsstrom bereitstellt. Alternativ oder zusätzlich kann der Befehlsstreamer 1703 direkt mit einem vereinheitlichten Rückgabepuffer 1718 gekoppelt sein. Der vereinheitlichte Rückgabepuffer 1718 kann kommunikativ mit einem Grafikkern-Array 1714 gekoppelt sein. Wahlweise ist der Befehlsstreamer 1703 mit Speicher gekoppelt, bei dem es sich um Systemspeicher oder um internen Cachespeicher und/oder gemeinsamen Cachespeicher handeln kann. Der Befehlsstreamer 1703 kann Befehle vom Speicher empfangen und sendet die Befehle an die 3D-Pipeline 1612 und/oder die Medienpipeline 1616. Bei den Befehlen handelt es sich um Direktiven, die aus einem Ringpuffer abgerufen werden, der Befehle für die 3D-Pipeline 1612 und die Medienpipeline 1616 speichert. Der Ringpuffer kann zusätzlich Batch-Befehlspuffer aufweisen, die Batches aus mehreren Befehlen speichern. Die Befehle für die 3D-Pipeline 1612 können auch Verweise auf Daten umfassen, die im Speicher gespeichert sind, beispielsweise, ohne jedoch hierauf eingeschränkt zu sein, Vertex- und Geometriedaten für die 3D-Pipeline 1612 und/oder Bilddaten und Speicherobjekte für die Medienpipeline 1616. Die 3D-Pipeline 1612 und die Medienpipeline 1616 verarbeiten die Befehle und Daten, indem sie Operationen über Logik innerhalb der jeweiligen Pipelines durchführen oder einen oder mehrere Ausführungs-Threads an das Grafikkern-Array 1714 verschicken. Das Grafikkern-Array 1714 kann einen oder mehrere Blöcke aus Grafikkernen (z.B. Grafikkern(e) 1715A, Grafikkern(e) 1715B) aufweisen, wobei jeder Block einen oder mehrere Grafikkerne aufweist. Jeder Grafikkern weist einen Satz aus Grafikausführungsressourcen auf, der Allzweck- und grafikspezifische Ausführungslogik zum Durchführen von Grafik- und Rechenoperationen sowie Festfunktions-Texturverarbeitungs- und/oder Maschinenlern- und KI-Beschleunigungslogik aufweist.
  • In verschiedenen Ausführungsformen kann die 3D-Pipeline 1612 Festfunktions- und programmierbare Logik enthalten, um ein oder mehrere Schattierprogramme wie beispielsweise Vertex-Shader, Geometrie-Shader, Pixel-Shader, Fragment-Shader, Rechen-Shader oder andere Schattierprogramme zu verarbeiten, indem die Anweisungen verarbeitet und Ausführungs-Threads an das Grafikkern-Array 1714 verschickt werden. Das Grafikkern-Array 1714 stellt einen vereinheitlichten Block aus Ausführungsressourcen zur Verwendung bei der Verarbeitung dieser Schattierprogramme bereit. Mehrzweck-Ausführungslogik (z.B. Ausführungseinheiten) innerhalb des oder der Grafikkerne 1715A bis 1715B des Grafikkern-Arrays 1714 umfasst Unterstützung für verschiedene 3D-API-Shader-Sprachen und kann mehrere gleichzeitige Ausführungs-Threads ausführen, die mit mehreren Shadem verbunden sind.
  • Das Grafikkern-Array 1714 kann Ausführungslogik zum Durchführen von Medienfunktionen wie beispielsweise Video- und/oder Bildverarbeitung aufweisen. Die Ausführungseinheiten können Allzwecklogik aufweisen, die so programmierbar ist, dass sie zusätzlich zu den Grafikverarbeitungsoperationen parallele Allzweck-Rechenoperationen durchführt. Die Allzwecklogik kann Verarbeitungsoperationen parallel zu oder zusammen mit Allzwecklogik in dem oder den Prozessorkernen 1407 aus 14 oder dem Kern 1502A bis 1502N wie in 15A durchführen.
  • Ausgabedaten, die von Threads erzeugt werden, die auf dem Grafikkern-Array 1714 ausgeführt werden, können in einem vereinheitlichten Rückgabepuffer (Unified Return Buffer, URB) 1718 an den Speicher ausgegeben werden. Der URB 1718 kann Daten für mehrere Threads speichern. Der URB 1718 kann verwendet werden, um Daten zwischen verschiedenen auf dem Grafikkern-Array 1714 ausgeführten Threads zu senden. Der URB 1718 kann zusätzlich für Synchronisierung zwischen Threads auf dem Grafikkern-Array 1714 und Festfunktionslogik innerhalb der gemeinsamen Funktionslogik 1720 verwendet werden.
  • Wahlweise kann das Grafikkern-Array 1714 skalierbar sein, derart, dass das Array eine variable Anzahl an Grafikkernen aufweist, die jeweils über eine variable Anzahl an Ausführungseinheiten verfügen, basierend auf der Zielleistung und dem Leistungsniveau der GPE 1710. Die Ausführungsressourcen können dynamisch skalierbar sein, derart, dass die Ausführungsressourcen nach Bedarf aktiviert und deaktiviert werden können.
  • Das Grafikkern-Array 1714 ist mit gemeinsamer Funktionslogik 1720 gekoppelt, die mehrere Ressourcen aufweist, die von den Grafikkernen im Grafikkern-Array gemeinsam verwendet werden. Bei den gemeinsam verwendeten Funktionen innerhalb der gemeinsamen Funktionslogik 1720 handelt es sich um Hardware-Logikeinheiten, die dem Grafikkern-Array 1714 spezialisierte ergänzende Funktionalität bereitstellen. In verschiedenen Ausführungsformen umfasst die gemeinsame Funktionslogik 1720, ohne jedoch hierauf eingeschränkt zu sein, Sampler- 1721, Mathe-1722 und Inter-Thread-Kommunikations- (ITC-) 1723 Logik. Zusätzlich können ein oder mehrere Caches 1725 innerhalb der gemeinsamen Funktionslogik 1720 implementiert werden.
  • Eine gemeinsam verwendete Funktion wird zumindest in dem Fall implementiert, in dem die Nachfrage nach einer bestimmten spezialisierten Funktion nicht ausreicht, um sie in das Grafikkern-Array 1714 aufzunehmen. Stattdessen wird eine einzelne Instantiierung dieser spezialisierten Funktion als eigenständige Einheit in der gemeinsamen Funktionslogik 1720 implementiert und von den Ausführungsressourcen innerhalb des Grafikkern-Arrays 1714 gemeinsam verwendet. Der genaue Satz aus Funktionen, die innerhalb des Grafikkern-Arrays 1714 gemeinsam verwendet werden und in dem Grafikkern-Array 1714 umfasst sind, variiert je nach Ausführungsform. Bestimmte gemeinsam verwendete Funktionen innerhalb der gemeinsamen Funktionslogik 1720, die von dem Grafikkern-Array 1714 intensiv genutzt werden, können in der gemeinsamen Funktionslogik 1716 innerhalb des Grafikkern-Arrays 1714 umfasst sein. Wahlweise kann die gemeinsame Funktionslogik 1716 innerhalb des Grafikkern-Arrays 1714 einen Teil der oder die gesamte Logik innerhalb der gemeinsamen Funktionslogik 1720 umfassen. Alle in der gemeinsamen Funktionslogik 1720 befindlichen Logikelemente können innerhalb der gemeinsamen Funktionslogik 1716 des Grafikkern-Arrays 1714 dupliziert werden. Alternativ wird die gemeinsame Funktionslogik 1720 zugunsten der gemeinsamen Funktionslogik 1716 innerhalb des Grafikkern-Arrays 1714 ausgeschlossen.
  • Ausführungseinheiten
  • 18A bis 18B veranschaulichen Thread-Ausführungslogik 1800 einschließlich eines Arrays in einem Grafikprozessorkern eingesetzter Verarbeitungselemente gemäß vorliegend beschriebenen Ausführungsformen. Die Elemente aus 18A bis 18B, die die gleichen oder ähnliche Namen wie die Elemente einer anderen vorliegend enthaltenen Figur haben, beschreiben die gleichen Elemente wie in den anderen Figuren, können in ähnlicher Weise arbeiten oder funktionieren, können die gleichen Komponenten umfassen und können mit anderen Einheiten verbunden sein, wie die, die vorliegend an anderer Stelle beschrieben sind, ohne jedoch hierauf eingeschränkt zu sein. 18A bis 18B veranschaulichen eine Übersicht einer Thread-Ausführungslogik 1800, die repräsentativ für mit jedem Teilkern 1521A bis 1521F aus 15B veranschaulichte Hardware-Logik sein kann. 18A repräsentiert eine Ausführungseinheit innerhalb eines Allzweck-Grafikprozessors, während 18B eine Ausführungseinheit repräsentiert, die innerhalb eines Rechenbeschleunigers verwendet werden kann.
  • Wie in 18A veranschaulicht, kann die Thread-Ausführungslogik 1800 einen Schattierprozessor 1802, einen Thread-Dispatcher 1804, einen Anweisungscache 1806, ein skalierbares Ausführungseinheiten-Array mit einer Vielzahl von Grafikausführungseinheiten 1808A bis 1808N, einen Sampler 1810, einen gemeinsam genutzten lokalen Speicher 1811, einen Datencache 1812 und einen Datenport 1814 umfassen. Wahlweise kann das skalierbare Ausführungseinheiten-Array auf Grundlage der Rechenanforderungen einer Arbeitslast durch Aktivieren oder Deaktivieren einer oder mehrerer Ausführungseinheiten (z.B. beliebiger der Grafikausführungseinheiten 1808A, 1808B, 1808C, 1808D bis 1808N-1 und 1808N) dynamisch skalieren. Die umfassten Komponenten können über ein Verbindungs-Fabric, das mit jeder der Komponenten verbunden ist, untereinander verbunden sein. Die Thread-Ausführungslogik 1800 kann eine oder mehrere Verbindungen mit Speicher, beispielsweise dem Systemspeicher oder dem Cachespeicher, über den Anweisungscache 1806, den Datenport 1814, den Sampler 1810 und/oder die Grafikausführungseinheiten 1808A bis 1808N aufweisen. Bei jeder Ausführungseinheit (z.B. 1808A) kann es sich um eine eigenständige programmierbare Allzweck-Recheneinheit handeln, die in der Lage ist, mehrere gleichzeitige Hardware-Threads auszuführen und dabei mehrere Datenelemente parallel für jeden Thread zu verarbeiten. In verschiedenen Ausführungsformen ist das Array aus Ausführungseinheiten 1808A bis 1808N so skalierbar, dass es eine beliebige Anzahl individueller Ausführungseinheiten aufweist.
  • In einigen Ausführungsformen können die Grafikausführungseinheiten 1808A bis 1808N primär verwendet werden, um Schattierprogramme auszuführen. Ein Schattierprozessor 1802 kann die verschiedenen Schattierprogramme verarbeiten und den Schattierprogrammen zugehörige Ausführungs-Threads über einen Thread-Dispatcher 1804 verschicken. Der Thread-Dispatcher kann Logik aufweisen, um Thread-Initiierungsanfragen von den Grafik- und Medienpipelines zu vermitteln und die angefragten Threads auf einer oder mehreren Ausführungseinheiten in den Grafikausführungseinheiten 1808A bis 1808N zu instantiieren. Beispielsweise kann eine Geometriepipeline Vertex-, Tesselations- oder Geometrie-Shader an die Thread-Ausführungslogik zur Verarbeitung verschicken. Wahlweise kann der Thread-Dispatcher 1804 zudem zur Laufzeit von den ausgeführten Schattierprogrammen erfolgende Thread-Erzeugungsanfragen verarbeiten.
  • In einigen Ausführungsformen können die Grafikausführungseinheiten 1808A bis 1808N einen Befehlssatz unterstützen, der native Unterstützung für viele standardmäßige 3D-Grafik-Schattieranweisungen umfasst, derart, dass Schattierprogramme aus 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 bis 1808N ist in der Lage, Mehrfachausgabe-SIMD (Single Instruction Multiple Data) auszuführen, und der Multi-Thread-Betrieb ermöglicht eine effiziente Ausführungsumgebung angesichts von Speicherzugriffen mit höherer Latenz. Jeder Hardware-Thread innerhalb jeder Ausführungseinheit hat eine dedizierte Registerdatei mit hoher Bandbreite und einen zugehörigen unabhängigen Thread-Status. Die Ausführung erfolgt in Mehrfachausgabe pro Takt an Pipelines, die Ganzzahl-, einfach und doppelt präzise Gleitkommaoperationen, SIMD-Verzweigung, logische Operationen, transzendente Operationen und verschiedene andere Operationen ausführen können. Während des Wartens auf Daten aus dem Speicher oder einer der gemeinsam genutzten Funktionen veranlasst Abhängigkeitslogik innerhalb der Ausführungseinheiten 1808A bis 1808N einen wartenden Thread zum Schlafen, bis die angefragten Daten zurückgegeben wurden. Während der wartende Thread schläft, können sich Hardware-Ressourcen der Verarbeitung anderer Threads widmen. Beispielsweise kann während einer Verzögerung in Zusammenhang mit einer Operation eines Vertex-Shaders eine Ausführungseinheit Operationen für einen Pixel-Shader, Fragment-Shader oder eine andere Art von Schattierprogramm ausführen, einschließlich eines anderen Vertex-Shaders, beispielsweise der in 21 veranschaulichte Vertex-Shader 2107. Verschiedene Ausführungsformen können die Ausführung unter Verwendung von SIMT (Single Instruction Multiple Thread) als Alternative zur Verwendung von SIMD oder zusätzlich zur Verwendung von SIMD betreffen. Bezugnahmen auf einen SIMD-Kern oder -Betrieb können ebenso SIMT oder SIMD in Kombination mit SIMT betreffen.
  • Jede Ausführungseinheit der Grafikausführungseinheiten 1808A bis 1808N arbeitet mit Anordnungen aus Datenelementen. Die Anzahl an Datenelementen ist die „Ausführungsgröße“ oder die Anzahl an Kanälen für die Anweisung. Ein Ausführungskanal ist eine logische Ausführungseinheit für Datenelementzugriff, Maskierung und Flusskontrolle innerhalb von Anweisungen. Die Anzahl der Kanäle kann unabhängig von der Anzahl physischer arithmetisch-logischer Einheiten (ALUs), Gleitkommaeinheiten (FPUs) oder anderer Logikeinheiten (z.B. Tensorkerne, Strahlverfolgungskerne usw.) eines bestimmten Grafikprozessors sein. Zusätzlich können die Grafikausführungseinheiten 1808A bis 1808N Ganzzahl- und Gleitkomma-Datentypen unterstützen.
  • Der Befehlssatz für die Ausführungseinheiten umfasst SIMD-Anweisungen. Die verschiedenen Datenelemente können als gepackter Datentyp in einem Register gespeichert werden, und die Ausführungseinheit wird die verschiedenen Elemente auf Grundlage der Datengröße der Elemente verarbeiten. Wenn beispielsweise ein 256 Bit breiter Vektor bearbeitet wird, werden die 256 Bits des Vektors in einem Register gespeichert, und die Ausführungseinheit bearbeitet den Vektor als vier separate gepackte 184-Bit-Datenelemente (Datenelemente der Größe Quad-Word (QW)), acht separate gepackte 32-Bit-Datenelemente (Datenelemente der Größe Double Word (DW)), sechzehn separate gepackte 16-Bit-Datenelemente (Datenelemente der Größe Word (W)) oder zweiunddreißig separate 8-Bit-Datenelemente (Datenelemente der Größe Byte (B)). Es sind jedoch auch andere Vektorbreiten und Registergrößen möglich.
  • Wahlweise können eine oder mehrere Ausführungseinheiten zu einer verschmolzenen Grafikausführungseinheit 1809A bis 1809N mit Thread-Steuerlogik (1807A bis 1807N) kombiniert werden, die den verschmolzenen EUs gemeinsam ist. Mehrere EUs können zu einer EU-Gruppe verschmolzen werden. Jede EU in der verschmolzenen EU-Gruppe kann dafür konfiguriert sein, einen separaten SIMD-Hardware-Thread auszuführen. Die Anzahl an EUs in einer verschmolzenen EU-Gruppe kann gemäß Ausführungsformen variieren. Zusätzlich können pro EU verschiedene SIMD-Breiten durchgeführt werden, darunter, ohne jedoch hierauf eingeschränkt zu sein, SIMD8, SIMD16 und SIMD32. Jede verschmolzene Grafikausführungseinheit 1809A bis 1809N weist mindestens zwei Ausführungseinheiten auf. Beispielsweise weist die verschmolzene Ausführungseinheit 1809A eine erste EU 1808A, eine zweite EU 1808B und Thread-Steuerlogik 1807A auf, die der ersten EU 1808A und der zweiten EU 1808B gemeinsam ist. Die Thread-Steuerlogik 1807A steuert auf der verschmolzenen Grafikausführungseinheit 1809A ausgeführte Threads, wodurch jede EU innerhalb der verschmolzenen Ausführungseinheiten 1809A bis 1809N mittels eines gemeinsamen Befehlszeigerregisters ausgeführt werden kann.
  • In der Thread-Ausführungslogik 1800 sind ein oder mehrere interne Anweisungscaches (z.B. 1806) umfasst, um Thread-Anweisungen für die Ausführungseinheiten zwischenzuspeichern. Ein oder mehrere Datencaches (z.B. 1812) können in der Thread-Ausführungslogik 1800 enthalten sein, um Thread-Daten während der Thread-Ausführung zwischenzuspeichern. Auf der Ausführungslogik 1800 ausgeführte Threads können zudem explizit verwaltete Daten im gemeinsamen lokalen Speicher 1811 speichern. Ein Sampler 1810 kann umfasst sein, um Textursampling (-abtastung) für 3D-Operationen und Mediensampling (-abtastung) für Medienoperationen bereitzustellen. Der Sampler 1810 kann spezialisierte Textur- oder Mediensampling-Funktionalität aufweisen, um Textur- oder Mediendaten während des Samplingprozesses zu verarbeiten, bevor die gesampelten Daten einer Ausführungseinheit bereitgestellt werden.
  • Während der Ausführung senden die Grafik- und Medienpipelines über Thread-Erzeugungs- und -Dispatch-Logik Thread-Initiierungsanfragen an die Thread-Ausführungslogik 1800. Sobald eine Gruppe geometrischer Objekte verarbeitet und in Pixeldaten gerastert wurde, wird Pixelprozessorlogik (z.B. Pixel-Shader-Logik, Fragment-Shader-Logik usw.) innerhalb des Schattierprozessors 1802 aufgerufen, um Ausgabeinformationen weiter zu berechnen und zu veranlassen, dass Ergebnisse in Ausgabeflächen (z.B. Farbpuffer, Tiefenpuffer, Schablonenpuffer usw.) geschrieben werden. Ein Pixel-Shader oder Fragment-Shader kann die Werte der verschiedenen Vertex-Attribute berechnen, die über das gerasterte Objekt interpoliert werden sollen. Anschließend kann die Pixelprozessorlogik innerhalb des Schattierprozessors 1802 ein durch eine Anwendungsprogrammierschnittstelle (Application Programming Interface, API) bereitgestelltes Pixel- oder Fragment-Schattierprogramm ausführen. Zur Ausführung des Schattierprogramms verschickt der Schattierprozessor 1802 über einen Thread-Dispatcher 1804 Threads an eine Ausführungseinheit (z.B. 1808A). Der Schattierprozessor 1802 kann Textursamplinglogik im Sampler 1810 verwenden, um auf Texturdaten in Texturkarten zuzugreifen, die im Speicher gespeichert sind. Arithmetische Operationen an den Texturdaten und den Eingangsgeometriedaten berechnen Pixelfarbdaten für jedes geometrische Fragment oder verwerfen ein oder mehrere Pixel von der weiteren Verarbeitung.
  • Zusätzlich kann der Datenport 1814 einen Speicherzugriffsmechanismus bereitstellen, damit die Thread-Ausführungslogik 1800 verarbeitete Daten zur weiteren Verarbeitung auf einer Grafikprozessor-Ausgabepipeline an den Speicher ausgeben kann. Der Datenport 1814 kann einen oder mehrere Cachespeicher (z.B. den Datencache 1812) aufweisen oder mit diesen gekoppelt sein, um Daten für Speicherzugriff über den Datenport 1814 zwischenzuspeichern.
  • Wahlweise kann die Ausführungslogik 1800 zudem einen Strahlverfolger 1805 aufweisen, der Beschleunigungsfunktionalität für Strahlverfolgung bereitstellen kann. Der Strahlverfolger 1805 kann einen Strahlverfolgungsbefehlssatz unterstützen, der Anweisungen/Funktionen für Strahlerzeugung umfasst. Der Strahlverfolgungsbefehlssatz kann dem von den Strahlverfolgungskernen 372 in 3C unterstützten Strahlverfolgungsbefehlssatz ähneln oder sich von diesem unterscheiden.
  • 18B veranschaulicht beispielhafte interne Einzelheiten einer Ausführungseinheit 1808. Eine Grafikausführungseinheit 1808 kann eine Anweisungsabrufeinheit 1837, ein Allgemeinregisterdatei-Array (General Register File, GRF) 1824, ein Architekturregisterdatei-Array (Architectural Register File, ARF) 1826, einen Thread-Vermittler 1822, eine Sendeeinheit 1830, eine Verzweigungseinheit 1832, einen Satz SIMD-Gleitkommaeinheiten (FPUs) 1834 und wahlweise einen Satz dedizierter Ganzzahl-SIMD-ALUs 1835 aufweisen. Das GRF 1824 und das ARF 1826 weisen den Satz aus Allgemeinregisterdateien und Architekturregisterdateien auf, der zu jedem simultanen Hardware-Thread gehört, der in der Grafikausführungseinheit 1808 aktiv sein kann. Es kann ein Architekturstatus pro Thread im ARF 1826 behalten werden, während im GRF 1824 während der Thread-Ausführung verwendete Daten gespeichert werden. Der Ausführungsstatus jedes Threads, einschließlich der Anweisungszeiger für jeden Thread, kann in Thread-spezifischen Registern im ARF 1826 gehalten werden.
  • Die Grafikausführungseinheit 1808 kann über eine Architektur verfügen, bei der es sich um eine Kombination aus gleichzeitigem Multi-Threading (Simultaneous Multi-Threading, SMT) und feinkörnigem verschachteltem Multi-Threading (fine-grained Interleaved Multi-Threading, IMT) handelt. Die Architektur kann über eine modulare Konfiguration verfügen, die zur Entwurfszeit auf Grundlage einer Zielanzahl gleichzeitiger Threads und einer Anzahl an Registern pro Ausführungseinheit feinabgestimmt werden kann, wobei Ressourcen der Ausführungseinheit auf zum Ausführen mehrerer gleichzeitiger Threads verwendete Logik aufgeteilt werden. Die Anzahl logischer Threads, die von der Grafikausführungseinheit 1808 ausgeführt werden können, ist nicht auf die Anzahl an Hardware-Threads begrenzt, und jedem Hardware-Thread können mehrere logische Threads zugewiesen werden.
  • Wahlweise kann die Grafikausführungseinheit 1808 mehrere Anweisungen zusammen ausgeben, bei denen es sich um verschiedene Anweisungen handeln kann. Der Thread-Vermittler 1822 der Grafikausführungseinheit 1808 kann die Anweisungen zur Ausführung an entweder die Sendeeinheit 1830, die Verzweigungseinheit 1832 oder die SIMD-FPU(s) 1834 verschicken. Jeder Ausführungs-Thread kann auf 128 Allzweckregister innerhalb des GRF 1824 zugreifen, wobei jedes Register 32 Bytes speichern kann, die als SIMD-8-Element-Vektor aus 32-Bit-Datenelementen verfügbar sind. Jeder Thread der Ausführungseinheit kann Zugriff auf 4 Kbytes innerhalb des GRF 1824 haben, wobei Ausführungsformen hierauf jedoch nicht eingeschränkt sind und in anderen Ausführungsformen mehr oder weniger Registerressourcen bereitgestellt sein können. Die Grafikausführungseinheit 1808 kann in sieben Hardware-Threads partitioniert sein, die unabhängig Rechenoperationen durchführen können, wobei jedoch die Anzahl an Threads pro Ausführungseinheit ebenfalls je nach Ausführungsform variieren kann und beispielsweise bis zu 16 Hardware-Threads unterstützt werden können. 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 weiteren beispielhaften Ausführungsform kann das GRF 1824, wenn 16 Threads auf 4 Kbytes zugreifen können, insgesamt 64 Kbytes speichern. Die Anzahl an Threads pro Ausführungseinheit ist jedoch nicht auf diese Beispiele eingeschränkt und kann mehr oder weniger als die angegebenen Anzahlen betragen. Flexible Adressierungsmodi können es erlauben, Register gemeinsam zu adressieren, um effektiv breitere Register zu bilden oder um abgemessene rechteckige Blockdatenstrukturen darzustellen.
  • Zusätzlich oder alternativ können Speicheroperationen, Sampleroperationen und andere Systemkommunikationen mit längerer Latenzzeit über „Sende“-Anweisungen verschickt werden, die von der Nachrichten weiterleitenden Sendeeinheit 1830 ausgeführt werden. Verzweigungsanweisungen können an eine dedizierte Verzweigungseinheit 1832 verschickt 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 zudem Ganzzahlberechnungen unterstützen. In einer Ausführungsform können die FPU(s) 1834 eine Anzahl von bis zu M 32-Bit-Gleitkomma- (oder Ganzzahl-) Operationen SIMD-ausführen oder bis zu 2M 16-Bit-Ganzzahl- oder 16-Bit-Gleitkommaoperationen SIMD-ausführen. Wahlweise bietet mindestens eine der FPU(s) erweiterte mathematische Fähigkeiten, um transzendente mathematische Funktionen mit hohem Durchsatz und 184-Bit-Gleitkomma mit doppelter Präzision zu unterstützen. Zudem kann ein Satz aus 8-Bit-Ganzzahl-SIMD-ALUs 1835 vorhanden sein, der speziell zur Durchführung von Operationen in Zusammenhang mit Maschinenlemberechnungen optimiert ist.
  • Wahlweise können Arrays aus mehreren Instanzen der Grafikausführungseinheit 1808 in einer Grafikteilkerngruppierung (z.B. einem Teilbaustein) instantiiert werden. Für Skalierbarkeit können Produktarchitekten die genaue Anzahl an Ausführungseinheiten pro Teilkerngruppierung wählen. Die Ausführungseinheit 1808 kann Anweisungen über eine Vielzahl von Ausführungskanälen hinweg ausführen. Zudem kann jeder auf der Grafikausführungseinheit 1808 ausgeführte Thread auf einem anderen Kanal ausgeführt werden.
  • 19 zeigt eine weitere beispielhafte Ausführungseinheit 1900. Die Elemente aus 19, die die gleichen oder ähnliche Namen wie die Elemente einer anderen vorliegend enthaltenen Figur haben, beschreiben die gleichen Elemente wie in den anderen Figuren, können in ähnlicher Weise arbeiten oder funktionieren, können die gleichen Komponenten umfassen und können mit anderen Einheiten verbunden sein, wie die, die vorliegend an anderer Stelle beschrieben sind, ohne jedoch hierauf eingeschränkt zu sein. Bei der Ausführungseinheit 1900 kann es sich um eine rechenoptimierte Ausführungseinheit zur Verwendung in beispielsweise einer Rechen-Engine-Kachel 1640A bis 1640D wie in 16C handeln, ohne jedoch hierauf eingeschränkt zu sein. Die Ausführungseinheit 1900 kann zudem in einer Grafik-Engine-Kachel 1610A bis 1610D wie in 16B verwendet werden. Die Ausführungseinheit 1900 kann eine Thread-Steuereinheit 1901, eine Thread-Statuseinheit 1902, eine Befehlsabruf- /Vorabrufeinheit 1903 und eine Anweisungsdecodiereinheit 1904 aufweisen. Die Ausführungseinheit 1900 kann zusätzlich eine Registerdatei 1906 aufweisen, die Register speichert, die Hardware-Threads innerhalb der Ausführungseinheit zugewiesen werden können. Die Ausführungseinheit 1900 kann zusätzlich eine Sendeeinheit 1907 und eine Verzweigungseinheit 1908 aufweisen. Die Sendeeinheit 1907 und die Verzweigungseinheit 1908 können ähnlich wie die Sendeeinheit 1830 und eine Verzweigungseinheit 1832 der Grafikausführungseinheit 1808 aus 18B arbeiten.
  • Die Ausführungseinheit 1900 kann zudem eine Recheneinheit 1910 aufweisen, die mehrere verschiedene Arten von Funktionseinheiten umfasst. Die Recheneinheit 1910 kann zudem eine ALU 1911, ein systolisches Array 1912 und eine Mathematikeinheit 1913 aufweisen. Die ALU 1911 weist ein Array aus arithmetischlogischen Einheiten auf. Die ALU 1911 kann so konfiguriert sein, dass sie 64-Bit-, 32-Bit- und 16-Bit-Ganzzahl- und Gleitkommaoperationen über mehrere Verarbeitungsspuren und Datenkanäle und für mehrere Hardware- und/oder Software-Threads ausführt. Die ALU 1911 kann Ganzzahl- und Gleitkomma-Operationen gleichzeitig (z.B. innerhalb desselben Taktzyklus) durchführen.
  • Das systolische Array 1912 weist ein W breites und D tiefes Netzwerk aus Datenverarbeitungseinheiten auf, das verwendet werden kann, um Vektor- und andere datenparallele Operationen systolisch durchzuführen. Das systolische Array 1912 kann so konfiguriert sein, dass es verschiedene Matrixoperationen durchführt, wie z.B. Punktprodukt, äußeres Produkt und allgemeine Matrix-Matrix-Multiplikations- (GEMM- ) Operationen. Das systolische Array 1912 kann sowohl 16-Bit-Gleitkommaoperationen als auch 8-Bit-, 4-Bit-, 2-Bit- und binäre Ganzzahloperationen unterstützen. Das systolische Array 1912 kann dafür konfiguriert sein, Maschinenlernoperationen zu beschleunigen. Das systolische Array 1912 kann mit Unterstützung für bfloat16, (brain floating point) 16-Bit-Gleitkommaformat oder ein Tensor-Float-32-Bit-Gleitkommaformat (TF32) konfiguriert sein, die andere Anzahlen an Mantissen- und Exponentenbits in Bezug auf Institute of Electrical and Electronics Engineers (IEEE) 754-Formate haben. Es können auch FP64-Formate unterstützt werden.
  • In einer Ausführungsform weist das systolische Array 1912 Hardware auf, um Sparse-Matrix-Operationen zu beschleunigen. Multiplikationsoperationen für spärlich besetzte Regionen der Eingabedaten können ohne Einbußen beim Durchsatz umgangen werden. Die Blockspärlichkeit innerhalb von Eingabematrizen kann erkannt werden und Operationen mit bekannten Ausgabewerten 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 spärlich besetzten Matrix speichert Nicht-Nullwerte und Metadaten, die die Position der Nicht-Nullwerte innerhalb der Matrix definieren. Beispielhafte komprimierte Darstellungen umfassen, ohne jedoch hierauf eingeschränkt zu sein, komprimierte Tensordarstellungen wie Compressed-Sparse-Row- (CSR-), Compressed-Sparse-Column- (CSC-), Compressed-Sparse-Fiber- (CSF-) Darstellungen. Die Unterstützung von komprimierten Darstellungen ermöglicht es, Operationen an Eingaben in einem komprimierten Tensorformat durchzuführen, ohne dass die komprimierte Darstellung dekomprimiert oder decodiert werden muss. In einer solchen Ausführungsform können Operationen nur an Nicht-Null-Eingabewerten durchgeführt werden und die resultierenden Nicht-Null-Ausgabewerte können in eine Ausgabematrix abgebildet werden. In einigen Ausführungsformen wird auch Hardware-Unterstützung für maschinenspezifische verlustfreie Datenkomprimierungsformate bereitgestellt, die bei der Übertragung von Daten innerhalb der Hardware oder über Systembusse verwendet werden. Solche Daten können in einem komprimierten Format für spärliche Eingabedaten beibehalten werden, und das systolische Array 1912 kann die Komprimierungs-Metadaten für die komprimierten Daten verwenden, um die Durchführung von Operationen nur an Nicht-Nullwerten zu ermöglichen, oder um Blöcke mit Null-Dateneingabe für Multiplikationsoperationen zu umgehen.
  • Eine Mathematikeinheit 1913 kann dafür konfiguriert sein, einen bestimmten Teilsatz mathematischer Operationen effizient und stromsparender als die ALU-Einheit 1911 durchzuführen. Die Mathematikeinheit 1913 kann Mathelogik umfassen, die in gemeinsamer Funktionslogik einer Grafikverarbeitungs-Engine zu finden sein kann, die durch andere beschriebene Ausführungsformen bereitgestellt ist, z.B. die Mathelogik 1722 der gemeinsamen Funktionslogik 1720 aus 17. Die Mathelogik 1913 kann dafür konfiguriert sein, 32-Bit- und 64-Bit-Gleitkommaoperationen durchzuführen.
  • Die Thread-Steuereinheit 1901 weist Logik zum Steuern der Ausführung von Threads innerhalb der Ausführungseinheit auf Die Thread-Steuereinheit 1901 kann Thread-Vermittlungslogik aufweisen, um die Ausführung von Threads innerhalb der Ausführungseinheit 1900 zu starten, zu stoppen und zurückzustellen. Die Thread-Statuseinheit 1902 kann verwendet werden, um einen Thread-Status für zur Ausführung auf der Ausführungseinheit 1900 zugewiesene Threads zu speichern. Das Speichern des Thread-Status innerhalb der Ausführungseinheit 1900 ermöglicht die schnelle Zurückstellung von Threads, wenn diese Threads blockiert oder untätig werden. Die Anweisungsabruf/-vorabrufeinheit 1903 kann Anweisungen aus einem Anweisungscache einer übergeordneten Ausführungslogik (z.B. Anweisungscache 1806 wie in 18A) abrufen. Die Anweisungsabruf/-vorabrufeinheit 1903 kann auch auf Grundlage einer Analyse aktuell ausgeführter Threads Vorabrufanfragen für Anweisungen ausgeben, die in den Anweisungscache geladen werden sollen. Die Anweisungsdecodiereinheit 1904 kann verwendet werden, um von den Recheneinheiten auszuführende Anweisungen zu decodieren. Die Anweisungsdecodiereinheit 1904 kann als sekundärer Decodierer verwendet werden, um komplexe Anweisungen in einzelne Mikrooperationen zu decodieren.
  • Die Ausführungseinheit 1900 weist zusätzlich eine Registerdatei 1906 auf, die von auf der Ausführungseinheit 1900 ausgeführten Hardware-Threads verwendet werden kann. Register in der Registerdatei 1906 können auf die zum Ausführen mehrerer gleichzeitiger Threads innerhalb der Recheneinheit 1910 der Ausführungseinheit 1900 verwendete Logik aufgeteilt werden. Die Anzahl logischer Threads, die von der Grafikausführungseinheit 1900 ausgeführt werden können, ist nicht auf die Anzahl an Hardware-Threads begrenzt, und jedem Hardware-Thread können mehrere logische Threads zugewiesen werden. Die Größe der Registerdatei 1906 kann je nach Ausführungsform auf Grundlage der Anzahl unterstützter Hardware-Threads variieren. Registerumbenennung kann verwendet werden, um Register dynamisch Hardware-Threads zuzuteilen.
  • 20 ist ein Blockschaubild, das Grafikprozessor-Anweisungsformate 2000 veranschaulicht. Die Grafikprozessor-Ausführungseinheiten unterstützen einen Befehlssatz mit Anweisungen in mehreren Formaten. Die Kästen mit durchgehenden Linien veranschaulichen die Komponenten, die grundsätzlich in einer Anweisung einer Ausführungseinheit umfasst sind, während die gestrichelten Linien Komponenten umfassen, die optional sind oder die nur in einem Teilsatz der Anweisungen umfasst sind. In einigen Ausführungsformen handelt es sich bei den beschriebenen und abgebildeten Grafikprozessor-Anweisungsformaten 2000 um Makroanweisungen, d.h. um Anweisungen, die der Ausführungseinheit zugeführt werden, im Gegensatz zu Mikrooperationen, die sich aus der Anweisungsdecodierung ergeben, sobald die Anweisung verarbeitet wurde. So kann eine einzelne Anweisung die Hardware veranlassen, mehrere Mikrooperationen auszuführen.
  • Die vorliegend beschriebenen Grafikprozessor-Ausführungseinheiten können nativ Anweisungen in einem 128-Bit-Anweisungsformat 2010 unterstützen. Auf Grundlage der ausgewählten Anweisung, der Anweisungsoptionen und der Anzahl an Operanden ist für einige Anweisungen ein komprimiertes 64-Bit-Anweisungsformat 2030 verfügbar. Das native 128-Bit-Anweisungsformat 2010 bietet Zugriff auf alle Anweisungsoptionen, während einige Optionen und Operationen im 64-Bit-Format 2030 eingeschränkt sind. Die im 64-Bit-Format 2030 verfügbaren nativen Anweisungen variieren je nach Ausführungsform. Die Anweisung wird zum Teil anhand eines Satzes von Indexwerten in einem Indexfeld 2013 komprimiert. Die Hardware der Ausführungseinheit referenziert einen Satz von Komprimierungstabellen auf Grundlage der Indexwerte und verwendet die Ausgaben der Komprimierungstabellen, um eine native Anweisung im 128-Bit-Anweisungsformat 2010 zu rekonstruieren. Es können auch andere Anweisungsgrößen und -formate verwendet werden.
  • Für jedes Format definiert ein Anweisungs-Opcode 2012 die Operation, die die Ausführungseinheit durchführen soll. Die Ausführungseinheiten führen jede Anweisung parallel über die mehreren Datenelemente jedes Operanden hinweg aus. Beispielsweise führt in Reaktion auf eine Addieranweisung die Ausführungseinheit eine gleichzeitige Addieroperation auf jedem Farbkanal durch, der ein Texturelement oder Bildelement darstellt. Standardmäßig führt die Ausführungseinheit jede Anweisung über alle Datenkanäle der Operanden hinweg durch. Ein Anweisungssteuerfeld 2014 kann die Steuerung bestimmter Ausführungsoptionen wie beispielsweise Kanalauswahl (z.B. Prädikation) und die Datenkanalreihenfolge (z.B. Swizzling) ermöglichen. Für Anweisungen im 128-Bit-Anweisungsformat 2010 begrenzt ein Ausf.-Größe-Feld 2016 die Anzahl an Datenkanälen, die parallel ausgeführt werden. Ein Ausf.-Größe-Feld 2016 ist möglicherweise nicht für die Verwendung im kompakten 64-Bit-Anweisungsformat 2030 verfügbar.
  • Einige Anweisungen der Ausführungseinheiten verfügen über bis zu drei Operanden, darunter zwei Quelloperanden src0 2020, src1 2022 sowie einen Zieloperanden 2018. Die Ausführungseinheiten können Anweisungen mit zwei Zielen unterstützen, wobei eines der Ziele implizit ist. Datenmanipulationsanweisungen können über einen dritten Quelloperanden (z.B. SRC2 2024) verfügen, wobei der Anweisungs-Opcode 2012 die Anzahl an Quelloperanden bestimmt. Beim letzten Quelloperanden einer Anweisung kann es sich um einen unmittelbaren (z.B. hartcodierten) Wert handeln, der mit der Anweisung weitergegeben wird.
  • Das 128-Bit-Anweisungsformat 2010 kann ein Feld 2026 für den Zugriffs-/Adressierungsmodus aufweisen, das beispielsweise angibt, ob der direkte Registeradressierungsmodus oder der indirekte Registeradressierungsmodus verwendet wird. Wenn der direkte Registeradressierungsmodus verwendet wird, wird die Registeradresse eines oder mehrerer Operanden direkt durch Bits in der Anweisung angegeben.
  • Das 128-Bit-Anweisungsformat 2010 kann zudem ein Feld 2026 für den Zugriffs-/Adressierungsmodus aufweisen, das einen Adressierungsmodus und/oder einen Zugriffsmodus für die Anweisung angibt. Der Zugriffsmodus kann verwendet werden, um eine Datenzugriffsausrichtung für die Anweisung zu definieren. Es können Zugriffsmodi unterstützt werden, die einen 16-Byte-ausgerichteten Zugriffsmodus und einen 1 -Byte-ausgerichteten Zugriffsmodus umfassen, wobei die Byte-Ausrichtung des Zugriffsmodus die Zugriffsausrichtung der Anweisungsoperanden bestimmt. Beispielsweise kann in einem ersten Modus die Anweisung Byte-ausgerichtete Adressierung für Quell- und Zieloperanden verwenden, und in einem zweiten Modus kann die Anweisung 16-Byte-ausgerichtete Adressierung für alle Quell- und Zieloperanden verwenden.
  • Der Adressierungsmodusabschnitt des Felds 2026 für den Zugriffs-/Adressierungsmodus kann bestimmen, ob die Anweisung direkte oder indirekte Adressierung verwenden soll. Wenn der direkte Registeradressierungsmodus verwendet wird, geben Bits in der Anweisung direkt die Registeradresse eines oder mehrerer Operanden an. Wenn der indirekte Registeradressierungsmodus verwendet wird, kann die Registeradresse eines oder mehrerer Operanden auf Grundlage eines Adressregisterwerts und eines unmittelbaren Adressfelds in der Anweisung berechnet werden.
  • Anweisungen können auf Grundlage von Opcode- 2012 Bitfeldern gruppiert werden, um Opcode-Decodierung 2040 zu vereinfachen. Für einen 8-Bit-Opcode ermöglichen die Bits 4, 5 und 6 der Ausführungseinheit, den Opcode-Typ zu bestimmen. Die konkret gezeigte Opcode-Gruppierung ist lediglich beispielhaft. Eine Verschiebungs- und Logik-Opcode-Gruppe 2042 kann Datenverschiebungs- und Logikanweisungen (z.B. Verschiebe (mov), Vergleiche (cmp)) umfassen. Die Verschiebungs- und Logikgruppe 2042 kann sich die fünf niedrigstwertigen Bits (Least Significant Bits, LSBs) teilen, wobei Verschiebe- (mov-) Anweisungen in der Form 0000xxxxb und Logikanweisungen in der Form 0001xxxxb vorliegen. Eine Anweisungsgruppe 2044 für Flusssteuerung (z.B. Rufe auf, Springe (jmp)) umfasst Anweisungen in der Form 0010xxxxb (z.B. 0x20). Eine Anweisungsgruppe 2046 für Verschiedenes umfasst eine Mischung aus Anweisungen, darunter Synchronisierungsanweisungen (z.B. Warte, Sende) in der Form 001 1xxxxb (z.B. 0x30). Eine Parallelmathe-Anweisungsgruppe 2048 umfasst komponentenweise arithmetische Anweisungen (z.B. Addiere, Multipliziere (mul)) in der Form 0100xxxxb (z.B. 0x40). Die Parallelmathe-Anweisungsgruppe 2048 führt die arithmetischen Operationen über Datenkanäle hinweg parallel durch. Die Vektormathegruppe 2050 umfasst arithmetische Anweisungen (z.B. dp4) in der Form 0101xxxxb (z.B. 0x50). Die Vektormathegruppe führt arithmetische Berechnungen wie beispielsweise Punktproduktberechnungen an Vektoroperanden durch. In einer Ausführungsform kann die veranschaulichte Opcode-Decodierung 2040 verwendet werden, um zu bestimmen, welcher Abschnitt einer Ausführungseinheit verwendet wird, um eine decodierte Anweisung auszuführen. Beispielsweise können einige Anweisungen als systolische Anwendungen bestimmt werden, die von einem systolischen Array durchgeführt werden. Andere Anweisungen wie beispielsweise Strahlverfolgungsanweisungen (nicht gezeigt) können zu einem Strahlverfolgungskern oder einer Strahlverfolgungslogik innerhalb eines Bausteins oder einer Partition der Ausführungslogik geleitet werden.
  • Grafikpipeline
  • 21 ist ein Blockschaubild eines Grafikprozessors 2100 gemäß einer weiteren Ausführungsform. Die Elemente aus 21, die die gleichen oder ähnliche Namen wie die Elemente einer anderen vorliegend enthaltenen Figur haben, beschreiben die gleichen Elemente wie in den anderen Figuren, können in ähnlicher Weise arbeiten oder funktionieren, können die gleichen Komponenten umfassen und können mit anderen Einheiten verbunden sein, wie die, die vorliegend an anderer Stelle beschrieben sind, ohne jedoch hierauf eingeschränkt zu sein.
  • Der Grafikprozessor 2100 kann verschiedene Arten von Grafikverarbeitungspipelines aufweisen, beispielsweise eine Geometriepipeline 2120, eine Medienpipeline 2130, eine Anzeige-Engine 2140, eine Thread-Ausführungslogik 2150 und eine Render-Ausgabepipeline 2170. Bei dem Grafikprozessor 2100 kann es sich um einen Grafikprozessor innerhalb eines Mehrkem-Verarbeitungssystems handeln, das einen oder mehrere Allzweck-Verarbeitungskerne aufweist. Der Grafikprozessor kann durch Register-Schreibvorgänge in ein oder mehrere Steuerregister (nicht gezeigt) oder über Befehle gesteuert werden, die über eine Ringverbindung 2102 an den Grafikprozessor 2100 ausgegeben werden. Die Ringverbindung 2102 kann den Grafikprozessor 2100 an andere Verarbeitungskomponenten wie beispielsweise andere Grafikprozessoren oder Allzweckprozessoren koppeln. Von der Ringverbindung 2102 kommende Befehle werden von einem Befehlsstreamer 2103 interpretiert, der Anweisungen an einzelne Komponenten der Geometriepipeline 2120 oder der Medienpipeline 2130 liefert.
  • In einigen Ausführungsformen kann der Befehlsstreamer 2103 den Betrieb eines Vertexabrufers 2105 lenken, der Vertexdaten aus dem Speicher liest und vom Befehlsstreamer 2103 bereitgestellte Vertexverarbeitungsbefehle ausführt. Der Vertexabrufer 2105 kann Vertexdaten an einen Vertex-Shader 2107 bereitstellen, der an jedem Vertex Koordinatenraumtransformation und Beleuchtungsoperationen durchführt. Der Vertexabrufer 2105 und der Vertex-Shader 2107 können Vertexverarbeitungsanweisungen ausführen, indem sie Ausführungs-Threads über einen Thread-Dispatcher 2131 an Ausführungseinheiten 2152A bis 2152B verschicken.
  • Bei den Ausführungseinheiten 2152A bis 2152B kann es sich um ein Array aus Vektorprozessoren mit einem Befehlssatz zum Durchführen von Grafik- und Medienoperationen handeln. Die Ausführungseinheiten 2152A bis 2152B können über einen angebundenen L1-Cache 2151 verfügen, der spezifisch für jedes Array ist oder von den Arrays gemeinsam verwendet wird. Der Cache kann als Datencache, Anweisungscache oder ein einziger Cache konfiguriert sein, der so partitioniert ist, dass er Daten und Anweisungen in verschiedenen Partitionen enthält.
  • Eine Geometriepipeline 2120 kann Tesselationskomponenten aufweisen, um Hardware-beschleunigte Tesselation von 3D-Objekten durchzuführen. Ein programmierbarer Hüllen-Shader 2111 kann die Tesselationsoperationen konfigurieren. Ein programmierbarer Domain-Shader 2117 kann für die Back-End-Auswertung der Tesselationsausgabe sorgen. Ein Tesselierer 2113 kann nach Anweisung des Hüllen-Shaders 2111 arbeiten und Speziallogik zum Erzeugen eines Satzes detaillierter geometrischer Objekte auf Grundlage eines groben geometrischen Modells enthalten, das als Eingabe an die Geometriepipeline 2120 bereitgestellt wird. Zudem können Tesselationskomponenten (z.B. der Hüllen-Shader 2111, der Tesselierer 2113 und der Domain-Shader 2117) umgangen werden, wenn keine Tesselation verwendet wird. Die Tesselationskomponenten können auf der Grundlage der vom Vertex-Shader 2107 empfangenen Daten arbeiten.
  • Komplette geometrische Objekte können von einem Geometrie-Shader 2119 über einen oder mehrere Threads verarbeitet werden, die an die Ausführungseinheiten 2152A bis 2152B verschickt werden, oder sie können direkt an den Clipper 2129 weitergeleitet werden. Der Geometrie-Shader kann an ganzen geometrischen Objekten anstatt an Vertices oder Vertexausschnitten wie in früheren Stufen der Grafikpipeline arbeiten. Wenn die Tesselation deaktiviert ist, empfängt der Geometrie-Shader 2119 Eingaben vom Vertex-Shader 2107. Der Geometrie-Shader 2119 kann durch ein Geometrie-Shader-Programm programmierbar sein, um Geometrietesselation durchzuführen, wenn die Tesselationseinheiten deaktiviert sind.
  • Vor der Rasterung verarbeitet ein Clipper 2129 Vertexdaten. Bei dem Clipper 2129 kann es sich um einen Clipper mit fester Funktion oder einen programmierbaren Clipper mit Clipping- und Geometrie-Shader-Funktionen handeln. Eine Raster- und Tiefenprüfkomponente 2173 in der Render-Ausgabepipeline 2170 kann Pixel-Shader verschicken, um die geometrischen Objekte in Pro-Pixel-Repräsentationen umzuwandeln. Die Pixel-Shader-Logik kann in der Thread-Ausführungslogik 2150 umfasst sein. Wahlweise kann eine Anwendung die Raster- und Tiefenprüfkomponente 2173 umgehen und über eine Stream-out-Einheit 2123 auf ungerasterte Vertexdaten zugreifen.
  • Der Grafikprozessor 2100 weist einen Verbindungsbus, ein Verbindungs-Fabric oder einen anderen Verbindungsmechanismus auf, der die Weitergabe von Daten und Nachrichten unter den Hauptkomponenten des Prozessors ermöglicht. In einigen Ausführungsformen sind die Ausführungseinheiten 2152A bis 2152B und die zugehörigen Logikeinheiten (z.B. L1-Cache 2151, Sampler 2154, Texturcache 2158 usw.) über einen Datenport 2156 miteinander verbunden, um Speicherzugriffe durchzuführen und mit Render-Ausgabepipeline-Komponenten des Prozessors zu kommunizieren. Der Sampler 2154, die Caches 2151, 2158 und die Ausführungseinheiten 2152A bis 2152B können jeweils über separate Speicherzugriffspfade verfügen. Wahlweise kann der Texturcache 2158 auch als Sampler-Cache konfiguriert sein.
  • Die Render-Ausgabepipeline 2170 kann eine Raster- und Tiefenprüfkomponente 2173 enthalten, die vertexbasierte Objekte in zugehörige pixelbasierte Repräsentationen umwandelt. Die Rasterlogik kann eine Fensterbildungs- /Maskiereinheit aufweisen, um Festfunktions-Dreieck- und Linienrasterung durchzuführen. Zudem sind in einigen Ausführungsformen ein zugehöriger Render-Cache 2178 und Tiefencache 2179 verfügbar. Eine Pixeloperationskomponente 2177 führt pixelbasierte Operationen an den Daten durch, obwohl in einigen Fällen Pixeloperationen, die mit 2D-Operationen verbunden sind (z.B. Bitblock-Bildübertragungen mit Überblendung), von der 2D-Engine 2141 durchgeführt oder zur Anzeigezeit vom Display-Controller 2143 unter Verwendung von Überlagerungsanzeigeebenen ersetzt werden. Ein gemeinsamer L3-Cache 2175 kann für alle Grafikkomponenten verfügbar sein, wodurch die gemeinsame Nutzung von Daten ohne Verwendung von Hauptsystemspeicher ermöglicht wird.
  • Die Medienpipeline 2130 kann eine Medien-Engine 2137 und ein Video-Front-End 2134 aufweisen. Das Video-Front-End 2134 kann Pipeline-Befehle vom Befehlsstreamer 2103 empfangen. Die Medienpipeline 2130 kann einen separaten Befehlsstreamer aufweisen. Das Video-Front-End 2134 kann Medienbefehle verarbeiten, bevor es den Befehl an die Medien-Engine 2137 sendet. Die Medien-Engine 2137 kann Thread-Erzeugungsfunktionalität aufweisen, um Threads zur Versendung an die Thread-Ausführungslogik 2150 über den Thread-Dispatcher 2131 zu erzeugen.
  • Der Grafikprozessor 2100 kann eine Anzeige-Engine 2140 aufweisen. Diese Anzeige-Engine 2140 kann sich außerhalb des Prozessors 2100 befinden und über die Ringverbindung 2102 oder einen anderen Verbindungsbus oder ein Verbindungs-Fabric mit dem Grafikprozessor gekoppelt sein. Die Anzeige-Engine 2140 kann eine 2D-Engine 2141 und einen Anzeigecontroller 2143 aufweisen. Die Anzeige-Engine 2140 kann Speziallogik aufweisen, die in der Lage ist, unabhängig von der 3D-Pipeline zu arbeiten. Der Anzeigecontroller 2143 kann mit einer Anzeigeeinrichtung (nicht gezeigt) gekoppelt sein, bei der es sich um eine systemintegrierte Anzeigeeinrichtung wie in einem Laptop-Computer oder um eine über einen Anzeigeeinrichtungsverbinder angeschlossene externe Anzeigeeinrichtung handeln kann.
  • Die Geometriepipeline 2120 und die Medienpipeline 2130 können so konfigurierbar sein, dass sie Operationen auf Grundlage mehrerer Grafik- und Medienprogrammierschnittstellen durchführen und nicht spezifisch für eine Anwendungsprogrammierschnittstelle (API) sind. Eine Treibersoftware für den Grafikprozessor kann API-Aufrufe übersetzen, die für eine bestimmte Grafik- oder Medienbibliothek spezifisch sind, in Befehle, die vom Grafikprozessor verarbeitet werden können. Es kann Unterstützung für die Open Graphics Library (OpenGL), Open Computing Language (OpenCL) und/oder Vulkan-Grafik- und Rechen-API, alle von der Khronos Group, bereitgestellt werden. Zudem kann die Direct3D-Bibliothek der Microsoft Corporation unterstützt werden. Es kann auch eine Kombination dieser Bibliotheken unterstützt werden. Zudem kann die Open Source Computer Vision Library (OpenCV) unterstützt werden. Eine künftige API mit einer kompatiblen 3D-Pipeline würde ebenfalls unterstützt werden, sofern die Pipeline der künftigen API auf die Pipeline des Grafikprozessors abgebildet werden kann.
  • Grafikpipelineprogrammierung
  • 22A ist ein Blockschaubild, das ein Grafikprozessor-Befehlsformat 2200 veranschaulicht, das für die Programmierung von Grafikverarbeitungspipelines verwendet wird, wie z.B. die vorliegend in Verbindung mit 16A, 17, 21 beschriebenen Pipelines. 22B ist ein Blockschaubild, das eine Befehlssequenz 2210 eines Grafikprozessors gemäß einer Ausführungsform veranschaulicht. Die Kästen mit durchgehenden Linien in 22A veranschaulichen die Komponenten, die grundsätzlich in einem Grafikbefehl umfasst sind, während die gestrichelten Linien Komponenten umfassen, die optional sind oder die nur in einem Teilsatz der Grafikbefehle umfasst sind. Das beispielhafte Grafikprozessor-Befehlsformat 2200 aus 22A weist Datenfelder auf, um einen Client 2202, einen Befehlsoperationscode (Opcode) 2204 und Daten 2206 für den Befehl zu identifizieren. In einigen Befehlen sind zudem ein Teil-Opcode 2205 und eine Befehlsgröße 2208 umfasst.
  • Der Client 2202 kann die Client-Einheit der Grafikeinrichtung angeben, die die Befehlsdaten verarbeitet. Ein Grafikprozessor-Befehlsparser kann das Client-Feld jedes Befehls untersuchen, um die weitere Verarbeitung des Befehls zu konditionieren und die Befehlsdaten an die geeignete Client-Einheit zu leiten. Die Grafikprozessor-Client-Einheiten können eine Speicherschnittstelleneinheit, eine Render-Einheit, eine 2D-Einheit, eine 3D-Einheit und eine Medieneinheit aufweisen. Jede Client-Einheit kann eine entsprechende Verarbeitungspipeline aufweisen, die die Befehle verarbeitet. Sobald der Befehl von der Client-Einheit empfangen wird, liest die Client-Einheit den Opcode 2204 und, sofern vorhanden, den Teil-Opcode 2205, um die durchzuführende Operation zu bestimmen. Die Client-Einheit führt den Befehl mittels Informationen im Datenfeld 2206 aus. Für einige Befehle wird eine explizite Befehlsgröße 2208 erwartet, um die Größe des Befehls anzugeben. Der Befehlsparser kann automatisch die Größe zumindest einiger der Befehle auf Grundlage des Befehls-Opcodes bestimmen. Befehle können über Vielfache eines Doppelworts ausgerichtet werden. Es können auch andere Befehlsformate verwendet werden.
  • Das Flussdiagramm in 22B veranschaulicht eine beispielhafte Grafikprozessor-Befehlssequenz 2210. Software oder Firmware eines Datenverarbeitungssystems, das über einen beispielhaften Grafikprozessor verfügt, kann eine Version der gezeigten Befehlssequenz zum Einrichten, Ausführen und Beenden eines Satzes von Grafikoperationen verwenden. Eine Beispiel-Befehlssequenz wird nur zu Beispielzwecken gezeigt und beschrieben und ist nicht auf diese konkreten Befehle oder diese Befehlssequenz eingeschränkt. Darüber hinaus können die Befehle als Batch aus Befehlen in einer Befehlssequenz ausgegeben werden, so dass der Grafikprozessor die Befehlssequenz zumindest teilweise gleichzeitig verarbeitet.
  • Die Grafikprozessor-Befehlssequenz 2210 kann mit einem Pipelineleerungsbefehl 2212 beginnen, um dafür zu sorgen, dass etwaige aktive Grafikpipelines die aktuell anstehenden Befehle für die Pipeline abschließen. Wahlweise arbeiten die 3D-Pipeline 2222 und die Medienpipeline 2224 nicht gleichzeitig. Die Pipelineleerung wird durchgeführt, um dafür zu sorgen, dass die aktive Grafikpipeline alle anstehenden Befehle abschließt. Als Reaktion auf eine Pipelineleerung pausiert der Befehlsparser für den Grafikprozessor die Befehlsverarbeitung, bis die aktiven Zeichen-Engines die anstehenden Operationen abgeschlossen haben und die entsprechenden Lesecaches ungültig gemacht wurden. Wahlweise können alle Daten im Render-Cache, die als „schmutzig“ markiert sind, in den Speicher geleert werden. Der Pipelineleerungsbefehl 2212 kann für Pipelinesynchronisierung verwendet werden oder bevor der Grafikprozessor in einen Stromsparmodus versetzt wird.
  • Ein Pipelineauswahlbefehl 2213 kann verwendet werden, wenn eine Befehlssequenz es erfordert, dass der Grafikprozessor explizit zwischen Pipelines umschaltet. Möglicherweise ist ein Pipelineauswahlbefehl 2213 nur einmal innerhalb eines Ausführungskontextes erforderlich, bevor Pipelinebefehle ausgegeben werden, es sei denn, der Kontext soll Befehle für beide Pipelines ausgeben. Ein Pipelineleerungsbefehl 2212 kann unmittelbar vor einem Pipelinewechsel über den Pipelineauswahlbefehl 2213 erforderlich sein.
  • Ein Pipelinesteuerbefehl 2214 kann eine Grafikpipeline für den Betrieb konfigurieren und verwendet werden, um die 3D-Pipeline 2222 und die Medienpipeline 2224 zu programmieren. Der Pipelinesteuerbefehl 2214 kann den Pipelinestatus für die aktive Pipeline konfigurieren. Der Pipelinesteuerbefehl 2214 kann für Pipelinesynchronisierung verwendet werden und um Daten aus einem oder mehreren Cachespeichern innerhalb der aktiven Pipeline zu löschen, bevor ein Batch aus Befehlen verarbeitet wird.
  • Es können den Rückgabepufferstatus 2216 betreffende Befehle verwendet werden, um einen Satz Rückgabepuffer für die jeweiligen Pipelines zum Schreiben von Daten zu konfigurieren. Einige Pipelineoperationen erfordern die Zuteilung, Auswahl oder Konfigurierung eines oder mehrerer Rückgabepuffer, in die die Operationen während der Verarbeitung Zwischendaten schreiben. Der Grafikprozessor kann zudem einen oder mehrere Rückgabepuffer verwenden, um Ausgabedaten zu speichern und Thread-übergreifende Kommunikation durchzuführen. Der Rückgabepufferstatus 2216 kann Auswählen der Größe und Anzahl an Rückgabepuffern umfassen, die für einen Satz von Pipelineoperationen verwendet werden sollen.
  • Die übrigen Befehle in der Befehlssequenz unterscheiden sich je nach der aktiven Pipeline für Operationen. Auf Grundlage einer Pipelinebestimmung 2220 wird die Befehlssequenz auf die 3D-Pipeline 2222 beginnend mit dem 3D-Pipelinestatus 2230 oder die Medienpipeline 2224 beginnend mit dem Medienpipelinestatus 2240 zugeschnitten.
  • Die Befehle zum Konfigurieren des 3D-Pipelinestatus 2230 umfassen 3D-Statuseinstellungsbefehle für Vertexpufferstatus, Vertexelementstatus, Konstantfarbenstatus, Tiefenpufferstatus und andere Statusvariablen, die zu konfigurieren sind, bevor 3D-Primitiv-Befehle verarbeitet werden. Die Werte dieser Befehle werden zumindest teilweise auf Grundlage der jeweils verwendeten 3D-API bestimmt. Die 3D-Pipelinestatus- 2230 Befehle können auch in der Lage sein, selektiv bestimmte Pipelineelemente zu deaktivieren oder zu umgehen, falls diese Elemente nicht verwendet werden.
  • Ein 3D-Primitiv- 2232 Befehl kann verwendet werden, um durch die 3D-Pipeline zu verarbeitende 3D-Primitive zu übermitteln. Befehle und zugehörige Parameter, die über den Befehl 3D-Primitiv 2232 an den Grafikprozessor übergeben werden, werden an die Vertexabruffunktion in der Grafikpipeline weitergeleitet. Die Vertexabruffunktion verwendet die Befehlsdaten des Befehls 3D-Primitiv 2232, um Vertexdatenstrukturen zu erzeugen. Die Vertexdatenstrukturen werden in einem oder mehreren Rückgabepuffern gespeichert. Der 3D-Primitiv- 2232 Befehl kann verwendet werden, um über Vertex-Shader Vertexoperationen an 3D-Primitiven durchzuführen. Um Vertex-Shader zu verarbeiten, verschickt die 3D-Pipeline 2222 Shader-Ausführungs-Threads an Grafikprozessor-Ausführungseinheiten.
  • Die 3D-Pipeline 2222 kann über einen Ausführungs- 2234 Befehl oder ein Ausführungsereignis ausgelöst werden. Ein Register kann Ausführungen von Auslösebefehlen schreiben. Eine Ausführung kann über einen „Go“- oder „Kick“-Befehl in der Befehlssequenz ausgelöst werden. Die Befehlsausführung kann mittels eines Pipelinesynchronisierungsbefehls zum Leeren der Befehlssequenz durch die Grafikpipeline ausgelöst werden. Die 3D-Pipeline führt Geometrieverarbeitung für die 3D-Primitive durch. Sobald die Operationen abgeschlossen sind, werden die resultierenden geometrischen Objekte gerastert und die Pixel-Engine färbt die resultierenden Pixel. Für diese Operationen können auch zusätzliche Befehle zum Steuern von Pixelschattierung und Pixel-Back-End-Operationen umfasst sein.
  • Die Grafikprozessor-Befehlssequenz 2210 kann bei der Durchführung von Medienoperationen dem Pfad der Medienpipeline 2224 folgen. Grundsätzlich hängen die konkrete Verwendung und Art der Programmierung für die Medienpipeline 2224 von den durchzuführenden Medien- oder Rechenoperationen ab. Bestimmte Mediendecodieroperationen können während der Mediendecodierung auf die Medienpipeline abgeladen werden. Die Medienpipeline kann auch umgangen werden, und Mediendecodierung kann ganz oder teilweise mittels Ressourcen durchgeführt werden, die durch einen oder mehrere Allzweck-Verarbeitungskerne bereitgestellt werden. Die Medienpipeline kann zudem Elemente für Operationen einer Allzweck-Grafikprozessoreinheit (GPGPUs) aufweisen, wobei der Grafikprozessor verwendet wird, um SIMD-Vektoroperationen mittels Rechen-Shader-Programmen durchzuführen, die nicht explizit mit dem Rendern von Grafikprimitiven zusammenhängen.
  • Die Medienpipeline 2224 kann in ähnlicher Weise wie die 3D-Pipeline 2222 konfiguriert sein. Ein Satz von Befehlen zum Konfigurieren des Medienpipelinestatus 2240 wird vor den Medienobjektbefehlen 2242 verschickt oder in einer Warteschlange platziert. Befehle für den Medienpipelinestatus 2240 können Daten zum Konfigurieren der Medienpipelineelemente umfassen, die verwendet werden, um die Medienobjekte zu verarbeiten. Dies umfasst Daten zum Konfigurieren der Videodecodier- und Videocodierlogik innerhalb der Medienpipeline, wie beispielsweise Codier- oder Decodierformat. Befehle für den Medienpipelinestatus 2240 können zudem die Verwendung eines oder mehrerer Zeiger auf „indirekte“ Statuselemente unterstützen, die ein Batch aus Statuseinstellungen enthalten.
  • Medienobjektbefehle 2242 können Zeiger auf Medienobjekte zur Verarbeitung durch die Medienpipeline liefern. Die Medienobjekte umfassen Speicherpuffer, die zu verarbeitende Videodaten enthalten. Wahlweise müssen alle Medienpipelinestatus gültig sein, bevor ein Medienobjektbefehl 2242 ausgegeben wird. Sobald der Pipelinestatus konfiguriert ist und die Medienobjektbefehle 2242 in die Warteschlange eingereiht sind, wird die Medienpipeline 2224 über einen Ausführungsbefehl 2244 oder ein äquivalentes Ausführungsereignis (z.B. einen Registerschreibvorgang) ausgelöst. Eine Ausgabe aus der Medienpipeline 2224 kann dann durch Operationen nachbearbeitet werden, die durch die 3D-Pipeline 2222 oder die Medienpipeline 2224 bereitgestellt werden. GPGPU-Operationen können in ähnlicher Weise konfiguriert und ausgeführt werden wie Medienoperationen.
  • Grafiksoftwarearchitektur
  • 23 veranschaulicht eine beispielhafte Grafiksoftwarearchitektur für ein Datenverarbeitungssystem 2300. Eine solche Softwarearchitektur kann eine 3D-Grafikanwendung 2310, ein Betriebssystem 2320 und mindestens einen Prozessor 2330 aufweisen. Der Prozessor 2330 kann einen Grafikprozessor 2332 und einen oder mehrere Allzweck-Prozessorkerne 2334 aufweisen. Der Prozessor 2330 kann eine Variante des Prozessors 1402 oder ein anderer der vorliegend beschriebenen Prozessoren sein. Der Prozessor 2330 kann anstelle des Prozessors 1402 oder eines anderen der vorliegend beschriebenen Prozessoren verwendet werden. Daher offenbart die Offenbarung jeglicher Merkmale in Kombination mit dem Prozessor 1402 oder einem anderen der vorliegend beschriebenen Prozessoren vorliegend auch eine entsprechende Kombination mit dem Grafikprozessor 2330, ohne jedoch hierauf eingeschränkt zu sein. Darüber hinaus können die Elemente aus 23, die die gleichen oder ähnliche Namen wie die Elemente einer anderen vorliegend enthaltenen Figur haben, die gleichen Elemente wie in den anderen Figuren beschreiben, können in ähnlicher Weise arbeiten oder funktionieren, können die gleichen Komponenten umfassen und können mit anderen Einheiten verbunden sein, wie die, die vorliegend an anderer Stelle beschrieben sind, ohne jedoch hierauf eingeschränkt zu sein. Die Grafikanwendung 2310 und das Betriebssystem 2320 werden jeweils im Systemspeicher 2350 des Datenverarbeitungssystems ausgeführt.
  • Die 3D-Grafikanwendung 2310 kann ein oder mehrere Shaderprogramme enthalten, die Schattieranweisungen 2312 umfassen. Die Anweisungen in der Shader-Sprache können in höherer Shader-Sprache vorliegen, beispielsweise High-Level Shader Language (HLSL) von Direct3D, OpenGL Shader Language (GLSL) usw. Die Anwendung kann zudem ausführbare Anweisungen 2314 in einer Maschinensprache aufweisen, die sich zur Ausführung durch den Allzweck-Prozessorkern 2334 eignet. Die Anwendung kann zudem durch Vertexdaten definierte Grafikobjekte 2316 umfassen.
  • Bei dem Betriebssystem 2320 kann es sich um ein Microsoft®-Windows®-Betriebssystem der Microsoft Corporation, ein proprietäres UNIX-ähnliches Betriebssystem oder ein UNIX-ähnliches Open-Source-Betriebssystem handeln, das eine Variante des Linux-Kernels verwendet. Das Betriebssystem 2320 kann eine Grafik-API 2322 wie beispielsweise die Direct3D-API, die OpenGL-API oder die Vulkan-API unterstützen. Wenn die Direct3D-API verwendet wird, verwendet das Betriebssystem 2320 einen Front-End-Shader-Compiler 2324, um alle Shader-Anweisungen 2312 in HLSL in eine Shader-Sprache niedrigerer Ebene zu kompilieren. Bei der Kompilierung kann es sich um Just-in-Time- (JIT-) Kompilierung handeln, oder die Anwendung kann Shader-Vorkompilierung durchführen. Während der Kompilierung der 3D-Grafikanwendung 2310 können Shader höherer Ebene in Shader niedrigerer Ebene kompiliert werden. Die Shader-Anweisungen 2312 können in einer Zwischenform bereitgestellt werden, beispielsweise einer Version der Standard Portable Intermediate Representation (SPIR), wie sie von der Vulkan-API verwendet wird.
  • Ein Nutzermodus-Grafiktreiber 2326 kann einen Back-End-Shader-Compiler 2327 enthalten, um die Shader-Anweisungen 2312 in eine hardwarespezifische Darstellung zu konvertieren. Wenn die OpenGL-API in Verwendung ist, werden Schattieranweisungen 2312 in der höheren GLSL-Sprache zur Kompilierung an einen Nutzermodus-Grafiktreiber 2326 übergeben. Der Nutzermodus-Grafiktreiber 2326 kann Betriebssystem-Kernelmodusfunktionen 2328 verwenden, um mit einem Kernelmodus-Grafiktreiber 2329 zu kommunizieren. Der Kernelmodus-Grafiktreiber 2329 kann mit dem Grafikprozessor 2332 kommunizieren, um Befehle und Anweisungen zu verschicken.
  • IP -Kern-Implementierungen
  • Ein oder mehrere Aspekte können durch auf einem maschinenlesbaren Medium gespeicherten repräsentativen Code implementiert werden, der Logik innerhalb einer integrierten Schaltung wie beispielsweise eines Prozessors repräsentiert oder definiert. Beispielsweise kann das maschinenlesbare Medium Anweisungen aufweisen, die verschiedene Logik innerhalb des Prozessors repräsentieren. Wenn sie von einer Maschine gelesen werden, können die Anweisungen die Maschine veranlassen, die Logik zur Durchführung der vorliegend beschriebenen Methoden zu fertigen. Solche Repräsentationen, die als „IP-Kerne“ bezeichnet werden, sind wiederverwendbare Logikeinheiten für eine integrierte Schaltung, die auf einem greifbaren, maschinenlesbaren Medium als Hardwaremodell gespeichert werden können, das die Struktur der integrierten Schaltung beschreibt. Das Hardwaremodell kann an verschiedene Kunden oder Herstellungseinrichtungen geliefert werden, die das Hardwaremodell auf Fertigungsmaschinen laden, die die integrierte Schaltung herstellen. Die integrierte Schaltung kann so gefertigt werden, dass die Schaltung Operationen durchführt, die in Zusammenhang mit einer der vorliegend beschriebenen Ausführungsformen beschrieben werden.
  • 24A ist ein Blockschaubild, das ein IP-Kern-Entwicklungssystem 2400 veranschaulicht, das verwendet werden kann, um eine integrierte Schaltung zur Durchführung von Operationen gemäß einer Ausführungsform herzustellen. Das IP-Kern-Entwicklungssystem 2400 kann verwendet werden, um modulare, wiederverwendbare Entwürfe zu erzeugen, die in einen größeren Entwurf integriert oder zum Konstruieren einer vollständigen integrierten Schaltung (z.B. einer integrierten SOC-Schaltung) verwendet werden können. Eine Entwurfseinrichtung 2430 kann eine Softwaresimulation 2410 eines IP-Kern-Entwurfs in einer höheren Programmiersprache (z.B. C/C++) erzeugen. Die Softwaresimulation 2410 kann verwendet werden, um das Verhalten des IP-Kerns mittels eines Simulationsmodells 2412 zu entwerfen, zu prüfen und zu verifizieren. Das Simulationsmodell 2412 kann Funktions-, Verhaltens- und/oder Zeitsteuerungssimulationen umfassen. Anschließend kann aus dem Simulationsmodell 2412 ein Register-Transfer-Level- (RTL-) Entwurf 2415 erstellt werden. Bei dem RTL-Entwurf 2415 handelt es sich um eine Abstraktion des Verhaltens der integrierten Schaltung, die den Fluss digitaler Signale zwischen Hardwareregistern modelliert, einschließlich der zugehörigen Logik, die mittels der modellierten digitalen Signale ausgeführt wird. Zusätzlich zu einem RTL-Entwurf 2415 können auch Entwürfe niedrigerer Ebenen auf Logikebene oder Transistorebene erstellt, entworfen oder synthetisiert werden. Daher können die einzelnen Details des ursprünglichen Entwurfs und der Simulation variieren.
  • Der RTL-Entwurf 2415 oder ein Äquivalent kann von der Entwurfseinrichtung weiter in ein Hardwaremodell 2420 synthetisiert werden, das in einer Hardware-Beschreibungssprache (Hardware Description Language, HDL) oder einer anderen Darstellung physikalischer Entwurfsdaten vorliegen kann. Die HDL kann ferner simuliert oder geprüft werden, um den IP-Kern-Entwurf zu verifizieren. Der IP-Kern-Entwurf kann mittels nichtflüchtigen Speichers 2440 (z.B. Festplatte, Flashspeicher oder ein beliebiges nichtflüchtiges Speichermedium) zur Lieferung an eine Fertigungseinrichtung 2465 Dritter gespeichert werden. Alternativ kann der IP-Kern-Entwurf (z.B. über das Internet) über eine drahtgebundene Verbindung 2450 oder eine drahtlose Verbindung 2460 übertragen werden. Die Fertigungseinrichtung 2465 kann dann eine integrierte Schaltung fertigen, die zumindest teilweise auf dem IP-Kern-Entwurf basiert. Die gefertigte integrierte Schaltung kann dafür konfiguriert sein, Operationen gemäß mindestens einer vorliegend beschriebenen Ausführungsform durchzuführen.
  • 24B zeigt eine seitliche Querschnittsansicht einer Package-Baugruppe 2470 für eine integrierte Schaltung. Die Package-Baugruppe 2470 für die integrierte Schaltung veranschaulicht eine Implementierung einer oder mehrerer Prozessor- oder Beschleunigereinrichtungen wie vorliegend beschrieben. Die Package-Baugruppe 2470 weist mehrere Hardwarelogikeinheiten 2472, 2474 auf, die mit einem Substrat 2480 verbunden sind. Die Logik 2472, 2474 kann zumindest teilweise in konfigurierbarer Logik oder Festfunktions-Logikhardware implementiert sein und kann einen oder mehrere Abschnitte eines der Prozessorkern(e), Grafikprozessor(en) oder anderen Beschleunigereinrichtungen wie vorliegend beschrieben umfassen. Jede Logikeinheit 2472, 2474 kann innerhalb eines Halbleiter-Dies implementiert und über eine Verbindungsstruktur 2473 mit dem Substrat 2480 gekoppelt sein. Die Verbindungsstruktur 2473 kann dafür konfiguriert sein, elektrische Signale zwischen der Logik 2472, 2474 und dem Substrat 2480 zu leiten, und kann Verbindungen wie beispielsweise, ohne jedoch hierauf eingeschränkt zu sein, Kontakthügel oder -säulen aufweisen. Die Verbindungsstruktur 2473 kann dafür konfiguriert sein, elektrische Signale wie beispielsweise Eingangs-/Ausgangs- (E/A-) Signale und/oder Stromversorgungs- oder Erdungssignale, die mit dem Betrieb der Logik 2472, 2474 verbunden sind, zu leiten. Wahlweise kann das Substrat 2480 ein laminiertes Substrat auf Epoxidbasis sein. Das Substrat 2480 kann auch andere geeignete Arten von Substraten umfassen. Die Package-Baugruppe 2470 kann über eine Package-Verbindung 2483 mit anderen elektrischen Einrichtungen verbunden sein. Die Package-Verbindung 2483 kann an eine Oberfläche des Substrats 2480 gekoppelt sein, um elektrische Signale an andere elektrische Einrichtungen wie beispielsweise ein Motherboard, einen anderen Chipsatz oder ein Mehrchipmodul zu leiten.
  • Die Logikeinheiten 2472, 2474 können elektrisch mit einer Brücke 2482 gekoppelt sein, die dafür konfiguriert ist, elektrische Signale zwischen der Logik 2472, 2474 zu leiten. Bei der Brücke 2482 kann es sich um eine dichte Verbindungsstruktur handeln, die einen Weg für elektrische Signale bereitstellt. Die Brücke 2482 kann ein aus Glas oder einem geeigneten Halbleitermaterial zusammengesetztes Brückensubstrat aufweisen. Auf dem Brückensubstrat können elektrische Leitungsmerkmale gebildet sein, um eine Chip-zu-Chip-Verbindung zwischen der Logik 2472, 2474 bereitzustellen.
  • Zwar sind zwei Logikeinheiten 2472, 2474 und eine Brücke 2482 veranschaulicht, jedoch können vorliegend 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 wegfallen kann, wenn die Logik auf einem einzigen Die enthalten ist. Alternativ können mehrere Dies oder Logikeinheiten durch eine oder mehr Brücken verbunden sein. Zudem können mehrere Logikeinheiten, Dies und Brücken in anderen möglichen Konfigurationen zusammengeschlossen sein, einschließlich dreidimensionalen Konfigurationen.
  • 24C veranschaulicht eine Package-Baugruppe 2490, die mehrere Einheiten aus Hardwarelogik-Chiplets aufweist, die mit einem Substrat 2480 (z.B. Basis-Die) verbunden sind. Eine Grafikverarbeitungseinheit, ein Parallelprozessor und/oder ein Rechenbeschleuniger wie vorliegend beschrieben können aus verschiedenen Silicium-Chiplets zusammengesetzt sein, die separat hergestellt werden. In diesem Kontext handelt es sich bei einem Chiplet um eine zumindest teilweise verpackte integrierte Schaltung, die einzelne Logikeinheiten aufweist und die mit anderen Chiplets zu einem größeren Package zusammengebaut werden kann. Ein vielfältiger Satz aus Chiplets mit unterschiedlicher IP-Kern-Logik kann zu einer einzigen Einrichtung zusammengebaut werden. Zusätzlich können die Chiplets mittels Active-Interposer-Technologie in einen Basis-Die oder ein Basis-Chiplet integriert werden. Die vorliegend beschriebenen Konzepte ermöglichen die Verbindung und Kommunikation zwischen den verschiedenen Formen von IP innerhalb der GPU. IP-Kerne können mit unterschiedlichen Prozesstechnologien hergestellt und während der Fertigung zusammengesetzt werden, wodurch die Komplexität der Konvergenz mehrerer IPs, insbesondere bei einem großen SoC mit mehreren verschiedenen IPs, auf denselben Fertigungsprozess vermieden wird. Die Verwendung mehrerer Prozesstechnologien verbessert die Markteinführungszeit und bietet eine kostengünstige Möglichkeit, mehrere Produkt-SKUs zu erstellen. Zudem lassen sich die disaggregierten IPs besser unabhängig voneinander mit Strom versorgen, und Komponenten, die für eine bestimmte Arbeitslast nicht verwendet werden, können abgeschaltet werden, was den Gesamtstromverbrauch reduziert.
  • In verschiedenen Ausführungsformen kann eine Package-Baugruppe 2490 eine kleinere oder größere Anzahl an Komponenten und Chiplets aufweisen, die durch ein Fabric 2485 oder eine oder mehrere Brücken 2487 untereinander verbunden sind. Die Chiplets in der Package-Baugruppe 2490 können eine 2,5D-Anordnung aufweisen, die eine Chip-auf-Wafer-auf-Substrat-Stapelung verwendet, bei der mehrere Dies nebeneinander auf einem Silicium-Zwischenelement gestapelt sind, das durch das Silicium verlaufende Durchkontaktierungen (Through-Silicon Vias, TSVs) aufweist, um die Chiplets mit dem Substrat 2480 zu koppeln, das elektrische Verbindungen zur Package-Baugruppe 2483 aufweist.
  • In einer Ausführungsform ist das Silicium-Zwischenelement ein aktives Zwischenelement (active interposer) 2489, das zusätzlich zu den TSVs eingebettete Logik aufweist. In einer solchen Ausführungsform werden die Chiplets innerhalb der Package-Baugruppe 2490 unter Verwendung von 3D-Face-to-Face-Die-Stapelung auf dem aktiven Zwischenelement 2489 angeordnet. Das aktive Zwischenelement 2489 kann neben dem Verbindungs-Fabric 2485 und einer Siliciumbrücke 2487 auch Hardwarelogik für E/A 2491, Cachespeicher 2492 und andere Hardwarelogik 2493 aufweisen. Das Fabric 2485 ermöglicht die Kommunikation zwischen den verschiedenen Logik-Chiplets 2472, 2474 und der Logik 2491, 2493 innerhalb des aktiven Zwischenelements 2489. Das Fabric 2485 kann eine NoC-Verbindung oder eine andere Form von paketvermitteltem Fabric sein, die Datenpakete zwischen Komponenten der Package-Baugruppe vermittelt. Bei komplexen Baugruppen kann das Fabric 2485 ein dediziertes Chiplet sein, das Kommunikation zwischen der verschiedenen Hardwarelogik der Package-Baugruppe 2490 ermöglicht.
  • Brückenstrukturen 2487 innerhalb des aktiven Zwischenelements 2489 können verwendet werden, um eine Punkt-zu-Punkt-Verbindung zwischen beispielsweise Logik- oder E/A-Chiplets 2474 und Speicher-Chiplets 2475 zu ermöglichen. In einigen Implementierungen können die Brückenstrukturen 2487 auch in das Substrat 2480 eingebettet sein.
  • Die Hardwarelogik-Chiplets können Spezial-Hardwarelogik-Chiplets 2472, Logik- oder E/A-Chiplets 2474 und/oder Speicher-Chiplets 2475 umfassen. Die Hardwarelogik-Chiplets 2472 und Logik- oder E/A-Chiplets 2474 können zumindest teilweise in konfigurierbarer Logik oder Festfunktions-Logikhardware implementiert sein und können einen oder mehrere Abschnitte eines der Prozessorkern(e), Grafikprozessor(en), Parallelprozessoren oder anderen Beschleunigereinrichtungen wie vorliegend beschrieben umfassen. Bei den Speicher-Chiplets 2475 kann es sich um DRAM- (z.B. GDDR-, HBM-) Speicher oder Cache- (SRAM-) Speicher handeln. Der Cachespeicher 2492 im aktiven Zwischenelement 2489 (oder Substrat 2480) kann als globaler Cache für die Package-Baugruppe 2490, als Teil eines verteilten globalen Cache oder als dedizierter Cache für das Fabric 2485 fungieren.
  • Jedes Chiplet kann als separater Halbleiter-Die gefertigt und mit einem Basis-Die gekoppelt werden, der in das Substrat 2480 eingebettet oder mit diesem gekoppelt ist. Die Kopplung mit dem Substrat 2480 kann über eine Verbindungsstruktur 2473 erfolgen. Die Verbindungsstruktur 2473 kann dafür konfiguriert sein, elektrische Signale zwischen den verschiedenen Chiplets und der Logik innerhalb des Substrats 2480 zu leiten. Die Verbindungsstruktur 2473 kann Verbindungen wie beispielsweise, ohne jedoch hierauf eingeschränkt zu sein, Kontakthügel oder -säulen umfassen. In einigen Ausführungsformen kann die Verbindungsstruktur 2473 dafür konfiguriert sein, elektrische Signale wie beispielsweise Eingangs-/Ausgangs- (E/A-) Signale und/oder Stromversorgungs- oder Erdungssignale, die mit dem Betrieb der Logik-, E/A- und Speicher-Chiplets verbunden sind, zu leiten. In einer Ausführungsform koppelt eine zusätzliche Verbindungsstruktur das aktive Zwischenelement 2489 mit dem Substrat 2480.
  • Das Substrat 2480 kann ein laminiertes Substrat auf Epoxidbasis sein, ist jedoch hierauf nicht eingeschränkt, und das Substrat 2480 kann auch andere geeignete Arten von Substraten umfassen. Die Package-Baugruppe 2490 kann über eine Package-Verbindung 2483 mit anderen elektrischen Einrichtungen verbunden sein. Die Package-Verbindung 2483 kann an eine Oberfläche des Substrats 2480 gekoppelt sein, um elektrische Signale an andere elektrische Einrichtungen wie beispielsweise ein Motherboard, einen anderen Chipsatz oder ein Mehrchipmodul zu leiten.
  • Ein Logik- oder E/A-Chiplet 2474 und ein Speicher-Chiplet 2475 können elektrisch über eine Brücke 2487 gekoppelt sein, die so konfiguriert ist, dass sie elektrische Signale zwischen dem Logik- oder E/A-Chiplet 2474 und einem Speicher-Chiplet 2475 leitet. Bei der Brücke 2487 kann es sich um eine dichte Verbindungsstruktur handeln, die einen Weg für elektrische Signale bereitstellt. Die Brücke 2487 kann ein aus Glas oder einem geeigneten Halbleitermaterial zusammengesetztes Brückensubstrat aufweisen. Auf dem Brückensubstrat können elektrische Leitungsmerkmale gebildet sein, um eine Chip-zu-Chip-Verbindung zwischen dem Logik- oder E/A-Chiplet 2474 und einem Speicher-Chiplet 2475 bereitzustellen. Die Brücke 2487 kann auch als Siliciumbrücke oder Interconnect-Brücke bezeichnet werden. Beispielsweise handelt es sich bei der Brücke 2487 um eine Embedded Multi-Die Interconnect Bridge (EMIB). Alternativ kann es sich bei der Brücke 2487 schlicht um eine direkte Verbindung von einem Chiplet zu einem anderen Chiplet handeln.
  • 24D veranschaulicht eine Package-Baugruppe 2494 mit austauschbaren Chiplets 2495 gemäß einer Ausführungsform. Die austauschbaren Chiplets 2495 können in standardisierte Slots auf einem oder mehreren Basis-Chiplets 2496, 2498 montiert werden. Die Basis-Chiplets 2496, 2498 können über eine Brückenverbindung 2497 gekoppelt werden, die den anderen vorliegend beschriebenen Brückenverbindungen ähneln und beispielsweise eine EMIB sein kann. Zudem können Speicher-Chiplets über eine Brückenverbindung mit Logik- oder E/A-Chiplets verbunden werden. E/A- und Logik-Chiplets können über ein Verbindungs-Fabric kommunizieren. Die Basis-Chiplets können jeweils einen oder mehrere Slots in einem standardisierten Format für Logik oder E/A oder Speicher/Cache unterstützen.
  • SRAM- und Stromversorgungsschaltungen können in einem oder mehreren der Basis-Chiplets 2496, 2498 hergestellt werden, die mit einer anderen Prozesstechnologie hergestellt werden können als die austauschbaren Chiplets 2495, die auf die Basis-Chiplets gestapelt werden. Beispielsweise können die Basis-Chiplets 2496, 2498 mittels einer größeren Prozesstechnologie gefertigt werden, während die austauschbaren Chiplets mittels einer kleineren Prozesstechnologie hergestellt werden können. Bei einem oder mehreren der austauschbaren Chiplets 2495 kann es sich um Speicher- (z.B. DRAM-) Chiplets handeln. Für die Package-Baugruppe 2494 können unterschiedliche Speicherdichten ausgewählt werden, je nach der angestrebten Leistung und/oder Performance für das Produkt, das die Package-Baugruppe 2494 verwendet. Zudem können zum Zeitpunkt der Montage je nach der für das Produkt angestrebten Leistung und/oder Performance Logik-Chiplets mit einer anderen Anzahl verschiedener Arten von Funktionseinheiten ausgewählt werden. Zusätzlich können Chiplets, die IP-Logikkerne unterschiedlicher Typen enthalten, in die austauschbaren Chiplet-Slots eingesetzt werden, was hybride Prozessor-Designs ermöglicht, die IP-Blöcke verschiedener Technologien mischen und anpassen können.
  • Beispielhafte integrierte Ein-Chip-System-Schaltung
  • 25 bis 26B veranschaulichen beispielhafte integrierte Schaltungen und zugehörige Grafikprozessoren, die mittels eines oder mehrerer IP-Kerne gefertigt werden können. Zusätzlich zum Dargestellten können andere Logik und Schaltungen umfasst sein, darunter zusätzliche Grafikprozessoren/-kerne, Peripherieschnittstellen-Controller oder Allzweck-Prozessorkerne. Die Elemente aus 25 bis 26B, die die gleichen oder ähnliche Namen wie die Elemente einer anderen vorliegend enthaltenen Figur haben, beschreiben die gleichen Elemente wie in den anderen Figuren, können in ähnlicher Weise arbeiten oder funktionieren, können die gleichen Komponenten umfassen und können mit anderen Einheiten verbunden sein, wie die, die vorliegend an anderer Stelle beschrieben sind, ohne jedoch hierauf eingeschränkt zu sein.
  • 25 ist ein Blockschaubild, das eine beispielhafte integrierte Ein-Chip-System-Schaltung 2500 veranschaulicht, die mittels eines oder mehrerer IP-Kerne gefertigt werden kann. Die beispielhafte integrierte Schaltung 2500 umfasst einen oder mehrere Anwendungsprozessor(en) 2505 (z.B. CPUs), mindestens einen Grafikprozessor 2510, der eine Variante des Grafikprozessors 1408, 1508, 2510 oder eines beliebigen vorliegend beschriebenen Grafikprozessors sein kann und anstelle jedes der beschriebenen Grafikprozessoren verwendet werden kann. Daher offenbart die Offenbarung jeglicher Merkmale in Kombination mit einem Grafikprozessor vorliegend auch eine entsprechende Kombination mit dem Grafikprozessor 2510, ohne jedoch hierauf eingeschränkt zu sein. Die integrierte Schaltung 2500 kann zusätzlich einen Bildprozessor 2515 und/oder einen Videoprozessor 2520 aufweisen, wobei jeder dieser Prozessoren ein modularer IP-Kern aus der gleichen oder mehreren verschiedenen Entwurfseinrichtungen sein kann. Die integrierte Schaltung 2500 kann Peripherie- oder Buslogik einschließlich eines USB-Controllers 2525, eines UART-Controllers 2530, eines SPI/SDIO-Controllers 2535 und eines I2S/I2C-Controllers 2540 aufweisen. Zusätzlich kann die integrierte Schaltung eine Anzeigeeinrichtung 2545 aufweisen, die an einen High-Definition-Multimedia-Interface- (HDMI-) Controller 2550 und/oder eine Mobile-Industry-Processor-Interface- (MIPI-) Anzeigeschnittstelle 2555 gekoppelt ist. Speicherung kann durch ein Flashspeicher-Teilsystem 2560 bereitgestellt werden, das Flashspeicher und einen Flashspeicher-Controller aufweist. Für Zugriff auf SDRAM- oder SRAM-Speichereinrichtungen kann eine Speicherschnittstelle über einen Speichercontroller 2565 bereitgestellt werden. Einige integrierte Schaltungen weisen zusätzlich eine eingebettete Sicherheits-Engine 2570 auf.
  • 26A bis 26B sind Blockschaubilder, die beispielhafte Grafikprozessoren zur Verwendung in einem SoC gemäß vorliegend beschriebenen Ausführungsformen veranschaulichen. Bei den Grafikprozessoren kann es sich um Varianten des Grafikprozessors 1408, 1508, 2510 oder jedes anderen vorliegend beschriebenen Grafikprozessors handeln. Die Grafikprozessoren können anstelle des Grafikprozessors 1408, 1508, 2510 oder jedes anderen der vorliegend beschriebenen Grafikprozessoren verwendet werden. Daher offenbart die Offenlegung beliebiger Merkmale in Kombination mit dem Grafikprozessor 1408, 1508, 2510 oder einem anderen der vorliegend beschriebenen Grafikprozessoren auch eine entsprechende Kombination mit den Grafikprozessoren aus 26A bis 26B, ohne jedoch hierauf eingeschränkt zu sein. 26A veranschaulicht einen beispielhaften Grafikprozessor 2610 einer integrierten Ein-Chip-System-Schaltung, die mittels eines oder mehrerer IP-Kerne gefertigt werden kann, gemäß einer Ausführungsform. 26B veranschaulicht einen weiteren beispielhaften Grafikprozessor 2640 einer integrierten Ein-Chip-System-Schaltung, die mittels eines oder mehrerer IP-Kerne gefertigt werden kann, gemäß einer Ausführungsform. Bei dem Grafikprozessor 2610 aus 26A handelt es sich um ein Beispiel eines Grafikprozessorkerns mit geringem Stromverbrauch. Bei dem Grafikprozessor 2640 aus 26B handelt es sich um ein Beispiel eines Grafikprozessorkerns mit höherer Leistung. Beispielsweise können sowohl der Grafikprozessor 2610 als auch der Grafikprozessor 2640 eine Variante des Grafikprozessors 2510 aus 25 sein, wie eingangs in diesem Absatz erwähnt.
  • Wie in 26A gezeigt, umfasst der Grafikprozessor 2610 einen Vertexprozessor 2605 und einen oder mehrere Fragmentprozessoren 2615A bis 2615N (z.B. 2615A, 2615B, 2615C, 2615D, bis 2615N-1 und 2615N). Der Grafikprozessor 2610 kann über separate Logik verschiedene Schattierprogramme ausführen, so dass der Vertexprozessor 2605 dafür optimiert ist, Operationen für Vertexschattierprogramme auszuführen, während der eine oder die mehreren Fragmentprozessoren 2615A bis 2615N Fragment- (z.B. Pixel-) Schattieroperationen für Fragment- oder Pixelschattierprogramme ausführen. Der Vertexprozessor 2605 führt die Vertexverarbeitungsstufe der 3D-Grafikpipeline durch und erzeugt Primitive- und Vertexdaten. Der oder die Fragmentprozessoren 2615A bis 2615N verwenden die vom Vertexprozessor 2605 erzeugten Primitiv- und Vertexdaten, um einen Rahmenpuffer zu erzeugen, der auf einer Anzeigeeinrichtung angezeigt wird. Der oder die Fragmentprozessoren 2615A bis 2615N können für die Ausführung von Fragmentschattierprogrammen optimiert sein, wie sie in der OpenGL-API vorgesehen sind, die verwendet werden können, um ähnliche Operationen wie ein Pixelschattierprogramm durchzuführen, wie es in der Direct-3D-API vorgesehen ist.
  • Der Grafikprozessor 2610 weist zusätzlich eine oder mehrere Speicherverwaltungseinheiten (Memory Management Units, MMUs) 2620A bis 2620B, einen oder mehrere Caches 2625A bis 2625B und eine oder mehrere Schaltungsverbindungen 2630A bis 2630B auf. Die eine oder die mehreren MMUs 2620A bis 2620B sorgen für Abbildung virtueller auf physische Adressen für den Grafikprozessor 2610, darunter für den Vertexprozessor 2605 und/oder den oder die Fragmentprozessoren 2615A bis 2615N, der zusätzlich zu in dem einen oder den mehreren Caches 2625A bis 2625B gespeicherten Vertex- oder Bild-/Texturdaten im Speicher gespeicherte Vertex oder Bild-/Texturdaten referenzieren kann. Die eine oder die mehreren MMUs 2620A bis 2620B können mit anderen MMUs innerhalb des Systems synchronisiert werden, darunter eine oder mehrere MMUs, die zu dem einen oder den mehreren Anwendungsprozessoren 2505, dem Bildprozessor 2515 und/oder dem Videoprozessor 2520 aus 25 gehören, so dass jeder Prozessor 2505 bis 2520 an einem gemeinsam genutzten oder vereinheitlichten virtuellen Speichersystem teilhaben kann. Komponenten des Grafikprozessors 2610 können Komponenten anderer vorliegend beschriebener Grafikprozessoren entsprechen. Die eine oder die mehreren MMUs 2620A bis 2620B können der MMU 245 aus 2C entsprechen. Der Vertexprozessor 2605 und der Fragmentprozessor 2615A bis 2615N können dem Grafik-Multiprozessor 234 entsprechen. Die eine oder die mehreren Schaltungsverbindungen 2630A bis 2630B ermöglichen es dem Grafikprozessor 2610, sich mit anderen IP-Kernen innerhalb des SoC zu verbinden, entweder über einen internen Bus des SoC oder über eine direkte Verbindung, je nach Ausführungsform. Die eine oder die mehreren Schaltungsverbindungen 2630A bis 2630B können der Datenkreuzschiene 240 aus 2C entsprechen. Weitere Entsprechungen können zwischen analogen Komponenten des Grafikprozessors 2610 und den verschiedenen vorliegend beschriebenen Grafikprozessorarchitekturen gefunden werden.
  • Wie in 26B gezeigt, weist der Grafikprozessor 2640 die eine oder die mehreren MMUs 2620A bis 2620B, den einen oder die mehreren Caches 2625A bis 2625B und die eine oder die mehreren Schaltungsverbindungen 2630A bis 2630B des Grafikprozessors 2610 aus 26A auf. Der Grafikprozessor 2640 umfasst einen oder mehrere Shader-Kerne 2655A bis 2655N (z.B. 2655A, 2655B, 2655C, 2655D, 2655E, 2655F bis 2655N-1 und 2655N), wodurch eine einheitliche Shader-Kern-Architektur bereitgestellt wird, bei der ein einziger Kern oder Typ oder Kern alle Arten von programmierbarem Shader-Code ausführen kann, einschließlich Schattierprogrammcode zur Implementierung von Vertex-Shadern, Fragment-Shadern und/oder Rechen-Shadern. Die genaue Anzahl vorhandener Shader-Kerne kann in verschiedenen Ausführungsformen und Implementierungen variieren. Zusätzlich umfasst der Grafikprozessor 2640 einen Inter-Core-Task-Manager 2645, der als Thread-Dispatcher fungiert, um Ausführungs-Threads an einen oder mehrere Shader-Kerne 2655A bis 2655N zu verteilen, sowie eine Kachel-Einheit 2658 zur Beschleunigung von Kacheloperationen für das kachelbasierte Rendering, bei dem Rendering-Operationen für eine Szene im Bildraum unterteilt werden, um beispielsweise die lokale räumliche Kohärenz innerhalb einer Szene auszunutzen oder die Nutzung interner Caches zu optimieren. Die Shader-Kerne 2655A bis 2655N können beispielsweise dem Grafik-Multiprozessor 234 wie in 2D oder den Grafik-Multiprozessoren 325, 350 aus 3A bzw. 3B oder der Mehrkerngruppe 365A aus 3C entsprechen.
  • Erweiterte Prozessorfunktionen für Berechnungen
  • Ein oder mehrere Prozessoren, einschließlich eines oder mehrerer Grafikprozessoren, können für Berechnungen beim maschinellen Lernen oder bei verwandten Verarbeitungen verwendet werden. Jeder Prozessor kann mehrere Verarbeitungsressourcen aufweisen (z.B. Verarbeitungseinheit, Verarbeitungs-Engine, Ausführungsressource, Ausführungseinheit (EU), Stream-Prozessor, Streaming-Multiprozessor (SM), Grafik-Multiprozessor, Mehrkerngruppe, Recheneinheit, Recheneinheit eines Grafikkerns), die bei Computeroperationen in unterschiedlichen Implementierungen verwendet werden können.
  • Herkömmliche Prozessoren verfügen jedoch möglicherweise über unzureichende Rechenkapazitäten für bestimmte Implementierungen, die sehr hohe Berechnungen erfordern, insbesondere solche, die eine hohe Präzision bei Maschinenlernverarbeitung, Min- oder Max-Operationen und der Erzeugung von Pseudozufallszahlen für bestimmte Berechnungen erfordern.
  • In einigen Ausführungsformen bietet eine Vorrichtung, ein System oder ein Prozess erweiterte Prozessorfunktionen für Rechenoperationen, darunter eines oder mehrere der Folgenden:
    1. (1) Konfigurierbare Pipeline zur Bereitstellung einer systolischen Ausgabe;
    2. (2) Min/Max-Operationen (Anweisungen) unter Verwendung einer systolischen Pipeline einer Verarbeitungsressource; oder
    3. (3) Pseudo-Zufallszahlengenerator in Verarbeitungsressourcen.
  • Konfigurierbare Pipeline zur Bereitstellung einer systolischen Ausgabe
  • Aktuelle Maschinenlern- (ML-) Hardware eines Prozessors unterstützt in der Regel nur Arithmetik mit niedriger Präzision, was für viele Maschinenlernoperationen ausreichend sein kann. Es gibt jedoch bestimmte High-End-WLS- (Weighted Least Squares, gewichtete kleinste Quadrate) Modelle, wie z.B. Linpoole, die einen Datentyp mit doppelter Präzision (DP) verwenden. (Daten mit doppelter Präzision belegen 64 Bit im Speicher, die mit einfacher Präzision 32 Bit im Speicher.) Aus diesem Grund besteht in der Maschinenlernverarbeitung ein Bedarf an flexibler Unterstützung für hochpräzise Mathematik.
  • In einigen Ausführungsformen soll eine Vorrichtung, ein System oder ein Prozess eine konfigurierbare Pipeline bereitstellen, beispielsweise eine Gleitkommapipeline mit doppelter Präzision, um eine systolische Ausgabe bereitzustellen. Eine Vorrichtung oder ein System kann zum Beispiel einen oder mehrere Prozessoren aufweisen, die einen oder mehrere Grafikprozessoren umfassen können. Ein Prozessor kann eine oder mehrere Verarbeitungsressourcen aufweisen, wobei eine Verarbeitungsressource eine konfigurierbare Pipeline für Rechenoperationen aufweist. In einigen Ausführungsformen kann die Pipeline verwendet werden, um sowohl eine normale Anweisung für eine Berechnung in einer bestimmten Präzision (wobei, wie vorliegend weiter beschrieben, die Präzisionen Gleitkomma mit halber Präzision (FP16), Gleitkomma mit einfacher Präzision (FP32), Gleitkomma mit doppelter Präzision (FP64) usw. umfassen können) als auch eine systolische Anweisung für eine Berechnung in einer bestimmten Präzision auszuführen. In einigen Ausführungsformen ist die Präzision für die Berechnung eine doppelte Präzision. Eine Berechnung kann unter Verwendung der konfigurierbaren Pipeline für eine Maschinenlernoperation durchgeführt werden.
  • Eine systolische Anweisung ist im Allgemeinen eine Anweisung, die unter Verwendung eines systolischen Arrays ausgeführt werden soll. Ein systolisches Array ist eine Pipelinestruktur, die ein Array aus Verarbeitungseinheiten aufweist, die als Zellen oder Knoten bezeichnet werden und in der Parallelverarbeitung eingesetzt werden, wobei die Zellen eine Sequenz von Operationen ausführen. Jeder Knoten berechnet selbständig ein Teilergebnis in Abhängigkeit der von vorgelagerten Nachbarknoten empfangenen Daten, speichert das Ergebnis innerhalb des Knotens und gibt dieses im Array nachgelagert weiter.
  • In einigen Ausführungsformen kann eine Vorrichtung oder ein System ferner einen Decodierer enthalten, wobei der Decodierer eine Anweisung decodieren und auf Grundlage einer ISA (Befehlssatzarchitektur), die von einem Compiler ausgegeben wird, bestimmen soll, ob die Anweisung eine reguläre Anweisung oder eine systolische Anweisung ist, und die systolische oder nicht-systolische entsprechend auswählen soll.
  • 27 veranschaulicht Verarbeitung in einer konfigurierbaren Pipeline gemäß einigen Ausführungsformen. In einem konfigurierbaren Pipelineprozess können für eine Operation mit doppelter Präzision zwei Werte empfangen werden. In einigen Ausführungsformen kann die resultierende Ausgabe des Pipelineprozesses entweder die Ausgabe der Doppelpräzisionsoperation oder eine nachfolgende Systemerweiterung zur Verarbeitung der Doppelpräzisionsausgabe sein, um eine systolische Ausgabe zu erzeugen.
  • In einigen Ausführungsformen wird die Doppelpräzisionsoperation in einer konfigurierbaren Doppelpräzisionspipeline 2700 implementiert, die reguläre Doppelpräzisionsfunktionen und systolische Doppelpräzisionsoperationen unterstützt. Wie in 27 dargestellt, umfasst die Doppelpräzisionspipeline 2700 eine Doppelpräzisions-(DP-) Operation 2705, um Eingabedaten (IN) zu empfangen und eine DP-Ausgabe 2710 zu erzeugen. In einigen Ausführungsformen weist die DP-Pipeline 2700 außerdem eine Systemerweiterung 2715 zur Verarbeitung der DP-Ausgabe 2710 auf, um eine systolische Ausgabe 2720 zu erzeugen.
  • In einigen Ausführungsformen kann eine DP-Pipeline-Ausgabe (OUT) entweder als DP-Ausgabe 2710 oder als systolische Ausgabe 2720 gewählt werden. In der dargestellten Implementierung empfängt ein Multiplexer 2730 die DP-Ausgabe 2710 und die systolische Ausgabe 2720 als Eingaben und wählt eine dieser Ausgaben entsprechend einer Auswahleingabe (SELECT) aus.
  • 28 veranschaulicht eine Verarbeitungsressource mit einer konfigurierbaren Pipeline zur Bereitstellung einer systolischen Ausgabe gemäß einigen Ausführungsformen. In einem Prozessor können mehrere Verarbeitungsressourcen vorhanden sein, einschließlich der abgebildeten Verarbeitungsressource 2800, die beispielsweise eine Ausführungseinheit, einen Streaming-Multiprozessor oder eine andere Verarbeitungsressource umfassen kann.
  • In einigen Ausführungsformen weist die Verarbeitungsressource zusätzlich zu anderen vorliegend beschriebenen Elementen für eine Verarbeitungsressource eine konfigurierbare Pipeline mit doppelter Präzision auf, um beispielsweise Unterstützung für Berechnungen mit doppelter Präzsision beim maschinellen Lernen und anderen Rechenoperationen zu bieten. In einigen Ausführungsformen ermöglicht eine Vorrichtung sowohl eine systolische Anweisung als auch eine reguläre DP-Berechnung innerhalb der gleichen konfigurierbaren Pipelinestruktur.
  • Wie in 28 veranschaulicht, umfasst Hardwarelogik für die Verarbeitungsressource 2800 einen Decodierer 2840. Die Verarbeitungsressource soll eine Anweisung 2850 aus dem Befehlscache lesen (in 28 nicht dargestellt), und der Decodierer 2840 soll die Anweisung 2850 empfangen und decodieren. In einigen Ausführungsformen umfasst das Decodieren der Anweisung 2850, dass der Decodierer 2840 auf Grundlage einer von einem Compiler ausgegebenen ISA (Befehlssatzarchitektur) bestimmt, ob die Anweisung 2850 eine reguläre (nicht-systolische) Anweisung oder eine systolische Anweisung ist. Die decodierte Anweisung kann einer Registerdatei wie beispielsweise einer allgemeinen Registerdatei (GRF) 2845 zur Verfügung gestellt werden. Die Anweisung kann eine Verarbeitung umfassen, die eine Verarbeitung mit doppelter Präzision erfordert, wobei die Daten für die Verarbeitung einer Verarbeitungseinheit mit doppelter Präzision 2805 zur Verfügung gestellt werden, um eine Ausgabe mit doppelter Präzision 2810 bereitzustellen.
  • In einigen Ausführungsformen weist die Verarbeitungsressource 2800 ferner eine Systemerweiterung 2815 zur Umwandlung der DP-Ausgabe 2810 in eine systolische Ausgabe 2820 auf. In einigen Ausführungsformen ist die Verarbeitungsressource 2800 für systolische oder nicht-systolische Verarbeitung konfigurierbar, indem entweder die systolische Ausgabe 2820 oder die DP-Ausgabe 2810 auf Grundlage der Decodierung der Anweisung 2850 als reguläre (nicht-systolische) Anweisung oder als systolische Anweisung ausgewählt wird. Dies ist so dargestellt, dass die systolische Ausgabe 2820 und die DP-Ausgabe 2810 Eingaben für einen Multiplexer 2830 sind, wobei die Auswahl (SELECT) entsprechend der Bestimmung des Decodierers 2840 bezüglich der regulären (nicht-systolischen) oder systolischen Natur der empfangenen Anweisung 2850 erfolgt. In einigen Ausführungsformen wird die resultierende Ausgabe des Multiplexers 2830 dann an die GRF 2845 zurückgegeben, um die erforderliche Verarbeitung fortzusetzen.
  • 29 ist ein Flussdiagramm zur Veranschaulichung eines Prozesses zur Bereitstellung einer systolischen Ausgabe unter Verwendung einer konfigurierbaren Pipeline gemäß einigen Ausführungsformen. In einigen Ausführungsformen kann eine Operation in einer konfigurierbaren Pipeline-Vorrichtung mit doppelter Präzision wie folgt ablaufen:
  • Eine Verarbeitungsressource liest eine Anweisung aus einem Anweisungscache 2905, wobei die Anweisung eine bestimmte Präzision erfordert, beispielsweise eine Gleitkommaverarbeitung mit doppelter Präzision (d.h. es handelt sich um eine DP-Anweisung). Die Verarbeitungsressource leitet die DP-Anweisung an einen Decodierer, 2910, der die Anweisung decodiert, einschließlich der Bestimmung, ob die Anweisung eine systolische DP-Anweisung oder eine reguläre DP-Anweisung ist, 2915.
  • In einigen Ausführungsformen soll die Decodier-Hardware die erforderliche Konfiguration der Pipeline auf Grundlage der vom Compiler ausgegebenen ISA (Befehlssatzarchitektur) erkennen. Für eine systolische Anweisung dpos oder eine reguläre DP-Berechnung (mod - multiple add instruction, Mehrfachaddieranweisung):
    • dpos: dst: DF src0: DF src1: DF
    • mod: dst: DF src0: DF src1: DF
  • In einigen Ausführungsformen leitet der Decodierer auf Grundlage der Bestimmung der systolischen oder regulären DP-Anweisung Lesevorgänge in einer allgemeinen Registerdatei (GRF) 2920 ein. Der Decodierer sendet ferner Informationen an die Verarbeitungsressource in Bezug auf die Operationsunterstützung für die Anweisung, 2925, wobei die Operationsunterstützung die Auswahl der systolischen oder nicht-systolischen DP-Unterstützung für die Anweisung umfasst.
  • In einigen Ausführungsformen fährt der Prozess mit dem Bereitstellen von Daten an einen DP-Operator fort, um eine DP-Operationsausgabe zu erzeugen, 2930, und mit dem Bereitstellen der DP-Operationsausgabe an ein Systemerweiterungselement, um eine systolische DP-Ausgabe zu erzeugen, 2935. Wenn die Informationen zur Operationsunterstützung eine systolische DP-Anweisung anzeigen, 2940, ist die Pipeline so konfiguriert, dass die systolische DP-Ausgabe an die Registerdatei zurückgegeben wird, 2950, und wenn die Informationen zur Operationsunterstützung eine nicht-systolische DP-Anweisung anzeigen, 2940, ist die Pipeline so konfiguriert, dass die DP-Ausgabe an die Registerdatei zurückgegeben wird, 2955. Daten aus der Registerdatei und die generierten Operationsinformationen (die angeben, ob es sich um eine systolische oder eine nicht-systolische Operation handelt) führen also dazu, dass eine Hardware mit doppelter Präzision die Operation ausführt und die entsprechenden Ausgabedaten zurück in die Registerdatei schreibt.
  • Min/Max-Operationen (Anweisungen) unter Verwendung einer systolischen Pipeline
  • Horizontale Operationen, also beispielsweise Operationen über SIMD-(Single Instruction Multiple Data) Anweisungskanäle hinweg, sind in der Regel schwer in Hardware zu adressieren. Insbesondere gibt es Fälle, in denen es notwendig ist, entweder einen Minimalwert oder einen Maximalwert über SIMD-Kanäle hinweg zu bestimmen, und herkömmliche Prozessortechnologien sind im Allgemeinen ineffizient bei der Handhabung einer solchen Operation.
  • In einigen Ausführungsformen kann eine systolische Hardwarestruktur verwendet werden, um Berechnungen mit horizontalen Daten durchzuführen. In einigen Ausführungsformen weist eine Verarbeitungsressource eine systolische Pipelinestruktur auf, wobei die Pipelinestruktur so implementiert ist, dass die Pipeline verwendet werden kann, um eine Operation wie beispielsweise eine Min- oder Max-Operation über Daten in einer horizontalen Datenstruktur hinweg durchzuführen.
  • In einigen Ausführungsformen sieht eine Vorrichtung, ein System oder ein Prozess Min/Max-Operationen unter Verwendung einer systolischen Pipeline vor. Beispielsweise kann eine Vorrichtung oder ein System einen oder mehrere Prozessoren mit einer oder mehreren Verarbeitungsressourcen und einen Speicher zum Speichern von Daten, einschließlich Daten für Rechenoperationen, aufweisen, wobei eine Verarbeitungsressource der einen oder der mehreren Verarbeitungsressourcen eine systolische Pipelinestruktur aufweist, um eine oder mehrere Operationen über Daten in horizontalen Kanälen hinweg durchzuführen. In einigen Ausführungsformen umfassen die eine oder die mehreren Operationen eine Operation zur Identifizierung eines Maximalwerts oder eines Minimalwerts in den horizontalen Kanaldaten. In einigen Ausführungsformen umfassen die horizontalen Kanaldaten Daten über SIMD-Kanäle hinweg.
  • 30 veranschaulicht die Berechnung einer horizontalen Operation über SIMD-Anweisungskanäle hinweg gemäß einigen Ausführungsformen. Wie in 30 dargestellt, können SIMD-Befehle 3010 in einem Prozessor über SIMD-Kanäle 3020 hinweg als Reaktion auf eine Anweisung verarbeitet werden. Die Kanäle werden als erster Kanal (ch0) bis zu einem letzten Kanal (ch(N-1)) von insgesamt N Kanälen bezeichnet.
  • In 30 umfassen die Operationen in einem Prozessor eine Operation, um einen Minimalwert (Min) oder einen Maximalwert (Max) der SIMD-Werte zu erzeugen. Die Generierung solcher Min- und Max-Werte kann durch Bereitstellen über die Kanäle der mehreren SIMD-Anweisungen hinweg und dann schließlich Erzeugen der endgültigen Ausgabe erfolgen, wie durch die Min/Max-Verarbeitung 3030 dargestellt. Die Maximal- und Minimaloperationen können jeweils wie folgt ausgedrückt werden: O u t [ c h ] = max c h : 0. N − 1 { d a t a [ c h ] }
    Figure DE102020130081A1_0001
     O u t [ c h ] = min c h : 0. N − 1 { d a t a [ c h ] }
    Figure DE102020130081A1_0002
  • Bei der konventionellen Verarbeitung werden die Werte jedoch nicht effizient über die Kanäle hinweg verarbeitet, was zu Kosten in der Verarbeitungszeit führt. In einigen Ausführungsformen wird die Min/Max-Verarbeitung 3030 durch die Implementierung eines systolischen Arrays ermöglicht, wie in 31 weiter dargestellt, um die horizontalen Operationen über die horizontalen Kanäle hinweg durchzuführen.
  • 31 ist eine Darstellung der Anwendung von systolischer Hardware zur Durchführung einer Operation zur Verarbeitung von Werten über horizontale Kanäle hinweg gemäß einigen Ausführungsformen. In einigen Ausführungsformen umfassen ein oder mehrere Prozessoren eine oder mehrere Verarbeitungsressourcen, wie die Verarbeitungsressource 3100. In einigen Ausführungsformen umfasst die Verarbeitungsressource eine systolische Pipelinestruktur 3110, die ein verbundenes Array aus Knoten 3120 aufweist, wobei das Array aus Knoten als eine Reihe von Pipes umfassend bezeichnet werden kann. In einigen Ausführungsformen ist die systolische Pipelinestruktur 3110 betreibbar, um eine Operation zum Verarbeiten von Werten über horizontale Kanäle hinweg durchzuführen, wobei die Operation eine Operation zur Bestimmung eines Maximalwerts in dem Array aus Knoten und/oder eine Operation zur Bestimmung eines Minimalwerts in dem Array aus Knoten umfassen kann.
  • Die zu verarbeitenden Daten können, ohne jedoch hierauf eingeschränkt zu sein, SIMD-Anweisungskanaldaten aufweisen. Für die in 31 veranschaulichte Operation: m a x   d s l : s r c [ c h ]
    Figure DE102020130081A1_0003
     wobei  s r c − Daten=SIMD-KANALDATEN
    Figure DE102020130081A1_0004
  • Bei dieser max-Operation werden die folgenden Prozesse angewendet:
    1. (a) In einer zweiten Pipe der systolischen Array-Struktur werden die dargestellten ch0- und ch1-Kanaldatenwerte verglichen, um einen Maximalwert zu ermitteln, wobei der resultierende Ausgabewert outo ist.
    2. (b) Der Wert der Ausgabe wird dann in einem dritten Zyklus mit dem folgenden Kanalwert, ch2, verglichen: o u t 1 = max ( o u t 0 , c h 2 )
      Figure DE102020130081A1_0005
    3. (c) In der nächsten Stufe der systolischen Pipeline schreitet der Prozess fort zum nächsten, folgenden Vergleich: o u t 2 = max ( o u t 1 , c h 3 )
      Figure DE102020130081A1_0006
  • Dieser Vergleichsprozess wird fortgesetzt, wobei jeder ermittelte Ausgabewert mit einem nächstfolgenden Kanalwert verglichen wird.
    • (d) Die endgültige Ausgabe hat den Vergleich für alle Kanäle durchgeführt und ergibt den endgültigen Maximalwert, der wie folgt ausgedrückt werden kann: o u t F i n a l = max ( o u t ( N − 2 ) , c h ( N − 1 ) )
      Figure DE102020130081A1_0007
  • Die Erzeugung eines Minimalwertes kann mit der gleichen systolischen Hardwarestruktur erfolgen, wobei jeder Vergleich eine Min-Wert-Operation ist.
  • 32 ist ein Flussdiagramm zur Veranschaulichung eines Prozesses für eine konfigurierbare Pipeline mit doppelter Präzision zur Bereitstellung einer systolischen Ausgabe gemäß einigen Ausführungsformen. In einigen Ausführungsformen kann eine Operation in einer konfigurierbaren Pipeline-Vorrichtung mit doppelter Präzision wie folgt ablaufen:
  • In einigen Ausführungsformen eines Prozesses 3200 empfängt eine Verarbeitungsressource eines Prozessors eine Anweisung, die eine horizontale Kanalverarbeitung über mehrere Datenelemente erfordert, 3205. Die Anweisung kann, ohne jedoch hierauf eingeschränkt zu sein, eine Anweisung zur Bestimmung eines Maximalwerts (Max) oder eines Minimalwerts (Min) in mehreren SIMD-Anweisungen umfassen.
  • In einigen Ausführungsformen werden die SIMD-Anweisungen in eine systolische Array-Struktur der Verarbeitungsressource geladen, um Vergleiche der Kanalwerte für die SIMD-Anweisungen 3210 zu verarbeiten, um die benötigte Verarbeitung auf effektive und effiziente Weise bereitzustellen. In einer solchen Operation wird ein erster Kanalwert (ch0) mit einem zweiten Kanalwert (ch1) verglichen, um eine erste Ausgabe (out0) zu erzeugen, 3215.
  • Der Prozess fährt dann mit dem Erhalten eines nächsten Kanalwertes (der nächste Kanalwert ist ch2), 3220, und dem Vergleichen der zuletzt erzeugten Ausgabe (outo) mit dem nächsten Kanalwert (ch2) fort, um eine nächste Ausgabe (out1) zu erzeugen, 3225. Der Prozess ermöglicht somit einen zeilenübergreifenden Vergleich der Daten durch die Verwendung der Hardware-Logikstruktur des systolischen Arrays.
  • In einigen Ausführungsformen kann der Prozess dann, wenn ein oder mehrere zusätzliche Kanalwerte zum Vergleichvorhanden sind, 3230, mit dem Erhalten eines nächsten Kanalwertes (z.B. ch3 oder ein nachfolgender Kanalwert), 3220, und dem Vergleichen der zuletzt erzeugten Ausgabe (z.B. out1) mit dem nächsten Kanalwert (ch3) fortgesetzt werden, um eine nächste Ausgabe (out2) zu erzeugen, 3225. Dieser Prozess kann dann durch alle verbleibenden Kanalwerte hindurch fortgesetzt werden.
  • Wenn festgestellt wird, dass keine weiteren Kanalwerte zum Vergleich vorhanden sind, 3230, wird die zuletzt erzeugte Ausgabe als endgültige Antwort auf die empfangene Anweisung bereitgestellt, 3235. Bei einer Min- oder Max-Anweisung für eine Reihe von SIMD-Befehlen ist beispielsweise die letzte generierte Ausgabe der Minimal- oder Maximalwert für die SIMD-Anweisungswerte.
  • Pseudo-Zufallszahlengenerator in Verarbeitungsressourcen
  • Bei der Durchführung von Berechnungen für eine Anwendung in einem Datenverarbeitungssystem ist es häufig erforderlich, Werte zu runden, z.B. auf eine bestimmte Anzahl von Ziffern zu runden. Das Runden auf den nächsten Wert, wie z.B. das Aufrunden von 1,67 auf 1,7 und das Abrunden von 1,32 auf 1,3, ist im Allgemeinen ein deterministischer Prozess, der jedes Mal, wenn ein bestimmter Wert auftritt, zu demselben Ergebnis führt. Dies kann jedoch je nach Anwendung und Art der erzeugten Werte zu unerwünschten Ergebnissen führen.
  • In bestimmten Anwendungen, z.B. beim maschinellen Lernen, kann stattdessen eine stochastische Rundung eingesetzt werden, um bessere Ergebnisse zu erzielen. Unter stochastischer Rundung versteht man im Allgemeinen das Runden auf eine der nächstliegenden Ganzzahlen mit einer von der Nähe zu den Werten abhängigen Wahrscheinlichkeit. Genauer gesagt, für einen Wert x, der zwischen den Werten x1 und x2 liegt, wobei x1 kleiner als x2 ist, kann der Prozess der stochastischen Rundung mit einer Wahrscheinlichkeit von (x - x1)/(x2 - x1) auf x2 aufrunden und mit einer Wahrscheinlichkeit von (x2 - x)/(x2 - x1) auf x1 abrunden. Daher ist die Wahrscheinlichkeit, entweder auf x1 oder x2 zu runden, proportional zu eins minus dem relativen Abstand von x zu jeder dieser Zahlen.
  • Die stochastische Rundungsoperation erfordert jedoch in der Regel die Anwendung einer Zufallszahl (oder Pseudozufallszahl), um die Operation entsprechend der zugewiesenen Wahrscheinlichkeit durchzuführen. In einigen Ausführungsformen ist in einer Verarbeitungsressource (wie z.B. einer Ausführungseinheit oder einem Streaming-Multiprozessor) ein Mechanismus zur effizienten Erzeugung von Pseudozufallszahlen zur Verwendung bei der stochastischen Rundung vorgesehen. Beispielsweise kann eine Vorrichtung oder ein System einen oder mehrere Prozessoren mit einer oder mehreren Verarbeitungsressourcen und einen Speicher zum Speichern von Daten, einschließlich Daten für Rechenoperationen, aufweisen, wobei eine Verarbeitungsressource der einen oder der mehreren Verarbeitungsressourcen einen Pseudozufallszahlengenerator aufweist. In einigen Ausführungsformen enthält der Pseudozufallszahlengenerator eine definierte Registerdatei, z.B. eine Architekturregisterdatei (ARF), und ein Schieberegister mit linearer Rückkopplung (Linear Feedback Shift Register, LFSR), um eine Pseudozufallsausgabe auf Grundlage eines aus der Architekturregisterdatei abgerufenen Keimwerts zu erzeugen. In einigen Ausführungsformen ist der Keimwert in der Architekturregisterdatei durch einen Compiler zu initiieren. In einigen Ausführungsformen soll die Verarbeitungsressource die Pseudozufallsausgabe des Pseudozufallszahlengenerators zur stochastischen Rundung von Daten anwenden.
  • Auf diese Weise kann die stochastische Rundungsoperation in der Verarbeitungsressource bereitgestellt werden, ohne dass erhebliche Hardware- oder Betriebskosten für die Verarbeitungsressource erforderlich sind.
  • 33 ist eine Darstellung einer Operation zur Bereitstellung stochastischer Rundung in einer Anwendung gemäß einigen Ausführungsformen. 33 zeigt einen vereinfachten Betriebsablauf, wobei die Ausführungsformen nicht auf diesen vereinfachten Ablauf beschränkt sind. In einer Operation, z.B. einer Operation, die von einer Verarbeitungsressource eines oder mehrerer Prozessoren durchgeführt wird, kann eine Anwendungsanweisung 3305 empfangen werden, wobei die Anweisung die Durchführung einer bestimmten mathematischen Operation 3310 erfordert. Die Anweisung kann, ohne jedoch hierauf eingeschränkt zu sein, eine Anweisung für eine Anwendung umfassen, die einen Maschinenlernprozess umfasst (der entweder ein Maschinenlemtraining oder Inferenzfindung umfassen kann).
  • Die Durchführung der mathematischen Operation 3310 kann die Anwendung von Pseudozufallswerten erfordern, beispielsweise bei der stochastischen Rundung der erzeugten Ergebnisse. Die Anwendung der stochastischen Rundung erhöht jedoch die Komplexität der Verarbeitungsressourcen, einschließlich der Notwendigkeit der Erzeugung eines Zufallswertes bei der Berechnung der Zufallswerte.
  • Wie in 33 dargestellt, wird ein Ergebnis 3315 der Operation 3310 einer stochastischen Rundung 3320 unterzogen. In einigen Ausführungsformen wird bei der stochastischen Rundung 3320 ein Pseudozufallswert verwendet, der durch den Betrieb eines Schieberegisters mit linearer Rückkopplung (LFSR) erzeugt wird. In einigen Ausführungsformen kann das LFSR einen anfänglichen Keimwert verwenden, der in einem definierten Register bereitgestellt wird, wie in 34 weiter dargestellt. Die Operation ermöglicht eine effiziente Verarbeitung der stochastischen Rundung, ohne dass erhebliche Hardware- oder Verarbeitungskosten in einer Verarbeitungsressource erforderlich sind. Der resultierende stochastisch gerundete Wert 3330 kann dann je nach Art des Prozesses einer weiteren Verarbeitung 3340 zugeführt oder als Ausgabe 3345 in Reaktion auf die Anweisung 3305 bereitgestellt werden.
  • 34 ist eine Darstellung einer Verarbeitungsressource zur Erzeugung von Pseudozufallswerten gemäß einigen Ausführungsformen. Wie im vereinfachten Prozess in 33 dargestellt, kann eine Anweisung 3305 die Erzeugung und Anwendung von Pseudozufallswerten erfordern, z.B. bei der stochastischen Rundung von Werten. In einigen Ausführungsformen umfasst die Erzeugung eines Pseudozufallswertes in einer Verarbeitungsressource 3400 die Verwendung eines Schieberegisters mit linearer Rückkopplung (LFSR) 3420 zur Erzeugung von Pseudozufallszahlenwerten 3430. Die Zufallszahl kann dann z.B. bei der Berechnung von stochastisch gerundeten Werten als Reaktion auf die Anweisung verwendet werden.
  • In einigen Ausführungsformen soll eine Vorrichtung, ein System oder ein Prozess eine Registerdatei für einen anfänglichen Keimwert 3455 einrichten, der bei der Erzeugung von Pseudozufallswerten durch das LFSR zur Verwendung bei der stochastischen Rundung von numerischen Werten verwendet wird. In einigen Ausführungsformen ist die Registerdatei eine Architekturregisterdatei (ARF) 3410, wobei eine Architekturregisterdatei eine dedizierte Registerdatei ist, die zur Aufrechterhaltung eines Architekturstatus pro Thread verwendet werden kann. In einigen Ausführungsformen soll ein Compiler 3450 in die definierte ARF 3410 schreiben, um den anfänglichen Keimwert 3455 für den Betrieb des Pseudozufallszahlengenerators bereitzustellen.
  • Wie in 34 dargestellt, kann der anfängliche Keimwert von der ARF durch das LFSR 3420 erhalten werden, wobei das LFSR eine Rückkopplungsfunktion 3425 verwendet, um Werte für die Erzeugung einer Sequenz aus Pseudozufallszahlenwerten 3430 zu erzeugen. Der von der Verarbeitungsressource ausgeführte Code kann die generierten Pseudozufallswerte in nachfolgenden Anweisungen verwenden.
  • Auf diese Weise kann eine Verarbeitungsressource Operationen durchführen, die Zufallszahlenwerte erfordern, ohne dass signifikante Hardware oder Overhead benötigt wird, da die Definition der Architekturregisterdatei und die Bereitstellung des anfänglichen Keimwerts in der definierten Architekturregisterdatei durch den Compiler die Komplexität und die Kosten für die Verarbeitungsressource bei der Zufallszahlenerzeugung minimieren.
  • 35 ist ein Flussdiagramm zur Veranschaulichung eines Prozesses zur Bereitstellung und Anwendung von Pseudozufallswerten in einer Anwendung gemäß einigen Ausführungsformen. In einigen Ausführungsformen eines Prozesses 3500 wird eine Anwendung verarbeitet, z.B. durch eine Verarbeitungsressource 3400 wie in 34 dargestellt, wobei die Anwendung eine Operation umfasst, die die Erzeugung von Pseudozufallswerten 3405 erfordert. Die Operation kann eine stochastische Rundungsoperation umfassen, wobei die Operation die Erzeugung von Zufalls- oder Pseudozufallswerten erfordert, um eine Verteilung der Werte entsprechend der Anwendungswahrscheinlichkeit bei der stochastischen Rundung zu ermöglichen. Eine solche stochastische Rundungsoperation kann, ohne jedoch hierauf eingeschränkt zu sein, eine Operation beinhalten, die Maschinenlemtraining oder Inferenzfindung umfasst. Die Anwendung erfordert daher die Erzeugung von Zufalls- oder Pseudozufallszahlen, um die stochastische Rundung von Zahlenwerten zu ermöglichen.
  • In einigen Ausführungsformen wird zur Unterstützung der erforderlichen Operation eine Registerdatei zur Erzeugung von Pseudozufallszahlen 3410 definiert. Die Registerdatei kann eine Architekturregisterdatei (ARF) aufweisen und kann von einem Compiler definiert werden. Ein anfänglicher Keimwert wird dann in der definierten Registerdatei gespeichert, 3515. Für eine Operation in der Anwendung wird ein Ergebnis berechnet, 3520, das dann stochastisch gerundet werden muss.
  • In einigen Ausführungsformen wird der anfängliche Keimwert aus der Registerdatei durch ein LFSR, wie z.B. das in 34 dargestellte LFSR 3420, zur Erzeugung von Pseudozufallswerten 3525 gewonnen. Anschließend wird ein Pseudozufallswert durch das LFSR erzeugt, 3530, wobei der Wert auf der Grundlage des anfänglichen Keimwerts erzeugt wird. Der erzeugte Wert wird dann in der Operation angewendet, 3535. Dies kann die Durchführung einer stochastischen Rundung des generierten Ergebnisses unter Verwendung des Pseudozufallswertes umfassen, um einen gerundeten Wert zu berechnen.
  • In einigen Ausführungsformen wird das Ergebnis der Operation für die Anwendung berechnet, 3545, wenn eine oder mehrere zusätzliche Berechnungen durchgeführt werden müssen, 3540. In einigen Ausführungsformen wird eine Rückmeldung, z.B. über die in 34 dargestellte Rückkopplungsfunktion, 3425, am LFSR zur Erzeugung eines nächsten Pseudozufallswertes empfangen, 3550. Der Prozess kann dann zum Erzeugen eines Pseudozufallswerts durch das LFSR, 3530, und Anwenden des erzeugten Werts in der Operation zurückkehren, wie z.B. das Durchführen einer stochastischen Rundung des erzeugten Ergebnisses unter Verwendung des Pseudozufallswerts, um einen nächsten gerundeten Wert zu berechnen, 3535.
  • Nach Abschluss der Berechnungen, 3540, kann die weitere Bearbeitung der Anwendung fortgesetzt werden, 3555. Bei einer Operation mit stochastischer Rundung kann dies die Ausgabe der gerundeten Werte oder die Verwendung der gerundeten Werte in anderen Berechnungen umfassen.
  • In einigen Ausführungsformen umfasst eine Vorrichtung einen oder mehrere Prozessoren, die eine oder mehrere Verarbeitungsressourcen aufweisen; und einen Speicher zum Speichern von Daten, wobei die Daten Daten für Rechenoperationen umfassen, wobei eine Verarbeitungsressource der einen oder der mehreren Verarbeitungsressourcen eine konfigurierbare Pipeline für Rechenoperationen aufweist, und wobei die konfigurierbare Pipeline verwendet werden kann, um Folgendes durchzuführen: sowohl eine normale Anweisung für eine Berechnung mit einer bestimmten Präzision als auch eine systolische Anweisung für eine Berechnung mit einer bestimmten Präzision.
  • In einigen Ausführungsformen handelt es sich bei einer Präzision für Berechnungen um Gleitkomma mit doppelter Präzision (FP64).
  • In einigen Ausführungsformen wird eine Berechnung unter Verwendung der konfigurierbaren Pipeline für eine Maschinenlernoperation durchgeführt.
  • In einigen Ausführungsformen weist die Vorrichtung ferner einen Decodierer auf, wobei der Decodierer dafür vorgesehen ist, eine Anweisung zu decodieren und auf Grundlage einer von einem Compiler ausgegebenen ISA (Befehlssatzarchitektur) zu bestimmen, ob die decodierte Anweisung eine reguläre Anweisung oder eine systolische Anweisung ist.
  • In einigen Ausführungsformen weist die Vorrichtung ferner eine Registerdatei auf, die dafür vorgesehen ist, die decodierte Anweisung zu empfangen.
  • In einigen Ausführungsformen ist die Registerdatei ferner dafür vorgesehen, ein Ergebnis der Anweisung von der konfigurierbaren Pipeline zu empfangen.
  • In einigen Ausführungsformen handelt es sich bei der Registerdatei um eine allgemeine Registerdatei (General Register File, GRF).
  • In einigen Ausführungsformen umfassen der eine oder die mehreren Prozessoren einen Grafikprozessor.
  • In einigen Ausführungsformen umfasst ein Verfahren Empfangen einer Anweisung zur Verarbeitung, wobei die Anweisung eine Verarbeitung einer Berechnung mit einer bestimmten Präzision erfordert; Decodieren der Anweisung, wobei das Decodieren Bestimmen umfasst, ob die Anweisung eine nicht-systolische Anweisung für eine Berechnung mit der bestimmten Präzision oder eine systolische Anweisung für eine Berechnung mit der bestimmten Präzision ist; Konfigurieren einer konfigurierbaren Pipeline, um entweder nicht-systolische oder systolische Berechnung bereitzustellen; Bereitstellen von Daten zur Verarbeitung; und Empfangen eines Ergebnisses der nicht-systolischen oder systolischen Berechnung.
  • In einigen Ausführungsformen handelt es sich bei einer Präzision für Berechnungen um Gleitkomma mit doppelter Präzision (FP64).
  • In einigen Ausführungsformen erfordert die Anweisung eine Berechnung für eine Maschinenlerntrainings- oder Inferenzfindungsoperation.
  • In einigen Ausführungsformen umfasst das Decodieren auf Grundlage einer von einem Compiler ausgegebenen ISA (Befehlssatzarchitektur) erfolgendes Bestimmen, ob die Anweisung eine reguläre Anweisung oder eine systolische Anweisung ist.
  • In einigen Ausführungsformen umfasst das Verfahren ferner Empfangen der decodierten Anweisung in einer Registerdatei.
  • In einigen Ausführungsformen umfasst das Verfahren ferner Empfangen eines Ergebnisses der Anweisung von der konfigurierbaren Pipeline in der Registerdatei.
  • In einigen Ausführungsformen handelt es sich bei der Registerdatei um eine allgemeine Registerdatei (General Register File, GRF).
  • In einigen Ausführungsformen umfasst ein System einen oder mehrere Prozessoren einschließlich eines Grafikprozessors, wobei der Grafikprozessor eine oder mehrere Verarbeitungsressourcen umfasst; einen Speicher zum Speichern von Daten, wobei die Daten Daten für Rechenoperationen umfassen; einen Decodierer zum Decodieren von Anweisungen; und eine Registerdatei zum Empfangen der decodierten Anweisungen, wobei eine Verarbeitungsressource der einen oder der mehreren Verarbeitungsressourcen eine konfigurierbare Pipeline für Rechenoperationen aufweist, und wobei die konfigurierbare Pipeline verwendet werden kann, um sowohl eine normale Anweisung für eine Berechnung mit einer bestimmten Präzision als auch eine systolische Anweisung für eine Berechnung mit einer bestimmten Präzision durchzuführen.
  • In einigen Ausführungsformen ist eine Präzision für Berechnungen eine solche, die Gleitkomma mit halber Präzision (FP16), Gleitkomma mit einfacher Präzision (FP32) oder Gleitkomma mit doppelter Präzision (FP64) umfasst.
  • In einigen Ausführungsformen wird eine Berechnung unter Verwendung der konfigurierbaren Pipeline für eine Maschinenlernoperation durchgeführt.
  • In einigen Ausführungsformen ist der Decodierer dafür vorgesehen, auf Grundlage einer von einem Compiler ausgegebenen ISA (Befehlssatzarchitektur) zu bestimmen, ob eine decodierte Anweisung eine reguläre Anweisung oder eine systolische Anweisung ist.
  • In einigen Ausführungsformen ist die Registerdatei ferner dafür vorgesehen, ein Ergebnis der Anweisung von der konfigurierbaren Pipeline zu empfangen.
  • In einigen Ausführungsformen handelt es sich bei der Registerdatei um eine allgemeine Registerdatei (General Register File, GRF).
  • In einigen Ausführungsformen weisen ein oder mehrere nicht transiente computerlesbare Speichermedien auf diesen gespeicherte ausführbare Computerprogrammanweisungen auf, die bei Ausführung durch einen oder mehrere Prozessoren den einen oder die mehreren Prozessoren veranlassen, Arbeitsschritte durchzuführen, umfassend Empfangen einer Anweisung zur Verarbeitung, wobei die Anweisung eine Verarbeitung einer Berechnung mit einer bestimmten Präzision erfordert; Decodieren der Anweisung, wobei das Decodieren Bestimmen umfasst, ob die Anweisung eine nicht-systolische Anweisung für eine Berechnung mit der bestimmten Präzision oder eine systolische Anweisung für eine Berechnung mit der bestimmten Präzision ist; Konfigurieren einer konfigurierbaren Pipeline, um entweder nicht-systolische oder systolische Berechnung bereitzustellen; Bereitstellen von Daten zur Verarbeitung; und Empfangen eines Ergebnisses der nicht-systolischen oder systolischen Berechnung.
  • In einigen Ausführungsformen handelt es sich bei einer Präzision für Berechnungen um Gleitkomma mit doppelter Präzision (FP64).
  • In einigen Ausführungsformen erfordert die Anweisung eine Berechnung für eine Maschinenlerntrainings- oder Inferenzfindungsoperation.
  • In einigen Ausführungsformen umfasst das Decodieren auf Grundlage einer von einem Compiler ausgegebenen ISA (Befehlssatzarchitektur) erfolgendes Bestimmen, ob die Anweisung eine reguläre Anweisung oder eine systolische Anweisung ist.
  • In einigen Ausführungsformen weist das Medium ferner Anweisungen zum Empfangen der decodierten Anweisung in einer Registerdatei auf.
  • In einigen Ausführungsformen weist das Medium ferner Anweisungen zum Empfangen eines Ergebnisses der Anweisung von der konfigurierbaren Pipeline in der Registerdatei auf.
  • In einigen Ausführungsformen umfasst eine Vorrichtung Mittel zum Empfangen einer Anweisung zur Verarbeitung, wobei die Anweisung eine Verarbeitung einer Berechnung mit einer bestimmten Präzision erfordert; Mittel zum Decodieren der Anweisung, wobei das Decodieren Bestimmen umfasst, ob die Anweisung eine nicht-systolische Anweisung für eine Berechnung mit der bestimmten Präzision oder eine systolische Anweisung für eine Berechnung mit der bestimmten Präzision ist; Mittel zum Konfigurieren einer konfigurierbaren Pipeline, um entweder nicht-systolische oder systolische Berechnung bereitzustellen; Bereitstellen von Daten zur Verarbeitung; und Mittel zum Empfangen eines Ergebnisses der nicht-systolischen oder systolischen Berechnung.
  • In einigen Ausführungsformen handelt es sich bei einer Präzision für Berechnungen um Gleitkomma mit doppelter Präzision (FP64).
  • In einigen Ausführungsformen erfordert die Anweisung eine Berechnung für eine Maschinenlerntrainings- oder Inferenzfindungsoperation.
  • In einigen Ausführungsformen umfasst das Decodieren auf Grundlage einer von einem Compiler ausgegebenen ISA (Befehlssatzarchitektur) erfolgendes Bestimmen, ob die Anweisung eine reguläre Anweisung oder eine systolische Anweisung ist.
  • In einigen Ausführungsformen weist die Vorrichtung ferner Mittel zum Empfangen der decodierten Anweisung in einer Registerdatei auf.
  • In einigen Ausführungsformen weist die Vorrichtung ferner Mittel zum Empfangen eines Ergebnisses der Anweisung von der konfigurierbaren Pipeline in der Registerdatei auf.
  • In einigen Ausführungsformen umfasst eine Vorrichtung einen oder mehrere Prozessoren mit einer oder mehreren Verarbeitungsressourcen; und einen Speicher zum Speichern von Daten, einschließlich Daten für Rechenoperationen, wobei eine Verarbeitungsressource der einen oder der mehreren Verarbeitungsressourcen eine systolische Pipelinestruktur aufweist, um eine oder mehrere Operationen über Daten in horizontalen Kanälen hinweg durchzuführen.
  • In einigen Ausführungsformen umfassen die eine oder die mehreren Operationen eine erste Operation zur Identifizierung eines Maximalwerts oder eines Minimalwerts in den horizontalen Kanaldaten.
  • In einigen Ausführungsformen umfasst die erste Operation Folgendes: Vergleichen eines ersten Kanalwertes mit einem zweiten Kanalwert in einer ersten Pipe der systolischen Pipelinestruktur, um eine erste Ausgabe zu erzeugen; und Vergleichen der ersten Ausgabe mit einem dritten Kanalwert in einer zweiten Pipe der systolischen Pipelinestruktur, um eine zweite Ausgabe zu erzeugen.
  • In einigen Ausführungsformen umfasst die erste Operation ferner nach Durchführen eines Vergleichs, der einen letzten Kanalwert beinhaltet, Ausgeben einer zuletzt erzeugten Ausgabe als Ausgabe für die erste Operation.
  • In einigen Ausführungsformen umfassen die Daten in horizontalen Kanälen Daten über SIMD- (Single Instruction Multiple Data) Kanäle hinweg.
  • In einigen Ausführungsformen umfasst ein Verfahren Empfangen einer Anweisung, die eine Operation umfasst, die eine horizontale Kanalverarbeitung über mehrere Datenelemente erfordert; Laden der Datenelemente in eine systolische Pipeline, um die Operation unter Verwendung von Kanalwerten für die mehreren Datenelemente durchzuführen; Durchführen der Operation über Daten in der systolischen Pipeline hinweg; und Erzeugen einer Ausgabe für die Operation zumindest teilweise auf Grundlage eines endgültigen Ergebnisses der Durchführung der Operation über die Daten in der systolischen Pipeline hinweg.
  • In einigen Ausführungsformen umfasst die Operation Identifizieren eines Maximalwerts oder eines Minimalwerts in den Datenelementen.
  • In einigen Ausführungsformen umfasst das Durchführen der Operation Vergleichen eines ersten Kanalwertes mit einem zweiten Kanalwert in einer ersten Pipe der systolischen Pipelinestruktur, um eine erste Ausgabe zu erzeugen; und Vergleichen der ersten Ausgabe mit einem dritten Kanalwert in einer zweiten Pipe der systolischen Pipelinestruktur, um eine zweite Ausgabe zu erzeugen.
  • In einigen Ausführungsformen umfasst das Durchführen der Operation ferner nach Durchführen eines Vergleichs, der einen letzten Kanalwert beinhaltet, Ausgeben einer zuletzt erzeugten Ausgabe als Ausgabe für die erste Operation.
  • In einigen Ausführungsformen umfassen die mehreren Datenelemente Daten in SIMD- (Single Instruction Multiple Data) Kanälen.
  • In einigen Ausführungsformen umfasst eine Vorrichtung einen oder mehrere Prozessoren, die eine oder mehrere Verarbeitungsressourcen aufweisen; und einen Speicher zum Speichern von Daten, einschließlich Daten für Rechenoperationen, wobei eine Verarbeitungsressource der einen oder der mehreren Verarbeitungsressourcen einen Pseudozufallszahlengenerator aufweist, wobei der Pseudozufallszahlengenerator eine Registerdatei zum Speichern eines anfänglichen Keimwerts und ein Schieberegister mit linearer Rückkopplung (LFSR) zum Erzeugen einer Pseudozufallsausgabe auf Grundlage des anfänglichen Keimwerts aufweist, der aus der Registerdatei abgerufen wird.
  • In einigen Ausführungsformen ist die Verarbeitungsressource dafür vorgesehen, die Pseudozufallsausgabe des Pseudozufallszahlengenerators zur stochastischen Rundung von Daten anzuwenden.
  • In einigen Ausführungsformen ist der Keimwert in der Registerdatei durch einen Compiler zu initiieren.
  • In einigen Ausführungsformen wird die Registerdatei durch den Compiler definiert.
  • In einigen Ausführungsformen weist das LFSR eine Rückkopplungsfunktion auf, um eine Reihe von Pseudozufallszahlen auf Grundlage des anfänglichen Keimwerts zu erzeugen.
  • In einigen Ausführungsformen handelt es sich bei der Registerdatei um eine Architekturregisterdatei (ARF).
  • In einigen Ausführungsformen umfasst ein Verfahren Verarbeiten einer Anwendung, die eine Operation unter Verwendung von Pseudozufallszahlen umfasst; Definieren einer Registerdatei zum Speichern eines anfänglichen Keimwerts für die Erzeugung der Pseudozufallszahlen; Erhalten des anfänglichen Keimwerts in einem Schieberegister mit linearer Rückkopplung (LFSR); Erzeugen einer Pseudozufallsausgabe durch das LFSR auf Grundlage des aus der Registerdatei abgerufenen anfänglichen Keimwerts; und Anwenden der Pseudozufallsausgabe in der Operation.
  • In einigen Ausführungsformen umfasst das Anwenden der Pseudozufallsausgabe in der Operation Durchführen einer stochastischen Rundung der Daten, die zumindest teilweise auf der Pseudozufallsausgabe basiert.
  • In einigen Ausführungsformen umfasst das Verfahren ferner Initiieren des anfänglichen Keimwerts in der Registerdatei durch einen Compiler.
  • In einigen Ausführungsformen umfasst das Verfahren außerdem Definieren der Registerdatei durch den Compiler.
  • In einigen Ausführungsformen umfasst das Erzeugen der Pseudozufallsausgabe durch das LFSR Empfangen eines Rückmeldungswerts am LFSR, um eine Reihe von Pseudozufallszahlen unter Verwendung des anfänglichen Keimwerts zu erzeugen.
  • In einigen Ausführungsformen handelt es sich bei der Registerdatei um eine Architekturregisterdatei (ARF).
  • In der vorstehenden Beschreibung werden zu Erläuterungszwecken zahlreiche konkrete Einzelheiten dargelegt, um ein umfassendes Verständnis der beschriebenen Ausführungsformen zu vermitteln. Ein Fachmann versteht jedoch, dass Ausführungsformen auch ohne einige dieser konkreten Einzelheiten umgesetzt werden können. In anderen Fällen werden bekannte Strukturen und Einrichtungen in Blockdiagrammform dargestellt. Zwischen den abgebildeten Komponenten können Zwischenstrukturen vorhanden sein. Die vorliegend beschriebenen oder abgebildeten Komponenten können zusätzliche Eingänge oder Ausgänge haben, die nicht abgebildet oder beschrieben sind.
  • Verschiedene Ausführungsformen können verschiedene Prozesse umfassen. Diese Prozesse können von Hardwarekomponenten ausgeführt werden oder in Computerprogrammen oder maschinenausführbaren Befehlen verkörpert sein, die verwendet werden können, um einen Allzweck- oder Spezialprozessor oder Logikschaltungen, die mit den Anweisungen programmiert sind, zur Ausführung der Prozesse zu veranlassen. Alternativ können die Prozesse auch durch eine Kombination aus Hardware und Software ausgeführt werden.
  • Teile verschiedener Ausführungsformen können als Computerprogrammprodukt bereitgestellt werden, das ein computerlesbares Medium mit darauf gespeicherten Computerprogrammanweisungen umfassen kann, die zur Programmierung eines Computers (oder anderer elektronischer Einrichtungen) zur Ausführung durch einen oder mehrere Prozessoren verwendet werden können, um einen Prozess gemäß bestimmten Ausführungsformen durchzuführen. Das computerlesbare Medium kann, ohne jedoch hierauf eingeschränkt zu sein, Magnetplatten, optische Platten, Nur-Lese-Speicher (ROM), Direktzugriffsspeicher (RAM), löschbaren programmierbaren Direktzugriffsspeicher (EPROM), elektrisch löschbaren programmierbaren Direktzugriffsspeicher (EEPROM), magnetische oder optische Karten, Flashspeicher oder eine andere Art von computerlesbarem Medium, das zum Speichern elektronischer Anweisungen geeignet ist, umfassen. Darüber hinaus können Ausführungsformen auch als Computerprogrammprodukt heruntergeladen werden, wobei das Programm von einem entfernten Computer auf einen anfordernden Computer übertragen werden kann. In einigen Ausführungsformen sind auf einem nicht transienten, computerlesbaren Speichermedium Daten gespeichert, die Sequenzen von Befehlen darstellen, die, wenn sie von einem Prozessor ausgeführt werden, den Prozessor veranlassen, bestimmte Operationen durchzuführen.
  • Viele der Verfahren werden in ihrer grundlegendsten Form beschrieben, jedoch können zu jedem der Verfahren Prozesse hinzugefügt oder gelöscht werden, und zu jeder der beschriebenen Meldungen können Informationen hinzugefügt oder abgezogen werden, ohne vom grundlegenden Umfang der vorliegenden Ausführungsformen abzuweichen. Ein Fachmann versteht, dass viele weitere Modifikationen und Anpassungen vorgenommen werden können. Die einzelnen Ausführungsformen dienen nicht dazu, das Prinzip einzuschränken, sondern um es zu veranschaulichen. Der Umfang der Ausführungsformen ist nicht durch die oben aufgeführten spezifischen Beispiele, sondern nur durch die nachfolgenden Ansprüche zu bestimmen.
  • Wenn es heißt, dass ein Element „A“ mit Element „B“ gekoppelt ist, kann Element A direkt mit Element B gekoppelt sein oder indirekt, z.B. über Element C. Wenn in der Spezifikation oder den Ansprüchen angegeben wird, dass eine Komponente, ein Merkmal, eine Struktur, ein Prozess oder eine Eigenschaft A eine Komponente, ein Merkmal, eine Struktur, einen Prozess oder eine Eigenschaft B „verursacht“, bedeutet dies, dass „A“ zumindest eine Teilursache von „B“ ist, dass es aber auch mindestens eine andere Komponente, ein Merkmal, eine Struktur, einen Prozess oder eine Eigenschaft geben kann, die bei der Verursachung von „B“ hilft. Wenn in der Spezifikation angegeben wird, dass eine Komponente, ein Merkmal, eine Struktur, ein Prozess oder ein Merkmal „enthalten sein kann“, „könnte“ oder „könnte“, muss diese bestimmte Komponente, dieses Merkmal, diese Struktur, dieser Prozess oder dieses Merkmal nicht enthalten sein. Wenn die Spezifikation Bezug auf „(irgend)ein“ Element nimmt, dann bedeutet dies nicht, dass nur eines der beschriebenen Elemente vorhanden ist.
  • Eine Ausführungsform ist eine Implementierung oder ein Beispiel. Verweise in der Spezifikation auf „(irgend)eine Ausführungsform“, „(genau)eine Ausführungsform“, „einige Ausführungsformen“ oder „andere Ausführungsformen“ bedeuten, dass ein bestimmtes Merkmal, eine bestimmte Struktur oder eine bestimmte Eigenschaft, die in Verbindung mit den Ausführungsformen beschrieben wird, in mindestens einigen Ausführungsformen, aber nicht notwendigerweise in allen Ausführungsformen enthalten ist. Die an verschiedener Stelle auftretenden Ausdrücke „(irgend)eine,“,, „(genau) eine Ausführungsform“ oder „einige Ausführungsformen“ beziehen sich nicht notwendigerweise alle auf die gleichen Ausführungsformen. Es ist zu beachten, dass in der vorstehenden Beschreibung von beispielhaften Ausführungsformen verschiedene Merkmale manchmal in einer einzigen Ausführungsform, Figur oder Beschreibung davon zusammengefasst sind, um die Offenlegung zu straffen und das Verständnis eines oder mehrerer der verschiedenen neuen Aspekte zu erleichtern. Diese Vorgehensweise in der Offenbarung ist jedoch nicht so auszulegen, dass die beanspruchten Ausführungsformen mehr Merkmale als explizit in jedem Anspruch angegeben erfordern sollen. Vielmehr liegen, wie die folgenden Ansprüche widerspiegeln, neuartige Aspekte in weniger als allen Merkmalen einer einzigen vorstehend offenbarten Ausführungsform. Daher werden die Ansprüche hiermit ausdrücklich in diese Beschreibung aufgenommen, wobei jeder Anspruch für sich allein als separate Ausführungsform steht.
  • 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/935758 [0001]

Claims (20)

  1. Vorrichtung, die Folgendes aufweist: einen oder mehrere Prozessoren, die eine oder mehrere Verarbeitungsressourcen aufweisen; und einen Speicher zum Speichern von Daten, wobei die Daten Daten für Rechenoperationen umfassen; wobei eine Verarbeitungsressource der einen oder der mehreren Verarbeitungsressourcen eine konfigurierbare Pipeline für Rechenoperationen aufweist, und wobei die konfigurierbare Pipeline verwendet werden kann, um Folgendes durchzuführen: sowohl eine normale Anweisung für eine Berechnung mit einer bestimmten Präzision; als auch eine systolische Anweisung für eine Berechnung mit einer bestimmten Präzision.
  2. Vorrichtung nach Anspruch 1, wobei es sich bei einer Präzision für Berechnungen um Gleitkomma mit doppelter Präzision (FP64) handelt.
  3. Vorrichtung nach Anspruch 1 oder 2, wobei eine Berechnung unter Verwendung der konfigurierbaren Pipeline für eine Maschinenlernoperation durchgeführt wird.
  4. Vorrichtung nach einem der Ansprüche 1 bis 3, ferner umfassend einen Decodierer, wobei der Decodierer dafür vorgesehen ist, eine Anweisung zu decodieren und auf Grundlage einer von einem Compiler ausgegebenen ISA (Befehlssatzarchitektur) zu bestimmen, ob die decodierte Anweisung eine reguläre Anweisung oder eine systolische Anweisung ist.
  5. Vorrichtung nach Anspruch 4, ferner umfassend eine Registerdatei, wobei die Registerdatei dafür vorgesehen ist, die decodierte Anweisung zu empfangen.
  6. Vorrichtung nach Anspruch 5, wobei die Registerdatei ferner dafür vorgesehen ist, ein Ergebnis der Anweisung von der konfigurierbaren Pipeline zu empfangen.
  7. Vorrichtung nach Anspruch 5 oder 6, wobei die Registerdatei eine allgemeine Registerdatei (GRF) ist.
  8. Vorrichtung nach einem der Ansprüche 1 bis 7, wobei der eine oder die mehreren Prozessoren einen Grafikprozessor umfassen.
  9. Verfahren, umfassend: Empfangen einer Anweisung zur Verarbeitung, wobei die Anweisung eine Verarbeitung einer Berechnung mit einer bestimmten Präzision erfordert; Decodieren der Anweisung, wobei das Decodieren Bestimmen umfasst, ob die Anweisung eine nicht-systolische Anweisung für eine Berechnung mit der bestimmten Präzision oder eine systolische Anweisung für eine Berechnung mit der bestimmten Präzision ist; Konfigurieren einer konfigurierbaren Pipeline, um entweder nicht-systolische oder systolische Berechnung bereitzustellen; Bereitstellen von Daten zur Verarbeitung; und Empfangen eines Ergebnisses der nicht-systolischen oder systolischen Berechnung.
  10. Verfahren nach Anspruch 9, wobei es sich bei einer Präzision für Berechnungen um Gleitkomma mit doppelter Präzision (FP64) handelt.
  11. Verfahren nach Anspruch 9 oder 10, wobei die Anweisung Berechnungen für eine Maschinenlerntrainings- oder Inferenzfindungsoperation umfasst.
  12. Verfahren nach einem der Ansprüche 9 bis 11, wobei das Decodieren auf Grundlage einer von einem Compiler ausgegebenen ISA (Befehlssatzarchitektur) erfolgendes Bestimmen umfasst, ob die Anweisung eine reguläre Anweisung oder eine systolische Anweisung ist.
  13. Verfahren nach einem der Ansprüche 9 bis 12, ferner umfassend Empfangen der decodierten Anweisung in einer Registerdatei.
  14. Verfahren nach Anspruch 13, ferner umfassend Empfangen eines Ergebnisses der Anweisung von der konfigurierbaren Pipeline in der Registerdatei.
  15. System, umfassend: einen oder mehrere Prozessoren einschließlich eines Grafikprozessors, wobei der Grafikprozessor eine oder mehrere Verarbeitungsressourcen umfasst; einen Speicher zum Speichern von Daten, wobei die Daten Daten für Rechenoperationen umfassen; einen Decodierer zum Decodieren von Anweisungen; und eine Registerdatei zum Empfangen der decodierten Anweisungen; wobei eine Verarbeitungsressource der einen oder der mehreren Verarbeitungsressourcen eine konfigurierbare Pipeline für Rechenoperationen aufweist, und wobei die konfigurierbare Pipeline verwendet werden kann, um Folgendes durchzuführen: sowohl eine normale Anweisung für eine Berechnung mit einer bestimmten Präzision; als auch eine systolische Anweisung für eine Berechnung mit einer bestimmten Präzision.
  16. System nach Anspruch 15, wobei eine Präzision für Berechnungen eine solche ist, die Gleitkomma mit halber Präzision (FP16), Gleitkomma mit einfacher Präzision (FP32) oder Gleitkomma mit doppelter Präzision (FP64) umfasst.
  17. System nach Anspruch 15 oder 16, wobei eine Berechnung unter Verwendung der konfigurierbaren Pipeline für eine Maschinenlemoperation durchgeführt wird.
  18. System nach einem der Ansprüche 15 bis 17, wobei der Decodierer dafür vorgesehen ist, auf Grundlage einer von einem Compiler ausgegebenen ISA (Befehlssatzarchitektur) zu bestimmen, ob eine decodierte Anweisung eine reguläre Anweisung oder eine systolische Anweisung ist.
  19. System nach einem der Ansprüche 15 bis 18, wobei die Registerdatei ferner dafür vorgesehen ist, ein Ergebnis der Anweisung von der konfigurierbaren Pipeline zu empfangen.
  20. System nach einem der Ansprüche 15 bis 19, wobei die Registerdatei eine allgemeine Registerdatei (GRF) ist.
DE102020130081.6A 2019-11-15 2020-11-13 Erweiterte prozessorfunktionen für berechnungen Pending DE102020130081A1 (de)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201962935758P 2019-11-15 2019-11-15
US62/935,758 2019-11-15
US17/095,626 US20210149677A1 (en) 2019-11-15 2020-11-11 Enhanced processor functions for calculation
US17/095,626 2020-11-11

Publications (1)

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

Family

ID=75683551

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102020130081.6A Pending DE102020130081A1 (de) 2019-11-15 2020-11-13 Erweiterte prozessorfunktionen für berechnungen

Country Status (3)

Country Link
US (1) US20210149677A1 (de)
CN (1) CN112819681A (de)
DE (1) DE102020130081A1 (de)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11544113B2 (en) * 2019-11-20 2023-01-03 Google Llc Task scheduling for machine-learning workloads
CN117132450B (zh) * 2023-10-24 2024-02-20 芯动微电子科技(武汉)有限公司 一种可实现数据共享的计算装置和图形处理器

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6088783A (en) * 1996-02-16 2000-07-11 Morton; Steven G DPS having a plurality of like processors controlled in parallel by an instruction word, and a control processor also controlled by the instruction word
US20050149701A1 (en) * 2003-12-24 2005-07-07 Inching Chen Method, apparatus and system for pair-wise minimum and minimum mask instructions
US10318291B2 (en) * 2011-11-30 2019-06-11 Intel Corporation Providing vector horizontal compare functionality within a vector register
US10824938B2 (en) * 2017-04-24 2020-11-03 Intel Corporation Specialized fixed function hardware for efficient convolution
TWI816475B (zh) * 2017-05-17 2023-09-21 美商谷歌有限責任公司 低延遲矩陣乘法單元中之胞元、相關之方法及非暫時性電腦程式產品

Also Published As

Publication number Publication date
CN112819681A (zh) 2021-05-18
US20210149677A1 (en) 2021-05-20

Similar Documents

Publication Publication Date Title
DE112020001258T5 (de) Grafikprozessoren und Grafikverarbeitungseinheiten mit Skalarproduktakkumulationsanweisungen für ein Hybrid-Gleitkommaformat
DE102020130078A1 (de) Systolische arithmetik an spärlichen daten
DE112020001249T5 (de) Dünnbesetzt-Optimierungen für eine Matrixbeschleunigerarchitektur
DE102020129969A1 (de) Verbesserungen der verarbeitung und des caching von graphikverarbeitungseinheiten
DE102020129251A1 (de) Adaptives verformbares kernvorhersagenetzwerk zum bildentrauschen
DE102018110380A1 (de) Tool zum Ermöglichen der Effizienz beim Maschinenlernen
DE102020130073A1 (de) Verbesserung der datenlokalität für grafikprozessoreinheiten
DE102020129970A1 (de) Systeme und verfahren zur fehlererkennung und steuerung für eingebettete arbeitsspeicher- und rechenelemente
DE102018110687A1 (de) Dynamisches Genauigkeitsmanagement für Deep-Learning-Ganzzahlprimitive
DE102018110371A1 (de) Intelligente speicherhandhabung und datenmanagement für maschinenlernnetzwerke
DE112020000464T5 (de) Mehrfachkachel-grafikprozessor-rendering
DE112020000854T5 (de) Thread-gruppen-planung für die grafikverarbeitung
DE102020107080A1 (de) Grafiksysteme und Verfahren zum Beschleunigen von Synchronisation mittels feinkörniger Abhängigkeitsprüfung und Planungsoptimierungen basierend auf verfügbarem gemeinsam genutztem Speicherplatz
DE102020132272A1 (de) Verfahren und vorrichtung zum codieren basierend auf schattierungsraten
DE102018110719A1 (de) Hardwareimplementierte Punkt-zu-Punkt-Kommunikationsprimitive zum Maschinenlernen
DE102020129409A1 (de) Dynamisches unterteilen von aktivierungen und kernels zum verbessern von speichereffizienz
CN113424219A (zh) 用于多线程通道的同步的系统和方法
DE112020000848T5 (de) Skalarkernintegration
DE102018110346A1 (de) Speichersystem für dnn-ausgaben für die black box
CN113495793A (zh) 用于缓冲器共享的方法和装置
DE102020129432A1 (de) System und Verfahren zum Anpassen eines ausführbaren Objekts an eine Verarbeitungseinheit
DE112020000902T5 (de) Datenvorabruf für die grafikdatenverarbeitung
CN115526760A (zh) 用于动态地改变高速缓存中的数据优先级的方法和装置
DE102020130184A1 (de) Optimierungsmechanismus mit spärlich besetzten matrizen
DE112022004016T5 (de) Zeitlich amortisierte Überabtastung unter Verwendung eines faltenden neuronalen Netzwerks mit gemischter Genauigkeit