DE102012221502A1 - System und Verfahren zum Durchführen von gestalteter-Speicherzugriff-Operationen - Google Patents

System und Verfahren zum Durchführen von gestalteter-Speicherzugriff-Operationen Download PDF

Info

Publication number
DE102012221502A1
DE102012221502A1 DE102012221502A DE102012221502A DE102012221502A1 DE 102012221502 A1 DE102012221502 A1 DE 102012221502A1 DE 102012221502 A DE102012221502 A DE 102012221502A DE 102012221502 A DE102012221502 A DE 102012221502A DE 102012221502 A1 DE102012221502 A1 DE 102012221502A1
Authority
DE
Germany
Prior art keywords
operands
instruction
register
memory access
memory
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102012221502A
Other languages
English (en)
Inventor
Xiaogang Qiu
Jack Hilaire Choquette
Manuel Olivier Gautho
Ming Y. Siu
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nvidia Corp
Original Assignee
Nvidia Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nvidia Corp filed Critical Nvidia Corp
Publication of DE102012221502A1 publication Critical patent/DE102012221502A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • G06F15/163—Interprocessor communication
    • G06F15/167—Interprocessor communication using a common memory, e.g. mailbox
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30098—Register arrangements
    • G06F9/3012—Organisation of register space, e.g. banked or distributed register file
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/34—Addressing or accessing the instruction operand or the result ; Formation of operand address; Addressing modes
    • G06F9/345—Addressing or accessing the instruction operand or the result ; Formation of operand address; Addressing modes of multiple operands or results
    • G06F9/3455—Addressing or accessing the instruction operand or the result ; Formation of operand address; Addressing modes of multiple operands or results using stride
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline, look ahead
    • G06F9/3824—Operand accessing
    • G06F9/383—Operand prefetching
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline, look ahead
    • G06F9/3836—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution
    • G06F9/3851—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution from multiple instruction streams, e.g. multistreaming
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline, look ahead
    • G06F9/3885—Concurrent instruction execution, e.g. pipeline, look ahead using a plurality of independent parallel functional units
    • G06F9/3887—Concurrent instruction execution, e.g. pipeline, look ahead using a plurality of independent parallel functional units controlled by a single instruction for multiple data lanes [SIMD]

Abstract

Eine Ausführungsform der vorliegenden Erfindung führt eine Technik aus, welche einen effizienten Weg bereitstellt, um Operanden von einer Registerdatei abzurufen. Insbesondere empfängt die Anweisung-Absetz-Einheit eine oder mehrere Anweisungen, wobei jede von diesen einen oder mehrere Operanden umfasst. Kollektiv werden die Operanden in eine oder mehrere Operanden-Gruppen organisiert, von welchen ein gestalteter-Zugriff gebildet werden kann. Die Operanden werden von der Registerdatei abgerufen und in einem Kollektor gespeichert. Sobald Operanden gelesen und in dem Kollektor gesammelt sind, übermittelt die Anweisung-Absetz-Einheit die Anweisungen und die entsprechenden Operanden an funktionale Einheiten innerhalb des Streaming-Mehrfach-Prozessors zur Ausführung. Ein Vorteil der vorliegenden Erfindung ist, dass mehrere Operanden von der Registerdatei in einer einzelnen Register-Zugriffs-Operation ohne einen Ressourcen-Konflikt abgerufen werden. Performanz beim Abrufen von Operanden von der Registerdatei ist dadurch verbessert, dass gestaltete Zugriffe gebildet werden, welche effizient Operanden abrufen, welche erkannte Speicher-Zugriffs-Muster aufweisen.

Description

  • HINTERGRUND DER ERFINDUNG
  • Gebiet der Erfindung
  • Die vorliegende Erfindung betrifft im Allgemeinen Computer-Architekturen und insbesondere ein System und ein Verfahren für Operand-Sammlung in einer Registerdatei.
  • BESCHREIBUNG DER ENTSPRECHENDEN TECHNIK
  • Eine gewöhnliche Praxis in Parallel-Verarbeitungs-Systemen ist es, einen Prozessor zu entwerfen, welcher mehrere Threads simultan ausführt. Wenn solche Threads alle dieselbe Anweisungs-Sequenz (typischerweise mit verschiedenen Daten für jeden Thread) ausführen, gibt es spürbare Vorteile, gewisse Ressourcen unter den Threads gemeinsam zu nutzen bzw. zu teilen (sharing). Zum Beispiel kann jeder Thread eine Anweisung ausführen, welche auf einen oder mehrere Operanden zugreift, welche von einer gemeinsam benutzten oder geteilten (shared) Bank von Registerdateien abgerufen sind, wobei jeder Thread auf eine verschiedene Registeradresse in der Bank von Registerdateien zugreift. Dieser Typ einer Operation kann auf Einzel-Anweisung-Mehrprozess-gestützten-(SIMT) und auf Einzel-Anweisung-Mehrdaten-(SIMD)-Prozessoren gefunden werden.
  • Während der Operation kann der Prozessor eine Anweisung über mehrere Threads hinweg ausführen, wobei die Anweisung auf einen oder mehrere Operanden aus der Bank von Registerdateien zugreift und wobei die Operanden bei verschiedenen Registeradressen innerhalb der Bank von Registerdateien lokalisiert sind. Der Prozessor führt dann eine Register-Zugriffs-Operation durch, um die Operanden abzurufen. Wenn z. B. vier Threads gleichzeitig eine Anweisung ausführen, welche jeweils drei Operanden erfordert, dann ruft der Prozessor bis zu zwölf separate Operanden ab, um die Anweisung auszuführen. Eine Performanz wird wesentlich verbessert, wenn alle zwölf Operanden innerhalb derselben Register-Zugriffs-Operation abgerufen werden können.
  • Aufgrund verschiedener Beschränkungen, wie etwa physikalischer-Speicher-Konfigurationen, können gewisse Kombinationen von Registern nicht simultan zugreifbar sein. Wenn zwei oder mehr Operanden in Registerdatei-Stellen lokalisiert sind, auf welche nicht zur selben Zeit zugegriffen werden können, begegnet der Prozessor einem Registerbank-Konflikt. In solch einem Fall ist der Prozessor nicht in der Lage, alle Operanden in einer einzelnen Register-Zugriffs-Operation abzurufen.
  • Eine Vorgehensweise oder Zugang (approach), Registerdatei-Konflikte zu vermeiden, ist, seriell eine separate Register-Zugriffs-Operation für jeden Operanden durchzuführen, auf welchen mittels der momentanen Anweisung zugegriffen ist. Dieser Zugang vermeidet Registerbank-Konflikte, weil auf jeden Operand jeweils einzeln zu einer Zeit zugegriffen ist (one at a time). Ein Nachteil dieser Vorgehensweise ist jedoch, dass der Prozessor nicht in der Lage ist, mehrere Operanden unter Benutzung derselben Register-Zugriffs-Operation abzurufen, um auf Operanden zuzugreifen, welche nicht zu einem Registerbank-Konflikt führen. Wenn z. B. vier Threads eine Anweisung ausführen, welche drei Operanden erfordert, würde der Prozessor zwölf separate Register-Zugriffs-Operationen durchführen, um Registerbank-Konflikte zu vermeiden. Die Verteilung der Operanden durch die Bank von Registerdateien hindurch könnte jedoch derart sein, dass der Prozessor alle Operanden in weniger als zwölf Register-Zugriffs-Operationen abrufen könnte. In solchen Situationen sind mögliche Effizienzen mit Speicherzugriffs-Operationen nicht realisiert.
  • Wie das Vorgehende illustriert, ist es, was in der Technik gebraucht ist, ein effizienterer Weg, um Operanden von einer Registerdatei zu sammeln.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Eine Ausführungsform der vorliegenden Erfindung führt ein Computer-implementiertes Verfahren zum Durchführen von Registerspeicher-Operationen aus. Eine Anweisungs-Absetz-Einheit (dispatching unit) empfängt eine Anweisung, welche über eine Mehrzahl von Operanden auszuführen ist. Die Anweisungs-Absetz-Einheit erkennt, dass eine Mehrzahl von Registerdateien, in welchen die Mehrzahl von Operanden gespeichert ist, über ein bestimmtes Speicherzugriffs-Muster zugreifbar ist. Als nächstes bildet die Anweisungs-Absetz-Einheit eine gestaltete (shaped) Speicherzugriffs-Operation, welche dem bestimmten Speicherzugriffs-Muster entspricht. Die Anweisungs-Absetz-Einheit führt dann die gestaltete Speicherzugriffs-Operation durch, um auf die Mehrzahl von Operanden von der Mehrzahl von Registerdateien zuzugreifen.
  • Ein Vorteil der offenbarten Technik ist, dass mehrere Operanden von einer Registerdatei in einer einzelnen Register-Zugriffs-Operation ohne einen Ressourcen-Konflikt abgerufen werden.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • So dass die Weise, in welcher die oben zitierten Merkmale der vorliegenden Erfindung 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 Erfindung illustrieren und dass sie daher nicht aufzufassen sind, ihren Geltungsbereich zu begrenzen, denn die Erfindung 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-Subsystems für das Computer-System der 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 Allgemein-Verarbeitungs-Clusters innerhalb einer der Parallel-Verarbeitungs-Einheiten von 2 gemäß einer Ausführungsform der vorliegenden Erfindung;
  • 3C ist ein Blockdiagramm eines Teils des Streaming-Mehrfach-Prozessors (SM) von 3B gemäß einer Ausführungsform der vorliegenden Erfindung;
  • 4A illustriert eine Bank von Registerdateien, welche für Operand-Sammlung gemäß einer Ausführungsform der vorliegenden Erfindung konfiguriert sind;
  • 4B illustriert eine Bank von Registerdateien, welche für Operand-Sammlung gemäß einer alternativen Ausführungsform der vorliegenden Erfindung konfiguriert sind;
  • 4C illustriert eine Bank von Registerdateien, welcher für Operand-Sammlung gemäß einer anderen alternativen Ausführungsform der vorliegenden Erfindung konfiguriert sind;
  • 4D illustriert eine Bank von Registerdateien, welche für Operand-Sammlung gemäß noch einer anderen alternativen Ausführungsform der vorliegenden Erfindung konfiguriert sind;
  • 5 illustriert ein Blockdiagramm der Warp-Planer-(warp scheduler) und -Anweisungs-Einheit und der lokalen Registerdatei der 3C, gemäß einer Ausführungsform der vorliegenden Erfindung; und
  • 6 ist ein Flussdiagramm von Verfahrensschritten zum Sammeln von Registerdatei-Operanden gemäß einer Ausführungsform der vorliegenden Erfindung.
  • DETAILLIERTE BESCHREIBUNG
  • In der folgenden Beschreibung werden zahlreiche spezifische Details ausgeführt, um ein durchgängigeres Verständnis der vorliegenden Erfindung 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.
  • SYSTEMÜBERBLICK
  • 1 ist ein Blockdiagramm, welches ein Computersystem 100 illustriert, welches konfiguriert ist, einen oder mehrere Aspekte der vorliegenden Erfindung 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 Pfad 106 und Speicherbrücke 105 weiter. Ein Parallel-Verarbeitungs-Subsystem 112 ist mit der Speicherbrücke 105 über einen Bus oder einen anderen Kommunikationspfad 113 (z. B. einen 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 CRT- oder LCD-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-/n-Cards) 120 und 121. Andere Komponenten (nicht explizit gezeigt) einschließlich USB- oder andere Port-Verbindungen, CD-Laufwerke, 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, können unter Benutzung irgendwelcher geeigneten Protokolle implementiert sein, wie etwa PCI (Peripheral Component Interconnect), 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 integriert sein, wie etwa der Speicherbrücke 105, CPU 102 und I/O-Brücke 107, um ein System auf dem Chip (system an 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. 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 Erfindung. 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 und auf 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 Aufgaben durchzuführen, welche das Erzeugen von Pixeldaten von Grafik-Daten, welche mittels CPU 102 und/oder Systemspeicher 104 über Speicherbrücke 105 und 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 sein eigenes dediziertes Parallel-Verarbeitungs-Speichergeräte) haben oder braucht nicht dedizierte Parallel-Verarbeitungs-Speichergeräte) zu haben. Eine oder mehrere PPUs 202 können Daten an das Anzeigegeräte 110 ausgeben oder jede PPU 202 kann Daten an eines oder mehrere Anzeigegeräte 110 ausgeben.
  • Im Betrieb ist CPU 102 der Master-Prozessor von Computer-System 100, welcher Operationen von anderen System-Komponenten steuert und koordiniert. Insbesondere stellt CPU 102 Befehle aus (issues), welche die Operation von PPUs 202 steuern. In einigen Ausführungsformen schreibt CPU 102 einen Strom von Befehlen für jede PPU 202 auf eine Datenstruktur (nicht explizit in weder 1 noch 2 gezeigt), welche in dem System-Speicher 104, Parallel-Verarbeitungs-Speicher 204 oder irgendeiner anderen Speicher-Stelle lokalisiert sein kann, welche sowohl für CPU 102 als auch für PPU 202 zugreifbar ist. Ein Zeiger (pointer) auf jede Datenstruktur wird auf einen Schiebepuffer (push buffer) geschrieben, um Verarbeitung des Stroms von Befehlen in der Datenstruktur zu initiieren. Die PPU 202 liest Befehlströme von einem oder mehreren Schiebepuffern und führt dann Befehle asynchron relativ zu dem Betrieb von CPU 102 aus. Ausführungs-Prioritäten können für jeden Schiebepuffer spezifiziert werden, um Planen der verschiedenen Schiebepuffer zu steuern.
  • Mit Bezug nun zurück auf 2 und 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 die Arbeit, welche mittels des Push-Puffers spezifiziert 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. Jedes 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, variieren.
  • GPCs 208 empfangen Verarbeitungs-Aufgaben, welche auszuführen sind, von einer Arbeits-Verteilungs-Einheit innerhalb einer Aufgabe-/Arbeit-Einheit 207. Die Arbeits-Verteilungs-Einheit empfängt Zeiger auf Rechen-Verarbeitungs-Aufgaben (Aufgabenzeiger), welche als Aufgabe-Metadaten (TMD) kodiert sind und im Speicher gespeichert sind. Die Zeiger auf TMDs sind in dem Befehls-Strom umfasst, welcher in einem Schiebepuffer 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 von zu verarbeitenden Daten, sowie Status- oder Zustands-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 die GPCs 208 in einem gültigen Zustand konfiguriert sind, bevor die Verarbeitung, welche mittels jeder der TMDs spezifiziert ist, initiiert ist. Eine Priorität kann für jede TMD spezifiziert sein, welche benutzt ist, um Ausführung der Verarbeitungs-Aufgaben zu planen (schedule). Verarbeitungsaufgaben können auch von dem Verarbeitungsclusterfeld 230 empfangen werden. Optional kann die TMD einen Parameter umfassen, der steuert, ob die TMD an den Kopf oder den Schwanz für eine Liste von Verarbeitungsaufgaben hinzugefügt wird (oder eine Liste von Zeigern auf Verarbeitungsaufgaben), wodurch ein anderer Level von Kontrolle ü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 dynamischem 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. 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-Karten (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.
  • Irgendeines 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 irgendein 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 zu Speicher-Schnittstelle 214, um mit I/O-Einheit 205 zu kommunizieren, sowie eine Verbindung zu lokalem Parallel-Verarbeitungs-Speicher 204, um dadurch den Verarbeitungs-Kernen innerhalb der verschiedenen GPCs 208 zu ermöglichen, mit System-Speicher 104 oder einem anderen Speicher zu kommunizieren, welcher nicht lokal zu der PPU 202 ist. In der in 2 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 exklusiv oder fast exklusiv System-Speicher 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-GLEICHZEITIGE-AUFGABE-PLANUNG
  • Mehrfach-Verarbeitungs-Aufgaben können gleichzeitig auf den GPCs 208 ausgeführt werden und eine Verarbeitungs-Aufgabe kann eine oder mehrere „Kindc-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 der 2, gemäß einer Ausführungsform der vorliegenden Erfindung. 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 basierend auf Ausführungs-Prioritäts-Niveaus zu planen bzw. zeitlich zu planen sind (scheduled). Für jedes Prioritäts-Niveau speichert die Aufgabe-Management-Einheit 300 eine Liste von Zeigern (pointers) auf die TMDs 322 entsprechend den Aufgaben in der Planer-Tabelle 321. 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 verschiedene Aufgaben basierend auf Prioritäts-Information oder unter Benutzung anderer Techniken sammeln.
  • Die Arbeit-Verteilungs-Einheit 340 umfasst eine Aufgabe-Tabelle 345 mit Fächern oder Zellen (slots), wobei jedes von der TMD 322 für eine Aufgabe besetzt sein kann, welche ausgeführt wird. Die Aufgabe-Management-Einheit 300 kann Aufgaben zur Ausführung planen, wenn es in der Aufgabe-Tabelle 345 ein freies Fach gibt. Wenn es kein freies Fach gibt, kann eine höhere-Priorität-Aufgabe, welche kein Fach besetzt, eine niedrigere-Priorität-Aufgabe, welche ein Fach besetzt, verdrängen oder ausweisen (evict). Wenn eine Aufgabe verdrängt ist oder ausgewiesen ist (evicted), wird die Aufgabe gestoppt und wenn die Ausführung der Aufgabe nicht vollständig ist, wird ein Zeiger auf die Aufgabe an eine Liste von zu planenden Aufgabe-Zeigern hinzugefügt, so dass Ausführung der Aufgabe später wiederaufnehmen wird. Wenn eine Kind-Verarbeitungs-Aufgabe erzeugt ist, während Ausführung einer Aufgabe, wird ein Zeiger auf die Kind-Aufgabe an eine Liste von Aufgabe-Zeigern, welche zu planen sind, angefügt. Eine Kind-Aufgabe kann mittels eines TMD 322 erzeugt werden, welcher 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 Schiebepuffer (pushbuffers) 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 Schiebepuffer bereitgestellt sind, und Kind-Aufgaben ist, dass die Aufgaben, welche durch die Schiebepuffer 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. Jedes 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 SIMT-Ausführung verschiedenen Threads, leichter divergenten Ausführungspfaden durch ein gegebenes Thread-Programm zu folgen. 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 jeder 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 betrieben 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 eine „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 SM 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 (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 auch 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 zwischengespeichert 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 buffers) (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 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 ein 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, Parallel-Verarbeitungs-Speicher 204 oder System-Speicher 104 wie benötigt geholt. Jeder SM 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 (Vor-raster-Operationen) 325 ist konfiguriert, um baten 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. SMs 310 oder Textur-Einheiten 315, preROPs 325, können innerhalb eines GPC 208 umfasst sein kann. 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, um Aufgaben, für ein oder mehrere Anwendungs-Programme auszuführen.
  • 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 seiner Ausführung zugreifbar ist. Der Thread-ID, welcher als ein eindimensionaler oder mehrdimensionaler numerischer Wert definiert werden kann, steuert verschiedene Aspekte des Verarbeitungs-Verhaltens des Threads. Zum Beispiel kann ein 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 Erfindung. Der SM 310 umfasst einen Anweisung-L1-Zwischenspeicher 370, welcher konfiguriert ist, Anweisungen und Konstanten von Speicher über L1.5-Zwischenspeicher 335 zu empfangen. Eine Warp-Planer- und Anweisungs-Einheit 312 empfängt Anweisungen und Konstanten von dem Anweisungs-L1-Zwischenspeicher 370 und steuert die lokale Registerdatei 304 und SM 310 funktionale Einheiten gemäß den Anweisungen und Konstanten. Die SM 310 funktionalen Einheiten umfassen N exec-(Ausführungs- oder Verarbeitungs-)-Einheiten 302 und P Lade-Speicher-Einheiten (LSU) 303.
  • SM 310 stellt auf-Chip(on-chip)-(internen)Datenspeicher mit verschiedenen Leveln eines Zugriffs bereit. Spezielle Register (nicht gezeigt) sind lesbar aber nicht mittels LSU 303 schreibbar und werden benutzt, um Parameter zu speichern, welche die „Position” jedes Threads definieren. In einer Ausführungsform umfassen spezielle Register ein Register pro Thread (oder pro exec-Einheit 302 innerhalb SM 310), welche eine Thread-ID speichert; jedes Thread-ID-Register ist nur von der jeweiligen der exec-Einheit 302 zugreifbar. Spezielle Register können auch zusätzliche Register umfassen, welche von allen Threads lesbar sind, welche dieselbe Verarbeitungsaufgabe ausführen, welche mittels einer TMD 322 repräsentiert ist (oder mittels aller LSUs 303), welche einen CTA-Identifikator speichert, die CTA-Dimensionen, die Dimensionen eines Gitters, zu welchem 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, welcher das CTA zugewiesen ist.
  • Wenn die TMD 322 eine Gitter-TMD ist, führt Ausführung der TMD 322 dazu, dass eine fixe Anzahl von CTAs anzustoßen ist (launched) und ausgeführt ist, um die feste Menge von Daten zu verarbeiten, welche in der Queue 525 gespeichert ist. Die Anzahl von CTAs ist als das Produkt der Gitter-Breite, -Höhe und -Tiefe spezifiziert. Die feste Menge von Daten kann in der TMD 322 gespeichert sein oder die TMD 322 kann einen Zeiger auf die Daten speichern, welche mittels der CTAs prozessiert 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 Daten, welche zu prozessieren ist, nicht notwendigerweise fest ist. Queue-Einträge speichern Daten zum Prozessieren 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 eine verschachtelte Parallelisierung (nested parallelism) bereitgestellt ist. Typischerweise wird eine Ausführung des Threads oder der CTA, welches den Thread umfasst, ausgesetzt, bis die Ausführung die Kind-Aufgabe vollendet. Die Queue kann in der TMD 322 oder separat von der TMD 322 gespeichert werden, in welchem Fall die TMD 322 einen Queue-Zeiger auf die Queue speichert. Vorteilhafterweise können Daten, welche mittels der Kind-Aufgabe erzeugt sind, auf 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 Gesamtmenge von Daten nicht auf die Größe der Queue begrenzt ist.
  • CTAs, welche zu einem Gitter gehören, haben implizite Gitter-Breite, -Höhe und -Tiefe-Parameter, welche die Position der entsprechenden CTA innerhalb des Gitters anzeigen. Spezielle Register werden während einer Initialisierung in Antwort auf Befehle geschrieben, welche über das Frontend 212 von dem Geräte-Treiber 103 empfangen werden, und ändern sich nicht während einer Ausführung einer Verarbeitungs-Aufgabe. Das Frontend 212 plant (schedules) jede Verarbeitungs-Aufgabe zur Ausführung. Jedes CTA ist mit einer spezifischen TMD 322 für gleichzeitige Ausführung von einer oder mehreren 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 nicht mittels irgendeines Threads innerhalb desselben CTA (oder irgendeiner LSU 303) geschrieben werden können. In einer Ausführungsform stellt der Geräte-Treiber 103 Parameter für den Parameter-Speicher bereit, bevor SM 310 darauf gerichtet wird, Ausführungen einer Aufgabe zu beginnen, welche diese Parameter benutzt. Irgendein Thread innerhalb irgendeines CTA (oder irgendeiner exec-Einheit 302 innerhalb SM 310) kann auf globalen Speicher über eine Speicher-Schnittstelle 214 zugreifen. Teile von globalem Speicher können. in dem L1-Cache oder Zwischenspeicher 320 gespeichert sein.
  • Lokale Registerdatei 304 wird mittels jedes Threads als ein Notizraum (scratch space) benutzt; jedes Register ist für die exklusive Benutzung eines Threads alloziert und Daten in irgendeiner lokalen Registerdatei 304 sind nur mittels des Threads zugreifbar, für den das Register alloziert ist. Lokale Registerdatei 304 kann als eine Registerdatei implementiert sein, welche physikalisch oder logisch in P Spuren oder Bahnen (lanes) geteilt ist, wobei jede eine gewisse Anzahl von Einträgen hat (wobei jeder Eintrag z. B. ein 32-Bit-Wort speichern könnte). Eine Spur ist für jede 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 bevölkert sein, welche dasselbe Programm ausführen, um SIMD-Ausführung zu erleichtern. Verschiedene Teile der Spuren können für verschiedene der G gleichzeitigen Thread-Gruppen alloziert sein, so dass ein gegebener Eintrag in der lokalen Registerdatei 304 nur für einen bestimmten Thread zugreifbar ist. In einer Ausführungsform sind gewisse Einträge innerhalb der lokalen Registerdatei 304 zum Speichern von Thread-Identifikatoren reserviert, eines der speziellen Register implementierend. Zusätzlich speichert ein uniformer L1-Zwischenspeicher 375 uniforme oder konstante Werte für jede Spur der N exec-Einheiten 302 und P Lade-Speicher-Einheiten LSU 303.
  • Der gemeinsame Speicher 306 ist für Threads innerhalb eines einzelnen CTA zugreifbar; mit anderen Worten ist jede Stelle in dem gemeinsamen Speicher 306 für irgendeinen Thread innerhalb desselben CTA (oder für irgendeine Verarbeitungs-Maschine innerhalb SM 310) zugreifbar. Der gemeinsame Speicher (shared memory) 306 kann als eine gemeinsame Registerdatei oder als ein gemeinsamer Auf-Chip-Cache-Speicher mit einer Zwischenverbindung implementiert sein, welche irgendeiner Verarbeitungs-Maschine erlaubt, von irgendeiner Stelle in dem gemeinsamen Speicher zu lesen oder auf irgendeine Stelle in dem gemeinsamen Speicher zu schreiben. In anderen Ausführungsformen könnte ein gemeinsamer Zustandsraum auf einen Pro-CTA-Bereich von Off-Chip-Speicher mappen, und könnte in L1-Cache 320 zwischengespeichert sein. Der Parameter-Speicher kann als ein designierter Abschnitt innerhalb derselben gemeinsamen Registerdatei oder gemeinsamem Cache-Speicher implementiert sein, welcher den gemeinsamen Speicher 306 implementiert, oder als eine separate gemeinsame Registerdatei oder Auf-Chip-Cache-Speicher, auf welchen die LSUs 303 Nur-Lese-Zugriff haben. In einer Ausführungsform ist die Fläche, welche den Parameter-Speicher implementiert, auch benutzt, um den CTA-ID und den Aufgabe-ID zu speichern, sowie CTA- und Gitter-Dimensionen oder Queue-Positionen, was Teile der speziellen Register implementiert. Jede LSU 303 in SM 310 ist mit einer unifizierte-Adresse-Abbildungs-Einheit 352 gekoppelt, welche eine Adresse, welche für Lade- und Speicher-Anweisungen bereitgestellt ist, welche in einem unifizierten Speicherraum spezifiziert sind, in eine Adresse in jedem distinkten Speicherraum konvertiert. Folglich kann eine Anweisung benutzt werden, auf irgendeinen des lokalen, gemeinsamen oder globalen Speicherraums dadurch zuzugreifen, dass eine Adresse in dem unifizierten Speicherraum spezifiziert ist.
  • Der L1-Zwischenspeicher 320 in jedem SM 310 kann benutzt werden, um private Pro-Thread-lokale-Daten und auch Pro-Anwendungglobale-Daten zwischenzuspeichern. In einigen Ausführungsformen können die Pro-CTA-gemeinsamen Daten in dem L1-Zwischenspeicher 320 zwischengespeichert sein. Die LSUs 302 sind mit dem gemeinsamen Speicher 306 und dem L1-Zwischenspeicher 320 über eine Speicher- und Zwischenspeicher-Zwischenverbindung 380 gekoppelt.
  • OPERAND-SAMMLUNG IN EINER REGISTERDATEI
  • Wie in den 4A bis 4D illustriert ist, umfassen Registerdateien 402 Register, welche Daten speichern, wie etwa Anweisungs-Operanden, auf welche mittels des Prozessors zugegriffen werden, wenn Anweisungen ausgeführt werden. Jede einzelne Registerzelle ist mittels einer Thread-Adresse und einer Register-Adresse identifiziert. Zum Beispiel ist das Register in der oberen linken Ecke von Registerdatei 0 402(0) Register 10 von Thread 4, so dass es mittels der Nomenklatur T4:10 identifiziert ist. Ähnlich ist das Register in der unteren rechten Ecke von Registerdatei 0 402(0) Register 0 von Thread 3, so dass es mittels der Nomenklatur T3:0 identifiziert ist. Jede Registerdatei ist derart organisiert, dass auf eine Zeile von Registern in jeder Registerdatei simultan während einer gegebenen Register-Zugriffs-Operation zugegriffen werden kann. Zum Beispiel kann auf Register T0:0, T1:0, T2:0 und T3:0 simultan in einer einzelnen Register-Zugriffs-Operation zugegriffen werden. Registerdateien 402 sind in logische Bänke gemäß des Typs von Operanden, auf welche während einer spezifischen Register-Zugriffs-Operation zugegriffen wird, organisiert. Wenn Operanden von den Registerdateien gelesen werden, bilden die Register-Zugriffs-Operationen Muster (register access operations form patterns) über die Registerdateien, welche hierin als „gestaltete Zugriffe” (shaped accesses) identifiziert sind. Die Platzierung von Registern innerhalb der Registerdateien und die gestalteter-Zugriff-Muster, welche während der Register-Zugriffs-Operationen gebildet sind, machen von gemeinsamen Operand-Konfigurationen Gebrauch. Als ein Ergebnis vermindert der Gebrauch von gestalteten Zugriffen im Gegensatz zu separaten seriellen Register-Zugriffs-Operationen für jeden Operanden die Latenz zum Sammeln von Anweisungs-Operanden von den Registerdateien, wodurch eine Performanz verbessert ist. Jede von 4A bis 4D illustriert ein anderes beispielhaftes Gestalter-Zugriff-Muster.
  • 4A illustriert eine Bank von Registerdateien, welche für Operand-Sammlung konfiguriert ist, gemäß einer Ausführungsform der vorliegenden Erfindung. Wie gezeigt ist, umfasst die Bank von Registerdateien Registerdateien 402 und logische Banken 420. In diesem Fall können die logischen Banken 420 derart gebildet sein, dass die logische Bank 0 420(0) Registerdatei 0 402(0) und Registerdatei 2 402(1) umfasst, dass logische Bank 1 420(1) Registerdatei 1 402(2) und Registerdatei 3 402(3) umfasst, usw. Mit dieser Anordnung sind die Registerdateien 402 optimiert, um Einzel-Breite-(single-width)-Operanden abzurufen. Wenn z. B. Threads 0 bis 7 alle auf einen Einzel-Breite-Operanden zugreifen, welcher in Register 0 gespeichert ist, dann kann der Prozessor einen gestalteten Zugriff innerhalb der logischen Bank 0 420(0) bilden, um die untere Zeile von Registern abzurufen, einschließlich T0:0 bis T7:0. Der Prozessor kann einen gestalteten Zugriff innerhalb der logischen Bank 1 420(1) bilden, um einen anderen Einzel-Breite-Operanden für eine selbe Gruppe von Threads abzurufen, wie etwa T0:1 bis T7:1. Ähnlich kann der Prozessor einen gestalteten Zugriff innerhalb der logischen Bank 2 420(2) und der logischen Bank 3 420(3) bilden, um einen Einzel-Breite-Operanden bei Registern 4 und 5 für denselben Satz von acht Threads abzurufen. Während einer einzelnen Register-Zugriff-Operation ruft der illustrierte gestaltete Zugriff vier Einzel-Breite-Operanden für jeden von acht Threads ab, wie mittels der schattierten Region in 4A illustriert ist.
  • 4B illustriert eine Bank von Registerdateien, welche für Operand-Sammlung konfiguriert sind, gemäß einer alternativen Ausführungsform der vorliegenden Erfindung. Wie gezeigt ist, umfasst die Bank von Registerdateien die Registerdateien 402 und logische Banken 440. In diesem Fall können die logischen Banken 420 derart gebildet sein, dass logische Bank 0 440(0) Registerdatei 0 402(0) und Registerdatei 2 402(2) umfasst, und derart, dass logische Bank 1 440(1) Registerdatei 1 402(1) und Registerdatei 3 402(3) umfasst, usw. Mit dieser Anordnung sind die Registerdateien 402 optimiert, Doppel-Breite-(double-width)-Operanden abzurufen. Wenn z. B. Threads 0 bis 3 alle auf einen Doppel-Breite-Operanden zugreifen, welcher in Registerpaar 0-1 gespeichert ist, dann kann der Prozessor einen gestalteten Zugriff innerhalb der logischen Bank 0 440(0) bilden, um die untere Zeile von Registern abzurufen, einschließlich T0:0-1 bis T3:0-1. Der Prozessor kann dann einen gestalteten Zugriff innerhalb der logischen Bank 1 440(1) bilden, um einen Doppel-Breite-Operanden für eine andere Gruppe von Threads abzurufen, wie etwa T4:0-1 bis T7:0-1. Ähnlich kann der Prozessor einen gestalteten Zugriff innerhalb der logischen Bank 2 440(2) und der logischen Bank 3 440(3) bilden, um einen Doppel-Breite-Operanden für vier Threads von jeder logischen Bank abzurufen. Zum Beispiel ruft während einer einzelnen Register-Zugriffs-Operation der illustrierte gestaltete Zugriff zwei Doppel-Breite-Operanden für jeden von acht Threads ab, wie mittels des schattierten Bereichs in 4B illustriert ist.
  • 4C illustriert eine Bank von Registerdateien, welche konfiguriert ist für Operand-Sammlung gemäß einer anderen alternativen Ausführungsform der vorliegenden Erfindung. Wie gezeigt ist, umfasst die Bank von Registerdateien die Registerdateien 402 und logische Banken 460. In diesem Fall können logische Banken 460 derart gebildet sein, dass zwei logische Banken 460(2) 460(3) optimiert sind, Einzel-Breite-Operanden abzurufen, und zwei logische Banken 460(0) 460(1) sind optimiert, Doppel-Breite-Operanden abzurufen. Während einer einzelnen Register-Zugriffs-Operation ruft z. B. der illustrierte gestaltete Zugriff einen Doppel-Breite-Operanden für jeden von acht Threads von der logischen Bank 0 460(0) und logischen Bank 1 460(1) ab, nämlich Register T0:0-1 bis T7:0-1. Während derselben Register-Zugriffs-Operation ruft der illustrierte gestaltete Zugriff zwei Einzel-Breite-Operanden für jeden von acht Threads von der logischen Bank 2 460(2) und logischen Bank 3 460(3) ab, nämlich Register 4 und 5 für Threads 0-7. Dieser beispielhafte gestaltete Zugriff ist durch die schattierte Region in 4C illustriert.
  • 4D illustriert eine Bank von Registerdateien, welche für Operand-Sammlung konfiguriert ist, gemäß noch einer anderen alternativen Ausführungsform der vorliegenden Erfindung. Wie gezeigt ist, umfasst die Bank von Registerdateien die Registerdateien 402 und die logischen Banken 480. In diesem Fall können die logischen Banken 480 derart gebildet sein, dass die logischen Banken 480 optimiert sind, Quadrupel-Breite-Operanden abzurufen. Während einer einzelnen Register-Zugriffs-Operation ruft z. B. der illustrierte gestaltete Zugriff einen Quadrupel-Breite-Operanden für jeden von vier Threads von der logischen Bank 0/1 480(0) ab, nämlich Register T0:0-3 bis T3:0-3. Während derselben Register-Zugriffs-Operation ruft der illustrierte gestaltete Zugriff einen zweiten Quadrupel-Breite-Operanden für dieselben vier Threads von der logischen Bank 2/3 480(1) ab, nämlich Register T0:4-7 bis T3:4-7. Dieser beispielhafte gestaltete Zugriff ist durch den schattierten Bereich in 4D illustriert.
  • 5 illustriert ein Blockdiagramm der Warp-Planer-(warp scheduler) und -Anweisungs-Einheit 312 und der lokalen Registerdatei 304 der
  • 3C gemäß einer Ausführungsform der vorliegenden Erfindung. Wie gezeigt ist, umfasst die Warp-Planer- und Anweisungs-Einheit 312 eine Warp-Planer- 502 und eine Anweisungs-Absetz-Einheit (instruction dispatch unit) 504 auf. Der Warp-Planer 502 ruft Anweisungen und Konstanten von dem Anweisung-L1-Zwischenspeicher 370 ab und plant die Anweisung, um als ein oder mehr Threads innerhalb einer Thread-Gruppe auszuführen. Die Anweisungs-Absetz-Einheit 504 steuert die lokale Registerdatei 304 und SM 310 funktionale Einheiten gemäß den Anweisungen und Konstanten, welche von dem Anweisung-L1-Zwischenspeicher 370 abgerufen sind. Die Anweisung-Absetz-Einheit 504 evaluiert die Anweisungs-Operanden, um zu bestimmen, ob die Operanden innerhalb eines erkannten gestalteter-Zugriff-Musters passen. Die Anweisung-Absetz-Einheit 504 wählt dann einen gestalteten Zugriff aus, um einen Satz von Operanden von der Registerdatei 506 zu lesen. Die Anweisung-Absetz-Einheit 504 erzeugt dann die Adressen und leseaktiviert (read enables), um die Operanden von der Registerdatei 506 zu lesen.
  • Die lokale Registerdatei 304 umfasst eine Registerdatei 506 und einen Kollektor 508. Die Registerdatei 506 ruft die Operanden während der Register-Zugriff-Operation gemäß des Musters des gestalteten Zugriffs ab und sendet die Operanden an den Kollektor 508. Der Kollektor 508 richtet die Operanden gemäß der Position der Operanden in den ursprünglichen Anweisungen aus und speichert die Operanden demgemäß. Wenn alle Operanden während der ersten Register-Zugriffs-Operation abgerufen sind, dann werden die Anweisungen und Operanden an die SM 310 funktionalen Einheiten übergeben, einschließlich der exec-Einheiten 302 und Lade-Speicher-Einheiten 303. Wenn einige Operanden während der ersten Register-Zugriffs-Operation nicht abgerufen sind, dann speichert der Kollektor 508 das Ergebnis jedes gestalteten Zugriffs, bis alle Operanden gesammelt sind. Sobald alle Operanden innerhalb des Kollektors 508 gespeichert sind, werden die Anweisungen und Operanden an die SM 310 funktionalen Einheiten übergeben, einschließlich der exec-Einheiten 302 und der Lade-Speicher-Einheiten 303.
  • Um einen gestalteten Zugriff zu bilden, empfängt die Anweisung-Absetz-Einheit 504 eine oder mehrere Anweisungen von dem Warp-Planer 502. Jede Anweisung ist mit einem oder mehreren Operanden assoziiert. Kollektiv sind die Operanden in eine oder mehrere Operanden-Gruppen organisiert, von welchen ein gestalteter Zugriff gebildet werden kann. Die Anweisung-Absetz-Einheit 504 ist konfiguriert, die verschiedenen Speicherzugriffs-Muster zu erkennen, welche typischerweise mittels der einen oder den mehreren Operanden-Gruppen benutzt werden. Die Anweisung-Absetz-Einheit 504 bildet gestaltete Zugriffe, um effizient Operanden-Gruppen abzurufen, eines oder mehrere dieser Speicherzugriffs-Muster repräsentierend. In einer Ausführungsform separiert die Anweisung-Absetz-Einheit 504 die Bank von Registerdateien in zwei Abschnitte, Registerdateien 0–3 402(0)–402(3) und Registerdateien 4-7 402(4)–402(7). Für jeden dieser zwei Registerdatei-Abschnitte erzeugt die Anweisung-Absetz-Einheit 504 einen oder mehrere gestaltete Zugriffe. Die Anweisung-Absetz-Einheit 504 identifiziert die Stelle jedes Operanden innerhalb der Bank von Registerdateien. Die Anweisung-Absetz-Einheit 504 zeichnet die spezifischen Threads auf, welche den Operanden erfordern, die Registerdatei, welche den Operanden für jeden dieser Threads hält, und die Zeile innerhalb der Registerdatei, wo der Operand lokalisiert ist. Als nächstes wählt die Anweisung-Absetz-Einheit 504 einen der Operanden aus und bestimmt, ob der Operand ein Einzel-Breite-, Doppel-Breite oder Quadrupel-Breite-Operand ist. Die Anweisung-Absetz-Einheit 504 bildet logische Banken innerhalb des Abschnitts von Registerdateien gemäß der Operanden-Breite. Die Anweisung-Absetz-Einheit 504 bildet logische Banken innerhalb des Abschnitts der Registerdateien gemäß der Operand-Breite. Die Anweisung-Absetz-Einheit 504 bildet dann einen gestalteten Zugriff über die logische Bank, wo der ausgewählte Operand gespeichert ist, typischerweise konfiguriert, um dieselbe Zeilen-Adresse über die logische Bank zu lesen. Ähnlich wird ein Operand für die andere logische Bank innerhalb des Abschnitts von Registerdateien ausgewählt und ein gestalteter Zugriff ist für diese logische Bank auch gebildet. Der Prozess wird dann für den anderen Abschnitt von Registerdateien wiederholt. Weil die zwei Abschnitte von Registerdateien separat gehandhabt werden, können die Anordnung von logischen Banken und die gestalteter-Zugriff-Typen verschieden in jedem der beiden Abschnitte von Registerdateien sein.
  • Sobald die gestalteten Zugriffe korrekt identifiziert und konfiguriert sind, befähigt die Anweisung-Absetz-Einheit 504 der Registerdatei 506, die Register zu lesen, welche mit den gestalteten Zugriffen assoziiert sind, wie oben beschrieben ist. Die Anweisung-Absetz-Einheit 504 richtet die abgerufenen Operanden mit den entsprechenden Anweisungen aus und übermittelt die ausgerichteten Operanden an den Kollektor 508, wo die Operanden gespeichert werden. Als nächstes bestimmt die Anweisung-Absetz-Einheit 504, ob alle Operanden, welche mit dem momentanen Satz von Anweisungen assoziiert sind, gelesen worden sind, und gesammelt worden sind von der Registerdatei 506 und in dem Kollektor 508 gespeichert sind. Wenn zusätzliche Operanden zu lesen sind, dann hält die Anweisung-Absetz-Einheit 504 die Pipeline innerhalb des SM 310 an (stalls) und wiederholt den Prozess, welcher oben beschrieben ist, um zusätzliche gestaltete Zugriffe für die übrigen Operanden zu bilden. Der Prozess dauert an, bis alle Operanden, welche mit dem momentanen Satz von Anweisungen assoziiert sind, gelesen und gesammelt sind, bei welcher Zeit die Anweisungs-Absetz-Einheit 504 die Pipeline innerhalb des SM 310 fortführt (unstalls), um dadurch zu ermöglichen, dass die Anweisungen ausgeführt werden.
  • Ein Beispiel des vorangehenden Prozesses ist wie folgt. Man nehme an, dass die Anweisung-Absetz-Einheit 504 einen Doppel-Breite-Operanden für Thread 0 auswählen könnte, welcher bei Register 0-1 innerhalb des ersten Abschnitts von Registerdateien lokalisiert ist. Der Operand könnte in den unteren linken Zellen von Registerdatei 0 402(0) und Registerdatei 2 402(2) lokalisiert sein, wie in 4C gezeigt ist. Als ein Ergebnis würde die Anweisung-Absetz-Einheit 504 eine logische Bank 0 460(0) bilden, welche konfiguriert ist, Registerdatei 0 402(0) und Registerdatei 2 402(2) zu umfassen. Ähnlich würde die Anweisung-Absetz-Einheit 504 logische Bank 1 460(1) bilden, welche konfiguriert ist, Registerdatei 1 402(1) und Registerdatei 3 402(3) zu umfassen. Der resultierende gestaltete Zugriff würde auf zwei Sätze von Doppel-Breite-Operanden für jeden von vier Threads zugreifen. Ähnlich könnte die Anweisung-Absetz-Einheit 504 einen Einzel-Breite-Operanden für Thread 0 auswählen, welcher bei Register 4 innerhalb des zweiten Abschnitts von Registerdateien lokalisiert ist. Der Operand könnte in der unteren linken Zelle von Registerdatei 4 402(4) lokalisiert sein, wie in 4C gezeigt ist. Als ein Ergebnis würde die Anweisung-Absetz-Einheit 504 logische Bank 2 460(2) bilden, welche konfiguriert ist, Registerdatei 4 402(4) und Registerdatei 5 402(5) zu umfassen. Ähnlich würde die Anweisung-Absetz-Einheit 504 logische Bank 3 460(3) bilden, welche konfiguriert ist, Registerdatei 6 402(6) und Registerdatei 7 402(7) zu umfassen. Der resultierende gestaltete Zugriff würde auf zwei Sätze von Einzel-Breite-Operanden für jeden von acht Threads zugreifen. Sobald die gestalteten Zugriffe vollendet sind, würde die Anweisung-Absetz-Einheit 504 bestimmen, ob zusätzliche Operanden übrig sind. Wenn mehr Operanden zu sammeln sind, würde die Anweisung-Absetz-Einheit 504 die SM 310-Pipeline unterbrechen oder anhalten (stall), würde zusätzliche gestaltete Zugriffe bilden, um irgendwelche übrigen Operanden zu sammeln und würde dann die SM 310-Pipeline fortführen.
  • 6 ist ein Flussdiagramm von Verfahrensschritten zum Sammeln von Registerdatei-Operanden gemäß einer Ausführungsform der vorliegenden Erfindung. Obwohl die Verfahrensschritte im Zusammenhang mit den Systemen von 1 bis 5 beschrieben sind, werden Fachleute in der Technik verstehen, dass irgendein System, welches konfiguriert ist, die Verfahrensschritte durchzuführen, in irgendeiner Ordnung, innerhalb des Geltungsbereichs der vorliegenden Erfindung ist.
  • Wie gezeigt ist, beginnt das Verfahren 600 bei Schritt 602, wo die Anweisung-Absetz-Einheit 504 einen Satz von einer oder mehreren Anweisungen von dem Warp-Planer 502 empfängt. Jede Anweisung kann einen oder mehrere Operanden umfassen und kann geplant werden, einen oder mehrere Threads auszuführen. Bei Schritt 604 evaluiert die Anweisung-Absetz-Einheit 504 den Satz von Operanden, auf welche gemäß der einen oder mehreren Anweisung zugegriffen wird, um zu bestimmen, ob die Operanden in eines von mehreren erkannten gestalteter-Zugriff-Mustern passt. Zu dem Ausmaß, zu dem ein gestalteter-Zugriff-Muster erkannt ist, bildet die Anweisung-Absetz-Einheit 504 bei Schritt 606 einen gestalteten Registerdatei-Zugriff, um die Anweisungs-Operanden abzurufen. Bei Schritt 608 führt die Anweisung-Absetz-Einheit 504 den gestalteten Registerdatei-Zugriff dadurch aus, dass entsprechende Register-Adressen gesendet werden und Lesebefähigungen an die Registerdatei 506 gesendet werden. Bei Schritt 610 richtet die Anweisungs-Absetz-Einheit 504 die abgerufenen Operanden mit den entsprechenden Anweisungen aus. Bei Schritt 612 schreibt die Anweisung-Absetz-Einheit 504 die abgerufenen Operanden an den Kollektor 508.
  • Bei Schritt 614 bestimmt die Anweisung-Absetz-Einheit 504, ob alle Operanden abgerufen worden sind. Wenn nicht alle Operanden abgerufen worden sind, dann führt das Verfahren 600 zu Schritt 616 fort, wo die Anweisung-Absetz-Einheit 504 die Pipeline anhält, um zu verhindern, dass weitere Anweisungen in die Warp-Planer- und Anweisungs-Einheit 312 eintreten. Das Verfahren 600 kehrt dann zu Schritt 606 zurück, wo die Anweisung-Absetz-Einheit 504 einen anderen gestalteten Register-Zugriff bildet. Das Verfahren 600 führt fort, bis die Anweisung-Absetz-Einheit 504 bestimmt, bei Schritt 614, dass alle Operanden abgerufen worden sind. Das Verfahren 600 schreitet dann zu Schritt 618 fort, wo die Anweisung-Absetz-Einheit 504 die Pipeline weiterführt (unstalls), bei welchem Punkt das Verfahren 600 terminiert.
  • Zusammenfassend stellt die offenbarte Technik einen effizienten Weg bereit, um Operanden von einer Registerdatei abzurufen. Spezifisch empfängt die Anweisung-Absetz-Einheit 504 eine oder mehrere Anweisungen von dem Warp-Planer 502, wobei jede davon einen oder mehrere Operanden umfasst, welche über einen oder mehrere Threads hinweg auszuführen sind. Kollektiv werden die Operanden in eine oder mehrere Operanden-Gruppen organisiert, von welchen ein „gestalteter Zugriff” gebildet werden kann. Die Anweisung-Absetz-Einheit 504 ist konfiguriert, verschiedene Speicherzugriffs-Muster, welche mittels der Operanden-Gruppen benutzt werden, zu erkennen. Die Anweisung-Absetz-Einheit 504 bildet einen gestalteten Zugriff, welcher den Speicherzugriffs-Mustern entspricht. Die Operanden, welche den Registern entsprechen, welche mittels des gestalteten Zugriffs abgedeckt sind, werden von der Registerdatei 506 abgerufen und in einem Kollektor 508 gespeichert. Wenn alle Anweisungs-Operanden nicht gelesen sind und in dem Kollektor 508 nach dem gestalteten Zugriff gesammelt sind, dann hält die Anweisung-Absetz-Einheit 504 die Pipeline innerhalb des SM 310 an und bildet einen weiteren gestalteten Zugriff, um die zusätzlichen Operanden von der Registerdatei 506 abzurufen und die Operanden in dem Kollektor 508 zu speichern. Sobald alle Operanden gelesen sind und in dem Kollektor 508 gesammelt sind, führt die Anweisung-Absetz-Einheit 504 die Pipeline weiter und übermittelt die Anweisungen und die entsprechenden Operanden an funktionale Einheiten innerhalb des SM 310 zur Ausführung.
  • Vorteilhafter Weise werden mehrere Operanden von der Registerdatei 506 in einer einzelnen Register-Zugriffs-Operation ohne einen Ressourcen-Konflikt abgerufen. Wo Anweisungs-Operanden erkannte Speicherzugriffs-Muster benutzen, ist eine Performanz beim Abrufen von Operanden von der Registerdatei 506 dadurch verbessert, dass gestaltete Zugriffe gebildet werden, welche effizient Operanden abrufen, welche diese Zugriffs-Muster aufweisen. Ferner können die Registerdateien 402 innerhalb der Bank von Registerdateien flexibel in logische Banken angeordnet werden, um mehrere Operanden innerhalb eines Satzes von Anweisungen abzurufen. Somit kann jede Register-Zugriffs-Operation einen anderen gestalteten Zugriff haben, welcher eine andere logische-Bank-Anordnung benutzt, wie mittels des Satzes von Operanden gewährleistet ist. Die Anweisung-Absetz-Einheit 504 führt eine oder mehrere Register-Zugriffs-Operationen unter Benutzung von gestalteten Zugriffen durch, bis alle Operationen gelesen und gesammelt sind.
  • Während das Vorangehende auf Ausführungsformen der vorliegenden Erfindung gerichtet ist, können andere und weitere Ausführungsformen der Erfindung entworfen werden (devised), ohne von dem grundsätzlichen Geltungsbereich davon abzuweichen, und der Geltungsbereich davon ist mittels der Ansprüche bestimmt, welche folgen.

Claims (10)

  1. Computer implementiertes Verfahren zum Durchführen von Register-Speicher-Operationen, wobei das Verfahren aufweist: Empfangen einer Anweisung, welche über einer Mehrzahl von Operanden auszuführen ist; Erkennen, dass eine Mehrzahl von Registerdateien, in welcher die Mehrzahl von Operanden gespeichert ist, über ein bestimmtes Speicherzugriffs-Muster zugreifbar ist; Bilden einer gestalteter-Speicherzugriff-Operation, welche dem bestimmten Speicherzugriffs-Muster entspricht; und Durchführen der gestalteter-Speicherzugriff-Operation, um auf die Mehrzahl von Operanden aus der Mehrzahl von Registerdateien zuzugreifen.
  2. Subsystem zum Durchführen von Register-Speicher-Operationen, aufweisend: eine Anweisung-Absetz-Einheit, welche konfiguriert ist, um: eine Anweisung zu empfangen, welche über einer Mehrzahl von Operanden auszuführen ist; zu erkennen, dass eine Mehrzahl von Registerdateien, in welcher die Mehrzahl von Operanden gespeichert ist, über ein bestimmtes Speicherzugriffs-Muster zugreifbar ist; eine gestalteteter-Speicherzugriff-Operation zu bilden, welche dem bestimmten Speicherzugriffs-Muster entspricht; und die gestalteter-Speicherzugriffs-Operation durchzuführen, um auf die Mehrzahl von Operanden von der Mehrzahl von Registerdateien zuzugreifen.
  3. Subsystem von Anspruch 2, wobei die Anweisung-Absetz-Einheit ferner konfiguriert ist, die Mehrzahl von Operanden gemäß der Anweisung auszurichten; und die Mehrzahl von Operanden in einem Operanden-Kollektor zu speichern.
  4. Subsystem gemäß Anspruch 2, wobei Bilden der gestalteter-Speicherzugriff-Operation Bilden einer oder mehrerer logischer Banken aufweist, zu welchen zumindest ein Teil der Mehrzahl von Registerdateien gehört.
  5. Subsystem gemäß Anspruch 2, wobei die gestalteter-Speicherzugriff-Operation konfiguriert ist, auf Einzel-Breite-Operanden zuzugreifen.
  6. Subsystem gemäß Anspruch 2, wobei die gestalteter-Speicherzugriff-Operation konfiguriert ist, auf Doppel-Breite-Operanden zuzugreifen.
  7. Subsystem gemäß Anspruch 2, wobei die gestalteter-Speicherzugriff-Operation konfiguriert ist, auf Quadrupel-Breite-Operanden zuzugreifen.
  8. Subsystem gemäß Anspruch 2, wobei die gestalteter-Speicherzugriff-Operation konfiguriert ist, auf Operanden zuzugreifen, welche verschiedene Operanden-Breiten haben.
  9. Subsystem gemäß Anspruch 2, wobei die Anweisung-Absetz-Einheit ferner konfiguriert ist, die Anweisung zu übermitteln und zumindest die Mehrzahl von Operanden an eine funktionelle Einheit zur Ausführung zu übermitteln.
  10. Rechengerät, aufweisend: ein Subsystem, welches eine Anweisung-Absetz-Einheit umfasst, welche konfiguriert ist, um: eine Anweisung zu empfangen, welche über eine Mehrzahl von Operanden auszuführen ist; zu erkennen, dass eine Mehrzahl von Registerdateien, in welchen die Mehrzahl von Operanden gespeichert ist, über ein bestimmtes Speicherzugriffs-Muster zugreifbar ist; eine gestalteter-Speicherzugriff-Operation zu bilden, welche dem bestimmten Speicherzugriffs-Muster entspricht; und die gestalteter-Speicherzugriff-Operation durchzuführen, um auf die Mehrzahl von Operanden aus der Mehrzahl von Registerdateien zuzugreifen.
DE102012221502A 2011-12-06 2012-11-23 System und Verfahren zum Durchführen von gestalteter-Speicherzugriff-Operationen Pending DE102012221502A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US13/312,954 US10255228B2 (en) 2011-12-06 2011-12-06 System and method for performing shaped memory access operations
US13/312,954 2011-12-06

Publications (1)

Publication Number Publication Date
DE102012221502A1 true DE102012221502A1 (de) 2013-06-06

Family

ID=48431581

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102012221502A Pending DE102012221502A1 (de) 2011-12-06 2012-11-23 System und Verfahren zum Durchführen von gestalteter-Speicherzugriff-Operationen

Country Status (4)

Country Link
US (1) US10255228B2 (de)
CN (1) CN103218208B (de)
DE (1) DE102012221502A1 (de)
TW (1) TWI498819B (de)

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9817791B2 (en) * 2015-04-04 2017-11-14 Texas Instruments Incorporated Low energy accelerator processor architecture with short parallel instruction word
US11847427B2 (en) 2015-04-04 2023-12-19 Texas Instruments Incorporated Load store circuit with dedicated single or dual bit shift circuit and opcodes for low power accelerator processor
US9952865B2 (en) 2015-04-04 2018-04-24 Texas Instruments Incorporated Low energy accelerator processor architecture with short parallel instruction word and non-orthogonal register data file
GB2540971B (en) * 2015-07-31 2018-03-14 Advanced Risc Mach Ltd Graphics processing systems
US10768935B2 (en) * 2015-10-29 2020-09-08 Intel Corporation Boosting local memory performance in processor graphics
US10503474B2 (en) 2015-12-31 2019-12-10 Texas Instruments Incorporated Methods and instructions for 32-bit arithmetic support using 16-bit multiply and 32-bit addition
US10401412B2 (en) 2016-12-16 2019-09-03 Texas Instruments Incorporated Line fault signature analysis
US10866806B2 (en) * 2017-11-14 2020-12-15 Nvidia Corporation Uniform register file for improved resource utilization
CN111079908B (zh) * 2018-10-18 2024-02-13 上海寒武纪信息科技有限公司 片上网络数据处理方法、存储介质、计算机设备和装置
WO2020078470A1 (zh) 2018-10-18 2020-04-23 上海寒武纪信息科技有限公司 片上网络数据处理方法及装置
CN111459543B (zh) * 2019-01-21 2022-09-13 上海登临科技有限公司 一种管理寄存器文件单元的方法
US11436166B2 (en) * 2019-02-05 2022-09-06 Arm Limited Data processing systems
US11281496B2 (en) * 2019-03-15 2022-03-22 Intel Corporation Thread group scheduling for graphics processing
KR102201352B1 (ko) * 2019-04-03 2021-01-08 연세대학교 산학협력단 스핀 전달 토크 랜덤 액세스 메모리 기반의 계층적 레지스터 파일 장치
US10839478B2 (en) * 2019-04-08 2020-11-17 Intel Corporation Accumulator pooling mechanism
CN112817639B (zh) * 2021-01-13 2022-04-08 中国民航大学 Gpu读写单元通过操作数收集器访问寄存器文件的方法
CN114489792B (zh) * 2021-03-25 2022-10-11 沐曦集成电路(上海)有限公司 处理器装置及其指令执行方法
CN114281414B (zh) * 2021-12-29 2022-12-27 海飞科(南京)信息技术有限公司 Aigpu架构中urf寄存器的数据写入方法
CN114546329B (zh) * 2022-03-01 2023-07-18 上海壁仞智能科技有限公司 用于实现数据奇偶重排的方法、设备和介质
CN115904510B (zh) * 2023-02-15 2023-05-09 南京砺算科技有限公司 多操作数指令的处理方法、图形处理器及存储介质

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS55164961A (en) * 1979-06-11 1980-12-23 Canon Inc Calculator
US5513366A (en) 1994-09-28 1996-04-30 International Business Machines Corporation Method and system for dynamically reconfiguring a register file in a vector processor
US7219213B2 (en) * 2004-12-17 2007-05-15 Intel Corporation Flag bits evaluation for multiple vector SIMD channels execution
US7257695B2 (en) 2004-12-28 2007-08-14 Intel Corporation Register file regions for a processing system
US8966223B2 (en) * 2005-05-05 2015-02-24 Icera, Inc. Apparatus and method for configurable processing
US8321849B2 (en) 2007-01-26 2012-11-27 Nvidia Corporation Virtual architecture and instruction set for parallel thread computing
US10360039B2 (en) 2009-09-28 2019-07-23 Nvidia Corporation Predicted instruction execution in parallel processors with reduced per-thread state information including choosing a minimum or maximum of two operands based on a predicate value

Also Published As

Publication number Publication date
CN103218208A (zh) 2013-07-24
US10255228B2 (en) 2019-04-09
US20130145124A1 (en) 2013-06-06
TWI498819B (zh) 2015-09-01
CN103218208B (zh) 2016-05-04
TW201337751A (zh) 2013-09-16

Similar Documents

Publication Publication Date Title
DE102012221502A1 (de) System und Verfahren zum Durchführen von gestalteter-Speicherzugriff-Operationen
DE102013208554B4 (de) Verfahren und System zum Managen verschachtelter Ausführungsströme
DE102013100179A1 (de) Verfahren und System zum Auflösen von Thread-Divergenzen
DE102012222394A1 (de) Verfahren und Vorrichtung zum Sammelzwischenspeichern von Quelloperanden
DE102013209350B4 (de) Ressource-Management-Subsystem, welches Fairness und Ordnung einhält
DE102013022712B4 (de) Virtuelle Speicherstruktur für Coprozessoren, die Speicherallokationsbegrenzungen haben
DE102012222913A1 (de) Verfahren und Apparat zum Planen von Anweisungen unter Benutzung von Zuvor-Dekodieren-Daten
DE102012220029A1 (de) Spekulative Ausführung und Zurücksetzen
DE102013200991A1 (de) Automatisches abhängige-Aufgabe-Anstoßen
DE102012221504B4 (de) Mehrniveau-Anweisung-Zwischenspeicher-Zuvor-Holen
DE102013114072A1 (de) System und Verfahren zum Hardware-Scheduling von indexierten Barrieren
DE102012222558B4 (de) Signalisieren, Ordnen und Ausführung von dynamisch erzeugten Aufgaben in einem Verarbeitungs-System
DE102012212639A1 (de) Temporäre SIMT-Ausführungs-Optimierung
DE102012222918A1 (de) Verfahren und Apparat zum Planen von Anweisungen ohne Anweisungs-Dekodieren
DE102012220267B4 (de) Rechenarbeitsverteilungs - Referenzzähler
DE102013200997A1 (de) Ein blockierungsfreies FIFO
DE102013201178A1 (de) Steuern von Arbeitsverteilung für Verarbeitung von Tasks
DE102013205886A1 (de) Dynamische Bankmodus-Adressierung für Speicherzugriff
DE102013202495A1 (de) Verfahren zur Durchführung von interaktivem Debugging auf nicht unterbrechbaren Graphikverarbeitungseinheiten
DE102013202173A1 (de) Einheitliche Lade-Verarbeitung für Teilsätze von parallelen Threads
DE112010003750T5 (de) Hardware für parallele Befehlslistenerzeugung
DE102009012766A1 (de) Ein Zugriffssperrenvorgang, um atomare Aktualisierungen zu einem geteilten Speicher zu ermöglichen
DE102013017511A1 (de) Effiziente speichervirtualisierung in mehrsträngigen verarbeitungseinheiten
DE102012222932A1 (de) Gestaltetes Register-Datei-Lesen
DE102013114351A1 (de) System und Verfahren für Hardware-Disponierung bedingter Barrieren und ungeduldiger Barrieren

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R082 Change of representative

Representative=s name: KRAUS & WEISERT PATENTANWAELTE PARTGMBB, DE

R016 Response to examination communication