DE102018124211A1

DE102018124211A1 - Lernbasierte Kameraposenschätzung von Bildern einer Umgebung

Info

Publication number: DE102018124211A1
Application number: DE102018124211.5A
Authority: DE
Inventors: Jinwei Gu; Samarth Manoj Brahmbhatt; Kihwan Kim; Jan Kautz
Original assignee: Nvidia Corp
Current assignee: Nvidia Corp
Priority date: 2017-10-06
Filing date: 2018-10-01
Publication date: 2019-04-11

Abstract

Ein tiefes neuronales Netzwerk (DNN) System lernt eine Kartendarstellung zum Schätzen einer Kameraposition und Orientierung (Pose). Das DNN wird trainiert, um eine der Umgebung entsprechende Kartendarstellung zu lernen, die Positionen und Attribute von Strukturen, Bäumen, Wänden, Fahrzeugen, Wänden, usw. definiert. Das DNN-System lernt eine Kartendarstellung, die vielseitig ist und für viele unterschiedliche Umgebungen (Innenraum, Außenraum, natürlich, synthetisch usw.) gut funktioniert. Das DNN-System empfängt Bilder einer Umgebung, die von einer Kamera (Beobachtungen) erfasst werden, und gibt eine geschätzte Kamerapose innerhalb der Umgebung aus. Die geschätzte Kamerapose wird verwendet, um eine Kameralokalisierung durchzuführen, d.h. die dreidimensionale (3D) Position und Orientierung einer sich bewegenden Kamera wiederzugewinnen, was eine fundamentale Aufgabe in Computer-Vision mit einer breiten Vielfalt von Anwendungen in Roboternavigation, Autolokalisierung für autonomes Fahren, Vorrichtungslokalisierung für mobile Navigation und augmentierter/virtueller Realität ist.

Description

GEBIET DER ERFINDUNG
Die vorliegende Erfindung betrifft das Bestimmen einer Kamerapose und insbesondere das Bestimmen der Kamerapose unter Verwendung eines neuronalen Netzwerks.
HINTERGRUND
Kameralokalisierung, d.h. Rückgewinnung der dreidimensionalen (3D) Position und Orientierung einer sich bewegenden Kamera, ist eine der fundamentalen Aufgaben in Computer-Vision mit einer breiten Vielfalt von Anwendungen in Roboternavigation, Autolokalisierung für autonomes Fahren, Vorrichtungslokalisierung für mobile Navigation und augmentierte/virtuelle Realität. Eine Schlüsselkomponente in der Kameralokalisierung ist das Konzept einer Karte. Eine Karte ist eine abstrakte Zusammenfassung der Eingangsdaten, die geometrische Beschränkungen zwischen Beobachtungen aufbaut und verwendet werden kann, um Korrespondenzen zwischen aufeinanderfolgenden Einzelbildern aufzubauen. Eine Karte kann abgefragt werden, um die Kamerapose zum Korrigieren von Drift in relativer Posenschätzung zu erhalten und die Kamerapose neu zu initialisieren, wenn die Verfolgung verloren gegangen ist. Karten werden jedoch gewöhnlicherweise in einer anwendungsspezifischen Art und Weise mit handwerklich gestalteten Merkmalen definiert. Beispiele umfassen 3D-Landmarken, 3D-Punkte, Linien/Kanten-Strukturen für Innenraum/künstliche Szenen, Gruppen von Pixeln mit Tiefe oder auf Objektniveaukontext für semantische Techniken. Da sie anwendungsspezifisch sind, können die Kartendarstellungen nützliche (manchmal die einzig verfügbaren) Merkmale in Umgebungen ignorieren und können somit für allgemeine Szenarien nicht optimal oder robust sein. Es gibt einen Bedarf, sich diesen Angelegenheiten und/oder anderen Angelegenheiten zu widmen, die dem Stand der Technik zugeordnet sind.
ZUSAMMENFASSUNG
Ein System eines tiefen neuronalen Netzwerks (DNN) lernt eine Kartendarstellung zur Kameralokalisierung. Das DNN-System empfängt Bilder einer durch eine Kamera erfassten Umgebung (Beobachtungen) und gibt eine Kamerapose (Position und Orientierung) innerhalb der Umgebung aus. Das DNN ist trainiert, um eine Kartendarstellung zu bestimmen, die der Umgebung entspricht, die Positionen und Attribute von Strukturen, Bäumen, Wänden, Fahrzeugen, Wänden, usw. definiert. Beispiele von herkömmlichen Kartendarstellungstypen umfassen dreidimensionale (3D) Punkte, Linien/Kanten-Strukturen für Innenraum/künstliche Szenen und Gruppen von Pixeln mit Tiefe. Typischerweise wird ein Typ einer Kartendarstellung verwendet, der für die bestimmte Umgebung am besten geeignet ist. Im Gegensatz dazu lernt das DNN-System eine Kartendarstellung, die vielseitig ist und für viele unterschiedliche Umgebungen (Innenraum, Außenraum, natürlich, synthetisch usw.) gut funktioniert. Die Kartendarstellung kann durch das DNN gelernt und unter Verwendung von überwachtem Training und/oder selbstüberwachtem Training aktualisiert werden. Außerdem kann das DNN durch Verschmelzen von zusätzlichen multisensorischen Eingaben mit den durch das DNN geschätzten Kameraposen trainiert werden, um die Genauigkeit des DNN zu verbessern.
Ein Verfahren, ein computerlesbares Medium und ein System werden zum Schätzen einer Kamerapose offenbart. Gewichtungen eines DNN werden während eines Trainings unter Verwendung eines etikettierten Trainingsdatensatzes bestimmt, der Bilder und entsprechende absolute Kameraposen und relative Kameraposen umfasst, wobei die Gewichtungen eine Kartendarstellung einer Umgebung definieren. Ein Eingangsbild wird bei das DNN empfangen. Das DNN wendet die Gewichtungen auf das Eingangsbild an, um eine geschätzte Kamerapose zur Erfassung der Umgebung zu generieren, um das Eingangsbild zu erzeugen.
Figurenliste

1A veranschaulicht ein Blockdiagramm eines Kameraposenschätzsystems gemäß einer Ausführungsform.
1B veranschaulicht ein Konzeptdiagramm der Kameraposen und Eingaben in das Kameraposenschätzsystem gemäß einer Ausführungsform.
1C veranschaulicht ein Ablaufdiagramm eines Verfahrens zum Schätzen einer Kamerapose gemäß einer Ausführungsform.
1D veranschaulicht ein Blockdiagramm eines weiteren Kameraposenschätzsystems gemäß einer Ausführungsform.
1E veranschaulicht ein Ablaufdiagramm eines weiteren Verfahrens zum Schätzen einer Kamerapose gemäß einer Ausführungsform.
2A veranschaulicht ein Blockdiagramm eines weiteren Kameraposenschätzsystems gemäß einer Ausführungsform.
2B veranschaulicht ein Ablaufdiagramm eines Verfahrens zum Schätzen einer Kamerapose unter Verwendung des in 2A gezeigten Kameraposenschätzsystems gemäß einer Ausführungsform.
2C veranschaulicht Kameralokalisierungsergebnisse gemäß einer Ausführungsform.
3 veranschaulicht eine Parallelverarbeitungseinheit gemäß einer Ausführungsform.
4A veranschaulicht einen allgemeinen Verarbeitungscluster innerhalb der Parallelverarbeitungseinheit von 3 gemäß einer Ausführungsform.
4B veranschaulicht eine Speicher-Partitions-Einheit der Parallelverarbeitungseinheit von 3 gemäß einer Ausführungsform.
5A veranschaulicht den Streaming-Multiprozessor von 4A gemäß einer Ausführungsform.
5B ist ein Konzeptdiagramm eines Verarbeitungssystems, das unter Verwendung der PPU von 3 implementiert wird, gemäß einer Ausführungsform.
5C veranschaulicht ein beispielhaftes System, bei dem die verschiedene Architektur und/oder Funktionalität der verschiedene vorherigen Ausführungsformen implementiert werden kann.

AUSFÜHRLICHE BESCHREIBUNG
Während eines Inferenzierens empfängt ein DNN-System eine Sequenz von Bildern und erzeugt eine Sequenz von Kameraposen unter Verwendung von Gewichtungen. Das DNN-System lernt eine Kartendarstellung einer Umgebung zur Kameralokalisierung. Im Kontext der folgenden Beschreibung umfasst die Kameralokalisierung das Bestimmen einer Kamerapose, die eine Position und Orientierung umfasst. Die Kartendarstellung entspricht der Umgebung, die Positionen und Attribute von Strukturen, Bäumen, Wänden, Fahrzeugen, Wänden, usw. definiert. Beispiele einer herkömmlichen Kartendarstellung-Faltungs-Neuronal-Netzwerkschicht umfassen dreidimensionale (3D) Punkte, Linien/Kanten-Strukturen für Innenraum/künstliche Szenen und Gruppen von Pixeln mit Tiefe. Typischerweise wird ein Typ einer Kartendarstellung verwendet, die für die bestimmte Umgebung am besten geeignet ist. Im Gegensatz zu herkömmlichen Kameralokalisierungssystemen lernt das DNN-System eine Kartendarstellung, die vielseitig ist und für viele unterschiedliche Umgebungen (Innenraum, Außenraum, natürlich, synthetisch usw.) gut funktioniert. Das DNN-System empfängt Bilder einer durch eine Kamera erfassten Umgebung (Beobachtungen) und gibt eine Kamerapose innerhalb der Umgebung aus. Das DNN-System wird anfangs unter Verwendung von etikettierten Trainingsdaten trainiert.
1A veranschaulicht ein Blockdiagramm eines Kameraposenschätzsystems 100 gemäß einer Ausführungsform. Obwohl das Kameraposenschätzsystem 100 im Kontext eines DNN-Modells beschrieben wird, kann das Kameraposenschätzsystem 100 ebenfalls durch ein Programm, kundenspezifische Schaltungen oder durch eine Kombination von kundenspezifischen Schaltungen und einem Programm durchgeführt werden. Beispielsweise kann das Verfahren 150 durch eine GPU (Graphikverarbeitungseinheit), eine CPU (zentrale Verarbeitungseinheit) oder einen beliebigen Prozessor implementiert werden, der imstande ist, die hier beschriebenen Operationen zu implementieren. Des Weiteren werden Fachleute verstehen, dass jedes System, welches das Kameraposenschätzsystem 100 durchführt, innerhalb des Umfangs und Wesens von Ausführungsformen der vorliegenden Erfindung ist.
Wie in 1A gezeigt, umfasst das Kameraposenschätzsystem 100 ein Paar von DNNs 110, eine Trainingsverlusteinheit 105 und eine relative Posenberechnungseinheit 120. In einer Ausführungsform ist das DNN 110 ein tiefes Faltungs-Neuronal-Netzwerk (CNN). In einer Ausführungsform umfasst das DNN 110 mindestens eine Faltungs-Neuronal-Netzwerkschicht, gefolgt von einer globalen Durchschnitts-Pooling-Schicht, gefolgt von einer vollständig verbundenen Schicht, um die geschätzten Kamerapose auszugeben. Das Kameraposenschätzsystem 100 wird trainiert, um eine Kartendarstellung für eine bestimmte Umgebung zu lernen. Bedeutenderweise ist das Kameraposenschätzsystem 100 vielseitig und kann trainiert werden, um unterschiedliche Typen von Kartendarstellungen zu lernen. Während überwachtem und/oder selbstüberwachtem Training werden Parameter (Gewichtungen θ) der DNNs 110 aktualisiert.
Jedes DNN 110 empfängt ein Bild (z.B. Pixelwerte) und erzeugt eine geschätzte Kamerapose basierend auf den Gewichtungen. Die DNNs 110 werden trainiert, um die Kartendarstellung zu lernen, die durch die Gewichtungen definiert und von den DNNs 110 verwendet wird, um ein Eingangsbildpaar der Bilder I_i und I_j zu verarbeiten und entsprechende geschätzte Kameraposenpaare p_i und p_j zu erzeugen. Die Eingangsbilder können von zwei unterschiedlichen Posen in der Umgebung erfasst werden. Beispielsweise können die Eingangsbilder einem Pfad durch die Umgebung entsprechen und nacheinander in Reihe sein. Bei einem weiteren Beispiel können die Eingangsbilder von zwei unterschiedlichen Punkte entlang des Pfads sein, die durch einen Abstand getrennt sind. Mit anderen Worten können null, ein, zwei oder eine beliebige Anzahl von dazwischenliegenden Bildern zwischen den Eingangsbildern I_l und I_j entlang des Pfads durch die Umgebung auftreten.
Die relative Posenberechnungseinheit 120 berechnet eine relative geschätzte Kamerapose v_ij unter Verwendung des geschätzten Kameraposenpaars. Die Trainingsverlusteinheit 105 empfängt das geschätzte Posenpaar, die relative geschätzte Kamerapose, eine Ground-Truth-(absolute)Kamerapose p*, die einem der Eingangsbilder entspricht, und eine relative Ground-Truth-Pose v*, die den Eingangsbildern entspricht. In einer Ausführungsform wird die relative Ground-Truth-Pose v* von den Eingangsbilder berechnet, die in einem Trainingsdatensatz umfasst sind, der mindestens die Eingangsbilder umfasst, wobei jedes Eingangsbild mit einer Ground-Truth-Kamerapose gepaart wird. Die Trainingsverlusteinheit 105 berechnet eine Verlustfunktion und aktualisiert die von den DNNs 110 verwendeten Gewichtungen. In einer Ausführungsform werden die Gewichtungen modifiziert, um Unterschiede zwischen den relativen geschätzten Kameraposen und den relativen Ground-Truth-Kameraposen und Unterschiede zwischen den geschätzten Kameraposen, die durch das DNN 110 erzeugt wurden, und den Ground-Truth-Kameraposen gleichzeitig zu verringern.
Weitere veranschaulichende Information wird nun hinsichtlich verschiedener optionaler Architekturen und Merkmale dargelegt, mit denen das vorhergehende Rahmenwerk gemäß den Wünschen des Benutzers implementiert werden kann. Es sei nachdrücklich bemerkt, dass die folgende Information für veranschaulichende Zwecke dargelegt wird und nicht in irgendeiner Art und Weise als beschränkend ausgelegt werden sollte. Jedes der folgenden Merkmale kann optional mit oder ohne den Ausschluss von anderen beschriebenen Merkmalen aufgenommen werden.
1B veranschaulicht ein Konzeptdiagramm der Kameraposen und Eingaben in das Kameraposenschätzsystem gemäß einer Ausführungsform. Ground-Truth-Kameraposen p₁ , p₂ und p₃ sind jeweils einem Ground-Truth-Eingangsbild (I₁ I₂ und I₃ ) zugeordnet. Das Ground-Truth-Eingangsbild, das einer Ground-Truth-Kamerapose entspricht, ist das Bild der Umgebung, das von einer Kamera erfasst wird, die (in Position und Orientierung) innerhalb der Umgebung gemäß der Ground-Truth-Kamerapose konfiguriert ist. Die Ground-Truth-Kameraposen p₁ und p₂ sind jeweils einer relativen Ground-Truth-Kamerapose v₁₂ und v₂₃ zugeordnet.
Die Ground-Truth-Eingangsbilder werden in das Kameraposenschätzsystem 100 eingegebenen, um geschätzte Kameraposen und geschätzte relative Kameraposen zu generieren. Die Trainingsverlusteinheit 105 empfängt die geschätzten Kameraposen, die geschätzten relativen Kameraposen, die Ground-Truth-Kameraposen und die relativen Ground-Truth-Kameraposen und erzeugt aktualisierte Gewichtungen gemäß einer Verlustfunktion. Wenn ein gewünschtes Genauigkeitsniveau durch das Kameraposenschätzsystem 100 erreicht wird, ist das überwachte Training der Kameraposenschätzsystems 100 abgeschlossen und die Umgebungskarte wird durch die Gewichtungen definiert. Das Genauigkeitsniveau wird durch Unterschiede zwischen den geschätzten Kameraposen und den Ground-Truth-Kameraposen und Unterschiede zwischen den geschätzten relativen Kameraposen und den relativen Ground-Truth-Kameraposen angegeben.
Bedeutenderweise wird die Umgebungskarte in einer datengetriebenen Art und Weise gelernt. Daher kann eine Vielfalt von unterschiedlichen Umgebungen, die jeweils einen zugeordneten Trainingsdatensatz aufweisen, durch das Kameraposenschätzsystem 100 gelernt werden. Nach dem überüberwachten Training kann das Kameraposenschätzsystem 100 eingesetzt werden, um geschätzte Kameraposen basierend auf Eingangsbildern, die in Echtzeit von einer Kamera empfangen werden, oder Bilder einer weiteren Quelle zu generieren. In einer Ausführungsform sind, nachdem das überwachte Training abgeschlossen ist, sind die relative Posenberechnungseinheit 120 und die Trainingsverlusteinheit 105 inaktiv und können entfernt oder neu konfiguriert werden.
In einer Ausführungsform umfasst das Kameraposenschätzsystem 100 lediglich ein einziges DNN 110 und eine einzige geschätzten Kamerapose wird für jedes Eingangsbild generiert. In einer derartigen Ausführungsform wird die einzige geschätzten Kamerapose innerhalb des Kameraposenschätzsystems 100 gespeichert und von der relativen Posenberechnungseinheit 120 und der Trainingsverlusteinheit 105 verwendet, um die Gewichtungen zu aktualisieren.
1C veranschaulicht ein Ablaufdiagramm eines Verfahrens 130 zum Schätzen einer Kamerapose gemäß einer Ausführungsform. Obwohl das Verfahren 130 im Kontext des Kameraposenschätzsystems 100 beschrieben wird, kann das Verfahren 130 ebenfalls durch ein Programm, kundenspezifische Schaltungen oder durch eine Kombination von kundenspezifischen Schaltungen und einem Programm durchgeführt werden. Beispielsweise kann das Verfahren 130 durch eine GPU (Graphikverarbeitungseinheit), eine CPU (zentrale Verarbeitungseinheit) oder einen beliebigen Prozessor implementiert werden, der imstande ist, die hier beschriebenen Operationen zu implementieren. Des Weiteren werden Fachleute verstehen, dass jedes System, welches das Verfahren 130 durchführt, innerhalb des Umfangs und Wesens von Ausführungsformen der vorliegenden Erfindung ist.
Bei Schritt 135 wird das DNN 110 durch Bestimmen von Gewichtungen unter Verwendung eines etikettierten Trainingsdatensatzes trainiert, der Bilder und entsprechende absolute Kameraposen und relative Kameraposen umfasst, wobei Gewichtungen des DNN 110 eine Kartendarstellung einer Umgebung definieren. Bei Schritt 140 wird ein Eingangsbild bei dem DNN 110 empfangen. Bei Schritt 145 wendet das DNN 110 die Gewichtungen auf das Eingangsbild an, um eine geschätzte Kamerapose zur Erfassung der Umgebung zu generieren, um das Eingangsbild zu erzeugen.
Herkömmliche Kameralokalisierungssysteme trainieren ein neuronales Netzwerk unter Verwendung von einzelnen Bildern, die mit absoluten Kameraposen etikettiert sind. Im Gegensatz dazu wird das Kameraposenschätzsystem 100 unter Verwendung von geometrischen Beschränkungen zwischen Paaren von Beobachtungen trainiert, die als ein zusätzlicher Verlustterm enthalten sind, um die Gewichtungen zu aktualisieren. In einer Ausführungsform werden die geometrischen Beschränkungen durch die relative geschätzte Kamerapose v_ij bereitgestellt. Somit ist das Training eine Geometrie-bewusste Lerntechnik, welche die Kameralokalisierungsleistung bedeutend verbessern kann. Das DNN 110 wird trainiert, um eine Kamerapose von einem eingegebenen RGB-Bild I auf dem Trainingssatz D = {(I, p*)} über überwachtes Lernen, f (I, Θ) = p, zu schätzen, wobei die Kamerapose p = (t, w), t eine Position, z.B. (x,y,z)-Koordinaten, und w eine Orientierung (Richtung) ist. Der Hauptunterschied zwischen dem Training des DNN 110 zum Schätzen von Kameraposen und anderen Trainingstechniken ist, dass der Verlust der absoluten Pose pro Bild und der Verlust der relativen Pose zwischen Bildpaaren gleichzeitig minimiert werden. In einer Ausführungsform wird die folgende Verlustfunktion verwendet, um Unterschiede zwischen den relativen geschätzten Kameraposen und den relativen Ground-Truth-Kameraposen und Unterschiede zwischen den geschätzten Kameraposen, die durch das DNN 110 erzeugt wurden, und den Ground-Truth-Kameraposen gleichzeitig zu verringern. $L_{D} (Θ) = \sum_{i = 1}^{| D |} h (p_{i}, p_{i}^{*}) + α \sum_{i, j = 1, i \neq j}^{| D |} h (v_{i j}, v_{i j}^{*}),$
wobei v_ij = (t_i - t_j, w_i - w_j) die relative Kamerapose zwischen Posenvorhersagen p_i und p_j für Bilder I_l und I_j ist. h(·) ist eine Funktion, um den Abstand zwischen der vorhergesagten Kamerapose p und der Ground-Truth-Kamerapose p* zu messen, die definiert ist als: $h (p,p*) = {‖ t - t* ‖}_{1} e^{- β} + β + {‖ w - w* ‖}_{1} e^{- γ} + γ$
wobei β und γ Gewichtungen sind, die einen Translationsverlust und einen Rotationsverlust ausgleichen. β und γ werden als β₀ und γ₀ initialisiert und beide werden während des Trainings gelernt. (I_i , I_j ) sind Bildpaare innerhalb jedes Tupels von s Bildern, die mit einer Lücke von k Einzelbildern von D abgetastet werden. Intuitiv hilft der Verlustbeitrag der relativen Kameraposen zwischen Bildpaaren globale Konsistenz durchzusetzen, was die Leistung der Kameralokalisierung verbessert. In einer Ausführungsform ist der Gewichtungskoeffizient α = 1, β₀ = 0,0 und γ₀ = -3,0. In einer Ausführungsform werden die Bildpaare von Tupeln der Größe s=3 mit einer Beabstandung von k=10 Einzelbildern abgetastet.
In einer Ausführungsform wird die Kameraorientierung als der Logarithmus eines Einheitsquaternions parametrisiert, um Rotation darzustellen, und ist für die Regression eines DNN besser geeignet. Herkömmliche Techniken verwenden 4-d Einheitsquaternionen, um die Kameraorientierung mit einer Normverlustfunktion I₁ oder I₂ darzustellen und zurückzubilden. Probleme bei der Verwendung von 4-d Einheitsquaternionen sind (1), dass das Quadrupel eine Überparametrisierung des dritten Freiheitsgrades (DoF) der Rotation ist, und (2), dass eine Normierung des Ausgangsquadrupels erforderlich ist, was jedoch häufig zu schlechterer Leistung führt. Herkömmliche Techniken können ebenfalls Eulerwinkel verwenden, die nicht überparametrisiert sind. Eulerwinkel sind jedoch nicht für Regression geeignet, da sie sich um 2n wickeln.
Der Logarithmus eines Einheitsquaternions, log q, weist 3 Dimensionen auf und ist nicht überparametrisiert. Daher wird der Abstand I₁ oder I₂ direkt als die Verlustfunktion ohne Normierung verwendet. Der Logarithmus eines Einheitsquaternions q = (u, v), wobei u ein Skalar und v ein 3-d Vektor ist, wird definiert als: $log q = {\begin{array}{l} \frac{v}{‖ v ‖} {cos}^{- 1} u, & falls ‖ v ‖ \neq 0 \\ 0, & anderenfalls \end{array}$
Die logarithmische Form w = log q kann zurück in ein Einheitsquaternion durch die Formel exp $w = (cos ‖ w ‖, \frac{w}{‖ w ‖} sin ‖ w ‖)$
umgewandelt werden. Unter Verwendung der logarithmischen Rotation erreicht die Parametrisierung hinsichtlich geschätzter Kameraposengenauigkeit bessere Ergebnisse als herkömmliche Techniken.
Herkömmliche Kameralokalisierungsysteme sind offline Techniken, die überwachtes Training erfordern, wobei Werte von Parametern festgelegt werden, die von dem neuronalen Netzwerk verwendet werden, nachdem das Training abgeschlossen ist. Im Gegensatz dazu kann das Kameraposenschätzsystem 100 modifiziert werden, um geometrische Beschränkungen zwischen Paaren von Beobachtungen zu verwenden, die Gewichtungen (d.h. definiert Kartendarstellung) kontinuierlich zu aktualisieren, die von den DNNs 110 verwendet werden. Während das überwachte Training unter Verwendung eines etikettierten Trainingsdatensatzes durchgeführt werden kann, der Ground-Truth-Kameraposen und relative Ground-Truth-Kameraposen umfasst, kann das selbstüberwachte Training durchgeführt werden, ohne Ground-Truth-Daten zu erfordern, weil zusätzliche nicht etikettierten Bilder empfangen werden. Die nicht etikettierten Bilder können während des Inferenzierens empfangen werden, wenn das Kameraposenschätzsystem 100 eingesetzt wird. Beispielsweise können die nicht etikettierten Bilder Videos umfassen, die zu unterschiedlichen Zeiten oder Kamerabewegungen in der Umgebung erfasst werden.
1D veranschaulicht ein Blockdiagramm eines weiteren Kameraposenschätzsystems 125 gemäß einer Ausführungsform. Obwohl das Kameraposenschätzsystem 125 im Kontext eines DNN-Modells beschrieben wird, kann das Verfahren 130 ebenfalls durch ein Programm, kundenspezifische Schaltungen oder durch eine Kombination von kundenspezifischen Schaltungen und einem Programm durchgeführt werden. Beispielsweise kann das Verfahren 130 durch eine GPU (Graphikverarbeitungseinheit), eine CPU (zentrale Verarbeitungseinheit) oder einen beliebigen Prozessor implementiert werden, der imstande ist, die hier beschriebenen Operationen zu implementieren. Des Weiteren werden Fachleute verstehen, dass jedes System, welches das Kameraposenschätzsystem 125 durchführt, innerhalb des Umfangs und Wesens von Ausführungsformen der vorliegenden Erfindung ist.
Wie in 1D gezeigt, umfasst das Kameraposenschätzsystem 125 das Paar von DNNs 110, eine Trainingsverlusteinheit 115 und die relative Posenberechnungseinheit 120. Das Kameraposenschätzsystem 125 lernt eine Kartendarstellung für eine bestimmte Umgebung durch überwachtes und/oder selbstüberwachtes Training. Während überwachten und/oder selbstüberwachten Trainings werden Parameter (Gewichtungen θ) der DNNs 110 aktualisiert. In einer Ausführungsform kann die Trainingsverlusteinheit 115 konfiguriert sein, um die Operationen der Trainingsverlusteinheit 105 durchzuführen, was überwachtes Lernen und selbstüberwachtes Lernen ermöglicht. In einer anderen Ausführungsform ist die Trainingsverlusteinheit 105 ebenfalls innerhalb des Kameraposenschätzsystems 125 umfasst.
Im Gegensatz zu dem Kameraposenschätzsystem 100 empfängt die Trainingsverlusteinheit 115 geometrische Beschränkungen in der Form von Sensordaten. Die geometrischen Beschränkungen können von einer Vielfalt von Quellen kommen: Posenbeschränkung von visueller Odometrie (VO) zwischen Paaren von Bildern, Translationsbeschränkung von Ablesungen von zwei globalen Positionierungssensoren (GPS) (die relative 3D-Positionsmessungen bereitstellen), Rotationsbeschränkung von zwei Ablesungen von Trägheitsmesseinheiten (Trägheitsmesseinheiten; IMU) (die relative Rotationsmessungen bereitstellen) und dergleichen. Des Weiteren stellen IMU und GPS Messungen über Kameraposen bereit, die für herausfordernde Bedingungen (z.B. texturlos, schwaches Licht) besonders nützlich sind. Wie in 1D gezeigt, sind die Eingaben p̂_i und v̂_ij GPS bzw. visuelle Odometriemessungen. Im Kontext der folgenden Beschreibung sind die Daten, die während gleichzeitigen Inferenzierens und selbstüberwachten Trainings (zusätzlich zu den Eingangsbildern) empfangen werden, zusätzliche Daten T.
Die Trainingsverlusteinheit 115 empfängt das geschätzte Posenpaar, die relative geschätzte Kamerapose v_ij von der relativen Posenberechnungseinheit 120 und die zusätzlichen Daten T einschließlich p̂_i und v̂_ij . Die Trainingsverlusteinheit 115 berechnet eine Verlustfunktion und aktualisiert die von den DNNs 110 verwendeten Gewichtungen. In einer Ausführungsform werden die Gewichtungen modifiziert, um Unterschiede zwischen den relativen geschätzten Kameraposen und v̂_ij und Unterschiede zwischen den geschätzten Kameraposen, die von dem DNN 110 generiert werden, und p̂_i gleichzeitig zu verringern
Es sei angenommen, dass die zusätzlichen Daten einige Videos der gleichen Szene sind, $T = {I_{t}} .$
Zusätzliche relative Kameraposen v̂_jj können zwischen aufeinanderfolgenden Einzelbildern (I_t und I_t+1 ) in einem der Videos unter Verwendung von herkömmlichen visuellen Odometriealgorithmen berechnet werden. Um die definierte Kartendarstellung mit $T$
zu aktualisieren, werden Gewichtungen θ des Kameraposenschätzsystems 125 durch Minimieren einer Verlustfunktion fein abgestimmt, die aus dem ursprünglichen Verlust des etikettierten Datensatzes $D$
und dem Verlust der nicht etikettierten Daten $T$
besteht $L (Θ) = L_{D} (Θ) + L_{T} (Θ),$
wobei $L_{T} (Θ)$
der Abstand zwischen der relativen Kamerapose v_ij (von Vorhersagen p_i , p_j ) und den zusätzlichen Daten, relative Kameraposen v̂_ij ist, und
Da visuelle Odometriealgorithmen v̂_ij im Koordinatensystem der Kamera i berechnen, wird die relative geschätzte Kamerapose v_ij ebenfalls im Koordinatensystem der Kamera I berechnet: $\begin{matrix} v_{i j} = {(exp (w_{j}) (t_{i} - t_{j}) exp (w_{j})}^{- 1}, \\ log (exp {(w_{j})}^{- 1} exp (w_{i})) . \end{matrix}$
Bedeutenderweise ist der Überwachungsverlust $L_{D} (Θ)$
des etikettierten Datensatzes $D$
in der Verlustfunktion von Gleichung (4) enthalten, um triviale Lösungen zu vermeiden, die sich daraus ergeben, dass lediglich der selbstüberwachte Verlust $L_{T} (Θ)$
von $T$
optimiert wird. In einer Ausführungsform tasten für überwachtes und selbstüberwachtes Training Mini-Batches von Trainingsdaten einen Abschnitt der etikettierten Daten $D$
und den Rest der nicht etikettierten Daten T ab. Die Bildpaare (I₁ , I_j ) werden auf ähnliche Weise von Tupeln von s Bildern mit einer Lücke von k Einzelbildern von sowohl $D$
als auch $T$
abgetastet. Im Einzelnen sei angenommen, dass es N Bilder in einer Eingabesequenz, I₁ , ..., I_N , gibt. Innerhalb jedes Tupels von s Bildern werden jeweils zwei benachbarte Elemente ein Bildpaar zum Training bilden. Beispielsweise sind sowohl (I_i , I_1+k ) als auch (I_i+k _(s-2) , I_i+k _(s-1) ) gültige Bildpaare.
Das Kameraposenschätzsystem 125 nutzt die komplementären Charakteristiken visueller Odometrie und DNN-basierte Kameraposenvorhersage aus — die visuelle Odometrie ist lokal exakt, driftet jedoch häufig im Zeitverlauf, und DNN-basierte Kameraposenvorhersagen sind rauschbehaftet, jedoch driftfrei. Für andere Sensoren, wie beispielsweise IMU (die relative Rotation misst) und GPS (die 3D-Orte misst), können ähnliche Verlustterme $L_{T} (Θ)$
definiert und durch die Trainingsverlusteinheit 115 berechnet werden, um den Unterschied zwischen derartigen Messungen und den durch das DNN 110 generierten Schätzungen (Vorhersagen) zu minimieren.
1E veranschaulicht ein Ablaufdiagramm eines weiteren Verfahrens 150 zum Schätzen einer Kamerapose gemäß einer Ausführungsform. Obwohl das Verfahren 150 im Kontext des Kameraposenschätzsystems 125 beschrieben wird, kann das Verfahren 150 ebenfalls durch ein Programm, kundenspezifische Schaltungen oder durch eine Kombination von kundenspezifischen Schaltungen und einem Programm durchgeführt werden. Beispielsweise kann das Verfahren 150 durch eine GPU (Graphikverarbeitungseinheit), eine CPU (zentrale Verarbeitungseinheit) oder einen beliebigen Prozessor implementiert werden, der imstande ist, Kameraposenschätzoperationen zu implementieren. Des Weiteren werden Fachleute verstehen, dass jedes System, welches das Verfahren 150 durchführt, innerhalb des Umfangs und Wesens von Ausführungsformen der vorliegenden Erfindung ist.
Schritt 135 wird abgeschlossen, wie zuvor beschrieben, um das DNN 110 unter Verwendung eines etikettierten Trainingsdatensatzes zu trainieren, der Bilder und entsprechende absolute Kameraposen und relative Kameraposen umfasst. Bei Schritt 155 wird ein Eingangsbild bei dem DNN 110 empfangen. Im Gegensatz zu den während des überwachten Trainings empfangenen Eingangsbildern wird das bei dem DNN 110 empfangene Eingangsbild nicht etikettiert und ist daher einer absoluten Ground-Truth-Kamerapose und einer relativen Ground-Truth-Kamerapose zugordnet. Bei Schritt 160 wendet das DNN 110 die Gewichtungen auf das Eingangsbild an, um eine geschätzte Kamerapose zur Erfassung der Umgebung zu generieren, um das Eingangsbild zu erzeugen. In einer Ausführungsform wird ein Rotationsabschnitt der geschätzten Kamerapose als ein 3D-Logarithmus eines Einheitsquaternions parametrisiert.
Bei Schritt 165 wird eine relative geschätzte Kamerapose durch die relative Posenberechnungseinheit 120 berechnet. Bei Schritt 170 aktualisiert die Trainingsverlusteinheit 115 die Gewichtungen basierend auf einer Verlustfunktion, die unter Verwendung der relativen geschätzten Kamerapose und zusätzlichen Daten berechnet wird. In einer Ausführungsform umfassen die zusätzlichen Daten visuelle Odometriedaten, die dem Eingangsbild entsprechen, und die Gewichtungen des DNN 110 werden aktualisiert, um Unterschiede zwischen einer relativen Kamerapose, die unter Verwendung der visuellen Odometriedaten berechnet wird, und der relativen geschätzten Kamerapose zu minimieren. In einer Ausführungsform umfassen die zusätzlichen Daten GPS-Daten, die dem Eingangsbild entsprechen, und die Gewichtungen des DNN 110 werden aktualisiert, um Unterschiede zwischen den GPS-Daten und der geschätzten Kamerapose zu minimieren. In einer Ausführungsform umfassen die zusätzlichen Daten Trägheitsmessdaten entsprechenden to das Eingangsbild, und die Gewichtungen des DNN 110 werden aktualisiert, um Unterschiede zwischen den Trägheitsmessdaten und der geschätzten Kamerapose zu minimieren.
2A veranschaulicht ein Blockdiagramm eines weiteren Kameraposenschätzsystems 200 gemäß einer Ausführungsform gemäß einer Ausführungsform. Das Kameraposenschätzsystem 200 umfasst das Kameraposenschätzsystem 100 oder 125 oder eine Kombination der Kameraposenschätzsysteme 100 oder 125. Außerdem verfeinert eine Posengraphenoptimierungseinheit 215 die geschätzten Kameraposen.
Der Zweck der Posengraphenoptimierung (PGO) ist, die eingegeben Kameraposen zu verfeinern, so dass die verfeinerten Kameraposen nahe an den eingegebenen Kameraposen (des Kameraposenschätzsystem 100 oder 125) sind und die relativen Transformationen zwischen den verfeinerten Kameraposen mit den eingegeben relativen Kameraposen v̂_ij übereinstimmen. Die PGO ist ein iterativer Optimierungsprozess. Während des Inferenzierens verschmilzt die Posengraphenoptimierungseinheit 215 die geschätzten Kamerapose von dem Kameraposenschätzsystems 100 oder 125 und die relativen Kameraposen v̂_ij von der visuellen Odometrie, um glatte und global konsistente Kameraposenvorhersagen $p_{i}^{o} {und p}_{j}^{o}$
zu erzeugen. Außerdem werden zur Laufzeit (d.h. während des Inferenzierens) die komplementären Rauschcharakteristiken der geschätzten Kameraposen (lokal rauschbehaftet, jedoch driftfrei) und der visuellen Odometrie (lokal glatt, jedoch driftend) durch Verschmelzen unter Verwendung einer Bewegtfenstertechnik mit PGO ausgenutzt.
Ein Bewegtfenster von T Einzelbildern wird für die Anfangsposen ${p_{i}}_{i = 1}^{T}$
verwendet, die durch das Kameraposenschätzsystem 100 oder 125 vorhergesagt werden und die relativen Posen zwischen zwei Einzelbildern von visuellen Odometrie sind {v̂_jj}, wobei i,j ∈ [1,T], i ≠ j. Das Kombinieren des Kameraposenschätzsystems 100 oder 125 mit der Posengraphenoptimierungseinheit 215 wird nach den optimalen Kameraposen ${p_{i}^{o}}_{i = 1}^{T}$
durch Minimieren der folgenden Verlustfunktion (Kosten) gelöst:
wobei h(·) eine Posenabstandsfunktion ist, die nachstehend als Gleichung (10) gezeigt wird. PGO ist ein iterativer Algorithmus, wobei $v_{i j}^{o}$
intern von $p_{i}^{o} {und p}_{j}^{o}$
hergeleitet wird, wie in Gleichung (6). Man beachte, dass Gewichtungen Θ des DNN 110 festgelegt sind und lediglich ${p_{i}^{o}}_{i = 1}^{T}$
optimiert ist. Das Kombinieren des Kameraposenschätzsystems 100 oder 125 mit der Posengraphenoptimierungseinheit 215 verbessert ferner die Genauigkeit der geschätzten Kameraposen mit einem Minimum an zusätzlichen Rechenkosten beim Testen.
Die geschätzten Kameraposen ${p_{i}}_{i = 1}^{T}$
und die relativen Kameraposen der visuellen Odometrie {v̂_ij} sind 6-dimensional (3d Translation t + 3d Log Quaternion w). Für den Rest der PGO-Algorithmusbeschreibung werden die Log Quaternionen in Einheitsquaternion unter Verwendung der exponentiellen Karte umgewandelt: $q = (cos ‖ w ‖, \frac{w}{‖ w ‖} sin ‖ w ‖) .$
Ein Zustandsvektor z ist die Verkettung aller Kameraposenvektoren T. Die gesamte Zielfunktion ist die Summe der Kosten aller Beschränkungen. Die Beschränkungen können entweder für die absolute Pose oder für die relative Pose zwischen einem Paar von Posen sein. Für beide dieser Kategorien gibt es getrennte Beschränkungen für Translation und Rotation: $\begin{matrix} E (z) = \sum_{c} E_{c} (z) \\ = \sum_{c} \bar{h} (f_{c} (c), k_{c}), \end{matrix}$
wobei h die Posenabstandsfunktion von Gleichung (7) und f_c eine Funktion ist, die den Zustandsvektor in die Größe abbildet, die für die Beschränkung c relevant ist. Beispielsweise wird p₁ , der Zustandsvektor für eine Beschränkung auf die absolute Kamerapose, von f_c ausgewählt oder die visuelle Odometrie zwischen Kameraposen für p_i und p_j wird für eine Beschränkung auf die relative Kamerapose berechnet. k_c ist die Beobachtung für die Beschränkung auf die relative Kamerapose und bleibt während des gesamtem Optimierungsprozesses konstant. (1) Beispielsweise ist k_c für die absoluten Kameraposenbeschränkungen die geschätzte Kamerapose, die durch das Kameraposenschätzsystem 125 erzeugt wird, und (2) k_c ist für die relativen Kameraposenbeschränkungen die zusätzliche Dateneingabe v̂_ij . Die Posenabstandsfunktion h wird definiert als: $\bar{h} (f_{c} (c), k_{c}) = {(f_{c} (z) - k_{c})}^{T} S_{c} (f_{c} (z) - k_{c}),$
wobei S_c die Kovarianzmatrix für die Beschränkung ist. In einer Ausführungsform wird S_c auf Identity für alle Translationsbeschränkungen eingestellt und auf σI₃ (σ = 10 bis 35) für unterschiedliche Umgebungen abgestimmt.
2B veranschaulicht ein Ablaufdiagramm eines Verfahrens 220 zum Schätzen einer Kamerapose unter Verwendung des in 2A gezeigten Kameraposenschätzsystems gemäß einer Ausführungsform. Schritte 135, 155, 160, 165 und 170 werden, wie zuvor beschrieben, in Verbindung mit 1E abgeschlossen. Bei Schritt 225 wird die geschätzte Kamerapose, die durch das Kameraposenschätzsystem 100 oder 125 generiert wird, durch die Posengraphenoptimierungseinheit 215 unter Verwendung von PGO verarbeitet, um die verfeinerte Kamerapose zu erzeugen. In einer Ausführungsform verarbeitet die Posengraphenoptimierungseinheit 215 Paare von geschätzten Kameraposen, um Paare von verfeinerten Kameraposen zu erzeugen.
2C veranschaulicht Kameralokalisierungsergebnisse gemäß einer Ausführungsform. Ein Plot 240 umfasst eine Ground-Truth-Kameratrajektorie (Pfad) 242, die 1120 Meter lang für eine autonome Fahranwendung ist. Der Plot 240 umfasst ebenfalls eine Trajektorie von geschätzten Kameraposen 244, die bei einem ersten Einzelbild 241 beginnen. Die Trajektorie 244 wird durch ein dem Stand der Technik zugeordnetes Kameralokalisierungssystem unter Verwendung von visueller Stereoodometrie generiert und weist einen mittleren Translationsfehler von 40,20 und einen mittleren Rotationsfehler von 12,85 Grad auf. Die Trajektorie 244 driftet von der Ground-Truth-Kameratrajektorie 242 weg.
Ein Plot 245 umfasst die Trajektorie 242, die mit einer Trajektorie von geschätzten Kameraposen 246 beginnend bei dem ersten Einzelbild überlagert wird, wobei die Trajektorie 246 durch das Kameraposenschätzsystem 100 (trainiert unter Verwendung von Überwachung) generiert wird und einen mittleren Translationsfehler von 9,84 und einen mittleren Rotationsfehler von 3,96 Grad aufweist. Ein Plot 250 umfasst die Trajektorie 242, die mit einer Trajektorie von geschätzten Kameraposen 252 beginnend bei dem ersten Einzelbild überlagert wird, wobei die Trajektorie 252 durch das Kameraposenschätzsystem 125 (trainiert unter Verwendung von Überwachung und Selbstüberwachung) erzeugt wird und einen mittleren Translationsfehler von 8,17 und einen mittleren Rotationsfehler von 2,62 Grad aufweist. Wie durch einen Plot 255 gezeigt, kann der mittlere Translationsfehler und ein mittlerer Rotationsfehler für das Kameraposenschätzsystem 125 verringert werden, in dem die Anzahl von Eingangsbildsequenzen für selbstüberwachtes Training auf 6,95 bzw. 2,38 Grad verdoppelt wird. Ein Plot 260 umfasst die Trajektorie 242, die mit einer Trajektorie von geschätzten Kameraposen 262 beginnend bei dem ersten Einzelbild überlagert wird, wobei die Trajektorie 262 durch das Kameraposenschätzsystem 125 (trainiert unter Verwendung von Überwachung und Selbstüberwachung) unter Verwendung von GPS-Daten und den in die Trainingsverlusteinheit 115 eingegeben zusätzlichen Daten erzeugt wird und einen mittleren Translationsfehler von 6,78 und einen mittleren Rotationsfehler von 2,72 Grad aufweist. Ein Plot 265 umfasst die Trajektorie 242, die mit einer Trajektorie von geschätzten Kameraposen 266 beginnend bei dem ersten Einzelbild überlagert wird, wobei die Trajektorie 266 durch das Kameraposenschätzsystem 200 (trainiert unter Verwendung von Überwachung und Selbstüberwachung) generiert wird und einen mittleren Translationsfehler von 6,73 und einen mittleren Rotationsfehler von 2,23 Grad aufweist.
Während das Kameraposenschätzsystem 100 eine genauere Trajektorie 246 im Vergleich mit der Trajektorie 244 erzeugt, verbessert der Gebrauch von Selbstüberwachung für das Kameraposenschätzsystem 125 weiter die Genauigkeit. Schließlich erzeugt der Gebrauch von PGO in dem Kameraposenschätzsystem 200 die genaueste Trajektorie 266. Geschätzte Ausreißerkameraposenpositionen in den in 2C gezeigten Plots entsprechen häufig Bildern mit großen überbelichteten Regionen und können mit einfacher Nachbearbeitung (e.g. Medianmittelwertfilterung) ausgefiltert werden.
Zusammenfassend lernen Kameraposenschätzsysteme 100, 125 und 200 eine allgemeine datengetriebene Kartendarstellung zur Kameralokalisierung. Die Gewichtungen des DNN 110 werden gelernt, um die Kartendarstellung einer Umgebung zu definieren, die von einer Kamera erfasst wird. Die Gewichtungen können während des Inferenzierens mit Selbstüberwachung unter Verwendung von nicht etikettierten Daten (Eingangsbildern, Translationsbeschränkungen von zwei GPS-Ablesungen, Posenbeschränkungen von visueller Odometrie zwischen Paaren von Bildern, Rotationsbeschränkungen von zwei IMU-Ablesungen usw.) kontinuierlich aktualisiert werden. Das DNN 110 wird (überwacht und selbstüberwacht) unter Verwendung von Paaren von Eingangsbildern trainiert und die Eingangsbilder in jedem Paar sind nicht notwendigerweise in einer Sequenz benachbart. Schließlich kann eine Bewegtfenster-PGO während des Inferenzierens benutzt werden, um eine glatte und driftfreie Kameratrajektorie durch Verschmelzen der geschätzten Kameraposenvorhersagen und visueller Odometriedaten zu erhalten.
Parallelverarbeitungsarchitektur
3 veranschaulicht eine Parallelverarbeitungseinheit (PPU) 300 gemäß einer Ausführungsform. In einer Ausführungsform ist die PPU 300 ein Multi-Threaded-Prozessor bzw. mehrsträngiger Prozessor, der auf einer oder mehreren integrierten Schaltungsvorrichtungen implementiert ist. Die PPU 300 ist eine Latenz-verbergende Architektur, die ausgestaltet ist, um eine große Anzahl von Threads bzw. Strängen parallel zu verarbeiten. Ein Thread bzw. Strang (d.h. ein Ausführungsthread) ist eine Instanziierung eines Satzes von Anweisungen, die konfiguriert sind, um von der PPU 300 ausgeführt zu werden. In einer Ausführungsform ist die PPU 300 eine Graphikverarbeitungseinheit (GPU), die konfiguriert ist, um eine Graphik-Rendering-Pipeline zur Verarbeitung von dreidimensionalen (3D) Graphikdaten zu implementieren, um zweidimensionale (2D) Bilddaten zur Anzeige auf einer Anzeigevorrichtung, wie beispielsweise einer Flüssigkristallanzeige(LCD)-Vorrichtung, zu erzeugen. In anderen Ausführungsformen kann die PPU 300 zum Durchführen von Allzweckberechnungen benutzt werden. Während ein beispielhafter paralleler Prozessor hier für veranschaulichende Zwecke bereitgestellt wird, sei nachdrücklich bemerkt, dass ein derartiger Prozessor lediglich für veranschaulichende Zwecke dargelegt wird und dass ein beliebiger Prozessor benutzt werden kann, um dasselbe zu ergänzen und/oder zu ersetzen.
Eine oder mehrere PPUs 300 können konfiguriert sein, um Tausende von HPC(High Performing Computing)-, Datenzentrum- und Maschinenlern-Anwendungen zu beschleunigen. Die PPU 300 kann konfiguriert sein, um zahlreiche Deep-Learning-Systeme und Anwendungen zu beschleunigen, die autonome Fahrzeugplattformen, Deep-Learning, hochgenaue Sprache, Bild- und Texterkennungssysteme, intelligente Videoanalyse, molekulare Simulationen, Wirkstoffentdeckung, Krankheitsdiagnose, Wettervorhersage, Analyse großer Datenmengen, Astronomie, Molekulardynamiksimulation, Finanzmodellierung, Robotertechnik, Fabrikautomation, Sprachübersetzung in Echtzeit, Online-Suchoptimierungen und personalisierte Benutzerempfehlungen und dergleichen umfassen.
Wie in 3 gezeigt, umfasst die PPU 300 eine Eingabe/Ausgabe(E/A)-Einheit 305, eine Frontend-Einheit 315, eine Planereinheit 320, eine Arbeitsverteilungs-Einheit 325, einen Hub 330, eine Kreuzschiene (Xbar) 370, einen oder mehrere allgemeine Verarbeitungsclusters (GPCs) 350 und eine oder mehrere Partitions-Einheiten 380. Die PPU 300 kann mit einem Host-Prozessor oder anderen PPUs über einen Interconnect des Hochgeschwindigkeits-NVLink 310 verbunden sein. Die PPU 300 kann ebenfalls mit einem Host-Prozessor oder anderen peripheren Vorrichtungen über einen Interconnect 302 verbunden sein. In einer Ausführungsform kann der lokale Speicher eine Anzahl von Direktzugriffsspeicher(DRAM)-Vorrichtungen umfassen. Die DRAM-Vorrichtungen können als ein HBM(Speicher mit hoher Bandbreite)-Subsystem konfiguriert sein, wobei mehrere DRAM-Dies innerhalb jeder Vorrichtung gestapelt sind.
Der Interconnect des NVLink 310 ermöglicht Systemen, eine oder mehrere PPUs 300 zu skalieren und zu umfassen, die mit einer oder mehreren CPUs kombiniert sind, unterstützt Cache-Kohärenz zwischen den PPUs 300 und CPUs sowie CPU-Mastering. Daten und/oder Befehle können mittels des NVLink 310 durch den Hub 330 an/von anderen Einheiten der PPU 300, wie beispielsweise eine oder mehrere Kopiermaschinen, einen Videocodierer, einen Videodecodierer, eine Leistungsverwaltungseinheit usw. (nicht explizit gezeigt) übertragen werden. Das NVLink 310 wird ausführlicher in Verbindung mit 5B beschrieben.
Die E/A-Einheit 305 ist konfiguriert, um Kommunikationen (d.h. Befehle, Daten usw.) von einem Host-Prozessor (nicht gezeigt) über den Interconnect 302 zu übertragen und zu empfangen. Die E/A-Einheit 305 kann mit dem Host-Prozessor direkt über den Interconnect 302 oder durch eine oder mehrere Zwischenvorrichtungen, wie beispielsweise eine Speicherbrücke, kommunizieren. In einer Ausführungsform kann die E/A-Einheit 305 mit einem oder mehreren anderen Prozessoren, wie beispielsweise eine oder mehrere der PPUs 300, über den Interconnect 302 kommunizieren. In einer Ausführungsformen implementiert die E/A-Einheit 305 eine PCIe(Peripheral Component Interconnect Express)-Schnittstelle für Kommunikationen über einen PCIe-Bus und der Interconnect 302 ist ein PCIe-Bus. In alternativen Ausführungsformen kann die E/A-Einheit 305 andere Typen von wohlbekannten Schnittstellen zum Kommunizieren mit externen Vorrichtungen umfassen.
Die E/A-Einheit 305 decodiert Pakete, die über den Interconnect 302 empfangen wurden. In einer Ausführungsform stellen die Pakete Befehle dar, die konfiguriert sind, um die PPU 300 zu veranlassen, verschiedene Operationen durchzuführen. Die E/A-Einheit 305 überträgt die decodierten Befehle an verschiedene andere Einheiten der PPU 300, wie es die Befehle spezifizieren können. Beispielsweise können einige Befehle an die Frontend-Einheit 315 übertragen werden. Andere Befehle können an den Hub 330 oder andere Einheiten der PPU 300, wie beispielsweise eine oder mehrere Kopiermaschinen, einen VideoCodierer, einen Video-Decodierer, eine Leistungsverwaltungseinheit usw. (nicht explizit gezeigt) übertragen werden. Mit anderen Worten ist die E/A-Einheit 305 konfiguriert, um Kommunikationen zwischen und unter den verschiedenen logischen Einheiten der PPU 300 weiterzuleiten.
In einer Ausführungsform codiert ein Programm, das von dem Host-Prozessor ausgeführt wird, einen Befehlsstrom in einem Puffer, welcher der PPU 300 Arbeitslasten zur Verarbeitung bereitstellt. Eine Arbeitslast kann mehrere Anweisungen und Daten umfassen, die von diesen Anweisungen zu verarbeiten sind. Der Puffer ist ein Bereich in einem Speicher, der von sowohl dem Host-Prozessor als auch der PPU 300 zugänglich ist (d.h. Lesen/Schreiben). Beispielsweise kann die E/A-Einheit 305 konfiguriert sein, um auf den Puffer in einem Systemspeicher, der mit dem Interconnect 302 verbunden ist, über Speicheranfragen, die über den Interconnect 302 übertragen werden, zuzugreifen. In einer Ausführungsform schreibt der Host-Prozessor den Befehlsstrom in den Puffer und überträgt dann einen Zeiger zu dem Start des Befehlsstroms an die PPU 300. Die Frontend-Einheit 315 empfängt Zeiger auf einen oder mehrere Befehlsströme. Die Frontend-Einheit 315 verwaltet den einen oder mehrere Ströme, liest Befehle von den Strömen und leitet Befehle an die verschiedenen Einheiten der PPU 300 weiter.
Die Frontend-Einheit 315 ist mit einer Planereinheit 320 gekoppelt, welche die verschiedenen GPCs 350 konfiguriert, um Aufgaben zu verarbeiten, die durch den einen oder mehrere Ströme definiert sind. Die Planereinheit 320 ist konfiguriert, um Zustandsinformation zu verfolgen, die verschiedene Aufgaben betrifft, die von der Planereinheit 320 verwaltet werden. Der Zustand kann angeben, welchem GPC 350 eine Aufgabe zugewiesen ist, ob die Aufgabe aktiv oder inaktiv ist, ob ein Prioritätsniveau der Aufgabe zugeordnet ist und so weiter. Die Planereinheit 320 verwaltet die Ausführung einer Mehrzahl von Aufgaben auf dem einen oder mehreren GPCs 350.
Die Planereinheit 320 ist mit einer Arbeitsverteilungs-Einheit 325 gekoppelt, die konfiguriert ist, um Aufgaben zur Ausführung auf den GPCs 350 zu versenden. Die Arbeitsverteilungs-Einheit 325 kann eine Anzahl von eingeplanten Aufgaben verfolgen, die von der Planereinheit 320 empfangen werden. In einer Ausführungsform verwaltet die Arbeitsverteilungs-Einheit 325 einen Pool für anhängige Aufgaben und einen Pool für aktive Aufgaben für jeden der GPCs 350. Der Pool für anhängige Aufgaben kann eine Anzahl von Schlitzen (z.B. 32 Schlitze) umfassen, die Aufgaben enthalten, die zugewiesen sind, um von einem bestimmten GPC 350 verarbeitet zu werden. Der Pool für aktive Aufgaben kann eine Anzahl von Schlitzen (z.B. 4 Schlitze) für Aufgaben umfassen, die von den GPCs 350 aktiv verarbeitet werden. Wenn ein GPC 350 die Ausführung einer Aufgabe abschließt, wird diese Aufgabe aus dem Pool für aktive Aufgaben für den GPC 350 geräumt und eine der anderen Aufgaben wird aus dem Pool für anhängige Aufgaben ausgewählt und zur Ausführung auf dem GPC 350 eingeplant. Wenn eine aktive Aufgabe auf dem GPC 350 inaktiv war, wie beispielsweise während darauf gewartet wird, dass eine Datenabhängigkeit behoben wird, dann kann die aktive Aufgabe aus dem GPC 350 geräumt und zu dem Pool für anhängige Aufgaben zurückgeführt werden, während eine weitere Aufgabe in dem Pool für anhängige Aufgaben ausgewählt und zur Ausführung auf dem GPC 350 eingeplant wird.
Die Arbeitsverteilungs-Einheit 325 kommuniziert mit dem einen oder mehreren GPCs 350 über eine Kreuzschiene bzw. XBar 370. Die XBar 370 ist ein Interconnect-Netzwerk, das viele der Einheiten der PPU 300 mit anderen Einheiten der PPU 300 koppelt. Beispielsweise kann die XBar 370 konfiguriert sein, um die Arbeitsverteilungs-Einheit 325 mit einem bestimmten GPC 350 zu koppeln. Obwohl nicht explizit gezeigt, kann eine oder mehrere andere Einheiten der PPU 300 ebenfalls mit der XBar 370 über den Hub 330 verbunden sein.
Die Aufgaben werden von der Planereinheit 320 verwaltet und an einen GPC 350 von der Arbeitsverteilungs-Einheit 325 versandt. Der GPC 350 ist konfiguriert, um die Aufgabe zu verarbeiten und Ergebnisse zu erzeugen. Die Ergebnisse können von anderen Aufgaben innerhalb des GPC 350 verbraucht werden, an einen unterschiedlichen GPC 350 über die XBar 370 weitergeleitet oder im Speicher 304 gespeichert werden. Die Ergebnisse können in den Speicher 304 über die Partitions-Einheiten 380 geschrieben werden, die eine Speicherschnittstelle zum Lesen und Schreiben von Daten in/von dem Speicher 304 implementieren. Die Ergebnisse können an eine andere PPU 304 oder CPU über den NVLink 310 übertragen werden. In einer Ausführungsform umfasst die PPU 300 eine Anzahl U von Partitions-Einheiten 380, die gleich der Anzahl von getrennten und unterschiedlichen Speichervorrichtungen 304 ist, die mit der PPU 300 gekoppelt sind. Eine Partitions-Einheit 380 wird nachstehend ausführlicher in Verbindung mit 4B beschrieben.
In einer Ausführungsform führt ein Host-Prozessor einen Treiber-Kernel aus, der eine Anwendungsprogrammmier-Schnittstelle (API) implementiert, die einer oder mehreren Anwendungen ermöglicht, die auf dem Host-Prozessor ausgeführt werden, Operationen zur Ausführung auf der PPU 300 einzuplanen. In einer Ausführungsform werden mehrere Rechenanwendungen gleichzeitig von der PPU 300 ausgeführt und die PPU 300 stellt Isolierung, Dienstqualität (QoS) und unabhängige Adressräume für die mehreren Rechenanwendungen bereit. Eine Anwendung kann Anweisungen (d.h. API-Aufrufe) erzeugen, welche den Treiber-Kernel veranlassen, eine oder mehrere Aufgaben zur Ausführung durch die PPU 300 zu erzeugen. Der Treiberkernel gibt Aufgaben an einen oder mehrere Streams aus, die von der PPU 300 verarbeitet werden. Jede Aufgabe kann eine oder mehrere Gruppen von in Beziehung stehender Threads umfassen, die hier als ein Warp bezeichnet werden. In einer Ausführungsform umfasst ein Warp 32 in Beziehung stehende Threads, die parallel ausgeführt werden können. Kooperierende Threads können sich auf eine Mehrzahl von Threads beziehen, die Anweisungen umfassen, um die Aufgabe durchzuführen, und die Daten durch einen gemeinsam benutzten Speicher austauschen können. Threads und kooperierende Threads werden ausführlicher in Verbindung mit 5A beschrieben.
4A veranschaulicht einen GPC 350 der PPU 300 von 3 gemäß einer Ausführungsform. Wie in 4A gezeigt, umfasst jeder GPC 350 eine Anzahl von Hardwareeinheiten zur Verarbeitung von Aufgaben. In einer Ausführungsform umfasst jeder GPC 350 einen Pipeline-Manager 410, eine Vor-Raster-Operationen-Einheit (PROP) 415, eine Raster-Engine 425, eine Arbeitsverteilungs-Kreuzschiene (WDX) 480, eine Speicherverwaltungseinheit (MMU) 490 und einen oder mehrere Datenverarbeitungscluster (DPCs) 420. Es wird anerkannt, dass der GPC 350 von 4A andere Hardwareeinheiten anstelle von oder zusätzlich zu den in 4A gezeigten Einheiten umfassen kann.
In einer Ausführungsform wird der Betrieb des GPC 350 durch den Pipeline-Manager 410 gesteuert. Der Pipeline-Manager 410 verwaltet die Konfiguration des einen oder mehrerer DPCs 420 zur Verarbeitung von Aufgaben, die dem GPC 350 zugeteilt sind. In einer Ausführungsform kann der Pipeline-Manager 410 mindestens einen des einen oder mehrerer DPCs 420 konfigurieren, um mindestens einen Abschnitt einer Graphik-Rendering-Pipeline zu implementieren. Beispielsweise kann ein DPC 420 konfiguriert sein, um ein Vertex-Shader-Programm auf dem programmierbaren Streaming-Multiprozessor (SM) 440 auszuführen. Der Pipeline-Manager 410 kann ebenfalls konfiguriert sein, um Pakete, die von der Arbeitsverteilungs-Einheit 325 empfangen werden, an die geeigneten logischen Einheiten innerhalb des GPC 350 weiterzuleiten. Beispielsweise können einige Pakete an Festfunktions-Hardwareeinheiten in der PROP 415 und/oder der Raster-Engine 425 weitergeleitet werden, während andere Pakete an die DPCs 420 zur Verarbeitung durch die Primitiven-Engine 435 oder den SM 440 weitergeleitet werden können. In einer Ausführungsform kann der Pipeline-Manager 410 mindestens einen der einen oder mehreren DPCs 420 konfigurieren, um ein neuronales Netzwerkmodell und/oder eine Rechen-Pipeline zu implementieren.
Die PROP-Einheit 415 ist konfiguriert, um Daten, die von der Raster-Engine 425 und den DPCs 420 erzeugt werden, an eine Raster-Operationen-Einheit (ROP-Einheit) in der Partitions-Einheit 380 weiterzuleiten, die nachstehend ausführlicher in Verbindung mit 4B beschrieben wird. Die PROP-Einheit 415 kann ebenfalls konfiguriert sein, um Optimierungen zur Farbenmischung durchzuführen, Pixeldaten zu organisieren, Adressenübersetzungen und dergleichen durchzuführen.
Die Raster-Engine 425 umfasst eine Anzahl von Festfunktions-Hardwareeinheiten, die konfiguriert sind, um verschiedene Raster-Operationen durchzuführen. In einer Ausführungsform umfasst die Raster-Engine 425 eine Setup-Engine, eine Grobraster-Engine, eine Aussonderungs-Engine, eine Abschneide-Engine, eine Feinraster-Engine und eine Kachel-verschmelzende Engine. Die Setup-Engine empfängt transformierte Vertices und erzeugt Ebenengleichungen, die den geometrischen Primitiven zugeordnet sind, die durch die Vertices definiert werden. Die Ebenengleichungen werden an die Grobraster-Engine übertragen, um Abdeckungsinformation (z.B. eine (x,y)-Abdeckungsmaske für eine Kachel) für die Primitive zu erzeugen. Die Ausgabe der Grobraster-Engine wird an die Aussonderungs-Engine übertragen, wo Fragmente, die der Primitiven zugeordnet sind, die einen z-Test nicht bestehen, ausgesondert und an eine Abschneide-Engine übertragen werden, wo Fragmente, die außerhalb eines Betrachtungsstumpfes liegen, abgeschnitten werden. Diejenigen Fragmente, welche die Abschneidung und Aussonderung überleben, können an eine Feinraster-Engine weitergeben werden, um Attribute für die Pixelfragmente basierend auf den Ebenengleichungen zu erzeugen, die durch die Setup-Engine erzeugt werden. Die Ausgabe der Raster-Engine 425 umfasst Fragmente, die beispielsweise von einem Fragment-Shader zu verarbeiten sind, der innerhalb eines DPC 420 implementiert ist.
Jeder DPC 420, der in dem GPC 350 umfasst ist, umfasst einen M-Pipe-Controller (MPC) 430, eine Primitiven-Engine 435 und einen oder mehrere SMs 440. Der MPC 430 steuert den Betrieb des DPC 420, wobei von dem Pipeline-Manager 410 empfangene Pakete an die geeigneten Einheiten im DPC 420 weiterleitet werden. Beispielsweise können einem Vertex zugeordnete Pakete an die Primitiven-Engine 435 weitergeleitet werden, die konfiguriert ist, um der Vertex zugeordnete Vertexattribute von dem Speicher 304 zu holen. Im Gegensatz dazu können einem Shader-Programm zugeordnete Pakete an den SM 440 übertragen werden.
Der SM 440 umfasst einen programmierbaren Streaming-Prozessor, der konfiguriert ist, um Aufgaben zu verarbeiten, die durch eine Anzahl von Threads dargestellt werden. Jeder SM 440 umfasst mehrere Threads (ist multi-threaded) und ist konfiguriert, um eine Mehrzahl von Threads (z.B. 32 Threads) von einer bestimmten Gruppe von Threads nebenläufig auszuführen. In einer Ausführungsform implementiert der SM 440 eine SIMD(Einzelne-Anweisung, Mehrere-Daten)-Architektur, wobei jeder Thread in einer Gruppe von Threads (d.h. einem Warp) konfiguriert ist, um einen unterschiedlichen Satz von Daten basierend auf dem gleichen Satz von Anweisungen zu verarbeiten. Alle Threads in der Gruppe von Threads führen die gleichen Anweisungen aus. In einer anderen Ausführungsform implementiert der SM 440 eine SIMT(Einzelne Anweisung, Mehrere Threads)-Architektur, wobei jeder Thread in einer Gruppe von Threads konfiguriert ist, um einen unterschiedlichen Satz von Daten basierend auf dem gleichen Satz von Anweisungen zu verarbeiten, wobei jedoch einzelnen Threads in der Gruppe von Threads ermöglicht wird, während der Ausführung zu divergieren. In einer Ausführungsform wird ein Programmzähler, ein Aufrufstapel und ein Ausführungszustand für jeden Warp beibehalten, was eine Nebenläufigkeit zwischen Warps und eine serielle Ausführung innerhalb Warps ermöglicht, wenn Threads innerhalb des Warp divergieren. In einer weiteren Ausführungsform wird ein Programmzähler, ein Aufrufstapel und ein Ausführungszustand für jeden einzelnen Thread beibehalten, was eine Nebenläufigkeit zwischen allen Threads, innerhalb und zwischen Warps ermöglicht. Wenn der Ausführungszustand für jeden einzelnen Thread beibehalten wird, können Threads, welche die gleichen Anweisungen ausführen, konvergiert und für maximale Effizienz parallel ausgeführt werden. Der SM 440 wird ausführlicher nachstehend in Verbindung mit 5A beschrieben.
Die MMU 490 stellt eine Schnittstelle zwischen dem GPC 350 und der Partitions-Einheit 380 bereit. Die MMU 490 kann eine Übersetzung von virtuellen Adressen in physische Adressen, einen Speicherschutz und eine Arbitrierung von Speicheranfragen bereitstellen. In einer Ausführungsform stellt die MMU 490 einen oder mehrere Adressenübersetzungspuffer (TLBs = translation lookaside buffers) zum Durchführen der Übersetzung von virtuellen Adressen in physische Adressen in dem Speicher 304 bereit.
4B veranschaulicht eine Speicher-Partitions-Einheit 380 der PPU 300 von 3 gemäß einer Ausführungsform. Wie in 4B gezeigt, umfasst die Partitions-Einheit 380 eine Raster-Operationen(ROP)-Einheit 450, einen L2-Cache-Speicher 460 und eine Speicherschnittstelle 470. Die Speicherschnittstelle 470 ist mit dem Speicher 304 gekoppelt. Die Speicherschnittstelle 470 kann 32-, 64-, 128-, 1024-Bit-Datenbusse oder dergleichen für Hochgeschwindigkeits-Datentransfer implementieren. In einer Ausführungsform umfasst die PPU 300 U Speicherschnittstellen 470, eine Speicherschnittstelle 470 pro Paar von Partitions-Einheiten 380, wobei jedes Paar von Partitions-Einheiten 380 mit einer entsprechenden Speichervorrichtung 304 verbunden ist. Beispielsweise kann die PPU 300 mit bis zu Y Speichervorrichtungen 304, wie beispielsweise Speicherstapel mit hoher Bandbreite oder Graphikdoppeldatenraten, Version 5 SDRAM oder anderen Arten von persistem Speicher verbunden sein.
In einer Ausführungsform implementiert die Speicherschnittstelle 470 eine HBM2-Speicherschnittstelle und Y ist gleich einem halben U. In einer Ausführungsform sind die HBM2-Speicherstapel auf der gleichen physischen Packung wie die PPU 300 lokalisiert, die wesentliche Leistungs- und Flächeneinsparungen verglichen mit herkömmlichen GDDR5 SDRAM Systemen bereitstellt. In einer Ausführungsform umfasst jeder HBM2-Stapel vier Speicher-Dies und Y ist gleich 4, wobei der HBM2-Stapel zwei 128-Bit Kanäle pro Die für eine Gesamtzahl von 8 Kanälen und eine Datenbusbreite von 1024 Bit umfasst.
In einer Ausführungsform unterstützt der Speicher 304 Fehlerkorrekturcode (ECC) mit Einzelfehlerkorrektur und Doppelfehlerdetektion (SECDED), um Daten zu schützen. Der ECC stellt eine höhere Zuverlässigkeit für Rechenanwendungen bereit, die gegen Datenverfälschung empfindlich sind. Zuverlässigkeit ist besonders wichtig in großen Cluster-Rechenumgebungen, wo PPUs 300 sehr große Datensätze verarbeiten und/oder Anwendungen für längere Zeiträume ausführen.
In einer Ausführungsform implementiert die PPU 300 eine Mehr-Ebenen-Speicherhierarchie. In einer Ausführungsform unterstützt die Speicher-Partitions-Einheit 380 einen vereinheitlichten Speicher, um einen einzigen vereinheitlichten virtuellen Adressraum für den Speicher der CPU und den Speicher der PPU 300 bereitzustellen, der Datenteilung zwischen virtuellen Speichersystemen ermöglicht. In einer Ausführungsform wird die Häufigkeit von Zugriffen durch eine PPU 300 auf einen Speicher, der auf anderen Prozessoren lokalisiert ist, verfolgt, um sicherzustellen, dass Speicherseiten in den physischen Speicher der PPU 300 bewegt werden, die häufiger auf die Seiten zugreift. In einer Ausführungsform unterstützt das NVLink 310 Adressenübersetzungsdienste, die der PPU 300 erlauben, auf Seitentabellen einer CPU direkt zuzugreifen und einen vollen Zugriff auf den CPU-Speicher durch die PPU 300 bereitstellen.
In einer Ausführungsform transferieren Kopiermaschinen Daten zwischen mehreren PPUs 300 oder zwischen PPUs 300 und CPUs. Die Kopiermaschinen können Seitenfehler für Adressen erzeugen, die nicht in den Seitentabellen abgebildet werden. Die Speicher-Partitions-Einheit 380 kann dann die Seitenfehler bedienen, wobei die Adressen in der Seitentabelle abgebildet werden, wobei die Kopiermaschine den Transfer danach durchführen kann. In einem herkömmlichen System ist der Speicher für mehrere Kopiermaschinenoperationen zwischen mehreren Prozessoren gesperrt (d.h. nicht auslagerbar), was den verfügbaren Speicher wesentlich verringert. Mit Hardware-Seiten-Faulting können Adressen an die Kopiermaschinen weitergeleitet werden, ohne sich Sorgen zu machen, ob die Speicherseiten resident sind, und das Kopierverfahren ist transparent.
Daten von dem Speicher 304 oder einem anderen Systemspeicher können von der Speicher-Partitions-Einheit 380 geholt und in dem L2-Cache-Speicher 460 gespeichert werden, der Auf-Chip lokalisiert ist und zwischen den verschiedenen GPCs 350 gemeinsam benutzt wird. Wie gezeigt, umfasst jede Speicher-Partitions-Einheit 380 einen Bereich des L2-Cache-Speichers 460, der einer entsprechenden Speichervorrichtung 304 zugeordnet ist. Cache-Speicher niedrigerer Ebene können dann in verschiedenen Einheiten innerhalb der GPCs 350 implementiert werden. Beispielsweise kann jeder der SMs 440 einen L1-Cache-Speicher implementieren. Der L1-Cache-Speicher ist ein privater Speicher, der einem bestimmten SM 440 fest zugeordnet ist. Daten von dem L2-Cache-Speicher 460 können geholt und in jedem der L1-Cache-Speicher zur Verarbeitung in den Funktionseinheiten der SMs 440 gespeichert werden. Der L2-Cache-Speicher 460 ist mit der Speicherschnittstelle 470 und der XBar 370 gekoppelt.
Die ROP-Einheit 450 führt Graphik-Raster-Operationen durch, welche die Pixelfarbe betreffen, wie beispielsweise Farbenkomprimierung, Pixelmischung und dergleichen. Die ROP-Einheit 450 implementiert ebenfalls Tiefentesten in Verbindung mit der Raster-Engine 425, wobei eine Tiefe für einen Abtastort, der einem Pixelfragment zugeordnet ist, von der Aussonderungs-Engine der Raster-Engine 425 empfangen wird. Die Tiefe wird gegen eine entsprechende Tiefe in einem Tiefenpuffer für einen Abtastort geprüft, der dem Fragment zugeordnet ist. Wenn das Fragment den Tiefentest für den Abtastort besteht, dann aktualisiert die ROP-Einheit 450 den Tiefenpuffer und überträgt ein Ergebnis des Tiefentests an die Raster-Engine 425. Es wird anerkannt, dass sich die Anzahl von Partitions-Einheiten 380 von der Anzahl von GPCs 350 unterscheiden kann, und daher kann jede ROP-Einheit 450 mit jedem der GPCs 350 gekoppelt werden. Die ROP-Einheit 450 verfolgt Pakete, die von den unterschiedlichen GPCs 350 empfangen werden, und bestimmt, zu welchem GPC 350 ein durch die ROP-Einheit 450 erzeugtes Ergebnis von der Xbar 470 weitergeleitet wird. Obwohl die ROP-Einheit innerhalb der Speicher-Partitions-Einheit 380 in 4B umfasst ist, kann die ROP-Einheit 450 außerhalb der Speicher-Partitions-Einheit 380 sein. Beispielsweise kann die ROP-Einheit 450 in der GPC oder einer anderen Einheit liegen.
5A veranschaulicht den Streaming-Multiprozessor 440 von 4A gemäß einer Ausführungsform. Wie in 5A gezeigt, umfasst der SM 440 einen Anweisungs-Cache-Speicher 505, eine oder mehrere Planereinheiten 510, eine Registerdatei 520, einen oder mehrere Verarbeitungskerne 550, eine oder mehrere Spezialfunktionseinheiten (SFUs) 552, eine oder mehrere Lade/Speicher-Einheiten (LSUs) 554, ein Interconnect-Netzwerk 580 und einen gemeinsam benutzten L1-Cache-Speicher 570.
Wie oben beschrieben, versendet die Arbeitsverteilungs-Einheit 325 Aufgaben zur Ausführung auf den GPCs 350 der PPU 300. Die Aufgaben werden einem bestimmten DPC 420 innerhalb eines GPC 350 zugeteilt, und wenn die Aufgabe einem Shader-Programm zugeordnet ist, kann die Aufgabe einem SM 440 zugeteilt werden. Die Planereinheit 510 empfängt die Aufgaben von der Arbeitsverteilungs-Einheit 325 und verwaltet die Anweisungs-Planung (instruction scheduling) für einen oder mehrere Thread-Blöcke, die dem SM 440 zugewiesen sind. Die Planereinheit 510 plant Thread-Blöcke zur Ausführung als Warps von parallelen Threads, wobei jeder Thread-Block mindestens einem Warp zugeordnet ist. In einer Ausführungsform führt jeder Warp 32 Threads aus. Die Planereinheit 510 kann eine Mehrzahl von unterschiedlichen Thread-Blöcken verwalten, welche die Warps den unterschiedlichen Thread-Blöcken zuordnet und dann Anweisungen von der Mehrzahl von unterschiedlichen kooperativen Gruppen an die verschiedenen Funktionseinheiten (d.h. Kerne 550, SFUs 552 und LSUs 554) während jedes Taktzyklus versendet.
Cooperative Groups ist ein Programmiermodell zum Organisieren von Gruppen von kommunizierenden Threads, das Entwicklern ermöglicht, die Granularität auszudrücken, bei der Threads kommunizieren, wobei der Ausdruck von reicheren, effizienten Parallelzerlegungen ermöglicht wird. Cooperative-Start-APIs unterstützen die Synchronisierung unter Thread-Blöcken für die Ausführung von parallelen Algorithmen. Herkömmliche Programmiermodelle stellen einen einzigen, einfachen Aufbau zum Synchronisieren von kooperierenden Threads bereit: eine Barriere über alle Threads eines Threadblocks (d.h. die Funktion syncthreads( )). Programmierer würden jedoch häufig gerne Gruppen von Threads bei kleineren als Thread-Block-Granularitäten definieren und innerhalb der definierten Gruppen synchronisieren, um größere Leistung, Gestaltungsflexibilität und Software-Wiederverwendung in der Form von kollektiven gruppenweiten Funktionsschnittstellen zu ermöglichen.
Cooperative Groups ermöglicht Programmierern, Gruppen von Threads explizit bei Sub-Block(d.h. so klein wie ein einziger Thread)- und Mehr-Block-Granularitäten zu definieren und kollektive Operationen, wie beispielsweise Synchronisierung, an den Threads in einer kooperativen Gruppe durchzuführen. Das Programmiermodell unterstützt eine saubere Zusammensetzung über Softwaregrenzen, so dass Bibliotheken und Hilfsfunktionen innerhalb ihres lokalen Kontexts sicher synchronisieren können, ohne Annahmen über Konvergenz machen zu müssen. Cooperative-Groups-Primitiven ermöglichen neue Muster von kooperativer Parallelität, die Erzeuger-Verbraucher Parallelität, opportunistische Parallelität und globale Synchronisierung über ein gesamtes Gitter von Threadblöcken umfassen.
Eine Versandeinheit 515 ist konfiguriert, um Anweisungen an eine oder mehrere der Funktionseinheiten zu übertragen. In der Ausführungsform umfasst die Planereinheit 510 zwei Versandeinheiten 515, die ermöglichen, dass zwei unterschiedliche Anweisungen von dem gleichen Warp während jedes Taktzyklus versandt werden. In alternativen Ausführungsformen kann jede Planereinheit 510 eine einzige Versandeinheit 515 oder zusätzliche Versandeinheiten 515 umfassen.
Jeder SM 440 umfasst eine Registerdatei 520, die einen Satz von Registern für die Funktionseinheiten des SM 440 bereitstellt. In einer Ausführungsform ist die Registerdatei 520 zwischen jeder der Funktionseinheiten aufgeteilt, so dass jeder Funktionseinheit ein zugehöriger Abschnitt der Registerdatei 520 zugeteilt ist. In einer anderen Ausführungsform ist die Registerdatei 520 zwischen den unterschiedlichen Warps aufgeteilt, die von dem SM 440 ausgeführt werden. Die Registerdatei 520 stellt temporäre Speicherung für Operanden bereit, die mit den Datenpfaden der Funktionseinheiten verbunden sind.
Jeder SM 440 umfasst L Verarbeitungskerne 450. In einer Ausführungsform umfasst der SM 440 eine große Anzahl (z.B. 128 usw.) von unterschiedlichen Verarbeitungskernen 450. Jeder Kern 450 kann eine vollständig in einer Pipeline angeordnete (fullypipelined) Einfach-Präzisions- Verarbeitungseinheit umfassen, die eine Gleitkommaarithmetik-Logikeinheit und eine Ganzzahlarithmetik-Logikeinheit umfasst. In einer Ausführungsform implementieren die Gleitkommaarithmetik-Logikeinheiten den IEEE 754-3008 Standard für Gleitkommaarithmetik. In einer Ausführungsform umfassen die Kerne 550 64 Einfach-Präzisions-(32-Bit)-Gleitkommakerne, 64 Integer-Kerne, 32 Doppel-Präzisions-(64-Bit)-Gleitkommakerne und 8 Tensorkerne.
Tensorkerne, die konfiguriert sind, um Matrix-Operationen, und in einer Ausführungsform ein oder mehrere Tensorkerne durchzuführen, sind in den Kernen 550 umfasst. Insbesondere sind die Tensorkerne konfiguriert, um Deep-Learning-Matrix-Arithmetik, wie beispielsweise Faltungsoperationen für neuronales Netzwerktraining und Inferenzieren, durchzuführen. In einer Ausführungsform arbeitet jeder Tensorkern an einer 4×4 Matrix und führt eine Matrix-Multiplikations- und Akkumulations-Operation D=A×B+C durch, wobei A, B, C und D 4x4 Matrizen sind.
In einer Ausführungsform sind die Matrix-Multiplikations-Eingaben A und B 16-Bit-Gleitkomma-Matrizen, während die Akkumulationsmatrizen C und D 16-Bit-Gleitkomma- oder 32-Bit-Gleitkomma-Matrizen sein können. Tensorkerne arbeiten an 16-Bit-Gleitkomma-Eingabedaten mit 32-Bit-Gleitkomma-Akkumulation. Die 16-Bit-Gleitkomma-Multiplikation erfordert 64 Operationen und ergibt ein Produkt voller Präzision, das dann unter Verwendung einer 32-Bit-Gleitkomma-Addition mit den anderen Zwischenprodukten für eine 4x4x4-Matrix-Multiplikation akkumuliert wird. In der Praxis werden Tensorkerne verwendet, um viel größere zweidimensionale oder höherdimensionale Matrixoperationen durchzuführen, die von diesen kleineren Elementen aufgebaut werden. Eine API, wie beispielsweise die CUDA 9 C++ API, stellt spezialisierte Matrix-Lade-, Matrix-Multiplikations- und Matrix-Akkumulations- und Matrix-SpeicherOperationen bereit, um Tensorkerne von einem CUDA-C++ Programm effizient zu verwenden. Auf der CUDA-Ebene nimmt das Warp-Schnittstellenniveau 16x16 große Matrizen an, die alle 32 Threads des Warp überspannen.
Jeder SM 440 umfasst ebenfalls M SFUs 552, die Sonderfunktionen durchführen (z.B. Attributauswertung, reziproke Quadratwurzel und dergleichen). In einer Ausführungsform können die SFUs 552 eine Baumtraversierungseinheit umfassen, die konfiguriert ist, um eine hierarchische Baumdatenstruktur zu durchlaufen. In einer Ausführungsform können die SFUs 552 eine Textureinheit umfassen, die konfiguriert ist, um Texturkarten-Filteroperationen durchzuführen. In einer Ausführungsform sind die Textureinheiten konfiguriert, um Texturkarten (z.B. eine 2D-Anordnung von Texeln) von dem Speicher 304 zu laden und die Texturkarten abzutasten, um abgetastete Texturwerte zum Gebrauch in Shader-Programmen zu erzeugen, die von dem SM 440 ausgeführt werden. In einer Ausführungsform werden die Texturkarten in dem gemeinsam benutzten Speicher/L1-Cache-Speicher 470 gespeichert. Die Textureinheiten implementieren Texturoperationen, wie beispielsweise Filteroperationen, unter Verwendung von Mip-Maps (d.h. Texturkarten von veränderlichem Detaillierungsgrad). In einer Ausführungsform umfasst jeder SM 340 zwei Textureinheiten.
Jeder SM 440 umfasst ebenfalls N LSUs 554, die Lade- und Speicheroperationen zwischen dem gemeinsam benutzten Speicher/L1-Cache-Speicher 570 und der Registerdatei 520 implementieren. Jeder SM 440 umfasst ein Interconnect-Netzwerk 580, das jede der Funktionseinheiten mit der Registerdatei 520 und die LSU 554 mit der Registerdatei 520, dem gemeinsam benutzten Speicher/ L1-Cache-Speicher 570 verbindet. In einer Ausführungsform ist das Interconnect-Netzwerk 580 eine Kreuzschiene, die konfiguriert sein kann, um irgendeine der Funktionseinheiten mit irgendeinem der Register in der Registerdatei 520 zu verbinden und die LSUs 554 mit der Registerdatei und Speicherorten im gemeinsam benutzten Speicher/L1-Cache-Speicher 570 zu verbinden.
Der gemeinsam benutzte Speicher/L1-Cache-Speicher 570 ist eine Auf-Chip-Speicheranordnung, die Datenspeicherung und Kommunikation zwischen dem SM 440 und der Primitiven-Engine 435 und zwischen Threads in dem SM 440 ermöglicht. In einer Ausführungsform umfasst der gemeinsam benutzte Speicher/L1-Cache-Speicher 570 128KB von Speicherkapazität und ist in dem Pfad von dem SM 440 zu der Partitions-Einheit 380. Der gemeinsam benutzte Speicher/L1-Cache-Speicher 570 kann verwendet werden, um Lese- und Schreibvorgänge zwischenzuspeichern. Einer oder mehrere der gemeinsam benutzten Speicher/L1-Cache-Speicher 570, L2-Cache-Speicher 460 und Speicher 304 sind Hintergrundspeicher.
Das Kombinieren von Daten-Cache und gemeinsam benutzter Speicherfunktionalität in einem einzigen Speicherblock stellt die beste Gesamtleistung für beide Arten von Speicherzugriffen bereit. Die Kapazität ist als ein Cache von Programmen benutzbar, die den gemeinsam benutzten Speicher nicht verwenden. Wenn der gemeinsam benutzte Speicher beispielsweise konfiguriert ist, die Hälfte der Kapazität zu verwenden, können Textur- und Lade/Speicher-Operationen die verbleibende Kapazität verwenden. Integration innerhalb des gemeinsam benutzten Speichers/L1-Cache-Speicher 570 ermöglicht dem gemeinsam benutzten Speicher/L1-Cache-Speicher 570 als eine Leitung mit hohem Durchsatz zum Streamen von Daten zu arbeiten, während gleichzeitig eine höhere Bandbreite und ein latenzarmer Zugriff auf häufig wiederverwendete Daten bereitgestellt werden.
Wenn für Allzweck-Parallelberechnung konfiguriert, kann im Vergleich mit der Graphikverarbeitung eine einfachere Konfiguration verwendet werden. Im Einzelnen werden die in 3 gezeigten Festfunktions-Graphikverarbeitungseinheiten umgangen, wobei ein viel einfacheres Programmiermodell erzeugt wird. In der Allzweck-Parallelberechnungs-Konfiguration werden Blöcke von Threads von der Arbeitsverteilungs-Einheit 325 direkt den DPCs 420 zugewiesen und verteilt. Die Threads in einem Block führen das gleiche Programm aus, wobei eine eindeutige Thread-ID in der Berechnung verwendet wird, um sicherzustellen, dass jeder Thread eindeutige Ergebnisse erzeugt, der SM 440 verwendet wird, um das Programm auszuführen und Berechnungen durchzuführen, ein gemeinsam benutzter Speicher/L1-Cache-Speicher 570 verwendet wird, um zwischen Threads zu kommunizieren, und der LSU 554 verwendet wirds, um einen globalen Speicher durch den gemeinsam benutzten Speicher/L1-Cache-Speicher 570 und die Speicher-Partitions-Einheit 380 zu lesen und zu beschreiben. Wenn für Allzweck-Parallelberechnung konfiguriert, kann der SM 440 ebenfalls Befehle schreiben, welche die Planereinheit 320 verwenden kann, um neue Arbeit auf den DPCs 420 zu starten.
Die PPU 300 kann in einem Tischcomputer, einem Laptop-Computer, einem Tablet-Computer, einem Smartphone (z.B. einer drahtlosen handgehaltenen Vorrichtung), einem persönlichen digitalen Assistenten (PDA), einer Digitalkamera, einer handgehaltenen elektronischen Vorrichtung und dergleichen umfasst sein. In einer Ausführungsform ist die PPU 300 auf einem einzelnen Halbleitersubstrat verkörpert. In einer anderen Ausführungsform ist die PPU 300 in einem System-auf-Chip (SoC) zusammen mit einer oder mehreren anderen Vorrichtungen, wie beispielsweise zusätzlichen PPUs 300, dem Speicher 204, einem Rechner-mit-reduziertem-Befehlssatz(RISC)-CPU, einer Speicherverwaltungseinheit (MMU), einem Digital/Analog-Wandler (DAC) und dergleichen umfasst.
In einer Ausführungsform kann die PPU 300 auf einer Graphikkarte umfasst sein, die eine oder mehrere Speichervorrichtungen 304 umfasst. Die Graphikkarte kann konfiguriert sein, um sich mit einem PCIe-Schlitz auf einer Hauptplatine eines Tischcomputers schnittstellenmäßig zu verbinden. In noch einer anderen Ausführungsform kann die PPU 300 eine integrierte Graphikverarbeitungseinheit (iGPU) oder ein Parallelprozessor sein, der in dem Chipsatz der Hauptplatine umfasst ist.
Beispielhaftes Rechensystem
Systeme mit mehrere GPUs und CPUs werden in einer Vielfalt von Industrien verwendet, sowie Entwickler mehr Parallelität in Anwendungen, wie beispielsweise Rechnen für künstliches Intelligenz, freilegen und wirksam einsetzen. Hochleistungs-GPU-beschleunigte Systeme mit zehn bis vielen tausenden von Rechenknoten werden in Datenzentren, Forschungsanlagen und Supercomputern eingesetzt, um immer größere Probleme zu lösen. Sowie die Anzahl von Verarbeitungsvorrichtungen innerhalb der Hochleistungssysteme zunimmt, müssen die Kommunikations- und Datentransfermechanismen angepasst werden, um die erhöhte Bandbreite zu unterstützen.
5B ist ein Konzeptdiagramm eines Verarbeitungssystems 500, das unter Verwendung der PPU 300 von 3 implementiert wird, gemäß einer Ausführungsform. Das beispielhafte System 565 kann konfiguriert sein, um das in 1C gezeigte Verfahren 130, das in 1E gezeigte Verfahren 150 oder das in 2B gezeigte Verfahren 220 zu implementieren. Das Verarbeitungssystem 500 umfasst eine CPU 530, einen Schalter 510 und jeweils mehrere PPUs 300 und jeweilige Speicher 304. Das NVLink 310 stellt Hochgeschwindigkeits-Kommunikationsverbindungen zwischen jeder der PPUs 300 bereit. Obwohl eine bestimmte Anzahl von NV-Link 350 und Interconnect 302 Verbindungen in 5B veranschaulicht sind, kann die Anzahl an jeder PPU 300 und der CPU 530 variieren. Der Schalter 510 ist schnittstellenmäßig zwischen dem Interconnect 302 und der CPU 530 verbunden. Die PPUs 300, die Speicher 304 und die NVLinks 310 können auf einer einzigen Halbleiterplattform gelegen sein, um ein Parallelverarbeitungsmodul 525 zu bilden. In einer Ausführungsform unterstützt der Schalter 50 zwei oder mehrere Protokolle, um sich schnittstellenmäßig zwischen verschiedenen Verbindungen und/oder Links zu verbinden.
In einer anderen Ausführungsform (nicht gezeigt) stellt das NVLink 310 ein oder mehrere Hochgeschwindigkeits-Kommunikationslinks zwischen jeder der PPUs 300 und der CPU 530 bereit und der Schalter 510 ist schnittstellenmäßig zwischen dem Interconnect 302 und jeder der PPUs 300 verbunden. Die PPUs 300, die Speicher 304 und der Interconnect 302 können auf einer einzigen Halbleiterplattform gelegen sein, um ein Parallelverarbeitungsmodul 525 zu bilden. In noch einer anderen Ausführungsform (nicht gezeigt) stellt der Interconnect 302 ein oder mehrere Kommunikationslinks zwischen jeder der PPUs 300 und der CPU 530 bereit und der Schalter 510 ist schnittstellenmäßig zwischen jeder der PPUs 300 unter Verwendung des NVLink 310 verbunden, um ein oder mehrere Hochgeschwindigkeits-Kommunikationslinks zwischen den PPUs 300 bereitzustellen. In einer anderen Ausführungsform (nicht gezeigt) stellt das NVLink 310 ein oder mehrere Hochgeschwindigkeits-Kommunikationslinks zwischen den PPUs 300 und der CPU 530 durch den Schalter 510 bereit. In noch einer anderen Ausführungsform (nicht gezeigt) stellt der Interconnect 302 ein oder mehrere Hochgeschwindigkeits-Kommunikationslinks zwischen jeder der PPUs 300 direkt bereit. Ein oder mehrere der NVLink 310 Hochgeschwindigkeits-Kommunikationslinks können als ein physischer NVLink-Interconnect oder entweder als ein Auf-Chip- oder Auf-Die-Interconnect unter Verwendung des gleichen Protokolls wie das NVLink 310 implementiert werden.
Im Kontext der vorliegenden Beschreibung kann sich eine einzige Halbleiterplattform auf eine einzelne unitäre Halbleiter-basierte integrierte Schaltung beziehen, die auf einem Die oder Chip angefertigt ist. Es sei bemerkt, dass sich der Begriff einzige Halbleiterplattform ebenfalls auf Mehr-Chip-Module mit erhöhter Konnektivität beziehen kann, die eine Auf-Chip-Operation simulieren und die wesentliche Verbesserungen gegenüber der Benutzung einer herkömmlichen Busimplementierung vornehmen. Natürlich können die verschiedenen Schaltungen oder Vorrichtungen ebenfalls getrennt oder in verschiedenen Kombinationen von Halbleiterplattformen gemäß den Wünschen des Benutzers gelegen sein. Alternativ kann das Parallelverarbeitungsmodul 525 als ein Leiterplattensubstrat implementiert sein und jede der PPUs 300 und/oder Speicher 304 können verpackte Vorrichtungen sein. In einer Ausführungsform sind die CPU 530, der Schalter 510 und das Parallelverarbeitungsmodul 525 auf einer einzigen Halbleiterplattform gelegen.
In einer Ausführungsform ist die Signalrate von jedem NVLink 310 gleich 20 bis 25 Gigabit/s und jede PPU 300 umfasst sechs NVLink 310 Schnittstellen (wie in 5B gezeigt, sind fünf NVLink 310 Schnittstellen für jede PPU 300 enthalten). Jedes NVLink 310 stellt eine Datentransferrate von 25 Gigabyte/s in jeder Richtung bereit, wobei sechs Verknüpfungen 300 Gigabyte/s bereitstellen. Die NVLinks 310 können exklusiv für PPU-zu-PPU Kommunikation, wie in 5B gezeigt, oder einer Kombination von PPU-zu-PPU und PPU-zu-CPU verwendet werden, wenn die CPU 530 ebenfalls eines oder mehrere NVLink 310 Schnittstellen umfasst.
In einer Ausführungsform ermöglicht das NVLink 310 einen direkten Lade/Speicher/atomaren Zugriff von der CPU 530 auf jeden Speicher 304 der PPU 300. In einer Ausführungsform unterstützt das NVLink 310 Kohärenzoperationen, die ermöglichen, das von dem Speicher 304 gelesene Daten in der Cache-Hierarchie der CPU 530 gespeichert werden können, was die Cachezugriffslatenz für die CPU 530 verringert. In einer Ausführungsform umfasst das NVLink 310 Unterstützung für Address Translation Services (ATS), was der PPU 300 ermöglicht, auf Seitentabellen innerhalb der CPU 530 direkt zuzugreifen. Eines oder mehrere der NVLinks 310 können ebenfalls konfiguriert sein, um in einem Niedrigleistungsmodus zu arbeiten.
5C veranschaulicht ein beispielhaftes System 565, bei dem die verschiedene Architektur und/oder Funktionalität der verschiedenen vorherigen Ausführungsformen implementiert werden kann. Das beispielhafte System 565 kann konfiguriert sein, um das in 1E gezeigte Verfahren 130, das in 1E gezeigte Verfahren 150 oder das in 2B gezeigte Verfahren 220 zu implementieren.
Wie gezeigt, wird ein System 565 bereitgestellt, das mindestens eine zentrale Verarbeitungseinheit 530 umfasst, die mit einem Kommunikationsbus 575 verbunden ist. Der Kommunikationsbus 575 kann unter Verwendung jedes geeigneten Protokolls, wie beispielsweise PCI (Peripheral Component Interconnect), PCI-Express, AGP (Accelerated Graphics Port), Hyper-Transport oder irgendeinem(irgendwelchen) anderen Bus- oder Punkt-zu-Punkt-Kommunikationsprotokoll(en) implementiert sein. Das System 565 umfasst ebenfalls einen Hauptspeicher 540. Steuerlogik (Software) und Daten werden in dem Hauptspeicher 540 gespeichert, der die Form eines Direkt-Zugriffs-Speichers (RAM) annehmen kann.
Das System 565 umfasst ebenfalls Eingabevorrichtungen 560, das Parallelverarbeitungssystem 525 und Anzeigevorrichtungen 545, d.h. eine herkömmliche CRT (Kathodenstrahlröhre), eine LCD (Flüssigkristallanzeige), eine LED (lichtemittierende Diode), eine Plasmaanzeige oder dergleichen. Eine Benutzereingabe kann von den Eingabevorrichtungen 560, z.B. Tastatur, Maus, Berührfeld, Mikrophon und dergleichen, empfangen werden. Jedes der vorhergehenden Module und/oder Vorrichtungen kann sogar auf einer einzigen Halbleiterplattform gelegen sein, um das System 565 zu bilden. Alternativ können die verschiedenen Module ebenfalls getrennt oder in verschiedenen Kombinationen von Halbleiterplattformen gemäß den Wünschen des Benutzers gelegen sein.
Ferner kann das System 565 mit einem Netzwerk (z.B. einem Telekommunikationsnetzwerk, Lokalbereichsnetzwerk (LAN), drahtlosen Netzwerk, Weitbereichsnetzwerk (WAN), wie beispielsweise dem Internet, Peer-zu-Peer-Netzwerk, Kabelnetzwerk oder dergleichen) durch eine Netzwerkschnittstelle 535 für Kommunikationszwecke gekoppelt sein.
Das System 565 kann ebenfalls einen Sekundärspeicher umfassen (nicht gezeigt). Der Sekundärspeicher 610 umfasst beispielsweise ein Festplattenlaufwerk und/oder ein entfernbares Speicherlaufwerk, das ein Diskettenlaufwerk darstellt, ein Magnetbandlaufwerk, ein Kompaktdisklaufwerk, ein digitale versatile Disk-(DVD)-Laufwerk, eine Aufzeichnungsvorrichtung und einen Universal-Serial-Bus-(USB)-Flash-Speicher. Das entfernbare Speicherlaufwerk liest von und/oder schreibt auf eine entfernbare Speichereinheit auf eine wohlbekannte Art und Weise.
Computerprogramme oder Computersteuerlogik-Algorithmen können in dem Hauptspeicher 540 und/oder dem Sekundärspeicher gespeichert sein. Derartige Computerprogramme, wenn ausgeführt, ermöglichen dem System 565, verschiedene Funktionen durchzuführen. Der Speicher 540, die Speicherung, und/oder jede andere Speicherung sind mögliche Beispiele von computerlesbaren Medien.
Die Architektur und/oder die Funktionalität der verschiedenen vorherigen Figuren kann im Kontext eines allgemeinen Computersystems, eines Leiterplattensystems, eines Unterhaltungszwecken fest zugeordneten Spielkonsolensystems, eines anwendungsspezifischen Systems und/oder jedem anderen gewünschten System implementiert sein. Beispielsweise kann das System 565 die Form eines Tischcomputers, eines Laptop-Computers, eines Tablet-Computers, von Servern, von Supercomputern, eines Smartphones (z.B. einer drahtlosen handgehaltenen Vorrichtung), eines persönlichen digitalen Assistenten (PDA), einer Digitalkamera, eines Fahrzeugs, einer am Kopf angebrachten Anzeige, einer handgehaltenen elektronischen Vorrichtung, eines mobilen Telefongeräts, eines Fernsehers, einer Arbeitsstation, von Spielkonsolen, eines eingebetteten Systems und/oder von jedem anderen Typ von Logik annehmen.
Während verschiedene Ausführungsformen oben beschrieben wurden, sei zu verstehen, dass sie lediglich beispielhaft und nicht begrenzend präsentiert wurden. Somit sollte die Breite und der Umfang einer bevorzugten Ausführungsform nicht durch irgendeine der oben beschriebenen beispielhaften Ausführungsformen begrenzt werden, sondern sollte nur durch die folgenden Ansprüche und ihrer Äquivalente definiert werden.
Maschinenlernen
Tiefe neuronale Netzwerke (DNNs), die auf Prozessoren entwickelt wurden, wie beispielsweise der PPU 300, wurden für diverse Verwendungsfälle, von selbstfahrenden Wagen bis schnellerer Wirkstoffentwicklung, von automatischer Bildbeschriftung in Online-Bilddatenbanken bis smarter Echtzeit-Sprachenübersetzung in Video-Chat-Anwendungen verwendet. Deep-Learning ist eine Technik, welche das neuronale Lernverfahren des menschlichen Gehirns modelliert, die kontinuierlich lernt, kontinuierlich immer smarter wird und genauere Ergebnisse mit der Zeit schneller liefert. Ein Kind wird anfangs von einem Erwachsenen unterrichtet, verschiedene Formen korrekt zu identifizieren und zu klassifizieren, um schließlich imstande zu sein, Formen ohne irgendeine Nachhilfe zu identifizieren. Auf ähnliche Weise muss ein Tiefen-Learning-System oder ein neuronales Lernsystem in Objekterkennung und Klassifizierung trainiert werden, damit es smarter und effizienter beim Identifizieren von Grundobjekten, verdeckten Objekte usw. wird, während ebenfalls Objekten Kontext zugewiesen wird. Beispielsweise wird ein neuronales Lernsystem zur Orientierungspunkt-Lokalisierung und/oder Attributklassifizierung trainiert
Auf der einfachsten Ebene schauen Neuronen im menschlichen Gehirn auf verschiedene Eingaben, die empfangen werden, wobei Wichtigkeitsgrade jeder dieser Eingaben zugewiesen werden und eine Ausgabe an andere Neuronen weitergeleitet wird, um auf diese zu wirken. Ein künstliches Neuron oder ein Perzeptron ist das grundlegendste Modell eines neuronalen Netzwerks. In einem Beispiel kann ein Perzeptron eine oder mehrere Eingaben empfangen, die verschiedene Merkmale eines Objekts darstellen, die das Perzeptron trainiert wird, zu erkennen und zu klassifizieren, und jedem dieser Merkmale wird ein bestimmtes Gewicht basierend auf der Wichtigkeit des Merkmals beim Definieren der Gestalt eines Objekts zugewiesen.
Ein Modell eines tiefen neuronalen Netzwerks (DNN) umfasst mehrere Schichten von vielen verbundenen Perzeptronen (z.B. Knoten), die mit enormen Mengen an Eingabedaten trainiert werden können, um komplexe Probleme mit hoher Genauigkeit schnell zu lösen. In einem Beispiel gliedert eine erste Schicht des DLL-Modells ein Eingabebild eines Automobils in verschiedene Abschnitte auf und sucht nach Grundmustern, wie beispielsweise Linien und Winkel. Die zweite Schicht setzt die Linien zusammen, um nach Mustern höherer Ebene, wie beispielsweise Rädern, Windschutzscheiben und Spiegeln, zu suchen. Die nächste Schicht kennzeichnet den Typ des Fahrzeugs und die letzten paar Schichten erzeugen ein Etikett für das Eingabebild, welches das Modell einer speziellen Automobilmarke kennzeichnet.
Sobald das DNN trainiert ist, kann das DNN eingesetzt und verwendet werden, um Objekte oder Muster in einem als Inferenz bekannten Verfahren zu identifizieren und zu klassifizieren. Beispiele von Inferenz (der Prozess, durch den ein DNN nützliche Information von einer gegebenen Eingabe extrahiert) umfassen ein Identifizieren handgeschriebener Zahlen auf Schecks, die in Geldausgabe-Maschinen eingezahlt werden, ein Identifizieren von Bildern von Freunden in Photos, Liefern von Filmempfehlungen an über fünfzig Millionen Nutzer, Identifizieren und Klassifizieren unterschiedlicher Typen von Automobilen, Fußgängern und Straßengefahren in fahrerlosen Wagen oder Übersetzen von menschlicher Sprache in Echtzeit.
Während des Trainings strömen Daten durch das DNN in einer Vorwärtspropagierungsphase, bis eine Vorhersage erzeugt wird, die ein Etikett angibt, das der Eingabe entspricht. Wenn das neuronale Netzwerk die Eingabe nicht korrekt kennzeichnet, dann werden Fehler zwischen dem korrekten Etikett und dem vorhergesagten Etikett analysiert und die Gewichte werden für jedes Merkmal während einer Rückwärtspropagierungsphase eingestellt, bis das DNN die Eingabe und andere Eingaben in einem Trainingsdatensatz korrekt kennzeichnet. Das Training komplexer neuronaler Netzwerke erfordert enorme Mengen an paralleler Rechenleistung, die Gleitkomma-Multiplikationen und Gleitkomma-Additionen umfassen, die von der PPU 300 unterstützt werden. Inferenzieren ist weniger rechenintensiv als Training, das ein Latenz-empfindliches Verfahren ist, wo ein trainiertes neuronales Netzwerk auf neue Eingaben angewandt wird, die es zuvor nicht gesehen hat, um Bilder zu klassifizieren, Sprache zu übersetzen und im Allgemeinen neue Informationen abzuleiten.
Neuronale Netzwerke stützen sich sehr auf Matrixrechenoperationen und komplexe mehrschichtige Netzwerke erfordern enorme Mengen an Gleitkomma-Leistung und Bandbreite für sowohl Effizienz als auch Geschwindigkeit. Mit Tausenden von Verarbeitungskernen, die für Matrixrechenoperationen optimiert sind und einige zehn bis hunderte von TFLOPS von Leistung liefern, ist die PPU 300 eine Rechenplattform, die imstande ist, Leistung zu liefern, die für tiefe neuronale Netzwerk-basierte künstliche Intelligenz und Maschinenlernanwendungen erforderlich ist.

Claims

Computerimplementiertes Verfahren, umfassend: Empfangen eines Eingangsbildes bei einem tiefen neuronalen Netzwerk (DNN), wobei Gewichtungen des DNN eine Kartendarstellung einer Umgebung definieren und die Gewichtungen während eines Trainings unter Verwendung eines etikettierten Trainingsdatensatzes bestimmt werden, der Bilder und entsprechende absolute Kameraposen und relative Kameraposen umfasst; und Anwenden, durch das DNN, der Gewichtungen auf das Eingangsbild, um eine geschätzte Kamerapose zur Erfassung der Umgebung zu generieren und das Eingangsbild zu erzeugen.
Computerimplementiertes Verfahren gemäß Anspruch 1, wobei während des Trainings Bildpaare in das DNN eingegeben werden und entsprechende geschätzte Kameraposenpaare durch das DNN erzeugt werden.
Computerimplementiertes Verfahren gemäß Anspruch 2, wobei ein Bildpaar ein erstes Bild und ein zusätzliches Bild in einer Bildsequenz umfasst und ein oder mehrere dazwischenliegende Bilder zwischen dem ersten Bild und dem zusätzlichen Bild auftreten können.
Computerimplementiertes Verfahren gemäß Anspruch 2 oder 3, wobei während des Trainings relative geschätzte Kameraposen für jedes geschätzte Kameraposenpaar berechnet werden.
Computerimplementiertes Verfahren gemäß Anspruch 4, wobei während des Trainings die Gewichtungen modifiziert werden, um Unterschiede zwischen den relativen geschätzten Kameraposen und den relativen Kameraposen, die in dem Trainingsdatensatz umfasst sind, und Unterschiede zwischen den geschätzten Kameraposen, die durch das DNN erzeugt werden, und den absoluten Kameraposen, die in dem Trainingsdatensatz umfasst sind, gleichzeitig zu verringern.
Computerimplementiertes Verfahren gemäß einem der vorangehenden Ansprüche, wobei ein Rotationsabschnitt der geschätzten Kamerapose als ein dreidimensionaler Logarithmus eines Einheitsquaternions parametrisiert wird.
Computerimplementiertes Verfahren gemäß einem der vorangehenden Ansprüche, ferner umfassend: Empfangen visueller Odometriedaten, die dem Eingangsbild entsprechen; und Modifizieren der Gewichtungen des DNN, um Unterschiede zwischen den visuellen Odometriedaten und einer relativen Kamerapose, die unter Verwendung der geschätzten Kamerapose berechnet werden, und einer zusätzlichen geschätzten Kamerapose, die durch das DNN generiert wird, zu minimieren.
Computerimplementiertes Verfahren gemäß einem der vorangehenden Ansprüche, ferner umfassend: Empfangen globaler Positionssensordaten, die dem Eingangsbild entsprechen; und Modifizieren der Gewichtungen, um Unterschiede zwischen den globalen Positionssensordaten und der geschätzten Kamerapose zu minimieren.
Computerimplementiertes Verfahren gemäß einem der vorangehenden Ansprüche, ferner umfassend: Empfangen von Trägheitsmessdaten, die dem Eingangsbild entsprechen; und Modifizieren der Gewichtungen, um Unterschiede zwischen den Trägheitsmessdaten und der geschätzten Kamerapose zu minimieren.
Computerimplementiertes Verfahren gemäß einem der vorangehenden Ansprüche, ferner umfassend eine Nachbearbeitung der geschätzten Kamerapose unter Verwendung von Posengraphenoptimierung (PGO), um eine verfeinerte Kamerapose zu erzeugen.
Computerimplementiertes Verfahren gemäß einem der vorangehenden Ansprüche, wobei das DNN mindestens eine Faltungs-Neuronal-Netzwerkschicht, gefolgt von einer globalen Durchschnitts-Pooling-Schicht, gefolgt von einer vollständig verbundenen Schicht umfasst, um die geschätzte Kamerapose auszugeben.
System, umfassend: ein tiefes neuronales Netzwerk (DNN), das konfiguriert ist, um: ein Eingangsbild zu empfangen, wobei Gewichtungen des DNN eine Kartendarstellung einer Umgebung definieren und die Gewichtungen während des Trainings unter Verwendung eines etikettierten Trainingsdatensatz bestimmt werden, der Bilder und entsprechende absolute Kameraposen und relative Kameraposen umfasst; und die Gewichtungen auf das Eingangsbild anzuwenden, um eine geschätzten Kamerapose zur Erfassung der Umgebung zu generieren, um das Eingangsbild zu erzeugen.
System gemäß Anspruch 12, wobei während des Trainings Bildpaare in das DNN eingegeben werden und entsprechende geschätzte Kameraposenpaare durch das DNN generiert werden, ferner umfassend eine relative Posenberechnungseinheit, die konfiguriert ist, um relative geschätzte Kameraposen für jedes geschätzte Kameraposenpaar während des Trainings zu berechnen.
System gemäß Anspruch 13, ferner umfassend eine Trainingsverlusteinheit, die konfiguriert ist, um die Gewichtungen während des Trainings zu modifizieren, um Unterschiede zwischen den relativen geschätzten Kameraposen und den relative Kameraposen, die in dem Trainingsdatensatz umfasst sind, und Unterschiede zwischen den geschätzten Kameraposen, die durch das DNN generiert werden, und den absoluten Kameraposen, die in dem Trainingsdatensatz umfasst sind, gleichzeitig zu verringern.
System gemäß einem der Ansprüche 12 bis 14, ferner umfassend eine Trainingsverlusteinheit, die konfiguriert ist, um: visuelle Odometriedaten zu empfangen, die dem das Eingangsbild entsprechen; und die Gewichtungen des DNN zu modifizieren, um Unterschiede zwischen den visuellen Odometriedaten und einer relativen Kamerapose, die unter Verwendung der geschätzten Kamerapose berechnet wird, und einer zusätzlichen geschätzten Kamerapose, die durch das DNN generiert wird, zu minimieren.
System gemäß Anspruch 12, ferner umfassend eine Posengraphenoptimierungseinheit, die konfiguriert ist, um die geschätzte Kamerapose unter Verwendung von Posengraphenoptimierung (PGO) nachzubearbeiten, um eine verfeinerte Kamerapose zu erzeugen.
System, wie in einem der Ansprüche 12 bis 16 erwähnt, das ferner konfiguriert wird, um ein Verfahren auszuführen, wie in einem der Ansprüche 1 bis 11 erwähnt.
Nichttransitorisches computerlesbares Medium, das Computeranweisungen zum Schätzen von Kameraposen speichert, die, wenn von einem oder mehreren Prozessoren ausgeführt, den einen oder mehrere Prozessoren veranlassen, die Schritte eines Verfahrens durchzuführen, wie in einem der Ansprüche 1 bis 11 erwähnt.