DE102023105568A1 - Programmatisch gesteuertes daten-multicasting über mehrere rechen-engines - Google Patents

Programmatisch gesteuertes daten-multicasting über mehrere rechen-engines Download PDF

Info

Publication number
DE102023105568A1
DE102023105568A1 DE102023105568.2A DE102023105568A DE102023105568A1 DE 102023105568 A1 DE102023105568 A1 DE 102023105568A1 DE 102023105568 A DE102023105568 A DE 102023105568A DE 102023105568 A1 DE102023105568 A1 DE 102023105568A1
Authority
DE
Germany
Prior art keywords
memory
processing system
data
multicast
packet
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
DE102023105568.2A
Other languages
English (en)
Inventor
Apoorv Parle
Ronny KRASHINSKY
John Edmondson
Jack Choquette
Shirish Gadre
Steve Heinrich
Manan Patel
Prakash Bangalore Prabhakar, Jr.
Ravi Manyam
Wish Gandhi
Lacky Shah
Alexander L. Minkin
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 DE102023105568A1 publication Critical patent/DE102023105568A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T1/00—General purpose image data processing
    • G06T1/20—Processor architectures; Processor configuration, e.g. pipelining
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • 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/1668—Details of memory controller
    • G06F13/1689—Synchronisation and timing concerns
    • 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/38—Information transfer, e.g. on bus
    • G06F13/40—Bus structure
    • G06F13/4004—Coupling between buses
    • G06F13/4022—Coupling between buses using switching circuits, e.g. switching matrix, connection or expansion network
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline, look ahead
    • G06F9/3885—Concurrent instruction execution, e.g. pipeline, look ahead using a plurality of independent parallel functional units
    • G06F9/3887—Concurrent instruction execution, e.g. pipeline, look ahead using a plurality of independent parallel functional units controlled by a single instruction for multiple data lanes [SIMD]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
    • G06F9/522—Barrier synchronisation
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/10—Packet switching elements characterised by the switching fabric construction
    • H04L49/101—Packet switching elements characterised by the switching fabric construction using crossbar or matrix

Abstract

Diese Spezifikation beschreibt eine programmatische Multicast-Technik, die einem Thread ermöglicht (beispielsweise in einem kooperativen Gruppen-Array (CGA) auf einer GPU), Daten im Namen eines oder mehrerer anderer Threads anzufragen (die beispielsweise auf jeweiligen Prozessorkernen der GPU ausgeführt werden). Das Multicast wird von Verfolgungsschaltungen unterstützt, die Schnittstellen zwischen Multicast-Anfragen, die von Prozessorkernen empfangen werden, und dem verfügbaren Speicher bilden. Das Multicast ist ausgestaltet, um Cache (beispielsweise Level 2 Cache) Bandbreitennutzung zu verringern, was starke Skalierung und kleinere Kachelgrößen ermöglicht.

Description

  • GEBIET
  • Diese Technologie betrifft im Allgemeinen das Verbessern der Verarbeitungseffizienz von Prozessoren. Genauer gesagt betrifft die Technologie hier spezialisierte Schaltungen, um Multicast zu handhaben.
  • HINTERGRUND
  • Benutzer wollen, dass Deep-Learning- und High-Performance-Computing(HPC)-Rechenprogramme weiterhin skalieren, wie sich die Technologie von Graphikverarbeitungseinheiten (GPUs) verbessert und die Anzahl von Verarbeitungskerneinheiten pro Chip mit jeder Generation zunimmt. Was gewünscht ist, ist ein schnellerer Zeit bis zur Lösung für eine einzige Anwendung und keine Skalierung lediglich durch Ausführen N unabhängiger Anwendungen.
  • 1A zeigt beispielhafte Deep-Learning(DL)-Netzwerke, die lange Ketten von sequenziell abhängigen rechenintensiven Schichten umfassen. Jede Schicht wird unter Verwendung von Operationen berechnet, wie z. B. Multiplizieren von Eingabeaktivierungen gegen eine Matrix von Gewichten, um Ausgabeaktivierungen zu erzeugen. Die Schichten werden typischerweise über eine GPU oder Cluster von GPUs durch Teilen der Arbeit in Ausgabeaktivierungs-Kacheln parallelisiert, die jeweils die Arbeit darstellen, die ein Verarbeitungskern verarbeiten wird.
  • Aufgrund der potenziell massiven Anzahl von Rechnungen, die Deep-Learning erfordert, ist schneller gewöhnlicherweise das Ziel. Und es macht intuitiv Sinn, dass das parallele Durchführen vieler Rechnungen die Verarbeitung im Vergleich zum seriellen Durchführen aller dieser Rechnungen seriell beschleunigen wird. Tatsächlich wird der Betrag an Leistungsvorteil, die eine Anwendung durch Ausführen auf einer gegebenen GPU-Implementierung realisieren wird, typischerweise vollständig von dem Ausmaß abhängen, zu dem sie parallelisiert werden kann. Es gibt jedoch unterschiedliche Vorgehensweisen zur Parallelität.
  • Konzeptionell könnte, um einen Prozess zu beschleunigen, jeder Parallelprozessor mehr Arbeit durchführen (siehe 1B) oder man könnte stattdessen die Menge von Arbeit auf jedem Parallelprozessor konstant halten und mehr Prozessoren hinzufügen (siehe 1C). Es sei ein Bemühen betrachtet, eine Schnellstraße neu zu befestigen, die mehrere Meilen lang ist. Sie als der Projektmanager wünschen, dass die Aufgabe der Neubefestigung in der kürzesten Menge an Zeit durchgeführt wird, um Verkehrsbeeinträchtigung zu minimieren. Es ist offensichtlich, dass das Projekt zur Straßenneubefestigung schneller erledigt wird, wenn sie mehrere Mannschaften aufweisen, die parallel auf unterschiedlichen Teilen der Straße arbeiten. Welche Vorgehensweise wird jedoch die Aufgabe schneller erledigen -jede Straßenmannschaft zu bitten, mehr Arbeit zu tun, oder mehr Mannschaften hinzuzufügen, die jeweils die gleiche Menge von Arbeit tun? es stellt sich heraus, dass die Antwort vom Wesen der Arbeit und den Ressourcen abhängt, die verwendet werden, um die Arbeit zu unterstützen.
  • Informatiker bezeichnen die erste Vorgehensweise als „schwache Skalierung“ und die zweite Vorgehensweise als „starke Skalierung.“
  • Benutzer derartiger Anwendungen wünschen somit typischerweise eine starke Skalierung, was bedeutet, dass eine einzige Anwendung eine höhere Leistung erreichen kann, ohne ihre Arbeitslast ändern zu müssen -- beispielsweise durch Vergrößern ihrer Chargengröße, um inhärentere Parallelität zu erzeugen. Benutzer erwarten ebenfalls erhöhte Geschwindigkeitsleistung beim Ausführen existierender (z. B. rekompilierter) Anwendungen auf neuen, fähigeren GPU-Plattformen, die mehr Parallelprozessoren bieten. Die GPU-Entwicklung hat die Erwartungen des Marktes hinsichtlich mehr Parallelprozessoren und mehr Koordination/Kooperation zwischen erhöhten Anzahlen von parallelen Ausführungs-Threads auf diesen Parallelprozessoren erfüllt oder sogar überschritten - wobei jedoch weitere Leistungsverbesserungen benötigt werden, um eine starke Skalierung zu erreichen.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
    • 1A zeigt eine beispielhafte Anwendung, die auf einer GPU ausgeführt wird.
    • 1B zeigt eine schwache Skalierung eines Deep-Learning-Szenarios.
    • 1C zeigt eine starke Skalierung eines Deep-Learning-Szenarios.
    • 1D zeigt, dass kleinere Kachelgrößen bei starker Skalierung hohe Schicht-2-Cache-Bandbreitenanforderungen auferlegt;
    • 1E zeigt ein Beispiel von redundanten Speicherabrufen.
    • 2A zeigt einen beispielhaften Multicast-Nachrichtenfluss bei programmatischen Multicast, wenn ein Prozessor Daten im Auftrag von mehrere Prozessoren abruft, gemäß einigen Ausführungsformen.
    • 2B zeigt ein Blockdiagramm einer L2-Anfrage-Koaleszenzeinheit (LRC), die einen Multicast-Nachrichtenfluss bedient, gemäß einigen Ausführungsformen.
    • 3 zeigt eine konzeptionelle Ansicht des kooperativen Gruppen-Arrays (CGA) von Threads.
    • 4 zeigt eine konzeptionelle Ansicht einer gemeinsam genutzten Speicherorganisation für ein kooperatives Thread-Array (CTA) .
    • 5 zeigt eine beispielhafte Anordnung des jeweiligen von jedem CTA gemeinsam genutzten Speichers.
    • 6 ist ein Architekturblockdiagramm einer GPU-Architektur einschließlich Prozessoren (z. B. Streaming-Multiprozessoren) und zugeordneten Zwischenverbindungen, die in unterschiedliche µGPC-Partitionen partitioniert und eine LRC umfassen, wie beispielsweise die in 2B gezeigten.
    • 7 zeigt beispielhafte Systemelemente, insbesondere einen Kreuzschienenschalter und einen allgemeinen Verarbeitungscluster (GPC), der mit der LRC durch die Kreuzschiene verbunden ist, die bei dem Multicast-Nachrichtenfluss teilnehmen, gemäß einigen Ausführungsformen.
    • 8 zeigt eine beispielhafte Konnektivität zu dem GPC ausführlicher in einem System, wie beispielweise dem in 7, gemäß einigen Ausführungsformen.
    • 9A zeigt einen beispielhaften Multidrop-Schalter zwischen einer Kreuzschiene und GPCs gemäß einigen Ausführungsformen.
    • 9B zeigt einen beispielhaften Multidrop-Schalter zwischen einem GPCARB und den SMs gemäß einigen Ausführungsformen.
    • 10 veranschaulicht eine beispielhafte Parallelverarbeitungseinheit einer GPU gemäß einigen Ausführungsformen.
    • 11A veranschaulicht einen beispielhaften allgemeinen Verarbeitungscluster (GPC) innerhalb der Parallelverarbeitungseinheit von 10, wobei jeder Streaming-Multiprozessor in dem allgemeinen Verarbeitungscluster mit einer Tensorspeicherzugriffseinheit gekoppelt ist, gemäß einigen Ausführungsformen.
    • 11B veranschaulicht eine beispielhafte Speicherpartitionseinheit der Parallelverarbeitungseinheit von 10.
    • 12 veranschaulicht einen beispielhaften Streaming-Multiprozessor von 11A.
    • 13A ist ein beispielhaftes Konzeptdiagramm eines Verarbeitungssystems, das unter Verwendung der
    • Parallelverarbeitungseinheit (PPU) von 10 implementiert ist.
    • 13B ist ein Blockdiagramm eines beispielhaften Systems, bei dem die verschiedene Architektur und/oder Funktionalität der verschiedenen vorherigen Ausführungsformen implementiert werden kann.
  • AUSFÜHRLICHE BESCHREIBUNG VON BEISPIELHAFTEN, NICHT EINSCHRÄNKENDEN AUSFÜHRUNGSFORMEN
  • Ausführungsformen dieser Offenbarung sind darauf gerichtet, GPU-Leistungsverbesserungen durch „starke Skalierung“ von L2-Cache- zu SM-Bandbreiten(ebenfalls als „L2-Bandbreite“ bezeichnet)-Verbesserungen und durch wirksames Einsetzen von algorithmischer Redundanz von Anwendungen zu unterstützen.
  • Starke Skalierung wurde oben in Relation zu 1A-1C beschrieben und bezieht sich auf GPU-Ausgestaltungsverbesserungen, so dass die gleiche Menge an Arbeit (im Vergleich mit einer vorherigen GPU-Generation) bei mehreren Malen der Geschwindigkeit auf einem schnelleren Prozessor durchgeführt werden kann. Dies verringert wirksam die jedem Prozessor zugeteilte Kachelgröße.
  • um eine starke Skalierung zu erreichen, bevorzugen GPU-Entwickler Kacheln aufzuweisen, die so klein wie möglich sind. verringerte Kachelgrößen stellen jedoch höhere Anforderungen auf die L2-Cache-Streaming-Multiprozessorbandbreite. Um die höhere Bandbreite zu erreichen, die durch Kacheln von kleinen Größen (z. B. 64x64) erforderlich sind, müssen Hardwareaspekte der GPU, wie beispielsweise eine oder mehrere der Anzahl von Prozessoren, die Anzahl von L2-Cache-Slices (als „L2-Slices“ bezeichnet), die Anzahl von Blöcken, die pro Taktzyklus transferiert wird, und die Taktgeschwindigkeit hochskaliert werden. Damit derartige Hardwareaspekte hochskaliert werden, werden jedoch Schwierigkeiten mit Bezug auf die erhöhte Anzahl von Drähten, der quadratischen Eskalation der Kreuzschienenkosten aufgrund des Bedarfs, eine zunehmende Anzahl von Ports mit dem L2-Cache und dem SM zu verbinden, der Zunahme von erforderlichen zusätzliche Direktzugriffspeicher(RAM)-Banken und dergleichen angetroffen.
  • 1D veranschaulicht die L2-Bandbreitenanforderung in drei unterschiedlichen GPUs, wobei von links nach rechts zunehmende Anzahlen von Prozessoren (in diesem Beispiel Streaming-Multiprozessoren (SM)) und L2-Slices pro GPU dargestellt werden, da die Kachelgröße kleiner gemacht wird. Das Muster eines starken Anstiegs in der L2-Bandbreiteanforderung in größeren leistungsfähigeren GPUs, wenn die Kachelgröße kleiner gemacht wird, ist in 1D offensichtlich.
  • Beispielhafte Ausführungsformen der Offenbarung setzen Datenabrufredundanz wirksam ein, um die Bandbreite und Leistung zu verringern, die erforderlich ist, um die gleiche Datenmenge zu bewegen und besser zu skalieren. Beispielhafte Ausführungsformen erhöhen wirksame L2-Bandbreite durch Multicast von Antwortdaten von einem L2-Lesen zu mehreren kooperativen Thread-Arrays (CTA) auf mehreren SMs. In einigen Ausführungsformen gehören die CTAs, welche die Multicast-Antwort empfangen, alle zu dem gleichen kooperativen Group-Array (CGA). Beispielhafte Anwendungen, die erheblich von der Offenbarung profitieren können, umfassen Generic Matrix Multiply (GEMM) und GEMM-ähnliche Kernel.
  • 1E zeigt ein beispielhaftes generisches Matrixmultiplikation (GEMM)-Szenario für das herkömmliche GPUs Leistung aufgrund von Datenabrufredundanz verlieren können. Die veranschaulichte GEMM führt zu einer 4×4 Ergebnismatrix, welche die Berechnung der Multiplikation des 4×1 Vektors A (mit Elementen A1-A4) mit dem 1 × 4 Vektor B (mit Elementen B1-B4) darstellt. Obwohl die auf 1E bezogene Erläuterung in Relation zu GEMM ist, sind Ausführungsformen dieser Offenbarung ebenfalls nicht auf verbesserte Leistung in GEMM-Kerneln begrenzt und können verbesserte Leistung für viele andere Anwendungen liefern, die Anwendungen, wie beispielsweise Faltungskernel, umfassen.
  • Wie in 1E zu erkennen ist, benutzt jede Zelle (Element) der ersten Zeile der Ergebnismatrix Element A1 von der Eingabematrix A und jede Zelle der ersten Spalte der Ergebnismatrix benutzt Element B1 von der Eingabematrix B. Im Allgemeinen benutzt jede Zelle in der Ergebnismatrix einige Eingabedaten, welche die gleichen wie in den Eingabedaten ihren benachbarten Zellen sind. In vorherigen NVIDIA-GPUs wurde das A1-Element getrennt von dem Speicher (typischerweise dem L2-Cache) zum Berechnen jedes Elements in der ersten Zeile der Ergebnismatrix abgerufen. Gleichermaßen wurde das Bl-Element getrennt zum Berechnen jedes Elements in der ersten Spalte der Ergebnismatrix abgerufen. Das Abrufen des gleichen Elements (z. B. Al, B1) mehrere Male von dem L2-Cache ist eine beispielhafte Datenabrufredundanz, die dazu führt, dass sowohl Bandbreite (z. B. Speicherbandbreite, Kreuzschiene(Netzwerk auf Chip - NOC)-Bandbreite) als auch Leistung verschwendet werden.
  • Beispielhafte Ausführungsformen dieser Offenbarung setzen diese Datenabrufredundanz wirksam ein, um die Bandbreite und Leistung zu verringern, die erforderlich ist, um die gleiche Datenmenge zu bewegen und besser zu skalieren.
  • Überblick von Programmatischem Multicast
  • Einige beispielhafte Ausführungsformen dieser Offenbarung stellen ein neues Programmier- und Hardwareausführungsmodell bereit, um koordiniertes Datenabrufen durch eine Prozessor im Auftrag von mehreren Prozessoren zu ermöglichen. In einigen Ausführungsformen bewegen sich von dem L2-Cache gelesene Daten in einem Lesevorgang durch mindestens einen Teil des Kreuzschienennetzwerks-auf-Chip (einfach als „Kreuzschiene“ oder „Kreuzschienenschalter“ bezeichnet) wie ein einziges Paket, bevor diese Daten oder Abschnitte davon an mehrere Prozessoren verteilt werden.
  • Neue Paketformate und Verfolgungsstrukturen in Hardware werden gebildet, um die Multicast-Operation zu steuern.
  • Die Kreuzschiene umfasst die Fähigkeit, Multicast-Paketformate mit Feldern zu handhaben, um mehrere Ziele anzuvisieren. Die Kreuzschiene umfasst ebenfalls die Fähigkeit, das gleiche Paket an mehrere Ziele bei einem oder mehrere Trennungspunkten zu senden.
  • Zusätzlich umfassen einige beispielhafte Ausführungsformen Synchronisationsmechanismen, um Transaktionsabschluss und/oder Fehlermeldung anzugeben.
  • 2A veranschaulicht einen Überblick eines Multicast-Paketursprungs und eines entsprechenden Paketflusses in einer GPU gemäß einigen Ausführungsformen.
  • Die GPU 200 umfasst einen oder mehrere GPC 202, die jeweils mehrere Prozessoren (z. B. 204, 206 usw.) wie beispielsweise SMs aufweisen. Ein Kernel wird als ein kooperatives Gruppen-Array (CGA) von Threads gestartet, wobei ein jeweiliges kooperatives Thread-Array (CTA) von Threads auf jedem der gezeigten SMs, einschließlich auf SMs 204 und 206, ausgeführt wird. In diesem Beispiel erzeugt der SM 204 ein Multicast-Anfragepaket 224. Genauer gesagt erzeugt ein Thread in dem CTA, der auf dem SM 204 ausgeführt wird, das Multicast-Anfragepaket 224. Der SM 204 kann als der „Multicast-Quellen-SM“ oder „Multicast-anfragende SM“ bezeichnet werden, weil der Thread, der das Multicast-Anfragepaket erzeugt, auf dem SM 204 ist.
  • Der Thread, welcher das Multicast-Anfragepaket 224 erzeugt, kann als der „Leader-Thread“ in einem Thread-Block bezeichnet werden, der den Leader-Thread umfasst und bei dem alle andere Threads Follower-Threads sind. Der Leader-Thread umfasst Anweisungen, um das Multicast-Anfragepaket 224 zu erzeugen und zu übertragen, das Daten im Auftrag von Threads auf mehrere SMs anfragt, wie beispielsweise dem SM 204 und SM 206. In einigen Ausführungsformen kann der Leader-Thread ein Multicast-Anfragepaket 224 machen, um Daten im Auftrag von mindestens einem Thread anzufragen, der auf mindestens einem anderen SM als dem Multicast-Quellen-SM ausgeführt wird. Alle Threads, für deren Nutzen der Leader-Thread Daten anfragt, können als „Follower-Threads“ ungeachtet dessen bezeichnet werden, ob sie auf dem gleichen SM wie der Leader-Thread sind.
  • Die Formate und Parameter des Multicast-Pakets werden nachstehend beschrieben. Wie ausführlicher nachstehend beschrieben ist, identifiziert das Multicast-Anfragepaket 224 die mehreren Empfänger SMs oder CTAs für die angefragten Daten. Es ist nicht erforderlich, dass der anfragende SM einer der Empfänger SMs ist. Das heißt, dass der SM Daten vollständig im Auftrag von anderen SMs anfragen kann.
  • Das Multicast-Anfragepaket 224 wird auf der Anfrage-Kreuzschiene 208 an die L2-Anfrage-Koaleszenzeinheit (LRC) 212 übertragen.
  • Bei der LRC 212 werden Multicast-spezifische Informationen, die in dem Multicast-Anfragepaket 224 umfasst waren, in einer Verfolgungsstruktur 222 gespeichert, und ein L2-Anfragepaket 226 wird erzeugt. Das L2-Anfragepaket 226 umfasst die Anfrage für Daten, die an den L2-Cache zu senden sind, jedoch nicht die mehrere Multicast-Empfängeridentifikatoren umfassen können, die in dem Paket 224 waren. Das L2-Anfragepaket 226 kann keine Multicast-spezifischen Informationen umfassen und wird durch den L2-Cache in einer gleichen oder ähnlichen Art und Weise gehandhabt, wie eine Anfrage für Daten für einen SM oder ein CTA gehandhabt wird.
  • Ein L2-Slice 220 von dem L2-Cache, der mehrere L2-Slices umfasst, der die angefragten Daten umfasst, empfängt das L2-Anfragepaket 226 und gibt ein L2-Antwortpaket 228 mit den angefragten Daten zurück. Das Antwortpaket 228 kann keine Multicast-spezifischen Informationen umfassen und kann als ein Unicast-Paket betrachtet werden.
  • Bei der LRC 212 wird das L2-Antwortpaket 228 an die Verfolgungsstruktur 222 von gespeicherten Verfolgungsinformationen angepasst. Die Anpassung kann basierend auf einem oder mehreren Parametern durchgeführt werden, die sowohl in dem L2-Anfragepaket 226 als auch dem L2-Antwortpaket 228 umfasst sind und den anhängigen L2-Anfrage-Slot identifizieren können. Ein LRC-Multicast-Antwortpaket 230, das die angefragten Daten, die von den L2s Slice 220 empfangen werden, und Informationen hinsichtlich der mehreren Empfänger für die angefragten Daten umfasst, wird erzeugt. Die Informationen hinsichtlich der mehreren Empfänger werden von den gespeicherten Verfolgungsinformationen in der Verfolgungsstruktur 222 erhalten. Wenn die Multicast-Anfrage durch den Leader-Thread ausgegeben wird, um Daten im Auftrag von mindestens einem Thread anzufragen, der auf mindestens einem anderen SM als dem Multicast-Quellen-SM ausgeführt wird, umfasst das LRC-Multicast-Antwortpaket die angefragten Daten und Informationen hinsichtlich des Empfänger-SM.
  • Das LRC-Multicast-Antwortpaket 230 bewegt sich durch die Antwort-Kreuzschiene 210 als ein einziges Paket durch den Kreuzschienenpfad, der allen Empfängern gemeinsam ist, die in dem Paket 230 zugewiesen sind. Die Ergebnisdaten in dem einzelnen Paket 230 werden in zwei oder mehr Paketen dupliziert, wie es als notwendig basierend auf der Liste von Empfängern bei einem oder mehrere Trennungspunkten bestimmt wird. In dem veranschaulichten Beispiel werden die im Paket 230 getragenen Ergebnisdaten in zwei Pakete 232 und 234 zum Empfangen von SMs 204 und 206 identifiziert, wie in der Liste von Empfängern an einem Trennungspunkt jeweils identifiziert ist, der ein Punkt in der Kreuzschiene ist, bei dem sich der gemeinsame Pfad eines Eingangsports in der Empfängerkreuzschiene 210 in einen ersten Pfad zu dem SM 204 und einen zweiten Pfad zu dem SM 206 trennt. Der Trennungspunkt könnte früher sein, wenn die Empfänger-SMs nicht in dem gleichen Texturverarbeitungscluster (TPC) sind.
  • Jeder des einen oder mehreren Empfängers von Multicast-Ergebnisdaten sendet eine ack-Nachricht an den Anfrager der Multicast-Daten. In dem veranschaulichten Beispiel werden die Multicast-Ergebnisdaten von den SMs 204 und 206 empfangen. Der SM 204 ist ebenfalls der Anfrager der Multicast-Daten und erzeugt daher keine Bestätigung für die empfangenen Ergebnisdaten. Der SM 206, der nicht der Anfrager ist, erzeugt ein Bestätigungspaket 236 an den Anfrager-SM 204.
  • Das Bestätigungspaket 236 bewegt sich durch die Anfrage-Kreuzschiene 208, Zwischenverbindungs-Kreuzschiene 209 und Antwort-Kreuzschiene 210 und wird von dem SM 204 empfangen. Wie ausführlicher nachstehend beschrieben ist, kann eine Synchronisationstechnik von dem Sender-SM 204 und den Empfänger-SMs benutzt werden, um den Abschluss der Transaktion oder eine fehlerhafte Transaktion zu erfassen. In einigen Ausführungsformen wird das Bestätigungspaket verwendet, um den Abschluss der Transaktion einer fehlerhaften Transaktion zu erfassen.
  • 2B ist ein Blockdiagramm von Komponenten der LRC 212, die primär bei der Multicast-Paketverarbeitung beteiligt waren. Der L2-Anfragegenerator 238 ist konfiguriert, um das Multicast-Anfragepaket zu empfangen, und basierend auf dem empfangenen Multicast-Paket für Daten, das L2-Anfragepaket für die Daten zu erzeugen. Der L2-Anfragegenerator 228 speichert zusätzlich Multicast-spezifische Informationen, die umfassend in dem Multicast-Anfragepaket umfasst sind, wie beispielsweise die Multicast-Empfängen, in Verfolgungsschaltungen und der Metadatenspeicherung 222.
  • Der Multicast-Antwortgenerator 240 empfängt das L2-Antwortpaket des L2-Slice mit den angefragten Daten und erzeugt das LRC-Multicast-Antwortpaket einschließlich der angefragten Daten, die von dem L2-Slice empfangen werden. Der Multicast-Antwortgenerator 240 passt das L2-Antwortpaket an die gespeicherten Metadaten an, um die zugeordnete Liste von Multicast-Empfängern zu erhalten und umfasst diese Informationen in dem Multicast-Antwortpaket.
  • Multicast in einem Kooperativen Gruppen-Array
  • 3 veranschaulicht eine Anordnung von Blöcken von Threads in einem kooperativen Gruppen-Array (CGA) gemäß einigen Ausführungsformen. Ein CGA ist ein neues Programmier-/Ausführungsmodell und unterstützt Hardwareimplementierung und wird in der U.S.-Patentanmeldung Nr. 17/691,621 beschrieben, die hier durch Bezugnahme in ihrer Gesamtheit aufgenommen ist. In einigen Ausführungsformen ist die in dieser Offenbarung beschriebene Multicast-Technologie auf dem CGA-Programmier-/Ausführungsmodell aufgebaut. Das CGA-Programmier-/Ausführungsmodell ermöglicht benachbarten Kacheln, in SMs auf dem gleichen GPC gestartet zu werden.
  • In einer Ausführungsform ist ein CGA eine Sammlung von CTAs, wobei Hardware garantiert, dass alle CTAs des CGA in die gleiche Hardwareorganisationsebene gestartet werden, welche das CGA spezifiziert oder dem es zugeordnet ist. Die Hardware ist konfiguriert, um sicherzustellen, dass es genug Verarbeitungsressourcen in der Zielhardwareebene gibt, um alle CTAs des CGA zu starten, bevor irgendwelche gestartet werden.
  • Wie 3 zeigt, ist ein CGA ein Gitter von Clustern von Thread-Blöcken oder CTAs, die als ein Array organisiert sind. Derartige CGAs stellen Koplanung, z. B. Steuerung darüber, wo Cluster von CTAs in der GPU platziert/ausgeführt werden, relativ zu dem durch eine Anwendung erforderlichen Speicher und relative zueinander bereit. Dies ermöglicht Anwendungen, mehr Datenlokalität, verringerte Latenz und bessere Synchronisation zwischen alle den Threads in eng kooperierenden Clustern von CTAs zu sehen.
  • Beispielsweise seien CGAs eine Anwendung, die das hierarchischen Wesen der Zwischenverbindung und des Caching-Untersystems in modernen GPUs ausnutzen und es einfacher machen, zu skalieren, wenn Chips in der Zukunft wachsen. Durch Ausnutzen räumlicher Lokalität ermöglichen CGAs effizientere Kommunikation und niedrigere Latenz-Datenbewegung. GPU-Hardwareverbesserungen garantieren, dass Threads von mehreren CTAs in der(den) neuen definierten CGA-hierarchischen Ebene(n) gleichlaufend für gewünschte räumliche Orte laufen werden, in dem CGAs erlaubt werden, zu steuern, wo auf der Maschine die gleichlaufenden CTA-Threads relativ zueinander laufen werden.
  • In einer Ausführungsform sind CGAs aus Clustern von CTAs zusammengesetzt, die durch Hardware garantiert werden, zu starten und gleichzeitig/gleichlaufend ausgeführt zu werden. Die CTAs in einem CGA-Cluster können -- und im allgemeinen Fall werden - auf unterschiedlichen SMs innerhalb der GPU ausgeführt. Obwohl sogar die CTAs auf unterschiedlichen SMs ausgeführt werden, stellt das GPU-Hardware/System nichtsdestotrotz eine Cross-SM-Garantie bereit, dass die CTAs in einem CGA-Cluster geplant werden, gleichlaufend ausgeführt zu werden. Das GPU-Hardware/System stellt ebenfalls effiziente Mechanismen bereit, durch welche die gleichlaufend-ausführenden CTAs miteinander kommunizieren können. Dies erlaubt einer Anwendung, Daten zwischen den CTAs in einem CGA-Cluster explizit gemeinsam zu nutzen und erlaubt ebenfalls eine Synchronisation zwischen den verschiedene Threads der CTAs in dem CGA-Cluster.
  • In beispielhaften Ausführungsformen können die verschiedenen Threads innerhalb des CGA-Clusters von einem gemeinsam genutzten Speicher lesen/schreiben -- was einen beliebigen Thread in dem CGA-Cluster ermöglicht, Daten mit einem beliebigen anderen Thread in dem Cluster gemeinsam zu nutzen. Die gemeinsame Nutzung von Daten zwischen CTAs in dem CGA-Cluster spart Zwischenverbindungs- und Speicherbandbreite, was häufig der Leistungsbegrenzer für eine Anwendung ist.
  • Nun ist es unter Verwendung der gleichlaufenden Ausführung und dem zusätzlichem gemeinsam genutzten Speicher, der durch Hardware unterstützt wird, möglich, Daten zwischen Threads eines CTA und Threads von einem anderen CTA direkt gemeinsam zu nutzen - was Abhängigkeiten über CTAs ermöglicht, die Hardware-(z. B. Cross-SM)-Partitionen überbrücken zu können.
  • Weil CGAs garantieren, dass alle ihre CTAs gleichlaufend mit einer bekannten räumlichen Beziehung ausgeführt werden, sind andere Hardwareoptimierungen möglich, wie beispielsweise: Multicasting von Daten, die von dem Speicher zu mehrere SMs (CTAs) zurückgeführt wurden, um Zwischenverbindungsbandbreite wie in Ausführungsformen dieser Offenbarung zu sparen; Direkte-SM-zu-SM-Kommunikation für niedrigere gemeinsame Latenzdatennutzung und verbesserte Synchronisation zwischen Erzeuger- und Konsumenten-Threads in dem CGA; Hardwarebarrieren zum Synchronisieren der Ausführung über alle (oder irgendwelchen) Threads in einem CGA; und mehr.
  • Der durch das CGA bereitgestellte zusätzliche Cluster-Overlay definiert wo und wenn die CTAs ausgeführt werden, und garantiert insbesondere, dass alle CTAs eines CGA gleichlaufend innerhalb einer gemeinsamen Hardwaredomäne ausgeführt werden, die eine dynamische gemeinsame Nutzung von Daten, Nachrichtenübermittlung und Synchronisation zwischen den CTAs bereitstellt.
  • Beispielhafte Ausführungsformen unterstützen unterschiedliche Typen/Niveaus von CGAs, die auf unterschiedliche GPU-Hardwaredomäne, Partitionen oder andere Organisationsebenen gerichtet sind. Im Einzelnen kann ein CGA-Cluster die Hardwaredomäne definieren oder spezifizieren, auf der alle CTAs in dem Cluster laufen sollen. In beispielhaften Ausführungsformen sind die Hierarchien oder das Clustering, welche die CGAs definieren/spezifizieren, angebunden an oder widerspiegeln anderweitig GPU-Hardwarepartitionen, die Speicherzugriff und/oder Kommunikationsfähigkeiten widerspiegeln, um gewünschte Ressourcen und Datenweiterverwendung und Datenlokalität bereitzustellen.
  • 4 veranschaulicht beispielhafte CGA-Szenarien, bei denen ein CGA-Cluster auf einer beliebigen Anzahl von (in diese Fall vier oder mehr) SMs ausgeführt wird. In beispielhaften Ausführungsformen können alle CTA-Threads innerhalb eines CGA verschiedene Typen von allgemein zugänglichen gemeinsam genutzten Speicher referenzieren. Eine Hardwareunterstützung in der GPU ermöglicht den unterschiedlichen CTAs in einem CGA-Cluster, jeden gemeinsam genutzten Speicher zu lesen und zu beschreiben. Somit können laden, speichern und atomare Speicherzugriffe durch ein erstes CTA den gemeinsam genutzten Speicher eines zweiten CTA anvisieren, wobei die ersten und zweiten CTAs innerhalb des gleichen CGA-Clusters sind.
  • In beispielhaften Ausführungsformen können die CTAs in einem GPC_CGA (d.h. alle CTAs der CGA sind in dem gleichen GPC) Speicher von einem gemeinsamen Datenpool in globalen Speicher zuteilen. In einigen Ausführungsformen ist dieser Datenpool vollständig unter Softwaresteuerung mit bestimmter strategischer Hardwareunterstützung (z. B., Speicher-Slot-Zuteilung mit Drosseln). Der Pool kann dimensioniert sein, so dass Speicher, der durch alle die ausführenden GPC_CGAs angefragt wird, immer in den Nahspeicher passt, wie beispielsweise einen L2-Cache für verringerte Latenz, oder er kann dimensioniert sein, eine viel größere gemeinsam genutzte Speicherstruktur bereitzustellen, als jemals in einen L1- oder L2-Cache passen könnte. Ein derartiger gemeinsamer „CGA linear gemeinsam genutzten Speicher“ Datenpool kann für Daten verwendet werden, die keine zusätzliche Hierarchie aufweisen oder nicht in andere Typen eines CGA gemeinsam genutzten Speichers passen. Einem derartigen CGA linear gemeinsam genutzten Speicher wird ein CGA zugeteilt und ist gleichermaßen zugänglich durch alle Threads der CTAs in dem Cluster der CGAs, um gleichmäßigen Zugriff auf den gemeinsam genutzten Speicher bereitzustellen, um dadurch das Programmiermodell zu vereinfachen.
  • 5 zeigt eine beispielhafte Schaltungsanordnung zum Zuteilen und Freigeben von linearen Speicher-Slots eines linearen gemeinsam genutzten Speicherpools zu/von CGAs. In einem CGA kann jeder SM auf jeden Speicher der andere SMs zugreifen. In einigen Ausführungsformen schreibt der Quellen-Multicast-SM in die Empfänger Multicast-SMs in ihren jeweiligen Speichern unter Verwendung der verteiltes Speichermechanismen, die mit Bezug auf 5 beschrieben sind. Laden, speichern, atomare Operationen können andere gemeinsam genutzte Speicher des CTA anvisieren. Ein beispielhafter verteilter Speicher, der in Ausführungsformen verwendet werden kann, wird in der U.S.-Anmeldung Nr. 17/691,690 beschrieben, die hier durch Bezugnahme in ihrer Gesamtheit aufgenommen ist. In einigen beispielhaften Ausführungsformen ist der verteilte gemeinsam genutzten Speicher der jeweiligen SMs in den generischen Adressenraum abgebildet.
  • Eine beispielhafte lineare, gemeinsam genutzte globale Speicherimplementierung basiert darauf, einen globalen CGA_linear_Speicher_Slot-Index aufzuweisen, der durch Hardware zugeteilt und zurückgeführt wird (siehe 5). Das meiste des Speichermanagements kann dann durch Software basierend auf dem eindeutigen CGA_linear_Speicher_slot durchgeführt werden, der jedem laufenden CGA zugeführt wird, das CGA linear gemeinsam genutzten globalen Speicher erfordert. Der linear gemeinsam genutzte globale Speicher kann ein regulärer globaler Speicher sein, der in dem L2-Cache zwischengespeichert und durch physikalische Adressen in DRAM gesichert werden kann, so dass keine spezielle Logik in der Speichermanagementeinheit (MMU) oder dem L2-Cache erforderlich ist.
  • In einer beispielhafte Ausführungsform stellt die Hardware einen eindeutigen globalen CGA linearen Speicher-Slot-Index pro GPCdimensionierten CGA bereit, der identifiziert, welchen der Puffer in dem Pool das CGA verwendet, und verwendet diesen Slot-Index, um den CGA-Start zu verhindern, bis ein Speicher-Slot in dem Bereich verfügbar ist, der das Gitter spezifiziert. In derartigen Implementierungen ist der Hardware-bereitgestellte CGA_linear_Speicher_Slot-Index eindeutig über alle laufenden CGAs. Dies ermöglicht unterschiedlichen Gittern von unterschiedlichen virtuellen Engines (die um Ressourcen konkurrieren können) auf der Hardware zur gleichen Zeit zu laufen.
  • 6 zeigt, wie einige beispielhafte GPU-Implementierungen mehrere Partitionen ermöglichen können, die als Mikro-GPUs fungieren, wie beispielsweise µGPU0 und µGPU1, wobei jede Mikro-GPU einen Abschnitt der Verarbeitungsressourcen der gesamten GPU umfasst. Wenn die GPU in zwei oder mehr getrennte kleinere µGPUs für Zugriff durch unterschiedliche Clienten partitioniert ist, werden Ressourcen -- einschließlich die physikalische Speichervorrichtungen, wie beispielsweise lokale L2-Cache-Speicher -- ebenfalls typischerweise partitioniert. Beispielsweise kann in einer Ausgestaltung eine erste Hälfte der physikalische Speichervorrichtungen, die mit der µGPU0 gekoppelt sind, einem ersten Satz von Speicherpartitionsorten entsprechen, und eine zweite Hälfte der physikalische Speichervorrichtungen, die mit der µGPU1 gekoppelt sind, kann einem zweiten Satz von Speicherpartitionsorten entsprechen. Leistungsressourcen innerhalb der GPU werden ebenfalls gemäß der zwei oder mehr separaten kleineren Prozessorpartitionen partitioniert. Die Ressourcen können Level-2-Cache (L2) Ressourcen und Verarbeitungsressourcen umfassen. Eine Ausführungsform eines derartigen Multi-Instance-GPU („MIG“)-Merkmals ermöglicht der GPU, sicher in viele separate GPU-Instanzen für CUDA („Compute Unified Device Architecture“)-Anwendungen partitioniert zu werden, die mehrere Benutzer mit separaten GPU-Ressourcen versieht, um ihre jeweiligen Anwendungen zu beschleunigen. Genauer gesagt umfasst jede Mikro-GPU mehrere GPCs jeweils mit mehreren SMs. Jeder GPC ist mit dem L2-Cache über eine Kreuzschiene und pro L2-Slice-LRC verbunden.
  • Für mehr Informationen über vorbekannte GPU-Hardware und wie sie fortgeschritten ist, siehe beispielsweise USP8,112,614 ; USP7,506,134 ; USP7,836,118 ; USP7,788,468 ; US10909033 ; US20140122809 ; Lindholm et al, „NVIDIA Tesla: A Unified Graphics and Computing Architecture“, IEEE Micro (2008); https://docs.nvidia.com/cuda/parallel-threadexecution/index.html (abgerufen 2021); Choquette et al, „Volta: Performance and Programmability“, IEEE Micro (Band: 38, Ausgabe: 2, Mar./Apr. 2018), DOI: 10.1109/MM.2018.022071134.
  • Programmatische Multicast-Operationen
  • Programmatischer Multicast ist eine neue Form von Speicheranfrage. Diese Anfrage liest zuerst globalen Speicher und dann liefert die Daten, die gelesen wurden, an mehrere Ziel-CTAs (die möglicherweise das gleiche CTA umfassen, welche die Anfrage initiierte/ausführte), wie in der Anweisung spezifiziert. Die Daten werden aus L2 gelesen, sobald sie an die LRC zurückgeführt sind, und dann an alle die Ziel-CTAs gleichzeitig auf der Antwort-Kreuzschiene multicast. Obwohl in bevorzugten Ausführungsformen die Multicast-Pakete parallel erzeugt werden, können in einigen Ausführungsformen mindestens einige der Multicast-Pakete seriell erzeugt werden.
  • In einigen Ausführungsformen wird eine neue Ladeoperation bereitgestellt. Obwohl in typischen Speicherzugriffsanfragen, wo eine SM Daten anfragt und selbst die angefragten Daten empfängt und daher selbst jegliche Informationen behalten kann, die er hinsichtlich der Handhabung dieser Daten zu erhalten hat, wenn sie empfangen werden, erfordert die Multicast-Operation dieser Offenbarung, dass die Informationen, die hier als „Metadaten“ bezeichnet werden, die zur Handhabung der empfangenen Daten notwendig sind, sich mit dem Multicast-Anfragepaket bewegen. Weil der Multicast-Anfrager und der Multicast-Empfänger nicht der gleiche sein können, müssen die Empfänger die Metadaten ebenfalls von dem Anfrager empfangen. Der Anfrager muss die Metadaten beim Übertragen der Anfrage nicht behalten und bewegt sich stattdessen mit dem Multicast-Paket selbst durch den Multicast-Pfad.
  • Multicast-Anfrageformat
  • Schlüsselattribute der neuen Ladeoperation umfassen die globale Speicheradresse, um von (z. B. Quellen-Datenadresse), Ziel(Empfänger) CTAs/SMs, Zieladresse des gemeinsam genutzten Speichers und die Synchronisationsentität zu lesen. Die Ziel-CTAs/SMs können als ein Bitvektor oder als eine andere Datenstruktur identifiziert sein, wie beispielsweise eine Liste. Die Zieladresse des gemeinsam genutzten Speichers (z. B., Zieldatenadresse) kann ein Offset sein, der symmetrisch über Ziel-CTAs ist. Das heißt, dass der Offset der gleiche für alle Ziel-CTAs sein kann. Die Synchronisationsentität kann durch eine Barrier-ID dargestellt werden, um einen Abschluss anzugeben. Die Synchronisationsentität, die als ein Offset spezifiziert werden kann, kann über alle CTAs der CGA symmetrisch sein.
  • In einigen Ausführungsformen ist die neue Ladeoperation oben auf dem CGA-Programmier-/Ausführungsmodul gebaut, um ihren Start, Synchronisation und verteilte Speichermerkmale wirksam einzusetzen. In einigen Ausführungsformen benutzt die neue Ladeoperation zugrundeliegende Speicherzugriffsdienste, die durch eine Tensorspeicherzugriffseinheit (TMA) bereitgestellt werden. Die TMA wird in der U.S.-Anmeldung Nr. 17/691,276 und der U.S.-Anmeldung Nr. 17/691,422 beschrieben, die hiermit durch Bezugnahme in ihrer Gesamtheit aufgenommen sind. In einigen Ausführungsformen kann die Ladeoperation auf Nicht-TMA-Anweisungen wie die LDGSTS (Asynchronous Global to Shared Memcopy) Anweisung erweitert werden, die in der US-Patentanmeldung Nr. 16/712,083 beschrieben ist.
  • In einer beispielhafte Ausführungsform kann eine auf TMA implementierte Multicast-Ladeanweisung ein Format aufweisen, wie beispielsweise das Folgende:
    • UTMALDG.dim{.IM2COL}{.MULTICAST} [URb], [URa], URc ...; .dim: {.1D, .2D, .3D, .4D, .5D} - Tensordimensionalität .IM2COL: Ermöglicht Bild-zu-Spalte-Lademodus. Die Bild-zu-Spalte-Modus-Unterstützung der TMA wird in der U.S.-Anmeldung-Nr. 17/691,276 beschrieben, die oben aufgenommen wurde.
    • URb: Quelle B einheitliches Register. Gepackte Zieladresse, gemeinsam genutzte Speicherbarrierenadresse und Tensorkoordinaten.
    • {URb, URb+1} spezifiziert die Zieldaten/Barrieren-verteilte gemeinsam genutzten Speicheradresse wie folgt:
      Figure DE102023105568A1_0001
      Figure DE102023105568A1_0002
    • URa: Quelle A einheitliches Register. Spezifiziert die globale Speicheradresse des Tensordeskriptors.
      • .MULTICAST: Ermöglicht Multicast-Modus.
      • URc: Quellen C einheitliches Register. Multicast-CTA-IDs (oder SM ids) und optional ebenfalls eine oder mehrere (z. B., bis zu drei) Tensorkoordinaten-Offsets für .IM2COL.
  • In einigen Ausführungsformen kann die CTA-ID-Maske im folgende Format codiert werden:
    Figure DE102023105568A1_0003
  • In einigen Ausführungsformen können alle CTAs in dem CGA Multicast-Ziele sein. in einigen Ausführungsformen werden jedoch bis zu 16 Ziel-CTA-IDs in eine in URc codierte 16-Bit Maske umfasst, wobei jedes Bit einer CTA-ID entspricht. In einigen Ausführungsformen können, obwohl ein CGA bis zu 32 CTAs aufweisen kann, lediglich die ersten 16 CTAs von dem [0:15] Bereich imstande sein, im Multicast-Modus teilzunehmen.
  • Ziel-SMs können keine Metadaten aufweisen, die beschreiben, wie die empfangenen Daten zu verarbeiten sind (z. B., wie empfangene Daten im Bild-zu-Spalten-Format geschrieben werden sollten, usw.), im Gegensatz zu Quellen-SMs. Daher müssen alle Metadaten, die notwendig sind, um die Antworten zu handhaben, mit dem Paket gesendet werden. Vom Quellen-SM zu Ziel-SMs transportierte „Metadaten“ können beispielsweise umfassen:
    • -SM ID Maske, die den Ziel-SMs (CTA-IDs) entspricht,
    • -CGA ID,
    • -Data SMEM (gemeinsam genutzter Speicher) Offset,
    • -Barrierenadresse Offset,
    • -Quellen-SM ID für Antworten,
    • -ACK Phase ID (zwei mögliche Phasen, Teil des MEMBAR-Protokolls), und
    • -Implementierungs-spezifische Ergebnisdaten-Verarbeitungsparameter.
  • Die SM ID Maske kann eine Bitmaske sein, die jede der Ziel(Empfänger) SMs identifiziert. Die Quellen-SM kann die SM-IDs von den entsprechenden CTA-IDs, die in einer Anweisung umfasst sind, durch Abbilden von CTA ID in SM ID basierend auf einer Abbildungstabelle erzeugen. Die CGA ID wird von dem Empfänger verwendet, um die CGA zu identifizieren, zu dem der(die) anfragende(n) Thread(s) gehören. In Implementierungen, wobei ein CGA lediglich ein CTA in einem SM aufweist, kann die CGA ID verwendet werden, um ebenfalls die CTA darzustellen. Der Offset des gemeinsam genutzten Speichers stellt den Offset von der gemeinsam genutzten Speicherbasisadresse für den SM dar, bei dem die Ergebnisdaten geschrieben werden sollten. Der Barrierenadressen-Offset kann von dem Empfänger verwendet werden, um die Barriere zu identifizieren.
  • Die Quellen-SM-ID wird von dem empfangenden SM verwendet, um eine Bestätigung der empfangenen Daten zu senden. Das Ack Phase ID Feld wird von dem empfangenden SM verwendet, um die Phase des MEMBAR-Synchronisationsprotokolls korrekt anzugeben, zu dem ein ack entspricht.
  • Andere Parameter, wie beispielsweise verschiedene Implementierungs-spezifische Parameter, können ebenfalls in den Metadaten umfasst sein. Beispielsweise können in einigen Ausführungsformen in einer TMA-basierten Implementierung TMAspezifische Parameter für Verarbeitungsergebnisdaten durch swizzling (Neuanordnen der Ergebnisdaten beim Schreiben gemäß der Quellen-Tensorattribute), z-filling (Füllen von Speicherorten außerhalb der Grenzen mit einem vorbestimmten Wert) usw. in den Metadaten umfasst sein, um mit dem Anfragepaket bewegt und in dem Ergebnispaket umfasst zu sein, das den empfangenden SM erreicht.
  • Multicast-Antwort
  • Die Antwortdaten (angefragten Daten), die in dem Multicast-Antwortpaket umfasst sind, werden schließlich bei jedem der empfangenden SMs empfangen. Gemäß einigen Ausführungsformen unterhält jeder SM eine Tabellenabbildung von {CGA-ID, CTA-IDin-CGA} in {SMEM Base Address}. Für jede bei einem SM empfangene Antwort wird die obige Abbildungstabelle nachgeschlagen, um die gemeinsam genutzte Speicherbasisadresse zu erhalten, die dem empfangenden CTA entspricht, die in dem Antwortpaket identifiziert ist. Die angefragten Daten, oder der entsprechende Abschnitt davon, wird in den SMEM-Daten-RAM bei {SMEM Base Address, SMEM Offset} geschrieben. Die Offset-Informationen sind in dem empfangenen Antwortpaket umfasst. Es sei bemerkt, dass bestimmte Implementierungs-spezifische Verarbeitung und/oder Organisation (z. B., oben erläuterte Swizzle- und z-fill-Operationen) der Antwortdaten durchgeführt werden kann, bevor oder während die Ergebnisdaten in den gemeinsam genutzten Speicher geschrieben werden.
  • Gemäß einigen Ausführungsformen inkrementiert der empfangenden Prozess zusätzlich auch einen eintreffende Zählwert, welcher der Barrierenadresse {SMEM Base Address, Barrier ID Offset in Packet} entspricht. Der eintreffende Zählwert wird durch die Anzahl von Bytes inkrementiert, die von der Ziel-SM empfangen wird. Nachdem der eintreffende Zählwert inkrementiert ist, wird ein Ack von dem Ziel-SM erzeugt und an die Quellen-SM ID gesendet (die Quellen-SM ID Informationen können in dem empfangenen Antwortpaket umfasst sein), um den Abschluss der Operation an der Ziel-SM zu signalisieren. Für den Ziel-SM kann es nicht erforderlich sein, auf den ack zu warten, um den Quellen-SM zu erreichen.
  • Abschluss/Fehlerhandhabung
  • Der Multicast-Sender-SM verfolgt weiter alle ausstehenden Transaktionen in Zählern. In beispielhaften Ausführungsformen gibt es 2 Typen (sync, async) von ausstehenden Transaktionen und 2 Phasen pro Typ, die verfolgt werden.
  • in dieser Offenbarung beschriebene programmatische Multicast-Lasten sind „async“ Typ von Transaktionen, während direkt verteilter gemeinsam genutzten Speicher in andere SMs schreibt (wie beispielsweise das, welches in der US-Anmeldung-Nr. 17/691,690 beschrieben ist) vom „sync“ Typ sind. Von jedem Empfänger-SM wird erwartet, dass er einen ack-Zählwert für jedes Datenpaket sendet.
  • Mehrere acks können als ein Zählwert für bessere Leistung kombiniert werden. Zu diesem Zweck verfolgt jeder Empfänger-SM Zählwerte pro Quellen-SM und sendet ein ack nur, wenn der Zählwert groß genug ist und der Bus im Leerlauf ist.
  • Im Fall von Fehlern wird stattdessen ein NACK gesendet. Die Fehler können Außerhalb-Bereich-Fehler, CTA bereits verlassen, spezifizierten Offset oder Barriere ist Außerhalb-Bereich usw. umfassen.
  • Die ack/nack-Erzeugung ist nützlich, um zu gewährleisten, dass keine Transaktionen vor Kontextumschaltung, CGA-Verlassen oder Haftstellenhandhabung Im-Flug sind.
  • Der Sender-SM verfolgt weiter total ausstehende Anfragen, nicht pro Empfänger-SM. Er weist separate Zähler für sync, async und die beiden Phasen für jeden Typ auf. Der Empfänger-SM verfolgt jedoch nicht total Acks, die anderen SMs mit einem Zähler pro anderem SM geschuldet sind. Der Sender-SM behält keine Zählwerte pro Empfänger-SM und verfolgt lediglich die Gesamtzahl der angefragten Bytes. Somit behält der Sender einen Zähler jeweils für die sync, async Typen und jede der beiden Phasen. Im Gegensatz dazu weist jeder Empfänger-SM einen Satz von Zählern für jeden potenziellen Quellen-SM auf.
  • Synchronisation
  • Eine Synchronisation weist zwei Aspekte in einigen Ausführungsformen auf: „Daten zur Verwendung bereit“ und MEMBAR.
  • In der „Daten zur Verwendung bereit" Synchronisation im regulären Betrieb können eine oder mehrere Barrieren in einer Anordnung, wie beispielsweise der SYNCS-Einheit, basierend auf Multicast-Antwortdaten aktualisiert werden, die von dem jeweiligen Empfänger empfangen werden. Die SYNCS-Einheit wird in der U.S. Anmeldung-Nr. 17/691,296 beschrieben, die hier in ihrer Gesamtheit durch Bezugnahme aufgenommen ist. Eine Barrierenverwendung, wie beispielsweise in der SYNCS-Einheit, kann das primäre Mittel der Synchronisation für regulären Betrieb sein. Bei dem Programmiermodell für die Barrieren gibt der Quellen-SM ein Laden für eine definierte Anzahl von Bytes aus und die empfangenden SMs warten jeweils darauf, dass eine Barriere für diese Anzahl von Bytes empfangen wird. Die Ladeanweisung kann die Barrierenadresse spezifizieren (z. B. als ein gemeinsam genutzten Speicher-Offset).
  • Jedes Datenantwort aktualisiert die Transaktionen, die aufgetreten sind. Die Transaktionszählwerte sind in Bytes von Daten. Die erwarteten Transaktionen oder Bytes werden ebenfalls in die Barriere programmiert. Die erwarteten Transaktionen können durch den Sender oder den Empfänger programmiert werden und dies kann getan werden bevor, während, oder nachdem die Daten zurückgeführt werden. Die Barriere wird freigemacht, wenn alle Daten empfangen wurden und alle die Barrieren EINTREFFEN, die benötigt werden, um den erwarteten Transaktionszählwert (in Bytes) in die Barriere zu programmieren, abgeschlossen wurden. Jeder Thread, der an der Barriere wartet, kann unter Verwendung der Daten starten, wenn seinem eintreffende Zählwert entsprochen wird.
  • Die MEMBAR-Operation wird verwendet, um sicherzustellen, dass die dem MEMBAR vorangehenden Operationen bereits abgeschlossen wurden oder dass sie allen Operationen sichtbar sind, welche dem MEMBAR folgen.
  • Programmatische Multicast-Lasten sind „asynchrone“ Operationen. Die MEMBAR.CTA oder MEMBAR.GPU warten nicht auf den Abschluss dieser Operationen. MEMBAR.ASYNC kann explizit verwendet werden, um die Sichtbarkeit von allen Operationen an alle CGA-Threads zu gewährleisten. Wenn ein MEMBAR.ASYNC erzeugt wird, dreht sich die aktuelle Betriebsphase herum und die nächste Phase beginnt. Wenn der MEMBAR auf alle Acks wartet, die der aktuellen zu empfangenden Phase entsprechen, und der MEMBAR nicht bis zu einem derartigen Zustand freigemacht wird, wird die nächste Phase verwendet, um nachfolgende Multicast-Operationen zu handhaben. ACK-Zähler werden verwendet, um ausstehenden Operationen zu verfolgen, bevor MEMBAR.ASYNC verworfen wird.
  • Phasen werden verwendet, um neue Multicast-Operationen auszugeben, während darauf gewartet wird, dass vorherige Operationen abgeschlossen werden.
  • Beispielhafte Multicast-Pakettransport-Hardware
  • 7 veranschaulicht ausführlicher die in 2A gezeigten Systemkomponenten gemäß einer Ausführungsform. Gemäß einigen Ausführungsformen entspricht die LRC 704 der LRC 212, die Kreuzschiene 706 entspricht den Kreuzschienen 208-210 und der GPC 708 entspricht dem GPC 202. Die GPU 700 umfasst zwei Mikro-GPUs 702. Jede Mikro-GPU 702 umfasst mehrere LRCs 704. Jede LRC 704 kommuniziert mit einem L2-Slice (nicht gezeigt).
  • Acht Slices sind mit jedem Kreuzschienenschalter 706 verbunden, der ein Schalternetzwerk von LRC oder genauer gesagt 6 Frame Pufferpartitionen (FBPs) ist, wobei jede FBP 8 Slices mit 2 Ports pro Slice aufweist, an SMs ist. Der Kreuzschienenschalter 706 umfasst sechs primäre Schalter und sechs sekundäre Schalter. Jeder Schalter kann als zwei getrennte Schaltnetzwerke aufgebaut sein, beispielsweise mit einem Schaltnetzwerk für Pakete mit einer ungeraden nummerierten CPC-ID und einem zweiten Schaltnetzwerk für Pakete mit einer geraden nummerierten CPC-ID. Das Schaltnetzwerk, auf das ein Paket der LRC zu senden ist, wird basierend auf der CPC-ID von diesen Paketen ausgewählt. Die Ausgaben von jedem von diesen kann zu jedem der Zuteiler auf jedem Compute Processing Cluster (CPC) multidropped werden.
  • Die GPU 700 umfasst mehrere GPC 708, wobei jeder GPC mehrere CPC 710 aufweist und jeder CPC mehrere SMs 712 aufweist. Ein CPC ist ein Satz von TPCs in dem GPC, die zusammen in der physikalischen Ausgestaltung des GPC optimiert werden. Die 6 primären und 6 sekundären Schalter der LRC 704, jeweils mit 8 eingehenden L2-Slices, speisen in den GPC. Jeder CPC umfasst zwei Zuteiler, die jeweils 4 Ports aufweisen, um 24 Ports der Eingabe in jeden GPC aufzuweisen. Die Speicheranfragen werden in der neuen Koaleszenzeinheit des L2 gehandhabt. Sobald ein Lesen/Laden an den L2 selbst weitergeleitet wird und die LRC ist zum Halten der Liste (z. B. in der Form einer Bitmaske) von Multicast-Zielen und Hilfsdaten (wie beispielsweise ZFILL, Zieloffsets) während der Zeit verantwortlich ist, bei welcher der L2 das Lesen ausführt, und dann werden die gespeicherten Hilfsdaten an der durch L2 erzeugten Antwort befestigt.
  • Ein beispielhafter Multidrop ist deutlicher in 8 erkennbar. Ein beliebiges Paket, das auf die Verbindung 802 durch die Kreuzschiene 706 multidropped wird, wird von allen GXC_CPCs empfangen und die Ausführungsformen können sich auf jede GXC_CPCs stützen, um zu prüfen, ob ihr cpc_id Bit in der cpc_id_bitmask des eingehenden Pakets gesetzt ist. wenn das cpc_id Bit gesetzt ist, wird GXC das Paket zu seinem jeweiligen GNIC/GPCARB (GPC-Zuteiler) 714 weiterleiten oder wird dieses Paket andernfalls verwerfen. Pakete von einem beliebigen der Ports (in diesem Beispiel 24 Ports) der Kreuzschiene 706 werden auf den einzigen Draht 802 gebracht, wobei jedes Paket die ID von jedem CPC aufweist, auf dem ein Ziel-SM liegt. Bevor ein Paket in dem GNIC 808 empfangen wird, wird es bei allen GXC_CPC 806 in dem GXC 804 empfangen das Paket und jeder GXC_CPC prüft die CPC-ID des Pakets und verarbeitet das Paket nur, wenn die CPC-ID des Pakets und die des CPC übereinstimmen. Lediglich die Pakete, deren ID dem entsprechenden CPC entspricht, werden an die GPCARB-EG 714 über die Schnittstelle 808 weitergeleitet.
  • Wenn ein Paket an dem GPC 708 eingeht und zu einem Ziel-CPC 710 gefiltert wird, kommt es an einem von zwei GPC-Zuteilern 714 an, die auf dem CPC 710 gehostet werden. Jeder Zuteiler 714 ist imstande, zu einem beliebigen SM 712 auf diesem CPC zu senden. Der Zuteiler kann ein Schema implementieren, um den Fluss von Antworten zu jedem SM auf der gleichen CPC zu steuern.
  • 9A veranschaulicht einen beispielhaften Kreuzschienen-Multidrop-Schalter 900, wie beispielsweise den in 7 gezeigten Kreuzschienenschalter 706, der das gerade/ungerade Multidrop-Sub-Netzwerk basierend auf einem relevanten Round-Robin-Zeiger auswählen und die gesamte entsprechende Transaktion auf diesem gegebenen ausgewählten Teilnetzwerk planen wird.
  • Der Kreuzschienenschalter 900 wird lediglich Kredite für Ports zu CPCs konsumieren, welche die Ziel-SMs aufweisen. Außerdem wird ein Multidrop-Paket nur als eine Ganzes gutgeschrieben werden, als ob alle seine Ziele Kredite verfügbar haben. Sogar wenn eines der Ziele keine Kredite aufweist, wird das gegebene Paket stecken bleiben.
  • Nachdem das Multidrop-Teilnetzwerk ausgewählt ist, werden eingehende Pakete des L2-Slice in einer Eingangswarteschlange 910 gehalten und die Krediterfassung zur Übertragung von diesem Paket wird durchgeführt. Für Multicast-Pakete ist der Credit-Zähler 904 konfiguriert, um Kredite für jedes Ziel der Multicast-Pakete zu erhalten. Der Credit-Zähler 904 bestimmt beispielsweise die Anzahl von CPCs, zu denen das Paket zu multicasten ist, und erhält zusammen mit vc Kreditlogik 912 Kredite für jeden CPC, zu dem das Paket gerichtet ist.
  • Der Verteiler 906 führt front fill, back fill und gemäß einem Algorithmus, wie beispielsweise NSLIP oder Wavefront Alignment Algorithm (WFA), für Pakete durch, für welche die Kredite erfasst wurden und signalisiert einen Grant oder keinen Grant. Wenn ein Signal eines Grant von angefragten Kredit empfangenen wird, wird das Paket durch eine Schalter-Fabric 908 an die ausgewählten Ziel-CPCs übertragen.
  • 9B veranschaulicht einen beispielhaften GPCARB-Multicast-Schalter 920 gemäß einigen Ausführungsformen. Ein Schalter 920 kann in jedem GPC-Zuteiler 714 umfasst sein, der in Relation zu 7 beschrieben ist, um ein multi-dropped Paket von der Kreuzschiene zu empfangen und es an die in diesem CPC befindlichen Ziel-SMs zu multicasten.
  • Pakete der Kreuzschiene 706 kommen am Eingang des Schalters 920 an und werden in einer Eingangswarteschlange 922 gehalten und die Credit-Erfassung findet in Credit-Zählern 924 statt. Wie gezeigt, werden innerhalb des Credit-Zählers 924 die Kredite für Unicast und Multicast getrennt implementiert. Ein Multicast-Credit-Zähler 934 arbeitet zuerst gefolgt von den Unicast-Credit-Zählern. Da der Multicast-Credit-Zähler 934 keinen Kredit erhalten kann, es sei denn, dass alle Empfänger verfügbare Kredite aufweisen, kann es zu einem verbesserten Multicast-Paketdurchsatz kommen, wenn dem Multicast-Credit-Zähler 934 Priorität gegeben wird. Ein Kreditmanager 932 kann konfiguriert sein, um den Multicast-Credit-Zähler 934 über die Unicast-Credit-Zähler beim Zuteilen von Krediten an Unicast und Multicast zu priorisieren. Der Multicast-Credit-Zähler 934 erhält Kredit-Quellen für jeden Ziel-SM, bevor das Paket gesendet wird.
  • Nachdem die Kredite erhalten werden, teilt der Verteiler 926 nicht in Konflikt stehende Quellen unter Verwendung eines kaskadierten zuallerletzt verwendeten Zuteilers oder einer anderen Planungstechnik zu. In einigen Ausführungsformen können Starvation-Vermeidungsmechanismen implementiert sein, um Bandbreite/Transaktions-Fairness zu erzwingen.
  • Der GPC-Zuteilerschalter kann Threads für Multicast-Pakete trennen. Beispielsweise kann ein Thread pro virtueller Quellenkanal umfasst sein. Beim Gutschreiben würde ein Multicast-Paket nur gutgeschrieben werden, wenn alle seine Ziele verfügbare Kredite aufweisen.
  • Multicast-Arbitration kann in der Vorfüllstufe stattfinden. Eine Technik, wie beispielsweise eine zuallerletzt verwendete (LRU), Multicast-Arbitration mit fester Priorität, kann benutzt werden. Nachdem Multicast-Pakete in einem Frame enthalten sind, können die übrig gebliebenen Löcher mit Unicast-Anfragen bei den Frontfüll- und die Rückfüllstufen gefüllt werden. Diese Multicast-Pakete würden gesendet werden, bis der Konfliktauflösungszuteiler nach dem GPC-Zuteiler-Demultiplexer, wobei sie an diesem Punkt in Unicast-Pakete umgewandelt werden würden, bevor sie von den vorgesehenen SMs empfangen werden.
  • Beispielhafte GPU-Architektur
  • Eine beispielhafte veranschaulichende Architektur, bei welcher der in dieser Anmeldung offenbarte programmatische Multicast aufgenommen ist, wird nun beschrieben. Die folgenden Informationen werden für veranschaulichende Zwecke dargelegt und sollten nicht in irgendeiner Art Weise als einschränkend ausgelegt werden. Jedes der folgenden Merkmalen kann optional mit oder ohne den Ausschluss von anderen beschriebenen Merkmalen aufgenommen werden.
  • 10 veranschaulicht eine Parallelverarbeitungseinheit (PPU) 1000 gemäß einer Ausführungsform. In einer Ausführungsform ist die PPU 1000 ein Multi-Thread-Prozessor, der auf einer oder mehreren integrierten Schaltungsvorrichtungen implementiert ist. Die PPU 1000 ein Multi-Threaded-Prozessor bzw. mehrsträngiger Prozessor, der auf einer oder mehreren integrierten Schaltungsvorrichtungen implementiert ist. Die PPU 1000 ist eine Latenz-verbergende Architektur, die ausgestaltet ist, um eine große Anzahl von Threads bzw. Strängen parallel zu verarbeiten. Ein Thread bzw. Strang (z. B. ein Ausführungsthread) ist eine Instanziierung eines Satzes von Anweisungen, die konfiguriert sind, um von der PPU 1000 ausgeführt zu werden. In einer Ausführungsform ist die PPU 1000 eine Graphikverarbeitungseinheit (GPU), die konfiguriert ist, um eine Graphik-Rendering-Pipeline zur Verarbeitung von dreidimensionalen (3D) Graphikdaten zu implementieren, um zweidimensionale (2D) Bilddaten zur Anzeige auf einer Anzeigevorrichtung, wie beispielsweise einer Flüssigkristallanzeige(LCD)-Vorrichtung, zu erzeugen. In anderen Ausführungsformen kann die PPU 1000 zum Durchführen von Allzweckberechnungen benutzt werden. In einigen anderen Ausführungsformen ist die PPU 100 konfiguriert, um große neuronale Netzwerke bei Deep-Learning-Anwendungen oder anderen Hochleistungsrechenanwendungen zu implementieren.
  • Eine oder mehrere PPUs 1000 können konfiguriert sein, um Tausende von HPC(High Performing Computing)-, Rechenzentrum-, Cloud-Computing- und Maschinenlern-Anwendungen zu beschleunigen. Die PPU 1000 kann konfiguriert sein, um zahlreiche Deep-Learning-Systeme und Anwendungen für autonome Fahrzeuge, Simulation, Rechengraphik zu beschleunigen, wie beispielsweise Strahlen- oder Pfadverfolgung, Deep-Learning, hochgenaue Sprache, Bild- und Texterkennungssysteme, intelligente Videoanalyse, molekulare Simulationen, Wirkstoffentdeckung, Krankheitsdiagnose, Wettervorhersage, Analyse großer Datenmengen, Astronomie, Molekulardynamiksimulation, Finanzmodellierung, Robotertechnik, Fabrikautomation, Sprachübersetzung in Echtzeit, Online-Suchoptimierungen und personalisierte Benutzerempfehlungen und dergleichen.
  • Wie in 10 gezeigt, umfasst die PPU 1000 eine Eingabe/Ausgabe(E/A)-Einheit 1005, eine Frontend-Einheit 1015, eine Planereinheit 1020, eine Arbeitsverteilungs-Einheit 1025, einen Hub 1030, eine Kreuzschiene (Xbar) 1070, einen oder mehrere allgemeine Verarbeitungscluster (GPCs) 1050 und eine oder mehrere Speicherpartitionseinheiten 1080. Die PPU 1000 kann mit einem Host-Prozessor oder anderen PPUs 1000 über eine Zwischenverbindung des Hochgeschwindigkeits-NVLink 1010 verbunden sein. Die PPU 1000 kann ebenfalls mit einem Host-Prozessor oder anderen peripheren Vorrichtungen über eine Zwischenverbindung 1002 verbunden sein. Die PPU 1000 kann ebenfalls mit einem lokalen Speicher 1004 verbunden sein, der eine Anzahl von Speichervorrichtungen umfasst. In einer Ausführungsform kann der lokale Speicher eine Anzahl von Direktzugriffsspeicher(DRAM)-Vorrichtungen umfassen. Die DRAM-Vorrichtungen können als ein HBM(Speicher mit hoher Bandbreite)-Subsystem konfiguriert sein, wobei mehrere DRAM-Dies innerhalb jeder Vorrichtung gestapelt sind.
  • Die Zwischenverbindung des NVLink 1010 ermöglicht Systemen, eine oder mehrere PPUs 1000 zu skalieren und zu umfassen, die mit einer oder mehreren CPUs kombiniert sind, unterstützt Cache-Kohärenz zwischen den PPUs 1000 und CPUs sowie CPU-Mastering. Daten und/oder Befehle können mittels des NVLink 1010 durch den Hub 1030 an/von anderen Einheiten der PPU 1000, wie beispielsweise eine oder mehrere Kopiermaschinen, einen Videocodierer, einen Videodecodierer, eine Leistungsverwaltungseinheit usw. (nicht explizit gezeigt) übertragen werden. Das NVLink 1010 wird ausführlicher in Verbindung mit 13A und 13B beschrieben.
  • Die E/A-Einheit 1005 ist konfiguriert, um Kommunikationen (z. B. Befehle, Daten usw.) von einem Host-Prozessor (nicht gezeigt) über die Zwischenverbindung 1002 zu übertragen und zu empfangen. Die E/A-Einheit 1005 kann mit dem Host-Prozessor direkt über die Zwischenverbindung 1002 oder durch eine oder mehrere Zwischenvorrichtungen, wie beispielsweise eine Speicherbrücke, kommunizieren. In einer Ausführungsform kann die E/A-Einheit 1005 mit einem oder mehreren anderen Prozessoren, wie beispielsweise eine oder mehrere der PPUs, über die Zwischenverbindung 1002 kommunizieren. In einer Ausführungsformen implementiert die E/A-Einheit 1005 eine PCIe(Peripheral Component Interconnect Express)-Schnittstelle für Kommunikationen über einen PCIe-Bus und die Zwischenverbindung 1002 ist ein PCIe-Bus. In alternativen Ausführungsformen kann die E/A-Einheit 1005 andere Typen von wohlbekannten Schnittstellen zum Kommunizieren mit externen Vorrichtungen umfassen.
  • Die E/A-Einheit 1005 decodiert Pakete, die über die Zwischenverbindung 1002 empfangen wurden. In einer Ausführungsform stellen die Pakete Befehle dar, die konfiguriert sind, um die PPU 1000 zu veranlassen, verschiedene Operationen durchzuführen. Die E/A-Einheit 1005 überträgt die decodierten Befehle an verschiedene andere Einheiten der PPU 1000, wie es die Befehle spezifizieren können. Beispielsweise können einige Befehle an die Frontend-Einheit 1015 übertragen werden. Andere Befehle können an den Hub 1030 oder andere Einheiten der PPU 1000, wie beispielsweise eine oder mehrere Kopiermaschinen, einen Video-Codierer, einen Video-Decodierer, eine Leistungsverwaltungseinheit usw. (nicht explizit gezeigt) übertragen werden. Mit anderen Worten ist die E/A-Einheit 1005 konfiguriert, um Kommunikationen zwischen und unter den verschiedenen logischen Einheiten der PPU 1000 weiterzuleiten.
  • In einer Ausführungsform codiert ein Programm, das von dem Host-Prozessor ausgeführt wird, einen Befehlsstrom in einem Puffer, welcher der PPU 1000 Arbeitslasten zur Verarbeitung bereitstellt. Eine Arbeitslast kann mehrere Anweisungen und Daten umfassen, die von diesen Anweisungen zu verarbeiten sind. Der Puffer ist ein Bereich in einem Speicher, der von sowohl dem Host-Prozessor als auch der PPU 1000 zugänglich ist (z. B. Lesen/Schreiben). Beispielsweise kann die Host-Schnittstelleneinheit 1010 konfiguriert sein, um auf den Puffer in einem Systemspeicher, der mit der Zwischenverbindung 1002 verbunden ist, über Speicheranfragen, die über die Zwischenverbindung 1002 übertragen werden, zuzugreifen. In einer Ausführungsform schreibt der Host-Prozessor den Befehlsstrom in den Puffer und überträgt dann einen Zeiger zu dem Start des Befehlsstroms an die PPU 1000. Die Frontend-Einheit 1015 empfängt Zeiger auf einen oder mehrere Befehlsströme. Die Frontend-Einheit 1015 verwaltet den einen oder mehrere Ströme, liest Befehle von den Strömen und leitet Befehle an die verschiedenen Einheiten der PPU 1000 weiter.
  • Die Frontend-Einheit 1015 ist mit einer Planereinheit 1020 gekoppelt, welche die verschiedenen GPCs 1050 konfiguriert, um Aufgaben zu verarbeiten, die durch den einen oder mehrere Ströme definiert sind. Die Planereinheit 1020 ist konfiguriert, um Zustandsinformation zu verfolgen, die verschiedene Aufgaben betrifft, die von der Planereinheit 1020 verwaltet werden. Der Zustand kann angeben, welchem GPC 1050 eine Aufgabe zugewiesen ist, ob die Aufgabe aktiv oder inaktiv ist, ob ein Prioritätsniveau der Aufgabe zugeordnet ist und so weiter. Die Planereinheit 1020 verwaltet die Ausführung einer Mehrzahl von Aufgaben auf dem einen oder mehreren GPCs 1050.
  • Die Planereinheit 1020 ist mit einer Arbeitsverteilungs-Einheit 1025 gekoppelt, die konfiguriert ist, um Aufgaben zur Ausführung auf den GPCs 1050 zu versenden. Die Arbeitsverteilungs-Einheit 1025 kann eine Anzahl von eingeplanten Aufgaben verfolgen, die von der Planereinheit 1020 empfangen werden. In einer Ausführungsform verwaltet die Arbeitsverteilungs-Einheit 1025 einen Pool für anhängige Aufgaben und einen Pool für aktive Aufgaben für jeden der GPCs 1050. Der Pool für anhängige Aufgaben kann eine Anzahl von Slots (z. B. 102 Slots) umfassen, die Aufgaben enthalten, die zugewiesen sind, um von einem bestimmten GPC 1050 verarbeitet zu werden. Der Pool für aktive Aufgaben kann eine Anzahl von Slots (z. B. 4 Slots) für Aufgaben umfassen, die von den GPCs 1050 aktiv verarbeitet werden. Wenn ein GPC 1050 die Ausführung einer Aufgabe abschließt, wird diese Aufgabe aus dem Pool für aktive Aufgaben für den GPC 1050 geräumt und eine der anderen Aufgaben wird aus dem Pool für anhängige Aufgaben ausgewählt und zur Ausführung auf dem GPC 1050 eingeplant. Wenn eine aktive Aufgabe auf dem GPC 1050 inaktiv war, wie beispielsweise während darauf gewartet wird, dass eine Datenabhängigkeit behoben wird, dann kann die aktive Aufgabe aus dem GPC 1050 geräumt und zu dem Pool für anhängige Aufgaben zurückgeführt werden, während eine weitere Aufgabe in dem Pool für anhängige Aufgaben ausgewählt und zur Ausführung auf dem GPC 1050 eingeplant wird.
  • Die Arbeitsverteilungs-Einheit 1025 kommuniziert mit dem einen oder mehreren GPCs 1050 über eine Kreuzschiene bzw. XBar 1070. Die XBar 1070 ist ein Zwischenverbindungs-Netzwerk, das viele der Einheiten der PPU 1000 mit anderen Einheiten der PPU 1000 koppelt. Beispielsweise kann die XBar 1070 konfiguriert sein, um die Arbeitsverteilungs-Einheit 1025 mit einem bestimmten GPC 1050 zu koppeln. Obwohl nicht explizit gezeigt, können eine oder mehrere andere Einheiten der PPU 1000 ebenfalls mit der XBar 1070 über den Hub 1030 verbunden sein.
  • Die Aufgaben werden von der Planereinheit 1020 verwaltet und an einen GPC 1050 von der Arbeitsverteilungs-Einheit 1025 versandt. Der GPC 1050 ist konfiguriert, um die Aufgabe zu verarbeiten und Ergebnisse zu erzeugen. Die Ergebnisse können von anderen Aufgaben innerhalb des GPC 1050 konsumiert werden, an einen unterschiedlichen GPC 1050 über die XBar 1070 weitergeleitet oder im Speicher 1004 gespeichert werden. Die Ergebnisse können in den Speicher 1004 über die Speicherpartitionseinheiten 1080 geschrieben werden, die eine Speicherschnittstelle zum Lesen und Schreiben von Daten in/von dem Speicher 1004 implementieren. Die Ergebnisse können an eine andere PPU 1000 oder CPU über den NVLink 1010 übertragen werden. In einer Ausführungsform umfasst die PPU 1000 eine Anzahl U von Speicherpartitionseinheiten 1080, die gleich der Anzahl von getrennten und unterschiedlichen Speichervorrichtungen des Speichers 1004 ist, die mit der PPU 1000 gekoppelt sind. Eine Speicherpartitionseinheit 1080 wird nachstehend ausführlicher in Verbindung mit 4B beschrieben.
  • In einer Ausführungsform führt ein Host-Prozessor einen TreiberKernel aus, der eine anwendungsprogrammierbare Schnittstelle (API) implementiert, die einer oder mehreren Anwendungen ermöglicht, die auf dem Host-Prozessor ausgeführt werden, Operationen zur Ausführung auf der PPU 1000 einzuplanen. In einer Ausführungsform werden mehrere Rechenanwendungen gleichzeitig von der PPU 1000 ausgeführt und die PPU 1000 stellt Isolierung, Dienstqualität (QoS) und unabhängige Adressräume für die mehreren Rechenanwendungen bereit. Eine Anwendung kann Anweisungen (z. B. API-Aufrufe) erzeugen, welche den TreiberKernel veranlassen, eine oder mehrere Aufgaben zur Ausführung durch die PPU 1000 zu erzeugen. 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 in Beziehung stehender Threads umfassen, die hier als ein Warp bezeichnet werden. In einer Ausführungsform umfasst ein Warp 102 in Beziehung stehende Threads, die parallel ausgeführt werden können. Kooperierende Threads können sich auf eine Mehrzahl von Threads beziehen, die Anweisungen umfassen, um die Aufgabe durchzuführen, und die Daten durch einen gemeinsam benutzten Speicher austauschen können. Threads, kooperierende Threads und eine hierarchische Gruppierung von Threads, wie beispielsweise kooperierende Thread-Arrays ()CTA kooperierende Gruppen-Arrays (CGA) gemäß einigen Ausführungsformen werden ausführlicher in der U.S.-Anmeldung Nr. 17/691,621 beschrieben, deren gesamter Inhalt hier durch Bezugnahme aufgenommen ist.
  • 11A veranschaulicht einen GPC 1050 der PPU 1000 von 10 gemäß einer Ausführungsform. Wie in 11A gezeigt, umfasst jeder GPC 1050 eine Anzahl von Hardwareeinheiten zur Verarbeitung von Aufgaben. In einer Ausführungsform umfasst jeder GPC 1050 einen Pipeline-Manager 1110, eine Vor-Raster-Operationen-Einheit (PROP) 1115, eine Raster-Engine 1125, eine Arbeitsverteilungs-Kreuzschiene (WDX) 1180, eine Speicherverwaltungseinheit (MMU) 1190 und einen oder mehrere Datenverarbeitungscluster (DPCs) 1120. Es wird anerkannt, dass der GPC 1050 von 11A andere Hardwareeinheiten anstelle von oder zusätzlich zu den in 11A gezeigten Einheiten umfassen kann.
  • In einer Ausführungsform wird der Betrieb des GPC 1050 durch den Pipeline-Manager 1110 gesteuert. Der Pipeline-Manager 1110 verwaltet die Konfiguration des einen oder mehrerer DPCs 1120 zur Verarbeitung von Aufgaben, die dem GPC 1050 zugeteilt sind. In einer Ausführungsform kann der Pipeline-Manager 1110 mindestens einen des einen oder mehrerer DPCs 1120 konfigurieren, um mindestens einen Abschnitt einer Graphik-Rendering-Pipeline, eines neuronalen Netzwerks und /oder einer Rechenpipeline zu implementieren. Beispielsweise kann mit Bezug eine Graphik-Rendering-Pipeline ein DPC 1120 konfiguriert sein, um ein Vertex-Shader-Programm auf dem programmierbaren Streaming-Multiprozessor (SM) 1140 auszuführen. Der Pipeline-Manager 1110 kann ebenfalls konfiguriert sein, um Pakete, die von der Arbeitsverteilungs-Einheit 1025 empfangen werden, an die geeigneten logischen Einheiten innerhalb des GPC 1050 weiterzuleiten. Beispielsweise können einige Pakete an Festfunktions-Hardwareeinheiten in der PROP 1115 und/oder der Raster-Engine 1125 weitergeleitet werden, während andere Pakete an die DPCs 1120 zur Verarbeitung durch die Primitiven-Engine 1135 oder den SM 1140 weitergeleitet werden können. In einer Ausführungsform kann der Pipeline-Manager 1110 mindestens einen der einen oder mehreren DPCs 1120 konfigurieren, um ein Neuronal-Netzwerkmodell und/oder eine Rechen-Pipeline zu implementieren.
  • Die PROP-Einheit 1115 ist konfiguriert, um Daten, die von der Raster-Engine 1125 und den DPCs 1120 erzeugt werden, an eine Raster-Operationen-Einheit (ROP-Einheit) in der Speicherpartitionseinheit 1080 weiterzuleiten, die nachstehend ausführlicher in Verbindung mit 11B beschrieben ist. Die PROP-Einheit 1115 kann ebenfalls konfiguriert sein, um Optimierungen zur Farbenmischung durchzuführen, Pixeldaten zu organisieren, Adressenübersetzungen und dergleichen durchzuführen.
  • Jeder DPC 1120, der in dem GPC 1050 umfasst ist, umfasst einen M-Pipe-Controller (MPC) 1130, eine Primitiven-Engine 1135 und einen oder mehrere SMs 1140. Der MPC 1130 steuert den Betrieb des DPC 1120, wobei von dem Pipeline-Manager 1110 empfangene Pakete an die geeigneten Einheiten im DPC 1120 weitergeleitet werden. Beispielsweise können einem Vertex zugeordnete Pakete an die Primitiven-Engine 1135 weitergeleitet werden, die konfiguriert ist, um der Vertex zugeordnete Vertexattribute von dem Speicher 1004 zu holen. Im Gegensatz dazu können einem Shader-Programm zugeordnete Pakete an den SM 1140 übertragen werden.
  • Der SM 1140 umfasst einen programmierbaren Streaming-Prozessor, der konfiguriert ist, um Aufgaben zu verarbeiten, die durch eine Anzahl von Threads dargestellt werden. Jeder SM 1140 umfasst mehrere Threads (ist multi-threaded) und ist konfiguriert, um eine Mehrzahl von Threads (z. B. 102 Threads) von einer bestimmten Gruppe von Threads nebenläufig auszuführen. In einer Ausführungsform implementiert der SM 1140 eine SIMD(Einzelne-Anweisung, Mehrere-Daten)-Architektur, wobei jeder Thread in einer Gruppe von Threads (z. B. einem Warp) konfiguriert ist, um einen unterschiedlichen Satz von Daten basierend auf dem gleichen Satz von Anweisungen zu verarbeiten. Alle Threads in der Gruppe von Threads führen die gleichen Anweisungen aus. In einer anderen Ausführungsform implementiert der SM 1140 eine SIMT(Einzelne Anweisung, Mehrere Threads)-Architektur, wobei jeder Thread in einer Gruppe von Threads konfiguriert ist, um einen unterschiedlichen Satz von Daten basierend auf dem gleichen Satz von Anweisungen zu verarbeiten, wobei jedoch einzelnen Threads in der Gruppe von Threads ermöglicht wird, während der Ausführung zu divergieren. In einer Ausführungsform wird ein Programmzähler, ein Aufrufstapel und ein Ausführungszustand für jeden Warp beibehalten, was eine Nebenläufigkeit zwischen Warps und eine serielle Ausführung innerhalb Warps ermöglicht, wenn Threads innerhalb des Warp divergieren. In einer weiteren Ausführungsform wird ein Programmzähler, ein Aufrufstapel und ein Ausführungszustand für jeden einzelnen Thread beibehalten, was eine gleiche Nebenläufigkeit zwischen allen Threads, innerhalb und zwischen Warps ermöglicht. Wenn der Ausführungszustand für jeden einzelnen Thread beibehalten wird, können Threads, welche die gleichen Anweisungen ausführen, konvergiert und für maximale Effizienz parallel ausgeführt werden. Der SM 1140 wird ausführlicher nachstehend in Verbindung mit 12A beschrieben.
  • Die MMU 1190 stellt eine Schnittstelle zwischen dem GPC 1050 und der Speicherpartitionseinheit 1080 bereit. Die MMU 1190 kann eine Übersetzung von virtuellen Adressen in physische Adressen, einen Speicherschutz und eine Arbitrierung von Speicheranfragen bereitstellen. In einer Ausführungsform stellt die MMU 1190 einen oder mehrere Adressenübersetzungspuffer (Translation Lookaside Buffers; TLBs) zum Durchführen der Übersetzung von virtuellen Adressen in physische Adressen in dem Speicher 1004 bereit.
  • 11B veranschaulicht eine Speicherpartitionseinheit 1080 der PPU 1000 von 10 gemäß einer Ausführungsform. Wie in 11B gezeigt, umfasst die Speicherpartitionseinheit 1080 eine Raster-Operationen(ROP)-Einheit 1150, einen L2-Cache-Speicher 1160 und eine Speicherschnittstelle 1170. Die Speicherschnittstelle 1170 ist mit dem Speicher 1004 gekoppelt. Die Speicherschnittstelle 1170 kann 102-, 64-, 128-, 1024-Bit-Datenbusse oder dergleichen für Hochgeschwindigkeits-Datentransfer implementieren. In einer Ausführungsform umfasst die PPU 1000 U Speicherschnittstellen 1170, eine Speicherschnittstelle 1170 pro Paar von Speicherpartitionseinheiten 1080, wobei jedes Paar von Speicherpartitionseinheiten 1080 mit einer entsprechenden Speichervorrichtung des Speichers 1004 verbunden ist. Beispielsweise kann die PPU 1000 mit bis zu Y Speichervorrichtungen, wie beispielsweise einem Speicherstapel mit hoher Bandbreite oder Graphikdoppeldatenraten, Version 5 SDRAM oder anderen Arten von persisten Speicher verbunden sein.
  • In einer Ausführungsform implementiert die Speicherschnittstelle 1170 eine HBM2-Speicherschnittstelle und Y ist gleich einem halben U. In einer Ausführungsform sind die HBM2-Speicherstapel auf der gleichen physischen Packung wie die PPU 1000 lokalisiert, die wesentliche Leistungs- und Flächeneinsparungen verglichen mit herkömmlichen GDDR5 SDRAM Systemen bereitstellt. In einer Ausführungsform umfasst jeder HBM2-Stapel vier Speicher-Dies und Y ist gleich 4, wobei der HBM2-Stapel zwei 128-Bit Kanäle pro Die für eine Gesamtzahl von 8 Kanälen und eine Datenbusbreite von 1024 Bit umfasst.
  • In einer Ausführungsform unterstützt der Speicher 1004 Einzelfehlerkorrektur-Doppelfehlerdetektion (SECDED) (ECC), um Daten zu schützen. Der ECC stellt eine höhere Zuverlässigkeit für Rechenanwendungen bereit, die gegen Datenverfälschung empfindlich sind. Zuverlässigkeit ist besonders wichtig in großen Cluster-Rechenumgebungen, wo PPUs 1000 sehr große Datensätze verarbeiten und/oder Anwendungen für längere Zeiträume ausführen.
  • In einer Ausführungsform implementiert die PPU 1000 eine Mehr-Ebenen-Speicherhierarchie. In einer Ausführungsform unterstützt die Speicherpartitionseinheit 1080 einen vereinheitlichten Speicher, um einen einzigen vereinheitlichten virtuellen Adressraum für den Speicher der CPU und den Speicher der PPU 1000 bereitzustellen, der Datenteilung zwischen virtuellen Speichersystemen ermöglicht. In einer Ausführungsform wird die Häufigkeit von Zugriffen durch eine PPU 1000 auf einen Speicher, der auf anderen Prozessoren lokalisiert ist, verfolgt, um sicherzustellen, dass Speicherseiten in den physischen Speicher der PPU 1000 bewegt werden, die häufiger auf die Seiten zugreift. In einer Ausführungsform unterstützt das NVLink 1010 Adressenübersetzungsdienste, die der PPU 1000 erlauben, auf Seitentabellen einer CPU direkt zuzugreifen und einen vollen Zugriff auf den CPU-Speicher durch die PPU 1000 bereitstellen.
  • In einer Ausführungsform transferieren Kopiermaschinen Daten zwischen mehreren PPUs 1000 oder zwischen PPUs 1000 und CPUs. Die Kopiermaschinen können Seitenfehler für Adressen erzeugen, die nicht in den Seitentabellen abgebildet werden. Die Speicherpartitionseinheit 1080 kann dann die Seitenfehler bedienen, wobei die Adressen in der Seitentabelle abgebildet werden, nachdem die Kopiermaschine den Transfer durchführen kann. In einem herkömmlichen System ist der Speicher für mehrere Kopiermaschinenoperationen zwischen mehreren Prozessoren gesperrt (z. B. nicht auslagerbar), was den verfügbaren Speicher wesentlich verringert. Mit Hardware-Seiten-Faulting können Adressen an die Kopiermaschinen weitergeleitet werden, ohne sich Sorgen zu machen, ob die Speicherseiten resident sind und das Kopierverfahren transparent ist.
  • Daten von dem Speicher 1004 oder einem anderen Systemspeicher können von der Speicherpartitionseinheit 1080 geholt und in dem L2-Cache-Speicher 1160 gespeichert werden, der Auf-Chip lokalisiert ist und zwischen den verschiedenen GPCs 1050 gemeinsam benutzt wird. Wie gezeigt, umfasst jede Speicherpartitionseinheit 1080 einen Bereich des L2-Cache-Speichers 1160, der einem entsprechenden Speicher 1004 zugeordnet ist. Cache-Speicher niedrigerer Ebene können dann in verschiedenen Einheiten innerhalb der GPCs 1050 implementiert werden. Beispielsweise kann jeder der SMs 1140 einen L1-Cache-Speicher implementieren. Der Ll-Cache-Speicher ist ein privater Speicher, der einem bestimmten SM 1140 fest zugeordnet ist. Daten von dem L2-Cache-Speicher 1160 können geholt und in jedem der Ll-Cache-Speicher zur Verarbeitung in den Funktionseinheiten der SMs 1140 gespeichert werden. Der L2-Cache-Speicher 1160 ist mit der Speicherschnittstelle 1170 und der XBar 1070 gekoppelt.
  • Die ROP-Einheit 1150 führt Graphik-Raster-Operationen durch, welche die Pixelfarbe betreffen, wie beispielsweise Farbenkomprimierung, Pixelmischung und dergleichen. Die ROP-Einheit 1150 implementiert ebenfalls Tiefentesten in Verbindung mit der Raster-Engine 1125, wobei eine Tiefe für einen Abtastort, der einem Pixelfragment zugeordnet ist, von der Aussonderungs-Engine der Raster-Engine 1125 empfangen wird. Die Tiefe wird gegen eine entsprechende Tiefe in einem Tiefenpuffer für einen Abtastort geprüft, der dem Fragment zugeordnet ist. Wenn das Fragment den Tiefentest für den Abtastort besteht, dann aktualisiert die ROP-Einheit 1150 den Tiefenpuffer und überträgt ein Ergebnis des Tiefentests an die Raster-Engine 1125. Es wird anerkannt, dass sich die Anzahl von Speicherpartitionseinheiten 1080 von der Anzahl von GPCs 1050 unterscheiden kann, und daher kann jede ROP-Einheit 1150 mit jedem der GPCs 1050 gekoppelt werden. Die ROP-Einheit 1150 verfolgt Pakete, die von den unterschiedlichen GPCs 1050 empfangen werden, und bestimmt, zu welchem GPC 1050 ein durch die ROP-Einheit 1150 erzeugtes Ergebnis durch die Xbar 1170 weitergeleitet wird. Obwohl die ROP-Einheit innerhalb der Speicherpartitionseinheit 1080 in 11B umfasst ist, kann die ROP-Einheit 1150 außerhalb der Speicherpartitionseinheit 1080 sein. Beispielsweise kann die ROP-Einheit 1150 in dem GPC oder einer anderen Einheit liegen.
  • 12 veranschaulicht den Streaming-Multiprozessor 1140 von 11A gemäß einer Ausführungsform. Wie in 12 gezeigt, umfasst der SM 1140 einen Anweisungs-Cache-Speicher !205, eine oder mehrere Planereinheiten 1210, eine Registerdatei 1220, einen oder mehrere Verarbeitungskerne 1250, eine oder mehrere Spezialfunktionseinheiten (SFUs) 1252, eine oder mehrere Lade/Speicher-Einheiten (LSUs) 1254, ein Zwischenverbindungs-Netzwerk 1280 und einen gemeinsam benutzten Ll-Cache-Speicher 1270.
  • Wie oben beschrieben, versendet die Arbeitsverteilungs-Einheit 1025 Aufgaben zur Ausführung auf den GPCs 1050 der PPU 1000. Die Aufgaben werden einem bestimmten DPC 1120 innerhalb eines GPC 1050 zugeteilt, und wenn die Aufgabe einem Shader-Programm zugeordnet ist, kann die Aufgabe einem SM 1140 zugeteilt werden. Die Planereinheit 1210 empfängt die Aufgaben von der Arbeitsverteilungs-Einheit 1025 und verwaltet die Anweisungs-Planung (instruction scheduling) für einen oder mehrere Thread-Blöcke, die dem SM 1140 zugewiesen sind. Die Planereinheit 1210 plant Thread-Blöcke zur Ausführung als Warps von parallelen Threads, wobei jeder Thread-Block mindestens einem Warp zugeordnet ist. In einer Ausführungsform führt jeder Warp 102 Threads aus. Die Planereinheit 1210 kann eine Mehrzahl von unterschiedlichen Thread-Blöcken verwalten, welche die Warps den unterschiedlichen Thread-Blöcken zuordnet und dann Anweisungen von der Mehrzahl von unterschiedlichen kooperativen Gruppen an die verschiedenen Funktionseinheiten (z. B. Kerne 1250, SFUs 1252 und LSUs 1254) während jedes Taktzyklus versendet.
  • Cooperative Groups ist ein Programmiermodell zum Organisieren von Gruppen von kommunizierenden Threads, das Entwicklern ermöglicht, die Granularität auszudrücken, bei der Threads kommunizieren, wobei der Ausdruck von reicheren, effizienten Parallelzerlegungen ermöglicht wird. Cooperative-Start-APIs unterstützen die Synchronisierung unter Thread-Blöcken für die Ausführung von parallelen Algorithmen. Herkömmliche Programmiermodelle stellen einen einzigen, einfachen Aufbau zum Synchronisieren von kooperierenden Threads bereit: eine Barriere über alle Threads eines Threadblocks (z. B. die Funktion syncthreads( )). Programmierer würden jedoch häufig gerne Gruppen von Threads bei kleineren als Thread-Block-Granularitäten definieren und innerhalb der definierten Gruppen synchronisieren, um größere Leistung, Gestaltungsflexibilität und Software-Wiederverwendung in der Form von kollektiven gruppenweiten Funktionsschnittstellen zu ermöglichen.
  • Cooperative Groups ermöglicht Programmierern, Gruppen von Threads explizit bei Sub-Block(z. B. so klein wie ein einziger Thread)- und Mehr-Block-Granularitäten zu definieren und kollektive Operationen, wie beispielsweise Synchronisierung, an den Threads in einer kooperativen Gruppe durchzuführen. Das Programmiermodell unterstützt eine saubere Zusammensetzung über Softwaregrenzen, so dass Bibliotheken und Hilfsfunktionen innerhalb ihres lokalen Kontexts sicher synchronisieren können, ohne Annahmen über Konvergenz machen zu müssen. Cooperative-Groups-Primitiven ermöglichen neue Muster von kooperativer Parallelität, die Erzeuger-Verbraucher Parallelität, opportunistische Parallelität und globale Synchronisierung über ein gesamtes Gitter von Threadblöcken umfassen.
  • Eine Versandeinheit 1148 ist konfiguriert, um Anweisungen an eine oder mehrere der Funktionseinheiten zu übertragen. In der Ausführungsform umfasst die Planereinheit 1210 zwei Versandeinheiten 1148, die ermöglichen, dass zwei unterschiedliche Anweisungen von dem gleichen Warp während jedes Taktzyklus versandt werden. In alternativen Ausführungsformen kann jede Planereinheit 1210 eine einzige Versandeinheit 1148 oder zusätzliche Versandeinheiten 1148 umfassen.
  • Jeder SM 1140 umfasst eine Registerdatei 1220, die einen Satz von Registern für die Funktionseinheiten des SM 1140 bereitstellt. In einer Ausführungsform ist die Registerdatei 1220 zwischen jeder der Funktionseinheiten aufgeteilt, so dass jeder Funktionseinheit ein zugehöriger Abschnitt der Registerdatei 1220 zugeteilt ist. In einer anderen Ausführungsform ist die Registerdatei 1220 zwischen den unterschiedlichen Warps aufgeteilt, die von dem SM 1140 ausgeführt werden. Die Registerdatei 1220 stellt temporäre Speicherung für Operanden bereit, die mit den Datenpfaden der Funktionseinheiten verbunden sind.
  • Jeder SM 1140 umfasst L Verarbeitungskerne 1250. In einer Ausführungsform umfasst der SM 1140 eine große Anzahl (z. B. 128, usw.) von unterschiedlichen Verarbeitungskernen 1250. Jeder Kern 1250 kann eine vollständig in einer Pipeline angeordnete (fully-pipelined) Einfach-Präzisions- Verarbeitungseinheit umfassen, die eine Gleitkommaarithmetik-Logikeinheit und eine Ganzzahlarithmetik-Logikeinheit umfasst. In einer Ausführungsform implementieren die Gleitkommaarithmetik-Logikeinheiten den IEEE 754-3008 Standard für Gleitkommaarithmetik. In einer Ausführungsform umfassen die Kerne 1250 64 Einfach-Präzisions-(32-Bit)-Gleitkommakerne, 64 Integer-Kerne, 102 Doppel-Präzisions-(64-Bit)-Gleitkommakerne und 8 Tensorkerne.
  • Tensorkerne sind konfiguriert, um Matrix-Operationen durchzuführen und in einer Ausführungsform sind ein oder mehrere Tensorkerne in den Kernen 1250 umfasst. Insbesondere sind die Tensorkerne konfiguriert, um Deep-Learning-Matrix-Arithmetik, wie beispielsweise Faltungsoperationen für Neuronal-Netzwerktraining und Inferenzieren, durchzuführen. In einer Ausführungsform arbeitet jeder Tensorkern an einer 4x4 Matrix und führt eine Matrix-Multiplikations- und Akkumulations-Operation D=A×B+C durch, wobei A, B, C und D 4x4 Matrizen sind.
  • In einer Ausführungsform sind die Matrix-Multiplikations-Eingaben A und B 16-Bit-Gleitkomma-Matrizen, während die Akkumulationsmatrizen C und D 16-Bit-Gleitkomma- oder 102-Bit-Gleitkomma-Matrizen sein können. Tensorkerne arbeiten an 16-Bit-Gleitkomma-Eingabedaten mit 102-Bit-Gleitkomma-Akkumulation. Die 16-Bit-Gleitkomma-Multiplikation erfordert 64 Operationen und ergibt ein Produkt voller Präzision, das dann unter Verwendung einer 32-Bit-Gleitkomma-Addition mit den anderen Zwischenprodukten für eine 4x4x4-Matrix-Multiplikation akkumuliert wird. In der Praxis werden Tensorkerne verwendet, um viel größere zweidimensionale oder höherdimensionale Matrixoperationen durchzuführen, die von diesen kleineren Elementen aufgebaut werden. Eine API, wie beispielsweise die CUDA 9 C++ API, stellt spezialisierte Matrix-Lade-, Matrix-Multiplikations- und Matrix-Akkumulations- und Matrix-SpeicherOperationen bereit, um Tensorkerne von einem CUDA-C++ Programm effizient zu verwenden. Auf der CUDA-Ebene nimmt das Warp-Schnittstellenniveau 16x16 große Matrizen an, die alle 102 Threads des Warp überspannen.
  • In einigen Ausführungsformen ist Transpositionshardware in den Verarbeitungskerne 1250 oder einer anderen Funktionseinheit (e.g., SFUs 1252 oder LSUs 1254) umfasst und ist konfiguriert, um Matrixdaten, die von Diagonale gespeichert werden, und/oder die ursprüngliche Matrix und/oder transponierte Matrix aus den von Diagonalen gespeicherten Matrixdaten zu erzeugen. Die Transpositionshardware kann innerhalb des Ladepfades von dem gemeinsam genutzten Speicher 1270 zu der Registerdatei 1220 des SM 1140 bereitgestellt werden.
  • In einem Beispiel können die von Diagonalen gespeicherten Matrixdaten aus dem DRAM geholt und in dem gemeinsam genutzten Speicher 1270 gespeichert werden. Wenn die Anweisung, eine Verarbeitung unter Verwendung der von Diagonalen gespeicherten Matrixdaten durchzuführen, verarbeitet wird, kann die in dem Pfad des gemeinsam genutzten Speichers 1270 und der Registerdatei 1220 angeordnete Transpositionshardware die ursprüngliche Matrix, die transponierte Matrix, die kompaktierte ursprüngliche Matrix, und/oder die kompaktierte transponierte Matrix bereitstellen. Bis zu der allerletzten Speicherung vor der Anweisung können die von Diagonalen gespeicherten Einzelmatrixdaten beibehalten werden, und der durch die Anweisung zugewiesene Matrixtyp wird nach Bedarf in der Registerdatei 1220 erzeugt.
  • Jeder SM 1140 umfasst ebenfalls mehrere SFUs 1252, die Sonderfunktionen durchführen (z. B. Attributauswertung, reziproke Quadratwurzel und dergleichen). In einer Ausführungsform können die SFUs 1252 eine Baumtraversierungseinheit (z. B. TTU 1143) umfassen, die konfiguriert ist, um eine hierarchische Baumdatenstruktur zu durchlaufen. In einer Ausführungsform können die SFUs 1252 eine Textureinheit (z. B. Textureinheit 1142) umfassen, die konfiguriert ist, um Texturkarten-Filteroperationen durchzuführen. In einer Ausführungsform sind die Textureinheiten konfiguriert, um Texturkarten (z. B. eine 2D-Anordnung von Texeln) von dem Speicher 1004 zu laden und die Texturkarten abzutasten, um abgetastete Texturwerte zum Gebrauch in Shader-Programmen zu erzeugen, die von dem SM 1140 ausgeführt werden.
  • In einer Ausführungsform werden die Texturkarten in dem gemeinsam benutzten Speicher/L1-Cache-Speicher 1170 gespeichert. Die Textureinheiten implementieren Texturoperationen, wie beispielsweise Filteroperationen, unter Verwendung von Mip-Maps (z. B. Texturkarten von veränderlichem Detaillierungsgrad). In einer Ausführungsform umfasst jeder SM 1040 zwei Textureinheiten.
  • Jeder SM 1140 umfasst ebenfalls mehrere LSUs 1254, die Lade- und Speicheroperationen zwischen dem gemeinsam benutzten Speicher/L1-Cache-Speicher 1270 und der Registerdatei 1220 implementieren. Jeder SM 1140 umfasst ein Zwischenverbindungs-Netzwerk 1280, das jede der Funktionseinheiten mit der Registerdatei 1220 und die LSU 1254 mit der Registerdatei 1220, gemeinsam benutzten Speicher/ Ll-Cache-Speicher 1270 verbindet. In einer Ausführungsform ist das Zwischenverbindungs-Netzwerk 1280 eine Kreuzschiene, die konfiguriert sein kann, um irgendeine der Funktionseinheiten mit irgendeinem der Register in der Registerdatei 1220 und Speicherorten im gemeinsam benutzten Speicher/L1-Cache-Speicher 1270 zu verbinden.
  • Der gemeinsam benutzte Speicher/L1-Cache-Speicher 1270 ist ein Array einer Auf-Chip-Speicheranordnung, die Datenspeicherung und Kommunikation zwischen dem SM 1140 und der Primitiven-Engine 1135 und zwischen Threads in dem SM 1140 ermöglicht. In einer Ausführungsform umfasst der gemeinsam benutzte Speicher/L1-Cache-Speicher 1270 128KB von Speicherkapazität und ist in dem Pfad von dem SM 1140 zu der Speicherpartitionseinheit 1080. Der gemeinsam benutzte Speicher/L1-Cache-Speicher 1270 kann verwendet werden, um Lese- und Schreibvorgänge zwischenzuspeichern. Einer oder mehrere der gemeinsam benutzten Speicher/L1-Cache-Speicher 1270, L2-Cache-Speicher 1160 und Speicher 1004 sind Hintergrundspeicher.
  • Das Kombinieren eines Daten-Cache und gemeinsam benutzter Speicherfunktionalität in einem einzigen Speicherblock stellt die beste Gesamtleistung für beide Arten von Speicherzugriffen bereit. Die Kapazität ist als ein Cache von Programmen benutzbar, die den gemeinsam benutzten Speicher nicht verwenden. Wenn der gemeinsam benutzte Speicher beispielsweise konfiguriert ist, die Hälfte der Kapazität zu verwenden, können Textur- und Lade/Speicher-Operationen die verbleibende Kapazität verwenden. Integration innerhalb des gemeinsam benutzten Speichers/L1-Cache-Speicher 1270 ermöglicht dem gemeinsam benutzten Speicher/L1-Cache-Speicher 1270 als eine Leitung mit hohem Durchsatz zum Streamen von Daten zu fungieren, während gleichzeitig eine höhere Bandbreite und ein latenzarmer Zugriff auf häufig wiederverwendete Daten bereitgestellt werden.
  • Im Kontext dieser Offenbarung bedeutet ein SM oder „Streaming-Multiprozessor“ einen Prozessor, der architektiert ist, wie in USP7,447,873 an Nordquist beschrieben, einschließlich Verbesserungen daran und Fortschritte davon, und wie beispielsweise in vielen Generationen von NVIDIA GPUs implementiert ist. Beispielsweise kann ein SM mehrere Verarbeitungs-Engines oder -kerne umfassen, die konfiguriert sind, um gleichlaufend mehreren Threads auszuführen, die in mehreren SIMD (Single-Instruction, Multiple-Data)-Gruppen (e.g., Warps) angeordnet sind, wobei jeder der Threads in einer gleichen der SIMD Gruppen ein gleiches Datenverarbeitungsprogramm ausführt, das eine Sequenz von Anweisungen auf einem unterschiedlichen Eingabeobjekt und unterschiedliche Threads in der gleichen der SIMD-Gruppe werden unter Verwendung unterschiedlicher der Verarbeitungs-Engines oder -kerne ausgeführt. Ein SM kann typischerweise ebenfalls (a) eine lokale Registerdatei mit mehreren Bahnen bereitstellen, wobei jede Verarbeitungs-Engine oder -kern konfiguriert ist, um auf eine unterschiedliche Untermenge der Bahnen zuzugreifen; und Anweisungsausgabelogik, die konfiguriert ist, um eine der SIMD Gruppen auszuwählen und um eine der Anweisungen des gleichen Datenverarbeitungsprogramm an jede der mehreren Verarbeitungs-Engines parallel auszugeben, wobei jede Verarbeitungs-Engine die gleiche Anweisung parallel mit jeder anderen Verarbeitungs-Engine unter Verwendung der Untermenge der lokalen Registerdateibahnen zugänglich dazu ausführt. Ein SM umfasst typischerweise ferner Kernschnittstellenlogik, die konfiguriert ist, um die Ausführung einer oder mehreren SIMD-Gruppen zu initiieren. Wie in den Figuren gezeigt, wurden derartige SMs aufgebaut, um einen schnellen lokalen gemeinsam genutzten Speicher bereitzustellen, der gemeinsame Datennutzung/Wiederverwendung und Synchronisierung zwischen allen Threads eines auf dem SM ausgeführten CTA bereitzustellen.
  • Wenn für Allzweck-Parallelberechnung konfiguriert, kann im Vergleich mit der Graphikverarbeitung eine einfachere Konfiguration verwendet werden. Im Einzelnen werden die in 11A gezeigten Festfunktions-Graphikverarbeitungseinheiten umgangen, wobei ein viel einfacheres Programmiermodell erzeugt wird. In der Allzweck-Parallelberechnungs-Konfiguration werden Blöcke von Threads von der Arbeitsverteilungs-Einheit 1025 direkt den DPCs 1120 zugewiesen und verteilt. Die Threads in einem Block führen das gleiche Programm unter Verwendung einer eindeutigen Thread-ID in der Berechnung, um sicherzustellen, dass jeder Thread eindeutige Ergebnisse erzeugt, unter Verwendung des SM 1140, um das Programm auszuführen und Berechnungen durchzuführen, eines gemeinsam benutzten Speicher/L1-Cache-Speichers 1270, um zwischen Threads zu kommunizieren, und der LSU 1254 aus, um globalen Speicher durch den gemeinsam benutzten Speicher/L1-Cache-Speicher 1270 und die Speicherpartitionseinheit 1080 zu lesen und zu beschreiben. Wenn für Allzweck-Parallelberechnung konfiguriert, kann der SM 1140 ebenfalls Befehle schreiben, welche die Planereinheit 1020 verwenden kann, um neue Arbeit auf den DPCs 1120 zu starten.
  • Die PPU 1000 kann in einem Tischcomputer, einem Laptop-Computer, einem Tablet-Computer, einem Smartphone (z. B. einer drahtlosen handgehaltenen Vorrichtung), einem persönlichen digitalen Assistenten (PDA), einer Digitalkamera, einer handgehaltenen elektronischen Vorrichtung und dergleichen umfasst sein. In einer Ausführungsform ist die PPU 1000 auf einem einzelnen Halbleitersubstrat verkörpert. In einer anderen Ausführungsform ist die PPU 1000 in einem System-auf-Chip (SoC) zusammen mit einer oder mehreren anderen Vorrichtungen, wie beispielsweise zusätzlichen PPUs 1000, dem Speicher 1004, einem Rechner-mitreduziertem-Befehlssatz (RISC)-CPU, einer Speicherverwaltungseinheit (MMU), einem Digital/Analog-Wandler (DAC) und dergleichen umfasst.
  • In einer Ausführungsform kann die PPU 1000 auf einer Graphikkarte umfasst sein, die eine oder mehrere Speichervorrichtungen 1004 umfasst. Die Graphikkarte kann konfiguriert sein, um sich mit einem PCIe-Slot auf einer Hauptplatine eines Desktop-Computers schnittstellenmäßig zu verbinden. In noch einer anderen Ausführungsform kann die PPU 1000 eine integrierte Graphikverarbeitungseinheit (iGPU) oder ein Parallelprozessor sein, der in dem Chipsatz der Hauptplatine umfasst ist.
  • Beispielhaftes Rechensystem
  • Systeme mit mehrere GPUs und CPUs werden in einer Vielfalt von Industrien verwendet, sowie Entwickler mehr Parallelität in Anwendungen, wie beispielsweise Rechnen für künstliches Intelligenz, offenlegen und wirksam einsetzen. Hochleistungs-GPU-beschleunigte Systeme mit zehn bis vielen Tausenden von Rechenknoten werden in Datenzentren, Forschungsanlagen und Supercomputern eingesetzt, um immer größere Probleme zu lösen. Sowie die Anzahl von Verarbeitungsvorrichtungen innerhalb der Hochleistungssysteme zunimmt, müssen die Kommunikations- und Datentransfermechanismen angepasst werden, um die erhöhte Bandbreite zu unterstützen.
  • 13B ist ein Konzeptdiagramm eines Verarbeitungssystems 1000, das unter Verwendung der PPU 1000 von 10 implementiert wird, gemäß einer Ausführungsform. Das beispielhafte System 1000 kann konfiguriert sein, um die in dieser Ausführungsform offenbarten Verfahren zu implementieren (z. B. die TMAU in 1, 2, 6 oder 11A). Das Verarbeitungssystem 1000 umfasst eine CPU 1330, einen Schalter 1010 und jeweils mehrere PPUs 1000 und jeweilige Speicher 1004. Das NVLink 1010 stellt Hochgeschwindigkeits-Kommunikationsverbindungen zwischen jeder der PPUs 1000 bereit. Obwohl eine bestimmte Anzahl von NV-Link 1050 und Zwischenverbindung 1002 Verbindungen in 13B veranschaulicht sind, kann die Anzahl an jeder PPU 1000 und der CPU 1330 variieren. Der Schalter 1355 ist schnittstellenmäßig zwischen der Zwischenverbindung 1002 und der CPU 1330 verbunden. Die PPUs 1000, die Speicher 1004 und die NVLinks 1010 können auf einer einzigen Halbleiterplattform situiert sein, um ein Parallelverarbeitungsmodul 1325 zu bilden. In einer Ausführungsform unterstützt der Schalter 1355 zwei oder mehrere Protokolle, um sich schnittstellenmäßig zwischen verschiedenen Verbindungen und/oder Links zu verbinden.
  • In einer anderen Ausführungsform (nicht gezeigt) stellt das NVLink 1010 ein oder mehrere Hochgeschwindigkeits-Kommunikationslinks zwischen jeder der PPUs 1000 und der CPU 1330 bereit und der Schalter 1355 ist schnittstellenmäßig zwischen der Zwischenverbindung 1002 und jeder der PPUs 1000 verbunden. Die PPUs 1000, die Speicher 1004 und die Zwischenverbindung können auf einer einzigen Halbleiterplattform situiert sein, um ein Parallelverarbeitungsmodul 1325 zu bilden. In noch einer anderen Ausführungsform (nicht gezeigt) stellt die Zwischenverbindung eine oder mehrere Kommunikationslinks zwischen jeder der PPUs 1000 und der CPU 1330 bereit und der Schalter 1355 ist schnittstellenmäßig zwischen jeder der PPUs 1000 unter Verwendung des NVLink 1010 verbunden, um ein oder mehrere Hochgeschwindigkeits-Kommunikationslinks zwischen den PPUs 1000 bereitzustellen. In einer anderen Ausführungsform (nicht gezeigt) stellt die Zwischenverbindung 1002 ein oder mehrere Hochgeschwindigkeits-Kommunikationslinks zwischen den PPUs 1000 und der CPU 1330 durch den Schalter 1010 bereit. In noch einer anderen Ausführungsform (nicht gezeigt) stellt die Zwischenverbindung 1302 eine oder mehrere Hochgeschwindigkeits-Kommunikationslinks zwischen jeder der PPUs 1000 direkt bereit. Ein oder mehrere der NVLink 1010 Hochgeschwindigkeits-Kommunikationslinks können als eine physikalische NVLink-Zwischenverbindung oder entweder als eine Auf-Chip- oder Auf-Die-Zwischenverbindung unter Verwendung des gleichen Protokolls wie das NVLink 1010 implementiert werden.
  • Im Kontext der vorliegenden Beschreibung kann sich eine einzige Halbleiterplattform auf eine einzelne unitäre Halbleiterbasierte integrierte Schaltung beziehen, die auf einem Die oder Chip angefertigt ist. Es sei bemerkt, dass sich der Begriff einzige Halbleiterplattform ebenfalls auf Mehr-Chip-Module mit erhöhter Konnektivität beziehen kann, die eine Auf-Chip-Operation simulieren und die wesentliche Verbesserungen gegenüber der Benutzung einer herkömmlichen Busimplementierung vornehmen. Natürlich können die verschiedenen Schaltungen oder Vorrichtungen ebenfalls getrennt oder in verschiedenen Kombinationen von Halbleiterplattformen gemäß den Wünschen des Benutzers gelegen sein. Alternativ kann das Parallelverarbeitungsmodul 1325 als ein Leiterplattensubstrat implementiert sein und jede der PPUs 1000 und/oder Speicher 1004 können verpackte Vorrichtungen sein. In einer Ausführungsform sind die CPU 1330, der Schalter 1355 und das Parallelverarbeitungsmodul 1325 auf einer einzigen Halbleiterplattform gelegen.
  • In einer Ausführungsform ist die Signalrate von jedem NVLink 1010 20 bis 25 Gigabit/s und jede PPU 1000 umfasst sechs NVLink 1010 Schnittstellen (wie in 13B gezeigt, sind fünf NVLink 1010 Schnittstellen für jede PPU 1000 umfasst). Jedes NVLink 1010 stellt eine Datentransferrate von 25 Gigabyte/s in jeder Richtung bereit, wobei sechs Links 1000 Gigabyte/s bereitstellen. Die NVLinks 1010 können exklusiv für PPU-zu-PPU Kommunikation, wie in 13A gezeigt, oder einer Kombination von PPU-zu-PPU und PPU-zu-CPU verwendet werden, wenn die CPU 1330 ebenfalls eines oder mehrere NVLink 1010 Schnittstellen umfasst.
  • In einer Ausführungsform ermöglicht das NVLink 1010 einen direkten Lade-/Speicher-/atomaren Zugriff von der CPU 1330 auf jeden Speicher 1004 der PPU 1000. In einer Ausführungsform unterstützt das NVLink 1010 Kohärenzoperationen, die ermöglichen, das von dem Speicher 1004 gelesene Daten in der Cache-Hierarchie der CPU 1330 gespeichert werden können, was die Cachezugriffslatenz für die CPU 1330 verringert. In einer Ausführungsform umfasst das NVLink 1010 Unterstützung für Address Translation Services (ATS), was der PPU 1000 ermöglicht, auf Seitentabellen innerhalb der CPU 1330 direkt zuzugreifen. Eines oder mehrere der NVLinks 1010 können ebenfalls konfiguriert sein, um in einem Niedrigleistungsmodus zu arbeiten.
  • 13B veranschaulicht ein beispielhaftes System 1365, bei dem die verschiedene Architektur und/oder Funktionalität der verschiedenen vorherigen Ausführungsformen implementiert werden kann. Das beispielhafte System 1365 kann konfiguriert sein, um die in dieser Anmeldung offenbarten Verfahren zu implementieren (z. B. die TMAU in 1, 2 6 oder 11A)
  • Wie gezeigt, wird ein System 1365 bereitgestellt, das mindestens eine zentrale Verarbeitungseinheit 1330 umfasst, die mit einem Kommunikationsbus 1375 verbunden ist. Der Kommunikationsbus 1375 kann unter Verwendung jedes geeigneten Protokolls, wie beispielsweise PCI (Peripheral Component Interconnect), PCI-Express, AGP (Accelerated Graphics Port), Hyper-Transport oder irgendeinem(irgendwelchen) anderen Bus- oder Punkt-zu-Punkt-Kommunikationsprotokoll(en) implementiert sein. Das System 1365 umfasst ebenfalls einen Hauptspeicher 1340. Steuerlogik (Software) und Daten werden in dem Hauptspeicher 1340 gespeichert, der die Form eines Direkt-Zugriffs-Speichers (RAM) annehmen kann.
  • Das System 1365 umfasst ebenfalls Eingabevorrichtungen 1360, das Parallelverarbeitungssystem 1325 und Anzeigevorrichtungen 1345, z.B. eine herkömmliche CRT (Kathodenstrahlröhre), eine LCD (Flüssigkristallanzeige), eine LED (lichtemittierende Diode), eine Plasmaanzeige oder dergleichen. Eine Benutzereingabe kann von den Eingabevorrichtungen 1360, z.B. Tastatur, Maus, Berührfeld, Mikrophon und dergleichen, empfangen werden. Jedes der vorhergehenden Module und/oder Vorrichtungen kann sogar auf einer einzigen Halbleiterplattform gelegen sein, um das System 1365 zu bilden. Alternativ können die verschiedenen Module ebenfalls getrennt oder in verschiedenen Kombinationen von Halbleiterplattformen gemäß den Wünschen des Benutzers gelegen sein.
  • Ferner kann das System 1365 mit einem Netzwerk (z.B. einem Telekommunikationsnetzwerk, Lokalbereichsnetzwerk (LAN), drahtlosen Netzwerk, Weitbereichsnetzwerk (WAN), wie beispielsweise dem Internet, Peer-zu-Peer-Netzwerk, Kabelnetzwerk oder dergleichen) durch eine Netzwerkschnittstelle 1335 für Kommunikationszwecke gekoppelt sein.
  • Das System 1365 kann ebenfalls eine Sekundärspeicherung umfassen (nicht gezeigt). Die Sekundärspeicherung 610 umfasst beispielsweise ein Festplattenlaufwerk und/oder ein entfernbares Speicherlaufwerk, das ein Diskettenlaufwerk darstellt, ein Magnetbandlaufwerk, ein Kompaktdisklaufwerk, ein digitale versatile Disk-(DVD)-Laufwerk, eine Aufzeichnungsvorrichtung und einen Universal-Serial-Bus-(USB)-Flash-Speicher. Das entfernbare Speicherlaufwerk liest von und/oder schreibt auf eine entfernbare Speichereinheit auf eine wohlbekannte Art und Weise.
  • Computerprogramme oder Computersteuerlogik-Algorithmen können in dem Hauptspeicher 1340 und/oder der Sekundärspeicherung gespeichert sein. Derartige Computerprogramme, wenn ausgeführt, ermöglichen dem System 1365, verschiedene Funktionen durchzuführen. Der Speicher 1340, die Speicherung, und/oder jede andere Speicherung sind mögliche Beispiele von computerlesbaren Medien.
  • Die Architektur und/oder Funktionalität der verschiedener vorherigen Figuren kann im Kontext eines allgemeinen Computersystems, eines Platinensystems, eines Unterhaltungszwecken fest zugeordneten Spielkonsolensystems, eines anwendungsspezifischen Systems und/oder jedem anderen gewünschten System implementiert sein. Beispielsweise kann das System 1365 die Form eines Tischcomputers, eines Laptop-Computers, eines Tablet-Computers, von Servern, von Supercomputern, eines Smartphones (z.B. einer drahtlosen handgehaltenen Vorrichtung), eines persönlichen digitalen Assistenten (PDA), einer Digitalkamera, eines Fahrzeugs, einer am Kopf angebrachten Anzeige, einer handgehaltenen elektronischen Vorrichtung, eines mobilen Telefongeräts, eines Fernsehers, einer Arbeitsstation, von Spielkonsolen, eines eingebetteten Systems und/oder von jedem anderen Typ von Logik annehmen.
  • Ein Anwendungsprogramm kann über eine Anwendung implementiert sein, die von einem Hostprozessor, wie beispielsweise einer CPU, ausgeführt wird. In einer Ausführungsform kann ein Gerätetreiber eine Anwendungsprogrammierschnittstelle (API) implementieren, die verschiedene Funktionen definiert, die von einer Anwendung benutzt werden können, um graphische Daten für die Anzeige zu erzeugen. Der Gerätetreiber ist ein Softwareprogramm, das eine Vielzahl von Anweisungen umfasst, die den Betrieb der PPU 1000 steuern. Die API bietet eine Abstraktion für einen Programmierer, die einen Programmierer spezielle Graphikhardware, wie beispielsweise die PPU 1000, verwenden lässt, um die Graphikdaten zu erzeugen, ohne dass der Programmierer den spezifischen Anweisungssatz für die PPU 1000 verwenden muss. Die Anwendung kann einen API-Aufruf umfassen, der an den Gerätetreiber für die PPU 1000 weitergeleitet wird. Der Gerätetreiber interpretiert den API-Aufruf und führt verschiedene Vorgänge durch, um auf den API-Aufruf zu reagieren. In einigen Fällen kann der Gerätetreiber Operationen dadurch ausführen, dass er Anweisungen auf der CPU ausführt. In anderen Fällen kann der Gerätetreiber zumindest teilweise Vorgänge dadurch durchführen, dass er unter Verwendung einer Ein-/Ausgabeschnittstelle zwischen der CPU und der PPU 1000 Vorgänge auf der PPU 1000 startet. In einer Ausführungsform ist der Gerätetreiber dazu eingerichtet, die Graphikverarbeitungspipeline 1400 unter Verwendung der Hardware der PPU 1000 zu implementieren.
  • Verschiedene Programme können innerhalb der PPU 1000 ausgeführt werden, um die verschiedenen Stufen der Graphikverarbeitungspipeline 1800 zu realisieren. Beispielsweise 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 anfänglich durch die PPU 1000 ausgeführte Kernel) kann ebenfalls andere Kernel auf der PPU 1000 starten, um andere Stufen der Verarbeitung durchzuführen. Wenn die Anwendungsprogrammverarbeitung eine Graphikverarbeitungs-Pipeline umfasst, dann können einige der Stufen der Graphikverarbeitungs-Pipeline auf fester Hardware implementiert werden, wie z. B. ein Rasterisierer oder ein Datenassembler, der in der PPU 1000 implementiert ist. Es sei anerkannt, dass Ergebnisse von einem Kernel durch eine oder mehrere dazwischenliegende Hardwareeinheiten mit fester Funktion verarbeitet werden können, bevor sie von einem nachfolgenden Kernel auf einem SM 700 verarbeitet werden.
  • Alle hier zitierten Patente, Patentanmeldungen und Veröffentlichungen sind durch Bezugnahme für alle Zwecke aufgenommen, als ob sie ausdrücklich dargelegt werden.
  • Während die Erfindung im Zusammenhang mit dem beschrieben wurde, was gegenwärtig als die praktischste und bevorzugste Ausführungsform angesehen wird, versteht sich, dass die Erfindung nicht auf die offenbarte Ausführungsform zu beschränken ist, sondern sie ist im Gegenteil bestimmt, verschiedene Modifikationen und äquivalente Anordnungen innerhalb des Wesens und des Umfangs der beigefügten Ansprüche abzudecken.
  • 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 17691621 [0033, 0101]
    • US 17691690 [0045, 0064]
    • US 8112614 [0049]
    • US 7506134 [0049]
    • US 7836118 [0049]
    • US 7788468 [0049]
    • US 10909033 [0049]
    • US 20140122809 [0049]
    • US 17691276 [0053, 0054]
    • US 17691422 [0053]
    • US 16712083 [0053]
    • US 17/691296 [0070]
  • Zitierte Nicht-Patentliteratur
    • USP7,447,873 [0131]

Claims (21)

  1. Verarbeitungssystem, umfassend: mehrere Prozessoren; einen verteilten gemeinsam genutzten Speicher, der mehrere verteilte gemeinsam genutzte Speicherbereiche umfasst, wobei jeder der mehreren verteilten gemeinsam genutzten Speicherbereiche lokal mit einem jeweiligen Prozessor der mehreren Prozessoren verbunden ist, wobei die mehreren Prozessoren konfiguriert sind, um gleichzeitig mehrere Threads auszuführen, wobei einer der Threads, der ausführenden auf einem ersten der mehreren Prozessoren ausgeführt wird, eine Speicherzugriffsanfrage für Daten für einen oder mehrere andere Threads der Threads erzeugt, die auf einem oder mehreren zweiten der mehreren Prozessoren ausgeführt werden; und Paketverteilungsschaltungen, die konfiguriert sind, um zu den jeweiligen der mehreren Prozessoren zur Speicherung in ihren jeweiligen verteilten gemeinsam genutzten Speicherbereichen jeweilige Abschnitte von Antwortdaten zu leiten, die als Antwort auf die Speicherzugriffsanfrage empfangenen werden.
  2. Verarbeitungssystem gemäß Anspruch 1, ferner umfassend Speicherschnittstellenschaltungen, wobei die Speicherschnittstellenschaltungen konfiguriert sind, um die Speicherzugriffsanfrage an eine Speicherhierarchie zu übertragen, die einen Cache-Speicher umfasst.
  3. Verarbeitungssystem gemäß Anspruch 1 oder 2, wobei die Paketverteilungsschaltungen Verfolgungsschaltungen umfassen und ferner konfiguriert sind, um als Antwort auf das Empfangen der Speicherzugriffsanfrage Metadaten der Speicherzugriffsanfrage in den Verfolgungsschaltungen zu speichern und eine modifizierte Speicherzugriffsanfrage für die angefragten Daten zu erzeugen, und als Antwort auf das Empfangen der Antwortdaten ein Multicast-Antwortpaket zu bilden, das die Metadaten umfasst, und das Multicast-Antwortpaket an mindestens den einen oder mehrere zweite der mehreren Prozessoren zu übertragen.
  4. Verarbeitungssystem gemäß Anspruch 3, wobei die gespeicherten Metadaten identifizierende Informationen des einen oder mehrerer anderer Threads umfassen und die modifizierte Speicherzugriffsanfrage ist frei von den identifizierenden Informationen des einen oder mehreren anderen Threads ist.
  5. Verarbeitungssystem gemäß Anspruch 3 oder 4, wobei die Paketverteilungsschaltungen ferner Paketerzeugungsschaltungen umfassen, die als Antwort auf das Empfangen des Multicast-Antwortpakets ein erstes Antwortpaket und ein zweites Antwortpaket erzeugen, die jeweils an einen jeweiligen der mehreren Prozessoren geleitet werden.
  6. Verarbeitungssystem gemäß Anspruch 5, wobei die Paketverteilungsschaltungen konfiguriert sind, um das Multicast-Antwortpaket in einen Abschnitt der Paketverteilungsschaltungen zu transportieren, bevor das erste Antwortpaket und das zweite Antwortpaket erzeugt wird.
  7. Verarbeitungssystem gemäß einem vorangehenden Anspruch, wobei die mehreren Threads mehrere kooperative Thread-Arrays (CTAs) umfassen, die als ein kooperatives Gruppen-Array (CGA) gestartet werden, wobei ein jeweiliges der CTAs auf jedem Prozessor der mehreren Prozessoren gestartet wird.
  8. Verarbeitungssystem gemäß einem vorangehenden Anspruch, wobei die Speicherzugriffsanfrage Anfragerinformationen, Empfängerinformationen für jeden von mehreren Empfängern und angefragte Dateninformationen umfasst.
  9. Verarbeitungssystem gemäß Anspruch 8, wobei die Empfängerinformationen ferner für jedes empfangende kooperativen Thread-Array (CTA) einen Empfängeridentifikator und einen Offset in dem entsprechenden gemeinsam genutzten Speicherbereich umfasst.
  10. Verarbeitungssystem gemäß Anspruch 9, wobei der Offset für jedes der empfangenden CTAs identisch ist.
  11. Verarbeitungssystem gemäß Anspruch 9, wobei alle Empfängeridentifikatoren in einer Liste spezifiziert sind.
  12. Verarbeitungssystem gemäß Anspruch 9, wobei alle Empfängeridentifikatoren in einer Bitmaske spezifiziert sind.
  13. Verarbeitungssystem gemäß einem der Ansprüche 8 bis 12, wobei die Speicherzugriffsanfrage ferner einen Synchronisationsbarrieren-Offset in dem verteilten gemeinsam genutzten Speicher umfasst.
  14. Verarbeitungssystem gemäß einem der Ansprüche 8 bis 13, wobei die Speicherzugriffsanfrage ferner eine oder mehrere Operationen umfasst, die von einem Empfänger vor oder während des Schreibens der Antwortdaten zu dem verteilten gemeinsam genutzten Speicherbereich des Empfängers durchzuführen sind.
  15. Verarbeitungssystem gemäß einem vorangehenden Anspruch, wobei mindestens einer der jeweiligen Prozessoren konfiguriert ist, um als Antwort auf das Empfangen der Multicast-Daten, eine Bestätigung an einen anderen der Prozessoren zu übertragen.
  16. Verarbeitungssystem gemäß einem vorangehenden Anspruch, umfassend einen ersten Satz von Zählern und einen zweiten Satz von Zählern für jeden der mehreren Prozessoren, wobei der erste Satz von Zählern bei dem ersten Prozessor einen jeweiligen Zähler umfasst, der Multicast-Daten darstellt, die von jedem von mehreren anderen der Prozessoren empfangen werden, und der zweite Satz von Zählern bei dem ersten Prozessor einen Zähler umfasst, der Multicast-Daten darstellt, die von dem ersten Prozessor im Namen von anderen der mehreren Prozessoren angefragt werden.
  17. Verarbeitungssystem gemäß einem vorangehenden Anspruch, wobei die Paketverteilungsschaltungen mehrere Kreuzschienenschalter umfassen, wobei jeder Kreuzschienenschalter einen Cache-Abschnitt mit den mehreren Prozessoren verbindet.
  18. Verarbeitungssystem gemäß einem vorangehenden Anspruch, wobei die Paketverteilungsschaltungen konfiguriert sind, um einen Kreuzschienenschalter zum Transportieren eines Pakets, das die angefragten Daten umfasst, basierend auf einem Zielidentifikator des Pakets auszuwählen.
  19. Verarbeitungssystem gemäß einem vorangehenden Anspruch, wobei die Paketverteilungsschaltungen konfiguriert sind, um jeweilige Abschnitte der Antwortdaten in den verteilten gemeinsam genutzten Speicher von mindestens dem einen oder mehreren zweiten der mehreren Prozessoren zu schreiben.
  20. Verarbeitungssystem gemäß einem vorangehenden Anspruch, wobei das Verarbeitungssystem eine Graphikverarbeitungseinheit (GPU) umfasst.
  21. System, umfassend mindestens eine Zentralverarbeitungseinheit (CPU) und mindestens ein Verarbeitungssystem gemäß einem vorangehenden Anspruch.
DE102023105568.2A 2022-03-10 2023-03-07 Programmatisch gesteuertes daten-multicasting über mehrere rechen-engines Pending DE102023105568A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US17/691,288 US20230289190A1 (en) 2022-03-10 2022-03-10 Programmatically controlled data multicasting across multiple compute engines
US17/691,288 2022-03-10

Publications (1)

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

Family

ID=87760123

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102023105568.2A Pending DE102023105568A1 (de) 2022-03-10 2023-03-07 Programmatisch gesteuertes daten-multicasting über mehrere rechen-engines

Country Status (3)

Country Link
US (1) US20230289190A1 (de)
CN (1) CN116777725A (de)
DE (1) DE102023105568A1 (de)

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7447873B1 (en) 2005-11-29 2008-11-04 Nvidia Corporation Multithreaded SIMD parallel processor with loading of groups of threads
US7506134B1 (en) 2006-06-16 2009-03-17 Nvidia Corporation Hardware resource based mapping of cooperative thread arrays (CTA) to result matrix tiles for efficient matrix multiplication in computing system comprising plurality of multiprocessors
US7788468B1 (en) 2005-12-15 2010-08-31 Nvidia Corporation Synchronization of threads in a cooperative thread array
US7836118B1 (en) 2006-06-16 2010-11-16 Nvidia Corporation Hardware/software-based mapping of CTAs to matrix tiles for efficient matrix multiplication
US8112614B2 (en) 2005-12-15 2012-02-07 Nvidia Corporation Parallel data processing systems and methods using cooperative thread arrays with unique thread identifiers as an input to compute an identifier of a location in a shared memory
US20140122809A1 (en) 2012-10-30 2014-05-01 Nvidia Corporation Control mechanism for fine-tuned cache to backing-store synchronization
US10909033B1 (en) 2019-08-15 2021-02-02 Nvidia Corporation Techniques for efficiently partitioning memory

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7043524B2 (en) * 2000-11-06 2006-05-09 Omnishift Technologies, Inc. Network caching system for streamed applications
US8831995B2 (en) * 2000-11-06 2014-09-09 Numecent Holdings, Inc. Optimized server for streamed applications
US7062567B2 (en) * 2000-11-06 2006-06-13 Endeavors Technology, Inc. Intelligent network streaming and execution system for conventionally coded applications
US8910171B2 (en) * 2009-04-27 2014-12-09 Lsi Corporation Thread synchronization in a multi-thread network communications processor architecture
US9471373B2 (en) * 2011-09-24 2016-10-18 Elwha Llc Entitlement vector for library usage in managing resource allocation and scheduling based on usage and priority
US9465657B2 (en) * 2011-07-19 2016-10-11 Elwha Llc Entitlement vector for library usage in managing resource allocation and scheduling based on usage and priority
US10375167B2 (en) * 2015-11-20 2019-08-06 Microsoft Technology Licensing, Llc Low latency RDMA-based distributed storage
US11409621B2 (en) * 2018-05-29 2022-08-09 Vmware, Inc. High availability for a shared-memory-based firewall service virtual machine
CN111885602B (zh) * 2020-07-27 2021-04-27 西南交通大学 一种面向异构网络的批量切换认证及密钥协商方法
US11645207B2 (en) * 2020-09-25 2023-05-09 Advanced Micro Devices, Inc. Prefetch disable of memory requests targeting data lacking locality
US20230216947A1 (en) * 2021-12-31 2023-07-06 Avila Technology, LLC Method and System to Implement Secure Real Time Communications (SRTC) Between WebRTC and the Internet of Things (IoT)
US20230236878A1 (en) * 2022-01-25 2023-07-27 Nvidia Corporation Efficiently launching tasks on a processor

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7447873B1 (en) 2005-11-29 2008-11-04 Nvidia Corporation Multithreaded SIMD parallel processor with loading of groups of threads
US7788468B1 (en) 2005-12-15 2010-08-31 Nvidia Corporation Synchronization of threads in a cooperative thread array
US8112614B2 (en) 2005-12-15 2012-02-07 Nvidia Corporation Parallel data processing systems and methods using cooperative thread arrays with unique thread identifiers as an input to compute an identifier of a location in a shared memory
US7506134B1 (en) 2006-06-16 2009-03-17 Nvidia Corporation Hardware resource based mapping of cooperative thread arrays (CTA) to result matrix tiles for efficient matrix multiplication in computing system comprising plurality of multiprocessors
US7836118B1 (en) 2006-06-16 2010-11-16 Nvidia Corporation Hardware/software-based mapping of CTAs to matrix tiles for efficient matrix multiplication
US20140122809A1 (en) 2012-10-30 2014-05-01 Nvidia Corporation Control mechanism for fine-tuned cache to backing-store synchronization
US10909033B1 (en) 2019-08-15 2021-02-02 Nvidia Corporation Techniques for efficiently partitioning memory

Also Published As

Publication number Publication date
US20230289190A1 (en) 2023-09-14
CN116777725A (zh) 2023-09-19

Similar Documents

Publication Publication Date Title
DE102019103340A1 (de) Simultanes rechen- und grafik-scheduling
DE102020127705A1 (de) Techniken für einen effizienten fabric-attached-speicher
DE102020124932A1 (de) Vorrichtung und Verfahren zur Echtzeit-Grafikverarbeitung mittels lokaler und cloudbasierter Grafikverarbeitungsbetriebsmittel
DE102019133028A1 (de) Für neuronale netzwerke geeignetes effizientes matrixformat
DE102020104637A1 (de) Techniken zur effizienten partitionierung von speicher
DE102019103310A1 (de) Schätzer for einen optimalen betriebspunkt für hardware, die unter einer beschränkung der gemeinsam genutzten leistung/wärme arbeitet
DE102019102009A1 (de) Reduzierung des rauschens während des renderings durch parallele path-space-filterung unter verwendung von hashing
DE102021120605A1 (de) Effiziente softmax-berechnung
DE102019135639A1 (de) Auf Echtzeit-Strahlverfolgung (RTRT) basierende adaptive Mehrfrequenzschattierung (AMFS)
DE102021102589A1 (de) Berechnungsgraph-optimierung
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
DE102020118860A1 (de) Techniken zum vorladen von texturen beim rendering von graphik
DE102020132377A1 (de) Vorrichtung und Verfahren zur Drosselung einer Raytracing-Pipeline
DE112020000865T5 (de) Speicherverwaltungssystem
DE102019134020A1 (de) Dekompprimierungstechniken zur verarbeitung komprimierter daten, die für künstliche neuronale netzwerke geeignet sind
DE102020121601A1 (de) Persistenter Notizblockspeicher zum Datenaustausch zwischen Programmen
DE102019101871A1 (de) Verfahren und Vorrichtung zum Gewinnen von Abtastpositionen von Textuieroperationen
DE102020127704A1 (de) Techniken zum effizienten transferieren von daten an einem prozessor
DE102021111335A1 (de) Techniken zum dynamischen komprimieren von speicherregionen, die einen einheitlichen wert haben
DE102020104651A1 (de) Arbeitsspeicherkomprimierungs-Hashmechanismus
DE112019001978T5 (de) Verbesserung des realismus von szenen mit wasseroberflächen beim rendern
DE102021102746A1 (de) Lese/schreib-seitenreplikation für mehrere recheneinheiten
DE102021113178A1 (de) Techniken für zugriff auf komprimierte daten und ihre statusinformationen sowie nutzung der daten und statusinformationen
DE102021114013A1 (de) Techniken zum effizienten abtasten eines bildes

Legal Events

Date Code Title Description
R012 Request for examination validly filed