DE102019103340A1

DE102019103340A1 - Simultanes rechen- und grafik-scheduling

Info

Publication number: DE102019103340A1
Application number: DE102019103340.3A
Authority: DE
Inventors: Rajballav Dash; Gregory PALMER; Gentaro Hirota; Lacky Shah; Jack Choquette; Emmett Kilgariff; Sriharsha Niverty; Milton Lei; Shirish Gadre; Omkar PARANJAPE; Lei Yang; Rouslan Dimitrov
Original assignee: Nvidia Corp
Current assignee: Nvidia Corp
Priority date: 2018-08-02
Filing date: 2019-02-11
Publication date: 2020-02-06
Also published as: CN110796588B; US11367160B2; CN110796588A; US20200043123A1

Abstract

Eine Parallelverarbeitungseinheit (z.B. eine GPU) beinhaltet in manchen Beispielen einen Hardware-Scheduler und einen Hardware-Arbiter, die Grafik- und Rechenarbeit zur gleichzeitigen Ausführung auf einer SIMD/SIMT-Verarbeitungseinheit starten. Jede Verarbeitungseinheit (z.B. ein Streaming-Multiprozessor) der Parallelverarbeitungseinheit arbeitet zu jeweiligen Zeiten in einem grafikhungrigen Modus oder einem rechenhungrigen Modus. Der Hardware-Arbiter kann als Reaktion auf ein Ergebnis eines Vergleichs zumindest einer überwachten Leistungs- oder Auslastungsmetrik mit einem benutzerdefinierten Schwellenwert die Verarbeitungseinheit selektiv dazu veranlassen, ein oder mehrere Rechen-Arbeitselemente aus einer Rechen-Warteschlange auszuführen, wenn die Verarbeitungseinheit in dem grafikhungrigen Modus arbeitet, und die Verarbeitungseinheit dazu veranlassen, ein oder mehrere Grafik-Arbeitselemente aus einer Grafik-Warteschlange auszuführen, wenn die Verarbeitungseinheit in dem rechenhungrigen Modus arbeitet. Zugeordnete Verfahren und Systeme werden ebenfalls beschrieben.

Description

QUERVERWEIS AUF VERWANDTE ANMELDUNGEN
Diese Anmeldung bezieht sich auf die am 20. Dezember 2013 eingereichte US-Patentanmeldung Nr. 14/137,818 mit dem Titel „System, method, and computer program product for simultaneous execution of compute and graphics workloads“.
GEBIET DER ERFINDUNG
Die Erfindung bezieht sich auf ein Planen von Aufgaben auf einem Rechenprozessor, insbesondere auf ein Planen von Grafikaufgaben und Rechenaufgaben auf einer Parallelverarbeitungseinheit, wie beispielsweise einer Grafikverarbeitungseinheit (GPU), und insbesondere auf das Planen von Grafikaufgaben und Rechenaufgaben zur gleichzeitigen Ausführung auf derselben Verarbeitungseinheit in einer Gruppe von Verarbeitungseinheiten einer Parallelverarbeitungseinheit (wie beispielsweise einer GPU).
HINTERGRUND
Eine Möglichkeit, die Leistung eines Verarbeitungssystems zu steigern, besteht darin, parallele Verarbeitungskerne zu verwenden, die viele Befehlsströme parallel ausführen können. In den letzten Jahren haben Zentralverarbeitungseinheiten (CPUs) und Grafikverarbeitungseinheiten (GPUs) von dieser gesteigerten Parallelität profitiert. Beispielsweise können superskalare Prozessoren mehrere Anweisungen an verschiedene Ausführungseinheiten senden, wodurch die durchschnittliche Ausführungsgeschwindigkeit erhöht wird. Ebenso haben viele moderne GPUs massiv parallele Verarbeitungsarchitekturen, was bedeutet, dass sie viele parallele Prozessoren enthalten, die parallel an verschiedenen Teilen eines Grafikbildes arbeiten können.
In der Vergangenheit waren GPU-Funktionen auf eine genau definierte Anzahl von Grafikoperationen beschränkt. Dies änderte sich, als GPUs programmierbar wurden. So hat NVidia beispielsweise 2001 seine GEForce3 NV20 GPU mit programmierbaren Eckpunkt- bzw. Vertex- und Pixel-Shadern auf den Markt gebracht. Später entwickelte Nvidia die parallele Rechenplattform CUDA® und das Programmiermodell für allgemeines Rechnen auf Grafikverarbeitungseinheiten (GPUs). Mit CUDA® konnten Entwickler Rechenanwendungen drastisch beschleunigen, indem sie GPU-Verarbeitungsfähigkeiten zur Ausführung von Rechenaufgaben zusätzlich zu Grafikaufgaben nutzten.
GPUs sind typischerweise darauf spezialisiert, große Datenblöcke zu verarbeiten, indem sie parallel eine große Anzahl von Threads verarbeiten, die sich auf einen bestimmten Kontext beziehen. Beispielsweise kann die GPU zunächst einem Grafikkontext zugeordnet sein, in dem alle GPU-Threads dazu konfiguriert sind, Grafikdaten parallel zu verarbeiten. Wenn die GPU mit dem Rendern von Grafiken fertig ist, kann die CPU die GPU auf einen anderen Kontext umschalten und alle GPU-Ressourcen für eine Rechendatenverarbeitung (außer Grafiken) umwidmen.
Wie hierin verwendet umfasst ein GPU-Grafikkontext den Zustand, der sich auf die Ausführung von Anweisungen auf der GPU für die Verarbeitung von Grafikdaten, wie z.B. das Rendern von 3D-Modelldaten zur Erzeugung von 2D-Bilddaten, die Verarbeitung von Texturen, das Erzeugen von weichen Schatten usw. bezieht. Ein GPU-Rechenkontext umfasst den Zustand, der sich auf das Ausführen von Anweisungen auf der GPU bezieht, um allgemeine parallele Berechnungen, wie beispielsweise physikalische Berechnungen, die in Animationen oder in der Analyse großer Datensätze verwendet werden, durchzuführen. Viele herkömmliche GPUs können so konfiguriert werden, dass sie entweder einen Grafikkontext oder einen Rechenkontext verarbeiten, aber nicht beide gleichzeitig. Das Betriebssystem kann die GPU während der Ausführung bei Bedarf dynamisch von einem Kontext auf einen anderen umschalten, um Grafikaufgaben oder Rechenaufgaben zu verarbeiten.
Die Möglichkeit, die Zuordnung von zumindest einigen Verarbeitungsfunktionen zwischen Grafikaufgaben und Rechenaufgaben dynamisch zu ändern, ohne einen Kontextwechsel zu erfordern, ist für viele Anwendungen erwünscht und kann die Verarbeitungsgeschwindigkeit von Anwendungen potenziell erhöhen und auch die Ressourcenauslastung verbessern. Beispielsweise kann der Grafikprozessor während der Grafikverarbeitung einige Grafikverarbeitungs-Threads oder -Warps abschließen, während er andere Grafikverarbeitungs-Threads oder -Warps weiter ausführt. Wenn ein Kontextwechsel von Grafik zu Berechnung erforderlich ist, bevor die GPU Rechen-Threads oder -Warps ausführen kann, müsste indessen die GPU die gesamte Grafikverarbeitung abschließen, bevor sie irgendwelche Verarbeitungsressourcen für Rechenfunktionen zuweisen kann, wodurch die Latenz erhöht und die Prozessorauslastung reduziert wird.
Einige andere GPUs ermöglichten es, einige der Verarbeitungseinheiten für Grafikverarbeitung und die anderen Verarbeitungseinheiten für Rechenverarbeitung zuzuweisen, und ermöglichten es, das Verhältnis der Zuweisung der Verarbeitungseinheiten zwischen Grafik und Berechnung ohne Kontextwechsel zu ändern. Siehe beispielsweise die Druckschrift USP 9,626,216 , welche eine GPU dazu konfiguriert hat, eine erste Arbeitslast und eine zweite Arbeitslast in Übereinstimmung mit dem universellen Verarbeitungskontext auszuführen und von der Ausführung der ersten Arbeitslast zu der Ausführung der zweiten Arbeitslast überzugehen, ohne einen Kontextwechsel auszuführen. Diese GPUs ermöglichten die gleichzeitige Ausführung von Grafikaufgaben auf einigen der Verarbeitungseinheiten, während die anderen Verarbeitungseinheiten Rechenaufgaben durchführten. Zumindest einige dieser früheren kommerziellen Implementierungen können jedoch eine Entleerung laufender Arbeit aus einer GPU-Verarbeitungseinheit erfordern, bevor diese Verarbeitungseinheit von Grafik zu Berechnung umverteilt werden kann - welches Ineffizienzen und Verzögerungen verursachen kann. Außerdem ist die Notwendigkeit, Ressourcen auf der Ebene der Verarbeitungseinheiten zuzuweisen, oft eine weitere Ursache für Ineffizienzen.
Es besteht Bedarf an Systemen mit Planungs- oder Zuteilungs- bzw. Scheduling-Techniken, die Reaktionszeiten und/oder die Auslastung bzw. Nutzung der Verarbeitungsressourcen verbessern können, indem sie eine flexiblere Zuordnung von Prozessoren zwischen Grafikfunktionen und Rechenfunktionen ermöglichen, ohne jedoch die Fähigkeit der GPU, Grafikverarbeitung schnell durchzuführen, übermäßig zu beeinträchtigen.
KURZBESCHREIBUNG
Beispielhafte Ausführungsbeispiele beheben einige der Mängel der vorstehend beschriebenen Techniken zur Aufteilung der Verarbeitungsressourcen einer GPU zwischen Grafik- und Rechenaufgaben.
Verfahren, computerlesbare Medien und Systeme werden offenbart, um einen Streaming-Multiprozessor in einer Parallelverarbeitungseinheit so zuzuteilen, dass zumindest ein Grafik-Warp und zumindest ein Rechen-Warp gleichzeitig parallel ausgeführt werden.
Ein beispielhaftes Ausführungsbeispiel stellt eine Grafikverarbeitungseinheit mit einem Streaming-Multiprozessor, der parallele Befehlsströme ausführt, und einem mit dem Streaming-Multiprozessor verbundenen Scheduler bereit. Der Scheduler teilt den Streaming-Multiprozessor so zu, dass er zumindest einen Grafik-Warp und zumindest einen Rechen-Warp gleichzeitig parallel ausführt.
Ein weiteres beispielhaftes Ausführungsbeispiel stellt eine Parallelverarbeitungseinheit mit einer Vielzahl von Verarbeitungseinheiten, einem Hardware-Scheduler und einem Hardware-Arbiter bereit. Jede Verarbeitungseinheit ist dazu konfiguriert, zu jeweiligen Zeiten in einem grafikhungrigen Modus oder einem rechenhungrigen Modus zu arbeiten und gleichzeitig Grafik-Arbeitselemente aus einer Grafik-Warteschlange und Rechen-Arbeitselemente aus einer Rechen-Warteschlange auszuführen. Der Hardware-Scheduler ist dazu konfiguriert, kontinuierlich Grafik-Arbeitselemente aus der Grafik-Warteschlange für den Ablauf auf einer bestimmten Verarbeitungseinheit auszuwählen, wenn die bestimmte Verarbeitungseinheit dazu konfiguriert ist, in dem grafikhungrigen Modus zu arbeiten, und kontinuierlich Rechen-Arbeitselemente aus der Rechen-Warteschlange für den Ablauf auf der bestimmten Verarbeitungseinheit auszuwählen, wenn die bestimmte Verarbeitungseinheit dazu konfiguriert ist, in dem rechenhungrigen Modus zu arbeiten. Der Hardware-Arbiter ist dazu konfiguriert, im Ansprechen bzw. als Reaktion auf ein Ergebnis eines Vergleichs von zumindest einer überwachten Leistungs- oder Auslastungsmetrik mit einem benutzerdefinierten Schwellenwert die bestimmte Verarbeitungseinheit selektiv dazu zu veranlassen, ein oder mehrere Rechen-Arbeitselemente aus der Rechen-Warteschlange auszuführen, wenn die bestimmte Verarbeitungseinheit dazu konfiguriert ist, in dem grafikhungrigen Modus zu arbeiten, und die bestimmte Verarbeitungseinheit zu veranlassen, ein oder mehrere Grafik-Arbeitselemente aus der Grafik-Warteschlange auszuführen, wenn die bestimmte Verarbeitungseinheit dazu konfiguriert ist, in dem rechenhungrigen Modus zu arbeiten.
Ein weiteres beispielhaftes Ausführungsbeispiel stellt ein Verfahren zum gleichzeitigen Ausführen von Grafik-Arbeitselementen und Rechen-Arbeitselementen auf einem Parallelprozessor bereit, der eine Vielzahl von Verarbeitungseinheiten aufweist. Das Verfahren beinhaltet ein Empfangen der Grafik-Arbeitselemente von einer Grafik-Pipeline und der Rechen-Arbeitselemente von einer Rechen-Pipeline und ein Planen bzw. Zuteilen einer ersten Gruppe der Grafik-Arbeitselemente und einer zweiten Gruppe der Rechen-Arbeitselemente so, dass diese gleichzeitig auf einer ausgewählten Single Instruction Multiple Data (SIMD)- oder Single Instruction Multiple Thread (SIMT)-Verarbeitungseinheit der Vielzahl von Verarbeitungseinheiten ausgeführt werden.
Ein weiteres beispielhaftes Ausführungsbeispiel stellt ein System mit einer CPU, die dazu konfiguriert ist, eine Anwendung auszuführen, einem Speicher, der dazu konfiguriert ist, eine Grafik-Warteschlange und eine Rechen-Warteschlange aufzuweisen, sowie einer Grafikverarbeitungseinheit bereit. Die Grafikverarbeitungseinheit beinhaltet eine Vielzahl von Verarbeitungseinheiten, einen Hardware-Scheduler und einen Hardware-Arbiter. Jede Verarbeitungseinheit ist dazu konfiguriert, jeweils in einem grafikhungrigen Modus oder einem rechenhungrigen Modus zu arbeiten und Grafik-Arbeitselemente aus einer Grafik-Warteschlange und Rechen-Arbeitselemente aus einer Rechen-Warteschlange gleichzeitig auszuführen. Der Hardware-Scheduler ist dazu konfiguriert, kontinuierlich Grafik-Arbeitselemente aus der Grafik-Warteschlange zum Ablauf auf einer bestimmten Verarbeitungseinheit auszuwählen, wenn die bestimmte Verarbeitungseinheit für den Betrieb in dem grafikhungrigen Modus konfiguriert ist, und kontinuierlich Rechen-Arbeitselemente aus der Rechen-Warteschlange zum Ablauf auf der bestimmten Verarbeitungseinheit auszuwählen, wenn die bestimmte Verarbeitungseinheit für den Betrieb in dem rechenhungrigen Modus konfiguriert ist. Der Hardware-Arbiter ist dazu konfiguriert, als Reaktion auf ein Ergebnis eines Vergleichs von zumindest einer überwachten Leistungs- oder Auslastungsmetrik mit einem benutzerdefinierten Schwellenwert die bestimmte Verarbeitungseinheit selektiv dazu zu veranlassen, ein oder mehrere Rechen-Arbeitselemente aus der Rechen-Warteschlange auszuführen, wenn die bestimmte Verarbeitungseinheit dazu konfiguriert ist, in dem grafikhungrigen Modus zu arbeiten, und die bestimmte Verarbeitungseinheit zu veranlassen, ein oder mehrere Grafik-Arbeitselemente aus der Grafik-Warteschlange auszuführen, wenn die bestimmte Verarbeitungseinheit dazu konfiguriert ist, in dem rechenhungrigen Modus zu arbeiten.
Figurenliste

1 veranschaulicht ein System, in dem Grafik-Arbeitselemente und Rechen-Arbeitselemente gleichzeitig in einer von mehreren Single Instruction Multiple Data (SIMD)- oder Single Instruction Multiple Thread (SIMT)-Verarbeitungseinheiten einer Parallelverarbeitungseinheit, wie beispielsweise einer GPU, verarbeitet werden können, gemäß einigen beispielhaften Ausführungsbeispielen.
2A veranschaulicht ein Ablaufdiagramm eines Scheduling-Prozesses gemäß einigen beispielhaften Ausführungsbeispielen.
2B zeigt eine beispielhafte Warp-Ebenen-Ansicht der Arbeit an einer Verarbeitungseinheit gemäß einer konventionellen Technik.
2C zeigt eine beispielhafte Warp-Ebenen-Ansicht der Arbeit an einer Verarbeitungseinheit (z.B. einem einzelnen Streaming-Multiprozessor) einer GPU, gemäß einigen beispielhaften Ausführungsbeispielen.
3 veranschaulicht eine Parallelverarbeitungseinheit gemäß einem Ausführungsbeispiel.
4A veranschaulicht einen allgemeinen Verarbeitungscluster innerhalb der Parallelverarbeitungseinheit von 3 gemäß einem Ausführungsbeispiel.
4B veranschaulicht eine Speicherpartitionierungseinheit der Parallelverarbeitungseinheit von 3 gemäß einem Ausführungsbeispiel.
5A veranschaulicht den Streaming-Multiprozessor von 4A gemäß einem Ausführungsbeispiel.
5B ist ein konzeptionelles Diagramm eines Verarbeitungssystems, das unter Verwendung der Parallelverarbeitungseinheit (PPU) von 3 implementiert wird, gemäß einem Ausführungsbeispiel.
5C veranschaulicht ein beispielhaftes System, in dem die unterschiedliche Architektur und/oder Funktionalität der verschiedenen vorherigen Ausführungsbeispiele implementiert sein kann.
6 ist ein konzeptionelles Diagramm einer Grafikverarbeitungs-Pipeline, die von der PPU von 3 implementiert wird, gemäß einem Ausführungsbeispiel.
7 veranschaulicht schematisch weitere Einzelheiten des Schedulers und des Arbiters, die in Bezug auf 1 und 2 beschrieben sind, gemäß einigen beispielhaften Ausführungsbeispielen.
8 veranschaulicht einen Prozess, durch welchen eine Anwendung die Scheduling- bzw. Zuteilungsrichtlinie konfigurieren kann, um einige Aspekte davon zu steuern, wie eine GPU (oder andere Art von PPU) ihre Grafik-Arbeitselemente und ihre Rechen-Arbeitselemente zuteilt.
9 zeigt ein Ablaufdiagramm eines Prozesses, der von einem Scheduler, wie beispielsweise dem Scheduler, durchgeführt werden kann, gemäß einigen beispielhaften Ausführungsbeispielen.
10 zeigt ein Ablaufdiagramm eines Prozesses, der von einem Arbiter, wie beispielsweise dem Arbiter, durchgeführt werden kann, gemäß einigen beispielhaften Ausführungsbeispielen.
11 veranschaulicht ein Ablaufdiagramm eines Prozesses, der von einer Anwendung oder einem anderen Programm an einem Host-Prozessor, wie beispielsweise einer CPU, ausgeführt werden kann, um ein oder mehrere Scheduling- bzw. Zuteilungsprofile und einen Zeitgeber zum Umschalten zwischen den Zuteilungsprofilen zu konfigurieren.
12 veranschaulicht ein Ablaufdiagramm eines Prozesses, der in einer GPU, oder in einigen Ausführungsbeispielen in einem M-Pipe Controller (MPC), ausgeführt werden kann, um Scheduler-Profile in einer Sequenz von konfigurierten Scheduler-Profilen umzuschalten bzw. zu wechseln.
13 veranschaulicht ein Ablaufdiagramm für einen Leerlauferkennungsprozess 1300 gemäß einigen beispielhaften Ausführungsbeispielen.

DETAILLIERTE BESCHREIBUNG
Beispielhafte Ausführungsbeispiele beseitigen einige der Mängel der vorstehend beschriebenen Techniken zur Aufteilung der Verarbeitungsressourcen einer GPU zwischen Grafik- und Rechenaufgaben. Beispielhafte Ausführungsbeispiele stellen beispielsweise einen Hardware-Scheduler bereit, der unabhängige Warteschlangen von Grafik- und Rechenarbeit auf einer Parallelverarbeitungseinheit (z.B. einer GPU) zur gleichzeitigen Ausführung effizient planen kann. Insbesondere ist dieser Hardware-Scheduler dazu konfiguriert, Rechenressourcen (z.B. Streaming-Multiprozessoren, die als SM's bezeichnet werden) optimal zu nutzen, indem er Zuteilungsentscheidungen auf Thread-Gruppen-Granularität (z.B. Warp-Granularität) basierend auf softwarespezifischen Zuteilungskontrollen und lokalisierter Rückmeldung der Ausführungseinheiten darüber, wie beschäftigt sie sind, trifft. Einige beispielhafte Ausführungsbeispiele ermöglichen es, eine GPU-Verarbeitungseinheit wie beispielsweise einen SM zwischen einer Grafik-Pipeline und einer Rechen-Pipeline zu teilen, indem ein oder mehrere Grafik-Warps und ein oder mehrere Rechen-Warps so gestartet werden, dass sie gleichzeitig auf demselben SM ausgeführt werden, wodurch der SM zwischen Grafik- und Rechenfunktionen geteilt bzw. gemeinsam genutzt wird, ohne dass ein Kontextwechsel oder die Beendigung einer der Funktionsarten erforderlich ist.
GPUs gemäß Ausführungsbeispielen sind dazu konfiguriert, Grafik-Shader (z.B. Vertex-, Tessellierungs- und Geometrie (VTG)-Shader, Pixel-Shader usw.) auszuführen und Rechen-Shader gleichzeitig auf einem einzigen SM auszuführen. Ein Rechen-Shader ist eine programmierbare Shader-Stufe, die eine konventionelle Grafik-Anwendungsprogrammierschnittstelle (API), wie beispielsweise Microsoft Direct3D 11, über die Grafikprogrammierung hinaus erweitert. Dies bedeutet, dass Warps aller Arten von Arbeiten gleichzeitig auf demselben SM ausgeführt werden können und die Warps um SM-Ressourcen, wie z.B. Registerdateispeicher, interne Stufenpuffer-Einträge (internal stage buffer entry; ISBE), gemeinsam genutzten Speicherplatz, SM-ALU-Ressourcen, L1-Cache-Bandbreite, Crossbar-Switch-Bandbreite, Frame-Puffer-Bandbreite usw., konkurrieren können.
Ausführungsbeispiele sehen vor, dass die GPU Rechen- und Grafikarbeiten auf Warp-Granularität zuteilt, während sie darüber hinaus, Software bereitstellend zum Geben von Zuteilungshinweisen an den Hardware-Scheduler zusammen mit Arbeit zum Optimieren der Leistung über verschiedene Arbeitsbereiche hinweg, ein Festlegen einer Rechenpriorität vis-à-vis einer Grafikpriorität pro Rechenkernstart ermöglicht, Rückmeldungen von den Ausführungseinheiten auf der GPU bereitstellt, um den Scheduler auf dem Laufenden zu halten, wenn er versucht, Zuteilungsentscheidungen zu treffen, und ermöglicht, Grafikarbeit über die Ausführungseinheiten hinweg gleichmäßig zu verteilen, um eine Unterauslastung usw. aufgrund der reihenfolgenbasierten Natur der Grafik-Pipeline zu reduzieren. Beispielhafte Ausführungsbeispiele verwenden einen hardwareimplementierten simultanen Rechen- und Grafik-Arbiter (SCG-SM-Arbiter), um SM-Belegungs- und Auslastungsstatistiken oder andere Metriken bzw. Kennzahlen einzulesen, um den Zeit-/Raum-Zuweisungsprozentsatz des SMs für Grafik gegenüber Berechnung zu bestimmen.
Frühere GPUs, wie die in der US-Anmeldung Nr. 14/137,818 beschriebene GPU, ermöglichten es einem Scheduler in Hardware, das Verhältnis von Grafik- zu Rechengruppen von SMs zur Laufzeit anzupassen. Allerdings war Software erforderlich, um die Bestimmungen bezüglich der geeigneten Mischung von Gruppen von SMs zu treffen und diese während des Frames mittels Rechenmethoden während der Ausführung der Arbeit anzupassen. Allerdings sind die Grafik- und Rechenlasten in vielen praktischen Szenarien asynchron und kommen zu zufälligen Zeiten und mit zufälliger Ausrichtung an, so dass eine Anpassung der Zuteilung über ein Rechenverfahren zur Laufzeit für Software unpraktisch ist. Beispielhafte Ausführungsbeispiele können gegenüber früheren Techniken auch in Eigenschaften, wie z.B. fest programmierten, rechenhungrigen Richtlinien, die nicht flexibel genug sind, um dynamisch auf unterschiedliche Arbeitslasten zu reagieren, die Unfähigkeit, Ressourcen weder der Berechnung noch der Grafik zuzuweisen (z.B. bei Nur-Z-Rendering oder 2D-Zeichnungen), hohen Latenzen im Zusammenhang mit der Entleerung von SMs und die hohe Zuordnungsgranularität, die sich auf einen gesamten SM bezieht, usw. Verbesserungen zeigen.
Zu den Vorteilen der Ausführungsbeispiele gehören verbesserte Ausführungsgeschwindigkeiten, verbesserte Ressourcenauslastung usw. aufgrund der grundlegenden Unterstützung einer dynamischen Zuordnung einzelner Verarbeitungseinheiten wie beispielsweise SMs zwischen Rechen- und Grafikaufgaben. Unter den vielen Vorteilen von Ausführungsbeispielen ist eine verbesserte Unterstützung für asynchrones Rechnen auch im Hinblick auf herkömmliche Grafik-APIs wie die DirectX 12 (DX12)-API relevant, welche die Entwicklung asynchroner Rechentechniken in Spielen stark fördert. Gleichzeitige Berechnung und Grafik ist ein wesentliches Merkmal der DX12-API. Die in beispielhaften Ausführungsbeispielen für Grafik und Berechnung bereitgestellte Fähigkeit, gleichzeitig auf demselben SM zu laufen, vermeidet neben anderen Vorteilen auch die Latenzprobleme und dergleichen, die in früheren Ansätzen auftreten, bei denen beispielsweise ein Entleerungsprotokoll erforderlich war, um die Fertigstellung aller Grafik-Warps zu erzwingen, bevor ein SM auf die Ausführung von Rechen-Warps umgestellt wird.
System und Verfahren zur gleichzeitigen Ausführung von Berechnungen und Grafik auf einem SM
1 veranschaulicht ein System 100, in dem Grafik-Arbeitselemente und Rechen-Arbeitselemente gleichzeitig in einer von mehreren Single Instruction Multiple Data (SIMD)- oder Single Instruction Multiple Thread (SIMT)-Verarbeitungseinheiten einer Parallelverarbeitungseinheit 102, wie beispielsweise einer GPU verarbeitet werden können, gemäß einigen beispielhaften Ausführungsbeispielen. Eine beispielhafte Parallelverarbeitungseinheit wird nachstehend unter Bezugnahme auf 3 beschrieben. In dem System 100 ist die SIMD-Verarbeitungseinheit 104 mit einem ersten Satz einer oder mehrerer Grafikaufgaben 106 und einem zweiten Satz einer oder mehrerer Rechenaufgaben 108, die gleichzeitig ausgeführt werden, gezeigt. Dies steht im Gegensatz zu früheren Systemen, wie z.B. dem in der am 20. Dezember 2013 eingereichten gemeinsamen US-Anmeldung Nr. 14/137,818 beschriebenen System, in der eine GPU zwar gleichzeitig Grafikaufgaben und Rechenaufgaben auf separaten Verarbeitungseinheiten verarbeiten kann, eine solche gleichzeitige Ausführung aber nicht in derselben SIMD-Verarbeitungseinheit der GPU erfolgte. Eine „Verarbeitungseinheit“, wie sie in dieser Erfindung verwendet wird, bezieht sich auf eine SIMD- oder SIMT-Verarbeitungseinheit, wie beispielsweise, aber nicht beschränkt auf, einen Streaming-Multiprozessor (SM), wie er nachstehend unter Bezugnahme auf 4A beschrieben wird. Wie in den 3 und 4A gezeigt ist, beinhaltet die beispielhafte PPU 300 mehrere SMs in jedem ihrer Rechenkerne 350.
Der erste Satz von Grafikaufgaben 106 und der zweite Satz von Rechenaufgaben 108 werden zur gleichzeitigen Ausführung auf der Verarbeitungseinheit 104 durch einen Hardware-Scheduler 110 eingeplant bzw. zugeteilt, der Aufgaben aus einer Grafik-Warteschlange 114 von Grafik-Arbeitselementen und einer Rechen-Warteschlange 116 von Rechen-Arbeitselementen in einem Speicher 117 zuteilt. Die Grafik-Arbeitselemente in der Grafik-Warteschlange 114 können von einer oder mehreren Grafik-Pipelines eingereiht werden, und die Rechen-Arbeitselemente in der Rechen-Warteschlange 116 können von einer oder mehreren Rechen-Pipelines eingereiht werden. Eine „Grafik-Pipeline“ (ein Beispiel ist in 6 dargestellt) ist ein Satz von logischen Stufen in der Verarbeitung von Grafikdaten mit Bezug zu einem Schattieren von Pixeln für ein Bild, wobei jede Stufe nach Art einer Pipeline separat zugeteilt werden kann. Eine „Rechen-Pipeline“ ist ein Satz von logischen Stufen zur Verarbeitung von Daten, die nicht in direktem Zusammenhang mit dem Schattieren von Pixeln in einem Bild stehen. Beispielhafte Rechen-Pipelines können physikalische Berechnungen beinhalten, die der Erzeugung eines Modells für eine Animation, der Analyse großer Datenmengen aus dem wissenschaftlichen oder finanziellen Bereich usw. zugeordnet sind, sind aber nicht darauf beschränkt.
Der Hardware-Scheduler 110 ist dazu konfiguriert, entweder in einem „grafikhungrigen Modus“, in dem er wiederholt Arbeitselemente aus der Grafik-Warteschlange 114 extrahiert und zu der Verarbeitungseinheit 104 hin startet, oder in einem „rechenhungrigen Modus“, in dem er wiederholt Arbeitselemente aus der Rechen-Warteschlange 116 extrahiert und zu der Verarbeitungseinheit 104 hin startet, zu arbeiten.
Ein Hardware-Arbiter 112 überwacht die Leistung und/oder Nutzung bzw. Auslastung der der Verarbeitungseinheit 104 zugeordneten Ausführungs- und Speicherressourcen und bestimmt unter Berücksichtigung benutzer- oder softwaredefinierter Konfigurationsparameter für Richtlinien und/oder Aufgabenprioritäten, ob zwischen der wiederholten Auswahl von Aufgaben des hungrigen Typs zur Ausführung in der Verarbeitungseinheit 104 Aufgaben des aktuellen nicht-hungrigen Typs zum Start einzufügen sind. Genauer gesagt überwacht der Hardware-Arbiter 112 kontinuierlich (oder periodisch zu konfigurierbaren Zeitpunkten) 113 Laufzeitstatistiken eines vorbestimmten Satzes von Verarbeitungs- oder Speicherressourcen, um „Lücken“ (z.B. überschüssige ungenutzte Kapazität) in der aktuellen Ressourcenverwendung zu identifizieren, die dann durch Starten einiger Aufgaben des nicht-hungrigen Typs aufgebraucht (z.B. belegt) werden können. Die Lücken können auch als „Möglichkeiten“ betrachtet werden, eine oder mehrere Aufgaben des nicht-hungrigen Typs zu starten, während der Hardware-Scheduler 110 in einem bestimmten hungrigen Modus arbeitet. Der Hardware-Arbiter 112 kann ein Signal 111 an den Hardware-Scheduler 110 liefern, das diesen über alle erkannten Lücken informiert.
In beispielhaften Ausführungsbeispielen beinhaltet jede Verarbeitungseinheit einen Hardware-Scheduler 110 und einen Hardware-Arbiter 112. Beispielsweise kann in 4A jeder SM 440 einen zugehörigen Hardware-Scheduler 110 und einen zugehörigen Hardware-Arbiter 112 aufweisen, die innerhalb seines Datenverarbeitungsclusters (DPC) angeordnet sind.
Die von dem Hardware-Arbiter 112 durchgeführte Überwachung kann in Übereinstimmung mit Richtlinien 120 erfolgen, die von einer Anwendung 122 und/oder einer Treibersoftware, die auf einer CPU 124 ausgeführt wird, konfiguriert werden. Die Richtlinien 120 können die Art des Hardware-Arbiters (z.B. die Art des SCG-SM-Arbiters), Schwellenwerte für das Bestimmen von Lücken in der aktuellen Ressourcennutzung, Raten, mit welchen nicht-hungrige Aufgaben bei Erkennung einer Lücke zu starten sind, usw. festlegen. Die Anwendung 122 kann ein Rechenspiel (z.B. auch als Videospiel bezeichnet) oder eine andere Anwendung sein, die sowohl Grafikanforderungen, die Arbeitselemente in die Grafik-Warteschlange 114 einreihen, als auch Rechenanforderungen, die Arbeitselemente in die Rechen-Warteschlange 116 einreihen, hat. Die Anwendung kann ihre Arbeitselemente 126 mit zugehörigen Aufgabenprioritäten an den Speicher 117 und ihre entsprechenden Anweisungen 128 an die Parallelverarbeitungseinheit (PPU) 102 übertragen.
2A veranschaulicht ein Ablaufdiagramm eines Scheduling-Prozesses 200 gemäß einigen beispielhaften Ausführungsbeispielen. Der Scheduling-Prozess 200 kann beispielsweise in der PPU 102 von Hardwareeinheiten durchgeführt werden, die den Hardware-Scheduler 110 und den Hardware-Arbiter 112 beinhalten, um Grafikaufgaben und Rechenaufgaben dynamisch zu planen, um sie gleichzeitig auf derselben SIMD-Verarbeitungseinheit 104 auszuführen.
Nach dem Eintreten in den Prozess 200 startet der Hardware-Scheduler bei Operation 202 wiederholt Arbeitselemente aus entweder einer Grafik-Warteschlange oder einer Rechen-Warteschlange in Übereinstimmung mit dem aktuellen Prioritätsmodus zur Ausführung auf einer Verarbeitungseinheit wie beispielsweise der Verarbeitungseinheit 104 (z.B. SM). Beispielsweise können in dem grafikhungrigen Modus Aufgaben aus der Grafik-Warteschlange wiederholt gestartet werden, und können in dem rechenhungrigen Modus Aufgaben aus der Rechen-Warteschlange wiederholt gestartet werden. Der Prioritätsmodus (z.B. grafikhungrig oder rechenhungrig) kann auf verschiedene Weisen festgelegt werden. In einigen Ausführungsbeispielen basiert der Prioritätsmodus auf der höheren der Prioritäten jeweiliger Elemente in der Grafik-Warteschlange und der Rechen-Warteschlange.
Bei Operation 204 kann eine „Lücke“ in der aktuellen Nutzung bzw. Auslastung einer oder mehrerer Ressourcen als ein Ergebnis der Überwachung von mit der Verarbeitungseinheit verbundenen Ressourcen erkannt werden. Die Lücke kann durch Vergleichen der aktuellen Auslastung (wie repräsentiert durch Statistiken, die über ein Zeitintervall hinweg gemittelt werden) mit einem oder mehreren Schwellenwerten, die in einer Scheduling-Richtlinie spezifiziert sind, erkannt werden.
Bei Operation 206 startet der Scheduler als Reaktion auf das Erkennen einer Lücke ein oder mehrere Arbeitselemente aus der Warteschlange für die aktuelle nicht-hungrige Priorität. Während des Betriebsablaufs in dem grafikhungrigen Modus kann beispielsweise eine Erkennung einer Lücke den Scheduler veranlassen, einige Rechen-Arbeitselemente zu starten, oder kann alternativ eine Lücke, die während des Betriebsablaufs in dem rechenhungrigen Modus erkannt wird, den Scheduler veranlassen, einige Grafik-Arbeitselemente zu starten. Die Arbeitselemente nicht-hungriger Priorität, die gestartet werden, können in Übereinstimmung mit der Ressourcenverfügbarkeit, die durch die erkannte Lücke angegeben wird, und/oder einer in einer aktuell aktiven Scheduling-Richtlinie festgelegten Bruchteilsrate bestimmt werden.
Folglich kann bei Operation 206 die Verarbeitungseinheit Grafik-Arbeitselemente und Rechen-Arbeitselemente haben, die gleichzeitig auf ihr ausgeführt werden und um gemeinsame Ressourcen konkurrieren.
Obwohl das Verfahren 200 im Kontext einer Verarbeitungseinheit und gewissen Hardwarekomponenten beschrieben wird, kann das Verfahren 200 auch durch eine benutzerdefinierte Schaltungsanordnung oder durch eine Kombination aus einer benutzerdefinierten Schaltungsanordnung und einem Programm durchgeführt werden. Beispielsweise kann das Verfahren 200 von einer GPU (Grafikverarbeitungseinheit) oder von irgend einem oder mehreren Prozessoren ausgeführt werden, der/die zu den Operationen 202-206 in der Lage ist/sind. Ferner wird der Fachmann verstehen, dass jedes System, das das Verfahren 200 durchführt, innerhalb des Schutzumfangs und des Rahmens der Ausführungsbeispiele der Erfindung liegt.
Beispielhafte Warp-Arbeitslast-Verteilung
2B veranschaulicht eine beispielhafte Arbeitslast mit Grafik und Berechnung auf einer Verarbeitungseinheit in einer konventionellen GPU. Wie dargestellt ist, kann zu einem beliebigen bestimmten Zeitpunkt nur eine einzige Art von Warps die Verarbeitungseinheit belegen. Wie dargestellt ist, führt die Verarbeitungseinheit eine Sequenz aus, die ein vollständiges Komplement von Grafik-Warps, gefolgt von einem vollständigen Komplement von Rechen-Warps, und wiederum ein vollständiges Komplement von Grafik-Warps umfasst. Die Sequenz wird dann fortgesetzt, wobei nur ein Teil der Rechenaufgaben zugeteilt wird und ein Teil der Kapazität der Verarbeitungseinheit ungenutzt bleibt.
2C stellt eine veranschaulichende Warpzuordnung zu einer Verarbeitungseinheit im Zeitverlauf dar, gemäß bestimmten beispielhaften Ausführungsbeispielen. Beispielsweise kann die Verarbeitungseinheit in der Lage sein, eine Vielzahl (z.B. 32) von gleichzeitigen Warps zu haben. 2C veranschaulicht die Verarbeitungseinheit, die zunächst in einem grafikhungrigen Modus, dann kurz in einem rechenhungrigen Modus, und wieder in einem grafikhungrigen Modus arbeitet. Sie veranschaulicht auch, dass während der grafikhungrigen Abschnitte zu bestimmten Zeiten, wie z.B. bei der Erkennung von Lücken (Unterauslastung), eine geringe Anzahl von Rechen-Warps auf der Verarbeitungseinheit zugeteilt wurde. Die Bereiche in dem Graphen, in denen kein Füllmuster vorhanden ist, können darauf hinweisen, dass die Lücken in der Arbeitslast nach einer kleinen Zeitspanne erkannt werden (z.B. aufgrund der Mittelwertbildung der Statistiken über die Zeit). Der Bereich, in dem mehr als die Hälfte der Arbeitslast Rechen-Warps sind, kann eine rechenhungrige Zeitspanne mit einer beträchtlichen Anzahl von Grafik-Warps darstellen.
Ein Vergleich der 2B und 2C veranschaulicht eine bessere Auslastung der Kapazität der Verarbeitungseinheit in 2C, die repräsentiert, dass die Verarbeitungseinheit gemeinsam genutzt wird, und veranschaulicht auch, dass zumindest einige Warps des nicht-hungrigen Typs starten können, während ein bestimmter hungriger Modus aktiv ist.
Eine Analogie kann zumindest einige Aspekte eines beispielhaften Ausführungsbeispiels veranschaulichen. Ein Polizeibeamter, der manuell den Verkehr an einer Kreuzung regelt, an der Autos in zwei einwärts gerichteten Straßen auf eine einzige auswärts gerichtete Straße wollen, kann wie der Hardware-Scheduler sein, der Arbeit an einer bestimmten Verarbeitungseinheit aus zwei Arbeitswarteschlangen zuteilt. Auf der ersten einwärts gerichteten Spur befinden sich alle wichtigen Autos, und diese werden von dem Polizeibeamten so schnell wie möglich auf die auswärts gerichtete Straße gelassen. Während besonders belebter Zeitspannen, in denen die erste einwärts gerichtete Straße auf mehreren Fahrspuren voll ist, kann der Polizeibeamte einen Assistenten haben, der einen besseren Aussichtspunkt für die Beobachtung des Verkehrsniveaus hat. Der Assistent, wie beispielsweise der Hardware-Arbiter in beispielhaften Ausführungsbeispielen, kann gelegentlich, bei Beobachtung eines schwächeren Verkehrs, dem Polizeibeamten signalisieren, der wiederum schnell die eine oder andere kleine Anzahl von Autos aus der zweiten einwärts gerichteten Straße in die auswärts gerichtete Straße lässt. Folglich wird, auf ähnliche Weise wie eine bestimmte Verarbeitungseinheit, die in dem grafikhungrigen Modus arbeitet, zwischen gleichzeitigen Grafik- und Rechen-Warps geteilt wird, die auswärts gerichtete Straße zwischen den Fahrzeugen aus der ersten und der zweiten einwärts gerichteten Straße geteilt.
Nachstehend werden weitere veranschaulichende Informationen bezüglich verschiedener optionaler Architekturen und Funktionen gegeben, mit welchen das vorangehende Rahmenwerk nach den Wünschen des Benutzers implementiert werden kann oder nicht. Es versteht sich ausdrücklich, dass die folgenden Informationen zur Veranschaulichung gegeben werden und nicht als beschränkend auszulegen sind. Ein beliebiges der folgenden Merkmale kann wahlweise mit oder ohne Ausnahme anderer beschriebener Merkmale einbezogen werden.
Paralielverarbeitungsarchitektur
3 veranschaulicht eine Parallelverarbeitungseinheit (PPU) 300 gemäß einem Ausführungsbeispiel. In einem Ausführungsbeispiel ist die PPU 300 ein Multithread-Prozessor, der auf einer oder mehreren integrierten Schaltungsvorrichtungen implementiert ist. Die PPU 300 ist eine latenzverbergende Architektur, die entwickelt wurde, um eine große Anzahl von Threads parallel zu verarbeiten. Ein Thread (d.h. ein Thread der Ausführung) ist eine Instanziierung eines Satzes von Anweisungen, die dazu konfiguriert sind, von der PPU 300 ausgeführt zu werden. In einem Ausführungsbeispiel ist die PPU 300 eine Grafikverarbeitungseinheit (GPU), die dazu konfiguriert ist, eine Grafik-Rendering-Pipeline zum Verarbeiten von dreidimensionalen (3D) Grafikdaten zu implementieren, um zweidimensionale (2D) Bilddaten zur Anzeige auf einer Anzeigevorrichtung, wie beispielsweise einer Flüssigkristallanzeigevorrichtung (LCD), zu erzeugen. In anderen Ausführungsbeispielen kann die PPU 300 zum Durchführen von Universalberechnungen verwendet werden. Obwohl hierin ein beispielhafter Parallelprozessor zu veranschaulichenden Zwecken bereitgestellt ist, ist dringend darauf hinzuweisen, dass dieser Prozessor nur zu veranschaulichenden Zwecken beschrieben wird und jeder Prozessor als Ergänzung und/oder Ersatz für denselben verwendet werden kann.
Eine oder mehrere PPUs 300 können dazu konfiguriert sein, Tausende von High Performance Computing (HPC), Rechenzentren und Anwendungen maschinellen Lernens zu beschleunigen. Die PPU 300 kann dazu konfiguriert sein, zahlreiche Systeme und Anwendungen für Deep Learning zu beschleunigen, darunter autonome Fahrzeugplattformen, Deep Learning, hochpräzise Sprach-, Bild- und Texterkennungssysteme, intelligente Videoanalytik, molekulare Simulationen, Medikamentenentdeckung, Krankheitsdiagnose, Wettervorhersage, Big Data Analytik, Astronomie, Molekulardynamiksimulation, Finanzmodellierung, Robotik, Fabrikautomatisierung, Echtzeit-Sprachübersetzung, Online-Suchoptimierung und personalisierte Benutzerempfehlungen und dergleichen.
Wie in 3 gezeigt ist, beinhaltet die PPU 300 eine Eingabe/Ausgabe- bzw. Input/Output (I/O)-Einheit 305, eine Frontend-Einheit 315, eine Scheduler-Einheit 320, eine Arbeitsverteilungseinheit 325, einen Verteiler bzw. Hub 330, eine Kreuz- bzw. Querschiene (Crossbar; Xbar) 370, einen oder mehrere Universalverarbeitungscluster bzw. General Processing Cluster (GPC) 350 und eine oder mehrere Partitionierungseinheiten 380. Die PPU 300 kann über eine oder mehrere schnelle NVLink 310-Zwischenverbindungen mit einem Host-Prozessor oder anderen PPUs 300 verbunden sein. Die PPU 300 kann über eine Zwischenverbindung 302 mit einem Host-Prozessor oder anderen Peripheriegeräten verbunden sein. Die PPU 300 kann darüber hinaus mit einem lokalen Speicher verbunden sein, der eine Anzahl von Speichervorrichtungen 304 umfasst. In einem Ausführungsbeispiel kann der lokale Speicher eine Anzahl von dynamischen DRAM (Dynamic Random Access Memory)-Vorrichtungen umfassen. Die DRAM-Vorrichtungen können als ein HBM (High-Bandwidth Memory)-Subsystem konfiguriert sein, wobei mehrere DRAM-Dies in jeder Vorrichtung gestapelt sind.
Die NVLink 310-Verbindung ermöglicht es Systemen, zu skalieren und eine oder mehrere PPUs 300 kombiniert mit einer oder mehreren CPUs zu beinhalten, unterstützt Cache-Kohärenz zwischen den PPUs 300 und CPUs und CPU-Mastering. Daten und/oder Befehle können von dem NVLink 310 über den Hub 330 zu/von anderen Einheiten der PPU 300, wie z.B. einer oder mehreren Kopiermaschinen, einem Video-Encoder, einem Video-Decoder, einer Leistungsverwaltungseinheit usw. (nicht explizit dargestellt) übertragen werden. Der NVLink 310 wird in Verbindung mit 5B näher beschrieben.
Die I/O-Einheit 305 ist dazu konfiguriert, Kommunikationen (d.h. Befehle, Daten usw.) von einem Host-Prozessor (nicht gezeigt) über die Zwischenverbindung 302 zu senden und zu empfangen. Die I/O-Einheit 305 kann mit dem Host-Prozessor direkt über die Zwischenverbindung 302 oder über eine oder mehrere Zwischenvorrichtungen, wie beispielsweise eine Speicherbrücke, kommunizieren. In einem Ausführungsbeispiel kann die I/O-Einheit 305 mit einem oder mehreren anderen Prozessoren, wie beispielsweise einer oder mehreren der PPUs 300, über die Zwischenverbindung kommunizieren. In einem Ausführungsbeispiel implementiert die I/O-Einheit 305 eine Peripheral Component Interconnect Express (PCIe)-Schnittstelle für Kommunikationen über einen PCIe-Bus und ist die Zwischenverbindung 302 ein PCIe-Bus. In alternativen Ausführungsbeispielen kann die I/O-Einheit 305 andere Arten von gut bekannten Schnittstellen zur Kommunikation mit externen Vorrichtungen implementieren.
Die I/O-Einheit 305 dekodiert Pakete, die über die Zwischenverbindung 302 empfangen wurden. In einem Ausführungsbeispiel repräsentieren die Pakete Befehle, die dazu konfiguriert sind, die PPU 300 zu veranlassen, verschiedene Operationen durchzuführen. Die I/O-Einheit 305 überträgt die dekodierten Befehle an verschiedene andere Einheiten der PPU 300, wie in den Befehlen angegeben. Beispielsweise können einige Befehle an die Frontend-Einheit 315 übertragen werden. Andere Befehle können an den Hub 330 oder andere Einheiten der PPU 300, wie z.B. eine oder mehrere Kopiermaschinen, ein Video-Encoder, ein Video-Decoder, eine Energie- bzw. Leistungsverwaltungseinheit usw. (nicht explizit dargestellt) übertragen werden. Mit anderen Worten ist die I/O-Einheit 305 dazu konfiguriert, Kommunikationen zwischen und unter den verschiedenen logischen Einheiten der PPU 300 zu routen.
In einem Ausführungsbeispiel kodiert ein von dem Host-Prozessor ausgeführtes Programm einen Befehlsstrom in einem Puffer, der Arbeitslasten für die PPU 300 zur Verarbeitung bereitstellt. Eine Arbeitslast kann eine Reihe von Anweisungen und von diesen Anweisungen zu verarbeitende Daten umfassen. Der Puffer ist eine Region in einem Speicher, auf den sowohl von dem Host-Prozessor als auch von der PPU 300 zugegriffen (d.h. lesend/schreibend) werden kann. Beispielsweise kann die I/O-Einheit 310 dazu konfiguriert sein, auf den Puffer in einem mit der Zwischenverbindung 302 verbundenen Systemspeicher über Speicheranforderungen zuzugreifen, die über die Zwischenverbindung 302 übertragen werden. In einem Ausführungsbeispiel schreibt der Host-Prozessor den Befehlsstrom in den Puffer und überträgt dann einen Zeiger auf den Beginn des Befehlsstroms an die PPU 300. Die Frontend-Einheit 315 empfängt Zeiger auf einen oder mehrere Befehlsströme. Die Frontend-Einheit 315 verwaltet den einen oder die mehreren Ströme bzw. Streams, wobei sie Befehle aus den Streams liest und Befehle an die verschiedenen Einheiten der PPU 300 weiterleitet.
Die Frontend-Einheit 315 ist mit einer Scheduler-Einheit 320 gekoppelt, die die verschiedenen GPCs 350 dazu konfiguriert, Aufgaben zu verarbeiten, die durch den einen oder die mehreren Streams definiert sind. Die Scheduler-Einheit 320 ist dazu konfiguriert, Zustandsinformationen mit Bezug zu den verschiedenen Aufgaben nachzuverfolgen, die von der Scheduler-Einheit 320 verwaltet werden. Der Zustand kann anzeigen, welchem GPC 350 eine Aufgabe zugeordnet ist, ob die Aufgabe aktiv oder inaktiv ist, eine der Aufgabe zugeordnete Prioritätsstufe, und so weiter. Die Scheduler-Einheit 320 verwaltet die Ausführung einer Vielzahl von Aufgaben auf dem einen oder den mehreren GPCs 350.
Die Scheduler-Einheit 320 ist mit einer Arbeitsverteilungseinheit 325 gekoppelt, die dazu konfiguriert ist, Aufgaben zur Ausführung auf den GPCs 350 zu verteilen. Die Arbeitsverteilungseinheit 325 kann eine Anzahl von zugeteilten bzw. geplanten Aufgaben nachverfolgen, die von der Scheduler-Einheit 320 empfangen wurden. In einem Ausführungsbeispiel verwaltet die Arbeitsverteilungseinheit 325 für jeden der GPCs 350 einen Pool offener Aufgaben und einen Pool aktiver Aufgaben. Der Pool offener Aufgaben kann eine Anzahl von Slots (z.B. 32 Slots) umfassen, die Aufgaben enthalten, die zugewiesen von einem bestimmten GPC 350 zu verarbeiten sind. Der Pool aktiver Aufgaben kann eine Anzahl von Slots (z.B. 4 Slots) für Aufgaben umfassen, die von den GPCs 350 aktiv verarbeitet werden. Wenn ein GPC 350 die Ausführung einer Aufgabe beendet, wird diese Aufgabe aus dem Pool aktiver Aufgaben für den GPC 350 entnommen, und wird eine der anderen Aufgaben aus dem Pool offener Aufgaben ausgewählt und zur Ausführung auf dem GPC 350 eingeplant. Falls eine aktive Aufgabe auf dem GPC 350 im Leerlauf war, wie beispielsweise während des Wartens auf die Auflösung einer Datenabhängigkeit, kann die aktive Aufgabe aus dem GPC 350 entnommen und in den Pool offener Aufgaben zurückgeführt werden, während eine andere Aufgabe in dem Pool offener Aufgaben ausgewählt und zur Ausführung auf dem GPC 350 eingeplant wird.
Die Arbeitsverteilungseinheit 325 kommuniziert über die XBar 370 mit dem einen oder den mehreren GPCs 350. Die XBar 370 ist ein Zwischenverbindungsnetzwerk, das viele der Einheiten der PPU 300 mit anderen Einheiten der PPU 300 koppelt. Beispielsweise kann die XBar 370 dazu konfiguriert sein, die Arbeitsverteilungseinheit 325 mit einem bestimmten GPC 350 zu koppeln. Obwohl nicht explizit gezeigt, können eine oder mehrere andere Einheiten der PPU 300 ebenfalls über einen Hub 330 mit der XBar 370 verbunden sein.
Die Aufgaben werden von der Scheduler-Einheit verwaltet und von der Arbeitsverteilungseinheit 325 an einen GPC 350 gesendet. Der GPC 350 ist dazu konfiguriert, die Aufgabe zu verarbeiten und Ergebnisse zu generieren. Die Ergebnisse können von anderen Aufgaben innerhalb des GPCs 350 übernommen, über die XBar 370 an einen anderen GPC 350 weitergeleitet oder in dem Speicher 304 gespeichert werden. Die Ergebnisse können über die Partitionierungseinheiten 380, welche eine Speicherschnittstelle zum Lesen und Schreiben von Daten in/aus dem Speicher 304 implementieren, in den Speicher 304 geschrieben werden. Die Ergebnisse können über den NVLink 310 an eine andere PPU 304 oder eine CPU übertragen werden. In einem Ausführungsbeispiel beinhaltet die PPU 300 eine Anzahl U von Partitionierungseinheiten 380, die gleich der Anzahl von separaten und unterschiedlichen Speichervorrichtungen 304 ist, die mit der PPU 300 gekoppelt sind. Eine Partitionierungseinheit 380 wird nachstehend in Verbindung mit 4B näher beschrieben.
In einem Ausführungsbeispiel führt ein Host-Prozessor einen Treiberkern aus, der eine Anwendungsprogrammierschnittstelle (API) implementiert, die es einer oder mehreren auf dem Host-Prozessor ausgeführten Anwendungen ermöglicht, Operationen zur Ausführung auf der PPU 300 zu planen. In einem Ausführungsbeispiel werden mehrere Rechenanwendungen gleichzeitig von der PPU 300 ausgeführt und stellt die PPU 300 Isolation, Quality of Service (QoS) und unabhängige Adressräume für die mehreren Rechenanwendungen bereit. Eine Anwendung kann Anweisungen (z.B. API-Aufrufe) erzeugen, die den Treiberkern veranlassen, eine oder mehrere Aufgaben zur Ausführung durch die PPU 300 zu erzeugen. Der Treiberkern gibt Aufgaben an einen oder mehrere Streams aus, die von der PPU 300 verarbeitet werden. Jede Aufgabe kann eine oder mehrere Gruppen verwandter Threads umfassen, die hierin als ein Warp bezeichnet werden. In einem, Ausführungsbeispiel umfasst ein Warp 32 verwandte Threads, die parallel ausgeführt werden können. Kooperierende Threads können sich auf eine Vielzahl von Threads einschließlich Anweisungen zum Durchführen der Aufgabe, und die Daten über gemeinsam genutzten Speicher austauschen können, beziehen. Threads und kooperierende Threads werden in Verbindung mit 5A näher beschrieben.
4A veranschaulicht einen GPC 350 der PPU 300 von 3 gemäß einem Ausführungsbeispiel. Wie in 4A gezeigt ist, beinhaltet jeder GPC 350 eine Anzahl von Hardwareeinheiten zum Verarbeiten von Aufgaben. In einem Ausführungsbeispiel beinhaltet jeder GPC 350 einen Pipeline-Verwalter bzw. Pipeline-Manager 410, eine Vorrasteroperationseinheit bzw. Pre-Raster Operations Unit (PROP) 415, eine Rastermaschine bzw. Raster-Engine 425, eine Arbeitsverteilungsquerschiene bzw. Work Distribution Crossbar (WDX) 480, eine Speicherverwaltungseinheit bzw. Memory Management Unit (MMU) 490 und einen oder mehrere Datenverarbeitungscluster bzw. Data Processing Cluster (DPC) 420. Es versteht sich, dass der GPC 350 von 4A anstelle oder zusätzlich zu den in 4A gezeigten Einheiten andere Hardwareeinheiten beinhalten kann.
In einem Ausführungsbeispiel wird der Betriebsablauf des GPCs 350 durch den Pipeline-Manager 410 gesteuert. Der Pipeline-Manager 410 verwaltet die Konfiguration eines oder mehrerer DPC 420 zum Verarbeiten von Aufgaben, die dem GPC 350 zugeordnet sind. In einem Ausführungsbeispiel kann der Pipeline-Manager 410 zumindest einen der einen oder mehreren DPCs 420 dazu konfigurieren, zumindest einen Teil einer Grafik-Rendering-Pipeline zu implementieren. Beispielsweise kann ein DPC 420 dazu konfiguriert sein, ein Vertex-Shader-Programm auf dem programmierbaren Streaming-Multiprozessor (SM) 440 auszuführen. Der Pipeline-Manager 410 kann darüber hinaus dazu konfiguriert sein, von der Arbeitsverteilungseinheit 325 empfangene Pakete an die geeigneten logischen Einheiten innerhalb des GPCs 350 weiterzuleiten. Beispielsweise können einige Pakete an Hardwareeinheiten mit fester Funktion in der PROP 415 und/oder in der Raster-Engine 425 weitergeleitet werden, während andere Pakete an die DPC 420 zur Verarbeitung durch die Stammfunktionen-Maschine bzw. Stammfunktionen-Engine 435 oder den SM 440 weitergeleitet werden können. In einem Ausführungsbeispiel kann der Pipeline-Manager 410 zumindest einen oder mehrere der DPC 420 dazu konfigurieren, ein neuronales Netzwerkmodell und/oder eine Rechen-Pipeline zu implementieren.
Die PROP-Einheit 415 ist dazu konfiguriert, von der Raster-Engine 425 und den DPCs 420 erzeugte Daten an eine Rasterbetriebsablaufeinheit bzw. Raster Operations (ROP)-Einheit die in Verbindung mit 4B näher beschrieben wird, weiterzuleiten. Die PROP-Einheit 415 kann darüber hinaus dazu konfiguriert sein, Optimierungen zur Farbmischung durchzuführen, Pixeldaten zu organisieren, Adressübersetzungen durchzuführen und dergleichen.
Die Raster-Engine 425 beinhaltet eine Reihe von Hardwareeinheiten mit fester Funktion, die dazu konfiguriert sind, verschiedene Rasteroperationen durchzuführen. In einem Ausführungsbeispiel beinhaltet die Raster-Engine 425 eine Setup-Engine, eine Grobraster-Engine, eine Entnahme-Engine, eine Clipping-Engine, eine Feinraster-Engine und eine Kachelvereinigungs- bzw. Kachel-Koaleszenz-Engine. Die Setup-Engine empfängt transformierte Eckpunkte bzw. Vertices und erzeugt Ebenengleichungen, die der durch die Eckpunkte definierten geometrischen Stammfunktion zugeordnet sind. Die Ebenengleichungen werden an die Grobraster-Engine übertragen, um Abdeckungsinformationen (z.B. eine x, y-Abdeckungsmaske für eine Kachel) für die Stammfunktion zu erzeugen. Die Ausgabe der Grobraster-Engine wird an die Entnahme-Engine übertragen, an der der Stammfunktion zugeordnete Fragmente, die einen z-Test nicht bestehen, entnommen bzw. aussortiert werden, und an eine Clipping-Engine übertragen, an der Fragmente, die außerhalb eines Betrachtungskegels liegen, abgeschnitten werden. Die Fragmente, die das Abschneiden und das Aussortieren überleben, können an die Feinraster-Engine übergeben werden, um Attribute für die Pixelfragmente auf der Grundlage der von der Setup-Engine erzeugten Ebenengleichungen zu erzeugen. Die Ausgabe der Raster-Engine 425 umfasst Fragmente, die beispielsweise von einem in einem DPC 420 implementierten Fragment-Shader zu verarbeiten sind.
Jeder in dem GPC 350 enthaltene DPC 420 beinhaltet einen M-Pipe-Controller (MPC) 430, eine Stammfunktions-Engine 435 und einen oder mehrere SMs 440. Der MPC 430 steuert den Betriebsablauf des DPC 420 und routet die von dem Pipeline-Manager 410 empfangenen Pakete an die geeigneten Einheiten in dem DPC 420. Beispielsweise können Pakete, die einem Eckpunkt zugeordnet sind, an die Stammfunktions-Engine 435 geroutet werden, die dazu konfiguriert ist, dem Eckpunkt zugeordnete Eckpunktattribute aus dem Speicher 304 zu holen. Demgegenüber können Pakete, die einem Shader-Programm zugeordnet sind, an den SM 440 übertragen werden.
Der SM 440 umfasst einen programmierbaren Streaming-Prozessor, der dazu konfiguriert ist, Aufgaben zu verarbeiten, die durch eine Reihe von Threads repräsentiert werden. Jeder SM 440 ist multi-threaded und dazu konfiguriert, eine Vielzahl von Threads (z.B. 32 Threads) aus einer bestimmten Gruppe von Threads gleichzeitig auszuführen. In einem Ausführungsbeispiel implementiert der SM 440 eine SIMD (Single-Instruction, Multiple-Data)-Architektur, bei der jeder Thread in einer Gruppe von Threads (d.h. einem Warp) dazu konfiguriert ist, einen anderen Datensatz auf der Grundlage desselben Befehlssatzes zu verarbeiten. Alle Threads in der Gruppe von Threads führen dieselben Anweisungen aus. In einem anderen Ausführungsbeispiel implementiert der SM 440 eine SIMT (Single-Instruction, Multiple Thread)-Architektur, bei der jeder Thread in einer Gruppe von Threads dazu konfiguriert ist, einen anderen Datensatz auf der Grundlage desselben Befehlssatzes zu verarbeiten, wobei jedoch einzelne Threads in der Gruppe von Threads während der Ausführung divergieren dürfen. In einem Ausführungsbeispiel werden für jeden Warp ein Programmzähler, ein Aufrufstapel und ein Ausführungszustand beibehalten, wodurch die Gleichzeitigkeit zwischen Warps und eine serielle Ausführung innerhalb von Warps ermöglicht wird, wenn Threads innerhalb des Warps divergieren. In einem anderen Ausführungsbeispiel werden für jeden einzelnen Thread ein Programmzähler, ein Aufrufstapel und ein Ausführungszustand beibehalten, wodurch eine gleiche Gleichzeitigkeit zwischen allen Threads, innerhalb und zwischen Warps, ermöglicht wird. Wenn der Ausführungszustand für jeden einzelnen Thread beibehalten wird, können Threads, die dieselben Anweisungen ausführen, konvergiert und parallel ausgeführt werden, um eine maximale Effizienz zu erreichen. Der SM 440 wird nachstehend in Verbindung mit 5A näher beschrieben.
Die MMU 490 stellt eine Schnittstelle zwischen dem GPC 350 und der Partitionierungseinheit 380 bereit. Die MMU 490 kann eine Übersetzung von virtuellen Adressen in physikalische Adressen, einen Speicherschutz und eine Arbitrierung von Speicheranforderungen bereitstellen. In einem Ausführungsbeispiel stellt die MMU 490 einen oder mehrere Translation Lookaside Buffer (TLBs) bereit zum Durchführen einer Übersetzung von virtuellen Adressen in physikalische Adressen in dem Speicher 304.
4B veranschaulicht eine Speicherpartitionierungseinheit 380 der PPU 300 von 3 gemäß einem Ausführungsbeispiel. Wie in 4B dargestellt ist, beinhaltet die Speicherpartitionierungseinheit 380 eine Raster Operations (ROP)-Einheit 450, einen Level-2 (L2)-Cache 460 und eine Speicherschnittstelle 470. Die Speicherschnittstelle 470 ist mit dem Speicher 304 gekoppelt. Die Speicherschnittstelle 470 kann 32, 64, 128, 1024-Bit-Datenbusse oder dergleichen für eine Hochgeschwindigkeits-Datenübertragung implementieren. In einem Ausführungsbeispiel beinhaltet die PPU 300 U-Speicherschnittstellen 470, eine Speicherschnittstelle 470 pro Paar von Partitionierungseinheiten 380, wobei jedes Paar von Partitionierungseinheiten 380 mit einer entsprechenden Speichervorrichtung 304 verbunden ist. Beispielsweise kann die PPU 300 mit bis zu Y Speichervorrichtungen 304 verbunden sein, wie beispielsweise Speicherstapeln mit hoher Bandbreite oder synchronem dynamischen Grafik-Direktzugriffsspeicher mit doppelter Datenrate, Version 5, oder anderen Arten von persistenten Speichern.
In einem Ausführungsbeispiel implementiert die Speicherschnittstelle 470 eine HBM2-Speicherschnittstelle und entspricht Y der Hälfte von U. In einem Ausführungsbeispiel befinden sich die HBM2-Speicherstapel in demselben physikalischen Gehäuse wie die PPU 300, wodurch im Vergleich zu herkömmlichen GDDR5-SDRAM-Systemen erheblichen Strom- und Flächeneinsparungen bereitgestellt werden. In einem Ausführungsbeispiel beinhaltet jeder HBM2-Stapel vier Speicherchips und ist Y gleich 4, wobei der HBM2-Stapel zwei 128-Bit-Kanäle pro Chip für insgesamt 8 Kanäle und eine Datenbusbreite von 1024 Bit beinhaltet.
In einem Ausführungsbeispiel unterstützt der Speicher 304 Single-Error Correcting Double-Error Detecting (SECDED) Error Correction Code (ECC) zum Schutz der Daten. ECC bietet eine höhere Zuverlässigkeit für Rechenanwendungen, die gegenüber Datenkorruption empfindlich reagieren. Zuverlässigkeit ist besonders wichtig in großen Cluster-Rechenumgebungen, in denen PPUs 300 sehr große Datensätze verarbeiten und/oder Anwendungen über längere Zeitspannen hinweg betreiben.
In einem Ausführungsbeispiel implementiert die PPU 300 eine mehrstufige Speicherhierarchie. In einem Ausführungsbeispiel unterstützt die Speicherpartitionseinheit 380 einen vereinigten Speicher, um einen einzigen vereinigten virtuellen Adressraum für CPU- und PPU 300-Speicher bereitzustellen, der ein Teilen von Daten zwischen virtuellen Speichersystemen ermöglicht. In einem Ausführungsbeispiel wird die Häufigkeit von Zugriffen einer PPU 300 auf Speicher, der sich auf anderen Prozessoren befindet, nachverfolgt, um sicherzustellen, dass Speicherseiten in den physikalischen Speicher der PPU 300 verschoben werden, die häufiger auf die Seiten zugreift. In einem Ausführungsbeispiel unterstützt der NVLink 310 Adressübersetzungsdienste, die es der PPU 300 ermöglichen, direkt auf die Seitentabellen einer CPU zuzugreifen, und vollen Zugriff auf CPU-Speicher durch die PPU 300 bereitstellen.
In einem Ausführungsbeispiel übertragen Kopier-Engines Daten zwischen mehreren PPUs 300 oder zwischen PPUs 300 und CPUs. Die Kopier-Engines können Seitenfehler für Adressen, die nicht in den Seitentabellen abgebildet sind, erzeugen. Die Speicherpartitionierungseinheit 380 kann dann die Seitenfehler beheben, wobei sie die Adressen in die Seitentabelle abbildet, woraufhin die Kopier-Engine die Übertragung durchführen kann. In einem herkömmlichen System ist der Speicher für mehrfache Kopier-Engine-Operationen zwischen mehreren Prozessoren verankert (d.h. nicht auslagerbar), welches den verfügbaren Speicher erheblich reduziert. Mit Hardware-Seitenfehlerverwerfung können Adressen an die Kopier-Engines weitergegeben werden, ohne besorgt sein zu müssen, ob die Speicherseiten resident sind, und ist der Kopiervorgang transparent.
Daten aus dem Speicher 304 oder anderem Systemspeicher können von der Speicherpartitionierungseinheit 380 abgerufen und in dem L2-Cache 460 gespeichert werden, welcher sich auf dem Chip befindet und von den verschiedenen GPCs 350 gemeinsam genutzt wird. Wie gezeigt ist, beinhaltet jede Speicherpartitionierungseinheit 380 einen Teil des L2-Cache 460, der einer entsprechenden Speichervorrichtung 304 zugeordnet ist. Untergeordnete Caches können dann in verschiedenen Einheiten innerhalb der GPCs 350 implementiert sein. So kann beispielsweise jeder der SMs 440 einen Level One (L1)-Cache implementieren. Der L1-Cache ist ein privater Speicher, der für einen bestimmten SM 440 dediziert ist. Daten aus dem L2-Cache 460 können abgerufen und in jedem der L1-Caches zur Verarbeitung in den Funktionseinheiten des SMs 440 gespeichert werden. Der L2-Cache 460 ist mit der Speicherschnittstelle 470 und der XBar 370 gekoppelt.
Die ROP-Einheit 450 führt Grafikrasteroperationen mit Bezug zu Pixelfarben durch, wie z.B. eine Farbkompression, ein Pixelblending und dergleichen. Die ROP-Einheit 450 implementiert darüber hinaus Tiefenprüfungen in Verbindung mit der Raster-Engine 425, wobei sie eine Tiefe für einen Probenort empfängt, der einem Pixelfragment aus der Entnahme-Engine der Raster-Engine 425 zugeordnet ist. Die Tiefe wird gegen eine entsprechende Tiefe in einem Tiefenpuffer für einen dem Fragment zugeordneten Probenort getestet. Wenn das Fragment den Tiefentest für den Probenort besteht, aktualisiert die ROP-Einheit 450 den Tiefenpuffer und überträgt ein Ergebnis des Tiefentests an die Raster-Engine 425. Es versteht sich, dass die Anzahl von Partitionierungseinheiten 380 von der Anzahl der GPCs 350 verschieden sein kann und daher jede ROP-Einheit 450 mit jedem der GPCs 350 gekoppelt sein kann. Die ROP-Einheit 450 verfolgt die von den verschiedenen GPCs 350 empfangenen Pakete nach und ermittelt den GPC 350, zu dem ein von der ROP-Einheit 450 erzeugtes Ergebnis über die Xbar 370 geroutet wird. Obwohl die ROP-Einheit 450 in 4B innerhalb der Speicherpartitionierungseinheit 380 enthalten ist, kann in einem anderen Ausführungsbeispiel die ROP-Einheit 450 außerhalb der Speicherpartitionierungseinheit 380 sein. Beispielsweise kann sich die ROP-Einheit 450 in dem GPC 350 oder in einer anderen Einheit befinden.
5A veranschaulicht den Streaming-Multiprozessor 440 von 4A gemäß einem Ausführungsbeispiel. Wie in 5A gezeigt ist, beinhaltet der SM 440 einen Anweisungs-Cache 505, eine oder mehrere Scheduler-Einheiten 510, eine Registerdatei 520, einen oder mehrere Verarbeitungskerne 550, eine oder mehrere Spezialfunktionseinheiten (SFUs) 552, eine oder mehrere Lade-/Speicher-Einheiten (LSUs) 554, ein Zwischenverbindungsnetzwerk 580 und einen gemeinsam genutzten Speicher bzw. Shared Memory/L1 -Cache 570.
Wie vorstehend beschrieben wurde, versendet die Arbeitsverteilungseinheit 325 Aufgaben zur Ausführung auf den GPCs 350 der PPU 300. Die Aufgaben sind einem bestimmten DPC 420 innerhalb eines GPCs 350 zugeordnet, und, wenn die Aufgabe einem Shader-Programm zugeordnet ist, kann die Aufgabe einem SM 440 zugeordnet sein. Die Scheduler-Einheit 510 empfängt die Aufgaben von der Arbeitsverteilungseinheit 325 und verwaltet die Anweisungsplanung für einen oder mehrere der dem SM 440 zugeordneten Thread-Blöcke. Die Scheduler-Einheit 510 plant Thread-Blöcke zur Ausführung als Warps paralleler Threads, wobei jedem Thread-Block zumindest ein Warp zugeordnet ist. In einem Ausführungsbeispiel führt jeder Warp 32 Threads aus. Die Scheduler-Einheit 510 kann eine Vielzahl verschiedener Thread-Blöcke verwalten, wobei sie die Warps den verschiedenen Thread-Blöcken zuordnet und dann während jedes Taktzyklus Anweisungen von der Vielzahl von verschiedenen kooperativen Gruppen an die verschiedenen Funktionseinheiten (d.h. Kerne 550, SFUs 552 und LSUs 554) sendet.
Cooperative Groups bzw. kooperative Gruppen ist ein Programmiermodell zum Organisieren von Gruppen kommunizierender Threads, das es Entwicklern ermöglicht, die Granularität auszudrücken, mit welcher Threads kommunizieren, wodurch der Ausdruck reichhaltigerer, effizienterer paralleler Zerlegungen ermöglicht wird. Kooperative Start-APIs unterstützen die Synchronisation zwischen Thread-Blöcken zur Ausführung paralleler Algorithmen. Herkömmliche Programmiermodelle stellen ein einziges, einfaches Konstrukt zur Synchronisation kooperierender Threads bereit: eine Barriere über alle Threads eines Thread-Blocks (d.h. die Funktion syncthreads()). Programmierer möchten jedoch oftmals Gruppen von Threads definieren, die kleiner als die Granularität von Threads sind, und innerhalb der definierten Gruppen synchronisieren, um mehr Leistung, Designflexibilität und Wiederverwendbarkeit von Software in Form von gemeinsamen gruppenweiten Funktionsschnittstellen zu ermöglichen.
Cooperative Groups ermöglicht es Programmierern, Gruppen von Threads explizit bei Subblock (d.h. so klein wie ein einzelner Thread)- und Multiblock-Granularitäten zu definieren und kollektive Operationen wie beispielsweise die Synchronisation auf den Threads in einer kooperativen Gruppe durchzuführen. Das Programmiermodell unterstützt eine saubere Zusammensetzung über Softwaregrenzen hinweg, so dass Bibliotheken und Utility-Funktionen in ihrem lokalen Kontext sicher synchronisieren können, ohne Annahmen über Konvergenz treffen zu müssen. Stammfunktionen kooperativer Gruppen ermöglichen neue Muster kooperativer Parallelität, einschließlich von Erzeuger-Verbraucher-Parallelität, opportunistischer Parallelität und globaler Synchronisation über ein ganzes Netz von Thread-Blöcken hinweg.
Eine Sendeeinheit 515 ist dazu konfiguriert, Anweisungen an eine oder mehrere der Funktionseinheiten zu senden. In dem Ausführungsbeispiel beinhaltet die Scheduler-Einheit 510 zwei Sendeeinheiten 515, die es ermöglichen, während jedes Taktzyklus zwei verschiedene Anweisungen desselben Warps zu versenden. In alternativen Ausführungsbeispielen kann jede Scheduler-Einheit 510 eine einzelne Sendeeinheit 515 oder zusätzliche Sendeeinheiten 515 beinhalten.
Jeder SM 440 beinhaltet eine Registerdatei 520, die einen Satz von Registern für die Funktionseinheiten des SMs 440 bereitstellt. In einem Ausführungsbeispiel ist die Registerdatei 520 zwischen jeder der Funktionseinheiten aufgeteilt, so dass jeder Funktionseinheit ein dedizierter Teil der Registerdatei 520 zugeordnet ist. In einem anderen Ausführungsbeispiel ist die Registerdatei 520 zwischen den verschiedenen Warps aufgeteilt, die von dem SM 440 ausgeführt werden. Die Registerdatei 520 stellt einen Zwischenspeicher für Operanden, die mit den Datenpfaden der Funktionseinheiten verbunden sind, bereit.
Jeder SM 440 umfasst L Verarbeitungskerne 550. In einem Ausführungsbeispiel beinhaltet der SM 440 eine große Anzahl (z.B. 128, usw.) verschiedener Verarbeitungskerne 550. Jeder Kern 550 kann eine vollpipelinierte, einfachgenaue, doppelgenaue und/oder gemischtgenaue Verarbeitungseinheit beinhalten, die eine Gleitkomma-Rechenlogikeinheit und eine Ganzzahl-Rechenlogikeinheit beinhaltet. In einem Ausführungsbeispiel implementieren die Gleitkomma-Rechenlogikeinheiten den Standard IEEE 754-2008 für Gleitkommaarithmetik. In einem Ausführungsbeispiel beinhalten die Kerne 550 64 einfachgenaue (32-Bit) Gleitkomma-Kerne, 64 Ganzzahlkerne, 32 doppelgenaue (64-Bit) Gleitkommakerne und 8 Tensorkerne.
Tensorkerne, sind dazu konfiguriert, Matrixoperationen durchzuführen, und in einem Ausführungsbeispiel sind ein oder mehrere Tensorkerne in den Kernen 550 enthalten. Insbesondere sind die Tensorkerne dazu konfiguriert, tief lernende Matrixarithmetik durchzuführen, wie z.B. Faltungsoperationen für das Training und die Inferenzierung neuronaler Netzwerke. In einem Ausführungsbeispiel arbeitet jeder Tensorkern auf einer 4x4-Matrix und führt eine Matrixmultiplikation- und Akkumulationsoperation D=A×B+C durch, worin A, B, C und D 4x4-Matrizen sind.
In einem Ausführungsbeispiel sind die Matrixmultiplikationseingänge A und B 16-Bit Fließkomma-Matrizen, während die Akkumulationsmatrizen C und D 16-Bit Fließkomma- oder 32-Bit Fließkomma-Matrizen sein können. Tensorkerne arbeiten mit 16-Bit Gleitkomma-Eingangsdaten mit 32-Bit Gleitkommaakkumulation. Die 16-Bit-Fließkomma-Multiplikation erfordert 64 Operationen und resultiert in einem hochpräzisen Produkt, das dann unter Verwendung der 32-Bit-Fließkommaaddition mit den anderen Zwischenprodukten für eine 4x4x4-Matrix-Multiplikation akkumuliert wird. In der Praxis werden Tensorkerne verwendet, um viel größere zweidimensionale oder höher dimensionale Matrixoperationen durchzuführen, die sich aus diesen kleineren Elementen zusammensetzen. Eine API, wie beispielsweise die CUDA 9 C++ API, stellt spezielle Matrixlasten, Matrixmultiplikationen und - akkumulationen sowie Matrixspeicheroperationen zur Verfügung, um Tensorkerne aus einem CUDA C++-Programm heraus effizient zu nutzen. Auf der CUDA-Ebene geht das Warp-Level-Interface von Matrizen der Größe 16x16 aus, die alle 32 Threads des Warps umspannen.
Jeder SM 440 umfasst auch M SFUs 552, die spezielle Funktionen (z.B. Attributbewertung, reziproke Quadratwurzel und dergleichen) durchführen. In einem Ausführungsbeispiel können die SFUs 552 eine Baumdurchlaufeinheit beinhalten, die dazu konfiguriert ist, eine hierarchische Baumdatenstruktur zu durchlaufen. In einem Ausführungsbeispiel können die SFUs 552 eine Textureinheit beinhalten, die dazu konfiguriert ist, Texturkartenfilteroperationen durchzuführen. In einem Ausführungsbeispiel sind die Textureinheiten dazu konfiguriert, Texturkarten (z.B. ein 2D-Array von Texeln) aus dem Speicher 304 zu laden und die Texturkarten abzutasten, um abgetastete Texturwerte zur Verwendung in Shader-Programmen zu erzeugen, die von dem SM 440 ausgeführt werden. In einem Ausführungsbeispiel werden die Texturkarten in dem gemeinsam genutzten Speicher/L1-Cache 470 gespeichert. Die Textureinheiten implementieren Texturoperationen wie z.B. Filteroperationen mit Hilfe von Mip-Maps (d.h. Texturkarten mit variierendem Detaillierungsgrad). In einem Ausführungsbeispiel beinhaltet jeder SM 340 zwei Textureinheiten.
Jeder SM 440 umfasst darüber hinaus N LSUs 554, die Lade- und Speicheroperationen zwischen dem gemeinsam genutzten Speicher/L1-Cache 570 und der Registerdatei 520 implementieren. Jeder SM 440 beinhaltet ein Zwischenverbindungsnetzwerk 580, das jede der Funktionseinheiten mit der Registerdatei 520 und die LSU 554 mit der Registerdatei 520 und dem gemeinsam genutzten Speicher/L1 Cache 570 verbindet. In einem Ausführungsbeispiel ist das Zwischenverbindungsnetzwerk 580 eine Kreuz- bzw. Querschiene (Crossbar), die dazu konfiguriert sein kann, eine beliebige der Funktions-einheiten mit einem beliebigen der Register in der Registerdatei 520 zu verbinden und die LSUs 554 mit der Registerdatei und Speicherplätzen in dem gemeinsam genutzten Speicher/L1-Cache 570 zu verbinden.
Der gemeinsam genutzte Speicher/L1 Cache 570 ist eine Anordnung von Speichern auf dem Chip bzw. ein On-Chip-Speicher, das bzw. der eine Datenspeicherung und Kommunikation zwischen dem SM 440 und der Stammfunktions-Engine 435 sowie zwischen Threads in dem SM 440 ermöglicht. In einem Ausführungsbeispiel umfasst der gemeinsam genutzte Speicher/L1-Cache 570 128KB Speicherkapazität und liegt in dem Pfad von dem SM 440 zu der Partitionseinheit 380. Der gemeinsam genutzte Speicher/L1-Cache 570 kann dazu verwendet werden, Lesevorgänge und Schreibvorgänge zwischenzuspeichern. Einer oder mehrere des gemeinsam genutzten Speichers/L1-Cache 570, des L2-Caches 460 und des Speichers 304 sind Backup-Speicher.
Ein Kombinieren von Daten-Cache- und Shared Memory-Funktionalität zu einem einzigen Speicherblock stellt die beste Gesamtleistung für beide Arten von Speicherzugriffen bereit. Die Kapazität ist als ein Zwischenspeicher bzw. Cache für Programme nutzbar, die keinen gemeinsam genutzten Speicher verwenden. Wenn beispielsweise ein gemeinsam genutzter Speicher so konfiguriert ist, dass er die Hälfte der Kapazität verwendet, können Textur- und Lade-/Speicher-Operationen die verbleibende Kapazität nutzen. Die Integration innerhalb des gemeinsam genutzten Speichers/L1-Caches 570 ermöglicht es dem gemeinsam genutzten Speicher/L1-Cache 570, als eine Hochdurchsatzleitung zum Streamen von Daten zu arbeiten und gleichzeitig einen Zugriff auf häufig wiederverwendete Daten mit hoher Bandbreite und geringer Latenz zu ermöglichen.
Bei einer Konfiguration für universelle parallele Berechnungen kann eine im Vergleich mit Grafikverarbeitung einfachere Konfiguration verwendet werden. Insbesondere werden die in 3 gezeigten Grafikverarbeitungseinheiten mit fester Funktion umgangen, wodurch ein wesentlich einfacheres Programmiermodell entsteht. In der Konfiguration für universelle parallele Berechnung weist die Arbeitsverteilungseinheit 325 Thread-Blöcke direkt den DPCs 420 zu und verteilt sie. Die Threads in einem Block führen dasselbe Programm aus, wobei eine eindeutige Thread-ID in der Berechnung verwendet wird, um sicherzustellen, dass jeder Thread eindeutige Ergebnisse erzeugt, und wobei der SM 440 verwendet wird, um das Programm auszuführen und Berechnungen durchzuführen, der gemeinsam genutzte Speicher/L1-Cache 570 verwendet wird, um zwischen Threads zu kommunizieren, und die LSU 554 verwendet wird, um den globalen Speicher über den gemeinsam genutzten Speicher/L1-Cache 570 und die Speicherpartitionseinheit 380 zu lesen und zu beschreiben. Bei der Konfiguration für universelle parallele Berechnungen kann der SM 440 ebenfalls Befehle schreiben, die die Scheduler-Einheit 320 dazu verwenden kann, neue Arbeit an den DPCs 420 zu beginnen.
Die PPU 300 kann in einem Desktop-Computer, einem Laptop-Computer, einem Tablet-Computer, Servern, Supercomputern, einem Smartphone (z.B. einem drahtlosen, tragbaren Gerät), einem Personal Digital Assistant (PDA), einer Digitalkamera, einem Fahrzeug, einem Kopfbildschirm, einer tragbaren elektronischen Vorrichtung und dergleichen integriert sein. In einem Ausführungsbeispiel ist die PPU 300 auf einem einzelnen Halbleitersubstrat ausgeführt. In einem anderen Ausführungsbeispiel ist die PPU 300 zusammen mit einer oder mehreren anderen Vorrichtungen, wie beispielsweise zusätzlichen PPUs 300, dem Speicher 204, einer CPU mit reduziertem Befehlssatz (RISC), einer Speicherverwaltungseinheit (MMU), einem Digital-Analog-Wandler (DAC) und dergleichen, in einem System auf einem Chip (SoC) enthalten.
In einem Ausführungsbeispiel kann die PPU 300 auf einer Grafikkarte enthalten sein, die eine oder mehrere Speichervorrichtungen 304 beinhaltet. Die Grafikkarte kann so konfiguriert sein, dass sie mit einem PCIe-Steckplatz auf einem Motherboard eines Desktop-Computers verbunden ist. In einem nochmals anderen Ausführungsbeispiel kann die PPU 300 eine integrierte Grafikverarbeitungseinheit (iGPU) oder ein paralleler Prozessor sein, der in dem Chipsatz des Motherboards enthalten ist.
Beispielhaftes Rechensystem
Systeme mit mehreren GPUs und CPUs werden in einer Vielzahl von Branchen eingesetzt, da Entwickler mehr Parallelität in Anwendungen wie künstlicher Intelligenz bereitstellen und nutzen. Leistungsstarke GPU-beschleunigte Systeme mit zehn bis vielen tausend Rechenknoten werden in Rechenzentren, Forschungseinrichtungen und Supercomputern eingesetzt, um immer größere Probleme zu lösen. Mit steigender Anzahl von Verarbeitungseinrichtungen innerhalb der Hochleistungssysteme müssen die Kommunikations- und Datenübertragungsmechanismen skalieren, um die größere Bandbreite zu unterstützen.
5B ist ein konzeptionelles Diagramm eines unter Verwendung der PPU 300 von 3 implementierten Verarbeitungssystems 500, gemäß einem Ausführungsbeispiel. Das beispielhafte System 500 kann dazu konfiguriert sein, das in 2A dargestellte Verfahren 200 zu implementieren. Das Verarbeitungssystem 500 beinhaltet eine CPU 530, einen Switch 555 und jeweils mehrere PPUs 300 und entsprechende Speicher 304. Der NVLink 310 stellt Hochgeschwindigkeits-Kommunikationsverbindungen zwischen jeder der PPUs 300 bereit. Obwohl eine bestimmte Anzahl von NVLink 310- und Interconnect 302-Verbindungen in 5B dargestellt ist, kann die Anzahl der Verbindungen zu jeder PPU 300 und der CPU 530 variieren. Der Switch 555 verbindet zwischen der Zwischenverbindung 302 und der CPU 530. Die PPUs 300, die Speicher 304 und die NVLinks 310 können auf einer einzigen Halbleiterplattform liegen, um ein Parallelverarbeitungsmodul 525 zu bilden. In einem Ausführungsbeispiel unterstützt der Switch 555 zwei oder mehr Protokolle, um zwischen verschiedenen unterschiedlichen Verbindungen und/oder Verknüpfungen zu verbinden.
In einem anderen Ausführungsbeispiel (nicht gezeigt) stellt der NVLink 310 eine oder mehrere Hochgeschwindigkeits-Kommunikationsverbindungen zwischen jeder der PPUs 300 und der CPU 530 bereit und verbindet der Switch 555 zwischen der Zwischenverbindung 302 und jeder der PPUs 300. Die PPUs 300, die Speicher 304 und die Zwischenverbindung 302 können auf einer einzigen Halbleiterplattform angeordnet sein, um ein Parallelverarbeitungsmodul 525 zu bilden. In einem nochmals weiteren Ausführungsbeispiel (nicht gezeigt) stellt die Zwischenverbindung 302 eine oder mehrere Kommunikationsverbindungen zwischen jeder der PPUs 300 und der CPU 530 bereit, und verbindet der Switch 555 zwischen jeder der PPUs 300 unter Verwendung des NVLinks 310, um eine oder mehrere Hochgeschwindigkeits-Kommunikationsverbindungen zwischen den PPUs 300 bereitzustellen. In einem weiteren Ausführungsbeispiel (nicht gezeigt) stellt der NVLink 310 eine oder mehrere Hochgeschwindigkeits-Kommunikationsverbindungen zwischen den PPUs 300 und der CPU 530 über den Switch 555 bereit. In einem nochmals anderen Ausführungsbeispiel (nicht gezeigt) stellt die Zwischenverbindung 302 eine oder mehrere Kommunikationsverbindungen zwischen jeder der PPUs 300 direkt zur Verfügung. Eine oder mehrere der NVLink 310-Hochgeschwindigkeits-Kommunikationsverbindungen können als physikalische NVLink-Zwischenverbindung oder als entweder eine On-Chip- oder eine On-Die-Zwischenverbindung unter Verwendung desselben Protokolls wie das des NVLink 310 implementiert sein.
Im Kontext der vorliegenden Beschreibung kann sich eine einzelne Halbleiterplattform auf eine einzige einheitliche halbleiterbasierte integrierte Schaltung beziehen, die auf einem Die oder einem Chip hergestellt ist. Es wird angemerkt, dass sich der Begriff einzelne Halbleiterplattform auch auf Multichip-Module mit erhöhter Konnektivität, die einen On-Chip-Betriebsablauf simulieren und wesentliche Verbesserungen gegenüber der Nutzung einer herkömmlichen Busimplementierung bereitstellen, beziehen kann. Natürlich können die verschiedenen Schaltungen oder Vorrichtungen auch einzeln oder in verschiedenen Kombinationen von Halbleiterplattformen nach den Wünschen des Benutzers angeordnet sein. Alternativ kann das Parallelverarbeitungsmodul 525 als ein Leiterplattensubstrat implementiert sein, und kann jede der PPUs 300 und/oder jeder der Speicher 304 eine gepackte Vorrichtung sein. In einem Ausführungsbeispiel befinden sich die CPU 530, der Switch 555 und das Parallelverarbeitungsmodul 525 auf einer einzigen Halbleiterplattform.
In einem Ausführungsbeispiel beträgt die Signalübertragungsrate jedes NVLinks 310 20 bis 25 Gigabit/Sekunde und beinhaltet jede PPU 300 sechs NVLink 310-Schnittstellen (wie in 5B dargestellt, sind fünf NVLink 310-Schnittstellen für jede PPU 300 enthalten). Jeder NVLink 310 stellt eine Datenübertragungsrate von 25 Gigabyte/Sekunde in jede Richtung bereit, wobei sechs Links 300 Gigabyte/Sekunde liefern. Die NVLinks 310 können ausschließlich für die PPU-zu-PPU-Kommunikation, wie in 5B gezeigt, oder für eine Kombination aus PPU-zu-PPU und PPU-zu-CPU verwendet werden, wenn die CPU 530 ebenfalls eine oder mehrere NVLink 310-Schnittstellen beinhaltet.
In einem Ausführungsbeispiel ermöglicht der NVLink 310 den direkten Lade-/ Speicher-/Kernzugriff von der CPU 530 auf den Speicher 304 jeder PPU 300. In einem Ausführungsbeispiel unterstützt der NVLink 310 Kohärenzoperationen, so dass aus den Speichern 304 gelesene Daten in der Cache-Hierarchie der CPU 530 gespeichert werden können, wodurch die Cache-Zugriffslatenz für die CPU 530 reduziert wird. In einem Ausführungsbeispiel beinhaltet der NVLink 310 die Unterstützung von Address Translation Services (ATS), so dass die PPU 300 direkt auf Seitentabellen innerhalb der CPU 530 zugreifen kann. Einer oder mehrere der NVLinks 310 können auch für den Betrieb in einem Energiesparmodus konfiguriert sein.
5C veranschaulicht ein beispielhaftes System 565, in welchem die unterschiedliche Architektur und/oder Funktionalität der verschiedenen vorangehenden Ausführungsbeispiele implementiert sein kann. Das beispielhafte System 565 kann dazu konfiguriert sein, das in 2 gezeigte Verfahren 200 zu implementieren.
Wie gezeigt ist, wird ein System 565 bereitgestellt, das zumindest eine Zentralverarbeitungseinheit 530 beinhaltet, die mit einem Kommunikationsbus 575 verbunden ist. Der Kommunikationsbus 575 kann unter Verwendung jedes geeigneten Protokolls, wie z.B. PCI (Peripheral Component Interconnect), PCI-Express, AGP (Accelerated Graphics Port), HyperTransport oder einem beliebigen anderen Bus- oder Punkt-zu-Punkt Kommunikationsprotokoll(en), implementiert sein. Das System 565 beinhaltet darüber hinaus einen Hauptspeicher 540. Steuerlogik (Software) und die Daten werden in dem Hauptspeicher 540 gespeichert, welcher als Direktzugriffsspeicher (RAM) ausgeführt sein kann.
Das System 565 beinhaltet darüber hinaus Eingabevorrichtungen 560, das Parallelverarbeitungssystem 525 und Anzeigevorrichtungen 545, d.h. eine herkömmliche CRT (Kathodenstrahlröhre), LCD (Flüssigkristallanzeige), LED (Leuchtdiode), Plasmaanzeige oder dergleichen. Benutzereingaben können von den Eingabegeräten 560, z.B. Tastatur, Maus, Touchpad, Mikrofon und dergleichen, empfangen werden. Jede(s) der vorgenannten Module und/oder Vorrichtungen kann sich sogar auf einer einzigen Halbleiterplattform befinden, um das System 565 zu bilden. Alternativ können die verschiedenen Module auch einzeln oder in verschiedenen Kombinationen von Halbleiterplattformen nach den Wünschen des Anwenders angeordnet sein.
Ferner kann das System 565 über eine Netzwerkschnittstelle 535 zu Kommunikationszwecken mit einem Netzwerk (z.B. einem Telekommunikationsnetzwerk, einem Local Area Network (LAN), einem drahtlosen Netzwerk, einem Wide Area Network (WAN) wie beispielsweise dem Internet, einem Peer-to-Peer-Netzwerk, einem Kabelnetzwerk oder dergleichen) gekoppelt sein.
Das System 565 kann darüber hinaus einen Sekundärspeicher (nicht gezeigt) beinhalten. Der Sekundärspeicher beinhaltet beispielsweise ein Festplattenlaufwerk und/oder ein Wechselspeicherlaufwerk, das ein Diskettenlaufwerk, ein Magnetbandlaufwerk, ein Compact-Disc-Laufwerk, ein Digital Versatile Disc (DVD)-Laufwerk, ein Aufzeichnungsgerät oder einen universeller serieller Bus-(USB)-Flashspeicher darstellt. Das Wechselspeicherlaufwerk liest und/oder schreibt in bekannter Weise von einer/auf eine Wechselspeichereinheit.
Computerprogramme, oder Logikalgorithmen der Computersteuerung, können in dem Hauptspeicher 540 und/oder in dem Sekundärspeicher gespeichert werden. Wenn sie ausgeführt werden, ermöglichen es solche Computerprogramme dem System 565, verschiedene Funktionen durchzuführen. Der Speicher 540, der Speicher und/oder jeder andere Speicher sind mögliche Beispiele von computerlesbaren Medien.
Die Architektur und/oder Funktionalität der verschiedenen vorangehenden Figuren kann im Kontext eines universellen Computersystems, eines Platinensystems, eines Spielkonsolensystems, das für Unterhaltungszwecke dediziert ist, eines anwendungsspezifischen Systems und/oder eines beliebigen anderen gewünschten Systems implementiert werden. Das System 565 kann beispielsweise die Form eines Desktop-Computers, eines Laptops, eines Tablet-Computers, von Servern, Supercomputern, eines Smartphones (z.B. eines drahtlosen, tragbaren Geräts), eines persönlichen digitalen Assistenten (PDA), einer Digitalkamera, eines Fahrzeugs, einer kopfmontierten Anzeige, einer tragbaren elektronischen Vorrichtung, einer mobilen Telefonvorrichtung, eines Fernsehers, einer Workstation, von Spielkonsolen, eines eingebetteten Systems und/oder einer beliebigen anderen Art von Logik annehmen.
Während vorstehend verschiedene Ausführungsbeispiele beschrieben wurden, versteht sich, dass diese lediglich beispielhaft und nicht als beschränkend dargestellt wurden. Daher ist die Breite und der Schutzumfang eines bevorzugten Ausführungsbeispiels nicht durch eines der vorstehend beschriebenen beispielhaften Ausführungsbeispiele zu beschränken, sondern nur in Übereinstimmung mit den nachfolgenden Ansprüchen und deren Äquivalenten zu definieren.
Grafikverarbeitungs-Pipeline
In einem Ausführungsbeispiel umfasst die PPU 300 eine Grafikverarbeitungseinheit (GPU). Die PPU 300 ist dazu konfiguriert, Befehle zu empfangen, die Shader-Programme zur Verarbeitung von Grafikdaten spezifizieren. Grafikdaten können als ein Satz von Stammfunktionen wie beispielsweise Punkte, Linien, Dreiecke, Vierecke, Dreiecksstreifen und dergleichen definiert sein. Typischerweise beinhaltet eine Stammfunktion Daten, die eine Anzahl von Eckpunkten für die Stammfunktion (z.B. in einem Modell-Raum-Koordinatensystem) spezifizieren, sowie Attribute, die jedem Eckpunkt der Stammfunktion zugeordnet sind. Die PPU 300 kann dazu konfiguriert sein, die Grafik-Stammfunktion zu verarbeiten, um einen Einzelbild- bzw. Frame-Puffer (d.h. Pixeldaten für jedes der Pixel des Displays) zu erzeugen.
Eine Anwendung schreibt Modelldaten für eine Szene (d.h. eine Sammlung von Eckpunkten und Attributen) in einen Speicher, wie beispielsweise einen Systemspeicher oder Speicher 304. Die Modelldaten definieren jedes der Objekte, die auf einer Anzeige sichtbar sein können. Die Anwendung führt dann einen API-Aufruf an den Treiberkern durch, der die Modelldaten zur Wiedergabe und Anzeige anfordert. Der Treiberkern liest die Modelldaten und schreibt Befehle in den einen oder die mehreren Streams, um Operationen zur Verarbeitung der Modelldaten durchzuführen. Die Befehle können verschiedene Shader-Programme referenzieren, die auf den SMs 440 der PPU 300 zu implementieren sind, einschließlich eines oder mehrere eines Eckpunkt- bzw. Vertex-Shaders, eines Hüllen-Shaders, eines Domain-Shaders, eines Geometrie-Shaders und eines Pixel-Shaders. Beispielsweise kann einer oder mehrere der SMs 440 dazu konfiguriert sein, ein Vertex-Shader-Programm auszuführen, das eine Anzahl von durch die Modelldaten definierten Eckpunkten verarbeitet. In einem Ausführungsbeispiel können die verschiedenen SMs 440 dazu konfiguriert sein, verschiedene Shader-Programme gleichzeitig auszuführen. Beispielsweise kann eine erste Teilmenge von SMs 440 dazu konfiguriert sein, ein Vertex-Shader-Programm auszuführen, während eine zweite Teilmenge von SMs 440 dazu konfiguriert sein kann, ein Pixel-Shader-Programm auszuführen. Die erste Teilmenge von SMs 440 verarbeitet Eckpunkt-Daten, um verarbeitete Eckpunkt-Daten zu erzeugen, und schreibt die verarbeiteten Eckpunkt-Daten in den L2-Cache 460 und/oder den Speicher 304. Nachdem die verarbeiteten Eckpunkt-Daten gerastert sind (d.h. von dreidimensionalen Daten in zweidimensionale Daten im Bildschirmraum umgewandelt wurden), um Fragmentdaten zu erzeugen, führt die zweite Teilmenge von SMs 440 einen Pixel-Shader aus, um verarbeitete Fragmentdaten zu erzeugen, welche dann mit anderen verarbeiteten Fragmentdaten vermischt und in den Frame-Puffer im Speicher 304 geschrieben werden. Das Vertex-Shader-Programm und das Pixel-Shader-Programm können gleichzeitig ausgeführt werden und dabei verschiedene Daten aus derselben Szene in einer Pipeline verarbeiten, bis alle Modelldaten für die Szene in den Frame-Puffer gerendert sind. Anschließend wird der Inhalt des Frame-Puffers an eine Anzeigesteuervorrichtung zur Anzeige auf einer Anzeigevorrichtung übertragen.
6 ist ein konzeptionelles Diagramm einer Grafikverarbeitungs-Pipeline 600, die durch die PPU 300 von 3 gemäß einem Ausführungsbeispiel implementiert wird. Die Grafikverarbeitungs-Pipeline 600 ist ein abstraktes Ablaufdiagramm der Verarbeitungsschritte, die zur Erzeugung von computergenerierten 2D-Bildern aus 3D-Geometriedaten implementiert sind. Wie gut bekannt ist, können Pipeline-Architekturen Operationen bzw. Betriebsabläufe mit langen Latenzzeiten durch Aufspalten der Operation in eine Vielzahl von Stufen effizienter durchführen, indem sie den Betriebsablauf in eine Vielzahl von Stufen aufteilen, wobei der Ausgang jeder Stufe mit dem Eingang der nächsten nachfolgenden Stufe gekoppelt ist. Somit empfängt die Grafikverarbeitungs-Pipeline 600 Eingangsdaten 601, die von einer Stufe zur nächsten Stufe der Grafikverarbeitungs-Pipeline 600 übertragen werden, um Ausgangsdaten 602 zu erzeugen. In einem Ausführungsbeispiel kann die Grafikverarbeitungs-Pipeline 600 eine durch die OpenGL^®-API definierte Grafikverarbeitungs-Pipeline repräsentieren. Optional kann die Grafikverarbeitungs-pipeline 600 im Kontext der Funktionalität und der Architektur der vorangehenden Figuren und/oder (einer) beliebigen nachfolgenden Figur(en) implementiert sein.
Wie in 5 gezeigt ist, umfasst die Grafikverarbeitungs-Pipeline 600 eine Pipeline-Architektur, die mehrere Stufen beinhaltet. Die Stufen beinhalten, sind aber nicht beschränkt auf, eine Daten-Zusammensetzungsstufe 610, eine Vertex-Shading-Stufe 620, eine Stammfunktion-Zusammensetzungsstufe 630, eine Geometrie-Shading-Stufe 640, eine Ansichtsbereich-Skalen-, Cull- und Clip- (VSCC)-Stufe 650, eine Rasterungsstufe 660, eine Fragment-Shading-Stufe 670 und eine Rasteroperationsstufe 680. In einem Ausführungsbeispiel umfassen die Eingangsdaten 601 Befehle, die die Verarbeitungseinheiten dazu konfigurieren, die Stufen der Grafikverarbeitungs-Pipeline 600 und geometrischer Stammfunktionen (z.B. Punkte, Linien, Dreiecke, Vierecke, Dreiecksstreifen oder Fächer, usw.) zu implementieren, die von den Stufen zu verarbeiten sind. Die Ausgangsdaten 602 können Pixeldaten (d.h. Farbdaten) umfassen, die in einen Frame-Puffer oder eine andere Art von Oberflächendatenstruktur in einem Speicher kopiert werden.
Die Daten-Zusammensetzungsstufe 610 empfängt die Eingangsdaten 601, die Eckpunkt-Daten für Oberflächen hoher Ordnung, Stammfunktion oder dergleichen spezifizieren. Die Daten-Zusammensetzungsstufe 610 sammelt die Eckpunkt-Daten in einem Zwischenspeicher oder einer Warteschlange, beispielsweise durch Empfangen eines Befehls von dem Host-Prozessor, der einen Zeiger auf einen Puffer im Speicher enthält, und Lesen der Eckpunkt-Daten aus dem Puffer. Die Eckpunkt-Daten werden dann zur Verarbeitung an die Vertex-Shading-Stufe 620 übertragen.
Die Vertex-Shading-Stufe 620 verarbeitet Eckpunkt-Daten, indem sie einen Satz von Operationen (z.B. einen Vertex-Shader oder ein Programm) einmal für jeden der Eckpunkte durchführt. Eckpunkte können z.B. als ein 4-Koordinaten-Vektor (d.h. <x, y, z, w>) angegeben sein, der einem oder mehreren Eckpunkt-Attributen (z.B. Farbe, Texturkoordinaten, Oberflächennormale, usw.) zugeordnet ist. Die Vertex-Shading-Stufe 620 kann einzelne Eckpunkt-Attribute wie Position, Farbe, Texturkoordinaten und dergleichen manipulieren. Mit anderen Worten führt die Vertex-Shading-Stufe 620 Operationen an den Eckpunkt-Koordinaten oder anderen Eckpunkt-Attributen durch, die einem Eckpunkt zugeordnet sind. Solche Operationen beinhalten üblicherweise Beleuchtungsoperationen (d.h. ein Modifizieren von Farbattributen für einen Eckpunkt) und Transformationsoperationen (d.h. ein Modifizieren des Koordinatenraums für einen Eckpunkt). Beispielsweise können Eckpunkte unter Verwendung von Koordinaten in einem Objektkoordinatenraum spezifiziert sein, welche durch Multiplizieren der Koordinaten mit einer Matrix, die die Koordinaten aus dem Objektkoordinatenraum in einen Welt-Raum oder einen für eine Vorrichtung normalisierten Koordinatenraum (normalized-device-coordinate; NCD) übersetzt, transformiert werden. Die Vertex-Shading-Stufe 620 erzeugt transformierte Eckpunkt-Daten, die an die Stammfunktion-Zusammensetzungsstufe 630 übertragen werden.
Die Stammfunktion-Zusammensetzungsstufe 630 sammelt die von der Vertex-Shading-Stufe 620 ausgegebenen Eckpunkte und gruppiert die Eckpunkte zu geometrischen Stammfunktionen zur Verarbeitung durch die Geometrie-Shading-Stufe 640. Beispielsweise kann die Stammfunktion-Zusammensetzungsstufe 630 dazu konfiguriert sein, jeweils drei aufeinanderfolgende Eckpunkte als geometrische Stammfunktion (d.h. ein Dreieck) zur Übertragung an die Geometrie-Shading-Stufe 640 zu gruppieren. In einigen Ausführungsbeispielen können bestimmte Vertices für aufeinanderfolgende geometrische Stammfunktionen wiederverwendet werden (z.B. können zwei aufeinanderfolgende Dreiecke in einem Dreieckstreifen zwei Eckpunkte teilen). Die Stammfunktion-Zusammensetzungsstufe 630 überträgt geometrische Stammfunktionen (d.h. eine Sammlung von zugehörigen Eckpunkten) an die Geometrie-Shading-Stufe 640.
Die Geometrie-Shading-Stufe 640 verarbeitet geometrische Stammfunktion, indem sie eine Reihe von Operationen (d.h. einen Geometrie-Shader oder ein Programm) auf den geometrischen Stammfunktionen durchführt. Tessellierungsoperationen können aus jeder geometrischen Stammfunktion eine oder mehrere geometrische Stammfunktionen erzeugen. Mit anderen Worten kann die Geometrie-Shading-Stufe 640 jede geometrische Stammfunktion in ein feineres Netzwerk von zwei oder mehr geometrischen Stammfunktionen zur Verarbeitung durch den Rest der Grafikverarbeitungs-Pipeline 600 unterteilen. Die Geometrie-Shading-Stufe 640 überträgt geometrische Stammfunktionen an die Ansichtsbereich-SCC-Stufe 650.
In einem Ausführungsbeispiel kann die Grafikverarbeitungs-Pipeline 600 innerhalb eines Streaming-Multiprozessors arbeiten, und können die Vertex-Shading-Stufe 620, die Stammfunktion-Zusammensetzungsstufe 630, die Geometrie-Shading-Stufe 640, die Fragment-Shading-Stufe 670 und/oder damit verbundene Hardware/Software sequenziell Verarbeitungsoperationen durchführen. Sobald die sequentiellen Verarbeitungsoperationen abgeschlossen sind, kann in einem Ausführungsbeispiel die Ansichtsbereich-SCC-Stufe 650 die Daten nutzen. In einem Ausführungsbeispiel können Stammfunktionsdaten, die von einer oder mehreren Stufen in der Grafikverarbeitungs-Pipeline 600 verarbeitet werden, in einen Cache (z.B. den L1-Cache, den Eckpunkt-Cache, usw.) geschrieben werden. In diesem Fall kann in einem Ausführungsbeispiel die Ansichtsbereich-SCC-Stufe 650 auf die Daten in dem Cache zugreifen. In einem Ausführungsbeispiel sind die Ansichtsbereich-SCC-Stufe 650 und die Rasterungsstufe 660 als Schaltungsanordnung mit fester Funktion implementiert.
Die Ansichtsbereich-SCC-Stufe 650 führt eine Ansichtsbereich-Skalierung, ein Culling und ein Clipping der geometrischen Stammfunktionen durch. Jede Oberfläche, auf die gerendert wird, ist einer abstrakten Kameraposition zugeordnet. Die Kameraposition repräsentiert eine Position eines Betrachters, der die Szene betrachtet, und definiert einen Betrachtungskegelstumpf, der die Objekte der Szene umschließt. Der Betrachtungskegelstumpf kann eine Betrachtungsebene, eine hintere Ebene und vier Clipping-Ebenen beinhalten. Jede geometrische Stammfunktion, die sich vollständig außerhalb des Betrachtungskegelstumpfs befindet, kann gecullt (d.h. verworfen) werden, weil die geometrische Stammfunktion nicht zu der endgültigen gerenderten Szene beitragen wird. Jede geometrische Stammfunktion, die sich teilweise innerhalb des Betrachtungskegelstumpfs und teilweise außerhalb des Betrachtungskegelstumpfs befindet, kann abgeschnitten werden (d.h. in eine neue geometrische Stammfunktion umgewandelt werden, die innerhalb des Betrachtungskegelstumpfs eingeschlossen ist). Darüber hinaus können geometrische Stammfunktion jeweils auf der Grundlage einer Tiefe des Betrachtungskegelstumpfs skaliert werden. Alle potenziell sichtbaren geometrischen Stammfunktionen werden dann an die Rasterungsstufe 660 übertragen.
Die Rasterungsstufe 660 wandelt die geometrischen 3D-Stammfunktionen in 2D-Fragmente (die z.B. zur Anzeige genutzt werden können, usw.) um. Die Rasterungsstufe 660 kann dazu konfiguriert sein, die Eckpunkte der geometrischen Stammfunktionen zu nutzen, um einen Satz von Ebenengleichungen aufzustellen, aus welchen verschiedene Attribute interpoliert werden können. Die Rasterungsstufe 660 kann auch eine Abdeckungsmaske für eine Vielzahl von Pixeln berechnen, die angibt, ob eine oder mehrere Musterorte für den Pixel die geometrische Stammfunktion unterbrechen. In einem Ausführungsbeispiel kann darüber hinaus ein z-Test durchgeführt werden, um zu ermitteln, ob die geometrische Stammfunktion durch andere geometrische Stammfunktionen, die bereits gerastert wurden, verdeckt wird. Die Rasterungsstufe 660 erzeugt Fragmentdaten (d.h. interpolierte Eckpunkt-Attribute, die einem bestimmten Musterort für jedes abgedeckte Pixel zugeordnet sind), die an die Fragment-Shading-Stufe 670 übertragen werden.
Die Fragment-Shading-Stufe 670 verarbeitet Fragmentdaten durch Durchführen einer Reihe von Operationen (z.B. einen Fragment-Shader oder ein Programm) an jedem der Fragmente. Die Fragment-Shading-Stufe 670 kann Pixeldaten (d.h. Farbwerte) für das Fragment erzeugen, z.B. durch Durchführen von Beleuchtungsoperationen oder Abtasten von Textur-Maps unter Verwendung interpolierter Texturkoordinaten für das Fragment. Die Fragment-Shading-Stufe 670 erzeugt Pixeldaten, die an die Rasteroperationsstufe 680 übertragen werden.
Die Rasteroperationsstufe 680 kann verschiedene Operationen an den Pixeldaten durchführen, wie z.B. Alpha-Tests, Schablonentests und ein Mischen der Pixeldaten mit anderen Pixeldaten, die anderen Fragmenten entsprechen, die dem Pixel zugeordnet sind. Wenn die Rasteroperationsstufe 680 das Verarbeiten der Pixeldaten (d.h. der Ausgabedaten 602) abgeschlossen hat, können die Pixeldaten in ein Renderziel, wie beispielsweise ein Frame-Puffer, ein Farbpuffer oder dergleichen, geschrieben werden.
Es versteht sich, dass zusätzlich zu oder anstelle von einer oder mehrerer der vorstehend beschriebenen Stufen eine oder mehrere zusätzliche Stufen in der Grafikverarbeitungs-Pipeline 600 enthalten sein können. Verschiedene Implementierungen der abstrakten Grafikverarbeitungs-Pipeline können verschiedene Stufen implementieren. Ferner können in manchen Ausführungsbeispielen eine oder mehrere der vorstehend beschriebenen Stufen aus der Grafikverarbeitungs-Pipeline ausgeschlossen sein (wie beispielsweise die Geometrie-Shading-Stufe 640). Andere Arten von Grafikverarbeitungs-Pipelines werden als im Rahmen der Offenbarung liegend betrachtet. Ferner kann jede der Stufen der Grafikverarbeitungs-Pipeline 600 durch eine oder mehrere dedizierte Hardwareeinheiten innerhalb eines Grafikprozessors wie beispielsweise der PPU 300 implementiert sein. Andere Stufen der Grafikverarbeitungs-Pipeline 600 können durch programmierbare Hardwareeinheiten wie beispielsweise den SM 440 der PPU 300 implementiert sein.
Die Grafikverarbeitungs-Pipeline 600 kann über eine Anwendung, die von einem Host-Prozessor, wie beispielsweise einer CPU, ausgeführt wird, implementiert sein. In einem Ausführungsbeispiel kann ein Gerätetreiber eine Anwendungsprogrammierschnittstelle (API) implementieren, die verschiedene Funktionen definiert, die von einer Anwendung genutzt werden können, um grafische Daten zur Anzeige zu erzeugen. Der Gerätetreiber ist ein Softwareprogramm, das eine Vielzahl von Anweisungen beinhaltet, die den Betriebsablauf der PPU 300 steuern. Die API stellt eine Abstraktion für einen Programmierer bereit, die es einem Programmierer ermöglicht, spezielle Grafikhardware, wie beispielsweise die PPU 300, zu verwenden, um die grafischen Daten zu erzeugen, ohne dass der Programmierer den spezifischen Befehlssatz für die PPU 300 verwenden muss. Die Anwendung kann einen API-Aufruf beinhalten, der an den Gerätetreiber für die PPU 300 weitergeleitet wird. Der Gerätetreiber interpretiert den API-Aufruf und führt verschiedene Operationen durch, um auf den API-Aufruf zu reagieren. In einigen Fällen kann der Gerätetreiber durch Ausführen von Anweisungen auf der CPU Operationen durchführen. In anderen Fällen kann der Gerätetreiber zumindest teilweise Operationen durchführen, indem er Operationen auf der PPU 300 über eine Eingabe-/Ausgabe-Schnittstelle zwischen der CPU und der PPU 300 startet, In einem Ausführungsbeispiel ist der Gerätetreiber dazu konfiguriert, die Grafikverarbeitungs-Pipeline 600 unter Verwendung der Hardware der PPU 300 zu implementieren.
Innerhalb der PPU 300 können verschiedene Programme ausgeführt werden, um die verschiedenen Stufen der Grafikverarbeitungs-Pipeline 600 zu implementieren. Beispielsweise kann der Gerätetreiber einen Kernel auf der PPU 300 starten, um die Vertex-Shading-Stufe 620 auf einem SM 440 (oder mehreren SMs 440) durchzuführen. Der Gerätetreiber (oder der initiale Kernel, der von der PPU 400 ausgeführt wird) kann auch andere Kernel auf der PPU 400 starten, um andere Stufen der Grafikverarbeitungs-Pipeline 600 durchzuführen, wie z.B. die Geometrie-Shading-Stufe 640 und die Fragment-Shading-Stufe 670. Darüber hinaus können einige der Stufen der Grafikverarbeitungs-Pipeline 600 auf fester Einheitshardware wie beispielsweise einem Rasterisierer oder einem innerhalb der PPU 400 implementierten Datenassembler implementiert sein. Es versteht sich, dass die Ergebnisse eines Kernels von einer oder mehreren dazwischenliegenden Hardwareeinheiten mit fester Funktion verarbeitet werden können, bevor sie von einem nachfolgenden Kernel auf einem SM 440 verarbeitet werden.
Maschinelles Lernen
Tiefe neuronale Netzwerke bzw. Deep Neural Networks (DNNs), die auf Prozessoren wie beispielsweise der PPU 300 entwickelt wurden, wurden für verschiedene Anwendungsfälle eingesetzt, von selbstfahrenden Autos bis hin zu schnellerer Medikamentenentwicklung, von der automatischen Bildüberschrift in Online-Bilddatenbanken bis hin zur intelligenten Echtzeit-Sprachübersetzung in Video-Chat-Anwendungen. Deep Learning ist eine Technik, die den neuronalen Lernprozess des menschlichen Gehirns modelliert, kontinuierlich lernt, kontinuierlich intelligenter wird und im Laufe der Zeit schnellere und genauere Ergebnisse liefert. Ein Kind wird zunächst von einem Erwachsenen gelehrt, verschiedene Formen richtig zu identifizieren und zu klassifizieren, um schließlich ohne Coaching Formen identifizieren zu können. Ebenso muss ein tief lernendes oder neuronal lernendes System in der Objekterkennung und -klassifizierung trainiert werden, damit es intelligenter und effizienter grundlegende Objekte, verdeckte Objekte usw. identifizieren und gleichzeitig den Objekten Kontext zuweisen kann.
Auf der einfachsten Ebene betrachten Neuronen im menschlichen Gehirn verschiedene Inputs bzw. Eingaben, die empfangen werden, werden jedem dieser Inputs Wichtigkeitsstufen zugewiesen, und wird ein Output bzw. eine Ausgabe an andere Neuronen weitergeleitet, um darauf zu reagieren. Ein künstliches Neuron oder Perzeptron ist das grundlegendste Modell eines neuronalen Netzwerks. In einem Beispiel kann ein Perzeptron eine oder mehrere Eingaben empfangen, die verschiedene Merkmale eines Objekts darstellen, für die das Perzeptron trainiert wird, um sie zu erkennen und zu klassifizieren, und wird jedem dieser Merkmale ein bestimmtes Gewicht zugewiesen, das auf der Bedeutung dieses Merkmals für die Definition der Form eines Objekts basiert.
Ein Deep Neural Network (DNN)-Modell beinhaltet mehrere Schichten vieler verbundener Perzeptrons (beispielsweise Knoten), die mit enormen Mengen von Eingangsdaten trainiert werden können, um komplexe Probleme mit hoher Genauigkeit schnell zu lösen. In einem Beispiel zerlegt eine erste Schicht des DNN-Modells ein Eingangsbild eines Autos in verschiedene Abschnitte und sucht nach Grundmustern wie beispielsweise Linien und Winkeln. Die zweite Schicht setzt die Linien zusammen, um nach Mustern höherer Ebene wie beispielsweise Rädern, Windschutzscheiben und Spiegeln zu suchen. Die nächste Schicht identifiziert den Fahrzeugtyp, und die letzten paar Schichten erzeugen ein Label für das Eingangsbild, das das Modell einer bestimmten Automobilmarke identifiziert.
Sobald das DNN trainiert ist, kann das DNN eingesetzt und dazu verwendet werden, Objekte oder Muster in einem Prozess, der als Inferenz bzw. Schlussfolgerung bekannt ist, zu identifizieren und zu klassifizieren. Beispiele für Schlussfolgerungen (der Prozess, durch welchen ein DNN nützliche Informationen aus einer gegebenen Eingabe extrahiert) beinhalten das Identifizieren von handschriftlichen Zahlen auf Schecks, die in Geldautomaten hinterlegt werden, das Identifizieren von Bildern von Freunden auf Fotos, das Liefern von Filmempfehlungen an über fünfzig Millionen Benutzer, das Identifizieren und Klassifizieren verschiedener Arten von Automobilen, Fußgängern und Straßengefahren in fahrerlosen Autos oder das Übersetzen menschlicher Sprache in Echtzeit.
Während des Trainings fließen Daten in einer Vorwärtspropagationsphase durch das DNN, bis eine Vorhersage erstellt wird, die ein dem Input entsprechendes Label angibt. Wenn das neuronale Netzwerk die Eingabe nicht korrekt kennzeichnet, werden Fehler zwischen der korrekten Bezeichnung und der vorhergesagten Kennzeichnung analysiert und werden die Gewichte für jedes Merkmal während einer Rückwärtspropagationsphase angepasst, bis das DNN die Eingabe und andere Eingaben in einem Trainingsdatensatz korrekt kennzeichnet. Das Training komplexer neuronaler Netze erfordert enorme Mengen an paralleler Rechenleistung, einschließlich von Gleitkomma-Multiplikationen und Additionen, die von der PPU 300 unterstützt werden. Die Inferenzierung ist weniger rechenintensiv als das Training, da es sich um einen latenzsensitiven Prozess handelt, bei dem ein trainiertes neuronales Netzwerk auf neue Eingaben, die es bisher noch nicht gegeben hat, angewendet wird, um Bilder zu klassifizieren, Sprache zu übersetzen und generell neue Informationen abzuleiten.
Neuronale Netzwerke sind stark auf Matrix-Mathematik-Operationen angewiesen, und komplexe mehrschichtige Netzwerke erfordern enorme Mengen an Gleitkommaleistung und Bandbreite für sowohl Effizienz als auch Geschwindigkeit. Mit Tausenden von Rechenkernen, die für Matrix-Mathematik-Operationen optimiert sind und Hunderte von TFLOPS an Leistung liefern, ist die PPU 300 eine Rechenplattform, die in der Lage ist, die Leistung zu liefern, die für auf tiefen neuronalen Netzwerken basierende künstliche Intelligenz und Anwendungen des maschinellen Lernens erforderlich ist.
Gleichzeitige Berechnung und Grafik auf SM mit unsymmetrischem Arbiter
7 veranschaulicht schematisch weitere Einzelheiten des Hardware-Schedulers und des Hardware-Arbiters, die unter Bezugnahme auf 1 und 2 beschrieben sind, anhand einiger beispielhafter Ausführungsbeispiele. Insbesondere veranschaulicht 7 einen MPC 702 einer PPU (z.B. der PPU 102) und einen in dem MPC 702 implementierten Scheduler und Arbiter. In dem in 7 dargestellten Ausführungsbeispiel befinden sich der Hardware-Scheduler 708 und der Hardware-Arbiter 710 in dem MPC 702, der dem SM 704 zugeordnet ist. In einigen Ausführungsbeispielen sind einer oder beide oder des Schedulers 708 und des Arbiters 710 außerhalb des MPCs 702, aber innerhalb desselben DPCs wie der SM 704 implementiert. Die physikalische Nähe des Arbiters 710 zu dem SM 704 ermöglicht schnelle Reaktionszeiten, die notwendig sind, um die allmähliche Zufuhr von nicht-hungrigen Arbeiten zu dem SM effektiv durchzuführen. Die physikalische Nähe verbessert darüber hinaus die Genauigkeit einer Rückmeldung über die SM-Auslastung.
Gemäß einigen Ausführungsbeispielen können der Scheduler 708 und der Arbiter 710 den Implementierungen jeweils des Schedulers 110 und des Arbiters 112 entsprechen. Gemäß einigen Ausführungsbeispielen arbeiten der Scheduler 708 und der Arbiter 710 in einem DPC-Level-Arbiter-Modus, der dahingehend „unsymmetrisch“ ist, dass jeder MPC Entscheidungen unabhängig auf der Grundlage lokaler Informationen seines DPCs trifft (der DPC und der MPC sind unter Bezugnahme auf 4A beschrieben).
Der Scheduler 708 teilt wiederholt Gruppen von Threads über einen Warp-Startblock 712 zu, um diese auf dem SM 704 auszuführen. Die Warp-Informationen 713, die der Warp-Startblock 712 dem SM 704 bereitstellt, können Warp-Prioritätsinformationen beinhalten, die von dem SM in Zuteilungsanweisungen verwendet werden können. Die Thread-Gruppen umfassen Grafik-Arbeitselemente 718 aus einer Grafik-Warteschlange oder Rechen-Arbeitselemente 720 aus einer Rechen-Warteschlange und werden von dem Scheduler 708 in Übereinstimmung mit dem aktuellen Prioritätsmodus (z.B. dem grafikhungrigen Modus oder dem rechenhungrigen Modus) erhalten. Jede Gruppe von Threads kann eine Gruppe von 32 Threads sein, die, wie zuvor beschrieben wurde, als ein Warp bezeichnet werden kann. Da ein SM gemäß einigen Ausführungsbeispielen 32 Warps (jeweils mit 32 Threads) gleichzeitig ausführen kann, kann der Scheduler Rechen-Warps und Grafik-Warps in verschiedenen Proportionen zuweisen, um sie gleichzeitig auf einem bestimmten SM auszuführen.
Der Arbiter 710 überwacht einen vorbestimmten Satz von Ressourcenauslastungsmetriken im Hinblick auf einen oder mehrere richtliniengesteuerte Schwellenwerte und veranlasst durch Bereitstellen eines Signals 716 den Scheduler 708, der derzeit in einem bestimmten hungrigen Modus arbeitet, einige Arbeitselemente aus der Warteschlange nicht-hungriger Arbeit zuzuteilen.
Der Rückmeldungsblock 714 kann die Überwachung der vorbestimmten Ressourcennutzung in Übereinstimmung mit einem Satz von Schwellenwerten, die in der Richtlinie festgelegt sind, implementieren.
In einigen Ausführungsbeispielen kann sich die Art und Weise, in der der Scheduler 708 Grafik-Arbeitselemente erhält, von der Art und Weise unterscheiden, wie er Rechen-Arbeitselemente empfangen hat. In der schematischen Darstellung von 7 kann der Scheduler 708 direkt (oder über die Frontend-Einheit (nicht gezeigt)) Grafik-Arbeitselemente aus einer Grafik-Warteschlange erhalten, muss aber Rechen-Arbeitselemente von einer Rechenarbeitsverteilungseinheit 706 anfordern. Die Rechenarbeitsverteilungseinheit 706 kann einen Rechenarbeitsverteiler (CWD) 722 und eine Rechenzuteilungseinheit (CSU) 724 beinhalten, die jeweils die Verteilung und die Zuteilung von Rechen-Arbeitselementen zwischen mehreren SMs durchführen.
8 veranschaulicht einen Prozess 800, durch den eine Anwendung die Zuteilungsrichtlinie konfigurieren kann, um einige Aspekte zu steuern, wie eine GPU (oder eine andere Art von PPU) ihre Grafik-Arbeitselemente und ihre Rechen-Arbeitselemente zuteilt. Der Prozess 800 kann beispielsweise von einer Anwendung wie beispielsweise der Anwendung 122 (z.B. ein Spiel, eine Anwendung mit einer Physiksimulation, einer anderen Anwendung, die eine API wie beispielsweise DX12 verwendet, usw.) durchgeführt werden, die auf der CPU 124 ausgeführt wird.
Nach dem Eintreten in den Prozess 800 kann die Anwendung bei Operation 802 eine Zuteilungsrichtlinie festlegen. Die Zuteilungsrichtlinie kann Konfigurationen zum Auswählen eines Arbiters aus einer Vielzahl von in dem System verfügbaren Arbitern, einer oder mehrerer Leistungsmetriken und/oder Ressourcenauslastungs-/Belegungsschwellen zur Verwendung beim Erkennen von „Lücken“ ungenutzter Ressourcenkapazität für jeden des grafikhungrigen Betriebsmodus und des rechenhungrigen Betriebsmodus, Bruchteilsraten, mit denen nicht-hungrige Arbeitselemente eingeführt werden können, usw. beinhalten.
Parameter, die als Inhalte einer Richtlinie konfiguriert werden können, können separate Parametersätze für Grafiken und Berechnungen beinhalten. Die Parameter sind in Übereinstimmung mit den Eigenschaften jeder Ressource und der Art der Arbeit konfiguriert. Während es hilfreich sein kann, als eine Leistungs- und/oder Ressourcenauslastungsmetrik zu berücksichtigen, ob die Ausgabe der Grafikarbeit angehalten ist, kann, da zumindest in einigen Ausführungsbeispielen die Berechnung in gemeinsam genutzten Speicher ausgegeben wird, die Überwachung der Verzögerung der Ausgabe für die Berechnung keinen zusätzlichen Nutzen bringen. Im Gegensatz zur Berechnung, die in gemeinsam genutzten Speicher ausgegeben wird, kann der SM eine oder mehrere Beschleunigungseinheiten mit fester Funktion für Grafikarbeit verwenden. Die Berücksichtigung des Anhaltens an dem SM aufgrund eines Gegendrucks aus diesen Einheiten mit fester Funktion in den Ausgabeaussetzungsmetriken für Grafik ermöglicht es dem Hardware-Scheduler in Situationen, in denen die dem SM zugeordneten Einheiten mit fester Funktion bereits gesichert sind, die Berechnung zu planen, ohne weitere Grafik zuzuteilen.
Die grafikbezogenen Richtlinienparameter, die als Schwellenwerte festgelegt sind, können beinhalten, sind aber nicht beschränkt auf: einen Eingabeleerzeit-Schwellenwert(e), welche den Schwellenwert angeben, unterhalb dessen der Arbiter davon ausgehen kann, dass eine bestimmte Eingabe-Pipeline den SM leer laufen lässt (dieser Parameter kann für jede der Alpha-, der Beta- und der Pixel-Pipeline separat angegeben werden (beispielsweise INPUT_STARVED_ALPHA, INPUT_STARVED_BETA bzw. INPUT_STARVED_PIX); jede Metrik kann als Integral einer binären Ausgangsprüfung berechnet werden, falls die jeweilige Art von Arbeit in der Eingabe-Warteschlange über das Mittelungsfenster hinweg verfügbar ist); einen Ausgabeaussetzungsschwellenwert(e), welche den Schwellenwert angeben, oberhalb dessen der Arbiter ein bestimmtes Ausgabeziel als den SM aussetzend bzw. verlangsamend betrachten kann, weil die Ausgabe nicht so schnell aufgenommen werden kann, wie der SM diese produziert (dieser Parameter kann für jede der Alpha-Pipeline, der Beta-Pipeline, die beide in ISBE-Speicher ausgeben, und der Pixel-Pipeline, die an PROP/GPM ausgibt, separat angegeben werden (beispielsweise PE_ALPHA_OUT_STALL, PE_BETA_OUT_STALL, GPM_PIX_OUT_STALL); kann als ein Verhältnis zwischen der Menge an ISBE, die auf eine Auswärtskopie wartet, und der Menge an ISBE, die von Live-Warps zugewiesen wurde und noch verwendet wird, oder als ein Verhältnis zwischen den Pixelregistern, die bereits berechnet wurden, aber auf die Entleerung zu den Pixelregistern warten, die noch von Pixel-Warps verwendet werden, berechnet werden; einen Grafik-Warp-Belegungsschwellenwert, der den Grafikhungrigkeitsschwellenwert (beispielsweise GFX_WARP_OCCUPANCY) für Warp-Ressourcen repräsentiert, oberhalb dessen der Arbiter beschließen kann, eine Berechnung zu starten; einen Grafik-Registerdatei-Belegungsschwellenwert (beispielsweise GFX_RF_OCCUPANCY), welcher den Grafikhungrigkeitsschwellenwert für die Registerdatei-Ressource repräsentiert, oberhalb dessen der Arbiter beschließen kann, die Berechnung zu starten; und einen grafischen ISBE-Belegungsschwellenwert (z.B. GFX_ISBE_OCCUPANCY), der den Grafikhungrigkeitsschwellenwert für ISBE darstellt, oberhalb dessen der Arbiter beschließen kann, die Berechnung zu starten. Jede der Belegungen kann als ein Integral der momentanen Rechen-Warp-Belegung für einen DPC über ein konfigurierbares Mittelungsfenster hinweg berechnet werden.
Die grafikbezogenen Richtlinienparameter beinhalten darüber hinaus eine Grafikpriorität, die die Prioritätsstufe für die Grafikarbeit angibt (dies ist in Bezug auf die von dem Treiber innerhalb jeder Rechen-Arbeitselement-Datenstruktur festgelegte Berechnungspriorität), und die Anzahl von Subkacheln oder einer anderen spezifizierten Menge an Arbeit, die in dem MPC zu reservieren ist, wenn Grafik von dem Arbiter in dem rechenhungrigen Modus gewährt wird. Die Voreinstellung ist auf einen kleinen Wert wie z.B. 1 festgelegt, um im rechenhungrigen Modus Grafik allmählich einfließen zu lassen.
Die rechenbezogenen Richtlinienparameter, die als Schwellenwerte festgelegt sind, können beinhalten, sind aber nicht beschränkt auf: einen Eingabeleerzeit-Rechenschwellenwert (beispielsweise INPUT_STARVED_COMP), bei welchem der Arbiter davon ausgehen kann, dass die Berechnung den SM leer laufen lässt (kann als ein Integral einer binären Ausgangsprüfung berechnet werden, falls eine Aufgabensynchronisierung ohne einen Nack über das Mittelungsfenster hinweg aussteht); einen Rechen-Warp-Belegungsgrenzwert (beispielsweise COMP_WARP_OCCUPANCY), die den Rechenhungrigkeits-Belegungsschwellenwert angibt, oberhalb dessen der Arbiter beschließen kann, Grafik zu starten; einen Rechen-Registerdatei-Schwellenwert (beispielsweise COMP_RF_OCCUPANCY), die den Rechenhungrigkeits-Belegungsschwellenwert für die Registerdatei-Ressource angibt, oberhalb dessen der Arbiter beschließen kann, Grafik zu starten; und einen Rechen-Shared Memory-Belegungsschwellenwert (beispielsweise COMP_SHM_OCCUPANCY), der den Rechenhungrigkeits-Belegungsschwellenwert der gemeinsam genutzten Speicherressource darstellt, oberhalb dessen der Arbiter beschließen kann, Grafik zu starten.
Die rechenbezogenen Richtlinienparameter beinhalten darüber hinaus eine Rechenpriorität, die die Prioritätsstufe repräsentiert, die für Rechenarbeit festzulegen ist (dies ist beispielsweise die von dem Treiber innerhalb jeder Rechen-Arbeitselement-Datenstruktur (manchmal beispielsweise auch als „QMD“ bezeichnet)) festgelegte Priorität, und einen Rechen-MPC-Ressourcenreserveparameter, der die Anzahl der CTAs („kooperatives Thread-Array“ (vorstehend auch kooperative Gruppe) oder eine andere Menge von Rechenarbeit) repräsentiert, die in dem MPC zu reservieren ist, wenn die Berechnung von dem Arbiter in dem grafikhungrigen Modus gewährt wird. Die Voreinstellung ist auf einen kleinen Wert wie z.B. 1 festgelegt, um Berechnungen in dem grafikhungrigen Modus allmählich einfließen zu lassen.
In einigen Ausführungsbeispielen können die Richtlinienparameter auch eine Größe des Mittelungsfensters beinhalten, die die Fensterdauer definiert, über welche hinweg die Mittelung von dem MPC für SCG-SM Arbiter-Eingabestatistiken durchgeführt wird. Der MPC kann einen Gleitfensterdurchschnitt für die dem SCG-SM-Arbiter bereitgestellten Statistiken implementieren. In einigen Ausführungsbeispielen kann dieses Fenster anstelle eines Zeitfensters als eine Gesamtzahl von Abtastungen implementiert sein. Die Richtlinienparameter können darüber hinaus eine Abtastdauer beinhalten, die die Abtastrate für das Integral für das Fenster definiert.
Bei Operation 804 kann die Anwendung Anweisungen und Arbeitselemente in Streams von einem oder mehreren Grafik-Arbeitselementen und/oder einem oder mehreren Rechen-Arbeitselementen an die GPU übertragen. Die Arbeitselemente können in geeigneter Weise in eine Grafik-Warteschlange und eine Rechen-Warteschlange eingereiht werden, auf die der Grafikprozessor zugreift. Die den Arbeitselementen zugeordneten Anweisungen können an die GPU übermittelt werden.
Die Übertragung von Grafik-Arbeitselementen und Rechen-Arbeitselementen kann während der Ausführung der Anwendung auf der CPU fortgesetzt werden und kann bewirken, dass Grafiken auf einer Anzeige des Systems wiedergegeben werden.
9 zeigt ein Ablaufdiagramm eines Prozesses 900, der von einem Hardware-Scheduler, wie beispielsweise dem Scheduler 708, durchgeführt werden kann, gemäß einigen beispielhaften Ausführungsbeispielen.
Nach dem Eintreten in den Prozess 900 bestimmt der Scheduler bei Operationen 902 - 904 den aktuellen Prioritätsmodus der GPU. Die höhere der Prioritäten, die dem nächsten Arbeitselement in der Grafik-Warteschlange und dem nächsten Element in der Rechen-Warteschlange zugeordnet sind, kann dazu verwendet werden, den aktuellen Prioritätsmodus zu bestimmen. Wenn beispielsweise das nächste Arbeitselement in der Grafik-Warteschlange eine höhere Priorität hat als das nächste Element in der Rechen-Arbeitswarteschlange, dann wird der aktuelle Prioritätsmodus auf den grafikhungrigen Modus festgelegt. Alternativ wird dann, wenn das nächste Element in der Rechen-Warteschlange eine höhere Priorität hat als die in der Grafik-Warteschlange, die GPU auf den rechenhungrigen Modus gesetzt.
Die Prioritäten für die Arbeitselemente können von der Anwendung in gleicher Größenordnung sowohl für grafische Arbeitselemente als auch für Rechen-Arbeitselemente festgelegt werden, um sie miteinander vergleichen zu können. In einigen beispielhaften Ausführungsbeispielen ist jedem Grafik-Arbeitselement und jedem Rechen-Arbeitselement ein Prioritätswert in der Skala 1 - 63 zugeordnet. Gemäß einigen Ausführungsbeispielen kann die Priorität von Grafik-Arbeitselementen inline mit dem Befehlsstrom festgelegt werden, und kann die Priorität von Rechen-Arbeitselementen in den Arbeitselementen selbst festgelegt werden.
In einigen Ausführungsbeispielen kann die Grafikpriorität von der Anwendung oder einem Treiber in einem Inline-Grafikbefehl angegeben werden. Die Priorität der Festlegung der Grafikbefehle kann an der Spitze der Pixel-Pipeline abgetastet werden, so dass sie mit allen vorherigen Pixel-Arbeiten in strenger Reihenfolge bleibt (aber nicht in strenger Reihenfolge mit nachfolgenden Eckpunkt- bzw. Vertex-Arbeiten). Die Rechenpriorität kann aus einem Feld in dem Rechen-Arbeitselement für das aktuelle Raster, das durch CWD verteilt wird, bestimmt werden.
Bei Operation 902 erfasst der Scheduler die Prioritäten der nächsten Elemente in jeder der Grafik-Warteschlange und der Rechen-Warteschlange, und führt bei Operation 904 eine Bestimmung dahingehend durch, welche Priorität höher ist.
Falls die Grafikpriorität als höher oder gleich bestimmt wird, dann wird bei Operation 906 der Scheduler so eingestellt, dass er in dem grafikhungrigen Modus arbeitet. Der Betrieb in dem grafikhungrigen Modus beinhaltet das wiederholte Starten von Grafik-Arbeitselementen aus der Grafik-Warteschlange, wobei vor allem die Grafikstatistiken berücksichtigt werden, um zu entscheiden, wann etwas mehr Rechenarbeit zuzuteilen ist.
In dem grafikhungrigen Modus wählt der Scheduler bei Operation 908 wiederholt das nächste Element aus der Grafik-Warteschlange aus und startet es zur Ausführung auf dem zugehörigen SM. Die Operation 908 wird so lange wiederholt, bis entweder die Grafik-Warteschlange leer ist, der Scheduler dem grafikhungrigen Modus verlässt oder ein Signal zum Starten eines oder mehrerer nicht-hungriger Arbeitselemente empfangen wird. Wie vorstehend beschrieben wurde, kann ein solches Signal zum „allmählichen einfließen lassen“ („trickle“) einiger nicht-hungriger Arbeitselemente, welche in diesem Fall Rechen-Arbeitselemente sind, von einem Hardware-Arbiter wie dem Arbiter 710 erzeugt werden. Bei Operation 910 wird bestimmt, ob ein Signal (beispielsweise ein Rechenstartbefehl) von dem Arbiter empfangen wurde, um nichthungriges (in diesem Fall Rechen-Arbeitselemente) allmählich einfließen zu lassen. Falls ja, schreitet der Prozess 900 zu Operation 914 fort, um ein oder mehrere Rechen-Arbeitselemente zu starten. Die Anzahl von Arbeitselementen, die gestartet wird, wenn in dem grafikhungrigen Modus Rechenarbeit langsam einfließt, kann auf Richtlinienparametern basieren (beispielsweise der Anzahl von CTAs, die durch einen COMP_MPC_RESOURCE_RESERVE-Parameter angegeben werden, welcher typischerweise auf 1 gesetzt ist, so dass der MPC nur 1 CTA für jeden Rechenstartbefehl von dem SCG-SM-Arbiter starten wird).
Falls nein, wird bei Operation 911 bestimmt, ob sich der Scheduler noch im grafikhungrigen Modus befindet. Falls sich der Scheduler noch im grafikhungrigen Modus befindet, schreitet der Prozess 900 zu Operation 908 fort, um weitere Grafik-Arbeitselemente zu starten. Falls sich der Scheduler nicht mehr in dem grafikhungrigen Modus befindet, dann kann beispielsweise der Prozess 900 zu Operation 914 fortschreiten, um die Verarbeitung in dem rechenhungrigen Modus fortzusetzen.
Falls bei Operation 904 bestimmt wird, dass die Rechenpriorität größer als die Grafikpriorität ist, dann wird bei Operation 912 der Scheduler so eingestellt, dass er im rechenhungrigen Modus arbeitet. Der Betrieb im rechenhungrigen Modus beinhaltet das wiederholte Starten von Rechen-Arbeitselementen aus der Rechen-Warteschlange, während hauptsächlich die Rechen-Statistiken berücksichtigt werden, um zu entscheiden, wann etwas mehr Grafikarbeit zugeteilt werden kann.
Ein Wechseln aus einem grafikhungrigen Modus zu einem rechenhungrigen Modus kann bestimmte Schritte involvieren. Falls die Änderung durch eine hohe Aufgabenpriorität aufgrund einer Aufgabensynchronisation durch CWD verursacht wird, dann kann der MPC die VTG-Arbeiten, welche Registerdateiplatz, Warps und ISBE-Speicher allokiert haben, leeren, die Pixelarbeit, die bereits Ressourcen allokiert hat, leeren und dann auf rechenhungrig umschalten. Es wird angemerkt, dass es möglicherweise nicht erforderlich ist, die gesamte Grafik-Eingangsleitung zu leeren. Alternativ können dann, wenn die Änderung durch Verringern der Grafikpriorität in der Grafik-Pipeline verursacht wird, alle Grafikeingaben vor der Prioritätsfestlegung von dem MPC geleert werden, bevor aus der Grafik heraus auf den hungrigen Modus zum Berechnen umgeschaltet wird.
In einigen Ausführungsbeispielen können die Rechen-Arbeitselemente aus der Rechen-Warteschlange erhalten und auf die gleiche Weise wie Grafik-Arbeitselemente gestartet werden. In den in 7 dargestellten Ausführungsbeispielen werden Rechen-Arbeitselemente jedoch von dem Scheduler in einer gegenüber der für Grafik-Arbeitselemente anderen Art und Weise zugeteilt. In den dargestellten Ausführungsbeispielen reserviert der Scheduler nach dem Festlegen des Starts von Rechen-Arbeitselementen bei Operation 914 Ressourcen für die zu startenden Rechen-Arbeitselemente, und fordert bei Operation 916 der Scheduler Rechenaufgaben an.
In bestimmten beispielhaften Ausführungsbeispielen fordert der Scheduler (oder eine andere Komponente in dem MPC) Rechen-Arbeitselemente von dem CWD an. Der Scheduler kann eine bestimmte Anzahl von CTAs anfordern, wann immer er will (beispielsweise bei der Aufgabensynchronisation, wenn sich die Entscheidung des SCG-SM-Arbiters ändert oder wenn ein CTA abgeschlossen ist). Der CWD wird entweder diese CTAs starten oder dem MPC mit CTA-Start-Nack bzw. CTS-Start-Nicht-Bestätigt antworten. Der CWD rastert CTAs, falls er mehr zu senden hat. Der CWD sendet CTA-Start-Nacks bzw. -Nicht-Bestätigungen, wenn er die von dem MPC angeforderten CTAs nicht starten kann, falls er sich in einem „RechnenlnGrafik“-Modus befindet (d.h. „RechnenlnGrafik“ bzw. „ComputelnGraphics“ bezieht sich auf ein Anfordern eines allmählichen Einfließen lassens von Berechnungen in dem grafikhungrigen Modus). Sobald der MPC CTAs anfordert, werden Ressourcen in dem SM reserviert und besteht eine Garantie dahingehend, dass jedes von dem CWD gestartete CTA schnell auf den SM geladen wird. In dem „RechnenlnGrafik“-Modus kann der MPC basierend auf dem SCG-SM Arbiter CTAs asynchron anfordern.
Das CWD-zu-MPC Protokoll macht den MPC konzeptionell zum Master und lässt den MPC CTAs von dem CWD anfordern. In dem RechnenlnGrafik-Modus ermöglicht das Protokoll dem SCG-SM-Arbiter (entweder lokalisiert auf dem MPC oder im GPM), CTAs zu starten, wann immer er will, ohne dass eine lokale CTA-Warteschlange innerhalb des MPCs erforderlich ist. Mit dem Protokoll im RechnenlnGrafik-Modus kann der CWD basierend auf den CTA-Anfragen von dem MPC Last über SMs hinweg balancieren, wobei die Ressourcen, die von der auf diesen TPCs laufender Grafik belegt werden, bereits berücksichtigt werden.
Mit dem CWD-zu-MPC-Protokoll kann der MPC CTA-Starts von dem CWD auf drei Arten anfordern: mit einem CTA-Berichtspaket zur Aufgabensynchronisationszeit, mit einem CTA-Komplettpaket, wenn ein vorheriges CTA auf dem SM abgeschlossen ist, oder mit einem neuen CTA-Anforderungspaket, wenn der SCG-Arbiter dem MPC sagt, dass er mehr SM-Ressourcen für Berechnungen anstelle von Grafiken verwenden soll. Wenn der SCG-SM-Arbiter den MPC auffordert, weniger SM-Ressourcen für Berechnungen anstelle von Grafik zu verwenden, kann der MPC entweder warten, bis diese alten Anfragen entweder einen CTA-Start zurückgeben oder von dem CWD nicht bestätigt werden, oder kann 0 zusätzliche CTA-Starts anfordern, wenn ein bestehendes CTA abgeschlossen wird. Dieses verschiebt langsam Ressourcen zurück zu Grafik.
Wenn der MPC CTA-Starts von dem CWD anfordert, muss der MPC die erforderlichen SM-Ressourcen für die Berechnung reservieren, bis diese Starts tatsächlich stattfinden oder von dem CWD nicht bestätigt werden. Diese Ressourcen werden nicht für gleichzeitige Grafik-Warp-Starts allokiert und sind für Berechnungen reserviert. Eine neue Aufgabensynchronisation kann zu einer impliziten Nicht-Bestätigung für alle vorherigen Reservierungen führen.
Der SCG-SM-Arbiter kann entscheiden, wann eine Berechnung gestartet werden kann, und kann den MPC darüber informieren, die Anzahl der CTAs zu berechnen, die er von dem CWD anfordern muss. Der MPC kann eine CTA-Anfrage mit der Anzahl der angeforderten CTAs an den CWD stellen, je nachdem, welchen Anteil der SM-Ressourcen die Berechnung verwenden soll. Der MPC kann den Platz in dem SM für diese CTAs vorab zuweisen und die Ressourcen nur bei Empfang eines Nacks von z.B. dem CWD deallokieren. Wenn CTAs von dem CWD ankommen, können sie daher so konfiguriert sein, dass sie die Auswahl innerhalb von MPC-Selektoren für sowohl die Allokierung von gemeinsam genutztem Speicher als auch Registerdatei/Warp-Allokierungen immer gewinnen. Es darf keine Warteschlangen oder Aussetzungen bzw. Verzögerungen von CTAs innerhalb des MPC geben.
Bei Operation 918 wird bestimmt, ob eine Rechenaufgabe empfangen oder abgelehnt wurde. Falls die Anforderung für die Rechenaufgabe abgelehnt wurde (z.B. eine Nicht-Bestätigung empfangen wurde, wie vorstehend beschrieben wurde), dann werden bei Operation 920 die reservierten Ressourcen freigegeben.
Die Ressourcenreservierung kann die verschiedenen Grafikelementtypen in der Grafik-Warteschlange berücksichtigen. Beispielsweise können ISBE für VTG-Warps und gemeinsam genutzter Speicher für Rechen-Warps auf demselben Zwischenregisterspeicher in dem SM zugeordnet werden und können daher um Platz konkurrieren, aber TRAM auf der Pixelseite wird Platz geschaffen haben. Daher kann zumindest in einigen Ausführungsbeispielen eine Nachverfolgung von ISBE- und Shared Memory-Ressourcen in dem MPC vereinheitlicht werden, um dieselben Ressourcenzähler zu verwenden. Für Registerdatei- und Warp-Allokation können die Ressourcen-Nachverfolgungszähler für Berechnung und Grafik vereinheitlicht werden.
Falls die Anforderung für Rechenaufgaben dazu führte, dass eine oder mehrere Aufgaben allokiert wurden (z.B. von dem CWD), dann werden bei Operation 922 die Aufgaben gestartet.
Nach entweder dem Ressourcenfreigabeschritt 920 oder dem Startschritt 922 wird bei Operation 924 bestimmt, ob der Arbiter signalisiert hat, dass nicht-hungrige Elemente (in diesem Fall Grafik-Arbeitselemente) zum Start gebracht werden sollen. Falls ja, dann schreitet der Prozess 900 zu Operation 908 fort, um ein oder mehrere Grafik-Arbeitselemente aus der Grafik-Warteschlange zu starten.
Falls nein, wird bei Operation 925 bestimmt, ob sich der Scheduler noch in dem rechenhungrigen Modus befindet. Falls sich der Scheduler noch in dem rechenhungrigen Modus befindet, schreitet der Prozess 900 zu Operation 914 fort, um weitere Rechen-Arbeitselemente zu starten. Falls sich der Scheduler nicht mehr in dem rechenhungrigen Modus befindet, dann kann beispielsweise der Prozess 900 zu Operation 908 fortschreiten, um die Verarbeitung in dem grafikhungrigen Modus fortzusetzen. Die Anzahl von Grafik-Arbeitselementen, die gestartet werden, wenn sie im rechenhungrigen Modus laufen sollen, kann durch einen richtlinienbasierten Parameter gesteuert werden (z.B. die Anzahl der Subkacheln oder Batches, die durch den Parameter GFX_MPC_RESOURCE_RESERVE angegeben wird, welcher typischerweise auf 1 gesetzt wird, so dass der MPC nur 1 Subkachel (oder eine andere Grafikarbeitseinheit) für jeden Grafikstartbefehl des SCG-SM-Arbiters startet).
Die Priorität von Grafik gegenüber Berechnung beeinflusst auch die Befehlszuteilung in dem SM. Der MPC kann eine 2-Bit-Priorität von Warps während eines Warpstarts auf dem SM festlegen: In dem grafikhungrigen Modus kann der SM mit der folgenden Priorität planen: VTG > PIX > COMP (z.B. Eckpunkt-Grafiken > Pixel-Grafiken > Berechnung); und im rechenhungrigen Modus kann der SM mit der folgenden Priorität planen: COMP > VTG > PIX, gemäß den von dem MPC kommunizierten Prioritäten.
Der SCG-SM-Arbiter vermittelt bzw. arbitriert zwischen Berechnung/Grafik und kann Eingaben für die Selektoren innerhalb des MPC bereitstellen, die zwischen den Arbeitstypen wählen (z.B. einfach Grafik und Berechnung, oder Eckpunkt-Grafik, Pixel-Grafik und Berechnung). Der MPC kann einige Rückmeldungen geben, um es dem Arbiter zu ermöglichen, korrekte Entscheidungen zu treffen. Sobald der SCG-Arbiter beschließt, die Berechnung zu starten, generiert der MPC CTA-Anfragen an den CWD und weist Platz für diese CTAs auf dem SM zu. Diese Vorarbitrierung für CTAs kann durchgeführt werden, um die Bildung von CTA-Warteschlangen in dem MPC zu verhindern und zu gewährleisten, dass CTAs, sobald sie ankommen, immer ausgewählt und aussetzungsfrei bzw. verzögerungsfrei an den SM gesendet werden. Trotz der Art und Weise, wie Dinge arbitriert werden, können Grafik und Berechnung in dem RechnenlnGrafik-Modus im Wesentlichen um folgende SM-Ressourcen konkurrieren: TRAM kann für Pixelarbeit dediziert sein; VTG und Berechnung können um einen gemeinsamen Pool von ISBE/Shared Memory konkurrieren; und VTG, PIX & Berechnung konkurrieren um lokale Registerdateien (LRF) und Warp-Slots. Im RechnenlnGrafik-Modus kann der MPC auch die auf dem SM laufende Grafik zur Berechnung des CTA-Slots berücksichtigen, bevor er CTA-Anfragen an den CWD sendet, und kann er CTAs basierend auf der SCG-SM-Arbiter-Entscheidung asynchron anfordern. Warps von VTG, Pixel und Berechnung können gleichzeitig auf einem SM ausgeführt werden.
10 zeigt ein Ablaufdiagramm eines Prozesses 1000, der von einem Hardware-Arbiter, wie beispielsweise dem Arbiter 710, ausgeführt werden kann, gemäß einigen beispielhaften Ausführungsbeispielen.
Nach dem Eintreten in den Prozess 1000 überwacht der Arbiter (oder eine andere Hardwareeinheit) bei Operation 1002 einen vorbestimmten Satz von Leistungs- und/oder Nutzungsmetriken für Ressourcen, die dem SM zugeordnet sind.
In Übereinstimmung mit einigen Ausführungsbeispielen sammelt der MPC Statistiken über die Belegung der Grafikressourcen basierend auf der Verwendung von Warp-IDs, Registerdateiplatz, und ISBE-Speicher usw. durch den DPC. Er kann auch Schnittstellenstatistiken sammeln, die sich darauf beziehen, ob Grafikeingaben leer laufen und Grafikausgaben ausgesetzt sind. Diese Schnittstellen- und Belegungsstatistiken brauchen nicht momentan zu sein, sondern können über einen konfigurierbaren Zeitraum integriert werden.
Der MPC kann dazu konfiguriert sein, Statistiken über die Belegung der Rechenressourcen basierend auf der Verwendung von Warp-IDs, Registerdateiplatz und gemeinsam genutztem Speicherplatz durch den DPC zu sammeln. Er kann auch Schnittstellenstatistiken sammeln, die sich darauf beziehen, ob Recheneingaben leer laufen. Auch diese Schnittstellenstatistiken brauchen nicht momentan zu sein, sondern können über einen (ähnlich wie in dem Fall der Grafikstatistiken) konfigurierbaren Zeitraum integriert werden.
Die Entscheidungsfindung auf der Grundlage der überwachten Statistiken ist abhängig von dem aktiven Prioritätsmodus. Daher wird bei Operation 1004 bestimmt, ob sich der Scheduler und der Arbiter in dem grafikhungrigen Modus oder in dem rechenhungrigen Modus befinden.
Der MPC vergleicht diese gesampelten Statistiken mit entsprechenden, von Software festgelegten Richtlinienkontrollen. Gemäß einigen Ausführungsbeispielen kann es einen Software-Schwellenwert geben, der jeder gesampelten Statistik entspricht.
Gemäß einem Ausführungsbeispiel kann der MPC die folgenden Einstellungen und Statistiken für die SCG-SM-Arbiter-Logik verfügbar machen: PRIORITY_TYPE, INPUT_STARVED_ALPHA, INPUT_STARVED_BETA, INPUT _STARVED_PIX, INPUT_STARVED_COMP, PE_ALPHA_OUT_STALL, PE_BETA_OUT_STALL, GPM_PIX_OUT_STALL, COMP_WARP_OCCUPANCY, COMP_SHM_OCCUPANCY, COMP_RF_OCCUPANCY, GFX_WARP_OCCUPANCY, GFX_ISBE_OCCUPANCY, und GFX_RF_OCCUPANCY.
Die SCG-SM Arbiter-Logik kann Folgendes pro DPC berechnen:

isGraphicsGreedy = (PRIORITY_TYPE == GFX);

 isAlphalnputEmpty = (INPUT_STARVING_ALPHA <
           INPUT_STARVING_ALPHA_THRESHOLD); 



 isBetalnputEmpty = (INPUT_STARVING_BETA <
            INPUT_STARVING_BETA_THRESHOLD);
 isPixlnputEmpty = (INPUT_STARVING_PIX < INPUT_STARVING_PIX_THRESHOLD);
 isComputelnputEmpty = (INPUT_STARVING_COMP <
            INPUT_STARVING_COMP_THRESHOLD);
 isAlphaOutputStalled = (PE_ALPHA_OUT_STALL >
            PE_ALPHA_OUT_STALL_THRESHOLD);
 isBetaOutputStalled = (PE_BETA_OUT_STALL >
            PE_BETA_OUT_STALL_THRESHOLD);
 isPixOutputStalled = (GPM_PIX_OUT_STALL >
           GPM_PIX_OUT_STALL_THRESHOLD);
 isGraphicsEmptyOrStalled = (isAlphalnputEmputEmpty || isAlphaOutputStalled) &&
           (isBetalnputEmpty || isBetaOutputStalled) &&&& (isPixlnputEmpty ||
           isPixOutputStalled);
 isGraphicsGreedyEnough = ((GFX_WARP_OCCUPANCY >
           GFX_WARP_OCCUPANCY_THRESHOLD) && (GFX_RF_OCCUPANCY >
           GFX_RF_OCCUPANCY_THRESHOLD) &&
           (GFX_ISBE_OCCUPANCY > GFX_ISBE_OCCUPANCY_THRESHOLD));
 isComputeGreedyEnough = ((COMP_WARP_OCCUPANCY >
           COMP_WARP_OCCUPANCY_THRESHOLD) &&
           (COMP RF_OCCUPANCY > COMP_RF_OCCUPANCY_THRESHOLD) &&
           (COMP_SHM_OCCUPANCY >
           COMP_SHM_OCCUPANCY_THRESHOLD))).

Falls der grafikhungrige Modus vorliegt, dann werden bei Operation 1006 die überwachten Statistiken primär anhand von grafikbezogenen Statistiken ausgewertet, um zu bestimmen, ob eine Lücke in der aktuellen Ressourcenauslastung zu finden ist. Bei Operation 1010 wird unter Verwendung der aktuellen Statistik bestimmt, ob eine Lücke identifiziert wurde oder nicht. Mit den vorstehenden Beispielstatistiken kann beispielsweise eine Auswertung von „!isGraphicsGreedyEnough || isGraphicsEmptyOrStalled“ auf WAHR oder „!isGraphicsGreedyEnough && isGraphicsEmptyOrStalled“ auf WAHR repräsentativ für eine Lücke sein, das in dem grafikhungrigen Modus bestimmt wird.

Falls eine „Lücke“ vorhanden ist, dann können bei Operation 1012 Parameter für die Anforderung von Rechen-Arbeitselementen bestimmt werden. Beispielsweise kann die Bruchteilsrate für Rechen-Arbeitselemente (beispielsweise COMP_MPC_RESOURCE_RESERVE) aus Richtlinienkonfigurationen ermittelt werden.

Basierend darauf, ob die Prioritäten den MPC in den grafikhungrigen oder den rechenhungrigen Modus versetzen, und basierend darauf, wie die Grafik-/Rechen-Statistiken die entsprechenden Schwellenwerte vergleichen, wählt der Arbiter aus, ob als nächstes Grafik oder Berechnung gestartet werden soll.

Beispielsweise kann nach den vorstehenden Berechnungen die SCG-SM-Arbiterlogik beschließen, Grafik oder Berechnung in der folgenden Weise zu starten: Falls (isGraphicsGreedy): Falls (isGraphicsEmptyOrStalled && !isComputelnputEmpty) dann starte die Berechnung; und Falls (!isGraphicsGreedyEnough && !isComputelnputEmpty) dann starte die Berechnung. Andernfalls fährt der Scheduler damit fort, Grafik zu starten.

Grafikarbeit kann sofort starten, da sie typischerweise in den MPC-Eingabewarteschlangen ansteht. Rechenarbeit kann jedoch in einigen Ausführungsbeispielen nicht sofort starten, sie muss zuerst mit dem CWD ausgehandelt werden. Wenn der Arbiter also die Berechnung gewährt, prüft der MPC, ob die in COMP_MPC_RESOURCE_RESERVE (NCTA) angegebene Anzahl von CTAs in den verbleibenden Platz auf diesem TPC passt. Er gibt diesen NCTA-Zählwert dem CWD bekannt und reserviert die Ressourcen für den NCTA (typischerweise sollte der Wert von NCTA für grafikhungrig auf ‚1‘ gesetzt werden, da wir wollen, dass CTAs allmählich in den leeren Raum einfließen, wenn Grafik läuft). Der CWD muss darauf reagieren, indem er entweder bis zu N CTAs startet, oder die verbleibende Reservierung nicht bestätigt, sobald alle CTAs zu anderen TPCS gestartet worden sind (oder die Aufgabe aus irgendeinem Grund von dem CWD ausgeplant wird).

Bei Operation 1014 signalisiert der Arbiter (beispielsweise durch einen Startbefehl) dem Scheduler, ein oder mehrere Rechen-Arbeitselemente zu starten. Das Signal kann eine Anzahl oder eine andere Angabe darüber enthalten, wie viele solcher Rechen-Arbeitselemente gestartet werden sollen.

Falls bei Operation 1004 bestimmt wird, dass der aktive Prioritätsmodus der rechenhungrige Modus ist, dann werden bei Operation 1008 die überwachten Statistiken primär basierend auf rechenbezogenen Statistiken ausgewertet, um zu bestimmen, ob eine „Lücke“ in der aktuellen Ressourcenauslastung gefunden werden kann.

Bei Operation 1016 wird unter Verwendung der aktuellen Statistik bestimmt, ob eine „Lücke“ identifiziert wurde oder nicht.

Falls eine „Lücke“ vorhanden ist, dann können bei Operation 1018 Parameter für die Anforderung von Grafik-Arbeitselementen bestimmt werden. Beispielsweise kann die Bruchteilsrate für Grafik-Arbeitselemente (z.B. GFX_MPC_RESOURCE_RESERVE) aus Richtlinienkonfigurationen ermittelt werden.

Zum Beispiel Falls (isComputeGreedy): Falls (isComputelnputEmpty && !isGraphicsEmptyOrStalled) dann starte Grafik; und Falls (isComputeGreedyEnough && !isGraphicsEmptyOrStalled) dann starte Grafik.

Nach einer „Nein“-Bestimmung bei den Operationen 1010 oder 1016, nach der Operation 1014 oder der Operation 1020 kann der Prozess 1000 enden.

Die 11 und 12 beschreiben Prozesse, die einigen beispielhaften Ausführungsbeispielen zugeordnet sind, in welchen mehrere Scheduling-Profile konfiguriert und verwendet werden können.

11 veranschaulicht ein Ablaufdiagramm eines Prozesses 1100, der von einer Anwendung oder einem anderen Programm an einem Host-Prozessor, wie beispielsweise einer CPU, ausgeführt werden kann, um ein oder mehrere Scheduling-Profile und einen Zeitgeber zum Umschalten zwischen den Scheduling-Profilen zu konfigurieren.

Bei Operation 1102 konfiguriert das Programm ein oder mehrere Scheduler-Profile und zugehörige Richtlinien. Jedes Profil kann verschiedene Kombinationen von Richtlinien und/oder unterschiedliche Werte für bestimmte Schwellenwerte in den Richtlinien enthalten. Die Richtlinien können beispielsweise Schwellenwerte für die Ressourcennutzung für Grafik und für Berechnung, Bruchteilsraten für Grafik und für Berechnung usw. beinhalten.

Bei Operation 1104 kann das Programm einen Zeitgeber konfigurieren, der zum Umschalten zwischen konfigurierten Scheduling-Profilen verwendet werden kann.

12 veranschaulicht ein Ablaufdiagramm eines Prozesses 1200, der in einer GPU oder, in einigen Ausführungsbeispielen, in einem MPC wie beispielsweise dem MPC 702 ausgeführt werden kann, um Scheduler-Profile in einer Sequenz von konfigurierten Scheduler-Profilen umzuschalten.

Software (z.B. eine Anwendung und/oder ein Treiber, die auf dem Host-Prozessor/der CPU ausgeführt werden) kann die Möglichkeit haben, die meisten Arbiter-Schwellen statisch über den gesamten Frame festzulegen, oder kann diese dynamisch synchron mit der Arbeitslast anpassen, indem sie Schwellenänderungsverfahren direkt in die Grafik- oder Rechen-Arbeitsabläufe einfügt.

Zusätzlich stellt der Prozess 1200 die Möglichkeit bereit zum dynamischen Ändern der Arbiter-Einstellung in einer asynchronen Weise unter Verwendung von Mikrocode. Software kann mehrere Sätze von Arbitrierungsparametern einrichten. Jeder Parametersatz wird als ein Arbiter-„Profil“ bezeichnet. Jedes Profil enthält den vollständigen Satz von Grafik-Zuteilungsparametern und Rechen-Zuteilungsparametern, wie vorstehend definiert. Er kann auch die Grafikpriorität enthalten. Die Rechenpriorität kann aus den Datenstrukturen der Rechen-Arbeitselemente bestimmt werden. Jedes Profil hat auch einen Zeitscheibenwert (z.B. in Sysclk-Zyklen) und ein gültiges Bit, das anzeigen kann, ob das jeweilige Profil verwendbar ist. In einigen Ausführungsbeispielen kann der Mikrocode bis zu 8 Profile unterstützen.

Bei Operation 1202 läuft der Profil-Zeitgeber ab. Nach Ablauf des Profil-Zeitgebers kann in einigen Ausführungsbeispielen einem Profilwechselblock (z.B. in der Frontend-Einheit) ein nicht blockierender Interrupt zugeordnet werden, der eine Datenstruktur in einem Speicher abrufen kann, die die Arbiter-Profile enthält.

Bei Operation 1204 wird das nächste Profil ausgewählt. Der Profilwechselblock kann das nächste gültige Profil finden und die Zuteilungsparameter in dem MPC aktualisieren (alle oder nur einige). Bei Operation 1206 werden die Richtlinien in Übereinstimmung mit dem ausgewählten nächsten Profil konfiguriert.

Auf diese Weise kann der Arbiter ohne jeglichen Softwareeingriff spontan neu konfiguriert werden. Ein Anwendungsfall kann das Umschalten zwischen zwei Profilen sein. Das erste kann ein grafikhungriges Profil sein, das für eine bestimmte Anzahl (z.B. X) von Zyklen läuft, und das zweite kann ein rechenhungriges Profil sein, das für eine andere vorgegebene Anzahl (z.B. Y) von Zyklen läuft. Falls X = 4*Y, dann würde dies 20% garantierten Service zum Berechnen bereitstellen, egal wie viel Grafikarbeit vorhanden ist. Natürlich ist dieser Anwendungsfall lediglich ein Beispiel und sind zahlreiche andere Möglichkeiten der Nutzung der Profilwechselfähigkeiten in Ausführungsbeispielen denkbar.

13 veranschaulicht ein Ablaufdiagramm für einen Leerlauferkennungsprozess 1300 gemäß einigen beispielhaften Ausführungsbeispielen. Der Prozess 1300 kann den aktiven Prioritätsmodus des Schedulers umschalten, wenn erfasst wird, dass der aktuelle aktive Prioritätsmodus leer läuft.

Nach dem Eintritt in den Prozess 1300 wird bei Operation 1302 erfasst, dass der aktive hungrige Modus leer laufend geworden ist. Beispielsweise kann der Scheduler in dem grafikhungrigen Modus erfassen, dass die Grafik-Warteschlange (z.B. irgendeine der Alpha-, Beta- oder Pixel-Warteschlangen) leer ist.

Bei Operation 1304 wird optional ein Hysterese-Zeitgeber eingestellt und wird der Prozess 1300 um ein konfigurierbares Zeitintervall verzögert. Nach dem Ablauf des Hysterese-Zeitgebers, falls ein solcher gesetzt war, schreitet der Prozess 1300 zu Operation 1306 fort.

Bei Operation 1306 wird bestimmt, ob der aktive Prioritätsmodus noch immer im Leerlauf ist, und falls ja, wird bei Operation 1308 der aktive Prioritätsmodus geändert. Falls beispielsweise der aktuelle aktive Prioritätsmodus der grafikhungrige Modus ist und dieser als leer laufend bestimmt wird, dann wird der aktive Prioritätsmodus auf rechenhungrig umgeschaltet.

In einigen beispielhaften Ausführungsbeispielen können die Operationen 1302-1306 beinhalten, dass der MPC ein Bit für jeweils die Rechen-Warteschlange und die Grafik-Warteschlange überwacht, wobei jedes Bit eine Hysterese derart aufweist, dass diese im Laufe der Zeit langsam und nicht sofort als leer laufend angezeigt werden. Um aktive Prioritätsmodi zu wechseln, muss außerdem zusätzlich zu der Bestimmung, dass der aktive Prioritätsmodus leer läuft, auch bestimmt werden, dass die aktuelle nicht-hungrige Warteschlange nicht leer ist.

Falls der Wechsel von grafikhungrig zu rechenhungrig durch Leerlauferfassungslogik verursacht wird, dann ist per Definition die Grafik-Pipeline leer. In diesem Fall kann der MPC sofort auf rechenhungrig umschalten, kann aber eine neue CTA-Anfrage mit allen verfügbaren freien Slots an den CWD stellen müssen, so dass er CTA-Starts empfangen kann. Falls der Wechsel von rechenhungrig zu grafikhungrig durch die Leerlauferfassungslogik verursacht wird, dann ist per Definition die Rechen-Pipeline leer. In diesem Fall kann der MPC sofort auf grafikhungrig umschalten und mit der Verarbeitung von Grafikarbeit beginnen.

Andere SCG-SM-Arbiter-Typen

In einigen Ausführungsbeispielen können verschiedene Typen der SCG-SM-Arbiter als alternative Hardware-Arbiter verwendet werden, die jeweils ihre eigenen Vor- und Nachteile haben: ein Ring-Arbiter, der sich in dem MPC befindet, ein SCG-SM-Arbiter auf DPC-Ebene, der sich in dem MPC befindet (vorstehend als der „unsymmetrische“ Arbiter bezeichnet), ein symmetrischer SCG-SM-Arbiter auf GPC-Ebene, der sich in dem GPM befindet, so dass er Kontrolle über mehrere TPCs hat, und ein dynamisch partitionierter SCG-SM-Arbiter in dem GPM, ebenfalls so, dass er Kontrolle über mehrere TPCs hat.

Bei dem Ring-Arbiter beschließt der Arbiter, die Berechnung in einer Ring- bzw. Round-Robin-Manier in Bezug auf Grafiktypen wie beispielsweise Alpha-, Beta- und Pixel-Warteschlangen zu starten. Wenn Berechnung an der Reihe ist, kann der Ring-Arbiter ein (oder eine andere vorbestimmte Anzahl von) CTA(s) starten. Wenn Grafik an der Reihe ist, kann der Ring-Arbiter 1 Stapel bzw. Batch, oder eine Aufgabe oder eine Subkachel starten, je nachdem, was die Grafikarbitrierungslogik zwischen Alpha-, Beta- und Pixelarbeit entscheidet. Wie vorstehend in Bezug auf den unsymmetrischen Arbiter beschrieben wurde, kann der Start von Berechnung und Grafik unterschiedlich sein.

Unter beispielsweise der Annahme, dass ein unendlicher Strom von Rechen- und Grafikarbeiten in den jeweiligen Warteschlangen verfügbar ist, dass der SM bis zu 20 Arbeitseinheiten halten kann, dass jede Grafikanforderung 2 Einheiten erfordert und dass jede Rechenanforderung 5 Einheiten erfordert, kann eine von dem Ring-Arbiter gewährte Arbeitsfolge sein: G2, C5, G2, C5, G2, C5, G2, keine weiteren Berechnungen passen, also G2, G2. Mehr Arbeit würde gewährt werden, wenn Warps fertig werden.

Der symmetrische SCG-SM-Arbiter auf GPC-Ebene innerhalb des GPM versucht, Arbeitslasten von SMs über den GPC hinweg zu berücksichtigen und die Arbeit gleichmäßig zu verteilen. Genauer gesagt befindet sich dieser Arbiter zentral in dem GPM und berücksichtigt viele SMs, um zu entscheiden, wann die nicht-hungrige Arbeit zu beginnen ist.

Dieser Arbiter aggregiert die Rückmeldungen/Statistiken vieler SMs, anstatt sie einzeln zu betrachten, um Lücken in der Ressourcennutzung durch Vergleichen mit von Richtlinien festgelegten Schwellenwerten zu ermitteln. Sobald der Arbiter beschließt, die nicht-hungrige Arbeit auszuführen, wird die Entscheidung an alle SMs in dem GPC übertragen. Diese Art von Arbeitsverteilung kann dazu führen, dass die hungrige Arbeit über die SMs hinweg gleichmäßiger verteilt wird.

Die Richtlinienkontrollen für diesen symmetrischen Arbiter können einige oder alle der vorstehend in Bezug auf den unsymmetrischen Arbiter beschriebenen Richtlinienkontrollen beinhalten. Richtlinienkontrollen für diesen Arbiter können zusätzlich SCG_GRANULARITY_SEL, das dazu programmiert ist, die Granularität der dynamischen Allokierung des Arbiters auszuwählen (beispielsweise bedeutet SCG_GRANULARITY_SEL=SUB_SM, dass der SCG-Arbiter die Sub-SM-Granularität zwischen Berechnung und Grafik dynamisch allokieren/deallokieren wird), BALANCE_TPC_IN_GPC, welches eine boolesche Festlegung ist, wenn „Wahr“ den Arbiter informiert, alle DPCs in dem GPC auszubalancieren („Falsch“ bedeutet, dass DPCs auf sich allein zu stellen sind), GFX_TPC_OCCUPANCY_MIN, welches eine garantierte minimale DPC-Allokierung für Grafik repräsentiert, und COMP_TPC_OCCUPANCY_MIN, das eine garantierte minimale DPC-Allokierung für Berechnung repräsentiert, beinhalten.

Der dynamisch partitionierte SCG-SM-Arbiter innerhalb des GPMs ist ein weiterer Arbiter, der versucht, Arbeit über mehrere SMs hinweg über einen GPC hinweg auszubalancieren. Wie der symmetrische Arbiter-Typ ist auch dieser Arbiter zentral angeordnet und aggregiert die Eingaben über viele SMs hinweg. Dieser Arbiter arbitriert Ressourcen dynamisch bei SM-Granularität, anstatt zwischen Berechnung und Grafik bei Warp-Granularität zu verhandeln. Dieser Arbiter führt nicht zu einer Entleerungs- bzw. Drain-Verriegelung, die bei dem Umschalten von SMs zwischen Grafik und Berechnung zu einer Unterauslastung führt. Stattdessen kann die Entleerung von Arbeit eines Typs gleichzeitig geschehen, wenn der SM Arbeit eines anderen Typs hochfährt. Dieser Arbiter kann eine Möglichkeit bereitstellen, SMs basierend auf den Anforderungen der Arbeitslast (durch dynamische Hardware-Arbitrierung) nahtlos von einem Typ zu einem anderen zu überführen, ohne Zyklen aufzuwenden, die eine explizite Entleerung durchführen.

Die Richtlinienkontrollen für diesen symmetrischen Arbiter können einige oder alle der vorstehend in Bezug auf den unsymmetrischen Arbiter beschriebenen Richtlinienkontrollen beinhalten. Richtlinienkontrollen für diesen Arbiter können zusätzlich SCG_GRANULARITY_SEL, welches dazu programmiert ist, die Granularität der dynamischen Arbiter-Allokierung auszuwählen (beispielsweise bedeutet SCG_GRANULARITY_SEL=TPC, dass der SCG-Arbiter DPCs zwischen Berechnung und Grafik zunächst dynamisch allokieren/deallokieren wird, bevor er eine Sub-SM-Allokierung verwendet); BALANCE_TPC_IN_GPC, welches immer auf „Wahr“ gesetzt ist (beispielsweise Feststellen, falls „Falsch“); TPC_MASK_MIXED, welches die feste Maske von DPCs pro GPC ist, welche sowohl Grafik als auch Berechnung gleichzeitig ausführen werden; MIN_TPC_MASK_GFX, welches die minimale Anzahl von DPCs pro GPC ist, die für Grafik garantiert ist (mit Ausnahme der gemischten DPCs); MIN_TPC_MASK_COMP, welches die minimale Anzahl von DPCs pro GPC ist, die für Berechnung garantiert ist; und CURR_GFX_EN[numTPCperGPC], welches eine Ausgabeanforderung ist, die von dem Arbiter auf pro MPC-Granularität gesendet wird und welches den MPC informiert, wann auf Grafik umzuschalten ist und wann auf Berechnung umzuschalten ist, beinhalten.

Der interne Status des Arbiters kann CURR_GFX_TPC_MASK beinhalten, welches ein Zustand ist, der nachverfolgt, welche DPCs in dem GPC von dem SCG-SM-Arbiter Grafik zugeordnet sind; und CURR_COMP_TPC_MASK, welches ein Zustand ist, der nachverfolgt, welche DPCs in dem GPC von dem SCG-Arbiter Berechnungen zugeordnet sind.

Beispielhafte-Anwendungsfälle

Die vorstehenden Techniken der Zuteilung und der Steuerung von Profil-Zeitscheiben können in Übereinstimmung mit Arbeitslastanforderungen auf verschiedene Weisen gesteuert werden. Es kann daran gedacht werden, die Zuteilung und die Steuerung der Zeitscheiben beispielsweise entweder synchron mit 3D/Rechenarbeit oder asynchron mit 3D/Rechenarbeit zu steuern. Beispielhafte Ausführungsbeispiele verleihen Anwendungen die Fähigkeit zu einer solchen Kontrolle über die Verarbeitung in einer PPU.

In einigen Aspekten können die Scheduling-Profile synchron mit 3D-/Rechenarbeit geändert werden. Beispielsweise kann Software über Grafikarbeitselemente neue Zuteilungsparameter in einer Weise einfügen, die synchron mit der Arbeit in der Pipeline ist. Die Arbeitselemente in der Pipeline können das aktuelle Profil in dem MPC überschreiben. Die Steuerung synchron mit 3D-/Rechenarbeit kann entweder ein Ändern nur von Grafik und Rechenprioritäten involvieren, oder kann alle (oder einen größeren Satz von) Profilparameter involvieren.

In einigen Beispielen, in denen die Zuteilungsprofile synchron mit 3D/Rechenarbeit geändert werden, können alle Zuteilungsparameter in dem MPC statisch festgelegt werden, und können nur die Grafik- und Berechnungsprioritäten variiert werden. Wie bereits erwähnt wurde, kann die Berechnungspriorität an jede Datenstruktur eines Rechen-Arbeitselements angefügt werden, wenn dieses gebildet wird, und kann die Grafikpriorität durch einen Befehl in der 3D-Pipeline geliefert werden. Das Ändern der Priorität wirkt sich darauf aus, ob der Scheduler in dem grafikhungrigen oder dem rechenhungrigen Modus arbeitet. Beispielsweise könnte der Treiber die Grafikpriorität konstant bei 16 halten und Rechen-Arbeitselemente mit niedriger Priorität mit 8 und Rechen-Arbeitselemente mit hoher Priorität mit 24 kennzeichnen. Wenn nur Grafik und Berechnungen mit niedriger Priorität vorhanden sind, wird der Arbiter in dem grafikhungrigen Modus arbeiten, und wenn ein Rechen-Arbeitselement mit hoher Priorität eintrifft, wird er den CWD dazu zwingen, die Verteilung des Rasters mit niedriger Priorität einzustellen auf dasjenige mit hoher Priorität zu wechseln. Der MPC wird die erhöhte Rechenpriorität sehen und den Arbiter in den rechenhungrigen Modus schalten, bis alle hochprioren Rechenarbeiten gestartet sind.

Software kann synchrone Rechenarbeit als höher prioritär markieren als asynchrone Rechenarbeit, welches den CWD dazu veranlasst, die synchrone Rechenarbeit, die typischerweise abgeschlossen werden muss, bevor mehr 3D- oder 2D-Arbeit gestartet werden kann, bevorzugt zu starten, um mehr gleichzeitige Rechen- und Grafiküberlappungen zu ermöglichen.

Es wird angemerkt, dass die Grafik-Pipeline aus drei aufeinanderfolgenden Stufen bestehen kann: Alpha, Beta und Pixel, und dass in einigen Ausführungsbeispielen Änderungen an der Grafikpriorität kurz vor der Pixel-Shader-Phase dekodiert werden. Beispielsweise wird in der folgenden Befehlssequenz: Grafikpriorität = 16; Zeichne A; Grafikpriorität = 32; Zeichne B, die Pixelarbeit für Zeichne A garantiert mit Priorität 16 ausgeführt, und die Pixelarbeit für Zeichne B garantiert mit Priorität 32 ausgeführt. Die Auswirkungen auf die damit verbundene VTG-Arbeit sind weniger deutlich. Die VTG-Arbeit für Zeichne A wird garantiert mit Priorität 16 ausgeführt, aber die VTG-Arbeit für Zeichne B kann mit 16 oder 32 ausgeführt werden, je nachdem, wie lange die Pixelarbeit für A den die Grafikpriorität anhebenden Befehl verzögert. Ein Binden der Grafikpriorität an die Pixel-Shader-Stufe kann jedoch vorteilhaft, weil die meisten Spiele typischerweise Pixel-Shader-dominiert sind.

Die Rechenpriorität wird typischerweise in beispielhaften Ausführungsbeispielen von dem einen Rechen-Arbeitselement geliefert, das von dem CWD gerastert wird. Da die Rechen Pipeline nur eine Stufe, die Rechen-Shader-Stufe, hat, gibt es keine Pipelining-Probleme wie bei Grafik. Der SCG-SM-Arbiter in dem MPC kann die Rechenpriorität von einem aktuell startenden Rechen-Arbeitselement von dem CWD mit der Grafikpriorität in der Pixel-Pipeline vergleichen, d.h. der SCG-SM-Arbiter in dem MPC ist sich der Prioritäten mehrerer Rechen-Arbeitselemente völlig unbewusst.

In einigen Beispielen, in denen die Scheduling-Profile synchron mit 3D/Rechenarbeit geändert werden, kann die Software nicht nur die Priorität, sondern auch die Grafik- und Rechen-Zuteilungsparameter variieren. In beispielhaften Ausführungsbeispielen kann dies synchron mit dem 3D-Arbeitselemente-Stream erfolgen, so dass die Pixelarbeit garantiert beeinträchtigt wird. Software kann die Priorität eines bestimmten Zeichnens erhöhen, um sicherzustellen, dass es in dem grafikhungrigen Modus ausgeführt wird, oder sie könnte die Grafikhungrigkeit eines bestimmten Zeichnens erhöhen (z.B. es extrem hungrig machen).

Demgegenüber sind Starts von Rechen-Arbeitselement-Streams und Rechen-Arbeitselement-Starts in der Rechen-Pipeline nicht notwendigerweise synchronisiert. Änderungen an den Rechen-Zuteilungsparametern dürfen nicht durch vorherige Rechen-Arbeitselemente, die nicht gestartet wurden, blockiert werden, sondern können anstelle dessen sofort an den MPC strömen. Wenn also die Software sicherstellen möchte, dass ein erstes Rechen-Arbeitselement den ersten Parametersatz sieht und das zweite Rechen-Arbeitselement den zweiten Parametersatz sieht, kann es erforderlich sein, die Synchronisation auszulösen.

Eine weitere Möglichkeit für Software, den SCG-SM-Arbiter zu verwenden, besteht in der Verwendung mehrerer Profile und Mikrocodes. Hierbei können die Zuteilungsparameter in einem Kontextpuffer im Speicher gehalten werden. Software kann eine vorgegebene Anzahl von Profilen (z.B. 8) erstellen, und jedes Profil kann ein gültiges Bit und einen Zeitscheibenwert enthalten. Die Software darf keinen der Zuteilungsparameter über Grafikbefehle senden, sondern diese können anstelle dessen durch Schreibvorgänge per Mikrocode in Register bereitgestellt werden. Software kann jedoch die Grafikpriorität über einen Befehl bereitstellen, oder diese können auch aus den Profilen und Mikrocode-Schreibvorgängen kommen. Software kann N gültige Profile in den Speicher programmieren und jedem Profil einen Zeitscheibenwert zuordnen. Ein Profilzeitgeber kann eingestellt werden, wenn jedes Profil aktiviert wird, und wenn der Zeitgeber abläuft, kann die Hardware zu dem nächsten gültigen Profil verschoben und der Zeitgeber neu gestartet werden. Die Zuteilungsparameter für sowohl Berechnung und Grafik können aktualisiert werden, und optional kann auch die Grafikpriorität aktualisiert werden, und zwar durch Schreibvorgänge per Hardware/Mikrocode in den MPC. Diese Schreibvorgänge können an alle MPCs gleichzeitig gesendet werden, da sie alle identisch programmiert sein können. Die Rechenpriorität kann noch immer aus Datenstrukturen von Rechen-Arbeitselementen ermittelt werden. Auf diese Weise kann mit Hilfe von Mikrocode der Scheduler asynchron zwischen verschiedenen Profilen verschoben werden. Dies kann verwendet werden, um ein gewisses Ausmaß an garantiertem Service für Rechnen oder ein gewisses Ausmaß an garantiertem Service für Grafik, oder eine beliebige andere gewünschte Kombination von gleichzeitig Rechnen und Grafik, zu ermöglichen.

In ähnlicher Weise kann, anstatt feste Zeitscheiben zum Rotieren zwischen N Profilen zu verwenden, in einigen Ausführungsbeispielen der Mikrocode selbst das beste Profil auswählen. Hierbei kann der Intervall-Zeitgeber auf irgendeinen festen Wert eingestellt werden (z.B. 100K Zyklen =~ 100µs). Jedes Mal, wenn der Mikrocode den Interrupt sieht, kann er Register um den Chip herum lesen, um zu bestimmen, ob der aktuelle Fall Frame-Puffer-beschränkt, L2-beschränkt, Shader-Mathematik-beschränkt, schwer in Bezug auf Grafik, aber leicht in Bezug auf Rechnen, usw. ist. Der Mikrocode kann diese Informationen verwenden, um zwischen N vorberechneten Profilen auszuwählen, die auf verschiedene Anwendungsfälle abgestimmt sind.

Beispielhafte Ausführungsbeispiele stellen zahlreiche Verbesserungen für GPUs und GPU-basierte Verarbeitung bereit. Die Programmierbarkeitssteuerungen in dem Hardware-Scheduler bestimmter Ausführungsbeispiele ermöglichen eine flexible Reaktion auf unterschiedliche Arbeitsmischungen und andere Anforderungen, die durch neue Spiele und andere Anwendungen entstehen. Diese Programmierbarkeit des Hardware-Schedulers ermöglicht auch verschiedene Mischungen von Rechen- und Grafikarbeit, die es Spieleentwicklern und dergleichen ermöglichen, neue Anwendungen und Programmiertechniken zu erforschen.

In einigen beispielhaften Ausführungsbeispielen kann ein Teil der Rechenarbeitslast, wie beispielsweise bei einigen Frames, die Rechentechniken verwenden, um die Grafikdaten am Ende des Frames nachzuverarbeiten, verarbeitet werden, ohne die Frame-Verarbeitungszeit überhaupt zu verlängern, indem die Grafik mit der höchsten Priorität ausgeführt wird und Berechnungen einfließen, wann immer Ressourcenverfügbarkeit gefunden wird.

Beispielhafte Ausführungsbeispiele können auch Simulationen usw. beschleunigen, die durch PhysX und dergleichen ermöglicht werden, welches eine Bibliothek ist zum Hinzufügen von physikalischen Simulationen (partikelbasierten Flüssigkeiten, lebensechten Explosionen usw.) zu einem Spiel. Wenn es auf der GPU ausgeführt wird, bildet PhysX typischerweise einen zweiten Thread von Rechenarbeit, unabhängig von den Rechentechniken, die in einem typischen Spiel bereits vorhanden sind. Die PhysX-Rechenarbeit kann auch grundlegend zwischen Grafik-Arbeitselementen einfließen, die in dem grafikhungrigen Modus verarbeitet werden.

Bestimmte beispielhafte Ausführungsbeispiele können CUDA-Arbeitslasten in Verbindung mit traditionellen Grafiken effizient ermöglichen, welches in bestimmten Deep Learning-Anwendungen oder anderen Anwendungen, die für CUDA innerhalb von Spielen usw. beschleunigt werden, nützlich sein kann. Der Hardware-Scheduler kann auch Ray-Tracing und dergleichen ermöglichen, indem er erlaubt, dass Berechnungen für Ray-Tracing über typische Grafikarbeit, die in dem System ausgeführt wird, priorisiert werden. Bestimmte beispielhafte Ausführungsbeispiele können aufgrund der Programmierbarkeit des Hardware-Schedulers durch Verringern des Prozentsatzes von Frame-Zeit, der für physikalische Berechnungen dediziert werden muss, auch eine verbesserte Benutzerfreundlichkeit für GPU-basierte physikalische Anwendungen bereitstellen. Bestimmte beispielhafte Ausführungsbeispiele können verbesserte Virtual-Reality-Anwendungen ermöglichen. Beispielsweise werden Berechnungen verwendet, um das endgültige Einzelbild basierend auf der letzten Abtastung der Kopfposition zu modifizieren, und möchte die asynchrone Rechenarbeit mit höchster Priorität ausgeführt werden, so dass sie garantieren kann, dass sie kurz vor dem nächsten Anzeigeereignis abgeschlossen wird.

ZITATE ENTHALTEN IN DER BESCHREIBUNG

Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.

Zitierte Patentliteratur

US 14137818 [0001, 0019, 0021]
US 9626216 [0008]

Claims

Grafikverarbeitungseinheit, umfassend: einen Streaming-Multiprozessor, der parallele Befehlsströme ausführt; und einen Scheduler, der mit dem Streaming-Multiprozessor verbunden ist, wobei der Scheduler den Streaming-Multiprozessor so zuteilt, dass er gleichzeitig zumindest einen Grafik-Warp und zumindest einen Rechen-Warp parallel ausführt.
Grafikverarbeitungseinheit nach Anspruch 1, ferner umfassend den Scheduler, der die Ressourcenauslastung überwacht, die dem Streaming-Multiprozessor während der Zuteilung zugeordnet ist, und als Reaktion auf das Erfassen einer Ressourcenunterauslastung entweder zumindest einen Rechen-Warp für den Streaming-Multiprozessor zuteilt, während er in einem grafikhungrigen Modus arbeitet, der wiederholt Grafik-Warps für den Streaming-Multiprozessor zuteilt, oder zumindest einen Grafik-Warp für den Streaming-Multiprozessor zuteilt, während er in einem rechenhungrigen Modus arbeitet, der wiederholt Rechen-Warps für den Streaming-Multiprozessor zuteilt.
Parallelverarbeitungseinheit, umfassend: eine Vielzahl von Verarbeitungseinheiten, wobei jede Verarbeitungseinheit dazu konfiguriert ist, zu jeweiligen Zeiten in einem grafikhungrigen Modus oder einem rechenhungrigen Modus zu arbeiten und gleichzeitig Grafik-Arbeitselemente aus einer Grafik-Warteschlange und Rechen-Arbeitselemente aus einer Rechen-Warteschlange auszuführen; einen Hardware-Scheduler, der dazu konfiguriert ist, kontinuierlich Grafik-Arbeitselemente aus der Grafik-Warteschlange auszuwählen, um sie auf einer bestimmten Verarbeitungseinheit der Vielzahl von Verarbeitungseinheiten auszuführen, wenn die bestimmte Verarbeitungseinheit dazu konfiguriert ist, in dem grafikhungrigen Modus zu arbeiten, und um kontinuierlich Rechen-Arbeitselemente aus der Rechen-Warteschlange auszuwählen, um sie auf der bestimmten Verarbeitungseinheit auszuführen, wenn die jeweilige Verarbeitungseinheit dazu konfiguriert ist, in dem rechenhungrigen Modus zu arbeiten; und einen Hardware-Arbiter, der dazu konfiguriert ist, als Reaktion auf ein Ergebnis eines Vergleichs zumindest einer überwachten Leistungs- oder Auslastungsmetrik mit einem benutzerdefinierten Schwellenwert die bestimmte Verarbeitungseinheit selektiv dazu zu veranlassen, ein oder mehrere Rechen-Arbeitselemente aus der Rechen-Warteschlange auszuführen, wenn die bestimmte Verarbeitungseinheit dazu konfiguriert ist, in dem grafikhungrigen Modus zu arbeiten, und die bestimmte Verarbeitungseinheit zu veranlassen, ein oder mehrere Grafik- Arbeitselemente aus der Grafik-Warteschlange auszuführen, wenn die bestimmte Verarbeitungseinheit dazu konfiguriert ist, in dem rechenhungrigen Modus zu arbeiten.
Parallelverarbeitungseinheit nach Anspruch 3, wobei jede der Vielzahl von Verarbeitungseinheiten ein SIMD (Single Instruction Multiple Data)-Prozessor oder ein SIMT (Single Instruction Multiple Thread)-Prozessor ist.
Parallelverarbeitungseinheit nach Anspruch 3 oder 4, wobei der Hardware-Scheduler ferner dazu konfiguriert ist, den grafikhungrigen Modus oder den Rechenhungrigen Modus basierend auf zumindest softwarekonfigurierten Prioritätswerten, die den Grafik-Arbeitselemente und Rechen-Arbeitselemente zugeordnet sind, auszuwählen.
Parallelverarbeitungseinheit nach Anspruch 5, wobei der Hardware-Arbiter ferner dazu konfiguriert ist, basierend auf einer softwarekonfigurierten Zuteilungsrichtlinie das Ausführen von entweder Rechen-Arbeitselementen oder Grafik-Arbeitselementen auszuwählen.
Parallelverarbeitungseinheit nach Anspruch 6, wobei der Hardware-Arbiter ferner dazu konfiguriert ist, das Ausführen entweder von Rechen-Arbeitselementen oder von Grafik-Arbeitselementen weiter basierend auf Belegungsmetriken auszuwählen, die der Belegung von Verarbeitungs- und Speicherressourcen durch Grafik-Arbeitselemente und Rechen-Arbeitselemente entsprechen.
Parallelverarbeitungseinheit nach Anspruch 7, wobei der Hardware-Arbiter ferner dazu konfiguriert ist, das Veranlassen des Ausführens entweder von Rechen-Arbeitselementen oder von Grafik-Arbeitselementen basierend auf Metriken in der bestimmten Verarbeitungseinheit auszuwählen.
Parallelverarbeitungseinheit nach Anspruch 7 oder 8, wobei der Hardware-Arbiter ferner dazu konfiguriert ist, das Veranlassen des Ablaufs entweder von Rechen-Arbeitselementen oder von Grafik-Arbeitselementen basierend auf Metriken in der bestimmten Verarbeitungseinheit und anderen Verarbeitungseinheiten auszuwählen.
Parallelverarbeitungseinheit nach einem der Ansprüche 7 bis 9, wobei der Hardware-Arbiter ferner dazu konfiguriert ist, das Ausführen entweder von Rechen-Arbeitselementen oder von Grafik-Arbeitselementen weiter basierend auf Ausgabeaussetzungsmetriken, die Grafik-Arbeitselementen zugeordnet sind, die von der Verarbeitungseinheit ausgegeben werden, und auf Eingabeleerzeitmetriken, die der Eingabe von Grafik-Arbeitselementen und Rechen-Arbeitselementen in die Verarbeitungseinheit zugeordnet sind, auszuwählen.
Parallelverarbeitungseinheit nach Anspruch 10, wobei der Hardware-Arbiter ferner dazu konfiguriert ist, das Veranlassen des Ausführens entweder von Rechen-Arbeitselementen oder Grafik-Arbeitselementen basierend weiter auf zeitgemittelten Werten der Belegungsmetriken auszuwählen, wobei die Ausgabeaussetzungsmetriken den Grafik-Arbeitselementen zugeordnet sind und die Eingabeleerzeitmetriken der Eingabe von Grafik-Arbeitselementen und Rechen-Arbeitselementen zugeordnet sind.
Parallelverarbeitungseinheit nach Anspruch 11, wobei die Belegungsmetriken eine oder mehrere Belegungsmetriken für Registerdateien, Belegungsmetriken für Warp-Ressourcen, Belegungsmetriken für gemeinsam genutzten Speicher und Belegungsmetriken für ISBE-Speicher umfassen, wobei die den Grafik-Arbeitselementen zugeordneten Eingabeleerzeitmetriken zumindest eine aus einer eckpunktassoziierten Warteschlange und einer pixelassoziierten Warteschlange umfassen, wobei die Eingabeleerzeitmetriken, die Rechen-Arbeitselementen zugeordnet sind, Leerzeitmetriken umfassen, die der Berechnungswarteschlange zugeordnet sind, und wobei die Ausgabeaussetzungsmetriken, die Grafik-Arbeitselementen zugeordnet sind, Ausgabeaussetzungsmetriken für zumindest eine von einer eckpunktassoziierten Warteschlange und einer pixelassoziierten Warteschlange umfassen.
Parallelverarbeitungseinheit nach einem der Ansprüche 10 bis 12, wobei die Ausgabeaussetzungsmetriken Effekte eines Gegendrucks von einer oder mehreren Einheiten mit fester Funktion beinhalten, die Grafik-Arbeitselemente verarbeiten.
Parallelverarbeitungseinheit nach einem der Ansprüche 5 bis 13, wobei der Hardware-Scheduler oder der Hardware-Arbiter ferner dazu konfiguriert ist, basierend auf einem jeweiligen Bruchteilparameter, der in einer softwarespezifizierten Richtlinie angegeben ist, eine Anzahl von Arbeitselementen zu bestimmen, die aus der Grafik-Warteschlange oder der Rechen-Warteschlange auszuwählen sind.
Parallelverarbeitungseinheit nach einem der Ansprüche 3 bis 14, wobei der Hardware-Scheduler ferner dazu konfiguriert ist, als Reaktion auf das Bestimmen, eine Gruppe von Grafik-Arbeitselementen für die bestimmte Verarbeitungseinheit zu starten, ein oder mehrere Grafik-Arbeitselemente, die bereits dem Hardware-Scheduler zugeordnet sind, zu starten; und als Reaktion auf das Bestimmen, eine Gruppe von Rechen-Arbeitselemente zu starten: Ressourcen, die der jeweiligen Verarbeitungseinheit zugeordnet sind, für eine bestimmte Anzahl von Rechen-Arbeitselementen zu reservieren; und die bestimmte Anzahl von Rechen-Arbeitselementen aus der Rechen-Warteschlange anzufordern.
Parallelverarbeitungseinheit nach Anspruch 15, wobei der Hardware-Scheduler ferner dazu konfiguriert ist, als Reaktion auf das Bestimmen, die Gruppe von Rechen-Arbeitselementen zu starten: Rechen-Arbeitselemente, die als Reaktion auf die Anforderung an der bestimmten Verarbeitungseinheit empfangen wurden, zu starten, oder Rechen-Arbeitselemente als Reaktion auf das Empfangen einer negativen Bestätigung auf die Anforderung nicht zu starten.
Parallelverarbeitungseinheit nach Anspruch 16, wobei der Hardware-Scheduler ferner dazu konfiguriert ist, Prioritätsinformationen mit dem Starten der Grafik-Arbeitselemente oder dem Starten der Rechen-Arbeitselemente an die bestimmte Verarbeitungseinheit zu übergeben.
Parallelverarbeitungseinheit nach einem der Ansprüche 3 bis 17, wobei der Hardware-Scheduler ferner dazu konfiguriert ist, eine aktive Zuteilungsrichtlinie automatisch zu ändern, und wobei das Ändern ein Ändern des benutzerdefinierten Schwellenwerts beinhaltet.
Parallelverarbeitungseinheit nach Anspruch 18, wobei sich das automatische Ändern an die Arbeitsbelastung anpasst.
Parallelverarbeitungseinheit nach Anspruch 18, wobei das automatische Ändern ein asynchrones Umschalten zwischen mehreren vorkonfigurierten Zuteilungsprofilen zum Ändern der aktiven Zuteilungsrichtlinie umfasst, wobei jedes vorkonfigurierte Zuteilungsprofil einen jeweils anderen Satz von Zuteilungsrichtlinien beinhaltet.
Parallelverarbeitungseinheit nach einem der Ansprüche 3 bis 20, wobei der Hardware-Scheduler und/oder der Hardware-Arbiter Metriken von einer Vielzahl von Verarbeitungseinheiten empfangen.
Verfahren zum gleichzeitigen Ausführen von Grafik-Arbeitselementen und Rechen-Arbeitselementen auf einem parallelen Prozessor mit einer Vielzahl von Verarbeitungseinheiten, umfassend: Empfangen der Grafik-Arbeitselemente von einer Grafik-Pipeline und der Rechen-Arbeitselemente von einer Rechen-Pipeline; und Zuteilen einer ersten Gruppe der grafischen Arbeitselemente und einer zweiten Gruppe der Rechen-Arbeitselemente so, dass diese gleichzeitig auf einer ausgewählten SIMD (Single Instruction Multiple Data)- oder SIMT (Single Instruction Multiple Thread)-Verarbeitungseinheit der Vielzahl von Verarbeitungseinheiten ausgeführt werden.
Verfahren nach Anspruch 22, wobei die Zuteilung das Auswählen der ersten Gruppe und der zweiten Gruppe basierend zumindest auf softwarekonfigurierten Prioritätswerten umfasst, die jeweiligen Gruppen der Grafik-Arbeitselemente und Rechen-Arbeitselemente zugeordnet sind.
Verfahren nach Anspruch 23, wobei die Zuteilung das Auswählen der ersten Gruppe und der zweiten Gruppe basierend auf einer softwarekonfigurierten Zuteilungsrichtlinie umfasst.
Verfahren nach Anspruch 23 oder 24, wobei die Zuteilung ferner das Auswählen der ersten Gruppe und der zweiten Gruppe basierend auf Belegungsmetriken umfasst, die der Belegung von Verarbeitungs- und Speicherressourcen durch Grafik-Arbeitselemente und Rechen-Arbeitselemente entsprechen.
Verfahren nach Anspruch 25, wobei die Zuteilung ferner das Auswählen der ersten Gruppe und der zweiten Gruppe auf der Grundlage von Ausgabeaussetzungsmetriken, die Grafik-Arbeitselementen zugeordnet sind, die von der Verarbeitungseinheit ausgegeben werden, und von Eingabeleerzeitmetriken, die der Eingabe von Grafik-Arbeitselementen und von Rechen-Arbeitselementen in die Verarbeitungseinheit zugeordnet sind, umfasst.
Verfahren nach Anspruch 26, wobei das Auswählen ferner auf zeitgemittelten Werten der Belegungsmetriken basiert, wobei die Ausgabeaussetzungsmetriken den Grafik-Arbeitselementen zugeordnet sind und die Eingabeleerzeitmetriken der Eingabe von Grafik-Arbeitselementen und Rechen-Arbeitselementen zugeordnet sind.
System, umfassend: eine CPU, die dazu konfiguriert ist, eine Anwendung auszuführen; einen Speicher, der dazu konfiguriert ist, eine Grafik-Warteschlange, in die Grafik-Arbeitselemente von der Anwendung eingereiht werden, und eine Rechen-Warteschlange, in die Rechen-Arbeitselemente von der Anwendung eingereiht werden, aufzuweisen; und eine Grafikverarbeitungseinheit (GPU), umfassend: eine Vielzahl von Verarbeitungseinheiten, wobei jede Verarbeitungseinheit dazu konfiguriert ist, zu jeweiligen Zeiten in einem grafikhungrigen Modus oder einem rechenhungrigen Modus zu arbeiten und Grafik-Arbeitselemente aus der Grafik-Warteschlange und Rechen-Arbeitselemente aus der Rechen-Warteschlange gleichzeitig auszuführen; einen Hardware-Scheduler, der dazu konfiguriert ist, kontinuierlich Grafik-Arbeitselemente aus der Grafik-Warteschlange auszuwählen, um sie auf einer bestimmten Verarbeitungseinheit der Vielzahl von Verarbeitungseinheiten auszuführen, wenn die bestimmte Verarbeitungseinheit dazu konfiguriert ist, im grafikhungrigen Modus zu arbeiten, und kontinuierlich Rechen-Arbeitselemente aus der Rechen-Warteschlange auszuwählen, um sie auf der bestimmten Verarbeitungseinheit auszuführen, wenn die bestimmte Verarbeitungseinheit dazu konfiguriert ist, im rechenhungrigen Modus zu arbeiten; und einen Hardware-Arbiter, der dazu konfiguriert ist, als Reaktion auf ein Ergebnis eines Vergleichs zumindest einer überwachten Leistungs- oder Auslastungsmetrik mit einem benutzerdefinierten Schwellenwert die bestimmte Verarbeitungseinheit selektiv dazu zu veranlassen, ein oder mehrere Rechen-Arbeitselemente aus der Rechen-Warteschlange auszuführen, wenn die bestimmte Verarbeitungseinheit konfiguriert ist, in dem grafikhungrigen Modus zu arbeiten, und die bestimmte Verarbeitungseinheit zu veranlassen, ein oder mehrere Grafik-Arbeitselemente aus der Grafik-Warteschlange auszuführen, wenn die bestimmte Verarbeitungseinheit dazu konfiguriert ist, in dem rechenhungrigen Modus zu arbeiten.