DE102023105565A1 - VERFAHREN UND VORRICHTUNG FÜR EFFIZIENTEN ZUGRIFF AUF MEHRDIMENSIONALE DATENSTRUKTUREN UND/ODER ANDERE GROßE DATENBLÖCKE - Google Patents

VERFAHREN UND VORRICHTUNG FÜR EFFIZIENTEN ZUGRIFF AUF MEHRDIMENSIONALE DATENSTRUKTUREN UND/ODER ANDERE GROßE DATENBLÖCKE Download PDF

Info

Publication number
DE102023105565A1
DE102023105565A1 DE102023105565.8A DE102023105565A DE102023105565A1 DE 102023105565 A1 DE102023105565 A1 DE 102023105565A1 DE 102023105565 A DE102023105565 A DE 102023105565A DE 102023105565 A1 DE102023105565 A1 DE 102023105565A1
Authority
DE
Germany
Prior art keywords
memory
data
tensor
memory access
tmau
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
DE102023105565.8A
Other languages
English (en)
Inventor
Alexander L. Minkin
Alan Kaatz
Olivier Giroux
Jack Choquette
Shirish Gadre
Manan Patel
John Tran
Ronny KRASHINSKY
Jeff SCHOTTMILLER
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.)
Nvidia Corp
Original Assignee
Nvidia 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 Nvidia Corp filed Critical Nvidia Corp
Publication of DE102023105565A1 publication Critical patent/DE102023105565A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/0207—Addressing or allocation; Relocation with multidimensional access, e.g. row/column, matrix
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0875—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches with dedicated cache, e.g. instruction or stack
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0806—Multiuser, multiprocessor or multiprocessing cache systems
    • G06F12/0811—Multiuser, multiprocessor or multiprocessing cache systems with multilevel cache hierarchies
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0806—Multiuser, multiprocessor or multiprocessing cache systems
    • G06F12/0813—Multiuser, multiprocessor or multiprocessing cache systems with a network or matrix configuration
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0806—Multiuser, multiprocessor or multiprocessing cache systems
    • G06F12/084—Multiuser, multiprocessor or multiprocessing cache systems with a shared cache
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0888—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches using selective caching, e.g. bypass
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/544—Buffers; Shared memory; Pipes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/02—Neural networks
    • G06N3/06—Physical realisation, i.e. hardware implementation of neural networks, neurons or parts of neurons
    • G06N3/063—Physical realisation, i.e. hardware implementation of neural networks, neurons or parts of neurons using electronic means
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/02—Neural networks
    • G06N3/08—Learning methods
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/52—Indexing scheme relating to G06F9/52
    • G06F2209/523—Mode
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/10—Providing a specific technical effect
    • G06F2212/1016—Performance improvement
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/10—Providing a specific technical effect
    • G06F2212/1016—Performance improvement
    • G06F2212/1024—Latency reduction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/25—Using a specific main memory architecture
    • G06F2212/254—Distributed memory
    • G06F2212/2542—Non-uniform memory access [NUMA] architecture
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/45—Caching of specific data in cache memory
    • G06F2212/452—Instruction code
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/45—Caching of specific data in cache memory
    • G06F2212/454—Vector or matrix data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/62—Details of cache specific to multiprocessor cache arrangements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/02—Neural networks
    • G06N3/04—Architecture, e.g. interconnection topology
    • G06N3/044—Recurrent networks, e.g. Hopfield networks
    • G06N3/0442—Recurrent networks, e.g. Hopfield networks characterised by memory or gating, e.g. long short-term memory [LSTM] or gated recurrent units [GRU]

Landscapes

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

Abstract

Eine Parallelverarbeitungseinheit umfasst eine Vielzahl von Prozessoren, die jeweils mit einer Speicherzugriffs-Hardwareschaltung gekoppelt sind. Jede Speicherzugriffs-Hardwareschaltung ist konfiguriert zum Empfangen, von dem gekoppelten Prozessor, einer Speicherzugriffsanforderung, die eine Koordinate einer mehrdimensionalen Datenstruktur spezifiziert, wobei die Speicherzugriffs-Hardwareschaltung eine von einer Vielzahl von Speicherzugriffsschaltungen ist, die jeweils mit einem entsprechenden der Prozessoren gekoppelt sind; und zum Übersetzen, als Antwort auf die Speicherzugriffsanforderung, der Koordinate der mehrdimensionalen Datenstruktur in mehrere Speicheradressen für die mehrdimensionale Datenstruktur und zum Verwenden der mehreren Speicheradressen, zum asynchronen Transferieren zumindest eines Teils der mehrdimensionalen Datenstruktur für die Verarbeitung durch zumindest den gekoppelten Prozessor. Die Speicherorte können sich in dem gemeinsam genutzten Speicher des gekoppelten Prozessors und/oder in einem externen Speicher befinden.

Description

  • Gebiet
  • Diese Technologie bezieht sich allgemein auf die Verbesserung der Verarbeitungseffizienz und die Verringerung des Stromverbrauchs von Prozessoren. Insbesondere bezieht sich die vorliegende Technologie auf spezialisierte Schaltungen für die Handhabung von Speicherzugriffen auf Datenblöcke durch einen Parallelprozessor.
  • Hintergrund
  • Hochgradig parallele Hochleistungs-Rechnersysteme - Systeme, die viele parallel operierende Rechenverarbeitungskerne enthalten - können komplexe Berechnungen in kleinere Aufgaben aufteilen, die dann von mehreren Verarbeitungskernen gleichzeitig parallel durchgeführt werden können. So sind beispielsweise GEMMs (General Matrix Multiplications) ein grundlegender Baustein für viele Operationen in neuronalen Netzwerken (z. B. vollständig verbundene Schichten, rekurrente Schichten wie RNNs, LSTMs oder GRUs und Faltungsschichten) und wissenschaftlichen Applikationen. GEMM wird im Allgemeinen als die Operation C = αAB+βC definiert, wobei A und B als Matrixeingaben, α und β als skalare Eingaben und C als eine bereits existierende Matrix, die durch die Ausgabe überschrieben wird, dienen. In vielen Applikationen können die Matrizen sehr groß sein (z.B. 1024 x 1024 Elemente) - was viele tausend individuelle Berechnungen erfordert.
  • Um die Effizienz zu steigern, teilen moderne Grafikprozessoren solche Matrixeingaben in Kacheln auf und berechnen die Kacheln parallel, um die Rechengeschwindigkeit zu erhöhen. Durch eine solche Parallelverarbeitung können komplexe Berechnungen in einem Bruchteil der Zeit durchgeführt werden, die erforderlich wäre, wenn nur ein oder wenige Rechner dieselben Berechnungen nacheinander durchführen würden. So kann beispielsweise das Ergebnis der Multiplikation zweier großer Matrizen durch einen Satz paralleler Threads bestimmt werden, wobei jedes Element der Ergebnismatrix von einem entsprechenden Thread im Satz paralleler Threads berechnet wird.
  • Weiterhin haben die neuesten GPUs von NVIDIA und anderen Herstellern Tensor-Kerne eingeführt, um die Geschwindigkeit von Tensor-Multiplikationen zu maximieren. Solche Tensor-Kerne beschleunigen Matrix-Multiplikations- und Akkumulationsoperationen für maschinelles Lernen und wissenschaftliche Applikationen. Während Tensor-Kerne jedoch die Geschwindigkeit des Berechnens drastisch erhöht haben, haben die Geschwindigkeiten des Speicherzugriffs nicht Schritt gehalten.
  • Viele moderne Verarbeitungssysteme organisieren den Speicher in einer Hierarchie (z.B. Level-1-Cache (L1), Level-2-Cache (L2), Level-3-Cache (L3), globaler Speicher usw.). In solchen Speicherhierarchien werden Daten, an denen die Verarbeitungskerne gerade arbeiten, näher an den Verarbeitungskernen gespeichert, so dass sie den Verarbeitungskernen mit geringeren Latenzzeiten zur Verfügung gestellt werden können. Cache-Speicher, der den Verarbeitungskernen am nächsten liegt, z.B. L1-Cache, kann partitioniert, verteilt oder anderweitig organisiert werden, so dass jeder Verarbeitungskern oder Satz von Verarbeitungskernen exklusiven Zugriff auf seinen eigenen Cache hat, wodurch Wartezeiten aufgrund von Speicherkonflikten mit anderen Kernen vermieden werden. Ein solcher Cache-Speicher wird häufig von Hardware-Schaltkreisen unterstützt, die Markierungen erhalten und dafür sorgen, dass „schmutzige“ (aktualisierte) Cache-Zeilen automatisch in den Hauptspeicher zurückgeschrieben werden, bevor die Zeilen geleert werden - so muss der Software-Programmierer den Cache nicht explizit verwalten. Der L1-Cache befindet sich oft „auf dem Chip“ mit dem/den Verarbeitungskern(en), die er bedient. In einigen Systemen kann ein paralleler Verarbeitungskern auf einen nicht gecachten „gemeinsam genutzten Speicher“ zugreifen, der sich ebenfalls „auf dem Chip“ oder zumindest näher als der L2-Cache an diesem parallelen Verarbeitungskern befindet. Siehe z.B. US-Patentannmeldung Nr. 11/554,552 mit dem Titel „Shared Memory For Concurrent Threads in a Multithreaded Processor Core“, eingereicht am 30. Oktober 2006. Dieser Speicher wird von verschiedenen Verarbeitungskernen gemeinsam genutzt, um ihnen die Synchronisation und Kommunikation zu ermöglichen und um die Datenlokalität und die Wiederverwendung von Daten zu erhöhen.
  • Traditionell erfordert das Abrufen von Daten aus dem globalen Speicher (manchmal auch als „Hauptspeicher“ oder „externer Speicher“ bezeichnet) in den gemeinsam genutzten Speicher einen mehrstufigen Prozess. Der Prozessor initiiert den Prozess, indem er eine Anweisung zum Laden des Speichers aus dem Hauptspeicher durchführt. Diese Anweisung zum Laden des Speichers ruft die adressierten Daten aus dem Hauptspeicher ab und speichert sie in einer oder mehreren Cache-Zeilen eines Cache-Speichers. In modernen GPU-Architekturen kann es mehrere verschiedene Ebenen von Cache-Speicher geben (z.B. L3, L2, L1). Schließlich werden die Daten aus dem Cache-Speicher abgerufen, der dem Prozessor „am nächsten“ liegt (z.B. dem L1-Cache), und in einem oder mehreren Registern des Prozessors gespeichert. Solche Register können in einer Registerdatei allokiert werden (bei der es sich um einen weiteren Block eines lokalen oder „On-Chip“-Speichers handeln kann) - wobei verschiedene Register innerhalb der Registerdatei verschiedenen Prozessoren oder Prozessorkernen allokiert sind.
  • Ein solcher herkömmlicher Ansatz zum Laden von Daten in den gemeinsam genutzten Speicher der GPU kann im Falle großer Datentransfers, die für bestimmte gängige Transaktionen wie Matrixmultiplikationen erforderlich sind, eine große Anzahl von Registern für einen längeren und oft unbestimmten Zeitraum beanspruchen. Während dieser Zeit (die in einigen Fällen aufgrund langer Latenzzeiten des Hauptspeichers oder anderer Abhängigkeiten Tausende von Zyklen dauern kann) können die Register gebunden sein und nicht für die Verwendung für andere Zwecke zur Verfügung stehen. Eine solche Registerbindung kann die Prozessoren, die den Speicher gemeinsam nutzen, daran hindern, andere nützliche Arbeiten auszuführen, bis die Register freigegeben werden.
  • Anweisungen wie die CUDA LDGSTS (Asynchronous Global to Shared Memcopy)-Anweisung, die im US-Patent Nr. 11.080.051 mit dem Titel „Techniques for Efficiently Transferring Data To a Processor“ (Techniken zum effizienten Transferieren von Daten zu einem Prozessor), das am 3. August 2021 erteilt wurde, beschrieben ist, verbessern die Latenz, die mit dem Verschieben von Daten aus dem globalen Speicher in den gemeinsam genutzten Speicher von Streaming-Multiprozessoren (SM) in NVIDIA-Architekturen assoziiert ist, indem sie den L1-Cache und/oder Registerdateien umgehen und die vom Hauptspeicher abgerufenen Daten direkt in den gemeinsam genutzten Speicher schreiben. Es sind jedoch weitere verbesserte Verfahren zum Verschieben von Daten in den gemeinsam genutzten Speicher und aus diesem heraus erwünscht, um die Anforderungen an den Speicherzugriff effizienter und mit einer höheren Gesamteffizienz der Datenverarbeitung zu verwalten und gleichzeitig einen höheren mathematischen Durchsatz in Bereichen wie künstliche Intelligenz (AI), Deep Learning (DL) und anderen Applikationen zu erzielen, die die parallele Ausführung vorteilhaft nutzen können.
  • Kurze Beschreibung der Zeichnungen
  • Die folgende detaillierte Beschreibung von beispielhaften, nicht einschränkenden Ausführungsbeispielen ist in Verbindung mit den Zeichnungen zu lesen, wobei Folgendes gezeigt wird:
    • 1 zeigt eine GPU-Architektur mit einer Parallelverarbeitungseinheit, in der jeder Streaming-Multiprozessor mit einer Tensor-Speicherzugriffseinheit („TMAU“) gekoppelt ist, die gemäß einigen Ausführungsbeispielen spezialisierte Hardwareschaltungen für Speicheradressberechnungen und das Bewegen von mehrdimensionalen Datenstrukturen oder Datenblöcken in/aus verschiedenen Speichertypen bereitstellt.
    • 2 zeigt Interaktionen zwischen einem Streaming-Multiprozessor, einer mit dem Streaming-Multiprozessor gekoppelten Tensor-Speicherzugriffseinheit, einem externen Speicher und einem lokalen gemeinsam genutzten Speicher des Streaming-Multiprozessors, wenn ein Datenblock aus dem externen Speicher in den gemeinsam genutzten Speicher geladen wird, gemäß einigen Ausführungsbeispielen.
    • 3A und 3B (zusammen 3) zeigen Tensor-Parameter, die auf die Adressierung von Tensoren anwendbar sind, die im externen Speicher gespeichert sind und auf die von der Tensor-Speicherzugriffseinheit zugegriffen wird, gemäß einigen Ausführungsbeispielen.
    • 4A und 4B (zusammen 4) zeigen Aspekte, wie z. B. Out-of-Bounds-Bedingungen (Zustand ausserhalb von Grenzen), die von der Tensor-Speicherzugriffseinheit beim Lesen von Tensor-Daten aus dem externen Speicher detektiert werden können, gemäß einigen Ausführungsbeispielen.
    • 5A und 5B (zusammen 5) zeigen beispielhafte Deskriptoren, die verwendet werden, um auf Daten zuzugreifen, gemäß einigen Ausführungsbeispielen.
    • 6 ist eine schematische Darstellung einer Pipeline zum Verarbeiten von Speicherzugriffsanforderungen in der Tensor-Speicherzugriffseinheit, gemäß einigen Ausführungsbeispielen.
    • 7A zeigt beispielhafte Parameter, die das Lesen von Tensor-Daten durch eine Tensor-Speicherzugriffseinheit beeinflussen, gemäß einigen Ausführungsbeispielen.
    • 7B zeigt beispielhaften Pseudocode auf hoher Ebene zum Verarbeiten durch die Tensor-Speicherzugriffseinheit, gemäß einigen Ausführungsbeispielen.
    • 7C zeigt beispielhaften Pseudocode auf hoher Ebene, der einen Streaming-Multiprozessor zeigt, der die TMAU zum Laden und Speichern von Tensor-Daten für GEMM-Berechnungen (Allgemeine Matrixmultiplikationen) verwendet.
    • 8A-8K (insgesamt 8) zeigen die Verwendung von beispielhaften Datenlademodi, insbesondere den Kachelmodus und den Bild-zu-Spalte-Modus, gemäß einigen Ausführungsbeispielen.
    • 9A-9D (zusammenfassend 9) zeigen Beispiele für das Verwürfeln von Daten (Data Swizzling), das von der Tensor-Speicherzugriffseinheit verarbeitet werden kann, gemäß einigen beispielhaften Ausführungsbeispielen.
    • 10 zeigt eine beispielhafte Parallelverarbeitungseinheit eines Grafikprozessors, gemäß einigen Ausführungsbeispielen.
    • 11 A zeigt ein Beispiel eines allgemeinen Parallelverarbeitungsclusters (GPC) innerhalb der Parallelverarbeitungseinheit von 10, wobei jeder Streaming-Multiprozessor in dem allgemeinen Verarbeitungscluster mit einer Tensor-Speicherzugriffseinheit gekoppelt ist, gemäß einigen Ausführungsbeispielen.
    • 11B zeigt eine beispielhafte Speicherpartitionseinheit der Parallelverarbeitungseinheit von 10.
    • 12 zeigt einen beispielhaften Streaming-Multiprozessor von 11A.
    • 13A ist ein beispielhaftes Konzeptdiagramm eines Verarbeitungssystems, das die Parallelverarbeitungseinheit (PPU) von 10 verwendet und implementiert.
    • 13B ist ein Blockdiagramm eines beispielhaften Systems, in dem die verschiedenen Architekturen und/oder Funktionen der verschiedenen Ausführungsbeispiele implementiert sein können.
  • Detaillierte Beschreibung von nicht-einschränkenden Ausführungsbeispielen
  • Die in dieser Offenbarung beschriebene, nicht einschränkende Beispieltechnologie stellt Streaming-Multiprozessoren (SMs) oder andere Parallelprozessorkerne in einem Parallelverarbeitungssystem mit eng gekoppelten dedizierten Hardwareschaltungen zum Bewegen von Daten in und aus Speichern bereit. Beispielsweise stellt die offenbarte Technologie jedem Parallelprozessor-Kern eine enge Kopplung mit einer Tensor-Speicherzugriffseinheit (TMAU) zur Verfügung, um große Datenblöcke zwischen dem gemeinsam genutzten Speicher des Parallelprozessor-Kerns und einem externen Speicher, wie z. B. dem globalen Speicher des Parallelverarbeitungssystems, zu bewegen.
  • Viele rechnerische Applikationen erfordern sehr große (z.B. Megabytes oder sogar Gigabytes) Datenbewegungen zwischen dem globalen Speicher und den Rechenkernen der Parallelprozessorkerne wie SMs. Häufig müssen Daten, die im globalen Speicher in Form komplizierter mehrdimensionaler Strukturen mit nicht sequentiellen Zugriffsmustern angeordnet sind, in den gemeinsam genutzten oder anderen Speicher (SMEM) des/der SM(s) transferiert werden, bevor sie von dem/den SM(s) verbraucht werden. Wenn beispielsweise eine Multiplikation zweier sehr großer Matrizen, wie sie in DL-Applikationen und dergleichen verwendet werden, von einer Vielzahl von Threads durchgeführt werden soll, die auf einem oder mehreren SMs laufen, müssen die Daten dieser beiden Matrizen aus dem globalen Speicher in den gemeinsam genutzten Speicher des einen oder der mehreren SMs kopiert werden, bevor das eine oder die mehreren SMs mit den Daten operieren können.
  • Der Zugriff auf solche mehrdimensionalen Strukturen im globalen Speicher ist oft mit einem erheblichen Rechenaufwand verbunden. Die Gründe für diesen Rechenaufwand können anspruchsvolle Adressberechnungen, die Behandlung von Out-of-Bounds-Bedingungen, die Lösung von SMEM-Lese-/Schreibbankkonflikten usw. umfassen. Dieser Typ von Overhead kann sich negativ auf die Leistung eines Kernels auswirken, der auf einem SM ausgeführt wird, und erhebliche Kosten für die Softwareentwicklung verursachen. Derartige Rechen-Overheads sind in Applikationen wie DL, z. B. in Faltungs-Kerneln, oft deutlich zu erkennen. Ein typischer Faltungs-Kernel greift auf mehrdimensionale Strukturen (Matrizen, die Tensoren oder andere Sätze repräsentieren können) zu, die gemäß verschiedener Typen von Standardlayouts im globalen Speicher angeordnet sein können. Die Leistungseinbußen bei Adressberechnungen in DL-Kernen können auf den Bandbreitenverbrauch der Registerdatei (RF), zusätzliche RF-Kapazitätsanforderungen, die Behandlung von Out-of-Bounds-Bedingungen, die begrenzte Kapazität des Anweisungs-Caches, Herausforderungen bei der Planung von Anweisungen usw. zurückgeführt werden. Leistungsexperimente in verschiedenen DL-Netzwerken ergaben durchschnittliche Leistungsverluste von über 10 %. Was die Kosten der DL-Software betrifft, so haben einige Entwickler abgeschätzt, dass bis zu 90 % der Entwicklungszeit auf das Schreiben und Testen von Code für den Datenzugriff entfallen. Die Zeit der Entwickler wird durch die Komplexität der Anweisungsterminierung, die Herausforderungen bei der Registerzuweisung, die Notwendigkeit der Anpassung von Kerneln für unterschiedliche Kachelgrößen usw. in Anspruch genommen. Die mit einem Kernel assoziierte Komplexität der Adressberechnung kann sowohl die funktionale Korrektheit als auch die Leistungsoptimierung des Kernels beeinträchtigen.
  • Um die beschriebenen Probleme zu lösen, stellen Ausführungsbeispiele dieser Offenbarung eine spezialisierte Speicherzugriffseinheit bereit, die mit einem SM gekoppelt ist. In Bezug auf einige Ausführungsbeispiele, in denen die spezialisierte Speicherzugriffseinheit Fähigkeiten umfasst, die für die Bewegung von Tensor-Daten oder anderen multidimensionalen Strukturen hilfreich sind, kann sie auch als Tensor-Speicherzugriffseinheit (engl. Tensor Memory Access Unit, TMAU) bezeichnet werden. Der Typ der Daten, die die TMAU bewegen kann, ist jedoch nicht auf Tensor-Daten beschränkt, und der Zielrechner, der die Daten verwendet, muss kein Tensor-Kern sein, sondern kann jede Art von Verarbeitungskern sein.
  • Ein wesentliches Designziel der TMAU besteht darin, den gekoppelten SM(s) effiziente Datentransfermechanismen bereitzustellen, um große Datenmengen zwischen Speicherorten, wie z. B. einem globalen Speicherort und einem gemeinsam genutzten Speicherort, zu transferieren. Die TMAU ermöglicht den SM(s) ein effizienteres Rechnen, indem sie einen erheblichen Teil der damit verbundenen Datenzugriffsoperationen von den auf den SM(s) laufenden Kerneln auf die TMAU verlagert. Im Gegensatz zu Kernels, die sich auf Lade-/Speicheranweisungen pro Thread verlassen, die mit relativ kleinen Datenquanten operieren, ist die TMAU so konfiguriert, dass sie Anfragen für wesentlich größere Datenblöcke oder andere Datenstrukturen akzeptiert. Mit einer einzigen Anforderung an die TMAU können mehrere Kilobyte oder Megabyte an Daten transferiert werden, die anschließend von den SM verwendet werden. Auch wenn die Anfrage an die TMAU von einem einzigen Thread auf einem einzigen SM gestellt werden kann, können die abgerufenen Daten von mehreren Threads auf diesem SM oder auf mehreren SMs verbraucht werden.
  • Eine Vorrichtung gemäß der in dieser Offenbarung beschriebenen Technologie kann mathematische SM-Kerneinheiten mit höheren Raten versorgen als Techniken, die sich auf den SM verlassen, um Speicheradressen in den zu kopierenden Daten zu berechnen und den Fortschritt des Kopierens großer Datenblöcke zu verfolgen. Nicht einschränkende Ausführungsbeispiele stellen Techniken des Blockdatentransfers bereit, die zu einer Verringerung des Overheads beim Transferieren von Daten und beim Zugriff auf den Speicher führen. Die verringerten Kosten für das Transferieren von Daten und den Zugriff auf den Speicher können den Energieverbrauch von Multiprozessoren (z.B. auf SM-Ebene) erheblich senken und die Verarbeitungseffizienz verbessern.
  • Als Analogie kann man sich einen Küchenchef vorstellen, der in einem Restaurant für das Grillen von Steaks und Koteletts zuständig ist. Der Küchenchef kann die Steaks und Koteletts sehr schnell grillen und plattieren. In einem stark frequentierten Restaurant ist der Küchenchef jedoch in der Regel nicht dafür verantwortlich, seinen Arbeitsplatz zu verlassen, um Fleisch aus dem großen begehbaren Kühlschrank des Restaurants zu holen, das Fleisch in Teile zu schneiden, das Fett vom Fleisch zu entfernen usw. Vielmehr verlässt sich der Küchenchef auf seine Commis (Hilfsköche), die diese Arbeit erledigen. Der Küchenchef kann sich dann auf das konzentrieren, was nur er kann: die Steaks und Koteletts gemäß der Bestellung des Kunden perfekt zu grillen.
  • Die oben erwähnte LDGSTS-Anweisung verringert die Latenzzeit für den Datenzugriff, indem sie Daten aus dem globalen Speicher in den gemeinsam genutzten Speicher der SMs verschiebt, ohne dazwischen in den L1-Cache und/oder die Registerdatei zu schreiben. Bei Verwendung dieser Anweisung erfordert die Verschiebung großer Datenblöcke jedoch zahlreiche komplexe Adressberechnungen, die vom SM durchgeführt werden müssen, bevor es Speicherzugriffsanforderungen an das Speichersystem stellen kann. Im Gegensatz zu der vom SM ausgeführten LDGSTS-Anweisung ermöglicht die TMAU dem SM, einen viel größeren Datenblock mit einer einzigen Anweisung asynchron zu transferieren und auch die assoziierten Adressberechnungen und dergleichen von den Threads auf dem SM auf die TMAU zu verlagern. Im Gegensatz zu jedem parallel ausgeführten Thread, der seine eigene Anweisung besitzt, um einen kleinen Teil (z.B. eine Kachel) der Daten aus dem globalen Speicher zu erhalten, wie dies mit der LDGSTS-Anweisung oder anderen herkömmlichen Lade-/Speicheranweisungen geschieht, ermöglicht es die TMAU einem einzelnen Thread in einer Thread-Gruppe, wie z.B. einem kooperativen Thread Array („CTA“), eine Anweisung zu erteilen, um die Daten für den Zugriff aller anderen Threads in der Gruppe zu erhalten.
  • Die TMAU kann ähnlich wie eine Direct-Memory-Access (DMA)-Engine betrachtet werden, da die TMAU Lese- und Schreibvorgänge auf den globalen Speicher unabhängig von einem anfordernden Prozessor durchführen kann. Ein wesentlicher Unterschied liegt in der Fähigkeit der TMAU, mehrdimensionale Datenlayouts zu kennen und zu durchlaufen, während DMA typischerweise mit linear angeordneten Daten arbeitet. Darüber hinaus verlangt die TMAU in einem Ausführungsbeispiel nicht, dass der anfordernde Prozessor eine oder mehrere Speicheradressen in die Anfrage für den Speicherzugriff umfasst. Die TMAU kann stattdessen die entsprechende(n) Speicheradresse(n) basierend auf einer Koordinate einer mehrdimensionalen Struktur generieren, die von dem anfordernden Verarbeitungskern bereitgestellt wird.
  • In einem Ausführungsbeispiel ist jede TMAU eng mit einem SM gekoppelt, und in einigen Ausführungsbeispielen ist jede TMAU mit einem entsprechenden SM in einer Eins-zu-Eins-Beziehung gekoppelt. Die enge Kopplung an einen bestimmten SM kann es der TMAU ermöglichen, Speicherzugriffsanfragen effizienter und mit weniger Konflikten zu bearbeiten, als wenn sie Anfragen von mehreren Prozessoren bearbeiten müsste. Im Gegensatz zu DMA-Engines, die Befehle von einem Treiber empfangen, empfängt jede TMAU die Speicherzugriffsanforderungen von dem gekoppelten SM. In einigen Ausführungsbeispielen kann die TMAU im Gegensatz zu DMA-Engines, die auf das Lesen aus dem globalen Speicher beschränkt sind, Daten aus dem globalen Speicher in den gemeinsam genutzten Speicher, aus dem gemeinsam genutzten Speicher in den globalen Speicher, von Quelladressen des globalen Speichers zu Zieladressen des globalen Speichers und/oder von Quelladressen des gemeinsam genutzten (lokalen) Speichers zu Zieladressen des gemeinsam genutzten (lokalen) Speichers kopieren. Beim Kopieren innerhalb eines gemeinsam genutzten Speichers kann eine mit einem ersten SM gekoppelte TMAU Daten zwischen dem gemeinsam genutzten/lokalen Speicher des ersten SM und einem gemeinsam genutzten/lokalen Speicher eines beliebigen anderen SM in der GPU verschieben. Beispielsweise kann die TMAU in einem Ausführungsbeispiel Daten aus einem gemeinsam genutzten verteilten Speicher, der sich lokal auf dem ersten SM befindet, in einen gemeinsam genutzten verteilten Speicher, der sich lokal auf einem anderen SM befindet, kopieren.
  • Die TMAU kann weiter Fähigkeiten zum Detektieren von Datenlesungen umfassen, die außerhalb der Grenzen (out of bounds) eines Tensors liegen. In einigen Ausführungsbeispielen kann die TMAU im Gegensatz zu Techniken, bei denen jeder Thread auf einem SM ein Datenquantum aus dem globalen Speicher lädt, Daten für eine beliebige Anzahl oder Gruppe von Threads in dem gekoppelten SM laden. Weiter ist die TMAU in der Lage, als Antwort auf eine einzelne Anforderung eines Datenblocks vom anfordernden SM mehrere Anforderungen zu generieren, jede für einen entsprechenden (unterschiedlichen) Teil des angeforderten Blocks.
  • In einem anderen Ausführungsbeispiel kann ein einzelner TMAU mehrere SMs bedienen, wobei jeder SM unabhängige Anforderungen an den einzelnen TMAU senden kann. In diesem Ausführungsbeispiel kann ein in Hardware implementierter Arbiter so operieren, dass er Anforderungen von mehreren SMs annimmt und die Anforderungen seriell an die einzelne TMAU weiterleitet. Die einzelne TMAU bedient die von verschiedenen SMs empfangenen Anfragen, indem sie Daten in die gemeinsam genutzten lokalen Speicher der jeweiligen anfragenden SMs transferiert.
  • Parallelverarbeitungssystem umfassend eine TMAU-Schaltung
  • 1 zeigt schematisch eine Parallelverarbeitungseinheit, z. B. eine GPU, gemäß einigen nicht einschränkenden Ausführungsbeispielen. Wie in 1 dargestellt, umfasst die GPU 100 eine Vielzahl von Prozessoren. In einigen Ausführungsbeispielen umfasst die Vielzahl von Prozessoren beispielsweise Mehrkernprozessoren, Streaming-Multiprozessoren (SM), 102a...102n (zusammen 102). Jeder SM 102 umfasst eine Vielzahl von Verarbeitungskernen wie z. B. Funktionseinheiten 104a...104m (zusammen 104). Diese Funktionseinheiten 104 können in einigen Ausführungsbeispielen eine Vielzahl verschiedener Typen von Berechnungen durchführen, z. B. Gleitkomma-Arithmetik mit 32-Bit-Präzision, Gleitkomma-Arithmetik mit 16-Bit-Präzision, Ganzzahl-Arithmetik mit verschiedenen Genauigkeiten usw. Darüber hinaus können einige dieser Funktionseinheiten 104 Tensorkerne umfassen, die so ausgelegt sind, dass sie eine Anzahl von GEMMs pro Taktsignal auf N x N Matrizen übertragen können, die Gleitkommawerte für die Gleitkommamultiplikation und - addition enthalten. Die Anzahl der SMs in der GPU und die Anzahl der Funktionseinheiten in einem SM sind nicht begrenzt. Jede Funktionseinheit 104 in einem SM hat Zugriff auf die Registerdatei 106 für diesen SM, einen L1-Cache 108 und einen gemeinsam genutzten/lokalen Speicher 110 für diesen SM. In einigen Ausführungsbeispielen, wie in dem in 1 gezeigten, kann der L1-Cache 108 ein Teil des gemeinsam genutzten/lokalen Speichers 110 sein. In einigen anderen Ausführungsbeispielen können der L1-Cache und der gemeinsam genutzte Speicher 110 voneinander getrennt sein. Weiterhin kann in einigen Ausführungsbeispielen der gemeinsam genutzte Speicher 110 Teil einer verteilten, gemeinsam genutzten Speicheranordnung (DSMEM) sein, auf die auch Threads zugreifen können, die auf anderen SMs ausgeführt werden. Die U.S. Applikation Nr. 17/691,690 mit dem Titel „Distributed Shared Memory“, die durch Verweis in ihrer Gesamtheit einbezogen ist, beschreibt gemeinsam genutzte Speicher.
  • Die Vielzahl von SMs 102 kann über eine globale Speicherschnittstelle 114 auf den globalen Speicher 116 zugreifen, der sich außerhalb der GPU 100 befindet. Der globale Speicher 116 kann einen hierarchischen Cache-Speicher (z.B. L2-Cache und/oder L3-Cache) und Dynamic Random Access Memory (DRAM) umfassen. In einigen Beispielen kann der globale Speicher 116 eine Speicherverwaltungseinheit (MMU), ein X-Bar- oder hierarchisches Cross-Bar-Verbindungsnetzwerk, eine Speicherpartitionseinheit und/oder einen Speicher umfassen, der unter Bezugnahme auf die 10, 11A und 11B beschrieben.
  • Mehrere Kerne, wie z. B. Funktionseinheiten 104, in jedem der SMs 102 sind so konfiguriert, dass sie eine Vielzahl von Threads parallel verarbeiten. Ein Thread (z.B. ein Ausführungs-Thread) ist eine Instanziierung eines Satzes von Anweisungen oder eines Kernels, der so konfiguriert ist, dass er von den Funktionseinheiten 104 auf einem bestimmten Datensatz ausgeführt werden kann. Threads eines Thread-Blocks können gleichzeitig ausgeführt werden, und mehrere Thread-Blöcke können gleichzeitig ausgeführt werden. In einigen Ausführungsbeispielen werden Techniken zur Ausgabe von SIMD-Befehlen (Single-Instruction Multiple-Data) verwendet, um die parallele Ausführung einer großen Anzahl von Threads zu unterstützen, ohne mehrere unabhängige Befehlseinheiten bereitzustellen. In anderen Ausführungsbeispielen werden SIMT-Techniken (Single-Instruction-Multiple-Thread) verwendet, um die parallele Ausführung einer großen Anzahl von im Allgemeinen synchronisierten Threads zu unterstützen, wobei eine gemeinsame Befehlseinheit verwendet wird, die so konfiguriert ist, dass sie Anweisungen an einen Satz von Kernen ausgibt.
  • Jede der Funktionseinheiten 104 kann mit einem Cache-Speicher 108, einem gemeinsam genutzten Speicher 110 und einer Registerdatei 104 über ein Verbindungsnetzwerk verbunden sein, zum Beispiel eine hierarchische Crossbar mit einer oder mehreren Lese- und/oder Schreib-Crossbars. Der Cache-Speicher 108, bei dem es sich um einen L1-Cache handeln kann, und der gemeinsam genutzte Speicher 110 stellen einen On-Chip-Speicher mit niedriger Latenz in der Nähe der Funktionseinheiten 104 eines SM 102 bereit. Die Registerdatei 106 kann Datenregister umfassen, die per Software einer anderen Funktionseinheit der Vielzahl von Funktionseinheiten 104 und/oder verschiedenen Warps, die vom SM 102 ausgeführt werden, zugewiesen werden können. Die Registerdatei 106 stellt einen temporären Speicher für Funktionseinheiten 104 auf dem SM bereit.
  • Die GPU 100 kann mehrere Adressräume einschließlich lokaler, gemeinsam genutzter und globaler Adressräume unterstützen, um die Datensichtbarkeit für die Threads zu unterstützen. Zusätzliche schreibgeschützte Adressräume, die Konstanten und Texturen umfassen, können unterstützt werden. Jeder Thread besitzt seinen eigenen lokalen oder privaten Speicher, der durch Allokation von Registern gesteuert werden kann (siehe z.B. US-Patent Nr. 8,555,035 und US-Patent Nr. 7,634,621 , die hiermit durch Verweis einbezogen werden, als ob sie hier ausdrücklich aufgeführt wären).
  • Jeder Thread in demselben Thread-Block oder in verschiedenen Thread-Blöcken kann unter Verwendung der hierarchischen Cache-Speicher auf den globalen Speicher 116 zugreifen. Jeder Thread in demselben Thread-Block kann auf einen zugewiesenen Teil des gemeinsam genutzten Speichers 110 zugreifen, der als gemeinsam genutzter Speicher pro Block betrachtet werden kann. Jedem ausführenden Block von Threads kann ein Teil des gemeinsam genutzten Speichers 110 allokiert sein. Der gemeinsam genutzte Speicher 110 ist ein von der Software verwalteter Cache, der zum Laden von Daten aus dem globalen Speicher verwendet wird, so dass die Anzahl der Zugriffe auf den Off-Chip-Speicher durch die ausführenden Threads reduziert wird. Die Software allokiert den gemeinsam genutzten Speicher 110 explizit und greift auf ihn zu. Threads in einem Thread-Block werden synchronisiert (z.B. nach dem kooperativen Laden von Daten aus dem globalen Speicher in den gemeinsam genutzten Speicher), um Konflikte bei der Verwendung kritischer Ressourcen zu vermeiden.
  • Wenn mehrere Threads in einem Thread-Block dieselben Daten aus dem globalen Speicher 116 verwenden sollen, kann der gemeinsam genutzte Speicher 110 zur Speicherung dieser Daten verwendet werden, so dass die Anzahl der Anforderungen an den globalen Speicher 116 durch individuelle Threads für dieselben Daten reduziert wird. Der gemeinsam genutzte Speicher 110 kann auch verwendet werden, um unkoalisierte Speicherzugriffe zu vermeiden, indem Daten in einem koalisierten Muster aus dem globalen Speicher 116 geladen und gespeichert und dann im gemeinsam genutzten Speicher 110 neu geordnet werden, um den Zugriff auf die Daten durch die Threads zu verbessern.
  • In einigen Ausführungsbeispielen wie dem in 1 gezeigten, bei dem der gemeinsam genutzte Speicher 110 den L1-Cache 108 umfasst, kann der gemeinsam genutzte Speicher als ein einheitlicher Speicher oder einheitlicher Cache bezeichnet werden. Der einheitliche Cache kann im selben On-Chip-Speicher (z.B. SRAM) bereitgestellt werden, der sowohl für den L1-Cache als auch für den gemeinsam genutzten Speicher verwendet wird, und einen Mechanismus umfassen, mit dem für jeden Kernel-Aufruf allokiert wird, wie viel des einheitlichen Speichers für den L1-Cache und wie viel für den gemeinsam genutzten Speicher bestimmt ist. In einigen Beispielen kann der einheitliche Cache auch eine dynamisch konfigurierbare Registerdatei umfassen (z.B. die Registerdatei 106). Weitere Informationen über ein einheitliches Cache-System und wie es konfiguriert werden kann, finden Sie beispielsweise in den folgenden Verweisen, die durch Bezugnahme hierin aufgenommen werden, als ob sie ausdrücklich aufgeführt wären: U.S. Patentanmeldung Veröffentlichungs-Nr. 2018/0322078 ; und CUDA C Programming Guide, PG-02829-001_v10.1| Mai 2019 https://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#shared-memory.
  • Die Vielzahl von SM 102a-102n kann auf den globalen Speicher 116 über eine Vielzahl von TMAUs 112a-112n (zusammen 112) zugreifen. Jeder SM 102 ist eng mit einer entsprechenden TMAU 112 gekoppelt, die so konfiguriert ist, dass sie über die globale Speicherschnittstelle 114 auf den globalen Speicher 116 zugreifen kann. In einigen Ausführungsbeispielen ist die enge Kopplung zwischen einem SM 102 und einer TMAU 112 eins-zu-eins, und jeder SM besitzt seine eigene dedizierte TMAU 112, doch sind die Ausführungsbeispiele nicht darauf beschränkt. Jede TMAU 112 hat Lese-/Schreibzugriff auf den gemeinsam genutzten Speicher 110 und den L1-Cache 108 des entsprechenden eng gekoppelten SM 102, indem sie Anfragen an das Speicher-Subsystem und auch an den globalen Speicher 116 stellt. In einigen Ausführungsbeispielen kann eine TMAU 112 zusätzlich zum Lese-/Schreibzugriff auf den gemeinsam genutzten Speicher 110 ihres gekoppelten SMs auch Lese- und/oder Schreibzugriff auf den gemeinsam genutzten Speicher anderer SMs haben, indem sie Anforderungen an das Speichersubsystem stellt. Ein verteilter gemeinsam genutzter Speicher, der von der TMAU eines SM genutzt werden kann, um auf den gemeinsam genutzten Speicher eines anderen SM zuzugreifen, wird in der bereits durch Verweis einbezogenen US-Anmeldung Nr. 17/691,690 beschrieben. Darüber hinaus kann die TMAU mehrdimensionale Datenstrukturen oder andere Daten zwischen dem globalen Massenspeicher und dem gemeinsam genutzten linearen globalen Speicher transferieren, auf den von Cooperative Group Arrays (CGAs) zugegriffen werden kann, die auf einem oder mehreren SMs ausgeführt werden.
  • Wenn Software, die auf einer oder mehreren der Funktionseinheiten 104 läuft, Daten benötigt, die im globalen Speicher 116 gespeichert sind, initiiert die Software einen Thread mit einem „Lade“-Befehl aus dem Speicher. Der Befehl zum Laden aus dem Speicher kann Daten aus dem globalen Speicher 116 laden und die Daten im gemeinsam genutzten Speicher 110 speichern, wodurch sie für alle Threads (z.B. alle Threads in einem Thread-Block) sichtbar werden. Nachdem die Daten im gemeinsam genutzten Speicher abgelegt sind, können die Threads mehrfach auf die Daten zugreifen.
  • Jede TMAU 112 ermöglicht es den Schaltkreisen der Verarbeitungskerne im entsprechenden SM, mathematische und andere Verarbeitungen von Anwendungsprogrammkernen fortzusetzen, während die Adressberechnungen und Speicherzugriffsoperationen an eng gekoppelte Schaltkreise ausgelagert werden, die für Adressberechnungen und Speicherzugriffe vorgesehen sind. Wie im Folgenden beschrieben, ermöglicht eine TMAU 112, die mit einem SM 102 gekoppelt ist und eine eigene Hardwareschaltung besitzt, um Speicheradressen zu berechnen und gemeinsam genutzte Speicher und den globalen Speicher zu lesen und zu schreiben, dem gekoppelten SM 102, die Gesamtleistung des Kernels des Anwendungsprogramms zu verbessern, indem Zugriffe auf jeden Typ von Daten an die TMAU ausgelagert werden. Im Falle von Zugriffen auf große mehrdimensionale Datenstrukturen oder Datenblöcke, die typischerweise Hunderte oder sogar mehr Taktsignale verbrauchen, stellt die Fähigkeit des SM, solche Datenzugriffe auszulagern und asynchron mit der Verarbeitung fortzufahren, eine besonders wesentliche Leistungsverbesserung bereit.
  • 2 zeigt gemäß einigen Ausführungsbeispielen Beispielinteraktionen zwischen einem SM 102, einer mit dem SM 102 gekoppelten TMAU 112, einem gemeinsam genutzten Speicher 110 und einem L2-Cache 202 des globalen Speichers 116 während eines Speicherzugriffs durch einen auf dem SM 102 laufenden Thread.
  • Wenn ein auf dem SM 102 laufender Thread Zugriff auf einen Datenblock benötigt, bestimmt der SM-Zugriffsparameter für den Datenblock im globalen Speicher und befiehlt in Block 204 der TMAU 112 durch Übertragung einer einzelnen Speicherzugriffsanforderung, den Datenblock zu erhalten. Der Typ der vom SM an die TMAU bereitzustellenden Zugriffsparameter kann sich basierend darauf unterscheiden, ob der angeforderte Datenblock ein Tensor ist oder nicht, wie nachstehend detailliert beschrieben. Wie weiter unten detailliert beschrieben, können Anforderungen für Nicht-Tensor-Blockdaten neben der globalen Speicheradresse und der Adresse des gemeinsam genutzten Speichers für die angeforderten Daten auch die Größe des zu ladenden Blocks umfassen. Anforderungen für Tensor-Daten umfassen einen Zeiger auf einen Tensor-Deskriptor, eine mit dem angeforderten Block assoziierte Ortskoordinate und eine gemeinsam genutzte Speicheradresse.
  • In einigen Instanzen kann die Anforderung vom SM-Daten anfordern, die größer sind als die, die vom globalen Speicher durch eine einzelne Lade-/Speicheranforderung angefordert und/oder erhalten werden können. Beispielsweise kann das Speichersubsystem nur Anforderungen für Größen bis zu maximal einer L2-Cache-Zeile verarbeiten. Als Antwort auf die vom SM empfangene einzelne Speicherzugriffsanforderung, die eine große Datenmenge (eine Datenstruktur oder einen Datenblock, der größer ist als die maximal zulässige Größe für eine einzelne Anforderung an das Speicher-Subsystem) anfordert, bildet die TMAU 112 mehrere Speicherzugriffsanforderungen und gibt sie aus, um die Gesamtheit der angeforderten Daten zu erhalten. Die TMAU 112 operiert asynchron zum anfragenden SM 102 und generiert in Operation 206 die mehrfachen Speicherzugriffsanforderungen, jede mit einer anderen Adresse für einen entsprechenden Subblock der angeforderten Daten. Die mehrfachen Speicherzugriffsanforderungen werden von der TMAU 112 an den L2-Cache 202 übertragen.
  • Operation 208 repräsentiert die Antworten des L2-Cache 202 (oder des globalen Speichers) auf jede der von Operation 206 gesendeten Speicherzugriffsanforderungen. Die Unterblöcke können in den gemeinsam genutzten Speicher 110 in Operation 210 und/oder von der TMAU 112 in Operation 212 geschrieben werden. Die Operationen 212 und 214 können eine Synchronisation des anfragenden SM 102 und des Status des Abschlusses der Datenanforderung bereitstellen. Zum Beispiel kann bei jedem Subblock, der in den gemeinsam genutzten Speicher geschrieben wird, ein Zähler von der TMAU inkrementiert werden. In einigen Ausführungsbeispielen umfasst jede von der TMAU generierte Subblockanforderung die Zähleradresse im gemeinsam genutzten Speicher, und die Aktualisierung (Inkrementierung) des Zählers kann durch den gemeinsam genutzten Speicher durchgeführt werden. Der SM kann den Zähler überwachen, um zu bestimmen, wann der gesamte angeforderte Datenblock in den gemeinsam genutzten Speicher geschrieben worden ist. In einigen Ausführungsbeispielen umfasst die vom SM übertragene Anforderung die Adresse des Zählers, und der SM enthält Hardware zur Überwachung des Zählers zwecks Synchronisation.
  • Zwischen der Ausgabe der Speicherzugriffsanforderung für die Daten bei Operation 206 und der nachfolgenden Synchronisation mit den in den gemeinsam genutzten Speicher geschriebenen Daten bei Operation 214 können viele Taktzyklen vergehen. Insbesondere bei Anfragen für große Datenmengen kann dieses Intervall mehrere tausend Taktsignale betragen. Da der SM 102 jedoch den gesamten Datenblock in einer einzigen Anforderung 204 an die TMAU 112 anfordern und danach mit den Verarbeitungsanweisungen fortfahren kann, während die TMAU 112 asynchron und unabhängig vom SM 112 die Daten durch eine oder mehrere Anforderungen an den globalen Speicher (z.B. über den L2-Cache 202) erhält, kann die Verarbeitungseffizienz des SM verbessert werden. Durch die Delegation der zahlreichen Adressberechnungen, die für den Erhalt einer großen Datenmenge einer Datenstruktur oder eines Blocks erforderlich sind, und der assoziierten Koordinierung der Lade- und Speichervorgänge der jeweiligen Unterblöcke der großen Datenmenge an die Hardware in der TMAU kann auch der Stromverbrauch des SM reduziert werden.
  • Im Gegensatz zu den Ausführungsbeispielen der vorliegenden Offenbarung berechnet der SM bzw. insbesondere die jeweiligen Threads bei Verwendung der oben genannten LDGSTS-Anweisung die Adressen für jeden zu ladenden Subblock und gibt eine entsprechende Anweisung direkt an den globalen Speicher (z.B. über L2 202). Der SM muss sich dann selbst mit dem gemeinsam genutzten Speicher 110 für die jeweiligen Subblöcke synchronisieren. Da jeder Thread für jeden Datenblock entsprechende Anforderungen stellt, die auf eine maximale Größe einer vom Speichersystem bearbeiteten Anforderung begrenzt sind, kann vom SM eine große Anzahl von Anforderungen an das Speichersubsystem übertragen werden. Das Generieren einer großen Anzahl von Anforderungen und die Synchronisation des SM und des gemeinsam genutzten Speichers in Bezug auf jeden von den jeweiligen Threads angeforderten Block bedeuten einen erheblichen Mehraufwand bei der Verarbeitung und auch beim Stromverbrauch. Im Gegensatz zu den LDGSTS-Anweisungen und anderen früheren Techniken ermöglichen die hier offenbaren Ausführungsbeispiele, dass ein Thread in der Gruppe von Threads auf dem SM die gesamten Daten für alle Threads in der Gruppe von der TMAU anfordert und dass die Threads ihre Aufgaben asynchron mit der TMAU weiterverarbeiten können, bis das angeforderte Transferieren von der TMAU abgeschlossen ist.
  • Zugriff auf Tensoren
  • Obwohl die TMAU 112 verwendet werden kann, um auf einen beliebigen Typ einer Datenblockanordnung zuzugreifen, umfasst die TMAU in einigen Ausführungsbeispielen Fähigkeiten, die spezifisch für Tensoren sind. Zum Beispiel können in Applikationen wie Deep Learning (DL) große Datenmengen in Tensoren gespeichert werden. Tensoren können eine beliebige Dimension haben, von einem eindimensionalen Tensor wie einem eindimensionalen Array bis zu einem n-dimensionalen Tensor wie einem n-dimensionalen Array, wobei n eine positive Zahl ist. Obwohl in einigen Ausführungsbeispielen nur Tensoren der Dimensionen 1-5 unterstützt werden, ist gemäß einigen anderen Ausführungsbeispielen die Größe und Dimensionalität des Tensors nur durch den Speicher begrenzt, und die TMAU 112 legt keine Grenze für die Größe und/oder Dimensionalität des Tensors fest, der als Block vom SM angefordert werden kann.
  • Die TMAU-Schaltung ermöglicht es Kernel-Entwicklern, auf Subblöcke innerhalb eines Tensors zuzugreifen, indem sie Koordinaten (z.B. (x, y) in einem zweidimensionalen Tensor) verwenden, die rechnerisch einfacher sind als Speicheradressen. Die TMAU konvertiert die Koordinate in eine oder mehrere entsprechende Speicheradressen, bevor sie die Anforderung an den externen Speicher ausgibt.
  • 3A-3B (zusammen 3) zeigen Parameter, die vom SM für den Zugriff auf Tensor-Daten verwendet werden können. 3A zeigt einen dreidimensionalen Tensor 302, der im globalen Speicher gespeichert ist. Der Tensor 302 kann von einem Prozess, der auf einer CPU, GPU oder einem anderen Prozessor in einem Rechnersystem ausgeführt wird, in den globalen Speicher geschrieben werden. Einige Ausführungsbeispiele dieser Offenbarung stellen Threads bereit, die auf einem oder mehreren SMs einer GPU ausgeführt werden, um aus dem Tensor 302 im globalen Speicher zu lesen und/oder in ihn zu schreiben.
  • Der SM greift auf den Tensor 302 in Blöcken zu, die kleiner sind als der gesamte Tensor, wie z. B. die Box 306. Die in 3A dargestellten Tensor-Parameter umfassen die Anzahl der Dimensionen des Tensors, die Größe jeder Dimension, den Schritt (Stride) für jede Dimension und die Elementgröße des Tensors. Der Block, auf den innerhalb des Tensors zugegriffen werden soll, ist durch die Größe der einzelnen Dimensionen des Blocks gekennzeichnet. Die Anzahl der Dimensionen des Blocks ist die gleiche wie die Anzahl der Dimensionen des Tensors. Der Tensor kann entlang einiger Dimensionen Auffüllungen (Padding) aufweisen, wie der Bereich oberhalb und rechts des Tensors 302 innerhalb des aufgefüllten Tensors 304 zeigt. Die Auffüllung könnte durch Tensorschritte in der Tensordefinition angezeigt werden, wobei der Schritt des Tensors in einer bestimmten Dimension als die Größe des Tensors in der bestimmten Dimension plus die Größe der Auffüllung in dieser Dimension definiert ist. Es ist zu beachten, dass auf denselben Tensor mit Blöcken unterschiedlicher Größe zugegriffen werden kann. In Ausführungsbeispielen werden für jeden Tensor alle erforderlichen Parameter in einem „Tensor-Deskriptor“ definiert, der sowohl die Eigenschaften des Tensors als auch des Zugriffsblocks kombiniert. Bevor Speicherzugriffsanfragen an die TMAU gestellt werden, müssen die erforderlichen Parameter in dem Deskriptor definiert werden.
  • Der Tensor-Deskriptor ist eine Datenstruktur, die im globalen Speicher definiert ist und durch ihre Adresse im globalen Speicher eindeutig identifiziert werden kann. Er kann entweder auf der Host-Seite vor der Kernel-Ausführung oder auf der GPU definiert werden, während der Kernel läuft. Das typische Muster für den Zugriff auf einen Tensor geht davon aus, dass mehrere Blöcke aus demselben Tensor geladen werden. Das Laden des TensorDeskriptors aus dem globalen Speicher für jede neue TMAU-Anfrage für einen Block wäre ineffizient, da die Latenzzeit des globalen Speichers die Leistung negativ beeinflussen würde. Daher verfügt die TMAU in einigen Ausführungsbeispielen über einen dedizierten Deskriptor-Cache (siehe 6), um die zeitliche Tensor-Zugriffskohärenz in vielen Kernels, die auf SMs ausgeführt werden, zu nutzen.
  • 3B zeigt einen zweidimensional aufgefüllten Tensor 308. Die Figur zeigt ein „Element“ 310 im Tensor, einen Block 312 innerhalb des Tensors und die Auffüllung 314 in Bezug auf die dargestellte Dimension. Die Tensorhöhe H und die Tensorbreite W sind definiert, ebenso wie die Elementgröße 310. Der Tensor 308 ist mit der Auffüllung 314 in x-Richtung aufgefüllt. Somit umfasst der Schritt des Tensors in x-Richtung die Breite der Auffüllung. Bei dem Block 312 handelt es sich um Daten, die von einem Kernel benötigt werden und die auch eine eigene Höhe (Blockhöhe) und Breite (Blockbreite) besitzen. Der SM kann auf den Block 312 zugreifen, indem er lediglich den Ursprungspunkt 316 für den Block durch seine Koordinaten im Koordinatensystem des Tensors bereitstellt - das Koordinatenpaar x, y.
  • 4A-4B (zusammen 4) zeigen einige Aspekte der Verarbeitung, die von der TMAU beim Zugriff auf einen Tensor im externen Speicher gehandhabt werden. 4A zeigt, dass ein aus dem Tensor 308, in diesem Beispiel ein zweidimensionaler Tensor, zu lesender Block an vielen verschiedenen Stellen liegen kann, an denen sich der Anker für den Block innerhalb des Tensors befindet. Wie gezeigt, können einige der Ankerorte dazu führen, dass die Box einen Speicherbereich umfasst, der außerhalb der Grenzen des Tensors 308 liegt.
  • 4B zeigt, dass die Out-of-Bounds-Bedingung (der Ausserhalb-des-gültigen-Bereichs-Zustand) in vielen Bereichen des Tensors 308 auftreten kann. Zum Beispiel zeigt die Figur entsprechende Positionen, in denen die linke Seite der Box, die rechte Seite des Blocks, die obere und rechte Seite des Blocks, die obere Seite des Blocks oder der gesamte Block außerhalb der Grenzen des Tensors im externen Speicher liegen kann.
  • Die TMAU muss Out-of-Bounds-Bedingungen, bei denen der angeforderte Block die Grenzen des Tensors im globalen Speicher überschreiten kann, richtig behandeln. 4B zeigt einige Beispiele, bei denen angeforderte Blöcke außerhalb des 2D-Tensors liegen. Wenn sich ein angefordertes Element außerhalb des Tensors befindet, kann sein Wert entweder auf Null oder eine andere vordefinierte spezielle Konstante (z.B. ein Nicht-eine-Zahl-Wert (NAN)) gezwungen werden.
  • Die Art und Weise, wie der Zugriff auf einen nicht gebundenen Wert gehandhabt wird, hängt von der jeweiligen Applikation ab. Im einfachsten Fall wird den Elementen, die sich außerhalb des Tensors befinden, Null zugewiesen. Das typische Beispiel ist ein Faltungsfilter, der auf die Pixel in der Nähe einer Bildgrenze angewendet wird, wobei einige der Filterpositionen außerhalb des Bildes liegen können.
  • Bei komplizierteren Applikationen müssen die Elemente, die außerhalb des Tensors liegen, unter Umständen mit speziellen Konstanten ungleich Null gefüllt werden. Ein Beispiel ist das Fusionieren der Normalisierungsschicht mit der folgenden Faltungsschicht in einem neuronalen Netzwerk mit tiefem Lernen. Die Normalisierungsschicht wendet eine Verzerrung und Skalierung auf jedes Element an, bevor es durch die Faltung verarbeitet wird. Die ungebundenen Elemente müssen auf Null gesetzt werden, damit die Faltungsfilterung ordnungsgemäß funktioniert; als Ergebnis der Normalisierung wird ihnen jedoch der Verzerrungswert zugewiesen. Um diesen Fall zu behandeln, kann die TMAU so programmiert werden, dass sie eine spezielle Nicht-eine-Zahl-Konstante (engl. not-a number, NaN) zuweist und erkennt, um die Zugriffe auf die Out-of-Bound-Elemente anzuzeigen. Die spezielle NaN-Konstante kann von der TMAU in gemeinsam genutzte Speicherorte geschrieben werden, wenn die Tensor-Daten aus dem globalen Speicher in den gemeinsam genutzten Speicher geschrieben werden. Ein Kernel muss unter Umständen jedes Element aus dem globalen Speicher daraufhin überprüfen, ob es dieser speziellen Konstante entspricht. Wird die spezielle Konstante detektiert, wird dem Element der Wert Null zugewiesen, andernfalls wird eine Skalierung und Vorspannung vorgenommen. Diese Art des Verarbeitens kann für Fließkommaformate nur während der Trainingsphase von DL relevant sein. Die spezielle NaN-Kodierung ist formatspezifisch und basiert auf der Einstellung des Tensordeskriptorformats. Siehe z.B. U. S. Patent Appl. No. 17/497,507 , eingereicht am 8. Oktober 2021, mit dem Titel „Neural Network Data Replacement“, dessen gesamter Inhalt hier durch Bezugnahme aufgenommen wird.
  • 5A-5B (zusammen 5) zeigen im Zusammenhang mit einem zweidimensionalen Tensor und einem entsprechenden Block die Gruppierungen von Parametern, die von der TMAU verwendet werden, um effizient auf den Tensor im Speicher zuzugreifen. Die Parameter, die der TMAU benötigt, um einen Block innerhalb eines Tensors eindeutig zu identifizieren, sind in drei Gruppen unterteilt: eine Gruppe von „Tensor-Deskriptor“-Parametern, die den Tensor als Ganzes beschreiben, eine Gruppe von „Zugriffs-Deskriptor“-Parametern, die einen Block innerhalb des Tensors im Allgemeinen beschreiben, und ein TMAU-„Anweisungsparameter“, der einen bestimmten Block identifiziert. Die Tensor-Parameter und die Zugriffs-Deskriptor-Parameter sind in 5A dargestellt, und die TMAU-Anweisungsparameter sind in 5B gezeigt.
  • Wie in 5A gezeigt, umfassen die Tensor-Deskriptor-Parameter in einer Ausführungsform die Tensor-Höhe, die Tensor-Breite, den Tensor-Schritt und die Elementgröße. Der Tensorschritt repräsentiert die Tensorgröße (Höhe oder Breite) zuzüglich der Auffüllung in einer bestimmten Dimension. Die Parameter des Zugriffsdeskriptors umfassen die Blockhöhe, die Blockbreite und den Wert, der außerhalb der Grenzen liegt. Die Tensorhöhe, die Tensorbreite, der Tensorschritt, die Blockhöhe und die Blockbreite werden pro Dimension des Tensors spezifiziert. Wie in 5B dargestellt, umfassen die Parameter der TMAU-Anweisung nur die Startkoordinate des Blocks (z.B. (x, y)). Die Anfangskoordinate für einen n-dimensionalen Vektor ist demnach ein n-dimensionales Tupel.
  • TMAU-Verarbeitungspfad
  • 6 zeigt schematisch einen beispielhaften Datenverarbeitungspfad einer TMAU gemäß einigen Ausführungsbeispielen. In 6 ist TMAU 612 gezeigt, das SM 602 umfasst. Es versteht sich jedoch, dass die TMAU 612 in einigen Ausführungsbeispielen zwar nicht physisch innerhalb des SM 602 angeordnet, aber eng mit dem SM 602 gekoppelt sein kann.
  • Ein Speicher-Eingabe/Ausgabe-Controller (MIOC) 604 stellt eine Schnittstelle zwischen SM 602 und der Pipeline zum Verarbeiten von Anfragen der TMAU 612 bereit. Die TMAU 612 empfängt Speicherzugriffsanforderungen, die vom SM über den MIOC 604 ausgegeben werden. Die empfangenen Speicherzugriffsanforderungen werden in die interne Anforderungswarteschlange 606 eingegeben. In einigen Ausführungsbeispielen werden die Anforderungen in der Warteschlange 606 in der Reihenfolge „first in first out“ (FIFO) verarbeitet. In anderen Ausführungsbeispielen können die Anforderungen in der Warteschlange jedoch basierend auf einer oder mehreren Charakteristiken der Anforderung zur weiteren Verarbeitung ausgewählt werden, z. B. dem Anforderungstyp, der Größe der Lese- oder Schreibanforderung, dem angeforderten Datentyp, dem Speicher, auf den zugegriffen werden soll, usw.
  • In der Anforderungswarteschlange 606 können zwei Klassen von Anforderungen empfangen werden: Tensor (mit Tensordeskriptor) und Nicht-Tensor (linearer Speicher, ohne Tensordeskriptor). Die Anforderungen können verschiedenen Typen angehören, wie z. B. Laden, Speichern, Reduzieren, Vorladen usw. Für jede Anforderung von Tensor-Daten erwartet die TMAU einen Zeiger auf den Deskriptor, der die notwendigen Informationen über den zugreifenden Tensor bereitstellt. Während in einigen Ausführungsbeispielen die Anforderungswarteschlange 606 eine einzige Warteschlange ist, die beide Typen von Anforderungen empfängt, können in anderen Ausführungsbeispielen entsprechende Warteschlangen jeden Typ von Anforderung bedienen. In einigen Ausführungsbeispielen kann die TMAU nur Anforderungen zum Abruf von Tensor-Daten verarbeiten, und in einigen anderen Ausführungsbeispielen kann sie nur Anforderungen zum Abruf von Nicht-Tensor-Blockdaten verarbeiten.
  • Aus Leistungsgründen erhält die TMAU in einigen Ausführungsbeispielen, in denen die TMAU so konfiguriert ist, dass sie Speicherzugriffsanforderungen für Tensor-Daten empfängt, einen Deskriptor-Cache 608, um kürzlich verwendete Tensor-Deskriptoren zu speichern. Da allgemeine Zugriffsmuster oft beinhalten, dass auf denselben Tensor-Deskriptor durch viele in zeitlicher Nähe empfangene Anfragen zugegriffen wird, kann der Deskriptor-Cache eine geringere Latenzzeit bereitstellen. Der Cache kann durch die globalen Adressen der Tensordeskriptoren markiert werden. Jede empfangene Speicherzugriffsanforderung kann die globale Adresse des betreffenden Tensordeskriptors spezifizieren. Der Cache ist über eine Schnittstelle mit dem allgemeinen Cache-Controller (GCC) 622 verbunden. Während des Verarbeitens einer aktuellen Anforderung in der internen Anforderungswarteschlange 606 kann die TMAU prüfen, ob der Deskriptor für die nächste Anforderung im Cache 608 vorhanden ist. Ist dies nicht der Fall (d.h. handelt es sich um einen Fehlschuss), wird eine Anforderung zum Laden des Deskriptors an den GCC ausgegeben, um den Deskriptor aus dem globalen Speicher in den Cache 608 vorzuladen. Diese parallele Verarbeitung trägt dazu bei, die Latenz des Deskriptor-Vorladens zu verbergen.
  • Wenn eine Anforderung aus der Warteschlange 606 zum Verarbeiten in der TMAU 602 ausgewählt wird, wird die ausgewählte Anforderung an den Einrichtungsblock 610 gesendet, wenn es sich um eine Anforderung für einen Tensor handelt. Wenn eine Speicherzugriffsanforderung in dem Einrichtungsblock 610 empfangen wird, erhält der Einrichtungsblock 610 den entsprechenden Deskriptor aus dem Deskriptor-Cache 608. Der Setup-Block 610 sammelt und/oder berechnet die notwendigen Parameter, die zum Verarbeiten der Anfrage verwendet werden. Obwohl viele der für den Speicherzugriff erforderlichen Parameter im Deskriptor verfügbar sind (bzw. diesen umfassen), werden einige andere Parameter mit der Speicherzugriffsanforderung empfangen. Beispielsweise kann die Schaltung der Einrichtungseinheit so konfiguriert sein, dass sie eine ähnliche Logik durchführt, wie sie in Tabelle 1 unter Bezugnahme auf 8 dargestellt ist, um basierend auf dem Tensor-Deskriptor die für die Adressberechnung usw. benötigten Parameter zu füllen. Sie prüft auch die Korrektheit der Eingabeparameter der Anforderung. Wie bereits erwähnt, wird die Bandbreitennutzung für Speicherzugriffsanforderungen vom SM an die TMAU optimiert, indem Parameter, die von mehreren Speicherzugriffsanforderungen verwendet werden, aus dem entsprechenden Tensor-Deskriptor erhalten werden und indem die Speicherzugriffsanforderung vom SM nur Parameter enthält, die für die jeweilige Anforderung eindeutig sind. Parameter, die für die Speicherzugriffsanforderung eindeutig sind, wie Koordinaten oder Adressen für einen Block, können als unmittelbare Parameter mit der Anforderung übertragen werden. Der Setup-Block ist so konfiguriert, dass er Berechnungen und Fehlerprüfungen an den Parametern durchführt. Wenn die Parameter nicht den vordefinierten TMAU-Anforderungen entsprechen, wird ein Fehler generiert und die Anforderung verworfen. Der Einrichtungsblock operiert parallel zum Anforderungsgenerator 716 und stellt eine Pipeline zum Einrichten generierender Anforderungen bereit, wodurch die Latenzzeit verringert wird.
  • Der Anforderungsgenerator 616 ist die Haupt-TMAU-Engine. Für eine Anforderung von Tensor-Daten empfängt er die relevanten Parameter vom Setup-Block und durchläuft den Tensor-Raum, indem er mehrdimensionale Koordinaten iteriert, Koordinaten zu Adressen zuordnet, Out-of-Bounds-Bedingungen überprüft, gemeinsam genutzte Speicheradressen berechnet, globale Speicheradressen berechnet und Anforderungen an das Speicher-Subsystem generiert. Der Anforderungsgenerator generiert so viele Anforderungen an das Speichersystem zum Laden/Speichern des Blocks von Tensor-Daten wie nötig, wobei die maximale Größe der vom Speichersubsystem bearbeiteten Speicheranforderungen eingehalten wird. Typischerweise schreibt das Speichersubsystem eine maximale Größe von einer Cache-Zeile (z.B. die Größe einer L2-Cache-Zeile) für jede an das Speichersubsystem empfangene Anforderung vor. Der Anforderungsgenerator optimiert die Anforderungen, um die Effizienz des Speichersubsystems zu verbessern. Die Verarbeitung durch den Anforderungsgenerator 616 stellt das automatische Generieren von Zugriffsanfragen für einen ganzen Block durch spezialisierte Hardware bereit, wodurch der Stromverbrauch reduziert wird. 7B zeigt einen High-Level-Beispielpseudocode zur Veranschaulichung des Verarbeitens innerhalb des Anforderungsgenerators.
  • Die Datenanforderung wird über die GNIC-Schnittstelle (General Network Interface Controller) 614 an das Speicher-Subsystem übertragen, und jede Anforderung wird in der Schaltung 618 zur Vervollständigung der Antwort verfolgt. Die Verfolgung ermöglicht die asynchrone Verarbeitung mit dem SM. Die Antworten auf die Anforderungen werden von einem GNIC-Antwortprozessor 620 empfangen, der mit der Anforderungsverfolgungsschaltung 618 kommuniziert, um den Abschlussstatus jeder vom Anforderungsgenerator 716 übertragenen Anforderung zu verfolgen.
  • Wenn die vom SM empfangene Speicherzugriffsanforderung für Blockdaten gilt, die kein Tensor sind, kann die Anforderung in einigen Ausführungsbeispielen unter Umgehung des Deskriptor-Caches 608 an den Anforderungsgenerator 616 gesendet werden. In 6 können beispielsweise die Anforderungen für Nicht-Tensor-Blockdaten von der Warteschlange 604 zum Anforderungsgenerator geroutet werden, wobei der Deskriptor-Cache 608 und die Setup-Einheit 610 umgangen werden. In einigen Ausführungsbeispielen können solche Anforderungen jedoch von der Warteschlange 606 zur Setup-Einheit 610 geleitet werden, bevor sie im Anforderungsgenerator 616 verarbeitet werden. Die vom SM empfangene Anforderung für einen großen Nicht-Tensor-Datenblock kann eine globale Speicheradresse für den Block, die gemeinsam genutzte Speicheradresse für den Block und die Größe des Blocks in Bytes umfassen. Der Anforderungsgenerator 616 kann bei einer vom SM empfangenen Anforderung eines großen Nicht-Tensor-Datenblocks automatisch eine Folge von Anforderungen an das Speicher-Subsystem generieren, wobei jede Anforderung einen kleineren Subblock des angeforderten Blocks betrifft. Der Anforderungsgenerator berechnet die globalen Speicheradressen für die Subblöcke basierend auf der globalen Speicheradresse für den Block, wie sie in der vom SM empfangenen Anforderung enthalten ist, und die Größe des Subblocks kann gemäß der maximalen Größe der vom Speicher-Subsystem gehandhabten Anforderungen bestimmt werden. Die Schaltung 618 zur Verfolgung des Abschlusses von Anforderungen verfolgt die Speicheranforderungen für die Subblöcke und die vom Speichersubsystem empfangenen Antworten auf dieselbe Weise, wie oben in Bezug auf Tensor-Datenblöcke beschrieben.
  • 7A und 7B zeigen Beispielparameter, die verwendet werden, um einen in 7A gezeigten Block 704 zu verfolgen, wenn eine Tensor-Datenstruktur 702 von der Schaltung der TMAU gelesen wird. 7A zeigt Beispiele für Parameter einschließlich Anker, Basis und Stromelement, die in dem in 7B gezeigten High-Level-Pseudocode einen Teils der in der Hardware der TMAU implementierten Verarbeitungslogik verwendet werden. 7C zeigt ein Beispiel für High-Level-Pseudocode, in dem der SM-Tensor-Ladeoperationen in der TMAU aufruft, um Daten aus dem globalen Speicher in den gemeinsam genutzten Speicher zu kopieren und nachfolgend die Ergebnisdaten in den globalen Speicher zu schreiben.
  • Der Pseudocode in 7B ist ein High-Level-Beispiel für einige der Verarbeitungsschritte, die von der TMAU als Antwort auf den Empfang einer Anforderung von ihrem gekoppelten SM zum Erhalt eines Blocks aus einem Tensor im globalen Speicher durchgeführt werden. Der Pseudocode ist in fünf verschachtelten Schleifen angeordnet, wobei jede Schleife jeweils einer der fünf Koordinatenachsen des Tensor-Datenraums entspricht. Obwohl das Beispiel für einen Tensor-Datenraum von fünf Dimensionen gilt, können einige Ausführungsbeispiele N verschachtelte Schleifen für einen N-dimensionalen Tensor-Datenraum unterstützen, wobei N eine beliebige positive ganze Zahl sein kann.
  • Das aktuelle Element wird innerhalb der innersten Schleife verarbeitet, indem die berechneten Koordinaten in jeder der fünf Dimensionen (Koordinaten c0, c1, c2, c3 und c4), die Adresse im gemeinsam genutzten Speicher, in den das aktuelle Element geladen werden soll, und die globale Adresse des aktuellen Elements spezifiziert werden. Nachdem das aktuelle Element erhalten wurde, werden die globale Speicheradresse und die Adresse des gemeinsam genutzten Speichers für das nächste Element berechnet, indem die globale Adresse um die Elementgröße für den Tensor und die Adresse des gemeinsam genutzten Speichers um ein vordefiniertes Adressinkrement des gemeinsam genutzten Speichers inkrementiert wird (das Adressinkrement des gemeinsam genutzten Speichers kann im Tensordeskriptor definiert sein und auf der für den Tensor definierten Elementgröße basieren). Die Verarbeitung innerhalb der innersten Schleife umfasst Verarbeitungen wie die Überprüfung von Out-of-Bounds-Bedingungen usw., die von der TMAU zum Kopieren von Tensor-Daten durchgeführt werden.
  • Die innerste Schleife stellt die Iteration über Elemente entlang der Dimension 0 (der Dimensionen 0-4) bereit, indem sie mit der Koordinate des angeforderten Blocks in der Dimension 0 (blockstart0) beginnt und die aktuelle Koordinate c0 in der Dimension 0 um den Traversalschritt für die Dimension 0 („tensorDescriptor.traversalStride[0]“) bis zu einer Koordinate in der Dimension 0 inkrementiert, die die Boxgröße in der Dimension 0 überschreitet („blockStart0 + tensorDescriptor.boxSize[0]“; Blockgrenze wird überschritten).
  • Wenn die innerste Schleife (die Schleife zur Iteration durch die Tensorelemente in der Dimension 0) verlassen wird, wird die globale Basisadresse für die nächste äußere Dimension (d. h. Dimension 1) um den für die Dimension 0 definierten Tensorschritt erhöht („baseGlobalAddr[1] += tensorDescriptor.tensorStride[0]“). Dadurch wird die globale Adresse auf den nächsten Abschnitt vorgerückt. Die initiale globale Adresse für jede Dimension wird basierend auf der globalen Adresse bestimmt, die dem Ankerelement des angeforderten Blocks entspricht.
  • Wie in 7B gezeigt, stellt jede Schleife in ähnlicher Weise wie oben für die Dimension 0 beschrieben eine Iteration in einer jeweiligen Dimension für eine Anzahl von Malen bereit, die durch eine Startblockkoordinate, den Traversalschritt entlang dieser Dimension und die Boxgröße für diese Dimension bestimmt wird. Es ist zu beachten, dass der Traversalschritt und die Boxgröße für jede Dimension im Tensordeskriptor für den Tensor definiert sind.
  • Indem die TMAU die mit dem Kopieren von Datenblöcken aus einem Tensor in den globalen Speicher verbundene Verarbeitung in Hardware durchführt, kann sie die Rechenlast auf dem SM zum Bewegen von Daten erheblich reduzieren und so die Verarbeitungseffizienz des SM erhöhen und auch den Stromverbrauch des SM verringern.
  • Der obige Pseudocode in 7B stellt High-Level-Ausführungslogik bereit und lässt Details im Zusammenhang mit bestimmten Aspekten aus, wie z. B. effizientes Generieren von L2-Anforderungen, Verwürfeln und Behandeln von Out-of-Bounds-Bedingungen, die von der TMAU beim Lesen und/oder Schreiben von Tensoren ausgeführt werden.
  • Zusätzlich zum Generieren von L2-Anforderungen (Anforderungen an den globalen Speicher) verfolgt die TMAU die Rückgabedaten, um den Abschluss der TMAU-Transaktion zu melden. Die TMAU muss über einen eigenen Zähler verfügen, der die ausgegebenen L2-Anforderungen verfolgt. Jedes Mal, wenn eine Anforderung an den L2 Cache gesendet wird, wird der Zähler inkrementiert. Wenn Daten aus dem L2-Cache zurückkommen, wird der Zähler dekrementiert. Sobald der Zähler den Nullwert erreicht, wird der gesamte Block in den gemeinsam genutzten Speicher geladen und die TMAU kann den Abschluss der Transaktion melden. Aus Effizienzgründen kann die TMAU einen einzigen Zähler verwenden, um eine Gruppe von mehreren Back-to-Back-Transaktionen zu verfolgen und den Abschluss der letzten Transaktion in der Gruppe zu melden. In einigen Ausführungsbeispielen kann der/die Zähler an einem vordefinierten Ort im gemeinsam genutzten Speicher erhalten werden. Der SM kann eine Schaltung zur Synchronisation umfassen, die den/die Zähler überwacht und basierend auf dem Zähler eine Synchronisationsbarriere oder ähnliches implementiert.
  • 7C zeigt einen beispielhaften Pseudocode für einen Faltungsfilter mit implizitem GEMM, der von einem auf einem SM laufenden Kernel durchgeführt wird. GEMM ist, wie ebenfalls oben erwähnt, allgemein als die Operation C = αAB + βC definiert, wobei A und B als Matrixeingaben, α und β als skalare Eingaben und C als eine bereits vorhandene Matrix, die durch die Ausgabe überschrieben wird, dienen. Ein einfaches Matrixprodukt AB ist eine GEMM mit α gleich eins und β gleich null. Dieser Typ von Berechnungen wird für viele DL-Applikationen und dergleichen benötigt. Ein Beispiel für die Implementierung einer effizienten Matrixmultiplikation und -addition, die die TMAU verwenden kann, wird in der US-Applikation Nr. 17/691,406 mit dem Titel „Efficient Matrix Multiply and Add with a Group of Warps“ beschrieben, die hiermit durch Bezugnahme in ihrer Gesamtheit einbezogen wird.
  • Der Kernel erhält Zeiger auf Tensor-Deskriptoren für drei Tensoren: einen Aktivierungs-Tensor, einen Gewichts-Tensor und einen Ausgabe-Tensor, sowie Größeninformationen für jeden dieser Tensoren. Der Aktivierungstensor, der Gewichtstensor und der Ausgangstensor können in der GEMM-Berechnung als Matrizen A, B bzw. C repräsentiert werden. Der Kernel stellt der TMAU die Zeiger auf die Tensordeskriptoren für den Aktivierungstensor, den Gewichtstensor und den Ausgabetensor bereit, wenn er eine nachfolgende Speicherzugriffsanforderung (tensorBlockLoad()) an die TMAU stellt.
  • Die Logik ist als eine Reihe von verschachtelten Schleifen organisiert, so dass eine Folge von Blöcken jedes Tensors kopiert wird, indem ein entsprechender Block in jeder Iteration der innersten Schleife kopiert wird. In jeder Iteration der innersten Schleife gibt der Kernel eine entsprechende tensorBlockLoad-Anforderung an die gekoppelte TMAU aus, um jeweils einen Block aus dem Aktivierungstensor und dem Gewichtstensor zu laden. Die tensorBlockLoad-Anforderung enthält als Argumente die Adresse des Tensors im globalen Speicher (wie vom SM bestimmt) und die Adresse im gemeinsam genutzten Speicher, in den die Tensor-Daten aus dem globalen Speicher geschrieben werden sollen. Die verschachtelten Schleifen sind so angeordnet, dass die äußeren drei Schleifen vertikal, horizontal und kanalweise iterieren, während die innersten Schleifen den Faltungsfilter iterieren.
  • Das NHWC-Layout (N (Dimension), Höhe, Breite, Kanal) wird für den Aktivierungstensor und das KNWC-Layout für den Gewichtstensor angenommen. Der Code iteriert durch die Dimensionen W und H. Er akkumuliert für Kanäle (Dimension C) und jede rund s-Position des Faltungsfilters. Der Einfachheit halber werden die Iterationen durch die Dimensionen N und K nicht dargestellt. Für gegebene [c, s, r] lädt die TMAU-Datenblöcke aus dem globalen Speicher in den gemeinsam genutzten Speicher. Das Laden erfolgt sowohl für Aktivierungs- als auch für Gewichtstensoren. Nachdem die Daten für die beiden Matrizen in den gemeinsam genutzten Speicher geladen wurden, kann der SM die GEMM-Berechnung aufrufen (computeGEMMQ). In einigen Ausführungsbeispielen wird die GEMM-Berechnung von einer spezialisierten Hardwareschaltung durchgeführt, und das Ergebnis wird in der Ausgabematrix akkumuliert. Die Matrixmultiplikation wird in dem gemeinsam genutzten Speicher berechnet.
  • Nachdem die Berechnung unter Verwendung der in den gemeinsam genutzten Speicher geladenen Tensor-Daten abgeschlossen ist, wird die TMAU vom Kernel auf dem SM verwendet, indem er eine Anforderung (tensorBlockStoreQ) ausgibt und die Adressen für die Ausgabe-Matrix, in der die Ergebnisse der GEMM gespeichert sind, und die Adresse im gemeinsam genutzten Speicher, in die das Ergebnis geschrieben werden soll, bereitstellt, um die Ergebnisse aus dem Puffer des gemeinsam genutzten Speichers in den Tensor im globalen Speicher zu speichern.
  • Unterstützung für Tensor-Lademodi
  • Die TMAU unterstützt mehrere Speicherlayouts für Tensoren. Zum Beispiel können dreidimensionale Bildtensoren das Tensor-Layoutformat NDHWC haben, in dem die innerste Dimension C die Anzahl der Kanäle repräsentiert (z.B. kann in einem Bildtensor jeder Kanal eine Farbe repräsentieren), die Dimensionen D, H, W entsprechen den Dimensionen Tiefe, Höhe bzw. Breite und N repräsentiert die Stapelgröße des Tensors.
  • Zusätzlich zur Unterstützung mehrerer Tensor-Layoutformate unterstützt die TMAU auch Tensoren, die im globalen Speicher im nicht verschachtelten Modus oder im verschachtelten Modus gespeichert sind. Im verschachtelten Modus kann die TMAU mehrere Abschnittsgrößen unterstützen (z.B. 16-Byte-Abschnitte, 32-Byte-Abschnitte usw.). In einigen Ausführungsbeispielen kann der Tensor-Deskriptor für einen Tensor spezifizieren, ob sich dieser Tensor im nicht verschachtelten Modus oder im verschachtelten Modus im globalen Speicher befindet, und auch die Größe des Abschnitts im verschachtelten Modus.
  • Darüber hinaus unterstützt die TMAU in einigen Ausführungsbeispielen mehr als einen Tensor-Lademodus. Zum Beispiel können ein Kachelmodus und ein Bild-zu-Spalte-Modus (auch als „im2col“ bezeichnet) als Tensor-Daten-Lademodi unterstützt werden.
  • Der Kachelmodus wird in einigen Instanzen aus Gründen wie der Datenreplikation, die bei der Implementierung der impliziten allgemeinen Matrixmultiplikation (GEMMs) nicht erforderlich ist, bevorzugt und stellt daher erhebliche Einsparungen bei der Speicherbandbreite bereit. Andererseits kann es in einigen Fällen zu Leistungseinbußen aufgrund von Kachelquantisierungseffekten kommen. Der Kachelmodus ist ein allgemeiner TMAU-Lademodus, der in einer Vielzahl verschiedener DL- und Hochleistungsrechner-Applikationen (HPC) verwendet werden kann. Ein Beispiel für Tensor-Traversal für den Kachelmodus ist oben in Bezug auf 7A und 7B beschrieben.
  • Der im2col-Modus wird hauptsächlich in Faltungs-Kerneln basierend auf impliziter GEMM verwendet. Wenn der im2col-Modus ausgewählt ist, führt die TMAU eine Bild-Spalten-Transformation durch, wenn sie Tensorblöcke aus dem globalen Speicher lädt. Dies führt zu einer zusätzlichen Komplexität des Tensor-Traversal-Algorithmus.
  • Im Kachelmodus definiert der Tensor-Parameter boxSize[] eindeutig die Größe der BoundingBox im Tensorraum, die alle Elemente enthält, die die TMAU als Antwort auf eine Anweisung des SM laden soll. Jedes Element von boxSize[] spezifiziert die BoundingBox-Größe entlang einer entsprechenden Dimension: boundingBox[i] = boxSize[i]. Die in einer TMAU-Speicherzugriffsanforderung vom SM spezifizierten Koordinaten definieren eindeutig den Ort der BoundingBox im Tensorraum.
  • Im im2col-Modus sind die Größe und die Position der BoundingBox anders definiert. Die Anzahl der BoundingBox-Dimensionen ist um eins geringer als die Tensor-Dimensionalität im Tensor-Deskriptor. boxSize[] wird in diesem Modus nicht verwendet, stattdessen gibt es alternative Parameter im Tensor-Deskriptor zur Unterstützung des im2col-Modus. Die alternativen Parameter umfassen die folgenden: rangeNDHW, rangeC, boxBaseCornerDHW, boxFarCornerDHW. Die Parameter boxBaseCornerDHW und boxFarCornerDHW definieren die Größe und Position der BoundingBox im DHW (Depth, Height, Width)-Raum. Der Parameter boxBaseCornerDHW spezifiziert die initialen Koordinaten des BoundingBox-Ursprungs, der die linke obere Ecke der Box ist. Der Parameter boxFarCornerDHW spezifiziert die initiale Position der gegenüberliegenden rechten unteren Ecke. Die Positionen der Ecken werden als vorzeichenbehaftete Offsets von den entsprechenden Tensorecken definiert. Daher können die Ecken des Begrenzungsrahmens sowohl innerhalb als auch außerhalb der Tensorgrenzen spezifiziert werden.
  • Die Positionen der Ecken des Begrenzungsrahmens werden von der Größe des Faltungsfilters und dem ausgewählten Dilatationsfaktor beeinflusst. Die Eckkoordinaten können als die Hälfte der Filtergröße multipliziert mit dem Dilatationsfaktor berechnet werden. Die Präzision für die Bounding-Box-Ecken wird so gewählt, dass ein breiter Bereich von Faltungs-Kernel-Größen und Dilatationsfaktoren bereitgestellt werden kann. Basierend auf der Analyse realer Applikationen kann eine höhere Präzision für Tensoren mit geringerer Dimensionalität wünschenswert sein. Zum Beispiel kann eine Applikation zur Sprachverarbeitung, die 3D-Tensoren verwendet, einen Dilatationsfaktor von bis zu 8K erfordern, während Applikationen zur Bildverarbeitung, die 4D- oder 5D-Tensoren verwenden, viel kleinere Dilatationsfaktoren von bis zu 128 benötigen.
  • boxBaseCornerDHW und boxFarCornerDHW definieren boundingBox-Größen unter Verwendung der folgenden Formeln: boundingBox{D,H,W} = tensorSize{D,H,W} - boxBaseCorner{D,H,W} + boxFarCorner{D,H,W}). Für die Dimension C wird die Größe durch den Parameter rangeC definiert.
  • 8A zeigt, wie boundingBox von den Einstellungen boxBaseCorner{D,H,W}, boxFarCorner{D,H,W} abhängt. Dieses Beispiel zeigt, dass viele Typen von Rändern in den Datenstrukturen verwendet werden können, und im im2col-Modus kann die Quantisierung vermieden werden.
  • Im Kachelmodus hängt die Anzahl der zu ladenden Elemente von den Parametern boxSize[] ab. Wenn die TMAU eine bestimmte Dimension durchläuft, verwendet sie den entsprechenden Wert aus boxSize[], um zu bestimmen, wie viele Elemente zu laden sind. Im im2col-Modus wird rangeNDHW verwendet, um zu bestimmen, wie viele Elemente entlang der NDHW-Dimensionen zu laden sind, und rangeC für die Dimension C. Eine einzelne TMAU-Anfrage kann es erforderlich machen, dass die TMAU mehrere Bilder aus einem Stapel (N Dimensionen) durchläuft, um die gewünschte Anzahl von Elementen zu laden. Wenn TMAU während des Durchlaufs mehrerer Bilder vom aktuellen Bild zum nächsten wechselt, überspringt es möglicherweise Kanäle, die außerhalb des durch den Parameter rangeC definierten Bereichs liegen.
  • Im Kachelmodus spezifizieren die von TMAU angeforderten Koordinaten die BoundingBox-Position (Ursprung) im Tensorraum. Im im2col-Modus werden Koordinaten entlang der C- und N-Dimensionen ähnlich wie im Kachelmodus verwendet; die Koordinaten entlang der W-, H- und D-Dimensionen spezifizieren jedoch die Basisposition des Faltungsfilters (linke obere Ecke) im Tensorraum. Zum korrekten Verarbeiten verlangt die TMAU, dass die Basisposition des Filters immer innerhalb der BoundingBox definiert ist. Darüber hinaus müssen in der TMAU-Anfrage Koordinatenoffsets für diese Dimensionen spezifiziert werden. Die Offsets ermöglichen es, die Position des Blocks relativ zum Tensor zu spezifizieren und daher nur eine minimale Anzahl von Bytes zu verwenden. Die Offsets werden zu den auf dem Filter basierenden Ortskoordinaten addiert, um die Startpositionen im Tensorraum zu bestimmen, von denen aus der Ladevorgang initiiert werden muss. Dieselben Offsets werden verwendet, um die BoundingBox relativ zu den in boxBaseCornerDHW angegebenen initialen Koordinaten zu positionieren. Die Offsets werden auf eine Teilmenge der Koordinaten basierend auf der oben definierten Tabelle angewendet. Die Offsets sind als Ganzzahl ohne Vorzeichen mit variabler Präzision definiert. Die Präzision hängt von der Dimensionalität des Tensors ab und wird basierend auf der früheren Begründung für die Präzision der Bounding-Box-Koordinaten gewählt.
  • In einigen Ausführungsbeispielen werden alle Offsets in 16 Bits innerhalb eines einzigen Registers gepackt. Die Anzahl der Offsets hängt von der Dimensionalität des Tensors ab; daher kann die Präzision entsprechend variieren. In einem typischen Faltungs-Kernel kann die einmal berechnete Filterbasis für mehrere TMAU-Anforderungen mit unterschiedlichen Koordinaten-Offsets wiederverwendet werden. Die Anzahl der Wiederverwendungen hängt von der Größe des Faltungsfilters ab. Bei einem 3x3-Filter werden beispielsweise neun Anfragen für dieselbe Position der Filterbasis ausgegeben.
  • Für die verschachtelten Layouts muss die C-Koordinate in Form von Kanalabschnitten und nicht in Form von individuellen Kanälen spezifiziert werden. Dies gilt sowohl für den Kachelmodus als auch für den im2col-Modus.
  • Tabelle 1 zeigt beispielhaften High-Level-Pseudocode für die in der TMAU implementierte Logik, insbesondere im Setup-Block, zur Konfiguration der Tensor- und Zugriffsparameter basierend auf dem in einer empfangenen TMAU-Anfrage identifizierten Tensor-Deskriptor
  • Figure DE102023105565A1_0001
  • Die folgenden Beispiele zeigen die Verwendung des im2col-Modus. Ein 3x3-Faltungsfilter wird auf einen NHWC-Tensor (64x14x9x64) angewendet. Jede Anforderung lädt 64 Elemente entlang der Dimensionen N, H, W und 8 Elemente entlang der Dimension C.
  • Im ersten Beispiel, das in 8B gezeigt wird, kann der Filter über die Tensorgrenze hinausgehen und auf die umgebende Auffüllung (Rand) zugreifen, die als Null oder konstanter Wert definiert werden kann. Die Tensor-Deskriptor-Parameter sind wie folgt gesetzt: tensorSize[0]=64; tensorSize[1]=9; tensorSize[2]=14; tensorSize[4]=64; rangeNDHW = 64; rangeC = 8; boxBaseCornerW = -1; boxBaseCornerH = -1; boxFarCornerW = -1; boxFarCornerH = -1. 8B zeigt das Verarbeiten von Anfragen mit den Koordinaten (7, 7, 4, 0) und verschiedenen Koordinatenversatzwerten: (0, 0), (1, 1), (2, 2). Dieses Beispiel zeigt das Laden verschiedener Begrenzungsbereiche des Tensors. Sie sind als Offsets definiert. Der Anforderer spezifiziert der TMAU den Begrenzungsbereich und wie viele Elemente geladen werden sollen (z.B. einen Bereich von Elementen - in diesem Fall 64). Dies kann als Parameter im Tensordeskriptor spezifiziert werden. Ein weiterer Parameter, der auf Anweisungsebene bereitgestellt werden kann, spezifiziert den Startpunkt des Blocks für das Laden der Anforderung. Die TMAU weiß, dass sie Tensorelemente ab der spezifizierten Startposition plus Offsets innerhalb des dargestellten Rechtecks laden und eine bestimmte Menge an Daten laden muss.
  • Im nächsten Beispiel ist der Filter so konfiguriert, dass er innerhalb der Tensorgrenzen bleiben muss und daher keine Auffüllung/Rahmen auf dem Tensor benötigt wird. Die Tensor-Deskriptor-Parameter sind wie folgt gesetzt: rangeNDHW = 64; rangeC = 8; boxBaseCornerW = 0; boxBaseCornerH = 0; boxFarCornerW = -2; boxFarCornerH =-2. 8C zeigt zum Verarbeiten die Anforderungen mit den Koordinaten (7, 7, 4, 0) und verschiedenen Koordinatenversatzwerten: (0, 0), (1, 1), (2, 2).
  • Zum Vergleich wird in den nächsten Beispielen gezeigt, wie ähnliche Faltungsfälle im Kachelmodus behandelt werden. Mit einer einzigen TMAU-Anforderung können alle für das Berechnen der Faltung benötigten Pixel an allen Filterpositionen geladen werden. Um dies zu erreichen, müssen die zusätzlichen Halo-Pixel geladen werden. Die Anzahl der Halo-Pixel hängt von der Filtergröße ab.
  • Im nächsten Beispiel wird ein 3x3-Faltungsfilter auf einen NHWC-Tensor (64x14x8x64) angewendet. Der Filter kann über die Tensorgrenze hinausgehen und auf die umgebende Auffüllung (Rand) zugreifen, die als Nullwert oder konstanter Wert definiert sein kann. Die einzelne Anforderung lädt eine 10x10-Kachel entlang der Dimensionen H, W und 8 Elemente entlang C. Jede geladene 10x10-Kachel hat 2 Halo-Zeilen und 2 Spalten. Die Tensor-Deskriptor-Parameter werden wie folgt eingestellt: tensorSize[0]=64; tensorSize[1]=8; tensorSize[2]=14; tensorSize[4]=64; boxSize[0] = 8; boxSize[1] = 10; boxSize[2] = 10; boxSize[3] = 1. Für jede gegebene Filterposition wird nur eine 8x8-Kachel für Faltungsberechnungen verwendet. 8D zeigt die Verarbeitungen für die Anforderungen mit den Koordinaten (0, -1, -1, 0). Negative W-, H-Blockkoordinaten werden benötigt, um auf Pixel außerhalb der Tensorgrenze mit Null oder einer Konstante (Auffüllung) zuzugreifen. Es werden die 8x8 Kacheln gezeigt, die zum Verarbeiten verschiedener Filterpositionen verwendet werden: (0, 0), (1, 1), (2, 2).
  • Das folgende Beispiel ähnelt dem vorangegangenen, aber der Filter muss innerhalb der Tensorgrenzen bleiben, und es ist keine Auffüllung/Rahmen erlaubt. Eine einzelne TMAU-Anfrage lädt eine 8x8-Kachel entlang der Dimensionen H, W und 8 Elemente entlang C. Jede geladene 8x8-Kachel hat 2 Halo-Zeilen und 2 -Spalten. Die Tensor-Deskriptor-Parameter sind wie folgt gesetzt: boxSize[0] = 8; boxSize[1] = 8; boxSize[2] = 8; boxSize[3] = 1. Für jede gegebene Filterposition wird eine 6x6-Kachel für Faltungsberechnungen verwendet. Zu jedem gegebenen Zeitpunkt werden nur 36 Pixel für Berechnungen verwendet. Das ist weniger als die optimalen 64 Pixel. Dies ist ein Beispiel für einen Kachelquantisierungseffekt, der die Gesamtleistung beeinträchtigen kann. 8E zeigt die Verarbeitungen für die TMAU-Anforderungen mit den Koordinaten (0, 0, 0, 0). Die Einstellung der W- und H-Blockkoordinaten auf Null verhindert, dass die Tensorgrenze überschritten wird. Es werden 6x6 Kacheln gezeigt, die zum Verarbeiten verschiedener Filterpositionen verwendet werden: (0, 0), (1, 1), (2, 2).
  • Der Tensor-Deskriptor-Parameter traversalStride wirkt sich sowohl auf den Kachelmodus als auch auf den im2col-Modus aus. Je größer der traversalStride im Kachelmodus ist, desto kleiner ist die Anzahl der für die Ladung besuchten Tensorostellen, was die Gesamtzahl der geladenen Elemente reduziert. Zum Vergleich: Im im2col-Modus hängt die Anzahl der geladenen Elemente entlang der NDHW-Dimensionen nicht vom traversalStride entlang dieser Dimensionen ab: Sie ist gleich dem Tensor-Deskriptor-RangeNDHW-Parameter. Wie im Kachelmodus wird jedoch die Anzahl der Elemente, die entlang der Dimensionen W, Hund D durchlaufen werden, durch den traversalStride basierend auf der Formel ceil(boundingBox {D,H, W} / traversalStride{D,H,W}) beeinflusst.
  • 8F zeigt die Handhabung von traversalStride im im2col-Modus. Ein 3x3-Faltungsfilter wird auf den NHWC-Tensor (64x14x9x64) mit traversalStride gleich zwei angewendet. Jede Anforderung lädt 32 Elemente entlang der Dimensionen N, H, W und 16 Elemente entlang C. Die Tensor-Deskriptor-Parameter sind wie folgt gesetzt: tensorSize[0]=64; tensorSize[1]=9; tensorSize[2]=14; tensorSize[4]=64; traversalStride=2; rangeNDHW = 32; rangeC = 16; boxBaseCornerW = -1; boxBaseCornerH = -1; boxFarCornerW = -1; boxFarCornerH = -1. 8B zeigt zum Verarbeiten die Anforderungen mit den Koordinaten (7, 7, 5, 0) und verschiedenen Koordinatenversatzwerten: (0, 0), (1, 1), (2, 2). Beachten Sie, dass in diesem Beispiel Pixel aus der obersten Reihe der BoundingBox geladen werden, nicht aber aus der untersten Reihe. Außerdem werden sie sowohl aus der ersten als auch aus der letzten Spalte geladen.
  • 8G zeigt ein leicht modifiziertes Beispiel, bei dem die Tensorgröße entlang der W- und H-Dimensionen um ein Pixel reduziert ist: NHWC (64x13x8x64). Man beachte, dass in diesem Beispiel Pixel sowohl aus der oberen als auch aus der unteren Reihe der BoundingBox geladen werden. Sie werden jedoch nicht aus der letzten Spalte geladen.
  • Das nächste Beispiel, das in 8H gezeigt wird, zeigt die Handhabung von traversalStride im Kachelmodus. Ein 3x3-Faltungsfilter wird auf einen NHWC-Tensor (64x14x8x64) mit traversalStride gleich zwei angewendet. Ähnlich wie bei früheren Beispielen mit traversalStride gleich eins (8D) kann eine einzige TMAU-Anforderung Pixel für alle Faltungsfilterpositionen bereitstellen, indem zusätzliche Halo-Pixel geladen werden.
  • In einigen Ausführungsbeispielen verfügt die TMAU möglicherweise nicht über dedizierte Hardware für die Handhabung der Faltungsdilatation, und andere TMAU-Schaltkreise können die erforderliche Unterstützung für diese Funktion bereitstellen. Die Präzision der im2col-Koordinaten-Offsets und der Bounding-Box-Eckkoordinaten wird jedoch so gewählt, dass ein breiter Bereich von Faltungs-Kernelgrößen und Dilatationsfaktoren bereitgestellt wird. 8I zeigt, wie der Dilatationsfaktor die Bounding-Box-Einstellungen für den 3x3-Faltungsfilter beeinflusst. Man beachte, dass sich die Dilatation auf die Position der Box auswirkt, nicht aber auf die Größe.
  • 8J zeigt, wie ein Dilatationsfaktor von zwei im im2col-Modus behandelt wird. Ein 3x3-Faltungsfilter wird auf einen NHWC-Tensor (64x14x9x64) angewendet. Bei jeder Anforderung werden 64 Elemente entlang der Dimensionen N, H, W und 16 Elemente entlang der Dimension C geladen. Die Tensor-Parameter sind wie folgt eingestellt: tensorSize[0]=64; tensorSize[1]=9; tensorSize[2]=14; tensorSize[4]=64; rangeNDHW = 64; rangeC = 16; boxBaseCornerW = -2; boxBaseCornerH = -2; boxFarCornerW = -2; boxFarCornerH = -2. 8J zeigt zum Verarbeiten die Anforderungen mit den Koordinaten (7, 6, 3, 0) und verschiedenen Koordinatenversatzwerten: (0, 0), (2, 2), (4, 4).
  • 8K zeigt, wie ein ähnliches Beispiel wie 8J im Kachelmodus behandelt wird. Eine einzige TMAU-Anforderung kann Pixel für alle Faltungsfilterpositionen bereitstellen, indem zusätzliche Halo-Pixel geladen werden. Die Anzahl der Halo-Pixel hängt von der Filtergröße und dem Dilatationsfaktor ab. Ein 3x3-Faltungsfilter wird auf einen NHWC-Tensor (64x14x8x64) angewendet. Eine einzige Anfrage lädt 12x12 Kacheln entlang der Dimensionen H und W und 8 Elemente entlang C. Jede geladene 12x12 Kachel hat 4 Halo-Zeilen und 4 Spalten. Die Tensor-Deskriptor-Parameter werden wie folgt festgelegt: tensorSize[0]=64; tensorSize[1]=8; tensorSize[2]=14; tensorSize[4]=64; boxSize[0] = 8; boxSize[1] = 12; boxSize[2] = 12; boxSize[3] = 1. Für jede gegebene Filterposition wird nur eine 8x8-Kachel für Faltungsberechnungen verwendet. 8K zeigt die Verarbeitungen für die Anforderungen mit den Koordinaten (0, -2, -2, 0). Negative W-, H-Blockkoordinaten werden benötigt, um auf Pixel außerhalb der Tensorgrenze mit Null oder einer Konstante (Auffüllung) zuzugreifen. Es werden 8x8 Kacheln gezeigt, die zum Verarbeiten verschiedener Filterpositionen verwendet werden: (0, 0), (2, 2), (4, 4).
  • Unterstützung für Tensor-Datenverwürfeln (Data Swizzling)
  • In vielen Applikationen lädt die TMAU die Daten in den gemeinsam genutzten Speicher in der gleichen Reihenfolge, in der sie im globalen Speicher angeordnet sind. Es gibt jedoch Anwendungen, bei denen zusätzliche Datenbewegungen erforderlich sind, um eine Degradation der Leistung zu vermeiden. Dies kann als anwendungsabhängige Optimierung implementiert werden. Die TMAU unterstützt einen Modus ohne Verwürfeln, bei dem die Daten in der gleichen Anordnung wie im globalen Speicher in den gemeinsam genutzten Speicher geschrieben werden, und einen Modus mit Verwürfeln, bei dem die Daten gemäß einem vorgegebenen oder konfigurierbaren Verwürfelungs-Muster in den gemeinsam genutzten Speicher geschrieben werden, das zu einer anderen Anordnung der Daten als im globalen Speicher führt. Wenn die TMAU eine Speicherzugriffsanforderung verarbeitet, kann sie mehrere externe Speicheranforderungen generieren, und für jede der generierten externen Speicheranforderungen kann sie eine entsprechende Zieladresse und ein entsprechendes Verwürfelungs-Muster für den gemeinsam genutzten Zielspeicher generieren. In Implementierungen können zwei Optionen für die Verfolgung der Zieladressen und Verwürfelungs-Muster verwendet werden - entweder werden alle Informationen mit der Anfrage und der Antwort durch das Speichersystem gesendet, oder die Informationen werden in einer Verfolgungstabelle im SM gespeichert und der entsprechende Index in dieser Tabelle mit der Anfrage und der Antwort durch das Speichersystem gesendet. In beiden Fällen kann die Antwort des Speichersystems diese Informationen verwenden, um die Adresse und das Muster für das Schreiben der Daten in den gemeinsam genutzten Zielspeicher zu bestimmen.
  • In einigen Ausführungsbeispielen sind die L2-Cache-Zeilen in vier 32B-Sektoren organisiert. Der gemeinsam genutzte Speicher ist in Gruppen von 8 Bänken, insgesamt 4 Gruppen, organisiert. Bei der Zuordnung von vier Sektoren in der Cache-Zeile zu bestimmten Bankgruppen besteht eine gewisse Flexibilität: Jeder Sektor kann jeder Gruppe zugeordnet werden, ein Sektor pro Gruppe. Darüber hinaus können 16B-Sektorhälften innerhalb des Sektors getauscht werden. Dies stellt eine zusätzliche Flexibilität bei der Zuordnung von 16B-Anzahlen zu 4-Bank-Untergruppen bereit.
  • Die Daten sind im globalen Speicher in einer bestimmten Reihenfolge organisiert, die jedoch möglicherweise nicht mit der Reihenfolge übereinstimmt, in der die Applikation auf die Daten im gemeinsam genutzten Speicher zugreift. Ein gutes Beispiel dafür ist die Organisation einer Matrix, bei der die Zeilen zuerst und die Spalten zuerst zugegriffen werden. Dieser Unterschied in der Datenorganisation kann beim Zugriff auf den gemeinsam genutzten Speicher Bankkonflikte veranlassen. Um dieses Problem zu vermeiden, können die Daten in den gemeinsam genutzten Speicher geladen werden, indem sie über die gemeinsam genutzten Speicherbänke hinweg gemischt werden. Die Sektoren der L2-Cache-Zeilen werden den gemeinsam genutzten Speicherbänken und Untergruppen basierend auf vordefinierten Mustern zugeordnet, die die Vermeidung von Bankkonflikten sowohl beim Lesen als auch beim Schreiben gewährleisten. Die TMAU unterstützt mehrere Muster, basierend auf den spezifischen Tensor-Layouts. Der Datenkonsument wiederum muss diese Muster wahrnehmen und entsprechend auf die Daten zugreifen.
  • In einigen Ausführungsbeispielen kann die TMAU-Daten verwürfeln, die in einen gemeinsam genutzten Speicher geladen werden, der in Form von Zeilen organisiert ist. In einem Beispiel ist der gemeinsam genutzte Speicher in Zeilen organisiert, wobei jede Zeile 128B (128 Byte) groß ist und eine eindeutige Adresse hat. Das Verwürfelungs-Muster (Swizzle-Muster) des gemeinsam genutzten Speichers kann in 8x8-Tabellen kodiert werden, wobei jeder Eintrag die Bankuntergruppen-ID für 16B-Unterblöcke innerhalb eines 128B-Datenblocks repräsentiert. Basierend auf den letzten 3 Bits der Adresse des gemeinsam genutzten Speichers (Zeilen-ID) wird die entsprechende Zeile aus der Tabelle ausgewählt. Beachten Sie, dass die Bits von der logischen Adresse innerhalb der gemeinsam genutzten CTA-Speicherregion stammen. Es ist ein Offset von der auf der Region basierenden Adresse. Sie ist nicht notwendigerweise mit der physikalischen Adresse des gemeinsam genutzten Speichers identisch.
  • In 9A ist eine beispielhafte Bankallokationstabelle für einen Verwürfelungs-128B-Modus dargestellt.
  • 9B-9D zeigen ein Beispiel für die Datenallokation in globalen und gemeinsam genutzten Speichern für den Verwürfelungs_128B-Modus gemäß der Bankallokationstabelle von 9A. 9B zeigt einen 4-dimensionalen NHWC-Tensor mit 1x10x10x64 (d.h. N=1, H=10, W=10 und C=64) Dimensionen im globalen Speicher. Mit 2B/Kanal und 64 Kanälen, die 128B belegen. Jede Aufzählungszelle, manchmal auch als Pixel bezeichnet, repräsentiert 8 Kanäle (16B). Die W- und H-Größen eines Bildes 902 betragen jeweils 10 und umfassen Halo-Pixel 906 zur Unterstützung eines 3x3-Faltungsfilters 904 entlang der 8x8-Bildkachel. Zum Verarbeiten wird der Faltungsfilter iterativ um jeweils ein Pixel nach links-rechts und oben-unten verschoben. Die Zellen sind in den 9A-D in der Reihenfolge aufgezählt, in der sie im globalen Speicher abgelegt sind. Die Kanalbereiche werden in verschiedenen Schraffur-Mustern (Hatch-Pattern) präsentiert.
  • 9C zeigt einen Teil des in 9B gezeigten Tensors im globalen Speicher für H=0 und 1. Jede Reihe von Zellen in 9C repräsentiert eine einzelne 128B L2 Cache-Zeile. 9D zeigt, wie dieselben Daten gemäß einem Ausführungsbeispiel im gemeinsam genutzten Speicher gespeichert werden. Jede Zeile repräsentiert 128B an Daten, die über die Speicherbänke verteilt sind. Die Daten werden basierend auf der Tabelle für den Verwürfelungs_128B-Modus verwürfelt. Rechts in 9D ist die Datenansicht aus der Sicht der GMMA-Applikation für die Filterposition R=0, S=-0 dargestellt. Der GMMA muss das Verwürfeln der Bank wahrnehmen und Schritte unternehmen, um die richtigen Daten in 16 8x8-Kacheln einzuspeisen.
  • Das Verwürfeln kommt Implementierungen entgegen, bei denen die Reihenfolge, in der die Daten im globalen Speicher gespeichert werden, nicht mit der Reihenfolge übereinstimmt, in der die Daten im gemeinsam genutzten Speicher gespeichert werden. Wenn die Daten vom globalen Speicher in den gemeinsam genutzten Speicher verschoben werden, stellt die TMAU in einigen Ausführungsbeispielen eine Verwürfelung der Daten bereit, weil der SM bei einigen Applikationen die Daten vertikal (z.B. in Datenspalten) liest. Außerdem berücksichtigt die TMAU beim Schreiben in den gemeinsam genutzten Speicher das Layout der Speicherbank im gemeinsam genutzten Speicher, um den nachfolgenden Lesezugriff des SM auf diese Daten zu optimieren. In dem gezeigten Beispiel ist der gemeinsam genutzte Speicher in Bänken organisiert, und zwar in 8 Bänken. Zu jedem gegebenen Taktsignal wird jede Bank gelesen, wobei jedoch nur ein kleiner Teil der Daten aus jeder gegebenen Bank gelesen werden kann. In den Figuren repräsentiert jedes Verwürfelungs-Muster Daten, die gemäß dem Verwürfeln des Tensors in eine andere Bank des gemeinsam genutzten Speichers geschrieben wurden. Wenn die Daten von H=0 W=0-7 aus dem gemeinsam genutzten Speicher gelesen werden sollen und wenn diese Daten im gemeinsam genutzten Speicher auf die gleiche Weise wie im globalen Speicher angeordnet sind, würde es 8 Taktsignale dauern, diese Daten zu lesen und dabei Bankkonflikte zu vermeiden. Daher werden, wie in 9D auf der linken Seite gezeigt, die Daten von H=0 W=0-7 über alle acht Bänke im gemeinsam genutzten Speicher verteilt, so dass alle diese Daten (d.h. die Daten von H=0 W=0-7) parallel über die 8 Bänke gelesen werden können. Dadurch wird der Datendurchsatz pro Taktsignal erhöht.
  • Auf der rechten Seite von 9D zeigt die Spalte ganz rechts die 8x8 Kacheln für jedes H, wenn W=0, wobei die Pfeile die Stellen im gemeinsam genutzten Speicher angeben, an denen die Kacheln für H=0, W=0 und H=1, W0 (aufgezählte Kacheln 0 bzw. 80) geschrieben werden. In ähnlicher Weise sind in der zweiten Spalte von rechts die 8x8 Kacheln für jedes H bei W=1 dargestellt, wobei die Pfeile die Stellen im gemeinsam genutzten Speicher angeben, an denen die Kacheln für H=0, W=1 und H=1, W=1 (aufgezählte Kacheln 0 bzw. 80) geschrieben werden. Das Verwürfeln wird gemäß einer vorkonfigurierten Tabelle, wie der in 9A gezeigten Tabelle, in der TMAU durchgeführt.
  • In einigen Ausführungsbeispielen ist GMMA eine Hardwareeinheit mit fester Funktion in den GPU-Tensorkernen, die so konfiguriert ist, dass sie eine Matrix-zu-Matrix-Multiplikation in einem Akkumulator durchführt. Zum Beispiel können zwei 16x16-Matrizen durch die GMMA in eine Akkumulationsmatrix multipliziert werden. In einigen Ausführungsbeispielen kann der GMMA auf Matrizen beschränkt sein, die kleiner als eine vordefinierte Größe sind. Wenn zwei Matrizen multipliziert werden sollen, ist der GMMA ein Verbraucher von Daten, die in Ausführungsbeispielen von der TMAU geliefert werden. Wenn in einem Rechenkern, der auf einem SM läuft, eine Matrix-Matrix-Multiplikation erforderlich ist, kann die Kernel-Anforderung die TMAU auffordern, die Daten für jede der beiden Matrizen in den gemeinsam genutzten Speicher zu kopieren, und dann eine Anforderung für eine Matrix-Matrix-Multiplikation an GMMA stellen. GMMA kann daraufhin seine Multiplikation unter Verwendung der Daten durchführen, die von der TMAU in den gemeinsam genutzten Speicher geladen wurden. Wird das Verwürfeln verwendet, kann der Kernel die Daten im gemeinsam genutzten Speicher gemäß den Verwürfelungs-Muster-Informationen lesen, die Berechnung durchführen und dann die Ergebnisse in den gemeinsam genutzten Speicher zurückschreiben. Das Verwürfeln wird gemäß einer vorkonfigurierten Tabelle, wie der in 9A gezeigten Tabelle, in der TMAU durchgeführt.
  • Der GMMA-Schaltkreis kann in einigen Ausführungsbeispielen so konfiguriert sein, dass er Daten aus dem gemeinsam genutzten Speicher in 8x8-Pixel-Kacheln liest, wie auf der rechten Seite von 9D dargestellt. Um die Daten für die Position R=0, S=0 zu erhalten (siehe 9B Indikation von R=0 S=0 im nicht gezischten Bild im globalen Speicher), müssen alle Kanäle 0-63 für die Position R=0 S=0 aus dem gemeinsam genutzten Speicher gelesen werden. Für die erste vom GMMA gelesene 8x8-Pixel-Kachel, wie in der oberen rechten Kachel auf der rechten Seite von 9D dargestellt, werden für die Position R-0 S=0 Pixel für die Kanäle C=0-7 von H=0 W=0-7 gelesen. Da die Daten im gemeinsam genutzten Speicher verwürfelt werden, wie in 9D gezeigt, können alle Kanäle 0-63 für acht Positionen einschließlich R=0, S=0 in acht Taktsignalen gelesen werden.
  • Die GMMA-Operation kann durch einen Faltungs-Kernel über ein Bild 902, wie in 9B gezeigt, aufgerufen werden, der einen 3x3-Faltungsfilter 904 verwendet. Für jede Position, R=0 S=0 usw., verlangt der Filter, dass eine Matrixmultiplikation für die 3x3-Box durchgeführt wird, in der diese Position die obere linke Position ist, wie in 9B unten rechts gezeigt. Die GMMA-Schaltung kann jedoch bei jedem Lesevorgang eine 8x8-Kachel lesen.
  • Multicast-Unterstützung
  • Die TMAU stellt Unterstützung für programmatisches Multicast bereit, bei dem eine einzelne TMAU eine Ladeanforderung generiert, die Daten aber an mehrere Ziele (z.B. SMs) geliefert werden. Beispielsweise fordert die mit dem ersten SM gekoppelte TMAU als Antwort auf eine Ladeanforderung von einem Kernel, der auf einem ersten SM ausgeführt wird, einen Block von Tensor-Daten oder anderen Daten aus dem globalen Speicher an und schreibt diese zusätzlich zum Schreiben in den gemeinsam genutzten Speicher des ersten SM (in einigen Ausführungsbeispielen ist es nicht erforderlich, dass das anfordernde SM die angeforderten Daten empfängt) auch in die gemeinsam genutzten Speicher eines oder mehrerer anderer SMs. Um dies zu unterstützen, wird der anfordernden TMAU eine Liste der empfangenen CTAs bereitgestellt. In einigen Ausführungsbeispielen können die empfangenen CTA-IDs in einer 16-Bit-Maske kodiert werden, wobei jedes Bit einer spezifischen CTA-ID entspricht. In einigen Ausführungsbeispielen initiiert eine Datenanforderung mit Multicast-Option TMAU-Multicast-Anforderungen. Die Maske für die Ziel-CTAs kann in der Zieladresse, die den Anweisungen bereitgestellt wird, kodiert sein.
  • Jeder Empfänger-CTA muss den Abschluss der Transaktion detektieren. Das Detektieren des Abschlusses kann basierend auf einer arrive/wait Synchronisation erfolgen. Zum Beispiel kann jedes empfangene Paket die gemeinsam genutzte Speicheradresse für den entsprechenden Ankunfts-/Warte-Strukturort umfassen, und der Zähler in der Struktur kann gemäß der Anzahl der empfangenen Datenbytes aktualisiert werden. Der Empfänger-CTA kann eine Synchronisation basierend auf einer Barriere oder ähnlichem auf dem Zähler implementieren.
  • Um die Vorkaufsrechte zu unterstützen, verfolgt die TMAU die empfangenen Datenpakete, um den Abschluss der Transaktion zu detektieren. Im typischen Fall wird die gesamte Buchführung lokal innerhalb der TMAU organisiert. Im Multicast-Fall jedoch muss die anfordernde TMAU den Abschluss der Transaktion bei allen Empfängern nachweisen. Daher kann ein zusätzlicher Bestätigungsmechanismus für mehrere TMAUs eingerichtet werden. Jedes Mal, wenn die TMAU die Daten empfängt, muss sie das Ereignis der anfordernden TMAU mitteilen. Die anfragende TMAU berücksichtigt die Gesamtzahl der empfangenen Datenpakete bei allen Empfängern. Ein Beispiel für eine Multicast-Implementierung, die unter Verwendung der TMAU implementiert werden kann, ist in der U.S. Application No. 17/691,288 mit dem Titel „Programmatically Controlled Data Multicasting Across Multiple Compute Engines“ beschrieben, die hiermit in vollem Umfang in den Text aufgenommen wird.
  • Vorladungs- (Prefetch-) Unterstützung
  • Zusätzlich zum Laden von Tensor-Daten unterstützt die TMAU Daten-Prefetch-Anfragen, um Daten aus dem globalen DRAM-Speicher in den L2-Cache vorzuladen. Dies stellt eine Möglichkeit bereit, die Latenzzeit beim Laden des Tensors zu verringern und die Gesamtleistung zu verbessern. Das Vorladen kann insbesondere bei Multicast-Operationen von Vorteil sein, bei denen die Latenz die Ausführung mehrerer CTAs beeinträchtigt. Die Handhabung von Prefetch-Anfragen ist ähnlich wie bei anderen Ladevorgängen, jedoch ohne dass die TMAU irgendeinen Typ von Abschlussverfolgung oder Ähnlichem durchführen muss. Bei Tensor-Daten ähnelt die Handhabung von Prefetch-Anforderungen in gewisser Weise dem Ladevorgang, bei dem Tensor-Deskriptor und Koordinaten festlegen, wie die Anforderung zu verarbeiten ist. In Bezug auf Vorladeanfragen für Tensor-Daten kann die TMAU jedoch nicht mit gemeinsam genutztem Speicher/globalen Alignment umgehen und Anfragen auf Sektor- oder Cache-Zeilen-Granularität verarbeiten.
  • Speicher- und Reduktionsanfragen
  • Die TMAU-Speicheranforderung kopiert einen Datenblock aus dem gemeinsam genutzten Speicher in den globalen Speicher. Die Daten im gemeinsam genutzten Speicher werden sequentiell als linearer Adressraum verarbeitet; der Zielspeicher wird jedoch als multidimensionaler Tensor behandelt. Die maximale Dimensionalität ist dieselbe wie bei Ladeanforderungen.
  • Wie bei den TMAU-Ladeanforderungen werden den TMAU-Speicheranforderungen der Tensor-Deskriptor-Zeiger, die Basisadresse des gemeinsam genutzten Speichers und die Koordinaten des Zielblocks im Tensorraum bereitgestellt. Die Speicheranforderungen können sowohl im Kachelmodus als auch im2col-Modus ausgeführt werden. Die Speicheranforderungen können auch ineinander verschachtelte Layouts unterstützen und gemeinsam genutzte Speicherbank-Verwürfelungs-Muster können spezifiziert werden. Die Speicherung mit Traversalschritt kann unterstützt werden. In einigen Ausführungsbeispielen kann der Speichervorgang auch die Behandlung der Out-of-Bounds-Bedingungen mit ZFILL/CFILL unterstützen. Darüber hinaus unterstützt die TMAU in bestimmten Ausführungsbeispielen das Speichern mit Reduktion für das Kopieren von Daten von gemeinsam genutzten zu globalen oder gemeinsam genutzten zu gemeinsam genutzten Speichern. Die unterstützten Reduktionsoperationen können unter anderem AND, ADD, XOR, MIN, MAX, DEC, OR und INC umfassen.
  • Deskriptorlose Anfragen
  • Eine Vielzahl von Applikationen führt Speicher-zu-Speicher-Transaktionen durch, die keine Kenntnis der zugrunde liegenden Datenlayouts erfordern. In diesem Fall werden die Daten als sequentielles Array von Blöcken mit einer vorgegebenen Größe behandelt. In einigen Ausführungsbeispielen kann für TMAU-Operationen zum Beispiel eine Standardblockgröße von 16B konfiguriert werden. Die Speicherzugriffsanforderung für einen Nicht-Tensor-Datenblock ist wesentlich einfacher als eine Anforderung für einen Tensor und erfordert in einigen Ausführungsbeispielen nur eine Quelladresse, eine Zieladresse und die Anzahl der Blöcke, um das Transferieren durchzuführen. Alle diese Parameter können auf der Anweisungsebene spezifiziert werden (d. h. in der Anforderung an die TMAU bereitgestellt werden), ohne dass ein assoziierter Tensor-Deskriptor im globalen Speicher gespeichert werden muss. Dies vereinfacht das Programmiermodell, da der Schritt der Tensor-Deskriptor-Definition für solche Speicherzugriffsanforderungen entfallen kann. Ist die Anzahl der zu transferierenden Blöcke gleich Null, werden diese Anweisungen wie eine Null-Operation (NOP) behandelt.
  • Die TMAU unterstützt spezielle Anweisungen für deskriptorlose Datentransfers (auch als Nicht-Tensor-Daten-Anforderungen bezeichnet). Solche Anweisungen können verwendet werden, um Daten von global zu gemeinsam genutzten, von gemeinsam genutzten zu globalen und von gemeinsam genutzten zu gemeinsam genutzten Speichern zu kopieren. In einem anderen Ausführungsbeispiel kann das Kopieren von global zu global implementiert werden. Eine weitere Anweisung führt eine Reduktion mit Datenkopie von gemeinsam genutzten zu globalen oder gemeinsam genutzten zu gemeinsam genutzten Speichern durch. Die unterstützten Reduktionsoperationen umfassen u. a. AND, ADD, XOR, MIN, MAX, DEC, OR und INC. Die TMAU unterstützt deskriptorlose Datenvorladeanfragen von DRAM zu L2.
  • Synchronisation und Transaktionsabschluss
  • Die TMAU unterstützt ein Ereignis zum Abschluss einer Anforderung. In einigen Ausführungsbeispielen wird eine Ankunfts-/Warteschranke als Mechanismus zum Erkennen des Abschlusses verwendet. Jede TMAU-Ladeanforderung erwartet eine gemeinsam genutzte Speicheradresse, an der sich die Barrierenstruktur befindet. Die TMAU umfasst diese Adresse in jeder L2-Anforderung. Wenn die Daten im Ziel-SM ankommen, wird die Barrierestruktur entsprechend aktualisiert. Die TMAU selbst ist an der Aktualisierung der Barriere nicht beteiligt. Dieser Mechanismus kann sowohl für Unicast- als auch für Multicast-Anfragen verwendet werden.
  • Darüber hinaus unterstützt die TMAU eine spezielle Anweisung, die dazu verwendet werden kann, den Abschluss aller zuvor ausgegebenen TMAU-Anfragen zu detektieren.
  • Programmiermodell für die TMAU
  • Die TMAU ist dafür ausgelegt, große Blöcke von Tensor-Daten oder anderen Daten zwischen globalen und gemeinsam genutzten Speichern zu verschieben. Eine einzige TMAU-Ladeanforderung kann Kilobytes, Megabytes oder noch größere Datenmengen bringen, die von mehreren Threads und CTAs verarbeitet werden könnten. Ebenso könnten große Blöcke gemeinsam genutzter Speicherdaten, die von einem großen Thread Array generiert werden, durch eine einzige TMAU-Speicheroperation im globalen Speicher in Tensor- oder anderer Form gespeichert werden.
  • Die skalare Natur von TMAU-Anfragen ist nicht gut mit der multi-threaded Natur des CUDA Programmierparadigmas aligniert. Daher stellen einige Ausführungsbeispiele ein intuitives und nicht-unterbrechendes Programmiermodell bereit, das in die CUDA-Umgebung integriert werden kann, um die Nutzung der TMAU in Applikationen bereitzustellen. Das Programmiermodell stellt Flexibilität für die Programmentwicklung bereit und ist für die Entwickler von Applikationen intuitiv und leicht zu erlernen.
  • In der typischen DL-Applikation wird erwartet, dass die TMAU in einer iterativen Weise verwendet wird. Mehrere CTAs iterieren durch die im globalen Speicher gespeicherten Tensoren, indem sie auf verschiedene Kacheln zugreifen. In jeder Iteration werden Tensorblöcke (Kacheln) extrahiert und zum Verarbeiten verwendet. Für jeden Block bestimmt die Applikation die Lage des Blocks im Tensorraum durch Berechnen der mehrdimensionalen Koordinaten. Darüber hinaus muss die Applikation gemeinsam genutzte Speicheradressen berechnen, die zur Speicherung der Blöcke verwendet werden.
  • Die skalare Natur der TMAU-Anweisungen macht Uniform Data Path (UDP) und Uniform Register File (URF) zu einem effizienten Ausführungsort. Dies gilt nicht nur für die TMAU-Anweisungen, sondern auch für den sie umgebenden Code, der die notwendigen Parameter für die Anweisungen generiert. Dieser Ansatz würde Redundanzen bei der Codeausführung beseitigen, HF-Kapazität und Bandbreite einsparen, Strom sparen und den Pfad für Vektordaten freigeben. Aufgrund der iterativen Natur des TMAU-bezogenen Codes ist es wichtig, dass die iterierten Parameter in URF verbleiben. Jedes Laden/Speichern von URF/RF würde Leistungsverluste und zusätzlichen Stromverbrauch veranlassen.
  • In einigen Ausführungsbeispielen wird ein Mechanismus bereitgestellt, der den Compiler bei der Erkennung der Warp-Single-Semantik der nahegelegenen Code-Blöcke unterstützt und durch CUDA und PTX (Parallel Thread Execution instruction set architecture) ausgedrückt werden kann. Eine Modifizierung fügt den Modifikator „.one” hinzu. Im folgenden Code erzwingt der vorgeschlagene Modifikator, dass ein einzelner Thread für die Ausführung ausgewählt wird:
         _warpsync.exclusive.one mask, L1;
            <Codeblock ausgeführt von einem einzelnen Thread>
  • Der Ausführungs-Thread wird aus dem Satz aktiver Threads ausgewählt, der durch die Maske definiert ist. Es ist wichtig, dass bei jeder Ausführung des Code-Blocks stets derselbe Thread ausgewählt wird. Man beachte, dass _warpsync.exclusive eine Synchronisation aller Threads vor und nach der Ausführung des Code-Blocks veranlasst. Das vorgeschlagene Programmiermodell kann Code-Analysen vereinfachen und stellt die Möglichkeit bereit, TMAU-bezogenen Code für die UDP-Ausführung zu generieren und relevante Daten in URF zu halten.
  • Das Modell auf CUDA-Ebene basiert auf der PTX-Struktur, in der der einzelne Thread konsequent für die Code-Block-Ausführung ausgewählt wird. Im folgenden Code stellt die Funktion _one_sync(mask) die wünschenswerte Funktionalität bereit:
    •          if (_one_sync(mask)) {
            <Codeblock ausgeführt von einem einzelnen Thread>
         } // keine 'else'-Klausel
  • Der auf TMAU basierende Zugriff wird in einigen Ausführungsbeispielen durch einen Satz von Funktionen implementiert. Es werden vier C-Gruppen definiert, um die folgenden Fälle abzudecken: Tiled Load mit L2-Deskriptor, Tiled Load ohne Tensor-Deskriptor, im2col Load mit Tensor-Deskriptor und im2col Load ohne Tensor-Deskriptor. Die Funktionen können als Eingabeparameter Tensor-Deskriptor-Zeiger, gemeinsam genutzte Speicher-Zieladresse, gemeinsam genutzte Speicheradresse für Ankunfts-/Warteschranke, Satz von Tensor-Koordinaten für den Zugriffs-Block-Ursprung, Pipeline-Struktur und optional Tensor-Deskriptor annehmen. Die im2col-Gruppe erwartet auch Koordinaten-Offsets innerhalb des Faltungs-Kernels.
  • In einem Ausführungsbeispiel kann ein Kernel, der auf dem SM ausgeführt wird, eine Speicherzugriffsanfrage an die TMAU stellen, um einen Tensor zwischen globalen und gemeinsam genutzten Speichern zu kopieren, und zwar mit der Anweisung tensor copy in einer Form wie:
    •  copy _tensor.mode,dimensionality.destination,source{.multicast} {reduction_op}
   Deskriptorkoordinaten SMEM_data _address {SMEM_barrier _addr}
   {im2col_coordinate_offsets} multicast_destinations
    wobei mode = {tiles, im2col}, dimensionality = {1D-5D}, destination = {shared, global}, source = {shared, global}. Multicast, reduction_op= {.AND, .ADD, .XOR, .MIN, .MAX, DEC, .OR, .INC}.
  • Eine Speicherzugriffsanforderung an die TMAU zum Vorladen von Tensor-Daten in den L2-Cache kann mit einer Tensor-Prefetch-Anweisung in einer Form wie folgt ausgegeben werden:
    •  prefetch_tensor.mode.dimensionality descriptor coordinates
   im2col_coordinate_offsets}
    wobei Modus = {Kacheln, im2col} und Dimensionalität = {1D-5D}.
  • Eine Speicherzugriffsanforderung an die TMAU zum Kopieren eines Blocks von Nicht-Tensor-Daten zwischen dem globalen und dem gemeinsam genutzten Speicher kann mit einer Blockkopieranweisung in einer Form wie folgt ausgegeben werden:
    • copy_block.destination,source{.multicast} {reduction_op} destination_address {barrier_addr} source _address multicast_destinations number_blocks
    • wobei Ziel = {gemeinsam genutzt, global}, Quelle = {gemeinsam genutzt, global}, Multicast, und
    • reduction_op= {.AND, ADD, XOR, MIN, MAX, DEC, OR, .INC}.
  • Eine Speicherzugriffsanforderung an die TMAU, um einen Block von Nicht-Tensor-Daten aus dem globalen Speicher in den L2-Cache vorzuladen, kann mit einer Block-Prefetch-Anweisung in einer Form wie folgt ausgegeben werden:
    • prefetch_block address number_blocks.
    • Beispielhafte GPU-Architektur für parallele Verarbeitung mit TMAU
  • Es wird nun eine beispielhafte Architektur beschrieben, in die die in dieser Applikation offenbarte TMAU integriert ist. Die folgenden Informationen werden zur Veranschaulichung gezeigt und sollten in keiner Weise als Einschränkung verstanden werden. Jedes der folgenden Merkmale kann optional mit oder ohne den Ausschluss anderer beschriebener Merkmale einbezogen werden.
  • 10 zeigt eine Parallelverarbeitungseinheit (PPU) 1000, gemäß einem Ausführungsbeispiel. In einem Ausführungsbeispiel ist die PPU 1000 ein Multi-Thread-Prozessor, der auf einem oder mehreren Geräten mit integrierter Schaltung implementiert ist. Bei der PPU 1000 handelt es sich um eine latenzverbergende Architektur, die für die parallele Verarbeitung vieler Threads ausgelegt ist. Ein Thread (z.B. ein Ausführungsstrang) ist eine Instanziierung eines Satzes von Anweisungen, die zur Ausführung durch die PPU 1000 konfiguriert sind. In einem Ausführungsbeispiel ist die PPU 1000 eine Graphikverarbeitungs-Pipeline (GPU), die so konfiguriert ist, dass sie eine Graphikverarbeitungs-Pipeline zum Verarbeiten von dreidimensionalen (3D) Graphikdaten implementiert, um zweidimensionale (2D) Bilddaten zur Anzeige auf einem Anzeigegerät, wie z. B. einem Flüssigkristallanzeigegerät (LCD), zu generieren. In anderen Ausführungsbeispielen kann die PPU 1000 für die Durchführung allgemeiner Berechnungen verwendet werden. In einigen anderen Ausführungsbeispielen ist die PPU 100 so konfiguriert, dass sie große neuronale Netzwerke in Deep-Learning-Anwendungen oder anderen Hochleistungsrechnern implementiert.
  • Eine oder mehrere PPUs 1000 können so konfiguriert werden, dass sie Tausende von High Performance Computing (HPC)-, Datenzentrum- und Machine Learning-Anwendungen beschleunigen. Die PPU 1000 kann so konfiguriert werden, dass sie zahlreiche Deep-Learning-Systeme und -Applikationen beschleunigt, darunter autonome Fahrzeugplattformen, Deep Learning, hochpräzise Sprach-, Bild- und Texterkennungssysteme, intelligente Videoanalyse, Molekularsimulationen, Arzneimittelentdeckung, Krankheitsdiagnose, Wettervorhersage, Big-Data-Analyse, Astronomie, Molekulardynamiksimulation, Finanzmodellierung, Robotik, Fabrikautomatisierung, Echtzeit-Sprachübersetzung, Online-Suchoptimierung und personalisierte Benutzerempfehlungen und dergleichen.
  • Wie in 10 gezeigt, umfasst die PPU 1000 eine Eingabe/Ausgabe-Einheit (E/A) 1005, eine Front-End-Einheit 1015, eine Scheduler-Einheit 1020, eine Arbeitsverteilungseinheit 1025, einen Hub 1030, eine Crossbar (Xbar) 1070, einen oder mehrere allgemeine Verarbeitungscluster (GPCs) 1050 und eine oder mehrere Partitionseinheiten 1080. Die PPU 1000 kann mit einem Host-Prozessor oder anderen PPUs 1000 über eine oder mehrere Hochgeschwindigkeits-NVLink 1010 Verbindungen verbunden sein. Die PPU 1000 kann mit einem Host-Prozessor oder anderen peripheren Geräten über eine Verbindung 1002 verbunden sein. Die PPU 1000 kann auch mit einem Speicher verbunden sein, der eine Reihe von Speichergeräten 1004 umfasst. In einem Ausführungsbeispiel kann der Speicher 1004 eine Anzahl von Dynamic Random Access Memory (DRAM)-Geräten umfassen. Die DRAM-Geräte können als HBM-Subsystem (High-Bandwidth Memory) konfiguriert werden, wobei mehrere DRAM-Chips in jedem Gerät gestapelt sind.
  • Die NVLink 1010 Verbindung ermöglicht es, Systeme zu skalieren und eine oder mehrere PPUs 1000 in Kombination mit einer oder mehreren CPUs zu umfassen, unterstützt die Cache-Kohärenz zwischen den PPUs 1000 und den CPUs sowie das CPU-Mastering. Daten und/oder Befehle können über den NVLink 1010 durch den Hub 1030 zu/von anderen Einheiten der PPU 1000 übertragen werden, wie z. B. einer oder mehreren Kopier-Engines, einem Video-Encoder, einem Video-Decoder, einer Energieverwaltungseinheit usw. (nicht explizit dargestellt). Der NVLink 1010 wird detaillierter in Verbindung mit 13A und 13B beschrieben.
  • Die E/A-Einheit 1005 ist so konfiguriert, dass sie Kommunikationen (z.B. Befehle, Daten usw.) von einem Host-Prozessor (nicht gezeigt) über die Verbindung 1002 überträgt und empfängt. Die E/A-Einheit 1005 kann mit dem Host-Prozessor direkt über die Verbindung 1002 oder über ein oder mehrere zwischengeschaltete Geräte wie eine Speicherbrücke kommunizieren. In einem Ausführungsbeispiel kann die E/A-Einheit 1005 über die Verbindung 1002 mit einem oder mehreren anderen Prozessoren, wie einer oder mehreren der PPUs 1000, kommunizieren. In einem Ausführungsbeispiel implementiert die E/A-Einheit 1005 eine Peripheral Component Interconnect Express (PCIe)-Schnittstelle für die Kommunikation über einen PCIe-Bus und die Verbindung 1002 ist ein PCIe-Bus. In alternativen Ausführungsbeispielen kann die E/A-Einheit 1005 andere Typen bekannter Schnittstellen für die Kommunikation mit externen Geräten implementieren.
  • Die E/A-Einheit 1005 dekodiert Pakete, die über die Verbindung 1002 empfangen werden. In einem Ausführungsbeispiel repräsentieren die Pakete Befehle, die konfiguriert sind, um die PPU 1000 zu veranlassen, verschiedene Operationen durchzuführen. Die E/A-Einheit 1005 überträgt die dekodierten Befehle an verschiedene andere Einheiten der PPU 1000, wie die Befehle spezifizieren können. So können beispielsweise einige Befehle an die Front-End-Einheit 1015 übertragen werden. Andere Befehle können an den Hub 1030 oder andere Einheiten der PPU 1000 übertragen werden, z. B. eine oder mehrere Kopier-Engines, einen Video-Encoder, einen Video-Decoder, eine Einheit zur Verwaltung der Stromversorgung usw. (nicht explizit dargestellt). Mit anderen Worten, die E/A-Einheit 1005 ist so konfiguriert, dass sie die Kommunikation zwischen und unter den verschiedenen logischen Einheiten der PPU 1000 routet.
  • In einem Ausführungsbeispiel kodiert ein vom Host-Prozessor ausgeführtes Programm einen Befehlsstream in einem Puffer, der der PPU 1000 Arbeitslasten zum Verarbeiten bereitstellt. Eine Arbeitslast kann mehrere Anweisungen und Daten umfassen, die von diesen Anweisungen zu verarbeiten sind. Der Puffer ist ein Bereich in einem Speicher, auf den sowohl der Host-Prozessor als auch die PPU 1000 zugreifen (z.B. lesen/schreiben) können. Beispielsweise kann die E/A-Einheit 1005 so konfiguriert sein, dass sie über Speicheranforderungen, die über die Verbindung 1002 übertragen werden, auf den Puffer in einem mit der Verbindung 1002 verbundenen Systemspeicher zugreift. In einem Ausführungsbeispiel schreibt der Hostprozessor den Befehlsstream in den Puffer und überträgt dann einen Zeiger auf den Anfang des Befehlsstreams an die PPU 1000. Die Front-End-Einheit 1015 empfängt Zeiger auf einen oder mehrere Command Streams. Die Frontend-Einheit 1015 verwaltet den einen oder die mehreren Streams, liest Befehle aus den Streams und leitet Befehle an die verschiedenen Einheiten der PPU 1000 weiter.
  • Die Front-End-Einheit 1015 ist mit einer Scheduler-Einheit 1020 gekoppelt, die die verschiedenen GPCs 1050 zum Verarbeiten von Aufgaben konfiguriert, die durch den einen oder die mehreren Streams definiert sind. Die Scheduler-Einheit 1020 ist so konfiguriert, dass sie Zustandsinformationen in Bezug auf die verschiedenen von der Scheduler-Einheit 1020 verwalteten Aufgaben verfolgt. Der Zustand kann indizieren, welchem GPC 1050 eine Aufgabe zugewiesen ist, ob die Aufgabe aktiv oder inaktiv ist, welche Prioritätsstufe der Aufgabe assoziiert ist, und so weiter. Die Scheduler-Einheit 1020 verwaltet die Ausführung einer Vielzahl von Aufgaben auf dem einen oder mehreren GPCs 1050.
  • Die Scheduler-Einheit 1020 ist mit einer Sendeeinheit 1025 gekoppelt, die konfiguriert ist, um Aufgaben zur Ausführung auf den GPCs 1050 zu verteilen. Die Arbeitsverteilungseinheit 1025 kann eine Anzahl von geplanten Aufgaben verfolgen, die von der Scheduler-Einheit 1020 empfangen wurden. In einem Ausführungsbeispiel verwaltet die Distributionseinheit 1025 einen Pool ausstehender Aufgaben und einen Pool aktiver Aufgaben für jeden der GPCs 1050. Der Pool ausstehender Aufgaben kann eine Anzahl von Slots (z.B. 32 Slots) umfassen, die Aufgaben enthalten, die einem bestimmten GPC 1050 zum Verarbeiten zugewiesen sind. Der aktive Aufgabenpool kann eine Reihe von Slots (z.B. 4 Slots) für Aufgaben umfassen, die von den GPCs 1050 aktiv bearbeitet werden. Wenn ein GPC 1050 die Ausführung einer Aufgabe beendet, wird diese Aufgabe aus dem Pool aktiver Aufgaben für den GPC 1050 entfernt und eine der anderen Aufgaben aus dem Pool ausstehender Aufgaben ausgewählt und zur Ausführung auf dem GPC 1050 eingeplant. Wenn eine aktive Aufgabe auf dem GPC 1050 im Leerlauf war, z.B. während des Wartens auf die Auflösung einer Datenabhängigkeit, dann kann die aktive Aufgabe aus dem GPC 1050 entfernt und in den Pool ausstehender Aufgaben zurückgeführt werden, während eine andere Aufgabe aus dem Pool ausstehender Aufgaben ausgewählt und zur Ausführung auf dem GPC 1050 eingeplant wird.
  • Die Distributionseinheit 1025 kommuniziert mit dem einen oder mehreren GPCs 1050 über die XBar 370. Die XBar 1070 ist ein Verbindungsnetzwerk, das viele der Einheiten der PPU 1000 mit anderen Einheiten der PPU 1000 koppelt. Beispielsweise kann die XBar 1070 so konfiguriert sein, dass sie die Distributionseinheit 1025 mit einem bestimmten GPC 1050 koppelt. Obwohl nicht explizit dargestellt, können auch eine oder mehrere andere Einheiten der PPU 1000 über den Hub 1030 mit der XBar 1070 verbunden sein.
  • Die Aufgaben werden von der Scheduler-Einheit 1020 verwaltet und von der Distributionseinheit 1025 an einen GPC 1050 verteilt. Der GPC 1050 ist so konfiguriert, dass er die Aufgabe verarbeitet und Ergebnisse generiert. Die Ergebnisse können von anderen Aufgaben innerhalb des GPC 1050 verbraucht, über die XBar 1070 an einen anderen GPC 1050 geroutet oder im Speicher 1004 abgelegt werden. Die Ergebnisse können über die Partitionseinheiten 1080 in den Speicher 1004 geschrieben werden, die eine Speicherschnittstelle zum Lesen und Schreiben von Daten in/aus dem Speicher 1004 implementieren. Die Ergebnisse können über den NVLink 1010 an eine andere PPU 1004 oder CPU übertragen werden. In einem Ausführungsbeispiel umfasst die PPU 1000 eine Anzahl U von Partitionseinheiten 1080, die der Anzahl von separaten und unterschiedlichen Speichergeräten 1004 entspricht, die mit der PPU 1000 gekoppelt sind. Eine Partitionseinheit 1080 wird im Folgenden in Verbindung mit 11B detaillierter beschrieben.
  • In einem Ausführungsbeispiel führt ein Hostprozessor einen Treiberkernel aus, der eine Anwendungsprogrammierschnittstelle (API) implementiert, die es einer oder mehreren auf dem Hostprozessor ausgeführten Applikationen ermöglicht, Operationen zur Ausführung auf der PPU 1000 zu planen. In einem Ausführungsbeispiel werden mehrere Rechenanwendungen gleichzeitig von der PPU 1000 ausgeführt, und die PPU 1000 stellt Isolierung, Dienstgüte (QoS) und unabhängige Adressräume für die mehreren Rechenanwendungen bereit. Eine Applikation kann Anweisungen (z.B. API-Aufrufe) generieren, die den Kernel des Treibers veranlassen, eine oder mehrere Aufgaben zur Ausführung durch die PPU 1000 zu generieren. Der Treiberkernel gibt Aufgaben an einen oder mehrere Streams aus, die von der PPU 1000 verarbeitet werden. Jede Aufgabe kann eine oder mehrere Gruppen von zusammenhängenden Threads umfassen, die hier als Warp bezeichnet werden. In einem Ausführungsbeispiel umfasst ein Warp 32 zusammengehörige Threads, die parallel ausgeführt werden können. Kooperierende Threads können sich auf eine Vielzahl von Threads beziehen, die Anweisungen zur Durchführung der Aufgabe umfassen und Daten über gemeinsam genutzte Speicher austauschen können. Threads, kooperierende Threads und eine hierarchische Gruppierung von Threads wie kooperierende Thread Arrays (CTA) und Cooperative Group Arrays (CGA) gemäß einigen Ausführungsbeispielen werden detaillierter in der am 10. März 2022 eingereichten US-Applikation Nr. 17/691,621 mit dem Titel „Cooperative Group Arrays“ beschrieben, deren gesamter Inhalt hiermit durch Bezugnahme in seiner Gesamtheit aufgenommen wird.
  • 11A zeigt einen GPC 1050 der PPU 1000 von 10, gemäß einem Ausführungsbeispiel. Wie in 11A gezeigt, umfasst jeder GPC 1050 eine Anzahl von Hardwareeinheiten zum Verarbeiten von Aufgaben. In einem Ausführungsbeispiel umfasst jeder GPC 1050 einen Pipeline-Verwalter 1110, eine Pre-Rasteroperationseinheit (PROP) 1115, eine Raster-Engine 1125, eine Work Distribution Crossbar (WDX) 1180, eine Memory Management Unit (MMU) 1190 und einen oder mehrere Data Processing Clusters (DPCs) 1120. Der GPC 1050 von 11 A kann anstelle der in 11A gezeigten Einheiten oder zusätzlich zu diesen andere Hardwareeinheiten umfassen.
  • In einem Ausführungsbeispiel wird der Betrieb des GPC 1050 durch den Pipeline-Verwalter 1110 gesteuert. Der Pipeline-Verwalter 1110 verwaltet die Konfiguration des einen oder der mehreren DPCs 1120 zum Verarbeiten von Aufgaben, die dem GPC 1050 allokiert sind. In einem Ausführungsbeispiel kann der Pipeline-Verwalter 1110 zumindest einen der einen oder mehreren DPCs 1120 konfigurieren, um zumindest einen Teil einer Grafik-Rendering-Pipeline, eines neuronalen Netzwerks und/oder einer Rechen-Pipeline zu implementieren. In Bezug auf eine Grafik-Rendering-Pipeline kann ein DPC 1120 beispielsweise konfiguriert sein, um ein Vertex-Shader-Programm auf dem programmierbaren Streaming-Multiprozessor (SM) 1140 auszuführen. Der Pipeline-Verwalter 1110 kann auch so konfiguriert sein, dass er die von der Distributionseinheit 1025 empfangenen Pakete an die entsprechenden logischen Einheiten innerhalb des GPC 1050 routet. Zum Beispiel können einige Pakete zu Hardware-Einheiten mit fester Funktion im PROP 1115 und/oder der Raster-Engine 1125 geroutet werden, während andere Pakete zu den DPCs 1120 zum Verarbeiten durch die Primitiv-Engine 1135 oder den SM 1140 geroutet werden können.
  • Die PROP-Einheit 1115 ist so konfiguriert, dass sie die von der Raster-Engine 1125 und den DPCs 1120 generierten Daten an eine Rasteroperationseinheit (ROP) routet, die in Verbindung mit 11B detaillierter beschrieben wird. Die PROP-Einheit 1115 kann auch so konfiguriert sein, dass sie Optimierungen für die Farbmischung durchführt, Pixeldaten organisiert, Adressübersetzungen vornimmt und dergleichen.
  • Jeder im GPC 1050 enthaltene DPC 1120 umfasst einen M-Pipe-Controller (MPC) 1130, eine Primitiv-Engine 1135 und einen oder mehrere SMs 1140. Der MPC 1130 steuert den operativen Betrieb des DPC 1120 und routet die vom Pipeline-Verwalter 1110 empfangenen Pakete an die entsprechenden Einheiten im DPC 1120. Zum Beispiel können Pakete, die mit einem Vertex assoziiert sind, an die Primitiv-Engine 1135 geroutet werden, die so konfiguriert ist, dass sie mit dem Vertex assoziierte Vertex-Attribute aus dem Speicher 1004 abruft. Im Gegensatz dazu können Pakete, die mit einem Shader-Programm assoziiert sind, an den SM 1140 übertragen werden.
  • Der SM 1140 umfasst einen programmierbaren Streaming-Prozessor, der zur Verarbeitung von Aufgaben konfiguriert ist, die durch eine Anzahl von Threads repräsentiert werden. Jeder SM 1140 ist multi-threaded und konfiguriert, um eine Vielzahl von Threads (z.B. 32 Threads) aus einer bestimmten Gruppe von Threads gleichzeitig auszuführen. In einem Ausführungsbeispiel implementiert der SM 1140 eine SIMD-Architektur (Single-Instruction, Multiple-Data), bei der jeder Thread in einer Gruppe von Threads (z.B. ein Warp) so konfiguriert ist, dass er basierend auf demselben Satz von Anweisungen einen anderen Satz von Daten verarbeitet. Alle Threads in der Gruppe von Threads führen die gleichen Anweisungen aus. In einem anderen Ausführungsbeispiel implementiert der SM 1140 eine SIMT-Architektur (Single-Instruction, Multiple Thread), bei der jeder Thread in einer Gruppe von Threads so konfiguriert ist, dass er basierend auf demselben Satz von Anweisungen einen anderen Satz von Daten verarbeitet, wobei jedoch einzelne Threads in der Gruppe von Threads während der Ausführung divergieren dürfen. In einem Ausführungsbeispiel werden ein Programmzähler, ein Aufrufstapel und ein Ausführungsstatus für jeden Warp erhalten, was die Gleichzeitigkeit zwischen Warps und die serielle Ausführung innerhalb von Warps ermöglicht, wenn Threads innerhalb des Warps divergieren. In einem anderen Ausführungsbeispiel werden ein Programmzähler, ein Aufrufstapel und ein Ausführungsstatus für jeden individuellen Thread erhalten, was die Gleichzeitigkeit zwischen allen Threads innerhalb und zwischen Warps ermöglicht. Wenn der Ausführungsstatus für jeden individuellen Thread erhalten bleibt, können Threads, die dieselben Anweisungen ausführen, zusammengeführt und parallel ausgeführt werden, um maximale Effizienz zu erzielen. Der SM 1140 wird im Folgenden in Verbindung mit 12A detaillierter beschrieben.
  • Die MMU 1190 stellt eine Schnittstelle zwischen dem GPC 1050 und der Partitionseinheit 1080 bereit. Die MMU 1190 kann die Übersetzung von virtuellen Adressen in physikalische Adressen, den Speicherschutz und die Arbitrierung von Speicheranforderungen bereitstellen. In einem Ausführungsbeispiel stellt die MMU 1190 einen oder mehrere Übersetzungs-Lookaside-Puffer (TLBs) bereit, um die Übersetzung von virtuellen Adressen in physikalische Adressen im Speicher 1004 durchzuführen.
  • 11B zeigt eine Speicherpartitionseinheit 1080 der PPU 1000 von 10 gemäß einem Ausführungsbeispiel. Wie in 11B gezeigt, umfasst die Speicherpartitionseinheit 1080 eine Rasteroperationseinheit (ROP) 1150, einen Level-Zwei-Cache (L2) 1160 und eine Speicherschnittstelle 1170. Die Speicherschnittstelle 1170 ist mit dem Speicher 1004 gekoppelt. Die Speicherschnittstelle 1170 kann 32-, 64-, 128-, 1024-Bit-Datenbusse oder ähnliches für das Hochgeschwindigkeits-Transferieren von Daten implementieren. In einem Ausführungsbeispiel verfügt die PPU 1000 über U Speicherschnittstellen 1170, eine Speicherschnittstelle 1170 pro Paar Partitionseinheiten 1080, wobei jedes Paar Partitionseinheiten 1080 mit einem entsprechenden Speichergerät 1004 verbunden ist. Beispielsweise kann die PPU 1000 mit bis zu Y Speichergeräten 1004 verbunden sein, wie z. B. Speicherstapeln mit hoher Bandbreite oder Grafikspeicher mit doppelter Datenrate, Version 5, synchronem Dynamic Random Access Memory oder anderen Typen von dauerhaftem Speicher.
  • In einem Ausführungsbeispiel implementiert die Speicherschnittstelle 1170 eine HBM2-Speicherschnittstelle, und Y entspricht der Hälfte von U. In einem Ausführungsbeispiel befinden sich die HBM2-Speicherstapel auf demselben physischen Gehäuse wie die PPU 1000, was erhebliche Energie- und Flächeneinsparungen im Vergleich zu herkömmlichen GDDR5-SDRAM-Systemen bereitstellt. In einem Ausführungsbeispiel umfasst jeder HBM2-Stapel vier Speicherchips und Y ist gleich 4, wobei der HBM2-Stapel zwei 128-Bit-Kanäle pro Chip für insgesamt 8 Kanäle und eine Datenbusbreite von 1024 Bit umfasst.
  • In einem Ausführungsbeispiel unterstützt der Speicher 1004 den Single-Error Correcting Double-Error Detecting (SECDED) Error Correction Code (ECC), um Daten zu schützen. ECC stellt eine höhere Zuverlässigkeit für Rechen-Applikationen bereit, die sensibel auf Datenbeschädigung reagieren. Zuverlässigkeit ist besonders wichtig in großen Cluster-Rechnerumgebungen, in denen PPUs 1000 sehr große Datensätze verarbeiten und/oder Anwendungen über längere Zeiträume laufen lassen.
  • In einem Ausführungsbeispiel implementiert die PPU 1000 eine Multi-Level-Speicherhierarchie. In einem Ausführungsbeispiel unterstützt die Speicherpartitionseinheit 1080 einen einheitlichen Speicher, um einen einzigen gemeinsam genutzten virtuellen Adressraum für den CPU- und PPU-300-Speicher bereitzustellen, was die gemeinsame Nutzung von Daten zwischen virtuellen Speichersystemen ermöglicht. In einem Ausführungsbeispiel wird die Häufigkeit der Zugriffe einer PPU 1000 auf Speicher, die sich auf anderen Prozessoren befinden, verfolgt, um sicherzustellen, dass Speicherseiten in den physischen Speicher der PPU 1000 verschoben werden, die häufiger auf die Seiten zugreift. In einem Ausführungsbeispiel unterstützt der NVLink 1010 Adressübersetzungsdienste, die es der PPU 1000 ermöglichen, direkt auf die Seitentabellen einer CPU zu leiten und einen vollständigen Zugriff auf den CPU-Speicher durch die PPU 1000 bereitzustellen.
  • In einem Ausführungsbeispiel transferieren Kopier-Engines Daten zwischen mehreren PPUs 1000 oder zwischen PPUs 1000 und CPUs. Die Kopier-Engines können Seitenfehler für Adressen generieren, die nicht den Seitentabellen zugeordnet sind. Die Speicherpartitionseinheit 1080 kann dann die Seitenfehler bearbeiten und die Adressen in die Seitentabelle zuordnen, woraufhin die Kopier-Engine das Transferieren durchführen kann. In einem herkömmlichen System wird der Speicher für mehrere Kopier-Engine-Operationen zwischen mehreren Prozessoren gepinnt (z.B. nicht auslagerbar), wodurch der verfügbare Speicher erheblich reduziert wird. Mit Hardware Page Faulting können Adressen an die Kopier-Engines weitergegeben werden, ohne dass man sich Gedanken darüber machen muss, ob die Speicherseiten resident sind, und der Kopiervorgang ist transparent.
  • Daten aus dem Speicher 1004 oder einem anderen Systemspeicher können von der Speicherpartitionseinheit 1080 abgerufen und im L2-Cache 1160 gespeichert werden, der sich auf dem Chip befindet und von den verschiedenen GPCs 1050 gemeinsam genutzt wird. Wie dargestellt, umfasst jede Speicherpartitionseinheit 1080 einen Teil des L2-Cache 1160, der einem entsprechenden Speichergerät 1004 assoziiert ist. Caches der unteren Ebene können dann in verschiedenen Einheiten innerhalb der GPCs 1050 implementiert werden. So kann beispielsweise jeder der SMs 1140 einen Cache der Ebene eins (L1) implementieren. Der L1-Cache ist ein privater Speicher, der einem bestimmten SM 1140 zugeordnet ist. Daten aus dem L2-Cache 1160 können abgerufen und in jedem der L1-Caches zum Verarbeiten in den Funktionseinheiten der SMs 1140 gespeichert werden. Der L2-Cache 1160 ist mit der Speicherschnittstelle 1170 und der XBar 1070 gekoppelt.
  • Die ROP-Einheit 1150 führt Grafikrasteroperationen durch, die sich auf die Pixelfarbe beziehen, wie z. B. Farbkomprimierung, Pixelüberblendung und ähnliches. Die ROP-Einheit 450 implementiert auch eine Tiefenprüfung in Verbindung mit der Raster-Engine 1125, wobei sie eine Tiefe für eine mit einem Pixelfragment assoziierte Abtaststelle von der Culling-Engine der Raster-Engine 1125 empfängt. Die Tiefe wird mit einer entsprechenden Tiefe in einem Tiefenpuffer für eine mit dem Fragment assoziierte Abtaststelle verglichen. Wenn das Fragment die Tiefenprüfung für den Musterort besteht, aktualisiert die ROP-Einheit 1150 den Tiefenpuffer und überträgt ein Ergebnis der Tiefenprüfung an die Raster-Engine 1125. Die Anzahl der Partitionseinheiten 1080 kann sich von der Anzahl der GPCs 1050 unterscheiden, so dass jede ROP-Einheit 1150 mit jedem der GPCs 1050 gekoppelt sein kann. Die ROP-Einheit 1150 verfolgt die von den verschiedenen GPCs 1050 empfangenen Pakete und bestimmt, zu welchem GPC 1050 ein von der ROP-Einheit 1150 generiertes Ergebnis über die Xbar 1070 geroutet wird. Obwohl die ROP-Einheit 1150 in 11B innerhalb der Speicherpartitionseinheit 1080 umfasst ist, kann sich die ROP-Einheit 1150 in anderen Ausführungsbeispielen außerhalb der Speicherpartitionseinheit 1080 befinden. Zum Beispiel kann die ROP-Einheit 1150 im GPC 1050 oder einer anderen Einheit untergebracht sein.
  • 12 zeigt den Streaming-Multiprozessor 1140 von 11A, gemäß einem Ausführungsbeispiel. Wie in 12 gezeigt, umfasst der SM 1140 einen Anweisungs-Cache 1205, eine oder mehrere Scheduler-Einheiten 1210, eine Registerdatei 1220, einen oder mehrere Verarbeitungskerne 1250, eine oder mehrere Sonderfunktionseinheiten (SFUs) 1252, eine oder mehrere Lade-/Speichereinheiten (LSUs) 1254, ein Verbindungsnetzwerk 1280, einen gemeinsam genutzten Speicher/L1-Cache 1270.
  • Wie oben beschrieben, verteilt die Distributionseinheit 1025 Aufgaben zur Ausführung auf den GPCs 1050 der PPU 1000. Die Aufgaben werden einem bestimmten DPC 1120 innerhalb eines GPCs 1050 allokiert, und wenn die Aufgabe mit einem Shader-Programm assoziiert ist, kann die Aufgabe einem SM 1140 allokiert werden. Die Scheduler-Einheit 1210 empfängt die Aufgaben von der Distributionseinheit 1025 und verwaltet die Anweisungen für einen oder mehrere Thread-Blöcke, die dem SM 1140 zugeordnet sind. Die Scheduler-Einheit 1210 plant Thread-Blöcke zur Ausführung als Warps paralleler Threads, wobei jedem Thread-Block zumindest ein Warp allokiert ist. In einem Ausführungsbeispiel führt jeder Warp 32 Threads aus. Die Scheduler-Einheit 1210 kann eine Vielzahl verschiedener Thread-Blöcke verwalten, indem sie die Warps den verschiedenen Thread-Blöcken allokiert und dann während jedes Taktsignals Anweisungen aus der Vielzahl verschiedener Cooperative Groups an die verschiedenen Funktionseinheiten (z.B. Kerne 1250, SFUs 1252 und LSUs 1254) sendet.
  • Cooperative Groups ist ein Programmiermodell für die Organisation von Gruppen kommunizierender Threads, das es Entwicklern ermöglicht, die Granularität auszudrücken, mit der Threads kommunizieren, und so reichhaltigere, effizientere parallele Dekompositionen zu ermöglichen. Kooperative Start-APIs unterstützen die Synchronisation zwischen Thread-Blöcken für die Ausführung von parallelen Algorithmen. Konventionelle Programmiermodelle stellen ein einziges, einfaches Konstrukt für die Synchronisation kooperierender Threads bereit: eine Barriere über alle Threads eines Thread-Blocks (z.B. die Funktion syncthreads( )). Programmierer möchten jedoch oft Gruppen von Threads mit einer kleineren Granularität als der eines Thread-Blocks definieren und innerhalb der definierten Gruppen synchronisieren, um eine höhere Leistung, Design-Flexibilität und Software-Wiederverwendung in Form von gemeinsamen gruppenweiten Funktionsschnittstellen zu ermöglichen.
  • Cooperative Groups ermöglicht es Programmierern, Gruppen von Threads explizit in Sub-Block- (z.B. so klein wie ein einzelner Thread) und Multi-Block-Granularität zu definieren und kollektive Operationen wie Synchronisation auf den Threads in einer Cooperative Group durchzuführen. Das Programmiermodell unterstützt eine saubere Komposition über Softwaregrenzen hinweg, so dass Bibliotheken und Dienstprogramme innerhalb ihres lokalen Kontexts sicher synchronisieren können, ohne dass Annahmen über Konvergenz getroffen werden müssen. Cooperative Groups-Primitive ermöglichen neue Muster kooperativer Parallelität, die Erzeuger-Verbraucher-Parallelität, opportunistische Parallelität und globale Synchronisation über ein ganzes Netz von Thread-Blöcken umfassen. Die hierarchische Gruppierung von Threads wie Cooperative Thread Arrays (CTA) und Cooperative Group Arrays (CGA) gemäß einigen Ausführungsbeispielen werden in der bereits durch Verweis einbezogenen U.S. Application No. 17/691,621 detaillierter beschrieben.
  • Eine Sendeeinheit 1215 ist so konfiguriert, dass sie Anweisungen an eine oder mehrere der Funktionseinheiten überträgt. Im Ausführungsbeispiel umfasst die Scheduler-Einheit 1210 zwei Sendeeinheiten 1215, die es ermöglichen, dass zwei verschiedene Anweisungen aus demselben Warp während jedes Taktsignals gesendet werden können. In alternativen Ausführungsbeispielen kann jede Scheduler-Einheit 1210 eine einzelne Sendeeinheit 1215 oder zusätzliche Sendeeinheiten 1215 umfassen.
  • Jeder SM 1140 umfasst eine Registerdatei 1220, die einen Satz von Registern für die Funktionseinheiten des SM 1140 bereitstellt. In einem Ausführungsbeispiel ist die Registerdatei 1220 zwischen den einzelnen Funktionseinheiten aufgeteilt, so dass jeder Funktionseinheit ein eigener Teil der Registerdatei 1220 allokiert ist. In einem anderen Ausführungsbeispiel ist die Registerdatei 1220 auf die verschiedenen Warps aufgeteilt, die vom SM 1140 ausgeführt werden. Die Registerdatei 1220 stellt einen temporären Speicher für Operanden bereit, die mit den Datenpfaden der Funktionseinheiten verbunden sind.
  • Jeder SM 1140 umfasst mehrere Verarbeitungskerne 1250. In einem Ausführungsbeispiel umfasst der SM 1140 eine große Anzahl (z.B. 128, etc.) von verschiedenen Verarbeitungskernen 1250. Jeder Kern 1250 kann eine Verarbeitungseinheit mit voller Pipeline, einfacher, doppelter und/oder gemischter Präzision umfassen, die eine arithmetische Gleitkomma-Logikeinheit und eine arithmetische Ganzzahl-Logikeinheit enthält. In einem Ausführungsbeispiel implementieren die arithmetischen Gleitkomma-Logikeinheiten den Standard IEEE 754-2008 für Gleitkomma-Arithmetik. In einem Ausführungsbeispiel umfassen die Kerne 1250 64 Gleitkomma-Kerne mit einfacher Präzision (32 Bit), 64 Ganzzahl-Kerne, 32 Gleitkomma-Kerne mit doppelter Präzision (64 Bit) und 8 Tensor-Kerne.
  • Tensor-Kerne sind konfiguriert, um Matrix-Operationen durchzuführen, und in einem Ausführungsbeispiel umfassen die Kerne 1250 einen oder mehrere Tensor-Kerne. Insbesondere sind die Tensorkerne so konfiguriert, dass sie Deep-Learning-Matrixarithmetik durchführen, wie z. B. Faltungsoperationen für das Trainieren und Inferieren neuronaler Netzwerke. In einem Ausführungsbeispiel operiert jeder Tensorkern auf einer 4x4-Matrix und führt eine Matrixmultiplikations- und Akkumulationsoperation D=A×B+C durch, wobei A, B, C und D 4x4-Matrizen sind.
  • In einem Ausführungsbeispiel sind die Eingaben für die Matrixmultiplikation A und B 16-Bit-Gleitkommamatrizen, während die Akkumulationsmatrizen C und D 16-Bit-Gleitkomma- oder 32-Bit-Gleitkommamatrizen sein können. Tensor-Kerne operieren mit 16-Bit-Gleitkomma-Eingabedaten und 32-Bit-Gleitkomma-Akkumulation. Die 16-Bit-Gleitkommamultiplikation erfordert 64 Operationen und führt zu einem Produkt voller Präzision, das dann unter Verwendung von 32-Bit-Gleitkommaaddition mit den anderen Zwischenprodukten zu einer 4x4x4-Matrixmultiplikation akkumuliert wird. In der Praxis werden Tensor-Kerne verwendet, um viel größere zweidimensionale oder höherdimensionale Matrixoperationen durchzuführen, die aus diesen kleineren Elementen aufgebaut sind. Eine API, wie z.B. die CUDA C++ API, stellt spezialisierte Operationen zum Laden, Multiplizieren und Akkumulieren von Matrizen sowie zum Speichern von Matrizen zur Verfügung, um Tensor Kerne in einem CUDA-C++ Programm effizient zu verwenden. Auf der CUDA-Ebene geht die Schnittstelle auf Warp-Ebene von Matrizen der Größe 16x16 aus, die sich über alle 32 Threads des Warps erstrecken.
  • In einigen Ausführungsbeispielen ist die Transpositionshardware in den Verarbeitungskernen 1250 oder einer anderen Funktionseinheit (z.B. SFUs 1252 oder LSUs 1254) umfasst und so konfiguriert, dass sie von Diagonalen gespeicherte Matrixdaten generiert und/oder die ursprüngliche Matrix und/oder transponierte Matrix aus den von Diagonalen gespeicherten Matrixdaten generiert. Die Transpositionshardware kann innerhalb des gemeinsam genutzten Speichers 1270 bereitgestellt werden, um den Pfad des SM 1140 zum Laden der Datei 1220 zu registrieren.
  • In einem Beispiel können die von Diagonalen gespeicherten Matrixdaten vom DRAM abgerufen und im gemeinsam genutzten Speicher 1270 gespeichert werden. Wenn die Anweisung zur Durchführung der Verarbeitung unter Verwendung der von Diagonalen gespeicherten Matrixdaten verarbeitet wird, kann die im Pfad des gemeinsam genutzten Speichers 1270 und der Registerdatei 1220 angeordnete Transpositionshardware die ursprüngliche Matrix, die transponierte Matrix, die verdichtete ursprüngliche Matrix und/oder die verdichtete transponierte Matrix bereitstellen. Bis zur allerletzten Speicherung vor der Anweisung können die durch Diagonalen gespeicherten Einzelmatrixdaten erhalten bleiben, und der durch die Anweisung bezeichnete Matrixtyp wird nach Bedarf in der Registerdatei 1220 generiert.
  • Jeder SM 1140 umfasst auch mehrere SFUs 1252, die spezielle Funktionen durchführen (z.B. Attributauswertung, reziproke Quadratwurzel und dergleichen). In einem Ausführungsbeispiel können die SFUs 1252 eine Tree Traversal Unit (z.B. TTU 1143) umfassen, die so konfiguriert ist, dass sie eine hierarchische Baumdatenstruktur durchläuft. In einem Ausführungsbeispiel können die SFUs 1252 eine Textureinheit (z.B. Textureinheit 1142) umfassen, die so konfiguriert ist, dass sie Filteroperationen für Texturkarten durchführt. In einem Ausführungsbeispiel sind die Textureinheiten so konfiguriert, dass sie Texture-Maps (z.B. ein 2D-Array von Texeln) aus dem Speicher 1004 laden und die Texture-Maps samplen, um Sample-Werte für die Verwendung in Shader-Programmen zu erzeugen, die vom SM 1140 ausgeführt werden. In einem Ausführungsbeispiel werden die Texturkarten im gemeinsam genutzten Speicher/L1 Cache 1170 gespeichert. Die Textureinheiten implementieren Texturoperationen wie Filteroperationen unter Verwendung von Mip-Maps (z.B. Texturkarten mit unterschiedlichem Detaillierungsgrad). In einem Ausführungsbeispiel umfasst jeder SM 1140 zwei Textureinheiten.
  • Jeder SM 1140 umfasst auch mehrere LSUs 1254, die Lade- und Speicheroperationen zwischen dem gemeinsam genutzten Speicher/L1-Cache 1270 und der Registerdatei 1220 implementieren. Jeder SM 1140 umfasst ein Verbindungsnetzwerk 1280, das jede der Funktionseinheiten mit der Registerdatei 1220 und die LSU 1254 mit der Registerdatei 1220 und dem gemeinsam genutzten Speicher/L1 Cache 1270 verbindet. In einem Ausführungsbeispiel ist das Verbindungsnetzwerk 1280 eine Crossbar, die so konfiguriert werden kann, dass sie jede der Funktionseinheiten mit jedem der Register in der Registerdatei 1220 verbindet und die LSUs 1254 mit der Registerdatei 1220 und gemeinsam genutzten Speicherorten im gemeinsam genutzten Speicher/L1 Cache 1270 verbindet. In Ausführungsbeispielen umfassen die LSUs 1254 eine TMAU 112. In einigen Ausführungsbeispielen kann die TMAU 112 jedoch auch von der LSU getrennt sein. Jede TMAU 112 kann eng an ein einzelnes SM oder an mehr als ein SM gekoppelt sein. In Ausführungsbeispielen, in denen die TMAU 112 eng mit mehreren SMs gekoppelt ist, kann ein Arbiter Anfragen von den SMs empfangen und sie seriell an die TMAU 112 weiterleiten.
  • Der gemeinsam genutzte Speicher/L1 Cache 1270 ist ein Array von On-Chip-Speicher, der die Datenspeicherung und Kommunikation zwischen dem SM 1140 und der Primitiv-Engine 1135 sowie zwischen Threads im SM 1140 ermöglicht. In einem Ausführungsbeispiel umfasst der gemeinsam genutzte Speicher/L1 Cache 1270 eine Speicherkapazität von 128 KB und befindet sich auf dem Pfad vom SM 1140 zur Partitionseinheit 1080. Der gemeinsam genutzte Speicher/L1 Cache 1270 kann zum Cachen von Lese- und Schreibvorgängen verwendet werden. Einer oder mehrere der gemeinsam genutzten Speicher/L1 Cache 1270, L2 Cache 1160 und Speicher 1004 sind Backing-Stores.
  • Die Kombination von Daten-Cache und gemeinsam genutzter Speicherfunktionalität in einem einzigen Speicherblock stellt die beste Gesamtleistung für beide Typen von Speicherzugriffen bereit. Die Kapazität kann von Programmen, die den gemeinsam genutzten Speicher nicht verwenden, als Cache genutzt werden. Wenn der gemeinsam genutzte Speicher beispielsweise so konfiguriert ist, dass die Hälfte der Kapazität verwendet wird, können Textur- und Lade-/Speicheroperationen die verbleibende Kapazität verwenden. Durch die Integration in den gemeinsam genutzten Speicher/L1-Cache 1270 kann der gemeinsam genutzte Speicher/L1-Cache 1270 als durchsatzstarke Leitung für Streaming-Daten fungieren und gleichzeitig einen Zugriff auf häufig wiederverwendete Daten mit hoher Bandbreite und niedriger Latenz bereitstellen.
  • Im Zusammenhang mit dieser Offenbarung bedeutet ein SM oder „Streaming-Multiprozessor“ einen Prozessor, der so aufgebaut ist, wie in USP7,447,873 von Nordquist beschrieben, einschließlich Verbesserungen und Weiterentwicklungen davon, und wie er beispielsweise in vielen Generationen von NVIDIA-GPUs implementiert ist. Ein SM kann beispielsweise eine Vielzahl von Verarbeitungs-Engines oder -Kernen umfassen, die so konfiguriert sind, dass sie gleichzeitig eine Vielzahl von Threads ausführen, die in einer Vielzahl von SIMD-Gruppen (z.B. Warps) angeordnet sind, wobei jeder der Threads in einer gleichen SIMD-Gruppe ein gleiches Datenverarbeitungsprogramm ausführt, das eine Befehlssequenz für ein anderes Eingabeobjekt umfasst, und verschiedene Threads in der gleichen SIMD-Gruppe unter Verwendung verschiedener Verarbeitungs-Engines oder -Kerne ausgeführt werden. Ein SM kann typischerweise auch bereitstellen: (a) eine lokale Registerdatei mit mehreren Lanes, wobei jede Verarbeitungs-Engine oder jeder Kern so konfiguriert ist, dass sie/er auf eine andere Teilmenge der Lanes zugreift; und eine Anweisungsausgabelogik, die so konfiguriert ist, dass sie eine der SIMD-Gruppen auswählt und eine der Anweisungen desselben Datenverarbeitungsprogramms an jede der Vielzahl von Verarbeitungs-Engines parallel ausgibt, wobei jede Verarbeitungs-Engine dieselbe Anweisung parallel zu jeder anderen Verarbeitungs-Engine ausführt und dabei die Teilmenge der ihr zugänglichen Lanes der lokalen Registerdatei verwendet. Ein SM enthält typischerweise weiter eine Kern-Schnittstellenlogik, die so konfiguriert ist, dass sie die Ausführung von einer oder mehreren SIMD-Gruppen initiiert. Wie in den Figuren gezeigt, wurden solche SMs so konstruiert, dass sie einen schnellen, gemeinsam genutzten Speicher bereitstellen, der die gemeinsame Nutzung/Wiederverwendung von Daten und die Synchronisation zwischen allen Threads eines CTA ermöglicht, der auf dem SM ausgeführt wird.
  • Wenn sie zum parallelen Berechnen für allgemeine Zwecke konfiguriert werden, kann eine einfachere Konfiguration verwendet werden als bei der Grafikverarbeitung. Insbesondere werden die in 11 A gezeigten Grafikverarbeitungseinheiten mit fester Funktion umgangen, wodurch ein wesentlich einfacheres Programmiermodell entsteht. In der Konfiguration des parallelen Berechnens für allgemeine Zwecke weist die Distributionseinheit 1025 Blöcke von Threads zu und verteilt sie direkt an die DPCs 1120. Die Threads in einem Block führen dasselbe Programm aus, wobei eine eindeutige Thread-ID in der Berechnung verwendet wird, um sicherzustellen, dass jeder Thread eindeutige Ergebnisse generiert, wobei der SM 1140 verwendet wird, um das Programm auszuführen und Berechnungen durchzuführen, der gemeinsam genutzte Speicher/L1-Cache 1270, um zwischen den Threads zu kommunizieren, und die LSU 1254, um den globalen Speicher über den gemeinsam genutzten Speicher/L1-Cache 1270 und die Speicherpartitionseinheit 1080 zu lesen und zu schreiben. Wenn der SM 1140 für allgemeines paralleles Rechnen konfiguriert ist, kann er auch Befehle schreiben, die die Scheduler-Einheit 1020 verwenden kann, um neue Arbeit auf den DPCs 1120 zu starten.
  • Die PPU 1000 kann einen Desktop-Rechner, einen Laptop-Computer, einen Tablet-Computer, Server, Supercomputer, ein Smartphone (z.B. ein drahtloses, tragbares Gerät), einen persönlichen digitalen Assistenten (PDA), eine Digitalkamera, ein Fahrzeug, eine kopfgetragene Anzeige, ein tragbares elektronisches Gerät und dergleichen umfassen. In einem Ausführungsbeispiel ist die PPU 1000 auf einem einzigen Halbleitersubstrat untergebracht. In einem anderen Ausführungsbeispiel ist die PPU 1000 in einem System-on-a-Chip (SoC) zusammen mit einem oder mehreren anderen Geräten wie zusätzlichen PPUs 1000, dem Speicher 1004, einer CPU mit reduziertem Befehlssatz (RISC), einer Speicherverwaltungseinheit (MMU), einem Digital-Analog-Wandler (DAC) und dergleichen umfasst.
  • In einem Ausführungsbeispiel kann die PPU 1000 auf einer Grafikkarte enthalten sein, die ein oder mehrere Speichergeräte 1004 umfasst. Die Grafikkarte kann so konfiguriert sein, dass sie mit einem PCIe-Steckplatz auf einer Hauptplatine eines Desktop-Rechners verbunden werden kann. In einem weiteren Ausführungsbeispiel kann die PPU 1000 eine integrierte Grafikverarbeitungseinheit (iGPU) oder ein Parallelprozessor sein, der den Chipsatz der Hauptplatine umfasst.
  • Beispielhaftes Rechnersystem
  • Systeme mit mehreren GPUs und CPUs werden in einer Vielzahl von Branchen verwendet, da Entwickler mehr Parallelität in Anwendungen wie dem Rechnen mit künstlicher Intelligenz aufdecken und nutzen. Leistungsstarke, GPU-beschleunigte Systeme mit zehn bis vielen tausend Rechenknoten werden in Datenzentren, Forschungsanlagen und Supercomputern eingesetzt, um immer größere Probleme zu lösen. Da die Anzahl der Verarbeitungsgeräte innerhalb der Hochleistungssysteme zunimmt, müssen die Kommunikations- und Datentransferierungsmechanismen skaliert werden, um die erhöhte Bandbreite zu unterstützen.
  • 13A ist ein konzeptionelles Diagramm eines Verarbeitungssystems 1300, das gemäß einem Ausführungsbeispiel die PPU 1000 aus 10 verwendet. Das beispielhafte System 1300 kann so konfiguriert sein, dass es die in dieser Applikation offenbaren Verfahren implementiert (z.B. die TMAU in den 1, 2, 6 oder 11A). Das Verarbeitungssystem 1300 umfasst eine CPU 1330, einen Switch 1355 und mehrere PPUs 1000 sowie entsprechende Speicher 1004. Der NVLink 1010 stellt Hochgeschwindigkeitskommunikationsverbindungen zwischen jeder der PPUs 1000 bereit. Obwohl in 13 A eine bestimmte Anzahl von NVLink 1010- und Verbindungen 1002-Verbindungen gezeigt wird, kann die Anzahl der Verbindungen zu jeder PPU 1000 und der CPU 1330 variieren. Der Switch 1355 bildet die Schnittstelle zwischen der Verbindung 1002 und der CPU 1330. Die PPUs 1000, die Speicher 1004 und die NVLinks 1010 können auf einer einzigen Halbleiterplattform angeordnet sein, um ein paralleles Verarbeitungsmodul 1325 zu bilden. In einem Ausführungsbeispiel unterstützt der Switch 1355 zwei oder mehr Protokolle, um eine Schnittstelle zwischen verschiedenen unterschiedlichen Verbindungen und/oder Links zu bilden.
  • In einem anderen Ausführungsbeispiel (nicht gezeigt) stellt der NVLink 1010 eine oder mehrere Hochgeschwindigkeitskommunikationsverbindungen zwischen jeder der PPUs 1000 und der CPU 1330 bereit, und der Switch 1355 bildet eine Schnittstelle zwischen der Verbindung 1002 und jeder der PPUs 1000. Die PPUs 1000, die Speicher 1004 und die Verbindung 1002 können auf einer einzigen Halbleiterplattform untergebracht werden, um ein paralleles Verarbeitungsmodul 1325 zu bilden. In einem weiteren Ausführungsbeispiel (nicht gezeigt) stellt die Verbindung 1002 eine oder mehrere Kommunikationsverbindungen zwischen jeder der PPUs 1000 und der CPU 1330 bereit, und der Switch 1355 stellt unter Verwendung des NVLink 1010 eine Schnittstelle zwischen jeder der PPUs 1000 her, um eine oder mehrere Hochgeschwindigkeitskommunikationsverbindungen zwischen den PPUs 1000 bereitzustellen. In einem anderen Ausführungsbeispiel (nicht gezeigt) stellt der NVLink 1010 über den Switch 1355 eine oder mehrere Hochgeschwindigkeits-Kommunikationsverbindungen zwischen den PPUs 1000 und der CPU 1330 bereit. In einem weiteren Ausführungsbeispiel (nicht gezeigt) stellt die Verbindung 1002 eine oder mehrere Kommunikationsverbindungen zwischen jeder der PPUs 1000 direkt bereit. Eine oder mehrere der NVLink 1010-Hochgeschwindigkeits-Kommunikationsverbindungen können als physische NVLink-Verbindung oder entweder als On-Chip- oder On-Die-Verbindung implementiert werden, die das gleiche Protokoll wie der NVLink 1010 verwendet.
  • Im Zusammenhang mit der vorliegenden Beschreibung kann sich eine einzelne Halbleiterplattform auf eine einzige einheitliche integrierte Schaltung auf Halbleiterbasis beziehen, die auf einem Die oder Chip hergestellt wird. Es sei darauf hingewiesen, dass sich der Begriff Einzel-Halbleiterplattform auch auf Multi-Chip-Module mit erhöhter Konnektivität beziehen kann, die den On-Chip-Betrieb simulieren und wesentliche Verbesserungen gegenüber der Verwendung einer herkömmlichen Bus-Implementierung bieten. Natürlich können die verschiedenen Schaltungen oder Geräte auch separat oder in verschiedenen Kombinationen von Halbleiterplattformen untergebracht werden, je nach den Wünschen des Benutzers. Alternativ kann das Parallelverarbeitungsmodul 1325 als ein Schaltungssubstrat implementiert werden, und jede der PPUs 1000 und/oder Speicher 1004 kann ein gehäustes Gerät sein. In einem Ausführungsbeispiel befinden sich die CPU 1330, der Switch 1355 und das Parallelverarbeitungsmodul 1325 auf einer einzigen Halbleiterplattform.
  • In einem Ausführungsbeispiel beträgt die Signalisierungsrate jedes NVLink 1010 20 bis 25 Gigabit/Sekunde, und jede PPU 1000 umfasst sechs NVLink 1010-Schnittstellen (wie in 13A gezeigt, sind fünf NVLink 1010-Schnittstellen für jede PPU 1000 umfasst). Jeder NVLink 1010 stellt eine Datenübertragungsrate von 25 Gigabyte/Sekunde in jeder Richtung bereit, wobei sechs Links 1000 Gigabyte/Sekunde transferieren. Die NVLinks 1010 können ausschließlich für die PPU-zu-PPU-Kommunikation verwendet werden, wie in 13A gezeigt, oder eine Kombination aus PPU-zu-PPU und PPU-zu-CPU, wenn die CPU 1330 auch eine oder mehrere NVLink 1010-Schnittstellen umfasst.
  • In einem Ausführungsbeispiel ermöglicht der NVLink 1010 einen direkten Lade-/Speicher-/Atomar-Zugriff von der CPU 1330 auf den Speicher 1004 jeder PPU 1000. In einem Ausführungsbeispiel unterstützt der NVLink 1010 Kohärenzoperationen, so dass aus den Speichern 1004 gelesene Daten in der Cache-Hierarchie der CPU 1330 gespeichert werden können, wodurch die Cache-Zugriffslatenz für die CPU 1330 verringert wird. In einem Ausführungsbeispiel umfasst der NVLink 1010 die Unterstützung von Adressübersetzungsdiensten (ATS), wodurch die PPU 1000 direkt auf Seitentabellen innerhalb der CPU 1330 zugreifen kann. Einer oder mehrere der NVLinks 1010 können auch so konfiguriert werden, dass sie in einem stromsparenden Modus operieren.
  • 13B zeigt ein beispielhaftes System 1365, in dem die verschiedenen Architekturen und/oder Funktionen der verschiedenen Ausführungsbeispiele implementiert werden können. Das beispielhafte System 1365 kann so konfiguriert sein, dass es die in dieser Applikation offenbaren Verfahren implementiert (z.B. die TMAU in den 1, 2, 6 oder 11 A).
  • Wie gezeigt, wird ein System 1365 bereitgestellt, das zumindest eine zentrale Verarbeitungseinheit 1330 umfasst, die mit einem Kommunikationsbus 1375 verbunden ist. Der Kommunikationsbus 1375 kann unter Verwendung eines beliebigen geeigneten Protokolls implementiert werden, z. B. PCI (Peripheral Component Interconnect), PCI-Express, AGP (Accelerated Graphics Port), HyperTransport oder eines anderen Bus- oder Punkt-zu-Punkt-Kommunikationsprotokolls bzw. anderer Protokolle. Das System 1365 umfasst auch einen Hauptspeicher 1340. Steuerlogik (Software) und Daten werden im Hauptspeicher 1340 gespeichert, der die Form eines Speichers mit wahlfreiem Zugriff (RAM) annehmen kann.
  • Das System 1365 umfasst auch Eingabegeräte 1360, das Parallelverarbeitungssystem 1325 und Anzeigegeräte 1345, z.B. eine herkömmliche Kathodenstrahlröhre (CRT), eine Flüssigkristallanzeige (LCD), eine Leuchtdiode (LED), ein Plasmadisplay oder ähnliches. Benutzereingaben können von den Eingabegeräten 1360 empfangen werden, z.B. Tastatur, Maus, Touchpad, Mikrofon und dergleichen. Jedes der vorgenannten Module und/oder Geräte kann sogar auf einer einzigen Halbleiterplattform angeordnet sein, um das System 1365 zu bilden. Alternativ können die verschiedenen Module auch separat oder in verschiedenen Kombinationen von Halbleiterplattformen angeordnet sein, je nach den Wünschen des Benutzers.
  • Weiterhin kann das System 1365 zu Kommunikationszwecken über eine Netzwerkschnittstelle 1335 an ein Netzwerk (z.B. ein Telekommunikationsnetzwerk, ein lokales Netzwerk (LAN), ein drahtloses Netzwerk, ein Weitverkehrsnetzwerk (WAN) wie das Internet, ein Peer-to-Peer-Netzwerk, ein Kabelnetzwerk oder Ähnliches) gekoppelt werden.
  • Das System 1365 kann auch einen Sekundärspeicher umfassen (nicht dargestellt). Der Sekundärspeicher umfasst beispielsweise ein Festplattenlaufwerk und/oder ein Wechselspeicherlaufwerk, das ein Diskettenlaufwerk, ein Magnetbandlaufwerk, ein Compact-Disk-Laufwerk, ein DVD-Laufwerk, ein Aufnahmegerät oder einen USB-Flash-Speicher repräsentiert. Das Wechselspeicherlaufwerk liest und/oder schreibt auf bekannte Weise von einem Wechselspeichergerät.
  • Im Hauptspeicher 1340 und/oder im Sekundärspeicher können Computerprogramme oder logische Algorithmen zur Computersteuerung gespeichert sein. Solche Rechnerprogramme ermöglichen es dem System 1365, wenn sie ausgeführt werden, verschiedene Funktionen durchzuführen. Der Speicher 1340, der Speicher und/oder jeder andere Speicher sind mögliche Beispiele für computerlesbare Medien.
  • Die Architektur und/oder Funktionalität der verschiedenen vorangegangenen Figuren kann im Rahmen eines allgemeinen Rechnersystems, eines Schaltungssystems, eines für Unterhaltungszwecke bestimmten Spielkonsolensystems, eines applikationsspezifischen Systems und/oder eines beliebigen anderen gewünschten Systems implementiert werden. Beispielsweise kann das System 1365 die Form eines Desktop-Rechners, eines Laptops, eines Tablet-Computers, eines Servers, eines Supercomputers, eines Smartphones (z.B. eines drahtlosen, handgehaltenen Geräts), eines persönlichen digitalen Assistenten (PDA), einer Digitalkamera, eines Fahrzeugs, einer kopfgetragenen Anzeige, eines handgehaltenen elektronischen Geräts, eines Mobiltelefongeräts, eines Fernsehers, einer Workstation, von Spielkonsolen, eines eingebetteten Systems und/oder eines beliebigen anderen Typs von Logik haben.
  • Ein Anwendungsprogramm kann über eine Applikation implementiert werden, die von einem Host-Prozessor, wie z.B. einer CPU, ausgeführt wird. In einem Ausführungsbeispiel kann ein Gerätetreiber eine Anwendungsprogrammierschnittstelle (API) implementieren, die verschiedene Funktionen definiert, die von dem Anwendungsprogramm genutzt werden können, um grafische Daten für die Anzeige zu generieren. Der Gerätetreiber ist ein Softwareprogramm, das eine Vielzahl von Anweisungen umfasst, die den Betrieb der PPU 1000 steuern. Die API stellt eine Abstraktion für einen Programmierer bereit, die es ihm ermöglicht, spezialisierte Grafikhardware wie die PPU 1000 zu nutzen, um die grafischen Daten zu generieren, ohne dass der Programmierer den spezifischen Anweisungssatz für die PPU 1000 nutzen muss. Die Applikation kann einen API-Aufruf umfassen, der an den Gerätetreiber für die PPU 1000 geroutet wird. Der Gerätetreiber interpretiert den API-Aufruf und führt verschiedene Operationen durch, um auf den API-Aufruf zu reagieren. In einigen Instanzen kann der Gerätetreiber Operationen durch Ausführen von Anweisungen auf der CPU durchführen. In anderen Instanzen kann der Gerätetreiber zumindest teilweise Operationen durchführen, indem er über eine Eingabe/Ausgabe-Schnittstelle zwischen der CPU und der PPU 1000 Operationen auf der PPU 1000 startet. In einem Ausführungsbeispiel ist der Gerätetreiber so konfiguriert, dass er die Graphikverarbeitungs-Pipeline 1400 unter Verwendung der Hardware der PPU 1000 implementiert.
  • In der PPU 1000 können verschiedene Programme ausgeführt werden, um die verschiedenen Stufen der Verarbeitung für das Anwendungsprogramm zu implementieren. Zum Beispiel kann der Gerätetreiber einen Kernel auf der PPU 1000 starten, um eine Stufe der Verarbeitung auf einem SM 1140 (oder mehreren SMs 1140) durchzuführen. Der Gerätetreiber (oder der initiale Kernel, der von der PPU 1000 ausgeführt wird) kann auch andere Kernel auf der PPU 1000 starten, um andere Verarbeitungsschritte durchzuführen. Umfasst die Verarbeitung des Anwendungsprogramms eine Graphikverarbeitungs-Pipeline, können einige der Stufen der Graphikverarbeitungs-Pipeline auf einer festen Hardware-Einheit implementiert werden, wie z. B. einem Rasterizer oder einem Datenassembler, der in der PPU 1000 implementiert ist. Es wird deutlich, dass die Ergebnisse eines Kernels von einer oder mehreren zwischengeschalteten Hardwareeinheiten mit fester Funktion verarbeitet werden können, bevor sie von einem nachfolgenden Kernel auf einem SM 1140 verarbeitet werden.
  • Alle Patente und gedruckten Veröffentlichungen, auf die oben Bezug genommen wird, sind durch Bezugnahme hierin enthalten, als ob sie ausdrücklich aufgeführt wären.
  • Obwohl die Erfindung im Zusammenhang mit den derzeit als am besten geeigneten und bevorzugten Ausführungsbeispielen beschrieben wurde, soll die Erfindung nicht auf die offenbaren Ausführungsbeispiele beschränkt sein, sondern im Gegenteil verschiedene Modifikationen und äquivalente Anordnungen umfassen, die in Geist und Umfang der beigefügten Ansprüche enthalten sind.
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Patentliteratur
    • US 11554552 B [0005]
    • US 11080051 B [0008]
    • US 17691690 B [0022, 0030]
    • US 8555035 B [0026]
    • US 7634621 B [0026]
    • US 20180322078 A [0029]
    • US 17497507 B [0049]
    • US 17/691406 [0069]
    • US 17691288 B [0116]

    Claims (16)

    1. Parallelprozessor, umfassend: eine Schnittstelle zu einem externen Speicher; eine Vielzahl von Mehrkernprozessoren, wobei jeder Mehrkernprozessor einen jeweiligen gemeinsam genutzten Speicher aufweist; und eine Vielzahl von Speicherzugriffs-Hardwareschaltungen, wobei jede Speicherzugriffs-Hardwareschaltung mit einem Mehrkernprozessor der Vielzahl von Mehrkernprozessoren gekoppelt ist und konfiguriert ist, zum: Empfangen einer Speicherzugriffsanforderung für einen Datenblock von dem gekoppelten Mehrkernprozessor; und asynchronen Transferieren, als Antwort auf die Speicherzugriffsanforderung, des Datenblocks zwischen Speicherorten in einem oder beiden von dem gemeinsam genutzten Speicher des gekoppelten Mehrkernprozessors und dem externen Speicher.
    2. Parallelprozessor gemäß Anspruch 1, wobei das asynchrone Transferieren von einem Speicherplatz im externen Speicher zu einem anderen Speicherplatz im externen Speicher erfolgt.
    3. Parallelprozessor gemäß einem der vorhergehenden Ansprüche, wobei das asynchrone Transferieren von einem Ort im gemeinsam genutzten Speicher des gekoppelten Mehrkernprozessors zu einem anderen Ort im gemeinsam genutzten Speicher des gekoppelten Mehrkernprozessors erfolgt.
    4. Parallelprozessor gemäß einem der vorhergehenden Ansprüche, wobei das asynchrone Transferieren zwischen einem Ort im externen Speicher und einem Ort in einem gemeinsam genutzten Speicher des gekoppelten Mehrkernprozessors erfolgt.
    5. Parallelprozessor gemäß Anspruch 4, wobei die mit dem Mehrkernprozessor gekoppelte Speicherzugriffs-Hardwareschaltung weiter konfiguriert ist, um als Antwort auf die Speicherzugriffsanforderung eine Vielzahl von Anforderungen an den externen Speicher zu senden, um den Datenblock zu transferieren, und wobei jede der Vielzahl von Anforderungen eine jeweils unterschiedliche Speicheradresse in dem Datenblock enthält, die von der Speicherzugriffs-Hardwareschaltung generiert wird.
    6. Parallelprozessor gemäß einem der vorhergehenden Ansprüche, wobei die mit dem Mehrkernprozessor gekoppelte Speicherzugriffs-Hardwareschaltung konfiguriert ist zum Lesen und Schreiben in einen gemeinsam genutzten Speicher des mit der Speicherzugriffs-Hardwareschaltung gekoppelten Mehrkernprozessors und in den externen Speicher.
    7. Parallelprozessor gemäß einem der vorhergehenden Ansprüche, wobei die mit dem Mehrkernprozessor gekoppelte Speicherzugriffs-Hardwareschaltung konfiguriert ist zum Kopieren des Datenblocks aus dem externen Speicher in den gemeinsam genutzten Speicher des gekoppelten Mehrkernprozessors.
    8. Parallelprozessor gemäß einem der vorhergehenden Ansprüche, wobei die mit dem Mehrkernprozessor gekoppelte Speicherzugriffs-Hardwareschaltung weiter konfiguriert ist zum Durchführen des asynchronen Transfers durch direktes Schreiben des Datenblocks aus dem externen Speicher in den gemeinsam genutzten Speicher des Mehrkernprozessors, und zwar von einem ersten Ort in dem gemeinsam genutzten Speicher zu einem zweiten Ort in dem gemeinsam genutzten Speicher, wobei auf den ersten und den zweiten Ort in dem gemeinsam genutzten Speicher durch jeweils unterschiedliche Mehrkernprozessoren der Vielzahl von Mehrkernprozessoren zugegriffen werden kann, oder von einem ersten Ort in dem externen Speicher zu einem zweiten Ort in dem externen Speicher.
    9. Parallelprozessor gemäß einem der vorhergehenden Ansprüche, wobei die mit dem Mehrkernprozessor gekoppelte Speicherzugriffs-Hardwareschaltung weiter konfiguriert ist, um den asynchronen Transfer unabhängig von der Größe des Datenblocks als Antwort auf die in einer einzigen Nachricht empfangene Speicherzugriffsanforderung durchzuführen.
    10. Parallelprozessor gemäß einem der vorhergehenden Ansprüche, wobei die Speicherzugriffs-Hardwareschaltung, die mit dem Mehrkernprozessor gekoppelt ist, weiter konfiguriert ist zum Aktualisieren eines Zählers in dem gemeinsam genutzten Speicher für jeden Unterblock von Daten in dem Datenblock, wobei der Mehrkernprozessor eine Synchronisationsschaltung umfasst, die konfiguriert ist zum Überwachen des Zählers auf einen vorbestimmten Wert.
    11. Parallelprozessor gemäß einem der vorhergehenden Ansprüche, wobei die Speicherzugriffs-Hardwareschaltung, die mit dem Mehrkernprozessor gekoppelt ist, weiter konfiguriert ist zum Lesen des Datenblocks in dem externen Speicher und Schreiben des Datenblocks an einen Speicherort in einem gemeinsam genutzten Speicher für jede Gruppe der Vielzahl von Mehrkernprozessoren.
    12. Parallelprozessor gemäß einem der vorhergehenden Ansprüche, wobei die Speicherzugriffs-Hardwareschaltung, die mit dem Mehrkernprozessor gekoppelt ist, eine Anforderungswarteschlange, eine Anforderungsgenerierungsschaltung und eine Schaltung zur Verfolgung des Abschlusses einer Anforderung umfasst.
    13. Parallelprozessor gemäß Anspruch 12, wobei die Anforderungswarteschlange so konfiguriert ist, dass sie Speicherzugriffsanforderungen für Tensoren und Speicherzugriffsanforderungen für Nicht-Tensor-Datenblöcke akzeptiert.
    14. Parallelprozessor gemäß einem der vorhergehenden Ansprüche, wobei jeder der Mehrkernprozessoren eine Vielzahl von parallelen Verarbeitungskernen mit unterschiedlichen Rechenfähigkeiten und/oder Präzisionen umfasst, wobei die Vielzahl von parallelen Verarbeitungskernen auf einen gemeinsamen Anweisungs-Cache-Speicher zugreift.
    15. Verfahren, das in einer parallelen Verarbeitungseinheit durchgeführt wird, die eine Vielzahl von Multiprozessoren umfasst, wobei das Verfahren folgende Schritte umfasst: Empfangen, durch eine Speicherzugriffs-Hardwareschaltung, die mit einem Mehrkernprozessor der Vielzahl von Mehrkernprozessoren gekoppelt ist, einer Speicherzugriffsanforderung für einen Datenblock von dem gekoppelten Mehrkernprozessor, wobei jeder Mehrkernprozessor einen entsprechenden gemeinsam genutzten Speicher umfasst, wobei die Speicherzugriffs-Hardwareschaltung eine von einer Vielzahl von Speicherzugriffsschaltungen ist, die jeweils mit einem der Mehrkernprozessoren gekoppelt sind; und asynchrones Transferieren, als Antwort auf die Speicherzugriffsanforderung, des Datenblocks durch die Speicherzugriffs-Hardwareschaltung zwischen einem ersten Speicherort und einem zweiten Speicherort.
    16. Speicherzugriffs-Hardwareschaltung, umfassend: eine Schnittstelle zu einem externen Speicher; eine Speicher-Eingabe/Ausgabe-Schnittstelle zum Empfangen von Speicherzugriffsanforderungen von einem Mehrkernprozessor; zumindest eine Speicherschnittstelle zu einem jeweiligen gemeinsam genutzten Speicher an jedem von einem oder mehreren anderen Mehrkernprozessoren und dem Mehrkernprozessor; und eine Verarbeitungs-Pipeline, konfiguriert zum: Empfangen, von dem Mehrkernprozessor, einer Speicherzugriffsanforderung für einen Block von Daten; und asynchronen Transferieren, als Antwort auf die Speicherzugriffsanforderung, des Datenblocks zwischen einem ersten Speicherort und einem zweiten Speicherort.
    DE102023105565.8A 2022-03-10 2023-03-07 VERFAHREN UND VORRICHTUNG FÜR EFFIZIENTEN ZUGRIFF AUF MEHRDIMENSIONALE DATENSTRUKTUREN UND/ODER ANDERE GROßE DATENBLÖCKE Pending DE102023105565A1 (de)

    Applications Claiming Priority (2)

    Application Number Priority Date Filing Date Title
    US17/691,422 2022-03-10
    US17/691,422 US20230289292A1 (en) 2022-03-10 2022-03-10 Method and apparatus for efficient access to multidimensional data structures and/or other large data blocks

    Publications (1)

    Publication Number Publication Date
    DE102023105565A1 true DE102023105565A1 (de) 2023-09-14

    Family

    ID=87760038

    Family Applications (1)

    Application Number Title Priority Date Filing Date
    DE102023105565.8A Pending DE102023105565A1 (de) 2022-03-10 2023-03-07 VERFAHREN UND VORRICHTUNG FÜR EFFIZIENTEN ZUGRIFF AUF MEHRDIMENSIONALE DATENSTRUKTUREN UND/ODER ANDERE GROßE DATENBLÖCKE

    Country Status (3)

    Country Link
    US (1) US20230289292A1 (de)
    CN (1) CN116775518A (de)
    DE (1) DE102023105565A1 (de)

    Families Citing this family (3)

    * Cited by examiner, † Cited by third party
    Publication number Priority date Publication date Assignee Title
    US12020035B2 (en) 2022-03-10 2024-06-25 Nvidia Corporation Programmatically controlled data multicasting across multiple compute engines
    CN117435855B (zh) * 2023-12-19 2024-03-19 北京壁仞科技开发有限公司 用于进行卷积运算的方法、电子设备和存储介质
    CN117785480B (zh) * 2024-02-07 2024-04-26 北京壁仞科技开发有限公司 处理器、归约计算方法及电子设备

    Citations (5)

    * Cited by examiner, † Cited by third party
    Publication number Priority date Publication date Assignee Title
    US7634621B1 (en) 2004-07-13 2009-12-15 Nvidia Corporation Register file allocation
    US8555035B1 (en) 2010-07-07 2013-10-08 Nvidia Corporation Conflict-free register allocation using a multi-bank register file with input operand alignment
    US20180322078A1 (en) 2017-05-04 2018-11-08 Nvidia Corporation Unified cache for diverse memory traffic
    US11080051B2 (en) 2019-10-29 2021-08-03 Nvidia Corporation Techniques for efficiently transferring data to a processor
    US11554552B2 (en) 2019-09-13 2023-01-17 Desktop Metal, Inc. Method for forming 3D printed objects with multi-layer rafts which optimize shrinkage

    Family Cites Families (9)

    * Cited by examiner, † Cited by third party
    Publication number Priority date Publication date Assignee Title
    US6816982B2 (en) * 2001-03-13 2004-11-09 Gonen Ravid Method of and apparatus for computer hard disk drive protection and recovery
    US7844801B2 (en) * 2003-07-31 2010-11-30 Intel Corporation Method and apparatus for affinity-guided speculative helper threads in chip multiprocessors
    US7478197B2 (en) * 2006-07-18 2009-01-13 International Business Machines Corporation Adaptive mechanisms for supplying volatile data copies in multiprocessor systems
    US7827357B2 (en) * 2007-07-31 2010-11-02 Intel Corporation Providing an inclusive shared cache among multiple core-cache clusters
    US8826270B1 (en) * 2010-03-16 2014-09-02 Amazon Technologies, Inc. Regulating memory bandwidth via CPU scheduling
    US10789544B2 (en) * 2016-04-05 2020-09-29 Google Llc Batching inputs to a machine learning model
    US10901639B2 (en) * 2016-11-29 2021-01-26 Sap Se Memory allocation in multi-core processors
    US10810142B2 (en) * 2017-05-15 2020-10-20 Xilinx, Inc. Adaptive scheduling of memory requests
    US11947835B2 (en) * 2021-09-21 2024-04-02 Black Sesame Technologies Inc. High-performance on-chip memory controller

    Patent Citations (5)

    * Cited by examiner, † Cited by third party
    Publication number Priority date Publication date Assignee Title
    US7634621B1 (en) 2004-07-13 2009-12-15 Nvidia Corporation Register file allocation
    US8555035B1 (en) 2010-07-07 2013-10-08 Nvidia Corporation Conflict-free register allocation using a multi-bank register file with input operand alignment
    US20180322078A1 (en) 2017-05-04 2018-11-08 Nvidia Corporation Unified cache for diverse memory traffic
    US11554552B2 (en) 2019-09-13 2023-01-17 Desktop Metal, Inc. Method for forming 3D printed objects with multi-layer rafts which optimize shrinkage
    US11080051B2 (en) 2019-10-29 2021-08-03 Nvidia Corporation Techniques for efficiently transferring data to a processor

    Also Published As

    Publication number Publication date
    US20230289292A1 (en) 2023-09-14
    CN116775518A (zh) 2023-09-19

    Similar Documents

    Publication Publication Date Title
    DE102021118444A1 (de) Einrichtung und Verfahren zum Komprimieren von Strahlverfolgungsbeschleunigungsstrukturaufbaudaten
    DE102019133028A1 (de) Für neuronale netzwerke geeignetes effizientes matrixformat
    DE102021120605A1 (de) Effiziente softmax-berechnung
    DE102023105565A1 (de) VERFAHREN UND VORRICHTUNG FÜR EFFIZIENTEN ZUGRIFF AUF MEHRDIMENSIONALE DATENSTRUKTUREN UND/ODER ANDERE GROßE DATENBLÖCKE
    DE102020129970A1 (de) Systeme und verfahren zur fehlererkennung und steuerung für eingebettete arbeitsspeicher- und rechenelemente
    DE102021114012A1 (de) Intelligente flüssigkeitsgekühlte computer- pods für ein mobiles rechenzentrum
    US20200327417A1 (en) Ir drop prediction with maximum convolutional neural network
    DE102020107080A1 (de) Grafiksysteme und Verfahren zum Beschleunigen von Synchronisation mittels feinkörniger Abhängigkeitsprüfung und Planungsoptimierungen basierend auf verfügbarem gemeinsam genutztem Speicherplatz
    DE102021102589A1 (de) Berechnungsgraph-optimierung
    DE102020132544A1 (de) Vorrichtung und verfahren für doppelpräzisionsstrahlquerung in einer raytracing-pipeline
    DE102020132377A1 (de) Vorrichtung und Verfahren zur Drosselung einer Raytracing-Pipeline
    DE112021002221T5 (de) Intelligentes testen von kühlsystemen in rechenzentren auf serverebene
    DE112020004781T5 (de) Kernel-fusion für maschinelles lernen
    DE102020118860A1 (de) Techniken zum vorladen von texturen beim rendering von graphik
    DE102020121601A1 (de) Persistenter Notizblockspeicher zum Datenaustausch zwischen Programmen
    DE102019134020A1 (de) Dekompprimierungstechniken zur verarbeitung komprimierter daten, die für künstliche neuronale netzwerke geeignet sind
    DE112020000865T5 (de) Speicherverwaltungssystem
    DE102020127704A1 (de) Techniken zum effizienten transferieren von daten an einem prozessor
    DE102022124599A1 (de) Vorrichtung und verfahren zur baumstrukturdatenreduzierung
    DE102021111335A1 (de) Techniken zum dynamischen komprimieren von speicherregionen, die einen einheitlichen wert haben
    DE102023105577A1 (de) Verfahren und Vorrichtung zum effizienten Zugriff auf mehrdimensionale Datenstrukturen und/oder andere große Datenblöcke
    DE102021102746A1 (de) Lese/schreib-seitenreplikation für mehrere recheneinheiten
    DE102019102825A1 (de) Kohärentes Caching von Daten für Skalierung mit hoher Bandbreite
    DE102021116364A1 (de) Vorrichtung und verfahren für strahlverfolgungs-detaillierungsgradübergänge von hoher qualität
    DE102021113178A1 (de) Techniken für zugriff auf komprimierte daten und ihre statusinformationen sowie nutzung der daten und statusinformationen

    Legal Events

    Date Code Title Description
    R012 Request for examination validly filed