DE102013114072B4 - System und Verfahren zum Hardware-Scheduling von indexierten Barrieren - Google Patents

System und Verfahren zum Hardware-Scheduling von indexierten Barrieren Download PDF

Info

Publication number
DE102013114072B4
DE102013114072B4 DE102013114072.6A DE102013114072A DE102013114072B4 DE 102013114072 B4 DE102013114072 B4 DE 102013114072B4 DE 102013114072 A DE102013114072 A DE 102013114072A DE 102013114072 B4 DE102013114072 B4 DE 102013114072B4
Authority
DE
Germany
Prior art keywords
barrier
thread
threads
instruction
execution
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.)
Active
Application number
DE102013114072.6A
Other languages
English (en)
Other versions
DE102013114072A1 (de
Inventor
John Erik Lindholm
Tero Tapani KARRAS
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nvidia Corp
Original Assignee
Nvidia Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nvidia Corp filed Critical Nvidia Corp
Publication of DE102013114072A1 publication Critical patent/DE102013114072A1/de
Application granted granted Critical
Publication of DE102013114072B4 publication Critical patent/DE102013114072B4/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003—Arrangements for executing specific machine instructions
    • G06F9/30076—Arrangements for executing specific machine instructions to perform miscellaneous control operations, e.g. NOP
    • G06F9/30087—Synchronisation or serialisation instructions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3824—Operand accessing
    • G06F9/3834—Maintaining memory consistency
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3836—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution
    • G06F9/3851—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution from multiple instruction streams, e.g. multistreaming
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3885—Concurrent instruction execution, e.g. pipeline or look ahead using a plurality of independent parallel functional units
    • G06F9/3888—Concurrent instruction execution, e.g. pipeline or look ahead using a plurality of independent parallel functional units controlled by a single instruction for multiple threads [SIMT] in parallel
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
    • G06F9/522—Barrier synchronisation

Landscapes

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

Abstract

Ein Verfahren aufweisend:Initiieren einer Ausführung einer Mehrzahl von Threads, um Instruktionen eines Programmes zu verarbeiten, das eine Barriereinstruktion aufweist;für jeden Thread in der Mehrzahl von Threads: Anhalten der Ausführung von Instruktionen, wenn der Thread die Barriereinstruktion erreicht;Bestimmen, dass die Barriereinstruktion zur Ausführung geschedulet werden mag, wenn entweder eine Minimumanzahl von teilnehmenden Threads, die kleiner ist als eine Anzahl von Threads, die an der Barriereinstruktion teilnehmen, die Barriereinstruktion erreicht hat oder wenn eine maximale Zeitdauer abgelaufen ist;Assoziieren einer ersten Subgruppe der Threads in der Mehrzahl von Threads mit einem ersten Subbarriereindex;Assoziieren einer zweiten Subgruppe der Threads in der Mehrzahl von Threads mit einem zweiten Subbarriereindex; undein serielles Ausführen von Threads in der ersten Subgruppe und ein serielles Ausführen von Threads in der zweiten Subgruppe, wobei zumindest ein Thread in der ersten Subgruppe parallel mit zumindest einem Thread in der zweiten Subgruppe ausgeführt wird.

Description

  • Diese Erfindung wurde mit US-Regierungsunterstützung unter LLNS Nebenvertrag B599861, zuerkannt von DOE, gemacht. Die US-Regierung hat gewisse Rechte an dieser Erfindung.
  • GEBIET DER ERFINDUNG
  • Die vorliegende Erfindung bezieht sich auf Programmausführung und spezifischer auf Barrieren.
  • HINTERGRUND
  • Konventionelle Parallelverarbeitungsarchitekturen unterstützen der Ausführung von mehreren Threads. Bestimmte Operationen, die während der Ausführung eines Programmes unter Verwendung einer konventionellen Parallelverarbeitungsarchitektur durchgeführt werden, mögen Synchronisation von mehreren Threads erfordern. Barriereinstruktionen (oder Zaun-Instruktionen) werden zum Synchronisieren der Ausführung von mehreren Threads während der Ausführung eines solchen Programmes verwendet. Eine Scheduling-Einheit innerhalb der Parallelverarbeitungsarchitektur erkennt die Barriereinstruktionen und sorgt dafür, dass alle Threads eine bestimmte Barriereinstruktion erreichen, bevor irgendeiner von den Threads eine Instruktion ausführt, die nach der bestimmten Barriereinstruktion folgt. Die Mehrthreadverarbeitungseinheit, welche die Threads ausführt, ist zum Synchronisieren der Threads bei der bestimmten Barriereinstruktion konfiguriert. Die Mehrthreadverarbeitungseinheit mag dazu konfiguriert sein, die synchronisierten Threads entweder parallel oder seriell auszuführen. In einigen Fällen mögen alle die synchronisierten Threads nicht parallel ausgeführt werden, zum Beispiel wenn die Barriere zum Abgrenzen eines geordneten kritischen Codeabschnittes verwendet wird. Serielle Ausführung der Threads reduziert aber die Performance bzw. Leistung. Die US 8 209 702 B1 beschreibt ein Verfahren zum Verteilen von Aufgaben an einen Pool von Verarbeitungs-Threads. Die US 2011/0 078 417 A1 beschreibt ein Verfahren zum Aggregieren von Operationen bei einer Synchronisationsbarriere.
  • Es besteht ein Bedürfnis danach, eine Ausführung von Barriereinstruktionen weiter zu verbessern.
  • ZUSAMMENFASSUNG
  • Es wird ein Verarbeitungssubsystem gemäß Anspruch 12 und ein Verfahren zum Scheduling der Ausführung von indexierten Barriereinstruktionen bereitgestellt gemäß Anspruch 1. Unter anderem wird die Ausführung einer Mehrzahl von Threads zur Verarbeitung von Instruktionen eines Programmes, das eine Barriereinstruktion enthält, initiiert, und wenn jeder Thread die Barriereinstruktion erreicht, hält der Thread die Ausführung der Instruktionen an. Eine erste Subgruppe von Threads in der Mehrzahl von Threads ist mit einem ersten Subbarriereindex assoziiert und eine zweite Subgruppe von Threads in der Mehrzahl von Threads ist mit einem zweiten Subbarriereindex assoziiert. Wenn die Barriereinstruktion zur Ausführung geschedulet werden kann, werden Threads in der ersten Subgruppe seriell ausgeführt und Threads in der zweiten Subgruppe werden seriell ausgeführt und zumindest ein Thread in der ersten Subgruppe wird parallel mit zumindest einem Thread in der zweiten Subgruppe ausgeführt.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
    • Die 1 ist ein Blockdiagramm, das ein Computersystem darstellt, das zum Implementieren eines oder mehrerer Aspekte der vorliegenden Offenbarung konfiguriert ist;
    • Die 2 ist ein Blockdiagramm von einem Parallelverarbeitungssubsystem für das Computersystem von 1, gemäß einer Ausführungsform der vorliegenden Offenbarung;
    • Die 3A ist ein Blockdiagramm von dem Frontend der 2, gemäß einer Ausführungsform der vorliegenden Offenbarung;
    • Die 3B ist ein Blockdiagramm von einem Allgemeinverarbeitungscluster (engl. „general processing cluster“) innerhalb einer der Parallelverarbeitungseinheiten von 2, gemäß einer Ausführungsform der vorliegenden Offenbarung;
    • Die 3C ist ein Blockdiagramm von einem Teil des Streaming-Multiprozessors von 3B, gemäß einer Ausführungsform der vorliegenden Offenbarung; und
    • Die 4 ist ein konzeptuelles Diagramm, das Threadblöcke eines CTA darstellt, gemäß einer beispielhaften Ausführungsform der vorliegenden Offenbarung;
    • Die 5A ist ein Blockdiagramm von der Warp-Scheduler- und Instruktionseinheit von 3C, gemäß einer beispielhaften Ausführungsform der vorliegenden Offenbarung;
    • Die 5B ist ein konzeptuelles Diagramm, das Subbarriereindexe auf ein Pixelgitter mappt, welches durch mehrere Grafikprimitive geschnitten wird, gemäß einer beispielhaften Ausführungsform der vorliegenden Offenbarung;
    • Die 5C ist ein Blockdiagramm von einem Teil der Scheduling-Einheit und der Barriere-Scheduling-Einheit von 5A, gemäß einer beispielhaften Ausführungsform der vorliegenden Offenbarung;
    • Die 5D stellt ein Verfahren zum Scheduling indexierter Barriereinstruktionen zur Ausführung dar, gemäß einer beispielhaften Ausführungsform der vorliegenden Offenbarung;
    • Die 6A stellt ein Verfahren zum Scheduling indexierter Barriereinstruktionen zur Ausführung dar, gemäß einer beispielhaften Ausführungsform der vorliegenden Offenbarung;
    • Die 6B stellt ein Verfahren zur Durchführung eines in der 6A gezeigten Schrittes dar, gemäß einer beispielhaften Ausführungsform der vorliegenden Offenbarung; und
    • Die 6C stellt ein Verfahren zur Durchführung eines in der 6B gezeigten Schrittes dar, gemäß einer beispielhaften Ausführungsform der vorliegenden Offenbarung.
  • DETAILLIERTE BESCHREIBUNG
  • Es wird ein System und ein Verfahren zum Scheduling der Ausführung von konditionellen Barrieren bereitgestellt, die eine Subgruppe von Threads dazu befähigen, an einer Barriereinstruktion teilzunehmen. Die Ausführung von Threads zur Verarbeitung von Instruktionen eines Programmes, das eine Barriereinstruktion enthält, wird initiiert, und wenn jeder Thread die Barriereinstruktion erreicht, wird es festgestellt, ob der Thread an der Barriereinstruktion teilnimmt. Die Threads, die an der Barriereinstruktion teilnehmen, werden ausgeführt, um eine oder mehrere Instruktionen des Programmes zu verarbeiten, die nach der Barriereinstruktion folgen. Threads, die nicht an der Barriereinstruktion teilnehmen, mögen weiter ausgeführt werden, ohne darauf zu warten, dass andere Threads die Barriereinstruktion erreichen.
  • Weitere illustrative Informationen in Bezug auf verschiedene optionale Architekturen und Merkmale werden jetzt dargelegt werden, mit denen die vorhergehende Technik implementiert oder nicht implementiert werden mag, gemäß den Wünschen des Benutzers. Es sollte deutlich beachtet werden, dass die folgenden Informationen zu illustrativen Zwecken dargelegt werden und nicht als in irgendeiner Art und Weise beschränkend ausgelegt bzw. aufgefasst werden sollten. Jedes der folgenden Merkmale mag optional mit oder ohne Ausschließung von anderen beschriebenen Merkmalen inkorporiert werden.
  • 1 ist ein Blockdiagramm, das ein Computersystem 100 zeigt, das zum Implementieren eines oder mehrerer Aspekte der vorliegenden Offenbarung konfiguriert ist. Das Computersystem 100 weist eine zentrale Verarbeitungseinheit (engl. „central processing unit“) (CPU) 102 und einen Systemspeicher 104 auf, die über einen Verbindungspfad (engl. „interconnection path“), der eine Speicherbrücke 105 aufweisen mag, miteinander in Verbindung stehen bzw. kommunizieren. Die Speicherbrücke 105, die zum Beispiel ein Northbridge-Chip sein mag, ist über einen Bus oder einen anderen Kommunikationspfad 106 (zum Beispiel einen HyperTransport-Link) mit einer I/O-(Input/Output)-Brücke 107 verbunden. Die I/O-Brücke 107, welche zum Beispiel ein Southbridge-Chip sein mag, erhält User-Input von einer oder mehreren User-Input-Vorrichtungen 108 (zum Beispiel Tastatur, Maus) und leitet den Input über den Kommunikationspfad 106 und die Speicherbrücke 105 an die CPU 102 weiter. Ein Parallelverarbeitungssubsystem 112 ist über einen Bus oder einen zweiten Kommunikationspfad 113 (zum Beispiel einen Peripheral Component Interconnect (PCI) Express, einen beschleunigten Grafikport (engl. „Accelerated Graphics Port“), oder einen HyperTransport-Link) an die Speicherbrücke 105 gekoppelt; in einer Ausführungsform ist das Parallelverarbeitungssubsystem 112 ein Grafiksubsystem, das Pixel an eine Displayvorrichtung 110 liefert (zum Beispiel einen auf einer konventionellen Kathodenstrahlröhre oder auf einem Flüssigkristalldisplay basierten Monitor). Eine Systemdisk 114 ist auch mit der I/O-Brücke 107 verbunden. Ein Switch 116 stellt Verbindungen zwischen der I/O-Brücke 107 und anderen Bauteilen, wie zum Beispiel einem Netzwerkadapter 118 und verschiedenen Erweiterungskarten (engl. „add-in cards“) 120 und 121, bereit. Andere (nicht explizit dargestellte) Bauteile, einschließlich Universal-Serial-Bus (USB) oder anderer Portanschlüsse (engl. „port connections“), Compact-Disc-(CD)-Laufwerke, Digital-Video-Disc-(DVD)-Laufwerke, Filmaufzeichnungsvorrichtungen und ähnliches, mögen auch mit der I/O-Brücke 107 verbunden sein. Die verschiedene Verbindungspfade, die in 1 gezeigt sind, einschließlich der spezifisch benannten Kommunikationspfade 106 und 113, mögen unter Verwendung von jeglichen geeigneten Protokollen, wie zum Beispiel PCI-Express, AGP (Accelerated Graphics Port), HyperTransport oder jedem anderen Bus oder Punkt-zu-Punkt-Kommunikationsprotokoll(en) (engl. „Point-to-Point Communication Protocol(s)“) implementiert sein, und Verbindungen zwischen verschiedenen Vorrichtungen mögen verschiedene Protokolle benutzen, wie es aus dem Stand der Technik bekannt ist.
  • Das Parallelverarbeitungssubsystem 112 weist in einer Ausführungsform Schaltkreise auf, die für Grafik- und Videoverarbeitung optimiert sind, einschließlich zum Beispiel Videoausgabeschaltkreise, und stellt eine Grafikverarbeitungseinheit (GPU) dar. In einer anderen Ausführungsform weist das Parallelverarbeitungssubsystem 112 Schaltkreise auf, die für Universalverarbeitung (engl. „general purpose processing“) optimiert sind, während die unterliegende rechnerische Architektur aufrechterhalten wird, wie es hierin detaillierter beschrieben wird. In noch einer anderen Ausführungsform mag das Parallelverarbeitungssubsystem 112 mit einem oder mehreren anderen Systemelementen in einem einzigen Subsystem integriert sein, wie zum Beispiel durch Zusammenfügen (engl. „joining“) der Speicherbrücke 105, der CPU 102 und der I/O-Brücke 107, um ein System-auf-Chip (engl. „system on chip“) (SoC) zu bilden.
  • Es wird verstanden werden, dass das hierin gezeigte System illustrativ ist und dass Variationen und Modifikationen möglich sind. Die Verbindungstopologie, einschließlich der Anzahl und Anordnung von Brücken, der Anzahl von CPUs 102 und der Anzahl von Parallelverarbeitungssubsystemen 112, mag wie gewünscht modifiziert werden. In einigen Ausführungsformen ist der Systemspeicher 104 zum Beispiel direkt mit der CPU 102 verbunden, statt durch eine Brücke, und andere Vorrichtungen kommunizieren über die Speicherbrücke 105 und die CPU 102 mit dem Systemspeicher 104. In anderen alternativen Topologien ist das Parallelverarbeitungssubsystem 112 mit der I/O-Brücke 107 oder direkt mit der CPU 102 verbunden, statt mit der Speicherbrücke 105. In noch anderen Ausführungsformen mögen die I/O-Brücke 107 und Speicherbrücke 105 in einem einzigen Chip integriert sein, statt als eine oder mehr diskrete Vorrichtungen zu existieren. Große Ausführungsformen mögen zwei oder mehr CPUs 102 und zwei oder mehr Parallelverarbeitungssysteme 112 aufweisen. Die jeweiligen hierin gezeigten Bauteile sind optional; zum Beispiel mag jede Anzahl von Erweiterungskarten oder Peripherievorrichtungen unterstützt werden. In einigen Ausführungsformen ist der Switch 116 entfernt und der Netzwerkadapter 118 und die Erweiterungskarten 120, 121 sind direkt mit der I/O-Brücke 107 verbunden.
  • 2 zeigt ein Parallelverarbeitungssubsystem 112 gemäß einer Ausführungsform der vorliegenden Offenbarung. Das Parallelverarbeitungssubsystem 112 weist, wie gezeigt, eine oder mehr Parallelverarbeitungseinheiten (engl. „Parallel Processing Units“) (PPUs) 202 auf, wobei jede von denen an einen lokalen Parallelverarbeitungs-(PP)-Speicher 204 gekoppelt ist. Im Allgemeinen weist ein Parallelverarbeitungssubsystem eine Anzahl U von PPUs auf, wobei U ≥ 1. (Hierin werden mehrere Instanzen ähnlicher Objekte mit Bezugszeichen, die das Objekt identifizieren, und Ziffern in Klammern, die, wenn nötig, die Instanz identifizieren, gekennzeichnet.) Die PPUs 202 und die Parallelverarbeitungsspeicher 204 mögen unter Verwendung einer oder mehrerer integrierten Schaltungsvorrichtungen implementiert werden, wie zum Beispiel programmierbare Prozessoren, anwendungsspezifische integrierte Schaltungen (engl. „Application Specific Integrated Circuits“) (ASICs) oder Speichervorrichtungen, oder in jeder anderen technisch realisierbaren Art und Weise.
  • In einigen Ausführungsformen sind, wieder mit Bezug sowohl auf 1 als auch auf 2, einige oder alle der PPUs 202 in dem Parallelverarbeitungssubsystem 112 Grafikprozessoren mit Rendering-Pipelines, die dazu konfiguriert werden können, verschiedene Operationen in Bezug auf das Erzeugen von Pixeldaten aus Grafikdaten, die von der CPU 102 und/oder dem Systemspeicher 104 über die Speicherbrücke 105 und den zweiten Kommunikationspfad 113 bereitgestellt werden, auszuführen, mit lokalem Parallelverarbeitungsspeicher 204 (der als Grafikspeicher einschließlich, zum Beispiel, eines konventionellen Framepuffers benutzt werden kann) zu interagieren, um Pixeldaten zu speichern und zu aktualisieren, Pixeldaten an die Displayvorrichtung 110 zu übermitteln, und ähnliches. In einigen Ausführungsformen mag das Parallelverarbeitungssubsystem 112 eine oder mehrere PPUs 202 aufweisen, die als Grafikprozessoren arbeiten, und eine oder mehrere PPUs 202, die für Universalberechnungen (engl. „general-purpose computations“) benutzt werden. Die PPUs mögen identisch oder unterschiedlich sein, und jede PPU mag eine dedizierte(n) Parallelverarbeitungsspeichervorrichtung(en) oder keine dedizierte(n) Parallelverarbeitungsspeichervorrichtung(en) aufweisen. Eine oder mehrere der PPUs 202 in dem Parallelverarbeitungssubsystem 112 mag bzw. mögen Daten an eine Displayvorrichtung 110 ausgeben oder jede PPU 202 in dem Parallelverarbeitungssubsystem 112 mag Daten an eine oder mehrere Displayvorrichtungen 110 ausgeben.
  • Im Betrieb ist die CPU 102 der Masterprozessor des Computersystems 100, welcher den Betrieb anderer Systembauteile steuert und koordiniert. Die CPU 102 erteilt insbesondere Befehle, die den Betrieb der PPUs 202 steuern. In einigen Ausführungsformen schreibt die CPU 102 einen Befehlsstrom für jede PPU 202 in eine (weder in 1 noch in 2 explizit gezeigte) Datenstruktur, die sich im Systemspeicher 104, Parallelverarbeitungsspeicher 204 oder in einer anderen Speicherstelle befinden mag, die für sowohl die CPU 102 als auch die PPU 202 zugreifbar ist. Ein Zeiger auf jede Datenstruktur wird in einen Push-Puffer (engl. „push puffer“) geschrieben, um Verarbeitung des Befehlsstroms in der Datenstruktur zu initiieren. Die PPU 202 liest Befehlsströme aus einem oder mehreren Push-Puffern aus und führt dann Befehle asynchron relativ zu dem Betrieb der CPU 102 aus. Ausführungsprioritäten mögen von einem Applikationsprogramm über den Gerätetreiber 103 für jeden Push-Puffer festgelegt werden, um das Scheduling der verschiedenen Push-Puffer zu steuern.
  • Jetzt wird sowohl auf 2 als auch auf 1 Rückbezug genommen und jede PPU 202 weist eine I/O-(Input/Output)-Einheit 205 auf, die mit dem restlichen Computersystem 100 über Kommunikationspfad 113 kommuniziert, der mit der Speicherbrücke 105 (oder in einer alternativen Ausführungsform direkt mit der CPU 102) in Verbindung steht. Die Verbindung der PPU 202 an das restliche Computersystem 100 mag auch variiert werden. In einigen Ausführungsformen ist das Parallelverarbeitungssubsystem 112 als eine Erweiterungskarte implementiert, die in einen Erweiterungsslot (engl. „expansion slot“) des Computersystems 100 eingebracht werden kann. In anderen Ausführungsformen kann eine PPU 202 auf einem einzigen Chip mit einer Busbrücke, wie zum Beispiel Speicherbrücke 105 oder I/O-Brücke 107, integriert sein. In noch anderen Ausführungsformen mögen einige oder alle Elemente der PPU 202 auf einem einzigen Chip mit der CPU 102 integriert sein.
  • In einer Ausführungsform ist der Kommunikationspfad 113 ein PCI-Express-Anschluss (engl. „PCI-Express link“), in welchem jeder PPU 202 dedizierte Spuren allokiert bzw. zugewiesen sind, wie es auf dem technischen Gebiet bekannt ist. Andere Kommunikationspfade mögen auch benutzt werden. Eine I/O-Einheit 205 erzeugt Pakete (oder andere Signale) für Transmission auf dem Kommunikationspfad 113 und empfängt auch alle ankommenden Pakete (oder anderen Signale) von dem Kommunikationspfad 113, wobei die ankommenden Pakete zu zweckmäßigen Bauteilen bzw. Komponenten der PPU 202 geleitet werden. Befehle, die sich auf Bearbeitungstasks beziehen, mögen zum Beispiel zu einer Hostschnittstelle (engl. „host interface“) 206 geleitet werden, während Befehle, die sich auf Speichervorgänge (zum Beispiel Auslesen aus oder Schreiben zu den Parallelverarbeitungsspeicher 204) beziehen, zu einer Speicher-Kreuzschieneneinheit 210 geleitet werden mögen. Die Hostschnittstelle 206 liest jeden Push-Puffer aus und gibt den Befehlsstrom, der in dem Push-Puffer gespeichert ist, zu einem Frontend 212 aus.
  • Jede PPU 202 implementiert vorteilhafterweise eine in hohem Maße parallele Verarbeitungsarchitektur. Die PPU 202(0) weist, wie im Detail gezeigt, ein Verarbeitungsclusterarray (engl. „processing cluster array“) 230 auf, das eine Anzahl C von Allgemeinverarbeitungsclustern (engl. „general processing clusters“) (GPCs) 208 aufweist, wobei C ≥ 1. Jeder GPC 208 ist in der Lage, eine große Anzahl (zum Beispiel hunderte oder tausende) von Threads gleichzeitig auszuführen, wobei jeder Thread eine Instanz eines Programmes ist. In verschiedenen Applikationen mögen unterschiedlichen GPCs 208 zur Verarbeitung unterschiedlicher Arten von Programmen oder zum Ausführen unterschiedlicher Arten von Berechnungen allokiert werden. Das Allokieren von GPCs 208 mag in Abhängigkeit von der Auslastung variieren, die für jede Art von Programm oder Berechnung entsteht.
  • Die GPCs 208 erhalten auszuführende Verarbeitungstasks von einer Arbeitsverteilungseinheit innerhalb einer Task/Arbeit-Einheit (engl. „task/work unit“) 207. Die Arbeitsverteilungseinheit empfängt Zeiger auf Rechenverarbeitungstasks, die als Taskmetadaten (engl. „task metadata“) (TMD) kodiert und im Speicher gespeichert sind. Die Zeiger auf TMDs sind in den Befehlsstrom beinhaltet, der als ein Push-Puffer gespeichert und mittels der Frontend-Einheit 212 von der Host-Schnittstelle 206 empfangen wird. Verarbeitungstasks, die als TMDs kodiert werden mögen, beinhalten Indices von zu verarbeitenden Daten sowie Zustandsparameter und Befehle, die definieren wie die Daten zu verarbeiten sind (zum Beispiel welches Programm auszuführen ist). Die Task/Arbeit-Einheit 207 empfängt Tasks von dem Frontend 212 und stellt sicher, dass die GPCs 208 zu einem gültigen Zustand konfiguriert sind, bevor die von jedem einzelnen der TMDs spezifizierte Verarbeitung eingeleitet wird. Eine Priorität mag für jede TMD, die zum Scheduling der Ausführung der Verarbeitungstasks benutzt wird, spezifiziert sein. Verarbeitungstasks können auch von dem Verarbeitungsclusterarray 230 erhalten werden. Die TMD können wahlweise bzw. optional einen Parameter enthalten, der steuert, ob die TMD zu dem Kopf oder Ende einer Liste von Verarbeitungstasks (oder Liste von Zeigern auf die Verarbeitungstasks) hinzugefügt werden soll, wobei eine weitere Stufe der Steuerung über Priorität bereitgestellt wird.
  • Die Speicherschnittstelle 214 weist eine Anzahl D von Partitionseinheiten 215 auf, die jeweils direkt an einen Teil des Parallelverarbeitungsspeichers 204 gekoppelt sind, wobei D ≥ 1. Die Anzahl der Partitionseinheiten 215 ist, wie gezeigt, generell gleich der Anzahl von dynamischen Direktzugriffspeicher (engl. „dynamic random access memory“) (DRAM) 220. In anderen Ausführungsformen mag die Anzahl der Partitionseinheiten 215 nicht gleich der Anzahl der Speichervorrichtungen sein. Fachleute durchschnittlicher Kenntnisse werden verstehen, dass DRAM 220 durch andere geeignete Speichervorrichtungen ersetzt werden mag und von einer generell konventionellen Bauform sein kann. Eine detaillierte Beschreibung wird deswegen weggelassen. Render-Ziele, wie zum Beispiel Framepuffer oder Strukturpläne, mögen quer über die DRAMs 220 gespeichert werden, was den Partitionseinheiten 215 ermöglicht, Teile von jedem Render-Ziel parallel zu schreiben, um die vorhandene Bandbreite des Parallelverarbeitungsspeichers 204 effizient zu nutzen.
  • Jeder der GPCs 208 mag Daten verarbeiten, die in irgendeinen der DRAMs 220 innerhalb des Parallelverarbeitungsspeichers 204 zu schreiben sind. Die Kreuzschieneneinheit 210 ist dazu konfiguriert, den Output jedes GPC 208 an den Input einer jeden Partitionseinheit 215 oder an einen anderen GPC 208 für weitere Verarbeitung zu leiten bzw. routen. Die GPCs 208 kommunizieren mit der Speicherschnittstelle 214 durch die Kreuzschieneneinheit 210, um aus bzw. in verschiedenen externen Speichervorrichtungen auszulesen bzw. zu schreiben. In einer Ausführungsform hat die Kreuzschieneneinheit 210 sowohl eine Verbindung zu der Speicherschnittstelle 214, um mit der I/O-Einheit 205 zu kommunizieren, als auch eine Verbindung zu dem lokalen Parallelverarbeitungsspeicher 204, wodurch es den Verarbeitungskernen innerhalb der verschiedenen GPCs 208 ermöglicht werden, mit dem Systemspeicher 104 oder einem anderen Speicher, der kein lokaler Teil der PPU 202 ist, zu kommunizieren. In der in 2 gezeigten Ausführungsform ist die Kreuzschieneneinheit 210 direkt mit der I/O-Einheit 205 verbunden. Die Kreuzschieneneinheit 210 mag virtuelle Kanäle benutzen, um Datenverkehrsströme zwischen den GPCs 208 und den Partitionseinheiten 215 zu separieren.
  • Wie erwähnt können die GPCs 208 zum Ausführen von Verarbeitungstasks, die sich auf eine umfangreiche Vielfalt von Applikationen beziehen, programmiert werden, einschließlich, aber nicht begrenzt auf, linearer und nicht-linearer Datentransformationen, Filtern von Video- und/oder Audiodaten, Modellierungsvorgänge (zum Beispiel der Anwendung von physikalischen Gesetzen zum Bestimmen von Position, Geschwindigkeit und anderen Eigenschaften von Objekten), Bild-Rendering-Vorgängen (zum Beispiel Mosaikshader-, Scheitelshader-, Geometrieshader- und/oder Pixel-Shaderprogramme (engl. „tesselation shader, vertex shader, geometry shader, and/or pixel shader programs“)), usw. Die PPUs 202 mögen Daten von dem Systemspeicher 104 und/oder den lokalen Parallelverarbeitungsspeichern 204 in einen internen (auf-dem-Chip) Speicher hinein übertragen, die Daten verarbeiten und die Ergebnisdaten zurück in den Systemspeicher 104 und/oder die lokalen Parallelverarbeitungsspeicher 204 hinein schreiben, wo auf solche Daten von anderen Systembauteilen, einschließlich CPU 102 oder anderer Parallelverarbeitungssubsysteme 112, zugegriffen werden kann.
  • Eine PPU 202 mag mit jeder Menge lokaler Parallelverarbeitungsspeicher 204, einschließlich keiner lokalen Speicher, ausgestattet sein, und mag lokalen Speicher und Systemspeicher in jeder beliebigen Kombination benutzen. Eine PPU 202 kann zum Beispiel ein Grafikprozessor in einer Ausführungsform mit einheitlicher Speicherarchitektur (engl. „unified memory architecture“) (UMA) sein. In solchen Ausführungsformen würde wenig oder kein dedizierter Grafik-(Parallelverarbeitungs-)Speicher bereitgestellt werden, und die PPU 202 würde ausschließlich oder fast ausschließlich den Systemspeicher benutzen. In UMA-Ausführungsformen mag eine PPU 202 in einem Brückenchip oder Prozessorchip integriert sein oder als ein diskreter Chip mit einem Hochgeschwindigkeitsanschluss (beispielsweise PCI-Express), der die PPU 202 über einen Brückenchip oder ein anderes Kommunikationsmittel mit dem Systemspeicher verbindet, bereitgestellt werden.
  • Wie oben erwähnt, kann jede beliebige Anzahl von PPUs 202 in einem Parallelverarbeitungssubsystem 112 enthalten sein. Mehrere PPUs 202 können zum Beispiel auf einer einzigen Erweiterungskarte bereitgestellt werden oder mehrere Erweiterungskarten können mit dem Kommunikationspfad 113 verbunden werden oder eine oder mehrere der PPUs 202 können in einem Brückenchip integriert werden. Die PPUs 202 in einem Mehrfach-PPU-System mögen gleich oder unterschiedlich voneinander sein. Unterschiedliche PPUs 202 mögen zum Beispiel eine jeweils unterschiedliche Anzahl von Prozessorkernen, unterschiedliche Mengen von lokalem Parallelverarbeitungsspeicher usw. aufweisen. Wenn mehrere PPUs 202 vorhanden sind, mögen diese PPUs parallel betrieben werden, um Daten mit einem größeren Durchsatz, als es mit einer einzigen PPU 202 möglich ist, zu verarbeiten. Systeme, die eine oder mehrere PPUs 202 aufweisen, mögen in einer Vielfalt von Konfigurationen und Formfaktoren implementiert werden, einschließlich Desktop-, Laptop- oder handgeführter persönlicher Rechner, Server, Arbeitsstationen (engl. „workstations“), Spielkonsolen, eingebetteter Systeme und ähnliches.
  • Scheduling von mehreren gleichzeitigen Tasks (engl. „Multiple Concurrent Task Scheduling“)
  • Mehrere Verarbeitungstasks mögen gleichzeitig auf den GPCs 208 ausgeführt werden und ein Verarbeitungstask mag während der Ausführung ein oder mehrere „Kind“-Verarbeitungstasks (engl. „„child" processing tasks") erzeugen. Die Task/Arbeit-Einheit 207 empfängt die Tasks und legt dynamisch die Ausführung der Bearbeitungstasks und der Kind-Verarbeitungstasks mittels der GPCs 208 zeitlich fest.
  • 3A ist ein Blockdiagramm von der Task/Arbeit-Einheit 207 von der 2, gemäß einer Ausführungsform der vorliegenden Offenbarung. Die Task/Arbeit-Einheit 207 weist eine Taskmanagementeinheit 300 und die Arbeitsverteilungseinheit 340 auf. Die Taskmanagementeinheit 300 organisiert die Tasks, die zu schedulen sind, basierend auf Ausführungsprioritätsstufen. Für jede Prioritätsstufe speichert die Taskmanagementeinheit 300 eine Liste von Zeigern auf die TMDs 322, die den Tasks in der Schedulertabelle 321 entsprechen, wobei die Liste als eine verbundene Liste (engl. „linked list“) implementiert werden mag. Die TMDs 322 mögen in dem PP-Speicher 204 oder in dem Systemspeicher 104 gespeichert sein. Die Rate, mit welcher die Taskmanagementeinheit 300 Tasks akzeptiert und die Tasks in der Schedulertabelle 321 speichert, ist von der Rate entkoppelt, mit der die Taskmanagementeinheit 300 die Ausführung von Tasks zeitlich festlegt (engl. „schedules“). Folglich mag die Taskmanagementeinheit 300 mehrere Tasks sammeln, bevor er deren Ausführung zeitlich festlegt. Die gesammelten Tasks mögen dann basierend auf Prioritätsinformation oder unter Verwendung anderer Techniken, wie zum Beispiel Rundlauf-Scheduling (engl. „round-robin scheduling“), geschedulet werden.
  • Die Arbeitsverteilungseinheit 340 weist eine Tasktabelle 345 mit Slots auf, die jeweils von den TMD 322 für einen Task, der ausgeführt wird, belegt sein mögen. Die Taskmanagementeinheit 300 mag die Tasks zur Ausführung schedulen, wenn es einen freien Slot in der Tasktabelle 345 gibt. Wenn es keinen freien Slot gibt, mag ein Task mit höherer Priorität, der keinen Slot belegt, einen Task mit niedrigerer Priorität vertreiben (engl. „evict“), der einen Slot belegt. Wenn ein Task vertrieben wird, wird der Task gestoppt, und falls die Ausführung des Tasks nicht abgeschlossen ist, dann wird ein Zeiger auf den Task zu einer Liste von Taskzeigern hinzugefügt, die geschedulet werden sollen, so dass die Ausführung des Tasks zu einem späteren Zeitpunkt wieder aufgenommen wird. Wenn ein Kind-Verarbeitungstask während Ausführung eines Tasks erzeugt wird, dann wird ein Zeiger auf den Kind-Task zu der Liste von Taskzeigern, die geschedulet werden sollen, hinzugefügt. Ein Kind-Task mag von einer TMD 322 erzeugt werden, die in dem Verarbeitungsclusterarray 230 ausgeführt wird.
  • Anders als ein Task, der durch die Task-/Arbeit-Einheit 207 von dem Frontend 212 erhalten wird, werden Kind-Tasks von dem Verarbeitungsclusterarray 230 erhalten. Kind-Tasks werden nicht in einem Push-Puffer eingefügt oder zu dem Frontend transmittiert. Die CPU 102 wird nicht benachrichtigt, wenn ein Kind-Task erzeugt wird oder Daten für den Kind-Task im Speicher gespeichert werden. Ein weiterer Unterschied zwischen den Tasks, die durch Push-Puffern bereitgestellt werden, und Kind-Tasks ist, dass die durch den Push-Puffern bereitgestellten Tasks von dem Applikationsprogramm definiert werden, während die Kind-Tasks während der Ausführung der Tasks dynamisch erzeugt werden.
  • Übersicht der Taskverarbeitung
  • Die 3B ist ein Blockdiagramm von einem GPC 208 innerhalb einer der PPUs 202 von 2, gemäß einer Ausführungsform der vorliegenden Offenbarung. Jeder GPC 208 mag zum parallelen Ausführen einer großen Anzahl von Threads konfiguriert sein, wobei der Begriff „Thread“ auf eine Instanz eines bestimmten Programmes hinweist, das auf einem bestimmten Satz von Inputdaten ausgeführt wird. In einigen Ausführungsformen werden einzelne-Instruktions-, mehrfache-Daten-(SIMD)- Instruktionsausgabetechniken (engl. „single-instruction, multiple-data (SIMD) instruction issue techniques“) verwendet, um parallele Ausführung von einer großen Anzahl von Threads zu unterstützen, ohne mehrfache unabhängige Instruktionseinheiten bereitzustellen. In anderen Ausführungsformen werden einzelne-Instruktions-, mehrfache-Threads-(SIMT)-Techniken (engl. „single-instruction, multiple-thread (SIMT) techniques“) verwendet, um parallele Ausführung von einer großen Anzahl von generell synchronisierten Threads zu unterstützen, unter Verwendung einen gemeinsamen Instruktionseinheit, die zur Ausgabe von Instruktionen an einen Satz von Verarbeitungsmaschinen (engl. „processing engines“) innerhalb jedes der GPCs 208 konfiguriert ist. Anders als bei einer SIMD-Ausführungsbetriebsart (engl. „SIMD execution regime“), bei der alle Verarbeitungsmaschinen typischerweise identische Instruktionen ausführen, erlaubt die SIMT-Ausführung, dass verschiedene Threads divergierende Ausführungspfade durch ein gegebenes Threadprogramm zügiger folgen. Fachleute werden verstehen, dass eine SIMD-Verarbeitungsbetriebsart eine funktionelle Untermenge von einer SIMT-Verarbeitungsbetriebsart ist. Eine SISD- (einzelne Instruktion, einzelne Daten) oder eine MIMD- (mehrere Instruktionen, mehrere Daten) -Betriebsart repräsentiert in ähnlicher Art und Weise auch eine funktionelle Untermenge von einer SIMT-Verarbeitungsbetriebsart.
  • Die Operation des GPC 208 wird vorteilhafterweise über einen Pipelinemanager 305 gesteuert, der Verarbeitungstasks an Streaming-Mehrfachprozessoren (SMs) 310 verteilt. Der Pipelinemanager 305 mag auch dazu konfiguriert sein, eine Arbeitsverteilungskreuzschiene 330 durch Angeben von Destinationen für verarbeitete Datenausgabe von den SMs 310 zu steuern.
  • In einer Ausführungsform weist jeder GPC 208 eine Anzahl M von SMs 310 auf, wobei M ≥ 1 und jeder SM 310 zum Verarbeiten einer oder mehrerer Threadgruppen konfiguriert ist. Jeder SM 310 weist vorteilhafterweise auch einen identischen Satz von funktionellen Ausführungseinheiten (zum Beispiel Ausführungseinheiten und Load-Store-Einheiten (engl. „load-store units“), die als Ausführungseinheiten 302 und LSUs 303 in 3C gezeigt sind) auf, die gepipelined sein mögen, erlaubend eine neue Instruktion ausgegeben zu werden, bevor eine vorhergehende Instruktion fertig ist, wie es auf dem technischen Gebiet bekannt ist. Jede Kombination funktioneller Ausführungseinheiten mag bereitgestellt werden. In einer Ausführungsform unterstützen die funktionellen Einheiten eine Vielzahl von Operationen, einschließlich Ganzzahl- und Fließkommaarithmetik (zum Beispiel Addition und Multiplikation), Vergleichsoperationen, boolescher Operationen (UND, ODER, EXKLUSIV-ODER), Bit-Verschiebung und Berechnung von diversen algebraischen Funktionen (zum Beispiel planarer Interpolation, trigonometrischer, exponentieller und logarithmischer Funktionen usw.); und die gleiche Funktionseinheitshardware kann zum Ausführen verschiedener Operationen eingesetzt (engl. „leveraged“) werden.
  • Die Reihe von Instruktionen, die an einen bestimmten GPC 208 übermittelt wird, werden von einem oder mehreren Threads ausgeführt, wie es hierin früher definiert wurde, und die Sammlung von einer bestimmten Anzahl von Threads, die gleichzeitig überall in (engl. „across“) den Parallelverarbeitungsmaschinen (nicht gezeigt) innerhalb eines SM 310 ausgeführt werden, wird als ein „Warp“ oder als eine „Threadgruppe“ (engl. „thread group“) bezeichnet. Wie hierin benutzt, bezeichnet eine „Threadgruppe“ eine Gruppe von einem oder mehreren Threads, die gleichzeitig das gleiche Programm auf unterschiedlichen Inputdaten ausführen, wobei ein Thread der Gruppe einer unterschiedlichen Verarbeitungsmaschine innerhalb eines SM 310 zugeordnet ist. Eine Threadgruppe mag weniger Threads als die Anzahl der Verarbeitungsmaschinen innerhalb des SM 310 enthalten, in welchem Falle einige Verarbeitungsmaschinen während Zyklen, in denen diese Threadgruppe verarbeitet wird, inaktiv bzw. im Leerlauf sein werden. Eine Threadgruppe mag auch mehr Threads als die Anzahl der Verarbeitungsmaschinen innerhalb des SM 310 enthalten, in welchem Falle die Verarbeitung in aufeinanderfolgenden Zyklen stattfinden wird. Da jeder SM 310 bis zu G Threadgruppen gleichzeitig unterstützen kann, folgt es, dass bis zu G*M Threadgruppen zu jedem gegebenen Zeitpunkt im GPC 208 ausgeführt werden können.
  • Eine Mehrzahl von verwandten bzw. in Beziehung stehenden Threadgruppen mag des Weiteren zum gleichen Zeitpunkt innerhalb eines SM 310 aktiv sein (in verschiedenen Phasen der Ausführung). Diese Sammlung von Threadgruppen wird hierin als ein „Array zusammenarbeitender Threads“ (engl. „cooperative thread array“) (CTA) oder „Threadarray“ bezeichnet. Jedes CTA weist eine vom Programmierer spezifizierte Anzahl von Warps auf, die in der gleichen SM 310 ausgeführt werden. Ein oder mehrere CTAs können potenziell gleichzeitig in dem gleichen SM 310 ausgeführt werden. Die Größe eines CTA wird generell von dem Programmierer und der Menge der für das CTA zur Verfügung stehenden Hardware-Ressourcen, wie zum Beispiel Speicher oder Register, bestimmt.
  • Jeder SM 310 enthält einen Stufe-Eins-(L1)-Cache (engl. „level one cache“) (gezeigt in 3C) oder nutzt Platz in einem entsprechenden L1-Cache außerhalb des SM 310, der zum Ausführen von Lade- und Speicheroperationen (engl. „load and store operations“) benutzt wird. Jeder SM 310 hat auch Zugriff auf Stufe-Zwei-(L2)-Caches, die von allen GPCs 208 gemeinsam genutzt werden und zum Übertragen von Daten zwischen Threads benutzt werden mögen. Schließlich haben die SMs 310 auch Zugriff auf externen (engl. „off-chip“) „globalen“ Speicher, welcher zum Beispiel Parallelverarbeitungsspeicher 204 und/oder Systemspeicher 104 aufweisen kann. Es ist zu verstehen, dass jeder beliebige Speicher, der extern zur PPU 202 ist, als globaler Speicher benutzt werden mag. Ein Stufe-Eins-Komma-Fünf-(L1,5)-Cache 335 mag zusätzlich in dem GPC 208 inkludiert sein, welcher dazu konfiguriert ist, Daten, die vom SM 310 angefordert und über Speicherschnittstelle 214 aus dem Speicher abgerufen werden, einschließlich Instruktionen, einheitlichen (engl. „uniform“) Daten und konstanten Daten, zu erhalten und halten und die angeforderten Daten an den SM 310 zu liefern. Ausführungsformen, die mehrere SMs 310 im GPC 208 haben, teilen mit Vorteil gemeinsamen Instruktionen und Daten, die im L1,5-Cache 335 gespeichert sind.
  • Jeder GPC 208 mag eine Speichermanagementeinheit (MMU) 328 aufweisen, die zum Abbilden bzw. Mappen virtueller Adressen auf absolute (engl. „physical“) Adressen konfiguriert ist. In anderen Ausführungsformen mag bzw. mögen die MMU(s) 328 sich innerhalb der Speicherschnittstelle 214 befinden. Die MMU 328 enthält einen Satz von Seitentabelleneinträgen (engl. „page table entries“) (PTEs), die zum Abbilden bzw. Mappen einer virtuellen Adresse auf eine absolute Adresse verwendet werden. Die MMU 328 mag Adressübersetzungsassoziative-Pufferspeicher (TLB) (engl. „address translation lookaside buffers“) oder Adressübersetzungs-parallele-Cachespeicher (engl. „address translation lookaside caches“) aufweisen, die sich innerhalb des Mehrfachprozessors SM 310 oder des L1-Caches oder der GPC 208 befinden mögen. Die absolute Adresse wird verarbeitet, um Daten-Zugriffslokalität (engl. „data access locality“) zu distribuieren, um effiziente Auftragsinterleaving (engl. „request interleaving“) zwischen Partitionseinheiten 215 zu erlauben. Der Cachezeilenindex mag benutzt werden, um zu bestimmen, ob eine Anforderung für eine Cachezeile einen Treffer (engl. „hit“) oder ein Verfehlen Fehlschuss (engl. „miss“) ist.
  • In Grafik- und Rechenapplikationen mag ein GPC 208 derart konfiguriert sein, dass jeder SM 310 an eine Textureinheit 315 gekoppelt ist, um Bemusterungsoperationen (engl. „texture mapping operations“) durchzuführen, zum Beispiel Bestimmen von Texturabtastwertpositionen (engl. „texture sample positions“), Lesen von Texturdaten und Filtern der Texturdaten. Texturdaten werden aus einem internen (nicht gezeigten) Textur-L1-Cache oder, in einigen Ausführungsformen, aus dem L1-Cache innerhalb des SM 310 gelesen und werden bei Bedarf aus einem L2-Cache, der zwischen allen GPCs 208 geteilt ist, dem Parallelverarbeitungsspeicher 204 oder dem Systemspeicher 104 abgerufen. Jeder SM 310 gibt verarbeitete Tasks an die Arbeitsverteilungskreuzschiene 330 aus, um die verarbeiteten Tasks für einen anderen GPC 208 zur weiteren Verarbeitung bereitzustellen oder um die verarbeiteten Tasks in einem L2-Cache, Parallelverarbeitungsspeicher 204 oder Systemspeicher 104 über die Kreuzschieneneinheit 210 zu speichern. Eine Vor-ROP (Vorrasteroperationen (engl. „pre-raster operations“)) 325 ist dazu konfiguriert, Daten von dem SM 310 zu erhalten, Daten an ROP-Einheiten innerhalb Partitionseinheiten 215 zu leiten und Optimierungen für Farbmischung durchzuführen, Pixelfarbdaten zu organisieren und Adressenübersetzungen durchzuführen.
  • Es wird verstanden, dass die hierin beschriebene Kernarchitektur illustrativ ist und dass Variationen und Modifikationen möglich sind. Es mag jede beliebige Anzahl von Verarbeitungseinheiten, zum Beispiel SMs 310 oder Textureinheiten 315, Vor-ROPs 325 in einem GPC 208 enthalten sein. Des Weiteren mag eine PPU 202, wie es in 2 gezeigt ist, jede beliebige Anzahl von GPCs 208 enthalten, die vorteilhafterweise einander funktionell ähnlich sind, so dass der Verlauf der Ausführung nicht davon abhängt, welcher GPC 208 einen gegebenen Verarbeitungstask erhält. Des Weiteren operiert jeder GPC 208 vorteilhafterweise unabhängig von anderen GPCs 208 unter Verwendung separater und individueller Verarbeitungseinheiten, L1-Caches zur Ausführung von Tasks für eins oder mehrere Applikationsprogramme.
  • Durchschnittliche Fachleute werden verstehen, dass die in den 1, 2, 3A und 3B dargestellten Architektur den Umfang der vorliegenden Erfindung in keiner Weise begrenzt und dass die hierin beschriebenen Techniken in jeder sachgemäß konfigurierten Verarbeitungseinheit implementiert werden mögen, einschließlich, ohne Begrenzung, einer oder mehrerer CPUs, einer oder mehrerer Mehrkern-CPUs, einer oder mehrerer PPUs 202, eines oder mehrerer GPCs 208, einer oder mehrerer Grafik- oder Sonderzweck-(engl. „special purpose“)-Verarbeitungseinheiten oder ähnliches, ohne den Umfang der Vorliegenden Erfindung zu verlassen.
  • In Ausführungsformen der vorliegenden Erfindung ist es wünschenswert, PPU 202 oder einen anderen bzw. andere Prozessor(en) eines Datenverarbeitungssystems zu benutzen, um allgemeine Berechnungen unter Verwendung von Threadarrays durchzuführen. Jedem Thread in dem Threadarray ist einen eindeutigen Threadidentifikator (engl. „Thread-ID“) zugeordnet, der während der Ausführung des Threads für den Thread zugänglich ist. Der Thread-ID, der als ein eindimensionaler oder mehrdimensionaler numerischer Wert definiert werden kann, steuert verschiedene Aspekte von dem Verlauf der Ausführung des Threads. Ein Thread-ID mag zum Beispiel verwendet werden, um zu bestimmen, welchen Teil des Eingangsdatensatzes ein Thread bearbeiten soll, und/oder zu bestimmen, welchen Teil eines Ausgangsdatensatzes ein Thread produzieren oder schreiben soll.
  • Eine Folge bzw. Sequenz von pro-Thread-Instruktionen (engl. „per-thread instructions“) mag zumindest eine Instruktion enthalten, die ein kooperatives Verhalten zwischen dem maßgeblichen (engl. „representative“) Thread und einem oder mehreren anderen Threads des Threadarrays definiert. Die Sequenz von pro-Thread-Instruktionen mag zum Beispiel eine Instruktion, die Ausführung von Operationen für den maßgeblichen Thread bei einem bestimmten Punkt in der Sequenz bis zu einem solchen Zeitpunkt zu suspendieren, bei dem ein oder mehr von den anderen Threads diesen bestimmten Punkt erreichen, eine Instruktion für den maßgeblichen Thread, Daten in einem gemeinsam genutzten Speicher, auf den ein oder mehr von den anderen Threads Zugriff haben, zu speichern, eine Instruktion für den maßgeblichen Thread, Daten, die in einem gemeinsam genutzten Speicher, auf den ein oder mehr von den anderen Threads Zugriff basierend auf deren Thread-IDs haben, atomar zu lesen und aktualisieren, oder ähnliche Instruktionen enthalten. Das Programm kann auch eine Instruktion enthalten, eine Adresse in dem gemeinsamen genutzten Speicher zu berechnen, aus der Daten zu lesen sind, wobei die Adresse eine Funktion von dem Thread-ID ist. Durch Definieren zweckmäßiger Funktionen und durch Bereitstellen von Synchronisierungstechniken können Daten von einem Thread eines CTA in einer gegebenen Stelle in dem gemeinsam genutzten Speicher geschrieben und von einem anderen Thread des gleichen CTA aus dieser Stelle gelesen werden auf eine vorhersehbare Art und Weise. Folglich kann jedes gewünschtes Muster von Datenteilung zwischen Threads unterstützt werden und jeder Thread in einem CTA kann Daten mit jedem anderen Thread in dem gleichen CTA teilen. Der Umfang, wenn überhaupt, der Datenteilung zwischen Threads eines CTA wird von dem Programm bestimmt; es ist somit zu verstehen, dass die Threads eines CTA in einer gegebenen Applikation, der CTAs verwendet, tatsächlich, in Abhängigkeit von dem Programm, Daten miteinander teilen oder nicht miteinander teilen mögen, und die Begriffe „CTA“ und „Threadarray“ werden hierin synonym verwendet.
  • 3C ist ein Blockdiagramm des SM 310 von 3B, gemäß einer Ausführungsform der vorliegenden Offenbarung. Der SM 310 weist einen Instruktions-L1-Cache 370 auf, der zum Erhalten Instruktionen und Konstanten vom Speicher durch L1,5-Cache 335 konfiguriert ist. Eine Warp-Scheduler- und Instruktionseinheit (engl. „warp scheduler and instruction unit“) 312 erhält Instruktionen und Konstanten von dem Instruktions-L1-Cache 370 und steuert den lokalen Registerspeicher (engl. „local register file“) 304 und funktionelle Einheiten des SM 310 gemäß den Instruktionen und Konstanten. Die funktionellen Einheiten des SM 310 weisen N Ausführungs- oder Verarbeitungseinheiten 302 und P Lade-Speicher-Einheiten (engl. „load-store units) (LSU) 303 auf.
  • Der SM 310 stellt internen (engl. „on-chip“) Datenspeicher mit verschiedenen Zugreifbarkeitsstufen bereit. Spezielle (nicht gezeigte) Register sind für die LSU 303 lesbar aber nicht schreibbar und werden zum Speichern von Informationen verwendet, die die „Position“ eines jeden Threads definieren. In einer Ausführungsform weisen die speziellen Register ein Register pro Thread (oder pro Ausführungseinheit 302 in dem SM 310) auf, das eine Thread-ID speichert; Jedes Thread-ID-Register ist nur für eine entsprechende Ausführungseinheit der Ausführungseinheiten 302 zugreifbar. Die speziellen Register mögen auch zusätzliche Register enthalten, die für alle die Threads lesbar sind, die den gleichen Verarbeitungstask ausführen, die durch eine TMD 322 (oder durch alle LSUs 303) dargestellt werden, die einen CTA-Identifikator, die CTA-Dimensionen, die Dimensionen eines Netzes (engl. „grid“), zu dem das CTA gehört, (oder die Warteschlangenposition, falls die TMD 322 eine Warteschlangentask statt eines Netztasks (engl. „grid task“) codiert) und einen Identifikator der TMD 322 speichert, zu der das CTA gespeichert wird.
  • Falls die TMD 322 eine Netz-TMD ist, dann bewirkt die Ausführung der TMD 322, dass eine feste Anzahl von CTAs gestartet und ausgeführt wird, um die feste Menge von Daten auszuführen, die in der Warteschlange gespeichert ist. Die Anzahl der CTAs ist als das Produkt der Breite, Höhe und Tiefe des Netzes spezifiziert. Die feste Menge von Daten mag in der TMD 322 gespeichert werden oder die TMD 322 mag einen Zeiger auf die Daten speichern, die von den CTAs ausgeführt werden werden. Die TMD 322 speichern auch eine Startadresse des Programmes, das von den CTAs ausgeführt wird.
  • Falls die TMD 322 eine Warteschlange-TMD ist, dann wird eine Warteschlangeneigenschaft der TMD 322 verwendet, was heißt, dass die Menge von Daten, die bearbeitet werden soll, nicht notwendigerweise fest ist. Warteschlangeneinträge speichern Daten, die von den CTAs verarbeitet werden sollen, die zu der TMD 322 zugeordnet sind. Die Warteschlangeneinträge mögen auch einen Kind-Task darstellen, der während Ausführung eines Threads von einer anderen TMD 322 erzeugt worden ist, wobei eine geschachtelte Parallelität (engl. „nested parallelism“) bereitgestellt wird. Die Ausführung des Threads oder des CTA, das den Thread enthält, wird typischerweise suspendiert bis die Ausführung des Kind-Tasks komplett ist. Die Warteschlange mag in oder getrennt von der TMD 322 gespeichert werden, wobei die TMD im letzteren Falle einen Warteschlangezeiger auf die Warteschlange speichert. Daten, die von dem Kind-Task erzeugt worden sind, können vorteilhaft zu der Warteschlange geschrieben werden, während der TMD 322 ausgeführt wird, die den Kind-Task darstellen. Die Warteschlange mag als eine zirkuläre Warteschlange implementiert werden, so dass die totale Menge von Daten nicht von der Größe der Warteschlange begrenzt ist.
  • CTAs, die zu einem Netz gehören, haben implizite Netz-Breite-, -Höhe- und -Tiefe-Parameter, die die Position des jeweiligen CTA innerhalb des Netzes bezeichnen. Die speziellen Register werden während der Initialisierung als Reaktion auf Befehle, die von dem Gerätetreiber 103 über das Frontend 212 erhalten werden, geschrieben und verändern sich während der Ausführung eines Verarbeitungstasks nicht. Das Frontend 212 legt der Ausführung jeden Verarbeitungstask zeitlich fest (engl. „schedules“). Jedes CTA ist mit einer bestimmten TMD 322 assoziiert für gleichzeitige Ausführung eines oder mehrerer Tasks. Ein einzelner GPC 208 mag des Weiteren eine Mehrzahl von Tasks gleichzeitig ausführen.
  • Ein (nicht gezeigter) Parameterspeicher speichert Ausführungsparameter (engl. „runtime Parameter“) (Konstante), die von jedem anderen Thread innerhalb des gleichen CTA (oder jeder beliebigen LSU 303) gelesen aber nicht geschrieben werden können. In einer Ausführungsform stellt der Gerätetreiber 103 Parameter für den Parameterspeicher bereit bevor er den SM 310 anweist, die Ausführung eines Tasks, der diese Parameter nutzt, zu beginnen. Jeder Thread innerhalb eines jeden CTA (oder jede Ausführungseinheit 302 innerhalb des SM 310) kann auf einen globalen Speicher durch eine Speicherschnittstelle 214 zugreifen. Bereiche des globalen Speichers mögen in dem L1-Cache 320 gespeichert werden.
  • Der lokale Registerspeicher 304 wird von jedem Thread als Arbeitsplatz (engl. „scratch space“) verwendet; jedes Register ist für die exklusive Nutzung eines Threads allokiert und Daten in jeder beliebigen der lokalen Registerspeicher 304 ist nur für den Thread zugreifbar, zu dem das Register allokiert ist. Der lokale Registerspeicher 304 kann als ein Registerspeicher implementiert werden, der physikalisch oder logisch in P Spuren (engl. „lanes“) aufgeteilt sind, wobei jede Spur irgendeine Anzahl von Einträgen hat (wobei jeder Eintrag zum Beispiel ein 32-Bit-Wort speichern mag). Eine Spur ist zu jedem der N Ausführungseinheiten 302 und P Load-Store-Einheiten LSU 303 zugeordnet, und entsprechende Einträge in unterschiedlichen Spuren können mit Daten für verschiedenen Threads, die das gleiche Programm ausführen, befüllt werden, um SIMD-Ausführung zu vereinfachen. Unterschiedliche Abschnitte der Spuren können zu unterschiedlichen Threadgruppen der G gleichzeitigen Threadgruppen allokiert werden, so dass ein gegebener Eintrag in dem lokalen Registerspeicher 304 nur für einen bestimmten Thread zugreifbar ist. In einer Ausführungsform werden gewisse Einträge in dem lokalen Registerspeicher 304 zum Speichern von Threadidentifikatoren reserviert, um eines der speziellen Register zu implementieren. Ein uniformer L1-Cache 375 speichert des Weiteren uniforme bzw. einheitliche oder konstante Werte für jede Spur der N Ausführungseinheiten 302 und P Lade-Speicher-Einheiten LSU 303.
  • Der geteilte bzw. gemeinsame Speicher 306 ist für Threads innerhalb eines einzigen CTA zugreifbar, mit anderen Worten ist jede beliebige Stelle in dem gemeinsamen Speicher 306 für jeden beliebigen Thread innerhalb des gleichen CTA (oder für jede beliebige Verarbeitungsmaschine innerhalb der SM 310) zugreifbar. Der gemeinsame Speicher 306 kann als ein gemeinsamer Registerspeicher oder als interner (engl. „on-chip“) gemeinsamer Cachespeicher mit einer Verbindung (engl. „interconnect“) implementiert sein, die es jede Verarbeitungsmaschine erlaubt, aus und zu jeder Stelle in dem gemeinsamen Speicher zu lesen und zu schreiben. In anderen Ausführungsformen mag ein gemeinsamer Zustandsraum auf einen pro-CTA-Bereich von externem (engl. „off-chip“) Speicher abbilden und in dem L1-Cache 320 zwischengespeichert werden. Der Parameterspeicher kann als ein designierter Abschnitt innerhalb des gleichen gemeinsamen Registerspeichers oder innerhalb des gleichen gemeinsamen Cachespeichers, die bzw. der den gemeinsamen Speicher 306 implementiert, oder als ein separater gemeinsamer Registerspeicher oder interner (engl. „on-chip“) Cachespeicher, zu dem die LSUs 303 Nur-Lese-Zugriff haben, implementiert werden. In einer Ausführungsform wird der Bereich, der den Parameterspeicher implementiert, auch dazu verwendet, die CTA-ID und Task-ID sowie CTA- und Netzdimensionen oder Warteschlangeposition zu speichern, wobei Abschnitte der speziellen Register implementiert werden. Jede LSU 303 in dem SM 310 ist an eine Einheitliche-Adressen-Mapping-Einheit 352 gekoppelt, die eine Adresse, die für Lade- und Speicherinstruktionen (engl. „load and store instructions“), die in einem einheitlichen Speicherraum spezifiziert sind, bereitgestellt worden sind, in eine Adresse in jedem distinkten Speicherraum umwandelt. Folglich mag eine Instruktion dazu verwendet werden, auf einen beliebigen der lokalen, gemeinsamen oder globalen Speicherräume durch Spezifizieren einer Adresse in dem vereinheitlichten Speicherraum zuzugreifen.
  • Der L1-Cache 320 in jedem SM 310 kann dazu verwendet werden, private einzelthreadbezogenen lokalen Daten (engl. „private per-thread local data“) und auch einzelapplikationsbezogene globalen Daten (engl. „perapplication global data“) zwischenzuspeichern. In einigen Ausführungsformen mögen die pro-CTA-geteilten-Daten in dem L1-Cache 320 zwischengespeichert werden. Die LSUs 303 sind an den gemeinsamen Speicher 306 und den L1-Cache 320 über eine Speicher-und-Cache-Verbindung (engl. „memory and cache interconnect“) 380 gekoppelt.
  • Logischer Threadidentifikator
  • Ein Eingangs-Arbeitspuffer, der mehrere Arbeitsstücke (engl. „work items“) aufweist, ist einem CTA zur Verarbeitung angewiesen. Der Arbeitspuffer mag Arbeitsstücke für eine Pixelkachel enthalten, wobei jedes Arbeitsstück einem bestimmten Abschnitt der Pixelkachel entspricht. Eine Anzahl von Threads, die gleich der Anzahl von Arbeitsstücken in dem Arbeitspuffer ist, wird an das „Eltern“-CTA befestigt. Wenn es einen Überschuss von Arbeitsstücken gibt, dann mag nur eine Untermenge von verfügbaren Arbeitsstücken an das „Eltern“-CTA befestigt werden. Es wird jedem Thread ein logischer Identifikator zugeordnet, der relativ zu dem Eltern-CTA ist, und die logische Identifikatoren inkrementieren in Folge, so dass die logischen Identifikatoren die Reihenfolge angeben, in welcher die Threads gestartet werden. Die logischen Identifikatoren sind in einem linearen statt in einem mehrdimensionalen Raum definiert. Wenn es benötigt wird, mögen die Threads zum Ausführen kritischer Abschnitte von Code basierend auf den logischen Identifikatoren konfiguriert sein mögen. Wenn die logischen Identifikatoren von jedem Thread verwendet werden, um in einen Eingangs-Arbeitspuffer hinein zu indexieren, können die Threads eines CTA (durch das Mapping von logisch auf physikalisch) in der Arbeitsreihenfolge ausgeführt werden. Es ist wichtig, dass die logischen Identifikatoren für die Threads innerhalb des SM 310 gespeichert werden, so dass der nächste Thread in der von den logischen Identifikatoren spezifizierten Sequenz bzw. Reihenfolge identifiziert werden kann, selbst wenn die Verarbeitungsarbeit außerhalb des SM 310 gespeichert ist. Dann kann die Verarbeitungsarbeit für den nächsten Thread in den SM 310 hinein geladen werden, um verarbeitet zu werden.
  • Um ein Mapping aus logischen Thread-IDs auf physikalischen Threads aufrechtzuerhalten, führen wir das Konzept eines Threadblocks ein, wobei jeder Threadblock einem festen Satz von physikalischen Threads (zum Beispiel 16 Threads pro Block) entspricht. Wenn neue Arbeit gestartet wird, allokieren wir physikalische Threads für einen Threadblock nach dem anderen. So müssen wir das Mapping nur auf pro-Block-Granularität aufrechterhalten, an Stelle von pro-Thread-Granularität. Die 4 ist ein Konzeptdiagramm, das Threadblöcke eines CTA darstellt, gemäß einer beispielhaften Ausführungsform der vorliegenden Offenbarung. Wie in der 4 gezeigt, mögen 16 CTAs innerhalb eines SM 310 ausgeführt werden und jedes CTA kann acht unterschiedliche Barrieren verwenden, die jeweils einen eindeutigen Barriereidentifikator haben. Eine Barriere mag „obere“ und „untere“ Barriereinstruktionen aufweisen, um den Anfang und das Ende eines kritischen Codeabschnittes innerhalb eines Programmes zu definieren. Eine einfachere Barriere weist nur eine „obere“ Barriereinstruktion auf. In einer Ausführungsform ist der Programmzähler der „oberen“ Barriereinstruktion zu einem Barriereidentifikator als ein Tag angehängt, um zu erlauben, dass der gleiche Barriereidentifikator an mehreren Stellen in einem einzigen Programm verwendet wird. Der Programmzähler unterscheidet in eindeutiger Weise zwischen verschiedenen Barrieren, wenn der gleiche Barriereidentifikator mehr als einmal in dem Programm auftritt bzw. vorkommt. In einer weiteren Ausführungsform wird ein inkrementierender Zähler verwendet, um eindeutige Barriereidentifikatoren zu erzeugen.
  • Es mag jedem CTA zumindest einen Threadblock allokiert sein, wobei ein Threadblock 16 Threads enthält. Wie in der 4 gezeigt, ist die maximale Anzahl von Threadblöcken, die in einem Ausführungsform zu einem CTA allokiert sein mögen, gleich acht. In einer weiteren Ausführungsform weist ein Threadblock 64 Threads auf und jedes CTA mag 512 oder mehr Threads enthalten. Sechzehn Warps sind zum Verarbeiten der Threadblöcke reserviert, wobei jeder Warp vier Threads enthält. Folglich ist jeder Threadblock eine Gruppe von 64 Threads, die Ressourcen aufweisen, die zusammen allokiert sind. Wie in der 4 gezeigt, mögen 128 Warps gleichzeitig von einem SM 310 verarbeitet werden und die vier Threadblöcke mögen an verschiedene Ausführungseinheiten 302 verteilt werden für Belastungsausgleich (engl. „load balancing“) unter den verschiedenen Ausführungseinheiten 302. In weiteren Ausführungsformen mögen verschiedene Anzähle von Threads in einem CTA enthalten sein und ein Threadblock mag eine unterschiedliche Anzahl von Threads enthalten.
  • Mit einem gegebenen logischen Identifikator, der mit einem bestimmten Thread assoziiert ist, mag die entsprechende Threadgruppe bestimmt werden, die den bestimmten Thread enthält. In einer Ausführungsform wird der Threadblock durch Trunkieren der niedrigsten vier Bits des logischen Identifikators berechnet. Die niedrigsten vier Bits des logischen Identifikators sind ein Offset innerhalb des Threadblocks. Der physikalische Identifikator für den Thread wird durch Mapping des Threadblocks auf eine entsprechende physikalische Identifikator-Basis und dann durch Verwenden des Offsets zum Lokalisieren der Verarbeitungsressourcen, die für den Thread allokiert sind, berechnet. Die hohen Bits des physikalischen Identifikators mögen zum Beispiel zum Bestimmen des Threadblocks verwendet werden und die niedrigeren Bits mögen zum Bestimmen des bestimmten Threads innerhalb des Threadblocks verwendet werden. Insgesamt ist der logische Identifikator ein CTA-bezogener Identifikator für jeden Thread in dem CTA und der physikalische Identifikator ist ein Hardware-bezogener Identifikator für jeden Thread, der von dem SM 310 für das CTA ausgeführt wird.
  • Scheduling von Barriereinstruktionen
  • Die 5A ist ein Blockdiagramm der Warp-Scheduler- und Instruktionseinheit 312 von 3C, gemäß einer beispielhaften Ausführungsform der vorliegenden Offenbarung. Wie in der 5A gezeigt, weist die Warp-Scheduler- und Instruktionseinheit 312 eine Instruktionscacheabrufeinheit 412 auf, die zum Abrufen von Cachezeilen konfiguriert ist, die die Instruktionen für Warps aus dem Instruktions-L1-Cache 370 enthalten. In einer Ausführungsform ist jede Cachezeile 512 Bits breit, wobei acht (64 Bits breite) Instruktionen in einer einzigen Cachezeile gespeichert sind. Die Instruktionscacheabrufeinheit 412 gibt die Instruktionen an die Instruktions-Scheduling-Einheit 420 aus.
  • Die Instruktions-Scheduling-Einheit 420 erhält die Instruktionen und Warp-Identifikatoren und geht zum Scheduling der Instruktionen zur Ausführung weiter. Die Instruktions-Scheduling-Einheit 420 mag konfiguriert sein zum Aufrechterhalten einer Priorität, die mit jedem Warp assoziiert ist, der auf dem SM 310 geschedulet ist, und zum Scheduling der abgerufenen Instruktionen basierend auf den Prioritäten. Die Scheduling-Einheit 425 mag zum Beispiel einen 6-Bit-Prioritätswert oder einen 10-Bit-Prioritätswert aufrechterhalten, der mit jedem von 16 unterschiedlichen Warps assoziiert sind, die zu jedem gegebenen Zeitpunkt auf dem SM 310 geschedulet sind. Die Priorität mag basierend auf verschiedenen Faktoren zugewiesen sein. In einer Ausführungsform mag Priorität darauf basiert sein, wann der Warp auf dem SM 310 geschedulet wurde (das heißt, dass der längst anstehende Warp die höchste Priorität haben mag). In anderen Ausführungsformen mag die Priorität für jeden Warp von dem Programm spezifiziert sein, das von den Instruktionen definiert ist, die von dem Warp ausgeführt werden, oder sie mag auf dem CTA basieren.
  • Die Instruktions-Scheduling-Einheit 420 weist eine Scheduling-Einheit 425, einen Barrierezustand 502, einen Threadzustand 510 und eine Barriere-Scheduling-Einheit 430 auf. Die Scheduling-Einheit 425 wählt nicht notwendigerweise die Instruktionen in der Prioritäts-Reihenfolge der verschieden Warps aus, weil eine oder mehrere der Instruktionen aufgrund einer Datenabhängigkeit nicht zur Ausführung bereit sein mögen oder weil alle die Threads, die an einer Barriereinstruktion teilnehmen, nicht die Barriereinstruktion erreicht haben. Wenn eine erste Instruktion erteilt werden kann, wird die Instruktion geschedulet und von der Scheduling-Einheit 425 ausgegeben. Wenn die erste Instruktion nicht erteilt werden kann, bestimmt die Scheduling-Einheit 425, ob eine Instruktion für einen anderen Warp für die jeweilige Instruktion erteilt werden mag. In einigen Fällen kann die erste Instruktion erteilt werden aber die erste Instruktion hat niedrigere Priorität, so dass eine andere Instruktion (aus einem anderen Warp) stattdessen erteilt werden mag. In allen Fällen werden die Instruktionen für jeden individuellen Thread eines Warps in der Reihenfolge erteilt, in welcher die Instruktionen für die jeweiligen individuellen Threads von der Warp-Scheduler- und Instruktions-Einheit312 erhalten werden.
  • Die Scheduling-Einheit 425 hält ein Zustandsmodell des SM 310 aufrecht, das basierend auf den erteilten Instruktionen aktualisiert wird. Das Zustandsmodell ermöglicht, dass die Scheduling-Einheit 425 Instruktionen basierend auf dynamischer Ausführung des Programmes und auf der Verfügbarkeit von Ressourcen innerhalb des SM 310 auswählt. Ein SM 310 oder eine funktionelle Einheit innerhalb eines SM 310 oder die Textureinheit 315, die die Instruktion ausführen wird, mag zum Beispiel als eine Ressource identifiziert werden, die für die Instruktion benötigt wird, und die Verfügbarkeit der Ressource mag von der Scheduling-Einheit 425 verwendet werden.
  • Zustandsinformationen werden von der Scheduling-Einheit 425 und von der Barriere-Scheduling-Einheit 430 aufrechterhalten und verwendet. Zustandsinformationen werden insbesondere für Barrieren und für Threads benötigt. Der Barrierezustand weist ein oder mehrere von den folgenden Feldern auf: eine Referenzanzahl, ein Rescan-Flag, ein statisches/dynamisches/inaktives Feld und einen Barriere-Typ (zum Beispiel einfacher konditioneller, kritischer Abschnitt, geordneter kritischer Abschnitt). Eine Barriere fängt in einem inaktiven Zustand an. Wenn zumindest ein Thread die obere Barriereinstruktion erreicht, wechselt der Zustand von inaktiv zu statisch. Die Scheduling-Einheit 425 ändert den Zustand von statisch zu dynamisch, wenn die Barriere „bereit“ ist, ausgeführt zu werden. Die Barriere-Scheduling-Einheit 430 ändert den Zustand von dynamisch zu inaktiv, wenn die Ausführung der Barriere „erledigt“ ist.
  • Der Threadzustand wird im Threadzustand 510 gespeichert und weist ein oder mehrere von den folgenden Feldern auf: Barriereidentifikator, ein Identifikator des Eltern-CTA, der logische Identifikator, ein Erledigt-Flag und ein Wach/Schlafend-Flag. Die Verwendung des Threadzustands 510 und des Barrierezustands wird in den folgenden Absätzen detaillierter beschrieben.
  • Wenn die Scheduling-Einheit 425 ein erstes Vorkommnis einer bestimmten Barriereinstruktion erkennt, das heißt, dass ein erster Thread eines CTA während Ausführung eines Programmes die bestimmte Barriereinstruktion erreicht hat, aktualisiert die Scheduling-Einheit 425 den Zustand des von der Barriereinstruktion spezifizierten Barriereidentifikators von „inaktiv“ zu „statisch“ (angenommen, dass der erste Thread eine Inkrementierung des BarriereMitgliedschaft-Zählers bewirkt, der mit der Referenzanzahl verglichen wird). Es ist nicht notwendig, dass alle Threads eines CTA an jeder Barriere teilnehmen, die einem CTA allokiert ist. Jeder Thread, der an einer bestimmten Barriere teilnimmt, spezifiziert einen Barriereidentifikator, der der bestimmten Barriere entspricht, und ein Thread mag jeweils an einer Barriere teilnehmen. In einer Ausführungsform mögen Threads Teilnahme an einer bestimmten Barriere unter Verwendung eines Intruktionsprädikats anzeigen. Threads, die nicht an einer Barriere teilnehmen, mögen zur Ausführung von Instruktionen geschedulet werden, die von der Scheduling-Einheit 425 erhalten werden. Threads, die an einer Barriere teilnehmen, können keine Instruktionen ausführen, die in Programmreihenfolge nach der Barriereinstruktion sind, bevor alle teilnehmenden Threads die Barriereinstruktion erreicht haben.
  • Die Scheduling-Einheit 425 ist dazu konfiguriert, den Barrierezustand von statisch zu dynamisch zu ändern, wenn die „Mitgliedschaft“ einer bestimmten Barriere beendet ist. Eine Vielfalt an verschiedenen Bedingungen mögen verwendet werden zum Bestimmen, ob die Mitgliedschaft beendet ist. Eine erste Bedingung ist, dass die Anzahl von Threads, die die Barriereinstruktion erreicht haben, gleich der Anzahl von Threads ist, die dem Eltern-CTA zugeteilt ist. Eine zweite Bedingung ist, dass die Anzahl von Threads, die die Barriereinstruktion erreicht haben, gleich der für die Barriere spezifizierten Referenzanzahl ist. Eine dritte Bedingung ist, dass die Anzahl von Threads, die die Barriereinstruktion erreicht haben und an der Barriere teilnehmen, gleich der für die Barriere spezifizierten Referenzanzahl ist. Der Referenzwert ist von dem Programm spezifiziert und gibt die Anzahl von Threads an, die es erwartet wird, an der Barriere ankommen werden. Ein Thread, der nicht an einer Barriere teilnimmt, speichert Null für den Barriereidentifikator im Threadzustand 510. Die Scheduling-Einheit 425 mag dazu konfiguriert sein, einen Barriere-Mitgliedschaftszähler zu inkrementieren, der der spezifischen Barriere entspricht, wenn Threads die Barriereinstruktion erreichen, um zu bestimmen, ob die Mitgliedschaft für die Barriere beendet ist.
  • Als jeder teilnehmende Thread der Barriereinstruktion erreicht, werden Zustandsdaten für den Thread aktualisiert, die im Threadzustand 510 gespeichert sind. Der Threadzustand ist spezifisch zu „schlafend“ gesetzt, was angibt, dass der Thread angehalten (das heißt pausiert) ist und keine Instruktionen ausführt. Ein Thread, der sich zurückgezogen hat, verbleibt „wach“ und mag die Ausführung fortsetzen. Wenn die Mitgliedschaft einst beendet ist, ändert die Scheduling-Einheit 425 den Zustand des Barriereidentifikators zu „dynamisch“ und gibt den CTA-Identifikator und den Barriereidentifikator an die Barriere-Scheduling-Einheit 430 aus. Die Barriere-Scheduling-Einheit 430 ist konfiguriert zum Scheduling von Threads zur Ausführung, die an Barriereinstruktionen teilnehmen.
  • Barriereinstruktionen mögen verwendet werden, um geordnete und nicht geordnete kritische Abschnitte eines Programmes abzugrenzen. Eine obere Barriereinstruktion tritt gerade vor der ersten Instruktion eines kritischen Codeabschnittes auf und eine untere Barriereinstruktion, die den gleichen Barriereidentifikator wie die obere Barriereinstruktion hat, tritt unmittelbar nach der letzten Instruktion des kritischen Codeabschnittes auf. Die TABELLE 1 stellt ein Beispiel eines geordneten kritischen Code-Abschnittes dar. TABELLE 1
    BARRIER.TOP.OCS // Starte geordneten kritischen Abschnitt
    LD R0, [address]; // Lade CTA-Zähler in R0 hinein, für lokale Arbeit
    IMAD R2, R0, R1, R3; // Inkrementiere unter Verwendung von Thread-Werten
    ST [address], R2 // Speichere den CTA-Zähler aus R2 im Speicher
    BARRIER.BOT.OCS; // Beende den geordneten kritischen Abschnitt
  • Die Barriereinstruktionen mögen auch zum Abgrenzen kritischer Codeabschnitte verwendet werden, die keine Ordnungsrestriktionen haben, das heißt nicht geordnete kritische Codeabschnitte. Nicht geordnete Codeabschnitte mögen von der Barriere-Scheduling-Einheit 430 in einer arbiträren Reihenfolge geschedulet werden, oder die logischen Identifikatoren mögen zum Scheduling der kritischen Codeabschnitte in der Reihenfolge der logischen Identifikatoren verwendet werden, sobald die geordneten kritischen Codeabschnitte geschedulet sind. Die Barriere-Scheduling-Einheit 430 wird nur die (geordneten und nicht geordneten) kritischen Codeabschnitte zur Ausführung von den Threads schedulen, die an der Barriere teilnehmen. In einer Ausführungsform grenzt eine Barriereinstruktion keinen kritischen Codeabschnitt ab und wird als eine (einfache) konditionelle Barriere verwendet, um die Ausführung von teilnehmenden Threads bei einer Barriereinstruktion zu synchronisieren. Mit anderen Worten gibt es statt einer oberen und einer unteren Barriere einfach eine einzige Barriereinstruktion.
  • Die Barriere-Scheduling-Einheit 430 schedulet die Threads, die an einer Barriere teilnehmen, durch Aufwecken eines ersten Threads, wobei der erste Thread der teilnehmende Thread ist, der den niedrigsten Wert des logischen Identifikators hat (es sei denn, eine andere Ordnungskonvention verwendet wird). Die Barriere-Scheduling-Einheit 430 aktualisiert den Threadzustand 510, um anzugeben, dass der erste Thread wach ist. Folglich wird die Scheduling-Einheit 425 den ersten Thread zur Ausführung schedulen, da der erste Thread jetzt zur Ausführung berechtigt ist. Wenn der erste Thread die untere Barriere erreicht, wird die Barriere-Scheduling-Einheit 430 von der Scheduling-Einheit benachrichtigt und der Threadzustand 510 wird entweder von der Barriere-Scheduling-Einheit 430 oder von der Scheduling-Einheit 425 aktualisiert, um anzugeben, dass der erste Thread schläft. Wenn der erste Thread die untere Barriere erreicht, wird das Erledigt-Flag im Threadzustand 510 auch entweder von der Barriere-Scheduling-Einheit 430 oder von der Scheduling-Einheit 425 aktualisiert, um anzugeben, dass der erste Thread fertig ist.
  • Die Barriere-Scheduling-Einheit 430 weckt dann den nächsten teilnehmenden Thread auf, und gibt damit die Ausführung des kritischen Codeabschnittes für den nächsten teilnehmenden Thread frei. Die Barriere-Scheduling-Einheit 430 fährt mit dem Aufwecken jedes teilnehmenden Threads in logischer Reihenfolge fort, bis der letzte teilnehmende Thread die untere Barriere erreicht. Wenn der letzte teilnehmende Thread die untere Barriere erreicht, ist die Ausführung der Barriere komplett und die Barriere-Scheduling-Einheit 430 aktualisiert den Threadzustand 510 zum Angeben, dass alle teilnehmende Threads wach sind. Die Barriere-Scheduling-Einheit 430 mag bestimmen, dass der letzte teilnehmende Thread geschedulet worden ist, wenn die Suche nach einem nächsten teilnehmenden Thread scheitert. Die Scheduler-Einheit 425 aktualisiert den Barrierezustand zum Angeben, dass der Barriereidentifikator „inaktiv“ (engl. „idie“) ist, zum Beispiel weder „statisch“ noch „dynamisch“. Die Scheduling-Einheit 425 ist dann in der Lage, einen oder mehrere der teilnehmenden Threads zur Ausführung in beliebiger Reihenfolge zu schedulen.
  • Scheduling von indexierten Barriereinstruktionen
  • In einigen Fällen müssen Threads, die an der Barriere teilnehmen, nicht seriell ausgeführt werden. Mit anderen Worten mögen Subgruppen der teilnehmenden Threads parallel ausgeführt werden. Die Threads innerhalb jeder Subgruppe werden seriell ausgeführt. Eine Technik zum Verbessern der Leistung bzw. Performance ist, jede Subgruppe zu einem unterschiedlichen Barriereidentifikator zuzuweisen, so dass die verschiedenen Subgruppen parallel ausgeführt werden mögen. Jeder von den teilnehmenden Threads mag auf einen einzigen Barriereidentifikator Bezug nehmen, so dass die teilnehmenden Threads synchronisiert werden, bevor die verschiedenen Subgruppen beginnen, parallel ausgeführt zu werden. Wie früher erläutert, wird eine Referenzanzahl für jede Barriere spezifiziert. Oft kann die Anzahl von Threads in jeder Subgruppe nicht notwendigerweise einfach bestimmt werden. Folglich mag das Verwenden eines unterschiedlichen Barriereidentifikators für jede Subgruppe keine praktikable Technik sein, um parallele Ausführung zu erlauben. Stattdessen mag eine indexierte Barriereinstruktion, wie sie hierin weiter beschrieben wird, zum Erlauben paralleler Ausführung von Subgruppen zumindest eines Threads verwendet werden, wobei jeder Thread an der gleichen indexierten Barriere teilnehmen.
  • Indexierte Barriereinstruktionen separieren den Barriereidentifikator in zwei (oder mehr) Felder, wobei ein erstes Feld einen Barriereidentifikator spezifiziert, die mit der Referenzanzahl assoziiert ist, und ein zweites Feld einen Subbarriereindex spezifiziert. Zum Beispiel mag ein 6-Bit Namenstelle (engl. „name space“) in ein 4.2-Format geteilt sein, wobei 4 Bits den primären Barriereidentifikator spezifizieren und 2 Bits einen Subbarriereindex spezifizieren, was 16 verschiedene primäre Barrieren erlaubt, die jeweils vier verschiedene Subbarrieren enthalten mögen. Folglich kann jede der 16 primären Barrieren bis zur 4-Weg-Parallelität unterstützen. Der Subbarriereindex differenziert zwischen den verschiedenen Subgruppen der teilnehmenden Threads und mag in einem Pro-Thread-Register gespeichert sein. Der primäre Barriereidentifikator mag als ein Befehlscodefeld bereitgestellt sein. In einer Ausführungsform sind sowohl der primäre Barriereidentifikator als auch der Subbarriereindex in einem Pro-Thread-Register gespeichert, wobei der Subbarriereindex sich in den niedrigeren Bits des Registers befindet.
  • Während Ausführung mögen die verschiedenen Subgruppen parallel ausgeführt werden, nachdem die teilnehmenden Threads an der indexierten Barriere synchronisiert sind. Innerhalb jeder Subgruppe von Threads, die den gleichen Subbarriereidentifikator spezifizieren, werden die teilnehmenden Threads aber seriell ausgeführt. Zu jedem Zeitpunkt nach der Synchronisation für die indexierte Barriere mag ein Thread, der jeder von den verschiedenen Subbarrieren gehört, zur Ausführung zu einer Zeit ausgewählt werden, und die ausgewählten Threads mögen parallel ausgeführt werden, so dass zwei oder mehr Threads, die an der indexierten Barriere teilnehmen, parallel ausgeführt werden mögen. In einer Ausführungsform mögen vier Threads parallel ausgeführt werden. In einer Ausführungsform mögen Gruppen von Threads, die als dazu fähig bekannt sind, parallel ausgeführt zu werden, wie zum Beispiel die vier Threads eines Pixel-Vierers (engl. „pixel quad“) (zum Beispiel 2x2, 1x4 oder 4x1 Pixel), an Stelle von einzelnen Threads gesteuert und ausgeführt werden.
  • Es werden keine separaten Referenzzahlen für jeden der Subbarriereidentifikatoren benötigt. In einigen Fällen mag die Berechnung einer Referenzzahl für jeden der Subbarriereinstruktion schwierig sein, weil die Anzahl von Threads, die die Subbarriere erreichen sollen, nicht bekannt ist. Deshalb ermöglicht die Fähigkeit zur Verwendung einer indexierten Barriere, die eine Referenzzahl für mehrere Subgruppen spezifiziert, die parallele Ausführung jeder Subgruppe ohne Berechnung einer Referenzanzahl für jede Subgruppe. Im Gegensatz erfordert die Verwendung einer separaten (nicht indexierten) Barriere für jede Subgruppe, so dass die Subgruppen parallel ausgeführt werden mögen, dass eine Referenzanzahl für jede der Subgruppen spezifiziert wird.
  • Die 5B ist ein konzeptuelles Diagramm, das Subbarriereindexe auf ein Pixelgitter 540 mappt, welches durch mehrere Grafikprimitive geschnitten wird, gemäß einer beispielhaften Ausführungsform der vorliegenden Offenbarung. Das Pixelgitter 540 ist ein 8x8 Gitter, das ferner in vier Abschnitten mit 4x4 Pixeln geteilt ist. In weiteren Ausführungsformen weist jeder Abschnitt ein oder mehrere Pixel aus benachbarten oder nicht benachbarten Pixeln im Pixelgitter 540 auf. Ein geordneter Abschnitt von kritischem Code mag zum Ausblenden verdeckter Flächen konfiguriert sein (zum Beispiel Z-Pufferung oder Tiefenüberprüfung). Beim Durchführen von Ausblenden verdeckter Flächen sollten die Grafikprimitive, die das Pixelgitter 540 schneiden, für jedes Pixel in der gleichen Reihenfolge verarbeitet werden, um zu vermeiden, dass visuelle Artefakte produziert werden. Wie in der 5B gezeigt, schneiden drei Primitive 542, 544 und 546 das Pixelgitter 540. Angenommen, dass die drei Primitive 542, 544 und 546 an der gleichen Tiefe sind, mag eine Veränderung der Reihenfolge, in welcher die Primitive während Ausblendens verdeckter Flächen verarbeitet werden, unterschiedliche Bilder produzieren.
  • Die TABELLE 2 stellt ein Beispiel eines geordneten kritischen Codeabschnittes dar, der verwendet werden mag, um eine Operation zum Ausblenden verdeckter Flächen zu implementieren. TABELLE 2
    BARRIER.TOP.OCS.IDX BAR_03, R8 // Starte geordneten kritischen Abschnitt
    LD R0, [pixel_z address]; // Lade Pixeltiefe aus dem Framepuffer in R0 hinein
    MATH R2, R0, prim_pixel_z; // Vergleiche die berechnete Primitivtiefe mit R0
    ST R2, [pixel_z address] // Speichere das Ergebnis in den Framepuffer hinein
    BARRIER.BOT; // Beende den geordneten kritischen Abschnitt
  • Die Barriere, BARRIER.TOP.OCS.IDX, ist dazu konfiguriert, vier verschiedene Indexe zu verwenden, die auf verschiedene 4x4 Pixel-Abschnitte des Pixelgitters 540 gemappt sind, wie in der 5B gezeigt. BAR_03 ist der Barriereidentifikator und R8 ist ein Eingaberegister, der einen Index aufweist.
  • Threads werden zum Verarbeiten jedes Pixels allokiert und, als jeder teilnehmender Thread an der BARRIER.TOP.OCS.IDX ankommt, wird die Anzahl von Threads, die die indexierte Barriere erreicht haben, inkrementiert und der Threadzustand 510 für den teilnehmenden Thread wird auf „schlafend“ gesetzt. In einer Ausführungsform werden die Referenzanzahl und der Barriereinformationszustand, die die Anzahl von teilnehmenden Threads angeben, die die Barriere erreicht haben, in dem Barrierezustand 502 für den Barriereidentifikator aufrechterhalten, der das erste Feld zu dem primären Barriereidentifikator gesetzt und den Subbarriereindex auf 0 gesetzt hat.
  • Unter Annahme eines 8-Bit Barriereidentifikators in 6.2-Format (6-Bit primärerer Barriereidentifikator und 2-Bit Indexfeld), wobei der primäre Barriereidentifikator gleich 3 (000011 im binären Format) ist, wird die Referenzanzahl für den Barriereidentifikator 0x3 < < 2 (00001100 im binären Format) spezifiziert, unter der Annahme eines 2-Bit Subbarriereindexes. Wenn der primäre Barriereidentifikator mit den 2-Bit Subbarriereindexen kombiniert wird, werden die Barriereidentifikatoren 00001100, 00001101, 00001110 und 00001111 (das heißt 12, 13, 14 und 15 im dezimalen Format) produziert, so dass ein eindeutiger Barriereidentifikator jedem der Subbarriereindexe entspricht. In einer weiteren Ausführungsform mögen die Subbarriereindexe Pixelschirmkoordinaten entsprechen. Zum Beispiel mögen die zwei niedrigsten Bits von (x,y) Pixelkoordinaten zum Spezifizieren eines 4-Bit Subbarriereindexes verwendet werden, wobei der Subbarriereindex = ((pixel.y & 3) < < 2) | (pixel.x & 3).
  • Aus der Sicht der Barriere-Scheduling-Einheit 430 entspricht eine indexierte Barriere mit einem 2-Bit Subbarriereindexfeld vier verschiedenen Barrieren, wobei eine unterschiedliche Subgruppe mit jeder der unterschiedlichen Barrieren assoziiert ist. Folglich kann die Barriere-Scheduling-Einheit 430 die Subgruppen zur parallelen Ausführung schedulen, während der Threads innerhalb jeder Subgruppe seriell ausgeführt werden. Wenn alle Threads, die an der indexierten Barriere teilnehmen, die indexierte Barriere erreichen (das heißt, wenn die Anzahl gleich der Referenzanzahl ist), ändert die Scheduling-Einheit 425 den Zustand der vier Barriereidentifikatoren in „dynamisch“ und gibt den CTA-Identifikator und die Barriereidentifikatoren an die Barriere-Scheduling-Einheit 430 aus. Um parallele Ausführung der Subgruppen zu ermöglichen, wird ein separater Barriereidentifikator von der Scheduling-Einheit 425 an die Barriere-Scheduling-Einheit 430 für jeden Subbarriereindex ausgegeben, der von zumindest einem der teilnehmenden Threads spezifiziert sind. Subbarrieren mögen als eine Subgruppe gesteuert bzw. kontrolliert werden durch Ausblenden des Subbarriereindexes für den gesamten Barriere-Nahmen. Dies erlaubt zum Beispiel, dass die Scheduler-Einheit 425 auf Ausführung aller Subbarrieren zu warten, bevor sie irgendeine von den Subbarrieren freigibt.
  • Wenn die gleiche Pixelstelle mehr als einmal in einer Subgruppe von teilnehmenden Threads auftritt, werden die entsprechenden Threads als Teil der gleichen Subgruppe in logischer Reihenfolge ausgeführt werden, welche die Eingabereihenfolge ist (das heißt die Reihenfolge, in welcher die Primitive 542, 544 und 546 erhalten wurden). Wenn der letzte teilnehmende Thread in einer bestimmten Subgruppe die untere Barriere erreicht, aktualisiert die Barriere-Scheduling-Einheit 430 den Threadzustand 510 um anzugeben, dass alle die teilnehmenden Threads in der bestimmten Subgruppe „wach“ sind. Die Barriere-Scheduling-Einheit 430 aktualisiert auch den Barrierenzustand 502 für den bestimmten Barrierenidentifikator, der der Subgruppe entspricht, von „dynamisch“ zu „inaktiv“ (das heißt weder „statisch“ noch „dynamisch“). Wenn alle die teilnehmenden Threads in den verschiedenen Subgruppen geschedulet worden sind, wird die Scheduling-Einheit 425 den Barrierenzustand aktualisiert haben, um anzugeben, dass die vier Barrierenidentifikatoren (zum Beispiel 12, 13, 14 und 15) „inaktiv“ sind (das heißt weder „statisch“ noch „dynamisch“). Die Scheduling-Einheit 425 ist dann in der Lage, einen oder mehrere von den teilnehmenden Threads zur Ausführung in beliebiger Reihenfolge zu schedulen.
  • Die Barriere-Scheduling-Einheit 430 mag auch konfiguriert sein zum Scheduling von exklusiven kritischen Codeabschnitten und geordneten kritischen Codeabschnitten mit einer nicht blockierenden unteren (indexierten oder nicht indexierten) Barriere. Die Barriere-Scheduling-Einheit 430 schedulet einen ersten Thread, der an einem exklusiven kritischen Codeabschnitt teilnimmt, dadurch, dass sie erst darauf wartet, dass die Ausführung jeglicher anderen kritischen Codeabschnitte oder exklusiven kritischen Codeabschnitte beendet wird. Die Barriere für einen exklusiven kritischen Codeabschnitt wird zur exklusiven Ausführung geschedulet. Ein exklusiver kritischer Codeabschnitt mag ein geordneter kritischer Codeabschnitt oder ein nicht geordneter kritischer Codeabschnitt sein, der exklusiv ist. Beachte, dass Threads, die nicht an einer Barriere teilnehmen, gleichzeitig mit den Threads ausgeführt werden mögen, die den exklusiven kritischen Codeabschnitt ausführen. Ein exklusiver kritischer Codeabschnitt mag verwendet werden, wenn Konflikte in Bezug auf Zugriff auf Ressourcen zwischen den Threads vorkommen mögen, die an unterschiedlichen Barrieren teilnehmen.
  • Die Barriere-Scheduling-Einheit 430 schedulet Threads, die an einem kritischen Codeabschnitt mit einer nicht blockierenden unteren Barriere teilnehmen, durch Erlauben, dass die Threads die Ausführung der nachfolgenden Instruktionen ausführen, die gleich nach der unteren Barriere sind, ohne darauf zu warten, dass die teilnehmenden Threads den kritischen Codeabschnitt ausführen. Wenn der Threadzustand 510 für einen teilnehmenden Thread von der Barriere-Scheduling-Einheit 430 aktualisiert wird, um anzugeben, dass der Thread wach ist, verbleibt der Thread nach dem Erreichen der unteren Barriere wach. Die Scheduling-Einheit 425 ist dann in der Lage zum Scheduling teilnehmender Threads, die die Ausführung des kritischen Codeabschnittes abgeschlossen haben, zur Ausführung gleichzeitig mit einem anderen teilnehmenden Thread (in jeder Subgruppe für eine indexierte Barriere), der gegenwärtig den kritischen Codeabschnitt ausführt. Wenn alle die teilnehmenden Threads die untere Barriere erreicht haben, ist die Ausführung der Barriere fertig und die Barriere-Scheduling-Einheit 430 aktualisiert den Barrierenzustand 502, um anzuzeigen, dass der Barriereidentifikator (oder die Barriereidentifikatoren für eine indexierte Barriere) weder „statisch“ noch „dynamisch“ ist.
  • In einer Ausführungsform führt die Scheduling-Einheit 425 eine dynamische Barriere-Anzeigetafelprüfung (engl. „dynamic barrier scoreboard check“) aus, um zu bestimmen, ob eine erste Instruktion erteilt werden kann, bevor die erste Instruktion an die Decodierungseinheit 450 ausgegeben wird. Wenn die erste Instruktion mit einer Barriereidentifikator assoziiert ist, wartet die Scheduling-Einheit 425 mit der Erteilung der ersten Instruktion in den folgenden Fällen: Wenn eine Barriere (in einem statischen oder dynamischen Zustand) den gleichen Barriereidentifikator und ein unterschiedliches Tag in Vergleich mit der ersten Instruktion hat, oder wenn eine Barriere (in dem dynamischen Zustand) den gleichen Identifikator und das gleiche Tag hat.
  • Die Decodierungseinheit 450 erhält die nächste Instruktion, die ausgegeben werden soll, von der Instruktions-Scheduling-Einheit 420. Die Decodierungseinheit 450 führt eine volle Decodierung der Instruktion durch und sendet die decodierte Instruktion an die Absendungseinheit (engl. „dispatch unit“) 470. Wiederum mögen Instruktion in einigen Ausführungsformen zweifach bzw. dual oder vierfach erteilt werden, und die Decodierungseinheit 450 mag separate Logik für jede erteilte Instruktion implementieren. Die Absendungseinheit 470 implementiert einen FIFO und schreibt die decodierten Werte an die lokale Registerdatei 304 zur Ausführung von den Ausführungseinheiten 302 oder den Lade/Speicher-Einheiten 303. In Ausführungsformen, die gleichzeitig mehrere Instruktionen erteilen, mag die Decodierungseinheit 470 jede Instruktion an einen unterschiedlichen Abschnitt von den funktionalen Einheiten des SM 310 erteilen. Der Anzeigetafeleinheit 480 managt und verfolgt die Anzahl von Instruktionen, die pro Threadgruppe decodiert und abgesendet worden sind.
  • In einigen Fällen ist es nicht notwendig, dass alle die teilnehmenden Threads die Barriereinstruktion erreichen, bevor einige von den Threads mit der Ausführung eines nicht geordneten kritischen Codeabschnittes beginnen. Eine Barriere mag zum Beispiel als eine „Temposchwelle“ funktionieren, um eine Gruppierung von einigen Threads anzuregen, ohne dabei zu verlangen, dass die Threads darauf warten, dass alle die Threads, die an der Barriere teilnehmen, die Barriere erreichen. Folglich mag zumindest einen Teil von Threads, von denen es erwartet wird, dass sie lokalisierte Speicherzugriffsmuster haben, zwecks verbesserter Cachezugriffsleistung gruppiert werden. Eine indexierte Barriere mag zum Ausführen von Code verwendet werden, der nicht geordnet kritisch ist, wenn eine Subbarrierenindex für verschiedene Versionen der Barriere von der Scheduling-Einheit 425 erzeugt werden.
  • Die Scheduling-Einheit 425 mag dazu konfiguriert sein, eine indexierte Barriere in den „dynamischen“ Zustand überzuleiten und einer „Version“ von der Barriere zu erzeugen, ohne notwendigerweise darauf zu warten, dass alle die Threads, die an der Barriere teilnehmen, die indexierte Barriereinstruktion erreichen. Jede indexierte Barriere mag spezifizieren, ob Versionierung für die Barriere freigegeben ist. Ein Timeout (das heißt eine maximale Zeitdauer) mag für Barrieren spezifiziert sein, die zum Steuern davon verwendet werden, wann ein neuer Subbarrierenindex erzeugt wird, um eine neue Version der Barriere zu erzeugen. Der Timeout wird seit dem ersten teilnehmenden Thread, der die Barriere erreicht, oder seit dem neusten teilnehmenden Thread, der die Barriere erreicht, gemessen. In einer Ausführungsform mag die Scheduling-Einheit 425 darauf warten, dass eine minimale Anzahl von teilnehmenden Threads die indexierte Barriere erreicht, bevor sie einen neuen Subbarrierenindex für eine Subgruppe der teilnehmenden Threads erzeugt. Der Timeout und/oder die minimale Anzahl teilnehmender Threads sind Versionserzeugungsbedingungen.
  • Wenn Versionierung für eine indexierte Barriere freigegeben ist und die Versionserzeugungsbedingung erfüllt ist, leitet die Scheduling-Einheit 425 den Barrierenidentifikator, der dem erzeugten Subbarrierenindex entspricht, von dem „statischen“ zu dem „dynamischen“ Zustand über und setzt den Subbarrierenindex, auf den jeder Thread in der Versionssubgruppe Bezug nimmt, zu dem Subbarrierenindex. Wenn eine versionierte indexierte Barriere verwendet wird, werden die Indexe nicht mehr von dem durch den Benutzer bereitgestellten Indexregister (zum Beispiel dem Eingaberegister R8, das in der Tabelle 2 gezeigt ist) kontrolliert, sondern werden stattdessen von der Scheduling-Einheit 425 in einer seriellen Art und Weise erzeugt. Die indexierte Barriere wird damit verarbeitet, ohne darauf zu warten, dass alle die teilnehmenden Threads die Barriere erreichen. Der Subbarrierenindex wird bei 0 initialisiert und wird für jede Version (Modulo der Indexanzahl) inkrementiert, die erzeugt wird. Weil die Anzahl von eindeutigen Subbarrierenindexe begrenzt ist, mag die Scheduling-Einheit 425 darauf warten müssen, dass eine Subgruppe, die der zuvor erzeugten Version entspricht, mit der Ausführung fertig wird (das heißt von „dynamisch“ zu „inaktiv“ übergeht), bevor sie den Subbarrierenindex zum Erzeugen einer anderen Version verwendet. Ausführung von Subgruppen (das heißt von Versionen) mag für jeden Subbarrierenindex parallel ausgeführt werden. Wenn die Anzahl gleich der Referenzanzahl wird, wird die letzte Version erzeugt, und wenn alle die teilnehmenden Threads ausgeführt sind, ist die Ausführung der indexierten Barriere fertig.
  • Die 5C ist ein Blockdiagramm von einem Teil der Scheduling-Einheit 425 und der Barriere-Scheduling-Einheit 430 von 5A, gemäß einer beispielhaften Ausführungsform der vorliegenden Offenbarung. Eine Threadbarriere-Ankunftsverfolgungseinheit 500 aktualisiert die Barrierezustandsinformationen, die im Barrierezustand 502 gespeichert sind, für jede Barriere, die zu einem CTA allokiert ist. Wie früher erklärt, geben die Barrierezustandsinformationen an, welche Barriereidentifikatoren „statisch“, „dynamisch“ oder „inaktiv“ (weder „statisch“ noch „dynamisch“) sind. Wenn ein Barriereidentifikator von „statisch“ zu „dynamisch“ übergeht, werden der Barriereidentifikator und der CTA-Identifikator an den FIFO 505 ausgegeben. Falls die Barriere eine indexierte Barriere ist und die Scheduling-Einheit nicht zum Erzeugen von Versionen konfiguriert ist, wird ein Barriereidentifikator mit dem gleichen primären Barriereidentifikator einmal für jeden eindeutigen Subbarriereindex ausgegeben. Wenn die Scheduling-Einheit 425 zum Erzeugen von Versionen für eine indexierte Barriere konfiguriert ist, wird der Barriereidentifikator für den der Version entsprechenden Subbarriereindex ausgegeben, wenn die Version erzeugt wird, und der Subbarriereindex mag recycelt werden, falls die Anzahl von Versionen größer als die Anzahl der eindeutigen Subbarriereindexe ist und die Version inaktiv ist. Als jeder Thread des CTAs, der an der Barriere teilnimmt, die Barriereinstruktion erreicht, aktualisiert die Scheduling-Einheit 425 den Zustand des teilnehmenden Threads, der im Threadzustand 510 gespeichert ist, um anzugeben, dass der teilnehmende Thread „schlafend“ ist.
  • Dier FIFO 505 puffert dynamische Barrieren, wenn kein Ausführungsslot in den Barriereausführungsslots 515 verfügbar ist. In einer Ausführungsform weisen die Barriereausführungsslots 515 16 Slots auf, die jeweils von einer dynamischen Barriere belegt werden mögen. Wenn ein Slot in den Barriereausführungsslots 515 verfügbar ist, wird eine dynamische Barriere aus dem FIFO 505 abgehoben (engl. „popped“) und in den Slot hinein eingefügt. Die Barriere-Arbitrierungseinheit 520 arbitriert zwischen den verschiedenen dynamischen Barrieren, die die Slots der Barriereausführungsslots 515 belegen. Verschiedene Prioritätsschemen mögen von der Arbitrierungseinheit 520 verwendet werden, um zwischen den verschiedenen dynamischen Barrieren zu arbitrieren. Die Barriere-Arbitrierungseinheit 520 versorgt die Threadauswahleinheit 530 mit einer dynamischen Barriere, aus welcher ein Thread zum Scheduling von der Threadauswahleinheit 530 ausgewählt werden mag.
  • Die Threadauswahleinheit 530 wählt Threads in der Reihenfolge aus, die von dem logischen Identifikator spezifiziert wird, der mit jedem Thread in einem Threadarray assoziiert ist (das heißt zu einem CTA allokiert ist). Die Threadauswahleinheit 530 greift auf die Barriereteilnahmeverfolgungsinformationen 532 zu, um zu bestimmen, welche Threads an der dynamischen Barriere teilnehmen. Die Threadauswahleinheit 530 greift auf den Threadzustand 510 und auf die Barrierezustandsinformationen zu, die in dem Barrierezustand 502 gespeichert sind, um jegliche spät ankommende teilnehmende Threads zu identifizieren.
  • Nicht alle Threads in dem einen Threadblock oder in den mehreren Threadblöcken, die zu einem CTA allokiert sind, nehmen notwendigerweise an jeder Barriere teil, die von dem CTA verwendet wird. Wie früher erklärt, sind die Barrieren von Barriereidentifikatoren spezifiziert und jeder Thread gibt durch Bezugnahme auf den primären Barriereidentifikator, der einer indexierten Barriere entspricht, an, ob er an einer oder mehreren von den indexierten Barrieren teilnimmt oder nicht. Die Threadauswahleinheit 530 identifiziert die teilnehmenden Threads einmal für jede Subgruppe während Verarbeitung der indexierten Barriere und geht dann weiter zum Auswählen jedes teilnehmenden Threads, der den gleichen Subbarriereindex hat, zur seriellen Ausführung. Die Threadauswahleinheit 530 überspringt während des Auswahlprozesses nicht teilnehmende Threads.
  • Bevor dem Auswählen eines ersten Threads zu Ausführung für eine bestimmte Barriere, bestimmt die Threadauswahleinheit 530, ob die Barriere eine exklusive Barriere ist, die einen exklusiven kritischen Codeabschnitt abgrenzt. Falls die Barriere exklusiv ist, dann bestimmt die Threadauswahleinheit 530, ob irgendwelche andere Threadarrays einen kritischen Codeabschnitt oder einen exklusiven kritischen Codeabschnitt ausführen, und wenn dem so ist, wartet die Threadauswahleinheit 530 bis Threads in diesen Threadarrays fertig ausgeführt sind, bevor sie einen ersten Thread zur Ausführung für die exklusive Barriere auswählt. In einer Ausführungsform hebt der FIFO 505 keine exklusive Barriere ab, während eine dynamische Barriere einen Slot in den Barriereausführungsslots 515 belegt, und der FIFO 505 hebt keine Barriere ab, während eine exklusive Barriere einen Slot in den Barriereausführungsslots 515 belegt.
  • Die Threadauswahleinheit 530 mag eine Ausführungsmaske basierend auf den teilnehmenden Threads für jede Subgruppe erzeugen. Teilnehmende Threads spezifizieren den Barriereidentifikator, der zu dem mit der Barriereinstruktion bereitgestellten Barriereidentifikator passt. Die Threadauswahleinheit 530 durchsucht die Ausführungsmaske, um den ersten Thread in Reihenfolge der logischen Identifikatoren zu finden, der zur Ausführung ausgewählt werden soll, bis alle Threads in der Subgruppe ausgewählt worden sind. Als jeder teilnehmender Thread ausgewählt wird, wird das Bit der Ausführungsmaske, das dem teilnehmenden Thread entspricht, gelöscht und der Thread wird als erledigt markiert. In einer Ausführungsform, wenn mehrere Threadblocks zu einem CTA allokiert sind, erzeugt die Threadauswahleinheit 530 eine Ausführungsmaske für einen Threadblock nach dem anderen, wobei die Anzahl von Bits in der Ausführungsmaske auf die Anzahl der Threads in einem Threadblock beschränkt wird.
  • Wenn die Threadauswahleinheit 530 einen teilnehmenden Thread zur Ausführung auswählt, aktualisiert die Threadauswahleinheit 530 den Zustand des Threads, der in dem Threadzustand 510 gespeichert ist, um anzugeben, dass der Thread „wach“ ist. Die Scheduling-Einheit 425 wird dann den Thread zur Ausführung ausgeben und fährt mit Ausgeben des Threads für jede Instruktion in dem kritischen Codeabschnitt fort, bis die untere Barriere erreicht wird. Wenn die untere Barriere erreicht wird, informiert die Scheduling-Einheit 425 die Threadauswahleinheit 530, und die Threadauswahleinheit 530 bestimmt, ob die Barriere erfordert, dass der Thread darauf wartet, dass alle andere an der Barriere teilnehmenden Threads den kritischen Codeabschnitt ausführen, bevor sie zum Ausführen einer Instruktion weitergeht, die in der Programmreihenfolge nach dem kritischen Codeabschnitt ist (das heißt, die Threadauswahleinheit 530 bestimmt, ob die untere Barriere eine nicht blockierende untere Barriere ist). Wenn die Barriere eine nicht blockierende Barriere ist, mag die Threadauswahleinheit 530 einen nächsten teilnehmenden Thread zur Ausführung auswählen, ohne den gegenwärtig ausgewählten teilnehmenden Thread zum „Schlafen“ zu bringen. Stattdessen wird der Zustand des nächsten teilnehmenden Threads, der in dem Threadzustand 510 gespeichert ist, zu „wach“ aktualisiert, und jegliche teilnehmende Threads, die Ausführung des kritischen Codeabschnittes abgeschlossen haben, fahren mit Ausführung nachfolgender Instruktionen des Programmes in Programmreihenfolge fort. Die Threadauswahleinheit 530 setzt auch das jeweilige Erledigt-Flag, indem jeder teilnehmende Thread die untere Barriere erreicht.
  • In einer Ausführungsform werden Barrieren verwendet, um sicherzustellen, dass Threads für ein bestimmtes CTA, das Daten unter Verwendung der Textureinheit 315 verarbeitet, durchgeführt werden, ohne zu erlauben, dass Threads aus einem anderen CTA sich einmischen bzw. intervenieren. Sicherstellen, dass die Threads für ein CTA von der Textureinheit 315 zusammen verarbeitet werden, erhöht die Wahrscheinlichkeit für Cachetreffer (engl. „cache hits“), da die Texturzugriffe innerhalb eines CTA lokalisiert sind. Die Textureinheit 315 ist ein Beispiel einer gemeinsam genutzten Ressource und die Barrieren mögen zum Kontrollieren verwendet werden, welche Threads auf eine gemeinsam genutzte Ressource oder auf eine Ressource, die von Lokalität profitieren mag, zugreifen. Während die Threads nicht in einer bestimmen Reihenfolge ausgeführt werden müssen, stellt das Abgrenzen der Textur-Ladeinstruktionen, die Texturdaten aus dem Speicher lesen, als exklusive kritische Codeabschnitte einen Mechanismus zum Erhöhen der Wahrscheinlichkeit bereit, dass die Texturlesungen (engl. „texture reads“) in der L1,5-Cache 335 treffen werden. Instruktionen in exklusiven kritischen Codeabschnitten, die eine spezifische Ressource (zum Beispiel die Textureinheit 315) kontrollieren, sind dazu fähig, gleichzeitig mit kritischen Codeabschnitten und/oder exklusiven kritischen Codeabschnitten, die nicht die gleiche Ressource verwenden, ausgeführt zu werden. Die Barriereausführungsslots 515 mögen einen Slot, der für Barriereabgrenzungsinstruktionen dediziert ist, die von der Textureinheit 315 ausgeführt werden, oder Slots für jegliche Ressourcen, die lokalisierten kontrollierten Zugriff bevorzugen, aufweisen. Threads, die von der Textureinheit 315 ausgeführt werden, mögen zur Ausführung gleichzeitig mit Threads, die von den Ausführungseinheiten 302 ausgeführt werden, geschedulet werden. Scheduling-Priorität mag für die verschiedenen Barriereidentifikatoren spezifiziert werden, und Textur-Ladeinstruktionen, die unter Verwendung von Barriereinstruktionen abgegrenzt sind, mögen oder mögen nicht mit höherer Priorität als andere Barrieren geschedulet werden.
  • Die 5D stellt ein Flussdiagramm 550 von einem Verfahren zum Scheduling indexierter Barriereinstruktionen zur Ausführung dar, gemäß einer beispielhaften Ausführungsform der vorliegenden Offenbarung. Wie früher beschrieben, mag der Subbarriereindex von einem Pro-Thread-Register spezifiziert sein oder er mag von der Scheduling-Einheit 425 dynamisch erzeugt werden, wenn eine Versionserzeugungsbedingung erfüllt ist. Obwohl die Verfahrensschritte in Zusammenhang mit den Systemen von den 1, 2, 3A-3C, 5A und 5C beschrieben werden, werden Fachleute mit durchschnittlichen Kenntnissen verstehen, dass jedes System, das zum Ausführen der Verfahrensschritte in beliebiger Reihenfolge konfiguriert ist, sich innerhalb des Umfangs der Offenbarung befindet.
  • Das Verfahren 550 beginnt bei Schritt 555, wo die zu einem CTA allokierten Threads mit logischen Identifikatoren assoziiert werden. Die logischen Identifikatoren sind auf physikalische Identifikatoren gemappt, auf welche die SMs 310 während Ausführung der Threads Bezug nehmen. Bei Schritt 560 wird die Ausführung des Programmes initiiert und die Scheduling-Einheit 425 erhält Instruktionen. Für Instruktionen vor der indexierten Barriereinstruktion setzt die Scheduling-Einheit 425 die Ausführung des Programmes durch Ausgabe der Instruktionen an die Decodierungseinheit 450 fort. Bei Schritt 565 erreicht zumindest ein Thread, der an der indexierten Barriere teilnimmt, die Barriereinstruktion, und bei Schritt 570 wird die Ausführung des teilnehmenden Threads angehalten. Die Scheduling-Einheit 425 aktualisiert die Anzahl von Threads, die die indexierte Barriereinstruktion erreicht haben, für jeden teilnehmenden Thread, der angehalten wird. Wenn die indexierte Barriereinstruktion für den ersten Thread eines CTA erreicht wird, aktualisiert die Scheduling-Einheit 425 auch den Zustand des primären Barriereidentifikators, um anzugeben, dass die Barriere „statisch“ ist. Wenn ein Thread, der nicht an der indexierten Barriereinstruktion teilnimmt, die indexierte Barriereinstruktion erreicht, setzt der Thread die Ausführung des Programmes fort.
  • Bei Schritt 572 bestimmt die Scheduling-Einheit 425, ob die indexierte Barriere geschedulet werden kann. Falls Versionierung nicht freigegeben ist, kann die indexierte Barriere geschedulet werden, wenn alle die teilnehmenden Threads die Barriereinstruktion erreicht haben (das heißt, die Anzahl ist gleich der Referenzanzahl). Falls Versionierung freigegeben ist, dann kann die indexierte Barriere geschedulet werden, wenn die Versionserzeugungsbedingung, die für die Barriere spezifiziert ist, erfüllt ist (das heißt, eine minimale Anzahl von teilnehmenden Threads haben die Barriere erreicht oder ein Timeout ist aufgetreten).
  • Falls die Scheduling-Einheit 425 beim Schritt 572 bestimmt, dass die indexierte Barriere nicht geschedulet werden kann, dann geht die Ausführung des Programmes bei Schritt 588 weiter. Anderenfalls, bei jedem der parallelen Schritten 585, wird der kritische Codeabschnitt für einen Thread in einer Subgruppe ausgeführt, die einem der Subbarriereindexe entspricht. Der kritische Codeabschnitt für die Threads in der Subgruppe mögen in einer seriellen Art und Weise ausgeführt werden. Eine oder mehrere von den Subgruppen mögen parallel ausgeführt werden, wie in der 5D gezeigt. Wenn Versionierung nicht freigegeben ist, mag der kritische Codeabschnitt ein geordneter Codeabschnitt sein, weil die indexierte Barriere nicht geschedulet werden, bevor alle die teilnehmenden Threads die indexierte Barriere erreicht haben. Versionierung sollte nicht für geordnete kritische Codeabschnitte freigegeben werden, da die teilnehmenden Threads nicht notwendigerweise in der Reihenfolge der logischen Identifikatoren ausgeführt werden mögen. Wenn die teilnehmenden Threads in den Subgruppen die Ausführung des kritischen Codeabschnittes beenden, geht die Ausführung des Programmes beim Schritt 588 weiter.
  • Die 6A stellt ein Flussdiagramm 600 von einem Verfahren zum Scheduling indexierter Barriereinstruktionen zur Ausführung basierend auf logischen Identifikatoren dar, gemäß einer beispielhaften Ausführungsform der vorliegenden Offenbarung. Obwohl die Verfahrensschritte in Zusammenhang mit den Systemen von den 1, 2, 3A-3C, 5A und 5C beschrieben werden, werden Fachleute mit durchschnittlichen Kenntnissen verstehen, dass jedes System, das zum Ausführen der Verfahrensschritte in beliebiger Reihenfolge konfiguriert ist, sich innerhalb des Umfangs der Offenbarung befindet.
  • Das Verfahren 600 beginnt bei Schritt 605, wo die zu einem CTA allokierten Threads mit logischen Identifikatoren assoziiert werden. Die logischen Identifikatoren sind auf physikalische Identifikatoren gemappt, auf welche die SMs 310 während Ausführung der Threads Bezug nehmen. Bei Schritt 610 wird die Ausführung des Programmes initiiert und die Scheduling-Einheit 425 erhält Instruktionen. Bei Schritt 615 bestimmt die Scheduling-Einheit 425, ob eine Instruktion eine Barriereinstruktion ist, und wenn dem nicht so ist, setzt die Scheduling-Einheit 425 die Ausführung des Programmes bei Schritt 658 durch Ausgeben der Instruktion an die Decodierungseinheit 450 fort.
  • Falls die Scheduling-Einheit 425 beim Schritt 615 feststellt, dass die Instruktion eine Barriereinstruktion ist, und wenn dem so ist, dann aktualisiert die Scheduling-Einheit 425 bei Schritt 616 die Barrieremitgliedschaft gemäß der für die Barriere verwendeten Mitgliedschaftsbedingung. Wenn die Barriereinstruktion für den ersten Thread eines CTA erreicht wird, aktualisiert die Scheduling-Einheit 425 auch den Zustand der Barriere zum Angeben, dass die Barriere „statisch“ ist (angenommen, dass der Thread eine Inkrementierung des Barrieremitgliedschaftszählers bewirkt, der mit der Referenzanzahl verglichen wird). Dann bestimmt die Scheduling-Einheit 425 bei Schritt 425, ob der Thread an der indexierten Barriereinstruktion teilnimmt. Falls die Barriereinstruktion eine indexierte Barriereinstruktion ist, mag das von jedem Thread spezifizierte Subbarriereindexfeld des Barriereidentifikators ignoriert werden, um Teilnahme zu bestimmen. Falls der Thread nicht an der indexierten Barriereinstruktion teilnimmt, dann geht die Scheduling-Einheit 425 zu Schritt 658 weiter, und der Thread setzt die Ausführung des Programmes fort. Anderenfalls nimmt der Thread an der indexierten Barriereinstruktion teil und die Scheduling-Einheit 425 aktualisiert bei Schritt 620 den Zustand des Threads als „schlafend“. Wenn eine indexierte Barriereinstruktion den Anfang eines kritischen (geordneten oder nicht geordneten) Codeabschnittes abgrenzt und Versionierung nicht freigegeben ist, sollte die Mitgliedschaftsbedingung der Scheduling-Einheit 425 erfordern, dass alle die teilnehmenden Threads in dem CTA die indexierte Barriereinstruktion erreichen, bevor sie erlauben, dass irgendeiner der teilnehmenden Threads den kritischen Codeabschnitt ausführt.
  • Bei Schritt 622 bestimmt die Scheduling-Einheit 425, ob die Mitgliedschaft gemäß der Vielfalt von Bedingungen vollständig ist, die zum Bestimmen, dass die Mitgliedschaft vollständig ist, verwendet werden mag. Wenn Versionierung nicht für die indexierte Barriere freigegeben ist, muss die Scheduling-Einheit 425 nicht darauf warten, dass alle teilnehmenden Threads die Barriereinstruktion erreichen, bevor sie erlaubt, dass eine Subgruppe der teilnehmenden Threads zur Ausführung geschedulet wird. Mit anderen Worten muss die Scheduling-Einheit 425 nicht darauf warten, dass die Mitgliedschaft vollständig ist. Falls die Mitgliedschaft nicht vollständig ist, dann bestimmt die Scheduling-Einheit 425 bei Schritt 623, ob die Versionserzeugungsbedingung erfüllt ist. Die Versionserzeugungsbedingung kann nicht erfüllt werden, wenn Versionierung nicht für die indexierte Barriere freigegeben ist. Wenn beim Schritt 623 die Versionserzeugungsbedingung nicht erfüllt ist, dann verbleiben die teilnehmenden Threads schlafend, die die indexierte Barriere erreicht haben, während die Scheduling-Einheit 425 die Ausführung des Programmes fortsetzt. Die Versionserzeugungsbedingung mag erfüllt werden, wenn Versionserzeugung für die indexierte Barriere freigegeben ist und wenn ein Timeout abgelaufen ist oder wenn eine minimale Anzahl von teilnehmenden Threads die indexierte Barriere erreicht hat. Falls die Scheduling-Einheit 425 beim Schritt 623 bestimmt, dass die Versionserzeugungsbedingung erfüllt ist, dann aktualisiert die Scheduling-Einheit 425 bei Schritt 624 den Subbarriereindex für die Barriere. Die Scheduling-Einheit 425 liefert den Subbarriereindex an jeden teilnehmenden Thread, so dass der Thread den korrekten Barriereidentifikator im Threadzustand 510 speichern kann. Wenn die teilnehmenden Threads zur Ausführung bereit sind, wird der Barriereidentifikator + Index an die Scheduling-Einheit 430 gesendet und der Index wird für die nächste Version aktualisiert. Wenn der nächste Index gegenwärtig verwendet wird, dann verhindert die Anzeigetafeleinheit 480 ein Ausgeben bis der nächste Index frei ist. Bei Schritt 627 aktualisiert die Scheduling-Einheit 425 den Zustand des dem Subbarriereindex entsprechenden Barriereidentifikators von „statisch“ zu „dynamisch“ und gibt den Barriereidentifikator und den CTA-Identifikator des Threads an die Barriere-Scheduling-Einheit 430 aus, bevor sie zu Schritt 655 weitergeht.
  • Wenn die Scheduling-Einheit 425 beim Schritt 622 bestimmt, dass die Mitgliedschaft vollständig ist, dann bestimmt die Scheduling-Einheit 425 bei Schritt 625, ob Versionserzeugung freigegeben ist. Wenn Versionserzeugung freigegeben ist, dann geht die Scheduling-Einheit 425 weiter zu Schritt 624, um die letzte Version für die Barriere zu erzeugen. Anderenfalls aktualisiert die Scheduling-Einheit 425 bei Schritt 627 den Zustand der Barriereidentifikatoren, die dem primären Barriereidentifikator entsprechen, von „statisch“ zu „dynamisch“ und gibt die Barriereidentifikatoren, die jedem der Subbarriereindexe entsprechen, und den CTA-Identifikator des Threads an die Barriere-Scheduling-Einheit 430 aus, bevor sie zu Schritt 655 weitergeht.
  • Bei Schritt 655 wählt die Barriere-Scheduling-Einheit 430 teilnehmende Threads innerhalb jeder Subgruppe zur seriellen Ausführung aus. Ein Thread aus jeder verschiedenen Subgruppe mag parallel ausgeführt werden. Wenn alle die teilnehmenden Threads die Ausführung des kritischen Codeabschnittes abgeschlossen haben, wird die Programmausführung bei Schritt 658 fortgesetzt. Zusätzliche Details des Schrittes 655 werden in Zusammenhang mit der 6B beschrieben. In einer Ausführungsform, falls eine Barriere „aufgehängt“ (engl. „hung“) wird, so dass die Threads nicht ausgeführt werden können, kann die Barriere zurückgesetzt werden in genau der gleichen Art und Weise, wie ungültig gemachte Barrieren zurückgesetzt werden können, das heißt mit einer speziellen Instruktion.
  • In einer Ausführungsform wird eine konditionelle Barriere dazu verwendet, die Ausführung von teilnehmenden Threads bei einer Barriereinstruktion zu synchronisieren, und beim Schritt 620 wird der Threadzustand für jeden teilnehmenden Thread zu schlafend gesetzt, und wenn die Mitgliedschaft beim Schritt 622 vollständig ist, aktualisiert die Scheduling-Einheit 425 den Zustand der Barriere von „statisch“ zu „dynamisch“ und aktualisiert den Zustand von allen teilnehmenden Threads, die im Threadzustand 510 gespeichert sind, zu „wach“. Beim Schritt 655 setzen die teilnehmenden Threads dann die Ausführung des Programmes fort, und die Barriere-Scheduling-Einheit 430 aktualisiert den Zustand der Barriere zu weder „statisch“ noch „dynamisch“, das heißt sie gibt an, dass die Ausführung der Barriere für zumindest einen Teil der Threads abgeschlossen ist.
  • Die 6B stellt ein Verfahren zur Durchführung des in der 6A gezeigten Schrittes 655 dar, gemäß einer beispielhaften Ausführungsform der vorliegenden Offenbarung. Obwohl die Verfahrensschritte in Zusammenhang mit den Systemen von den 1, 2, 3A-3C, 5A und 5C beschrieben werden, werden Fachleute mit durchschnittlichen Kenntnissen verstehen, dass jedes System, das zum Ausführen der Verfahrensschritte in beliebiger Reihenfolge konfiguriert ist, sich innerhalb des Umfangs der Offenbarung befindet.
  • Bei Schritt 630 wählt die Barriere-Scheduling-Einheit 430 einen Thread zur Ausführung basierend auf den logischen Identifikatoren aus, die mit den Threads assoziiert sind, die an der Barriere teilnehmen. Der Zustand des ausgewählten Threads wird von „schlafend“ zu „wach“ aktualisiert, so dass der Thread zur Ausführung auswählbar ist. Zusätzliche Details des Schrittes 630 werden in Zusammenhang mit der 6C beschrieben. Wenn Versionierung freigegeben ist, mag die Barriere-Scheduling-Einheit 430 Threads zur Ausführung auswählen, die in Vergleich mit den logischen Identifikatoren außer der Reihe sind.
  • Bei Schritt 635 werden die Instruktionen innerhalb des kritischen Codeabschnittes von der Absendungseinheit 470 abgesandt und für den ausgewählten Thread ausgeführt. Bei Schritt 636 erhält die Scheduling-Einheit 312 die untere Barriereinstruktion, die mit dem Barriereidentifikator assoziiert ist, und der Zustand des Threads wird zum Setzen des Erledigt-Flags aktualisiert. Bei Schritt 638 bestimmt die Scheduling-Einheit 312, ob die untere Barriereinstruktion eine blockierende untere Barriereinstruktion ist. Wenn die Barriere-Scheduling-Einheit 430 beim Schritt 638 bestimmt, dass die untere Barriereinstruktion blockierend ist, dann bestimmt die Barriere-Scheduling-Einheit 430 bei Schritt 640, ob ein anderer Thread, der an der Barriere teilnimmt, den kritischen Codeabschnitt ausführen muss. Falls ein anderer Thread den kritischen Codeabschnitt ausführen muss, dann aktualisiert die Barriere-Scheduling-Einheit bei Schritt 643 den Zustand des Threads, der die untere Barriereinstruktion erreicht hat, von „wach“ zu „schlafend“, so dass der Thread nicht zur Ausführung auswählbar ist. Anderenfalls aktualisiert die Barriere-Scheduling-Einheit 430 bei Schritt 650 den Threadzustand 510 zum Angeben, dass alle Threads in der Subgruppe „wach“ sind und der Index erneut verwendet werden kann. In einer weiteren Ausführungsform aktualisiert die Barriere-Scheduling-Einheit 430 nicht den Threadzustand 510 zum Angeben, dass die Threads in einer Subgruppe wach sind, bis alle die Threads die untere Barriereinstruktion erreicht haben. Bei Schritt 652 entfernt die Barriere-Scheduling-Einheit 430 den Barriereidentifikator (für die Subgruppe) und den CTA-Identifikator von einem Ausführungsslot in den Barriereausführungsslots 515, und aktualisiert den Zustand eines Barriereidentifikators zum Anzeigen, dass die indexierte Barriere weder „statisch“ noch „dynamisch“ ist. Beachte, dass indem jede Subgruppe die Ausführung abschließt, wird der Zustand des bestimmten Barriereidentifikators aktualisiert, der der Subgruppe entspricht.
  • Die Scheduling-Einheit 425 geht dann zum Fortsetzen der Ausführung des Programmes weiter. Während Ausführung des kritischen Codeabschnittes für eine CTA-Barriere mögen andere Threads von anderen Barrieren des gleichen CTA sowie Threadbarrieren von anderen CTAs auch die Ausführung von anderem Code fortsetzen. Falls die Barriere aber exklusiv ist, mögen nur Instruktionen, die nicht innerhalb kritischer Codeabschnitte enthalten sind, für andere Barrieren ausgeführt werden.
  • Die 6C stellt ein Verfahren zur Durchführung des in der 6A gezeigten Schrittes 630 dar, gemäß einer beispielhaften Ausführungsform der vorliegenden Offenbarung. Obwohl die Verfahrensschritte in Zusammenhang mit den Systemen von den 1, 2, 3A-3C, 5A und 5C beschrieben werden, werden Fachleute mit durchschnittlichen Kenntnissen verstehen, dass jedes System, das zum Ausführen der Verfahrensschritte in beliebiger Reihenfolge konfiguriert ist, sich innerhalb des Umfangs der Offenbarung befindet.
  • Der Schritt 630 wird von der Barriere-Scheduling-Einheit 430 für jeden Scheduling-Zyklus durchgeführt. Bei Schritt 660 identifiziert die Barriere-Scheduling-Einheit 430 jegliche anstehende Barriere in den Barriereausführungsslots 515, die eine dynamische Barriere speichern und einen nächsten Thread haben, der geschedulet werden kann. Wenn eine exklusive Barriere ausgeführt wird, dann wartet die Barriere-Scheduling-Einheit 430, bis die Ausführung der exklusiven Barriere abgeschlossen ist, bevor sie jegliche anstehende Barriere identifiziert. Bei Schritt 662 wählt die Barriere-Scheduling-Einheit 430 die dynamische Barriere mit höchster Priorität aus. Bei Schritt 665 bestimmt die Barriere-Scheduling-Einheit 430, ob die ausgewählte dynamische Barriere eine exklusive Barriere ist, und wenn dem so ist, wartet die Barriere-Scheduling-Einheit 430 bei Schritt 668, bis irgendeine andere Barriere, die (geordnete oder nicht geordnete) kritische Codeabschnitte abgrenzt, nicht von Threads ausgeführt werden, bevor sie zu Schritt 670 weitergeht. Es wird verstanden werden, dass die Barriere-Scheduling-Einheit 430 darauf warten mag, dass alle teilnehmenden Threads die Ausführung des anderen kritischen Codeabschnittes abschließen, oder dass sie nur darauf warten mag, dass Threads, die gegenwärtig ausgeführt werden, die Ausführung des kritischen Codeabschnittes anschließen, bevor die Threads, die an der exklusiven Barriere teilnehmen, (seriell) ausgeführt werden. Es wird verstanden werden, dass mehrere nicht exklusive Barrieren für mehrere CTAs parallel ausgeführt werden mögen, wobei aber nur jeweils eine exklusive Barriere nach der anderen ausgeführt werden mag.
  • Bei Schritt 670 identifiziert die Barriere-Scheduling-Einheit 430 die Threads, die an der ausgewählten Barriere teilnehmen, durch Bestimmen, ob jeder Thread die Barriere namentlich spezifiziert. Bei Schritt 675 sucht die Barriere-Scheduling-Einheit 430 nach dem nächsten teilnehmenden Thread durch Prüfen der logischen Identifikatoren, die mit jedem teilnehmenden Thread assoziiert sind, der den kritischen Codeabschnitt noch nicht ausgeführt hat. Bei Schritt 680 aktualisiert die Barriere-Scheduling-Einheit 430 den Threadzustand, der im Threadzustand 510 für die ausgewählte teilnehmende Threadsubgruppe gespeichert ist, um anzugeben, dass der Thread „wach“ ist, bevor zu Schritt 635 fortgefahren wird. Es wird verstanden werden, dass der Schritt 670 einmal pro Threadblock oder einmal pro Zyklus durchgeführt werden mag, um die teilnehmenden Threads in der Subgruppe zu identifizieren. Weil die Barriere-Scheduling-Einheit 430 zum Aufrechterhalten einer Ausführungsgruppe für jede Subgruppe konfiguriert sein mag. Die Barriere-Ausführungs-Einheit 430 weckt in effizienter Art und Weise die teilnehmenden Threads in logischer Reihenfolge auf, als jeder vorherige teilnehmende Thread die Ausführung des kritischen Codes abschließt und die Ausführungsmaske für jede Subgruppe aktualisiert. In einer Ausführungsform wird die Ausführungsmaske für jeden Threadblock berechnet.
  • Während verschiedene Ausführungsformen oben beschrieben worden sind, sollte es verstanden werden, dass sie nur als Beispiele und nicht beschränkend dargelegt worden sind. Folglich sollten die Breite und der Umfang einer bevorzugten Ausführungsform nicht von irgendeiner der oben beschriebenen beispielhaften Ausführungsformen beschränkt werden, sollte aber nur in Übereinstimmung mit den nachfolgenden Patentansprüchen und deren Äquivalenten definiert werden.

Claims (16)

  1. Ein Verfahren aufweisend: Initiieren einer Ausführung einer Mehrzahl von Threads, um Instruktionen eines Programmes zu verarbeiten, das eine Barriereinstruktion aufweist; für jeden Thread in der Mehrzahl von Threads: Anhalten der Ausführung von Instruktionen, wenn der Thread die Barriereinstruktion erreicht; Bestimmen, dass die Barriereinstruktion zur Ausführung geschedulet werden mag, wenn entweder eine Minimumanzahl von teilnehmenden Threads, die kleiner ist als eine Anzahl von Threads, die an der Barriereinstruktion teilnehmen, die Barriereinstruktion erreicht hat oder wenn eine maximale Zeitdauer abgelaufen ist; Assoziieren einer ersten Subgruppe der Threads in der Mehrzahl von Threads mit einem ersten Subbarriereindex; Assoziieren einer zweiten Subgruppe der Threads in der Mehrzahl von Threads mit einem zweiten Subbarriereindex; und ein serielles Ausführen von Threads in der ersten Subgruppe und ein serielles Ausführen von Threads in der zweiten Subgruppe, wobei zumindest ein Thread in der ersten Subgruppe parallel mit zumindest einem Thread in der zweiten Subgruppe ausgeführt wird.
  2. Das Verfahren gemäß Anspruch 1, ferner aufweisend für jeden Thread in der Mehrzahl von Threads: Bestimmen, ob der Thread an der Barriereinstruktion teilnimmt, wenn der Thread während Ausführung des Threads die Barriereinstruktion erreicht.
  3. Das Verfahren gemäß Anspruch 1, wobei das Bestimmen, dass die Barriereinstruktion zur Ausführung geschedulet werden mag, ein Bestimmen aufweist, dass eine Thread-Ankunftsanzahl gleich einer Referenzanzahl ist, wobei die Thread-Ankunftsanzahl aktualisiert wird, wenn jeder Thread, der an der Barriereinstruktion teilnimmt, die Barriereinstruktion während Ausführung des Threads erreicht.
  4. Das Verfahren gemäß Anspruch 3, wobei die Referenzanzahl gleich der Anzahl von Threads ist, die an der Barriereinstruktion teilnehmen.
  5. Das Verfahren gemäß Anspruch 1, wobei das Bestimmen, dass die Barriereinstruktion zur Ausführung geschedulet werden mag, ein Vergleichen der maximalen Zeitdauer mit einer Verzögerung, seitdem ein erster teilnehmender Thread in der Mehrzahl von Threads die Barriereinstruktion erreichte, aufweist.
  6. Das Verfahren gemäß Anspruch 1, wobei das Bestimmen, dass die Barriereinstruktion zur Ausführung geschedulet werden mag, ein Vergleichen der maximalen Zeitdauer mit einer Verzögerung, seitdem ein neuster teilnehmender Thread in der Mehrzahl von Threads die Barriereinstruktion erreichte, aufweist.
  7. Das Verfahren gemäß Anspruch 1, ferner aufweisend ein Assoziieren der Threads mit logischen Identifikatoren, die auf physikalische Identifikatoren gemappt sind, wobei auf die physikalischen Identifikatoren von einem Mehrthread-Verarbeitungskern während Ausführung der Threads Bezug genommen werden.
  8. Das Verfahren gemäß Anspruch 1, ferner aufweisend: Erzeugen eines Tags basierend auf einem Programmzähler oder einer Speicheradresse, der bzw. die der Barriereinstruktion entspricht; und Assoziieren des Tags mit der Barriereinstruktion.
  9. Das Verfahren gemäß Anspruch 1, wobei der erste Subbarriereindex und der zweite Subbarriereindex basierend auf Pixel-Bildschirmkoordinaten oder auf Speicheradressen von Inhalten, die entsprechend den Pixel-Bildschirmkoordinaten gespeichert sind, bestimmt werden.
  10. Das Verfahren gemäß Anspruch 1, wobei die Barriereinstruktion einen kritischen Codeabschnitt abgrenzt.
  11. Das Verfahren gemäß Anspruch 1, wobei jeder Thread einen Barriereidentifikator für jede Barriereinstruktion spezifiziert, für welche der Thread teilnimmt.
  12. Ein Verarbeitungssubsystem aufweisend: eine Instruktions-Scheduling-Einheit, die konfiguriert ist zum: Initiieren einer Ausführung einer Mehrzahl von Threads, um Instruktionen eines Programmes zu verarbeiten, das eine Barriereinstruktion aufweist; für jeden Thread in der Mehrzahl von Threads: Anhalten der Ausführung von Instruktionen, wenn der Thread die Barriereinstruktion erreicht; Bestimmen, dass die Barriereinstruktion zur Ausführung geschedulet werden mag, wenn entweder eine Minimumanzahl von teilnehmenden Threads, die kleiner ist als eine Anzahl von Threads, die an der Barriereinstruktion teilnehmen, die Barriereinstruktion erreicht hat oder wenn eine maximale Zeitdauer abgelaufen ist; Assoziieren einer ersten Subgruppe der Threads in der Mehrzahl von Threads mit einem ersten Subbarriereindex; Assoziieren einer zweiten Subgruppe der Threads in der Mehrzahl von Threads mit einem zweiten Subbarriereindex; und einen Mehrthread-Verarbeitungskern, der konfiguriert ist zum seriellen Ausführen von Threads in der ersten Subgruppe und zum seriellen Ausführen von Threads in der zweiten Subgruppe, wobei zumindest ein Thread in der ersten Subgruppe parallel mit zumindest einem Thread in der zweiten Subgruppe ausgeführt wird.
  13. Das Verarbeitungssubsystem gemäß Anspruch 12, wobei die Instruktions-Scheduling-Einheit ferner konfiguriert ist zum Bestimmen, für jeden Thread in der Mehrzahl von Threads, ob der Thread an der Barriereinstruktion teilnimmt, wenn der Thread während Ausführung des Threads die Barriereinstruktion erreicht.
  14. Das Verarbeitungssubsystem gemäß Anspruch 12, wobei die Instruktions-Scheduling-Einheit ferner konfiguriert ist zum Bestimmen, bevor dem Bestimmen, dass die Barriereinstruktion zur Ausführung geschedulet werden mag, dass eine Thread-Ankunftsanzahl gleich einer Referenzanzahl ist, wobei die Thread-Ankunftsanzahl aktualisiert wird, wenn jeder Thread, der an der Barriereinstruktion teilnimmt, die Barriereinstruktion während Ausführung des Threads erreicht.
  15. Das Verarbeitungssubsystem gemäß Anspruch 14, wobei die Referenzanzahl gleich der Anzahl von Threads ist, die an der Barriereinstruktion teilnehmen.
  16. Das Verarbeitungssubsystem gemäß Anspruch 12, wobei die Instruktions-Scheduling-Einheit ferner konfiguriert ist zum Bestimmen des ersten Subbarriereindexes und des zweiten Subbarriereindexes basierend auf Pixel-Bildschirmkoordinaten oder auf Speicheradressen von Inhalten, die entsprechend den Pixel-Bildschirmkoordinaten gespeichert sind.
DE102013114072.6A 2013-03-15 2013-12-16 System und Verfahren zum Hardware-Scheduling von indexierten Barrieren Active DE102013114072B4 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US13/844,541 US9442755B2 (en) 2013-03-15 2013-03-15 System and method for hardware scheduling of indexed barriers
US13/844,541 2013-03-15

Publications (2)

Publication Number Publication Date
DE102013114072A1 DE102013114072A1 (de) 2014-09-18
DE102013114072B4 true DE102013114072B4 (de) 2024-08-01

Family

ID=51418666

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102013114072.6A Active DE102013114072B4 (de) 2013-03-15 2013-12-16 System und Verfahren zum Hardware-Scheduling von indexierten Barrieren

Country Status (4)

Country Link
US (1) US9442755B2 (de)
CN (1) CN104050033A (de)
DE (1) DE102013114072B4 (de)
TW (1) TWI512630B (de)

Families Citing this family (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9448803B2 (en) 2013-03-11 2016-09-20 Nvidia Corporation System and method for hardware scheduling of conditional barriers and impatient barriers
US9984430B2 (en) * 2013-04-15 2018-05-29 Intel Corporation Ordering threads as groups in a multi-threaded, multi-core graphics compute system
US9842111B2 (en) * 2013-12-22 2017-12-12 Varonis Systems, Ltd. On-demand indexing
FR3021429B1 (fr) * 2014-05-23 2018-05-18 Kalray Barriere de synchronisation materielle entre elements de traitement
US10241958B2 (en) * 2014-08-29 2019-03-26 Microsoft Technology Licensing, Llc Configurable synchronized processing of multiple operations
US9519944B2 (en) * 2014-09-02 2016-12-13 Apple Inc. Pipeline dependency resolution
US9298807B1 (en) * 2014-09-09 2016-03-29 Sas Institute Inc. Techniques for dynamic partitioning in a distributed parallel computational environment
EP3326059A4 (de) * 2015-07-21 2019-04-17 Ampere Computing LLC Implementierung von ladeaufnahme-/speicherfreisetzungsanweisungen anhand von lade-/speicheroperation mit dmb-betrieb
US10489206B2 (en) * 2016-12-30 2019-11-26 Texas Instruments Incorporated Scheduling of concurrent block based data processing tasks on a hardware thread scheduler
US10558464B2 (en) * 2017-02-09 2020-02-11 International Business Machines Corporation Infinite processor thread balancing
CN107102582B (zh) * 2017-04-07 2019-07-26 深圳怡化电脑股份有限公司 一种子系统命令的同步方法及装置
US10325341B2 (en) * 2017-04-21 2019-06-18 Intel Corporation Handling pipeline submissions across many compute units
US11353868B2 (en) * 2017-04-24 2022-06-07 Intel Corporation Barriers and synchronization for machine learning at autonomous machines
GB2560059B (en) 2017-06-16 2019-03-06 Imagination Tech Ltd Scheduling tasks
GB2563587B (en) * 2017-06-16 2021-01-06 Imagination Tech Ltd Scheduling tasks
US10558418B2 (en) * 2017-07-27 2020-02-11 Advanced Micro Devices, Inc. Monitor support on accelerated processing device
US11061742B2 (en) * 2018-06-27 2021-07-13 Intel Corporation System, apparatus and method for barrier synchronization in a multi-threaded processor
DE102020127704A1 (de) 2019-10-29 2021-04-29 Nvidia Corporation Techniken zum effizienten transferieren von daten an einem prozessor
US11080051B2 (en) 2019-10-29 2021-08-03 Nvidia Corporation Techniques for efficiently transferring data to a processor
US11409579B2 (en) * 2020-02-24 2022-08-09 Intel Corporation Multiple independent synchonization named barrier within a thread group
DE112021000305T5 (de) 2020-03-20 2022-12-01 Nvidia Corporation Programmiermodell für ressourcenbeschränkte Planung
US20210382717A1 (en) * 2020-06-03 2021-12-09 Intel Corporation Hierarchical thread scheduling
US11977895B2 (en) 2020-06-03 2024-05-07 Intel Corporation Hierarchical thread scheduling based on multiple barriers
US11204774B1 (en) * 2020-08-31 2021-12-21 Apple Inc. Thread-group-scoped gate instruction
US11720360B2 (en) * 2020-09-11 2023-08-08 Apple Inc. DSB operation with excluded region
US11656796B2 (en) 2021-03-31 2023-05-23 Advanced Micro Devices, Inc. Adaptive memory consistency in disaggregated datacenters
CN113721987B (zh) * 2021-09-02 2022-07-05 海光信息技术股份有限公司 指令执行方法和指令执行装置
US20230289242A1 (en) 2022-03-10 2023-09-14 Nvidia Corporation Hardware accelerated synchronization with asynchronous transaction support
US20230315655A1 (en) 2022-03-10 2023-10-05 Nvidia Corporation Fast data synchronization in processors and memory
US11954492B1 (en) 2022-09-19 2024-04-09 Apple Inc. Fence enforcement techniques based on stall characteristics
CN117311995B (zh) * 2023-11-28 2024-02-23 苏州元脑智能科技有限公司 一种存储系统的后台任务执行方法及其系统、控制器

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110078417A1 (en) 2009-09-25 2011-03-31 Brian Fahs Cooperative thread array reduction and scan operations
US8209702B1 (en) 2007-09-27 2012-06-26 Emc Corporation Task execution using multiple pools of processing threads, each pool dedicated to execute different types of sub-tasks

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7310722B2 (en) * 2003-12-18 2007-12-18 Nvidia Corporation Across-thread out of order instruction dispatch in a multithreaded graphics processor
US7669203B2 (en) * 2003-12-19 2010-02-23 Intel Corporation Virtual multithreading translation mechanism including retrofit capability
US7555607B2 (en) 2005-11-10 2009-06-30 Hewlett-Packard Development Company, L.P. Program thread syncronization for instruction cachelines
CN101542442B (zh) 2007-04-09 2012-12-19 松下电器产业株式会社 多处理器控制装置、其控制方法及集成电路
US7941791B2 (en) 2007-04-13 2011-05-10 Perry Wang Programming environment for heterogeneous processor resource integration
US8661226B2 (en) * 2007-11-15 2014-02-25 Nvidia Corporation System, method, and computer program product for performing a scan operation on a sequence of single-bit values using a parallel processor architecture
US9678775B1 (en) * 2008-04-09 2017-06-13 Nvidia Corporation Allocating memory for local variables of a multi-threaded program for execution in a single-threaded environment
US8423750B2 (en) 2010-05-12 2013-04-16 International Business Machines Corporation Hardware assist thread for increasing code parallelism
US8799454B2 (en) 2010-12-15 2014-08-05 International Business Machines Corporation Behavior based client selection for disparate treatment
CN102508712B (zh) * 2011-09-29 2014-01-15 中国科学技术大学苏州研究院 异构多核可重构混合系统中的中间件系统及任务执行方法
US9158595B2 (en) 2012-10-25 2015-10-13 Nvidia Corporation Hardware scheduling of ordered critical code sections
US9448803B2 (en) 2013-03-11 2016-09-20 Nvidia Corporation System and method for hardware scheduling of conditional barriers and impatient barriers

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8209702B1 (en) 2007-09-27 2012-06-26 Emc Corporation Task execution using multiple pools of processing threads, each pool dedicated to execute different types of sub-tasks
US20110078417A1 (en) 2009-09-25 2011-03-31 Brian Fahs Cooperative thread array reduction and scan operations

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
Adam Betts, Nathan Chong, Alastair Donaldson, Shaz Qadeer, and Paul Thomson: GPUVerify: a verifier for GPU kernels. SIGPLAN Not. 47, Oktober 2012, S. 113–132.

Also Published As

Publication number Publication date
TWI512630B (zh) 2015-12-11
US9442755B2 (en) 2016-09-13
TW201435746A (zh) 2014-09-16
DE102013114072A1 (de) 2014-09-18
US20140282566A1 (en) 2014-09-18
CN104050033A (zh) 2014-09-17

Similar Documents

Publication Publication Date Title
DE102013114072B4 (de) System und Verfahren zum Hardware-Scheduling von indexierten Barrieren
DE102013208554B4 (de) Verfahren und System zum Managen verschachtelter Ausführungsströme
DE102013022712B4 (de) Virtuelle Speicherstruktur für Coprozessoren, die Speicherallokationsbegrenzungen haben
DE102013017509B4 (de) Effiziente Speichervirtualisierung in mehrsträngigen Verarbeitungseinheiten
DE102013201178B4 (de) Steuern von Arbeitsverteilung für Verarbeitung von Tasks
DE102012222394A1 (de) Verfahren und Vorrichtung zum Sammelzwischenspeichern von Quelloperanden
DE102013017511B4 (de) Effiziente speichervirtualisierung in mehrsträngigen verarbeitungseinheiten
DE102013209350B4 (de) Ressource-Management-Subsystem, welches Fairness und Ordnung einhält
DE102013016871B4 (de) Technik zur Steigerung der Effizienz in mehrsträngigen Verarbeitungseinrichtungen
DE102012220267B4 (de) Rechenarbeitsverteilungs - Referenzzähler
DE102012222558B4 (de) Signalisieren, Ordnen und Ausführung von dynamisch erzeugten Aufgaben in einem Verarbeitungs-System
DE102013114351A1 (de) System und Verfahren für Hardware-Disponierung bedingter Barrieren und ungeduldiger Barrieren
DE102012222913A1 (de) Verfahren und Apparat zum Planen von Anweisungen unter Benutzung von Zuvor-Dekodieren-Daten
DE102012221502A1 (de) System und Verfahren zum Durchführen von gestalteter-Speicherzugriff-Operationen
DE102013205886A1 (de) Dynamische Bankmodus-Adressierung für Speicherzugriff
DE102012211670A1 (de) Simultanes Unterbreiten an eine Mehr-Produzenten-Queue mittels mehrerer Threads
DE102013202173A1 (de) Einheitliche Lade-Verarbeitung für Teilsätze von parallelen Threads
DE102013200997A1 (de) Ein blockierungsfreies FIFO
DE102013208558A1 (de) Verfahren und System zur Verarbeitung verschachtelter Stream-Events
DE102013200991A1 (de) Automatisches abhängige-Aufgabe-Anstoßen
DE102012221504A1 (de) Mehrniveau-Anweisung-Zwischenspeicher-Zuvor-Holen
DE102012222918A1 (de) Verfahren und Apparat zum Planen von Anweisungen ohne Anweisungs-Dekodieren
DE102012220029A1 (de) Spekulative Ausführung und Zurücksetzen
DE102009012766A1 (de) Ein Zugriffssperrenvorgang, um atomare Aktualisierungen zu einem geteilten Speicher zu ermöglichen
DE102013100179A1 (de) Verfahren und System zum Auflösen von Thread-Divergenzen

Legal Events

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

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

R016 Response to examination communication
R018 Grant decision by examination section/examining division