DE102012222932A1

DE102012222932A1 - Gestaltetes Register-Datei-Lesen

Info

Publication number: DE102012222932A1
Application number: DE102012222932A
Authority: DE
Inventors: Jack Hilaire Choquette; Michael Fetterman; Shirish Gadre; Xiaogang Qiu; Omkar PARANJAPE; Anjana Rajendran; Stewart Glenn Carlton; Eric Lyell Hill; Rajeshwaran Selvanesan; Douglas J. Hahn
Original assignee: Nvidia Corp
Current assignee: Nvidia Corp
Priority date: 2011-12-22
Filing date: 2012-12-12
Publication date: 2013-06-27
Also published as: TW201337829A; US9626191B2; CN103257931A; US20130166877A1

Abstract

Eine Ausführungsform der vorliegenden Offenbarung führt eine Technik zum Durchführen eines gestalteten Zugriffs einer Register-Datei aus, welche einen Satz von N Registern umfasst, wobei N größer ist als zwei ist oder gleich zwei ist. Die Technik involviert für zumindest einen Thread, welcher in einer Gruppe von Threads umfasst ist, Empfangen einer Anfrage, um auf eine erste Menge von Daten aus jedem Register in dem Satz von N Registern zuzugreifen, und Konfigurieren einer Kreuzschiene, um dem zumindest einen Thread zu erlauben, auf die erste Menge von Daten aus jedem Register in dem Satz von N Registern zuzugreifen.

Description

HINTERGRUND DER ERFINDUNG
Die vorliegende Offenbarung betrifft im Allgemeinen Prozessor-Register-Dateien und insbesondere Verfahren und Apparat zum gestalteten (shaped) Register-Datei-Lesen.
BESCHREIBUNG DER BETREFFENDEN TECHNIK
Parallel-Prozessoren haben mehrere unabhängige Kerne, welche es mehreren Threads erlaubt, simultan unter Benutzung verschiedener Hardware-Ressourcen ausgeführt zu werden. SIMD(Einfach-Anweisung, Mehrfach-Daten)-Architektur-Prozessoren führen dieselbe Anweisung auf jedem der mehreren Kerne aus, wobei jeder Kern an verschiedene Eingabe-Daten ausführt. MIMD-(Mehrfach-Anweisungen, Mehrfach-Daten)-Architektur-Prozessoren führen verschiedene Anweisungen auf verschiedenen Kernen aus, wobei verschiedene Eingabe-Daten zu jedem Kern zugeführt sind. Parallel-Prozessoren können auch Mehrprozess-gestützt sein (multi-threaded), was ermöglicht, dass zwei oder mehrere Threads im Wesentlichen simultan unter Benutzung der Ressourcen eines einzelnen Verarbeitungs-Kerns ausführen (d. h. die verschiedenen Threads werden auf dem Kern während verschiedener Taktzyklen ausgeführt).
Wenn ein Prozessor eine Anweisung zur Ausführung mittels eines Prozessor-Kerns plant (schedules), schreibt der Prozessor gewisse Werte in spezielle Register in einer Register-Datei, welche mit dem Prozessor-Kern gekoppelt ist. Ein Register kann den Opcode speichern, welcher die Operation spezifiziert, welche mittels des Prozessor-Kerns auszuführen ist, und zusätzliche Register können Operanden-Werte speichern, welche als Eingabe für den Prozessor-Kern zur Ausführung der Anweisung benutzt werden. Damit eine Operation ausgeführt wird, muss jeder der Werte in die Register-Datei geschrieben werden und dann mit den Eingängen bzw. Eingaben (inputs) des Daten-Pfades über eine Kreuzschiene (crossbar) oder ein anderes Daten-Übermittlungs-Mittel gekoppelt werden.
Häufig bezieht sich eine Anweisung für einen Thread auf 32-Bit-, 64-Bit- oder sogar 128-Bit-Operanden, welche von der Register-Datei zu lesen sind. Konventionelle Register-Dateien – welche typischerweise eine Mehrzahl von 32-Bit-Fächern (slots) umfassen – erfordern jedoch von dem Prozessor, mehrere 32-Bit-Werte, welche von den 32-Bit-Fächern gelesen sind, in 64-Bit- oder 128-Bit-Werte zu transponieren, welche mittels der Threads angefragt sind, was einige Taktzyklen zu vollenden erfordert. Eine Lösung dieses Problems involviert einfach Implementieren von Register-Dateien, welche größere Fächer umfassen, z. B. 64-Bit-Fächer. Unglücklicherweise sind derartige Register-Dateien zu höheren Kosten zu bekommen und erhöhen die Gesamt-Komplexität des Prozessors, in welchem sie umfasst sind.
Was demgemäß in der Technik benötigt ist, ist eine verbesserte Technik zum Handhaben von Größe-variables-Daten-Lesen einer Register-Datei (variable-sized data reads).
ZUSAMMENFASSUNG DER ERFINDUNG
Eine Ausführungsform der vorliegenden Erfindung führt ein Verfahren zum Durchführen eines gestalteten Zugriffs einer Register-Datei aus, welche einen Satz von N Registern umfasst, wobei N größer ist als zwei oder gleich zwei ist. Das Verfahren umfasst die Schritte von, für zumindest einen Thread, welcher in einer Gruppe von Threads umfasst ist, Empfangen einer Anfrage, auf eine erste Menge von Daten für jedes Register in dem Satz von N Registern zuzugreifen, und Konfigurieren einer Kreuzschiene, um dem zumindest einen Thread zu erlauben, auf die erste Menge von Daten von jedem Register in dem Satz von N Registern zuzugreifen.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
So dass die Weise, in welcher die oben zitierten Merkmale der vorliegenden Offenbarung im Detail verstanden werden können, kann eine besondere Beschreibung der Erfindung, welche kurz oben zusammengefasst ist, durch Bezugnahme auf Ausführungsformen genommen werden, von welchen einige in den angehängten Zeichnungen illustriert sind. Es ist jedoch zu bemerken, dass die angehängten Zeichnungen nur typische Ausführungsformen dieser Offenbarung illustrieren und dass sie daher nicht aufzufassen sind, ihren Geltungsbereich zu begrenzen, denn die Offenbarung kann andere genauso effektive Ausführungsformen zulassen.
1 ist ein Blockdiagramm, welches ein Computersystem illustriert, welches konfiguriert ist, einen oder mehrere Aspekte der vorliegenden Erfindung zu implementieren;
2 ist ein Blockdiagramm eines Parallel-Verarbeitungs-Subsystem für das Computersystem der 1, gemäß einer Ausführungsform der vorliegenden Erfindung;
3A ist ein Blockdiagramm des Frontends von 2, gemäß einer Ausführungsform der vorliegenden Offenbarung;
3B ist ein Blockdiagramm eines Allgemein-Verarbeitungs-Clusters innerhalb einer der Parallel-Verarbeitungs-Einheiten von 2, gemäß einer Ausführungsform der vorliegenden Offenbarung;
3C ist ein Blockdiagramm eines Teils des Streaming-Mehrfach-Prozessors von 3B, gemäß einer Ausführungsform der vorliegenden Offenbarung; und
4 ist ein Blockdiagramm eines Streaming-Mehrfach-Prozessors von 3B gemäß einer anderen Beispiel-Ausführungsform der vorliegenden Offenbarung.
5 illustriert eine detaillierte Ansicht der lokalen Register-Datei von 3C gemäß einer Ausführungsform der vorliegenden Offenbarung.
6 illustriert 32-Bit-Lese-Operationen (32-bit reads) von vier verschiedenen Registern für acht Threads gemäß einer Ausführungsform der vorliegenden Offenbarung.
7 illustriert 64-Bit-Lese-Operationen (reads) von vier verschiedenen Registern für acht Threads gemäß einer Ausführungsform der vorliegenden Offenbarung.
8 illustriert 128-Bit-Lese-Operationen eines Registers für acht Threads gemäß einer Ausführungsform der vorliegenden Offenbarung.
DETAILLIERTE BESCHREIBUNG
In der folgenden Beschreibung werden zahlreiche spezifische Details ausgeführt, um ein durchgängigeres Verständnis der vorliegenden Offenbarung bereitzustellen. Es wird jedoch für den Fachmann in der Technik ersichtlich sein, dass die vorliegende Erfindung ohne ein oder mehrere dieser spezifischen Details praktiziert werden kann. In anderen Fällen sind wohl bekannte Merkmale nicht beschrieben worden, um ein Verschleiern der vorliegenden Offenbarung zu vermeiden.
Die Offenbarung beschreibt Verfahren und Apparat für Quelle-Operand-Kollektor-Zwischenspeichern (source operand collector caching). In einer Ausführungsform umfasst ein Prozessor eine Register-Datei, welche mit Speicher-Elementen (d. h. einem Operand-Kollektor) gekoppelt sein kann, welche Eingaben bzw. Eingänge (inputs) an den Daten-Pfad des Prozessor-Kerns zur Ausführung einer Anweisung bereitstellen. Um die Bandbreite zwischen der Register-Datei und dem Operand-Kollektor zu vermindern, können Operanden zwischengespeichert werden und in nachfolgenden Anweisungen erneut benutzt werden. Folglich kann nur eine Untermenge der Operanden, welche mittels einer gegebenen Anweisung spezifiziert sind, benötigt sein, in den Operand-Kollektor geladen zu werden. Eine Planungs-Einheit unterhält eine Zwischenspeicher-Tabelle zum Überwachen der Register-Werte, welche momentan in dem Operand-Kollektor gespeichert sind. Die Planungs-Einheit kann auch den Operand-Kollektor konfigurieren, die bestimmten Speicher-Elemente auszuwählen, welche mit den Eingaben bzw. Eingängen an den Daten-Pfad für eine gegebene Anweisung gekoppelt sind, was erlaubt, dass Operanden für zwei oder mehr Anweisungen simultan zwischengespeichert werden.
Systemüberblick
1 ist ein Blockdiagramm, welches ein Computersystem 100 illustriert, welches konfiguriert ist, einen oder mehrere Aspekte der vorliegenden Offenbarung zu implementieren. Computersystem 100 umfasst eine Zentralverarbeitungseinheit (CPU) 102 und einen Systemspeicher 104, welcher über einen Zwischenverbindungspfad (interconnection path) kommuniziert, welcher eine Speicherbrücke 105 umfassen kann. Speicherbrücke 105, welche z. B. ein Northbridge-Chip sein kann, ist über einen Bus oder einen anderen Kommunikationspfad 106 (z. B. HyperTransport-Link) mit einer I/O-(Eingabe/Ausgabe)-Brücke 107 verbunden. I/O-Brücke 107, welche z. B. ein Southbridge-Chip sein kann, empfängt Benutzereingabe von einem oder mehreren Benutzer-Eingabegeräten 108 (z. B. Tastatur, Maus) und leitet die Eingabe an CPU 102 über Kommunikationspfad 106 und Speicherbrücke 105 weiter. Ein Parallel-Verarbeitungs-Subsystem 112 ist mit der Speicherbrücke 105 über einen Bus oder einen zweiten Kommunikationspfad 113 (z. B. einen Peripheral Component Interconnect(PCI)-Express Accelerated Graphics Port, oder HyperTransport-Link) gekoppelt; in einer Ausführungsform ist das Parallel-Verarbeitungs-Subsystem 112 ein Grafik-Subsystem, welches Pixel an ein Anzeigegerät 110 (z. B. ein konventioneller Kathodenstrahlröhre- oder Flüssigkristallanzeige-basierter Monitor) liefert. Eine Systemplatte 114 ist auch mit der I/O-Brücke 107 verbunden. Ein Switch 116 stellt Verbindungen zwischen I/O-Brücke 107 und anderen Komponenten bereit, wie etwa ein Netzwerkadapter 118 und verschiedenen Hinzufügungskarten (Add-in-Cards) 120 und 121. Andere Komponenten (nicht explizit gezeigt) umfassend Universal Serial Bus USB- oder andere Port-Verbindungen, Kompakt-Disk(CD)-Laufwerke, digitale Video-Disk(DVD)-Laufwerke, Filmaufnahmegeräte, und dergleichen, können auch mit der I/O-Brücke 107 verbunden sein. Die verschiedenen Kommunikationspfade, welche in 1 gezeigt sind, einschließlich die speziell genannten Kommunikationspfade 106 und 113, können unter Benutzung irgendwelcher geeigneten Protokolle implementiert sein, wie etwa PCI-Express, AGP (Accelerated Graphics Port), HyperTransport, oder irgendeines oder irgendwelcher Bus- oder Punkt-zu-Punkt-Kommunikations-Protokoll(e), und Verbindungen zwischen verschiedenen Geräten können verschiedene Protokolle benutzen, wie in der Technik bekannt ist.
In einer Ausführungsform inkorporiert das Parallel-Verarbeitungs-Subsystem 112 Schaltung, welche für Grafik- und Video-Verarbeitung optimiert ist, einschließlich zum Beispiel Videoausgabe-Schaltung, und konstituiert eine Grafik-Verarbeitungseinheit (GPU). In einer anderen Ausführungsform umfasst das Parallel-Verarbeitungs-Subsystem 112 Schaltung, welche für Allgemeinzweck-Verarbeitung optimiert ist, während die darunter liegende Computer-Architektur, welche im größeren Detail hierin beschrieben ist, beibehalten ist. In noch einer anderen Ausführungsform kann das Parallel-Verarbeitungs-Subsystem 102 mit einem oder mit mehreren anderen Systemelementen in ein einzelnes Subsystem integriert sein, wie etwa die Speicherbrücke 105, CPU 102 und I/O-Brücke 107 verbindend, um ein System auf dem Chip (system on chip) (SoC) zu bilden.
Es wird geschätzt werden, dass das hierin gezeigte System illustrativ ist und dass Variationen und Modifikationen möglich sind. Die Verbindungstopologie, einschließlich der Anzahl und der Anordnung von Brücken, der Anzahl von CPUs 102, und der Anzahl von Parallel-Verarbeitungs-Subsystemen 112 kann wie gewünscht modifiziert werden. Zum Beispiel ist in einigen Ausführungsformen Systemspeicher 104 mit CPU 102 direkt gekoppelt anstatt durch eine Brücke, und andere Geräte kommunizieren mit Systemspeicher 104 über Speicherbrücke 105 und CPU 102. In anderen alternativen Topologien ist das Parallel-Verarbeitungs-Subsystem 112 mit I/O-Brücke 107 oder direkt mit CPU 102 verbunden anstatt mit der Speicherbrücke 105. In noch anderen Ausführungsformen können die I/O-Brücke 107 und Speicherbrücke 105 in einen einzelnen Chip integriert sein, anstatt als ein oder mehr Geräte zu existieren. Große Ausführungsformen können zwei oder mehr CPUs 102 und zwei oder mehr Parallel-Verarbeitungs-Subsysteme 112 umfassen. Die besonderen Komponenten, welche hierin gezeigt sind, sind optional; z. B. könnte irgendeine Anzahl von Hinzufügungskarten oder peripheren Geräten unterstützt sein. In einigen Ausführungsformen ist der Switch 116 eliminiert und der Netzwerkadapter 116 und Hinzufügungskarten 120, 121 verbinden direkt mit der I/O-Brücke 107.
2 illustriert ein Parallel-Verarbeitungs-Subsystem 112 gemäß einer Ausführungsform der vorliegenden Offenbarung. Wie gezeigt, umfasst das Parallel-Verarbeitungs-Subsystem 112 eine oder mehrere Parallel-Verarbeitungseinheiten (PPUs) 202, wobei jede von diesen mit einem lokalen Parallel-Verarbeitungs-(PP)-Speicher 204 gekoppelt ist. Im Allgemeinen umfasst ein Parallel-Verarbeitungs-Subsystem eine Anzahl U von PPUs, wobei U ≥ 1 (hierin sind mehrere Instanzen von ähnlichen Objekten mit Referenznummern bezeichnet, welche das Objekt identifizieren und Nummern in Klammern die Instanz identifizieren, wenn benötigt). PPUs 202 und Parallel-Verarbeitungs-Speicher 204 können unter Benutzung von einem oder mehreren integrierte-Schaltung-Geräten implementiert sein, wie etwa programmierbare Prozessoren, Anwendungs-spezifische integrierte Schaltungen (ASICs), oder Speichergeräte, oder in irgendeiner anderen technisch machbaren Weise.
Mit Bezug wieder auf 1 sowie 2 sind in einigen Ausführungsformen einige oder alle der PPUs 202 in dem Parallel-Verarbeitungs-Subsystem 112 Grafikprozessoren mit Render-Pipelines, welche konfiguriert sein können, um verschiedene Operationen durchzuführen, welche das Erzeugen von Pixeldaten von Grafik-Daten, welche mittels CPU 102 und/oder Systemspeicher 104 über Speicherbrücke 105 und den zweiten Kommunikationspfad 113 zugeführt sind, ein Interagieren mit lokalem Parallel-Verarbeitungs-Speicher 204 (welcher als ein Grafikspeicher benutzt werden kann einschließlich z. B. eines konventionellen Bildpuffers (frame buffer)), um Pixeldaten zu speichern und zu aktualisieren, ein Liefern von Pixeldaten an das Anzeigegeräte 110, und dergleichen betreffen. In einigen Ausführungsformen kann das Parallel-Verarbeitungs-Subsystem 112 eine oder mehrere PPUs 202 umfassen, welche als Grafikprozessoren operieren, und eine oder mehrere andere PPUs 202, welche für Allgemeinzweck-Berechnungen benutzt werden können. Die PPUs können identisch sein oder verschieden sein und jede PPU kann ein dediziertes Parallel-Verarbeitungs-Speichergerät(e) haben oder braucht nicht dedizierte Parallel-Verarbeitungs-Speichergerät(e) zu haben. Eine oder mehrere PPUs 202 in Parallelverarbeitungs-Subsystem 112 können Daten an das Anzeigegeräte 110 ausgeben oder jede PPU 202 Parallelverarbeitungs-Subsystem 112 kann Daten an eines oder mehrere Anzeigegeräte 110 ausgeben.
Im Betrieb ist CPU 102 der Master-Prozessor von Computersystems 100, welcher Operationen von anderen Systemkomponenten steuert und koordiniert. Insbesondere stellt CPU 102 Befehle aus, welche den Betrieb von PPUs 202 steuern. In einigen Ausführungsformen schreibt CPU 102 einen Strom von Befehlen für jede PPU 202 an eine Daten-Struktur (nicht explizit gezeigt in entweder 1 oder 2), welche in System-Speicher 104, Parallel-Verarbeitungs-Speicher 204, oder einer anderen Speicher-Stelle lokalisiert sein kann, welche sowohl für CPU 102 als auch für PPU 202 zugreifbar ist. Ein Zeiger auf jede Daten-Struktur ist an einen Schiebe-Puffer (push buffer) geschrieben, um eine Verarbeitung von dem Strom von Befehlen in der Daten-Struktur zu initiieren. Die PPU 202 liest Befehls-Ströme von einem oder mehr Schiebe-Puffern und führt dann Befehle asynchron relativ zu dem Betrieb von CPU 102 aus. Ausführungs-Prioritäten können für jeden Schiebe-Puffer mittels eines Anwendungs-Programms über den Geräte-Treiber 103 spezifiziert werden, um eine Planung der verschiedenen Schiebe-Puffer zu steuern.
Mit Bezug nun zurück auf 2 sowie 1 umfasst jede PPU 202 eine I/O-(Eingabe/Ausgabe)-Einheit 205, welche mit dem Rest des Computersystems 100 über Kommunikationspfad 113 kommuniziert, welcher zu Speicherbrücke 105 (oder in einer anderen Ausführungsform direkt mit CPU 102) verbindet. Die Verbindung von PPU 202 an den Rest des Computersystems 100 kann auch variiert werden. In einigen Ausführungsformen ist das Parallel-Verarbeitungs-Subsystem 112 als eine Hinzufügungskarte implementiert, welche in einen Erweiterungsschlitz oder Erweiterungssteckplatz (expansion slot) von Computersystem 100 eingeführt werden kann. In anderen Ausführungsformen kann eine PPU 202 auf einem einzelnen Chip integriert sein mit einer Bus-Brücke, wie etwa Speicherbrücke 105 oder I/O-Brücke 107. In noch anderen Ausführungsformen können einige oder alle Elemente von PPU 202 auf einem einzelnen Chip mit CPU 102 integriert sein.
In einer Ausführungsform ist der Kommunikationspfad 113 ein PCI-Express-Link, in welchem dedizierte Spuren oder Bahnen (lanes) an jede PPU 202 alloziert sind, wie es in der Technik bekannt ist. Andere Kommunikationspfade können auch benutzt werden. Eine I/O-Einheit 205 erzeugt Pakete (oder andere Signale) für eine Übermittlung auf Kommunikationspfad 113 und empfängt auch alle einlaufenden oder hereinkommenden (incoming) Pakete (oder andere Signale) von Kommunikationspfad 113, wobei die einlaufenden Pakete zu den geeigneten Komponenten von PPU 202 gerichtet werden. Zum Beispiel können Befehle, welche Verarbeitungs-Aufgaben betreffen, an eine Host-Schnittstelle 206 gerichtet werden, während Befehle, welche Speicher-Operationen betreffen (z. B. Lesen von oder Schreiben auf Parallel-Verarbeitungsspeicher 204) an eine Speicher-Kreuzschiene-Einheit (memory crossbar unit) 202 gerichtet werden können. Host-Schnittstelle 206 liest jeden Push-Puffer und gibt den Befehlsstrom, welches in dem Push-Puffers gespeichert ist, an ein Frontend 212 aus.
Jede PPU 202 implementiert vorteilhafter Weise eine Hochparallel-Verarbeitungs-Architektur. Wie im Detail gezeigt ist, umfasst PPU 202(0) ein Verarbeitungscluster-Feld (processing cluster array) 230, welches eine Anzahl C von Allgemein-Verarbeitungs-Clustern (GPCs) 208 umfasst, wobei C ≥ 1. Jeder GPC 208 ist in der Lage, eine große Anzahl (z. B. Hunderte oder Tausende) von Threads simultan (concurrently) auszuführen, wobei jeder Thread eine Instanz eines Programms ist. In verschiedenen Anwendungen können verschiedene GPCs 208 zur Verarbeitung von verschiedenen Typen von Programmen oder zum Durchführen von verschiedenen Typen von Berechnungen alloziert werden. Die Allozierung von GPCs 208 kann abhängig von der Arbeitsbelastung, welche für jeden Typ von Programm oder Berechnung auftritt, variiert werden.
GPCs 208 empfangen Verarbeitungs-Aufgaben, welche auszuführen sind, von einer Arbeit-Verteilungs-Einheit innerhalb einer Aufgabe-/Arbeit-Einheit 207. Die Arbeit-Verteilungs-Einheit empfängt Zeiger auf Verarbeitungs-Aufgaben, welche als Aufgabe-Metadaten (TMD) kodiert sind und in Speicher gespeichert sind. Die Zeiger auf TMDs sind in dem Befehls-Strom umfasst, welcher als ein Schiebe-Puffer gespeichert ist und mittels der Frontend-Einheit 212 von der Host-Schnittstelle 206 empfangen ist. Verarbeitungs-Aufgaben, welche als TMDs kodiert sein können, umfassen Indizes auf Daten, welche zu prozessieren sind, sowie Status-Parameter und Befehle, welche definieren, wie die Daten zu prozessieren sind (z. B. welches Programm auszuführen ist). Die Aufgabe/Arbeit-Einheit 207 empfängt Aufgaben von dem Frontend 212 und stellt sicher, dass GPCs 208 auf einen gültigen Zustand konfiguriert sind, bevor die Prozessierung, welche mittels jeder der TMDs spezifiziert ist, initiiert ist. Eine Priorität kann für jede TMD spezifiziert sein, welche benutzt ist, Ausführung der Verarbeitungs-Aufgabe zu planen. Verarbeitungs-Aufgaben können auch von dem Verarbeitungs-Cluster-Feld 230 empfangen werden. Optional kann die TMD einen Parameter umfassen, welcher steuert, ob die TMD an den Kopf (head) oder den Schwanz (tail) für eine Liste von Verarbeitungs-Aufgaben hinzugefügt wird (oder eine Liste von Zeigern auf die Verarbeitungs-Aufgaben), wodurch ein anderes Niveau von Steuerung über Priorität bereitgestellt ist.
Speicher-Schnittstelle 214 umfasst ein Anzahl D von Partitions-Einheiten 215, welche jeweils direkt mit einem Teil von Parallel-Verarbeitungs-Speicher 204 gekoppelt sind, wobei D ≥ 1. Wie gezeigt, ist die Anzahl von Partitions-Einheiten 215 im Allgemeinen gleich der Anzahl von dynamischer-willkürlicher-Zugriff-Speicher (DRAM) 220. In anderen Ausführungsformen muss die Anzahl von Partitions-Einheiten 215 nicht gleich der Nummer von Speicher-Geräten sein. Gewöhnliche Fachleute in der Technik werden schätzen, dass DRAM 220 durch irgendwelche anderen geeigneten Speicher-Geräte ersetzt werden kann und von einem im Allgemeinen konventionellen Design sein kann. Eine detaillierte Beschreibung wird daher ausgelassen. Render-Ziele (render targets), wie etwa Frame-Puffer oder Textur-Maps können über DRAMs 220 gespeichert sein, was den Partitions-Einheiten 215 erlaubt, Teile von jedem Render-Target in paralleler Weise zu schreiben, um effektiv die verfügbare Bandbreite von Parallel-Verarbeitungs-Speicher 204 zu nutzen.
Irgendeine von GPCs 208 kann Daten verarbeiten, welche auf irgendeinen der DRAMs 220 innerhalb des Parallel-Verarbeitungs-Speichers 204 zu schreiben sind. Kreuzschiene-Einheit 210 ist konfiguriert, um die Ausgabe von jedem GPC 208 an den Eingang irgendeiner Partitions-Einheit 215 oder an irgendeinen GPC 208 für weitere Verarbeitung zu leiten (route). GPCs 208 kommunizieren mit der Speicher-Schnittstelle 214 durch die Kreuzschiene 210, um von/auf verschiedene externe Speicher-Geräte zu schreiben oder zu lesen. In einer Ausführungsform hat die Kreuzschiene-Einheit 210 eine Verbindung der Speicher-Schnittstelle 214, um mit I/O-Einheit 205 zu kommunizieren, sowie eine Verbindung mit lokalem Parallel-Verarbeitungs-Speicher 204, um dadurch den Verarbeitungs-Kernen innerhalb der verschiedenen GPCs 208 zu ermöglichen, mit dem System-Speicher 104 oder einem anderen Speicher zu kommunizieren, welcher nicht lokal zu der PPU 202 ist. In der in 2B gezeigten Ausführungsform ist die Kreuzschiene-Einheit 210 direkt mit I/O-Einheit 205 verbunden. Kreuzschiene-Einheit 210 kann virtuelle Kanäle benutzen, um Verkehrsströme zwischen den GPCs 208 und den Partitions-Einheiten 215 zu separieren.
Wiederum können GPCs 208 programmiert sein, Verarbeitungs-Aufgaben durchzuführen, welche eine große Verschiedenheit von Anwendungen betreffen, einschließlich aber nicht darauf beschränkt, lineare oder nichtlineare Daten-Transformationen, Filtern von Video- und/oder Audio-Daten, Modellierungs-Operationen (z. B. Anwenden der Gesetze der Physik, um Position, Geschwindigkeit und andere Attribute von Objekten zu bestimmen), Bild-Render-Operationen (z. B. Tessellations-Schattierung, Vertex-Schattierung, Geometrie-Schattierung und/oder Pixel-Schattierungs-Programme), usw. PPUs 202 können Daten von dem System-Speicher 104 und/oder Lokal-Parallel-Verarbeitungs-Speichern 204 in internen (On-Chip)-Speicher transferieren, können die Daten prozessieren, und können Ergebnis-Daten zurück in den System-Speicher 104 und/oder lokalen Parallel-Verarbeitungs-Speicher 204 schreiben, wo auf solche Daten mittels anderer System-Komponenten zugegriffen werden kann, einschließlich CPU 102 oder ein anderes Parallel-Verarbeitungs-Subsystem 112.
Eine PPU 202 kann mit irgendeiner Menge/Umfang (amount) von Lokal-Parallel-Verarbeitungs-Speicher 204 bereitgestellt sein, einschließlich keines Lokal-Speichers, und kann Lokal-Speicher und System-Speicher in irgendeiner Kombination benutzen. Zum Beispiel kann eine PPU 202 ein Grafikprozessor in einer unifizierter-Speicher-Architektur (unified memory architecture) (UMA)-Ausführungsform sein. In solchen Ausführungsformen würde wenig oder kein dedizierter Grafik-(Parallel-Verarbeitungs)-Speicher bereitgestellt sein und PPU 202 würde System-Speicher exklusiv oder fast exklusiv benutzen. In UMA-Ausführungsformen kann eine PPU 202 in einen Brücken-Chip oder Prozessor-Chip integriert sein oder als ein diskreter Chip bereitgestellt sein mit einem Hochgeschwindigkeits-Link (z. B. PCI-Express), welcher die PPU 202 mit System-Speicher über einen Brücke-Chip oder ein anderes Kommunikations-Mittel verbindet.
Wie oben bemerkt ist, kann irgendeine Anzahl von PPUs 202 in einem Parallel-Verarbeitungs-Subsystem 112 umfasst sein. Zum Beispiel können mehrere PPUs 202 auf einer einzelnen Hinzufügungskarte bereitgestellt sein oder mehrere Hinzufügungskarten können mit dem Kommunikationspfad 113 verbunden sein oder eine oder mehrere der PPUs 202 können in einen Brücken-Chip integriert sein. PPUs 202 in einem Mehr-PPU-System können identisch sein oder verschieden voneinander sein. Zum Beispiel könnten verschiedene PPUs 202 verschiedene Anzahlen von Verarbeitungs-Kernen haben, verschiedene Mengen oder Größen von Lokal-Parallel-Verarbeitungs-Speicher, usw. Wo mehrere PPUs 202 vorhanden sind, können diese PPUs in paralleler Weise betrieben werden, um Daten bei einem höheren Durchsatz zu verarbeiten als es mit einer einzelnen PPU 202 möglich ist. Systeme, welche eine oder mehrere PPUs 202 inkorporieren, können in einer Verschiedenheit von Konfigurationen und Formfaktoren implementiert sein, einschließlich Schreibtisch-Computer, Laptop-Computer, oder handgehaltenen Personal-Computern, Servern, Arbeitsstationen, Spielekonsolen, eingebetteten Systemen und dergleichen.
Mehrfach-gleichzeitiges-Aufgabe-Planen
Mehrere Verarbeitungs-Aufgaben können gleichzeitig auf den GPCs 208 ausgeführt werden und eine Verarbeitungs-Aufgabe kann eine oder mehr „Kind”-Verarbeitungs-Aufgaben während der Ausführung erzeugen. Die Aufgabe-/Arbeit-Einheit 207 empfängt die Aufgaben und plant dynamisch die Verarbeitungs-Aufgaben und Kind-Verarbeitungs-Aufgaben zur Ausführung mittels der GPCs 208.
3A ist ein Blockdiagramm der Aufgabe-/Arbeit-Einheit 207 von 2 gemäß einer Ausführungsform der vorliegenden Offenbarung. Die Aufgabe-/Arbeit-Einheit 207 umfasst eine Aufgabe-Management-Einheit 300 und die Arbeit-Verteilungs-Einheit 340. Die Aufgabe-Management-Einheit 300 organisiert Aufgaben, welche zu planen sind, basierend auf Ausführungs-Prioritäts-Niveaus. Für jedes Prioritäts-Niveau speichert die Aufgabe-Management-Einheit 300 eine Liste von Zeigern auf die TMDs 322, welche den Aufgaben entsprechen, in der Planer-Tabelle 321, wobei die Liste als eine verkettete Liste (linked list) implementiert sein kann. Die TMDs 322 können in dem PP-Speicher 204 oder System-Speicher 104 gespeichert sein. Die Rate, bei welcher die Aufgabe-Management-Einheit 300 Aufgaben annimmt und die Aufgaben in der Planer-Tabelle 321 speichert, ist entkoppelt von der Rate, bei welcher die Aufgabe-Management-Einheit 300 Aufgaben zur Ausführung plant. Daher kann die Aufgabe-Management-Einheit 300 einige Aufgaben sammeln, bevor die Aufgaben geplant werden. Die gesammelten Aufgaben können dann basierend auf Prioritäts-Information oder unter Benutzung anderer Techniken, wie etwa Ring-Verteilungs-Planung (round-robin), geplant werden.
Die Arbeit-Verteilungs-Einheit 340 umfasst eine Aufgabe-Tabelle 345 mit Fächern (slots), welche jeweils von einer TMD 322 für eine Aufgabe besetzt sein können, welche ausgeführt wird. Die Aufgabe-Management-Einheit 300 kann Aufgaben zur Ausführung planen, wenn es ein freies Fach in der Aufgabe-Tabelle 345 gibt. Wenn es kein freies Fach gibt, kann eine höhere-Priorität-Aufgabe, welche kein Fach besetzt, eine niedrigere Priorität-Aufgabe verdrängen oder ausschließen (evict), welche ein Fach besetzt. Wenn eine Aufgabe ausgeschlossen wird, wird die Aufgabe gestoppt und wenn Ausführung der Aufgabe nicht vollständig ist, dann wird ein Zeiger auf die Aufgabe an eine Liste von Aufgabe-Zeigern, welche auszuführen sind, so hinzugefügt, dass Ausführung der Aufgabe zu einer späteren Zeit wieder aufnehmen. Wenn eine Kind-Verarbeitungs-Aufgabe erzeugt ist, während einer Ausführung einer Aufgabe, wird ein Zeiger auf die Kind-Aufgabe an die Liste von Aufgabe-Zeigern, welche zu planen sind, hinzugefügt. Eine Kind-Aufgabe kann mittels einer TMD 322 erzeugt sein, welche in dem Verarbeitungs-Cluster-Feld 230 ausführt.
Unähnlich einer Aufgabe, welche mittels der Aufgabe-/Arbeit-Einheit 207 von dem Frontend 212 empfangen wird, werden Kind-Aufgaben von dem Verarbeitungs-Cluster-Feld 230 empfangen. Kind-Aufgaben werden nicht in Schiebe-Puffer eingefügt oder an das Frontend übermittelt. Die CPU 102 wird nicht benachrichtigt, wenn eine Kind-Aufgabe erzeugt ist oder Daten für die Kind-Aufgabe im Speicher gespeichert werden. Ein anderer Unterschied zwischen den Aufgaben, welche durch Schiebe-Puffer bereitgestellt sind, und Kind-Aufgaben ist, dass die Aufgaben, welche durch die Schiebe-Puffer bereitgestellt sind, mittels des Anwendungs-Programms definiert sind, wogegen die Kind-Aufgaben dynamisch während einer Ausführung der Aufgaben erzeugt sind.
Aufgabe-Verarbeitung-Überblick
3B ist ein Blockdiagramm eines GPC 208 innerhalb einer der PPUs 202 der 2, gemäß einer Ausführungsform der vorliegenden Erfindung. Jeder GPC 208 kann konfiguriert sein, eine große Anzahl von Threads parallel auszuführen, wobei der Ausdruck „Thread” sich auf eine Instanz eines bestimmten Programms bezieht, welches auf einem bestimmten Satz von Eingabe-Daten ausführt. In einigen Ausführungsformen werden Einzel-Anweisung-, Mehr-Daten-(SIMD)-Befehls-Ausstellungs-Techniken benutzt, um eine parallele Ausführung einer großen Anzahl von Threads zu unterstützen, ohne mehrere unabhängige Anweisungs-Einheiten bereitzustellen. In anderen Ausführungsformen werden Einzel-Anweisung-, Mehrfach-Thread-(SIMT)-Techniken benutzt, um eine parallele Ausführung einer großen Anzahl von im Allgemeinen synchronisierten Threads zu unterstützen, unter Benutzung einer gemeinsamen Anweisungs-Einheit, welche konfiguriert ist, Anweisungen für einen Satz von Verarbeitungs-Maschinen innerhalb jedes der GPCs 208 auszustellen (issue). Unähnlich zu einem SIMD-Ausführungs-Regime, wobei alle Verarbeitungs-Maschinen typischerweise identische Anweisungen ausführen, erlaubt eine große SIMT-Ausführung verschiedenen Threads, leichter divergenten Ausführungspfaden durch ein gegebenes Thread-Programm zu folgen. Gewöhnliche Fachleute in der Technik werden verstehen, dass ein SIMD-Verarbeitungs-Regime eine funktionale Untermenge eines SIMT-Verarbeitungs-Regimes repräsentiert.
Betrieb von GPC 208 wird vorteilhafterweise über einen Pipeline-Manager 305 gesteuert, welcher Verarbeitungs-Aufgaben an Strömungs-Mehrfach-Prozessoren (streaming multiprocessors) (SMs) 310 verteilt. Pipeline-Manager 305 kann auch konfiguriert sein, eine Arbeitsverteilungs-Kreuzschiene (work distribution crossbar) 330 dadurch zu steuern, dass Ziele (destinations) für prozessierte Daten-Ausgaben mittels SMs 310 spezifiziert sind.
In einer Ausführungsform umfasst jede GPC 208 eine Anzahl M von SMs 310, wobei M ≥ 1, wobei jeder SM 310 konfiguriert ist, eine oder mehrere Thread-Gruppen zu verarbeiten. Auch umfasst jeder SM 310 vorteilhafterweise einen identischen Satz von funktionalen Ausführungseinheiten (z. B. Ausführungseinheiten und Lade-Speicher-Einheiten – gezeigt als Exec-Einheiten 302 und LSUs 303 in 3C), welche in einer Pipeline angeordnet sein können (pipelined), was erlaubt, eine neue Anweisung auszustellen, bevor eine vorherige Anweisung beendet worden ist, wie es in der Technik bekannt ist. Irgendeine Kombination von funktionalen Ausführungs-Einheiten kann bereitgestellt sein. In einer Ausführungsform unterstützen die funktionalen Einheiten eine Verschiedenheit von Operationen, einschließlich Ganzzahl-Arithmetik und Gleitzahl-Arithmetik (z. B. Addition und Multiplikation), Vergleichs-Operationen, Bool'sche Operationen (AND, OR, XOR), Bit-Verschiebung und Berechnen von verschiedenen algebraischen Funktionen (z. B. planare Interpolation, trigonometrische, exponentiale und logarithmische Funktionen); und dieselbe Funktional-Einheit-Hardware kann eingesetzt werden, um verschiedene Operationen durchzuführen.
Die Serie von Anweisungen, welche an eine bestimmte GPC 208 übermittelt wird, konstituiert einen Thread, wie vorher hierin definiert ist, und die Sammlung einer gewissen Anzahl von simultan ausführenden Threads über die Parallel-Verarbeitungs-Maschinen (nicht gezeigt) innerhalb eines SM 310 wird hierin als ein „Warp” oder „Thread-Gruppe” bezeichnet. Wie hierin benutzt, bezeichnet eine „Thread-Gruppe” eine Gruppe von Threads, welche simultan dasselbe Programm auf verschiedenen Eingabe-Daten ausführen, wobei ein Thread der Gruppe an eine verschiedene Verarbeitungs-Maschine innerhalb eines SM 310 zugewiesen ist. Eine Thread-Gruppe kann weniger Threads umfassen als die Anzahl von Verarbeitungs-Einheiten innerhalb des SM 310, in welchem Fall einige Verarbeitungs-Maschinen während Zyklen untätig sein werden, wenn diese Thread-Gruppe verarbeitet wird. Eine Thread-Gruppe kann auch mehr Threads umfassen als die Anzahl von Verarbeitungs-Maschinen innerhalb des SM 310, in welchem Fall die Verarbeitung über nachfolgende Taktzyklen stattfinden wird. Da jeder SM 310 bis zu G Thread-Gruppen gleichzeitig unterstützen kann, folgt, dass bis zu G·M Thread-Gruppen zu einer gegebenen Zeit in GPC 208 ausführen können.
Zusätzlich kann eine Mehrzahl von bezogenen Thread-Gruppen aktiv sein, in verschiedenen Phasen einer Ausführung, zu derselben Zeit innerhalb eines SPM 310. Diese Sammlung von Thread-Gruppen wird hierin als ein „kooperatives Thread-Feld” (cooperative thread array) („CTA”) oder „Thread-Feld” bezeichnet. Die Größe eines bestimmten CTA ist m·k, wobei k die Anzahl von gleichzeitig ausführenden Threads in einer Thread-Gruppe ist und typischerweise ein ganzzahliges Vielfaches der Anzahl von Parallel-Verarbeitungs-Einheiten innerhalb des SM 310 ist, und wobei m die Anzahl von Thread-Gruppen ist, welche simultan innerhalb des SM 310 aktiv sind. Die Größe eines CTA ist im Allgemeinen mittels des Programmierers bestimmt und mittels der Menge von Hardware-Ressourcen, wie Speicher oder Register, welche für das CTA verfügbar sind.
Jeder SM 310 beinhaltet einen Level-eins(L1)-Cache (in 3C gezeigt) oder benutzt Raum (space) in einem entsprechenden L1-Cache außerhalb des SM 310, welcher benutzt ist, um Lade- und Speicher-Operationen durchzuführen. Jeder SM 310 hat auch Zugriff auf Level-zwei(L2)-Caches, welche unter allen GPCs 208 gemeinsam benutzt oder geteilt sind (shared) und benutzt werden können, um Daten zwischen Threads zu transferieren. Schließlich haben die SMs 310 Zugriff auf Off-Chip „globalen” Speicher, welcher z. B. Parallel-Verarbeitungs-Speicher 204 oder System-Speicher 104 umfassen kann. Es ist verstanden, dass irgendein Speicher extern zu PPU 202 als globaler Speicher benutzt werden kann. Zusätzlich kann ein Level-eins-Komma-fünf(L1.5)-Cache 335 innerhalb des GPC 208 umfasst sein, welcher konfiguriert ist, Daten zu empfangen und zu halten, welche von dem Speicher über Speicher-Schnittstelle 214 geholt sind, abgefragt mittels SM 310, einschließlich Anweisungen, uniforme Daten und konstante Daten, und die angefragten Daten an SM 310 bereitzustellen. Ausführungsformen, welche mehrere SMs 310 in GPC 208 haben, teilen oder benutzen gemeinsam (share) in vorteilhafter Weise gemeinsame Anweisungen und Daten, welche in L1.5-Cache 335 gecached sind.
Jeder GPC 208 kann eine Speicher-Management-Einheit (MMU) 328 umfassen, welche konfiguriert ist, virtuelle Adressen in physikalische Adressen abzubilden (map). In anderen Ausführungsformen, können MMU(s) 328 innerhalb der Speicher-Schnittstelle 214 ansässig sein (reside). Die MMU 328 umfasst einen Satz von Seite-Tabelle-Einträgen (page table entry) (PTEs), welche benutzt werden, um eine virtuelle Adresse in eine physikalische Adresse einer Kachel (tile) und optional einen Cache-Zeilen-Index abzubilden. Die MMU 328 kann Adresse-Übersetzungs-Puffer (translation lookaside buffer) (TLB) oder Caches umfassen, welche innerhalb des Mehrfach-Prozessors SM 310 oder dem L1-Cache oder GPC 208 ansässig sein können. Die physikalische Adresse ist verarbeitet, um Oberflächendaten-Zugriffslokalität zu verteilen, um eine effiziente Abfrage-Verschachtelung (interleaving) unter Partitions-Einheiten 215 zu erlauben. Der Cache-Zeile-Index kann benutzt werden, um zu bestimmen, ob eine Anfrage nach einer Cache-Zeile ein Treffer ist oder eine Verfehlung ist oder nicht.
In Grafik- und Berechnungs-Anwendungen kann eine GPC 208 derart konfiguriert sein, dass jeder SM 310 mit einer Textur-Einheit 315 zum Durchführen von Textur-Abbildungs-Operationen gekoppelt ist, z. B. Bestimmen von Textur-Proben-Positionen (texture sample position), Lesen von Textur-Daten und Filtern der Textur-Daten. Textur-Daten werden von einem internen Textur-L1-Cache (nicht gezeigt) oder in einigen Ausführungsformen von dem L1-Cache innerhalb von SM 310 gelesen und werden von einem L2-Cache, welcher unter allen GPCs 208 geteilt ist, Parallel-Verarbeitungs-Speicher 204 oder System-Speicher 104 wie benötigt geholt. Jeder SPM 310 gibt verarbeitete Aufgaben an die Arbeits-Verteilungs-Kreuzschiene 330 aus, um die verarbeitete Aufgabe an einen anderen GPC 208 für weitere Verarbeitung bereitzustellen oder um die verarbeitete Aufgabe in einem L2-Cache, Parallel-Verarbeitungs-Speicher 204 oder System-Speicher 104 über Kreuzschiene-Einheit 210 zu speichern. Ein preROP (Vorraster-Operationen) 325 ist konfiguriert, um Daten von SM 310 zu empfangen, Daten an ROP-Einheiten innerhalb der Partitions-Einheiten 215 zu richten, und Optimierungen für Farbmischung durchzuführen, Pixel-Farbdaten zu organisieren und Adress-Translationen durchzuführen.
Es wird geschätzt werden, dass die hierin beschriebene Kern-Architektur illustrativ ist und dass Variationen und Modifikationen möglich sind. Irgendeine Anzahl von Verarbeitungs-Einheiten, z. B. SPMs 310 oder Textur-Einheiten 315, preROPs 325, können innerhalb eines GPC 208 umfasst sein kann. Ferner, wie in 2 gezeigt ist, kann eine PPU 202 irgendeine Anzahl von GPCs 208 umfassen, welche vorteilhafterweise funktionell ähnlich zueinander sind, so dass ein Ausführungs-Verhalten nicht davon abhängt, welcher GPC 208 eine bestimmte Verarbeitungs-Aufgabe empfängt. Ferner operiert jeder GPC 208 vorteilhafterweise unabhängig von anderen GPCs 208 unter Benutzung von separaten und distinkten Verarbeitungs-Einheiten L1-Caches, usw., um Aufgaben für ein oder mehr Anwendungsprogramme auszuführen.
Gewöhnliche Fachleute in der Technik werden verstehen, dass die in 1, 2, 3A und 3B beschriebene Architektur in keiner Weise den Geltungsbereich der vorliegenden Erfindung begrenzt und dass die hierin gelehrten Techniken auf irgendeiner korrekt konfigurierten Verarbeitungs-Einheit implementiert werden können, einschließlich ohne Begrenzung eine oder mehrere CPUs, eine oder mehrere Mehr-Kern-CPUs, eine oder mehrere PPUs 202, ein oder mehrere GPCs 208, eine oder mehrere Grafik- oder Spezialzweck-Verarbeitungs-Einheiten, oder dergleichen, ohne von dem Geltungsbereich der vorliegenden Erfindung abzuweichen.
In Ausführungsformen der vorliegenden Erfindung ist es wünschenswert, die PPU 202 oder andere Prozessor(en) eines Computer-Systems zu benutzen, um Allgemeinzweck-Berechnungen unter Benutzung von Thread-Feldern auszuführen. Jedem Thread in dem Thread-Feld ist ein eindeutiger Thread-Identifikator („Thread-ID”) zugewiesen, welcher für den Thread während Ausführung des Threads zugreifbar ist. Die Thread-ID, welche als ein eindimensionaler oder mehrdimensionaler numerischer Wert definiert werden kann, steuert verschiedene Aspekte des Verarbeitungs-Verhaltens des Threads. Zum Beispiel kann eine Thread-ID benutzt werden, um zu bestimmen, welchen Teil des Eingabe-Datensatzes ein Thread zu prozessieren hat, und/oder zu bestimmen, welchen Teil eines Ausgabe-Datensatzes ein Thread zu erzeugen hat oder zu schreiben hat.
Eine Sequenz von Pro-Thread-Anweisungen kann zumindest eine Anweisung umfassen, welche ein kooperatives Verhalten zwischen dem repräsentativen Thread und einem oder mehreren anderen Threads des Thread-Feldes definiert. Zum Beispiel könnte die Sequenz von Pro-Thread-Anweisungen eine Anweisung umfassen, um eine Ausführung von Operationen für den repräsentativen Thread bei einem bestimmten Punkt in der Sequenz anzuhalten (suspend), bis zu einer solchen Zeit, wenn einer oder mehrere der anderen Threads diesen bestimmten Punkt erreichen, eine Anweisung für den repräsentativen Thread, Daten in einem gemeinsamen Speicher zu speichern, auf welchen einer oder mehrere der anderen Threads zugreifen können, eine Anweisung für den repräsentativen Thread, um atomar Daten zu lesen und zu aktualisieren, welche in einem gemeinsamen Speicher gespeichert sind, auf welchen einer oder mehrere der anderen Threads Zugriff haben, basierend auf ihren Thread-IDs, oder dergleichen. Das CTA-Programm kann auch eine Anweisung umfassen, um eine Adresse in dem gemeinsamen Speicher zu berechnen, von welchem Daten zu lesen sind, wobei die Adresse eine Funktion der Thread-ID ist. Mittels eines Definierens von geeigneten Funktionen und mittels eines Bereitstellens von Synchronisations-Techniken können Daten auf eine bestimmte Stelle in dem gemeinsamen Speicher mittels eines Threads eines CTA geschrieben werden und von dieser Stelle mittels eines verschiedenen Threads desselben CTA in einer vorhersagbaren Weise gelesen werden. Folglich kann irgendein gewünschtes Muster von Daten-gemeinsam-Benutzen (data sharing) unter Threads unterstützt werden, und irgendein Thread in einem CTA kann mit irgendeinem anderen Thread in demselben CTA Daten gemeinsam nutzen bzw. teilen (share). Das Ausmaß, wenn überhaupt, eines gemeinsamen Benutzens von Daten unter Threads eines CTA ist mittels des CTA-Programms bestimmt; somit wird verstanden, dass in einer bestimmten Anwendung, welche CTAs benutzt, die Threads eines CTA tatsächlich Daten miteinander teilen bzw. benutzen könnten oder nicht, abhängig von dem CTA-Programm, und die Ausdrucke „CTA” und „Thread-Feld” werden hierin synonym benutzt.
3C ist ein Blockdiagramm des SM 310 von 3B gemäß einer Ausführungsform der vorliegenden Offenbarung. Der SM 310 umfasst einen Anweisungs-L1-Cache 370, welcher konfiguriert ist, Anweisungen und Konstanten von Speicher über L1.5-Cache 335 zu empfangen. Eine Warp-Planer-(warp scheduler) und -Anweisungs-Einheit 312 empfängt Anweisungen und Konstanten von dem Anweisungs-L1-Cache 370 und steuert eine lokale Register-Datei 304 und SM 310 funktionale Einheiten gemäß den Anweisungen und Konstanten. Die SM 310 funktionalen Einheiten umfassen N exec(Ausführung- oder Verarbeitung-)-Einheiten 302 und P Lade-Speicher-Einheiten (LSU) 303.
SM 310 stellt Auf-Chip-(on-chip)-(internen)-Daten-Speicher mit verschiedenen Zugriffs-Niveaus bereit. Spezielle Register (nicht gezeigt) sind lesbar aber nicht schreibbar mittels LSU 303 und werden benutzt, um Parameter zu speichern, welche eine „Position” jedes Threads definieren. In einer Ausführungsform umfassen spezielle Register ein Register pro Thread (oder pro exec-Einheit 302 innerhalb SM 310), welches eine Thread-ID speichert; jedes Thread-ID-Register ist nur mittels einer jeweiligen der exec-Einheit 302 zugreifbar. Spezielle Register können auch zusätzliche Register umfassen, welche mittels aller Threads lesbar sind, welche dieselbe Verarbeitungs-Aufgabe ausführen, welche mittels einer TMD 322 repräsentiert ist (oder mittels aller LSUs 303), welche einen CTA-Identifikator, die CTA-Dimensionen, die Dimensionen eines Gitters, zu welchem die oder das CTA gehört (oder Queue-Position, wenn die TMD 322 eine Queue-Aufgabe anstatt einer Gitter-Aufgabe kodiert), und einen Identifikator der TMD 322, an welche das CTA zugewiesen ist, speichert.
Wenn die TMD 322 eine Gitter-TMD ist, führt eine Ausführung der TMD 322 dazu, dass eine fixe Anzahl von CTAs angestoßen wird und ausgeführt wird, um die fixe Menge von Daten zu verarbeiten, welche in der Queue 525 gespeichert sind. Die Anzahl von CTAs ist als das Produkt der Gitter-Breite, -Höhe und -Tiefe spezifiziert. Die fixe Menge von Daten kann in der TMD 322 gespeichert werden oder die TMD 322 kann einen Zeiger auf die Daten speichern, welche mittels der CTAs verarbeitet werden. Die TMD 322 speichert auch eine Start-Adresse des Programms, welches mittels der CTAs ausgeführt ist.
Wenn die TMD 322 eine Queue-TMD ist, dann wird ein Queue-Merkmal der TMD 322 benutzt, was bedeutet, dass die Menge von zu prozessierenden Daten nicht notwendiger Weise fix ist. Queue-Einträge speichern Daten zur Verarbeitung mittels der CTAs, welche der TMD 322 zugewiesen sind. Die Queue-Einträge können auch eine Kind-Aufgabe repräsentieren, welche mittels einer anderen TMD 322 während einer Ausführung eines Threads erzeugt ist, wodurch ein geschachtelter Parallelismus bereitgestellt ist. Typischerweise wird Ausführung des Threads, oder des CTA, welches den Thread umfasst, angehalten oder unterbrochen (suspended), bis Ausführung der Kind-Aufgabe vollendet. Die Queue kann in der TMD 322 gespeichert sein oder separat von der TMD 322, in welchem Fall die TMD 322 einen Queue-Zeiger auf die Queue speichert. Vorteilhafter Weise können Daten, welche mittels der Kind-Aufgabe erzeugt sind, an die Queue geschrieben werden, während die TMD 322, welche die Kind-Aufgabe repräsentiert, ausführt. Die Queue kann als eine zirkuläre Queue implementiert sein, so dass die gesamte Menge von Daten nicht auf die Größe der Queue begrenzt ist.
CTAs, welche zu einem Gitter gehören, haben implizit Gitter-Breite-, -Höhe- und -Tiefe-Parameter, welche die Position des entsprechenden CTA innerhalb des Grids anzeigen. Spezielle Register werden während einer Initialisierung in Antwort auf Befehle geschrieben, welche über Frontend 212 von Geräte-Treiber 103 empfangen sind und ändern sich nicht während der Ausführung einer Verarbeitungs-Aufgabe. Das Frontend 212 plant jede Verarbeitungs-Aufgabe zur Ausführung. Jedes CTA ist mit einer spezifischen TMD 322 zur gleichzeitigen Ausführung von einer oder mehr Aufgaben assoziiert. Zusätzlich kann ein einzelnes GPC 208 mehrere Aufgaben gleichzeitig ausführen.
Ein Parameter-Speicher (nicht gezeigt) speichert Laufzeit-Parameter (Konstanten), welche gelesen werden können aber welche nicht mittels irgendeines Threads innerhalb desselben CTA (oder irgendeiner LSU 303) geschrieben werden können. In einer Ausführungsform stellt der Gerätetreiber 103 Parameter für den Parameter-Speicher bereit, bevor der SM 310 darauf gerichtet wird, eine Ausführung einer Aufgabe zu beginnen, welche diese Parameter benutzt. Irgendein Thread innerhalb irgendeines CTA (oder irgendeine exec-Einheit 302 innerhalb SM 310) kann auf globalen Speicher durch eine Speicher-Schnittstelle 214 zugreifen. Teile von globalem Speicher können in dem L1-Cache 320 gespeichert sein.
Lokale Register-Datei 304 ist mittels jedes Threads als ein Notizzettel-Raum (scratch spase) benutzt; jedes Register wird für die exklusive Benutzung eines Threads alloziert und Daten in irgendeiner Register-Datei 304 sind nur von dem Thread zugreifbar, an welchen das Register alloziert ist. Die lokale Register-Datei 304 kann als eine Register-Datei implementiert sein, welche physikalisch oder logisch in P Spuren oder Bahnen aufgeteilt ist, wobei jede irgendeine Anzahl von Einträgen hat (wobei jeder Eintrag z. B. ein 32-Bit-Wort speichern könnte), was unten im Detail in Zusammenhang mit 5 bis 8 beschrieben ist. Eine Spur (lane) ist jeder der N exec-Einheiten 302 und P Lade-Speicher-Einheiten LSU 303 zugewiesen und entsprechende Einträge in verschiedenen Spuren können mit Daten für verschiedene Threads populiert sein, welche dasselbe Programm ausführen, um eine SIMD-Ausführung zu ermöglichen. Verschiedene Teile der Spuren können an verschiedene der G gleichzeitigen Thread-Gruppen alloziert sein, so dass ein gegebener Eintrag in der lokalen Register-Datei 304 nur für einen bestimmten Thread zugreifbar ist. In einer Ausführungsform werden gewisse Einträge innerhalb der lokalen Register-Datei 304 zum Speichern von Thread-Identifikatoren reserviert, welche eines der speziellen Register implementieren. Zusätzlich speichert ein L1-Cache 375 uniforme oder konstante Werte für jede Spur der N exec-Einheiten 302 und P Lade-Speicher-Einheiten LSU 303.
Gemeinsamer Speicher 306 ist für alle Threads (innerhalb eines einzelnen CTA) zugreifbar; mit anderen Worten, ist irgendeine Stelle in dem gemeinsamen Speicher 306 für irgendeinen Thread innerhalb desselben CTA zugreifbar (oder für irgendeine Verarbeitungs-Maschine innerhalb SM 310). Der gemeinsame Speicher 306 kann als eine gemeinsam benutzte oder geteilte (shared) Register-Datei oder ein gemeinsamer On-Chip-Cache-Speicher implementiert sein mit einer Zwischenverbindung, welche irgendeiner Verarbeitungs-Maschine erlaubt, von oder auf irgendeine Stelle in dem gemeinsamen Speicher zu lesen oder zu schreiben. In anderen Ausführungsformen könnte der gemeinsame Zustandsraum (shared state space) auf eine Pro-CTA-Region von Off-Chip-Speicher abbilden und könnte in L1-Cache 320 gecached sein. Der Parameter-Speicher kann als ein designierter Abschnitt innerhalb derselben gemeinsamen Register-Datei oder des gemeinsamen Cache-Speichers implementiert sein, welcher den gemeinsamen Speicher 306 implementiert, oder als eine separate gemeinsame Register-Datei oder ein On-Chip-Cache-Speicher, auf welchen die LSUs 303 nur-Lese-Zugriff haben. In einer Ausführungsform ist der Bereich, welcher den Parameter-Speicher implementiert, auch dazu benutzt, um die CTA-ID und die Aufgabe-ID zu speichern, sowie CTA- und Gitter-Dimensionen oder Queue-Position, wobei Teile der speziellen Register implementiert sind. Jede LSU 303 in SM 310 ist mit einer unifizierten Adress-Abbildungs-Einheit 352 gekoppelt, welche eine Adresse, welche für Lade- und Speicher-Befehle bereitgestellt ist, welche in einem unifizierten Speicher-Raum spezifiziert ist, in eine Adresse in jedem distinkten Speicherraum zu konvertieren. Folglich kann eine Anweisung genutzt werden, um auf irgendwelche der lokalen, gemeinsamen oder globalen Speicherräume dadurch zuzutreiben, dass eine Adresse in dem unifizierten Speicherraum spezifiziert wird.
Der L1-Cache 320 in jedem SM 310 kann benutzt werden, um private Pro-Thread-lokale-Daten und auch Pro-Applikation-globale-Daten zu cachen. In einigen Ausführungsformen können die Pro-CTA-geteilten Daten in dem L1-Cache 320 gecached werden. Die LSUs 303 sind mit dem gemeinsamen Speicher 306 und dem L1-Cache 320 über eine Speicher- und Cache-Zwischenverbindung 380 gekoppelt.
Gestaltete Register-Datei-Lese-Operation
4 ist ein Blockdiagramm des SM 310 von 3B gemäß einer anderen Beispiel-Ausführungsform der vorliegenden Offenbarung. Obwohl nicht explizit gezeigt, kann SM 310 von 4 einige oder alle der Komponenten von SM 310 von 3C, oben beschrieben, zusätzlich zu den Komponenten, welche explizit in 4 gezeigt sind, beinhalten. Wie in 4 gezeigt ist, umfasst SM 310 die Warp-Planungs- und -Anweisungs-Einheit 312, die lokale Register-Datei 304 und eine oder mehr Ausführungs-Einheiten 302. Warp-Planungs- und -Anweisungs-Einheit 312 umfasst eine Dekodier-Einheit 450 und eine Absetz-Einheit (dispatch unit) 470. Dekodier-Einheit 450 empfängt eine nächste Anweisung, welche an Ausführungs-Einheit 302 abzusetzen ist. Die Dekodier-Einheit 450 führt ein vollständiges Dekodieren der Anweisung durch und übermittelt die dekodierte Anweisung an die Absetz-Einheit 470. Zum Beispiel wird die Dekodier-Einheit 450 den bestimmten Typ von Anweisung, welcher mittels eines Opcodes in der Anweisung spezifiziert ist, bestimmen und die bestimmten lokale-Register-Datei 304-Indizes, welches als Operanden für die Anweisung spezifiziert sind, sowie einen Register-Index zum Speichern des Resultats einer Anweisung. In einigen Ausführungsformen können Anweisungen zweifach oder vierfach (dual or quad) ausgestellt werden und die Dekodier-Einheit 450 kann separate Dekodier-Logik für jede ausgestellte Anweisung implementieren. Absetz-Einheit 470 implementiert einen FIFO und schreibt die dekodierten Werte an lokale Register-Datei 304 zur Ausführung. In Ausführungsformen, welche mehrere Anweisungen gleichzeitig ausstellen, kann Absetz-Einheit 470 jede Anweisung an einen anderen Teil der Ausführungs-Einheiten 302 von SM 310 ausstellen.
In eine Ausführungsform umfasst die lokale Register-Datei 304 vier Banken von Registern (bank_0 422, bank_1 424, bank_2 426 und bank_3 428). In den meisten herkömmlichen Verarbeitungs-Einheiten kann die lokale Register-Datei 304 ziemlich klein sein. Zum Beispiel umfasst die x86-CPU-Architektur 8 (32-Bit) oder 16 (64-Bit) Register pro Prozessor-Kern. Im Gegensatz dazu kann jede Bank von lokaler Register-Datei 304 eine große Anzahl von Registern umfassen, welche verfügbar zur Benutzung als Eingaben für die Ausführungs-Einheiten 302 sind, wie im Detail unten im Zusammenhang mit 5 bis 8 beschrieben ist. Kreuzschiene 420 ist konfiguriert, die verschiedenen Register in jeder der Register-Banken an Ausführungs-Einheit 302 zu verbinden, welche einen Daten-Pfad zur Durchführung einer Operation implementiert. In einer Ausführungsform umfasst der Daten-Pfad einen Operand-Kollektor 440, eine arithmetisch-logische-Einheit (ALU) 452 und ein Ergebnis-FIFO 454. In einer Ausführungsform umfasst Operand-Kollektor 440 eine Mehrzahl von Speicher-Elementen, welche mit den Eingängen von der ALU 452 gekoppelt sein können. Jedes der Speicher-Elemente kann ein Flipflop, ein Latch oder irgendeine andere technisch machbare Schaltungs-Komponente sein, welche in der Lage ist, temporär einen Wert zu speichern, um ihn als eine Eingabe an die ALU 452 zuzuführen. Die Ausgaben oder Ausgänge (outputs) der Speicher-Elemente können mit den Schaltungs-Elementen hartverdrahtet sein, welche die ALU 452 aufweisen, wie etwa eine Addier-Schaltung oder eine Fließpunkt-Multiplikator-Schaltung. Wie gezeigt ist, ist die Ausgabe von ALU 452 in den Ergebnis-FIFO 454 eingegeben, so dass arithmetische Ergebnisse von der ALU 452 erneut benutzt werden können oder nachfolgend zurück in Speicher gespeichert werden können, z. B. gemeinsam bzw. geteilten (shared) Speicher 306 über Speicher- und Zwischenspeicher-Zwischenverbindung 380.
In konventionellen Prozessor-Designs, welche relativ kleine Register-Dateien umfassen, kann eine Kreuzschiene oder eine andere Zwischen-Verbindung konfiguriert sein, irgendein Register in einer lokalen Register-Datei mit irgendeiner der Daten-Pfad-Eingaben bzw. -Eingänge während eines einzelnen Taktzyklus zu koppeln. Ferner kann in herkömmlichen Prozessoren eine Zahl von Registern, wobei die Zahl gleich der Zahl von Eingängen für den Daten-Pfad ist, simultan mit irgendwelchen der Daten-Pfad-Eingaben bzw. -Eingänge in einem einzelnen Taktzyklus verbunden sein. Es wird geschätzt werden, dass ein Erhöhen der Größe der lokalen Register-Datei 304 über 8 oder 16 Register die Komplexität von Kreuzschiene 420 erhöhen kann.
5 illustriert eine detaillierte Ansicht 500 der lokalen Register-Datei 403 gemäß einer Ausführungsform der vorliegenden Offenbarung. Wie in 5 gezeigt ist, ist die bank_0 (422) in bank_0.a (422-1) und bank_0.b (422-2) Unter-Banken separiert, die bank_1 (424) ist in bank_1.a (424-1) und bank_1.b (424-2) Unter-Banken separiert, die bank_2 (426) ist in bank_2.a (426-1) und bank_2.b (426-2) Unter-Banken separiert und die bank_3 (428) ist in bank_3.a (428-1) und bank_3.b (428-2) Unter-Banken separiert. Wie auch gezeigt ist, umfasst jede Unter-Bank sechs individuell adressierbare Register für acht verschiedene Threads T0, T1, T2, T3, T4, T5, T6 und T7. Zum Beispiel ist ein separates und distinktes 32-Bit-Register R0 über bank_0.a (422-1) und bank_0.b (422-2) für jeden der Threads T0–T3 bzw. T4–T7 umfasst, was durch Register-R0-Gliederung bzw. Zusammenbruch (breakdown) 502 illustriert ist. Natürlich umfassen Ausführungen der Erfindung, dass jede Unter-Bank konfiguriert ist, irgendeine Anzahl N von individuellen adressierbaren Registern zu speichern.
Die Stelle von Registern für Threads T0–T3 und Threads T4–T7 ist über jedes gerade benummerte Register, welches R0 folgt, alterniert, z. B. ist ein separates und distinktes 32-Bit-Register R10 über bank_0.a (422-1) und bank_0.b (422-2) für jeden der Threads T4–T7 und T0–T7 umfasst, welches durch Register-Gliederung 504 illustriert ist. Ähnlich ist die Stelle von Registern für Threads T0–T7 und T4–T7 über jedes ungerade benummerte Register, welches R1 folgt, alterniert. Wie in weiterem Detail unten in Verbindung mit 6 bis 8 beschrieben ist, sind die Banken 422, 424, 426 und 428 innerhalb der lokalen Register-Datei 304 gemäß der detaillierten Ansicht 500 organisiert, um die Threads in die Lage zu versetzen, 32-Bit-, 64-Bit- und 128-Bit-Lese-Operationen von Registern unter Benutzung nur eines einzelnen Taktzyklus auszustellen.
Es wird für die gewöhnlichen Fachleute in der Technik ersichtlich sein, dass jedes Register, welches in der lokalen Register-Datei 403 umfasst ist, konfiguriert sein kann, irgendeine Anzahl von Bits, z. B. 8 Bits, 16 Bits, 32 Bits, 64 Bits und 128 Bits usw. zu speichern. Außerdem können die Register-Zuweisungen an Unter-Banken auf N·2 Unter-Banken verallgemeinert werden, wenn expandierte Werte gelesen werden (z. B. die 64-Bit-Lese-Operationen, welche unten im Zusammenhang mit 7 beschrieben sind), und können weiter verallgemeinert werden auf N·4 Unter-Banken, wenn ferner expandierte Werte gelesen werden (z. B. die 128-Bit-Lese-Operationen, welche unten im Zusammenhang mit 8 beschrieben sind), für beliebige Werte von N.
6 illustriert 32-Bit-Lese-Operationen von Register R0, R9, R14 und R7 für acht Threads T0–T7 gemäß einer Ausführungsform der vorliegenden Offenbarung. In dem in 6 illustrierten Beispiel stellt jeder der Threads T0–T7 eine 32-Bit-Lese-Anfrage für ihre jeweiligen Werte aus, welche in Registern R0, R9, R14 und R7 gespeichert sind (zweiunddreißig verschiedene 32-Bit-Werte im Ganzen, da vier 32-Bit-Werte für jeden von acht Threads gelesen werden). Demgemäß ist die Kreuzschiene 420 konfiguriert, zu erlauben, dass 32-Bit-Werte von acht verschiedenen R0-Registern gelesen werden, welche jeweils einem bestimmten der Threads T0–T7 entsprechen, was mittels Ereignis 602 illustriert sind. Die Kreuzschiene 420 ist auch konfiguriert, um zu erlauben, dass 32-Bit-Werte von acht verschiedenen R9-Registern gelesen werden, welche jeweils einem entsprechenden der Threads T0–T7 entsprechen. Die Kreuzschiene 420 ist auch konfiguriert, zu erlauben, dass 32-Bit-Werte von acht verschiedenen R14-Registern gelesen werden, welche jeweils einem jeweiligen der Threads T0–T7 entsprechen. Die Kreuzschiene 420 ist ferner konfiguriert, zu erlauben, dass 32-Bit-Werte von acht verschiedenen R7-Registern gelesen werden, welche jeweils einem entsprechenden der Threads T0–T7 entsprechen.
Somit sind in einem Taktzyklus acht verschiedene Threads T0–T7 jeweils in der Lage, vier verschiedene 32-Bit-Register R0, R9, R14 und R7 zu lesen. Nachfolgend werden die in dem Ereignis 602 extrahierten 32-Bit-Werte in Operand-Kollektor 440 gespeichert und schließlich an die ALU 452 für Arithmetik übergeben. In einigen Fällen können jedoch Threads T0–T7 eine Anweisung empfangen, auf 64-Bit-Werten zu operieren, welche innerhalb der lokalen Register-Datei 304 gespeichert sind. Demgemäß folgt die Weise, in welcher die Register R0–R23 mittels der Threads T0–T7 gelesen werden, den Techniken, welche unten in Verbindung mit 7 beschrieben sind.
7 illustriert 64-Bit-Lese-Operationen von Registern R8, R10, R4 und R22 für acht Threads T0–T7 gemäß einer Ausführungsform der vorliegenden Offenbarung. In dem in 7 illustrierten Beispiel stellt jeder der Threads T0–T7 eine 64-Bit-Lese-Anfrage für ihre entsprechenden Werte aus, welche in Registern R8, R10, R4 und R22 gespeichert sind. Da die Lese-Anfragen 64-Bit sind, was nicht auf die 32-Bit-Länge von jedem der Register R0–R23 abbildet (map), ist in diesem Fall die Kreuzschiene 420 konfiguriert, auch die Register R9, R11, R5 und R23 für jeden der Threads T0–T7 zusammen mit den Registern R8, R10, R4 und R22 für jeden Threads T0–T7 zu lesen. Wie im Detail unten beschrieben ist, wird ein Lesen der Register R8–R9, R10–R11, R4–R5 und R22–R23 für jeden der Threads T0–T7 über zwei Taktzyklen durchgeführt und ist mittels der Ereignisse 702 und 704 illustriert.
Insbesondere erfolgt das erste Lese-Ereignis 702 in Antwort auf ein Empfangen einer 64-Bit-Lese-Anfrage der Register R8, R10, R4 und R22 für die Threads T0–T7 und involviert ein Lesen der Register R8–R10, R9–R11, R4–R22 und R5–R23 für jeden der Threads T0–T3 von den Banken 422, 424, 426 und 428. Wie gezeigt ist, werden die 32-Bit-Werte für jedes der Register R8, R10, R9, R11, R4, R22, R5 und R23 mittels Kreuzschiene 420 während eines ersten Taktzyklus extrahiert. Nachfolgend wird für jeden der Threads T0–T3 das entsprechende Register R8 mit dem Register R9 zusammengefügt bzw. konkateniert (concatenated), um einen 64-Bit-Wert für das Register R8 zu ergeben, das entsprechende Register R10 ist mit dem Register R11 konkateniert, um einen 64-Bit-Wert für das Register R10 zu ergeben, das entsprechende Register R4 ist mit dem Register R5 konkateniert, um einen 64-Bit-Wert für das Register R4 zu ergeben, und das entsprechende Register R22 ist konkateniert mit Register 23, um einen 64-Bit-Wert für das Register R22 zu ergeben. Dies ist illustriert mittels der Pfeile innerhalb des ersten Lese-Ereignisses 702. Somit sind bei der Terminierung des ersten Taktzyklus die 64-Bit-Werte, welche mittels der Threads T0–T3 angefragt sind, von der lokalen Register-Datei 304 extrahiert worden.
Als nächstes erfolgt das zweite Lese-Ereignis 704 in Antwort auf Empfangen einer 64-Bit-Lese-Anfrage der Register R8, R10, R4 und R22 für die Threads T0–T7 und involviert ein Lesen der Register R8–R10, R9–R11, R4–R22 und R5–R23 für jeden der Threads T4–T7 von den Banken 422, 424, 426 und 428. Wie gezeigt ist, werden die 32-Bit-Werte für jedes der Register R8, R10, R9, R11, R4, R22, R5 und R23 mittels Kreuzschiene 420 während eines zweiten Taktzyklus extrahiert. Nachfolgend ist für jeden der Threads T4–T7 das entsprechende Register R8 konkateniert mit dem Register R9, um einen 64-Bit-Wert für das Register R8 zu ergeben, das entsprechende Register R10 ist mit dem Register R11 konkateniert, um einen 64-Bit-Wert für das Register R10 zu ergeben, das entsprechende Register R4 ist mit dem Register R5 konkateniert, um einen 64-Bit-Wert für das Register R4 zu ergeben und das entsprechende Register R22 ist konkateniert mit Register 23, um einen 64-Bit-Wert für das Register R22 zu ergeben. Dies ist mittels der Pfeile innerhalb des ersten Lese-Ereignisses 702 illustriert. Somit sind bei der Terminierung des zweiten Taktzyklus die 64-Bit-Werte, welche mittels Threads T4–T7 angefragt sind, von der lokalen Register-Datei 304 extrahiert worden.
Somit sind in jedem Taktzyklus vier verschiedene Threads (T0–T3/T4–T7) jeweils in der Lage, vier verschiedene 64-Bit-Register (z. B. R8, R10, R4 und R22 und die entsprechenden Register R9, R11, R5 bzw. R23) zu lesen. Nachfolgend werden die 64-Bit-Werte, welche in Ereignissen 702 und 704 für die Threads T0–T7 extrahiert sind, in Operand-Kollektor 440 gespeichert und schließlich an ALU 452 zur Arithmetik übergeben. In einigen Fällen können jedoch Threads T0–T7 eine Anweisung empfangen, auf 128-Bit-Werten zu operieren, welche innerhalb der lokalen Register-Datei 304 gespeichert sind. Demgemäß folgt die Weise, in welcher die Register R0–R23 mittels der Threads T0–T7 gelesen sind, den Techniken, welche unten im Zusammenhang mit 7 beschrieben sind.
8 illustriert 128-Bit-Lese-Aktivitäten bzw. -Operationen (reads) des Registers R4 für acht Threads T0–T7 gemäß einer Ausführungsform der vorliegenden Offenbarung. In dem in 8 illustrierten Beispiel stellt jeder der Threads T0–T7 eine 128-Bit-Lese-Anfrage nach ihren entsprechenden Werten, welche in Register R4 gespeichert sind, aus (issues). Da die Lese-Anfragen 128-Bit sind, was nicht auf die 32-Bit-Länge der Register R0 abbildet, ist in diesem Fall die Kreuzschiene 420 konfiguriert, zu erlauben, dass die Register R5, R6 und R7 von jedem der Threads T0–T7 gelesen werden, zusätzlich zum Erlauben, dass das Register R4 mittels jedes der Threads T0–T7 gelesen wird oder bereit wird (ready). Die 32-Bit-Werte von Registern R4, R5, R6 und R7 werden dann konkateniert, um den jeweiligen 128-Bit-Wert zu etablieren, welcher mittels jedes der Threads T0–T7 angefragt ist, wie in größerem Detail unten beschrieben ist.
Ereignis 802 illustriert 128-Bit-Lese-Aktivitäten von Register R4 für Threads T0–T3 während eines ersten Taktzyklus. Wie oben erwähnt ist, ist, wenn eine 128-Bit-Lese-Anfrage von einem Register angefragt ist, die Kreuzschiene 420 konfiguriert, automatisch die drei Register, welche unmittelbar dem Register folgen, d. h. Register R5–R7 für eine 128-Bit-Lese-Anfrage von Register R4 zu lesen. Wie illustriert ist, werden in Ereignis 802 die 32-Bit-Werte von Registern R4–R7 derart umgeordnet, dass die 128-Bit-Werte für jeden der Threads T0–T3 korrekt geordnet (R4–R7) sind.
Ereignis 804 illustriert 128-Bit-Lese-Aktivitäten von Register R4 für Threads T4–T7 während eines zweiten Taktzyklus. Entsprechend der oben beschriebenen Techniken ist die Kreuzschiene 420 konfiguriert, automatisch die drei Register R5–R7 zusätzlich zu dem Register R4 für die Threads T4–T7 zu lesen, um die jeweiligen 128-Bit-Werte zu extrahieren. Wieder werden die 32-Bit-Werte von Registern R4–R7 derart umgeordnet, dass die 128-Bit-Werte für jeden der Threads T4–T7 korrekt geordnet (R4–R7) sind.
Somit sind in jedem Taktzyklus vier verschiedene Threads (z. B. T0–T3) jeweils in der Lage, ein entsprechendes 128-Bit-Register (z. B. R4–R7) zu lesen. Nachfolgend werden die 128-Bit-Werte, welche in Ereignissen 802 und 804 für die Threads T0–T7 extrahiert sind, in Operand-Kollektor 440 gespeichert und schließlich an ALU 452 zu Arithmetik übergeben.
Eine Ausführungsform der Erfindung kann als ein Programm-Produkt zur Benutzung mit einer Computer-System implementiert sein. Das Programm oder die Programme des Programm-Produkts definieren Funktionen der Ausführungsformen (einschließlich der hierin beschriebenen Verfahren) und können auf einer Verschiedenheit von Computer-lesbaren Speichermedien beinhaltet sein. Illustrative Computer-lesbare Speichermedien umfassen, sind jedoch nicht darauf beschränkt: (i) nicht-schreibbare Speichermedien, z. B. Nur-Lese-Speicher-Geräte innerhalb eines Computers (wie CD-ROM-Platten, welche mittels eines CD-ROM-Laufwerks lesbar sind, Flash-Speicher, ROM-Chips oder irgendein anderer Typ von Festkörper-nicht-volatilem Halbleiter-Speicher), auf welchen Informationen permanent gespeichert ist; und (ii) schreibbare Speichermedien (z. B. Floppy-Disks innerhalb eines Disketten-Laufwerks oder eines Festplatten-Laufwerks oder irgendein anderer Typ von Festkörper-Halbleiter-Speicher mit willkürlichem Zugriff), auf welchen veränderbare Informationen gespeichert ist.
Die Offenbarung ist oben mit Bezug auf spezifische Ausführungsformen beschrieben worden. Gewöhnliche Fachleute in der Technik werden jedoch verstehen, dass verschiedene Modifikationen und Änderungen dann vorgenommen werden können, ohne von dem breiteren Geist und Geltungsbereich der Offenbarung abzuweichen, wie in den angehängten Ansprüchen ausgeführt ist. Die vorangehende Beschreibung und die Zeichnungen sind demgemäß in einem illustrativen anstatt in einem restriktiven Sinne anzusehen.

Claims

Computer-implementiertes Verfahren zum Durchführen eines gestalteten Zugriffs einer Register-Datei, welche einen Satz von N Registern umfasst, wobei N größer als zwei ist oder gleich zwei ist, wobei das Verfahren aufweist: für zumindest einen Thread, welcher in einer Gruppe von Threads umfasst ist, Empfangen einer Anfrage, auf eine erste Menge von Daten aus jedem Register in dem Satz von N Registern zuzugreifen; und Konfigurieren einer Kreuzschiene, um dem zumindest einen Thread zu erlauben, auf die erste Menge von Daten aus jedem Register in dem Satz von N Registern zuzugreifen.
Computer-implementiertes Verfahren gemäß Anspruch 1, wobei die Register-Datei eine Mehrzahl von Speicher-Banken aufweist, und wobei jedes Register in dem Satz von N Registern in einer anderen Speicher-Bank ansässig ist.
Computer-implementiertes Verfahren gemäß Anspruch 1, wobei bei jedem Taktzyklus der zumindest eine Thread auf die erste Menge von Daten zugreift aus entweder: jedem Register in dem Satz von N Registern, um eine gestaltete Zugriffs-Operation zu erzeugen, welche N Zugriffe der ersten Menge von Daten aufweist; jedem Register in N/2 ausgerichteten Paaren von sequentiellen Registern, um eine gestaltete Zugriffs-Operation zu erzeugen, welche N/2 Zugriffe von zweimal der ersten Menge von Daten aufweist; oder jedem Register in N/4 ausgerichteten Quads von sequentiellen Registern, um eine gestaltete Zugriffs-Operation zu erzeugen, welche N/4 Zugriffe von viermal der ersten Menge von Daten aufweist.
Computer-implementiertes Verfahren gemäß Anspruch 1, wobei der Satz von N Registern N/2 ausgerichtete Paare von sequentiellen Registern umfasst, und wobei der zumindest eine Thread auf die erste Menge von Daten aus jedem Register in jedem ausgerichteten Paar von sequentiellen Registern in einem einzelnen Taktzyklus zugreift, um eine gestaltete Zugriffs-Operation zu erzeugen, welche N/2 Zugriffe von zweimal der ersten Menge von Daten aufweist.
Computer-implementiertes Verfahren gemäß Anspruch 1, wobei der Satz von N Registern N/4 ausgerichtete Quads von sequentiellen Registern umfasst, und wobei der zumindest eine Thread auf die erste Menge von Daten aus jedem Register in jedem ausgerichteten Quad von sequentiellen Registern in einem einzelnen Taktzyklus zugreift, um eine gestaltete Zugriffs-Operation zu erzeugen, welche N/4 Zugriffe von viermal der ersten Menge von Daten aufweist.
Computer-implementiertes Verfahren gemäß Anspruch 1, wobei die erste Gruppe von Threads eine Untermenge einer zweiten Gruppe von Threads aufweist und entweder eine sequentielle niedrigere Hälfte der Threads, welche in der zweiten Gruppe von Threads umfasst sind, oder eine sequentielle obere Hälfte der Threads umfasst, welche in der zweiten Gruppe von Threads umfasst sind.
Computer-implementiertes Verfahren gemäß Anspruch 1, wobei der zumindest eine Thread auf die erste Menge von Daten dadurch zugreift, dass entweder die erste Menge von Daten aus jedem Register in dem Satz von N Registern gelesen wird oder dass die erste Menge von Daten an jedes Register in dem Satz von N Registern geschrieben wird.
Computer-implementiertes Verfahren gemäß Anspruch 1, wobei die erste Menge von Daten 32-Bits von Daten aufweist.
System zum Durchführen eines gestalteten Zugriffs einer Register-Datei, welche einen Satz von N Registern umfasst, wobei N größer als zwei ist oder gleich zwei ist, wobei das System aufweist: die Register-Datei; eine Kreuzschiene; und einen Prozessor, welcher konfiguriert ist, um: für zumindest einen Thread, welcher in einer Gruppe von Threads umfasst ist, eine Anfrage zu empfangen, auf eine erste Menge von Daten aus jedem Register in dem Satz von N Registern zuzugreifen; und die Kreuzschiene zu konfigurieren, dem zumindest einen Thread zu erlauben, auf die erste Menge von Daten aus jedem Register in dem Satz von N Registern zuzugreifen.
System gemäß Anspruch 9, wobei bei jedem Taktzyklus der zumindest eine Thread auf die erste Menge von Daten zugreift aus entweder: jedem Register in dem Satz von N Registern, um eine gestaltete Zugriffs-Operation zu erzeugen, welche N Zugriffe der ersten Menge von Daten aufweist; jedem Register in N/2 ausgerichteten Paaren von sequentiellen Registern, um eine gestaltete Zugriffs-Operation zu erzeugen, welche N/2 Zugriffe von zweimal der ersten Menge von Daten aufweist; oder jedem Register in N/4 ausgerichteten Quads von sequentiellen Registern, um eine gestaltete Zugriffs-Operation zu erzeugen, welche N/4 Zugriffe von viermal der ersten Menge von Daten aufweist.