DE102018129135A1

DE102018129135A1 - Verwendung von rest-videodaten, die aus einer kompression von original-videodaten resultieren, um eine dekompression der original-videodaten zu verbessern

Info

Publication number: DE102018129135A1
Application number: DE102018129135.3A
Authority: DE
Inventors: Yi-Hsuan Tsai; Ming-Yu Liu; Deqing Sun; Ming-Hsuan Yang; Jan Kautz
Original assignee: Nvidia Corp
Current assignee: Nvidia Corp
Priority date: 2017-11-21
Filing date: 2018-11-20
Publication date: 2019-05-23

Abstract

Offenbart werden ein Verfahren, ein computerlesbares Medium und ein System zum Identifizieren von Rest-Videodaten. Diese Daten beschreiben Daten, die während einer Kompression von Original-Videodaten verloren gehen. Zum Beispiel können die Original-Videodaten komprimiert und dann dekomprimiert werden, und dieses Ergebnis kann mit den Original-Videodaten verglichen werden, um die Rest-Videodaten zu ermitteln. Diese Rest-Videodaten werden durch Codieren, Binarisieren und Komprimieren in ein kleineres Format umgewandelt und an ein Ziel gesendet. Am Ziel werden die Rest-Videodaten wieder in ihr ursprüngliches Format umgewandelt und während der Dekompression der komprimierten Original-Videodaten verwendet, um die Qualität der dekomprimierten Original-Videodaten zu verbessern.

Description

GEBIET DER ERFINDUNG
Die vorliegende Erfindung bezieht sich auf Video-Streaming und insbesondere auf die Nutzung von Rest-Videodaten, die aus einer Kompression von Original-Videodaten resultieren, um eine Dekompression der Original-Videodaten zu verbessern.
HINTERGRUND
Video-Streaming ist eine beliebte Methode, um Benutzern Inhalte zu liefern. Aufgrund großer Video-Größen und begrenzter Netzbandbreite kann Videokompression erforderlich sein, um Videodaten zu streamen. Gegenwärtige Verfahren zur Implementierung von Videokompression führen jedoch zu unerwünschten Artefakten und Effekten innerhalb der dekomprimierten Videodaten. Daher ist es wünschenswert, die Qualität von gestreamten Videodaten zu verbessern. Es besteht daher die Notwendigkeit, diese Probleme und/oder andere Probleme im Zusammenhang mit dem Stand der Technik zu beheben.
Figurenliste

1 veranschaulicht ein Flussdiagramm eines Verfahrens zum Erzeugen und Senden von binären Rest-Darstellungen gemäß einer Ausführungsform.
2 veranschaulicht eine Parallelverarbeitungseinheit gemäß einer Ausführungsform.
3A veranschaulicht einen Allgemeinverarbeitungscluster innerhalb der Parallelverarbeitungseinheit von 2 gemäß einer Ausführungsform.
3B veranschaulicht eine Speicherpartitionseinheit der Parallelverarbeitungseinheit von 2 gemäß einer Ausführungsform.
4A veranschaulicht den Streaming-Multiprozessor von 3A gemäß einer Ausführungsform.
4B ist ein konzeptionelles Diagramm eines unter Verwendung der PPU von 2 implementierten Verarbeitungssystems gemäß einer Ausführungsform.
4C veranschaulicht ein Beispiel-System, in dem die verschiedene Architektur und/oder Funktionalität der verschiedenen vorherigen Ausführungsformen implementiert werden kann.
5 ist ein konzeptionelles Diagramm einer durch die PPU von 2 implementierten Grafikverarbeitungspipeline gemäß einer Ausführungsform.
6 ist ein Beispiel-Überblick über eine Video-Streaming-Pipeline gemäß einer Ausführungsform.
7 ist eine Beispiel-Binär-Rest-Autoencoder-Architektur gemäß einer Ausführungsform.

DETAILLIERTE BESCHREIBUNG
Video-Streaming ist eine gängige Methode, um Videoinhalte (z. B. Filme, Fernsehsendungen, aufgezeichnete Veranstaltungen usw.) von einem Ort zum anderen zu senden. Zum Beispiel kann Video von einem Server an viele Heimcomputer, Medien-Streaming-Geräte, Mobiltelefone usw. gestreamt werden. Häufig werden Videos komprimiert (größenreduziert), um sie effizienter streamen zu können. Die zum Komprimieren eines Videos verwendeten Verfahren können sich jedoch negativ auf die Qualität des Videos auswirken, wenn das Video später dekomprimiert (auf seine ursprüngliche Größe zurückgebracht) wird. Zum Beispiel kann der Kompressions-/Dekompressionsprozess Artefakte (Glitches/Verzerrung) im dekomprimierten Video erzeugen.
Um dieses Problem zu beheben, wird ein Video zuerst komprimiert und dann dekomprimiert. Die Ergebnisse dieses Prozesses werden mit dem Originalvideo verglichen, um eine Differenz zwischen den beiden zu ermitteln, die als Rest-Videodaten bezeichnet wird. Diese Rest-Videodaten werden durch Prozesse, die als Codieren, Binarisieren und Komprimieren bezeichnet werden, in ein kleineres Format umgewandelt, und die umgewandelten Restdaten werden mit dem komprimierten Video an ein Ziel gesendet. Am Ziel werden die Rest-Videodaten wieder in ihr ursprüngliches Format umgewandelt und zur Verbesserung der Qualität des dekomprimierten Videos verwendet.
1 veranschaulicht ein Flussdiagramm eines Verfahrens 100 zum Erzeugen und Senden von binären Rest-Darstellungen gemäß einer Ausführungsform. Obwohl das Verfahren 100 im Zusammenhang mit einer Verarbeitungseinheit beschrieben wird, kann das Verfahren 100 auch durch ein Programm, eine benutzerspezifische Schaltung oder durch eine Kombination aus einer benutzerspezifischen Schaltung und einem Programm durchgeführt werden. Zum Beispiel kann das Verfahren 100 von einer GPU (Grafikverarbeitungseinheit), einer CPU (Zentralverarbeitungseinheit) oder irgendeinem Prozessor durchgeführt werden, der in der Lage ist, durch Hashing (Streuwertverfahren) eine Parallelpfadraumfilterung durchzuführen. Weiterhin erkennt der Fachmann, dass irgendein System, welches das Verfahren 100 durchführt, im Schutzbereich und Geist der Ausführungsformen der vorliegenden Erfindung liegt.
Wie in Operation 102 gezeigt, werden aus einer Kompression der Original-Videodaten resultierende Rest-Videodaten identifiziert. In einer Ausführungsform können die Original-Videodaten beliebige Videodaten beinhalten (z. B. aufgezeichnete Videodaten, erzeugte Videodaten, Spiele-Videodaten usw.). Zum Beispiel können die Original-Videodaten von einer oder mehreren Kameras erzeugt werden. In einem anderen Beispiel können sich die eine oder die mehreren Kameras an oder in einem Fahrzeug befinden.
Zusätzlich können die Original-Videodaten in einer Ausführungsform unter Verwendung eines oder mehrerer Komprimierungsalgorithmen komprimiert werden. In einer weiteren Ausführungsform können die Original-Videodaten unter Verwendung eines oder mehrerer Encoder (z. B. eines H.264-Encoders usw.) komprimiert werden. In noch einer weiteren Ausführungsform können die Ergebnisse der Kompression der Original-Videodaten komprimierte Original-Videodaten beinhalten.
Weiterhin können in einer Ausführungsform die komprimierten Original-Videodaten mit den Original-Videodaten verglichen werden. Zum Beispiel können die komprimierten Videodaten zuerst dekomprimiert/decodiert werden (z. B. unter Verwendung eines oder mehrerer Decoder wie z. B. eines H.264-Decoders usw.), um dekomprimierte/decodierte Original-Videodaten zu erzeugen. In einem weiteren Beispiel können die Rest-Videodaten durch Berechnen der Differenz zwischen den dekomprimierten/decodierten Original-Videodaten und den Original-Videodaten ermittelt werden.
Weiterhin werden, wie in Operation 104 gezeigt, die Rest-Videodaten codiert, um codierte Rest-Videodaten zu erzeugen. In einer Ausführungsform kann das Codieren der Rest-Videodaten beinhalten, die Rest-Videodaten zu komprimieren. In einer weiteren Ausführungsform können die Rest-Videodaten unter Verwendung eines Binär-Rest-Autoencoders codiert werden. Zum Beispiel kann der Binär-Rest-Autoencoder von einem Encoder-Modul getrennt sein, das die Original-Videodaten komprimiert hat.
In einer Ausführungsform kann der Binär-Rest-Autoencoder auch einen Rest-Encoder beinhalten. Zum Beispiel können die Restdaten unter Verwendung des Rest-Encoders codiert werden. In einer weiteren Ausführungsform kann der Binär-Rest-Autoencoder ein neuronales Netz beinhalten.
Zusätzlich werden, wie in Operation 106 gezeigt, die codierten Rest-Videodaten binarisiert, um binarisierte Rest-Videodaten zu erzeugen. In einer Ausführungsform können die codierten Rest-Videodaten unter Verwendung des Binär-Rest-Autoencoders binarisiert werden. In einer weiteren Ausführungsform kann der Binär-Rest-Autoencoder einen Binarisierer beinhalten. Zum Beispiel kann der Binarisierer Einzelbilddaten der codierten Rest-Videodaten in einen komprimierbaren binären Bitstrom umwandeln, so dass die binarisierten Rest-Videodaten einen binären Bitstrom beinhalten. In einem weiteren Beispiel kann der Binarisierer unter Verwendung einer Tanh-Aktivierung trainiert und implementiert werden. In noch einem weiteren Beispiel kann der Binarisierer unter Verwendung einer HardTanh-Aktivierung trainiert und implementiert werden. In noch einem weiteren Beispiel kann der Binarisierer unter Verwendung einer oder mehrerer der folgenden Methoden trainiert und implementiert werden: Sigmoid-Aktivierung, stochastische Regularisierung und Gumbel-Rauschen.
Weiterhin werden in einer Ausführungsform die binarisierten Rest-Videodaten komprimiert, um komprimierte Rest-Videodaten zu erzeugen. In einer Ausführungsform können die binarisierten Rest-Videodaten unter Verwendung des Binär-Rest-Autoencoders komprimiert werden. In einer weiteren Ausführungsform kann der Binär-Rest-Autoencoder einen Huffman-Encoder beinhalten. Zum Beispiel kann der Huffman-Encoder den vom Binarisierer erzeugten binären Bitstrom komprimieren, um eine zu übertragende Datenmenge zu reduzieren.
In einer weiteren Ausführungsform kann das Codieren, Binarisieren und Komprimieren gebietsspezifisch sein. Zum Beispiel kann der Binär-Rest-Autoencoder das Codieren, Binarisieren und Komprimieren der Rest-Videodaten durchführen, und ein derartiger Binär-Rest-Autoencoder kann auf eine gebietsspezifische Weise trainiert werden. Insbesondere kann während des Trainings des Binär-Rest-Autoencoders eine begrenzte Menge von möglichen Ergebnissen (z. B. Bilder, Szenen, Situationen usw.) verwendet werden. Auf diese Weise kann die Videokompressionsleistung unter Verwendung eines Binär-Rest-Autoencoders, der auf ein bestimmtes Gebiet beschränkt ist, verbessert werden. In noch einer weiteren Ausführungsform kann das Codieren, Binarisieren und Komprimieren unter Verwendung einer oder mehrerer Parallelverarbeitungseinheiten (PPUs) 200 durchgeführt werden, wie in 2 unten dargestellt.
Außerdem werden, wie in Operation 108 gezeigt, die komprimierten Rest-Videodaten übertragen. In einer Ausführungsform können die komprimierten Rest-Videodaten mit den komprimierten Original-Videodaten übertragen werden. In einer weiteren Ausführungsform können die komprimierten Rest-Videodaten und die komprimierten Original-Videodaten gleichzeitig über einen einzelnen Kanal gesendet werden. In noch einer weiteren Ausführungsform können die komprimierten Rest-Videodaten und die komprimierten Original-Videodaten in einem Server-Gerät erzeugt werden und können an ein Client-Gerät für Empfang und Dekompression und zum Aufbau eines Ausgabe-Videos gesendet werden. In noch einer weiteren Ausführungsform können die komprimierten Rest-Videodaten und die komprimierten Original-Videodaten an einen Client gestreamt werden.
Zusätzlich können in einer Ausführungsform die komprimierten Original-Videodaten und die komprimierten Rest-Videodaten in einem Client-Gerät empfangen werden. In einer weiteren Ausführungsform können die komprimierten Original-Videodaten in dem Client-Gerät dekomprimiert werden, um dekomprimierte Original-Videodaten zu erzeugen. Zum Beispiel können die komprimierten Original-Videodaten durch ein Decoder-Modul dekomprimiert werden. In einem weiteren Beispiel können die komprimierten Original-Videodaten unter Verwendung eines oder mehrerer Dekomprimierungsalgorithmen dekomprimiert werden. In noch einem weiteren Beispiel können die komprimierten Original-Videodaten unter Verwendung eines oder mehrerer Decoder (z. B. eines H.264-Decoders usw.) dekomprimiert werden.
Weiterhin können in einer Ausführungsform die komprimierten Rest-Videodaten in dem Client-Gerät rekonstruiert werden, um rekonstruierte Rest-Videodaten zu erzeugen. Zum Beispiel kann das Rekonstruieren der komprimierten Rest-Videodaten beinhalten, die komprimierten Rest-Videodaten zu dekomprimieren. In einem weiteren Beispiel können die komprimierten Rest-Videodaten unter Verwendung eines vom Decoder-Modul getrennten Rest-Moduls dekomprimiert werden. In noch einem weiteren Beispiel kann das Decoder-Modul einen Huffman-Decoder beinhalten. In noch einem weiteren Beispiel kann das Decoder-Modul einen Rest-Decoder beinhalten.
Weiterhin können in einer Ausführungsform die rekonstruierten Rest-Videodaten wieder zu den dekomprimierten Original-Videodaten hinzugefügt werden, um Ausgabe-Videodaten zu erzeugen. In einer weiteren Ausführungsform können die Ausgabe-Videodaten angezeigt werden. Zum Beispiel können die Ausgabe-Videodaten auf einem Display angezeigt werden, können in einem Fahrzeug angezeigt werden, können analysiert werden, können in einem Spielgerät betrachtet werden, usw.
Auf diese Weise können Rest-Videodaten codiert und mit komprimierten Original-Videodaten übertragen werden, um die Ergebnisse des Dekomprimierens der komprimierten Original-Videodaten zu verbessern. Für die Original-Videodaten und die Rest-Videodaten können getrennte Encoder verwendet werden. Diese Rest-Videodaten können auf eine gebietsspezifische Weise komprimiert werden, was eine Größe der komprimierten Rest-Videodaten reduzieren und eine Menge an Bandbreite verringern kann, die zum Übertragen der komprimierten Rest-Videodaten an ein Client-Gerät verwendet wird. Weiterhin kann ein Binär-Rest-Autoencoder verwendet werden, um die Rest-Videodaten zu codieren, wobei der Binär-Rest-Autoencoder einen Rest-Encoder und einen Binarisierer beinhaltet.
Es werden nun nähere Informationen zu verschiedenen optionalen Architekturen und Merkmalen gegeben, mit denen das vorgenannte Gerüst nach den Wünschen des Benutzers implementiert werden kann. Man beachte dringend, dass die folgenden Informationen zur Veranschaulichung gegeben werden und nicht als in irgendeiner Weise einschränkend auszulegen sind. Irgendeines der folgenden Merkmale kann wahlweise mit oder ohne den Ausschluss von anderen beschriebenen Merkmalen aufgenommen werden.
Parallelverarbeitungsarchitektur
2 veranschaulicht eine Parallelverarbeitungseinheit (PPU) 200 gemäß einer Ausführungsform. In einer Ausführungsform ist die PPU 200 ein Multi-Thread-Prozessor, der auf einer oder mehreren integrierten Schaltungen implementiert ist. Die PPU 200 ist eine Latenz verbergende Architektur (Latency Hiding Architecture), die darauf ausgelegt ist, viele Threads parallel zu verarbeiten. Ein Thread (d. h. ein Thread einer Ausführung) ist eine Instanziierung eines Satzes von Befehlen, die so konfiguriert sind, dass sie von der PPU 200 ausgeführt werden. In einer Ausführungsform ist die PPU 200 eine Grafikverarbeitungseinheit (GPU), die so konfiguriert ist, dass sie eine Grafik-Rendering-Pipeline für Verarbeitung von dreidimensionalen (3D) Grafikdaten implementiert, um zweidimensionale (2D) Bilddaten für Anzeige auf einem Display-Gerät wie z. B. einem Flüssigkristalldisplay-Gerät (LCD-Gerät) zu erzeugen. In anderen Ausführungsformen kann die PPU 200 zur Durchführung von Mehrzweckberechnungen verwendet werden. Obwohl hierin zur Veranschaulichung ein Beispiel-Parallelprozessor vorgesehen ist, sei ausdrücklich darauf hingewiesen, dass dieser Prozessor nur zu veranschaulichenden Zwecken angegeben ist und dass irgendein Prozessor eingesetzt werden kann, um diesen zu ergänzen und/oder zu ersetzen.
Eine oder mehrere PPUs 200 können so konfiguriert sein, dass sie Tausende von Hochleistungsrechnern (HPC, High Performance Computing), ein Rechenzentrum und Anwendungen für maschinelles Lernen beschleunigen. Die PPU 200 kann so konfiguriert sein, dass sie zahlreiche Systeme und Anwendungen für Deep Learning (tiefgehendes Lernen) beschleunigt, darunter autonome Fahrzeugplattformen, Deep Learning, hochpräzise Sprach-, Bild- und Texterkennungssysteme, intelligente Videoanalytik, molekulare Simulationen, Medikamentenentdeckung, Krankheitsdiagnose, Wettervorhersage, Big Data Analytik, Astronomie, Molekulardynamiksimulation, Finanzmodellierung, Robotik, Fabrikautomatisierung, Echtzeit-Sprachübersetzung, Online-Suchoptimierungen und personalisierte Benutzerempfehlungen und dergleichen.
Wie in 2 gezeigt, enthält die PPU 200 eine Eingabe/Ausgabe-(l/O)-Einheit 205, eine Vorverarbeitungseinheit 215, eine Scheduler-Einheit 220, eine Arbeitsverteilungseinheit 225, einen Hub 230, ein Koppelfeld (Xbar, crossbar) 270, einen oder mehrere Allgemeinverarbeitungscluster (GPCs) 250 und eine oder mehrere Partitionseinheiten 280. Die PPU 200 kann über eine oder mehrere Hochgeschwindigkeits-NVLink 210 Verbindungen mit einem Host-Prozessor oder anderen PPUs 200 verbunden sein. Die PPU 200 kann über eine Verbindung 202 mit einem Host-Prozessor oder anderen Peripheriegeräten verbunden sein. Die PPU 200 kann auch mit einem lokalen Speicher verbunden sein, der eine Anzahl von Speichergeräten 204 umfasst. In einer Ausführungsform kann der lokale Speicher eine Anzahl von DRAM-(Dynamic Random Access Memory, Speicher mit dynamischem Direktzugriff)-Geräten umfassen. Die DRAM-Geräte können als ein HBM-(High-Bandwidth Memory)-Subsystem konfiguriert sein, wobei mehrere DRAM-Dies (Waferstücke) in jedem Gerät gestapelt sind.
Die NVLink 210 Verbindung ermöglicht es Systemen, eine oder mehrere PPUs 200 in Kombination mit einer oder mehreren CPUs zu skalieren und zu integrieren, unterstützt Cache-Kohärenz zwischen den PPUs 200 und CPUs sowie CPU-Mastering. Daten und/oder Befehle können vom NVLink 210 über den Hub 230 zu/von anderen Einheiten der PPU 200 übertragen werden, wie z. B. einer oder mehreren Kopier-Engines, einem Video-Encoder, einem Video-Decoder, einer Leistungsmanagement-Einheit usw. (nicht explizit gezeigt). Der NVLink 210 wird in Verbindung mit 4B näher beschrieben.
Die I/O-Einheit 205 ist so konfiguriert, dass sie über die Verbindung 202 Kommunikation (d. h. Befehle, Daten, usw.) von einem Host-Prozessor (nicht gezeigt) sendet und empfängt. Die I/O-Einheit 205 kann mit dem Host-Prozessor direkt über die Verbindung 202 oder über ein oder mehrere Zwischen-Geräte wie z.B. eine Speicherbrücke kommunizieren. In einer Ausführungsform kann die I/O-Einheit 205 über die Verbindung 202 mit einem oder mehreren anderen Prozessoren kommunizieren, wie z. B. einer oder mehreren der PPUs 200. In einer Ausführungsform implementiert die I/O-Einheit 205 eine PCIe-(Peripheral Component Interconnect Express)-Schnittstelle für Kommunikation über einen PCIe-Bus, und die Verbindung 202 ist ein PCIe-Bus. In alternativen Ausführungsformen kann die I/O-Einheit 205 andere Arten von bekannten Schnittstellen für Kommunikation mit externen Geräten implementieren.
Die I/O-Einheit 205 decodiert Pakete, die über die Verbindung 202 empfangen wurden. In einer Ausführungsform repräsentieren die Pakete Befehle, die so konfiguriert sind, dass sie die PPU 200 verschiedene Operationen durchführen lassen. Die I/O-Einheit 205 überträgt die decodierten Befehle an verschiedene andere Einheiten der PPU 200, wie es die Befehle spezifizieren können. So können zum Beispiel manche Befehle an die Vorverarbeitungseinheit 215 übertragen werden. Andere Befehle können an den Hub 230 oder andere Einheiten der PPU 200 übertragen werden, wie z. B. eine oder mehrere Kopier-Engines, einen Video-Encoder, einen Video-Decoder, eine Leistungsmanagement-Einheit usw. (nicht explizit gezeigt). Mit anderen Worten, die I/O-Einheit 205 ist so konfiguriert, dass sie die Kommunikation zwischen und unter den verschiedenen logischen Einheiten der PPU 200 weiterleitet.
In einer Ausführungsform codiert ein vom Host-Prozessor ausgeführtes Programm einen Befehlsstrom in einem Puffer, der der PPU 200 Arbeit (Workload) zur Verarbeitung liefert. Ein Workload kann mehrere Anweisungen sowie Daten, die von diesen Anweisungen verarbeitet werden sollen, umfassen. Der Puffer ist ein Bereich in einem Speicher, auf den sowohl der Host-Prozessor als auch die PPU 200 zugreifen (d. h. lesen/schreiben) können. Zum Beispiel kann die I/O-Einheit 205 so konfiguriert sein, dass sie über Speicheranforderungen, die über die Verbindung 202 übertragen werden, auf den Puffer in einem Systemspeicher zugreift, der mit der Verbindung 202 verbunden ist. In einer Ausführungsform schreibt der Host-Prozessor den Befehlsstrom in den Puffer und sendet dann einen Zeiger auf den Anfang des Befehlsstroms an die PPU 200. Die Vorverarbeitungseinheit 215 empfängt Zeiger auf einen oder mehrere Befehlsströme. Die Vorverarbeitungseinheit 215 verwaltet einen oder mehrere Ströme, liest Befehle aus den Strömen und leitet Befehle an die verschiedenen Einheiten der PPU 200 weiter.
Die Vorverarbeitungseinheit 215 ist mit einer Scheduler-Einheit 220 gekoppelt, die die verschiedenen GPCs 250 so konfiguriert, dass sie Aufgaben bzw. Tasks bearbeiten, die durch die ein oder mehreren Ströme definiert sind. Die Scheduler-Einheit 220 ist so konfiguriert, dass sie Zustandsinformationen zu den verschiedenen Aufgaben verfolgt, die von der Scheduler-Einheit 220 verwaltet werden. Der Zustand kann angeben, welchem GPC 250 eine Aufgabe zugewiesen ist, ob die Aufgabe aktiv oder inaktiv ist, einen der Aufgabe zugewiesenen Prioritätsgrad und so weiter. Die Scheduler-Einheit 220 verwaltet die Ausführung einer Vielzahl von Aufgaben auf den ein oder mehreren GPCs 250.
Die Scheduler-Einheit 220 ist mit einer Arbeitsverteilungseinheit 225 gekoppelt, die so konfiguriert ist, dass sie Aufgaben zur Ausführung auf den GPCs 250 abfertigt. Die Arbeitsverteilungseinheit 225 kann eine Reihe von geplanten Aufgaben verfolgen, die von der Scheduler-Einheit 220 empfangen wurden. In einer Ausführungsform verwaltet die Arbeitsverteilungseinheit 225 für jeden der GPCs 250 einen Pool von anstehenden Aufgaben und einen Pool von aktiven Aufgaben. Der Pool von anstehenden Aufgaben kann eine Anzahl von Slots (z. B. 32 Slots) umfassen, die Aufgaben enthalten, die von einem bestimmten GPC 250 zu bearbeiten sind. Der Pool von aktiven Aufgaben kann eine Anzahl von Slots (z. B. 4 Slots) für Aufgaben umfassen, die gerade von den GPCs 250 aktiv bearbeitet werden. Wenn ein GPC 250 die Ausführung einer Aufgabe beendet, wird diese Aufgabe aus dem Pool von aktiven Aufgaben für den GPC 250 entfernt, und es wird eine der anderen Aufgaben aus dem Pool von anstehenden Aufgaben ausgewählt und für Ausführung auf dem GPC 250 eingeplant. Wenn eine aktive Aufgabe auf dem GPC 250 untätig war, z. B. während des Wartens auf Auflösung einer Datenabhängigkeit, kann die aktive Aufgabe aus dem GPC 250 entfernt und an den Pool von anstehenden Aufgaben zurückgegeben werden, während eine andere Aufgabe im Pool von anstehenden Aufgaben ausgewählt und für Ausführung auf dem GPC 250 eingeplant wird.
Die Arbeitsverteilungseinheit 225 kommuniziert über das XBar 270 mit einem oder mehreren GPCs 250. Das XBar 270 ist ein Verbindungsnetz, das viele Einheiten der PPU 200 mit anderen Einheiten der PPU 200 koppelt. Zum Beispiel kann das XBar 270 so konfiguriert sein, dass es die Arbeitsverteilungseinheit 225 mit einem bestimmten GPC 250 koppelt. Obwohl nicht explizit gezeigt, können eine oder mehrere andere Einheiten der PPU 200 auch über den Hub mit dem XBar 270 verbunden sein.
Die Aufgaben werden von der Scheduler-Einheit 220 verwaltet und von der Arbeitsverteilungseinheit 225 an einen GPC 250 abgefertigt. Der GPC 250 ist so konfiguriert, dass er die Aufgabe bearbeitet und Ergebnisse erzeugt. Die Ergebnisse können von anderen Aufgaben innerhalb des GPC 250 aufgenommen, über das XBar 270 an einen anderen GPC 250 weitergeleitet oder im Speicher 204 gespeichert werden. Die Ergebnisse können über die Partitionseinheiten 280, die eine Speicherschnittstelle zum Lesen und Schreiben von Daten in den bzw. aus dem Speicher 204 implementieren, in den Speicher 204 geschrieben werden. Die Ergebnisse können über den NVLink 210 an eine andere PPU 204 oder CPU übertragen werden. In einer Ausführungsform enthält die PPU 200 eine Anzahl U von Partitionseinheiten 280, die der Anzahl von separaten und getrennten Speichergeräten 204 entspricht, die mit der PPU 200 gekoppelt sind. Eine Partitionseinheit 280 wird im Folgenden in Verbindung mit 3B näher beschrieben.
In einer Ausführungsform führt ein Host-Prozessor einen Treiber-Kernel aus, der eine Anwendungsprogrammierschnittstelle (API) implementiert, die es einer oder mehreren auf dem Host-Prozessor ausgeführten Anwendungen ermöglicht, Operationen für Ausführung auf der PPU 200 zu planen. In einer Ausführungsform werden mehrere Rechenanwendungen gleichzeitig von der PPU 200 ausgeführt, und die PPU 200 bietet Isolation, Dienstgüte (QoS, Quality of Service) und unabhängige Adressräume für die mehreren Rechenanwendungen. Eine Anwendung kann Anweisungen (d. h. API-Aufrufe) generieren, die den Treiber-Kernel veranlassen, eine oder mehrere Aufgaben für Ausführung durch die PPU 200 zu generieren. Der Treiber-Kernel gibt Aufgaben an einen oder mehrere Ströme aus, die von der PPU 200 bearbeitet werden. Jede Aufgabe kann eine oder mehrere Gruppen von verwandten Threads umfassen, die hier als ein Warp bezeichnet werden. In einer Ausführungsform umfasst ein Warp 32 in Bezug stehende Threads, die parallel ausgeführt werden können. Kooperierende Threads können sich auf eine Vielzahl von Threads beziehen, einschließlich Anweisungen zur Durchführung der Aufgabe und dass Daten über Gemeinschaftsspeicher ausgetauscht werden können. Threads und kooperierende Threads werden in Verbindung mit 4A näher beschrieben.
3A veranschaulicht einen GPC 250 der PPU 200 von 2 gemäß einer Ausführungsform. Wie in 3A gezeigt, enthält jeder GPC 250 eine Reihe von Hardware-Einheiten zur Bearbeitung von Aufgaben. In einer Ausführungsform enthält jeder GPC 250 einen Pipeline-Manager 310, eine Pre-Rasteroperationseinheit (PROP) 315, eine Raster-Engine 325, ein Arbeitsverteilungs-Koppelfeld (WDX) 380, eine Speicherverwaltungs-Einheit (MMU) 390 und einen oder mehrere Datenverarbeitungs-Cluster (DPCs) 320. Man beachte, dass der GPC 250 von 3A anstelle der oder zusätzlich zu den in 3A gezeigten Einheiten andere Hardware-Einheiten enthalten kann.
In einer Ausführungsform wird der Betrieb des GPC 250 durch den Pipeline-Manager 310 gesteuert. Der Pipeline-Manager 310 verwaltet die Konfiguration der ein oder mehreren DPCs 320 für Bearbeitung von Aufgaben, die dem GPC 250 zugewiesen sind. In einer Ausführungsform kann der Pipeline-Manager 310 mindestens einen der ein oder mehreren DPCs 320 so konfigurieren, dass er mindestens einen Teil einer Grafik-Rendering-Pipeline implementiert. Zum Beispiel kann ein DPC 320 so konfiguriert sein, dass er ein Vertex-Shader-Programm auf dem programmierbaren Streaming-Multiprozessor (SM) 340 ausführt. Der Pipeline-Manager 310 kann auch so konfiguriert sein, dass er von der Arbeitsverteilungseinheit 225 empfangene Pakete an die entsprechenden logischen Einheiten innerhalb des GPC 250 weiterleitet. Zum Beispiel können manche Pakete an Hardware-Einheiten mit fester Funktion in der PROP 315 und/oder der Raster-Engine 325 weitergeleitet werden, während andere Pakete an die DPCs 320 zur Verarbeitung durch die Primitiv-Engine 335 oder den SM 340 weitergeleitet werden können. In einer Ausführungsform kann der Pipeline-Manager 310 mindestens einen der ein oder mehreren DPCs 320 so konfigurieren, dass er ein Modell für ein neuronales Netz und/oder eine Rechen-Pipeline implementiert.
Die PROP-Einheit 315 ist so konfiguriert, dass sie von der Raster-Engine 325 und den DPCs 320 erzeugte Daten an eine Rasteroperations-(ROP)-Einheit weiterleitet, die in Verbindung mit 3B näher beschrieben wird. Die PROP-Einheit 315 kann auch so konfiguriert sein, dass sie Optimierungen für Farbmischung durchführt, Pixeldaten organisiert, Adressenübersetzungen durchführt und dergleichen.
Die Raster-Engine 325 enthält eine Reihe von Hardware-Einheiten mit fester Funktion, die so konfiguriert sind, dass sie verschiedene Rasteroperationen durchführen können. In einer Ausführungsform enthält die Raster-Engine 325 eine Setup-Engine, eine Grobraster-Engine, eine Culling-Engine, eine Clipping-Engine, eine Feinraster-Engine und eine Kachel-Coalescing-Engine. Die Setup-Engine empfängt transformierte Vertices und generiert Ebenengleichungen, die dem geometrischen Primitiv zugeordnet sind, das durch die Vertices definiert ist. Die Ebenengleichungen werden an die Grobraster-Engine übertragen, um Abdeckungsinformationen (z. B. eine x,y-Abdeckungsmaske für eine Kachel) für das Primitiv zu generieren. Die Ausgabe der Grobraster-Engine wird zu der Culling-Engine übertragen, wo Fragmente, die dem Primitiv zugeordnet sind, dass einen Z-Test nicht besteht, einem Culling (Auslesen) unterzogen werden, und zu einer Clipping-Engine übertragen, wo Fragmente, die außerhalb eines Betrachtungsstumpfs liegen, einem Clipping (Abschneiden) unterzogen werden. Diejenigen Fragmente, die das Clipping und Culling überleben, können an die Feinraster-Engine übergeben werden, um Attribute für die Pixelfragmente auf Basis der von der Setup-Engine generierten Ebenengleichungen zu generieren. Die Ausgabe der Raster-Engine 325 umfasst Fragmente, die zum Beispiel von einem Fragment-Shader zu verarbeiten sind, der innerhalb eines DPC 320 implementiert ist.
Jeder in dem GPC 250 enthaltene DPC 320 enthält einen M-Pipe-Controller (MPC) 330, eine Primitiv-Engine 335 und einen oder mehrere SMs 340. Der MPC 330 steuert den Betrieb des DPC 320 und leitet die vom Pipeline-Manager 310 empfangenen Pakete an die entsprechenden Einheiten im DPC 320 weiter. Zum Beispiel können Pakete, die einem Vertex zugeordnet sind, an die Primitiv-Engine 335 weitergeleitet werden, die so konfiguriert ist, dass sie Vertex-Attribute, die dem Vertex zugeordnet sind, aus dem Speicher 204 holt. Im Gegensatz dazu können Pakete, die einem Shader-Programm zugeordnet sind, an den SM 340 übertragen werden.
Der SM 340 umfasst einen programmierbaren Streaming-Prozessor, der so konfiguriert ist, dass er Aufgaben verarbeitet, die durch eine Reihe von Threads repräsentiert werden. Jeder SM 340 ist multi-threaded (mehrprozessfähig) und so konfiguriert, dass er eine Vielzahl von Threads (z. B. 32 Threads) aus einer bestimmten Gruppe von Threads gleichzeitig ausführen kann. In einer Ausführungsform implementiert der SM 340 eine SIMD-(Single-Instruction, Multiple-Data)-Architektur, bei der jeder Thread in einer Gruppe von Threads (z. B. einem Warp) so konfiguriert ist, dass er einen anderen Datensatz auf Basis desselben Befehlssatzes verarbeitet. Alle Threads in der Gruppe der Threads führen dieselben Anweisungen aus. In einer anderen Ausführungsform implementiert der SM 340 eine SIMT-(Single-Instruction, Multiple-Thread)-Architektur, bei der jeder Thread in einer Gruppe von Threads so konfiguriert ist, dass er einen anderen Datensatz auf Basis desselben Befehlssatzes verarbeitet, wobei jedoch einzelne Threads in der Gruppe von Threads während der Ausführung voneinander abweichen dürfen. In einer Ausführungsform werden für jeden Warp ein Programmzähler, ein Aufruf-Stapel und ein Ausführungszustand aufrechterhalten, was Gleichzeitigkeit zwischen Warps und serielle Ausführung innerhalb von Warps ermöglicht, wenn Threads innerhalb des Warps voneinander abweichen. In einer weiteren Ausführungsform werden für jeden einzelnen Thread ein Programmzähler, ein Aufruf-Stapel und ein Ausführungszustand aufrechterhalten, was gleiche Gleichzeitigkeit zwischen allen Threads, innerhalb und zwischen Warps, ermöglicht. Wenn der Ausführungszustand für jeden einzelnen Thread aufrechterhalten wird, können Threads, die dieselben Anweisungen ausführen, konvergiert und parallel ausgeführt werden, um maximale Effizienz zu erreichen. Der SM 340 wird im Folgenden in Verbindung mit 4A näher beschrieben.
Die MMU 390 stellt eine Schnittstelle zwischen dem GPC 250 und der PartitionsEinheit 280 bereit. Die MMU 390 kann Übersetzung von virtuellen Adressen in physische Adressen, Speicherschutz und Arbitrierung von Speicheranforderungen ermöglichen. In einer Ausführungsform stellt die MMU 390 einen oder mehrere Übersetzungspuffer (TLBs, Translation Lookaside Buffers) bereit, um Übersetzung von virtuellen Adressen in physische Adressen im Speicher 204 durchzuführen.
3B veranschaulicht eine Speicherpartitionseinheit 280 der PPU 200 von 2 gemäß einer Ausführungsform. Wie in 3B gezeigt, enthält die Speicherpartitionseinheit 280 eine Rasteroperationen-(ROP)-Einheit 350, einen Level-2-Cache (L2-Cache) 360 und eine Speicherschnittstelle 370. Die Speicherschnittstelle 370 ist mit dem Speicher 204 gekoppelt. Die Speicherschnittstelle 370 kann 32, 64, 128, 1024-Bit-Datenbusse oder dergleichen für Hochgeschwindigkeits-Datenübertragung implementieren. In einer Ausführungsform enthält die PPU 200 U Speicherschnittstellen 370, eine Speicherschnittstelle 370 pro Paar Partitionseinheiten 280, wobei jedes Paar Partitionseinheiten 280 mit einem entsprechenden Speichergerät 204 verbunden ist. Zum Beispiel kann die PPU 200 an bis zu Y Speichergeräte 204 angeschlossen werden, wie z. B. Speicherstapel mit hoher Bandbreite oder Grafik mit Doppel-Datenrate, Version 5, Speicher mit synchronem dynamischen Direktzugriff oder andere Arten von persistentem Speicher.
In einer Ausführungsform implementiert die Speicherschnittstelle 370 eine HBM2-Speicherschnittstelle und entspricht Y einem halben U. In einer Ausführungsform befinden sich die HBM2-Speicherstapel auf demselben physischen Gehäuse wie die PPU 200, was im Vergleich zu herkömmlichen GDDR5-SDRAM-Systemen zu erheblichen Leistungs- und Flächeneinsparungen führt. In einer Ausführungsform enthält jeder HBM2-Stapel vier Speicher-Dies und ist Y gleich 4, wobei der HBM2-Stapel zwei 128-Bit-Kanäle pro Die für insgesamt 8 Kanäle sowie eine Datenbusbreite von 1024 Bits aufweist.
In einer Ausführungsform unterstützt der Speicher 204 Einzelfehler korrigierenden und Doppelfehler erkennenden (SECDED) Fehlerkorrekturcode (ECC) zum Schutz von Daten. ECC bietet höhere Zuverlässigkeit für Rechenanwendungen, die empfindlich auf Datenbeschädigung reagieren. Zuverlässigkeit ist besonders wichtig in großen Cluster-Computerumgebungen, in denen PPUs 200 sehr große Datensätze verarbeiten und/oder Anwendungen über längere Zeiträume laufen.
In einer Ausführungsform implementiert die PPU 200 eine mehrstufige Speicherhierarchie. In einer Ausführungsform unterstützt die Speicherpartitionseinheit 280 einen vereinheitlichten Speicher, um einen einzigen vereinheitlichten virtuellen Adressraum für Speicher der CPU und PPU 200 bereitzustellen, der das Teilen von Daten zwischen virtuellen Speichersystemen ermöglicht. In einer Ausführungsform wird die Häufigkeit der Zugriffe einer PPU 200 auf Speicher verfolgt, der sich auf anderen Prozessoren befindet, um sicherzustellen, dass Speicherseiten in den physischen Speicher derjenigen PPU 200 verschoben werden, die häufiger auf die Seiten zugreift. In einer Ausführungsform unterstützt der NVLink 210 Adressenübersetzungsdienste, die es der PPU 200 ermöglichen, direkt auf Seitentabellen einer CPU zuzugreifen, und vollen Zugriff auf CPU-Speicher durch die PPU 200 ermöglichen.
In einer Ausführungsform übertragen Kopier-Engines Daten zwischen mehreren PPUs 200 oder zwischen PPUs 200 und CPUs. Die Kopier-Engines können Seitenstörungen für Adressen erzeugen, die nicht in die Seitentabellen eingetragen sind. Die Speicherpartitionseinheit 280 kann dann die Seitenstörungen bedienen und die Adressen in die Seitentabelle eintragen, woraufhin die Kopier-Engine die Übertragung durchführen kann. In einem herkömmlichen System ist Speicher für Mehrfach-Kopier-Engine-Operationen zwischen mehreren Prozessoren festgeheftet (d. h. nicht auslagerbar), was den verfügbaren Speicher erheblich reduziert. Bei Hardware-Seitenstörung können Adressen an die Kopier-Engines weitergegeben werden, ohne sich Sorgen zu machen, ob die Speicherseiten resident sind, und die Kopier-Operation ist transparent.
Daten aus dem Speicher 204 oder einem anderen Systemspeicher können von der Speicherpartitionseinheit 280 abgerufen und im L2-Cache 360, der On-Chip (auf dem Chip) angesiedelt ist und zwischen den verschiedenen GPCs 250 geteilt wird, gespeichert werden. Wie gezeigt, enthält jede Speicherpartitionseinheit 280 einen Teil des L2-Cache 360, der einem entsprechenden Speichergerät 204 zugeordnet ist. Untergeordnete Caches können dann in verschiedenen Einheiten innerhalb der GPCs 250 implementiert werden. Zum Beispiel kann jeder der SMs 340 einen Level-One-Cache (L1-Cache) implementieren. Der L1-Cache ist privater Speicher, der einem bestimmten SM 340 zugeordnet ist. Daten aus dem L2-Cache 360 können abgerufen und in jedem der L1-Caches zur Verarbeitung in den Funktionseinheiten der SMs 340 gespeichert werden. Der L2-Cache 360 ist mit der Speicherschnittstelle 370 und dem XBar 270 gekoppelt.
Die ROP-Einheit 350 führt grafische Rasteroperationen in Bezug auf Pixelfarbe durch, wie z. B. Farbkompression, Pixel-Blending und dergleichen. Die ROP-Einheit 350 führt auch Tiefenprüfungen in Verbindung mit der Raster-Engine 325 durch und empfängt eine Tiefe für eine Abtast-Position, die einem Pixelfragment zugeordnet ist, von der Culling-Engine der Raster-Engine 325. Die Tiefe wird gegen eine entsprechende Tiefe in einem Tiefenpuffer für eine dem Fragment zugeordnete Abtast-Position getestet. Wenn das Fragment den Tiefentest für die Abtast-Position besteht, aktualisiert die ROP-Einheit 350 den Tiefenpuffer und sendet ein Ergebnis des Tiefentests an die Raster-Engine 325. Man beachte, dass die Anzahl der Partitionseinheiten 280 von der Anzahl der GPCs 250 abweichen kann und daher jede ROP-Einheit 350 mit jeder der GPCs 250 gekoppelt sein kann. Die ROP-Einheit 350 verfolgt die von den verschiedenen GPCs 250 empfangenen Pakete und bestimmt, zu welchem GPC 250 ein von der ROP-Einheit 350 erzeugtes Ergebnis durch das Xbar 270 geleitet wird. Obwohl die ROP-Einheit 350 in 3B innerhalb der Speicherpartitionseinheit 280 enthalten ist, kann sich die ROP-Einheit 350 in einer anderen Ausführungsform außerhalb der Speicherpartitionseinheit 280 befinden. Zum Beispiel kann sich die ROP-Einheit 350 im GPC 250 oder einer anderen Einheit befinden.
4A veranschaulicht den Streaming-Multiprozessor 340 von 3A gemäß einer Ausführungsform. Wie in 4A gezeigt, enthält der SM 340 einen Anweisungs-Cache 405, eine oder mehrere Scheduler-Einheiten 410(K), eine Registerdatei 420, einen oder mehrere Verarbeitungs-Rechenkerne 450, eine oder mehrere Spezial-Funktionseinheiten (SFUs) 452, eine oder mehrere Lade-/Speicher-Einheiten (LSUs) 454, ein Verbindungsnetz 480 und einen Gemeinschaftsspeicher/L1 -Cache 470.
Wie oben beschrieben, fertigt die Arbeitsverteilungseinheit 225 Aufgaben zur Ausführung auf den GPCs 250 der PPU 200 ab. Die Aufgaben sind einem bestimmten DPC 320 innerhalb eines GPC 250 zugewiesen, und wenn die Aufgabe einem Shader-Programm zugeordnet ist, kann die Aufgabe einem SM 340 zugewiesen werden. Die Scheduler-Einheit 410(K) empfängt die Aufgaben von der Arbeitsverteilungseinheit 225 und verwaltet die Anweisungsplanung für einen oder mehrere Thread-Blöcke, die der SM 340 zugeordnet sind. Die Scheduler-Einheit 410(K) plant Thread-Blöcke zur Ausführung als Warps von parallelen Threads ein, wobei jedem Thread-Block mindestens ein Warp zugewiesen ist. In einer Ausführungsform führt jeder Warp 32 Threads aus. Die Scheduler-Einheit 410(K) kann eine Vielzahl verschiedener Thread-Blöcke verwalten, die Warps den verschiedenen Thread-Blöcken zuweisen und dann während jedes Taktzyklus Anweisungen von der Vielzahl von verschiedenen kooperativen Gruppen an die verschiedenen Funktionseinheiten (d. h. Rechenkerne 450, SFUs 452 und LSUs 454) abfertigen.
Cooperative Groups ist ein Programmiermodell für die Organisation von Gruppen kommunizierender Threads, das es Entwicklern ermöglicht, die Granularität auszudrücken, mit der Threads kommunizieren, was den Ausdruck reichhaltigerer, effizienterer paralleler Zerlegungen ermöglicht. Kooperative Start-APIs unterstützen Synchronisation zwischen Thread-Blöcken für die Ausführung paralleler Algorithmen. Herkömmliche Programmiermodelle bieten ein einziges, einfaches Konstrukt zur Synchronisation kooperierender Threads: eine Barriere über alle Threads eines Thread-Blocks hinweg (d. h. die Funktion syncthreads()). Programmierer möchten jedoch oft Gruppen von Threads mit kleinerer Granularität als Thread-Blöcke definieren und innerhalb der definierten Gruppen synchronisieren, um mehr Leistung, Designflexibilität und Softwarewiederverwendung in Form von gemeinsamen gruppenweiten Funktionsschnittstellen zu ermöglichen.
Cooperative Groups ermöglicht es Programmierern, Gruppen von Threads explizit am Unterblock (d. h. so klein wie ein einzelner Thread) und Multiblock-Granularitäten zu definieren und kollektive Operationen wie z. B. Synchronisation der Threads in einer kooperativen Gruppe durchzuführen. Das Programmiermodell unterstützt saubere Zusammensetzung über Softwaregrenzen hinweg, so dass Bibliotheken und Utility-Funktionen in ihrem lokalen Kontext sicher synchronisieren können, ohne Annahmen über Konvergenz treffen zu müssen. Cooperative Groups Primitive ermöglichen neue Muster kooperativer Parallelität, einschließlich Produzenten-Verbraucher-Parallelität, opportunistischer Parallelität und globaler Synchronisation über ein ganzes Netz von Thread-Blöcken hinweg.
Eine Abfertigungs-Einheit 415 ist so konfiguriert, das sie Anweisungen an eine oder mehrere der Funktionseinheiten senden kann. In der Ausführungsform enthält die Scheduler-Einheit 410(K) zwei Abfertigungs-Einheiten 415, die es ermöglichen, während jedes Taktzyklus zwei verschiedene Anweisungen von derselben Warp zu senden. In alternativen Ausführungsformen kann jede Scheduler-Einheit 410(K) eine einzige Abfertigungs-Einheit 415 oder zusätzliche Abfertigungs-Einheiten 415 enthalten.
Jeder SM 340 enthält eine Registerdatei 420, die einen Satz Register für die Funktionseinheiten der SM 340 bereitstellt. In einer Ausführungsform ist die Registerdatei 420 zwischen den einzelnen Funktionseinheiten aufgeteilt, so dass jeder Funktionseinheit ein bestimmter Teil der Registerdatei 420 zugeordnet ist. In einer anderen Ausführungsform ist die Registerdatei 420 zwischen den verschiedenen Warps aufgeteilt, die von dem SM 340 ausgeführt werden. Die Registerdatei 420 stellt temporären Speicher für Operanden bereit, die mit den Datenpfaden der Funktionseinheiten verbunden sind.
Jeder SM 340 umfasst L Verarbeitungs-Rechenkerne 450. In einer Ausführungsform enthält der SM 340 eine große Anzahl (z. B. 128, usw.) von getrennten Verarbeitungs-Rechenkernen 450. Jeder Rechenkern 450 kann eine Verarbeitungseinheit mit vollständiger Pipeline, einfacher Genauigkeit, Einfachpräzision, Doppelpräzision und/oder gemischter Präzision enthalten, die eine Gleitkomma-Arithmetik-Logikeinheit und eine Ganzzahl-Arithmetik-Logikeinheit enthält. In einer Ausführungsform implementieren die Gleitkomma-Arithmetik-Logikeinheiten die Norm IEEE 744 -2008 für Gleitkomma-Arithmetik. In einer Ausführungsform enthalten die Rechenkerne 450 64 Einfachpräzision-(32-Bit)-Gleitkomma-Rechenkerne, 64 Ganzzahl-Rechenkerne, 32 Doppelpräzision-(64-Bit)-Gleitkomma-Rechenkerne und 8 Tensor-Rechenkerne.
Tensor-Rechenkerne sind dafür konfiguriert, Matrixoperationen durchzuführen, und in einer Ausführungsform sind ein oder mehrere Tensor-Rechenkerne in den Rechenkernen 450 enthalten. Insbesondere sind die Tensor-Rechenkerne so konfiguriert, dass sie Deep-Learning-Matrixarithmetik durchführen können, wie z. B. Faltungsoperationen für Training und Inferenzierung neuronaler Netze. In einer Ausführungsform arbeitet jeder Tensor-Rechenkern auf einer 4x4-Matrix und führt eine Matrix-Multiplikations- und Akkumulationsoperation D=AxB+C durch, worin A, B, C und D 4x4-Matrizen sind.
In einer Ausführungsform sind die Matrixmultiplikations-Eingaben A und B 16-Bit-Gleitkomma-Matrizen, während die Akkumulations-Matrizen C und D 16-Bit-Gleitkomma- oder 32-Bit-Gleitkomma-Matrizen sein können. Tensor-Rechenkerne arbeiten an 16-Bit-Gleitkomma-Eingabedaten mit 32-Bit-Gleitkomma-Akkumulation. Die 16-Bit-Gleitkomma-Multiplikation erfordert 64 Operationen und führt zu einem hochpräzisen Produkt, das dann unter Verwendung von 32-Bit-Gleitkomma-Addition mit den anderen Zwischenprodukten für eine 4x4x4-Matrix-Multiplikation akkumuliert wird. In der Praxis werden Tensor-Rechenkerne verwendet, um viel größere zweidimensionale oder höherdimensionale Matrixoperationen durchzuführen, die sich aus diesen kleineren Elementen zusammensetzen. Eine API, wie z. B. die CUDA 9 C++ API, stellt spezielle Matrixlast, Matrix-Multiplikation und -Akkumulation sowie Matrix-Speicheroperationen zur Verfügung, um Tensor-Rechenkerne von einem CUDA-C++-Programm effizient zu nutzen. Auf der CUDA-Ebene setzt die Schnittstelle auf Warp-Ebene Matrizen der Größe 16x16 voraus, die alle 32 Threads des Warps überspannen.
Jeder SM 340 enthält auch M SFUs 452, die spezielle Funktionen ausführen (z. B. Attributbewertung, reziproke Quadratwurzel und dergleichen). In einer Ausführungsform können die SFUs 452 eine Baumdurchlaufeinheit enthalten, die so konfiguriert ist, dass eine hierarchische Baumdatenstruktur durchlaufen wird. In einer Ausführungsform können die SFUs 452 eine Textureinheit enthalten, die so konfiguriert ist, dass sie Texturabbildungs-Filteroperationen durchführt. In einer Ausführungsform sind die Textureinheiten so konfiguriert, dass sie Texturabbildungen (z. B. ein zweidimensionales Array von Texeln) aus dem Speicher 204 laden und die Texturabbildungen abtasten, um abgetastete Texturwerte zur Verwendung in Shader-Programmen zu erzeugen, die vom SM 340 ausgeführt werden. In einer Ausführungsform werden die Texturabbildungen im Gemeinschaftsspeicher/L1-Cache 370 gespeichert. Die Textureinheiten implementieren Textur-Operationen wie z. B. Filteroperationen mit Hilfe von Mip-Maps (d. h. Texturabbildungen mit unterschiedlichem Detaillierungsgrad). In einer Ausführungsform enthält jeder SM 240 zwei Textureinheiten.
Jeder SM 340 umfasst auch N LSUs 454, die Lade- und Speicheroperationen zwischen dem Gemeinschaftsspeicher/L1-Cache 470 und der Registerdatei 420 implementieren. Jeder SM 340 enthält ein Verbindungsnetz 480, das jede der Funktionseinheiten mit der Registerdatei 420 und die LSU 454 mit der Registerdatei 420, Gemeinschaftsspeicher/ L1 Cache 470 verbindet. In einer Ausführungsform ist das Verbindungsnetz 480 ein Koppelfeld, das so konfiguriert sein kann, dass es irgendeine der Funktionseinheiten mit irgendeinem der Register in der Registerdatei 420 verbindet und die LSUs 454 mit der Registerdatei und Speicherstellen im Gemeinschaftsspeicher/L1-Cache 470 verbindet.
Der Gemeinschaftsspeicher/L1 Cache 470 ist ein Array von On-Chip-Speicher, das Datenspeicherung und Kommunikation zwischen dem SM 340 und der Primitiv-Engine 335 sowie zwischen Threads im SM 340 ermöglicht. In einer Ausführungsform umfasst der Gemeinschaftsspeicher/L1-Cache 470 128KB Speicherkapazität und befindet sich in dem Pfad vom SM 340 zur Partitionseinheit 280. Mit dem Gemeinschaftsspeicher/L1-Cache 470 können Lese- und Schreibzugriffe zwischengespeichert werden. Einer oder mehrere von dem Gemeinschaftsspeicher/L1-Cache 470, L2-Cache 360 und Speicher 204 sind Backup-Speicher.
Die Kombination von Daten-Cache und Gemeinschaftsspeicher-Funktionalität in einem einzigen Speicherblock bietet die beste Gesamtleistung für beide Arten von Speicherzugriffen. Die Kapazität ist als ein Cache von Programmen nutzbar, die keinen Gemeinschaftsspeicher verwenden. Wenn zum Beispiel Gemeinschaftsspeicher so konfiguriert ist, dass die Hälfte der Kapazität genutzt werden kann, können Textur- und Lade-/Speicher-Operationen die verbleibende Kapazität nutzen. Integration in den Gemeinschaftsspeicher/L1-Cache 470 ermöglicht es dem Gemeinschaftsspeicher/L1-Cache 470, als Hochdurchsatz-Leitung für das Streaming von Daten zu fungieren und zugleich Zugriff mit hoher Bandbreite und niedriger Latenz auf häufig wiederverwendete Daten zu ermöglichen.
Bei Konfiguration für Universal-Parallelberechnung kann eine einfachere Konfiguration im Vergleich zu Grafikverarbeitung verwendet werden. Insbesondere werden die in 2 gezeigten Grafikverarbeitungseinheiten mit fester Funktion umgangen, wodurch ein viel einfacheres Programmiermodell entsteht. In der Universal-Parallelberechnungs-Konfiguration weist die Arbeitsverteilungseinheit 225 Thread-Blöcke direkt den DPCs 320 zu und verteilt sie darauf. Die Threads in einem Block führen das gleiche Programm aus, wobei eine eindeutige Thread-ID bei der Berechnung verwendet wird, um sicherzustellen, dass jeder Thread eindeutige Ergebnisse erzeugt, wobei der SM 340 verwendet wird, um das Programm auszuführen und Berechnungen durchzuführen, der Gemeinschaftsspeicher/L1-Cache 470, um zwischen Threads zu kommunizieren, und die LSU 454, um über den Gemeinschaftsspeicher/L1-Cache 470 und die Speicherpartitionseinheit 280 globalen Speicher zu lesen und darin zu schreiben. Wenn für Universal-Parallelberechnung konfiguriert, kann der SM 340 auch Befehle schreiben, mit denen die Scheduler-Einheit 220 neue Arbeit auf den DPCs 320 starten kann.
Die PPU 200 kann in einem Desktop-Computer, einem Laptop-Computer, einem Tablet-Computer, Servern, Supercomputern, einem Smartphone (z. B. einem drahtlosen, tragbaren Gerät), einem Personal Digital Assistant (PDA), einer Digitalkamera, einem Fahrzeug, einem am Kopf befestigten Display, einem tragbaren elektronischen Gerät und dergleichen enthalten sein. In einer Ausführungsform ist die PPU 200 auf einem einzelnen Halbleitersubstrat ausgebildet. In einer anderen Ausführungsform ist die PPU 200 zusammen mit einem oder mehreren anderen Geräten, wie z. B. zusätzlichen PPUs 200, dem Speicher 204, einer CPU für Computer mit reduziertem Befehlssatz (RISC), einer Speicherverwaltungseinheit (MMU), einem Digital-Analog-Wandler (DAC) und dergleichen in einem SoC (System-on-a-Chip, System auf einem Chip) enthalten.
In einer Ausführungsform kann die PPU 200 auf einer Grafikkarte enthalten sein, die ein oder mehrere Speichergeräte 204 enthält. Die Grafikkarte kann so konfiguriert sein, dass sie eine Schnittstellenverbindung mit einem PCIe-Steckplatz auf einem Motherboard eines Desktop-Computers herstellt. In noch einer Ausführungsform kann die PPU 200 eine integrierte Grafikverarbeitungseinheit (iGPU) oder ein Parallelprozessor sein, die bzw. der im Chipsatz des Motherboards enthalten ist.
Beispiel-Rechensystem
Systeme mit mehreren GPUs und CPUs werden in mannigfachen Branchen eingesetzt, da Entwickler mehr Parallelität bei Anwendungen wie z. B. künstlicher Intelligenz enthüllen und nutzen. Leistungsstarke GPU-beschleunigte Systeme mit Zehntausenden von Rechenknoten werden in Rechenzentren, Forschungseinrichtungen und Supercomputern eingesetzt, um immer größere Probleme zu lösen. Mit zunehmender Anzahl von Verarbeitungsgeräten innerhalb der Hochleistungssysteme müssen die Kommunikations- und Datenübertragungsmechanismen skaliert werden, um die erhöhte Bandbreite zu unterstützen.
4B ist ein konzeptionelles Diagramm eines unter Verwendung der PPU 200 von 2 implementierten Verarbeitungssystems 400 gemäß einer Ausführungsform. Das Beispiel-System 465 kann so konfiguriert sein, dass es das in 1 gezeigte Verfahren 100 implementiert. Das Verarbeitungssystem 400 enthält eine CPU 430, einen Switch 410 und jeweils mehrere PPUs 200 und entsprechende Speicher 204. Der NVLink 210 stellt Hochgeschwindigkeits-Kommunikationsverbindungen zwischen jeder der PPUs 200 bereit. Obwohl in 4B eine bestimmte Anzahl von Verbindungen mittels NVLink 210 und Verbindung 202 gezeigt ist, kann die Anzahl der Verbindungen zu jeder PPU 200 und der CPU 430 variieren. Der Switch 410 bildet eine Schnittstelle zwischen der Verbindung 202 und der CPU 430. Die PPUs 200, der Speicher 204 und die NVLinks 210 können sich auf einer einzelnen Halbleiterplattform befinden, um ein Parallelverarbeitungsmodul 425 zu bilden. In einer Ausführungsform unterstützt der Switch 410 zwei oder mehr Protokolle zur Schnittstellenbildung zwischen verschiedenen unterschiedlichen Verbindungen und/oder Links.
In einer weiteren Ausführungsform (nicht gezeigt) stellt der NVLink 210 eine oder mehrere Hochgeschwindigkeits-Kommunikationsverbindungen zwischen jeder der PPUs 200 und der CPU 430 bereit, und der Switch 410 bildet Schnittstellen zwischen der Verbindung 202 und jeder der PPUs 200. Die PPUs 200, die Speicher 204 und die Verbindung 202 können sich auf einer einzelnen Halbleiterplattform befinden, um ein Parallelverarbeitungsmodul 425 zu bilden. In noch einer Ausführungsform (nicht gezeigt) stellt die Verbindung 202 eine oder mehrere Kommunikationsverbindungen zwischen jeder der PPUs 200 und der CPU 430 bereit, und der Switch 410 bildet Schnittstellen zwischen jeder der PPUs 200 unter Verwendung des NVLinks 210, um eine oder mehrere Hochgeschwindigkeits-Kommunikationsverbindungen zwischen den PPUs 200 bereitzustellen. In noch einer Ausführungsform (nicht gezeigt) stellt der NVLink 210 eine oder mehrere Hochgeschwindigkeits-Kommunikationsverbindungen zwischen den PPUs 200 und der CPU 430 über den Switch 410 bereit. In noch einer Ausführungsform (nicht gezeigt) stellt die Verbindung 202 eine oder mehrere Kommunikationsverbindungen zwischen jeder der PPUs 200 direkt bereit. Eine oder mehrere der Hochgeschwindigkeits-Kommunikationsverbindungen NVLink 210 können als physische NVLink-Verbindung oder als On-Chip- oder On-Die-Verbindung unter Verwendung des gleichen Protokolls wie der NVLink 210 implementiert werden.
Im Kontext der vorliegenden Beschreibung kann sich eine einzelne Halbleiterplattform auf eine einzige einheitliche halbleiterbasierte integrierte Schaltung beziehen, die auf einem Die oder Chip hergestellt wird. Man beachte, dass sich der Begriff einzelne Halbleiterplattform auch auf Multichip-Module mit erhöhter Konnektivität beziehen kann, die On-Chip-Betrieb simulieren und wesentliche Verbesserungen gegenüber herkömmlicher Bus-Implementierung vornehmen. Natürlich können die verschiedenen Schaltungen oder Geräte nach den Wünschen des Benutzers auch getrennt oder in verschiedenen Kombinationen von Halbleiterplattformen angeordnet sein. Alternativ kann das Parallelverarbeitungsmodul 425 als ein Leiterplattensubstrat implementiert sein und kann jede(r) der PPUs 200 und/oder Speicher 204 als verpacktes Gerät ausgeführt sein. In einer Ausführungsform befinden sich die CPU 430, der Switch 410 und das Parallelverarbeitungsmodul 425 auf einer einzelnen Halbleiterplattform.
In einer Ausführungsform beträgt die Signalübertragungsrate jedes NVLink 210 20 bis 25 Gigabit/Sekunde und enthält jede PPU 200 sechs NVLink 210 Schnittstellen (wie in 4B gezeigt, sind fünf NVLink 210 Schnittstellen für jede PPU 200 enthalten). Jeder NVLink 210 bietet eine Datenübertragungsrate von 25 Gigabyte/Sekunde in jede Richtung, wobei sechs Links 300 Gigabyte/Sekunde liefern. Die NVLinks 210 werden möglicherweise ausschließlich für PPU-zu-PPU-Kommunikation verwendet, wie in 4B gezeigt, oder für irgendeine Kombination von PPU-zu-PPU und PPU-zu-CPU, wenn die CPU 430 ebenfalls eine oder mehrere NVLink 210 Schnittstellen enthält.
In einer Ausführungsform ermöglicht der NVLink 210 direkten Lade-/Speicher-/atomischen Zugriff von der CPU 430 auf den Speicher 204 jeder PPU 200. In einer Ausführungsform unterstützt der NVLink 210 Kohärenz-Operationen, so dass aus den Speichern 204 gelesene Daten in der Cache-Hierarchie der CPU 430 gespeichert werden können, was die Cache-Zugriffslatenz für die CPU 430 reduziert. In einer Ausführungsform enthält der NVLink 210 Unterstützung für Adressenübersetzungsdienste (ATS), so dass die PPU 200 direkt auf Seitentabellen innerhalb der CPU 430 zugreifen kann. Einer oder mehrere der NVLinks 210 können auch für Betrieb in einem Niedrigverbrauchsmodus konfiguriert sein.
4C veranschaulicht ein Beispiel-System 465, in dem die verschiedene Architektur und/oder Funktionalität der verschiedenen früheren Ausführungsformen implementiert sein kann. Das Beispiel-System 465 kann so konfiguriert sein, dass es das in 1 gezeigte Verfahren 100 implementiert.
Wie gezeigt, ist ein System 465 vorgesehen, das mindestens eine Zentralverarbeitungseinheit 430 enthält, die mit einem Kommunikationsbus 475 verbunden ist. Der Kommunikationsbus 475 kann unter Verwendung irgendeines geeigneten Protokolls implementiert werden, wie z. B. PCI (Peripheral Component Interconnect), PCI-Express, AGP (Accelerated Graphics Port), HyperTransport oder irgendeinem anderen Bus oder Punkt-zu-Punkt-Kommunikationsprotokoll(en). Das System 465 enthält auch einen Hauptspeicher 440. Steuerlogik (Software) und Daten werden im Hauptspeicher 440 gespeichert, der als Direktzugriffsspeicher (RAM) ausgeführt sein kann.
Das System 465 enthält auch Eingabegeräte 460, das Parallelverarbeitungssystem 425 und Display-Geräte 445, d. h. eine herkömmliche CRT (Kathodenstrahlröhre), ein LCD (Flüssigkristall-Display), eine LED (Leuchtdiode), ein Plasma-Display oder dergleichen. Benutzereingaben können von den Eingabegeräten 460 empfangen werden, z. B. einer Tastatur, einer Maus, einem Touchpad, einem Mikrofon und dergleichen. Jedes der vorgenannten Module und/oder Geräte kann sich sogar auf einer einzelnen Halbleiterplattform befinden, um das System 465 zu bilden. Alternativ können die verschiedenen Module auch getrennt oder in verschiedenen Kombinationen von Halbleiterplattformen nach den Wünschen des Anwenders angeordnet werden.
Weiterhin kann das System 465 zu Kommunikationszwecken über eine Netzschnittstelle 435 mit einem Netz (z. B. einem Telekommunikationsnetz, Lokalen Netz (LAN), Drahtlosnetz, Weitverkehrsnetz (WAN) wie z. B. das Internet, Peer-to-Peer-Netz, Kabelnetz oder dergleichen) gekoppelt sein.
Das System 465 kann auch einen Sekundärspeicher enthalten (nicht gezeigt). Der Sekundärspeicher enthält zum Beispiel ein Festplattenlaufwerk und/oder ein Wechselspeicherlaufwerk, das ein Diskettenlaufwerk, ein Magnetbandlaufwerk, ein CD-Laufwerk, ein DVD-Laufwerk, ein Aufzeichnungsgerät oder einen USB-Flashspeicher repräsentiert. Das Wechselspeicherlaufwerk liest und/oder schreibt in einer bekannten Weise von einer bzw. auf eine Wechselspeicher-Einheit.
Computerprogramme oder Computer-Steuerlogikalgorithmen können in dem Hauptspeicher 440 und/oder dem Sekundärspeicher gespeichert werden. Solche Computerprogramme ermöglichen es dem System 465, verschiedene Funktionen durchzuführen, wenn sie ausgeführt werden. Der Speicher 440, der Sekundärspeicher und/oder irgendwelche anderen Speicher sind mögliche Beispiele von computerlesbaren Medien.
Die Architektur und/oder Funktionalität der verschiedenen vorhergehenden Figuren kann im Kontext eines allgemeinen Computersystems, eines Platinensystems, eines Spielkonsolensystems für Unterhaltungszwecke, eines anwendungsspezifischen Systems und/oder irgendeines anderen gewünschten Systems implementiert werden. Das System 465 kann zum Beispiel die Form eines Desktop-Computers, eines Laptop-Computers, eines Tablet-Computers, von Servern, Supercomputern, eines Smartphones (z. B. eines drahtlosen, tragbaren Geräts), eines persönlichen digitalen Assistenten (PDA), einer Digitalkamera, eines Fahrzeugs, eines kopfmontierten Displays, eines tragbaren elektronischen Geräts, eines Mobiltelefongeräts, eines Fernsehgeräts, einer Workstation, einer Spielkonsole, eines eingebetteten Systems und/oder eines anderen Typs von Logik annehmen.
Obwohl verschiedene Ausführungsformen vorstehend beschrieben worden sind, versteht es sich, dass sie nur als Beispiel und nicht als Einschränkung präsentiert worden sind. Daher sind die Breite und der Schutzumfang einer bevorzugten Ausführungsform nicht durch irgendwelche der oben beschriebenen Ausführungsbeispiele einzuschränken, sondern nur in Übereinstimmung mit den folgenden Ansprüchen und ihren Äquivalenten zu definieren.
Grafikverarbeitungs-Pipeline
In einer Ausführungsform umfasst die PPU 200 eine Grafikverarbeitungseinheit (GPU). Die PPU 200 ist so konfiguriert, dass sie Befehle empfängt, die Shader-Programme zur Verarbeitung von Grafikdaten spezifizieren. Grafikdaten können als eine Menge von Primitiven definiert sein, wie z. B. Punkte, Linien, Dreiecke, Vierecke, Dreiecksstreifen und dergleichen. Typischerweise enthält ein Primitiv Daten, die eine Anzahl von Vertices bzw. Eckpunkten für das Primitiv spezifizieren (z. B. in einem Modell-Raum-Koordinatensystem), sowie Attribute, die einem jedem Vertex des Primitivs zugeordnet sind. Die PPU 200 kann so konfiguriert sein, dass sie die Grafik-Primitive verarbeitet, um einen Bildpuffer zu erzeugen (d. h. Pixeldaten für jedes Pixel des Displays).
Eine Anwendung schreibt Modelldaten für eine Szene (d. h. eine Sammlung von Vertices und Attributen) in einen Speicher, wie z. B. einen Systemspeicher oder Speicher 204. Die Modelldaten definieren jedes der Objekte, die auf einem Display sichtbar sein können. Die Anwendung führt dann einen API-Aufruf an den Treiber-Kernel durch, der anfordert, dass die Modelldaten gerendert und angezeigt werden. Der Treiber-Kernel liest die Modelldaten und schreibt Befehle an die ein oder mehreren Ströme, um Operationen zur Verarbeitung der Modelldaten durchzuführen. Die Befehle können sich auf verschiedene Shader-Programme beziehen, die auf den SMs 340 der PPU 200 implementiert werden sollen, einschließlich eines oder mehrerer Vertex-Shader, Hull-Shader, Domain-Shader, Geometrie-Shader und Pixel-Shader. Beispielsweise kann ein oder können mehrere SMs 340 so konfiguriert sein, dass sie ein Vertex-Shader-Programm ausführen, das eine Anzahl von Vertices verarbeitet, die durch die Modelldaten definiert sind. In einer Ausführungsform können die verschiedenen SMs 340 so konfiguriert sein, dass sie verschiedene Shader-Programme gleichzeitig ausführen. Zum Beispiel kann eine erste Teilmenge von SMs 340 so konfiguriert sein, dass sie ein Vertex-Shader-Programm ausführt, während eine zweite Teilmenge von SMs 340 so konfiguriert sein kann, dass sie ein Pixel-Shader-Programm ausführt. Die erste Teilmenge von SMs 340 verarbeitet Vertexdaten zu verarbeiteten Vertexdaten und schreibt die verarbeiteten Vertexdaten in den L2-Cache 360 und/oder den Speicher 204. Nachdem die verarbeiteten Vertexdaten gerastert (d. h. von dreidimensionalen Daten in zweidimensionale Daten im Bildschirmraum transformiert) wurden, um Fragmentdaten zu erzeugen, führt die zweite Teilmenge von SMs 340 einen Pixel-Shader aus, um verarbeitete Fragmentdaten zu erzeugen, die dann mit anderen verarbeiteten Fragmentdaten gemischt und in den Bildpuffer im Speicher 204 geschrieben werden. Das Vertex-Shader-Programm und das Pixel-Shader-Programm können gleichzeitig ausgeführt werden, wobei unterschiedliche Daten derselben Szene gemäß einem Pipeline-Vorgehen verarbeitet werden, bis alle Modelldaten für die Szene in den Bildpuffer gerendert worden sind. Anschließend wird der Inhalt des Bildpuffers an eine Display-Steuerung zur Anzeige auf einem Display-Gerät übertragen.
5 ist ein konzeptionelles Diagramm einer von der PPU von 2 implementierten Grafikverarbeitungs-Pipeline gemäß einer Ausführungsform. Die Grafikverarbeitungs-Pipeline 500 ist ein abstraktes Flussdiagramm der zur Erzeugung von 2D-Computerbildern aus 3D-Geometriedaten implementierten Verarbeitungsschritte. Wie bekannt, können Pipeline-Architekturen Operationen mit langer Latenz effizienter durchführen, indem sie die Operation in eine Vielzahl von Stufen aufteilen, wobei der Ausgang jeder Stufe mit dem Eingang der nächstfolgenden Stufe gekoppelt ist. Somit empfängt die Grafikverarbeitungs-Pipeline 500 Eingabedaten 501, die von einer Stufe zur nächsten Stufe der Grafikverarbeitungs-Pipeline 500 übertragen werden, um Ausgabedaten 502 zu erzeugen. In einer Ausführungsform kann die Grafikverarbeitungs-Pipeline 500 eine durch die OpenGL^®-API definierte Grafikverarbeitungs-Pipeline repräsentieren. Optional kann die Grafikverarbeitungs-Pipeline 500 im Kontext der Funktionalität und Architektur der vorherigen Figuren und/oder irgendwelcher nachfolgenden Figur(en) implementiert werden.
Wie in 5 gezeigt, weist die Grafikverarbeitungs-Pipeline 500 eine Pipeline-Architektur auf, die mehrere Stufen umfasst. Die Stufen umfassen, sind aber nicht beschränkt auf, eine Datenaufbaustufe 510, eine Vertex-Shading-Stufe 520, eine Primitiv-Aufbaustufe 530, eine Geometrie-Shading-Stufe 540, eine Viewport Skalier-, Cull und Clip (VSCC) Stufe 550, eine Rasterungsstufe 560, eine Fragment-Shading-Stufe 570 und eine Rasteroperationen-Stufe 580. Die Eingabedaten 501 umfassen in einer Ausführungsform Befehle, die die Verarbeitungseinheiten so konfigurieren, dass die Stufen der Grafikverarbeitungs-Pipeline 500 und geometrische Primitive (z. B. Punkte, Linien, Dreiecke, Quadrate, Dreieckstreifen oder Fächer usw.), die von den Stufen zu verarbeiten sind, implementiert werden. Die Ausgabedaten 502 können Pixeldaten (d. h. Farbdaten) umfassen, die in einen Bildpuffer oder eine andere Art von Oberflächendatenstruktur in einem Speicher kopiert werden.
Die Datenaufbaustufe 510 empfängt die Eingabedaten 501, die Vertexdaten für Oberflächen höherer Ordnung, Primitive oder dergleichen spezifizieren. Die Datenaufbaustufe 510 sammelt die Vertexdaten in einem temporären Speicher oder einer Warteschlange, wie z. B. durch Empfangen eines Befehls vom Host-Prozessor, der einen Zeiger auf einen Puffer im Speicher enthält, und Lesen der Vertexdaten aus dem Puffer. Die Vertexdaten werden dann zur Verarbeitung an die Vertex-Shading-Stufe 520 übertragen.
Die Vertex-Shading-Stufe 520 verarbeitet Vertexdaten, indem sie eine Reihe von Operationen (d. h. einen Vertex-Shader oder ein Programm) einmal für jeden der Vertices ausführt. Vertices können z. B. als ein 4-Koordinaten-Vektor (d. h. <x, y, z, w>) angegeben werden, der einem oder mehreren Vertex-Attributen zugeordnet ist (z. B. Farbe, Texturkoordinaten, Flächennormale, usw.). Die Vertex-Shading-Stufe 520 kann einzelne Vertex-Attribute wie z. B. Position, Farbe, Texturkoordinaten und dergleichen handhaben. Mit anderen Worten führt die Vertex-Shading-Stufe 520 Operationen an den Vertex-Koordinaten oder anderen Vertex-Attributen durch, die einem Vertex zugeordnet sind. Solche Operationen umfassen gewöhnlich Ausleuchtungsoperationen (d. h. Modifizieren von Farbattributen für einen Vertex) und Transformationsoperationen (d. h. Modifizieren des Koordinatenraums für einen Vertex). Zum Beispiel können Vertices mit Hilfe von Koordinaten in einem Objekt-Koordinatenraum spezifiziert werden, welche durch Multiplikation der Koordinaten mit einer Matrix transformiert werden, die die Koordinaten aus dem Objekt-Koordinatenraum in einen World-Space oder einen NCD-Raum (Raum mit normierten Gerätekoordinaten) übersetzt. Die Vertex-Shading-Stufe 520 erzeugt transformierte Vertexdaten, die an die Primitiv-Aufbaustufe 530 übertragen werden.
Die Primitiv-Aufbaustufe 530 sammelt Vertices, die von der Vertex-Shading-Stufe 520 ausgegeben werden, und gruppiert die Vertices zu geometrischen Primitiven für Verarbeitung durch die Geometrie-Shading-Stufe 540. Zum Beispiel kann die Primitiv-Aufbaustufe 530 so konfiguriert sein, dass sie immer drei aufeinanderfolgende Vertices als ein geometrisches Primitiv (d. h. ein Dreieck) für Übertragung an die Geometrie-Shading-Stufe 540 gruppiert. In manchen Ausführungsformen können bestimmte Vertices für aufeinanderfolgende geometrische Primitive wiederverwendet werden (z. B. können zwei aufeinanderfolgende Dreiecke in einem Dreieckstreifen zwei Vertices gemeinsam benutzen). Die Primitiv-Aufbaustufe 530 überträgt geometrische Primitive (d. h. eine Sammlung von zugehörigen Vertices) an die Geometrie-Shading-Stufe 540.
Die Geometrie-Shading-Stufe 540 verarbeitet geometrische Primitive, indem sie eine Reihe von Operationen (d. h. einen Geometrie-Shader oder ein Programm) an den geometrischen Primitiven ausführt. Tesselierungs-Operationen können aus jedem geometrischen Primitiv ein oder mehrere geometrische Primitive erzeugen. Mit anderen Worten kann die Geometrie-Shading-Stufe 540 jedes geometrische Primitiv in ein feineres Geflecht aus zwei oder mehr geometrischen Primitiven für Verarbeitung durch den Rest der Grafikverarbeitungs-Pipeline 500 unterteilen. Die Geometrie-Shading-Stufe 540 überträgt geometrische Primitive an die Viewport SCC Stufe 550.
In einer Ausführungsform kann die Grafikverarbeitungs-Pipeline 500 innerhalb eines Streaming-Multiprozessors arbeiten, und die Vertex-Shading-Stufe 520, die Primitiv-Aufbaustufe 530, die Geometrie-Shading-Stufe 540, die Fragment-Shading-Stufe 570 und/oder damit verbundene Hard- bzw. Software können sequentiell Verarbeitungsoperationen durchführen. Sobald die sequentiellen Verarbeitungsoperationen abgeschlossen sind, kann in einer Ausführungsform die Viewport SCC Stufe 550 die Daten verwenden. In einer Ausführungsform können von einer oder mehreren Stufen der Grafikverarbeitungs-Pipeline 500 verarbeitete Primitiv-Daten in einen Cache geschrieben werden (z. B. L1-Cache, einen Vertex-Cache, usw.). In diesem Fall kann die Viewport SCC Stufe 550 in einer Ausführungsform auf die Daten im Cache zugreifen. In einer Ausführungsform sind die Viewport SCC Stufe 550 und die Rasterungsstufe 560 als Schaltungen mit festgelegter Funktion implementiert.
Die Viewport SCC Stufe 550 führt die Skalierung, das Culling und das Clipping der geometrischen Primitive durch. Jeder Oberfläche, die gerendert wird, ist eine abstrakte Kameraposition zugeordnet. Die Kameraposition stellt den Standort eines Betrachters dar, der auf die Szene schaut, und definiert einen Betrachtungsstumpf, der die Objekte der Szene umschließt. Der Betrachtungsstumpf kann eine Betrachtungsebene, eine hintere Ebene und vier Clipping-Ebenen umfassen. Jedes geometrische Primitiv, das sich vollständig außerhalb des Betrachtungsstumpfs befindet, kann einem Culling unterzogen (d. h. verworfen) werden, da das geometrische Primitiv nicht zu der endgültigen gerenderten Szene beiträgt. Irgendein geometrisches Primitiv, das sich teils innerhalb des Betrachtungsstumpfs und teils außerhalb des Betrachtungsstumpfs befindet, kann abgeschnitten werden (d. h. in ein neues geometrisches Primitiv umgewandelt werden, das innerhalb des Betrachtungsstumpfs eingeschlossen ist). Darüber hinaus können geometrische Primitive jeweils auf Basis einer Tiefe des Betrachtungsstumpfs skaliert werden. Alle potentiell sichtbaren geometrischen Primitive werden dann in die Rasterungsstufe 560 übertragen.
Die Rasterungsstufe 560 wandelt die geometrischen 3D-Primitive in 2D-Fragmente um (z. B. für Anzeige usw. verwendbar). Die Rasterungsstufe 560 kann so konfiguriert sein, dass sie die Vertices der geometrischen Primitive verwendet, um einen Satz von Ebenengleichungen zu erstellen, aus denen verschiedene Attribute interpoliert werden können. Die Rasterungsstufe 560 kann auch eine Abdeckungsmaske für eine Vielzahl von Pixeln berechnen, die angibt, ob eine oder mehrere Abtast-Positionen für das Pixel das geometrische Primitiv abschneiden. In einer Ausführungsform kann auch Z-Testen durchgeführt werden, um zu bestimmen, ob das geometrische Primitiv von anderen geometrischen Primitiven, die bereits gerastert wurden, verdeckt wird. Die Rasterungsstufe 560 erzeugt Fragmentdaten (d. h. interpolierte Vertex-Attribute, die einer bestimmten Abtast-Position für jedes abgedeckte Pixel zugeordnet sind), die an die Fragment-Shading-Stufe 570 übertragen werden.
Die Fragment-Shading-Stufe 570 verarbeitet Fragmentdaten, indem sie eine Reihe von Operationen (z. B. einen Fragment-Shader oder ein Programm) an jedem der Fragmente durchführt. Die Fragment-Shading-Stufe 570 kann Pixeldaten (d. h. Farbwerte) für das Fragment erzeugen, z. B. indem sie Ausleuchtungs-Operationen oder Abtasten von Texturabbildungen unter Verwendung interpolierter Texturkoordinaten für das Fragment durchführt. Die Fragment-Shading-Stufe 570 erzeugt Pixeldaten, die an die Rasteroperationen-Stufe 580 übertragen werden.
Die Rasteroperationen-Stufe 580 kann verschiedene Operationen an den Pixeldaten durchführen, wie z. B. Alpha-Tests, Schablonentests und Mischen der Pixeldaten mit anderen Pixeldaten, die anderen Fragmenten entsprechen, die dem Pixel zugeordnet sind. Wenn die Rasteroperationen-Stufe 580 die Verarbeitung der Pixeldaten (d. h. der Ausgabedaten 502) abgeschlossen hat, können die Pixeldaten in ein Renderziel wie z. B. einen Bildpuffer, einen Farbpuffer oder dergleichen geschrieben werden.
Man beachte, dass eine oder mehrere zusätzliche Stufen zusätzlich zu oder anstelle einer oder mehreren der oben beschriebenen Stufen in die Grafikverarbeitungs-Pipeline 500 aufgenommen werden können. Verschiedene Implementierungen der abstrakten Grafikverarbeitungs-Pipeline können unterschiedliche Stufen implementieren. Darüber hinaus können in manchen Ausführungsformen eine oder mehrere der oben beschriebenen Stufen (wie z. B. die Geometrie-Shading-Stufe 540) von der Grafikverarbeitungs-Pipeline ausgeschlossen sein. Andere Arten von Grafikverarbeitungs-Pipelines werden als im Schutzumfang der vorliegenden Offenbarung liegend betrachtet. Darüber hinaus kann jede der Stufen der Grafikverarbeitungs-Pipeline 500 von einer oder mehreren dedizierten Hardware-Einheiten innerhalb eines Grafikprozessors wie z. B. der PPU 200 implementiert werden. Andere Stufen der Grafikverarbeitungs-Pipeline 500 können durch programmierbare Hardware-Einheiten wie z. B. den SM 340 der PPU 200 implementiert werden.
Die Grafikverarbeitungs-Pipeline 500 kann über eine Anwendung implementiert werden, die von einem Host-Prozessor ausgeführt wird, wie z. B. einer CPU. In einer Ausführungsform kann ein Gerätetreiber eine Anwendungsprogrammierschnittstelle (API) implementieren, welche verschiedene Funktionen definiert, die von einer Anwendung genutzt werden können, um grafische Daten für Anzeige zu generieren. Der Gerätetreiber ist ein Softwareprogramm, das eine Vielzahl von Anweisungen enthält, die den Betrieb der PPU 200 steuern. Die API bietet eine Abstraktion für einen Programmierer, die es einem Programmierer ermöglicht, spezielle Grafikhardware wie z. B. die PPU 200 zu verwenden, um die grafischen Daten zu erzeugen, ohne dass der Programmierer den spezifischen Befehlssatz für die PPU 200 verwenden muss. Die Anwendung kann einen API-Aufruf enthalten, der an den Gerätetreiber für die PPU 200 weitergeleitet wird. Der Gerätetreiber interpretiert den API-Aufruf und führt verschiedene Operationen durch, um auf den API-Aufruf zu reagieren. In manchen Fällen kann der Gerätetreiber Operationen durchführen, indem er Anweisungen auf der CPU ausführt. In anderen Fällen kann der Gerätetreiber zumindest teilweise Operationen durchführen, indem er Operationen auf der PPU 200 über eine Eingabe/Ausgabe-Schnittstelle zwischen der CPU und der PPU 200 startet. In einer Ausführungsform ist der Gerätetreiber so konfiguriert, dass er die Grafikverarbeitungs-Pipeline 500 unter Verwendung der Hardware der PPU 200 implementiert.
Innerhalb der PPU 200 können verschiedene Programme ausgeführt werden, um die verschiedenen Stufen der Grafikverarbeitungs-Pipeline 500 zu implementieren. Zum Beispiel kann der Gerätetreiber einen Kernel auf der PPU 200 starten, um die Vertex-Shading-Stufe 520 auf einem SM 340 (oder mehreren SMs 340) durchzuführen. Der Gerätetreiber (oder der von der PPU 300 ausgeführte anfängliche Kernel) kann auch andere Kernel auf der PPU 300 starten, um andere Stufen der Grafikverarbeitungs-Pipeline 500 auszuführen, wie z. B. die Geometrie-Shading-Stufe 540 und die Fragment-Shading-Stufe 570. Darüber hinaus können einige der Stufen der Grafikverarbeitungs-Pipeline 500 auf Festeinheiten-Hardware implementiert werden, wie z. B. einem Rasterer oder einem Datenassembler, der in der PPU 200 implementiert ist. Man beachte, dass Ergebnisse aus einem Kernel von einer oder mehreren dazwischenliegenden Hardware-Einheiten mit fester Funktion verarbeitet werden können, bevor sie von einem nachfolgenden Kernel auf einem SM 340 verarbeitet werden.
Maschinelles Lernen
Tiefe neuronale Netze (DNNs), die auf Prozessoren wie z. B. der PPU 200 entwickelt wurden, hat man für verschiedene Anwendungsfälle eingesetzt, von selbstfahrenden Automobilen bis hin zu schnellerer Medikamentenentwicklung, von automatischer Bilderfassung in Online-Bilddatenbanken bis hin zur intelligenter Echtzeit-Sprachübersetzung in Video-Chat-Anwendungen. Deep Learning ist eine Technik, die den neuronalen Lernprozess des menschlichen Gehirns modelliert, kontinuierlich lernt, kontinuierlich intelligenter wird und im Laufe der Zeit schneller genauere Ergebnisse liefert. Ein Kind wird zunächst von einem Erwachsenen gelehrt, verschiedene Formen richtig zu identifizieren und zu klassifizieren, um schließlich ohne Nachhilfe Formen identifizieren zu können. Ähnlich muss ein System für Deep Learning oder neuronales Lernen in Objekterkennung und -klassifizierung trainiert werden, damit es intelligenter und effizienter wird, grundlegende Objekte, verdeckte Objekte usw. zu identifizieren und den Objekten auch Kontext zuzuweisen.
Auf der einfachsten Ebene betrachten Neuronen im menschlichen Gehirn verschiedene Eingaben, die empfangen werden, jedem dieser Inputs werden Wichtigkeitsstufen zugewiesen, und Ausgaben werden an andere Neuronen weitergeleitet, um darauf zu reagieren. Ein künstliches Neuron oder Perzeptron ist das grundlegendste Modell eines neuronalen Netzes. In einem Beispiel kann ein Perzeptron eine oder mehrere Eingaben empfangen, die verschiedene Merkmale eines Objekts repräsentieren, für die das Perzeptron trainiert wird, sie zu erkennen und zu klassifizieren, und jedem dieser Merkmale wird ein bestimmtes Gewicht zugewiesen, das auf der Wichtigkeit dieses Merkmals für die Definition der Form eines Objekts basiert.
Ein DNN-Modell enthält mehrere Schichten vieler verbundener Perzeptronen (z. B. Knoten), die mit enormen Mengen Eingabedaten trainiert werden können, um komplexe Probleme schnell und mit hoher Genauigkeit zu lösen. In einem Beispiel zerlegt eine erste Schicht des DLL-Modells ein Eingabebild eines Automobils in verschiedene Teile und sucht nach Grundmustern wie z. B. Linien und Winkeln. Die zweite Schicht setzt die Linien zusammen, um nach Mustern höherer Ebenen wie z. B. Rädern, Windschutzscheiben und Spiegeln zu suchen. Die nächste Schicht identifiziert den Fahrzeugtyp, und die letzten paar Schichten erzeugen ein Etikett für das Eingabebild, welches das Modell einer bestimmten Fahrzeugmarke identifiziert.
Sobald das DNN trainiert ist, kann das DNN eingesetzt und verwendet werden, um Objekte oder Muster in einem als Schlussfolgerung bekannten Prozess zu identifizieren und zu klassifizieren. Beispiele für eine Schlussfolgerung (den Prozess, durch den ein DNN nützliche Informationen aus einer gegebenen Eingabe extrahiert) umfassen das Identifizieren von handschriftlichen Zahlen auf in Geldautomaten gelegten Schecks, das Identifizieren von Bildern von Freunden auf Fotos, das Liefern von Filmempfehlungen an über fünfzig Millionen Benutzer, das Identifizieren und Klassifizieren von verschiedenen Arten von Automobilen, Fußgängern und Straßengefahren in fahrerlosen Fahrzeugen oder das Übersetzen von menschlicher Sprache in Echtzeit.
Während des Trainings fließen die Daten in einer Vorwärtspropagierungs-Phase durch das DNN, bis eine Vorhersage erzeugt wird, die ein der Eingabe entsprechendes Etikett anzeigt. Wenn das neuronale Netz die Eingabe nicht korrekt etikettiert, werden Fehler zwischen dem korrekten Etikett und dem vorhergesagten Etikett analysiert und werden die Gewichte für jedes Merkmal während einer Rückwärtspropagierungs-Phase angepasst, bis der DNN die Eingabe und andere Eingaben in einem Trainingsdatensatz korrekt etikettiert. Das Training komplexer neuronaler Netze erfordert enorme Mengen an Parallelrechenleistung, einschließlich Gleitkomma-Multiplikationen
und -Additionen, die von der PPU 200 unterstützt werden. Schlussfolgerung ist weniger rechenintensiv als Training, da es sich um einen latenzsensitiven Prozess handelt, bei dem ein trainiertes neuronales Netz auf neue Eingaben angewendet wird, die es vorher nicht gegeben hat, um Bilder zu klassifizieren, Sprache zu übersetzen und allgemein neue Informationen zu schlussfolgern.
Neuronale Netze sind stark auf mathematische Matrix-Operationen angewiesen, und komplexe mehrschichtige Netze erfordern enorme Mengen an Gleitkommaleistung und Bandbreite für Effizienz und Geschwindigkeit. Mit Tausenden von Verarbeitungs-Rechenkernen, die für mathematische Matrix-Operationen optimiert sind und mehrere zehn bis Hunderte TFLOPS Leistung liefern, ist die PPU 200 eine Computerplattform, die in der Lage ist, die für tiefe neuronale netzbasierte künstliche Intelligenz und Anwendungen für maschinelles Lernen erforderliche Leistung zu liefern.
Lernen von binären Rest-Darstellungen für gebietsspezifisches Video-Streaming
Video-Streaming-Dienste sind heutzutage beliebte Verfahren, um Unterhaltungsinhalte zu betrachten. Aufgrund großer Video-Größen und begrenzter Netzbandbreite ist Videokompression erforderlich, um Videoinhalte von Servern an Clients zu streamen. Zwar kann Videokompression die Größe eines Videos reduzieren, doch geht sie oft mit unerwünschten Kompressions-Artefakten wie z. B. Bildblockungseffekten und Unschärfeeffekten einher.
In einer Ausführungsform stellen wir die Hypothese auf, dass man die Rest-Informationen wirkungsvoll komprimieren kann, um die Videokompressionsleistung zu steigern, wenn man bereit ist, die Verwendung des Videokompressionsverfahrens auf ein bestimmtes Gebiet zu beschränken. Mit anderen Worten, wir wollen kein Videokompressionsverfahren mehr, das bei allen Videos universell gut arbeitet. Wir wollen nur ein Verfahren, das auf einem bestimmten Gebiet besonders gut arbeitet. Dieses Setting passt möglicherweise gut zu Video-Streaming-Anwendungen wie z. B. Videospiel-Streaming und Sport-Streaming. So wählt der Spieler zum Beispiel für Videospiel-Streaming-Dienste einen Spiel-Titel zum Abspielen aus, und die Videoinhalte werden auf dem Server gerendert und an ein mobiles Bedienungspult des Kunden übermittelt.
Während der Zeitspanne, in der das Spiel gespielt wird, liegen alle Videoinhalte im Stream auf demselben Videospiel-Gebiet, und ein gebietsspezifisches Videokompressionsverfahren ist völlig angemessen. Das Setting passt auch zu anderen Anwendungsfällen wie z. B. Streaming von Sportarten, die oft auf eine bestimmte Disziplin beschränkt sind, und auch zu Dingen wie dem Komprimieren von Dash-Cam-Videos, da es sich bei allen Videos um Straßenszenen handelt.
Um unsere Hypothese zu verifizieren, nutzen wir Deep-Learning-Modelle, die sich als leistungsfähige Approximierer für nichtlineare Funktionen etabliert haben, um die hochgradig nichtlinearen Rest-Informationen zu codieren. In unserer Videokompressions-Pipeline wenden wir zuerst H.264 an, um Videos auf einem bestimmten Gebiet zu komprimieren, und trainieren einen neuartigen Binär-Autoencoder, um die resultierenden Rest-Informationen Einzelbild für Einzelbild in eine binäre Darstellung zu codieren.
Wir wenden dann Huffman-Codierung an, um die binären Darstellungen verlustfrei zu komprimieren. Die komprimierten binären Darstellungen können in dem Metadatenfeld im H.264-Streaming-Paket an den Client gesendet werden. Auf diese Weise kann unser Verfahren in den bestehenden Video-Streaming-Standard integriert werden. Wir zeigen, dass man mit unserer vorgeschlagenen binären Rest-Darstellung eine bessere Videoqualität (bei einer gewählten Bandbreite) erzielen kann, indem man den Video-Stream unter Verwendung von H.264 mit einer kleineren Bandbreite sendet und die eingesparte Bandbreite zur Übertragung der gelernten binären Rest-Darstellung nutzt.
Wir führen umfangreiche Experimente durch, um unsere Hypothese zu verifizieren, dass wir Videokompressionsverfahren des Standes der Technik verbessern können, indem wir lernen, die gebietsspezifischen Rest-Informationen in einer binären Form zu codieren. Wir vergleichen auch verschiedene Methoden zum Trainieren des vorgeschlagenen Binär-Autoencoders zum Codieren der Rest-Informationen.
Gebietsspezifische Videokompression mit Rest-Autoencoder
Hier stellen wir zunächst unsere Videokompressions-Pipeline für das Streaming von gebietsspezifischen Videos vor. Anschließend präsentieren wir die Details unseres Autoencoders zum Codieren der Rest-Informationen in binäre Formen und die Trainingsmethoden.
Video-Streaming-Pipeline
Eine Beispiel-Pipeline besteht sie aus zwei Modulen: einem Videokompressions-Modul und einem auf Deep Learning basierenden Autoencoder. Das Videokompressions-Modul verwendet den H.264-Standard, der gute Leistung beim Komprimieren zeitlich glatter Bildsignale gezeigt hat, während unser Rest-Autoencoder hilft, die verlorenen Informationen während der Komprimierung auf der Client-Seite wiederherzustellen, indem er die Eigenschaft nutzt, dass die zu komprimierenden Videos aus demselben Gebiet kommen. Mit einer solchen hybriden Methode können wir nicht nur die Ausgabequalität mit geringem Aufwand verbessern, sondern auch das System an bestehende Kompressions-Plattformen anpassen und durch Verwerten umfangreicher Daten für bestimmte Gebiete trainieren.
6 veranschaulicht einen Beispiel-Überblick über eine Video-Streaming-Pipeline 600 gemäß einer Ausführungsform. Die Pipeline 600 besteht aus zwei Modulen: einem konventionellen H.264-Modul 602 und einem Rest-Autoencoder-Modul 604. Die Eingabe in unser Rest-Autoencoder-Modul 604 ist die Differenz 606 zwischen dem Originalvideo 608 und dem komprimierten Video 610. Die Differenz 606 wird codiert und binarisiert, um binäre Darstellungen zu erzeugen. Wir verwenden einen Huffman-Encoder 612, um die binären Darstellungen weiter verlustfrei in einen Bitstrom zu komprimieren. Auf der Client-Seite decodieren wir das Video unter Verwendung eines Huffman-Decoders 614 und eines Rest-Decoders 616 und rekonstruieren das Ausgabe-Video 618, indem wir die decodierte Differenz 620 wieder zu dem komprimierten Video 622 hinzufügen.
Man beachte, dass wir zwar H.264 in unserer Pipeline verwenden, dass aber auch andere Videokompressions-Standards wie z. B. MPEG4 und HEVC verwendet werden können. Bei einem Eingabe-Video X erhalten wir das komprimierte Video Y durch Anwenden von H.264. Die Differenz zwischen den beiden Videos wird als die Rest-Informationen R = X - Y bezeichnet. Je größer die Rest-Informationen, desto schlechter die Qualität des komprimierten Videos. Man beachte auch, dass R nicht in Y enthalten ist, da es aus hochgradig nichtlinearen Mustern besteht, die mit herkömmlichen Methoden nicht wirkungsvoll komprimiert werden können.
Wir behaupten, dass wir durch Einschränken des Video-Gebiets einen neuartigen Autoencoder nutzen konnten, um die Rest-Informationen wirkungsvoll zu komprimieren. Der Autoencoder besteht aus einem Paar Funktionen $(E, D),$
wobei der Encoder $E$
die Funktion R auf eine binäre Abbildung abbildet und der Decoder $D$
die Funktion R aus der binären Abbildung auf der Client-Seite wiederherstellt. Die wiederhergestellten Rest-Informationen werden als R̂ bezeichnet, und das endgültige Ausgabe-Video Y + R hat eine bessere Bildqualität als Y. Wir stellen fest, dass die binäre Abbildung weiterhin auf einen Bitstrom abgebildet wird, indem der Huffman-Codierungsalgorithmus verwendet wird, der asymptotisch optimal ist, um seine Bandbreitenverwendung zu reduzieren.
Das Senden des Bitstroms der Rest-Informationen erfordert zusätzliche Bandbreite. Wir können jedoch einen Autoencoder trainieren, der lediglich eine viel kleinere Bandbreite benötigt, um die Rest-Informationen zu komprimieren, als H.264. Daher können wir den H.264-Standard in einer höheren Kompressionsrate laufen lassen, die eine geringere Bandbreite verwendet, aber in einem größeren Rest-Signal resultiert. Wir wenden dann unseren Autoencoder an, um das Rest-Signal zu einem kleinen Bitstrom zu komprimieren. Betrachten wir ein Szenario, in dem die Bandbreite für einen Video-Stream 5 Mbit/s beträgt, können wir die vorgeschlagene Pipeline anwenden, um das Video unter Verwendung von H.264 in 4 Mbit/s zu komprimieren und die restlichen 1 Mbit/s für das Senden des Rest-Signals zu verwenden. Da unser Autoencoder beim Komprimieren des Rest-Signals effizienter ist als H.264, erzielt unser System eine bessere Leistung als ein Basis-System, das alle 5 Mbit/s für H.264 vergibt.
Man kann sich fragen, weshalb der H.264-Standard nicht vollständig durch den vorgeschlagenen Rest-Autoencoder ersetzt wird. Wir behaupten, dass unser Rest-Autoencoder nur beim Komprimieren des Rest-Signals effizienter ist als H.264. Das sorgfältig entwickelte H.264 ist beim Komprimieren des Kern-Videos effizienter. Durch Verheiraten der Stärke von H.264 und des vorgeschlagenen Autoencoders erzielt unser Hybrid-System bessere Leistung.
Darüber hinaus lässt sich unsere Pipeline leicht in den bestehenden H.264-Standard integrieren, da die Rest-Informationen im Metafeld eines H.264-Streaming-Pakets angehängt werden können. Daher können wir die Popularität des H.264-Standards und verschiedener für H.264 implementierter Hardwarebeschleuniger genießen.
Wir stellen fest, dass man in der vorgeschlagenen gebietsspezifischen Video-Streaming-Pipeline möglicherweise die Parameter von $D$
und die Huffman-Decoder-Tabelle an den Client für den Streaming-Service senden muss, was zusätzliche Bandbreite erfordert. Die Parameter können jedoch vor Beginn des Streamings gesendet werden. Sobald die Parameter gesendet sind, kann der Benutzer die Merkmale niedrige Latenzzeit und hohe Videoqualität der vorgeschlagenen Video-Streaming-Pipeline genießen.
Binärer Rest-Autoencoder
Wir gestalten einen Autoencoder, der aus drei Komponenten besteht: Encoder $E$
Binarisierer $B$
und Decoder $D .$
Für den Encoder ist es ein Beispiel-Ziel, zu lernen, kompakte Merkmal-Darstellungen für den folgenden Binarisierer zu extrahieren. Wir verwenden L Faltungsschichten in unserem Encoder, wobei jede Schicht dieselbe Kanalzahl C und eine Schrittgröße zwei hat, die Merkmal-Abbildungen (Feature Maps) heruntertaktet. Der Binarisierer wandelt die Ausgabe der letzten Faltungsschicht in eine binäre Abbildung um. Für den Decoder ist es unser Ziel, die binäre Abbildung wieder auf die ursprüngliche Eingabe hochzutakten. Unser Decoder hat L Faltungsschichten.
Am Ende jeder Faltungsschicht wird eine Subpixelschicht zum Hochtakten verwendet. Da wir darauf abzielen, die Auflösung der Merkmal-Abbildung um zwei in jeder Raumdimension hochzutakten, wird die Kanalzahl jeder Faltungsschicht im Decoder aufgrund der Verwendung der Subpixelschicht auf 4 X C gesetzt. Um den Lernprozess zu erleichtern, werden Batch-Normalisierung und ReLU-Schichten verwendet.
7 veranschaulicht eine Beispiel-Binär-Rest-Autoencoder-Architektur 700 gemäß einer Ausführungsform. In einer Ausführungsform verarbeitet die Binär-Rest-Autoencoder-Architektur 700 das Video Einzelbild für Einzelbild. Die Autoencoder-Architektur 700 besteht aus einem Encoder 702, einem Binarisierer 704 und einem Decoder 706. Der Encoder 702 und der Decoder 706 haben jeweils L Faltungsschichten, und jede Schicht enthält C/4C Kanäle. Der Einfachheit halber sind Huffman-Codiermodule nicht dargestellt.
Wir codieren und decodieren das Rest-Signal R Einzelbild für Einzelbild. frig sei ein Satz von Rest-Einzelbildern, die durch Anwenden von H.264 mit einer Ziel-Bitrate berechnet werden. Wir trainieren unseren Autoencoder, indem wir das folgende Optimierungsproblem lösen: $min_{D, E} \sum_{i} {‖ r_{i} - D (B (E (r_{i}))) ‖}_{2}^{2}$
Wir interessieren uns für die zur Übertragung von binären Darstellungen benötigte Bandbreite, die durch zwei Faktoren bestimmt wird: 1) die Zahl der Schichten L im Encoder und 2) die Zahl der Kanäle C. W und H seien die Breite und Höhe des Eingabebildes, wobei die Größe der binären Abbildung durch $\frac{C \times W \times H}{2^{2 L}}$
gegeben ist. Eine große Zahl von L und eine kleinere Zahl von C würde zu einer kleineren Größe der Encoder-Ausgabe und damit zu einer kleineren binären Abbildung führen. Eine kleinere Encoder-Ausgabe erschwert jedoch das Training des Autoencoders.
Training des Binär-Rest-Autoencoders
Binarisierende Merkmal-Abbildungen in neuronalen Netzen können verwendet werden, um den Speicherbedarf in mobilen Geräten zu reduzieren. Sie werden auch für Bildkompression verwendet. Wir werden verschiedene Binarisierungsverfahren erörtern.
Formulierung
Die Ausgabe-Merkmal-Abbildung von $E sei e_{i} = E (r_{i}) .$
Unser Binarisierer $B$
zielt darauf ab, die binäre Ausgabe {-1; 1}^-1 zu erzeugen. Um solche binären Ausgaben zu erzeugen, besteht der Prozess $B$
aus zwei Teilen: 1) Bilde jedes Element der Encoder-Ausgabe $e_{i}$
auf das Intervall [-1, 1] ab, und 2) Diskretisiere es auf {-1, 1}, gegeben durch: $B (e_{i}) = b (σ (e_{i}))$
worin σ und b die Aktivierungs- bzw. Diskretisierungsfunktionen sind. Im Folgenden erörtern wir verschiedene Funktionen für Aktivierung (z. B. Tanh, HardTanh, Sigmoid) und verschiedene Methodiken für Binarisierung (z. B. stochastische Regularisierung, Gumbel-Rauschen, usw.).
Tanh/HardTanh Aktivierung
Tanh ist eine gebräuchliche Aktivierung, um Merkmal-Abbildungen auf das Intervall [-1, 1] zu projizieren, ebenso wie die Approximierungsversion HardTanh-Funktion. Hier definieren wir die binarisierte Ausgabe als: $b (z) = {\begin{matrix} 1, & falls z \geq 0 \\ - 1, & falls z < 0, \end{matrix}$
$z = σ (e_{i})$
die Funktion Tanh oder HardTanh sein kann. Da Binarisierung jedoch keine differenzierbare Funktion ist, können wir den vorgeschlagenen Autoencoder nicht unter Verwendung von Rückwärtspropagierung trainieren. Um das Problem zu vermeiden, verwenden wir eine stückweise Funktion b_bp während Rückwärtspropagierung: $b_{b p} (z) = {\begin{array}{l} 1, & falls z > 1 \\ z, & falls - 1 \leq z \leq 1 \\ - 1, & falls z < - 1. \end{array}$
Unter Verwendung des Straight-Through-Schätzers können wir den Gradienten von $b_{b p} (z)$
berechnen und Gradienten durch b unverändert weitergeben als: $b_{b p}^{'} (z) = {\begin{array}{l} 1, & falls - 1 \leq z \leq 1 \\ 0, & sonst . \end{array}$
Sigmoid-Aktivierung
Die Sigmoid-Funktion gibt einen Wert im Intervall [0, 1] aus. Wir wandeln die Ausgabe durch Anwenden von $z = 2 (σ (e_{i}) - 0.5)$
auf das Intervall von [-1, 1] um. Wir können dann die im vorherigen Absatz beschriebene Methode für Binarisierung und Training verwenden.
Stochastische Regularisierung
In einer Ausführungsform integrieren wir einen stochastischen Prozess in (3) unter Verwendung der Tanh-Aktivierung: $b (z) = z + ε,$
worin ∈ ein randomisiertes Quantisierungsrauschen ist, resultierend in: $b (z) = {\begin{matrix} 1, & mit Wahrscheinlichkeit \frac{1 + z}{2} \\ - 1, & mit Wahrscheinlichkeit \frac{1 - z}{2} \end{matrix}$
Für Rückwärtspropagierung können wir ebenso unveränderte Gradienten durch b weitergeben.
Gumbel-Rauschen
Gumbel-Softmax-Verteilungen hat man verwendet, um kategorische/diskrete Ausgaben zu lernen. Einen ähnlichen Ansatz verfolgen wir durch Hinzufügen von Gumbel-Rauschen in der Sigmoid-Funktion, was wir als Gumbel-Sigmoid bezeichnen. Da Sigmoid als ein spezieller Zwei-Klassen-Fall (e_i und 0 in unserem Fall) von softmax angesehen werden kann, gewinnen wir das Gumbel-Sigmoid als: $σ (e_{i}) = \frac{exp ((e_{i} + g_{k}) / τ)}{exp ((e_{i} + g_{k}) / τ) + exp (g_{l} / τ)}$
worin g der Abtastwert aus dem Gumbel-Rauschen ist und τ die Temperatur ist, die steuert, wie genau die Gumbel-Sigmoid-Verteilung der binären Verteilung nahekommt. Aus (7) können wir das weiter vereinfachen als: $\begin{matrix} σ (e_{i}) = \frac{1}{1 + exp (- (e_{i} + g_{k} - g_{l}) / τ)} \\ = s i g m ((e_{i} + g_{k} - g_{l}) / τ), \end{matrix}$
worin sigm die Sigmoid-Funktion ist. Da σ(e_i) noch im Bereich von [0, 1] ist, verwenden wir denselben Ansatz wie zuvor eingeführt, um den Wert via $z = 2 (σ (e_{i}) - 0.5)$
zu verschieben. Wir beginnen mit einer hohen Temperatur und kühlen sie allmählich auf eine kleine Temperatur, die aber nicht Null ist.
Verlustfreie Komprimierung
Sobald wir die binäre Merkmal-Abbildung erzeugt haben, verwenden wir weiterhin Huffman-Codierung, um die Größe der binären Darstellung zu reduzieren. Diese Codierungsschemata sind asymptotisch optimal, was bedeutet, dass das Kompressionsverhältnis um so besser ist, je mehr Bits wir als ein Symbol zusammenfassen. Wir weisen darauf hin, dass auch andere Quellcodierungsverfahren wie z. B. arithmetische Codierung verwendet werden können.
Obwohl verschiedene Ausführungsformen oben beschrieben worden sind, versteht es sich, dass sie nur als Beispiel und nicht als Einschränkung präsentiert worden sind. Daher sind die Breite und der Schutzumfang einer bevorzugten Ausführungsform nicht durch irgendwelche der oben beschriebenen Ausführungsbeispiele einzuschränken, sondern nur in Übereinstimmung mit den folgenden Ansprüchen und ihren Äquivalenten zu definieren.

Claims

Verfahren, umfassend: Identifizieren von Rest-Videodaten, die aus einer Kompression von Original-Videodaten resultieren; Codieren der Rest-Videodaten, um codierte Rest-Videodaten zu erzeugen; Binarisieren der codierten Rest-Videodaten, um binarisierte Rest-Videodaten zu erzeugen; Komprimieren der binarisierten Rest-Videodaten, um komprimierte Rest-Videodaten zu erzeugen; und Übertragen der komprimierten Rest-Videodaten.
Verfahren nach Anspruch 1, wobei die Rest-Videodaten durch Berechnen einer Differenz zwischen dekomprimierten Original-Videodaten und den Original-Videodaten ermittelt werden.
Verfahren nach Anspruch 1 oder 2, wobei das Codieren der Rest-Videodaten umfasst, die Rest-Videodaten zu komprimieren.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die Rest-Videodaten unter Verwendung eines Binär-Rest-Autoencoders codiert werden.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die codierten Rest-Videodaten unter Verwendung eines Binär-Rest-Autoencoders binarisiert werden.
Verfahren nach Anspruch 5, wobei der Binär-Rest-Autoencoder einen Binarisierer enthält, der Einzelbilddaten der codierten Rest-Videodaten in einen komprimierbaren binären Bitstrom umwandelt.
Verfahren nach Anspruch 6, wobei der Binarisierer unter Verwendung einer Tanh-Aktivierung trainiert und implementiert wird.
Verfahren nach Anspruch 6 oder 7, wobei der Binarisierer unter Verwendung einer HardTanh-Aktivierung trainiert und implementiert wird.
Verfahren nach einem der Ansprüche 6 bis 8, wobei die binarisierten Rest-Videodaten unter Verwendung eines Binär-Rest-Autoencoders komprimiert werden.
Verfahren nach Anspruch 9, wobei der Binär-Rest-Autoencoder einen Huffman-Encoder enthält, der einen von dem Binarisierer erzeugten binären Bitstrom komprimiert, um eine zu übertragende Datenmenge zu reduzieren.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das Codieren, Binarisieren und Komprimieren gebietsspezifisch sind, so dass: ein Binär-Rest-Autoencoder das Codieren, Binarisieren und Komprimieren der Rest-Videodaten durchführt; der Binär-Rest-Autoencoder auf eine gebietsspezifische Weise trainiert wird; und während eines Trainings des Binär-Rest-Autoencoders eine begrenzte Menge von möglichen Ergebnissen verwendet wird.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die komprimierten Rest-Videodaten mit den Original-Videodaten, die komprimiert worden sind, übertragen werden.
Verfahren nach einem der vorhergehenden Ansprüche, das weiterhin umfasst: Dekomprimieren der Original-Videodaten, die in einem Client-Gerät komprimiert worden sind, um dekomprimierte Original-Videodaten zu erzeugen; Rekonstruieren der komprimierten Rest-Videodaten in dem Client-Gerät, um rekonstruierte Rest-Videodaten zu erzeugen; und Wiederhinzufügen der rekonstruierten Rest-Videodaten zu den dekomprimierten Original-Videodaten, um Ausgabe-Videodaten zu erzeugen.
Ein System, umfassend einen Prozessor, der konfiguriert ist, um ein Verfahren gemäß einem der Ansprüche 1 bis 13 durchzuführen.
Computerlesbares Speichermedium, das Anweisungen speichert, die bei Ausführung durch einen Prozessor bewirken, dass der Prozessor Schritte eines Verfahrens gemäß einem der Ansprüche 1 bis 13 durchführt.