DE102020123164A1

DE102020123164A1 - Techniken zum konfigurieren eines prozessors, um wie mehrere, separate prozessoren zu funktionieren

Info

Publication number: DE102020123164A1
Application number: DE102020123164.4A
Authority: DE
Inventors: Jerome F. Duluk jun.; Gregory Scott Palmer; Jonathon Stuart Ramsay EVANS; Shailendra Singh; Samuel H. Duncan; Wishwesh Anil GANDHI; Lacky V. Shah; Eric Rock; Feiqi Su; James Leroy Deming; Alan Menezes; Pranav Vaidya; Praveen Joginipally; Timothy John Purcell; Manas Mandal
Original assignee: Nvidia Corp
Current assignee: Nvidia Corp
Priority date: 2019-09-05
Filing date: 2020-09-04
Publication date: 2021-03-11
Also published as: US11663036B2; CN112445609A; US20210073025A1

Abstract

Eine Parallelverarbeitungseinheit (PPU-Partition) kann in Partitionen aufgeteilt werden. Jede Partition ist so konfiguriert, dass sie ähnlich funktioniert wie die gesamte PPU-Partition. Eine bestimmte Partition umfasst einen Teilsatz der mit der gesamten PPU assoziierten Rechen- und Speicherressourcen. Software, die auf einer CPU ausgeführt wird, partitioniert die PPU-Partition für einen Admin-Benutzer. Ein Gastbenutzer wird einer Partition zugewiesen und kann innerhalb dieser Partition isoliert von allen anderen Gastbenutzern, die beliebigen anderen Partitionen zugewiesen sind, Verarbeitungsaufgaben ausführen. Da die PPU in isolierte Partitionen aufgeteilt werden kann, können mehrere CPU-Prozesse die PPU-Ressourcen effizient nutzen.

Description

HINTERGRUND
Bereich der verschiedenen Ausführungsbeispiele
Verschiedene Ausführungsbeispiele beziehen sich im Allgemeinen auf Parallelverarbeitungsarchitekturen, genauer gesagt auf Techniken zur Konfiguration eines Prozessors, so dass er wie mehrere, separate Prozessoren funktioniert.
Beschreibung von verwandten Techniken
Eine herkömmliche Zentralverarbeitungseinheit (engl. central processing unit, CPU) umfasst in der Regel eine relativ kleine Anzahl von Verarbeitungskernen, die eine relativ kleine Anzahl von CPU-Prozessen ausführen können. Im Gegensatz dazu umfasst eine herkömmliche Grafikverarbeitungseinheit (engl. graphics processing unit, GPU) in der Regel Hunderte von Verarbeitungskernen, die Hunderte von Threads parallel zueinander ausführen können. Dementsprechend können herkömmliche GPUs in der Regel bestimmte Verarbeitungsaufgaben schneller und effektiver ausführen als herkömmliche CPUs, da bei Verwendung herkömmlicher GPUs eine größere Menge an Verarbeitungsressourcen bereitgestellt werden kann.
In einigen Implementierungen kann ein CPU-Prozess, der auf einer CPU ausgeführt wird, eine bestimmte Verarbeitungsaufgabe an eine GPU abgeben, so dass diese Verarbeitungsaufgabe schneller ausgeführt werden kann. Dabei erzeugt der CPU-Prozess einen Verarbeitungskontext auf der GPU, der einen Zielzustand für die verschiedenen GPU-Ressourcen angibt, die zur Ausführung der Verarbeitungsaufgabe implementiert werden sollen. Diese GPU-Ressourcen können u. a. Verarbeitungs-, Grafik- und Speicherressourcen umfassen. Der CPU-Prozess startet dann eine Reihe von Threads auf der GPU entsprechend dem Verarbeitungskontext, und die Reihe von Threads verwendet die verschiedenen GPU-Ressourcen, um die Verarbeitungsaufgabe auszuführen. Bei vielen dieser Arten von Implementierungen ist die GPU jeweils nur für einen Verarbeitungskontext konfiguriert. In einigen Situationen muss die CPU jedoch mehr als einen CPU-Prozess während desselben Zeitintervalls an die GPU abgeben. In solchen Situationen kann die CPU den auf der GPU implementierten Verarbeitungskontext zu verschiedenen Zeitpunkten dynamisch ändern, um diese CPU-Prozesse über das Zeitintervall hinweg seriell zu bedienen. Ein Nachteil dieses Ansatzes ist jedoch, dass die von bestimmten CPU-Prozessen ausgelagerten Verarbeitungsaufgaben die Ressourcen des Grafikprozesses nicht vollständig ausnutzen. Wenn daher eine oder mehrere Verarbeitungsaufgaben, die mit diesen CPU-Prozessen assoziiert sind, seriell auf der GPU ausgeführt werden, können einige GPU-Ressourcen ungenutzt bleiben, was die Gesamtleistung und -auslastung der GPU verringert.
Ein Ansatz zur gleichzeitigen Ausführung mehrerer CPU-Prozesse auf einer GPU besteht darin, mehrere verschiedene Verarbeitungssubkontexte innerhalb eines gegebenen „übergeordneten“ Verarbeitungskontextes zu erzeugen und jeden verschiedenen Verarbeitungssubkontext einem anderen CPU-Prozess zuzuordnen. Mehrere CPU-Prozesse können dann gleichzeitig verschiedene Sätze von Threads auf der GPU starten, wobei jeder Thread-Satz spezifische GPU-Ressourcen verwendet, die entsprechend einem bestimmten Verarbeitungssubkontext konfiguriert sind. Mit diesem Ansatz kann die GPU effizienter genutzt werden, da mehr als ein CPU-Prozess gleichzeitig Verarbeitungsaufgaben an die GPU abgeben kann, wodurch Situationen vermieden werden können, in denen einige GPU-Ressourcen ungenutzt bleiben.
Ein Problem des obigen Ansatzes besteht darin, dass CPU-Prozesse, die mit verschiedenen Verarbeitungssubkontexten assoziiert sind, GPU-Ressourcen auf ungerechte Weise verbrauchen können, die gleichmäßiger zugewiesen oder auf die verschiedenen Verarbeitungssubkontexte verteilt werden sollten. Beispielsweise könnte ein erster CPU-Prozess einen ersten Satz von Threads innerhalb eines ersten Verarbeitungssubkontextes starten, der eine große Menge von Leseanforderungen ausführt und eine große Menge an verfügbarer GPU-Speicherbandbreite verbraucht. Ein zweiter CPU-Prozess könnte anschließend einen zweiten Satz von Threads innerhalb eines zweiten Verarbeitungssubkontextes starten, der ebenfalls eine große Menge von Leseanforderungen durchführt. Da jedoch ein Großteil der verfügbaren GPU-Speicherbandbreite bereits von der ersten Gruppe von Threads verbraucht wird, könnte es bei der zweiten Gruppe von Threads zu hohen Latenzen kommen, was zu einem Stillstand des zweiten CPU-Prozesses führen könnte.
Ein weiteres Problem mit dem obigen Ansatz besteht darin, dass aufgrund der Tatsache, dass sich die verarbeitenden Subkontexte einen übergeordneten Kontext teilen, beliebige Fehler, die auftreten, wenn die Threads, die mit einer Ausführung eines verarbeitenden Subkontextes assoziiert sind, die Ausführung anderer Threads stören können, die mit einem anderen verarbeitenden Subkontext assoziiert sind, der denselben übergeordneten Kontext teilt. Beispielsweise könnte ein erster CPU-Prozess einen ersten Satz von Threads starten, die mit einem ersten Verarbeitungssubkontext assoziiert sind, um eine erste Verarbeitungsaufgabe auszuführen. Ein zweiter CPU-Prozess könnte eine zweite Gruppe von Threads starten, die mit einem zweiten Verarbeitungssubkontext assoziiert sind, und die zweite Gruppe von Threads könnte anschließend fehlerhaft werden und fehlschlagen. Um den Fehler zu beheben, müsste die GPU den übergeordneten Kontext zurücksetzen, wodurch sowohl der erste Verarbeitungssubkontext als auch der zweite Verarbeitungssubkontext automatisch zurückgesetzt würden. In einem solchen Szenario würde die Ausführung der ersten Gruppe von Threads unterbrochen werden, obwohl der Fehler in der zweiten Gruppe von Threads und nicht in der ersten Gruppe von Threads auftrat.
Wie vorstehend gezeigt wurde, sind in diesem Bereich effektivere Techniken zur Konfiguration einer GPU erforderlich, um Verarbeitungsaufgaben auszuführen, die mit mehreren Kontexten assoziiert sind.
ZUSAMMENFASSUNG
Verschiedene Ausführungsbeispiele umfassen ein computerimplementiertes Verfahren, einschließlich eines Partitionierens eines Satzes von Hardwareressourcen, die in einem Prozessor enthalten sind, um eine erste logische Partition zu erzeugen, die einen ersten Teilsatz von Hardwareressourcen enthält, und eines Erzeugens einer Vielzahl von Engines innerhalb der ersten logischen Partition, wobei jeder Engine, die in der Vielzahl von Engines enthalten ist, ein anderer Teil des ersten Teilsatzes von Hardwareressourcen zugewiesen wird und sie in funktionaler Isolierung von allen anderen Engines, die in der Vielzahl von Engines enthalten sind, ausgeführt wird.
Ein technologischer Vorteil der offenbarten Techniken gegenüber dem Stand der Technik besteht darin, dass mit den offenbarten Techniken eine Parallelverarbeitungseinheit (PPU) (wie z.B. eine GPU) mehrere Kontexte gleichzeitig und in funktionaler Isolierung voneinander unterstützen kann. Dementsprechend können mehrere CPU-Prozesse PPU-Ressourcen effizient nutzen, indem sie gleichzeitig mehrere verschiedene Kontexte ausführen, ohne dass sich die Kontexte gegenseitig stören.
Figurenliste
Um die Art und Weise, in der die oben angeführten Merkmale der verschiedenen Ausführungsbeispiele im Einzelnen verstanden werden können, zu erläutern, kann eine genauere Beschreibung der oben kurz zusammengefassten erfinderischen Konzepte anhand verschiedener Ausführungsbeispiele erfolgen, von denen einige in den beigefügten Zeichnungen gezeigt werden. Es ist jedoch darauf hinzuweisen, dass die beigefügten Zeichnungen nur typische Ausführungsbeispiele der erfinderischen Konzepte zeigen und daher nicht als in irgendeiner Weise einschränkend zu betrachten sind, und dass es andere ebenso geeignete Ausführungsbeispiele gibt.

1 zeigt ein Blockdiagramm eines Computersystems, das konfiguriert ist, um einen oder mehrere Aspekte der verschiedenen Ausführungsbeispiele zu implementieren;
2 zeigt ein Blockdiagramm einer Parallelverarbeitungseinheit (PPU), die im Parallelverarbeitungs-Subsystem von 1 enthalten ist, gemäß verschiedenen Ausfü hru ngsbeispielen;
3 zeigt ein Blockdiagramm eines allgemeinen Verarbeitungsclusters, der in der Parallelverarbeitungseinheit von 2 enthalten ist, gemäß verschiedenen Ausführungsbeispielen;
4 zeigt ein Blockdiagramm einer Partitionseinheit, die in der PPU von 2 enthalten ist, gemäß verschiedenen Ausführungsbeispielen;
5 zeigt ein Blockdiagramm der verschiedenen PPU-Ressourcen, die in den PPU von 2 enthalten sind, gemäß verschiedenen Ausführungsbeispielen;
6 zeigt in einem Beispiel, wie der Hypervisor von 1 PPU-Ressourcen logisch in einen Satz von PPU-Partitionen gruppiert, gemäß verschiedenen Ausführungsbeispielen;
7 zeigt, wie der Hypervisor in 1 einen Satz von PPU-Partitionen konfiguriert, um eine oder mehrere Simultane-Multiple-Context (SMC)-Engines zu implementieren, gemäß verschiedenen Ausführungsbeispielen;
8A zeigt eine detaillierte Darstellung des DRAMs von 7, gemäß verschiedenen Ausführungsbeispielen;
8B zeigt, wie die verschiedenen DRAM-Bereiche von 8B adressiert werden, gemäß verschiedenen Ausführungsbeispielen;
9 zeigt ein Datenflussdiagramm, das illustriert, wie der Hypervisor von 1 eine PPU partitioniert und konfiguriert, gemäß verschiedenen Ausführungsbeispielen;
10 zeigt ein Flussdiagramm mit Verfahrensschritten zum Partitionieren und Konfigurieren einer PPU im Auftrag eines oder mehrerer Benutzer, gemäß verschiedenen Ausführungsbeispielen;
11 zeigt eine Partitionskonfigurationstabelle, nach der der Hypervisor in 1 eine oder mehrere PPU-Partitionen konfigurieren kann, gemäß verschiedenen Ausführungsbeispielen;
12 zeigt, wie der Hypervisor von 1 eine PPU partitioniert, um eine oder mehrere PPU-Partitionen zu erzeugen, gemäß verschiedenen Ausführungsbeispielen;
13 zeigt, wie der Hypervisor von 1 während der Partitionierung verschiedene PPU-Ressourcen zuweist, gemäß verschiedenen Ausführungsbeispielen;
14A zeigt, wie mehrere Gastbetriebssysteme, auf denen mehrere VMs laufen, mehrere Verarbeitungskontexte gleichzeitig innerhalb einer oder mehrerer PPU-Partitionen starten, gemäß verschiedenen Ausführungsbeispielen;
14B zeigt, wie ein Host-Betriebssystem mehrere Verarbeitungskontexte gleichzeitig innerhalb einer oder mehrerer PPU-Partitionen startet, gemäß verschiedenen Ausführungsbeispielen;
15 zeigt, wie der Hypervisor von 1 die virtuellen Adressraumidentifikatoren den verschiedenen SMC-Engines zuordnet, gemäß verschiedenen Ausführungsbeispielen;
16 zeigt, wie eine Speicherverwaltungseinheit lokale virtuellen Adressraumidentifikatoren bei der Fehlerkorrektur übersetzt, gemäß verschiedenen Ausführungsbeispielen;
17 zeigt, wie der Hypervisor von 1 ein Soft-Floorsweeping implementiert, wenn ein Verarbeitungskontext zwischen SMC-Engines auf verschiedenen PPUs migriert wird, gemäß verschiedenen Ausführungsbeispielen;
18 zeigt ein Flussdiagramm mit Verfahrensschritten zum Konfigurieren von Rechenressourcen innerhalb einer PPU, um Operationen, die mit mehreren Verarbeitungskontexten assoziiert sind, gleichzeitig zu unterstützen, gemäß verschiedenen Ausführungsbeispielen;
19 zeigt einen Satz von Begrenzungsoptionen, nach denen der Hypervisor von 1 eine oder mehrere PPU-Speicherpartitionen erzeugen kann, gemäß verschiedenen Ausführungsbeispielen;
20 zeigt in einem Beispiel, wie der Hypervisor von 1 PPU-Speicher partitioniert, um eine oder mehrere PPU-Speicherpartitionen zu erzeugen, gemäß verschiedenen Ausführungsbeispielen;
21 zeigt, wie die Speicherverwaltungseinheit von 16 Zugriff auf verschiedene PPU-Speicherpartitionen ermöglicht, gemäß verschiedenen Ausführungsbeispielen;
22 zeigt, wie die Speicherverwaltungseinheit von 16 verschiedene Adressübersetzungen durchführt, gemäß verschiedenen Ausführungsbeispielen;
23 zeigt, wie die Speicherverwaltungseinheit von 16 Unterstützungsoperationen, die mit mehreren Verarbeitungskontexten gleichzeitig assoziiert sind, bereitstellt, gemäß verschiedenen Ausführungsbeispielen;
24 zeigt ein Flussdiagramm mit Verfahrensschritten zum Konfigurieren von Speicherressourcen innerhalb einer PPU, um Operationen, die mit mehreren Verarbeitungskontexten assoziiert sind, gleichzeitig zu unterstützen, gemäß verschiedenen Ausführungsbeispielen;
25 zeigt einen Satz von Zeitreihen, die ein zeitliches Aufteilen (engl. time-slicing) auf VM-Ebene zeigen, das mit der PPU von 2 assoziiert ist, gemäß verschiedenen Ausführungsbeispielen;
26 zeigt einen weiteren Satz von Zeitreihen, der ein zeitliches Aufteilen auf VM-Ebene zeigt, das mit der PPU von 2 assoziiert ist, gemäß verschiedenen anderen Ausführungsbeispielen;
27 zeigt eine Zeitreihe, die ein zeitliches Aufteilen auf SCM-Ebene zeigt, das mit der PPU von 2 assoziiert ist, gemäß verschiedenen Ausführungsbeispielen;
28 zeigt, wie VMs von einer PPU zu einer anderen PPU migrieren können, gemäß verschiedenen Ausführungsbeispielen;
29 zeigt einen Satz von Zeitreihen, die eine feine VM-Migration zeigen, die mit der PPU von 2 assoziiert ist, gemäß verschiedenen Ausführungsbeispielen;
30A-30B zeigen ein Flussdiagramm mit Verfahrensschritten für das zeitliche Aufteilen von VMs in der PPU von 2, gemäß verschiedenen Ausführungsbeispielen;
31 zeigt eine Speicherkarte, die zeigt, wie der BAR0-Adressraum auf den privilegierten Registerraum innerhalb der PPU von 2 abgebildet wird, gemäß verschiedenen Ausführungsbeispielen;
32 zeigt ein Flussdiagramm mit Verfahrensschritten zur Adressierung des privilegierten Registeradressraums in der PPU von 2, gemäß verschiedenen Ausführungsbei spielen;
33 zeigt ein Blockdiagramm eines Leistungsüberwachungssystems für die PPU von 2, gemäß verschiedenen Ausführungsbeispielen;
34A-34B zeigen verschiedene Konfigurationen der Leistungsmultiplexer-Einheiten aus 33, gemäß verschiedenen Ausführungsbeispielen;
35 zeigt ein Blockdiagramm eines Leistungsüberwachungs-Aggregationssystems für die PPU von 2, gemäß verschiedenen Ausführungsbeispielen;
36 zeigt das Format der Auslöserpakete, die mit dem Leistungsüberwachungs-Aggregationssystem von 35 assoziiert sind, gemäß verschiedenen Ausführungsbeispielen;
37 zeigt ein Flussdiagramm mit Verfahrensschritten zur Überwachung der Leistung der PPU von 2, gemäß verschiedenen Ausführungsbeispielen;
38 zeigt ein Blockdiagramm eines Leistungs- und Taktfrequenzverwaltungssystems für die PPU von 2, gemäß verschiedenen Ausführungsbeispielen; und
39 zeigt ein Flussdiagramm mit Verfahrensschritten zur Verwaltung des Stromverbrauchs der PPU 200 aus 2, gemäß verschiedenen Ausführungsbeispielen.

DETAILLIERTE BESCHREIBUNG
In der folgenden Beschreibung werden zahlreiche spezifische Details dargelegt, um ein tieferes Verständnis der verschiedenen Ausführungsbeispiele zu ermöglichen. Für den Fachmann wird es jedoch offensichtlich sein, dass die erfinderischen Konzepte auch ohne eine oder mehrere dieser spezifischen Details ausgeführt werden können.
Wie bereits erwähnt, können herkömmliche GPUs bestimmte Verarbeitungsaufgaben in der Regel schneller ausführen als herkömmliche CPUs. In einigen Konfigurationen kann ein auf einer CPU ausgeführter CPU-Prozess eine bestimmte Verarbeitungsaufgabe an eine GPU abgeben, um diese Verarbeitungsaufgabe schneller auszuführen. Dabei erzeugt der CPU-Prozess auf der GPU einen Verarbeitungskontext, der einen Zielzustand für verschiedene GPU-Ressourcen angibt, und startet dann einen Satz Threads auf der GPU, um die Verarbeitungsaufgabe auszuführen.
In einigen Situationen kann es erforderlich sein, dass mehr als ein CPU-Prozess während desselben Zeitintervalls Verarbeitungsaufgaben an die GPU abgeben muss. Die GPU kann jedoch jeweils nur für einen Verarbeitungskontext konfiguriert werden. In solchen Situationen kann die CPU den Verarbeitungskontext der GPU zu verschiedenen Zeitpunkten dynamisch ändern, um die mehreren CPU-Prozesse über das Zeitintervall hinweg seriell zu bedienen. Es kann jedoch vorkommen, dass bestimmte CPU-Prozesse die GPU-Ressourcen bei der Ausführung von Verarbeitungsaufgaben nicht voll auslasten, so dass verschiedene GPU-Ressourcen zeitweise ungenutzt bleiben. Um dieses Problem zu beheben, kann die CPU mehrere Verarbeitungssubkontexte innerhalb eines „übergeordneten“ Verarbeitungskontextes erzeugen und diese Verarbeitungssubkontexte verschiedenen CPU-Prozessen zuweisen. Diese CPU-Prozesse können dann gleichzeitig verschiedene Sätze von Threads auf der GPU starten, und jeder Satz von Threads kann bestimmte GPU-Ressourcen nutzen, die entsprechend einem bestimmten Verarbeitungssubkontext konfiguriert sind. Dieser Ansatz kann zur effizienteren Nutzung von GPU-Ressourcen implementiert werden. Dieser Ansatz weist jedoch einige Nachteile auf.
Erstens können CPU-Prozesse, die mit verschiedenen Verarbeitungssubkontexten assoziiert sind, GPU-Ressourcen auf ungerechte Weise verbrauchen, die gerecht auf die verschiedenen Verarbeitungssubkontexte verteilt werden sollten, was zu Situationen führen kann, in denen ein CPU-Prozess den Fortschritt eines anderen CPU-Prozesses blockieren kann. Zweitens, da sich die Verarbeitungssubkontexte einen übergeordneten Verarbeitungskontext teilen, können beliebige Fehler, die während der Ausführung von Threads auftreten, die mit einem Verarbeitungssubkontext assoziiert sind, die Ausführung von Threads stören, die mit anderen Verarbeitungssubkontexten assoziiert sind, die denselben übergeordneten Verarbeitungskontext umfassen. In einigen Fällen kann ein Fehler, der innerhalb eines Verarbeitungssubkontextes auftritt, dazu führen, dass alle anderen Verarbeitungssubkontexte innerhalb desselben übergeordneten Verarbeitungskontextes zurückgesetzt und neu gestartet werden.
Im Allgemeinen schränken die oben genannten Nachteile, die mit der Verarbeitung von Subkontexten assoziiert sind, das Ausmaß ein, in dem konventionelle GPUs Mehrmandantenfähigkeit (engl. multitenancy) unterstützen können. Wie hierin erwähnt, bezieht sich „Mehrmandantenfähigkeit“ auf GPU-Konfigurationen, bei denen mehrere Benutzer oder „Mandanten“ Verarbeitungsoperationen unter Verwenden von GPU-Ressourcen gleichzeitig oder während sich überlappender Zeitintervalle durchführen. Typischerweise bieten herkömmliche GPUs Unterstützung für die Mehrmandantenfähigkeit, indem sie es verschiedenen „Mandanten“ ermöglichen, verschiedene Verarbeitungsaufgaben unter Verwenden verschiedener Verarbeitungssubkontexte innerhalb eines gegebenen übergeordneten Verarbeitungskontextes auszuführen. Verarbeitungssubkontexte sind jedoch keine isolierten Rechenumgebungen, da sich Verarbeitungsaufgaben, die innerhalb verschiedener Verarbeitungssubkontexte ausgeführt werden, aus den verschiedenen oben genannten Gründen gegenseitig stören können. Folglich kann sich jeder beliebige Mandant, der eine bestimmte GPU belegt, negativ auf die Servicequalität auswirken, die die GPU anderen Mandanten bietet. Diese Faktoren können die Attraktivität von Cloud-basierten GPU-Bereitstellungen verringern, bei denen mehrere Benutzer gleichzeitig Zugriff auf denselben GPU haben können.
Um diese Probleme zu lösen, umfassen verschiedene Ausführungsbeispiele eine Parallelverarbeitungseinheit (PPU), die in Partitionen unterteilt werden kann. Jede Partition ist so konfiguriert, dass sie Verarbeitungsaufgaben, die mit mehreren Verarbeitungskontexten assoziiert sind, gleichzeitig ausführt. Eine bestimmte Partition umfasst eine oder mehrere logische Gruppierungen oder „Abschnitte“ (engl. slices) von GPU-Ressourcen. Jeder Abschnitt bietet ausreichend Rechen-, Grafik- und Speicherressourcen, um den Betrieb der PPU als Ganzes nachzubilden. Ein Hypervisor, der auf einer CPU ausgeführt wird, führt im Auftrag eines Admin-Benutzers verschiedene Techniken zum Partitionieren der PPU aus. Ein Gastbenutzer wird einer Partition zugewiesen und kann dann innerhalb dieser Partition isoliert von allen anderen Gastbenutzern, die beliebigen anderen Partitionen zugewiesen sind, Verarbeitungsaufgaben ausführen.
Ein technologischer Vorteil der offenbarten Techniken gegenüber dem Stand der Technik besteht darin, dass eine PPU mit den offenbarten Techniken mehrere Verarbeitungskontexte gleichzeitig und in funktionaler Isolierung voneinander unterstützen kann. Dementsprechend können mehrere CPU-Prozesse PPU-Ressourcen effizient durch mehrere verschiedene Verarbeitungskontexte nutzen, ohne sich gegenseitig zu stören. Ein weiterer technologischer Vorteil der offenbarten Techniken besteht darin, dass dadurch, dass die PPU unter Verwenden der offengelegten Techniken in isolierte Computerumgebungen partitioniert werden kann, die PPU eine robustere Form der Mehrmandantenfähigkeit unterstützen kann, im Vergleich zu Ansätzen nach dem Stand der Technik, die sich zur Bereitstellung von Mehrmandantenfähigkeitsfunktionalität auf Verarbeitungssubkontexte stützen. Dementsprechend eignet sich eine PPU bei der Implementierung der offenbaren Techniken besser für Cloud-basierte Implementierungen, bei denen verschiedenen und potenziell konkurrierenden Einheiten Zugang zu verschiedenen Partitionen innerhalb derselben PPU gewährt werden kann. Diese technologischen Vorteile repräsentieren einen oder mehrere technologische Fortschritte gegenüber Ansätzen nach dem Stand der Technik.
Systemübersicht
1 zeigt ein Blockdiagramm eines Computersystems, das konfiguriert ist, um einen oder mehrere Aspekte der vorliegenden Erfindung zu implementieren. Wie dargestellt, umfasst das Computersystem 100 eine Zentralverarbeitungseinheit (CPU) 110, einen Systemspeicher 120 und ein Parallelverarbeitungs-Subsystem 130, die über eine Speicherbrücke 132 miteinander verbunden sind. Das Parallelverarbeitungs-Subsystem 130 ist über einen Kommunikationspfad 134 mit der Speicherbrücke 132 gekoppelt. Ein oder mehrere Anzeigegeräte 136 können mit dem Parallelverarbeitungs-Subsystem 130 gekoppelt werden. Computersystem 100 umfasst ferner ein Systemlaufwerk 140, eine oder mehrere Erweiterungskarten 150 und einen Netzwerkadapter 160. Das Systemlaufwerk 140 ist mit einer E/A-Brücke 142 gekoppelt. Die E/A-Brücke 142 ist über den Kommunikationspfad 144 mit der Speicherbrücke 132 gekoppelt und auch mit den Eingabegeräten 146 verbunden. Die Erweiterungskarte(n) 150 und der Netzwerkadapter 160 sind über einen Switch 148 miteinander verbunden, der seinerseits mit der E/A-Brücke 142 gekoppelt ist.
Die Speicherbrücke 132 ist eine Hardware-Einheit, die die Kommunikation zwischen CPU 110, Systemspeicher 120 und Parallelverarbeitungs-Subsystem 130 sowie anderen Komponenten des Computersystems 100 ermöglicht. Zum Beispiel könnte Speicherbrücke 132 ein Northbridge-Chip sein. Der Kommunikationspfad 134 ist eine Datenverbindung mit hoher Geschwindigkeit und/oder hoher Bandbreite, die eine Kommunikation mit geringer Latenz zwischen dem Parallelverarbeitungs-Subsystem 130 und der Speicherbrücke 132 über eine oder mehrere separate Spuren ermöglicht. Der Kommunikationspfad 134 könnte beispielsweise eine PCIe-Verbindung (PCle = Peripheral Component Interconnect Express), ein AGP (= Accelerated Graphics Port), ein HyperTransport oder ein beliebiger anderer technisch verfügbarer Kommunikationsbustyp sein.
Die E/A-Brücke 142 ist eine Hardware-Einheit, die Ein- und/oder Ausgabeoperationen ermöglicht, die mit dem Systemlaufwerk 140, Eingabegeräten 146, Erweiterungskarte(n) 150, Netzwerkadapter 160 und verschiedenen anderen Komponenten des Rechensystems 100 durchgeführt werden. Zum Beispiel könnte die E/A-Brücke 143 ein Southbridge-Chip sein. Der Kommunikationspfad 144 ist eine Datenverbindung mit hoher Geschwindigkeit und/oder hoher Bandbreite, die eine Kommunikation mit geringer Latenz zwischen Speicherbrücke 132 und E/A-Brücke 142 ermöglicht. Der Kommunikationspfad 142 könnte z.B. eine PCIe-Verbindung, ein AGP, ein HyperTransport oder irgendeine andere technisch umsetzbare Art von Kommunikationsbus sein. Mit der gezeigten Konfiguration kann jede beliebige Komponente, die entweder mit der Speicherbrücke 132 oder der E/A-Brücke 142 gekoppelt ist, mit jeder anderen Komponente kommunizieren, die entweder mit der Speicherbrücke 132 oder der E/A-Brücke 142 gekoppelt ist.
Die CPU 110 ist ein Prozessor, der so konfiguriert ist, dass er den Gesamtbetrieb des Computersystems 100 koordiniert. Dabei führt CPU 110 Anweisungen aus, um Befehle an die verschiedenen anderen Komponenten, die das Computersystem 100 umfasst, zu übermitteln. CPU 110 ist auch so konfiguriert, dass sie Befehle ausführt, um Daten zu verarbeiten, die von irgendeiner der anderen im Computersystem 100 enthaltenen Komponenten, einschließlich des Systemspeichers 120 und des Systemlaufwerks 140, erzeugt und/oder gespeichert werden. Systemspeicher 120 und Systemlaufwerk 140 sind Speichergeräte, die computerlesbare Medien umfassen, die zur Speicherung von Daten und Softwareanwendungen konfiguriert sind. Der Systemspeicher 120 umfasst einen Gerätetreiber 122 und einen Hypervisor 124, deren Funktionsweise im Folgenden ausführlicher beschrieben wird. Das Parallelverarbeitungs-Subsystem 130 umfasst eine oder mehrere Parallelverarbeitungseinheiten (PPUs), die so konfiguriert sind, dass sie über eine hochparallele Verarbeitungsarchitektur mehrere Operationen gleichzeitig ausführen können. Jede PPU umfasst eine oder mehrere Rechen-Engines, die allgemeine Rechenoperationen parallel ausführen, und/oder eine oder mehrere Grafik-Engines, die grafikorientierte Operationen parallel ausführen. Eine bestimmte PPU kann so konfiguriert sein, dass sie Pixel für die Anzeige über Anzeigegerät 136 erzeugt. Eine beispielhafte PPU wird weiter unten in Verbindung mit den 2-4 detaillierter beschrieben.
Der Gerätetreiber 122 ist eine Software-Anwendung, die, wenn sie von CPU 110 ausgeführt wird, als Schnittstelle zwischen CPU 110 und dem Parallelverarbeitungs-Subsystem 130 fungiert. Insbesondere ermöglicht es der Gerätetreiber 122 der CPU 110, verschiedene Verarbeitungsoperationen an das Parallelverarbeitungs-Subsystem 130 zur hochparallelen Ausführung auszulagern, einschließlich allgemeiner Rechenoperationen sowie Operationen in der Grafikverarbeitung. Der Hypervisor 124 ist eine Softwareanwendung, die, wenn sie von CPU 110 ausgeführt wird, verschiedene Rechen-, Grafik- und Speicherressourcen, die im Parallelverarbeitungs-Subsystem 130 enthalten sind, partitioniert, um getrennten Benutzern eine unabhängige Nutzung dieser Ressourcen zu ermöglichen, wie im Folgenden in Verbindung mit den 5-10 näher beschrieben wird.
In verschiedenen Ausführungsbeispielen können einige oder alle Komponenten des Computersystems 100 in einer cloud-basierten Umgebung implementiert werden, die potenziell über ein großes geografisches Gebiet verteilt ist. Beispielsweise könnten verschiedene Komponenten des Computersystems 100 in geografisch weit auseinander liegenden Datenzentren eingesetzt werden. In solchen Ausführungsbeispielen können die verschiedenen Komponenten des Computersystems 100 über ein oder mehrere Netzwerke miteinander kommunizieren, einschließlich einer beliebigen Anzahl lokaler Intranets und/oder des Internets. In verschiedenen anderen Ausführungsbeispielen können bestimmte Komponenten des Computersystems 100 durch ein oder mehrere virtualisierte Geräte implementiert werden. Zum Beispiel könnte CPU 110 als eine virtualisierte Instanz einer Hardware-CPU implementiert werden. In einigen Ausführungsbeispielen kann ein Teil oder das gesamte Parallelverarbeitungs-Subsystem 130 zusammen mit einer oder mehreren anderen Komponenten des Computersystems 100 integriert werden, um einen einzigen Chip zu bilden, wie z.B. ein System-on-Chip (SoC).
Fachkundige Personen werden verstehen, dass die Architektur des Computersystems 100 flexibel genug ist, um in einem breiten Spektrum von möglichen Szenarien und Anwendungsfällen implementiert werden zu können. Beispielsweise könnte das Computersystem 100 in einem Cloud-Computing Zentrum implementiert werden, um einem oder mehreren Benutzern allgemeine Rechenkapazitäten und/oder allgemeine Kapazitäten der Grafikverarbeitung zur Verfügung zu stellen. Alternativ könnte das Computersystem 100 in einer Automobil-Implementierung eingesetzt werden, um Datenverarbeitungsoperationen im Zusammenhang mit der Fahrzeugnavigation durchzuführen. Fachkundige Personen werden weiter verstehen, dass die verschiedenen Komponenten des Computersystems 100 und die Verbindungstopologie zwischen diesen Komponenten auf jede technisch machbare Weise modifiziert werden können, ohne vom Gesamtumfang und Geist der vorliegenden Ausführungsbeispiele abzuweichen.
2 zeigt ein Blockdiagramm einer PPU, die im Parallelverarbeitungs-Subsystem von 1 enthalten ist, gemäß verschiedenen Ausführungsbeispielen. Wie dargestellt, umfasst eine PPU 200 eine E/A-Einheit 210, eine Host-Schnittstelle 220, Sys-Pipes 230, ein Verarbeitungs-Cluster Array 240, eine Crossbar-Einheit 250 und eine Speicherschnittstelle 260. Eine PPU 200 ist mit einer PPU-Speichereinheit 270 gekoppelt. Jede der gezeigten Komponenten kann über jede technisch machbare Art von Hardware und/oder jede technisch machbare Kombination von Hardware und Software implementiert werden.
Die E/A-Einheit 210 ist über den Kommunikationspfad 134 und die Speicherbrücke 132 mit der CPU 110 der 1 gekoppelt. Die E/A-Einheit 210 ist auch an die Host-Schnittstelle 220 und an die Crossbar-Einheit 250 gekoppelt. Die Host-Schnittstelle 220 ist mit einer oder mehreren physikalischen Copy-Engines (PCEs) 222 gekoppelt, die ihrerseits mit einem oder mehreren PCE-Zählern 224 gekoppelt sind. Die Host-Schnittstelle 220 ist auch mit Sys-Pipes 230 gekoppelt. Eine bestimmte Sys-Pipe 230 umfasst ein Front-End 232, eine Aufgaben-/Arbeitseinheit 234 und einen Leistungsmonitor (engl. performance monitor, PM) 236 und ist mit dem Verarbeitungs-Cluster-Array 240 gekoppelt. Das Verarbeitungs-Cluster-Array 240 umfasst die allgemeinen Verarbeitungs-Cluster (GPCs) 242(0) bis 242(A), wobei A eine positive ganze Zahl ist. Das Verarbeitungs-Cluster-Array 240 ist mit der Crossbar-Einheit 250 gekoppelt. Die Crossbar-Einheit 250 ist mit der Speicherschnittstelle 260 gekoppelt. Die Speicherschnittstelle 260 umfasst die Partitionseinheiten 262(0) bis 262(B), wobei B ein positiver ganzzahliger Wert ist. Jede Partitionseinheit 262 kann separat mit der Crossbar-Einheit 250 verbunden werden. PPU-Speicher 270 umfasst die dynamischen DRAMs 272(0) bis 272(C), wobei C ein positiver ganzzahliger Wert ist. Um den gleichzeitigen Betrieb in mehreren Verarbeitungskontexten zu erleichtern, werden verschiedene Einheiten innerhalb der PPU 200 wie folgt repliziert: (a) die Host-Schnittstelle 220 umfasst die PBDMAs 520(0) bis 520(7); (b) die Sys-Pipe 230 einschließlich der Sys-Pipe 230(0) bis 230(7), so dass Aufgaben-/Arbeitseinheit 234 SKED 500(0) bis SKED 500(7) entspricht; und Aufgaben-/Arbeitseinheit 234 entspricht CWD 560(0) bis 560(7).
Im Betrieb erhält die E/A-Einheit 210 verschiedene Arten von Befehlsdaten von CPU 110 und verteilt diese Befehlsdaten zur Ausführung an die relevanten Komponenten der PPU 200. Insbesondere erhält die E/A-Einheit 210 Befehlsdaten, die mit Verarbeitungsaufgaben assoziiert sind, von CPU 110 und leitet diese Befehlsdaten an die Host-Schnittstelle 220 weiter. Die E/A-Einheit 210 erhält auch Befehlsdaten, die mit Speicherzugriffsoperationen assoziiert sind, von CPU 110 und leitet diese Befehlsdaten an die Crossbar-Einheit 250 weiter. Befehlsdaten im Zusammenhang mit Verarbeitungsaufgaben umfassen im Allgemeinen einen oder mehrere Zeiger auf Aufgabenmetadaten (engl. task metadata, TMD), die in einer Befehlswarteschlange im PPU-Speicher 270 oder an anderer Stelle im Computersystem 100 gespeichert sind. Eine bestimmte TMD ist eine kodierte Verarbeitungsaufgabe, die Indizes der zu verarbeitenden Daten, die mit diesen Daten auszuführenden Operationen, die mit diesen Operationen assoziierten Zustandsparameter, eine Ausführungspriorität und andere aufgabenorientierte Verarbeitungsinformationen beschreibt.
Die Host-Schnittstelle 220 empfängt Befehlsdaten im Zusammenhang mit Verarbeitungsaufgaben von der E/A-Einheit 210 und verteilt diese Befehlsdaten dann über einen oder mehrere Befehlsströme an die Sys-Pipes 230. In einigen Konfigurationen erzeugt die Host-Schnittstelle 210 für jede Sys-Pipe 230 einen anderen Befehlsstrom, wobei ein gegebener Befehlsstrom Zeiger auf TMDs umfasst, die für eine entsprechende Sys-Pipe 230 relevant sind.
Eine bestimmte Sys-Pipe 230 führt verschiedene Vorverarbeitungsoperationen mit empfangenen Befehlsdaten durch, um die Ausführung entsprechender Verarbeitungsaufgaben auf GPCs 242 innerhalb des Verarbeitungs-Cluster-Arrays 240 zu erleichtern. Nach dem Empfang von Befehlsdaten, die mit einer oder mehreren Verarbeitungsaufgaben assoziiert sind, erhält das Front-End 232 innerhalb der gegebenen Sys-Pipe 230 die assoziierten Verarbeitungsaufgaben und leitet diese Verarbeitungsaufgaben an die Aufgabe/Arbeitseinheit 234 weiter. Aufgaben-/Arbeitseinheit 234 konfiguriert eine oder mehrere GPCs 242 in einen Betriebszustand, der für die Ausführung der Verarbeitungsaufgaben geeignet ist, und überträgt dann die Verarbeitungsaufgaben zur Ausführung an diese GPCs 242. Jede Sys-Pipe 230 kann Kopieraufgaben an eine oder mehrere PCEs 222 auslagern, die dedizierte Kopiervorgänge durchführen. Die PCE-Zähler 224 verfolgen die Verwendung der PCEs 222, um die Arbeitslasten der Kopiervorgänge zwischen den verschiedenen Sys-Pipes 230 auszugleichen. PM 236 überwacht die Gesamtleistung und/oder den Ressourcenverbrauch der entsprechenden Sys-Pipe 230 und kann verschiedene von dieser Sys-Pipe 230 ausgeführte Vorgänge drosseln, um den Ressourcenverbrauch über alle Sys-Pipes 230 hinweg ausgeglichen zu halten.
Jeder GPC 242 umfasst mehrere parallele Verarbeitungskerne, die in der Lage sind, eine große Anzahl von Threads gleichzeitig und mit beliebigem Grad der Unabhängigkeit und/oder Isolierung von anderen GPCs 242 auszuführen. Beispielsweise könnte ein bestimmter GPC 242 Hunderte oder Tausende von Threads gleichzeitig in Verbindung mit oder isoliert von einem beliebigen anderen GPC 242 ausführen. Ein Satz gleichzeitiger Threads, die auf einem GPC 242 ausgeführt werden, kann separate Instanzen desselben Programms oder separate Instanzen verschiedener Programme ausführen. In einigen Konfigurationen werden die GPCs 242 von allen Sys-Pipes 230 gemeinsam genutzt, während in anderen Konfigurationen verschiedene Sätze von GPCs 242 für den Betrieb in Verbindung mit bestimmten Sys-Pipes 230 zugewiesen werden. Jeder GPC 242 empfängt Verarbeitungsaufgaben von einer oder mehreren Sys-Pipes 230 und startet in Reaktion darauf einen oder mehrere Sätze von Threads, um diese Verarbeitungsaufgaben auszuführen und Ausgabedaten zu erzeugen. Nach Abschluss einer bestimmten Verarbeitungsaufgabe überträgt eine bestimmte GPC 242 die Ausgabedaten an eine andere GPC 242 zur weiteren Verarbeitung oder an die Crossbar-Einheit 250 zur entsprechenden Weiterleitung. Ein beispielhafter GPC wird nachstehend in Verbindung mit 3 ausführlicher beschrieben.
Die Crossbar-Einheit 250 ist ein Switching-Mechanismus, der verschiedene Arten von Daten zwischen E/A-Einheit 210, Verarbeitungs-Cluster-Array 240 und Speicherschnittstelle 260 weiterleitet. Wie oben erwähnt, überträgt die E/A-Einheit 210 Befehlsdaten im Zusammenhang mit Speicherzugriffsoperationen an die Crossbar-Einheit 250. Als Antwort sendet die Crossbar-Einheit 250 die assoziierten Speicherzugriffsoperationen zur Verarbeitung an die Speicherschnittstelle 260. In einigen Fällen leitet die Crossbar-Einheit 250 auch Lesedaten, die von der Speicherschnittstelle 260 zurückgegeben werden, an die Komponente zurück, die die Lesedaten anfordert. Crossbar-Einheit 250 empfängt, wie oben erwähnt, auch Ausgabedaten von GPCs 242 und kann diese Ausgabedaten dann zur Übertragung an CPU 110 an die E/A-Einheit 210 oder zur Speicherung und/oder Verarbeitung an die Speicherschnittstelle 260 weiterleiten. Die Crossbar-Einheit 250 ist im Allgemeinen so konfiguriert, dass sie Daten zwischen den GPCs 242 und von jedem GPC 242 an jede beliebige Partitionseinheit 262 weiterleitet. In verschiedenen Ausführungsbeispielen kann die Crossbar-Einheit 250 virtuelle Kanäle implementieren, um Verkehrsströme zwischen den GPCs 242 und den Partitionseinheiten 262 zu trennen. In verschiedenen Ausführungsbeispielen kann die Crossbar-Einheit 250 nicht gemeinsam genutzte Pfade zwischen einem Satz von GPCs 242 und einem Satz von Partitionseinheiten 262 ermöglichen.
Die Speicherschnittstelle 260 implementiert die Partitionseinheiten 262, um einen Speicherzugriff mit hoher Bandbreite auf DRAMS 272 innerhalb des PPU-Speichers 270 zu ermöglichen. Jede Partitionseinheit 262 kann Speicherzugriffsoperationen mit einem anderen DRAM 272 parallel zueinander ausführen, wodurch die verfügbare Speicherbandbreite des PPU-Speichers 270 effizient genutzt wird. Eine bestimmte Partitionseinheit 262 unterstützt auch ein Caching über einen oder mehrere interne Caches. Eine beispielhafte Partitionseinheit 262 wird im Folgenden in Verbindung mit 4 ausführlicher beschrieben.
Der PPU-Speicher 270 im Allgemeinen und die DRAMs 272 im Besonderen können so konfiguriert werden, dass sie jeden technisch machbaren Datentyp speichern können, der mit allgemeinen Computeranwendungen und/oder Anwendungen der Grafikverarbeitung assoziiert ist. Beispielsweise könnten DRAMs 272 große Matrizen von Datenwerten speichern, die mit neuronalen Netzen in allgemeinen Rechenanwendungen assoziiert sind, oder alternativ einen oder mehrere Einzelbild-Puffer, die verschiedene Rendering-Ziel in der Grafikverarbeitung umfassen. In verschiedenen Ausführungsbeispielen können DRAMs 272 über ein beliebiges technisch geeignetes Speichergerät implementiert werden.
Die oben beschriebene Architektur ermöglicht es der PPU 200, eine Vielzahl von Verarbeitungsoperationen beschleunigt und asynchron zum Betrieb der CPU 110 durchzuführen. Insbesondere ermöglicht die parallele Architektur von PPU 200 die parallele Ausführung einer großen Anzahl von Operationen, die parallel und mit beliebigem Grad der Unabhängigkeit voneinander und von Operationen auf CPU 110 durchgeführt werden können, wodurch die Gesamtleistung dieser Operationen beschleunigt wird.
In einem Ausführungsbeispiel kann die PPU 200 so konfiguriert sein, dass sie allgemeine Rechenoperationen ausführt, um Berechnungen mit großen Datensätzen zu beschleunigen. Solche Datensätze können sich unter anderem auf finanzielle Zeitreihen, dynamische Simulationsdaten, Echtzeit-Sensormesswerte, Gewichtsmatrizen und/oder Tensoren neuronaler Netzwerke und Parameter des maschinellen Lernens beziehen. In einem anderen Ausführungsbeispiel kann PPU 200 so konfiguriert sein, dass sie als Grafikverarbeitungseinheit (GPU) arbeitet, die eine oder mehrere Grafik-Rendering-Pipelines implementiert, um Pixeldaten basierend auf Grafikbefehlen zu erzeugen, die von CPU 110 generiert werden. PPU 200 kann dann die Pixeldaten über Anzeigegerät 136 als ein oder mehrere Einzelbilder ausgeben. PPU-Speicher 170 kann so konfiguriert sein, dass er als Grafikspeicher fungiert, der einen oder mehrere Einzelbildpuffer und/oder ein oder mehrere Rendering-Ziele in der gleichen Weise wie oben erwähnt speichert. In einem weiteren Ausführungsbeispiel kann PPU 200 so konfiguriert werden, dass sie sowohl allgemeine Rechenoperationen als auch Grafikverarbeitungsoperationen gleichzeitig ausführt. In solchen Konfigurationen können eine oder mehrere Sys-Pipes 230 so konfiguriert werden, dass sie über eine oder mehrere GPCs 242 allgemeine Rechenoperationen implementieren, und eine oder mehrere andere Sys-Pipes 230 können so konfiguriert werden, dass sie über eine oder mehrere GPCs 242 eine oder mehrere Grafikverarbeitungs-Pipelines implementieren.
Bei jeder der oben genannten Konfigurationen arbeiten Gerätetreiber 122 und Hypervisor 124 zusammen, um verschiedene Rechen-, Grafik- und Speicherressourcen, die in PPU 200 enthalten sind, in separate „PPU-Partitionen“ zu unterteilen. Alternativ kann es eine Vielzahl von Gerätetreibern 122 geben, die jeweils einer „PPU-Partition“ zugeordnet sind. Vorzugsweise werden Gerätetreiber auf einem Satz von Kernen in der CPU 110 ausgeführt. Eine bestimmte PPU-Partition arbeitet im Wesentlichen ähnlich wie die PPU 200 als Ganzes. Insbesondere kann jede PPU-Partition so konfiguriert sein, dass sie allgemeine Rechenoperationen, Operationen in der Grafikverarbeitung oder beide Arten von Operationen isoliert von den anderen PPU-Partitionen ausführt. Darüber hinaus kann eine gegebene PPU-Partition so konfiguriert sein, dass sie mehrere Verarbeitungskontexte gleichzeitig implementiert, wenn eine oder mehrere virtuelle Maschinen (VMs) gleichzeitig auf den der gegebenen PPU-Partition zugewiesenen Rechen-, Grafik- und Speicherressourcen ausgeführt werden. Logische Gruppierungen von PPU-Ressourcen in PPU-Partitionen werden nachstehend in Verbindung mit den 5-8 detaillierter beschrieben. Techniken zum Partitionieren und Konfigurieren von PPU-Ressourcen werden im Folgenden in Verbindung mit den 9-10 ausführlicher beschrieben.
3 zeigt ein Blockdiagramm einer GPC, die in der PPU von 2 enthalten ist, gemäß verschiedenen Ausführungsbeispielen der vorliegenden Erfindung. Wie gezeigt, ist GPC 242 mit einer Speicherverwaltungseinheit 300 (engl. memory management unit, MMU) gekoppelt und umfasst einen Pipeline-Manager 310, eine Arbeitsverteilungs-Crossbar 320, einen oder mehrere Texturverarbeitungs-Cluster 330 ( engl. texture processing clusters, TPCs), eine oder mehrere Textureinheiten 340, einen Level-1.5 (L1.5) -Cache 350, einen PM 360 und einen Pre-Raster Operations Processor (preROP) 370. Der Pipeline-Manager 310 ist mit der Arbeitsverteilungs-Crossbar 320 und den TPCs 330 gekoppelt. Jeder TPC 330 umfasst einen oder mehrere Streaming-Multiprozessoren (SMs) 332 und ist mit der Textureinheit 340, der MMU 300, dem L1.5-Cache 350, dem PM 360 und dem preROP 370 gekoppelt. Die Textureinheit 340 und der L1.5-Cache 350 sind ebenfalls mit der MMU 300 und untereinander gekoppelt. PreROP 370 ist mit der Arbeitsverteilungs-Crossbar 320 gekoppelt. Jede der gezeigten Komponenten kann mit einer beliebigen technisch geeigneten Hardware und/oder einer beliebigen technisch geeigneten Kombination von Hardware und Software implementiert werden.
Der GPC 242 umfasst eine hochparallele Architektur, die eine große Anzahl von Threads parallel ausführen kann. Wie hierin erwähnt, ist ein „Thread“ eine Instanz eines bestimmten Programms, das auf einem bestimmten Satz von Eingabedaten ausgeführt wird, um verschiedene Arten von Operationen auszuführen, einschließlich allgemeiner Rechenoperationen und Operationen zur Grafikverarbeitung. In einem Ausführungsbeispiel kann GPC 242 SIMD-Techniken (engl. Single-Instruction Multiple-Data) implementieren, um die parallele Ausführung einer großen Anzahl von Threads zu unterstützen, ohne sich notwendigerweise auf mehrere unabhängige Befehlseinheiten zu stützen.
In einem anderen Ausführungsbeispiel kann der GPC 242 SIMT-Techniken (engl. Single-Instruction Multiple-Thread) implementieren, um die parallele Ausführung einer großen Anzahl allgemein synchronisierter Threads über eine gemeinsame Befehlseinheit zu unterstützen, die Befehle an eine oder mehrere der Engines ausgibt. Fachleute werden verstehen, dass es eine SIMT-Ausführung verschiedenen Threads ermöglicht, leichter divergierenden Ausführungspfaden durch ein bestimmtes Programm zu folgen, im Gegensatz zur SIMD-Ausführung, bei der alle Threads im Allgemeinen nicht-divergierenden Ausführungspfaden durch ein bestimmtes Programm folgen. Fachkundige Personen werden erkennen, dass SIMD-Techniken einen funktionellen Teilsatz von SIMT-Techniken repräsentieren.
Der GPC 242 kann eine große Anzahl paralleler Threads über SMs 332 ausführen, die die TPCs 330 umfassen. Jeder SM 332 umfasst einen Satz von Funktionseinheiten (nicht abgebildet), einschließlich einer oder mehrerer Ausführungseinheiten und/oder einer oder mehrerer Load-Store-Einheiten, die so konfiguriert sind, dass sie Anweisungen ausführen, die mit den empfangenen Verarbeitungsaufgaben assoziiert sind. Eine bestimmte Funktionseinheit kann Befehle in einem Pipeline-Verfahren ausführen, was bedeutet, dass ein Befehl an die Funktionseinheit ausgegeben werden kann, bevor die Ausführung eines vorhergehenden Befehls abgeschlossen ist. In verschiedenen Ausführungsbeispielen können die Funktionseinheiten innerhalb von SMs 332 so konfiguriert werden, dass sie eine Vielzahl verschiedener Operationen ausführen können, einschließlich Ganzzahl- und Gleitkommaarithmetik (z.B. Addition und Multiplikation u.a.), Vergleichsoperationen, Boolesche Operationen (z.B. UND, ODER und XOR u.a.), Bitverschiebung und Berechnung verschiedener algebraischer Funktionen (z.B. planare Interpolation und trigonometrische, exponentielle und logarithmische Funktionen u.a.). Jede funktionale Einheit kann Zwischendaten in einem Level-1 (L1) -Cache speichern, der sich in dem SM 332 befindet.
Über die oben beschriebenen funktionalen Einheiten ist der SM 332 so konfiguriert, dass er eine oder mehrere „Thread-Gruppen“ (auch als „Warps“ bezeichnet) verarbeitet, die gleichzeitig dasselbe Programm mit unterschiedlichen Eingabedaten ausführen. Jeder Thread innerhalb einer Thread-Gruppe wird im Allgemeinen über eine andere funktionale Einheit ausgeführt, obwohl nicht alle funktionalen Einheiten in bestimmten Situationen Threads ausführen. Wenn z.B. die Anzahl der in der Thread-Gruppe enthaltenen Threads geringer ist als die Anzahl der funktionalen Einheiten, dann könnten die nicht verwendeten funktionalen Einheiten während der Verarbeitung der Thread-Gruppe untätig bleiben. In anderen Situationen werden mehrere Threads innerhalb einer Thread-Gruppe über dieselbe funktionale Einheit zu unterschiedlichen Zeiten ausgeführt. Wenn z.B. die Anzahl der in der Thread-Gruppe enthaltenen Threads größer ist als die Anzahl der funktionalen Einheiten, dann könnten eine oder mehrere funktionale Einheiten verschiedene Threads über aufeinander folgende Taktzyklen hinweg ausführen.
In einem Ausführungsbeispiel kann ein Satz verwandter Thread-Gruppen gleichzeitig in verschiedenen Phasen der Ausführung innerhalb des SM 332 aktiv sein. Ein Satz verwandter Thread-Gruppen wird hier als „kooperatives Thread-Array“ (CTA) oder als „Thread-Array“ bezeichnet. Threads innerhalb desselben CTA oder Threads innerhalb verschiedener CTAs können im Allgemeinen Zwischendaten und/oder Ausgabedaten miteinander über einen oder mehrere L1-Caches gemeinsam nutzen, einschließlich der SMs 332, L1.5-Cache 350, einen oder mehrere L2-Caches, die von SMs 332 gemeinsam genutzt werden, oder über einen beliebigen gemeinsamen Speicher, globalen Speicher oder einen anderen Speichertyp, der sich auf einem beliebigen, in Rechnersystem 100 enthaltenen Gerät befindet. In einem Ausführungsbeispiel kann der L1.5-Cache 350 so konfiguriert sein, dass er Anweisungen zwischenspeichert, die von Threads ausgeführt werden sollen, die auf SMs 332 ausgeführt werden.
Jedem Thread in einer bestimmten Thread-Gruppe oder CTA wird im Allgemeinen eine eindeutige Thread-Kennung (Thread-ID) zugewiesen, auf die der Thread während der Ausführung zugreifen kann. Die einem bestimmten Thread zugewiesene Thread-ID kann als eindimensionaler oder mehrdimensionaler numerischer Wert definiert werden. Das Ausführungs- und Verarbeitungsverhalten des gegebenen Threads kann je nach Thread-ID variieren. Beispielsweise könnte der Thread auf der Grundlage der Thread-ID bestimmen, welcher Teil eines Eingabedatensatzes zu verarbeiten und/oder welcher Teil eines Ausgabedatensatzes zu schreiben ist.
In einem Ausführungsbeispiel kann eine Sequenz von jeweils auf einen Thread bezogenen Anweisungen (Anweisungen pro Thread, engl. per-thread instructions) mindestens eine Anweisung umfassen, die ein kooperatives Verhalten zwischen einem bestimmten Thread und einem oder mehreren anderen Threads definiert. Beispielsweise könnte die Sequenz von Thread-bezogenen Anweisungen eine Anweisung umfassen, die bei ihrer Ausführung den gegebenen Thread in einem bestimmten Ausführungszustand aussetzt, bis einige oder alle anderen Threads einen entsprechenden Ausführungszustand erreichen. In einem anderen Beispiel könnte die Sequenz von Thread-bezogenen Anweisungen eine Anweisung umfassen, die bei ihrer Ausführung bewirkt, dass der angegebene Thread Daten in einem gemeinsamen Speicher speichert, auf den einige oder alle anderen Threads Zugriff haben. In einem weiteren Beispiel könnte die Sequenz von Thread-bezogenen Anweisungen eine Anweisung umfassen, die bei ihrer Ausführung bewirkt, dass der betreffende Thread die in einem gemeinsamen Speicher gespeicherten Daten atomistisch liest und aktualisiert, auf die einige oder alle anderen Threads je nach Thread-IDs dieser Threads Zugriff haben. In einem weiteren Beispiel könnte die Sequenz von Anweisungen pro Thread eine Anweisung umfassen, die, wenn sie ausgeführt wird, den gegebenen Thread veranlasst, eine Adresse in einem gemeinsamen Speicher basierend auf einer entsprechenden Thread-ID zu berechnen, um Daten aus diesem gemeinsamen Speicher zu lesen. Mit den obigen Synchronisierungstechniken kann ein erster Thread Daten an eine bestimmte Stelle in einem gemeinsamen Speicher schreiben und ein zweiter Thread kann diese Daten auf vorbestimmter Weise aus dem gemeinsamen Speicher auslesen. Dementsprechend können Threads so konfiguriert sein, dass sie eine Vielzahl von Datenfreigabemustern innerhalb einer bestimmten Thread-Gruppe oder eines bestimmten CTA oder zwischen Threads in verschiedenen Thread-Gruppen oder verschiedenen CTAs implementieren. In verschiedenen Ausführungsbeispielen beschreibt eine in der Programmiersprache CUDA (Compute Unified Device Architecture) geschriebene Softwareanwendung das Verhalten und den Betrieb von Threads, die auf dem GPC 242 ausgeführt werden, einschließlich beliebiger der oben beschriebenen Verhaltensweisen und Operationen.
Im Betrieb koordiniert der Pipeline-Manager 310 im Allgemeinen die parallele Ausführung von Verarbeitungsaufgaben innerhalb von GPC 242. Der Pipeline-Manager 310 empfängt Verarbeitungsaufgaben von der Aufgaben-/Arbeitseinheit 234 und verteilt diese Verarbeitungsaufgaben an die TPCs 330 zur Ausführung über die SMs 332. Eine bestimmte Verarbeitungsaufgabe ist im Allgemeinen mit einem oder mehreren CTAs assoziiert, die auf einem oder mehreren SMs 332 innerhalb eines oder mehrerer TPCs 330 ausgeführt werden können. In einem Ausführungsbeispiel kann eine bestimmte Aufgaben-/Arbeitseinheit 234 eine oder mehrere Verarbeitungsaufgaben an GPC 242 verteilen, indem sie ein oder mehrere CTAs startet, die an einen oder mehrere bestimmte TPCs 330 gerichtet sind. Der Pipeline-Manager 310 kann das gestartete CTA von der Aufgaben-/Arbeitseinheit 234 empfangen und das CTA an die entsprechende TPC 330 zur Ausführung über eine oder mehrere SMs 332, die in der TPC 330 enthalten sind, weiterleiten. Während oder nach der Ausführung einer bestimmten Verarbeitungsaufgabe erzeugt jeder SM 332 Ausgabedaten und überträgt die Ausgabedaten je nach aktueller Konfiguration und/oder der Art der aktuellen Verarbeitungsaufgabe an verschiedene Stellen.
In Konfigurationen, die sich auf die allgemeine Datenverarbeitung oder die Grafikverarbeitung beziehen, kann der SM 332 die Ausgabedaten an die Arbeitsverteilungs-Crossbar 320 übertragen, und die Arbeitsverteilungs-Crossbar 320 leitet die Ausgabedaten dann zur weiteren Verarbeitung an eine oder mehrere GPCs 242 oder leitet die Ausgabedaten zur weiteren Weiterleitung an die Crossbar-Einheit 250 weiter. Die Crossbar-Einheit 250 kann die Ausgabedaten unter anderem an einen L2-Cache, der in einer bestimmten Partitionseinheit 262 enthalten ist, an den PPU-Speicher 270 oder an den Systemspeicher 120 weiterleiten. Der Pipeline-Manager 310 koordiniert im Allgemeinen die Weiterleitung von Ausgabedaten, die von der Arbeitsverteilungs-Crossbar 320 durchgeführt wird, basierend auf den mit diesen Ausgabedaten assoziierten Verarbeitungsaufgaben.
In für Grafikverarbeitung spezifischen Konfigurationen kann der SM 332 Ausgabedaten an Textureinheit 340 und/oder preROP 370 übertragen. In einigen Ausführungsbeispielen kann preROP 370 einige oder alle Rasteroperationen implementieren, die in einer 3D-Grafik-API spezifiziert sind. In diesem Fall implementiert preROP 370 einige oder alle Operationen, die ansonsten über ein ROP 410 ausgeführt werden. Die Textureinheit 340 führt im Allgemeinen Texture-Mapping-Operationen aus, die unter anderem die Bestimmung von Texturprobenpositionen, das Lesen von Texturdaten und das Filtern von Texturdaten umfassen. PreROP 370 führt im Allgemeinen rasterorientierte Operationen durch, die z. B. die Organisation von Pixelfarbdaten und die Durchführung von Optimierungen für die Farbmischung umfassen. PreROP 370 kann auch Adressübersetzungen und direkte Ausgaben der von SMs 332 empfangenen Daten an eine oder mehrere Rasteroperationsprozessor-Einheiten (ROP-Einheiten) innerhalb der Partitionseinheiten 262 durchführen.
In jeder der oben genannten Konfigurationen überwachen ein oder mehrere PMs 360 die Leistung der verschiedenen Komponenten von GPC 242, um den Benutzern Leistungsdaten zur Verfügung zu stellen und/oder die Auslastung der Rechen-, Grafik- und/oder Speicherressourcen über Gruppen von Threads auszugleichen und/oder die Auslastung dieser Ressourcen mit der anderer GPCs 242 auszugleichen. Weiterhin können in jeder der oben genannten Konfigurationen der SM 332 und andere Komponenten innerhalb von GPC 242 Speicherzugriffsoperationen mit der Speicherschnittstelle 260 über MMU 300 durchführen. MMU 300 schreibt im Allgemeinen Ausgabedaten in verschiedene Speicherbereiche und/oder liest Eingabedaten aus verschiedenen Speicherbereichen im Auftrag von GPC 242 und den darin enthaltenen Komponenten. Die MMU 300 ist so konfiguriert, dass sie virtuelle Adressen über einen Satz von Seitentabelleneinträgen (engl. page table entries, PTEs) und einen oder mehrere optionale Address Translation Lookaside Buffers (TLBs) in physische Adressen umwandelt. MMU 300 kann verschiedene Daten im L1.5-Cache 350 zwischenspeichern, einschließlich Lesedaten, die von der Speicherschnittstelle 260 zurückgegeben werden. In einem Ausführungsbeispiel ist die MMU 300 extern an GPC 242 gekoppelt und kann möglicherweise auch von anderen GPCs 242 gemeinsam genutzt werden. In anderen Ausführungsbeispielen kann der GPC 242 eine dedizierte Instanz der MMU 300 enthalten, die Zugriff auf eine oder mehrere Partitionseinheiten 262 bietet, die in der Speicherschnittstelle 260 enthalten sind.
4 zeigt ein Blockdiagramm einer Partitionseinheit 262, die in der PPU 200 von 2 enthalten ist, gemäß verschiedenen Ausführungsbeispielen. Wie dargestellt, umfasst die Partitionseinheit 262 einen L2-Cache 400, eine Schnittstelle 410 für DRAM-Speicher (engl. frame buffer, FB), einen Rasteroperationsprozessor (engl. raster operations processor (ROP) 420) und einen oder mehrere PMs 430. L2-Cache 400 ist zwischen der FB-DRAM-Schnittstelle 410, dem ROP 420 und dem PM 430 gekoppelt.
Der L2-Cache 400 ist ein Lese-/Schreib-Cache, der Lade- und Speicheroperationen durchführt, die von der Crossbar-Einheit 250 und dem ROP 420 empfangen werden. Der L2-Cache 400 gibt Lesefehler und dringende Rückschreibanforderungen zur Verarbeitung an die FB-DRAM-Schnittstelle 410 aus. L2-Cache 400 überträgt auch unsaubere Aktualisierungen zur opportunistischen Verarbeitung an die FB-DRAM-Schnittstelle 410. In einigen Ausführungsbeispielen überwachen die PMs 430 während des Betriebs die Auslastung des L2-Cache 400, um die Speicherzugriffsbandbreite gerecht auf verschiedene GPCs 242 und andere Komponenten der PPU 200 aufzuteilen. Die FB-DRAM-Schnittstelle 410 hat eine direkte Schnittstelle zu einem bestimmten DRAM 272, um Speicherzugriffsoperationen durchzuführen, einschließlich des Schreibens von Daten in den DRAM 272 und des Lesens von Daten aus dem DRAM 272. In einigen Ausführungsbeispielen wird der Satz von DRAM 272 auf mehrere DRAM-Chips aufgeteilt, wobei Teile mehrerer DRAM-Chips jedem DRAM 272 entsprechen.
In Konfigurationen, die mit der Grafikverarbeitung zusammenhängen, führt der ROP 420 Rasteroperationen aus, um Grafikdaten zu erzeugen. Der ROP 420 könnte beispielsweise unter anderem Schablonenoperationen, z-Testoperationen, Überblendoperationen sowie Komprimierungs- und/oder Dekomprimierungsoperationen an z- oder Farbdaten durchführen. Der ROP 420 kann so konfiguriert sein, dass er verschiedene Arten von Grafikdaten erzeugt, einschließlich Pixeldaten, Grafikobjekten, Fragmentdaten und so weiter. Der ROP 420 kann auch Grafikverarbeitungsaufgaben auf andere Recheneinheiten verteilen. In einem Ausführungsbeispiel umfasst jede GPC 242 einen dedizierten ROP 420, der Rasteroperationen im Auftrag der entsprechenden GPC 242 durchführt.
Fachkundige Personen werden verstehen, dass die in den 1-4 beschriebene Architektur den Umfang der vorliegenden Ausführungsbeispiele in keiner Weise einschränkt und dass die hier offenbart werdenden Techniken auf jeder beliebigen ordnungsgemäß konfigurierten Verarbeitungseinheit implementiert werden können, einschließlich, ohne Einschränkung, einer oder mehrerer CPUs, einer oder mehrerer Mehrkern-CPUs, einer oder mehrerer PPUs 200, einer oder mehrerer GPCs 242, einer oder mehrerer GPUs oder anderer spezieller Verarbeitungseinheiten usw., ohne vom Umfang und Geist der vorliegenden Ausführungsbeispiele abzuweichen.
Logische Gruppierungen von Hardware-Ressourcen
5 zeigt ein Blockdiagramm von verschiedenen PPU-Ressourcen, die in der PPU von 2 enthalten sind, gemäß verschiedenen Ausführungsbeispielen. Wie gezeigt, umfassen die PPU-Ressourcen 500 die Sys-Pipes 230(0) bis 230(7), der Steuerungs-Crossbar und SMC-Arbiter 510, Privileged Register Interface (PRI) Hub 512, GPCs 242, Crossbar-Einheit 250 und L2-Cache 400. Der L2-Cache 400 wird hier als eine Sammlung von „L2-Cache-Abschnitte“ dargestellt, von denen jeder einem anderen Bereich von DRAM 262 entspricht. Sys-Pipes 230, GPCs 242 und PRI-Hub 512 sind über den Steuerungs-Crossbar und SMC-Arbiter 510 miteinander gekoppelt. GPCs 242 und einzelne Abschnitte des L2-Cache 400 sind über die Crossbar-Einheit 250 miteinander gekoppelt. In dem hier besprochenen Beispiel umfasst die PPU-Ressource 500 acht Sys-Pipes 230, acht GPCs 242 und eine bestimmte Anzahl weiterer Komponenten. Fachleute werden jedoch verstehen, dass die PPU-Ressourcen 500 jede technisch geeignete Anzahl dieser Komponenten umfassen kann.
Jede Sys-Pipe 230 umfasst im Allgemeinen PBDMAs 520 und 522, einen Front-End-Kontext-Switch (FECS) 530, ein Compute (COMP)-Front-End (FE) 540, einen Scheduler (SKED) 550 und einen CUDA-Work-Distributor (CWD) 560. PBDMAs 520 und 522 sind Hardware-Speicher-Controller, die die Kommunikation zwischen Gerätetreiber 122 und PPU 200 verwalten. FECS 530 ist eine Hardware-Einheit, die Kontext-Switches verwaltet. Compute FE 540 ist eine Hardware-Einheit, die die Verarbeitung von Rechenaufgaben für die Ausführung vorbereitet. SKED 550 ist eine Hardware-Einheit, die Verarbeitungsaufgaben für die Ausführung plant. CWD 560 ist eine Hardware-Einheit, die so konfiguriert ist, dass sie ein oder mehrere Thread-Gitter in eine Warteschlange stellt und an einen oder mehrere GPCs 242 sendet, um eine oder mehrere Verarbeitungsaufgaben auszuführen. In einem Ausführungsbeispiel kann eine bestimmte Verarbeitungsaufgabe in einem CUDA-Programm spezifiziert werden. Über die oben genannten Komponenten können die Sys-Pipes 230 so konfiguriert werden, dass sie allgemeine Rechenoperationen ausführen und/oder verwalten können.
Die Sys Pipe 230(0) umfasst weiter eine Graphik-Front-End (FE)-Einheit 542 (dargestellt als GFX FE 542), einen Zustandsänderungs-Controller SCC 552 und Primitive-Distributor Phase A / Phase B Einheiten (PDA/PDB) 562. Die Graphik FE 542 ist eine Hardware-Einheit, die Graphikverarbeitungsaufgaben für die Ausführung vorbereitet. SCC 552 ist eine Hardware-Einheit, die die Parallelisierung der Arbeit mit verschiedenen API-Zuständen verwaltet (z.B. ein Shader-Programm, Konstanten, die von einem Shader verwendet werden, und wie eine Textur abgetastet wird), um die geordnete Anwendung des API-Zustands aufrechtzuerhalten, auch wenn Grafik-Primitive nicht der Reihe nach verarbeitet werden. PDA/PDB 562 ist eine Hardware-Einheit, die Grafik-Primitive (z.B. Dreiecke, Linien, Punkte, Vierecke, Netze usw.) an GPCs 242 verteilt. Über diese zusätzlichen Komponenten kann die Sys-Pipe 230(0) weiter konfiguriert werden, um Operationen in der Grafikverarbeitung durchzuführen. In verschiedenen Ausführungsbeispielen können einige oder alle Sys-Pipes 230 so konfiguriert sein, dass sie ähnliche Komponenten wie die Sys-Pipe 230(0) umfassen und daher entweder allgemeine Rechenoperationen oder Grafikverarbeitungsoperationen durchführen können. Alternativ dazu können in verschiedenen anderen Ausführungsbeispielen einige oder alle Sys-Pipes 230 so konfiguriert sein, dass sie ähnliche Komponenten wie die Sys-Pipe 230(1) bis 220(7) umfassen und daher nur allgemeine Rechenoperationen ausführen können. Generell kann das Front-End 232 in 2 so konfiguriert werden, dass es die Berechnung FE 540, die Grafik FE 542 oder sowohl die Berechnung FE 540 als auch die Grafik FE 542 umfasst. Dementsprechend wird im Folgenden allgemein auf das Front-End 232 in Bezug auf die Berechnung FE 540 und die Graphik FE 542 oder beide verwiesen.
Die Steuerungs-Crossbar und der SMC-Arbiter 510 erleichtert die Kommunikation zwischen Sys-Pipes 230 und GPCs 242. In einigen Konfigurationen sind eine oder mehrere spezifische GPCs 242 programmierbar zugeordnet, um Verarbeitungsaufgaben im Namen einer spezifischen Sys-Pipe 230 auszuführen. In solchen Konfigurationen sind die Steuerungs-Crossbar und der SMC-Arbiter 510 so konfiguriert, dass sie Daten zwischen beliebigen GPC(s) 242 und der/den entsprechenden Sys-Pipe(s) 220 weiterleiten. PRI-Hub 512 ermöglicht den Zugriff der Einheiten CPU 110 und/oder PPU 200 auf einen Satz privilegierter Register zur Steuerung der Konfiguration der PPU 200. Der Registeradressraum mit der PPU 200 kann durch ein PRI-Register konfiguriert werden, und dabei wird der PRI-Hub 212 unter Verwendung von PRI-Hub 212 zur Konfiguration der Zuordnung von PRI-Registeradressen zwischen einem generischen PRI-Adressraum und einem für jede Sys-Pipe 230 separat definierten PRI-Adressraum verwendet. Diese PRI-Adressraumkonfiguration ermöglicht die Übertragung an mehrere PRI-Register von den SMC-Engines, die nachstehend in Verbindung mit 7 beschrieben werden. Die GPCs 242 schreiben über die Crossbar-Einheit 250 auf die zuvor beschriebene Weise Daten in den L2-Cache 400 und lesen Daten aus diesem. In einigen Konfigurationen wird jedem GPC 242 ein separater Satz von L2-Abschnitten zugewiesen, die vom L2-Cache 400 abgeleitet sind, und jeder beliebige GPC 242 kann Schreib-/Leseoperationen mit dem entsprechenden Satz von L2-Abschnitten durchführen.
Jede der oben besprochenen PPU-Ressourcen 500 kann logisch in eine oder mehrere PPU-Partitionen gruppiert oder partitioniert werden, die jeweils in gleicher Weise wie die PPU 200 als Ganzes funktionieren. Insbesondere kann eine bestimmte PPU-Partition mit ausreichend Rechen-, Grafik- und Speicherressourcen konfiguriert werden, um jede beliebige technisch geeignete Operation durchzuführen, die von PPU 200 ausgeführt werden kann. Ein Beispiel dafür, wie PPU-Ressourcen 500 logisch in Partitionen gruppiert werden können, wird unten in Verbindung mit 6 ausführlicher beschrieben.
6 zeigt in einem Beispiel, wie der Hypervisor von 1 PPU-Ressourcen logisch in einen Satz von PPU-Partitionen gruppiert, gemäß verschiedenen Ausführungsbeispielen. Wie gezeigt, umfassen PPU-Partitionen 600 einen oder mehrere PPU-Abschnitte 610. Insbesondere umfasst PPU-Partition 600(0) die PPU-Abschnitte 610(0) bis 610(3), PPU-Partition 600(4) umfasst PPU-Abschnitt 610(4) und 610(5), PPU-Partition 600(6) umfasst PPU-Abschnitt 610(6) und PPU-Partition 600(7) umfasst PPU-Abschnitt 610(7). In dem hier besprochenen Beispiel umfassen die PPU-Partitionen 600 die spezifische Anzahl der gezeigten PPU-Abschnitte 610. In anderen Konfigurationen können PPU-Partitionen 600 jedoch eine andere Anzahl von PPU-Abschnitten 610 umfassen.
Jeder PPU-Abschnitt 610 umfasst verschiedene Ressourcen, die von einer Sys-Pipe 230 abgeleitet sind, darunter die PBDMAs 520 und 522, FECS 530, Front End 232, SKED 550 und CWD 560. Jeder PPU-Abschnitt 610 umfasst ferner einen GPC 242, einen Satz L2-Abschnitte 620 und entsprechende Abschnitte von DRAM 272 (hier nicht abgebildet). Die verschiedenen Ressourcen, die in einem bestimmten PPU-Abschnitt 610 enthalten sind, verleihen ihm eine ausreichende Funktionalität, so dass jeder beliebige PPU-Abschnitt 610 mindestens einige der allgemeinen Rechen- und/oder Grafikverarbeitungsoperationen ausführen kann, die PPU 200 ausführen kann.
Beispielsweise könnte ein PPU-Abschnitt 610 Verarbeitungsaufgaben über das Front-End 232 empfangen und dann diese Verarbeitungsaufgaben zur Ausführung über SKED 550 einplanen. CWD 560 könnte dann Gitter von Threads ausgeben, um diese Verarbeitungsaufgaben auf GPC 242 auszuführen. GPC 242 könnte zahlreiche Thread-Gruppen parallel in der oben in Verbindung mit 3 beschriebenen Weise ausführen. Die PBDMAs 520 und 522 könnten Speicherzugriffsoperationen für die verschiedenen Komponenten ausführen, die im PPU-Abschnitt 610 enthalten sind. In einigen Ausführungsbeispielen holen die PBDMAs 520 und 522 Befehle aus dem Speicher und senden die Befehle zur Verarbeitung an FE 232. Je nach Bedarf konnten verschiedene Komponenten des PPU-Abschnitts 610 Daten in den entsprechenden Satz von L2-Cache-Abschnitte 620 schreiben und aus diesem lesen. Die Komponenten des PPU-Abschnitts 610 könnten bei Bedarf auch eine Schnittstelle zu externen Komponenten, die in PPU 200 enthalten sind, herstellen, unter anderem zu E/A-Einheit 210 und/oder PCEs 222. FECS 530 könnte beim zeitlichen Aufteilen einer oder mehrerer VMs auf den verschiedenen in PPU-Abschnitt 610 enthaltenen Ressourcen Kontext-Switch-Operationen durchführen.
In dem gezeigten Ausführungsbeispiel umfasst jeder PPU-Abschnitt 610 Ressourcen, die von einer Sys-Pipe 230 abgeleitet sind, die so konfiguriert ist, dass sie allgemeine Rechenoperationen koordiniert. Dementsprechend sind die PPU-Abschnitte 610 so konfiguriert, dass sie nur allgemeine Verarbeitungsaufgaben ausführen. In anderen Ausführungsbeispielen kann jedoch jeder PPU-Abschnitt 610 weiter Ressourcen umfassen, die von einer Sys-Pipe 230 abgeleitet sind, die so konfiguriert ist, dass sie Grafikverarbeitungsoperationen koordiniert, wie z.B. Sys-Pipe 230(0). In diesen Ausführungsbeispielen können die PPU-Abschnitte 610 so konfiguriert sein, dass sie zusätzlich Grafikverarbeitungsaufgaben ausführen.
Im Allgemeinen handelt es sich bei jeder PPU-Partition 600 um eine harte Partitionierung von Ressourcen, die einem oder mehreren Benutzern eine dedizierte parallele Computerumgebung bietet, die von anderen PPU-Partitionen 600 isoliert ist. Eine bestimmte PPU-Partition 600 umfasst, wie gezeigt, einen oder mehrere dedizierte PPU-Abschnitte 610, die gemeinsam die verschiedenen allgemeinen Rechen-, Grafikverarbeitungs- und Speicherressourcen umfassen, die erforderlich sind, um zumindest bis zu einem gewissen Grad die übergreifende Funktionalität der PPU 200 als Ganzes nachzuahmen. Dementsprechend kann ein bestimmter Benutzer Parallelverarbeitungsoperationen innerhalb einer bestimmten PPU-Partition 600 in der gleichen Weise ausführen wie ein Benutzer, der dieselben Parallelverarbeitungsoperationen auf PPU 200 ausführt, wenn PPU 200 nicht partitioniert ist. Jede PPU-Partition 600 ist gegenüber anderen PPUs 600 fehlerunempfindlich, und jede PPU-Partition kann unabhängig von und ohne Unterbrechung des Betriebs anderer PPUs Partitionen 600 zurückgesetzt werden. Verschiedene Ressourcen, die hier nicht spezifisch dargestellt sind, sind im Verhältnis zur Größe dieser verschiedenen PPU-Partitionen 600 gerecht auf die verschiedenen PPU-Partitionen 600 verteilt, wie im Folgenden näher beschrieben wird.
In der hier besprochenen Beispielkonfiguration von PPU-Partitionen 600 werden der PPU-Partition 600(0) vier von acht PPU-Abschnitten 610 zugewiesen und damit die Hälfte der PPU-Ressourcen 500 einschließlich verschiedener Bandbreitentypen, wie z.B. Speicherbandbreite, zur Verfügung gestellt. Dementsprechend wäre die PPU-Partition 610(0) darauf beschränkt, die Hälfte der verfügbaren Systemspeicherbandbreite, die Hälfte der verfügbaren PPU-Speicherbandbreite, die Hälfte der verfügbaren PCE 212-Bandbreite usw. zu verbrauchen. In ähnlicher Weise werden der PPU-Partition 600(4) zwei von acht PPU-Abschnitten 610 zugewiesen und sie wird daher mit einem Viertel der PPU-Ressourcen 500 versorgt. Dementsprechend wäre die PPU-Partition 610(4) darauf beschränkt, ein Viertel der verfügbaren Systemspeicherbandbreite, ein Viertel der verfügbaren PPU-Speicherbandbreite, ein Viertel der verfügbaren PCE 212-Bandbreite usw. zu verbrauchen. Die anderen PPU-Partitionen 600(6) und 600(7) würden in analoger Weise eingeschränkt werden. Fachkundige Personen werden verstehen, wie die oben diskutierte beispielhafte Partitionierung und die damit assoziierte Ressourcenbereitstellung mit jeder anderen technisch geeigneten Konfiguration von PPU-Partitionen 600 umgesetzt werden kann.
In einigen Ausführungsbeispielen führt jede PPU Partition 600 Kontexte für eine virtuelle Maschine (VM) aus. In einem Ausführungsbeispiel kann die PPU 200 verschiedene Leistungsmonitore und Drosselungszähler implementieren, die die Menge der lokalen und/oder systemweiten Ressourcen aufzeichnen, die von jeder PPU-Partition 600 verbraucht werden, um einen proportionalen Ressourcenverbrauch über alle PPU-Partitionen 600 hinweg aufrechtzuerhalten. Die Zuweisung des entsprechenden Anteils der PPU-Speicherbandbreite an eine PPU-Partition 600 kann durch die Zuweisung desselben Anteils von L2-Abschnitten 400 an die PPU-Partition 600 erreicht werden.
Generell können PPU-Partitionen 600 so konfiguriert werden, dass sie in funktionaler Isolierung relativ zueinander arbeiten. Wie hierin erwähnt, bedeutet der Begriff „funktionale Isolierung“, wie er auf einen Satz von PPU-Partitionen 600 angewendet wird, im Allgemeinen, dass jede PPU-Partition 600 eine oder mehrere Operationen unabhängig von den Operationen durchführen kann, die von einer beliebigen anderen PPU-Partition 600 im Satz von PPU-Partitionen 600 durchgeführt werden, ohne diese zu stören und ohne von ihnen gestört zu werden.
Eine bestimmte PPU Partition 600 kann so konfiguriert werden, dass sie gleichzeitig Verarbeitungsaufgaben ausführt, die mit mehreren Verarbeitungskontexten assoziiert sind. Der Begriff „Verarbeitungskontext“ oder „Kontext“ bezieht sich im Allgemeinen auf den Zustand der Hardware-, Software- und/oder Speicherressourcen während der Ausführung eines oder mehrerer Threads und entspricht im Allgemeinen einem Prozess auf CPU 110. Die mit einer bestimmten PPU Partition 600 assoziierten Mehrfachverarbeitungskontexte können verschiedene Verarbeitungskontexte oder verschiedene Instanzen desselben Verarbeitungskontextes sein. Wenn sie auf diese Weise konfiguriert werden, werden spezifische PPU-Ressourcen, die der gegebenen PPU-Partition 600 zugewiesen sind, logisch in separate „SMC-Engines“ gruppiert, die getrennte Verarbeitungsaufgaben ausführen, die mit getrennten Verarbeitungskontexten assoziiert sind, wie weiter unten in Verbindung mit 7 näher beschrieben wird. Ein gegebener Verarbeitungskontext könnte z.B. Hardware-Einstellungen, Pro-Thread-Instruktionen und/oder Registerinhalte umfassen, die mit Threads assoziiert sind, die innerhalb einer SMC-Engine 700 ausgeführt werden.
7 zeigt in einem Beispiel, wie der Hypervisor von 1 einen Satz von PPU-Partitionen konfiguriert, um eine oder mehrere Simultaneous Multiple Context (SMC) -Engines zu implementieren, gemäß verschiedenen Ausführungsbeispielen. Wie gezeigt, umfassen die PPU-Partitionen 600 eine oder mehrere SMC-Engines 700. Insbesondere umfasst die PPU-Partition 600(0) die SMC-Engines 700(0) und 700(2), die PPU-Partition 600(4) die SMC-Engine 700(4), die PPU-Partition 600(6) die SMC-Engine 700(6) und die PPU-Partition 600(7) die SMC-Engine 700(7). Jede SMC-Engine 700 kann so konfiguriert werden, dass sie einen oder mehrere Verarbeitungskontexte ausführt und/oder so konfiguriert werden, dass sie eine oder mehrere mit einem bestimmten Verarbeitungskontext assoziierte Verarbeitungsaufgaben ausführt, in gleicher Weise wie die PPU 200 als Ganzes.
Eine bestimmte SMC-Engine 700 umfasst im Allgemeinen Rechen- und Speicherressourcen, die mit mindestens einem PPU-Abschnitt 610 assoziiert sind. Beispielsweise umfassen die SMC-Engines 700(6) und 700(7) die Rechen- und Speicherressourcen, die mit den PPU-Abschnitten 610(6) bzw. 610(7) assoziiert sind. Jede SMC-Engine 700 umfasst auch einen Satz virtueller Engine Identifizierer (engl. Virtual Engine Identifiers, VEIDs) 702, die lokal auf einen oder mehrere Subkontexte verweisen, wobei ein VEID mit einem Identifier für virtuellen Adressraum assoziiert ist und mit diesem identisch sein kann, der zur Auswahl eines virtuellen Adressraums verwendet wird, wobei die Seiten der virtuellen Adressräume durch Seitentabellen beschrieben werden, die vom MMU1600 verwaltet werden. Eine bestimmte SMC-Engine 700 kann auch Rechen- und Speicherressourcen umfassen, die mit mehreren PPU-Abschnitten 610 assoziiert sind. Zum Beispiel umfasst die Engine 700(0) die Rechen-Engine 700(0) die mit den PPU-Abschnitten 610(0) und 610(1) assoziierten Rechenressourcen, verwendet aber nicht die Sys-Pipe 230(1). Die Engine 700(0) umfasst und verwendet die L2-Abschnitte in vier PPU-Abschnitten 610(0), 610(1), 610(2) und 610(3). In einigen Ausführungsbeispielen teilen sich die SMC-Engines 700 innerhalb desselben PPU-Abschnitts 600 die L2-Abschnitte innerhalb des PPU-Abschnitts 600. In dieser Konfiguration ist die Sys-Pipe 230(1) der PPU-Partition 600(1), wie gezeigt, unbenutzt, da eine SMC-Engine in der Regel jeweils nur einen Verarbeitungskontext ausführt und nur eine Sys-Pipe 230 für einen Verarbeitungskontext benötigt wird. Die Engine 700(2) ist in der gleichen Weise konfiguriert wie die Engine 700(0). Die in einer bestimmten PPU-Partition 600 enthaltenen Speicherressourcen, die einer beliebigen oder mehreren SMC-Engines 700 innerhalb dieser bestimmten PPU-Partition 700 zugewiesen und/oder auf diese verteilt werden können, werden als PPU-Speicherpartitionen 710 dargestellt.
Eine bestimmte PPU-Speicherpartition 710 umfasst den Satz von L2-Abschnitten, der in der PPU-Partition 600 enthalten ist, und entsprechende Abschnitte von DRAM 272. In der Regel teilen sich mehrere SMC-Engines 700 eine PPU-Speicherpartition 710, wenn die SMC-Engines 700 in derselben PPU-Partition 600 enthalten sind. Die Zuweisungen an die einzelnen SMC-Engines 700 werden für die Kontexte bereitgestellt, die auf diesen SMC-Engines 700 laufen, und die Zuweisungen innerhalb der PPU-Speicherpartition 710 werden basierend auf Seiten implementiert.
Jede SMC Engine 700 kann so konfiguriert werden, dass sie jederzeit unabhängig Verarbeitungsaufgaben ausführt, die mit einem beliebigen Verarbeitungskontext assoziiert sind. Dementsprechend kann die PPU Partition 600(0) mit den beiden SMC-Engines 700(0) und 700(2) so konfiguriert werden, dass sie zu einem beliebigen Zeitpunkt simultan Verarbeitungsaufgaben ausführt, die mit zwei separaten Verarbeitungskontexten assoziiert sind. PPU-Partitionen 600(4), 600(6) und 600(7) hingegen, die jeweils eine SMC-Engine 700(4), 700(6) bzw. 700(7) umfassen, können so konfiguriert werden, dass sie zu einem bestimmten Zeitpunkt Verarbeitungsaufgaben ausführen, die jeweils einem Verarbeitungskontext zugeordnet sind. In einigen Ausführungsbeispielen können Kontexte, die auf den SMC-Engines 700 in verschiedenen PPU-Partitionen 600 laufen, Daten gemeinsam nutzen, indem sie eine oder mehrere Seiten in einer oder beiden PPU-Partitionen 600 gemeinsam nutzen.
Eine beliebige SMC Engine 700 kann weiter konfiguriert werden, um verschiedene Verarbeitungskontexte über verschiedene Zeitintervalle in Abschnitte zu unterteilen. Dementsprechend kann jede SMC Engine 700 unabhängig die Ausführung von Verarbeitungsaufgaben unterstützen, die mit mehreren Verarbeitungskontexten assoziiert sind, wenn auch nicht unbedingt gleichzeitig. Beispielsweise könnte die Engine 700(6) vier verschiedene Abschnitte über vier verschiedene Zeitintervalle zeitlich aufteilen, so dass Verarbeitungsaufgaben, die mit diesen vier Verarbeitungskontexten assoziiert sind, innerhalb von PPU-Abschnitt 600(6) ausgeführt werden können. In einigen Ausführungsbeispielen werden VMs auf einer oder mehreren PPU-Partitionen 600 in zeitlichen Abschnitten angeordnet. Beispielsweise kann die PPU-Partition 600(0) zeitliches Aufteilen zwischen zwei VMs vornehmen, wobei jede VM gleichzeitig zwei Verarbeitungskontexte ausführt, einen auf jeder SMC-Engine 700(0) und 700(1). In diesen Ausführungsbeispielen ist es vorzuziehen, alle Verarbeitungskontexte aus einer ersten VM auszuschalten, bevor der Kontextwechsel in den Verarbeitungskontexten aus einer zweiten VM erfolgt, was von Vorteil ist, wenn die auf der PPU-Partition 600(0) laufenden Verarbeitungskontexte die L2-Abschnitte 400 gemeinsam nutzen, die sich innerhalb der PPU-Partition 600(0) befinden.
In einem Ausführungsbeispiel kann eine bestimmte VM mit einer GPU-Funktions-ID (GFID) assoziiert werden. Eine bestimmte GFID kann ein oder mehrere Bits umfassen, die einer Physikalischen Funktionalität (PF) entsprechen, die mit der Hardware assoziiert ist, auf der die VM ausgeführt wird. Der gegebene GFID kann auch einen Satz von Bits umfassen, der einer Virtuellen Funktionalität (VF) entspricht, die der VM eindeutig zugeordnet ist. Ein gegebener GFID kann u. a. dazu verwendet werden, Fehler an ein entsprechendes Gastbetriebssystem einer VM zu leiten.
Die SMC-Engines 700 innerhalb verschiedener PPU-Partitionen 600 arbeiten in der Regel isoliert voneinander, da, wie bereits erwähnt, jede PPU-Partition 600 eine harte Partitionierung von PPU-Ressourcen 500 ist. Mehrere SMC-Engines 700 innerhalb derselben PPU-Partition 600 können im Allgemeinen unabhängig voneinander arbeiten und insbesondere unabhängig voneinander den Kontext wechseln. Beispielsweise könnte die SMC-Engine 700(0) innerhalb der PPU-Partition 600(0) unabhängig und asynchron relativ zur SMC-Engine 700(2) kontextabhängig wechseln. In einigen Ausführungsbeispielen können mehrere SMC-Engines 700 innerhalb desselben PPU-Abschnitts 600 den Kontextwechsel synchronisieren, um bestimmte Betriebsarten zu unterstützen, wie z.B. zeitliches Aufteilen (engl. time-slicing) zwischen zwei VMs.
Im Allgemeinen arbeiten Gerätetreiber 122 und Hypervisor 124 der 1 zusammen, um PPU 200 in der bisher beschriebenen Weise zu partitionieren. Darüber hinaus arbeiten Gerätetreiber 122 und Hypervisor 124 zusammen, um jede PPU-Partition 600 in eine oder mehrere SMC-Engines 700 zu konfigurieren. Dabei konfigurieren Gerätetreiber 122 und Hypervisor 124 DRAMs 272 und/oder L2-Cache 400, um den Satz von L2-Abschnitten in Gruppen zu unterteilen, die jeweils eine SMC-Speicherpartition 710 darstellen, wie unten in Verbindung mit 8 ausführlicher beschrieben. In einigen Ausführungsbeispielen reagiert Hypervisor 124 auf die Steuerung durch einen Systemadministrator, damit dieser Konfigurationen von PPU-Partitionen erstellen kann. Diese PPU-Partitionen 600 werden an das Gastbetriebssystem 916 einer VM übergeben, und das Gastbetriebssystem 916 sendet anschließend Anfragen an Hypervisor 124, eine assoziierte PPU-Partition 600 in eine oder mehrere SMC-Engines 700 zu konfigurieren. In einigen Ausführungsbeispielen kann das Gastbetriebssystem die SMC Engines 700 direkt innerhalb einer PPU-Partition 700 konfigurieren, da eine ausreichende Isolierung hinzugefügt wird, um zu verhindern, dass ein Gastbetriebssystem die PPU-Partition 700 eines anderen Gastbetriebssystems beeinträchtigt.
8A ist eine detailliertere Darstellung des DRAMs von 7, gemäß verschiedenen Ausführungsbeispielen. Wie gezeigt, ist der DRAM 272, der jeden der DRAMs 272(0) bis 272(7) der 7 umfasst, über L2-Abschnitte 800 zugänglich. Jeder L2-Abschnitt 800 entspricht einem anderen Abschnitt des L2-Cache 400 und ist für den Zugriff auf einen entsprechenden Teilsatz von Speicherorten innerhalb des DRAM 272 konfiguriert. Im Allgemeinen entspricht die Partitionierung von DRAM 272 einem rohen 2D-Adressraum, der in ähnlicher Weise organisiert ist wie der hier gezeigte DRAM 272.
Wie ebenfalls gezeigt, ist der DRAM 272 in eine obere Sektion 810, eine unterteilbare Sektion 820 und eine untere Sektion 830 unterteilt. Bei der oberen Sektion 810 und der unteren Sektion 830 handelt es sich um Speicher-Carve-Outs, die von den oberen bzw. unteren Teilen aller DRAMs 272(0) bis 272(7) abgeleitet sind. Gerätetreiber 122, Hypervisor 124 und andere Einheiten auf Systemebene haben Zugriff auf die obere Sektion 810 und/oder die untere Sektion 830, und in einigen Ausführungsbeispielen sind diese Sektionen für PPU-Partitionen 600 nicht zugänglich. Die partitionierbare Sektion 820 hingegen ist für die Verwendung von PPU-Partitionen 600 im Allgemeinen und den SMC-Engines 700 im Besonderen vorgesehen. In einigen Ausführungsbeispielen befinden sich sichere Daten in der oberen Sektion 810 oder der unteren Sektion 830 und sind für alle PPU-Partitionen 600 zugänglich. In einigen Ausführungsbeispielen werden die obere Sektion 810 oder die untere Sektion 830 für Hypervisor-Daten verwendet, auf die die VMs keinen Zugriff haben.
In der gezeigten beispielhaften Speicherpartitionierung umfasst die partitionierbare Sektion 820 den DRAM-Bereich 822(0), der der PPU-Speicherpartition 710(0) innerhalb der PPU-Partition 600(0) entspricht, den DRAM-Bereich 822(4), der der PPU-Speicherpartition 710(4) innerhalb der PPU-Partition 600(2) entspricht, den DRAM-Bereich 822(6), der der PPU-Speicherpartition 710(6) innerhalb der PPU-Partition 600(6) entspricht, und den DRAM-Bereich 822(7), der der PPU-Speicherpartition 710(7) innerhalb der PPU-Partition 600(7) entspricht. Jeder DRAM-Bereich 822 entspricht dem mittleren Bereich der Adressen, die einem Satz von L2-Cache-Abschnitte 800 entsprechen. Ein bestimmter DRAM-Bereich 822 kann weiter unterteilt werden, um separate Sätze von L2-Cache-Abschnitten für verschiedene VMs bereitzustellen, die Verarbeitungsaufgaben ausführen, die mit unterschiedlichen Verarbeitungskontexten assoziiert sind. Beispielsweise könnte der DRAM-Bereich 822(4) in zwei oder mehr Regionen unterteilt werden, um zwei oder mehr VMs zu unterstützen, die Verarbeitungsaufgaben ausführen, die mit zwei oder mehr Verarbeitungskontexten assoziiert sind. Sobald ein DRAM-Bereich konfiguriert und verwendet wird, wird er im Allgemeinen zu jeweils einem Zeitpunkt von einer VM verwendet, die auf einer PPU-Partition 600 läuft.
Im Betrieb führen Gerätetreiber 122 und Hypervisor 124 Speicherzugriffsoperationen innerhalb der oberen Sektion 810 und/oder der unteren Sektion 830 über obere Bereiche und untere Bereiche von Adressbereichen, die allen L2-Cache-Abschnitten 800 entsprechen, in relativ ausgewogener Weise durch, wodurch die Speicherbandbreite über jeden L2-Abschnitt 800 proportional bestraft wird. In einigen Ausführungsbeispielen führen die SMC-Engines 700 Speicherzugriffsoperationen auf den Systemspeicher 120 über L2-Cache-Abschnitte 800 mit einem Durchsatz durch, der von den Drosselzählern 840 gesteuert wird. Jeder Drosselzähler 840 überwacht die Speicherbandbreite, die verbraucht wird, wenn die SMC-Engines 700 über L2-Cache-Abschnitte 800, die den entsprechenden PPU-Speicherpartitionen 710 zugeordnet sind, auf den Systemspeicher 120 zugreifen, um für jede PPU-Partition 600 eine proportionale Speicherbandbreite bereitzustellen. Wie besprochen, erhalten PPU-Partitionen 600 Zugriff auf verschiedene systemweite Ressourcen im Verhältnis zur Konfiguration dieser PPU-Partitionen 600. In dem gezeigten Beispiel wird der PPU-Partition 600(0) die Hälfte der PPU-Ressourcen 500 und damit die Hälfte der partitionierbaren Sektion 820 (dargestellt als DRAM-Bereich 822(0)) und dementsprechend die Hälfte der verfügbaren Speicherbandbreite dem Systemspeicher 120 zugewiesen. Die Partitionierung von DRAM 272 wird nachstehend in Verbindung mit den 19-24 detaillierter beschrieben.
8B zeigt, wie die verschiedenen DRAM-Sektionen von 8B adressiert werden, gemäß verschiedenen Ausführungsbeispielen. Wie gezeigt, umfasst ein eindimensionaler (1D-) Adressraum physikalischer Adressen des Systems (engl. system physical adress, SPA) 850 die oberen Adressen 852, die der oberen Sektion 810 entsprechen, die partitionierbaren Adressen 854, die in Adressbereiche 856 unterteilt sind und den DRAM-Bereichen 822 entsprechen, sowie die unteren Adressen 858, die der unteren Sektion 830 entsprechen. Die oberen Adressen 852 sind allen L2-Abschnitten 800 zugeordnet (engl. swizzled, d. h. pseudozufällig auf der Basis der SPA-Adresse verschachtelt, engl. interleaved) und entsprechen den oberen Bereichen dieser L2-Abschnitte. Die unteren Adressen 858 werden allen L2-Abschnitten 800 zugeordnet (engl. swizzled) und korrespondieren mit den unteren Bereichen dieser L2-Abschnitte. Die oberen Adressen 852 und die unteren Adressen 858 sind im Allgemeinen nur für Entitäten auf Systemebene wie Hypervisor 124 und/oder beliebige Entitäten, die über eine physikalische Funktionalität (PF) arbeiten, zugänglich. Partitionierbare Adressen 854 sind den PPU-Partitionen 600 zugeordnet. Insbesondere ist der Adressbereich 856(0) der PPU-Partition 600(0), der Adressbereich 856(4) der PPU-Partition 600(4), der Adressbereich 856(6) der PPU-Partition 600(6) und der Adressbereich 856(7) der PPU-Partition 600(7) zugeordnet. Adressbereiche 856 können nur für die SMC-Engine(s) 700 zugänglich sein, die innerhalb der entsprechenden PPU-Partitionen 600 ausgeführt wird bzw. werden.
Unter allgemeiner Bezugnahme auf die 5-8B unterstützt der obige Ansatz zum Partitionieren der PPU-Ressourcen 500 eine Reihe von Nutzungsszenarien, die u.a. Nutzungsszenarien mit einem Mandanten und mit mehreren Mandanten (engl. single-tenant und multi-tenant) umfassen. In einem Nutzungsszenario mit einem Mandant kann die PPU 200 partitioniert werden, um verschiedenen Benutzern, die mit einem einzigen Mandant assoziiert sind, unabhängigen Zugriff auf PPU-Ressourcen zu ermöglichen. Beispielsweise könnten verschiedene Benutzer, die mit einem bestimmten Mandant assoziiert sind, unterschiedliche kuratierte Arbeitslasten auf verschiedenen PPU-Partitionen 600 ausführen. In Nutzungsszenarien mit einem einzigen Mandant kann einer einzigen Einheit Zugriff auf die Gesamtheit der PPU-Ressourcen 500 gewährt werden. In einem Nutzungsszenario mit mehreren Mandanten kann die PPU 200 partitioniert werden, um einem oder mehreren Benutzern, die mit einem oder mehreren verschiedenen Mandanten assoziiert sind, unabhängigen Zugriff auf PPU-Ressourcen zu ermöglichen. In einem Nutzungsszenario mit mehreren Mandanten können mehrere Einheiten Zugriff auf verschiedene PPU-Partitionen 600 erhalten, die verschiedene Bereiche der PPU-Ressourcen 500 umfassen.
In einem beliebigen Anwendungsszenario arbeiten Gerätetreiber 122 und Hypervisor 124 zusammen, um einen zweistufigen Prozess durchzuführen, der erstens die Partitionierung von PPU 200 in PPU-Partitionen 600 und zweitens die Konfiguration dieser PPU-Partitionen 600 zu den SMC-Engines 700 umfasst. Dieser Prozess wird nachstehend in Verbindung mit den 9-10 detaillierter beschrieben.
Techniken zum Konfigurieren logischer Gruppierungen von Hardware-Ressourcen
9 zeigt in einem Flussdiagramm, wie der Hypervisor von 1 eine PPU partitioniert und konfiguriert, gemäß verschiedenen Ausführungsbeispielen. Wie dargestellt, umfasst die Hypervisor-Umgebung 900 eine Gastumgebung 910 und eine Host-Umgebung 920, die durch eine Hypervisor-Vertrauensgrenze 930 voneinander getrennt sind. Die Gastumgebung 910 umfasst die Systemverwaltungsschnittstelle (SMI) 912, den Treiberkernel 914 und das Gastbetriebssystem (OS) 916. Die Host-Umgebung 920 umfasst SMI 922, Plugin 924 für virtuelle GPUs (vGPUs), Host-Betriebssystem 926 und den Treiberkernel 928. Module, die in der Gastumgebung 910 enthalten sind und sich oberhalb der Hypervisor-Vertrauensgrenze 930 befinden, werden im Allgemeinen mit einer niedrigeren Berechtigungsstufe ausgeführt als Module, die in der Host-Umgebung 920 enthalten sind und sich unterhalb der Hypervisor-Vertrauensgrenze 930 befinden, einschließlich wiederholter Instanzen desselben Moduls, wie SMI 912 und SMI 922. Hypervisor 124 wird mit einem Satz von Berechtigungen auf Kernel-Ebene ausgeführt und kann jedem der gezeigten Module entsprechende Berechtigungen erteilen. In einigen Ausführungsbeispielen besteht eine Eins-zu-Eins-Entsprechung zwischen einer VM und einer Gastumgebung 910; und wenn mehrere VMs nicht kontextbezogen auf eine PPU-Partition 600 gewechselt werden, besteht im Allgemeinen eine Eins-zu-Entsprechung zwischen Gastumgebungen und PPU-Partitionen.
Im Betrieb interagiert ein Admin-Benutzer der PPU 200 mit der PPU 200 über die Host-Umgebung 920 und das Host-Betriebssystem 926, um PPU-Partitionen 600 zu konfigurieren. Insbesondere stellt der Admin-Benutzer dem SMI 922 eine Partitionierungseingabe 904 bereit. Als Antwort darauf gibt SMI 922 einen Befehl „Partition erstellen“ an den Treiberkernel 928 aus, der die Zielkonfiguration der PPU-Partitionen 600 angibt. Der Treiberkernel 928 überträgt den Befehl „Partition erstellen“ an die Host-Schnittstelle 220 innerhalb der PPU 200, um die verschiedenen PPU-Ressourcen 500 zu partitionieren. Auf diese Weise kann der Admin-Benutzer die PPU 200 initialisieren, um eine spezifische Konfiguration der PPU-Partitionen 600 zu erhalten. Im Allgemeinen hat der Admin-Benutzer uneingeschränkten Zugriff auf PPU 200. Der Admin-Benutzer könnte beispielsweise der Systemadministrator in einem Rechenzentrum sein, in dem sich PPU 200 befindet. Der Admin-Benutzer könnte der Systemadministrator in einem Rechenzentrum sein, in dem sich eine Vielzahl von PPUs 200 befindet. Der Admin-Benutzer partitioniert PPU 200 in der beschriebenen Weise, um die verschiedenen PPU-Partitionen 600 so vorzubereiten, dass sie von verschiedenen Gastbenutzern unabhängig konfiguriert und verwendet werden können, wie weiter unten ausführlicher beschrieben.
Ein Gastbenutzer der PPU 200 interagiert mit einer bestimmten „Gast“-PPU-Partition 600 über eine VM, die innerhalb der Gastumgebung 910 ausgeführt wird, um die SMC-Engines 700 innerhalb dieser Gast-PPU-Partition 600 zu konfigurieren. Konkret stellt der Gastbenutzer eine Konfigurationseingabe 902 an den SMI 912 bereit. Das SMI 912 gibt dann einen Befehl „Partition konfigurieren“ an den Treiberkernel 914 aus, der die Zielkonfiguration der SMC-Engines 700 angibt. Der Treiberkernel 914 überträgt den Befehl „Partition konfigurieren“ über das Gastbetriebssystem 916 über die Hypervisor-Vertrauensgrenze 930 hinweg an vGPU-Plugin 924. vGPU-Plugin 924 gibt verschiedene VM-Aufrufe an den Treiberkernel 928 aus. Der Treiberkernel 928 überträgt den Befehl „Partition konfigurieren“ an die Host-Schnittstelle 220 innerhalb der PPU 200, um verschiedene Ressourcen der Gast-PPU-Partition 600 zu konfigurieren. Auf diese Weise kann der Gastbenutzer eine bestimmte PPU-Partition 600 so konfigurieren, dass sie eine spezifische Konfiguration von SMC-Engines 700 hat. Im Allgemeinen hat der Gastbenutzer nur eingeschränkten Zugriff auf einen Teil der PPU-Ressourcen 500, der mit der Gast-PPU-Partition 600 assoziiert ist. Der Gastbenutzer könnte z.B. ein Kunde des Rechenzentrums sein, in dem die PPU 200 liegt, der Zugang zu einem Anteil der PPU 200 erwirbt. In einem Ausführungsbeispiel können Gastbetriebssysteme 916 mit ausreichenden Sicherheitsmaßnahmen konfiguriert werden, damit jedes Gastbetriebssystem 916 eine entsprechende PPU-Partition 600 ohne Beteiligung der Host-Umgebung 920 und/oder des Hypervisors 124 konfigurieren kann.
10 zeigt ein Flussdiagramm mit Verfahrensschritten zum Partitionieren und Konfigurieren einer PPU im Auftrag eines oder mehrerer Benutzer, gemäß verschiedenen Ausführungsbeispielen. Obwohl die Verfahrensschritte in Verbindung mit den Systemen der 1-9 beschrieben werden, werden Fachleute verstehen, dass jedes System, das so konfiguriert ist, dass es die Verfahrensschritte in beliebiger Reihenfolge ausführt, unter den Umfang der vorliegenden Ausführungsbeispiele fällt.
Wie gezeigt, beginnt ein Verfahren mit Schritt 1000, in dem Hypervisor 124 eine Partitionierungseingabe 904 über die Host-Umgebung 920 empfängt. Die Host-Umgebung 920 wird mit einer erhöhten Berechtigungsstufe ausgeführt, wodurch ein Admin-Benutzer direkt mit PPU 200 interagieren kann. Die Partitionierungseingabe 904 spezifiziert eine Zielkonfiguration von PPU-Partitionen 600, einschließlich einer gewünschten Größe und Anordnung der PPU-Partitionen 600. In einem Ausführungsbeispiel kann die Partitionierungseingabe über die Host-Umgebung vom Admin-Benutzer empfangen werden.
In Schritt 1004 erzeugt der Hypervisor 124 eine oder mehrere PPU-Partitionen 600 innerhalb der PPU 200 basierend auf den in Schritt 1002 empfangenen Partitionierungseingabe 904. Insbesondere implementiert Hypervisor 124 das SMI 922, um einen „Partition erstellen“-Befehl an den Treiberkernel 928 auszugeben. In Reaktion darauf interagiert der Treiberkernel 928 mit der Host-Schnittstelle 220 der PPU 200, um eine oder mehrere PPU-Partitionen 600 mit der gewünschten Konfiguration zu erstellen.
In Schritt 1006 verteilt Hypervisor 124 die Speicherressourcen auf die in Schritt 1004 erzeugten PPU-Partition(en) 600. Insbesondere unterteilt Hypervisor 124 über den oben beschriebenen Befehl „Partition erstellen“ DRAM 272 in der oben in Verbindung mit 8A beschriebenen Weise, um verschiedene Bereiche von DRAM 272 und die entsprechenden L2-Cache-Abschnitte 800 den PPU-Partition(en) 600 zuzuweisen. In einem Ausführungsbeispiel kann Hypervisor 124 auch eine Adresszuordnungseinheit konfigurieren, um partitionsspezifische Swizzle-Operationen durchzuführen, um den Zugriff auf diese verschiedenen Bereiche von DRAM 272 über L2-Cache-Abschnitte 800 zu ermöglichen. Dieses spezielle Ausführungsbeispiel wird nachstehend in Verbindung mit 22 ausführlicher beschrieben.
In Schritt 1008 verteilt Hypervisor 124 die PPU-Berechnungs- und/oder Grafikressourcen auf die PPU-Partition(en) 600. Dabei weist Hypervisor 124 über den Befehl „Partition erstellen“ eine oder mehrere Sys-Pipes 230 und eine oder mehrere GPCs 242 diesen PPU-Partition(en) 600 zu. In einem Ausführungsbeispiel kann Hypervisor 124 die Schritte 1006 und 1008 implementieren, indem er einen oder mehrere PPU-Abschnitte 610 logisch den PPU-Partition(en) 600 zuweist, wodurch Speicherressourcen und Rechen-/Grafikressourcen zusammen zugewiesen werden. Wenn die Schritte 1002, 1004, 1006 und 1008 des Verfahrens 1000 abgeschlossen sind, wird PPU 200 partitioniert, und ein Gastbenutzer kann dann eine oder mehrere dieser PPU-Partitionen 600 konfigurieren, wie nachfolgend beschrieben.
In Schritt 1010 erhält Hypervisor 124 die Konfigurationseingabe 902, die über die Gastumgebung 910 mit einer ersten PPU-Partition assoziiert wird. Die Gastumgebung 910 wird mit einer reduzierten Berechtigungsstufe ausgeführt, wodurch ein Gastbenutzer nur mit der ersten PPU-Partition 600 interagieren kann. Die Konfigurationseingabe 902 spezifiziert eine Zielkonfiguration der SMC-Engines 700 innerhalb der ersten PPU-Partition 600, einschließlich einer gewünschten Größe und Anordnung der SMC-Engines 700. In einem Ausführungsbeispiel kann die Konfigurationseingabe vom Gastbenutzer über die Gastumgebung empfangen werden.
In Schritt 1012 erzeugt der Hypervisor 124 über den Befehl „Partition konfigurieren“ eine oder mehrere SMC-Engines 700 innerhalb der ersten PPU-Partition 600 basierend auf der in Schritt 1010 empfangenen Konfigurationseingabe 902. Eine bestimmte SMC-Engine 700 kann Rechen- und/oder Grafikressourcen umfassen, die von einer Sys-Pipe 230 und einem oder mehreren GPCs 242 abgeleitet sind, die von einem oder mehreren PPU-Abschnitten 610 abgeleitet sind. Eine bestimmte SMC-Engine 700 hat Zugriff auf mindestens einen Bereich einer PPU-Speicherpartition 710, die in der PPU-Partition 600 enthalten ist, in der sich die SMC-Engine 700 befindet, wobei diese PPU-Speicherpartition 710 einen oder mehrere Sätze von L2-Cache-Abschnitten und entsprechende Bereiche von DRAM 272 umfasst.
In Schritt 1014 verteilt Hypervisor 124 die der ersten PPU Partition 600 zugewiesenen Speicherressourcen auf die in Schritt 1012 erzeugte(n) SMC Engine(s) 700. Im Allgemeinen teilen sich die SMC-Engine(s) 700 die erste PPU-Speicherpartition 710, wenn diese SMC-Engine(s) 700 in derselben PPU-Partition 600 enthalten sind. Die Zuweisungen an jede SMC-Engine 700 werden den Kontexten, die auf diesen SMC-Engines 700 laufen, zur Verfügung gestellt, und die Zuweisungen innerhalb der PPU-Speicherpartition 710 werden basierend auf Seiten implementiert. In einigen Ausführungsbeispielen führt das Gastbetriebssystem 916 einer VM den Schritt 1014 aus, indem es Speicherressourcen an die Kontexte verteilt, die auf den SMC-Engines 700 laufen, die Teil der PPU-Partition 600 sind, die zur Gastumgebung 910 gehört. In anderen Ausführungsbeispielen führt der Hypervisor 124 eine Speicherressourcenzuweisung 1014 für mehrere VMs unter Verwenden einer PPU-Partition 600 durch, und jede VM verteilt auch Speicherressourcen 1024 auf Kontexte, die auf den SMC-Engines 700 laufen.
In Schritt 1016 verteilt Hypervisor 124 die der ersten PPU-Partition 600 zugewiesenen Rechen- und/oder Grafikressourcen auf die in Schritt 1012 erzeugte(n) SMC-Engine(n) 700. Über den Befehl „Partition konfigurieren“ weist Hypervisor 124 jeder SMC-Engine 700 eine bestimmte Sys-Pipe 230 zu, die in der Gast-PPU-Partition 600 enthalten ist. Der Hypervisor 124 ordnet außerdem jeder SMC-Engine 700 eine oder mehrere GPCs 242 zu. Wenn die Schritte 1010, 1012, 1014 und 1016 des Verfahrens 1000 abgeschlossen sind, ist die erste PPU-Partition 600 konfiguriert, und der Gastbenutzer kann dann Verarbeitungsoperationen auf der/den SMC-Engine(s) 700 innerhalb dieser PPU-Partition 600 einleiten.
In Schritt 1018 veranlasst Hypervisor 124 die erste PPU-Partition 600 dazu, eine oder mehrere VMs über die SMC-Engine(s) 700, die innerhalb der ersten PPU-Partition 600 konfiguriert ist/sind, in zeitlichen Abschnitten zu unterteilen (engl. timeslice). Die in zeitliche Abschnitte aufgeteilten VMs können unabhängig von anderen VMs arbeiten, die innerhalb der ersten PPU-Partition 600 ausgeführt werden, und isoliert von anderen VMs arbeiten, die innerhalb anderer PPU-Partitionen 600 ausgeführt werden. In einem Ausführungsbeispiel können eine oder mehrere VMs gleichzeitig über die Engine(s) 700 des SMC in zeitlichen Abschnitte unterteilt werden. Auf diese Weise ermöglichen die offenbarten Techniken, dass eine fraktionierte PPU die parallele Ausführung von Verarbeitungsaufgaben unterstützt, die mit mehreren unterschiedlichen Verarbeitungskontexten assoziiert sind.
In einigen Ausführungsbeispielen werden die hier offenbarten Techniken in einem nicht-virtualisierten System angewandt. Fachkundige Personen werden erkennen, dass ein einziges Betriebssystem-Nutzungsmodell auf einer PPU 200 oder einem Satz von PPUs 200 alle beschriebenen Mechanismen in Verbindung mit VMs verwenden kann. In einigen Ausführungsbeispielen entsprechen Container der Beschreibung von VMs, was bedeutet, dass Container auf einem einzelnen Betriebssystem die Verarbeitungsisolation erreichen können, die den hier beschriebenen VMs gewährt wird.
Aufteilen von Rechenressourcen zur Unterstützung simultaner Mehrfachkontexte
In verschiedenen Ausführungsbeispielen, wenn der Hypervisor 124 die PPU 200 im Auftrag eines Admin-Benutzers in der oben beschriebenen Weise partitioniert, erhält Hypervisor 124 eine Eingabe vom Admin-Benutzer, die verschiedene Grenzen zwischen PPU-Partitionen 600 anzeigt. Basierend auf dieser Eingabe gruppiert Hypervisor 124 PPU-Abschnitte 610 logisch in PPU-Partitionen 600, weist jeder PPU-Partition 600 verschiedene Hardware-Ressourcen zu und koordiniert verschiedene andere Operationen, um die simultane Implementierung mehrerer Verarbeitungskontexte innerhalb einer bestimmten PPU-Partition 600 zu unterstützen. Hypervisor 124 führt auch zusätzliche Techniken aus, um die Migration von Verarbeitungskontexten zwischen PPU-Partitionen 600, die auf verschiedenen PPUs 200 konfiguriert sind, zu unterstützen. Diese verschiedenen Techniken werden nachstehend in Verbindung mit den 11-18 detaillierter beschrieben.
11 zeigt ein Ausführungsbeispiel einer Partitionskonfigurationstabelle, nach der der Hypervisor 124 von 1 eine oder mehrere PPU-Partitionen gemäß verschiedenen Ausführungsbeispielen konfigurieren kann. Wie gezeigt, umfasst die Partitionskonfigurationstabelle 1100 die Partitionierungsoptionen 0 bis 14. Die Partitionierungsoptionen 0-14 sind über den PPU-Abschnitten 610 dargestellt. Jede der Partitionierungsoptionen 0-14 umfasst eine andere Gruppierung von PPU-Abschnitten 610 und repräsentiert auf diese Weise eine andere mögliche PPU-Partition 600. Insbesondere umfasst die Partitionierungsoption 0 die PPU-Abschnitte 610(0) bis 610(7) und repräsentiert somit eine PPU-Partition 600, die alle acht PPU-Abschnitte 610 umfasst. In ähnlicher Weise überspannt die Partitionierungsoption 1 die PPU-Abschnitte 610(0) bis 610(3) und repräsentiert daher eine PPU-Partition 600, die nur die ersten vier PPU-Abschnitte 610 umfasst, ähnlich wie die in 6-7 dargestellte PPU-Partition 600(0). Partitionierungsoption 2 umfasst die PPU-Abschnitte 610(4) bis 610(7) und repräsentiert daher eine PPU-Partition 600, die nur die letzten vier PPU-Abschnitte 610 umfasst. Die Partitionierungsoptionen 3, 4, 5 und 6 umfassen verschiedene Gruppierungen von zwei benachbarten PPU-Abschnitten 610, während die Partitionierungsoptionen 7, 8, 9, 10, 11, 12, 13 und 14 nur einen entsprechenden PPU-Abschnitt 610 umfassen.
Die Partitionskonfigurationstabelle 1100 umfasst auch die Grenzoptionen 1110, die verschiedene mögliche Positionen für Partitionsgrenzen repräsentieren. Insbesondere repräsentieren die Grenzoptionen 1110(1) und 1110(9) die Grenzen von Partitionierungsoption 0, während die Grenzoptionen 1110(1) und 110(5) die Grenzen von Partitionierungsoption 1 repräsentieren, während die Grenzoptionen 1110(5) und 1110(9) die Grenzen von Partitionierungsoption 2 repräsentieren. Die Grenzoptionen 1110(1), 1110(3), 1110(5), 1110(7) und 1110(9) repräsentieren die Grenzen, die mit den Partitionierungsoptionen 3, 4, 5 und 6 assoziiert sind. Die Grenzoptionen 1110(1) bis 1110(9) repräsentieren Grenzen, die mit den Partitionierungsoptionen 7 bis 14 assoziiert sind. Es ist zu beachten, dass fachkundige Personen viele verschiedene Schemata erstellen können, um dieselbe Funktionalität wie die Konfigurationstabelle 1100 zu erreichen, d.h. einen Satz von Aktivierungsbits, eine Liste von vordefinierten Auswahlmöglichkeiten oder eine beliebige andere Form, die eine Kontrolle darüber ermöglicht, wie PPU-Abschnitte 610 in PPU-Partitionen 600 partitioniert werden können. Weiter werden fachkundige Personen verstehen, dass die Partitionskonfigurationstabelle 1100 jede weitere technisch geeignete Anzahl von Einträgen umfassen kann, die nicht in 11 dargestellt sind.
Während der Partitionierung empfängt Hypervisor 124 oder Gerätetreiber 122, der auf Hypervisor-Ebene läuft, vom Admin-Benutzer Eingaben zur Partitionierung, die spezifische Partitionierungsoptionen angeben, nach denen PPU 200 partitioniert werden soll. Hypervisor 124 oder Gerätetreiber 122 aktiviert dann einen spezifischen Satz von Grenzoptionen 1110, die eine oder mehrere Gruppen von PPU-Abschnitten 610 logisch voneinander isolieren, um die gewünschte Partitionierung zu implementieren, wie unten anhand des Beispiels in Verbindung mit 12 näher beschrieben.
12 zeigt, wie der Hypervisor 124 oder der Gerätetreiber 122 aus 1 eine PPU partitioniert, um eine oder mehrere PPU-Partitionen gemäß verschiedenen Ausführungsbeispielen zu erzeugen. Wie gezeigt, erhält der Hypervisor 124 oder der Gerätetreiber 122, der auf Hypervisor-Ebene läuft, während der Partitionierung eine Eingabe vom Admin-Benutzer, die angibt, dass die PPU 200 gemäß den Partitionierungsoptionen 1, 5, 13 und 14 (zur Verdeutlichung hervorgehoben) partitioniert werden soll. In Reaktion darauf aktiviert Hypervisor 124 oder Gerätetreiber 122 die Grenzoptionen 1110(1), 1110(5), 1110(7), 1110(8) und 1110(9) und deaktiviert die anderen Grenzoptionen, um die PPU-Partitionen 600(0), 600(4), 600(6) und 600(7) zu erzeugen. Diese beispielhafte Konfiguration der PPU-Partitionen 600 ist auch in den 6-7 dargestellt.

Allgemein auf die 11-12 Bezug nehmend, implementiert Hypervisor 124 oder der Gerätetreiber 122 die obigen Techniken, indem er jede Auswahl einer Partitionierungsoption einem bestimmten Binärwert zuordnet, der anschließend dazu verwendet wird, die Grenzoptionen 1110 zu aktivieren und zu deaktivieren. Der mit einer bestimmten Partitionierungsoption assoziierte Binärwert wird hier als „swizzle Identifizierer“ (swizID) bezeichnet. Die verschiedenen vom Hypervisor 124 implementierten swizlDs sind unten in Tabelle 1 tabellarisch dargestellt: Tabelle 1

Partitions-Option	SwizID
0	11000000011
1	10000100011
2	11000100001
3	10000001011
4	10000101001
5	10010100001
6	11010000001
7	10000000111
8	10000001101
9	10000011001
10	10000110001
11	10001100001
12	10011000001
13	10110000001
14	11100000001

Hypervisor 124 aktiviert oder deaktiviert Begrenzungsoptionen 1110 für eine gegebene Partitions-Option basierend auf der swizID, die mit der gegebenen Partitions-Option assoziiert ist. Beispielsweise könnte Hypervisor 124 die Begrenzungsoptionen 1110(1) und 1110(3) aktivieren, um PPU 200 gemäß Partitionierungsoption 3 basierend auf der entsprechenden swizlD, 10000001011, zu konfigurieren. Die Bits 1 und 3 dieser swizID aktivieren die Begrenzungsoptionen 1110(1) bzw. 1110(3), und die Bits 2 und 4-9 deaktivieren die übrigen Begrenzungsoptionen. Die Bits 0 und 10 aller swizlDs werden auf eins (1) gesetzt, um die Grenzen innerhalb des L2-Cache 400 zu aktivieren, wie unten in Verbindung mit den 19-20 detaillierter beschrieben. Hypervisor 124 sammelt die verschiedenen swizlDs für die verschiedenen ausgewählten Konfigurationsoptionen und berechnet eine ODER-Operation über alle gesammelten swizlDs, um eine Konfigurations-swizlD zu erzeugen, die die Konfiguration von PPU-Partitionen 600 definiert. Die Konfigurations-SwizID zeigt alle Begrenzungsoptionen 1110 an, die aktiviert und deaktiviert werden sollen, um die gewünschte Konfiguration der PPU-Partitionen 600 zu erreichen.
Fachkundige Personen werden erkennen, dass bestimmte Kombinationen von Partitionierungsoptionen nicht durchführbar sind. Zum Beispiel können die Partitionierungsoptionen 0 und 1 nicht in Verbindung miteinander implementiert werden, da die Partitionierungsoptionen 0 und 1 einander überlappen. Während des Partitionierens erkennt Hypervisor 124 automatisch undurchführbare Kombinationen von Partitionsoptionen und korrigiert diese Kombinationen, indem er eine oder mehrere Partitionsoptionen und/oder entsprechende swizlDs modifiziert oder eine oder mehrere Partitionsoptionen und/oder entsprechende swizlDs auslässt.
Darüber hinaus kann der Hypervisor 124 dynamisch Hardware-Fehler erkennen, die dazu führen, dass bestimmte Partitionierungsoptionen nicht durchführbar sind. Nehmen wir zum Beispiel an, der PPU-Abschnitt 610(0) umfasst einen nicht funktionsfähigen GPC 242, der während der Herstellung abgeschaltet (engl. floorswept) und abgetrennt (engl. fused off) wurde. In dieser Situation würde es einer PPU-Partition 600, die nur PPU-Abschnitt 610(0) umfasst, an ausreichenden Rechenressourcen für den Betrieb fehlen und wäre daher nicht zu implementieren. In dieser Situation würde Hypervisor 124 die Auswahl von Partitionierungsoption 7 und/oder die Verwendung der entsprechenden swizID verbieten, da jede beliebige PPU-Partition 600, die entsprechend dieser Partitionierungsoption konfiguriert ist, keine Rechenoperationen durchführen könnte und daher nicht korrekt funktionieren würde.
In einigen Situationen kann der Hypervisor 124 bestimmte Konfigurationsoptionen zulassen, die eine gewisse Menge nicht funktionsfähiger Hardware umfassen, solange eine PPU-Partition 600, die gemäß solchen Konfigurationsoptionen konfiguriert ist, noch bis zu einem gewissen Grad funktionieren kann. Im obigen Beispiel könnte Hypervisor 124 die Auswahl von Konfigurationsoption 3 erlauben, solange der PPU-Abschnitt 610(1) einen funktionsfähigen GPC 242 umfasst. Jede gemäß Konfigurationsoption 3 konfigurierte PPU-Partition 600 wäre zwar immer noch funktionsfähig, würde aber im Vergleich zu einer ähnlichen PPU-Partition 600, die keine nicht funktionsfähige Hardware enthält, nur die Hälfte der Rechenressourcen umfassen.
Im Anschluss an das Partitionieren der PPU 200 in der oben beschriebenen Weise weist Hypervisor 124 den resultierenden PPU-Partitionen 600 verschiedene Hardwareressourcen zu. Einige dieser Ressourcen werden statisch verschiedenen PPU-Abschnitten 610 zugewiesen und bieten dedizierte Unterstützung für bestimmte Operationen, während andere Ressourcen von verschiedenen PPU-Abschnitten 610 innerhalb desselben PPU-Abschnitts 600 oder innerhalb verschiedener PPU-Partitionen 600 gemeinsam genutzt werden, wie weiter unten in Verbindung mit 13 näher beschrieben wird.
13 zeigt, wie der Hypervisor von 1 verschiedene PPU-Ressourcen während der Partitionierung zuweist, gemäß verschiedenen Ausführungsbeispielen. Wie gezeigt, sind die PCE 222(0) bis 222(7) an die PPU-Abschnitte 610(0) bis 610(7) gekoppelt. In diesem Beispiel umfasst der PPU-Abschnitt 200 eine Anzahl von PCEs 222, die der Anzahl der PPU-Abschnitte 610 entspricht. Dementsprechend kann Hypervisor 124 jeden PCE 222 statisch einem anderen PPU-Abschnitt 610 zuweisen und diese PCE 222 so konfigurieren, dass sie Kopieroperationen im Namen des entsprechenden PPU-Abschnitts 610 auf dedizierte Weise durchführen.
Andere Hardwareressourcen, die in der PPU 200 enthalten sind, können nicht auf die oben beschriebene Weise statisch zugewiesen werden, da diese Ressourcen vergleichsweise knapp sein können. In dem gezeigten Beispiel umfasst PPU 200 nur zwei Dekodierer 1300, die auf acht PPU-Abschnitte 610 verteilt werden müssen. Dementsprechend weist Hypervisor 124 den in PPU-Abschnitt 600(0) enthaltenen PPU-Abschnitten 610(0) bis 610(3) dynamisch den Dekodierer 1300(0) zu. Hypervisor 124 weist außerdem Dekodierer 1300(1) dynamisch den PPU-Abschnitten 610(4) und 610(5) zu, die in PPU-Partition 600(4) enthalten sind, PPU-Abschnitt 610(6), der in PPU-Partition 600(6) enthalten ist, und PPU-Abschnitt 600(7), der in PPU-Partition 600(7) enthalten ist.
In der gezeigten Konfiguration ist der Dekodierer 1300(0) dynamisch zugewiesen, um Dekodiervorgänge für die PPU-Partition 600(0) in einer dedizierten Weise durchzuführen, aber der Dekodierer 1300(1) wird von den PPU-Partitionen 600(4), 600(6) und 600(7) gemeinsam genutzt. In verschiedenen Ausführungsbeispielen können ein oder mehrere Leistungsmonitore die Nutzung von Hardwareressourcen verwalten, die auf die beschriebene Weise gemeinsam genutzt werden, um die Ressourcennutzung über verschiedene PPU-Abschnitte 610 gleichmäßig zu verteilen. Hypervisor 124 führt die oben beschriebenen Techniken aus, um beliebige technisch geeignete Ressourcen der PPU 200 auf PPU-Partitionen 600 zu verteilen.
Wenn die Partitionierung durchgeführt wurde und die verschiedenen Ressourcen von PPU 200 statisch oder dynamisch den entsprechenden PPU-Abschnitten 610 zugewiesen sind, ist Hypervisor 124 bereit, VMs die Ausführung von Verarbeitungsaufgaben innerhalb dieser PPU-Abschnitte 600 zu ermöglichen. Auf diese Weise können VMs innerhalb einer bestimmten PPU-Partition 600 gleichzeitig mehrere Verarbeitungskontexte starten, und zwar isoliert von anderen Verarbeitungskontexten, die mit anderen PPU-Partitionen 600 assoziiert sind, wie oben erwähnt und unten in Verbindung mit 14A-14B ausführlicher beschrieben. PPU-Abschnitte 610, die nicht in Gebrauch sind, können in andere PPU-Partitionen 600 umpartitioniert werden, während andere PPU-Abschnitte in aktiven PPU-Partitionen 600 in Gebrauch sind.
14A zeigt, wie mehrere Gastbetriebssysteme 916, auf denen mehrere VMs laufen, gemäß verschiedenen Ausführungsbeispielen mehrere Verarbeitungskontexte gleichzeitig innerhalb einer oder mehrerer PPU-Partitionen starten. Wie gezeigt, umfasst Gastbetriebssystem 916 verschiedene Verarbeitungskontexte 1400, die verschiedenen PPU-Partitionen 600 zugeordnet sind. Die Verarbeitungskontexte 1400(0) und 1400(1) sind der PPU-Partition 600(0) zugeordnet und können entweder auf der SMC Engine 700(0) oder der SMC Engine 700(1) gestartet werden. In einigen Ausführungsbeispielen verbleibt ein Verarbeitungskontext, nachdem er einer SMC Engine 700 zugewiesen wurde, bis zur Fertigstellung auf der Engine 700. Der Verarbeitungskontext 1400(4) ist der PPU-Partition 600(4) zugeordnet und kann auf der Engine 700(4) des SMC gestartet werden. Die Verarbeitungskontexte 1400(6) und 1400(6) sind den PPU-Partitionen 600(6) bzw. 600(7) zugeordnet und können auf den SMC-Engines 700(6) bzw. 700(7) gestartet werden.
Wie bereits in Verbindung mit 7 erwähnt, kann jede SMC-Engine 700 Verarbeitungsaufgaben, die mit einem beliebigen Verarbeitungskontext 1400 assoziiert sind, isoliert von anderen SMC-Engines 700 ausführen, die Verarbeitungsaufgaben ausführen, die mit einem beliebigen Verarbeitungskontext 1400 assoziiert sind. Die Verarbeitungsaufgaben, die von einer bestimmten SMC Engine 700 in Verbindung mit einem bestimmten Verarbeitungskontext 1400 ausgeführt werden, werden unabhängig von anderen Verarbeitungsaufgaben geplant, die von anderen SMC Engines 700 in Verbindung mit beliebigen anderen Verarbeitungskontexten 1400 ausgeführt werden. Darüber hinaus können die SMC-Engines 700, wie weiter unten in Verbindung mit den 15-16 genauer beschrieben, unabhängig voneinander Fehler und/oder Störungen erfahren und zurückgesetzt werden, ohne den Betrieb der anderen SMC-Engines 700 zu stören.
Darüber hinaus kann jede SMC-Engine 700 so konfiguriert sein, dass sie Verarbeitungsaufgaben ausführt, die mit einem oder mehreren Verarbeitungssubkontexten 1410 assoziiert sind, die in einem einzigen übergeordneten Verarbeitungskontext 1400 enthalten sind und/oder von diesem abgeleitet wurden. Wie gezeigt, umfasst ein gegebener Verarbeitungskontext 1400(0) einen oder mehrere Verarbeitungssubkontexte 1410(0) und ein gegebener Verarbeitungskontext 1400(1) einen oder mehrere Verarbeitungssubkontexte 1410(1). Hypervisor 124 konfiguriert den Verarbeitungssubkontext 1410 und die entsprechenden Gerätetreiber. Verarbeitungssubkontexte 1410, die einem gegebenen übergeordneten Verarbeitungskontext 1400 zugeordnet sind, werden auf derselben SMC-Engine 700 gestartet, auf der auch der übergeordnete Verarbeitungskontext 1400 gestartet wird. Im gezeigten Beispiel werden also die Verarbeitungssubkontexte 1410(0) auf der SMC Engine 700(0) und die Verarbeitungssubkontexte 1410(1) auf der SMC Engine 700(1) gestartet. In einem Ausführungsbeispiel könnte jedes Gastbetriebssystem 916 in der Lage sein, eine entsprechende PPU-Partition 600 unabhängig vom Hypervisor 124 zu konfigurieren, ohne die Konfiguration der anderen PPU-Partitionen 600 zu stören.
In bestimmten Ausführungsbeispielen, in denen keine Virtualisierung verwendet wird, können Hypervisor 124 und Gastbetriebssysteme 916 fehlen und das Host-Betriebssystem 926 kann Verarbeitungskontexte 1400 und Verarbeitungssubkontexte 1410 konfigurieren und starten, wie weiter unten in Verbindung mit 14B ausführlicher beschrieben wird.
14B zeigt, wie ein Host-Betriebssystem mehrere Verarbeitungskontexte gleichzeitig innerhalb einer oder mehrerer PPU-Partitionen startet, gemäß verschiedenen Ausführungsbeispielen. Wie dargestellt, umfasst das Host-Betriebssystem 926 die Verarbeitungskontexte 1400 und die Verarbeitungssubkontexte 1410. In dem gezeigten Ausführungsbeispiel ist das Host-Betriebssystem 926 so konfiguriert, dass es Verarbeitungskontexte 1400 und Verarbeitungssubkontexte 1410 auf den SMC-Engines 700 ohne Beteiligung eines Hypervisors oder anderer Virtualisierungssoftware startet. Das gezeigte Ausführungsbeispiel kann in einem „Bare-Metal“-Szenario implementiert werden.
Allgemein auf die 14A-14B Bezug nehmend, werden Verarbeitungsaufgaben, die mit der Verarbeitungssubkontexten 1410 innerhalb desselben übergeordneten Verarbeitungskontextes 1400 assoziiert sind, im Allgemeinen nicht unabhängig voneinander geplant und teilen sich in der Regel die Ressourcen der entsprechenden SMC Engine 700. Ferner können Verarbeitungssubkontexte 1410, die innerhalb einer bestimmten SMC-Engine 700 gestartet werden, in einigen Situationen Fehler und/oder Irrtümer verursachen, die dazu führen, dass die SMC-Engine 700 alle relevanten Verarbeitungskontexte 1400 zurückgesetzt und/oder die Verarbeitungssubkontexte 1410 neu gestartet werden. Verarbeitungskontexte 1400 und/oder Verarbeitungssubkontexte 1410 werden einem lokalen virtuellen Adressraumidentifikator zugewiesen, der von einem globalen virtuellen Adressraumidentifikator 1510 abgeleitet ist, der mit der PPU 200 als Ganzes assoziiert ist, wie unten in Verbindung mit 15 näher beschrieben wird.
In einigen Ausführungsbeispielen gibt es keine Virtualisierung und daher auch keinen Hypervisor, aber es ist einem Fachmann klar, dass ein einziges Betriebssystem-Nutzungsmodell auf einer PPU 200 oder einem Satz von PPUs 200 alle Mechanismen nutzen kann, die als VMs zugehörig beschrieben werden. In einigen Ausführungsbeispielen entsprechen Container der Beschreibung von VMs, was bedeutet, dass Container auf einem einzigen Betriebssystem die Verarbeitungsisolation erreichen können, die den VMs in den Beschreibungen hierin gewährt wird. Beispiele für Container sind LXC (LinuX-Container) und Docker-Container, wie sie in der Computerindustrie bekannt sind. Beispielsweise kann jeder Docker-Container einer PPU Partition 600 entsprechen, so dass die vorliegende Erfindung eine Isolierung zwischen mehreren Docker-Containern unter einem Betriebssystem ermöglicht.
15 zeigt, wie der Hypervisor von 1 die Identifikatoren für virtuellen Adressraum den verschiedenen SMC-Engines zuordnet, gemäß verschiedenen Ausführungsbeispielen. Wie gezeigt, umfassen die virtuellen Adressraumidentifikatoren 1500 einen separaten Bereich von virtuellen Adressen für jede SMC-Engine 700. Jeder Bereich der virtuellen Adressen beginnt bei Null (0), um die Konsistenz über die Engines 700 der SMC-Engines hinweg zu gewährleisten, aber jeder Bereich der virtuellen Adressen entspricht einem anderen Teil der globalen virtuellen Adressraumidentifikatoren 1510. Zum Beispiel sind die der SMC-Engine 700(0) zugewiesenen Identifikatoren 0-15 für den virtuellen Adressraum den globalen Identifikatoren 0-15 für den virtuellen Adressraum zugeordnet, während die der SMC-Engine 700(1) zugewiesenen Identifikatoren 0-15 für den virtuellen Adressraum den globalen Identifikatoren 16-31 für den virtuellen Adressraum entsprechen. In einem Ausführungsbeispiel kann der globale Satz des virtuellen Adressraums 1510 ein virtueller Adressraum oder ein physischer Adressraum sein. In einigen Ausführungsbeispielen gibt es auch einen virtuellen Adressraumidentifkator pro PDU-Partition, damit das Gastbetriebssystem einer VM einen nullbasierten Satz von virtuellen Adressraumidentifikatoren für alle SMC-Engines 700 hat, die es besitzt.
Der Hypervisor 124 weist einer bestimmten SMC-Engine 700 einen bestimmten Bereich von virtuellen Adressraumidentifikatoren zu, abhängig von der Anzahl der PPU-Abschnitte 610, aus denen der SMC-Engine 700 Ressourcen zugewiesen werden. Im gezeigten Beispiel weist Hypervisor 124 der SMC-Engine 700(0) die virtuellen Adressraum-Identifikatoren 0-15, der SMC-Engine 700(1) die virtuellen Adressraum-Identifikatoren 0-15 und der SMC-Engine 700(4) die virtuellen Adressraum-Identifikatoren 0-15 zu. Hypervisor 124 weist den SMC-Engines 700(0), 700(1) und 700(4) 16 virtuellen Adressraumidentifikatoren zu, da diese SMC-Engines Ressourcen aus zwei PPU-Abschnitten 610 beziehen, wie in 7 dargestellt. Im Gegensatz dazu weist der Hypervisor 124 den SMC-Engines 700(6) und 700(7) die virtuellen Adressraum-Identifikatoren 0-7 zu, da die SMC-Engines 700 Ressourcen aus jeweils nur einem PPU-Abschnitt 610 beziehen, wie in 7 dargestellt. Hypervisor 124 kann die Identifikatoren des virtuellen Adressraums, die einer bestimmten SMC-Engine 700 zugewiesen sind, weiter unterteilen, um mehrere Verarbeitungskontexte 1400 zu unterstützen. Beispielsweise könnte Hypervisor 124 die virtuellen Adressraum-Identifikatoren 0-15, die der SMC-Engine 700(0) zugewiesen sind, in zwei Bereiche, 0-7 und 0-7, unterteilen, von denen jeder einem anderen Verarbeitungskontext 1400 zugewiesen werden könnte. Dieses Beispiel zeigt, wie die globalen virtuellen Adressraum-Identifikatoren 1510 proportional in Gruppen wie 0-15, 16-31, 32-47, 48-55 und 55-63 unterteilt sind. In einigen Ausführungsbeispielen sind die virtuellen Adressraumidentifikatoren eindeutig, so dass im obigen Beispiel die virtuellen Adressraumidentifikatoren 0-15, 16-31, 32-47, 48-55 und 55-63 und nicht 0-15, 0-15, 0-15, 0-15, 0-7 und 0-7 wie in 15 dargestellt, wären. In einigen Ausführungsbeispielen werden die globalen virtuellen Adressraum-Identifikatoren 1510 nicht proportional zur Anzahl der PPU-Abschnitte 610 zugewiesen, und es steht dem Hypervisor frei, jede beliebige Teilmenge der globalen virtuellen Adressraum-Identifikatoren 1510 den PPU-Partitionen 600 oder den SMC-Engines 700 zuzuweisen.
Der Hypervisor 124 weist virtuellen Adressraumidentifikatoren auf die beschriebene Weise zu, so dass verschiedene SMC-Engines 700 Verarbeitungsaufgaben, die mit einem beliebigen Verarbeitungskontext 1400 assoziiert sind, ausführen können, ohne dass virtuelle Adressen, die durch diese Verarbeitungsaufgaben spezifiziert wurden, neu zugeordnet werden müssen. Dementsprechend kann Hypervisor 124 Verarbeitungskontexte 1400 zwischen den SMC-Engines 700 dynamisch zwischen den SMC-Engines 700 migrieren, ohne dass diese Verarbeitungskontexte wesentlich verändert werden müssen. Während der Ausführung verschiedener Verarbeitungsaufgaben, die mit einem gegebenen Verarbeitungskontext 1400 assoziiert sind, kann es bei jeder beliebigen SMC-Engine 700 gelegentlich zu Fehlern kommen, und sie ist so konfiguriert, dass sie diese Fehler unter Verwendung der lokal zugewiesenen virtuellen Adressen meldet, wie weiter unten in Verbindung mit 16 ausführlicher beschrieben. Nach der Migration verwendet der migrierte Verarbeitungskontext immer noch die gleichen virtuellen Adressraum-Identifikatoren 1500, aber diese könnten anderen globalen virtuellen Adressraum-Identifikatoren 1510 entsprechen.
16 zeigt, wie eine Speicherverwaltungseinheit lokale virtuelle Adressraum-Identifikatoren 1500 in globale virtuelle Adressraum-Identifikatoren 1510 übersetzt, wenn sie Fehler behebt, gemäß verschiedenen Ausführungsbeispielen. Wie gezeigt, können die SMC-Engines 700 während der Ausführung Fehler und/oder Störungen aufweisen und unabhängig voneinander abstürzen, wie zuvor besprochen. Im gezeigten Beispiel tritt bei der SMC-Engine 700(1) ein Fehler auf, der die Ausgabe eines lokalen Fehler-Identifikators 1610 an eine Speicherverwaltungseinheit (MMU) 1600 verursacht. Ein Zugriff durch die Engine 700 auf eine nicht abgebildete (engl. unmapped) Seite kann dazu führen, dass die MMU einen Fehler erzeugt, der ebenfalls einen lokalen Fehler-Identifikator verursacht.
Die MMU 1600 enthält eine Zuordnung zwischen den lokalen virtuellen Adressraum-Identifikatoren 1500 und den globalen virtuellen Adressraum-Identifikatoren 1510. Basierend auf dieser Zuordnung erzeugt die MMU 1600 einen globalen Identifikator 1620 und überträgt den globalen Identifikator 1620 an das Gastbetriebssystem OS 916(0). In Reaktion auf den Empfang des globalen Fehleridentifikators 1620 kann Gastbetriebssystem 916(0) die SMC-Engine 700(1) zurücksetzen, ohne den Betrieb beliebiger anderer SMC-Engines 700 zu unterbrechen, und dann den Verarbeitungskontext 1400(1) neu starten. Bei diesem Ansatz arbeitet jede SMC-Engine 700 mit verschiedenen Sätzen von Virtuellen Adressraumidentifikatoren, die bei Null beginnen und potenziell ähnliche Bereiche umfassen, aber unterschiedlichen Bereichen des globalen Speichers entsprechen. Dementsprechend kann der globale virtuelle Adressraum-Identifikator 1510 auf die SMC-Engines 700 aufgeteilt werden, wobei das Erscheinungsbild eines dedizierten Adressraums erhalten bleibt. In einigen Ausführungsbeispielen können die Fehler-Identifikatoren 1620 für die gesamte PPU-Partition 600 nullbasiert sein. In anderen Ausführungsbeispielen kann der Fehler-Identifikator 1620 ein Identifikator für die Engine 700 der SMC-Engine und den virtuellen Adressraum-Identifikator 1500 sein.
In einem Ausführungsbeispiel können die globalen Fehler-Identifikatoren 1620 an Hypervisor 124 gemeldet werden, und Hypervisor 124 kann verschiedene Operationen durchführen, um die assoziierten Fehler zu beheben. In einem anderen Ausführungsbeispiel können einige Fehlerarten an das assoziierte Gast-OS 916 und andere Fehlerarten, wie z. B. harte Fehler, die in der oberen Sektion 810 oder der unteren Sektion 830 von DRAM 272 auftreten, an Hypervisor 124 gemeldet werden. In Reaktion auf solche Fehler kann Hypervisor 124 einige oder alle SMC-Engines 700 zurücksetzen. In verschiedenen anderen Ausführungsbeispielen kann ein bestimmter globaler Fehler-Identifikator 1620 virtualisiert sein und daher nicht direkt einem echten globalen Identifikator entsprechen. Im Betrieb kann die MMU 1600 auf der Grundlage der mit diesen VMs assoziierten GFIDs Fehler an die entsprechenden VMs weiterleiten. GFIDs werden oben in Verbindung mit 7 diskutiert.
Unter allgemeiner Bezugnahme auf die 15-16 kann Hypervisor 124 analoge Techniken wie die oben beschriebenen implementieren, um Identifikatoren den verschiedenen Hardwareressourcen zuzuweisen, die mit jeder PPU Partition 600 und/oder jeder SMC-Engine 700 assoziiert sind. Beispielsweise könnte Hypervisor 124 jedem GPC 242, der in einer bestimmten PPU-Partition 600 enthalten ist, einen lokalen GPC-Identifikator (GPC-ID) aus einem Bereich von lokalen GPC-IDs zuweisen, der mit Null (0) beginnt. Jede lokale GPC-ID würde einer anderen globalen GPC-ID entsprechen. Dieser Ansatz kann mit jeder beliebigen PPU-Ressource implementiert werden, um einen Satz von Identifikatoren zu erhalten, der innerhalb einer gegebenen PPU-Partition 600 und/oder der Engine 700 intern konsistent ist. Wie bereits erwähnt, erleichtert dieser Ansatz die Migration von Verarbeitungskontexten 1400 zwischen den SMC-Engines 700 und ermöglicht ferner die Migration von Verarbeitungskontexten 1400 zwischen verschiedenen PPUs 200.
Wenn der Hypervisor 124 einen Verarbeitungskontext 1400 zwischen verschiedenen SMC-Engines 700, die auf verschiedenen PPUs 200 residieren, migriert, führt der Hypervisor 124 eine hierin als „Soft Floorsweeping“ bezeichnete Technik durch, um eine Ziel-PPU 200 mit ähnlichen Hardwareressourcen wie die Quell-PPU 200 zu konfigurieren, wie unten in Verbindung mit 17 näher beschrieben wird.
17 zeigt, wie der Hypervisor von 1 das Soft Floorsweeping bei der Migration eines Verarbeitungskontextes zwischen SMC-Engines auf verschiedenen PPUs umsetzt, gemäß verschiedenen Ausführungsbeispielen. Wie gezeigt, umfasst eine Rechenumgebung 1700(0) eine Instanz des Hypervisors 124(0) und eine PPU-Partition 600(0). PPU-Partition 600(0) ist mit der SMC-Engine 700(0) konfiguriert. Die SMC-Engine 700(0) führt Verarbeitungsaufgaben aus, die einem Verarbeitungskontext 1710 zugeordnet sind. Der SMC-Engine 700(0) werden die Ressourcen 1720(0) und 1720(1) zugewiesen, aber die Ressource 1720(1) ist nicht funktional. Daher wird die Ressource 1720(1) während der Herstellung abgetrennt (engl. floorswept). Bei der Ressource 1720 kann es sich um eine beliebige der bisher beschriebenen Rechen-, Grafik- oder Speicherressourcen handeln. Beispielsweise könnte eine bestimmte Ressource 1720 unter anderem eine GPC 242, eine TPC 330 innerhalb einer GPC 242, die SM 332 innerhalb einer TPC 330, eine GFX FE 542 oder ein L2-Cache-Abschnitt 800 sein.
Unter verschiedenen Umständen kann der Hypervisor 124(0) bestimmen, dass der Verarbeitungskontext 1710 aus der Rechenumgebung 1700(0) in die Rechenumgebung 1700(1) migriert werden sollte. Beispielsweise könnte die Rechenumgebung 1700(0) für eine geplante Stillstandszeit eingeplant werden, und um einen kontinuierlichen Betrieb aufrechtzuerhalten, bestimmt Hypervisor 124(0), dass der Verarbeitungskontext 1710 zumindest vorübergehend in eine andere Rechenumgebung migriert werden sollte, während die Rechenumgebung 1700(0) nicht verfügbar ist.
In solchen Situationen interagiert der Hypervisor 124(0) mit einem entsprechenden Hypervisor 124(1), der in der Rechenumgebung 1700(1) ausgeführt wird, um eine PPU-Partition 600(1) so zu konfigurieren, dass sie dieselben oder ähnliche Ressourcen wie die PPU-Partition 600(0) aufweist. Wie gezeigt, umfasst die PPU-Partition 600(1) die Ressourcen 1720(2) und 1720(3), aber 1720(3) wird nicht verfügbar gemacht, um die Menge an Ressourcen zu imitieren, die von der PPU-Partition 600(0) zur Verfügung gestellt wird. Daher kann der Verarbeitungskontext 1710 von der SMC-Engine 700(0) innerhalb der PPU-Partition 600(0) auf die SMC-Engine 700(1) innerhalb der PPU-Partition 600(1) migriert werden, ohne dass sich die Dienstqualität merklich ändert. Dieser Ansatz trägt dazu bei, dass Erscheinungsbild beizubehalten, dass jede beliebige PPU-Partition 600 in gleicher Weise wie PPU 200 funktioniert, indem der Zugriff auf einen konsistenten Satz von Ressourcen ermöglicht wird und gleichzeitig Verarbeitungskontexte über verschiedene Hardware hinweg migriert werden können. Hypervisor 124 kann den obigen Ansatz auch für die Migration der SMC-Engines 700 zwischen Partitionen 600 innerhalb derselben PPU 200 umsetzen. In einem Ausführungsbeispiel können die Hypervisoren 124(0) und 124(1) als eine einheitliche Softwareeinheit ausgeführt werden, die den Betrieb mehrerer PPUs 200 in verschiedenen Rechenumgebungen 1700 verwaltet.
Unter allgemeiner Bezugnahme auf die 11-17 implementiert Hypervisor 124 die oben genannten Techniken, um PPU-Ressourcen so aufzuteilen, dass die simultane Ausführung von Verarbeitungsaufgaben, die mit mehreren Verarbeitungskontexten assoziiert sind, unterstützt wird. Diese Techniken werden nachstehend in Verbindung mit 18 detaillierter beschrieben.
18 zeigt ein Flussdiagramm mit Verfahrensschritten zur Konfiguration von Rechenressourcen innerhalb einer PPU, um Operationen, die mit mehreren Verarbeitungskontexten assoziiert sind, gleichzeitig zu unterstützen, gemäß verschiedenen Ausführungsbeispielen. Obwohl die Verfahrensschritte in Verbindung mit den Systemen der 1-17 beschrieben werden, werden Fachleute verstehen, dass jedes System, das so konfiguriert sein kann, dass es die Verfahrensschritte in beliebiger Reihenfolge ausführt, unter den Umfang der vorliegenden Ausführungsbeispiele fällt.
Wie gezeigt, beginnt ein Verfahren 1800 mit Schritt 1802, bei dem Hypervisor 124 der 1 die PPU 200 auswertet, um einen Satz verfügbarer Hardwareressourcen zu bestimmen. Bestimmte Hardwareressourcen werden bei der Herstellung einer bestimmten PPU 200 manchmal nicht korrekt hergestellt und können nicht funktionsfähig sein. In der Praxis werden diese nicht-funktionalen Hardwareressourcen abgeschmolzen und nicht verwendet. Andere Hardwareressourcen innerhalb der gegebenen PPU 200 sind jedoch funktionsfähig, so dass die PPU 200 als Ganzes weiterhin funktionieren kann, wenn auch mit geringerer Leistung. Ein Verwerten von teilweise funktionsfähigen PPUs und anderen Arten von Einheiten auf die beschriebene Weise ist in dem Fachbereich als „Floorsweeping“ bekannt.
In Schritt 1804 bestimmt Hypervisor 124 einen Satz verfügbarer swizlDs basierend auf den in Schritt 1802 ermittelten verfügbaren Hardwareressourcen. Wie oben in Verbindung mit 11 beschrieben, definiert eine bestimmte swizID einen Satz von Hardware-Grenzen, die aktiviert und deaktiviert werden können, um verschiedene Gruppen von PPU-Abschnitten 610 innerhalb von PPU 200 zu isolieren und PPU-Partitionen 600 zu bilden. In Situationen, in denen bestimmte Hardwareressourcen nicht verfügbar sind, bestimmt Hypervisor 124, dass einige swizlDs nicht durchführbaren Partitionskonfigurationen entsprechen und nicht verfügbar gemacht werden sollen.
In Schritt 1806 erzeugt Hypervisor 124 einen Satz von swizlDs basierend auf Partitionierungseingaben. Beispielsweise könnte Hypervisor 124 eine Eingabe vom Admin-Benutzer erhalten, die einen Satz von Partitionierungsoptionen angibt, und diese Partitionierungsoptionen dann einem entsprechenden Satz von swizlDs zuordnen, der aus dem in Schritt 1804 ermittelten Satz verfügbarer swizlDs abgeleitet wird. Alternativ könnte Hypervisor 124 den Satz von swizlDs direkt vom Admin-Benutzer erhalten und dann jeden dieser swizlDs, die nicht im Satz der verfügbaren swizlDs enthalten sind, modifizieren.
In Schritt 1808 konfiguriert Hypervisor 124 einen Satz von Grenzen zwischen Hardwareressourcen basierend auf dem Satz von swizlDs, die in Schritt 1806 erzeugt wurden. Dabei berechnet Hypervisor 124 eine logische ODER-Verknüpfung über den Satz von swizlDs, um eine Konfigurations-SwizID (oder „lokale“ swizID) zu erzeugen, die angibt, welche Begrenzungsoptionen als Grenzen aktiviert und welche Begrenzungsoptionen deaktiviert werden sollen. Ein beispielhafter Satz von Partitionierungsoptionen und entsprechenden Begrenzungsoptionen wird oben in Verbindung mit 12 beschrieben.
In Schritt 1810 startet ein Gastbetriebssystem 916 einen Satz von Verarbeitungskontexten innerhalb einer PPU-Partition 600, die einem Gastbenutzer zumindest teilweise basierend auf einer oder mehreren swizlDs zugewiesen wird. Hypervisor 124 weist der PPU-Partition 600 einen Satz virtueller Adressraum-Identifikatoren 1500 zu, der einem Bereich der globalen virtuellen Adressraum-Identifikatoren 1510 der 15 entspricht. Hypervisor 124 oder eine SMC-Engine 700 innerhalb dieser PPU-Partition 600 kann den Satz der virtuellen Adressraum-Identifikatoren 1500 in verschiedene Bereiche unterteilen, die wiederum verschiedenen Verarbeitungskontexten zugeordnet sind. Dieser Ansatz ermöglicht es jedem Verarbeitungskontext, mit einem konsistenten Satz virtueller Adressräume über alle SMC-Engines 700 hinweg zu arbeiten, wodurch Verarbeitungskontexte leichter migriert werden können.
In Schritt 1812 setzt der Hypervisor 124 oder das entsprechende Gastbetriebssystem 916 in Reaktion auf einen oder mehrere Fehler einen Teilsatz der in Schritt 1810 gestarteten Verarbeitungskontexte zurück. Die Fehler könnten u.a. auf der Ebene der Ausführungseinheit, auf der Ebene der SMC-Engine oder auf VM-Ebene auftreten. Wichtig ist, dass Fehler, die während der Ausführung von Verarbeitungsaufgaben erzeugt werden, die mit einem Verarbeitungskontext assoziiert sind, im Allgemeinen nicht die Ausführung von Verarbeitungsaufgaben beeinflussen, die mit anderen Verarbeitungskontexten assoziiert sind. Diese Fehlerisolierung zwischen Verarbeitungskontexten behandelt insbesondere Probleme, die in Ansätzen nach dem Stand der Technik auftreten, die sich auf Verarbeitungssubkontexte stützen. Optional kann zwischen den Schritten 1810 und 1812 ein Debugger aufgerufen werden, um die SMC-Engine 700 zu steuern, bei der ein Fehler aufgetreten ist.
In Schritt 1814 konfiguriert Hypervisor 124 ein Migrationsziel basierend auf den verfügbaren Hardwareressourcen, die mit der PPU 200 assoziiert sind. Das Migrationsziel kann eine weitere PPU 200 sein, aber in einigen Situationen ist das Migrationsziel 200 eine weitere SMC 700 innerhalb einer bestimmten PPU-Partition 600 oder eine weitere PPU-Partition 600 innerhalb der PPU 200. Bei der Konfiguration des Migrationsziels kann Hypervisor 124 eine hierin als „Soft Floorsweeping“ bezeichnete Technik ausführen, um zu bewirken, dass das Migrationsziel ähnliche Hardwareressourcen bereitstellt, wie sie von dem Satz von Verarbeitungskontexten verwendet werden.
In Schritt 1816 migriert Hypervisor 124 den Satz von Verarbeitungskontexten zum Migrationsziel. Die mit diesen Verarbeitungskontexten assoziierten Verarbeitungsaufgaben können mit wenig oder keiner Unterbrechung und mit entsprechenden verfügbaren Hardwareressourcen fortgesetzt werden. Dementsprechend ermöglichen diese Techniken die Bereitstellung einer ausgeglichenen Dienstqualität unter Umständen, in denen Verarbeitungskontexte über verschiedene PPU-Partitionen 600 oder verschiedene PPUs 200 verschoben werden müssen.
Unter allgemeiner Bezugnahme auf die 11-18 führt Hypervisor 124, Gastbetriebssysteme 916 und/oder Host-Betriebssystem 926 die offenbarten Techniken aus, um die Rechenressourcen, die mit PPU 200 assoziiert sind, in isolierte und unabhängige PPU-Partitionen 600 aufzuteilen, innerhalb derer verschiedene Verarbeitungskontexte gleichzeitig aktiv sein können. Dementsprechend können die Ressourcen der PPU 200 im Vergleich zu herkömmlichen Ansätzen, die jeweils nur einen Verarbeitungskontext unterstützen, der die PPU möglicherweise nicht vollständig ausnutzt, effizienter genutzt werden. Die verschiedenen PPU-Partitionen 600 können auch von mehreren verschiedenen Mandanten unabhängig voneinander aufgerufen und konfiguriert werden. Auf diese Weise bieten die offenbaren Techniken eine robuste Unterstützung für Mehrmandantenfähigkeit und können daher die Nachfrage der Verbraucher nach einer effizienten, Cloud-basierten Parallelverarbeitungsplattform erfüllen.
Aufteilen von Speicherressourcen zur Unterstützung simultaner Mehrfachkontexte
Zusätzlich zur Partitionierung der mit PPU 200 assoziierten Rechenressourcen zur Unterstützung mehrerer simultaner Verarbeitungskontexte, partitioniert Hypervisor 124 auch die mit PPU 200 assoziierten Speicherressourcen, um mehrere Kontexte gleichzeitig zu unterstützen und somit eine robuste Unterstützung für Mehrmandantenfähigkeit zu bieten. Hypervisor 124 implementiert verschiedene Techniken beim Partitionieren von mit PPU 200 assoziierten Speicherressourcen, die im Folgenden in Verbindung mit den 19-24 näher beschrieben werden.
19 zeigt einen Satz von Begrenzungsoptionen, nach denen der Hypervisor von 1 eine oder mehrere PPU-Speicherpartitionen erzeugen kann, gemäß verschiedenen Ausführungsbeispielen. Wie dargestellt, umfasst DRAM 272 einen Satz Begrenzungsoptionen 1900, die während des Partitionierens aktiviert werden können, um den L2-Cache in verschiedene Sektionen und Partitionen zu unterteilen.
Insbesondere unterteilen die Begrenzungsoptionen 1900(0), 1900(1), 1900(9) und 1900(10) den DRAM 272 in die obere Sektion 810, die partitionierbare Sektion 820 und die untere Sektion 830 der 8A. Begrenzungsoption 1900(0) bildet die untere Begrenzung der unteren Sektion 830, und Begrenzungsoption 1900(1) bildet die obere Begrenzung der unteren Sektion 830. Begrenzungsoption 1900(1) bildet auch die untere Begrenzung der partitionierbaren Sektion 820 sowie die linke Begrenzung der partitionierbaren Sektion 820. Begrenzungsoption 1900(9) bildet die rechte Begrenzung der partitionierbaren Sektion 820 sowie die obere Begrenzung der partitionierbaren Sektion 820. Begrenzungsoption 1900(9) bildet auch die untere Begrenzung der oberen Sektion 810, und Begrenzungsoption 1900(10) bildet die obere Begrenzung der oberen Sektion 810. Begrenzungsoptionen 1900(1) bis 1900(8) unterteilen die partitionierbare Sektion 820 weiter in verschiedene Speicherpartitionen, die unten in Verbindung mit 20 detaillierter beschrieben werden.
Wie ebenfalls gezeigt, hat DRAM 272 eine Gesamtgröße M, die obere Sektion 810 eine Gesamtgröße T, die partitionierbare Sektion 820 eine Gesamtgröße P und die untere Sektion 830 eine Gesamtgröße B. F und W sind konfigurierbare Parameter, die über Hypervisor 124 eingestellt werden können und die in einigen Ausführungsbeispielen die Werte von T, P und B relativ zu M vollständig einschränken können.
Während der Konfiguration konfiguriert Hypervisor 124 DRAM 272 auf der Grundlage von M, F und W in die obere Sektion 810, die partitionierbare Sektion 820 und die untere Sektion 830. Dabei bestimmt Hypervisor 124 Werte für T, P und B auf der Grundlage der Werte von M, F und W. Hypervisor 124 aktiviert außerdem bestimmte Begrenzungsoptionen 1900 auf der Grundlage der durch Interaktionen mit dem Admin-Benutzer erzeugten Konfigurations-swizID, wie oben in Verbindung mit 11-12 beschrieben. Eine beispielhafte Aktivierung der Begrenzungsoptionen 1900 wird nachstehend in Verbindung mit 20 beschrieben.
20 zeigt in einem Beispiel, wie der Hypervisor von 1 den PPU-Speicher partitioniert, um eine oder mehrere PPU-Speicherpartitionen zu erzeugen, gemäß verschiedenen Ausführungsbeispielen. Wie gezeigt, werden die Begrenzungsoptionen 1900(0), 1900(1), 1900(9) und 1900(10) aktiviert, wodurch die obere Sektion 810, die partitionierbare Sektion 820 und die untere Sektion 830 von DRAM 272 gebildet werden. Die Begrenzungsoptionen 1900(1), 1900(5), 1900(7) und 1900(8) werden ebenfalls aktiviert, wodurch die PPU-Speicherpartitionen 710(0), 710(4), 710(6) und 710(7) gebildet werden, die den DRAM-Bereichen 822(0), 822(4), 822(6) bzw. 822(7) innerhalb der partitionierbaren Sektion 820 entsprechen. Die Begrenzungsoptionen 1900(2), 1900(3), 1900(4) und 1900(6) sind nicht aktiviert und wurden daher weggelassen. Hypervisor 124 konfiguriert DRAM 272 auf die gezeigte Weise basierend auf einer Konfigurations-swizID, die gleich „11110100011“ ist.
Die Begrenzungsoptionen 1900, die mit DRAM 272 assoziiert sind, entsprechen logisch den Begrenzungsoptionen 1110, die in 11-12 dargestellt sind. Wie oben in Verbindung mit 11-12 erläutert, zeigt jedes Bit einer gegebenen Konfiguration swizlD an, ob eine entsprechende Begrenzungsoption 1110 aktiviert oder deaktiviert werden soll, um PPU-Abschnitte 610 zu gruppieren. Ebenso zeigt, wie hier in 20 dargestellt, jedes Bit der beispielhaften Konfigurations-SwizID „11110100011“ an, ob eine entsprechende Begrenzungsoption 1900, die mit DRAM 272 assoziiert ist, aktiviert oder deaktiviert werden soll.
Die Bits 0 und 10 der beispielhaften swizID sind standardmäßig auf eins gesetzt, um die Begrenzungsoptionen 1900(0) und 1900(10) zu aktivieren. Die Bits 1 und 9 der beispielhaften swizID werden auf eins gesetzt, um die Begrenzungsoptionen 1900(1) und 1900(9) zu aktivieren und die partitionierbare Sektion 820 zu erstellen. Die Bits 5, 7 und 8 der beispielhaften swizID werden auf eins gesetzt, um die Begrenzungsoptionen 1900(5), 1900(7) und 1900(8) zu aktivieren und die partitionierbare Sektion 820 in DRAM-Bereiche 822 zu unterteilen, die mit PPU-Speicherpartitionen 710 assoziiert sind. Die anderen Bits der swizID werden auf Null gesetzt, um die entsprechenden Begrenzungsoptionen zu deaktivieren. Die hier gezeigte Partitionierung von DRAM 272 entspricht der in 12 gezeigten beispielhaften Konfiguration von PPU-Abschnitten 610. Nach dieser Partitionierung über Hypervisor 124 können die SMC-Engines 700, die innerhalb der PPU-Partitionen 600 ausgeführt werden, Speicherzugriffsoperationen über L2-Cache-Abschnitte 800 in der nachstehend in Verbindung mit den 21-23 beschriebenen Weise durchführen.
21 zeigt, wie die Speicherverwaltungseinheit von 16 den Zugriff auf verschiedene PPU-Speicherpartitionen ermöglicht, gemäß verschiedenen Ausführungsbeispielen. Wie dargestellt, ist die MMU 1600 in 16 zwischen DRAM 272 und 1D SPA-Bereich 850 gekoppelt. Der 1D-SPA-Bereich 850 ist in obere Adressen 852, die der oberen Sektion 810 entsprechen, partitionierbare Adressen 854, die der partitionierbaren Sektion 820 entsprechen, und untere Adressen 856, die der unteren Sektion 830 entsprechen, unterteilt, wie ebenfalls in 8B dargestellt. Während des Partitionierens erzeugt Hypervisor 124 basierend auf der Konfiguration von DRAM 272 den 1D-SPA-Bereich 850.
Die MMU 1600 umfasst eine Adresszuordnungseinheit (engl. Address Mapping Unit , AMAP) 2110, die so konfiguriert ist, dass sie die oberen Adressen 852, die partitionierbaren Adressen 854 und die unteren Adressen 858 in Rohadressen abbildet, die jeweils der oberen Sektion 810, der partitionierbaren Sektion 820 und der unteren Sektion 830 zugeordnet sind. Auf diese Weise bedient die MMU 1600 Speicherzugriffsanforderungen, die vom Hypervisor 124 empfangen werden und auf die obere Sektion 810 und/oder die untere Sektion 830 abzielen, sowie Speicherzugriffsanforderungen, die von den SMC-Engines 700 empfangen werden und auf die partitionierbare Sektion 820 abzielen, wie unten in Verbindung mit 22 ausführlicher beschrieben.
22 zeigt, wie die Speicherverwaltungseinheit von 16 verschiedene Adress-Übersetzungen durchführt, gemäß verschiedenen Ausführungsbeispielen. Wie gezeigt, umfassen partitionierbare Adressen 854 den Adressbereich 856(0), der Adressen entsprechend der PPU-Speicherpartition 710(0) umfasst, wie oben in Verbindung mit 8B besprochen. Die MMU 1600 übersetzt physikalische Adressen, die den Adressbereich 856(0) umfassen, über AMAP 2110 in Rohadressen, die dem DRAM-Bereich 822(0) zugeordnet sind. AMAP 2110 ist so konfiguriert, dass Adressen aus dem Adressbereich 856(0) über L2-Cache-Abschnitte 800(0), die in PPU-Abschnitt 710(0) des Speichers enthalten sind, hinweg zugeordnet (engl. swizzle) werden, um Situationen zu vermeiden, in denen durch Schrittfolgen (engl. striding) wiederholt auf denselben L2-Cache-Abschnitt 800(0) zugegriffen wird (auch als „Camping“ bekannt).
In einem Ausführungsbeispiel kann AMAP 2110 eine „Speicherzugriffs“- swizID implementieren, die einen Speicher-Überlappungs-Faktor für einen bestimmten Bereich des Speichers identifiziert. Eine bestimmte Speicherzugriffs- swizID bestimmt einen Satz von L2-Cache-Abschnitten, die für verschiedene Arten von Speicherzugriffen, einschließlich Videospeicher, Systemspeicher und Peer-Speicherzugriff, überlappend (oder verschachtelt, engl. interleaved across) angeordnet sind. Unterschiedliche PPU-Partitionen 600 implementieren im Allgemeinen unterschiedliche und nicht überlappende Speicherbereiche 822 innerhalb der partitionierbaren Sektion 829, um Interferenzen zwischen gleichzeitig ausgeführten Aufträgen zu minimieren. Hypervisor 124 kann eine Speicherzugriffs- swizID von Null verwenden, um Speicherzugriffsoperationen über L2-Cache-Abschnitte auszugleichen, die im Allgemeinen entweder auf die obere Sektion 810 oder die untere Sektion 830 zugreifen würden.
Bei einer bestimmten Speicherzugriffs- swizID kann es sich um eine „lokale“ swizID handeln, die auf der Grundlage einer physikalischen Systemadresse berechnet wird und dazu dient, Speicherzugriffsanforderungen über relevante L2-Abschnitte und entsprechende Bereiche des DRAMs zu verschachteln oder zuzuordnen (engl. swizzle). Eine bestimmte lokale swizID, die mit einer bestimmten PPU-Partition 600 assoziiert ist, kann einer swizID entsprechen, die zur Konfiguration dieser PPU-Partition verwendet wird. Mit diesem Ansatz kann AMAP 2110 Adressen innerhalb der Grenzen einer bestimmten PPU-Speicherpartition zuordnen basierend auf der swizID, die zur Aktivierung dieser Grenzen verwendet wurde. Das Zuordnen (engl. Swizzling) von Adressen basierend auf Speicherzugriffs-SwizlDs ermöglicht es der MMU 1600, den DRAM 272 so zu verschachteln, dass jede PPU-Partition 600 ihren Teil der partitionierbaren Sektion 820 im linearen physikalischen Systemadressraum 850 als zusammenhängend ansieht. Auf diese Weise kann die Isolierung zwischen PPU-Partitionen 600 und die mit diesen PPU-Partitionen 600 assoziierte Datenintegrität aufrechterhalten werden.
Eine gegebene Speicherzugriffs- swizID kann alternativ eine „entfernte“ swizID sein, die von Gerätetreiber 122 oder Hypervisor 124 geliefert wird und dazu verwendet wird, Speicherzugriffsanforderungen über L2-Abschnitte für Systemspeicherzugriffsoperationen zu verschachteln. Die lokale swizlD und die „remote“ swizID können für Verarbeitungsoperationen, die innerhalb einer bestimmten PPU Partition 600 stattfinden, identisch sein. Unterschiedliche PPU-Partitionen 600 haben im Allgemeinen unterschiedliche Remote-SwizlDs, damit Systemspeicherzugriffsoperationen nur über L2-Abschnitte 800 laufen, die zur PPU-Partition 600 gehören.
Die MMU 1600 bietet auch Unterstützung für die Übersetzung virtueller Adressen, die mit einem Identifikator 1500 für den virtuellen Adressraum assoziiert sind, in eine physikalische Systemadresse im physikalischen Adressraum 850 des 1D-Systems. Die SMC-Engine 700(0) in 7 kann beispielsweise unter Verwendung der PPU-Speicherpartition 710(0) und des entsprechenden DRAM-Bereichs 822(0) ausgeführt werden und dabei einen Speicherfehler verursachen. Die MMU 1600 kann einen Fehler ausgeben, mit einem lokalen Fehler-Identifikator 1610. MMU 1600 wiederum kann den lokalen Fehler-Identifikator 1610 in einen globalen Fehler-Identifikator 1620 übersetzen. Fehler und Störungen können gemäß der öffentlichen SR-IOV-Beschreibung an virtuelle Funktionen gemeldet werden.
Die MMU 1600 ermöglicht auch ein Unterteilen der Adressbereiche 856 und der PPU-Speicherpartitionen 710, um Unterstützung für mehrere SMC-Engines 700, mehrere VMs und/oder mehrere Verarbeitungskontexte 1400 zu bieten, die innerhalb einer bestimmten PPU-Partition 600 ausgeführt werden, wie unten in Verbindung mit 23 ausführlicher beschrieben.
23 zeigt, wie die Speicherverwaltungseinheit von 16 Operationen unterstützt, die simultan mit mehreren Verarbeitungskontexten assoziiert sind, gemäß verschiedenen Ausführungsbeispielen. Wie gezeigt, umfasst der Adressbereich 856(0) mehrere virtuelle Speicherseiten 2310 unterschiedlicher Größe. Für die SMC-Engine 700(0) wird ein Identifikator 1500 für den virtuellen Speicherraum auf einen Identifikator 1510 für den globalen virtuellen Speicherraum abgebildet, der die Seitentabelle für einen bestimmten virtuellen Adressraum auswählt, der von einem Verarbeitungskontext auf der SMC-Engine 700(0) verwendet wird. Seiten, die durch eine Seitentabelle A spezifiziert sind, wählen Seiten 2310(A) innerhalb des DRAM-Bereichs 822(0) aus. Simultan kann die SMC-Engine 700(2) Seiten verwenden, die durch eine Seitentabelle B spezifiziert sind, die Seiten 2310(B) auch innerhalb des DRAM-Bereichs 822(0) auswählt. Durch ein seitenbasiertes virtuelles Speicherverwaltungsschema können Seiten innerhalb des DRAM-Bereichs 822(0) verschiedenen Subkontexten oder verschiedenen Verarbeitungssubkontexten zugewiesen werden. Dabei ist zu beachten, dass ein Verarbeitungssubkontext mehrere virtuelle Adressraum-Identifikatoren 1500 verwenden kann, da er viele Subkontexte ausführen kann.
Durch das gezeigte Unterteilen des Adressbereichs 856(0) und des DRAM-Bereichs 822(0), die den PPU-Speicherpartitionen 710(0) entsprechen, erhalten die verschiedenen SMC-Engines 700, die innerhalb einer entsprechenden PPU-Partition 600 ausgeführt werden, dedizierte Speicherressourcen innerhalb der PPU-Speicherpartition 822(0). Dementsprechend können mehrere SMC-Engines 700 in verschiedenen PPU 600-Partitionen Verarbeitungsaufgaben innerhalb verschiedener Verarbeitungskontexte simultan ausführen, ohne sich gegenseitig in Bezug auf die Bandbreite zu stören.
Der oben beschriebene seitenbasierte Ansatz kann auch auf eine einzelne SMC-Engine 700 angewendet werden, die mehrere Verarbeitungssubkontexte ausführt, wobei jeder Verarbeitungssubkontext einen dedizierten Bereich der PPU-Speicherpartition 710(0) benötigt. Ebenso kann der oben beschriebene Ansatz auf verschiedene VMs angewendet werden, die auf einer oder mehreren SMC-Engines 700 ausgeführt werden und dedizierte Bereiche der PPU-Speicherpartition 710(0) benötigen.
Unter allgemeiner Bezugnahme auf die 19-23 erlauben die offenbarten Techniken, dass eine bestimmte PPU Partition 600, die in der oben beschriebenen Weise in Verbindung mit den 11-12 konfiguriert ist, mehrere Verarbeitungskontexte sicher simultan starten kann. Insbesondere durch ein Partitionieren des L2-Caches, wie beschrieben, werden die DRAM-Bereiche 822 fair auf verschiedene PPU-Partitionen 600 verteilt. Darüber hinaus nutzen die verschiedenen über MMU 1600 und AMAP 2110 implementierten Adressübersetzungen die Speicherbandbreite effizient und gleichmäßig, wodurch allen Mandanten der PPU 200 eine einheitliche Dienstqualität geboten wird. Die in Verbindung mit den 19-23 beschriebenen Techniken werden im Folgenden in Verbindung mit 24 detaillierter beschrieben.
24 zeigt ein Flussdiagramm mit Verfahrensschritten zum Konfigurieren von Speicherressourcen innerhalb einer PPU, um Operationen, die mit mehreren Verarbeitungskontexten gleichzeitig assoziiert sind, zu unterstützen, gemäß verschiedenen Ausführungsbeispielen. Obwohl die Verfahrensschritte in Verbindung mit den Systemen der 1-23 beschrieben werden, werden Fachleute verstehen, dass jedes System, das so konfiguriert sein kann, dass es die Verfahrensschritte in beliebiger Reihenfolge ausführt, unter den Umfang der vorliegenden Ausführungsbeispiele fällt.
Wie gezeigt, beginnt ein Verfahren 2400 mit Schritt 2402, in dem Hypervisor 124 der 1 einen Satz von Speicherkonfigurationsparametern bestimmt, mit denen DRAM 272 partitioniert werden soll. Der Satz von Speicherkonfigurationsparametern kann einen beliebigen technisch geeigneten Satz von Parametern umfassen, die ein beliebiges Attribut von DRAM 272 beschreiben, einschließlich der Gesamtgröße von DRAM 272 (M), der Größe T der oberen Sektion 810, der Größe P der partitionierbaren Sektion 820, der Größe B der unteren Sektion 830, der Anzahl der L2-Cache-Abschnitte 800 (z. B. 96), der Größe jedes Cache-Abschnitts-Bereichs F, der der partitionierbaren Sektion 820 entspricht, und/oder der Größe jedes Cache-Abschnitts-Bereichs W, der der unteren Sektion 830 entspricht. In einem Ausführungsbeispiel braucht der Satz von Konfigurationsparametern nur die Parameter M, F und W zu umfassen.
In Schritt 2404 aktiviert Hypervisor 124 einen ersten Satz Begrenzungsoptionen basierend auf dem in Schritt 2402 festgelegten Satz von Speicherkonfigurationsparametern, um DRAM 272 in Sektionen zu unterteilen. Insbesondere aktiviert Hypervisor 124 die in 19 dargestellten Begrenzungsoptionen 1900(0), 1900(1), 1900(9) und 1900(10), um DRAM 272 in die obere Sektion 810, die partitionierbare Sektion 820 und die untere Sektion 820 zu unterteilen. In einem Ausführungsbeispiel kann Hypervisor 124 die Platzierung einer gegebenen Begrenzungsoption ändern, um die Größe eines entsprechenden Abschnitts von DRAM 272 anzupassen.
In Schritt 2406 bestimmt Hypervisor 124 eine Konfigurations-swizlD basierend auf einer Partitionierungseingabe. Die Partitionierungseingabe kann über Schritt 1002 des oben beschriebenen Verfahrens 1000 in Verbindung mit 10 erhalten werden. Die Partitionierungseingabe gibt einen Satz von Ziel-PPU-Partitionen für die PPU 200 an. Hypervisor 124 kann eine Konfigurations-swizlD für den Zielsatz von Partitionen über die oben in Verbindung mit den 11-12 beschriebenen Techniken ermitteln. In einem Ausführungsbeispiel kann die Konfigurations-swizlD vor Schritt 2404 ermittelt werden, und der erste Satz Begrenzungsoptionen kann dann basierend auf dieser Konfigurations-swizlD aktiviert werden.
In Schritt 2408 aktiviert der Hypervisor einen zweiten Satz Begrenzungsoptionen basierend auf der Konfiguration swizID, um eine oder mehrere PPU-Speicherpartitionen 710 innerhalb der partitionierbaren Sektion 820 von DRAM 272 zu erzeugen. Der zweite Satz Begrenzungsoptionen kann jede der in 19 dargestellten Begrenzungsoptionen 1900(2) bis 1900(8) umfassen. Diese verschiedenen Begrenzungsoptionen können die partitionierbare Sektion 820 in eine Anzahl von DRAM-Bereichen 822 unterteilen, die den PPU-Speicherpartitionen 710 entspricht, die gleich oder kleiner als die Anzahl der PPU-Abschnitte 610 ist. In verschiedenen Ausführungsbeispielen können die Schritte 2404 und 2408 des Verfahrens 2400 basierend auf einer Konfigurationseingabe (swizID), die über Admin-Benutzer erhalten oder aufgrund von Admin-Benutzereingaben erzeugt wurde, in Verbindung miteinander durchgeführt werden.
In Schritt 2410 bestimmt Hypervisor 124 einen Satz partitionierbarer Adressen 854 basierend auf dem Satz von Speicherkonfigurationsparametern und/oder der Konfigurations-swizlD. Dabei unterteilt Hypervisor 124 einen 1 D-SPA-Bereich 850 in obere Adressen 852, partitionierbare Adressen 854 und untere Adresse 858, wie in 21 dargestellt. Die oberen Adressen 852 können in Rohadressen übersetzt werden, die mit der oberen Sektion 810 assoziiert sind, partitionierbare Adressen 854 können in Rohadressen übersetzt werden, die mit der partitionierbaren Sektion 820 assoziiert sind, und die unteren Adressen 856 können in Rohadressen übersetzt werden, die mit der unteren Sektion 830 assoziiert sind.
In Schritt 2412 bedient die MMU 1600 Speicherzugriffsanforderungen, indem sie partitionierbare Adressen 854 über die L2-Cache-Abschnitte 800 hinweg innerhalb einer PPU-Speicherpartition 710, die einem DRAM-Bereich 822 entspricht, zuordnet (engl. swizzling). Die MMU 1600 adressiert partitionierbare Adressen über AMAP 2110 basierend auf einer Speicherzugriffs-SwizID (oder „Remote“-SwizID), die mit der PPU-Speicherpartition 710 assoziiert ist. In einem Ausführungsbeispiel wird die Speicherzugriffs- swizlD von einer swizlD abgeleitet, nach der die PPU-Speicherpartition 710 konfiguriert ist. Ein Zuordnen (engl. swizzling) partitionierbarer Adressen 854 auf diese Weise kann wiederholte Zugriffe auf einzelne L2-Cache-Abschnitte um 800 verringern (auch als „Camping“ bezeichnet).
In Schritt 2414 erhält die MMU 1600 einen lokalen Fehler-Identifikator, der mit einem Speicherfehler assoziiert ist, und übersetzt den lokalen Fehler-Identifikator in einen globalen Fehler-Identifikator. Dabei kann die MMU 1600 eine mit dem lokalen Fehler-Identifikator assoziierte virtuelle Adresse in eine mit dem globalen Fehler-Identifikator assoziierte globale Adresse übersetzen. Der Speicherfehler könnte z.B. verursacht werden, wenn eine bestimmte SMC-Engine 700 während eines Speicherlesevorgangs oder eines Speicherschreibvorgangs, der mit einer PPU-Speicherpartition 710 ausgeführt wird, einen Fehler feststellt. Die Implementierung von Fehler-IDs in einem lokalen virtuellen Adressraum ermöglicht es den SMC-Engines 700, mit ähnlichen Adressräumen zu arbeiten, wodurch eine einfachere Migration von Verarbeitungskontexten zwischen PPU-Partitionen 600 ermöglicht wird, wie oben in Verbindung mit 17 beschrieben. Das Übersetzen dieser Fehler-IDs in einen globalen Fehler-Identifikator 1620 ermöglicht es dem Hypervisor 124, Fehler, die diesen Fehler-IDs entsprechen, aus der Perspektive des Identifikators 1510 des globalen virtuellen Adressraums zu adressieren.
Allgemein auf die 19-24 Bezug nehmend, ergänzen die offenbarten Techniken zum Partitionieren von PPU-Speicherressourcen die oben in Verbindung mit den 11-18 beschriebenen Techniken zum Partitionieren von PPU-Rechenressourcen. Mit diesen Techniken kann Hypervisor 124 die PPU 200 so konfigurieren und partitionieren, dass mehrere Verarbeitungskontexte simultan unterstützt werden. Mit dieser Funktionalität kann PPU 200 eine Vielzahl unterschiedlicher Verarbeitungsaufgaben für mehrere CPU-Prozesse sicher ausführen, ohne dass sich diese CPU-Prozesse gegenseitig stören, wodurch die PPU-Ressourcen effizienter genutzt werden können. Darüber hinaus können die offenbarten Techniken angewandt werden, um robuste Unterstützung für Mehrmandantenfähigkeit in Cloud-basierten PPU-Bereitstellungen zu bieten und damit eine Produktnachfrage zu erfüllen, die in der Vergangenheit von früheren Ansätzen nicht erfüllt wurde.
Zeitliches Aufteilen mehrerer VMs und Verarbeitungskontexte
Wie hier weiter erörtert, unterstützt die PPU 200 in 2 zwei Ebenen des Partitionierens. In einer ersten Partitionierungsebene, die hier als „PPU-Partitionierung“ bezeichnet wird, werden die PPU-Ressourcen 500 der PPU 200 in PPU-Partitionen 600 unterteilt, die hier auch als „fraktionierte PPUs“ bezeichnet werden. In einigen Ausführungsbeispielen können PP-Speicher 270 und DRAM 272 oder beide in SMC-Speicherpartitionen 710 partitioniert sein. Bei diesem Partitionierungsgrad führt jede PPU-Partition 600 zu einem beliebigen Zeitpunkt eine VM aus. In einer zweiten Partitionierungsebene, die hier als „SMC-Partitionierung“ bezeichnet wird, ist jede PPU-Partition 600 weiter in SMC-Engines 700 unterteilt. Jede PPU-Partition 600 umfasst eine oder mehrere SMC-Engines 700. Auf dieser Partitionierungsebene führt jede SMC-Engine 700 zu einem beliebigen Zeitpunkt einen Verarbeitungskontext für eine VM aus.
Im Laufe der Zeit wechseln die SMC-Engines 700 von der Ausführung eines bestimmten Verarbeitungskontextes für eine VM zur Ausführung eines anderen Verarbeitungskontextes für dieselbe VM oder zur Ausführung eines anderen Verarbeitungskontextes für eine andere VM. Dieser Prozess wird hier als „zeitliches Aufteilen“ (engl. time-slicing) bezeichnet, da die Ausführungszeit für die Engine 700 auf mehrere Verarbeitungskontexte „aufgeteilt“ wird, die einer oder mehreren VMs entsprechen.
Jede SMC-Engine 700 wird zeitlich aufgeteilt zwischen Verarbeitungskontexten, die in einer Ablaufliste aufgeführt sind, wie von der PBDMA 520 und 522 der SMC-Engine 700 verwaltet. Im Allgemeinen werden bei einem Wechseln zwischen VMs die Ablauflisten auf allen betroffenen SMC-Engines 700 ersetzt, so dass ein anderer Satz von Verarbeitungskontexten in zeitliche Abschnitte aufgeteilt wird. Wenn mehrere SMC-Engines 700 aktiv sind, werden die Ablauflisten gleichzeitig ersetzt. Diese Art der Planung durch Ersetzen von Ablauflisten wird hier als „Software-Planung“ (engl. software scheduling) bezeichnet. Das Wechseln zwischen Verarbeitungskontexten innerhalb derselben VM kann in ähnlicher Weise auch das Ersetzen von Ablauflisten beinhalten und ähnelt sehr dem Wechseln von VMs, außer dass sich die VM durch den Kontextwechsel nicht ändert. Daher ist für diese Art des Kontextwechsels keine zusätzliche Hardware-Unterstützung erforderlich. In einigen Ausführungsbeispielen können VMs zahlreiche unterschiedliche Verarbeitungskontexte unterschiedlicher Größe aufweisen. In solchen Ausführungsbeispielen kann die Software-Planung berücksichtigen, wie diese Verarbeitungskontexte für eine korrekte und effiziente Ausführung in die SMC-Engines 700 eingebracht werden können. Weiter kann die Software-Planung die Anzahl der PPU-Partitionen 600 und die Anzahl der SMC-Engines innerhalb jeder PPU-Partition 600 rekonfigurieren, um die Verarbeitungskontexte für die VM korrekt und effizient auszuführen.
Damit die PPU-Ressourcen 500 die beiden oben beschriebenen Partitionierungsebenen unterstützen können, unterstützt PPU 200 entsprechend auch zwei Ebenen von zeitlichem Aufteilen. Entsprechend einer PPU-Partitionierung führt PPU 200 ein zeitliches Aufteilen auf VM-Ebene durch, wobei jede PPU-Partition 600 zwischen mehreren virtuellen Maschinen zeitlich aufgeteilt ist. Entsprechend einer SMC-Partitionierung führt PPU 200 ein zeitliches Aufteilen auf SMC-Ebene durch, wobei jede VM 600 zwischen mehreren Verarbeitungskontexten zeitlich aufgeteilt ist. In verschiedenen Ausführungsbeispielen weist das zeitliche Aufteilen auf beiden Ebenen die gleiche Anzahl von TPCs in jedem Abschnitt der GPC 242 auf. In verschiedenen Ausführungsbeispielen kann das zeitliche Aufteilen ein Ändern der Anzahl der TPCs in einem oder mehreren GPCs 242 im Laufe der Zeit beinhalten. Die zwei Ebenen des zeitlichen Aufteilens werden im Folgenden beschrieben.
25 ist ein Satz von Zeitreihen 2500, die ein zeitliches Aufteilen auf VM-Ebene zeigen, das mit den PPU-Abschnitten 600 der PPU 200 aus 2 assoziiert ist, gemäß verschiedenen Ausführungsbeispielen. Wie gezeigt, umfasst der Satz der Zeitreihen 2500 ohne Einschränkung vier PPU-Partitions-Zeitreihen 2502(0), 2502(4), 2502(6) und 2502(7). In einigen Ausführungsbeispielen können die PPU-Partitions-Zeitreihen 2502(0), 2502(4), 2502(6) und 2502(7) den PPU-Partitionen 600(0), 600(4), 600(6) bzw. 600(7) in 6 entsprechen. In solchen Ausführungsbeispielen kann die PPU-Partitions-Zeitreihe 2502(0) den PPU-Abschnitten 610(0)-610(3) entsprechen, und die PPU-Partitions-Zeitreihe 2502(4) kann den PPU-Abschnitten 610(4)-610(5) entsprechen. In ähnlicher Weise kann die PPU-Partitions-Zeitreihe 2502(6) dem PPU-Abschnitt 610(6) entsprechen, und die PPU-Partitions-Zeitreihe 2502(7) kann dem PPU-Abschnitt 610(7) entsprechen. Infolgedessen kann PPU-Partition 600(0) bis zu vier Verarbeitungskontexte gleichzeitig ausführen, PPU-Partition 600(4) kann bis zu zwei Verarbeitungskontexte gleichzeitig ausführen, und jede der PPU-Partitionen 600(6) und 600(7) kann jeweils einen Verarbeitungskontext gleichzeitig ausführen.
Wie in der PPU-Partitions-Zeitreihe 2502(0) gezeigt, ist die PPU-Partition 600(0) zwischen zwei VMs, die als VM A und VM B bezeichnet werden, in zeitliche Abschnitte aufgeteilt. Die Zeitreihe 2502(0) zeigt ein zeitliches Aufteilen zwischen VM A, wobei mit VM A assoziierte Verarbeitungskontexte in Form von CONTEXT 2510(Ax-y) gezeigt werden, und VM B, wobei mit VM B assoziierte Verarbeitungskontexte in Form von CONTEXT 2510(Bx-y) gezeigt werden. Vom Zeitpunkt t0 bis zum Zeitpunkt t1 führt die PPU-Partition 600(0) die Verarbeitungskontexte der VM A aus. Eine erste SMC-Engine 700(0) der PPU-Partition 600(0) führt sequentiell den Verarbeitungskontext 2510(A0-1), den Verarbeitungskontext 2510(A1-1) und den Verarbeitungskontext 2510(A2-1) aus. Gleichzeitig führt eine zweite SMC-Engine 700(2) der PPU-Partition 600(0) sequentiell den Verarbeitungskontext 2510(A3-1), den Verarbeitungskontext 2510(A4-1) und den Verarbeitungskontext 2510(A5-1) aus. Zum Zeitpunkt t1 stoppt die PPU-Partition 600(0) die Ausführung der mit VM A assoziierten Verarbeitungskontexte und wechselt zu den mit VM B assoziierten Verarbeitungskontexten. Der Verarbeitungskontext 2510(A2-1) und der Verarbeitungskontext 2510(A5-1) werden aus den entsprechenden SMC-Engines 700(0) und 700(2) kontextgeschaltet. Die PPU-Partition 600(0) wird rekonfiguriert von zwei SMC-Engines 700(0), umfassend die zwei GPCs 230(0) und 230(1), und 700(2), umfassend die zwei GPCs 230(2) und 230(3), zu nur einer SMC-Engine 700(0), umfassend die vier GPCs 230(0), 230(1), 230(2) und 230(3). Sobald die Partitionierung abgeschlossen ist, beginnt die PPU Partition 600(0) mit der Ausführung des Verarbeitungskontextes 2510(B0-1) der VM B.
Vom Zeitpunkt t1 bis zum Zeitpunkt t4 führt die PPU-Partition 600(0) die Verarbeitungskontexte der VM B aus. Eine erste SMC-Engine 700(0) der PPU-Partition 600(0) führt sequentiell den Verarbeitungskontext 2510(B0-1), den Verarbeitungskontext 2510(B1-1) und den Verarbeitungskontext 2510(B2-1) aus. Zum Zeitpunkt t4 stoppt die PPU-Partition 600(0) die Ausführung der mit VM B assoziierten Verarbeitungskontexte und wechselt zu den mit VM A assoziierten Verarbeitungskontexten. Der Verarbeitungskontext 2510(B2-1) wird aus der entsprechenden SMC-Engine 700(0) kontextgeschaltet. PPU-Partition 600(0) wird von einer SMC-Engine 700(0), umfassend vier GPCs 230(0), 230(1), 230(2) und 230(3), auf zwei SMC-Engines 700(0), umfassend zwei GPCs 230(0) und 230(1), und 700(2), umfassend zwei GPCs 230(2) und 230(3), umkonfiguriert. Sobald die Rekonfiguration abgeschlossen ist, beginnt die PPU-Partition 600(0) mit der Ausführung der Verarbeitungskontexte 2510(A2-2) und 2510(A5-2) von VM A. Ab dem Zeitpunkt t4 führt die PPU-Partition 600(0) wieder die Verarbeitungskontexte von VM A aus. Eine erste SMC-Engine 700(0) der PPU-Partition 600(0) führt nacheinander den Verarbeitungskontext 2510(A2-2) und den Verarbeitungskontext 2510(A0-2) aus. Gleichzeitig führt eine zweite SMC-Engine 700(2) der PPU-Partition 600(0) sequentiell den Verarbeitungskontext 2510(A5-2) und den Verarbeitungskontext 2510(A3-2) aus.
Wie in PPU-Partitions-Zeitreihe 2502(4) gezeigt, ist die PPU-Partition 600(4) zwischen zwei VMs, die als VM C und VM D bezeichnet werden, in zeitliche Abschnitte aufgeteilt. Die Zeitreihe 2502(4) zeigt ein zeitliches Aufteilen zwischen VM C, wobei mit VM C assoziierte Verarbeitungskontexte in Form von KONTEXT 2510(Cx-y) dargestellt sind, und VM D, wobei mit VM D assoziierte Verarbeitungskontexte in Form von KONTEXT 2510(Dx-y) dargestellt sind. Vom Zeitpunkt t0 bis zum Zeitpunkt t2 ist die PPU-Partition 600(4) inaktiv und führt keine Verarbeitungskontexte aus. Von der Zeit t2 bis zur Zeit t5 führt die PPU-Partition 600(4) Verarbeitungskontexte der VM C aus. Eine erste SMC-Engine 700(4) der PPU-Partition 600(4) führt sequentiell den Verarbeitungskontext 2510(C0-1) und den Verarbeitungskontext 2510(C1 -1) aus. Zum Zeitpunkt t5 stoppt die PPU-Partition 600(4) die Ausführung von Verarbeitungskontext 2510(C1-1) und konfiguriert sich neu, um mit der Ausführung von Verarbeitungskontexten von VM D zu beginnen. Ab dem Zeitpunkt t5 führt die PPU-Partition 600(4) Verarbeitungskontexte von VM D aus. Eine erste SMC-Engine 700(4) der PPU-Partition 600(4) führt den Verarbeitungskontext 2510(D1-1) aus.
Wie in der PPU-Partitions-Zeitreihe 2502(6) gezeigt, ist die PPU-Partition 600(6) in Zeitabschnitte zweiter VMs, die als VM E und VM F bezeichnet werden, aufgeteilt. Die Zeitreihe 2502(6) zeigt ein zeitliches Aufteilen zwischen VM E, wobei mit VM E assoziierte Verarbeitungskontexte in Form von KONTEXT 2510(Ex-y) gezeigt werden, und VM F, wobei mit VM F assoziierte Verarbeitungskontexte in Form von KONTEXT 2510(Fx-y) gezeigt werden. Vom Zeitpunkt t0 bis zum Zeitpunkt t3 ist die PPU-Partition 600(6) inaktiv und führt keine Verarbeitungskontexte aus. Von dem Zeitpunkt t3 bis zum Zeitpunkt t6 führt die PPU-Partition 600(6) Verarbeitungskontexte der VM E aus. Eine erste SMC-Engine 700(6) der PPU-Partition 600(6) führt sequentiell den Verarbeitungskontext 2510(E0-1) und den Verarbeitungskontext 2510(E1-1) aus. Zum Zeitpunkt t6 stoppt die PPU-Partition 600(6) die Ausführung des Verarbeitungskontextes 2510(E1-1) und konfiguriert sich neu, um mit der Ausführung von Verarbeitungskontexten der VM F zu beginnen. Ab dem Zeitpunkt t6 führt die PPU-Partition 600(4) Verarbeitungskontexte der VM F aus. Eine erste SMC-Engine 700(6) der PPU-Partition 600(6) führt den Verarbeitungskontext 2510(F0-1) aus.
Wie in der PPU-Partitions-Zeitreihe 2502(7) gezeigt, ist die PPU-Partition 600(7) in Zeitabschnitte einer einzelnen VM, die als VM G bezeichnet wird, aufgeteilt. Die Zeitreihe 2502(6) zeigt ein zeitliches Aufteilen für VM G, wobei mit VM G assoziierte Verarbeitungskontexte in Form von KONTEXT 2510(Gx-y) gezeigt werden. Vom Zeitpunkt t0 bis zum Zeitpunkt t5 ist die PPU-Partition 600(7) inaktiv und führt keine Verarbeitungskontexte aus. Ab dem Zeitpunkt t5 führt die PPU-Partition 600(7) den Verarbeitungskontext G aus. Eine erste SMC-Engine 700(7) der PPU-Partition 600(7) führt den Verarbeitungskontext 2510(G0-1) aus.
Auf diese Weise ist jede der PPU-Partitionen 600(0), 600(4), 600(6) und 600(7) in zeitliche Abschnitte von Verarbeitungskontexten aufgeteilt, die einer oder mehreren VMs entsprechen. Jede der PPU-Partitionen 600(0), 600(4), 600(6) und 600(7) geht unabhängig voneinander von einem Verarbeitungskontext in einen anderen Verarbeitungskontext über. Beispielsweise könnte die PPU-Partition 600(0) von der Ausführung eines Verarbeitungskontextes für eine bestimmte VM zu einem anderen Verarbeitungskontext für dieselbe oder eine andere VM wechseln, unabhängig davon, ob eine oder mehrere der PPU-Partitionen 600(4), 600(6) und 600(7) einen Verarbeitungskontext wechseln oder nicht. Während des dargestellten Zeitraums behält jede der PPU-Partitionen 600(0), 600(4), 600(6) und 600(7) eine konstante Anzahl von PPU-Abschnitten 610 bei. In einigen Ausführungsbeispielen kann sich die Anzahl der PPU-Abschnitte 610 in jedem PPU-Abschnitt 600 ändern, wie hier beschrieben.
26 zeigt einen weiteren Satz von Zeitreihen 2600, der ein zeitliches Aufteilen auf VM-Ebene zeigt, das mit der PPU 200 aus 2 assoziiert ist, gemäß verschiedenen anderen Ausführungsbeispielen. Die im Satz der Zeitreihen 2600 gezeigten Verarbeitungskontexte haben im Wesentlichen die gleiche Funktionalität wie der Satz der Zeitreihen 2500 in 25, außer wie weiter unten weiter beschrieben. Wie gezeigt, umfasst der Satz von Zeitreihen 2600 ohne Einschränkung vier PPU-Partitions-Zeitreihen 2602(0), 2602(4), 2602(6) und 2602(7). In einigen Ausführungsbeispielen können die PPU-Partitions-Zeitreihen 2602(0), 2602(4), 2602(6) und 2602(7) den PPU-Partitionen 600(0), 600(4), 600(6) bzw. 600(7) in 6 entsprechen.
Wie in der PPU-Partitions-Zeitreihe 2602(0) gezeigt, ist die PPU-Partition 600(0) in zeitlich zwei VMs, die als VM A und VM B bezeichnet werden, aufgeteilt. Die Zeitreihe 2602(0) zeigt ein zeitliches Aufteilen zwischen VM A, wobei mit VM A assoziierte Verarbeitungskontexte in Form von CONTEXT 2610(Ax-y) gezeigt werden, und VM B, wobei mit VM B assoziierte Verarbeitungskontexte in Form von CONTEXT 2610(Bx-y) gezeigt werden. Vom Zeitpunkt t0 bis zum Zeitpunkt t1 führt die PPU-Partition 600(0) Verarbeitungskontexte der VM B aus. Eine erste SMC-Engine 700(0) der PPU-Partition 600(0) führt sequentiell den Verarbeitungskontext 2610(B1-1) und den Verarbeitungskontext 2610(B2-1) aus. Zum Zeitpunkt t1 stoppt die PPU-Partition 600(0) die Ausführung der mit VM B assoziierten Verarbeitungskontexte und wechselt zu den mit VM A assoziierten Verarbeitungskontexten. Der Verarbeitungskontext 2610(B2-1) wird aus der entsprechenden SMC-Engine 700(0) kontextgeschaltet. Die PPU-Partition 600(0) wird von einer SMC-Engine 700(0), umfassend vier GPCs 230(0), 230(1), 230(2) und 230(3), auf zwei SMC-Engines 700(0), umfassend zwei GPCs 230(0) und 230(1), und 700(2), umfassend zwei GPCs 230(2) und 230(3), rekonfiguriert. Sobald die Rekonfiguration abgeschlossen ist, beginnt die PPU-Partition 600(0) mit der Ausführung von Verarbeitungskontexten von VM A. Vom Zeitpunkt t1 bis zum Zeitpunkt t3 führt die PPU-Partition 600(0) Verarbeitungskontexte von A aus. Eine erste SMC-Engine 700(0) der PPU-Partition 600(0) führt sequentiell den Verarbeitungskontext 2610(A2-1), den Verarbeitungskontext 2610(A0-1) und den Verarbeitungskontext 2610(A1-1) aus. Gleichzeitig führt eine zweite SMC-Engine 700(2) der PPU-Partition 600(0) sequentiell den Verarbeitungskontext 2610(A5-1), den Verarbeitungskontext 2610(A3-1) und den Verarbeitungskontext 2610(A4-1) aus. Zum Zeitpunkt t3 stoppt die PPU-Partition 600(0) die Ausführung der mit VM A assoziierten Verarbeitungskontexte und wechselt zu den mit VM B assoziierten Verarbeitungskontexten. Der Verarbeitungskontext 2610(A1-1) und der Verarbeitungskontext 2610(A4-1) werden aus den entsprechenden SMC-Engines 700(0) und 700(2) kontextgeschaltet. PPU-Partition 600(0) wird von zwei SMC-Engines 700(0), umfassend zwei GPCs 230(0) und 230(1), und 700(2), umfassend zwei GPCs 230(2) und 230(3), auf eine SMC-Engine 700(0), umfassend vier GPCs 230(0), 230(1), 230(2) und 230(3), rekonfiguriert. Sobald die Rekonfiguration abgeschlossen ist, beginnt die PPU-Partition 600(0) mit der Ausführung von Verarbeitungskontexten der VM B. Ab dem Zeitpunkt t3 führt die PPU-Partition 600(0) wieder Verarbeitungskontexte der VM B aus. Eine erste SMC-Engine 700(0) der PPU-Partition 600(0) führt sequentiell den Verarbeitungskontext 2610(B2-2) und den Verarbeitungskontext 2610(B0-1) aus.
Wie in der PPU-Partitions-Zeitreihe 2602(4) gezeigt, führt eine erste SMC-Engine 700(4) der PPU-Partition 600(4) vom Zeitpunkt t0 bis zum Zeitpunkt t2 sequentiell den Verarbeitungskontext 2610(D0-1) und den Verarbeitungskontext 2610(D1-1) aus. Die erste SMC-Engine 700(4) der PPU-Partition 600(4) befindet sich danach im Leerlauf. Wie in der PPU-Partitions-Zeitreihe 2602(6) dargestellt, führt die erste SMC-Engine 700(6) der PPU-Partition 600(6) vom Zeitpunkt t0 bis zum Zeitpunkt t2 sequentiell den Verarbeitungskontext 2610(F0-1) und den Verarbeitungskontext 2610(F1-1) aus. Die erste SMC-Engine 700(6) der PPU-Partition 600(6) befindet sich danach im Leerlauf. Wie in der PPU-Partitions-Zeitreihe 2602(7) dargestellt, befindet sich die PPU-Partition 600(7) vom Zeitpunkt t0 bis zum Zeitpunkt t2 im Leerlauf.
Zum Zeitpunkt t2 werden die PPU-Partitionen 600(4), 600(6) und 600(7) zu einer einzigen PPU-Partition 600(4) mit vier SMC-Engines 700(4)-700(7) zusammengeführt. Wie in der PPU-Partitions-Zeitreihe 2604(4) dargestellt, führt die zusammengeführte PPU-Partition 600(4) Verarbeitungskontexte von VM Haus. Beginnend mit Zeitpunkt t2 führt die erste SMC-Engine 700(4) der PPU-Partition 600(4) sequentiell den Verarbeitungskontext 2610(H0-1), den Verarbeitungskontext 2610(H1-1), den Verarbeitungskontext 2610(H2-1) und den Verarbeitungskontext 2610(H0-2) aus.
Auf diese Weise können PPU-Partitionen 600 während des zeitlichen Aufteilens (time-slicing) zusammengeführt und/oder aufgeteilt werden, um Partitionen unterschiedlicher Größe zu erhalten. PPU-Partitionen 600 können unabhängig voneinander zusammengefasst und/oder aufgeteilt werden. In den 25 und 26 wird jede VM auf einer festen Anzahl von SMC-Engines 700 ausgeführt, was zu einer konstanten Anzahl von gleichzeitig ausgeführten Verarbeitungskontexten für eine bestimmte VM führt. Wie gezeigt, wird die VM A gleichzeitig auf zwei SMC-Engines 700 ausgeführt, während die übrigen VMs jeweils auf einer SMC-Engine 700 gleichzeitig ausgeführt werden. In einigen Ausführungsbeispielen kann eine bestimmte VM die Anzahl der SMC-Engines 700 ändern, auf denen die VM, wie hier beschrieben, ausgeführt wird.
27 ist eine Zeitreihe 2700, die ein zeitliches Aufteilen auf SMC-Ebene in Verbindung mit der PPU 200 aus 2 zeigt, gemäß verschiedenen Ausführungsbeispielen. Die in der Zeitreihe 2700 gezeigten Verarbeitungskontexte haben im Wesentlichen die gleiche Funktionalität wie die Sätze von Zeitreihen 2500 und 2600 in den 25 bzw. 26, außer wie weiter unten beschrieben. Wie gezeigt, repräsentiert die Zeitreihe 2700 eine einzelne PPU-Partitions-Zeitreihe. In einigen Ausführungsbeispielen kann die PPU-Partitions-Zeitreihe, die durch die Zeitreihe 2700 repräsentiert wird, einer beliebigen PPU-Partition 600 in 6 entsprechen, die mindestens zwei SMC-Engines 700 umfasst.
Wie in Zeitreihe 2700 gezeigt wird, ist die PPU-Partition in Zeitabschnitte einer einzigen VM zeitlich aufgeteilt, die als VM A bezeichnet wird. Die Zeitreihe 2700 zeigt ein zeitliches Aufteilen für VM A, wobei die mit VM A assoziierten Verarbeitungskontexte in Form von CONTEXT 2710(Ax-y) gezeigt werden. Beginnend mit dem Zeitpunkt t0 wird VM A auf den beiden SMC-Engines 700 ausgeführt. Eine erste SMC-Engine 700, die in der PPU-Partition 600 enthalten ist, führt den Verarbeitungskontext 2710(A0-1) aus und bleibt dann bis zum Zeitpunkt t1 im Leerlauf. Gleichzeitig führt die zweite SMC-Engine 700, die in PPU-Partition 600 enthalten ist, den Verarbeitungskontext 2710(A1-1) aus und bleibt dann bis zum Zeitpunkt t1 im Leerlauf. Die Dauer zwischen dem Zeitpunkt t0 und dem Zeitpunkt t1 ist ausreichend lang, um zu gewährleisten, dass die Ausführung der Verarbeitungskontexte 2710(A0-1) und 2710(A1-1) abgeschlossen wird und dass die SMC-Engines in den Leerlaufzustand eintreten. In einigen Ausführungsbeispielen können der Verarbeitungskontext 2710(A0-1) und der Verarbeitungskontext 2710(A1-1) dieselben Aufgaben gleichzeitig auf zwei separaten SMC-Engines 700 ausführen, wodurch eine räumliche Redundanz entsteht. In solchen Ausführungsbeispielen können der Verarbeitungskontext 2710(A0-1) und der Verarbeitungskontext 2710(A1-1) Aufgaben auf redundanten SMC-Engines 700 ausführen, die die gleiche Konfiguration haben, und dann die Ergebnisse hinsichtlich Genauigkeit und Determinismus vergleichen.
Zwischen dem Zeitpunkt t1 und dem Zeitpunkt t2 werden die Ablauflisten für die Verarbeitungskontexte 2710(A0-1) und 2710(A1-1) aus der PPU Partition 600 entfernt. Die PPU-Partition 600 wird von zwei SMC-Engines 700 auf eine SMC-Engine 700 rekonfiguriert, die alle Ressourcen der beiden SMC-Engines 700 umfasst. Die PPU-Partition 600 verwendet dann neue Ablauflisten für die Ausführung der Verarbeitungskontexte 2710(B2-1), 2710(B3-1) und 2710(B4-1).
Zwischen dem Zeitpunkt t2 und dem Zeitpunkt t3 wird VM B auf einer SMC-Engine 700 ausgeführt. Die in der PPU Partition 600 enthaltene SMC-Engine 700 führt sequentiell den Verarbeitungskontext 2710(B2-1), den Verarbeitungskontext 2710(B3-1) und den Verarbeitungskontext 2710(B4-1) aus. In einigen Ausführungsbeispielen können die Verarbeitungskontexte 2710(B2-1), 2710(B3-1) und 2710(B4-1) leistungsintensive Aufgaben ausführen, die von der Ausführung auf einer einzigen SMC-Engine 700 profitieren können, die über mehr Rechenressourcen verfügt als die SMC-Engines, die die Verarbeitungskontexte 2710(A0-1) und 2710(A1-1) ausführen. Die SMC-Engine 700 befindet sich danach bis zum Zeitpunkt t3 im Leerlauf. In einigen Ausführungsbeispielen führt die Engine 700 während dieser Leerlaufphase Offline-Planungsaufgaben aus.
Zwischen dem Zeitpunkt t3 und dem Zeitpunkt t4 werden die Ablauflisten für die Verarbeitungskontexte 2710(B2-1), 2710(B3-1) und 2710(B4-1) aus PPU-Partition 600 entfernt. PPU-Partition 600 wird von einer SMC-Engine 700 zu zwei SMC-Engines 700 rekonfiguriert. Die beiden SMC-Engines 700 umfassen jeweils einen Bereich der Ressourcen, die in der einen SMC-Engine 700 enthalten waren. Die PPU-Partition 600 verwendet dann neue Ablauflisten für die Ausführung der Verarbeitungskontexte 2710(A0-2) und 2710(A1-2).
Ab dem Zeitpunkt t4 wird VM A wieder auf zwei SMC-Engines 700 ausgeführt. Die erste SMC-Engine 700 führt den Verarbeitungskontext 2710(A0-2) aus und bleibt dann bis zum Zeitpunkt t5 im Leerlauf. Gleichzeitig führt die zweite SMC-Engine 700 den Verarbeitungskontext 2710(A1-2) aus und bleibt dann bis zum Zeitpunkt t5 im Leerlauf. Die Dauer zwischen dem Zeitpunkt t4 und dem Zeitpunkt t5 ist ausreichend lang, um ausreichend Zeit dafür zu gewährleisten, dass die Verarbeitungskontexte 2710(AO-2) und 2710(A1-2) die Ausführung abschließen und die SMC-Engines in einen Leerlaufzustand übergehen können. In einigen Ausführungsbeispielen können der Verarbeitungskontext 2710(A0-2) und der Verarbeitungskontext 2710(A1-2) dieselben Aufgaben gleichzeitig auf zwei separaten SMC-Engines 700 ausführen, wodurch eine räumliche Redundanz entsteht. In solchen Ausführungsbeispielen können der Verarbeitungskontext 2710(A0-2) und der Verarbeitungskontext 2710(A1-2) Aufgaben auf redundanten SMC-Engines 700 ausführen, die die gleiche Konfiguration haben, und dann die Ergebnisse hinsichtlich Genauigkeit und Determinismus vergleichen.
Zwischen dem Zeitpunkt t5 und dem Zeitpunkt t6 werden Ablauflisten für die Verarbeitung der Kontexte 2710(A0-2) und 2710(A1-2) aus der PPU-Partition 600 entfernt. Die PPU-Partition 600 wird von zwei SMC-Engines 700 zu einer SMC-Engine 700 rekonfiguriert, die alle Ressourcen der beiden SMC-Engines 700 umfasst. PPU-Partition 600 verwendet dann neue Ablauflisten für die Ausführung des Verarbeitungskontextes 2710(B3-2). Ab dem Zeitpunkt t6 wird VM B wieder auf der einen SMC-Engine 700 ausgeführt. Die SMC-Engine 700 führt den Verarbeitungskontext 2710(B3-2) aus.
In einigen Ausführungsbeispielen kann die PPU-Partition 600 zwischen der Ausführung auf einer SMC-Engine und der Ausführung auf zwei SMC-Engines schnell rekonfiguriert werden, ein Prozess, der hier als „schnelle Rekonfiguration“ bezeichnet wird. Die schnelle Rekonfiguration erhöht die Auslastung der PPU-200-Ressourcen und bietet gleichzeitig einen Mechanismus für mehrere Verarbeitungskontexte, die auf einer einzigen PPU-Partition 600 in verschiedenen Modi ausgeführt werden können. Sowohl der Treiberkernel 914 als auch der Hardware-Mikrocode innerhalb der PPU 200 umfassen verschiedene Optimierungen, die eine schnelle Rekonfiguration ermöglichen. Diese Optimierungen werden hier beschrieben.
Während der Rekonfiguration werden bestimmte Ressourcen in PPU 200, wie z.B. FECS 530 und GPC 242- Kontext-Switches, nicht zurückgesetzt, es sei denn, die Ressource erzeugt einen Fehler. Infolgedessen kann das Laden von Mikrocode in diese Ressourcen während der Rekonfiguration in mehrere Phasen unterteilt werden. Insbesondere kann die Mikrocode-Ladesequenz für FECS 530 und GPC 242 in eine LOAD-Phase und eine INIT-Phase unterteilt werden. Die LOAD-Phase wird für alle verfügbaren FECS 530- und GPC 242-Kontext-Switches innerhalb der PPU-Partition 600 parallel ausgeführt, wodurch die zum Laden von Mikrocode in diese Ressourcen benötigte Zeit reduziert wird. Die INIT-Phase wird während der Rekonfiguration durchgeführt, wodurch die Initialisierung der FECS 530- und GPC 242-Kontext-Switches parallel zur Rekonfiguration der PPU-Partition 600 durchgeführt wird. Während der Initialisierungsphase stellt die PPU 200 sicher, dass die LOAD-Phase für alle FECS 530- und GPC 242-Kontext-Switches abgeschlossen ist. Dadurch wird die Zeit zum Laden und Initialisieren der Ressourcen von PPU-Partition 600 reduziert. Darüber hinaus speichert PPU 200 für jede mögliche Konfiguration von PPU-Partitionen 600 einen Cache mit standardisierten Verarbeitungskontextbildern, die hier als „goldene Verarbeitungskontextbilder“ bezeichnet werden. Die entsprechenden Golden-Processing-Kontextbilder werden während der LOAD- und INIT-Phase abgerufen und geladen, wodurch die Zeit zum Laden und Initialisieren der Ressourcen von PPU-Partition 600 weiter reduziert wird.
Wie hier beschrieben, kann eine bestimmte VM im Laufe der Zeit die Anzahl der SMC-Engines 700 ändern, auf denen die VM ausgeführt wird. In einem bestimmten Beispiel umfasst die VM A verschiedene Aufgaben, die mit einem selbstfahrenden Fahrzeug assoziiert sind. Bestimmte Aufgaben des selbstfahrenden Fahrzeugs sind kritischer als andere Aufgaben. Beispielsweise würden Aufgaben, die mit dem selbständigen Fahren assoziiert sind, wie das Erkennen von Ampeln und das Vermeiden von Unfällen, als kritischer angesehen als Aufgaben, die mit dem Unterhaltungssystem des Fahrzeugs assoziiert sind. Diese kritischeren Aufgaben können bestimmten Vorschriften oder Industrienormen unterliegen. Eine dieser Normen weist eine Klassifizierungsstufe zu, die als „Automotive Safety Integrity Level“ (ASIL) bezeichnet wird. ASIL umfasst vier Stufen, die als ASIL-A, ASIL-B, ASIL-C und ASIL-D bezeichnet werden, in der Reihenfolge steigender Integritätsstufen. Aufgaben wie das Erkennen von Ampeln und die Vermeidung von Unfällen werden als ASIL-D klassifiziert. Weniger kritische Aufgaben können als niedrigere ASIL-Stufen klassifiziert werden. Aufgaben, die keine Sicherheitsrelevanz haben, wie z.B. Aufgaben, die mit dem Unterhaltungssystem des Fahrzeugs assoziiert sind, können als QM klassifiziert werden, was bedeutet, dass nur Standardqualitätsmanagementpraktiken anwendbar sind.
In dieser Hinsicht können die Verarbeitungskontexte 2710(A0-1) und 2710(A1-1) zwei Instanzen derselben Aufgabe auf ASIL-D-Ebene umfassen, die gleichzeitig auf zwei verschiedenen SMC-Engines 700 einer PPU-Partition 600 ausgeführt werden. Nachdem die Verarbeitungskontexte 2710(A0-1) und 2710(A1-1) vollständig ausgeführt wurden, werden die Ergebnisse der Verarbeitungskontexte 2710(A0-1) und 2710(A1-1) miteinander verglichen. Wenn der Verarbeitungskontext 2710(A0-1) und der Verarbeitungskontext 2710(A1-1) die gleichen Ergebnisse erzeugen, werden die Ergebnisse validiert, und das Fahrzeug fährt entsprechend den Ergebnissen fort. Auf der anderen Seite kann ein Fehler in einer oder mehreren Komponenten, die entweder mit dem Verarbeitungskontext 2710(A0-1) oder dem Verarbeitungskontext 2710(A1-1) assoziiert sind, dazu führen, dass der betroffene Verarbeitungskontext falsche Ergebnisse erzeugt. Wenn also der Verarbeitungskontext 2710(A0-1) und der Verarbeitungskontext 2710(A1-1) unterschiedliche Ergebnisse erzeugen, werden die Ergebnisse ungültig, und das Fahrzeug führt eine geeignete Ausweichaktion aus, z.B. langsames Fahren in Richtung der nächstgelegenen Position außerhalb des Verkehrsflusses.
Nachdem die Verarbeitungskontexte 2710(A0-1) und 2710(A1-1) vollständig ausgeführt wurden, wird die PPU-Partition 600 so rekonfiguriert, dass sie nur eine SMC-Engine 700 umfasst. Die SMC-Engine 700 führt sequentiell die Verarbeitungskontexte 2710(B2-1), 2710(B3-1) und 2710(B4-1) auf QM-Ebene aus. Diese Verarbeitungskontexte umfassen weniger kritische Aufgaben, wie z.B. Aufgaben, die mit dem Unterhaltungssystem des Fahrzeugs assoziiert sind. Nach der vollständigen Ausführung der Verarbeitungskontexte 2710(B2-1), 2710(B3-1) und 2710(B4-1) wird PPU-Partition 600 so rekonfiguriert, dass sie zwei SMC-Engines 700 umfasst. Die SMC-Engines 700 führen gleichzeitig die Verarbeitungskontexte 2710(AO-2) und 2710(A1-2) aus, bei denen es sich um zwei Instanzen derselben Aufgabe auf ASIL-D-Ebene handelt. Nachdem die Verarbeitungskontexte 2710(A0-2) und 2710(A1-2) vollständig ausgeführt wurden, rekonfiguriert sich die PPU-Partition 600 erneut, so dass sie nur eine SMC-Engine 700 umfasst, und führt den Verarbeitungskontext 2710(B3-2) auf QM-Ebene aus.
Auf diese Weise wird die PPU-Partition 600 dynamisch zwischen mehreren SMC-Engines 700, die Aufgaben auf ASIL-D-Ebene ausführen, und einer einzigen SMC-Engine 700, die Aufgaben auf QM-Ebene ausführt, rekonfiguriert. Die Dauer zwischen aufeinanderfolgenden ASIL-D-Verarbeitungskontexten, z. B. die Dauer zwischen dem Zeitpunkt t0 und dem Zeitpunkt t4, wird als „Frame“ bezeichnet, wobei der Bereich des Frames zwischen dem Zeitpunkt t0 und dem Zeitpunkt t1 für die Ausführung von ASIL-D-Aufgaben zugewiesen wird.
28 zeigt, wie VMs von einer PPU 200(1) zu einer anderen PPU 200(2) migrieren können, gemäß verschiedenen Ausführungsbeispielen. Wie in 2800 dargestellt, führt PPU 200(1) die vier VMs 2810A, 2810B, 2810C und 2810D aus. Jede dieser VMs 2810A, 2810B, 2810C und 2810D wird auf einer anderen SMC-Engine 700 ausgeführt, die in PPU 200(1) enthalten ist. In ähnlicher Weise führt PPU 200(2) die vier VMs 2810E, 2810F, 2810G und 2810H aus. Jede dieser VMs 2810E, 2810F, 2810G und 2810H wird auf einer anderen SMC-Engine 700 ausgeführt, die in PPU 200(1) enthalten ist.
Im Laufe der Zeit können VMs aus verschiedenen Gründen von einer PPU 200 auf eine andere PPU 200 migriert werden, unter anderem, ohne Einschränkung, zur Vorbereitung einer Systemwartung, zur Konsolidierung von VMs auf weniger PPUs 200, um eine bessere Auslastung oder Energieeinsparungen zu erzielen, und zur Effizienzsteigerung durch die Migration auf verschiedene Rechenzentren. In einem ersten Beispiel könnten VMs gezwungen sein, auf andere PPUs 200 zu migrieren, wenn das System, auf dem die VMs derzeit ausgeführt werden, kurz vor dem Herunterfahren für eine Systemwartung steht. In einem zweiten Beispiel könnten die Verarbeitungskontexte einer oder mehrerer VMs für eine unbestimmte Zeit inaktiv sein. Wenn alle Verarbeitungskontexte in einer oder mehreren VMs untätig sind, könnten die VMs von einer PPU 200 zu einer anderen PPU 200 migrieren, um die Auslastung der PPU 200 zu verbessern oder den Stromverbrauch zu senken. In einem dritten Beispiel könnten VMs, die einem bestimmten Benutzer oder Satz von Benutzern zugeordnet sind, von einem geografisch entfernten Zentrum in ein näher gelegenes Rechenzentrum migriert werden, um die Kommunikationslatenz zu verbessern. Ganz allgemein können VMs auf verschiedene PPUs 200 migriert werden.
Allgemeiner gesagt können VMs jederzeit von einer PPU 200 auf eine andere PPU 200 migrieren, wenn ein Kontext über eine Kontextspeicherung von der Ausführung auf der Hardware entfernt wurde. Das betreffende Betriebssystem, wie z.B. das Gastbetriebssystem 916 in 9, kann einen Kontext unterbrechen und eine Kontextspeicherung jederzeit erzwingen, nicht nur, wenn die entsprechende VM im Leerlauf ist. Ein Kontext kann unterbrochen werden, wenn alle Arbeiten für die entsprechende VM abgeschlossen sind. Darüber hinaus kann ein Kontext unterbrochen werden, indem der Kontext gezwungen wird, keine weitere Arbeit mehr einzureichen und die aktuelle laufende Arbeit abzubrechen, selbst wenn die VM noch weitere Arbeit zu leisten hat. In beiden Fällen kann die VM von einer PPU 200 in eine andere PPU 200 migriert werden, sobald die laufende Arbeit für den Kontext abgebrochen und der Kontext gespeichert wurde. Während der VM-Migration kann es bei der VM zu einer Aussetzung der Ausführung in der Größenordnung von einigen Millisekunden kommen.
In einigen Ausführungsbeispielen migriert eine VM möglicherweise nur zu einer PPU-Partition 600 in einer anderen PPU 200, die dieselbe Konfiguration hat wie die PPU-Partition 600, die die VM gerade ausführt. Beispielsweise kann die VM so eingeschränkt werden, dass sie nur zu einer PPU-Partition 600 in einer anderen PPU 200 migriert, die dieselbe Anzahl von GPCs 242 hat wie die PPU-Partition 600, die derzeit die VM ausführt. Wie in Diagramm 2802 dargestellt, befinden sich vier der VMs in einem Leerlaufzustand. PPU 200(1) führt die beiden VMs 2810A und 2810C aus. Die beiden anderen VMs 2810B und 2810D, die zuvor auf PPU 200(1) ausgeführt wurden, befinden sich im Leerlauf. In ähnlicher Weise führt PPU 200(2) die beiden VMs 2810E und 2810H aus. Die beiden anderen VMs 2810F und 2810G, die zuvor auf PPU 200(1) ausgeführt wurden, befinden sich im Leerlauf. Infolgedessen sind PPU 200(1) und 200(2) nicht voll ausgelastet. In solchen Fällen können die derzeit ausführenden VMs migrieren, um die verfügbaren PPU-Ressourcen besser auszunutzen. In einem Beispiel könnten die auf PPU 200(1) ausgeführten VMs die Hälfte der auf PPU 200(1) verfügbaren Hardwareressourcen verbrauchen. Ebenso könnten die auf PPU 200(2) ausgeführten VMs die Hälfte der auf PPU 200(2) verfügbaren Hardwareressourcen verbrauchen. Infolgedessen würden PPU 200(1) und PPU 200(2) jeweils mit etwa 50 % der Kapazität betrieben werden. Wenn alle VMs, die auf PPU 200(2) ausgeführt werden, auf PPU 200(1) migriert werden, dann würde PPU 200(1) mit etwa 100 % der Kapazität arbeiten. PPU 200(2) würde mit 0 % der Kapazität betrieben werden. Infolgedessen könnte die Versorgungsspannung für PPU 200(2) reduziert werden, um den Stromverbrauch zu senken. Wie in Diagramm 2804 dargestellt, wurden die VMs 2810E und 2810H von PPU 200(2) auf PPU 200(1) umgestellt. Infolgedessen führt PPU 200(1) die vier VMs 2810A, 2810E, 2810C und 2810H aus. PPU 200(1) wird daher besser ausgelastet. Nach der VM-Migration führt PPU 200(2) keine VMs mehr aus. Infolgedessen kann PPU 200(2) heruntergefahren werden, um den Stromverbrauch zu reduzieren. Wenn anschließend weitere VMs mit der Ausführung beginnen, kann PPU 200(2) hochgefahren werden, um die zusätzlichen VMs auszuführen.
29 ist ein Satz von Zeitreihen 2900, die eine feine VM-Migration assoziiert mit der PPU 200 aus 2 zeigen, gemäß verschiedenen Ausführungsbeispielen. Der Satz von Zeitreihen 2900 hat im Wesentlichen die gleiche Funktionalität wie die Sätze von Zeitreihen 2500 und 2600 in den 25 bzw. 26 und die Zeitreihe 2700 in 27, außer wie weiter unten weiter beschrieben. Wie gezeigt, umfasst der Satz von Zeitreihen 2900 ohne Einschränkung die vier PPU-Partitions-Zeitreihen 2902(0), 2902(1), 2902(2) und 2902(3). In einigen Ausführungsbeispielen können die PPU-Partitions-Zeitreihen 2902(0), 2902(1), 2902(2) und 2902(3) den vier PPU-Partitionen 600 in 6 entsprechen. Jede PPU-Partition 600 umfasst eine SMC-Engine 700. Daher kann jede PPU-Partition 600 jeweils eine VM auf einmal ausführen. Wie in den PPU-Partitions-Zeitreihen 2902(0), 2902(1), 2902(2) und 2902(3) dargestellt, ist jede PPU-Partition 600 in Zeitabschnitte von fünf VMs, die als VM A bis VM F bezeichnet werden, zeitlich unterteilt. Daher wird jede der fünf VMs zwischen den vier PPU-Partitionen 600 migriert.
Während des Zeitraums, der in 29 dargestellt ist, führt VM A den Verarbeitungskontext 2910(A0) auf einer ersten PPU-Partition aus, wie in der PPU-Partitions-Zeitreihe 2902(3) dargestellt. Anschließend migriert VM A zu einer zweiten PPU-Partition und führt Verarbeitungskontext 2910(A1) auf der PPU-Partitions-Zeitreihe 2902(2) aus. Anschließend migriert VM A wiederum zu einer dritten PPU-Partition und einer vierten PPU-Partition und führt Verarbeitungskontexte 2910(A2) und 2910(A3) auf den Zeitreihen 2902(1) bzw. 2902(0) der PPU-Partition aus. VM A migriert dann zurück zur ersten PPU-Partition und führt Verarbeitungskontext 2910(A4) auf der PPU-Partitions-Zeitreihe 2902(3) aus. Schließlich migriert VM A erneut zur zweiten PPU-Partition und führt Verarbeitungskontext 2910(A5) auf der Zeitreihe 2902(2) der PPU-Partition aus.
In ähnlicher Weise wird VM B, das die Verarbeitungskontexte 2910(BO) bis 2910(B4) ausführt, auf der ersten PPU-Partition 600 ausgeführt und migriert dann zwischen den anderen drei PPU-Partitionen, wie in den PPU-Partitions-Zeitreihen 2902(0), 2902(1), 2902(2) und 2902(3) dargestellt. Die übrigen drei VMs migrieren ebenfalls zwischen den vier PPU-Partitionen, wobei VM C die Verarbeitungskontexte 2910(C0) bis 2910(C5), VM D die Verarbeitungskontexte 2910(D0) bis 2910(D5) und VM E die Verarbeitungskontexte 2910(EO) bis 2910(E5) ausführt.
Auf diese Weise migrieren fünf VMs zwischen vier PPU-Partitionen 600, wobei jede VM im Wesentlichen auf die gleiche Menge an PPU-Ressourcen zugreift. Insgesamt sind die fünf VMs jeweils in der Lage, etwa 80% der Zeit auszuführen, wobei vier PPU-Partitionen 600 geteilt durch fünf VMs gleich 4/5 oder 80% sind. Infolgedessen führt eine feine VM-Migration einen Lastausgleich zwischen einem Satz von VMs durch, unabhängig von der Anzahl der VMs im Verhältnis zur Anzahl der PPU-Partitionen 600.
Die 30A-30B zeigen ein Flussdiagramm mit Verfahrensschritten zum zeitlichen Aufteilen von VMs im PPU-Abschnitt 200 von 2, gemäß verschiedenen Ausführungsbeispielen. Obwohl die Verfahrensschritte in Verbindung mit den Systemen der 1-15 beschrieben werden, werden Fachleute verstehen, dass jedes beliebige System, das zur Durchführung der Verfahrensschritte in beliebiger Reihenfolge konfiguriert sein kann, unter den Umfang der vorliegenden Offenbarung fällt.
Wie gezeigt, beginnt ein Verfahren 3000 mit Schritt 3002, in dem PPU 200 bestimmt, dass mindestens eine VM im Begriff ist, von einem ersten Satz eines oder mehrerer Verarbeitungskontexte zu einem zweiten Satz eines oder mehrerer Verarbeitungskontexte zu wechseln. Eine VM kann aus jedem technisch geeigneten Grund dabei sein, den/die Verarbeitungskontext(e) zu wechseln, einschließlich, aber nicht beschränkt darauf, dass die VM die Ausführung aller Aufgaben abschließt, die VM in einen Leerlaufzustand übergeht, die VM für eine maximal zugewiesene Zeitspanne ausgeführt wurde oder die VM einen Fehler erzeugt hat.
In Schritt 3004 bestimmt die PPU 200, ob die PPU 200 eine Intra-PPU-Partitionsänderung durchführen muss, um den/die neuen Verarbeitungskontext(e) zu berücksichtigen. Eine Intra-PPU-Partitionsänderung erfolgt, wenn eine PPU-Partition 600 während des Kontext-Switch die gleiche Anzahl von PPU-Abschnitten 610 beibehält, aber die Anzahl der aktiven SMC-Engines 700 innerhalb der PPU-Partition 600 ändert. Wenn die PPU-Partition 200 keine Intra-PPU-Partitionsänderung durchführen muss, um den/die neuen Verarbeitungskontext(e) aufzunehmen, geht das Verfahren 3000 zu Schritt 3008 über. Wenn die PPU 200 jedoch eine Intra-PPU-Partitionsänderung durchführen muss, um den neuen Verarbeitungskontext/die neuen Verarbeitungskontexte zu berücksichtigen, fährt das Verfahren 3000 mit Schritt 3006 fort, in dem die PPU 200 die PPU-Partition 600 rekonfiguriert, um die gleiche Anzahl von PPU-Abschnitten 610 beizubehalten, während die Anzahl der aktiven SMC-Engines 700 geändert wird.
In Schritt 3008 bestimmt die PPU 200, ob die PPU 200 eine Inter-PPU-Partitionsänderung durchführen muss, um den/die neuen Verarbeitungskontext(e) zu berücksichtigen. Eine Inter-PPU-Partitionsänderung erfolgt, wenn eine PPU-Partition 600 während des Kontext-Switch die Anzahl der PPU-Abschnitte 610 durch Zusammenführen oder Aufteilen einer oder mehrerer PPU-Partitionen 600 ändert. Infolgedessen ändert PPU 200 auch die Anzahl der PPU-Partitionen 600 innerhalb von 700. Abhängig von den neuen Verarbeitungskontexten kann PPU 200 die Anzahl der aktiven SMC-Engines 700 innerhalb jeder PPU-Partition 600 ändern oder nicht. Wenn die PPU 200 keine Inter-PPU-Partitionsänderung durchführen muss, um den/die neuen Verarbeitungskontext(e) zu berücksichtigen, fährt das Verfahren 3000 mit Schritt 3012 fort. Wenn die PPU 200 jedoch eine Inter-PPU-Partitionsänderung durchführen muss, um den/die neuen Verarbeitungskontext(e) zu berücksichtigen, fährt das Verfahren 3000 mit Schritt 3010 fort, in dem die PPU 200 die PPU-Partition 600 rekonfiguriert, um die Anzahl der in der PPU-Partition 600 enthaltenen PPU-Abschnitte 610 zu ändern. Um die Anzahl der PPU-Abschnitte 610 in einer PPU-Partition 600 zu ändern, führt PPU 200 zwei oder mehr PPU-Partitionen 600 zu einer einzigen PPU-Partition 600 zusammen. Zusätzlich oder alternativ teilt PPU 200 eine PPU-Partition 600 in zwei oder mehr PPU-Partitionen 600 auf.
In Schritt 3012 bestimmt die PPU 200, ob alle VMs, die auf einer bestimmten PPU 200 ausgeführt werden, im Leerlauf sind. Wenn eine oder mehrere VMs auf der gegebenen PPU 200 nicht im Leerlauf (aktiv) sind, fährt das Verfahren mit Schritt 3018 fort. Wenn dagegen alle VMs, die auf einer bestimmten PPU 200 ausgeführt werden, im Leerlauf sind, fährt das Verfahren 3000 mit Schritt 3014 fort, wobei PPU 200 bestimmt, ob eine oder mehrere andere PPUs 200 über die Ressourcen verfügen, um die inaktiven VMs auszuführen. Wenn die Ressourcen auf einer oder mehreren anderen PPUs 200 nicht verfügbar sind, fährt das Verfahren mit Schritt 3018 fort. Wenn dagegen die Ressourcen auf einer oder mehreren anderen PPUs 200 nicht verfügbar sind, fährt das Verfahren mit Schritt 3016 fort, in dem die PPU 200 die im Leerlauf befindlichen VMs auf eine oder mehrere andere PPUs 200 migriert.
In Schritt 3018 beginnt PPU 200 nach der Durchführung von Intra-PPU-Partitionsänderungen, Inter-PPU-Partitionsänderungen und/oder VM-Migrationen mit der Ausführung der neuen Verarbeitungskontexte. Das Verfahren 3000 wird dann beendet. In verschiedenen Ausführungsbeispielen bestimmt PPU 200 die Notwendigkeit, Intra-PPU-Änderungen durchzuführen, unabhängig von der Notwendigkeit, Inter-PPU-Änderungen durchzuführen. In verschiedenen Ausführungsbeispielen bestimmt PPU 200 in ähnlicher Weise die Notwendigkeit, Inter-PPU-Änderungen vorzunehmen, unabhängig von der Bestimmung der Notwendigkeit, Intra-PPU-Änderungen vorzunehmen.
Adressenzuordnung mit privilegierten Register
Wie hier weiter beschrieben, ermöglicht der PRI-Hub 512 von 5 und ein interner PRI-Bus (nicht abgebildet) einer CPU 110 und/oder einer beliebigen Einheit in der PPU 200 das Lesen und Schreiben privilegierter Register, auch „PRI-Register“ genannt, die über die gesamte PPU 200 verteilt sind. Dabei ist der PRI-Hub 212 so konfiguriert, dass er PRI-Bus-Adressen zwischen einem generischen Adressraum, der alle PRI-Bus-Register abdeckt, und einem für jede Sys-Pipe 230 separat definierten Adressraum abbildet. Bei der Kommunikation über eine PCIe-Verbindung, im Allgemeinen von der CPU aus, erfolgt der Zugriff auf die PRI-Register über einen PCle-Adressraum, der hier als „Basisadressregister 0“-Raum oder einfacher als „BAR0“-Adressraum bezeichnet wird, wie er für an PCIe-Bussen angeschlossene Geräte typisch ist. Normalerweise ist der adressierbare Speicherbereich des BARO-Adressraums für die PPU 200 auf 16 Megabyte (MB) begrenzt, da eine große Anzahl von Geräten alle in den BARO-Adressraum passen müssen. Der Adressbereich von 16 MB ist für den Zugriff auf die privilegierten Register für eine einzelne SMC-Engine 700 ausreichend. Um jedoch mehrere SMC-Engines 700 zu unterstützen, kann der Adressbereich 16 MB überschreiten. Daher bietet der PRI-Hub 512 zwei Adressierungsmodi, um die Ausführung mit mehreren SMC-Engines 300 zu unterstützen. Der erste Adressierungsmodus, der hier als „Alt-Modus“ (herkömmlich, engl. legacy) bezeichnet wird, gilt für Operationen mit einer einzelnen SMC-Engine 700. Der zweite Adressierungsmodus, hier als SMC-Engine-Adressierungsmodus‟ bezeichnet, gilt für Operationen mit mehreren SMC-Engines 700. Die Adressierungsmodi werden hier beschrieben.
31 zeigt eine Speicherkarte, die darstellt, wie der BARO-Adressraum 3110 auf den privilegierten Registeradressraum 3120 innerhalb der PPU 200 von 2 abgebildet wird, gemäß verschiedenen Ausführungsbeispielen. Der BARO-Adressraum 3110 umfasst, ohne Einschränkung, einen ersten Adressraum 3112, einen GFX REG-Adressraum (GFX REG) 3114 und einen zweiten Adressraum 3116. Der Adressraum des privilegierten Registers 3120 umfasst, ohne Einschränkung, einen ersten Adressraum 3122, einen Alt-Grafikregister-Adressraum 3124, einen zweiten Adressraum 3126 und die SMC-Grafikregister-Adressräume 3128(0) - 3128(7). Der „BARO-Adressraum 3110 unterstützt zwei Adressierungsmodi, den Alt-Adressierungsmodus und den SMC-Adressierungsmodus. Im Allgemeinen sind die Ziele der beiden Modi: (1) Alt-Modus, bei dem die gesamte PPU 200 als eine Engine mit einem Satz PRI-Register behandelt wird; und (2) SMC-Modus, bei dem jede PPU-Partition 600 so adressiert wird, als ob jede PPU-Partition 600 eine separate Engine wäre und als ob jede PPU-Partition 600 eine eigenständige PPU 200 wäre. Der SMC-Modus erlaubt es der Treibersoftware 122, identisch zu sein, wenn sie mit der gesamten PPU im Alt-Modus und wenn sie mit nur einer PPU-Partition 600 arbeitet. Das heißt, der Treiber kann einmal geschrieben und in beiden Szenarien, im Alt-Modus und im SMC-Modus, verwendet werden.
Im Alt-Adressierungsmodus führt die PPU 200 Aufgaben als ein einzelner Cluster von Hardwareressourcen aus, und nicht als separate PPU-Partitionen 600 mit separaten SMC-Engines 700. Im Alt-Modus wird durch das Lenken eines Lese- oder Schreibzugriffs auf eine Speicheradresse in Richtung des ersten Adressraums 3112 oder des zweiten Adressraums 3116 des BARO-Adressraums 3110 auf eine entsprechende Speicheradresse innerhalb des ersten Adressraums 3122 bzw. des zweiten Adressraums 3126 des privilegierten Registeradressraums 3120 zugegriffen. In ähnlicher Weise greift das Lenken eines Lese- oder Schreibzugriffs auf eine Speicheradresse in Richtung Grafikregister-Adressraum 3114 des BARO-Adressraums 3110 auf eine entsprechende Speicheradresse innerhalb des Alt-Grafikregister-Adressraums 3124 des privilegierten Register-Adressraums 3120 zu. Der Alt-Grafikregister-Adressraum 3124 umfasst einen Adressbereich für verschiedene Komponenten innerhalb der PPU 200, einschließlich, ohne Einschränkung, Rechen FE 540, Graphik FE 542, SKED 550, CWD 560 und PDA/PDB 562. Darüber hinaus umfasst der Alt-Grafikregister-Adressraum 3124 einen Adressbereich für jeden der GPCs 242. GPCs 242 sind einzeln adressierbar, abzüglich beliebiger GPCs 242, die aufgrund von Floor Sweeping entfernt wurden, über dedizierte Adressbereiche innerhalb des Alt-Grafikregister-Adressraums 3124. Zusätzlich oder alternativ dazu umfasst der Alt-Grafikregister-Adressraum 3124 Adressbereiche für die gleichzeitige Übertragung von Daten an alle GPCs 242. Diese GPC-Broadcast-Adressräume können nützlich sein, wenn alle GPCs 242 identisch konfiguriert werden.
Im SMC-Adressierungsmodus führt die PPU 200 Aufgaben als separate PPU-Partitionen 600 mit den separaten SMC-Engines 700 aus. Wie im Alt-Modus wird durch das Lenken eines Lese- oder Schreibzugriffs auf eine Speicheradresse in Richtung des ersten Adreßraums 3112 oder des zweiten Adressraums 3116 des BARO-Adressraums 3110 auf eine entsprechende Speicheradresse innerhalb des ersten Adressraums 3122 bzw. des zweiten Adressraums 3126 des privilegierten Registeradressraums 3120 zugegriffen. Im SMC-Modus sind die SMC-Grafikregister-Adressräume 3128(0) - 3128(7) vorgesehen, um auf die verschiedenen Komponenten innerhalb der jeweiligen SMC-Engines 700(0) - 700(7) zuzugreifen. Diese Komponenten umfassen, ohne Einschränkung, die Berechnung von FE 540(0) - 540(7), die Grafik FE 542(0) - 542(7), SKED 550(0) - 550(7), CWD 560(0) - 560(7) und PDA/PDB 562(0) - 562(7). Die GPCs 242 für eine bestimmte entsprechende SMC-Engine 700 sind einzeln adressierbar, abzüglich beliebiger GPCs 242, die aufgrund von Floor Sweeping entfernt wurden, über dedizierte Adressbereiche innerhalb des Alt-Grafikregister-Adressraums 3124. Zusätzlich oder alternativ dazu umfasst der Alt-Grafikregister-Adressraum 3124 einen Adressbereich zum gleichzeitigen Übertragen von Daten an alle GPCs 242 für eine bestimmte entsprechende SMC-Engine 700. Der BARO-Adressraum 3110 bietet zwei Mechanismen für den Zugriff auf die SMC-Grafikregister-Adressräume 3128(0) - 3128(7).
In einem ersten Mechanismus ordnet der Grafikregister-Adressraum 3114 des BARO-Adressraums 3110 einem der SMC-Grafikregister-Adressräume 3128(0) - 3128(7) im privilegierten Register-Adressraum 3120 zu. Eine bestimmte Adresse im BARO-Adressraum 3110 greift auf ein SMC-Fensterregister zu. Das SMC-Fensterregister umfasst zwei Felder. Diese beiden Felder umfassen ein SMC-Aktivierungsfeld und ein SMC-Indexfeld. Das SMC-Aktivierungsfeld umfasst einen binären Logikwert, der entweder FALSE oder TRUE ist. Wenn das SMC-Aktivierungsfeld FALSE ist, dann greift BARO-Adressraum 3110 auf den privilegierten Register-Adressraum 3120 im Alt-Adressierungsmodus zu, wie hier beschrieben. Wenn das SMC-Freigabefeld WAHR ist, dann greift der BARO-Adressraum 3110 auf den privilegierten Register-Adressraum 3120 im SMC-Adressierungsmodus zu, basierend auf den Werten des SMC-Indexfeldes. Der Wert des SMC-Indexfeldes spezifiziert, welche SMC-Engine 700 derzeit dem BARO-Adressraum 3110 zugeordnet ist. Wenn z.B. der Wert des SMC-Indexfeldes 0 ist, dann würde der SMC-Grafikregister-Adressraum 3128(0) des privilegierten Register-Adressraums 3120 dem Grafikregister-Adressraum 3114 des BARO-Adressraums 3110 zugeordnet werden. Wenn der Wert des SMC-Indexfeldes 1 ist, dann würde der SMC-Grafikregister-Adressraum 3128(1) des privilegierten Register-Adressraums 3120 dem Grafikregister-Adressraum 3114 des BARO-Adressraums 3110 zugeordnet werden, und so weiter. Durch ein Leiten eines Lese- oder Schreibzugriffs auf eine Speicheradresse in Richtung des Graphikregister-Adressraums 3114 des BARO-Adressraums 3110 wird auf eine entsprechende Speicheradresse innerhalb des durch das SMC-Indexfeld spezifizierten SMC-Graphikregister-Adressraums 3128 zugegriffen. Über diesen ersten Mechanismus ist der durch das SMC-Indexfeld spezifizierte SMC-Grafikregister-Adressraum 3128 für die SMC-Engine 700 zugänglich, während der Zugriff auf die übrigen SMC-Grafikregister-Adressräume 3128 verboten ist.
In einem zweiten Mechanismus sind einzelne Adressen innerhalb beliebiger SMC-Grafikregister-Adressräume 3128(0) - 3128(7) durch bestimmte privilegierte Komponenten, wie z.B. den Hypervisor 124, zugänglich. Dieser zweite Mechanismus greift auf die SMC-Grafikregister-Adressräume 3128(0) - 3128(7) über zwei bestimmte Adressen innerhalb des BARO-Adressraums 3110 zu. Eine der beiden Adressen greift auf ein SMC-Adressregister zu. Die andere der beiden Adressen greift auf ein SMC-Datenregister zu. Auf eine bestimmte Speicheradresse irgendwo innerhalb der SMC-Grafikregister-Adressräume 3128(0) - 3128(7) wird in zwei Schritten zugegriffen. In einem ersten Schritt wird das SMC-Adressregister mit einer Adresse beschrieben, die einer Adresse in den SMC-Grafikregister-Adressräumen 3128(0) - 3128(7) entspricht. In einem zweiten Schritt wird das SMC-Datenregister mit einem Datenwert gelesen oder geschrieben. Das Lesen oder Schreiben des SMC-Datenregisters im BARO-Adressraum 3110 bewirkt ein entsprechendes Lesen oder Schreiben in den privilegierten Register-Adressraum 3120 an der im SMC-Adressregister spezifizierten Speicheradresse. Das SMC-Adressregister wird dann dereferenziert, wodurch das SMC-Adressregister und das SMC-Datenregister für eine nachfolgende Transaktion freigegeben werden. Das Lesen oder Schreiben des SMC-Adressregisters führt nicht zu einem Lesen oder Schreiben des privilegierten Register-Adressraums 3120.
32 zeigt ein Flussdiagramm mit Verfahrensschritten zum Adressieren des privilegierten Registeradressraums in der PPU 200 von 2, gemäß verschiedenen Ausführungsbeispielen. Obwohl die Verfahrensschritte in Verbindung mit den Systemen der 1-17 beschrieben werden, werden Fachleute verstehen, dass jedes beliebige System, das konfiguriert sein kann, um die Verfahrensschritte in beliebiger Reihenfolge durchzuführen, in den Umfang der vorliegenden Offenbarung fällt.
Wie gezeigt, beginnt ein Verfahren 3200 mit Schritt 3202, in dem PPU 200 einen Speicherzugriff erkennt, der auf den privilegierten Registeradressraum 3120 gerichtet ist. Genauer gesagt, PPU 200 erkennt einen Speicherzugriff, der auf den BARO-Adressraum 3110 adressiert ist. In Schritt 3204 bestimmt PPU 200, ob der Speicherzugriff auf den Grafikregister-Adressraum 3114 gerichtet ist. Wenn der Speicherzugriff nicht auf den Graphikregister-Adressraum 3114 gerichtet ist, geht das Verfahren 3200 zu Schritt 3214 über, in dem PPU 200 eine Speichertransaktion an die durch den Speicherzugriff spezifizierte Adresse erzeugt. Das Verfahren 3200 wird dann beendet.
Zurück zu Schritt 3204: Wenn der Speicherzugriff auf den Grafikregister-Adressraum 3114 gerichtet ist, geht das Verfahren 3200 zu Schritt 3206 über, in dem PPU 200 bestimmt, ob der Speicherzugriff im Alt-Modus erfolgt. Wenn sich der Speicherzugriff im Alt-Modus erfolgt, dann fährt das Verfahren 3200 mit Schritt 3214 fort, in dem PPU 200 eine Speichertransaktion an der durch den Speicherzugriff spezifizierten Adresse erzeugt. Die Methode 3200 wird dann beendet. Wenn sich der Speicherzugriff dagegen nicht im Alt-Modus befindet, fährt das Verfahren 3200 mit Schritt 3208 fort, in dem PPU 200 bestimmt, ob sich der Speicherzugriff im Fenster-Modus befindet.
Wenn der Speicherzugriff im Fenster-Modus erfolgt, geht das Verfahren zu Schritt 3212 über, in dem PPU 200 eine Speichertransaktion basierend auf dem Wert des im SMC-Fensterregister spezifizierten SMC-Indexfeldes erzeugt. Der Wert des SMC-Indexfelds spezifiziert, welche SMC-Engine 700 derzeit dem BARO-Adressraum 3110 zugeordnet ist. Wenn z.B. der Wert des SMC-Indexfeldes 0 ist, dann würde der SMC-Grafikregister-Adressraum 3128(0) des privilegierten Register-Adressraums 3120 dem Grafikregister-Adressraum 3114 des BARO-Adressraums 3110 zugeordnet werden. Wenn der Wert des SMC-Indexfeldes 1 ist, dann würde der SMC-Grafikregister-Adressraum 3128(1) des privilegierten Register-Adressraums 3120 dem Grafikregister-Adressraum 3114 des BARO-Adressraums 3110 zugeordnet werden, und so weiter. Das Richten eines Speicher-Lese- oder Schreibzugriffs auf eine Speicheradresse in Richtung des Graphikregister-Adressraums 3114 des BARO-Adressraums 3110 greift auf eine entsprechende Speicheradresse innerhalb des durch das SMC-Indexfeld spezifizierten SMC-Graphikregister-Adressraums 3128 zu. Über diesen ersten Mechanismus ist der durch das SMC-Indexfeld spezifizierte SMC-Grafikregister-Adressraum 3128 für die SMC-Engine 700 zugänglich, während der Zugriff auf die übrigen SMC-Grafikregister-Adressräume 3128 verboten ist. Das Verfahren 3200 wird dann beendet.
Zurück zu Schritt 3208: Wenn sich der Speicherzugriff nicht im Fenster-Modus befindet, geht das Verfahren zu Schritt 3210 über, wo PPU 200 eine Speichertransaktion basierend auf den Werten des SMC-Adressregisters und des SMC-Datenregisters erzeugt. Genauer gesagt greift PPU 200 auf die SMC-Grafikregister-Adressräume 3128(0) - 3128(7) über zwei bestimmte Adressen innerhalb des BARO-Adressraums 3110 zu. Eine der beiden Adressen greift auf ein SMC-Adressregister zu. Die andere der beiden Adressen greift auf ein SMC-Datenregister zu. Auf eine bestimmte Speicheradresse irgendwo innerhalb der SMC-Grafikregister-Adressräume 3128(0) - 3128(7) wird in zwei Schritten zugegriffen. In einem ersten Schritt wird das SMC-Adressregister mit einer Adresse beschrieben, die einer Adresse in den SMC-Grafikregister-Adressräumen 3128(0) - 3128(7) entspricht. In einem zweiten Schritt wird das SMC-Datenregister mit einem Datenwert gelesen oder geschrieben. Das Lesen oder Schreiben des SMC-Datenregisters im BARO-Adressraum 3110 bewirkt ein entsprechendes Lesen oder Schreiben in den privilegierten Register-Adressraum 3120 an der im SMC-Adressregister spezifizierten Speicheradresse. Das SMC-Adressregister wird dann dereferenziert, wodurch das SMC-Adressregister und das SMC-Datenregister für eine nachfolgende Transaktion freigegeben werden. Das Lesen oder Schreiben des SMC-Adressregisters führt nicht zu einem Lesen oder Schreiben des privilegierten Registeradressraums 3120. Das Verfahren 3200 wird dann beendet.
Leistungsüberwachung mit mehreren SMC-Engines
Wie hier weiter erörtert, überwachen Leistungsmonitore (engl. performance monitors, PMs), wie PM 236 in 2, PM 360 in 3 und PM 430 in 4, die Gesamtleistung und/oder den Ressourcenverbrauch der entsprechenden Komponenten, die in der PPU 200 enthalten sind. Die Leistungsmonitore (PMs) sind in einem Leistungsüberwachungssystem enthalten, das eine Leistungsüberwachung und Profilerstellung über mehrere SMC-Engines 700 hinweg ermöglicht. Das Leistungsüberwachungssystem erstellt gleichzeitig oder im Wesentlichen gleichzeitig Profile für mehrere VMs und Verarbeitungskontexte, die in den VMs ausgeführt werden. Das Leistungsüberwachungssystem isoliert die mehreren VMs und mehrere Verarbeitungskontexte, die in den VMs ausgeführt werden, voneinander hinsichtlich der Art und Weise, wie Leistungsdaten erzeugt und erfasst werden, um ein Vermischen von Leistungsdaten zwischen den VMs zu verhindern. PMs 232 und assoziierte Zähler innerhalb des Leistungsdaten-Überwachungssystems verfolgen eine Zuschreibung von Leistungsdaten zu bestimmten SMC-Engines 700. Im Falle gemeinsam genutzter Ressourcen und Einheiten, bei denen die Zuweisung nicht zu einer bestimmten SMC-Engine 700 zurückverfolgt werden kann, erfasst ein Gerät mit einer höher privilegierten Einheit, wie z.B. der Hypervisor 124, Leistungsdaten für die gemeinsam genutzten Ressourcen und Einheiten. Das Leistungsüberwachungssystem erstellt simultan Profile von Rechen-Engines und Grafik-Engines und erstellt Profile von VMs, wenn die VMs zu anderen PPU-Partitionen 600 und/oder anderen PPUs 200 migrieren. Das Leistungsüberwachungssystem wird im Folgenden beschrieben.
33 zeigt ein Blockdiagramm eines Leistungsüberwachungssystems 3300 für die PPU 200 von 2, gemäß verschiedenen Ausführungsbeispielen. Wie gezeigt, umfasst das Leistungsüberwachungssystem 3300 ohne Einschränkung einen Leistungsmonitor 3310, Auswahlmultiplexer 3320, einen Überwachungsbus 3330 und Leistungs-Multiplexer-Einheiten 3340. Zusammen bilden der Leistungsmonitor 3310 und die Auswahlmultiplexer 3320 ein Leistungsmonitor-Modul (PMM). Jeder GPC 242, jede Partitionseinheit 262 und jede Sys-Pipe 230 umfasst mindestens ein PMM. Die Leistungs-Multiplexer-Einheiten 3340 sind in jeder Einheit, die überwacht wird, enthalten. Die Logik innerhalb der Leistungs-Multiplexer-Einheiten 3340 ist in einer oder mehreren der Einheiten FE 540, SKED 550, CWD 560 und/oder anderen geeigneten Funktionseinheiten enthalten. Wie hier weiter beschrieben, kommunizieren alle Komponenten der verschiedenen Leistungsüberwachungs-Aggregationssysteme 3300 mit einem Leistungsüberwachungs-Aggregator (in 33 nicht dargestellt). Das Leistungsüberwachungssystem 3300 hat im Wesentlichen die gleiche Funktionalität wie PM 236 in 2, PM 360 in 3 und PM 430, außer wie weiter unten weiter beschrieben.
Im Betrieb ermöglichen die Leistungs-Multiplexer-Einheiten 3340(0) - 3340(P) eine programmierbare Auswahl von Signalgruppen innerhalb der PPU 200, die von einem entsprechenden Leistungsmonitor 3340 überwacht werden können. Jeder Leistungs-Multiplexer 3340 kann eine Gruppe von Signalen auswählen, die an den Überwachungsbus 3330 übertragen wird. Ein Teilsatz der Signale vom Überwachungsbus 3330 wird zur Überwachung durch Auswahlmultiplexer 3320 ausgewählt. Signale vom Überwachungsbus 3330, die nicht über Auswahlmultiplexer 3320 ausgewählt werden, werden nicht überwacht. Signale von innerhalb der PPU 200 werden mit den Leistungs-Multiplexer-Einheiten 3340(0) - 3340(P) zu Gruppen verbunden, so dass jeweils eine Gruppe für die Überwachung ausgewählt werden kann. Leistungs-Multiplexer-Einheit 3340 multiplext die Signale so, dass die Signale in einer bestimmten Signalgruppe als Gruppe ausgewählt werden können. Die ausgewählten Eingaben für die in der Einheit 3340 enthaltenen Auswahlmultiplexer werden über ein oder mehrere Register programmiert, die im privilegierten Registeradressraum 3120 enthalten sind. Folglich sind die bestimmten Signale, die von der Leistungs-Multiplexer-Einheit 3340 an den Überwachungsbus 3330 übertragen werden, programmierbar.
Der Überwachungsbus 3330 empfängt Signalgruppen von den Leistungs-Multiplexer-Einheiten 3340(0) - 3340(P). Jedes an den Überwachungsbus 3330 übertragene Signal wird als Eingabe mit jedem der Auswahlmultiplexer 3320 verbunden.
Die Auswahlmultiplexer 3320 umfassen einen Satz einzelner Multiplexer 3322(0) - 3322(M) und 3324(0) - 3324(N). Die Eingangsseite jedes Multiplexers 3322(0) - 3322(M) und 3324(0) - 3324(N) empfängt alle Signale vom Überwachungsbus 3330 und wählt ein Signal zur Übertragung aus. Die Eingaben für die Auswahlmultiplexer 3322(0) - 3322(M) und 3324(0) - 3324(N) werden über ein oder mehrere Register programmiert, die im privilegierten Registeradressraum 3120 enthalten sind. Folglich ist der Satz bestimmter Signale, die von Auswahlmultiplexern 3320 übertragen werden, programmierbar. Die Auswahlmultiplexer 3320 übertragen die ausgewählten Signale an den Leistungsmonitor 3310.
Die einzelnen PPU-Signale, die vom Leistungsmonitor 3310 überwacht werden, sind als Ergebnis der Zusammensetzung aus programmierbaren Leistungs-Multiplexer-Einheiten 3340 und programmierbaren Auswahlmultiplexern 3320 programmierbar.
Der Leistungsmonitor 3310 umfasst ein Leistungszähler-Array 3312, ein Schattenzähler-Array (engl. shadow counter array) 3314 und eine Auslöserfunktionstabelle 3316. Der Leistungsmonitor 3310 empfängt Signale, die von Auswahlmultiplexern 3320 übertragen werden. Genauer gesagt empfängt das Schattenzähler-Array 3314 Signale, die von den Multiplexern 3322(0) - 3322(M) übertragen werden. In ähnlicher Weise empfängt die Auslöserfunktionstabelle 3316 Signale, die von den Multiplexern 3324(0) - 3324(N) übertragen werden. Wie weiter beschrieben, werden die Zähler innerhalb des Schattenzähler-Arrays 3314 basierend auf den von den Multiplexern 3322(0) - 3322(M) empfangenen Signalen und auf verschiedenen Auslöserbedingungen aktualisiert. Im Allgemeinen umfasst das Schattenzähler-Array 3314 einen Satz von einem oder mehreren Signalzählern, wobei jeder Zähler immer dann inkrementiert wird, wenn sich ein von einem entsprechenden Multiplexer 3322 empfangenes Signal in einem bestimmten logischen Zustand befindet. Die Werte im Schattenzähler-Array 3314 werden basierend auf bestimmten Signalen in Form von Auslöserbedingungen an das Leistungszähler-Arrat 3312 übertragen. DasLeistungszähler-Array 3312 umfasst einen Satz von einem oder mehreren Signalzählern, die den im Schattenzähler-Array enthaltenen Signalzählern entsprechen.
In einer Betriebsart werden die Zähler im Schattenzähler-Array 3314 nach der Übertragung an das Leistungszähler-Array 3312 auf Null zurückgesetzt, so dass die im Schattenzähler-Array 3314 gespeicherten Schattenzähler-Werte immer der Aktivität seit dem vorherigen Auslöser (engl. trigger) entsprechen.
Der Leistungsmonitor 3310 ist nach verschiedenen Zählmodi konfigurierbar, die die Anzahl der Zähler umfassen, die im Leistungszähler-Array 3312 und im Schattenzähler-Array 3314 enthalten sind. Die Zählmodi definieren weiter, wie und wann Leistungszähler-Array 3312 und Schattenzähler-Array 3314 ausgelöst werden und wie Daten vom Leistungszähler-Array 3312 an andere Geräte innerhalb der PPU 200 übertragen werden. Diese verschiedenen Zählmodi können in zwei Hauptleistungsüberwachungsmodi gruppiert werden - Nicht-Streaming-Leistungsüberwachung und Streaming-Leistungsüberwachung.
Im Nicht-Streaming-Leistungsüberwachungsmodus ist die Auslöserfunktionstabelle 3316 (engl. trigger function table) so programmiert, dass sie von den Multiplexern 3324(0) - 3324(N) empfangene Signale gemäß bestimmten spezifizierten logischen Signalausdrücken kombiniert. Wenn die Bedingungen eines oder mehrerer dieser logischen Signalausdrücke erfüllt sind, sendet die Auslöserfunktionstabelle 3316 ein Signal in Form des Logikauslösers 3350 (engl. logic trigger) an das Leistungszähler-Array 3312. In Reaktion auf den Empfang des Logikauslösers 3350 tastet das Leistungszähler-Array 3312 die aktuellen Werte ab und speichert sie im Schattenzähler-Array 3314. Die Werte im Leistungszähler-Array 3312 sind dann über den privilegierten Registeradressraum 3120 lesbar.
Im Streaming-Leistungsüberwachungsmodus überträgt ein Leistungsüberwachungs-Aggregator (PMA) ein Signal in Form eines PMA-Auslösers 3352 an das Leistungszähler-Array 3312. In Reaktion auf den Empfang des PMA-Auslösers 3352 tastet das Leistungszähler-Array 3312 die aktuellen Werte ab und speichert sie im Schattenzähler-Array 3314. Der Leistungsmonitor 3310 erzeugt Leistungsmonitor-(PMM-)Datensätze, die unter anderem die Werte in Leistungszähler-Array 3312 zum Zeitpunkt des Empfangs des PMA-Auslösers 3352 vom PMA, eine Zählung der Gesamtzahl der PMA-Auslöser, auf die der Leistungsmonitor 3310 reagiert hat, eine SMC-Engine-ID und eine PMM-ID umfassen können, die das PMM, das den Datensatz im System erzeugt hat, eindeutig identifiziert. Diese PMM-Aufzeichnungen werden dann an einen PMM-Router übertragen, der mit einem oder mehreren Leistungsmonitoren 3310 assoziiert ist. Der PMM-Router wiederum überträgt die PMM-Sätze an den PMA. In einigen Ausführungsbeispielen kann die PMM-ID für jeden Leistungsmonitor 3310 über ein oder mehrere Register programmiert werden, die im Adressraum 3120 des privilegierten Registers enthalten sind.
Im Allgemeinen befindet sich ein bestimmter Leistungsmonitor 3310 in einem bestimmten Leistungsüberwachungssystem 3300 in PPU 200 innerhalb desselben Taktfrequenzbereichs wie die Signale, die von diesem bestimmten Leistungsmonitor 3310 überwacht werden. Ein bestimmter Leistungsmonitor 3310 kann jedoch innerhalb derselben Taktfrequenzdomäne oder innerhalb einer anderen Taktfrequenzdomäne im Vergleich zu einem anderen Leistungsmonitor in PPU 200 liegen.
Verschiedene Konfigurationen von Leistungs-Multiplexer-Einheiten 3340 werden im Folgenden beschrieben.
Die 34A-34B zeigen verschiedene Konfigurationen der Leistungsmultiplexer-Einheiten 3340 aus 33, gemäß verschiedenen Ausführungsbeispielen.
Wie in 34A dargestellt, umfasst eine erste Konfiguration einer Leistungs-Multiplexer-Einheit 3340(0) ohne Einschränkung die Signalgruppen A 3420(0) - 3420(P), die Signalgruppen B 3430(0) - 3430(Q) sowie die Multiplexer 3412(0) und 3412(1). Im Betrieb wählt der Auswahlmultiplexer 3412(0) eine der Signalgruppen A 3420(0) - 3420(P) aus, wobei jede der Signalgruppen A 3420(0) - 3420(P) eine Untergruppe innerhalb einer größeren Signalgruppe C ist. Der Auswahlmultiplexer 3412(0) wählt eine der Signalgruppen A 3420(0) - 3420(P) aus und überträgt die ausgewählte Signalgruppe an den Überwachungsbus 3330. In ähnlicher Weise wählt der Auswahlmultiplexer 3412(1) eine der Signalgruppen B 3430(0) - 3430(Q) aus, wobei jede der Signalgruppen B 3430(0) - 3430(Q) eine Untergruppe innerhalb einer größeren Signalgruppe D ist. Auswahlmultiplexer 3412(1) wählt eine der Signalgruppen B 3430(0) - 3430(Q) aus und überträgt die ausgewählte Untergruppe an den Überwachungsbus 3330. Die in der Leistungs-Multiplexer-Einheit 3340(0) enthaltenen Auswahlmultiplexer 3412(1) werden über ein oder mehrere Register programmiert, die im privilegierten Registeradressraum 3120 enthalten sind. Folglich ist der Satz von Signalen, die von der Leistungs-Multiplexer-Einheit 3340(0) übertragen werden, programmierbar.
Wie in 34B dargestellt, umfasst eine zweite Konfiguration einer Leistungs-Multiplexer-Einheit 3340(1) ohne Einschränkung die Signalgruppen C 3440(0) - 3440(R) und Multiplexer 3412(2). Im Betrieb wählt der Auswahlmultiplexer 3412(2) eine der Signalgruppen C 3440(0) - 3440(R) aus, wobei jede der Signalgruppen C 3440(0) - 3440(R) eine Untergruppe innerhalb einer größeren Signalgruppe E ist. Der Auswahlmultiplexer 3412(2) wählt eine der Signalgruppen C 3440(0) - 3440(R) aus und überträgt die ausgewählte Signalgruppe an den Überwachungsbus 3330. In der Konfiguration von Leistungs-Multiplexer-Einheiten 3340(1) werden mehrere Signale an mehrere Signalgruppen übertragen. Insbesondere wird das Signal C1 3450 sowohl an die Signalgruppe C 3440(0) als auch an die Signalgruppe C 3440(1) übertragen. In ähnlicher Weise wird das Signal C2 3452 sowohl an die Signalgruppe C 3440(1) als auch an die Signalgruppe C 3440(2) übertragen. Die in der Leistungs-Multiplexer-Einheit 3340(1) enthaltenen Auswahlmultiplexer-Eingänge zum Multiplexer 3412(2) werden über ein oder mehrere Register programmiert, die im privilegierten RegisterAdressraum 3120 enthalten sind. Folglich ist der Satz von Signalen, die von der Leistungs-Multiplexer-Einheit 3340(1) übertragen werden, programmierbar. Die Konfiguration der Leistungs-Multiplexer-Einheit 3340(1) kann nützlich sein, wenn die Bereitstellung von Signalen in mehreren Signalgruppen 3440 die Sichtbarkeit bestimmter Signalgruppen in einem einzigen Durchgang des Leistungsüberwachungssystems 3300 erleichtert.
35 zeigt ein Blockdiagramm eines Leistungsüberwachungs-Aggregationssystems 3500 für PPU 200 aus 2, gemäß verschiedenen Ausführungsbeispielen. Wie gezeigt, umfasst das Leistungsüberwachungs-Aggregationssystem 3500 ohne Einschränkung die GPCs 242(0) - 242(M), Partitionseinheiten 262(0) - 262(N), eine Crossbar-Einheit 250, einen Steuerungs-Crossbar und SMC-Arbiter 510, ein PM-Managementsystem 3530 und ein Leistungsüberwachungs-Analysesystem 3540.
Im Betrieb führen die GPCs 242(0) - 242(M) verschiedene Verarbeitungsaufgaben für eine oder mehrere Sys-Pipes 230 aus. Jeder GPC 242 umfasst mehrere parallele Verarbeitungskerne, die in der Lage sind, eine große Anzahl von Threads gleichzeitig und mit beliebigem Grad von Unabhängigkeit und/oder Isolierung von anderen GPCs 242 auszuführen. Jeder der GPCs 242(0) - 242(M) umfasst einen oder mehrere PMs 360(0) - 360(M) und einen GPC-PMM-Router 3514(0) - 3514(M). Die Funktionalität der PMs 360(0) - 360(M) ähnelt im Wesentlichen der des Leistungsmonitors 3310 in 33. Die PMs 360(0) - 360(M) erzeugen PMM-Datensätze, die Leistungsdaten für die entsprechenden GPCs 242(0) - 242(M) umfassen. Die PMs 360(0) - 360(M) senden diese PMM-Aufzeichnungen an die entsprechenden GPC-PMM-Router 3514(0) - 3514(M) und empfangen Daten von diesen. Die GPC-PMM-Router 3514(0) - 3514(M) übertragen die PMM-Datensätze über die Crossbar-Einheit 250 an das PM-Management-System 3530.
Die Partitionseinheiten 262(0) - 262(N) bieten Speicherzugriff mit hoher Bandbreite auf DRAMS innerhalb des PPU-Speichers (nicht in 35 dargestellt). Jede Partitionseinheit 262 führt Speicherzugriffsoperationen mit einem anderen DRAM parallel zueinander aus, wodurch die verfügbare Speicherbandbreite des PPU-Speichers effizient genutzt wird. Jede der Partitionseinheiten 262(0) - 262(N) umfasst einen oder mehrere PMs 430(0) - 430(N) und einen PMM-Router 3524(0) - 3524(N) der Partitionseinheit (PU). Die Funktionalität der PMs 430(0) - 430(N) ähnelt im Wesentlichen der des Leistungsmonitors 3310 in 33. Die PMs 430(0) - 430(N) erzeugen PMM-Datensätze, die Leistungsdaten für die entsprechenden Partitionseinheiten 262(0) - 262(N) umfassen. Die PMs 430(0) - 430(N) senden diese PMM-Datensätze an die entsprechenden PU-PMM-Router 3524(0) - 3524(N) und empfangen Daten von diesen. Die PU-PMM-Router 3524(0) - 3524(N) übertragen ihrerseits die PMM-Sätze über den Steuerungs-Crossbar und SMC-Arbiter 510 an das PM-Managementsystem 3530.
Das PM-Managementsystem 3530 steuert die Sammlung von PMM-Aufzeichnungen und speichert die PMM-Aufzeichnungen zu Berichtszwecken. Das PM-Managementsystem 3530 umfasst, ohne Einschränkung, Systemleistungsüberwachungs-Monitore 3532, einen System (SYS)-PMM-Router 3534, einen Leistungsüberwachungs-Aggregator (PMA) 3536, einen Hochgeschwindigkeits-Hub (HSHUB) und die Übertragungslogik 3539.
Die Funktionalität der System PMs 3532 ähnelt im Wesentlichen der des Leistungsmonitors 3310 aus 33. Die System PMs 3532 erzeugen PMM-Datensätze, die Leistungsdaten für systemweite Komponenten umfassen, die nicht in einer bestimmten GPC 242 oder Partitionseinheit 262 enthalten sind. Die System-PMs 3532 senden diese PMM-Aufzeichnungen an den System-PMM-Router 3534 und empfangen Daten von diesem. Der System-PMM-Router 3534 wiederum überträgt die PMM-Datensätze an den PMA 3536.
PMA 3536 erzeugt Auslöser (Trigger) für die verschiedenen Leistungsmonitore, einschließlich PMs 360(0) - 360(M), PMs 430(0) - 430(N) und System PMs 3532. PMA 3536 erzeugt diese Auslöser mittels zweier Techniken. Bei der ersten Technik erzeugt PMA 3536 Auslöser in Reaktion auf Signale, die von jeder der Sys-Pipes 230 gesendet werden, wenn die Sys-Pipes 230 Befehle von der Host-Schnittstelle 220 empfangen. Bei einer zweiten Technik erzeugt PMA 3536 Auslöser, indem es periodisch programmgesteuerte Auslöserimpulse an die PMs sendet. Im Allgemeinen enthält das Leistungsüberwachungs-Aggregationssystem 3500 mindestens einen programmierbaren Auslöserimpulsgenerator, der jeder Sys-Pipe 230 entspricht, zusätzlich zu einem weiteren Auslöserimpulsgenerator, der von jeder beliebigen Sys-Pipe 230 unabhängig ist. PMA 3536 überträgt die Auslöser an die GPC-PMM-Router 3514(0) - 3514(M) und die PU-PMs 3524(0) - 3524(N) über den Steuerungs-Crossbar und SMC-Arbiter 510. PMA 3536 überträgt die Auslöser an den PMM-Router 3534 des Systems direkt über eine interne Kommunikationsverbindung zum PM-Managementsystem 3530. Die PMM-Router übertragen die PMA-Auslöser an die entsprechenden PMs. In einigen Ausführungsbeispielen haben diese Auslöser die Form von Auslösepaketen, die nachstehend in Verbindung mit 36 beschrieben werden.
36 zeigt das Format der Auslöserpakete, die mit dem Leistungsüberwachungs-Aggregationssystem 3500 von 3500 assoziiert sind, gemäß verschiedenen Ausführungsbeispielen. Der Zweck der Auslöserpakete besteht darin, Informationen über die Quelle des Auslösers an die Leistungsmonitore 3310 zu übermitteln. Jeder der Leistungsmonitore 3310 verwendet diese Informationen, um zu bestimmen, ob er auf einen bestimmten Auslöser reagieren soll oder nicht. In dieser Hinsicht enthalten die Auslöserpakete Informationen, die von jedem Leistungsmonitor 3310 verwendet werden können, um zu bestimmen, ob auf ein bestimmtes Auslöserpaket reagiert werden soll oder nicht. Jeder Leistungsmonitor 3310, der mit einer bestimmten SMC-Engine 700 assoziiert ist, wird mit einer SMC-Engine-ID programmiert, die der SMC-Engine 700 entspricht. Ein solcher Leistungsmonitor 3310 reagiert auf Auslöserpakete pro SMC-Engine, die die gleiche SMC-Engine-ID umfassen. Jeder Leistungsmonitor 3310, der nicht mit einer bestimmten SMC-Engine 700 assoziiert ist oder mit einer ungültigen SMC-Engine-ID programmiert ist, reagiert nicht auf Auslöserpakete pro SMC. Stattdessen reagieren solche Leistungsmonitore 3310 auf gemeinsame Auslöserpakete.
Das Diagramm 3600 zeigt das allgemeine Format der Auslöserpakete. Wie gezeigt, umfasst Diagramm 3600 einen Pakettyp 3602, der anzeigt, dass es sich bei dem Paket um einen PM-Auslöser handelt, einen Auslösertyp 3604 und eine Auslösernutzlast 3606. Der PM-Auslösertyp 3604 ist ein Aufzählungswert, der den Typ des Auslöserformats identifiziert. Um beispielsweise drei verschiedene Auslöserpakettypen zu identifizieren, könnte der PM-Auslösertyp 3604 ein 2-Bit-Wert sein. Die Auslösernutzlast 3606 umfasst Daten, die sich basierend auf dem PM-Auslösertyp 3604 unterscheiden. Es werden nun drei verschiedene Typen von Auslöserpaketen beschrieben, wobei die drei Typen von Auslöserpaketen den drei Kategorien von Leistungsüberwachungsdaten entsprechen (Alt-Daten, Pro-SMC-Daten und gemeinsam genutzte Daten).
Diagramm 3610 zeigt das Format der Auslöserpakete. Alt-Auslöserpakete umfassen einen Pakettyp 3602, der anzeigt, dass das Paket ein PM-Auslöser ist, und einen Auslösertyp 3614, der anzeigt, dass das Auslöserpaket ein Alt-Auslöserpaket ist. Die Auslösernutzlast 3606 des Alt-Auslöserpakets umfasst ein unbenutztes Feld 3616.
Diagramm 3620 zeigt das Format der Pro-SMC-Auslöserpakete (d.h. auf einen jeweiligen SMC bezogen). Pro-SMC-Auslöserpakete umfassen einen Pakettyp 3602, der angibt, dass das Paket ein PM-Auslöser ist, und einen Auslösertyp 3624, der angibt, dass das Auslöserpaket ein SMC-Auslöserpaket ist. Die Auslösernutzlast 3606 (engl. trigger payload) des Pro-SMC-Auslöserpakets umfasst ein SMC-Engine-ID-Feld. Das SMC-Engine-ID-Feld 3626 identifiziert die Engine 700, auf die sich der Auslöser bezieht.
Diagramm 3630 zeigt das Format von gemeinsam genutzten Auslöserpaketen. Gemeinsam genutzte Auslöserpakete umfassen einen Pakettyp 3602, der anzeigt, dass das Paket ein PM-Auslöser ist, und einen Auslösertyp 3634, der anzeigt, dass das Auslöserpaket ein gemeinsam genutztes Auslöserpaket ist. Die Auslösernutzlast 3606 des gemeinsamen Auslöserpakets umfasst ein unbenutztes Feld.
Der Typ des von dem PMA 3536 gesendeten Auslöserpakets wird durch die Quelle des Auslösers und ein oder mehrere Register bestimmt, die im privilegierten Registeradressraum 3120 entsprechend jeder Auslöserquelle enthalten sind und so programmiert sind, dass sie den Auslöserpakettyp angeben, den PMA für diese Quelle senden soll. In einer Betriebsart ist der PMA so programmiert, dass Auslöserpakete, die in Reaktion auf eine Quelle erzeugt werden, die mit einer SMC-Engine assoziiert ist, Pro-SMC-Auslöserpakete sind, wobei die SMC-Engine-ID auf die entsprechende SMC-Engine gesetzt ist, und Auslöserpakete, die in Reaktion auf Quellen erzeugt werden, die nicht mit einer SMC-Engine assoziiert sind, gemeinsam genutzte Auslöserpakete sind. Auslöserpakete können mit jeder technisch geeigneten Rate erzeugt werden, bis zu einem Auslöserpaket pro Rechenzyklus, das ein Auslöserpaket pro Rechenzyklus umfasst.
In Reaktion auf den Empfang eines Auslöserpakets von PMA 3536 prüft jeder PM den Auslösertyp und die Auslösernutzlast, um festzustellen, ob der PM-Auslöser auf den Auslöser reagieren soll. Jeder PM-Auslöser reagiert bedingungslos auf Alt-Auslöserpakete. Bei Pro-SMC-Auslöserpaketen antwortet das PM nur, wenn die in der Auslöser-Nutzlast enthaltene SMC-Engine-ID mit der SMC-Engine-ID übereinstimmt, die dem PM durch Programmierung eines registerprivilegierten Register-Adressraums 3120 zugewiesen wurde. Die Programmierung einer ungültigen SMC-Engine-ID in diesem Register stellt sicher, dass das PM nicht auf Pro-SMC-Auslöserpakete reagiert. Bei gemeinsamen Auslöserpaketen antwortet das PM nur, wenn das PM über ein Register im privilegierten Registeradressraum 3120 entsprechend programmiert wurde. In einer Betriebsart sind alle PMs, bei denen es sich um Überwachungseinheiten handelt, die eindeutig einer SMC-Engine zugeordnet sind, so programmiert, dass sie auf Pro-SMC-Auslöserpakete mit der entsprechenden SMC-Engine-ID-Nutzlast reagieren, und alle anderen PMs sind so programmiert, dass sie auf gemeinsame Auslöserpakete, nicht aber auf Pro-SMC-Auslöserpakete reagieren.
Für den Fall, dass ein PM feststellt, dass eine Reaktion auf den Auslöser gerechtfertigt ist, entnimmt der PM die in dem jeweiligen PM enthaltenen Zähler. Die antwortenden PMs übermitteln dann PMM-Datensätze, die abgetastete Zählerwerte, die Gesamtzahl der Auslöser, auf die geantwortet wurde, die dem PM zugeordnete SMC-Engine ID und die PMM-ID umfassen, die das PM innerhalb des Systems eindeutig identifiziert. Die PMM-Router, PMA 3536, und/oder das Leistungsanalysesystem 3540 verwenden die PMM-ID, um zu identifizieren, welcher PM den entsprechenden PMM-Datensatz übertragen hat. Die PMM-Router übertragen diese Datensätze dann an PMA 3536. Genauer gesagt übertragen die GPC-PMM-Router 3514(0) - 3514(M) PMM-Datensätze über die Crossbar-Einheit 250 und den Hochgeschwindigkeits-Hub 3538 an PMA 3536. Die PU-PMM-Router 3524(0) - 3524(N) übertragen PMM-Datensätze über den Steuerungs-Crossbar und SMC-Arbiter 510 an PMA 3536. Der System-PMM-Router 3534 überträgt PMM-Datensätze direkt über eine interne Kommunikationsverbindung zum PM-Managementsystem 3530. Auf diese Weise empfängt PMA 3536 PMM-Einträge von allen relevanten PMs in PPU 200.
In einigen Ausführungsbeispielen erzeugt der PMA 3536 bei der Übermittlung eines Auslösers zusätzlich PMA-Einträge. Im Allgemeinen besteht der Zweck eines PMA-Eintrags darin, zu einem Zeitstempel aufzuzeichnen, bei dem ein bestimmter PMA-Auslöser erzeugt wird, und die entsprechenden PMM-Einträge von den Leistungsmonitoren 3310, die auf den PMA-Auslöser zu diesem Zeitstempel geantwortet haben, zu assoziieren. Die PMA-Aufzeichnungen umfassen, ohne Einschränkung, einen Zeitstempel, eine SMC-Engine-ID, die mit der Quelle des PMA-Auslösers assoziiert ist, eine Gesamtzahl von Auslösern, die von Quellen mit derselben SMC-Engine-ID erzeugt wurden, und zugehörige Metadaten. Wenn die Leistungsmonitore 3310 einen Auslöser erhalten, erzeugen die Leistungsmonitore 3310 ebenfalls PMM-Datensätze mit einer Auslöserzählung. Anschließend können beim Parsen von PMA- und PMM-Einträgen PMM-Einträge mit einer bestimmten Auslöserzahl mit PMA-Einträgen mit derselben Auslöserzahl assoziiert werden. Auf diese Weise wird der den PMM-Einträgen entsprechende Zeitstempel basierend auf dem Zeitstempel des assoziierten PMA-Eintrags erstellt. Infolgedessen wird das Verhalten der PPU 200, das durch die PMM-Einträge widergespiegelt wird, genau mit einem Zeitbereich assoziiert, der durch zwei benachbarte PMA-Auslöser aus derselben Quelle begrenzt wird.
Beim Empfang von PMM-Einträgen und beim Erzeugen von PMA-Einträgen speichert PMA 3536 die PMM-Einträge und PMA-Einträge über den Hochgeschwindigkeits-Hub 3538 in einen Datenspeicher in Form eines Eintragspuffers im PPU-Speicher. Der Hochgeschwindigkeits-Hub 3538 überträgt die PMM-Einträge und PMA-Einträge an die Partitionseinheiten 262(0) - 262(N). Die Partitionseinheiten speichern dann die PMM-Einträge und PMA-Einträge im Eintragspuffer im PPU-Speicher. Zusätzlich oder alternativ überträgt der Hochgeschwindigkeits-Hub 3538 die PMM-Einträge und PMA-Einträge über die Transferlogik 3539 an das Leistungsanalysesystem 3540. In einigen Ausführungsbeispielen können der Hochgeschwindigkeits-Hub 3538, die Übertragungslogik 3539 und das Leistungsanalysesystem 3540 über eine PCIe-Verbindung miteinander kommunizieren. Ein Benutzer kann die PMM-Einträge und PMA-Einträge auf dem Leistungsanalysesystem 3540 anzeigen, um das Verhalten der PPU 200, wie es in den PMM-Einträgen wiedergegeben wird, zu charakterisieren. Das Leistungsanalysesystem 3540 sammelt PMM-Einträge und PMA-Einträge, die die gleiche Anzahl von Auslösern haben. Dann verwendet das Leistungsanalysesystem 3540 den Zeitstempel aus dem PMA-Eintrag und die Leistungsdaten aus den PMM-Einträgen mit derselben Auslöserzahl, um den mit den Leistungsdaten assoziierten Zeitstempel zu bestimmen. In einigen Ausführungsbeispielen kann das Leistungsanalysesystem 3540 als virtueller Speicher auf den Eintragspuffer zugreifen. Infolge der Platzierung von Leistungseintragspuffer in verschiedenen virtuellen Adressräumen können die Leistungsüberwachungsdaten für die verschiedenen SMC-Engines 700 voneinander isoliert sein, wie im Folgenden beschrieben.
Der PMA 3536 ermöglicht eine Isolierung der Leistungsüberwachungsdaten zwischen den verschiedenen SMC-Engines 700. Insbesondere sortiert PMA 3536 die PMM-Einträge und PMA-Einträge basierend auf der Betriebsart in Kategorien. Wenn die PPU 200 im Alt-Modus arbeitet, führt die PPU 200 die Aufgaben als ein einziger Cluster von Hardwareressourcen aus, und nicht als separate PPU-Partitionen 600 mit den separaten SMC-Engines 700. Im Alt-Modus speichert PMA 3536 PMM-Einträge und PMA-Einträge in einer einzigen Kategorie als einen einzigen Satz von Leistungsüberwachungsdaten. Wenn die PPU 200 im SMC-Modus arbeitet, führt die PPU 200 Aufgaben als separate PPU-Partitionen 600 mit separaten SMC-Engines 700 aus. Im SMC-Modus sortiert und speichert PMA 3536 PMM-Einträge und PMA-Einträge in verschiedenen Kategorien unter Verwendung des SMC-Engine-ID-Feldes der PMM-Einträge und PMA-Einträge. Datensätze mit jeder SMC-Engine-ID werden in einem separaten Datenspeicher in Form eines Eintragspuffers gespeichert, auf den über einen separaten virtuellen Adressraum zugegriffen werden kann, der mit der entsprechenden SMC-Engine 700 übereinstimmt. Wie oben beschrieben, enthalten PMM-Einträge und PMA-Einträge, die nicht zu einer bestimmten SMC-Engine 700 rückverfolgbar sind, eine ungültige SMC-Engine-ID. PMA speichert diese Datensätze in einem separaten Datenspeicher in Form eines Nicht-SMC-Eintragspuffers in einem virtuellen Adressraum, auf den jede autorisierte Einheit zugreifen kann, die über ausreichende Privilegien für den Zugriff auf die Daten aller SMC-Engines 700 verfügt. Solche autorisierten Einheiten umfassen, ohne Einschränkung, einen Hypervisor 124 in einer virtualisierten Umgebung und einen Root-Benutzer oder Betriebssystem-Kernel in einer nicht virtualisierten Umgebung. Jede SMC-Engine 700 kann auf einige oder alle Leistungsüberwachungsdaten im Nicht-SMC-PMA-Eintragspuffer zugreifen, indem sie die Daten von der autorisierten Einheit anfordert.
In einigen Ausführungsbeispielen ist der PMA 3536 so konfiguriert, dass Auslöser, die jeder SMC-Engine 700 entsprechen, erzeugt werden, so dass sie mit Kontext-Switch-Ereignissen für dieselbe SMC-Engine 700 zusammenfallen. In solchen Ausführungsbeispielen sind die PMs so konfiguriert, dass die Zähler im Schattenzähler-Array 3314 nach jedem Auslöser auf Null zurückgesetzt werden, so dass die von den PMs an das PMA 3536 übertragenen Daten für jede SMC-Engine-ID einem individuellen Kontext oder VM zugeordnet werden können, während das zeitliche Aufteilen aktiviert ist.
37 zeigt ein Flussdiagramm mit Verfahrensschritten zur Überwachung der Leistung der PPU 200 aus 2, gemäß verschiedenen Ausführungsbeispielen. Obwohl die Verfahrensschritte in Verbindung mit den Systemen der 1-23 beschrieben werden, werden Fachleute mit gewöhnlichen Fachkenntnissen verstehen, dass jedes beliebige System, das zur Durchführung der Verfahrensschritte in beliebiger Reihenfolge konfiguriert sein kann, unter den Umfang der vorliegenden Offenbarung fällt.
Wie gezeigt, beginnt ein Verfahren 3700 mit Schritt 3702, in dem PMA 3536 einen Auslöser erzeugt und an die PMs 3310 sendet. Weiter erzeugt PMA 3536 einen entsprechenden PMA-Datensatz, der einen Zeitstempel und, optional, eine SMC-Engine-ID umfasst, die der Quelle des Auslösers entspricht. Die PMs 3310 erhalten einen Auslöser zur Abtastung von Leistungsdaten.
In Schritt 3704 bestimmen die PMs 3310 in Reaktion auf den Empfang des Auslösers, ob eine Reaktion auf den Auslöser gerechtfertigt ist. Jeder PM 3310 prüft den Auslösertyp und die Auslösernutzlast aus dem Auslöserpaket, um festzustellen, ob der PM 3310 auf den Auslöser reagieren soll. Jeder PM 3310 antwortet bedingungslos auf Alt-Auslöserpakete. Bei Pro-SMC-Auslöserpaketen antwortet das PM 3310 nur dann, wenn die in der Auslösernutzlast enthaltene SMC-Engine-ID mit der SMC-Engine-ID übereinstimmt, die dem PM 3310 durch Programmierung eines Registers im privilegierten Registeradressraum 3120 zugewiesen wurde. Die Programmierung einer ungültigen SMC-Engine-ID in diesem Register stellt sicher, dass das PM 3310 nicht auf Pro-SMC-Auslöserpakete reagiert. Bei gemeinsamen Auslöserpaketen antwortet das PM 3310 nur dann, wenn das PM 3310 über ein Register im privilegierten Registeradressraum 3120 entsprechend programmiert wurde. In einer Betriebsart sind alle PMs 3310, die Überwachungseinheiten sind, die eindeutig einer SMC-Engine 700 zugeordnet sind, so programmiert, dass sie auf Pro-SMC-Auslöserpakete mit der entsprechenden SMC-Engine-ID-Nutzlast reagieren. Alle anderen PMs 3310 sind so programmiert, dass sie auf gemeinsame Auslöserpakete, aber nicht auf Pro-SMC-Auslöserpakete reagieren.
Wenn eine Antwort gerechtfertigt ist, nimmt das Leistungszähler-Array 3312 Abtastungen vor und speichert die aktuellen Werte im Schattenzähler-Array 3314. Im Nicht-Streaming-Modus können andere Komponenten die Werte in den Leistungszähler-Arrays über den privilegierten Register-Schnittstellen-Hub 512 lesen.
Im Streaming-Modus fährt das Verfahren mit Schritt 3706 fort, in dem PMs 3310 abgetastete Leistungsdaten sendet und PMA 3536 die abgetasteten Leistungsdaten von den PMs 3310 empfängt. Die PMs 3310 erzeugen PMM-Einträge, die die Werte im Leistungszähler-Array 3312 zum Zeitpunkt des Empfangs des PMA-Auslösers 3352 vom PMA 3536 umfassen. Diese PMM-Einträge werden dann an einen PMM-Router übertragen, der mit dem jeweiligen Leistungsmonitor 3310 assoziiert ist. Der PMM-Router wiederum überträgt die PMM-Einträge an PMA 3536.
In Schritt 3708 sortiert PMA 3536 die PMM-Einträge und PMA-Einträge basierend auf der Betriebsart in Kategorien. Wenn die PPU 200 im Alt-Modus arbeitet, sortiert PMA 3536 die PMM-Einträge und PMA-Einträge in einer einzigen Kategorie als einen einzigen Satz von Leistungsüberwachungsdaten. Wenn die PPU 200 im SMC-Modus arbeitet, sortiert PMA 3536 PMM-Einträge und PMA-Einträge in verschiedene Kategorien unter Verwendung des SMC-Engine-ID-Feldes der PMM-Einträge und PMA-Einträge. Wie oben beschrieben, enthalten PMM-Einträge und PMA-Einträge, die nicht zu einer bestimmten SMC-Engine 700 verfolgbar sind, eine ungültige SMC-Engine-ID. PMA 3536 sortiert diese PMM-Einträge und PMA-Einträge in eine separate Kategorie.
In Schritt 3710 speichert PMA 3536 die PMM-Einträge und/oder PMA-Einträge in einem PMA-Eintragspuffer in dem PPU-Speicher. Wenn PPU 200 im Alt-Modus arbeitet, speichert PMA 3536 PMM-Einträge und PMA-Einträge in einer einzigen Kategorie als einen einzigen Satz von Leistungsüberwachungsdaten. Wenn PPU 200 im SMC-Modus arbeitet, speichert PMA 3536 PMM-Einträge und PMA-Einträge, die jeder SMC-Engine-ID zugeordnet sind, in einem separaten Datenspeicher, auf den über einen separaten virtuellen Adressraum zugegriffen werden kann, der mit der entsprechenden SMC-Engine 700 verknüpft ist. PMA 3536 speichert PMM-Einträge und PMA-Einträge, die nicht zu einer bestimmten SMC-Engine 700 verfolgbar sind, in einem separaten Datenspeicher in Form eines Nicht-SMC-PMA-Eintragspuffers in einem virtuellen Adressraum, auf den nur jede beliebige autorisierte Einheit zugreifen kann, die über ausreichende Privilegien für den Zugriff auf die Daten aller SMC-Engines 700 verfügt. Solche autorisierten Einheiten umfassen, ohne Einschränkung, einen Hypervisor 124 in einer virtualisierten Umgebung und einen Root-Benutzer oder Betriebssystem-Kernel in einer nicht virtualisierten Umgebung. Jede SMC-Engine 700 kann auf einige oder alle Leistungsüberwachungsdaten im Nicht-SMC-PMA-Eintragspuffer zugreifen, indem sie die Daten von der autorisierten Einheit anfordert.
Genauer gesagt streamt PMA 3536 die PMM-Einträge und PMA-Einträge zum Hochgeschwindigkeits-Hub 3538. Der Hochgeschwindigkeits-Hub 3538 überträgt die PMM-Einträge und PMA-Einträge an die Partitionseinheiten 262(0) - 262(N). Die Partitionseinheiten speichern dann die PMM-Einträge und PMA-Einträge im PMA-Eintragspuffer im PPU-Speicher. Der PMA-Satzpuffer für jeden Datensatz wird basierend auf dem SMC-Engine-ID-Feld des Datensatzes so gewählt, dass sich jeder Datensatz letztlich im PPU-Speicher befindet, auf den in einem virtuellen Adressraum zugegriffen werden kann, der mit der SMC-Engine übereinstimmt, der dem PMA-Eintragspuffer entspricht. PMM-Einträge und PMA-Einträge, die nicht zu einer bestimmten SMC-Engine 700 verfolgbar sind, befinden sich in einem separaten Datenspeicher, auf den nur eine autorisierte Einheit Zugriff hat.
In Schritt 3712 überträgt PMA 3536 die PMA-Einträge und/oder PMM-Einträge über den Hochgeschwindigkeits-Hub 3538 und die Übertragungslogik 3539 an das Leistungsanalysesystem 3540. Zusätzlich oder alternativ greift das Leistungsanalysesystem 3540 über eine oder mehrere virtuelle Adressen in einem virtuellen Adressraum auf die PMA- und/oder PMM-Einträge zu. Im Allgemeinen umfasst das Leistungsanalysesystem 3540 eine Softwareanwendung, die auf CPU 110 und/oder einem beliebigen anderen technisch geeigneten Prozessor ausgeführt wird. Das Leistungsanalysesystem 3540 greift direkt auf den virtuellen Speicher zu, um auf die PMA- und/oder PMM-Einträge zuzugreifen. Der virtuelle Speicher kann mit PPU 200 und/oder CPU 110 assoziiert sein. Ein Benutzer kann die PMA- und/oder PMM-Einträge auf dem Leistungsanalysesystem 3540 ansehen, um das Verhalten der PPU 200 zu charakterisieren, wie es in den PMA- und/oder PMM-Einträgen wiedergegeben wird. Das Verfahren 3700 wird dann beendet.
Leistungs- und Taktfrequenzmanagement mit den SMC-Engines
Komplexe Systeme, wie z.B. PPU 200 in 2, können erhebliche Mengen an Energie verbrauchen. Genauer gesagt können bestimmte Komponenten innerhalb der PPU 200 zu verschiedenen Zeitpunkten einen unterschiedlichen Stromverbrauch haben. In einem Beispiel kann eine Komponente in einer PPU-Partition 600 rechen- und/oder grafikintensive Aufgaben ausführen und dadurch den Stromverbrauch im Vergleich zu anderen PPU-Partitionen 600 erhöhen. In einem anderen Beispiel kann eine PPU-Partition 600 aufgrund von Leckstrom und verwandten Faktoren auch im Leerlauf Strom verbrauchen. Weiter kann ein erhöhter Stromverbrauch zu einer höheren Betriebstemperatur führen, was wiederum zu einer verringerten Leistung führen kann. Infolgedessen umfasst die PPU 200 ein Leistungs- und Taktfrequenzmanagement, das berücksichtigt, wie sich die Leistungsaufnahme innerhalb einer PPU-Partition 600 negativ auf die Leistung anderer PPU-Partitionen 600 auswirken kann.
38 zeigt ein Blockdiagramm eines Leistungs- und Taktfrequenzverwaltungssystems 3800 für die PPU 200 von 2, gemäß verschiedenen Ausführungsbeispielen. Das Leistungs- und Taktfrequenzverwaltungssystem 3800 umfasst, ohne Einschränkung, die Schaltungsunterabschnitte 3810(0) - 3810(N), einen Power-Gate-Controller 3820 und einen Taktfrequenz-Controller 3830.
Jeder der Schaltungsunterabschnitte 3810(0) - 3810(N) umfasst einen beliebigen Satz von Komponenten, die in PPU 200 auf jeder Granularitätsebene enthalten sind. In dieser Hinsicht kann jeder der Stromkreisunterabschnitte 3810(0) - 3810(N) ohne Einschränkung eine Sys-Pipe 230, eine PPU-Partition 600, einen PPU-Abschnitt 610, eine SMC-Engine 700 oder einen beliebigen technisch geeigneten Teilsatz davon umfassen.
Im Betrieb überwacht der Power-Gate-Controller 3820 den Aktivitätsstatus der Schaltungsunterabschnitte 3810(0) - 3810(N). Wenn der Power-Gate-Controller 3820 feststellt, dass sich ein bestimmter Schaltungsunterabschnitt, wie z.B. Schaltungsunterabschnitt 3810(2), im Leerlauf befindet, dann reduziert der Power-Gate-Controller 3820 die Versorgungsspannung für den Schaltungsunterabschnitt 3810(2) auf eine Spannung, die kleiner als eine Betriebsspannung ist, aber die im Speicher gespeicherten Daten beibehält. Alternativ kann der Power-Gate-Controller 3820 den Strom aus Schaltungsunterabschnitt 3810(2) entfernen und dadurch Schaltungsunterabschnitt 3810(2) abschalten. Wenn anschließend der Schaltungsunterabschnitt 3810(2) zur Ausführung bestimmter Aufgaben benötigt wird, erhöht der Power-Gate-Controller 3820 die Versorgungsspannung des Schaltungsunterabschnitts 3180(2) auf eine für den Betrieb geeignete Spannung.
Der Taktfrequenz-Controller 3830 überwacht die Leistungsaufnahme der Schaltungsunterabschnitte 3810(0) - 3810(N). Wenn der Taktfrequenz-Controller 3830 feststellt, dass ein bestimmter Schaltungsunterabschnitt, wie z.B. Schaltungsunterabschnitt 3810(3), im Vergleich zu anderen Schaltungsunterabschnitten 3810 mehr Leistung verbraucht, dann reduziert der Taktfrequenz-Controller 3830 die Frequenz der mit Schaltungsunterabschnitt 3810(3) assoziierten Taktsignale. Infolgedessen wird die von Schaltungsunterabschnitt 3810(3) verbrauchte Leistung reduziert. Wenn der Taktfrequenz-Controller 3830 anschließend feststellt, dass Schaltungsunterabschnitt 3810(3) im Vergleich zu anderen Schaltungsunterabschnitten 3810 weniger Leistung verbraucht, dann erhöht der Taktfrequenz-Controller 3830 die Frequenz der Taktsignale, die mit Schaltungsunterabschnitt 3810(3) assoziiert sind, wodurch die Leistung von Schaltungsunterabschnitt 3810(3) erhöht wird.
Auf diese Weise reduzieren der Power-Gate-Controller 3820 und der Taktfrequenz-Controller 3830 den Gesamtstromverbrauch von PPU 200 und verringern die negativen Auswirkungen einer PPU-Partition 600 auf eine andere PPU-Partition 600 aufgrund von Temperatureffekten.
39 zeigt ein Flussdiagramm mit Verfahrensschritten zur Verwaltung des Stromverbrauchs der PPU 200 aus 2, gemäß verschiedenen Ausführungsbeispielen. Obwohl die Verfahrensschritte in Verbindung mit den Systemen der 1-25 beschrieben werden, werden Fachleute mit gewöhnlichen Fachkenntnissen verstehen, dass jedes beliebige System, das zur Durchführung der Verfahrensschritte in beliebiger Reihenfolge konfiguriert sein kann, unter den Umfang der vorliegenden Offenbarung fällt.
Wie gezeigt, beginnt ein Verfahren 3900 mit Schritt 3902, in dem das Leistungs- und Taktfrequenzverwaltungssystem 3800 der PPU 200 den Aktivitätsstatus von VMs überwacht, die auf verschiedenen Schaltkreisunterabschnitten 3810 der PPU 200 ausgeführt werden. In Schritt 3904 bestimmt das Leistungs- und Taktfrequenzverwaltungssystem 3800, ob irgendein Schaltungsunterabschnitt 3810 im Leerlauf ist. Wenn keine Schaltungsunterabschnitte 3810 im Leerlauf sind, fährt das Verfahren mit Schritt 3908 fort. Wenn jedoch eine oder mehrere Schaltungsunterabschnitte 3810 im Leerlauf sind, fährt das Verfahren mit Schritt 3906 fort, in dem das Leistungs- und Taktfrequenzverwaltungssystem 3800 die Versorgungsspannung für die im Leerlauf befindlichen Schaltungsunterabschnitte 3810 reduziert. Insbesondere reduziert der Power-Gate-Controller 3820 innerhalb des Leistungs- und Taktfrequenzverwaltungssystems 3800 die Versorgungsspannung für den Schaltungsunterabschnitt 3810(2) auf eine Spannung, die kleiner als eine Betriebsspannung ist, aber die im Speicher gespeicherten Daten beibehält. Alternativ kann der Leistungs-Gate-Controller 3820 die Leistung aus dem Schaltungsunterabschnitt 3810(2) entfernen und dadurch den Schaltungsunterabschnitt 3810(2) abschalten.
In Schritt 3908 überwacht das Leistungs- und Taktfrequenzmanagementsystem 3800 den Stromverbrauch für jede SMC-Engine 700 innerhalb der PPU. In Schritt 3910 ermittelt das Leistungs- und Taktfrequenzmanagementsystem 3800, ob eine oder mehrere der SMC-Engines 700 im Vergleich zu den anderen SMC-Engines 700 übermäßig Leistung verbrauchen. Wenn keine der SMC-Engines 700 übermäßige Leistung verbraucht, fährt das Verfahren mit Schritt 3902 fort, um die Überwachung fortzusetzen. Wenn jedoch eine oder mehrere SMC-Engines 700 übermäßige Leistung verbrauchen, fährt das Verfahren mit Schritt 3912 fort, wobei der Taktfrequenz-Controller 3830 im Leistungs- und TaktfrequenzManagementsystem 3800 die Taktfrequenz zu einem oder mehreren Schaltungsunterabschnitten 3810 reduziert, die den SMC-Engines 700 zugeordnet sind, die übermäßige Leistung verbrauchen. Das Verfahren fährt dann mit Schritt 3902 fort, um die Überwachung fortzusetzen.
Zusammenfassend umfassen verschiedene Ausführungsbeispiele eine Parallelverarbeitungseinheit (PPU), die in Partitionen unterteilt werden kann. Jede Partition ist so konfiguriert, dass sie Verarbeitungsaufgaben, die mit mehreren Verarbeitungskontexten assoziiert sind, simultan ausführt. Eine bestimmte Partition umfasst eine oder mehrere logische Gruppierungen oder „Abschnitte“ von GPU-Ressourcen. Jeder Abschnitt bietet ausreichend Rechen-, Grafik- und Speicherressourcen, um den Betrieb der PPU als Ganzes nachzubilden. Ein Hypervisor, der auf einer CPU ausgeführt wird, führt im Auftrag eines Admin-Benutzers verschiedene Techniken zum Partitionieren der PPU-Partition aus. Ein Gastbenutzer wird einer Partition zugewiesen und kann dann Verarbeitungsaufgaben innerhalb dieser Partition isoliert von allen anderen Gastbenutzern ausführen, die beliebigen anderen Partitionen zugewiesen sind.
Ein technologischer Vorteil der offenbarten Techniken gegenüber dem Stand der Technik besteht darin, dass eine PPU mit den offenbarten Techniken mehrere Verarbeitungskontexte gleichzeitig und funktional voneinander isoliert unterstützen kann. Dementsprechend können mehrere CPU-Prozesse PPU-Ressourcen effizient durch mehrere verschiedene Verarbeitungskontexte nutzen, ohne sich gegenseitig zu stören. Ein weiterer technologischer Vorteil der offenbarten Techniken besteht darin, dass dadurch, dass die PPU mit Hilfe der offengelegten Techniken in isolierte Rechenumgebungen partitioniert werden kann, die PPU eine robustere Form der Mehrmandantenfähigkeit unterstützen kann, im Vergleich zu Ansätzen nach dem Stand der Technik, die sich auf Verarbeitungssubkontexte stützen, um Mehrmandantenfähigkeitsfunktionalität bereitzustellen. Dementsprechend eignet sich eine PPU bei der Implementierung der offengelegten Techniken besser für Cloudbasierte Implementierungen, bei denen verschiedenen und potenziell konkurrierenden Einheiten Zugriff auf verschiedene Partitionen innerhalb derselben PPU gewährt werden kann. Diese technologischen Vorteile repräsentieren einen oder mehrere technologische Fortschritte gegenüber Ansätzen nach dem Stand der Technik.
1. Einige Ausführungsbeispiele umfassen ein computerimplementiertes Verfahren, das ein Partitionieren eines Satzes von Hardwareressourcen, die in einem Prozessor enthalten sind, um eine erste logische Partition zu erzeugen, die einen ersten Teilsatz von Hardwareressourcen umfasst, und ein Erzeugen einer Vielzahl von Engines innerhalb der ersten logischen Partition umfasst, wobei jeder Engine, die in der Vielzahl von Engines enthalten ist, ein anderer Bereich (Teil) des ersten Teilsatzes von Hardwareressourcen zugewiesen wird und sie in funktionaler Isolierung von allen anderen Engines, die in der Vielzahl von Engines enthalten sind, ausgeführt wird.
2. Computerimplementiertes Verfahren nach Ziffer 1, wobei das Partitionieren des Satzes von Rechenressourcen weiter ein Partitionieren des Satzes von Rechenressourcen umfaßt, um eine zweite logische Partition zu erzeugen, die einen zweiten Teilsatz von Rechenressourcen umfaßt, wobei der erste Teilsatz von Rechenressourcen mehr Rechenressourcen umfaßt als der zweite Teilsatz von Rechenressourcen.
3. Computerimplementiertes Verfahren nach einer der Ziffern 1-2, wobei jede Engine, die in der Vielzahl von Engines enthalten ist, einen Satz von Verarbeitungsaufgaben ausführt, die mit einem anderen Verarbeitungskontext assoziiert sind.
4. Computer-implementiertes Verfahren nach einer der Ziffern 1-3, weiter umfassend ein Veranlassen einer ersten Engine, die in der Vielzahl von Engines enthalten ist, einen Satz von Verarbeitungsaufgaben, die mit einem Verarbeitungskontext assoziiert sind, während eines gegebenen Zeitintervalls auszuführen, und ein Veranlassen einer zweiten Engine, die in der Vielzahl von Engines enthalten ist, eine oder mehrere Kontextwechsel-Operationen (Operationen zum Wechsel eines Kontexts) während des gegebenen Zeitintervalls auszuführen.
5. Computer-implementiertes Verfahren einer der Ziffern 1-4, weiter umfassend, ein Veranlassen einer ersten Engine, die in der Vielzahl von Engines enthalten ist, einen ersten Satz von Verarbeitungsaufgaben, die mit einem ersten Verarbeitungskontext assoziiert sind, während eines gegebenen Zeitintervalls auszuführen, und Veranlassen, dass eine zweite Engine, die in der Vielzahl von Engines enthalten ist, während des gegebenen Zeitintervalls als Reaktion auf einen Fehler, der auftritt, während die zweite Engine einen zweiten Satz von Verarbeitungsaufgaben ausführt, die mit einem zweiten Verarbeitungskontext assoziiert sind, sich zurücksetzt.
6. Computerimplementiertes Verfahren nach einer der Ziffern 1-5, weiter umfassend ein Veranlassen einer ersten Engine, die in der Vielzahl von Engines enthalten ist, einen ersten Satz von Verarbeitungsaufgaben, die mit einem ersten Verarbeitungssubkontext assoziiert sind, während eines ersten Zeitintervalls auszuführen, und ein Veranlassen der ersten Engine, einen zweiten Satz von Verarbeitungsaufgaben, die mit einem zweiten Verarbeitungssubkontext assoziiert sind, während des ersten Zeitintervalls auszuführen, wobei sowohl der erste Verarbeitungssubkontext als auch der zweite Verarbeitungssubkontext von einem ersten Verarbeitungskontext abgeleitet sind, und wobei die erste Engine entsprechend dem ersten Verarbeitungskontext konfiguriert ist.
7. Computerimplementiertes Verfahren nach einer der Ziffern 1 bis 6, weiter umfassend ein Analysieren des Satzes von Hardwareressourcen, um eine nicht-funktionale Instanz einer ersten Hardwareressource zu identifizieren, ein Bestimmen, dass der Teilsatz von Hardwareressourcen eine funktionale Instanz der ersten Hardwareressource umfasst, und elektrisches Isolieren der nicht-funktionalen Instanz der ersten Hardwareressource.
8. Computerimplementiertes Verfahren nach einer der Ziffer 1-7, weiter umfassend ein weiteres Partitionieren des Satzes von Hardware-Ressourcen, um eine zweite logische Partition zu erzeugen, ein Konfigurieren der zweiten logischen Partition in Übereinstimmung mit der ersten logischen Partition, ein Identifizieren einer ersten Engine, die in der ersten Partition enthalten ist und eine erste Verarbeitungsaufgabe ausführt, die mit einem ersten Verarbeitungskontext assoziiert ist, und ein Migrieren des ersten Verarbeitungskontextes zu einer zweiten Engine, die in der zweiten logischen Partition enthalten ist.
9. Computerimplementiertes Verfahren nach einer der Ziffern 1-8, weiter umfassend ein Bestimmen, dass die erste logische Partition eine nicht-funktionale Instanz einer ersten Hardwareressource umfasst, ein Bestimmen, dass eine zweite logische Partition eine funktionale Instanz der ersten Hardwareressource umfasst, ein Deaktivieren der funktionalen Instanz der ersten Hardwareressource, ein Konfigurieren der zweiten logischen Partition in Übereinstimmung mit der ersten logischen Partition und ein Migrieren eines ersten Verarbeitungskontextes, der mit der ersten logischen Partition assoziiert ist, in die zweite logische Partition.
10. Computerimplementiertes Verfahren nach einer der Ziffern 1-9, weiter umfassend ein Empfangen einer ersten Eingabe, die mit einer ersten Rechenumgebung assoziiert ist, wobei ein erster Satz von Operationen auf dem Prozessor innerhalb der ersten Rechenumgebung basierend auf einem ersten Satz von Berechtigungen ausgeführt wird, und ein Empfangen einer zweiten Eingabe, die mit einer zweiten Rechenumgebung assoziiert ist, wobei ein zweiter Satz von Operationen auf dem Prozessor innerhalb der zweiten Rechenumgebung basierend auf einem zweiten Satz von Berechtigungen ausgeführt wird, und der erste Satz von Berechtigungen eine größere Anzahl von Berechtigungen enthält als der zweite Satz von Berechtigungen, wobei der Satz von Hardware-Ressourcen basierend auf der ersten Eingabe partitioniert wird, und wobei eine erste Engine, die in der Vielzahl von Engines enthalten ist, basierend auf der zweiten Eingabe konfiguriert ist.
11. Einige Ausführungsbeispiele umfassen ein nichtflüchtiges computerlesbares Medium, das Programmbefehle gespeichert hat, die, wenn sie von einem Prozessor ausgeführt werden, den Prozessor veranlassen, die folgenden Schritte auszuführen; ein Erzeugen einer ersten logischen Partition innerhalb eines Prozessors, der einen Satz von Hardware-Ressourcen umfasst, wobei die erste logische Partition einen ersten Teilsatz Hardware-Ressourcen umfasst, und ein Erzeugen einer Vielzahl von Engines innerhalb der ersten logischen Partition, wobei jeder Engine, die in der Vielzahl von Engines enthalten ist, ein anderer Bereich des ersten Teilsatzes von Hardware-Ressourcen zugewiesen wird und diese in funktioneller Isolierung von allen anderen Engines, die in der Vielzahl von Engines enthalten sind, ausgeführt wird.
12. Nichtflüchtiges computerlesbares Medium nach Ziffer 11, wobei jede Engine, die in der Vielzahl von Engines enthalten ist, einen Satz von Verarbeitungsaufgaben ausführt, die mit einem anderen Verarbeitungskontext assoziiert sind.
13. Nichtflüchtiges computerlesbares Medium nach einer der Ziffern 11-12, weiter umfassend die folgenden Schritte: ein Veranlassen einer ersten Engine, die in der Vielzahl von Engines enthalten ist, einen Satz von Verarbeitungsaufgaben, die mit einem Verarbeitungskontext assoziiert sind, während eines gegebenen Zeitintervalls auszuführen, und ein Veranlassen einer zweiten Engine, die in der Vielzahl von Engines enthalten ist, eine oder mehrere Kontextwechsel-Operationen (Operationen zum Wechseln eines Kontexts) während des gegebenen Zeitintervalls auszuführen.
14. Nichtflüchtiges computerlesbare Medium nach einer der Ziffern 11-13, weiter umfassend die folgenden Schritte: ein Veranlassen einer ersten Engine, die in der Vielzahl von Engines enthalten ist, während eines gegebenen Zeitintervalls einen ersten Satz von Verarbeitungsaufgaben, die mit einem ersten Verarbeitungskontext assoziiert sind, auszuführen, und ein Veranlassen einer zweiten Engine, die in der Vielzahl von Engines enthalten ist, als Reaktion auf einen Fehler, der auftritt, während die zweite Engine einen zweiten Satz von Verarbeitungsaufgaben, die mit einem zweiten Verarbeitungskontext assoziiert sind, ausführt, während des gegebenen Zeitintervalls zurückgesetzt zu werden.
15. Nichtflüchtiges computerlesbares Medium nach einer der Ziffern 11-14, weiter umfassend die folgenden Schritte: ein Veranlassen, dass eine erste Engine, die in der Vielzahl von Engines enthalten ist, einen ersten Satz von Verarbeitungsaufgaben, die mit einem ersten Verarbeitungssubkontext assoziiert sind, während eines ersten Zeitintervalls ausführt, und ein Veranlassen der ersten Engine, einen zweiten Satz von Verarbeitungsaufgaben, die mit einem zweiten Verarbeitungssubkontext assoziiert sind, während des ersten Zeitintervalls auszuführen, wobei sowohl der erste Verarbeitungssubkontext als auch der zweite Verarbeitungssubkontext von einem ersten Verarbeitungskontext abgeleitet sind, und wobei die erste Engine entsprechend dem ersten Verarbeitungskontext konfiguriert ist.
16. Nichtflüchtiges computerlesbares Medium nach einer der Ziffern 11-15, weiter umfassend die folgenden Schritte: ein Bestimmen, daß die erste logische Partition eine nicht-funktionale Instanz einer ersten Hardwareressource umfaßt, ein Bestimmen, daß eine zweite logische Partition eine funktionale Instanz der ersten Hardwareressource umfaßt, ein Deaktivieren der funktionalen Instanz der ersten Hardwareressource, ein Konfigurieren der zweiten logischen Partition in Übereinstimmung mit der ersten logischen Partition, und ein Migrieren eines ersten Verarbeitungskontextes, der mit der ersten logischen Partition assoziiert ist, zu der zweiten logischen Partition.
17. Nichtflüchtiges computerlesbares Medium nach einer der Ziffern 11-16, weiter umfassend folgenden Schritte: ein Empfangen einer Partitionierungseingabe, die mit einer Host-Rechenumgebung assoziiert ist, und ein Empfangen einer Konfigurationseingabe, die mit einer Gast-Rechenumgebung assoziiert ist, wobei der Satz von Hardwareressourcen basierend auf der Partitionierungseingabe partitioniert wird, und wobei eine erste Engine, die in der Vielzahl von Engines enthalten ist, basierend auf der Konfigurationseingabe konfiguriert wird.
18. Nichtflüchtiges computerlesbares Medium nach einer der Ziffern 11-17, wobei die Vielzahl von Engines derart konfiguriert ist, dass sie eine Vielzahl von Grafikverarbeitungs-Pipelines implementiert.
19. Nichtflüchtiges computerlesbares Medium nach einer der Ziffern 11-18, wobei der Schritt des Partitionierens des Satzes von Hardware-Ressourcen ein Aktivieren eines Satzes von logischen Grenzen umfasst, die mit dem Prozessor assoziiert sind, basierend auf einem Satz von Bits, wobei jedes Bit, das in dem Satz von Bits enthalten ist, einer anderen logischen Grenze entspricht, die in dem Satz von logischen Grenzen enthalten ist.
20. Einige Ausführungsbeispiele umfassen ein System, das einen Speicher zum Speichern einer Softwareanwendung und einen Prozessor umfaßt, der bei der Ausführung der Softwareanwendung derart konfiguriert ist, daß er die folgenden Schritte ausführt: ein Partitionieren eines Satzes von Hardwareressourcen, die in einem Prozessor enthalten sind, um eine erste logische Partition zu erzeugen, die einen ersten Teilsatz der Hardwareressourcen umfaßt, und ein Erzeugen einer Vielzahl von Engines innerhalb der ersten logischen Partition, wobei jeder Engine, die in der Vielzahl von Engines enthalten ist, ein anderer Bereich des ersten Teilsatzes von Hardwareressourcen zugewiesen wird und diese in funktioneller Isolierung von allen anderen Engines, die in der Vielzahl von Engines enthalten sind, ausgeführt wird.
Jede beliebige Kombination und alle Kombinationen der in einem der Ansprüche genannten Anspruchselemente und/oder der in dieser Anmeldung beschriebenen Elemente fällt in jeglicher Hinsicht unter den beabsichtigten Umfang der vorliegenden Ausführungsbeispiele und des Schutzumfangs.
Die Beschreibungen der verschiedenen Ausführungsbeispiele wurden zu Illustrationszwecken dargestellt, sollen aber weder abschließend noch auf die offenbarten Ausführungsbeispiele beschränkt sein. Viele Modifikationen und Variationen werden von Fachleuten vorgenommen, ohne vom Umfang und Geist der beschriebenen Ausführungsbeispiele abzuweichen.
Aspekte der vorliegenden Ausführungsbeispiele 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ührung, einer vollständigen Software-Ausführung (einschließlich Firmware, residenter Software, Mikrocode usw.) oder einer Ausführung annehmen, die Software- und Hardware-Aspekte kombiniert, die alle hierin allgemein als „Modul“, „System“ oder „Computer“ bezeichnet werden können. Darüber hinaus kann jede beliebige Hardware- und/oder Software-Technik, jeder beliebige Prozess, jede beliebige Funktion, jede beliebige Komponente, jede beliebige Engine, jedes beliebige Modul oder jedes beliebige System, die in dieser Offenbarung beschrieben werden, als Schaltkreis oder Satz von Schaltkreisen implementiert werden. Darüber hinaus können Aspekte der vorliegenden Offenbarung die Form eines Computerprogrammprodukts annehmen, das in einem oder mehreren computerlesbaren Datenträgern mit darauf enthaltenem computerlesbarem Programmcode ausgeführt ist.
Es kann eine beliebige Kombination aus einem oder mehreren computerlesbaren Datenträgern verwendet werden. Das computerlesbare Medium kann ein computerlesbares Signalmedium oder ein computerlesbares Speichermedium sein. Ein computerlesbares Speichermedium kann zum Beispiel, aber nicht ausschließlich, ein elektronisches, magnetisches, optisches, elektromagnetisches, Infrarot- oder Halbleitersystem, -apparat oder -gerät oder eine beliebige Kombination der vorgenannten sein. Spezifischere Beispiele (eine nicht erschöpfende Liste) für das computerlesbare Speichermedium würden folgendes umfassen: eine elektrische Verbindung mit einem oder mehreren Drähten, eine tragbare Computerdiskette, eine Festplatte, einen Random-Access-Speicher (RAM), einen Festwertspeicher (ROM), einen löschbaren programmierbaren Festwertspeicher (EPROM oder Flash-Speicher), eine optische Faser, einen tragbaren Compact-Disc-Festwertspeicher (CD-ROM), ein optisches Rechengerät, ein magnetisches Speichergerät oder eine beliebige geeignete Kombination der vorstehenden Elemente. Im Zusammenhang mit diesem Dokument kann ein computerlesbares Speichermedium jedes beliebige greifbare Medium sein, das ein Programm zur Verwendung durch oder in Verbindung mit einem Befehlsausführungssystem, -gerät oder -vorrichtung enthalten oder speichern kann.
Aspekte der vorliegenden Offenbarung werden oben unter Bezugnahme auf Flussdiagramm-Illustrationen und/oder Blockdiagramme von Methoden, Apparaten (Systemen) und Computerprogramm-Produkten entsprechend den Ausführungsbeispielen der Offenbarung beschrieben. Es ist zu verstehen, dass jeder Block der Flussdiagrammfiguren und/oder Blockdiagramme und Kombinationen von Blöcken in den Flussdiagrammfiguren und/oder Blockdiagrammen durch Computerprogrammanweisungen implementiert werden kann. Diese Computerprogrammbefehle können einem Prozessor eines allgemeinen Computers, eines Computers für besondere Zwecke oder eines anderen programmierbaren Datenverarbeitungsgeräts, welches eine Maschine darstellt, zur Verfügung gestellt werden. Wenn die Anweisungen über den Prozessor des Computers oder einer anderen programmierbaren Datenverarbeitungsanlage ausgeführt werden, ermöglichen sie die Implementierung der im Flussdiagramm und/oder in den Blockdiagrammfiguren und/oder Blockdiagrammen spezifizierten Funktionen/Aktionen. Bei diesen Prozessoren kann es sich ohne Einschränkung um allgemeine Prozessoren, Spezialprozessoren, anwendungsspezifische Prozessoren oder feldprogrammierbare Gate-Arrays handeln.
Das Flussdiagramm und die Blockdiagramme in den Figuren zeigen die Architektur, Funktionalität und Funktionsweise möglicher Implementierungen von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedenen Ausführungsbeispielen der vorliegenden Offenbarung. In dieser Hinsicht kann jeder Block in dem Flussdiagramm oder den Blockdiagrammen ein Modul, ein Segment oder einen Bereich von Code repräsentieren, der einen oder mehrere ausführbare Befehle zur Implementierung der spezifizierten logischen Funktionalität(en) umfasst. Es ist auch zu beachten, dass in einigen alternativen Implementierungen die im Block angegebenen Funktionen außerhalb der in den Figuren angegebenen Reihenfolge auftreten können. So können z.B. zwei nacheinander dargestellte Blöcke im wesentlichen gleichzeitig ausgeführt werden, oder die Blöcke können manchmal in umgekehrter Reihenfolge ausgeführt werden, je nach der betreffenden Funktionalität. Es wird auch darauf hingewiesen, dass jeder Block der Blockdiagramme und/oder der Flussdiagrammdarstellung sowie Kombinationen von Blöcken in den Blockdiagrammen und/oder der Flussdiagrammdarstellung durch spezifische Hardware-basierte Systeme implementiert werden können, die die spezifizierten Funktionen oder Handlungen oder Kombinationen von spezieller Hardware und Computeranweisungen ausführen.
Obwohl das Vorhergehende auf Ausführungsbeispiele der vorliegenden Offenbarung gerichtet ist, können andere und weitere Ausführungsbeispiele der Offenbarung ausgearbeitet werden, ohne vom grundlegenden Umfang der Offenbarung abzuweichen, und der Umfang der Offenbarung wird durch die folgenden Ansprüche bestimmt.

Claims

Computerimplementiertes Verfahren, umfassend: Partitionieren eines Satzes von Hardwareressourcen, die in einem Prozessor enthalten sind, um eine erste logische Partition zu erzeugen, die einen ersten Teilsatz von Hardwareressourcen umfasst; und Erzeugen einer Vielzahl von Engines innerhalb der ersten logischen Partition, wobei jeder Engine, die in der Vielzahl von Engines enthalten ist, ein anderer Bereich des ersten Teilsatzes von Hardwareressourcen zugewiesen ist und diese in funktionaler Isolierung von allen anderen Engines, die in der Vielzahl von Engines enthalten sind, ausgeführt wird.
Computerimplementiertes Verfahren nach Anspruch 1, wobei das Partitionieren des Satzes von Hardwareressourcen weiter ein Partitionieren des Satzes von Hardwareressourcen umfasst, um eine zweite logische Partition zu erzeugen, die einen zweiten Teilsatz von Hardwareressourcen umfasst, wobei der erste Teilsatz von Hardwareressourcen mehr Hardwareressourcen umfasst als der zweite Teilsatz von Hardwareressourcen.
Computerimplementiertes Verfahren nach Anspruch 1 oder 2, wobei jede Engine, die in der Vielzahl von Engines enthalten ist, einen Satz von Verarbeitungsaufgaben ausführt, die mit einem unterschiedlichen Verarbeitungskontext assoziiert sind.
Computerimplementiertes Verfahren nach einem der vorhergehenden Ansprüche, weiter umfassend: Veranlassen einer ersten Engine, die in der Vielzahl von Engines enthalten ist, einen Satz von Verarbeitungsaufgaben, die mit einem Verarbeitungskontext assoziiert sind, während eines gegebenen Zeitintervalls auszuführen; und Veranlassen einer zweiten Engine, die in der Vielzahl von Engines enthalten ist, eine oder mehrere Operationen zum Wechseln eines Kontexts während des gegebenen Zeitintervalls durchzuführen.
Computerimplementiertes Verfahren nach einem der vorhergehenden Ansprüche, weiter umfassend: Veranlassen einer ersten Engine, die in der Vielzahl von Engines enthalten ist, einen ersten Satz von Verarbeitungsaufgaben, die mit einem ersten Verarbeitungskontext assoziiert sind, während eines gegebenen Zeitintervalls auszuführen; und Veranlassen, dass sich eine zweite Engine, die in der Vielzahl von Engines enthalten ist, während des gegebenen Zeitintervalls als Reaktion auf einen Fehler zurücksetzt, der auftritt, während die zweite Engine einen zweiten Satz von Verarbeitungsaufgaben ausführt, die mit einem zweiten Verarbeitungskontext assoziiert sind.
Computerimplementiertes Verfahren nach einem der vorhergehenden Ansprüche, weiter umfassend: Veranlassen einer ersten Engine, die in der Vielzahl von Engines enthalten ist, einen ersten Satz von Verarbeitungsaufgaben, die mit einem ersten Verarbeitungssubkontext assoziiert sind, während eines ersten Zeitintervalls auszuführen; und Veranlassen, dass die erste Engine während des ersten Zeitintervalls einen zweiten Satz von Verarbeitungsaufgaben ausführt, die mit einem zweiten Verarbeitungssubkontext assoziiert sind, wobei sowohl der erste Verarbeitungssubkontext als auch der zweite Verarbeitungssubkontext von einem ersten Verarbeitungskontext abgeleitet sind, und wobei die erste Engine entsprechend dem ersten Verarbeitungskontext konfiguriert ist.
Computerimplementiertes Verfahren nach einem der vorhergehenden Ansprüche, weiter umfassend: Analysieren des Satzes von Hardwareressourcen, um eine nicht-funktionale Instanz einer ersten Hardwareressource zu identifizieren; Bestimmen, dass der Teilsatz der Hardwareressourcen eine funktionale Instanz der ersten Hardwareressource umfasst; und elektrisches Isolieren der nicht-funktionalen Instanz der ersten Hardware-Ressource.
Computerimplementiertes Verfahren nach einem der vorhergehenden Ansprüche, weiter umfassend: weiteres Partitionieren des Satzes von Hardwareressourcen, um eine zweite logische Partition zu erzeugen; Konfigurieren der zweiten logischen Partition in Übereinstimmung mit der ersten logischen Partition; Identifizieren einer ersten Engine, die in der ersten Partition enthalten ist und eine erste Verarbeitungsaufgabe ausführt, die mit einem ersten Verarbeitungskontext assoziiert ist; und Migrieren des ersten Verarbeitungskontextes zu einer zweiten Engine, die in der zweiten logischen Partition enthalten ist.
Computerimplementiertes Verfahren nach einem der vorhergehenden Ansprüche, weiter umfassend: Bestimmen, dass die erste logische Partition eine nicht-funktionale Instanz einer ersten Hardwareressource umfasst; Bestimmen, dass eine zweite logische Partition eine funktionale Instanz der ersten Hardwareressource umfasst; Deaktivieren der funktionalen Instanz der ersten Hardwareressource; Konfigurieren der zweiten logischen Partition in Übereinstimmung mit der ersten logischen Partition; und Migrieren eines ersten Verarbeitungskontextes, der mit der ersten logischen Partition assoziiert ist, auf die zweite logische Partition.
Computerimplementiertes Verfahren nach einem der vorhergehenden Ansprüche, weiter umfassend: Empfangen einer ersten Eingabe, die mit einer ersten Rechenumgebung assoziiert ist, wobei ein erster Satz von Operationen auf dem Prozessor innerhalb der ersten Rechenumgebung basierend auf einem ersten Satz von Berechtigungen ausgeführt wird; und Empfangen einer zweiten Eingabe, die mit einer zweiten Rechenumgebung assoziiert ist, wobei ein zweiter Satz von Operationen auf dem Prozessor innerhalb der zweiten Rechenumgebung basierend auf einem zweiten Satz von Berechtigungen ausgeführt wird, und der erste Satz von Berechtigungen eine größere Anzahl von Berechtigungen umfasst als der zweite Satz von Berechtigungen, wobei der Satz von Hardwareressourcen basierend auf der ersten Eingabe partitioniert wird, und wobei eine erste Engine, die in der Vielzahl von Engines enthalten ist, basierend auf der zweiten Eingabe konfiguriert wird.
Nichtflüchtiges computerlesbares Medium, das Programmbefehle speichert, die, wenn sie von einem Prozessor ausgeführt werden, den Prozessor veranlassen, die folgenden Schritte auszuführen: Erzeugen einer ersten logischen Partition innerhalb eines Prozessors, der einen Satz von Hardwareressourcen umfasst, wobei die erste logische Partition einen ersten Teilsatz von Hardwareressourcen umfasst; und Erzeugen einer Vielzahl von Engines innerhalb der ersten logischen Partition, wobei jeder Engine, die in der Vielzahl von Engines enthalten ist, ein anderer Bereich des ersten Teilsatzes von Hardwareressourcen zugewiesen wird und diese in funktionaler Isolierung von allen anderen Engines, die in der Vielzahl von Engines enthalten sind, ausgeführt wird.
Nichtflüchtiges computerlesbares Medium nach Anspruch 11, wobei jede Engine, die in der Vielzahl von Engines enthalten ist, einen Satz von Verarbeitungsaufgaben ausführt, die mit einem unterschiedlichen Verarbeitungskontext assoziiert sind.
Nichtflüchtiges computerlesbares Medium nach Anspruch 11 oder 12, weiter umfassend die folgenden Schritte: Veranlassen einer ersten Engine, die in der Vielzahl von Engines enthalten ist, einen Satz von Verarbeitungsaufgaben, die mit einem Verarbeitungskontext assoziiert sind, während eines gegebenen Zeitintervalls auszuführen; und Veranlassen einer zweiten Engine, die in der Vielzahl von Engines enthalten ist, eine oder mehrere Kontext-Switch-Operationen während des gegebenen Zeitintervalls durchzuführen.
Nichtflüchtiges computerlesbares Medium nach einem der Ansprüche 11 bis 13, weiter umfassend die folgenden Schritte: Veranlassen einer ersten Engine, die in der Vielzahl von Engines enthalten ist, einen ersten Satz von Verarbeitungsaufgaben, die mit einem ersten Verarbeitungskontext assoziiert sind, während eines gegebenen Zeitintervalls auszuführen; und Veranlassen einer zweiten Engine, die in der Vielzahl von Engines enthalten ist, sich während des gegebenen Zeitintervalls als Reaktion auf einen Fehler zurückzusetzen, der auftritt, während die zweite Engine einen zweiten Satz von Verarbeitungsaufgaben ausführt, die mit einem zweiten Verarbeitungskontext assoziiert sind.
Nichtflüchtiges computerlesbares Medium nach einem der Ansprüche 11 bis 14, weiter umfassend die folgenden Schritte: Veranlassen einer ersten Engine, die in der Vielzahl von Engines enthalten ist, einen ersten Satz von Verarbeitungsaufgaben, die mit einem ersten Verarbeitungssubkontext assoziiert sind, während eines ersten Zeitintervalls auszuführen; und Veranlassen der ersten Engine, während des ersten Zeitintervalls einen zweiten Satz von Verarbeitungsaufgaben auszuführen, die mit einem zweiten Verarbeitungssubkontext assoziiert sind, wobei sowohl der erste Verarbeitungssubkontext als auch der zweite Verarbeitungssubkontext von einem ersten Verarbeitungskontext abgeleitet sind, und wobei die erste Engine entsprechend dem ersten Verarbeitungskontext konfiguriert ist.
Nichtflüchtiges computerlesbares Medium nach einem der Ansprüche 11 bis 15, weiter umfassend die folgenden Schritte: Bestimmen, dass die erste logische Partition eine nicht-funktionale Instanz einer ersten Hardware-Ressource umfasst; Bestimmen, dass eine zweite logische Partition eine funktionale Instanz der ersten Hardwareressource umfasst; Deaktivieren der funktionalen Instanz der ersten Hardwareressource; Konfigurieren der zweiten logischen Partition in Übereinstimmung mit der ersten logischen Partition; und Migrieren eines ersten Verarbeitungskontextes, der mit der ersten logischen Partition assoziiert ist, auf die zweite logische Partition.
Nichtflüchtiges computerlesbares Medium nach einem der Ansprüche 11 bis 16, weiter umfassend die folgenden Schritte: Empfangen einer Partitionierungseingabe, die mit einer Host-Rechnerumgebung assoziiert ist; und Empfangen einer Konfigurationseingabe, die mit einer Gast-Computerumgebung assoziiert ist, wobei der Satz von Hardwareressourcen basierend auf der Partitionierungseingabe partitioniert wird, und wobei eine erste Engine, die in der Vielzahl von Engines enthalten ist, basierend auf der Konfigurationseingabe konfiguriert wird.
Nichtflüchtiges computerlesbares Medium nach einem der Ansprüche 11 bis 17, wobei die Vielzahl von Engines so konfiguriert ist, dass sie eine Vielzahl von Grafikverarbeitungs-Pipelines implementiert.
Nichtflüchtiges computerlesbares Medium nach einem der Ansprüche 11 bis 18, wobei der Schritt des Partitionierens des Satzes von Hardware-Ressourcen ein Aktivieren eines Satzes von logischen Grenzen umfasst, die dem Prozessor basierend auf einem Satz von Bits zugeordnet sind, wobei jedes Bit, das in dem Satz von Bits enthalten ist, einer anderen logischen Grenze entspricht, die in dem Satz von logischen Grenzen enthalten ist.
System, umfassend: einen Speicher, der eine Software-Anwendung speichert; und einen Prozessor, der bei der Ausführung der Softwareanwendung so konfiguriert ist, dass er die Schritte eines computerimplementierten Verfahrens nach einem der Ansprüche 1 bis 10 ausführt.