DE102013201195A1 - Zuvor-geplante Wiederholungen von divergenten Operationen - Google Patents

Zuvor-geplante Wiederholungen von divergenten Operationen Download PDF

Info

Publication number
DE102013201195A1
DE102013201195A1 DE102013201195A DE102013201195A DE102013201195A1 DE 102013201195 A1 DE102013201195 A1 DE 102013201195A1 DE 102013201195 A DE102013201195 A DE 102013201195A DE 102013201195 A DE102013201195 A DE 102013201195A DE 102013201195 A1 DE102013201195 A1 DE 102013201195A1
Authority
DE
Germany
Prior art keywords
threads
instruction
operations
scheduled
thread
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102013201195A
Other languages
English (en)
Inventor
Michael Fetterman
Stewart Glenn Carlton
Jack Hilaire Choquette
Shirish Gadre
Olivier Giroux
Douglas J. Hahn
Steven James HEINRICH
Eric Lyell Hill
Charles McCarver
Omkar PARANJAPE
Anjana Rajendran
Rajeshwaran Selvanesan
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 DE102013201195A1 publication Critical patent/DE102013201195A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline, look ahead
    • G06F9/3861—Recovery, e.g. branch miss-prediction, exception handling
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline, look ahead
    • G06F9/3836—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline, look ahead
    • G06F9/3836—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution
    • G06F9/3851—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution from multiple instruction streams, e.g. multistreaming
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline, look ahead
    • G06F9/3885—Concurrent instruction execution, e.g. pipeline, look ahead using a plurality of independent parallel functional units
    • G06F9/3887—Concurrent instruction execution, e.g. pipeline, look ahead using a plurality of independent parallel functional units controlled by a single instruction for multiple data lanes [SIMD]

Abstract

Eine Ausführungsform der vorliegenden Erfindung führt einen optimierten Weg aus, Zuvor-geplante-Wiederholen-Operationen für divergente Operationen in einem Parallel-Verarbeitungs-Subsystem auszuführen. Spezifisch umfasst ein Streaming-Multiprozessor (SM) eine Mehr-Stufe-Pipeline, welche konfiguriert ist, Zuvor-geplante-Wiederholen-Operationen in eine Mehr-Stufe-Pipeline einzufügen. Eine Zuvor-geplante-Wiederholen-Einheit detektiert, ob die Operation, welche mit der momentanen Anweisung assoziiert ist, auf eine gemeinsame Ressource zugreift. Wenn die Threads auf Daten zugreifen, welche über mehrere Zwischenspeicher-Zeilen verteilt sind, dann fügt die Zuvor-geplante-Wiederholen-Einheit Zuvor-geplante-Wiederholen-Operationen hinter der momentanen Anweisung ein. Die Mehr-Stufe-Pipeline führt die Anweisung und die assoziierten Zuvor-geplante-Wiederholen-Operationen sequentiell aus. Wenn zusätzliche Threads nach Ausführung der Anweisung und der Zuvor-geplante-Wiederholen-Operationen unbedient verbleiben, dann werden zusätzliche Wiederholen-Operationen über die Wiederholen-Schleife eingefügt, bis alle Threads bedient sind. Ein Vorteil der offenbarten Technik ist, dass divergente Operationen, welche eine oder mehr Wiederholen-Operationen erfordern, mit verminderter Latenz ausführen.

Description

  • HINTERGRUND DER ERFINDUNG
  • GEBIET DER ERFINDUNG
  • Die vorliegende Erfindung betrifft im Allgemeinen Computer-Architekturen und insbesondere Zuvor-geplante Wiederholungen (prescheduled replays) von divergenten Operationen.
  • BESCHREIBUNG DER BETREFFENDEN TECHNIK
  • Eine gewöhnliche Praxis in Parallel-Verarbeitungs-Systemen ist es, einen Prozessor zu entwerfen, welcher eine gewisse Anzahl von Threads simultan ausführt. Jeder Thread kann in einer separaten Ausführungs-Pipeline innerhalb des Prozessors ausführen. Wenn solche Threads alle dieselbe Anweisungs-Sequenz ausführen müssen (typischerweise mit verschiedenen Daten für jeden Thread), kann es merkbare Vorteile geben, die Kontroll-Strukturen der Threads gemeinsam zu benutzen bzw. zu teilen. Zum Beispiel muss nur eine Anweisung geholt werden und alle Threads führen dann diese selbe Anweisung aus. Dieser Typ einer Operation kann auf Einfach-Anweisung-Mehr-Thread-(SIMT)-Prozessoren und Einzel-Anweisung-Mehr-Daten-(SIMD)-Prozessoren aufgefunden werden.
  • Da eine Ausführung parallel voranschreitet, können verschiedene Threads auf eine gemeinsame Ressource zugreifen, wie etwa einen gemeinsamen Speicher, in einer Weise, welche dazu führt, dass den Threads ein Ressourcen-Konflikt begegnet. Zum Beispiel können die Threads eine gemeinsame-Ressource-Zugriffs-Operation ausführen, wie etwa eine Speicher-Lade-Operation, wobei sich der Satz von Speicherstellen über zwei oder mehr Zwischenspeicher-Zeilen erstreckt (spans). Solch eine Lade-Anweisung kann eine „divergente” Operation genannt werden, weil die Speicherstellen, welche mittels der verschiedenen Threads erfordert sind, auf divergenten Zwischenspeicher-Zeilen sind. In solchen Situationen transferiert die Pipeline Daten von einer der Zwischenspeicher-Zeilen, auf welche einige der Threads zugreifen, und diese Threads sind in der Lage, die gemeinsame-Ressource-Zugriffs-Operation zu vollenden. Die anderen Threads jedoch, welche auf Stellen innerhalb einer anderen Zwischenspeicher-Zeile zeigen, sind nicht in der Lage, die gemeinsame-Ressource-Zugriffs-Operation zu vollenden und bleiben unbedient. Somit sind mit einem einzelnen Durchgang durch die Pipeline einige Threads in der Lage, die gemeinsame-Ressource-Zugriffs-Operation zu vollenden, während andere Threads es nicht sind. In Ermangelung eines Mittels, um mehrere Ausführungs-Zyklen zu verarbeiten, ist die Operation nicht in der Lage, erfolgreich zu beenden bzw. vollenden.
  • Eine Zugangsweise zum Implementieren von mehreren Ausführungs-Zyklen ist es, die Anweisung in die vorherige Stufe der Verarbeitungs-Pipeline erneut einzusetzen und die Lade-Anweisung wiederum für die Threads auszuführen, welche nicht in der Lage waren, auf die Daten von ihren Ziel-Speicher-Adress-Stellen zuzugreifen. Solch eine Technik wird eine „Wiederholung bzw. Wiederholen” („replay”)-Operation genannt. Wo eine Stufe in der Pipeline eine Operation durchführt, welche in dem momentanen Zyklus nicht vollendet werden kann, „wiederholt” die Pipeline im Wesentlichen die Lade-Anweisung einmal für jede Zwischenspeicher-Zeile, welche zumindest eine Ziel-Adresse umfasst, bis jeder Thread die relevante gemeinsame-Ressource-Zugriffs-Operation durchführt. Während dieses Prozesses wird ein Teil der Pipeline benutzt, um die Wiederholen-Operationen zu vollenden. Daher wird die Pipelinie angehalten (stalled), um zu verhindern, dass neue Anweisungen in die Pipeline eintreten, bis alle Wiederholen-Operationen vollendet worden sind. Ein Nachteil dieser Zugangsweise ist, dass die Pipeline angehalten wird, bis alle Wiederholen-Operationen vollenden. Stromaufwärts-Anweisungen können nicht in die Pipeline voranschreiten, bis die Pipeline-Unterbrechung bzw. Pipeline-Anhalten freigegeben ist, was eine Gesamt-System-Performance vermindert. Ein zusätzlicher Nachteil ist, dass das Parallel-Verarbeitungs-System nicht in der Lage zu sein braucht, alle Pipeline-Stufen innerhalb einer Pipeline-Stufe-Verzögerung anzuhalten. Wenn das Parallel-Verarbeitungs-System die Pipeline nicht pünktlich oder in der Zeit (in time) anhalten kann, dann können eine oder mehrere neue Anweisungen, welche in die Pipeline eintreten, inkorrekt verworfen werden oder die Wiederholen-Operation ist ähnlich verworfen. In jedem Fall vollendet die neue Anweisung oder die Wiederholen-Operation nicht korrekt.
  • Eine andere Zugangsweise zum Implementieren von mehreren Ausführungs-Zyklen ist es, die Anweisung weiter zurück in der Pipeline wieder einzusetzen. Mit dieser Zugangsweise werden die Anweisungen, welche „wiederholt” werden, in der Pipeline zusammen mit neuen Anweisungen verschachtelt (interleaved), was die Frequenz von Pipeline-Unterbrechungen bzw. -Anhaltevorgängen (stalls) vermindert, um dadurch eine Pipeline-Performance zu erhöhen. Ein Nachteil dieser Vorgehensweise ist jedoch eine erhöhte Latenz der wiederholten Anweisungen. Man betrachte z. B. einen Prozessor mit 32 simultan ausführenden Threads. In einer divergenten Lade-Operation können die Ziel-Adress-Stellen für die 32 Threads über 32 verschiedene Zwischenspeicher-Zeilen divergieren. Wenn eine Wiederholen-Operation eine Pipeline-Stufe zurück eingeführt bzw. eingefügt wird, dann kann die Pipeline für 31 Pipeline-Zyklen anhalten, während 31 Wiederholen-Operationen ausführen. Ein Einfügen der Wiederholen-Operation fünf Pipeline-Stufen zurück erhöht die Latenz für die Anweisungen, welche wiederholt werden, auf fünf Pipeline-Stufen multipliziert mit 31 Wiederholen-Operationen oder 155 Pipeline-Zyklen.
  • Wie das Vorangehende illustriert, ist was in der Technik gebraucht ist, ein effizienterer Weg, um Wiederholen-Operationen für divergente Operationen auszuführen.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Eine Ausführungsform der vorliegenden Erfindung führt ein Computer-implementiertes Verfahren zum Zuvor-Planen (pre-scheduling) von Wiederholungen von gemeinsame-Ressource-Zugriffs-Operationen aus. Ein Streaming-Multiprozessor (SM) empfängt eine Anweisung, welche mittels einer Gruppe von Threads in einer Mehr-Stufe-Pipeline auszuführen ist. Der SM bestimmt, dass eine Zuvor-geplante-Wiederholen-Operation in die Mehr-Stufe-Pipeline eingefügt werden soll, um einem zweiten Satz von einem oder mehreren Threads von der Gruppe von Threads die Anweisung auszuführen zu erlauben. Der SM wählt einen ersten Satz von einem oder mehreren Threads von der Gruppe von Threads aus, um die Anweisung in der Mehr-Stufe-Pipeline auszuführen. Der SM fügt die Anweisung in die Mehr-Stufe-Pipeline zur Ausführung mittels des ersten Satzes von einem oder mehreren Threads ein. Der SM fügt die Zuvor-geplante-Wiederholen-Operation in die Mehr-Stufe-Pipeline ein, um dem zweiten Satz von einem oder mehreren Threads zu erlauben, die erste Anweisung auszuführen. Der erste Satz von einem oder mehreren Threads ist beabsichtigt, auf einen ersten Aspekt oder Teil einer gemeinsamen Ressource zuzugreifen, und der zweite Satz von einem oder mehreren Threads ist beabsichtigt, auf einem zweiten Aspekt oder Teil der gemeinsamen Ressource zuzugreifen.
  • Ein Vorteil der offenbarten Technik ist, dass divergente Operationen, welche eine oder mehrere Wiederholen-Operationen erfordern, mit verminderter Latenz ausführen. Ferner ist die Mehr-Stufe-Pipeline effizienter benutzt, weil eine oder mehrere Zuvor-geplante-Wiederholen-Operationen durch die Wiederholen-Schleife seriell entlang oder zusammen (along) mit ursprünglichen Anweisungen voranschreiten.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • So dass die Weise, in welcher die oben zitierten Merkmale der vorliegenden Erfindung im Detail verstanden werden können, kann eine besondere Beschreibung der Erfindung, welche kurz oben zusammengefasst ist, durch Bezugnahme auf Ausführungsformen genommen werden, von welchen einige in den angehängten Zeichnungen illustriert sind. Es ist jedoch zu bemerken, dass die angehängten Zeichnungen nur typische Ausführungsformen dieser Erfindung illustrieren und dass sie daher nicht aufzufassen sind, ihren Geltungsbereich zu begrenzen, denn die Erfindung kann andere genauso effektive Ausführungsformen zulassen.
  • 1 ist ein Blockdiagramm, welches ein Computersystem illustriert, welches konfiguriert ist, einen oder mehrere Aspekte der vorliegenden Erfindung zu implementieren;
  • 2 ist ein Blockdiagramm eines Parallel-Verarbeitungs-Subsystem für das Computersystem der 1, gemäß einer Ausführungsform der vorliegenden Erfindung;
  • 3A ist ein Blockdiagramm des Frontends von 2, gemäß einer Ausführungsform der vorliegenden Erfindung;
  • 3B ist ein Blockdiagramm eines Allgemein-Verarbeitungs-Clusters innerhalb einer der Parallel-Verarbeitungs-Einheiten von 2, gemäß einer Ausführungsform der vorliegenden Erfindung;
  • 3C ist ein Blockdiagramm eines Teils des Streaming-Mehrfach-Prozessors von 3B, gemäß einer Ausführungsform der vorliegenden Erfindung; und
  • 4 illustriert eine Mehr-Stufe-Pipeline, welche konfiguriert ist, Zuvor-geplante Wiederholungen von divergenten Operationen zu implementieren, gemäß einer Ausführungsform der vorliegenden Erfindung; und
  • 5 ist ein Flussdiagramm von Verfahrensschritten zum Ausführen von Zuvor-geplanten-Wiederholen-Operationen in einer Mehr-Stufe-Pipeline gemäß einer Ausführungsform der vorliegenden Erfindung.
  • DETAILLIERTE BESCHREIBUNG
  • In der folgenden Beschreibung werden zahlreiche spezifische Details ausgeführt, um ein durchgängigeres Verständnis der vorliegenden Erfindung bereitzustellen. Es wird jedoch für den Fachmann in der Technik ersichtlich sein, dass die vorliegende Erfindung ohne ein oder mehrere dieser spezifischen Details praktiziert werden kann.
  • Systemüberblick
  • 1 ist ein Blockdiagramm, welches ein Computersystem 100 illustriert, welches konfiguriert ist, einen oder mehrere Aspekte der vorliegenden Erfindung zu implementieren. Computersystem 100 umfasst eine Zentralverarbeitungseinheit (CPU) 102 und einen Systemspeicher 104, welcher über einen Zwischenverbindungspfad (interconnection path) kommuniziert, welcher eine Speicherbrücke 105 umfassen kann. Speicherbrücke 105, welche z. B. ein Northbridge-Chip sein kann, ist über einen Bus oder einen anderen Kommunikationspfad 106 (z. B. HyperTransport-Link) mit einer I/O-(Eingabe/Ausgabe)-Brücke 107 verbunden. I/O-Brücke 107, welche z. B. ein Southbridge-Chip sein kann, empfängt Benutzereingabe von einem oder mehreren Benutzer-Eingabegeräten 108 (z. B. Tastatur, Maus) und leitet die Eingabe an CPU 102 über Kommunikationspfad 106 und Speicherbrücke 105 weiter. Ein Parallel-Verarbeitungs-Subsystem 112 ist mit der Speicherbrücke 105 über einen Bus oder einen zweiten Kommunikationspfad 113 (z. B. einen Peripheral Component Interconnect(PCI)-Express Accelerated Graphics Port, oder HyperTransport-Link) gekoppelt; in einer Ausführungsform ist das Parallel-Verarbeitungs-Subsystem 112 ein Grafik-Subsystem, welches Pixel an ein Anzeigegerät 110 (z. B. ein konventioneller Kathodenstrahlröhre- oder Flüssigkristallanzeige-basierter Monitor) liefert. Eine Systemplatte 114 ist auch mit der I/O-Brücke 107 verbunden. Ein Switch 116 stellt Verbindungen zwischen I/O-Brücke 107 und anderen Komponenten bereit, wie etwa ein Netzwerkadapter 118 und verschiedenen Hinzufügungskarten (Add-in-Cards) 120 und 121. Andere Komponenten (nicht explizit gezeigt) umfassend Universal Serial Bus USB- oder andere Port-Verbindungen, Kompakt-Disk(CD)-Laufwerke, digitale Video-Disk(DVD)-Laufwerke, Filmaufnahmegeräte, und dergleichen, können auch mit der I/O-Brücke 107 verbunden sein. Die verschiedenen Kommunikationspfade, welche in 1 gezeigt sind, einschließlich die speziell genannten Kommunikationspfade 106 und 113, können unter Benutzung irgendwelcher geeigneten Protokolle implementiert sein, wie etwa PCI-Express, AGP (Accelerated Graphics Port), HyperTransport, oder irgendeines oder irgendwelcher Bus- oder Punkt-zu-Punkt-Kommunikations-Protokoll(e), und Verbindungen zwischen verschiedenen Geräten können verschiedene Protokolle benutzen, wie in der Technik bekannt ist.
  • In einer Ausführungsform inkorporiert das Parallel-Verarbeitungs-Subsystem 112 Schaltung, welche für Grafik- und Video-Verarbeitung optimiert ist, einschließlich zum Beispiel Videoausgabe-Schaltung, und konstituiert eine Grafik-Verarbeitungseinheit (GPU). In einer anderen Ausführungsform umfasst das Parallel-Verarbeitungs-Subsystem 112 Schaltung, welche für Allgemeinzweck-Verarbeitung optimiert ist, während die darunter liegende Computer-Architektur, welche im größeren Detail hierin beschrieben ist, beibehalten ist. In noch einer anderen Ausführungsform kann das Parallel-Verarbeitungs-Subsystem 102 mit einem oder mit mehreren anderen Systemelementen in ein einzelnes Subsystem integriert sein, wie etwa die Speicherbrücke 105, CPU 102 und I/O-Brücke 107 verbindend, um ein System auf dem Chip (system an chip) (SoC) zu bilden.
  • Es wird geschätzt werden, dass das hierin gezeigte System illustrativ ist und dass Variationen und Modifikationen möglich sind. Die Verbindungstopologie, einschließlich der Anzahl und der Anordnung von Brücken, der Anzahl von CPUs 102, und der Anzahl von Parallel-Verarbeitungs-Subsystemen 112 kann wie gewünscht modifiziert werden. Zum Beispiel ist in einigen Ausführungsformen Systemspeicher 104 mit CPU 102 direkt gekoppelt anstatt durch eine Brücke, und andere Geräte kommunizieren mit Systemspeicher 104 über Speicherbrücke 105 und CPU 102. In anderen alternativen Topologien ist das Parallel-Verarbeitungs-Subsystem 112 mit I/O-Brücke 107 oder direkt mit CPU 102 verbunden anstatt mit der Speicherbrücke 105. In noch anderen Ausführungsformen können die I/O-Brücke 107 und Speicherbrücke 105 in einen einzelnen Chip integriert sein, anstatt als ein oder mehr Geräte zu existieren. Große Ausführungsformen können zwei oder mehr CPUs 102 und zwei oder mehr Parallel-Verarbeitungs-Subsysteme 112 umfassen. Die besonderen Komponenten, welche hierin gezeigt sind, sind optional; z. B. könnte irgendeine Anzahl von Hinzufügungskarten oder peripheren Geräten unterstützt sein. In einigen Ausführungsformen ist der Switch 116 eliminiert und der Netzwerkadapter 116 und Hinzufügungskarten 120, 121 verbinden direkt mit der I/O-Brücke 107.
  • 2 illustriert ein Parallel-Verarbeitungs-Subsystem 112 gemäß einer Ausführungsform der vorliegenden Erfindung. Wie gezeigt, umfasst das Parallel-Verarbeitungs-Subsystem 112 eine oder mehrere Parallel-Verarbeitungseinheiten (PPUs) 202, wobei jede von diesen mit einem lokalen Parallel-Verarbeitungs-(PP)-Speicher 204 gekoppelt ist. Im Allgemeinen umfasst ein Parallel-Verarbeitungs-Subsystem eine Anzahl U von PPUs, wobei U ≥ 1 (hierin sind mehrere Instanzen von ähnlichen Objekten mit Referenznummern bezeichnet, welche das Objekt identifizieren und Nummern in Klammern die Instanz identifizieren, wenn benötigt). PPUs 202 und Parallel-Verarbeitungs-Speicher 204 können unter Benutzung von einem oder mehreren integrierte-Schaltung-Geräten implementiert sein, wie etwa programmierbare Prozessoren, Anwendungs-spezifische integrierte Schaltungen (ASICs), oder Speichergeräte, oder in irgendeiner anderen technisch machbaren Weise.
  • Mit Bezug wieder auf 1 sowie 2 sind in einigen Ausführungsformen einige oder alle der PPUs 202 in dem Parallel-Verarbeitungs-Subsystem 112 Grafikprozessoren mit Render-Pipelines, welche konfiguriert sein können, um verschiedene Operationen durchzuführen, welche das Erzeugen von Pixeldaten von Grafik-Daten, welche mittels CPU 102 und/oder Systemspeicher 104 über Speicherbrücke 105 und den zweiten Kommunikationspfad 113 zugeführt sind, ein Interagieren mit lokalem Parallel-Verarbeitungs-Speicher 204 (welcher als ein Grafikspeicher benutzt werden kann einschließlich z. B. eines konventionellen Bildpuffers (frame buffer)), um Pixeldaten zu speichern und zu aktualisieren, ein Liefern von Pixeldaten an das Anzeigegeräte 110, und dergleichen betreffen. In einigen Ausführungsformen kann das Parallel-Verarbeitungs-Subsystem 112 eine oder mehrere PPUs 202 umfassen, welche als Grafikprozessoren operieren, und eine oder mehrere andere PPUs 202, welche für Allgemeinzweck-Berechnungen benutzt werden können. Die PPUs können identisch sein oder verschieden sein und jede PPU kann ein dediziertes Parallel-Verarbeitungs-Speichergerät(e) haben oder braucht nicht dedizierte Parallel-Verarbeitungs-Speichergerät(e) zu haben. Eine oder mehrere PPUs 202 in Parallelverarbeitungs-Subsystem 112 können Daten an das Anzeigegeräte 110 ausgeben oder jede PPU 202 Parallelverarbeitungs-Subsystem 112 kann Daten an eines oder mehrere Anzeigegeräte 110 ausgeben.
  • Im Betrieb ist CPU 102 der Master-Prozessor von Computersystems 100, welcher Operationen von anderen Systemkomponenten steuert und koordiniert. Insbesondere stellt CPU 102 Befehle aus, welche den Betrieb von PPUs 202 steuern. In einigen Ausführungsformen schreibt CPU 102 einen Strom von Befehlen für jede PPU 202 an eine Daten-Struktur (nicht explizit gezeigt in 1 oder 2), welche in System-Speicher 104, Parallel-Verarbeitungs-Speicher 204, oder einer anderen Speicher-Stelle lokalisiert sein kann, welche sowohl für CPU 102 als auch für PPU 202 zugreifbar ist. Ein Zeiger auf jede Daten-Struktur ist an einen Schiebe-Puffer (push buffer) geschrieben, um eine Verarbeitung von dem Strom von Befehlen in der Daten-Struktur zu initiieren. Die PPU 202 liest Befehls-Ströme von einem oder mehr Schiebe-Puffern und führt dann Befehle asynchron relativ zu dem Betrieb von CPU 102 aus. Ausführungs-Prioritäten können für jeden Schiebe-Puffer mittels eines Anwendungs-Programms über den Geräte-Treiber 103 spezifiziert werden, um eine Planung der verschiedenen Schiebe-Puffer zu steuern.
  • Mit Bezug nun zurück auf 2 sowie 1 umfasst jede PPU 202 eine I/O-(Eingabe/Ausgabe)-Einheit 205, welche mit dem Rest des Computersystems 100 über Kommunikationspfad 113 kommuniziert, welcher zu Speicherbrücke 105 (oder in einer anderen Ausführungsform direkt mit CPU 102) verbindet. Die Verbindung von PPU 202 an den Rest des Computersystems 100 kann auch variiert werden. In einigen Ausführungsformen ist das Parallel-Verarbeitungs-Subsystem 112 als eine Hinzufügungskarte implementiert, welche in einen Erweiterungsschlitz oder Erweiterungssteckplatz (expansion slot) von Computersystem 100 eingeführt werden kann. In anderen Ausführungsformen kann eine PPU 202 auf einem einzelnen Chip integriert sein mit einer Bus-Brücke, wie etwa Speicherbrücke 105 oder I/O-Brücke 107. In noch anderen Ausführungsformen können einige oder alle Elemente von PPU 202 auf einem einzelnen Chip mit CPU 102 integriert sein.
  • In einer Ausführungsform ist Kommunikationspfad 113 ein PCI-Express-Link, in welchem dedizierte Spuren oder Bahnen (lanes) an jede PPU 202 alloziert sind, wie es in der Technik bekannt ist. Andere Kommunikationspfade können auch benutzt werden. Eine I/O-Einheit 205 erzeugt Pakete (oder andere Signale) für eine Übermittlung auf Kommunikationspfad 113 und empfängt auch alle einlaufenden oder hereinkommenden (incoming) Pakete (oder andere Signale) von Kommunikationspfad 113, wobei die einlaufenden Pakete zu den geeigneten Komponenten von PPU 202 gerichtet werden. Zum Beispiel können Befehle, welche Verarbeitungs-Aufgaben betreffen, an eine Host-Schnittstelle 206 gerichtet werden, während Befehle, welche Speicher-Operationen betreffen (z. B. Lesen von oder Schreiben auf Parallel-Verarbeitungsspeicher 204) an eine Speicher-Kreuzschiene-Einheit (memory crossbar unit) 202 gerichtet werden können. Host-Schnittstelle 206 liest jeden Push-Puffer und gibt den Befehlsstrom, welches in dem Push-Puffers gespeichert ist, an ein Frontend 212 aus.
  • Jede PPU 202 implementiert vorteilhafter Weise eine Hochparallel-Verarbeitungs-Architektur. Wie im Detail gezeigt ist, umfasst PPU 202(0) ein Verarbeitungscluster-Feld (processing cluster array) 230, welches eine Anzahl C von Allgemein-Verarbeitungs-Clustern (GPCs) 208 umfasst, wobei C ≥ 1.
  • Jeder GPC 208 ist in der Lage, eine große Anzahl (z. B. Hunderte oder Tausende) von Threads simultan (concurrently) auszuführen, wobei jeder Thread eine Instanz eines Programms ist. In verschiedenen Anwendungen können verschiedene GPCs 208 zur Verarbeitung von verschiedenen Typen von Programmen oder zum Durchführen von verschiedenen Typen von Berechnungen alloziert werden. Die Allozierung von GPCs 208 kann abhängig von der Arbeitsbelastung, welche für jeden Typ von Programm oder Berechnung auftritt, variiert werden.
  • GPCs 208 empfangen Verarbeitungs-Aufgaben, welche auszuführen sind, von einer Arbeit-Verteilungs-Einheit innerhalb einer Aufgabe-/Arbeit-Einheit 207. Die Arbeit-Verteilungs-Einheit empfängt Zeiger auf Verarbeitungs-Aufgaben, welche als Aufgabe-Metadaten (TMD) kodiert sind und in Speicher gespeichert sind. Die Zeiger auf TMDs sind in dem Befehls-Strom umfasst, welcher als ein Schiebe-Puffer gespeichert ist und mittels der Frontend-Einheit 212 von der Host-Schnittstelle 206 empfangen ist. Verarbeitungs-Aufgaben, welche als TMDs kodiert sein können, umfassen Indizes auf Daten, welche zu prozessieren sind, sowie Status-Parameter und Befehle, welche definieren, wie die Daten zu prozessieren sind (z. B. welches Programm auszuführen ist). Die Aufgabe/Arbeit-Einheit 207 empfängt Aufgaben von dem Frontend 212 und stellt sicher, dass GPCs 208 auf einen gültigen Zustand konfiguriert sind, bevor die Prozessierung, welche mittels jeder der TMDs spezifiziert ist, initiiert ist. Eine Priorität kann für jede TMD spezifiziert sein, welche benutzt ist, Ausführung der Verarbeitungs-Aufgabe zu planen. Verarbeitungs-Aufgaben können auch von dem Verarbeitungs-Cluster-Feld 230 empfangen werden. Optional kann die TMD einen Parameter umfassen, welcher steuert, ob die TMD an den Kopf (head) oder den Schwanz (tail) für eine Liste von Verarbeitungs-Aufgaben hinzugefügt wird (oder eine Liste von Zeigern auf die Verarbeitungs-Aufgaben), wodurch ein anderes Niveau von Steuerung über Priorität bereitgestellt ist.
  • Speicher-Schnittstelle 214 umfasst ein Anzahl D von Partitions-Einheiten 215, welche jeweils direkt mit einem Teil von Parallel-Verarbeitungs-Speicher 204 gekoppelt sind, wobei D ≥ 1. Wie gezeigt, ist die Anzahl von Partitions-Einheiten 215 im Allgemeinen gleich der Anzahl von dynamischerwillkürlicher-Zugriff-Speicher (DRAM) 220. In anderen Ausführungsformen muss die Anzahl von Partitions-Einheiten 215 nicht gleich der Nummer von Speicher-Geräten sein. Gewöhnliche Fachleute in der Technik werden schätzen, dass DRAM 220 durch irgendwelche anderen geeigneten Speicher-Geräte ersetzt werden kann und von einem im Allgemeinen konventionellen Design sein kann. Eine detaillierte Beschreibung wird daher ausgelassen. Render-Ziele (render targets), wie etwa Frame-Puffer oder Textur-Maps können über DRAMs 220 gespeichert sein, was den Partitions-Einheiten 215 erlaubt, Teile von jedem Render-Target in paralleler Weise zu schreiben, um effektiv die verfügbare Bandbreite von Parallel-Verarbeitungs-Speicher 204 zu nutzen.
  • Irgendeine von GPCs 208 kann Daten verarbeiten, welche auf irgendeinen der DRAMs 220 innerhalb des Parallel-Verarbeitungs-Speichers 204 zu schreiben sind. Kreuzschiene-Einheit 210 ist konfiguriert, um die Ausgabe von jedem GPC 208 an den Eingang irgendeiner Partitions-Einheit 215 oder an irgendeinen GPC 208 für weitere Verarbeitung zu leiten (route). GPCs 208 kommunizieren mit der Speicher-Schnittstelle 214 durch die Kreuzschiene 210, um von/auf verschiedene externe Speicher-Geräte zu schreiben oder zu lesen. In einer Ausführungsform hat die Kreuzschiene-Einheit 210 eine Verbindung der Speicher-Schnittstelle 214, um mit I/O-Einheit 205 zu kommunizieren, sowie eine Verbindung mit lokalem Parallel-Verarbeitungs-Speicher 204, um dadurch den Verarbeitungs-Kernen innerhalb der verschiedenen GPCs 208 zu ermöglichen, mit dem System-Speicher 104 oder einem anderen Speicher zu kommunizieren, welcher nicht lokal zu der PPU 202 ist. In der in 2B gezeigten Ausführungsform ist die Kreuzschiene-Einheit 210 direkt mit I/O-Einheit 205 verbunden. Kreuzschiene-Einheit 210 kann virtuelle Kanäle benutzen, um Verkehrsströme zwischen den GPCs 208 und den Partitions-Einheiten 215 zu separieren.
  • Wiederum können GPCs 208 programmiert sein, Verarbeitungs-Aufgaben durchzuführen, welche eine große Verschiedenheit von Anwendungen betreffen, einschließlich aber nicht darauf beschränkt, lineare oder nichtlineare Daten-Transformationen, Filtern von Video- und/oder Audio-Daten, Modellierungs-Operationen (z. B. Anwenden der Gesetze der Physik, um Position, Geschwindigkeit und andere Attribute von Objekten zu bestimmen), Bild-Render-Operationen (z. B. Tessellations-Schattierung, Vertex-Schattierung, Geometrie-Schattierung und/oder Pixel-Schattierungs-Programme), usw. PPUs 202 können Daten von dem System-Speicher 104 und/oder Lokal-Parallel-Verarbeitungs-Speichern 204 in internen (On-Chip)-Speicher transferieren, können die Daten prozessieren, und können Ergebnis-Daten zurück in den System-Speicher 104 und/oder lokalen Parallel-Verarbeitungs-Speicher 204 schreiben, wo auf solche Daten mittels anderer System-Komponenten zugegriffen werden kann, einschließlich CPU 102 oder ein anderes Parallel-Verarbeitungs-Subsystem 112.
  • Eine PPU 202 kann mit irgendeiner Menge/Umfang (amount) von Lokal-Parallel-Verarbeitungs-Speicher 204 bereitgestellt sein, einschließlich keines Lokal-Speichers, und kann Lokal-Speicher und System-Speicher in irgendeiner Kombination benutzen. Zum Beispiel kann eine PPU 202 ein Grafikprozessor in einer unifizierter-Speicher-Architektur (unified memory architecture) (UMA)-Ausführungsform sein. In solchen Ausführungsformen würde wenig oder kein dedizierter Grafik-(Parallel-Verarbeitungs)-Speicher bereitgestellt sein und PPU 202 würde System-Speicher exklusiv oder fast exklusiv benutzen. In UMA-Ausführungsformen kann eine PPU 202 in einen Brücken-Chip oder Prozessor-Chip integriert sein oder als ein diskreter Chip bereitgestellt sein mit einem Hochgeschwindigkeits-Link (z. B. PCI-Express), welcher die PPU 202 mit System-Speicher über einen Brücke-Chip oder ein anderes Kommunikations-Mittel verbindet.
  • Wie oben bemerkt ist, kann irgendeine Anzahl von PPUs 202 in einem Parallel-Verarbeitungs-Subsystem 112 umfasst sein. Zum Beispiel können mehrere PPUs 202 auf einer einzelnen Hinzufügungskarte bereitgestellt sein oder mehrere Hinzufügungskarten können mit dem Kommunikationspfad 113 verbunden sein oder eine oder mehrere der PPUs 202 können in einen Brücken-Chip integriert sein. PPUs 202 in einem Mehr-PPU-System können identisch sein oder verschieden voneinander sein. Zum Beispiel könnten verschiedene PPUs 202 verschiedene Anzahlen von Verarbeitungs-Kernen haben, verschiedene Mengen oder Größen von Lokal-Parallel-Verarbeitungs-Speicher, usw. Wo mehrere PPUs 202 vorhanden sind, können diese PPUs in paralleler Weise betrieben werden, um Daten bei einem höheren Durchsatz zu verarbeiten als es mit einer einzelnen PPU 202 möglich ist. Systeme, welche eine oder mehrere PPUs 202 inkorporieren, können in einer Verschiedenheit von Konfigurationen und Formfaktoren implementiert sein, einschließlich Schreibtisch-Computer, Laptop-Computer, oder handgehaltenen Personal-Computern, Servern, Arbeitsstationen, Spielekonsolen, eingebetteten Systemen und dergleichen.
  • Mehrfach-gleichzeitiges-Aufgabe-Planen
  • Mehrere Verarbeitungs-Aufgaben können gleichzeitig auf den GPCs 208 ausgeführt werden und eine Verarbeitungs-Aufgabe kann eine oder mehr „Kind”-Verarbeitungs-Aufgaben während der Ausführung erzeugen. Die Aufgabe-/Arbeit-Einheit 207 empfängt die Aufgaben und plant dynamisch die Verarbeitungs-Aufgaben und Kind-Verarbeitungs-Aufgaben zur Ausführung mittels der GPCs 208.
  • 3A ist ein Blockdiagramm der Aufgabe-/Arbeit-Einheit 207 von 2 gemäß einer Ausführungsform der vorliegenden Offenbarung. Die Aufgabe-/Arbeit-Einheit 207 umfasst eine Aufgabe-Management-Einheit 300 und die Arbeit-Verteilungs-Einheit 340. Die Aufgabe-Management-Einheit 300 organisiert Aufgaben, welche zu planen sind, basierend auf Ausführungs-Prioritäts-Niveaus. Für jedes Prioritäts-Niveau speichert die Aufgabe-Management-Einheit 300 eine Liste von Zeigern auf die TMDs 322, welche den Aufgaben entsprechen, in der Planer-Tabelle 321, wobei die Liste als eine verkettete Liste (linked list) implementiert sein kann. Die TMDs 322 können in dem PP-Speicher 204 oder System-Speicher 104 gespeichert sein. Die Rate, bei welcher die Aufgabe-Management-Einheit 300 Aufgaben annimmt und die Aufgaben in der Planer-Tabelle 321 speichert, ist entkoppelt von der Rate, bei welcher die Aufgabe-Management-Einheit 300 Aufgaben zur Ausführung plant. Daher kann die Aufgabe-Management-Einheit 300 einige Aufgaben sammeln, bevor die Aufgaben geplant werden. Die gesammelten Aufgaben können dann basierend auf Prioritäts-Information oder unter Benutzung anderer Techniken, wie etwa Ring-Verteilungs-Planung (round-robin), geplant werden.
  • Die Arbeit-Verteilungs-Einheit 340 umfasst eine Aufgabe-Tabelle 345 mit Fächern (slots), welche jeweils von einer TMD 322 für eine Aufgabe besetzt sein können, welche ausgeführt wird. Die Aufgabe-Management-Einheit 300 kann Aufgaben zur Ausführung planen, wenn es ein freies Fach in der Aufgabe-Tabelle 345 gibt. Wenn es kein freies Fach gibt, kann eine höhere-Priorität-Aufgabe, welche kein Fach besetzt, eine niedrigere Priorität-Aufgabe verdrängen oder ausschließen (evict), welche ein Fach besetzt. Wenn eine Aufgabe ausgeschlossen wird, wird die Aufgabe gestoppt und wenn Ausführung der Aufgabe nicht vollständig ist, dann wird ein Zeiger auf die Aufgabe an eine Liste von Aufgabe-Zeigern, welche auszuführen sind, so hinzugefügt, dass Ausführung der Aufgabe zu einer späteren Zeit wieder aufnehmen. Wenn eine Kind-Verarbeitungs-Aufgabe erzeugt ist, während einer Ausführung einer Aufgabe, wird ein Zeiger auf die Kind-Aufgabe an die Liste von Aufgabe-Zeigern, welche zu planen sind, hinzugefügt. Eine Kind-Aufgabe kann mittels einer TMD 322 erzeugt sein, welche in dem Verarbeitungs-Cluster-Feld 230 ausführt.
  • Unähnlich einer Aufgabe, welche mittels der Aufgabe-/Arbeit-Einheit 207 von dem Frontend 212 empfangen wird, werden Kind-Aufgaben von dem Verarbeitungs-Cluster-Feld 230 empfangen. Kind-Aufgaben werden nicht in Schiebe-Puffer eingefügt oder an das Frontend übermittelt. Die CPU 102 wird nicht benachrichtigt, wenn eine Kind-Aufgabe erzeugt ist oder Daten für die Kind-Aufgabe im Speicher gespeichert werden. Ein anderer Unterschied zwischen den Aufgaben, welche durch Schiebe-Puffer bereitgestellt sind, und Kind-Aufgaben ist, dass die Aufgaben, welche durch die Schiebe-Puffer bereitgestellt sind, mittels des Anwendungs-Programms definiert sind, wogegen die Kind-Aufgaben dynamisch während einer Ausführung der Aufgaben erzeugt sind.
  • Aufgabe-Verarbeitung-Überblick
  • 3B ist ein Blockdiagramm eines GPC 208 innerhalb einer der PPUs 202 der 2, gemäß einer Ausführungsform der vorliegenden Erfindung. Jeder GPC 208 kann konfiguriert sein, eine große Anzahl von Threads parallel auszuführen, wobei der Ausdruck „Thread” sich auf eine Instanz eines bestimmten Programms bezieht, welches auf einem bestimmten Satz von Eingabe-Daten ausführt. In einigen Ausführungsformen werden Einzel-Anweisung-, Mehr-Daten-(SIMD)-Befehls-Ausstellungs-Techniken benutzt, um eine parallele Ausführung einer großen Anzahl von Threads zu unterstützen, ohne mehrere unabhängige Anweisungs-Einheiten bereitzustellen. In anderen Ausführungsformen werden Einzel-Anweisung-, Mehrfach-Thread-(SIMT)-Techniken benutzt, um eine parallele Ausführung einer großen Anzahl von im Allgemeinen synchronisierten Threads zu unterstützen, unter Benutzung einer gemeinsamen Anweisungs-Einheit, welche konfiguriert ist, Anweisungen für einen Satz von Verarbeitungs-Maschinen innerhalb jedes der GPCs 208 auszustellen (issue). Unähnlich zu einem SIMD-Ausführungs-Regime, wobei alle Verarbeitungs-Maschinen typischerweise identische Anweisungen ausführen, erlaubt eine große SIMT-Ausführung verschiedenen Threads, leichter divergenten Ausführungspfaden durch ein gegebenes Thread-Programm zu folgen. Gewöhnliche Fachleute in der Technik werden verstehen, dass ein SIMD-Verarbeitungs-Regime eine funktionale Untermenge eines SIMT-Verarbeitungs-Regimes repräsentiert.
  • Betrieb von GPC 208 wird vorteilhafterweise über einen Pipeline-Manager 305 gesteuert, welcher Verarbeitungs-Aufgaben an Strömungs-Mehrfach-Prozessoren (streaming multiprocessors) (SMs) 310 verteilt. Pipeline-Manager 305 kann auch konfiguriert sein, eine Arbeitsverteilungs-Kreuzschiene (work distribution crossbar) 330 dadurch zu steuern, dass Ziele (destinations) für prozessierte Daten-Ausgaben mittels SMs 310 spezifiziert sind.
  • In einer Ausführungsform umfasst jede GPC 208 eine Anzahl M von SMs 310, wobei M ≥ 1, wobei jeder SM 310 konfiguriert ist, eine oder mehrere Thread-Gruppen zu verarbeiten. Auch umfasst jeder SM 310 vorteilhafterweise einen identischen Satz von funktionalen Ausführungseinheiten (z. B. Ausführungseinheiten und Lade-Speicher-Einheiten – gezeigt als Exec-Einheiten 302 und LSUs 303 in 3C), welche in einer Pipeline angeordnet sein können (pipelined), was erlaubt, eine neue Anweisung auszustellen, bevor eine vorherige Anweisung beendet worden ist, wie es in der Technik bekannt ist. Irgendeine Kombination von funktionalen Ausführungs-Einheiten kann bereitgestellt sein. In einer Ausführungsform unterstützen die funktionalen Einheiten eine Verschiedenheit von Operationen, einschließlich Ganzzahl-Arithmetik und Gleitzahl-Arithmetik (z. B. Addition und Multiplikation), Vergleichs-Operationen, Bool'sche Operationen (AND, OR, XOR), Bit-Verschiebung und Berechnen von verschiedenen algebraischen Funktionen (z. B. planare Interpolation, trigonometrische, exponentiale und logarithmische Funktionen); und dieselbe Funktional-Einheit-Hardware kann eingesetzt werden, um verschiedene Operationen durchzuführen.
  • Die Serie von Anweisungen, welche an eine bestimmte GPC 208 übermittelt wird, konstituiert einen Thread, wie vorher hierin definiert ist, und die Sammlung einer gewissen Anzahl von simultan ausführenden Threads über die Parallel-Verarbeitungs-Maschinen (nicht gezeigt) innerhalb eines SM 310 wird hierin als ein „Warp” oder „Thread-Gruppe” bezeichnet. Wie hierin benutzt, bezeichnet eine „Thread-Gruppe” eine Gruppe von Threads, welche simultan dasselbe Programm auf verschiedenen Eingabe-Daten ausführen, wobei ein Thread der Gruppe an eine verschiedene Verarbeitungs-Maschine innerhalb eines SM 310 zugewiesen ist. Eine Thread-Gruppe kann weniger Threads umfassen als die Anzahl von Verarbeitungs-Einheiten innerhalb des SM 310, in welchem Fall einige Verarbeitungs-Maschinen während Zyklen untätig sein werden, wenn diese Thread-Gruppe verarbeitet wird. Eine Thread-Gruppe kann auch mehr Threads umfassen als die Anzahl von Verarbeitungs-Maschinen innerhalb des SM 310, in welchem Fall die Verarbeitung über nachfolgende Taktzyklen stattfinden wird. Da jeder SM 310 bis zu G Thread-Gruppen gleichzeitig unterstützen kann, folgt, dass bis zu G·M Thread-Gruppen zu einer gegebenen Zeit in GPC 208 ausführen können.
  • Zusätzlich kann eine Mehrzahl von bezogenen Thread-Gruppen aktiv sein, in verschiedenen Phasen einer Ausführung, zu derselben Zeit innerhalb eines SPM 310. Diese Sammlung von Thread-Gruppen wird hierin als ein „kooperatives Thread-Feld” (cooperative thread array) („CTA”) oder „Thread-Feld” bezeichnet. Die Größe eines bestimmten CTA ist m·k, wobei k die Anzahl von gleichzeitig ausführenden Threads in einer Thread-Gruppe ist und typischerweise ein ganzzahliges Vielfaches der Anzahl von Parallel-Verarbeitungs-Einheiten innerhalb des SM 310 ist, und wobei m die Anzahl von Thread-Gruppen ist, welche simultan innerhalb des SM 310 aktiv sind. Die Größe eines CTA ist im Allgemeinen mittels des Programmierers bestimmt und mittels der Menge von Hardware-Ressourcen, wie Speicher oder Register, welche für das CTA verfügbar sind.
  • Jeder SM 310 beinhaltet einen Level-eins(L1)-Cache (in 3C gezeigt) oder benutzt Raum (space) in einem entsprechenden L1-Cache außerhalb des SM 310, welcher benutzt ist, um Lade- und Speicher-Operationen durchzuführen. Jeder SM 310 hat auch Zugriff auf Level-zwei(L2)-Caches, welche unter allen GPCs 208 gemeinsam benutzt oder geteilt sind (shared) und benutzt werden können, um Daten zwischen Threads zu transferieren. Schließlich haben die SMs 310 Zugriff auf Off-Chip „globalen” Speicher, welcher z. B. Parallel-Verarbeitungs-Speicher 204 oder System-Speicher 104 umfassen kann. Es ist verstanden, dass irgendein Speicher extern zu PPU 202 als globaler Speicher benutzt werden kann. Zusätzlich kann ein Level-eins-Komma-fünf(L1.5)-Cache 335 innerhalb des GPC 208 umfasst sein, welcher konfiguriert ist, Daten zu empfangen und zu halten, welche von dem Speicher über Speicher-Schnittstelle 214 geholt sind, abgefragt mittels SM 310, einschließlich Anweisungen, uniforme Daten und konstante Daten, und die angefragten Daten an SM 310 bereitzustellen. Ausführungsformen, welche mehrere SMs 310 in GPC 208 haben, teilen oder benutzen gemeinsam (share) in vorteilhafter Weise gemeinsame Anweisungen und Daten, welche in L1.5-Cache 335 gecached sind.
  • Jeder GPC 208 kann eine Speicher-Management-Einheit (MMU) 328 umfassen, welche konfiguriert ist, virtuelle Adressen in physikalische Adressen abzubilden (map). In anderen Ausführungsformen, können MMU(s) 328 innerhalb der Speicher-Schnittstelle 214 ansässig sein (reside). Die MMU 328 umfasst einen Satz von Seite-Tabelle-Einträgen (page table entry) (PTEs), welche benutzt werden, um eine virtuelle Adresse in eine physikalische Adresse einer Kachel (tile) und optional einen Cache-Zeilen-Index abzubilden.
  • Die MMU 328 kann Adresse-Übersetzungs-Puffer (translation lookaside buffer) (TLB) oder Caches umfassen, welche innerhalb des Mehrfach-Prozessors SM 310 oder dem L1-Cache oder GPC 208 ansässig sein können. Die physikalische Adresse ist verarbeitet, um Oberflächendaten-Zugriffslokalität zu verteilen, um eine effiziente Abfrage-Verschachtelung (interleaving) unter Partitions-Einheiten 215 zu erlauben. Der Cache-Zeile-Index kann benutzt werden, um zu bestimmen, ob eine Anfrage nach einer Cache-Zeile ein Treffer ist oder eine Verfehlung ist oder nicht.
  • In Grafik- und Berechnungs-Anwendungen kann ein GPC 208 derart konfiguriert sein, dass jeder SM 310 mit einer Textur-Einheit 315 zum Durchführen von Textur-Abbildungs-Operationen gekoppelt ist, z. B. Bestimmen von Textur-Proben-Positionen (texture sample position), Lesen von Textur-Daten und Filtern der Textur-Daten. Textur-Daten werden von einem internen Textur-L1-Cache (nicht gezeigt) oder in einigen Ausführungsformen von dem L1-Cache innerhalb von SM 310 gelesen und werden von einem L2-Cache, welcher unter allen GPCs 208 geteilt ist, Parallel-Verarbeitungs-Speicher 204 oder System-Speicher 104 wie benötigt geholt. Jeder SPM 310 gibt verarbeitete Aufgaben an die Arbeits-Verteilungs-Kreuzschiene 330 aus, um die verarbeitete Aufgabe an einen anderen GPC 208 für weitere Verarbeitung bereitzustellen oder um die verarbeitete Aufgabe in einem L2-Cache, Parallel-Verarbeitungs-Speicher 204 oder System-Speicher 104 über Kreuzschiene-Einheit 210 zu speichern. Ein preROP (Vorraster-Operationen) 325 ist konfiguriert, um Daten von SM 310 zu empfangen, Daten an ROP-Einheiten innerhalb der Partitions-Einheiten 215 zu richten, und Optimierungen für Farbmischung durchzuführen, Pixel-Farbdaten zu organisieren und Adress-Translationen durchzuführen.
  • Es wird geschätzt werden, dass die hierin beschriebene Kern-Architektur illustrativ ist und dass Variationen und Modifikationen möglich sind. Irgendeine Anzahl von Verarbeitungs-Einheiten, z. B. SPMs 310 oder Textur-Einheiten 315, preROPs 325, können innerhalb eines GPC 208 umfasst sein kann. Ferner, wie in 2 gezeigt ist, kann eine PPU 202 irgendeine Anzahl von GPCs 208 umfassen, welche vorteilhafterweise funktionell ähnlich zueinander sind, so dass ein Ausführungs-Verhalten nicht davon abhängt, welcher GPC 208 eine bestimmte Verarbeitungs-Aufgabe empfängt. Ferner operiert jeder GPC 208 vorteilhafterweise unabhängig von anderen GPCs 208 unter Benutzung von separaten und distinkten Verarbeitungs-Einheiten L1-Caches, usw., um Aufgaben für ein oder mehr Anwendungsprogramme auszuführen.
  • Gewöhnliche Fachleute in der Technik werden verstehen, dass die in 1, 2, 3A und 3B beschriebene Architektur in keiner Weise den Geltungsbereich der vorliegenden Erfindung begrenzt und dass die hierin gelehrten Techniken auf irgendeiner korrekt konfigurierten Verarbeitungs-Einheit implementiert werden können, einschließlich ohne Begrenzung eine oder mehrere CPUs, eine oder mehrere Mehr-Kern-CPUs, eine oder mehrere PPUs 202, ein oder mehrere GPCs 208, eine oder mehrere Grafik- oder Spezialzweck-Verarbeitungs-Einheiten, oder dergleichen, ohne von dem Geltungsbereich der vorliegenden Erfindung abzuweichen.
  • In Ausführungsformen der vorliegenden Erfindung ist es wünschenswert, die PPU 202 oder andere Prozessor(en) eines Computer-Systems zu benutzen, um Allgemeinzweck-Berechnungen unter Benutzung von Thread-Feldern auszuführen. Jedem Thread in dem Thread-Feld ist ein eindeutiger Thread-Identifikator („Thread-ID”) zugewiesen, welcher für den Thread während Ausführung des Threads zugreifbar ist. Die Thread-ID, welche als ein eindimensionaler oder mehrdimensionaler numerischer Wert definiert werden kann, steuert verschiedene Aspekte des Verarbeitungs-Verhaltens des Threads. Zum Beispiel kann eine Thread-ID benutzt werden, um zu bestimmen, welchen Teil des Eingabe-Datensatzes ein Thread zu prozessieren hat, und/oder zu bestimmen, welchen Teil eines Ausgabe-Datensatzes ein Thread zu erzeugen hat oder zu schreiben hat.
  • Eine Sequenz von Pro-Thread-Anweisungen kann zumindest eine Anweisung umfassen, welche ein kooperatives Verhalten zwischen dem repräsentativen Thread und einem oder mehreren anderen Threads des Thread-Feldes definiert. Zum Beispiel könnte die Sequenz von Pro-Thread-Anweisungen eine Anweisung umfassen, um eine Ausführung von Operationen für den repräsentativen Thread bei einem bestimmten Punkt in der Sequenz anzuhalten (suspend), bis zu einer solchen Zeit, wenn einer oder mehrere der anderen Threads diesen bestimmten Punkt erreichen, eine Anweisung für den repräsentativen Thread, Daten in einem gemeinsamen Speicher zu speichern, auf welchen einer oder mehrere der anderen Threads zugreifen können, eine Anweisung für den repräsentativen Thread, um atomar Daten zu lesen und zu aktualisieren, welche in einem gemeinsamen Speicher gespeichert sind, auf welchen einer oder mehrere der anderen Threads Zugriff haben, basierend auf ihren Thread-IDs, oder dergleichen. Das CTA-Programm kann auch eine Anweisung umfassen, um eine Adresse in dem gemeinsamen Speicher zu berechnen, von welchem Daten zu lesen sind, wobei die Adresse eine Funktion der Thread-ID ist. Mittels eines Definierens von geeigneten Funktionen und mittels eines Bereitstellens von Synchronisations-Techniken können Daten auf eine bestimmte Stelle in dem gemeinsamen Speicher mittels eines Threads eines CTA geschrieben werden und von dieser Stelle mittels eines verschiedenen Threads desselben CTA in einer vorhersagbaren Weise gelesen werden. Folglich kann irgendein gewünschtes Muster von Daten-gemeinsam-Benutzen (data sharing) unter Threads unterstützt werden, und irgendein Thread in einem CTA kann mit irgendeinem anderen Thread in demselben CTA Daten gemeinsam nutzen bzw. teilen (share). Das Ausmaß, wenn überhaupt, eines gemeinsamen Benutzens von Daten unter Threads eines CTA ist mittels des CTA-Programms bestimmt; somit wird verstanden, dass in einer bestimmten Anwendung, welche CTAs benutzt, die Threads eines CTA tatsächlich Daten miteinander teilen bzw. benutzen könnten oder nicht, abhängig von dem CTA-Programm, und die Ausdrucke „CTA” und „Thread-Feld” werden hierin synonym benutzt.
  • 3C ist ein Blockdiagramm des SM 310 von 3B gemäß einer Ausführungsform der vorliegenden Erfindung. Der SM 310 umfasst einen Anweisungs-L1-Cache 370, welcher konfiguriert ist, Anweisungen und Konstanten von Speicher über L1.5-Cache 335 zu empfangen. Eine Warp-Planer-(warp scheduler) und -Anweisungs-Einheit 312 empfängt Anweisungen und Konstanten von dem Anweisungs-L1-Cache 370 und steuert eine lokale Register-Datei 304 und SM 310 funktionale Einheiten gemäß den Anweisungen und Konstanten. Die SM 310 funktionalen Einheiten umfassen N exec (Ausführung- oder Verarbeitung-)-Einheiten 302 und P Lade-Speicher-Einheiten (LSU) 303.
  • SM 310 stellt Auf-Chip-(on-chip)-(internen)-Daten-Speicher mit verschiedenen Zugriffs-Niveaus bereit. Spezielle Register (nicht gezeigt) sind lesbar aber nicht schreibbar mittels LSU 303 und werden benutzt, um Parameter zu speichern, welche eine „Position” jedes Threads definieren. In einer Ausführungsform umfassen spezielle Register ein Register pro Thread (oder pro exec-Einheit 302 innerhalb SM 310), welches eine Thread-ID speichert; jedes Thread-ID-Register ist nur mittels einer jeweiligen der exec-Einheit 302 zugreifbar. Spezielle Register können auch zusätzliche Register umfassen, welche mittels aller Threads lesbar sind, welche dieselbe Verarbeitungs-Aufgabe ausführen, welche mittels einer TMD 322 repräsentiert ist (oder mittels aller LSUs 303), welche einen CTA-Identifikator, die CTA-Dimensionen, die Dimensionen eines Gitters, zu welchem die oder das CTA gehört (oder Queue-Position, wenn die TMD 322 eine Queue-Aufgabe anstatt einer Gitter-Aufgabe kodiert), und einen Identifikator der TMD 322, an welche das CTA zugewiesen ist, speichert.
  • Wenn die TMD 322 eine Gitter-TMD ist, führt eine Ausführung der TMD 322 dazu, dass eine fixe Anzahl von CTAs angestoßen wird und ausgeführt wird, um die fixe Menge von Daten zu verarbeiten, welche in der Queue 525 gespeichert sind. Die Anzahl von CTAs ist als das Produkt der Gitter-Breite, -Höhe und -Tiefe spezifiziert. Die fixe Menge von Daten kann in der TMD 322 gespeichert werden oder die TMD 322 kann einen Zeiger auf die Daten speichern, welche mittels der CTAs verarbeitet werden. Die TMD 322 speichert auch eine Start-Adresse des Programms, welches mittels der CTAs ausgeführt ist.
  • Wenn die TMD 322 eine Queue-TMD ist, dann wird ein Queue-Merkmal der TMD 322 benutzt, was bedeutet, dass die Menge von zu prozessierenden Daten nicht notwendiger Weise fix ist. Queue-Einträge speichern Daten zur Verarbeitung mittels der CTAs, welche der TMD 322 zugewiesen sind. Die Queue-Einträge können auch eine Kind-Aufgabe repräsentieren, welche mittels einer anderen TMD 322 während einer Ausführung eines Threads erzeugt ist, wodurch ein geschachtelter Parallelismus bereitgestellt ist. Typischerweise wird Ausführung des Threads, oder des CTA, welches den Thread umfasst, angehalten oder unterbrochen (suspended), bis Ausführung der Kind-Aufgabe vollendet. Die Queue kann in der TMD 322 gespeichert sein oder separat von der TMD 322, in welchem Fall die TMD 322 einen Queue-Zeiger auf die Queue speichert. Vorteilhafter Weise können Daten, welche mittels der Kind-Aufgabe erzeugt sind, an die Queue geschrieben werden, während die TMD 322, welche die Kind-Aufgabe repräsentiert, ausführt. Die Queue kann als eine zirkuläre Queue implementiert sein, so dass die gesamte Menge von Daten nicht auf die Größe der Queue begrenzt ist.
  • CTAs, welche zu einem Gitter gehören, haben implizit Gitter-Breite-, -Höhe- und -Tiefe-Parameter, welche die Position des entsprechenden CTA innerhalb des Grids anzeigen. Spezielle Register werden während einer Initialisierung in Antwort auf Befehle geschrieben, welche über Frontend 212 von Geräte-Treiber 103 empfangen sind und ändern sich nicht während der Ausführung einer Verarbeitungs-Aufgabe. Das Frontend 212 plant jede Verarbeitungs-Aufgabe zur Ausführung. Jedes CTA ist mit einer spezifischen TMD 322 zur gleichzeitigen Ausführung von einer oder mehr Aufgaben assoziiert. Zusätzlich kann ein einzelnes GPC 208 mehrere Aufgaben gleichzeitig ausführen.
  • Ein Parameter-Speicher (nicht gezeigt) speichert Laufzeit-Parameter (Konstanten), welche gelesen werden können aber welche nicht mittels irgendeines Threads innerhalb desselben CTA (oder irgendeiner LSU 303) geschrieben werden können. In einer Ausführungsform stellt der Gerätetreiber 103 Parameter für den Parameter-Speicher bereit, bevor der SM 310 darauf gerichtet wird, eine Ausführung einer Aufgabe zu beginnen, welche diese Parameter benutzt. Irgendein Thread innerhalb irgendeines CTA (oder irgendeine exec-Einheit 302 innerhalb SM 310) kann auf globalen Speicher durch eine Speicher-Schnittstelle 214 zugreifen. Teile von globalem Speicher können in dem L1-Cache 320 gespeichert sein.
  • Lokale Register-Datei 304 ist mittels jedes Threads als ein Notizzettel-Raum (scratch spase) benutzt; jedes Register wird für die exklusive Benutzung eines Threads alloziert und Daten in irgendeiner Register-Datei 304 sind nur von dem Thread zugreifbar, an welchen das Register alloziert ist. Die lokale Register-Datei 304 kann als eine Register-Datei implementiert sein, welche physikalisch oder logisch in P Spuren oder Bahnen aufgeteilt ist, wobei jede irgendeine Anzahl von Einträgen hat (wobei jeder Eintrag z. B. ein 32-Bit-Wort speichern könnte). Eine Spur ist jeder der N exec-Einheiten 302 und P Lade-Speicher-Einheiten LSU 303 zugewiesen und entsprechende Einträge in verschiedenen Spuren können mit Daten für verschiedene Threads populiert sein, welche dasselbe Programm ausführen, um eine SIMD-Ausführung zu ermöglichen. Verschiedene Teile der Spuren können an verschiedene der G gleichzeitigen Thread-Gruppen alloziert sein, so dass ein gegebener Eintrag in der lokalen Register-Datei 304 nur für einen bestimmten Thread zugreifbar ist. In einer Ausführungsform werden gewisse Einträge innerhalb der lokalen Register-Datei 304 zum Speichern von Thread-Identifikatoren reserviert, welche eines der speziellen Register implementieren. Zusätzlich speichert ein L1-Cache 375 uniforme oder konstante Werte für jede Spur der N exec-Einheiten 302 und P Lade-Speicher-Einheiten LSU 303.
  • Gemeinsamer Speicher 306 ist für alle Threads (innerhalb eines einzelnen CTA) zugreifbar; mit anderen Worten, ist irgendeine Stelle in dem gemeinsamen Speicher 306 für irgendeinen Thread innerhalb desselben CTA zugreifbar (oder für irgendeine Verarbeitungs-Maschine innerhalb SM 310). Der gemeinsame Speicher 306 kann als eine gemeinsam benutzte oder geteilte (shared) Register-Datei oder ein gemeinsamer On-Chip-Cache-Speicher implementiert sein mit einer Zwischenverbindung, welche irgendeiner Verarbeitungs-Maschine erlaubt, von oder auf irgendeine Stelle in dem gemeinsamen Speicher zu lesen oder zu schreiben. In anderen Ausführungsformen könnte der gemeinsame Zustandsraum (shared state space) auf eine Pro-CTA-Region von Off-Chip-Speicher abbilden und könnte in L1-Cache 320 gecached sein. Der Parameter-Speicher kann als ein designierter Abschnitt innerhalb derselben gemeinsamen Register-Datei oder des gemeinsamen Cache-Speichers implementiert sein, welcher den gemeinsamen Speicher 306 implementiert, oder als eine separate gemeinsame Register-Datei oder ein On-Chip-Cache-Speicher, auf welchen die LSUs 303 nur-Lese-Zugriff haben. In einer Ausführungsform ist der Bereich, welcher den Parameter-Speicher implementiert, auch dazu benutzt, um die CTA-ID und die Aufgabe-ID zu speichern, sowie CTA- und Gitter-Dimensionen oder Queue-Position, wobei Teile der speziellen Register implementiert sind. Jede LSU 303 in SM 310 ist mit einer unifizierten Adress-Abbildungs-Einheit 352 gekoppelt, welche eine Adresse, welche für Lade- und Speicher-Befehle bereitgestellt ist, welche in einem unifizierten Speicher-Raum spezifiziert ist, in eine Adresse in jedem distinkten Speicherraum zu konvertieren. Folglich kann eine Anweisung genutzt werden, um auf irgendwelche der lokalen, gemeinsamen oder globalen Speicherräume dadurch zuzutreiben, dass eine Adresse in dem unifizierten Speicherraum spezifiziert wird.
  • Der L1-Cache 320 in jedem SM 310 kann benutzt werden, um private Pro-Thread-lokale-Daten und auch Pro-Applikation-globale-Daten zu cachen. In einigen Ausführungsformen können die Pro-CTA-geteilten Daten in dem L1-Cache 320 gecached werden. Die LSUs 303 sind mit dem gemeinsamen Speicher 306 und dem L1-Cache 320 über eine Speicher- und Cache-Zwischenverbindung 380 gekoppelt. Der uniforme Cache 375 ist konfiguriert, nur-Lese-Daten und Konstanten von Speicher über den L1.5-Cache 335 zu empfangen.
  • Zuvor-geplante Wiederholungen von divergenten Operationen
  • 4 illustriert eine Mehr-Stufe-Pipeline 400, welche konfiguriert ist, zuvor-geplante Wiederholungen von divergenten Operationen zu implementieren, gemäß einer Ausführungsform der vorliegenden Erfindung. Wie gezeigt ist, umfasst die Mehr-Stufe-Pipeline 400 eine Zuvor-geplante-Wiederholen-Einheit 420, Pipeline-Stufen 402, Logik-Elemente 404, eine Wiederholen-Einheit 406 und einen Wiederholen-Multiplexer 408. In verschiedenen Implementierungen ist die Mehr-Stufe-Pipeline 400 innerhalb einer Exec-Einheit 302 oder einer LSU 303 des Streaming-Multiprozessors (SM) 310 ansässig, wie in 3C gezeigt ist.
  • Die Zuvor-geplante-Wiederholen-Einheit 420 empfängt eine neue Anweisung 412, wenn die Anweisung in die Mehr-Stufe-Pipeline 400 eintritt. Wenn eine neue Anweisung 412 in die Mehr-Stufe-Pipeline 400 eintritt, bestimmt die Exec-Einheit 302, ob die Anweisung eine gemeinsame-Ressource-Zugriffs-Operation ist, welche von einem Benutzen von Zuvorgeplante-Wiederholen-Operationen profitieren kann. Wenn die neue Anweisung 412 eine gemeinsame-Ressource-Zugriffs-Operation ist, dann wählt die LSU 303 einen ersten Thread von der Gruppe von Threads aus, welche geplant sind, die Anweisung auszuführen. Die LSU 303 wählt eine Gruppe von Threads, welche mit dem ersten Thread assoziiert sind, aus, wobei die Gruppe von Threads sämtlich die gemeinsame-Ressource-Zugriffs-Operation innerhalb eines einzelnen Ausführungs-Durchgangs der Mehr-Stufe-Pipeline 400 vollenden können. Solch eine Gruppe von Threads wird hierin als eine Thread-Familie identifiziert. Die Thread-Familie, welche mit dem ersten Thread assoziiert ist, kann gleichzeitig mit einem Auswählen des ersten Threads ausgewählt werden, oder die Thread-Familie kann zu einem späteren Zeitpunkt bestimmt werden. Die LSU 303 wählt dann einen oder mehrere zusätzliche Threads aus, um während des anfänglichen Durchganges durch die Mehr-Stufe-Pipeline 400 zu verarbeiten. Die zusätzlichen Threads werden auf der Basis ausgewählt, dass sie unbedient bleiben können, nachdem die Anweisung für den ersten Thread und die erste Thread-Familie ausgeführt ist. Die LSU 303 wählt Thread-Familien aus, welche mit jedem der zusätzlichen Threads assoziiert sind. Die mit jedem zusätzlichen Thread assoziierte Thread-Familie kann gleichzeitig mit einem Auswählen der zusätzlichen Threads ausgewählt werden, oder die Thread-Familien können zu einem späteren Zeitpunkt bestimmt werden. Bis zu B Operationen können zum Verarbeiten während des anfänglichen Durchgangs ausgewählt werden, wobei B die anfängliche Anweisung für den ersten Thread und die Zuvor-geplante-Wiederholen-Operationen für die zusätzlich ausgewählten Threads beinhaltet. Die Exec-Einheit 302 fügt eine Operation in die Mehr-Stufe-Pipeline, über die Zuvor-geplante-Wiederholen-Einheit 420, ein, um die Anweisung für den ersten Thread und die erste Thread-Familie auszuführen. Sobald die anfängliche Operation, welche mit dem ersten Thread assoziiert ist, Pipeline-Stufe 402(0) erreicht, fügt die Exec-Einheit 302, über die Zuvor-geplante-Wiederholen-Einheit 420, die Zuvor-geplante-Wiederholen-Operationen, welche mit den zusätzlichen Threads assoziiert sind, seriell mit der anfänglichen Operation ein.
  • Pipeline-Stufen 402 speichern Zwischenergebnisse für verschiedene Anweisungen und sie progressieren durch Mehr-Stufe-Pipeline 400. Die Pipeline-Stufen 402 speichern die Zwischenergebnisse bei dem Beginn jedes Taktzyklus der Mehr-Stufe-Pipeline 400. Mehrere Anweisungen können in der Mehr-Stufe-Pipeline 400 bei verschiedenen Stufen eines Fortschrittes vorhanden sein. Zum Beispiel tritt eine Anweisung in die Mehr-Stufe-Pipeline 400 ein und wird in die Pipeline-Stufe 402(0) bei dem Beginn eines spezifischen Taktzyklus gespeichert. Bei dem Beginn des nächsten Taktzyklus progressiert diese Anweisung zu Pipeline-Stufe 402(1), während eine andere Anweisung in die Mehr-Stufe-Pipeline 400 eintritt und in die Pipeline-Stufe 402(0) gespeichert wird. Jede Anweisung progressiert typischerweise eine Pipeline-Stufe 402 für jeden Taktzyklus der Mehr-Stufe-Pipeline 400.
  • Logik-Elemente 404 separieren die Pipeline-Stufen 402. Logik-Elemente 404 können irgendeine Funktion durchführen, welche von dem SM 310 erfordert ist, einschließlich, ohne Begrenzung, arithmetische Operationen, logische Operationen, und Lade-/Speicher-Operationen. Zum Beispiel wird eine Anweisung, welche in Pipeline-Stufe 402(0) gespeichert ist, als eine Eingabe an Logik-Element 404(0) präsentiert. Nach einer Verzögerungs-Periode wird die Ausgabe von Logik-Element 404(0) als ein funktionales Ergebnis für die Eingabe von Pipeline-Stufe 402(1) präsentiert. Dieses Ergebnis wird dann in Pipeline-Stufe 402(1) bei dem nächsten Taktzyklus der Mehr-Stufe-Pipeline 400 gespeichert. In dieser Weise führt die Anweisung die verschiedenen Funktionen durch, welche mittels der Logik-Elemente 404 bestimmt sind, wenn die Anweisung entlang den Pipeline-Stufen 402 voranschreitet. Die Anweisung schreitet durch die Mehr-Stufe-Pipeline 400 mit jedem Taktzyklus fort, bis die Anweisung durch alle Pipeline-Stufen 402 hindurch passiert ist. Im Allgemeinen ist die Gesamt-Latenz durch die Mehr-Stufe-Pipeline 400 gleich der Anzahl von Pipeline-Stufen 402 innerhalb der Mehr-Stufe-Pipeline 400 multipliziert mit der Zeitperiode zwischen aufeinander folgenden Pipeline-Taktzyklen. Die Verzögerung durch die Logik-Elemente 404 ist typischerweise niedrig, um die Taktzyklus-Zeit für die Pipeline-Stufen 402 zu minimieren, um dadurch Pipeline-Performance zu maximieren. Sobald die Anweisung Pipeline-Stufe 402(S-1) erreicht, bestimmt die LSU 303, dass die Anweisung auf eine gemeinsame Ressource zugreift, wie etwa eine Anweisung, um auf eine Speicherstelle zuzugreifen, welche innerhalb eines Zwischenspeichers gespeichert ist. Die LSU 303 transferiert eine Zwischenspeicher-Zeile, welche mittels zumindest eines Threads referenziert ist, und bedient alle Threads, welche auf dieselbe Zwischenspeicher-Zeile zugreifen. Wenn eine Zuvorgeplante-Wiederholen-Operation, welche mit der Anweisung assoziiert ist, in die Mehr-Stufe-Pipeline 400 eingefügt worden ist, dann transferiert die LSU 303 eine Zwischenspeicher-Zeile, welche mittels zumindest eines Threads referenziert ist, referenziert in der Zuvor-geplante-Wiederholen-Operation und bedient alle Threads, welche auf dieselbe Zwischenspeicher-Zeile zugreifen. Die LSU 303 wiederholt den Prozess für irgendeine andere Zuvor-geplante-Wiederholen-Operation, welche mit der Anweisung assoziiert ist. Wenn einige Threads nach Verarbeitung der Anweisung und der Zuvor-geplante-Wiederholen-Operationen unbedient bleiben, dann bereitet die LSU 303 zusätzliche Wiederholen-Operationen wie erfordert vor und übergibt bzw. passiert die Wiederholen-Operationen an die Wiederholen-Einheit 406 über die Wiederholen-Schleife 410.
  • Die Wiederholen-Einheit 406 empfängt Wiederholen-Operationen über Wiederholen-Schleife 410 und fügt die verschiedenen Wiederholen-Operationen zurück in die Mehrprozess-gestützte (multi-threaded) Pipeline 400 ein. Wiederholen-Operationen sind für eine divergente gemeinsame Ressource implementiert, wo ein oder mehrere Threads unbedient bleiben nach einem Prozessieren der anfänglichen Operation, welche einer gemeinsamen-Ressource-Zugriffs-Anweisung entspricht und irgendwelchen assoziierten Zuvor-geplante-Wiederholen-Operationen. In solch einem Fall fügt die Wiederholen-Einheit 406 eine oder mehrere Wiederholen-Operationen in der Mehr-Stufe-Pipeline 400 über Eingabe 416 von Wiederholen-Multiplexer 408 ein. Die Wiederholen-Operationen schreiten durch die Mehr-Stufe-Pipeline 400 fort. Sobald eine Wiederholen-Operation Logik-Element 404(S-1) erreicht, bestimmt die LSU 303, ob irgendwelche unbedienten Threads verbleiben. Wenn es irgendwelche unbediente Threads gibt, dann bereitet die LSU 303 eine oder mehrere Wiederholen-Operationen in der oben diskutierten Weise vor, bis alle Threads, welche mit einer gegebenen Anweisung assoziiert sind, bedient worden sind.
  • Der Wiederholen-Multiplexer 408 wählt aus, ob neuen Anweisungen 412 oder Wiederholen-Operationen erlaubt ist, in die Mehr-Stufe-Pipeline 400 bei Pipeline-Stufe 402(0) einzutreten. Der Wiederholen-Multiplexer 408 ist mittels des Wiederholen-Indikators 414 gesteuert. Anfänglich ist der Wiederholen-Indikator 414 gesetzt, um Eingabe 418 des Wiederholen-Multiplexers 408 auszuwählen. Eine hereinkommende neue Anweisung 412 passiert durch die Zuvor-geplante-Wiederholen-Einheit 420, zu Eingabe 418 des Wiederholen-Multiplexers 408, und dann zu der Eingabe bzw. Eingang der ersten Pipeline-Stufe 402(0). Wie oben beschrieben ist, können, wenn die LSU 303 eine divergente Operation detektiert, dann eine oder mehrere Wiederholen-Operationen erfordert sein, um die Anweisung über alle Threads zu vollenden. Die Exec-Einheit 302 erlaubt, dass Zuvor-geplante-Wiederholen-Operationen, wenn überhaupt, von der Zuvor-geplante-Wiederholen-Einheit 420 in die Mehr-Stufe-Pipeline 400 über Eingabe 418 von Wiederholen-Multiplexer 408 eingesetzt werden. Wenn nach Verarbeiten der anfänglichen Operation und der assoziierten Zuvor-geplante-Operationen Threads unbedient verbleiben, dann behauptet bzw. versichert (asserts) die LSU 303 den Wiederholen-Indikator 414, um Eingabe 416 des Wiederholen-Multiplexers 408 auszuwählen. In Antwort darauf passieren eine oder mehrere Wiederholen-Operationen von der Wiederholen-Einheit 406 durch die Wiederholen-Schleife 410, an Eingabe 416 des Wiederholen-Multiplexers 408, und dann zu der Eingabe der ersten Pipeline-Stufe 402(0). Sobald die Wiederholen-Operationen in die Mehr-Stufe-Pipeline 400 eingetreten sind, kann die LSU 303 den Wiederholen-Indikator 414 entfernen, um neuen Anweisungen 412 zu erlauben, wiederum in die Mehr-Stufe-Pipeline 400 über Eingabe 418 des Wiederholen-Multiplexers 408 einzutreten. Sobald eine Wiederholen-Operation durch die Mehr-Stufe-Pipeline 400 verarbeitet worden ist, bestimmt die LSU 303, ob alle Threads bedient worden sind. Wenn einige Threads unbedient bleiben, dann versichert bzw. behauptet die LSU 303 den Wiederholen-Indikator 414, passiert eine andere Wiederholen-Operation durch die Wiederholen-Schleife 410 und entfernt dann den Wiederholen-Indikator 414. Der Prozess dauert an, bis alle Threads bedient sind, d. h. bis alle Threads die Anweisung, welche mit der gemeinsamen-Ressource-Zugriffs-Operation assoziiert ist, ausgeführt haben.
  • Die neue Anweisung 412 kann Ausführungen für alle Threads während einer Ausführung der anfänglichen Operation, während Ausführung einer der Zuvor-geplante-Wiederholen-Operationen oder später vollenden. Sobald z. B. die anfängliche Operation, welche mit dem ersten Thread und der entsprechenden Thread-Familie assoziiert ist, verarbeitet ist, kann die LSU 303 bestimmen, dass alle Threads bedient worden sind. In diesem Fall sind keine Zuvor-geplante-Wiederholen-Operationen erfordert. Wenn irgendwelche Zuvor-geplante-Wiederholen-Operationen in die Mehr-Stufe-Pipeline 400 eingefügt wurden, dann verwirft die LSU 303 die Zuvor-geplanten Wiederholungen. In einem anderen Beispiel können die Zuvor-geplante-Wiederholen-Operationen, welche mittels der Zuvor-geplante-Wiederholen-Einheit 420 eingefügt sind, in der Lage sein, diejenigen Threads zu bedienen, welche die Anweisung nicht während der Verarbeitung der anfänglichen Operation ausführten. In diesem Fall dienten eine oder mehrere der Zuvorgeplante-Wiederholen-Operationen dazu, Latenz dadurch zu vermindern, dass sie zur Ausführung seriell mit der anfänglichen Operation geplant sind. In einem anderen Beispiel bleiben einige Threads unbedient selbst nach Prozessierung bzw. Verarbeitung der anfänglichen Operation und der Zuvorgeplante-Wiederholen-Operationen. In solch einem Fall können die Zuvorgeplante-Wiederholen-Operationen die Ausführungs-Latenz der Anweisung vermindert haben, aber mehr Operationen können erfordert sein als mittels eines einzelnen Durchgangs durch die Mehr-Stufe-Pipeline 400 verarbeitet werden könnten. Threads, welche für Zuvor-geplante-Wiederholen-Operationen ausgewählt sind, können in irgendeiner technisch machbaren Weise ausgewählt werden. Solche Threads werden typischerweise ausgewählt, um die Wahrscheinlichkeit zu erhöhen, dass die ausgewählten Threads nicht in derselben Thread-Familie wie irgendwelche anderen ausgewählten oder wie irgendein anderer ausgewählter Thread ist, während die Komplexität der Zuvor-geplante-Wiederholen-Einheit 420 begrenzt ist, um Zeit-, Energie-, und Raum-Anforderungen der Mehr-Stufe-Pipeline 400 zu erfüllen.
  • Die Threads, welche für Zuvor-geplante-Wiederholen-Operationen während des anfänglichen Durchgangs ausgewählt wurden, können Thread-Familien repräsentieren, welche tatsächlich separate Wiederholen-Operationen erforderten. In solch einem Fall vermindert oder eliminiert die Zuvor-geplante-Wiederholen-Operation die Anzahl von Wiederholen-Operationen durch die Wiederholen-Schleife 410, um dadurch eine Gesamt-Ausführungs-Latenz zu vermindern. Wenn Threads, welche für Zuvor-geplante-Wiederholen-Operationen ausgewählt wurden, während der anfänglichen Operation oder einer vorherigen Zuvor-geplante-Wiederholen-Operation verarbeitet worden sind, dann wird die assoziierte Zuvor-geplante-Wiederholen-Operation verworfen. Ein Fachmann der Technik wird verstehen, wie der Wert von Zuvor-geplante-Wiederholen-Operation gegenüber der möglichen Gelegenheitskosten, welche mit einem Verzögern von neuen Operationen assoziiert sind, zu evaluieren ist.
  • Die Exec-Einheit 302 kann irgendeinen von einem oder mehreren einer Anzahl von Zugangsweisen verwenden, um zu bestimmen, ob Zuvorgeplante Wiederholungen in die Mehr-Stufe-Pipeline 400 einzusetzen sind. Zum Beispiel kann die Zuvor-geplante-Wiederholen-Einheit 420 bestimmen, dass eine neue Anweisung 412 eine Wiederholen-Operation erfordert basierend auf der Anweisung selbst. Wenn eine Anweisung einen 128-Bit-Operanden erfordert, die gemeinsame Ressource, welche mit dem Operanden assoziiert ist, jedoch einen 64-Bit-Daten-Pfad hat, dann weiß die Exec-Einheit 302, dass zumindest eine Wiederholen-Operation erfordert sein wird, um 128-Bit von Daten über den 64-Bit-Daten-Pfad abzurufen. In solch einem Fall kann die Exec-Einheit 302 eine Zuvor-geplante-Wiederholen-Operation seriell mit der anfänglichen Operation einfügen. In einem anderen Beispiel kann die Exec-Einheit 302 probabilistisch bestimmen, dass eine Zuvor-geplante-Wiederholen-Operation von einer neuen Anweisung 412 erfordert sein kann. Gewisse Anweisungen können eine hohe Wahrscheinlichkeit haben, eine Wiederholen-Operation zu erfordern. In solch einem Fall kann die Exec-Einheit 302 bestimmen, eine oder mehrere Zuvor-geplante-Wiederholen-Operationen seriell mit der anfänglichen Operation einfügen, wenn die Wahrscheinlichkeit gegeben ist, dass die Zuvor-geplanten Wiederholungen tatsächlich benutzt werden. Wenn die LSU 303 später bestimmt, dass die zuvor-geplanten Wiederholungen nicht benötigt wurden, dann kann die LSU 303 die unbenutzten Zuvor-geplante-Wiederholen-Operationen verwerfen. In einem anderen Beispiel kann die neue Anweisung 412 einen Befehl umfassen, um eine oder mehrere Zuvor-geplante-Wiederholen-Operationen zu erzeugen, welche mit der neuen Anweisung 412 assoziiert sind. Die Befehle können manuell mittels eines Software-Programmierers oder automatisch mittels des Compilers zur Kompilierungs-Zeit eingefügt werden. In solch einem Fall können prädiktive Modelle, welche für den Software-Programmierer oder den Compiler verfügbar sind, eine hohe Wahrscheinlichkeit anzeigen, dass eine oder mehrere Zuvor-geplante-Wiederholen-Operationen mittels der assoziierten Anweisungen erfordert sind. Zusätzlich kann der Compiler Einfüge-Zeit-Information (insert timing Information) über einen „Wiederholen-Befehl” einfügen, um spezifische Zuvor-geplante-Wiederholen-Operationen zu planen, in die Mehr-Stufe-Pipeline 400 bei spezifischen Zeiten relativ zu der neuen Anweisung 412 einzutreten. Die Zuvor-geplante-Wiederholen-Einheit 420 kann den Wiederholen-Befehl, welcher mittels des Compilers innerhalb der neuen Anweisung 412 eingefügt ist, erkennen und Zuvor-geplante-Wiederholen-Operationen demgemäß einfügen. Alternativ kann die Exec-Einheit 302 irgendeinen anderen technisch durchführbaren Zugang benutzen, um zu bestimmen, ob eine oder mehrere Zuvor-geplante-Wiederholen-Operationen in die Mehr-Stufe-Pipeline einzufügen sind.
  • Die LSU 303 kann verschiedene Zugangsweisen verwenden bzw. benutzen, um zu verhindern, dass die Wiederholen-Einheit 406 eine Operation wiederholt, welche bereits in die Mehr-Stufe-Pipeline 400 mittels der Zuvorgeplante-Wiederholen-Einheit 420 eingesetzt worden ist. Wenn die anfängliche Operation bei Logik-Element 404(S-1) ankommt, braucht die Mehr-Stufe-Pipeline 400 nicht gewahr sein, dass zusätzliche Zuvor-geplante-Wiederholen-Operationen mittels der Zuvor-geplante-Wiederholen-Einheit 420 eingefügt worden sind. Als ein Ergebnis kann die LSU 303 unnötige Wiederholen-Operationen planen. Um solch ein Vorkommen zu verhindern, kann die Exec-Einheit 302 einen Indikator einfügen, welcher mit der anfänglichen Operation assoziiert ist, um anzuzeigen, dass eine oder mehrere Zuvor-geplante-Wiederholen-Operationen der anfänglichen Operation folgen. Die LSU 303 kann dann warten, bis die Zuvor-geplanten-Wiederholen-Operationen verarbeitet sind, vor Einfügen zusätzlicher Wiederholen-Operationen. Alternativ kann Logik-Element 404(S-1) dieselbe Logik wie sie in der Zuvorgeplante-Wiederholen-Einheit 420 benutzt ist, umfassen, um Zuvor-geplante-Wiederholen-Operationen zu erzeugen. In solch einem Fall ist Logik-Element 404(S-1) in der Lage, die Anzahl und Typ von Zuvor-geplante-Wiederholen-Operationen zu bestimmen, welche mittels der Zuvor-geplante-Wiederholen-Einheit 420 eingefügt sind. Die LSU 303 wartet dann, bis die Zuvor-geplante-Wiederholen-Operationen die Mehr-Stufe-Pipeline 400 leeren (clear), vor dem Bestimmen, ob zusätzliche Wiederholen-Operationen geplant werden sollten. Alternativ kann irgendeine technisch durchführbare Zugangsweise mittels der LSU 303 implementiert werden, um zu verhindern, dass die Wiederholen-Einheit 406 Wiederholen-Operationen einfügt, welche Duplikate von denjenigen sind, welche mittels der Zuvor-geplante-Wiederholen-Einheit 420 eingefügt sind.
  • Das folgende Beispiel illustriert, wie Zuvor-geplante-Wiederholen-Operationen in einer beispielhaften Mehr-Stufe-Pipeline 400 verarbeitet werden, wobei B = 3. Eine neue Anweisung 412 kann in die Mehr-Stufe-Pipeline 400 über die Zuvor-geplante-Wiederholen-Einheit 420 eintreten. Die Exec-Einheit 302 kann bestimmen, dass die Anweisung programmiert ist, eine gemeinsame-Ressource-Zugriffs-Operation auszuführen, wie etwa eine Lade-Anweisung, welche auf einen gemeinsamen Speicher gerichtet ist. Die Exec-Einheit 302 fügt eine Operation in die Mehr-Stufe-Pipeline ein, über die Zuvorgeplante-Wiederholen-Einheit 420, um die Anweisung für den ersten Thread und die erstes Thread-Familie auszuführen. Die LSU 303 kann dann die zusätzlichen Zuvor-geplante-Wiederholen-Operationen, über die Zuvorgeplante-Wiederholen-Einheit 420, in die Mehr-Stufe-Pipeline 400 über Eingabe 418 des Wiederholen-Multiplexers 408 seriell mit der anfänglichen Operation einfügen. Wenn die neue Anweisung 412 eine gemeinsame-Ressource-Zugriffs-Operation ist, dann kann die LSU 303 einen ersten Thread von der Gruppe von Threads auswählen, welche geplant sind, die Anweisung auszuführen. Die LSU 303 wählt eine Thread-Familie, welche mit dem ersten Thread assoziiert ist, aus. Die LSU 303 kann dann bis zu zwei zusätzliche Threads auswählen, um während des anfänglichen Durchgangs durch die Mehr-Stufe-Pipeline 400 von denjenigen Threads zu verarbeiten, welche Service bzw. Dienst benötigen. Die LSU 303 kann dann Thread-Familien, welche mit jedem der zusätzlichen Threads assoziiert sind, auswählen. Die LSU 303 kann Zuvor-geplante-Wiederholen-Operationen erzeugen, welche mit jedem der zusätzlichen Threads assoziiert sind. Die LSU 303 kann bestimmen, ob irgendwelche Threads unbedient bleiben, nachdem die Mehr-Stufe-Pipeline 400 die anfängliche Operation und die Zuvor-geplante-Wiederholen-Operationen verarbeitet. Die LSU 303 kann zusätzliche Wiederholen-Operationen über Wiederholen-Schleife 410 einfügen, bis alle Threads bedient worden sind.
  • In diesem Beispiel, wo die maximale Zuvor-geplante-Wiederholen-Batch-Größe B = 3 ist, und die Länge von Wiederholen-Schleife 410 fünf Pipeline-Stufen 402 ist, kann eine gemeinsame-Ressource-Zugriffs-Operation mit zwei erneut geplanten Wiederholen-Operationen von Pipeline-Stufe 402(0) zu 402(S) in einem einzelnen Durchgang von sieben Taktzyklen passieren, fünf Taktzyklen für die anfängliche Anweisung plus ein zusätzlicher Taktzyklus für jede der zwei Zuvor-geplante-Wiederholen-Operationen. Ohne Zuvor-geplante-Wiederholen-Operationen kann solch eine Anweisung, welche zwei Wiederholen-Operationen erfordert, 15 Taktzyklen erfordern, fünf Taktzyklen für die anfängliche Anweisung plus fünf Taktzyklen für jede der zwei Wiederholen-Operationen. In diesem Beispiel ist die Anzahl von Taktzyklen, um die gemeinsame-Ressource-Zugriffs-Operation zu vollenden, um mehr als die Hälfte reduziert worden.
  • Es wird geschätzt werden, dass die hierin beschriebene Architektur nur illustrativ ist und dass Variationen und Modifikationen möglich sind. Zum Beispiel ist die hierin beschriebene Architektur im Zusammenhang mit einer Mehr-Stufe-Pipeline 400 innerhalb der Exec-Einheit 302 und der Lade-Speicher-Einheit 303 eines Streaming-Multiprozessors 310 beschrieben worden, aber sie kann in irgendeiner Mehr-Stufe-Pipeline 400 eingesetzt werden, welche auf gemeinsame Ressourcen zugreift, einschließlich, ohne Begrenzung, in Assoziation mit einer Zentral-Verarbeitungs-Einheit (CPU), Allgemein-Verarbeitungs-Einheit (GPU), oder in irgendeiner anderen technisch machbaren Rechen-Umgebung. In einem anderen Beispiel kann eine größere Effizienz erreicht werden, wo die maximale Zuvor-geplante-Wiederholen-Batch-Größe B eine andere Zahl als 3 ist. Ein gewöhnlicher Fachmann in der Technik wird verstehen, dass der optimale Wert für B mittels der Länge S von Wiederholen-Schleife 410, der Natur von Anweisungen, welche durch die Mehr-Stufe-Pipeline 400 progressieren, und anderen Faktoren bestimmt sein kann. In noch einem anderen Beispiel werden die anfängliche Operation und assoziierte Zuvor-geplante-Wiederholen-Operationen typischerweise in die Mehr-Stufe-Pipeline 400 bei aufeinander folgenden Taktzyklen eingefügt, so dass Operationen innerhalb eines Batch durch die Mehr-Stufe-Pipeline 400 eine Pipeline-Stufe 402 voneinander beabstandet progressieren. Aufeinander folgende Einfügungen können jedoch bei anderen Intervallen erfolgen, welche größer sind als ein Taktzyklus.
  • Die hierin beschriebenen Techniken sind in Bezug bzw. mit Blick auf gemeinsame-Ressource-Zugriffs-Operationen beschrieben, wie etwa Lade-Operationen über mehrere Threads, wobei die Threads auf Speicher-Stellen über divergente Zwischenspeicher-Zeilen zugreifen. Die Techniken sind ausreichend flexibel, um in anderen Anwendungen eingesetzt zu werden, wo divergente Operationen vorhanden sind. In einem Beispiel sind die hierin beschriebenen Techniken nicht auf Ausführung von Threads begrenzt, sondern können für irgendwelche Operationen eingesetzt werden, welche über mehrere Durchgänge durch eine oder mehrere Stufen einer Mehr-Stufe-Pipeline voranschreiten. In einem anderen Beispiel kann eine Anweisung über eine andere gemeinsame Ressource als Zwischenspeicher-Zeilen innerhalb eines Zwischenspeichers divergieren. Solche Ressourcen können umfassen, ohne Begrenzung, Zwischenspeicher-Kennzeichen (cache tags), Zwischenspeicher-Daten, Register-Banken, und gemeinsamen Speicher. Die Threads, welche die Anweisung ausführen, können dahingehend divergieren, dass sie auf verschiedene Aspekte oder Teile der gemeinsamen Ressource zugreifen. In noch einem anderen Beispiel kann die LSU 303 mehrere gemeinsame Ressourcen abrufen, wie etwa mehrere Zwischenspeicher-Zeilen, während einer gegebenen Operation. Zuvor-geplante-Wiederholen-Operationen können noch eingesetzt werden, wo Threads unbedient bleiben nach einer Operation, welche mehrere gemeinsame Ressourcen abgerufen hat.
  • Ein gewöhnlicher Fachmann in der Technik wird die Weise, in welcher Threads zur Verarbeitung bestimmt und ausgewählt werden können. In einem Beispiel kann die Gesamtzahl von Threads und entsprechender Thread-Familien in demselben Taktzyklus bestimmt werden. Ein oder mehrere Threads können zur Verarbeitung in dem momentanen Durchgang durch die Mehr-Stufe-Pipeline 400 gekennzeichnet werden, während die übrigen Threads unbedient bleiben bis zu einem späteren Durchgang. In einem anderen Beispiel kann ein einzelner Thread während eines gegebenen Taktzyklus ausgewählt werden. Während dieser ausgewählte Thread Verarbeitung beginnt, kann ein nächster Thread, wenn überhaupt, während eines folgenden Taktzyklus ausgewählt werden. Somit können Threads, welche für Zuvorgeplante-Wiederholen-Operationen ausgewählt sind, einer zu einer Zeit, wie benötigt ist, bestimmt werden, bis alle Threads bedient sind. Zusätzlich zu diesen Zugangsweisen kann irgendein technisch machbares Verfahren zum Auswählen von Threads und Auswählen von assoziierten Thread-Familien eingesetzt werden. Irgendwelche sinnvollen Kriterien können benutzt werden, um einen spezifischen Thread zur Verarbeitung auszuwählen. Zum Beispiel kann ein Thread zufällig aus den Threads ausgewählt werden, welche Bedienung erfordern. Alternativ kann ein Thread basierend darauf ausgewählt werden, welcher Thread die größte Thread-Familie erzeugt, oder wieder in irgendeiner anderen sinnvollen Weise.
  • 5 ist ein Flussdiagramm von Verfahrensschritten 500 zum Ausführen von Zuvor-geplante-Wiederholen-Operationen in einer Mehr-Stufe-Pipeline 400 gemäß einer Ausführungsform der vorliegenden Erfindung. Obwohl die Verfahrensschritte 500 im Zusammenhang mit den Systemen von 1–4 beschrieben sind, werden gewöhnliche Fachleute in der Technik verstehen, dass irgendein System, welches konfiguriert ist, die Verfahrensschritte 500 durchzuführen, in irgendeiner Ordnung, innerhalb des Geltungsbereichs der vorliegenden Erfindung ist.
  • Das Verfahren 500 beginnt bei Schritt 502, wobei der SM 310 eine gemeinsame-Ressource-Zugriffs-Operation empfängt, wie etwa eine Anweisung, um einen Daten-Wert von einem gemeinsamen Speicher bei einer spezifizierten Adresse für eine gewisse Anzahl von Threads zu laden. Jeder Thread, welcher geplant ist, die Anweisung auszuführen, kann programmiert sein, Daten von einer anderen Speicherstelle zu laden, welche auf derselben oder auf divergenten Zwischenspeicher-Zeilen sein können. Bei Schritt 504 wählt der SM 310 einen Thread von den verschiedenen Threads aus, welche Bedienung erfordern, um die gemeinsame-Ressource-Zugriffs-Operation zu vollenden. Der Thread kann basierend auf einer Anzahl von Kriterien oder Politiken ausgewählt werden. Bei Schritt 506 wählt der SM 310 eine erste Thread-Familie, welche mit dem ersten Thread assoziiert ist, aus. Die erste Thread-Familie umfasst den Satz von Threads, welche auf denselben Teil oder Aspekt einer gemeinsamen Ressource wie der erste Thread zugreifen müssen, wie etwa dieselbe Zwischenspeicher-Zeile innerhalb eines Zwischenspeichers. Bei Schritt 508 fügt der SM 310 eine anfängliche Operation in die Mehr-Stufe-Pipeline 400 ein, welche konfiguriert ist, die Anweisung für den ersten Thread und die erste Thread-Familie auszuführen. Bei Schritt 510 bestimmt der SM 310, ob zusätzliche Zuvor-geplante-Operationen seriell mit der anfänglichen Anweisung einzusetzen sind. Wenn der SM 310 bestimmt, nicht Zuvorgeplante-Operationen einzufügen, dann terminiert das Verfahren 500. Wenn der SM 310 bestimmt, Zuvor-geplante-Operationen einzufügen, dann schreitet das Verfahren 500 zu Schritt 512 fort, wobei der SM 310 einen zusätzlichen Thread von den Threads auswählt, welche geplant sind, die Anweisung auszuführen. Bei Schritt 514 wählt der SM 310 eine Thread-Familie, welche mit dem zusätzlichen Thread assoziiert ist, aus. Bei Schritt 516 fügt der SM 310 eine Zuvor-geplante-Wiederholen-Operation in die Mehr-Stufe-Pipeline 400 ein, welche konfiguriert ist, die Anweisung für den ausgewählten Thread und die assoziierte Thread-Familie auszuführen.
  • Bei Schritt 518 bestimmt der SM 310, ob die Batch-Größe, einschließlich der anfänglichen Anweisung und jeder der Zuvor-geplante-Wiederholen-Anweisungen gleich B ist, wobei B die maximale Anzahl von Operationen ist, welche während des anfänglichen Durchgangs durch die Mehr-Stufe-Pipeline 400 verarbeitet werden können, einschließlich der anfänglichen Anweisung. Wenn die Batch-Größe nicht gleich B ist, dann kehrt das Verfahren 500 zu Schritt 512 zurück, wo der SM 310 einen zusätzlichen Thread auswählt. Wenn die Batch-Größe gleich B ist, dann terminiert das Verfahren 500.
  • Zusammenfassend stellt die offenbarte Technik einen optimierten Weg zum Ausführen von Wiederholen-Operationen für divergente Operationen in einem Parallel-Verarbeitungs-Subsystem bereit. Insbesondere umfasst ein Streaming-Multiprozessor SM 310 eine Mehr-Stufe-Pipeline 400, welche konfiguriert ist, eine oder mehrere Zuvor-geplante-Wiederholen-Operationen in eine Mehr-Stufe-Pipeline 400 einzufügen. Eine Zuvor-geplante-Wiederholen-Einheit 420 detektiert, ob die Operation, welche mit der momentanen Anweisung assoziiert ist, auf eine gemeinsame Ressource zugreift, wie etwa Laden von Daten von einem gemeinsamen Speicher. Wenn die Threads auf Daten zugreifen, welche über mehrere gemeinsame Ressourcen verteilt sind, wie etwa divergente Zwischenspeicher-Zeilen, dann fügt die Zuvor-geplante-Wiederholen-Einheit 420 Zuvor-geplante-Wiederholen-Operationen hinter der anfänglichen Operation ein, um die momentane Anweisung auszuführen. Die Mehr-Stufe-Pipeline 400 führt die anfängliche Operation und die Zuvorgeplante-Wiederholen-Operationen sequentiell aus. Wenn zusätzliche Threads nach Ausführung der anfänglichen Operation und der Zuvor-geplante-Wiederholen-Operationen unbedient verbleiben, dann werden zusätzliche Wiederholen-Operationen über die Wiederholen-Schleife 410 eingefügt, bis alle Threads bedient sind.
  • Vorteilhafterweise führen divergente Operationen, welche eine oder mehrere Wiederholen-Operationen erfordern, mit verminderter Latenz aus. Die Mehr-Stufe-Pipeline 400 ist effizienter benutzt, weil eine oder mehrere Zuvor-geplante-Wiederholen-Operationen durch die Mehr-Stufe-Pipeline 400 seriell zusammen mit anfänglichen Anweisungen progressieren. Zusätzlich erfahren neue Anweisungen 412, welche darauf warten, in die Mehr-Stufe-Pipeline 400 bei dem Einfügungspunkt einzutreten, eine verminderte Verzögerung, was mittels der Anweisungen bewirkt ist, welche Wiederholen-Operationen erfordern. Ferner kann die Anzahl und das Timing von Zuvor-geplante-Wiederholen-Operationen bei Kompilierungs-Zeit bestimmt werden, was zu weiteren Effizienzen führt gegenüber einem Bestimmen von Zuvor-geplante-Wiederholen-Operationen exklusiv innerhalb der Mehr-Stufe-Pipeline 400 zu der Zeit von Anweisungs-Ausführung.
  • Während das Vorangehende auf Ausführungsformen der vorliegenden Erfindung gerichtet ist, können andere und weitere Ausführungsformen der Erfindung entworfen werden, ohne von dem grundsätzlichen Geltungsbereich abzuweichen, und der Geltungsbereich davon ist mittels der Ansprüche bestimmt, welche folgen.

Claims (12)

  1. Subsystem zum Zuvor-Planen von Wiederholen einer gemeinsame-Ressource-Zugriffs-Operation, aufweisend: eine Lade-Speicher-Einheit (LSU), welche konfiguriert ist, um: eine erste Anweisung, welche mittels einer Gruppe von Threads in einer Mehr-Stufe-Pipeline auszuführen ist, zu empfangen; zu bestimmen, dass eine Zuvor-geplante-Wiederholen-Operation in die Mehr-Stufe-Pipeline eingefügt werden sollte, um einem zweiten Satz von einem oder mehreren Threads von der Gruppe von Threads zu erlauben, die erste Anweisung auszuführen; einen ersten Satz von einem oder mehreren Threads von der Gruppe von Threads auszuwählen, um die erste Anweisung in der Mehr-Stufe-Pipeline auszuführen; die erste Anweisung in die Mehr-Stufe-Pipeline zur Ausführung mittels des ersten Satzes von einem oder mehreren Threads einzufügen; und die Zuvor-geplante-Wiederholen-Operation in die Mehr-Stufe-Pipeline einzufügen, um dem zweiten Satz von einem oder mehreren Threads zu erlauben, die erste Anweisung auszuführen, wobei der erste Satz von einem oder mehreren Threads beabsichtigt ist, auf einen ersten Aspekt oder Teil einer gemeinsamen Ressource zuzugreifen, und wobei der zweite Satz von einem oder mehreren Threads beabsichtigt ist, auf einen zweiten Aspekt oder Teil der gemeinsamen Ressource zuzugreifen.
  2. Subsystem gemäß Anspruch 1, wobei die gemeinsame Ressource einen Zwischenspeicher aufweist.
  3. Subsystem gemäß Anspruch 1, ferner aufweisend Einfügen in die Mehr-Stufe-Pipeline eines Identifikators, welcher der Zuvor-geplante-Wiederholen-Operation entspricht, wobei der Identifikator die Existenz von einer oder mehreren Zuvor-geplante-Wiederholen-Operationen anzeigt.
  4. Subsystem gemäß Anspruch 1, wobei die Zuvor-geplante-Wiederholen-Operation in die Mehr-Stufe-Pipeline seriell relativ zu der ersten Anweisung eingefügt ist.
  5. Subsystem gemäß Anspruch 1, wobei eine zweite Anweisung in die Mehr-Stufe-Pipeline seriell relativ zu der Zuvor-geplante-Wiederholen-Operation eingefügt ist.
  6. Subsystem gemäß Anspruch 1, wobei die erste Anweisung anzeigt, dass zumindest eine Zuvor-geplante-Wiederholen-Operation in die Mehr-Stufe-Pipeline eingefügt werden sollte.
  7. Subsystem gemäß Anspruch 1, wobei die Zuvor-geplante-Wiederholen-Operation erfordert ist, die erste Anweisung für alle Threads innerhalb der Gruppe von Threads auszuführen.
  8. Subsystem gemäß Anspruch 1, wobei die Zuvor-geplante-Wiederholen-Operation wahrscheinlich erfordert ist, die erste Anweisung für alle Threads innerhalb der Gruppe von Threads auszuführen.
  9. Rechengerät, aufweisend: ein Subsystem, welches eine Lade-Speicher-Einheit (LSU) umfasst, welche konfiguriert ist, um: eine erste Anweisung, welche mittels einer Gruppe von Threads in einer Mehr-Stufe-Pipeline auszuführen ist, zu empfangen; zu bestimmen, dass eine Zuvor-geplante-Wiederholen-Operation in die Mehr-Stufe-Pipeline eingefügt werden sollte, um einem zweiten Satz von einem oder mehreren Threads von der Gruppe von Threads zu erlauben, die erste Anweisung auszuführen; einen ersten Satz von einem oder mehreren Threads von der Gruppe von Threads auszuwählen, um die erste Anweisung in der Mehr-Stufe-Pipeline auszuführen; die erste Anweisung in die Mehr-Stufe-Pipeline zur Ausführung mittels des ersten Satzes von einem oder mehreren Threads einzufügen; und die Zuvor-geplante-Wiederholen-Operation in die Mehr-Stufe-Pipeline einzufügen, um dem zweiten Satz von einem oder mehreren Threads zu erlauben, die erste Anweisung auszuführen, wobei der erste Satz von einem oder mehreren Threads beabsichtigt ist, auf einen ersten Aspekt oder Teil einer gemeinsamen Ressource zuzugreifen, und wobei der zweite Satz von einem oder mehreren Threads beabsichtigt ist, auf einen zweiten Aspekt oder Teil der gemeinsamen Ressource zuzugreifen.
  10. Rechengerät gemäß Anspruch 9, wobei die erste Anweisung anzeigt, dass zumindest eine Zuvor-geplante-Wiederholen-Operation in die Mehr-Stufe-Pipeline eingefügt werden sollte.
  11. Rechengerät gemäß Anspruch 9, wobei die Zuvor-geplante-Wiederholen-Operation erfordert ist, die erste Anweisung für alle Threads innerhalb der Gruppe von Threads auszuführen.
  12. Rechengerät gemäß Anspruch 9, wobei die Zuvor-geplante-Wiederholen-Operation wahrscheinlich erfordert ist, die erste Anweisung für alle Threads innerhalb der Gruppe von Threads auszuführen.
DE102013201195A 2012-02-09 2013-01-25 Zuvor-geplante Wiederholungen von divergenten Operationen Pending DE102013201195A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US13/370,173 US10152329B2 (en) 2012-02-09 2012-02-09 Pre-scheduled replays of divergent operations
US13/370,173 2012-02-09

Publications (1)

Publication Number Publication Date
DE102013201195A1 true DE102013201195A1 (de) 2013-08-14

Family

ID=48868444

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102013201195A Pending DE102013201195A1 (de) 2012-02-09 2013-01-25 Zuvor-geplante Wiederholungen von divergenten Operationen

Country Status (4)

Country Link
US (1) US10152329B2 (de)
CN (1) CN103294449B (de)
DE (1) DE102013201195A1 (de)
TW (1) TWI489289B (de)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10133572B2 (en) 2014-05-02 2018-11-20 Qualcomm Incorporated Techniques for serialized execution in a SIMD processing system
US20160188519A1 (en) * 2014-12-27 2016-06-30 Intel Corporation Method, apparatus, system for embedded stream lanes in a high-performance interconnect
US10474468B2 (en) * 2017-02-22 2019-11-12 Advanced Micro Devices, Inc. Indicating instruction scheduling mode for processing wavefront portions
CN108509791B (zh) * 2018-02-09 2021-06-04 清华大学 检测处理器的方法、检测装置以及检测系统
US11803391B2 (en) * 2020-10-20 2023-10-31 Micron Technology, Inc. Self-scheduling threads in a programmable atomic unit

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6385715B1 (en) 1996-11-13 2002-05-07 Intel Corporation Multi-threading for a processor utilizing a replay queue
US7363470B2 (en) 2003-05-02 2008-04-22 Advanced Micro Devices, Inc. System and method to prevent in-flight instances of operations from disrupting operation replay within a data-speculative microprocessor
US7788468B1 (en) * 2005-12-15 2010-08-31 Nvidia Corporation Synchronization of threads in a cooperative thread array
US8438370B1 (en) * 2006-12-08 2013-05-07 Nvidia Corporation Processing of loops with internal data dependencies using a parallel processor
US7861066B2 (en) 2007-07-20 2010-12-28 Advanced Micro Devices, Inc. Mechanism for predicting and suppressing instruction replay in a processor
US8312254B2 (en) * 2008-03-24 2012-11-13 Nvidia Corporation Indirect function call instructions in a synchronous parallel thread processor
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
US8086801B2 (en) 2009-04-08 2011-12-27 International Business Machines Corporation Loading data to vector renamed register from across multiple cache lines
US8458440B2 (en) 2009-09-25 2013-06-04 Nvidia Corporation Deferred complete virtual address computation for local memory space requests
US8732713B2 (en) * 2010-09-29 2014-05-20 Nvidia Corporation Thread group scheduler for computing on a parallel thread processor
US8751771B2 (en) * 2010-09-29 2014-06-10 Nvidia Corporation Efficient implementation of arrays of structures on SIMT and SIMD architectures
US9817668B2 (en) * 2011-12-16 2017-11-14 Nvidia Corporation Batched replays of divergent operations
US9606808B2 (en) * 2012-01-11 2017-03-28 Nvidia Corporation Method and system for resolving thread divergences
US10095548B2 (en) * 2012-05-21 2018-10-09 Nvidia Corporation Mechanism for waking common resource requests within a resource management subsystem
US9755994B2 (en) * 2012-05-21 2017-09-05 Nvidia Corporation Mechanism for tracking age of common resource requests within a resource management subsystem
US9836325B2 (en) * 2012-05-21 2017-12-05 Nvidia Corporation Resource management subsystem that maintains fairness and order

Also Published As

Publication number Publication date
US10152329B2 (en) 2018-12-11
US20130212364A1 (en) 2013-08-15
CN103294449A (zh) 2013-09-11
TW201346576A (zh) 2013-11-16
CN103294449B (zh) 2016-08-03
TWI489289B (zh) 2015-06-21

Similar Documents

Publication Publication Date Title
DE102013208554B4 (de) Verfahren und System zum Managen verschachtelter Ausführungsströme
DE102012222913A1 (de) Verfahren und Apparat zum Planen von Anweisungen unter Benutzung von Zuvor-Dekodieren-Daten
DE102013100179A1 (de) Verfahren und System zum Auflösen von Thread-Divergenzen
DE102012221502A1 (de) System und Verfahren zum Durchführen von gestalteter-Speicherzugriff-Operationen
DE102013209350B4 (de) Ressource-Management-Subsystem, welches Fairness und Ordnung einhält
DE102012222918A1 (de) Verfahren und Apparat zum Planen von Anweisungen ohne Anweisungs-Dekodieren
DE102013200991A1 (de) Automatisches abhängige-Aufgabe-Anstoßen
DE102013022712B4 (de) Virtuelle Speicherstruktur für Coprozessoren, die Speicherallokationsbegrenzungen haben
DE102012222394A1 (de) Verfahren und Vorrichtung zum Sammelzwischenspeichern von Quelloperanden
DE102012221504B4 (de) Mehrniveau-Anweisung-Zwischenspeicher-Zuvor-Holen
DE102012222558B4 (de) Signalisieren, Ordnen und Ausführung von dynamisch erzeugten Aufgaben in einem Verarbeitungs-System
DE102013114072A1 (de) System und Verfahren zum Hardware-Scheduling von indexierten Barrieren
DE102012220029A1 (de) Spekulative Ausführung und Zurücksetzen
DE102013202495A1 (de) Verfahren zur Durchführung von interaktivem Debugging auf nicht unterbrechbaren Graphikverarbeitungseinheiten
DE102012212639A1 (de) Temporäre SIMT-Ausführungs-Optimierung
DE102012220267B4 (de) Rechenarbeitsverteilungs - Referenzzähler
DE102013200997A1 (de) Ein blockierungsfreies FIFO
DE102013016871A1 (de) Technik zur Steigerung der Effizienz in mehrsträngigen Verarbeitungseinrichtngen
DE102013201178A1 (de) Steuern von Arbeitsverteilung für Verarbeitung von Tasks
DE102013208558A1 (de) Verfahren und System zur Verarbeitung verschachtelter Stream-Events
DE102013205886A1 (de) Dynamische Bankmodus-Adressierung für Speicherzugriff
DE102013020966B4 (de) Leistungseffiziente Attribut-Handhabung für Parkettierungs- und Geometrie-Schattierungseinheiten
DE102013114351A1 (de) System und Verfahren für Hardware-Disponierung bedingter Barrieren und ungeduldiger Barrieren
DE102013208421A1 (de) Sharing einer Grafikverarbeitungseinheit unter vielen Anwendungen
DE102012222932A1 (de) Gestaltetes Register-Datei-Lesen

Legal Events

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

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

Representative=s name: DILG HAEUSLER SCHINDELMANN PATENTANWALTSGESELL, DE

R082 Change of representative

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

R016 Response to examination communication