DE102023105577A1 - Verfahren und Vorrichtung zum effizienten Zugriff auf mehrdimensionale Datenstrukturen und/oder andere große Datenblöcke - Google Patents

Verfahren und Vorrichtung zum effizienten Zugriff auf mehrdimensionale Datenstrukturen und/oder andere große Datenblöcke Download PDF

Info

Publication number
DE102023105577A1
DE102023105577A1 DE102023105577.1A DE102023105577A DE102023105577A1 DE 102023105577 A1 DE102023105577 A1 DE 102023105577A1 DE 102023105577 A DE102023105577 A DE 102023105577A DE 102023105577 A1 DE102023105577 A1 DE 102023105577A1
Authority
DE
Germany
Prior art keywords
memory
tensor
processor
memory access
data
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
DE102023105577.1A
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 DE102023105577A1 publication Critical patent/DE102023105577A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14—Handling requests for interconnection or transfer
    • G06F13/16—Handling requests for interconnection or transfer for access to memory bus
    • G06F13/1605—Handling requests for interconnection or transfer for access to memory bus based on arbitration
    • G06F13/1652—Handling requests for interconnection or transfer for access to memory bus based on arbitration in a multiprocessor architecture
    • G06F13/1663—Access to shared memory
    • 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/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
    • 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/0862—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches with prefetch
    • 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/0464—Convolutional networks [CNN, ConvNet]
    • 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
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T1/00—General purpose image data processing
    • G06T1/60—Memory management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/10—Providing a specific technical effect
    • G06F2212/1016—Performance improvement
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/45—Caching of specific data in cache memory
    • G06F2212/454—Vector or matrix data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/45—Caching of specific data in cache memory
    • G06F2212/455—Image or video data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/60—Details of cache memory
    • G06F2212/6028—Prefetching based on hints or prefetch instructions
    • 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]

Abstract

Eine parallele Verarbeitungseinheit umfasst eine Vielzahl von Prozessoren, die jeweils mit einer Speicherzugriffs-Hardwareschaltung gekoppelt sind. Jede Speicherzugriffs-Hardwareschaltung ist so konfiguriert, dass sie von dem gekoppelten Prozessor eine Speicherzugriffsanforderung empfängt, 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 als Antwort auf die Speicherzugriffsanforderung die Koordinate der mehrdimensionalen Datenstruktur in mehrere Speicheradressen für die mehrdimensionale Datenstruktur übersetzt und unter Verwendung der mehreren Speicheradressen zumindest einen Teil der mehrdimensionalen Datenstruktur zum Verarbeiten durch zumindest den gekoppelten Prozessor asynchron transferiert. Die Speicherorte können sich in dem gemeinsam genutzten Speicher des gekoppelten Prozessors und/oder in einem externen Speicher befinden.

Description

  • Bereich
  • Diese Technologie bezieht sich allgemein auf die Verbesserung der Effizienz zum Verarbeiten und die Verringerung des Stromverbrauchs von Prozessoren. Insbesondere bezieht sich die vorliegende Technologie auf spezialisierte Schaltungen zur Handhabung von Speicherzugriffen auf Datenblöcke durch einen Parallelprozessor.
  • Hintergrund
  • Massiv parallele Hochleistungs-Rechnersysteme - Systeme, die viele parallel operierende Verarbeitungskerne 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 häufig zusammen mit dem/den Verarbeitungskern(en), den/die er bedient, auf dem Chip. 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-Patentanmeldungen: Applikation Nr. 11/554,552 mit dem Titel „Gemeinsam genutzter Speicher für gleichzeitige Threads in einem Multithreading-Prozessorkern“, eingereicht am 30. Oktober 2006. Dieser Speicher wird von verschiedenen Verarbeitungskernen gemeinsam genutzt, um ihnen die Synchronisation und Kommunikation zu ermöglichen sowie die Datenlokalität und die Datenwiederverwendung 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 Cache-Zeile bzw. in 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 Datentransferierungen, die für bestimmte gängige Transaktionen wie Matrixmultiplikationen erforderlich sind, eine große Anzahl von Registern über einen längeren und oft unbestimmten Zeitraum hinweg 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. Ein solcher Registerstau 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 Latenzzeit, 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 Zu- und Abgreifen von Daten aus dem gemeinsam genutzten Speicher erwünscht, um die Anforderungen an den Speicherzugriff effizienter zu verwalten und die Gesamteffizienz der Datenverarbeitung zu steigern, während gleichzeitig ein höherer mathematischer Durchsatz in Bereichen wie künstliche Intelligenz (AI), Deep Learning (DL) und anderen Applikationen erreicht wird, 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, die eine parallele Verarbeitungseinheit umfasst, in der jeder Streaming-Multiprozessor mit einer Tensor-Speicherzugriffseinheit („TMAU“) gekoppelt ist, die spezialisierte Hardwareschaltungen für Speicheradressberechnungen und das Bewegen von mehrdimensionalen Datenstrukturen oder Datenblöcken in/aus verschiedenen Speichertypen bereitstellt, gemäß einigen Ausführungsbeispielen.
    • 2 zeigt Wechselwirkungen zwischen einem Streaming-Multiprozessor, der mit dem Streaming-Multiprozessor gekoppelten Tensor-Speicherzugriffseinheit, dem externen Speicher und dem gemeinsam genutzten lokalen Speicher des Streaming-Multiprozessors beim Laden eines Datenblocks aus dem externen Speicher in den gemeinsam genutzten Speicher, gemäß einigen Ausführungsbeispielen.
    • Die 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 gemäß einigen Ausführungsbeispielen von der Tensor-Speicherzugriffseinheit zugegriffen wird.
    • Die 4A und 4B (zusammen 4) zeigen Out-Of-Bound-Bedingungen (engl. out-of-bounds conditions, dt. auch Grenzüberschreitungszustände), 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 Beispiel-Deskriptoren, die für den Zugriff auf Daten verwendet werden, gemäß einigen Ausführungsbeispielen.
    • 6 ist eine schematische Darstellung einer Pipeline zum Verarbeiten von Speicherzugriffsanforderungen in der Tensor-Speicherzugriffseinheit gemäß einigen beispielhaften Ausführungsbeispielen.
    • 7A zeigt Ausführungsbeispiele für Parameter, die das Lesen von Tensor-Daten durch eine Tensor-Speicherzugriffseinheit beeinflussen, gemäß einigen Ausführungsbeispielen.
    • 7B zeigt ein Beispiel für High-Level-Pseudocode zum Verarbeiten durch die Tensor-Speicherzugriffseinheit, gemäß einigen Ausführungsbeispielen.
    • 7C zeigt ein Beispiel für einen High-Level-Pseudocode, der einen Streaming-Multiprozessor zeigt, der die TMAU zum Laden und Speichern von Tensor-Daten für GEMM-Berechnungen (Allgemeine Matrix-Multiplikationen) verwendet.
    • Die 8A-8K (zusammenfassend 8) zeigen die Verwendung von beispielhaften Datenlademodi, insbesondere des Kachelmodus und des Bild-zu-Spalte-Modus, gemäß einigen Ausführungsbeispielen.
    • Die 9A-9D (zusammenfassend 9) zeigen Beispiele für die Datenumwandlung, die von der Tensor-Speicherzugriffseinheit gehandhabt werden kann, gemäß einigen Ausführungsbeispielen.
    • 10 zeigt eine beispielhafte parallele Verarbeitungseinheit eines Grafikprozessors, gemäß einigen Ausführungsbeispielen.
    • 11A zeigt ein beispielhaftes allgemeines Verarbeitungscluster (GPC) innerhalb der parallelen Verarbeitungseinheit von 10, wobei jeder Streaming-Multiprozessor in dem allgemeinen Verarbeitungscluster mit einer Tensor-Speicherzugriffseinheit gekoppelt ist, gemäß einigen Ausführungsbeispielen.
    • 11B zeigt eine beispielhafte Partitionseinheit der parallelen Verarbeitungseinheit von 10.
    • 12 zeigt einen beispielhaften Streaming-Multiprozessor aus 11A.
    • 13A ist ein beispielhaftes Konzeptdiagramm eines Verarbeitungssystems, das unter Verwendung der parallelen Verarbeitungseinheit (PPU) von 10 implementiert ist.
    • 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 beispielhafte, nicht einschränkende Technologie stellt Streaming-Multiprozessoren (SMs) oder andere parallele Verarbeitungskerne 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 dem 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 im Zusammenhang mit Adressberechnungen in DL-Kernen können auf den Bandbreitenverbrauch der Registerdatei (RF), zusätzliche RF-Kapazitätsanforderungen, die Behandlung von Out-of-Bound-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, Kernel für verschiedene Kachelgrößen anzupassen, und ähnliches verbraucht. Die mit einem Kernel assoziierte Komplexität der Adressberechnung kann sowohl die funktionale Korrektheit als auch die Leistungsoptimierung des Kernels beeinträchtigen.
  • Um die skizzierten Probleme anzugehen, 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 bei der 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 Mechanismen zum Transferieren von Daten bereitzustellen, um große Datenmengen zwischen Speicherorten, wie z. B. einem globalen Speicherort und einem gemeinsam genutzten Speicherort, zu bewegen. Die TMAU ermöglicht es den SM(s), effizienter zu 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 Anforderungen für wesentlich größere Datenblöcke oder andere Datenstrukturen akzeptiert. Durch eine einzige Anforderung an die TMAU können mehrere Kilobyte oder Megabyte an Daten transferiert werden, die dann von den SMs verwendet werden können. Auch wenn die Anforderung 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 SM-Kern-Matheeinheiten mit schnelleren Datenraten versorgen als Techniken, die sich auf die 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 für das Transferieren von Datenblöcken bereit, die zu einer Verringerung des Overheads für das Transferieren von Daten und den Zugriff auf den Speicher führen. Das reduzierte Transferieren von Daten und der reduzierte Speicherzugriff können zu einem deutlich reduzierten Energieverbrauch bei Multiprozessoren (z.B. auf SM-Ebene) und zu einer verbesserten Effizienz der Verarbeitung führen.
  • Nehmen wir als Analogie einen Küchenchef, 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 auch 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, 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 Anweisung LDGSTS 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 müssen jedoch für die Verschiebung großer Datenblöcke zahlreiche komplexe Adressberechnungen vom SM durchgeführt werden, bevor es Speicherzugriffsanforderungen an das Speichersystem stellen kann. Die TMAU ermöglicht es dem SM im Gegensatz zu der von ihm ausgeführten Anweisung LDGSTS, 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 Anforderung zum 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 ein bestimmtes SM kann es der TMAU ermöglichen, Speicherzugriffsanforderungen effizienter und mit weniger Konflikten zu bedienen, als wenn sie Anforderungen von mehreren Prozessoren bedienen 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 Speicher, der sich lokal auf dem ersten SM befindet, in einen gemeinsam genutzten 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 eines Tensors liegen. In einigen Ausführungsbeispielen kann die TMAU im Gegensatz zu Techniken, bei denen jeder Thread auf einer SM ein Datenquantum aus dem globalen Speicher lädt, Daten für eine beliebige Anzahl oder Gruppe von Threads in der 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 eine einzelne TMAU mehrere SMs bedienen, wobei jede SM unabhängige Anforderungen an die einzelne 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 Anforderungen, indem sie Daten in die gemeinsam genutzten lokalen Speicher der jeweiligen anfordernden SMs transferiert.
  • Parallelverarbeitungssystem, das TMAU-Schaltungen umfasst
  • 1 zeigt schematisch eine parallele Verarbeitungseinheit, 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 Multicore-Prozessoren, beispielsweise 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 einer SM hat Zugriff auf die Registerdatei 106 für diese SM, einen L1-Cache 108 und einen gemeinsam genutzten/lokalen Speicher 110 für diese 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 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ührungsstrang) 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 wird. 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 Single-Instruction-Multiple-Thread (SIMT)-Techniken verwendet, um die parallele Ausführung einer großen Anzahl von im Allgemeinen synchronisierten Threads zu unterstützen, wobei eine gemeinsame Anweisungseinheit 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 Netzwerk von Verbindungen 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 zum Speichern 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 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 dem L1-Cache gegenüber dem gemeinsam genutzten Speicher zugewiesen wird. 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. Patentanmeldungsveröffentlichung 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. Jedes 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 Anforderungen 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 gemeinsam genutzter verteilter 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-Applikation 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 der Kernel von Applikationsprogrammen 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 multidimensionale 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 Zugriffsparameter, die vom SM an die TMAU bereitgestellt werden müssen, kann sich basierend darauf unterscheiden, ob es sich bei dem angeforderten Datenblock um einen Tensor handelt 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 Ort-Koordinate und eine gemeinsam genutzte Speicheradresse.
  • In manchen Instanzen kann die Anforderung des SM Daten anfordern, die größer sind als die, die mit einer einzigen Lade-/Speicheranforderung aus dem globalen Speicher 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 anfordernden SM 102 und generiert bei Operation 206 die mehrfachen Speicherzugriffsanforderungen, jede mit einer jeweils unterschiedlichen Adresse für einen entsprechenden Teilblock in den 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 anfordernden SM 102 und des Status der Abschließung der Datenanforderung bereitstellen. Zum Beispiel kann bei jedem Teilblock, 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 Teilblockanforderung 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, die den Zähler zur Synchronisation überwacht.
  • Zwischen dem Ausstellen der Speicherzugriffsanforderung für die Daten bei Operation 206 und der anschließenden Synchronisation mit den in den gemeinsam genutzten Speicher geschriebenen Daten bei Operation 214 können viele Taktsignale vergehen. Insbesondere bei Anforderungen 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 Anweisungen zum Verarbeiten 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 erforderlich sind, um eine große Datenmenge einer Datenstruktur oder eines Blocks zu erhalten, 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 Unterblock und gibt eine entsprechende Anweisung direkt an den globalen Speicher (z.B. über L2 202) aus. Der SM muss sich dann selbst mit dem gemeinsam genutzten Speicher 110 für die jeweiligen Unterbblö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 zum Verarbeiten und auch für den Stromverbrauch. Im Gegensatz zu den LDGSTS-Anweisungen und anderen früheren Techniken ermöglichen die hier offenbarten 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 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 Unterblö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 von der 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.
  • Auf den Tensor 302 wird von der SM in Blöcken zugegriffen, 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 Stride (Schrittgröße) für jede Dimension und die Elementgröße im Tensor. 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 aufgefüllt (engl. padded) sein, wie der Bereich oberhalb und rechts des Tensors 302 innerhalb des aufgefüllten Tensors 304 zeigt. Das Padding (dt. auch Auffüllung, Polsterung) könnte durch Tensor-Strides 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 des Padding 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 Speicherzugriffsanforderungen an die TMAU gestellt werden, müssen die erforderlichen Parameter im 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 Tensor-Deskriptors aus dem globalen Speicher für jede neue TMAU-Anforderung 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 zweidimensionalen 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 dem Padding 314 in x-Richtung aufgefüllt. Somit umfasst der Tensor-Stride 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 Block, der aus dem Tensor 308, in diesem Beispiel ein zweidimensionaler Tensor, gelesen werden soll, an vielen verschiedenen Orten 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 Bedingung „out of bounds“ (außerhalb der Grenzen) 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 die Bedingungen, unter denen der angeforderte Block die Grenzen des Tensors im globalen Speicher überschreiten kann, richtig handhaben. 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)) gesetzt 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 Filterorte außerhalb des Bildes liegen können.
  • Bei komplizierteren Applikationen müssen die Elemente, die außerhalb des Tensors liegen, möglicherweise mit einer speziellen Konstante 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 der TMAU so programmiert werden, dass er eine spezielle Nicht-eine-Zahl-Konstante (NaN) zuweist und erkennt, um die Out-of-Bound-Zugriffe 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 Verzerrung 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. Nr. 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-Parameter in einer Ausführungsform die Tensor-Höhe, die Tensor-Breite, den Tensor-Stride und die Elementgröße. Der Tensor-Stride repräsentiert die Tensorgröße (Höhe oder Breite) plus die Auffüllung in einer bestimmten Dimension. Die Parameter für den Zugriffs-Deskriptor umfassen die Blockhöhe, die Blockbreite und den Wert außerhalb der Grenze. Tensorhöhe, Tensorbreite, Tensor-Stride, Blockhöhe und Blockbreite werden pro Dimension des Tensors spezifiziert. Wie in 5B gezeigt, 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 wird gezeigt, dass TMAU 612 in SM 602 umfasst ist. 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 Anforderungen der TMAU 612 bereit. Die TMAU 612 empfängt Speicherzugriffsanforderungen, die von der 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 (Prefetch) 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 für Tensor-Daten verarbeiten, und in einigen anderen Ausführungsbeispielen kann sie nur Anforderungen für 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 Anforderungen 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 Fehler), 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 die Anforderung einen Tensor betrifft. 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 Anforderung 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 für das Generieren von Anforderungen bereit, wodurch die Latenzzeit verringert wird.
  • Der Anforderunggenerator 616 ist die wichtigste TMAU-Engine. Für eine Anforderung von Tensor-Daten empfängt er die relevanten Parameter vom Setup-Block und durchläuft den Tensor-Raum durch Iteration mehrdimensionaler Koordinaten, Zuordnen von Koordinaten zu Adressen, Prüfen von Out-of-Bound-Bedingungen, Berechnen gemeinsam genutzter Speicheradressen, Berechnen globaler Speicheradressen und Generieren von Anforderungen an das Speicher-Subsystem. 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 Zugriffsanforderungen 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 das asynchrone Verarbeiten mit dem SM. 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 von SM empfangene Speicherzugriffsanforderung für Blockdaten gilt, die kein Tensor sind, kann die Anforderung in einigen Ausführungsbeispielen an den Anforderungsgenerator 616 unter Umgehung des Deskriptor-Caches 608 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 Teilblock des angeforderten Blocks betrifft. Der Anforderungsgenerator berechnet die globalen Speicheradressen für die Unterblöcke basierend auf der globalen Speicheradresse für den Block, wie sie in der vom SM empfangenen Anforderung umfasst ist, und die Größe des Unterblocks kann entsprechend der maximalen Größe der vom Speicher-Subsystem behandelten Anforderungen bestimmt werden. Die Schaltung 618 zur Verfolgung des Abschlusses von Anforderungen verfolgt die Speicheranforderungen für die Teilblöcke und die vom Speichersubsystem empfangenen Antworten auf dieselbe Weise, wie oben in Bezug auf Tensor-Datenblöcke beschrieben.
  • 7A und 7B zeigen Beispielparameter, mit denen ein in 7A dargestellter Block 704 verfolgt wird, wenn eine Tensor-Daten-Struktur 702 von der Schaltung der TMAU gelesen wird. 7A zeigt Beispiele von Parametern, die ein Anker-, Basis- und aktuelles Element umfassen, die in dem in 7B gezeigten High-Level-Pseudocode für einen Teil der in der Hardware des 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 anschließend 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 das Empfangen 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 inkrementiert wird 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 werden und kann 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 Tensor-Stride erhöht („baseGlobalAddr[1] += tensorDescriptor.tensorStride[0]“). Dadurch wird die globale Adresse auf den nächsten Abschnitt vorgerückt. Die globale Basisadresse für jede Dimension wird initial 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 Verarbeitungen zum Kopieren von Datenblöcken aus einem Tensor in den globalen Speicher in Hardware durchführt, kann sie die Rechenlast des SM für die Datenbewegung erheblich reduzieren und so die Verarbeitungseffizienz des SM erhöhen und auch den Stromverbrauch des SM verringern.
  • Der obige Pseudocode in 7B stellt eine High-Level-Ausführungslogik bereit und lässt Details im Zusammenhang mit bestimmten Aspekten aus, wie z. B. die effiziente Generierung von L2-Anforderungen, das Swizzling und die Behandlung von Out-of-Bound-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 erhöht. 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. Das SM kann eine Synchronisationsschaltung umfassen, die den/die Zähler überwacht und basierend auf dem Zähler eine Synchronisationsbarriere oder ähnliches implementiert.
  • 7C zeigt einen Beispielpseudocode 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, ist 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 Ausgabetensor können in der GEMM-Berechnung als die Matrizen A, B bzw. C repräsentiert werden. Der Kernel stellt dem TMAU die Zeiger auf die Tensor-Deskriptoren für den Aktivierungs-Tensor, den Gewichts-Tensor und den Ausgabe-Tensor bereit, wenn er eine nachfolgende Speicherzugriffsanforderung (tensorBlockLoad()) an den TMAU ausgibt.
  • 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 stellt der Kernel eine entsprechende tensorBlockLoad-Anforderung an die gekoppelte TMAU, um jeweils einen Block aus dem Aktivierungstensor und dem Gewichtstensor zu laden. Die tensorBlockLoad-Anforderung erhä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 (C-Dimension) und jeden r- und s-Ort 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 (computeGEMM()). 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 (tensorBlockStore()) ausgibt und die Adressen für die Ausgabematrix, 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 TMAU eine Bild-Spalten-Transformation durch, wenn es 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 (dt. auch Begrenzungsbox, -rahmen) im Tensorraum, die alle Elemente enthält, die der 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 des SM spezifizierten Koordinaten definieren eindeutig den Ort der BoundingBox im Tensorraum.
  • Im im2col-Modus sind die Größe und der Ort 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 den Ort der BoundingBox im DHW-Raum (Depth, Height, Width). Der Parameter boxBaseCornerDHW spezifiziert die initialen Koordinaten des BoundingBox-Ursprungs, der die linke obere Ecke der Box ist. boxFarCornerDHW spezifiziert den initialen Ort der gegenüberliegenden rechten unteren Ecke. Die Orte der Ecken sind als vorzeichenbehaftete Offsets von den entsprechenden Tensorecken definiert. Daher können die Ecken der Bounding-Box sowohl innerhalb als auch außerhalb der Tensorgrenzen spezifiziert werden.
  • Die Orte der Ecken der Bounding-Box 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.
  • Die boxBaseCornerDHW und boxFarCornerDHW definieren die 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 der TMAU eine bestimmte Dimension durchläuft, verwendet er 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-Anforderung 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, kann es Kanäle überspringen, die außerhalb des durch den Parameter rangeC definierten Bereichs liegen.
  • Im Kachelmodus spezifizieren die von TMAU angeforderten Koordinaten den Ort der BoundingBox (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 den Ort des Faltungsfilters (linke obere Ecke) im Tensorraum. Zum korrekten Verarbeiten verlangt die TMAU, dass der Ort, auf dem der Filter basiert, immer innerhalb der BoundingBox definiert ist. Darüber hinaus müssen in der TMAU-Anforderung Koordinatenoffsets für diese Dimensionen spezifiziert werden. Mit den Offsets kann die Position des Blocks relativ zum Tensor spezifiziert werden, so dass nur eine minimale Anzahl von Bytes verwendet wird. Die Offsets werden zu den auf dem Filter basierenden Ortskoordinaten addiert, um die Startorte 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 Anforderungen für denselben Ort der Filterbasis gestellt.
  • 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 ein Beispiel für Pseudocode auf hohem Niveau für die im TMAU implementierte Logik, insbesondere im Setup-Block, um den Tensor und die Zugriffsparameter basierend auf dem in einer empfangenen TMAU-Anforderung identifizierten Tensor-Deskriptor zu konfigurieren:
    Figure DE102023105577A1_0001
    Figure DE102023105577A1_0002
  • 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 C.
  • Im ersten Beispiel, das in 8B gezeigt wird, kann der Filter über die Tensorgrenze hinausgehen und auf die umgebende Füllung (Rand) zugreifen, die als Null oder konstanter Wert definiert sein 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 Anforderungen 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 Ort, an dem der Block zum Laden der Anforderung beginnt. Die TMAU weiß, dass sie Tensorelemente ab dem spezifizierten Ort plus Offsets innerhalb des dargestellten Rechtecks laden und eine bestimmte Datenmenge laden muss.
  • Im nächsten Beispiel ist der Filter so konfiguriert, dass er innerhalb der TensorGrenzen bleiben muss und daher kein Padding/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 in alle Filterorte 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 Füllung (Rand) zugreifen, die als Null 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 jeden gegebenen Filterort wird nur eine 8x8-Kachel für die 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 Konstante (Padding) zuzugreifen. Es werden die 8x8 Kacheln gezeigt, die zum Verarbeiten verschiedener Filterorte verwendet werden: (0, 0), (1, 1), (2, 2).
  • Das folgende Beispiel ähnelt dem vorherigen, aber der Filter muss innerhalb der Tensorgrenzen bleiben, und es sind keine Auffüllungen/Ränder erlaubt. Eine einzelne TMAU-Anforderung 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 jeden gegebenen Filterort wird eine 6x6-Kachel für die 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 das Verarbeiten der 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 Filterorte 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 Orte des Tensors, wodurch sich die Gesamtzahl der geladenen Elemente verringert. 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 beeinflusst, basierend auf der Formel ceil(boundingB ox {D,H, W} / traversal Str ide {D ,H, W}).
  • 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, aber nicht 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 die 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 Orte des Faltungsfilters 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 großer 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 den Ort 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 Orte des Faltungsfilters 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 einzelne Anforderung 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 jeden gegebenen Filterort wird nur eine 8x8-Kachel für die 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 (Padding) zuzugreifen. Es werden 8x8 Kacheln gezeigt, die zum Verarbeiten verschiedener Filterorte verwendet werden: (0, 0), (2, 2), (4, 4).
  • Unterstützung für Tensor-Daten 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 Nicht-Swizzle-Modus, bei dem die Daten in der gleichen Anordnung wie im globalen Speicher in den gemeinsam genutzten Speicher geschrieben werden, und einen Swizzle-Modus, bei dem die Daten gemäß einem vorgegebenen oder konfigurierbaren Swizzle-Muster in den gemeinsam genutzten Speicher geschrieben werden, das zu einer anderen Anordnung der Daten als im globalen Speicher führt. Zum Verarbeiten einer Speicherzugriffsanforderung kann die TMAU mehrere externe Speicheranforderungen generieren und für jede der generierten externen Speicheranforderungen eine entsprechende Zieladresse und ein Swizzle-Muster für den gemeinsam genutzten Speicher generieren. In Implementierungen können zwei Optionen für die Verfolgung der Zieladressen und Swizzle-Muster verwendet werden - entweder werden alle Informationen mit der Anforderung und der Antwort über das Speichersystem gesendet, oder die Informationen werden in einer Verfolgungstabelle in der SM gespeichert und der entsprechende Index in dieser Tabelle mit der Anforderung und der Antwort über das Speichersystem gesendet. In beiden Fällen kann die Antwort des Speichersystems diese Informationen verwenden, um die Adresse und das Muster zum Schreiben der Daten in den gemeinsam genutzten Speicher 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önnten 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 basierend auf vordefinierten Mustern den gemeinsam genutzten Speicherbankgruppen und -untergruppen zugeordnet, um Bankkonflikte sowohl beim Lesen als auch beim Schreiben zu vermeiden. Die TMAU unterstützt mehrere Muster basierend auf den spezifischen Tensor-Layouts. Der Datenkonsument wiederum muss sich dieser Muster bewusst sein und entsprechend auf die Daten zugreifen.
  • In einigen Ausführungsbeispielen kann die TMAU Daten, die in einen gemeinsam genutzten Speicher geladen werden, der in Form von Zeilen organisiert ist, durcheinander bringen. 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 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 handelt sich um einen 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 Beispiel-Bankzuweisungstabelle für einen Swizzle_128B-Modus dargestellt.
  • 9B-9D zeigen ein Beispiel für Datenlayouts in globalen und gemeinsam genutzten Speichern für den Swizzle_128B-Modus gemäß der Bankzuweisungstabelle 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 Hatch-Mustern 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 swizzle_128B - Modus geswizzled. Rechts in 9D ist die Datenansicht aus der Sicht der GMMA-Applikation für den Filterort R=0, S=-0 dargestellt. Der GMMA muss das Bank-Swizzling wahrnehmen und sich bemühen, die richtigen Daten in 16 8x8-Kacheln einzuspeisen.
  • Das Swizzling berücksichtigt Implementierungen, 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 anschließenden 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 Schraffur-Muster Daten, die gemäß dem Swizzle-Muster für den Tensor 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 bei W=0, wobei die Pfeile die Orte 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 werden in der zweiten Spalte von rechts die 8x8 Kacheln für jedes H bei W=1 gezeigt, wobei die Pfeile die Orte 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 Swizzling 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 den 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 Rechen-Kernel, der auf einem SM läuft, eine Matrix-Matrix-Multiplikation erforderlich ist, kann der Kernel 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. Als Antwort darauf kann GMMA seine Multiplikation unter Verwendung der Daten durchführen, die von der TMAU in den gemeinsam genutzten Speicher geladen wurden. Wird das Swizzle-Muster verwendet, kann der Kernel die Daten im gemeinsam genutzten Speicher gemäß den Swizzle-Muster-Informationen lesen, die Berechnung durchführen und die Ergebnisse dann in den gemeinsam genutzten Speicher zurückschreiben. Das Zischen 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 gezeigt, 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, wie in 9D gezeigt, im gemeinsam genutzten Speicher geswizled werden, können alle Kanäle 0-63 für acht Positionen, die R=0, S=0 umfassen, 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.) erfordert der Filter eine Matrixmultiplikation, die 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 einzige TMAU eine Ladeanforderung generiert, die Daten jedoch an mehrere Ziele (z.B. SMs) geliefert werden. Als Antwort auf eine Ladeanforderung von einem Kernel, der auf einem ersten SM ausgeführt wird, fordert die mit dem ersten SM gekoppelte TMAU beispielsweise einen Block von Tensor-Daten oder anderen Daten aus dem globalen Speicher an und schreibt diese nicht nur in den gemeinsam genutzten Speicher des ersten SM (in einigen Ausführungsbeispielen ist es nicht erforderlich, dass der anfordernde SM die angeforderten Daten empfängt), sondern auch in die gemeinsam genutzten Speicher eines oder mehrerer anderer SMs. Um dies zu unterstützen, wird dem anfordernden TMAU die Liste der empfangenden 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 Ort der Ankunfts-/Warte-Struktur 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.
  • Zur Unterstützung des Vorkaufsrechts 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 muss die anfordernde TMAU jedoch 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 an die anfordernde TMAU weiterleiten. Die anfordernde 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. Anmeldung Nr. 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.
  • Vorladungsunterstützung
  • Zusätzlich zum Laden von Tensor-Daten unterstützt die TMAU das Vorladen von Daten aus dem globalen DRAM-Speicher in den L2-Cache. 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 Vorlade-Anforderungen ist ähnlich wie bei anderen Ladevorgängen, ohne dass die TMAU irgendeinen Typ von Abschlussverfolgung oder Ähnlichem durchführen muss. Bei Tensor-Daten ähnelt die Handhabung von Vorlade-Anforderungen in gewisser Weise dem Ladevorgang, bei dem Tensor-Deskriptor und Koordinaten festlegen, wie die Anforderung zu verarbeiten ist. In Bezug auf Vorlade Anforderungen für Tensor-Daten kann die TMAU jedoch nicht mit gemeinsam genutztem Speicher/globalen Alignment umgehen und Anforderungen auf Sektor- oder Cache-Zeilen-Granularität verarbeiten.
  • Speicher- und Reduktionsanforderungen
  • 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 verschachtelte Layouts unterstützen, und es können gemeinsam genutzte Speicherbank-Swizzle-Muster spezifiziert werden. Die Speicherung mit Traversalschritt kann unterstützt werden. In einigen Ausführungsbeispielen kann der Speichervorgang auch die Behandlung von Out-of-Bound-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 gemeinsamen Speichern. Die unterstützten Reduktionsoperationen können unter anderem AND, ADD, XOR, MIN, MAX, DEC, OR und INC umfassen.
  • Deskriptorlose Abfragen
  • 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 beispielsweise eine Standardblockgröße von 16B für TMAU-Operationen konfiguriert werden. Die Speicherzugriffsanforderung für einen Block von Nicht-Tensor-Daten 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 dedizierte Anweisungen für deskriptorloses Transferieren von Daten (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 Datenvorladeanforderungen von DRAM an 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. Der TMAU umfasst diese Adresse in jeder L2-Anforderung. Wenn die Daten am Ziel-SM ankommen, wird die Barrierestruktur entsprechend aktualisiert. Der TMAU selbst ist an der Aktualisierung der Barriere nicht beteiligt. Dieser Mechanismus kann sowohl für Unicast- als auch für Multicast-Anforderungen verwendet werden.
  • Darüber hinaus unterstützt der TMAU eine spezielle Anweisung, die dazu verwendet werden kann, den Abschluss aller zuvor ausgegebenen TMAU-Anforderungen zu detektieren.
  • Programmiermodell für die TMAU
  • Die TMAU ist dafür ausgelegt, große Blöcke von Tensor- 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-Anforderungen ist nicht gut mit der multithreaded 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 Iteration 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 den Ort des Blocks im Tensorraum durch Berechnen von 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-Befehle, sondern auch für den umgebenden Code, der die notwendigen Parameter für die Anweisungen generiert. Dieser Ansatz würde die Redundanz bei der Codeausführung beseitigen, Kapazität und Bandbreite der Registerdatei (RF) einsparen, Strom sparen und den Pfad für Vektordaten freigeben. Aufgrund des iterativen Charakters des TMAU-bezogenen Codes ist es wichtig, dass die iterierten Parameter in URF verbleiben. Jedes Laden/Speichern von URF/RF würde Leistungseinbußen 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 Anweisung Satz Architektur) 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;
            <Code-Block, der von einem einzelnen Thread ausgeführt wird>
  • Der Ausführungs-Thread wird aus dem Satz der aktiven 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 die Synchronisation aller Threads vor und nach der Ausführung des Code-Blocks veranlasst. Das vorgeschlagene Programmiermodell kann die Codeanalyse vereinfachen, die Möglichkeit bereitstellen, TMAU-bezogenen Code für die UDP-Ausführung zu generieren und relevante Daten im 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 gewünschte Funktionalität bereit:
    •          if (_one_sync(mask)) {
            <Code-Block, der von einem einzelnen Thread ausgeführt wird>
         } // kein 'eise' -Block
  • Der TMAU-basierte Zugriff wird in einigen Ausführungsbeispielen durch einen Satz von Funktionen implementiert. Vier Gruppen im C-Stil sind 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 Speicherzugriffsanforderung an die TMAU ausgeben, um einen Tensor zwischen dem globalen und dem gemeinsam genutzten Speicher zu kopieren, wobei die Anweisung zum Kopieren des Tensors in einer Form wie folgt erfolgt:
    •  copytensor.mode.dimensionality.destination,source{.multicast}{reductionop}
   descriptor coordinates 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, um Tensor-Daten in den L2-Cache vorzuladen, kann mit einer Tensor-Vorladeanweisung in einer Form wie dieser ausgegeben werden:
    •  prefetch_tensor.mode.dimensionality descriptor coordinates
   im2col_coordinate_offsets}
 wobei mode = {tiles, im2col} and dimensionality = {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 der folgenden ausgegeben werden:
    •  copy _block. destination,source {. multicast } {reduction_op} destination _address
 {barrier_addr} source_address multicast_destinations number_blocks
     wobei destination = {shared, global}, source = {shared, 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 Blockvorladeanweisung in einer Form wie dieser ausgegeben werden:
    •  prefetch_block address number _blocks.
  • Beispielhafte Parallelverarbeitungs-GPU-Architektur mit TMAU
  • Im Folgenden wird eine beispielhafte Architektur beschrieben, in die die in dieser Applikation offenbarte TMAU integriert ist. Die folgenden Informationen werden zur Veranschaulichung gezeigt und sollten nicht als Einschränkung verstanden werden. Jedes der folgenden Merkmale kann optional mit oder ohne den Ausschluss anderer beschriebener Merkmale integriert werden.
  • 10 zeigt gemäß einem Ausführungsbeispiel eine parallele Verarbeitungseinheit (PPU) 1000. 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 dazwischenliegende 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 so konfiguriert sind, dass sie die PPU 1000 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. Zum Beispiel können 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, wie 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 Beginn 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 Arbeitsverteilungseinheit 1025 gekoppelt, die so konfiguriert ist, dass sie Aufgaben zur Ausführung auf den GPCs 1050 verteilt. Die Arbeitsverteilungseinheit 1025 kann eine Anzahl von geplanten Aufgaben verfolgen, die von der Scheduler-Einheit 1020 empfangen wurden. In einem Ausführungsbeispiel verwaltet die Verteilungseinheit 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 für die 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 Verteilungseinheit 1025 kommuniziert mit dem einen oder mehreren GPCs 1050 über die XBar 370. Die XBar 1070 ist ein Netzwerk, das viele der Einheiten der PPU 1000 mit anderen Einheiten der PPU 1000 verbindet. Beispielsweise kann die XBar 1070 so konfiguriert sein, dass sie die Verteilungseinheit 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 Arbeitsverteilungseinheit 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 der separaten und unterschiedlichen Speichergeräte 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 sind 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 vollem Umfang 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 11A 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 Verteilungseinheit 1025 empfangenen Pakete an die entsprechenden logischen Einheiten innerhalb des GPC 1050 routet. Beispielsweise können einige Pakete an Hardwareeinheiten mit fester Funktion im PROP 1115 und/oder in der Raster-Engine 1125 geroutet werden, während andere Pakete an die 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 zu einer 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 zum Verarbeiten von Aufgaben konfiguriert ist, die durch eine Anzahl von Threads repräsentiert werden. Jeder SM 1140 ist Multi-Thread-fähig und so konfiguriert, dass er eine Vielzahl von Threads (z.B. 32 Threads) aus einer bestimmten Gruppe von Threads gleichzeitig ausführen kann. 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 einen anderen Satz von Daten basierend auf demselben Satz von Anweisungen 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 einen anderen Satz von Daten basierend auf demselben Satz von Anweisungen verarbeitet, wobei jedoch individuelle 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. Das 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 virtueller 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 physische 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 enthält die PPU 1000 U Speicherschnittstellen 1170, eine Speicherschnittstelle 1170 pro Paar von Partitionseinheiten 1080, wobei jedes Paar von 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) zum Schutz der Daten. 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 den 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 einen mit einem Pixelfragment assoziierten Ort von der Culling-Engine der Raster-Engine 1125 empfängt. Die Tiefe wird mit einer entsprechenden Tiefe in einem Tiefenpuffer für einen mit dem Fragment assoziierten Ort verglichen. Wenn das Fragment die Tiefenprüfung für den Ort der Probe 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 auch 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 dargestellt, 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 Netzwerk zur Verbindung 1280, einen gemeinsam genutzten Speicher/L1-Cache 1270.
  • Wie oben beschrieben, verteilt die Verteilungseinheit 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 Tasks von der Arbeitsplanungs-/Verteilungseinheit 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, Designflexibilität und Software-Wiederverwendung in Form von kollektiven gruppenweiten Funktionsschnittstellen zu ermöglichen.
  • Cooperative Groups ermöglicht es Programmierern, Gruppen von Threads explizit auf 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. In dem 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. 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 vollständig mit Pipelines arbeitende Verarbeitungseinheit mit 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.
  • Die Tensor-Kerne sind so konfiguriert, dass sie Matrixoperationen durchführen, und in einem Ausführungsbeispiel sind ein oder mehrere Tensor-Kerne in den Kernen 1250 umfasst. 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=AxB+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 Texturkarten (z.B. ein 2D Array von Texeln) aus dem Speicher 1004 laden und die Texturkarten abtasten, um abgetastete Texturwerte zur 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 Netzwerk 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 Netzwerk 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 den gemeinsam genutzten Speicherorten im gemeinsamen 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 mehrere SM gekoppelt sein. In Ausführungsbeispielen, in denen die TMAU 112 eng mit mehreren SMs gekoppelt ist, kann ein Arbiter Anforderungen 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 Kontext dieser Offenbarung bedeutet ein SM oder „Streaming-Multiprozessor“ einen Prozessor, der so aufgebaut ist, wie in USP 7,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, die auf dem SM ausgeführt werden.
  • Wenn sie zum parallelen Berechnen für allgemeine Zwecke konfiguriert sind, kann eine einfachere Konfiguration verwendet werden als bei der Grafikverarbeitung. Insbesondere werden die in 11 A gezeigten Grafikverarbeitungseinheiten mit festen Funktionen umgangen, wodurch ein wesentlich einfacheres Programmiermodell entsteht. In der Konfiguration des parallelen Berechnens für allgemeine Zwecke weist die Verteilungseinheit 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 Geräte zum Verarbeiten 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 Anmeldung offenbarten 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 13A eine bestimmte Anzahl von NVLink 1010- und Verbindungen 1002- 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 angeordnet sein, 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 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 können gehäuste Geräte 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 Verbindungen 1000 Gigabyte/Sekunde bereitstellen. 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 Anmeldung offenbarten Verfahren implementiert (z.B. die TMAU in den 1, 2, 6 oder 11A).
  • 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.
  • Weiter 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 (Digital Versatile Disk), ein Aufzeichnungsgerät oder einen USB-Flash-Speicher (Universal Serial Bus) 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 jedes anderen Typs von Logik annehmen.
  • 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, 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. [00213] Obwohl die Erfindung im Zusammenhang mit den derzeit besten und bevorzugtesten Ausführungsbeispielen beschrieben wurde, soll die Erfindung nicht auf die offenbarten Ausführungsbeispiele beschränkt sein, sondern im Gegenteil verschiedene Modifikationen und äquivalente Anordnungen umfassen, die in dem Verständnis 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 [0023]
    • US 8555035 B [0027]
    • US 7634621 B [0027]
    • US 20180322078 A [0030]
    • US 17/691690 [0031]
    • US 17497507 B [0050]
    • US 17691406 B [0070]
    • US 17691288 B [0117]

    Claims (27)

    1. Parallelprozessor, umfassend: eine Speicherschnittstelle; eine Vielzahl von Prozessoren; und eine Vielzahl von Speicherzugriffs-Hardwareschaltungen, wobei jede Speicherzugriffs-Hardwareschaltung mit einem Prozessor der Vielzahl von Prozessoren gekoppelt ist und konfiguriert ist, zum: Empfangen einer Speicherzugriffsanforderung für eine mehrdimensionale Datenstruktur von dem gekoppelten Prozessor, wobei die Speicherzugriffsanforderung eine Koordinate der mehrdimensionalen Datenstruktur spezifiziert, und als Antwort auf die Speicherzugriffsanforderung, Übersetzen zumindest der Koordinate der multidimensionalen Datenstruktur in mehrere Speicheradressen für die multidimensionale Datenstruktur und, unter Verwenden der mehreren Speicheradressen, asynchrones Transferieren zumindest eines Teils der multidimensionalen Datenstruktur.
    2. Parallelprozessor gemäß Anspruch 1, wobei der asynchrone Transfer von einem Ort in einem externen Speicher, auf den über die Speicherschnittstelle zugegriffen wird, zu einem anderen Ort in dem externen Speicher erfolgt.
    3. Parallelprozessor gemäß Anspruch 1 oder 2, wobei der asynchrone Transfer zwischen einem Ort in einem externen Speicher, auf den über die Speicherschnittstelle zugegriffen wird, und einem Ort in einem gemeinsam genutzten Speicher des gekoppelten Prozessors erfolgt.
    4. Parallelprozessor gemäß Anspruch 3, wobei die mit dem Prozessor gekoppelte Speicherzugriffs-Hardwareschaltung konfiguriert ist, zum Lesen von und Schreiben in einen gemeinsam genutzten Speicher des mit der Speicherzugriffs-Hardwareschaltung gekoppelten Prozessors.
    5. Parallelprozessor gemäß Anspruch 3 oder 4, wobei zumindest die Koordinate einen Ort eines Datenblocks innerhalb der im externen Speicher gespeicherten mehrdimensionalen Datenstruktur definiert.
    6. Parallelprozessor gemäß Anspruch 5, wobei die mit dem Prozessor gekoppelte Speicherzugriffs-Hardwareschaltung weiter konfiguriert ist, zum Durchführen der Übersetzung durch Erhalten einer Basisadresse der mehrdimensionalen Datenstruktur aus einem zuvor gespeicherten Deskriptor für die mehrdimensionale Datenstruktur.
    7. Parallelprozessor gemäß Anspruch 5 oder 6, wobei die mit dem Prozessor gekoppelte Speicherzugriffs-Hardwareschaltung eine Setup-Schaltung umfasst, die konfiguriert ist, zum Vorladen des zuvor gespeicherten Deskriptors aus dem externen Speicher in einen Deskriptor-Cache in der Speicherzugriffs-Hardwareschaltung, vor dem Durchführen der Übersetzung.
    8. Parallelprozessor gemäß Anspruch 6 oder 7, wobei die mit dem Prozessor gekoppelte Speicherzugriffs-Hardwareschaltung weiter konfiguriert ist, zum Detektieren, während des Lesens der mehrdimensionalen Datenstruktur, von Speicherorten, die außerhalb der Grenzen der mehrdimensionalen Datenstruktur in dem externen Speicher liegen.
    9. Parallelprozessor gemäß einem der Ansprüche 6 bis 8, wobei die mit dem Prozessor gekoppelte Speicherzugriffs-Hardwareschaltung weiter konfiguriert ist, zum Kodieren, während des Schreibens des Ortes in den gemeinsam genutzten Speicher des gekoppelten Prozessors, von Speicherorten, die außerhalb der Grenzen der mehrdimensionalen Datenstruktur in dem externen Speicher liegen, mit einem vorbestimmten Wert.
    10. Parallelprozessor gemäß einem der Ansprüche 5 bis 9, wobei die mit dem Prozessor gekoppelte Speicherzugriffs-Hardwareschaltung weiter konfiguriert ist, zum Durchführen des asynchronen Transfers durch direktes Schreiben des mindestens einen Teils vom externen Speicher in den gemeinsam genutzten Speicher des Prozessors, vom gemeinsam genutzten Speicher des Prozessors in den externen Speicher, oder von einem ersten Ort im externen Speicher in einen zweiten Ort im externen Speicher.
    11. Parallelprozessor gemäß einem der Ansprüche 5 bis 10, wobei die mit dem Prozessor gekoppelte Speicherzugriffs-Hardwareschaltung weiter konfiguriert ist, zum Durchführen des asynchronen Transfers, unabhängig von der Größe des Blocks der angeforderten Daten, als Antwort auf die in einer einzigen Nachricht empfangene Speicherzugriffsanforderung.
    12. Parallelprozessor gemäß einem der Ansprüche 5 bis 11, wobei die mit dem Prozessor gekoppelte Speicherzugriffs-Hardwareschaltung weiter konfiguriert ist, zum Bestimmen, ob der Datenblock ein Teil in einem im externen Speicher gespeicherten Tensor ist oder ob der Datenblock Nicht-Tensor-Daten im externen Speicher umfasst.
    13. Parallelprozessor gemäß einem der Ansprüche 5 bis 12, wobei die mit dem Prozessor gekoppelte Speicherzugriffs-Hardwareschaltung weiter konfiguriert ist, zum Lesen zumindest eines Teils von Daten aus dem externen Speicher und zum Schreiben des Datenblocks in den gemeinsam genutzten Speicher in einer „Swizzle“-Form.
    14. Parallelprozessor nach Anspruch 13, wobei die mit dem Prozessor gekoppelte Speicherzugriffs-Hardwareschaltung weiter konfiguriert ist, zum Schreiben des zumindest einen Teils der Daten in den gemeinsam genutzten Speicher in der „Swizzle“-Form gemäß einem vorbestimmten „Swizzle“-Muster.
    15. Parallelprozessor nach Anspruch 13 oder 14, wobei die mit dem Prozessor gekoppelte Speicherzugriffs-Hardwareschaltung weiter konfiguriert ist, zum Bestimmen des vorbestimmten Swizzle-Musters entsprechend Informationen, die in einer Antwort enthalten sind, die auf eine Anforderung empfangen wurde, das Lesen des mindestens einen Teils der Daten aus dem externen Speicher durchzuführen.
    16. Parallelprozessor gemäß einem der Ansprüche 5 bis 15, wobei die mit dem Prozessor gekoppelte Speicherzugriffs-Hardwareschaltung weiter konfiguriert ist, zum Zugreifen auf den externen Speicher in dem Kachelmodus.
    17. Parallelprozessor gemäß einem der Ansprüche 5 bis 16, wobei die mit dem Prozessor gekoppelte Speicherzugriffs-Hardwareschaltung weiter konfiguriert ist, zum Zugreifen auf den externen Speicher im Image-to-Column-Modus.
    18. Parallelprozessor gemäß einem der Ansprüche 5 bis 17, wobei die mit dem Prozessor gekoppelte Speicherzugriffs-Hardwareschaltung eine Anforderungswarteschlange, einen Deskriptor-Cache, eine Setup-Schaltung, eine Anforderungsgenerierungsschaltung und eine Anforderungsabschlussverfolgungsschaltung umfasst.
    19. Parallelprozessor gemäß einem der Ansprüche 5 bis 18, wobei die mit dem Prozessor gekoppelte Speicherzugriffs-Hardwareschaltung weiter konfiguriert ist, zum Aktualisieren eines Zählers in dem gemeinsam genutzten Speicher des gekoppelten jeweiligen Prozessors für jeden Unterblock von Daten in dem mindestens einen Teil von Daten, wobei der jeweilige Prozessor eine Synchronisationsschaltung umfasst, die konfiguriert ist, um den Zähler auf einen vorbestimmten Wert zu überwachen.
    20. Parallelprozessor gemäß einem der Ansprüche 5 bis 19, wobei die mit dem Prozessor gekoppelte Speicherzugriffs-Hardwareschaltung weiter konfiguriert ist, zum Lesen des zumindest einen Teils in dem externen Speicher und zum Schreiben des zumindest einen Teils an einen Ort in einem gemeinsam genutzten Speicher für jede einer Gruppe der Vielzahl von Prozessoren.
    21. Parallelprozessor gemäß einem der Ansprüche 3 bis 20, wobei die Speicherzugriffsanforderung eine Ladeoperation vom externen Speicher zum gemeinsam genutzten Speicher oder eine Speicheroperation vom gemeinsam genutzten Speicher zum externen Speicher ist.
    22. Parallelprozessor gemäß einem der vorhergehenden Ansprüche, wobei der asynchrone Transfer eine Reduktionsoperation umfasst.
    23. Parallelprozessor gemäß einem der vorhergehenden Ansprüche, wobei der asynchrone Transfer eine Multicast-Operation umfasst.
    24. Parallelprozessor gemäß einem der vorhergehenden Ansprüche, wobei jeder der Rechner 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.
    25. Parallelprozessor gemäß einem der vorhergehenden Ansprüche, weiter umfassend eine Arbitrierungs-Hardwareschaltung, wobei die Speicherzugriffs-Hardwareschaltung mit dem Prozessor und zumindest einem anderen Prozessor über die Arbitrierungs-Hardwareschaltung gekoppelt ist.
    26. Verfahren, das in einem Parallelprozessor durchgeführt wird, der eine Vielzahl von Prozessoren umfasst, wobei das Verfahren folgende Schritte umfasst: Empfangen, durch eine Speicherzugriffs-Hardwareschaltung, die mit einem Prozessor der Vielzahl von Prozessoren gekoppelt ist, von dem gekoppelten Multiprozessor, 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 als Antwort auf die Speicherzugriffsanforderung, Übersetzen zumindest der Koordinate der mehrdimensionalen Datenstruktur in eine Vielzahl von Speicheradressen für die mehrdimensionale Datenstruktur und, unter Verwendung der Vielzahl von Speicheradressen, asynchrones Transferieren zumindest eines Teils der mehrdimensionalen Datenstruktur.
    27. Speicherzugriffs-Hardwareschaltung, umfassend: eine Schnittstelle zu einem externen Speicher; eine Speicher-Eingabe/Ausgabe-Schnittstelle zum Empfangen von Speicherzugriffsanforderungen von einem Prozessor; zumindest eine Speicherschnittstelle zu einem jeweiligen gemeinsam genutzten Speicher an jedem von einem oder mehreren weiteren Prozessoren und dem Prozessor; und eine Pipeline zum Verarbeiten, konfiguriert zum: Empfangen einer Speicherzugriffsanforderung von dem Prozessor, 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 als Antwort auf die Speicherzugriffsanforderung, Übersetzen zumindest der Koordinate der mehrdimensionalen Datenstruktur in eine Vielzahl von Speicheradressen für die mehrdimensionale Datenstruktur, und unter Verwenden der Vielzahl von Speicheradressen, asynchrones Transferieren zumindest eines Teils der mehrdimensionalen Datenstruktur.
    DE102023105577.1A 2022-03-10 2023-03-07 Verfahren und Vorrichtung zum effizienten Zugriff auf mehrdimensionale Datenstrukturen und/oder andere große Datenblöcke Pending DE102023105577A1 (de)

    Applications Claiming Priority (2)

    Application Number Priority Date Filing Date Title
    US17/691,276 2022-03-10
    US17/691,276 US20230289304A1 (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
    DE102023105577A1 true DE102023105577A1 (de) 2023-09-14

    Family

    ID=87759958

    Family Applications (1)

    Application Number Title Priority Date Filing Date
    DE102023105577.1A Pending DE102023105577A1 (de) 2022-03-10 2023-03-07 Verfahren und Vorrichtung zum effizienten Zugriff auf mehrdimensionale Datenstrukturen und/oder andere große Datenblöcke

    Country Status (3)

    Country Link
    US (1) US20230289304A1 (de)
    CN (1) CN116775519A (de)
    DE (1) DE102023105577A1 (de)

    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 (7)

    * Cited by examiner, † Cited by third party
    Publication number Priority date Publication date Assignee Title
    US6879341B1 (en) * 1997-07-15 2005-04-12 Silverbrook Research Pty Ltd Digital camera system containing a VLIW vector processor
    US7814166B2 (en) * 2006-01-27 2010-10-12 Sony Computer Entertainment Inc. Methods and apparatus for virtualizing an address space
    US8570393B2 (en) * 2007-11-30 2013-10-29 Cognex Corporation System and method for processing image data relative to a focus of attention within the overall image
    US8547385B2 (en) * 2010-10-15 2013-10-01 Via Technologies, Inc. Systems and methods for performing shared memory accesses
    US10691838B2 (en) * 2014-06-20 2020-06-23 Cypress Semiconductor Corporation Encryption for XIP and MMIO external memories
    US20190339380A1 (en) * 2016-06-22 2019-11-07 Duke University Multiple-input-multiple-output (mimo) imaging systems and methods for performing massively parallel computation
    US20210279837A1 (en) * 2020-03-09 2021-09-09 Nvidia Corporation Cooperative parallel memory allocation

    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
    CN116775519A (zh) 2023-09-19
    US20230289304A1 (en) 2023-09-14

    Similar Documents

    Publication Publication Date Title
    DE102021118444A1 (de) Einrichtung und Verfahren zum Komprimieren von Strahlverfolgungsbeschleunigungsstrukturaufbaudaten
    US11080051B2 (en) Techniques for efficiently transferring data to a processor
    DE102023105565A1 (de) VERFAHREN UND VORRICHTUNG FÜR EFFIZIENTEN ZUGRIFF AUF MEHRDIMENSIONALE DATENSTRUKTUREN UND/ODER ANDERE GROßE DATENBLÖCKE
    DE102021120605A1 (de) Effiziente softmax-berechnung
    US11645533B2 (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
    DE102020132557A1 (de) Vorrichtung und verfahren für asynchrones raytracing
    DE102021102589A1 (de) Berechnungsgraph-optimierung
    DE102020131901A1 (de) Vorrichtung und verfahren zum durchführen nicht lokaler mittelwertfilterung unter verwendung eines bewegungsschätzschaltkreises eines grafikprozessors
    DE102021114012A1 (de) Intelligente flüssigkeitsgekühlte computer- pods für ein mobiles rechenzentrum
    DE102020132377A1 (de) Vorrichtung und Verfahren zur Drosselung einer Raytracing-Pipeline
    US11907717B2 (en) Techniques for efficiently transferring data to a processor
    DE102020121601A1 (de) Persistenter Notizblockspeicher zum Datenaustausch zwischen Programmen
    DE102019134020A1 (de) Dekompprimierungstechniken zur verarbeitung komprimierter daten, die für künstliche neuronale netzwerke geeignet sind
    DE102022124599A1 (de) Vorrichtung und verfahren zur baumstrukturdatenreduzierung
    DE102021102746A1 (de) Lese/schreib-seitenreplikation für mehrere recheneinheiten
    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
    DE102020130081A1 (de) Erweiterte prozessorfunktionen für berechnungen
    DE102019102825A1 (de) Kohärentes Caching von Daten für Skalierung mit hoher Bandbreite
    DE102019108051A1 (de) Beibehalten einer hohen zeitlichen zwischenspeicherlokalisierung zwischen unabhängigen threads mit dem gleichen zugriffsmuster
    DE102023105577A1 (de) Verfahren und Vorrichtung zum effizienten Zugriff auf mehrdimensionale Datenstrukturen und/oder andere große Datenblöcke
    DE112020007283T5 (de) Dockingboard für eine Multiformat-Grafikverarbeitungseinheit
    DE112020007377T5 (de) Intelligente anpassbare rippen zur kühlung von rechenzentrumsvorrichtungen
    US20230289190A1 (en) Programmatically controlled data multicasting across multiple compute engines

    Legal Events

    Date Code Title Description
    R012 Request for examination validly filed