DE102018128497A1 - Einheitliche registerdatei zur verbesserten ressourcennutzung - Google Patents

Einheitliche registerdatei zur verbesserten ressourcennutzung Download PDF

Info

Publication number
DE102018128497A1
DE102018128497A1 DE102018128497.7A DE102018128497A DE102018128497A1 DE 102018128497 A1 DE102018128497 A1 DE 102018128497A1 DE 102018128497 A DE102018128497 A DE 102018128497A DE 102018128497 A1 DE102018128497 A1 DE 102018128497A1
Authority
DE
Germany
Prior art keywords
threads
thread
block
group
cohesive
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
DE102018128497.7A
Other languages
English (en)
Inventor
Ajay TIRUMALA
Jack Choquette
Manan Patel
Shirish Gadre
Praveen KAUSHIK
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
Priority claimed from US15/897,092 external-priority patent/US10866806B2/en
Application filed by Nvidia Corp filed Critical Nvidia Corp
Publication of DE102018128497A1 publication Critical patent/DE102018128497A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G06F8/44—Encoding
    • G06F8/443—Optimisation
    • G06F8/4434—Reducing the memory space required by the program code
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G06F8/44—Encoding
    • G06F8/441—Register allocation; Assignment of physical memory space to logical memory space
    • 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/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5066—Algorithms for mapping a plurality of inter-dependent sub-tasks onto a plurality of physical CPUs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/5017—Task decomposition
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G06F8/45—Exploiting coarse grain parallelism in compilation, i.e. parallelism between groups of instructions
    • G06F8/453—Data distribution

Landscapes

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

Abstract

Ein Compiler parst eine Multithread-Anwendung in kohäsive Blöcke von Anweisungen. Kohäsive Blöcke umfassen Anweisungen, die nicht divergieren oder konvergieren. Jeder kohäsive Block ist einem oder mehreren einheitlichen Registern zugeordnet. Wenn ein Satz von Threads die Anweisungen in einem vorgegebenen kohäsiven Block ausführt, kann jeder Thread in dem Satz auf das einheitliche Register unabhängig von den anderen Threads in dem Satz zugreifen. Demgemäß kann das einheitliche Register eine einzige Kopie von Daten seitens aller Threads in dem Satz von Threads speichern, um dadurch Ressourcen zu schonen.

Description

  • HINTERGRUND DER ERFINDUNG
  • Gebiet der Erfindung
  • Ausführungsformen der vorliegenden Erfindung betreffen im Allgemeinen eine Multithread-Verarbeitung und genauer gesagt eine einheitliche Registerdatei zur verbesserten Ressourcennutzung.
  • Beschreibung der Verwandten Technik
  • Ein herkömmlicher Parallelprozessor führt typischerweise mehrere Sätze von Threads parallel aus, um verschiedene Operationen durchzuführen. Der herkömmliche Parallelprozessor umfasst einen Vektorprozessor zum Durchführen von vektororientierten Operationen. Der Vektorprozessor umfasst typischerweise eine Registerdatei, die Daten auf einer Pro-Thread-Grundlage speichert. Die Registerdatei umfasst einen separaten Speicherslot für jeden Thread in einem vorgegebenen Satz von Threads. Für einen bestimmten Thread in dem vorgegebenen Satz von Threads speichert der entsprechende Speicherslot in der Registerdatei Werte, die von dem Thread während der Ausführung verwendet werden. Wenn der vorgegebene Satz von Threads ausgeführt wird, greift jeder Thread in dem vorgegebenen Satz von Threads auf den entsprechenden Speicherslot zu und liest von und/oder schreibt in diesen Speicherslot.
  • Während der Ausführung kann jeder Thread in einem Satz von Threads Operationen an unterschiedlichen Daten durchführen. Demgemäß speichert in einigen Fällen jeder Speicherslot in der Registerdatei unterschiedliche Daten. In bestimmten Situationen können die Threads in einem Satz von Threads jedoch Operationen an mindestens einigen der gleichen Daten durchführen. Demgemäß speichern in diesen Fällen einige oder alle der Speicherslots in der Registerdatei identische Kopien von Daten. Wenn ein Satz von Threads beispielsweise konfiguriert ist, um eine Matrixmultiplikationsoperation durchzuführen, könnte jeder Speicherslot in der Registerdatei eine unterschiedliche Kopie der Basisadresse einer Matrixdatenstruktur speichern, wohin das Ergebnis der Matrixmultiplikationsoperation zu schreiben ist. Während der Ausführung der Matrixmultiplikationsoperation würde ein vorgegebener Thread auf den entsprechenden Datenslot in der Registerdatei zugreifen, um die Kopie der darin gespeicherten Basisadresse zu lesen. Der Thread würde dann einen Abschnitt der Matrixmultiplikationsoperation durchzuführen und das Ergebnis dieser Operation in die Matrixdatenstruktur unter Verwendung der Basisadresse und einen dem Thread zugeordneten Versatz schreiben. Demgemäß würde für einen Satz von 32 Threads die Registerdatei 32 Kopien der gleichen Basisadresse in 32 separate Speicherslots speichern.
  • Während der Ausführung kann jeder Thread in einem Satz von Threads ebenfalls unterschiedliche Operationen abhängig von verschiedenen Faktoren durchführen, die Eingabeparameter, Thread-Indizes und so weiter umfassen. In bestimmten Situationen kann jeder Thread in einem Satz von Threads identische Operationen ausführen. Wenn ein Satz von Threads beispielsweise konfiguriert ist, um die oben erwähnte Matrixmultiplikationsoperation durchzuführen, kann jeder Thread konfiguriert sein, eine Teilungsoperation zwischen zwei konstanten Werten durchzuführen. Während der Ausführung würde jeder Thread die beiden konstanten Werte teilen, um ein Ergebnis zu erzeugen. Das Ergebnis würde dann beim Durchführen eines Abschnitts der Gesamtmatrixmultiplikationsoperation verwendet werden. Demgemäß würde für einen Satz von 32 Threads die gleiche Teilungsoperation 32 Mal durchgeführt werden.
  • Ein Nachteil der obigen Vorgehensweise ist, dass die Registerdatei enden kann, redundante Kopien von Daten zu speichern. Für 32 Threads kann die Registerdatei bisweilen 32 identische Kopien von Daten wieder speichern, die von den 32 Threads verwendet werden. Das Bereitstellen von Speicherplatz für redundante Daten ist inhärent ineffizient und verschwendet unnötigerweise Prozessor-Die-Fläche. Ein weiterer Nachteil der obigen Vorgehensweise ist, dass mehrere Threads enden können, die gleiche Operation durchzuführen, um das gleiche Ergebnis zu erzeugen. Wie oben bemerkt, können in bestimmten Situationen, die einen Satz von 32 Threads beinhalten, alle 32 Threads eine identische Operation durchführen und ein identisches Ergebnis erzeugen. Ein Durchführen der gleichen Operation mehrere Male verschwendet Prozessorzyklen und konsumiert unnötigerweise Leistung.
  • Wie das Vorhergehende veranschaulicht, werden in der Technik wirksamere Techniken zum Ausführen von Threads in Parallelprozessoren benötigt.
  • ZUSAMMENFASSUNG DER VORLIEGENDEN ERFINDUNG
  • Eine Ausführungsform der vorliegenden Erfindung legt ein computerimplementiertes Verfahren zum Ausführen kohäsiver Blöcke von Anweisungen dar, das umfasst: Parsen eines Anwendungsprogramms, um einen ersten kohäsiven Block zu erzeugen, wobei der erste kohäsive Block einen ersten Satz von Anweisungen umfasst, die nicht konvergieren und nicht divergieren, Veranlassen, dass ein erster Thread in einer ersten Gruppe von Threads auf eine erste einheitliche Registerdatei zugreift, um einen ersten Wert zu lesen, während der erste kohäsive Block ausgeführt wird, und Veranlassen, dass ein zweiter Thread in der ersten Gruppe von Threads auf das erste einheitliche Register zugreift, um den ersten Wert zu lesen, während der erste kohäsive Block ausgeführt wird, wobei der zweite Thread auf den ersten Wert mindestens teilweise parallel mit dem Zugreifen des ersten Threads auf den ersten Wert zugreift.
  • Ein Vorteil der hier beschriebenen Vorgehensweise ist, dass lediglich eine Kopie von Eingabedaten seitens aller Threads in einer Gruppe von Threads gespeichert werden muss. Demgemäß können Speicherplatz und Prozessorfläche geschont werden. Die offenbarte Vorgehensweise stellt daher einen technischen Fortschritt gegenüber herkömmlichen Techniken dar, die erfordern, dass separate Kopien der Eingabedaten für jeden unterschiedlichen Thread gespeichert werden. Ein weiterer Vorteil der offenbarten Vorgehensweise ist, dass mehrere Threads keine identischen Operationen durchführen müssen, um identische Ergebnisse zu erzeugen, um dadurch Prozessorzyklen zu schonen und Prozessoreffizienz zu erhöhen. Somit verleiht die hier beschriebene Vorgehensweise einen technischen Vorteil durch Verbessern der Arbeitsweise einer Rechenvorrichtung.
  • Figurenliste
  • Um die Art und Weise anzugeben, in der die oben genannten Merkmale der Erfindung im Detail verstanden werden können, wird eine genauere Beschreibung der Erfindung, die oben kurz zusammengefasst ist, mit Bezug auf Ausführungsformen angegeben, wovon einige in den beigefügten Zeichnungen veranschaulicht sind. Es sei jedoch bemerkt, dass die beigefügten Zeichnungen lediglich typische Ausführungsformen dieser Erfindung veranschaulichen und daher nicht als ihren Schutzbereich beschränkend zu betrachten sind, da die Erfindung andere, gleichermaßen wirksame Ausführungsformen zulassen kann.
    • 1 ist ein Blockdiagramm, das ein Computersystem veranschaulicht, das konfiguriert ist, um einen oder mehrere Aspekte der vorliegenden Erfindung zu implementieren;
    • 2 ist ein Blockdiagramm einer Parallelverarbeitungseinheit, die in dem Parallelverarbeitungssubsystem von 1 enthalten ist, gemäß verschiedener Ausführungsformen der vorliegenden Erfindung;
    • 3A ist ein Blockdiagramm eines allgemeinen Verarbeitungs-Clusters, der in der Parallelverarbeitungseinheit von 2 enthalten ist, gemäß verschiedener Ausführungsformen der vorliegenden Erfindung;
    • 3B ist eine ausführlichere Veranschaulichung des Streaming-Multiprozessors von 3A gemäß verschiedener Ausführungsformen der vorliegenden Erfindung
    • 4 ist eine konzeptionelle Veranschaulichung, wie einheitliche Register Gruppen von Threads vor dem Ausführen kohäsiver Blöcke zugeteilt werden, gemäß verschiedener Ausführungsformen der vorliegenden Erfindung;
    • 5 ist eine Veranschaulichung von beispielhaften kohäsiven Blöcken, die von einer Gruppe von Threads auszuführen sind, gemäß verschiedener Ausführungsformen der vorliegenden Erfindung;
    • 6 ist eine Veranschaulichung von beispielhaften kohäsiven Blöcken, die von einer Gruppe von Threads auszuführen sind, die im Nur-Lese-Modus arbeiten, gemäß verschiedener Ausführungsformen der vorliegenden Erfindung;
    • 7 ist eine Veranschaulichung von beispielhaften kohäsiven Blöcken, die von einer Gruppe von Threads auszuführen sind, die konfiguriert sind, sich miteinander zu synchronisieren, gemäß verschiedener Ausführungsformen der vorliegenden Erfindung; und
    • 8A-8B legen ein Ablaufdiagramm von Verfahrensschritten zum Ausführen kohäsiver Blöcke eines Maschinencodes dar, gemäß verschiedener Ausführungsformen der vorliegenden Erfindung.
  • AUSFÜHRLICHE BESCHREIBUNG
  • In der folgenden Beschreibung werden zahlreiche spezifische Einzelheiten dargelegt, um ein gründlicheres Verständnis der vorliegenden Erfindung bereitzustellen. Jedoch erkennt ein Fachmann auf diesem Gebiet, dass die vorliegende Erfindung ohne eine oder mehrerer dieser spezifischen Einzelheiten praktiziert werden kann.
  • Wie oben bemerkt, implementiert ein herkömmlicher Parallelprozessor eine Registerdatei, die eine identische Kopie von Daten für jeden unterschiedlichen Thread in einer Gruppe von Threads speichert. Ein Bereitstellen von Speicherplatz für diese identischen Kopien ist inhärent ineffizient und verschwendet unnötigerweise Prozessorfläche. Ferner Veranlassen herkömmliche Parallelprozessoren häufig, dass mehrere Threads in einer Gruppe von Threads die gleiche Operation durchführen, um das gleiche Ergebnis zu erzeugen. Ein Durchführen der gleichen Operation mehrere Male verschwendet Prozessorzyklen und konsumiert unnötigerweise ein Übermaß an Leistung.
  • Um sich diesen Ineffizienzen zu widmen, umfasst ein Datenpfadkern eine einheitliche Registerdatei (unified register file; URF), die eine einzige Kopie von Daten speichert, die über alle Threads in einer Gruppe von Threads gemeinsam genutzt werden. Die URF kann ebenfalls eine einzige Kopie des Ergebnisses einer Operation speichern, die jeder Thread in der Thread-Gruppe konfiguriert ist, durchzuführen.
  • Im Betrieb parst ein Compiler ein Anwendungsprogramm, um einen oder mehrere „kohäsive Blöcke“ zu erzeugen, die von einem oder mehreren Sätzen von Threads auszuführen sind. Ein kohäsiver Block (cohesive block; CB) umfasst eine Teilmenge von Anweisungen, die nicht konvergieren oder divergieren. Ein vorgegebener CB spezifiziert ebenfalls ein bestimmtes einheitliches Register (unified register; UR) innerhalb der URF, das konfiguriert ist, um Daten zu speichern, die von einem Satz von Threads zu verwenden sind, die den CB ausführen. Wenn jeder Thread in der Gruppe von Threads eine Operation durchführt, die von einem vorgegebenen Wert abhängt, speichert das UR eine einzige Kopie dieses Werts. Jeder Thread wird mit unabhängigem Zugriff auf die einzige Kopie des Wertes versehen. Wenn jeder Thread in der Gruppe von Threads die gleiche Operation durchführt, um ein einziges Ergebnis zu erzeugen, speichert das UR außerdem eine einzige Kopie des Ergebnisses. Jeder Thread wird mit unabhängigem Zugriff auf die einzige Kopie des Ergebnisses versehen.
  • Ein Vorteil dieser Vorgehensweise ist, dass beliebige zusätzliche Speicherslots, die gewöhnlicherweise redundanten Daten zugeteilt werden, freigegeben werden können, um dadurch Speicherplatz mit größerer Effizienz zu benutzen. Ein weiterer Vorteil dieser Vorgehensweise ist, dass mehrere Threads keine identischen Operationen durchführen müssen, um identische Ergebnisse zu erzeugen, um dadurch Prozessorzyklen zu schonen und Speichereffizienz weiter zu verbessern. Außerdem können, weil jeder Thread mit unabhängigem Zugriff auf die einzige Kopie von Daten versehen ist, die in dem UR gespeichert sind, Anwendungsprogrammierer Programme gemäß gemeinsamen Programmierparadigmen schreiben, die eine Steuerung über einzelne Threads bereitstellen.
  • Systemüberblick
  • 1 ist ein Blockdiagramm, das ein Computersystem 100 veranschaulicht, das konfiguriert ist, um ein oder mehrere Aspekte der vorliegenden Erfindung zu implementieren. Allgemein gesagt, kann das Computersystem 100 jedes System sein, das einen Speicher, eine Parallelverarbeitungseinheit oder eine Graphikverarbeitungseinheit und eine zentrale Verarbeitungseinheit enthalten. Wie gezeigt, enthält das Computersystem 100 jedoch, ohne einschränkend zu sein, eine zentrale Recheneinheit (central processing unit; CPU) 102 und einen Systemspeicher 104, die über eine Speicherbrücke 105 und einen Kommunikationspfad 113 mit einem Parallelverarbeitungssubsystem 112 verbunden sind. Die Speicherbrücke 105 ist ferner mit einer I/O(Eingabe/Ausgabe)-Brücke 107 über einen Kommunikationspfad 106 verbunden, und die I/O-Brücke 107 ist ihrerseits mit einem Schalter 116 verbunden.
  • Im Betrieb ist die I/O-Brücke 107 konfiguriert, um Anwendereingabeinformation von Eingabevorrichtungen 108, wie beispielsweise einer Tastatur oder einer Maus, zu erhalten und die Eingabeinformation an die CPU 102 zur Verarbeitung über den Kommunikationspfad 106 und die Speicherbrücke 105 weiterzuleiten. Der Schalter 116 ist konfiguriert, um Verbindungen zwischen der I/O-Brücke 107 und anderen Komponenten des Computersystems 100, wie beispielsweise einem Netzwerkadapter 118 und verschiedenen Zusatzkarten 120 und 121, bereitzustellen.
  • Wie ebenfalls gezeigt, ist die I/O-Brücke 107 mit einer Systemdiskette 114 verbunden, die konfiguriert sein kann, um Inhalt und Anwendungen sowie Daten zur Verwendung durch die CPU 102 und das Parallelverarbeitungssubsystem 112 zu speichern. Allgemein stellt die Systemdiskette 114 nichtflüchtigen Speicherplatz für Anwendungen und Daten bereit und kann fest installierte oder entfernbare Festplattenlaufwerke, Flash-Speichervorrichtungen und CD-(Kompaktdisketten-Nur-Lese-Speicher), DVD(digital versatile disc)-ROM, Blu-Ray, HD-DVD (hochauflösende DVD) oder andere magnetische, optische oder elektronische Speichervorrichtungen umfassen. Schließlich können, obwohl nicht explizit gezeigt, weitere Komponenten, wie beispielsweise ein universeller serieller Bus oder andere Portverbindungen, Kompaktdisketten-Laufwerke, DVD(digital versatile disc)-Laufwerke, Filmaufzeichnungsvorrichtungen und dergleichen ebenfalls mit der I/O-Brücke 107 verbunden sein.
  • In verschiedenen Ausführungsformen kann die Speicherbrücke 105 ein Nordbrücken-Chip und die I/O-Brücke 107 ein Südbrücken-Chip sein. Des Weiteren können die Kommunikationspfade 106 und 113 sowie andere Kommunikationspfade innerhalb des Computersystems 100 unter Verwendung beliebiger technisch geeigneter Protokolle implementiert werden, einschließlich, ohne einschränkend zu sein, eines beschleunigten Graphikports (accelerated graphic port; AGP), HyperTransport oder anderen im Stand der Technik bekannten Bus- oder Punkt-Zu-Punkt-Kommunikationsprotokollen.
  • In einigen Ausführungsformen enthält das Parallelverarbeitungssubsystem 112 ein Graphiksubsystem, das Pixel an eine Anzeigevorrichtung 110 liefert, die eine beliebige herkömmliche Kathodenstrahlröhre, eine Flüssigkristallanzeige, eine Leuchtdiodenanzeige oder dergleichen sein kann. In derartigen Ausführungsformen umfasst das Parallelverarbeitungssubsystem 112 Schaltungen, die für Graphik- oder Videoverarbeitung optimiert sind, wozu beispielsweise Video-Ausgabeschaltungen gehören. Wie nachfolgend in 2 detaillierter beschrieben, können derartige Schaltungen in einer oder mehreren Parallelverarbeitungseinheiten (parallel processing units; PPUs) aufgenommen sein, die in dem Parallelverarbeitungssubsystem 112 enthalten sind. In anderen Ausführungsformen umfasst das Parallelverarbeitungssubsystem 112 Schaltungen, die für eine Verarbeitung für Allgemeinzwecke und/oder für eine Rechenverarbeitung optimiert sind. Derartige Schaltungen können ihrerseits in einer oder mehreren PPUs aufgenommen sein, die in dem Parallelverarbeitungssubsystem 112 enthalten sind und die konfiguriert sind, derartige Operationen für Allgemeinzwecke und/oder Berechnungen auszuführen. In noch anderen Ausführungsformen kann die eine oder mehrere PPUs, die in dem Parallelverarbeitungssubsystem 112 enthalten sind, konfiguriert sein, um Operationen für eine Graphikverarbeitung, eine Verarbeitung für Allgemeinzwecke und eine Verarbeitung von Berechnungen auszuführen. Der Systemspeicher 104 umfasst mindestens einen Vorrichtungstreiber 103, der konfiguriert ist, um die Verarbeitungsoperationen der einen oder der mehreren PPUs in dem Parallelverarbeitungssubsystem 112 zu verwalten. Der Vorrichtungstreiber 103 kann einen oder mehrere Compiler umfassen, die konfiguriert sind, um anwendungsebene Anweisungen in maschinenebene Anweisungen zu kompilieren, wie nachstehend ausführlicher in Verbindung mit 4 beschrieben.
  • In verschiedenen Ausführungsformen kann das Parallelverarbeitungssubsystem 112 in einem oder mehreren anderen der anderen Elemente von 1 integriert sein, um ein einzelnes System zu bilden. Beispielsweise kann das Parallelverarbeitungssubsystem 112 mit der CPU 102 und anderen Verbindungsschaltungen auf einem einzelnen Chip integriert sein, um ein System auf einem Chip (SoC) zu bilden.
  • Zu beachten ist, dass das hier gezeigte System veranschaulichend ist und dass Variationen und Modifikationen möglich sind. Die Verbindungstopologie, einschließlich der Anzahl und Anordnung von Brücken, der Anzahl an CPUs 102 und der Anzahl an Parallelverarbeitungssubsystemen 112, kann nach Bedarf modifiziert werden. Beispielsweise könnte in einigen Ausführungsformen der Systemspeicher 104 mit der CPU 102 direkt anstatt über die Speicherbrücke 105 verbunden sein, und andere Vorrichtungen würden mit dem Systemspeicher 104 über die Speicherbrücke 105 und die CPU 102 kommunizieren. In anderen alternativen Topologien kann das Parallelverarbeitungssubsystem 112 mit der I/O-Brücke 107 oder direkt mit der CPU 102 anstatt über die Speicherbrücke 105 verbunden sein. In noch anderen Ausführungsformen können die I/O-Brücke 107 und die Speicherbrücke 105 in einem einzelnen Chip integriert sein, anstatt als ein oder mehrere diskrete Bauelemente vorhanden zu sein. Schließlich können in bestimmten Ausführungsformen eine oder mehrere der in 1 gezeigten Komponenten nicht vorhanden sein. Beispielsweise könnte der Schalter 116 weggelassen werden, und der Netzwerkadapter 118 und die Zusatzkarten 120, 121 könnten direkt mit der I/O-Brücke 107 verbunden sein.
  • 2 ist ein Blockdiagramm einer Parallelverarbeitungseinheit (parallel processing unit; PPU) 202, die in dem Parallelverarbeitungssubsystem 112 von 1 umfasst ist, gemäß einer Ausführungsform der vorliegenden Erfindung. Obwohl 2 eine PPU 202 darstellt, wie oben angegeben ist, kann das Parallelverarbeitungssubsystem 112 eine beliebige Anzahl an PPUs 202 umfassen. Wie gezeigt, ist die PPU 202 mit einem lokalen Parallelverarbeitungs(PP)-Speicher 204 gekoppelt. Die PPU 202 und der PP-Speicher 204 können unter Verwendung einer oder mehrerer integrierter Schaltungsvorrichtungen, wie beispielsweise programmierbaren Prozessoren, anwendungsspezifischen integrierten Schaltungen (ASIC) oder Speichervorrichtungen oder in irgendeiner anderen technisch machbaren Art und Weise implementiert sein.
  • In einigen Ausführungsformen umfasst die PPU 202 eine graphische Verarbeitungseinheit (GPU), die konfiguriert sein kann, um eine Graphik-Rendering-Pipeline zu implementieren, um verschiedene Operationen auszuführen, die mit der Erzeugung von Pixeldaten auf der Grundlage von Graphikdaten in Beziehung stehen, die von der CPU 102 und/oder dem Systemspeicher 104 zugeführt werden. Wenn Graphikdaten verarbeitet werden, kann der PP-Speicher 204 als ein Graphikspeicher verwendet werden, der einen oder mehrere herkömmliche Frame-Puffer und bei Bedarf auch ein oder mehrere andere Rendering-Ziele speichert. Unter anderem kann der PP-Speicher 204 verwendet werden, um Pixeldaten zu speichern und zu aktualisieren und endgültige Pixeldaten oder Anzeigeblöcke an die Anzeigevorrichtung 110 zur Anzeige zu leiten. In einigen Ausführungsformen kann die PPU 202 ebenfalls für Allzweckverarbeitung und Rechenoperationen konfiguriert sein.
  • Während des Betriebs ist die CPU 102 der Master-Prozessor des Computersystems 100, der den Betrieb anderer Systemkomponenten steuert und koordiniert. Insbesondere gibt die CPU 102 Befehle aus, die den Betrieb der PPU 202 steuern. In einigen Ausführungsformen schreibt die CPU 102 einen Strom von Befehlen für die PPU 202 in eine Datenstruktur (in 1 oder 2 nicht explizit gezeigt), die im Systemspeicher 104, im PP-Speicher 204 oder an einer anderen Speicherstelle lokalisiert sein kann, auf die sowohl die CPU 102 als auch die PPU 202 zugreifen können. Ein Zeiger auf die Datenstruktur wird in einen Schiebepuffer geschrieben, um die Verarbeitung des Stroms von Befehlen in der Datenstruktur einzuleiten. Die PPU 202 liest Befehlsströme aus dem Schiebepuffer aus und führt dann Befehle asynchron relativ zu der Betriebsweise der CPU 102 aus. In Ausführungsformen, in denen mehrere Schiebepuffer erzeugt werden, können Prioritäten für die Ausführung für jeden Schiebepuffer durch ein Anwendungsprogramm über den Vorrichtungstreiber 103 spezifiziert werden, um die Disponierung der unterschiedlichen Schiebepuffer zu steuern.
  • Wie ebenfalls gezeigt, umfasst die PPU 202 eine I/O(Eingabe/Ausgabe)-Einheit 205, die mit dem Rest des Computersystems 100 über den Kommunikationspfad 113 und die Speicherbrücke 105 kommuniziert. Die I/O-Einheit 205 erzeugt Pakete (oder andere Signale) zur Übertragung auf dem Kommunikationspfad 113 und empfängt ebenfalls alle ankommenden Pakete (oder andere Signale) von dem Kommunikationspfad 113 und leitet die ankommenden Pakete zu geeigneten Komponenten der PPU 202. Beispielsweise können Befehle, die mit Verarbeitungsaufgaben in Bezug stehen, an eine Host-Schnittstelle 206 geleitet werden, während Befehle, die mit Speicheroperationen in Verbindung stehen (beispielsweise Auslesen aus dem und Schreiben in den PP-Speicher 204) an eine Kreuzungseinheit 210 gesendet werden. Die Host-Schnittstelle 206 liest jeden Schiebepuffer aus und überträgt den in dem Schiebepuffer gespeicherten Befehlsstrom an einen Frontbereich 212.
  • Wie zuvor in Verbindung mit 1 erwähnt, kann die Verbindung der PPU 202 mit dem Rest des Computersystems 100 unterschiedlich sein. In einigen Ausführungsformen ist das Parallelverarbeitungssubsystem 112, das mindestens eine PPU 202 umfasst, als eine Zusatzkarte implementiert, die in einen Erweiterungssteckplatz des Computersystems 100 eingesetzt werden kann. In anderen Ausführungsformen kann die PPU 202 auf einem einzelnen Chip mit einer Busbrücke, wie beispielsweise der Speicherbrücke 105 oder der I/O-Brücke 107, integriert sein. In noch anderen Ausführungsformen können einige oder alle der Elemente der PPU 202 zusammen mit der CPU 102 in einer einzelnen integrierten Schaltung oder einem System auf Chip (SoC) enthalten sein.
  • Im Betrieb überträgt der Frontbereich 212 Verarbeitungsaufgaben, die von der Host-Schnittstelle 206 empfangen werden, an eine Arbeitsverteilungseinheit (nicht gezeigt) in der Aufgaben/Arbeits-Einheit 207. Die Arbeitsverteilungseinheit empfängt Zeiger auf Verarbeitungsaufgaben, die als Aufgaben-Metadaten (TMD) codiert und im Speicher gespeichert sind. Die Zeiger auf die TMD sind in einem Befehlsstrom enthalten, der als ein Schiebepuffer gespeichert ist und durch die Frontbereichseinheit 212 von der Host-Schnittstelle 206 empfangen wird. Verarbeitungsaufgaben, die als TMD codiert sein können, umfassen Indizes, die den zu verarbeitenden Daten zugeordnet sind, sowie Zustandsparameter und Befehle, die festlegen, wie die Daten zu verarbeiten sind. Beispielsweise können die Zustandsparameter und die Befehle das Programm festlegen, das an den Daten auszuführen ist. Die Aufgaben/Arbeits-Einheit 207 empfängt Aufgaben von dem Frontbereich 212 und stellt sicher, dass die GPCs 208 in einen gültigen Zustand konfiguriert werden, bevor die von jedem Satz der TMD spezifizierte Verarbeitungsaufgabe eingeleitet wird. Es kann eine Priorität für jeden Satz an TMD spezifiziert werden, die verwendet wird, um die Ausführung der Verarbeitungsaufgaben zu disponieren. Verarbeitungsaufgaben können ferner aus dem Verarbeitungs-Cluster-Array 230 empfangen werden. Optional können die TMD einen Parameter umfassen, der steuert, ob die TMD dem Anfang oder dem Ende einer Liste an Verarbeitungsaufgaben (oder einer Liste aus Zeigern auf die Verarbeitungsaufgaben) hinzugefügt werden, wodurch eine weitere Steuerebene über die Ausführungspriorität bereitgestellt wird.
  • Die PPU 202 implementiert vorteilhafterweise eine hoch parallele Verarbeitungsarchitektur auf der Grundlage eines Verarbeitungs-Cluster-Arrays 230, das einen Satz aus C allgemeinen Verarbeitungs-Clustern (general processing clusters; GPCs) 208 umfasst, wobei C ≥ 1 ist. Jeder GPC 208 ist in der Lage, eine große Anzahl (beispielsweise Hunderte oder Tausende) von Threads gleichzeitig auszuführen, wobei jeder Thread eine Instanz eines Programms ist. In verschiedenen Anwendungen können unterschiedliche GPCs 208 zur Verarbeitung von unterschiedlichen Arten von Programmen oder zum Durchführen unterschiedlicher Arten von Berechnungen zugeteilt werden. Die Zuteilung von GPCs 208 kann abhängig von der Arbeitslast unterschiedlich sein, die sich für jede Art von Programm oder Berechnung ergibt.
  • Eine Speicherschnittstelle 214 umfasst einen Satz aus D Partitionseinheiten 215, wobei D ≥ 1 ist. Jede Partitionseinheit 215 ist mit einem oder mehreren dynamischen Speichern mit wahlfreiem Zugriff (DRAM) 220 verbunden, die in dem PP-Speicher 204 liegen. In einer Ausführungsform ist die Anzahl an Partitionseinheiten 215 gleich der Anzahl an DRAMs 220, und jede Partitionseinheit 215 ist mit einem anderen DRAM 220 verbunden. In anderen Ausführungsformen unterscheidet sich die Anzahl an Partitionseinheiten 215 von der Anzahl an DRAMs 220. Fachleute werden erkennen, dass ein DRAM 220 durch eine beliebige andere technisch geeignete Speichervorrichtung ersetzt werden kann. Im Betrieb können verschiedene Rendering-Ziele, wie beispielsweise Texturzuordnungen und Frame-Puffer, über die DRAMs 220 hinweg gespeichert werden, wodurch es den Partitionseinheiten 215 ermöglicht wird, Abschnitte jedes Rendering-Ziels parallel zu beschreiben, um die verfügbare Bandbreite des PP-Speichers 204 effizient zu nutzen.
  • Ein vorgegebener GPC 208 kann Daten verarbeiten, die in einen oder mehrere der DRAMs 220 in dem PP-Speicher 204 zu schreiben sind. Die Kreuzungseinheit 210 ist konfiguriert, um die Ausgabe jedes GPC 208 an den Eingang einer beliebigen Partitionseinheit 215 oder an einen anderen GPC 208 zur weiteren Verarbeitung zu leiten. Die GPCs 208 kommunizieren mit der Speicherschnittstelle 214 über die Kreuzungseinheit 210, um aus verschiedenen DRAMs 220 zu lesen oder in diese zu schreiben. In einer Ausführungsform weist die Kreuzungseinheit 210 eine Verbindung zu der I/O-Einheit 205 zusätzlich zu einer Verbindung mit dem PP-Speicher 204 über die Speicherschnittstelle 214 auf, wodurch die Verarbeitungskerne in den unterschiedlichen GPCs 208 in die Lage versetzt werden, mit dem Systemspeicher 104 oder mit einem anderen Speicher, der nicht lokal zu der PPU 202 ist, zu kommunizieren. In der Ausführungsform von 2 ist die Kreuzungseinheit 210 direkt mit der I/O-Einheit 205 verbunden. In verschiedenen Ausführungsformen kann die Kreuzungseinheit 210 virtuelle Kanäle verwenden, um Verkehrsströme zwischen den GPCs 208 und den Partitionseinheiten 215 zu trennen.
  • Die GPCs 208 können ihrerseits so programmiert sein, dass sie Verarbeitungsaufgaben ausführen, die mit einer weiten Vielfalt von Anwendungen in Beziehung stehen, einschließlich, ohne einschränkend zu sein, lineare und nicht-lineare Datentransformationen, die Filterung von Video- und/oder Audiodaten, Modellierungsoperationen (beispielsweise die Anwendung physikalischer Gesetze zur Bestimmung von Position, Geschwindigkeit und anderen Attributen von Objekten), Bild-Rendering-Operationen (beispielsweise Programme zur Parkettierung-Schattierung, Vertex-Schattierung, Geometrie-Schattierung und/oder Pixel/Fragment-Schattierung), allgemeine Berechnungsoperationen, usw. Im Betrieb ist die PPU 202 konfiguriert, um Daten von dem Systemspeicher 104 und/oder dem PP-Speicher 204 an eine oder mehrere chipinterne Speichereinheiten zu übertragen, die Daten zu verarbeiten und Ergebnisdaten zurück in den Systemspeicher 104 und/oder den PP-Speicher 204 zu schreiben. Auf die Ergebnisdaten kann dann von anderen Systemkomponenten zugegriffen werden, wozu die CPU 102, eine weitere PPU 202 innerhalb des Parallelverarbeitungssubsystems 112 oder eines weiteren Parallelverarbeitungssubsystems 112 in dem Computersystem 100 gehören.
  • Wie zuvor bemerkt, kann eine beliebige Anzahl von PPUs 202 in einem Parallelverarbeitungssubsystem 112 enthalten sein. Beispielsweise können mehrere PPUs 202 in einer einzelnen Zusatzkarte bereitgestellt werden, oder es können mehrere Zusatzkarten mit dem Kommunikationspfad 113 verbunden werden, oder eine oder mehrere der PPUs 202 können in einem Brückenchip integriert sein. Die PPUs 202 in einem Mehrfach-PPU-System können identisch oder unterschiedlich voneinander sein. Beispielsweise können unterschiedliche PPUs 202 eine unterschiedliche Anzahl an Verarbeitungskernen und/oder unterschiedliche Größen des PP-Speichers 204 aufweisen. In Ausführungsformen, in denen mehrere PPUs 202 vorhanden sind, können diese PPUs parallel betrieben werden, um Daten mit einem höheren Durchsatz zu verarbeiten, als dies mit einer einzelnen PPU 202 möglich wäre. Systeme, in denen eine oder mehrere PPUs 202 umfasst sind, können in einer Vielzahl von Konfigurationen und Formfaktoren implementiert werden, wozu gehören, ohne einschränkend zu sein, Tischrechner, Mobilrechner, handgehaltene Personal-Computer oder andere handgehaltene Vorrichtungen, Server, Arbeitsplatzrechner, Spielekonsolen, eingebettete Systeme und dergleichen.
  • 3A ist ein Blockdiagramm eines GPC 208, der in der PPU 202 von 2 umfasst ist, gemäß einer Ausführungsform der vorliegenden Erfindung. Im Betrieb kann der GPC 208 konfiguriert sein, um eine große Anzahl an Threads parallel auszuführen, um Operationen für Graphik, allgemeine Verarbeitung und/oder Berechnungen durchzuführen. Wie hier verwendet, bezeichnet ein „Thread“ eine Instanz eines bestimmten Programms, das an einem bestimmten Satz an Eingangsdaten ausgeführt wird. In einigen Ausführungsformen werden SIMD(Single Instruction, Multiple Data)-Befehlsausgabetechniken eingesetzt, um eine parallele Ausführung einer großen Anzahl an Threads zu unterstützen, ohne mehrere unabhängige Befehlseinheiten bereitzustellen. In anderen Ausführungsformen werden SIMT(Single Instruction, Multiple Threads)-Techniken verwendet, um die parallele Ausführung einer großen Anzahl an allgemein synchronisierten Threads unter Verwendung einer gemeinsamen Befehlseinheit zu unterstützen, die konfiguriert ist, um Befehle an einen Satz von Verarbeitungseinheiten innerhalb des GPC 208 auszugeben. Anders als ein SIMD-Ausführungsregime, in welchem alle Verarbeitungseinheiten typischerweise identische Befehle ausführen, ermöglicht eine SIMT-Ausführung, dass unterschiedliche Threads leichter effizienten divergenten Ausführungspfaden durch ein vorgegebenes Programm folgen. Fachleute werden erkennen, dass ein SIMD-Verarbeitungsregime eine funktionale Teilmenge eines SIMT-Verarbeitungsregimes darstellt.
  • Der Betrieb des GPC 208 wird über einen Pipeline-Verwalter 305 gesteuert, der Verarbeitungsaufgaben, die von einer Arbeitsverteilungseinheit (nicht gezeigt) in der Aufgaben/Arbeits-Einheit 207 empfangen werden, an einen oder mehrere Datenstrom-Multiprozessoren (SMs) 310 verteilt. Der Pipeline-Verwalter 305 kann ebenfalls konfiguriert sein, um eine Arbeitsverteilungs-Kreuzungseinheit 330 durch Spezifizieren von Zielen für verarbeitete Daten, die von den SM 310 ausgegeben werden, zu steuern.
  • In einer Ausführungsform umfasst der GPC 208 einen Satz M von SMs 310, wobei M ≥ 1 ist. Ferner umfasst jeder SM 310 einen Satz von Funktionsausführungseinheiten (nicht gezeigt), wie beispielsweise Ausführungseinheiten und Lade-SpeicherEinheiten. Die Verarbeitung von Operationen, die für jedwede der Funktionsausführungseinheiten speziell sind, kann als Pipeline betrieben bzw. parallel ausgeführt werden, wodurch es möglich ist, dass ein neuer Befehl zur Ausführung ausgegeben werden kann, bevor die Ausführung eines vorhergehenden Befehls abgeschlossen ist. Es kann eine beliebige Kombination von Funktionsausführungseinheiten in einem vorgegebenen SM 310 bereitgestellt werden. Die Funktionsausführungseinheiten können in verschiedenen Ausführungsformen konfiguriert sein, um eine Vielfalt unterschiedlicher Operationen zu unterstützen, wozu Ganzzahl- und Fließkommaarithmetik (beispielsweise Addition und Multiplikation), Vergleichsoperationen, boolesche Operationen (UND, ODER, EXKLUSIV ODER), Bit-Verschiebung und Berechnung verschiedener algebraischer Funktionen (beispielsweise ebene Interpolation, trigonometrische, exponentielle und logarithmische Funktionen usw.) gehören. Vorteilhafterweise kann die gleiche Funktionsausführungseinheit konfiguriert sein, um unterschiedliche Operationen auszuführen.
  • Im Betrieb ist jeder SM 310 konfiguriert, um eine oder mehrere Threadgruppen zu verarbeiten. Wie hier verwendet, bedeutet eine „Threadgruppe“ oder „Wölbung“ eine Gruppe von Threads, die gleichzeitig das gleiche Programm an unterschiedlichen Eingangsdaten ausführen, wobei einem Thread der Gruppe eine unterschiedliche Ausführungseinheit innerhalb eines SM 310 zugewiesen wird. Eine Threadgruppe kann weniger Threads umfassen als es der Anzahl an Ausführungseinheiten innerhalb des SM 310 entspricht, in welchem Falle einige der Ausführungseinheiten während Zyklen untätig sein können, wenn diese Threadgruppe verarbeitet wird. Eine Threadgruppe kann auch mehr Threads umfassen, als dies der Anzahl an Ausführungseinheiten innerhalb des SM 310 entspricht, wobei sich in diesem Fall die Verarbeitung über aufeinander folgende Taktzyklen erstrecken kann. Da jeder SM 310 bis zu G Threadgruppen nebenläufig unterstützen kann, folgt, dass bis zu G*M Threadgruppen in dem GPC 208 gleichzeitig ausgeführt werden können.
  • Außerdem kann eine Mehrzahl von in Beziehung stehender Threadgruppen gleichzeitig in einem SM 310 aktiv sein (in unterschiedlichen Phasen der Ausführung). Diese Ansammlung an Threadgruppen wird hier als ein „kooperatives Thread-Array“ („CTA“) oder als „Thread-Array“ bezeichnet. Die Größe eines bestimmten CTA ist gleich m*k, wobei k die Anzahl an gleichzeitig ausgeführten Threads in einer Threadgruppe ist, die typischerweise ein ganzzahliges Vielfaches der Anzahl an Ausführungseinheiten innerhalb des SM 310 ist, und m die Anzahl an Threadgruppen ist, die gleichzeitig in dem SM 310 aktiv sind.
  • Obwohl in 3A nicht gezeigt, umfasst jeder SM 310 einen Cache-Speicher der Ebene eins (L1) oder verwendet Platz in einem entsprechenden L1-Cache-Speicher außerhalb des SM 310, um unter anderem Lade- und Speicher-Operationen zu unterstützen, die von den Ausführungseinheiten durchgeführt werden. Jeder SM 310 weist ferner Zugriff auf Cache-Speicher der Ebene zwei (L2) (nicht gezeigt) auf, die gemeinsam von allen GPCs 208 in der PPU 202 verwendet werden. Die L2-Cache-Speicher können verwendet werden, um Daten zwischen Threads auszutauschen. Schließlich können die SMs 310 auch Zugriff auf einen chipexternen „globalen“ Speicher aufweisen, der den PP-Speicher 204 und/oder den Systemspeicher 104 umfassen kann. Ferner ist zu beachten, dass ein beliebiger Speicher außerhalb der PPU 202 als globaler Speicher verwendet werden kann. Wie außerdem in 3A gezeigt ist, kann ein Cache-Speicher der Ebene eins-Punkt-fünf (L1.5) in dem GPC 208 verwendet werden und konfiguriert sein, um aus dem Speicher über die Speicherschnittstelle 214 von den SM 310 angeforderte Daten zu empfangen und zu halten. Derartige Daten können umfassen, ohne einschränkend zu sein, Anweisungen, gleichförmige Daten und konstante Daten. In Ausführungsformen mit mehreren SMs 310 innerhalb des GPC 208 können die SM 310 vorteilhafterweise gemeinsame Befehle und Daten, die in dem L1.5-Cache-Speicher 335 zwischengespeichert sind, gemeinsam nutzen.
  • Jeder GPC 208 kann eine zugeordnete Speicherverwaltungseinheit (MMU) 320 aufweisen, die konfiguriert ist, um virtuelle Adressen auf physikalische Adressen abzubilden. In verschiedenen Ausführungsformen kann die MMU 320 entweder in dem GPC 208 oder in der Speicherschnittstelle 214 liegen. Die MMU 320 umfasst einen Satz aus Seitentabelleneinträgen (PTE), die verwendet werden, um eine virtuelle Adresse in eine physische Adresse einer Kachel oder einer Speicherseite abzubilden und optional einem Cache-Zeilenindex zuzuordnen. Die MMU 320 kann Adressen-Translations-Nebenschaupuffer (TLB) oder Cache-Speicher umfassen, die in den SMs 310 in einem oder mehreren L1-Cache-Speichern oder in dem GPC 208 liegen können.
  • Der GPC 208 kann in Graphik- und Rechenanwendungen konfiguriert sein, so dass jeder SM 310 mit einer Textureinheit 315 zum Durchführen von Texturabbildungsanforderungen, wie beispielsweise der Bestimmung von Texturabtastpositionen, dem Auslesen von Texturdaten und der Filterung von Texturdaten, gekoppelt ist.
  • Im Betrieb sendet jeder SM 310 eine verarbeitete Aufgabe an die Arbeitsverteilungs-Kreuzungseinheit 330, um die verarbeitete Aufgabe einem weiteren GPC 208 zur Weiterverarbeitung bereitzustellen, oder um die verarbeitete Aufgabe in einem L2-Cache-Speicher (nicht gezeigt), dem Parallelverarbeitungsspeicher 204 oder dem Systemspeicher 104 über die Kreuzungseinheit 210 zu speichern. Außerdem ist eine Vor-Rasteroperationen(PreROP)-Einheit 325 konfiguriert, um Daten von dem SM 310 zu empfangen, Daten einer oder mehreren Rasteroperations(ROP)-Einheiten in den Partitionseinheiten 215 zuzuführen, Optimierungen zur Farbmischung durchzuführen, Pixel-Farbdaten zu organisieren und Adressenübersetzungen durchzuführen.
  • Zu beachten ist, dass die hier beschriebene Kernarchitektur veranschaulichend ist und dass Variationen und Modifikationen möglich sind. Unter anderem kann eine beliebige Anzahl an Verarbeitungseinheiten, wie beispielsweise SMs 310, Textureinheiten 315 oder Vor-ROP-Einheiten 325 in dem GPC 208 enthalten sein. Wie ferner oben in Verbindung mit 2 beschrieben, kann die PPU 202 eine beliebige Anzahl an GPCs 208 umfassen, die konfiguriert sind, um funktionsmäßig zueinander ähnlich zu sein, so dass das Ausführungsverhalten nicht davon abhängt, welcher GPC 208 eine bestimmte Verarbeitungsaufgabe erhält. Ferner arbeitet jeder GPC 208 unabhängig von den anderen GPCs 208 in der PPU 202, um Aufgaben für ein oder mehrere Anwendungsprogramme auszuführen. Im Hinblick auf das Vorhergehende erkennen Fachleute, dass die in 1-3A beschriebene Architektur in keiner Weise den Schutzumfang der vorliegenden Erfindung einschränkt.
  • 3B ist eine ausführlichere Veranschaulichung des Streaming-Multiprozessors (SM) von 3A gemäß verschiedener Ausführungsformen der vorliegenden Erfindung. Wie gezeigt, umfasst der SM 310 eine Konvergenzbarriereneinheit (convergence barrier unit; CBU) 340, die mit einem oder mehreren Datenpfadkernen 350 gekoppelt ist. Jeder Datenpfadkern 350 ist stromabwärts mit einer Datenpfadschnittstelle 370 gekoppelt, die ihrerseits mit einem SM-Cache 380 gekoppelt ist. Der SM-Cache 380 könnte beispielsweise der L1.5-Cache 335 von 3A sein.
  • Jeder Datenpfadkern 350 ist konfiguriert, um Anweisungen auszuführen, die Threads zugeordnet sind, die in einer Thread-Gruppe oder Warp enthalten sind. Ein vorgegebener Datenpfadkern 350 umfasst einen Anweisungs-Cache (I-Cache) 352, einen Ebene-Null-Konstant-Cache (L0-Konstant-Cache) 354, eine einheitliche Registerdatei (uniform register file; URF) 356, einen Anweisungsplaner 358, einen Vektordatenpfad (vector data path; VDP) 360, der eine Vektorregisterdatei (vector register file; VRF) 362 umfasst, und einen einheitlichen Datenpfad (unform data path; UDP) 364, der Kollektoren 366 und Math-Einheiten 368 umfasst. Der Anweisungs-Cache 352 zwischenspeichert Anweisungen, die durch Threads in einer oder mehreren Thread-Gruppen auszuführen sind, und/oder anweisungsorientierte Daten. Der LO-Konstant-Cache 354 zwischenspeichert kürzlich verwendete konstante Werte für einen beschleunigten Zugriff. Die URF 356 ist eine gemeinsam genutzte Speicherressource, die konfiguriert ist, um einheitliche Register (uniform registers; URs) zu umfassen, auf die unabhängig von Threads in einer vorgegebenen Thread-Gruppe zugegriffen werden kann. Der Anweisungsplaner 358 plant zwischengespeicherte Anweisungen zur Ausführung. Der Anweisungsplaner 358 kann jeden Thread, der in einer Thread-Gruppe enthalten ist, zur Ausführung unabhängig von anderen Threads in der Thread-Gruppe planen, um dadurch ein gemeinsames Programmierparadigma zu bewahren, wobei Threads als unabhängige Entitäten betrachtet werden.
  • Der VDP 360 umfasst verschiedene Einheiten, die bei der Ausführung von Vektor-orientierten Anweisungen beteiligt sind. Jene Einheiten können Ausführungseinheiten, Lade/Speicher-Einheiten und so weiter umfassen. Die Vektorregisterdatei 362 ist konfiguriert, um Daten zu speichern, die durch Gruppen von Threads verarbeitet werden, die in dem VDP 360 ausgeführt werden. Anweisungen, die über den VDP 360 ausgeführt werden, können dem Wesen nach divergierend sein. Der UDP 364 umfasst verschiedene Einheiten die bei der Ausführung von einheitlichen Anweisungen beteiligt sind, die Kollektoren 366 und Math-Einheiten 368 umfassen. Im Kontext dieser Offenbarung beziehen sich „einheitliche“ Anweisungen auf jene Anweisungen, die im Allgemeinen einem identischen oder ähnlichen Steuerpfad folgen und die gleichen oder eng verwandte Daten verarbeiten. Einheiten in dem UDP 364 können auf die URF 366 während der Ausführung zugreifen.
  • Im Betrieb arbeiten der VDP 360 und der UDP 364 in Verbindung miteinander, um Programmanweisungen auszuführen, die über einen Treiber 103 kompiliert werden. Jene Programmanweisungen können während der Kompilierung in „kohäsive Blöcke“ von Anweisungen geparst werden, die keine Anweisungen umfassen, die divergieren oder rekonvergieren. Andere Programmanweisungen, die Anweisungen umfassen, die divergieren oder rekonvergieren, können diese kohäsiven Blöcke von Anweisungen begrenzen. Der VDP 360 kann divergierende/konvergierende Anweisungen ausführen, während der UDP 364 kohäsive Blöcke von Anweisungen ausführen kann. Jeder kohäsive Block kann einem spezifischen UR in der URF 356 zugeteilt sein. Eine Gruppe von Threads, die konfiguriert sind, um den kohäsiven Block auszuführen, kann auf das zugeteilte UR während der Ausführung zugreifen. Ferner wird jedem Thread in der Gruppe von Threads ein unabhängiger Zugriff auf das UR gestattet.
  • In einer Ausführungsform sammeln, wenn der UDP 364 einen kohäsiven Block ausführt, Kollektoren 366 anfangs Eingangsdaten für diesen kohäsiven Block von dem zugeordneten UR. Die Daten können ebenfalls lokal in einigen Fällen in der URF 356 zwischengespeichert werden. Jeder Kollektor 366 stellt dann die gesammelten Eingangsdaten den Math-Einheiten 368 zur Verfügung. Die Math-Einheiten 368 können dann verschiedene Verarbeitungsoperationen mit den Eingangsdaten seitens der zugeordneten Threads durchführen. Wenn ein bestimmter Thread in der Thread-Gruppe Anweisungen ausführt, die dem kohäsiven Block zugeordnet sind, weist demgemäß jeder derartige Thread einen unabhängigen Zugriff auf die Eingangsdaten auf, die von dem UR gesammelt werden. Diese Vorgehensweise unterscheidet sich von herkömmlichen Techniken, weil der Datenpfadkern 350 lediglich eine einzige Kopie der Eingabedaten innerhalb des UR im Gegensatz zum Speichern mehrerer Kopien (wie von herkömmlichen Techniken verlangt) bewahrt. In einer weiteren Ausführungsform, wenn jeder Thread in der Thread-Gruppe von der gleichen Basisadresse abhängt, kann diese Basisadresse nur einmal berechnet und dann in einem UR gespeichert werden. Dann kann jeder Kollektor 366 diese Basisadresse im Interesse von Threads in der Thread-Gruppe sammeln, um dadurch Verarbeitungszyklen durch Vermeiden redundanter Berechnungen zu verringern. Die Erzeugung und Ausführung von kohäsiven Blöcken unter Verwendung entsprechender URs wird ausführlicher nachstehend in Verbindung mit 4-8B beschrieben.
  • Einheitliche Registerdatei zur effizienten Ausführung von kohäsiven Blöcken
  • 4 ist eine konzeptionelle Veranschaulichung, wie einheitliche Register an Gruppen von Threads vor dem Ausführen kohäsiver Blöcke zugeteilt werden, gemäß verschiedener Ausführungsformen der vorliegenden Erfindung. Wie gezeigt, empfängt ein Treiber 103 anfangs eine Multithread-Anwendung 400 und kompiliert dann diese Anwendung über einen oder mehrere Compiler 410, um einen kompilierten Code 420 zu erzeugen. Die Multithread-Anwendung 400 kann jede technisch machbare Art einer Anwendung sein, die eine Graphikspezifische Multithread-Anwendung oder eine generische Parallelverarbeitungsanwendung umfasst. Die Compiler 410 können eine Hierarchie von Compilern umfassen, wobei ein vorgegebener Compiler in der Hierarchie empfangene Anweisungen in Zwischenanweisungen zur weiteren Kompilierung durch einen nachfolgenden Compiler in der Hierarchie übersetzt. Die Compiler 410 können ebenfalls verschiedene Hardwarespezifische Compiler umfassen, die unterschiedliche Arten von Maschinencodes erzeugen, die spezifischer darunterliegender Prozessorhardware entspricht. In einer Ausführungsform kompiliert ein erster Compiler 410 die Multithread-Anwendung 400, um parallel Thread Ausführung (PTX)Code zu erzeugen, und dann führt ein zweiter Compiler 410 eine just-in-time (JIT) Kompilierung des PTX-Code durch, um einen maschinenspezifischen kompilierten Code 420 zur Laufzeit zu erzeugen. In einer verwandten Ausführungsform kann der zweite Compiler 420 stattdessen maschinenausführbare Binärdateien zur Kompilierungszeit erzeugen. In einer anderen Ausführungsform kann ein oder mehrere zusätzliche Compiler extern zu dem Treiber 103 anfangs die Multithread-Anwendung 400 kompilieren und dann den kompilierten Code an den Treiber 103 vor den oben beschriebenen Kompilierungsschritten übertragen. Fachleute werden verstehen, dass viele Kompilierungsparadigmen angewendet werden können, ohne vom Gesamtumfang der vorliegenden Offenbarung abzuweichen.
  • Während der Kompilierung kennzeichnen de Compiler 410 Abschnitte der Multithread-Anwendung 400 (oder einer kompilierten Herleitung derselben), die divergentes oder rekonvergentes Programmverhalten beschreiben, und andere Abschnitte, die kein divergentes oder rekonvergentes Verhalten beschreiben. Die Compiler 410 erzeugen dann einen kompilierten Code 420, um kohäsive Blöcke (cohesive blocks; CBs) 424 zu umfassen. Die CBs 424 umfassen Anweisungen, die bei der Ausführung nicht konvergieren, divergieren oder rekonvergieren werden. Die CBs 424 können durch andere Anweisungen begrenzt werden, die konvergentes, divergentes oder rekonvergentes Programmverhalten veranlassen.
  • Die Compiler 410 können viele Techniken implementieren, um CBs 424 zu kennzeichnen. In einer Ausführungsform bezeichnen die Compiler 410 anfangs alle Bereiche der Multithread-Anwendung 400 als „einheitliche“ Anweisungen zu enthalten, die potentiell in den CBs 424 enthalten sein können. Dann wenden die Compiler 410 iterativ unterschiedliche Kriterien an, um bestimmte Bereiche als „nicht-einheitliche“ Anweisungen enthaltend zu bezeichnen, die in den CBs 424 nicht enthalten sein können. Diese neu bezeichneten Bereiche begrenzen die CBs 424. Ein vorgegebenes Kriterium könnte beispielsweise angeben, dass, wenn zwei oder mehr Threads unterschiedliche Werte während der Ausführung einer vorgegebenen Teilmenge von Anweisungen schreiben, diese Teilmenge von Anweisungen dann „nicht-einheitlich“ gekennzeichnet werden sollte. Ein anderes Kriterium könnte beispielsweise angeben, dass jedwede Anweisungen, die in einem Block umfasst sind, der einer Synchronisierungsanweisung folgt, „nicht-einheitlich“ gekennzeichnet werden sollte. Die Compiler 410 können jeden technisch machbaren Satz von Kriterien implementieren, um nicht-einheitliche Anweisungen zu kennzeichnen, obgleich diese Kriterien im Allgemeinen dazu dienen, Bereiche von Anweisungen zu kennzeichnen, die konvergieren, divergieren oder rekonvergieren.
  • Der SM 310 gibt verschiedene Gruppen von Threads aus, um die CBs 424 auszuführen. Beispielsweise sind, wie gezeigt, Thread-Gruppen 426(0), 426(1) und 426(2) konfiguriert, um Anweisungen auszuführen, die CBs 424(1), 424(2) bzw. 424(4) zugeordnet sind. Wenn ein vorgegebener CB 424 ausgeführt wird, teilt der UDP 364 (oder eine andere Einheit innerhalb des Datenpfadkerns 330) ein entsprechendes UR 432 innerhalb der URF 356 und initialisiert es. Jeder Thread in der Thread-Gruppe, die den vorgegebenen CB 424 ausführt, kann auf das entsprechende UR 432 zugreifen, um Eingangsdaten zu erhalten, die zum Ausführen des vorgegebenen CB 424 benötigt werden. Ein vorgegebener CB 424 könnte beispielsweise einen Zeiger auf das entsprechende UR 432 umfassen. In dem gezeigten Beispiel führt die Thread-Gruppe 426(0) den CB 424(1) mit in dem UR 432(0) gespeicherten Daten aus. Die Thread-Gruppe 426(1) führt den CB 424(2) ebenso mit in dem UR 432(0) gespeicherten Daten aus. Die Thread-Gruppe 426(2) führt den CB 424(4) mit in dem UR 432(1) gespeicherten Daten aus. Als eine allgemeine Angelegenheit können irgendeine oder mehr Thread-Gruppen 426 versendet werden, um irgendeinen oder mehr CBs 424 unter Verwendung von irgendeinem oder mehr URs 432 auszuführen.
  • Wie erwähnt, kann jeder Thread in einer Thread-Gruppe 426 auf spezifische Daten, die innerhalb des entsprechenden UR 432 gespeichert sind, unabhängig von anderen Threads in der Thread-Gruppe zugreifen. Diese spezifischen Daten können, unter anderem, einen bestimmten Wert oder eine bestimmte Anordnung von Werten umfassen. Weil jeder Thread in einer vorgegebenen Thread-Gruppe auf spezifische Daten in der beschriebenen Art und Weise unabhängig zugreifen kann, ist einen Zuteilung von redundanten Kopien von Daten unnötig, um die Ausführung von CBs 424 zu unterstützen. Das getrennte Durchführen redundanter Operationen für jeden Thread, wie beispielsweise das Berechnen der gleichen Basisadresse für alle Threads in der Gruppe, kann vermieden werden. 5-7 legen beispielhafte Sequenzen von Programmanweisungen dar, die in kohäsive Blöcke geparst wurden.
  • Beispielhafte Sequenzen von Kohäsiven Blöcken
  • Figure 5 ist eine Veranschaulichung von beispielhaften kohäsiven Blöcken, die von einer Gruppe von Threads auszuführen sind, gemäß verschiedener Ausführungsformen der vorliegenden Erfindung. Wie gezeigt, umfasst ein Programm 500 einen Block 510, einen kohäsiven Block 520, sequentielle kohäsive Blöcke 522 und einen Block 530. Wie ebenfalls gezeigt, geht der Programmablauf von Block 510 durch den kohäsiven Block 520 zu Block 530 weiter. Der Programmablauf geht ebenfalls von Block 510 durch kohäsive Blöcke 522(0) und 522(1) zu Block 530 weiter. Die Blöcke 510 und 530 können in einigen Fällen einfach einzelne Anweisungen umfassen.
  • Eine oder mehrere Gruppen von Threads können konfiguriert sein, um das Programm 500 unter Verwendung von Rechenressourcen auszuführen, die im Datenpfadkern 330 enthalten sein können. Außerdem ist eine Gruppe von Threads mit einer aktiven Maske 0x0F konfiguriert, um den kohäsiven Block 520 auszuführen, und eine Gruppe von Threads mit einer aktiven Maske 0xF0 ist konfiguriert, um die kohäsiven Blöcke 522(0) und 522(1) auszuführen. In einer Ausführungsform können Anweisungen, welche die aktive Maske einer vorgegebenen Thread-Gruppe ändern und ebenfalls mit dem gleichen Programmzähler arbeiten, in einem kohäsiven Block zusammen gruppiert werden. Im Allgemeinen werden dann, wenn sich die aktive Maske einer Thread-Gruppe an einer vorgegebenen Grenze ändert, Anweisungen jeweils an einer Seite dieser Grenze in unterschiedliche Blöcke gruppiert.
  • Während der Ausführung des kohäsiven Blocks 520 kann jeder Thread in der zugeordneten Thread-Gruppe unabhängig auf Daten zugreifen, die in einem einheitlichen Register UR1 gespeichert sind. Wenn die Ausführung des kohäsiven Blocks 520 abgeschlossen ist, ist UR1 inaktiv und kann neu initialisiert werden, um sich auf die Ausführung von kohäsiven Blöcken 522 vorzubereiten.
  • Kohäsive Blöcke 522(0) und 522(1) können unterschiedliche Zweige innerhalb des Programms 500 darstellen. Beispielsweise könnte der kohäsive Block 522(0) Anweisungen umfassen, die auszuführen sind, wenn eine erste Bedingung erfüllt ist, während der kohäsive Block 522(1) Anweisungen umfassen könnte, die auszuführen sind, wenn eine zweite Bedingung erfüllt ist. Im Allgemeinen können verwandte kohäsive Blöcke (wie beispielsweise 522(0) und 522(1)) so lange erzeugt werden, wie alle Threads in der Thread-Gruppe sich zusammen verzweigen. Mit anderen Worten führen alle Threads den kohäsiven Block 522(0) aus oder alle Threads führen den kohäsiven Block 522(1) aus.
  • Während der Ausführung des kohäsiven Blocks 522(0) oder 522(1) kann jeder Thread in der zugeordneten Thread-Gruppe ebenfalls unabhängig auf Daten zugreifen, die in dem einheitlichen Register UR1 gespeichert sind. Beispielsweise kann jeder Thread eine vorgegebene Basisadresse von UR1 lesen, um verschiedene Berechnungen durchzuführen. Lediglich eine Kopie der Basisadresse wird benötigt, wie beschrieben. Wenn die Ausführung der kohäsiven Blöcke 522 abgeschlossen ist, ist die Verwendung von UR1 ebenfalls abgeschlossen und UR1 kann anderswo neu zugeteilt werden. Wenn der Programmablauf Block 530 erreicht, veranlasst die BSYNC-Anweisung, dass die CBU 320 die Thread-Gruppe synchronisiert. Die BSYNC-Anweisung kann nicht innerhalb eines kohäsiven Blocks zugelassen werden, weil BSYNC rekonvergentes Thread-Verhalten implementiert. Ein anderes beispielhaftes Programm wird in Verbindung mit 6 dargelegt.
  • 6 ist eine Veranschaulichung von beispielhaften kohäsiven Blöcken, die von einer Gruppe von Threads auszuführen sind, die im Nur-Lese-Modus arbeiten, gemäß verschiedener Ausführungsformen der vorliegenden Erfindung. Wie gezeigt, umfasst ein Programm 600 einen Block 610, einen kohäsiven Block 620, sequentielle kohäsive Blöcke 622, einen Block 630 und einen Block 640. Wie ebenfalls gezeigt, geht der Programmablauf von Block 610 durch den kohäsiven Block 620 zu Block 530. Der Programmablauf geht ebenfalls von Block 610 durch kohäsive Blöcke 622(0) und 622(1) zu Block 630 weiter. Der Programmablauf geht dann von Block 630 zu Block 640 weiter. Eine Thread-Gruppe mit aktiver Maske OxFF ist konfiguriert, um das Programm 600 auszuführen.
  • Während der Ausführung führt die Thread-Gruppe den Block 600 aus, um ein einheitliches Register UR2 mit Daten aufzufüllen. Dann führt die Thread-Gruppe den kohäsiven Block 610 im Nur-Lese-Modus aus, um Daten aus dem UR2 zu lesen. Wenn die Ausführung des kohäsiven Blockes 620 abgeschlossen ist, bleibt das UR2 aktiv. Die Thread-Gruppe führt dann kohäsive Blöcke 622(0) und 622(1) im Nur-Lese-Modus aus, um Daten aus dem UR2 zu lesen. Wenn vollständig, fährt das UR2 fort, aktiv zu bleiben, weil das UR2 unmodifiziert ist. Wenn der Programmablauf Block 630 erreicht, synchronisiert sich die Gruppe von Threads und endet dann beim Ausführen des Blocks 640.
  • Während der Ausführung des Programms 600 muss das UR2 nach jedem kohäsiven Block nicht geleert und/oder neu zugeteilt werden, weil diese kohäsiven Blöcke lediglich Daten von dem UR2 lesen. Daten werden nicht geschrieben, bis das Programm 600 bei Block 630 konvergiert. Aus diesem Grund kann dieses Programmiermuster als ein „konvergentes Schreib“-Muster bezeichnet werden. Wie mit Programm 500 in Verbindung mit 5 oben erwähnt, kann jeder Thread in der Thread-Gruppe, der auf UR2 zugreift, dies unabhängig von anderen Threads in der Gruppe tun. Demgemäß kann das UR2 von anderen Thread-Gruppen erneut verwendet werden, die Ausführen anderen Abschnitte der Programme ausführen. Diese Vorgehensweise kann Speicherpatz schonen und/oder Prozessorzyklen verringern. Insbesondere werden in dem UR2 gespeicherte redundante Kopien von Daten nicht benötigt. Doppelte Verarbeitungsoperationen werden gleichermaßen nicht benötigt, weil Thread-Gruppen, welche die Ergebnisse von derartigen Operationen benötigen, einen einzigen Ergebniswert, der in dem UR2 gespeichert ist, gemeinsam nutzen können.
  • 7 ist eine Veranschaulichung von beispielhaften kohäsiven Blöcken, die von einer Gruppe von Threads auszuführen sind, die konfiguriert sind, um sich miteinander zu synchronisieren, gemäß verschiedener Ausführungsformen der vorliegenden Erfindung. Wie gezeigt, umfasst ein Programm 700 einen Block 710, einen kohäsiven Block 720, sequentielle kohäsive Blöcke 722, einen Block 730, einen Block 740 und kohäsive Blöcke 742, 744 und 746. Wie ebenfalls gezeigt, geht der Programmablauf von Block 710 durch den kohäsiven Block 720 zu Block 730 weiter. Der Programmablauf geht ebenfalls von Block 710 durch kohäsive Blöcke 722(0) und 722(1) zu Block 630 weiter. Der Programmablauf fährt dann von Block 730 zu Block 740 fort. Schließlich teilt sich der Programmablauf und läuft durch kohäsive Blöcke 742, 744 und 746.
  • Eine oder mehrere Thread-Gruppen mit spezifischen aktiven Masken führen den Block 710 und kohäsive Blöcke 720 und 722 aus. Die Thread-Gruppe(en), welche die kohäsiven Blöcken 720 und 722 ausführt(en), weisen unterschiedliche aktive Masken ähnlich zu oben erwähnten Programmen 500 und 600 auf. Ebenfalls, like Programm 600, führt(en) die Thread-Gruppe(s) kohäsive Blöcke 720 und 722 mit dem UR2 auf eine Nur-Lese Art und Weise aus und somit muss das UR2 nicht überlaufen oder gefüllt werden, wenn diese kohäsiven Blöcke fertig sind. Wenn die kohäsiven Blöcke 720 und 722 fertig sind, führt eine Thread-Gruppe zusätzliche Anweisungen aus, die im Block 730 enthalten sind, und führt dann eine Warp-Ebenen-Synchronisierung beim Ausführen des Blöcke 740 durch. In einer Ausführungsform gibt der Block 740 einen spezifischen Satz von Threads an, die nachfolgende Anweisungen ausführen müssen. An diesem Punkt im Programm 700 kann das UR2 neu initialisiert werden. Sobald der Block 740 abgeschlossen ist, werden unterschiedliche Thread-Gruppen verschickt, um kohäsive Blöcke 742, 744 und 746 auszuführen. Diese Thread-Gruppen weisen unterschiedliche aktive Masken auf, obwohl jede kann auf das UR2 zugreifen kann. Das Programm 700 gewährt im Allgemeinen ähnliche Vorteile wie die Programme 500 und 600, weil die Threads in jeder Thread-Gruppe unabhängigen Zugriff auf einzelne Datenwerte aufweisen, die in einheitlichen Registern gespeichert sind, die kohäsiven Blöcken zugeordnet sind.
  • Allgemein bezugnehmend auf 5-7, veranschaulichen die in Verbindung mit diesen Beispielen erläuterten unterschiedlichen Programme, wie kohäsive Blöcke nebeneinander ausgeführt werden, um eine Multithread-Anwendung effizient auszuführen. Weil Threads, die konfiguriert sind, kohäsive Blöcke auszuführen, eine einzige Kopie von Daten gemeinsam nutzen können, die in einem einheitlichen Register gespeichert sind, kann Speicherplatz vorteilhaft geschont werden. Ein zusätzlicher Vorteil des Implementierens eines einheitlichen Registers ist, dass identische Operationen nicht mehrere Male durchgeführt werden müssen, um identische Eingabedaten unterschiedlichen Threads in einer Thread-Gruppe zur Verfügung zu stellen. Stattdessen muss die Operation lediglich einmal durchgeführt werden und das in einem einheitlichen Register gespeicherte Ergebnis ist von jedem Thread in der Thread-Gruppe zugänglich. Diese bestimmte Vorgehensweise kann vorteilhafterweise eine Adressenauflösungsberechnung von vielen zehn Zyklen auf weniger als zehn Zyklen absenken. Die bislang erläuterten Techniken werden ebenfalls auf eine schrittweise Art und Weise in Verbindung mit 8A-8B beschrieben.
  • 8A-8B legen ein Ablaufdiagramm von Verfahrensschritten zum Ausführen von kohäsiven Blöcken von Maschinencode gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung dar. Obwohl die Verfahrensschritte in Verbindung mit dem System von 1-7 beschrieben werden, werden Fachleute verstehen, dass jedes System, das konfiguriert ist, die Verfahrensschritte in einer beliebigen Reihenfolge durchzuführen, innerhalb des Umfangs der vorliegenden Erfindung fällt.
  • Wie in 8A gezeigt, beginnt ein Verfahren 800(A) bei Schritt 802, wo der Vorrichtungstreiber 103 von 1 und 4 einen Anwendungscode empfängt, der einer Multithread-Softwareanwendung, wie beispielsweise der in 4 gezeigten Multithread-Anwendung 400, zugeordnet ist. Bei Schritt 804 parst ein oder mehrere Compiler 410 innerhalb des Vorrichtungstreibers 103 den Anwendungscode, um einen oder mehrere Blöcke von Anweisungen zu kennzeichnen, wobei Threads nicht divergieren oder rekonvergieren. Der(die) Compiler(s) 410 kann/können die Parsing-Operation durchführen, wenn die Multithread-Softwareanwendung in eine Zwischendarstellung kompiliert wird, wenn die Multithread-Anwendung in Maschinencode kompiliert wird und/oder beim Durchführen einer Just-in-Time-Kompilierung, die der Multithread-Anwendung zugeordnet ist. Fachleute werden verstehen, wie divergente und rekonvergente Bereiche von Anweisungen gekennzeichnet werden können. Bei Schritt 806 sammelt(sammeln) der(die) Compiler(s) 410 die gekennzeichneten Blöcke von Anweisungen in einem oder mehreren entsprechenden kohäsiven Blöcken. Bei Schritt 808 trennen die Compiler(s) 410 divergente und konvergente Anweisungen auf. Diese Anweisungen können die bei Schritt 806 gekennzeichneten kohäsiven Blöcke begrenzen. Bei Schritt 810 gibt (geben) Compiler in kohäsive Blöcke geparsten Maschinencode aus. Das Verfahren 800(A) setzt das Verfahren 800(B) in 8B fort.
  • Wie in 8B bei Schritt 812 gezeigt, initiiert der Vorrichtungstreiber 103 die Ausführung eines Maschinencodes, der kohäsive Blöcke umfasst. Elemente innerhalb eines Datenpfadkerns 350 führen im Allgemeinen einiges oder alles des Maschinencodes aus, wenn eine Anweisung von dem Anweisungsplaner 358 ausgegeben wird. Bei Schritt 816 bestimmt der Anweisungsplaner 358, ob ein kohäsiver Block auszuführen ist.
  • Wenn bei Schritt 816 der Anweisungsplaner 358 bestimmt, dass ein kohäsiver Block nicht auszuführen ist, dann geht das Verfahren zu Schritt 818 weiter. Bei Schritt 818 gibt der Anweisungsplaner 358 die Anweisung, die kann divergentes oder konvergentes Verhalten erzeugen kann, an den VDP 360 aus. Der VDP 360 teilt Ressourcen zum Ausführen der Anweisung zu. Das Verfahren geht dann zu Schritt 822 weiter, wo der Anweisungsplaner 358 zu einem anschließenden Block von Anweisungen weitergeht.
  • Wenn bei Schritt 816 der Anweisungsplaner 358 bestimmt, dass ein kohäsiver Block auszuführen ist, dann geht das Verfahren zu Schritt 816 weiter, bei dem der UDP 364 ein erstes einheitliches Register innerhalb der einheitlichen Registerdatei 356 zuteilt und initialisiert. Bei Schritt 820 versendet der Anweisungsplaner 358 eine Gruppe von Threads, um Anweisungen, die in dem kohäsiven Block enthalten sind, mit in dem ersten einheitlichen Register gespeicherten einheitlichen Daten auszuführen. Das Verfahren geht dann zu Schritt 822 weiter, wo der Anweisungsplaner 358 zu einem anschließenden Block von Anweisungen weitergeht. Das Verfahren wird nach dann nach Bedarf bis zum Programmaustritt wiederholt.
  • Der SM 310 im Allgemeinen und der Datenpfadkern 350 insbesondere können spezifische Schritte des Verfahrens 800(B) für eine beliebige Anzahl von unterschiedlichen Blöcken von Anweisungen wiederholt implementieren. Ferner können diese Blöcke parallel oder seriell ausgeführt werden.
  • Zusammengefasst umfasst ein Vektordatenpfad eine einheitliche Registerdatei (URF), die eine einzige Kopie von Daten speichert, die über alle Threads in einer Gruppe von Threads gemeinsam genutzt werden. Die URF kann ebenfalls eine einzige Kopie des Ergebnisses einer Operation speichern, die jeder Thread in der Gruppe von Threads konfiguriert ist, durchzuführen. Wenn die URF bevölkert wird, parst ein Compiler ein Anwendungsprogramm, um einen oder mehrere „kohäsive Blöcke“ zu erzeugen, die durch eine oder mehrere Gruppen von Threads auszuführen sind. Ein kohäsiver Block (CB) umfasst eine Teilmenge von Anweisungen, die nicht konvergieren oder divergieren. Ein vorgegebener CB spezifiziert ebenfalls eine URF, um Daten zu speichern, die von einer Gruppe von Threads zu verwenden sind, die den CB ausführt. Wenn jeder Thread in der Gruppe von Threads eine Operation durchführt, die von einem vorgegebenen Wert abhängt, speichert die URF eine einzige Kopie dieses Werts. Jeder Thread ist mit unabhängigem Zugriff auf die einzige Kopie des Werts versehen. Wenn jeder Thread in die Gruppe von Threads die gleiche Operation durchführt, um ein einziges Ergebnis zu erzeugen, speichert die URF außerdem eine einzige Kopie dieses Ergebnisses. Jeder Thread wird mit unabhängigem Zugriff auf die einzige Kopie des Ergebnisses versehen.
  • Ein Vorteil der hier beschriebenen Vorgehensweise ist, dass lediglich eine Kopie von Eingabedaten seitens aller Threads in einer Gruppe von Threads gespeichert werden muss. Demgemäß können Speicherplatz und Prozessorfläche geschont werden. Die offenbarte Vorgehensweise stellt daher einen technischen Fortschritt gegenüber herkömmlichen Techniken dar, die erfordern, das separate Kopien der Eingabedaten für jeden unterschiedlichen Thread zu speichern sind. Ein weiterer Vorteil der offenbarten Vorgehensweise ist, dass mehrere Threads keine identischen Operationen durchführen müssen, um identische Ergebnisse zu erzeugen, um dadurch Prozessorzyklen zu schonen und Prozessoreffizienz zu erhöhen. Somit verleiht die hier beschriebene Vorgehensweise einen technischen Vorteil durch Verbessern der Arbeitsweise einer Rechenvorrichtung. Außerdem können, weil jeder Thread mit unabhängigem Zugriff auf die einzige Kopie von in der URF gespeicherten Daten versehen wird, können Anwendungsprogrammierer Programme mit detaillierter Steuerung über einzelne Threads schreiben, ohne Gruppierungen höherer Ebene von Threads berücksichtigen zu müssen. Demgemäß können Programmierer, die mit Einzel-Thread-Architekturen vertraut sind, diesen Architekturen zugeordnete Programmierparadigmen bequem auf Multi-Thread-Architekturen anwenden.
  • Beliebige und alle Kombinationen von beliebigen der Anspruchselemente, die in irgendeinem der Ansprüche und/oder irgendwelchen Elementen vorgetragen werden, die in dieser Anwendung auf irgendeine Art und Weise beschriebenen werden, fallen in den in Betracht gezogenen Umfang und Schutz der vorliegenden Offenbarung.
    • 1. Einige Ausführungsformen umfassen ein computerimplementiertes Verfahren zum Ausführen kohäsiver Blöcke von Anweisungen, wobei das Verfahren umfasst: Parsen eines Anwendungsprogramms, um einen ersten kohäsiven Block zu erzeugen, wobei der erste kohäsive Block einen ersten Satz von Anweisungen umfasst, die nicht konvergieren und nicht divergieren, Veranlassen, dass ein erster Thread in einer ersten Gruppe von Threads auf eine erste einheitliche Registerdatei zugreift, um einen ersten Wert zu lesen, während der erste kohäsive Block ausgeführt wird, und Veranlassen, dass ein zweiter Thread in der ersten Gruppe von Threads auf das erste einheitliche Register zugreift, um den ersten Wert zu lesen, während der erste kohäsive Block ausgeführt wird, wobei der zweite Thread auf den ersten Wert mindestens teilweise parallel mit dem Zugreifen des ersten Threads auf den ersten Wert zugreift.
    • 2. Das computerimplementierte Verfahren gemäß Klausel 1, ferner umfassend: Parsen des Anwendungsprogramms, um einen zweiten kohäsiven Block zu erzeugen, wobei der zweite kohäsive Block einen zweiten Satz von Anweisungen umfasst, die nicht konvergieren und nicht divergieren, und Veranlassen, dass ein oder mehrere Threads in einer zweiten Gruppe von Threads auf das erste einheitliche Register zugreifen, um den ersten Wert zu lesen, während der zweite kohäsive Block ausgeführt wird.
    • 3. Das computerimplementierte Verfahren gemäß einem der Klauseln 1 und 2, wobei die erste Gruppe von Threads einer ersten aktiven Maske zugeordnet ist und die zweite Gruppe von Threads einer zweiten aktiven Maske zugeordnet ist, die sich von der ersten aktiven Maske unterscheidet.
    • 4. Das computerimplementierte Verfahren gemäß einem der Klauseln 1, 2 und 3, ferner umfassend: Parsen des Anwendungsprogramms, um einen ersten Block zu erzeugen, wobei der erste Block einen dritten Satz von Anweisungen umfasst, die konvergieren, und Veranlassen, dass sich mindestens ein Thread, der in der ersten Gruppe von Threads enthalten ist, und mindestens ein Thread, der in der zweiten Gruppe von Threads umfasst ist, miteinander als Antwort darauf synchronisieren, dass der dritte Satz von Anweisungen ausgeführt wird.
    • 5. Das computerimplementierte Verfahren gemäß einem der Klauseln 1, 2, 3 und 4, ferner umfassend: Parsen des Anwendungsprogramms, um einen ersten Block zu erzeugen, wobei der erste Block einen dritten Satz von Anweisungen umfasst, die divergieren, und Veranlassen, dass zwei oder mehr andere Gruppen von Threads Anweisungen, die in zwei oder mehr entsprechenden kohäsiven Blöcken enthalten sind, als Antwort darauf ausführen, dass der dritte Satz von Anweisungen ausgeführt wird.
    • 6. Das computerimplementierte Verfahren gemäß einem der Klauseln 1, 2, 3, 4 und 5, ferner umfassend: Parsen des Anwendungsprogramms, um eine erste Operation zu kennzeichnen, die von jedem Thread in der ersten Gruppe von Threads durchzuführen ist, und wenn von einem vorgegebenen Thread durchgeführt, den ersten Wert erzeugt, Veranlassen, dass das erste einheitliche Register eine einzige Kopie des ersten Werts speichert, wobei der erste Thread in der ersten Gruppe von Threads den ersten Wert von dem ersten einheitlichen Register extrahiert, anstatt die erste Operation durchzuführen, und der zweite Thread in der ersten Gruppe von Threads den ersten Wert von dem ersten einheitlichen Register extrahiert, anstatt die erste Operation durchzuführen.
    • 7. Das computerimplementierte Verfahren gemäß einem der Klauseln 1, 2, 3, 4, 5 und 6, wobei das Veranlassen, dass das erste einheitliche Register eine einzige Kopie des ersten Werts speichert, umfasst: Veranlassen, dass ein dritter Thread in der ersten Gruppe von Threads die erste Operation durchzuführt, um einen ersten Wert zu erzeugen, und Veranlassen, dass der dritte Thread den ersten Wert im ersten einheitlichen Register speichert.
    • 8. Das computerimplementierte Verfahren gemäß einem der Klauseln 1, 2, 3, 4, 5, 6 und 7, ferner umfassend: Parsen des Anwendungsprogramms, um einen ersten Block zu erzeugen, wobei der erste Block einen zweiten Satz von Anweisungen umfasst, die konvergieren oder divergieren, und Veranlassen, dass die erste Gruppe von Threads den ersten Block mittels eines ersten Datenpfads ausführt, wobei die erste Gruppe von Threads den ersten kohäsiven Block mittels eines zweiten Datenpfads ausführt.
    • 9. Das computerimplementierte Verfahren gemäß einem der Klauseln 1, 2, 3, 4, 5, 6, 7 und 8, ferner umfassend: Veranlassen, dass ein Planer den ersten Thread plant, um den ersten kohäsiven Block auszuführen, und Veranlassen, dass der Planer den zweiten Thread plant, um den ersten kohäsiven Block auszuführen, wobei der Planer den ersten Thread unabhängig vom Planen des zweiten Threads plant.
    • 10. Einige Ausführungsformen umfassen ein nichttransitorisches computerlesbares Medium, das Programmanweisungen speichert, die, wenn von einem Prozessor ausgeführt, den Prozessor veranlassen, kohäsive Blöcke von Anweisungen durch Durchführen der folgenden Schritte auszuführen: Parsen eines Anwendungsprogramms, um einen ersten kohäsiven Block zu erzeugen, wobei der erste kohäsive Block einen ersten Satz von Anweisungen umfasst, die nicht konvergieren und nicht divergieren, Veranlassen, dass ein erster Thread in einer ersten Gruppe von Threads auf ein erstes einheitliches Register zugreift, um einen ersten Wert während des Ausführens des ersten kohäsiven Blocks zu lesen, und Veranlassen, dass ein zweiter Thread in der ersten Gruppe von Threads auf das erste einheitliche Register zugreift, um den ersten Wert während des Ausführens des ersten kohäsiven Blocks zu lesen, wobei der zweite Thread auf den ersten Wert teilweise parallel mit dem Zugreifen des ersten Threads auf den ersten Wert zugreift.
    • 11. Das nichttransitorische computerlesbare Medium gemäß Klausel 10, ferner umfassend die folgenden Schritte: Parsen des Anwendungsprogramms, um einen zweiten kohäsiven Block zu erzeugen, wobei der zweite kohäsive Block einen zweiten Satz von Anweisungen umfasst, die nicht konvergieren und nicht divergieren, und Veranlassen, dass ein oder mehrere Threads in einer zweiten Gruppe von Threads auf das erste einheitliche Register zugreifen, um den ersten Wert während des Ausführens des zweiten kohäsiven Blocks zu lesen.
    • 12. Das nichttransitorische computerlesbare Medium gemäß einem der Klauseln 10 und 11, ferner umfassend die folgenden Schritte: Parsen des Anwendungsprogramms, um einen ersten Block zu erzeugen, wobei der erste Block einen dritten Satz von Anweisungen umfasst, die konvergieren, und Veranlassen, dass sich mindestens ein Thread, der in der ersten Gruppe von Threads enthalten ist, und mindestens ein Thread, der in der zweite Gruppe von Threads enthalten ist, als Antwort darauf miteinander synchronisieren, dass der dritte Satz von Anweisungen ausgeführt wird.
    • 13. Das nichttransitorische computerlesbare Medium gemäß einem der Klauseln 10, 11 und 12, ferner umfassend die folgenden Schritte: Parsen des Anwendungsprogramms, um einen ersten Block zu erzeugen, wobei der erste Block einen dritten Satz von Anweisungen umfasst, die divergieren, und Veranlassen, dass zwei oder mehr andere Gruppen von Threads Anweisungen, die in zwei oder mehr entsprechenden kohäsiven Blöcken enthalten sind, als Antwort darauf ausführen, dass der dritte Satz von Anweisungen ausgeführt wird.
    • 14. Das nichttransitorische computerlesbare Medium gemäß einem der Klauseln 10, 11, 12 und 13, ferner umfassend die folgenden Schritte: Parsen des Anwendungsprogramms, um eine erste Operation zu kennzeichnen, die von jedem Thread in der ersten Gruppe von Threads durchzuführen ist, und wenn von einem vorgegebenen Thread durchgeführt, den ersten Wert erzeugt, Veranlassen, dass das erste einheitliche Register, eine einzige Kopie des ersten Werts speichert, wobei der erste Thread in der ersten Gruppe von Threads den ersten Wert von dem ersten einheitlichen Register extrahiert, anstatt die ersten Operation durchzuführen, und der zweite Thread in der ersten Gruppe von Threads den ersten Wert von dem ersten einheitlichen Register extrahiert, anstatt die erste Operation durchzuführen, und wobei ein dritter Thread in der ersten Gruppe von Threads die erste Operation durchführt, um den ersten Wert zu erzeugen und den ersten Wert in dem ersten einheitlichen Register zu speichern.
    • 15. Das nichttransitorische computerlesbare Medium gemäß einem der Klauseln 10, 11, 12, 13 und 14, wobei die erste Gruppe von Threads den ersten kohäsiven Block mittels eines ersten Datenpfads ausführt, der das erste einheitliche Register umfasst.
    • 16. Das nichttransitorische computerlesbare Medium gemäß einem der Klauseln 10, 11, 12, 13, 14 und 15, ferner umfassend den Schritt eines Veranlassens, dass eine dritte Gruppe von Threads, um einen ersten Block von Anweisungen mittels eines zweiten Datenpfads auszuführen, der eine erste Vektorregisterdatei umfasst, wobei der erste Block einen zweiten Satz von Anweisungen umfasst, die konvergieren oder divergieren.
    • 17. Das nichttransitorische computerlesbare Medium gemäß einem der Klauseln 10, 11, 12, 13, 14, 15 und 16, wobei der erste kohäsive Block einen ersten Zeiger auf das erste einheitliche Register umfasst.
    • 18. Einige Ausführungsformen umfassen ein System zum Ausführen kohäsiver Blöcke von Anweisungen, umfassend: einen Speicher, der einen Vorrichtungstreiber speichert, und einen Prozessor der, wenn der Vorrichtungstreiber ausführt, konfiguriert ist, um die folgenden Schritte auszuführen: Parsen eines Anwendungsprogramms, um einen ersten kohäsiven Block zu erzeugen, wobei der erste kohäsive Block einen ersten Satz von Anweisungen umfasst, die nicht konvergieren und nicht divergieren, Veranlassen, dass ein erster Thread in einer ersten Gruppe von Threads auf ein erstes einheitliches Register zugreift, um einen ersten Wert während des Ausführens des ersten kohäsiven Blocks zu lesen, und Veranlassen, dass ein zweiter Thread in der ersten Gruppe von Threads auf das erste einheitliche Register zugreift, um den ersten Wert während des Ausführens des ersten kohäsiven Blocks zu lesen, wobei der zweite Thread auf den ersten Wert mindestens teilweise parallel mit dem Zugreifen des ersten Threads auf den ersten Wert zugreift.
    • 19. Das System gemäß Klausel 18, ferner umfassend: einen Datenpfadkern mit: einem Vektordatenpfad, der Anweisungen ausführt, die divergieren oder konvergieren, einem einheitlichen Datenpfad, der Anweisungen ausführt, die nicht divergieren und nicht konvergieren, und eine einheitliche Registerdatei, die mit dem Vektordatenpfad und dem einheitlichen Datenpfad gekoppelt ist und die das erste einheitliche Register umfasst.
    • 20. Das System gemäß einem der Klauseln 18 und 19, wobei der einheitliche Datenpfad umfasst: mehrere Kollektoren, die den ersten Wert des ersten einheitlichen Registers lesen, und mehrere Math-Operatoren, die eine oder mehreren Operationen mit dem ersten Wert durchführen.
  • Die Beschreibungen der verschiedenen Ausführungsformen wurden der Veranschaulichung halber vorgestellt, wobei sie jedoch nicht dazu gedacht sind, erschöpfend oder auf die offenbarten Ausführungsformen beschränkt zu sein. Viele Modifikationen und Variationen werden Fachleuten offensichtlich sein, ohne vom Umfang und Wesen der beschriebenen Ausführungsformen abzuweichen. Beispielsweise können die hier beschriebenen verschiedenen Ausführungsformen in jeder Art von Graphikoperation, die konstante Werte beinhaltet, wie beispielsweise Strahlverfolgung, implementiert werden. Die verschiedenen Ausführungsformen können jedoch in jedem Graphiksystem oder jeder Graphikumgebung, in jeder Cloud-Rechenumgebung, in einer oder mehreren Servermaschinen für Spielzwecke, Graphik, Video-Streaming usw. oder in jedem Fahrzeugnavigations-, Infotainment- oder Kombiinstrumentencontroller-System (wie es zum Beispiel in Automobilen gefunden wird) breiter implementiert werden. Die NVIDIA GeForce NOW® ist ein Beispiel eines vernetzten Spieledienstes, der die verschiedenen Ausführungsformen wirksam einsetzen kann, um Leistung und die Gesamtnutzererfahrung zu steigern. Aspekte der vorliegenden Ausführungsformen können als ein System, Verfahren oder Computerprogrammprodukt verkörpert sein. Demgemäß können Aspekte der vorliegenden Offenbarung die Form einer reinen Hardware-Ausführungsform, einer reinen Software-Ausführungsform (einschließlich Firmware, residenter Software, Mikrocode, usw.) oder einer Ausführungsform, die Software- und Hardware-Aspekte kombiniert, annehmen, die hier alle allgemein als „Schaltung“, „Modul“ oder „System“ bezeichnet werden können. Des Weiteren können Aspekte der vorliegenden Offenbarung die Form eines Computerprogrammprodukts annehmen, das in einem oder mehreren computerlesbaren Medium(Medien) verkörpert wird, die darauf verkörperten computerlesbaren Programmcode aufweisen.
  • Jede Kombination aus einem oder mehreren computerlesbaren Medien kann benutzt werden. Das computerlesbare Medium kann ein computerlesbares Signalmedium oder ein computerlesbares Speichermedium sein. Ein computerlesbares Speichermedium kann beispielsweise, jedoch ohne darauf begrenzt zu sein, eine Einrichtung oder eine Vorrichtung eines elektronischen, magnetischen, optischen, elektromagnetischen, Infrarot- oder Halbleiter-Systems oder jede geeignete Kombination des Vorhergehenden sein. Spezifischere Beispiele (eine nicht erschöpfende Liste) des computerlesbaren Speichermediums würde Folgendes umfassen: eine elektrische Verbindung mit einer oder mehreren Leitungen, eine tragbare Computerdiskette, eine Festplatte, einen Direktzugriffsspeicher (RAM), einen Festwertspeicher (ROM), einen löschbaren programmierbaren Festwertspeicher (EPROM oder Flash-Speicher), einen Lichtwellenleiter, einen tragbaren Compactdisk-Festwertspeicher (CD-ROM), eine optische Speichervorrichtung, eine magnetische Speichervorrichtung oder jede geeignete Kombination des Vorhergehenden. Im Kontext dieses Dokuments kann ein computerlesbares Speichermedium jedes materielle Medium sein, das ein Programm zur Verwendung durch oder in Verbindung mit einem Anweisungsausführungssystem, einer Einrichtung oder Vorrichtung umfasst oder speichern kann.
  • Aspekte der vorliegenden Offenbarung werden oben mit Bezug auf Ablaufdiagramme und/oder Blockdiagramme von Verfahren, Einrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der Offenbarung beschrieben. Es versteht sich, dass jeder Block der Ablaufdiagramme und/oder der Blockdiagramme und Kombinationen von Blöcken in den Ablaufdiagrammen und/oder Blockdiagrammen durch Computerprogramm-Anweisungen implementiert werden können. Diese Computerprogramm-Anweisungen können für einen Prozessor eines Allzweckcomputers, Spezialzweckcomputers oder einer sonstigen programmierbaren Datenverarbeitungseinrichtung bereitgestellt werden, um eine Maschine zu erzeugen, so dass die Anweisungen, die über den Prozessor des Computers oder einer sonstigen programmierbaren Datenverarbeitungseinrichtung ausgeführt werden, die Implementierung der in dem Ablaufdiagramm und/oder Blockdiagramm oder Blockdiagramm spezifizierten Funktionen/Handlungen ermöglichen. Derartige Prozessoren können, ohne einschränkend zu sein, Allzweck-Prozessoren, Spezialzweck-Prozessoren, anwendungsspezifische Prozessoren oder feldprogrammierbare Prozessoren sein.
  • Die Ablaufdiagramme und die Blockdiagramme in den Figuren veranschaulichen die Architektur, die Funktionalität und den Betrieb möglicher Implementierungen von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedener Ausführungsformen der vorliegenden Offenbarung. In dieser Hinsicht kann jeder Block in den Ablaufdiagrammen oder Blockdiagrammen ein Modul, ein Segment oder einen Abschnitt eines Codes darstellen, der eine oder mehrere ausführbare Anweisungen zum Implementieren der spezifizierten logischen Funktion(en) umfasst. Es sei ebenfalls bemerkt, dass in einigen alternativen Implementierungen die in dem Block erwähnten Funktionen außerhalb der in den Figuren erwähnten Reihenfolge auftreten können. Beispielsweise können zwei aufeinanderfolgend gezeigte Blöcke tatsächlich im Wesentlichen nebenläufig ausgeführt werden oder die Blöcke können einige Male in umgekehrter Reihenfolge abhängig von der beteiligten Funktionalität ausgeführt werden. Es sei ebenfalls bemerkt, dass jeder Block der Blockdiagramme und/oder der Ablaufdiagramme sowie Kombinationen von Blöcken in den Blockdiagrammen und/oder den Ablaufdiagrammen von Spezialzweck-Hardware-basierten Systemen, welche die spezifizierten Funktionen oder Handlungen oder Kombinationen von Spezialzweck-Hardware und Computeranweisungen durchführen, implementiert werden können.
  • Während das Vorhergehende auf Ausführungsformen der vorliegenden Offenbarung gerichtet ist, können andere und weitere Ausführungsformen der Offenbarung erdacht werden, ohne vom grundlegenden Schutzumfang derselben abzuweichen, wobei der Umfang derselben von den Ansprüchen bestimmt wird, die folgen.

Claims (17)

  1. Computerimplementiertes Verfahren zum Ausführen kohäsiver Blöcke von Anweisungen, wobei das Verfahren umfasst: Parsen eines Anwendungsprogramms, um einen ersten kohäsiven Block zu erzeugen, wobei der erste kohäsive Block einen ersten Satz von Anweisungen umfasst, die nicht konvergieren und nicht divergieren; Veranlassen, dass ein erster Thread in einer ersten Gruppe von Threads auf eine erste einheitliche Registerdatei zugreift, um einen ersten Wert zu lesen, während der erste kohäsive Block ausgeführt wird; und Veranlassen, dass ein zweiter Thread in der ersten Gruppe von Threads auf das erste einheitliche Register zugreift, um den ersten Wert zu lesen, während der erste kohäsive Block ausgeführt wird, wobei der zweite Thread auf den ersten Wert mindestens teilweise parallel mit dem Zugreifen des ersten Threads auf den ersten Wert zugreift.
  2. Computerimplementiertes Verfahren gemäß Anspruch 1, ferner umfassend: Parsen des Anwendungsprogramms, um einen zweiten kohäsiven Block zu erzeugen, wobei der zweite kohäsive Block einen zweiten Satz von Anweisungen umfasst, die nicht konvergieren und nicht divergieren; und Veranlassen, dass ein oder mehrere Threads in einer zweiten Gruppe von Threads auf das erste einheitliche Register zugreifen, um den ersten Wert zu lesen, während der zweite kohäsive Block ausgeführt wird.
  3. Computerimplementiertes Verfahren gemäß Anspruch 2, wobei die erste Gruppe von Threads einer ersten aktiven Maske zugeordnet ist und die zweite Gruppe von Threads einer zweiten aktiven Maske zugeordnet ist, die sich von der ersten aktiven Maske unterscheidet.
  4. Computerimplementiertes Verfahren gemäß Anspruch 2 oder 3, ferner umfassend: Parsen des Anwendungsprogramms, um einen ersten Block zu erzeugen, wobei der erste Block einen dritten Satz von Anweisungen umfasst, die konvergieren; und Veranlassen, dass sich mindestens ein Thread, der in der ersten Gruppe von Threads enthalten ist, und mindestens ein Thread, der in der zweiten Gruppe von Threads umfasst ist, miteinander als Antwort darauf synchronisieren, dass der dritte Satz von Anweisungen ausgeführt wird.
  5. Computerimplementiertes Verfahren gemäß einem der Ansprüche 2 bis 4, ferner umfassend: Parsen des Anwendungsprogramms, um einen ersten Block zu erzeugen, wobei der erste Block einen dritten Satz von Anweisungen umfasst, die divergieren; und Veranlassen, dass zwei oder mehr andere Gruppen von Threads Anweisungen, die in zwei oder mehr entsprechenden kohäsiven Blöcken enthalten sind, als Antwort darauf ausführen, dass der dritte Satz von Anweisungen ausgeführt wird.
  6. Computerimplementiertes Verfahren gemäß einem der vorangehenden Ansprüche, ferner umfassend: Parsen des Anwendungsprogramms, um eine erste Operation zu kennzeichnen, die von jedem Thread in der ersten Gruppe von Threads durchzuführen ist, und wenn von einem vorgegebenen Thread durchgeführt, den ersten Wert erzeugt; Veranlassen, dass das erste einheitliche Register eine einzige Kopie des ersten Werts speichert, wobei der erste Thread in der ersten Gruppe von Threads den ersten Wert von dem ersten einheitlichen Register extrahiert, anstatt die erste Operation durchzuführen, und der zweite Thread in der ersten Gruppe von Threads den ersten Wert von dem ersten einheitlichen Register extrahiert, anstatt die erste Operation durchzuführen.
  7. Computerimplementiertes Verfahren gemäß Anspruch 6, wobei das Veranlassen, dass das erste einheitliche Register eine einzige Kopie des ersten Werts speichert, umfasst: Veranlassen, dass ein dritter Thread in der ersten Gruppe von Threads die erste Operation durchzuführt, um einen ersten Wert zu erzeugen; und Veranlassen, dass der dritte Thread den ersten Wert im ersten einheitlichen Register speichert.
  8. Computerimplementiertes Verfahren gemäß einem der vorangehenden Ansprüche, ferner umfassend: Parsen des Anwendungsprogramms, um einen ersten Block zu erzeugen, wobei der erste Block einen zweiten Satz von Anweisungen umfasst, die konvergieren oder divergieren; und Veranlassen, dass die erste Gruppe von Threads den ersten Block mittels eines ersten Datenpfads ausführt, wobei die erste Gruppe von Threads den ersten kohäsiven Block mittels eines zweiten Datenpfads ausführt.
  9. Computerimplementiertes Verfahren gemäß einem der vorangehenden Ansprüche, ferner umfassend: Veranlassen, dass ein Planer den ersten Thread plant, um den ersten kohäsiven Block auszuführen; und Veranlassen, dass der Planer den zweiten Thread plant, um den ersten kohäsiven Block auszuführen, wobei der Planer den ersten Thread unabhängig vom Planen des zweiten Threads plant.
  10. Nichttransitorisches computerlesbares Medium, das Programmanweisungen speichert, die, wenn von einem Prozessor ausgeführt, den Prozessor veranlassen, kohäsive Blöcke von Anweisungen durch Durchführen der Schritte eines Verfahrens gemäß einem der Ansprüche 1 bis 9 auszuführen.
  11. Nichttransitorisches computerlesbares Medium gemäß Anspruch 10, ferner umfassend die folgenden Schritte: Parsen des Anwendungsprogramms, um eine erste Operation zu kennzeichnen, die von jedem Thread in der ersten Gruppe von Threads durchzuführen ist, und wenn von einem vorgegebenen Thread durchgeführt, den ersten Wert erzeugt, Veranlassen, dass das erste einheitliche Register, eine einzige Kopie des ersten Werts speichert, wobei der erste Thread in der ersten Gruppe von Threads den ersten Wert von dem ersten einheitlichen Register extrahiert, anstatt die ersten Operation durchzuführen, und der zweite Thread in der ersten Gruppe von Threads den ersten Wert von dem ersten einheitlichen Register extrahiert, anstatt die erste Operation durchzuführen, und wobei ein dritter Thread in der ersten Gruppe von Threads die erste Operation durchführt, um den ersten Wert zu erzeugen und den ersten Wert in dem ersten einheitlichen Register zu speichern.
  12. Nichttransitorisches computerlesbares Medium gemäß Anspruch 10 oder 11, wobei die erste Gruppe von Threads den ersten kohäsiven Block mittels eines ersten Datenpfads ausführt, der das erste einheitliche Register umfasst.
  13. Nichttransitorisches computerlesbares Medium gemäß Ansprüche 12, ferner umfassend den Schritt eines Veranlassens, dass eine dritte Gruppe von Threads einen ersten Block von Anweisungen mittels eines zweiten Datenpfads ausführt, der eine erste Vektorregisterdatei umfasst, wobei der erste Block einen zweiten Satz von Anweisungen umfasst, die konvergieren oder divergieren.
  14. Nichttransitorisches computerlesbares Medium gemäß einem der Ansprüche 10 bis 13, wobei der erste kohäsive Block einen ersten Zeiger auf das erste einheitliche Register umfasst.
  15. System zum Ausführen kohäsiver Blöcke von Anweisungen, umfassend: einen Speicher, der einen Vorrichtungstreiber speichert; und einen Prozessor der, wenn der Vorrichtungstreiber ausgeführt wird, konfiguriert ist, um die Schritte eines Verfahrens gemäß einem der Ansprüche 1 bis 9 auszuführen.
  16. Das System gemäß Anspruch 15, ferner umfassend: einen Datenpfadkern mit: einem Vektordatenpfad, der Anweisungen ausführt, die divergieren oder konvergieren, einem einheitlichen Datenpfad, der Anweisungen ausführt, die nicht divergieren und nicht konvergieren, und einer einheitlichen Registerdatei, die mit dem Vektordatenpfad und dem einheitlichen Datenpfad gekoppelt ist und die das erste einheitliche Register umfasst.
  17. System gemäß Anspruch 16, wobei der einheitliche Datenpfad umfasst: mehrere Kollektoren, die den ersten Wert des ersten einheitlichen Registers lesen; und mehrere Math-Operatoren, die eine oder mehreren Operationen mit dem ersten Wert durchführen.
DE102018128497.7A 2017-11-14 2018-11-14 Einheitliche registerdatei zur verbesserten ressourcennutzung Pending DE102018128497A1 (de)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201762586031P 2017-11-14 2017-11-14
US62/586,031 2017-11-14
US15/897,092 2018-02-14
US15/897,092 US10866806B2 (en) 2017-11-14 2018-02-14 Uniform register file for improved resource utilization

Publications (1)

Publication Number Publication Date
DE102018128497A1 true DE102018128497A1 (de) 2019-05-16

Family

ID=66335852

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102018128497.7A Pending DE102018128497A1 (de) 2017-11-14 2018-11-14 Einheitliche registerdatei zur verbesserten ressourcennutzung

Country Status (1)

Country Link
DE (1) DE102018128497A1 (de)

Similar Documents

Publication Publication Date Title
CN110032395B (zh) 用于提高资源利用率的统一寄存器文件
DE102013017640B4 (de) Verteilte gekachelte Zwischenspeicherung
DE102013017509A1 (de) Effiziente Speichervirtualisierung in mehrsträngigen Verarbeitungseinheiten
DE102013017510A1 (de) Effiziente Speichervirtualisierung in mehrsträngigen Verarbeitungseinheiten
DE102013017511A1 (de) Effiziente speichervirtualisierung in mehrsträngigen verarbeitungseinheiten
DE102016122297A1 (de) Mehrfach-Durchlauf-Rendering in einer Bildschirm-Raum-Pipeline
DE102018109538A1 (de) Techniken zum umfassenden Synchronisieren einer Ausführung von Threads
DE102013201178B4 (de) Steuern von Arbeitsverteilung für Verarbeitung von Tasks
DE112010003750T5 (de) Hardware für parallele Befehlslistenerzeugung
DE112012002905T5 (de) Technik zum Kompilieren und Ausführen von Programmen in höheren Programmiersprachen auf heterogenen Computern
DE102013205886A1 (de) Dynamische Bankmodus-Adressierung für Speicherzugriff
DE102013020968A1 (de) Technik zum Zugreifen auf einen inhaltsadressierbaren Speicher
DE102012211670A1 (de) Simultanes Unterbreiten an eine Mehr-Produzenten-Queue mittels mehrerer Threads
DE112013004751T5 (de) Prozessor mit mehreren Kernen, gemeinsam genutzter Kernerweiterungslogik und gemeinsam genutzten Kernerweiterungsnutzungsbefehlen
DE102013224160A1 (de) System, Verfahren und Computer-Programm-Produkt zum Optimieren des Managements von Thread-Stapel-Speicher
DE102013202173A1 (de) Einheitliche Lade-Verarbeitung für Teilsätze von parallelen Threads
DE102013020966B4 (de) Leistungseffiziente Attribut-Handhabung für Parkettierungs- und Geometrie-Schattierungseinheiten
DE102013208554A1 (de) Verfahren und System zum Managen verschachtelter Ausführungsströme
DE102013017639A1 (de) Zwischenspeicherung von adaptiv dimensionierten Cache-Kacheln in einem vereinheitlichen L2-Cache-Speicher mit Oberflächenkomprimierung
DE102020112826A1 (de) Verfahren zur effizienten durchführung von datenreduktionen in parallelverarbeitungseinheiten
DE102013020613A1 (de) Umgehung der Pixel-Schattierung für die grafische Bilderzeugung mit geringer Leistung
DE102013200997A1 (de) Ein blockierungsfreies FIFO
DE102013208421A1 (de) Sharing einer Grafikverarbeitungseinheit unter vielen Anwendungen
DE102013020807A1 (de) Handhabung von nachgeordneten Z-Abdeckungsdaten in Rasteroperationen
DE102013020485A1 (de) Technik zur Ausführung von Speicherzugriffsoperationen über eine Textur-Hardware

Legal Events

Date Code Title Description
R012 Request for examination validly filed