DE102019101853A1

DE102019101853A1 - Dynamische Partitionierung von Ausführungsressourcen

Info

Publication number: DE102019101853A1
Application number: DE102019101853.6A
Authority: DE
Inventors: Jerome F. Duluk jun.; Luke Durant; Ramon Matas Navarro; Alan Menezes; Jeffrey Tuckey; Gentaro Hirota; Brian Pharris
Original assignee: Nvidia Corp
Current assignee: Nvidia Corp
Priority date: 2018-01-31
Filing date: 2019-01-25
Publication date: 2019-08-01
Also published as: CN110096341B; CN110096341A

Abstract

Ausführungsformen der vorliegenden Erfindung stellen Techniken zum Zuteilen von Ausführungsressourcen zu Gruppen von Threads innerhalb einer Grafikverarbeitungseinheit dar. Ein in der Grafikverarbeitungseinheit enthaltener Rechenarbeitsverteiler empfängt von einem Prozess eine Angabe, dass eine erste Gruppe von Threads zu starten ist. Der Rechenarbeitsverteiler ermittelt, dass ein erster Subkontext, der dem Prozess zugeordnet ist, mindestens ein Prozessor-Guthaben aufweist. In manchen Ausführungsformen können CTAs auch dann gestartet werden, wenn es keine Prozessor-Guthaben gibt, falls einer der TPCs bereits genügend Platz erworben hat. Der Rechenarbeitsverteiler identifiziert einen ersten Prozessor, der in einer Vielzahl von Prozessoren enthalten ist und der eine Verarbeitungslast aufweist, die kleiner oder gleich der Prozessorlast ist, die allen anderen Prozessoren zugeordnet ist, die in der Vielzahl von Prozessoren enthalten sind. Der Rechenarbeitsverteiler startet die erste Gruppe von Threads zur Ausführung auf dem ersten Prozessor.

Description

Hintergrund der Erfindung
Gebiet der Erfindung
Ausführungsformen der vorliegenden Erfindung beziehen sich allgemein auf Computerverarbeitung und insbesondere auf dynamische Partitionierung von Ausführu ngsressourcen.
Beschreibung der zugehörigen Technik
Moderne Grafikverarbeitungseinheiten (GPUs) sind typischerweise so konfiguriert, dass sie eine große Anzahl von Threads parallel ausführen können. Dabei ist eine GPU normalerweise darauf beschränkt, in einem Kontext nach dem anderen zu arbeiten, wobei alle Threads in dem gleichen Kontext ausgeführt werden. Diese Beschränkung bedeutet unter anderem, dass jeder Thread, der zu einer bestimmten Zeit ausgeführt wird, den gleichen GPU-Zustand und den gleichen virtuellen Adressraum teilt. Ein solches Betriebsmodell arbeitet gut für einen Prozess, der große Mengen von Parallelität zeigt, wobei der Prozess einen erheblichen Prozentsatz der verfügbaren Verarbeitungsressourcen der GPU nutzen kann. Viele Anwendungsprogramme führen jedoch Mehrfachprozesse aus, wobei jeder Prozess nur genügend Parallelität ausdrückt, um einen kleinen Prozentsatz der verfügbaren Verarbeitungsressourcen der GPU zu nutzen, und wobei jeder Prozess einen anderen GPU-Zustand und einen anderen virtuellen Adressraum benötigt. Dementsprechend laufen Anwendungsprogramme, die Mehrfachprozesse ausführen, oftmals ineffizient auf GPUs.
Um dieses Problem zu lösen, arbeiten manche GPU-Ausführungsmodelle in einem einzigen Kontext, wobei dieser Kontext mehrere Subkontexte hat und jeder Subkontext einem anderen Prozess zugewiesen ist. Bei einer solchen Methode arbeiten alle Subkontexte innerhalb des gleichen Kontexts, doch hat jeder Subkontext einen anderen GPU-Zustand und einen anderen virtuellen Adressraum. In einer bestimmten Implementierung wird jeder Subkontext statisch einem oder mehreren spezifischen Texturverarbeitungsclustern (TPCs) zugewiesen, wobei jeder TPC zwei oder mehr Streaming-Multiprozessoren (SMs) enthält, so dass jeder TPC eine bestimmte Anzahl von Threads gleichzeitig ausführen kann. Weiterhin wird der Teilsatz des virtuellen Adressraums eines jeden Subkontexts, der für Verwendung als lokaler Thread-Speicher reserviert ist, statisch für jeden TPC zugewiesen, den der Subkontext verwenden darf.
Ein Nachteil der obigen Implementierung ist, dass die Zuweisung von TPCs und Speicherplätzen zu den verschiedenen Subkontexten, die den verschiedenen Prozessen zugeordnet sind, statisch ist, was die Fähigkeit des Systems zu Lastausgleich zwischen den verschiedenen TPCs und Speicherressourcen beschränkt. Unter anderem kann es sein, dass die verschiedenen Prozesse, die den verschiedenen Subkontexten zugeordnet sind, unterschiedliche Mengen von Verarbeitungs- und Speicherressourcen benötigen. Darüber hinaus können sich die Verarbeitungs- und Speicheranforderungen für einen bestimmten Prozess mit der Zeit ändern. Da die den verschiedenen Subkontexten zugeteilten TPCs und der den verschiedenen Subkontexten zugewiesene Speicher jedoch statisch sind, können diese Ressourcen nicht erhöht oder verringert werden, wenn sich Bedingungen oder Anforderungen ändern. Zum Beispiel könnte ein Prozess, der in einem Subkontext ausgeführt wird, der einem Satz stark belasteter TPCs zugewiesen ist, ein neues Kooperativ-Thread-Array (CTA) starten. Das neue CTA wäre jedoch nur im Stande, auf dem Satz der stark belasteten TPCs zu starten, da diese TPCs diejenigen sind, die diesem Prozess zugeteilt sind, selbst wenn andere TPCs, die anderen Prozessen zugeteilt sind, geringer belastet oder untätig sind. Daher kann statische Partitionierung von Ressourcen auf verschiedene Subkontexte auch zu ineffizienter Zuteilung und Ausführung von GPU-Ressourcen führen.
Wie das Vorhergehende veranschaulicht, werden in der Technik effektivere Techniken zum Zuteilen von Ausführungsressourcen innerhalb eines Prozessors benötigt.
Kurzdarstellung der Erfindung
Ausführungsformen der vorliegenden Erfindung stellen ein computerimplementiertes Verfahren zum Zuteilen von Ausführungsressourcen zu Gruppen von Threads innerhalb einer Grafikverarbeitungseinheit dar. Das Verfahren umfasst das Empfangen einer Angabe von einem Prozess, dass eine erste Gruppe von Threads zu starten ist. Das Verfahren umfasst weiterhin das Ermitteln, dass ein erster Subkontext, der dem Prozess zuordnet ist, mindestens ein Prozessor-Guthaben aufweist. Das Verfahren umfasst weiterhin das Identifizieren eines ersten Prozessors, der in einer Vielzahl von Prozessoren enthalten ist und der eine Verarbeitungslast aufweist, die kleiner oder gleich den Prozessorlasten ist, die allen anderen Prozessoren zugeordnet sind, die in der Vielzahl von Prozessoren enthalten sind. Das Verfahren umfasst weiterhin das Starten der ersten Gruppe von Threads zur Ausführung auf dem ersten Prozessor.
Ausführungsformen der vorliegenden Erfindung stellen ein computerimplementiertes Verfahren zum Zuweisen von lokalem Speicher zu Thread-Gruppen innerhalb einer Grafikverarbeitungseinheit dar. Das Verfahren umfasst das Empfangen einer Angabe, dass eine erste Thread-Gruppe, die einem ersten Subkontext zugeordnet ist, zur Ausführung auf einem ersten Prozessor zugewiesen worden ist. Das Verfahren umfasst weiterhin das Identifizieren einer ersten Aufzeichnung in einer Lokalspeicherblock-Zuweisungstabelle entsprechend dem ersten Subkontext. Das Verfahren umfasst weiterhin das Identifizieren eines ersten Lokalspeicherblocks, der gegenwärtig nicht zugewiesen ist. Das Verfahren umfasst weiterhin das Speichern eines ersten Wertes in der ersten Aufzeichnung, der angibt, dass der erste Lokalspeicherblock dem ersten Subkontext und dem ersten Prozessor zugewiesen ist.
Andere Ausführungsformen der vorliegenden Erfindung umfassen ohne Beschränkung ein Parallelverarbeitungs-Subsystem zur Durchführung eines oder mehrerer Aspekte der offenbarten Techniken sowie ein System zur Durchführung eines oder mehrerer Aspekte der offenbarten Techniken.
Mindestens ein Vorteil der offenbarten Techniken besteht darin, dass Ausführungs- und Lokalspeicherressourcen flexibel und effizient Subkontexten zugeordnet werden, die Mehrfachprozessen innerhalb eines Parallelverarbeitungssystems entsprechen. Dadurch wird die Ausnutzung der Ausführungs- und Lokalspeicherressourcen im Vergleich zu früheren Methoden erhöht. Ein weiterer Vorteil der offenbarten Techniken besteht darin, dass die maximale Menge an Ausführungs- und Lokalspeicherressourcen, die einem Subkontext zugeteilt oder zugewiesen werden können, innerhalb der Grenzen der Anzahl der verfügbaren TPCs und Lokalspeicherblöcke wählbar ist und begrenzt werden kann, damit mehr Subkontexte gleichzeitig ausführen können. Ein weiterer Vorteil der offenbarten Techniken ist, dass alle Subkontexte innerhalb eines einzigen Kontexts ausführen, aber getrennte virtuelle Adressräume und getrennte Zustandsdaten unterhalten. Dadurch können TPCs schnell von der Ausführung eines CTA für einen Subkontext auf die Ausführung eines CTA für einen anderen Subkontext wechseln, ohne dass ein vollständiger Kontextwechsel erforderlich ist.
Figurenliste
Für ein näheres Verständnis der oben angegebenen Merkmale der vorliegenden Erfindung ist eine speziellere Beschreibung der oben kurz zusammengefassten Erfindung unter Bezugnahme auf Ausführungsformen erhältlich, von denen einige in den beigefügten Zeichnungen dargestellt sind. Man beachte jedoch, dass die beigefügten Zeichnungen nur typische Ausführungsformen dieser Erfindung veranschaulichen und daher nicht als ihren Schutzbereich beschränkend anzusehen sind, da die Erfindung andere, gleichermaßen wirksame Ausführungsformen zulassen kann.

1 ist ein Blockdiagramm, das ein Computersystem veranschaulicht, das konfiguriert ist, um einen oder mehrere Aspekte der vorliegenden Erfindung zu implementieren;
2 ist ein Blockdiagramm einer Parallelverarbeitungseinheit (PPU), die in dem Parallelverarbeitungs-Subsystem von 1 enthalten ist, gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung;
3 ist ein Blockdiagramm eines Allgemeinverarbeitungsclusters (GPC), der in der Parallelverarbeitungseinheit (PPU) von 2 enthalten ist, gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung;
4 ist eine detailliertere Ansicht der Aufgaben-/Arbeitseinheit von 2 gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung;
5A-5B veranschaulichen eine TPC-Freigabetabelle und eine LMEM-Block-Indextabelle für statische TPC-Partitionierung gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung;
6A-6B veranschaulichen eine TPC-Freigabetabelle und eine LMEM-Block-Indextabelle für statische TPC-Partitionierung gemäß weiteren verschiedenen Ausführungsformen der vorliegenden Erfindung;
7 veranschaulicht eine TPC-Freigabetabelle 800 für dynamische TPC-Partitionierung gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung;
8 veranschaulicht eine TPC-Freigabetabelle 800 für dynamische TPC-Partitionierung gemäß anderen verschiedenen Ausführungsformen der vorliegenden Erfindung;
9A-9C zeigen ein Flussdiagramm von Verfahrensschritten zum Zuteilen von Ausführungsressourcen innerhalb eines Prozessors gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung; und
10A-10B zeigen ein Flussdiagramm von Verfahrensschritten zum Zuweisen von Lokalspeicherressourcen innerhalb eines Prozessors gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung.

Detaillierte Beschreibung
In der folgenden Beschreibung werden zahlreiche spezifische Details dargelegt, um ein besseres Verständnis der vorliegenden Erfindung zu ermöglichen. Ein Fachmann erkennt jedoch, dass die vorliegende Erfindung ohne eines oder mehrere dieser spezifischen Details realisiert werden kann.
Systemübersicht
1 ist ein Blockdiagramm, das ein Computersystem 100 veranschaulicht, das konfiguriert ist, um einen oder mehrere Aspekte der vorliegenden Erfindung zu implementieren. In manchen Ausführungsformen ist das Computersystem 100 eine Servermaschine, die in einem Rechenzentrum oder einer Cloud-Computing-Umgebung arbeitet und skalierbare Computerressourcen als ein Dienst über ein Netz bereitstellt. Wie gezeigt, enthält das Computersystem 100 ohne Beschränkung eine Zentralverarbeitungseinheit (CPU) 102 und einen Systemspeicher 104, der über eine Speicherbrücke 105 und einen Kommunikationsweg 113 mit einem Parallelverarbeitungs-Subsystem 112 gekoppelt ist. Die Speicherbrücke 105 ist weiterhin über einen Kommunikationsweg 106 mit einer I/O(Eingabe/Ausgabe)-Brücke 107 gekoppelt, und die I/O-Brücke 107 ist wiederum mit einem Switch 116 gekoppelt.
Im Betrieb ist die I/O-Brücke 107 konfiguriert, um Benutzereingabeinformationen von optionalen Eingabegeräten 108 wie z. B. einer Tastatur oder einer Maus zu empfangen und die Eingabeinformationen über den Kommunikationsweg 106 und die Speicherbrücke 105 an die CPU 102 zur Verarbeitung weiterzuleiten. In manchen Ausführungsformen kann das Computersystem 100 eine Servermaschine in einer Cloud-Computing-Umgebung sein. In solchen Ausführungsformen hat das Computersystem 100 möglicherweise keine Eingabegeräte 108. Stattdessen kann das Computersystem 100 äquivalente Eingabeinformationen empfangen, indem es Befehle in Form von über ein Netz gesendeten und über den Netzadapter 118 empfangenen Nachrichten empfängt. Der Switch 116 ist konfiguriert, um Verbindungen zwischen der I/O-Brücke 107 und anderen Komponenten des Computersystems 100 bereitzustellen, wie z. B. einem Netzadapter 118 und verschiedenen Add-in-Karten 120 und 121.
Wie ebenfalls gezeigt, ist die I/O-Brücke 107 mit einer Systemplatte 114 gekoppelt, die konfiguriert sein kann, um Inhalte, Anwendungen und Daten zur Verwendung durch die CPU 102 und das Parallelverarbeitungs-Subsystem 112 zu speichern. Generell stellt die Systemplatte 114 nichtflüchtigen Speicher für Anwendungen und Daten bereit und kann Fest- oder Wechselplattenlaufwerke, Flash-Speichergeräte und CD-ROM (Compact Disc Read-only-Memory), DVD-ROM (Digital Versatile Disc-ROM), Blu-Ray, HD-DVD (High Definition DVD) oder andere magnetische, optische oder Halbleiterspeichergeräte enthalten. Schließlich können, obwohl nicht explizit gezeigt, auch andere Komponenten wie z. B. USB-(Universal Serial Bus) oder andere Port-Anschlüsse, CD-Laufwerke, DVD-Laufwerke, Filmaufzeichnungsgeräte und dergleichen mit der I/O-Brücke 107 verbunden sein.
In verschiedenen Ausführungsformen kann die Speicherbrücke 105 ein Northbridge-Chip sein und kann die I/O-Brücke 107 ein Southbridge-Chip sein. Darüber hinaus können die Kommunikationswege 106 und 113 sowie andere Kommunikationswege innerhalb des Computersystems 100 unter Verwendung irgendwelcher technisch geeigneten Protokolle implementiert werden, einschließlich, aber nicht beschränkt auf AGP (Accelerated Graphics Port), HyperTransport oder irgendein anderes in der Technik bekanntes Bus- oder Punkt-zu-Punkt-Kommunikationsprotokoll.
In manchen Ausführungsformen umfasst das Parallelverarbeitungs-Subsystem 112 ein Grafik-Subsystem, das Pixel an ein optionales Display-Gerät 110 liefert, das eine konventionelle Kathodenstrahlröhre, eine Flüssigkristallanzeige, eine Leuchtdiodenanzeige oder dergleichen sein kann. In solchen Ausführungsformen enthält das Parallelverarbeitungs-Subsystem 112 eine für Grafik- und Videoverarbeitung optimierte Schaltung, die zum Beispiel eine Videoausgabeschaltung enthält. Wie im Folgenden in Verbindung mit 2 und 3 näher beschrieben, kann eine solche Schaltung über eine oder mehrere Parallelverarbeitungseinheiten (PPUs), die hierin auch als Parallelprozessoren bezeichnet werden und in dem Parallelverarbeitungs-Subsystem 112 enthalten sind, einbezogen werden. In weiteren Ausführungsformen enthält das Parallelverarbeitungs-Subsystem 112 eine Schaltung, die für Universal- und/oder Rechenverarbeitung optimiert ist. Auch hier kann eine solche Schaltung über eine oder mehrere PPUs einbezogen werden, die in dem Parallelverarbeitungs-Subsystem 112 enthalten sind und für Durchführung solcher Universal- und/oder Rechenoperationen konfiguriert sind. In noch weiteren Ausführungsformen können die eine oder mehreren PPUs, die in dem Parallelverarbeitungs-Subsystem 112 enthalten sind, konfiguriert sein, um Grafikverarbeitungs-, Universalverarbeitungs- und Rechenverarbeitungs-Operationen durchzuführen. Der Systemspeicher 104 enthält mindestens einen Gerätetreiber 103, der konfiguriert ist, um die Verarbeitungsoperationen der einen oder mehreren PPUs innerhalb des Parallelverarbeitungs-Subsystems 112 zu verwalten.
In verschiedenen Ausführungsformen kann das Parallelverarbeitungs-Subsystem 112 mit einem oder mehreren der anderen Elemente von 1 zu einem einzigen System integriert sein. Zum Beispiel kann das Parallelverarbeitungs-Subsystem 112 mit der CPU 102 und anderen Verbindungsschaltungen auf einem einzigen Chip integriert sein, um ein Ein-Chip-System (System-on-Chip; SoC) zu bilden.
Im Betrieb ist die CPU 102 der Master-Prozessor des Computersystems 100, der die Operationen anderer Systemkomponenten steuert und koordiniert. Insbesondere gibt die CPU 102 Befehle aus, die den Betrieb von PPUs steuern. In manchen Ausführungsformen ist der Kommunikationsweg 113 eine PCI-Express-Verbindung, bei der jeder PPU dedizierte Lanes zugeteilt sind, wie in der Technik bekannt. Es können auch andere Kommunikationswege verwendet werden. Die PPU implementiert vorteilhaft eine Architektur für hochparallele Verarbeitung. Eine PPU kann mit irgendeiner Menge an lokalem Parallelverarbeitungsspeicher (PP-Speicher) versehen sein.
Man beachte, dass das hier gezeigte System veranschaulichend ist und dass Abweichungen und Modifikationen möglich sind. Die Verbindungstopologie, einschließlich der Anzahl und Anordnung der Brücken, der Anzahl der CPUs 102 und der Anzahl der Parallelverarbeitungs-Subsysteme 112, kann nach Bedarf geändert werden. Zum Beispiel könnte in manchen Ausführungsformen der Systemspeicher 104 direkt und nicht über die Speicherbrücke 105 mit der CPU 102 verbunden sein, und andere Geräte würden über die Speicherbrücke 105 und die CPU 102 mit dem Systemspeicher 104 kommunizieren. In anderen alternativen Topologien kann das Parallelverarbeitungs-Subsystem 112 mit der I/O-Brücke 107 oder direkt mit der CPU 102 und nicht mit der Speicherbrücke 105 verbunden sein. In noch weiteren Ausführungsformen können die I/O-Brücke 107 und die Speicherbrücke 105 in einen einzigen Chip integriert sein, statt als eine oder mehrere diskrete Geräte zu existieren. Schließlich sind in bestimmten Ausführungsformen eine oder mehrere der in 1 gezeigten Komponenten möglicherweise nicht vorhanden. Zum Beispiel könnte der Switch 116 entfernt werden, und der Netzadapter 118 und die Add-in-Karten 120, 121 würden direkt mit der I/O-Brücke 107 verbunden.
2 ist ein Blockdiagramm einer Parallelverarbeitungseinheit (PPU) 202, die in dem Parallelverarbeitungs-Subsystem 112 von 1 enthalten ist, gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung. 2 zeigt zwar eine (Zahlwort) PPU, wie oben angegeben, doch kann das Parallelverarbeitungs-Subsystem 112 eine beliebige Anzahl von PPUs 202 enthalten. Wie gezeigt, ist die PPU 202 mit einem lokalen Parallelverarbeitungsspeicher (PP-Speicher) 204 gekoppelt. Die PPU 202 und der PP-Speicher 204 können mittels einer oder mehrerer integrierten Schaltungen wie z. B. programmierbaren Prozessoren, anwendungsspezifischen integrierten Schaltungen (ASICs) oder Speichergeräten oder auf irgendeine andere technisch machbare Weise implementiert werden.
In manchen Ausführungsformen umfasst die PPU 202 eine Grafikverarbeitungseinheit (GPU), die konfiguriert sein kann, um eine Grafik-Render-Pipeline zu implementieren, um verschiedene Operationen in Bezug auf Erzeugung von Pixeldaten auf Basis der von der CPU 102 und/oder dem Systemspeicher 104 zugeführten Grafikdaten durchzuführen. Beim Verarbeiten von Grafikdaten kann der PP-Speicher 204 als Grafikspeicher verwendet werden, der einen oder mehrere konventionelle Bildpuffer und bei Bedarf auch ein oder mehrere andere Render-Ziele speichert. Unter anderem kann der PP-Speicher 204 verwendet werden, um Pixeldaten zu speichern und zu aktualisieren und End-Pixeldaten oder Anzeigebilder an ein optionales Display-Gerät 110 für Anzeige zu liefern. In manchen Ausführungsformen kann die PPU 202 auch für Universalverarbeitungs- und Rechenoperationen konfiguriert sein. In manchen Ausführungsformen kann das Computersystem 100 eine Servermaschine in einer Cloud-Computing-Umgebung sein. In solchen Ausführungsformen hat das Computersystem 100 möglicherweise kein Display-Gerät 110. Stattdessen kann das Computersystem 100 äquivalente Ausgabeinformationen erzeugen, indem es Befehle in Form von Nachrichten über den Netzadapter 118 über ein Netz sendet.
Im Betrieb ist die CPU 102 in manchen Ausführungsformen der Master-Prozessor des Computersystems 100, der die Operationen anderer Systemkomponenten steuert und koordiniert. Insbesondere gibt die CPU 102 Befehle aus, die den Betrieb der PPU 202 steuern. In manchen Ausführungsformen schreibt die CPU 102 einen Befehlsstrom für die PPU 202 in eine Datenstruktur (weder in 1 noch in 2 explizit gezeigt), die sich im Systemspeicher 104, PP-Speicher 204 oder an einem anderen Speicherort befinden kann, der sowohl für die CPU 102 als auch für die PPU 202 zugänglich ist. Ein Zeiger auf die Datenstruktur wird in eine Befehlswarteschlange, hierin auch als Push-Puffer bezeichnet, geschrieben, um die Verarbeitung des Befehlsstroms in der Datenstruktur zu initiieren. Die PPU 202 liest Befehlsströme aus der Befehlswarteschlange und führt dann Befehle asynchron zum Betrieb der CPU 102 aus. In Ausführungsformen, in denen mehrere Push-Puffer erzeugt werden, können für jeden Push-Puffer von einem Anwendungsprogramm über den Gerätetreiber 103 Ausführungsprioritäten festgelegt werden, um die Ablaufplanung der verschiedenen Push-Puffer zu steuern.
Wie ebenfalls gezeigt, enthält die PPU 202 eine I/O(Eingabe-Ausgabe)-Einheit 205, die mit dem Rest des Computersystems 100 über den Kommunikationsweg 113 und die Speicherbrücke 105 kommuniziert. Die I/O-Einheit 205 erzeugt Pakete (oder andere Signale) für Übertragung auf dem Kommunikationsweg 113 und empfängt auch alle eingehenden Pakete (oder andere Signale) vom Kommunikationsweg 113 und leitet die eingehenden Pakete zu geeigneten Komponenten der PPU 202. Zum Beispiel können Befehle, die sich auf Verarbeitungsaufgaben beziehen, zu einer Hostschnittstelle 206 geleitet werden, während Befehle, die sich auf Speicheroperationen beziehen (z. B. Lesen von dem oder Schreiben in den PP-Speicher 204), zu einer Koppelfeld-Einheit (Crossbar-Einheit) 210 geleitet werden können. Die Hostschnittstelle 206 liest jede Befehlswarteschlange und sendet den in der Befehlswarteschlange gespeicherten Befehlsstrom an eine Vorverarbeitung 212.
Wie oben in Verbindung mit 1 erwähnt, kann die Verbindung der PPU 202 mit dem Rest des Computersystems 100 abgewandelt werden. In manchen Ausführungsformen ist das Parallelverarbeitungs-Subsystem 112, das mindestens eine PPU 202 enthält, als eine Add-In-Karte implementiert, die in einen Erweiterungssteckplatz des Computersystems 100 eingesetzt werden kann. In anderen Ausführungsformen kann die PPU 202 auf einem einzigen Chip mit einer Busbrücke wie z. B. einer Speicherbrücke 105 oder einer I/O-Brücke 107 integriert sein. In noch weiteren Ausführungsformen können auch hier einige oder alle Elemente der PPU 202 zusammen mit der CPU 102 in einer einzigen integrierten Schaltung oder einem Ein-Chip-System (SoC) enthalten sein.
Im Betrieb sendet die Vorverarbeitung 212 von der Hostschnittstelle 206 empfangene Verarbeitungsaufgaben an eine Arbeitsverteilungseinheit (nicht gezeigt) innerhalb der Aufgaben-/Arbeitseinheit 207. Die Arbeitsverteilungseinheit empfängt Zeiger auf Verarbeitungsaufgaben, die als Aufgaben-Metadaten (TMD) kodiert und in Speicher gespeichert sind. Die Zeiger auf TMDs sind in einem Befehlsstrom enthalten, der als eine Befehlswarteschlange gespeichert und durch die Vorverarbeitungseinheit 212 von der Host-Schnittstelle 206 empfangen wird. Verarbeitungsaufgaben, die als TMDs kodiert sein können, enthalten Indizes, die den zu verarbeitenden Daten zugeordnet sind, und außerdem Zustandsparameter und Befehle, die festlegen, wie die Daten zu verarbeiten sind. Zum Beispiel könnten die Zustandsparameter und Befehle das Programm definieren, das an den Daten auszuführen ist. Auch könnten die TMD zum Beispiel die Anzahl und Konfiguration des Satzes von CTAs angeben. Allgemein entspricht jede TMD einer Aufgabe. Die Aufgaben-/Arbeitseinheit 207 empfängt Aufgaben von der Vorverarbeitung 212 und stellt sicher, dass GPCs 208 in einem gültigen Zustand konfiguriert sind, bevor die durch jeweils eine der TMDs spezifizierte Verarbeitungsaufgabe initiiert wird. Für jede TMD, die zum Planen der Ausführung der Verarbeitungsaufgabe verwendet wird, kann eine Priorität spezifiziert werden. Verarbeitungsaufgaben können auch von dem Verarbeitungscluster-Array 230 empfangen werden. Optional kann die TMD einen Parameter enthalten, der steuert, ob die TMD dem Kopf oder dem Ende einer Liste von Verarbeitungsaufgaben (oder einer Liste von Zeigern auf die Verarbeitungsaufgaben) hinzugefügt wird, wodurch eine weitere Ebene von Kontrolle über Ausführungspriorität bereitgestellt wird.
Die PPU 202 implementiert vorteilhaft eine Architektur für hochparallele Verarbeitung auf Basis eines Verarbeitungscluster-Arrays 230, das einen Satz von C Allgemeinverarbeitungsclustern (General Processing Clusters; GPCs) 208 enthält, wobei C ≥ 1. Jeder GPC 208 ist in der Lage, eine große Anzahl (z. B. 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 werden. Die Zuteilung von GPCs 208 kann in Abhängigkeit von der für jede Art von Programm oder Berechnung entstehenden Arbeitsbelastung variieren.
Die Speicherschnittstelle 214 enthält einen Satz D von Partitionseinheiten 215, wobei D ≥ 1. Jede Partitionseinheit 215 ist mit einem oder mehreren dynamischen Direktzugriffsspeichern (DRAMs) 220 gekoppelt, die sich im PPM-Speicher 204 befinden. In manchen Ausführungsformen entspricht die Anzahl der Partitionseinheiten 215 der Anzahl der DRAMs 220, und jede Partitionseinheit 215 ist mit einem anderen DRAM 220 gekoppelt. In anderen Ausführungsformen kann die Anzahl der Partitionseinheiten 215 von der Anzahl der DRAMs 220 verschieden sein. Der Fachmann erkennt, dass ein DRAM 220 durch irgendein anderes technisch geeignetes Speichermedium ersetzt werden kann. Im Betrieb können verschiedene Render-Ziele wie z. B. wie Texturabbildungen und Bildpuffer über DRAMs 220 gespeichert werden, so dass die Partitionseinheiten 215 Teile jedes Render-Ziels parallel schreiben können, um die verfügbare Bandbreite des PP-Speichers 204 effizient zu nutzen.
Ein gegebener GPC 208 kann Daten verarbeiten, die in einen der DRAMs 220 im PP-Speicher 204 geschrieben werden sollen. Die Koppelfeld-Einheit 210 ist konfiguriert, um die Ausgabe jedes GPC 208 zum Eingang irgendeiner Partitionseinheit 215 oder zu einem anderen GPC 208 zur weiteren Verarbeitung zu leiten. Die GPCs 208 kommunizieren über die Koppelfeld-Einheit 210 mit der Speicherschnittstelle 214, um von verschiedenen DRAMs 220 zu lesen oder zu schreiben. In manchen Ausführungsformen weist die Koppelfeld-Einheit 210 eine Verbindung zur I/O-Einheit 205 sowie eine Verbindung zum PP-Speicher 204 über die Speicherschnittstelle 214 auf, wodurch die Verarbeitungskerne innerhalb der verschiedenen GPCs 208 mit dem Systemspeicher 104 oder anderem Speicher, der nicht lokal zur PPU 202 ist, kommunizieren können. In der Ausführungsform von 2 ist die Koppelfeld-Einheit 210 direkt mit der I/O-Einheit 205 verbunden. In verschiedenen Ausführungsformen kann die Koppelfeld-Einheit 210 virtuelle Kanäle verwenden, um Verkehrsströme zwischen den GPCs 208 und den Partitionseinheiten 215 zu trennen.
Auch hier können GPCs 208 programmiert sein, um Verarbeitungsaufgaben in Bezug auf mannigfache Anwendungen auszuführen, einschließlich, aber nicht beschränkt auf lineare und nichtlineare Datentransformationen, Filtern von Video- und/oder Audiodaten, Modellierungsoperationen (z. B. Anwenden von physikalischen Gesetzen zum Ermitteln von Position, Geschwindigkeit und anderen Attributen von Objekten), Bildrender-Operationen (z. B. Tessellierungs-Shader-, Vertex-Shader-, Geometrie-Shader- und/oder Pixel/Fragment-Shader-Programme), allgemeine Rechenoperationen, usw. Im Betrieb ist die PPU 202 konfiguriert, um Daten vom Systemspeicher 104 und/oder PP-Speicher 204 an eine oder mehrere On-Chip-Speichereinheiten zu senden, die Daten zu verarbeiten und Ergebnisdaten zurück in den Systemspeicher 104 und/oder PP-Speicher 204 zu schreiben. Auf die Ergebnisdaten können dann andere Systemkomponenten zugreifen, einschließlich der CPU 102, einer anderen PPU 202 im Parallelverarbeitungs-Subsystem 112 oder eines anderen Parallelverarbeitungs-Subsystems 112 im Computersystem 100.
Wie oben erwähnt, kann eine beliebige Anzahl von PPUs 202 in ein Parallelverarbeitungs-Subsystem 112 aufgenommen werden. Zum Beispiel können mehrere PPUs 202 auf einer einzigen Add-in-Karte bereitgestellt werden, oder mehrere Add-in-Karten können mit dem Kommunikationsweg 113 verbunden werden, oder eine oder mehrere PPUs 202 können in einen Brücken-Chip integriert werden. PPUs 202 in einem Multi-PPU-System können identisch oder voneinander verschieden sein. Zum Beispiel können unterschiedliche PPUs 202 unterschiedliche Anzahlen von Verarbeitungskernen und/oder unterschiedliche Mengen von PP-Speicher 204 aufweisen. In Implementierungen, in denen mehrere PPUs 202 vorhanden sind, können diese PPUs parallel betrieben werden, um Daten mit einem höheren Durchsatz zu verarbeiten als es mit einer einzigen PPU 202 möglich ist. Systeme mit einer oder mehreren PPUs 202 können in mannigfachen Konfigurationen und Formfaktoren implementiert werden, einschließlich, aber nicht beschränkt auf Desktops, Laptops, Hand-PCs oder andere Hand-Geräte, Server, Workstations, Spielkonsolen, eingebettete Systeme und dergleichen.
3 ist ein Blockdiagramm eines Allgemeinverarbeitungsclusters (GPC) 208, der in der Parallelverarbeitungseinheit (PPU) 202 von 2 enthalten ist, gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung. Wie gezeigt, enthält der GPC 208 ohne Beschränkung einen Pipeline-Manager 305, eine oder mehrere Textureinheiten 315, eine PreROP-Einheit 325, ein Arbeitsverteilungs-Koppelfeld 330, einen L1,5-Cache 335 und einen oder mehrere Texturverarbeitungscluster (TPCs) 340. Die TPCs 340, die Textureinheiten 315 und der L1,5-Cache 335 sind mit einer MMU 320 gekoppelt.
Jeder TPC 340 enthält mehrere SMs 310 zusammen mit anderen zugehörigen Schaltungen (nicht gezeigt). In einem Beispiel enthält jeder TPC 340 zwei SMs 310. Die Aufgaben-/Arbeitseinheit 207 startet CTAs, die an die in den verschiedenen GPCs 408 enthaltenen TPCs 340 gerichtet sind. Der Pipeline-Manager 305 empfängt ein gestartetes CTA von der Aufgaben-/Arbeitseinheit 207 und übergibt das CTA wiederum an den geeigneten TPC 340. Der TPC 340 führt dann das CTA auf einem oder mehreren SMs 310 aus, die in dem TPC 340 enthalten sind.
Im Betrieb kann der GPC 208 konfiguriert sein, um eine große Anzahl von Threads parallel auszuführen, um Grafik-, Universalverarbeitungs- und/oder Rechenoperationen durchzuführen. Wie hierin verwendet, bezieht sich ein „Thread“ auf eine Instanz eines bestimmten Programms, das an einem bestimmten Satz von Eingabedaten ausgeführt wird. In manchen Ausführungsformen werden Anweisungserteilungstechniken mit Einzelanweisung und Mehrfachdaten (Single Instruction, Multiple Data; SIMD) verwendet, um parallele Ausführung einer großen Anzahl von Threads zu unterstützen, ohne mehrere unabhängige Anweisungseinheiten bereitzustellen. In anderen Ausführungsformen werden Techniken mit Einzelanweisung und Mehrfach-Thread (Single Instruction, Multiple Thread; SIMT) verwendet, um parallele Ausführung einer großen Anzahl von allgemein synchronisierten Threads zu unterstützen, wobei eine gemeinsame Anweisungseinheit verwendet wird, die konfiguriert ist, um Anweisungen an einen Satz von Verarbeitungsmaschinen innerhalb des GPC 208 auszugeben. Anders als ein SIMD-Ausführungsregime, bei dem alle Verarbeitungsmaschinen typischerweise identische Anweisungen ausführen, ermöglicht SIMT-Ausführung unterschiedlichen Threads, auseinander gehenden Ausführungswegen durch ein gegebenes Programm leichter zu folgen. Der Fachmann erkennt, dass ein SIMD-Verarbeitungsregime einen funktionalen Teilsatz eines SIMT-Verarbeitungsregimes darstellt.
Der Betrieb des GPC 208 wird über einen Pipeline-Manager 305 gesteuert, der von einer Arbeitsverteilungseinheit (nicht gezeigt) innerhalb der Aufgaben-/Arbeitseinheit 207 empfangene Verarbeitungsaufgaben auf einen oder mehrere Streaming-Multiprozessoren (SMs) 310 verteilt. Der Pipeline-Manager 305 kann auch konfiguriert sein, um ein Arbeitsverteilungs-Koppelfeld 330 zu steuern, indem Ziele für von SMs 310 ausgegebene verarbeitete Daten spezifiziert werden.
In verschiedenen Ausführungsformen enthält der GPC 208 einen Satz M von SMs 310, wobei M ≥ 1. Außerdem enthält jeder SM 310 einen Satz von funktionalen Ausführungseinheiten (nicht gezeigt), wie z. B. Ausführungseinheiten und Lade-Speicher-Einheiten. Verarbeitungsoperationen, die für irgendeine der funktionalen Ausführungseinheiten spezifisch sind, können in einer Pipeline behandelt werden, was es ermöglicht, eine neue Anweisung zur Ausführung zu erteilen, bevor eine frühere Anweisung ganz ausgeführt worden ist. Es kann eine beliebige Kombination von funktionalen Ausführungseinheiten innerhalb eines gegebenen SM 310 vorgesehen werden. In verschiedenen Ausführungsformen können die funktionalen Ausführungseinheiten konfiguriert sein, um mannigfache unterschiedliche Operationen zu unterstützen, einschließlich Ganzzahl- und Gleitkomma-Arithmetik (z. B. Addition und Multiplikation), Vergleichsoperationen, booleschen Operationen (AND, OR, XOR), Bitverschiebung und Berechnung von verschiedenen algebraischen Funktionen (z. B. Planarinterpolation und trigonometrische, exponentielle und logarithmische Funktionen usw.). Vorteilhaft ist, dass dieselbe funktionale Ausführungseinheit zur Durchführung von unterschiedlichen Operationen konfiguriert sein kann.
Im Betrieb ist jeder SM 310 konfiguriert, um eine oder mehrere Thread-Gruppen zu verarbeiten. Wie hierin verwendet, bezieht sich eine „Thread-Gruppe“ oder ein „Warp“ auf eine Gruppe von Threads, die gleichzeitig dasselbe Programm an unterschiedlichen Eingabedaten ausführen, wobei ein Thread der Gruppe einer anderen Ausführungseinheit innerhalb einer SM 310 zugewiesen wird. Eine Thread-Gruppe enthält möglicherweise weniger Threads als die Anzahl der Ausführungseinheiten innerhalb des SM 310, in welchem Fall ein Teil der Ausführung während Zyklen, in denen diese Thread-Gruppe verarbeitet wird, möglicherweise untätig ist. Eine Thread-Gruppe kann auch mehr Threads enthalten als die Anzahl der Ausführungseinheiten innerhalb des SM 310, in welchem Fall die Verarbeitung über aufeinander folgende Taktzyklen stattfinden kann. Da jeder SM 310 bis zu G Thread-Gruppen gleichzeitig unterstützen kann, folgt daraus, dass in irgendeinem gegebenen Zeitpunkt bis zu G*M Thread-Gruppen im GPC 208 ausgeführt werden können.
Zusätzlich kann eine Vielzahl von verwandten Thread-Gruppen (in verschiedenen Ausführungsphasen) gleichzeitig innerhalb eines SM 310 aktiv sein. Diese Sammlung von Thread-Gruppen wird hierin als „Kooperativ-Thread-Array“ (Cooperative Thread Array; CTA) oder „Thread-Array“ bezeichnet. Die Größe eines bestimmten CTA ist gleich m*k, worin k die Anzahl der gleichzeitig ausgeführten Threads in einer Thread-Gruppe ist, die typischerweise ein ganzzahliges Vielfaches der Anzahl der Ausführungseinheiten innerhalb des SM 310 ist, und m die Anzahl der gleichzeitig innerhalb des SM 310 aktiven Thread-Gruppen ist. In manchen Ausführungsformen kann eine einzelne SM 310 mehrere CTAs gleichzeitig unterstützen, wobei solche CTAs die Granularität sind, in der Arbeit auf die SMs 310 verteilt wird.
Obwohl in 3 nicht gezeigt, enthält jeder SM 310 einen Level-Eins(L1)-Cache oder verwendet Platz in einem entsprechenden L1-Cache außerhalb des SM 310, um unter anderem Lade- und Speicheroperationen zu unterstützen, die von den Ausführungseinheiten durchgeführt werden. Jeder SM 310 hat auch Zugriff auf Level-Zwei(L2)-Caches (nicht gezeigt), die von allen GPCs 208 in der PPU 202 gemeinsam genutzt werden. Die L2-Caches können zum Übertragen von Daten zwischen Threads verwendet werden. Schließlich haben SMs 310 auch Zugriff auf chipexternen „globalen“ Speicher, der PP-Speicher 204 und/oder Systemspeicher 104 enthalten kann. Man erkennt, dass irgendein Speicher außerhalb der PPU 202 als globaler Speicher verwendet werden kann. Zusätzlich kann, wie in 3 dargestellt, ein Level-Einskommafünf(L1,5)-Cache 335 im GPC 208 enthalten und konfiguriert sein, um Daten zu empfangen und festzuhalten, die vom SM 310 über die Speicherschnittstelle 214 aus Speicher angefordert werden. Diese Daten können ohne Beschränkung Anweisungen, einheitliche Daten und konstante Daten enthalten. In Ausführungsformen mit mehreren SMs 310 innerhalb des GPC 208 können die SMs 310 vorteilhaft gemeinsame Anweisungen und im L1,5-Cache 335 zwischengespeicherte Daten teilen.
Jeder GPC 208 kann eine zugehörige Speicherverwaltungseinheit (MMU) 320 aufweisen, die konfiguriert ist, um virtuelle Adressen auf physische Adressen abzubilden. In verschiedenen Ausführungsformen kann sich die MMU 320 entweder innerhalb des GPC 208 oder innerhalb der Speicherschnittstelle 214 befinden. Die MMU 320 enthält einen Satz von Seitentabelleneinträgen (PTEs), die verwendet werden, um eine virtuelle Adresse auf eine physische Adresse einer Kachel oder Speicherseite abzubilden, und optional einen Cache-Zeilenindex. Die MMU 320 kann Adressen-Übersetzungspuffer (Translation Lookaside Buffers; TLB) oder Caches enthalten, die sich in SMs 310, in einem oder mehreren L1-Caches oder im GPC 208 befinden können.
Bei Grafik- und Rechenanwendungen kann der GPC 208 so konfiguriert sein, dass jeder SM 310 mit einer Textureinheit 315 gekoppelt ist, um Texturabbildungsoperationen durchzuführen, wie z. B. Ermitteln von Texturabtastpositionen, Lesen von Texturdaten und Filtern von Texturdaten.
Im Betrieb sendet jeder SM 310 eine verarbeitete Aufgabe an das Arbeitsverteilungs-Koppelfeld 330, um die verarbeitete Aufgabe einem anderen GPC 208 zur weiteren Verarbeitung bereitzustellen oder um die verarbeitete Aufgabe über die Koppelfeld-Einheit 210 in einem L2-Cache (nicht gezeigt), Parallelverarbeitungsspeicher 204 oder Systemspeicher 104 zu speichern. Darüber hinaus ist eine Pre-Rasteroperationen(preROP)-Einheit 325 konfiguriert, um Daten vom SM 310 zu empfangen, Daten an eine oder mehrere Rasteroperationen(ROP)-Einheiten innerhalb der Partitionseinheiten 215 zu leiten, Optimierungen für Farbmischen durchzuführen, Pixelfarbdaten zu organisieren und Adressenübersetzungen durchzuführen.
Man beachte, dass die hierin beschriebene Kernarchitektur veranschaulichend ist und dass Veränderungen und Modifikationen möglich sind. Unter anderem können beliebig viele Verarbeitungseinheiten wie z. B. SMs 310, Textureinheiten 315 oder preROP-Einheiten 325 in den GPC 208 aufgenommen werden. Darüber hinaus kann die PPU 202, wie oben in Verbindung mit 2 beschrieben, eine beliebige Anzahl von GPCs 208 enthalten, die so konfiguriert sind, dass sie einander funktional ähnlich sind, so dass das Ausführungsverhalten nicht davon abhängt, welcher GPC 208 eine bestimmte Verarbeitungsaufgabe empfängt. Weiterhin arbeitet jeder GPC 208 unabhängig von den anderen GPCs 208 in der PPU 202, um Aufgaben für ein oder mehrere Anwendungsprogramme auszuführen. Angesichts des Vorhergehenden erkennt der Fachmann, dass die in 1-3 beschriebene Architektur den Schutzbereich der vorliegenden Erfindung in keiner Weise beschränkt.
Dynamische Partitionierung von Ausführungsressourcen
Gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung wurde der Rechenarbeitsverteiler (Compute Work Distributer; CWD) innerhalb der GPU so gestaltet, dass er ein guthabenbasiertes System für dynamische Partitionierung und Zuweisung von TPCs 340 zu verschiedenen Subkontexten enthält, die verschiedenen Prozessen zugeordnet sind, die auf der GPU ausgeführt werden. Eine solche Methode führt unter anderem zu einer effektiveren Ressourcenzuteilung zwischen den verschiedenen Prozessen, die auf der GPU ausgeführt werden, und zu einer effizienteren GPU-Ausführung. Ein CPU-Prozess kann einem oder mehreren Subkontexten zugeordnet sein.
Gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung teilt ein GPU-Gerätetreiber während GPU-Initialisierung jedem Subkontext eine Anzahl von TPC-Guthaben zu, wobei jeder Subkontext einem anderen Prozess entspricht und die Anzahl der TPC-Guthaben die maximale Anzahl der TPCs 340 bestimmt, die der Subkontext gleichzeitig verwenden kann. In manchen Ausführungsformen entsprechen die Subkontexte möglicherweise nicht getrennten Prozessen. Zum Beispiel könnte ein bestimmter Prozess mehreren Subkontexten zugeordnet sein. Beim Starten eines neuen CTA für einen bestimmten Subkontext während der Laufzeit teilt der CWD eines der TPC-Guthaben für den entsprechenden Subkontext zu, indem er einen dem Subkontext zugeordneten Guthabenzähler dekrementiert. Der CWD erwirbt den am wenigsten belasteten TPC 340 für nichtexklusive Nutzung durch diesen Subkontext. Beim Erwerben des TPC 340 weist der CWD dem TPC 340 eine virtuelle TPC-Kennung (ID) zu und stellt die virtuelle TPC-ID dem physischen TPC 340 zur Verfügung, zu dem das neue CTA gestartet wird. Der physische TPC 340 verwendet dann die virtuelle TPC-ID, wenn er Lokalspeicheradressen-Berechnungen für das neue CTA durchführt. Spätere CTAs, die zu anderen Subkontexten gehören, haben andere virtuelle TPC-IDs. Im Allgemeinen wird die virtuelle TPC-ID für CTAs verwendet, die einem bestimmten Subkontext zugeordnet sind. Zum Beispiel könnte ein physischer TPC 340 bis zu 64 virtuelle TPC-IDs gleichzeitig haben - eine virtuelle TPC-ID für jeden der 64 Subkontexte. Threads innerhalb von CTAs aus einem bestimmten Subkontext auf einem TPC 340 verwenden die virtuelle TPC-ID dieses Subkontexts für diesen TPC 340, um Lokalspeicheradressen-Berechnungen durchzuführen.
In bestimmten Fällen ermittelt der CWD möglicherweise, dass der am wenigsten belastete TPC 340 bereits erworben wurde oder dass der Subkontext, der das neue CTA startet, keine TPC-Guthaben mehr aufweist. In solchen Fällen startet der CWD einfach das dem Subkontext zugeordnete CTA innerhalb des aktuellen Satzes von erworbenen TPCs 340.
Generell ist der CWD in der Lage, die effizientesten Lastausgleichs-Entscheidungen zu treffen, wenn ein Subkontext, der ein neues CTA startet, verfügbare TPC-Guthaben aufweist. Daher sehen verschiedene Ausführungsformen der vorliegenden Erfindung Techniken zur Freigabe von TPCs 340 und zur Rückgabe von TPC-Guthaben vor, wann immer dies möglich ist. In verschiedenen Ausführungsformen, wenn die TPCs 340 ihre jeweiligen CTAs ausführen, behält der CWD eine Zählung der Anzahl von TPCs 340, die CTAs für jeden Subkontext ausführen. Wenn ein TPC 340 die Ausführung der CTAs für einen gegebenen Subkontext abgeschlossen hat, gibt der CWD die dem bestimmten TPC 340 zugeordnete virtuelle TPC-ID wieder in den Pool von verfügbaren IDs für den Subkontext frei und hebt die Zuteilung des entsprechenden TPC-Guthabens für den Subkontext auf, indem er den dem Subkontext zugeordneten Guthabenzähler inkrementiert.
Der oben beschriebene TPC-Erwerbs- und Freigabemechanismus passt die jedem Subkontext zugeteilten Ressourcen während des Betriebs dynamisch an, was den Gesamt-Lastausgleich und die GPU-Ausführung im Vergleich zu Methoden nach dem Stand der Technik verbessert. Dieser TPC-Erwerbs- und Freigabemechanismus wird nun näher beschrieben.
4 ist eine detailliertere Ansicht der Aufgaben-/Arbeitseinheit von 2 gemäß den verschiedenen Ausführungsformen der vorliegenden Erfindung. Wie gezeigt, enthält die Aufgaben-/Arbeitseinheit 207 ohne Beschränkung einen Scheduler 410 und einen Rechenarbeitsverteiler (Compute Work Distributer; CWD) 420. Wie ebenfalls gezeigt, enthält der CWD 420 einen Lastverteiler 422, N TPC Ressourcen-Tracker (TRTs) 425(0), 425(1), ... 425(N-1), eine TPC-Freigabetabelle 430, eine Lokalspeicher(LMEM)-Block-Indextabelle 432, Guthabenzähler 434, eine Aufgabentabelle 436 und eine prioritätssortierte Aufgabentabelle 438. Jeder der TRTs 425(0), 425(1), ... 425(N-1) kommuniziert mit einem entsprechenden TPC 340(0), 340(1), ... 340(N-1).
Der Scheduler 410 empfängt Aufgaben von der Vorverarbeitung 212 für verschiedene Prozesse, die auf der CPU 102 ausgeführt werden. Jeder Prozess, der auf der CPU ausgeführt wird, gibt solche Aufgaben aus, wobei die für einen bestimmten Prozess ausgegebenen Aufgaben an einen oder mehrere Subkontexte gerichtet sind. Jede Aufgabe entspricht einer Gruppe von CTAs, die für den entsprechenden Subkontext zu starten sind. Im Allgemeinen entspricht jede Aufgabe einem TMD, und jeder TMD entspricht einer Aufgabe. Der Scheduler 410 sendet Aufgaben an den CWD 420. Der CWD 420 wiederum unterhält eine Aufgabentabelle 436, die eine getrennte Aufgabenliste für jeden Subkontext enthält. Die Aufgabentabelle 436 enthält alle Aufgaben, die mindestens ein noch zu startendes CTA oder mindestens ein CTA aufweisen, das gerade ausgeführt wird (hierin als Im-Flug-CTA bezeichnet). Der Scheduler 410 unterhält weiterhin eine prioritätssortierte Aufgabentabelle 438, die alle Aufgaben enthält, die mindestens ein noch zu startendes CTA aufweisen. Die Aufgaben in der prioritätssortierten Aufgabentabelle 438 werden nach Ankunftszeit am CWD 420, nach einem spezifizierten Prioritätswert oder nach einer Kombination von Ankunftszeit und Prioritätswert sortiert. In einem Beispiel könnten Aufgaben in der prioritätssortierten Aufgabentabelle 438 zuerst nach den spezifizierten Prioritätswerten sortiert werden. Dann könnte jede Gruppe von Aufgaben mit dem gleichen spezifizierten Prioritätswert nach Ankunftszeit sortiert werden. Wenn eine Aufgabe vom Scheduler empfangen wird, wird die Aufgabe in die Aufgabentabelle 436 gesetzt. Die Aufgabe wird auch in der geeigneten Position entsprechend der Ankunftszeit und/oder dem spezifizierten Prioritätswert in die prioritätssortierte Aufgabentabelle 438 gesetzt. Sobald alle CTAs für eine bestimmte Aufgabe gestartet worden sind, wird die Aufgabe aus der prioritätssortierten Aufgabentabelle 438 entfernt. Die bestimmte Aufgabe bleibt jedoch in der Aufgabentabelle 436, solange ein oder mehrere CTAs Im-Flug-CTAs sind. Nachdem alle CTAs für die bestimmte Aufgabe abgeschlossen worden sind, bleiben keine Im-Flug-CTAs mehr für die bestimmte Aufgabe übrig. Die bestimmte Aufgabe wird dann aus der Aufgabentabelle 436 entfernt.
Die auf der CPU 102 ausgeführten Prozesse senden weiter neue Aufgaben für verschiedene Subkontexte über die Vorverarbeitung 212 an den Scheduler 410. Der Scheduler 410 sendet solche Aufgaben an den CWD 420. Der CWD 420 wiederum fügt diese neuen Aufgaben der Aufgabentabelle 436 und der prioritätssortierten Aufgabentabelle 438 hinzu. Jede von einem Prozess ausgegebene Aufgabe enthält ein oder mehrere Kooperativ-Thread-Arrays (CTAs), die für Ausführung auf den TPCs 340 zu starten sind. Im Allgemeinen kann eine bestimmte Aufgabe nur ein CTA oder bis zu mehreren tausend CTAs enthalten. Im Betrieb wählt der CWD 420 eine Aufgabe aus der prioritätssortierten Aufgabentabelle 438 aus und weist die Aufgabe einem oder mehreren TRTs 425 zu. Dann kommuniziert jeder der einen oder mehreren TRTs 425 mit dem entsprechenden TPC 340, um die Anzahl der freien Slots auf jedem der entsprechenden TPCs 340 zu ermitteln. Dann wählt der Lastverteiler 422 in jedem Zyklus den TRT 425 mit der größten Anzahl freier Slots aus, und der ausgewählte TRT 425 startet ein CTA aus der Aufgabe zu dem TPC 340, der diesem TRT 425 entspricht. Die TRTs 425 verfolgen freie Slots, wenn CTAs gestartet und abgeschlossen werden, wodurch der Lastverteiler 422 einen TRT 425 für den nächsten CTA-Start auswählen kann.
In verschiedenen Ausführungsformen kann die PPU 202 konfiguriert sein, um CTAs für irgendeine technisch mögliche Anzahl von Subkontexten auf irgendeiner technisch möglichen Anzahl von TPCs 340 auszuführen. In einem Beispiel könnte die PPU 202 konfiguriert sein, um CTAs für bis zu 64 Subkontexte auf bis zu 42 TPCs 340 auszuführen. Die 42 TPCs 340 könnten auf 7 GPCs 408 verteilt sein, wobei jeder GPC 408 6 TPCs 340 enthält. Dementsprechend würde der CWD 420 42 TRTs 425 enthalten. In einem weiteren Beispiel könnte die PPU 202 konfiguriert sein, um CTAs für bis zu 16 Subkontexte auf bis zu 14 TPCs 340 auszuführen. Die 14 TPCs 340 könnten auf 7 GPCs 408 verteilt sein, wobei jeder GPC 408 2 TPCs 340 enthält. Dementsprechend würde der CWD 420 14 TRTs 425 enthalten.
Auch hier enthält der CWD 420 ohne Beschränkung einen Lastverteiler 422 und mehrere TPC Ressourcen-Tracker (TRTs) 425(0), 425(1), ... 425(N-1). Während jedes Taktzyklus der PPU 202 wählt der Lastverteiler 422 im CWD 420 eine Aufgabe aus der prioritätssortierten Aufgabentabelle 438 aus, die mindestens ein CTA enthält, das auf einem der TPCs 340(0), 340(1), ... 340(N-1) zu starten ist. Der Lastverteiler 422 ermittelt auf Basis der TPC-Freigabetabelle 430 die TPCs 340, auf welchen die CTAs für die ausgewählte Aufgabe zur Ausführung freigegeben werden. Im Allgemeinen wählt der Lastverteiler 422 die Aufgabe mit der höchsten Priorität aus, die für Ausführung auf einem oder mehreren TPCs 340 geeignet ist. Danach weist der Lastverteiler 422 die Aufgabe allen verfügbaren TRTs 425 zu. Jeder verfügbare TRT 425 sendet eine Anforderung an den entsprechenden TPC 340, die die Anzahl der verfügbaren Slots anfordert. Jeder verfügbare TRT 425 empfängt eine Nachricht von dem entsprechenden TPC 340, wobei die Nachricht die Anzahl der freien Slots kennzeichnet, die zur Ausführung von CTAs auf dem entsprechenden TPC 340 zur Verfügung stehen. Jeder verfügbare TRT 425 sendet dann eine Nachricht an den Lastverteiler 422, hierin als „Ressourcenangebot“ bezeichnet, welche die Anzahl der freien Ausführungs-Slots enthält. Wenn zum Beispiel jeder TPC 340 vier Ausführungs-Slots hat, würde ein TRT 425 für einen TPC 340, der gegenwärtig keine CTAs ausführt, einen Wert von vier senden. Ein TRT 425 für einen TPC 340, der gegenwärtig ein CTA ausführt, würde einen Wert von drei senden, und so weiter. Jeder verfügbare TRT 425, der einem TPC 340 mit verfügbaren Slots entspricht, sendet ein Ressourcenangebot an den Lastverteiler 422, das die Anzahl der verfügbaren CTA-Ausführungs-Slots enthält.
Nach Empfang der Ressourcenangebote wählt der Lastverteiler 422 einen TPC 340 zur Ausführung des aktuellen CTA auf Basis der Ressourcenangebote von den TRTs 425 aus. Insbesondere wählt der Lastverteiler 422 auf Basis des TPC 340, der die höchste Anzahl verfügbarer CTA-Ausführungs-Slots aufweist, einen TPC 340 aus, um das aktuelle CTA auszuführen. Im Allgemeinen weist der TPC 340 mit der höchsten Anzahl verfügbarer CTA-Ausführungs-Slots eine Verarbeitungslast auf, die kleiner als die anderen TPCs 340 zugeordnete Prozessorlast ist. Wenn mehr als ein TPC 340 die gleiche Anzahl verfügbarer Slots aufweist, kann der Lastverteiler 422 irgendeinen der TPCs 340 auswählen, der die höchste Anzahl verfügbarer Slots aufweist. Der Lastverteiler 422 dekrementiert den Guthabenzähler 434 für den Subkontext entsprechend der Aufgabe. Der Lastverteiler 422 hebt dann die Zuweisung der Aufgabe zu den verfügbaren TRTs 425 auf, die der Lastverteiler 422 nicht ausgewählt hat. Der ausgewählte TRT 425 sendet dann CTAs für die Aufgabe an den entsprechenden TPC 340.
Im Allgemeinen kann eine Aufgabe einem bestimmten TRT 425 zugewiesen werden, wenn der gegebene TRT 425 gegenwärtig keiner anderen Aufgabe zugewiesen ist und der Subkontext für die Aufgabe mindestens ein Guthaben aufweist, wie in dem entsprechenden Guthabenzähler 434 widergespiegelt. Wie hierin näher beschrieben, kennzeichnet die TPC-Freigabetabelle 430 für jeden Subkontext, welche TPCs 340 zur Verfügung stehen, um CTAs für den bestimmten Subkontext auszuführen. Wie ebenfalls hierin näher beschrieben, unterhält der CWD 420 auch die LMEM-Block-Indextabelle 432, die hierin auch als Lokalspeicher(LMEM)-Block-Zuweisungstabelle bezeichnet wird, die die Speicherblöcke kennzeichnet, die für jeden Subkontext und jeden TPC 340 als lokaler Speicher dienen sollen.
Jeder der TRTs 425 führt verschiedene Operationen durch, um die Ausführung von CTAs auf den entsprechenden TPCs 340 zu verwalten. Jeder TRT 425 unterhält eine Zählung der Gesamtzahl der Ausführungs-Slots auf dem entsprechenden TPC 340. Ebenso unterhält jeder TRT 425 eine Zählung der Anzahl der Ausführungs-Slots auf dem entsprechenden TPC 340, die gegenwärtig CTAs ausführen. Der Unterschied zwischen diesen beiden Zählungen besteht in der Anzahl der Ausführungs-Slots, die zur Ausführung von hereinkommenden CTAs zur Verfügung stehen. In manchen Ausführungsformen können Aufgaben, deren CTAs unterschiedliche Mengen von TPC-Ressourcen verbrauchen, unterschiedliche Anzahlen von Ausführungs-Slots aufweisen.
Wenn ein TRT 425 ein CTA vorbereitet, auf dem entsprechenden TPC 340 zu starten, bereitet der TRT 425 ein Startpaket vor, das das CTA enthält. Das Startpaket enthält auch die Subkontext-Anzahl für den Subkontext entsprechend dem CTA. Die PPU 202 unterhält eine getrennte Seitenverzeichnis-Basisadresse für jeden Subkontext, so dass jeder Subkontext einen getrennten virtuellen Speicheradressraum haben kann. Der TRT 425 sendet dann das vorbereitete Startpaket zur Ausführung an den TPC 340. Der TRT 425 ermittelt weiterhin, ob ein Lokalspeicherblock zugewiesen worden ist und für den Subkontext auf diesem bestimmten TPC 340 gültig ist. Wenn nicht, wird dem TRT 425 ein Lokalspeicherblock zugewiesen und die LMEM-Block-Indextabelle 432 entsprechend aktualisiert. Dementsprechend enthält das Startpaket Lokalspeicher-Zuweisungsinformationen für das CTA, so dass der TPC 340 die zugewiesenen Lokalspeicherblöcke lokalisieren kann. In manchen Ausführungsformen kann die virtuelle TPC-ID die gleiche sein wie ein Lokalspeicherblock-Index, wobei der Lokalspeicherblock-Index einen Bereich innerhalb von Speicher auswählt, der für Verwendung durch einen Subkontext als lokaler Speicher zugeteilt ist.
Wenn ein TPC 340 ein Startpaket von einem TRT 425 empfängt, lädt der TPC 340 das CTA in das Startpaket und bereitet das CTA zur Ausführung vor. Der TPC 340 ruft die Subkontext-Anzahl aus dem Startpaket ab und weist den TPC 340 an, beim Ausführen des CTA auf die dem Subkontext entsprechenden Zustandsdaten zuzugreifen. Jeder der TPCs 340 unterhält getrennte Zustandsdaten für jeden Subkontext. In einem Beispiel, wenn die PPU 202 64 Subkontexte unterstützt, unterhält jeder TPC 340 64 Instanzen von Zustandsdaten, eine Instanz von Zustandsdaten für jeden der 64 Subkontexte. In einem weiteren Beispiel, wenn die PPU 202 16 Subkontexte unterstützt, unterhält jeder TPC 340 16 Instanzen von Zustandsdaten, eine Instanz von Zustandsdaten für jeden der 16 Subkontexte. Der TPC 340 verwendet die Subkontext-Anzahl, um die Seitenverzeichnis-Basisadresse abzurufen und auf die Seitentabelle zuzugreifen, die dem virtuellen Adressraum entspricht, der dem Subkontext entspricht. Schließlich ruft der TPC 340 die Lokalspeicher-Zuweisungsinformationen aus dem Startpaket ab und weist den TPC 340 an, auf die entsprechenden Lokalspeicherblöcke zuzugreifen.
In manchen Ausführungsformen kann die Zuordnung zwischen einer Subkontext-Anzahl und einer Seitenverzeichnisbasis in einer Speicherverwaltungseinheit wie z. B. der MMU 320 unterhalten werden, wobei die Speicherverwaltungseinheit für das Abbilden von virtueller Adresse auf physische Adresse verantwortlich ist.
Der Prozess zum Starten von CTAs zur Ausführung auf TPCs 340 im Auftrag verschiedener Prozesse, die auf der CPU 102 ausgeführt werden, wird nun näher beschrieben.
Im Betrieb haben Mehrfachprozesse, die auf der CPU 102 ausgeführt werden, verschiedene Aufgaben, die die PPU 202 durchführen soll. Unter der Annahme, dass die einem bestimmten CPU-Prozess zugeordneten Aufgaben nicht alle Ressourcen der PPU 202 verbrauchen, werden die Ressourcen der PPU 202 nicht vollständig von einem einzigen Prozess genutzt, der auf der PPU 202 ausgeführt wird. Weiterhin führt die PPU 202 in einem Kontext nach dem anderen aus. Dadurch teilen sich alle Aufgaben für alle Prozesse, die auf der PPU 202 in einem gegebenen Zeitpunkt ausgeführt werden, bestimmte Funktionen. Diese geteilten Funktionen umfassen Kontextplanung und Fehlerisolierung. Wie hierin näher beschrieben, bringt die PPU 202 jedoch mehrere Subkontexte innerhalb eines gegebenen Kontexts unter, wobei jeder Subkontext einen eindeutigen virtuellen Adressraum und eindeutige Zustandsdaten aufweist. Folglich haben Subkontexte innerhalb eines Kontexts getrennte virtuelle Adressräume und getrennte Zustandsdaten. Die Subkontexte innerhalb eines Kontexts werden jedoch gemeinsam geplant und durchlaufen gemeinsam Kontextwechsel, wie hierin näher beschrieben.
Um getrennte virtuelle Adressräume für jeden Subkontext unterzubringen, unterhält der CWD 420 Subkontext-Anzahlen, die jeweils einer Seitenverzeichnis-Basisadresse entsprechen, wobei jede Seitenverzeichnis-Basisadresse auf eine bestimmte Seitentabelle zeigt. Um eindeutige Zustandsdaten für jeden Subkontext unterzubringen, unterhält die gesamte PPU 202 für jeden Subkontext eine getrennte Instanz der Zustandsdaten. Insbesondere unterhält jeder der TPCs 340 für jeden Subkontext eine getrennte Instanz der Zustandsdaten. Beim Starten eines CTA zur Ausführung auf einem bestimmten TPC 340 enthält ein TRT 425 die entsprechende Subkontext-Anzahl in dem an den TPC 340 gesendeten Startpaket. Als Antwort greift der TPC 340 beim Ausführen des CTA entsprechend der Subkontext-Anzahl auf die korrekte Instanz von Zustandsdaten zu.
In manchen Ausführungsformen könnten, auch wenn jeder Subkontext einen anderen virtuellen Adressraum hat, zwei oder mehr Subkontexte auf den gleichen virtuellen Adressraum gesetzt werden, indem die Seitenverzeichnis-Basisadresse für die zwei oder mehr Subkontexte auf dieselbe Adresse gesetzt wird. Auf diese Weise teilen sich die zwei oder mehreren Subkontexte den gleichen virtuellen Adressraum, haben aber getrennte Zustandsdaten. Zum Beispiel könnten bestimmte Subkontexte, die sich auf Grafikfunktionen beziehen, und bestimmte andere Subkontexte, die sich auf Rechenfunktionen beziehen, mit demselben virtuellen Adressraum, aber mit getrennten Zustandsdaten ausführen.
Der Lastverteiler 422 im CWD 420 unterhält eine TPC-Freigabetabelle 430 und eine LMEM-Block-Indextabelle 432. Im Betrieb initialisiert oder aktualisiert der Lastverteiler 422 oder ein auf der CPU 102 ausgeführtes Betriebssystem oder Hypervisor die TPC-Freigabetabelle 430. Der Lastverteiler 422, das Betriebssystem oder der Hypervisor kann die TPC-Freigabetabelle 430 initialisieren oder aktualisieren, wenn die PPU 202 initialisiert wird, ein Kontext initialisiert wird oder sich die PPU 202 anderweitig in einem untätigen Zustand befindet. Darüber hinaus kann der Lastverteiler 422, das Betriebssystem oder der Hypervisor Zellen innerhalb der TPC-Freigabetabelle 430 für bestimmte Subkontextzeilen aktualisieren, wenn diese Subkontexte gegenwärtig untätig sind. In manchen Ausführungsformen werden Subkontextzeilen für Subkontexte, die gegenwärtig nicht untätig sind, möglicherweise nicht aktualisiert, um das Design zu vereinfachen, indem Lese-/Schreibkonflikte verhindert werden. Weiterhin kann der Lastverteiler 422, das Betriebssystem oder der Hypervisor Zellen innerhalb der TPC-Freigabetabelle 430 für bestimmte Subkontext-Spalten aktualisieren, wenn diese TPCs 340 gegenwärtig im Leerlauf sind. Auch hier werden in manchen Ausführungsformen Subkontext-Spalten für TPCs 340, die gegenwärtig nicht untätig sind, möglicherweise nicht aktualisiert, um das Design zu vereinfachen, indem Lese-/Schreibkonflikte verhindert werden.
Die TPC-Freigabetabelle 430 enthält eine Zeile pro Subkontext und eine Spalte pro TPC 340. Ein Wert von ‚1‘ in der Zelle der TPC-Freigabetabelle 430 zeigt an, dass der Subkontext, der der Zeile entspricht, in der die Zelle liegt, auf dem TPC 340 ausgeführt werden darf, der der Spalte entspricht, in der die Zelle liegt. Ein Wert von ‚0‘ in der Zelle der TPC-Freigabetabelle 430 zeigt an, dass der Subkontext, der der Zeile entspricht, in der die Zelle liegt, nicht auf dem TPC 340 ausgeführt werden darf, der der Spalte entspricht, in der die Zelle liegt.
Die LMEM-Block-Indextabelle 432 enthält auch eine Zeile pro Subkontext und eine Spalte pro TPC 340. Jede Zelle in der LMEM-Block-Indextabelle 432 enthält eine virtuelle TPC-Kennung, die den virtuellen TPC kennzeichnet, der dem bestimmten Subkontext zugewiesen ist, entsprechend der Zeile der LMEM-Block-Indextabelle 432. Jede Zelle in der LMEM-Block-Indextabelle 432 kennzeichnet weiterhin den physischen TPC 340, der der Spalte der LMEM-Block-Indextabelle 432 entspricht, die den virtuellen TPC für den Subkontext ausführt. Darüber hinaus kennzeichnet die virtuelle TPC-Kennung einen entsprechenden Lokalspeicherblock in dem Lokalspeicher, der an den physischen TPC 340 entsprechend der Spalte der LMEM-Block-Indextabelle 432 für den Subkontext entsprechend der Zeile der LMEM-Block-Indextabelle 432 gebunden ist. Auf diese Weise kennzeichnet die LMEM-Block-Indextabelle 432 alle gegenwärtig aktiven TPCs 340 für alle Subkontexte und die Positionen für die entsprechenden Lokalspeicherblöcke. Man beachte, dass ein Lokalspeicherblock im Allgemeinen nicht gleichzeitig von zwei verschiedenen TPCs 340 verwendet wird, um zu verhindern, dass zwei TPCs an die gleiche Speicherposition schreiben, was zu Speicherbeschädigung führen würde. Ein einem bestimmten TPC 340 zugewiesener Lokalspeicherblock kann jedoch von jedem SM 310 innerhalb des TPC 340 verwendet werden. Weiterhin werden LMEM-Blöcke zusammenhängend zugewiesen, wobei die virtuellen TPC-Kennungen in der LMEM-Block-Indextabelle 432 von 0 bis zur maximalen Guthabenzählung (wie anfänglich in den Guthabenzählern 434 gespeichert) minus 1 reichen. Wenn ein TPC 340 schließlich alle CTAs für einen bestimmten Subkontext abgeschlossen hat und untätig wird, werden die entsprechenden Lokalspeicherblöcke für Neuzuweisung freigegeben. Weiterhin wird der Guthabenzähler 434 für den Subkontext um eins inkrementiert. Wenn der Subkontext einen CTA-Start zu dem gleichen TPC 340 startet, bevor der Lokalspeicherblock freigegeben ist, führt das CTA auf dem TPC 340 aus, ohne dass der Lokalspeicherblock neu zugewiesen werden muss.
Die PPU 202 kann in drei verschiedenen Modi betrieben werden: statische TPC-Partitionierung, dynamische TPC-Partitionierung und hybride statische/dynamische TPC-Partitionierung. Statische TPC-Partitionierung, dynamische TPC-Partitionierung und hybride statische/dynamische TPC-Partitionierung werden hierin auch als statische Ressourcenzuteilung, dynamische Ressourcenzuteilung bzw. hybride statische/dynamische Zuteilung bezeichnet. Bei statischer TPC-Partitionierung initialisiert und aktualisiert das Betriebssystem oder der Hypervisor sowohl die TPC-Freigabetabelle 430 als auch die LMEM-Block-Indextabelle 432. In manchen Ausführungsformen in Bezug auf TPC-Partitionierung kann der CWD 420 die LMEM-Block-Indextabelle 432 initialisieren und aktualisieren. In manchen Ausführungsformen kann die Anzahl der LMEM-Blockindizes gleich der Anzahl der TPCs 340 sein, so dass das Abbilden nicht dynamisch geändert wird. Jeder Subkontext wird statisch zugewiesen, um auf bestimmten TPCs 340 auszuführen. Weiterhin wird jeder TPC 340 für jeden Subkontext bestimmten virtuellen TPC-Kennungen zugewiesen, so dass jeder Subkontext statisch zugewiesene Lokalspeicherblöcke für jeden TPC 340 aufweist. In manchen Ausführungsformen von statischer TPC-Partitionierung wird die Guthabenzählung nicht verwendet, da virtuelle TPC-Kennungen nicht geändert werden.
Bei dynamischer TPC-Partitionierung initialisiert und aktualisiert das Betriebssystem oder der Hypervisor die TPC-Freigabetabelle 430, während der CWD 420 die LMEM-Block-Indextabelle 432 dynamisch aktualisiert, auf Basis der eingehenden Aufgaben und der aktuellen Belastung der TPCs 340. Jeder Subkontext empfängt eine anfängliche Guthabenzählung, die die maximale Anzahl von TPCs 340 angibt, auf die der Subkontext in irgendeinem gegebenen Zeitpunkt zugreifen kann. Der Lastverteiler 422 im CWD 420 lädt diese anfängliche Guthabenzählung für jeden Subkontext in den Guthabenzähler 434. Wenn die anfängliche Guthabenzählung zum Beispiel drei beträgt, kann jeder Subkontext gleichzeitig CTAs auf bis zu drei TPCs 340 ausführen. Ein bestimmter Subkontext könnte auf irgendwelchen drei verfügbaren TPCs 340 ausführen, wobei die verfügbaren TPCs 340 durch die TPC-Freigabetabelle 430 gekennzeichnet werden. Nach dem Start eines CTA für einen bestimmten TPC 340 dekrementiert der Lastverteiler 422 den Guthabenzähler 434 für den entsprechenden Subkontext.
Bei hybrider statisch-dynamischer TPC-Partitionierung ist jeder Subkontext gezwungen, auf einem bestimmten Teilsatz der Gesamtzahl der TPCs 340 auszuführen. Innerhalb des spezifizierten Teilsatzes von TPCs 340 kann der Subkontext CTAs auf irgendwelchen der TPCs 340 ausführen, die in dem Teilsatz von TPCs 340 enthalten sind, und irgendwelche Lokalspeicherblöcke in lokalem Speicher zuweisen, die dem gleichen Teilsatz von TPCs 340 entsprechen, vorbehaltlich einer maximalen Guthabenzählung für den gegebenen Subkontext.
Bei statischer TPC-Partitionierung, dynamischer TPC-Partitionierung über eine Guthabenzählung und hybrider statisch-dynamischer TPC-Partitionierung über eine Guthabenzählung kann die Anzahl der TPCs 340, die jeder Subkontext gleichzeitig verwenden kann, begrenzt werden. Dementsprechend kann auch die Anzahl der Lokalspeicherblöcke, die jedem Subkontext auf einmal zugewiesen werden können, begrenzt werden.
In manchen Ausführungsformen kann die PPU 202 in einem partiellen dynamischen Modus betrieben werden. In solchen Ausführungsformen kann jeder Subkontext einem Teil der Gesamtzahl der TPCs 340 zugewiesen werden. Innerhalb des zugewiesenen Teils der TPCs 340 kann jedoch jeder Subkontext auf irgendwelchen spezifischen TPCs 340 bis zu der im Guthabenzähler 434 gespeicherten anfänglichen Guthabenzählung ausführen. Wenn zum Beispiel eine PPU 202 64 Subkontexte und 42 TPCs 340 unterstützt, könnte die TPC-Freigabetabelle 430 spezifizieren, dass jeder der Subkontexte 0 bis 31 auf irgendwelchen TPCs von 0 bis 20 ausführen könnte und jeder der Subkontexte 32 bis 63 auf allen TPCs von 21 bis 42 ausführen könnte. Wenn jeder Subkontext eine anfängliche Guthabenzählung von 3 empfängt, könnte jeder der Subkontexte 0 bis 31 auf irgendwelchen 3 TPCs von 0 bis 20 ausführen. Ebenso könnte jeder der Subkontexte 32 bis 63 auf irgendwelchen 3 TPCs von 21 bis 42 ausführen.
Im Allgemeinen werden CTAs auf dem verfügbaren TPC 340 gestartet, der gegenwärtig die geringste Arbeitslast aufweist, innerhalb der Grenzen der Anzahl der Guthaben, die der Subkontext hat, und der statischen TPC-Freigabetabelle 430, die den verfügbaren Satz von TPCs 340 für jeden Kontext kennzeichnet. Diese Methode kann verbesserte Fairness beim Planen und Zuteilen im Vergleich zu früheren Methoden bieten.
Als ein besonderes Beispiel betrachte man eine PPU 202, die konfiguriert ist, um Aufgaben für zwei Subkontexte zu empfangen, die auf vier TPCs 340 ausführen. Die prioritätssortierte Aufgabenliste 438 enthält drei Aufgaben: eine erste Aufgabe für Subkontext 0, eine erste Aufgabe für Subkontext 1 und eine zweite Aufgabe für Subkontext 0, in der Reihenfolge abnehmender Priorität. Jeder Subkontext empfängt eine anfängliche Guthabenzählung von drei. Der Lastverteiler 422 oder andere Hard- und/oder Software auf der CPU 102 initialisiert den Guthabenzähler 434 für jeden Subkontext mit einem Wert von drei und zeigt damit an, dass jeder Subkontext gleichzeitig CTAs auf bis zu drei der vier TPCs ausführen kann. Nach Initialisierung empfängt der Scheduler 410 die drei Aufgaben und sendet die Aufgaben an den CWD 420. Der Lastverteiler 422 im CWD 420 empfängt die Aufgaben, wobei jede der Aufgaben einem Satz von einem oder mehreren CTAs entspricht. Der Lastverteiler 422 speichert die empfangenen Aufgaben in der Aufgabentabelle 436 und der prioritätssortierten Aufgabentabelle 438. Da im Subkontext 0 Guthaben verfügbar sind und keiner der TRTs 425 gegenwärtig eine Aufgabe hat, ordnet der Lastverteiler 422 die empfangene erste Aufgabe für Subkontext 0 allen TRTs 425 als eine in Frage kommende Aufgabe zu. Jeder TRT 425, der eine in Frage kommende Aufgabe hat, kommuniziert mit den TRTs 425 entsprechend TPC 340 und empfängt eine Anzahl freier Slots. Unter der Annahme, dass alle TPCs 340 vier freie Slots aufweisen, sendet jeder TRT 425 ein Ressourcenangebot an den Lastverteiler 422, das angibt, dass vier Ausführungs-Slots verfügbar sind. Nach Empfang der Ressourcenangebote wählt der Lastverteiler 422 auf Basis der Ressourcenangebote von den TRTs 425 einen TRT 425 aus, um das CTA zu dem entsprechenden TPC 340 zu starten. Der ausgewählte TRT 425 bereitet ein Startpaket für das CTA vor und sendet das Startpaket an den TPC 340. Ist noch kein Lokalspeicherblock zugewiesen, was in diesem Zeitpunkt des Beispiels der Fall ist, so weist der TRT 425 einen Lokalspeicherblock für das auf dem TPC 340 ausgeführte CTA zu. Der Lastverteiler 422 dekrementiert den Guthabenzähler 434 für Subkontext 0 von 3 auf 2. Dieser Prozess geht weiter, um den nächsten TRT 425 auszuwählen, um ein CTA zu starten, wodurch der Lastverteiler 422 den Guthabenzähler 434 für Subkontext 0 von 2 auf 1 dekrementiert. Dieser Prozess geht mit der Auswahl des nächsten TRT 425 weiter, um das CTA zu starten, wodurch der Lastverteiler 422 den Guthabenzähler 434 für Subkontext 0 von 1 auf 0 dekrementiert. In diesem Zeitpunkt verwendet der Lastverteiler 422 den vierten TRT 425 für Subkontext 0 möglicherweise nicht, so dass die Zuweisung der Aufgabe zu dem vierten TRT 425 aufgehoben wird, was den TRT 425 für eine Aufgabe von einem anderen Subkontext verfügbar macht.
Der Lastverteiler 422 wählt nun die erste Aufgabe für Subkontext 1 aus der prioritätssortierten Aufgabentabelle 438 aus. Da der Subkontext 0 keine übrigen Guthaben hat und es einen verfügbaren TRT 425 gibt, wählt der Scheduler die Aufgabe für Subkontext 1 aus und weist die Aufgabe dem übrigen TRT 425 zu. Dieser TRT 425 startet dann CTAs auf dem entsprechenden TPC 340, und der Lastverteiler 340 dekrementiert den Guthabenzähler 434 für Subkontext 1 von 3 auf 2. Wenn Subkontext 0 und Subkontext 1 nicht exklusiv sind, dann kann, wenn alle CTAs für die erste Aufgabe gestartet worden sind und die Zuweisung der ersten Aufgabe zu den drei TRTs 425 aufgehoben worden ist, die Aufgabe für Subkontext 1 bis zu zwei weitere TRTs 425 zusätzlich zu dem einen TRT 425 verwenden, den die Aufgabe gegenwärtig aufweist. Wenn Subkontext 0 und Subkontext 1 exklusiv sind, dann wartet Subkontext 1, bis mindestens ein TPC 340 die Ausführung aller CTAs für Subkontext 0 abgeschlossen hat, und kann dann die Aufgabe von Subkontext 1 einem der ersten drei TRTs 425 zugewiesen bekommen, die die Ausführung aller CTAs für Subkontext 0 abgeschlossen haben.
Der Lastverteiler 422 wählt nun die zweite Aufgabe für Subkontext 0 aus der prioritätssortierten Aufgabentabelle 438 aus. Subkontext 0 hat Null Guthaben, so dass die zweite Aufgabe für Subkontext 0 wartet, bis alle CTAs für die erste Aufgabe für Subkontext 0 gestartet sind, auch wenn es einen verfügbaren TRT 425 gibt. Wenn alle CTAs von der ersten Aufgabe für Subkontext 0 gestartet sind, wird die Zuweisung der Aufgabe zu den TRTs 425 aufgehoben, so dass die TRTs für eine neue Aufgabe zur Verfügung stehen.
Wenn ein TPC 340 die Ausführung von CTAs für eine bestimmte Aufgabe abschließt, hängt das Verhalten des Lastverteilers 422, der TRTs 425 und der TPCs 340 vom aktuellen Status für alle Aufgaben in der prioritätssortierten Aufgabentabelle 438 ab. In Fortführung des obigen Beispiels betrachte man eine Situation, in der drei der vier TPCs 340 CTAs für die erste Aufgabe für Subkontext 0 ausführen, während einer der vier TPCs 340 CTAs für die erste Aufgabe für Subkontext 1 ausführen. Der aktuelle Wert der Guthabenzähler 434 für Subkontext 0 und Subkontext 1 ist 0 bzw. 2. Der zweite TPC 340 der drei TPCs 340, der CTAs für die erste Aufgabe für Subkontext 0 ausführt, beendet die Ausführung aller CTAs.
In einem ersten Szenario hat die erste Aufgabe für Subkontext 0 zusätzliche CTAs zu starten. In diesem ersten Szenario startet der TRT 425, der dem zweiten TPC 340 entspricht, zusätzliche CTAs für die erste Aufgabe für Subkontext 0 zu dem zweiten TPC 340. In einem zweiten Szenario sind alle CTAs für die erste Aufgabe für Subkontext 0 gestartet worden. Daher ist die erste Aufgabe für Subkontext 0 aus der prioritätssortierten Aufgabentabelle 438 entfernt worden. In diesem zweiten Szenario hat die erste Aufgabe für Subkontext 1 zusätzliche CTAs zu starten. Der Lastverteiler 422 inkrementiert den Guthabenzähler 435 für Subkontext 0 von 0 auf 1. Der Lastverteiler 422 weist die erste Aufgabe für Subkontext 1 allen verfügbaren TRTs 425 zu. Der Lastverteiler 422 wählt einen der verfügbaren TRTs 425 aus. Der ausgewählte TRT 425 kann der TRT 425 sein, der dem zweiten TPC 340 zugeordnet ist, oder kann alternativ der TRT 425 sein, der irgendeinem anderen TPC 340 zugeordnet ist. Der Lastverteiler 422 dekrementiert den Guthabenzähler 435 für Subkontext 1 von 2 auf 1. Der ausgewählte TRT 425 gibt dann CTAs für die erste Aufgabe für Subkontext 1 an den entsprechenden TPC 340 aus. Man beachte, dass, wenn die erste Aufgabe für Subkontext 1 keine ungestarteten CTAs mehr hat, der Lastverteiler 422 die Zuweisung der ersten Aufgabe für Subkontext 1 zu den nicht ausgewählten TRTs 425 aufhebt. Andernfalls, wenn die erste Aufgabe des Subkontexts 1 noch ungestartete CTAs hat, wird die Zuweisung der ersten Aufgabe für Subkontext 1 zu irgendeinem TRT 425 nicht aufgehoben, bis Subkontext 1 nachfolgend keine übrigen Guthaben mehr hat. In einem dritten Szenario hat weder die erste Aufgabe für Subkontext 0 noch die erste Aufgabe für Subkontext 1 zusätzliche CTAs zu starten. Daher ist die erste Aufgabe für Subkontext 0 und die erste Aufgabe für Subkontext 1 aus der prioritätssortierten Aufgabentabelle 438 entfernt worden. In diesem dritten Szenario startet der TRT 425, der dem zweiten TPC 340 entspricht, CTAs für die zweite Aufgabe für Subkontext 0 zu dem zweiten TPC 340. Auf diese Weise wandern Aufgaben und zugeordnete Subkontexte mit der Zeit zwischen den verschiedenen TRTs 425 auf Basis der dynamischen Lastbedingungen der zugeordneten TPCs 340.
In manchen Ausführungsformen kann es bestimmten Subkontexten verboten sein, gleichzeitig auf demselben TPC 340 auszuführen. In manchen Ausführungsformen kann der CWD 420 eine Exklusiv-Zuteilungstabelle mit einem Bit pro Subkontext unterhalten, um zu kennzeichnen, ob dieser Subkontext exklusiv ist. Wenn ein bestimmter Subkontext als exklusiv gekennzeichnet ist, darf kein anderer Subkontext auf einem bestimmten TPC 340 ausführen, wenn der exklusive Subkontext auf demselben TPC 340 ausgeführt wird. In manchen Ausführungsformen kann der CWD 420 eine Exklusiv-Zuteilungstabelle unterhalten, die kennzeichnet, ob bestimmte Paare von Subkontexten exklusiv sind. In solchen Ausführungsformen stellen die Zeilen und Spalten der Exklusivitätstabellen Subkontexte dar. Eine ‚1‘ in einer bestimmten Zelle kann kennzeichnen, dass die beiden entsprechenden Subkontexte paarweise exklusiv sind. Zwei Subkontexte, die paarweise exklusiv sind, kann es verboten sein, CTAs auf demselben TPC 340 gleichzeitig auszuführen. Wenn zwei Subkontexte paarweise exklusiv in Bezug aufeinander sind und der erste Subkontext CTAs auf einem bestimmten TPC 340 ausführt, dann wartet der zweite Subkontext, bis die CTAs für den ersten Subkontext die Ausführung abschließen, bevor er CTAs auf demselben TPC 340 startet.
Man beachte, dass das hier gezeigte System veranschaulichend ist und dass Abweichungen und Modifikationen möglich sind. Zum Beispiel bedeutet in den beschriebenen Ausführungsformen ein Wert von ‚1‘, dass bestimmte Elemente freigegeben, zugelassen, zugeteilt oder zugewiesen sind, während ein Wert von ‚0‘ angibt, dass bestimmte Elemente deaktiviert, verboten, nicht zugeteilt oder nicht zugewiesen sind. Innerhalb des Schutzbereichs der Erfindung können irgendwelche anderen geeigneten Werte verwendet werden.
5A-5B veranschaulichen eine TPC-Freigabetabelle 500 und eine LMEM-Block-Indextabelle 550 für statische TPC-Partitionierung gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung. Die TPC-Freigabetabelle 500 und die LMEM-Block-Indextabelle 550 arbeiten im Wesentlichen wie die TPC-Freigabetabelle 430 und die LMEM-Block-Indextabelle 432 von 4, außer wie nachfolgend näher beschrieben. Wie gezeigt, enthält die TPC-Freigabetabelle 500 Subkontextzeilen 510 und TPC-Spalten 520. Jede Zelle in der TPC-Freigabetabelle 500 ist auf ‚1‘ gesetzt, was angibt, dass irgendein Subkontext auf irgendeinem TPC 340 ausführen kann. Die LMEM-Block-Indextabelle 550 enthält ebenfalls Subkontextzeilen 560 und TPC-Spalten 570. Jede Zelle in der LMEM-Block-Indextabelle 550 kennzeichnet eine virtuelle TPC-Kennung für einen bestimmten Subkontext, der auf einem bestimmten TPC 340 ausgeführt wird. Die virtuelle TPC-Kennung, die in jeder Zelle der LMEM-Block-Indextabelle 550 enthalten ist, kennzeichnet weiterhin eine Position des Lokalspeicherblocks für den Subkontext, wenn er CTAs auf dem entsprechenden TPC 340 ausführt.
6A-6B veranschaulichen eine TPC-Freigabetabelle 600 und eine LMEM-Block-Indextabelle 650 für statische TPC-Partitionierung gemäß anderen verschiedenen Ausführungsformen der vorliegenden Erfindung. Die TPC-Freigabetabelle 600 und die LMEM-Block-Indextabelle 650 arbeiten im Wesentlichen wie die TPC-Freigabetabelle 430 und die LMEM-Block-Indextabelle 432 von 4, außer wie im Folgenden näher beschrieben. Wie gezeigt, enthält die TPC-Freigabetabelle 600 Subkontextzeilen 610 und TPC-Spalten 620. Die Subkontextzeile 610 für Subkontext 0 enthält zwei Zellen, die auf ‚1‘ gesetzt sind, entsprechend TPC 0 und TPC 1. Die übrigen Zellen in der Subkontextzeile 610 für Subkontext 0 sind auf ‚0‘ gesetzt. Folglich kann der Subkontext 0 CTAs auf TPC 0 und TPC 1 ausführen, aber auf keinen anderen TPCs 340. Ähnlich enthält die Subkontextzeile 610 für Subkontext 0 zwei Zellen, die auf ‚1‘ gesetzt sind, entsprechend TPC 1 und TPC 2. Die übrigen Zellen in der Subkontextzeile 610 für Subkontext 1 sind auf ‚0‘ gesetzt. Folglich kann der Subkontext 0 CTAs auf TPC 1 und TPC 2 ausführen, aber auf keinen anderen TPCs 340. Die Zellen für die übrigen Subkontextzeilen 610 der TPC-Freigabetabelle 600 sind in ähnlicher Weise gesetzt. Demzufolge kann jeder Subkontext auf bis zu zwei spezifizierten TPCs 340 ausführen, wie in der TPC-Freigabetabelle 600 gekennzeichnet, und jeder TPC ist darauf beschränkt, CTAs für nur zwei Subkontexte auszuführen.
Die Subkontextzeile 660 für Subkontext 0 in der LMEM-Block-Indextabelle 650 ist auf ‚0‘ bzw. ‚1‘ für TPC 0 bzw. TPC 1 gesetzt. Diese Werte zeigen an, dass die virtuelle TPC-Kennung 0 für Subkontext 0 dem physischen TPC 0 entspricht und die virtuelle TPC-Kennung 1 für Subkontext 0 dem physischen TPC 1 entspricht. Diese virtuellen TPC-Kennungen kennzeichnen weiterhin eine Position des Lokalspeicherblocks für Subkontext 0, wenn er CTAs auf dem entsprechenden TPC 340 ausführt. Die übrigen Zellen in der Subkontextzeile 660 für Subkontext 0 sind auf X gesetzt (gleichgültig), da Subkontext 0 auf keinem der übrigen TPCs 340 ausführen darf.
Die Subkontextzeile 660 für Subkontext 1 in der LMEM-Block-Indextabelle 650 ist auf ‚0‘ bzw. ‚1‘ für TPC 1 bzw. TPC 2 gesetzt. Diese Werte zeigen an, dass die virtuelle TPC-Kennung 0 für Subkontext 1 dem physischen TPC 1 entspricht und die virtuelle TPC-Kennung 1 für Subkontext 1 dem physischen TPC 2 entspricht. Diese virtuellen TPC-Kennungen kennzeichnen weiterhin eine Position des Lokalspeicherblocks für Subkontext 1, wenn er CTAs auf dem entsprechenden TPC 340 ausführt. Die übrigen Zellen in der Subkontextzeile 660 für Subkontext 1 sind auf X gesetzt (gleichgültig), da Subkontext 1 auf keinem der übrigen TPCs 340 ausführen darf. Die Zellen für die übrigen Subkontextzeilen 660 der LMEM-Block-Indextabelle 650 sind in ähnlicher Weise gesetzt.
7 veranschaulicht eine TPC-Freigabetabelle 700 für dynamische TPC-Partitionierung gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung. Die TPC-Freigabetabelle 700 arbeitet im Wesentlichen wie die TPC-Freigabetabelle 430 in 4, außer wie nachfolgend näher beschrieben. Wie gezeigt, enthält die TPC-Freigabetabelle 700 Subkontextzeilen 710 und TPC-Spalten 720. Jede Zelle in der TPC-Freigabetabelle 700 ist auf ‚1‘ gesetzt, was angibt, dass irgendein Subkontext auf irgendeinem TPC 340 ausführen kann, vorbehaltlich Beschränkungen der Guthabenzählung. Die LMEM-Block-Indextabelle (nicht gezeigt) wird vom Lastverteiler 422 auf Basis der aktuellen Guthabenzählung, die im Guthabenzähler 434 für jeden Subkontext gespeichert ist, und der aktuellen Ausführungslast auf jedem TPC 340 dynamisch gesetzt, wie hierin näher beschrieben.
8 veranschaulicht eine TPC-Freigabetabelle 800 für dynamische TPC-Partitionierung gemäß anderen verschiedenen Ausführungsformen der vorliegenden Erfindung. Die TPC-Freigabetabelle 800 arbeitet im Wesentlichen wie die TPC-Freigabetabelle 430 in 4, außer wie nachfolgend näher beschrieben. Wie gezeigt, enthält die TPC-Freigabetabelle 800 Subkontextzeilen 810 und TPC-Spalten 820. Jede Subkontextzeile 810 für Subkontext 0 bis Subkontext 7 enthält eine ‚1‘ in den Zellen für TPC 0 bis TPC 6 und eine ‚0‘ in den übrigen Zellen. Folglich kann jeder der Subkontexte 0 bis 7 CTAs auf einem oder mehreren der TPC 0 bis TPC 6 ausführen, vorbehaltlich Beschränkungen der Guthabenzählung. Ähnlich enthält jede Subkontextzeile 810 für Subkontext 8 bis Subkontext 15 eine ‚1‘ in den Zellen für TPC 7 bis TPC 13 und eine ‚0‘ in den übrigen Zellen. Folglich kann jeder der Subkontexte 8 bis 15 CTAs auf einem oder mehreren der TPC 7 bis TPC 13 ausführen, vorbehaltlich Beschränkungen der Guthabenzählung. Die LMEM-Block-Indextabelle (nicht gezeigt) wird vom Lastverteiler 422 auf Basis der aktuellen Guthabenzählung, die im Guthabenzähler 434 für jeden Subkontext gespeichert ist, und der aktuellen Ausführungslast auf jedem TPC 340 dynamisch gesetzt, wie hierin näher beschrieben.
9A-9C zeigen ein Flussdiagramm von Verfahrensschritten zum Zuteilen von Ausführungsressourcen innerhalb eines Prozessors gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung. Obwohl die Verfahrensschritte in Verbindung mit den Systemen der 1-8 beschrieben werden, erkennt der Fachmann, dass irgendein System, das zur Durchführung der Verfahrensschritte in beliebiger Reihenfolge konfiguriert ist, in den Schutzbereich der vorliegenden Erfindung fällt.
Wie gezeigt, beginnt ein Verfahren 900 im Schritt 902, worin der Lastverteiler 422 im CWD 420, ein Betriebssystem (OS), das auf der CPU 102 ausgeführt wird, oder ein Hypervisor, der auf der CPU 102 ausgeführt wird, eine TPC-Freigabetabelle initialisiert, die die TPCs 340 kennzeichnet, die CTAs für jeden Subkontext ausführen dürfen. Wenn statische TPC-Partitionierung verwendet wird, initialisiert der Lastverteiler 422, das Betriebssystem oder der Hypervisor auch die Block-Indextabelle des Lokalspeichers (LMEM), die die virtuellen TPC-Kennungen und Lokalspeicherblock-Positionen für jeden Subkontext kennzeichnet, wenn CTAs auf einem TPC 340 ausgeführt werden. Wenn dynamische oder hybride TPC-Partitionierung verwendet wird, initialisiert und aktualisiert der Lastverteiler 422 die LMEM-Block-Indextabelle. Im Schritt 904 initialisiert der Lastverteiler 422, das Betriebssystem (OS) oder der Hypervisor die anfängliche Guthabenzählung im CWD 420 für jeden Subkontext. Die anfängliche Guthabenzählung stellt die maximale Anzahl von TPCs dar, die in einem gegebenen Zeitpunkt CTAs für einen Subkontext ausführen können. In einem Beispiel, wenn die anfängliche Guthabenzählung drei beträgt, kann jeder Subkontext bis zu drei TPCs aufweisen, die in irgendeinem gegebenen Zeitpunkt einen oder mehrere CTAs ausführen. Wenn jeder TPC vier CTAs unterbringen kann, könnten in irgendeinem gegebenen Zeitpunkt bis zu zwölf CTAs gleichzeitig ausgeführt werden.
Im Schritt 906 empfängt der Scheduler 410 in der Aufgaben-/Arbeitseinheit 207 Aufgaben von verschiedenen Prozessen, die auf der CPU 102 ausgeführt werden, wobei jede Aufgabe einem oder mehreren CTAs entspricht. Jeder Prozess gibt solche Aufgaben an einen oder mehrere Subkontexte aus, die in der PPU 202 ausführen. Im Schritt 908 sendet der Scheduler 410 die empfangenen Aufgaben an den Lastverteiler 422 im CWD 420. Im Schritt 910 setzt der Lastverteiler 422 jede empfangene Aufgabe entsprechend der Ankunftszeit und/oder dem ausgewählten Prioritätswert entsprechend der Aufgabe an eine geeignete Position auf der Aufgabentabelle 436 und der prioritätssortierten Aufgabentabelle 438. Im Schritt 912 wählt der Lastverteiler 422 eine Aufgabe aus der prioritätssortierten Aufgabentabelle 438 aus. Der Scheduler 410 kann irgendeine Aufgabe für einen Subkontext auswählen, der kein aktuelles Guthaben von Null hat. Im Allgemeinen wählt der Lastverteiler 422 eine Aufgabe aus, die auch die höchste Priorität hat. In manchen Ausführungsformen kann jeder TRT 425 CTAs für verschiedene Aufgaben ausführen, und jede Aufgabe kann mehr als einem CTA entsprechen. Der Lastverteiler 422 kann Ressourcenangebote berücksichtigen, die von jedem TRT 425 empfangen werden, wenn ein TPC 340 ausgewählt wird, CTAs für eine bestimmte Aufgabe auszuführen, wie hierin näher beschrieben.
Im Schritt 914 ordnet der Lastverteiler 422 die ausgewählte Aufgabe allen verfügbaren TRTs 425 zu, die TPCs 340 entsprechen, die freigegeben sind, um die CTAs der Aufgabe auf Basis der TPC-Freigabetabelle auszuführen. Im Schritt 916 sendet jeder TRT 425 ein Ressourcenangebot an den Lastverteiler 422, wobei das Ressourcenangebot für einen entsprechenden TPC 340 gilt. Das Ressourcenangebot eines TRT 425 zeigt die Anzahl der verfügbaren CTA-Ausführungs-Slots auf dem entsprechenden TPC 340 an. Im Schritt 918 empfängt der Lastverteiler 422 Ressourcenangebote von jedem der verfügbaren TRTs 425, wobei jedes Ressourcenangebot von einem TRT 425 die Anzahl der verfügbaren CTA-Ausführungs-Slots auf dem entsprechenden TPC 340 enthält. Im Schritt 920 wählt der Lastverteiler 422 den TRT 425 entsprechend dem TPC 340 aus, der am wenigsten belastet ist, das heißt, den TPC 340 mit der höchsten Anzahl von freien CTA-Ausführungs-Slots. Wenn mehrere TPCs 340 die gleiche Anzahl von verfügbaren CTA-Ausführungs-Slots aufweisen, wählt der Lastverteiler 422 irgendeinen TPC 340 aus den TPCs 340 mit der höchsten Anzahl von verfügbaren CTA-Ausführungs-Slots aus. Im Schritt 922 hebt der Lastverteiler 422 die Zuweisung der Aufgabe zu den nicht ausgewählten TRTs 425 auf.
Im Schritt 924 ermittelt der Lastverteiler 422, ob der TPC 340 für den ausgewählten TRT 425 irgendwelche CTAs für den der Aufgabe zugeordneten Subkontext ausführt. Wenn der TPC 340 für den ausgewählten TRT 425 keine CTAs für den Subkontext ausführt, fährt das Verfahren 900 mit Schritt 926 fort, worin der Lastverteiler 422 den Guthabenzähler 434 des der Aufgabe entsprechenden Subkontexts dekrementiert. Das Verfahren fährt dann mit Schritt 928 fort, der im Folgenden beschrieben wird. Wenn im Schritt 924 der TPC 340 für den ausgewählten TRT 425 CTAs für den Subkontext ausführt, fährt das Verfahren 900 mit Schritt 928 fort, worin der Lastverteiler 422 ein Startsignal an den TRT 425 sendet, der dem ausgewählten TPC 340 entspricht.
Im Schritt 930 bereitet der TRT 425 im CWD 420 ein Startpaket vor, das das CTA enthält. Das Startpaket enthält auch die Subkontext-Anzahl, die verwendet wird, um eine entsprechende Seitenverzeichnis-Basisadresse für den Subkontext zu kennzeichnen, und kennzeichnet auch die Zustandsdaten für den Subkontext, für das CTA. Das Startpaket enthält Lokalspeicher-Zuweisungsinformationen für das CTA, so dass der TPC 340 die zugewiesenen Lokalspeicherblöcke lokalisieren kann.
Im Schritt 932 sendet der TRT 425 das Startpaket an den entsprechenden TPC 340. Im Schritt 934 führt der TPC 340 das CTA aus. Im Schritt 936 ermittelt der Lastverteiler 422, ob der TPC 340 die Ausführung des letzten auf dem TPC 340 für den Subkontext ausgeführten CTA abgeschlossen hat. Wenn der TPC 340 die Ausführung des letzten auf dem TPC 340 für den Subkontext ausgeführten CTA abgeschlossen hat, fährt das Verfahren 900 mit Schritt 938 fort, worin der Lastverteiler 422 den entsprechenden Guthabenzähler 434 für den bestimmten Subkontext um eins inkrementiert. Das Verfahren 900 endet dann. Wenn der TPC 340 im Schritt 934 die Ausführung des letzten auf dem TPC 340 für den Subkontext ausgeführten CTA nicht abgeschlossen hat, endet das Verfahren 900.
10A-10B zeigen ein Flussdiagramm von Verfahrensschritten zum Zuweisen von Lokalspeicherressourcen innerhalb eines Prozessors gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung. Obwohl die Verfahrensschritte in Verbindung mit den Systemen der 1-8 beschrieben werden, erkennt der Fachmann, dass irgendein System, das zur Durchführung der Verfahrensschritte in beliebiger Reihenfolge konfiguriert ist, in den Schutzbereich der vorliegenden Erfindung fällt.
Wie gezeigt, beginnt ein Verfahren 1000 im Schritt 1002, worin die Lokalspeicher(LMEM)-Block-Indextabelle initialisiert wird. Die LMEM-Block-Indextabelle kennzeichnet die virtuellen TPC-Kennungen und Lokalspeicherblock-Positionen für jeden Subkontext, wenn CTAs auf einem TPC 340 ausgeführt werden. Wenn statische TPC-Partitionierung verwendet wird, initialisiert das Betriebssystem oder der Hypervisor die LMEM-Block-Indextabelle. Wenn dynamische oder hybride TPC-Partitionierung verwendet wird, initialisiert und aktualisiert der CWD 420 die LMEM-Block-Indextabelle. Im Schritt 1004 ermittelt der Lastverteiler 422 im CWD 420, dass ein TRT 425 ein CTA zur Ausführung auf einem TPC 340 startet. Das Starten eines CTA erfolgt unabhängig von der Zuweisung eines Lokalspeicherblocks. Ein CTA kann zur Ausführung vor, gleichzeitig mit oder nach Zuweisung des entsprechenden Lokalspeicherblocks zu dem TPC gestartet werden. Im Allgemeinen ist der TPC 340, zu dem das CTA gestartet wird, einem Lokalspeicherblock zugewiesen, wobei der Lokalspeicherblock für den dem CTA entsprechenden Subkontext ist. Typischerweise ist der Lokalspeicherblock nicht dem CTA, sondern dem TPC 340 zugewiesen. Der CTA beginnt nicht mit der Ausführung, bis der entsprechende Lokalspeicherblock zugewiesen ist. Im Schritt 1006 ermittelt der Lastverteiler 422, ob dem TPC, zu dem das CTA gestartet wird, bereits ein Lokalspeicherblock zugewiesen worden ist. Wenn bereits ein Lokalspeicherblock zugewiesen worden ist, fährt das Verfahren 1000 mit Schritt 1022 fort, wie im Folgenden beschrieben. Wenn dem gerade gestarteten CTA noch kein Lokalspeicherblock zugewiesen worden ist, fährt das Verfahren 1000 mit Schritt 1008 fort, worin der Lastverteiler 422 ermittelt, ob statische TPC-Partitionierung verwendet wird.
Wenn statische TPC-Partitionierung verwendet wird, fährt das Verfahren 1000 mit Schritt 1010 fort, worin der Lastverteiler 422 den Lokalspeicherblock-Index aus der LMEM-Block-Indextabelle abruft. Der Lastverteiler 422 kennzeichnet die Position für die Zelle in der LMEM-Block-Indextabelle, die dem Subkontext für das gerade gestartete CTA und dem zur Ausführung des CTA ausgewählten TPC 340 entspricht. Der Lastverteiler 422 ruft den Lokalspeicherblock-Index aus der gekennzeichneten Zelle in der LMEM-Block-Indextabelle ab. Im Schritt 1012 weist der Lastverteiler 422 einen Lokalspeicherblock entsprechend dem Lokalspeicherblock-Index zu. Der Lastverteiler 422 weist den Lokalspeicherblock aus dem Lokalspeicherpool für den Subkontext zu. Sobald der Lokalspeicherblock zugewiesen ist, können alle CTAs, die auf allen SMs 310 in dem entsprechenden TPC 340 ausgeführt werden, auf Speicherpositionen innerhalb des Lokalspeicherblocks zugreifen. Im Schritt 1014 aktualisiert der Lastverteiler 422 die Zelle in der LMEM-Block-Indextabelle, um anzuzeigen, dass der Lokalspeicherblock zugewiesen worden ist. Das Verfahren 1000 fährt dann mit Schritt 1022 fort, der im Folgenden beschrieben wird.
Zurück zu Schritt 1008, wenn im Schritt 1008 keine statische TPC-Partitionierung verwendet wird, dann wird entweder dynamische TPC-Partitionierung oder hybride statische/dynamische TPC-Partitionierung verwendet. In solchen Fällen fährt das Verfahren 1000 mit Schritt 1016 fort, worin der Lastverteiler 422 den Lokalspeicherblock-Index für den Lokalspeicherblock ermittelt, der dem gerade gestarteten CTA zuzuweisen ist. Lokalspeicherblöcke können zusammenhängend, zufällig oder durch irgendeinen Algorithmus zugewiesen werden, der es nicht zulässt, dass der gleiche Lokalspeicherblock gleichzeitig auf verschiedenen TPCs 340 verwendet wird. Wenn zum Beispiel das gerade gestartete CTA einem Subkontext entspricht, bei dem bereits Lokalspeicherblöcke für Lokalspeicherblock-Indizes 0, 1 und 2 zugewiesen worden sind, dann könnte der Lastverteiler 422 den nächsten Lokalspeicherblock für den Subkontext unter Verwendung des Lokalspeicherblock-Index 3 zuweisen. Wird anschließend der Lokalspeicherblock 1 freigegeben, während die Lokalspeicherblöcke 0, 2 und 3 zugewiesen bleiben, kann der Lastverteiler 422 den nächsten Lokalspeicherblock für den Subkontext unter Verwendung des Lokalspeicherblock-Index 1 zuweisen.
Im Schritt 1018 kann der Lastverteiler 422 in manchen Ausführungsformen einen Lokalspeicherblock entsprechend dem Lokalspeicherblock-Index zuweisen. Der Lastverteiler 422 weist den Lokalspeicherblock aus dem Lokalspeicherpool zu. Sobald der Lokalspeicherblock zugewiesen ist, können alle CTAs, die auf allen SMs 310 in dem entsprechenden TPC 340 ausgeführt werden, auf Speicherpositionen innerhalb des zugewiesenen Lokalspeicherblocks zugreifen. Im Schritt 1020 aktualisiert der Lastverteiler 422 die Zelle in der LMEM-Block-Indextabelle entsprechend dem Lokalspeicherblock mit dem Lokalspeicherblock-Index, um anzuzeigen, dass der Lokalspeicherblock zugewiesen worden ist.
Im Schritt 1022 ermittelt der Lastverteiler 422, ob alle CTAs, die auf den Lokalspeicherblock zugreifen, die Ausführung abgeschlossen haben und keinen Zugriff mehr auf den Lokalspeicherblock benötigen. Wenn alle CTAs, die auf den Lokalspeicherblock zugreifen, die Ausführung noch nicht abgeschlossen haben, endet das Verfahren 1000. Wenn dagegen alle CTAs, die auf den Lokalspeicherblock zugreifen, die Ausführung abgeschlossen haben, fährt das Verfahren 1000 mit Schritt 1024 fort, worin, bevor die Zuweisung des Lokalspeicherblocks aufgehoben wird, der Lastverteiler 422 eine Speichersperren-Operation durchführt, um sicherzustellen, dass alle Lokalspeicherschreibvorgänge vom TPC 340 den Zeitpunkt der Speicherkohärenz erreicht haben. Darüber hinaus stellt die Speichersperre sicher, dass ein anderer TPC 340 mit demselben Lokalspeicherblock nicht zu einer Beschädigung des Lokalspeichers führt. Insbesondere stellt die Speichersperre sicher, dass es bei einer Neuzuweisung des Lokalspeicherblocks keine ausstehenden Schreibvorgänge von vorherigen TPCs gibt, welche die Daten in lokalem Speicher ändern könnten. Im Schritt 1026 gibt der Lastverteiler 422 den Lokalspeicherblock wieder in den Lokalspeicherpool frei. Im Schritt 1028 aktualisiert der Lastverteiler 422 die Zelle in der LMEM-Block-Index-Tabelle entsprechend dem Lokalspeicherblock, um anzuzeigen, dass der Lokalspeicherblock nicht mehr zugewiesen ist. Das Verfahren 1000 endet dann.
Zusammenfassend werden verschiedene Techniken zum Partitionieren von Ausführungs- und Speicherressourcen in einem Parallelverarbeitungssystem für Ausführung von Kooperativ-Thread-Arrays (CTAs) entsprechend Aufgaben offenbart. Insbesondere werden Ausführungsressourcen in Form von Texturverarbeitungsclustern (TPCs) und Speicherressourcen in Form von Lokalspeicherblöcken verschiedenen Subkontexten zugewiesen, die in einem einzigen Kontext ausführen. Jeder Subkontext unterhält einen getrennten virtuellen Adressraum und getrennte Zustandsdaten, teilt sich aber Planungs- und Kontextwechsel-Ressourcen.
Bei einer ersten Technik werden TPCs und Lokalspeicherblöcke statisch Subkontexten zugeordnet. Bei dieser ersten Technik ist jeder Subkontext darauf beschränkt, CTAs auf bestimmten TPCs auszuführen und bestimmte Lokalspeicherblöcke in lokalem Speicher zuzuweisen. Bei einer zweiten Technik werden TPCs und Lokalspeicherblöcke dynamisch Subkontexten zugewiesen. Bei dieser zweiten Technik kann jeder Subkontext CTAs auf irgendwelchen der TPCs ausführen und irgendwelche Lokalspeicherblöcke in lokalem Speicher zuweisen, vorbehaltlich einer maximalen Guthabenzählung für den gegebenen Subkontext. Bei einer dritten Technik werden die Eigenschaften der statischen und dynamischen Ressourcenzuteilung in einer hybriden Methode kombiniert. Bei dieser dritten Technik ist jeder Subkontext gezwungen, auf einem bestimmten Teilsatz der Gesamtzahl der TPCs auszuführen. Innerhalb des spezifizierten Teilsatzes von TPCs kann der Subkontext CTAs auf irgendwelchen der in dem Teilsatz von TPCs enthaltenen TPCs ausführen und Lokalspeicherblöcke in lokalem Speicher entsprechend dem gleichen Teilsatz von TPCs zuweisen, vorbehaltlich einer maximalen Guthabenzählung für den gegebenen Subkontext.
Mindestens ein Vorteil der offenbarten Techniken besteht darin, dass Ausführungs- und Lokalspeicherressourcen flexibel und effizient Subkontexten zugewiesen werden, die Mehrfachprozessen innerhalb eines Parallelverarbeitungssystems entsprechen. Dadurch wird die Ausnutzung der Ausführungs- und Lokalspeicherressourcen im Vergleich zu früheren Methoden erhöht. Ein weiterer Vorteil der offenbarten Techniken besteht darin, dass die maximale Menge an Ausführungs- und Lokalspeicherressourcen, die einem Subkontext zugeteilt oder zugewiesen werden können, innerhalb der Grenzen der Anzahl der verfügbaren TPCs und Lokalspeicherblöcke wählbar ist und begrenzt werden kann, damit mehr Subkontexte gleichzeitig ausführen können. Ein weiterer Vorteil der offenbarten Techniken ist, dass alle Subkontexte in einem einzigen Kontext ausführen, aber getrennte virtuelle Adressräume und getrennte Zustandsdaten unterhalten. Dadurch können TPCs schnell von der Ausführung eines CTA für einen Subkontext auf die Ausführung eines CTA für einen anderen Subkontext wechseln, ohne dass ein vollständiger Kontextwechsel erforderlich ist.
Ein weiterer Vorteil der offenbarten Techniken besteht darin, dass Ausführungs- und Lokalspeicherressourcen verschiedenen Subkontexten zugeordnet sind, die verschiedenen CPU-Prozessen entsprechen, die auf einer Servermaschine ausgeführt werden, die in einem Rechenzentrum oder einer Cloud-Computing-Umgebung arbeitet, die skalierbare Computerressourcen als ein Dienst über ein Netz bereitstellt. Verschiedene Dienste, die von der Servermaschine bereitgestellt werden, können Endbenutzern über eine Cloud-Computing-Infrastruktur bereitgestellt werden. Cloud-Computing bezeichnet allgemein die Bereitstellung von skalierbaren Computerressourcen als ein Dienst über ein Netz. Formaler kann Cloud-Computing als eine Computerleistung definiert werden, die eine Abstraktion zwischen der Computerressource und ihrer zugrunde liegenden technischen Architektur (z. B. Server, Speicher, Netze) bereitstellt und bequemen Bedarfs-Netzzugriff auf einen gemeinsamen Pool von konfigurierbaren Computerressourcen ermöglicht, die mit minimalem Verwaltungsaufwand oder minimaler Interaktion mit dem Dienstanbieter schnell bereitgestellt und freigegeben werden können. Somit ermöglicht Cloud-Computing einem Benutzer Zugriff auf virtuelle Computerressourcen (z. B. Speicher, Daten, Anwendungen und sogar komplette virtualisierte Computersysteme) in der „Cloud“, ohne Rücksicht auf die zugrunde liegenden physischen Systeme (oder Standorte dieser Systeme), die zur Bereitstellung der Computerressourcen verwendet werden.
1. In manchen Ausführungsformen umfasst ein computerimplementiertes Verfahren zum Zuteilen von Ausführungsressourcen zu Gruppen von Threads innerhalb einer Grafikverarbeitungseinheit: Empfangen einer Angabe von einem Prozess, dass eine erste Gruppe von Threads zu starten ist; Ermitteln, dass ein erster Subkontext, der dem Prozess zugeordnet ist, mindestens ein Prozessor-Guthaben aufweist; Identifizieren eines ersten Prozessors, der in einer Vielzahl von Prozessoren enthalten ist und der eine Verarbeitungslast aufweist, die kleiner oder gleich den Prozessorlasten ist, die allen anderen Prozessoren zugeordnet ist, die in der Vielzahl von Prozessoren enthalten sind; und Starten der ersten Gruppe von Threads zur Ausführung auf dem ersten Prozessor.
2. Das computerimplementierte Verfahren von Abschnitt 1, wobei der erste Subkontext in einer Vielzahl von Subkontexten enthalten ist und jeder Subkontext, der in der Vielzahl von Subkontexten enthalten ist, einem anderen Prozess und einem anderen virtuellen Adressraum zugeordnet ist.
3. Das computerimplementierte Verfahren von Abschnitt 1 oder Abschnitt 2, wobei der erste Subkontext in einer Vielzahl von Subkontexten enthalten ist und jeder Subkontext, der in der Vielzahl von Subkontexten enthalten ist, anderen Zustandsdaten zugeordnet ist.
4. Das computerimplementierte Verfahren eines der Abschnitte 1-3, wobei der erste Subkontext in einer Vielzahl von Subkontexten enthalten ist; der erste Subkontext einem ersten virtuellen Adressraum zugeordnet ist; ein zweiter Subkontext, der in der Vielzahl von Subkontexten enthalten ist, dem ersten virtuellen Adressraum zugeordnet ist; und ein dritter Subkontext, der in der Vielzahl von Subkontexten enthalten ist, einem zweiten virtuellen Adressraum zugeordnet ist, der von dem ersten virtuellen Adressraum verschieden ist.
5. Das computerimplementierte Verfahren eines der Abschnitte 1-4, das weiterhin umfasst, als Antwort auf das Starten der ersten Gruppe von Threads zur Ausführung auf dem ersten Prozessor einen Guthabenzähler, der dem ersten Subkontext zugeordnet ist, zu dekrementieren.
6. Das computerimplementierte Verfahren eines der Abschnitte 1-5, das weiterhin umfasst: Ermitteln, dass die erste Gruppe von Threads die Ausführung auf dem ersten Prozessor abgeschlossen hat; und Inkrementieren des dem ersten Subkontext zugeordneten Guthabenzählers.
7. Das computerimplementierte Verfahren eines der Abschnitte 1-6, wobei das Identifizieren eines ersten Prozessors, der in der Vielzahl von Prozessoren enthalten ist, umfasst: Ermitteln einer Zählung von verfügbaren Ausführungs-Slots für jeden Prozessor, der in der Vielzahl von Prozessoren enthalten ist; Identifizieren eines oder mehrerer Prozessoren, die in der Vielzahl von Prozessoren enthalten sind, die eine höchste Zählung von verfügbaren Ausführungs-Slots aufweisen; und Auswählen des ersten Prozessors aus den ein oder mehreren Prozessoren.
8. Das computerimplementierte Verfahren eines der Abschnitte 1-7, das weiterhin umfasst, zu ermitteln, dass der erste Subkontext nicht exklusiv in Bezug auf irgendeinen Subkontext ist, der einer zweiten Gruppe von Threads zugeordnet ist, die gegenwärtig auf dem ersten Prozessor ausgeführt werden.
9. Das computerimplementierte Verfahren eines der Abschnitte 1-8, das weiterhin umfasst: Abrufen einer dem ersten Subkontext zugeordneten ersten Aufzeichnung aus einer ersten Tabelle; und Ermitteln aus der ersten Aufzeichnung, dass jeder Prozessor, der in der Vielzahl von Prozessoren enthalten ist, in Bezug auf das Ausführen mindestens einer Gruppe von Threads, die dem ersten Subkontext zugeordnet sind, verfügbar ist.
10. Das computerimplementierte Verfahren eines der Abschnitte 1-9, wobei die erste Tabelle durch ein Betriebssystem oder einen Hypervisor initialisiert wird, bevor irgendeine Gruppe von Threads zur Ausführung auf irgendeinen Prozessor, der in der Vielzahl von Prozessoren enthalten ist, gestartet wird.
11. Das computerimplementierte Verfahren eines der Abschnitte 1-10, das weiterhin umfasst, eine zweite Aufzeichnung, die dem ersten Subkontext zugeordnet ist, aus einer zweiten Tabelle abzurufen, wobei die zweite Aufzeichnung eine andere virtuelle Prozessorkennung für jeden Prozessor spezifiziert, der in der Vielzahl von Prozessoren enthalten ist und der in Bezug auf das Ausführen mindestens einer Gruppe von Threads, die dem ersten Subkontext zugeordnet sind, verfügbar ist; und eine virtuelle Prozessorkennung für den ersten Prozessor aus der zweiten Aufzeichnung zu identifizieren; wobei der erste Prozessor eine Speicheradressenberechnung auf Basis der virtuellen Prozessorkennung durchführt.
12. In manchen Ausführungsformen umfasst ein Parallelverarbeitungssystem: einen Scheduler, der eine Vielzahl von Aufgaben an einen Rechenarbeitsverteiler sendet; und einen Rechenarbeitsverteiler, der: eine in der Vielzahl von Aufgaben enthaltene Aufgabe entsprechend einem Prozess aus einer einem ersten Subkontext zugeordneten Aufgabenliste auswählt, eine der zu startenden Aufgabe zugeordnete erste Thread-Gruppe identifiziert, ermittelt, dass der erste Subkontext mindestens ein Prozessor-Guthaben aufweist, einen ersten Prozessor identifiziert, der in einer Vielzahl von Prozessoren enthalten ist und der eine Verarbeitungslast aufweist, die kleiner oder gleich der Prozessorlast ist, die allen anderen Prozessoren zugeordnet ist, die in der Vielzahl von Prozessoren enthalten sind, und die erste Gruppe von Threads zur Ausführung auf dem ersten Prozessor startet.
13. Das Parallelverarbeitungssystem von Abschnitt 12, wobei der Rechenarbeitsverteiler weiterhin ermittelt, dass der erste Prozessor verfügbar ist, um die erste Gruppe von Threads auszuführen.
14. Das Parallelverarbeitungssystem von Abschnitt 12 oder Abschnitt 13, wobei der Rechenarbeitsverteiler weiterhin als Antwort auf das Starten der ersten Gruppe von Threads zur Ausführung auf dem ersten Prozessor einen dem ersten Subkontext zugeordneten Guthabenzähler dekrementiert.
15. Das Parallelverarbeitungssystem eines der Abschnitte 12-14, wobei der Rechenarbeitsverteiler weiterhin: ermittelt, dass die erste Gruppe von Threads die Ausführung auf dem ersten Prozessor abgeschlossen hat; und den dem ersten Subkontext zugeordneten Guthabenzähler inkrementiert.
16. Das Parallelverarbeitungssystem eines der Abschnitte 12-15, wobei das Identifizieren eines ersten Prozessors, der in der Vielzahl von Prozessoren enthalten ist, umfasst: Ermitteln einer Zählung von verfügbaren Ausführungs-Slots für jeden Prozessor, der in der Vielzahl von Prozessoren enthalten ist; Identifizieren eines oder mehrerer Prozessoren, die in der Vielzahl von Prozessoren enthalten sind, die eine höchste Zählung von verfügbaren Ausführungs-Slots aufweisen; und Auswählen des ersten Prozessors aus den ein oder mehreren Prozessoren.
17. Das Parallelverarbeitungssystem eines der Abschnitte 12-16, wobei der Rechenarbeitsverteiler weiterhin: ein Startpaket für den ersten Prozessor erzeugt, das die erste Gruppe von Threads enthält; und das Startpaket an den ersten Prozessor sendet.
18. Das Parallelverarbeitungssystem eines der Abschnitte 12-17, wobei das Startpaket weiterhin eine dem ersten Subkontext entsprechende Zahl enthält.
19. Das Parallelverarbeitungssystem eines der Abschnitte 12-18, wobei das Parallelverarbeitungssystem einer Servermaschine zugeordnet ist, die in einem Rechenzentrum enthalten ist.
20. In manchen Ausführungsformen umfasst ein computerimplementiertes Verfahren zum Zuteilen von Ausführungsressourcen zu Gruppen von Threads innerhalb einer Grafikverarbeitungseinheit: Empfangen einer Angabe von einem Prozess, dass eine erste Gruppe von Threads zu starten ist, wobei der erste Subkontext in einer Vielzahl von Subkontexten enthalten ist und jeder Subkontext, der in der Vielzahl von Subkontexten enthalten ist, einem anderen Prozess und einem anderen virtuellen Adressraum zugeordnet ist; Ermitteln, ob der erste Subkontext mindestens ein Prozessor-Guthaben aufweist; und wenn der erste Subkontext mindestens ein Prozessor-Guthaben aufweist, dann: Identifizieren eines ersten Prozessors, der in einer Vielzahl von Prozessoren enthalten ist und der eine Verarbeitungslast aufweist, die kleiner oder gleich den Prozessorlasten ist, die allen anderen Prozessoren zugeordnet sind, die in der Vielzahl von Prozessoren enthalten sind, und Starten der ersten Gruppe von Threads zur Ausführung auf dem ersten Prozessor; oder wenn der erste Subkontext nicht mindestens ein Prozessor-Guthaben aufweist, dann: Identifizieren eines Teilsatzes von Prozessoren, die in der Vielzahl von Prozessoren enthalten sind, die bereits dem ersten Subkontext zugewiesen sind, Identifizieren eines zweiten Prozessors, der in dem Teilsatz von Prozessoren enthalten ist und der eine Verarbeitungslast aufweist, die kleiner oder gleich den Prozessorlasten ist, die allen anderen Prozessoren zugeordnet sind, die in dem Teilsatz von Prozessoren enthalten sind; und Starten der ersten Gruppe von Threads auf dem zweiten Prozessor.
21. In manchen Ausführungsformen umfasst ein computerimplementiertes Verfahren zum Zuteilen von lokalem Speicher zu Thread-Gruppen innerhalb einer Grafikverarbeitungseinheit: Empfangen einer Angabe, dass eine erste Thread-Gruppe, die einem ersten Subkontext zugeordnet ist, zur Ausführung auf einem ersten Prozessor zugewiesen worden ist; Identifizieren einer ersten Aufzeichnung in einer Lokalspeicherblock-Zuweisungstabelle entsprechend dem ersten Subkontext; Identifizieren eines ersten Lokalspeicherblocks, der gegenwärtig nicht zugewiesen ist; und Speichern eines ersten Wertes in der ersten Aufzeichnung, der angibt, dass der erste Lokalspeicherblock dem ersten Subkontext und dem ersten Prozessor zugewiesen ist.
22. Das computerimplementierte Verfahren von Abschnitt 21, das weiterhin umfasst, einen ersten Index zu dem ersten Lokalspeicherblock in der ersten Aufzeichnung zu speichern.
23. Das computerimplementierte Verfahren von Abschnitt 21 oder Abschnitt 22, das weiterhin umfasst: Empfangen einer Angabe, dass eine dem ersten Subkontext zugeordnete zweite Thread-Gruppe zugewiesen worden ist, um auf einem zweiten Prozessor ausgeführt zu werden; Identifizieren der ersten Aufzeichnung in der Lokalspeicherblock-Zuweisungstabelle entsprechend dem ersten Subkontext; Identifizieren eines zweiten Lokalspeicherblocks, der gegenwärtig nicht zugewiesen ist; Speichern eines zweiten Wertes in der ersten Aufzeichnung, der angibt, dass der zweite Lokalspeicherblock dem ersten Subkontext und dem zweiten Prozessor zugewiesen ist; und Speichern eines zweiten Index zu dem zweiten Lokalspeicherblock in der ersten Aufzeichnung, wobei der zweite Index größer als der erste Index ist.
24. Das computerimplementierte Verfahren eines der Abschnitte 21-23, wobei: der erste Prozessor und der zweite Prozessor in einem Verarbeitungscluster enthalten sind; und der erste Lokalspeicherblock sowohl für den ersten Prozessor als auch für den zweiten Prozessor zugänglich ist.
25. Das computerimplementierte Verfahren eines der Abschnitte 21-24, wobei der erste Prozessor und der zweite Prozessor in einer Vielzahl von Prozessoren enthalten sind und die Lokalspeicherblock-Zuweisungstabelle durch ein Betriebssystem oder einen Hypervisor initialisiert wird, bevor irgendeine Gruppe von Threads zur Ausführung auf irgendeinen Prozessor, der in der Vielzahl von Prozessoren enthalten ist, gestartet wird.
26. Das computerimplementierte Verfahren eines der Abschnitte 21-25, das weiterhin umfasst: Abrufen des ersten Index zu dem ersten Lokalspeicherblock aus der ersten Aufzeichnung; und Zuordnen des ersten Lokalspeicherblocks zu dem ersten Index.
27. Das computerimplementierte Verfahren eines der Abschnitte 21-26, das weiterhin umfasst, eine Nachricht an den ersten Prozessor zu senden, die den ersten Index zu dem ersten Lokalspeicherblock enthält.
28. Das computerimplementierte Verfahren eines der Abschnitte 21-27, das weiterhin umfasst: Ermitteln, dass die erste Thread-Gruppe die Ausführung auf dem ersten Prozessor abgeschlossen hat; und Speichern eines neuen Wertes in der ersten Aufzeichnung, der angibt, dass der erste Lokalspeicherblock dem ersten Subkontext nicht zugewiesen ist.
29. Das computerimplementierte Verfahren eines der Abschnitte 21-28, das weiterhin umfasst: Empfangen einer Angabe, dass eine zweite Thread-Gruppe, die einem zweiten Subkontext zugeordnet ist, zugewiesen worden ist, um auf einem zweiten Prozessor ausgeführt zu werden; Identifizieren einer zweiten Aufzeichnung in der Lokalspeicherblock-Zuweisungstabelle entsprechend dem zweiten Subkontext und dem zweiten Prozessor; und Ermitteln, dass ein Speicherblock bereits dem zweiten Subkontext zugewiesen worden ist.
30. Das computerimplementierte Verfahren eines der Abschnitte 21-29, wobei mit einer ersten Thread-Gruppe gestartet wird, um auf dem ersten Prozessor auszuführen, bevor der Wert in der ersten Aufzeichnung gespeichert wird, der angibt, dass der erste Lokalspeicherblock dem ersten Subkontext zugeordnet ist.
31. In manchen Ausführungsformen umfasst ein Parallelverarbeitungssystem: einen Scheduler, der eine Vielzahl von Aufgaben an einen Rechenarbeitsverteiler sendet; und einen Rechenarbeitsverteiler, der: eine Aufgabe entsprechend einem Prozess aus einer einem ersten Subkontext zugeordneten Aufgabenliste auswählt, eine dem ersten Subkontext zugeordnete erste Thread-Gruppe identifiziert, die zur Ausführung auf einem ersten Prozessor zugeordnet worden ist, ermittelt, dass der erste Subkontext mindestens ein Prozessor-Guthaben aufweist, eine erste Aufzeichnung in einer Lokalspeicherblock-Zuweisungstabelle entsprechend dem ersten Subkontext identifiziert, einen ersten Lokalspeicherblock identifiziert, der gegenwärtig nicht zugewiesen ist, und einen ersten Wert in der ersten Aufzeichnung speichert, der angibt, dass der erste Lokalspeicherblock dem ersten Subkontext und dem ersten Prozessor zugewiesen ist.
32. Das Parallelverarbeitungssystem von Abschnitt 31, wobei der Rechenarbeitsverteiler weiterhin einen ersten Index zu dem ersten Lokalspeicherblock in der ersten Aufzeichnung speichert.
33. Das Parallelverarbeitungssystem von Abschnitt 31 oder Abschnitt 32, wobei der Rechenarbeitsverteiler weiterhin: eine dem ersten Subkontext zugeordnete zweite Thread-Gruppe identifiziert, die zur Ausführung auf einem zweiten Prozessor zugewiesen worden ist; die erste Aufzeichnung in der Lokalspeicherblock-Zuteilungstabelle entsprechend dem ersten Subkontext identifiziert; einen zweiten Lokalspeicherblock identifiziert, der gegenwärtig nicht zugewiesen ist; einen zweiten Wert in der ersten Aufzeichnung speichert, der angibt, dass der zweite Lokalspeicherblock dem ersten Subkontext und dem zweiten Prozessor zugewiesen ist; und einen zweiten Index zu dem zweiten Lokalspeicherblock in der ersten Aufzeichnung speichert, wobei der zweite Index größer als der erste Index ist.
34. Das Parallelverarbeitungssystem eines der Abschnitte 31-33, wobei: der erste Prozessor und der zweite Prozessor in einem Verarbeitungscluster enthalten sind; und der erste Lokalspeicherblock sowohl für den ersten Prozessor als auch für den zweiten Prozessor zugänglich ist.
35. Das Parallelverarbeitungssystem eines der Abschnitte 31-34, wobei der erste Prozessor und der zweite Prozessor in einer Vielzahl von Prozessoren enthalten sind und die Lokalspeicherblock-Zuweisungstabelle durch ein Betriebssystem oder einen Hypervisor initialisiert wird, bevor irgendeine Gruppe von Threads zur Ausführung auf irgendeinen Prozessor, der in der Vielzahl von Prozessoren enthalten ist, gestartet wird.
36. Das Parallelverarbeitungssystem eines der Abschnitte 31-35, wobei der Rechenarbeitsverteiler weiterhin: den ersten Index zu dem ersten Lokalspeicherblock aus der ersten Aufzeichnung abruft; und den ersten Lokalspeicherblock dem ersten Index zuordnet.
37. Das Parallelverarbeitungssystem eines der Abschnitte 31-36, wobei der erste Prozessor über einen dem ersten Subkontext zugeordneten virtuellen Adressraum auf den ersten Lokalspeicherblock zugreift.
38. Das Parallelverarbeitungssystem eines der Abschnitte 31-37, wobei der Rechenarbeitsverteiler weiterhin: ein Startpaket für den ersten Prozessor erzeugt, das eine dem virtuellen Adressraum zugeordnete Seitenverzeichnis-Basisadresse enthält; und das Startpaket an den ersten Prozessor sendet.
39. Das Parallelverarbeitungssystem eines der Abschnitte 31-38, wobei das Startpaket weiterhin Lokalspeicher-Zuweisungsinformationen in Bezug auf den ersten Lokalspeicherblock enthält.
40. In manchen Ausführungsformen umfasst ein computerimplementiertes Verfahren zum Zuweisen von lokalem Speicher zu Thread-Gruppen innerhalb einer Grafikverarbeitungseinheit: Empfangen einer Angabe, dass eine erste Thread-Gruppe, die einem ersten Subkontext zugeordnet ist, zur Ausführung auf einem ersten Prozessor zugewiesen worden ist; Identifizieren einer ersten Aufzeichnung in einer Lokalspeicherblock-Zuweisungstabelle entsprechend dem ersten Subkontext; Ermitteln, ob Lokalspeicherblöcke, die in einer Vielzahl von Lokalspeicherblöcken enthalten sind, statisch zugewiesen sind; und wenn die in der Vielzahl von Lokalspeicherblöcken enthaltenen Lokalspeicherblöcke statisch zugewiesen sind, dann Abrufen eines ersten Index, der einem ersten Lokalspeicherblock zugeordnet ist, aus der ersten Aufzeichnung, oder wenn die in der Vielzahl von Lokalspeicherblöcken enthaltenen Lokalspeicherblöcke nicht statisch zugewiesen sind, dann Identifizieren eines zweiten Lokalspeicherblocks, der gegenwärtig nicht zugewiesen ist; und Speichern eines zweiten Index, der dem zweiten Lokalspeicherblock in der ersten Aufzeichnung zugeordnet ist.
Irgendwelche und alle Kombinationen irgendwelcher der in irgendeinem der Ansprüche angegebenen Anspruchselemente und/oder irgendwelcher in dieser Anmeldung beschriebenen Elemente fällt in irgendeiner Weise in den ins Auge gefassten Schutzbereich der vorliegenden Erfindung und den Schutz.
Die Beschreibungen der verschiedenen Ausführungsformen wurden zwecks Veranschaulichung gegeben, sollen aber nicht erschöpfend oder auf die offenbarten Ausführungsformen beschränkt sein. Viele Modifikationen und Abweichungen ergeben sich für den Fachmann, ohne den Schutzbereich und Geist der beschriebenen Ausführungsformen zu verlassen.
Aspekte der vorliegenden Ausführungsformen können als ein System, Verfahren oder Computerprogrammprodukt ausgeführt werden. Dementsprechend können Aspekte der vorliegenden Offenbarung die Form einer vollständigen Hardware-Ausführungsform, einer vollständigen Software-Ausführungsform (einschließlich Firmware, residenter Software, Mikrocode usw.) oder einer Ausführungsform, die Soft- und Hardwareaspekte kombiniert, die hierin alle allgemein als ein „Modul“ oder „System“ bezeichnet werden können, annehmen. Darüber hinaus können Aspekte der vorliegenden Offenbarung die Form eines Computerprogrammprodukts annehmen, das in einem oder mehreren computerlesbaren Medien mit einem darauf verkörperten computerlesbaren Programmcode verkörpert ist.
Es kann irgendeine Kombination von einem oder mehreren computerlesbaren Medien verwendet werden. Das computerlesbare Medium kann ein computerlesbares Signalmedium oder ein computerlesbares Speichermedium sein. Ein computerlesbares Speichermedium kann zum Beispiel, ohne darauf beschränkt zu sein, ein elektronisches, magnetisches, optisches, elektromagnetisches, Infrarot- oder Halbleitersystem, eine Vorrichtung oder ein Gerät oder irgendeine geeignete Kombination der vorgenannten sein. Speziellere Beispiele (eine nicht abschließende Liste) für das computerlesbare Speichermedium wären: eine elektrische Verbindung mit einem oder mehreren Kabeln, eine tragbare CD, eine Festplatte, ein Direktzugriffsspeicher (RAM), ein Nur-Lese-Speicher (ROM), ein löschbarer programmierbarer Nur-Lese-Speicher (EPROM oder Flash-Speicher), eine Glasfaser, ein tragbarer CD-ROM-Speicher, ein optisches Speichergerät, ein magnetisches Speichergerät oder irgendeine geeignete Kombination der vorgenannten. Im Kontext dieses Dokuments kann ein computerlesbares Speichermedium irgendein materielles Medium sein, das ein Programm zur Verwendung durch oder in Verbindung mit einem System, einer Vorrichtung oder einem Gerät zur Ausführung von Anweisungen enthalten oder speichern kann.
Aspekte der vorliegenden Offenbarung sind oben unter Bezugnahme auf Flussdiagramm-Darstellungen und/oder Blockdiagramme von Verfahren, Geräten (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der Offenbarung beschrieben. Es versteht sich, dass jeder Block der Flussdiagramm-Darstellungen und/oder Blockdiagramme und Kombinationen von Blöcken in den Flussdiagramm-Darstellungen und/oder Blockdiagrammen durch Computerprogrammanweisungen implementiert werden können. Diese Computerprogrammanweisungen können einem Prozessor eines Universalcomputers, eines Spezialcomputers oder eines anderen programmierbaren Datenverarbeitungsgeräts bereitgestellt werden, um eine Maschine herzustellen, so dass die Anweisungen, die über den Prozessor des Computers oder anderen programmierbaren Datenverarbeitungsgeräts ausgeführt werden, die Implementierung der in dem Flussdiagramm- und/oder Blockdiagramm-Block oder den Blöcken angegebenen Funktionen/Aktionen ermöglichen. Solche Prozessoren können ohne Beschränkung Universalprozessoren, Spezialprozessoren, anwendungsspezifische Prozessoren oder feldprogrammierbare Gate-Arrays sein.
Das Flussdiagramm und die Blockdiagramme in den Figuren veranschaulichen die Architektur, Funktionalität und den Betrieb möglicher Implementierungen von Systemen, Methoden und Computerprogrammprodukten gemäß verschiedenen Ausführungsformen der vorliegenden Offenbarung. In dieser Hinsicht kann jeder Block in dem Flussdiagramm oder den Blockdiagrammen ein Modul, Segment oder einen Abschnitt von Code darstellen, der eine oder mehrere ausführbare Anweisungen zur Implementierung der spezifizierten logischen Funktion(en) umfasst. Man beachte auch, dass in manchen alternativen Implementierungen die in dem Block angegebenen Funktionen außerhalb der in den Figuren angegebenen Reihenfolge stattfinden können. Zum Beispiel können zwei aufeinanderfolgend gezeigte Blöcke im Wesentlichen gleichzeitig ausgeführt werden, oder die Blöcke können je nach der beteiligten Funktionalität manchmal in umgekehrter Reihenfolge ausgeführt werden. Man beachte auch, dass jeder Block der Blockdiagramme und/oder der Flussdiagramm-Darstellung und Kombinationen von Blöcken in den Blockdiagrammen und/oder der Flussdiagramm-Darstellung durch hardwarebasierte Spezialsysteme, die die spezifizierten Funktionen oder Aktionen durchführen, oder Kombinationen von Spezial-Hardware und Computeranweisungen implementiert werden kann
Während sich das Vorhergehende auf Ausführungsformen der vorliegenden Offenbarung bezieht, können andere und weitere Ausführungsformen der Offenbarung erdacht werden, ohne von ihrem grundlegenden Schutzbereich abzuweichen, und ihr Schutzbereich wird durch die nachfolgenden Ansprüche bestimmt.

Claims

Computerimplementiertes Verfahren zum Zuteilen von Ausführungsressourcen zu Gruppen von Threads innerhalb einer Grafikverarbeitungseinheit, wobei das Verfahren umfasst: Empfangen einer Angabe von einem Prozess, dass eine erste Gruppe von Threads zu starten ist; Ermitteln, dass ein erster Subkontext, der dem Prozess zugeordnet ist, mindestens ein Prozessor-Guthaben aufweist; Identifizieren eines ersten Prozessors, der in einer Vielzahl von Prozessoren enthalten ist und der eine Verarbeitungslast aufweist, die kleiner oder gleich den Prozessorlasten ist, die allen anderen Prozessoren zugeordnet sind, die in der Vielzahl von Prozessoren enthalten sind; und Starten der ersten Gruppe von Threads zur Ausführung auf dem ersten Prozessor.
Computerimplementiertes Verfahren nach Anspruch 1, wobei der erste Subkontext in einer Vielzahl von Subkontexten enthalten ist und jeder Subkontext, der in der Vielzahl von Subkontexten enthalten ist, einem anderen Prozess und einem anderen virtuellen Adressraum zugeordnet ist.
Computerimplementiertes Verfahren nach Anspruch 1 oder 2, wobei der erste Subkontext in einer Vielzahl von Subkontexten enthalten ist und jeder Subkontext, der in der Vielzahl von Subkontexten enthalten ist, anderen Zustandsdaten zugeordnet ist.
Computerimplementiertes Verfahren nach einem der vorhergehenden Ansprüche, wobei: der erste Subkontext in einer Vielzahl von Subkontexten enthalten ist; der erste Subkontext einem ersten virtuellen Adressraum zugeordnet ist; ein zweiter Subkontext, der in der Vielzahl von Subkontexten enthalten ist, dem ersten virtuellen Adressraum zugeordnet ist; und ein dritter Subkontext, der in der Vielzahl von Subkontexten enthalten ist, einem zweiten virtuellen Adressraum zugeordnet ist, der von dem ersten virtuellen Adressraum verschieden ist.
Computerimplementiertes Verfahren nach einem der vorhergehenden Ansprüche, das weiterhin umfasst, als Antwort auf das Starten der ersten Gruppe von Threads zur Ausführung auf dem ersten Prozessor einen dem ersten Subkontext zugeordneten Guthabenzähler zu dekrementieren.
Computerimplementiertes Verfahren nach Anspruch 5, das weiterhin umfasst: Ermitteln, dass die erste Gruppe von Threads die Ausführung auf dem ersten Prozessor abgeschlossen hat; und Inkrementieren des dem ersten Subkontext zugeordneten Guthabenzählers.
Computerimplementiertes Verfahren nach einem der vorhergehenden Ansprüche, wobei das Identifizieren eines ersten Prozessors, der in der Vielzahl der Prozessoren enthalten ist, umfasst: Ermitteln einer Zählung von verfügbaren Ausführungs-Slots für jeden Prozessor, der in der Vielzahl von Prozessoren enthalten ist; Identifizieren eines oder mehrerer Prozessoren, die in der Vielzahl von Prozessoren enthalten sind, die eine höchste Zählung von verfügbaren Ausführungs-Slots aufweisen; und Auswählen des ersten Prozessors aus den ein oder mehreren Prozessoren.
Computerimplementiertes Verfahren nach einem der vorhergehenden Ansprüche, das weiterhin umfasst, zu ermitteln, dass der erste Subkontext nicht exklusiv in Bezug auf irgendeinen Subkontext ist, der einer zweiten Gruppe von Threads zugeordnet ist, die gegenwärtig auf dem ersten Prozessor ausgeführt werden.
Computerimplementiertes Verfahren nach einem der vorhergehenden Ansprüche, das weiterhin umfasst: Abrufen einer ersten Aufzeichnung, die dem ersten Subkontext zugeordnet ist, aus einer ersten Tabelle; und Ermitteln aus der ersten Aufzeichnung, dass jeder Prozessor, der in der Vielzahl von Prozessoren enthalten ist, in Bezug auf das Ausführen mindestens einer Gruppe von Threads, die dem ersten Subkontext zugeordnet sind, verfügbar ist.
Computerimplementiertes Verfahren nach Anspruch 9, wobei die erste Tabelle durch ein Betriebssystem oder einen Hypervisor initialisiert wird, bevor irgendeine Gruppe von Threads zur Ausführung auf irgendeinen Prozessor, der in der Vielzahl von Prozessoren enthalten ist, gestartet wird.
Computerimplementiertes Verfahren nach Anspruch 9 oder 10, das weiterhin umfasst: Abrufen einer zweiten Aufzeichnung, die dem ersten Subkontext zugeordnet ist, aus einer zweiten Tabelle, wobei die zweite Aufzeichnung eine andere virtuelle Prozessorkennung für jeden Prozessor spezifiziert, der in der Vielzahl von Prozessoren enthalten ist und der in Bezug auf das Ausführen mindestens einer Gruppe von Threads, die dem ersten Subkontext zugeordnet sind, verfügbar ist; und Identifizieren einer virtuellen Prozessorkennung für den ersten Prozessor aus der zweiten Aufzeichnung; wobei der erste Prozessor eine Speicheradressenberechnung auf Basis der virtuellen Prozessorkennung durchführt.
Parallelverarbeitungssystem, umfassend: einen Scheduler, der eine Vielzahl von Aufgaben an einen Rechenarbeitsverteiler sendet; und ein Rechenarbeitsverteiler, der: eine in der Vielzahl von Aufgaben enthaltene Aufgabe entsprechend einem Prozess aus einer einem ersten Subkontext zugeordneten Aufgabenliste auswählt, eine der zu startenden Aufgabe zugeordnete erste Thread-Gruppe identifiziert, ermittelt, dass der erste Subkontext mindestens ein Prozessor-Guthaben aufweist, einen ersten Prozessor identifiziert, der in einer Vielzahl von Prozessoren enthalten ist und der eine Verarbeitungslast aufweist, die kleiner oder gleich den Prozessorlasten ist, die allen anderen Prozessoren zugeordnet sind, die in der Vielzahl von Prozessoren enthalten sind, und die erste Gruppe von Threads zur Ausführung auf dem ersten Prozessor startet.
Parallelverarbeitungssystem nach Anspruch 12, wobei der Rechenarbeitsverteiler weiterhin ermittelt, dass der erste Prozessor verfügbar ist, um die erste Gruppe von Threads auszuführen.
Parallelverarbeitungssystem nach Anspruch 12 oder 13, wobei der Rechenarbeitsverteiler weiterhin als Antwort auf das Starten der ersten Gruppe von Threads zur Ausführung auf dem ersten Prozessor einen dem ersten Subkontext zugeordneten Guthabenzähler dekrementiert.
Parallelverarbeitungssystem nach Anspruch 14, wobei der Rechenarbeitsverteiler weiterhin: ermittelt, dass die erste Gruppe von Threads die Ausführung auf dem ersten Prozessor abgeschlossen hat; und den dem ersten Subkontext zugeordneten Guthabenzähler inkrementiert.
Parallelverarbeitungssystem nach einem der Ansprüche 12 bis 15, wobei das Identifizieren eines ersten Prozessors, der in der Vielzahl der Prozessoren enthalten ist, umfasst: Ermitteln einer Zählung von verfügbaren Ausführungs-Slots für jeden Prozessor, der in der Vielzahl von Prozessoren enthalten ist; Identifizieren eines oder mehrerer Prozessoren, die in der Vielzahl von Prozessoren enthalten sind, die eine höchste Zählung von verfügbaren Ausführungs-Slots aufweisen; und Auswählen des ersten Prozessors aus den ein oder mehreren Prozessoren.
Parallelverarbeitungssystem nach einem der Ansprüche 12 bis 16, wobei der Rechenarbeitsverteiler weiterhin: ein Startpaket für den ersten Prozessor erzeugt, das die erste Gruppe von Threads enthält; und das Startpaket an den ersten Prozessor sendet.
Parallelverarbeitungssystem nach Anspruch 17, wobei das Startpaket weiterhin eine dem ersten Subkontext entsprechende Zahl enthält.
Parallelverarbeitungssystem nach Anspruch 17 oder 18, wobei das Parallelverarbeitungssystem einer Servermaschine zugeordnet ist, die in einem Rechenzentrum enthalten ist.
Computerimplementiertes Verfahren zum Zuteilen von Ausführungsressourcen zu Gruppen von Threads innerhalb einer Grafikverarbeitungseinheit, wobei das Verfahren umfasst: Empfangen einer Angabe von einem Prozess, dass eine erste Gruppe von Threads zu starten ist, wobei der erste Subkontext in einer Vielzahl von Subkontexten enthalten ist und jeder Subkontext, der in der Vielzahl von Subkontexten enthalten ist, einem anderen Prozess und einem anderen virtuellen Adressraum zugeordnet ist; Ermitteln, ob der erste Subkontext mindestens ein Prozessor-Guthaben aufweist; und wenn der erste Subkontext mindestens ein Prozessor-Guthaben aufweist, dann: Identifizieren eines ersten Prozessors, der in einer Vielzahl von Prozessoren enthalten ist und der eine Verarbeitungslast aufweist, die kleiner oder gleich den Prozessorlasten ist, die allen anderen Prozessoren zugeordnet sind, die in der Vielzahl von Prozessoren enthalten sind, und Starten der ersten Gruppe von Threads zur Ausführung auf dem ersten Prozessor; oder wenn der erste Subkontext nicht mindestens ein Prozessor-Guthaben aufweist, dann: Identifizieren eines Teilsatzes von Prozessoren, die in der Vielzahl von Prozessoren enthalten sind, die bereits dem ersten Subkontext zugewiesen sind, Identifizieren eines zweiten Prozessors, der in dem Teilsatz von Prozessoren enthalten ist und der eine Verarbeitungslast aufweist, die kleiner oder gleich den Prozessorlasten ist, die allen anderen Prozessoren zugeordnet sind, die in dem Teilsatz von Prozessoren enthalten sind; und Starten der ersten Gruppe von Threads auf dem zweiten Prozessor.