DE102022117746A1

DE102022117746A1 - Speicherschnittstelle mit energiesparendem übertragungsmodus

Info

Publication number: DE102022117746A1
Application number: DE102022117746.7A
Authority: DE
Inventors: James Michael O'Connor; Donghyuk Lee
Original assignee: Nvidia Corp
Current assignee: Nvidia Corp
Priority date: 2021-07-30
Filing date: 2022-07-15
Publication date: 2023-02-02
Also published as: CN115687194A; US20230043152A1

Abstract

PAM-Kodierungstechniken, die ungenutzte Leerlaufzeiten in Kanälen zwischen Datenübertragungen nutzen, um längere, aber energieeffizientere Codes anzuwenden. Um die Energieeinsparungen zu verbessern, können mehrere dünnbesetzte Kodierungsverfahren selektiv eingesetzt werden, um unterschiedlich große Lücken im Datenverkehr zu schließen. Diese Ansätze können beispielsweise beim READ- und WRITE-Verkehr mit Speicher Energieeinsparungen bringen, wenn 4-Bit-Daten unter Verwendung von 3-Symbol-Sequenzen übertragen werden.

Description

HINTERGRUND
Puls-Amplituden-Modulation (PAM) verwendet mehrere Spannungspegel, um verschiedene Datensymbole auf einem Kommunikationsbus zu repräsentieren, wobei mehrere Datenbits gleichzeitig übertragen werden, wodurch eine höhere Kommunikationsbandbreite ohne höhere operative Frequenzen ermöglicht wird. Die Aufteilung der Spannung in mehrere Symbole führt jedoch zu einer geringeren Spannungsdifferenz zwischen benachbarten Symbolen, wodurch die Schnittstelle anfälliger für Übersprechen (engl. crosstalk) und Leistungsrauschen (engl. power noise) wird. Herkömmliche PAM-Kodierungsverfahren können übermäßig viel Energie verbrauchen und übermäßiges Leistungsrauschen erzeugen.
Figurenliste
Um die Erörterung eines bestimmten Elements oder einer bestimmten Handlung leicht erkennen zu können, beziehen sich die höchstwertige(n) Ziffer(n) einer Bezugsnummer auf die Figurennummer, in der dieses Element zum ersten Mal eingeführt wird.

1A zeigt ein Beispiel für PAM-2-Symbole 100a.
1B zeigt ein Beispiel für PAM-4-Symbole 100b.
2A zeigt einen Leitungstreiber für das PAM-4-Symbol L0, gemäß einem Ausführungsbeispiel.
2B zeigt einen Leitungstreiber für das PAM-4-Symbol L1, gemäß einem Ausführungsbeispiel.
2C zeigt einen Leitungstreiber für das PAM-4-Symbol L2, gemäß einem Ausführungsbeispiel.
2D zeigt einen Leitungstreiber für das PAM-4-Symbol L3, gemäß einem Ausführungsbeispiel.
3 Datenbitpartitionierung mit Vermeidung von maximalen Übergängen (Maximum-Transition-Avoidance, MTA), gemäß einem Ausführungsbeispiel.
4 zeigt eine Datenzuordnung zu seriellen Leitungen mit und ohne MTA, gemäß einem Ausführungsbeispiel.
5A zeigt eine lückenlose Leseoperation, gemäß einem Ausführungsbeispiel.
5B zeigt ein Lesen einer Taktlücke, gemäß einem Ausführungsbeispiel.
5C zeigt eine Dünnbesetzungs-Kodierung, gemäß einem Ausführungsbeispiel.
5D zeigt eine Dünnbesetzungs-Kodierung, gemäß einem weiteren Ausführungsbeispiel.
6 zeigt eine Kodierungslogik, gemäß einem Ausführungsbeispiel.
7 zeigt den Energieverbrauch für Vier-Bit-Eingabecodes, gemäß einem Ausführungsbeispiel.
8 zeigt Vergleiche des Energieverbrauchs, gemäß einem Ausführungsbeispiel.
9 zeigt eine Parallelverarbeitungseinheit 920, gemäß einem Ausführungsbeispiel.
10 zeigt einen allgemeinen Verarbeitungscluster 1000, gemäß einem Ausführungsbeispiel.
11 zeigt eine Speicherpartitionseinheit 1100, gemäß einem Ausführungsbeispiel.
12 zeigt einen Streaming-Multiprozessor 1200, gemäß einem Ausführungsbeispiel.
13 zeigt ein Verarbeitungssystem 1300, gemäß einem Ausführungsbeispiel.
14 zeigt ein beispielhaftes Verarbeitungssystem 1400, gemäß einem Ausführungsbeispiel.
15 zeigt eine Grafikverarbeitungs-Pipeline 1500, gemäß einem Ausführungsbeispiel.

DETAILLIERTE BESCHREIBUNG
Ausführungsbeispiele von Techniken zur Energiereduzierung für die PAM-Kommunikation auf einseitigen seriellen Verbindungen sind hierin offenbart. Ungenutzte Leerlaufzeiten in Kanälen zwischen Datenübertragungen werden genutzt, um längere, aber energieeffizientere Codes anzuwenden. Um die Energieeinsparungen zu maximieren, kann eine multi-modale Dünnbesetzungs- Kodierungsmethodik verwendet werden, um die angewandte Kodierung dynamisch an unterschiedlich große Lücken im Datenverkehr anzupassen. Dies kann zu erheblichen (z.B. > 20%) Energieeinsparungen bei der Kommunikation von 4-Bit-Daten unter Verwendung von 3-Symbol-Sequenzen führen. Eine Kodierung einer Folge von N Bits in Symbole ist dünnbesetzt (sparse), wenn die Anzahl der für die Bitfolge verwendeten Symbole größer ist als für eine optimale Kodierung von N Bits erforderlich. Somit ist die Dünnbesetzung (Sparsity) einer Kodierung eine Funktion sowohl der Anzahl der zur Kodierung der Bitfolge verwendeten Symbole als auch der Anzahl der in den Symbolen verwendeten Spannungspegel (Spannungsstufen/Spannungslevel).
In PAM-4-Ausführungsbeispielen können längere, energieeffiziente dünnbesetzte Kodierungen opportunistisch während Leerlauflücken auf einem seriellen Datenbus angewandt werden, mit der Einschränkung, dass 3ΔV-Übergänge zwischen Symbolen vermieden werden, während gleichzeitig Leistungsverluste verringert werden.
Auf einigen Rechnerplattformen ist die am häufigsten auftretende Taktlücke auf dem Bus ein Taktintervall lang. Dies schränkt die Techniken ein, die bei der Generierung längerer, dünnbesetzter Symbolcodes, die die energieärmsten Symbole umfassen, eingesetzt werden können.
Bei der PAM-4-Signalisierung stehen vier verschiedene Spannungspegel zur Verfügung, um jedes Symbol zu kodieren. Jedes Symbol kann somit 2 Datenbits kodieren. Für die Übertragung von 4 Bits sind zwei Symbole erforderlich, und es gibt 16 Möglichkeiten, die 4 Bits in diesen beiden Symbolen zu kodieren. Vier solcher Sequenzen mit dem geringsten Energieverbrauch sind L0L0, LOL1, L1L0 und L2L0.
Die Stromaufnahme (Energiedifferenz) zwischen L0 und L1 (z.B. 9,4 mA) ist größer als die Differenz zwischen L1 und L2 (z.B. 6,6 mA). Dadurch ist die Symbolfolge L2L0 (oder LoL2) energieeffizienter zu übertragen als die Folge L1L1.
Die Anzahl der Datenbits, die in den Encoder eingegeben werden, ist ein zu berücksichtigender Designparameter. Beispielsweise kann die Eingabe von mehr Bits zur gleichzeitigen Kodierung energieeffizientere Codes ermöglichen. Allerdings steigt der Overhead der Nachschlagetabelle (die mit synthetischen Logikgattern implementiert werden kann) bei größeren Eingabelängen erheblich an. In einem Ausführungsbeispiel werden Kodierungsschemata verwendet, die 4 Bits auf einmal kodieren und den Großteil der Vorteile von Kodierern mit längeren Bitfolgen bieten, während sie relativ wenig Schaltungsfläche und Energie für den Kodierer verbrauchen.
Ein weiterer Designparameter ist die resultierende Codelänge nach der Kodierung. Dies ist die Anzahl der Symbole, die auf der Datenleitung gesendet werden, um die Eingabe-Bitfolge zu repräsentieren. Eine Ausgabe-Codelänge von vier Symbolen bedeutet zum Beispiel, dass die Datenfolge als vier PAM-4-Symbole codiert und übertragen wird. Die Länge des Ausgabecodes bestimmt den Bandbreiten-Overhead des Codes. Ein längerer dünnbesetzter Code kann eine höhere Energieeffizienz bieten, wird aber möglicherweise seltener angewendet, da weniger Kommunikationsszenarien ein ausreichendes Lückenintervall auf der Datenleitung umfassen, um den Code ohne Leistungseinbußen unterzubringen.
Ein weiterer Parameter ist die Anzahl der Spannungspegel, die für die dünnbesetzten Codesymbole verwendet werden. Wenn der dünnbesetzte Ausgabecode beispielsweise nur die Symbole L0 und L1 verwendet, kann dies als 2-Pegel-Kodierung in PAM-4 bezeichnet werden (weil die Spannungspegel der Symbole selbst die eines PAM-4-Treibers sind, aber in der Praxis nur zwei der vier PAM-4-Symbole verwendet werden). Eine N-Level-Kodierung in PAM-4 bedeutet, dass der dünnbesetzte Code die N<4 PAM-4-Symbole verwendet, die der Datenleitung die geringste Energie entziehen. Durch die Verwendung einer 2-Pegel- oder 3-Pegel-Kodierung in PAM-4 für dünnbesetzte Ausgabecodes wird der maximale Übergang zwischen den Symbolen auf 1ΔV bzw. 2ΔV begrenzt. Da der maximale Übergang von PAM-4 (3ΔV) grundsätzlich vermieden wird, benötigen solche dünnbesetzten Kodierungsverfahren keinen Mechanismus zur Begrenzung des Übergangs wie MTA.
Die Kombination aus der Länge des Ausgabecodes und der Anzahl der verwendeten Pegel bestimmt den Coderaum des generierten dünnbesetzten Codes. Wenn beispielsweise die Ausgabe-Codelänge vier Symbole und die Anzahl der genutzten Pegel drei beträgt, ist die Anzahl der verschiedenen Symbolfolgen, der Coderaum, 34 = 81. Bei einer Eingabe-Codelänge von 4 Bits wird ein Code ausgewählt, der die sechzehn Sequenzen mit der niedrigsten Energie aus den 81 möglichen Ausgabe-Kombinationen nimmt. Wir nennen dies einen 4-Bit-zu-4-Symbol-Code mit 3 Pegel (4b4s31). 6 zeigt die Kodierungen für vier verschiedene 4-Bit-Eingabe-3-Pegel-Codes mit unterschiedlichen Codelängen (4b3s31, 4b4s31, 4b6s31 und 4b8s31).
Dünnbesetzte Kodierungen von 2-Level- oder 3-Level-Symbolen erreichen MTA ohne Nutzung der DBI-Leitung. Um den Energieverbrauch weiter zu senken, kann die DBI-Leitung zusätzlich zur dünnbesetzten Kodierung verwendet werden. Zum Beispiel kann die DBI-Leitung verwendet werden, um Teile von acht Datenbitsequenzen zu übertragen, die gleichzeitig über acht Datenleitungen übertragen werden.
In einem Ausführungsbeispiel wird eine dünnbesetzte Kodierung auf eine Eingabe-Bitfolge zusammen mit einem DBI-Mechanismus angewendet. Der DBI-Mechanismus kann auf einen dünnbesetzten 3-Ebenen-Code angewendet werden, wobei eine Level-Swap-Technik verwendet wird. Wird ein Symbol während eines Bursts auf der Mehrheit der Datenleitungen repräsentiert und handelt es sich nicht um das Symbol mit der geringsten Energie L0, wird es mit L0 vertauscht. Das DBI-Signal gibt an, ob L0 gegen L1 oder L2 (oder keines von beiden) ausgetauscht wurde. Dieser Mechanismus kann z. B. bei 2-Level- oder 3-Level-Codes verwendet werden. Im folgenden Algorithmus bezieht sich NL auf die Anzahl der Symbole eines gegebenen Pegels auf M Datenleitungen. Wenn z. B. M=8 ist, bezieht sich NL1 auf die Anzahl der L1-Symbole, die in einem gegebenen Burst auf acht Datenleitungen übertragen werden.

Vertauschen von L0 und L1 und Setzen von DBI = L1, wenn NL1 > M/2
Vertauschen von L0 und L2 und Setzen von DBI = L2, wenn NL2 > M/2
Andernfalls DBI = L0

Ein 2-Pegel- oder 3-Pegel-Code hat niemals 3ΔV-Übergänge zwischen seinen eigenen Symbolen. Es kann jedoch eine Situation eintreten, in der der unmittelbar vorhergehende Code mit einem L3-Symbol abschließt und der aktuelle Code mit einem L0-Symbol beginnt. Diese Situation führt zu einem verrauschten 3ΔV-Ubergang auf der Datenspur. In einem Ausführungsbeispiel invertiert der Codierer den gesamten Code unter der Bedingung, dass das vorherige Symbol mit einem L3-Symbol endete. Dies hat keinen wesentlichen Einfluss auf die Energieeffizienz des Kodierungsmechanismus.
Bei dünnbesetzten Codes ist die Invertierung eines Codes auf diese Weise unpraktisch, da in der Praxis eine große Anzahl von energieminimalen L0-Symbolen in energieaufwendige L3-Symbole umgewandelt werden kann. Anstatt den Code zu invertieren, können dünnbesetzte Codes ein Level-Shifting-Verfahren verwenden. Wenn das vorhergehende Symbol auf dem Bus ein L3-Symbol ist, wird das nächste Symbol mit einem um eins höheren Pegel übertragen, als es sonst der Fall gewesen wäre. Wenn also auf ein L3-Symbol ein problematisches L0-Symbol folgen würde, wird es stattdessen von einem pegelverschobenen L1-Symbol gefolgt. Wenn das nächste Symbol nach einem L3-Symbol ein L2-Symbol ist, wird das Symbol auf der Datenspur zu einem L3-Symbol verschoben. In diesem letzteren Fall wird das auf das L2-Symbol folgende Symbol, das zu einem L3-Symbol befördert wurde, ebenfalls einer Pegelverschiebung unterzogen usw.
Die Pegelverschiebung wird nach der Anwendung von DBI durchgeführt. Der Empfänger subtrahiert einen Pegel von jedem Symbol, das nach einem L3-Symbol empfangen wird, und wendet dann die DBI-spezifische Pegelverschiebung an, falls erforderlich. Mit diesem Ansatz lassen sich 3ΔV-Übergänge an den Nahtstellen zwischen einem MTA-codierten Burst und einem dünnbesetzten Burst wirksam vermeiden.
1A zeigt ein Beispiel für PAM-2-Symbole 100a. Bei Hochgeschwindigkeitsschnittstellen ist es üblich, jede Datenleitung über einen Abschlusswiderstand an die Versorgungsspannung VDD zu koppeln. Somit liegt ein Symbol auf dem VDD-Pegel und ein anderes Symbol auf einem Spannungspegel, der durch das Verhältnis zwischen dem Abschlusswiderstand und dem „Ein“-Widerstand des Treibers bestimmt wird. Aufgrund dieses Abschlussschemas zieht die Schnittstelle bei der Übertragung von Symbolen mit niedrigerer Spannung Strom und verbraucht mehr Energie als bei der Übertragung von Symbolen mit höherer Spannung. Um eine höhere Bandbreite bei gleicher Taktfrequenz zu ermöglichen, können Systeme mehr Pegel in die PAM E/A-Schnittstelle einführen.
1B zeigt ein Beispiel für PAM-4-Symbole 100b mit vier verschiedenen Spannungspegel, die zwei Bits pro Symbol kodieren. Dieser Ansatz bietet die doppelte Bandbreite von PAM-2, wenn er mit der gleichen Frequenz betrieben wird.
2A - 2D zeigen Ausführungsbeispiele von Leitungstreibern für die PAM-4-Symbole L0, L1, L2, und L3. Die unterschiedlichen Spannungspegel für die verschiedenen Symbole werden generiert, indem Widerstände an der Eingabe in die serielle Datenleitung auf unterschiedliche Weise kombiniert werden. Um ein Symbol mit niedrigerer Spannung zu liefern, werden mehr Treiber aktiviert, was zu einem höheren Stromfluss führt. Die Widerstandsspalte in Tabelle 1 zeigt Beispiele für PAM-4-Symbole und den entsprechenden Spannungs- und Stromabfluss auf der seriellen Leitung.
Aufgrund der unterschiedlichen Stromaufnahme haben die verschiedenen Symbole unterschiedliche Energieverbräuche. In Tabelle 1 hat L0 den niedrigsten und L3 den höchsten Energieverbrauch. Wie Tabelle 1 zeigt, kann die PAM-4-Signalisierung einige praktische Probleme mit sich bringen, wie z. B. eine größere Anfälligkeit für Leistungsrauschen und Übersprechen durch Aktivitäten in benachbarten Datenleitungen. Wird beispielsweise eine 1,35-V-Versorgung für VDD verwendet, beträgt der Spannungsunterschied zwischen den PAM-4-Symbolen nur 225 mV. Der geringere Spannungsunterschied zwischen benachbarten Symbolen im Vergleich zur PAM-2-Signalisierung bedeutet, dass kleinere Variationen in der Signalspannung dazu führen können, dass das falsche Symbol detektiert wird. Diese Probleme sind besonders schwerwiegend, wenn die Symbole zwischen dem maximalen und dem minimalen Spannungspegel, L0 und L3, oder umgekehrt wechseln. Diese maximalen Übergangsschwankungen verursachen das meiste Rauschen in den Signalen auf den benachbarten Datenleitungen. Die maximalen Übergangsschwankungen erfordern auch die schnellsten Spannungsänderungen, was zu den anfälligsten Zeiten für Übersprechen führt. Tabelle 1

Symbol Strom Spannung

L0 0 mA VDD

L1 9.4 mA 5/6 VDD

L2 15.0 mA 2/3 VDD

L3 17.0 mA 1/2 VDD
3 zeigt eine 7-Bit-zu-4-Symbol-MTA-Kodierlogik (z.B. ein „Codebuch“), gemäß einem Ausführungsbeispiel. Um die Probleme anzugehen, die durch Übergänge zwischen den Symbolen mit der höchsten und der niedrigsten Spannung verursacht werden, kann die MTA-Kodierung (Maximum Transition Avoidance) verwendet werden. Bei dieser Technik werden die Daten so kodiert, dass auf dem Datenbus keine 3ΔV-Übergänge von L0 nach L3 oder L3 nach L0 auftreten. Die MTA-Kodierung basiert auf den 139 möglichen 4-Symbol-Sequenzen, die mit L0, L1 oder L2 beginnen und keine 3ΔV-Übergänge enthalten. Von diesen 139 Sequenzen werden die 11 Sequenzen mit der höchsten Energie verworfen, so dass ein Satz von 128 Symbolen übrig bleibt. 3 zeigt ein Beispiel für eine MTA-Kodierung gemäß diesen Einschränkungen.
4 zeigt die Datenallokation zu seriellen Datenleitungen mit und ohne MTA, gemäß einem Ausführungsbeispiel. Der MTA-Kodierungsprozess teilt jede 8-Bit-Sequenz, die auf einer gegebenen Datenleitung gesendet werden würde, in ihr höchstwertiges 1 -Bit und die restlichen 7-Bits auf. Die 7-Bits werden in eine von 128 4-Symbol-Sequenzen umgewandelt (z.B. die in 3). Diese Kodierung wird für Gruppen von acht 8-Bit-Signalen durchgeführt. Die verbleibenden nicht kodierten 1 -Bit aus jedem der acht Signale werden zu einer 4-Symbol-PAM-4-Sequenz kombiniert, die parallel zu den kodierten Daten auf einer neunten Datenleitung (DBI-Leitung) übertragen wird. Da die auf dieser DBI-Leitung gesendeten Daten nicht MTA-kodiert sind, können zusätzliche Konstruktionseinschränkungen nur auf die DBI-Leitung angewendet werden, z. B. die Anwendung eines zusätzlichen Abstands zwischen der DBI-Leitung und den Datenleitungen oder das Hinzufügen zusätzlicher Erdungsabschirmungsdrähte.
Die MTA-Kodierung beinhaltet eine zusätzliche Verbesserung, um 3ΔV-Übergänge zwischen aufeinanderfolgenden kodierten 4-Symbol-Sequenzen zu verhindern. Während jede der 128 kodierten Sequenzen mit einem L0-, L1- oder L2-Symbol beginnt, kann eine Sequenz mit einem L3-Symbol enden. Infolgedessen kann ein L3-zu-L0-Übergang von einer Sequenz zur nächsten auftreten. Um dies zu verhindern, wird jedes Mal, wenn eine Symbolfolge mit einem L2- oder L3-Symbol endet, das nächste kodierte Symbol auf dieser Datenspur invertiert gesendet. Ein L0-Symbol wird als L3, L1 als L2, L2 als L1 und L3 als L0 übertragen. Durch diese Invertierung wird der problematische 3ΔV-Übergang zwischen aufeinanderfolgenden Symbolen verhindert. Ein spezielles Verfahren wird auch angewandt, wenn nach einem Datenburst keine Daten zu senden sind. Nach einem Datenburst kann eine „Postambel“ im Abstand von einem Taktintervall auf eine unbesetzte Datenleitung angewendet werden. Diese Postambel setzt den Bus auf die L1-Spannung und verhindert 3ΔV-Ubergänge am Ende eines Bursts.
5A zeigt ein Beispiel für eine lückenlose READ Operation. Zwei READ-Befehle werden vom Speicher abgearbeitet. Die Befehle und Adressen werden in jedem der Taktzyklen T0 und T2 bereitgestellt. Nach dem Empfang des ersten READ-Befehls im Zyklus T0 dekodiert der Empfänger den Befehl/die Adresse und bringt die angeforderten Daten aus dem entsprechenden Array an die E/A-Schnittstelle (z.B. die Leitungstreiber). Dies dauert eine gewisse Zeit, RL, die Leselatenz. Ab dem Zyklus T_RL beginnt der Empfänger, die 256-Bit-Lesedaten unter Verwendung von PAM-4 über die Datenkanäle zu übertragen. Die Daten werden in einem Burst als acht Symbole auf jeder der sechzehn seriellen Datenkanäle (plus zwei DBI-Pins) übertragen. Die Daten werden an beiden Flanken eines Taktes gesendet, der mit der doppelten Rate des Befehlstaktes getaktet ist.
Somit wird die gesamte Lesedatenantwort in den beiden Zyklen von T_RL bis T_RL +2 an die Quelle des READ-Befehls zurück übertragen. Der bei T2 empfangene READ-Befehl überträgt seine Daten in den beiden folgenden Zyklen T_RL +2 bis T_RL +4. Liegen mehr als zwei Takte zwischen aufeinanderfolgenden READ-Befehlen, führt die zusätzliche Lücke zu Leerlaufzyklen auf dem Datenbus. Diese Leerlaufzyklen werden hier als Lücken bezeichnet.
5B zeigt einen READ-Befehl mit einer Lücke von zwei Takten und einer L1-Postambel mit einem Takt, um 3ΔV-Übergänge zwischen einem L3-Symbol und einem L0-(Leerlauf-)Symbol zu vermeiden. Zwei READ-Befehle, die bei T0 bzw. T4 gesendet werden, sind durch vier Taktintervalle getrennt.. Dies führt zu einer Leerlaufzeit von zwei Takten (Lücke 502) auf der Datenspur. Nach Abschluss der ersten Datenübertragung bei T_RL +2 folgt die Postambel mit einem Befehlstakt, in der die dem L1-Symbol entsprechende Spannung auf der Datenleitung aufrechterhalten wird. Diese Postambel verhindert, dass 3ΔV-Übergänge vom letzten Symbol (z.B. einem L3) in einem Burst zu einem Leerlaufbus (Lo-Symbol) stattfinden. Nach der Postambel kehrt der Bus zu dem LO-Symbol mit der niedrigsten Energie bei T_RL +3 zurück.
5C und 5D zeigen die dynamische Nutzung verschiedener Kodierungsmechanismen in verschiedenen Buskommunikationsszenarien, z.B. verschiedene Taktintervalllücken. 5C zeigt einen Lesevorgang mit zwei Taktintervallen und einer L1-Postambel mit einem Takt, um 3ΔV-Übergänge zwischen einem L3-Symbol und einem L0-(Leerlauf-)Symbol zu vermeiden. Das Ausführungsbeispiel in 5D ist eine 4-Bit-zu-3-Symbol-Kodierung für eine Lücke von einem Taktintervall, wobei die Symbole jeweils einen von drei Spannungspegeln umfassen (d.h. eine (4b3s31-Kodierung).
6 zeigt die zuvor beschriebene Kodierlogik für dünnbesetzte 4-Bit-Kodierungen verschiedener Länge auf 3 Pegel, gemäß einem Ausführungsbeispiel. Bei der Implementierung kann jede Spalte oder Kombination von Spalten ein eigenes „Codebuch“ für PAM-Symbole repräsentieren, die auf einem Datenbus übertragen werden, oder die Logik kann als ein einziges „Codebuch“ betrachtet werden. In der Praxis können einige oder alle „Codebücher“ in einem oder mehreren Assoziativspeichern gespeichert werden (z. B. indiziert durch die „Eingabe“-Sequenz).
7 zeigt Beispiele für den Energieverbrauch verschiedener Kodierungsmechanismen bei 4-Bit-Eingangssequenzen.
8 zeigt ein Beispiel eines Energieverbrauchs für die Basis-PAM-4-Kodierung im Vergleich zu dünnbesetzten Kodierungen in einem Ausführungsbeispiel.
Ausführungsbeispiele der hier offengelegten Kommunikationsmechanismen können von Rechengeräten implementiert werden, die eine oder mehrere Grafikverarbeitungseinheiten (GPU) und/oder allgemeine Datenprozessoren (z.B. eine „Central Processing Unit“ oder CPU) verwenden. Ausführungsbeispiele der hier beschriebenen Kodierungstechniken und Schaltungen zu ihrer Durchführung können beispielsweise für die Kommunikation zwischen GPUs und/oder zwischen parallelen Verarbeitungseinheiten in einem System, zwischen einer GPU und einer CPU oder zwischen einer der oben genannten Komponenten und einem Gerät verwendet werden. Es werden nun beispielhafte Architekturen beschrieben, die so konfiguriert werden können, dass sie die hier offenbarten Techniken auf derartigen Geräten ausführen.
In der folgenden Beschreibung können bestimmte Akronyme und Abkürzungen wie folgt verwendet werden:

„DPC“ bezieht sich auf einen „Datenverarbeitungscluster“;
„GPC“ bezieht sich auf einen „allgemeinen Verarbeitungscluster“;
„E/A“ bezieht sich auf eine „Eingabe/Ausgabe“;
„L1-Cache“ bezieht sich auf einen „Level-1-Cache“;
„L2-Cache“ bezieht sich auf einen „Level-2-Cache“;
„LSU“ bezieht sich auf eine „Lade-/Speichereinheit“;
„MMU“ bezieht sich auf eine „Speicherverwaltungseinheit“;
„MPC“ bezieht sich auf einen „M-Pipe-Controller“;
„PPU“ bezieht sich auf eine „Parallelverarbeitungseinheit“;
„PROP“ bezieht sich auf eine „Pre-Raster Operations Unit“;
„ROP“ bezieht sich auf eine „Raster Operation“;
„SFU“ bezieht sich auf eine „spezielle Funktionseinheit“;
„SM“ bezieht sich auf einen „Streaming-Multiprozessor“;
„Viewport SCC“ bezieht sich auf „Viewport scale, cull, and clip“;
„WDX“ bezieht sich auf eine „Work Distribution Crossbar“; und
„XBar“ bezieht sich auf eine „Crossbar“.

Parallelverarbeitungseinheit
9 stellt eine Parallelverarbeitungseinheit 920 dar, gemäß einem Ausführungsbeispiel. In einem Ausführungsbeispiel ist die Parallelverarbeitungseinheit 920 ein Multi-Thread-Prozessor, der auf einem oder mehreren Geräten mit integrierter Schaltung implementiert ist. Bei der Parallelverarbeitungseinheit 920 handelt es sich um eine latenzverbergende Architektur, die dafür ausgelegt ist, viele Threads parallel zu verarbeiten. Ein Thread (z.B. ein Ausführungsstrang) ist eine Instanziierung eines Satzes von Anweisungen, die für die Ausführung durch die Parallelverarbeitungseinheit 920 konfiguriert sind. In einem Ausführungsbeispiel ist die Parallelverarbeitungseinheit 920 eine Grafikverarbeitungseinheit (GPU), die so konfiguriert ist, dass sie eine Grafik-Rendering Pipeline für die Verarbeitung dreidimensionaler (3D) Grafikdaten implementiert, um zweidimensionale (2D) Bilddaten für die Anzeige auf einem Anzeigegerät, wie z. B. einem Flüssigkristallanzeigegerät (LCD), zu generieren. In anderen Ausführungsbeispielen kann die Parallelverarbeitungseinheit 920 zur Durchführung von allgemeinen Berechnungen verwendet werden. Während ein beispielhafter Parallelprozessor hier zu illustrativen Zwecken dargestellt wird, sollte ausdrücklich darauf hingewiesen werden, dass ein solcher Prozessor nur zu illustrativen Zwecken dargestellt wird und dass jeder beliebige Prozessor zur Ergänzung und/oder zum Ersatz desselben verwendet werden kann.
Ein oder mehrere Module der Parallelverarbeitungseinheit 920 können so konfiguriert werden, dass sie Tausende von Anwendungen für High Performance Computing (HPC), Datenzentren und maschinelles Lernen beschleunigen. Die Parallelverarbeitungseinheit 920 kann so konfiguriert werden, dass sie zahlreiche Deep-Learning-Systeme und -Applikationen beschleunigt, darunter autonome Fahrzeugplattformen, Deep Learning, hochpräzise Sprach-, Bild- und Texterkennungssysteme, intelligente Videoanalysen, molekulare Simulationen, Arzneimittelentdeckung, Krankheitsdiagnose, Wettervorhersage, Big-Data-Analytik, Astronomie, Molekulardynamiksimulation, Finanzmodellierung, Robotik, Fabrikautomatisierung, Echtzeit-Sprachübersetzung, Online-Suchoptimierung und personalisierte Benutzerempfehlungen und dergleichen.
Wie in 9 gezeigt, umfasst die Parallelverarbeitungseinheit 920 eine E/A-Einheit 902, eine Front-End-Einheit 904, eine Planer-Einheit 908, eine Arbeitsverteilungseinheit 910, einen Hub 906, eine Crossbar 914, ein oder mehrere allgemeine Verarbeitungscluster 1000-Module und ein oder mehrere Speicherpartitionseinheiten 1100-Module. Die Parallelverarbeitungseinheit 920 kann mit einem Host-Prozessor oder anderen Modulen der Parallelverarbeitungseinheit 920 über eine oder mehrere Hochgeschwindigkeits-NVLink 916-Verbindungen verbunden sein. Die Parallelverarbeitungseinheit 920 kann über eine Zwischenverbindung 918 mit einem Host-Prozessor oder anderen peripheren Geräten verbunden sein. Die Parallelverarbeitungseinheit 920 kann auch mit einem lokalen Speicher verbunden sein, der eine Reihe von Speichergeräten 912 umfasst. In einem Ausführungsbeispiel kann der lokale Speicher eine Reihe von DRAM-Geräten (Dynamic Random Access Memory) umfassen. Die DRAM-Geräte können als HBM-Subsystem (High-Bandwidth Memory) konfiguriert sein, wobei in jedem Gerät mehrere DRAM-Chips gestapelt sind. Der Speicher 912 kann eine Logik umfassen, um die Parallelverarbeitungseinheit 920 so zu konfigurieren, dass sie Aspekte der hier offenbaren Techniken ausführt.
Die NVLink 916-Verbindung ermöglicht die Skalierung von Systemen und umfasst ein oder mehrere Module der Parallelverarbeitungseinheit 920, die mit einer oder mehreren CPUs kombiniert sind, unterstützt die Cache-Kohärenz zwischen den Modulen der Parallelverarbeitungseinheit 920 und den CPUs sowie das CPU-Mastering. Daten und/oder Befehle können über den NVLink 916 durch den Hub 906 zu/von anderen Einheiten der Parallelverarbeitungseinheit 920 übertragen werden, z. B. einer oder mehreren Copy-Engines, einem Video-Encoder, einem Video-Decoder, einer Einheit zur Verwaltung der Stromversorgung usw. (nicht explizit dargestellt). Der NVLink 916 wird in Verbindung mit 13 detaillierter beschrieben.
Die E/A-Einheit 902 ist so konfiguriert, dass sie Kommunikationen (z.B. Befehle, Daten usw.) von einem Host-Prozessor (nicht abgebildet) über die Zwischenverbindung 918 sendet und empfängt. Die E/A-Einheit 902 kann mit dem Host-Prozessor direkt über die Verbindung 918 oder über ein oder mehrere zwischengeschaltete Geräte wie eine Speicherbrücke kommunizieren. In einem Ausführungsbeispiel kann die E/A-Einheit 902 mit einem oder mehreren anderen Prozessoren, wie z. B. einem oder mehreren Modulen der Parallelverarbeitungseinheit 920, über die Verbindung 918 kommunizieren. In einem Ausführungsbeispiel implementiert die E/A-Einheit 902 eine Peripheral Component Interconnect Express (PCIe)-Schnittstelle für die Kommunikation über einen PCIe-Bus, und die Verbindungsleitung 918 ist ein PCIe-Bus. In alternativen Ausführungsbeispielen kann die E/A-Einheit 902 andere Arten von bekannten Schnittstellen für die Kommunikation mit externen Geräten implementieren.
Die E/A-Einheit 902 dekodiert Pakete, die über die Verbindung 918 empfangen werden. In einem Ausführungsbeispiel repräsentieren die Pakete Befehle, die so konfiguriert sind, dass sie die Parallelverarbeitungseinheit 920 veranlassen, verschiedene Operationen durchzuführen. Die E/A-Einheit 902 überträgt die dekodierten Befehle an verschiedene andere Einheiten der Parallelverarbeitungseinheit 920, wie es die Befehle vorgeben. So können beispielsweise einige Befehle an die Front-End-Einheit 904 übertragen werden. Andere Befehle können an den Hub 906 oder andere Einheiten der Parallelverarbeitungseinheit 920 übertragen werden, wie z. B. eine oder mehrere Copy-Engines, einen Video-Encoder, einen Video-Decoder, eine Einheit zur Verwaltung der Stromversorgung usw. (nicht explizit dargestellt). Mit anderen Worten, die E/A-Einheit 902 ist so konfiguriert, dass sie die Kommunikation zwischen und unter den verschiedenen logischen Einheiten der Parallelverarbeitungseinheit 920 leitet.
In einem Ausführungsbeispiel kodiert ein vom Host-Prozessor ausgeführtes Programm einen Befehlsstrom in einem Puffer, der der Parallelverarbeitungseinheit 920 Arbeitslasten zur Verarbeitung bereitstellt. Eine Arbeitslast kann mehrere Befehle und Daten umfassen, die von diesen Befehlen verarbeitet werden sollen. Der Puffer ist ein Bereich in einem Speicher, auf den sowohl der Host-Prozessor als auch die Parallelverarbeitungseinheit 920 zugreifen (z.B. lesen und schreiben) können. Beispielsweise kann die E/A-Einheit 902 so konfiguriert sein, dass sie über Speicheranforderungen, die über die Verbindung 918 übertragen werden, auf den Puffer in einem mit der Verbindung 918 verbundenen Systemspeicher zugreift. In einem Ausführungsbeispiel schreibt der Host-Prozessor den Befehlsstrom in den Puffer und überträgt dann einen Zeiger auf den Beginn des Befehlsstroms an die Parallelverarbeitungseinheit 920. Die Front-End-Einheit 904 empfängt Zeiger auf einen oder mehrere Befehlsströme. Die Front-End-Einheit 904 verwaltet den einen oder die mehreren Ströme, liest Befehle aus den Strömen und leitet Befehle an die verschiedenen Einheiten der Parallelverarbeitungseinheit 920 weiter.
Die Front-End-Einheit 904 ist mit einer Planer-Einheit 908 gekoppelt, die die verschiedenen Module des allgemeinen Verarbeitungsclusters 1000 für die Verarbeitung von Aufgaben konfiguriert, die durch den einen oder die mehreren Ströme definiert sind. Die Planereinheit 908 ist so konfiguriert, dass sie Zustandsinformationen in Bezug auf die verschiedenen, von der Planereinheit 908 verwalteten Aufgaben verfolgt. Der Zustand kann angeben, welchem allgemeinen Verarbeitungscluster 1000 eine Aufgabe zugewiesen ist, ob die Aufgabe aktiv oder inaktiv ist, welche Prioritätsstufe der Aufgabe assoziiert ist, usw. Die Planer-Einheit 908 verwaltet die Ausführung einer Vielzahl von Aufgaben auf dem einen oder mehreren allgemeinen Verarbeitungscluster 1000-Modulen.
Die Planereinheit 908 ist mit einer Arbeitsverteilungseinheit 910 gekoppelt, die so konfiguriert ist, dass sie Aufgaben zur Ausführung auf den allgemeinen Verarbeitungsclustermodulen 1000 versendet. Die Arbeitsverteilungseinheit 910 kann eine Anzahl von geplanten Aufgaben verfolgen, die von der Planereinheit 908 empfangen wurden. In einem Ausführungsbeispiel verwaltet die Arbeitsverteilungseinheit 910 einen Pool ausstehender Aufgaben und einen Pool aktiver Aufgaben für jedes der Module des allgemeinen Verarbeitungsclusters 1000. Der Pool ausstehender Aufgaben kann eine Anzahl von Slots (z.B. 32 Slots) umfassen, die Aufgaben enthalten, die zur Verarbeitung durch ein bestimmtes allgemeines Verarbeitungscluster 1000 zugewiesen sind. Der Pool aktiver Aufgaben kann eine Anzahl von Slots (z.B. 4 Slots) für Aufgaben umfassen, die von den Modulen des allgemeinen Verarbeitungsclusters 1000 aktiv bearbeitet werden. Wenn ein allgemeiner Verarbeitungscluster 1000 die Ausführung einer Aufgabe beendet, wird diese Aufgabe aus dem aktiven Aufgabenpool für den allgemeinen Verarbeitungscluster 1000 entfernt, und eine der anderen Aufgaben aus dem anstehenden Aufgabenpool wird ausgewählt und für die Ausführung auf dem allgemeinen Verarbeitungscluster 1000 eingeplant. Wenn eine aktive Aufgabe auf dem allgemeinen Verarbeitungscluster 1000 im Leerlauf war, z. B. während des Wartens auf die Auflösung einer Datenabhängigkeit, dann kann die aktive Aufgabe aus dem allgemeinen Verarbeitungscluster 1000 entfernt und in den Pool der ausstehenden Aufgaben zurückgeführt werden, während eine andere Aufgabe im Pool der ausstehenden Aufgaben ausgewählt und zur Ausführung auf dem allgemeinen Verarbeitungscluster 1000 eingeplant wird.
Die Arbeitsverteilungseinheit 910 kommuniziert mit dem einen oder mehreren Modulen des allgemeinen Verarbeitungsclusters 1000 über die Crossbar 914. Die Crossbar 914 ist ein Netzwerk, das viele der Einheiten der Parallelverarbeitungseinheit 920 mit anderen Einheiten der Parallelverarbeitungseinheit 920 koppelt. Die Crossbar 914 kann beispielsweise so konfiguriert sein, dass sie die Arbeitsverteilungseinheit 910 mit einem bestimmten allgemeinen Verarbeitungscluster 1000 koppelt. Obwohl nicht explizit dargestellt, können eine oder mehrere andere Einheiten der Parallelverarbeitungseinheit 920 auch über den Hub 906 mit der Crossbar 914 verbunden sein.
Die Aufgaben werden von der Verwaltereinheit 908 verwaltet und von der Arbeitsverteilungseinheit 910 an ein allgemeines Verarbeitungscluster 1000 verteilt. Der allgemeine Verarbeitungscluster 1000 ist so konfiguriert, dass er die Aufgabe verarbeitet und Ergebnisse generiert. Die Ergebnisse können von anderen Aufgaben innerhalb des allgemeinen Verarbeitungsclusters 1000 verbraucht, über die Crossbar 914 an ein anderes allgemeines Verarbeitungscluster 1000 weitergeleitet oder im Speicher 912 gespeichert werden. Die Ergebnisse können über die Module der Partitionseinheit 1100 in den Speicher 912 geschrieben werden, die eine Speicherschnittstelle zum Lesen und Schreiben von Daten in/aus dem Speicher 912 implementieren. Die Ergebnisse können über den NVLink 916 an eine andere Parallelverarbeitungseinheit 920 oder CPU übertragen werden. In einem Ausführungsbeispiel umfasst die Parallelverarbeitungseinheit 920 eine Anzahl U von Modulen der Speicherpartitionseinheit 1100, die der Anzahl von separaten und unterschiedlichen Geräten des Speichers 912 entspricht, die mit der Parallelverarbeitungseinheit 920 gekoppelt sind. Eine Speicherpartitionseinheit 1100 wird im Folgenden in Verbindung mit 11 detaillierter beschrieben.
In einem Ausführungsbeispiel führt ein Hostprozessor einen Treiberkern aus, der eine Anwendungsprogrammierschnittstelle (API) implementiert, die es einer oder mehreren auf dem Hostprozessor ausgeführten Applikationen ermöglicht, Operationen zur Ausführung auf der Parallelverarbeitungseinheit 920 zu planen. In einem Ausführungsbeispiel werden mehrere Rechenanwendungen gleichzeitig von der Parallelverarbeitungseinheit 920 ausgeführt, und die Parallelverarbeitungseinheit 920 bietet Isolierung, Dienstgüte (QoS) und unabhängige Adressräume für die mehreren Rechenanwendungen. Eine Applikation kann Anweisungen generieren (z.B. API-Aufrufe), die den Treiberkern veranlassen, eine oder mehrere Aufgaben zur Ausführung durch die Parallelverarbeitungseinheit 920 zu generieren. Der Treiberkern gibt Aufgaben an einen oder mehrere Ströme aus, die von der Parallelverarbeitungseinheit 920 verarbeitet werden. Jede Aufgabe kann eine oder mehrere Gruppen von zusammenhängenden Threads umfassen, die hier als Warp bezeichnet werden. In einem Ausführungsbeispiel umfasst ein Warp 32 zusammenhängende Threads, die parallel ausgeführt werden können. Kooperierende Threads können sich auf eine Vielzahl von Threads beziehen, die Anweisungen zur Ausführung der Aufgabe enthalten und Daten über gemeinsam genutzte Speicher austauschen können. Threads und kooperierende Threads werden in Verbindung mit 12 detaillierter beschrieben.
10 zeigt einen allgemeinen Verarbeitungscluster 1000 der Parallelverarbeitungseinheit 920 aus 9, gemäß einem Ausführungsbeispiel. Wie in 10 dargestellt, umfasst jeder allgemeine Verarbeitungscluster 1000 eine Anzahl von Hardwareeinheiten zur Verarbeitung von Aufgaben. In einem Ausführungsbeispiel umfasst jeder allgemeine Verarbeitungscluster 1000 einen Pipeline-Verwalter 1002, eine Einheit für Pre-Raster-Operationen 1004, eine Raster-Engine 1008, eine Crossbar 1014 zur Arbeitsverteilung, eine Speicherverwaltungseinheit 1016 und einen oder mehrere Datenverarbeitungscluster 1006. Es wird deutlich, dass der allgemeine Verarbeitungscluster 1000 von 10 andere Hardwareeinheiten anstelle der in 10 gezeigten Einheiten oder zusätzlich zu diesen enthalten kann.
In einem Ausführungsbeispiel wird die Operation des allgemeinen Verarbeitungsclusters 1000 durch den Pipeline-Verwalter 1002 gesteuert. Der Pipeline-Verwalter 1002 verwaltet die Konfiguration des einen oder der mehreren Datenverarbeitungscluster-Module 1006 zur Verarbeitung von Aufgaben, die dem allgemeinen Verarbeitungscluster 1000 zugewiesen sind. In einem Ausführungsbeispiel kann der Pipeline-Verwalter 1002 zumindest eines der ein oder mehreren Datenverarbeitungscluster 1006-Module so konfigurieren, dass es zumindest einen Teil einer Grafik-Rendering-Pipeline implementiert. Zum Beispiel kann ein Datenverarbeitungscluster 1006 so konfiguriert werden, dass er ein Vertex-Shader-Programm auf dem programmierbaren Streaming-Multiprozessor 1200 ausführt. Der Pipeline-Verwalter 1002 kann auch so konfiguriert sein, dass er von der Arbeitsverteilungseinheit 910 empfangene Pakete an die entsprechenden logischen Einheiten innerhalb des allgemeinen Verarbeitungsclusters 1000 weiterleitet. Beispielsweise können einige Pakete an Hardwareeinheiten mit fester Funktion in der Pre-Raster-Operations-Einheit 1004 und/oder der Raster-Engine 1008 weitergeleitet werden, während andere Pakete an die Module des Datenverarbeitungsclusters 1006 zur Verarbeitung durch die Primitiv-Engine 1012 oder den Streaming-Multiprozessor 1200 weitergeleitet werden können. In einem Ausführungsbeispiel kann der Pipeline-Verwalter 1002 zumindest eines der ein oder mehreren Datenverarbeitungscluster 1006-Module konfigurieren, um ein Modell eines neuronalen Netzwerks und/oder eine Rechen-Pipeline zu implementieren.
Die Pre-Raster-Operations-Einheit 1004 ist so konfiguriert, dass sie die von der Raster-Engine 1008 und den Datenverarbeitungscluster-Modulen 1006 generierten Daten an eine Raster-Operations-Einheit (ROP) weiterleitet, die in Verbindung mit 11 detaillierter beschrieben wird. Die Pre-Raster Operations-Einheit 1004 kann auch so konfiguriert sein, dass sie Optimierungen für die Farbmischung durchführt, Pixeldaten organisiert, Adressübersetzungen vornimmt und ähnliches.
Die Raster-Engine 1008 umfasst eine Reihe von Hardware-Einheiten mit fester Funktion, die zur Durchführung verschiedener Raster-Operationen konfiguriert sind. In einem Ausführungsbeispiel umfasst die Raster-Engine 1008 eine Setup-Engine, eine Grob-Raster-Engine, eine Culling-Engine, eine Clipping-Engine, eine Fein-Raster-Engine und eine Kachel-Koaleszenz-Engine. Die Setup-Engine empfängt transformierte Vertices und generiert Ebenengleichungen, die mit dem durch die Vertices definierten geometrischen Primitiv assoziiert sind. Die Ebenengleichungen werden an die Raster-Engine weitergeleitet, um Abdeckungsinformationen (z.B. eine x,y-Abdeckungsmaske für eine Kachel) für das Primitiv zu generieren. Die Ausgabe der groben Raster-Engine wird an die Culling-Engine weitergeleitet, wo die dem Primitiv zugeordneten Fragmente, die einen z-Test nicht bestehen, aussortiert werden, und an eine Clipping-Engine weitergeleitet, wo Fragmente, die außerhalb eines Sichtkegelstumpfes liegen, abgeschnitten werden. Diejenigen Fragmente, die das Clipping und Culling überstehen, können an die Fine-Raster-Engine weitergeleitet werden, um Attribute für die Pixelfragmente basierend auf den von der Setup-Engine generierten Ebenengleichungen zu generieren. Die Ausgabe der Raster-Engine 1008 umfasst Fragmente, die z. B. von einem Fragment-Shader verarbeitet werden, der in einem Datenverarbeitungscluster 1006 implementiert ist.
Jeder Datenverarbeitungscluster 1006, der in dem allgemeinen Verarbeitungscluster 1000 enthalten ist, umfasst einen M-Pipe-Controller 1010, eine Primitiv-Engine 1012 und ein oder mehrere Streaming-Multiprozessor 1200-Module. Der M-Pipe-Controller 1010 steuert die Operation des Datenverarbeitungsclusters 1006, indem er vom Pipeline-Verwalter 1002 empfangene Pakete an die entsprechenden Einheiten im Datenverarbeitungscluster 1006 weiterleitet. So können beispielsweise Pakete, die mit einem Vertex assoziiert sind, an die Primitiv-Engine 1012 weitergeleitet werden, die so konfiguriert ist, dass sie mit dem Vertex assoziierte Vertex-Attribute aus dem Speicher 912 abruft. Im Gegensatz dazu können Pakete, die mit einem Shader-Programm assoziiert sind, an den Streaming-Multiprozessor 1200 übertragen werden.
Der Streaming-Multiprozessor 1200 umfasst einen programmierbaren Streaming-Prozessor, der so konfiguriert ist, dass er Aufgaben verarbeitet, die durch eine Anzahl von Threads repräsentiert werden. Jeder Streaming-Multiprozessor 1200 ist multi-threaded und so konfiguriert, dass er eine Vielzahl von Threads (z.B. 32 Threads) aus einer bestimmten Gruppe von Threads gleichzeitig ausführt. In einem Ausführungsbeispiel implementiert der Streaming-Multiprozessor 1200 eine SIMD-Architektur (Single-Instruction, Multiple-Data), bei der jeder Thread in einer Gruppe von Threads (z.B. ein Warp) so konfiguriert ist, dass er basierend auf demselben Satz von Befehlen einen anderen Satz von Daten verarbeitet. Alle Threads in der Gruppe von Threads führen die gleichen Anweisungen aus. In einem anderen Ausführungsbeispiel implementiert der Streaming-Multiprozessor 1200 eine SIMT-Architektur (Single-Instruction, Multiple Thread), bei der jeder Thread in einer Gruppe von Threads so konfiguriert ist, dass er basierend auf demselben Satz von Befehlen einen anderen Datensatz verarbeitet, wobei jedoch individuelle Threads in der Gruppe von Threads während der Ausführung divergieren dürfen. In einem Ausführungsbeispiel werden ein Programmzähler, ein Aufrufstapel und ein Ausführungsstatus für jeden Warp beibehalten, was die Gleichzeitigkeit zwischen Warps und die serielle Ausführung innerhalb von Warps ermöglicht, wenn Threads innerhalb des Warps divergieren. In einem anderen Ausführungsbeispiel werden ein Programmzähler, ein Aufrufstapel und ein Ausführungsstatus für jeden individuellen Thread beibehalten, was eine gleiche Gleichzeitigkeit zwischen allen Threads innerhalb und zwischen Warps ermöglicht. Wenn der Ausführungsstatus für jeden individuellen Thread beibehalten wird, können Threads, die dieselben Anweisungen ausführen, zusammengeführt und parallel ausgeführt werden, um maximale Effizienz zu erzielen. Der Streaming-Multiprozessor 1200 wird im Folgenden in Verbindung mit 12 detaillierter beschrieben.
Die Speicherverwaltungseinheit 1016 stellt eine Schnittstelle zwischen dem allgemeinen Verarbeitungscluster 1000 und der Speicherpartitionseinheit 1100 bereit. Die Speicherverwaltungseinheit 1016 kann die Übersetzung virtueller Adressen in physikalische Adressen, den Speicherschutz und die Arbitrierung von Speicheranforderungen bereitstellen. In einem Ausführungsbeispiel stellt die Speicherverwaltungseinheit 1016 einen oder mehrere Translation-Lookaside-Puffer (TLBs) bereit, um die Übersetzung von virtuellen Adressen in physische Adressen im Speicher 912 durchzuführen.
Um eine energieeffiziente Kodierung für READ-Anforderungen zu ermöglichen, muss das System zunächst die Lücke zwischen Speicheranforderungen (z.B. DRAM) detektieren und dann die angeforderten Daten mit einem dünnbesetzten Code geeigneter Codelänge codieren. Nach dem Empfang der Daten muss die GPU die erwartete Länge des Codes ermitteln und ihn mit dem entsprechenden Dekodierer dekodieren.
In einem Ausführungsbeispiel antizipiert die Speichersteuerungs-/Speicherverwaltungseinheit 1016 Lücken zwischen Lesebefehlen und gibt basierend auf der zu verwendenden Kodierung verschiedene Lesebefehlstypen an. Die Konfiguration dieser Einheiten zur Signalisierung und Erkennung verschiedener Typen von READ- und WRITE-Befehlen kann jedoch zu einer unerwünschten Komplexität des Systems führen.
Zwischen der Ausgabe von READ/WRITE-Anforderungen an den Speicher und dem Zeitpunkt, zu dem die angeforderten Daten zurückgegeben (oder im Fall von WRITES gesendet) werden, besteht in der Regel eine Latenz (Verzögerung). In Systemen, in denen die READ-Latenz (RL) und die WRITE-Latenz viel größer (z.B. >=2X) sind als die Lückenintervalle, ist das Bestimmen der Lücke zum Zeitpunkt des Empfangs der nächsten READ/WRITE-Anforderung früh genug, um die erste Antwort ohne Leistungseinbußen zu kodieren.
Nachdem eine READ-Anforderung gesendet wurde, können sowohl die Speicherverwaltungseinheit 1016 als auch der Speicher, der das Ziel des READ-Befehls ist (z.B. in seiner Schnittstellen-/Steuerlogik), Zähler zurücksetzen, die die Anzahl der Zyklen zählen, bis der nächste READ- oder WRITE-Befehl gesendet und/oder empfangen wird. Da die Daten jedes READ-Befehls nach einer bestimmten Anzahl von Zyklen vom Array an die E/A-Schnittstelle des Speichers zurückgesendet werden, kann die zulässige Anzahl von Zyklen, die für die Übertragung dieser Daten verwendet werden können, verfolgt werden. Wenn die Anzahl solcher Zyklen zwischen READ-Befehlen das Einfügen eines dünnbesetzten Codes auf dem Datenbus ermöglicht, werden die zurückzugebenden Daten von der Speicher-E/A-Logik mit einem dünnbesetzten Code kodiert (oder einem von vielen Codes, so dass der längste Code, der kleiner oder gleich der Zielanzahl der Übertragungszyklen ist, verwendet wird). Die Speicherverwaltungseinheit 1016 akkumuliert basierend auf ihrer eigenen Verfolgung der Lückenlängen Daten über die Anzahl der Zyklen, die für den dünnbesetzten Code erforderlich sind, von dem sie bestimmt, dass die Speicher-E/A-Logik ihn auswählen wird, und dekodiert diese Daten mit dem entsprechenden Dekodierer. Ein Vorteil dieses Mechanismus ist, dass er keine zusätzlichen Befehle oder Pins erfordert.
In einem Ausführungsbeispiel (hier als „konservative Lückenerkennung“ bezeichnet) detektiert die Speicherschnittstellenlogik den Empfang eines WRITE-Befehls und verfolgt auch, ob eine vorkonfigurierte Anzahl von Buszyklen verstrichen ist, ohne dass ein READ- oder WRITE-Befehl empfangen wurde. Sie reagiert auf diese Ereignisse in der gleichen Weise, wie sie reagieren würde, wenn ein weiterer READ-Befehl ohne Lücke empfangen wird. Auf diese Weise wird verhindert, dass eine dünnbesetzte Kodierung von READ-Daten eine Verzögerung des Zeitpunkts veranlasst, zu dem WRITE-Daten auf dem Bus gesendet werden können, und die damit verbundene Latenzzeit.
In einem alternativen Ausführungsbeispiel (hier als „erschöpfende Lückenerkennung“ bezeichnet) kann das System so konfiguriert werden, dass WRITE-Befehle mit einem Buszyklusversatz relativ zu den zu schreibenden Daten gesendet werden. Dadurch werden die WRITE-Latenzzeit und die READ-Latenzzeit im System angeglichen. Daher kann jede detektierte Buslücke für die dünnbesetzte Kodierung ausgenutzt werden, ohne dass es zu einer zusätzlichen Verzögerung beim Senden der WRITE-Daten kommen kann.
Bei WRITE-Befehlen, die vom Prozessor gesendet werden, können sowohl die Speicherverwaltungseinheit 1016 als auch die Speicherschnittstellenlogik eine Anzahl von Buszyklen zählen, bis ein nächster WRITE- oder READ-Befehl gesendet oder empfangen wird. Die Daten, die jeden WRITE-Befehl begleiten, können vom Prozessor eine vorkonfigurierte Anzahl von Buszyklen nach dem WRITE-Befehl selbst gesendet werden. Auf diese Weise kann eine zulässige Anzahl von Buszyklen, die für die Übertragung der WRITE-Daten zur Verfügung stehen, nachverfolgt werden. Wenn eine Anzahl von Buszyklen zwischen WRITE-Befehlen die Verwendung eines dünnbesetzten Codes zulässt, kann der Prozessor die Daten als dünnbesetzten Code kodieren (ausgewählt aus einem von mehreren möglichen dünnbesetzten Codes, so dass ein längster dünnbesetzter Code verwendet wird, der kleiner oder gleich der verfügbaren Anzahl von Buszyklen ist). Basierend auf ihrer eigenen Verfolgung der Buslückenlängen zwischen WRITE-Befehlen kann die Speicherschnittstellenlogik Daten über die Anzahl der Zyklen akkumulieren, die von dem ausgewählten dünnbesetzten Code genutzt werden, den sie bestimmt, dass der Prozessor senden wird. Die Speicherschnittstellenlogik kann dann den geeigneten Dekodierer auswählen, um die WRITE-Daten zu dekodieren.
In Systemen, in denen die READ-Latenzzeit immer gleich oder länger als die WRITE-Latenzzeit ist, kann die Detektierung eines READ-Befehls nach einem WRITE-Befehl immer das Vorhandensein einer geeigneten Lückenlänge für dünnbesetzte Kodierung anzeigen.
Nachdem die aus dem Speicher gelesenen Daten an die seriellen Leitungstreiber weitergeleitet wurden, kann das System die Daten basierend auf der detektierten Lücke (falls vorhanden) in einen geeigneten MTA- oder dünnbesetzten Code kodieren, was eine gewisse Zeit in Anspruch nimmt. In Systemen, in denen die vorherrschende (häufigste) Lücke auf dem Datenbus ein Taktintervall ist, kann die Verwendung eines einzigen effizienten dünnbesetzten Kodierungsschemas, das für alle Lücken (unabhängig von ihrer Größe) geeignet ist, die meisten Vorteile gegenüber der Verwendung eines anspruchsvolleren dynamischen Kodierungsschemas bieten. In einem Ausführungsbeispiel ist dieses einzelne Kodierungsschema ein 4-Bit-zu-3-Symbol-Schema (mit jeweils drei Pegel), wie das in 5D dargestellte.
In einem Ausführungsbeispiel wendet das System MTA für lückenlose Anfragen und dünnbesetzte Kodierung für aufeinanderfolgende Anfragen mit Leerlaufintervallen an. Die zuvor beschriebene 4-Bit-zu-3-Symbol-Kodierung (5D) weist eine geringe Latenz auf, wobei die Rechenzeit mit der für MTA vergleichbar ist.
Bei der Ausgabe von aufeinanderfolgenden READ/WRITE-Anforderungen kann das System (z.B. eine GPU) die Zykluszahlen zwischen der Folge von READ/WRITE-Anforderungen verfolgen. Die Lücken zwischen den READ-Anforderungen ermöglichen es der GPU, das Kodierungsformat zu antizipieren, das der Kodierer verwenden wird, um Daten aus dem Speicher zurückzugeben. Die GPU dekodiert die empfangenen Daten entweder mit dem entsprechenden MTA-Decoder oder mit einem dünnbesetzten Dekodierer. Da der MTA Dekodierer eine vergleichbare Rechenzeit wie der Sparse Dekodierer hat, kann es sein, dass keine zusätzlichen Bandbreiten- und Latenzkosten anfallen.
In einem Ausführungsbeispiel wird die dünnbesetzte Kodierung initiiert, nachdem alle Daten empfangen wurden, die sich über Leerlaufzeiten in der Basislinie erstrecken. Mit anderen Worten, der Startzeitpunkt der dünnbesetzten Dekodierung wird um so viele Zyklen verschoben, wie die erweiterte Menge beträgt. Wenn der Burst nur um einen zusätzlichen Zyklus verlängert wird, kann der Leistungsverlust gering sein. WRITE-Daten werden ähnlich gehandhabt, wobei die GPU Schreibdaten basierend auf den Lücken kodiert und das System die Daten basierend auf den Lücken zwischen den Schreibbefehlen dekodiert.
Das System kann den Code auswählen, der am besten zu der Leerlaufzeit im Datenbus passt. Dies kann als variable Codespezifikation bezeichnet werden. Dieser multi-modale Kodierungsansatz kann mehr Energie einsparen, allerdings auf Kosten der Implementierung von mehr Schaltungsfläche für mehrere Dekodierer und Kodierer. Möglicherweise verbraucht er auch zusätzliche Energie beim Detektieren von Leerlaufzeiten und bei der Übersetzung von Daten.
Ein alternativer Ansatz besteht darin, nur eine dominante dünnbesetzte Kodierung zu unterstützen, die einen einfacheren Erkennungsmechanismus verwendet, um zu bestimmen, dass die Leerlaufperiode eine Bedingung für das vordefinierte dünnbesetzte Kodierungsschema erfüllt. Dies kann als statische Codespezifikation bezeichnet werden. Die statische Codespezifikation bietet nicht so viele Möglichkeiten zur Energiereduzierung wie die variable Codespezifikation, kann aber mit geringerem Schaltkreisflächenaufwand und geringerer logischer Komplexität implementiert werden.
Eine weitere Möglichkeit der Implementierung ist der Punkt, an dem das Leerlauferkennungsschema entscheidet, dass eine Lücke detektiert wurde. Eine Lösung besteht darin, alle aufeinanderfolgenden READ/WRITE-Anforderungen zu verfolgen und dann die Lücke zu bestimmen. Leider funktioniert dieses Schema in manchen Fällen nicht. In einem Szenario, in dem eine große Lücke zwischen zwei aufeinanderfolgenden READ-Anforderungen besteht, muss der Speicher die Daten für die erste Anforderung übertragen, noch bevor er die zweite Anforderung erhält. Um alle möglichen Leerlaufzeiten zu nutzen, kann daher ein auf Zählern basierender Mechanismus erforderlich sein, um alle vier READ- und WRITE-Kombinationen zu erfassen. Dies kann als erschöpfende Lückenerkennung bezeichnet werden. Ein alternativer Ansatz ist die konservative Lückenerkennung, bei der die aufeinanderfolgenden Anforderungen nur für einige Takte nach Eingang einer Anforderung verfolgt werden. Trifft innerhalb eines vordefinierten Erkennungszeitraums eine weitere Anforderung im Speicher ein, wird die Leerlaufzeit zur Energieeinsparung genutzt. Trifft keine weitere Anforderung ein, wird konservativ davon ausgegangen, dass es keine Lücke in den aktuellen Anforderungen gibt.
Dieser konservative Fall ist aufgrund des Latenzunterschieds zwischen READ und WRTTE erforderlich. Nach Erhalt einer READ-Anforderung weiß das System nicht, ob die nächste Anforderung READ oder WRITE ist. Daher verschiebt es seine Entscheidung, ob eine Leerlaufzeit vorliegt, bis zum erwarteten Zeitpunkt der Ausgabe einer WRITE-Anforderung. Dies lässt sich durchaus implementieren und ist der Mechanismus, der bei der umfassenden Lückenerkennung zum Einsatz kommt. Das konservative Ignorieren einer Lücke nach dem Erkennungszeitraum ist jedoch eine einfache und effektive Lösung. Durch die Kombination von variabler/statischer Codespezifikation und erschöpfender/konservativer Lückenerkennung gibt es vier Ansätze zur Integration dünnbesetzter Kodierung, deren Wahl von den Einschränkungen der jeweiligen Implementierung abhängt.
11 zeigt gemäß einem Ausführungsbeispiel eine Speicherpartitionseinheit 1100 der Parallelverarbeitungseinheit 920 von 9. Wie in 11 gezeigt, umfasst die Partitionseinheit 1100 eine Rasteroperationseinheit 1102, einen Level-2-Cache 1104 und eine Speicherschnittstelle 1106. Die Speicherschnittstelle 1106 ist mit dem Speicher 912 gekoppelt. Die Speicherschnittstelle 1106 kann 32-, 64-, 128-, 1024-Bit-Datenbusse oder Ähnliches für die Hochgeschwindigkeitsdatenübertragung implementieren. In einem Ausführungsbeispiel enthält die Parallelverarbeitungseinheit 920 U-Module der Speicherschnittstelle 1106, eine Speicherschnittstelle 1106 pro Paar von Modulen der Speicherpartitionseinheit 1100, wobei jedes Paar von Modulen der Speicherpartitionseinheit 1100 mit einem entsprechenden Gerät des Speichers 912 verbunden ist. Zum Beispiel kann die Parallelverarbeitungseinheit 920 mit bis zu Y Geräten des Speichers 912 verbunden sein, wie z. B. Speicherstapel mit hoher Bandbreite oder Grafikspeicher mit doppelter Datenrate, Version 5, synchroner dynamischer Direktzugriffsspeicher oder andere Arten von dauerhaftem Speicher.
In einem Ausführungsbeispiel implementiert die Speicherschnittstelle 1106 eine HBM2-Speicherschnittstelle, und Y entspricht der Hälfte von U. In einem Ausführungsbeispiel befinden sich die HBM2-Speicherstapel auf demselben physischen Gehäuse wie die Parallelverarbeitungseinheit 920, was im Vergleich zu herkömmlichen GDDR5-SDRAM-Systemen erhebliche Energie- und Flächeneinsparungen ermöglicht. In einem Ausführungsbeispiel umfasst jeder HBM2-Stapel vier Speicherchips und Y ist gleich 4, wobei der HBM2-Stapel zwei 128-Bit-Kanäle pro Chip für insgesamt 8 Kanäle und eine Datenbusbreite von 1024 Bit umfasst.
In einem Ausführungsbeispiel unterstützt der Speicher 912 den Single-Error Correcting Double-Error Detecting (SECDED) Error Correction Code (ECC) zum Schutz der Daten. ECC bietet eine höhere Zuverlässigkeit für Rechen-Applikationen, die empfindlich auf Datenbeschädigung reagieren. Zuverlässigkeit ist besonders wichtig in großen Cluster-Rechner-Umgebungen, in denen Module der Parallelverarbeitungseinheit 920 sehr große Datensätze verarbeiten und/oder Anwendungen über längere Zeiträume laufen.
In einem Ausführungsbeispiel implementiert die Parallelverarbeitungseinheit 920 eine Multi-Level-Speicherhierarchie. In einem Ausführungsbeispiel unterstützt die Partitionseinheit 1100 einen einheitlichen Speicher, um einen einzigen einheitlichen virtuellen Adressraum für den Speicher der CPU und der Parallelverarbeitungseinheit 920 bereitzustellen, was die gemeinsame Nutzung von Daten zwischen virtuellen Speichersystemen ermöglicht. In einem Ausführungsbeispiel wird die Häufigkeit von Zugriffen einer Parallelverarbeitungseinheit 920 auf Speicher an anderen Orten verfolgt, um sicherzustellen, dass Speicherseiten in den physischen Speicher der Parallelverarbeitungseinheit 920 verschoben werden, die häufiger auf die Seiten zugreift. In einem Ausführungsbeispiel unterstützt der NVLink 916 Adressübersetzungsdienste, die es der Parallelverarbeitungseinheit 920 ermöglichen, direkt auf die Seitentabellen einer CPU zuzugreifen und der Parallelverarbeitungseinheit 920 vollen Zugriff auf den CPU-Speicher zu gewähren.
In einem Ausführungsbeispiel übertragen Copy-Engines Daten zwischen mehreren Modulen der Parallelverarbeitungseinheit 920 oder zwischen Modulen der Parallelverarbeitungseinheit 920 und CPUs. Die Copy-Engines können Seitenfehler für Adressen generieren, die nicht in den Seitentabellen abgebildet sind. Die Partitionseinheit 1100 kann dann die Seitenfehler bearbeiten und die Adressen in der Seitentabelle abbilden, woraufhin die Kopier-Engine die Übertragung durchführen kann. In einem herkömmlichen System wird der Speicher für mehrere Operationen der Copy-Engine zwischen mehreren Prozessoren gepinnt (z.B. nicht auslagerbar), wodurch der verfügbare Speicher erheblich reduziert wird. Mit Hardware Page Faulting können Adressen an die Copy-Engines weitergegeben werden, ohne dass man sich darum kümmern muss, ob die Speicherseiten resident sind, und der Kopiervorgang ist transparent.
Daten aus dem Speicher 912 oder einem anderen Systemspeicher können von der Speicherpartitionseinheit 1100 abgerufen und im Level-2-Cache 1104 gespeichert werden, der sich auf dem Chip befindet und von den verschiedenen Modulen des allgemeinen Verarbeitungsclusters 1000 gemeinsam genutzt wird. Wie dargestellt, enthält jede Partitionseinheit 1100 einen Teil des Level-2-Cache 1104, der einem entsprechenden Gerät 912 zugeordnet ist. Caches der unteren Ebene können dann in verschiedenen Einheiten innerhalb der Module des allgemeinen Verarbeitungsclusters 1000 implementiert werden. Zum Beispiel kann jedes der Module des Streaming-Multiprozessors 1200 einen L1-Cache implementieren. Der L1-Cache ist ein privater Speicher, der für einen bestimmten Streaming-Multiprozessor 1200 bestimmt ist. Daten aus dem Level-2-Cache 1104 können in jedem der L1-Caches zur Verarbeitung in den Funktionseinheiten der Streaming-Multiprozessor 1200-Module abgerufen und gespeichert werden. Der Level Two Cache 1104 ist mit der Speicherschnittstelle 1106 und der Crossbar 914 gekoppelt.
Die Rasteroperationseinheit 1102 führt Grafikrasteroperationen durch, die sich auf die Pixelfarbe beziehen, wie z. B. Farbkompression, Pixelüberblendung und ähnliches. Die Rasteroperationseinheit 1102 implementiert auch eine Tiefenprüfung in Verbindung mit der Raster-Engine 1008, wobei sie eine Tiefe für einen Sample-Ort, der mit einem Pixelfragment assoziiert ist, von der Culling-Engine der Raster-Engine 1008 erhält. Die Tiefe wird mit einer entsprechenden Tiefe in einem Tiefenpuffer für einen mit dem Fragment assoziierten Sample-Ort verglichen. Wenn das Fragment den Tiefentest für den Ort des Samples besteht, aktualisiert die Rasteroperationseinheit 1102 den Tiefenpuffer und überträgt das Ergebnis des Tiefentests an die Raster-Engine 1008. Die Anzahl der Module der Partitionseinheit 1100 des Partitionsspeichers kann sich von der Anzahl der Module des allgemeinen Verarbeitungsclusters 1000 unterscheiden, so dass jede Rasteroperationseinheit 1102 mit jedem der Module des allgemeinen Verarbeitungsclusters 1000 gekoppelt sein kann. Die Rasteroperationseinheit 1102 verfolgt die von den verschiedenen Modulen des allgemeinen Verarbeitungsclusters 1000 empfangenen Pakete und bestimmt, zu welchem allgemeinen Verarbeitungscluster 1000 ein von der Rasteroperationseinheit 1102 generiertes Ergebnis über die Crossbar 914 weitergeleitet wird. Obwohl die Rasteroperationseinheit 1102 in 11 innerhalb der Speicherpartitionseinheit 1100 enthalten ist, kann sich die Rasteroperationseinheit 1102 in anderen Ausführungsbeispielen auch außerhalb der Speicherpartitionseinheit 1100 befinden. Zum Beispiel kann die Rasteroperationseinheit 1102 im allgemeinen Verarbeitungscluster 1000 oder einer anderen Einheit untergebracht sein.
12 zeigt den Streaming-Multiprozessor 1200 von 10, gemäß einem Ausführungsbeispiel. Wie in 12 gezeigt, umfasst der Streaming-Multiprozessor 1200 einen Befehls-Cache 1202, einen oder mehrere Planer-Einheiten 1204 (z.B. wie die Planer-Einheit 908), eine Registerdatei 1208, einen oder mehrere Verarbeitungskerne 1210, eine oder mehrere Sonderfunktionseinheiten 1212, eine oder mehrere Lade-/Speicher-Einheiten 1214, ein Verbindungsnetzwerk 1216 und einen gemeinsam genutzten Speicher/L1-Cache 1218.
Wie oben beschrieben, verteilt die Arbeitsverteilungseinheit 910 Aufgaben zur Ausführung auf den Modulen des allgemeinen Verarbeitungsclusters 1000 der Parallelverarbeitungseinheit 920. Die Aufgaben werden einem bestimmten Datenverarbeitungscluster 1006 innerhalb eines allgemeinen Verarbeitungsclusters 1000 zugewiesen, und wenn die Aufgabe mit einem Shader-Programm assoziiert ist, kann die Aufgabe einem Streaming-Multiprozessor 1200 zugewiesen werden. Der Planer 908 empfängt die Aufgaben von der Arbeitsverteilungseinheit 910 und verwaltet die Befehlsplanung für einen oder mehrere Thread-Blöcke, die dem Streaming-Multiprozessor 1200 zugewiesen sind. Die Planer-Einheit 1204 plant Thread-Blöcke für die Ausführung als Warps paralleler Threads, wobei jedem Thread-Block zumindest ein Warp zugewiesen wird. In einem Ausführungsbeispiel führt jeder Warp 32 Threads aus. Die Planer-Einheit 1204 kann eine Vielzahl verschiedener Thread-Blöcke verwalten, indem sie die Warps den verschiedenen Thread-Blöcken zuweist und dann Anweisungen aus der Vielzahl verschiedener kooperativer Gruppen an die verschiedenen Funktionseinheiten (z.B. Kern 1210-Module, spezielle Funktionseinheit 1212-Module und Lade-/Speichereinheit 1214-Module) während jedes Taktzyklus versendet.
Kooperative Gruppen sind ein Programmiermodell für die Organisation von Gruppen kommunizierender Threads, das es Entwicklern ermöglicht, die Granularität auszudrücken, mit der Threads kommunizieren, und so reichhaltigere, effizientere parallele Dekompositionen zu ermöglichen. Cooperative Launch APIs unterstützen die Synchronisation zwischen Thread-Blöcken für die Ausführung paralleler Algorithmen. Konventionelle Programmiermodelle bieten ein einziges, einfaches Konstrukt für die Synchronisation kooperierender Threads: eine Barriere über alle Threads eines Thread-Blocks (z.B. die Funktion syncthreads( )). Programmierer möchten jedoch oft Gruppen von Threads mit einer kleineren Granularität als der eines Thread-Blocks definieren und innerhalb der definierten Gruppen synchronisieren, um eine höhere Leistung, Design-Flexibilität und Software-Wiederverwendung in Form von gemeinsamen gruppenweiten Funktionsschnittstellen zu ermöglichen.
Kooperative Gruppen ermöglichen es Programmierern, Gruppen von Threads explizit auf Sub-Block- (z.B. so klein wie ein einzelner Thread) und Multi-Block-Granularität zu definieren und kollektive Operationen wie Synchronisation auf den Threads in einer kooperativen Gruppe durchzuführen. Das Programmiermodell unterstützt eine saubere Komposition über Softwaregrenzen hinweg, so dass Bibliotheken und Dienstprogramme innerhalb ihres lokalen Kontexts sicher synchronisieren können, ohne dass Annahmen über Konvergenz getroffen werden müssen. Die Primitive für kooperative Gruppen ermöglichen neue Muster kooperativer Parallelität, einschließlich Produzent-Verbraucher-Parallelität, opportunistischer Parallelität und globaler Synchronisation über ein ganzes Netz von Thread-Blöcken.
Eine Sendeeinheit 1206 ist innerhalb der Planer-Einheit 1204 konfiguriert, um Anweisungen an eine oder mehrere der Funktionseinheiten zu übertragen. In einem Ausführungsbeispiel umfasst die Planer-Einheit 1204 zwei Sendeeinheiten 1206, die es ermöglichen, dass zwei verschiedene Anweisungen aus demselben Warp während jedes Taktzyklus versendet werden. In alternativen Ausführungsbeispielen kann jede Planer-Einheit 1204 eine einzelne Sendeeinheit 1206 oder zusätzliche Sendeeinheiten 1206 enthalten.
Jeder Streaming-Multiprozessor 1200 enthält eine Registerdatei 1208, die einen Satz von Registern für die Funktionseinheiten des Streaming-Multiprozessors 1200 bereitstellt. In einem Ausführungsbeispiel wird die Registerdatei 1208 zwischen den einzelnen Funktionseinheiten aufgeteilt, so dass jeder Funktionseinheit ein eigener Teil der Registerdatei 1208 zugewiesen wird. In einem anderen Ausführungsbeispiel ist die Registerdatei 1208 auf die verschiedenen Warps aufgeteilt, die vom Streaming-Multiprozessor 1200 ausgeführt werden. Die Registerdatei 1208 dient als temporärer Speicher für Operanden, die mit den Datenpfaden der Funktionseinheiten verbunden sind.
Jeder Streaming-Multiprozessor 1200 umfasst L Module des Verarbeitungskerns 1210. In einem Ausführungsbeispiel umfasst der Streaming-Multiprozessor 1200 eine große Anzahl (z.B. 128 usw.) von verschiedenen Verarbeitungskernen 1210-Modulen. Jeder Kern 1210 kann eine Voll-Pipeline-, Einzelpräzisions-, Doppelpräzisions- und/oder gemischte Präzisionsverarbeitungseinheit enthalten, die eine Gleitkomma-Arithmetik-Logikeinheit und eine Ganzzahl-Arithmetik-Logikeinheit umfasst. In einem Ausführungsbeispiel implementieren die arithmetischen Gleitkomma-Logikeinheiten den Standard IEEE 754-2008 für Gleitkomma-Arithmetik. In einem Ausführungsbeispiel umfassen die Module des Kerns 1210 64 Gleitkomma-Kerne mit einfacher Genauigkeit (32 Bit), 64 Ganzzahl-Kerne, 32 Gleitkomma-Kerne mit doppelter Genauigkeit (64 Bit) und 8 Tensor-Kerne.
Tensorkerne, die zur Durchführung von Matrixoperationen konfiguriert sind, und in einem Ausführungsbeispiel sind ein oder mehrere Tensorkerne in den Kern 1210-Modulen enthalten. Insbesondere sind die Tensorkerne so konfiguriert, dass sie Deep-Learning-Matrixarithmetik durchführen, wie z. B. Faltungsoperationen für das Trainieren und Inferieren von neuronalen Netzwerken. In einem Ausführungsbeispiel arbeitet jeder Tensorkern mit einer 4x4-Matrix und führt eine Matrixmultiplikations- und Akkumulationsoperation D=A'B+C durch, wobei A, B, C und D 4x4-Matrizen sind.
In einem Ausführungsbeispiel sind die Eingaben für die Matrixmultiplikation A und B 16-Bit-Gleitkommamatrizen, während die Akkumulationsmatrizen C und D 16-Bit-Gleitkomma- oder 32-Bit-Gleitkommamatrizen sein können. Tensor-Kerne operieren mit 16-Bit-Gleitkomma-Eingabedaten und 32-Bit-Gleitkomma-Akkumulation. Die 16-Bit-Gleitkommamultiplikation erfordert 64 Operationen und führt zu einem Produkt mit voller Genauigkeit, das dann unter Verwendung von 32-Bit-Gleitkommaaddition mit den anderen Zwischenprodukten zu einer 4x4x4-Matrixmultiplikation akkumuliert wird. In der Praxis werden Tensor-Kerne verwendet, um viel größere zweidimensionale oder höherdimensionale Matrixoperationen durchzuführen, die aus diesen kleineren Elementen aufgebaut sind. Eine API, wie die CUDA 9C++ API, stellt spezialisierte Operationen zum Laden, Multiplizieren und Akkumulieren von Matrizen und zum Speichern von Matrizen zur Verfügung, um Tensor Cores in einem CUDA-C++ Programm effizient zu verwenden. Auf der CUDA-Ebene geht die Schnittstelle auf Warp-Ebene von Matrizen der Größe 16x16 aus, die sich über alle 32 Threads des Warp erstrecken.
Jeder Streaming-Multiprozessor 1200 umfasst auch Module der M-Sonderfunktionseinheit 1212, die spezielle Funktionen ausführen (z.B. Attributauswertung, reziproke Quadratwurzel und dergleichen). In einem Ausführungsbeispiel können die Module der Sonderfunktionseinheit 1212 eine Baum-Traversal-Einheit umfassen, die so konfiguriert ist, dass sie eine hierarchische Baumdatenstruktur durchläuft. In einem Ausführungsbeispiel können die Module der Sonderfunktionseinheit 1212 eine Textureinheit enthalten, die so konfiguriert ist, dass sie Operationen zur Filterung von Texturkarten durchführt. In einem Ausführungsbeispiel sind die Textureinheiten so konfiguriert, dass sie Texturkarten (z.B. ein 2D-Array von Texeln) aus dem Speicher 912 laden und die Texturkarten samplen, um gesampelte Texturwerte zur Verwendung in Shader-Programmen zu erzeugen, die vom Streaming-Multiprozessor 1200 ausgeführt werden. In einem Ausführungsbeispiel werden die Texturkarten im gemeinsam genutzten Speicher/L1-Cache 1218 gespeichert. Die Textureinheiten implementieren Texturoperationen wie z.B. Filteroperationen unter Verwendung von Mip-Maps (z.B. Texturkarten mit unterschiedlichem Detaillierungsgrad). In einem Ausführungsbeispiel umfasst jeder Streaming-Multiprozessor 1200 zwei Textureinheiten.
Jeder Streaming-Multiprozessor 1200 umfasst auch N Module der Lade-/Speichereinheit 1214, die Lade- und Speicheroperationen zwischen dem gemeinsam genutzten Speicher/L1-Cache 1218 und der Registerdatei 1208 implementieren. Jeder Streaming-Multiprozessor 1200 umfasst ein Netzwerk 1216, das jede der Funktionseinheiten mit der Registerdatei 1208 und die Lade-/Speichereinheit 1214 mit der Registerdatei 1208 und dem gemeinsam genutzten Speicher/L1-Cache 1218 verbindet. In einem Ausführungsbeispiel ist das Netzwerk 1216 eine Crossbar, die so konfiguriert werden kann, dass sie jede der Funktionseinheiten mit jedem der Register in der Registerdatei 1208 verbindet und die Module der Lade-/Speichereinheit 1214 mit der Registerdatei 1208 und Speicherorten im gemeinsam genutzten Speicher/L1-Cache 1218 verbindet.
Der gemeinsam genutzte Speicher/L1-Cache 1218 ist ein Array von On-Chip-Speicher, der die Datenspeicherung und Kommunikation zwischen dem Streaming-Multiprozessor 1200 und der Primitiv-Engine 1012 sowie zwischen Threads im Streaming-Multiprozessor 1200 ermöglicht. In einem Ausführungsbeispiel umfasst der gemeinsam genutzte Speicher/L1-Cache 1218 eine Speicherkapazität von 128 KB und befindet sich auf dem Pfad vom Streaming-Multiprozessor 1200 zur Partitionseinheit des Speichers 1100. Der gemeinsam genutzte Speicher/L1-Cache 1218 kann zum Cachen von Lese- und Schreibvorgängen verwendet werden. Einer oder mehrere der gemeinsam genutzten Speicher/L1-Cachespeicher 1218, der Level-Zwei-Cachespeicher 1104 und der Speicher 912 sind Backing-Stores.
Die Kombination von Daten-Cache und gemeinsam genutzter Speicherfunktionalität in einem einzigen Speicherblock bietet die beste Gesamtleistung für beide Arten von Speicherzugriffen. Die Kapazität kann von Programmen, die den gemeinsam genutzten Speicher nicht verwenden, als Cache genutzt werden. Wenn der gemeinsam genutzte Speicher beispielsweise so konfiguriert ist, dass die Hälfte der Kapazität verwendet wird, können Textur- und Lade-/Speicheroperationen die verbleibende Kapazität verwenden. Die Integration in den gemeinsam genutzten Speicher/L1-Cache 1218 ermöglicht es dem gemeinsam genutzten Speicher/L1-Cache 1218, als durchsatzstarke Leitung für Stromdaten zu fungieren und gleichzeitig den Zugriff auf häufig wiederverwendete Daten mit hoher Bandbreite und niedriger Latenz zu ermöglichen.
Bei der Konfiguration für allgemeines paralleles Rechnen kann im Vergleich zur Grafikverarbeitung eine einfachere Konfiguration verwendet werden. Insbesondere werden die in 9 gezeigten Grafikverarbeitungseinheiten mit fester Funktion umgangen, wodurch ein viel einfacheres Programmiermodell entsteht. In der Konfiguration für parallele Berechnungen mit allgemeinem Zweck weist die Arbeitsverteilungseinheit 910 Blöcke von Threads zu und verteilt sie direkt an die Module des Datenverarbeitungsclusters 1006. Die Threads in einem Block führen dasselbe Programm aus, wobei eine eindeutige Thread-ID in der Berechnung verwendet wird, um sicherzustellen, dass jeder Thread eindeutige Ergebnisse generiert, wobei der Streaming-Multiprozessor 1200 zur Ausführung des Programms und zur Durchführung von Berechnungen, der gemeinsam genutzte Speicher/L1-Cache 1218 zur Kommunikation zwischen den Threads und die Lade-/Speichereinheit 1214 zum Lesen und Schreiben des globalen Speichers über den gemeinsam genutzten Speicher/L1-Cache 1218 und die Speicherpartitionseinheit 1100 verwendet werden. Wenn der Streaming-Multiprozessor 1200 für allgemeines paralleles Berechnen konfiguriert ist, kann er auch Befehle schreiben, die der Planer 908 verwenden kann, um neue Arbeiten an den Modulen des Datenverarbeitungsclusters 1006 zu starten.
Die Parallelverarbeitungseinheit 920 kann in einem Desktop-Computer, einem Laptop-Computer, einem Tablet-Computer, Servern, Supercomputern, einem Smartphone (z.B. einem drahtlosen, handgehaltenen Gerät), einem persönlichen digitalen Assistenten (PDA), einer Digitalkamera, einem Fahrzeug, einem Head Mounted Display, einem handgehaltenen elektronischen Gerät und dergleichen enthalten sein. In einem Ausführungsbeispiel ist die Parallelverarbeitungseinheit 920 auf einem einzigen Halbleitersubstrat untergebracht. In einem anderen Ausführungsbeispiel ist die Parallelverarbeitungseinheit 920 in einem System-on-a-Chip (SoC) zusammen mit einem oder mehreren anderen Geräten wie zusätzlichen Modulen der Parallelverarbeitungseinheit 920, dem Speicher 912, einer RISC-CPU (Reduced Instruction Set Computer), einer Speicherverwaltungseinheit (MMU), einem Digital-Analog-Wandler (DAC) und dergleichen enthalten.
In einem Ausführungsbeispiel kann die Parallelverarbeitungseinheit 920 auf einer Grafikkarte enthalten sein, die ein oder mehrere Speichergeräte enthält. Die Grafikkarte kann so konfiguriert sein, dass sie mit einem PCIe-Steckplatz auf einer Hauptplatine eines Desktop-Rechners verbunden werden kann. In einem weiteren Ausführungsbeispiel kann die Parallelverarbeitungseinheit 920 eine integrierte Grafikverarbeitungseinheit (iGPU) oder ein Parallelprozessor sein, der in den Chipsatz der Hauptplatine integriert ist.
Beispielhaftes Rechensystem
Systeme mit mehreren GPUs und CPUs werden in einer Vielzahl von Branchen verwendet, da Entwickler mehr Parallelität in Anwendungen wie dem Rechnen mit künstlicher Intelligenz aufdecken und nutzen. Leistungsstarke GPU-beschleunigte Systeme mit zehn bis vielen Tausenden von Rechenknoten werden in Datenzentren, Forschungsanlagen und Supercomputern eingesetzt, um immer größere Probleme zu lösen. Da die Anzahl der verarbeitenden Geräte innerhalb der Hochleistungssysteme steigt, müssen die Kommunikations- und Datenübertragungsmechanismen skaliert werden, um die erhöhte Bandbreite zu unterstützen.
13 ist ein konzeptionelles Diagramm eines Verarbeitungssystems 1300, das die Parallelverarbeitungseinheit 920 aus 9 verwendet, gemäß einem Ausführungsbeispiel. Das Verarbeitungssystem 1300 umfasst eine zentrale Verarbeitungseinheit 1306, einen Switch 1304 und mehrere Module der Parallelverarbeitungseinheit 920 sowie entsprechende Speichermodule 912. Der NVLink 916 stellt Hochgeschwindigkeitskommunikationsverbindungen zwischen den einzelnen Modulen der Parallelverarbeitungseinheit 920 bereit. Obwohl in 13 eine bestimmte Anzahl von NVLink 916- und Interconnect 918-Verbindungen dargestellt ist, kann die Anzahl der Verbindungen zu jeder Parallelverarbeitungseinheit 920 und der zentralen Verarbeitungseinheit 1306 variieren. Der Switch 1304 bildet die Schnittstelle zwischen der Verbindung 918 und der zentralen Verarbeitungseinheit 1306. Die Module der Parallelverarbeitungseinheit 920, die Speichermodule 912 und die NVLink-Verbindungen 916 können auf einer einzigen Halbleiterplattform angeordnet sein, um ein Parallelverarbeitungsmodul 1302 zu bilden. In einem Ausführungsbeispiel unterstützt der Switch 1304 zwei oder mehr Protokolle, um zwischen verschiedenen Verbindungen und/oder Links zu vermitteln.
In einem anderen Ausführungsbeispiel (nicht dargestellt) stellt der NVLink 916 eine oder mehrere Hochgeschwindigkeits-Kommunikationsverbindungen zwischen jedem der Module der Parallelverarbeitungseinheit (Parallelverarbeitungseinheit 920, Parallelverarbeitungseinheit 920, Parallelverarbeitungseinheit 920 und Parallelverarbeitungseinheit 920) bereit, und der Switch 1304 bildet eine Schnittstelle zwischen der Verbindung 918 und jedem der Module der Parallelverarbeitungseinheit. Die Module der Parallelverarbeitungseinheit, die Module des Speichers 912 und die Verbindung 918 können auf einer einzigen Halbleiterplattform angeordnet sein, um ein Parallelverarbeitungsmodul 1302 zu bilden. In einem weiteren Ausführungsbeispiel (nicht gezeigt) stellt die Verbindung 918 eine oder mehrere Kommunikationsverbindungen zwischen jedem der Module der Parallelverarbeitungseinheit und der zentralen Verarbeitungseinheit 1306 bereit, und der Switch 1304 bildet eine Schnittstelle zwischen jedem der Module der Parallelverarbeitungseinheit unter Verwendung des NVLink 916, um eine oder mehrere Hochgeschwindigkeitskommunikationsverbindungen zwischen den Modulen der Parallelverarbeitungseinheit bereitzustellen. In einem anderen Ausführungsbeispiel (nicht gezeigt) stellt der NVLink 916 eine oder mehrere Hochgeschwindigkeits-Kommunikationsverbindungen zwischen den Modulen der Parallelverarbeitungseinheit und der Zentraleinheit 1306 über den Switch 1304 bereit. In einem weiteren Ausführungsbeispiel (nicht gezeigt) stellt die Verbindung 918 eine oder mehrere Kommunikationsverbindungen zwischen den einzelnen Modulen der Parallelverarbeitungseinheit direkt her. Eine oder mehrere der NVLink 916-Hochgeschwindigkeits-Kommunikationsverbindungen können als physische NVLink-Verbindung oder entweder als On-Chip- oder On-Die-Verbindung implementiert werden, die das gleiche Protokoll wie NVLink 916 verwendet.
Im Zusammenhang mit der vorliegenden Beschreibung kann sich eine einzelne Halbleiterplattform auf eine einzige einheitliche integrierte Schaltung auf Halbleiterbasis beziehen, die auf einem Die oder Chip hergestellt wird. Es sei darauf hingewiesen, dass sich der Begriff Einzelhalbleiterplattform auch auf multi-Chip-Module mit erhöhter Konnektivität beziehen kann, die eine Operation auf dem Chip simulieren und wesentliche Verbesserungen gegenüber der Verwendung einer herkömmlichen Bus-Implementierung bieten. Natürlich können die verschiedenen Schaltungen oder Geräte auch separat oder in verschiedenen Kombinationen von Halbleiterplattformen untergebracht werden, je nach den Wünschen des Benutzers. Alternativ dazu kann das Parallelverarbeitungsmodul 1302 als Leiterplattensubstrat implementiert werden, und jedes der Module der Parallelverarbeitungseinheit und/oder des Speichers 912 kann ein gehäustes Gerät sein. In einem Ausführungsbeispiel befinden sich die zentrale Verarbeitungseinheit 1306, der Switch 1304 und das Parallelverarbeitungsmodul 1302 auf einer einzigen Halbleiterplattform.
In einem Ausführungsbeispiel beträgt die Signalisierungsrate jedes NVLink 916 20 bis 25 Gigabit/Sekunde, und jedes Modul der Parallelverarbeitungseinheit umfasst sechs NVLink 916-Schnittstellen (wie in 13 gezeigt, sind fünf NVLink 916-Schnittstellen für jedes Modul der Parallelverarbeitungseinheit enthalten). Jeder NVLink 916 bietet eine Datenübertragungsrate von 25 Gigabyte/Sekunde in jeder Richtung, wobei sechs Verbindungen 300 Gigabyte/Sekunde liefern. Der NVLink 916 kann ausschließlich für die PPU-zu-PPU-Kommunikation verwendet werden, wie in 13 gezeigt, oder für eine Kombination von PPU-zu-PPU und PPU-zu-CPU, wenn die Zentraleinheit 1306 auch eine oder mehrere NVLink 916-Schnittstellen enthält.
In einem Ausführungsbeispiel ermöglicht der NVLink 916 einen direkten Laden/Speichern/atomaren Zugriff von der zentralen Verarbeitungseinheit 1306 auf den Speicher 912 jedes Moduls der Parallelverarbeitungseinheit. In einem Ausführungsbeispiel unterstützt der NVLink 916 Kohärenzoperationen, die es ermöglichen, dass aus den Modulen des Speichers 912 gelesene Daten in der Cache-Hierarchie der zentralen Verarbeitungseinheit 1306 gespeichert werden, wodurch die Cache-Zugriffslatenz für die zentrale Verarbeitungseinheit 1306 verringert wird. In einem Ausführungsbeispiel umfasst der NVLink 916 die Unterstützung von Adressübersetzungsdiensten (ATS), die es dem Modul der Parallelverarbeitungseinheit ermöglichen, direkt auf Seitentabellen innerhalb der Zentraleinheit 1306 zuzugreifen. Einer oder mehrere der NVLink 916 können auch so konfiguriert werden, dass sie in einem stromsparenden Modus arbeiten.
14 zeigt ein beispielhaftes Verarbeitungssystem 1400, in dem die verschiedenen Architekturen und/oder Funktionen der verschiedenen vorherigen Ausführungsbeispiele implementiert werden können. Wie dargestellt, ist ein beispielhaftes Verarbeitungssystem 1400 vorgesehen, das zumindest eine zentrale Verarbeitungseinheit 1306 enthält, die mit einem Kommunikationsbus 1410 verbunden ist. Der Kommunikationsbus 1410 kann unter Verwendung eines beliebigen geeigneten Protokolls implementiert werden, wie z. B. PCI (Peripheral Component Interconnect), PCI-Express, AGP (Accelerated Graphics Port), HyperTransport oder ein anderes Bus- oder Punkt-zu-Punkt-Kommunikationsprotokoll bzw. andere Protokolle. Das beispielhafte Verarbeitungssystem 1400 umfasst auch einen Hauptspeicher 1402. Steuerlogik (Software) und Daten werden im Hauptspeicher 1402 gespeichert, der die Form eines Direktzugriffsspeichers (RAM) annehmen kann.
Das beispielhafte Verarbeitungssystem 1400 umfasst auch Eingabegeräte 1408, das Parallelverarbeitungsmodul 1302 und Anzeigegeräte 1406, z.B. eine herkömmliche CRT (Kathodenstrahlröhre), LCD (Flüssigkristallanzeige), LED (lichtemittierende Diode), Plasmabildschirm oder dergleichen. Benutzereingaben können über die Eingabegeräte 1408, z.B. Tastatur, Maus, Touchpad, Mikrofon usw., erfolgen. Jedes der vorgenannten Module und/oder Geräte kann sogar auf einer einzigen Halbleiterplattform angeordnet sein, um das beispielhafte Verarbeitungssystem 1400 zu bilden. Alternativ können die verschiedenen Module auch separat oder in verschiedenen Kombinationen von Halbleiterplattformen angeordnet sein, je nach den Wünschen des Benutzers.
Weiter kann das beispielhafte Verarbeitungssystem 1400 über eine Netzwerkschnittstelle 1404 zu Kommunikationszwecken an ein Netzwerk (z.B. ein Telekommunikationsnetzwerk, ein lokales Netzwerk (LAN), ein drahtloses Netzwerk, ein Weitverkehrsnetzwerk (WAN) wie das Internet, ein Peer-to-Peer-Netzwerk, ein Kabelnetzwerk oder ähnliches) gekoppelt sein.
Das beispielhafte Verarbeitungssystem 1400 kann auch einen Sekundärspeicher (nicht dargestellt) enthalten. Der Sekundärspeicher umfasst beispielsweise ein Festplattenlaufwerk und/oder ein Wechselspeicherlaufwerk, das ein Diskettenlaufwerk, ein Magnetbandlaufwerk, ein Compact-Disk-Laufwerk, ein DVD-Laufwerk (Digital Versatile Disk), ein Aufzeichnungsgerät oder einen USB-Flash-Speicher (Universal Serial Bus) repräsentiert. Das Wechselspeicherlaufwerk liest von einem Wechselspeicher und/oder schreibt auf einen Wechselspeicher in bekannter Weise.
Im Hauptspeicher 1402 und/oder im Sekundärspeicher können Computerprogramme oder logische Algorithmen zur Computersteuerung gespeichert sein. Solche Rechnerprogramme, wenn sie ausgeführt werden, ermöglichen dem beispielhaften Rechnersystem 1400, verschiedene Funktionen auszuführen. Der Hauptspeicher 1402, der Speicher und/oder jeder andere Speicher sind mögliche Beispiele für computerlesbare Medien.
Die Architektur und/oder Funktionalität der verschiedenen vorangegangenen Figuren kann im Rahmen eines allgemeinen Rechnersystems, eines Leiterplattensystems, eines für Unterhaltungszwecke bestimmten Spielkonsolensystems, eines anwendungsspezifischen Systems und/oder eines beliebigen anderen gewünschten Systems implementiert werden. Zum Beispiel kann das beispielhafte Rechnersystem 1400 die Form eines Desktop-Computers, eines Laptop-Computers, eines Tablet-Computers, eines Servers, eines Supercomputers, eines Smartphones (z.B. eines drahtlosen, handgehaltenen Geräts), eines persönlichen digitalen Assistenten (PDA), einer Digitalkamera, eines Fahrzeugs, eines Head Mounted Display, eines handgehaltenen elektronischen Geräts, eines Mobiltelefongeräts, eines Fernsehers, einer Workstation, von Spielkonsolen, eines eingebetteten Systems und/oder jeder anderen Art von Logik annehmen.
Obwohl oben verschiedene Ausführungsbeispiele beschrieben wurden, sollten diese nur als Beispiel und nicht als Einschränkung verstanden werden. Daher sollte die Breite und der Umfang einer bevorzugten Ausführungsform nicht durch eines der oben beschriebenen Ausführungsbeispiele begrenzt werden, sondern nur gemäß den folgenden Ansprüchen und deren Äquivalenten definiert werden.
Grafikverarbeitungs-Pipeline
15 ist ein konzeptionelles Diagramm einer Grafikverarbeitungs-Pipeline 1500, die durch die Parallelverarbeitungseinheit 920 von 9 implementiert wird, gemäß einem Ausführungsbeispiel. In einem Ausführungsbeispiel umfasst die Parallelverarbeitungseinheit 920 eine Grafikverarbeitungseinheit (GPU). Die Parallelverarbeitungseinheit 920 ist so konfiguriert, dass sie Befehle empfängt, die Shader-Programme zur Verarbeitung von Grafikdaten angeben. Grafikdaten können als ein Satz von Primitiven wie Punkte, Linien, Dreiecke, Quads, Dreiecksstreifen und dergleichen definiert werden. Typischerweise enthält ein Primitiv Daten, die eine Anzahl von Vertices für das Primitiv (z.B. in einem Modell-Raum-Koordinatensystem) sowie Attribute, die mit jedem Vertex des Primitivs assoziiert sind, spezifizieren. Die Parallelverarbeitungseinheit 920 kann so konfiguriert werden, dass sie die Grafikprimitive verarbeitet, um einen Bildpuffer zu generieren (z.B. Pixeldaten für jedes der Pixel der Anzeige).
Eine Applikation schreibt Modelldaten für eine Szene (z.B. eine Sammlung von Vertices und Attributen) in einen Speicher wie z.B. einen Systemspeicher oder Speicher 912. Die Modelldaten definieren jedes der Objekte, die auf einer Anzeige sichtbar sein können. Die Applikation führt dann einen API-Aufruf an den Treiberkern durch, der die zu rendernden und darzustellenden Modelldaten anfordert. Der Treiberkern liest die Modelldaten und schreibt Befehle in einen oder mehrere Ströme, um Operationen zur Verarbeitung der Modelldaten durchzuführen. Die Befehle können auf verschiedene Shader-Programme verweisen, die auf den Modulen des Streaming-Multiprozessors 1200 der Parallelverarbeitungseinheit 920 zu implementieren sind, darunter ein oder mehrere Vertex-Shader, Hull-Shader, Domain-Shader, Geometrie-Shader und ein Pixel-Shader. Beispielsweise kann eines oder mehrere der Streaming-Multiprozessor 1200-Module so konfiguriert sein, dass sie ein Vertex-Shader-Programm ausführen, das eine durch die Modelldaten definierte Anzahl von Vertices verarbeitet. In einem Ausführungsbeispiel können die verschiedenen Streaming-Multiprozessor 1200-Module so konfiguriert sein, dass sie verschiedene Shader-Programme gleichzeitig ausführen. So kann beispielsweise eine erste Teilmenge von Streaming-Multiprozessor 1200-Modulen so konfiguriert sein, dass sie ein Vertex-Shader-Programm ausführt, während eine zweite Teilmenge von Streaming-Multiprozessor 1200-Modulen so konfiguriert sein kann, dass sie ein Pixel-Shader-Programm ausführt. Der erste Teilsatz von Streaming-Multiprozessor 1200-Modulen verarbeitet Vertex-Daten, um verarbeitete Vertex-Daten zu erzeugen, und schreibt die verarbeiteten Vertex-Daten in den Level-2-Cache 1104 und/oder in den Speicher 912. Nachdem die verarbeiteten Vertex-Daten gerastert (z.B. von dreidimensionalen Daten in zweidimensionale Daten im Bildschirmraum umgewandelt) wurden, um Fragmentdaten zu erzeugen, führt der zweite Teilsatz von Streaming-Multiprozessor 1200-Modulen einen Pixel-Shader aus, um verarbeitete Fragmentdaten zu erzeugen, die dann mit anderen verarbeiteten Fragmentdaten gemischt und in den Frame-Puffer im Speicher 912 geschrieben werden. Das Vertex-Shader-Programm und das Pixel-Shader-Programm können gleichzeitig ausgeführt werden, wobei verschiedene Daten aus derselben Szene in einer Pipeline verarbeitet werden, bis alle Modelldaten für die Szene in den Bildpuffer gerendert worden sind. Dann wird der Inhalt des Bildpuffers an eine Anzeigesteuerung zur Anzeige auf einem Gerät übertragen.
Die Grafikverarbeitungs-Pipeline 1500 ist ein abstraktes Flussdiagramm der Verarbeitungsschritte, die implementiert werden, um aus 3D-Geometriedaten 2D-Computergenerierte Bilder zu erzeugen. Bekanntlich können Pipeline-Architekturen Operationen mit langer Latenzzeit effizienter durchführen, indem sie die Operation in eine Vielzahl von Stufen aufteilen, wobei die Ausgabe jeder Stufe mit der Eingabe der nächstfolgenden Stufe gekoppelt ist. So empfängt die Grafikverarbeitungs-Pipeline 1500 Eingabedaten 601, die von einer Stufe zur nächsten Stufe der Grafikverarbeitungs-Pipeline 1500 übertragen werden, um Ausgabedaten 1504 zu generieren. In einem Ausführungsbeispiel kann die Grafikverarbeitungs-Pipeline 1500 eine von der OpenGL® API definierte Grafikverarbeitungs-Pipeline repräsentieren. Optional kann die grafikverarbeitende Pipeline 1500 im Kontext der Funktionalität und Architektur der vorherigen Figuren und/oder jeder nachfolgenden Figur(en) implementiert werden.
Wie in 15 gezeigt, umfasst die Grafikverarbeitungspipeline 1500 eine Pipeline-Architektur, die eine Reihe von Stufen umfasst. Die Stufen umfassen unter anderem eine Datenzusammenstellung 1506, eine Vertex-Schattierungsstufe 1508, eine PrimitivZusammenstellung 1510, eine Geometrie-Schattierungsstufe 1512, eine Darstellungsbereich-SCC-Stufe 1514, eine Rasterisierung 1516, eine Fragment-Schattierungsstufe 1518 und eine Rasteroperationen 1520. In einem Ausführungsbeispiel umfassen die Eingabedaten 1502 Befehle, die die Verarbeitungseinheiten so konfigurieren, dass sie die Stufen der grafischen Pipeline 1500 implementieren, sowie geometrische Primitive (z.B. Punkte, Linien, Dreiecke, Quads, Dreiecksstreifen oder Gebläse usw.), die von den Stufen zu verarbeiten sind. Die Ausgabedaten 1504 können Pixeldaten (z.B. Farbdaten) umfassen, die in einen Bildpuffer oder eine andere Art von Oberflächendatenstruktur in einem Speicher kopiert werden.
Die Datenzusammenstellungsstufe 1506 empfängt die Eingabedaten 1502, die Vertex-Daten für Oberflächen höherer Ordnung, Primitive oder Ähnliches spezifizieren. Die Datenzusammenstellung 1506 sammelt die Vertex-Daten in einem Zwischenspeicher oder einer Warteschlange, z. B. durch Empfang eines Befehls vom Host-Prozessor, der einen Zeiger auf einen Puffer im Speicher enthält, und Lesen der Vertex-Daten aus dem Puffer. Die Vertex-Daten werden dann zur Verarbeitung an die Vertex-Schattierungsstufe 1508 übertragen.
Die Vertex-Schattierung-Stufe 1508 verarbeitet Vertex-Daten, indem sie einen Satz von Operationen (z.B. einen Vertex-Shader oder ein Programm) einmal für jeden der Vertices ausführt. Vertices können z.B. als 4-Koordinaten-Vektor (z.B. <x, y, z, w>) angegeben werden, der mit einem oder mehreren Vertex-Attributen assoziiert ist (z.B. Farbe, Texturkoordinaten, Oberflächennormale usw.). Die Scheitelpunkt-Schattierung 1508 kann individuelle Scheitelpunkt-Attribute wie Position, Farbe, Textur-Koordinaten und ähnliches manipulieren. Mit anderen Worten, die Stufe Vertex Schattierung 1508 führt Operationen an den Vertex-Koordinaten oder anderen mit einem Vertex assoziierten Vertex-Attributen durch. Zu diesen Operationen gehören in der Regel Beleuchtungsoperationen (z.B. Ändern von Farbattributen für einen Vertex) und Transformationsoperationen (z.B. Ändern des Koordinatenraums für einen Vertex). Beispielsweise können Vertices unter Verwendung von Koordinaten in einem Objektkoordinatenraum angegeben werden, die durch Multiplikation der Koordinaten mit einer Matrix transformiert werden, die die Koordinaten aus dem Objektkoordinatenraum in einen Weltraum oder einen Raum mit normalisierten Gerätekoordinaten (NCD) überträgt. Die Vertex-Schattierung-Stufe 1508 generiert transformierte Vertex-Daten, die an die Primitivzusammenstellungs-Stufe 1510 übertragen werden.
Die Primitivzusammenstellung 1510 sammelt die von der Vertex-Schattierung-Stufe 1508 ausgegebenen Vertices und gruppiert die Vertices in geometrische Primitive zur Verarbeitung durch die Geometrie-Schattierung-Stufe 1512. Beispielsweise kann die Primitivzusammenstellung 1510 so konfiguriert sein, dass sie alle drei aufeinanderfolgenden Vertices als geometrische Primitive (z.B. ein Dreieck) zur Übertragung an die Geometrieschattierungsstufe 1512 gruppiert. In einigen Ausführungsbeispielen können bestimmte Vertices für aufeinanderfolgende geometrische Primitive wiederverwendet werden (z.B. können zwei aufeinanderfolgende Dreiecke in einem Dreiecksstreifen zwei Vertices gemeinsam nutzen). Die Primitivzusammenstellung 1510-Stufe überträgt geometrische Primitive (z.B. eine Sammlung assoziierter Vertices) an die Geometrie-Schattierung 1512-Stufe.
Die Geometrieschattierungsstufe 1512 verarbeitet geometrische Primitive, indem sie eine Reihe von Operationen (z.B. einen Geometrieshader oder ein Programm) an den geometrischen Primitiven durchführt. Tesselierungsoperationen können ein oder mehrere geometrische Primitive aus jedem geometrischen Primitiv generieren. Mit anderen Worten: Die Geometrie-SchattierungsStufe 1512 kann jedes geometrische Element in ein feineres Netz aus zwei oder mehr geometrischen Grundelementen unterteilen, das vom Rest der grafischen Pipeline 1500 verarbeitet wird. Die Geometrieschattierungsstufe 1512 überträgt geometrische Primitive an die Darstellungsbereich-SCC-Stufe 1514.
In einem Ausführungsbeispiel kann die Grafikverarbeitungs-Pipeline 1500 innerhalb eines Streaming-Multiprozessors betrieben werden, und die Vertex-Schattierungsstufe 1508, die Primitiv-Assemblierungsstufe 1510, die Geometrie-Schattierungsstufe 1512, die Fragment-Schattierungsstufe 1518 und/oder die damit assoziierte Hardware/Software können nacheinander Verarbeitungsoperationen durchführen. Sobald die sequentiellen Operationen abgeschlossen sind, kann in einem Ausführungsbeispiel die Darstellungsbereich SCC-Stufe 1514 die Daten verwenden. In einem Ausführungsbeispiel können primitive Daten, die von einer oder mehreren Stufen in der Grafikverarbeitungs-Pipeline 1500 verarbeitet wurden, in einen Cache (z.B. L1-Cache, Vertex-Cache usw.) geschrieben werden. In diesem Fall kann in einem Ausführungsbeispiel die Stufe Viewport SCC 1514 auf die Daten im Cache zugreifen. In einem Ausführungsbeispiel sind die Darstellungsbereich-SCC-Stufe 1514 und die Rasterisierungsstufe 1516 als Schaltungen mit fester Funktion implementiert.
Die Stufe Viewport SCC 1514 führt ein Skalieren des Darstellungsbereichs, ein Culling und ein Clipping der geometrischen Primitive durch. Jede Oberfläche, auf die gerendert wird, ist mit einer abstrakten Kameraposition assoziiert. Die Position der Kamera repräsentiert den Ort eines Betrachters, der auf die Szene blickt, und definiert einen Sichtkegel, der die Objekte der Szene einschließt. Der Sichtkegelstumpf kann eine Betrachtungsebene, eine Rückwandebene und vier Beschneidungsebenen umfassen. Geometrische Primitive, die vollständig außerhalb des Sichtkegelstumpfes liegen, können aussortiert (z.B. verworfen) werden, da sie keinen Beitrag zur final gerenderten Szene leisten. Jedes geometrische Element, das sich teilweise innerhalb und teilweise außerhalb des Sichtkegelstumpfes befindet, kann abgeschnitten werden (z.B. durch Umwandlung in ein neues geometrisches Element, das innerhalb des Sichtkegelstumpfes liegt). Weiterhin können geometrische Primitive basierend auf einer Tiefe des Sichtkegelstumpfes skaliert werden. Alle potenziell sichtbaren geometrischen Primitive werden dann an die Rasterisierungsstufe 1516 weitergeleitet.
Die Rasterisierungsstufe 1516 wandelt die geometrischen 3D-Primitive in 2D-Fragmente um (die z.B. für die Anzeige verwendet werden können, usw.). Die Rasterisierungsstufe 1516 kann so konfiguriert sein, dass sie die Vertices der geometrischen Primitive verwendet, um einen Satz von Ebenengleichungen aufzustellen, aus denen verschiedene Attribute interpoliert werden können. Die Rasterisierungsstufe 1516 kann auch eine Abdeckungsmaske für eine Vielzahl von Pixeln berechnen, die angibt, ob ein oder mehrere Sample-Orte für das Pixel das geometrische Primitiv durchschneiden. In einem Ausführungsbeispiel kann auch ein Z-Test durchgeführt werden, um zu bestimmen, ob die geometrische Grundform von anderen geometrischen Grundformen, die bereits gerastert wurden, verdeckt wird. Die Rasterisierungsstufe 1516 generiert Fragmentdaten (z.B. interpolierte Vertex-Attribute, die mit einem bestimmten Sample-Ort für jedes abgedeckte Pixel assoziiert sind), die an die Fragmentschattierungsstufe 1518 übertragen werden.
Die Fragment-Schattierung-Stufe 1518 verarbeitet Fragmentdaten, indem sie eine Reihe von Operationen (z.B. einen Fragment-Shader oder ein Programm) an jedem der Fragmente durchführt. Die Fragmentschattierungsstufe 1518 kann Pixeldaten (z.B. Farbwerte) für das Fragment generieren, z.B. durch Ausführen von Beleuchtungsoperationen oder Sampling von Texturkarten unter Verwendung interpolierter Texturkoordinaten für das Fragment. Die Fragmentschattierungsstufe 1518 generiert Pixeldaten, die an die Rasteroperationsstufe 1520 weitergeleitet werden.
Die Rasteroperationsstufe 1520 kann verschiedene Operationen an den Pixeldaten durchführen, wie z. B. Alphatests, Schablonentests und das Mischen der Pixeldaten mit anderen Pixeldaten, die anderen, mit dem Pixel assoziierten Fragmenten entsprechen. Wenn die Rasteroperationsstufe 1520 die Verarbeitung der Pixeldaten (z.B. der Ausgabedaten 1504) abgeschlossen hat, können die Pixeldaten in ein Rendering-Ziel geschrieben werden, wie z.B. einen Frame-Puffer, einen Farbpuffer oder ähnliches.
Es versteht sich von selbst, dass die Graphikverarbeitungs-Pipeline 1500 zusätzlich zu oder anstelle einer oder mehrerer der oben beschriebenen Stufen eine oder mehrere zusätzliche Stufen enthalten kann. Verschiedene Implementierungen der abstrakten Graphikverarbeitungs-Pipeline können unterschiedliche Stufen implementieren. Weiterhin können eine oder mehrere der oben beschriebenen Stufen in einigen Ausführungsbeispielen von der Graphikverarbeitungs-Pipeline ausgeschlossen werden (z. B. die Geometrieschattierungsstufe 1512). Andere Arten von Graphikverarbeitungs-Pipelines sind im Rahmen der vorliegenden Offenbarung denkbar. Weiterhin kann jede der Stufen der Graphikverarbeitungs-Pipeline 1500 durch eine oder mehrere dedizierte Hardwareeinheiten innerhalb eines Graphikprozessors implementiert werden, wie z. B. die Parallelverarbeitungseinheit 920. Andere Stufen der Graphikverarbeitungs-Pipeline 1500 können von programmierbaren Hardwareeinheiten wie dem Streaming-Multiprozessor 1200 der Parallelverarbeitungseinheit 920 implementiert werden.
Die Graphikverarbeitungs-Pipeline 1500 kann über eine Applikation implementiert werden, die von einem Host-Prozessor, wie z.B. einer CPU, ausgeführt wird. In einem Ausführungsbeispiel kann ein Gerätetreiber eine Anwendungsprogrammierschnittstelle (API) implementieren, die verschiedene Funktionen definiert, die von einer Applikation genutzt werden können, um grafische Daten für die Anzeige zu generieren. Der Gerätetreiber ist ein Softwareprogramm, das eine Vielzahl von Anweisungen enthält, die die Operation der Parallelverarbeitungseinheit 920 steuern. Die API bietet eine Abstraktion für einen Programmierer, die es ihm ermöglicht, spezialisierte Grafikhardware wie die Parallelverarbeitungseinheit 920 zu nutzen, um die Grafikdaten zu generieren, ohne dass der Programmierer den spezifischen Befehlssatz für die Parallelverarbeitungseinheit 920 verwenden muss. Die Applikation kann einen API-Aufruf enthalten, der an den Gerätetreiber für die Parallelverarbeitungseinheit 920 weitergeleitet wird. Der Gerätetreiber interpretiert den API-Aufruf und führt verschiedene Operationen durch, um auf den API-Aufruf zu reagieren. In einigen Instanzen kann der Gerätetreiber Operationen durch Ausführen von Anweisungen auf der CPU durchführen. In anderen Instanzen kann der Gerätetreiber Operationen zumindest teilweise durch Starten von Operationen auf der Parallelverarbeitungseinheit 920 unter Verwendung einer Eingabe/Ausgabe-Schnittstelle zwischen der CPU und der Parallelverarbeitungseinheit 920 durchführen. In einem Ausführungsbeispiel ist der Gerätetreiber so konfiguriert, dass er die Graphikverarbeitungs-Pipeline 1500 unter Verwendung der Hardware der Parallelverarbeitungseinheit 920 implementiert.
Verschiedene Programme können innerhalb der Parallelverarbeitungseinheit 920 ausgeführt werden, um die verschiedenen Stufen der Graphikverarbeitungs-Pipeline 1500 zu implementieren. Beispielsweise kann der Gerätetreiber einen Kernel auf der Parallelverarbeitungseinheit 920 starten, um die Vertex-Schattierungsstufe 1508 auf einem Streaming-Multiprozessor 1200 (oder mehreren Streaming-Multiprozessor 1200-Modulen) auszuführen. Der Gerätetreiber (oder der initiale Kernel, der von der Parallelverarbeitungseinheit 920 ausgeführt wird) kann auch andere Kernel auf der Parallelverarbeitungseinheit 920 starten, um andere Stufen der Graphikverarbeitungs-Pipeline 1500 auszuführen, wie z. B. die Geometrie-Schattierungsstufe 1512 und die Fragment-Schattierungsstufe 1518. Darüber hinaus können einige der Stufen der Graphikverarbeitungs-Pipeline 1500 auf fester Hardware implementiert werden, wie z. B. ein Rasterisierer oder ein Datenassembler, der in der Parallelverarbeitungseinheit 920 implementiert ist. Es wird deutlich, dass die Ergebnisse eines Kerns von einer oder mehreren zwischengeschalteten Hardwareeinheiten mit fester Funktion verarbeitet werden können, bevor sie von einem nachfolgenden Kern auf einem Streaming-Multiprozessor 1200 verarbeitet werden.
Verschiedene hierin beschriebene funktionale Operationen können in einer Logik implementiert werden, auf die mit Hilfe eines Substantivs oder einer Substantivphrase verwiesen wird, die diese Operation oder Funktion widerspiegelt. Zum Beispiel kann eine assoziierte Operation von einem „Assoziator“ oder „Korrelator“ durchgeführt werden. Ebenso kann das Schalten durch einen „Switch“, die Selektion durch einen „Selektor“ usw. erfolgen. „Logik“ bezieht sich auf maschinelle Speicherschaltungen und nicht transitorische, maschinenlesbare Medien, die maschinenausführbare Anweisungen (Software und Firmware) umfassen, und/oder Schaltungen (Hardware), die aufgrund ihrer materiellen und/oder materiell-energetischen Konfiguration Steuer- und/oder Verfahrenssignale und/oder Einstellungen und Werte (wie Widerstand, Impedanz, Kapazität, Induktivität, Strom-/Spannungswerte usw.) umfassen, die zur Beeinflussung der Operation eines Geräts verwendet werden können. Magnetische Medien, elektronische Schaltungen, elektrische und optische Speicher (sowohl flüchtig als auch nichtflüchtig) und Firmware sind Beispiele für Logik. Logik schließt ausdrücklich reine Signale oder Software als solche aus (schließt jedoch nicht aus, dass Maschinenspeicher Software umfassen und dadurch Konfigurationen von Materie bilden).
Im Rahmen dieser Offenbarung können verschiedene Einheiten (die auch als „Einheiten“, „Schaltkreise“, andere Komponenten usw. bezeichnet werden können) als „konfiguriert“ beschrieben oder beansprucht werden, um eine oder mehrere Aufgaben oder Operationen auszuführen. Diese Formulierung - [Einheit], die so konfiguriert ist, dass sie [eine oder mehrere Aufgaben ausführt] - wird hier verwendet, um sich auf eine Struktur zu beziehen (d. h. auf etwas Physisches, wie z. B. einen elektronischen Schaltkreis). Insbesondere wird diese Formulierung verwendet, um darauf hinzuweisen, dass diese Struktur so beschaffen ist, dass sie während der Operation die eine oder mehrere Aufgaben erfüllt. Eine Struktur kann auch dann als „konfiguriert“ bezeichnet werden, um eine bestimmte Aufgabe zu erfüllen, wenn die Struktur gerade nicht operativ ist. Eine „Kreditverteilungsschaltung, die so konfiguriert ist, dass sie Kredite an eine Vielzahl von Prozessorkernen verteilt“, soll z.B. einen integrierten Schaltkreis umfassen, der über eine Schaltung verfügt, die diese Funktion während der Operation ausführt, auch wenn der betreffende integrierte Schaltkreis gerade nicht verwendet wird (z.B. keine Stromversorgung angeschlossen ist). Eine Einheit, die als „konfiguriert, um eine Aufgabe zu erfüllen“ beschrieben oder zitiert wird, bezieht sich also auf etwas Physisches, wie ein Gerät, einen Schaltkreis, einen Speicher, der Programmanweisungen speichert, die zur Implementierung der Aufgabe ausgeführt werden können, usw. Dieser Ausdruck wird hier nicht verwendet, um sich auf etwas Immaterielles zu beziehen.
Der Begriff „konfiguriert für“ ist nicht gleichbedeutend mit „konfigurierbar für“. Ein unprogrammiertes FPGA würde zum Beispiel nicht als „konfiguriert“ gelten, um eine bestimmte Funktion auszuführen, obwohl es nach der Programmierung „konfigurierbar“ sein kann, um diese Funktion auszuführen.
Wenn in den beigefügten Ansprüchen erwähnt wird, dass eine Struktur „konfiguriert“ ist, um eine oder mehrere Aufgaben auszuführen, so ist ausdrücklich nicht beabsichtigt, 35 U.S.C. § 112(f) für dieses Anspruchselement geltend zu machen. Dementsprechend sollten Ansprüche in dieser Applikation, die nicht das Konstrukt „Mittel zum“ [Durchführung einer Funktion] enthalten, nicht gemäß 35 U.S.C. § 112(f) interpretiert werden.
Wie hier verwendet, wird der Begriff „basierend auf“ verwendet, um einen oder mehrere Faktoren zu beschreiben, die eine Bestimmung beeinflussen. Dieser Begriff schließt nicht die Möglichkeit aus, dass zusätzliche Faktoren die Bestimmung beeinflussen können. Das heißt, ein Bestimmen kann ausschließlich auf spezifizierten Faktoren basieren oder auf den spezifizierten Faktoren sowie auf anderen, nicht spezifizierten Faktoren basieren. Betrachten Sie die Formulierung „Bestimmen Sie A basierend auf B“. Dieser Satz gibt an, dass B ein Faktor ist, der verwendet wird, um A zu bestimmen, oder der die Bestimmung von A beeinflusst. Dieser Satz schließt nicht aus, dass die Bestimmung von A auch auf einem anderen Faktor basieren kann, wie z. B. C. Dieser Satz soll auch ein Ausführungsbeispiel abdecken, in dem A ausschließlich basierend auf B bestimmt wird.
Wie hierin verwendet, beschreibt der Ausdruck „als Reaktion auf“ einen oder mehrere Faktoren, die eine Wirkung auslösen. Dieser Ausdruck schließt nicht die Möglichkeit aus, dass zusätzliche Faktoren die Wirkung beeinflussen oder anderweitig auslösen können. Das heißt, eine Wirkung kann ausschließlich als Reaktion auf die genannten Faktoren eintreten oder auch als Reaktion auf die genannten Faktoren sowie auf andere, nicht näher bezeichnete Faktoren. Nehmen wir die Formulierung „A als Reaktion auf B ausführen“. Dieser Satz gibt an, dass B ein Faktor ist, der die Ausführung von A auslöst. Dieser Satz schließt nicht aus, dass die Ausführung von A auch als Reaktion auf einen anderen Faktor, wie z. B. C, erfolgen kann. Dieser Satz soll auch ein Ausführungsbeispiel abdecken, bei dem A ausschließlich als Reaktion auf B ausgeführt wird.
Wie hier verwendet, werden die Begriffe „erster“, „zweiter“ usw. als Kennzeichnungen für Substantive verwendet, denen sie vorausgehen, und implizieren keine Art von Ordnung (z.B. räumlich, zeitlich, logisch usw.), sofern nicht anders angegeben. Beispielsweise können in einer Registerdatei mit acht Registern die Begriffe „erstes Register“ und „zweites Register“ für zwei beliebige der acht Register verwendet werden und nicht nur für die logischen Register 0 und 1.
Wenn der Begriff „oder“ in den Ansprüchen verwendet wird, wird er als ein einschließendes oder und nicht als ein ausschließendes oder verwendet. Zum Beispiel bedeutet die Formulierung „zumindest eines von x, y oder z“ ein beliebiges von x, y und z, sowie eine beliebige Kombination davon.
Wie hierin verwendet, sollte eine Erwähnung von „und/oder“ in Bezug auf zwei oder mehr Elemente so interpretiert werden, dass nur ein Element oder eine Kombination von Elementen gemeint ist. So kann beispielsweise „Element A, Element B und/oder Element C“ nur Element A, nur Element B, nur Element C, Element A und Element B, Element A und Element C, Element B und Element C oder die Elemente A, B und C umfassen. Darüber hinaus kann „mindestens eines von Element A oder Element B“ mindestens eines von Element A, mindestens eines von Element B oder mindestens eines von Element A und mindestens eines von Element B enthalten.
Der Gegenstand der vorliegenden Offenbarung wird hier mit einer gewissen Spezifität beschrieben, um die gesetzlichen Anforderungen zu erfüllen. Die Beschreibung selbst soll jedoch den Umfang dieser Offenbarung nicht einschränken. Vielmehr haben die Erfinder in Betracht gezogen, dass der beanspruchte Gegenstand auch auf andere Weise verkörpert werden könnte, um verschiedene Schritte oder Kombinationen von Schritten, die den in diesem Dokument beschriebenen ähnlich sind, in Verbindung mit anderen gegenwärtigen oder zukünftigen Technologien zu umfassen. Auch wenn die Begriffe „Schritt“ und/oder „Block“ hier verwendet werden, um verschiedene Elemente der verwendeten Verfahren zu bezeichnen, sollten die Begriffe nicht so ausgelegt werden, dass sie eine bestimmte Reihenfolge unter oder zwischen den verschiedenen hier offenbaren Schritten implizieren, es sei denn, die Reihenfolge der einzelnen Schritte wird ausdrücklich beschrieben.
Nachdem die Ausführungsbeispiele so detailliert beschrieben wurden, wird deutlich, dass Modifikationen und Variationen möglich sind, ohne dass der Umfang der beanspruchten Erfindung verlassen wird. Der Umfang des Erfindungsgegenstandes ist nicht auf die dargestellten Ausführungsbeispiele beschränkt, sondern wird vielmehr in den folgenden Ansprüchen dargelegt.

Claims

Kommunikationsverfahren, umfassend: Anwenden einer ersten Kodierungstechnik auf einer Bitsequenz, um eine Vielzahl von ersten pulsamplitudenmodulierten (PAM) Symbolen für Daten zu generieren, die über zumindest einen Bus übertragen werden; Detektieren einer Lücke im Befehlsverkehr auf dem Bus; und als Reaktion auf das Detektieren der Lücke im Befehlsverkehr, Umschalten auf eine zweite Kodierungstechnik auf der Bitsequenz, um zweite PAM-Symbole für die Daten auf dem Bus zu generieren, wobei die zweiten PAM-Symbole eine stärkere Dünnbesetzung aufweisen als die ersten PAM-Symbole.
Verfahren nach Anspruch 1, wobei sowohl das erste als auch das zweite Kodierverfahren 3ΔV-Übergänge zwischen Symbolen auf dem Bus vermeiden.
Verfahren nach Anspruch 1 oder 2, wobei die zweiten PAM-Symbole so ausgebildet sind, dass sie dem Bus weniger Energie entziehen als die ersten PAM-Symbole.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die zweiten PAM-Symbole 4b4s31-Symbole umfassen.
Verfahren nach einem der vorangehenden Ansprüche, wobei die zweiten PAM-Symbole 4b3s31-Symbole umfassen.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die zweite Kodierungstechnik basierend auf einer Größe der Lücke im Befehlsverkehr ausgewählt wird.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die zweite Kodierungstechnik 4b3s31 ist, unabhängig von der Größe der Lücke im Befehlsverkehr.
Verfahren nach einem der vorhergehenden Ansprüche, weiter umfassend: unter der Bedingung, dass ein erster Symbolwert nicht ein Symbolwert mit dem niedrigsten Energieverbrauch ist, Vertauschen des ersten Symbolwertes auf dem Bus mit einem zweiten Symbolwert mit dem niedrigsten Energieverbrauch; und Codieren einer Indikation der Vertauschung auf einer Datenbus-Inversionsleitung (DBI) des zumindest einen Busses.
Verfahren nach Anspruch 8, wobei die Indikation auf der DBI-Leitung angibt, ob L0 gegen L1, L2 oder keines von beiden vertauscht wurde.
Verfahren nach einem der vorhergehenden Ansprüche, weiter umfassend: unter der Bedingung, dass eines der ersten PAM-Symbole bzw. eines der zweiten PAM-Symbole ein Symbol mit dem höchsten Energieverbrauch ist, Verschieben eines Pegels eines nächsten auf dem Bus zu übertragenden Symbols auf einen nächsthöheren Pegel, als ihn das erste Kodierverfahren bzw. das zweite Kodierverfahren sonst generiert hätte.
Transceiver, umfassend: ein erstes Codebuch für eine Vielzahl von ersten PAM-Symbolen; ein zweites Codebuch für eine zweite Vielzahl von PAM-Symbolen, das eine stärkere Dünnbesetzung aufweist als die ersten PAM-Symbole; und Logik zum Umschalten vom ersten Codebuch zum zweiten Codebuch, um Symbole auf einem Datenbus zu generieren, als Reaktion auf das Detektieren einer Lücke im Befehlsverkehr.
Transceiver nach Anspruch 11, wobei die zweiten PAM-Symbole so konfiguriert sind, dass sie dem Datenbus weniger Energie entziehen als die ersten PAM-Symbole.
Transceiver nach Anspruch 11 oder 12, wobei die zweiten PAM-Symbole 4b4s31-Symbole umfassen.
Transceiver nach einem der Ansprüche 11 bis 13, wobei die zweiten PAM-Symbole 4b3s31-Symbole umfassen.
Transceiver nach einem der Ansprüche 11 bis 14, wobei das zweite Codebuch basierend auf einer Größe der Lücke im Befehlsverkehr ausgewählt wird.
System, umfassend: einen Prozessor; einen Speicher; Logik zum Umschalten von der Verwendung eines ersten Kodierungsmechanismus auf die Verwendung eines zweiten Kodierungsmechanismus, um PAM-Symbole auf einem Speicherbus zu generieren, als Reaktion auf das Detektieren einer Lücke in Zugriffsbefehlen von dem Prozessor zu dem Speicher; und wobei der zweite Kodierungsmechanismus weniger Leistung vom Speicherbus zieht als der erste Kodierungsmechanismus.
System nach Anspruch 16, wobei der zweite Kodierungsmechanismus basierend auf einer Größe der Lücke zwischen den Speicherzugriffsbefehlen ausgewählt wird.
System nach Anspruch 16 oder 17, wobei sowohl der erste Kodierungsmechanismus als auch der zweite Kodierungsmechanismus eine Maximum-Transition-Avoidance-Technik implementieren.
System nach einem der Ansprüche 16 bis 18, wobei der zweite Kodierungsmechanismus 4b3s31-PAM-Symbole generiert.
System nach einem der Ansprüche 16 bis 18, wobei der Prozessor eine Grafikverarbeitungseinheit ist.