DE102012220365A1 - Aufgabe-Thread-Feld-Granularität-Ausführung-Präemption - Google Patents

Aufgabe-Thread-Feld-Granularität-Ausführung-Präemption Download PDF

Info

Publication number
DE102012220365A1
DE102012220365A1 DE201210220365 DE102012220365A DE102012220365A1 DE 102012220365 A1 DE102012220365 A1 DE 102012220365A1 DE 201210220365 DE201210220365 DE 201210220365 DE 102012220365 A DE102012220365 A DE 102012220365A DE 102012220365 A1 DE102012220365 A1 DE 102012220365A1
Authority
DE
Germany
Prior art keywords
context
program instructions
execution
processing pipeline
task
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
DE201210220365
Other languages
English (en)
Inventor
Lacky V. Shah
Gregory Scott Palmer
Gernot Schaufler
Samuel H. Duncan
Philip Browning Johnson
Shirish Gadre
Robert OHANNESSIAN
Nicholas Wang
Christopher Lamb
Philip Alexander Cuadra
Timothy John Purcell
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nvidia Corp
Original Assignee
Nvidia Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US13/294,045 external-priority patent/US20130124838A1/en
Priority claimed from US13/302,962 external-priority patent/US20130132711A1/en
Application filed by Nvidia Corp filed Critical Nvidia Corp
Publication of DE102012220365A1 publication Critical patent/DE102012220365A1/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/46—Multiprogramming arrangements
    • G06F9/461—Saving or restoring of program or task context

Landscapes

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

Abstract

Eine Ausführungsform der vorliegenden Erfindung führt eine Technik Anweisungs-Level- und Rechen-Thread-Feld-Granularität-Ausführung-Präemption aus. Ausschließen bei dem Anweisungs-Level erfordert kein Entleeren der Verarbeitungs-Pipeline. Keine neuen Anweisungen werden ausgestellt und der Kontext-Zustand wird von der Verarbeitungs-Pipeline entladen. Wenn Präemption bei einer Rechen-Thread-Feld-Grenze durchgeführt wird, ist die Menge von Kontext-Zustand, welche zu speichern ist, vermindert, weil Ausführungs-Einheiten innerhalb der Verarbeitungs-Pipeline Ausführung von In-Flug-Anweisungen vollenden und untätig werden. Wenn die Zeitmenge, welche benötigt ist, Ausführung der In-Flug-Anweisungen zu vollenden, einen Schwellwert übersteigt, dann kann die Präemption dynamisch geändert werden, bei dem Anweisungs-Level anstatt bei einer Rechen-Thread-Feld-Granularität durchgeführt zu werden.

Description

  • HINTERGRUND DER ERFINDUNG
  • Gebiet der Erfindung
  • Die vorliegende Erfindung betrifft im Allgemeinen Programm-Ausführung-Präemption und insbesondere Rechen-Thread-Feld-Granularität-Ausführung-Präemption.
  • BESCHREIBUNG DER BETREFFENDEN TECHNIK
  • Präemption (preemption) ist ein Mechanismus, um einen Prozessor zwischen mehreren verschiedenen Anwendungen in Zeitscheiben zu schneiden (time-slice). Wenn mehrere verschiedene Anwendungen den Prozessor simultan benutzen müssen, ist ein Weg, ein Vorwärts-Voranschreiten auf allen Anwendungen zu erreichen, jede Anwendung für eine kurze Zeitscheibe (time-slice) auf dem Prozessor abzulaufen. Herkömmlicher Weise erfordert ein in Zeitscheiben-Schneiden bzw. nach Zeitscheiben-Betreiben, dass die Prozessor-Pipeline vollständig entleert wird, und wenn der Prozessor untätig ist, wird eine andere Anwendung eingeschaltet, um mittels der Prozessor-Pipeline ausgeführt zu werden. Dieser Mechanismus eines Schneidens in Zeitscheiben (time-slicing) ist als „Warte auf Untätigkeit”-Präemption bezeichnet worden und der Mechanismus funktioniert nicht gut, wenn es eine lange Zeit für den Prozessor erfordert, die Arbeit zu entleeren, welche auf der Prozessor-Pipeline abläuft. Man betrachte z. B. ein sehr lang ablaufendes Grafik-Schattierungsprogramm, oder in dem schlimmsten Fall, ein Schattierungsprogramm mit einer unendlichen Schleife. Um in der Lage zu sein, unter verschiedenen Anwendungen Zeitscheiben zu schneiden (time-slice), sollte die Menge an Zeit, welche benötigt ist, Ausführung jeder Anwendung leer zu laufen (to idle), begrenzt sein, so dass lang ablaufende Anwendungen nicht effektiv die Zeitscheibe vermindern, welche für andere Anwendungen verfügbar ist.
  • Ein anderer Mechanismus, welcher betrachtet worden ist, um Präemption zu implementieren, ist, den Prozessor anzuhalten (stall) oder zu blockieren (freeze) und dann die Inhalte aller der Register und Pipeline-Flip-Flops innerhalb des Prozessors zu speichern und später die Inhalte aller der Register und Pipeline-Flip-Flops innerhalb des Prozessors wieder herzustellen. Speichern und Wiederherstellen der Inhalte von allen der Register und Pipeline-Flip-Flops führt dazu, dass typischer Weise eine sehr große Menge von Zustand gesichert und wieder hergestellt werden muss. Die Zeit, welche benötigt ist, den Zustand zu speichern und wieder herzustellen, vermindert die Zeit, welche zum Ausführen jeder der Anwendungen während der Zeitscheiben verfügbar ist.
  • Demgemäß ist, was in der Technik benötigt ist, ein System und ein Verfahren zur Ausführung-Präemption, welches entweder nicht erfordert, den gesamten Zustand einer Anwendung zu speichern, wenn die Anwendung bevorrechtet bzw. ausgeschlossen (preempted) wird, oder es nicht erfordert, dass darauf gewartet wird, dass die Verarbeitungs-Pipeline untätig wird, um die Anwendung zu auszuschließen.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Ein System und ein Verfahren für Rechen-Thread-Feld-Granularität-Ausführung-Präemption bzw. -Präemption. Wenn eine Präemption bzw. Präemption (Präemption) initialisiert wird, wird der Kontext-Zustand von der Verarbeitungs-Pipeline entladen (unloaded). Wenn eine Präemption bei einer Rechen-Thread-Feld-Grenze (task thread field boundary) durchgeführt wird, wird die Menge oder der Umfang von Kontext-Zustand, welcher zu speichern ist, reduziert, weil die Ausführungseinheiten innerhalb der Verarbeitungs-Pipeline Ausführung von In-Flug-Anweisungen (in-flight instructions) vollenden und untätig werden. Wenn die Menge an Zeit, welche benötigt wird, eine Ausführung der In-Flug-Anweisungen zu vervollständigen oder zu vollenden, einen Schwellwert übersteigt, dann kann sich die Präemption dynamisch ändern, um bei dem Anweisungs-Level anstatt bei einer Rechen-Thread-Feld-Granularität durchgeführt zu werden.
  • Verschiedene Ausführungsformen eines Verfahrens der Erfindung zum Ausschließen (prempting) von Ausführung von Programm-Anweisungen in einem Mehrprozess-gestützten System (multi-threaded system) umfassen ein Ausführen von Programm-Anweisungen in einer Verarbeitungs-Pipeline innerhalb eines Mehrprozess-gestützten Systems (multi-threaded system) unter Benutzung eines ersten Kontextes. Ausführung unter Benutzung des ersten Kontextes bzw. des ersten Umstands wird bei einem Rechen-Thread-Feld-Level ausgeschlossen (preempted), um verschiedene Programm-Anweisungen in dem Mehrprozess-gestützten System unter Benutzung eines zweiten Kontextes bzw. eines zweiten Umstands auszuführen. Eine Indikation, dass Ausführung der Programm-Anweisungen unter Benutzung des ersten Umstands ausgeschlossen wurde, wird gespeichert und die verschiedenen Programm-Anweisungen werden in der Verarbeitungs-Pipeline unter Benutzung des zweiten Kontextes ausgeführt.
  • Verschiedene Ausführungsformen der Erfindung umfassen ein Mehrprozess-gestütztes System zum Ausschließen von Ausführung von Programm-Anweisungen. Das Mehrprozess-gestützte System umfasst einen Speicher, eine Host-Schnittstelle und eine Verarbeitungs-Pipeline. Der Speicher ist konfiguriert, eine Programm-Anweisung entsprechend einem ersten Kontext und verschiedene Programm-Anweisungen entsprechend eines zweiten Kontextes zu speichern. Die Host-Schnittstelle ist mit der Verarbeitungs-Pipeline gekoppelt und konfiguriert, Ausführung der Programm-Anweisungen unter Benutzung des ersten Kontextes bzw. Umstands bei dem Rechen-Thread-Feld-Level auszuschließen, um verschiedene Programm-Anweisungen unter Benutzung eines zweiten Kontextes bzw. Umstands auszuführen. Die Verarbeitungs-Pipeline ist konfiguriert, die Programm-Anweisungen unter Benutzung des ersten Kontextes auszuführen, Ausführung der Programm-Anweisungen unter Benutzung des ersten Kontextes auszuschließen, um verschiedene Programm-Anweisungen unter Benutzung des zweiten Kontextes auszuführen, eine Indikation zu speichern, dass Ausführung der Programm-Anweisungen unter Benutzung des ersten Kontextes ausgeschlossen wurde und die verschiedenen Programm-Anweisungen unter Benutzung des zweiten Kontextes auszuführen.
  • Der Präemption-Mechanismus (Präemption mechanism) minimiert die Menge von Zustand, welcher gespeichert ist, wenn eine Anwendung ausgeschlossen ist, und welcher wieder hergestellt ist, wenn die Anwendung Ausführung wieder aufnimmt. Zusätzlich können lang ablaufende Anwendungen in einer sehr kurzen Menge von Zeit ausgeschlossen werden.
  • 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-Subsystems für das Computer-System der 1, gemäß einer Ausführungsform der vorliegenden Erfindung;
  • 3A ist ein Blockdiagramm der Aufgabe-/Arbeit-Einheit der 2, gemäß einer Ausführungsform der Erfindung;
  • 3B ist ein Blockdiagramm eines Allgemein-Verarbeitungs-Clusters innerhalb einer der Parallel-Verarbeitungs-Einheiten von 2 gemäß einer Ausführungsform der vorliegenden Erfindung;
  • 4 ist ein Blockdiagramm der Verarbeitungs-Pipeline gemäß einer Ausführungsform der Erfindung;
  • 5A illustriert ein Entlade-Verfahren (unload method) zum Entladen eines Kontext-Zustands, wenn ein Prozess ausgeschlossen ist, gemäß einer Ausführungsform der Erfindung;
  • 5B illustriert ein Wiederherstellungs-Verfahren zum Wiederherstellen eines Kontext-Zustands, wenn ein ausgeschlossener Prozess wieder hergestellt wird gemäß einer Ausführungsform der vorliegenden Erfindung;
  • 6A illustriert ein anderes Entlade-Verfahren zum Entladen eines Kontext-Zustands, wenn ein Prozess ausgeschlossen ist, gemäß einer Ausführungsform der Erfindung;
  • 6B illustriert ein anderes Wiederherstellungs-Verfahren zum Wiederherstellen eines Kontext-Zustands, wenn ein ausgeschlossener Prozess wieder hergestellt ist, gemäß einer Ausführungsform der 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. In anderen Fällen sind wohl bekannte Merkmale nicht beschrieben worden, um ein Verschleiern der vorliegenden Erfindung zu vermeiden.
  • 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 Pfad 106 und Speicherbrücke 105 weiter. Ein Parallel-Verarbeitungs-Subsystem 112 ist mit der Speicherbrücke 105 über einen Bus oder einen anderen Kommunikationspfad 113 (z. B. einen 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 CRT- oder LCD-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) einschließlich USB- oder andere Port-Verbindungen, CD-Laufwerke, DVD-Laufwerke, Filmaufnahmegeräte, und dergleichen, können auch mit der I/O-Brücke 107 verbunden sein. Kommunikationspfade, welche die verschiedenen Komponenten in 1 wechselseitig verbinden, können unter Benutzung irgendwelcher geeigneten Protokolle implementiert sein, wie etwa PCI (Peripheral Component Interconnect), 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 integriert sein, wie etwa der Speicherbrücke 105, CPU 102 und I/O-Brücke 107, 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. 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 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 Aufgaben durchzuführen, welche das Erzeugen von Pixeldaten von Grafik-Daten, welche mittels CPU 102 und/oder Systemspeicher 104 über Speicherbrücke 105 und 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 sein eigenes dediziertes Parallel-Verarbeitungs-Speichergeräte) haben oder braucht nicht dedizierte Parallel-Verarbeitungs-Speichergeräte) zu haben. Eine oder mehrere PPUs 202 können Daten an das Anzeigegeräte 110 ausgeben oder jede PPU 202 kann Daten an eines oder mehrere Anzeigegeräte 110 ausgeben.
  • Im Betrieb ist CPU 102 der Master-Prozessor von Computer-System 100, welcher Operationen von anderen System-Komponenten steuert und koordiniert. Insbesondere stellt CPU 102 Befehle aus (issues), welche die Operation von PPUs 202 steuern. In einigen Ausführungsformen schreibt CPU 102 einen Strom von Befehlen für jede PPU 202 auf eine Datenstruktur (nicht explizit in weder 1 noch 2 gezeigt), welche in dem System-Speicher 104, Parallel-Verarbeitungs-Speicher 204 oder irgendeiner anderen Speicher-Stelle lokalisiert sein kann, welche sowohl für CPU 102 als auch für PPU 202 zugreifbar ist. Ein Zeiger (pointer) auf jede Datenstruktur wird auf einen Schiebepuffer (push buffer) geschrieben, um Verarbeitung des Stroms von Befehlen in der Datenstruktur zu initiieren. Die PPU 202 liest Befehlströme von einem oder mehreren Schiebepuffern und führt dann Befehle asynchron relativ zu dem Betrieb von CPU 102 aus. Ausführungs-Prioritäten können für jeden Schiebepuffer spezifiziert werden, um Planen der verschiedenen Schiebepuffer zu steuern.
  • Mit Bezug nun zurück auf 2B 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 der 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 die Arbeit, welche mittels des Push-Puffers spezifiziert 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, variieren.
  • GPCs 208 empfangen Verarbeitungs-Aufgaben, welche auszuführen sind, von einer Arbeits-Verteilungs-Einheit innerhalb einer Aufgabe-/Arbeit-Einheit 207. Die Arbeits-Verteilungs-Einheit empfängt Zeiger auf Rechen-Verarbeitungs-Aufgaben (Aufgabenzeiger), welche als Aufgabe-Metadaten (TMD) kodiert sind und im Speicher gespeichert sind. Die Aufgabenzeiger auf TMDs sind in dem Befehls-Strom umfasst, welcher in einem Schiebepuffer 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 von zu verarbeitenden Daten, sowie Status- oder Zustands-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 die GPCs 208 in einem gültigen Zustand konfiguriert sind, bevor die Verarbeitung, welche mittels jeder der TMDs spezifiziert ist, initiiert ist. Eine Priorität kann für jede TMD spezifiziert sein, welche benutzt ist, um Ausführung der Verarbeitungs-Aufgaben zu planen (schedule).
  • 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 DRAM 220. In anderen Ausführungsformen muss die Anzahl von Partitions-Einheiten 215 nicht gleich der Nummer von Speicher-Geräten sein. 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-Karten (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 zu Speicher-Schnittstelle 214, um mit I/O-Einheit 205 zu kommunizieren, sowie eine Verbindung zu lokalem Parallel-Verarbeitungs-Speicher 204, um dadurch den Verarbeitungs-Kernen innerhalb der verschiedenen GPCs 208 zu ermöglichen, mit System-Speicher 104 oder einem anderen Speicher zu kommunizieren, welcher nicht lokal zu der PPU 202 ist. In der in 2 gezeigten Ausführungsformen sind 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 exklusiv oder fast exklusiv System-Speicher 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-Gleichzeitige-Aufgabe-Planung
  • Mehrfach-Verarbeitungs-Aufgaben können gleichzeitig auf den GPCs 204 ausgeführt werden und eine Verarbeitungs-Aufgabe kann eine oder mehrere „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 der 2, gemäß einer Ausführungsform der vorliegenden Erfindung. 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 basierend auf Ausführungs-Prioritäts-Niveaus zu planen bzw. zeitlich zu planen sind (scheduled). Für jedes Prioritäts-Niveau speichert die Aufgabe-Management-Einheit 300 eine Liste von Zeigern (pointers) auf die TMDs 322 entsprechend den Aufgaben in der Planer-Tabelle 321. 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, was der Aufgabe-Management-Einheit 300 ermöglicht, Aufgaben basierend auf Prioritäts-Information oder Benutzung anderer Techniken zu planen.
  • Die Arbeit-Verteilungs-Einheit 340 umfasst eine Aufgabe-Tabelle 345 mit Fächern oder Zellen (slots), wobei jedes von der TMD 322 für eine Aufgabe besetzt sein kann, welche ausgeführt wird. Die Aufgabe-Management-Einheit 300 kann Aufgaben zur Ausführung planen, wenn es in der Aufgabe-Tabelle 345 ein freies Fach gibt. Wenn es kein freies Fach gibt, kann eine höhere-Priorität-Aufgabe, welche kein Fach besetzt, eine niedrigere-Priorität-Aufgabe, welche ein Fach besetzt, verdrängen oder ausweisen (evict). Wenn eine Aufgabe verdrängt ist oder ausgewiesen ist (evicted), wird die Aufgabe gestoppt und wenn die Ausführung der Aufgabe nicht vollständig ist, wird die Aufgabe an eine verkettete Liste in der Planer-Tabelle 321 hinzugefügt. Wenn eine Kind-Verarbeitungs-Aufgabe erzeugt ist, wird die Kind-Aufgabe an eine verkettete Liste in der Planer-Tabelle 321 hinzugefügt. Eine Aufgabe wird von einem Fach entfernt, wenn die Aufgabe ausgewiesen ist (evicted).
  • 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 SIMT-Ausführung verschiedenen Threads, leichter divergenten Ausführungspfaden durch ein gegebenes Thread-Programm zu folgen. 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 jeder 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, 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 einen bestimmten 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 eine „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 SM 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 (L1-)Cache 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 zwischengespeichert 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 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, Parallel-Verarbeitungs-Speicher 204 oder System-Speicher 104 wie benötigt geholt. Jeder SM 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. SMs 310 oder Textur-Einheiten 315, preROPs 325, können innerhalb eines GPC 208 umfasst sein kann. Ferner, während nur ein GPC 208 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.
  • 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, 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 seiner Ausführung zugreifbar ist. Der Thread-ID, welcher als ein eindimensionaler oder mehrdimensionaler numerischer Wert definiert werden kann, steuert verschiedene Aspekte des Verarbeitungs-Verhaltens des Threads. Zum Beispiel kann ein 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 des 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.
  • Programm-Ausführung- und -Präemption
  • Präemption bzw. Ausschließung (Präemption) kann benutzt werden, einen Prozessor zwischen mehreren verschiedenen Anwendungen zeitlich in Zeitscheiben zu teilen (time-slice), so dass die verschiedenen Anwendungen serialisiert werden und jede für eine kurze Zeitscheibe auf dem Prozessor ausführt. Präemption kann auch benutzt werden, momentan ausführenden Kontext für andere Zwecke zu entladen (unload). Zum Beispiel kann die Host-Schnittstelle 206 einen Kontext ausschließen, wenn die CPU 102 eine Kanal-Präemption oder eine Ablaufliste-Präemption initiiert, wobei ein Kanal eine Sammlung von Zeigern auf Verarbeitungs-Arbeit ist und wobei eine Anwendung einen oder mehrere Kanäle beinhalten kann. Eine Kanal-Präemption ist dadurch durchgeführt, dass ein gültiges Bit in einem Kanalram-Eintrag gelöscht wird und ein Kanal-Identifikator des Kanals, welcher auszuschließen ist, an ein Präemptions-Register geschrieben wird. Der spezifizierte Kanal wird dann von der PPU 202 entladen weg sowohl von Host und der Maschine (engine).
  • Eine Ablaufliste-Präemption (runlist preempt) ist dadurch durchgeführt, dass ein Zeiger auf das Ablaufliste-Register geschrieben wird. Der Zeiger kann auf eine neue Ablaufliste zeigen oder kann auf die Ablaufliste zeigen, welche momentan aktiv ist. Ablaufliste-Präemption führt dazu, dass das, was in einer PPU 202 abläuft, entladen wird. Die Host-Schnittstelle 206 beginnt dann eine Verarbeitung bei dem ersten Eintrag auf der Ablaufliste, welche mit dem Zeiger assoziiert ist, und sucht nach dem ersten gültigen Eintrag mit anhängender Arbeit. Der erste Kanal auf der Ablaufliste, welcher anhängende Arbeit hat, wird in die PPU 202 geladen.
  • Die Host-Schnittstelle 206 kann auch Kontext ausschließen, welcher ausführt, bevor eine Zeitscheibe abgelaufen ist, wenn der Kontext frei von Verfahren ist (out of methods) (d. h. Programmen) und wenn ein anderer Kontext auszuführen wartet. In einer Ausführungsform sind die Zeitscheiben nicht gleiche Mengen von Zeit, sondern sind stattdessen basierend auf dem Kontext-Verfahrens-Strom, so dass einem Kontext mit einem dichten Verfahrens-Strom eine größere Zeitscheibe alloziert ist, verglichen mit einem anderen Kontext, welcher einen spärlichen Verfahrens-Strom hat. Die Host-Schnittstelle 206 ist konfiguriert, dem Frontend 212 anzuzeigen, wenn die Host-Schnittstelle 206 nicht irgendwelche Verfahren für einen ausführenden Kontext hat. Die Host-Schnittstelle 206 initiiert jedoch nicht einen Kontext-Schalter (context switch) für den ausführenden Kontext, bis entweder die Zeitscheibe, welche für den Kontext alloziert worden ist, abgelaufen ist oder die Verarbeitungs-Pipeline untätig ist und es keine Verfahren gibt.
  • 4 ist ein Blockdiagramm der Host-Schnittstelle 206 und der Verarbeitungs-Pipeline, beginnend mit der Aufgabe-/Arbeit-Einheit 207 bis zu den GPCs 208 gemäß einer Ausführungsform der Erfindung. Der Präemptions-Prozess hat fünf Phasen, welche von dem Frontend 212 kontrolliert sind. Eine erste Phase (Phase 1) stoppt die Verarbeitung in dem momentanen Kontext. Für CTA-Level-Präemption heißt dies Stoppen von Arbeit bei einer CTA-Aufgabe-Grenze. Für Anweisungs-Level-Präemption heißt dies Stoppen von Arbeit bei einer SM 310-Anweisungs-Grenze. Wenn eine Unterbrechung oder ein Fehler auftritt, nachdem Präemption oder initiiert ist und während der Phase 1, wartet das Frontend 212 darauf, dass die anhängige Unterbrechung oder der Fehler gelöst wird, bevor zu Phase 2 fortgeschritten wird.
  • Sobald der Kontext gestoppt ist (und irgendwelche Unterbrechungen oder Fehler aufgeklärt oder gelöst worden sind), sichert Phase 2 den momentanen Kontext-Zustand im Speicher. Phase 3 setzt die Maschine zurück, bevor Phase 4 einen neuen Kontext-Zustand auf die Maschine lädt. Phase 5 startet erneut das Verarbeiten von irgendeiner Arbeit, welche in einer vorherigen Phase 1 ausgeschlossen wurde (preempted). Wenn ein Kontext ausgeschlossen wird, wählt die Host-Schnittstelle 206 einen neuen Kontext von der Ablaufliste, welcher auszuführen ist, und weist das Frontend 212 an, Kontext-Präemption zu beginnen. Das Frontend 212 konfiguriert die Verarbeitungs-Pipeline, um den neuen Kontext dadurch auszuführen, dass die fünf Phasen des Präemptions-Prozesses vollendet werden. Nachdem die fünf Phasen des Präemptions-Prozesses vollendet sind, sendet das Frontend 212 eine Bestätigung (ACK) an die Host-Schnittstelle 206. In einer Ausführungsform führt eine separate Grafik-Verarbeitungs-Pipeline (nicht in 4 gezeigt) grafikspezifische Operationen durch und das Frontend 212 wartet auch darauf, dass die Grafik-Verarbeitungs-Pipeline untätig wird. Typischerweise führen die Grafik-Verarbeitungs-Verfahren in kürzeren Zeiten aus verglichen mit Rechen-Verarbeitungs-Verfahren, so dass darauf Warten, dass die Grafik-Verarbeitungs-Pipeline untätig wird, vollendet werden kann, während die Verarbeitungs-Pipeline die erste Phase des Präemptions-Prozesses vollendet. Auch ist die Menge von Status-Information, welche in einer Grafik-Verarbeitungs-Pipeline gehalten ist, typischerweise viel größer als der Kontext-Zustand, welcher in der (Rechen)-Verarbeitungs-Pipeline gehalten ist. Darauf Warten, dass die Grafik-Verarbeitungs-Pipeline untätig ist, vermindert signifikant den Speicher, welcher benötigt ist, um den Kontext-Zustand zu fassen.
  • Bevor Präemption durchgeführt wird, wird ein Kontext-Puffer, um den CTA-Level(und Anweisungs-Level)-Kontext-Zustand für einen bestimmten Kontext zu speichern, mittels eines Programms, welches auf der CPU 102 ausführt, alloziert. Die Größe des Kontext-Puffers, welcher alloziert ist, kann auf der PPU 202-Konfiguration und der Anzahl von SMs 310 basiert sein.
  • Um die erste Phase des Präemptions-Prozesses zu vollenden, stoppt das Frontend 212, neue Verfahren von der Host-Schnittstelle 206 anzunehmen und gibt einen Präemptions-Befehl an die Aufgabe-/Arbeit-Einheit 207 aus. Wenn der Präemptions-Befehl von der Verarbeitungs-Einheit empfangen ist, stoppt die Verarbeitungs-Einheit Ausgeben einer Arbeit an eine stromabwärts angeordnete Einheit. Das Frontend 212 wartet darauf, dass alle stromabwärts gelegenen Einheiten Ausgeben von Arbeit stoppen und bestätigt dann ein Kontext-Einfriersignal (context freeze signal), um die zweite Phase des Präemptions-Prozesses zu sein. Bestätigung des Kontext-Einfrier-Signals stellt sicher, dass die Verarbeitungs-Pipeline nicht irgendeine Operation basierend auf den Transaktionen durchführt, welche benutzt sind, um den Kontext-Zustand zu sichern. Das Frontend 212 bestimmt auch, ob ein Warte-auf-Untätigkeit-Befehl verarbeitet ist, welcher erfordert, dass das Frontend 212 darauf wartet, dass die Verarbeitungs-Pipeline untätig wird, und, wenn dem so ist, unterbricht das Frontend 212 die Warte-auf-Untätigkeit-Operation und sichert Kontext-Zustands-Information, welche anzeigt, dass ein Warte-auf-Untätigkeit-Befehl für den Kontext ausgeführt wurde. Wenn der Kontext wieder aufgenommen wird, wird die Warte-auf-Untätigkeit-Ausführung von dem Frontend 212 erneut gestartet werden.
  • Wenn die Aufgabe-/Arbeit-Einheit 207 den Präemptions-Befehl (preempt command) empfängt, stoppt die Aufgabe-/Arbeit-Einheit 207 Einführen oder Anstoßen (launching) von neuer Arbeit. Schließlich bestimmt die Aufgabe-/Arbeit-Einheit 207, dass die ersten zwei Phasen des Präemptions-Prozesses vollendet sind und benachrichtigt das Frontend 212, dass die Verarbeitungs-Pipeline untätig ist. Das Frontend 212 wird dann den Kontext-Zustand speichern, welcher innerhalb der Aufgabe-/Arbeit-Einheit 207 gehalten ist, bevor die Verarbeitungs-Pipeline zurückgesetzt wird, um die dritte Phase des Präemptions-Prozesses zu vollenden. Wenn Anweisungs-Level-Präemption benutzt wird, wird der Kontext-Zustand, welcher innerhalb der GPCs 208 gehalten ist, von den GPCs 208 selbst gespeichert. Wenn CTA-Level-Präemption benutzt wird, werden die GPCs 208 entleert, so dass der Umfang von Kontext-Zustand, welcher gespeichert ist, vermindert ist.
  • Selbst nachdem die Aufgabe-/Arbeit-Einheit 207 Anstoßen (launching) von Arbeit stoppt, kann die Aufgabe-/Arbeit-Einheit 207 zusätzliche Arbeit empfangen, welche von den GPCs 208 während Ausführung von vorherigen Anweisungen erzeugt wird. Die Aufgabe-/Arbeit-Einheit 207 puffert die zusätzliche Arbeit, welche mittels des Frontends 212 als Teil des Kontext-Zustandes für die Aufgabe-/Arbeit-Einheit 207 zu speichern ist.
  • Wenn der Präemptions-Befehl empfangen ist, stoppt die Arbeit-Verteilungs-Einheit 340 ein Anstoßen von CTAs. Wenn CTA-Level-Präemption durchgeführt wird, werden die Verarbeitungs-Einheiten in der Verarbeitungs-Pipeline, welche stromabwärts von der Arbeit-Verteilungs-Einheit 340 sind, z. B. GPCs 208, entleert, so dass kein Kontext-Zustand in diesen stromabwärts gelegenen Verarbeitungs-Einheiten verbleibt. Daher wird die Menge von Kontext-Zustand vermindert, wenn CTA-Level-Präemption durchgeführt wird, verglichen mit Anweisungs-Level-Präemption, weil Anweisungs-Level-Präemption ein Entleeren der stromabwärts gelegenen Verarbeitungs-Einheiten nicht erfordert.
  • Die Arbeit-Verteilungs-Einheit 340 bestimmt, welche GPCs 208 empfangene Arbeit basierend auf Information ausführen werden, welche mittels der Aufgabe-Management-Einheit 300 erzeugt ist. Weil die GPCs 208 in einer Pipeline angeordnet sind (pipelined), kann ein einzelner GPC 208 mehrere Aufgaben gleichzeitig ausführen. Die Aufgabe-Management-Einheit 300 plant jede Verarbeitungs-Aufgabe zur Ausführung als entweder ein Gitter (grid) oder Queue. Die Arbeits-Verteilungs-Einheit 340 assoziiert jedes CTA mit einem spezifischen Gitter oder Queue für gleichzeitige Ausführung von einer oder mehreren Aufgaben. CTAs, welche zu einem Gitter gehören, haben implizite x, y, z-Parameter, welche die Position der jeweiligen CTA innerhalb des Gitters anzeigen. Die Arbeit-Verteilungs-Einheit 340 vollzieht die verfügbaren GPCs 208 nach (tracks) und stößt die CTAs an, wenn GPCs 208 verfügbar sind.
  • Während Anweisung-Level-Präemption reicht die Arbeit-Verteilungs-Einheit 340 den Präemptions-Befehl an den Pipeline-Manager 305 in den GPCs 208. Der Pipeline-Manager 305 kann einen Kontroller für jeden SM 310 umfassen. Auf Empfangen des Präemptions-Befehls hin, stoppen die SMs 310 ein Ausstellen von Anweisungen und treten in einen Fallen-Händler (trap handler) ein. Die SMs 310 warten auch darauf, dass alle Speicher-Transaktionen, welche mit vorher ausgestellten Anweisungen assoziiert sind, vollenden, d. h. darauf, dass alle ausstehenden Speicher-Anfragen vollenden. Speicher-Anfragen werden als noch ausstehend betrachtet, wenn Daten für eine Lese-Anfrage nicht zurückgegeben worden sind und wenn eine Bestätigung von der MMU 328 für eine Schreib-Anfrage nicht empfangen worden ist, für welche eine Bestätigung explizit angefragt wurde. Die Pipeline-Manager 305 halten Informationen über CTAs und Thread-Gruppen und vollziehen nach (track), welche Thread-Gruppen ausgeschlossen sind pro CTA.
  • Sobald die SMs 310 in den GPCs 208 gestoppt haben, Anweisungen auszustellen, und jeder SM 310 untätig wird, entlädt der Trap-Handler den Kontext-Zustand für die CTAs, welche auf den GPCs 208 ablaufen, und eine Kombination von einem oder mehr des Trap-Handlers, des Pipeline-Managers 305 und des Frontends 212 speichert den Kontext-Zustand. Der Kontext-Zustand, welcher entladen ist und gespeichert ist, umfasst Register innerhalb der SMs 310, Register innerhalb des Pipeline-Managers 305, Register innerhalb der GPCs 208, gemeinsamen Speicher, und dergleichen und wird in einem vordefinierten Puffer in Grafik-Speicher gespeichert. Auch werden Schreib-Vorgänge auf Speicher von den Zwischen-Speichern (caches) innerhalb der GPCs 208, z. B. L1.5-Cache 335, herausgezwungen in den Speicher (forced out to memory) und die Zwischen-Speicher werden ungültig gemacht (invalidated). Sobald der Kontext-Zustand entladen worden ist und gespeichert worden ist, wird der Trap-Handler alle aktiven Threads ausschalten (exit), wodurch die SMs 310 und die GPCs 208 untätig werden (idling).
  • Der Fangstellen-Händler (trap handler) steuert dann ein Signal von den SMs 310 an den Pipeline-Manager 305, welches anzeigt, dass die ersten zwei Phasen des Präemptions-Prozesses von den GPCs 208 vollendet worden sind und dass die GPCs 208 untätig sind. Der Pipeline-Manager 305 berichtet an die Arbeit-Verteilungs-Einheit 340, den Präemptions-Befehl bestätigend (ACKing), um anzuzeigen, dass die ersten zwei Phasen des Präemptions-Prozesses vollendet worden sind. Diese ACK wird stromaufwärts von der Arbeit-Verteilungs-Einheit 340 an die Aufgabe-Management-Einheit 300 gereicht und schließlich hoch bis zu dem Frontend 212.
  • Der Pipeline-Manager 305 hält Status-Informationen für jede Thread-Gruppe, welche innerhalb des GPCs 208 ausgeführt wurde, wenn der Präemptions-Befehl von der Arbeit-Verteilungs-Einheit 340 ausgegeben wurde. Die Status-Information zeigt an, ob eine Thread-Gruppe nach Komplettierung der Ausführung ausstieg, oder ob die Thread-Gruppe ausgeschlossen wurde (preempted). Die Status-Information wird von den Pipeline-Managern 305 gesichert und kann von den Pipeline-Managern 305 benutzt werden, um nur diejenigen Thread-Gruppen wieder herzustellen, welche ausgeschlossen wurden. Wenn alle der Threads in einer Thread-Gruppe aussteigen (exit), nachdem der Pipeline-Manager 305 den Präemptions-Befehl erhält und bevor der Fangstelle-Händler eingetreten ist, die Status-Information zu speichern, wird Status-Information für die Thread-Gruppe nicht gespeichert und die Thread-Gruppe wird nicht wieder hergestellt. Nachdem die GPCs 208 untätig sind, können die GPCs zurückgesetzt werden, um die dritte Phase des Präemptions-Prozesses zu vollenden.
  • Das Frontend 212 vollendet dann die zweite Phase des Präemptions-Prozesses, indem der Kontext-Zustand, welcher von dem Frontend 212 gehalten ist, herausgeschrieben wird. Das Frontend 212 sichert alle Register und ramchains heraus in den Kontext-Zustands-Puffer für den ausgeschlossenen Kontext. Um die dritte Phase des Präemptions-Prozesses zu vollenden, bestätigt oder behauptet (asserts) das Frontend 212 ein Kontext-Rücksetz-Signal, welches von der Verarbeitungs-Pipeline empfangen wird, z. B. der Aufgabe-/Arbeit-Einheit 207 und den GPCs 208.
  • Wenn ein Kontext auszuführen ausgewählt ist, muss die Host-Schnittstelle 206 bestimmen, ob der ausgewählte Kontext ein Kontext ist, welcher vorher ausgeschlossen wurde (preempted). Eine Kontext-erneut-Laden-(ctx_reload)-Flagge, welche anzeigt, ob ein Kontext ausgeschlossen wurde, wird von der Host-Schnittstelle 206 gehalten. Wenn die Host-Schnittstelle 206 erkennt, dass der ausgewählte Kontext ausgeschlossen wurde, wird der vorher entladene und gespeicherte Kontext-Zustand erneut geladen, bevor Ausführung des ausgewählten Kontextes wieder aufnimmt. Ein Kontext, welcher ausgeschlossen worden ist, wird wieder geladen, selbst wenn es keine übrigen Verfahren für den ausgewählten Kontext gibt, weil es Arbeit geben kann, welche mittels der SMs 310 während der Ausführung der Verfahren erzeugt wurde und als Teil des Kontext-Zustands gesichert wurde.
  • Das Frontend 212 signalisiert an die Host-Schnittstelle 206, ob der Kontext untätig war, als die Host-Schnittstelle 206 die Präemption initiierte. Wenn der Kontext untätig war, d. h. die Verarbeitungs-Pipeline untätig war und es keine ausstehenden Speicher-Anfragen gab, muss der ausgeschlossene (preempted) Kontext nicht erneut geladen werden, bevor die Ausführung des Kontextes wieder aufnimmt. Wenn der Kontext nicht untätig war, sichert die Host-Schnittstelle 206 den Kontext-erneut-Laden-Zustand, welcher zu prozessieren ist, wenn der Kanal erneut geladen wird.
  • Es gibt auch den Fall, wo die Verarbeitungs-Pipeline bereits untätig ist, wenn das Frontend 212 den Präemptions-Befehl von der Host-Schnittstelle 206 empfängt. Wenn die Verarbeitungs-Pipeline bereits untätig ist, sendet das Frontend 212 keinen Präemptions-Befehl an die Aufgabe-/Arbeit-Einheit 207, sondern dauert mit der zweiten Phase des Präemptions-Prozesses an. Daher sollte der Untätigkeits-Zustand der Aufgabe-/Arbeit-Einheit 207 und der GPCs 208 diese Einheit in die Lage versetzen, einen neuen Kontext-Zustand zu empfangen oder einen Kontext-Zustand wieder herzustellen. Zum Beispiel sollte die Aufgabe-/Arbeit-Einheit 207 derart in einem Zustand sein, dass keine Aufgaben ablaufen. Die Pipeline-Manager 305 sollten nur ausgeschlossene (preempted) Thread-Gruppen oder CTAs wieder herstellen und sollten nicht Thread-Gruppen wieder herstellen, welche ausstiegen.
  • Wenn das Frontend 212 die vierte Phase des Präemptions-Prozesses vollendet, wird der ausgewählte Kontext-Zustand von einem Kontext-Puffer gelesen und in die Register und ramchains geladen. Das Kontext-Frier-Signal wird von dem Frontend 212 von dem Start der zweiten Phase bis zu dem Ende der vierten Phase des Präemptions-Prozesses bestätigt oder behauptet (asserted). Bestätigung des Kontext-Frier-Signals (contect freeze signal) stellt sicher, dass die Verarbeitungs-Pipeline nicht irgendeine Operation basierend auf den Transaktionen durchführt, welche von dem Frontend 212 benutzt sind, um den Kontext-Zustand zu sichern und wieder herzustellen.
  • Das Frontend 212 initiiert die fünfte Phase (Phase 5) des Präemptions-Prozesses dadurch, dass sie einen Präemptions-Wiederherstellen-Befehl an die Aufgabe-/Arbeit-Einheit 207 ausgibt. Nachdem die Aufgabe-/Arbeit-Einheit 207 den Präemptions-Wiederherstellen-Befehl empfängt, bestätigt die Aufgabe-/Arbeit-Einheit 207 nicht ein Bereit-Signal an das Frontend 212, so dass keine neue Arbeit von dem Frontend 212 an die Aufgabe-/Arbeit-Einheit 207 gereicht werden kann, bis der Präemptions-Prozess vollendet ist. Die Arbeit-Verteilungs-Einheit 340 innerhalb der Aufgabe-/Arbeit-Einheit 207 empfängt den Präemptions-Wiederherstellen-Befehl und stellt den ausgewählten Kontext-Zustand wieder her, wobei die wieder hergestellten Aufgaben in die GPCs 208 wieder eingespielt werden und ausgeschlossene CTAs und Thread-Gruppen in die Pipeline-Manager 305 bzw. die SMs 310 zurück wieder hergestellt werden.
  • Zum Beispiel gibt ein Pipeline-Manager 305 den Präemptions-Wiederherstellen-Befehl aus, um einen jeweiligen SM 310 zu konfigurieren, in einen „Präemption-Wiederherstellen-Beginnen”-Modus einzutreten. Der Pipeline-Manager 305 sendet dann die ausgeschlossenen CTAs und Thread-Gruppen an den SM 310. Nachdem der Pipeline-Manager 305 alle ausgeschlossenen Thread-Gruppen wieder hergestellt hat, gibt der Pipeline-Manager 305 einen Befehl an den SM 310 aus, was anzeigt, dass der „Präemption-Wiederherstellen-Ende”-Modus verlassen werden sollte. Wenn CTA-Level-Präemption benutzt wird, haben die GPCs 308 nicht irgendeinen gespeicherten Kontext-Zustand erneut zu laden und es gibt keinen Thread-Gruppe-Zustand wieder herzustellen.
  • Wenn Anweisung-Level-Präemption benutzt ist, um einen ausgewählten Kontext wieder herzustellen, lesen die GPCs 308 den Kontext-Zustand von dem ausgewählten Kontext von einem Kontext-Puffer und laden die Register und den gemeinsamen Speicher. Pipeline-Manager 305 starten erneut alle die CTAs, welche ausgeschlossen wurden, indem die CTAs an den jeweiligen SM 310 gesendet werden, auf welchem jedes CTA ausführte, in der Ordnung, in welcher die CTAs berichtet waren, ausgeschlossen wurden. Diese Technik stellt sicher, dass jedes CTA in demselben physikalischen CTA-Fach (slot) in einem SM 310 angestoßen ist (launched), wie das CTA besetzte, als der Kontext ausgeschlossen wurde. Thread-Gruppen werden in derselben physikalischen Thread-Gruppe-ID angestoßen (launched). Ein erneutes Starten der Thread-Gruppen in derselben Stelle nach Präemption ist vorteilhaft, weil die Thread-Gruppen und die CTAs dadurch garantiert sind, nicht den Speicher und andere Ressourcen zu überschreiben, welche in dem jeweiligen SM 310 verfügbar sind. Jeder SM 310 stellt Register-Werte, Barrieren (barriers), einen Programm-Zähler, einen Stapel-Zeiger (stack pointer), eine aktive Maske für jede Thread-Gruppe und dergleichen wieder her.
  • Schließlich bestätigt (ACKs) das Frontend 212 den ursprünglichen Präemptions-Befehl an die Host-Schnittstelle 206. Die ACK zeigt an, dass der Präemptions-Prozess vollendet ist und dass Ausführung des ausgewählten Kontextes initiiert worden ist. Irgendwelche vorher ausgeschlossenen CTAs haben Ausführung in der Aufgabe-/Arbeit-Einheit 207 und dem GPCs 208 wieder aufgenommen. Wenn Anweisung-Level-Präemption benutzt wird, haben vorher ausgeschlossene Threads Ausführung auf den SMs 310 wieder aufgenommen. Die Host-Schnittstelle 206 kann nun damit beginnen, neue Arbeit in die Grafik-Pipeline zu senden.
  • In einer Ausführungsform bestätigt (ACKs), dass Frontend 212 den ursprünglichen Präemptions-Befehl, nachdem der Präemptions-Wiederherstellen-Befehl an die Aufgabe-/Arbeit-Einheit 207 ausgegeben worden ist, und die Aufgabe-/Arbeit-Einheit 207 puffert irgendeine neue Arbeit, welche nach dem Präemptions-Wiederherstellen-Befehl empfangen ist, bis Phase 5 vollendet ist. Die Aufgabe-/Arbeit-Einheit 207 stößt keine neuen (nicht wieder hergestellten) CTAs an (launced), bis der Präemptions-Prozess vollendet ist. Das Frontend 212 hat daher keine Kenntnis (unaware), wann die fünfte Phase vollendet ist. Wenn die Aufgabe-/Arbeit-Einheit 207 nicht alles der neuen Arbeit puffern kann, negiert die Aufgabe-/Arbeit-Einheit 207 das Bereit-Signal an das Frontend 212. Das Frontend 212 ist jedoch nicht in der Lage, zu unterscheiden, ob das Bereit-Signal während oder nach Vollendung des Präemptions-Prozesses negiert ist.
  • 5A illustriert ein Entlade-Verfahren 500 zum Entladen eines Kontext-Zustands, wenn ein Prozess ausgeschlossen ist bei einem Anweisungs-Level, gemäß einer Ausführungsform der Erfindung. Obwohl die Verfahrensschritte im Kontext mit den Systemen von 1, 2, 3A, 3B und 4 beschrieben sind, werden Fachleute in der Technik verstehen, dass irgendein System, welches konfiguriert ist, die Verfahrensschritte durchzuführen, in irgendeiner Ordnung, innerhalb des Geltungsbereichs der Erfindungen ist.
  • Bei Schritt 505 gibt die Host-Schnittstelle 206 einen Anweisungs-Level-Präemptions-Befehl an das Frontend 212 aus und das Entladen des momentanen Kontextes ist initiiert. Bei Schritt 510 bestimmt das Frontend 212, ob die Verarbeitungs-Pipeline untätig ist, und wenn dem so ist, dann schreitet das Frontend 212 direkt zu Schritt 545 fort, um den Kontext-Zustand zu speichern, welcher von dem Frontend 212 gehalten ist.
  • Wenn bei Schritt 510 das Frontend 212 bestimmt, dass die Verarbeitungs-Pipeline nicht untätig ist, dann stoppt bei Schritt 515 das Frontend 212 das Anstoßen von neuer Arbeit für den momentanen Kontext. Bei Schritt 520 gibt das Frontend 212 einen Präemptions-Befehl an die Aufgabe-/Arbeit-Einheit 207 aus. Bei Schritt 525 stoppt die Aufgabe-Management-Einheit 300 innerhalb der Aufgabe-/Arbeit-Einheit 207 ein Ausstellen (issuing) von Aufgaben an die Arbeit-Verteilungs-Einheit 340 und gibt den Präemptions-Befehl an die Arbeit-Verteilungs-Einheit 340 aus. Bei Schritt 525 stoppt die Arbeit-Verteilungs-Einheit 340 auch ein Anstoßen (launching) von CTAs und gibt den Präemptions-Befehl an die Pipeline-Manager 305 aus. Die Pipeline-Manager 305 geben einen Anweisung-Level-Präemptions-Befehl an die SMs 310 aus.
  • Bei Schritt 525 stoppen die SMs 310 ein Ausführen von Anweisungen und in Schritt 530 warten die SMs 310 darauf, dass irgendwelche ausstehenden Speicher-Transaktionen vollenden. Jeder SM 310 wiederholt den Schritt 530, bis alle der Speicher-Transaktionen vollendet sind. Die SMs 310 zeigen dem Pipeline-Manager 305 an, ob jede Thread-Gruppe ausstieg oder ausgeschlossen wurde (preempted). Wenn alle der ausstehenden Speicher-Transaktionen vollendet sind, wird bei Schritt 535 der Kontext-Zustand, welcher in den SMs 310 gehalten ist, in einem Kontext-Puffer gespeichert und der Kontext-Zustand, welcher in dem Pipeline-Manager 305 gehalten ist, wird auch in dem Kontext-Puffer gespeichert.
  • Bei Schritt 540 berichten die Pipeline-Manager 305 an die Arbeit-Verteilungs-Einheit 340, dass der Anweisung-Level-Teil der Verarbeitungs-Pipeline, z. B. die SMs 310 und die GPCs 208, untätig sind, und die Arbeit-Verteilungs-Einheit 340 sichert dann den CTA-Level-Zustand, welcher in der Arbeit-Verteilungs-Einheit 340 gehalten ist, für den momentanen Kontext. Die Arbeit-Verteilungs-Einheit 340 berichtet an die Aufgabe-Management-Einheit 300, dass sie diese Phase der Präemption vollendet hat. Die Aufgabe-Management-Einheit 300 sichert dann den Aufgabe-Level-Zustand, welcher in der Aufgabe-Management-Einheit 300 gehalten ist. Die Aufgabe-Management-Einheit 300 berichtet an das Frontend 212, wann oder wenn (when) der momentane Zustand gespeichert worden ist, und bei Schritt 445 speichert das Frontend 212 den Kontext-Zustand, welcher für den momentanen Kontext mittels des Frontends 212 gehalten ist, in oder auf den Kontext-Puffer. Bei Schritt 550 speichert dann das Frontend 212 eine Indikation, dass der gesicherte Kontext-Zustand für einen ausgeschlossenen Kontext ist (preempted context) und setzt die Verarbeitungs-Pipeline zurück.
  • 5B illustriert ein Wiederherstellen-Verfahren 560 zum Wiederherstellen eines Kontext-Zustandes, wenn ein Prozess, welcher bei dem Anweisungs-Level ausgeschlossen wurde (preempted), wieder hergestellt wird, gemäß einer Ausführungsform der Erfindung. Obwohl die Verfahrensschritte im Kontext mit den Systemen von 1, 2, 3A, 3B und 4 beschrieben sind, werden Fachleute in der Technik verstehen, dass irgendein System, welches konfiguriert ist, die Verfahrensschritte durchzuführen, in irgendeiner Ordnung, innerhalb des Geltungsbereichs der Erfindungen ist.
  • Bei Schritt 565 initiiert das Frontend 212 eine Wiederherstellung eines gesicherten Kontextes für einen Kontext, welcher von der Host-Schnittstelle 206 ausgewählt ist. Bei Schritt 570 bestätigt das Frontend 212 das Kontext-Frier-Signal (context freeze signal), um sicherzustellen, dass die Verarbeitungs-Pipeline nicht irgendeine Operation basierend auf den Transaktionen durchführt, welche von dem Frontend 212 benutzt sind, um den Kontext-Zustand wieder herzustellen. Bei Schritt 575 wird der ausgewählte Kontext-Zustand von einem Kontext-Puffer von dem Frontend 212 und der Aufgabe-/Arbeit-Einheit 207 gelesen und bei dem Aufgabe- und CTA-Level wieder hergestellt.
  • Bei Schritt 580 gibt jeder Pipeline-Manager 305 einen Befehl herunter aus, um den jeweiligen SM 310 zu konfigurieren, in einen „Präemption-Wiederherstellen-Beginnen”-Modus einzutreten, wodurch dadurch die SMs 310 in einen pausierten Zustand konfiguriert werden. Bei Schritt 580 sendet der Pipeline-Manager 305 ausgeschlossene (preempted) CTAs und Thread-Gruppen an die SMs 310 und die GPCs 308 stellen den Anweisung-Level-Kontext-Zustand wieder her, welcher in den SMs 310 für den ausgewählten Kontext gehalten wurde, wieder her, welcher bei Schritt 535 (siehe 5A) gesichert wurde. Nachdem der CTA- und Anweisung-Level-Zustand wieder hergestellt ist, geben die Pipeline-Manager 305 einen Befehl an die jeweiligen SMs 310 aus, was anzeigt, dass der „Präemption-Wiederherstellen-Ende”-Modus verlassen werden sollte, und bei Schritt 582 negiert das Frontend 212 das Kontext-Frier-Signal. Schritte 580 und 582 können simultan durchgeführt werden. Bei Schritt 585 werden die CTAs in der ausgeschlossenen Ordnung angestoßen und bei Schritt 590 wird Ausführung wieder aufgenommen unter Benutzung des wieder hergestellten Kontext-Zustandes für den ausgewählten Kontext. Bei Schritt 590 bestätigt (ACKs) das Frontend 212 auch die Host-Schnittstelle 206, um zu signalisieren, dass der Anweisung-Level-Präemption-Befehl Ausführung vollendet hat. Die Host-Schnittstelle 206 kann dann damit beginnen, mehr Arbeit von den Schiebe-Puffer (push buffer) an das Frontend 212 zu senden. In einer Ausführungsform bestätigt die Aufgabe-/Arbeit-Einheit 207 und negiert das Kontext-Frieren (context freeze) und Schritt 590 wird durchgeführt (mittels des Frontends 212), nachdem das Kontext-Frieren in Schritt 570 bestätigt ist. Die Aufgabe-/Arbeit-Einheit puffert die neue Arbeit von dem Schiebe-Puffer, bis der Anweisung-Level-Präemption-Befehl Ausführung vollendet hat. Die neue Arbeit wird nicht mittels der Aufgabe-/Arbeit-Einheit ausgegeben, bis nachdem die CTAs in Schritt 585 angestoßen sind.
  • Wie vorher erläutert ist, kann der Kontext-Zustand, welcher gesichert ist und wieder hergestellt ist, auf Kosten von möglicherweise längeren Wartezeiten zum Stoppen des laufenden Kontextes vermindert werden, indem bei dem CTA-Level anstatt bei dem Anweisungs-Level ausgeschlossen wird (preempting). Wenn ein Kontext bei dem CTA-Level ausgeschlossen wird, vollenden die SMs 310 Ausführung von irgendwelchen angestoßenen CTAs, so dass der CTA-Zustand nicht innerhalb der Pipeline-Manager 305 und GPCs 208 gehalten ist, welcher gespeichert werden muss. Jedoch wird ein Aufgabe-Level-Zustand, welcher benötigt ist, um zumindest einen zusätzlichen CTA anzustoßen, um Ausführung der Aufgabe zu vollenden, für den ausgeschlossenen Kontext gespeichert.
  • In einer Ausführungsform ist der Kontext bei dem Aufgabe-Level ausgeschlossen (preempted) und die Aufgabe-/Arbeit-Einheit 207 vollendet Ausführung von irgendeiner Aufgabe, welche zumindest einen CTA angestoßen hat, so dass Aufgabe-Zustand nicht gespeichert werden muss. Ausschließen (preempting) bei dem Aufgabe-Level kann ein Anstoßen von einem oder mehr zusätzlichen CTAs erfordern, um Ausführung der Aufgabe zu vollenden, bevor der Frontend-Zustand gesichert ist. Wenn Aufgabe-Level-Präemption durchgeführt wird, wird kein Zustand für entweder Aufgaben oder CTAs gespeichert.
  • 6A illustriert ein Entladen-Verfahren 600 zum Entladen eines Kontext-Zustandes, wenn ein Prozess bei einem CTA-Level ausgeschlossen ist gemäß einer Ausführungsform der Erfindung. Obwohl die Verfahrensschritte im Kontext mit den Systemen von 1, 2, 3A, 3B und 4 beschrieben sind, werden Fachleute in der Technik verstehen, dass irgendein System, welches konfiguriert ist, die Verfahrensschritte durchzuführen, in irgendeiner Ordnung, innerhalb des Geltungsbereichs der Erfindungen ist.
  • Bei Schritt 605 gibt die Host-Schnittstelle 206 einen CTA-Level-Präemptions-Befehl an das Frontend 212 aus und das Entladen des momentanen Kontextes ist initiiert. Bei Schritt 610 bestimmt das Frontend 212, ob die Verarbeitungs-Pipeline untätig ist, und wenn dem so ist, dann schreitet das Frontend 212 direkt zu Schritt 645 fort, um den Kontext-Zustand zu speichern, welcher mittels des Frontends 212 gehalten ist.
  • Wenn das Frontend 212 bei Schritt 610 bestimmt, dass die Verarbeitungs-Pipeline nicht untätig ist, dann stoppt bei Schritt 615 das Frontend 212 ein Anstoßen von neuer Arbeit für den momentanen Kontext. Bei Schritt 620 gibt das Frontend 212 einen Präemptions-Befehl an die Aufgabe-/Arbeit-Einheit 207 aus. Bei Schritt 625 stoppt die Aufgabe-Management-Einheit 300 innerhalb der Aufgabe-/Arbeit-Einheit 207 ein Ausgeben von Aufgaben an die Arbeit-Verteilungs-Einheit 340 und gibt den Präemptions-Befehl an die Arbeit-Verteilungs-Einheit 340 aus. Die Arbeit-Verteilungs-Einheit 340 stoppt ein Anstoßen von CTAs und bei Schritt 630 wartet die Arbeit-Verteilungs-Einheit 340 darauf, dass die GPCs 208 untätig werden.
  • Wenn die Arbeit-Verteilungs-Einheit 340 bei Schritt 630 bestimmt, dass die GPCs 208 nicht untätig sind, dann bestimmt bei Schritt 635 die Arbeit-Verteilungs-Einheit 340, ob ein Zeitnehmer oder ein Zeitzähler (timer) abgelaufen ist. Der Zeitnehmer begrenzt die Anzahl von Taktzyklen, für wie lange die Arbeit-Verteilungs-Einheit 340 warten wird, dass die GPCs untätig werden. Die Anzahl von Taktzyklen kann ein programmierter Wert sein und, in einer Ausführungsform, wenn der Wert überschritten ist, führt die Arbeit-Verteilungs-Einheit 340 eine Präemption bei dem Anweisungs-Level anstatt bei dem CTA-Level durch. Wenn die Arbeit-Verteilungs-Einheit 340 bei Schritt 635 bestimmt, dass der Zeitnehmer nicht abgelaufen ist, dann kehrt die Arbeit-Verteilungs-Einheit 340 zu Schritt 630 zurück. Anderenfalls, wenn der Zeitnehmer abgelaufen ist, schreitet die Arbeit-Verteilungs-Einheit 340 zu Schritt 520 von 5A fort, um Präemption bei dem Anweisungs-Level durchzuführen.
  • Wenn bei Schritt 630 die GPCs 208 untätig sind, sichert bei Schritt 630 die Arbeit-Verteilungs-Einheit 340 den CTA-Level-Zustand, welcher in der Arbeit-Verteilungs-Einheit 340 für den momentanen Kontext gehalten ist. Die Arbeit-Verteilungs-Einheit 340 berichtet an die Aufgabe-Management-Einheit 300, dass der momentane Zustand gesichert worden ist. Die Aufgabe-Management-Einheit 300 sichert dann den Aufgabe-Level-Zustand, welcher in der Aufgabe-Management-Einheit 300 gehalten ist. Die Aufgabe-Management-Einheit 300 berichtet an das Frontend 212, wann oder wenn der momentane Zustand gesichert worden ist, und bei Schritt 645 speichert das Frontend den Kontext-Zustand, welcher für den momentanen Kontext mittels des Frontends 212 gehalten ist, an oder in den Kontext-Puffer. Bei Schritt 650 speichert dann das Frontend 212 eine Indikation, dass der gesicherte Kontext-Zustand für einen ausgeschlossenen Kontext ist und setzt die Verarbeitungs-Pipeline zurück.
  • 6B illustriert ein Wiederherstellen-Verfahren 660 zum Wiederherstellen eines Kontext-Zustandes, wenn ein Prozess, welcher bei dem CTA-Level ausgeschlossen wurde, wieder hergestellt ist, gemäß einer Ausführungsform der Erfindung. Obwohl die Verfahrensschritte im Kontext mit den Systemen von 1, 2, 3A, 3B und 4 beschrieben sind, werden Fachleute in der Technik verstehen, dass irgendein System, welches konfiguriert ist, die Verfahrensschritte durchzuführen, in irgendeiner Anordnung, innerhalb des Geltungsbereichs der Erfindungen ist.
  • Bei Schritt 665 initiiert das Frontend 212 eine Wiederherstellung eines Kontextes, welcher vorher bei dem CTA-Level ausgeschlossen wurde (preempted). Bei Schritt 670 bestätigt das Frontend 212 das Kontext-Frier-Signal (context freeze signal), um sicherzustellen, dass die Verarbeitungs-Pipeline nicht irgendeine Operation basierend auf den Transaktionen durchführt, welche mittels des Frontends 212 benutzt sind, um den Kontext-Zustand wieder herzustellen. Bei Schritt 675 wird der ausgewählte Kontext-Zustand von einem Kontext-Puffer mittels des Frontends 212 und der Aufgabe-/Arbeit-Einheit 207 gelesen und wird bei dem Aufgabe- und CTA-Level wieder hergestellt. Bei Schritt 682 wird das Kontext-Frier-Signal negativ bestätigt (deasserted).
  • Bei Schritt 685 werden die CTAs, welche ausgeschlossen wurden, als dieser Kontext das letzte Mal ablief, mittels der Aufgabe-/Arbeit-Einheit 207 in die GPCs 208 wieder angestoßen (relaunched). Bei Schritt 690 bestätigt (ACKs) das Frontend 212 die Host-Schnittstelle 206, um zu signalisieren, dass der CTA-Level-Präemptions-Befehl Ausführung vollendet hat. Die Host-Schnittstelle 206 kann dann damit beginnen, mehr Arbeit von dem Schiebe-Puffer (push buffer) an das Frontend 212 zu senden. In einer Ausführungsform bestätigt die Aufgabe-/Arbeit-Einheit 207 und negiert das Kontext-Frieren und Schritt 690 wird durchgeführt (mittels des Frontends 212), nachdem das Kontext-Frieren in Schritt 670 bestätigt ist. Die Aufgabe-/Arbeit-Einheit puffert die neue Arbeit von dem Schiebe-Puffer, bis der Anweisung-Level-Präemptions-Befehl Ausführung vollendet hat. Die neue Arbeit wird nicht mittels der Aufgabe-/Arbeit-Einheit ausgegeben, bis nachdem die CTAs in Schritt 685 angestoßen sind.
  • Die Fähigkeit, einen Kontext entweder bei dem Anweisung-Level oder bei den CTA-Level auszuschließen (preempt), kann für jeden bestimmten Kontext spezifiziert werden. Ein lang ablaufender Kontext kann bei dem Anweisungs-Level ausgeschlossen werden, um eine lange Verzögerung zwischen Initiierung der Präemption und Vollendung der Präemption zu vermeiden. Ein Kontext, welcher nicht notwendiger Weise lang ablaufend ist, aber eine große Menge von Zustand hält, kann bei dem CTA-Level ausgeschlossen werden, um die Menge von Kontext-Zustand zu minimieren, welche gespeichert ist.
  • Eine Ausführungsform der Erfindung kann als ein Programm-Produkt zur Benutzung mit einem Computer-System implementiert sein. Das Programm oder die Programme des Programm-Produkts definieren Funktionen der Ausführungsformen (einschließlich der hierin beschriebenen Verfahren) und können auf einer Verschiedenheit von Computer-lesbaren Speichermedien beinhaltet sein. Illustrative Computer-lesbare Speichermedien umfassen, sind jedoch nicht darauf beschränkt: (i) nicht-schreibbare Speichermedien, z. B. Nur-Lese-Speicher-Geräte innerhalb eines Computers (wie CD-ROM-Platten, welche mittels eines CD-ROM-Laufwerks lesbar sind, Flash-Speicher, ROM-Chips oder irgendein anderer Typ von Festkörper-nicht-volatilem Halbleiter-Speicher), auf welchen Informationen permanent gespeichert ist; und (ii) schreibbare Speichermedien (z. B. Floppy-Disks innerhalb eines Disketten-Laufwerks oder eines Festplatten-Laufwerks oder irgendein anderer Typ von Festkörper-Halbleiter-Speicher mit willkürlichem Zugriff), auf welchen veränderbare Information gespeichert ist.
  • Die Erfindung ist oben mit Bezug auf spezifische Ausführungsformen beschrieben worden. Fachleute in der Technik werden jedoch verstehen, dass verschiedene Modifikationen und Änderungen daran gemacht werden können, ohne von dem weiteren Geist und Geltungsbereich abzuweichen, wie in den angehängten Ansprüchen ausgeführt. Die vorangehende Beschreibung und die Zeichnungen sind demgemäß in einem illustrativen anstatt in einem restriktiven Sinne anzusehen.

Claims (10)

  1. Verfahren eines Ausschließens von Ausführung von Programm-Anweisungen in einem Mehrprozess-gestützten System, wobei das Verfahren aufweist: Ausführen von Programm-Anweisungen in einer Verarbeitungs-Pipeline innerhalb des Mehrprozess-gestützten Systems unter Benutzung eines ersten Kontextes; Ausschließen von Ausführung unter Benutzung des ersten Kontextes bei einem Anweisungs-Level, um verschiedene Programm-Anweisungen in dem Mehrprozess-gestützten System unter Benutzung eines zweiten Kontextes auszuführen; Speichern einer Indikation, dass Ausführung der Programm-Anweisungen unter Benutzung des ersten Kontextes ausgeschlossen wurde; und Ausführen der verschiedenen Programm-Anweisungen in der Verarbeitungs-Pipeline unter Benutzung des zweiten Kontextes.
  2. Verfahren gemäß Anspruch 1, ferner aufweisend, vor Ausführen der verschiedenen Programm-Anweisungen, Speichern eines Teils des ersten Kontext-Zustands, welcher innerhalb der Verarbeitungs-Pipeline während Ausführung der Programm-Anweisungen unter Benutzung des ersten Kontextes gehalten ist.
  3. Verfahren gemäß Anspruch 1, wobei das Ausschließen der Ausführung unter Benutzung des ersten Kontextes ferner aufweist Speichern eines ersten Kontext-Zustandes für jede Thread-Gruppe, welche in einem Streaming-Mehrprozessor ausführt, welche ausgeschlossen ist, wenn eine Präemption bei dem Anweisungs-Level auftritt.
  4. Verfahren gemäß Anspruch 1, wobei das Ausschließen der Ausführung unter Benutzung des ersten Kontextes ferner aufweist Bestimmen, dass Streaming-Mehrprozessoren, welche konfiguriert sind, die Programm-Anweisungen unter Benutzung des ersten Kontextes auszuführen, untätig sind.
  5. Verfahren gemäß Anspruch 1, ferner aufweisend: Bestimmen, vor Ausführen der verschiedenen Programm-Anweisungen, dass die Verarbeitungs-Pipeline untätig ist; und Zurücksetzen der Verarbeitungs-Pipeline ohne Speichern des Kontext-Zustandes, welcher in der Verarbeitungs-Pipeline für den ersten Kontext gehalten ist.
  6. Verfahren eines Ausschließens von Ausführung von Programm-Anweisungen in einem Mehrprozess-gestützten System, wobei das Verfahren aufweist: Ausführen von Programm-Anweisungen in einer Verarbeitungs-Pipeline innerhalb des Mehrprozess-gestützten Systems unter Benutzung eines ersten Kontextes; Ausschließen von Ausführung unter Benutzung des ersten Kontextes bei einem Rechen-Thread-Feld-Level, um verschiedene Programm-Anweisungen in dem Mehrprozess-gestützten System unter Benutzung eines zweiten Kontextes auszuführen; Speichern einer Indikation, dass Ausführung der Programm-Anweisungen unter Benutzung des ersten Kontextes ausgeschlossen wurde; und Ausführen der verschiedenen Programm-Anweisungen in der Verarbeitungs-Pipeline unter Benutzung des zweiten Kontextes.
  7. Verfahren gemäß Anspruch 6, ferner aufweisend, vor Ausführen der verschiedenen Programm-Anweisungen, Vollenden von Ausführung von allen Rechen-Thread-Feldern, welche schon zur Ausführung in der VerarbeitungsPipeline angestoßen sind, und Speichern des ersten Kontext-Zustands, welcher gehalten ist, um ein zusätzliches Rechen-Thread-Feld anzustoßen und Ausführen der Programm-Anweisungen unter Benutzung des ersten Kontextes zu vollenden.
  8. Verfahren gemäß Anspruch 6, wobei Ausschließen der Ausführung unter Benutzung des ersten Kontextes ferner aufweist: Vollenden von Ausführung aller Rechen-Thread-Felder, welche bereits zur Ausführung in der Verarbeitungs-Pipeline angestoßen sind; Anstoßen zumindest eines zusätzlichen Rechen-Thread-Feldes, um Ausführung der Programm-Anweisungen unter Benutzung des ersten Kontextes zu vollenden; und Vollenden von Ausführung des zusätzlichen Rechen-Thread-Feldes mittels der Verarbeitungs-Pipeline.
  9. Verfahren gemäß Anspruch 6, wobei das Ausschließen der Ausführung unter Benutzung des ersten Kontextes ferner aufweist Bestimmen, dass Streaming-Mehrprozessoren, welche konfiguriert sind, die Programm-Anweisungen unter Benutzung des ersten Kontextes auszuführen, untätig sind.
  10. Verfahren gemäß Anspruch 6, ferner aufweisend: Bestimmen, vor Ausführen der verschiedenen Programm-Anweisungen, dass die Verarbeitungs-Pipeline untätig ist; und Zurücksetzen der Verarbeitungs-Pipeline ohne Speichern von Kontext-Zustand, welcher in der Verarbeitungs-Pipeline für den ersten Kontext gehalten ist.
DE201210220365 2011-11-10 2012-11-08 Aufgabe-Thread-Feld-Granularität-Ausführung-Präemption Pending DE102012220365A1 (de)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US13/294,045 2011-11-10
US13/294,045 US20130124838A1 (en) 2011-11-10 2011-11-10 Instruction level execution preemption
US13/302,962 US20130132711A1 (en) 2011-11-22 2011-11-22 Compute thread array granularity execution preemption
US13/302,962 2011-11-22

Publications (1)

Publication Number Publication Date
DE102012220365A1 true DE102012220365A1 (de) 2013-05-16

Family

ID=48145390

Family Applications (1)

Application Number Title Priority Date Filing Date
DE201210220365 Pending DE102012220365A1 (de) 2011-11-10 2012-11-08 Aufgabe-Thread-Feld-Granularität-Ausführung-Präemption

Country Status (3)

Country Link
CN (1) CN103197917A (de)
DE (1) DE102012220365A1 (de)
TW (1) TWI457828B (de)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10210593B2 (en) * 2016-01-28 2019-02-19 Qualcomm Incorporated Adaptive context switching
CN109961136B (zh) * 2017-12-14 2020-05-19 中科寒武纪科技股份有限公司 集成电路芯片装置及相关产品
CN110134074B (zh) * 2018-02-02 2022-03-01 华中科技大学 一种生产线控制系统及其控制方法
CN108874548B (zh) * 2018-07-11 2021-04-02 深圳市东微智能科技股份有限公司 数据处理调度方法、装置、计算机设备和数据处理系统
CN109445565B (zh) * 2018-11-08 2020-09-15 北京航空航天大学 一种基于流多处理器内核独占和预留的gpu服务质量保障方法

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5872963A (en) * 1997-02-18 1999-02-16 Silicon Graphics, Inc. Resumption of preempted non-privileged threads with no kernel intervention
US7310722B2 (en) * 2003-12-18 2007-12-18 Nvidia Corporation Across-thread out of order instruction dispatch in a multithreaded graphics processor
US8813080B2 (en) * 2007-06-28 2014-08-19 Intel Corporation System and method to optimize OS scheduling decisions for power savings based on temporal characteristics of the scheduled entity and system workload
US8589943B2 (en) * 2007-08-15 2013-11-19 Sony Computer Entertainment Inc. Multi-threaded processing with reduced context switching
US8656145B2 (en) * 2008-09-19 2014-02-18 Qualcomm Incorporated Methods and systems for allocating interrupts in a multithreaded processor

Also Published As

Publication number Publication date
TW201342228A (zh) 2013-10-16
TWI457828B (zh) 2014-10-21
CN103197917A (zh) 2013-07-10

Similar Documents

Publication Publication Date Title
US10552201B2 (en) Software-assisted instruction level execution preemption
DE102013022712B4 (de) Virtuelle Speicherstruktur für Coprozessoren, die Speicherallokationsbegrenzungen haben
DE102013200991A1 (de) Automatisches abhängige-Aufgabe-Anstoßen
DE102012220029A1 (de) Spekulative Ausführung und Zurücksetzen
DE102012222558B4 (de) Signalisieren, Ordnen und Ausführung von dynamisch erzeugten Aufgaben in einem Verarbeitungs-System
DE102013208554B4 (de) Verfahren und System zum Managen verschachtelter Ausführungsströme
DE102013202495A1 (de) Verfahren zur Durchführung von interaktivem Debugging auf nicht unterbrechbaren Graphikverarbeitungseinheiten
DE102012220267B4 (de) Rechenarbeitsverteilungs - Referenzzähler
DE102013209350B4 (de) Ressource-Management-Subsystem, welches Fairness und Ordnung einhält
DE102013208558A1 (de) Verfahren und System zur Verarbeitung verschachtelter Stream-Events
DE102012221502A1 (de) System und Verfahren zum Durchführen von gestalteter-Speicherzugriff-Operationen
US20130124838A1 (en) Instruction level execution preemption
DE102012222394A1 (de) Verfahren und Vorrichtung zum Sammelzwischenspeichern von Quelloperanden
DE102012212639A1 (de) Temporäre SIMT-Ausführungs-Optimierung
DE102013100179A1 (de) Verfahren und System zum Auflösen von Thread-Divergenzen
DE102013201178A1 (de) Steuern von Arbeitsverteilung für Verarbeitung von Tasks
DE102012222913A1 (de) Verfahren und Apparat zum Planen von Anweisungen unter Benutzung von Zuvor-Dekodieren-Daten
DE102013114072A1 (de) System und Verfahren zum Hardware-Scheduling von indexierten Barrieren
DE102012211670A1 (de) Simultanes Unterbreiten an eine Mehr-Produzenten-Queue mittels mehrerer Threads
DE102013200997A1 (de) Ein blockierungsfreies FIFO
DE102012222918A1 (de) Verfahren und Apparat zum Planen von Anweisungen ohne Anweisungs-Dekodieren
CN107111552B (zh) 用于版本控制的方法、版本控制器以及机器可读介质
US20130132711A1 (en) Compute thread array granularity execution preemption
DE102012220277A1 (de) Rechen-Aufgabe-Zustands-Einkapselung
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

R016 Response to examination communication