DE102012220267A1

DE102012220267A1 - Rechenarbeitsverteilungs - Referenzzähler

Info

Publication number: DE102012220267A1
Application number: DE102012220267A
Authority: DE
Inventors: Philip Alexander Cuadra; Karim M. Abdalla; Jerome F. Duluk jr.; Luke Durant; Gerald F. Luiz; Timothy John Purcell; Lacky V. Shah
Original assignee: Nvidia Corp
Current assignee: Nvidia Corp
Priority date: 2011-11-08
Filing date: 2012-11-07
Publication date: 2013-05-08
Anticipated expiration: 2032-11-08
Also published as: US20130117758A1; TWI560615B; US9507638B2; DE102012220267B4; TW201333829A; CN103176848A

Abstract

Eine Ausführungsform der vorliegenden Erfindung stellt eine Technik zum Verwalten der Zuteilung und des Freigebens von Ressourcen während einer Multithreaded-Programmausführung dar. Programmierbare Referenzzähler sind auf Werte initialisiert, die die Menge an Ressourcen zur Zuteilung für Aufgaben begrenzen, die denselben Referenzzähler teilen. Ressourcenparameter sind für jede Aufgabe spezifiziert, um die Menge an Ressourcen, die zum Verbrauch durch jedes Array von Ausführungsthreads zugeteilt sind, die gestartet sind, um die Aufgabe auszuführen, zu definieren. Die Ressourcenparameter spezifizieren auch das Verhalten des Arrays zum Erlangen und Freigeben von Ressourcen. Schließlich kann während der Ausführung jedes Threads in dem Array eine Exit-Anweisung konfiguriert werden, um das Freigeben der Ressourcen zu überschreiben, die dem Array zugeteilt waren. Die Ressourcen können dann zur Verwendung durch eine Kindaufgabe behalten werden, die während der Ausführung eines Threads erzeugt wird.

Description

Hintergrund der Erfindung
Gebiet der Erfindung
Die vorliegende Erfindung bezieht sich im Allgemeinen auf Programmausführung und insbesondere auf Architekturressourcenverwaltung für Programmausführung.
Beschreibung der verwandten Technik
Ausführung von Programmen erfordert üblicherweise Zuteilung von Verarbeitungs- und Speicherressourcen zur Verarbeitung von Daten und Speichern von Zwischenergebnissen und Ausgaben. Da die Architekturressourcen beschränkt sind, wird die Menge an Ressourcen, die jedem Programm zugeteilt wird, verfolgt, um sicherzustellen, dass die Ressourcen in einem Ressourcenpool nicht über-zugeteilt werden. Wenn ein Programm die Ausführung fertigstellt, werden die zugeteilten Ressourcen freigegeben und zu dem Ressourcenpool zurückgegeben.
Wenn Multithreaded-Programmausführung mit Kontextumschalten unterstützt wird, werden die Zustandsdaten, die für jeden Ausführungsthread aufrechterhalten werden, gespeichert, um ein Kontextumschalten durchzuführen. Der Speicher, der benötigt wird, um die Zustandsdaten zu speichern, ist eine zusätzliche Ressource, die auch zugeteilt werden muss, um sicherzustellen, dass die Zustandsdaten gespeichert werden können.
Dementsprechend ist, was in der Technik benötigt wird, ein System und Verfahren zum verbesserten Zuteilen und Freigeben von Ressourcen während einer Multithreaded-Ausführung.
Zusammenfassung der Erfindung
Ein System und Verfahren zum Verwalten der Zuteilung und dem Freigeben von Ressourcen während einer Multithreaded-Programmausführung initialisiert programmierbare Referenzzähler auf Werte, die die Menge an Ressourcen zur Zuteilung zu Verarbeitungsaufgaben beschränken, die denselben Referenzzähler teilen. Ressourcenparameter werden für jede Aufgabe spezifiziert, um die Menge an Architekturressourcen zu definieren, die zum Verbrauch durch jedes Array von Ausführungsthreads zugeteilt sind, das gestartet wird, um die Aufgabe auszuführen. Die Ressourcenparameter spezifizieren auch das Verhalten des Arrays zum Erlangen und Freigeben von Ressourcen. Schließlich kann während der Ausführung von jedem Thread in dem Array, wenn eine Kindaufgabe erzeugt wird, eine Ausgangsanweisung konfiguriert werden, um das Freigeben der Ressourcen zu überschreiben, die dem Array zugeteilt waren. Das Überschreiben stellt sicher, dass die Architekturressourcen zur Verwendung durch eine Fortsetzungsaufgabe beibehalten werden, die auch erzeugt wird.
Verschiedene Ausführungsformen eines Verfahrens der Erfindung zum Zuteilen und Freigeben von Architekturressourcen in einem Multithreaded-System weisen das Zuteilen der Architekturressourcen für ein Thread-Array, das eine Mehrzahl von Threads aufweist, um eine Verarbeitungsaufgabe auszuführen und Bestimmen durch jeden Thread in dem Thread-Array, während des Ausführens der Verarbeitungsaufgabe, auf, ob ein Freigeben der Architekturressourcen überschrieben werden wird, wenn das Thread-Array beendet. Die Architekturressourcen werden freigegeben, wenn das Thread-Array beendet und kein Thread in dem Array von Threads bestimmt, dass das Freigeben der Architekturressourcen nicht überschrieben werden würde. Die Architekturressourcen werden behalten, wenn das Thread-Array beendet und zumindest ein Thread in dem Thread-Array bestimmt hat, dass das Freigeben der Architekturressourcen überschrieben werden würde.
Verschiedene Ausführungsformen der Erfindung weisen ein Multithreaded-System auf, das konfiguriert ist, Architekturressourcen zuzuteilen und freizugeben. Das Multithreaded-System weist einen Speicher, ein allgemeines Verarbeitungscluster und eine Arbeitsverteilungseinheit auf. Der Speicher ist konfiguriert, um Programmanweisungen zu speichern, die zu einer Verarbeitungsaufgabe korrespondieren. Das allgemeine Verarbeitungscluster ist konfiguriert, um ein erstes Thread-Array zu verarbeiten, das eine Mehrzahl von Threads aufweist, um die Verarbeitungsaufgabe auszuführen, wobei, während der Ausführung der Verarbeitungsaufgabe, jeder Thread des ersten Thread-Arrays bestimmt, ob ein Freigeben der Architekturressourcen überschrieben werden wird, wenn das erste Thread-Array beendet. Die Arbeitsverteilungseinheit ist mit dem allgemeinen Verarbeitungscluster gekoppelt und konfiguriert, um die Architekturressourcen zu dem ersten Thread-Array zuzuteilen, die Architekturressourcen freizugeben, wenn das erste Thread-Array beendet und kein Thread in dem ersten Thread-Array bestimmt hat, dass das Freigeben der Architekturressourcen nicht überschrieben werden würde, und die Architekturressourcen beizubehalten, wenn das erste Thread-Array beendet und zumindest ein Thread in dem ersten Thread-Array bestimmt hat, dass das Freigeben der Architekturressourcen überschrieben werden würde.
Wenn eine Kindaufgabe erzeugt wurde, wird die Ausführung der Elternaufgabe ausgesetzt und die Fortsetzungssaufgabe wird erzeugt. Nachdem die Ausführung der Kindaufgabe vervollständigt ist, wird die Fortsetzungsaufgabe ausgeführt unter Verwendung der Architekturressourcen, die der Elternaufgabe zugeteilt sind. Nach dem Beenden gibt die Fortsetzungsaufgabe die Architekturressourcen frei, die ursprünglich der Elternaufgabe zugeteilt waren. Die Architekturressourcen werden nicht über-zugeteilt und die Quantität der Ressourcen, die zur Zuteilung verfügbar ist, kann durch die Ressourcenparameter verwaltet werden.
Kurze Beschreibung der Zeichnungen
Damit die Art, in der die oben genannten Merkmale der vorliegenden Erfindung im Detail verstanden werden können, kann eine genauere Beschreibung der Erfindung, die oben kurz zusammengefasst ist, durch Bezugnahme auf Ausführungsformen, von denen manche in den angehängten Zeichnungen dargestellt sind, erhalten werden. Es sollte jedoch beachtet werden, dass die angehängten Figuren nur übliche Ausführungsformen dieser Erfindung darstellen und daher nicht dazu gedacht sind, ihren Schutzumfang zu beschränken, da die Erfindung auch andere gleicheffektive Ausführungsformen erlauben kann.
1 ist ein Blockdiagramm, das ein Computersystem darstellt, das konfiguriert ist, einen oder mehrere Aspekte der Erfindung zu implementieren;
2 ist ein Blockdiagramm eines parallelen Verarbeitungsuntersystems für das Computersystem von 1 gemäß einer Ausführungsform der Erfindung;
3A ist ein Blockdiagramm der Aufgaben-/Arbeitseinheit von 2 gemäß einer Ausführungsform der Erfindung;
3B ist ein Blockdiagramm eines allgemeinen Verarbeitungsclusters innerhalb einer der Parallelverarbeitungseinheiten von 2 gemäß einer Ausführungsform der vorliegenden Erfindung;
4A stellt die Referenzzähler von 3A und die ressourcenbezogenen Parameter einer Scheduler-Aufgabe gemäß einer Ausführungsform der Erfindung dar;
4B stellt die Referenzzähler von 3A und ressourcenbezogene Parameter von unterschiedlichen Aufgaben gemäß einer Ausführungsform der Erfindung dar;
5A stellt ein Verfahren zum Verwalten von Architekturressourcen dar, wenn Aufgaben gestartet sind, gemäß einer Ausführungsform der Erfindung; und
5B stellt ein Verfahren zum Verwalten von Architekturressourcen dar, wenn die Ausführung beendet, gemäß einer Ausführungsform der Erfindung.
Detaillierte Beschreibung
In der folgenden Beschreibung werden verschiedene spezifische Details dargestellt, um ein gründlicheres Verständnis der vorliegenden Erfindung bereitzustellen. Jedoch wird dem Fachmann ersichtlich sein, dass die vorliegende Erfindung ohne ein oder mehrere dieser speziellen Details ausgeführt werden kann. In anderen Beispielen wurden gut bekannte Merkmale nicht beschrieben, um ein Verschleiern der vorliegenden Erfindung zu vermeiden.
Systemüberblick
1 ist ein Blockdiagramm, das ein Computersystem 100 darstellt, das konfiguriert ist, um einen oder mehrere Aspekte der vorliegenden Erfindung zu implementieren. Das Computersystem 100 weist eine Zentralverarbeitungseinheit (CPU) 102 und einen Systemspeicher 104 auf, die über einen Verbindungspfad kommunizieren, der eine Speicherbridge 105 aufweisen kann. Die Speicherbridge 105, die beispielsweise ein Northbridge-Chip sein kann, ist über einen Bus oder einen anderen Kommunikationspfad 106 (zum Beispiel ein HyperTransport-Link) mit einer I/O-(Input/Output)Bridge 107 verbunden. Die I/O-Bridge 107, die beispielsweise ein Southbridge-Chip sein kann, empfängt eine Benutzereingabe von einer oder mehreren Benutzereingabevorrichtungen 108 (zum Beispiel Tastatur, Maus) und leitet die Eingabe an die CPU 102 über den Pfad 106 und die Speicher-Bridge 105 weiter. Ein paralleles Verarbeitungsuntersystem 112 ist mit der Speicher-Bridge 105 über einen Bus oder einen anderen Kommunikationspfad 113 (zum Beispiel einen PCI-Express, Accelerated Graphics Port oder HyperTransport-Link) gekoppelt; in einer Ausführungsform ist das parallele Verarbeitungsuntersystem 112 ein Grafikuntersystem, das Pixel zu einer Anzeigevorrichtung 110 (zum Beispiel einem herkömmlichen CRT- oder LCD-basierten Monitor) liefert. Eine Systemfestplatte 114 ist auch mit der I/O-Bridge 107 verbunden. Ein Switch 116 stellt Verbindungen zwischen der I/O-Bridge 107 und anderen Komponenten wie einem Netzwerkadapter 118 und verschiedenen Erweiterungskarten 120 und 121 bereit. Andere Komponenten (nicht explizit gezeigt), einschließlich USB oder anderen Schnittstellenverbindungen, CD-Laufwerken, DVD-Laufwerken, Filmaufnahmevorrichtungen und ähnliches, können auch mit der I/O-Bridge 107 verbunden werden. Kommunikationspfade, die die verschiedenen Komponenten in 1 verbinden, können unter Verwendung irgendwelcher geeigneter Protokolle implementiert werden, wie PCI (Peripheral Component Interconnect), PCI-Express (PCI-E), AGP (Accelerated Graphics Port), HyperTransport- oder irgendwelchen anderen Bus- oder Punkt-zu-Punkt-Kommunikationsprotokoll(en), und Verbindungen zwischen unterschiedlichen Vorrichtungen können unterschiedliche Protokolle verwenden, wie es in der Technik bekannt ist.
In einer Ausführungsform integriert das parallele Verarbeitungsuntersystem 112 Schaltkreise, die zur Grafik- und Videoverarbeitung optimiert sind, einschließlich beispielsweise Videoausgabeschaltkreise, und bildet eine Grafikverarbeitungseinheit (GPU). In einer anderen Ausführungsform integriert das parallele Verarbeitungsuntersystem 112 Schaltkreise, die für allgemeine Verarbeitung optimiert sind, während die zugrunde liegende Rechnerarchitektur bewahrt wird, wie hierin detaillierter beschrieben ist. In wiederum einer anderen Ausführungsform kann das parallele Verarbeitungsuntersystem 112 mit einem oder mehreren anderen Systemelementen integriert werden, wie der Speicher-Bridge 105, CPU 102 und I/O-Bridge 107, um ein System auf dem Chip (SoC) zu bilden.
Es wird anerkannt werden, dass das hierin gezeigte System beispielhaft ist, und dass Variationen und Modifikationen möglich sind. Die Verbindungstopologie, einschließlich der Anzahl und Anordnung von Bridges, der Anzahl von CPUs 102 und der Anzahl von Parallelverarbeitungsuntersystemen 112, kann wie gewünscht modifiziert werden. Beispielsweise ist in manchen Ausführungsformen der Systemspeicher 104 mit der CPU 102 direkt statt über eine Bridge verbunden, und andere Vorrichtungen kommunizieren mit dem Systemspeicher 104 über die Speicher-Bridge 105 und CPU 102. In anderen alternativen Topologien ist das parallele Verarbeitungsuntersystem 112 mit der I/O-Bridge 107 oder direkt mit der CPU 102, statt mit der Speicher-Bridge 105 verbunden. In wiederum anderen Ausführungsformen könnten die I/O-Bridge 107 und die Speicher-Bridge 105 in einen oder mehrere Chips integriert sein. Große Ausführungsformen können zwei oder mehr CPUs 102 und zwei oder mehr Parallelverarbeitungsuntersysteme 112 aufweisen. Die bestimmten Komponenten, die hierin gezeigt sind, sind optional; beispielsweise kann irgendeine Anzahl von Erweiterungskarten oder peripheren Vorrichtungen unterstützt werden. In manchen Ausführungsformen ist der Switch 116 entfernt und der Netzwerkadapter 118 und Erweiterungskarten 120, 121 verbinden direkt mit der I/O-Bridge 107.
2 stellt ein paralleles Verarbeitungsuntersystem 112 gemäß einer Ausführungsform der vorliegenden Erfindung dar. Wie gezeigt weist das parallele Verarbeitungsuntersystem 112 eine oder mehrere parallele Verarbeitungseinheiten (PPUs) 202 auf, von denen jede mit einem lokalen parallelen Verarbeitungs(PP)-Speicher 204 gekoppelt ist. Im Allgemeinen weist ein paralleles Verarbeitungsuntersystem eine Anzahl U von PPUs auf, wobei U ≥ 1. (Hierin werden mehrere Instanzen von ähnlichen Objekten mit Bezugszeichen bezeichnet, die das Objekt identifizieren, und eingeklammerten Zahlen, die die Instanz identifizieren, wo benötigt.) PPUs 202 und parallele Verarbeitungsspeicher 204 können unter Verwendung von einer oder mehreren integrierten Schaltungsvorrichtungen implementiert werden, wie programmierbaren Prozessoren, anwendungsspezifischen integrierten Schaltungen (ASICs) oder Speichervorrichtungen oder in irgendeiner anderen technisch möglichen Weise.
Wiederum bezugnehmend auf 1 sind in manchen Ausführungsformen manche oder alle der PPUs 202 in dem parallelen Verarbeitungsuntersystem 112 Grafikprozessoren mit Rendering-Pipelines, die konfiguriert sein können, um verschiedene Operationen durchzuführen, die mit dem Erzeugen von Pixeldaten aus Grafikdaten, die durch die CPU 102 und/oder den Systemspeicher 104 über die Speicher-Bridge 105 und den Bus 113 zugeführt werden, verbunden sind, interagierend mit dem lokalen parallelen Verarbeitungsspeicher 204 (der als ein Grafikspeicher einschließlich zum Beispiel einem herkömmlichen Frame-Puffer verwendet werden kann), um Pixeldaten zu speichern und zu aktualisieren, Pixeldaten zu der Anzeigevorrichtung 110 zu liefern, und ähnliches. In manchen Ausführungsformen kann das parallele Verarbeitungsuntersystem 112 eine oder mehrere PPUs 202 aufweisen, die als Grafikprozessoren arbeiten, und eine oder mehrere andere PPUs 202, die für allgemeine Berechnungen verwendet werden. Die PPUs können identisch oder unterschiedlich sein, und jede PPU kann ihre eigene zugehörige parallele Verarbeitungsspeichervorrichtung(en) oder keine zugehörige parallele Verarbeitungsspeichervorrichtung(en) aufweisen. Eine oder mehrere PPUs 202 können Daten an die Anzeigevorrichtung 110 ausgeben oder jede PPU 202 kann Daten zu einer oder mehreren Anzeigevorrichtungen 110 ausgeben.
Im Betrieb ist die CPU 102 der Master-Prozessor des Computersystems 100, der die Vorgänge von anderen Systemkomponenten steuert und koordiniert. Insbesondere gibt die CPU 102 Befehle aus, die die Operation von PPUs 202 steuern. In manchen Ausführungsformen schreibt die CPU 102 einen Strom von Befehlen für jede PPU 202 auf eine Datenstruktur (weder in 1 noch 2 explizit gezeigt), der in dem Systemspeicher 104, dem parallelen Verarbeitungsspeicher 204 oder irgendeinem anderen Speicherort, der sowohl für die CPU 102 als auch die PPU 202 zugreifbar ist, angeordnet sein kann. Ein Zeiger zu jeder Datenstruktur wird in einen Push-Puffer geschrieben, um Verarbeitung des Stroms von Befehlen in der Datenstruktur zu initiieren. Die PPU 202 liest Befehlsströme von einem oder mehreren Push-Puffern und führt dann die Befehle asynchron relativ zu der Operation der CPU 102 aus. Ausführungsprioritäten können für jeden Push-Puffer spezifiziert werden, um Ablaufplanung zu unterschiedlichen Push-Puffern zu steuern.
Zurückbeziehend auf 2B weist jede PPU 202 eine I/O(Input/Output)-Einheit 205 auf, die mit dem Rest des Computersystems 100 über den Kommunikationspfad 113 kommuniziert, der mit der Speicher-Bridge 105 (oder in einer alternativen Ausführungsform direkt mit der CPU 102) verbindet. Die Verbindung der PPU 202 mit dem Rest des Computersystems 100 kann auch variiert werden. In manchen Ausführungsformen ist das parallele Verarbeitungsuntersystem 112 als eine Erweiterungskarte implementiert, die in einen Erweiterungsslot des Computersystems 100 eingeführt werden kann. In anderen Ausführungsformen kann eine PPU 202 auf einem einzelnen Chip mit einer Bus-Bridge, wie der Speicher-Bridge 105 oder der I/O-Bridge 107, integriert sein. In wiederum anderen Ausführungsformen können manche oder alle Elemente der PPU 202 auf einem einzelnen Chip mit der CPU 102 integriert sein.
In einer Ausführungsform ist der Kommunikationspfad 113 ein PCI-Express-Link, in dem zugehörige Spuren zu jeder PPU 202 zugeordnet sind, wie es in der Technik bekannt ist. Andere Kommunikationspfade können auch verwendet werden. Eine I/O-Einheit 205 erzeugt Pakete (oder andere Signale) zur Übertragung auf dem Kommunikationspfad 113 und empfängt auch alle eingehenden Pakete (oder andere Signale) von dem Kommunikationspfad 113, wobei sie die eingehenden Pakete zu geeigneten Komponenten der PPU 202 leitet. Beispielsweise können Befehle, die sich auf Verarbeitungsaufgaben beziehen, zu einer Host-Schnittstelle 206 geleitet werden, während Befehle, die sich auf Speicheroperationen (zum Beispiel Lesen von oder Schreiben auf den parallelen Verarbeitungsspeicher 204) beziehen, zu einer Speicherkreuzschieneneinheit 210 geleitet werden können. Die Host-Schnittstelle 206 liest jeden Push-Puffer und gibt den Befehlsstrom, der in dem Push-Puffer gespeichert ist, zu einem Frontend 212 aus.
Jede PPU 202 implementiert vorteilhafter Weise eine hochparallele Verarbeitungsarchitektur. Wie im Detail gezeigt, weist die PPU 202(0) ein Verarbeitungs-Cluster-Array 230 auf, das eine Anzahl C von allgemeinen Verarbeitungs-Clustern (general processing cluster, GPCs) 208 aufweist, wobei C ≥ 1. Jede GPC 208 ist fähig, eine große Anzahl (zum Beispiel Hunderte oder Tausende) von Threads gleichzeitig auszuführen, wobei jeder Thread eine Instanz eines Programms ist. In verschiedenen Anwendungen können unterschiedliche GPCs 208 zum Verarbeiten von unterschiedlichen Arten von Programmen oder zum Durchführen von unterschiedlichen Arten von Berechnungen zugeteilt sein. Die Zuteilung von GPCs 208 kann in Abhängigkeit von der Arbeitslast, die für jede Art von Programm oder Berechnung entsteht, variieren.
GPCs 208 empfangen Verarbeitungsaufgaben, die auszuführen sind, von einer Arbeitsverteilungseinheit innerhalb einer Aufgaben-/Arbeitseinheit 207. Die Arbeitsverteilungseinheit empfängt Zeiger, um Verarbeitungsaufgaben zu berechnen, die als Aufgaben-Metadaten (TMD) codiert und in dem Speicher gespeichert sind. Die Aufgabenzeiger auf TMDs sind in dem Befehlsstrom enthalten, der als ein Push-Puffer gespeichert ist und durch die Frontend-Einheit 212 von der Host-Schnittstelle 206 empfangen werden. Verarbeitungsaufgaben, die als TMDs codiert sein können, weisen Indizes von zu verarbeitenden Daten auf, sowie Zustandsparameter und Befehle, die definieren, wie die Daten zu verarbeiten sind (zum Beispiel welches Programm auszuführen ist). Die Aufgaben-/Arbeitseinheit 207 empfängt Aufgaben von dem Frontend 212 stellt sicher, dass GPCs 208 auf einen gültigen Zustand konfiguriert sind, bevor die Verarbeitung, die durch die Befehlspuffer spezifiziert ist, initiiert wird. Eine Priorität kann für jede TMD spezifiziert sein, die verwendet wird, um Ausführung der Verarbeitungsaufgabe zu planen. Verarbeitungsaufgaben können auch von dem Verarbeitungsclusterarray 230 empfangen werden. Optional kann die TMD einen Parameter aufweisen, der steuert, ob die TMD zu dem Beginn oder dem Ende der verlinkten Liste hinzugefügt wird, wodurch ein anderer Level der Steuerung über die Priorität hinzugefügt wird.
Speicherschnittstelle 214 weist eine Anzahl D von Speicherpartitionseinheiten 215 auf, die jede direkt mit einem Teilbereich des parallelen Verarbeitungsspeichers 204 gekoppelt ist, wobei D ≥ 1. Wie gezeigt, gleicht die Anzahl der Partitionseinheiten 215 im Allgemeinen der Anzahl von DRAM 220. In anderen Ausführungsformen mag die Anzahl der Partitionseinheiten 215 nicht der Anzahl von Speichervorrichtungen gleichen. Der Fachmann wird anerkennen, dass DRAM 220 mit anderen geeigneten Speichervorrichtungen ersetzt werden kann und von allgemeinem herkömmlichen Design sein kann. Eine detaillierte Beschreibung wird daher weggelassen. Render-Ziele, wie Bildpuffer oder Texturabbildungen können über DRAMs 220 hinweg gespeichert werden, wobei es Partitionseinheiten 215 erlaubt wird, Teilbereiche von jedem Render-Ziel parallel zu schreiben, um effizient die verfügbare Bandbreite des parallelen Verarbeitungsspeichers 204 zu nutzen.
Irgendeine der GPCs 208 kann Daten verarbeiten, die auf irgendeinen der DRAMs 220 innerhalb des parallelen Verarbeitungsspeichers 204 zu schreiben sind. Die Kreuzschieneneinheit 210 ist konfiguriert, um die Ausgabe von jeder GPC 208 zu dem Eingang von irgendeiner Partitionseinheit 215 oder zu einer anderen GPC 208 zur weiteren Verarbeitung zu leiten. GPCs 208 kommunizieren mit der Speicherschnittstelle 214 über die Kreuzschieneneinheit 210, um von verschieden externen Speichervorrichtungen zu lesen oder auf sie zu schreiben. In einer Ausführungsform hat die Kreuzschieneneinheit 210 eine Verbindung zu der Speicherschnittstelle 214, um mit der I/O-Einheit 205 zu kommunizieren, sowie eine Verbindung zu dem lokalen parallelen Verarbeitungsspeicher 204, wodurch die Verarbeitungskerne innerhalb der unterschiedlichen GPCs 208 in die Lage versetzt werden, mit dem Systemspeicher 104 oder einem anderen Speicher, der nicht lokal zu der PPU 202 ist, zu kommunizieren. In der Ausführungsform gezeigt in 2 ist die Kreuzschieneneinheit 210 direkt mit der I/O-Einheit verbunden. Die Kreuzschieneneinheit 210 kann virtuelle Kanäle verwenden, um Verkehrsströme zwischen den GPCs 208 und den Partitionseinheiten 215 zu trennen.
Wiederum können die GPCs 208 programmiert werden, um Verarbeitungsaufgaben, die sich auf eine weite Vielzahl von Anwendungen beziehen, auszuführen, einschließlich aber nicht beschränkt auf lineare und nicht-lineare Datentransformationen, Filtern von Video- und/oder Audiodaten, Modellierungsoperationen (zum Beispiel Anwenden von Gesetzen der Physik, um Position, Geschwindigkeit und andere Attribute von Objekten zu bestimmen), Bildrenderoperationen (zum Beispiel Tesselationsschattierer-, Vertexschattierer-, Geometrieschattierer- und/oder Pixelschattiererprogramme), usw.. GPUs 202 können Daten von dem Systemspeicher 104 und/oder lokalen parallelen Bearbeitungsspeichern 204 in einen internen (On-Chip-)Speicher übertragen, die Daten verarbeiten und Ergebnisdaten zurück auf den Systemspeicher 104 und/oder lokale parallele Verarbeitungsspeicher 204 schreiben, wobei auf solche Daten durch andere Systemkomponenten, einschließlich der CPU 102 oder einem anderen parallelen Verarbeitungsuntersystem 112 zugegriffen werden kann.
Eine PPU 202 kann mit irgendeiner Menge an lokalen parallelen Verarbeitungsspeicher 204 bereitgestellt werden, einschließlich nicht lokalem Speicher, und kann lokalen Speicher und Systemspeicher in irgendeiner Kombination verwenden. Beispielsweise kann eine PPU 202 ein Grafikprozessor in einer einheitlichen Speicherarchitektur(UMA)-Ausführungsform sein. In solchen Ausführungsformen würde geringer oder kein zugehöriger Grafik-(paralleler Verarbeitungs-)Speicher bereitgestellt werden und die PPU 202 würde Systemspeicher exklusiv oder beinahe exklusiv verwenden. In UMA-Ausführungsformen kann eine PPU 202 in einen Bridge-Chip oder Prozessor-Chip integriert sein oder kann als ein diskreter Chip mit einem Hochgeschwindigkeitslink (z. B. PCI-Express) bereitgestellt werden, der die PPU 202 mit dem Systemspeicher über einen Bridge-Chip oder andere Kommunikationsmittel verbindet.
Wie oben erwähnt, kann irgendeine Anzahl von PPUs 202 in einem parallelen Verarbeitungsuntersystem 112 enthalten sein. Beispielsweise können mehrere PPUs 202 auf einer einzelnen Erweiterungskarte bereitgestellt werden oder mehrere Erweiterungskarten können mit dem Kommunikationspfad 113 verbunden sein, oder eine oder mehrere PPUs 202 können in einem Bridge-Chip integriert sein. PPUs 202 in einem Multi-PPU-System können identisch oder unterschiedlich zueinander sein. Beispielsweise können unterschiedliche PPUs 202 eine unterschiedliche Anzahl von Verarbeitungskernen, unterschiedliche Mengen an lokalem parallelem Verarbeitungsspeicher usw. haben. Wo mehrere PPUs 202 vorhanden sind, können diese PPUs parallel arbeiten, um Daten bei einem höheren Durchsatz zu verarbeiten als es mit einer einzelnen PPU 202 möglich ist. Systeme, die eine oder mehrere PPUs 202 integrieren, können in einer Vielzahl von Konfigurationen und Formfaktoren implementiert sein, einschließlich Desktop, Laptop oder Handgerätarbeitsplatzrechner, Server, Workstations, Spielkonsolen, eingebettete Systeme und ähnliches.
Multiple-Gleichzeitige-Aufgaben-Planung
Mehrere Verarbeitungsaufgaben können gleichzeitig auf den GPCs 208 ausgeführt werden und eine Verarbeitungsaufgabe kann eine oder mehrere „Kind”-Verarbeitungsaufgabert während der Ausführung erzeugen. Die Aufgaben-/Arbeitseinheit 207 empfängt die Aufgaben und plant die Verarbeitungsaufgaben und Kindverarbeitungsaufgaben zur Ausführung durch die GPCs 208 dynamisch.
3A ist ein Blockdiagramm der Aufgaben-/Arbeitseinheit 207 von 2 gemäß einer Ausführungsform der vorliegenden Erfindung. Die Aufgaben-/Arbeitseinheit 207 weist eine Aufgabenverwaltungseinheit 300 und die Arbeitsverteilungseinheit 340 auf. Die Aufgabenverwaltungseinheit 300 organisiert Aufgaben, die zu planen sind, basierend auf Ausführungsprioritätsleveln. Für jeden Prioritätslevel speichert die Aufgabenverwaltungseinheit 300 eine Liste von Aufgabenzeigern auf die TMDs 322 korrespondierend zu den Aufgaben in der Scheduler-Tabelle 321, wo die Liste mit einer verlinkten Liste implementiert werden kann, und hierin später wird eine verlinkte Liste angenommen. Die TMDs 322 sind Metadaten, die eine Aufgabe darstellen, wie Konfigurationsdaten und Zustandsinformationen, die benötigt werden, um die Aufgabe auszuführen. Die TMDs 322 können in dem PP-Speicher 204 oder Systemspeicher 104 gespeichert werden. Die Rate, zu der die Aufgabenverwaltungseinheit 300 Aufgaben akzeptiert und die Aufgaben in der Scheduler-Tabelle 321 speichert, ist von der Rate entkoppelt, zu der die Aufgabenverwaltungseinheit 300 Aufgaben zur Ausführung plant, was ermöglicht, dass die Aufgabenverwaltungseinheit 300 Aufgaben basierend auf Prioritätsinformationen oder unter Verwendung anderer Techniken plant.
Die Arbeitsverteilungseinheit 340 weist eine Aufgabentabelle 345 mit Slots auf, die jeder durch die TMD 322 für eine Aufgabe, die ausgeführt wird, besetzt werden können. Die Aufgabenverwaltungseinheit 300 kann Aufgaben zur Ausführung planen, wenn es einen freien Slot in der Aufgabentabelle 345 gibt. Wenn es keinen freien Slot gibt, kann eine Aufgabe höherer Priorität, die keinen Slot besetzt, eine Aufgabe niedrigerer Priorität zwangsräumen, die einen Slot besetzt. Wenn eine Aufgabe zwangsgeräumt wird, wird die Aufgabe gestoppt, und wenn die Ausführung der Aufgabe nicht vervollständigt ist, wird die Aufgabe zu einer gelinkten Liste in der Scheduler-Tabelle 321 hinzugefügt. Wenn eine Kindverarbeitungsaufgabe erzeugt wird, wird die Kindverarbeitungsaufgabe zu einer gelinkten Liste in der Scheduler-Tabelle 321 hinzugefügt. Eine Aufgabe wird von einem Slot entfernt, wenn die Aufgabe zwangsgeräumt wird.
Die Arbeitsverteilungseinheit 340 weist auch Rechenarbeitsverteilungs-(CWD)Referenzzähler 350 auf, die verwendet werden, um die verfügbaren Ressourcen nachzuverfolgen, die benötigt werden, um eine Aufgabe zu verarbeiten. Die Referenzzähler werden initialisiert, um die Maximalmenge an Ressourcen zu beschränken, die verbraucht werden kann. Da Aufgaben durch die Arbeitsverteilungseinheit 340 zur Ausführung durch die GPCs 208 gestartet werden, werden die Referenzzähler aktualisiert, um die Menge an Ressourcen anzugeben, die verfügbar sind, nachdem die Aufgabe gestartet wurde, wodurch der Teil der Ressource, der durch die Aufgabe verbraucht wird, verrechnet wird. Die Ressourcen können Speicher, Verarbeitungsressourcen, Anzahl von Threads oder irgendeine andere quantifizierbare Architekturressource sein, die durch eine Aufgabe verbraucht werden kann. Jede TMD 322 spezifiziert einen bestimmten Referenzzähler und einen Wert, der die Menge an Ressourcen angibt, die durch die Aufgabe benötigt werden (oder benötigt werden können). Bevor die Aufgabe gestartet wird, überprüft die Arbeitsverteilungseinheit 340, dass der Wert nicht größer als der Referenzzähler ist, der durch die TMD 322 spezifiziert ist. Wenn eine Aufgabe gestartet wird, aktualisiert die Arbeitsverteilungseinheit 340 den spezifizierten Referenzzähler, so dass der Wert von Ressourcen, die der Aufgabe zugeteilt sind, nicht verfügbar ist. Da Aufgaben fertiggestellt werden, werden die Ressourcen, die der Aufgabe zugeteilt sind, freigegeben und die Referenzzähler 350 werden entsprechend aktualisiert. Verwenden und Aktualisieren der Referenzzähler 350 ist detaillierter im Zusammenhang mit 4A, 4B, 5A und 5B beschrieben. In einer Ausführungsform ist eine Mehrzahl von Referenzzählern in jeder TMD 322, zusammen mit assoziierten Zählerwerten, spezifiziert, wodurch zwei oder mehrere Architekturressourcen verrechnet werden.
Aufgabenverarbeitungs-Überblick
3B ist ein Blockdiagramm einer GPC 208 innerhalb einer der PPUs 202 von 2 gemäß einer Ausführungsform der vorliegenden Erfindung. Jede GPC 208 kann konfiguriert sein, um eine große Anzahl von Threads parallel auszuführen, wobei der Begriff „Thread” sich auf eine Instanz eines bestimmten Programms bezieht, das eine bestimmte Menge an Eingabedaten ausführt. In manchen Ausführungsformen werden Einzel-Anweisungen-mehrere-Daten(SIMD)-Anweisungserteilungstechniken verwendet, um eine parallele Ausführung einer großen Anzahl von Threads zu unterstützen, ohne mehrere unabhängige Anweisungseinheiten bereitzustellen. In anderen Ausführungsformen werden Einzelne-Anweisung-mehrere-Thread(SIMT)-Techniken verwendet, um eine parallele Ausführung einer großen Anzahl von im Allgemeinen synchronisierten Threads zu unterstützen, wobei eine gemeinsame Anweisungseinheit verwendet wird, die konfiguriert ist, Anweisungen zu einer Menge von Verarbeitungsfunktionseinheiten innerhalb von jeder der GPCs 208 zu erteilen. Anders als ein SIMD-Ausführungssystem, wo alle Verarbeitungsfunktionseinheiten üblicherweise identische Anweisungen ausführen, ermöglicht eine SIMT-Ausführung unterschiedliche Threads, um leichter divergenten Ausführungspfaden durch ein gegebenes Thread-Programm zu folgen. Der Fachmann wird verstehen, dass ein SIMD-Verarbeitungssystem eine funktionelle Untermenge eines SIMT-Verarbeitungssystems darstellt.
Der Betrieb der GPC 208 wird vorteilhafter Weise durch einen Pipeline-Manager 305 gesteuert, der Verarbeitungsaufgaben zu Stream-Multiprozessoren (SMs) 310 verteilt. Der Pipeline-Manager 305 kann auch konfiguriert sein, um eine Arbeitsverteilungskreuzschiene 330 zu steuern, indem Ziele für verarbeitete Datenausgaben durch die SMs 310 spezifiziert werden.
In einer Ausführungsform weist jede GPC 208 eine Anzahl M von SMs 310 auf, wobei M ≥ 1, wobei jede SM 310 konfiguriert ist, um eine oder mehrere Threadgruppen zu verarbeiten. Auch weist jede SM 310 vorteilhafterweise einen identischen Satz an funktionellen Ausführungseinheiten aus, die in eine Pipeline gestellt werden können, was erlaubt, dass eine neue Anweisung ausgegeben wird, bevor eine vorherige Anweisung geendet hat, wie es in der Technik bekannt ist. Irgendeine Kombination von funktionellen Ausführungseinheiten kann bereitgestellt werden. In einer Ausführungsform unterstützen die funktionellen Einheiten eine Vielzahl von Operationen, einschließlich ganzzahligen und fließkommaarithmetischen (beispielsweise Addition und Multiplikation), Vergleichsoperationen, Booleschen Operationen (AND, OR, XOR), Bitverschiebung, und Berechnung von zahlreichen algebraischen Funktionen (beispielsweise planare Interpolation, trigonometrische, exponentielle und logarithmische Funktionen, etc.); und dieselbe funktionelle Einheitshardware kann unterstützt werden, um unterschiedliche Operationen durchzuführen.
Die Reihe an Anweisungen, die zu einer bestimmten GPC 208 übermittelt werden, stellt einen Thread dar, wie vorher hierin definiert, und die Sammlung einer bestimmten Anzahl von gleichzeitig ausführenden Threads über die parallelen Verarbeitungsfunktionseinheiten (nicht gezeigt) innerhalb einer SM 310 wird hierin als eine „Threadgruppe” bezeichnet. Wie hierin verwendet, bezieht sich eine „Threadgruppe” auf eine Gruppe von Threads, die gleichzeitig dasselbe Programm auf unterschiedlichen Eingangsdaten ausführen, wobei ein Thread der Gruppe zu einer unterschiedlichen Verarbeitungsfunktionseinheit innerhalb einer SM 310 zugeordnet ist. Eine Threadgruppe kann weniger Threads als die Anzahl von Verarbeitungsfunktionseinheiten innerhalb der SM 310 aufweisen, in welchem Fall manche Verarbeitungsfunktionseinheiten während Zyklen inaktiv sein werden, wenn diese Threadgruppe verarbeitet wird. Eine Threadgruppe kann auch mehr Threads als die Anzahl von Verarbeitungsfunktionseinheiten innerhalb der SM 310 aufweisen, in welchem Fall die Verarbeitung über aufeinanderfolgende Taktzyklen stattfinden wird. Da jede SM 310 bis zu G Threadgruppen gleichzeitig unterstützen kann, folgt, dass bis zu G × M Threadgruppen in der GPC 208 zu irgendeiner gegebenen Zeit ausgeführt werden können.
Zusätzlich kann eine Mehrzahl von verwandten Threadgruppen aktiv (in unterschiedlichen Phasen der Ausführung) zu derselben Zeit innerhalb einer SM 310 sein. Diese Sammlung von Threadgruppen wird hierin als ein „kooperatives Thread-Array” („CTA”) oder „Thread-Array” bezeichnet. Die Größe einer bestimmten CTA ist gleich m·k, wobei k die Anzahl von gleichzeitig ausführenden Threads in einer Threadgruppe ist und üblicherweise ein ganzzahliges Mehrfaches der Anzahl von parallelen Verarbeitungsfunktionseinheiten innerhalb der SM 310 ist und m die Anzahl von Threadgruppen ist, die simultan innerhalb der SM 310 aktiv sind. Die Größe einer CTA wird im Allgemeinen durch den Programmierer und die Menge an Hardware-Ressourcen bestimmt, wie Speicher oder Register, die für die CTA verfügbar sind.
Jede SM 310 enthält einen Level 1(L1)-Cache oder verwendet Raum in einem korrespondierenden L1-Cache außerhalb der SM 310, der verwendet wird, um Lade- und Speicheroperationen durchzuführen. Jede SM 310 hat auch Zugriff auf Level 2(L2)-Caches, die zwischen allen GPCs 208 geteilt werden und verwendet werden können, um Daten zwischen Threads zu übertragen. Schließlich haben SMs 310 auch Zugriff auf Off-Chip „globalen” Speicher, der zum Beispiel Parallelverarbeitungsspeicher 204 und/oder Systemspeicher 104 aufweisen kann. Es sollte verstanden werden, dass irgendein Speicher extern zu der PPU 202 als globaler Speicher verwendet werden kann. Zusätzlich kann ein Level-Eins-Punkt-Fünf(L1.5)-Cache 335 innerhalb der GPC 208 enthalten sein, der konfiguriert ist, um Daten, die von dem Speicher über die Speicherschnittstelle 214 angefordert durch die SM 310 abgerufen wurden, zu empfangen und zu halten, einschließlich Anweisungen, einheitlichen Daten, und konstanten Daten, und die angeforderten Daten zu der SM 310 bereitzustellen. Ausführungsformen, die mehrere SMs 310 in der GPC 208 haben, teilen vorteilhafterweise gemeinsame Anweisungen und Daten, die in den L1.5-Cache 335 zwischengespeichert sind.
Jede GPC 208 kann eine Speicher-Verwaltungs-Einheit (MMU) 328 aufweisen, die konfiguriert ist, um virtuelle Adressen in physikalische Adressen abzubilden. In anderen Ausführungsformen können MMU(s) 328 innerhalb der Speicherschnittstelle 214 liegen. Die MMU 328 weist eine Menge von Seitentabelleneinträgen (PTEs) auf, die verwendet werden, um eine virtuelle Adresse auf eine physikalische Adresse einer Kachel und optional eines Cache-Zeilenindexes abzubilden. Die MMU 328 kann Adress-Translations-Lookaside-Puffer (TLB) oder Caches aufweisen, die innerhalb des Mikroprozessor SM 310 oder dem L1 Cache oder der GPC 208 hegen. Die physikalische Adresse wird verarbeitet, um Oberflächendaten-Zugriffsörtlichkeit zu verteilen, um effizientes Anfrage-Verzahnen zwischen Partitionseinheiten zu ermöglichen. Der Cache-Zeilenindex kann verwendet werden, um zu bestimmen, ob oder ob nicht eine Anfrage für eine Cache-Zeile ein Treffer oder ein Fehlschlag ist.
In Grafik- und Berechnungsanwendungen kann eine GPC 208 konfiguriert sein, so dass jede SM 310 mit einer Textureinheit 315 gekoppelt ist, um Texturabbildungsoperationen durchzuführen, zum Beispiel Bestimmen von Texturabtastpositionen, Lesen von Texturdaten und Filtern der Texturdaten. Texturdaten werden von einem internen Textur-L1-Cache (nicht gezeigt) oder in manchen Ausführungsformen von dem L1-Cahce innerhalb des SM 310 gelesen und von einem L2-Cache, parallelen Verarbeitungsspeicher 204 oder Systemspeicher 104, wie benötigt, abgerufen. Jede SM 310 gibt verarbeitete Aufgaben an die Arbeitsverteilungskreuzschiene 330 aus, um die verarbeitete Aufgabe zu einer anderen GPC 208 zur weiteren Verarbeitung bereitzustellen oder die verarbeitete Aufgabe in einem L2-Cache, parallelen Verarbeitungsspeicher 204 oder Systemspeicher 104 über die Kreuzschieneneinheit 210 zu speichern. Eine preROP (Vor-Rasteroperationen) 325 ist konfiguriert, um Daten von der SM 310 zu empfangen, Daten zu ROP-Einheiten innerhalb von Partitionseinheiten 215 zu leiten und Optimierungen für Farbvermischung durchzuführen, Pixelfarbdaten zu organisieren und Adresstranslationen durchzuführen.
Es wird anerkannt werden, dass die Kernarchitektur, die hierin beschrieben ist, beispielhaft ist, und dass Variationen und Modifikationen möglich sind. Irgendeine Anzahl von Verarbeitungsfunktionseinheiten, zum Beispiel SMs 310 oder Textureinheiten 315, preROPs 325 können innerhalb einer GPC 208 enthalten sein. Des Weiteren, während nur eine GPC 208 gezeigt ist, kann eine PPU 202 irgendeine Anzahl von GPCs 208 aufweisen, die vorteilhafter Weise funktionell ähnlich zu einer anderen ist, so dass ein Ausführungsverhalten nicht davon abhängt, welche GPC 208 eine bestimmte Verarbeitungsaufgabe empfängt. Des Weiteren arbeitet jede GPC 208 vorteilhafter Weise unabhängig von anderen GPCs 208 unter Verwendung von separaten und verschiedenen Verarbeitungsfunktionseinheiten, L1-Caches 320 usw.
Der Fachmann wird verstehen, dass die Architektur, die in den 1, 2, 3A und 3B beschrieben ist, in keiner Weise den Schutzumfang der vorliegenden Erfindung beschränkt, und dass die hierin gelehrten Techniken auf irgendeiner geeignet konfigurierten Verarbeitungseinheit, einschließlich ohne Beschränkung eine oder mehrere CPUs, eine oder mehrere Multikern-CPUs, eine oder mehrere PPUs 202, eine oder mehrere GPCs 208, eine oder mehrere Grafik- oder Spezialzweckverarbeitungseinheiten oder ähnliches, implementiert werden können, ohne den Schutzumfang der vorliegenden Erfindung zu verlassen.
In Ausführungsformen der vorliegenden Erfindung ist es wünschenswert, PPU 202 oder einen anderen Prozessor (andere Prozessoren) eines Rechensystems zu verwenden, um Allzweckberechnungen auszuführen, die Thread-Arrays verwenden. Jedem Thread in dem Thread-Array ist eine einmalige Thread-Bezeichnung („Thread-ID”) zugeordnet, die für den Thread während seiner Ausführung zugreifbar ist. Die Thread-ID, die als ein eindimensionaler oder mehrdimensionaler numerischer Wert definiert sein kann, steuert verschiedene Aspekte des Verarbeitungsverhaltens des Threads. Beispielsweise kann eine Thread-ID verwendet werden, um zu bestimmen, welcher Teilbereich des Eingangsdatensatzes ein Thread zu verarbeiten hat und/oder um zu bestimmen, welche Teilbereiche eines Ausgangsdatensatzes ein Thread zu erzeugen oder zu schreiben hat.
Eine Sequenz von Pro-Thread-Anweisungen kann zumindest eine Anweisung aufweisen, die ein kooperatives Verhalten zwischen dem repräsentativen Thread und einem oder mehreren anderen Threads des Thread-Arrays definiert. Beispielsweise kann die Sequenz von Pro-Thread-Anweisungen eine Anweisung aufweisen, die Ausführen von Operationen für den repräsentativen Thread bei einem bestimmten Punkt in der Sequenz auszusetzen, bis zu einer Zeit, zu der ein oder mehrere der anderen Threads diesen bestimmten Punkt erreichen, eine Anweisung für den repräsentativen Thread, Daten in einem geteilten Speicher zu speichern, zu dem einer oder mehrere der anderen Threads Zugriff haben, eine Anweisung für den repräsentativen Thread, Daten, die in einem geteilten Speicher gespeichert sind, zu dem einer oder mehrere der anderen Threads Zugriff haben basierend auf ihren Thread-IDs, atomar zu lesen und zu aktualisieren, oder ähnliches. Das CTA-Programm kann auch eine Anweisung aufweisen, eine Adresse in dem geteilten Speicher zu berechnen, von dem Daten zu lesen sind, wobei die Adresse eine Funktion der Thread-ID ist. Indem geeignete Funktionen definiert und Synchronisierungstechniken bereitgestellt werden, können Daten auf einen gegebenen Ort in einem geteilten Speicher durch einen Thread einer CTA geschrieben werden und von diesem Ort durch einen unterschiedlichen Thread derselben CTA in einer vorhersagbaren Weise gelesen werden. Folglich kann irgendein gewünschtes Muster von Daten, die zwischen Threads geteilt werden, unterstützt werden, und irgendein Thread in einer CTA kann Daten mit irgendeinem anderen Thread in derselben CTA teilen. Der Umfang, wenn überhaupt, von Datenteilung zwischen Threads einer CTA wird durch das CTA-Programm bestimmt; somit sollte verstanden werden, dass in einer bestimmten Anwendung, die CTAs verwendet, die Threads einer CTA aktuell Daten miteinander teilen können oder nicht, abhängig von dem CTA-Programm, und die Begriffe „CTA” und „Thread-Array” werden hierin synonym verwendet.
Rechenarbeitsverteilungs-Referenzzähler
Eine TMD 322 fasst die Metadaten für eine Verarbeitungsaufgabe zusammen, einschließlich von Gitterdimensionen. Die Gitterdimensionen (n, m), wobei n und m ganze Zahlen sind, spezifizieren die Anzahl von CTAs, die ausgeführt werden, um die Aufgabe zu verarbeiten. Beispielsweise spezifizieren Gitterdimensionen 1, 1 eine einzelne CTA und Gitterdimensionen 2, 1 oder 1, 2 spezifizieren zwei CTAs. Gitter können mehr als zwei Dimensionen haben und alle Dimensionsgrößen sind in der TMD spezifiziert. Jede CTA erfordert manche Architekturressourcen zur Ausführung. Die Referenzzähler 350 stellen einen Mechanismus bereit, um die Überzuteilung der Architekturressourcen zu verhindern. Jeder Referenzzähler 350 kann eine einzelne Architekturressource oder eine Kombination von zwei oder mehr Architekturressourcen darstellen. Die Architekturressourcen können einen Teilbereich von geteiltem Speicher, lokalem Speicher, Registern, CTA-Kennzeichnern, Thread-Gruppen und Threads aufweisen. Eine Architekturressource kann auch einen Sperren-Zähler aufweisen, der verwendet wird, um die Synchronisation von unterschiedlichen CTAs einer Ausführung einer Sperren-Anweisung durch einen Thread folgend nachzuverfolgen. Ein separater Sperren-Zähler wird benötigt, um die unterschiedlichen Threads nachzuverfolgen, da sie jeweils eine Sperren-Anweisung erreichen. Eine beschränkte Anzahl von Sperren-Zählern ist verfügbar; daher sind die Sperren-Zähler eine Architekturressource.
Ein Fortsetzungsslot ist eine andere Architekturressource, die für Aufgaben zugeteilt ist. Wie vorher erklärt, kann eine Verarbeitungsaufgabe ein oder mehrere „Kind”-Verarbeitungsaufgaben während der Ausführung erzeugen. Wenn eine Kind-Verarbeitungsaufgabe durch zumindest einen Thread während der Ausführung eines CTA erzeugt wird, werden die Ressourcen, die für den CTA zugeteilt sind, nicht freigegeben. Stattdessen wird die Ausführung des CTA ausgesetzt, während die Kindaufgabe ausgeführt wird unter Verwendung der Architekturressourcen, die der Kindaufgabe zugeteilt sind. Eine Fortsetzungsaufgabe wird erzeugt, um die Ausführung des CTA zu vervollständigen, nachdem die Ausführung der Kindaufgabe vervollständigt ist. Die Fortsetzungsaufgabe ist durch eine TMD 322 dargestellt und verbraucht einen Fortsetzungsslot. Die Kindaufgabe verbraucht keine Architekturressourcen, die für den Eltern-CTA zugeteilt sind. Umgekehrt verbraucht das Eltern-CTA keine Architekturressourcen, die für die Kindaufgabe zugeteilt sind.
Die Aufgaben-/Arbeitseinheit 207 setzt die Ausführung des Eltern-CTA aus, das die Kindaufgabe erzeugt hat, und plant dynamisch die Kindverarbeitungsaufgabe zu einem höheren Prioritätslevel verglichen mit dem Prioritätslevel des Eltern-CTA. Die höhere Priorität ist spezifiziert, so dass die Ausführung der Kindverarbeitungsaufgabe schnell vervollständigt, verglichen mit irgendwelchen anderen CTAs, die für dieselben Aufgaben wie das Eltern-CTA gestartet wurden. Üblicherweise ist die Kindaufgabe erzeugt, um Daten zu berechnen, von denen das Eltern-CTA abhängt. Wenn die Ausführung des Eltern-CTA ausgesetzt ist, ist der Zustand des Eltern-CTA von den GPCs 208 ungeladen und gespeichert. Ausführung des Eltern-CTA kann zu einer späteren Zeit wiederaufnehmen. Fortsetzungsslots sind zugeteilt, um TMDs 322 zu speichern, die die Zustandsinformationen darstellen, die benötigt werden, um die Ausführung des Eltern-CTA wieder aufzunehmen.
Wenn Seitenabruf für Speicher nicht unterstützt ist, muss aller Speicher für die Fortsetzungsslots im Voraus zu der Zeit reserviert werden, zu der die Arbeitsverteilungseinheit 340 ein CTA für die Aufgabe startet. Für eine gegebene Verarbeitungsaufgabe sollte eine spezifizierte Anzahl von Fortsetzungsslots, die für jedes CTA benötigt werden, verfügbar sein, als eine Vorbedingung, um das CTA zu starten, andernfalls mag es nicht möglich sein, den Zustand des CTA zu speichern und nachfolgend wieder herzustellen. Da die Fortsetzungsslotverwendung nur der Software-Laufzeit bekannt ist, die die Aufgaben erzeugt, kann die Arbeitsverteilungseinheit 340 die Fortsetzungsslotsanforderungen nicht ohne Unterstützung durch die Software-Laufzeit nachverfolgen. Die Software-Laufzeit programmiert die Anzahl von Fortsetzungsslots, die in die TMD 322 benötigt werden. In einer Ausführungsform stellt ein Delta-Wert, der als ein Ressourcenparameter enthalten ist, die Anzahl der Fortsetzungsslots dar.
Zusätzlich kann eine Kindaufgabe auch eine Elternaufgabe sein, die ein oder mehrere Kindaufgaben erzeugt, die auch jeweils einen Fortsetzungsslot benötigen werden, um erfolgreich auszuführen. Um zu garantieren, dass jede Kindaufgabe genügend Fortsetzungsslots hat, um zu vervollständigen, wird eine Kindaufgabe einem Fortsetzungsslot aus einem unterschiedlichen Pool von Fortsetzungsslots zugeteilt als die Elternaufgabe. Somit gibt es mehrere Pools von Fortsetzungsslots, die in den Architekturressourcen enthalten sind.
Die Referenzzähler 350 sind initialisiert, um Werte vor der Ausführung der Verarbeitungsaufgaben zu spezifizieren. In einer Ausführungsform wird ein separater Referenzzähler 350 verwendet für jeden unterschiedlichen Prioritätslevel, der für eine TMD 322 spezifiziert sein kann. Die Referenzzähler 350 können als M·P initialisiert sein, um jeden der M SMs 310 zu begrenzen, um eine spezifische Anzahl (P) von CTAs gleichzeitig zu laufen. Alternativ können die Referenzzähler 350 initialisiert sein, um die Anzahl von Thread-Gruppen, die gleichzeitig laufen, zu begrenzen. Da jeder Thread, der für eine CTA ausgeführt wird, eine Kindaufgabe erzeugen kann, kann die Anzahl von Fortsetzungsslots basierend auf der Anzahl unterschiedlicher Prioritätslevel und der Anzahl von gleichzeitigen CTAs (oder der Anzahl von gleichzeitigen Thread-Gruppen) berechnet werden.
Die Ressourcenparameter, die in einer TMD 322 für eine Verarbeitungsaufgabe spezifiziert sind, sind in TABELLE 1 gezeigt. TABELLE 1: Ressourcenparameter

Aufgabe

Gitter (nm)

Ref.Zähl.ID

dec_enable

in_enable

Delta
Die Gitterdimensionen sind spezifiziert und können verwendet werden, um die Anzahl von CTAs zu bestimmen, die für die Aufgabe ausgeführt werden. Die Ref.Zähl.ID ist ein Bezeichner für einen der Referenzzähler 350, wobei ein Referenzzähler eine Anzahl von verfügbaren Ressourcen angibt. Ein dec_enable-Flag ist ein Zuteilungsaktivierungs-Flag, das Dekrementieren des Referenzzählers aktiviert, wenn ein CTA für die Aufgabe gestartet ist. Ein inc_enable-Flag ist ein Zuteilungsfreigabeaktivierungs-Flag, das Inkrementieren des Referenzzählers aktiviert, wenn die Ausführung eines CTA für die Aufgabe vervollständigt ist. In anderen Worten steuern die dec_enable- und inc_enable-Flags Zuteilung und Dezuteilung von Ressourcen für die Aufgabe. Das inc_enable-Flag kann durch eine EXIT-Anweisung überschrieben werden, wenn ein Thread eines CTAs ein Bit setzt, um zu spezifizieren, dass die EXIT-Anweisung eine EXIT.KEEPREFCOUNT-Anweisung ist. Wenn die EXIT-Anweisung eine EXIT.KEEPREFCOUNT-Anweisung ist, werden die Ressourcen, die zur Ausführung des CTA zugeteilt sind, behalten, wenn das CTA beendet und der Referenzzähler wird beibehalten und nicht aktualisiert oder geändert.
Der Delta-Wert ist die Menge, um die der Referenzzähler dekremeniert oder inkrementiert wird. In anderen Ausführungsformen können die Referenzzähler die Anzahl von Ressourcen angeben, die zugeteilt wurden, anstelle der Anzahl von Ressourcen, die verfügbar sind, so dass ein Referenzzähler inkrementiert wird, wenn ein CTA gestartet wird, und dekrementiert wird, wenn ein CTA vervollständigt ist.

Die Ressourcenparameter für die Aufgabe können unterschiedlich für unterschiedliche Aufgaben wie in TABELLE 2 gezeigt spezifiziert werden. TABELLE 2

	Dec_enable	Inc_enable	EXIT.KEEPREFCOUNT
Zuteilen/De-Zuteilen	True	True	False
Zuteilen/De-Zuteilen Elternaufgabe	True	True	True
Nur Zuteilen	True	False	X
Nur De-Zuteilen Fortsetzungsaufgabe	False	True	False
De-Zuteilen deaktiviert	False	True	True
Kein Zuteilen/De-Zuteilen	False	False	X

Beispielsweise wird eine Aufgabe, die dazu gedacht ist, Ressourcen zuzuteilen und dezuzuteilen, dec_enable und inc_enable auf TRUE gesetzt haben. Wenn EXIT.KEEPREFCOUNT FALSE ist, wie in der ersten Zeile von TABELLE 2 gezeigt, werden die Ressourcen freigegeben. Wenn EXIT.KEEPREFCOUNT auf TRUE während der Ausführung des CTA gesetzt wird, wie in der zweiten Zeile von TABELLE 2 gezeigt, kann die Aufgabe eine Elternaufgabe sein und die zugeteilten Ressourcen werden nicht freigegeben. Die EXIT.KEEPREFCOUNT-Funktion ist in größerem Detail im Zusammenhang mit 4 beschrieben.
Wenn eine Berechnungsaufgabe nur konfiguriert ist, Architekturressourcen zuzuteilen und nicht die zugeteilten Architekturressourcen freizugeben, ist die dec_enable auf TRUE gesetzt und inc_enable ist auf FALSE gesetzt, wie in der dritten Zeile von TABELLE 2 gezeigt. Eine Fortsetzungsaufgabe ist konfiguriert, um die Ressourcen, die durch die Elternaufgabe zugeteilt sind, dezuzuteilen. Eine Fortsetzungsaufgabe hat dec_enable auf FALSE gesetzt und inc_enable auf TRUE gesetzt, und EXIT.KEEPREFCOUNT ist nicht auf TRUE gesetzt während der Ausführung der Fortsetzungsaufgabe (angenommen, dass keine Kindaufgabe erzeugt wurden), wie in der vierten Zeile von TABELLE 2 gezeigt. Wenn eine Fortsetzungsaufgabe, die nur konfiguriert ist, Architekturressourcen freizugeben, und nicht um Architekturressourcen zuzuteilen, eine Kindaufgabe während der Ausführung erzeugt, wird die Freigabe der Architekturressourcen durch Setzen von EXIT.KEEPREFCOUNT auf TRUE überschrieben, wie in der fünften Zeile von TABELLE 2 gezeigt. Wenn eine Verarbeitungsaufgabe konfiguriert ist, um Architekturressourcen weder zuzuteilen noch freizugeben, sind dec_enable und inc_enable auf FALSE gesetzt, wie in der letzten Zeile von TABELLE 2 gezeigt.
4A stellt die Referenzzähler 350 von 3A und ressourcenbezogene Parameter einer Scheduler-Aufgabe 430 gemäß einer Ausführungsform der Erfindung dar. Die Referenzzähler 350 speichern ein Array von Referenz(Ref)-Zählern, einschließlich von Ref-Zählern 401, 402, 403 und 404. Die Scheduler-Aufgabe 430 ist konfiguriert, ein Hochprioritätslevel zu haben, und nur ein einzelnes Scheduler-CTA wird zu einer Zeit ausgeführt. Die Scheduler-Aufgabe ist verantwortlich, zu bestimmen, wenn ein Gitter die Ausführung vervollständigt hat und um den Start von Fortsetzungsaufgaben zu initiieren.
Die Scheduler-Aufgabe 430 spezifiziert ein Gitter (n, m) und den Referenzzählerbezeichner (ID) des Referenzzähler's 404. Inc_enable und dec_enable sind beide TRUE und das Delta ist auf 1 gesetzt. Der Referenzzähler 404 ist auf 1 initialisiert, gleich dem Delta, so dass nur ein einzelnes CTA zu einer Zeit ausgeführt werden kann. Daher ist die Ausführung der Scheduler-Aufgabe 430 serialisiert. Wenn die Scheduler-Aufgabe 430 ein erstes CTA startet, wird der Referenzzähler 404 um 1 auf einen Wert von 0 dekrementiert. Wenn die Ausführung des CTA vervollständigt, wird der Referenzzähler 303 von 0 auf einen Wert von 1 inkrementiert und ein zweites CTA kann für die Scheduler-Aufgabe 430 gestartet werden. Der Referenzzähler 404 sollte nicht durch irgendwelche anderen Aufgaben spezifiziert werden, um sicherzustellen, dass die Scheduler-Aufgabe 430 immer ein CTA ausführend haben kann.
In Summe werden die programmierbaren Referenzzähler 350 auf Werte initialisiert, die die Menge an Ressourcen zur Zuteilung für Aufgaben begrenzen, die denselben Referenzzähler spezifizieren. Die Ressourcenparameter, die für jede Aufgabe spezifiziert sind, definieren die Menge an Ressourcen, die zum Verbrauch durch jedes CTA zugeteilt sind, das gestartet wird, um eine Aufgabe auszuführen. Die Ressourcenparameter spezifizieren auch das Verhalten eines CTA zum Erlangen und Freigeben von Ressourcen. Schließlich kann die EXIT-Anweisung zur Laufzeit konfiguriert sein, das Freigeben der Ressourcen, die einem CTA zugeteilt sind, zu überschreiben.
4B stellt die Referenzzähler 350 von 3A und ressourcenbezogene Parameter für unterschiedliche Aufgaben gemäß einer Ausführungsform der Erfindung dar. Zusätzlich zu den Referenzzählern 350 und der Scheduler-Aufgabe 430 stellt 4B Aufgabe 410, die eine Elternaufgabe ist, eine Kindaufgabe 420 und eine Fortsetzungsaufgabe 440 dar, die durch die Elternaufgabe 410 erzeugt ist. Die Aufgabe 410 spezifiziert ein Gitter (2, 2), so dass vier CTAs ausführen werden und die Referenzzähler-ID des Referenzzählers 401. Inc_enable und dec_enable sind beide TRUE und das Delta ist auf 2 gesetzt. Der Referenzzähler 401 ist auf 4 initialisiert, zweimal den Delta-Wert, so dass zwei CTAs gleichzeitig ausführen können. Wenn die Scheduler-Aufgabe 430 ein erstes CTA startet, wird der Referenzzähler 404 um 2 auf einen Wert von 2 dekrementiert. Wenn die Scheduler-Aufgabe 430 ein zweites CTA startet, wird der Referenzzähler 404 um zwei auf einen Wert von 0 dekrementiert.
Während der Ausführung erzeugt ein Thread des ersten CTA die Kindaufgabe 420. Ein oder mehrere Threads des ersten CTAs können einen Codepfad ausführen, der in der Erzeugung einer Kindaufgabe resultiert. Üblicherweise ist die weitere Ausführung des ersten CTAs von der Ausführung der Kindaufgabe(n), die durch das erste CTA erzeugt wird (werden), abhängig. Wenn zumindest ein Thread des ersten CTA eine Kindaufgabe erzeugt, wird ein „klebriges” Bit gesetzt, um sicherzustellen, dass die EXIT-Anweisung an dem Ende des Codes für den ersten CTA als ein EXIT.KEEPREFCOUNT ausgeführt wird, so dass die Ressourcen, die dem ersten CTA zugeteilt sind, behalten und nicht freigegeben werden. Das klebrige Merkmal des KEEPREFCOUNT ermöglicht, dass die unterschiedlichen Threads eines CTA, ohne zueinander bei der EXIT-Anweisung zu synchronisieren, beenden. Daher fallen durch die Threads, die die EXIT-Anweisung früher als andere Threads in dem CTA erreichen, keine Leerlaufzyklen an.
Die Ressourcen, die dem ersten CTA zugeteilt sind, weisen einen Fortsetzungsslot auf, das heißt Speicher, der benötigt wird, um den Ausführungszustand des ersten CTA in einem TMD 322 zu speichern, der die Fortsetzungsaufgabe 440 darstellt. Daher überschreibt das EXIT.KEEPREFCOUNT den inc_enable, der auf True gesetzt ist, der gewöhnlich die zugeteilten Ressourcen für das erste CTA freigeben würde, wenn das erste CTA beendet. Wichtigerweise kann die EXIT-Anweisung dynamisch konfiguriert sein, die Ressourcen (durch Anhängen des .KEEPREFCOUNT) für ein CTA während der Ausführung der CTA-Threads nicht freizugeben. Im Gegensatz werden die Ressourcenparameter, zum Beispiel Gitter, inc_enable, dec_enable, Delta und Ref_Zähler, initialisiert oder geändert, wenn keine CTAs für die Aufgabe ausgeführt werden.
Die Fortsetzungsaufgabe 440 ist durch Software-Laufzeit als eine Fortsetzung des ersten CTA erzeugt, wenn das letzte CTA der Kindaufgabe die Ausführung vervollständigt und beendet oder wenn die Scheduler-Aufgabe ausgeführt wird. Während der Ausführung können andere CTAs, wie das zweite CTA, auch ein oder mehrere Kindaufgaben erzeugen, die dann korrespondierende Fortsetzungsaufgaben veranlassen, erzeugt zu werden. Die Fortsetzungsaufgabe 440 führt zu einer späteren Zeit aus, um die Ausführung des ersten CTA zu vervollständigen. Beim Beenden gibt die Fortsetzungsaufgabe 440 die Ressourcen, die ursprünglich dem ersten CTA zugeteilt waren, frei. Daher spezifiziert die Fortsetzungsaufgabe 440 ein Gitter (1, 1), so dass ein einzelnes CTA, das das erste CTA der Aufgabe 410 fortführt, ausgeführt werden wird. Dieselbe Referenzzähler-ID, wie durch das erste CTA verwendet, so Referenzzähler 401, ist für die Fortsetzungsaufgabe 440 spezifiziert. Inc_enable ist TRUE, so dass die Ressourcen, die dem ersten CTA zugeteilt sind, freigegeben werden, außer wenn durch den EXIT.KEEPREFCOUNT aufgrund der Erzeugung einer anderen Kindaufgabe überschrieben. Das dec_enable ist FALSE gesetzt, so dass das Ressourcen zusätzlich zu denen, die für das erste CTA zugeteilt sind, für die Fortsetzungsaufgabe 440 nicht zugeteilt werden. Das Delta ist auf 2 gesetzt, was dem Delta der Elternaufgabe 410 entspricht.
Die Scheduler-Aufgabe 430 ermöglicht, dass das Starten der Fortsetzungsaufgabe 440 die Ausführung des ersten CTA wieder aufnimmt, indem Abhängigkeiten des ersten CTA überwacht werden, wie Fertigstellung der Kindaufgabe 420. Wenn das CTA für die Fortsetzungsaufgabe 440 die Ausführung vervollständigt (angenommen, dass keine Kindaufgabe erzeugt ist), wird der Ref-Zähler 401 um das Delta inkrementiert, was den Restzähler 401 um 2 erhöht. Dies ermöglicht, dass ein anderes CTA für die Aufgabe 410 gestartet wird. In ähnlicher Weise, wenn das zweite CTA die Ausführung vervollständigt (angenommen, dass keine Kindaufgabe für das zweite CTA erzeugt ist), wird der Ref-Zähler 401 um das Delta inkrementiert, was erlaubt, dass ein anderes CTA für die Aufgabe 410 gestartet wird.
5A stellt ein Verfahren 500 zum Verwalten von Architekturressourcen dar, wenn Aufgaben gestartet werden, gemäß einer Ausführungsform der Erfindung. Obwohl die Verfahrensschritte im Zusammenhang mit den Systemen von 1, 2, 3A und 3B beschrieben sind, wird der Fachmann verstehen, dass irgendein System, das konfiguriert ist, die Verfahrensschritte in irgendeiner Reihenfolge durchzuführen, innerhalb des Schutzumfangs der Erfindungen ist.
Bei Schritt 505 werden die Architekturressourcenparameter für eine Aufgabe initialisiert. Bei Schritt 510 wird die Aufgabentabelle 345 mit Verarbeitungsaufgaben, die auszuführen sind, gefüllt. Man beachte, dass Fortsetzungsaufgaben in der Aufgabentabelle 345 durch die Scheduler-Aufgabe 430 gespeichert werden, da Einträge verfügbar werden und da irgendwelche Abhängigkeiten, die die Ausführung einer Fortsetzungsaufgabe verhindern, gelöst werden.
Bei Schritt 515 wählt die Arbeitsverteilungseinheit 340 eine Verarbeitungsaufgabe von der Aufgabentabelle 345 zur Ausführung aus. Bei Schritt 520 bestimmt die Arbeitsverteilungseinheit 340, ob der dec_enable-Ressourcenparameter für die ausgewählte Aufgabe auf FALSE gesetzt ist, und, wenn so, dann startet bei Schritt 540 die Arbeitsverteilungseinheit 340 ein CTA für die ausgewählte Aufgabe. Andernfalls liest bei Schritt 525 die Arbeitsverteilungseinheit 340 den Ref-Zähler, der durch die ausgewählte Aufgabe spezifiziert ist, um den Wert zu erhalten, der die verfügbaren Architekturressourcen angibt. Bei Schritt 530 bestimmt die Arbeitsverteilungseinheit 340, ob der Delta-Wert, der durch die ausgewählte Aufgabe spezifiziert ist, größer ist als der Wert, der die verfügbaren Architekturressourcen angibt, und, wenn so, dann sind nicht genügend Architekturressourcen zur Zuteilung zu der ausgewählten Aufgabe verfügbar und die Arbeitsverteilungseinheit 340 kehrt zu Schritt 515 zurück, um eine unterschiedliche Aufgabe auszuwählen.
Andernfalls aktualisiert bei Schritt 535 die Arbeitsverteilungseinheit 340 den Wert, der die verfügbaren Architekturressourcen angibt, zum Beispiel dekrementiert den Ref-Zähler um das Delta, um die verfügbaren Architekturressourcen zu reduzieren. Man beachte, dass die Dekrementierungsoperation eine atomare Operation sein sollte, da derselbe Referenzzähler auch simultan aktualisiert sein kann, um zugeteilte Architekturressourcen freizugeben. Bei Schritt 504 startet die Arbeitsverteilungseinheit 340 ein CTA für die ausgewählte Aufgabe. Wenn eine Aufgabe nicht geeignet ist, ein CTA zu starten, aufgrund einer Knappheit an Architekturressourcen bei Schritt 530, kann die Arbeitsverteilungseinheit 340 die Aufgabe von der Aufgabentabelle 345 entfernen, um die Aufgabe mit einer unterschiedlichen Aufgabe oder gleicher oder höherer Priorität zu ersetzen.
5B stellt ein Verfahren 550 zum Verwalten von Architekturressourcen dar, wenn eine Exit-Anweisung erreicht wird, gemäß einer Ausführungsform der Erfindung. Obwohl die Verfahrensschritte im Zusammenhang mit den Systemen von 1, 2, 3A und 3B beschrieben sind, wird der Fachmann verstehen, dass irgendein System, das konfiguriert ist, die Verfahrensschritte in irgendeiner Reihenfolge durchzuführen, innerhalb des Schutzumfangs der Erfindungen ist.
Bei Schritt 555 erreicht ein CTA-Thread für eine Aufgabe eine Exit-Anweisung. Bei Schritt 560 bestimmt der Thread, ob inc_enable FALSE ist und wenn so, dann ist bei Schritt 585 die Ausführung des Threads vervollständigt. Andernfalls bestimmt bei Schritt 565 der Thread, ob KEEPREFCOUNT TRUE ist. Wenn, wird der Thread oder irgendein anderer Thread des CTA, der eine Kindaufgabe während der Ausführung des KEEPREFCOUNT erzeugt hat, auf TRUE gesetzt werden. Wenn bei Schritt 565 der KEEPREFCOUNT TRUE ist, wird bei Schritt 585 die Ausführung des Threads vervollständigt. Andernfalls, wenn KEEPREFCOUNT FALSE ist, bestimmt der Thread, ob dies der letzte Thread für das CTA ist, und wenn so, wird bei Schritt 580 der Referenzzähler aktualisiert, um die Ressourcen, die dem CTA zugeteilt sind, freizugeben. Man beachte, dass die Inkrementierungsoperation eine atomare Operation sein sollte, da derselbe Referenzzähler auch simultan aktualisiert sein kann, um Architekturressourcen zuzuteilen. Bei Schritt 585 ist die Ausführung des Threads vervollständigt.
Die Fähigkeit, das Freigeben von Architekturressourcen durch den KEEPREFCOUNT dynamisch zu steuern, ermöglicht, dass eine Verarbeitungsaufgabe ein oder mehrere Level von geschachteltem Parallelismus durchführt. Jedoch müssen die Fortsetzungsslots, die während des Verarbeitens einer Aufgabe benötigt werden können, zugeteilt werden, wenn jeder CTA für eine Aufgabe gestartet ist, um sicherzustellen, dass nicht mehr Architekturressourcen, als sie verfügbar sind, verbraucht werden. Daher können die Ressourcenparameter eine oder mehrere Architekturressourcen darstellen. Auch ermöglicht die Fähigkeit, die Ausführung eines CTA auszusetzen, ein Kontextschalten bei dem individuellen Aufgabenlevel ohne Zustandsinformationen für alle der Verarbeitungsaufgaben, die von den GPCs 208 ausgeführt werden, zu entladen oder zu entleeren.
Eine Ausführungsform der Erfindung kann als ein Programmprodukt zur Verwendung mit einem Computersystem implementiert werden. Das Programm (die Programme) des Programmprodukts definieren Funktionen der Ausführungsformen (einschließlich der hierin beschriebenen Methoden) und können auf einer Vielzahl von computerlesbaren Speichermedien enthalten sein. Beispielhafte computerlesbare Speichermedien weisen auf, aber sind nicht beschränkt auf: (i) nicht-schreibbare Speichermedien (z. B. Nur-Lesespeicher-Vorrichtungen innerhalb eines Computers wie CD-ROM-Festplatten, die durch ein CD-ROM-Laufwerk lesbar sind, Flash-Speicher, ROM-Chips oder irgendeine andere Art von nicht-flüchtigem Festkörper-Halbleiterspeicher), auf dem Informationen permanent gespeichert sind; und (ii) beschreibbare Speichermedien (z. B. Disketten innerhalb eines Diskettenlaufwerks oder Festplatten oder irgendeiner andere Art von Festkörper-Zufalls-Zugriffs-Halbleiterspeicher), auf denen veränderbare Informationen gespeichert sind.
Die Erfindung wurde oben mit Bezug auf spezifische Ausführungsformen beschrieben. Der Fachmann wird jedoch verstehen, dass verschiedene Modifikationen und Veränderungen daran gemacht werden können, ohne von dem breiteren Sinn und Schutzumfang der Erfindung, wie in den angehängten Ansprüchen dargelegt, abzuweichen. Die vorhergehende Beschreibung und Zeichnungen sind daher in einem veranschaulichenden statt einem einschränkenden Sinn zu betrachten.

Claims

Ein Verfahren zum Zuteilen und Freigeben von Architekturressourcen in einem Multithreaded-System, wobei das Verfahren aufweist: Zuteilen der Architekturressourcen zu einem ersten Thread-Array, das eine Mehrzahl von Threads aufweist, um eine Verarbeitungsaufgabe auszuführen; Bestimmen durch jeden Thread in dem ersten Thread-Array, während der Ausführung der Verarbeitungsaufgabe, ob ein Freigeben der Architekturressourcen überschrieben werden wird, wenn das erste Thread-Array beendet, Freigeben der Architekturressourcen, wenn das erste Thread-Array beendet und kein Thread in dem ersten Thread-Array bestimmt hat, dass das Freigeben der Architekturressourcen nicht überschrieben werden würde; und Behalten der Architekturressourcen, wenn das erste Thread-Array beendet und zumindest ein Thread in dem ersten Thread-Array bestimmt hat, dass das Freigeben der Architekturressourcen überschrieben werden würde.
Das Verfahren gemäß Anspruch 1, wobei ein erster Thread des ersten Thread-Arrays eine Kindverarbeitungsaufgabe während der Ausführung der Verarbeitungsaufgabe erzeugt und bestimmt, dass das Freigeben der Architekturressourcen überschrieben werden wird, wenn das erste Thread-Array beendet.
Das Verfahren gemäß Anspruch 2, des Weiteren aufweisend Zuteilen von zusätzlichen Architekturressourcen für die Kindverarbeitungsaufgabe von einem separaten Pool, der nicht die Architekturressourcen enthält, die dem ersten Thread-Array zugeteilt sind.
Das Verfahren gemäß Anspruch 2, des Weiteren aufweisend Erzeugen einer Fortsetzungsaufgabe, die konfiguriert ist, die Verarbeitungsaufgabe zu vervollständigen, die durch den ersten Thread ausgeführt wird, und die Architekturressourcen freizugeben, die dem ersten Thread-Array zugeteilt sind.
Das Verfahren gemäß Anspruch 1, weiterhin aufweisend Initialisieren eines Referenzzählers, der eine Maximalquantität von Architekturressourcen in einem Pool begrenzt, die zur Zuteilung verfügbar sind.
Das Verfahren gemäß Anspruch 5, wobei Ressourcenparameter durch die Berechnungsaufgabe spezifiziert sind, und die Ressourcenparameter einen Delta-Wert aufweisen, der eine Quantität der Architekturressourcen angibt, die für das erste Thread-Array benötigt werden.
Ein Multithreaded-System, das konfiguriert ist, Architekturressourcen zuzuteilen und freizugeben, aufweisend: einen Speicher, der konfiguriert ist, Programmanweisungen zu speichern, die zu einer Verarbeitungsaufgabe korrespondieren; ein allgemeines Verarbeitungscluster, das konfiguriert ist, ein erstes Thread-Array zu verarbeiten, das eine Mehrzahl von Threads aufweist, um die Verarbeitungsaufgabe auszuführen, wobei, während der Ausführung der Verarbeitungsaufgabe, jeder Thread des ersten Thread-Arrays bestimmt, ob ein Freigeben der Architekturressourcen überschrieben werden wird, wenn das erste Thread-Array beendet; eine Arbeitsverteilungseinheit, die mit dem allgemeinen Verarbeitungscluster gekoppelt ist, und konfiguriert ist, um: die Architekturressourcen dem ersten Thread-Array zuzuteilen; die Architekturressourcen freizugeben, wenn das erste Thread-Array beendet und kein Thread in dem ersten Thread-Array bestimmt hat, dass das Freigeben der Architekturressourcen nicht überschrieben werden würde; und die Architekturressourcen zu behalten, wenn das erste Thread-Array beendet und zumindest ein Thread in dem ersten Thread-Array bestimmt hat, dass das Freigeben der Architekturressourcen überschrieben werden würde.
Das Multithreaded-System gemäß Anspruch 7, wobei ein erster Thread des ersten Thread-Arrays eine Kindverarbeitungsaufgabe während der Ausführung der Verarbeitungsaufgabe erzeugt und bestimmt, dass das Freigeben der Architekturressourcen überschrieben werden wird, wenn das erste Thread-Array beendet.
Das Multithreaded-System gemäß Anspruch 7, wobei die Arbeitsverteilungseinheit des Weiteren konfiguriert ist, einen Referenzzähler zu initialisieren, der eine Maximalquantität von Architekturressourcen in einem Pool begrenzt, die zur Zuteilung verfügbar sind.
Das Multithreaded-System gemäß Anspruch 9, wobei der Referenzzähler eine Kombination von unterschiedlichen Architekturressourcen darstellt.