DE102013205886A1 - Dynamische Bankmodus-Adressierung für Speicherzugriff - Google Patents

Dynamische Bankmodus-Adressierung für Speicherzugriff Download PDF

Info

Publication number
DE102013205886A1
DE102013205886A1 DE102013205886A DE102013205886A DE102013205886A1 DE 102013205886 A1 DE102013205886 A1 DE 102013205886A1 DE 102013205886 A DE102013205886 A DE 102013205886A DE 102013205886 A DE102013205886 A DE 102013205886A DE 102013205886 A1 DE102013205886 A1 DE 102013205886A1
Authority
DE
Germany
Prior art keywords
memory
bank
thread
address
memory bank
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.)
Ceased
Application number
DE102013205886A
Other languages
English (en)
Inventor
Michael Fetterman
Stewart Glenn Carlton
Douglas J. Hahn
Rajeshwaran Selvanesan
Shirish Gadre
Steven James HEINRICH
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 DE102013205886A1 publication Critical patent/DE102013205886A1/de
Ceased legal-status Critical Current

Links

Images

Classifications

    • 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]
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Multimedia (AREA)
  • Advance Control (AREA)
  • Memory System Of A Hierarchy Structure (AREA)
  • Multi Processors (AREA)

Abstract

Eine Ausführungsform legt eine Technik zum dynamischen Mappen von Adressen von Speicherbänken eines Speichers auf mehrere Speicherbänke basierend auf einem Speicherbankmodus dar. Anwendungsprogramme mögen dazu konfiguriert sein, einen Speicher zu lesen oder schreiben, wobei auf unterschiedliche Anzähle von Bits pro Speicherbank zugegriffen werden, zum Beispiel auf 32 Bits pro Speicherbank, 64 Bits pro Speicherbank oder 128 Bits pro Speicherbank. Eine Zugriffsanforderung mag zu jedem Taktzyklus von einem der Anwendungsprogramme erhalten werden, und Adressen pro Verarbeitungsthread von der Zugriffsanforderung werden dynamisch gemappt basierend auf dem Speicherbankmodus, um einen Satz von Speicherbankadressen zu erzeugen. Die Speicherbankadressen werden dann verwendet, um auf den Multibank-Speicher zuzugreifen. Das Erlauben von unterschiedlichen Speicherbank-Mappings ermöglicht, dass jedes Anwendungsprogramm Speicherbankkonflikte beim Speicherzugreifen vermeidet in Vergleich mit der Verwendung von einem einzigen Speicherbank-Mapping für alle Zugriffe.

Description

  • HINTERGRUND DER ERFINDUNG
  • Gebiet der Erfindung
  • Die vorliegende Erfindung bezieht sich generell auf Parallelverarbeitung und spezifischer auf eine parallele Architektur, die dynamisches Mappen von Speicherbankadressen für Zugriffe auf Multibank-Speicher unterstützt.
  • Beschreibung des verwandten Standes der Technik
  • In einer einzelne-Instruktions-, mehrfache-Threads-(SIMT)-Verarbeitungsumgebung (engl. „single-instruction, multiple-thread (SIMT) processing environment”) sind Threads in Gruppen bestehend aus P parallelen Threads organisiert, die Warps genannt werden und das gleiche Programm ausführen. Obwohl die P Threads einer Threadgruppe jede Instruktion des Programmes parallel ausführen, führt jeder Thread einer Threadgruppe unter Verwendung seiner eigenen Daten und Register die Instruktion unabhängig aus. Jeder Thread in der Threadgruppe ist dazu konfiguriert, auf einen Multibank-Speicher zuzugreifen unter Verwendung eines festen Mappings von Adressen pro Thread (engl. „per-thread adresses”) auf die Speicherbänke des Multibank-Speichers. Wenn mehrere Threads auf zwei oder mehr Stellen in der gleichen Speicherbank zugreifen müssen, als innerhalb eines einzigen Taktzyklus zugegriffen werden können, dann liegt einen Speicherbankkonflikt vor.
  • Anwendungsprogramme sind typischerweise so geschrieben, dass Speicherbankkonflikte vermieden werden, wenn die parallele Threads einer Threadgruppe den Multibank-Speicher ausliest und beschreibt, so dass Daten für allen der parallelen Threads in der Threadgruppe in einem einzigen Taktzyklus gelesen oder geschrieben werden mögen. Ein Programm mag zum Beispiel so geschrieben werden, dass von einer Threadgruppe auf entweder eine Zeile oder eine Säule von einem Array von Daten zugegriffen werden mag, ohne einen Speicherbankkonflikt. Wenn Speicherbankkonflikte auftreten, müssen die Zugriffe für Adressen, die auf die gleiche Speicherbank gemappt sind, in separaten Taktzyklen durchgeführt werden, wobei die Performance reduziert wird.
  • Folglich ist das, was auf dem technischen Gebiet benötigt wird, ein Verfahren zur Vermeidung von Speicherbankkonflikten, wenn parallele Threads einer Threadgruppe auf einen Multibank-Speicher zugreifen.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Ein System und Verfahren zur Verarbeitung einer Speicherzugriffsanforderung für parallele Threads von einer Threadgruppe, die auf einen Multibank-Speicher zugreifen, unterstützt verschiedene Datenbank-Bitbreiten. Adressen pro Thread werden auf Speicherbänke eines Speichers basierend auf einem Speicherbankmodus gemappt, der eine Bitbreite pro Speicherbank definiert. Anwendungsprogramme mögen zum Lesen und Schreiben eines Speichers konfiguriert sein, wobei auf unterschiedliche Anzähle von Bits pro Speicherbank zugegriffen werden, zum Beispiel auf 32 Bits pro Speicherbank, 64 Bits pro Speicherbank oder 128 Bits pro Speicherbank. Eine Zugriffsanforderung und ein Speicherbankmodus mag zu jedem Taktzyklus für ein der Anwendungsprogramme erhalten werden, und Adressen pro Verarbeitungsthread von der Zugriffsanforderung werden basierend auf dem Speicherbankmodus dynamisch gemappt, um einen Satz von Speicherbankadressen zu erzeugen. Die Speicherbankadressen werden dann verwendet, um auf den Speicher zuzugreifen. Das Erlauben von unterschiedlichen Speicherbank-Mappings basierend auf einem Speicherbankmodus, der für jede Speicherzugriffsanforderung spezifisch ist, ermöglicht, dass jedes Anwendungsprogramm Speicherbankkonflikte vermeidet in Vergleich mit der Verwendung von einem einzigen Speicherbank-Mapping für alle Zugriffe.
  • Verschiedene Ausführungsformen eines erfindungsgemäßen Verfahrens zum Zugreifen auf einen Multibank-Speicher weisen ein Erhalten einer Speicherzugriffsinstruktion auf, die eine individuelle Speicheradresse spezifiziert. Ein Speicherbankmodus, der eine Bitbreite pro Speicherbank definiert, wird erhalten und die individuelle Speicheradresse wird dynamisch gemappt, basierend auf dem Speicherbankmodus, um eine gemappte individuelle Speicheradresse zu erzeugen. Eine Leseanforderung oder eine Schreibeanforderung wird dann an den Multibank-Speicher gesendet, um die Speicherzugriffsinstruktion für die gemappte individuelle Speicheradresse auszuführen.
  • Verschiedene Ausführungsformen der Erfindung enthalten ein Verarbeitungssubsystem zum Zugreifen auf einen Multibank-Speicher. Das Verarbeitungssubsystem weist eine Adressenerzeugungseinheit und eine Laden/Speichern-Einheit auf, die zwischen der Adressenerzeugungseinheit und einem Multibank-Speicher gekoppelt ist. Die Adressenerzeugungseinheit ist konfiguriert zum Erhalten einer Speicherzugriffsinstruktion, die eine individuelle Speicheradresse spezifiziert. Die Adressenerzeugungseinheit ist auch konfiguriert zum Erhalten eines Speicherbankmodus, der eine Bitbreite pro Speicherbank spezifiziert, und mappt die individuelle Speicheradresse dynamisch basierend auf dem Speicherbankmodus, um eine gemappte individuelle Speicheradresse zu erzeugen. Die Laden/Speichern-Einheit ist konfiguriert zum Senden einer Leseanforderung oder einer Schreibeanforderung an den Multibank-Speicher, um die Speicherzugriffsinstruktion für die gemappte individuelle Speicheradresse auszuführen.
  • Es ist ein Vorteil des offenbarten Verfahrens, dass die Adresse-auf-Speicherbank-Mapping, das zum Zugreifen auf einen Multibank-Speicher verwendet wird, für jeden Taktzyklus geändert werden mag. Jede Speicheradresse, die für parallelen Thread in einer Threadgruppe spezifiziert ist, wird basierend auf dem Speicherbankmodus, der für die Speicherzugriffsanforderung spezifiziert ist, dynamisch auf eine Speicherbankadresse gemappt. Ein erstes Anwendungsprogramm, das zum Vermeiden von Speicherbankkonflikten, wenn jede Speicherbank 32 Bits von Daten speichert, geschrieben ist, mag folglich eine andere Speicheradresse-auf-Speicherbankadresse-Mapping verwenden, in Vergleich mit einem zweiten Anwendungsprogramm, das zum Vermeiden von Speicherbankkonflikten geschrieben ist, wenn jede Speicherbank 64 Bits von Daten speichert. Zusammengefasst mag ein älteres (engl. „legacy”) Anwendungsprogramm bzw. ein Altanwendungsprogramm, das zur Ausführung von einem Prozessor, der eine erste Speicherbankgröße aufweist, geschrieben wurde, ausgeführt werden, ohne eine Performanceverringerung zu verursachen, wenn es auf einem zeitgemäßen Prozessor ausgeführt wird, der dazu fähig ist, Speicheradressen dynamisch zu mappen, um sowohl die erste Speicherbankgröße als auch größere Speicherbankgrößen zu unterstützen, die für Operationen mit größeren Bitbreite benötigt werden, die von dem zeitgemäßen Prozessor ausgeführt werden.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • So dass die Art und Weise, in der die oben angeführten Merkmale der vorliegenden Erfindung im Detail verstanden werden kann, mag eine detailliertere Beschreibung der Erfindung, die oben kurz zusammengefasst wurde, durch Bezugnahme auf Ausführungsformen gehabt haben, von denen einige in der angehängten Zeichnungen dargestellt sind. Es muss aber bemerkt werden, dass die angehängten Zeichnungen nur typische Ausführungsformen dieser Erfindung illustrieren und somit nicht als den Umfang der Erfindung beschränkend angesehen werden dürfen, da die Erfindung andere gleich effektive Ausführungsformen zulassen mag.
  • 1 ist ein Blockdiagramm, das ein Computersystem zeigt, das zum Implementieren eines oder mehrerer Aspekte der vorliegenden Erfindung konfiguriert ist;
  • 2 ist ein Blockdiagramm von einem Parallelverarbeitungssubsystem für das Computersystem von 1, gemäß einer Ausführungsform der vorliegenden Erfindung;
  • 3A ist ein Blockdiagramm von dem Frontend der 2, gemäß einer Ausführungsform der vorliegenden Erfindung;
  • 3B ist ein Blockdiagramm von einem Allgemeinverarbeitungscluster innerhalb einer der Parallelverarbeitungseinheiten von 2, gemäß einer Ausführungsform der vorliegenden Erfindung;
  • 3C ist ein Blockdiagramm von einem Teil des Streaming-Multiprozessors von 3B, gemäß einer Ausführungsform der vorliegenden Erfindung;
  • 4A ist ein Blockdiagramm von dem Laden/Speichern-Einheit-(LSU)-Array und gemeinsamen Speicher von 3C, gemäß einer Ausführungsform der Erfindung;
  • 4B ist ein Konzeptdiagramm, das ein Mapping von einem 8×8-Array von 32-Bit Daten auf 8 32-Bit Datenbänke darstellt, gemäß einer Ausführungsform der Erfindung;
  • 4C ist ein Konzeptdiagramm, das eine Mapping von einem 8×8-Array von 32-Bit Daten auf 8 64-Bit Datenbänke darstellt, gemäß einer Ausführungsform der Erfindung;
  • 4D ist ein Konzeptdiagramm, das eine andere Mapping von einem 8×8-Array von 32-Bit Daten auf 8 64-Bit Datenbänke darstellt, gemäß einer Ausführungsform der Erfindung; und
  • 5 stellt ein Flussdiagramm von Verfahrensschritten zum Verarbeiten einer Zugriffsanforderung für einen Multibank-Speicher dar, gemäß einer Ausführungsform der vorliegenden Erfindung.
  • DETAILLIERTE BESCHREIBUNG
  • In der folgenden Beschreibung werden zahlreiche spezifische Details dargestellt, um ein eingehenderes Verständnis der vorliegenden Erfindung bereitzustellen. Es wird aber für einen Fachmann offenkundig sein, dass die vorliegende Erfindung auch ohne ein oder mehrere von diesen spezifischen Details ausgeübt werden kann.
  • Systemübersicht
  • 1 ist ein Blockdiagramm, das ein Computersystem 100 zeigt, das zum Implementieren eines oder mehrerer Aspekte der vorliegenden Erfindung konfiguriert ist. Das Computersystem 100 weist eine zentrale Verarbeitungseinheit (engl. „central processing unit”) (CPU) 102 und einen Systemspeicher 104 auf, die über einen Verbindungspfad (engl. „interconnection path”), der eine Speicherbrücke 105 aufweisen mag, miteinander in Verbindung stehen bzw. kommunizieren. Die Speicherbrücke 105, die zum Beispiel ein Northbridge-Chip sein mag, ist über einen Bus oder einen anderen Kommunikationspfad 106 (zum Beispiel einen HyperTransport-Links) mit einer I/O-(Input/Output)-Brücke 107 verbunden. Die I/O-Brücke 107, welche zum Beispiel ein Southbridge-Chip sein mag, erhält User-Input von einer oder mehreren User-Input-Vorrichtungen 108 (zum Beispiel Tastatur, Maus) und leitet den Input über den Kommunikationspfad 106 und die Speicherbrücke 105 an die CPU 102 weiter. Ein Parallelverarbeitungssubsystem 112 ist über einen Bus oder einen zweiten Kommunikationspfad 113 (zum Beispiel einen Peripheral Component Interconnect (PCI) Express, einen beschleunigten Grafikport (engl. „Accelerated Graphics Port”), oder einen HyperTransport-Link) an die Speicherbrücke 105 gekoppelt; in einer Ausführungsform ist das Parallelverarbeitungssubsystem 112 ein Grafiksubsystem, das Pixel zu einer Displayvorrichtung 110 (zum Beispiel einem konventionellen auf Kathodenstrahlröhre oder Flüssigkristalldisplay basierten Monitor) liefert. Eine Systemdisk 114 ist auch mit der I/O-Brücke 107 verbunden. Ein Switch 116 stellt Verbindungen zwischen der I/O-Brücke 107 und anderen Bauteilen, wie zum Beispiel einem Netzwerkadapter 118 und verschiedenen Erweiterungskarten (engl. „add-in cards”) 120 und 121, bereit. Andere (nicht explizit dargestellte) Bauteile, einschließlich „universal serial bus” (USB) oder anderer Portanschlüsse (engl. „port connections”), „compact disc”-(CD)-Laufwerke, „digial video disc”-(DVD)-Laufwerke, Filmaufzeichnungsvorrichtungen und ähnliches, mögen auch mit der I/O-Brücke 107 verbunden sein. Die verschiedene Verbindungspfade, die in 1 gezeigt sind, einschließlich der spezifisch benannten Kommunikationspfade 106 und 113, mögen unter Verwendung von jeglichen geeigneten Protokollen, wie zum Beispiel PCI-Express, AGP (engl. „Accelerated Graphics Port”), HyperTransport oder jedem anderen Bus oder Punkt-zu-Punkt-Kommunikationsprotokoll(en) (engl. „Point-to-Point Communication Protocol(s)”) implementiert sein, und Verbindungen zwischen verschiedenen Vorrichtungen mögen verschiedene Protokolle benutzen, wie es aus dem Stand der Technik bekannt ist.
  • Das Parallelverarbeitungssubsystem 112 weist in einer Ausführungsform Schaltkreise auf, die für Grafik- und Videoverarbeitung optimiert sind, einschließlich zum Beispiel Videoausgabeschaltkreise, und stellt eine Grafikverarbeitungseinheit (GPU) dar. In einer anderen Ausführungsform weist das Parallelverarbeitungssubsystem 112 Schaltkreise auf, die für Universalverarbeitung (engl. „general purpose processing”) optimiert sind, während die unterliegende rechnerische Architektur aufrechterhalten wird (wie es hierin detaillierter beschrieben wird). In noch einer anderen Ausführungsform mag das Parallelverarbeitungssubsystem 112 mit einem oder mehreren anderen Systemelementen in einem einzigen Subsystem integriert sein, wie zum Beispiel durch Zusammenfügen der Speicherbrücke 105, der CPU 102 und der I/O-Brücke 107, um ein System-auf-Chip (engl. „system an chip”) (SoC) zu bilden.
  • Es wird verstanden werden, dass das hierin gezeigte System illustrativ ist und dass Variationen und Modifikationen möglich sind. Die Verbindungstopologie, einschließlich der Anzahl und Anordnung von Brücken, der Anzahl von CPUs 102 und der Anzahl von Parallelverarbeitungssubsystemen 112, mag wie gewünscht variiert werden. In einigen Ausführungsformen ist der Systemspeicher 104 zum Beispiel direkt mit der CPU 102 verbunden, statt durch eine Brücke, und andere Vorrichtungen kommunizieren über die Speicherbrücke 105 und die CPU 102 mit dem Systemspeicher 104. In anderen alternativen Topologien ist das Parallelverarbeitungssubsystem 112 mit der I/O-Brücke 107 oder direkt mit der CPU 102 verbunden, statt mit der Speicherbrücke 105. In noch anderen Ausführungsformen mögen die I/O-Brücke 107 und Speicherbrücke 105 in einem einzigen Chip integriert sein, statt als eine oder mehr diskrete Vorrichtungen zu existieren. Große Ausführungsformen mögen zwei oder mehr CPUs 102 und zwei oder mehr Parallelverarbeitungssubsysteme 112 aufweisen. Die jeweiligen hierin gezeigten Bauteile sind optional; zum Beispiel mag jede Anzahl von Erweiterungskarten oder Peripherievorrichtungen unterstützt werden. In einigen Ausführungsformen ist der Switch 116 entfernt und der Netzwerkadapter 118 und die Erweiterungskarten 120, 121 sind direkt mit der I/O-Brücke 107 verbunden.
  • 2 zeigt ein Parallelverarbeitungssubsystem 112 gemäß einer Ausführungsform der vorliegenden Erfindung. Das Parallelverarbeitungssubsystem 112 weist, wie gezeigt, eine oder mehr Parallelverarbeitungseinheiten (engl. „Parallel Processing Units”) (PPUs) 202 auf, wobei jede von denen an einen lokalen Parallelverarbeitungs-(PP)-Speicher 204 gekoppelt ist. Im Allgemeinen weist ein Parallelverarbeitungssubsystem eine Anzahl U von PPUs auf, wobei U ≥ 1. (Hierin werden mehrere Instanzen ähnlicher Objekte mit Bezugszeichen, die das Objekt identifizieren, und Ziffern in Klammern, die, wenn nötig, die Instanz identifizieren, gekennzeichnet.) Die PPUs 202 und die Parallelverarbeitungsspeicher 204 mögen unter Verwendung einer oder mehrerer integrierten Schaltungsvorrichtungen implementiert werden, wie zum Beispiel programmierbare Prozessoren, anwendungsspezifische integrierte Schaltungen (engl. „Application Specific Integrated Circuits”) (ASICs) oder Speichervorrichtungen, oder in jeder anderen technisch realisierbaren Art und Weise.
  • In einigen Ausführungsformen sind, wieder mit Bezug sowohl auf 1 als auch auf 2, einige oder alle der PPUs 202 in dem Parallelverarbeitungssubsystem 112 Grafikprozessoren mit Rendering-Pipelines, die dazu konfiguriert werden können, verschiedene Operationen in Bezug auf das Erzeugen von Pixeldaten aus Grafikdaten, die von der CPU 102 und/oder dem Systemspeicher 104 über die Speicherbrücke 105 und den zweiten Kommunikationspfad 113 bereitgestellt werden, auszuführen, mit lokalem Parallelverarbeitungsspeicher 204 (der als Grafikspeicher einschließlich, zum Beispiel, eines konventionellen Framepuffers benutzt werden kann) zu interagieren, um Pixeldaten zu speichern und zu aktualisieren, Pixeldaten an die Displayvorrichtung 110 zu übermitteln, und ähnliches. In einigen Ausführungsformen mag das Parallelverarbeitungssubsystem 112 eine oder mehrere PPUs 202 aufweisen, die als Grafikprozessoren arbeiten, und eine oder mehrere PPUs 202, die für Universalberechnungen (engl. „general-purpose computations”) benutzt werden. Die PPUs mögen identisch oder unterschiedlich sein, und jede PPU mag eine dedizierte(n) Parallelverarbeitungsspeichervorrichtung(en) oder keine dedizierte(n) Parallelverarbeitungsspeichervorrichtung(en) aufweisen. Eine oder mehrere der PPUs 202 in dem Parallelverarbeitungssystem 112 mag bzw. mögen Daten an eine Displayvorrichtung 110 ausgeben oder jede PPU 202 in dem Parallelverarbeitungssystem 112 mag Daten an eine oder mehrere Displayvorrichtungen 110 ausgeben.
  • Im Betrieb ist die CPU 102 der Masterprozessor des Computersystems 100, welcher den Betrieb anderer Systembauteile steuert und koordiniert. Die CPU 102 erteilt insbesondere Befehle, die den Betrieb der PPUs 202 steuern. In einigen Ausführungsformen schreibt die CPU 102 einen Befehlsstrom für jede PPU 202 in eine (weder in 1 noch in 2 explizit gezeigte) Datenstruktur, die sich im Systemspeicher 104, Parallelverarbeitungsspeicher 204 oder in einer anderen Speicherstelle befinden mag, die für sowohl die CPU 102 als auch die PPU 202 zugreifbar ist. Ein Zeiger auf jede Datenstruktur wird in einen Stoßpuffer (engl. „push puffer”) geschrieben, um Verarbeitung des Befehlsstroms in der Datenstruktur zu initiieren. Die PPU 202 liest Befehlsströme aus einem oder mehreren Stoßpuffern aus und führt dann Befehle asynchron relativ zu dem Betrieb der CPU 102 aus. Ausführungsprioritäten mögen von einem Applikationsprogramm über den Gerätetreiber 103 für jeden Stoßpuffer festgelegt werden, um das Scheduling der verschiedenen Stoßpuffer zu steuern.
  • Jetzt wird sowohl auf 2 als auch auf 1 Rückbezug genommen und jede PPU 202 weist eine I/O-(Input/Output)-Einheit 205 auf, die mit dem restlichen Computersystem 100 über Kommunikationspfad 113 kommuniziert, der mit der Speicherbrücke 105 (oder in einer alternativen Ausführungsform direkt mit der CPU 102) in Verbindung steht. Die Verbindung der PPU 202 an das restliche Computersystem 100 mag auch variiert werden. In einigen Ausführungsformen ist das Parallelverarbeitungssubsystem 112 als eine Erweiterungskarte implementiert, die in einen Erweiterungsslot (engl. „expansion slot”) des Computersystems 100 eingebracht werden kann. In anderen Ausführungsformen kann eine PPU 202 auf einem einzigen Chip mit einer Busbrücke, wie zum Beispiel Speicherbrücke 105 oder I/O-Brücke 107, integriert sein. In noch anderen Ausführungsformen mögen einige oder alle Elemente der PPU 202 auf einem einzigen Chip mit der CPU 102 integriert sein.
  • In einer Ausführungsform ist der Kommunikationspfad 113 ein PCI-Express-Anschluss (engl. „PCI-Express Link”), in welchem jeder PPU 202 dedizierte Spuren zugewiesen sind, wie es auf dem technischen Gebiet bekannt ist. Andere Kommunikationspfade mögen auch benutzt werden. Eine I/O-Einheit 205 erzeugt Pakete (oder andere Signale) für Transmission auf dem Kommunikationspfad 113 und empfängt auch alle ankommenden Pakete (oder anderen Signale) von dem Kommunikationspfad 113, wobei die ankommenden Pakete zu zweckmäßigen Bauteilen der PPU 202 geleitet werden. Befehle, die sich auf Bearbeitungstasks beziehen, mögen zum Beispiel zu einer Hostschnittstelle (engl. „host interface”) 206 geleitet werden, während Befehle, die sich auf Speichervorgänge (zum Beispiel Auslesen aus oder Schreiben auf den Parallelverarbeitungsspeicher 204) beziehen, zu einer Speicher-Kreuzschieneneinheit 210 geleitet werden mögen. Die Hostschnittstelle 206 liest jeden Stoßpuffer aus und gibt den Befehlsstrom, der in dem Stoßpuffer gespeichert ist, zu einem Frontend 212 aus.
  • Jede PPU 202 implementiert vorteilhafterweise eine in hohem Maße parallele Verarbeitungsarchitektur. Die PPU 202(0) weist, wie im Detail gezeigt, ein Verarbeitungscluster-Array (engl. „processing cluster array”) 230 auf, das eine Anzahl C von Allgemeinverarbeitungsclustern (engl. „general processing clusters”) (GPCs) 208 aufweist, wobei C ≥ 1. Jeder GPC 208 ist in der Lage, eine große Anzahl (zum Beispiel hunderte oder tausende) von Threads gleichzeitig auszuführen, wobei jeder Thread eine Instanz eines Programms ist. In verschiedenen Applikationen mögen unterschiedlichen GPCs 208 zur Verarbeitung unterschiedlicher Arten von Programmen oder zum Ausführen unterschiedlicher Arten von Berechnungen allokiert werden. Das Allokieren von GPCs 208 mag in Abhängigkeit von der Auslastung variieren, die für jede Art von Programm oder Berechnung entsteht.
  • Die GPCs 208 empfangen auszuführende Verarbeitungstasks von einer Arbeitsverteilungseinheit innerhalb einer Task/Arbeit-Einheit (engl. „task/work unit”) 207. Die Arbeitsverteilungseinheit empfängt Zeiger auf Rechenverarbeitungstasks, die als Taskmetadaten (engl. „task metadata”) (TMD) kodiert und im Speicher gespeichert sind. Die Zeiger auf TMDs sind in den Befehlsstrom beinhaltet, der als ein Stoßpuffer gespeichert und mittels der Frontend-Einheit 212 von der Host-Schnittstelle 206 empfangen wird. Verarbeitungstasks, die als TMDs kodiert werden mögen, beinhalten Indices von zu verarbeitenden Daten sowie Zustandsparameter und Befehle, die definieren wie die Daten zu verarbeiten sind (zum Beispiel welches Programm auszuführen ist). Die Task/Arbeit-Einheit 207 empfängt Tasks von dem Frontend 212 und stellt sicher, dass die GPCs 208 zu einem gültigen Zustand konfiguriert sind, bevor die von jedem einzelnen der TMDs spezifizierte Verarbeitung eingeleitet wird. Eine Priorität mag für jede TMD, die zum Scheduling der Ausführung der Verarbeitungstasks benutzt wird, spezifiziert sein. Verarbeitungstasks können auch von dem Verarbeitungsclusterarray 230 erhalten werden. Die TMD können wahlweise einen Parameter enthalten, die steuert, ob die TMD zu dem Kopf oder Ende einer Liste von Verarbeitungstasks (oder Liste von Zeigern auf die Verarbeitungstasks) hinzugefügt werden soll, wobei eine weitere Stufe der Steuerung über Priorität bereitgestellt wird.
  • Die Speicherschnittstelle 214 weist eine Anzahl D von Partitionseinheiten 215 auf, die jeweils direkt an einen Teil des Parallelverarbeitungsspeichers 204 gekoppelt sind, wobei D ≥ 1. Die Anzahl der Partitionseinheiten 215 ist, wie gezeigt, generell gleich der Anzahl von dynamischen Direktzugriffspeicher (engl. „dynamic random access memory”) (DRAM) 220. In anderen Ausführungsformen mag die Anzahl der Partitionseinheiten 215 nicht gleich der Anzahl der Speichervorrichtungen sein. Fachleute werden verstehen, dass DRAM 220 durch andere geeignete Speichervorrichtungen ersetzt werden mag und von einer generell konventionellen Bauform sein kann. Eine detaillierte Beschreibung wird deswegen weggelassen. Render-Ziele, wie zum Beispiel Puffer- oder Strukturpläne, mögen quer über die DRAMs 220 gespeichert werden, was den Partitionseinheiten 215 ermöglicht, Teile von jedem Render-Ziel parallel zu schreiben, um die vorhandene Bandbreite des Parallelverarbeitungsspeichers 204 effizient zu nutzen.
  • Jeder der GPCs 208 mag Daten verarbeiten, die in irgendeinen der DRAMs 220 innerhalb des Parallelverarbeitungsspeichers 204 zu schreiben sind. Die Kreuzschieneneinheit 210 ist dazu konfiguriert, den Output jedes GPC 208 an den Input einer jeden Partitionseinheit 215 oder an einen anderen GPC 208 für weitere Verarbeitung zu leiten. Die GPCs 208 kommunizieren mit der Speicherschnittstelle 214 durch die Kreuzschieneneinheit 210, um aus bzw. in verschiedenen externen Speichervorrichtungen auszulesen bzw. zu schreiben. In einer Ausführungsform hat die Kreuzschieneneinheit 210 sowohl eine Verbindung zu der Speicherschnittstelle 214, um mit der I/O-Einheit 205 zu kommunizieren, als auch eine Verbindung zu dem lokalen Parallelverarbeitungsspeicher 204, wodurch es den Verarbeitungskernen innerhalb der verschiedenen GPCs 208 ermöglicht werden, mit dem Systemspeicher 104 oder einem anderen Speicher, der kein lokaler Teil der PPU 202 ist, zu kommunizieren. In der in 2 gezeigten Ausführungsform ist die Kreuzschieneneinheit 210 direkt mit der I/O-Einheit 205 verbunden. Die Kreuzschieneneinheit 210 mag virtuelle Kanäle benutzen, um Datenverkehrsströme zwischen den GPCs 208 und den Partitionseinheiten 215 zu separieren.
  • Wie erwähnt können die GPCs 208 zum Ausführen von Verarbeitungstasks, die sich auf eine umfangreiche Vielfalt von Applikationen beziehen, programmiert werden, einschließlich, aber nicht begrenzt auf, linearer und nicht-linearer Datentransformationen, Filtern von Video- und/oder Audiodaten, Modellierungsvorgänge (zum Beispiel der Anwendung von physikalischen Gesetzen zum Bestimmen von Position, Geschwindigkeit und anderen Eigenschaften von Objekten), Bild-Rendering-Vorgängen (zum Beispiel Mosaikshader-, Scheitelshader-, Geometrieshader- und/oder Pixel-Shaderprogramme (engl. „tesselation shader, vertex shader, geometry shader, and/or pixel shader programs”)), usw. Die PPUs 202 mögen Daten von dem Systemspeicher 104 und/oder den lokalen Parallelverarbeitungsspeichern 204 in einen internen (auf-dem-Chip) Speicher hinein übertragen, die Daten verarbeiten und die Ergebnisdaten zurück in den Systemspeicher 104 und/oder die lokalen Parallelverarbeitungsspeicher 204 schreiben, wo auf solche Daten von anderen Systembauteilen, einschließlich CPU 102 oder anderer Parallelverarbeitungssubsysteme 112, zugegriffen werden kann.
  • Eine PPU 202 mag mit jeder Menge lokaler Parallelverarbeitungsspeicher 204, einschließlich keiner lokalen Speicher, ausgestattet sein, und mag lokalen Speicher und Systemspeicher in jeder beliebigen Kombination benutzen. Eine PPU 202 kann zum Beispiel ein Grafikprozessor in einer Ausführungsform mit „unified memory architecture” (UMA) sein. In solchen Ausführungsformen würde wenig oder kein dedizierter Grafik-(Parallelverarbeitungs-)Speicher bereitgestellt werden, und die PPU 202 würde ausschließlich oder fast ausschließlich den Systemspeicher benutzen. In UMA-Ausführungsformen mag eine PPU 202 in einem Brückenchip oder Prozessorchip integriert sein oder als ein diskreter Chip mit einem Hochgeschwindigkeitsanschluss (beispielsweise PCI-Express), der die PPU 202 über einen Brückenchip oder ein anderes Kommunikationsmittel mit dem Systemspeicher verbindet, bereitgestellt werden.
  • Wie oben erwähnt, kann eine beliebige Anzahl von PPUs 202 in einem Parallelverarbeitungssubsystem 112 enthalten sein. Mehrere PPUs 202 können zum Beispiel auf einer einzigen Erweiterungskarte bereitgestellt werden oder mehrere Erweiterungskarten können mit dem Kommunikationspfad 113 verbunden werden oder eine oder mehrere der PPUs 202 können in einem Brückenchip integriert werden. Die PPUs 202 in einem Mehrfach-PPU-System mögen gleich oder unterschiedlich voneinander sein. Unterschiedliche PPUs 202 mögen zum Beispiel eine jeweils unterschiedliche Anzahl von Prozessorkernen, unterschiedliche Mengen von lokalem Parallelverarbeitungsspeicher usw. aufweisen. Wenn mehrere PPUs 202 vorhanden sind, mögen diese PPUs parallel betrieben werden, um Daten mit einem größeren Durchsatz, als es mit einer einzigen PPU 202 möglich ist, zu verarbeiten. Systeme, die eine oder mehrere PPUs 202 aufweisen, mögen in einer Vielfalt von Konfigurationen und Formfaktoren implementiert werden, einschließlich Desktop-, Laptop- oder handgeführter Rechner, Server, Arbeitsstationen (engl. „workstations”), Spielkonsolen, eingebetteter Systeme und ähnliches.
  • Scheduling von mehreren gleichzeitigen Tasks (engl. „Multiple Concurrent Task Scheduling”)
  • Mehrere Verarbeitungstasks mögen gleichzeitig auf den GPCs 208 ausgeführt werden und ein Verarbeitungstask mag während der Ausführung ein oder mehrere „Kind”-Verarbeitungstasks (engl. „„child” processing tasks”) erzeugen. Die Task/Arbeit-Einheit 207 empfängt die Tasks und legt dynamisch die Ausführung der Bearbeitungstasks und der Kind-Verarbeitungstasks mittels der GPCs 208 zeitlich fest.
  • 3A ist ein Blockdiagramm von der Task/Arbeit-Einheit 207 von der 2, gemäß einer Ausführungsform der vorliegenden Erfindung. Die Task/Arbeit-Einheit 207 weist eine Taskmanagementeinheit 300 und die Arbeitsverteilungseinheit 340 auf. Die Taskmanagementeinheit 300 organisiert die Tasks, die zu schedulen sind, basierend auf Ausführungsprioritätsstufen. Für jede Prioritätsstufe speichert die Taskmanagementeinheit 300 eine Liste von Zeigern auf die TMDs 322, die den Tasks in der Schedulertabelle 321 entsprechen, wobei die Liste als eine verbundene Liste implementiert werden mag. Die TMDs 322 mögen in dem PP-Speicher 204 oder in dem Systemspeicher 104 gespeichert sein. Die Rate, mit welcher die Taskmanagementeinheit 300 Tasks akzeptiert und die Tasks in der Schedulertabelle 321 speichert, ist von der Rate entkoppelt, mit der die Taskmanagementeinheit 300 die Ausführung von Tasks zeitlich festlegt (engl. „schedules”). Folglich mag die Taskmanagementeinheit 300 mehrere Tasks sammeln, bevor er deren Ausführung zeitlich festlegt. Die gesammelten Tasks mögen dann basierend auf Prioritätsinformation oder unter Verwendung anderer Techniken, wie zum Beispiel Rundlauf-Scheduling (engl. „round-robin scheduling”), geschedulet werden.
  • Die Arbeitsverteilungseinheit 340 weist eine Tasktabelle 345 mit Slots auf, die jeweils von den TMD 322 für einen Task, der ausgeführt wird, belegt sein mögen. Die Taskmanagementeinheit 300 mag die Tasks zur Ausführung schedulen, wenn es einen freien Slot in der Tasktabelle 345 gibt. Wenn es keinen freien Slot gibt, mag ein Task mit höherer Priorität, der keinen Slot belegt, einen Task mit niedrigerer Priorität vertreiben, der einen Slot belegt. Wenn ein Task vertrieben wird, wird der Task gestoppt, und falls die Ausführung des Tasks nicht abgeschlossen ist, dann wird ein Zeiger auf den Task zu einer Liste von Taskzeigern, die gescheduled werden sollen hinzugefügt, so dass die Ausführung des Tasks zu einem späteren Zeitpunkt wieder aufgenommen wird. Wenn ein Kind-Verarbeitungstask während Ausführung eines Tasks erzeugt wird, dann wird ein Zeiger auf den Kind-Task zu der Liste von Taskzeigern, die gescheduled werden sollen, hinzugefügt. Ein Kind-Task mag von einer TMD 322 erzeugt werden, die in dem Verarbeitungsclusterarray 230 ausgeführt wird.
  • Anders als ein Task, der durch die Task-/Arbeit-Einheit 207 von dem Frontend 212 erhalten wird, werden Kind-Tasks von dem Verarbeitungsclusterarray 230 erhalten. Kind-Tasks werden nicht in einem Stoßpuffer eingefügt oder zu dem Frontend transmittiert. Die CPU 102 wird nicht benachrichtigt, wenn ein Kind-Task erzeugt wird oder Daten für den Kind-Task im Speicher gespeichert werden. Ein weiterer Unterschied zwischen den Tasks, die durch Stoßpuffern bereitgestellt werden, und Kind-Tasks ist, dass die durch den Stoßpuffern bereitgestellten Tasks von dem Applikationsprogramm definiert werden, während die Kind-Tasks dynamisch während der Ausführung der Tasks erzeugt werden.
  • Übersicht der Taskverarbeitung
  • 3B ist ein Blockdiagramm von einem GPC 208 innerhalb einer der PPUs 202 von 2, gemäß einer Ausführungsform der vorliegenden Erfindung. Jeder GPC 208 mag zum parallelen Ausführen einer großen Anzahl von Threads konfiguriert sein, wobei der Begriff „Thread” auf eine Instanz eines bestimmten Programmes hinweist, das auf einem bestimmten Satz von Inputdaten ausgeführt wird. In einigen Ausführungsformen werden einzelne-Instruktions-, mehrfache-Daten-(SIMD)-Instruktionsausgabetechniken (engl. „single-instruction, multiple-data (SIMD) instructions issue techniques”) verwendet, um parallele Ausführung von einer großen Anzahl von Threads zu unterstützen, ohne mehrfache unabhängige Instruktionseinheiten bereitzustellen. In anderen Ausführungsformen werden einzelne-Instruktions-, mehrfache-Threads-(SIMT)-Techniken (engl. „single-instruction, multiple-thread (SIMT) techniques”) verwendet, um parallele Ausführung von einer großen Anzahl von generell synchronisierten Threads zu unterstützen, unter Verwendung einen gemeinsamen Instruktionseinheit, die zur Ausgabe von Instruktionen an einen Satz von Verarbeitungsmaschinen (engl. „processing engines”) innerhalb jedes der GPCs 208 konfiguriert ist. Anders als bei einer SIMD-Ausführungsbetriebsart (engl. „SIMD execution regime”), bei der alle Verarbeitungsmaschinen typischerweise identische Instruktionen ausführen, erlaubt die SIMT-Ausführung, dass verschiedene Threads divergierende Ausführungspfade durch ein gegebenes Threadprogramm zügiger folgen. Fachleute werden verstehen, dass eine SIMD-Verarbeitungsbetriebsart eine funktionelle Untermenge von einer SIMT-Verarbeitungsbetriebsart ist.
  • Die Operation des GPC 208 wird vorteilhafterweise über einen Pipelinemanager 305 gesteuert, der Verarbeitungstasks an Streaming-Mehrfachprozessoren (SMs) 310 verteilt. Der Pipelinemanager 305 mag auch dazu konfiguriert sein, eine Arbeitsverteilungskreuzschiene 330 durch Angeben von Destinationen für verarbeitete Datenausgabe von den SMs 310 zu steuern.
  • In einer Ausführungsform weist jeder GPC 208 eine Anzahl M von SMs 310 auf, wobei M ≥ 1 und jeder SM 310 zum Verarbeiten einer oder mehrerer Threadgruppen konfiguriert ist. Jeder SM 310 weist vorteilhafterweise auch einen identischen Satz von funktionellen Ausführungseinheiten (zum Beispiel Ausführungseinheiten und Load-Store-Einheiten (engl. „load-store units”), die als Ausführungseinheiten 302 und LSUs 303 in 3C gezeigt sind) auf, die gepipelined sein mögen, erlaubend eine neue Instruktion ausgegeben zu werden, bevor eine vorhergehende Instruktion fertig ist, wie es auf dem technischen Gebiet bekannt ist. Jede Kombination funktioneller Ausführungseinheiten mag bereitgestellt werden. In einer Ausführungsform unterstützen die funktionellen Einheiten eine Vielzahl von Operationen, einschließlich Ganzzahl- und Fließkommaarithmetik (zum Beispiel Addition und Multiplikation), Vergleichsoperationen, boolescher Operationen (UND, ODER, EXKLUSIV-ODER), Bit-Verschiebung und Berechnung von diversen algebraischen Funktionen (zum Beispiel planarer Interpolation, trigonometrischer, exponentieller und logarithmischer Funktionen usw.); und die gleiche Funktionseinheitshardware kann zum Ausführen verschiedener Operationen eingesetzt (engl. „leveraged”) werden.
  • Die Reihe von Instruktionen, die an einen bestimmten GPC 208 übermittelt wird, bildet einen Thread, wie hierin früher definiert wurde, und die Sammlung von einer bestimmten Anzahl von Threads, die gleichzeitig überall in (engl. „across”) den Parallelverarbeitungsmaschinen (nicht gezeigt) innerhalb eines SM 310 ausgeführt werden, wird als ein „Warp” oder als eine „Threadgruppe” (engl. „thread group”) bezeichnet. Wie hierin benutzt, bezeichnet eine „Threadgruppe” eine Gruppe von Threads, die gleichzeitig das gleiche Programm auf unterschiedlichen Inputdaten ausführen, wobei ein Thread der Gruppe einer unterschiedlichen Verarbeitungsmaschine innerhalb eines SM 310 zugeordnet ist. Eine Threadgruppe mag weniger Threads als die Anzahl der Verarbeitungsmaschinen innerhalb des SM 310 enthalten, in welchem Falle einige Verarbeitungsmaschinen während Zyklen, in denen diese Threadgruppe verarbeitet wird, inaktiv sein werden. Eine Threadgruppe mag auch mehr Threads als die Anzahl der Verarbeitungsmaschinen innerhalb des SM 310 enthalten, in welchem Falle die Verarbeitung in aufeinanderfolgenden Zyklen stattfinden wird. Da jeder SM 310 bis zu G Threadgruppen gleichzeitig unterstützen kann, folgt es, dass bis zu G·M Threadgruppen zu jedem gegebenen Zeitpunkt im GPC 208 ausgeführt werden können.
  • Eine Mehrzahl von verwandten bzw. in Beziehung stehenden Threadgruppen mag des Weiteren zum gleichen Zeitpunkt innerhalb eines SM 310 aktiv sein (in verschiedenen Phasen der Ausführung). Diese Sammlung von Threadgruppen wird hierin bezeichnet als ein „Array zusammenarbeitender Threads” (engl. „cooperative thread array”) (CTA) oder „Threadarray” bezeichnet. Die Größe eines bestimmten CTA ist gleich m·k, wobei k die Anzahl der gleichzeitig ausführenden Threads in einer Threadgruppe ist, die typischerweise ein ganzzahliges Vielfaches der Anzahl von Parallelverarbeitungsmaschinen innerhalb des SM 310 ist, und m die Anzahl von gleichzeitig aktiven Threadgruppen innerhalb des SM 310 ist. Die Größe eines CTA wird generell von dem Programmierer und der Menge der für das CTA zur Verfügung stehenden Hardware-Ressourcen, wie zum Beispiel Speicher oder Register, bestimmt.
  • Jeder SM 310 enthält einen Stufe-Eins-(L1)-Cache (engl. „level one cache”) (gezeigt in 3C) oder nutzt Platz in einem entsprechenden L1-Cache außerhalb des SM 310, der zum Ausführen von Lade- und Speicheroperationen (engl. „load and store operations”) benutzt wird. Jeder SM 310 hat auch Zugriff auf Stufe-Zwei-(L2)-Caches, die von allen GPCs 208 gemeinsam genutzt werden und zum Übertragen von Daten zwischen Threads benutzt werden mögen. Schließlich haben die SMs 310 auch Zugriff auf externen (engl. „off-chip”) „globalen” Speicher, welcher zum Beispiel Parallelverarbeitungsspeicher 204 und/oder Systemspeicher 104 aufweisen kann. Es ist zu verstehen, dass jeder beliebige Speicher, der extern zur PPU 202 ist, als globaler Speicher benutzt werden mag. Ein Stufe-Eins-Komma-Fünf-(L1,5)-Cache 335 mag zusätzlich in dem GPC 208 inkludiert sein, welcher dazu konfiguriert ist, Daten, die vom SM 310 angefordert und über Speicherschnittstelle 214 aus dem Speicher abgerufen werden, einschließlich Instruktionen, einheitlichen (engl. „uniform”) Daten und konstanten Daten, zu erhalten und halten und die angeforderten Daten an den SM 310 zu liefern. Ausführungsformen, die mehrere SMs 310 im GPC 208 haben, teilen mit Vorteil gemeinsamen Instruktionen und Daten, die im L1,5-Cache 335 gespeichert sind.
  • Jeder GPC 208 mag eine Speichermanagementeinheit (MMU) 328 aufweisen, die zum Abbilden virtueller Adressen auf absolute (engl. „physical”) Adressen konfiguriert ist. In anderen Ausführungsformen mag bzw. mögen die MMU(s) 328 sich innerhalb der Speicherschnittstelle 214 befinden. Die MMU 328 enthält einen Satz von Seitentabelleneinträgen (engl. „page table entries”) (PTEs), die zum Abbilden einer virtuellen Adresse auf eine absolute Adresse einer Fliese und wahlweise eines Cachezeilenindex verwendet werden. Die MMU 328 mag Adressübersetzungs-assoziative-Pufferspeicher (TLB) (engl. „address translation lookaside buffers”) oder Adressübersetzungs-parallele-Cachespeicher (engl. „address translation lookaside caches”) aufweisen, die sich innerhalb des Mehrfachprozessors SM 310 oder des L1-Caches oder der GPC 208 befinden mögen. Die physikalische Adresse wird verarbeitet, um Oberflächendaten-Zugriffslokalität (engl. „surface data access locality”) zu distribuieren, um effiziente Auftragsinterleaving (engl. „request interleaving”) zwischen Partitionseinheiten 215 zu erlauben. Der Cachezeilenindex mag benutzt werden, um zu bestimmen, ob eine Anforderung für eine Cachezeile einen Treffer (engl. „hit”) oder einen Fehlschuss (engl. „miss”) ist.
  • In Grafik- und Rechenapplikationen mag ein GPC 208 derart konfiguriert sein, dass jeder SM 310 an eine Textureinheit 315 gekoppelt ist, um Bemusterungsoperationen (engl. „texture mapping operations”) durchzuführen, zum Beispiel Bestimmen von Texturabtastwertpositionen (engl. „texture sample positions”), Lesen von Texturdaten und Filtern der Texturdaten. Texturdaten werden aus einem internen (nicht gezeigten) Textur-L1-Cache oder, in einigen Ausführungsformen, aus dem L1-Cache innerhalb des SM 310 gelesen und werden bei Bedarf aus einem L2-Cache, der zwischen allen GPCs 208 geteilt ist, dem Parallelverarbeitungsspeicher 204 oder dem Systemspeicher 104 abgerufen. Jeder SM 310 gibt verarbeitete Tasks an die Arbeitsverteilungskreuzschiene 330 aus, um die verarbeiteten Tasks für einen anderen GPC 208 zur weiteren Verarbeitung bereitzustellen oder um die verarbeiteten Tasks in einem L2-Cache, Parallelverarbeitungsspeicher 204 oder Systemspeicher 104 über die Kreuzschieneneinheit 210 zu speichern. Eine Vor-ROP (Vorrasteroperationen (engl. „pre-raster operations”)) 325 ist dazu konfiguriert, Daten von dem SM 310 zu erhalten, Daten an ROP-Einheiten innerhalb Partitionseinheiten 215 zu leiten und Optimierungen für Farbmischung durchzuführen, Pixelfarbdaten zu organisieren und Adressübersetzungen durchzuführen.
  • Es wird verstanden, dass die hierin beschriebene Kernarchitektur illustrativ ist und dass Variationen und Modifikationen möglich sind. Es mag jede beliebige Anzahl von Verarbeitungseinheiten, zum Beispiel SMs 310 oder Textureinheiten 315, Vor-ROPs 325 in einem GPC 208 enthalten sein. Des Weiteren mag eine PPU 202, wie es in 2 gezeigt ist, jede beliebige Anzahl von GPCs 208 enthalten, die vorteilhafterweise einander funktionell ähnlich sind, so dass der Verlauf der Ausführung nicht davon abhängt, welcher GPC 208 einen gegebenen Verarbeitungstask erhält. Des Weiteren operiert jeder GPC 208 vorteilhafterweise unabhängig von anderen GPCs 208 unter Verwendung separater und individueller Verarbeitungseinheiten, L1-Caches zur Ausführung von Tasks für eins oder mehrere Applikationsprogramme.
  • Durchschnittliche Fachleute werden verstehen, dass die in den 1, 2, 3A und 3B dargestellten Architektur den Umfang der vorliegenden Erfindung in keiner Weise begrenzt und dass die hierin beschriebenen Techniken in jeder sachgemäß konfigurierten Verarbeitungseinheit implementiert werden mögen, einschließlich, ohne Begrenzung, einer oder mehrerer CPUs, einer oder mehrerer Mehrkern-CPUs, einer oder mehrerer PPUs 202, eines oder mehrerer GPCs 208, einer oder mehrerer Grafik- oder Sonderzweck-(engl. „special purpose”)-Verarbeitungseinheiten oder ähnliches, ohne den Umfang der Vorliegenden Erfindung zu verlassen.
  • In Ausführungsformen der vorliegenden Erfindung ist es wünschenswert, PPU 202 oder einem anderen bzw. andere Prozessor(en) eines Datenverarbeitungssystems zu benutzen, um allgemeine Berechnungen unter Verwendung von Threadarrays durchzuführen. Jedem Thread in dem Threadarray ist einen eindeutigen Thread-Identifikator (engl. „Thread-ID”) zugeordnet, der während der Ausführung des Threads für den Thread zugänglich ist. Der Thread-ID, der als ein eindimensionaler oder mehrdimensionaler numerischer Wert definiert werden kann, steuert verschiedene Aspekte von dem Verlauf der Ausführung des Threads. Ein Thread-ID mag zum Beispiel verwendet werden, um zu bestimmen, welchen Teil des Eingangsdatensatzes ein Thread bearbeiten soll, und/oder zu bestimmen, welchen Teil eines Ausgangsdatensatzes ein Thread produzieren oder schreiben soll.
  • Eine Folge bzw. Sequenz von pro-Thread-Instruktionen (engl. „per-thread instructions”) mag zumindest eine Instruktion enthalten, die ein kooperatives Verhalten zwischen dem maßgeblichen (engl. „representative”) Thread und einem oder mehreren anderen Threads des Threadarrays. Die Sequenz von pro-Thread-Instruktionen mag zum Beispiel eine Instruktion, die Ausführung von Operationen für den maßgeblichen Thread bei einem bestimmten Punkt in der Sequenz bis zu einem solchen Zeitpunkt zu suspendieren, bei dem ein oder mehr von den anderen Threads diesen bestimmten Punkt erreichen, eine Instruktion für den maßgeblichen Thread, Daten in einem gemeinsam genutzten Speicher, auf den ein oder mehr von den anderen Threads Zugriff haben, zu speichern, eine Instruktion für den maßgeblichen Thread, Daten, die in einem gemeinsam genutzten Speicher, auf den ein oder mehr von den anderen Threads Zugriff basierend auf deren Thread-IDs haben, atomar zu lesen und aktualisieren, oder ähnliche Instruktionen enthalten. Das CTA-Programm kann auch eine Instruktion enthalten, eine Adresse in dem gemeinsamen genutzten Speicher zu berechnen, aus der Daten zu lesen sind, wobei die Adresse eine Funktion von dem Thread-ID ist. Durch Definieren zweckmäßiger Funktionen und durch Bereitstellen von Synchronisierungstechniken können Daten von einem Thread eines CTA in einer gegebenen Stelle in dem gemeinsam genutzten Speicher geschrieben und von einem anderen Thread des gleichen CTA aus dieser Stelle gelesen werden auf eine vorhersehbare Art und Weise. Folglich kann jedes gewünschtes Muster von Datenteilung zwischen Threads unterstützt werden und jeder Thread in einem CTA kann Daten mit jedem anderen Thread in dem gleichen CTA teilen. Der Umfang, wenn überhaupt, der Datenteilung zwischen Threads eines CTA wird von dem CTA-Programm bestimmt; es ist somit zu verstehen, dass die Threads eines CTA in einer gegebenen Applikation, der CTAs verwendet, tatsächlich, in Abhängigkeit von dem CTA-Programm, Daten miteinander teilen oder nicht miteinander teilen mögen, und die Begriffe „CTA” und „Threadarray” werden hierin synonym verwendet.
  • 3C ist ein Blockdiagramm des SM 310 von 3B, gemäß einer Ausführungsform der vorliegenden Erfindung. Der SM 310 weist einen Instruktions-L1-Cache 370 auf, der zum Erhalten Instruktionen und Konstanten vom Speicher durch L1,5-Cache 335 konfiguriert ist. Eine Warp-Scheduler- und Instruktionseinheit (engl. „warp scheduler and instruction unit”) 312 erhält Instruktionen und Konstanten von dem Instruktions-L1-Cache 370 und steuert den lokalen Registerspeicher (engl. „local register file”) 304 und funktionelle Einheiten des SM 310 gemäß den Instruktionen und Konstanten. Die funktionellen Einheiten des SM 310 weisen N Ausführungs- oder Verarbeitungseinheiten 302 und P Lade-Speicher-Einheiten (engl. „load-store units) (LSU) 303 auf innerhalb eines LSU-Arrays 375.
  • Der SM 310 stellt internen (engl. „on-chip”) Datenspeicher mit verschiedenen Zugreifbarkeitsstufen bereit. Spezielle (nicht gezeigte) Register sind für die LSU 303 lesbar aber nicht schreibbar und werden zum Speichern von Informationen verwendet, die die „Position” eines jeden Threads definieren. In einer Ausführungsform weisen die speziellen Register ein Register pro Thread (oder pro Ausführungseinheit 302 in dem SM 310) auf, das einen Thread-ID speichert; Jedes Thread-ID-Register ist nur für eine entsprechende Ausführungseinheit der Ausführungseinheiten 302 zugreifbar. Die speziellen Register mögen auch zusätzliche Register enthalten, die für alle die Threads lesbar sind, die den gleichen Verarbeitungstask ausführen, die durch eine TMD 322 (oder durch alle LSUs 303) dargestellt werden, die einen CTA-Identifikator, die CTA-Dimensionen, die Dimensionen eines Netzes (engl. „grid”), zu dem das CTA gehört, (oder die Warteschlangenposition, falls die TMD 322 eine Warteschlangentask statt eines Netztasks (engl. „grid task”) codiert) und einen Identifikator der TMD 322, zu der das CTA gespeichert wird.
  • Falls die TMD 322 eine Netz-TMD ist, dann bewirkt die Ausführung der TMD 322, dass eine feste Anzahl von CTAs gestartet und ausgeführt wird, um die feste Menge von Daten auszuführen, die in der Warteschlange 525 gespeichert ist. Die Anzahl der CTAs ist als das Produkt der Breite, Höhe und Tiefe des Netzes spezifiziert. Die feste Menge von Daten mag in der TMD 322 gespeichert werden oder die TMD 322 mag einen Zeiger auf die Daten speichern, die von den CTAs ausgeführt werden werden. Die TMD 322 speichern auch eine Startadresse des Programms, das von den CTAs ausgeführt wird, und einen Speicherbankmodus, der eine Bitbreite pro Speicherbank von einem gemeinsamen Multibank-Speicher 306 definiert. Der Speicherbankmodus steuert wie Speicherdressen pro Thread (engl. „per-thread addresses”) auf die verschiedenen Banken des gemeinsamen Multibank-Speichers 306 gemappt werden.
  • Falls die TMD 322 eine Warteschlange-TMD ist, dann wird eine Warteschlangeneigenschaft der TMD 322 verwendet, was heißt, dass die Menge von Daten, die bearbeitet werden soll, nicht notwendigerweise fest ist. Warteschlangeneinträge speichern Daten, die von den CTAs verarbeitet werden sollen, die zu der TMD 322 zugeordnet sind. Die Warteschlangeneinträge mögen auch einen Kind-Task darstellen, der während Ausführung eines Threads von einer anderen TMD 322 erzeugt worden ist, wobei eine geschachtelte Parallelität (engl. „nested parallelism”) bereitgestellt wird. Die Ausführung des Threads oder des CTA, das den Thread enthält, wird typischerweise suspendiert bis die Ausführung des Kind-Tasks komplett ist. Die Warteschlange mag in oder getrennt von der TMD 322 gespeichert werden, wobei die TMD im letzteren Falle einen Warteschlangezeiger auf die Warteschlange speichert. Daten, die von dem Kind-Task erzeugt worden sind, können vorteilhaft zu der Warteschlange geschrieben werden, während der TMD 322 ausgeführt wird, die den Kind-Task darstellen. Die Warteschlange mag als eine zirkuläre Warteschlange implementiert werden, so dass die totale Menge von Daten nicht von der Größe der Warteschlange begrenzt ist.
  • CTAs, die zu einem Netz gehören, haben implizite Netz-Breite-, -Höhe- und -Tiefe-Parameter, die die Position des jeweiligen CTA innerhalb des Netzes bezeichnen. Die speziellen Register werden während der Initialisierung als Reaktion auf Befehle, die von dem Gerätetreiber 103 über das Frontend 212 erhalten werden, geschrieben und verändern sich während der Ausführung eines Verarbeitungstasks nicht. Das Frontend 212 legt der Ausführung jeden Verarbeitungstask zeitlich fest (engl. „schedules”). Jedes CTA ist mit einer bestimmten TMD 322 assoziiert für gleichzeitige Ausführung eines oder mehrerer Tasks. Ein einzelner GPC 208 mag des Weiteren eine Mehrzahl von Tasks gleichzeitig ausführen.
  • Ein (nicht gezeigter) Parameterspeicher speichert Ausführungsparameter (engl. „runtime parameter”) (Konstante), die von jedem anderen Thread innerhalb des gleichen CTA (oder jeder beliebigen LSU 303) gelesen aber nicht geschrieben werden kann. In einer Ausführungsform stellt der Gerätetreiber 103 Parameter für den Parameterspeicher bereit bevor er den SM 310 anweist, die Ausführung eines Tasks, der diese Parameter nutzt, zu beginnen. Jeder Thread innerhalb eines jeden CTA (oder jede Ausführungseinheit 302 innerhalb des SM 310) kann auf einen globalen Speicher durch eine Speicherschnittstelle 214 zugreifen. Bereiche des globalen Speichers mögen in dem L1-Cache 320 gespeichert werden.
  • Der lokale Registerspeicher 304 wird von jedem Thread als Arbeitsplatz (engl. „scratch space”) verwendet; jedes Register ist für die exklusive Nutzung eines Threads allokiert und Daten in jeder beliebigen der lokalen Registerspeicher 304 ist nur für den Thread zugreifbar, zu dem das Register allokiert ist. Der lokale Registerspeicher 304 kann als ein Registerspeicher implementiert werden, der physikalisch oder logisch in P Spuren (engl. „lanes”) aufgeteilt sind, wobei jede Spur irgendeine Anzahl von Einträgen hat (wobei jeder Eintrag zum Beispiel ein 32-Bit-Wort speichern mag). Eine Spur ist zu jedem der N Ausführungseinheiten 302 und P Load-Store-Einheiten LSU 303 zugeordnet, und entsprechende Einträge in unterschiedlichen Spuren können mit Daten für verschiedenen Threads, die das gleiche Programm ausführen, befüllt werden, um SIMD-Ausführung zu vereinfachen. Unterschiedliche Abschnitte der Spuren können zu unterschiedlichen Threadgruppen der G gleichzeitigen Threadgruppen allokiert werden, so dass ein gegebener Eintrag in dem lokalen Registerspeicher 304 nur für einen bestimmten Thread zugreifbar ist. In einer Ausführungsform werden gewisse Einträge in dem lokalen Registerspeicher 304 zum Speichern von Thread-Identifikatoren reserviert, um eines der speziellen Register zu implementieren.
  • Der geteilte bzw. gemeinsame Speicher 306 ist für Threads innerhalb eines einzigen CTA zugreifbar, mit anderen Worten ist jede beliebige Stelle in dem gemeinsamen Speicher 306 für jeden beliebigen Thread innerhalb des gleichen CTA (oder für jede beliebige Verarbeitungsmaschine innerhalb der SM 310) zugreifbar. Der gemeinsame Speicher 306 kann als ein gemeinsamer Multibank-Registerspeicher (engl. „multi-banked shared register file”) oder als gemeinsamer interner (engl. „on-chip”) Speicher mit einer Verbindung (engl. „interconnect”) implementiert sein, die es jede Verarbeitungsmaschine erlaubt, aus und zu jeder Stelle in dem gemeinsamen Speicher 306 zu lesen und zu schreiben. Die Anzahl der Speicherbänke, die zum Konstruieren des gemeinsamen Speichers 306 verwendet werden, mag gleich der Anzahl von Threads in einer Threadgruppe sein, so dass jeder Thread parallel auf den gemeinsamen Speicher 306 zugreifen mag.
  • In anderen Ausführungsformen mag ein gemeinsamer Zustandsraum auf einen pro-CTA-Bereich von externem (engl. „off-chip”) Speicher abbilden und in dem L1-Cache 320 zwischengespeichert werden. Der Parameterspeicher kann als ein designierter Abschnitt innerhalb des gleichen gemeinsamen Registerspeichers oder innerhalb des gleichen gemeinsamen Cachespeichers, die bzw. der den gemeinsamen Speicher 306 implementiert, oder als ein separater gemeinsamer Registerspeicher oder interner (engl. „on-chip”) Cachespeicher, zu dem die LSUs 303 Nur-Lese-Zugriff haben, implementiert werden. In einer Ausführungsform wird der Bereich, der den Parameterspeicher implementiert, auch dazu verwendet, die CTA-ID und Task-ID sowie CTA- und Netzdimensionen oder Warteschlangeposition zu speichern, wobei Abschnitte der speziellen Register implementiert werden. Jede LSU 303 in dem LSU-Array 375 weist eine (in 4A gezeigte) Adressenerzeugungseinheit auf, die eine Adresse, die für Lade- und Speicherinstruktionen (engl. „load and store instructions”), die in einem einheitlichen Speicherraum spezifiziert sind, bereitgestellt worden sind, in eine Adresse in jedem distinkten Speicherraum umwandelt. Folglich mag eine Instruktion dazu verwendet werden, auf einen beliebigen der lokalen, gemeinsamen oder globalen Speicherräume durch Spezifizieren einer Adresse in dem vereinheitlichten Speicherraum zuzugreifen.
  • Der L1-Cache 320 in jedem SM 310 kann dazu verwendet werden, private einzelthreadbezogenen lokalen Daten (engl. „private per-thread local data”) und auch einzelapplikationsbezogene globalen Daten (engl. „per-application global data”) zwischenzuspeichern. In einigen Ausführungsformen mögen die pro-CTA-geteilten-Daten in dem L1-Cache 320 zwischengespeichert werden. Die LSUs 303 sind an den gemeinsamen Speicher 306 und den L1-Cache 320 über eine Speicher-und-Cache-Verbindung (engl. „memory and cache interconnect”) 380 gekoppelt.
  • Auf der Anwendungs- und Compilerebene erscheinen die distinkten Speicherräume innerhalb eines einzigen vereinheitlichten Speicheradressenraums. Deshalb werden vereinheitlichte Speicherzugriffsinstruktionen verwendet, statt separate Lade- und Speicherinstruktionen für jeden distinkten Speicherraum. Ein C/C++-Programm mag einen vereinheitlichten Zeiger und eine vereinheitlichten Zugriffsinstruktion verwenden, um effizient auf jeden der drei distinkten Speicheradressräume zuzugreifen. Ein beispielhaftes Format einer Ladeinstruktion ist: LD.32 Rd, [Ra + Offset]; welche auf einer Gruppe von P parallelen Threads ausgeführt wird und das Register Rd von jedem Thread mit 32 Bits von Daten aus dem Speicher an jede vereinheitlichte Byteadresse lädt, die von der Summe von jedem Threads Register Ra plus Offset spezifiziert wird. Ein beispielhaftes Format einer Speicherinstruktion ist:
    ST.32 [Ra + Offset], Rb; welche auf einer Gruppe von P parallelen Threads ausgeführt wird und 32 Bits von Daten aus dem Register Rd von jedem Thread in dem Speicher an jede vereinheitlichte Byteadresse speichert, die von der Summe von jedem Threads Register Ra plus Offset spezifiziert wird.
  • Die Ausführungseinheiten 302 sind zum Verarbeiten von 32-, 64- und 128-Bit Daten konfiguriert, so die jeweilige Lade- und Speicherinstruktionen jeweils auf 64- und 128-Bit Daten zugreifen, laden und schreiben. Während einige Ausführungsformen von dem gemeinsamen Speicher 306 unter Verwendung von Speicherbänken mit einer Breite von 32 Bit konstruiert sind, wird der gemeinsame Speicher 306 in jüngerer Zeit unter Verwendung von Speicherbänken mit einer Breite von 64 oder 128 Bit konstruiert. Ein „Altanwendungsprogramm” (engl. „”legacy” application program”), das zum Vermeiden von Speicherbankkonflikten unter der Annahme, dass der gemeinsame Speicher 306 unter Verwendung von 32 Bit breiten Speicherbänken konstruiert ist, geschrieben wurde, mag Speicherbankkonflikte Verursachen, wenn es auf einer zeitgemäßen (engl. „non-legacy”) PPU 202 ausgeführt wird, die einen gemeinsamen Speicher 306 aufweist, der unter Verwendung von 64 oder 128 Bit breiten Speicherbänken konstruiert wurde. Statt zu fordern, dass das Altprogramm modifiziert wird, um Speicherbankkonflikte zu vermeiden, mag ein Speicherbankmodus spezifiziert werden, welcher das Mapping von Speicheradressen pro Thread auf die Speicherbänke des gemeinsamen Speichers 306 dynamisch steuert. Der Speicherbankmodus mag folglich verwendet werden zum Erlauben, dass Altanwendungsprogramme auf neuerer Hardware ausgeführt werden, ohne solche Speicherkonflikte zu verursachen, die nicht aufgetreten hätten, wenn die Altanwendungsprogramme von Althardware ausgeführt worden wäre, zum Beispiel einer Alt-PPU 202, die 32 Bit breite Speicherbänke verwendet.
  • Dynamische Adressierung von Speicherbänken
  • Jede Speicherbank des gemeinsamen Speichers 306 ist ein unabhängig adressierbarer Speicher, der gewöhnlich als ein statischer Schreib-Lese-Speicher (engl. „static random access memory”) (SRAM) implementiert ist, obwohl andere Implementierungen möglich sind. In einer Alt-Ausführungsform des gemeinsamen Speichers 306 wird jedes aufeinanderfolgende 32-Bit-Wort in einer aufeinanderfolgenden Speicherbank gespeichert, und jede Speicherbank weist eine unabhängig gesteuerte Adresse auf. Jedes 32-Bit-Wort ist mit einem unterschiedlichen Thread einer Threadgruppe assoziiert. Eine zeitgemäße Ausführungsform des gemeinsamen Speichers 306 ist mit 64 Bit breiten Speicherbänken konstruiert, so dass jeder Thread einen 64-Bit-Wert lesen oder schreiben mag. Wenn ein Altanwendungsprogramm ausgeführt wird und zwei nebeneinanderliegende 32-Bit-Werte für zwei Threads in der gleichen 64-Bit breite Speicherbank gespeichert sind, dann müssen die zwei Threads die gleiche Adresse spezifizieren, um auf die 32-Bit-Werte in dem gleichen Taktzyklus zuzugreifen. Ein Speicherbankkonflikt tritt auf, wenn die zwei Threads unterschiedliche Adressen haben, die beide auf die gleiche Speicherbank mappen. Im Gegensatz dazu, wenn das Altanwendungsprogramm auf Althardware ausgeführt wird und 32-Bit-Werte in nebeneinanderliegenden Speicherbänken gespeichert sind, dann mappt jede Adresse, die mit einem Thread assoziiert ist, auf eine unterschiedliche Speicherbank und es treten keine Speicherbankkonflikte auf. Zusammengefasst mag eine Instruktion, die auf den gemeinsamen Speicher 306 zugreift und nur einen einzigen Taktzyklus benötigte, um auf Althardware ausgeführt zu werden, zwei Taktzyklen benötigen, um auf neueren Hardware, ohne das Speicherbankmodus-Merkmal, ausgeführt zu werden. Obwohl die Speicherzugriffe und der Speicherbankmodus mit Bezug auf den gemeinsamen Speicher 306 beschrieben wird, mag der Speicherbankmodus auch für Speicherzugriffe von einem Multibank-Speicher verwendet werden, der nicht von verschiedenen CTAs gemeinsam genutzt wird.
  • Ein erster Speicherbankmodus mappt Adressen auf Speicherbanken in einer solchen Art und Weise, dass Eigenschaften bzgl. Speicherbankkonflikte aufrechterhalten werden unter der Annahme von 32 Bits pro Speicherbank. Wenn der erste Speicherbankmodus verwendet wird, operiert der gemeinsame Speicher 306 oder ein anderer Multibank-Speicher als ob es 4 Bytes pro logische Speicherbank gibt (4BB-Modus). Eine zweite Speicherbank mappt Adressen, um Eigenschaften bzgl. Speicherbankkonflikte unter der Annahme von 64 Bits aufrechtzuerhalten. Wenn der zweite Speicherbankmodus verwendet wird, operiert der Multibank-Speicher als ob es 8 Bytes pro logische Speicherbank gibt (8BB-Modus). Andere Speichermodi sind auch möglich, um unterschiedliche Anzahlen von Bit pro Speicherbank zu unterstützen.
  • Als eine Illustration der ersten und zweiten Speicherbankmodi, betrachte eine Ausführungsform des Multibank-Speichers mit nur 8 logischen Speicherbänken, jeweils von 64 Bits. Die TABELLE 1 zeigt wie aufeinanderfolgende 32-Bit-Wörter 0 bis 15 über die 8 logischen Speicherbänke hinweg in einer Zeile des Multibank-Speichers gespeichert sind. TABELLE 1 32-Bit-Wörter gespeichert in 8 Speicherbänken
    Relative Wort-Indexe pro ”Speicherzeile” bei 8 logischen Speicherbänken mit einer jeweiligen Breite von 2 Wörtern
    Speicherbank: 0 1 2 3 4 5 6 7
    Wörter in Sp.bank: 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1
    Bytes/ Sp.bank 4 0 8 1 9 2 10 3 11 4 12 5 13 6 14 7 15
    8 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
  • Das Mapping von Speicheradresse pro Thread auf Speicherstelle (engl. „storage location”), zum Beispiel gemappte Speicheradresse pro Thread, wird durch die unten angeführten allgemeinen Gleichungen beschrieben. Für dieses Beispiel gelten die folgenden konstanten Parameter und Funktionen für den ersten und zweiten Speicherbankmodus:
    kBytesPerWord = 4
    kWordsPerLogicalBank = 2
    kNumLogicalBanks = 8
    wobei der Operator / eine ganzzahlige Divisionsfunktion bezeichnet, der Operator % eine ganzzahlige Modulfunktion bezeichnet, und Adressen in Form von Bytes spezifiziert sind. Während die 4BB- und 8BB-Speicherbankmodi unterstützt werden, sind die folgenden Gleichungen nicht auf diese zwei Speicherbankmodi beschränkt. Zum Beispiel ergibt die Verwendung von kWordsPerLogicalBank = 4 und kNumLogicalBanks = 4 ein gültiges und selbstkonsistentes (engl. „self-consistent”) Mapping über die gleichen logischen Speicherbänke hinweg. Beachte, dass die physikalische Speicherbankbreite nur kleiner oder gleich der logischen Speicherbankbreite sein muss.
  • Die folgenden Gleichungen beschreiben das Mapping von einer Byteadresse (byteAddr) auf Speicher innerhalb einer logischen Speicherbank und ein Wort innerhalb dieser Speicherbank für den 4BB-Speichermodus. Speicherbank = (byteAddr/kBytesPerWord) % kNumLogicalBanks; Wort = (byteAddr/(kNumLogicalBanks·kBytesPerWord)) % kWordsPerLogicalBank;
  • Die TABELLE 2 zeigt wie Byteadressen, die bündig (engl. „aligned”)) mit Worträndern angeordnet sind, auf logische Speicherbänke und die Hälften innerhalb jeder Speicherbank für den 4BB-Speicherbankmodus mappen. TABELLE 2 Mapping von Byteadressen auf Speicherbänke in 4BB-Speicherbankmodus
    Figure 00340001
  • Die folgenden Gleichungen beschreiben das Mappen von einer Byteadresse (byteAddr) auf Speicher innerhalb einer logischen Speicherbank und ein Wort innerhalb dieser Speicherbank für den 8BB-Speichermodus. Speicherbank = (byteAddr/(kBytesPerWord·kWordsPerLogicalBank) % kNumLogicalBanks; Wort = (byteAddr/kBytesPerWord) % kWordsPerLogicalBank;
  • Die TABELLE 3 zeigt wie Byteadressen, die bündig mit Worträndern angeordnet sind, auf logische Speicherbänke und die Hälften innerhalb jeder Speicherbank für den 8BB-Speicherbankmodus mappen. TABELLE 3: Mapping von Byteadressen auf Speicherbänke in 8BB-Speicherbankmodus
    Figure 00350001
  • Wie früher erläutert unterstützt der SM 310 gleichzeitiges Ausführen von mehreren Warps, wobei die Warps eng mit einander verknüpft (ein CTA gehören), lose mit einander verknüpft, indem sie unterschiedliche CTAs gehören, oder gar nicht verknüpft sein können, indem sie unterschiedliche Netze (engl. „grids”) von CTAs gehören. Während eine statische Wahl des Speicherbankmodus einigermaßen gut funktionieren mag für die Warps, die auf dem gleichen SM 310 von einem einzigen Netz von CTAs erzeugt worden sind, mag die Performance von Warps, die von einem unterschiedlichen Netz erzeugt worden sind, reduziert werden, wenn alle Warps den gleichen Speicherbankmodus benutzen. Die Warps eines ersten Netzes mögen zum Beispiel 32-Bit-Zugriffe ausführen und Warps eines zweiten Netzes mögen hauptsächlich 64-Bit- oder 128-Bit-Zugriffe ausführen. Wenn Warps aus beiden Netzen auf dem gleichen SM 310 ausgeführt werden, mag einer der Warps unbeabsichtigte Speicherbankkonflikte erleiden. Falls die Ausführung des zweiten Netzes bis zum nach Beendigung der Ausführung des ersten Netzes verzögert wird, mag die Warpbelegung (engl. „warp occupancy”) in dem SM 310 reduziert werden, was Leerlaufblasen (engl. „idle bubbles”) erzeugt, das heißt Taktzyklen, wenn keine Instruktion verarbeitet wird.
  • Der Speicherbankmodus mag für jede Zugriffsanforderung spezifiziert werden, das heißt für jeden Warp, so dass die Adressen pro Thread gemäß entweder dem 4BB-Speicherbankmodus, dem 8BB-Speicherbankmodus oder einem anderen Speicherbankmodus gemappt werden. Der Speicherbankmodus wird in der TMD 322 für jedes Netz gespeichert, so der gleiche Speicherbankmodus für alle Warps verwendet wird, die die TMD 322 ausführen. In einigen Ausführungsformen mag der Speicherbankmodus als Teil der Lade- oder Speicherprogramminstruktion spezifiziert werden oder der Speicherbankmodus mag für verschiedene Abschnitte des Multibank-Speichers spezifisch sein.
  • Unabhängig davon, wie der Speicherbankmodus für eine Zugriffsanforderung bereitgestellt wird, werden die physikalische Stellen, die unter Verwendung eines Speicherbankmodus geschrieben werden, nicht notwendigerweise die gleichen physikalischen Stellen sein, die unter Verwendung eines anderen Speicherbankmodus gelesen werden. Das Feature des dynamischen Speicherbankmodus ist dafür vorgesehen, die Ausführung von Altanwendungsprogrammen zu ermöglichen, ohne dass zusätzliche Speicherbankkonflikte verursacht werden, das heißt, die Performance des Altanwendungsprogrammes beim Ausführen mittels neuerer Hardware aufrechtzuerhalten oder zu verbessern. Deswegen mag der Speicherbankmodus während der Ausführung eines bestimmten Anwendungsprogrammes geändert werden, wenn darauf geachtet wird, dass konsistente Zugriffe innerhalb eines Warps sichergestellt werden, zum Beispiel durch Bereitstellen von Randpunkten (engl. „boundary points”) in dem Anwendungsprogramm, wie zum Beispiel Barriereinstruktionen (engl. „barrier instructions”). Wenn alle Warps, die für ein Netz gestartet (engl. „launched”) worden sind, den gleichen Speicherbankmodus verwenden, mögen die Warps immer noch frei verschachtelt (engl. „interleaved”) werden mit Warps, die von anderen Netzen gestartet worden sind unter Verwendung eines anderen Speicherbankmodus während der Ausführung durch einen SM 310.
  • Schließlich mag der Speicherbankmodus zu einer bestimmten Einstellung gezwungen werden, die sich von dem Speicherbankmodus unterscheidet, der für das Netz oder das Anwendungsprogramm vorgegeben ist. Eine gezwungene Einstellung mag zum Debuggen, Profilierung (engl. „profiling”) und Auto-Abstimmungszwecke (engl. „auto-tuning purposes”) verwendet werden.
  • 4A ist ein Blockdiagramm von dem LSU-Array 375 von 3C, gemäß einer Ausführungsform der vorliegenden Erfindung. Das LSU-Array 375 weist, wie gezeigt, die verschiedene LSUs 303 und eine Adressenerzeugungseinheit 405 auf. In einer SIMT-Architektur, wie diejenige, die in den 3A bis 3C beschrieben ist, wird eine einzige Instruktion, wie beispielsweise eine Lade- oder Speicher-Zugriffsanforderung, an eine Threadgruppe (Warp) von P parallelen Threads zusammen mit einer aktiven Maske für den Warp gesendet. Die Adressenerzeugungseinheit 405 erhält Warpadressen für jede Zugriffsanforderung, eine aktive Maske für den Warp und den Speicherbankmodus. Der gemeinsame Speicher 306 ist an das LSU-Array 375 über der Speicher-und-Cache-Verbindung (engl. „memory and cache interconnect”) 380 gekoppelt und weist eine Lese/Schreibe-Schnittstelle 430 und P Speicherbänke 440 auf.
  • Die aktive Maske zeigt, welche individuelle Threads in einem Warp dazu freigegeben sind, die Instruktion für den Warp auszuführen. Aktive Threads führen die Instruktion aus und nicht aktive Threads führen die Instruktion nicht aus. Threads mögen aktiv und inaktiv werden, wenn Divergenz während der Ausführung eines Programmes wegen Abzweigung oder ähnliches auftritt. Bis zum P aktive Threads führen die Instruktion gleichzeitig aus. Eine arithmetische Instruktion für P Threads wird von P parallelen Ausführungseinheiten 302 ausgeführt. Eine Speicher-Lade/Speicher-Instruktion für P Threads wird von P parallelen LSUs 303 ausgeführt. Eine Speicherinstruktion für P Threads erhält folglich P Adressen, die P oder weniger verschiedene Speicheradressen sein mögen.
  • Die Adressenerzeugungseinheit 405 führt Adressenberechnungstasks, zum Beispiel Adressenmappingoperationen, für die Zugriffsanforderungen basierend auf dem Speicherbankmodus aus. In einer Ausführungsform mag die Adressenerzeugungseinheit 405 zum Verarbeiten einer Zugriffsanforderung von einem Warp über mehrere Zyklen konfiguriert sein, so dass eine Teilmenge (engl. „sub-set”) der Threads während jedes Zyklus der mehreren Zyklen verarbeitet wird. Eine Teilmenge von 8 Threads mag zum Beispiel über 4 Zyklen verarbeitet werden, wenn der Warp 32 Threads enthält. Die Adressenerzeugungseinheit 405 stellt auch fest, ob jegliche Speicherbankkonflikte zwischen den gemappten Speicheradressen pro Thread für einen Warp vorliegen. Es ist wichtig, dass Speicheradressen von Threads, die gemäß der aktiven Maske nicht aktiv sind, keinen Speicherbankkonflikt verursachen.
  • Die Adressenerzeugungseinheit 405 gibt die gemappten Speicheradressen der aktiven Threads, die keinen Speicherbankkonflikt verursachen, an die LSUs 303 aus. Die LSUs 303 senden dann eine Lese- oder Schreibeanforderung, einschließlich einer oder mehrerer der gemappten Speicheradressen, an die Cacheverbindung (engl. „cache interconnect”), um die Zugriffsanforderung für die aktiven parallelen Threads in dem Warp fertigzustellen. Die maximale Anzahl eindeutiger Speicheradressen, die in einem einzigen Taktzyklus gesendet wird, ist typischerweise durch die Speicherarchitektur und die Schnittstelle zwischen dem LSU-Array 375 und dem Speicher-und-Cache-Verbindung 308 begrenzt.
  • In einer Ausführungsform mag die Adressenerzeugungseinheit 405 dazu konfiguriert sein, nur die Anzahl von gemappten Speicheradressen, die von der LSU 303 als eine einzige Anforderung gesendet werden kann, an die LSU 303 auszugeben. Wenn die Anzahl von gemappten Speicheradressen für einen Warp größer ist als diese Anzahl, wird eine Replayanforderung (engl. „replay request”) von der Adressenerzeugungseinheit 405 an die Warp-Scheduler-und-Instruktionseinheit 312 ausgegeben. Die Warp-Scheduler-und-Instruktionseinheit 312 wird dann die Zugriffsanforderung für Ausführung zu einer späteren Zeit erneut abgeben und zusätzliche Taktzyklen für die Ausführung der Ladeinstruktion reservieren, um Platz für das Senden mehrerer Zugriffsanforderungen zu bieten, wie es von den LSUs 303 benötigt wird. Jegliche nachfolgende Instruktion für den gleichen Warp wird verworfen oder in anderer Art und Weise davon gehindert, ausgeführt zu werden, bis nachdem die Zugriffsanforderung replayed und von dem LSU-Array 375 erfolgreich ausgeführt worden ist.
  • 4B ist ein Konzeptdiagramm, das ein Mapping von einem 8×8-Array von 32-Bit Daten auf 8 32-Bit Datenbänke darstellt. Die 32-Bit Daten, die auf 8 32-Bit Speicherbänke 460 gemappt sind, sind ein Beispiel eines ersten Mappings, das eine Auffüllung (engl. „pad”) von einem 32-Bit Wort (als „Füllung” gezeigt) in jeder Zeile verwendet, so dass auf entweder eine ganze Zeile oder eine ganze Spalte des 8×8-Arrays zugegriffen werden mag, ohne jegliche Speicherbankkonflikte zu verursachen. Jedes Element in dem Array ist mit Zeile:Spalte angegeben. Die erste Zeile des Arrays enthält die Elemente 0:0, 0:1, 0:2, 0.3, 0:4, 0:5, 0:6 und 0:7. Die erste Spalte des Arrays enthält die Elemente 0:0, 1:0, 2:0, 3:0, 4:0, 5:0, 6:0 und 7:0.
  • 4C ist ein Konzeptdiagramm, das ein Mapping von dem 8×8-Array von 32-Bit Daten auf 8 64-Bit Datenbänke darstellt, gemäß einer Ausführungsform der Erfindung. Die 32-Bit Daten, die auf 8 64-Bit Datenbänke 462 gemappt sind, sind ein Beispiel eines zweiten Mappings, das auch eine Auffüllung von einem 32-Bit Wort in jeder Zeile verwendet und die 32-Bit Daten auf Datenbänke, die jeweils 64-Bit breit sind, linear mappt. Dieses zweite Mapping ist das Ergebnis eines Speicherns des 8×8-Array von 32-Bit Daten, die zum Ausführen von Althardware vorgesehen sind, in Hardware, die Speicherbänke enthält, die 64-Bit breit statt 32-Bit breit sind, unter Verwendung des 8BB-Speicherbankmodus.
  • Es bestehen keine Konflikte beim Zugreifen auf Elemente in der gleichen Zeile des Arrays. Für eine jede Zeile N können spezifisch auf alle N:[0...7] gleichzeitig zugegriffen werden, ohne einen Speicherbankkonflikt zu verursachen. Dagegen gibt es Konflikte beim Zugreifen auf Elemente in der gleichen Spalte des Arrays, das heißt, wenn für einen gegebenen M auf [0...7]:M zugegriffen wird. Die Elemente, die die Speicherbankkonflikte produzieren, sind in fetter Schrift gezeigt. Insbesondere gibt es Speicherbankkonflikte in Speicherbank 0 für Spalte = 1, in Speicherbank 1 für Spalte = 3, in Speicherbank 2 für Spalte = 5 und in Speicherbank 3 für Spalte = 7.
  • 4D ist Konzeptdiagramm, das eine andere Mapping von dem 8×8-Array von 32-Bit Daten auf 8 64-Bit Datenbänke darstellt, gemäß einer Ausführungsform der Erfindung. Die 32-Bit Daten, die auf 8 64-Bit Datenbänke 464 gemappt sind, sind ein Beispiel eines dritten Mappings, das auch eine Auffüllung von einem 32-Bit Wort in jeder Zeile verwendet und die 32-Bit Daten auf Datenbänke, die jeweils 64-Bit breit sind, linear mappt. Anders als das zweite Mapping separiert dieses dritte Mapping die 32-Bit Daten in eine niedrige und eine hohe Hälfte jeder Speicherbank. Dieses dritte Mapping ist das Ergebnis eines Speicherns des 8×8-Array von 32-Bit Daten, die zum Ausführen von Althardware vorgesehen sind, in Hardware, die Speicherbänke enthält, die 64-Bit breit statt 32-Bit breit sind, unter Verwendung des 4BB-Speicherbankmodus. Jede Zeile von Daten in dem Array ist mit einem anderen Muster markiert (engl. „indicated”). Es mag auf jede Zeile und jede Spalte des 8×8-Arrays zugegriffen werden, ohne einen Speicherbankkonflikt zu verursachen.
  • Andere Anordnungen von Daten als ein N×M-Array mögen in 32-Bit, 64-Bit oder 128-Bit Speicherbänke unter Verwendung des 8BB Speicherbankmodus gespeichert werden, um das Verursachen von Speicherbankkonflikte zu vermeiden, wenn auf die Daten zugegriffen wird. Beispiele anderer Anordnungen beinhalten Schablonenmuster (engl. „stencil patterns”).
  • 5 stellt ein Flussdiagramm von Verfahrensschritten zum Verarbeiten einer Ladeanforderung dar, gemäß einer Ausführungsform der vorliegenden Erfindung. Obwohl die Verfahrensschritte im Zusammenhang mit den Systemen der 1, 2, 3A, 3B und 3C beschrieben werden, werden durchschnittlich qualifizierte Fachleute verstehen, dass jedes System, das zum Durchführen der Verfahrensschritte, in jeglicher Reihenfolge, konfiguriert ist, in dem Umfang der Erfindungen enthalten ist.
  • Das Verfahren 500 beginnt bei Schritt 505, wo die Adressenerzeugungseinheit 405 eine Speicherzugriffsanforderung erhält,. die eine individuelle Speicheradresse für jeden jeweiligen Thread in dem Warp, einen Speicherbankmodus und eine aktive Maske für den Warp enthält. Bei Schritt 510 stellt die Adressenerzeugungseinheit 405 fest, ob der Speicherbankmodus ein Altspeicherbankmodus ist, wie zum Beispiel der 4BB-Speicherbankmodus, und, wenn dies der Fall ist, dann mappt die Adressenerzeugungseinheit 405 bei Schritt 520 die individuelle Speicheradressen basierend auf dem Altspeicherbankmodus, um eine gemappte individuelle Speicheradresse für jeden respektiven Thread in der ersten Threadgruppe zu produzieren bzw. erzeugen.
  • In einer Ausführungsform, in welcher der Speicherbankmodus zu einer bestimmen Einstellung gezwungen werden mag, die anders als der Speicherbankmodus ist, der für das Netz oder Anwendungsprogramm spezifiziert ist, steuert die bestimmte Einstellung, ob die Adressenerzeugungseinheit 405 zum Schritt 520 oder zum Schritt 515 weitergeht.
  • Falls die Adressenerzeugungseinheit 405 beim Schritt 510 feststellt, dass der Speicherbankmodus nicht der Altspeicherbankmodus ist, dann stellt die Adressenerzeugungseinheit 405 fest, dass der Speicherbankmodus keiner Altspeicherbankmodus ist, wie zum Beispiel das 8BB-Speicherbankmodus, und beim Schritt 515 mappt die Adressenerzeugungseinheit 405 die individuelle Speicheradressen dynamisch basierend auf dem nicht-Altspeicherbankmodus, um eine gemappte individuelle Speicheradresse für jeden respektiven Thread in der ersten Threadgruppe zu erzeugen.
  • Bei Schritt 525 stellt die Adressenerzeugungseinheit 405 fest, ob ein Speicherbankkonflikt zwischen zwei oder mehr von den gemappten individuellen Speicheradressen für die erste Threadgruppe vorliegt. Falls die Adressenerzeugungseinheit 405 feststellt, dass kein Speicherbankkonflikt vorliegt, dann sendet die Adressenerzeugungseinheit 405 bei Schritt 535 eine Lese- oder Schreibeanforderung an den Multibank-Speicher, um die Zugriffsanforderung in einem einzigen Taktzyklus zu verarbeiten. Anderenfalls sendet die Adressenerzeugungseinheit 405 bei Schritt 530 Lese- und Schreibeanforderungen an den Multibank-Speicher, um die Zugriffsanforderung in mehreren Taktzyklen zu verarbeiten. In einer Ausführungsform sendet die Adressenerzeugungseinheit 405 keine Lese- oder Schreibeanforderungen an den Multibank-Speicher, wenn ein Speicherbankkonflikt existiert, und gibt stattdessen eine Replayanforderung an die Warp-Scheduler-und-Instruktionseinheit 312 aus, so dass mehrere Zyklen für Verarbeitung der Zugriffsanforderung reserviert werden mögen.
  • Es ist ein Vorteil des offenbarten Verfahrens, dass das Adresse-auf-Speicherbank-Mapping, das zum Zugreifen auf einen Multibank-Speicher verwendet wird, für jeden Taktzyklus geändert werden mag. Jede Speicheradresse, die für parallelen Thread in der Threadgruppe spezifiziert ist, wird dynamisch auf eine Speicherbankadresse basierend auf einem Speicherbankmodus gemappt. Ein erstes Anwendungsprogramm, das zum Vermeiden von Speicherbankkonflikten, wenn jede Speicherbank 32 Bits von Daten speichert, geschrieben ist, mag folglich eine andere Speicheradresse-auf-Speicherbankadresse-Mapping verwenden, in Vergleich mit einem zweiten Anwendungsprogramm, dass zum Vermeiden von Speicherbankkonflikten, wenn jede Speicherbank 64 Bits von Daten speichert, geschrieben ist. Zusammengefasst mag ein älteres Anwendungsprogramm bzw. Altanwendungsprogramm, das zur Ausführung von einem Prozessor, der eine erste Speicherbankgröße aufweist, geschrieben wurde, ausgeführt werden, ohne eine Performanceverringerung zu verursachen, wenn es auf einem zeitgemäßen Prozessor ausgeführt wird, der dazu fähig ist, Speicheradressen dynamisch zu mappen, um sowohl die erste Speicherbankgröße als auch größere Speicherbankgrößen zu unterstützen, die für Operationen mit größeren Bitbreite benötigt werden, die von dem zeitgemäßen Prozessor ausgeführt werden.
  • Eine Ausführungsform der Erfindung mag als ein Programmprodukt zur Verwendung mit einem Computersystem implementiert werden. Das Programm bzw. die Programme des Programmprodukts definiert bzw. definieren Funktionen der Ausführungsformen (einschließlich der hierin beschriebenen Verfahren) und kann bzw. können auf einer Vielfalt von computerlesbaren Speichermedien enthalten werden. Beispielhafte computerlesbare Speichermedien umfassen, sind aber nicht darauf begrenzt:
    • (i) nicht-schreibbare Speichermedien (zum Beispiel schreibgeschützte (engl. „read-only”) Speichervorrichtungen innerhalb eines Computers, wie zum Beispiel Compact-Disc-Read-Only-Memory-(CD-ROM)-Discs, die mittels eines CD-ROM-Laufwerks lesbar sind, Flash-Speicher, Read-Only-Memory-(ROM)-Chips oder jede andere Art von nicht-flüchtigem Festkörper-Halbleiterspeicher (engl. „solid-state non-volatile semiconductor memory”)), auf welchen Informationen permanent gespeichert werden; und
    • (ii) schreibbare Speichermedien (zum Beispiel Floppy-Disks in einem Diskettenlaufwerk oder Festplattenlaufwerk oder jede Art von Festkörper-Halbleiterspeicher mit wahlfreiem Zugriff (engl. „solid-state random-access semiconductor memory”)), auf welchem veränderbare Informationen gespeichert sind.
  • Die Erfindung ist mit Bezug auf spezifische Ausführungsformen oben beschrieben worden. Durchschnittliche Fachleute werden aber verstehen, dass verschiedene Modifikationen und Änderungen davon gemacht werden können, ohne von dem breiteren Geist und Umfang der Erfindung, wie sie in den angehängten Patentansprüchen dargestellt ist, abzuweichen. Die vorhergehenden Beschreibung und Zeichnungen sind folglich eher in einer illustrativen als in einer restriktiven Bedeutung zu beachten.

Claims (10)

  1. Ein Verarbeitungssubsystem aufweisend: eine Adressenerzeugungseinheit, die konfiguriert ist zum: Erhalten einer Speicherzugriffsinstruktion, die eine individuelle Speicheradresse spezifiziert; Erhalten eines Speicherbankmodus, der eine Bitbreite pro Speicherbank für die Speicherzugriffsinstruktion spezifiziert; und dynamischen Mappens der individuellen Speicheradresse basierend auf dem Speicherbankmodus, um eine gemappte individuelle Speicheradresse zu erzeugen; und eine Laden/Speichern-Einheit, die zwischen der Adressenerzeugungseinheit und einem Multibank-Speicher gekoppelt ist und konfiguriert ist zum Senden einer Leseanforderung oder einer Schreibeanforderung an den Multibank-Speicher, um die Speicherzugriffsinstruktion auszuführen.
  2. Das Verarbeitungssubsystem gemäß Anspruch 1, wobei die Speicherzugriffsinstruktion für parallele Ausführung von einem ersten Thread und zusätzlichen Threads in einer ersten Threadgruppe ist, die individuelle Speicheradresse für den ersten Thread in der Threadgruppe spezifiziert ist, die Speicherzugriffsinstruktion zusätzliche individuelle Speicheradressen spezifiziert, einschließlich einer individuellen Speicheradresse für jeden zusätzlichen Thread in der ersten Threadgruppe, und die Bitbreite pro Speicherbank mit der ersten Threadgruppe assoziiert ist; und die Adressenerzeugungseinheit ferner dazu konfiguriert ist zum Mappen der individuellen Speicheradresse und der zusätzlichen individuellen Speicheradressen basierend auf dem Speicherbankmodus, um eine gemappte individuelle Speicheradresse für den ersten Thread und jeden zusätzlichen Thread in der ersten Threadgruppe zu erzeugen.
  3. Das Verarbeitungssubsystem gemäß Anspruch 2, wobei sowohl eine erste gemappte individuelle Speicheradresse für den ersten Thread in der ersten Threadgruppe als auch eine zweite gemappte individuelle Speicheradresse für einen zweiten Thread in der ersten Threadgruppe zu einer ersten Speicherbank des Speichers mit mehreren Speicherbänken mappen.
  4. Das Verarbeitungssubsystem gemäß Anspruch 3, wobei die erste gemappte individuelle Speicheradresse in der Leseanforderung oder Schreibeanforderung enthalten ist, die während eines ersten Zugriffszyklus an den Multibank-Speicher gesendet wird, und die zweite gemappte individuelle Speicheradresse in einer zweiten Leseanforderung oder einer zweiten Schreibeanforderung enthalten ist, die während eines zweiten Zugriffszyklus an den Multibank-Speicher gesendet wird.
  5. Das Verarbeitungssubsystem gemäß Anspruch 1, wobei die Adressenerzeugungseinheit ferner konfiguriert ist zum: Erhalten einer zweiten Speicherzugriffsinstruktion, die eine zweite individuelle Speicheradresse spezifiziert; Erhalten eines zweiten Speicherbankmodus, der eine zweite Bitbreite pro Speicherbank spezifiziert; und dynamischen Mappens der zweiten individuellen Speicheradresse basierend auf dem zweiten Speicherbankmodus, um eine zweite gemappte individuelle Speicheradresse zu erzeugen; und die Laden/Speichern-Einheit ferner konfiguriert ist zum Senden einer zweiten Leseanforderung oder einer zweiten Schreibeanforderung an den Multibank-Speicher, um die zweite Speicherzugriffsinstruktion für die zweite gemappte individuelle Speicheradresse auszuführen.
  6. Das Verarbeitungssubsystem gemäß Anspruch 2, wobei die Adressenerzeugungseinheit ferner konfiguriert ist zum: Erhalten einer aktiven Maske für die erste Threadgruppe, welche aktive Maske diejenige Threads in der ersten Threadgruppe kennzeichnen, die die Speicherzugriffsinstruktion ausführen sollen; und Bestimmen, dass keiner Speicherbankkonflikt innerhalb der ersten Threadgruppe existiert, wenn sowohl eine erste gemappte individuelle Speicheradresse für den ersten Thread, der aktiv ist, als auch eine zweite gemappte individuelle Speicheradresse für einen zweiten Thread, der nicht aktiv ist, zu einer ersten Speicherbank des Speichers mit mehreren Speicherbänken mappen.
  7. Das Verarbeitungssubsystem gemäß Anspruch 1, wobei die Bitbreite pro Bank gleich 32 ist und eine zweite Bitbreite pro Bank gleich 64 ist.
  8. Das Verarbeitungssubsystem gemäß Anspruch 1, wobei die Bitbreite pro Bank gleich 64 ist und eine zweite Bitbreite pro Bank gleich 128 ist.
  9. Das Verarbeitungssubsystem gemäß Anspruch 1, wobei ein N×M-Array von Daten in dem Multibank-Speicher gespeichert ist und wobei die Speicherzugriffsinstruktion entweder eine Spalte oder eine Zeile des N×M-Arrays liest oder schreibt, ohne einen Speicherbankkonflikt zu verursachen.
  10. Das Verarbeitungssubsystem gemäß Anspruch 1, wobei die Speicherbank zum Zugreifen auf Daten spezifiziert ist, die in jeder Speicherbank des Speichers mit mehreren Speicherbänken gespeichert sind, ohne einen Speicherkonflikt zu verursachen, wenn jede Speicherbank des Speichers mit mehreren Speicherbänken gleich N-mal die Bitbreite pro Speicherbank ist.
DE102013205886A 2012-04-05 2013-04-03 Dynamische Bankmodus-Adressierung für Speicherzugriff Ceased DE102013205886A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US13/440,945 2012-04-05
US13/440,945 US9262174B2 (en) 2012-04-05 2012-04-05 Dynamic bank mode addressing for memory access

Publications (1)

Publication Number Publication Date
DE102013205886A1 true DE102013205886A1 (de) 2013-10-10

Family

ID=49210115

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102013205886A Ceased DE102013205886A1 (de) 2012-04-05 2013-04-03 Dynamische Bankmodus-Adressierung für Speicherzugriff

Country Status (4)

Country Link
US (1) US9262174B2 (de)
CN (1) CN103365631B (de)
DE (1) DE102013205886A1 (de)
TW (1) TWI588653B (de)

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9626218B1 (en) * 2014-03-10 2017-04-18 Altera Corporation Repartitioning and reordering of multiple threads into subsets based on possible access conflict, for sequential access to groups of memory banks in a shared memory
US9720696B2 (en) 2014-09-30 2017-08-01 International Business Machines Corporation Independent mapping of threads
US9946588B2 (en) * 2014-12-17 2018-04-17 International Business Machines Corporation Structure for reducing power consumption for memory device
US9996354B2 (en) * 2015-01-09 2018-06-12 International Business Machines Corporation Instruction stream tracing of multi-threaded processors
US9977678B2 (en) 2015-01-12 2018-05-22 International Business Machines Corporation Reconfigurable parallel execution and load-store slice processor
US10133576B2 (en) 2015-01-13 2018-11-20 International Business Machines Corporation Parallel slice processor having a recirculating load-store queue for fast deallocation of issue queue entries
CN105262680A (zh) * 2015-10-21 2016-01-20 浪潮(北京)电子信息产业有限公司 一种应用于云存储系统的多线程nas网关
US20170301382A1 (en) * 2016-04-14 2017-10-19 Cavium, Inc. Method and apparatus for shared multi-port memory access
US10552211B2 (en) * 2016-09-02 2020-02-04 Intel Corporation Mechanism to increase thread parallelism in a graphics processor
US10956360B2 (en) * 2017-03-14 2021-03-23 Azurengine Technologies Zhuhai Inc. Static shared memory access with one piece of input data to be reused for successive execution of one instruction in a reconfigurable parallel processor
US10877757B2 (en) * 2017-11-14 2020-12-29 Nvidia Corporation Binding constants at runtime for improved resource utilization
US11023241B2 (en) 2018-08-21 2021-06-01 Advanced Micro Devices, Inc. Systems and methods for selectively bypassing address-generation hardware in processor instruction pipelines
CN109547355B (zh) * 2018-10-17 2022-05-06 中国电子科技集团公司第四十一研究所 一种基于万兆以太网口接收机的存储解析装置及方法
US10996949B2 (en) * 2019-05-10 2021-05-04 International Business Machines Corporation Address generation for high-performance vector processing
US11397578B2 (en) * 2019-08-30 2022-07-26 Advanced Micro Devices, Inc. Selectively dispatching waves based on accumulators holding behavioral characteristics of waves currently executing
US11836527B2 (en) 2021-08-02 2023-12-05 Nvidia Corporation Accelerating table lookups using a decoupled lookup table accelerator in a system on a chip
US11704067B2 (en) * 2021-08-02 2023-07-18 Nvidia Corporation Performing multiple point table lookups in a single cycle in a system on chip
CN116955044B (zh) * 2023-09-12 2023-12-22 北京开源芯片研究院 处理器的缓存工作机制的测试方法、装置、设备及介质

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7266634B2 (en) * 2000-01-05 2007-09-04 Rambus Inc. Configurable width buffered module having flyby elements
US7363422B2 (en) * 2000-01-05 2008-04-22 Rambus Inc. Configurable width buffered module
US6889304B2 (en) * 2001-02-28 2005-05-03 Rambus Inc. Memory device supporting a dynamically configurable core organization
KR100532471B1 (ko) * 2003-09-26 2005-12-01 삼성전자주식회사 입출력 데이터 위스 조절이 가능한 메모리 장치 및 그위스 조절 방법
KR100790446B1 (ko) * 2006-06-30 2008-01-02 주식회사 하이닉스반도체 스택뱅크 구조를 갖는 반도체 메모리 장치
US7805587B1 (en) 2006-11-01 2010-09-28 Nvidia Corporation Memory addressing controlled by PTE fields
US8392669B1 (en) 2008-03-24 2013-03-05 Nvidia Corporation Systems and methods for coalescing memory accesses of parallel threads
US20100076941A1 (en) * 2008-09-09 2010-03-25 Microsoft Corporation Matrix-based scans on parallel processors
US8171234B2 (en) 2009-03-16 2012-05-01 Mosys, Inc. Multi-bank multi-port architecture
US8587598B2 (en) 2009-10-29 2013-11-19 Mediatek Inc. Memory address mapping method for controlling storage of images in memory device and memory address mapping circuit thereof
US20120047344A1 (en) 2010-08-17 2012-02-23 Sheaffer Gad S Methods and apparatuses for re-ordering data

Also Published As

Publication number Publication date
TW201403321A (zh) 2014-01-16
TWI588653B (zh) 2017-06-21
CN103365631B (zh) 2016-03-16
US20130268715A1 (en) 2013-10-10
CN103365631A (zh) 2013-10-23
US9262174B2 (en) 2016-02-16

Similar Documents

Publication Publication Date Title
DE102013205886A1 (de) Dynamische Bankmodus-Adressierung für Speicherzugriff
DE102013022712B4 (de) Virtuelle Speicherstruktur für Coprozessoren, die Speicherallokationsbegrenzungen haben
DE102012222394A1 (de) Verfahren und Vorrichtung zum Sammelzwischenspeichern von Quelloperanden
DE102013208554B4 (de) Verfahren und System zum Managen verschachtelter Ausführungsströme
DE102013202173A1 (de) Einheitliche Lade-Verarbeitung für Teilsätze von parallelen Threads
DE102013200997A1 (de) Ein blockierungsfreies FIFO
DE102012222558B4 (de) Signalisieren, Ordnen und Ausführung von dynamisch erzeugten Aufgaben in einem Verarbeitungs-System
DE102012211670A1 (de) Simultanes Unterbreiten an eine Mehr-Produzenten-Queue mittels mehrerer Threads
DE102012221504B4 (de) Mehrniveau-Anweisung-Zwischenspeicher-Zuvor-Holen
DE102018132468A1 (de) Multi-gpu-frame-rendern
DE102013017509A1 (de) Effiziente Speichervirtualisierung in mehrsträngigen Verarbeitungseinheiten
DE102013114072A1 (de) System und Verfahren zum Hardware-Scheduling von indexierten Barrieren
DE102012220267B4 (de) Rechenarbeitsverteilungs - Referenzzähler
DE102013017511A1 (de) Effiziente speichervirtualisierung in mehrsträngigen verarbeitungseinheiten
DE102013017510A1 (de) Effiziente Speichervirtualisierung in mehrsträngigen Verarbeitungseinheiten
DE102012221502A1 (de) System und Verfahren zum Durchführen von gestalteter-Speicherzugriff-Operationen
DE102013100179A1 (de) Verfahren und System zum Auflösen von Thread-Divergenzen
DE102013020968A1 (de) Technik zum Zugreifen auf einen inhaltsadressierbaren Speicher
DE112010003750T5 (de) Hardware für parallele Befehlslistenerzeugung
DE102013208421A1 (de) Sharing einer Grafikverarbeitungseinheit unter vielen Anwendungen
DE102009046847A1 (de) Mehrklassen-Daten-Cache-Verfahren
DE112010003758T5 (de) Instruktionen zum Verwalten einer parallelen Cache-Hierarchie
DE102009039231A1 (de) Einzeldurchgang-Kachelung
DE102013201178A1 (de) Steuern von Arbeitsverteilung für Verarbeitung von Tasks
DE102013020485A1 (de) Technik zur Ausführung von Speicherzugriffsoperationen über eine Textur-Hardware

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R016 Response to examination communication
R082 Change of representative

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

R016 Response to examination communication
R016 Response to examination communication
R002 Refusal decision in examination/registration proceedings
R006 Appeal filed
R008 Case pending at federal patent court
R003 Refusal decision now final
R011 All appeals rejected, refused or otherwise settled