DE102012222391A1

DE102012222391A1 - Mehrkanal-Zeitscheibengruppen

Info

Publication number: DE102012222391A1
Application number: DE102012222391A
Authority: DE
Inventors: Samuel H. Duncan; Lacky V. Shah; Sean J. Treichler; Daniel Elliot Wexler; Jerome F. Duluk jun.; Philip Browning Johnson; Jonathon Stuart Ramsay EVANS
Original assignee: Nvidia Corp
Current assignee: Nvidia Corp
Priority date: 2011-12-09
Filing date: 2012-12-06
Publication date: 2013-06-13
Anticipated expiration: 2032-12-07
Also published as: DE102012222391B4; CN103197918B; US9442759B2; TW201337767A; US20130152093A1; TWI501156B; CN103197918A

Abstract

Eine Zeitscheibengruppe (TSG) ist eine Gruppierung von unterschiedlichen Arbeitsströmen (hierin als „Kanälen” bezeichnet), die die gleiche Kontextinformation gemeinsam haben. Der Satz von Kanälen, die zu einer TSG gehören, wird in einer vorbestimmten Reihenfolge verarbeitet. Wenn aber ein Kanal während der Verarbeitung zum Stillstand kommt, kann der nächste Kanal mit unabhängiger Arbeit geschaltet werden, um die Parallelverarbeitungseinheit voll auszulasten. Es ist wesentlich, dass eine Kontextschaltvorgang nicht benötigt wird, wenn die Verarbeitung einer bestimmten Kanal in der TSG gestoppt und die Verarbeitung einer nächsten Kanal in der TSG begonnen wird, weil jeder Kanal in der TSG die gleiche Kontextinformation teilt. Folglich können mehrere unabhängige Arbeitsströme gelichzeitig innerhalb eines einzigen Kontexts ausgeführt werden und dabei die Ausnutzung von parallelen Verarbeitungseinheiten erhöhen.

Description

HINTERGRUND DER ERFINDUNG
Gebiet der Erfindung
Die vorliegende Erfindung bezieht sich generell auf die Ausführung von Tasks, und spezifischer auf Mehrkanal-Zeitscheibengruppen („multi-channel time slice groups”).
Beschreibung des verwandten Standes der Technik
Eine Grafikverarbeitungseinheit (GPU) weist ein großes Array von Streaming-Mehrfachprozessoren („streaming multiprocessors”) (SMs) auf, die zum Ausführen von Arbeit konfiguriert sind, welche von verschiedenen Applikationen innerhalb des Systems erzeugt wird. Arbeit, die von Applikationen zur Ausführung innerhalb der GPU erzeugt wird, mag zu mehreren Klassen gehören, einschließlich Grafikarbeit, Rechenarbeit, Raytracing-Arbeit usw. Jede dieser Klassen von Arbeit weist unterschiedliche Eigenschaften auf.
Rechenarbeit wird typischerweise so organisiert, dass verschiedene Gruppierungen von Tasks innerhalb der Rechenarbeit gleichzeitig ausgeführt werden können. Die Hosteinheit („host unit”) in der GPU startet aber die Rechentasks sequentiell. Demzufolge, falls ein bestimmter Task darauf wartet, dass ein vorhergehender Task beendet wird, und der vorhergehende Task nur einen Anteil der SMs benutzt, dann sind die ungenutzten SMs inaktiv bzw. im Leerlauf („idle”). Ein solches Szenario ist sehr unerwünscht, da die Verarbeitungsleistung („processing power”) der SMs verschwendet wird, während die SMs inaktiv verbleiben, und die Verarbeitung von Rechenarbeit, die effizienter verarbeitet werden kann, dauert länger.
Wie es auf dem technischen Gebiet bekannt ist, besteht eine Lösung zu dem obigen Problem darin, jede Gruppe von Tasks in einem unterschiedlichen Kanal zu inkludieren, so dass, wenn ein Kanal zum Stillstand kommt oder gebracht wird („is stalled”), Tasks, die von einem anderen Kanal spezifiziert worden sind, mit der Ausführung beginnen können. Bei einer solchen Implementierung müssen die SMs aber leerlaufen und eine Kontextwechseloperation wird jedes Mal benötigt, wenn ein Kanal gewechselt wird. Wie es den Fachleuten gut bekannt ist, ist unnötiges Leerlaufen einer parallelen Maschine ineffizient und Kontextwechseloperationen sind sowohl mit intensiver Zeit- als auch Verarbeitungsaufwand verbunden. Demzufolge führt das Erfordernis nach einer Kontextwechseloperation jedes Mal, wenn ein Kanal gewechselt wird, zu einer unnötigen Leistungsverringerung des Systems.
Folglich ist das, was auf dem technischen Gebiet benötigt wird, ein System und ein Verfahren, die es Erlauben, dass mehrere Arbeitsströme gleichzeitig innerhalb einer einzigen Kontext ablaufen.
ZUSAMMENFASSUNG DER ERFINDUNG
Eine Ausführungsform der Erfindung ist ein Verfahren zum Scheduling bzw. zeitlichen Festlegen der Ausführung von Tasks innerhalb einer Verarbeitungseinheit. Das Verfahren weist ein Bestimmen, dass ein Satz von Kanälen, die Tasks spezifizieren, welche innerhalb der Verarbeitungseinheit ausgeführt werden sollen, mit einer Zeitscheibengruppe assoziiert ist, wobei jeder Kanal einen unterschiedlichen Satz von Tasks spezifiziert und Kontextinformation entsprechend jedem Kanal, der mit der Zeitscheibengruppe assoziiert ist, die gleiche ist, ein Auswählen eines ersten Kanals, der in dem Satz von Kanälen enthalten ist, zur nächsten Ausführung innerhalb der Verarbeitungseinheit, ein Bestimmen, ob Kontextinformation, die dem ersten Kanal entspricht, innerhalb der Verarbeitungseinheit gesetzt werden muss, wobei, wenn ein vorhergehender Kanal, der von der Verarbeitungseinheit ausgeführt wurde, in dem Satz von Kanälen enthalten ist, Kontextinformation entsprechend dem ersten Kanal nicht gesetzt werden muss innerhalb der Verarbeitungseinheit, und wenn der vorhergehende Kanal, der von der Verarbeitungseinheit ausgeführt wurde, nicht in dem Satz von Kanälen enthalten ist, Kontextinformation entsprechend dem ersten Kanal gesetzt werden muss innerhalb der Verarbeitungseinheit, und ein Scheduling eines ersten Satzes von Tasks, der von dem ersten Kanal spezifiziert ist, zur Ausführung innerhalb der Verarbeitungseinheit, auf.
Ein Vorteil der vorliegenden Erfindung ist, dass unterschiedliche Kanäle von Arbeit, welche die gleiche Kontextinformation gemeinsam haben bzw. teilen („share”), von den GPCs 208 ausgeführt werden können, ohne den Bedarf an intervenierende Kontextwechseloperationen. Demzufolge, falls ein Kanal zum Stillstand kommt, kann ein anderer Kanal zur Ausführung gescheduled werden, ohne die mit dem Kontextwechsel verbundenen Kosten zu verursachen, und dabei den gesamten Durchsatz und die gesamte Leistung des Systems erhöhen.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
So dass die Art und Weise, in der die oben angeführten Merkmale der vorliegenden Erfindung im Detail verstanden werden kann, mag eine detailliertere Beschreibung der oben kurz zusammengefassten Erfindung durch Bezugnahme auf Ausführungsformen gehabt haben, von denen einige in der angehängten Zeichnungen dargestellt sind. Es muss aber bemerkt werden, dass die angehängten Zeichnungen nur typische Ausführungsformen der Erfindung illustrieren und somit nicht als den Umfang der Erfindung beschränkend angesehen werden dürfen, da die Erfindung andere gleich effektive Ausführungsformen zulassen mag.
1 ist ein Blockdiagramm, das ein Computersystem zeigt, das zum Implementieren einer oder mehrerer Aspekte der vorliegenden Erfindung konfiguriert ist.
2 ist ein Blockdiagramm eines Parallelverarbeitungssubsystems für das Computersystem von 1, gemäß einer Ausführungsform der vorliegenden Erfindung.
3A ist ein Blockdiagramm des Frontends von 2, gemäß einer Ausführungsform der vorliegenden Erfindung.
3B ist ein Blockdiagramm eines Allgemeinverarbeitungsclusters („general processing cluster”) innerhalb einer der Parallelverarbeitungseinheiten von 2, gemäß einer Ausführungsform der vorliegenden Erfindung.
3C ist ein Blockdiagramm von einem Teil des Streaming-Mehrfachprozessors von 3B, gemäß einer Ausführungsform der vorliegenden Erfindung.
4 ist eine Illustration einer Ausführungsliste („run list”), eines Kanalplans („channel map”) und einer pro-Kanal-Kontextinformation basierend darauf, welche Tasks zur Ausführung innerhalb der GPCs gescheduled sind, gemäß einer Ausführungsform der vorliegenden Erfindung.
5 ist eine detailliertere Darstellung der Hostschnittstelle von 2, welche Hostschnittstelle dazu konfiguriert ist, Arbeit zur Ausführung innerhalb des Verarbeitungsclusterarrays auszuwählen, gemäß einer Ausführungsform der vorliegenden Erfindung.
Die 6A und 6B stellen ein Flussdiagramm von Verfahrensschritten zum Identifizieren eines nächsten Kanals zur Ausführung bereit, gemäß einer Ausführungsform der vorliegenden Erfindung.
DETAILLIERTE BESCHREIBUNG
In der folgenden Beschreibung werden zahlreiche spezifische Details dargestellt, um ein eingehenderes Verständnis der vorliegenden Erfindung bereitzustellen. Es wird aber für einen Fachmann offenkundig sein, dass die vorliegende Erfindung auch ohne ein oder mehrere von diesen spezifischen Details ausgeübt werden kann. In anderen Beispielen sind gut bekannte Merkmale nicht beschrieben worden, um zu vermeiden, dass die vorliegende Erfindung verborgen wird.
Systemübersicht
1 ist ein Blockdiagramm, das ein Computersystem 100 zeigt, das zum Implementieren eines oder mehrerer Aspekte der vorliegenden Erfindung konfiguriert ist. Das Computersystem 100 weist eine zentrale Verarbeitungseinheit („central processing unit”) (CPU) 102 und einen Systemspeicher 104 auf, die über einen Verbindungspfad („interconnection path”), der eine Speicherbrücke 105 aufweisen mag, miteinander in Verbindung stehen bzw. kommunizieren. Die Speicherbrücke 105, die zum Beispiel ein Northbridge-Chip sein mag, ist über einen Bus oder einen anderen Kommunikationspfad 106 (zum Beispiel einen HyperTransport-Links) mit einer I/O-(Input/Output)-Brücke 107 verbunden. Die I/O-Brücke 107, welche zum Beispiel ein Southbridge-Chip sein mag, erhält User-Input von einer oder mehreren User-Input-Vorrichtungen 108 (zum Beispiel Tastatur, Maus) und leitet den Input über den Pfad 106 und die Speicherbrücke 105 an die CPU 102 weiter. Ein Parallelverarbeitungssubsystem 112 ist über einen Bus oder einen anderen Kommunikationspfad 113 (zum Beispiel einen Peripheral Component Interconnect (PCI) Express, einen beschleunigten Grafikport („Accelerated Graphics Port”), oder einen HyperTransport-Link) an die Speicherbrücke 105 gekoppelt; in einer Ausführungsform ist das Parallelverarbeitungssubsystem 112 ein Grafiksubsystem, das Pixel zu einer Displayvorrichtung 110 (zum Beispiel einem konventionellen auf Kathodenstrahlröhre oder Flüssigkristalldisplay basierten Monitor) liefert. Eine Systemdisk 114 ist auch mit der I/O-Brücke 107 verbunden. Ein Switch 116 stellt Verbindungen zwischen der I/O-Brücke 107 und anderen Bauteilen, wie zum Beispiel einem Netzwerkadapter 118 und verschiedenen Erweiterungskarten („add-in cards”) 120 und 121, bereit. Andere (nicht explizit dargestellte) Bauteile, einschließlich „universal serial bus” (USB) oder anderer Portanschlüsse („port connections”), „compact disc”-(CD)-Laufwerke, „digial video disc”-(DVD)-Laufwerke, Filmaufzeichnungsvorrichtungen und ähnliches, mögen auch mit der I/O-Brücke 107 verbunden sein. Verbindungspfade, die die verschiedenen Bauteile in 1 miteinander verbinden, mögen unter Verwendung von jeglichen geeigneten Protokollen, wie zum Beispiel PCI-Express, AGP („Accelerated Graphics Port”), HyperTransport oder jedem anderen Bus oder Punkt-zu-Punkt-Kommunikationsprotokoll(en) („Point-to-Point Communication Protocol(s)”) implementiert sein, und Verbindungen zwischen verschiedenen Vorrichtungen mögen verschiedene Protokolle benutzen, wie es aus dem Stand der Technik bekannt ist.
Das Parallelverarbeitungssubsystem 112 weist in einer Ausführungsform Schaltkreise auf, die für Grafik- und Videoverarbeitung optimiert sind, einschließlich zum Beispiel Videoausgabeschaltkreise, und stellt eine Grafikverarbeitungseinheit (GPU) dar. In einer anderen Ausführungsform weist das Parallelverarbeitungssubsystem 112 Schaltkreise auf, die für Universalverarbeitung („general purpose processing”) optimiert sind, während die unterliegende rechnerische Architektur aufrechterhalten wird (wie es hierin detaillierter beschrieben wird). In noch einer anderen Ausführungsform mag das Parallelverarbeitungssubsystem 112 mit einem oder mehreren anderen Systemelementen integriert sein, wie zum Beispiel der Speicherbrücke 105, der CPU 102 und der I/O-Brücke 107, um ein System-auf-Chip („system on chip”) (SoC) zu bilden.
Es wird verstanden werden, dass das hierin gezeigte System illustrativ ist und dass Variationen und Modifikationen möglich sind. Die Verbindungstopologie, einschließlich der Anzahl und Anordnung von Brücken, der Anzahl von CPUs 102 und der Anzahl von Parallelverarbeitungssubsystemen 112, mag wie gewünscht variiert werden. In einigen Ausführungsformen ist der Systemspeicher 104 zum Beispiel direkt mit der CPU 102 verbunden, statt durch eine Brücke, und andere Vorrichtungen kommunizieren über die Speicherbrücke 105 und die CPU 102 mit dem Systemspeicher 104. In anderen alternativen Topologien ist das Parallelverarbeitungssubsystem 112 mit der I/O-Brücke 107 oder direkt mit der CPU 102 verbunden, statt mit der Speicherbrücke 105. In noch anderen Ausführungsformen mögen die I/O-Brücke 107 und Speicherbrücke 105 in einem einzigen Chip integriert sein. Große Ausführungsformen mögen zwei oder mehr CPUs 102 und zwei oder mehr Parallelverarbeitungssysteme 112 aufweisen. Die jeweiligen hierin gezeigten Bauteile sind optional; zum Beispiel mag jede Anzahl von Erweiterungskarten oder Peripherievorrichtungen unterstützt werden. In einigen Ausführungsformen ist der Switch 116 entfernt und der Netzwerkadapter 118 und die Erweiterungskarten 120, 121 sind direkt mit der I/O-Brücke 107 verbunden.
2 zeigt ein Parallelverarbeitungssubsystem 112 gemäß einer Ausführungsform der vorliegenden Erfindung. Das Parallelverarbeitungssubsystem 112 weist, wie gezeigt, eine oder mehr Parallelverarbeitungseinheiten („Parallel Processing Units”) (PPUs) 202 auf, wobei jede von denen an einen lokalen Parallelverarbeitungs-(PP)-Speicher 204 gekoppelt ist. Im Allgemeinen weist ein Parallelverarbeitungssubsystem eine Anzahl U von PPUs auf, wobei U ≥ 1. (Hierin werden mehrere Instanzen ähnlicher Objekte mit Bezugszeichen, die das Objekt identifizieren, und Ziffern in Klammern, die, wenn nötig, die Instanz identifizieren, gekennzeichnet.) Die PPUs 202 und die Parallelverarbeitungsspeicher 204 mögen unter Verwendung einer oder mehrerer integrierten Schaltungsvorrichtungen implementiert werden, wie zum Beispiel programmierbare Prozessoren, anwendungsspezifische integrierte Schaltungen („Application Specific Integrated Circuits”) (ASICs) oder Speichervorrichtungen, oder in jeder anderen technisch realisierbaren Art und Weise.
In einigen Ausführungsformen sind, wieder mit Bezug sowohl auf 1 als auch auf 2, einige oder alle der PPUs 202 in dem Parallelverarbeitungssubsystem 112 Grafikprozessoren mit Rendering-Pipelines, die dazu konfiguriert werden können, verschiedene Operationen in Bezug auf das Erzeugen von Pixeldaten aus Grafikdaten, die von der CPU 102 und/oder dem Systemspeicher 104 über die Speicherbrücke 105 und den Bus 113 bereitgestellt werden, auszuführen, mit lokalem Parallelverarbeitungsspeicher 204 (der als Grafikspeicher einschließlich, zum Beispiel, eines konventionellen Framepuffers benutzt werden kann) zu interagieren, um Pixeldaten zu speichern und zu aktualisieren, Pixeldaten an die Displayvorrichtung 110 zu übermitteln, und ähnliches. In einigen Ausführungsformen mag das Parallelverarbeitungssubsystem 112 eine oder mehrere PPUs 202 aufweisen, die als Grafikprozessoren arbeiten, und eine oder mehrere PPUs 202, die für Universalberechnungen („general-purpose computations”) benutzt werden. Die PPUs mögen identisch oder unterschiedlich sein, und jede PPU mag ihre eigene(n) dedizierte(n) Parallelverarbeitungsspeichervorrichtung(en) oder keine dedizierte(n) Parallelverarbeitungsspeichervorrichtung(en) aufweisen. Eine oder mehrere der PPUs 202 mag bzw. mögen Daten an eine Displayvorrichtung 110 ausgeben oder jede PPU 202 mag Daten an eine oder mehrere Displayvorrichtungen 110 ausgeben.
Jetzt wird sowohl auf 2 als auch auf 1 Rückbezug genommen. Im Betrieb ist die CPU 102 der Masterprozessor des Computersystems 100, welcher den Betrieb anderer Systembauteile steuert und koordiniert. Die CPU 102 erteilt insbesondere Befehle, die den Betrieb der PPUs 202 steuern. In einigen Ausführungsformen schreibt die CPU 102 einen Befehlsstrom für jede PPU 202 in eine (weder in 1 noch in 2 explizit gezeigte) Datenstruktur, die sich im Systemspeicher 104, Parallelverarbeitungsspeicher 204 oder in einer anderen Speicherstelle befinden mag, die für sowohl die CPU 102 als auch die PPU 202 zugreifbar ist. Ein Zeiger auf jede Datenstruktur wird in einen Stoßpuffer („push puffer”) geschrieben, um Verarbeitung des Befehlsstroms in der Datenstruktur zu initiieren. Die PPU 202 liest Befehlsströme aus einem oder mehreren Stoßpuffern aus und führt dann Befehle asynchron relativ zu dem Betrieb der CPU 102 aus. Ausführungsprioritäten mögen für jeden Stoßpuffer festgelegt werden, um das Scheduling der verschiedenen Stoßpuffer zu steuern.
Jede PPU 202 weist eine I/O-(Input/Output)-Einheit 205 auf, die mit dem restlichen Computersystem 100 über Kommunikationspfad 113 kommuniziert, der mit der Speicherbrücke 105 (oder in einer alternativen Ausführungsform direkt mit der CPU 102) in Verbindung steht. Die Verbindung der PPU 202 an das restliche Computersystem 100 mag auch variiert werden. In einigen Ausführungsformen ist das Parallelverarbeitungssubsystem 112 als eine Erweiterungskarte implementiert, die in einen Erweiterungsslot („expansion slot”) des Computersystems 100 eingebracht werden kann. In anderen Ausführungsformen kann eine PPU 202 auf einem einzigen Chip mit einer Busbrücke, wie zum Beispiel Speicherbrücke 105 oder I/O-Brücke 107, integriert sein. In noch anderen Ausführungsformen mögen einige oder alle Elemente der PPU 202 auf einem einzigen Chip mit der CPU 102 integriert sein.
In einer Ausführungsform ist der Kommunikationspfad 113 ein PCI-Express-Anschluss („PCI-Express Link”), in welchem jeder PPU 202 dedizierte Spuren zugewiesen sind, wie es auf dem technischen Gebiet bekannt ist. Andere Kommunikationspfade mögen auch benutzt werden. Eine I/O-Einheit 205 erzeugt Pakete (oder andere Signale) für Transmission auf dem Kommunikationspfad 113 und empfängt auch alle ankommenden Pakete (oder anderen Signale) von dem Kommunikationspfad 113, wobei die ankommenden Pakete zu zweckmäßigen Bauteilen der PPU 202 geleitet werden. Befehle, die sich auf Bearbeitungstasks beziehen, mögen zum Beispiel zu einer Hostschnittstelle („host interface”) 206 geleitet werden, während Befehle, die sich auf Speichervorgänge (zum Beispiel Auslesen aus oder Schreiben auf den Parallelverarbeitungsspeicher 204) beziehen, zu einer Speicher-Kreuzschieneneinheit 210 geleitet werden mögen. Die Hostschnittstelle 206 liest jeden Stoßpuffer aus und gibt den Befehlsstrom, der in dem Stoßpuffer gespeichert ist, zu einem Frontend 212 aus.
Jede PPU 202 implementiert vorteilhafterweise eine in hohem Maße parallele Verarbeitungsarchitektur. Die PPU 202(0) weist, wie im Detail gezeigt, ein Verarbeitungscluster-Array („processing cluster array”) 230 auf, das eine Anzahl C von Allgemeinverarbeitungsclustern („general processing clusters”) (GPCs) 208 aufweist, wobei C ≥ 1. Jeder GPC 208 ist in der Lage, eine große Anzahl (zum Beispiel hunderte oder tausende) von Threads gleichzeitig auszuführen, wobei jeder Thread eine Instanz eines Programms ist. In verschiedenen Applikationen mögen unterschiedlichen GPCs 208 zur Verarbeitung unterschiedlicher Arten von Programmen oder zum Ausführen unterschiedlicher Arten von Berechnungen allokiert werden. Das Allokieren von GPCs 208 mag in Abhängigkeit von der Auslastung variieren, die für jede Art von Programm oder Berechnung entsteht.
Die GPCs 208 empfangen auszuführende Verarbeitungstasks von einer Arbeitsverteilungseinheit innerhalb einer Task/Arbeit-Einheit („task/work unit”) 207. Die Arbeitsverteilungseinheit empfängt Zeiger auf Rechenverarbeitungstasks, die als Taskmetadaten („task metadata”) (TMD) kodiert und im Speicher gespeichert sind. Die Zeiger auf TMDs sind in den Befehlsstrom beinhaltet, der als ein Stoßpuffer gespeichert und mittels der Frontend-Einheit 212 von der Host-Schnittstelle 206 empfangen wird. Verarbeitungstasks, die als TMDs kodiert werden mögen, beinhalten Indices von zu verarbeitenden Daten sowie Zustandsparameter und Befehle, die definieren wie die Daten zu verarbeiten sind (zum Beispiel welches Programm auszuführen ist). Die Task/Arbeit-Einheit 207 empfängt Tasks von dem Frontend 212 und stellt sicher, dass die GPCs 208 zu einem gültigen Zustand konfiguriert sind, bevor die von jedem einzelnen der TMDs spezifizierte Verarbeitung eingeleitet wird. Eine Priorität mag für jede TMD, die zum Scheduling der Ausführung der Verarbeitungstasks benutzt wird, spezifiziert sein.
Die Speicherschnittstelle 214 weist eine Anzahl D von Partitionseinheiten 215 auf, die jeweils direkt an einen Teil des Parallelverarbeitungsspeichers 204 gekoppelt sind, wobei D ≥ 1. Die Anzahl der Partitionseinheiten 215 ist, wie gezeigt, generell gleich der Anzahl von dynamischen Direktzugriffspeicher („dynamic random access memory”) (DRAM) 220. In anderen Ausführungsformen mag die Anzahl der Partitionseinheiten 215 nicht gleich der Anzahl der Speichervorrichtungen sein. Fachleute werden verstehen, dass DRAM 220 durch andere geeignete Speichervorrichtungen ersetzt werden mag und von einer generell konventionellen Bauform sein kann. Eine detaillierte Beschreibung wird deswegen weggelassen. Render-Ziele, wie zum Beispiel Puffer- oder Strukturpläne, mögen quer über die DRAMs 220 gespeichert werden, was den Partitionseinheiten 215 ermöglicht, Teile von jedem Render-Ziel parallel zu schreiben, um die vorhandene Bandbreite des Parallelverarbeitungsspeichers 204 effizient zu nutzen.
Jeder der GPCs 208 mag Daten verarbeiten, die in irgendeinen der DRAMs 220 innerhalb des Parallelverarbeitungsspeichers 204 zu schreiben sind. Die Kreuzschieneneinheit 210 ist dazu konfiguriert, den Output jedes GPC 208 an den Input einer jeden Partitionseinheit 215 oder an einen anderen GPC 208 für weitere Verarbeitung zu leiten. Die GPCs 208 kommunizieren mit der Speicherschnittstelle 214 durch die Kreuzschieneneinheit 210, um aus bzw. in verschiedenen externen Speichervorrichtungen auszulesen bzw. zu schreiben. In einer Ausführungsform hat die Kreuzschieneneinheit 210 sowohl eine Verbindung zu der Speicherschnittstelle 214, um mit der I/O-Einheit 205 zu kommunizieren, als auch eine Verbindung zu dem lokalen Parallelverarbeitungsspeicher 204, wodurch es den Verarbeitungskernen innerhalb der verschiedenen GPCs 208 ermöglicht werden, mit dem Systemspeicher 104 oder einem anderen Speicher, der kein lokaler Teil der PPU 202 ist, zu kommunizieren. In der in 2 gezeigten Ausführungsform ist die Kreuzschieneneinheit 210 direkt mit der I/O-Einheit 205 verbunden. Die Kreuzschieneneinheit 210 mag virtuelle Kanäle benutzen, um Datenverkehrsströme zwischen den GPCs 208 und den Partitionseinheiten 215 zu separieren.
Wie erwähnt können die GPCs 208 zum Ausführen von Verarbeitungstasks, die sich auf eine umfangreiche Vielfalt von Applikationen beziehen, programmiert werden, einschließlich, aber nicht begrenzt auf, linearer und nicht-linearer Datentransformationen, Filtern von Video- und/oder Audiodaten, Modellierungsvorgänge (zum Beispiel der Anwendung von physikalischen Gesetzen zum Bestimmen von Position, Geschwindigkeit und anderen Eigenschaften von Objekten), Bild-Rendering-Vorgängen (zum Beispiel Mosaikshader-, Scheitelshader-, Geometrieshader- und/oder Pixel-Shaderprogramme („tesselation shader, vertex shader, geometry shader, and/or pixel shader programs”)), usw. Die PPUs 202 mögen Daten von dem Systemspeicher 104 und/oder den lokalen Parallelverarbeitungsspeichern 204 in einen internen (auf-dem-Chip) Speicher hinein übertragen, die Daten verarbeiten und die Ergebnisdaten zurück in den Systemspeicher 104 und/oder die lokalen Parallelverarbeitungsspeicher 204 schreiben, wo auf solche Daten von anderen Systembauteilen, einschließlich CPU 102 oder anderer Parallelverarbeitungssubsysteme 112, zugegriffen werden kann.
Eine PPU 202 mag mit jeder Menge lokaler Parallelverarbeitungsspeicher 204, einschließlich keiner lokalen Speicher, ausgestattet sein, und mag lokalen Speicher und Systemspeicher in jeder beliebigen Kombination benutzen. Eine PPU 202 kann zum Beispiel ein Grafikprozessor in einer Ausführungsform mit „unified memory architecture” (UMA) sein. In solchen Ausführungsformen würde wenig oder kein dedizierter Grafik-(Parallelverarbeitungs-)Speicher bereitgestellt werden, und die PPU 202 würde ausschließlich oder fast ausschließlich den Systemspeicher benutzen. In UMA-Ausführungsformen mag eine PPU 202 in einem Brückenchip oder Prozessorchip integriert sein oder als ein diskreter Chip mit einem Hochgeschwindigkeitsanschluss (beispielsweise PCI-Express), der die PPU 202 über einen Brückenchip oder ein anderes Kommunikationsmittel mit dem Systemspeicher verbindet, bereitgestellt werden.
Wie oben erwähnt, kann eine beliebige Anzahl von PPUs 202 in einem Parallelverarbeitungssubsystem 112 enthalten sein. Mehrere PPUs 202 können zum Beispiel auf einer einzigen Erweiterungskarte bereitgestellt werden oder mehrere Erweiterungskarten können mit dem Kommunikationspfad 113 verbunden werden oder eine oder mehrere der PPUs 202 können in einem Brückenchip integriert werden. Die PPUs 202 in einem Mehrfach-PPU-System mögen gleich oder unterschiedlich voneinander sein. Unterschiedliche PPUs 202 mögen zum Beispiel eine jeweils unterschiedliche Anzahl von Prozessorkernen, unterschiedliche Mengen von lokalem Parallelverarbeitungsspeicher usw. aufweisen. Wenn mehrere PPUs 202 vorhanden sind, mögen diese PPUs parallel betrieben werden, um Daten mit einem größeren Durchsatz, als es mit einer einzigen PPU 202 möglich ist, zu verarbeiten. Systeme, die eine oder mehrere PPUs 202 aufweisen, mögen in einer Vielfalt von Konfigurationen und Formfaktoren implementiert werden, einschließlich Desktop-, Laptop- oder handgeführter Rechner, Server, Arbeitsstationen („workstations”), Spielkonsolen, eingebetteter Systeme und ähnliches.
Scheduling von mehreren gleichzeitigen Tasks („Multiple Concurrent Task Scheduling”)
Mehrere Verarbeitungstasks mögen gleichzeitig auf den GPCs 208 ausgeführt werden und ein Verarbeitungstask mag während der Ausführung ein oder mehrere „Kind”-Verarbeitungstasks („„child” processing tasks”) erzeugen. Die Task/Arbeit-Einheit 207 empfängt die Tasks und legt dynamisch die Ausführung der Bearbeitungstasks und der Kind-Verarbeitungstasks mittels der GPCs 208 zeitlich fest.
3A ist ein Blockdiagramm von der Task/Arbeit-Einheit 207 von der 2, gemäß einer Ausführungsform der vorliegenden Erfindung. Die Task/Arbeit-Einheit 207 weist eine Taskmanagementeinheit 300 und die Arbeitsverteilungseinheit 340 auf. Die Taskmanagementeinheit 300 organisiert die Tasks, die zu schedulen sind, basierend auf Ausführungsprioritätsstufen. Für jede Prioritätsstufe speichert die Taskmanagementeinheit 300 eine verbundene Liste von Zeigern auf die TMDs 322, die den Tasks in der Schedulertabelle 321 entsprechen. Die TMDs 322 mögen in dem PP-Speicher 204 oder in dem Systemspeicher 104 gespeichert sein. Die Rate, mit welcher die Taskmanagementeinheit 300 Tasks akzeptiert und die Tasks in der Schedulertabelle 321 speichert, ist von der Rate entkoppelt, mit der die Taskmanagementeinheit 300 die Ausführung von Tasks zeitlich festlegt („schedules”), was der Taskmanagementeinheit 300 ermöglicht Tasks basierend auf Prioritätsinformation oder unter Verwendung anderer Techniken zu schedulen.
Die Arbeitsverteilungseinheit 340 weist eine Tasktabelle 345 mit Slots auf, die jeweils von den TMD 322 für einen Task, der ausgeführt wird, belegt sein mögen. Die Taskmanagementeinheit 300 mag die Tasks zur Ausführung schedulen, wenn es einen freien Slot in der Tasktabelle 345 gibt. Wenn es keinen freien Slot gibt, mag ein Task mit höherer Priorität, der keinen Slot belegt, einen Task mit niedrigerer Priorität vertreiben, der einen Slot belegt. Wenn ein Task vertrieben wird, wird der Task gestoppt, und falls die Ausführung des Tasks nicht abgeschlossen ist, wird der Task zu einer verbundenen Liste in der Schedulertabelle 321 hinzugefügt. Wenn ein Kind-Verarbeitungstask erzeugt wird, wird der Kind-Task zu einer verbundenen Liste in der Schedulertabelle 321 hinzugefügt. Ein Task wird von einem Slot entfernt, wenn der Task vertrieben wird.
Übersicht der Taskverarbeitung
3B ist ein Blockdiagramm von einem GPC 208 innerhalb einer der PPUs 202 von 2, gemäß einer Ausführungsform der Erfindung. Jeder GPC 208 mag zum parallelen Ausführen einer großen Anzahl von Threads konfiguriert sein, wobei der Begriff „Thread” auf eine Instanz eines bestimmten Programmes hinweist, das auf einem bestimmten Satz von Inputdaten ausgeführt wird. In einigen Ausführungsformen werden einzelne-Instruktions-, mehrfache-Daten-(SIMD)-Instruktionsausgabetechniken („single-instruction, multiple-data (SIMD) instructions issue techniques”) verwendet, um parallele Ausführung von einer großen Anzahl von Threads zu unterstützen, ohne mehrfache unabhängige Instruktionseinheiten bereitzustellen. In anderen Ausführungsformen werden einzelne-Instruktions-, mehrfache-Threads-(SIMT)-Techniken („single-instruction, multiple-thread (SIMT) techniques”) verwendet, um parallele Ausführung von einer großen Anzahl von generell synchronisierten Threads zu unterstützen, unter Verwendung einen gemeinsamen Instruktionseinheit, die zur Ausgabe von Instruktionen an einen Satz von Verarbeitungsmaschinen („processing engines”) innerhalb jedes der GPCs 208 konfiguriert ist. Anders als bei einer SIMD-Ausführungsbetriebsart („SIMD execution regime”), bei der alle Verarbeitungsmaschinen typischerweise identische Instruktionen ausführen, erlaubt die SIMT-Ausführung, dass verschiedene Threads divergierende Ausführungspfade durch ein gegebenes Threadprogramm zügiger folgen. Fachleute werden verstehen, dass eine SIMD-Verarbeitungsbetriebsart eine funktionelle Untermenge von einer SIMT-Verarbeitungsbetriebsart ist.
Die Operation des GPC 208 wird vorteilhafterweise über einen Pipelinemanager 305 gesteuert, der Verarbeitungstasks an Streaming-Mehrfachprozessoren (SMs) 310 verteilt. Der Pipelinemanager 305 mag auch dazu konfiguriert sein, eine Arbeitsverteilungskreuzschiene 330 durch Angeben von Destinationen für verarbeitete Datenausgabe von den SMs 310 zu steuern.
In einer Ausführungsform weist jeder GPC 208 eine Anzahl M von SMs 310 auf, wobei M ≥ 1 und jeder SM 310 zum Verarbeiten einer oder mehrerer Threadgruppen konfiguriert ist. Jeder SM 310 weist vorteilhafterweise auch einen identischen Satz von funktionellen Ausführungseinheiten (zum Beispiel Ausführungseinheiten und Load-Store-Einheiten („load-store units”), die als Ausführungseinheiten 302 und LSUs 303 in 3C gezeigt sind) auf, die gepipelined sein mögen, erlaubend eine neue Instruktion ausgegeben zu werden, bevor eine vorhergehende Instruktion fertig ist, wie es auf dem technischen Gebiet bekannt ist. Jede Kombination funktioneller Ausführungseinheiten mag bereitgestellt werden. In einer Ausführungsform unterstützen die funktionellen Einheiten eine Vielzahl von Operationen, einschließlich Ganzzahl- und Fließkommaarithmetik (zum Beispiel Addition und Multiplikation), Vergleichsoperationen, boolescher Operationen (UND, ODER, EXKLUSIV-ODER), Bit-Verschiebung und Berechnung von diversen algebraischen Funktionen (zum Beispiel planarer Interpolation, trigonometrischer, exponentieller und logarithmischer Funktionen usw.); und die gleiche Funktionseinheitshardware kann zum Ausführen verschiedener Operationen eingesetzt („leveraged”) werden.
Die Reihe von Instruktionen, die an einen bestimmten GPC 208 übermittelt wird, bildet einen Thread, wie hierin früher definiert wurde, und die Sammlung von einer bestimmten Anzahl von Threads, die gleichzeitig überall in („across”) den Parallelverarbeitungsmaschinen (nicht gezeigt) innerhalb eines SM 310 ausgeführt werden, wird als ein „Warp” oder als eine „Threadgruppe” („thread group”) bezeichnet. Wie hierin benutzt, bezeichnet eine „Threadgruppe” eine Gruppe von Threads, die gleichzeitig das gleiche Programm auf unterschiedlichen Inputdaten ausführen, wobei ein Thread der Gruppe einer unterschiedlichen Verarbeitungsmaschine innerhalb eines SM 310 zugeordnet ist. Eine Threadgruppe mag weniger Threads als die Anzahl der Verarbeitungsmaschinen innerhalb des SM 310 enthalten, in welchem Falle einige Verarbeitungsmaschinen während Zyklen, in denen diese Threadgruppe verarbeitet wird, inaktiv sein werden. Eine Threadgruppe mag auch mehr Threads als die Anzahl der Verarbeitungsmaschinen innerhalb des SM 310 enthalten, in welchem Falle die Verarbeitung in aufeinanderfolgenden Zyklen stattfinden wird. Da jeder SM 310 bis zu G Threadgruppen gleichzeitig unterstützen kann, folgt es, dass bis zu G·M Threadgruppen zu jedem gegebenen Zeitpunkt im GPC 208 ausgeführt werden können.
Eine Mehrzahl von verwandten bzw. in Beziehung stehenden Threadgruppen mag des Weiteren zum gleichen Zeitpunkt innerhalb eines SM 310 aktiv sein (in verschiedenen Phasen der Ausführung). Diese Sammlung von Threadgruppen wird hierin bezeichnet als ein „Array zusammenarbeitender Threads” („cooperative thread array”) (CTA) oder „Threadarray” bezeichnet. Die Größe eines bestimmten CTA ist gleich m·k, wobei k die Anzahl der gleichzeitig ausführenden Threads in einer Threadgruppe ist, die typischerweise ein ganzzahliges Vielfaches der Anzahl von Parallelverarbeitungsmaschinen innerhalb des SM 310 ist, und m die Anzahl von gleichzeitig aktiven Threadgruppen innerhalb des SM 310 ist. Die Größe eines CTA wird generell von dem Programmierer und der Menge der für das CTA zur Verfügung stehenden Hardware-Ressourcen, wie zum Beispiel Speicher oder Register, bestimmt.
Jeder SM 310 enthält einen Stufe-Eins-(L1)-Cache („level one cache”) (gezeigt in 3C) oder nutzt Platz in einem entsprechenden L1-Cache außerhalb des SM 310, der zum Ausführen von Lade- und Speicheroperationen („load and store operations”) benutzt wird. Jeder SM 310 hat auch Zugriff auf Stufe-Zwei-(L2)-Caches, die von allen GPCs 208 gemeinsam genutzt werden und zum Übertragen von Daten zwischen Threads benutzt werden mögen. Schließlich haben die SMs 310 auch Zugriff auf externen („off-chip”) „globalen” Speicher, welcher zum Beispiel Parallelverarbeitungsspeicher 204 und/oder Systemspeicher 104 aufweisen kann. Es ist zu verstehen, dass jeder beliebige Speicher, der extern zur PPU 202 ist, als globaler Speicher benutzt werden mag. Ein Stufe-Eins-Komma-Fünf-(L1,5)-Cache 335 mag zusätzlich in dem GPC 208 inkludiert sein, welcher dazu konfiguriert ist, Daten, die vom SM 310 angefordert und über Speicherschnittstelle 214 aus dem Speicher abgerufen werden, einschließlich Instruktionen, einheitlichen („uniform”) Daten und konstanten Daten, zu erhalten und halten und die angeforderten Daten an den SM 310 zu liefern. Ausführungsformen, die mehrere SMs 310 im GPC 208 haben, teilen mit Vorteil gemeinsamen Instruktionen und Daten, die im L1,5-Cache 335 gespeichert sind.
Jeder GPC 208 mag eine Speichermanagementeinheit (MMU) 328 aufweisen, die zum Abbilden virtueller Adressen auf absolute („physical”) Adressen konfiguriert ist. In anderen Ausführungsformen mag bzw. mögen die MMU(s) 328 sich innerhalb der Speicherschnittstelle 214 befinden. Die MMU 328 enthält einen Satz von Seitentabelleneinträgen („page table entries”) (PTEs), die zum Abbilden einer virtuellen Adresse auf eine absolute Adresse einer Fliese und wahlweise eines Cachezeilenindex verwendet werden. Die MMU 328 mag Adressübersetzungs-assoziative-Pufferspeicher (TLB) („address translation lookaside buffers”) oder Adressübersetzungs-parallele-Cachespeicher („address translation lookaside caches”) aufweisen, die sich innerhalb des Mehrfachprozessors SM 310 oder des L1-Caches oder der GPC 208 befinden mögen. Die physikalische Adresse wird verarbeitet, um Oberflächendaten-Zugriffslokalität („surface data access locality”) zu distribuieren, um effiziente Auftragsinterleaving („request interleaving”) zwischen Partitionseinheiten zu erlauben. Der Cachezeilenindex mag benutzt werden, um zu bestimmen, ob eine Anforderung für eine Cachezeile einen Treffer („hit”) oder einen Fehlschuss („miss”) ist.
In Grafik- und Rechenapplikationen mag ein GPC 208 derart konfiguriert sein, dass jeder SM 310 an eine Textureinheit 315 gekoppelt ist, um Bemusterungsoperationen („texture mapping operations”) durchzuführen, zum Beispiel Bestimmen von Texturabtastwertpositionen („texture sample positions”), Lesen von Texturdaten und Filtern der Texturdaten. Texturdaten werden aus einem internen (nicht gezeigten) Textur-L1-Cache oder, in einigen Ausführungsformen, aus dem L1-Cache innerhalb des SM 310 gelesen und werden bei Bedarf aus einem L2-Cache, dem Parallelverarbeitungsspeicher 204 oder dem Systemspeicher 104 abgerufen. Jeder SM 310 gibt verarbeitete Tasks an die Arbeitsverteilungskreuzschiene 330 aus, um die verarbeiteten Tasks für einen anderen GPC 208 zur weiteren Verarbeitung bereitzustellen oder um die verarbeiteten Tasks in einem L2-Cache, Parallelverarbeitungsspeicher 204 oder Systemspeicher 104 über die Kreuzschieneneinheit 210 zu speichern. Eine Vor-ROP (Vorrasteroperationen („pre-raster operations”)) 325 ist dazu konfiguriert, Daten von dem SM 310 zu erhalten, Daten an ROP-Einheiten innerhalb Partitionseinheiten 215 zu leiten und Optimierungen für Farbmischung durchzuführen, Pixelfarbdaten zu organisieren und Adressübersetzungen durchzuführen.
Es wird verstanden, dass die hierin beschriebene Kernarchitektur illustrativ ist und dass Variationen und Modifikationen möglich sind. Es mag jede beliebige Anzahl von Verarbeitungseinheiten, zum Beispiel SMs 310 oder Textureinheiten 315, Vor-ROPs 325 in einem GPC 208 enthalten sein. Des Weiteren mag eine PPU 202, obwohl nur ein GPC 208 gezeigt ist, jede beliebige Anzahl von GPCs 208 enthalten, die vorteilhafterweise einander funktionell ähnlich sind, so dass der Verlauf der Ausführung nicht davon abhängt, welcher GPC 208 einen gegebenen Verarbeitungstask erhält. Des Weiteren operiert jeder GPC 208 vorteilhafterweise unabhängig von anderen GPCs 208 unter Verwendung separater und individueller Verarbeitungseinheiten, L1-Caches und so weiter.
Durchschnittliche Fachleute werden verstehen, dass die in den 1, 2, 3A und 3B dargestellten Architektur den Umfang der vorliegenden Erfindung in keiner Weise begrenzt und dass die hierin beschriebenen Techniken in jeder sachgemäß konfigurierten Verarbeitungseinheit implementiert werden mögen, einschließlich, ohne Begrenzung, einer oder mehrerer CPUs, einer oder mehrerer Mehrkern-CPUs, einer oder mehrerer PPUs 202, eines oder mehrerer GPCs 208, einer oder mehrerer Grafik- oder Sonderzweck-(„special purpose”)-Verarbeitungseinheiten oder ähnliches, ohne den Umfang der Vorliegenden Erfindung zu verlassen.
In Ausführungsformen der vorliegenden Erfindung ist es wünschenswert, PPU 202 oder einem anderen bzw. andere Prozessor(en) eines Datenverarbeitungssystems zu benutzen, um allgemeine Berechnungen unter Verwendung von Threadarrays durchzuführen. Jedem Thread in dem Threadarray ist einen eindeutigen Thread-Identifikator („Thread-ID”) zugeordnet, der während der Ausführung des Threads für den Thread zugänglich ist. Der Thread-ID, der als ein eindimensionaler oder mehrdimensionaler numerischer Wert definiert werden kann, steuert verschiedene Aspekte von dem Verlauf der Ausführung des Threads. Ein Thread-ID mag zum Beispiel verwendet werden, um zu bestimmen, welchen Teil des Eingangsdatensatzes ein Thread bearbeiten soll, und/oder zu bestimmen, welchen Teil eines Ausgangsdatensatzes ein Thread produzieren oder schreiben soll.
Eine Folge bzw. Sequenz von pro-Thread-Instruktionen („per-thread instructions”) mag zumindest eine Instruktion enthalten, die ein kooperatives Verhalten zwischen dem maßgeblichen („representative”) Thread und einem oder mehreren anderen Threads des Threadarrays. Die Sequenz von pro-Thread-Instruktionen mag zum Beispiel eine Instruktion, die Ausführung von Operationen für den maßgeblichen Thread bei einem bestimmten Punkt in der Sequenz bis zu einem solchen Zeitpunkt zu suspendieren, bei dem ein oder mehr von den anderen Threads diesen bestimmten Punkt erreichen, eine Instruktion für den maßgeblichen Thread, Daten in einem gemeinsam genutzten Speicher, auf den ein oder mehr von den anderen Threads Zugriff haben, zu speichern, eine Instruktion für den maßgeblichen Thread, Daten, die in einem gemeinsam genutzten Speicher, auf den ein oder mehr von den anderen Threads Zugriff basierend auf deren Thread-IDs haben, atomar zu lesen und aktualisieren, oder ähnliche Instruktionen enthalten. Das CTA-Programm kann auch eine Instruktion enthalten, eine Adresse in dem gemeinsamen genutzten Speicher zu berechnen, aus der Daten zu lesen sind, wobei die Adresse eine Funktion von dem Thread-ID ist. Durch Definieren zweckmäßiger Funktionen und durch Bereitstellen von Synchronisierungstechniken können Daten von einem Thread eines CTA in einer gegebenen Stelle in dem gemeinsam genutzten Speicher geschrieben und von einem anderen Thread des gleichen CTA aus dieser Stelle gelesen werden auf eine vorhersehbare Art und Weise. Folglich kann jedes gewünschtes Muster von Datenteilung zwischen Threads unterstützt werden und jeder Thread in einem CTA kann Daten mit jedem anderen Thread in dem gleichen CTA teilen. Der Umfang, wenn überhaupt, der Datenteilung zwischen Threads eines CTA wird von dem CTA-Programm bestimmt; es ist somit zu verstehen, dass die Threads eines CTA in einer gegebenen Applikation, der CTAs verwendet, tatsächlich, in Abhängigkeit von dem CTA-Programm, Daten miteinander teilen oder nicht miteinander teilen mögen, und die Begriffe „CTA” und „Threadarray” werden hierin synonym verwendet.
3C ist ein Blockdiagramm des SM 310 von 3B, gemäß einer Ausführungsform der vorliegenden Erfindung. Der SM 310 weist einen Instruktions-L1-Cache 370 auf, der zum Erhalten Instruktionen und Konstanten vom Speicher durch L1,5-Cache 335 konfiguriert ist. Eine Warp-Scheduler- und Instruktionseinheit („warp scheduler and instruction unit”) 312 erhält Instruktionen und Konstanten von dem Instruktions-L1-Cache 370 und steuert den lokalen Registerspeicher („local register file”) 304 und funktionelle Einheiten des SM 310 gemäß den Instruktionen und Konstanten. Die funktionellen Einheiten des SM 310 weisen N Ausführungs- oder Verarbeitungseinheiten 302 und P Load-Store-Einheiten (LSU) 303 auf.
Der SM 310 stellt internen („on-chip”) Datenspeicher mit verschiedenen Zugreifbarkeitsstufen bereit. Spezielle (nicht gezeigte) Register sind für die LSU 303 lesbar aber nicht schreibbar und werden zum Speichern von Informationen verwendet, die die „Position” eines jeden Threads definieren. In einer Ausführungsform weisen die speziellen Register ein Register pro Thread (oder pro Ausführungseinheit 302 in dem SM 310) auf, das einen Thread-ID speichert; Jedes Thread-ID-Register ist nur für eine entsprechende Ausführungseinheit der Ausführungseinheiten 302 zugreifbar. Die speziellen Register mögen auch zusätzliche Register enthalten, die für alle Threads lesbar sind, die in dem gleichen Netz („grid”) oder in der gleichen Warteschlange (oder für alle LSUs 303) sind und einen CTA-Identifikator, die CTA-Dimensionen, die Dimensionen eines Netzes, zu dem das CTA gehört, (oder die Warteschlangenposition im Falle einer Warteschlange) und einen Identifikator des Netzes oder der Warteschlange, zu dem bzw. der das CTA gehört, speichern. CTAs, die zu einem Netz gehören, haben impliziten x, y, z-Parameter, die die Position des jeweiligen CTA innerhalb des Netzes bezeichnen. Die speziellen Register werden während der Initialisierung als Reaktion auf Befehle, die von dem Gerätetreiber 103 über das Frontend 212 erhalten werden, geschrieben und verändern sich während der Ausführung eines Verarbeitungstasks nicht. Das Frontend 212 legt der Ausführung jeden Verarbeitungstask als entweder ein Netz oder eine Warteschlange zeitlich fest („schedules”). Jedes CTA ist mit einem bestimmten Netz oder Warteschlange verknüpft zur gleichzeitigen Ausführung eines oder mehrerer Tasks. Ein einzelner GPC 208 mag des Weiteren eine Mehrzahl von Tasks gleichzeitig ausführen.
Ein (nicht gezeigter) Parameterspeicher speichert Ausführungsparameter („runtime parameter”) (Konstante), die von jedem anderen Thread innerhalb des gleichen CTA (oder jeder beliebigen LSU 303) gelesen aber nicht geschrieben werden kann. In einer Ausführungsform stellt der Gerätetreiber 103 Parameter für den Parameterspeicher bereit bevor er den SM 310 anweist, die Ausführung eines Tasks, der diese Parameter nutzt, zu beginnen. Jeder Thread innerhalb eines jeden CTA (oder jede Ausführungseinheit 302 innerhalb des SM 310) kann auf einen globalen Speicher durch eine Speicherschnittstelle 214 zugreifen. Bereiche des globalen Speichers mögen in dem L1-Cache 320 gespeichert werden.
Der lokale Registerspeicher 304 wird von jedem Thread als Arbeitsplatz („scratch space”) verwendet; jedes Register ist für die exklusive Nutzung eines Threads allokiert und Daten in jeder beliebigen der lokalen Registerspeicher 304 ist nur für den Thread zugreifbar, zu dem das Register allokiert ist. Der lokale Registerspeicher 304 kann als ein Registerspeicher implementiert werden, der physikalisch oder logisch in P Spuren („lanes”) aufgeteilt sind, wobei jede Spur irgendeine Anzahl von Einträgen hat (wobei jeder Eintrag zum Beispiel ein 32-Bit-Wort speichern mag). Eine Spur ist zu jedem der N Ausführungseinheiten 302 und P Load-Store-Einheiten LSU 303 zugeordnet, und entsprechende Einträge in unterschiedlichen Spuren können mit Daten für verschiedenen Threads, die das gleiche Programm ausführen, befüllt werden, um SIMD-Ausführung zu vereinfachen. Unterschiedliche Abschnitte der Spuren können zu unterschiedlichen Threadgruppen der G gleichzeitigen Threadgruppen allokiert werden, so dass ein gegebener Eintrag in dem lokalen Registerspeicher 304 nur für einen bestimmten Thread zugreifbar ist. In einer Ausführungsform werden gewisse Einträge in dem lokalen Registerspeicher 304 zum Speichern von Thread-Identifikatoren reserviert, um eines der speziellen Register zu implementieren. Ein einheitlicher („uniform”) L1-Cache 375 speichert zusätzlich einheitliche oder konstante Werte für jede Spur der N Ausführungseinheiten 302 und P Load-Store-Einheiten LSU 303.
Der geteilte bzw. gemeinsame Speicher 306 ist für Threads innerhalb eines einzigen CTA zugreifbar, mit anderen Worten ist jede beliebige Stelle in dem gemeinsamen Speicher 306 für jeden beliebigen Thread innerhalb des gleichen CTA (oder für jede beliebige Bearbeitungsmaschine innerhalb der SM 310) zugreifbar. Der gemeinsame Speicher 306 kann als ein gemeinsamer Registerspeicher oder als gemeinsamer interner („on-chip”) Speicher mit einer Verdrahtung („interconnect”) implementiert sein, die es jede Verarbeitungsmaschine erlaubt, aus und zu jeder Stelle in dem gemeinsamen Speicher zu lesen und zu schreiben. In anderen Ausführungsformen mag ein gemeinsamer Zustandsraum auf einen pro-CTA-Bereich von externem („off-chip”) Speicher abbilden und in dem L1-Cache 320 zwischengespeichert werden. Der Parameterspeicher kann als ein designierter Abschnitt innerhalb des gleichen gemeinsamen Registerspeichers oder innerhalb des gleichen gemeinsamen Cachespeichers, der den gemeinsamen Speicher 306 implementiert, oder als ein separater gemeinsamer Registerspeicher oder interner („on-chip”) Cachespeicher, zu der bzw. dem die LSUs 303 Nur-Lese-Zugriff haben, implementiert werden. In einer Ausführungsform wird der Bereich, der den Parameterspeicher implementiert, auch dazu verwendet, die CTA-ID und Task-ID sowie CTA- und Netzdimensionen oder Warteschlangeposition zu speichern, wobei Abschnitte der speziellen Register implementiert werden. Jede LSU 303 in dem SM 310 ist an eine einheitliche Adressabbildungseinheit 352 gekoppelt, die eine Adresse, die für Lade- und Speicherinstruktionen („load and sotre instructions”), die in einem einheitlichen Speicherraum angegeben sind, bereitgestellt worden sind, in eine Adresse in jedem distinkten Speicherraum umwandelt. Folglich mag eine Instruktion dazu verwendet werden, auf einen beliebigen der lokalen, gemeinsamen oder globalen Speicherräume durch Spezifizieren einer Adresse in dem vereinheitlichten Speicherraum zuzugreifen.
Der L1-Cache 320 in jedem SM 310 kann dazu verwendet werden, private einzelthreadbezogenen lokalen Daten („private per-thread local data”) und auch einzelapplikationsbezogene globalen Daten („per-application global data”) zwischenzuspeichern. In einigen Ausführungsformen mögen die pro-CTA-geteilten-Daten in dem L1-Cache 320 zwischengespeichert werden. Die LSUs 303 sind an den gemeinsamen Speicher 306 und den L1-Cache 320 über eine Speicher-und-Cache-Verdrahtung („memory and cache interconnect”) 380 gekoppelt.
MEHRKANAL-ZEITSCHEIBENGRUPPEN
Eine Zeitscheibengruppe („time slice group”) (TSG) ist eine Gruppierung von unterschiedlichen Strömen von Arbeit (die hierin als „Kanäle” bezeichnet werden), die die gleiche Kontextinformation teilen. In einer einer Ausführungsform wird der Satz von Kanälen, die einer TSG anhören, in einer Rundlaufordnung („round-robin order”) verarbeitet. Es ist wesentlich, dass eine Kontextwechselvorgang nicht benötigt wird, wenn die Verarbeitung einer bestimmten Kanal in der TSG gestoppt und die Verarbeitung einer nächsten Kanal in der TSG begonnen wird, weil jeder Kanal in der TSG die gleiche Kontextinformation gemeinsam hat. Folglich wird in einem bestimmten Verarbeitungszyklus eine Kontextwechseloperation, die die für die Verarbeitung der Kanäle in einer TSG notwendige Kontextinformation setzt, nur einmal ausgeführt, wenn der erste Kanal zur Verarbeitung ausgewählt wird.
4 ist eine Illustration einer Ausführungsliste („run list”) 402, eines Kanalplans („channel map”) 404 und einer pro-Kanal-Kontextinformation 406 basierend darauf, welche Tasks zur Ausführung innerhalb der GPCs 208 geplant bzw. gescheduled sind, gemäß einer Ausführungsform der vorliegenden Erfindung.
Wie es früher hierin beschrieben wurde, erzeugen Applikationen Tasks, die in der PPU ausgeführt werden sollen, wobei jeder Task mit einem bestimmten Kanal assoziiert ist. Ein Kanal mag mit Rechentasks oder Grafiktasks assoziiert sein. Alle anderen Typen von Tasks oder Kombinationen davon sind im Bereich der vorliegenden Erfindung. Die Verarbeitungsreihenfolge („processing sequence”) wird von den Applikationen definiert. Nachdem er die Kanäle von den Applikationen erhalten hat, gruppiert der Treiber 103 Kanäle, die die gleiche Kontextinformation teilen, in einer einzigen Zeitscheibengruppe (TSG). In einer Ausführungsform ist die Anzahl der Kanäle, die zu einer bestimmten TSG gehören können, auf eine vorbestimmte Anzahl begrenzt.
Ein (nicht gezeigter) Ressourcenmanager innerhalb des Treibers 103 erzeugt dann basierend auf den Kanälen und den entsprechenden TSGs die Ausführungsliste 402. Die Ausführungsliste 402 enthält einen Satz von Ausführungslisteneinträgen, die jeweils eine Eintragsart 504 und Eintragsinhalt 506 enthalten. Es gibt zwei Arten von Ausführungslisteneinträgen, ein Kanal-Ausführungslisteneintrag, wie zum Beispiel der Ausführungslisteneintrag 410, oder ein TSG-Ausführungslisteneintrag, wie zum Beispiel der Ausführungslisteneintrag 408. Ein Kanal-Ausführungslisteneintrag hat eine Kanal-Eintragsart 412 und speichert, in dem Eintragsinhalt 414, einen Kanalidentifikator, der mit einem bestimmten Kanal assoziiert ist. Ein TSG-Eintrag hat eine TSG-Eintragsart 412 und speichert, in dem Eintragsinhalt 414, einen TSG-Header. Der TSG-Header spezifiziert einen TSG-Identifikator (ID), die Länge der TSG in Ausführungslisteneinträge, die die Anzahl von zu der TSG gehörenden Kanälen angibt, und eine Ausführungslistenzeitscheibe, die eine Zeitdauer angibt, innerhalb der zu der TSG gehörenden Kanäle in einem einzigen Verarbeitungszyklus ausgeführt werden können.
Die Ausführungsliste 402 ist so organisiert, dass Kanal Ausführungslisteneinträge, die mit den zu einer bestimmten TSG gehörenden Kanälen assoziiert sind, direkt nach dem mit der bestimmten TSG assoziierten TSG-Ausführungslisteneintrag inkludiert sind. Falls der TSG-Header des Ausführungslisteneintrags 408 zum Beispiel angibt, dass die mit dem Ausführungslisteneintrag 408 assoziierten TSG zwei Kanäle hat, dann sind die zwei direkt nach dem Ausführungslisteneintrag 408 folgenden Einträge Kanal-Ausführungslisteneinträge, die mit diesen zwei Kanälen assoziiert sind. Die zu der bestimmten TSG gehörenden Kanäle sind zur Ausführung in einer vorbestimmten Reihenfolge gescheduled. Die Reihenfolge mag basierend auf der Sequenz der Ausführungslisteneinträge in der Ausführungsliste 406 oder auf jedem anderen Ordnungsmechanismus spezifiziert werden. Es wird von den mit dem Gebiet vertrauten Fachleuten verstanden werden, dass eine Ausführungsliste nur ein Beispiel davon ist, wie Kanäle, die ein Kontextbild („context image”) teilen können, zusammengruppiert werden können, jeder Mechanismus, der Kanäle gruppiert, die ein Kontextbild teilen können, ist von diesem Patent umfasst. In einer Ausführungsform enthält jeder Kanaleintrag, der mit einem zu einer TSG gehörenden Kanal assoziiert ist, einen Abschnitt, der angibt, ob dieser Kanal der „nächste” Kanal in der TSG ist. Dieser „nächsten” Abschnitt stellt sicher, dass die Verarbeitung der TSG auf dem gleichen Kanal beginnt, als den die TSG zuletzt verarbeitet hat.
Der Kanalplan 404 ist eine Abbildung zwischen Kanälen und entsprechender Kontextinformation. Der Kanalplan 404 enthält einen Satz von Planeinträgen, wobei jeder Planeintrag mit einem unterschiedlichen Kanal assoziiert ist, und enthält einen Kanalidentifikator und einen Zeiger auf Kontextinformation, die mit dem Kanal assoziiert ist. Jeder Kanal-Ausführungslisteneintrag, der in einer Ausführungsliste 402 enthalten ist, ist mit einem Planeintrag innerhalb des Kanalplans 404 assoziiert. Folglich entspricht ein Kanal-ID, der in dem Eintragsinhalt 414 einer Kanal-Ausführungslisteneintrag, der in der Ausführungsliste 402 enthalten ist, gespeichert ist, einem Kanal-ID, der in einem in dem Kanalplan 404 enthaltenen Planeintrag gespeichert ist. Jeder Planeintrag in dem Kanalplan 404 enthält des Weiteren einen Zeiger auf Kontextinformation, die dem mit dem Planeintrag assoziierten Kanal entspricht. Der Planeintrag 416 ist zum Beispiel mit einem bestimmten Kanal assoziiert, der durch den Kanal-ID 418 identifiziert und auch mit dem Kanal-Ausführungslisteneintrag 410 assoziiert ist. Der Planeintrag 416 enthält einen Kontextzeiger 420, der auf pro-Kanal-Kontextinformation 406 zeigt, die mit dem bestimmten Kanal assoziiert ist. Die pro-Kanal-Kontextinformation 406 enthält, ohne darauf beschränkt zu sein, Host-Zustand, Speichermanagement-Zustand, Maschinen-Zustand, usw., die zum Ausführen der in dem bestimmten Kanal enthaltenen Tasks benötigt werden.
5 ist eine detailliertere Darstellung der Hostschnittstelle 206 von 2, die zum Auswählen von Arbeit konfiguriert ist, die innerhalb des Verarbeitungsclusterarrays 230 ausgeführt werden soll, gemäß einer Ausführungsform der vorliegenden Erfindung. Die Hostschnittstelle 206 weist, wie gezeigt, einen Ausführungslisteprozessor 502 und einen Kontextwechsler 504 auf. Die Hostschnittstelle 206 hat des Weiteren Zugriff auf die Ausführungsliste 402, den Kanalplan 404 und der pro-Kanal-Kontextinformation 406.
Wenn neue Arbeit zur Ausführung innerhalb der GPCs 208 gescheduled werden muss, analysiert der Ausführungslisteprozessor 502 die Ausführungsliste 402, um einen Kanal auszuwählen, der als nächster zur Ausführung gescheduled werden soll. Bevor die mit einem bestimmten Kanal assoziierten Tasks verarbeitet werden können, muss mit diesem Kanal assoziierter pro-Kanal-Kontextinformation 408 typischerweise innerhalb der GPCs 208 gesetzt werden. Folglich bestimmt der Ausführungslisteprozessor 502, sobald der Kanal ausgewählt ist, der als nächster gescheduled werden soll, ob ein Kontextwechsel benötigt wird, um Tasks auszuführen, die mit dem ausgewählten Kanal assoziiert sind. Falls ein Kontextwechsel benötigt wird, dann erstellt der Kontextwechsler 404 eine Kontextwechseloperation, die basierend auf der pro-Kanal-Kontextinformation 408, die mit dem ausgewählten Kanal assoziiert ist, ausgeführt werden soll. Wenn aber ein Kontextwechsel nicht benötigt wird, dann wird eine Kontextwechseloperation nicht benötigt und Tasks, die mit dem ausgewählten Kanal assoziiert sind, werden zur Ausführung gescheduled. Da Kanäle, die zu der gleichen TSG gehören, mit der gleichen pro-Kanal-Kontextinformation assoziiert sind, können diese Kanäle, was wichtig ist, zur Ausführung nacheinander gescheduled werden, ohne das Bedürfnis nach einer Kontextwechseloperation dazwischen.
In Betrieb durchläuft der Ausführungslisteprozessor 502 die Einträge innerhalb der Ausführungsliste 402 in einer zyklischen Art und Weise („round robin fashion”). Indem er bestimmt, welcher Kanal als nächster zur Ausführung gescheduled werden soll, ruft der Ausführungslisteprozessor 502 den nächsten Eintrag in der Ausführungsliste 402 auf. Falls der nächste Eintrag in der Ausführungsliste 402 ein TSG-Ausführungslisteneintrag ist, dann liest der Ausführungslisteprozessor 502 den TSG-Header, der in dem Eintragsinhalt 414 enthalten ist. Der Ausführungslisteprozessor 502 identifiziert basierend auf der Länge, die in dem TSG-Header spezifiziert ist, die Kanal-Ausführungslisteneinträge, die zu der TSG gehören. Der Ausführungslisteprozessor 502 identifiziert auch basierend auf dem TSG-Header die Zeitscheibe, die zu der TSG allokiert ist, so dass die Kanäle in der TSG in Rundlaufordnung („round robin order”) verarbeitet werden bis die Zeitscheibe endet, die TSG keine Tasks mehr hat, die sie starten kann, oder vom System unterbrochen („preempted”) wird. Der Ausführungslisteprozessor 502 identifiziert dann einen bestimmten Kanal, der mit einem Kanal-Ausführungslisteneintrag assoziiert ist, der der TSG entspricht, und als nächster zur Ausführung gescheduled werden soll. In einer Ausführungsform wird der erste Kanal, der in eine TSG geladen wird, basierend auf dem Vorhandensein eines Bits in dem Eintragsinhalt 414 von dem Kanal-Ausführungslisteneintrag identifiziert, welches Bit indiziert, dass der bestimmte Kanal in der TSG als nächster zur Ausführung gescheduled werden soll.
Sobald der bestimmte Kanal identifiziert ist, weist der Ausführungslisteprozessor den Kontextwechsler 504 darauf hin, die Kontextinformation zu laden, die sich auf den bestimmten Kanal bezieht. Der Kontextwechsler 504 identifiziert basierend auf dem Kanalplan 404 die pro-Kanal-Kontextinformation 406, die mit dem bestimmten Kanal assoziiert ist, und wechselt dementsprechend den Kontext in der GPCs 208. Sobald die mit dem bestimmten Kanal assoziierte Kontextinformation geladen ist, fängt die Zeitscheibe, die zu der TSG allokiert ist, an und die Ausführung der Tasks, die mit dem bestimmten Kanal assoziiert sind, können von den GPCs 208 begonnen werden.
Die mit dem bestimmten Kanal innerhalb der TSG assoziierten Tasks werden weiterhin ausgeführt bis (i) ein Kanalwechsel zu einem anderen Kanal innerhalb der TSG benötigt wird oder (ii) ein Kanalwechsel zu einem Kanal außerhalb der TSG benötigt wird. Ein Kanalwechsel von dem bestimmten Kanal zu einem anderen Kanal innerhalb der TSG wird benötigt, wenn die Ausführung von Tasks innerhalb des bestimmten Kanals erledigt ist oder wenn die Ausführung zum Stillstand gekommen ist als Folge eines Fehlers bzw. Versagens beim Akquirieren eines Semaphors („semaphore acquire failure”). In einem solchen Szenario wird ein nächster Kanal innerhalb der TSG zur Ausführung ausgewählt. Da alle Kanäle innerhalb der TSG die gleiche Kontextinformation teilen, wird eine Kontextwechseloperation beim Wechseln zwischen Kanälen innerhalb der gleichen TSG nicht benötigt. Demzufolge können Tasks, die mit dem neu ausgewählten Kanal assoziiert sind, auf die GPCs 208 ausgeführt werden, ohne eine dazwischenkommende Kontextwechseloperation. Da die TSG von einem Kanal zu einem anderen wechseln kann, wenn Tasks erledigt sind oder das Akquirieren eines Semaphors scheitert, sind die Kanäle zwischen Kanälen, was wichtig ist, nicht geordnet, es sei denn, dass dies explizit von einem Semaphor gemacht wird.
In einer Ausführungsform mögen Kanäle innerhalb einer TSG Zugriff auf eine Mehrzahl unterschiedlicher Typen von Verarbeitungsclustern haben. Zum Beispiel ein Rechencluster, Grafikcluster, Kopie-Cluster, 2D-Cluster, usw. In der bevorzugten Ausführungsform ist jeder Cluster dazu fähig, gleichzeitig auf einen unabhängigen Kanal zu arbeiten. In anderen Ausführungsformen mögen einige Cluster einander gegenseitig ausschließen („mutually exclusive”). Zum Beispiel mag es für den Rechencluster notwendig sein, mit der Ausführung eines Tasks zu warten bis der Grafikcluster inaktiv bzw. leerläuft. In anderen Ausführungsformen mag ein Cluster nur dazu fähig sein, ein einziger Task auf einmal zu verarbeiten. Der Kopie-Cluster mag zum Beispiel nur eine einzige Kopie behandeln. In einigen Ausführungsformen mag ein Kanal nur Zugriff auf jeweils einen einzigen Verarbeitungscluster haben. In einigen Ausführungsformen müssen unabhängige Cluster deren Kontexte vor der Verarbeitung des ersten TSG-Tasks unabhängig geladen haben.
Während Kanäle, die zu der TSG gehören, zur Ausführung innerhalb der GPCs 208 gescheduled worden sind, führt eine (nicht gezeigete) Kopiermaschine des Weiteren Kopieroperationen gleichzeitig mit der Ausführung von Tasks und basierend auf dem gegenwärtig gesetzten Kontextinformation durch. Für die asynchronen Kopiermaschinen läuft dies auf eine Leistungssteigerung hinaus, da die Kopiermaschine nicht unabhängig Kontext wechseln muss.
Ein Kanalwechsel zu einem Kanal außerhalb der TSG wird benötigt, falls eine von vielen Bedingungen erfüllt sind. Diese Bedingungen enthalten, ohne aber dazu begrenzt zu sein, (i) den Ablauf der Zeitscheibe, die zu der TSG allokiert ist, (ii) dass jeder Kanal innerhalb der TSG komplett ausgeführt worden ist und deswegen leerläuft, (iii) dass jeder Kanal innerhalb der TSG zum Stillstand kommt wegen Scheiterns beim Akquirieren eines Semaphors oder wegen Leerlaufens, (iv) dass einem Produktionsverfahren („yield method”) begegnet worden ist, das die zu der TSG allokierte Zeitschiebe effektiv beendet und (vi) eine Vorwegnahme-Bedingung, die das Auswählen eines neuen Kanals oder einer anderen Ausführungsliste erzwingt. Falls eine Bedingung bzw. einen Zustand existiert, die bzw. der einen Kanalwechsel zu einem Kanal außerhalb der TSG erfordert, dann speichert der Ausführungslisteprozessor 502 erst den jetzigen Zustand der TSG, einschließlich der Identität des letzten Kanals innerhalb der TSG, der zumindest teilweise verarbeitet wurde. Der Ausführungslisteprozessor 502 wählt dann den nächsten Kanal außerhalb der TSG aus, der berarbeitet werden soll. Da die Kontextinformation bezüglich eines Kanals außerhalb der TSG unterschiedlich ist, wird eine Kontextwechseloperation benötigt beim Wechseln zu einem Kanal außerhalb der TSG.
Fachleute werden verstehen, dass andere Kriterien für das Wechseln zwischen Kanäle in einer TSG oder aus einer TSG heraus verwendet werden können, so lange das Kriterium erlaubt, dass Software zusammenhängende Tasks in einem Kanal zu spezifizieren, die als eine atomare Operation ausgeführt werden. Ein Kanal braucht mit anderen Worten einen Weg, um zu garantieren, dass ein Task, der Zustand anordnet („sets up”), und ein zweiter Task, der auf diesem Zustand ausführt, nacheinander ausgeführt werden, ohne Wechsel zu einem anderen Kanal in der TSG.
In einer Ausführungsform hat jeder Kanal innerhalb der TSG ein anhängige-Arbeit-Bit, das angibt, ob es ausstehende Arbeit in Bezug auf dem Kanal gibt. Falls in einer solchen Ausführungsform Arbeit in Bezug auf dem Kanal noch anhängig ist als ein Kanalwechsel stattfindet, dann wird das anhängige-Arbeit-Bit gesetzt, um anzugeben, dass Arbeit in Bezug auf dem Kanal noch aussteht.
Die 6A und 6B stellen ein Flussdiagramm von Verfahrensschritten zum Identifizieren eines nächsten Kanals zur Ausführung bereit, gemäß einer Ausführungsform der vorliegenden Erfindung. Obwohl die Verfahrensschritte in Zusammenhang mit den Systemen für die 1–5 beschrieben werden, werden Fachleute verstehen, dass jedes System, das zum Durchführen der Verfahrensschritte, in jeder beliebigen Reihenfolge, konfiguriert ist, im Bereich der vorliegenden Erfindung liegt.
Das Verfahren beginnt beim Schritt 602, in dem der Ausführungslisteprozessor 502 beim Bestimmen, welcher Kanal als nächster zur Ausführung gescheduled werden soll, den nächsten Eintrag in der Ausführungsliste 402 erhält. Beim Schritt 604 bestimmt der Ausführungslisteprozessor 502, ob der erhaltene Eintrag ein Eintrag der TSG-Art ist. Falls der erhaltene Eintrag kein Eintrag der TSG-Art ist, dann schreitet das Verfahren zu Schritt 605 weiter, in dem der Ausführungslisteprozessor 502 die Ausführung des mit dem erhaltenen Eintrag assoziierten Kanals zeitlich festlegt („schedules”). Falls aber der erhaltene Eintrag kein Eintrag der TSG-Art ist, dann schreitet das Verfahren zu Schritt 606 weiter.
Beim Schritt 606 parst der Ausführungslisteprozessor 502 den TSG-Header, der in dem erhaltenen Eintrag enthalten ist, um den TSG-ID, die TSG-Länge und die TSG-Zeitscheibe der TSG zu bestimmen, die mit dem erhaltenen Eintrag assoziiert ist. Wie es früher hierin beschrieben wurde, gibt die TSG-Länge die Anzahl der Kanäle an, die zu der TSG gehören, und die TSG-Zeitscheibe gibt eine Zeitdauer an, während der Kanäle, die zu der TSG gehören, in einem einzigen Verarbeitungszyklus ausgeführt werden können.
Beim Schritt 608 bestimmt der Ausführungslisteprozessor basierend auf der TSG-Länge den Satz von Kanälen, der zu der TSG gehört. Die Ausführungsliste 402 ist noch einmal so organisiert, dass die Kanal-Ausführungslisteneinträge, die mit den Kanälen assoziiert sind, die zu der TSG gehören, direkt nach dem erhaltenen Eintrag inkludiert sind. Beim Schritt 610 wählt der Ausführungslisteprozessor 502 einen Kanal innerhalb des Satzes von Kanälen aus, welcher als nächster zur Ausführung gescheduled werden soll. In einer Ausführungsform enthält jeder Kanal einen „nächster”-Identifikator, welcher, wenn er gesetzt ist, angibt, dass der bestimmte Kanal zur Ausführung als nächster gescheduled werden soll. Dieses Bit wird nur im Schritt 610 benutzt.
Beim Schritt 610 lädt der Kontextwechsler 504 die pro-Kanal-Kontextinformation 406, die sich auf den ausgewählten Kanal bezieht. Da der ausgewählte Kanal der erste Kanal ist, der zu der TSG gehört und in dem gegenwärtigen Verarbeitungszyklus gescheduled werden soll, muss die Kontextinformation innerhalb der GPCs 208 gesetzt werden, so dass Tasks, die von dem Kanal spezifiziert werden, ausgeführt werden mögen. Die Zeitscheibe, die zu der TSG allokiert ist, fängt an, wenn die pro-Kanal-Kontextinformation 406, die sich auf den ausgewählten Kanal bezieht, geladen wird. Kanäle, die zu der TSG gehören, können innerhalb dieser Zeitscheibe ausgeführt werden, es sei denn, dass sie unterbrochen werden. Beim Schritt 612 stellt der Ausführungslisteprozessor 206 Tasks, die von dem ausgewählten Kanal spezifiziert sind, für Ausführung innerhalb der GPCs 208 aus.
Beim Schritt 616 bestimmt der Ausführungslisteprozessor 502, ob eine oder mehrere Bedingungen für den Wechsel zu einem Kanal außerhalb der TSG erfüllt sind. Wie es schon früher hierin diskutiert wurde, enthalten die Bedingungen für das Wechseln zu einem Kanal außerhalb der TSG, ohne aber dazu begrenzt zu sein, (i) den Ablauf der Zeitscheibe, die zu der TSG allokiert ist, (ii) dass jeder Kanal innerhalb der TSG komplett ausgeführt worden ist und deswegen leerläuft, (iii) dass jeder Kanal innerhalb der TSG zum Stillstand kommt wegen Scheiterns beim Akquirieren eines Semaphors oder wegen Leerlaufens, (iv) dass einem Produktionsverfahren („yield method”) begegnet worden ist, das die zu der TSG allokierte Zeitschiebe effektiv beendet und (vi) eine Vorwegnahme-Bedingung, die das Auswählen eines neuen Kanals oder einer anderen Ausführungsliste erzwingt.
Falls eine Bedingung, die einen Kanalwechsel zu einem Kanal außerhalb der TSG erfordert, erfüllt ist, dann schreitet das Verfahren 600 zu Schritt 618 weiter, in dem der Ausführungslisteprozessor 502 den gegenwärtigen Zustand der TSG speichert. Das Verfahren 600 läuft dann weiter zurück zu Schritt 602, in dem den nächsten Eintrag innerhalb der Ausführungsliste erhalten wird, um den nächsten Kanal außerhalb der TSG auszuwählen, der ausgeführt werden soll. Da sich die pro-Kanal-Kontextinformation, die sich auf einen Kanal außerhalb der TSG bezieht, von der gegenwärtig gesetzten Kontextinformation unterscheidet, wird eine Kontextwechseloperation benötigt, wenn es zu einem Kanal außerhalb der TSG gewechselt wird.
Falls eine Bedingung, die einen Kanalwechsel zu einem Kanal außerhalb der TSG, nicht erfüllt ist, dann schreitet das Verfahren zu Schritt 620 weiter. Beim Schritt 620 bestimmt der Ausführungslisteprozessor 502, ob eine oder mehrere Bedingungen für einen Wechsel zu einem anderen Kanal innerhalb der TSG erfüllt sind. Ein Kanalwechsel von dem bestimmten Kanal zu einem anderen Kanal innerhalb der TSG wird noch einmal benötigt, wenn die Ausführung von Tasks innerhalb des bestimmten Kanals erledigt ist oder wenn die Ausführung zum Stillstand gekommen ist als Folge eines Fehlers beim Akquirieren eines Semaphors. Falls eine Bedingung, die einen Kanalwechsel zu einem anderen Kanal innerhalb der TSG erfordert, nicht erfüllt ist, dann kehrt das Verfahren zu Schritt 614 zurück, der früher hierin beschrieben wurde.
Wenn aber eine Bedingung erfüllt ist, die einen Kanalwechsel zu einem anderen Kanal innerhalb der TSG erfordert ist, dann schreitet das Verfahren zu Schritt 622 fort, in dem der Ausführungslisteprozessor 502 in einer Ausführungsform das nächste Bit für den gegenwärtigen Kanal löscht, einen nächsten Kanal in dem Satz von Kanälen auswählt, die zu der TSG gehören, und das nächste Bit in dem neuen Kanal setzt. Beim Schritt 624 erlässt der Ausführungslisteprozessor 206 Tasks, die von dem ausgewählten Kanal spezifiziert sind, für Ausführung innerhalb der GPCs 208. Da jeder Kanal in der TSG die gleiche Kontextinformation teilt, wird eine Kontextwechseloperation, was wichtig ist, nicht benötigt, wenn die Verarbeitung eines bestimmten Kanals in der TSG stoppt und die Verarbeitung eines nächsten Kanals in der TSG beginnt. Das Verfahren 600 kehrt dann zum Schritt 616 zurück, der früher hierin beschrieben wurde.
Es ist ein Vorteil der vorliegenden Erfindung, dass unterschiedliche Kanäle von Arbeit, die die gleiche Kontextinformation mit einander teilen, von den GPCs 208 ausgeführt werden können, ohne das Bedürfnis nach intervenierenden Kontextwechseloperationen. Wenn ein Kanal zum Stillstand kommt, kann ein anderer Kanal folglich zur Ausführung gescheduled werden, ohne die mit dem Kontextwechseln verbundenen Kosten zu verursachen, und dabei den gesamten Durchsatz und die gesamte Effizienz und Leistung des Systems erhöhen.
Eine Ausführungsform der Erfindung mag als ein Programmprodukt zur Verwendung mit einem Computersystem implementiert werden. Das Programm bzw. die Programme des Programmprodukts definiert bzw. definieren Funktionen der Ausführungsformen (einschließlich der hierin beschriebenen Verfahren) und kann bzw. können auf einer Vielfalt von computerlesbaren Speichermedien enthalten werden. Beispielhafte computerlesbare Speichermedien umfassen, sind aber nicht darauf begrenzt: (i) nicht-schreibbare Speichermedien (zum Beispiel schreibgeschützte („read-only”) Speichervorrichtungen innerhalb eines Computers, wie zum Beispiel nicht schreibbare CD-(„compact disc”)-Speicher-(CD-ROM)-Discs, die mittels eines CD-ROM-Laufwerks lesbar sind, Flash-Speicher, nicht schreibbare Speicher-(ROM)-Chips oder jede andere Art von nicht-flüchtigem Festkörper-Halbleiterspeicher („solid-state non-volatile semiconductor memory”)), auf welchen Informationen permanent gespeichert werden; und (ii) schreibbare Speichermedien (zum Beispiel Floppy-Disks in einem Diskettenlaufwerk oder Festplattenlaufwerk oder jede Art von Festkörper-Halbleiterspeicher mit wahlfreiem Zugriff („solid-state random-access semiconductor memory”)), auf welchem veränderbare Informationen gespeichert sind.
Die Erfindung ist mit Bezug auf spezifische Ausführungsformen oben beschrieben worden. Fachleute werden aber verstehen, dass verschiedene Modifikationen und Änderungen davon gemacht werden können, ohne von dem breiteren Geist und Umfang der Erfindung, wie er in den angehängten Patentansprüchen dargestellt ist, abzuweichen. Die vorhergehende Beschreibung und Zeichnungen sind folglich eher in einer illustrativen als in einer restriktiven Bedeutung zu beachten.

Claims

Computerimplementiertes Verfahren zum Scheduling der Ausführung von Tasks innerhalb einer Verarbeitungseinheit, das Verfahren aufweisend: Bestimmen, dass ein Satz von Kanälen, die Tasks spezifizieren, welche innerhalb der Verarbeitungseinheit ausgeführt werden sollen, mit einer Zeitscheibengruppe assoziiert ist, wobei jeder Kanal einen unterschiedlichen Satz von Tasks spezifiziert und Kontextinformation entsprechend jedem Kanal, der mit der Zeitscheibengruppe assoziiert ist, die gleiche ist, Auswählen eines ersten Kanals, der in dem Satz von Kanälen enthalten ist, zur nächsten Ausführung innerhalb der Verarbeitungseinheit, Bestimmen, ob Kontextinformation, die dem ersten Kanal entspricht, in der Verarbeitungseinheit gesetzt werden muss, wobei, wenn ein vorhergehender Kanal, der von der Verarbeitungseinheit ausgeführt wurde, in dem Satz von Kanälen enthalten ist, Kontextinformation entsprechend dem ersten Kanal nicht gesetzt werden muss innerhalb der Verarbeitungseinheit, und wenn der vorhergehende Kanal, der von der Verarbeitungseinheit ausgeführt wurde, nicht in dem Satz von Kanälen enthalten ist, Kontextinformation entsprechend dem ersten Kanal gesetzt werden muss innerhalb der Verarbeitungseinheit, und Scheduling eines ersten Satzes von Tasks, der von dem ersten Kanal spezifiziert ist, zur Ausführung innerhalb der Verarbeitungseinheit.
Computersystem aufweisend: eine Verarbeitungseinheit, die zur Ausführung von Tasks konfiguriert ist, und eine Hostschnittstelle, die konfiguriert ist zum Scheduling der Ausführung von Tasks innerhalb der Verarbeitungseinheit durch Durchführen der folgenden Schritten: Bestimmen, dass ein Satz von Kanälen, die Tasks spezifizieren, welche innerhalb der Verarbeitungseinheit ausgeführt werden sollen, mit einer Zeitscheibengruppe assoziiert ist, wobei jeder Kanal einen unterschiedlichen Satz von Tasks spezifiziert und Kontextinformation entsprechend jedem Kanal, der mit der Zeitscheibengruppe assoziiert ist, die gleiche ist, Auswählen eines ersten Kanals, der in dem Satz von Kanälen enthalten ist, zur nächsten Ausführung innerhalb der Verarbeitungseinheit, Bestimmen, ob Kontextinformation, die dem ersten Kanal entspricht, in der Verarbeitungseinheit gesetzt werden muss, wobei, wenn ein vorhergehender Kanal, der von der Verarbeitungseinheit ausgeführt wurde, in dem Satz von Kanälen enthalten ist, Kontextinformation entsprechend dem ersten Kanal nicht gesetzt werden muss innerhalb der Verarbeitungseinheit, und wenn der vorhergehende Kanal, der von der Verarbeitungseinheit ausgeführt wurde, nicht in dem Satz von Kanälen enthalten ist, Kontextinformation entsprechend dem ersten Kanal gesetzt werden muss innerhalb der Verarbeitungseinheit, und Scheduling eines ersten Satzes von Tasks, der von dem ersten Kanal spezifiziert ist, zur Ausführung innerhalb der Verarbeitungseinheit.
Das Computersystem gemäß Anspruch 2, wobei das Bestimmen, dass der Satz von Kanälen mit der Zeitscheibengruppe assoziiert ist, ein Parsen eines Zeitscheibengruppe-Headers aufweist, der mit der Zeitscheibengruppe assoziiert ist, die den Satz von Kanälen identifiziert.
Das Computersystem gemäß Anspruch 2, ferner aufweisend ein Bestimmen, ob die Verarbeitungseinheit das Ausführen von Tasks stoppen soll, die von Kanälen in dem Satz von Kanälen spezifiziert sind.
Das Computersystem gemäß Anspruch 4, wobei die Zeitscheibengruppe mit einer Zeitdauer assoziiert ist, während welcher die von dem Satz von Kanälen spezifizierten Tasks, nachdem diese gescheduled worden sind, ausgeführt werden dürfen.
Das Computersystem gemäß Anspruch 5, wobei die Verarbeitungseinheit das Ausführen von Tasks, die von Kanälen in dem Satz von Kanälen spezifiziert sind, stoppen soll, wenn die Zeitdauer abläuft.
Das Computersystem gemäß Anspruch 5, wobei die Verarbeitungseinheit das Ausführen von Tasks, die von Kanälen in dem Satz von Kanälen spezifiziert sind, stoppen soll, wenn jeder Kanal in dem Satz von Kanälen darauf wartet, dass ein Task beendet oder inaktiv wird.
Das Computersystem gemäß Anspruch 5, ferner aufweisend, wenn die Verarbeitungseinheit die Ausführung von Tasks, die von den Kanälen in dem Satz von Kanälen spezifiziert ist, stoppen soll, Speichern eines mit der Zeitscheibengruppe assoziierten Zustands und Auswählen eines zweiten Kanals, der nicht mit der Zeitscheibengruppe assoziiert ist, zur nächsten Ausführung innerhalb der Verarbeitungseinheit.
Das Computersystem gemäß Anspruch 2, ferner aufweisend, vor dem Auswählen des ersten Kanals, ein Bestimmen, ob ein nächster Kanal, der in dem Satz von Kanälen enthalten ist, zur Ausführung innerhalb der Verarbeitungseinheit ausgewählt werden soll.
Das Computersystem gemäß Anspruch 9, wobei ein nächster Kanal, der in dem Satz von Kanälen enthalten ist, zur Ausführung ausgewählt werden soll, wenn ein vorhergehender Kanal, der innerhalb der Verarbeitungseinheit ausgeführt wurde, inaktiv ist oder darauf wartet, dass ein Task beendet wird.