DE102013202173A1 - Einheitliche Lade-Verarbeitung für Teilsätze von parallelen Threads - Google Patents

Einheitliche Lade-Verarbeitung für Teilsätze von parallelen Threads Download PDF

Info

Publication number
DE102013202173A1
DE102013202173A1 DE102013202173A DE102013202173A DE102013202173A1 DE 102013202173 A1 DE102013202173 A1 DE 102013202173A1 DE 102013202173 A DE102013202173 A DE 102013202173A DE 102013202173 A DE102013202173 A DE 102013202173A DE 102013202173 A1 DE102013202173 A1 DE 102013202173A1
Authority
DE
Germany
Prior art keywords
threads
thread
memory
subset
parallel
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
DE102013202173A
Other languages
English (en)
Inventor
Michael Fetterman
Stewart Glenn Carlton
Douglas J. Hahn
Rajeshwaran Selvanesan
Shirish Gadre
Steven James HEINRICH
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 DE102013202173A1 publication Critical patent/DE102013202173A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/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/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline, look ahead
    • G06F9/3824—Operand accessing
    • G06F9/383—Operand prefetching
    • 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/3836—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution
    • G06F9/3851—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution from multiple instruction streams, e.g. multistreaming

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Multimedia (AREA)
  • Advance Control (AREA)
  • Multi Processors (AREA)

Abstract

Ein Ausführungsbeispiel der vorliegenden Erfindung beschreibt eine Technik zur Verarbeitung von Lade-Instruktionen für parallele Threads einer Thread-Gruppe, wenn ein Teilsatz der parallelen Threads die gleiche Speicheradressen aufruft. Die Lade-/Speicher-Einheit stellt fest, ob die Speicheradressen für jeden Teilsatz der parallelen Threads mit einem oder mehreren einheitlichen Mustern übereinstimmt. Wenn eine Übereinstimmung für mindestens eins der einheitlichen Muster erreicht wird, überträgt die Lade-/Speicher-Einheit einen Lesebefehl, um Daten für den parallelen Threads aufzurufen. Die Anzahl der übertragenen Leseaufrufe wird im Vergleich zur Ausführung von separaten Leseaufrufen für jeden Thread des Teilsatzes reduziert. Eine Mehrzahl der einheitlichen Muster kann basierend auf einem gemeinsamen Zugriffsmuster, welches in den Programm-Instruktionen vorkommt, definiert werden. Eine Mehrzahl der einheitlichen Mustern kann auch basierend auf Interconnect-Engpässen zwischen der Lade-/Speicher-Einheit und dem Speicher definiert, wenn ein kompletter Crossbar-Interconnect nicht verfügbar ist.

Description

  • Hintergrund der Erfindung
  • Gebiet der Erfindung
  • Die vorliegende Erfindung bezieht sich im Allgemeinen auf Parallelverarbeitung und insbesondere auf eine Parallelarchitektur für einen Zugriff auf einheitliche Daten mit reduzierter Bandbreite.
  • Beschreibung des Standes der Technik
  • Bei einer Single-Instruction Multiple-Thread (SIMT) Verarbeitungsumgebung werden Threads in Gruppen von P parallelen Threads Gruppen – genannt Warps – organisiert, welche dasselbe Programm ausführen. Obwohl die P Threads einer Thread-Gruppe jede Instruktionen des Programms parallel ausführen, führt jeder Thread der Thread-Gruppe die Instruktionen unabhängig unter Nutzung seiner eigenen Daten und Register aus. Jeder Thread der Thread-Gruppe führt seine Programm-Instruktionen sequenziell nacheinander aus. Ein gemeinsames paralleles Programmmuster bezieht eine Sequenz von Instruktionen ein, inklusive zweier separater Lade-Instruktionen zum Laden von zwei Einheiten von Daten und eine arithmetisch Instruktion zur Verarbeitung der zwei Einheiten der Daten. Folglich setzt die Gruppe der P Threads beim Verarbeiten der Instruktionssequenz 2P Speicherlesezugriffe ab, wenn die Lade-Instruktionen verarbeitet werden.
  • Viele parallele Algorithmen – inklusive Tiled Matrix Multiplikation, Image Convolution Filter und Bild-Motion-Estimation – können so organisiert werden, dass für jede Lade-Instruktion in der Instruktionssequenz die entsprechende Speicheradresse für jeden Thread in der Thread-Gruppe die gleiche ist. Wenn die Lade-Instruktion verarbeitet wird, gibt jeder Threads in der Threads-Gruppe einen separaten Speicherleseaufruf aus, um entsprechende Einheiten von Daten aus dem Speicher aufzurufen. Weil allerdings die Speicheradresse, welche durch jeden Thread an die Lade-Instruktion über die Threads-Gruppe bereitgestellt wird, die gleiche innerhalb der Threadgruppe ist, bedingt jeder separate Speicher-Lese-Zugriff bei der Verarbeitung ein Auslesen der gleichen Einheiten von Daten aus dem Speicher. In so einem Fall wird Speicherauslesebandbreite für Daten P Mal unnötig verschwendet und zwar für jeden Threads in der Gruppe von P Threads.
  • Dementsprechend besteht ein Bedarf für ein Verfahren für eine effektive Verarbeitung von mehreren Leseaufrufen von jedem Thread in einer Gruppe von parallelen Threads zum Aufruf der gleichen Daten aus einem Speicher.
  • Zusammenfassung der Erfindung
  • Ein System und ein Verfahren zur Verarbeitung einer Lade-Instruktion für parallele Threads einer Thread-Gruppe, wenn ein Teilsatz der parallelen Threads die gleiche Speicheradresse aufruft, kann die Anzahl der Leseaufrufe und Daten, die zur Verarbeitung der Lade-Instruktionen verarbeitet werden, reduzieren. Die Lade-/Speicher-Einheit stellt fest, ob Speicheradressen für jeden Teilsatz der parallelen Threads basierend auf einem oder mehreren einheitlichen Mustern übereinstimmen. Wenn eine Übereinstimmung für mindestens einen der einheitlichen Muster erreicht wird, überträgt die Lade-/Speicher-Einheit einen Leseaufruf, um Daten für den Teilsatz der parallelen Threads aufzurufen. Die Anzahl der Lese-Anforderungen wird im Vergleich zur Ausführung von separaten Leseaufrufen für jeden Thread der Teilgruppe reduziert. Eine Mehrzahl von einheitlichen Mustern kann basierend auf allgemeinen Zugriffsmustern, welche in Programmbefehlen vorkommen, definiert werden. Eine Mehrzahl von einheitlichen Mustern kann auch basierend auf Interconnect-Engpässen zwischen der Lade-/Speicher-Einheit und dem Speicher, falls kein vollständiger Crossbar-Interconnect verfügbar ist, definiert werden.
  • Verschiedene Ausführungsformen eines Verfahrens der Erfindung, welche Lade-Instruktionen zugeordnet sind, umfassen ein Empfangen einer ersten Lade-Instruktion für eine Parallelausführung durch jeden Thread der Thread-Gruppe, bei denen die erste Lade-Instruktion eine erste individuelle Speicheradresse für jeden entsprechenden Thread in der Thread-Gruppe festlegt. Die individuellen Speicheradressen werden, inklusive der ersten Speicheradressen, welche mit einem Teil der Threads, welche in dem Teilsatz der parallelen Threads enthalten sind, basierend auf einem einheitlichen Muster verglichen, um ein Vergleichsergebnis zu erzeugen. Wenn Vergleichsergebnis darauf hinweist, dass die individuelle Speicheradressen der Teilegruppe der parallelen Threads mit dem einheitlichen Muster übereinstimmen, wird ein Leseaufruf an den Speicher übertragen, um Daten, die in der ersten Speicheradresse gespeichert sind, aufzurufen.
  • Verschiedene Ausführungsformen der Erfindung umfassen ein Verarbeitungssubsystem zum Aufrufen von gespeicherten Daten, die einer Lade-Instruktion zugeordnet sind. Das Verarbeitungssubsystem weist eine einheitliche Ladeeinheit auf, welche konfiguriert ist, eine erste Lade-Instruktion für eine Parallelverarbeitung durch jeden Thread in einer Thread-Gruppe zu empfangen, wobei die erste Lade-Instruktionen eine individuelle Speicheradresse für jeden entsprechenden Thread in der Thread-Gruppe festlegt. Die einheitliche Ladeeinheit identifiziert einen Teilsatz von parallelen Threads, welche nur einen Teil der Threads in der Thread-Gruppe enthält. Die einheitliche Ladeeinheit vergleicht die individuelle Speicheradressen, die dem Teil der Threads zugeordnet ist – inklusive der ersten Speicheradressen – basierend auf einem einheitlichen Muster, um ein Vergleichsergebnis zu erzeugen. Wenn die einheitliche Ladeeinheit feststellt, dass das Vergleichsergebnis darauf hinweist, dass die individuellen Speicheradressen, welche dem Teilsatz der parallelen Threads zugeordnet ist, mit dem einheitlichen Muster übereinstimmen, überträgt eine Lade-/Speicher-Einheit, welche zwischen der einheitlichen Ladeeinheit und einem Speicher gekoppelt ist, eine Leseanforderung an den Speicher, um Daten, die an der ersten Speicheradresse gespeichert sind, aufzurufen.
  • Ein Vorteil des offenbarten Verfahrens ist, dass eine Mehrzahl von Threads, welche ein Auslesen der gleichen Adresse anfordern, nur einen einzigen Leseaufruf ausführen. Weil darüber hinaus ein einheitliches Muster durch die Lade-/Speicher-Einheit basierend auf einem oder mehreren Mustern festgestellt wurde, hat der Compiler die Flexibilität darauf hinzuweisen, dass eine Lade-Instruktionen einheitlich sein kann, auch dann, wenn der Compiler nicht garantieren kann, dass jeder Thread in der Thread-Gruppe auf die gleiche Adresse während der Ausführung zu greifen wird.
  • Kurze Beschreibung der Figuren
  • Damit die Art und Weise, in welcher die oben genannten Merkmale der vorliegenden Erfindung besser im Detail verstanden werden können, wird eine detailliertere Beschreibung der Erfindung, die im Groben kurz zusammengefasst ist, mit Bezug auf die Ausführungsbeispiele angegeben, von denen einige durch die beiliegenden Zeichnungen illustriert sind. Es sei darauf hingewiesen, dass die beiliegenden Zeichnungen nur typische Ausführungsbeispiele dieser Erfindung darstellen und deshalb nicht als den Umfang beschränkt zu betrachten sind und daher andere gleichwertige Ausführungsbeispiele zulassen.
  • 1 ist ein Blockdiagramm, welches ein Computersystem darstellt, welches konfiguriert ist, um einen oder mehrere Aspekte der vorliegenden Erfindung zu implementieren;
  • 2 ist ein Blockdiagramm eines Parallelverarbeitungssubsystems für das Computersystem gemäß 1 entsprechend einem Ausführungsbeispiel der vorliegenden Erfindung;
  • 3A ist ein Blockdiagramm für ein Frontend von 2 entsprechend einem Ausführungsbeispiel der vorliegenden Erfindung;
  • 3B ist ein Blockdiagramm für ein allgemeines Verarbeitungs-Cluster innerhalb einer der Parallelverarbeitungseinheiten von 2 entsprechend einem Ausführungsbeispiel der vorliegenden Erfindung;
  • 3C ist ein Blockdiagramm des Streaming Multiprozessors gemäß 3B, entsprechend einem Ausführungsbeispiel der vorliegenden Erfindung; und
  • 4A ist ein Blockdiagramm des Lade-/Speicher-Einheiten-(LSU)-Array von 3C entsprechend einem Ausführungsbeispiel der vorliegenden Erfindung;
  • 4B ist ein konzeptionelles Diagramm, welches einen Teilsatz der parallelen Threads und eines ersten einheitlichen Musters darstellt, welches genutzt wird, um ein Vergleichsergebnis zu erzeugen, entsprechend einem Ausführungsbeispiel der vorliegenden Erfindung;
  • 4C ist ein weiteres konzeptionelles Diagramm, welches einen Teilsatz der parallelen Threads und ein zweites einheitliches Muster darstellt, um ein Vergleichsergebnis zu erzeugen, entsprechend einem Ausführungsbeispiel der vorliegenden Erfindung;
  • 4D ist ein weiteres konzeptionelles Diagramm, welches einen Teilsatz der parallelen Threads und ein drittes einheitliches Muster darstellt, welches genutzt wird, um einen Vergleichsergebnis zu erzeugen, entsprechend einem Ausführungsbeispiel der vorliegenden Erfindung;
  • 5 stellt ein Flussdiagramm von Verfahrensschritten zum Verarbeiten einer Lade-Instruktion entsprechend einem Ausführungsbeispiel der vorliegenden Erfindung dar.
  • Detaillierte Beschreibung
  • In der folgenden Beschreibung werden eine Vielzahl von besonderen Details dargestellt, um ein besseres Verständnis der vorliegenden Erfindung zu ermöglichen. Allerdings ist auch klar, dass es einem Fachmann möglich ist, die vorliegende Erfindung ohne eines mehrere dieser besonderen Details auszuführen.
  • System-Übersicht
  • 1 ist ein Blockdiagramm, welches einen Computer-System 100 darstellt, welches konfiguriert ist, um einen oder mehrere Aspekte der vorliegenden Erfindung zu implementieren. Das Computer-System 100 weist eine zentrale Verarbeitungseinheit (CPU) 102 und einen Systemspeicher 104 auf, welche über einen Verbindungspfad, welcher eine Speicherbrücke 105 aufweist, miteinander kommunizieren. Die Speicherbrücke 105, welche beispielsweise aus einem Northbridge-Chip bestehen kann, ist über einen Bus oder einen anderen Kommunikationspfad 106 (z. B. einen HyperTransport-Link) mit einer I/O-Brücke 107 verbunden. Die I/O-Brücke 107, welche beispielsweise einen Southbridge-Chip sein kann, empfängt Eingaben eines Benutzers über ein oder mehrere Eingabegeräte 108 (z. B. Tastatur, Maus) und gibt diese Eingaben über den Kommunikationspfad 106 und die Speicherbrücke 105 an die CPU 102 weiter. Ein Parallelverarbeitungssubsystem 112 ist an die Speicherbrücke 105 über einen Bus oder einen zweiten Kommunikationspfad 113 (z. B. einen Peripheral Component Interconnect (PCI), Accelerated Graphics Port, oder HyperTransport-Link) gekoppelt; in einem Ausführungsbeispiel ist das Parallelverarbeitungssubsystem ein Graphik-Subsystem, welches Pixel an eine Anzeigevorrichtung 110 liefert (z. B. ein auf einer konventionellen Bildröhre oder einem Flüssigkeitsbildschirm basierenden Monitor). Eine System-Festplatte 114 ist zusätzlich an die I/O 107 angeschlossen. Ein Switch 116 stellt Verbindungen zwischen der I/O-Brücke 107 und anderen Komponenten wie einem Netzwerk-Adapter 118 und in mehreren Erweiterungskarten 120 und 121 her. Andere Komponenten (nicht explizit dargestellt), inklusive Universal Serial Bus (USB) und anderen Port-Verbindungen, Compact Disk-(CD)-Laufwerken den Digital-Video-Disk-(DVD)-Laufwerken, Filmaufnahmegeräten und anderen, können zusätzlich an die I/O-Brücke 107 angeschlossen sein. Die Vielzahl der Kommunikationspfade, inklusive der explizit genannten Kommunikationspfaden 106 und 113, die in 1 dargestellt sind, können verschiedene, einem Fachmann bekannten Protokolle nutzen. Diese können – wie beispielsweise PCI-Express AGP (Advanded Graphics Port), HyperTransport oder andere Bus- oder Punkt-zu-Punkt-Kommunikationsprotokolle und Verbindungen zwischen verschiedenen Geräten – über geeignete Protokolle implementiert sein.
  • In einem Ausführungsbeispiel schließt das Parallelverarbeitungssubsystem 112 Schaltkreise ein, die für eine Grafik- und Video-Verarbeitung, wie beispielsweise Video-Ausgabe-Schaltkreise, optimiert sind und eine Grafik-Verarbeitungseinheit (GPU) aufweisen. In einem anderen Ausführungsbeispiel schließt das Parallelverarbeitungssubsystem 112 einen Schaltkreis ein, der für eine allgemeine Verarbeitung optimiert ist, und der die darunter liegende Berechnungsarchitektur, welche hier ausführlich detailliert beschrieben ist, einschließt. In einem weiteren Ausführungsbeispiel kann das Parallelverarbeitungssubsystemen mit einem oder mehreren anderen Systemelementen in einem einzigen Subsystem integriert sein, um somit die Speicherbrücke 105, die CDU 102 und die I/O-Brücke 107 einzuschließen, um ein System auf einem Chip (System on a Chip, SoC) zu bilden.
  • Es sei darauf hingewiesen, dass das abgebildete System einen illustrativen Charakter hat und dass Variationen und Modifikationen möglich sind. Die Verbindungstopologie inklusive der Anzahl und Anordnung von Brücken, die Anzahl der CPUs 102 und die Anzahl der Parallelverarbeitungssubsysteme 112 können je nach Bedarf modifiziert werden. In einigen Ausführungsbeispielen ist beispielsweise ein der Systemspeicher 104 direkt und nicht über eine Brücke an die CPU 102 verbunden und andere Vorrichtungen kommunizieren mit dem Systemspeicher 104 über die Speicherbrücke 105 und die CPU 102. In anderen alternativen Topologien ist das Parallelverarbeitungssubsystem 112 mit der I/O-Brücke 107 oder direkt mit der CPU 102 und nicht über die Speicherbrücke 105 verbunden. In wieder anderen Ausführungsbeispielen kann die I/O-Brücke 107 und die Speicherbrücke 105 in einem einzigen Chip integriert sein anstelle einer oder mehrerer existierenden diskreten Vorrichtungen. Große Ausführungsbeispiele können zwei oder mehrere CPUs 102 und zwei oder mehrere Parallelverarbeitungssubsysteme 112 aufweisen. Die hier insbesondere dargestellten Komponenten sind optional; beispielsweise kann jede Anzahl von Erweiterungskarten oder Peripheriegeräten unterstützt werden. In einigen Ausführungsbeispielen fällt der Switch 116 weg und der Netzwerkadapter 118 und die Erweiterungskarten 120, 121 sind direkt an die I/O-Brücke 107 angeschlossen.
  • 2 stellt ein Parallelverarbeitungssubsystem 112 entsprechend einem Ausführungsbeispiel der vorliegenden Erfindung dar. Wie dargestellt weist das Parallelverarbeitungssubsystem 112 eine oder mehrere Parallelerarbeitungssubeinheiten (PPUs) 202 auf, von denen jede mit einem lokalen Parallelverarbeitungs-(PP)Speicher (PP = parallel processing) 204 verbunden ist. Generell gilt, dass ein Parallelverarbeitungssubsystem eine Anzahl U von PPUs (parallel processing units) aufweist, wobei U ≥ 1 ist. (Im folgenden werden multiple Instanzen von vergleichbaren Objekten mit Bezugszeichen bezeichnet, die das Objekt identifizieren und in Klammern gesetzte Ziffern identifizieren – wo erforderlich – die Instanz). PPUs 202 und die Parallelverarbeitungsspeicher 204 können als eine oder mehrere integrierte Schaltkreisvorrichtungen wie programmierbarer Prozessoren, Applikationsspezifische Integrierte Schaltkreise (ASICs) oder Speichervorrichtungen, oder in jeder anderen technisch möglichen Weise implementiert sein.
  • Jetzt wird wieder Bezug auf 1 und 2 genommen. In einigen Ausführungsbeispielen sind alle in der PPU 202 in dem Parallelverarbeitungssubsystem 112 Graphikprozessoren mit Rendering-Pipelines, die konfiguriert werden können, um verschiedene Befehle auszuführen, um Pixeldaten aus Grafikdaten zu erzeugen, die von der CPU 102 und/oder dem Systemspeicher 104 über die Speicherbrücke 105 und den zweiten Kommunikationspfad 113, welcher mit dem lokalen Parallelverarbeitungsspeicher 204 (welche als Grafikspeicher inklusive beispielsweise einem konventionellen Frame-Buffer genutzt werden können) kommuniziert, bereitgestellt werden, um Pixeldaten zu speichern und zu aktualisieren, wodurch Pixeldaten an die Anzeigevorrichtung 110 oder andere geliefert werden. In einigen Ausführungsbeispielen kann das Parallelverarbeitungssubsystem 112 eine oder mehrere PPUs 202, die als Grafik-Prozessoren arbeiten, sowie eine oder mehrere andere PPUs 202 aufweisen, die für allgemeine Berechnungen genutzt werden. Die PPUs können identisch oder unterschiedlich sein und jede PPU kann eine/mehrere dedizierte Parallelverarbeitungsspeichervorrichtung(en) oder keine Parallelverarbeitungsspeichervorrichtung(en) aufweisen. Eine oder mehrere PPUs 202 in dem Parallelverarbeitungssubsystem 112 kann Daten an die Anzeigevorrichtung 110 ausgeben oder jede PPU 202 in dem Parallelverarbeitungssubsystem 112 kann Daten an eine oder mehrere Anzeigevorrichtungen 110 ausgeben.
  • Im Betrieb ist die CPU 102 der Hauptprozessor des Computersystems 100, in welchem der Betrieb der anderen Systemkomponenten kontrolliert und koordiniert wird. Insbesondere setzt CPU 102 Befehle ab, welche den Betrieb der PPUs 202 steuern. In einigen Ausführungsbeispielen schreibt die CPU 102 einen Befehlsstrom für jede PPU 202 in eine Datenstruktur (welche weder in 1 noch 2 explizit dargestellt ist), welche sich in dem Systemspeicher 104, dem Parallelverarbeitungsspeicher 204 oder in anderen Speicherbereichen befindet, die sowohl von der CPU 102 als auch von der PPU 202 zugreifbar sind. Für jede Datenstruktur wird ein Pointer in einen Push-Buffer geschrieben, um eine Verarbeitung des Befehlsstroms aus der Datenstruktur zu initiieren. Die PPU 202 Liest den Befehlsstrom von einem oder mehreren Pushbuffern und führt dann die Kommandos asynchron relativ zum Betrieb der CPU 102 aus. Für jeden Push-Buffer können Verarbeitungsprioritäten durch ein Anwendungsprogramm über Device-Treiber spezifiziert werden, um eine zeitliche Reihenfolge der unterschiedlichen Push-Buffer zu steuern.
  • Es wird nun wieder Bezug auf 2 wie auch auf 1 genommen: Jede PPU 202 weist eine I/O-(Input/Output = Eingabe/Ausgabe)-Einheit 205 auf, welche mit dem Rest des Computersystems 100 über den Kommunikationspfad 113 kommuniziert, welcher mit der Speicherbrücke 105 (oder in einem anderen Ausführungsbeispiel direkt mit der CPU 102) verbunden ist. Die Verbindung der PPU 202 mit dem Rest des Computersystems 100 kann auch andersartige sein. In einigen Ausführungsbeispielen kann das Parallelverarbeitungssubsystem 112 als eine Ergänzungskarte implementiert sein, die in ein Ergänzungsslot des Computersystems 100 eingeführt werden kann. In anderen Ausführungsbeispielen kann einen PPU 202 in einen einzigen Chip mit einer Busbrücke 105 wie die Speicherbrücke 107 integriert sein. In wiederum anderen Ausführungsbeispielen können alle Elemente der PPU 202 auf einem einzigen Chip mit der CPU 102 integriert sein.
  • In einem Ausführungsbeispiel ist der Kommunikationspartner 113 ein PCI-Express-Link, bei dem dedizierte Verbindungen für jede PPU 202 reserviert sind, wie es dem Fachmann bekannt ist. Es können auch andere Kommunikationspfade genutzt werden. Eine I/O-Einheit erzeugt Pakete (oder andere Signale) zur Übertragung über den Kommunikationspfad 113 und empfängt auch eingehende Pakete (oder andere Signale) über den Kommunikationspfad 113, wobei die eingehenden Pakete entsprechenden Komponenten der PPU 202 zugeordnet werden. Beispielsweise können Befehle die sich auf Verarbeitungsaufgaben beziehen einem Host-Interface 206 zugeführt werden, während Befehle die sich auf Speicheroperationen (z. B. Lesen von oder Schreiben in den Parallelverarbeitungsspeicher 204) beziehen, einer Speicher-Crossbar-Einheit 210 zugeordnet werden. Das Host-Interface 206 liest jeden Push-Buffer und gibt die Befehlsstruktur, die in dem Push-Buffer gespeichert ist, an einen Frontend 212 aus.
  • Jede PPU 202 implementiert vorteilhafterweise eine hoch parallelisierte Verarbeitungsarchitektur. Wie detailliert dargestellt weist PPU 202 (0) ein Verarbeitungs-Cluster-Array 230 auf, welches eine Anzahl C von allgemeinen Verarbeitungs-Clustern (GPCs) 208 aufweist, wobei C ≥ 1 ist. Jede GPC 208 ist in der Lage, eine große Anzahl (z. B. Hunderte oder Tausende) von Threads gleichzeitig zu verarbeiten, wobei jeder Thread eine Instanz eines Programmes ist. In verschiedenen Anwendungen können unterschiedliche GPCs 208 unterschiedlichen Arten von Programmen zugewiesen sein oder können unterschiedliche Arten von Berechnungen durchführen. Die Zuweisung der GPCs 208 kann abhängig von der Arbeitslast, welche sich aus jeder Art von Programmen oder Berechnung ergibt, variieren.
  • GPCs 208 empfangen auszuführende Berechnungsaufgaben von einer Arbeitsverteilungseinheit innerhalb einer Aufgaben-/Arbeitseinheit 207. Die Arbeitsverteilungseinheit empfängt Pointer auf Berechnungsaufgaben die als Aufgaben-Meta-Daten (TMD = task metadata) verschlüsselt und im Speicher gespeichert sind. Der Pointer auf die TMDs sind in dem Befehlsstrom enthalten, der in dem Push-Buffer gespeichert ist und von der Frontend-Einheit 202 von dem Host-Interface 206 empfangen wird. Berechnungsaufgaben, die als TMDs verschlüsselt sind, enthalten neben Indizes von Daten, die zu verarbeiten sind, auch Statusparameter und Kommandos, welche definieren, wie die Daten zu verarbeiten sind (z. B. welches Programm ausgeführt werden soll). Die Aufgaben-/Arbeitseinheit 297 empfängt Aufgaben von dem Frontend 212 und stellt sicher, dass die GPCs 208 in einen gültigen Status konfiguriert werden, bevor die durch jede der TMDs spezifizierte Verarbeitung initiiert wird. Für jede TMD kann eine Priorität spezifiziert werden, welche dafür genutzt wird, die Ausführung der Verarbeitungsaufgabe zeitlich zu steuern. Verarbeitungsaufgaben können auch von dem Verarbeitungs-Cluster-Array 230 empfangen werden. Optional können die TMD auch einen Parameter enthalten, welcher steuert, ob die TMD an den Beginn oder das ändern einer Liste (oder einer Liste von Pointern auf die Verarbeitungsaufgaben) von Verarbeitungsaufgaben hinzugefügt werden, wodurch ein weiterer Steuerungslevel über Prioritäten verfügbar gemacht wird.
  • Das Speicher-Interface 214 enthält eine Anzahl D von Partition-Einheiten 215, welche jeweils an einem Teil des Parallelverarbeitungsspeichers 214 gekoppelt sind, wobei D ≥ 1 ist. Wie dargestellt, ist die Anzahl der Partition-Einheiten 215 generell gleich der Anzahl von dynamischem Random Access Memory (DRAM) 220. In anderen Ausführungsbeispielen kann die Anzahl der Partition-Einheiten 215 gleich der Anzahl von Speichervorrichtungen sein. Einem Fachmann wird bekannt sein, dass DRAM 220 durch andere geeignete Speichervorrichtungen ersetzt werden und ein allgemeines konventionelles Design aufweisen kann. Auf eine weitere Beschreibung wird deshalb verzichtet. Rendering-Ziele wie Frame-Buffer oder Texturabbildungen können an unterschiedlichen Stellen des DRAM 220 gespeichert sein, womit es den Partition-Einheiten 215 ermöglichst wird, Teile von jedem Rendering-Ziel parallel zu schreiben, um die verfügbare Bandbreite des Parallelverarbeitungsspeichers 204 effektiv zu nutzen.
  • Jede der GPC 208 kann Daten, die in ein beliebiges der DRAMs 220 innerhalb des Parallelverarbeitungsspeichers 204 zu schreiben sind, verarbeiten. Die Crossbar-Einheit 210 ist so konfiguriert, Ausgabedaten jeder GPC 208 an den Eingang jeder Partition-Einheit 215 oder einer anderen GPC 208 zur Weiterverarbeitung zu leiten. Die GPCs 208 kommunizieren mit dem Speicher-Interface 214 durch die Crossbar-Einheit 210, um von einem der unterschiedlichen externen Speichervorrichtungen zu lesen oder zu schreiben. In einem Ausführungsbeispiel weist die Crossbar-Einheit 210 eine Verbindung zu dem Speicher-Interface 214 auf, um mit deren I/O-Einheit 205 zu kommunizieren. Des Weiteren besteht eine Verbindung zum lokalen Parallelverarbeitungsspeicher 214, wodurch es ermöglicht wird, dass es den Verarbeitungskerne innerhalb der unterschiedlichen GPCs 208 mit dem Systemspeicher 104 oder anderen Speichern, die nicht lokal relativ zur PPU 202 sind, ermöglicht wird, zu kommunizieren. In dem Ausführungsbeispiel, welches in 2 dargestellt ist, ist die Crossbar-Einheit 210 direkt mit der I/O-Einheit 205 verbunden. Die Crossbar-Einheit 210 kann virtuelle Kanäle aufweisen, um Datenströme zwischen den GPCs 208 und den Partitions-Einheiten 215 zu separieren.
  • Die GPCs 208 können programmiert sein, um Verarbeitungsaufgaben bezüglich einer großen Vielzahl von Anwendungen auszuführen. Dies schließt folgendes ein ist aber nicht darauf begrenzt: linear und nichtlineare Datentransformation, Filterung von Video- und-/oder Audiodaten, Modellierungsaufgaben (z. B. Anwendung von physikalischen Gesetzen um die Position, die Geschwindigkeit und andere Attribute eines Objektes zu bestimmen), Bildbearbeitungsberechnungen (z. B. Tesselation-Shader, Vertex-Shader, Geometry-Shader, und/oder Pixelschattierungsprogramme), usw. Die PPUs 202 können Daten vom Systemspeicher 102 und/oder den lokalen, Prallelverarbeitungsspeichern 204 in einen internen (on-chip) Speicher übertragen, die Daten bearbeiten und Ergebnisdaten zurück in den System-Speicher 104 und/oder den lokalen Parallelverarbeitungsspeichern 204 schreiben, von wo aus andere Systemkomponenten auf die Daten zugreifen können. Dazu gehören die CPU 102 oder andere Parallelverarbeitungssubsysteme 112.
  • Eine PPU 202 kann mit jeder beliebigen Menge von lokalem Parallelverarbeitungsspeicher 204 – inklusive keinem lokalen Speicher – ausgerüstet sein, und kann lokalen Speicher und Systemspeicher in jeder Kombination nutzen. Beispielsweise kann eine PPU 202 ein Grafikprozessor in einem Ausführungsbeispiel einer Unified-Graphics-Architektur (UMA) sein. In solchen Ausführungsbeispielen würde kein dedizierter Grafikspeicher (Parallelverarbeitung) verfügbar gemacht werden und die PPU 202 würde den Systemspeicher exklusiv oder fast exklusiv nutzen. In UMA-Ausführungsballspielen kann die PPU 202 in einen Brücken-Chip oder Prozessor-Chip integriert sein oder in Form eines diskreten Chip mit einer Hochgeschwindigkeitsverbindung (PCI Express) verfügbar sein, der die PPU 202 mit dem Systemspeicher über einen Brücken-Chip, oder andere Kommunikationsmittel, verbindet.
  • Wie bereits oben erläutert, kann jede beliebige Anzahl von PPUs 202 in einem Parallelverarbeitungssubsystem 112 enthalten sein. Beispielsweise kann eine Mehrzahl von PPUs 202 auf einer einzigen Ergänzungskarte bereitgestellt sein oder eine Mehrzahl von Ergänzungskarten kann über den Kommunikationspfad 113 verbunden sein, oder eine oder mehrere PPUs 202 können in einen Brücken-Chip integriert sein. Die PPUs in einem Multi-PPU-System können zueinander identisch sein, oder sich unterscheiden. Beispielsweise können unterschiedliche PPUs 202 eine unterschiedliche Anzahl von Verarbeitungskernen aufweisen, eine unterschiedliche Menge an lokalem Wenn mehrere Parallelverarbeitungsspeicher aufweisen usw. Wenn mehrere PPUs 202 verfügbar sind, können diese PPU parallel betrieben werden, um Daten mit einem höheren Durchsatz zu verarbeiten wie es in einem System mit einer einzigen PPU 202 möglich wäre. Systeme, welche eine oder mehrere PPUs 202 aufweisen können in einer Vielzahl von Konfigurationen und Formfaktoren implementiert sein. Das schließt Desktops, Laptops oder tragbare PCs, Server, Workstations, Spielekonsolen, Embedded Systems, usw., ein.
  • Mehrfach gleichzeitige Aufgabenverteilung
  • Mehrere Berechnungsaufgaben können gleichzeitig auf den GPCs 208 verarbeitet werden und Verarbeitungsaufgaben können während ihrer Ausführung eine oder mehrere ”Tochter”-Verarbeitungsaufgaben erzeugen. Die Aufgaben-/Arbeitseinheit 207 empfängt die Aufgaben und weist die Verarbeitungsaufgaben und Tochter-Verarbeitungsaufgaben zur Ausführung den GPCs 208 zu.
  • 3A ist ein Blockdiagramm der Aufgaben-/Arbeitseinheit 207 von 2 entsprechend einem Ausführungsbeispiel der vorliegenden Erfindung die Aufgaben-/Arbeitseinheit 207 enthält eine Arbeits- oder Task-Managementeinheit 300 und die Aufgabenverteilungseinheit 340. Die Task-Management-Einheit 300 organisiert Aufgaben oder Tasks, die basierend auf Ausführungs-Prioritäts-Level zu verteilen sind. Für jeden Prioritäts-Level speichert die Task-Management-Einheit 300 eine Liste von Pointern für die TMD 322 entsprechend der Aufgaben in der Scheduler-Tabelle 321, in der die Liste als eine verkettete Liste implementiert sein kann. Die TMD 322 können in dem PP-Speicher 204 oder dem System-Speicher 214 gespeichert sein. Die Rate in der die Task-Management-Einheit 300 Aufgaben oder Tasks akzeptiert und in diese in der Scheduler-Tabelle 321 speichert, ist von der Rate, mit der die Task-Management-Einheit 300 Aufgaben zur Verarbeitung zuweist, entkoppelt. Deshalb kann die Task-Management-Einheit 300 mehrerer Aufgaben sammeln, bevor diese zugeordnet werden. Die gesammelten Aufgaben können dann basierend auf Prioritätsinformationen oder anderen Techniken wie ein Round-Robin-Scheduling zugewiesen werden.
  • Die Arbeitsverteilungseinheit 340 enthält eine Task-Tabelle 345 mit Slots, die jeweils durch die TMDs 322 für eine Aufgabe bzw. Task, besetzt sind, die auszuführen ist. Die Task-Management-Einheit 300 kann Aufgaben zur Ausführung zuweisen, wenn es ein freies Slot in der Task- bzw. Task-Tabelle 345 gibt. Wenn kein freies Slot existiert, kann eine höher priorisierte Task eine niedriger priorisierte Task, die ein Slot belegt, verdrängen. Wenn eine Task verdrängt wird, wird die Task gestoppt, und wenn die Task nicht abgeschlossen ist wird ein Pointer der Task zur einer Liste von zuzuweisenden Task-Pointern hinzugefügt, sodass die Ausführung der Task zu einem späteren Zeitpunkt wieder aufgenommen werden kann. Wenn während einer Ausführung einer Task eine Tochter-Verarbeitungs-Task erzeugt wird, wird ein Pointer der Tochter-Task zu der Liste der zuzuweisenden Task-Pointer hinzugefügt. Eine Tochter-Task kann durch eine TMD 322 die erzeugt werden, welche in dem Verarbeitungs-Cluster-Array 230 ausgeführt wird.
  • Anders als eine Task, welche durch die Aufgaben-/Arbeitseinheiten 207 von dem Frontend 212 empfangen wird, werden Tochter-Tasks von dem Verarbeitungs-Cluster-Array 230 empfangen. Tochter-Tasks werden nicht in die Push-Buffer eingefügt oder auf das Frontend übertragen. Die CPU 102 wird nicht benachrichtigt, wenn eine Tochter-Task erzeugt wird oder Daten von der Tochter-Task in dem Speicher gespeichert werden. Ein anderer Unterschied zwischen dem Tasks, die über die Push-Buffer verfügbar sind, und Tochter-Tasks besteht darin, dass Tasks, welche über die Push-Buffer kommen, durch das Anwendungsprogramm definiert sind, während die Tochter-Tasks dynamischen während der Ausführung der Tasks erzeugt werden.
  • Task-Verarbeitungs-Übersicht
  • 3B ist ein Blockdiagramm einer GPC 208 innerhalb einer der PPUs 202 von 2 entsprechend einem Ausführungsbeispiel der vorliegenden Erfindung. Jede GPC 208 kann konfiguriert sein, um eine große Anzahl von Threads parallel zu verarbeiten, wobei der Ausdruck ”Thread” für eine Instanz eines bestimmten Programmes steht, welches einen bestimmten Satz von Eingangsdaten verarbeitet. In einigen Ausführungsbeispielen werden Single-Instruction-Multiple-Data-Ausgabetechniken (SIMD) genutzt, um eine Parallelausführung einer großen Anzahl von Threads ohne eine Zurverfügungstellung einer Vielzahl von unabhängigen Verarbeitungseinheiten zu erfordern. In anderen Ausführungsbeispielen werden Single-Instruction-Multiple-Thread-Techniken (SIMT) genutzt, um eine große Anzahl von dem allgemeinen synchronisierten Threads auszuführen, wobei eine gemeinsame Verarbeitungseinheit konfiguriert ist, um Instruktionen an einen Satz von Verarbeitungs-Engines innerhalb einer der GPCs 208 auszugeben. Im Gegensatz zu einem SIMD-Ausführungs-Regime, bei dem typischerweise alle Verarbeitungs-Engines identischer Instruktionen ausführen, erlaubt es eine SIMT-Verarbeitung unterschiedlichen Threads leichter, divergenten Verarbeitungspfade durch ein gegebenes Thread-programm zu folgen. Fachleuten ist vertraut, dass ein SIMD-Regime eine funktionale Untergruppe eines SIMT-Verarbeitungs-Regimes ist.
  • Der Betrieb einer GPC 208 wird vorteilhafterweise über einen Pipeline-Manager 305 gesteuert, der Tasks an Streaming-Multiprozessoren (SMs) 310 verteilt. Der Pipeline-Manager 305 kann auch dazu konfiguriert sein, eine Arbeitslast-Verteilungs-Crossbar 330 durch eine Spezifizierung von Zielen für verarbeitete Datenausgaben der SMs 310 zu steuern.
  • In einem Ausführungsbeispiel weist jede GPC 208 eine Anzahl M von SMs 310 auf, wobei M ≥ 1, wobei jeder SM 310 konfiguriert ist, um eine oder mehrere Thread-Gruppen zu verarbeiten. Außerdem enthält vorteilhafterweise jede SM 310 einen identischen Satz von Verarbeitungseinheiten (z. B., Ausführungseinheiten und Lade/-Speicher-Einheiten – dargestellt als Ausführungseinheiten 302 und LSUs 303 in 3C), welche pipelined sind, was es erlaubt, dass eine neue Instruktionen ausgegeben werden kann, bevor eine vorangegangene Instruktion beendet wurde, wie es dem Fachmann bekannt ist. Jede Kombination von funktionalen Ausführungseinheiten kann genutzt werden. In einem Ausführungsbeispiel unterstützen die funktionalen Einheiten eine Mehrzahl von Befehlen, inklusive Integer- und Floating-Point-Arithmetik (z. B. Addition und Multiplikation), Vergleichs-Befehle, Boolsche Befehle (AND, OR, XOR), Bit-Schiebe-Befehle und eine Berechnung von verschiedenen algebraischen Funktionen (z. B. planare Interpolation, Trigonometrie, Exponentialfunktionen und logarithmische Funktionen, usw.); und die gleiche funktionale Hardware-Einheit kann zur Nutzung von unterschiedlichen Befehlen verwendet werden.
  • Die Abfolge von Instruktionen, die an eine bestimmte GPU 208 übertragen wird, macht einen Thread – wie bereits vorher definiert – aus. Eine Zusammenfassung einer bestimmten Anzahl von gleichzeitig über die Parallelverarbeitungs-Engine ausgeführten Threads wird hier im weiteren als ”Warp” oder ”Thread-Gruppe” bezeichnet. Im Weiteren beschreibt eine ”Thread-Gruppe” eine Gruppe von Threads, welche gleichzeitig das gleiche Programm auf verschiedenen Eingangsdaten ausführt, wobei jeder Thread der Gruppe einer anderen Verarbeitungs-Engine innerhalb einer SM 310 zugeordnet ist. Eine Thread-Gruppe kann weniger Threads als die Anzahl der Verarbeitungs-Engines innerhalb der SM 310 aufweisen. In diesem Fall werden einige Verarbeitungs-Engines während eines Zyklus ”idle” sein, wenn die Thread-Gruppe verarbeitet wird. Eine Thread-Gruppe kann auch mehr Threads als die Anzahl der auf Verarbeitungs-Engines innerhalb der SM 310 aufweisen. In diesem Fall wird eine Verarbeitung in aufeinanderfolgenden Taktzeiten abgearbeitet. Weil jede SM 310 bis zu G Thread-Gruppen gleichzeitig unterstützen kann, folgt, dass bis zu G·M Thread-Gruppen in der GPC 208 zu einem bestimmten Zeitpunkt ausgeführt werden können.
  • Zusätzlich kann eine Mehrzahl von zugehörigen Thread-Gruppen (in unterschiedlichen Ausführungsphasen) zur gleichen Zeit innerhalb einer SM 310 aktiv sein. So eine Ansammlung von Thread-Gruppen wird hier und im Weiteren als ein ”kooperatives Thread-Array” (”CTA”) oder ”Thread Array” bezeichnet. Die Größe eines bestimmten CTA ist gleich m·k, wobei k die Anzahl der gleichzeitig ausgeführten Threads in einer Thread-Gruppe ist. Sie ist typischerweise Integer-Vielfaches der Anzahl der Parallelverarbeitungs-Engines des SM 310, und m ist die Anzahl der gleichzeitig aktiven Thread-Gruppen innerhalb der SM 310. Die Größe eines CTA wird im Allgemeinen durch den Programmierer und den Umfang der Hardware-Ressourcen – wie des im CTA verfügbaren Speichers oder Registern – festgelegt.
  • Jede SM 310 enthält einen Level-1-Cache (L1) (dargestellt in 3C) oder nutzt einen Platz in einem entsprechenden L1-Cache außerhalb der SM 310, welcher genutzt wird, um Lade- und Speicher-Befehle auszuführen. Jede SM 310 hat auch Zugriff auf einen Level-2-Cache (L2), welchen sich alle GPCs 208 teilen und welcher genutzt werden kann, um Daten zwischen den Threads auszutauschen. Außerdem haben die SM 310 Zugriff auf einen „globalen” Speicher außerhalb des Chip (off-chip), beispielsweise einem Parallelverarbeitungsspeicher 204 und/oder einem Systemspeicher 104. Dabei sollte klar sein, dass jeder Speicher, welche extern zur PPU 202 ist, als globaler Speicher genutzt werden kann. Außerdem kann ein Level-1,5-Cache (11,5) 335 in der GPC 208 enthalten sein, welcher konfiguriert ist, um Daten zu empfangen und zu halten, die über das Speicher-Interface 214 durch den SM 310 angefordert und vom Speicher abgerufen wurden. Dies umfasst Instruktionen, einheitliche Daten, und konstante Daten und stellt die angeforderten Daten der SM 310 dar. Ausführungsformen, welche mehrere SM 310 in der GPC 208 aufweisen, können den Vorteil eines gemeinsamen Instruktions- und Daten-Cache im L1,5-Cache 335 nutzen.
  • Jeder GPC 208 kann nur eine Speichermanagementeinheit (MMU) 328 aufweisen, welche konfiguriert ist, virtuelle Adressen auf physikalische Adressen abzubilden. In anderen Ausführungsbeispielen können sich MMUs 328 innerhalb des Speicher-Interfaces 214 befinden. Die MMU 328 weist einen Satz von Seitentabelleneinträgen (PTE = page table entries) auf, welcher dafür genutzt wird, eine virtuelle Adresse auf eine physikalische Adresse oder „Tile” oder optional auf einen Cache-Line-Index abzubilden. Die MMU 328 kann Address-Translation-Lookaside-Buffer (TLB) oder Caches aufweisen, die sich in dem Multiprozessor SM 310 oder dem L1-Cache oder der GPC 208 befinden. Die physikalischer Adresse wird verarbeitet, um einen Oberflächendatenzugriffe für eine effiziente Anforderungsverschachtelung zwischen den Partition-Einheiten 215 zu erlauben. Der Cache-Line-Index kann dafür genutzt werden, festzustellen, ob eine Anforderung für eine Cache-Line ein „Hit” oder „Miss” ist.
  • In Grafik- und Computeranwendungen kann eine GPC 208 dafür konfiguriert sein, dass jeder SM 310 an eine Textureinheit 315 zur Ausführung von Textur-Abbildungsbefehlen – z. B. Feststellung von Textur-Muster-Positionen, Lesen von Texturdaten und Filterung der Texturdaten – gekoppelt ist. Texturdaten werden von einem internen Textur-L1-Cache (nicht dargestellt) – oder in einigen Ausführungsbeispielen – von dem L1-Cache innerhalb des SM 310 gelesen und von einem L2-Cache angefordert, der von allen GPCs 208 genutzt wird, dem Parallelverarbeitungsspeicher oder dem Systemspeicher 104, wie es erforderlich ist. Jeder SM 310 gibt verarbeitete Tasks an die Verarbeitungs-Verteilungs-Crossbar 330 aus, um die verarbeitete Task einer anderen GPC 208 zur Weiterverarbeitung zur Verfügung zu stellen, oder um die verarbeitete Task in einem L2-Cache, dem Parallelverarbeitungsspeicher, oder Systemspeicher über die Crossbar-Einheit 210 zu speichern. Eine preROP (pre-raster operations) 325 ist konfiguriert, um Daten von einem SM 310, direkte Daten an RPO-Einheiten innerhalb von Partition-Einheiten 215 zu empfangen und Optimierungen für Farbmischungen auszuführen, Pixel-Farbdaten zu organisieren und Adressübersetzungen auszuführen.
  • Es sei darauf hingewiesen, dass die Kernarchitektur, welche hier beschrieben ist, einen nur illustrativen Charakter hat, und dass Abweichungen und Modifikationen möglich sind. Jede beliebige Anzahl von Verarbeitungseinheiten, z. B. SM 310 oder Textureinheiten 315 oder preROP 325 können in einer GPC 328 enthalten sein. Wie es weiterhin in 2 dargestellt ist, kann eine PPU 202 eine Anzahl von GPCs 208 enthalten, welche vorteilhafterweise einander ähnlich sind, so dass es nicht davon abhängt, von welcher GPC 208 eine bestimmte Verarbeitungs-Task empfangen wird. Darüber hinaus funktioniert jede GPC 208 unabhängig von anderen und nutzt separate eindeutig zugewiesene Verarbeitungseinheiten, L1-Caches, um Tasks für ein oder mehrere Anwendungsprogramme auszuführen.
  • Kenner des Faches werden verstehen, dass die Architektur, die in den 1, 2, 3A und 3B dargestellt sind, in keiner Weise den Umfang der vorliegenden Erfindung beschränkt, und dass die Techniken, die hier dargestellt sind, auf jeder ordentlich konfigurierten Verarbeitungseinheit ausgeführt werden können. Das bedeutet auch und ohne Einschränkung auf einer oder mehreren CPUs, einer oder mehreren GPCs 208, einer oder mehreren Graphik- oder Spezialverarbeitungseinheiten, etc. ohne vom Grundgedanken der vorliegenden Erfindung abzuweichen.
  • In Ausführungsbeispielen der vorliegenden Erfindung, ist es wünschenswert, eine PPU 202 oder andere Prozessoren eines Computersystems zu nutzen, um allgemeine Berechnungen unter Nutzung von Thread-Arrays durchzuführen. Jedem Thread im Thread-Array wird ein eindeutiges Thread-Kennzeichen („Thread-ID”) zugewiesen, auf welches von dem Thread während der Verarbeitung des Thread zugriffen werden kann. Die Thread-ID, welche als eindimensionaler oder mehrdimensionaler numerischer Wert definiert werden kann, steuert verschiedene Aspekte des Verhaltens der Thread-Verarbeitung. Beispielsweise kann eine Thread-ID genutzt werden, um festzustellen, welcher Anteil des Eingangsdatensatzes von dem Thread verarbeitet werden soll und/oder um festzustellen, welcher Anteil des Ausgabedatensatzes von einem Thread erzeugt oder geschrieben werden soll.
  • Eine Abfolge von pro-Thread Instruktionen kann mindestens eine Instruktion aufweisen, die ein kooperatives Verhalten zwischen dem repräsentativen und einem oder mehreren anderen Threads des Thread-Array definiert. Beispielsweise kann die Abfolge von pro-Thread Instruktionen aufweisen: eine Instruktion zum Aussetzen von Befehlen für den repräsentativen Thread an einem bestimmten Punkt in der Abfolge aufweisen, bis zu einer Zeit, zu der einer oder mehrere der anderen Threads diesen besonderen Punkt erreichen; eine Instruktion des repräsentativen Thread zum Speichern von Daten in einem gemeinsam genutzten (shared) Speicher, auf den eine oder mehrere der anderen Threads Zugriff haben; eine Instruktion für einen repräsentativen Thread, um atomistisch Daten in einem gemeinsam genutzten Speicher zu lesen oder zu schreiben, oder Daten zu aktualisieren, die in dem gemeinsam genutzten Speicher gespeichert sind, auf den ein oder mehrere der anderen Threads Zugriff auf Basis Ihrer ID etc. haben. Das CTA-Programm kann also eine Instruktion aufweisen, eine Adresse in dem gemeinsam genutzten Speicher, von dem Daten gelesen werden zu, zu berechnen, wobei die Adresse eine Funktion der Thread-ID ist. Durch eine Definition von geeigneten Funktionen und bei Synchronisationstechniken können Daten an eine vorgegebene Adresse in dem gemeinsam genutzten Speicher durch einen Thread eines CTA geschrieben werden und von einem anderen Thread von dem Speicherort durch einen anderen Thread oder dem gleichen CTA in einer vorhersagbaren Art gelesen werden. Folglich kann jedes gewünschte Muster zur gemeinsamen Nutzung von Daten zwischen den Threads unterstützt werden und jeder Thread kann Daten mit jedem anderen Thread in dem gleichen CTA gemeinsam nutzen. Der potenzielle Umfang einer gemeinsamen Datennutzung zwischen Threads eines CTA wird durch das CTA-Programm festgelegt; es versteht sich also, dass bei einer bestimmten Anwendung, welche CTAs nutzt, die Threads eines CTA tatsächlich Daten gemeinsamen – abhängig von dem CTA-Programm – miteinander nutzen oder nicht, wobei die Begriffe „CTA” und „Thread-Array” hier als Synonyme genutzt werden.
  • 3C ist ein Blockdiagramm des SM 310 von 3B entsprechend einem Ausführungsbeispiel der vorliegenden Erfindung. Die SM 310 weist einen Instruktions-L1-Cache auf, welcher konfiguriert ist, Instruktionen und Konstanten vom Speicher über den L1,5-Cache zu empfangen. Eine Warp-Scheduler-und-Instruktions-Einheit 312 empfängt Instruktionen und Konstanten über den Instruktions-L1-Cache 370 und steuert die lokalen Register 304 und SM-Funktionseinheiten 310 entsprechend den Instruktionen und Konstanten. Die SM-Funktionseinheiten 310 weisen N Exec-Einheiten 302 (Ausführung oder Verarbeitung) und P-Lade/-Speicher-Einheiten (LSU) 303 innerhalb eines LSU-Array 375 auf.
  • Die SM 310 bietet einen On-Chip-Datenspeicher (intern) mit unterschiedlichen Zugriffs-Leveln. Von speziellen Registern (nicht dargestellt) kann durch die LSU 303 gelesen aber nicht geschrieben werden und sie werden dazu genutzt, Parameter zu speichern, welche jede „Thread-Position” definiert. In einem Ausführungsbeispiel weisen spezielle Register ein Register pro Thread auf (oder pro Exec-Einheit 302 innerhalb von SM 310), welches die Thread-ID speichert; jedes Thread-ID-Register ist nur von einer entsprechenden Exec-Einheit 302 zugreifbar. Spezielle Register können auch zusätzliche Register umfassen, welche durch alle Threads lesbar sind, welche die gleiche Verarbeitungs-Task verarbeiten, welche durch TMD 322 präsentiert werden (oder durch alle LSU 303), welche folgendes aufweisen: ein CTA-Kennzeichnung, die CTA-Dimensionen, die Dimensionen eines Grid, zu welchem das CTA gehört (oder eine Warteschlangenposition, wenn die TMD 322 eine glatte Queue-Task anstelle einer Grid-Task kodiert), und eine Kennzeichnung der TMD 322, zu welchen das CTA zugewiesen ist.
  • Wenn die TMD 322 Grid-TMD sind, bedingt eine Ausführung der TMD 322 einen Start und eine Ausführung einer festen Anzahl von CTAs, um den festgelegten Umfang der Daten, welche in der Warteschlange (Queue) 525 gespeichert sind, abzuarbeiten. Die Anzahl der CTAs wird durch das Produkt aus der Grid-Breite, -Höhe und -Tiefe festgelegt. Der festgelegte Umfang an Daten kann in den TMD 322 gespeichert sein, oder die TMD 322 können einen Pointer auf die Daten speichern, die von dem CTA verarbeitet werden. Die TMD 322 speichern auch eine Startadresse des Programms, welches durch die CTAs ausgeführt wird.
  • Wenn die TMD 322 eine Warteschlangen-TMD (Queue-TMD) ist, wird eine Warteschlangen-Besonderheit der TMD 322 genutzt, was bedeutet, dass der Umfang der zu verarbeitenden Daten nicht notwendigerweise festgelegt ist. Queue-Einträge speichern Daten zur Verarbeitung durch die CTAs, welche den TMD 322 zugeordnet sind. Die Queue-Einträge können auch eine Tochter-Task repräsentieren, welche durch eine TMD 322 während einer Ausführung des Thread erzeugt wird, wodurch eine geschachtelte Parallelität erreicht wird. Normalerweise wird die Ausführung des Thread oder CTA, welche den Thread aufweist, ausgesetzt, bis die Ausführung der Tochter-Tasks abgeschlossen ist. Die Queue kann in den TMD 322 oder separat von den TMD 322 gespeichert sein. In diesem Fall speichern die TMD 322 einen Queue-Pointer für die Queue. Vorteilhafterweise werden die Daten, welche durch die Tochter-Task erzeugt werden, in die Queue geschrieben, während die TMD 322, welche die Tochter-Task generiert, ausgeführt wird. Die Queue kann als eine zirkulierende Queue implementiert sein, sodass der gesamte Umfang der Daten nicht auf die Größe der Queue begrenzt ist.
  • CTAs, welche zu einem Grid gehören, haben implizite Grid-Breite-, -Höhe-, und -Tiefe-Parameter, welche die Positionen innerhalb des entsprechenden CTAs innerhalb des Grid festlegen. Spezielle Register werden während einer Initialisierung als Folge von Befehlen, die über das Frontend 212 von dem die Device-Treiber 103 empfangen werden und werden während der Ausführung einer Verarbeitungs-Task nicht verändert. Das Frontend 212 legte für jede Verarbeitungs-Task die Ausführungszeiten fest. Jedem CTA werden spezifische TMD 322 zur gleichzeitigen Ausführung von einer oder mehreren Task zugeordnet. Zusätzlich können einzelne GPCs 208 mehrere Task gleichzeitig ausführen.
  • Ein Parameterspeicher (nicht dargestellt) speichert Runtime-Parameter (Konstanten), welche durch jeden Thread innerhalb des gleichen CTA (oder anderen LSU 303) gelesen aber nicht geschrieben werden können. In einem Ausführungsbeispiel stellt der Device-Treiber 103 Parameter an den Parameterspeicher zur Verfügung, bevor die SM 310 angewiesen wird, eine Ausführung einer Task unter Nutzung dieser Parameter zu beginnen. Jeder Thread innerhalb irgendeines CTA (oder jeder Exec-Einheit 302 innerhalb SM 310) kann auf einen globalen Speicher durch ein Speicher-Interface 214 zugreifen. Teile des globalen Speichers können in dem L1-Cache 320 gespeichert sein.
  • Der lokale Registerspeicher 304 wird von jedem Thread als Zwischenspeicher genutzt; jedes Register ist der exklusiven Nutzung durch eine Thread vorbehalten. Grunddaten in irgendeinem lokalen Registerspeicher 304 sind nur durch den Thread zugreifbar, für den das Register exklusiv bestimmt ist. Der lokale Registerspeicher 304 kann als ein Registerspeicher implementier sein, welches physikalisch oder logisch in P Ebenen aufgeteilt ist, wobei jede Ebene eine Anzahl von Einträgen aufweist (dabei kann jeder Eintrag z. B. ein 32-Bit-Wort speichern). Jeweils ein Zugang ist jeder der N Exec-Einheiten 302 und P Lade/-Speicher-Einheiten 303 zugewiesen, und entsprechende Einträge der unterschiedlichen Zugänge können mit Daten für unterschiedliche Thread gefüllt sein, welche das gleiche Programm ausführen, um einer SIMD-Ausführung gerecht zu werden. Unterschiedliche Anteile der Zugänge können unterschiedlichen der G gleichzeitigen Thread-Gruppen zugeordnet sein, so dass ein gegebener Eintrag in dem lokalen Registerspeicher 304 nur von einen bestimmten Thread aus zugreifbar ist. In einem Ausführungsbeispiel sind bestimmte Einträge in den lokalen Registerspeicher 304 zum Speichern von Thread-Kennzeichnern reserviert, welche eines der speziellen Register implementieren.
  • Der gemeinsam genutzte Speicher 306 (auch shared memory) ist für Threads innerhalb eines einzelnen CTAs reserviert; mit anderen Worten: jeder Speicherplatz in dem gemeinsam genutzten Speicher 306 ist durch jeden Thread innerhalb des gleichen CTA (oder für jede Verarbeitungs-Engine innerhalb von SM 310) zugreifbar. Der gemeinsam genutzte Speicher 306 kann als ein gemeinsam genutzter Registerspeicher oder als ein gemeinsam genutzter Cache-Speicher auf dem Chip implementiert sein und kann einen Interconnect aufweisen, welcher es jeder Verarbeitungs-Engine erlaubt, jeden Speicherplatz in dem gemeinsam genutzten Speicher zu lesen oder zu beschreiben. Mit anderen Worten: jeder genutzter Status-Speicherplatz kann auf eine pro-CTA-Region von Speicherplätzen außerhalb des Chips abgebildet werden und im L1-Cache 320 „gecached” werden. Der Parameterspeicher kann als eine fest zugewiesene Sektion innerhalb des gemeinsam genutzten Registerspeichers oder gemeinsam genutzten Cache-Speichers implementiert sein, welcher als gemeinsam genutzten Speicher 306 oder auch als ein separater gemeinsam genutzter Registerspeicher oder On-Chip Cache-Speicher implementiert sein kann, auf denen die LSUs 303 ausschließlichen Lesezugriff haben. In einem Ausführungsbeispiel wird der Bereich, der den Parameterspeicher implementiert, auch genutzt, um die CTA-ID wie auch die Task-ID und Grid-Dimensionen oder Warteschlangenpositionen zu speichern, wodurch Anteile der speziellen Register implementiert sind. Jede LSU 303 in dem LSU-Array 375 enthält eine Adresse-Erzeugungseinheit (dargestellt in 4A), welche eine Adresse, die für Lade- und Speicherbefehle bereitgestellt wird, welche in einem einheitlichen Speicherraum spezifiziert sind, in eine Adresse in jedem spezifischen Adressraum konvertiert. Folglich kann jeder Befehl dazu genutzt werden, um auf die lokalen, gemeinsam genutzten oder global verfügbaren Speicherräume durch Angabe einer Adresse in dem einheitlichen Speicherraum zuzugreifen.
  • Der L1-Cache 320 in jedem SM 310 kann dazu genutzt werden, um private, pro-Thread-lokale Daten – also pro-Anwendung globale Daten – zwischen zu speichern (zu „cachen”). In einigen Ausführungsbeispielen können pro-CTA gemeinsam genutzte Daten in den L1-Cache 310 ge-cached werden. Die LSUs 303 sind mit dem gemeinsam genutzten Speicher 306 und dem L1-Cache 320 und einem Speicher-und-Cache-Interconnect 380 verbunden.
  • Auf Anwendungs- und Compiler-Level erscheinen die besonderen Speicherräume innerhalb eines einzigen einheitlichen Adressraumes. Deshalb werden einheitliche Speicherzugriffsbefehle anstelle von separaten Lade- und Speicherbefehlen für jeden bestimmten Speicherraum genutzt. Ein C/C++ Programm kann einen einheitlichen Pointer und einen einheitlichen Zugriffsbefehl nutzen, um effektiv auf einen der drei besondere Adressräume zuzugreifen. Ein beispielhaftes Ladebefehlsformat ist: LD.32 RD [Rd + Offset]; welches auf eine Gruppe von P parallelen Threads ausgeführt wird und Register Rd von jedem Thread mit 32-Bit-Daten aus dem Speicher von jeder einheitlichen Byte-Adresse lädt, welche durch jeweils die Summe des Thread-Registers Ra plus Offset spezifiziert ist. Ein Beispiel für ein Ladebefehlsformat ist: ST.32 [Rd + Offset], Rb; welches auf einer Gruppe von P parallelen Threads ausgeführt wird und 32-Bit-Daten von jedem Register jedes Thread an jeder einheitliche Byte-Adresse speichert, welche durch die Summe jedes Thread-Registers Ra plus Offset spezifiziert ist. Kürzlich werden die Exec-Einheiten 302 konfiguriert, um 64- und 128-Bit-Daten zu verarbeiten, so dass durch die Lade- und Speicher-Befehle Lese- und Schreib-Aktionen auf entsprechend 64- und 128-Bit-Daten zugegriffen wird.
  • Verarbeitung von einheitlichen Lade-Befehlen für Teilsätze von parallelen Threads
  • Ein Compiler (nicht dargestellt) kompiliert ein Anwendungsprogramm in Befehle, welche durch jeden Thread in einer Single-Instruction/Multiple-Thread(SIMT)-Umgebung, wie etwa dem Parallelverarbeitungssubsystem 112, ausgeführt werden. Während des Compilierungsprozesses entdeckt der Compiler Programmbefehle, welche eine gewisse Wahrscheinlichkeit dafür haben, dass mehrere Threads innerhalb einer Thread-Gruppe auf die gleichen Speicheradressen zugreifen werden, wenn sie in der SIMT-Umgebung ausgeführt werden. Wie im Weiteren genauer erklärt wird, stellt der Compiler fest, dass eine Programmanweisung wahrscheinlich einem einheitlichen Muster von Speicherzugriffen der Threads in einer Thread-Gruppe gleicht. Für jeden solcher Programmanweisungen fügt der Compiler in dem kompilierten Anwendungsprogramm einen Hinweis darauf ein, dass die Lade-Instruktionen als eine einheitliche Lade-Instruktionen anstelle einer Standard-Lade-Instruktion verarbeitet wird. Ein Beispiel für ein einheitliches Ladebefehlsformat ist: LD-U.128 Rd [Rd + Offset]; welches eine Gruppe von P parallelen Threads ausführt und jedes Register Rd von jedem Thread mit 128-Bit-Daten vom Speicher jeder Byte-Adresse lädt, welche durch die Summe aus dem Threads-Register Ra und dem Offset spezifiziert ist.
  • Die LD und LD.U-Varianten der Ladebefehle sind in Bezug auf die Funktionen äquivalent. Ein einheitlicher Ladebefehl LD.U weist darauf hin, dass mindestens ein Teil der P Adressen, welche durch die P Threads der Thread-Gruppe bereitgestellt werden, die gleiche Speicheradresse oder den gleichen Satz von Speicheradressen referenziert. Es ist möglich, dass jeder Thread in der Thread-Gruppe eines LD.U-Befehls eine andere Speicheradresse referenziert; in diesem Fall wird der LD.U-Befehle durch das LSU-Array 375 in gleicher Art und Weise wie ein LD-Befehl ausgeführt. Es ist wichtig festzustellen, dass eine Verarbeitung des LD.U-Befehls nicht voraussetzt, dass alle Threads in der Thread-Gruppe auf eine einzelne gemeinsame Speicheradresse Bezug nehmen. Ein Performance-Gewinn kann dadurch entstehen, dass Threads in der Thread-Gruppe ein einheitliches Muster von Speicheradressen anstelle von unterschiedlichen Speicheradressen referenziert. Ein beispielhaftes einheitliches Muster besteht aus Paaren von Threads, welche die gleiche Speicheradresse haben. Die Threads in einen Thread-Paar haben einen Offset von i in der gleichen Thread-Gruppe, wobei der einzige Integer-Wert kleiner oder gleich bzgl. P/2 ist. Wenn beispielsweise i = 1 ist, entsprechen die Thread-Paare benachbarten Threads, beispielsweise thread0 und thread1...thread30 und thread31.
  • Wie im Detail im Folgenden beschrieben ist, wird der einheitliche Ladebefehl für das Subset der parallelen Threads ausgeführt und ein einzelner Speicher-Leseaufruf wird übertragen, um die Daten an der durch die parallelen Threads spezifizierten Speicheradressen zu laden, wenn das LSU-Array 375 feststellt, dass parallele Threads in der Thread-Gruppe mit einem einheitlichen Mustern von Speicheradressen für einen einheitlichen Ladebefehl übereinstimmen. Die aufgerufenen Daten werden dann auf jeden der Threads verteilt, welcher auf die entsprechende Speicheradressen verweist. Die Speicher-Bandbreiten-Anforderungen zu von dem LSU-Array 375 wird im Vergleich zu einem Aufruf der gleichen Daten für mehrere Threads reduziert.
  • 4 ist ein Blockdiagramm des LSU-Array 375 von 3C entsprechend einem Ausführungsbeispiel der vorliegenden Erfindung. Wie dargestellt, weist das LSU-Array 375 unterschiedliche LSUs 303, eine Adresserzeugungseinheit 405, eine einheitliche Ladeeinheit 410 und eine nicht-einheitliche Ladeeinheit 415 auf.
  • In einer SIMT-Architektur – wie derjenigen, welche in den 3A–3C beschrieben ist – wird eine einzelne Instruktion auf eine Gruppe (Warp) der P parallelen Threads zusammen mit einer aktiven Maske für den Warp verteilt. Die aktive Maske weist darauf hin, welche individuellen Threads in einem Warp für eine Ausführung der Instruktion für den Warp geeignet ist. Aktive Threads führen die Instruktionen aus und nicht aktive Threads führen die Instruktion nicht aus. Threads werden aktiv oder nicht aktiv wenn es einen Unterschied während einer Ausführung eines Programmes gibt, welcher auf eine Verzweigung o. ä. zurückgeht. Bis zu P aktive Threads verarbeiten die Instruktionen simultan. Ein Arithmetikbefehl für P Threads wird durch P parallele Exec-Einheiten 302 ausgeführt. Ein Speicher-Lade-/Speicher-Befehl für P Threads wird durch P parallele LSUs 303 ausgeführt. Folglich erhält ein Speicherbefehl für P Threads P Adressen, welche P oder weniger unterschiedliche Speicheradressen sein können.
  • Die Adress-Erzeugungseinheit 405 führt Adressberechnungsaufgaben durch, z. B. Adress-Mapping-Operationen für Lade-/Speicher Instruktionen. In einem Ausführungsbeispiel kann die Adress-Erzeugungseinheit 405 konfiguriert sein, um eine Anforderung von einem Warp über mehrere Zyklen zu verarbeiten, so dass ein Teilsatz der Threads während jedes Zyklus der mehreren Zyklen verarbeitet wird. Beispielsweise kann ein Teilsatz von 8 Threads in viele Zyklen verarbeitet werden, wenn der Warp 32 Threads enthält.
  • Die aktive Maske und die Speicheradressen für mindestens einen Teilsatz der Threads in einem Warp wird durch die Adress-Erzeugungseinheit 405 an die einheitliche Ladeeinheit 410 ausgegeben. Wenn eine Lade-Instruktion als eine einheitliche Lade-Instruktionen spezifiziert ist, vergleicht die einheitliche Ladeeinheit 410 die Speicheradressen für aktive Threads in jedem Teilersatz der Threads, um festzustellen, ob die parallelen Threads in dem Teilsatz mit einem einheitlichen Muster der Speicheradressen übereinstimmen. Die einheitliche Ladeeinheit 410 kann ein oder mehrere unterschiedliche einheitliche Muster für den Vergleich nutzen. Jedes einheitliche Muster kann konfiguriert sein, um separat für den Vergleich aktiviert oder deaktiviert zu sein. Insbesondere werden Speicheradressen von Threads, die entsprechend der aktiven Maske nicht aktiv sind, als übereinstimmend mit jeder Speicheradresse angesehen.
  • Wenn die Lade-Instruktion als eine einheitliche Lade-Instruktionen spezifiziert ist und die Speicheradressen für die aktiven Threads in jedem Teilsatz der Threads mit mindestens einem einheitlichen Muster übereinstimmen, kann die Lade-Instruktion als eine einheitliche Lade-Instruktion ausgeführt werden. Die einheitliche Ladeeinheit 410 gibt eine eindeutige Speicheradresse für die aktiven Threads an die nicht-einheitliche Ladeeinheit 415 zur Verarbeitung aus. Es sei darauf hingewiesen, dass, wenn die Lade-Instruktionen als eine einheitliche Lade-Instruktion durch die einheitliche Ladeeinheit 410 identifiziert wird, die Anzahl der eindeutigen Speicheradressen höchstens halb so groß im Vergleich zu einer Lade-Instruktion ist, welche Speicheradressen spezifiziert, die nicht mit einem einheitlichen Muster übereinstimmen (dabei wird angenommen, dass eine Übereinstimmung mit einem einheitlichen Muster nicht das Ergebnis eines nicht-aktiven Thread ist). Deshalb kann die Anzahl der Lese-/Schreib-Anforderungen durch das LSU-Array 375 reduziert werden und der Umfang der Daten, welche über den Speicher-und-Cache-Interconnect 380 an die LSUs 303 zurückgegeben wird, ebenfalls reduziert werden.
  • Wenn die Lade-Instruktion nicht als eine einheitliche Lade-Instruktion spezifiziert wird, gibt die einheitliche Ladeeinheit 410 die aktive Maske und die Speicheradressen durch die nicht-einheitliche Ladeeinheit 415 zur Verarbeitung aus. Die nicht-einheitliche Ladeeinheit 415 überträgt jede eindeutige Speicheradressen, auf welche durch einen aktiven Thread in dem Warp Bezug genommen wird, an die LSUs 303. Die LSUs 303 übertragen dann eine Lese-Anforderung inklusive einer oder mehrere der einheitlichen Speicheradressen an den Speicher-und-Cache-Interconnect 308, um Daten für die parallelen Threads in dem Warp aufzurufen. Die maximale Anzahl der einheitlichen Speicheradressen, welche in einem einzelnen Taktzyklus übertragen werden, wird typischerweise durch die Speicherarchitektur und die Schnittstellen zwischen dem LSU-Array 375 und dem Speicher-und-Cache-Interconnect 308 begrenzt.
  • In einem Ausführungsbeispiel kann die einheitliche Ladeeinheit 410 und die nicht-einheitliche Ladeeinheit 415 konfiguriert sein, um nur die Anzahl der eindeutigen Speicheradressen an die LSU 303 auszugeben, die durch die LSU 303 als eine einzelner Lese-Anforderung übertragen werden kann. Wenn die Anzahl der einheitlichen Speicheradressen für einen Warp größer als die Anzahl ist, wird eine Wiederholungs-Anforderung durch die nicht-einheitliche Ladeeinheit 415 an den Warp-Scheduler-und-Instruktions-Einheit 312 ausgegeben. Die Warp-Scheduler-und-Instruktions-Einheit 312 wird dann die Lade-Instruktionen zu einem späteren Zeitpunkt erneut aufsetzen und zusätzliche Taktzyklen zur Ausführung der Lade-Instruktionen reservieren, um der Übertragung von mehreren Lese-Anforderungen – wie für die LSUs 303 erforderlich – zu ermöglichen. Alle nachfolgenden Instruktionen für den gleichen Warp werden nicht beachtet oder anders von einer Ausführung abgehalten bis die Lade-Instruktion erneut aufgesetzt und erfolgreich durch das LSU-Array 303 ausgeführt wurde.
  • 4B ist ein konzeptionelles Diagramm, welches einen Teilsatz von parallelen Threads und eine erstes einheitliches Muster 421 darstellt, welches genutzt wird, um ein Vergleichsergebnis 431 entsprechend einem Ausführungsbeispiel der vorliegenden Erfindung zu erzeugen. Der Teilsatz der parallelen Threads 420 enthält acht parallele Threads in einem 32-Thread-Warp. Die einheitliche Ladeeinheit 410 empfängt die Warp-Adressen 430 und identifiziert die individuellen Speicheradressen, die dem Teilsatz der Threads 420 zugeordnet sind. Die individuellen Speicheradressen, die dem Teilsatz der parallelen Threads 420 zugeordnet sind, basieren auf einem einheitlichen Muster 421, um das Vergleichsergebnis 431 zu erzeugen. Das einheitliche Muster 421 gruppiert aufeinanderfolgende Threads in dem Teilsatz von parallelen Threads 420 für den Speicheradressenvergleich. Die Threads in jedem Thread-Paar werden durch die Thread-Index-Werte n und (n XOR 1) definiert.
  • Die individuellen Speicheradressen der parallelen Threads mit den Indizes 0, und 1, Indizes 2 und 3, Indizes 16 und 17 und Indizes 18 und 19 werden durch die einheitliche Ladeeinheit 410 verglichen, um vier übereinstimmender Ergebnisse zu erzeugen. In anderen Ausführungsbeispielen können Speicheradressen mit anderen Indizes verglichen werden. Die vier übereinstimmenden Ergebnisse werden dann genutzt, um das Vergleichsergebnis 431 zu erzeugen. Das Vergleichsergebnis 431 weist darauf hin, ob eine einheitliche Lade-Instruktion für den Teilesatz der parallelen Threads zum Lesen von Daten genutzt werden kann. Zusätzliche zweite, dritte und vierte Teilsätze von parallelen Threads können Threads 4 bis 7 und Threads 20–23, Threads 8–11 und Threads 24–27 und Threads 12–15 und Threads 28–31 entsprechend enthalten.
  • In einem Ausführungsbeispiel hat jeder Thread die Bandbreite, um 64 Bits an Daten zurückzugeben, was der halben Datenmenge entspricht, wenn 128-Bit-Befehle ausgeführt werden. Wenn Threads gepaart werden, wird die Hälfte der Daten über die Bandbreite, die für den ersten Thread reserviert ist, zurückgegeben und die andere Hälfte der Daten wird über die Bandbreite, die für den zweiten Thread reserviert ist, zurückgegeben. Die Hälfte der Daten wird dann von dem ersten und dem zweiten Thread innerhalb des LSU-Array 375 gemeinsam genutzt.
  • 4C ist ein anderes konzeptionelles Diagramm, welches den Teilsatz der parallelen Threads 420 und ein zweites einheitliches Muster 422 darstellt, welches genutzt wird, um ein Vergleichsergebnis 432 entsprechend einem Ausführungsbeispiele der vorliegenden Erfindung zu erzeugen. Die einheitliche Ladeeinheit 410 identifiziert jetzt die individuellen Speicheradressen, die dem Teilsatz der parallelen Threads 420 zugeordnet sind, und vergleicht dann die individuellen Speicheradressen basierend auf dem einheitlichen Muster 422, um das Vergleichsergebnis 432 zu erzeugen. Das einheitliche Muster gruppiert Threads, welche einen Index aufweisen, welcher einen Offset von 16 in dem Teilsatz der parallelen Threads 420 für den Speicheradressenvergleich aufweisen.
  • In einem Ausführungsbeispiel werden die Warp-Adressen 430 durch die einheitliche Ladeeinheit 410 über zwei oder mehrere Taktzyklen empfangen, so dass zwei Threads in dem Thread-Paar in der gleichen Lane (z. B. die gleichen Signale) beim Takt t und (t XOR 1) empfangen werden. Die individuellen Speicheradressen der parallelen Threads mit den Indizes 0 und 16, Indizes 1 und 17, Indizes 2 und 18, und Indizes 3 und 19 werden durch die einheitliche Ladeeinheit 410 verglichen, um vier Übereinstimmungsergebnisse zu erzeugen. Die vier Ergebnisse werden dann genutzt, um das Vergleichsergebnis 432 für das einheitliche Muster 422 zu erzeugen. Das Vergleichsergebnis 432 weist darauf hin, ob eine einheitliche Lade-Instruktion genutzt werden kann, um Daten für den Teilsatz der parallelen Threads 420 basierend auf dem einheitlichem Muster 422 zu lesen.
  • Wenn alle aktiven Threads in dem Teilsatz der parallelen Threads 420 entweder mit dem einheitlichen Muster 421 oder dem einheitlichen Muster 422 übereinstimmen, wird die Lade-Instruktionen als eine einheitliche Lade-Instruktionen durch die einheitliche Ladeeinheit 410 für mindestens den Teilsatz der parallelen Threads 420 bestimmt. Wenn die Threads in dem Teilsatz der parallelen Threads 420 mit beiden der einheitlichen Muster 421 und 422 übereinstimmt, wird eins der beiden einheitlichen Muster basierend auf Prioritätseinstellungen ausgewählt. Wenn hingegen die Threads in dem Teilsatz der parallelen Threads 420 nicht mit einem der einheitlichen Muster übereinstimmen, wird die Lade-Instruktion als eine nicht-einheitliche Lade-Instruktion durch die nicht-einheitliche Ladeeinheit 415 für die Threads in dem Teilsatz der parallelen Threads 420 ausgeführt.
  • In einem Ausführungsbeispiel müssen alle Teilsätze der parallelen Threads innerhalb eines Warp mit dem gleichen einheitlichen Muster für die Lade-Instruktion übereinstimmen, um als eine einheitliche Lade-Instruktion ausgeführt zu werden. Mit anderen Worten: das einheitliche Muster wird auf Warp-Level anstelle auf Teilsatz-Level angewendet.
  • 4D ist ein anderes Konzeptdiagramm, welches den Teilsatz der Threads 420 und ein drittes einheitliches Muster 423 darstellt, welches genutzt wird, um ein Vergleichsergebnis 433 entsprechend einem Ausführungsbeispiel der vorliegenden Erfindung zu erzeugen. Die einheitliche Ladeeinheit 410 stellt die individuellen Speicheradressen fest, die dem Teilsatz der parallelen Threads 420 zugeordnet ist, und vergleicht dann die individuellen Speicheradressen basierend auf dem einheitlichen Muster 423, um das Vergleichsergebnis 433 zu erzeugen. Das einheitliche Muster 423 gruppiert Threads, die einen Index mit einem Offset von 1, 2 und 3 in dem Teilsatz von parallelen Threads 420 aufweisen, für den Speicheradressenvergleich. Insbesondere werden die individuellen Speicheradressen von parallelen Threads mit Indizes 0, 1, 2 und 3 und Indizes 16, 17, 18 und 19 durch die einheitliche Ladeeinheit 410 verglichen, um zwei übereinstimmende Ergebnisse zu erzeugen. Die zwei übereinstimmenden Ergebnisse werden dann genutzt, um das Vergleichsergebnis 433 für das einheitliche Muster 423 zu erzeugen. Das Vergleichsergebnis 433 weist darauf hin, ob eine einheitliche Lade-Instruktion zum Lesen von Daten von dem Teilsatz von parallelen Threads 420 basierend auf dem einheitlichen Muster 423 genutzt werden kann. In einem Ausführungsbeispiel kann das einheitliche Muster 423 für LD.U.128 sein, bei dem jeder Thread die Bandbreite hat, 32-Bit-Daten zurückzugeben, was einem Viertel der erforderlichen Daten entspricht, wenn 128-Bit-Befehle verarbeitet werden. Zusätzliche einheitliche Muster können definiert werden, welche die Threads in ein Warp andersartig für einen Vergleich der individuellen Thread-Speicheradressen gruppieren.
  • 5 zeigt ein Flussdiagramm von Verfahrensschritten zum Verarbeiten einer Lade-Instruktion entsprechend einem Ausführungsbeispiel der vorliegenden Erfindung. Obwohl die Verfahrensschritte im Kontext mit dem System der 1, 2, 3A, 3B und 3C beschrieben sind, wird der Fachmann verstehen, dass irgendein System, welches konfiguriert ist, um die Verfahrensschritte in irgendeiner Reihenfolge auszuführen, nicht über den Umfang der Erfindung hinausgeht.
  • Das Verfahren beginnt bei Schritt 505, bei dem die Adress-Erzeugungseinheit 405 eine Lade-Instruktionen inklusive Adressen für mindestens einen Teil eines Warp und eine entsprechende aktive Maske für den Warp empfängt. Bei Schritt 510 führt die Adress-Erzeugungseinheit 405 einer Adressberechnungs-Task durch, um individuelle Speicheradressen für jeden parallelen Thread zu erzeugen. Bei Schritt 515 stellt die einheitliche Ladeeinheit 410 fest, ob die Lade-Instruktionen als eine einheitliche Lade-Instruktion spezifiziert ist, d. h., ob ein „Einheitlichkeits„-Hinweis in der Instruktion enthalten ist. Falls ein „Einheitlichkeits„-Hinweis nicht in der Lade-Instruktion enthalten ist, führt die nicht-einheitliche Ladeeinheit 415 bei Schritt 530 den Zugriff als eine nicht-einheitlicher Lade-Instruktion aus.
  • Anderenfalls identifiziert die einheitliche Ladeeinheit 410 Teilsätze von parallelen Threads innerhalb des Warp bei Schritt 422. Bei Schritt 524 vergleicht die einheitliche Ladeeinheit 410 die individuellen Speicheradressen, die einem oder mehreren der Teilsätze der parallelen Threads zugeordnet sind mit einem oder mehreren einheitlichen Mustern, um ein Vergleichsergebnis für jedes einheitliche Muster zu erzeugen. Die aktive Maske für den Warp wird auch durch die einheitliche Ladeeinheit 410 genutzt, so dass nicht-aktive Threads bei einem Abgleich als übereinstimmend mit einer individuellen Speicheradresse berücksichtigt werden. Die individuellen Speicheradressen werden nicht mit einheitlichen Mustern, welche nicht aktiviert sind, auf Übereinstimmung geprüft. Bei Schritt 528 stellt die einheitliche Ladeeinheit 410 fest, ob das/die Vergleichsergebnis(se) darauf hindeuten, dass die Threads in dem Teilsatz der parallelen Threads mit mindestens einem einheitlichen Muster der Speicheradressen übereinstimmen, welche eine erste Speicheradressen aufweist.
  • Wenn die einheitliche Ladeeinheit 410 feststellt, dass das Vergleichsergebnis darauf hinweist, dass jeder Teilsatzes der parallelen Threads nicht mit mindestens einem einheitlichen Muster der Speicheradressen übereinstimmt, verarbeitet die nicht-einheitliche Ladeeinheit 415 die Lade-Instruktion als eine nicht-einheitliche Lade-Instruktionen bei Schritt 530. Anderenfalls überträgt das LSU-Array 375 bei Schritt 535 einen Leseaufruf inklusive einer ersten Speicheradresse und andere eindeutige Speicheradressen für den Teilsatz der parallelen Threads an den Speicher-und-Cache-Interconnect 380, um Daten für den Teilsatz der parallelen Threads aufzurufen, um den Zugriff für den Teilsatz der parallelen Threads als eine einheitliche Lade-Instruktion zu verarbeiten.
  • Ein Vorteil des offenbarten Verfahrens ist es, dass mehrere Threads, welche ein Lesen der gleichen Speicheradresse anfordern, nur einen einzigen Speicherlesezugriff ausführen, wodurch Speicherbandbreite eingespart wird, um den Aufruf zu übertragen, und um Daten zu empfangen. Bedingt dadurch, dass ein einheitliches Laden durch das LSU-Array 375 basierend auf einem oder mehreren einheitlichen Mustern erkannt wird, hat der Compiler darüber hinaus die Flexibilität, dass eine Lade-Instruktionen als einheitlich gekennzeichnet wird, auch wenn der Compiler nicht garantieren kann, dass jeder Threads in der Threads-Gruppe während der Ausführung auf die gleiche Speicheradresse zugreifen wird. Das einheitliche Muster kann basierend auf der Verbindung (oder Routing), welche durch den Speicher-und-Cache-Interconnect 380 zwischen dem LSU-Array 375 und dem gemeinsam genutzten Speicher 306 und dem L1-Cache 320 definiert werden.
  • Ein Ausführungsbeispiel der Erfindung kann als ein Programmprodukt zur Nutzung in einem Computer implementiert sein. Das/die Programm(e) des Programmproduktes definiert Funktionen des Ausführungsbeispiels (inklusive des hier beschriebenen Verfahrens) und kann in einer Vielzahl von Computerlesbaren Speichermedien enthalten sein. Beispielhafte Computer-lesbarer Speichermedien umfassen, sind aber nicht darauf beschränkt, (i) nicht beschreibbaren Speichermedien (read-only Speichervorrichtungen innerhalb eines Computers wie Compact Disc Read Only Memory (CD-ROM) Disks, die von einem CD-ROM-Laufwerk lesbar sind, Flash-Speicher, Read-only-Speicher(ROM)-Chips oder jeder Art von nicht-flüchtigem Halbleiterfestkörperspeicher) auf welchem Information permanent gespeichert ist; und (ii) beschreibbare Speichermedien (Floppy-Disks in einem Diskettenlaufwerk oder ein Festplattenlaufwerk oder jede andere Art von Festkörper-Halbleiterspeicher mit Wahlfreiem Zugriff).
  • Die Erfindung wurde oben mit Bezug auf spezifische Ausführungsbeispiele beschrieben. Der Fachmann wird allerdings verstehen, dass verschiedene Modifikationen und Änderungen gemacht werden können ohne von der allgemeine Ideen und dem Umfang der Erfindung, wie sie auch in den folgenden Ansprüchen beschrieben ist, abzuweichen. Die vorangegangene Beschreibung und die Zeichnungen sind dementsprechend als beispielhaft und nicht im einschränkenden Sinne zu verstehen.

Claims (10)

  1. Ein Verfahren zum Abrufen von Speicherdaten, die einer Lade-Instruktion zugeordnet ist, wobei das Verfahren aufweist: – Empfangen einer ersten Lade-Instruktion zur parallelen Ausführung durch jeden Thread in einer Thread-Gruppe, wobei die erste Lade-Instruktion eine individuelle Speicheradresse für jeden entsprechenden Thread in der Thread-Gruppe spezifiziert; – Erkennen eines Teilsatzes von parallelen Threads, welch nur einen Teil der Threads der Thread-Gruppe aufweist; – Vergleichen der individuellen Speicheradresse inklusive einer ersten Speicheradresse, die dem Anteil der Threads, die in dem Teilsatz der parallelen Threads enthalten ist, zugeordnet ist, basierend auf einem einheitlichen Muster, um ein Vergleichsergebnis zu erzeugen; – Feststellen, dass das Vergleichsergebnis darauf hinweist, dass die individuelle Speicheradresse, die dem Teilsatz der parallelen Threads mit dem einheitlichen Muster entspricht, übereinstimmt; und – Übertragen einer Leseaufforderung an den Speicher, um Daten abzurufen, die an der ersten Speicheradresse gespeichert sind.
  2. Ein Rechnersubsystem, welche aufweist: – eine einheitliche Ladeeinheit, die angepasst ist zum: – Empfangen einer ersten Lade-Instruktion zur parallelen Ausführung durch jeden Thread in einer Thread-Gruppe, wobei die erste Lade-Instruktion eine individuelle Speicheradresse für jeden entsprechenden Thread in der Thread-Gruppe spezifiziert; – Erkennen eines Teilsatzes von parallelen Threads, welcher nur einen Teil der Threads der Thread-Gruppe aufweist; – Vergleichen der individuellen Speicheradresse inklusive einer ersten Speicheradresse, die dem Anteil der Threads, die in dem Teilsatz der parallelen Thread enthalten ist, zugeordnet ist, basierend auf einem einheitlichen Muster, um ein Vergleichsergebnis zu erzeugen; – Feststellen, dass das Vergleichsergebnis darauf hinweist, dass die individuelle Speicheradresse, die dem Teilsatz der parallelen Threads mit dem einheitlichen Muster entspricht, übereinstimmt; und – eine Lade-/Speicher-Einheit, die zwischen der einheitlichen Ladeeinheit und einem Speicher gekoppelt ist, und die konfiguriert ist, um eine Leseaufforderung an den Speicher zu übertragen, um Daten abzurufen, die an der ersten Speicheradresse gespeichert sind.
  3. Das Rechnersubsystem gemäß Anspruch 2, bei dem das Vergleichsergebnis einen Hinweis darauf liefert, dass mindestens zwei Threads innerhalb des Teilsatzes der parallelen Threads der ersten Speicheradresse zugeordnet sind.
  4. Das Rechnersubsystem gemäß Anspruch 2, bei dem die Vergleichseinheit einen Hinweis darauf liefert, dass mindestens zwei Threads innerhalb des Teilsatzes der parallelen Threads einer zweiten Speicheradresse zugeordnet sind, und dass der Leseaufruf die erste Speicheradresse und die zweite Speicheradresse betrifft.
  5. Das Rechnersubsystem gemäß Anspruch 2, bei dem die einheitliche Ladeeinheit konfiguriert ist, um vor einer Feststellung des Teilsatzes der parallelen Thread festzustellen, dass die erste Instruktion einen Hinweis darauf beschreibt, dass die erste Lade-Instruktion und weitere Teilsätze von parallelen Threads als eine einheitliche Lade-Instruktion verarbeitbar ist.
  6. Das Rechnersubsystem gemäß Anspruch 2, bei dem das einheitliche Muster beschreibt, dass die individuelle Speicheradressen, die jedem Paar von benachbarten Threads innerhalb des Teilsatzes parallelen Threads zugeordnet sind, verglichen werden.
  7. Das Rechnersubsystem gemäß Anspruch 2, bei dem das einheitliche Muster beschreibt, dass die individuelle Speicheradressen, die jedem Paar von nicht benachbarten Threads innerhalb des Teilsatzes der parallelen Threads zugeordnet sind, verglichen werden.
  8. Das Rechnersubsystem gemäß Anspruch 2, bei dem die einheitliche Ladeeinheit weiterhin konfiguriert ist, um: – eine aktive Maske für die Thread-Gruppe zu empfangen, wobei die aktive Maske Threads in der Thread-Gruppe bezeichnet, die die erste Lade-Instruktion ausführen sollen; und – Nutzen der aktiven Maske, um ein Vergleichsergebnis zu erzeugen.
  9. Ein Computersystem aufweisend: einen Speicher, der konfiguriert ist um Daten für parallele Thread in Thread-Gruppen zu speichern; und ein Rechnersubsystem aufweisend: eine einheitliche Ladeeinheit, welche konfiguriert ist zum: – Empfangen einer ersten Lade-Instruktion zur parallelen Ausführung durch jeden Thread in einer Thread-Gruppe, wobei die erste Lade-Instruktion eine individuelle Speicheradresse für jeden entsprechenden Thread in der Thread-Gruppe spezifiziert; – Erkennen eines Teilsatzes der parallelen Threads, welche nur einen Teil der Threads der Thread-Gruppe aufweist; – Vergleichen der individuellen Speicheradresse inklusive einer ersten Speicheradresse, die dem Anteil der Threads, die in dem Teilsatz der parallelen Threads enthalten ist, zugeordnet ist, basierend auf einem einheitlichen Muster, um ein Vergleichsergebnis zu erzeugen; – Feststellen, dass das Vergleichsergebnis darauf hinweist, dass die individuelle Speicheradresse, die den Teilsatz der parallelen Threads mit dem einheitlichen Muster entspricht, übereinstimmt; und – eine Lade-/Speichereinheit, die zwischen der einheitlichen Ladeeinheit und einem Speicher gekoppelt ist, und die konfiguriert ist, um eine Leseaufforderung an den Speicher zu übertragen, um Daten abzurufen, die an der ersten Speicheradresse gespeichert sind.
  10. Das Computersystem gemäß Anspruch 9, bei dem das Vergleichsergebnis darauf hinweist, dass mindestens zwei Threads der Teilgruppe der parallelen Threads innerhalb des Teilsatzes der parallelen Threads einer ersten Speicheradresse zugeordnet sind.
DE102013202173A 2012-03-05 2013-02-11 Einheitliche Lade-Verarbeitung für Teilsätze von parallelen Threads Pending DE102013202173A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US13/412,438 US10007527B2 (en) 2012-03-05 2012-03-05 Uniform load processing for parallel thread sub-sets
US13/412,438 2012-03-05

Publications (1)

Publication Number Publication Date
DE102013202173A1 true DE102013202173A1 (de) 2013-09-05

Family

ID=48985205

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102013202173A Pending DE102013202173A1 (de) 2012-03-05 2013-02-11 Einheitliche Lade-Verarbeitung für Teilsätze von parallelen Threads

Country Status (4)

Country Link
US (1) US10007527B2 (de)
CN (1) CN103309702A (de)
DE (1) DE102013202173A1 (de)
TW (1) TW201351277A (de)

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2524063B (en) * 2014-03-13 2020-07-01 Advanced Risc Mach Ltd Data processing apparatus for executing an access instruction for N threads
US10255547B2 (en) * 2014-12-04 2019-04-09 Nvidia Corporation Indirectly accessing sample data to perform multi-convolution operations in a parallel processing system
US9772852B2 (en) * 2015-04-23 2017-09-26 Google Inc. Energy efficient processor core architecture for image processor
US9720691B2 (en) 2015-09-23 2017-08-01 Qualcomm Incorporated Speculative scalarization in vector processing
US10649770B2 (en) * 2017-01-31 2020-05-12 Facebook, Inc. κ-selection using parallel processing
US10325344B2 (en) * 2017-04-17 2019-06-18 Intel Corporation Efficient merging of atomic operations at computing devices
US10489877B2 (en) 2017-04-24 2019-11-26 Intel Corporation Compute optimization mechanism
US10726514B2 (en) 2017-04-28 2020-07-28 Intel Corporation Compute optimizations for low precision machine learning operations
US10691455B2 (en) * 2017-05-23 2020-06-23 Samsung Electronics Co., Ltd Power saving branch modes in hardware
CN107333282B (zh) * 2017-06-05 2021-02-19 惠州Tcl移动通信有限公司 一种基于gpp的5g终端通用平台优化方法及系统
US10474822B2 (en) * 2017-10-08 2019-11-12 Qsigma, Inc. Simultaneous multi-processor (SiMulPro) apparatus, simultaneous transmit and receive (STAR) apparatus, DRAM interface apparatus, and associated methods
US10877757B2 (en) * 2017-11-14 2020-12-29 Nvidia Corporation Binding constants at runtime for improved resource utilization
CN110032407B (zh) 2019-03-08 2020-12-22 创新先进技术有限公司 提升cpu并行性能的方法及装置和电子设备
CN110442462B (zh) 2019-07-16 2020-07-28 阿里巴巴集团控股有限公司 Tee系统中的多线程数据传输方法和装置
CN110399235B (zh) * 2019-07-16 2020-07-28 阿里巴巴集团控股有限公司 Tee系统中的多线程数据传输方法和装置
US10699015B1 (en) 2020-01-10 2020-06-30 Alibaba Group Holding Limited Method and apparatus for data transmission in a tee system
CN111343239B (zh) * 2020-02-10 2022-11-04 中国银联股份有限公司 通信请求处理方法、通信方法、通信请求处理装置以及交易系统
CN114510271B (zh) * 2022-02-09 2023-08-15 海飞科(南京)信息技术有限公司 用于在单指令多线程计算系统中加载数据的方法和装置
TWI802275B (zh) * 2022-02-16 2023-05-11 昱文 李 晶片系統架構
CN117033298A (zh) * 2022-10-21 2023-11-10 上海天数智芯半导体有限公司 一种瓦片处理器、soc芯片以及电子设备

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5854638A (en) 1996-02-02 1998-12-29 Opti Inc. Unified memory architecture with parallel access by host and video controller
KR100324279B1 (ko) 1999-08-24 2002-02-25 서평원 교환기에서 이중화 프로세서 간 메모리 일치 시스템 및 방법
CN100426268C (zh) 2004-08-06 2008-10-15 华为技术有限公司 光模块寻址装置及其方法
US20080244080A1 (en) * 2007-03-29 2008-10-02 James Thomas H Prefetching Based on Streaming Hints
US8056080B2 (en) 2009-08-31 2011-11-08 International Business Machines Corporation Multi-core/thread work-group computation scheduler
US8458440B2 (en) * 2009-09-25 2013-06-04 Nvidia Corporation Deferred complete virtual address computation for local memory space requests
US8271763B2 (en) * 2009-09-25 2012-09-18 Nvidia Corporation Unified addressing and instructions for accessing parallel memory spaces

Also Published As

Publication number Publication date
TW201351277A (zh) 2013-12-16
US10007527B2 (en) 2018-06-26
US20130232322A1 (en) 2013-09-05
CN103309702A (zh) 2013-09-18

Similar Documents

Publication Publication Date Title
DE102013202173A1 (de) Einheitliche Lade-Verarbeitung für Teilsätze von parallelen Threads
DE102013022712B4 (de) Virtuelle Speicherstruktur für Coprozessoren, die Speicherallokationsbegrenzungen haben
DE102013208554B4 (de) Verfahren und System zum Managen verschachtelter Ausführungsströme
DE102013205886A1 (de) Dynamische Bankmodus-Adressierung für Speicherzugriff
DE102018132468A1 (de) Multi-gpu-frame-rendern
DE102012221504B4 (de) Mehrniveau-Anweisung-Zwischenspeicher-Zuvor-Holen
DE102012220267B4 (de) Rechenarbeitsverteilungs - Referenzzähler
DE102013200997A1 (de) Ein blockierungsfreies FIFO
DE102012222394A1 (de) Verfahren und Vorrichtung zum Sammelzwischenspeichern von Quelloperanden
DE102012211670A1 (de) Simultanes Unterbreiten an eine Mehr-Produzenten-Queue mittels mehrerer Threads
DE102012222558B4 (de) Signalisieren, Ordnen und Ausführung von dynamisch erzeugten Aufgaben in einem Verarbeitungs-System
DE102013114072A1 (de) System und Verfahren zum Hardware-Scheduling von indexierten Barrieren
DE102012221502A1 (de) System und Verfahren zum Durchführen von gestalteter-Speicherzugriff-Operationen
DE102013100179A1 (de) Verfahren und System zum Auflösen von Thread-Divergenzen
DE112010003750T5 (de) Hardware für parallele Befehlslistenerzeugung
DE102013202495A1 (de) Verfahren zur Durchführung von interaktivem Debugging auf nicht unterbrechbaren Graphikverarbeitungseinheiten
DE102013208421A1 (de) Sharing einer Grafikverarbeitungseinheit unter vielen Anwendungen
DE102012220029A1 (de) Spekulative Ausführung und Zurücksetzen
DE102009046847A1 (de) Mehrklassen-Daten-Cache-Verfahren
DE102013020968A1 (de) Technik zum Zugreifen auf einen inhaltsadressierbaren Speicher
DE102012222913A1 (de) Verfahren und Apparat zum Planen von Anweisungen unter Benutzung von Zuvor-Dekodieren-Daten
DE102013200991A1 (de) Automatisches abhängige-Aufgabe-Anstoßen
DE112010003758T5 (de) Instruktionen zum Verwalten einer parallelen Cache-Hierarchie
DE102013020966B4 (de) Leistungseffiziente Attribut-Handhabung für Parkettierungs- und Geometrie-Schattierungseinheiten
DE102009039231A1 (de) Einzeldurchgang-Kachelung

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R082 Change of representative

Representative=s name: KRAUS & WEISERT PATENTANWAELTE PARTGMBB, DE

R016 Response to examination communication