DE102019134020A1

DE102019134020A1 - Dekompprimierungstechniken zur verarbeitung komprimierter daten, die für künstliche neuronale netzwerke geeignet sind

Info

Publication number: DE102019134020A1
Application number: DE102019134020.9A
Authority: DE
Inventors: Jorge Albericio Latorre; Jack H. Choquette; Manan Maheshkumar Patel; Jeffrey Pool; Ming Y. Siu; Ronny Meir Krashinsky; Ganesh Venkatesh
Original assignee: Nvidia Corp
Current assignee: Nvidia Corp
Priority date: 2019-03-08
Filing date: 2019-12-11
Publication date: 2020-09-10
Also published as: US11379420B2; US20200285618A1; CN111667542A; CN111667542B

Abstract

Komprimierte Daten sind häufig zum Verringern der erforderlichen Rechenressourcen vorteilhaft, um beispielsweise Daten zu übertragen und zu speichern. Die Komprimierung von Daten ist besonders beim Umgang mit spärlichen Daten nützlich (Daten, die zahlreiche Nullen oder Nahe-Null-Werte umfassen) und nur Nicht-Null-Werte oberhalb einer bestimmte Schwelle haben Bedeutung. Beim Umgang mit komprimierten Daten müssen die Daten häufig zur Verarbeitung dekomprimiert werden (z.B., durch Netzwerke für tiefgehendes Lernen oder andere Anwendungen, die konfiguriert sind, um an spärlichen oder anderen unkomprimierten Daten zu arbeiten). Anweisungen werden zur Unterstützung der Dekomprimierung von komprimierten Daten durch eine Verarbeitungseinheit, wie beispielsweise eine CPU und GPU, offenbart.

Description

GEBIET DER ERFINDUNG
Die vorliegende Erfindung betrifft komprimierte Daten und genauer gesagt die Dekomprimierung von komprimierten Daten.
HINTERGRUND
Es gibt viele Umstände beim Rechnen, wo komprimierte Daten nützlich sind. Im Allgemeinen können, da die Komprimierung von Daten die Größe der Daten verringern wird, die komprimierten Daten übertragen, gespeichert und manchmal sogar mit weniger erforderlichen Rechenressourcen (z.B., Bandbreite, Speicher, usw.) verarbeitet werden, als andernfalls erforderlich wäre, wenn die Daten nicht komprimiert wären. Die Komprimierung von Daten ist besonders nützlich beim Umgang mit spärlichen Daten, wie nachstehend beschrieben. Es sei natürlich bemerkt, dass Datenkomprimierung auf ähnliche Weise mit anderen Arten von Daten, die nicht notwendigerweise dünnbesetzt sind, aus den oben erwähnten Gründen nützlich sein kann.
In Netzwerken für tiefgehendes Lernen und anderen Anwendungen gibt es typischerweise eine große Menge an beteiligten Daten, die als spärliche Daten angesehen werden, oder mit anderen Worten, Daten, die zahlreiche Nullen oder Nahe-Null-Werte umfassen. Aufgrund der großen Größe der in derartigen Anwendungen beteiligten Daten ist es hilfreich, die Daten zu komprimieren (z.B., die Datengröße zu verringern), um Bandbreitenressourcen beim Übertragen der Daten und Speicherressourcen beim Speichern der Daten einzusparen. Typischerweise werden die Daten in einem Format komprimiert, das versuchen wird, die signifikanten Werte (z.B., Nicht-Null-Werte oder Werte oberhalb einer vorbestimmten Schwelle) in den ursprünglichen Daten zu bewahren, während die insignifikanten Werte ausgeschlossen werden.
In vielen Fällen müssen die komprimierten Daten jedoch für Verarbeitungszwecke dekomprimiert werden. Beispielsweise werden Netzwerke für tiefgehendes Lernen (oder andere oben erwähnte Anwendungen) im Allgemeinen die Daten in einem dekomprimierten Zustand vor der Verarbeitung benötigen. Dies gilt insbesondere, wenn die Daten von Hardwareeinheiten verarbeitet werden, welche die Daten im dekomprimierten Zustand benötigen. Die dekomprimierten Daten werden die gleichen oder im Wesentlichen die gleichen wie die ursprünglichen Daten sein, an denen die Komprimierung anfangs durchgeführt wurde. Leider sind herkömmliche Datendekomprimierungstechniken, die komprimierte spärliche Daten oder andere Arten von komprimierten Daten behandeln, häufig komplex und erfordern komplizierte Recheneinheiten in Hardware, was kostspielig ist. Es gibt eine Notwendigkeit, sich diesen Problemen und/oder anderen Problemen zu widmen, die dem Stand der Technik zugeordnet sind.
ZUSAMMENFASSUNG
In einer Ausführungsform werden ein Verfahren, ein computerlesbares Medium und ein System für eine Anweisung offenbart, die mindestens einen Abschnitt von komprimierten Daten dekomprimiert. Eine N-Elementdatenstruktur wird als Eingabe empfangen, wobei jedes Element in der N-Elementdatenstruktur einen Wert hält. Die N-Elementdatenstruktur wurde zuvor durch Komprimieren einer ursprünglichen M-Elementdatenstruktur erzeugt, wobei N<M. Außerdem werden Metadaten, die der N-Elementdatenstruktur zugeordnet sind, als Eingabe empfangen. Die Metadaten spezifizieren für jeden Wert in der N-Elementdatenstruktur einen Ort, wo der Wert in der M-Elementdatenstruktur herrührte. Ferner wird eine Ziel-M-Elementdatenstruktur optional initialisiert. Mindestens eine Anweisung wird ausgeführt, um mindestens einen Abschnitt der N-Elementdatenstruktur in mindestens einen Abschnitt der Ziel-M-Elementdatenstruktur zu dekomprimieren, durch Schreiben in das Ziel-M-Elementdatenstruktur ein oder mehrere Werte der N-Elementdatenstruktur an dem(den) Ort(en) geschriebenen werden, der(die) durch die zugeordneten Metadaten spezifiziert wird(werden). Vorausgesetzt, dass eine N-Elementdatenstruktur vollständig in eine Ziel-M-Elementdatenstruktur dekomprimiert wird, ist das Komprimierungsverhältnis zwischen den komprimierten und unkomprimierten Daten gleich N zu M (oder N:M).
In einer Ausführungsform werden ein Verfahren, ein computerlesbares Medium und ein System für eine Anweisung offenbart, die als Eingabe komprimierte Daten nimmt und weniger dicht komprimierte Daten durch teilweises Dekomprimieren der eingegebenen komprimierten Daten erzeugt. Eine N-Elementdatenstruktur (wie oben erläutert) und ihre zugeordneten Metadaten (ebenfalls wie oben erläutert) werden als Eingabe empfangen. Die eingegebene N-Elementdatenstruktur kann in eine M-Elementdatenstruktur dekomprimiert werden, die ein N:M Komprimierungsverhältnis darstellt. Mindestens eine Anweisung wird ausgeführt, um von der N-Elementdatenstruktur und ihren zugeordneten Metadaten eine R-Elementdatenstruktur und entsprechende Metadaten zu erzeugen, wobei N<=R<M (wobei „<=“ bedeutet „weniger als oder gleich“). Die R-Elementdatenstruktur und ihre zugeordneten Metadaten dekomprimieren vollständig in eine Q-Elementdatenstruktur, wobei Q<=M und die Q-Elementdatenstruktur mindestens einem Abschnitt der M-Elementdatenstruktur entspricht. Folglich ist das Komprimierungsverhältnis zwischen der R-Elementdatenstruktur (die komprimierte Daten hält) und der Q-Elementdatenstruktur (die unkomprimierte Daten hält) gleich R:Q. Wenn sowohl R!=N-als auch Q!=M (wobei „!=“ bedeutet „nicht gleich“), ist das Komprimierungsverhältnis R:Q>N:M. Somit stellen die resultierende R-Elementdatenstruktur und die Metadaten weniger dicht komprimierte Daten als die N-Elementdatenstruktur und die Metadaten dar.
Figurenliste

1 veranschaulicht ein beispielhaftes N:M Komprimierungsformat.
2 veranschaulicht ein beispielhaftes 4:16 Komprimierungsformat.
3 veranschaulicht ein beispielhaftes Ablaufdiagramm zum Dekomprimieren komprimierter Daten in N:M Komprimierungsformat.
4 veranschaulicht eine beispielhafte 4:16 Dekomprimierungsanweisung.
5 veranschaulicht eine beispielhafte 4:16 Dekomprimierungsanweisung, die im PAIR-Modus arbeitet.
6 veranschaulicht eine beispielhaftes 4:16 Dekomprimierungsanweisung, die im QUAD-Modus arbeitet.
7 veranschaulicht eine beispielhafte Erzeugung von weniger dicht komprimierten Daten aus dichter komprimierten Daten.
8 veranschaulicht ein beispielhaftes Ablaufdiagramm zum Erzeugen weniger dicht komprimierter Daten aus dichter komprimierten Daten durch teilweises Dekomprimieren der dichter komprimierten Daten.
9 veranschaulicht eine beispielhafte 2:16 zu 2:4 teilweise Dekomprimierungsanweisung.
10 veranschaulicht eine beispielhafte 2:16 zu 2:4 teilweise Dekomprimierungsanweisung, die im PAIR-Modus arbeitet.
11 veranschaulicht eine beispielhafte 2:32 zu 2:4 teilweise Dekomprimierungsanweisung, die im QUAD-Modus arbeitet.
12 veranschaulicht eine Parallelverarbeitungseinheit gemäß einer Ausführungsform.
13A veranschaulicht einen allgemeinen Verarbeitungscluster innerhalb der Parallelverarbeitungseinheit von 12 gemäß einer Ausführungsform.
13B veranschaulicht eine Speicherpartitions-Einheit der Parallelverarbeitungseinheit von 3 gemäß einer Ausführungsform.
14A veranschaulicht den Streaming-Mehrfachprozessor von 13A gemäß einer Ausführungsform.
14B ist ein Konzeptdiagramm eines Verarbeitungssystems, das unter Verwendung der PPU von 12 implementiert wird, gemäß einer Ausführungsform.
14C veranschaulicht ein beispielhaftes System, bei dem die verschiedene Architektur und/oder Funktionalität der verschiedenen vorherigen Ausführungsformen implementiert werden kann.
15 ist ein Konzeptdiagramm einer Graphikverarbeitungs-Pipeline, die durch die PPU von 12 implementiert wird, gemäß einer Ausführungsform.

AUSFÜHRLICHE BESCHREIBUNG
1 veranschaulicht ein beispielhaftes N:M Komprimierungsformat. Das Komprimierungsdatenformat 100 umfasst eine N-Elementdatenstruktur 104 und Metadaten 106. Im Komprimierungsdatenformat 100 gehaltene Daten werden in ein unkomprimiertes Datenformat 102 dekomprimiert. Das unkomprimierte Datenformat 102 umfasst eine M-Elementdatenstruktur 108, wobei N<M. Metadaten 106 geben für jedes Datum D_N-1, ..., D₁, D₀ in der N-Elementdatenstruktur 102 den Ort (z.B., M-1, M-2, 6, 1) in der M-Elementdatenstruktur 108 an, wo das Datum kopiert werden soll. Vorausgesetzt, dass die Daten in der N-Elementdatenstruktur 104 in die M-Elementdatenstruktur 108 dekomprimiert werden, wird das in 1 gezeigte Komprimierungsformat als ein Komprimierungs- zu Dekomprimierungsverhältnis von N zu M (oder „N:M“) aufweisend bezeichnet.
In einer Ausführungsform kann jedes Datum D_N-1, ..., D₁, D₀ ein numerischer Wert sein. Ein numerischer Wert kann in einer beliebigen Anzahl von Bits (z.B., 4-Bit („Halbbyte“), 8-Bit („Byte“), 16-Bit („Halbwort“), 32-Bit („Wort“), 64-Bit („Doppelwort“), usw.) dargestellt werden, die in einem Ganzzahl-, Gleitkomma-, Festkomma-, Logarithmus- oder irgendeinem anderen numerischen Format zum Codieren numerischer Werte auf einem Computer codiert werden.
In einer Ausführungsform können Metadaten 106 N Einträge umfassen, wobei jeder Eintrag einem Datum in der N-Elementdatenstruktur 104 entspricht und jeder Eintrag einen Ort (z.B., einen Index) angibt, wo das entsprechende Datum in die M-Elementdatenstruktur 108 zu kopieren ist. In einer anderen Ausführungsform (nicht gezeigt) können Metadaten 106 eine Anzahl M von Bits umfassen, wobei lediglich eine Anzahl N von Bits eingestellt wird, um die Orte anzugeben, wo jedes Datum in der N-Elementdatenstruktur 102 in die M-Elementdatenstruktur 108 kopiert werden soll. In noch einer anderen Ausführungsform (nicht gezeigt) können Metadaten 106 einen Index in einer Nachschlagetabelle (lookup table; LUT) umfassen, die Information darüber bereitstellt, wo jedes Datum in der N-Elementdatenstruktur 102 in die M-Elementdatenstruktur 108 zu kopieren ist.
2 veranschaulicht ein beispielhaftes 4:16 Komprimierungsformat. Wie in 2 gezeigt, wird das komprimierte Datenformat 200 in das unkomprimierte Datenformat 202 dekomprimiert. Das komprimierte Datenformat 200 umfasst eine N-Elementdatenstruktur 204, wobei N=4. Wie gezeigt, umfasst die 4-Elementdatenstruktur 204 4 beispielhafte Werte A, B, C und D. Das komprimierte Datenformat 200 umfasst ferner Metadaten 206 mit 4 beispielhaften Einträgen, die angeben, wo jeder der beispielhaften Werte A, B, C und D in die M-Elementdatenstruktur 208 kopiert werden soll (wobei M=16), wenn die 4-Elementdatenstruktur 202 in die 16-Elementdatenstruktur 208 dekomprimiert wird. Vorausgesetzt, dass die Daten in der 4-Elementdatenstruktur 204 in die 16-Elementdatenstruktur 208 dekomprimiert werden, wird das in 2 gezeigte Komprimierungsformat bezeichnet, als ein Komprimierungs- zu Dekomprimierungsverhältnis von 4 zu 16 (oder „4:16“) aufzuweisen.
3 veranschaulicht ein beispielhaftes Ablaufdiagramm eines Verfahrens 300 zum Dekomprimieren komprimierter Daten im N:M Komprimierungsformat. Eine Anweisung kann ausgeführt werden, um zu veranlassen, dass das Verfahren 300 an allen oder einem Teil der komprimierten Daten durchgeführt wird. Eine derartige Anweisung kann von einer GPU (Graphikverarbeitungseinheit), einer CPU (Zentralverarbeitungseinheit) oder einer anderen Rechenhardware durchgeführt werden.
Bei Schritt 302 wird mindestens ein Abschnitt einer N-Elementdatenstruktur als Eingabe empfangen. Die N-Elementdatenstruktur kann durch Komprimieren einer ursprünglichen M-Elementdatenstruktur erzeugt worden sein, wobei N<M. Jedes Element in der N-Elementdatenstruktur umfasst ein Datum (z.B., einen numerischen Wert). Die N-Elementdatenstruktur und auf ähnliche Weise die M-Elementdatenstruktur kann eine Anordnung, ein Vektor, eine Matrix, ein Tensor oder eine beliebige andere Art von Struktur zum Halten von Daten sein. In einer Ausführungsform kann die ursprüngliche M-Elementdatenstruktur aus spärlichen Daten bestehen, wobei in diesem Fall die N-Elementdatenstruktur durch Komprimieren der M-Elementdatenstruktur erzeugt worden sein kann, um Nullen oder Nahe-Null-Werte auszuschließen (z.B., Werte, die innerhalb eines(einiger) kleinen(r) Schwellenwerts(e) nahe Null sind, wie beispielsweise Werte innerhalb -0,03 und 0,05, oder in einem anderen Beispiel, Werte innerhalb -0,05 und 0,05).
Bei Schritt 304 wird mindestens ein Abschnitt der Metadaten für die N-Elementdatenstruktur als Eingabe empfangen. Die Metadaten spezifizieren für jedes Datum in der N-Elementdatenstruktur, wo das Datum in eine M-Elementdatenstruktur kopiert werden soll.
Bei Schritt 306 wird mindestens ein Abschnitt einer Ziel-M-Elementdatenstruktur gekennzeichnet und kann initialisiert werden. In einer Ausführungsform kann das Initialisieren ein Setzen aller oder einiger der Elemente in dem Ziel-Anpassprozess auf einen vorbestimmten Standardwert, wie beispielsweise Null, Nichts, 0,05 usw., umfassen. In einer Ausführungsform kann das Initialisieren ein Setzen aller oder einiger der Elemente in der Ziel-M-Elementdatenstruktur auf einen Zufallswert oder Pseudozufallswert oder Nahe-NullWert umfassen. In einer Ausführungsform kann das Initialisieren ein Setzen aller oder einiger der Elemente in der Ziel-M-Elementdatenstruktur mit Werten umfassen, die von einer anderen M-Elementdatenstruktur oder einer anderen Datenquelle erhalten werden.
Bei Schritt 308 wird mindestens ein Abschnitt der eingegebenen N-Elementdatenstruktur in die Ziel-M-Elementdatenstruktur unter Verwendung der eingegebenen Metadaten dekomprimiert. Die Dekomprimierung wird durch Schreiben in die Ziel-M-Elementdatenstruktur jedes Datums in der empfangenen N-Elementdatenstruktur an dem durch die Metadaten spezifizierten Ort durchgeführt. Verbleibende Elemente der Ziel-M-Elementdatenstruktur können ihre existierenden oder initialisierten Werte (z.B., Null, Nichts, Zufallswert usw.) beibehalten.
Das Verfahren 300 kann von einem einzelnen Thread der Ausführung durchgeführt werden. Alternativ kann das Verfahren 300 von einer Mehrzahl von Threads durchgeführt werden. In einer Ausführungsform dekomprimiert ein einzelner Thread die Gesamtheit der eingegebenen N-Elementdatenstruktur. In einer anderen Ausführungsform dekomprimiert jeder eines Paars von Threads die Hälfte der eingegebenen N-Elementdatenstruktur. In noch einer anderen Ausführungsform dekomprimiert jeder eines Quads von Threads ein Viertel der eingegebenen N-Elementdatenstruktur. Ferner können in einer Ausführungsform unterschiedliche Threads oder unterschiedliche Anweisungen in einem einzelnen Thread die gleiche eingegebene N-Elementdatenstruktur oder unterschiedliche Instanzen der N-Elementdatenstruktur verwenden. Außerdem können in einer Ausführungsform unterschiedliche Threads oder unterschiedliche Anweisungen in einem einzelnen Thread auf unterschiedlichen Instanzen der Ziel-M-Elementdatenstruktur arbeiten. In einer anderen Ausführungsform können die unterschiedlichen Threads oder unterschiedliche Anweisungen in einem einzelnen Thread auf einer gemeinsam genutzten Instanz der Ziel-M-Elementdatenstruktur arbeiten. Während die vorliegende Beschreibung sowohl vorstehend als auch nachstehend Threads der Ausführung (z.B., auf einer GPU) beschreibt, sei bemerkt, dass Ausführungsspuren (z.B., auf jedem Ausführungspfad einer einzelnen Anweisung mehreren Daten (SIMD) CPU) auf ähnliche Weise anstelle von oder zusätzlich zu Threads benutzt werden können.
Ein Format für eine beispielhafte Anweisung, genannt SCATTER, um eine GPU, eine CPU oder eine andere Rechenhardware zu veranlassen, das Verfahren 300 durchzuführen, wird in Tabelle 1 gezeigt.
Tabelle 1
SCATTER{.elsize}.mode{.idxSize} {.partial} Rd, Ra, Rb, {Rc,} #VecIdx {#Maske} wobei:

Ra: Quellenregister zum Halten der Gesamtheit oder eines Abschnitts einer N-Elementdatenstruktur
Rb: Quellenregister zum Halten der Gesamtheit oder eines Abschnitts der Metadaten für die N-Elementdatenstruktur
Rd: Zielregister zum Halten der Gesamtheit oder eines Abschnitts der Ziel-M-Elementdatenstruktur
{Rc}: optionales Quellenregister, das die Gesamtheit oder einen Abschnitt einer anderen N-Elementdatenstruktur hält, das benutzt werden kann, um Rd zu initialisieren (alternativ kann Rd mit Nullen oder irgendeinem(welchen) anderen vordefinierten Wert(en) initialisiert werden)
{elsize}: optionaler Parameter, der die Anzahl von Bits angibt, die verwendet, um ein Datum in der N-Elementdatenstruktur darzustellen (z.B., elsize = „8b“ für 8 Bits, „16b“ für 16 Bits, usw.); wenn nicht bereitgestellt, wird SCATTER standardmäßig 8 Bits {idxSize}: optional Parameter, der die Anzahl von Bits angibt, die verwendet werden, um einen Eintrag in den Metadaten darzustellen (z.B., idxSize = „U8“ für 8 Bits, „U4“ für 4 Bits, usw.); wenn nicht bereitgestellt, wird SCATTER standardmäßig gleich 8 Bits #VecIdx: gibt an, welcher Abschnitt der Ziel-M-Elementdatenstruktur in Rd gehalten wird {#Maske}: eine optionale Bitmaske, die angibt, welche Abschnitte von Ra dekomprimiert werden

Modus: eines von „THREAD,“ „PAIR“ oder „QUAD“, die angeben, wie #VecIdx zu interpretieren ist, wie ausführlicher nachstehend beschrieben ist {.partial}: optionaler Parameter, der angibt, ob Ra beispielsweise teilweise dekomprimiert wird, um weniger dicht komprimierte Daten zu erzeugen
Die SCATTER-Anweisung behandelt das Quellenregister Ra, als ob es X Elemente der N-Elementdatenstruktur speichert, wobei $X = ⌊ \frac{B}{elsize} ⌋,$
wobei B die Anzahl von Bits ist, die im Register Ra gespeichert werden kann (z.B., 32 Bits). Somit behandelt, wenn das Register Ra 32 Bits hält und elsize gleich 8 Bit ist, SCATTER das Quellenregister Ra, als ob es 4 Elemente der N-Elementdatenstruktur speichert (d.h., $X = ⌊ \frac{32}{8} ⌋ = 4$
). In einem anderen Beispiel behandelt SCATTER, wenn das Register Ra 32 Bits hält und elsize gleich 16 Bits ist, das Quellenregister Ra als ob es 2 Elemente der N-Elementdatenstruktur speichert (d.h., $X = ⌊ \frac{32}{16} ⌋ = 2$
).
Die SCATTER-Anweisung behandelt das Zielregister Rd ebenfalls, als ob es X Elemente der M-Elementdatenstruktur speichert, wobei X berechnet wird, wie oben beschrieben. Vorausgesetzt, dass M viel größer als X sein kann, behandelt SCATTER Rd, als ob es nur einen zusammenhängenden X-Element-Abschnitt der M-Elementdatenstruktur hält. Der spezifische Abschnitt der M-Elementdatenstruktur wird durch die #VecIdx-Eingabe in die SCATTER-Anweisung und den Modus der SCATTER-Anweisung spezifiziert.
Im THREAD-Modus interpretiert die SCATTER-Anweisung #VecIdx als angebend, dass Rd Orte (#VecIdx * X + X- 1) bis (#VecIdx * X) der M-Elementdatenstruktur hält. Wenn beispielsweise X = 4 ist, gibt ein #VecIdx Wert von 0 an, dass Rd Orte 3 ... 0 der M-Elementdatenstruktur hält, ein #VecIdx Wert von 1 an, dass Rd Orte 7 ... 4 hält, ein #VecIdx Wert von 2 an, dass Rd Orte 11 ... 8 hält, usw. In einem anderen Beispiel gibt, wenn X = 2, ein #VecIdx Wert von 0 an, dass Rd Orte 1 und 0 hält, ein #VecIdx Wert von 1 an, dass Rd Orte 3 und 2 hält, usw.
Im PAIR-Modus interpretiert die SCATTER-Anweisung #VecIdx als angebend, dass Rd Orte (#VecIdx * 2X + X-1 + (ThreadID Modulus 2)*X) bis (#VecIdx * 2X + (ThreadID Modulus 2)*X) der M-Elementdatenstruktur hält. Die ThreadID (kurz für „Thread identifier“) ist ein numerischer Wert, welcher dem die SCATTER-Anweisung ausführenden Thread zugeordnet ist. Wenn beispielsweise X=4 ist und die ThreadID des die SCATTER-Anweisungausführenden Threads gleich 28 ist, gibt ein #VecIdx Wert von 1 an, dass Rd Orte 11 ... 8 hält. Wenn X=4 und die ThreadID des die SCATTER-Anweisung ausführenden Threads gleich 29 ist, gibt ein #VecIdx Wert von 1 ebenfalls an, dass Rd Orte 15 ... 12 hält. Ebenso gibt, wenn X=4 und die ThreadID des die SCATTER-Anweisung ausführenden Threads gleich 29 ist, ein #VecIdx Wert von 2 an, dass Rd Orte 23 ... 20 hält.
Im QUAD-Modus interpretiert die SCATTER-Anweisung #VecIdx als angebend, dass Rd Orte (#VecIdx * 4X + X-1 + (ThreadID Modulus 4)*X) bis (#VecIdx * 4X + (ThreadID Modulus 4)*X) der M-Elementdatenstruktur hält. Wenn beispielsweise X=4 und die ThreadID des die SCATTER-Anweisung ausführenden Threads gleich 17 ist, gibt ein #VecIdx Wert von 1 an, dass Rd Orte 23 ... 20 hält.
Ein Beispiel einer Anweisung, die mit dem in Tabelle 1 gezeigten Format konform ist, wird in Tabelle 2 gezeigt.
Tabelle 2
SCATTER.THREAD R12 R10 R11 0
Die beispielhafte Anweisung in Tabelle 2 gibt an, dass mindestens ein Abschnitt der N-Elementdatenstruktur in Register R10 gespeichert ist, mindestens ein Abschnitt der Metadaten in R11 gespeichert ist und der Inhalt von R10 in R12 dekomprimiert werden sollte. Ferner gibt, wie oben erläutert, wo Register R10 und R12 jeweils 32 Bits speichern, ein 0-Wert für #VecIdx an, dass R12 den Abschnitt der Ziel-M-Elementdatenstruktur mit Orten 3 ... 0 darstellt.
Ein weiteres Beispiel einer Anweisung, die dem in Tabelle 1 gezeigten Format konform ist, wird in Tabelle 3 gezeigt.
Tabelle 3
SCATTER.16b.THREAD.U4R12 R10 R11 0
Die beispielhafte Anweisung in Tabelle 3 übermittelt die gleiche Anweisung, die in Tabelle 2 gezeigt ist, außer dass die beispielhafte Anweisung in Tabelle 3 angibt, dass das Datum in der N-Elementdatenstruktur in 16 Bits anstatt in 8 Bits dargestellt wird, und dass die Einträge in den Metadaten in 4 Bits anstatt 8 Bits dargestellt werden. Ferner gibt, wie oben erläutert, wo Register R10 und R12 jeweils 32 Bits speichern, ein 0-Wert für #VecIdx in dieser Instanz an, dass R12 den Abschnitt der Ziel-M-Elementdatenstruktur mit Orten 1 und 0 darstellt.
4 veranschaulicht einen beispielhaften Satz von Anweisungen, die eine 4:16 Dekomprimierung durchführen. In dem vorliegenden Beispiel arbeitet die 4:16 Dekomprimierung im oben beschriebenen THREAD-Modus. Genauer gesagt führt jeder Thread der Ausführung, der den beispielhaften Satz der in 4 gezeigten Anweisungen durchführt, eine vollständige 4:16 Dekomprimierung einer 4-Elementdatenstruktur (in R2) und Metadaten (in R3) in eine 16-Elementdatenstruktur (in R10, R11, R12, R13) durch. In einem Multi-Thread-Prozessor kann jeder Thread auf seinem eigenen Satz von Registern arbeiten (z.B., jeder Thread mit seinen eigenen 32 Registern mit den Namen R0, R1, R2, ... R31). Folglich kann, während die in 4 gezeigten gleichen Anweisungen von mehreren Threads verarbeitet werden können, jeder Thread mit unterschiedlichen Werten ausgeführt werden, die in seinem eigenen Satz von Quellenregistern R2 und R3 gespeichert sind (die eine unterschiedliche komprimierte 4-Elementdatenstruktur darstellen), um entsprechende dekomprimierte Daten in seinem eigenen Satz von Zielregistern R10, R11, R12 und R13 zu erzeugen.
Wie gezeigt, gibt die erste Anweisung (SCATTER.THREAD R10, R2, R3, 0) an, dass die N-Elementdatenstruktur in Register R2 gespeichert wird, die Metadaten in R3 gespeichert werden und mindestens ein Abschnitt des Inhalts von R2 in R10 dekomprimiert werden sollte. Ferner gibt der 0-Wert (für #VecIdx) an, dass R10 den Abschnitt der Ziel-M-Elementdatenstruktur mit Orten 3 ... 0 darstellt. Wenn die erste Anweisung ausgeführt wird, wird der Wert A von Register R2 in R10 in die Position kopiert, die dem Ort 2 in der Ziel-M-Elementdatenstruktur entspricht (wie durch die Metadaten in R3 spezifiziert). Weil die Metadaten in R3 angeben, dass es keine anderen Werte in R2 für Orte 3 ... 0 in der Ziel-M-Elementdatenstruktur gibt, werden keine anderen Werte (d.h., B, C oder D) in das Register R10 kopiert.
Die zweite Anweisung (SCATTER.THREAD R11, R2, R3, 1) gibt an, dass die N-Elementdatenstruktur in Register R2 gespeichert ist, die Metadaten in R3 gespeichert sind und mindestens ein Abschnitt des Inhalts von R2 in R11 dekomprimiert werden sollte. Ferner gibt der 1-Wert (für #VecIdx) an, dass R11 den Abschnitt der Ziel-M-Elementdatenstruktur mit Orten 7 ... 4 darstellt. Wenn die zweite Anweisung ausgeführt wird, wird Wert B aus Register R2 in R11 an die Position kopiert, die dem Ort 4 in der Ziel-M-Elementdatenstruktur entspricht (wie durch die Metadaten in R3 spezifiziert).
Die dritte Anweisung (SCATTER.THREAD R12, R2, R3, 2) gibt an, dass die N-Elementdatenstruktur in Register R2 gespeichert ist, die Metadaten in R3 gespeichert sind und mindestens ein Abschnitt des Inhalts von R2 in R12 dekomprimiert werden sollte. Ferner gibt der 2-Wert (für #VecIdx) an, dass R12 den Abschnitt der Ziel-M-Elementdatenstruktur mit Orten 11 ... 8 darstellt. Wenn die dritte Anweisung ausgeführt wird, werden keine Werte von Register R2 in R12 kopiert, weil die Metadaten in R3 angeben, dass kein Wert in R2 einem der Orte 11 ... 8 in der Ziel-M-Elementdatenstruktur entspricht.
Die vierte Anweisung (SCATTER.THREAD R13, R2, R3, 3) gibt an, dass die N-Elementdatenstruktur in Register R2 gespeichert ist, die Metadaten in R3 gespeichert sind und mindestens ein Abschnitt des Inhalts von R2 in R13 dekomprimiert werden sollte. Ferner gibt der 3-Wert (für #VecIdx) an, dass R12 den Abschnitt der Ziel-M-Elementdatenstruktur mit Orten 15 ... 12 darstellt. Wenn die vierte Anweisung ausgeführt wird, werden Werte C und D von Register R2 in R13 an den Positionen kopiert, die jeweils Orten 14 und 15 in der Ziel-M-Elementdatenstruktur entsprechen (wie durch die Metadaten in R3 spezifiziert).
5 veranschaulicht eine beispielhafte 4:16 Dekomprimierungsanweisung, die im PAIR-Modus arbeitet. Im PAIR-Modus kann jeder eines Paars von Threads die Hälfte der N-Elementdatenstruktur dekomprimieren. Wie oben erläutert, arbeitet in einigen Ausführungsformen jeder Thread auf seinem eigenen Satz von Registern. In dem in 5 gezeigten Beispiel beenden 2 Anweisungen die 4:16 Dekomprimierung, wenn mindestens zwei Threads die 2 Anweisungen ausführen, wobei jeder Thread die Hälfte der ursprünglichen N-Elementdatenstruktur dekomprimiert.
Wie gezeigt, gibt die erste Anweisung (SCATTER.PAIR R10, R2, R3, 0) an, dass die N-Elementdatenstruktur in Register R2 gespeichert ist, die Metadaten in R3 gespeichert sind und mindestens ein Abschnitt des Inhalts von R2 in R10 dekomprimiert werden sollte. Ferner gibt der 0-Wert (für #VecIdx) an, dass R10 den Abschnitt der Ziel-M-Elementdatenstruktur mit Orten 3 ... 0 darstellt, wenn der Thread, der die erste Anweisung ausführt, einen geraden ThreadID-Wert (d.h., (ThreadID Modulus 2) == 0) aufweist, und Orten 7 ... 4 darstellt, wenn der Thread, der die erste Anweisung ausführt, eine ungerade ThreadID aufweist (d.h., (ThreadID Modulus 2) == 1). Wenn die erste Anweisung durch einen Thread mit einem geraden ThreadID-Wert ausgeführt wird, wird Wert A aus Register R2 in R10 an einer Position kopiert, die dem Ort 2 in der Ziel-M-Elementdatenstruktur entspricht (wie durch die Metadaten in R3 spezifiziert). Wenn die erste Anweisung durch einen Thread mit einem ungeraden ThreadID-Wert ausgeführt wird, wird Wert B aus Register R2 in R10 an einer Position kopiert, die dem Ort 4 in der Ziel-M-Elementdatenstruktur entspricht (wie durch die Metadaten in R3 spezifiziert).
Außerdem gibt die zweite Anweisung (SCATTER.PAIR R11, R2, R3, 1) an, dass die N-Elementdatenstruktur in Register R2 gespeichert ist, die Metadaten in R3 gespeichert sind und mindestens ein Abschnitt des Inhalts von R2 in R11 dekomprimiert werden sollte. Ferner gibt der 1-Wert (für #VecIdx) an, dass R11 den Abschnitt der Ziel-M-Elementdatenstruktur mit Orten 11 ... 8 darstellt, wenn der Thread, der die zweite Anweisung ausführt, einen geraden ThreadID-Wert aufweist, und Orten 15 ... 12 darstellt, wenn der Thread, der die zweite Anweisung ausführt, einen ungeraden ThreadID-Wert aufweist. Wenn die zweite Anweisung durch einen Thread mit einem geraden ThreadID-Wert ausgeführt wird, werden keine Werte aus Register R2 in R11 kopiert, wie durch die Metadaten in R3 spezifiziert. Wenn die zweite Anweisung durch einen Thread mit einem ungeraden ThreadID-Wert ausgeführt wird, werden Werte C und D in R11 an Positionen kopiert, die jeweils Orten 14 und 15 in der Ziel-M-Elementdatenstruktur entsprechen (wie durch die Metadaten in R3 spezifiziert).
6 veranschaulicht eine beispielhaftes 4:16 Dekomprimierungsanweisung, die im QUAD-Modus arbeitet. Im QUAD-Modus kann jeder eines Quads von Threads ein Viertel der N-Elementdatenstruktur dekomprimieren. Wie oben erläutert, arbeitet in einigen Ausführungsformen jeder Thread auf seinem eigenen Satz von Registern. In dem in 6 gezeigten Beispiel beendet 1 Anweisung die 4:16 Dekomprimierung, wenn mindestens vier Threads die einzelne Anweisung ausführen, wobei jeder Thread ein Viertel der ursprünglichen N-Elementdatenstruktur dekomprimiert.
Wie gezeigt, gibt die erste Anweisung (SCATTER.QUAD R10, R2, R3, 0) an, dass die N-Elementdatenstruktur in Register R2 gespeichert ist, die Metadaten in R3 gespeichert sind und mindestens ein Abschnitt des Inhalts von R2 in R10 dekomprimiert werden sollte. Ferner gibt der 0-Wert (für #VecIdx) an, dass R10 den Abschnitt der Ziel-M-Elementdatenstruktur mit Orten 3 ... 0 darstellt, wenn der Thread, der die erste Anweisung ausführt, einen ThreadID-Wert für einen ersten Quadranten aufweist (d.h., (ThreadID Modulus 4) == 0), mit Orten 7 ... 4 darstellt, wenn der Thread einen ThreadID-Wert für einen zweiten Quadranten aufweist (d.h., (ThreadID Modulus 4) == 1), mit Orten 11 ... 8 darstellt, wenn der Thread einen ThreadID-Wert für einen dritten Quadrant aufweist (d.h., (ThreadID Modulus 4) == 2) und mit Orten 15 ... 12 darstellt, wenn der Thread einen ThreadID-Wert für einen vierten Quadrant aufweist (d.h., (ThreadID Modulus 4) == 3). Wenn die erste Anweisung durch einen Thread mit einer ThreadID für ersten Quadrant ausgeführt wird, wird Wert A aus Register R2 in R10 an eine Position kopiert, die dem Ort 2 der Ziel-M-Elementdatenstruktur entspricht (wie durch die Metadaten in R3 spezifiziert). Außerdem wird, wenn die erste Anweisung durch einen Thread mit einer ThreadID für einen zweiten Quadranten ausgeführt wird, wird Wert B aus Register R2 in R10 an eine Position kopiert, die dem Ort 4 der Ziel-M-Elementdatenstruktur entspricht (wie durch die Metadaten in R3 spezifiziert). Wenn die erste Anweisung durch einen Thread mit einer ThreadID für einen dritten Quadranten ausgeführt wird, wird kein Wert aus Register R2 in R10 kopiert, wie durch die Metadaten in R3 spezifiziert. Schließlich werden, wenn die erste Anweisung durch einen Thread mit einer ThreadID für einen vierten Quadranten ausgeführt wird, Werte C und D in R10 an Positionen kopiert, die jeweils Orten 14 und 15 der Ziel-M-Elementdatenstruktur entsprechen (wie durch die Metadaten spezifiziert).
7 veranschaulicht eine beispielhafte Erzeugung von weniger dicht komprimierten Daten aus dichter komprimierten Daten. Anstatt das komprimierte Datenformat 700 in das unkomprimierte Datenformat 702 zu dekomprimieren, wie für Beispiel in 2 beschrieben, zeigt 7 das komprimierte Datenformat 700 mit dichter komprimierten Daten (2:8 wie gezeigt), die in nahezu gleichwertige, weniger dicht komprimierte Daten dekomprimiert werden (zwei Sätze von 2:4 Daten, wie gezeigt). Mit anderen Worten wird das komprimierte Datenformat 700 teilweise in das teilweise dekomprimierte Datenformat 704 dekomprimiert.
Das komprimierte Datenformat 700 umfasst eine N-Elementdatenstruktur 706, wobei N=2. Wie gezeigt, umfasst die N-Elementdatenstruktur 706 2 beispielhafte Werte F und E. Das komprimierte Datenformat 700 umfasst ferner Metadaten 708 mit 2 beispielhaften Einträgen, die angeben, wo jeder der beispielhaften Werte E und F in die M-Elementdatenstruktur 709 (wobei M=8) zu kopieren sind, wenn die N-Elementdatenstruktur 706 in die M-Elementdatenstruktur 709 dekomprimiert wird.
Andererseits umfasst das teilweise dekomprimierte Datenformat 704 zwei Sätze von Daten und Metadaten, die für jeden Satz eine R-Elementdatenstruktur 710A, 712A umfassen, wobei R=2, und entsprechende Metadaten 710B, 712B umfassen. Metadaten 710B, 712B für jede R-Elementdatenstruktur 710A, 712A umfassen 2 beispielhafte Einträge, die angeben, wo jeder der beispielhaften Werte in die entsprechende R-Elementdatenstruktur 710A, 712A in eine Q-Elementdatenstruktur 714A, 714B (wobei Q=4) zu kopieren sind, wenn jede R-Elementdatenstruktur 710A, 712A in eine entsprechende Q-Elementdatenstruktur 714A, 714B dekomprimiert wird. Jede Q-Elementdatenstruktur entspricht einem Abschnitt der M-Elementdatenstruktur.
Wie gezeigt, entsprechen der erste Satz von Daten und die Metadaten 710A, 710B für das teilweise dekomprimierte Datenformat 704 einem ersten Element der N-Elementdatenstruktur (E) und der zweite Satz von Daten und die Metadaten 712A, 712B für das teilweise dekomprimierte Datenformat 704 entsprechen einem zweiten Element der N-Elementdatenstruktur (F). Somit speichert der erste Satz von Daten 710A den Wert des ersten Elements der N-Elementdatenstruktur (E), wobei ein oder mehrere zusätzliche Elemente Null oder einen anderen definierten Quellenwert speichern. Auf ähnliche Weise speichert der zweite Satz von Daten 712A den Wert des zweiten Elements der N-Elementdatenstruktur (F), wobei ein oder mehrere zusätzliche Elemente Null oder einer anderen definierten Quellenwert speichern.
Die gezeigte beispielhafte Ausführungsform befolgt Anforderungen, dass Metadaten 710B, 712B von rechts nach links größer werden müssen, wobei Nullen in den R-Elementdatenstrukturen 710A, 712A lediglich Elementen 1 oder 2 in Q-Elementdatenstrukturen 714A, 714B entsprechen. Natürlich können diese Anforderungen vollständig von den spezifischen Einheiten fester Funktion abhängen, welche die Dekomprimierung durchführen.
Allgemein werden für N:M dicht komprimierten Daten zwei Sätze von R:Q nahezu gleichwertiger, weniger dicht komprimierten Daten erzeugt, wobei N<=R. Für diese teilweise Dekomprimierung dekomprimieren die R-Elementdatenstruktur 710A, 712A und ihre zugeordneten Metadaten 710B, 712B vollständig in die entsprechende Q-Elementdatenstruktur 714A, 714B, wobei Q<=M und die Q-Elementdatenstruktur mindestens einem Abschnitt der M-Elementdatenstruktur entspricht. Folglich ist das Komprimierungsverhältnis zwischen der R-Elementdatenstruktur 710A, 712A (Halten komprimierter Daten) und der Q-Elementdatenstruktur 714A, 714B (Halten unkomprimierten Daten) gleich R:Q. Wenn sowohl R!=N als auch Q!=M (wobei „!=“ bedeutet „nicht gleich“), ist das Komprimierungsverhältnis R:Q>N:M. Somit stellen die resultierende R-Elementdatenstruktur 710A, 712A und die Metadaten 710B, 712B weniger dicht komprimierte Daten als die N-Elementdatenstruktur 706 und die Metadaten 708 dar.
Das teilweise dekomprimierte Datenformat 704 kann in bestimmten Anwendungen nützlich sein, die verlangen, dass die Daten von einer bestimmten Größe sind. Ferner kann das Ausmaß, zu dem die N-Elementdatenstruktur dekomprimiert ist, durch Konfigurieren der Größe der R-Elementdatenstrukturen konfiguriert werden, in welche die N-Elementdatenstruktur dekomprimiert ist.
8 veranschaulicht ein beispielhaftes Ablaufdiagramm eines Verfahrens 800 zum Erzeugen weniger dicht komprimierter Daten aus dichter komprimierten Daten durch teilweises Dekomprimieren der dichter komprimierten Daten.
Bei Schritt 802 wird mindestens ein Abschnitt einer N-Elementdatenstruktur als Eingabe empfangen. Die N-Elementdatenstruktur kann durch Komprimieren einer ursprünglichen M-Elementdatenstruktur erzeugt worden sein, wobei N<M. Somit kann die N-Elementdatenstruktur die gleiche oder ähnlich der bei Schritt 302 von 3 beschriebenen N-Elementdatenstruktur sein.
Bei Schritt 804 wird mindestens ein Abschnitt der Metadaten für die N-Elementdatenstruktur als Eingabe empfangen. Die Metadaten spezifizieren für jede Datum in der N-Elementdatenstruktur, wo das Datum in eine M-Elementdatenstruktur kopiert werden soll, wenn die N-Elementdatenstruktur in die M-Elementdatenstruktur dekomprimiert wird.
Bei Schritt 806 werden mindestens zwei Ziel-R-Elementdatenstrukturen gekennzeichnet und können initialisiert werden, wobei N<=R<M. In einer Ausführungsform kann das Initialisieren ein Setzen aller oder einiger der Elemente in der Ziel-R-Elementdatenstruktur auf einen vorbestimmten Standardwert (z.B., Null, Werte von einer oder mehreren anderen R-Elementdatenstrukturen usw.) umfassen.
Bei Schritt 808 werden mindestens zwei Abschnitte der eingegebenen N-Elementdatenstruktur jeweils in einer entsprechenden Ziel-R-Elementdatenstruktur gespeichert. Verbleibende Elemente der Ziel-R-Elementdatenstruktur können ihre initialisierten oder existierenden Werte beibehalten.
Bei Schritt 810 werden Metadaten für jede der R-Elementdatenstrukturen erzeugt. Es sei bemerkt, dass Schritt 810 ein optionaler Schritt für das vorliegende Verfahren 800 ist und in einer anderen Ausführungsform offline oder anderweitig separat zu dem Verfahren 800 durchgeführt werden kann. Die Metadaten spezifizieren für jedes Datum in der R-Elementdatenstruktur, wo das Datum in eine Q-Elementdatenstruktur kopiert werden soll, wenn die R-Elementdatenstruktur in die Q-Elementdatenstruktur dekomprimiert wird. Im Kontext der vorliegenden Ausführungsform dekomprimiert die R-Elementdatenstruktur und ihre zugeordneten Metadaten vollständig in die Q-Elementdatenstruktur, wobei Q<=M und die Q-Elementdatenstruktur mindestens einem Abschnitt der M-Elementdatenstruktur entspricht. Das Komprimierungsverhältnis zwischen der R-Elementdatenstruktur (Halten komprimierter Daten) und der Q-Elementdatenstruktur (Halten unkomprimierter Daten) ist wiederum R:Q. Wenn sowohl R!=N als auch Q!=M (wobei „!=“ bedeutet „nicht gleich“), ist das Komprimierungsverhältnis R:Q>N:M. Somit stellen der resultierenden Satz von R-Elementdatenstrukturen und Metadaten weniger dicht komprimierte Daten als die N-Elementdatenstruktur und Metadaten dar. Im Allgemeinen ist beim Übergang von N:M in R:Q Dekomprimierung, dann N<=R (z.B., wenn R:Q-= 2:4, dann muss N gleich 1 oder 2 sein, wenn R:Q jedoch 4:8 ist, dann kann N gleich 1, 2, 3 oder 4 sein, wobei N:M = 4:16 zum Beispiel).
Das Verfahren 800 kann durch einen einzelnen Thread der Ausführung durchgeführt werden. Alternativ kann das Verfahren 800 durch eine Mehrzahl von Threads (z.B., 2 (Paar) oder 4 (Quad) Threads) durchgeführt werden. In einer Ausführungsform dekomprimiert ein einzelner Thread die Gesamtheit der eingegebenen N-Elementdatenstruktur. In einer anderen Ausführungsform dekomprimiert jeder eines Paar von Threads die Hälfte der eingegebenen N-Elementdatenstruktur. In noch einer anderen Ausführungsform dekomprimiert jeder eines Quad von Threads ein Viertel der eingegebenen N-Elementdatenstruktur.
Ein Format für eine beispielhafte Anweisung, um eine GPU, CPU oder andere Rechenhardware zu veranlassen, Schritte 802-808 des Verfahren 800 durchzuführen, wird in der obigen Tabelle 1 spezifisch durch Einschließen des Parameters „.partial“ in der Anweisung gezeigt.
Ein Format für eine beispielhafte Anweisung, um eine GPU, CPU oder andere Rechenhardware zu veranlassen, Schritt 810 des Verfahrens 800 durchzuführen, wird in der folgenden Tabelle 4 gezeigt.
Tabelle 4
spMetadata{.elsize}.mode{.idxSize} Rd, Ra, {Rb,} #VecIdx, {#Mask}, #Dest wobei:

{elsize}: optionaler Parameter, welcher die Anzahl von Bits angibt, die verwendet werden, um ein Datum in der N-Elementdatenstruktur darzustellen (z.B., elsize = „8b“ für 8 Bits, „16b“ für 16 Bits, usw.); wenn nicht bereitgestellt, wird SCATTER standardmäßig gleich 8 Bits
mode: einer von „THREAD“, „PAIR“ oder „QUAD“, die angeben, ob jeweils die Gesamtheit, die Hälfte oder ein Viertel von Ra durch einen Thread dekomprimiert werden sollte, der diese Anweisung ausführt; die bestimmte Hälfte oder das bestimmte Viertel, die/das durch einen bestimmten Thread dekomprimiert wird, basiert auf der Identifizierungsnummer („ThreadID“) des bestimmten Threads
{idxSize}: optionaler Parameter, der die Anzahl von Bits angibt, die verwendet werden, um einen Eintrag in die Metadaten darzustellen (z.B., idxSize = „U8“ für 8 Bits, „U4“ für 4 Bits usw.); wenn nicht bereitgestellt, wird SCATTER standardmäßig gleich 8 Bits Rd: Zielregister zum Halten der Gesamtheit oder eines Abschnitts der Ziel-R-Elementdatenstruktur
Ra: Quellenregister zum Halten der Gesamtheit oder eines Abschnitts eines N-Elementdatenstruktur
{Rb}: Quellenregister zum Halten der Gesamtheit oder eines Abschnitts der Metadaten für die N-Elementdatenstruktur
#VecIdx: gibt an, welcher Abschnitt der Ziel-M-Elementdatenstruktur in Rd gehalten wird {#Maske}: eine optionale Bitmaske, die angibt, welche Abschnitte von Ra dekomprimiert werden
#Dest: 0, ..., 7, gibt an, welches das Halbbyte ist, wohin die Metadaten geschrieben werden

9 veranschaulicht eine beispielhafte 2:16 (N:M) zu 2:4 (R:Q) teilweise Dekomprimierungsanweisung. In dem vorliegenden Beispiel arbeitet die teilweise Dekomprimierungsanweisung in dem oben beschriebenen „Thread“-Modus. Insbesondere führt ein einzelner Thread der Ausführung die teilweise Dekomprimierung für einen bestimmten Satz von Zielregistern aus, wobei jeder Satz von Zielregistern ein erstes Register zum Speichern der R-Elementdatenstruktur und ein zweites Register zum Speichern der entsprechenden Metadaten umfasst, die für die R-Elementdatenstruktur erzeugt werden. Somit beenden in dem gezeigten Beispiel 2 Sätze von Anweisungen die 2:16 zu 2:4 teilweise Dekomprimierung.
Wie gezeigt, gibt die erste Anweisung (SCATTER.THREAD.partial R10, R2, R3, 0, 3) an, dass die N-Elementdatenstruktur in Register R2 gespeichert ist, die Metadaten in R3 gespeichert sind und mindestens ein Abschnitt des Inhalts von R2 in R10 dekomprimiert werden sollte. Ferner gibt der 0-Wert (für #VecIdx) an, welcher Abschnitt der unkomprimierten Datenstruktur (M) in R10 gehalten wird (wobei 0 Elemente 0 ... 7 von M darstellt). In der vorliegenden Ausführungsform wird #VecIdx durch 2 geteilt, da die 2 ursprünglichen Datenwerte in zwei Zieldatenstrukturen je eine jeweils eingegeben werden. Der 3-Wert (für #Maske) gibt den Abschnitt von R2 an, der zu dekomprimieren ist (wobei 3 das Element in der unkomprimierten Datenstruktur (M) darstellt, welches in dem Fall dem Element in N entspricht, das den Wert A hält). Wenn ausgeführt, kopiert der erste Thread der Ausführung den Wert A aus Register R2 in Element 1 in R10. Das Element 0 in R10 wird ein zuvor initialisierter Wert bei einer Ausführungsform sein.
Die zweite Anweisung (spMETADATA.THREAD.U2 R11, R3, 0, 3, 0) gibt an, dass die Metadaten für die N-Elementdatenstruktur in Register R3 gespeichert sind und dass basierend auf diesen Metadaten und dem Ergebnis der ersten Anweisung neue Metadaten in das Register R11 für die Daten in R10 zu schreiben sind. In dem vorliegenden Beispiel ist jeder Index in Register R11 gleich 2 Bit. Ferner gibt der 0-Wert (für #VecIdx) den Teilabschnitt von R11 an, der zu beschreiben ist (wobei 0 die Elemente 0 ... 3 darstellt). Außerdem gibt der 3-Wert (für #Maske) an, dass Element 3 in den unkomprimierten Daten in den teilweisen komprimierten Daten aufzunehmen ist, und der letzte 0-Wert (für #Dest) gibt den Abschnitt des Teilabschnitts von R11 an, in den die Metadaten für R10 zu schreiben sind (wobei 0 die Elemente 0 ... 1 des angegebenen Teilabschnitts von R11 darstellt). Wenn ausgeführt, schreibt der erste Thread der Ausführung in R11 den Ort in die Q-Elementdatenstruktur, in den der Wert A in R10 zu schreiben ist, wenn dekomprimiert. Wie gezeigt, kann das erste Element des angegebenen Teilabschnitts von R11 den Wert 0, 1 oder 2 halten und das zweite Element des angegebenen Teilabschnitts von R11 kann den Wert 1, 2 oder 3 in der vorliegenden Ausführungsform halten. Ferner entsprechen in dem gezeigten Beispiel die ersten beiden Elemente des angegebenen Teilabschnitts von R11 (Elemente 0 ... 1) einer unterschiedlichen Gruppe (und jeweiligen Teilabschnitt der Q-Elementdatenstruktur) als die zweiten zwei Elemente (Elemente 2 ... 3), so dass, obwohl Elemente 0 und 2 beide den Wert 1 halten, diese Elemente effektiv unterschiedlichen Plätzen in der Q-Elementdatenstruktur entsprechen.
Die dritte Anweisung (SCATTER.THREAD.partial R12, R2, R3, 1, 3) gibt an, dass die N-Elementdatenstruktur in Register R2 gespeichert ist, die Metadaten in R3 gespeichert sind und mindestens ein Abschnitt des Inhalts von R2 in R12 dekomprimiert werden sollte. Ferner gibt der 1-Wert (für #VecIdx) an, welcher Abschnitt der unkomprimierten Datenstruktur (M) in R12 gehalten wird (wobei 1 die Elemente 8 ... 15 von M darstellt). Der 3-Wert (für #Maske) gibt den Abschnitt von R2 an, der zu dekomprimieren ist (wobei 3, mit einer binären Darstellung von 11, die beiden ersten Elemente von R2 darstellt). Wenn ausgeführt, kopiert ein zweiter Thread der Ausführung den Wert B aus Register R2 in Element 3 in R12. Element 2 in R12 wird ein zuvor initialisierter Wert in einer Ausführungsform sein.
Die vierte Anweisung (spMETADATA.THREAD.U2 R13, R3, 1, 3, 1) gibt an, dass die Metadaten für die N-Elementdatenstruktur in Register R3 gespeichert sind und dass basierend auf diesen Metadaten und dem Ergebnis der dritten Anweisung neue Metadaten in Register R11 für die Daten in R12 zu schreiben sind. Ferner gibt der 1-Wert (für #VecIdx) den Teilabschnitt von R11 an, der zu beschreiben ist (wobei 1 die Elemente 4... 7 darstellt). Außerdem gibt der 3-Wert (für #Maske) an, dass Elemente 0 und 1 in den unkomprimierten Daten in den teilweise komprimierten Daten aufzunehmen sind, und der letzte 1-Wert (für #Dest) gibt den Abschnitt des Teilabschnitts von R11 an, in den die Metadaten für R12 zu schreiben sind (wobei 1 die Elemente 2 ... 3 des angegebenen Teilabschnitts von R11 darstellt). Wenn ausgeführt, schreibt der zweite Thread der Ausführung in R11 den Ort in die Q-Elementdatenstruktur, in den der Wert B in R12 zu schreiben ist, wenn dekomprimiert. Wie gezeigt, kann das erste Element des angegebenen Teilabschnitts von R11 den Wert 0, 1 oder 2 halten und das zweite Element des angegebenen Teilabschnitts von R11 den Wert 1, 2 oder 3 in der vorliegenden Ausführungsform halten. Ferner entsprechen in dem gezeigten Beispiel die ersten beiden Elemente des angegebenen Teilabschnitts von R11 (Elemente 0 ... 1) einer unterschiedlichen Gruppe (und jeweiligen Teilabschnitt der Q-Elementdatenstruktur) als die zweiten zwei Elemente (Elemente 2 ... 3), so dass, obwohl Elemente 0 und 2 beide den Wert 1 halten, diese Elemente effektiv unterschiedlichen Plätzen in der Q-Elementdatenstruktur entsprechen.
10 veranschaulicht eine beispielhafte 2:16 zu 2:4 teilweise Dekomprimierungsanweisung, die im PAIR-Modus arbeitet. Im PAIR-Modus kann jeder eines Paar von Threads eine teilweise Dekomprimierung für die Hälfe der N-Elementdatenstruktur bereitstellen. Mit anderen Worten erzeugt jeder Thread in dem Paar einen Satz der 2:4 Daten. In dem gezeigten Beispiel arbeitet jeder Thread auf seinem eigenen Satz von Registern.
Wie gezeigt, gibt die erste Anweisung (SCATTER.PAIR.partial R10, R2, R3, 0, 3) an, dass die N-Elementdatenstruktur in Register R2 gespeichert ist, die Metadaten in R3 gespeichert sind und mindestens ein Abschnitt des Inhalts von R2 in R10 dekomprimiert werden sollte. Ferner gibt der 0-Wert (für #VecIdx) an, dass R10 den Abschnitt der Ziel-M-Elementdatenstruktur mit Orten 7 ... 0 darstellt, wenn der Thread, der die erste Anweisung ausführt, einen geraden ThreadID-Wert (d.h., (ThreadID Modulus 2) == 0) aufweist, und Orte 15 ... 8 darstellt, wenn der Thread, der die erste Anweisung ausführt, eine ungerade ThreadID (d.h., (ThreadID Modulus 2) == 1) aufweist. De 3-Wert (für #Maske) gibt den Abschnitt von R2 an, der zu dekomprimieren ist. Wenn die erste Anweisung durch einen Thread mit einem geraden ThreadID-Wert ausgeführt wird, wird der Wert A aus Register R2 in R10 kopiert. Wenn die erste Anweisung durch einen Thread mit einem ungeraden ThreadID-Wert ausgeführt wird, wird der Wert B aus Register R2 in R10 kopiert.
Außerdem wird die zweite Anweisung (spMETADATA.PAIR.U2 R11, R3, 0, 3, 0) auf ähnliche Weise, wie oben mit Bezugnahme auf 9 beschrieben, außer durch das Paar von Threads in dieser Ausführungsform ausgeführt. Somit wird der Thread, der den Wert A in seine Kopie von R10 schreibt, die neuen Metadaten für A in seine Kopie von R11 schreiben, und der Thread, der den Wert B in seine Kopie von R10 schreibt, die neuen Metadaten für B in seine Kopie von R11 schreiben.
11 veranschaulicht eine beispielhafte 2:32 zu 2:4 teilweise Dekomprimierungsanweisung, die im QUAD-Modus arbeitet. Im QUAD-Modus kann jeder eines Quad (Vierergruppe) von Threads eine teilweise Dekomprimierung für ein Viertel der N-Elementdatenstruktur bereitstellen. Mit anderen Worten erzeugt jeder Thread in dem Quad einen Satz der 2:4 Daten. In dem gezeigten Beispiel arbeitet jeder Thread auf seinem eigenen Satz von Registern.
Wie gezeigt, gibt die erste Anweisung (SCATTER.QUAD.partial R10, R2, R3, 0, 3) an, dass die N-Elementdatenstruktur in Register R2 gespeichert ist, die Metadaten in R3 gespeichert sind und mindestens ein Abschnitt des Inhalts von R2 in R10 dekomprimiert werden sollte. Ferner gibt der 0-Wert (für #VecIdx) an, dass R10 den Abschnitt der Ziel-M-Elementdatenstruktur mit Orten 7 ... 0 darstellt, wenn der Thread, der die erste Anweisung ausführt, einen ThreadID-Wert für einen ersten Quadranten aufweist (d.h., (ThreadID Modulus 4) == 0), mit Orten 15 ... 8 darstellt, wenn der Thread einen ThreadID-Wert für einen zweiten Quadranten (d.h., (ThreadID Modulus 4) == 1) aufweist, mit Orten 23 ... 16 darstellt, wenn der Thread einen ThreadID-Wert für einen dritten Quadranten aufweist (d.h., (ThreadID Modulus 4) == 2) und mit Orten 31 ... 24 darstellt, wenn der Thread einen ThreadID-Wert für einen vierten Quadranten aufweist (d.h., (ThreadID Modulus 4) == 3). Der 3-Wert (für #Maske) gibt den Abschnitt von R2 an, der zu dekomprimieren ist.
Wenn die erste Anweisung durch einen Thread mit einer ThreadID für den ersten Quadranten ausgeführt wird, wird Wert A von Register R2 in R10 kopiert. Außerdem wird, wenn die erste Anweisung durch einen Thread mit einer ThreadID für den zweiten Quadranten ausgeführt wird, kein Wert von Register R2 in R10 kopiert. Wenn die erste Anweisung durch einen Thread mit einer ThreadID für den dritten Quadranten ausgeführt wird, wird Wert B aus Register R2 in R10 kopiert. Schließlich wird, wenn die erste Anweisung durch einen Thread mit einer ThreadID für den vierten Quadrant ausgeführt wird, kein Wert aus Register R2 in R10 kopiert.
Außerdem wird die zweite Anweisung (spMETADATA.QUAD.U2 R11, R3, 0, 3, 0) auf ähnliche Weise, wie oben mit Bezugnahme auf 9 beschrieben, außer durch die Quad von Threads in dieser Ausführungsform ausgeführt. Somit wird der Thread, der den Wert A in seine Kopie von R10 schreibt, die neuen Metadaten für A in seine Kopie von R11 schreiben, und der Thread, der den Wert B in seine Kopie von R10 schreibt, wird die neuen Metadaten für B in seine Kopie von R11 schreiben.
Komprimierung von Daten
Die obige Beschreibung stellt Ausführungsformen für die vollständigen und teilweisen Dekomprimierungsanweisungen für Daten bereit. Wie jedoch oben bemerkt, arbeiten diese vollständigen und teilweisen Dekomprimierungsanweisungen an N-Element-Datenstrukturen, die durch Komprimieren einer M-Elementdatenstruktur erzeugt wurden. Die Komprimierung kann auf jede beliebige Weise ausgeführt werden, welche die Metadaten bereitstellt, die von den vollständigen und teilweisen Dekomprimierungsanweisungen benutzt werden.
Parallelverarbeitungsarchitektur
12 veranschaulicht eine Parallelverarbeitungseinheit (PPU) 1200 gemäß einer Ausführungsform. In einer Ausführungsform ist die PPU 1200 ein Multi-Threaded-Prozessor bzw. mehrsträngiger Prozessor, der auf einer oder mehreren integrierten Schaltungsvorrichtungen implementiert ist. Die PPU 1200 ist eine Latenz-verbergende Architektur, die ausgestaltet ist, um eine große Anzahl von Threads bzw. Strängen parallel zu verarbeiten. Ein Thread bzw. Strang (d.h. ein Ausführungsthread) ist eine Instanziierung eines Satzes von Anweisungen, die konfiguriert sind, um von der PPU 1200 ausgeführt zu werden. In einer Ausführungsform ist die PPU 1200 eine Graphikverarbeitungseinheit (GPU), die konfiguriert ist, um eine Graphik-Rendering-Pipeline zur Verarbeitung von dreidimensionalen (3D) Graphikdaten zu implementieren, um zweidimensionale (2D) Bilddaten zur Anzeige auf einer Anzeigevorrichtung, wie beispielsweise einer Flüssigkristallanzeige(LCD)-Vorrichtung, zu erzeugen. In anderen Ausführungsformen kann die PPU 1200 zum Durchführen von Allzweckberechnungen benutzt werden. Während ein beispielhafter paralleler Prozessor hier für veranschaulichende Zwecke bereitgestellt wird, sei nachdrücklich bemerkt, dass ein derartiger Prozessor lediglich für veranschaulichende Zwecke dargelegt wird und dass ein beliebiger Prozessor benutzt werden kann, um dasselbe zu ergänzen und/oder zu ersetzen.
Eine oder mehrere PPUs 1200 können konfiguriert sein, um Tausende von HPC(High Performing Computing)-, Datenzentrum- und Maschinenlern-Anwendungen zu beschleunigen. Die PPU 1200 kann konfiguriert sein, um zahlreiche Systeme und Anwendungen für tiefgehendes Lernen zu beschleunigen, die autonome Fahrzeugplattformen, tiefgehendes Lernen, hochgenaue Sprache, Bild- und Texterkennungssysteme, intelligente Videoanalyse, molekulare Simulationen, Wirkstoffentdeckung, Krankheitsdiagnose, Wettervorhersage, Analyse großer Datenmengen, Astronomie, Molekulardynamiksimulation, Finanzmodellierung, Robotertechnik, Fabrikautomation, Sprachübersetzung in Echtzeit, Online-Suchoptimierungen und personalisierte Benutzerempfehlungen und dergleichen umfassen.
Wie in 12 gezeigt, umfasst die PPU 1200 eine Eingabe/Ausgabe(E/A)-Einheit 1205, eine Frontend-Einheit 1215, eine Planer-Einheit 1220, eine Arbeitsverteilungs-Einheit 1225, einen Hub 1230, eine Kreuzschiene (Xbar) 1270, einen oder mehrere allgemeine Verarbeitungscluster (GPCs) 1250 und eine oder mehrere Partitions-Einheiten 1280. Die PPU 1200 kann mit einem Host-Prozessor oder anderen PPUs über einen Interconnect des Hochgeschwindigkeits-NVLink 1210 verbunden sein. Die PPU 1200 kann ebenfalls mit einem Host-Prozessor oder anderen peripheren Vorrichtungen über einen Interconnect 1202 verbunden sein. In einer Ausführungsform kann der lokale Speicher eine Anzahl von Direktzugriffsspeicher(DRAM)-Vorrichtungen umfassen. Die DRAM-Vorrichtungen können als ein HBM(Speicher mit hoher Bandbreite)-Subsystem konfiguriert sein, wobei mehrere DRAM-Dies innerhalb jeder Vorrichtung gestapelt sind.
Der Interconnect des NVLink 1210 ermöglicht Systemen, eine oder mehrere PPUs 1200 zu skalieren und zu umfassen, die mit einer oder mehreren CPUs kombiniert sind, unterstützt Cache-Kohärenz zwischen den PPUs 1200 und CPUs sowie CPU-Mastering. Daten und/oder Befehle können mittels des NVLink 1210 durch den Hub 1230 an/von anderen Einheiten der PPU 1200, wie beispielsweise eine oder mehrere Kopiermaschinen, einen Videocodierer, einen Videodecodierer, eine Leistungsverwaltungseinheit usw. (nicht explizit gezeigt) übertragen werden. Das NVLink 1210 wird ausführlicher in Verbindung mit 14B beschrieben.
Die E/A-Einheit 1205 ist konfiguriert, um Kommunikationen (d.h. Befehle, Daten usw.) von einem Host-Prozessor (nicht gezeigt) über den Interconnect 1202 zu übertragen und zu empfangen. Die E/A-Einheit 1205 kann mit dem Host-Prozessor direkt über den Interconnect 1202 oder durch eine oder mehrere Zwischenvorrichtungen, wie beispielsweise eine Speicherbrücke, kommunizieren. In einer Ausführungsform kann die E/A-Einheit 1205 mit einem oder mehreren anderen Prozessoren, wie beispielsweise eine oder mehrere der PPUs, über den Interconnect 1202 kommunizieren. In einer Ausführungsformen implementiert die E/A-Einheit 1205 eine PCIe(Peripheral Component Interconnect Express)-Schnittstelle für Kommunikationen über einen PCIe-Bus und der Interconnect 1202 ist ein PCIe-Bus. In alternativen Ausführungsformen kann die E/A-Einheit 1205 andere Typen von wohlbekannten Schnittstellen zum Kommunizieren mit externen Vorrichtungen umfassen.
Die E/A-Einheit 1205 decodiert Pakete, die über den Interconnect 1202 empfangen wurden. In einer Ausführungsform stellen die Pakete Befehle dar, die konfiguriert sind, um die PPU 1200 zu veranlassen, verschiedene Operationen durchzuführen. Die E/A-Einheit 1205 überträgt die decodierten Befehle an verschiedene andere Einheiten der PPU 1200, wie es die Befehle spezifizieren können. Beispielsweise können einige Befehle an die Frontend-Einheit 1215 übertragen werden. Andere Befehle können an den Hub 1230 oder andere Einheiten der PPU 1200, wie beispielsweise eine oder mehrere Kopiermaschinen, einen Video-Codierer, einen Video-Decodierer, eine Leistungsverwaltungseinheit usw. (nicht explizit gezeigt) übertragen werden. Mit anderen Worten ist die E/A-Einheit 1205 konfiguriert, um Kommunikationen zwischen und unter den verschiedenen logischen Einheiten der PPU 1200 weiterzuleiten.
In einer Ausführungsform codiert ein Programm, das von dem Host-Prozessor ausgeführt wird, einen Befehlsstrom in einem Puffer, welcher der PPU 1200 Arbeitslasten zur Verarbeitung bereitstellt. Eine Arbeitslast kann mehrere Anweisungen und Daten umfassen, die von diesen Anweisungen zu verarbeiten sind. Der Puffer ist eine Region in einem Speicher, der von sowohl dem Host-Prozessor als auch der PPU 1200 zugänglich ist (d.h. Lesen/Schreiben). Beispielsweise kann die Host-Schnittstelleneinheit 1205 konfiguriert sein, um auf den Puffer in einem Systemspeicher, der mit dem Interconnect 1202 verbunden ist, über Speicheranfragen, die über den Interconnect 1202 übertragen werden, zuzugreifen. In einer Ausführungsform schreibt der Host-Prozessor den Befehlsstrom in den Puffer und überträgt dann einen Zeiger zu dem Start des Befehlsstroms an die PPU 1200. Die Frontend-Einheit 1215 empfängt Zeiger auf einen oder mehrere Befehlsströme. Die Frontend-Einheit 1215 verwaltet den einen oder mehrere Ströme, liest Befehle von den Strömen und leitet Befehle an die verschiedenen Einheiten der PPU 1200 weiter.
Die Frontend-Einheit 1215 ist mit einer Planer-Einheit 1220 gekoppelt, welche die verschiedenen GPCs 1250 konfiguriert, um Aufgaben zu verarbeiten, die durch den einen oder mehrere Ströme definiert sind. Die Planer-Einheit 1220 ist konfiguriert, um Zustandsinformation zu verfolgen, die verschiedene Aufgaben betrifft, die von der Planer-Einheit 1220 verwaltet werden. Der Zustand kann angeben, welchem GPC 1250 eine Aufgabe zugewiesen ist, ob die Aufgabe aktiv oder inaktiv ist, ob ein Prioritätsniveau der Aufgabe zugeordnet ist und so weiter. Die Planer-Einheit 1220 verwaltet die Ausführung einer Mehrzahl von Aufgaben auf dem einen oder mehreren GPCs 1250.
Die Planer-Einheit 1220 ist mit einer Arbeitsverteilungs-Einheit 1225 gekoppelt, die konfiguriert ist, um Aufgaben zur Ausführung auf den GPCs 1250 zu versenden. Die Arbeitsverteilungs-Einheit 1225 kann eine Anzahl von eingeplanten Aufgaben verfolgen, die von der Planer-Einheit 1220 empfangen werden. In einer Ausführungsform verwaltet die Arbeitsverteilungs-Einheit 1225 einen Pool für anhängige Aufgaben und einen Pool für aktive Aufgaben für jeden der GPCs 1250. Der Pool für anhängige Aufgaben kann eine Anzahl von Schlitzen (z.B. 122 Schlitze) umfassen, die Aufgaben enthalten, die zugewiesen sind, um von einem bestimmten GPC 1250 verarbeitet zu werden. Der Pool für aktive Aufgaben kann eine Anzahl von Schlitzen (z.B. 4 Schlitze) für Aufgaben umfassen, die von den GPCs 1250 aktiv verarbeitet werden. Wenn ein GPC 1250 die Ausführung einer Aufgabe abschließt, wird diese Aufgabe aus dem Pool für aktive Aufgaben für den GPC 1250 geräumt und eine der anderen Aufgaben wird aus dem Pool für anhängige Aufgaben ausgewählt und zur Ausführung auf dem GPC 1250 eingeplant. Wenn eine aktive Aufgabe auf dem GPC 1250 inaktiv war, wie beispielsweise während darauf gewartet wird, dass eine Datenabhängigkeit behoben wird, dann kann die aktive Aufgabe aus dem GPC 1250 geräumt und zu dem Pool für anhängige Aufgaben zurückgeführt werden, während eine weitere Aufgabe in dem Pool für anhängige Aufgaben ausgewählt und zur Ausführung auf dem GPC 1250 eingeplant wird.
Die Arbeitsverteilungs-Einheit 1225 kommuniziert mit dem einen oder mehreren GPCs 1250 über eine Kreuzschiene bzw. XBar 1270. Die XBar 1270 ist ein Interconnect-Netzwerk, das viele der Einheiten der PPU 1200 mit anderen Einheiten der PPU 1200 koppelt. Beispielsweise kann die XBar 1270 konfiguriert sein, um die Arbeitsverteilungs-Einheit 1225 mit einem bestimmten GPC 1250 zu koppeln. Obwohl nicht explizit gezeigt, kann eine oder mehrere andere Einheiten der PPU 1200 ebenfalls mit der XBar 1270 über den Hub 1230 verbunden sein.
Die Aufgaben werden von der Planer-Einheit 1220 verwaltet und an einen GPC 1250 durch die Arbeitsverteilungs-Einheit 1225 versandt. Der GPC 1250 ist konfiguriert, um die Aufgabe zu verarbeiten und Ergebnisse zu erzeugen. Die Ergebnisse können von anderen Aufgaben innerhalb des GPC 1250 verbraucht werden, an einen unterschiedlichen GPC 1250 über die XBar 1270 weitergeleitet oder im Speicher 1204 gespeichert werden. Die Ergebnisse können in den Speicher 1204 über die Partitions-Einheiten 1280 geschrieben werden, die eine Speicherschnittstelle zum Lesen und Schreiben von Daten in/von dem Speicher 1204 implementieren. In einer Ausführungsform umfasst die PPU 1200 eine Anzahl U von Speicherpartitions-Einheiten 1280, die gleich der Anzahl von getrennten und unterschiedlichen Speichervorrichtungen 1204 ist, die mit der PPU 1200 gekoppelt sind. Eine Speicherpartitions-Einheit 1280 wird nachstehend ausführlicher in Verbindung mit 13B beschrieben.
In einer Ausführungsform führt ein Host-Prozessor einen Treiber-Kernel aus, der eine Anwendungsprogrammmier-Schnittstelle (API) implementiert, die einer oder mehreren Anwendungen ermöglicht, die auf dem Host-Prozessor ausgeführt werden, Operationen zur Ausführung auf der PPU 1200 einzuplanen. In einer Ausführungsform werden mehrere Rechenanwendungen gleichzeitig von der PPU 1200 ausgeführt und die PPU 1200 stellt Isolierung, Dienstqualität (QoS) und unabhängige Adressräume für die mehreren Rechenanwendungen bereit. Eine Anwendung kann Anweisungen (d.h. API-Aufrufe) erzeugen, welche den Treiber-Kernel veranlassen, eine oder mehrere Aufgaben zur Ausführung durch die PPU 1200 zu erzeugen. Der Treiberkernel gibt Aufgaben an einen oder mehrere Streams aus, die von der PPU 1200 verarbeitet werden. Jede Aufgabe kann eine oder mehrere Gruppen von in Beziehung stehender Threads umfassen, die hier als ein Warp bezeichnet werden. In einer Ausführungsform umfasst ein Warp 122 in Beziehung stehende Threads, die parallel ausgeführt werden können. Kooperierende Threads können sich auf eine Mehrzahl von Threads beziehen, die Anweisungen umfassen, um die Aufgabe durchzuführen, und die Daten durch einen gemeinsam benutzten Speicher austauschen können. Threads und kooperierende Threads werden ausführlicher in Verbindung mit 14A beschrieben.
13A veranschaulicht einen GPC 1250 der PPU 1200 von 12 gemäß einer Ausführungsform. Wie in 13A gezeigt, umfasst jeder GPC 1250 eine Anzahl von Hardwareeinheiten zur Verarbeitung von Aufgaben. In einer Ausführungsform umfasst jeder GPC 1250 einen Pipeline-Manager 410, eine Vor-Raster-Operationen-Einheit (PROP) 415, eine Raster-Engine 1325, eine Arbeitsverteilungs-Kreuzschiene (WDX) 480, eine Speicherverwaltungseinheit (MMU) 490 und einen oder mehrere Datenverarbeitungscluster (DPCs) 1320. Es wird anerkannt, dass der GPC 1250 von 13A andere Hardwareeinheiten anstelle von oder zusätzlich zu den in 13A gezeigten Einheiten umfassen kann.
In einer Ausführungsform wird der Betrieb des GPC 1250 durch den Pipeline-Manager 410 gesteuert. Der Pipeline-Manager 410 verwaltet die Konfiguration des einen oder mehrerer DPCs 1320 zur Verarbeitung von Aufgaben, die dem GPC 1250 zugeteilt sind. In einer Ausführungsform kann der Pipeline-Manager 410 mindestens einen des einen oder mehrerer DPCs 1320 konfigurieren, um mindestens einen Abschnitt einer Graphik-Rendering-Pipeline zu implementieren. Beispielsweise kann ein DPC 1320 konfiguriert sein, um ein Vertex-Shader-Programm auf dem programmierbaren Streaming-Multiprozessor (SM) 1340 auszuführen. Der Pipeline-Manager 410 kann ebenfalls konfiguriert sein, um Pakete, die von der Arbeitsverteilungs-Einheit 1225 empfangen werden, an die geeigneten logischen Einheiten innerhalb des GPC 1250 weiterzuleiten. Beispielsweise können einige Pakete an Festfunktions-Hardwareeinheiten in der PROP 415 und/oder der Raster-Engine 1325 weitergeleitet werden, während andere Pakete an die DPCs 1320 zur Verarbeitung durch die Primitiven-Engine 1335 oder den SM 1340 weitergeleitet werden können. In einer Ausführungsform kann der Pipeline-Manager 410 mindestens einen oder mehrere DPCs konfigurieren, um ein Neuronal-Netzwerkmodell und/oder eine Rechen-Pipeline zu implementieren.
Die PROP-Einheit 415 ist konfiguriert, um Daten, die von der Raster-Engine 1325 und den DPCs 1320 erzeugt werden, an eine Raster-Operationen-Einheit (ROP-Einheit) weiterzuleiten, die nachstehend ausführlicher beschrieben wird. Die PROP-Einheit 415 kann ebenfalls konfiguriert sein, um Optimierungen zur Farbenmischung durchzuführen, Pixeldaten zu organisieren, Adressenübersetzungen und dergleichen durchzuführen.
Die Raster-Engine 1325 umfasst eine Anzahl von Festfunktions-Hardwareeinheiten, die konfiguriert sind, um verschiedene Raster-Operationen durchzuführen. In einer Ausführungsform umfasst die Raster-Engine 1325 eine Setup-Engine, eine Grobraster-Engine, eine Aussonderungs-Engine, eine Abschneide-Engine, eine Feinraster-Engine und eine Kachel-verschmelzende Engine. Die Setup-Engine empfängt transformierte Vertices und erzeugt Ebenengleichungen, die den geometrischen Primitiven zugeordnet sind, die durch die Vertices definiert werden. Die Ebenengleichungen werden an die Grobraster-Engine übertragen, um Abdeckungsinformation (z.B. eine (x,y)-Abdeckungsmaske für eine Kachel) für die Primitive zu erzeugen. Die Ausgabe der Grobraster-Engine wird an die Aussonderungs-Engine übertragen, wo Fragmente, die der Primitiven zugeordnet sind, die einen z-Test nicht bestehen, ausgesondert und an eine Abschneide-Engine übertragen werden, wo Fragmente, die außerhalb eines Betrachtungsstumpfes liegen, abgeschnitten werden. Diejenigen Fragmente, welche die Abschneidung und Aussonderung überleben, können an eine Feinraster-Engine weitergeben werden, um Attribute für die Pixelfragmente basierend auf den Ebenengleichungen zu erzeugen, die durch die Setup-Engine erzeugt werden. Die Ausgabe der Raster-Engine 1325 umfasst Fragmente, die beispielsweise von einem Fragment-Shader zu verarbeiten sind, der innerhalb eines DPC 1320 implementiert ist.
Jeder DPC 1320, der in dem GPC 1250 umfasst ist, umfasst einen M-Pipe-Controller (MPC) 430, eine Primitiven-Engine 1335 und einen oder mehrere SMs 1340. Der MPC 430 steuert den Betrieb des DPC 1320, wobei von dem Pipeline-Manager 410 empfangene Pakete an die geeigneten Einheiten im DPC 1320 weiterleitet werden. Beispielsweise können einem Vertex zugeordnete Pakete an die Primitiven-Engine 1335 weitergeleitet werden, die konfiguriert ist, um der Vertex zugeordnete Vertexattribute von dem Speicher 1204 zu holen. Im Gegensatz dazu können einem Shader-Programm zugeordnete Pakete an den SM 1340 übertragen werden.
Der SM 1340 umfasst einen programmierbaren Streaming-Prozessor, der konfiguriert ist, um Aufgaben zu verarbeiten, die durch eine Anzahl von Threads dargestellt werden. Jeder SM 1340 umfasst mehrere Threads (ist multi-threaded) und ist konfiguriert, um eine Mehrzahl von Threads (z.B. 122 Threads) von einer bestimmten Gruppe von Threads nebenläufig auszuführen. In einer Ausführungsform implementiert der SM 1340 eine SIMD(Einzelne-Anweisung, Mehrere-Daten)-Architektur, wobei jeder Thread in einer Gruppe von Threads (d.h. einem Warp) konfiguriert ist, um einen unterschiedlichen Satz von Daten basierend auf dem gleichen Satz von Anweisungen zu verarbeiten. Alle Threads in der Gruppe von Threads führen die gleichen Anweisungen aus. In einer anderen Ausführungsform implementiert der SM 1340 eine SIMT(Einzelne Anweisung, Mehrere Threads)-Architektur, wobei jeder Thread in einer Gruppe von Threads konfiguriert ist, um einen unterschiedlichen Satz von Daten basierend auf dem gleichen Satz von Anweisungen zu verarbeiten, wobei jedoch einzelnen Threads in der Gruppe von Threads ermöglicht wird, während der Ausführung zu divergieren. In einer Ausführungsform wird ein Programmzähler, ein Aufrufstapel und ein Ausführungszustand für jeden Warp beibehalten, was eine Nebenläufigkeit zwischen Warps und eine serielle Ausführung innerhalb Warps ermöglicht, wenn Threads innerhalb des Warp divergieren. In einer weiteren Ausführungsform wird ein Programmzähler, ein Aufrufstapel und ein Ausführungszustand für jeden einzelnen Thread beibehalten, was eine gleiche Nebenläufigkeit zwischen allen Threads, innerhalb und zwischen Warps ermöglicht. Wenn der Ausführungszustand für jeden einzelnen Thread beibehalten wird, können Threads, welche die gleichen Anweisungen ausführen, konvergiert und für maximale Effizienz parallel ausgeführt werden. Der SM 1340 wird ausführlicher nachstehend in Verbindung mit 14A beschrieben.
Die MMU 490 stellt eine Schnittstelle zwischen dem GPC 1250 und der Partitions-Einheit 1280 bereit. Die MMU 490 kann eine Übersetzung von virtuellen Adressen in physische Adressen, einen Speicherschutz und eine Arbitrierung von Speicheranfragen bereitstellen. In einer Ausführungsform stellt die MMU 490 einen oder mehrere Adressenübersetzungspuffer (TLBs = translation lookaside buffers) zum Durchführen der Übersetzung von virtuellen Adressen in physische Adressen in dem Speicher 1204 bereit.
13B veranschaulicht eine Speicherpartitions-Einheit 1280 der PPU 1200 von 12 gemäß einer Ausführungsform. Wie in 13B gezeigt, umfasst die Partitions-Einheit 1280 eine Raster-Operationen(ROP)-Einheit 1350, einen L2-Cache-Speicher 1360 und eine Speicherschnittstelle 1370. Die Speicherschnittstelle 1370 ist mit dem Speicher 1204 gekoppelt. Die Speicherschnittstelle 1370 kann 32-, 64-, 128-, 1024-Bit-Datenbusse oder dergleichen für Hochgeschwindigkeits-Datentransfer implementieren. In einer Ausführungsform umfasst die PPU 1200 U Speicherschnittstellen 1370, eine Speicherschnittstelle 1370 pro Paar von Speicherpartitions-Einheiten 1280, wobei jedes Paar von Speicherpartitions-Einheiten 1280 mit einer entsprechenden Speichervorrichtung 1204 verbunden ist. Beispielsweise kann die PPU 1200 mit bis zu Y Speichervorrichtungen 1204, wie beispielsweise Speicherstapel mit hoher Bandbreite oder Graphikdoppeldatenraten, Version 5 SDRAM oder andere Typen von persistenter Speicherung verbunden sein.
In einer Ausführungsform implementiert die Speicherschnittstelle 1370 eine HBM2-Speicherschnittstelle und Y ist gleich einem halben U. In einer Ausführungsform sind die HBM2-Speicherstapel auf der gleichen physischen Packung wie die PPU 1200 lokalisiert, die wesentliche Leistungs- und Flächeneinsparungen verglichen mit herkömmlichen GDDR5 SDRAM Systemen bereitstellt. In einer Ausführungsform umfasst jeder HBM2-Stapel vier Speicher-Dies und Y ist gleich 4, wobei der HBM2-Stapel zwei 128-Bit Kanäle pro Die für eine Gesamtzahl von 8 Kanälen und eine Datenbusbreite von 1024 Bit umfasst.
In einer Ausführungsform unterstützt der Speicher 1204 Fehlerkorrekturcode (ECC) mit Einzelfehlerkorrektur und Doppelfehlerdetektion (SECDED), um Daten zu schützen. Der ECC stellt eine höhere Zuverlässigkeit für Rechenanwendungen bereit, die gegen Datenverfälschung empfindlich sind. Zuverlässigkeit ist besonders wichtig in großen Cluster-Rechenumgebungen, wo PPUs 1200 sehr große Datensätze verarbeiten und/oder Anwendungen für längere Zeiträume ausführen.
In einer Ausführungsform implementiert die PPU 1200 eine Mehrebenen-Speicherhierarchie. In einer Ausführungsform unterstützt die Speicherpartitions-Einheit 1280 einen vereinheitlichten Speicher, um einen einzigen vereinheitlichten virtuellen Adressraum für den Speicher der CPU und den Speicher der PPU 1200 bereitzustellen, der Datenteilung zwischen virtuellen Speichersystemen ermöglicht. In einer Ausführungsform wird die Häufigkeit von Zugriffen durch eine PPU 1200 auf einen Speicher, der auf anderen Prozessoren lokalisiert ist, verfolgt, um sicherzustellen, dass Speicherseiten in den physischen Speicher der PPU 1200 bewegt werden, die häufiger auf die Seiten zugreift. In einer Ausführungsform unterstützt das NVLink 1210 Adressenübersetzungsdienste, die der PPU 1200 erlauben, auf Seitentabellen einer CPU direkt zuzugreifen und einen vollen Zugriff auf den CPU-Speicher durch die PPU 1200 bereitstellen.
In einer Ausführungsform transferieren Kopiermaschinen Daten zwischen mehreren PPUs 1200 oder zwischen PPUs 1200 und CPUs. Die Kopiermaschinen können Seitenfehler für Adressen erzeugen, die nicht in den Seitentabellen abgebildet werden. Die Speicherpartitions-Einheit 1280 kann dann die Seitenfehler bedienen, wobei die Adressen in der Seitentabelle abgebildet werden, nachdem die Kopiermaschine den Transfer durchführen kann. In einem herkömmlichen System ist der Speicher für mehrere Kopiermaschinenoperationen zwischen mehreren Prozessoren gesperrt (d.h. nicht auslagerbar), was den verfügbaren Speicher wesentlich verringert. Mit Hardware-Seiten-Faulting können Adressen an die Kopiermaschinen weitergeleitet werden, ohne sich Sorgen zu machen, ob die Speicherseiten resident sind und das Kopierverfahren transparent ist.
Daten von dem Speicher 1204 oder einem anderen Systemspeicher können von der Speicherpartitions-Einheit 1280 geholt und in dem L2-Cache-Speicher 1360 gespeichert werden, der Auf-Chip lokalisiert ist und zwischen den verschiedenen GPCs 1250 gemeinsam benutzt wird. Wie gezeigt, umfasst jede Speicherpartitions-Einheit 1280 einen Bereich des L2-Cache-Speichers 1360, der einer entsprechenden Speichervorrichtung 1204 zugeordnet ist. Cache-Speicher niedrigerer Ebene können dann in verschiedenen Einheiten innerhalb der GPCs 1250 implementiert werden. Beispielsweise kann jeder der SMs 1340 einen L1-Cache-Speicher implementieren. Der L1-Cache-Speicher ist ein privater Speicher, der einem bestimmten SM 1340 fest zugeordnet ist. Daten von dem L2-Cache-Speicher 1360 können geholt und in jedem der L1-Cache-Speicher zur Verarbeitung in den Funktionseinheiten der SMs 1340 gespeichert werden. Der L2-Cache-Speicher 1360 ist mit der Speicherschnittstelle 1370 und der XBar 1270 gekoppelt.
Die ROP-Einheit 1350 führt Graphik-Raster-Operationen durch, welche die Pixelfarbe betreffen, wie beispielsweise Farbenkomprimierung, Pixelmischung und dergleichen. Die ROP-Einheit 1350 implementiert ebenfalls Tiefentesten in Verbindung mit der Raster-Engine 1325, wobei eine Tiefe für einen Abtastort, der einem Pixelfragment zugeordnet ist, von der Aussonderungs-Engine der Raster-Engine 1325 empfangen wird. Die Tiefe wird gegen eine entsprechende Tiefe in einem Tiefenpuffer für einen Abtastort geprüft, der dem Fragment zugeordnet ist. Wenn das Fragment den Tiefentest für den Abtastort besteht, dann aktualisiert die ROP-Einheit 1350 den Tiefenpuffer und überträgt ein Ergebnis des Tiefentests an die Raster-Engine 1325. Es wird anerkannt, dass sich die Anzahl von Speicherpartitions-Einheiten 1280 von der Anzahl von GPCs 1250 unterscheiden kann, und daher kann jede ROP-Einheit 1350 mit jedem der GPCs 1250 gekoppelt werden. Die ROP-Einheit 1350 verfolgt Pakete, die von den unterschiedlichen GPCs 1250 empfangen werden, und bestimmt, zu welchem GPC 1250 ein durch die ROP-Einheit 1350 erzeugtes Ergebnis durch die Xbar 1370 weitergeleitet wird. Obwohl die ROP-Einheit 1350 innerhalb der Speicherpartitions-Einheit 1280 in 13B umfasst ist, kann die ROP-Einheit 1350 außerhalb der Speicherpartitions-Einheit 1280 sein. Beispielsweise kann die ROP-Einheit 1350 in dem GPC 1250 oder einer anderen Einheit liegen.
14A veranschaulicht den Streaming-Multiprozessor 1340 von 13A gemäß einer Ausführungsform. Wie in 14A gezeigt, umfasst der SM 1340 einen Anweisungs-Cache-Speicher 1405, eine oder mehrere Planer-Einheiten 1410, eine Registerdatei 1420, einen oder mehrere Verarbeitungskerne 1450, eine oder mehrere Spezialfunktionseinheiten (SFUs) 1452, eine oder mehrere Lade/Speicher-Einheiten (LSUs) 1454, ein Interconnect-Netzwerk 1480 und einen gemeinsam benutzten L1-Cache-Speicher 1470.
Wie oben beschrieben, versendet die Arbeitsverteilungs-Einheit 1225 Aufgaben zur Ausführung auf den GPCs 1250 der PPU 1200. Die Aufgaben werden einem bestimmten DPC 1320 innerhalb eines GPC 1250 zugeteilt, und wenn die Aufgabe einem Shader-Programm zugeordnet ist, kann die Aufgabe einem SM 1340 zugeteilt werden. Die Planer-Einheit 1410 empfängt die Aufgaben von der Arbeitsverteilungs-Einheit 1225 und verwaltet die Anweisungs-Planung (instruction scheduling) für einen oder mehrere Thread-Blöcke, die dem SM 1340 zugewiesen sind. Die Planer-Einheit 1410 plant Thread-Blöcke zur Ausführung als Warps von parallelen Threads, wobei jeder Thread-Block mindestens einem Warp zugeordnet ist. In einer Ausführungsform führt jeder Warp 122 Threads aus. Die Planer-Einheit 1410 kann eine Mehrzahl von unterschiedlichen Thread-Blöcken verwalten, welche die Warps den unterschiedlichen Thread-Blöcken zuordnet und dann Anweisungen von der Mehrzahl von unterschiedlichen kooperativen Gruppen an die verschiedenen Funktionseinheiten (d.h. Kerne 1450, SFUs 1452 und LSUs 1454) während jedes Taktzyklus versendet.
Cooperative Groups ist ein Programmiermodell zum Organisieren von Gruppen von kommunizierenden Threads, die Entwicklern ermöglicht, die Granularität auszudrücken, bei der Threads kommunizieren, wobei der Ausdruck von reicheren, effizienten Parallelzerlegungen ermöglicht wird. Cooperative-Start-APIs unterstützen die Synchronisierung unter Thread-Blöcken für die Ausführung von parallelen Algorithmen. Herkömmliche Programmiermodelle stellen einen einzigen, einfachen Aufbau zum Synchronisieren von kooperierenden Threads bereit: eine Barriere über alle Threads eines Threadblocks (d.h. die Funktion syncthreads( )). Programmierer würden jedoch häufig gerne Gruppen von Threads bei kleineren als Thread-Block-Granularitäten definieren und innerhalb der definierten Gruppen synchronisieren, um größere Leistung, Gestaltungsflexibilität und Software-Wiederverwendung in der Form von kollektiven gruppenweiten Funktionsschnittstellen zu ermöglichen.
Cooperative Groups ermöglicht Programmierern, Gruppen von Threads explizit bei Sub-Block(d.h. so klein wie ein einziger Thread)- und Mehr-Block-Granularitäten zu definieren und kollektive Operationen, wie beispielsweise Synchronisierung, an den Threads in einer kooperativen Gruppe durchzuführen. Das Programmiermodell unterstützt eine saubere Zusammensetzung über Softwaregrenzen, so dass Bibliotheken und Hilfsfunktionen innerhalb ihres lokalen Kontexts sicher synchronisieren können, ohne Annahmen über Konvergenz machen zu müssen. Cooperative-Groups-Primitive ermöglichen neue Muster von kooperativer Parallelität, die Erzeuger-Verbraucher Parallelität, opportunistische Parallelität und globale Synchronisierung über ein gesamtes Gitter von Threadblöcken umfassen.
Eine Versandeinheit 1415 ist konfiguriert, um Anweisungen an eine oder mehrere der Funktionseinheiten zu übertragen. In der Ausführungsform umfasst die Planer-Einheit 1410 zwei Versandeinheiten 1415, die ermöglichen, dass zwei unterschiedliche Anweisungen von dem gleichen Warp während jedes Taktzyklus versandt werden. In alternativen Ausführungsformen kann jede Planer-Einheit 1410 eine einzige Versandeinheit 1415 oder zusätzliche Versandeinheiten 1415 umfassen.
Jeder SM 1340 umfasst eine Registerdatei 1420, die einen Satz von Registern für die Funktionseinheiten des SM 1340 bereitstellt. In einer Ausführungsform ist die Registerdatei 1420 zwischen jeder der Funktionseinheiten aufgeteilt, so dass jeder Funktionseinheit ein zugehöriger Abschnitt der Registerdatei 1420 zugeteilt ist. In einer anderen Ausführungsform ist die Registerdatei 1420 zwischen den unterschiedlichen Warps aufgeteilt, die von dem SM 1340 ausgeführt werden. Die Registerdatei 1420 stellt temporäre Speicherung für Operanden bereit, die mit den Datenpfaden der Funktionseinheiten verbunden sind.
Jeder SM 1340 umfasst L Verarbeitungskerne 1350. In einer Ausführungsform umfasst der SM 1340 eine große Anzahl (z.B., 128, usw.) von unterschiedlichen Verarbeitungskernen 1350. Jeder Kern 1350 kann eine vollständig in einer Pipeline angeordnete (fülly-pipelined) Einfach-Präzisions- Verarbeitungseinheit umfassen, die eine Gleitkommaarithmetik-Logikeinheit und eine Ganzzahlarithmetik-Logikeinheit umfasst. In einer Ausführungsform implementieren die Gleitkommaarithmetik-Logikeinheiten den IEEE 754-12008 Standard für Gleitkommaarithmetik. In einer Ausführungsform umfassen die Kerne 1450 64 Einfach-Präzisions-(122-Bit)-Gleitkommakerne, 64 Integer-Kerne, 122 Doppel-Präzisions-(64-Bit)-Gleitkommakeme und 8 Tensorkerne.
Tensorkerne, die konfiguriert sind, um Matrix-Operationen durchzuführen, und in einer Ausführungsform ein oder mehrere Tensorkerne sind in den Kernen 1450 umfasst. Insbesondere sind die Tensorkerne konfiguriert, um tiefgehendes Lernen-Matrix-Arithmetik, wie beispielsweise Faltungsoperationen für neuronales Netzwerktraining und Inferenzieren, durchzuführen. In einer Ausführungsform arbeitet jeder Tensorkern an einer 4x4 Matrix und führt eine Matrix-Multiplikations- und Akkumulations-Operation D=A×B+C durch, wobei A, B, C und D 4×4 Matrizen sind.
In einer Ausführungsform sind die Matrix-Multiplikations-Eingaben A und B 16-Bit-Gleitkomma-Matrizen, während die Akkumulationsmatrizen C und D 16-Bit-Gleitkomma- oder 122-Bit-Gleitkomma-Matrizen sein können. Tensorkerne arbeiten an 16-Bit-Gleitkomma-Eingabedaten mit 122-Bit-Gleitkomma-Akkumulation. Die 16-Bit-Gleitkomma-Multiplikation erfordert 64 Operationen und ergibt ein Produkt voller Präzision, das dann unter Verwendung einer 122-Bit-Gleitkomma-Addition mit den anderen Zwischenprodukten für eine 4x4x4-Matrix-Multiplikation akkumuliert wird. In der Praxis werden Tensorkerne verwendet, um viel größere zweidimensionale oder höherdimensionale Matrixoperationen durchzuführen, die von diesen kleineren Elementen aufgebaut werden. Eine API, wie beispielsweise die CUDA 9 C++ API, stellt spezialisierte Matrix-Lade-, Matrix-Multiplikations- und Matrix-Akkumulations- und Matrix-Speicher-Operationen bereit, um Tensorkerne von einem CUDA-C++ Programm effizient zu verwenden. Bei der CUDA-Ebene nimmt das Warp-Schnittstellenniveau 16x16 große Matrizen an, die alle 122 Threads des Warp überspannen.
Jeder SM 1340 umfasst ebenfalls M SFUs 1452, die Sonderfunktionen durchführen (z.B. Attributauswertung, reziproke Quadratwurzel und dergleichen). In einer Ausführungsform können die SFUs 1452 eine Baumtraversierungseinheit umfassen, die konfiguriert ist, um eine hierarchische Baumdatenstruktur zu durchlaufen. In einer Ausführungsform können die SFUs 1452 eine Textureinheit umfassen, die konfiguriert ist, um Texturkarten-Filteroperationen durchzuführen. In einer Ausführungsform sind die Textureinheiten konfiguriert, um Texturkarten (z.B. eine 2D-Anordnung von Texeln) von dem Speicher 1204 zu laden und die Texturkarten abzutasten, um abgetastete Texturwerte zum Gebrauch in Shader-Programmen zu erzeugen, die durch den SM 1340 ausgeführt werden. In einer Ausführungsform werden die Texturkarten in dem gemeinsam benutzten Speicher/L1-Cache-Speicher 1370 gespeichert. Die Textureinheiten implementieren Texturoperationen, wie beispielsweise Filteroperationen, unter Verwendung von Mip-Maps (d.h. Texturkarten von veränderlichem Detaillierungsgrad). In einer Ausführungsform umfasst jeder SM 1240 zwei Textureinheiten.
Jeder SM 1340 umfasst ebenfalls N LSUs 1454, die Lade- und Speicheroperationen zwischen dem gemeinsam benutzten Speicher/L1-Cache-Speicher 1470 und der Registerdatei 1420 implementieren. Jeder SM 1340 umfasst ein Interconnect-Netzwerk 1480, das jede der Funktionseinheiten mit der Registerdatei 1420 und die LSU 1454 mit der Registerdatei 1420, dem gemeinsam benutzten Speicher/ L1-Cache-Speicher 1470 verbindet. In einer Ausführungsform ist das Interconnect-Netzwerk 1480 eine Kreuzschiene, die konfiguriert sein kann, um irgendeine der Funktionseinheiten mit irgendeinem der Register in der Registerdatei 1420 zu verbinden und die LSUs 1454 mit der Registerdatei und Speicherorten im gemeinsam benutzten Speicher/L1-Cache-Speicher 1470 zu verbinden.
Der gemeinsam benutzte Speicher/L1-Cache-Speicher 1470 ist eine Auf-Chip-Speicheranordnung, die Datenspeicherung und Kommunikation zwischen dem SM 1340 und der Primitiven-Engine 1335 und zwischen Threads in dem SM 1340 ermöglicht. In einer Ausführungsform umfasst der gemeinsam benutzte Speicher/L1-Cache-Speicher 1470 128KB von Speicherkapazität und ist in dem Pfad von dem SM 1340 zu der Partitions-Einheit 1280. Der gemeinsam benutzte Speicher/L1-Cache-Speicher 1470 kann verwendet werden, um Lese- und Schreibvorgänge zwischen zu speichern. Einer oder mehrere der gemeinsam benutzten Speicher/L1-Cache-Speicher 1470, L2-Cache-Speicher 1360 und Speicher 1204 sind Hintergrundspeicher.
Das Kombinieren eines Daten-Cache und gemeinsam benutzter Speicherfunktionalität in einem einzigen Speicherblock stellt die beste Gesamtleistung für beide Arten von Speicherzugriffen bereit. Die Kapazität ist als ein Cache von Programmen benutzbar, die den gemeinsam benutzten Speicher nicht verwenden. Wenn der gemeinsam benutzte Speicher beispielsweise konfiguriert ist, die Hälfte der Kapazität zu verwenden, können Textur- und Lade/Speicher-Operationen die verbleibende Kapazität verwenden. Integration innerhalb des gemeinsam benutzten Speichers/L1-Cache-Speicher 1470 ermöglicht dem gemeinsam benutzten Speicher/L1-Cache-Speicher 1470 als eine Leitung mit hohem Durchsatz zum Streamen von Daten zu arbeiten, während gleichzeitig eine höhere Bandbreite und ein latenzarmer Zugriff auf häufig wiederverwendete Daten bereitgestellt werden.
Wenn für Allzweck-Parallelberechnung konfiguriert wird, kann im Vergleich mit der Graphikverarbeitung eine einfachere Konfiguration verwendet werden. Im Einzelnen werden die in 12 gezeigten Festfunktions-Graphikverarbeitungseinheiten umgangen, wobei ein viel einfacheres Programmiermodell erzeugt wird. In der Allzweck-Parallelberechnungs-Konfiguration werden Blöcke von Threads von der Arbeitsverteilungs-Einheit 1225 direkt den DPCs 1320 zugewiesen und verteilt. Die Threads in einem Block führen das gleiche Programm unter Verwendung einer eindeutigen Thread-ID in der Berechnung, um sicherzustellen, dass jeder Thread eindeutige Ergebnisse erzeugt, unter Verwendung des SM 1340, um das Programm auszuführen und Berechnungen durchzuführen, eines gemeinsam benutzten Speicher/L1-Cache-Speichers 1470, um zwischen Threads zu kommunizieren, und der LSU 1454 aus, um globalen Speicher durch den gemeinsam benutzten Speicher/L1-Cache-Speicher 1470 und die Speicherpartitions-Einheit 1280 zu lesen und zu beschreiben. Wenn für Allzweck-Parallelberechnung konfiguriert, kann der SM 1340 ebenfalls Befehle schreiben, welche die Planer-Einheit 1220 verwenden kann, um neue Arbeit auf den DPCs 1320 zu starten.
Die PPU 1200 kann in einem Tischcomputer, einem Laptop-Computer, einem Tablet-Computer, einem Smartphone (z.B. einer drahtlosen handgehaltenen Vorrichtung), einem persönlichen digitalen Assistenten (PDA), einer Digitalkamera, einer handgehaltenen elektronischen Vorrichtung und dergleichen umfasst sein. In einer Ausführungsform ist die PPU 1200 auf einem einzelnen Halbleitersubstrat verkörpert. In einer anderen Ausführungsform ist die PPU 1200 in einem System-auf-Chip (SoC) zusammen mit einer oder mehreren anderen Vorrichtungen, wie beispielsweise zusätzlichen PPUs 1200, dem Speicher 1204, einem Rechner-mit-reduziertem-Befehlssatz(RISC)-CPU, einer Speicherverwaltungseinheit (MMU), einem Digital/Analog-Wandler (DAC) und dergleichen umfasst.
In einer Ausführungsform kann die PPU 1200 auf einer Graphikkarte umfasst sein, die eine oder mehrere Speichervorrichtungen 1204 umfasst. Die Graphikkarte kann konfiguriert sein, um sich mit einem PCIe-Schlitz auf einer Hauptplatine eines Tischcomputers schnittstellenmäßig zu verbinden. In noch einer anderen Ausführungsform kann die PPU 1200 eine integrierte Graphikverarbeitungseinheit (iGPU) oder ein Parallelprozessor sein, der in dem Chipsatz der Hauptplatine umfasst ist.
Beispielhaftes Rechensystem
Systeme mit mehrere GPUs und CPUs werden in einer Vielfalt von Industrien verwendet, da Entwickler mehr Parallelität in Anwendungen, wie beispielsweise Rechnen für künstliches Intelligenz, freilegen und wirksam einsetzen. Hochleistungs-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 von Verarbeitungsvorrichtungen innerhalb der Hochleistungssysteme zunimmt, müssen die Kommunikations- und Datentransfermechanismen angepasst werden, um die erhöhte Bandbreite zu unterstützen.
14B ist ein Konzeptdiagramm eines Verarbeitungssystems 1400, das unter Verwendung der PPU 1200 von 12 implementiert wird, gemäß einer Ausführungsform. Das beispielhafte System 1465 kann konfiguriert sein, um das in 1 gezeigte Verfahren 100 und oder das in 2A gezeigte Verfahren 200 zu implementieren. Das Verarbeitungssystem 1400 umfasst eine CPU 1430, einen Schalter 1410 und jeweils mehrere PPUs 1200 und jeweilige Speicher 1204. Das NVLink 1210 stellt Hochgeschwindigkeits-Kommunikationslinks zwischen jeder der PPUs 1200 bereit. Obwohl eine bestimmte Anzahl von Verbindungen des NVLink 1210 und des Interconnect 1202 in 14B veranschaulicht werden, kann die Anzahl von Verbindungen zu jeder PPU und der CPU 1430 variieren. Der Schalter 1410 verbindet sich schnittstellenmäßig zwischen dem Interconnect 1202 und der CPU 1430. Die PPUs 1200, die Speicher 1204 und die NVLinks 1210 können auf einer einzigen Halbleiterplattform gelegen sein, um ein Parallelverarbeitungsmodul 1425 zu bilden. In einer Ausführungsform unterstützt der Schalter 1410 zwei oder mehrere Protokolle, um sich schnittstellenmäßig zwischen verschiedenen unterschiedlichen Verbindungen und/oder Links zu verbinden.
In einer anderen Ausführungsform (nicht gezeigt) stellt das NVLink 1210 ein oder mehrere Hochgeschwindigkeits-Kommunikationslinks zwischen jeder der PPUs 1200 und der CPU 1430 bereit und der Schalter 1410 ist schnittstellenmäßig zwischen dem Interconnect 1202 und jeder der PPUs 1200 verbunden. Die PPUs 1200, die Speicher 1204 und der Interconnect 1202 können auf einer einzigen Halbleiterplattform situiert sein, um ein Parallelverarbeitungsmodul 1425 zu bilden. In noch einer anderen Ausführungsform (nicht gezeigt) stellt der Interconnect 1202 ein oder mehrere Kommunikationslinks zwischen jeder der PPUs 1200 und der CPU 1430 bereit und der Schalter 1410 ist schnittstellenmäßig zwischen jeder der PPUs 1200 unter Verwendung des NVLink 1210 verbunden, um ein oder mehrere Hochgeschwindigkeits-Kommunikationslinks zwischen den PPUs 1200 bereitzustellen. In einer anderen Ausführungsform (nicht gezeigt) stellt das NVLink 1210 ein oder mehrere Hochgeschwindigkeits-Kommunikationslinks zwischen den PPUs 1200 und der CPU 1430 durch den Schalter 1410 bereit. In noch einer anderen Ausführungsform (nicht gezeigt) stellt der Interconnect 1202 ein oder mehrere Hochgeschwindigkeits-Kommunikationslinks zwischen jeder der PPUs 1200 direkt bereit. Ein oder mehrere der NVLink 1210 Hochgeschwindigkeits-Kommunikationslinks können als ein physischer NVLink-Interconnect oder entweder als ein Auf-Chip- oder Auf-Die-Interconnect unter Verwendung des gleichen Protokolls wie das NVLink 1210 implementiert werden.
Im Kontext der vorliegenden Beschreibung kann sich eine einzige Halbleiterplattform auf eine einzelne unitäre Halbleiter-basierte integrierte Schaltung beziehen, die auf einem Die oder Chip angefertigt ist. Es sei bemerkt, dass sich der Begriff einzige Halbleiterplattform ebenfalls auf Mehr-Chip-Module mit erhöhter Konnektivität beziehen kann, die eine Auf-Chip-Operation simulieren und die wesentlichen Verbesserungen gegenüber der Benutzung einer herkömmlichen Busimplementierung vornehmen. Natürlich können die verschiedenen Schaltungen oder Vorrichtungen ebenfalls getrennt oder in verschiedenen Kombinationen von Halbleiterplattformen gemäß den Wünschen des Benutzers situiert sein. Alternativ kann das Parallelverarbeitungsmodul 1425 als ein Leiterplattensubstrat implementiert sein und jede der PPUs 1200 und/oder Speicher 1204 können verpackte Vorrichtungen sein. In einer Ausführungsform sind die CPU 1430, der Schalter 1410 und das Parallelverarbeitungsmodul 1425 auf einer einzigen Halbleiterplattform situiert.
In einer Ausführungsform ist die Signalrate von jedem NVLink 1210 gleich 20 bis 25 Gigabit/s und jede PPU 1200 umfasst sechs NVLink 1210 Schnittstellen (wie in 14B gezeigt, fünf NVLink 1210 Schnittstellen sind für jede PPU 1200 umfasst). Jedes NVLink 1210 stellt eine Datentransferrate von 25 Gigabyte/s in jeder Richtung bereit, wobei sechs Verknüpfungen 1200 Gigabyte/s bereitstellen. Die NVLinks 1210 können exklusiv für PPU-zu-PPU Kommunikation, wie in 14B gezeigt, oder einer Kombination von PPU-zu-PPU und PPU-zu-CPU verwendet werden, wenn die CPU 1430 ebenfalls eines oder mehrere NVLink 1210 Schnittstellen umfasst.
In einer Ausführungsform ermöglicht das NVLink 1210 einen direkten Lade/Speicher/atomaren Zugriff der CPU 1430 auf jeden Speicher 1204 der PPU 1200. In einer Ausführungsform unterstützt das NVLink 1210 Kohärenzoperationen, die ermöglichen, das von dem Speicher 1204 gelesene Daten in der Cache-Hierarchie der CPU 1430 gespeichert werden können, was die Cachezugriffslatenz für die CPU 1430 verringert. In einer Ausführungsform umfasst das NVLink 1210 Unterstützung für Address Translation Services (ATS), was der PPU 1200 ermöglicht, auf Seitentabellen innerhalb der CPU 1430 direkt zuzugreifen. Eines oder mehrere der NVLinks 1210 können ebenfalls konfiguriert sein, um in einem Niedrigleistungsmodus zu arbeiten.
14C veranschaulicht ein beispielhaftes System 1465, bei dem die verschiedene Architektur und/oder Funktionalität der verschiedenen vorherigen Ausführungsformen implementiert werden kann. Das beispielhafte System 1465 kann konfiguriert sein, um das in 1 gezeigte Verfahren 100 und/oder das Verfahren 200 zu implementieren.
Wie gezeigt, wird ein System 1465 bereitgestellt, das mindestens eine zentrale Verarbeitungseinheit 1430 umfasst, die mit einem Kommunikationsbus 1475 verbunden ist. Der Kommunikationsbus 1475 kann unter Verwendung jedes geeigneten Protokolls, wie beispielsweise PCI (Peripheral Component Interconnect), PCI-Express, AGP (Accelerated Graphics Port), Hyper-Transport oder irgendeinem anderen Bus- oder Punkt-zu-Punkt-Kommunikationsprotokoll(en), implementiert sein. Das System 1465 umfasst ebenfalls einen Hauptspeicher 1440. Steuerlogik (Software) und Daten werden in dem Hauptspeicher 1440 gespeichert, der die Form eines Direkt-Zugriffs-Speichers (RAM) annehmen kann.
Das System 1465 umfasst ebenfalls Eingabevorrichtungen 1460, das Parallelverarbeitungssystem 1425 und Anzeigevorrichtungen 1445, d.h. eine herkömmliche CRT (Kathodenstrahlröhre), eine LCD (Flüssigkristallanzeige), eine LED (lichtemittierende Diode), eine Plasmaanzeige oder dergleichen. Eine Benutzereingabe kann von den Eingabevorrichtungen 1460, z.B. Tastatur, Maus, Berührfeld, Mikrophon und dergleichen empfangen werden. Jedes der vorhergehenden Module und/oder Vorrichtungen kann sogar auf einer einzigen Halbleiterplattform situiert sein, um das System 1465 zu bilden. Alternativ können die verschiedenen Module ebenfalls getrennt oder in verschiedenen Kombinationen von Halbleiterplattformen gemäß den Wünschen des Benutzers situiert sein.
Ferner kann das System 1465 mit einem Netzwerk (z.B. einem Telekommunikationsnetzwerk, Lokalbereichsnetzwerk (LAN), drahtlosen Netzwerk, Weitbereichsnetzwerk (WAN), wie beispielsweise dem Internet, Peer-zu-Peer-Netzwerk, Kabelnetzwerk oder dergleichen) durch eine Netzwerkschnittstelle 1435 für Kommunikationszwecke gekoppelt sein.
Das System 1465 kann ebenfalls einen Sekundärspeicher umfassen (nicht gezeigt). Der Sekundärspeicher 1510 umfasst beispielsweise ein Festplattenlaufwerk und/oder ein entfernbares Speicherlaufwerk, das ein Diskettenlaufwerk darstellt, ein Magnetbandlaufwerk, ein Kompaktdisklaufwerk, ein DVD(digitale versatile disk)-Laufwerk, eine Aufzeichnungsvorrichtung und einen Universal-Serial-Bus-(USB)-Flash-Speicher. Das entfernbare Speicherlaufwerk liest von und/oder schreibt auf eine entfernbare Speichereinheit auf eine wohlbekannte Art und Weise.
Computerprogramme oder Computersteuerlogik-Algorithmen können in dem Hauptspeicher 1440 und/oder dem Sekundärspeicher gespeichert sein. Derartige Computerprogramme, wenn ausgeführt, ermöglichen dem System 1465, verschiedene Funktionen durchzuführen. Der Speicher 1440, die Speicherung, und/oder jede andere Speicherung sind mögliche Beispiele von computerlesbaren Medien.
Die Architektur und/oder Funktionalität der verschiedener vorherigen Figuren kann im Kontext eines allgemeinen Computersystems, eines Schaltungsplatinensystems, eines Unterhaltungszwecken fest zugeordneten Spielkonsolensystems, eines anwendungsspezifischen Systems und/oder jedem anderen gewünschten System implementiert sein. Beispielsweise kann das System 1465 die Form eines Tischcomputers, eines Laptop-Computers, eines Tablet-Computers, von Servern, von Supercomputern, eines Smartphones (z.B. einer drahtlosen handgehaltenen Vorrichtung), eines persönlichen digitalen Assistenten (PDA), einer Digitalkamera, eines Fahrzeugs, einer am Kopf angebrachten Anzeige, einer handgehaltenen elektronischen Vorrichtung, eines mobilen Telefongeräts, eines Fernsehers, einer Arbeitsstation, einer Spielkonsole, eines eingebetteten Systems und/oder von jedem anderen Typ von Logik annehmen.
Während verschiedene Ausführungsformen oben beschrieben wurden, sei zu verstehen, dass sie lediglich beispielhaft und nicht begrenzend präsentiert wurden. Somit sollte die Breite und der Umfang einer bevorzugten Ausführungsform nicht durch irgendeine der oben beschriebenen beispielhaften Ausführungsformen begrenzt werden, sondern sollte nur durch die folgenden Ansprüche und ihrer Äquivalente definiert werden.
Graphikverarbeitungs-Pipeline
In einer Ausführungsform umfasst die PPU 1200 eine Graphikverarbeitungseinheit (GPU). Die PPU 1200 ist konfiguriert, um Befehle zu empfangen, die Shader-Programme zur Verarbeitung von Graphikdaten spezifizieren. Graphikdaten können als ein Satz von Primitiven, wie beispielsweise Punkte, Linien, Dreiecke, Vierecke, Dreieckstreifen und dergleichen, definiert sein. Typischerweise umfasst eine Primitive Daten, die eine Anzahl von Vertices für die Primitive (z.B., in einem Modellraum-Koordinatensystem) sowie auch Attribute spezifizieren, die jedem Vertex der Primitive zugeordnet sind. Die PPU 1200 kann konfiguriert sein, um die Graphikprimitive zu verarbeiten, um ein Frame-Puffer zu erzeugen (d.h. Pixeldaten für jedes der Pixel der Anzeige).
Eine Anwendung schreibt Modelldaten für eine Szene (d.h. eine Sammlung von Vertices und Attributen) in einen Speicher, wie beispielsweise einen Systemspeicher oder Speicher 1204. Die Modelldaten definieren jedes der Objekte, die auf einer Anzeige sichtbar sein können. Die Anwendung führt dann einen API-Aufruf an dem Treiber-Kernel aus, der die Modelldaten anfragt, die zu rendern und anzuzeigen sind. Der Treiber-Kernel liest die Modelldaten und schreibt Befehle an den einen oder mehrere Ströme, um Operationen durchzuführen, um die Modelldaten zu verarbeiten. Die Befehle können unterschiedliche Shader-Programme referenzieren, die auf den SMs 1340 der PPU 1200 zu implementieren sind, die einen oder mehrere eines Vertex-Shader, Hull-Shader, Domain-Shader, Geometrie-Shader und eines Pixel-Shader umfassen können. Beispielsweise können eine oder mehrere der SMs 1340 konfiguriert sein, um ein Vertex-Shader-Programm auszuführen, das eine Anzahl von Vertices verarbeitet, die durch die Modelldaten definiert sind. In einer Ausführungsform können die unterschiedlichen SMs 1340 konfiguriert sein, um unterschiedliche Shader-Programme nebenläufig auszuführen. Beispielsweise kann eine erste Untermenge von SMs 1340 konfiguriert sein, ein Vertex-Shader-Programm auszuführen, während eine zweite Untermenge von SMs 1340 konfiguriert sein kann, ein Pixel-Shader-Programm auszuführen. Die erste Untermenge von SMs 1340 verarbeitet Vertexdaten, um verarbeitete Vertexdaten zu erzeugen, und schreibt die verarbeiteten Vertexdaten in den L2-Cache-Speicher 1360 und/oder den Speicher 1204. Nachdem die verarbeiteten Vertexdaten gerastert sind (d.h. von dreidimensionalen Daten in zweidimensionale Daten im Bildschirmraum transformiert sind), um Fragmentdaten zu erzeugen, führt die zweite Untermenge von SMs 1340 einen Pixel-Shader aus, um verarbeitete Fragmentdaten zu erzeugen, die dann mit anderen verarbeiteten Fragmentdaten gemischt werden und in den Frame-Puffer im Speicher 1204 geschrieben werden. Das Vertex-Shader-Programm und das Pixel-Shader-Programm können nebenläufig ausgeführt werden, wobei unterschiedliche Daten von der gleichen Szene in einem Pipeline-Verfahren verarbeitet werden, bis alle der Modelldaten für die Szene gerenderten zu dem Frame-Puffer gerendert wurden. Dann wird der Inhalt des Frame-Puffers an einen Anzeigencontroller zur Anzeige auf einer Anzeigevorrichtung übertragen.
15 ist ein Konzeptdiagramm einer von der PPU 1200 von 12 implementierten Graphikverarbeitungs-Pipeline 1500 gemäß einer Ausführungsform. Die Graphikverarbeitungs-Pipeline 1500 ist ein abstraktes Ablaufdiagramm der Verarbeitungsschritte, die implementiert werden, um 2D-Computer-erzeugte Bilder aus 3D-Geometriedaten zu erzeugen. Wie bekannt ist, können Pipeline-Architekturen Operationen mit langer Latenz effizienter durch Aufteilen der Operation in eine Mehrzahl von Stufen durchführen, wobei die Ausgabe jeder Stufe mit dem Eingang der nächsten aufeinanderfolgenden Stufe gekoppelt ist. Somit empfängt die Graphikverarbeitungs-Pipeline 1500 Eingabedaten 1501, die von einer Stufe an die nächste Stufe der Graphikverarbeitungs-Pipeline 1500 übertragen werden, um Ausgabedaten 1502 zu erzeugen. In einer Ausführungsform kann die Graphikverarbeitungs-Pipeline 1500 eine Graphikverarbeitungs-Pipeline darstellen, die durch die OpenGL^® API definiert ist. Als eine Option kann die Graphikverarbeitungs-Pipeline 1500 im Kontext der Funktionalität und Architektur der vorherigen Figuren und/oder etwaiger nachfolgenden Figur(en) implementiert werden.
Wie in 15 gezeigt, umfasst die Graphikverarbeitungs-Pipeline 1500 eine Pipeline-Architektur, die eine Anzahl von Stufen umfasst. Die Stufen umfassen, sind jedoch nicht beschränkt auf, eine Datenanordnungs-Stufe 1510, eine Vertex-Shading-Stufe 1520, eine Primitivenanordnungs-Stufe 1530, eine Geometrie-Shading-Stufe 1540, eine Darstellungsfeld-Skalierungs-, Aussonderungs- und Abschneide-(VSCC)-Stufe 1550, eine Rasterungs-Stufe 1560, eine Fragment-Shading-Stufe 1570 und eine Raster-Operationen-Stufe 1580. In einer Ausführungsform umfassen die Eingabedaten 1501 Befehle, welche die Verarbeitungseinheiten konfigurieren, um die Stufen der Graphikverarbeitungs-Pipeline 1500 zu implementieren, und geometrische Primitive (z.B., Punkte, Linien, Dreiecke, Vierecke, Dreieckstreifen oder Fächer, usw.), die mittels der Stufen zu verarbeiten sind. Die Ausgabedaten 1502 können Pixeldaten (d.h. Farbdaten) umfassen, die in einen Frame-Puffer oder einen anderen Typ von Oberflächen-Datenstruktur in einem Speicher kopiert werden.
Die Datenanordnungs-Stufe 1510 empfängt die Eingabedaten 1501, die Vertexdaten für Oberflächen höherer Ordnung, Primitive oder dergleichen spezifizieren. Die Datenanordnungs-Stufe 1510 sammelt die Vertexdaten in einem temporären Speicher oder Warteschlange, wie beispielsweise durch Empfangen eines Befehls von dem Host-Prozessor, der einen Zeiger auf einen Puffer im Speicher umfasst und die Vertexdaten aus dem Puffer liest. Die Vertexdaten werden dann an die Vertex-Shading-Stufe 1520 zur Verarbeitung übertragen.
Die Vertex-Shading-Stufe 1520 verarbeitet Vertexdaten durch Durchführen eines Satzes von Operationen (d.h. eines Vertex-Shader oder eines Programms) einmal für jede der Vertices. Vertices können beispielsweise als ein 4-Koordinaten-Vektor (d.h. <x, y, z, w>) spezifiziert sein, der einem oder mehreren Vertexattributen (z.B., Farbe, Texturkoordinaten, Oberflächennormalen, usw.) zugeordnet ist. Die Vertex-Shading-Stufe 1520 kann einzelne Vertexattribute, wie beispielsweise Position, Farbe, Texturkoordinaten und dergleichen, manipulieren. Mit anderen Worten führt die Vertex-Shading-Stufe 1520 Operationen an den Vertex-Koordinaten oder anderen Vertexattributen durch, welche einem Vertex zugeordnet sind. Derartige Operationen umfassen gewöhnlicherweise Beleuchtungs-Operationen (d.h. Modifizieren von Farbattributen für einen Vertex) und Transformations-Operationen (d.h. Modifizieren des Koordinatenraums für einen Vertex). Beispielsweise können Vertices unter Verwendung von Koordinaten in einem Objekt-Koordinatenraum spezifiziert sein, die durch Multiplizieren der Koordinaten mittels einer Matrix transformiert werden, welche die Koordinaten aus dem Objekt-Koordinatenraum in einen Welt-Raum oder einen normierten Vorrichtungskoordinaten(NCD = Normalized Device Coordinates)-Raum übersetzt. Die Vertex-Shading-Stufe 1520 erzeugt transformierte Vertexdaten, die an die Primitivenanordnungs-Stufe 1530 übertragen werden.
Die Primitivenanordnungs-Stufe 1530 sammelt Vertices, die mittels der Vertex-Shading-Stufe 1520 ausgegeben werden, und gruppiert die Vertices in geometrische Primitive zur Verarbeitung durch die Geometrie-Shading-Stufe 1540. Beispielsweise kann die Primitivenanordnungs-Stufe 1530 konfiguriert sein, um alle drei aufeinanderfolgenden Vertices als eine geometrische Primitive (d.h. ein Dreieck) zur Übertragung an die Geometrie-Shading-Stufe 1540 zu gruppieren. In einigen Ausführungsformen können spezifische Vertices für aufeinanderfolgende geometrische Primitive erneut verwendet werden (z.B. können zwei aufeinanderfolgende Dreiecke in einem Dreieckstreifen zwei Vertices gemeinsam benutzen). Die Primitivenanordnungs-Stufe 1530 überträgt geometrische Primitive (d.h. eine Sammlung von zugeordneten Vertices) an die Geometrie-Shading-Stufe 1540.
Die Geometrie-Shading-Stufe 1540 verarbeitet geometrische Primitive durch Durchführen eines Satzes von Operationen (d.h. eines Geometrie-Shader oder Programms) an den geometrischen Primitiven. Tessellations-Operationen können eine oder mehrere geometrische Primitive aus jeder geometrischen Primitive erzeugen. Mit anderen Worten kann die Geometrie-Shading-Stufe 1540 jede geometrische Primitive in ein feineres Netz von zwei oder mehreren geometrischen Primitiven zur Verarbeitung durch den Rest der Graphikverarbeitungs-Pipeline 1500 unterteilen. Die Geometrie-Shading-Stufe 1540 überträgt geometrische Primitive an die Darstellungsfeld-SCC-Stufe 1550.
In einer Ausführungsform kann die Graphikverarbeitungs-Pipeline 1500 innerhalb eines Streaming-Multiprozessors arbeiten und die Vertex-Shading-Stufe 1520, die Primitivenanordnungs-Stufe 1530, die Geometrie-Shading-Stufe 1540, die Fragment-Shading-Stufe 1570 und/oder die damit zugeordnete Hardware/Software kann sequenziell Verarbeitungsoperationen durchführen. Sobald die sequenziellen Verarbeitungsoperationen in einer Ausführungsform abgeschlossen sind, kann die Darstellungsfeld-SCC-Stufe 1550 die Daten benutzen. In einer Ausführungsform können Primitivendaten, die durch eine oder mehrere der Stufen in der Graphikverarbeitungs-Pipeline 1500 verarbeitet wurden, in einen Cache-Speicher (z.B. einen L1-Cache-Speicher, einen Vertex-Cache-Speicher usw.) geschrieben werden. In diesem Fall kann in einer Ausführungsform die Darstellungsfeld-SCC-Stufe 1550 auf die Daten in dem Cache-Speicher zugreifen. In einer Ausführungsform sind die Darstellungsfeld-SCC-Stufe 1550 und die Rasterungs-Stufe 1560 als Festfunktionsschaltungen implementiert.
Die Darstellungsfeld-SCC-Stufe 1550 führt Darstellungsfeld-Skalierung, Aussonderung und Abschneidung der geometrischen Primitive durch. Jede Oberfläche, die gerendert wird, wird einer abstrakten Kameraposition zugeordnet. Die Kameraposition stellt einen Ort eines Betrachters dar, der die Szene betrachtet, und definiert einen Betrachtungsstumpf, der die Objekte der Szene einschließt. Der Betrachtungsstumpf kann eine Betrachtungsebene, eine hintere Ebene und vier Abschneideebenen umfassen. Jede geometrische Primitive, die vollständig außerhalb des Betrachtungsstumpfes ist, kann ausgesondert (d.h. verworfen) werden, weil die geometrische Primitive nicht zu der endgültigen gerenderten Szene beitragen wird. Jede geometrische Primitive, die innerhalb des Betrachtungsstumpfs und teilweise außerhalb des Betrachtungsstumpf ist, kann abgeschnitten werden (d.h. in eine neue geometrische Primitive transformiert werden, die innerhalb des Betrachtungsstumpf eingeschlossen ist). Des Weiteren können geometrische Primitive jeweils basierend auf einer Tiefe des Betrachtungsstumpfes skaliert werden. Alle potenziell sichtbaren geometrischen Primitive werden dann an die Rasterungs-Stufe 1560 übertragen.
Die Rasterungs-Stufe 1560 wandelt die 3D-geometrischen Primitive in 2D-Fragmente um (die z.B. in der Lage sind, zur Anzeige benutzt zu werden, usw.). Die Rasterungs-Stufe 1560 kann konfiguriert sein, um die Vertices der geometrischen Primitive zu benutzen, um einen Satz von Ebenengleichungen aufzustellen, von denen verschiedene Attribute interpoliert werden können. Die Rasterungs-Stufe 1560 kann ebenfalls eine Abdeckungsmaske für eine Mehrzahl von Pixeln berechnen, die angibt, ob eine oder mehrere Abtastorte für das Pixel die geometrische Primitive schneiden. In einer Ausführungsform kann auch z-Testen durchgeführt werden, um zu bestimmen, ob die geometrische Primitive von anderen geometrischen Primitiven verdeckt wird, die bereits gerastert wurden. Die Rasterungs-Stufe 1560 erzeugt Fragmentdaten (d.h. interpolierte Vertexattribute, die einem bestimmten Abtastort für jedes abgedeckte Pixel zugeordnet sind), die an die Fragment-Shading-Stufe 1570 übertragen werden.
Die Fragment-Shading-Stufe 1570 verarbeitet Fragmentdaten durch Durchführen eines Satzes von Operationen (d.h. eines Fragment-Shader oder eines Programms) an jedem der Fragmente. Die Fragment-Shading-Stufe 1570 kann Pixeldaten (d.h. Farbenwerte) für das Fragment erzeugen, wie beispielsweise durch Durchführen von Beleuchtungs-Operationen oder Abtasten von Texturabbildungen unter Verwendung von interpolierten Texturkoordinaten für das Fragment. Die Fragment-Shading-Stufe 1570 erzeugt Pixeldaten, die an die Raster-Operationen-Stufe 1580 übertragen werden.
Die Rasteroperationen-Stufe 1580 kann verschiedene Operationen an den Pixeldaten durchführen, wie beispielsweise Alpha-Tests, Stencil-Tests und Mischung der Pixeldaten mit anderen Pixeldaten, die anderen Fragmente entsprechen, die dem Pixel zugeordnet sind. Wenn die Raster-Operationen-Stufe 1580 die Verarbeitung der Pixeldaten (d.h. der Ausgabedaten 1502) beendet hat, können die Pixeldaten in ein Render-Ziel, wie beispielsweise einen Frame-Puffer, einen Farbenpuffer oder dergleichen, geschrieben werden.
Es wird anerkannt, dass eine oder mehrere zusätzliche Stufen in der Graphikverarbeitungs-Pipeline 1500 zusätzlich zu oder anstatt einer oder mehrerer der oben beschriebenen Stufen umfasst sein können. Verschiedene Implementierungen der abstrakten Graphikverarbeitungs-Pipeline können unterschiedliche Stufen implementieren. Des Weiteren können eine oder mehrere der oben beschriebenen Stufen der Graphikverarbeitungs-Pipeline in einigen Ausführungsformen (wie beispielsweise der Geometrie-Shading-Stufe 1540) ausgeschlossen sein. Andere Arten von Graphikverarbeitungs-Pipelines werden betrachtet, als innerhalb des Schutzumfangs der vorliegenden Offenbarung zu liegen. Des Weiteren können beliebige der Stufen der Graphikverarbeitungs-Pipeline 1500 von einer oder mehreren dedizierten Hardwareeinheiten innerhalb eines Graphikprozessors, wie beispielsweise der PPU 1200, implementiert werden. Andere Stufen der Graphikverarbeitungs-Pipeline 1500 können durch programmierbare Hardwareeinheiten, wie beispielsweise dem SM 1340 der PPU 1200, implementiert werden.
Die Graphikverarbeitungs-Pipeline 1500 kann über eine Anwendung implementiert werden, die von einem Host-Prozessor, wie beispielsweise einer CPU, ausgeführt wird. In einer Ausführungsform kann ein Vorrichtungstreiber eine Anwendungsprogrammierschnittstelle (API) implementieren, die verschiedene Funktionen definiert, die von einer Anwendung benutzt werden können, um graphische Daten zur Anzeige zu erzeugen. Der Vorrichtungstreiber ist ein Softwareprogramm, das eine Mehrzahl von Befehlen umfasst, die den Betrieb der PPU 1200 steuern. Die API stellt eine Abstraktion für einen Programmierer bereit, die einem Programmierer erlaubt, spezialisierte Graphikhardware zu benutzen, wie beispielsweise die PPU 1200, um die graphischen Daten zu erzeugen, ohne zu verlangen, dass der Programmierer den spezifischen Befehlssatz für die PPU 1200 benutzen muss. Die Anwendung kann einen API-Aufruf umfassen, der an den Vorrichtungstreiber für die PPU 1200 weitergeleitet wird. Der Vorrichtungstreiber interpretiert den API-Aufruf und führt verschiedene Operationen durch, um auf den API-Aufruf zu antworten. In einigen Fällen kann der Vorrichtungstreiber Operationen durch Ausführen von Befehlen auf der CPU 550 durchführen. In anderen Fällen kann der Vorrichtungstreiber Operationen, zumindest teilweise, durch Starten von Operationen auf der PPU 1200 durchführen, wobei eine Eingabe/Ausgabe-Schnittstelle zwischen der CPU und der PPU 1200 benutzt wird. In einer Ausführungsform ist der Vorrichtungstreiber konfiguriert, um die Graphikverarbeitungs-Pipeline 1500 unter Benutzung der Hardware der PPU 1200 zu implementieren.
Verschiedene Programme können innerhalb der PPU 1200 ausgeführt werden, um die verschiedenen Stufen der Graphikverarbeitungs-Pipeline 1500 zu implementieren. Beispielsweise kann der Vorrichtungstreiber ein Kernel auf der PPU 1200 starten, um die Vertex-Shading-Stufe 1520 auf einem SM 1340 (oder mehreren SMs 1340) durchzuführen. Der Vorrichtungstreiber (oder den von der PPU 1200 ausgeführten Anfangskernel) kann ebenfalls andere Kernels auf der PPU 1200 starten, um andere Stufen der Graphikverarbeitungs-Pipeline 1500 durchzuführen, wie beispielsweise die Geometrie-Shading-Stufe 1540 und die Fragment-Shading-Stufe 1570. Außerdem können einige der Stufen der Graphikverarbeitungs-Pipeline 1500 auf einer festen Hardwareeinheit implementiert werden, wie beispielsweise einem Rasterer oder einem Daten-Assembler, der innerhalb der PPU 1200 implementiert ist. Es wird anerkannt, dass Ergebnisse von einem Kernel durch eine oder mehrere intervenierende Festfunktions-Hardwareeinheiten verarbeitet werden können, bevor sie von einem nachfolgenden Kernel auf einem SM 1340 verarbeitet werden.
Maschinenlernen
Tiefe neuronale Netzwerke (DNNs), die auf Prozessoren entwickelt wurden, wie beispielsweise der PPU 1200, wurden für diverse Verwendungsfälle, von selbstfahrenden Wagen bis schnellerer Wirkstoffentwicklung, von automatischer Bildbeschriftung in Online-Bilddatenbanken bis smarter Echtzeit-Sprachenübersetzung in Video-Chat-Anwendungen verwendet. tiefgehendes Lernen ist eine Technik, welche das neuronale Lernverfahren des menschlichen Gehirns modelliert, kontinuierlich lernt, kontinuierlich immer smarter wird und genauere Ergebnisse schneller im Laufe der Zeit liefert. Ein Kind wird anfangs von einem Erwachsenen unterrichtet, verschiedene Formen korrekt zu identifizieren und zu klassifizieren, um schließlich imstande zu sein, Formen ohne irgendeine Nachhilfe zu identifizieren. Auf ähnliche Weise muss ein System für tiefgehendes Lernen oder ein System für neuronales Lernen in Objekterkennung und Klassifizierung trainiert werden, damit es smarter und effizienter beim Identifizieren von Grundobjekten, verdeckten Objekte usw. wird, während ebenfalls Objekten Kontext zugewiesen wird.
Auf der einfachsten Ebene schauen Neuronen im menschlichen Gehirn auf verschiedene Eingaben, die empfangen werden, wobei Wichtigkeitsgrade jeder dieser Eingaben zugewiesen werden und eine Ausgabe an andere Neuronen weitergeleitet wird, um auf diese zu wirken. Ein künstliches Neuron oder ein Perzeptron ist das grundlegendste Modell eines neuronalen Netzwerks. In einem Beispiel kann ein Perzeptron eine oder mehrere Eingaben empfangen, die verschiedene Merkmale eines Objekts darstellen, die das Perzeptron trainiert wird, zu erkennen und zu klassifizieren, und jedem dieser Merkmale wird ein bestimmtes Gewicht basierend auf der Wichtigkeit des Merkmals beim Definieren der Gestalt eines Objekts zugewiesen.
Ein Modell eines tiefen neuronalen Netzwerks (DNN) umfasst mehrere Schichten von vielen verbundenen Perzeptronen (z.B. Knoten), die mit enormen Mengen an Eingabedaten trainiert werden können, um komplexe Probleme mit hoher Genauigkeit schnell zu lösen. In einem Beispiel gliedert eine erste Schicht des DNN-Modells ein Eingabebild eines Automobils in verschiedene Abschnitte auf und sucht nach Grundmustern, wie beispielsweise Linien und Winkel. Die zweite Schicht setzt die Linien zusammen, um nach Mustern höherer Ebene, wie beispielsweise Rädern, Windschutzscheiben und Spiegeln, zu suchen. Die nächste Schicht kennzeichnet den Typ des Fahrzeugs und die letzten paar Schichten erzeugen ein Etikett für das Eingabebild, welches das Modell einer speziellen Automobilmarke kennzeichnet.
Sobald das DNN trainiert ist, kann das DNN eingesetzt und verwendet werden, um Objekte oder Muster in einem als Inferenz bekannten Verfahren zu identifizieren und zu klassifizieren. Beispiele von Inferenz (der Prozess, durch den ein DNN nützliche Information von einer gegebenen Eingabe extrahiert) umfassen ein Identifizieren handgeschriebener Zahlen auf Schecks, die in Geldausgabe-Maschinen eingezahlt werden, ein Identifizieren von Bildern von Freunden in Photos, Liefern von Filmempfehlungen an über fünfzig Millionen Nutzern, Identifizieren und Klassifizieren unterschiedlicher Typen von Automobilen, Fußgängern und Straßengefahren in fahrerlosen Wagen oder Übersetzen von menschlicher Sprache in Echtzeit.
Während des Trainings strömen Daten durch das DNN in einer Vorwärtspropagierungsphase, bis eine Vorhersage erzeugt wird, die ein Etikett angibt, das der Eingabe entspricht. Wenn das neuronale Netzwerk die Eingabe nicht korrekt kennzeichnet, dann werden Fehler zwischen dem korrekten Etikett und dem vorhergesagten Etikett analysiert und die Gewichte werden für jedes Merkmal während einer Rückwärtspropagierungsphase eingestellt, bis das DNN die Eingabe und andere Eingaben in einem Trainingsdatensatz korrekt kennzeichnet. Das Training komplexer neuronaler Netzwerke erfordert enorme Mengen an paralleler Rechenleistung, die Gleitkomma-Multiplikationen und Gleitkomma-Additionen umfassen, die von der PPU 1200 unterstützt werden. Inferenzieren ist weniger rechenintensiv als Training, das ein Latenz-empfindliches Verfahren ist, wobei ein trainiertes neuronales Netzwerk auf neue Eingaben angewandt wird, die es zuvor nicht gesehen hat, um Bilder zu klassifizieren, Sprache zu übersetzen und im Allgemeinen neue Informationen abzuleiten.
Neuronale Netzwerke stützen sich sehr auf Matrixrechenoperationen und komplexe mehrschichtige Netzwerke erfordern enorme Mengen an Gleitkomma-Leistung und Bandbreite für sowohl Effizienz als auch Geschwindigkeit. Mit Tausenden von Verarbeitungskernen, die für Matrixrechenoperationen optimiert sind und liefern von zehn bis hunderten von TFLOPS von Leistung, ist die PPU 1200 eine Rechenplattform, die imstande ist, Leistung zu liefern, die für tiefe Neuronal-Netzwerk-basierte künstliche Intelligenz und Maschinenlernanwendungen erforderlich ist.

Claims

Verfahren zum Dekomprimieren von komprimierten Daten, umfassend: Empfangen als Eingabe mindestens eines Abschnitts einer N-Elementdatenstruktur, wobei die N-Elementdatenstruktur durch Komprimieren einer ursprünglichen M-Elementdatenstruktur erzeugt wurde, wobei jedes Element in der N-Elementdatenstruktur einen Wert hält und wobei N<M; Empfangen als Eingabe mindestens eines Abschnitts von der der N-Elementdatenstruktur zugeordneten Metadaten, wobei die Metadaten für jeden Wert in der N-Elementdatenstruktur einen Ort spezifizieren, wo der Wert in der ursprünglichen M-Elementdatenstruktur entstanden ist; Kennzeichnen mindestens eines Abschnitts einer Ziel-M-Elementdatenstruktur; und Ausführen mindestens einer Anweisung, um mindestens einen Abschnitt der N-Elementdatenstruktur in die Ziel-M-Elementdatenstruktur zu komprimieren, durch: Schreiben in die Ziel-M-Elementdatenstruktur eines oder mehrerer Werte der N-Elementdatenstruktur unter Verwendung der eingegebenen Metadaten.
Verfahren gemäß Anspruch 1, wobei: die N-Elementdatenstruktur ein N-Elementvektor ist und wobei die M-Elementdatenstruktur ein M Elementvektor ist, oder die N-Elementdatenstruktur ein N-Elementtensor ist und wobei die M-Elementdatenstruktur ein M-Elementtensor ist.
Verfahren gemäß Anspruch 1 oder 2, wobei das Kennzeichnen der Ziel-M-Elementdatenstruktur ferner das Initialisieren der Ziel-M-Elementdatenstruktur durch Setzen jedes Elements in der Ziel-M-Elementdatenstruktur auf Null umfasst.
Verfahren gemäß einem der vorangehenden Ansprüche, wobei das Kennzeichnen der Ziel-M-Elementdatenstruktur ferner das Initialisieren der Ziel-M-Elementdatenstruktur durch Setzen jedes Elements in der Ziel-M-Elementdatenstruktur auf Werte von einer anderen M-Elementdatenstruktur umfasst.
Verfahren gemäß einem der vorangehenden Ansprüche, wobei das Kennzeichnen der Ziel-M-Elementdatenstruktur ferner das Initialisieren der Ziel-M-Elementdatenstruktur durch Setzen jedes Elements in der Ziel-M-Elementdatenstruktur auf Werte von einer Auswahl von M Elementen aus einer Gruppe von Datenstrukturen umfasst.
Verfahren gemäß einem der vorangehenden Ansprüche, wobei das Ausführen mindestens einer Anweisung das Ausführen einer Anweisung von einem einzelnen Thread oder in einer einzelnen Ausführungsspur umfasst.
Verfahren gemäß Anspruch 6, wobei der einzelne Thread oder die einzelne Ausführungsspur eine einzelne Instanz der Ziel-M-Elementdatenstruktur verwendet.
Verfahren gemäß einem der vorangehenden Ansprüche, wobei das Ausführen mindestens einer Anweisung das Ausführen einer Anweisung von einer Mehrzahl von Threads oder in mehreren Ausführungsspuren umfasst.
Verfahren gemäß Anspruch 8, wobei die Mehrzahl von Threads oder Ausführungsspuren in Gruppen aufgeteilt ist und jede Gruppe eine unterschiedliche Instanz der Ziel-M-Elementdatenstruktur verwendet.
Verfahren gemäß Anspruch 8, wobei die Mehrzahl von Threads oder Ausführungsspuren mindestens eines gemeinsam nutzen von: einer einzelnen Instanz der N-Elementdatenstruktur und einer einzelnen Instanz der Ziel-M-Elementdatenstruktur.
Nichttransitorisches computerlesbares Medium, das einen durch einen Prozessor ausführbaren Code speichert, um ein Verfahren zum Dekomprimieren komprimierter Daten durchzuführen, wie in einem der Ansprüche 1 bis 10 erwähnt.
System zum Dekomprimieren komprimierter Daten, umfassend: einen Speicher; und mindestens einen Prozessor zum Ausführen eines Verfahrens, wie in einem der Ansprüche 1 bis 10 erwähnt.
Verfahren zum teilweisen Dekomprimieren komprimierter Daten, umfassend: Empfangen als Eingabe mindestens eines Abschnitts einer N-Elementdatenstruktur, wobei die N-Elementdatenstruktur durch Komprimieren einer ursprünglichen M-Elementdatenstruktur erzeugt wurde, wobei jedes Element in der N-Elementdatenstruktur einen Wert hält und wobei N<M; Empfangen als Eingabe mindestens eines Abschnitts der den N-Elementdatenstruktur zugeordneten Metadaten, wobei die Metadaten für jeden Wert in der N-Elementdatenstruktur einen Ort spezifizieren, wo der Wert in der ursprünglichen M-Elementdatenstruktur entstanden ist; Kennzeichnen von mindestens zwei Ziel-R-Elementdatenstrukturen, wobei N<=R<M; und Ausführen mindestens einer Anweisung, um die N-Elementdatenstruktur in die mindestens zwei Ziel-R-Elementdatenstrukturen zu dekomprimieren, durch: Speichern von mindestens jeweils zwei Abschnitten der eingegebenen N-Elementdatenstruktur in einer entsprechenden der mindestens zwei Ziel-R-Elementdatenstrukturen.
Verfahren gemäß Anspruch 13, wobei die N-Elementdatenstruktur ein N-Elementvektor ist und wobei die mindestens zwei Ziel-R-Elementdatenstrukturen jeweils ein R-Elementvektor sind, oder die N-Elementdatenstruktur ein N-Elementtensor ist und wobei die mindestens zwei Ziel-R-Elementdatenstrukturen jeweils ein R-Elementtensor sind.
Verfahren gemäß Anspruch 13 oder 14, wobei das Kennzeichnen der mindestens zwei Ziel-R-Elementdatenstrukturen ferner ein Initialisieren der mindestens zwei Ziel-R-Elementdatenstrukturen durch Setzen jedes Elements in die mindestens zwei Ziel-R-Elementdatenstrukturen auf Null umfasst.
Verfahren gemäß einem der Ansprüche 13 bis 15, wobei das Kennzeichnen der mindestens zwei Ziel-R-Elementdatenstrukturen ferner ein Initialisieren der mindestens zwei Ziel-R-Elementdatenstrukturen durch Setzen jedes Elements in der mindestens zwei Ziel-R-Elementdatenstruktur auf Werte von einer anderen R-Elementdatenstruktur umfasst.
Verfahren gemäß einem der Ansprüche 13 bis 16, wobei das Kennzeichnen der mindestens zwei Ziel-R-Elementdatenstrukturen ferner ein Initialisieren der mindestens zwei Ziel-R-Elementdatenstrukturen durch Setzen jedes Elements in der mindestens zwei Ziel-R-Elementdatenstrukturen auf Werte von einer Auswahl von R-Elementen aus einer Gruppe von Datenstrukturen umfasst.
Verfahren gemäß einem der Ansprüche 13 bis 17, wobei das Ausführen mindestens einer Anweisung das Ausführen einer Anweisung von einem einzelnen Thread oder in einer einzelnen Ausführungsspur umfasst.
Verfahren gemäß Anspruch 18, wobei der einzelne Thread oder die einzelne Ausführungsspur eine einzelne Instanz der mindestens zwei Ziel-R-Elementdatenstrukturen verwendet.
Verfahren gemäß einem der Ansprüche 13 bis 19, wobei das Ausführen mindestens einer Anweisung das Ausführen einer Anweisung von mehreren Threads oder in mehreren Ausführungsspuren umfasst.
Verfahren gemäß Anspruch 20, wobei die mehreren Threads oder Ausführungsspuren in Gruppen aufgeteilt werden und jede Gruppe eine unterschiedliche Instanz der mindestens zwei Ziel-R-Elementdatenstrukturen verwendet.
Verfahren gemäß einem der Ansprüche 13 bis 21, wobei das Ausführen mindestens einer Anweisung, um die N-Elementdatenstruktur in die mindestens zwei Ziel-R-Elementdatenstrukturen zu dekomprimieren, ferner umfasst: Erzeugen neuer Metadaten für jede der mindestens zwei Ziel-R-Elementdatenstrukturen.